A Pragmatic Approach for Testing Robustness on Real-Time ...

A Pragmatic Approach for Testing Robustness on Real-Time Component Based Systems Abbas Tarhini∗, Antoine Rollet LICA/CReSTIC, Université de Reims Champagne-Ardenne Moulin de la Housse, BP 1039, 51687 Reims Cedex 2, France email:{Abbas.Tarhini,Antoine.Rollet}@univ-reims.fr

Abstract In this paper, we suggest a realistic methodology for testing robustness of Real-Time Component-Based Systems (RTCBS). A RTCBS system is described as a collection of components where each component is specified by a nominal and a degraded specification, modeled as a Timed InputOutput Automaton (TIOA). Further, the communication of the whole system is also specified by its nominal and degraded specification. We extract test sequences from the nominal specification and we inject automatically faults in order to model hostile environments. Then we present an adequate test architecture consisting of the System Under Test (SUT) of components, and a distributed tester that consists of a set of coordinating testers. Each tester is dedicated to test a single SUT component. A test execution algorithm with an approach to handle testers’ coordination and execution delay is presented. Testing the SUT is divided into two phases. In the first phase, the tester tests the robustness of each component in isolation. If all components are robust according to the inserted hazards, in the second phase, we use the nominal and degraded specification of the whole system to check the robustness of communications between components. Key-words : Real-Time System, Timed Automata, Component based System, Validation, Testing, Robustness.

1 Introduction Recently, software is urged to be more complex consisting of many independent distributed components running concurrently on heterogeneous networks; consequently, facilitating the creation of emerging technologies such as ∗ also

at Lebanese American University, Beirut, Lebanon

Hacène Fouchal GRIMAAG Universitsé des Antiles et de la Guyane Campus de Fouillole 97159 Pointe-à-Pitre, Guadeloupe, France email:[email protected]

commercial Off-The-Shelf (COTS) products which are becoming a market reality [11]. Traditional testing methods that ordinary COTS products undergo are not thorough enough to guarantee reliability; still, many of these products are integrated temporally in critical real-time componentbased systems. Such integration may lead to architectural mismatches when assembling components with incorrect behavior [7], leaving the system in a hostile environment. The criticality of such systems requires the creation of software components that can function correctly even when faced with improper usage or stressful environmental conditions. The degree of tolerance to such situations is referred to as a component’s robustness. This paper deals with robustness testing for Real-Time Component-Based Systems (RTCBS). Our methodology consists of (1) representing the communication of the whole systems and each of the SUT components as Timed InputOutput Automata (TIOA), (2) generating and mutating test sequences from each TIOA, (3) executing mutated test sequences using a distributed tester that consists of a set of coordinating testers, and (4) an approach handling time delay in each tester. The mutation method inserts hazards to test sequences generated from the communication and the component’s nominal (original) specification. The mutated test sequences are used to test the system’s robustness according to a corresponding degraded specification which describes the minimal authorized behavior in case of unexpected situations. These timed test sequences are divided into two sets. One set is used to check the robustness of each component in isolation, and another set is used to test the correctness of communication between the components integrated in a RTCBS; and thus the robustness of the whole system. Then, we focus on the execution of these timed test sequences. The execution of timed-mutated test sequences on the

SUT is divided into two phases. In the first phase, the tester executes a set of test sequences to test the robustness of each component in isolation, and register the feedback from the components into traces. Next after checking the registered traces with the corresponding degraded specification, the tester produces a verdict success or failure relative to the inserted hazards. If success, the components are robust-enough stand-alone objects. Otherwise, components are identified as not robust. In the second phase, the tester also executes and monitor timed test sequences, however, to test the robustness of interaction between components integrated in a RTCBS and thus testing the system’s robustness. In what follows we present our proposed approach. Section 2 provides a review on related work done on testing distributed and component based systems. Section 3 provides our modeling techniques used to represent RTCBS. In Section 4 we focus on our method for testing Real-Time Component Based Systems. The timed test sequence mutation method is presented. It explains how we insert hazards, and we detail the acceptance relation used in robustness testing. In Section 5, we detail the test architecture, tester coordination and time-delay handling as well as the test execution process. Finally, we conclude in Section 6.

