PCS 7 CFC Runtime Group Optimization: Best Practices Guide

Runtime group optimization in SIMATIC PCS 7 Continuous Function Chart (CFC) programming reorders blocks by topological signal flow so every producer executes before its consumer. The function typically slashes AS cycle time — field reports document a drop from 120 ms to 30 ms after a single pass on a 280-block chart — but it is a topological sort, not a semantic analyzer, and silently breaks any chart whose engineer deliberately relied on a previous-cycle value. This article explains the algorithm, the OB assignment model behind it, when the function is safe, when manual sequencing is mandatory, the online versus offline deployment paths, the per-group exclusion mechanism, the implications for PID sampling time selection, and the quality-control posture that prevents accidental "software delays" from surviving code review.

Reference: Siemens Industry Online Support for the SIMATIC PCS 7 CFC and APL manual set.

Runtime Group Architecture and OB Assignment

A runtime group is a named container for blocks that share an Organization Block (OB) cycle and an execution priority. In the SIMATIC Manager or TIA Portal-based PCS 7 engineering environment, the runtime editor displays the sequence of all blocks assigned to a CFC chart and lets the engineer drag blocks to reorder them. Each runtime group is bound to exactly one OB. The OB determines the cycle period and the priority class that the SIMATIC CPU scheduler applies when dispatching the group.

The block sequence inside the OB is the runtime group sequence. Blocks at the top of the sequence run first; their output values become visible to subsequent blocks within the same OB invocation through the CFC runtime. A block that reads a value written earlier in the same group sees the up-to-date value; a block that reads a value written in the previous OB cycle (because its producer runs after it in the sequence) sees the previous-cycle value. That single fact is the root cause of every "last cycle value" surprise that the optimizer can introduce.

Engineering implication: when a PID controller block (CTRL_PID from the PCS 7 APL) is bound to OB35, its SAMPLE_T input must match the OB35 period exactly. A mismatch causes either missed samples (SAMPLE_T > OB period) or repeated samples (SAMPLE_T < OB period), both of which destabilize the loop. See Siemens PCS 7 APL documentation.

Signal-Flow Reordering Algorithm

The Optimize Runtime Sequence function in the CFC editor runs a topological sort over the dependency graph of blocks in the runtime group. The dependency graph has one node per block and one directed edge from block A to block B whenever an output of A is connected to an input of B. The topological sort produces a linear order such that for every edge (A → B), A appears before B in the runtime group sequence.

The algorithm honors three classes of constraints beyond pure topological order:

1. Locked positions. A block whose position has been pinned by the engineer (lock icon in the runtime editor) stays at that position. The algorithm only fills the gaps between locked blocks.
2. Runtime group boundaries. The algorithm never moves a block across runtime group boundaries. Each runtime group is sorted independently.
3. Feedback loops. When two blocks depend on each other through a feedback path (an output of B feeding an input of A while A's output also feeds B), the algorithm emits a compile warning and preserves the engineer's existing order for that subchain, because no valid topological order exists for a true cycle.

The optimizer is invoked through the right-click context menu of the runtime group view or through the menu command "CFC > Optimize Runtime Sequence". The menu command offers a selection mode that lets the engineer drag a marquee around a subset of blocks and limit the reorder to that subset, leaving locked and untouched blocks in place.

The output of the optimizer is a new sequence list. If invoked online, the new list is written to the AS immediately and the next OB invocation runs the blocks in the new order; no CPU stop and no full program download are required. If invoked offline, the new sequence lives in the engineering database only; a compile and download step is required to push it to the AS.

Block Topology and Execution Order Rules

Three rules govern execution order inside a runtime group. They are independent of the optimizer and apply to every CFC chart ever written.

Rule 1 — Producer-before-consumer. If block B reads any input that is wired from block A's output, then A must appear before B in the sequence. Violation produces "previous-cycle" behavior that is sometimes intentional and sometimes a bug; the compiler cannot distinguish.

Rule 2 — Same-cycle visibility. Within one OB invocation, every output written by a block is visible to every block that runs later in the same group. There is no race, no read-before-write hazard, and no need for explicit synchronization primitives. This holds across blocks in the same runtime group and across runtime groups running in the same OB, provided the consuming block is later in the sequence.

Rule 3 — Cross-OB visibility is one-cycle delayed. A block bound to OB35 reading the output of a block bound to OB1 sees the value as of the previous OB1 invocation, because OB35 may run while OB1 is mid-cycle. The optimizer cannot fix this; the only fix is to put both blocks in the same OB.

When Automatic Optimization Works Well

The optimizer is safe and beneficial for charts whose block wiring forms a strict feed-forward graph. The defining property is: every block writes its outputs based only on its inputs, never on its own previous output or on a value computed in this same chart by a downstream block. The following categories all satisfy this property and may be optimized without risk to logic correctness:

• Pure combinational logic (valve command decoders, mode selectors)
• Feed-forward PID chains (setpoint → controller → valve)
• Motor start/stop interlocks with feedback through physical wiring only
• Alarm blocks with digital debounce and time-on-delay
• Totalizer and counter blocks driven by an upstream pulse source

A second safe case is closed-loop PID control where the loop is broken by the physical process: the controller output goes to a valve, the valve drives a flow, the flow measurement returns to the controller. The cycle-time delay through the physical process is orders of magnitude larger than one OB cycle, so the one-cycle delay added by reading the previous cycle's setpoint is negligible. Optimizing these charts is safe.

A third safe case is cascade control where the master and slave controllers sit in different runtime groups with appropriate OB periods. The optimizer is run on each group independently; cross-group dependencies are handled by the natural OB-to-OB delay, which is part of the cascade design.

When Manual Sequencing Is Required

The optimizer is unsafe when the engineer has deliberately placed a consumer before a producer to obtain the previous-cycle value. The classic pattern is a software delay built from two blocks: an integrator or running-average block (call it DLY_A) followed by a threshold detector (call it THR_B). The engineer wires the input to both blocks; THR_B reads the input directly, and DLY_A accumulates. THR_B's output drives a downstream alarm block (ALM_C). The intended logic is: "raise an alarm only after the input has been high for two consecutive cycles." If the runtime group sequence is ALM_C → THR_B → DLY_A, then ALM_C sees THR_B's output from the previous cycle (because THR_B ran after ALM_C), which gives the desired two-cycle delay. The optimizer, seeing that DLY_A's output feeds no consumer and THR_B feeds ALM_C, reorders to ALM_C → DLY_A → THR_B and breaks the alarm logic.

The fix is not to disable optimization globally. The fix is one of the following:

1. Mark the runtime group as "Do not optimize" in the runtime group properties dialog. The engineer retains full control of the sequence and the optimizer leaves the group untouched.
2. Lock the offending blocks in place using the pin icon in the runtime editor before invoking the optimizer. Locked blocks stay where they are; the optimizer only reorders blocks between the pins.
3. Restructure the chart to use the APL DLY (delay) block from the PCS 7 Advanced Process Library. The DLY block produces the previous-cycle value by design and does not rely on runtime group ordering. This is the recommended path because it makes the intent visible to the code reviewer.

Code review practices in plants that have banned manual sequence dependencies note that any chart caught in review with a consumer-before-producer ordering triggers a rejection, even if the chart passes the optimizer. The reasoning is that optimization is optional and may be re-run by a future engineer who is unaware of the implicit dependency; the resulting regression is hard to diagnose because the symptom is a transient alarm logic change.

Online vs Offline Optimization Procedure

The two deployment modes differ in where the new sequence is applied and what changes propagate to the running AS.

Online optimization

1. Open the CFC editor and navigate to the runtime group view.
2. Right-click the runtime group and choose "Optimize Runtime Sequence".
3. The editor computes the new sequence and applies it to the connected AS.
4. The next OB invocation runs the blocks in the new order.
5. The CPU does not stop. No download is required. Existing process values are preserved.

Offline optimization

1. Open the CFC editor offline (no online connection to the AS).
2. Right-click the runtime group and choose "Optimize Runtime Sequence".
3. The editor computes the new sequence and writes it to the engineering database.
4. Compile the program (S7 program > Compile).
5. Download the changes to the AS. PCS 7 supports online download of individual runtime groups without stopping the CPU when the changes are confined to the sequence list and to non-structural block parameter updates.
6. Verify on the AS that the new sequence matches the engineering database.

When to use which mode: online optimization is preferred for live plants where the engineer wants to verify the impact of the new sequence on the running process before committing to a download. Offline optimization is required when the change must be staged for a planned maintenance window or routed through a code review and approval workflow. Both modes produce the same final sequence; the difference is purely the deployment path. Reference: PCS 7 engineering and online download documentation at Siemens Industry Online Support.

Excluding Individual Runtime Groups from Optimization

The CFC editor lets the engineer mark a runtime group as excluded from optimization. The setting lives in the runtime group properties dialog, on the General or Options tab depending on the PCS 7 version. The flag is named "Do not optimize runtime sequence" or equivalent (the exact label varies across PCS 7 V8.x, V9.0, V9.1, and V10.0).

When the flag is set, the "Optimize Runtime Sequence" command operates on all other runtime groups in the chart but leaves the flagged group untouched. This is the right choice for groups that contain:

• Charts with deliberate last-cycle-value dependencies
• Charts that contain operator-face blocks whose sequence must match the operator's mental model (rare but documented)
• Charts whose sequence has been locked by a code review comment

When the flag is cleared, the group is included in the next optimization pass. The flag is per-group, not per-chart, so an engineer can mix optimized and hand-tuned groups in the same CFC. A useful project-wide convention is to set the flag during initial chart creation, run the optimizer once on the chart, then clear the flag and re-run to confirm no further change is produced — that final clear is the project standard for charts that may be optimized in the future.

Performance Impact and Cycle-Time Reduction

The performance impact of optimization is a function of the chart's average block size, the number of cross-block references, and the OB period. The biggest gains come from charts where many small blocks each call a few inputs from many other blocks, because the pre-optimization sequence forces the OB to re-execute blocks several times to settle dependencies. The optimizer eliminates that re-execution by linearizing the dependency graph.

The lab-sample example illustrates the boundary: charts that already have linear block topology see no benefit. The compressor example illustrates the cost of high cross-block density: even with only 90 blocks, three dependencies per block forces the OB to revisit blocks, and optimization cuts the revisits in half.

Cycle-time budget rule of thumb: keep the optimized cycle time below 50 % of the OB period. For OB35 at 1 s, the budget is 500 ms. For OB32 at 100 ms, the budget is 50 ms. The compressor example at 22 ms inside a 100 ms OB is healthy; the boiler example at 32 ms inside a 1 s OB is very healthy. As an order-of-magnitude check, the optimized AS cycle time Tcycle should satisfy Tcycle < 0.5 × OBperiod for the recommended budget, or Tcycle < 0.8 × OBperiod as a hard ceiling to avoid OB-time overruns that trip the OB80 (time error) diagnostic.

PID Sampling Time Selection and Process Classification

The Optimize Runtime Sequence function does not change the OB period, but it changes how the PID controller inside the OB behaves by determining whether the controller sees the current cycle's setpoint or the previous cycle's setpoint. The PID block (CTRL_PID from the PCS 7 APL) has an SAMPLE_T input that must match the OB period. A mismatch is the most common PID instability root cause after runtime group reordering.

Process classification drives the OB period and therefore the sampling time:

Rule of thumb for sampling time selection (reproduced in PCS 7 PID tuning guides): the sampling time should be between one-tenth and one-fifth of the dominant process time constant Tp. Slower than Tp/5 and the loop becomes sluggish; faster than Tp/10 and the integrator windup amplifies quantization noise.

The Optimize Runtime Sequence function helps the PID see the same-cycle setpoint and process variable, which makes the controller effectively deterministic with respect to the OB period. Without optimization, the controller may alternate between current-cycle and previous-cycle readings depending on where the producer block sits in the sequence, which introduces a one-cycle transport delay that is equivalent to halving the controller's effective gain. In practice this shows up as a loop that oscillates at half the expected frequency and a process variable that lags its setpoint by one extra OB period.

Quality Control and Project Standards

Most operating plants that maintain a PCS 7 quality program have explicit rules for runtime group ordering. The rules vary by site but converge on three principles.

First, every chart must have either a single signal-flow path (producer → consumer throughout) or an explicit set of DLY / accumulator blocks where previous-cycle values are needed. The chart's runtime group sequence is then either optimized automatically or hand-locked with the rationale documented in the chart comment.

Second, charts whose sequence is hand-locked must carry a comment in the chart header explaining the dependency. The comment is read by the next engineer during code review and is the only thing that prevents an inadvertent optimization pass from breaking the logic.

Third, the Optimize Runtime Sequence function is part of the standard commissioning checklist. The engineer optimizes all runtime groups at the end of chart creation, locks the exceptions, and attaches a "sequence report" to the chart that lists every runtime group, its lock state, and the OB period. The report is archived in the project documentation.

The penalty for violating these rules in operating plants is consistent: a code review rejection and a mandatory rework before the chart can be released. The reasoning is that runtime group ordering is invisible at the I/O level and only manifests as a transient logic error after the next optimization pass or chart migration. Project standards typically cite IEC 61131-3 as the underlying programming-language framework and the in-house PCS 7 engineering guideline as the project-specific enforcement layer.

Troubleshooting Matrix

Frequently Asked Questions