Designing PCS7 Custom Blocks for OEM Library Development

Overview: What "PCS7 Block Design" Actually Means

Within SIMATIC PCS7, a "block designer" is the engineer who authors the reusable type definitions (FB types, FC types, UDTs, block icons, faceplates) that an OEM plant supplier ships to end customers as a project-specific library. The role is fundamentally different from a CFC chart engineer who instantiates pre-built blocks in a process tag. A block designer produces the building blocks themselves, typically through SCL (Structured Control Language) source plus CFC/SFC (Continuous Function Chart / Sequential Function Chart) composition, and packages them into a master data library that downstream engineering stations consume.

The PCS7 ecosystem does not ship a single standalone "Block Designer" utility in the way it ships, for example, the CFC editor. Block authoring is performed with the standard PCS7 Engineering Station (ES) toolchain - SIMATIC Manager or the TIA-based PCS7 Engineering (depending on the PCS7 version in service), the SCL compiler, the CFC/SFC editor, the Type/Instance Manager, and for the OS side, WinCC Explorer for the block icon (faceplate) and the Graphics Designer. There is no cloud-based OEM block-authoring portal supplied by Siemens for this task; everything happens on the ES.

PCS7 Block Design Architecture: ES, AS, and OS

Before discussing tools, the block designer must understand the three-tier topology into which their blocks will be loaded.

A custom block designed for an OEM library must be valid on all three tiers. Forgetting the OS-side block icon (the visual representation in WinCC) is the single most common defect when designers hand a library over to a customer site. The block works perfectly in CFC and runs on the AS, but the operator sees a yellow placeholder rectangle in the OS picture because no @PCS7Typicals faceplate was bound.

Block Categories You Will Design

An OEM master data library typically contains blocks from several categories. The block designer must understand each layer because the SCL signature, the CFC interface, and the WinCC faceplate attributes all change between categories.

Driver Blocks (Channel Layer)

Driver blocks form the bottom of the hierarchy and convert raw signal-processing into standardized PCS7 process tags. Typical examples are CH_AI (analog input), CH_DI (digital input), CH_AO, CH_DO, and the F-channel variants for safety-instrumented functions. A block designer rarely creates new driver blocks from scratch but may extend signal-conditioning parameters (linearization tables, unit conversion) on a project-specific subclass.

Technological Blocks (Control Layer)

Technological blocks implement the closed-loop and sequential logic - CTRL_PID, CTRL_S (step controller), MOT_SPEED, VALVE_ANA, VALVE_DIG, DOSE, RCP (recipe), and the safety blocks. Custom OEM variants normally subclass an existing technological block via the Type/Instance model rather than re-implementing from raw I/O.

Custom Application Blocks

These are the blocks an OEM block designer actually authors. They typically encode a vendor-specific piece of equipment - a burner management sequence, a CIP (clean-in-place) skid, a heat exchanger model, a kiln burner, a compressor surge controller. The SCL source implements the algorithm; the CFC composition wires it to PCS7 I/O; the faceplate exposes it to operations.

Block Icons (OS Faceplates)

The OS-side visual: a WinCC picture with operator inputs, setpoint sliders, mode selector, bar graph, and message priority. Every PCS7 block type must have a matching block icon, or the operator sees no faceplate when they click the field device in the overview.

Required Toolchain on the Engineering Station

There is no smaller subset that produces a working OEM block. The block designer must install and authorize the following on the ES:

1. SIMATIC PCS7 ES (full installation with the option packages required by the target version - typically "PCS7 Engineering", "SCL", "CFC", "SFC", "Type/Instance Manager", "IMAP").
2. STEP 7 / SIMATIC Manager or the TIA Portal component that hosts the PCS7 project (depending on PCS7 version - V8.x uses classic STEP 7; V9.x introduces TIA-based engineering where supported).
3. S7-PLCSIM or S7-PLCSIM Advanced (for offline simulation - mandatory for any "home office" workflow).
4. WinCC Explorer with the PCS7 OS option (only required for OS-side block-icon design and faceplate validation).
5. PCS7 Library Automation License Manager entries for SCL compiler, CFC, SFC, and versioned library support.
6. Optional but standard: Versioned library (VL) admin tool, the PCS7 Master Data Library Generator, and the PCS7 Library Update Tool.

The Type/Instance Paradigm (Why It Matters)

PCS7's central engineering concept is the distinction between a block type (the master definition, one copy per OEM library) and a block instance (every actual field device, motor, valve, or controller in a customer project). A block designer works exclusively in the type layer; project engineers instantiate the types.

This model has direct consequences for OEM delivery:

