Acessibilidade / Reportar erro

On synthesizing test cases in symbolic real-time testing

Abstract

Test synthesis (or test generation) can be described as follows: from a formal specification of an implementation under test (IUT), and from a test purpose describing behaviors to be tested, the aim is to synthesize test cases to be executed in order to check whether the IUT conforms to its formal specification, while trying to control the IUT so that it satisfies the test purpose. In this paper, we study the synthesis of test cases for symbolic real-time systems. By symbolic, we mean that the specification of the IUT contains variables and parameters. And by real-time, we mean that the specification of the IUT contains timing constraints. Our method combines and generalizes two testing methods presented in previous work, namely: 1) a method for synthesizing test cases for (non-symbolic) real-time systems, and 2) a method for synthesizing test cases for (non-real-time) symbolic systems.

Test cases synthesis; real-time test; symbolic test; timed input output symbolic automata; test architecture


ARTICLES

On synthesizing test cases in symbolic real-time testing

Ahmed Khoumsi

University of Sherbrooke, Dep. GEGI, Sherbrooke J1K2R1, CANADA. Ahmed.Khoumsi@USherbrooke.ca

ABSTRACT

Test synthesis (or test generation) can be described as follows: from a formal specification of an implementation under test (IUT), and from a test purpose describing behaviors to be tested, the aim is to synthesize test cases to be executed in order to check whether the IUT conforms to its formal specification, while trying to control the IUT so that it satisfies the test purpose. In this paper, we study the synthesis of test cases for symbolic real-time systems. By symbolic, we mean that the specification of the IUT contains variables and parameters. And by real-time, we mean that the specification of the IUT contains timing constraints. Our method combines and generalizes two testing methods presented in previous work, namely: 1) a method for synthesizing test cases for (non-symbolic) real-time systems, and 2) a method for synthesizing test cases for (non-real-time) symbolic systems.

Keywords: Test cases synthesis, real-time test, symbolic test,timed input output symbolic automata,test architecture.

1. INTRODUCTION

Testing is an essential step in the design of software systems, and conformance testing [1] is one of the most rigorous testing techniques. The objective of conformance testing is to determine whether the IUT respects a formal specification of the desired behavior of the IUT. The notion of conformance relation is used in order to define rigorously what we mean by "respects". In the sequel, the term testing means conformance testing. The main test activities consist of: synthesizing (or generating) test cases from the specification, and executing them on the IUT. We study both activities by proposing: a synthesis method, as well as an architecture for the execution of the synthesized test cases. Among existing work on testing, we are essentially interested by the following two complementary works:

Real-time testing (or test of real-time systems): the specification of the IUT contains order as well as timing constraints of the interactions between the IUT and its environment. This is the case for example of many safety-critical applications, such as patient monitoring systems and air traffic control systems. Several real-time testing methods have been developed in the last years [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12].

Symbolic testing (or test of symbolic systems): the specification of the IUT contains variables and parameters. This is the case for example of most industrial softwares. A few symbolic testing methods have been developed [13, 14, 15]. These methods aim at avoiding the synthesis of test cases where all variables are instantiated. Note that symbolic techniques have also been developed in other areas than testing, e.g., model-checking [16] and diagnosis [17].

This paper is motivated by the fact that each of the above two types of testing is unsatisfactory when the IUT is both real-time and symbolic. And our objective is indeed to propose a test synthesis method which combines the two types of testing. That is, the method to be developed can be used to synthesize test cases for real-time systems without instantiating their variables (i.e., without enumerating all the possible values of variables). We first define the model of timed input output symbolic automata (Tiosa), that adds time to the IOSTS model of [13] and is used to model the specification of the IUT. We use a two-step synthesis method:

Step 1: we express the test problem into a non-real-time form, by transforming a Tiosa into an automaton called Set-Exp-IOSA (SEiosa). SetExp denotes the transformation, and SetExp(A) is the SEiosa obtained by applying SetExp to a Tiosa A.

Step 2: we adapt the non-real-time symbolic test method of [13].

An advantage of our method is its simplicity, due to the fact that the main treatment of the real-time aspect is concentrated into the first step. A short and incomplete version of this paper has been published in [18]. In Sect. 7 we will indicate the contributions of the present paper w.r.t. [18].

The rest of the paper is structured as follows. Sect. 2 describes the Tiosa model used to describe the specification of the IUT. In Sect. 3, we define formally the test problem to be solved. Sect. 4 introduces the SEiosa model and the transformation "SetExp : Tiosa → SEiosa". In Sect. 5, we propose a test architecture. Sect. 6 presents a method based on SetExp that solves the test problem. In Sect. 7, we conclude the paper. And finally, follows an appendix containing proofs of all lemmas and propositions.

2. TIMED IOSA (Tiosa)

In this section, we present timed input output symbolic automata (Tiosa) used to model the IUT and its specification. Tiosa is a combination of timed automata of [11] and input output symbolic transition systems (IOSTS) of [13].

2.1 CLOCKS AND RELATED CONCEPTS

A clockci is a real-valued variable that can be reset (to 0) when an action occurs and such that, between two resets, its derivative (w.r.t. time) is equal to 1. Let = H{c1,... ,cNc} be a set of clocks.

A Clock Guard (CG) is a conjunction of formula(s) in the form "ci ~ k", where ci ∈, ~∈{<,>,<,> ,=}, and k is a nonnegative integer. A CG can be the constant True (empty conjunction). Let ΦH be the set of CGs using clocks of H.

A clock reset is a (possibly empty) subset of H, and 2H is the set of clock resets.

2.2 DATA AND RELATED CONCEPTS

A variable is a data whose value can be set when an action occurs. Let V be a set of variables.

A constant is a data whose value is set once at initial time. Let C be a set of constants.

A communication parameter (or more briefly, a parameter) is a data which is transmitted as a parameter of an action. Let P be a set of parameters.

A Data Guard (DG) is a boolean expression using data of D = VCP. Let be the set of data guards (we consider that True).

A Variable Assignment (VA) is a (possibly empty) set of assignments v := E, where vV and E is an expression depending on D. Let ΛD be the set of VAs.

Let also Type(x) denote the domain of definition of x ∈ D.

2.3 SYNTAX OF Tiosa

A Tiosa is defined by , where: is a finite set of locations, l0 is the initial location, H is a finite set of clocks, D = VC ∪ P is a finite set of data, is a boolean expression depending of VC called initial condition, Σ is a finite set of actions, and is a transition relation. There are three kinds of actions: the reception of an input, the sending of an output, and the occurrence of an internal action. In the sequel, these three kinds of actions will be abbreviated by "input", "output" and "internal action", respectively. To each input or output a ∈ Σ is associated a (possibly empty) tuple (p1,... ,pk) of parameters denoted θa. Signature of a is denoted Sig(a) and defined as follows:

We will use the following notation for actions: an input i containing a tuple θi is written ?ii), an output o containing a tuple θo is written !o(θo), and an internal action a (without tuple) is written εa. θi and θo are omitted when empty. Inputs and outputs are observable, whereas internal actions are unobservable.

A transition of Tiosa is defined by Tr = , where: q and r are origin and destination locations; σ is an action in the form ?i, !o or εa; θσ is the (possibly empty) tuple of parameters associated to σ; CG and Zσ are a clock guard and a clock reset; and DG and VA are a data guard and a variable assignment defined in .1 1 Note that DG and VA of a transition Tr = are defined in V ∪ C ∪ θσ and not in the whole D = V ∪ C ∪ P. The index σ in Zσ means that the clock reset of a transition depends only on its action, that is, all transitions with the same event will also have the same clock reset. This restriction guarantees determinizability of Tiosa [11].

