A Concept for Testing and Diagnosis of Embedded Systems based on Extended Finite States Machines

1. A Concept for Testing and Diagnosis of Embedded Systems based on Extended Finite States Machines A. Guerrouat, H. Richter Clausthal University of Technology Germany SV'04

2. Overview • Motivation • Basic Structure of Embedded Systems • Diagnosis System Development • Formal Specification • Test Generation • Observation • Fault Model/Error Diagnosis • Knowledge Representation • Diagnosis Example • Summary and Future Works SV'04

3. Motivation • Successfully use of knowledge-based and expert systems in diagnosis tasks • Availability of testing and analysis methods for communicating systems and protocols • Costly and error-prone software development cycle for embedded systems • Formal techniques highly recommended in safety-critical systems • Formal methods allow abstraction, understandability, analysis, scalability and non-ambiguity • Formal description techniques are based on EFSMs and allow both a formal syntax and a formal semantic SV'04

4. Basic Structure of Embedded Systems SV'04

5. Diagnosis System Development SV'04

6. Formal Specification (1) • EFSMs (Extended Finite State Machines) • Models both the behaviour and data flow • Basis for FDTs (Formal Description Techniques): SDL and Estelle • Defined as 7-Tuple <S, C, I, O, T, s0, c0> S: Set of main states; C: Set of contexts; I: Set of Inputs; O: Set of outputs; T: Set of transition relations; s0S: Initial main sate; c0C: Initial context of the EFSM Transition tT: 6-tuple <s, c, i, o, s, c´> SV'04

7. Formal Specification (2) SV'04

8. Formal Specification (3) • EFSMs describe dedicated functions as processes in FDTs • A system: A collection of concurrently-running blocks or modules • Blocks/modules communicate through signals (broadcasting events) via channels • Block/module: Collection of concurrently-running processes (EFSMs) • Sensors, controller and actuators are modelled as blocks/modules where communication obeys to some hierarchy • Easy mapping between EFSM specifications and behavioural parts of SDL blocks or SDL modules SV'04

9. Observation • Observed behaviour: Set of interaction sequences i (IxO)* obtained by running test cases on the IUT • I: Set of inputs; O: Set of outputs • Run of a test case on an implementation (test case execution) is a function: • exec:TxI O T: Set of test cases, I: Set of implementations O  (IxO)* is a set of observations • Test result defined by verdict assignment • verdict: TxO {pass, fail, inconclusive} • Assuming a given test architecture (not the scope of this work) SV'04

10. Test Generation • Test case derivation are based on FSM test sequence generation methods: • Transition Tour, Distinguishing Sequences, etc. • Basic idea - A test sequence: • is preferably a short sequence of consecutive transitions that contains every transition of the FSM at least • allows to check whether every transition is implemented as defined • A black-box testing: only input/output interactions are observable at the environment interface SV'04

11. Fault Model/Error Diagnosis • Fault model for a state transition-based system uses error classes because of the huge number of potential error cases in ES: • Erroneous transitions - includes many error subclasses: interaction point errors, output errors, parameter errors, predicate errors, delay errors etc. • Missing and additional transitions: • Interactions are not present in the observation regarding the specification • Interactions are not present the specification • Efficiently error diagnostic need appropriate knowledge representation formalisms • EDiagnostiquor: composed from a rule base and object base containing error diagnostic knowledge and fact and data needed for inferencing: specification, fault models, observations and diagnosis reports explaining the error reasons • Diagnostic knowledge is based on rules of the form: If a diagnostic D causes the symptom S and S is observed then D is a possible explanation of S and perform actions SV'04

12. Diagnosis Example (1) SV'04

13. Diagnosis Example (2) • For each observation i(1i5): exec(tci,I)= i and verdict(tci,i)=”fail” • Phase 1 (detecting all invalid interaction sequences): • 1=”!C.EV8; ?A.EV5; !C.EV6; ?C.EV7; !C.EV1(3); ?C.EV2(1,1)” *** interaction 2: erroneous interaction point *** • 2=”!C.EV8; ?C.EV5; !delay(5); ?timeout(5); !C.EV6; ?C.EV7” *** interaction 4: occurring of time out *** … • Phase 2 (determing the non-conformance reasons of the IUT): • *** interaction 2: erroneous interaction point --- interaction 2 must be ?C.EV5 *** • *** interaction 5: expected interaction must occur within time limit 5 *** ... SV'04

14. Summary and Future Work • Test derivation and error diagnosis are time consuming in the design of reliable ES • Error diagnostic require a lot of knowledge and experience to explain possible systems disturbances and failures; this implies the definition of appropriate fault models • Special knowledge and appropriate knowledge representation formalisms are needed to diagnose faulty implementations in respect to the specification • In a future work a case study of real-life embedded systems (the automotive) will be performed • Involving other specification approaches SV'04