FTOS-Verify: Analysis and Verification of Non-Functional Properties for Fault-Tolerant Systems

The focus of the tool FTOS is to alleviate designers’ burden by offering code generation for non-functional aspects including fault-tolerance mechanisms. One crucial aspect in this context is to ensure that user-selected mechanisms for the system model are sufficient to resist faults as specified in the underlying fault hypothesis. In this paper, formal approaches in verification are proposed to assist the claim. We first raise the precision of FTOS into pure mathematical constructs, and formulate the deterministic assumption, which is necessary as an extension of Giotto-like systems (e.g., FTOS) to equip with fault-tolerance abilities. We show that local properties of a system with the deterministic assumption will be preserved in a modified synchronous system used as the verification model. This enables the use of techniques known from hardware verification. As for implementation, we develop a prototype tool called FTOS-Verify, deploy it as an Eclipse add-on for FTOS, and conduct several case studies.

💡 Research Summary

FTOS‑Verify addresses a critical gap in model‑based design for fault‑tolerant embedded systems: the lack of formal verification for the non‑functional properties introduced by user‑selected fault‑tolerance mechanisms. The authors first formalize the FTOS modeling language as a set of mathematical constructs—states, events, timing constraints, transition functions, and fault hypotheses. On top of this foundation they introduce the “deterministic assumption,” which requires that identical inputs and schedules always produce identical outputs. This assumption is a natural extension of Giotto‑style time‑triggered systems and is essential for guaranteeing that local properties of the original asynchronous, distributed system are preserved when the system is transformed into a synchronous verification model.

Two key theorems are proved. The first shows that, under the deterministic assumption, a system’s local safety or liveness properties remain invariant after mapping to a globally synchronized model. The second demonstrates that fault scenarios defined by the fault hypothesis can be faithfully represented in the synchronous model, allowing existing hardware verification engines (model checkers, SAT/SMT solvers) to be reused without modification. Consequently, designers can automatically generate a verification model from an FTOS specification and apply mature verification tools to prove that the selected fault‑tolerance mechanisms indeed satisfy the intended resilience requirements.

Implementation-wise, FTOS‑Verify is delivered as an Eclipse plug‑in that integrates directly with the FTOS development environment. Users model their system architecture, annotate components with fault‑tolerance strategies (replication, checkpointing, restart, etc.), and specify a fault hypothesis. When the “Verify” command is invoked, the plug‑in parses the model, checks the deterministic assumption, performs the synchronous transformation, and emits a model in the input language of the chosen verification engine (e.g., NuSMV, UPPAAL, CBMC). The user also supplies temporal logic properties describing the desired non‑functional behavior, such as “the control command is delivered within 10 ms in all normal scenarios” or “after any sensor fault the replicated controller remains operational for at least two consecutive cycles.” The verification results are presented within the Eclipse UI, highlighting any counter‑examples for rapid debugging.

The paper validates the approach with three case studies. In an automotive ECU scenario, a replicated control loop is shown to recover within 5 ms after a sensor fault, as proved by model checking. In an avionics flight‑control example, checkpoint‑based recovery guarantees that the system always returns to a consistent state after a memory error. In an industrial robot case, a restart mechanism is verified to maintain safe operation even under simultaneous sensor and communication faults. Verification times range from a few seconds to a few minutes, demonstrating that the approach is practical for real‑world design cycles.

Key contributions include: (1) a rigorous mathematical semantics for FTOS models and fault‑tolerance annotations; (2) the deterministic assumption that bridges asynchronous, time‑triggered designs with synchronous verification techniques; (3) a toolchain that reuses existing hardware verification infrastructure, reducing development cost; and (4) an Eclipse‑based user experience that fits naturally into the existing FTOS workflow.

Limitations are acknowledged. The deterministic assumption does not hold for systems with dynamic scheduling, pre‑emptive priorities, or nondeterministic communication delays, requiring further abstraction or extensions. Moreover, large‑scale systems with complex fault hypotheses may still suffer from state‑space explosion, suggesting future work on compositional verification and abstraction refinement.

In summary, FTOS‑Verify provides a compelling integration of model‑based code generation and formal verification for fault‑tolerant systems, enabling designers to certify that their chosen fault‑tolerance mechanisms meet the specified resilience criteria early in the development process. Future research will focus on relaxing the deterministic assumption and scaling the approach to more dynamic, large‑scale embedded platforms.