Fig. 1 illustrates the definition of Tiosa through an example. Locations are represented by nodes, and a transition Tr = is represented by an arrow linking q to r and labeled in 3 lines by: σ(θσ), (CG;Zσ) and (DG;VA). The CG and DG True and the absence of Zσ or VA are indicated by "-". x,p,m are integers, . Φ cannot be an internal action because it contains parameter m, and the other actions can be of any type.


2.4 SEMANTICS OF Tiosa

At time τ0 = 0, the Tiosa A = is at location l0 with all clocks equal to 0, and variables and constants taking values such that evaluates to True. A transition Tr = of A is enabled when q is the current location and both CG and DG evaluate to True; otherwise, Tr is disabled. From this location q, the action σ (containing parameters of θσ) can be executed only when Tr is enabled2 2 But when Tr is enabled, σ is not necessarily executed. ; and after the execution of σ: location r is reached, the clocks in Zσ (if any) are reset, and the assignments in VA (if any) are applied.

For the example of Fig. 1, let δu,v be the delay between actions u and v:

• The Tiosa is initially in location l0. At the occurrence of Φ(m), location l1 is reached and variable x is assigned with the value of m.

• From l1, the Tiosa reaches l2 at the occurrence of α.

• From l2, the Tiosa reaches l3 or l4 at the occurrence of β. l3 is reached only if δα,β < 3 and x > p, and l4 is reached only if δα,β > 2 and x < p. We see that there is a nondeterminism when 2 < δα,β < 3 and x = p. x is incremented when l4 is reached.

• From l3, the Tiosa executes nothing.

• From l4, the Tiosa reaches l1 at the occurrence of ρ. We have δα,ρ > 3.

The semantics of a TiosaA can also be defined by the set of timed traces accepted by A. Here are a few necessary definitions:

A timed action is a pair (e,τ) where e is an action and τ is the instant of time when e occurs. When e is an input (resp. output, internal) action, then (e,τ) is called timed input (resp. timed output, timed internal) action.

A timed sequence is a (finite or infinite) sequence of timed actions "(e11)... (eii)...", where 0 < τ1 <... < τi <....

A timed trace is obtained from a timed sequence by removing all its timed internal actions.

Acceptance of a timed sequence λt = (e11)(e22)..., for e1,e2, ... ∈ Σ. Let n be the length of λt (n can be infinite), and λti = (e11)... (eii) be the prefix of λt of length i, for 0 < i < n (i is finite). λt is accepted by A iff λt is the empty sequence λt0 or A has a sequence of length n of consecutive transitions Tr1Tr2 ... starting at l0 and such that ∀i = 1,2,... ,n: the action of Tri is ei and, after the execution of λti-1, Tri is enabled at time τi. Intuitively, λt corresponds to an execution of A.

Acceptance of a timed trace: Let μt = (e11)(e22)... be a timed trace. μt is accepted by A iff μt is obtained by removing all the timed internal actions of a timed sequence accepted by A. Intuitively, μt corresponds to the observation of an execution of A.

We can now introduce the notion of timed observable language of a Tiosa:

Definition 2.1The Timed observable language of a Tiosa A is the set of timed traces accepted by A. That is, models the observable behavior of A.

The class of Tiosa that we will consider obeys to the following hypothesis:

Hypothesis 2.1 Infinite timed sequences accepted by a TiosaA are non-zeno, i.e., an infinite number of actions cannot be executed into a finite time interval.

Remark 2.1 Unlike [19], with our model, consecutive actions cannot occur at the same time. We think that this is not a restriction, because we consider that if an action e is followed an action f, then e and f are not simultaneous.

3 TEST PROBLEM TO BE SOLVED

In order to clarify the test problem to be solved, we need to define formally a conformance relation between Tiosa and the notion of test purpose. A test hypothesis is also necessary.

3.1 CONFORMANCE RELATION BETWEEN Tiosa

Let I and S denote two Tiosas over the same alphabet Σ. We define the following conformance relation I confTiosaS, where λ is a timed trace, "." stands for concatenation, o is an output action of Σ and τ is its occurrence time:

Definition 3.1 I confTiosaS is read "I conforms to S" and means: ,

The intuition of "I confTiosa S" is that after an execution of the IUT (modeled by I ), the IUT can generate an output o at time τ only if S accepts o at time τ.

In order to give a simpler definition of confTiosa, we will first define the input-completion of Tiosa. Let Σ? be the set of inputs of the alphabet Σ, and Univ be the "universal" Tiosa accepting all the timed traces over Σ. That is, TOLTiosaUniv contains every timed trace over Σ. The following definition is inspired from [20, 21].

Definition 3.2The input-completion of a TiosaA = is a TiosaInpComp(A) that contains all the timed traces of A, as well as all the timed traces that diverge from the timed traces of A by executing inputs not accepted by A. Formally, InpComp(A) is a Tiosasuch that:

A is said input-complete iff A = InpComp(A). Intuitively, an input-complete Tiosa accepts every input at any time.

Lemma 3.13 3 Proof in Section A.1 I confTiosaSI confTiosaInpComp(S).

Lemma 3.24 4 Proof in Section A.2 If S is input-complete then: I confTiosaS ⇔ TOLTiosaI⊆ TOLTiosaS .

Lemma 3.1 implies that we can replace a TiosaS by its input-completion before checking if a TiosaI conforms to it, w.r.t. confTiosa. Lemma 3.2 means that if S is input-complete, then confTiosa is simplified into an inclusion of timed observable languages of Tiosa. Based on these two lemmas, an interesting approach would be to check I confTiosaInpComp(S) instead of I confTiosaS. However, Def. 3.2 is not constructive and we do not know how to compute InpComp(S)) from a TiosaS in the general case. Hence, we will use the following hypothesis:

Hypothesis 3.1 In "I confTiosa S", we assume S input-complete.

Note that Lemma 3.1 and Hyp. 3.1 are inspired from their non-real-time and non-symbolic (i.e., without clocks and data) version in [20].

Remark 3.1 In the simple case where S has no internal action and is deterministic, its input-completion can be simply computed as follows:

1. A trap TL is added to S; by trap we mean a location such that for every action σ, TL has a self-loop transition . That is, when a trap is reached, then it is never left and every action is executable from it at any time.

2. For every location l and every input i of S, a non-specified transition is added to S; by non-specified we mean that the guards CG and DG define the domain in which i is not enabled in l of S.

Therefore, Hyp. 3.1 is not restrictive when we are in the case of Remark 3.1. There exist many real examples in this case. But we agree that there are also many real examples containing internal actions. For these examples, we can try to input-complete the specification manually by using our intuition, but we have no guarantee of success. This issue is being studied presently.

3.2 TEST PURPOSE, AND TEST HYPOTHESIS

In order to define test purpose, let us first define the notion of completeness:

Definition 3.3 A Tiosa A = is said to be complete iff: , e is enabled in l for every possible clock value and data value. Intuitively, a complete Tiosaaccepts every (input, output or internal) action at any time.

Definition 3.4 A test purpose is a TiosaTP used to select the behaviors to be tested. By analogy with [22, 13, 11], TP is complete, deterministic, and equipped with two sets of trap5 5 The notion of trap has been defined in Remark 3.1 locations A and R (for Accept and Refuse). Timed Sequences to be considered in testing activity are those terminating in and not traversing a location A, whereas timed sequences to be ignored are those terminating in or traversing a location R.