2 Related Work A noticeable work has been done on distributed testing [9]; however, only few of them, [3], [14] dealt with testing component based systems. Yet, very few works are done on RTCBS robustness testing. Distributed systems may be viewed as a set of components connected via a communication system, where each component sends and/or receives messages through one or more communication channel. Distributed testing was studied with different test architectures. [9] proposed a distributed tester, with the distribution of global test sequence (GTS) into local test sequences executed over local testers, where the synchronization and the fault detectability problems are discussed. In Component Based Systems (CBS), components must interact with different external elements [13]. Those components may run on single, multiple, distributed or network systems in a sequential or individual concurrent manner, and may communicate with every other component. Such systems require a tight and loose coupling of components of diverse granularity [10] , taking into consideration some major requirements such as, flexibility, time-tomarket, quality, and cross-department standardization. With all its advantages, CBS still lacks some aspects of real-time systems that cannot be encapsulated in a component such as synchronization, and memory optimization [12] . From the above requirements, it is clear how complex and sensitive it is to build and have a reliable tested component-based

system. [9] handles testing distributed real-time systems. It assumed a more realistic clock between testers synchronizing with a reference clock with a given inaccuracy rather than synchronizing with other tester’s clock. Robustness testing has been studied in many areas. It is based on insertion of hazards into test sequences. Some studies are based on fault injection by using special-purpose hardware which causes electric disturbances. [8] apply heavy-ion radiations on replicated CPU boards to measure radiation effects on a system. Another fault injection approach is developed, using software. It is called Software Implemented Fault Injection (SWIFI). Among these studies the FIAT system ([2]) modifies the binary image of a process in memory (fault injection at compile time). In the following section we discuss how a real-time component-based system is best modeled.

3 Modeling Modeling component-based systems requires us to recall the definition of components that are the building blocks of such system. Szyperski [11] defined components as: a component is a unit of composition with contractually specified interfaces and fully explicit context dependencies that can be deployed independently and is subject to thirdparty composition. Software architectures (SA) that represent the individual components and their interactions are used in building component-based systems. [4] distinguished between the following perspectives of CBS: (1) The component implementation, (2) The component interface,and (3) real-time component: component technology for real-time systems should support specification and prediction of timing. In fact, the time factor problem in real-time component based systems (RTCBS) is not enough developed [4]. The time issue should be included in the model of such systems. Consequently, a Timed Input-Output Automata (TIOA) best represents the (SA) of a RTCBS. In our model, we use continuous time. This is due to the fact that is more realistic. A solid theoretical foundation of a timed automata (TA) is defined by Alur-Dill [1] as a finite set of states and a finite set of clocks which are real-valued variables. All clocks proceed at the same rate and measure the amount of time that has elapsed since they were started or reset. Each transition of the system might reset some of the clocks, and has an associated enabling condition (EC) which is a constraint on the values of the clocks. A transition is enabled only if its corresponding state is reached and the current clock values satisfy its enabling condition. In this study, we choose to model the communication of the whole system and the individual components of the RTCBS as TIOA. In the next section, we, first, present a rep-

resentation of a single component, then a formal definition of the TIOA; next, we describe the test sequence mutation method.

4 A Robustness Testing Methodology for RTCBS The purpose of our testing is to check how the system reacts to hazards, and consequently to some stressful situations. A hazard could be defined as any unexpected event from the environment. In our study we handle external hazards. External hazards are modeled as actions received by the system or erroneous timing constraints. The automatic generation and integration of hazards in the test sequences can be found in [5].

4.1

Single Component Representation

