Not everything in a sequence has to happen one step at a time. Often several independent activities should run at once, such as purging one system while pre-lubricating another, and only when all of them are finished should the sequence move on. A simultaneous branch is the sequential-chart construct that expresses exactly this: a single transition splits the flow into several parallel paths that all become active together, run concurrently, and then rejoin at a synchronization point that waits for every path to complete. It is how a sequence does several things in parallel without losing the discipline of knowing when they are all done.
Simultaneous branch in an SFC in one line: A simultaneous branch, also called a parallel branch, is a sequential-chart construct where one transition activates several step chains at the same time so they run concurrently. It is drawn with a double horizontal line at the split, called the divergence, and another double line at the join, called the convergence. All of the parallel paths run independently, and the sequence only advances past the convergence once every branch has reached its end, which synchronizes them back together.
A simultaneous branch has three parts. The divergence is where the flow splits: a single transition sits above a double horizontal line, and when that transition fires, every path below the line becomes active at once. This is the key contrast with a selection branch, where the sequence chooses one path among several; in a simultaneous branch there is no choosing, because all the paths are taken together. The double line is the drawing convention that signals this parallel, take-all behavior, as opposed to the single line used for a choice.
Between the divergence and the convergence, each path is an ordinary chain of steps and transitions that runs on its own. The paths are genuinely concurrent: each advances through its own steps according to its own transition conditions, independently of how far the others have progressed. One branch might have three quick steps and finish early while another has a single long step still running, and that is perfectly normal. Each branch minds its own business, carrying out its part of the work at its own pace, with no coordination between them until the very end.
The convergence is where the paths come back together, drawn as another double horizontal line with a single transition below it. This is the synchronization point, and it enforces the rule that gives the construct its purpose: the sequence cannot pass the convergence until every parallel branch has reached its final step and the convergence transition condition is true. A branch that finishes early simply waits at its end for the others to catch up. Only when all branches are complete does the flow merge back into a single path and continue. The convergence is, in effect, a barrier that no branch crosses alone.
The synchronizing behavior at the convergence is the whole reason to use a simultaneous branch rather than just launching some background logic. The construct guarantees that when the sequence moves past the join, every one of the parallel activities is genuinely finished, not merely started. This gives you a clean, provable point in the sequence where you know a whole set of concurrent tasks has completed. Without that barrier, you would have to hand-write logic that tracks each parallel activity and checks that they have all finished, which is exactly the error-prone bookkeeping the construct removes.
This matters most when the next stage of the sequence depends on all of the parallel work being done. If the step after the convergence assumes that both a purge and a pre-lube have completed, then it is only safe to run once both are actually complete, and the convergence enforces precisely that. A branch that races ahead is held at the join, so there is no way for the sequence to proceed with one task still in progress. The construct turns must all be finished before continuing from a fragile assumption into a structural guarantee of the chart.
It is worth being clear about what the convergence does and does not do. It synchronizes completion, meaning it waits for every branch to reach its end, but it does not force the branches to march in lockstep along the way; they still run at their own paces internally. It also introduces the one real hazard of the construct: if any single branch cannot complete, perhaps because one of its transition conditions never clears, the entire convergence stalls and the whole sequence hangs, because the barrier is waiting for a branch that will never arrive. Designing each branch so it can always reach its end, or providing a fault path, is therefore part of using simultaneous branches safely.
A common plant use is running several independent preparation activities in parallel before a machine is allowed to start. Imagine a compressor startup where, at a single divergence, the sequence launches a purge branch that clears the casing and a pre-lube branch that brings the oil system up to pressure, both at the same time. The two activities have nothing to do with each other and there is no reason to do them one after the other, so running them concurrently shortens the startup. Each branch works through its own steps: the purge branch times or proves its purge, and the pre-lube branch runs the pump and confirms pressure.
The convergence is what makes this safe. The step that actually starts the machine sits below the join, so it cannot run until both the purge branch and the pre-lube branch have reached their ends, meaning the casing is proven purged and the oil system is proven up. If the pre-lube finishes first, it waits at its end for the purge to complete, and vice versa. The machine start therefore only happens when both preconditions are truly satisfied, which is exactly the guarantee you want and exactly what the simultaneous branch provides without any extra hand-written coordination.
For SCADA and remote operations, the parallel structure is genuinely useful to display, because it lets a remote operator see multiple concurrent activities and their individual progress at once. A dashboard can show the purge branch and the pre-lube branch side by side, each with its own active step, so a supervisor watching from a distance can tell that both preparations are underway and how far each has got. When the sequence stalls at the convergence, the parallel view makes the culprit obvious: the operator can see which branch is still not at its end and therefore which condition is holding up the join, rather than facing a single opaque not ready. The construct that keeps the logic honest also makes concurrent work legible from anywhere.
A selection branch chooses exactly one path among several based on which transition condition is true, so only one branch runs. A simultaneous branch takes all paths at once, activating every branch when the single divergence transition fires, so they run concurrently. The two are drawn differently: a single horizontal line marks a selection, while a double horizontal line marks a simultaneous, take-all branch.
The double horizontal line is the drawing convention for a simultaneous branch. At the divergence it marks the point where one transition activates several parallel paths at once, and at the convergence it marks the synchronization point where those paths rejoin. It distinguishes parallel, take-all behavior from the single line used for a selection branch, where only one path is chosen.
The convergence stalls and the whole sequence hangs, because the join is a barrier that waits for every branch to reach its end, and it will keep waiting for a branch that never arrives. That is the main hazard of the construct, so each branch should be designed so it can always reach its end, or a fault path should be provided that detects a branch stuck too long and moves the sequence to a safe state instead of hanging forever.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.