In the above Def. 3.4, by complete, we mean that TestPurp accepts every (input, output, and internal) action at any time. A test purpose should be simple because the objective of its use is to select a relatively small part of the specification in order to concentrate only in certain aspects (e.g., scenarios, properties) of the specification. Ideally, a test purpose should correspond exactly to what the user has in mind to test. Generally, this intention is defined by scenarios (i.e., executions) or by properties (i.e. formulas, e.g. in temporal logic). We have selected Tiosa to describe test purposes; this model gives enough expressiveness for describing test purposes defined by scenarios with timing constraints and variables. For test purposes defined by a property, we will need to construct the Tiosa that allows to check the given property. This process is in general iterative: a first Tiosa is constructed grossly and is refined repeatedly.

We will also use the following test hypothesis inspired from [23]:

Hypothesis 3.2The behavior of theIUTcan be described by a (possibly unknown) input-complete Tiosa.

We think that Hyp. 3.2 is realistic because the model of Tiosa is sufficiently rich for modeling many real-time discrete event systems using parameters.

3.3 CLARIFICATION OF THE TEST PROBLEM

We can now state our objective: Given two TiosaS Spec and TP over the same alphabet, modeling the specification and the test purpose respectively, the aim is to synthesize an automaton CTG (Complete Test Graph) and then to extract test cases from CTG.

The test cases are intended to be executed on the IUT in order to check whether confTiosaSpec. We assume Spec input-complete (see Hyp. 3.1). CTG is an interesting automaton because it contains all test cases of Spec leading to locations A of TP.

The test system takes into account TP by ignoring every execution λ of the IUT accepted by Spec and such that: a location R of TP may be reached by λ, or no location A of TP is reachable after λ by Spec.

4. TRANSFORMATION Of Tiosa INTO SEiosa

Our test problem will be solved in Sect. 6 by using a transformation, called SetExp, that is described in detail in [24] and applied in [10, 11, 25, 26, 27]. In these references, SetExp basically transforms a timed automaton (TA) into a finite state automaton by adding to the structure of the TA two additional types of actions: Set and Exp, that capture the temporal aspect of the TA. In the present article, we apply SetExp to Tiosa instead of TA. When applying SetExp to Tiosa, the semantics of data and their DG and VA is ignored, that is, they are processed just like action labels. Their semantics is taken into account when using (interpreting, processing, . . . ) the automaton called SEiosa that results from SetExp. In this Section, we present the SEiosa model and illustrate SetExp by an example. Let A be a Tiosa over an alphabet Σ and SetExp(A) be the SEiosa obtained by applying SetExp to A.

4.1 ACTIONS Set AND Exp

Set(ci,k) means: clock ci is reset (to 0) and will expire when ci evaluates to k. And Set(ci,k1,k2, ... ,kp), k1 < k2 <... < kp, means that ci is reset and will expire several times, when its value is equal to k1,k2,... ,kp, resp.

Exp(ci,k) means: clock ci evaluates to k and thus expires.

Therefore, Set(ci,k) is followed (after a delay k) by Exp(ci,k), and Set(ci,k1,k2,... ,kp) is followed (after delays k1,... ,kp) by Exp(ci,k1), Exp(ci,k2),... ,Exp(ci,kp). When a Set(ci,m) occurs, then all Exp(ci,*) which were expected before this Set(ci,m) are canceled.

4.2 BASIC PRINCIPLE OF SetExp

In a TiosaA, a clock c is reset with the objective to compare later its value to (at least) one constant, say k. The action Set(c,k) is very convenient for that purpose, because it resets c and programs Exp(c,k) which is a notification that c evaluates to k. When applied to a TiosaA, SetExp is realized in two steps as follows:

Step 1: To replace each clock reset in A by the appropriate Set action.

Step 2: To construct a finite state automaton, denoted SetExp(A), that accepts sequences containing actions of A and Set actions obtained in Step 1 and the corresponding Exp actions, and such that the order of actions in each accepted sequence respects order and timing constraints of A.

In order to illustrate SetExp by a trivial example, let us consider the following two specifications. Specification 1: a task must be realized in less than two units of time. Specification 2: at the beginning of the task an alarm is programmed so that it occurs after two time units, and the task must be terminated before the alarm. Clearly, these two specifications define the same timing constraint. Intuitively, SetExp generates the second specification from the first one. The programming of the alarm corresponds to a Set action, and the occurrence of the alarm corresponds to an Exp action.

4.3 Transitions of SEiosa

We have seen in Sect. 2 that a transition of Tiosa is defined by and is represented in a figure by an arrow linking q to r and labeled by: σ(θσ), (CG;Zσ) and (DG;VA). Let: η be an action of the alphabet Σ of the TiosaA with its parameters, S (resp.ε) be a set of Set (resp. Exp) actions, and occurrence of S(resp.ε) mean the simultaneous occurrences of all the actions in S(resp.ε). Transitions of the SEiosaSetExp(A) can be categorized into three types as follows:

Type 1: a transition labeled (ε) represents the occurrence of ε.

Type 2: a transition labeled by (η) or (η,S), and by a DG and a VA. (η) represents the occurrence of η, (η,S) represents the simultaneous occurrences of η and S, and DG and VA have the same semantics as in Tiosa. A transition TR of Type 2 in the SEiosaSetExp(A), corresponds to a transition Tr of A such that: Tr and TR have the same η and DG and VA, and Tr resets the clocks in the S(if any) of TR.

Type 3: transition labeled by (ε,η) or (ε,η,S), and by a DG and a VA. (ε,η) represents the simultaneous occurrences of ε and η, and (ε,η,S) represents the simultaneous occurrences of ε,η and S. A transition TR of Type 3 in the SEiosaSetExp(A) corresponds to simultaneous executions of ε and a transition Tr of A such that: Tr and TR have the same η and DG and VA, and Tr resets the clocks in the S (if any) of TR.

Remark 4.1 A transition of type 3 corresponds to the simultaneity of two transitions of type 1 and 2, respectively.

Definition 4.1An Exp-Trans of SetExp(A) is a transition of type 1 or 3, i.e., whose label contains one or several Exp actions.

4.4 TWO EXAMPLES OF APPLICATION OF SetExp : Tiosa SEiosa

4.4.1 Example 1: We illustrate here SetExp by an example without data. We consider the specification: 1 < δ a,b < 3, where δa,b is the delay between actions a and b. In a Tiosa, such a constraint is expressed by: 1) using two transitions Tr1 and Tr2 that represent the occurrences of a and b, respectively; 2) resetting a clock c at the occurrence of Tr1; and 3) associating to Tr2 the clock guard (CG): ((c > 1) ∧ (c < 3)). This timing constraint can be expressed differently as follows: i) the reset "c := 0" of Tr1 is replaced by a Set(c,1,3) (which will be followed by Exp(c,1) and Exp(c,3)), and ii) the CG "((c > 1) ∧ (c < 3))" of Tr2 becomes "Tr2 occurs after or simultaneously to Exp(c,1) and before Exp(c,3)". This timing constraint will be represented in a SEiosa by the following two sequences, where consecutive actions are separated by "·" and simultaneous actions are grouped in "<>".):

•

•

4.4.2 Example 2: For the TiosaA of Fig. 1, we obtain the SEiosaSetExp(A) of Fig. 2, where Set2,3 is an abbreviation of ?Set(c1,2,3), Expi is an abbreviation of !Exp(c1,i) for i = 2,3, x++ means "x is incremented by 1", and the constant DG True and the absence of VA are indicated by "-". Transitions of Type 1 are those labeled Expi. Transitions of Types 2 and 3 are labeled in two lines, where Line 2 consists of (DG;VA). Transitions of Type 2 are those labeled Φ(m), (α,Set2,3), β or ρ in Line 1. Transitions of Type 3 are those labeled (Expi,β) in Line 1, and correspond to the simultaneous executions of Expi and β. We do not indicate whether each action Φ(m), α, β or ρ is an input, an output or an internal action, because this aspect is irrelevant for the comprehension of SetExp.