• When the OEM ships a master data library to a customer, the customer receives only the type definitions. The customer ES then creates instances inside their project.
• Updating a block behavior means changing the type once in the OEM library; the change can be propagated to every instance via the Type/Instance Manager with change tracking.
• A versioned library (VL) records type revisions. A customer can roll back a type revision without losing their own instance parameters.

The Type/Instance Manager is therefore the block designer's daily tool. It lives in the PCS7 ES menu tree under "Options > Type/Instance Manager" and exposes revision diff, instance count per type, and the rules governing which instance attributes can be modified at the instance level versus which are locked to the type.

Authoring a Custom Block in SCL: Skeleton

The SCL source for a PCS7 block lives in the program's S7 program / Sources folder in the ES project. The block designer typically derives from a PCS7 base FB (such as FB 1869 in the PCS7 Basis Library) and overrides the cyclic method or adds user methods. A minimal skeleton for a custom technological block follows:

FUNCTION_BLOCK FB_CustomHeater
// Attribute 'S7_m_c' = true marks this FB as a PCS7-compliant
// type that participates in the OS faceplate generation.
{ S7_m_c := 'true' }
// Standard PCS7 interface section, version-tagged so the
// Type/Instance Manager can detect breaking interface changes.
VERSION : '1.0.0'
AUTHOR : 'OEM'
FAMILY : 'OEM_PLANT'
NAME : 'HTRE'

VAR_INPUT
  // Primary process value, sourced from upstream AI block
  iPV            : REAL;       // PV in engineering units
  iSP_Ext        : REAL;       // External setpoint from recipe
  iModeExt       : INT;        // Operator mode (0=Auto, 1=Manual, 2=Out)
  iManOp         : REAL;       // Manual output (0..100)
  iCfgHeatCool   : BOOL;       // TRUE=heat, FALSE=cool
END_VAR

VAR_OUTPUT
  oMV            : REAL;       // Manipulated variable 0..100
  oActMode       : INT;        // Active mode reported to OS
  oAlarmHH       : BOOL;       // High-high alarm
  oAlarmLL       : BOOL;       // Low-low alarm
  oStatus        : WORD;       // Status word, bit-coded per PCS7 spec
END_VAR

VAR
  // Internal state - persisted across scan cycles
  sPV_Filt       : REAL;       // 1st-order filtered PV
  sPID           : REAL;       // PID working value
  sTs            : REAL := 0.1;// Sample time [s]
  sKp            : REAL := 1.0;
  sTn            : REAL := 60.0;
  sTv            : REAL := 0.0;
  sOutLimHi      : REAL := 100.0;
  sOutLimLo      : REAL := 0.0;
END_VAR

BEGIN
  // 1. PV filtering (1st-order PT1)
  sPV_Filt := sPV_Filt + (iPV - sPV_Filt) * (1.0 - EXP(-0.001 / sTs));

  // 2. Mode arbitration - external always wins over operator
  IF iModeExt > 0 THEN
    oActMode := iModeExt;
  ELSE
    oActMode := 0; // Auto default
  END_IF;

  // 3. PID core (simplified positional algorithm)
  IF oActMode = 1 THEN
    oMV := LIMIT(sOutLimLo, iManOp, sOutLimHi);
  ELSE
    sPID := sPID + sKp * (iSP_Ext - sPV_Filt) * sTs;
    oMV := LIMIT(sOutLimLo, sPID, sOutLimHi);
  END_IF;

  // 4. Alarm generation per PCS7 convention
  oAlarmHH := sPV_Filt > (iSP_Ext * 1.10);
  oAlarmLL := sPV_Filt < (iSP_Ext * 0.90);

  // 5. Status word per PCS7 standard bit map
  oStatus.%X0 := (oActMode = 1);       // Bit0 = Manual active
  oStatus.%X1 := oAlarmHH OR oAlarmLL; // Bit1 = Alarm
  oStatus.%X2 := FALSE;                // Bit2 = Bad quality (TBD by channel)
END_FUNCTION_BLOCK

The key PCS7-specific constructs are the {S7_m_c := 'true'} attribute (declares master-data-library compatibility), the typed I/O interface (real, bool, int with engineering units), and the status word with PCS7-standard bit assignments. The status word convention is what allows the OS faceplate to render mode, alarm, and quality states consistently across the plant.

CFC Composition and Block Interconnection

The SCL block above defines what the algorithm does. The CFC chart defines how multiple blocks are wired together in a unit. The block designer typically also produces a "template chart" - a pre-wired CFC sheet that the customer drops into their unit, connects to their I/O, and parametrizes.

Rules of thumb for OEM template charts:

• Place all input conditioning (signal scaling, linearization) on the left of the sheet in a column.
• Place the main control block (your custom FB) in the center.
• Place the output handling (limit checks, alarms, output to AO block) on the right.
• Use named interconnects rather than implicit sheet-to-sheet carries so the chart survives a "Compile and Download" rebuild.
• Set the run sequence in the CFC chart menu: input block (priority 1), custom FB (priority 2), output block (priority 3). PCS7 compiles this into OB35 (or OB1) call order.

OS Block Icon (Faceplate) Design

Every PCS7 technological block requires an associated block icon stored in the OS picture hierarchy. The OS side is created in WinCC Explorer and Graphics Designer. The designer publishes a typical (a WinCC picture with the same name as the type) into the master data library's @PCS7Typicals folder.

A minimal block icon contains:

1. A symbol (the SVG/EMF graphic of the heater, motor, valve).
2. A faceplate window with five standard views: Standard, Trend, Alarm, Message, and Parameters.
3. Tag connections via the standard PCS7 attribute list (S7_m_c attribute above is what drives the connection automation).
4. Operator-authorization level settings per input element (operator vs. process engineer vs. service).

Library Packaging for OEM Delivery

The block designer must ship the OEM's custom library in a form the customer ES can consume. The standard delivery format is the versioned PCS7 master data library - a ZIP archive exported via "Options > PCS7 Library > Export" in the ES. The export contains:

• The S7 program with SCL sources, FBs, FCs, UDTs.
• CFC and SFC charts used as templates.
• The WinCC OS project files for block icons.
• A library readme with version, dependency list (which PCS7 Basis Library and AP Library revisions are required), and revision history.

The customer ES imports the ZIP via "Options > PCS7 Library > Import". The Type/Instance Manager then reads the new types into the customer's master data library folder.

Working from a Home Office: What's Realistically Possible

Returning to the original question: an OEM block designer can work from home, but only within the constraints of the ES toolchain. The realistic scenarios are:

Verification Checklist Before Shipping an OEM Library

Before sending a master data library to a customer, run this checklist on a clean PCS7 test project that mirrors the customer's expected version:

1. Import the library into a virgin test project. Resolve every dependency warning.
2. Instantiate each new type once. Confirm CFC and SFC compile without errors.
3. Download the test project to PLCSIM. Run each instance through its full mode/operating range.
4. Open the OS picture, click the symbol, confirm the faceplate opens and writes back to the instance.
5. Generate trend views, trigger each alarm class, confirm message frames appear in the OS log.
6. Update a parameter at the type level (Type/Instance Manager), confirm the change propagates to the test instance without a re-download of the entire AS.
7. Run "Compile and Download" twice. No warnings on the second pass = clean.
8. Export the test project as a backup ZIP and archive it next to the library delivery.

Common Pitfalls and Field-Proven Caveats

Block designers who deliver OEM libraries hit a recurring set of issues. The following are worth pre-empting on every release:

• Mixed-version AP Library: The customer has a different PCS7 Basis/AP Library revision. Always ship a minimum revision requirement in the readme. The Type/Instance Manager cannot silently upgrade a base FB referenced by your custom type.
• SCL attribute drift: Removing or renaming an I/O tag in a new revision breaks every existing customer instance. Use the optional S7_attr "m_c_interface_revision" string and bump it deliberately so the Type/Instance Manager flags incompatibilities.
• WinCC faceplate color states: The standard PCS7 status word bit map is referenced by the OS-side standard stylesheet. If you allocate bit positions arbitrarily, the customer's "Good/Bad" coloring flips silently. Follow the documented PCS7 status-bit convention.
• Run sequence conflicts: Multiple instances of your block in one CFC chart with different priorities cause intermittent logic ordering. Document the recommended run priority in the readme.
• Library signing and read-only delivery: OEM deliveries often need to be code-signed or at least MD5-stamped for traceability. Add a CHKSUM.TXT in the library ZIP.

Standards and Compliance References

OEM block designers working on process control libraries should keep the following reference documents close, not as guarantees but as design constraints to verify against for each customer domain:

• IEC 61131-3 - PLC programming languages (SCL is a textual IEC 61131-3 language, CFC is graphical).
• IEC 62443 - Industrial network and system security (relevant when the OEM block exposes OPC UA or Ethernet/IP data).
• NAMUR NE 107 - Field device status categorization; relevant when your block consumes diagnostic data from field instruments.
• IEC 61508 / IEC 61511 - Functional safety. If your block participates in a SIF (safety instrumented function), the design must meet the SIL target; PCS7 F-blocks run on the F-CPU in a separate runtime.

Frequently Asked Questions