Each component of the RTCBS is described by a nominal and a degraded specification. A nominal specification describes the normal behavior of the system. A degraded specification describes the vital functionalities and the minimal required behavior of the system. Each of these specifications is represented by input-complete, minimal, strongly connected timed input-output automata TIOA. A TIOA is defined formally as follows: Definition 4.1 (Timed Input Output Automaton (TIOA)) A TIOA is defined by M = (S, A, C, T, s0 ) where S is a finite set of states, s0 is the initial state, and A is a set of actions. A is partitioned into 2 sets: AI is the set of input actions (written ?i), AO is the set of output actions (written !o). Input and output actions are referred to as visible actions. C is a set of clocks. T is a transition set having the form {T r1 .T r2 ...T rn }. T ri = , where s and d are starting and destination states. ’a’ is the action of the transition. EC is an enabling condition evaluate to the result of the formula a ∼ b where ∼∈ { , ≤, ≥, = } or to a constant valued either true or false. Cs is a set of clocks to be reset at the execution of a transition. Whenever enabled, if T ri is output transition, it should be directly executed reaching state ’d’ without staying indefinitely in state s. The initial state of TIOA is s0 . s0 can execute only input transitions. After the execution of T ri all clocks in Cs are reset. Definition 4.2 (Controllable state) A state s ∈ S of a TIOA M is called a controllable state, denoted by δ(s) if there is no other possibility than applying an input action to reach an other state of M , ie : if there exists a state s0 ∈ S − {s} and an edge e =< s, a, s0 , EC, CS > then a ∈ {AI }.

Notation 4.1 (Pm , S Pm , S Cm , SdPm , SdCm )Pm is a subcomponent indexed "m". S Pm is a TIOA nominal specification that specifies component Pm of the system under test (SUT). SUT is composed of a set of components P1 , P2 , ..., PN . S Cm is a TIOA communication nominal specification that specifies the communication of the whole system. SdPm is the degraded specification for component Pm . SdCm is a TIOA degraded specification for the communication of the whole system. Definition 4.3 (Order relation T (≺T )) We define the order relation on two actions ai , aj of a path T , denoted ai ≺T aj , meaning that action ai occurs before action aj in T . Definition 4.4 (⊂D ) Let M = (S, A, C, T, s0 ) and M 0 = (S 0 , A0 , C 0 , T 0 , s00 ) be two TIOA, T r(M ) and T r(M 0 ) respectively all traces of M (from s0 ) and M 0 (from s00 ). M 0 ⊂D M iff s0 = s00 and A0 ⊂ A and ∀t0 ∈ T r(M 0 ), ∃t ∈ T r(M ) such that ∀(a, b) ∈ (A0 )2 , a ≺t0 b =⇒ a ≺t b. Figure 1 shows an example of a nominal specification TIOA M with initial state s1 . A transition is represented by an arrow between two states and labeled by (action; EC; Cs). The set of actions A={?temperatureReq, !temperature,?posReq,!pos,?moveMode,?endMoveMode}; and the set of states S={s1 , s2 , s3 , s4 }. S4

?endMoveMode ?temperatureReq x:=0

?moveMode

S1

!pos y t.

4.2.1 Test Sequence Generation In this work, we are not concerned with the test sequence generation. We assume timed test sequences are already generated from the nominal specification using the test purpose technique [6]. In [6], the generated test sequences start with an input event and end with output events. For each controllable state we derive a sequence able to characterize this state among all others. The generated test sequences contain events that may not be included in the degraded specification, such events are identified as non-relevant events, other events are identified as relevant events. Next, we present our method for mutating those test sequences by insertion of input hazards. 4.2.2 Hazards Hazards are inserted in the generated test sequences to simulate a hostile environment. In fact, we modify only the inputs in the testing sequences, since the outputs are generated by the system (they are external to the system). Besides, because we check if the system is able to react well in presence of relevant actions, we do not allow to modify any input action that belongs to the set of input actions of the degraded specification. We choose a “pragmatic” approach for this integration. The designer decides which scenario he wants to integrate in a sequence based on his own experience. Many operations may be performed : replacing an input action by another, changing the instant of an input action occurrence, exchanging two input actions, adding an unexpected transition, removing a transition.