Remark 4.2 Clocks are real-valued variables although they are compared to (nonnegative) integers, the latter being considered just as particular reals. SetExp remains applicable if clocks are compared to reals.

4.5 SYNTAX OF SEiosa

Let A = be a Tiosa and B = SetExp(A) be the corresponding SEiosa. The syntax of B can be defined by B = , where: is a finite set of states, q0 is the initial state, Λ is a finite alphabet that labels the transitions of B, Ψ is a transition relation, and D and are the same as those used in the definition of A (see Sect. 2.3). A transition of B is syntactically defined by TR = , where: q and r are origin and destination states; μ consists of the action(s) of TR; and DG and VA are a data guard and a variable assignment. DG and VA are always empty for transitions of Type 1 (see Sects. 4.3 and 4.4). Λ is an alphabet consisting of labels of transitions of types 1, 2 and 3 (see Sect. 4.3).

4.6 SEMANTICS OF SEiosa

Initially, the SEiosaB = is at state q0 with all clocks of H equal to 0, and variables and constants taking values such that 6 6 H is the set of clocks of the T iosa A such that B = SetExp( A). evaluates to true. A transition TR = is enabled when q is the current state and DG (if any) evaluates to true; otherwise, TR is disabled. From this state q, μ (consisting of one or more actions) is executed only when TR is enabled; and after the execution of μ: State r is reached, and the assignments in VA (if any) are applied.

Let sequence of SEiosa denote a sequence "E1E2...", where E1,E2,... ,∈ Λ; and let a trace of SEiosa be obtained from a sequence of SEiosa by removing all its internal actions. The semantics of a SEiosaB = can also be defined by the set of sequences and traces accepted by B:

Acceptance of a (finite or infinite) sequence

λ = E1E2 ..., for E1,E2, ∈Λ. Let n be the length of λ (n can be infinite), and λi = E1E2...Ei be the prefix of λ of length i, for 0 < i < n (i is finite). λ is accepted by B iff :

• either λ is the empty sequence λ0;

• or there exists a sequence of transitions Tr1Tr2... of B of length n such that ∀i = 1,2,... ,n: Tri is labeled by Ei and, after the execution of λi-1, Tri is enabled.

Intuitively, λ corresponds to an execution of B.

Acceptance of a trace μ: μ is accepted by B iff μ is obtained by removing the internal actions of a sequence accepted by B. Intuitively, μ corresponds to the observation of an execution of B.

We can now introduce the notion of Observable Language of a SEiosa:

Definition 4.2The observable language of a SEiosaB ( ) is the set of traces accepted by B. That is, OLSEiosa B models the observable behavior of B.

Note that OLSEiosa B implicitly respects the following Consistency condition: every Set(c,k) and its corresponding Exp(c,k) are effectively separated by time k.

We define the following conformance relation confSEiosa relating two SEiosaS:

Definition 4.3Let I' and S' be two SEiosaS over the same alphabet: I' confSEiosa S' ≡ .

We terminate this section by presenting a fundamental property of SetExp. Let TL = AddTime(L) be a timed language obtained from a language L by associating a time to each action such that the consistency condition is respected. Let RmvSetExp(TL) be obtained from a timed language TL by removing all the Set and Exp actions, if any. We have the following proposition of equivalence:

Proposition 4.1 7 7 Proof in Section C

Intuitively, Proposition 4.1 states that from a behavioral point of view, there is no difference between A and SetExp(A) for an observer who does not see (or ignores) Set and Exp actions. In a sense, SetExp(A) does nothing but add some new actions (Set and Exp) to A that capture the relevant temporal aspect of A. As we will see in the next section, in our test method these Set and Exp are physical actions that are produced by the test system.

5. TEST ARCHITECTURE, AND A PROPOSITION

Given two Tiosas Spec and TP over the same alphabet, we have clarified in Sect. 3.3 that our objective is to synthesize an automaton CTG (Complete Test Graph) from which test cases are extracted. The latter are intended to be executed in order to study the conformance of the IUT to the part of Spec corresponding to TP. CTG will not be directly computed on the Tiosas Spec and TP, but rather on a SEiosa computed from the two Tiosas. In order to make the link between CTG and the IUT, we use the test architecture represented in Fig. 3 and proposed in [11]. It comprises the IUT, a Tester, and a Clock-Handler that mimics the timing aspect of the IUT. More precisely, we have:

Clock-Handler receives Set actions from the Tester and sends Exp actions to the Tester. It respects the consistency condition (see end of Sect. 4.6). It can be seen as a Timer module that upon the reception of a Set action, activates a timer and sends back to the Tester the corresponding Exp action when the timer elapses. Note that Clock-Handler guarantees the consistency condition, i.e., Set(c,k) and the corresponding Exp(c,k) are separated by time k.

Tester executes test cases that are derived from a SEiosa and is tagged with the Set and Exp actions of this SEiosa. It sends the inputs and receives the outputs of the IUT, it also sends Set actions to Clock-Handler and receives Exp actions from Clock-Handler. The timing constraints that the Tester has to deal with are performed via its interaction with the Clock-Handler module.


Here are a few necessary notations:

Notation 5.1 If L is a language, then denotes the prefix of L. That is, contains every finite sequence that is a prefix of a sequence contained in L.

Notation 5.2 Testermeans that during a test execution, the Tester generates only Set actions that are accepted by the SEiosaK. More formally, it means:

action ofIUT, ∀U set of Set actions: after the execution of λ, the Tester generates S simultaneously to U (if any) iff .

We can now state the next proposition which makes the link between confSEiosa (relating two SEiosas) and the real-time conformance relation confTiosa (relating two Tiosas), where SUT (System Under Test) consists of IUT and Clock-Handler, is the Tiosa modeling IUT, is the SEiosa modeling SUT, and S is a Tiosa:

Proposition 5.1 Tester SetExp(S) implies:

confTiosa S ⇔ (∃ SEiosa accepting behavior of SUT s.t. confSEiosa SetExp(S).

The above proposition implies that we can check " confSEiosa SetExp(S)" instead of " confTiosa S". We have transformed the test of a real-time symbolic system into a non-real-time form, and thus, we can (and will) adapt a non-real-time method of Symbolic Test Generation (STG) [13].

Here is a simple example that gives the intuition of Prop. 5.1. S specifies that a task is realized in less than two units of time. SetExp(S) specifies that: i) at the beginning of an alarm is programmed so that it occurs after two units of time, and ii) is terminated before the alarm. The programming (resp. occurrence) of the alarm corresponds to a Set (resp. Exp) action. Tester orders the IUT to start and, simultaneously, programs the alarm by sending a Set(c,2) to Clock-Handler. Tester deduces that IUT has conformed to S iff it receives Exp(c,2) from Clock-Handler after it receives from the IUT the indication that is terminated.

The proposed architecture is applicable only if transitions executing internal (i.e., unobservable) actions do not reset clocks. In fact, in order to generate Set actions, the Tester needs to observe every action to which is associated a clock reset. Hence the following hypothesis meaning that there is no timing constraint relatively to unobservable actions:

Hypothesis 5.1 Transitions executing internal actions do not reset clocks.

