Control logic that outlives
the vendor who sold you the hardware.
A vendor-neutral PLC compiler and runtime, architecturally aligned with IEC 61131-3 and OPC UA.
- Programming model
- IEC 61131-3
- Data model
- OPC UA
- Deploys as
- One portable binary
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 SD-PLC does about it
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 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.
Author, compile, validate, deploy
- 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.
Proof, not promises
Two ways in, depending on how much detail you want: the long-form engineering write-ups, or the wider body of project work at a glance.
Case studies
The flotation-tank control thesis in full — plant model, controller design, and software-first validation. This is the work SD-PLC grew out of.
Read the write-ups → At a glancePortfolio
The wider set of projects — control systems, embedded work, and software delivery — with the stack and role on each.
Browse the portfolio →A person of the strings
In the Dholuo language of East Africa, a Jawaya is a musician — literally, “a person of the strings,” celebrating the artists who mastered physical wires to create harmony.
We co-opted the name for embedded and systems engineering because modern hardware demands that same precise artistry. Today the strings we play are the circuits, bare wires, and low-level code that connect hardware to intelligence — the foundational software that lets physical components communicate with absolute reliability.
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.