Definition 4.6 (Timed word) A timed word over an alphabet A is a pair (σ, τ ) where σ = σ1 σ2 ... is an infinite word over A and τ is a time sequence. An example of possible execution traces set is given in figure 2. • (?posReq, 3) → (!pos, 203) → (?tempReq, 208) → (!temperature, 708) → (?moveM ode, 720) • (?moveM ode, 3) → (?moveM ode, 8) → (!stopT urn, 28) → (?endM oveM ode, 33) → (?endM oveM ode, 38) → (?posReq, 48) → (!pos, 248)

Figure 2. Example of execution traces The aim of this part is to give the rules to decide whether an execution trace is accepted by the degraded specification. Figure 3 shows an example of a degraded specification. If all execution traces are accepted, then the component implementation is considered as robust enough (according to the hazards inserted in test sequences). To express this relation, we will use the notion of a run defined in [1], that gives a relation between a timed word and a timed automaton of the degraded specification. This relation is called robustness acceptance.

?temperatureReq x’:=0

!pos y’ −→ < s2 , ν2 > −→ ...

Definition 4.9 (acceptR ) A finite word w = (σ, τ ) is accepted in the sense of robustness by a TIOA specification M 0 , denoted M 0 acceptR w iff there exists a run r = (¯ s, ν¯) 0 0 of Mcompl over w such that the last state of Mcompl reached by r is controllable. By extension, for a set of timed words Υ, we denote M 0 acceptR Υ iff ∀w ∈ Υ, M 0 acceptR w.

τ1

τ2

τ3

with si ∈ A and νi ∈ [C → R ], for all i ≥ 0, satisfying the following requirements: • Initiation: ν0 (x) = 0 for all x ∈ C. • Consecution: for all i ≥ 1, there is an edge in T of the form < si−1 , σi , si , ECi , Csi > such that (νi−1 + τi − τi−1 ) satisfies ECi and νi equals [Csi 7−→ 0] (νi−1 + τi − τi−1 ). For any test sequence T sm (obtained from the nominal specification M ), we may not be able to execute a run of M 0 over a timed word obtained by the test execution. The reason is that these words contain some actions not expected by the degraded specification M 0 . As a consequence, any run would be blocked in almost any case. For example, suppose that we would like to find a run of the degraded specification M 0 of Fig. 3 over the first timed word obtained from M = (S, A, C, T, s0 ) in Fig. 2, we notice that it is not possible because the last action of the word (?moveM ode) is not in M 0 . To avoid this problem, we propose to complete the TIOA M 0 by adding to each state transition loops labeled by (1) all complementary actions (input/output) of the alphabet and (2) other loops labeled with the same action however, with complementary time constraint. We further assume that the implementation of a component is also input-complete. 0 Then any run of the completed M’ (Mcompl ) is possible over any timed word w based on the restriction that w and 0 Mcompl use the same alphabet and that the time constraints are compatible. The idea of robustness acceptance is that the tester sends an input (or several inputs), and waits for an answer (or more) respecting time constraints bounded in time. Then we have two cases: • if the input was not expected in the degraded specification M 0 , this means that it was not a relevant action. 0 , the system stays in Thus, during the run of Mcompl the same state, waiting for a relevant input. • if the input was expected in the degraded specification 0 M 0 , the run of Mcompl passes the transitions. Then the only way to come back in a controllable state is that the implementation of the component gives the output(s) expected in M 0 . If not, the run is blocked in a non controllable state.

5

Test Architecture and execution

In this work, we consider a real-time component-based system that consists of several components each of which is able to interact with the environment. Figure 4 illustrates our test architecture. It consists of a set of distributed local testers. For each component "Pm " of the system, a dedicated Tester "Tm " is assigned. Below we present the notations needed in this section. In the following subsections, we describe the scheme for component’s communication; next, we present the architecture of each local tester, then tester coordination, and finally we explain the test execution process. Tester ioQ1

ioQ2

ioQn

T1

T2

Tn

P1

P2

Pn

Figure 4. Test Architecture for the whole system

Ti Notation 5.1 (Tm , N, Om ) Tm is a tester for a component "Pm ". N is the number of local testers, and thus the number Ti of components. Om is an output from a component "Pm " sent to tester Ti (tester for component "Pi ") through tester Tm .