We argue that there exist many real examples respecting Hyp. 5.1, because in many cases, timing constraints that interest the user of IUT are defined between actions that (s)he observes.

6. METHOD OF TEST GENERATION

Let us propose a test method that can be used to synthesize test cases for real-time systems without enumerating all the possible values of their variables. The proposed method combines, and thus extends, two complementary test methods: 1) a test method applicable to (non-symbolic) real-time systems [11], and 2) a test method applicable to (non-real-time) symbolic systems [13]. It consists of five steps outlined in Fig. 4 and described in subsections 6.1 to 6.5. Its inputs are Spec (input-complete, from Lemma 3.1 and Hyp. 3.1) and TP (complete, from Def. 3.4). In a first step, we compute a TiosaSpecTP that accepts (all and only) the timed sequences of Spec and indicates the locations corresponding to the locations A and R of TP. Then, we synthesize in three steps (2 to 4) a complete test graph (CTG), from which test cases are extracted in Step 5. Test cases are intended to be executed on the IUT in order to check whether: confTiosaSpecTP. The indication A and R is used to ignore every execution of the IUT that leads to a location R or from which no location A is reachable. The fact that TP is deterministic and complete implies that Spec is input-complete iff SpecTP is input-complete.


An advantage of our method is its simplicity because the main treatment of the real-time aspect is concentrated in Step 2. Steps 1, 3 and 4 constitute a slight adaptation of the (non-real-time) symbolic test generator (STG) [13].8 8 Actually, STG is a software tool. But here, STG denotes the theoretical method that underlies the tool. Step 5 is inspired from [11].

Spec and TP of Figure 5 will be used to illustrate the five steps of the test method. These two Tiosa are defined over the alphabet Σ= {?Φ,?σ,!ρ,εa,εb}. Data of Spec are H1 = {c1}, V1 = {x},C1 = {p},P1 = {m}, where x,p,m are integers. Data of TP are H2 =V2 =C2 = , P2 = {n}, where n is integer.≠ x means any action of Σ different from x, and ?* means any input ∈Σ (i.e., ?Φ or ?σ). Spec was not initially input-complete and we represent by dotted arrows the part that has been added to make Spec input-complete. Recall that input-completion of Spec is justified by Lemma 3.1, and that we do not know how to compute it in the general case (Def. 3.2 is not constructive). In the particular example of Fig. 5, input-completion of Spec can be computed using Remark 3.1, although Spec contains internal actions. Transitions labeled only by an action mean that: their (clock and data) guards are equal to the constant True, and they do not reset clocks and do not have variable assignments.


The TP of this example means that: we intend to test executions of Spec terminating by the first occurrence of !ρ in Spec (i.e. without traversing Location TL). This example of TP is taken very simple (with one parameter and no timing constraint) in order to clarify the operations of the different steps. Recall that generally, TP should be relatively simple because the objective of its use is to select a relatively small part of the specification in order to concentrate only in certain aspects (e.g., scenarios, properties) of the specification. A simple test purpose defined by scenarios can be easily modeled by Tiosa. In the presence of a test purpose defined by a property P , we need to transform P into a Tiosa in an iterative way: a first Tiosa is constructed grossly and is refined repeatedly.

6.1 Step 1 : Compute the synchronous product of Spec and TP

We compute a TiosaSpecTP that is observationally equivalent to Spec (i.e., ), but SpecTP contains locations indicated by A (resp. R) that correspond to locations A (resp. R) of TP. For that purpose, we need to define the synchronized product of two Tiosas. Let Ai = where , for i = 1,2, be two Tiosas. The synchronized product of A1 and A2, written A1 A2, is inspired (but different) from the synchronized product of TA [28] and the synchronized product of IOSTS [13]. A1A2 is defined iff the following four conditions are satisfied:

1. Σ1 = Σ2. The common alphabet will then be denoted Σ. This condition can be easily relaxed [13], but we will keep it for simplicity.

2. [28].

3. [13].

4. Each action a ∈ Σ has the same signature in A1 and A2 [13].

Assuming the above four conditions satisfied, A1 A2 is defined by such that: and the set of transitions is defined as follows: For each pair of transitions i = 1,2:

If θσ1and θσ2are the empty tuple ε: then there exists a transition .

If θσ1and θσ2are not empty: let DG1,2 (resp. VA1,2) denote the expression obtained by replacing in DG2 (resp. VA2) each parameter from θσ2 by the corresponding, same-position parameter from θσ1; then there exists a transition .

Note that we can also proceed symmetrically by defining DG2,1 and VA2,1, instead of DG1,2 and VA1,2.

This procedure is inspired from [13].

In Step 1, we compute SpecTP = SpecTP, from which we remove the (unreachable) locations without incoming transitions.

