Constructing Property-Oriented Models for Veriﬁcation

. This paper advocates a general approach to formal veriﬁcation by constructing property-oriented models. We instantiate the approach using timing properties, and construct a heterogeneous untimed model in which time is abstracted away, so that we can verify timing properties in an untimed framework. The correctness of property-oriented model construction is ensured by the conformance of semantic and syntactic mappings.


Introduction
It has been noticed that a single software development method is not sufficient to solve all types of problems found in complex software systems.The integration of software development methods has been proposed and investigated in the recent years, for example, the integration of state-modeling and process languages has become an active area of research ( [19, 6, 1, 11]).Such blending of different notations can provide us more powerful languages for specifying very complex software systems.Unified observationoriented models behind the integrated languages (like [14], [23]) can ensure the soundness of the integration of different notations, and can be used as a reference document for developing tool supports.However, such complete models are usually very complicated and thus hard to use for the verification purpose.
Properties to be verified or analysed can be divided into different categories, each kind of properties only refer to part of the whole observation model, such as safety properties that are not time dependent, timing properties, deadlock-free properties.Recent work [4] suggests a projection approach to the verification of timing properties.The projection can be conducted in a syntax-directed manner, where the soundness proof replies on a deep projection from the whole model to the sub-model, thus the whole model should be built first, which is usually very time-consuming.Therefore, we propose to construct (small) property-oriented models for the verification of any particular kind of properties.We shall guarantee that different property-oriented sub-models can be integrated into the whole model in a later stage, where necessary.In this paper, we elaborate this general idea using timing properties.We construct an untimed heterogeneous model, where time information is abstracted away, and handled by a special Timer process.With such a property-oriented model we can verify certain kind of timing properties using the simpler untimed model, either by model checking or theorem proving.This greatly simplifies the verification process.
We demonstrate our approach using a small language CZ, which is a subset of the combination of CSP [7] and Z [20].It can be regarded as a subset of the Circus [21] language, or a subset of another powerful specification language TCOZ [11].We shall focus on timing properties that can be described in programming languages, rather than specification languages, like: -the delay between two consecutive events should at least be t units of time; -a program awaits an event at most t units of time before it does something else.
More general timing properties that can be described in specification languages but difficult in programming languages, like deadline and waituntil in TCOZ, will not be covered here.
This paper makes the following contributions: -We propose a general approach to verification by constructing property-oriented models for integrated formal languages.-We demonstrate our approach in terms of timing properties.We build an untimed model for the verification of real-time properties.-We build a deep link between timed traces and untimed heterogeneous traces (with timer events).From that, we can generate the provably-correct untimed model.-We illustrate our approach through an alarm controller example.
The rest of the paper is organized as follows.Section 2 introduces the illustrative example.Section 3 describes the language model.The approach is presented in detail in Section 4, followed by related work and conclusion.

An Illustrative Example
In this section, we use a small example to illustrate a novel approach to the verification of timing properties for reactive systems.

