{'fraction_non_alphanumeric': 0.026534517723001343, 'fraction_numerical': 0.00739767501642341, 'mean_word_length': 4.754766600920447, 'pattern_counts': {'":': 0, '<': 6, '<?xml version=': 0, '>': 10, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
TEST SCENARIO SPECIFICATION LANGUAGE FOR MODEL-BASED TESTING

In mission critical systems a single failure might cause catastrophic consequences. This sets high expectations to timely detection of design faults and runtime failures. By traditional software testing methods the detection of deeply nested faults that occur sporadically is almost impossible. The discovery of such bugs can be facilitated by generating well-targeted test cases where the test scenario is explicitly specified. On the other hand, the excess of implementation details in manually crafted test scripts makes it hard to understand and to interpret the test results. This paper defines high-level test scenario specification language TDLTP for specifying complex test scenarios that are relevant for model-based testing of mission critical systems. The syntax and semantics of TDLTP operators are defined and the transformation rules that map its declarative expressions to executable Uppaal Timed Automata test models are specified. The scalability of the method is demonstrated on the TUT100 satellite software integration testing case study.


INTRODUCTION
In model-based testing (MBT), the requirements model of System Under Test (SUT) describes the expected correct behavior of the system under possible inputs from its environment. The model, represented in a suitable machine interpretable formalism, can be used to automatically generate the test cases either offline or online, and be used as the oracle that checks if the SUT behavior conforms to this model. Offline test generation means that tests are generated before test execution and executed when needed. In online test generation the model is executed in lock step with the SUT. The test model communicates with SUT via controllable inputs and observable outputs of the SUT.
Test description in MBT typically relies on two formal representations, SUT modelling language and the test purpose specification language. An extensive survey on modelling formalisms used in MBT can be found in [20].
The requirements to the test purpose specification languages for MBT can be summarized as following: 1. intuitive and user-friendly specification process; 2. expressiveness to capture the features and behaviours under test in a compact and unambiguous form; 3. formal semantics to make the test purpose specifications verifiable and pertinent for automated test generation; 4. decidability to make the test generation from test purpose specification algorithmically feasible. The first two criteria have been capitalized in earlier attempts of designing test purpose specification languages. Check Case Definition Language (CCDL) [1] provides a high-level approach for requirements-based black-box system level testing. Test simulations and expected results specified in human readable form in CCDL can be compiled into executable test scripts. However, due to the lack of standardization, high-level tests in CCDL are heavily tool-dependent and can be used only in tool specific testing processes.
High-level keyword-based test languages, such as the Robot Framework [2], have also been integrated with MBT [3]. In domains such as avionics [4] and automotive industry the efforts have been made to address the standardization of testing methods and languages, e.g. creating a meta-model for testing avionics systems [4], and the Automotive TestML [5]. Similarly, the Open Test Sequence Exchange Format (OTX) [6] standardized by ISO provides tool-independent XML-based data exchange format [7] for description and documentation of executable test sequences. These efforts have focused primarily on enabling the exchange of test specifications between involved stakeholders and tools. Due to their domain and purpose specialization the applicability of these languages in other domains is limited.
The Message Sequence Chart (MSC) [8] standardized by International Telecommunication Union was one of the first scenario specification languages though it was not only focusing on testing. The semantics of MSC is specified in [9]. Some of the features of MSC are adopted in UML, e.g. in Sequence Diagrams. Still, loose semantics limits its use as a consistent test description language [10].
Precise UML [11] introduces a subset of UML and OCL for MBT. The attempt to unify the semantics of different diagrams was motivated by the need for behavioral specifications of SUT which are well suited for generating test cases out of SUT models.
Concrete test scripting languages, such as TTCN-3, regardless their strict semantics are not well suited for high-level description of test scenarios. They rather follow the style of syntax typical to imperative programming languages [12].
Thus, most of the test purpose specification languages referred above suffer from some of the disadvantages, either they have imprecise or informal semantics, lack of standardization, lack of comprehensive tool support, or poor interoperability with other development and testing tools.
European Telecommunications Standards Institute (ETSI) intended to address these shortcomings and developed a new specification language standard by introducing Test Purpose Language (TPLan) that supports the high-level expression of test purposes in prose [13]. Though TPLan provides notation for the standardized specification of test purposes, it leaves a gap between the declarative test purpose and its imperative implementation in test. Without formal semantics the development of test descriptions by means of different notations and dialects led to overhead and inconsistencies that need to be checked and fixed manually. As a consequence, ETSI started a new initiative by developing the Test Description Language TDL [12]. It is intended to bridge the gap between declarative test purposes and imperative test cases by offering a standardized approach for the specification of test descriptions. The main benefits of ETSI TDL outlined in [12] are higher quality tests through better design, easier layout to review by non-testing experts, better and faster test development, and seamless integration of methodology and tools.
The development of ETSI TDL was driven by industry where it is used primarily, but not exclusively, for functional testing. To enable the application of TDL in UML based working environments, a UML Profile for TDL (UP4TDL) [10] was developed. Domain-specific concepts are represented in UP4TDL by means of stereotypes.
Though TDL features one of the most advanced test purpose description language it has room for improvements. In the first place, automatic mapping of ETSI TDL to TTCN-3 is not fully implemented yet. The mapping is needed for generating executable tests from TDL descriptions and re-using the existing TTCN-3 tools and frameworks for test execution.
Second limitation of TDL is restricted timing semantics. The Time package in TDL contains concepts for the specification of time operations, time constraints, and timers. Since time in TDL is global and progresses monotonically in discrete quantities there is no way of expressing synchronization conditions between local time events of parallel processes and detecting possible Zeno computations that can be analyzed in continuous time models. Similarly, timelockfreedom and bifurcation analysis [22] cannot be performed in this setting.
One step further towards automatic test generation was timed games based synthesis of test strategies introduced in [14] and implemented in the Uppaal Tiga tool. Timed Computation Tree Logic (TCTL) used for specifying test purpose in this approach has high expressive power and formal semantics relevant for expressing quantitative time properties combined with CTL operators such as 'always', 'inevitable', 'potentially always', 'possible', and 'leads-to' [15].
Due to the complexity of model checking [21], the TCTL syntax in Uppaal tool is limited with unnested operators making the TCTL expressions flat with respect to the temporal operators. On the other hand, to specify the properties of timed reachability the flat TCTL expressions are not sufficient for specifying complex properties and so called auxiliary property recognizing automata, e.g. 'stopwatch' automata are needed. Modifying the test model structure by adding property automata is not trivial for non-experts and may be an error prone process leading to the unintended changes of semantics of tests.
The aim of this work is to build an extra language layer (Test Scenario Definition Language -TDL TP ) for test scenario specification that is expressive, free from the limitations of 'flat' TCTL, interpretable in Uppaal TA, and suited for test generation.
In our approach, Uppaal Timed Automata (TA) [16] serve as a SUT specification language. Uppaal TA have been chosen because they are designed to express the timed behavior of state transition systems and there exists a mature set of tools that supports model construction, verification and online model-based testing [17].
For the test purpose specification to be concise and still expressive its specification language must be more abstract than SUT modeling language and not necessarily self-contained in the sense that its expressions are interpreted in the context of SUT model only. It means that the terms of test purpose specification refer to the SUT model structural elements of interest, they are called test coverage items (TCIs). The test purpose specification language TDL TP proposed in our approach allows expressing multiple coverage criteria in terms of TCIs, including test scenario constraints such as iteration, next, leads to, and structural coverage criteria such as selected states, selected transitions, transition pairs, and timing constraints, e.g. time bounded leads to.
Generating the test model based on the SUT model and TDL TP coverage expression includes two phases.
In the first phase, the TCIs have to be labelled in the SUT model with Boolean variables called traps. The traps are needed to make TCIs referable in the TDL TP expressions. In case of non-deterministic SUT model the coverage of those elementary TCIs is ensured by reactive planning tester (RPT) automata, one automaton for each conjunctive set of TCIs (see [19] for further details of RPT generation).
In the second phase of generation, a test supervisor model M SVR is constructed from the TDL TP expression to trigger the RPT automata according to the test scenario so that the temporal and logical coverage constraints stated in TDL TP specification would be satisfied. Since nondeterministic SUT models based tests are partially controllable only pseudo optimal traces can be generated by this method.
Alternatively, in case of deterministic SUT models, the RPT automata generation phase can be discarded since Uppaal model checker generates optimal witness traces from the parallel composition of SUT and tester models.
The rest of this paper is organized as follows. In Section 2 Uppaal Timed Automata formalism is introduced, Sections 3 and 4 define the TDL TP language syntax and semantics respectively, Section 5 defines the map from TDL TP to Uppaal TA that controls if the test scenario execution satisfies its declarative expression. In Section 6 the reduction rules of TDL TP expressions are presented. Section 7 describes how the whole test model is composed by introducing test supervisor automaton. Section 8 explains how the test verdict and test diagnosis capability are encoded in the tester model, and finally the conclusions are drawn.

UPPAAL TIMED AUTOMATA
Uppaal Timed Automata [16] (TA) used for modelling SUT is defined as a closed network of extended timed automata that are called processes. The processes are gathered into a single system by parallel composition known from the process algebra CCS. An example of a system comprising two automata is given in Fig. 1.
The nodes of the automata are called locations and the directed edges transitions. The state of an automaton consists of its current location and assignments to all variables, including clocks. The initial locations of the automata are graphically denoted by double circle inside the location. Synchronous communication between the processes is by hand-shake synchronization links that are called channels. A channel relates a pair of edges labeled with symbols for input actions denoted by e.g. chA? and chB? in Fig. 1, and output actions denoted by chA! and chB!, where chA and chB are the names of the channels.
In Fig. 1, there is an example of a model that represents a synchronous remote procedure call. The calling process Process_i and the callee process Process_j both include three locations and two synchronized transitions. Process_i, initially at location Start_i, initiates the call by executing the send action chA! that is synchronized with the receive action chA? in Process_j. The location Operation denotes the situation where Process_j computes the value to output variable y. Once done, the control is returned to Process_i by the action chB!.
The duration of executing the result is specified by the interval [lb, ub] where the upper bound ub is given by the invariant cl<=ub of location Operation, and the lower bound lb by the guard condition cl>=lb of the transition Operation ⟶ Stop_j. The assignment cl=0 on the transition Start_j ⟶ Operation ensures that the clock cl is reset when the control reaches the location Operation. The global variables x and y model the input and output arguments of the remote procedure call, and the computation itself is modelled by the function f(x) defined in the declarations block.
While the synchronous communication between processes is modeled using channels, asynchronous communication between processes is modeled using global variables accessible to all processes.
Formally, the Uppaal TA are defined as follows: Let ∑ denote a finite alphabet of actions a, b, … and C a finite set of real-valued variables p, q, r, denoting clocks. A guard is a conjunctive formula of atomic constraints of the form p ~ n for p ∈ C, ~ ∈ {≤, ≥, =, <, >} and n ∈ N + . We use G(C) to denote the set of clock guards. A timed automaton A is a tuple N, l0, E, I where N is a finite set of locations (graphically denoted by nodes), l0 ∈ N is the initial location, E ∈ N × G(C) × ∑ × 2 C × N is the set of edges (an edge is denoted by an arc) and I : N ⟶ G(C) assigns invariants to locations (here we restrict to constraints in the form: p ≤ n or p < n, n ∈ N + .
Without the loss of generality we assume that guard conditions are in conjunctive form with conjuncts including besides clock constraints also constraints on integer variables. Similarly to clock conditions, the propositions on integer variables k are of the form k ~ n for n ∈ N, and ~ ∈ {≤, ≥, =, <, >}. For the formal definition of Uppaal TA semantics we refer the reader to [18] and [16].

TDL TP SYNTAX
The ground terms in TDL TP are sets (denoted TS) of assignments to auxiliary variables called trap variables or simply traps added to the SUT model for test purpose specification. A trap is updated by Boolean variable assignment that labels a TCI. In case of Uppaal TA, the TCIs are edges of the SUT model M SUT . The value of all traps is initially set to false. When the edge of M SUT labelled with a trap is visited during test execution the trap update function is executed and the trap value is set to true. We say that a trap tr is elementary trap if its update function is unconditional, i.e. of shape tr := true.
Generally we assume that the trap names are unique, trap update functions are non-recursive and their arguments have definite values whenever the edge labelled with that trap is executed. The trap tr update condition, if conditional trap, is a Boolean expression (we call it also update constraint) the arguments of which range over the sets of variables and constants of M SUT and over the auxiliary constants and variables occurring in the test purpose specification in TDL TP , e.g. references to other traps, event counters and the time bounds of model clocks.
Although we deal with finite sets of traps and their value domains the quantifiers are introduced in TDL TP for notational convenience. To refer to the situations where many traps have to be true or false at once, we group these traps to sets called trapsets denoted by TS and prefix them with trapset quantifiers -A for universal and E for existential quantification. A(TS) means that all traps and E(TS) means that at least one trap of the set TS has to be true. To represent a trapset in Uppaal TA syntax we encode them as one-dimensional trap arrays and refer to individual traps in the array by array index value, e.g. i-th trap in TS is referred to as TS [i].
In the following we give the syntax of TDL TP expressions in BNF:

TDL TP SEMANTICS
To define the semantics of TDL TP we assume there are given: - We assume the uniqueness of the labeling within a trapset, i.e. there is at most one edge labelled with a trap from the given trapset but an edge can be labelled with many traps if each of them is from different trapset.

ATOMIC LABELLING FUNCTION
Atomic labelling function is non-surjective and injective-only mapping between TS and ( ), i.e. each element of TS is mapped to a unique edge in ( ): (1)

DERIVED LABELLING OPERATIONS (TRAPSET OPERATIONS)
The formulas with a trapset operation symbol and trapset(s) identifiers being its argument(s) are called TDL TP trapset formulas.
Relative complement of trapsets ( \ ). Only those edges labelled with traps of and not with traps of are in the relative complement trapset \ : Absolute complement of a trapset (! ). All edges that are not labelled with traps of TS are in the absolute complement trapset ! : where ⟦ ⟧ denotes the interpretation of the trapset TS on the trace and denotes the l-th suffix of the trace , i.e. the suffix which starts from l-th location of ; and denote cardinalities of trapsets and respectively. Note that operator ';' enables expressing one of the "classical" structural coverage criteria 'selected transition pairs'.

Quantifiers of trapsets.
Given the definitions 1 -4 of trapset operations we define the semantics of bounded universal quantifier A and bounded existential quantifier E of a trapset TS as follows: where n denotes the cardinality of the trapset TS.
Note that quantification is defined on the trapsets only and not on higher level operators.
Logic connectives. Since recursive nesting of TDL TP logic and temporal operators is allowed for better expressiveness we define the semantics of these higher level operators where the argument terms are not trapset formulas but derived from them using recursive nesting of logic and temporal operator symbols. Let SE, 1 and 2 denote such argument sub-formulas, then

Temporal operators
Leads to' operator ′ ↝ ′ in TDL TP is inspired by Computation Tree Logic CTL 'always leads to' operator, denoted by ′ − −> ′ in Uppaal, which is equivalent to CTL formula ( ⟹ а ). Leads to expresses that after reaching the state which satisfies in the computation all possible continuations of this computation reach the state in which is satisfied.
For clarity we substitute the meta-symbols and with non-terminals and of TDL TP .
where denotes the k-th suffix of the trace , i.e. the suffix which starts from k-th location of , and ⟦ ⟧ denotes the interpretation of TS on the k-th suffix of trace .
The application of logic not to non-ground level TDL TP terms has following interpretation: where denotes the time bound constraint that yields the negation of constraint ⊛ .

MAPPING TDL TP EXPRESSIONS TO BEHAVIOR RECOGNIZING AUTOMATA
When mapping the TDL TP formulae to test supervisor component automata we implement the mappings starting from ground level terms and move towards the root term by following the structure of the TDL TP formula parse tree. The terminal nodes of any TDL TP formula parse tree are trapset identifiers. The next above the terminal layer of the parse tree constitute the trapset operation symbols. The trapset operation symbols, in turn, are the arguments of logic and temporal operators. The ground level trapsets and the trapsets which are the results of trapset operations are mapped to the labelling of SUT model M SUT . In the following the mappings are specified for TDL TP trapset operations, logic operators and temporal operators in separate subsections.

MAPPING TDL TP TRAPSET EXPRESSIONS TO SUT MODEL M SUT LABELLING
Mapping M1: Relative complement of trapsets 1 \ 2 : The 1 \ 2 -mapping adds the traps of the trapset 1 \ 2 only to these edges of M SUT which are labelled with traps of 1 and not with traps of 2 . An example of such mapping is depicted in Fig. 2. The example of Algorithm 1 application is demonstrated in Fig. 4. Notice that the labelling concerns not only the edges that are labelled with traps of TS1 and TS2 but also those which depart from the same location as the edge with TS2 labelling. This is necessary for resetting the variable flag which indicates the executing a trapset TS1 labelled edge in the previous step of the computation.

MAPPING TDL TP LOGIC OPERATORS TO RECOGNIZING AUTOMATA
The indexing of trapset array elements, universal and existential quantifiers in Uppaal modelling language support direct mapping of trapset quantifiers to forall and exists expressions of Uppaal TA as shown in Fig. 5 and 6.

Negation not
Since logic negation not can be pushed to ground level trapset terms by applying equivalences (14 -22) and the direct mappings of not formulas are not considered in this work.

Mapping M6: Conjunction of sub-formulas
The conjunction SE1 & SE2 is mapped to the automata fragment as shown in Fig. 7. In the conjunction and disjunction automata depicted in the Fig. 7 and 8 the guard conditions P and Q encode the argument terms SE1 and SE2 respectively. In conjunction automaton the End location is reachable from the initial location Idle if both P and Q evaluate to true in any order.

Mapping M7: Disjunction of sub-formulas
In the disjunction automaton the End location is reachable from the initial location Idle if either P and Q are true.

Figure 8 -Automaton that recognizes the disjunction of TDL TP formulas P and Q
The implication of TDL TP formulas can be defined using disjunction and negation as shown in formula (9) and their transformation to property automata are implemented through these mappings.
Similarly, the equivalence of TDL TP formulas can be expressed via conjunction and implication by using equivalence in formula (10).

Mapping M8: 'Leads to' ↝q
Mapping the leads to operator to Uppaal TA produces the model fragment depicted in Fig. 9. Mapping M9: Timed leads to p ↝ ⊛ Mapping 'timed leads to' to a Uppaal TA fragment is depicted in Fig. 10. It presumes an additional clock cl which is reset to 0 at the time instant when formula P become true. The condition 'cl<=d' in Fig. 10 a) sets the upper time bound d to the event when formula Q has to becomes true after P, i.e. after the clock cl reset. The mapping to property automaton depends on the time condition of leads to. For instance if the conditions is 'cl>d' the mapping results in automaton shown in Fig. 10 b).
Mapping M10: Conditional repetition # ⊛ : The Uppaal TA fragment generated by the mapping of # ⊛ (Fig. 11) includes a counter variable i to enumerate the events when the SE formula P becomes true. If the loop exit condition, e.g., 'i >=n', is satisfied then the transition to location End is fired without delay (the middle location is of type committed).

REDUCTION OF THE SUPERVISOR AUTOMATA AND THE LABELLING OF SUT
The TDL TP expressions with many nested operators may become large and involve some overhead. Removal of this overhead in the formulas provides reduction in the state space needed for their model checking and improves the readability and comprehension of this formula.
The simplifications are formulated in terms of the parse tree of the TDL TP formula and standard logic simplifications. Due to the nesting of operations in the TDL TP formula the root operation can be any operator listed in the BNF grammar of TDL TP but the terminals of the parse tree are always trapsets. The trapset formulas are implemented by labelling operations such as relative and absolute complement. Only trapset formulas can be universally and existentially quantification. No nesting of quantifiers is allowed. Since the validity of root formula can be calculated only using the truth value of the highest trapset expression in the parse tree, all the trapsets being closer to the ground level trapset along the parse tree sub branch can be removed from the labelling of the SUT model. This reduction can be done after labelling the SUT model and applying all the trapset operations. An example of such reduction is demonstrated for relative complement operation \ in Fig. 12. Logic simplification follows after the trapset expression simplification is completed. Here standard logic simplifications are applicable: We will introduce also a set of simplifications for TDL TP temporal operators which follow from their semantics and the properties of integer arithmetic:

COMPOSING THE TEST SUPERVISOR MODEL
The test supervisor model M SVR is constructed as a parallel composition of single TDL TP property recognizing automata each of which is produced by parsing the TDL TP formula and mapping corresponding sub-formulae to the automaton template as defined in Section 5. To interrelate these sub-formula automata, two phases have to be completed: 1) Each trap labelled transition e of M SUT (here we consider the traps which are left after labels reduction as described in Section 6) has to be split in two edges e' and e" connected via an auxiliary committed location l c . The edge e' will inherit the labelling of e while e" will be labelled with an auxiliary broadcast channel that signals the trap update occurrence to the upper neighbor sub-formula automaton. We use the channel naming convention, where a channel name has a prefix ch_ followed by the trapset identifier, e.g. for an edge e labelled with the trap TS[i], the broadcast channel label ch_TS! is added to the edge e" (an example is shown in Fig. 13  a)). 2) Each non-trapset formula automaton will be extended with a wrapping construct shown in Fig. 13 b). The wrapper has one or two, channel labels, depending if the sub-formula operation is unary or binary, to synchronize its state transition with those of its child expression(s). We call them downwards channels denoted by Activate_subOP1, Activate_subOP2 and used to activate the recognizing mode in the first and second subformula automata. Similarly, two broadcast channels are introduced to synchronize the state transition of sub-formula automata with their upper operation automaton. We call them upwards channels, denoted by Activate_OPi and Done OPi in Fig. 13 b). The root node is an exception because it has upwards channel only with the test Stopwatch automaton (the Stopwatch automaton will be explained in Section 8). If the sub-formulas of given property automaton are mapped to trapset expressions then the back edge EndIdle to the initial state is labelled also with trapset reset function with TS being the argument trapset identifier. The TDL TP operator automata extensions with wrapper constructs for implementing their composition in test supervisor model M SVR are shown in Fig. 14. Note that the TDL TP sub-formula meta symbols P and Q in the original templates are replaced with channels which signal when the sub-formulas interpretation automata reach their local End locations.

