PCS 7 vs S7-400: Architecture, Programming, and Use Cases

Overview: PCS 7 and the S7-400 Relationship

SIMATIC PCS 7 is not a different controller than the SIMATIC S7-400 — it is a higher-level engineering framework that runs on top of the S7-400 hardware platform. The S7-400 CPU family provides the physical execution engine, the backplane, the distributed I/O interfaces, and the communication processors that both STEP 7 projects and PCS 7 projects ultimately compile down to. The distinction between the two environments is therefore a distinction of engineering methodology, program organization, HMI integration, and process-control library scope, not of silicon or I/O capability.

An S7-400 programmed with the STEP 7 (or STEP 7 Professional / TIA Portal) toolset produces a generic automation program in which the engineer manually authors every block, every screen, and every alarm. A PCS 7 project produces a process-control program in which CFC (Continuous Function Chart), SFC (Sequential Function Chart), and SCL (Structured Control Language) blocks are placed on technology-oriented charts, and the WinCC operator screens, faceplates, alarm logging, and archive tags are generated automatically at compile time from those charts. Both projects ultimately execute on the same S7-400 firmware; the PCS 7 toolchain simply wraps the controller in a process-oriented library and a tightly bound HMI.

This reference article walks through the architectural, programming, runtime, and lifecycle differences between the two environments, and gives field engineers a decision matrix for selecting the right tool for a given application.

Hardware Platform: The S7-400 Backbone

The SIMATIC S7-400 is Siemens' modular, high-end PLC platform designed for standard and failsafe applications in manufacturing and process automation. Per the official Siemens product page, the S7-400 is "flexibly configurable" and is the designated execution platform for PCS 7 Automation Stations (AS).

Typical S7-400 building blocks used in both STEP 7 and PCS 7 projects include:

• Power supply modules (PS 405 / PS 407) — 10 A and 20 A versions for 24 V DC and 120/230 V AC input.
• Central Processing Units (CPU 410, CPU 412, CPU 414, CPU 416, CPU 417) — varying work memory, bit execution time, and communication resources. The CPU 410-5H is the standard failsafe / redundant PCS 7 controller.
• Signal modules (SM 421 / SM 422) — digital and analog input/output modules for the central rack.
• Function modules (FM) — for counting, positioning, and high-speed closed-loop control.
• Communication processors (CP 443-1, CP 443-5, CP 443-6) — PROFINET, PROFIBUS-DP, and Industrial Ethernet / IT integration.
• Interface modules (IM 460 / IM 461) — for multi-rack expansion up to 21 m of segmented backplane.

Reference: SIMATIC S7-400 – Siemens Product Page.

For PCS 7 deployments the typical automation station uses a CPU 410-5H (fail-safe / H-system) or CPU 417-4 for large plants, paired with ET 200M or ET 200SP remote I/O on PROFIBUS-DP or PROFINET. STEP 7-only projects may use the same CPUs, but a wider range of controller sizes (CPU 412, CPU 414) is common in machine-level applications where PCS 7 is overkill.

Programming Model: STEP 7 vs PCS 7

The most visible difference between a STEP 7 project and a PCS 7 project is the language and organization of the user program.

STEP 7 (Classic) Program Structure

A STEP 7 program for the S7-400 is structured around the following block types:

• Organization Blocks (OB) — interface between the operating system and the user program (OB1 main cyclic, OB10–OB17 time-of-day, OB35 cyclic interrupt, OB40 hardware interrupt, OB80–OB87 error, OB100–OB102 startup, OB121/OB122 programming error).
• Function Blocks (FB) — blocks with instance DBs used for reusable stateful logic.
• Functions (FC) — stateless subroutines.
• Data Blocks (DB) — shared and instance data storage.
• System Blocks (SFB / SFC) — Siemens-supplied blocks for time, counter, PID, and communication.

The engineer writes FBs, FCs, and DBs in LAD (Ladder), FBD (Function Block Diagram), STL (Statement List), or SCL (Structured Control Language) and explicitly calls those blocks from OB1 or from cyclic interrupt OBs such as OB35.

PCS 7 Program Structure

A PCS 7 program is structured around charts rather than directly around blocks:

• CFC charts (Continuous Function Chart) — graphically place pre-engineered blocks from the PCS 7 Advanced Process Library (APL) or the predecessor Standard Library. Each placed block becomes an FB instance in the generated S7 program.
• SFC charts (Sequential Function Chart) — graphical state/transition diagrams for batch and procedural sequences (similar to IEC 61131-3 SFC).
• SCL sources — used for derived block types and complex calculations, compiled alongside the charts.