Notation 5.2 (LT sm , CT sm ) LT sm = m m {LT sm 1 , LT s2 , ..., LT sn } is a set of local mutated test sequences for a component ”Pm ”. Each LT sm i has the form T r1m .T r2m ...T rnm . CT sm is an LT sm with at least an event T rki requiring a component ”Pm ” to get input from (resp. send output to) another component ”Pi ”.

Notation 5.3 (IT s, T s)IT s is an interoperable mutated test sequence that contains all CT sm . Ts is a set of LT sm and CT sm . For simplicity we refer to LT sm and CT sm as T sm . Notation 5.4 (ioQ, T rjm ) ioQ = {ioQ1 , ioQ2 , ..., ioQN } where each ioQm is an input/output priority queue dedicated for tester Tm . ioQm holds inputs sent by any tester Ti to component Pm . T rjm is a transition indexed j and is an input from tester Tm .

5.1

Component communication scheme

Components communicate with each other only through their corresponding testers. It is important to note that in our model the time taken by the communication between components through the testers is considered with accuracy.

5.2

Local Tester Representation

Local testers execute local test sequences (T sm) on their corresponding components (Pm ) by sending input acTi tions and receiving output actions in the form Om (i = {1,..,m,..N}). Each local tester consists of the following: (1) a test executer unit (TEU), (2) a test monitor unit (TMU), (3) a local input/output queue (ioQ) and (4) a local clock. The job of the test executer unit (TEU) is to apply mutated-timed test sequences to a component, and the job of the test monitor unit (TMU) is to register the feedback from the components into execution traces, then validate them with the degraded specification. Embedding the clocks in testers, enables the tester to tell about the time an event occurred instantaneously with no communication delay. All testers’ clocks are supposed to be synchronized with a reference clock. Moreover, each tester’s clock is assumed synchronized with its corresponding component’s clock. The assumption of synchronization between a tester’s clock and the corresponding component’s clock is essential; otherwise, we will not able to tell about the clock of the blackbox component. N.B.: in this section the terms input and output are from the tester point of view.

5.3 Tester Coordination Testers communicate with each other through the input/output queues (ioQ). In their communication, the following testers’s communication scheme is respected. The output transition from tester Ti , sent as an input, to tester Tj will wait on queue ioQj until this transition is enabled in Tj . On the other hand, the execution of a communication test sequence CT sj by tester Tj will pause if this test sequence

requires Pj to wait on an input from component Pi . The execution in tester Tj will resume after receiving the needed input from tester Ti ; and thus, testers give a higher priority to handle inputs received from the components over inputs received from other testers that are stored in local testers’ queues. During the reception of inputs and the sending of outputs testers may undergo some local delays in processing some events. In order to make the execution of the SUT more realistic, such delays should be taken into account in evaluating timing conditions of events. Delays could be identified in 3 main situations, which are: delay between the instant of reception of an input from • component Pm by tester Tm and the instant of sending an output from Tm back to component Pm . • component Pm by tester Tm and the instant of sending an output from Tm to tester Ti . • tester Ti to tester Tm and the instant of sending an output from Tm to component Pm . To illustrate, consider Figure 5 and test sequences T sm = T r1m .T r2m ...T rkm T rnm executing on component Pm : T s1 = (!b; c1 > 200; −).(?a; c1 < 240; c1).(!e; c1 < 200; c1)..., and T s2 = ...(?b; c2 < 270; c2 ).(!d; c1 < 300; c1 )..., the time delay is handled as follows: th Notation 5.5 let tm transition k be the instant when the k m (T rk ) executes on component Pm . let eck be the enabling condition for the k th transition. Let Ct be the current time.

