Notes from a Mutexer training
22 May 2026 · Thomas De Kelver
We spent a couple of days last week on Mutexer’s level-1 training [1]. The short version: Toggle is adding a new service line as a Mutexer system integrator. The longer version is below, with the parts we think actually matter for the pharma and broader manufacturing crowd, plus where this connects to the GxP validation work we have been doing in parallel.
This post reflects the state of the Mutexer platform documentation as of May 2026.
What Mutexer actually is
Mutexer markets itself as software-defined industrial automation. In practice the agent is a runtime that turns a standard Linux device into a controller. Drop the agent on Ubuntu or another Debian-based distribution and you can run vPLC, vHMI, SCADA, and MES applications on the same hardware, manage them from a cloud portal, and push updates over the air [1].
Three things from the platform are worth pulling out for an engineering audience.
PREEMPT_RT on Linux
PLCs dominate factory floors because of determinism. Guaranteed, repeatable cycle times. Until recently, that meant proprietary real-time operating systems on vendor hardware.
PREEMPT_RT was fully merged into the mainline Linux kernel in v6.12, released November 2024 [2]. It is no longer a fork or an out-of-tree patch set. Mutexer’s agent uses PREEMPT_RT to give sub-millisecond cycle times on Intel or ARM hardware you bought because of price or supply, not because the controls vendor told you to [1].
A caveat. PREEMPT_RT gives you a real-time kernel, but a real-time system is more than the kernel. Hardware, drivers, ISR latency, interrupt affinity, and the rest of the user-space stack all matter. The training covered this well, and Mutexer’s docs separate hard real-time from soft real-time without overclaiming.
Git-style version control, automatically
Mutexer ships its own version control. It is Git-adjacent (branches, snapshots, merges) with two design choices that change the picture. Every file operation is recorded automatically as a transaction. There is no staging step, no rebase, no force-push. The history is immutable [4].
For most software engineers this would feel restrictive. For a regulated environment, the picture flips. An automatically captured, tamper-evident change history is exactly what an auditor wants to see. The system removes a class of “did anyone forget to commit that hotfix” problems that we have all seen at site acceptance testing.
The part we find most interesting
The project code base is accessible to AI LLM agents. That opens up a workflow that has been technically possible for a while but practically painful: automated unit test generation against the control logic.
Unit testing PLC code is not a new idea. TcUnit has existed for Beckhoff TwinCAT 3 for years. It is an xUnit-style framework with type-specific assertion methods for IEC 61131-3 data types, and it integrates with CI pipelines like Jenkins [5].
What is new is the cost of getting from “we have no tests” to “we have a reasonable starting suite”. An LLM with read access to the codebase can draft test cases against function blocks and Program Organization Units (POUs) in minutes. For the Python side of a controls project (historian feeds, MES integration glue, alarm processing), there is also Pynguin, an academic-but-mature framework out of the University of Passau that does automated unit test generation for Python using algorithms like DynaMOSA and MOSA [6]. We have not put it into a regulated production pipeline yet, but it is on the shortlist to evaluate.
Generated tests are a starting point, not a deliverable. Every test that ends up in a validation pack needs a human review, a clear rationale, and revision control. Skipping that step is how you ship a test suite that passes for the wrong reasons.
Where this plugs into our GxP validation work
In parallel with the Mutexer work, we have been building a GxP validation platform that generates a full V-model lifecycle documentation set: URS, FS, DS, IQ, OQ, PQ, traceability matrix, the whole stack. It can optionally pull software unit test results in as part of the OQ evidence package.
The pattern we want for Mutexer-based projects is roughly:
The control logic lives in Mutexer’s version-controlled project. Unit tests are drafted with LLM assistance, then a human engineer reviews each test, signs off, and the test enters the revision-controlled test suite. The test runner produces results that the validation platform ingests automatically, attaching them to the relevant FS/DS items via the traceability matrix. The auditor sees a closed loop from requirement to implementation to test to evidence, without anyone having copy-pasted a screenshot into a Word document.
The human-in-the-loop step is the non-negotiable part. Generated tests that nobody read are worse than no tests. They create an illusion of coverage. The validation platform is set up so that test authorship and review are themselves recorded events, with the reviewer named.
What else we have been building
The validation platform sits alongside two other systems we have built on Mutexer:
A custom Environmental Monitoring System (EMS) for cleanroom-scale particulate and microbiological data, with the audit trail and electronic-signature handling required for GMP environments. And a custom Electronic Batch Record (EBR) system for clients whose batch size, recipe complexity, or change frequency makes off-the-shelf MES economics painful.
Both are currently in staging for internal testing.
If you want to dig in
If any of this is relevant to what you are building (a soft PLC pilot, a validation pipeline that does not collapse under change requests, an EMS or EBR that fits your process instead of the other way around), reach out. Easiest is the contact page on toggle-engineering.com or a LinkedIn message.
References
- mutexer Agent: Industrial Runtime for Linux Devices. Mutexer platform page. Retrieved May 2026. https://www.mutexer.com/os
- Linux Kernel 6.12 RC1 Released: PREEMPT_RT Mainlined and Sched_ext Merged. Linux Today, September 2024. https://www.linuxtoday.com/blog/linux-kernel-6-12-rc1-released-preempt_rt-mainlined-and-sched_ext-merged/ . See also Phoronix coverage at https://www.phoronix.com/news/Linux-6.12-Does-Real-Time .
- IEC 61131-3 Standard. Mutexer documentation. Retrieved May 2026. https://docs.mutexer.com/v1/key-concepts/iec-61131-3.html
- Moving from Git. Mutexer documentation, version control section. Retrieved May 2026. https://docs.mutexer.com/v1/version-control/moving-from-git.html
- TcUnit: An unit testing framework for Beckhoff’s TwinCAT 3. Project site and GitHub. https://tcunit.org/ and https://github.com/tcunit/TcUnit
- Pynguin: Automated Unit Test Generation for Python. Project site, University of Passau. https://www.pynguin.eu/ and https://github.com/se2p/pynguin