Completeness of TP implies that Spec and SpecTP are observationally equivalent (i.e., . Completeness of TP and input-completeness of Spec imply that SpecTP is input-complete. The effect of SpecTP is to determine in Spec all the executions that correspond to locations A and R, respectively.

For Spec and TP of Fig. 5, we obtain the SpecTP of Fig. 6. Locations L1 and A1 are equivalent in the sense that the same behavior can be produced from them. The difference between these two locations is that only A1 corresponds to Location A of TP. Note that, in accordance with the definition of synchronized product, parameter n of TP has been removed by replacing it by parameter m of Spec. The symmetrical approach consists of removing m, instead of n.


6.2 Step 2 : TRANSFORMING THe TiosaSpecTP INTO SEiosa

We transform the problem into a non-real-time form by computing SpecTPSEiosa = SetExp(SpecTP). For the SpecTP of Fig. 6, we obtain the SpecTPSEiosa of Fig. 7: ?* denotes any input (i.e., ?Φ(m) or ?σ); Σ means any action x ∈ Σ = {?Φ(m),?σ,!ρ,εa,εb}; Set2,3 denotes ?Set(c1,2,3); Expi denotes !Exp(c1,i) for i = 2,3; (Expi,Σ) means the simultaneous occurrence of Expi and any x ∈ Σ; nodes linked by a dotted line correspond to the same location9 9 They are duplicated for the sake of clarity. ; and states that correspond to location A (resp. R) of SpecTP are indicated by A (resp. R). State A1 is equivalent to State S1 with the difference that S1 does not correspond to a location A of TP. We have not represented the states reachable from A1 because the sequences to be tested are those terminating in and not traversing a state A. In Fig. 7 and subsequent figures, if DG evaluates to true and VA is empty in a transition (of Type 2 or 3), then (DG;VA) is not represented.


6.3 Step 3 : EXTRACTING THE OBSERVABLE BEHAVIOR OF SpecTPSEiosa

We construct the observable behavior of SpecTPSEiosa in three substeps:

Substep 3a: Internal actions are eliminated by projection into the observable alphabet. For that purpose, we can adapt a procedure proposed in [13]. The result is denoted Obs(SpecTPSEiosa ). The adaptation consists of a preliminary step where internal actions in transitions of Type 3 are simply erased. After that, we can use the procedure of [13] because the remaining internal actions are "alone" in their transitions (of type 2). (Recall that we consider only the case where internal actions do not reset clocks.)

Substep 3b:Obs(SpecTPSEiosa ) is determinized by using a heuristic proposed in [13]. The result is denoted Det(Obs(SpecTPSEiosa )).

Substep 3c: Note that every state of Det(Obs(SpecTPSEiosa )) corresponds to one or several states of SpecTPSEiosa . States R and A of Det(Obs(SpecTPSEiosa )) are selected as follows:

• We call R every state corresponding to at least one state R of SpecTPSEiosa. Intuitively, we ignore every execution which can correspond to a sequence not to be tested.

• We call A every state corresponding exclusively to states A of SpecTPSEiosa. Intuitively, we accept an execution only when we are sure that it corresponds to a sequence to be tested.

The result is denoted .

For the SpecTPSEiosa of Fig. 7, after Substep 3a, we obtain Obs(SpecTPSEiosa ) of Fig. 8 where Σo means any observable action x ∈ {?σ,?Φ(m),!ρ}; and after Substep 3c, we obtain of Fig. 9.



6.4 Step 4 : Computing a Complete Test Graph (CTG)

Recall that a transition of SEiosa can be labeled as follows: (ε), (σ), (σ, S), (ε,σ), or (ε,σ,S), (in addition to (DG;VA)). Let:

output transition be any transition labeled in one of the five forms and such that σ is an output of the IUT;

input transition be any transition labeled (σ) or (σ, S) and such that σ is an input of the IUT;

mixed transition be any transition labeled (ε,σ) or (ε, σ, S) and such that σ is an input of the IUT.

We construct a Complete Test Graph (CTG) in a way inspired (but different) from [22, 11, 13] as follows:

• Let L2A be the set of states of that are co-accessible to a location A, i.e., from which a state A is accessible.

• Let Pass be the set of states A of .

• Let Fail = {fail} consist of a new state that is reached by every non-specified output transition of executable from L2A.

• Let Inconc be the set of states of that are not in L2A ∪ Pass and are accessible from L2A by a single output transition of .

• We then obtain CTG from Spec by:

- adding (implicitly) state Fail and its incoming (non-specified output) transitions,

- removing every state ∉ L2APassInconcFail, and

- removing outgoing transitions of every state ∉ PassInconc.

To synthesize test cases executable in acceptable time (that is, to avoid that Tester waits for an output of the IUT during a very long time), we select a delay T and define a fictitious event !δ whose occurrence means: no observable action occurs during a period equal to T. We then proceed as follows:

• we define a new state inconcδInconc, and

• to every state ∉ PassInconcFail in which only output transitions of type 2 can be executed, we add a transition labeled !δ and leading to inconcδ.

The use of !δ and inconcδ can be intuitively explained as follows: in a test execution if nothing happens during time T , then the verdict Inconclusive is generated.

For the Spec of Fig. 9, we obtain the CTG of Fig. 10. Transition !δ in State 4 indicates that nothing has happened during time T, which implies the verdict Inconclusive. For simplicity, Fail and its incoming transitions are not represented; Fail is implicitly reached by every non-specified transition. Note that !δ can be easily implemented by using ?Set(c0,T) and !Exp(c0,T), where c0 is a clock not used for describing timing constraints of Spec and TP.


Correctness of our construction of CTG is stated by the following three lemmas:

Lemma 6.110 10 Proof in Section D.1 When the Tester observes a trace λ of SUT that leads to a state pPass, then the IUT has executed a timed trace μ that conforms to Spec w.r.t. confTiosa (i.e., μ ∈ ) and that leads to a location A of TP.

Lemma 6.211 11 Proof in Section D.2 When the Tester observes a trace λ of SUT that leads to the state fail, then the IUT has executed a timed trace μ that does not conform to Spec w.r.t. confTiosa (i.e., μ ∉ ).

Lemma 6.312 12 Proof in Section D.3 When the Tester observes a trace λ of SUT that leads to the state xInconc, then the IUT has executed a timed trace μ that conforms to Spec w.r.t. confTiosabut no location A of TP can be reached after μ.

6.5 Step 5 : Extracting Test Cases from CTG

The objective of Step 5 is to extract so-called controllable subgraphs of CTG. For that purpose, let us use the following hypothesis:

Hypothesis 6.1 When desired, the Tester is capable of reacting more promptly than the SUT in all situations where both are allowed to send an action to each other.

Hyp 6.1 is reasonable when the SUT is a system with very high computing ressources and a very high clock frequency. Assuming this hypothesis, controllable subgraphs can be extracted from CTG by executing one the following three options for each state of CTG:

• One input transition is kept and all other (input, output, and mixed) transitions are pruned. That is, the Tester sends a given input to the SUT, before the latter has the time to generate an output.

• All output transitions are kept, and all other (input and mixed) transitions are pruned. That is, the Tester sends no input and waits for the reception of any possible output from the SUT.

• One mixed transition T is kept with all the outputs transitions that have not the same ε as T, and all other transitions are pruned. That is, the Tester waits for the reception of a given set of expirations ε1 with the objective to send a given input to the SUT simultaneously to ε1. The input is not sent if Tester receives an output or another ε from the SUT.

Note that this procedure is more complex than procedures in [22, 11] that have inspired us. For the CTG of Fig. 10, we obtain a single controllable subgraph: CTG itself.

7. CONTRIBUTION AND FUTURE WORK

We have proposed a test method that combines two types of testing: real-time testing that consists of testing systems with timing constraints; and symbolic test that consists of testing systems without enumerating values of their data. More precisely, our method combines and extends in a rigorous way the method STG of symbolic testing of [13] and the method of real-time testing of [11]. An advantage of our method is its simplicity because the main treatment of the real-time aspect is concentrated into one step. Since the test method in [11] is a rigorous generalization of TGV [22] to the real-time case, we can say that our method is a rigorous generalization of STG and TGV13 13 Actually, STG and TGV are software tools for testing. But here, STG and TGV denote the theoretical test methods that underly the tools, respectively. to the real-time case. We are optimistic for the applicability of our method because both TGV and STG have led to interesting software tools. But we recognize that such applicability remains to be demonstrated with real world examples.

Theoretically, the method may suffer from state explosion essentially during the synchronized product (Step 1) and the transformation SetExp (Step 2). But in practice, the state explosion is attenuated by the following facts:

For Step 1: TP is relatively simple.

For Step 2: the following two numbers, that influence state explosion, are relatively small: - the number of clocks,

- the number of values to which each clock is compared in timing constraints.

A previous version of his article has been published in [18]. Here are the main contributions of the present paper w.r.t. [18]:

1. All lemmas and propositions are rigorously proved (in the Appendix).

2. New lemmas (6.1, 6.2, 6.3), that state correctness of the test method, are added and proved.

3. The test method contains an additional (fifth) step that extracts test cases from the synthesized Complete Test Graph.

4. Proposition 5.1 is expressed more formally and proved; this proposition is the basis for transforming the test problem into a non-real-time form.

5. The notion of test purpose is presented and explained in more detail.

6. A few errors have been corrected.

Here are some future work directions:

• Our method (as well as STG in [13]) does not support the quiescence aspect, that is used for specifying when the IUT is permitted to stop its execution. We intend to investigate the possibility to fill this gap.

• Our method (as well as other methods of real-time testing) does not support unobservable clock resets. We intend to determine conditions under which our method is applicable in the presence of unobservable clock reset.

• We intend to add the notion of invariants in order to model actions that must occur (instead of being only permitted to occur) when they are enabled.

• Def. 3.2 is not constructive and we do not know how to compute InpComp(S) from a TiosaA in the general case. We have explained how to compute InpComp(S) when S has no internal action and is deterministic. We intend to determine a more general class of Tiosas for which we can construct their input-completion.

• We intend to implement a prototype of the test method in order to study it with real world examples.

A PROOFS OF LEMMAS 3.1 AND 3.2

A.1 PROOF OF LEMMA 3.1:

(I confTiosaS) ⇔ (I confTiosaInpComp(S))

A.1.1 Proof of:

(I confTiosaS) ⇒ (I confTiosaInpComp(S)):

  1. We assume

  2. (I confTiosaS), that is (from Def. 3.1), for any output o and .

    λ ∈ implies:

    , because only inputs (and not outputs) are added to locations of S when InpComp operator is applied to S.

  3. Items 1 and 2 imply that : . Letτλ be the time of the last (observable) event of λ.

    If then, from Def. 3.2, λ = w·x such that: . Therefore: .

  4. Items 4 and 5 imply that

    Items 3 and 6 imply that :

  5. Item 7 means (I confTiosa InpComp(S)).

    QED

A.1.2 Proof of:

(I confTiosa InpComp(S)) ⇒ (I confTiosa S):

    We assume (I confTiosa InpComp(S)), that is (from Def. 3.1), .

  1. .

  2. Items 1 and 2 imply that :

    Item 2 of Sect. A.1.1 and the above Item 3 imply that

  3. Item 4 means (I confTiosa S). QED

A.2 PROOF OF LEMMA 3.2:

A.2.1 Proof of:

: In the following, τλ denotes the time of the last (observable) action of λ.

  1. We assume

    S =

    InpComp(

    S)).

  2. Items 2, 4 and and 5 imply that :

  3. Item 7 means:

    .

    QED