Situation 1: The tester Tm handles the first situation by m recording the instant (tm k ) of receiving an input (T rk ) from the component Pm . Tester Tm should execute the k th +1 m transition (T rk+1 ) with an enabling condition = ecm k+1 + m (Ct − tk ). For example, consider T s1 and figure 5, assume !b is received by tester T1 from component P1 at time t11 = 210, if at Ct = 260 T1 is ready to send ?a, then the enabling condition should satisfy: 240 + (260 - 210). Situation 2: The tester Tm handles the second situation by m recording the instant (tm k ) of reception of an input (T rk ) from the component Pm , then sends (forwards) it as an output to Tester Ti attaching to it (tm k ), that is, the message between testers would have the following format: M(T rkm , tm k ). For example consider T s1 and figure 5 again, assume !b is received by tester T1 from component P1 at time t11 = 210, T1 sends the message M (!b, 210) to tester T2 . Situation 3: The tester Tm handles the third situation by receiving an input in the form M(T rki , tik ) from Tester Ti . Then, when the tester Tm is ready to execute the k th + 1

m transition (T rk+1 ), it executes it with an enabling condition m = eck+1 + (Ct − tik ). For example, consider T s2 and Figure 5, with M(!b,210) from T1 , if at Ct = 280 T2 is ready to send ?b to P2 , then the enabling condition should satisfy: 270 + (280 - 210).

M(!b, 210)

T1

1

T2

?a c1 < 240

t 1 =210 !b c1 > 200 P1

?b c2 < 270

P2

Figure 5. Time delay in tester’s communication

5.4 Test Execution The time-test execution scheme is defined as follows: A time-test execution will be declared as success iff the execution of all relevant events respecting the acceptR relation respects the timing conditions of their transitions specified in the degraded system. Otherwise, it will be declared as failure. The testing execution process is done in two phases. The first phase tests the robustness of each component separately, and the second phase tests the robustness of communication among components. In both phases, each tester Tm executes, using TEU, the corresponding mutated test sequences and records, using TMU, the corresponding feedbacks from each component into execution traces without instantaneous evaluation. Next, based on the acceptR relation, we check the robustness of each recorded execution trace from each component with its corresponding degraded specification. In the first phase, we ignore all communication requests from other components; and thus, all inputs from testers are sent at the instant those inputs are needed based on the information in the nominal specification S Pm without considering the communication from any other tester Ti , and therefore, here we are checking the robustness of the component in isolation, without taking any communication input from other components. Consequently, the communication time delay is ignored in this phase since the channel between tester and its component is the same as the channel between the environment and the component itself. An execution of a mutated test sequence T sm by Tm gives a verdict success, iff, in its corresponding recorded

execution trace, the reception of outputs from "Pm " are accepted in the degraded specification SdPm and the timing constraints respect the time-test execution scheme defined above. In the second phase, respecting the tester’s communication scheme mentioned above, all testers Tm execute, using TEU, the same communication test sequence IT s generated from the communication nominal specification. Tester Ti executes only its corresponding events (transitions) in IT s ignoring all transitions for other testers. In this phase, testers are not exclusively dedicated to test only the communication but also they handle some local events; therefore, we take into consideration the time delay in tester’s communication. Testers communicate with each other via input/output queues respecting the scheme of testers’ coordination mentioned above. An execution of tester Tm to a communication test sequence IT sm gives a verdict success, iff , in its corresponding recorded execution trace, the sending of inputs and reTi ception of outputs Om from Pm or Ti are accepted in the communication degraded specification SdCm respecting the timing constraints stated by the time-test execution scheme. The advantage of phase 2 is that it would detect a nonrobust system even if each component is robust by itself. Moreover, a system’s communication would be robust even if one of the components is not robust. To illustrate, let us consider figure 5 again and the following test sequences T s1 = (!b; c1 > 200; −).(?a; c1 < 240; c1).(!e; c1 < 200; c1)..., and T s2 = ...(?b; c2 < 270; c2).(!d; c1 < 300; c1)..., two cases to be studied: case 1: Assume event "b" is not relevant in the degraded specification of component P1 , and, it is relevant in the degraded specification of component P2 , then P1 will be robust even without the occurrence of event "b". On the other hand, the system’s communication would be robust only if event b occurs; otherwise, it would not be. case 2: Assume event "e" is relevant in the degraded specification of component P1 , and, it is not relevant in the communication degraded specification. If event "e" did not occur, component P1 will not be robust, still the communication of the whole system would show robustness. The complete testing methodology is illustrated in Figure 6.

