SFC alternative vs parallel branches: a worked batch sequence

Use a simultaneous branch when every path must become active; use an alternative branch when exactly one eligible path should become active. In the worked batch sequence below, heating and mixing begin together after LevelHigh, and the chart cannot advance until both completion conditions are true. Later, QualityOK selects release while NOT QualityOK selects rework; the two outcomes must never be active together.

Scope and terms before the sequence

IEC 61131-3:2025 Edition 4.0 defines SFC elements for structuring programs and function blocks. The standard page does not make a rendered chart into a validated control program: a controller project still supplies typed variables, task timing, action implementations, diagnostics, safety behavior, and a vendor-specific execution environment.

Four terms carry the example:

• A step represents an active phase. Its associated actions run according to their qualifiers.
• A transition is a Boolean condition between phases. It is evaluated only when its preceding step or branch state is eligible.
• A simultaneous branch—often called a parallel branch in vendor tools—uses double horizontal bars. When its entry transition fires, every first branch step becomes active.
• An alternative branch uses single horizontal bars. Its branch-entry transitions choose one path; it is an exclusive decision, not parallel work.

The visual distinction is small but the execution difference is large. Schneider Electric's Machine Expert documentation describes parallel branches as activating the first step in every branch, while alternative branches evaluate branch transitions from left to right and activate the first eligible path. CODESYS documents the same high-level distinction and separately publishes its processing order. Confirm the exact scan semantics in the target controller manual before implementation.

Worked inputs and assumptions

This teaching chart represents a fictional, nonhazardous batch. It assumes these Boolean signals have already been debounced, range-checked, and assigned by other reviewed logic:

Signal	Meaning in this example	Required behavior
StartCmd	operator or supervisory start request	one accepted request, not a safety permission
GuardsClosed	permissive summary	true before charging; not a substitute for a safety function
LevelHigh	charge target reached	stable before the simultaneous split fires
TempReady	heating branch completion	stays true until the convergence is accepted
MixTimeDone	mixing branch completion	stays true until the convergence is accepted
QualityOK	reviewed binary disposition	fresh for this batch; true means release, false means rework
TransferComplete	release path complete	acknowledged by the transfer sequence
ReworkAccepted	rework path complete	acknowledged by the rework sequence

The action associations shown are also abstractions. HoldOutputsSafe, InletValveOpen, and RequestQualitySample name requests to lower-level control logic. The heat, mix, release, and rework step implementations are intentionally omitted so the branch topology remains the review focus. Emergency stops, overtemperature trips, guard monitoring, motor protection, valve proof, fail-safe de-energization, and independent protection layers are outside this chart and must not depend on its drawing semantics.

Reproducible Schematex source

sfc "Batch release sequence"
step S_IDLE [initial]
  N HoldOutputsSafe
step S_CHARGE [label: "Charge vessel"]
  N InletValveOpen
transition from: S_IDLE to: S_CHARGE: StartCmd AND GuardsClosed

sim from: S_CHARGE: LevelHigh
  branch:
    step S_HEAT [label: "Heat batch"]
  branch:
    step S_MIX [label: "Mix batch"]
merge_to: S_SAMPLE: TempReady AND MixTimeDone

step S_SAMPLE [label: "Request sample"]
  P RequestQualitySample
alt from: S_SAMPLE:
  branch [priority: 1]:
    transition: QualityOK
    step S_RELEASE [label: "Release batch"]
    transition: TransferComplete
  branch [priority: 2]:
    transition: NOT QualityOK
    step S_REWORK [label: "Send to rework"]
    transition: ReworkAccepted
merge_to: S_COMPLETE

step S_COMPLETE [final]

This source returned valid with no diagnostics in Schematex 1.0.9 on August 17, 2026. The SFC syntax reference documents sim, alt, branch priorities, transition syntax, and action qualifiers. Schematex treats condition and action text as opaque strings: successful rendering proves that the diagram grammar and topology are accepted, not that the names exist in a PLC project or that the Boolean logic is safe.

Trace the simultaneous branch

Assume the controller begins with S_IDLE active. The N action HoldOutputsSafe is associated with that active step. When StartCmd AND GuardsClosed becomes true, S_IDLE deactivates and S_CHARGE activates. InletValveOpen remains requested while the charge step is active.