A.2.2 Proof of:

  1. We assume

    .

  2. Item 2 implies: (I confTiosa S).

    QED

B PROOF OF PROPOSITION 4.1

We first need to define symbolic languages of Tiosa and SEiosa.

B.1 SYMBOLIC LANGUAGES OF Tiosa AND SEiosa

In [24], SetExp is used to transform timed automata (TA) into Set-Exp-Automata (SEA), and timed language of a TA A (TLTAA) and timed language of a SEA B are defined as the set of timed sequences accepted by A and B, respectively. Note that if we ignore the semantics of DG and VA in Tiosa and SEiosa, we obtain the models of TA and SEA, respectively.

By analogy with timed language of TA, we define the symbolic timed language of a as the set of timed sequences accepted by A, where in each transition Tr = of A: the semantics of DG and VA is ignored, and (σ(θ);DG;VA) is syntactically processed as an action. That is, a sequence corresponds to a sequence of consecutive transitions Tr1 Tr2 ... Tri ... in A such that:

- Tr1 is a first transition of A (i.e., executable from l0);

- αi consists of σ(θ), DG and VA of Tri; and

- after the execution of a prefix (α11) (αpp) of ξt, the CG of Trp+1 is True at time τp+1.

In the same way, by analogy with timed language of SEA, the symbolic timed language of a SEiosa B () is defined as the set of timed sequences accepted by B, where in each transition Tr = <θ; ρ; μ; DG; VA> of B: the semantics of DG and VA is ignored, and (μ; DG; VA) is syntactically processed as an action. That is, a sequence

ξt = (α11)(α22) (αii) ... corresponds to a sequence of consecutive transitions Tr1 Tr2 ... Tri ... in B such that:

- Tr1 is a first transition of B,

- αi consists of μ, DG and VA of Tri, and

- consistency condition is respected (see Definition in Sect. 4.6).

In [24], it is proved that for a TA A and the corresponding SEA B = SetExp(A), we have: . From the above analogy, we deduce that for a Tiosa A and the corresponding SEiosa B = SetExp(A), we have: S = RmvSetExp().

B.2 TRANSFORMING A SYMBOLIC TIMED LANGUAGE INTO A TIMED LANGUAGE

To a symbolic timed language (STL) corresponds a timed language (TL) defined as follows:

λt = (e11)(e22) ... TL iff

- λt and ξt have the same length n (n can be infinite)

- αi = (ei,DGi,VAi) or αi = ei (in the latter case, DGi = True and VAi is empty),

- ∀i < n: DGi evaluates to True after the application of VA1, VA2, VAi-1.

Let then STL2TL be the operator that transforms STL into TL, (written TL = STL2TL(STL)). Therefore, for a Tiosa A we have = STL2TL (S), and for a SEiosa B we have = STL2TL().

B.3 PROOF THAT:

= RmvSetExp()

  1. In Sect. B.1, we have seen that for every Tiosa A: S

    = RmvSetExp(S

    ).

  2. In Sect. B.2, we have seen that for every Tiosa A:

    = STL2TL(S

    ).

  3. In Sect. B.2, we have seen that for every SEiosa B:

    = STL2TL(

    ).

  4. The order in which operators RmvSetExp and STL2TL are applied has no influence on the result.

  5. Items 1 and 2 imply:

    = STL2TL(RmvSetExp(S

    )).

B.4 PROOF THAT:

= RmvSetExp()

Let A be a Tiosa and B = SetExp(A) be the corresponding SEiosa. The timed observable language of A ( ) is obtained from by removing all the internal actions. And the timed observable language of B ( ) is obtained in the same way from . And let RmvIntern(x) be the operation that removes all internal actions from a timed language. Let us prove that: = RmvSetExp().

  1. = RmvSetExp(

    ).

  2. = RmvIntern(

    )

  3. = RmvIntern(

    ).

  4. The order in which Set and Exp actions and internal actions are removed from a timed sequence, has no influence on the result.

  5. Items 4 and 5 imply:

    = RmvSetExp(RmvIntern(

    )).

  6. Items 3 and 6 imply:

    = RmvSetExp(

    ).

    QED

Proposition 4.1 is obtained by replacing by AddTime() in the above Item 7. QED

C PROOF OF PROPOSITION 5.1

Let S be an input-complete Tiosa, and X, Y be defined as follows:

X:

Y : ∃ SEiosa accepting the behavior of SUT s.t.

From Hyp. 3.1, Lemma 3.2 and Def. 4.3, we deduce that the objective is to prove:

C.1 Proof of: XY

Assuming X and Tester

SetExp(S), the aim is to prove Y. Recall that ξ denotes a set of Exp actions.

Definition C.1The supremal SEiosaof a SEiosaB is denoted SupSEiosa(B) and constructed as follows:

  • Construct Obs(B), the projection of B into the observable alphabet, i.e., internal actions are made invisible.

  • For every internal action ε

    x: add a selfloop labeled ε

    x to every location of Obs(B).

  • For every internal action ε

    x and every transition of type 1 (i.e, labeled in the form ε

    ) from a location q to a location r: add another transition of type 3 labeled (ε,ε

    x) from q to r.

Note that by construction, = , = T,

, and = .

  1. Item 3 and

  2. Item 4 and Tester

    SetExp(S) imply that

  3. SUT

From X and (Tester SetExp(S)), we have determined a SEiosa that accepts the behavior of SUT and s.t. = . Therefore, we have Y.

C.2 PROOF OF: Y X

Let RmvTime(x) be the operation defined as follows:

if λ = (e11)(e22) (eii), then RmvTime(λ) = e1e2…ei….

  1. We consider λ ∈

    .

  2. RmvSetExp
  3. The existence of

  4. SUT

From Y and Item 1, we have deduced Item 8. Therefore, we have X. QED

D. PrOOFS OF LEMMAS 6.1, 6.2 AND 6.3

Let SpecTPA denote the part of SpecTP (obtained in Step 1) that leads to a location A, and A denote the part of SpecTPSEiosa (obtained in Step 2) that leads to a state A.

D.1 PROOF OF LEMMA 6.1

    SUTpPassconfSEiosaSUTpPassIUTconfTiosaSpecTPASUTpPassIUT confTiosaSpecTPSUTpPassIUTconfTiosaSpecSUTpPassIUTATP
  1. Items 4 and 5 imply Lemma 6.1.

    QED