6

Conclusion and future work

Robustness testing for real-Time component-based systems is discussed in this paper. As far as we know, quite a few works has been done in this field. In this paper, we present a methodology for testing robustness of realtime component-based systems using fault injection and adequate distributed test architecture. The system communication and each component is described by its nominal

Test sequence TS1 Test sequence TS2

Mutated TS1 Test sequence Mutation

Test sequence TSn

Method

Mutated TS2 Test execution

Mutated TSn

− Phase 1 Degraded Components’ Specifications

SUT

CTS1

Verdict for the system

Test execution − Phase 2

Building Communication CTS2 Test Sequence

Verdict for each component

CTSn

Figure 6. Testing Methodology Scheme specification and its degraded one. The main contributions in this method are summarized as follows: The first contribution is using a test purpose technique to generate automatically test sequence set for each component from its nominal specification.Then, based on observation notion, the software architect inserts relevant (hazards) faults in these sequences in order to simulate hostile environment. Another contribution is handling errors produced by communication inherent to component development. The third contribution is providing an approach to handle time delays in communication between components though testers with synchronized clocks. As a future work, we intend to investigate more realistic hazard insertion by using metrics produced by real case studies. Another issue to explore is to reduce the specification of the system communication. We may focus on the description of the communication of each component alone without its interaction with other communications. We will investigate an adapted technique to generate test sequences for such model. We need also to experiment this methodology in a real case study such as industrial control software or complex embedded systems.

References [1] R. Alur and D. Dill. A theory of timed automata. Theoretical Computer Science, 126:183–235, 1994. [2] J. H. Barton, E. W. Czeck, Z. Z. Segall, and D. P. Siewiorek. Fault injection experiments using fiat. IEEE Trans. Comput., 39(4):575–582, 1990. [3] A. Bertolino, F. Corradini, P. Inveradi, and H. Muccini. Deriving test plans from architectural descriptions. In ACM Proceedings, International Conference on Software Engineering ICSE2000, June 2000, June 2000.

[4] Ed Brinksma, Geoff Coulson, and Ivica Crnkovic. Project ist-2001-34820 - artist- advanced realtime systems. roadmap: Component-based design and integration platforms. http://www.systemescritiques.org/ARTIST/. [5] H. Fouchal and A. Rollet. Embedded system testing. In Proceedings of 7th International Conference on Principles of Distributed Systems (OPODIS 2003), December 10-13 2003, La Martinique, France, volume 3144 of Lecture Notes in Computer Science. Springer, dec 2003. [6] Hacène Fouchal, Eric Petitjean, and Sébastien Salva. An User-Oriented Testing of Real Time Systems. In Proceedings of the International Workshop on RealTime Embeded Systems RTES’01 (London), IEEE Computer Society, December 2001. [7] D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch: Why reuse is so hard. IEEE software, November 1995. [8] J. Karlsson and al. Using heavy-ion radiation to validate fault-handling mechanisms. IEEE Micro, 14(1):25–40, February 1994. [9] A. Khoumsi. Testing distributed real-time systems in the presence of inaccurate clock synchronization. Journal of Information Soft. Technology (IST), 45, Dec 2003. [10] H. Schmidt. Trustworthy componentscompositionality and prediction. The Journal of Systems and Software, 65:215–225, 2003. [11] C. Szyperski. Component Software: Beyond Object Oriented Programming. Addison Wesley, Harlow, England, 1998. [12] A. Tesanovic, D. Nystrom, J. Hansson, and C. Norstrom. Towards aspectual component-based development of real-time systems. In Proceeding of the 9th International Conference on Real-Time and Embedded Computing Systems and Applications (RTCSA 2003), February 2003, February 2003. [13] J. Zalewski. Developing component-based software for real-time systems. In 27th Euromicro Conference 2001: A Net Odyssey (euromicro’01), September 2001, September 2001. [14] Peter Zimmerer. Test architectures for testing distributed systems. In 12th International software quality week (QW’99), May 1999, May 1999.