Incremental methods for checking real-time consistency
Thierry Jéron, Nicolas Markey, David Mentré, Reiya Noguchi, Ocan Sankur
IIncremental methodsfor checking real-time consistency (cid:63)
Thierry J´eron , Nicolas Markey , David Mentr´e Reiya Noguchi , and Ocan Sankur Univ Rennes, INRIA, CNRS, Rennes (France) [email protected] Mitsubishi Electrics R&D Centre Europe, Rennes (France) [email protected]
Abstract.
Requirements engineering is a key phase in the developmentprocess. Ensuring that requirements are consistent is essential so thatthey do not conflict and admit implementations. We consider the formalverification of rt-consistency , which imposes that the inevitability ofdefinitive errors of a requirement should be anticipated, and that of partial consistency , which was recently introduced as a more effectivecheck. We generalize and formalize both notions for discrete-time timedautomata, develop three incremental algorithms, and present experimentalresults.
In the process of developing computer systems, requirement engineering consistsin defining, documenting and maintaining the requirements. Requirements canbe of different nature, but since we are interested in timed systems, i.e. systemswhere time constraints are of importance, we will focus here on timed functionalones. Requirements are the primary phase of the development process, and areused to partly drive the testing campaign in order to check that they are indeedsatisfied by the implementation. In a formal approach, it is thus important todesign formal requirements that are consistent, i.e. that are not contradictoryand admit implementations that conform to them.In this paper, we study two prominent consistency notions studied in theliterature for real-time system requirements, called rt-consistency [PHP11a]and partial consistency [Bec19]. Partial consistency concentrates the notion ofconsistency on Simplified Universal Patterns (SUP) [BTES16] which are simplereal-time temporal patterns used to define real-time requirements, essentiallycomprising an assumption (named trigger ), a guarantee (named action ), togetherwith timed constraints on delays of these and between them. The advantage ofSUPs is that they define a specification language that is expressive enough yet (cid:63)
This work was partially funded by ANR project Ticktac (ANR-18-CE40-0015), andby a MERCE/Inria collaboration. a r X i v : . [ c s . F L ] J u l asy to understand, even by non experts. The counterpart is that the notion ofpartial consistency is specific to them and tricky.Rt-consistency requires that all finite executions that do not violate therequirements, have infinite extensions that satisfy all of requirements. Put differ-ently, this means that if an implementation produces a finite execution whose allcontinuations necessarily lead to the violation of some requirement, then theremust be a requirement that is already violated by the finite execution. In simplewords, inevitability of errors should be anticipated by the set of requirements.Thus, rt-consistency ensures that the set of requirements is well designed andsane. This is interesting in that it may reveal conflicts between requirements andcatch subtle problems, but it is rather expensive to check. Several directions canbe investigated to mitigate this complexity: restrict to sub-classes of requirements,in particular SUPs, restrict to subsets of requirements, examine alternative andcheaper notions of consistency. However these lead in general to false positivesand false negatives, and avoiding them requires additional conditions or checks.Partial consistency is one of these alternative notions of consistency thatonly considers pairs of SUP requirements. It checks that if there are possiblydifferent executions that trigger both requirements and satisfy one of them, thenthere should be a common execution in which both requirements are triggeredand satisfied. This check is perhaps better understood as a necessary conditionfor the rt-consistency of subsets of requirements (but this does not imply thert-consistency of the whole set). We formalize this link in this paper. The generalmotivation is to gain in efficiency, both by restricting to pairs of requirements,but also by focusing on particular situations where inconsistencies may arise.Nevertheless partial consistency can still be costly to check. Contributions.
We address the efficiency issue mentioned above by consideringan incremental approach to checking consistency and finding inconsistencies inreal-time requirements. In fact, rt-consistency and (bounded) partial consistencyare rather expensive to check already on small examples, and because of thestate-space explosion problem (which is a classical problem when composingseveral systems or properties), there is no hope that the approaches would scaleto large sets of requirements. Our algorithms improve the scalability of thisapproach by allowing one to check larger sets of requirements. We also definea new notion of incremental consistency, and allow to get different degrees ofconfidence about consistency (up to full rt-consistency).We show that checking rt-consistency can be reduced to
CTL model checkingfor discrete-time systems, providing an alternative approach to duration calculusand timed automata model checking of [PHP11a]. Then, we develop incremen-tal algorithms for checking rt-consistency and a variant of partial consistencygeneralized for automata. Inconsistencies are searched by starting with smallbatches of requirements. Whenever we find a counterexample to consistency, weeither confirm it (by checking that it fulfills the other requirements) or startthe analysis again with more precision by adding a new requirement in thebatch. This helps us to scale our analysis to larger sets of requirements. Thisidea is applied separately for both consistency notions. Moreover, we formalize2he relation between the two notions, showing how to obtain counterexamplesto rt-inconsistency from counterexamples to partial consistency. Due to spaceconstraints, all proofs are given in the appendix.
Related works.
Consistency notions appear naturally in the contract-based designof systems [BCN + existential consistency isstudied in [ESH14], where consistency consists in the existence of an executionsatisfying the requirements.Simplified Universal Patterns were introduced in [BTES16] to simplify thewriting of requirements by non-experts. The patterns are in the form of anassumption and guarantee. In this paper, the notion of consistency ensures theexistence of an execution which realizes one requirement (both the assumptionand the guarantee) without violating any other one. In [BTES16], the authorsalso use coverage notions to measure sets of consistent executions to give aquantitative measure of consistency. The notion considered there is thus relatedto non-vacuity (see e.g. [PHP11b]).More reactive notions were studied as in [AHL +
17] where consistency requiresthat the system should react to uncontrollable inputs along the execution so asto satisfy all requirements. The notion is thus formalized as a game betweenthe system and the environment, and an SMT-based algorithm is given tocheck consistency within a given bound. This notion thus relies on alternation ofquantifiers at each step. Rt-consistency and partial consistency, which we considerin this paper, lie between the two extreme approaches (that is simply existential versus game semantics). In fact, a single quantifier alternation is needed todefine rt-consistency (see Section 2.4). The rt-consistency checking algorithmof [PHP11a] considers systems in a continuous-time setting, and uses durationcalculus and timed automata model checking. We consider discrete-time systems(with unit delays rather than arbitrary real-valued delays).
We use
CTL to characterize certain kinds of inconsistencies.
CTL formulas aredefined as
CTL (cid:51) φ ::= p | ¬ φ | φ ∨ φ | AX φ | EG φ | E φ U φ, where p rangesover AP . CTL formulas are evaluated at the root of computation trees. We thusconsider computation trees labeled by valuations of atomic propositions: a tree t is a set of finite non-empty traces, i.e. words over 2 AP , closed under prefix, hencecontaining exactly one trace of size 1 (called its root, and denoted with r ( t )).We denote ≺ p the prefix ordering on traces. Given a node in the tree representedby a trace σ ∈ t , we write t σ for the subtree of t rooted at σ (i.e., the set of alltraces σ (cid:48) such that σ · σ (cid:48) ∈ t ). We write σ [ i ] for the prefix of length i of σ . Thata tree t satisfies a formula φ ∈ CTL is defined as follows: t | = p ⇐⇒ p ∈ r ( t )( p ) 3 | = ¬ φ ⇐⇒ t (cid:54)| = φt | = φ ∨ φ (cid:48) ⇐⇒ t | = φ or t | = φ (cid:48) t | = AX φ ⇐⇒ ∀ σ ∈ t. ( t σ [1] | = φ ) t | = E φ U φ (cid:48) ⇐⇒ ∃ σ ∈ t. ( t σ | = φ (cid:48) and ∀ σ (cid:48) . ( r ( t ) ≺ p σ (cid:48) ≺ p σ ) ⇒ t σ (cid:48) | = φ ) t | = EG φ ⇐⇒ ∃ σ ∈ t. ( ∀ i. t σ [ i ] | = φ )Using AX , we can define EX by EX φ ≡ ¬ AX ¬ φ . Similarly, AF φ ≡ ¬ EG ¬ φ means that φ holds along any infinite branch of the tree, and finally A φ U φ (cid:48) ≡ AF φ (cid:48) ∧ ¬ E ( ¬ φ (cid:48) ) U ( ¬ φ ∧ ¬ φ (cid:48) ) means that along all infinite branch, φ (cid:48) eventuallyholds and φ holds at all intermediary nodes. We consider requirements expressible by a class of timed automata (TA) [AD90].These extend finite-state automata with variables, called clocks , that can be usedto measure (and impose constraints on) delays between various events alongexecutions. More precisely, given a set X = { c i | ≤ i ≤ k } of clocks, the set of clock constraints is defined by the grammar: g ::= c ∼ n | g ∧ g , where c ∈ X , n ∈ N , and ∼ ∈ { <, ≤ , = , ≥ , > } . Let C ( X ) denote the set of all clock constraints.We consider integer-valued clocks whose semantics of constraints is defined inthe expected way: given a clock valuation v : X → N , a constraint g ∈ C ( X ) istrue at v , denoted v | = g , if the formula obtained by replacing each occurrence of c by v ( c ) holds. For a valuation v : X → N , an integer d ∈ N , and a subset R ⊆ X ,we define v + d as the valuation ( v + d )( c ) = v ( c ) + d for all c ∈ X , and v [ R ← v [ R ← c ) = 0 if c ∈ R , and v [ R ← c ) = v ( c ) otherwise. Let be thevaluation mapping all variables to 0.We consider timed automata as monitors of the evolution of the systemthrough the observation of values of Boolean variables. We thus consider a set AP = { b i | ≤ i ≤ n } of atomic propositions, and define the set of Booleanconstraints B ( AP ) as the set of all propositional formulas built on AP . Definition 1. A timed automaton is a tuple T = (cid:104) S, S , AP, X , T, F (cid:105) where S is a finite set of states, S ⊆ S is a set of initial states, AP is a finite set ofatomic propositions, X is a finite set of clocks, T ⊆ S × B ( AP ) × C ( X ) × X × S is a finite set of transitions, and F ⊆ S is the set of accepting states. We distinguish the following classes of timed automata. A safety timedautomaton is such that there are no transitions from S \ F to F . Converselya co-safety timed automaton is such that there are no transitions from F to S \ F .For a transition t = ( s, c, g, r, s (cid:48) ) ∈ T of a timed automaton, we define src ( t ) = s , tgt ( t ) = s (cid:48) , bool ( t ) = c , guard ( t ) = g , and reset ( t ) = r . Note that guardsare pairs of Boolean and timed guards that can be interpreted (and will be noted)as conjunctions since the two types of guards do not interfere.With a timed automaton T , we associate the infinite-state automaton S ( T ) = (cid:104) Q, Q , Σ, D, Q F (cid:105) that defines its semantics, where4 the set of states Q contains all configurations ( s, v ) ∈ S × N X ; – the initial states are obtained by adjoining the null valuation (all clocks aremapped to zero) to initial states S , i.e. Q = S × ; – Σ = 2 AP is the alphabet of actions, i.e. valuations of all Boolean variables; – transitions in D are combinations of a transition of the TA and a one-time-unit delay. Formally, given a letter σ ∈ Σ and two configurations( s, v ) and ( s (cid:48) , v (cid:48) ), there is a transition (( s, v ) , σ, ( s (cid:48) , v (cid:48) )) in D if, and only if,there is a transition ( s, c, g, r, s (cid:48) ) in T such that σ | = c and v | = g , and v (cid:48) = ( v [ r ← – Q F = F × N X is the set of accepting configurations.Our semantics thus makes it compulsory to alternate between taking atransition of the TA (possibly a self-loop) and taking a one-time-unit delay.Self-loops can be used to emulate invariants in states.The transition system S ( T ) is infinite because we impose no bound on thevalues of the clocks during executions. However, as in the setting of TA [AD90],the exact value of a clock is irrelevant as soon as it exceeds the largest integerconstant with which it is compared. We could thus easily modify the definitionof S ( T ) in such a way that it only contains finitely many states.A run of T is a run of its associated infinite-state automaton S ( T ). It canbe represented as a sequence along which configurations and actions alternate:( s , v ) · σ · ( s , v · σ · · · ( s n , v n ) · · · . A finite run is accepted if it ends in Q F .A trace of a run is its projection on the set of actions. In other terms, it is afinite or infinite sequence σ = ( σ i ) ≤ i Given two TAs T = (cid:104) S , S , , AP , X , T , F (cid:105) and T = (cid:104) S , S , ,AP , X , T , F (cid:105) with disjoint clock sets (i.e., X ∩ X = ∅ ), their product T ⊗ T is a TA T = (cid:104) S, S , AP, X , T, F (cid:105) where S = S × S , S = S , × S , , AP = AP ∪ AP , X = X ∪ X , F = F × F and the set of transitions isdefined as follows: there is a transition (( s , s ) , c, g, r, ( s (cid:48) , s (cid:48) )) in T if there aretransitions ( s , c , g , r , s (cid:48) ) in T and ( s , c , g , r , s (cid:48) ) in T with c = c ∧ c , g = g ∧ g , and r = r ∪ r . Note that completeness and determinism are preserved by product. The prod-uct of TAs can be generalized to an arbitrary number of TAs: for a set R = { R i } i ∈ I of requirements, each specified by a TA T i ( R i ), we note ⊗R the requirementspecified by the TA ⊗ i ∈ I T i ( R i ).Note that in this definition, clocks of factor automata are disjoint, whileatomic propositions are not, which may cause conflicts in guards of the product,and possibly inconsistencies as will be seen later. Also note that the product oftwo automata visits its accepting states if both automata do ( F = F ∧ F ), whileby complementation it visits non-accepting states if one of the automata does( ¬ F = ¬ F ∨¬ F ). For the product automaton, we directly define (without relyingon F ) Success T = Success T ∧ Success T and Error T = Error T ∨ Error T ,and both are trap sets. The definitions of Error and Success thus depend on thecontext: these are defined by the formulas ¬ F i ∧ AG ¬ F i and F i ∧ AG F i for theTAs T i representing the given requirements; for the products of these automata, Error T (resp. Success T ) is the disjunction (resp. conjunction) of Error T i (resp. Success T i ) of their operands. Notice that we have Success T = F ∧ AG F , butonly Error T ⊆ ¬ F ∧ AG ¬ F . The inclusion is in general strict, but becomes anequality when both T and T are safety TAs.For the rest of this document, we consider complete deterministic timedautomata (CDTAs for short) with accepting states F . We use complete deterministic TAs to encode requirements and identify therequirements with the CDTAs that define them. Remember that Error (resp. Success ) are sets of configurations from which one cannot escape. Intuitively,entering an Error (resp. Success ) configuration of a CDTA corresponds toviolating (resp. satisfying) the corresponding requirement definitively: Definition 3. For any requirement R defined by a complete deterministic timedautomaton and any finite or infinite trace σ , we write σ fails R if running σ in R enters Error R , and write σ succeeds R if it enters Success R . Note that for a finite trace σ , it could be the case that it does not hit Error R (resp. Success R ) but all infinite continuations inevitably do. We are particularlyinterested in such cases; we thus define the following notations for finite traces:6 efinition 4. For a finite trace σ , and a requirement R defined by a CDTA,we write σ I-fails R if for all infinite traces σ (cid:48) , σ · σ (cid:48) fails R . Similarly σ I-succeeds R if for all infinite traces σ (cid:48) , σ · σ (cid:48) succeeds R . Clearly, for finite traces, fails (resp. succeeds ) is stronger than I-fails (resp. I-succeeds ). Indeed σ fails R ( σ succeeds R ) means reaching a configuration in Error R (resp. Success R ), while σ I-fails R ( σ I-succeeds R ) means reachinga configuration in AF Error R (resp. AF Success R ). And Error R implies AG Error R , which implies AF Error R (and similarly for Success R ).For a given trace σ , and set of timed automata R = {T i } i ∈ I , we write σ fails R (resp σ succeeds R ) to mean that σ fails ⊗ R (resp. σ succeeds ⊗ R ). Notethe following simple facts: given R (cid:48) ⊆ R , for any finite trace σ , if σ fails R (cid:48) then σ fails R , and if σ I-fails R (cid:48) then σ I-fails R , while conversely, if σ succeeds R then σ succeeds R (cid:48) , and if σ I-succeeds R then σ I-succeeds R (cid:48) . Simplified Universal Patterns (SUP). TAs can be used to express the semanticsof Simplified Universal Pattern (SUP) [TBH16, Bec19], a pattern language thatis used to define requirements. Compared to TAs, SUPs offer a more intuitivebut less expressive way of writing requirements. Since partial consistency wasintroduced for SUP, we briefly introduce them. An SUP has the following form:(TSE , TC , TEE)[Tmin , Tmax] [Lmin , Lmax] −−−−−−−−→ (ASE , AC , AEE)[Amin , Amax] , where TSE, TC, TEE, ASE, AC, AEE, are Boolean formulas on a set AP ofatomic propositions, Tmin, Tmax, Lmin, Lmax, Amin, Amax are integers. Trigger phase Trigger EndEvent (TEE)Trigger StartEvent (TSE)Trigger Condition (TC)duration in [Tmin , Tmax] Action phase Action StartEvent (ASE) Action EndEvent (AEE)Action Condition (AC)duration in [Amin , Amax]delay in[Lmin , Lmax] Fig. 1. Intuitive semantics of SUP Figure 1 illustrates the intuitive semantics of SUP. A trigger phase (left) isrealized, if TSE is confirmed within a duration in [Tmin; Tmax], that is, if TCholds until TEE occurs; otherwise the trigger is aborted . For the SUP instanceto be satisfied, following each realized trigger phase, an action phase must berealized: an action phase starts with ASE within [Lmin; Lmax] time units afterthe end of the trigger phase, and then AC must hold until AEE occurs within[Amin , Amax] time units. Otherwise, the SUP is violated . Following [Bec19], onecan translate SUP instances (and repetitions of them) into complete deterministictimed automata. In fact all SUPs can be written as safety or co-safety CDTAs.7 xample 1. Consider the following two SUPs: R : request [3;4] −−−→ response , and R : repair [5;5] −−−→ ¬ response [3; 3], where an SUP of the form ( p, p, p )[0; 0] [0;1] −−−→ ( q, q, q )[0; 0] is written p [0;1] −−−→ q .The first requirement models a system that has to respond to any requestwithin 3 to 4 time units. The second requirement states that if the system entersa maintenance phase, then it will be off (and cannot respond) after 5 time units,and for a duration of 3 time units. Figure 2 displays the (safety) automataencoding these two SUPs where E i states are non-accepting trap states and allother ones are accepting. I D E ¬ request ( c < ∧ ¬ response ) ∨ c < request c := 0 response ∧ ≤ c ≤ c := 0 ¬ response ∧ c ≥ I D A E ¬ repair c < repair c := 0 ¬ response ∧ c = 5; c := 0 ¬ response ∧ c < ¬ r e s p o n s e ∧¬ r e p a i r ∧ c = ; c : = response ∧ c = 5 r e s p o n s e ∨ c = ¬ response ∧ repair ∧ c = 3; c := 0 Fig. 2. Timed automata encoding R and R We reformulate the original rt-consistency notion, introducedin [PHP11a]. Definition 5. Let R be a set of requirements. Then R is rt-consistent if, andonly if, for all finite traces σ , if σ I-fails R then σ fails R . Thus the set R is rt-consistent if any finite trace that inevitably fails, imme-diately fails. This is indeed equivalent to the formulation in [PHP11a], whichsays that all finite traces not violating any requirement can be extended to aninfinite trace not violating any of them (i.e. ¬ ( σ fails R ) implies ¬ ( σ I-fails R )).Notice that rt-consistency (w.r.t. Error R ) could be generalized to rt-consistencyw.r.t Success R : if σ I-succeeds R then σ succeeds R ; and all following resultseasily generalize to rt-consistency w.r.t. Success R with similar treatment.Observe that even when all individual requirements are rt-consistent (i.e., forall R ∈ R and all traces σ , it holds σ I-fails R = ⇒ σ fails R ) their conjunction(i.e. the product ⊗R ) may not be rt-consistent; for instance, taken individually,8oth requirements R and R of Example 1 are rt-consistent, but their productis not, as explained in Example 2). Rt-consistency requires that fails and I-fails be equivalent for all traces in the product automaton.Rather than using duration calculus as in [PHP11a], we show that CTL model checking can be used in a discrete-time setting to check rt-consistency.In CTL , rt-consistency of R can be expressed by requiring AF Error R ⇔ Error R at all reachable states. Since Error R is absorbing, a trace endingin a configuration in ¬ Error R ∧ AF Error R is a witness to rt-inconsistency. Moreover, only configurations in ¬ Error R need to be traversed to reach suchconfigurations; and such a configuration exists if, and only if, configurations existin ¬ Error R with all immediate successors in Error R , i.e., AX Error is true.In fact, we obtain the following property. Lemma 1. A given set of requirements R has a witness to rt-inconsistency if,and only if, R | = E ( ¬ Error R U ( ¬ Error R ∧ AX Error R )) .Example 2. The requirements in Example 1 are not rt-consistent: consider afinite trace σ where the repair signal is received, followed 3 time units later witha request . Then ¬ ( σ fails R ∧ R ); the joint run of the automata are as follows:( I , I , c =0 c =0 ) repair −−−−−→ (+delay) ( I , D , c =1 c =1 ) (cid:63) −−−−−→ (+delay) ( I , D , c =2 c =2 ) (cid:63) −−−−−→ (+delay) ( I , D , c =3 c =3 ) request −−−−−→ (+delay) ( D , D , c =1 c =4 ) . From this last configuration, it can be checked that no continuations of this tracewill avoid reaching E or E : indeed, both automata will first loop in their currentstates D and D , reaching configuration ( D , D ) , c = 2 , c = 5. In order toavoid visiting E , the next two steps must satisfy ¬ response , thereby reaching( D , A ) , c = 4 , c = 2. From there, we have a conflict: if response is true at thenext step, R reaches E , while if response is false, R reaches E .Now, assume we add the following requirement, which expresses that no re-quest can be received during maintenance: R : repair −→ ¬ request [5; 5]. This rulesout the above trace, and it can be checked that the resulting set of requirementsis now rt-consistent. Partial consistency. Partial consistency was introduced in [Bec19] as an al-ternative, more efficient check to detect inconsistencies in SUP requirements.We here generalize this notion to CDTAs. The name partial consistency mightbe misleading since it does not directly compare with rt-consistency: partialinconsistency identifies risky situations for pairs of requirements that could causert-inconsistency of the whole set. In this paper, we formalize this link, and showhow to lift witnesses of partial inconsistencies to witnesses of rt-inconsistencies.In a requirement R i , let us call action configurations those configurations al-lowing to enter immediately Error R i (i.e. satisfying EX Error R i ) . Then, action For SUPs, such configurations correspond to action phases, hence the name. Error R i are char-acterized by EX Error R i ∧ ¬ AF Error R i . Now, EX Error R ∧ EX Error R means we are simultaneously at action configurations of both R and R . Inthis case, even though there are separate continuations that avoid Error R and Error R , there may not be a common one. In our generalization of partialconsistency, we focus our attention to checking that a common continuationexists for this type of configurations which are seen as “risky” since they are inthe proximity of error.Let reach k ( R ) denote the set of configurations of R reachable within k steps. Definition 6. Consider requirements R , R and a set R (cid:48) of requirements. We saythat R and R are partially consistent w.r.t. R (cid:48) if for all k ∈ N ,if, for all i ∈ { , } , ∃ s i ∈ reach k ( R × R × R (cid:48) ) . s i | = EX Error R ∧ EX Error R ∧¬ AF ( Error R (cid:48) ∨ Error R i ) then ∃ s ∈ reach k ( R × R × R (cid:48) ) . s | = EX Error R ∧ EX Error R ∧¬ AF ( Error R (cid:48) ∨ Error R ∨ Error R ) . (1)Partial consistency requires that for all depths k , if infinite traces for bothrequirements can be found leading to an action configuration within k steps, andneither violate the requirement itself nor R (cid:48) , then a single infinite trace mustexist that reaches action configurations of both requirements within k steps, anddoes not violate any of them, nor R (cid:48) . Therefore, a witness of partial inconsistencyis a number k ≥ σ and σ such that, σ i reachesactions phases of both requirements within k steps, and never fails R i or R (cid:48) ,such that there are no infinite traces that do so without violating one of therequirements R , R or R (cid:48) .We establish that partial consistency is a necessary condition for the rt-consistency of the subset R (cid:48) ∪ { R , R } , since counterexamples for the formerprovide counterexamples for the latter: Lemma 2. If R and R are partially inconsistent w.r.t. R (cid:48) , then R (cid:48) ∪ { R , R } is rt-inconsistent. To efficiently find counterexamples to partial consistency, we consider thefollowing approximation, which is similar to that of [Bec19] but generalized toCDTAs. Given bounds α, β > 0, requirements R , R are ( α, β ) -bounded partiallyconsistent if for all k ≤ α ,if, for all i ∈ { , } , ∃ s i ∈ reach k ( R × R × R (cid:48) ) . s i | = EX Error R ∧ EX Error R ∧¬ AF α − k ( Error R (cid:48) ∨ Error R i )then ∃ s ∈ reach k ( R × R × R (cid:48) ) . s | = EX Error R ∧ EX Error R ∧¬ AF α + β − k ( Error R (cid:48) ∨ Error R ∨ Error R ) . (2)10here AF l φ means the inevitability of φ within l steps, which can be expressed in CTL as the disjunction of all formulas of the form AX ( φ ∨ AX ( · · · φ ∨ AX φ )) with l repetitions of AX . Thus the approximation consists in looking for witnesses ofbounded length for the satisfaction of the Equation 1). But notice that witnessesof failure of Equation 2 are not witnesses of failure of Equation 1 which requireinfinite traces (see below). Example 3. We consider again the requirements of Example 1. Requirements R and R are not partially consistent under empty R (cid:48) : as soon as a trace reachesaction configurations of both requirements, error states of any of them can beavoided, but not both of them. Under requirement R , requirements R and R cannot reach their action phases simultaneously, so that with R (cid:48) = { R } , thosetwo requirements are partially consistent.There are a few differences with the original definition of partial consistencyof [Bec19]. First, partial consistency of [Bec19] only checks the very first triggerof the traces. Moreover, it focuses on situations where, after respective triggers,no timing allows requirements to avoid being simultaneously in action phases.In our case, EX Error R ∧ EX Error R does not restrict simultaneous actionphases to such particular ones. Thus we can detect more subtle inconsistencies.The second difference is that the bounded approximation in [Bec19] checksfor the existence of a lasso-shaped execution in the automata that recognize theSUP requirements. The advantage of this is that such a lasso describes an infiniteexecution, so if partial consistency holds, so does the bounded approximation;while the converse is not true. In other terms, a witness for bounded partialinconsistency is a witness for partial inconsistency. In our case, we do not lookfor a lasso in the premise of (2), so this implication does not hold. We do prove,on the other hand, that rt-consistency implies (2); see Lemma 5.Third, in [Bec19], R (cid:48) contains only a specific type of requirements calledinvariants. In our case, R (cid:48) is an arbitrary subset of the requirement set. We provide three incremental methods to check rt-consistency of a given set ofrequirements R . The first one provides strong guarantees and can assess thert-consistency of the whole set R , or that of its subsets, and uses CTL modelchecking. The second one uses SAT/SMT solving and scales to larger sets. It can detect rt-inconsistencies of R , but cannot prove rt-consistency; it can only ensurepartial consistency. The third one can quickly find rt-inconsistencies.In all algorithms we consider a set R = { R i } i ∈ I of requirements, each givenas a CDTA, and their product ⊗R . In this section, we present our incremental algorithm for rt-consistency checking.Unlike the previous work of [Hoe06], which uses duration calculus [ZHR91],11 nput: A set R of requirements given as CDTAs, 2 ≤ n ≤ |R| φ ( R ) ← E [ ¬ Error R U ( ¬ Error R ∧ AX Error R )] for all pairs { R , R } ⊆ R do R (cid:48) ← { R , R } while |R (cid:48) | ≤ n and R (cid:48) | = φ ( R (cid:48) ) do σ ← witness of φ ( R (cid:48) ) // σ witnesses rt-inconsistency of R (cid:48) if ∃ R ∈ R \ R (cid:48) s.t. σ fails R then R (cid:48) ← R (cid:48) ∪ { R } elsereturn σ // σ witnesses rt-inconsistency of R return ∅ // no witness for the rt-inconsistency of R is found Algorithm 1: Incremental rt-consistency checking algorithm. In order to avoidchecking the same subsets of R (cid:48) several times, one can store the subsets seenso far and break the while loop when R (cid:48) has already been treated.our algorithm is based on computation tree logic ( CTL ) model checking. Rt-inconsistency of R reduces to checking whether a finite trace exists along which Error R remains false such that, from the last configuration, Error R is inevitable.Such a finite trace σ is called a witness for the rt-inconsistency of R . Rememberthat, by Lemma 1, this can be written in CTL as E [ ¬ Error R U ( ¬ Error R ∧ AX Error R )] to be checked in ⊗R .When the size of R is too large for model-checking tools to handle, we considersubsets R (cid:48) of R . Such incomplete checks alone do not provide any guarantee;indeed if R (cid:48) ⊆ R , consistency of R does not imply consistency of R (cid:48) , nor theopposite. Nevertheless, they can be used to detect rt-inconsistencies with anadditional check: Lemma 3. Let σ ∈ Σ ∗ be a witness for the rt-inconsistency of R (cid:48) ⊆ R .If ¬ ( σ fails R ) , then σ is also a witness for the rt-inconsistency of R . Let us now describe our procedure summarized in Algorithm 1. Given R and a bound n ≤ |R| , we consider subsets of R of size up to n , starting withsubsets of size 2. Assume a subset R (cid:48) ⊆ R is found to be rt-inconsistent witha witness trace σ . We check whether σ fails R \ R (cid:48) . If this is the case, weselect R ∈ R \ R (cid:48) such that σ fails R , and restart the analysis with R (cid:48) ∪ { R } .Notice that if R (cid:48) ∪ { R } is inconsistent, then σ cannot be a witness trace sinceit violates R . This ensures that a new requirement will be added to the set ateach iteration. Otherwise, by Lemma 3, we conclude that R is rt-inconsistentand σ is a witness. If no confirmed witnesses are found, then we stop and reportthat no rt-inconsistency is found. If n ≥ |R| , then one can conclude that R isrt-consistent; otherwise the check is incomplete.To increase the precision (to have a better chance to detect rt-inconsistencies),one can increase the bound n . In order to reduce the number of cases to check,thus giving up on completeness, one might restrict only to some subsets, forinstance making sure that each requirement is covered by at least one subset.12 nput: A set R of requirements given as CDTAs, parameters α, β > for all pairs { R , R } ⊆ R do R (cid:48) ← ∅ while Equation (2) fails do ( σ , σ ) ← witness traces for the premise of (2) for some k ≤ α if ∃ i ∈ { , } , ¬ ( σ i fails R ) thenreturn σ i // witness of rt-inconsistency of R elseif R = R (cid:48) ∪ { R , R } thenbreak // No witness is found for this pair else Choose R ∈ R such that σ i fails R for some i ∈ { , }R (cid:48) ← R (cid:48) ∪ { R } return ∅ // no counterexample is found Algorithm 2: Incremental partial consistency checking algorithm. We now present an incremental algorithm for checking partial consistency via the bounded partial consistency checking in the same vein as the previous section.Ideally, we would like to check Equation(2) for all pairs { R , R } of require-ments with respect to R (cid:48) = R \ { R , R } ; in fact, considering the whole set R (cid:48) makes sure that counterexample traces do not trivially violate requirements.This is costly in general, so we will start with an empty R (cid:48) and let it growincrementally by adding requirements as needed. The following lemma exhibitswhen such counterexamples can be lifted to witnesses of rt-inconsistency: Lemma 4. Let σ , σ and k be witnesses of bounded partial inconsistency for R , R ∈ R and R (cid:48) ⊆ R , i.e. counterexamples of Equation 2. If, for some i , ¬ ( σ i fails R ) , then σ i is also a witness for the rt-inconsistency of R . The procedure is summarized in Algorithm 2. Given pair ( R , R ) and set R (cid:48) ⊆R \ { R , R } , integer parameters α, β > 0, checking the ( α, β )-bounded partial-consistency consists in verifying Equation (2). A negative check is witnessedby some k ≤ α and a pair of traces σ , σ . If ¬ ( σ i fails R ) holds for some i ∈ { , } , the trace is returned as a counterexample by Lemma 4. Otherwise,a requirement R ∈ R such that σ i fails R is added to the set R (cid:48) and theprocedure is repeated. Thus, subsequent iterations will discard σ i and look forother traces. The following lemma shows that all counterexamples returned byAlgorithm 2 are witnesses to rt-inconsistency: Lemma 5. Let R be a set of requirements, and σ be a finite trace returned byAlgorithm 2. Then σ is a witness for rt-inconsistency for R . We now propose an algorithm for rt-consistency checking, that combines anincremental approach targeting subsets of requirements (hence the name partial),13 nput: A set R of requirements, parameters α > n ∈ [1 , |R| ] for all subsets S ⊆ R such that |S| ≤ n do R (cid:48) ← ∅ while S × R (cid:48) | = φ p,α do σ ← witness trace for φ p,α if ¬ ( σ fails R ) thenreturn σ // Counterexample for R elseif R = R (cid:48) ∪ S thenbreak // No counterexample is found for this subset else Choose R ∈ R such that σ fails R R (cid:48) ← R (cid:48) ∪ { R } return ∅ // no counterexample is found Algorithm 3: Incremental partial rt-consistency checking algorithm.and a bounded search, providing an alternative to Algorithm 1 amenable to usingSMT solvers. Intuitively, we check for the existence of configurations where allrequirements in a subset S of R immediately conflict i.e. AX Error S , meaningthat at the next step they inevitably violate at least one requirement of S .Let S be a subset of requirements of R . We say that S is partially rt-consistent with respect to R (cid:48) if for all configurations s , s | = ¬ Error S∪R (cid:48) = ⇒ ¬ AX Error S . (3)This clearly implies that S is rt-consistent, but also that no immediate conflictaffects the subset S in any configuration. A witness of partial rt-inconsistencyis a trace σ that reaches a configuration s satisfying ¬ Error S∪R (cid:48) ∧ AX Error S .Since AX Error S implies AX Error R (because Error S implies Error R ), ifadditionally ¬ ( σ fails R ) it is also a witness of rt-inconsistency by Lemma 3.Similarly to Lemma 1, the existence of a witness of partial inconsistency reducesto checking the formula φ p = E ( ¬ Error S∪R (cid:48) U ( ¬ Error S∪R (cid:48) ∧ AX Error S )) . Partial rt-consistency can be further restricted by bounding the size of S and restricting the exploration depth. For integers n and α , we say that R is α -bounded n -partially rt-consistent if Formula 3 holds for any subset S ofsize |S| ≤ n , and configurations s ∈ reach α ( R ). Checking α -bounded n -partialrt-inconsistency can be done by replacing U by U α in φ p thus checking φ p,α = E ( ¬ Error S∪R (cid:48) U α ( ¬ Error S∪R (cid:48) ∧ AX Error S )).We summarize the procedure in Algorithm 3, where, similarly to Algorithm 2,the set R (cid:48) is augmented by requirements failed by tentative counterexamples.We easily get the following lemma since a witness of α -bounded n -partial rt-inconsistency that does not fail R is also a witness of rt-inconsistency. Lemma 6. Let R be a set of requirements, and σ be a finite trace returned byAlgorithm 3. Then σ is a witness for rt-inconsistency. et size rt-consistency partial consistency partial rt-consistency Algorithm 1 Algorithm 2 Algorithm 3 (cid:88) (55s) 1 inconsist. (101s) (cid:88) (24s) (cid:88) (61s) (cid:88) (115s) (cid:88) (359s) (cid:88) (85s) (cid:88) (141s) (cid:88) (1143s) (cid:88) (133s) (cid:88) (227s) (cid:88) (5311s) (cid:88) (138s) (cid:88) (232s) Table 1. Experiments on our case study. The size shows the number of timed re-quirements + the number of (non-timed) Boolean requirements of the instance. Theparameters were chosen as α = 40 and n = 2. The sign (cid:88) means that no inconsistencieswere found. The experiments were run on a 1.9Ghz processor with a timeout of 3 hours. We experimented the different algorithms on a factory automation use case. Inthis system, a carriage and an arm cooperate to convey material: objects arepushed onto the carriage, which brings them to a position where a pushing armplaces them on a conveyor belt. The correctness of this system relies on severaltimed requirements between different elements of the system.Table 1 shows the inconsistencies found with our algorithms on sets of require-ments of varying sizes. The largest set we considered contained 29 requirements ofwhich 13 are timed and the other 16 are purely Boolean. We compare the incremen-tal partial consistency and partial rt-consistency algorithms (implemented usingthe SMT solver Z3 [Z3]), with the incremental rt-consistency algorithm (imple-menting CTL model-checking using NuSMV [NuS]). Inconsistencies were detectedin the first two sets, but partial consistency failed in detecting any in set In this paper, we studied the notions of rt-consistency and partial consistency.We showed how to reduce the problem to CTL model checking on timed automatamodels, and presented algorithms that can detect rt-inconsistencies. Our prelimi-nary experiments show encouraging results. As future work, we will extensivelyevaluate the ability of these algorithms to capture inconsistencies, and theirperformances on large realistic use cases. One might investigate other variants ofthe (partial) consistency notions, with the goal of detecting more inconsistenciesmore efficiently. There is a trade-off to find for such partial consistency algorithms.In fact, they might allow one to examine more potential counterexample witnesses,which means that one might detect more inconsistencies, but one might also haveto deal with more false positives. Another interesting question is how to correctrt-inconsistencies e.g. by adding new requirements.15 eferences [AD90] Rajeev Alur and David L. Dill. Automata for modeling real-time systems.In Mike Paterson, editor, Automata, Languages and Programming, 17thInternational Colloquium, ICALP90, Warwick University, England, UK,July 16-20, 1990, Proceedings , volume 443 of Lecture Notes in ComputerScience , pages 322–335. Springer, 1990.[AHL + 17] Bernhard K. Aichernig, Klaus H¨ormaier, Florian Lorber, Dejan Niˇckovi´c,and Stefan Tiran. Require, test, and trace it. International Journal onSoftware Tools for Technology Transfer , 19(4):409–426, Aug 2017.[BCN + 18] Albert Benveniste, Benoˆıt Caillaud, Dejan Nickovic, Roberto Passerone,Jean-Baptiste Raclet, Philipp Reinkemeier, Alberto L. Sangiovanni-Vincentelli, Werner Damm, Thomas A. Henzinger, and Kim G. Larsen.Contracts for system design. Foundations and Trends in Electronic DesignAutomation , 12(2-3):124–400, 2018.[Bec19] Jan Steffen Becker. Analyzing consistency of formal requirements. ElectronicCommunications of the EASST (AVOCS 2018) , 76, 2019.[BTES16] Tom Bienm¨uller, Tino Teige, Andreas Eggers, and Matthias Stasch. Mod-eling requirements for quantitative consistency analysis and automatic testcase generation. In Workshop on Formal and Model-Driven Techniquesfor Developing Trustworthy Systems at 18th International Conference onFormal Engineering Methods , 2016.[ESH14] Christian Ellen, Sven Sieverding, and Hardi Hungar. Detecting consis-tencies and inconsistencies of pattern-based functional requirements. InFr´ed´eric Lang and Francesco Flammini, editors, Formal Methods for Indus-trial Critical Systems , pages 155–169, Cham, 2014. Springer InternationalPublishing.[Hoe06] Jochen Hoenicke. Combination of Processes, Data, and Time . PhD thesis,University of Oldenburg, 2006.[NuS] NuSMV: a new symbolic model checker. http://nusmv.fbk.eu/ .[PHP11a] Amalinda Post, Jochen Hoenicke, and Andreas Podelski. rt-inconsistency:a new property for real-time requirements. In Fundamental Approaches toSoftware Engineering (FASE) , volume 6603 of LNCS . Springer, 2011.[PHP11b] Amalinda Post, Jochen Hoenicke, and Andreas Podelski. Vacuous real-time requirements. In IEEE 19th International Requirements EngineeringConference , pages 153–162, Aug 2011.[TBH16] Tino Teige, Tom Bienm¨uller, and Hans J¨urgen Holberg. Universal pattern:Formalization, testing, coverage, verification, and test case generation forsafety-critical requirements. In Ralf Wimmer, editor, , pages 6–9. Albert-Ludwigs-Universit¨at Freiburg, 2016.[Z3] The Z3 theorem prover. https://github.com/Z3Prover/z3 .[ZHR91] Chaochen Zhou, C.A.R. Hoare, and Anders P. Ravn. A calculus of durations. Information Processing Letters (IPL) , 40(5):269–276, 1991. Proofs Lemma 1. A given set of requirements R has a witness to rt-inconsistency if,and only if, R | = E ( ¬ Error R U ( ¬ Error R ∧ AX Error R )) .Proof. Let us consider the following formula φ ( R ) = E ( ¬ Error R U ( ¬ Error R ∧ AX Error R ))By definition, R is rt-inconsistent if there is a reachable configuration s suchthat s | = ¬ Error R ∧ AF Error R . It is thus clear that if the initial state of ⊗R satisfies φ ( R ), then R is rt-inconsistent.Let us assume that R is rt-inconsistent, and consider a reachable config-uration s satisfying ¬ Error R ∧ AF Error R . Let ρ denote the run that endsin s . Since Error R is absorbing, all states of ρ satisfy ¬ Error R . We show thatthere exists some configuration s (cid:48) reachable from s with both s (cid:48) | = ¬ Error R and s (cid:48) | = AX Error R . To see this, we build a run from s inductively as follows.Initially, the run is at configuration s . At any moment, if the current configurationhas a successor satisyfing ¬ Error R , we choose one arbitrarily and extend therun. If there are no such successors, then this provides the configuration s (cid:48) asdesired. Notice that this constructed run cannot be infinite, since this wouldcontradict that s | = AF Error R , so such a s (cid:48) must exist.Now the run we obtain from the initial configuration to s (cid:48) is a witness for φ ( R ). (cid:3) Lemma 2. If R and R are partially inconsistent w.r.t. R (cid:48) , then R (cid:48) ∪ { R , R } is rt-inconsistent.Proof. Consider k ≥ 0, and traces σ , σ which are witnesses to partial incon-sistency, as well as configurations s i ∈ reach k ( R × R × R (cid:48) ). We have s | = ¬ Error R ∧ ¬ Error R ∧ ¬ Error R (cid:48) . Rt-consistency requires that there existsan infinite continuation from s satisfying ¬ Error R ∧ ¬ Error R ∧ ¬ Error R (cid:48) .However, since (1) does not hold, there is no state s ∈ reach k ( R × R × R (cid:48) )satisfying both s | = EX Error R ∧ EX Error R and admitting such an infi-nite continuation. Therefore, s i cannot have such a continuation, which provesthat R (cid:48) ∪ { R , R } is rt-inconsistent. (cid:3) Lemma 3. Let σ ∈ Σ ∗ be a witness for the rt-inconsistency of R (cid:48) ⊆ R .If ¬ ( σ fails R ) , then σ is also a witness for the rt-inconsistency of R .Proof. In fact, if σ is a witness of rt-inconsistency in R (cid:48) , by definition ¬ ( σ fails R (cid:48) )but σ I-fails R (cid:48) . Since R (cid:48) ⊆ R , (inevitably) failing R implies (inevitably) failing R (cid:48) ( σ I-fails R (cid:48) implies σ I-fails R ). By hypothesis, ¬ ( σ fails R (cid:48) ), but it maybe the case that σ ; fails R . If additionnally ¬ ( σ fails R ), then we can concludethat σ is a witness of rt-inconsistency of R . (cid:3) emma 4. Let σ , σ and k be witnesses of bounded partial inconsistency for R , R ∈ R and R (cid:48) ⊆ R , i.e. counterexamples of Equation 2. If, for some i , ¬ ( σ i fails R ) , then σ i is also a witness for the rt-inconsistency of R .Proof. For any i ∈ { , } , if σ i witnesses ( α, β )-bounded partial inconsistency,by definition σ i reaches a configuration s i in reach k ( R × R × R (cid:48) ) satisfying EX Error R ∧ EX Error R ∧ ¬ AF α − k ( Error R (cid:48) ∨ Error R i ) but no configu-ration s ∈ reach k ( R × R × R (cid:48) ) satisfies EX Error R ∧ EX Error R ∧¬ AF α + β − k ( Error R (cid:48) ∨ Error R ∨ Error R ). Since s i | = EX Error R ∧ EX Error R , it satisfies AF α + β − k ( Error R (cid:48) ∨ Error R ∨ Error R ). If addition-ally σ i satisfies ¬ ( σ i fails R ), since AF α + β − k ( Error R (cid:48) ∨ Error R ∨ Error R )implies AF Error R , then s i satisfies ¬ Error R ∧ AF Error R , thus σ i is awitness for rt-inconsistency. (cid:3) Lemma 5. Let R be a set of requirements, and σ be a finite trace returned byAlgorithm 2. Then σ is a witness for rt-inconsistency for R .Proof. Assume that the algorithm returned a counterexample trace σ ∈ Σ ∗ forthe outer iteration with R , R ∈ R , and inner iteration R (cid:48) ⊆ R . The algorithmensures that ¬ ( σ fails R ) (line 6). We then use Lemma 4 to conclude that σ is awitness for rt-inconsistency for R . (cid:3)(cid:3)