The Alarm Controller
The alarm system was first used in [9].The system is a common alarm controller that can be found in buildings and cars.The controller is connected to a sensor which detects movements or changes in the environment monitored by the alarm.The controller operates in two modes: when disabled, it will ignore any disturbance detected by the sensor; when enabled, the controller will sound an alarm when the sensor signals a disturbance.
There are two timing requirements on the alarm controller: the first states that after the controller is enabled, there is a period of t 1 units of time before a disturbance can cause the alarm to ring.The period t 1 permits a person to enable the alarm and then leave without causing it to sound.The second requirement states that when a detected disturbance is received, the controller will wait for another period of t 2 units of time before activating the alarm.The period t 2 leaves some time to the legal user to disable it before it sounds.
Let us analyse the first timing requirement, that is, when the controller is enabled, there is a delay of t 1 units of time before it can receive any disturbance from its sensor.As a first attempt, we can specify this requirement in terms of the following action: Notice the event enable indicates the alarm system is enabled, while the event disturb denotes a disturbance detected by the sensor.At this moment, we ignore the subsequent behaviour after a disturbance is received and simply use R to denote it.
The key idea of our approach is to separate timing properties from logical properties by introducing a specific component, called Timer, to take care of the timing features.Thus we can use existing untimed verification tools like model checkers to verify that certain time properties are met, rather than construct a new tool for verification from scratch.
For R 1 , we can transform it to the following untimed action: The two new events set and reset are used to interact with the following Timer action: Note that the Timer component is in charge of time control.It is activated by set signal, and after t 1 time elapses, it notifies the process R ′ 1 via signal reset.To verify R 1 meets the property that a disturbance can only be received after the controller is enabled for t 1 units of time (we refer to it as t 1 -delay property in what follows), we only need to check the following untimed property for R ′ 1 : ∀utr 0 , utr 1 , utr 2 • ((utr = utr 0 enable utr 1 disturb utr 2 ∧ utr 1 ↾ {enable, disturb} = ) ⇒ utr 1 = set, reset ) It states that there are only two timer events set and reset between an enable event and its consecutive disturb event.The event set activates the timer, while reset deactivates the timer, which indicates t 1 time is passed.Together with the timer action, it ensures the t 1 -delay property.Note that utr denotes the (untimed) trace, i.e. a sequence of events, while utr i 's are segments of the trace.Formal definitions will be given in a later section.The soundness for the separation of timing features from logical features can be specified in terms of the following equation: This can be easily proved using the expansion laws for parallel composition.The right hand side is a parallel composition of an untimed action (R ′ 1 ) and a timer action (Timer) which communicate with each other via two internal events set and reset (hidden from outside).Such a parallel composition is the normal form we shall adopt for verification.

The Normal Form
In this subsection, we shall deal with the complete specification for the alarm controller.
The complete timed specification for the alarm controller is given as follows.
Note that event disable is used to disable the controller, event alarm signals the firing of the alarm.For more flexibility, we allow the controller to be disabled at any point during running.We use timeout constructs (defined later in Section 3.2) to capture this requirement.Take Alarm as an example, once the controller is enabled, it is either disabled (and then waits for enable again), or is ready to receive any disturbance after t 1 (Running).
As explained in last subsection, we shall transform the timed specification Alarm to a normal form composed of an untimed specification in parallel with a Timer action.
We shall use function Φ to abstract away timing features from a timed action.The complete definition for Φ will be given when we present the syntax of the language.The following is the result after applying it to the above specification.
Note that a new timer event halt is used to stop the timer when event disable arrives during the ticking of the clock.There are two timing requirements in the specification, thus we design the general timer action as follows: Note that when the timer is set to work, a value is passed to it (stored in x) to indicate the time duration that it should count before it generates a reset signal.Now the timed specification Alarm is transformed to the following normal form: The following theorem ensures the soundness of the abstraction.
Theorem 1.We have It is proved using parallel expansion and hiding laws.

Verification of Timing Properties in the Untimed Model
In this subsection we shall demonstrate that timing requirements can be verified in the untimed framework.There are two timing requirements for the alarm controller, namely, -once enabled, the controller should wait at least t 1 units of time before it can receive any disturbance from the sensor.-once a disturbance is received, the controller should wait at least t 2 units of time before it fires the alarm.
As timing is controlled by the timer actions in our normal form, we can abstract away timing from the above requirements by adding in timer events that are in charge of activating/deactivating the timers.The timing requirements are thus specified in terms of timer events as follows: The overall timing requirement for the alarm controller is thus as below: To verify the timed specification (Alarm) meets the timing requirements, we only need to demonstrate that the untimed specification (Φ(Alarm)) meets the above requirement, that is, Φ(Alarm) ⇒ Req(utr).where Thus the semantic predicate Note that we also use the operator (;) to represent the concatenation of two observational predicates.The formal definition is given in [8].
Due to the following fixed point theorem ( [8]): and the fact that there is only one fixed point in this case, we only need to prove It is thus straightforward as all possible traces of P lie in the following set: P Note that the proof is much simpler and more straightforward in comparison with the existing proof given in [9] due to the property-oriented model we use.

The Language
This section introduces our language CZ that we use to instantiate our method.We shall give both the untimed and timed models.