ENCODING THE TEST VERDICT AND TEST DIAGNOSTICS IN THE TESTER MODEL
The test verdict is yielded by the test StopWatch automaton either when the automaton reaches its end state End within time bound TO. Otherwise, the timeout event Swatch==TO triggers the transition to the terminal location Failed. Specifically, Passed in the StopWatch automaton is reached simultaneously with executing the test purpose formula  TP automaton transition to its End location. For example, in Fig. 15, the automaton that implements root formula P, synchronizes its transition to the location End with StopWatch transition to the location Passed via upwards channel Done_P. Another extension to the supervisor model is the capability of recording the test diagnostic information. For that each sub-formula of the test purpose specification formula  TP is indexed according to its position in the parsing tree of  TP . A diagnostic array D of type Boolean and of the size equal to the number of sub-formulas in  TP is defined in the model. The initial valuation of D sets all its elements to false. Whenever a model fragment that corresponds to a sub-formula reaches its end state (that is sub-formula satisfaction state), the element in D that corresponds to that sub-formula is set to true.

CASE STUDY
To demonstrate the usability of TDL TP the TTU100 satellite testing case study has been chosen. The objective of the TTU100 project is to build a space system consisting of a 1U (10 cm x 10 cm x 10 cm) nanosatellite and a ground station, where mission planning and mission control software for scientific experiments is installed. The TTU100 system consists of a Ground Segment and a Space Segment. The Ground Segment communicates, stores and processes data aquired from satellite. The Space Segment is nanosatellite on Earth's Sun Synchronous Orbit (650km altitude). The satellite onboard system consists of smart electrical power supply (EPS), attitude determination and control system (ADCS), on-board computer (OBC), communication system (UHF band, Ku-band) and camera and optics payload.
For TDL TP usability demonstration smart EPS subsystem is selected as a SUT. The test purpose is specified for a test case which demonstrates the TDL TP capability to express combinations of multiple coverage criteria in a single test case. From TDL TP expressions the test models are constructed and the test sequences generated using Uppaal model checker. The section is concluding with comparison of the tests generated with the methods presented in the paper and with those available using ordinary TCTL model checking.