Instead of writing "Motor_Start FB" and "Motor_Stop FB" by hand, the engineer drops a CTRL_PID, MOT_SPEED, or VALVE_ANA block from the library onto a CFC chart, wires its inputs and outputs, and assigns it to an OB35 cyclic execution group. The compiler generates the FB, the instance DB, the OB1 wiring, and the corresponding WinCC faceplate from a single graphical action.

Organization Blocks: OB1 vs OB3x

A common point of confusion is whether OB1 exists in a PCS 7 controller. The answer is yes — OB1 (and a full set of error, startup, and interrupt OBs) is always present in the S7-400 firmware regardless of whether the project is a STEP 7 or PCS 7 program. What differs is how OB1 is populated.

STEP 7 Convention

In a STEP 7 project the engineer typically places explicit FB/FC calls in OB1, the free cyclic OB. The OB1 calls drive the entire application, and additional cyclic OBs (OB32, OB35, OB38) handle time-deterministic secondary tasks. The execution model is "call from OB1, branch to FCs/FBs."

PCS 7 Convention

In a PCS 7 project the engineer does not intentionally call user blocks from OB1. Instead, every CFC chart is assigned to a run-time group that is bound to a cyclic OB — usually OB35 (default 1000 ms) for continuous control, OB32 for faster control, OB34/OB36 for very fast control loops, and OB38 for special-purpose computation. The PCS 7 compiler generates the OB1 body automatically to invoke the run-time groups in the correct order, and the engineer never edits that body.

The result is a deterministic, time-sliced execution model that is easier to certify for process-control applications and easier to expand without manually rewiring OB1.

Block Library Scope: APL, Standard Library, and User Blocks

PCS 7 ships with two principal control libraries:

• APL — Advanced Process Library (V8.0 and later). A unified, state-based, certified library of motor, valve, PID, dosing, and interlocking blocks. Each block contains standardized operator faceplates, message configuration, and simulation support.
• PCS 7 Standard Library (V7.x and earlier). The predecessor library with separate block families for motor (MOT), valve (VLV), PID (CTRL), and so on, with corresponding faceplates.

STEP 7 ships only the IEC 61131-3 standard library and Siemens system blocks (SFB 0–SFB 255 for IEC timers, counters, PID, and communication). A STEP 7 engineer who wants a "motor block" must build the FB by hand, including HMI tags, alarms, and interlocks. A PCS 7 engineer drops MOT_SPEED or MOT_SLOWD from the APL and the faceplate, alarm, and interlock logic are inherited.

HMI / SCADA Integration: WinCC in STEP 7 vs PCS 7

The WinCC tie-in is the single biggest productivity differentiator between the two environments.

STEP 7 + WinCC (Flexible / TIA / Classic)

In a STEP 7 project, WinCC tags are added to the HMI project manually, with each tag pointing to a specific DB address, input/output, or bit in the controller. Screens are drawn with the WinCC graphics designer; alarm messages are typed by hand with reference to SFB 33 / SFB 34 / SFB 35 bits in the program. The mapping between program logic and operator faceplate is a hand-maintained contract.

PCS 7 + WinCC

In a PCS 7 project, the engineer does not create WinCC tags directly. Instead, when a CFC chart is compiled, the PCS 7 "OS-Compiler" generates:

• WinCC tags for every visible block I/O.
• Alarm messages with severity, class, and acknowledgement strategy pre-defined per block type.
• Operator faceplates with standard operating, override, and simulation views.
• Trend and archive configuration linked to APL block inputs.

The result is that every motor, every valve, every PID loop added to the CFC charts automatically appears in the WinCC operator screens at compile time. This eliminates the largest source of inconsistency in large process plants — program/HMI drift — and is one of the strongest arguments for PCS 7 in brownfield and greenfield plant projects above a certain scale.

System Architecture: Automation Stations, Operator Stations, and Engineering Station

A PCS 7 project is organized into a fixed set of station types, each of which is a real node on the plant network:

• AS — Automation Station. One or more S7-400 CPUs (often CPU 410-5H for redundancy) plus ET 200 remote I/O. Runs the compiled CFC/SFC user program and exchanges process data with the OS.
• OS — Operator Station (and OS Server / OS Client). A WinCC PC pair that displays process graphics, handles operator input, archives alarms and trends, and routes historical data. Multiple OS servers in a redundant client-server configuration is the standard PCS 7 deployment pattern.
• ES — Engineering Station. The CFC/SFC/SCL and WinCC development workstation; typically not used for live control.
• Maintenance Station (MS). Optional PCS 7 add-on for asset-management and diagnostic screens for intelligent field devices (Siemens SIPART, SITRANS, SIMOCODE, etc.).
• BATCH Station. Optional PCS 7 BATCH add-on for ISA-88 batch recipe execution.
• Route Control Station. Optional add-on for material routing on conveyor or pipeline networks.