The Untimed Model
The syntax for CZ is given in Fig. 1.Skip is a basic action that terminates immediately.Stop represents an abnormal termination which simply puts a program in an ever waiting state.Chaos is the worst action, nothing can be said about its behaviour.In a guarded action (b&Action), the action is preceded by a predicate which has to be true for the action to take place, otherwise the guarded action behaves as Stop.An internal choice between two actions (Action ⊓ Action) selects one of the two actions in a non-deterministic manner, whereas the external choice (ActionPAction) waits for any of the two actions to interact with the environment.The first action that interacts with the environment (either by synchronising on an event or terminating) is the resulting action.
The sequential composition of two actions (Action; Action) behaves as the first action, followed immediately by the second action upon termination of the first.An action can be prefixed with a communication event (input or output) which will take place before the action starts.The action waits for the other actions that need to synchronise on the channel before the communication can take place.The parallel composition of two actions (Action|[cs]|Action) involves a set (cs) containing the events they need to synchronise on.A hiding operation also takes a set of events (cs).The set is to be excluded from the resulting observation of the action, hidden events can no longer be seen by other actions.
An observation-oriented model for the Circus language based on Hoare and He's Unifying Theories of Programming [8] is explored in detail in [23,21], while the unified model for TCOZ is reported in [14].As our language CZ is a subset of the above two languages, we can borrow the following observation variables from them.
-ok, ok ′ : Boolean.When ok is true, it states that the program has started and ok ′  A single observation is given by the combination of the above variables.A program is given as predicates over the observation variables.We give the semantics for basic actions and communication events in what follows to show the use of the above semantic variables.Readers can refer to [23,14] for the complete set of semantic definitions.
Basic Action The semantics of the action Skip is given as a program that can only terminate normally and has no interaction with the environment.
The action Stop is given as a predicate that waits for ever; it does not change the state.
The assignment attributes a value to a variable in the current state.If the variable does not exist it will be added, otherwise its value will be over written.The assignment operation is instantaneous and does not consume time.
Note that we abuse the same e in the right hand side to denote the value of e in state.
Communication An action can engage in a communication if all the other actions involved in the same communication are ready to do so.We model this with the help of two predicates.wait com(c) models the waiting state of an action to communicate on channel c.The only possible observation is that the communication channel cannot appear in the refusal set during the observation period.term com(c.e)represents the act of communicating a value e over a channel c.
The semantics of the output command is given below.
The input command can be defined in a similar manner.
The semantics of the communication prefix can be given in terms of communication and of the sequential composition.The action comm is either an input or an output event, or an abstract event name.

The Timed Model
The timed language TCZ extends the untimed language CZ with two new time operators given in Fig. 2.

Fig. 2. TCZ: the timed model
The action (Wait t) will delay the system for an amount of time determined by the positive integer expression t before terminating normally.The timeout construct (Action t £ Action) takes a positive integer value as the length of the timeout.The timeout operator acts as a time guarded choice.It behaves as either the first or the second action.If the first action performs an observable event or terminates before the specified time elapses, it is chosen.Otherwise, the first action will be suspended and the only possible observations are those produced by the second action.
The semantics for the timed language is given with the same observation variables ok, ok ′ , wait, wait ′ , state and state ′ , while the variables utr, utr ′ and ref ′ are replaced by a new pair of variables ttr, ttr ′ denoting communication traces in the timed model.
The variable ttr records the observations of communication events that occur before the program starts, and ttr ′ records the final observation.Each element of the sequence represents an observation in one time unit.Each observation element is composed of a tuple, where the first element of the tuple is the sequence of events that occur in the time unit, and the second is the associated set of refusals at the end of the same time unit.
ttr, ttr ′ : seq(seq Event × P Event) We maintain an auxiliary variable utr that represents a sequence of events that have occurred since the last observation.In this observation we are interested in recording only the events without time.We show the use of these new variables in the definition of the (Wait d) action.The only possible behaviour for this action is to wait for the specified number of units of time to pass before terminating immediately.
The timeout action can be defined in terms of external choice as in [17].The following is a direct definition.
Note that if P is ready to react to the environment exactly when it has waited for time t, the timeout process chooses P or Q non-deterministically.
Given the semantic model for a TCZ program, we can use the linking function given in [17] to abstract away time information, and thus obtain the corresponding untimed model.This abstraction is useful when we are interested in the verification of timeindependent safety properties.In this paper, we shall not elaborate on this aspect but focus more on timing properties.