D.2 PROOF OF LEMMA 6.2

    SUTconfSEiosa SpecTPSEiosaSUTfailIUTconfTiosaSpecTPSUTIUTSpecQED

D.3 PROOF OF LEMMA 6.3

    SUTInconcSpecTPSEiosaASUTInconcIUTconfTiosaSpecTPASUTInconcIUTconfTiosaSpecAQED
  • [1] ISO/IEC. International Standard 9646-1/2/3, OSI-Open Systems Interconnection, Information Technology - Open Systems Interconnection Conformance Testing Methodology and Framework, 1992.
  • [2] D. Clarke. Testing real-time constraints PhD thesis, Department of Computer and Information Science, University of Pennsylvania, USA, 1996.
  • [3] J. Springintveld, F. Vaandrager, and P. D'Argenio. Testing timed automata. Technical Report CTIT97-17, University of Twente, Amsterdam, The Netherlands, 1997.
  • [4] V. Braberman, M. Felder, and M. Massé. Testing timing behaviors of real time software. In Proc. Quality Week 1997, pages 143-155, San Francisco, USA, April-May 1997.
  • [5] J. Peleska, P. Amthor, S. Dick, O. Meyer, M. Siegel, and C. Zahlten. Testing reactive real-time systems. In Proc. Mater. for the School-5th Intern. School and Sympos. on Form. Technique in Real-Time and Fault-Toler. Syst. (FTRTFT), Lyngby, Denmark, 1998.
  • [6] A. En-Nouaary, R. Dssouli, F. Khendek, and A. Elqortobi. Timed test generation based on state characterization technique. In Proc. 19th IEEE Real-Time Systems Sympos. (RTSS), Madrid, Spain, December 1998.
  • [7] B. Nielsen. Specification and test of real-time systems PhD thesis, Dept of Comput. Science, Faculty of Engin. and Sc., Aalborg University, Aalborg, Denmark, 2000.
  • [8] R. Cardell-Oliver. Conformance testing of real-time systems with timed automata. Formal Aspects of Computing, 12:350-371, 2000.
  • [9] R. Cardell-Oliver. Conformance testing of real-time systems with timed automata. In Nordic Workshop on Programming Theory, October 2000.
  • [10] A. Khoumsi. A method for testing the conformance of real time systems. In Proc. 7th Intern. Sympos. on Formal Techn. in Real-Time and Fault Toler. Systems (FTRTFT), Oldenburg, Germany, September 2002.
  • [11] A. Khoumsi, T. Jéron, and H. Marchand. Test cases generation for nondeterministic real-time systems. In Proc. Formal Approaches to TEsting of Software (FATES), LNCS 2931, Montreal, Canada, October 2003. Springer.
  • [12] M. Krichen and S. Tripakis. Black-box conformance testing for real-time systems. In Proc. Model Checking Software: 11th Int. SPIN Workshop, LNCS 2989 Springer-Verlag, 2004.
  • [13] V. Rusu, L. du Bousquet, and T. Jéron. An approach to symbolic test generation. In Int. Conf. on Integrating Formal Methods (IFM), pages 338-357, Dagstuhl, Germany, 2000. LNCS 1945.
  • [14] V. Rusu. Verification using test generation techniques. In Formal Methods Europe (FME), pages 252-271. LNCS 2391, 2002.
  • [15] D. Clarke, Thierry Jéron, V. Rusu, and E. Zinovieva. STG: a symbolic test generation tool. In Tools and Algor. for the Const. and Anal. of Syst. (TACAS), pages 470-475. LNCS 2280, 2002.
  • [16] G. Behrmann, J. Bengtsson, A. David, K. G., Larsen, P. Pettersson, and W. Yi. Uppaal implementation secrets. In Proc. Form. Technique in Real-Time and Fault-Toler. Syst. (FTRTFT), pages 3-22. Springer-Verlag, Sept. 2002.
  • [17] S. Tripakis. Fault diagnosis for timed automata. In Proc. Form. Technique in Real-Time and Fault-Toler. Syst. (FTRTFT), LNCS 2469 Springer-Verlag, 2002.
  • [18] A. Khoumsi. Complete test graph generation for symbolic real-time systems. In Proc. Brazilian Symposium of Formal Methods (SBMF), Recife, Brazil, November 2004. Best Paper Award.
  • [19] R. Alur. Timed automata. In Proc. 11th Intern. Conf. on Comp. Aided Verif. (CAV), pages 8-22. Springer-Verlag LNCS 1633, 1999.
  • [20] C. Jard, T. Jéron, L. Tanguy, and C. Viho. Remote testing can be as powerful as local testing. In Proc. PSTV/FORTE, Beijing, China, October 1999.
  • [21] T. Jéron, H. Marchand, V. Rusu, and V. Tschaen. Ensuring the conformance of reactive discrete-event systems using supervisory control. In 42nd CDC, Hawaii, USA, December 2003.
  • [22] C. Jard and T. Jéron. TGV: theory, principles and algorithms. In Proc. 6th World Conf. on Integ. Design and Process Technol. (IDPT), Pasadena, California, USA, June 2002.
  • [23] J. Tretmans. A Formal Approach to Conformance Testing PhD thesis, University of Twente, The Netherlands, December 1992.
  • [24] A. Khoumsi and L. Ouedraogo. A new method for transforming timed automata. In Proc. Brazilian Symposium of Formal Methods (SBMF), Recife, Brazil, November 2004.
  • [25] A. Khoumsi and M. Nourelfath. An efficient method for the supervisory control of dense real-time discrete event systems. In Proc. 8th Intern. Conf. on Real-Time Computing Systems (RTCSA), Tokyo, Japan, March 2002.
  • [26] A. Khoumsi. Supervisory control of dense real-time discrete-event systems with partial observation. In Proc. 6th Intern. Workshop on Discrete Event Systems (WODES), Zaragoza, Spain, October 2002.
  • [27] A. Khoumsi. Supervisory control for the conformance of real-time discrete-event systems. In Proc. 7th Intern. Workshop on Discrete Event Systems (WODES), Reims, France, September 2004.
  • [28] R. Alur and D. Dill. A theory of timed automata. Theoretical Computer Science, 126:183-235, 1994.
  • 1
    Note that
    DG and
    VA of a transition Tr =
    are defined in
    V
    C ∪ θσ and not in the whole
    D =
    V
    C
    P.
  • 2
    But when Tr is enabled, σ is not necessarily executed.
  • 3
    Proof in Section A.1
  • 4
    Proof in Section A.2
  • 5
    The notion of
    trap has been defined in Remark 3.1
  • 6
    H is the set of clocks of the T
    iosa
    A such that
    B =
    SetExp(
    A).
  • 7
    Proof in Section C
  • 8
    Actually, STG is a software tool. But here, STG denotes the theoretical method that underlies the tool.
  • 9
    They are duplicated for the sake of clarity.
  • 10
    Proof in Section D.1
  • 11
    Proof in Section D.2
  • 12
    Proof in Section D.3
  • 13
    Actually, STG and TGV are software tools for testing. But here, STG and TGV denote the theoretical test methods that underly the tools, respectively.
  • Publication Dates

    • Publication in this collection
      24 May 2010
    • Date of issue
      Sept 2006
    Sociedade Brasileira de Computação Sociedade Brasileira de Computação - UFRGS, Av. Bento Gonçalves 9500, B. Agronomia, Caixa Postal 15064, 91501-970 Porto Alegre, RS - Brazil, Tel. / Fax: (55 51) 316.6835 - Campinas - SP - Brazil
    E-mail: jbcs@icmc.sc.usp.br