When LevelHigh is true, the double-bar divergence activates both S_HEAT and S_MIX. This is the first critical invariant:

active_after_LevelHigh = {S_HEAT, S_MIX}

Suppose TempReady = TRUE while MixTimeDone = FALSE. The convergence condition is:

TempReady AND MixTimeDone
= TRUE AND FALSE
= FALSE

The chart therefore remains inside the simultaneous region; S_SAMPLE must not activate. When both completion signals are true, the expression becomes TRUE AND TRUE = TRUE, and the convergence can activate S_SAMPLE. The double-bar merge is a rendezvous: one completed path does not allow the other path to be abandoned.

For implementation review, do not infer physical concurrency from the picture. A cyclic PLC task still executes instructions in a defined order. “Simultaneous” means both SFC paths are active over the same logical interval, subject to the target runtime's scan and action-order rules.

Trace the alternative branch

On entry to S_SAMPLE, the P qualifier requests RequestQualitySample for one PLC scan in the Schematex subset. The quality result must come from a separate, explicit handshake; a one-scan pulse is not evidence that sampling, analysis, or operator review finished.

The two branch-entry conditions are complements in this simplified two-state model:

QualityOK	Release condition	Rework condition	Selected branch
TRUE	TRUE	FALSE	S_RELEASE only
FALSE	FALSE	TRUE	S_REWORK only

That truth table establishes the second critical invariant:

active_disposition_steps ∈ {{S_RELEASE}, {S_REWORK}}
S_RELEASE AND S_REWORK = impossible by construction

Priority 1 is declared for release and priority 2 for rework in the source because several vendor runtimes evaluate eligible alternative transitions in a defined order. However, priority should not conceal overlapping conditions. If two branch conditions can both be true, document and test the intended winner; preferably rewrite them so exclusivity is visible. If neither can be true, the chart should remain at the decision step rather than silently invent an outcome.

This example deliberately omits an Unknown, Pending, or Invalid quality state. A production design should not encode missing or stale quality data as QualityOK = FALSE unless the requirements explicitly make that the approved fail-state behavior. A small enum and separate validated transition conditions are often clearer than one reused Boolean.

Checks that should survive every edit

Use these invariants as review cases or automated model tests:

1. Reset activates one initial step, S_IDLE.
2. LevelHigh activates both S_HEAT and S_MIX, never only one.
3. S_SAMPLE cannot activate while either TempReady or MixTimeDone is false.
4. Entering S_SAMPLE produces one RequestQualitySample pulse per activation under the selected runtime's qualifier semantics.
5. Exactly one of S_RELEASE and S_REWORK can activate for a fresh binary disposition.
6. TransferComplete cannot finish the rework path, and ReworkAccepted cannot finish the release path.
7. A held or stale completion bit is reset or transaction-scoped before the next batch.

A useful negative test is to change the simultaneous sim block into an alt block. The diagram may still look orderly, but only one of heat or mix would be selected. Conversely, changing the disposition alt into sim would request both release and rework. These are topology defects, not styling differences.

Failure modes and review boundary

The common defects are using a double bar for a mutually exclusive choice, using a single bar for work that must all complete, allowing overlapping alternative conditions without an explicit priority decision, advancing a convergence on only one completion signal, and reusing stale latched bits from the prior cycle. Another subtle defect is assigning physical outputs directly to SFC actions without a lower-level permissive and trip layer.

Schematex 1.0.9 is a deterministic drafting and review tool, not a PLC simulator, compiler, or safety validator. Its current SFC documentation describes an IEC 61131-3:2013-oriented subset, while the current IEC publication is IEC 61131-3:2025 Edition 4.0. The renderer does not type-check variables, execute transitions, prove mutual exclusion, or model task scheduling. One version-boundary check is visible in this artifact: 1.0.9 renders S_COMPLETE with a third inset border even though the public SFC page accessed August 17 still lists that treatment as deferred. Treat the mismatch as a reason to record the renderer version and inspect output, not as evidence of broader compliance.

For a real project, map this chart to the chosen vendor's SFC implementation, specify every signal's owner and reset behavior, trace at least the seven invariants above in a controller test environment, and have the controls and safety functions reviewed under the site's engineering process. Then paste the source into the Schematex playground to review topology changes before copying them into the controlled PLC project.