SD-PLC
A vendor-neutral PLC compiler and runtime, architecturally aligned with IEC 61131-3 and OPC UA.
SD-PLC compiles the control logic engineers already write — structured text, ladder, function block — into a portable runtime that deploys as a single cross-architecture binary. The point is architectural freedom: control code you can test in software, review like any other engineering artifact, and move between targets without rewriting it for another vendor IDE.
The lock-in is in the toolchain, not the hardware
Industrial control is bought as hardware, but what you are really buying is a toolchain. The logic is authored in one vendor IDE, stored in that IDE project format, compiled by that IDE compiler, and runs only on that vendor controllers. The moment you want to change supplier, test off-rig, put the logic under version control, or simply read a diff, you discover the control code was never really yours to move.
That is a business risk long before it is a technical one. Support windows end, part numbers go obsolete, licensing changes, and the one engineer who knew the project file leaves. The plant still has to run.
What it does
The programming model you already use
Built around IEC 61131-3 — structured text, ladder, and function block. This is not a new language to learn or a DSL to migrate to; it targets the model controls engineers are already trained in and already writing.
Compiles to one portable binary
Logic compiles to a runtime that deploys as a single cross-architecture binary. No vendor IDE on the target, no runtime licence per seat, no per-controller toolchain install.
Testable before it touches a machine
Because the runtime is ordinary software, the logic can be exercised in software first and then hardware-in-the-loop — so faults surface at a desk instead of on a live rig.
Interoperable by information model
Modeled on the OPC UA information model, so process data is exposed in a shape other systems can actually consume, rather than trapped behind a proprietary tag database.
Version-controllable like real code
Plain-text source, meaningful diffs, branches, code review, and CI. Control logic becomes an engineering artifact with a history, not a binary blob on a laptop.
Vendor-neutral by construction
Neutrality is an architectural property here, not a marketing position: nothing in the compiler or runtime assumes a specific manufacturer hardware platform, IDE, or licence server.
Front to back
- 01
Author
Standard IEC 61131-3 logic — structured text, ladder, function block — in plain text, in your own editor and repository.
- 02
Compile
The SD-PLC compiler lowers that logic to a portable intermediate form, checking it up front rather than at commissioning.
- 03
Validate
Run the compiled logic against a software model of the plant, then hardware-in-the-loop, before it drives anything real.
- 04
Deploy
Ship a single cross-architecture binary to the target. The same artifact you tested is the artifact that runs.
Where SD-PLC is today
SD-PLC is active engineering work, not a shipping commercial product. Here is an honest read of what stands up right now, so you can judge it on its actual state.
-
IEC 61131-3 front end
In progressStructured text first, with ladder and function block following the same lowering path.
-
Portable runtime
In progressSingle-binary runtime targeting multiple architectures from one compiled artifact.
-
Software-first validation
WorkingThe workflow proven on the flotation-tank thesis: model the plant, validate the controller in software before hardware.
-
Hardware-in-the-loop on Modicon M241
In progressExtending validation onto real industrial hardware. Results published as they land.
-
OPC UA information model
PlannedExposing process data in an interoperable shape rather than a proprietary tag database.
-
Assessed conformance
PlannedNo accredited assessment has been sought or granted. See the standards note above.
Who this is for
A good fit
- Teams carrying a long-lived plant whose controller platform is heading for obsolescence
- Engineering groups that want control logic under version control and code review
- Operations where off-rig testing would remove real commissioning risk
- Anyone evaluating whether vendor-neutral control is architecturally realistic for them
Not yet a fit
- Projects that require assessed conformance to PLCopen, O-PAS, or a similar body
- Safety-instrumented functions requiring a certified safety PLC
- Drop-in replacement of a running production controller today
Straight answers
Is this a replacement for my existing PLCs?
Not today, and the honest answer matters more than an ambitious one. SD-PLC is at the stage where it is worth evaluating architecturally — as the direction your control estate could move — rather than swapped into a running production line.
Do my engineers have to learn a new language?
No. That is the design constraint. SD-PLC targets IEC 61131-3 — the structured text, ladder, and function block your team already writes — rather than asking controls engineers to become general-purpose software developers.
What does "architecturally aligned" mean, exactly?
It means SD-PLC is built to the IEC 61131-3 programming model and the OPC UA information model, and designed against them deliberately — but that no accredited body has assessed or certified it. Those are not the same thing, and this site will not blur them.
Where can I see the engineering behind it?
The flotation-tank control system is written up in full on the case studies page — it is the thesis work that grounds the software-first validation approach SD-PLC is built around. The portfolio page covers the wider body of work.
Assessing whether vendor-neutral control is realistic for you?
That is a conversation worth having properly, with your actual constraints on the table — platform, obsolescence horizon, and what off-rig testing would be worth. Nothing on this site takes payment: we scope the problem first.