SYSTEM UNDER TEST MODELLING
EPS receives commands from other system components to change its operation mode and respond with its status information. In the integration level test model we abstract from the concrete content of the commands and responses and describe its interface behavior in response to input commands.
EPS is sampling its input periodically with period 20 time units. EPS wakeup time when detecting a new input command can vary within interval [15,20] time units after previous sampling. After wakeup it is ready to receive incoming commands. Due to internal maintenance procedures of EPS some of the commands when sent during self-maintenance can be ignored, and need to be repeated later. The command processing after its successful receive takes at most 20 time units. Thereafter, the validity of the command is checked using CRC errordetecting code. If the error is detected the error report will be sent back to EPS output port in o_response message. If the received command data is correct, the command is processed and its results returned in the outgoing o_message. Since EPS internal processing time is negligible compared to that of input sampling period and wakeup time, all the other locations except start and commandCreated are modelled as committed locations. The model M SUT of the EPS is depicted in Fig. 16.

TEST PURPOSE SPECIFICATION
The goal of test case is to show that after invalid command has been received the valid command can be received correctly and responded with acknowledgement. We specify the test purpose in TDL TP as formula which expresses that all transition pairs labelled with traps of TS2 and TS4 must lead to some pair of transitions labelled with traps of trapsets TS2 and TS3.

