Lessons from DEPLOYment

This paper reviews the major lessons learnt during two significant pilot projects by Bosch Research during the DEPLOY project. Principally, the use of a single formalism, even when it comes together with a rigorous refinement methodology like Event-B, cannot offer a complete solution. Unfortunately (but not unexpectedly), we cannot offer a panacea to cover every phase from requirements to code; in fact any specific formalism or language (or tool) should be used only where and when it is really suitable and not necessarily (and somehow forcibly) over the entire lifecycle.

💡 Research Summary

The paper presents a reflective account of two pilot projects carried out under the DEPLOY (Development of Embedded Platforms by Leveraging Formal Methods) initiative by Bosch Research. The first pilot involved the development of an automotive electronic control unit (ECU), while the second focused on a smart‑factory production‑line monitoring system. Both pilots were used as testbeds for applying Event‑B, a state‑based formal method equipped with a rigorous refinement calculus, throughout the entire software development lifecycle—from requirements capture to code generation and verification.

In the requirements phase, the team attempted to translate natural‑language specifications into Event‑B contexts, variables, and events. This translation required close collaboration between domain experts and formal‑methods specialists, and it quickly revealed that Event‑B’s native notation struggles with time‑critical constraints and continuous physical phenomena. To compensate, the researchers introduced auxiliary timing constructs or coupled Event‑B models with external simulation tools, thereby increasing model complexity.

During refinement, the initial abstract models were incrementally concretised, and proof obligations were dispatched to automated provers (Rodin, ProB). For small models, the provers succeeded automatically, but as the system grew, state‑space explosion caused a sharp rise in proof failures. The team resorted to manual proof assistance and model decomposition, which introduced schedule overruns and required expertise beyond the reach of most developers. The proofs were predominantly mathematical in nature, creating a communication barrier that hindered knowledge transfer and long‑term maintenance.

Code generation from the refined Event‑B models produced C and assembly code that satisfied functional correctness checks. However, performance‑critical sections—such as low‑power mode transitions, interrupt handling, and hardware‑specific optimizations—could not be fully addressed by the generated code and demanded manual intervention. This highlighted the limited reach of formal‑method‑driven code synthesis in real‑time embedded contexts.

Verification combined model checking (via ProB) with runtime monitoring. Model checking efficiently uncovered abstract design flaws, but hardware‑interface bugs only manifested during runtime monitoring. The dual‑layer verification strategy demonstrated that a single formal technique cannot guarantee end‑to‑end assurance; complementary techniques are essential to bridge the gap between abstract models and concrete implementations.

From these experiences, the authors distilled several key lessons:

1. No single formalism suffices for the whole lifecycle. Event‑B excels at requirements and design, but its benefits diminish during implementation and deployment.
2. Tool‑chain scalability is a practical concern. Automated provers and model checkers hit performance limits on large industrial models, necessitating model partitioning and a balanced mix of automatic and manual proof efforts.
3. Domain‑specific constraints demand specialised notations. Timing, continuous dynamics, and low‑level hardware concerns are awkward to express in pure Event‑B, suggesting the use of complementary formalisms (e.g., TLA+, hybrid automata) where appropriate.
4. Traceability between models and code must be established early. Maintaining a bidirectional mapping enables impact analysis, regression checking, and smoother evolution of the system.
5. Hybrid, phase‑targeted adoption is optimal. The authors recommend employing lightweight, natural‑language‑linked models for early requirements, augmenting them with Event‑B or similar refinement techniques during design, and relying on conventional testing, static analysis, and runtime monitoring for the final implementation stage.

In conclusion, the DEPLOY pilots demonstrate that formal methods can add substantial value to industrial software engineering, but only when they are applied judiciously, in concert with other engineering practices, and with a clear strategy that matches each method to the phase and problem domain where it is most effective. This nuanced, “right‑tool‑for‑the‑right‑task” philosophy is presented as the central takeaway for practitioners seeking to integrate formal methods into real‑world development pipelines.