A STEP 7 project has no formal station taxonomy. The engineer can build any architecture, but is responsible for hand-configuring the HMI/PLC data exchange, the network topology, and the OS redundancy model. In effect, PCS 7 imposes a discipline on the plant network that STEP 7 leaves to the integrator.

Compilation and Code Generation: Two-Stage Build

The PCS 7 build process is a two-stage compilation that has no STEP 7 equivalent:

1. S7 Compile. CFC/SFC/SCL charts are compiled into the underlying STEP 7 program — FBs, FCs, DBs, OB1, OB3x wiring, system data, and HW Config are regenerated from the high-level charts.
2. OS Compile. The compiled S7 program is analyzed to discover block I/O, message configuration, and chart hierarchy; WinCC tags, alarms, screens, and archives are generated for every operator station.

This is the reason that a PCS 7 engineer can hand the program to a junior engineer with minimal hand-holding: the high-level charts are self-documenting, and the generated code is not edited by hand. A STEP 7 program, by contrast, requires the original author to explain how the FBs were structured and how WinCC tags are bound to data blocks.

Application Scale and Use Case

Licensing, Toolchain, and Lifecycle

PCS 7 carries a separate, higher-cost engineering license than STEP 7. The PCS 7 toolchain includes the SIMATIC Manager (or, in V9.0 SPx and later, the PCS 7 Engineering Toolset on the TIA Portal framework), the PCS 7 Library, the OS-Compiler, and the WinCC option set. Runtime licenses are sold per AS, per OS Server, and per OS Client, with model-based and tag-based options.

STEP 7 (or STEP 7 Professional in the TIA Portal) is a single engineering license per developer seat, with a one-time cost for the runtime license on the S7-400 (which is included in the CPU firmware for most modern S7-400 CPUs). For small machines, STEP 7 is dramatically cheaper to deploy.

From a lifecycle perspective, PCS 7 is version-coupled to specific S7-400 firmware versions and specific APL/Standard Library releases; upgrades typically follow a controlled migration plan, especially when the plant is in a validated or GMP-regulated environment. STEP 7 programs are generally easier to lift onto newer CPUs (for example, the CPU 410-5H replacing a CPU 417-4) but the engineer owns the migration effort.

Common Misconceptions

A few points that are frequently misunderstood in the field:

• "PCS 7 is a different PLC." False. PCS 7 always runs on an S7-400 (or S7-400H) CPU. The same CPU can host either a STEP 7 or a PCS 7 program; the choice is made at engineering time.
• "PCS 7 does not use OB1." False. OB1 is present and is automatically populated by the PCS 7 compiler. The engineer is not expected to edit it.
• "Ladder is forbidden in PCS 7." False in principle. SCL-derived FBs and standard FBs in LAD/FBD can be used, but the prevailing convention is CFC/SFC for control logic. Pure LAD is unusual in a modern PCS 7 program.
• "STEP 7 is obsolete." False. STEP 7 remains the standard engineering tool for the S7-1500 family (via TIA Portal STEP 7 Professional) and for S7-300/400 machine-level work. The two toolchains coexist.

Decision Matrix: Choosing Between PCS 7 and STEP 7

Commissioning and Field-Proven Caveats

Several field-tested notes from experienced PCS 7 and STEP 7 engineers are worth recording:

• Run-time group load. In PCS 7, every CFC chart belongs to a run-time group. If a run-time group is overloaded (CPU execution time exceeds the OB time slice), the system logs a "OB1 request error" or a "run-time group overrun" in the diagnostic buffer of the CPU. Symptom: slow operator response or stale values on faceplates.
• OS compilation delta. A partial OS compile can leave stale WinCC tags in the OS database. Always do a full OS compile before commissioning, and always re-transfer the OS project to the runtime OS server(s).
• CEMAT exception. When modifying CEMAT-based plants, be prepared to see OB1 populated and to debug call chains directly in OB1, which is unusual in a non-CEMAT PCS 7 program.
• Block consistency check. After replacing a CPU or upgrading the PCS 7 library version, run the "Check Block Consistency" function and recompile the entire program before downloading to the AS. This avoids runtime errors from block-interface mismatches.
• Licensing model. PCS 7 AS runtime is licensed per AS and per the number of process objects (PO). A PO is roughly equivalent to one APL block instance. Under-licensing will result in the OS refusing to go online or limiting the number of operator-controllable objects.

Frequently Asked Questions