LABELLING OF M SUT
The labelling of M SUT starts from the ground level trapsets TS2, TS3 and TS4 of the formula (25). These traps guide branching conditions to be satisfied in the test scenario. The labelling is shown in Fig. 16.
Second level labelling results in applying trapset operation next ';' for pairs TS2;TS3 and TS2;TS4 which presumes introducing auxiliary variables fl23 and fl24 to identify occurrence of traps of TS3 and TS4 right after traps of TS2. Since TS2;TS3 and TS2;TS4 are arguments of the upper 'forall' and 'exists' formula their occurrence should be signaled respectively to 'forall' and 'exists' automata. For this purpose additional committed locations and edges with upwards channels ch_TS23 and ch_TS24 are introduced in Fig. 17.

TEST MODEL CONSTRUCTION
When moving upwards in the parse tree of formula (25) the next operators that have TS2;TS4 and TS2;TS3 in arguments are forall A(TS2;TS4) and exists E(TS2;TS3) which automata are depicted in Fig. 18. The root operator in the formula (25) is 'leads to' the arguments of which are A(TS2;TS4) and E(TS2;TS3). The automaton that recognizes A(TS2;TS4) ∼> E(TS2;TS3) is depicted in Fig. 19. The full test model for generating test sequences of test scenario A(TS2;TS4) ∼> E(TS2;TS3) is composed of automations shown in Fig. 17, Fig. 18, Fig.19 and Fig. 20.