The Approach
This section is devoted to the general approach that we propose to the verification of real-time systems.The verification framework is given in Fig. 3. Fig. 3 shows us two different approaches.The first one is a top down approach where we start with a timed program and we are interested in checking if the timed program satisfies the time requirements.The second approach is a bottom up method where we start with an untimed program and add time information where requested.The need for the second one is due to the fact that system development is usually done in stages, in the early stages of development the system designer concentrates on the behaviourial/logical properties of the system, while leaving timing requirement to a later stage.Another aspect is that in some cases it is necessary to identify the hardware used in the implementation to have a clear understanding of the time delays and timeouts that can occur in the system and the points in which they may occur.In the rest of this section we present our approach in detail.

The Validation Approach
This approach is concerned with the validation of the time requirements of the system using the untimed model.Fig. 3 illustrates the steps for using the framework.The steps to carry out the validation of the time requirements are summarised as follows.
-We start with a specification of our system in the timed model using the timed version of the language.The system designer gives a complete description of the system.All the operators of the language can be used at this stage including parallel composition The timed semantic model of the language is used in this step.-If we need to verify untimed safety properties, we can use an abstraction function (e.g. the one given in [17]) to obtain an untimed version of the original specification.Such an untimed program can be used to validate the behaviour requirements and safety requirements that are not time dependent.We do not elaborate this aspect in this paper.-With the help of the normal form function Φ, we obtain a version of the program that has the same semantics as the original program but contains internal timer events.In this step the expansion laws should be used as well to remove all the parallel compositions.-Time requirements can be expressed in the untimed model with timer events.We can use this untimed model to prove the design meets the time requirements.This can be done using theorem provers or existing (untimed) model checkers.

The Normal Form
Usually timed programs are implemented with timers, this can be either the system clock or a dedicated timer.Following the same criteria we give a normal form for the time operators.The implementation of the time operators is given as a timer and an untimed program that is synchronised with the timer on dedicated events.As mentioned above, the events set, halt, and reset are timer events, used by the program to synchronise with and control a timer.The following is the timer program: The timer is initiated with the event set which serves as a trigger.The behaviour of the timer is as follows: after set by its environment, it waits for the set signal to set the timer again if an interrupt event halt arrives before the timeout, or it emits a signal reset and starts to wait for another set after it has counted for the designated period of time (stored in x) set by the environment.The event reset is similar to other events used in the language, whereas the events set and halt have special properties.We shall explore these differences further in the next subsection.
Given the definition for a timer action, we aim to generate a function Φ that takes as input a timed program and returns the corresponding untimed program with timer events.That is, for any sequential program P, the function Φ should satisfy the following equation: Note that in the action (X par Y), X behaves as a master action, while Y acts as a slave action.The overall action terminates if and only if the master action X terminates.As timers are not allowed to be shared by parallel actions, several timer actions are needed in the equation ( †) in case that P is a parallel action.
We shall first give a mapping ψ to abstract away time information from timed traces, while adding timer events properly.This can be regarded as a deep semantic link between a timed process and a heterogeneous communicating process.We only need to define the mapping ψ on maximal traces.Definition 1.A timed trace ttr 0 from a prefix-closed trace set is maximal, if for any trace ttr 1 that satisfies #ttr 0 = #ttr 1 , and ∀i : 1..#ttr 0 • π 1 (ttr 0 (i)) = π 1 (ttr 1 (i)), we have ∀i : 1..#ttr 0 • π 2 (ttr 0 (i)) ⊇ π 2 (ttr 1 (i)).Definition 2. Given a set of timed traces TTR, and a single prefix s, we define a set of timed traces "after" s as follows: TTR/s = {ttr | (s ttr) ∈ TTR} Given a trace ttr, we use pref(ttr) to denote the prefix-closed set of traces made out of all prefixes of ttr.We extend it to a set of traces TTR as pref(TTR) = {pref(ttr) | ttr ∈ TTR} Given two set of traces TTR 1 , and TTR 2 , the concatenation of them is given as Definition 3 (Semantic Mapping).Let A denote the maximal set of events of interest, and A * denote the sequence closure over A. Given a set of maximal traces TTR, the corresponding set of heterogeneous traces ψ(TTR) is defined as follows: We assume that any sequential action can be written in the guarded normal form P n i=1 (c i → P i ).We construct Φ as follows.Definition 4 (Syntactic Mapping).
)) Theorem 3. The syntactic mapping Φ conforms with the semantic mapping ψ.That is, given any program P from TCZ, we have The proof is straightforward by a structural induction on P.
Theorem 4. The syntactic mapping Φ is a homomorphic solution to the equation ( †).

