Formalizing Safety Requirements Using Controlling Automata

Safety is an important element of dependability. It is defined as the absence of accidents. Most accidents involving software-intensive systems have been system accidents, which are caused by unsafe inter-system or inter-component interactions. To validate the absence of system hazards concerning dysfunctional interactions, industrials call for approaches of modeling system safety requirements and interaction constraints among components. This paper proposes such a formalism, namely interface control systems (or shortly C-Systems). An interface C-System is composed of an interface automaton and a controlling automaton, which formalizes safe interactions and restricts system behavior at the meta level. This framework differs from the framework of traditional model checking. It explicitly separates the tasks of product engineers and safety engineers, and provides a top-down technique for modeling a system with safety constraints, and for automatically composing a safe system that conforms to safety requirements. The contributions of this work include formalizing safety requirements and a way of automatically ensuring system safety.

💡 Research Summary

The paper addresses a fundamental source of accidents in software‑intensive systems: unsafe interactions between components or subsystems, often referred to as “system accidents.” Traditional verification techniques, such as model checking, treat safety as a property to be verified after a functional model has been built. This post‑hoc approach suffers from state‑space explosion and becomes costly when safety requirements evolve. To overcome these limitations, the authors introduce a novel formalism called a C‑System (Interface Control System), which couples an Interface Automaton (IA) with a Controlling Automaton (CA).

The IA captures the functional behavior of a component: its input and output events, internal states, and transition relations. It is essentially a standard automaton specialized for modeling component interfaces, supporting concurrency and asynchronous communication. The CA, on the other hand, lives at a meta‑level. It does not describe functional behavior directly; instead, it encodes safety constraints as a set of admissible transitions. A transition is admissible only if the pair (pre‑state, event, post‑state) satisfies the CA’s rules. In this way, the CA can forbid dangerous state combinations, not merely filter individual events.

The two automata are composed through a synchronous product operation. The resulting composite automaton inherits all possible behaviors of the IA, but any transition that violates the CA’s constraints is eliminated, rendering it unreachable. Consequently, the C‑System enforces safety requirements during system synthesis rather than after the fact. This separation of concerns allows safety engineers to focus on writing CA specifications while product engineers concentrate on functional IA models.

Key contributions of the work include:

1. Formalization of safety requirements as a controlling automaton. By elevating safety constraints to a first‑class automaton, the approach provides a precise, mathematically rigorous representation that can be analyzed with existing automata theory tools.

2. Top‑down, model‑driven safety enforcement. The CA’s meta‑level restrictions are applied during the composition of IA and CA, eliminating unsafe behaviors before any execution or simulation takes place.

3. Automatic synthesis of a safe system. The composition algorithm requires only the synchronous product of IA and CA; no exhaustive state‑space exploration or external model‑checking pass is needed, dramatically reducing computational overhead.

4. Clear role separation. Safety engineers can modify CA independently of IA, enabling rapid adaptation to changing regulations or newly discovered hazards without re‑engineering the functional model.

The authors discuss implementation aspects, noting that CA specifications can be expressed as regular languages and thus automatically translated into automata using standard compiler‑like pipelines. Integration with existing verification environments (e.g., UPPAAL, SPIN) is straightforward because the final C‑System is itself an automaton amenable to those tools.

A case study demonstrates the practical impact. In a traditional control system, a particular sequence of concurrent inputs could drive the system into an unsafe state. By adding a CA that explicitly forbids the offending transition pattern, the composite C‑System no longer permits the hazardous path, while all legitimate control actions remain functional. This illustrates that safety can be strengthened without sacrificing intended behavior—a common challenge in safety‑critical design.

In summary, the C‑System framework provides a mathematically sound, compositional method for embedding safety constraints directly into system models. By treating safety requirements as controlling automata, it sidesteps the state‑explosion problem of conventional model checking, supports incremental requirement changes, and offers a clear engineering workflow that separates functional design from safety assurance. Future work suggested includes automated generation of controlling automata from high‑level safety specifications, extensions to real‑time constraints, and large‑scale industrial evaluations.