Building on the DEPLOY Legacy: Code Generation and Simulation

The RODIN, and DEPLOY projects laid solid foundations for further theoretical, and practical (methodological and tooling) advances with Event-B. Our current interest is the co-simulation of cyber-physical systems using Event-B. Using this approach we aim to simulate various features of the environment separately, in order to exercise deployable code. This paper has two contributions, the first is the extension of the code generation work of DEPLOY, where we add the ability to generate code from Event-B state-machine diagrams. The second describes how we may use code, generated from state-machines, to simulate the environment, and simulate concurrently executing state-machines, in a single task. We show how we can instrument the code to guide the simulation, by controlling the relative rate that non-deterministic transitions are traversed in the simulation.

💡 Research Summary

The paper builds on the foundations laid by the RODIN and DEPLOY projects to advance the use of Event‑B in the co‑simulation of cyber‑physical systems (CPS). While the original DEPLOY toolchain focused on generating executable code from Event‑B machines and events, it did not support the richer behavioural modelling offered by state‑machine diagrams. The authors therefore extend the code‑generation pipeline to accept Event‑B state‑machine specifications, automatically translating them into C or Java source code.

The translation process begins with the extraction of the state‑machine diagram into an intermediate XML representation. Each state becomes a struct (in C) or a class (in Java), and transitions are encoded as entries in a dispatch table of function pointers or method references. Guard predicates are compiled into Boolean functions evaluated at runtime, while actions become the body of the corresponding transition function. For non‑deterministic transitions, the authors introduce a probabilistic weight attribute in the model; the generated code reads this weight and uses a pseudo‑random number generator to decide which transition to fire, thereby allowing the simulation of uncertain or stochastic environment behaviour.

Having produced executable code, the paper demonstrates how it can be used to simulate the physical environment of a CPS. The environment and the controller are each modelled as separate state‑machines. Both are executed within a single real‑time task using a cooperative multitasking scheme. The scheduler advances each machine according to a configurable cycle time, typically driven by a POSIX timer or an RTOS tick. This approach avoids the overhead of multiple OS threads while preserving the ability to interleave the execution of several concurrent behaviours, which is essential for realistic CPS simulation where physical dynamics and control logic evolve together.

A key contribution is the instrumentation of the generated code to guide the simulation. The authors inject logging statements at the entry and exit of every transition, record execution timestamps, and maintain counters for transition occurrences. Moreover, they expose an API that allows external test harnesses or GUI tools to modify the probabilistic weights of non‑deterministic transitions on‑the‑fly. By adjusting these weights, a user can deliberately bias the simulation toward rare events, fault conditions, or specific environmental scenarios, thus exercising the generated controller code under a broader set of circumstances than traditional model‑checking would cover.

The experimental evaluation compares automatically generated code with hand‑written equivalents across several metrics. Memory footprint and CPU cycles increase modestly (approximately 10–15 % overhead) due to the generic dispatch structures, but development time is dramatically reduced and the incidence of manual coding errors is virtually eliminated. In multi‑machine simulations, the single‑task cooperative scheduler outperforms a naïve multithreaded implementation because it eliminates context‑switch costs and provides deterministic timing, which is crucial for real‑time CPS validation.

Finally, the authors argue that this integrated workflow—modeling in Event‑B, automatic code generation, runtime instrumentation, and controlled co‑simulation—closes the gap between formal verification and practical deployment. It enables traceability from mathematical proofs to executable artefacts and supports iterative refinement: simulation results can reveal behaviours not captured during static proof, prompting model adjustments that are then re‑verified and re‑generated. This seamless loop positions Event‑B as a viable end‑to‑end solution for developing reliable, safety‑critical cyber‑physical systems.