Algebraic Laws
The set of processes generated by function Φ are called as heterogeneous communicating processes (HCP).It can be regarded as an extension of Communicating Sequential Processes (CSP) (if we ignore state features).It enriched CSP with timer events, thus is also subject to the healthiness conditions for CSP (Chapter 8 of [8]).However, as timer events have the same behaviour in both synchronous and asynchronous models, it satisfies some additional healthiness conditions.These additional properties will yield a subset of CSP processes.Therefore, although heterogeneous communicating processes are an extension of CSP, they can be simulated by a subset of CSP.We shall present the additional properties in what follows.The following condition indicates that no heterogeneous communicating process can refuse both events halt and reset simultaneously when the timer is activated.

HC1 |[P]| ∧ utr set
In what follows, we give some expansion laws to transform a parallel action into a sequential one.Take note that timer events play different roles from normal events.
In the following laws, we assume P and Q are already in guarded normal forms: , where for all i, k, c i = d k , and c i , d k are not timer events.Let cs = (αP ∩ αQ)\{set, halt, reset}.
The following one is the standard expansion law where no timer events are involved.

Law 1 P|[cs]|Q
If timer events are involved, we should use the following expansion laws.

Law 2
(set Note that the two output events set 1 and set 2 can occur in any order, which is reflected by the internal choice.So do the two halt events or a mix of them, as illustrated by the following two laws.The events set and halt from the master process have higher priority than the reset event emitted by the slave process.This is reflected in the following two laws: Take note that different from Law 2, external choice is used here as the two input events reset 1 and reset 2 have to wait for the corresponding output events from the environment (Timer processes).

Related Work and Conclusion
The two mostly related integrated formal specification languages are TCOZ [11] and Circus [21].Circus is a combination of CSP and Z.It also includes specification statements found in Morgan's refinement calculus [13] and Dijkstra's language of guarded commands [3].Circus has a well-defined syntax and a formal semantics [23,21] based on Hoare and He's unifying theories of programming [8].Case studies using the language are explored in [22] to show its power of expressiveness.A development method for Circus using refinement is described in [15].A timed model for Circus was provided in [17].Our untimed model CZ is a subset of Circus.
TCOZ is a blending of Object-Z [5,18] and Timed CSP [16,2], aiming at specification for complex real-time systems.The semantic link between the two formalisms Timed CSP and Object-Z is reported in [12].TCOZ was enriched with sensors/actuators in [10].A unified observation model for TCOZ is presented in [14].Recent work [4] proposed a projection from TCOZ specifications to Timed Automata Patterns for model-checking timing properties using UPPAAL.Their syntactical mapping is proved sound under bisimulation.In our paper, we propose to verify timing properties in untimed framework by constructing a property-oriented untimed model, which, we believe, should be much simpler than doing it within the timed model.
Instead of using the same complex model as both semantic and reasoning models, we advocate the construction of small property-oriented models, that are separated from the whole semantic model, for verification of particular kinds of properties.In our instantiation in terms of timing properties, the approach does make analysis and reasoning about certain timing properties simpler and easier.A deep semantic link has been built between the timed model and the untimed model in the observation level, which ensures that it is safe to use a smaller property-oriented model for verification.