Incremental Methods for Checking Real-Time Consistency

Abstract

Requirements engineering is a key phase in the development process. Ensuring that requirements are consistent is essential so that they do not conflict and admit implementations. We consider the formal verification of rt-consistency, which imposes that the inevitability of definitive errors of a requirement should be anticipated, and that of partial consistency, which was recently introduced as a more effective check. We generalize and formalize both notions for discrete-time timed automata, develop three incremental algorithms, and present experimental results.This work was partially funded by ANR project Ticktac (ANR-18-CE40-0015), and by a MERCE/Inria collaboration.

Repairing Real-Time Requirements

“…Under such a condition, a run is accepting if, and only if, it never visits any non-accepting state. This simplifies the presentation but a richer set of properties could be handled as in [18].…”

“…RT-Consistency. We recall rt-consistency, introduced in [27] and further studied in [18]. Put simply, a set R of requirements is rt-consistent if all finite traces that do not fail R admit infinite continuations that satisfy R. In other terms, at any finite trace where failure is inevitable, some requirement must already be failed.…”

“…A simpler characterization of rt-inconsistency was proven in [18]: Non-vacuity. We define the non-vacuity of a set of requirements, which states that each requirement must be triggered by some trace without failing any requirement.…”

“…Due to this form, non-vacuity is easy to define and to interpret: the trigger phase of each requirement must be realized by some execution which does not fail other requirements. SUPs can be expressed as timed automata, and our algorithms can be easily extended to general timed automata [2] as in [18]. We do focus on SUPs here for their simplicity, and because non-vacuity can be defined naturally due to their form.…”

“…Put differently, this means that if an implementation produces a finite execution whose all continuations necessarily lead to the failure of some requirement, then there must be a requirement that already fails at the said finite execution: the inevitability of an error must be anticipated by the set of requirements. It can be shown that rt-consistency is not a linear-time property; it was expressed using a CTL formula in [18]. It can be observed that adding a requirement to the set can remove rt-inconsistencies, since, intuitively, the new requirement can be made to imediately fail whenever the error is inevitable in the future.…”