GENERATING TEST SEQUENCES
The test sequences of the SUT model M SUT shown in Fig. 16 and of the scenario A(TS2;TS4) ∼> E(TS2;TS3) are generated by running the model checking query E<> StopWatch.Pass. There are three options of selecting the trace for test -shortest, fastest, or some. The trace generated with model checking option shortest is shown in the Fig.21.

Figure 21 -Test Case test sequence
The lenght of the trace generated by using TDL TP is 22 transitions and the average lenght generated using ordinary TCTL model checking is 50 transitions.

CONCLUSION
In this paper high level test purpose specification language TDL TP , its syntax and semantics have been defined for model-based testing of time critical systems. Based on the semantics proposed in this work a mapping from TDL TP to Uppaal TA formalism has been defined. The mapping is used for automatic construction of test models that are composition of a SUT model and the tester model derived from the test purpose specification in TDL TP . Practical side effect of this is the diagnosis capability enabling tracing back the specification sub-formulae which violation by SUT behavior causes test fail. The application of TDL TP based test generation approach on the TTU100 satellite power supply system case study confirmed our expectations that complex multi-purpose test goals can be specified in compact and comprehensible way saving from time consuming and error prone manual test scripting. Future study is needed to evaluate the capability of TDL TP to specify and provide efficient online interpretation algorithms of non-linear dynamics phenomena such as bifurcation and chaotic behavior of complex systems.