An Integrated Framework for Validating Model-based Embedded Software
This presentation is the property of its rightful owner.
Sponsored Links
1 / 33

An Integrated Framework for Validating Model-based Embedded Software Li Tan PowerPoint PPT Presentation


  • 84 Views
  • Uploaded on
  • Presentation posted in: General

An Integrated Framework for Validating Model-based Embedded Software Li Tan University of Pennsylvania September, 2003. Outline. Motivations The overview of our approach Model-based monitoring. Monitoring hybrid automata From logic specification to model-based monitor

Download Presentation

An Integrated Framework for Validating Model-based Embedded Software Li Tan

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


An integrated framework for validating model based embedded software li tan

An Integrated Framework for Validating Model-based Embedded Software

Li Tan

University of Pennsylvania

September, 2003

Testing and Monitoring at Penn


Outline

Outline

  • Motivations

  • The overview of our approach

  • Model-based monitoring.

    • Monitoring hybrid automata

    • From logic specification to model-based monitor

    • Model instrumentation

  • Model-based testing

    • Creating and refining model-based testers

  • The case study on SONY AIBO Dog

    • Design-level validation

    • “on-board” validation

  • Conclusion

Testing and Monitoring at Penn


Motivations

Motivations

  • Implementing state-of-art validation technique is a painful and costly process.

    • Validation requires special instrument/programs.

    • The details/interfaces of targeted tools are not always available.

  • Lack of an integrated solution for both design-level and implementation-level validations.

    • Difficult to relate the result of design-level validation with implementation-level validation.

  • Bringing formal methods techniques down to implementation level is challenging.

    • Validation directly on targeted hardware platform is much needed in designing model-based embedded software.

Testing and Monitoring at Penn


The outline of our approach

The outline of our approach

  • Goal: introducing state-of-art validation techniques to model-based software design domain using existing tools and techniques.

  • Solution: a model-based validation technique for model-based software design.

  • A four-step plan.

    • Synthesizing model-based monitor from the logic specification.

    • Creating model-based tester from the testing criteria.

    • Design-level validation: simulating self-monitoring and self-testing model.

    • Implementation-level validation: generating self-monitoring and self-testing code for target hardware from the composed model.

Testing and Monitoring at Penn


An overview

System model

Tester Model

Instrumented

model

Monitor Model

Design Level Validation

Composed Model

Simulator

CodeGenerator

Self-testing

and Self-monitoring Code

Implementation Level Validation

An overview

Coverage

Criteria/

environment

constrains

MEDLspecification

Model

Instrumentation

Monitor

Synthesizer

Coverage

Checker

Testing and Monitoring at Penn


The details of our plan

The details of our plan

  • Modeling language: Charon for hybrid systems. Charon toolkit has,

    • A simulator.

    • A code generator to C++.

  • Model-based testing and monitoring.

    • Testing: working well on implementation level.

      • Need be extended to model level

    • Runtime verification: checking the execution of software system.

      • Need be extended to hybrid systems

  • SONY AiBo Robot Dog: a hands-on example.

    • The controller for its head is generated from a Charon model.

Testing and Monitoring at Penn


Outline1

Outline

  • Motivations

  • Overview of our approach

  • Model-based Monitoring.

    • Monitoring hybrid automata

    • From logic specification to model-based monitor

    • Model instrumentation

  • Model-based Testing

    • Creating and refining model-based testers

  • Case study on SONY AIBO Dog

    • Design-level validation

    • “on-board” validation

  • Conclusion

Testing and Monitoring at Penn


Runtime verification

Runtime verification

Runtime verification (monitoring) is to check an execution of a program again its temporal logic specification

Java Programs

MEDLspecification

MEDL compiler

Program

Instrumentation

Monitoring script

events

Java Programs

+Filter

Monitor

Computer

Testing and Monitoring at Penn


Monitoring hybrid automata

System Automaton

System Automaton

Filter

Monitoring Automaton

Monitoring hybrid automata

MEDLspecification

Model

Instrumentation

Medl2Charon Monitor Synthesizer

Instrumented Model

Simulator

Testing and Monitoring at Penn


Hybrid automata

Hybrid Automata

  • A hybrid automaton A={S, V, T, G, W, D, A, I, s0} extends a EFSM {S, V, T, G, W, s0} with continuous behaviors

    • S is the set of modes

    • V is the set of variables

    • T=V£ V is the set of transitions

    • G assigns each t 2 T a guard, a predicate over V.

    • W assigns each t 2 T an assignment for Vµ V.

    • D assigns each s 2 S a set of differential equations over .

    • A assigns each s 2 S a set of algebra equations over V.

    • I assigns each s 2 S an invariant, a predicate over V.

    • s02 S is the initial mode.

Testing and Monitoring at Penn


An example dog head controller

An example: Dog Head Controller

  • Hybrid automata can be composed concurrently.

  • Hybrid automata can be composed hierarchically.

    • A location can be a collection of sub-locations.

|| >10?

x 45?

x

.

x = -10

x -46

x -45

: The visibility of the ball

x: The angle of the head

: The angle of the ball

||  10?

Testing and Monitoring at Penn


Medl expressing your properties

MEDL: expressing your properties

  • MEDL (Meta Events Definition Language) is a linear interval temporal logic for specifying safety properties.

    • MEDL is initially introduced for monitoring Java programs in MaC (Monitor and Checking) System [KKL01]

  • Syntax

    • Defined on conditions, events, and expressions.

      C := defined(C) | [E, E) | : C | C && C | C||C | Q  Q

      E := e | start(C) | end(C) | E || E | E&&E | E when C

      Q := time(E) | c |Q }Q

      Where e is primitive event, c is a constant, 2 {>, <, =}, and }2 {*,/,+,-}

.

Testing and Monitoring at Penn


Informal medl semantics

(Informal) MEDL semantics

Interpreting MEDL on runs of hybrid automata,

  • A condition C maps a time period with true, false, or undefined. If C is,

    • [E1, E2). C is true from event E1 to E2 (not included)

    • C1&&C2. C is true when C1 and C2 are both true.

    • C1||C2. C is true when either of C1 and C2 is true.

    • : C1. C is the dual of C1.

  • An event E maps a time instance with true or false. If E is,

    • start(C). E occurs at the time C becomes true.

    • end(C). E occurs at the time C becomes not true.

    • E1||E2. E occurs when either E1 or E2 occurs.

    • E1&&E2. E occurs when both E1 and E2 occur.

    • E1 when C. E occurs when E1 occurs and C is true

  • Q is an expression. If Q is,

    • time (E). Q’s value is the latest time E occurs.

    • Q1} Q2. Q’s value is Q1} Q2.

.

Testing and Monitoring at Penn


An example

An example

  • If the dog loses the ball 50 seconds after the ball becomes visible, an alarm should be raised.

    Begin

    import event isVisible, isInvisible, track,lost;

    condition visible= [isVisible, isInvisible);

    event becameTruelost= lost when visible;

    alarm lostTrack=start (time(becameTruelost)-time(isVisible)>50);

    End

    • isVisible, isInvisible, track, and lost are primitiveevents

      • isVisible (isInvisible) occurs when  >10 becomes true (false).

      • Lost (track) occurs when |-x| > 10 become true (false).

    • An alarm is an event which indicates the violation of the safety requirement.

.

Testing and Monitoring at Penn


From spec to monitor

From Spec to Monitor

  • Monitoring hybrid automaton A is synthesized from its MEDL specification S,

    • For each event E in S,

      • Variable VE in A records the latest time E occurs.

    • For each condition C in S

      • Variable VC in A records the current value of C.

      • Variable VC- in A records the previous value of C.

      • Variable VCl records the latest time C changes.

    • For each expression Q in S

      • Variable VQ in A records the value of Q.

.

Testing and Monitoring at Penn


The monitor synthesizing algorithm 1

The monitor-synthesizing algorithm (1)

The translation is highly modularized,

  • Each condition, expression, and event is translated to an automaton just for it.

    • Each has a token ID Pc reflecting its syntactical order in MEDL script.

    • Each automaton is enabled only if the token is passed to it (P=Pc)

  • t records the occurrence timeof the primitive event being processed.

.

(a) C=: C1

Testing and Monitoring at Penn


The monitor synthesizing algorithm 2

The monitor-synthesizing algorithm (2)

(b) C=[E1, E2)

.

(c) E=start(C)

(d) Q=time(E)

Testing and Monitoring at Penn


The monitor synthesizing algorithm 3

Monitoring Automaton

Automaton e1

Automaton Cn

Engine Automaton

The monitor-synthesizing algorithm (3)

  • Monitor is the composition of engine automaton and the automata for events, conditions, and expression.

    • Engine automaton checks incoming event and initialize the token.

.

Event, Condition, and Expression Automaton

Token flow

  • Alarm/event detecting is indicated by the value change on the event variable.

    • VE records the time E occurs in the model.

Testing and Monitoring at Penn


Outline2

Outline

  • Motivations

  • Overview of our approach

  • Model-based Monitoring.

    • Monitoring hybrid automata

    • From logic specification to model-based monitor

    • Model instrumentation

  • Model-based Testing

    • Creating and refining model-based testers

  • From Simulation to Implementation

  • Case study on SONY AIBO Dog

    • Design-level validation

    • “on-board” validation

  • Conclusion

Testing and Monitoring at Penn


Model instrumentation 1

Model Instrumentation (1)

Monitor observes primitive events emitted by system model.

  • Event is emitted via shared variables

  • (Option I) Model modification.

|| >10?

x 45?

x -45

||  10?

Testing and Monitoring at Penn


Model instrumentation 11

Model Instrumentation (1)

Monitor observes primitive events emitted by system model.

  • Event is emitted via shared variables

  • (Option I) Model modification.

|| >10?VisVisible=t, newEvent:=true

|-x| 10?Vtrack=t, newEvent=true

x 45?

x -45

|-x| >10?Vlost=t, newEvent=true

||  10?VisInvisible=t, newEvent=true

Testing and Monitoring at Penn


Model instrumentation 2

Model Instrumentation (2)

  • (Option 2) Model Augmentation

    • A observer automaton (filter) is concurrently composed with the model.

    • The structure of the model will not be changed.

|| >10?

Filter

x 45?

|-x| >10?Vlost=t,newEvent=true

|| >10?VisVisible=t,newEvent=true

|-x|10?Vtrack=t,newEvent=true

||10?VisInvisible=t,newEvent=true

x -45

||  10?

Testing and Monitoring at Penn


Outline3

Outline

  • Motivations

  • Overview of our approach

  • Model-based Monitoring.

    • Monitoring hybrid automata

    • From logic specification to model-based monitor

    • Model instrumentation

  • Model-based Testing

    • Creating and refining model-based testers

  • Case study on SONY AIBO Dog

    • Design-level validation

    • “on-board” validation

  • Conclusion

Testing and Monitoring at Penn


Modeling testing task

Environ. Model

System Model

Tester Model

Modeling testing task

Tester model reassembles a virtual environment which supplies test trace

Environment /hardware constrains

+

Simulator

No

Determination

Coverage

Criteria

Coverage

Checker

Yes

Test Trace

Testing and Monitoring at Penn


Modeling tester an example 1

Modeling tester: an example (1)

  • Testing requirements.

    • Testing should cover all the locations in system model.

    • Testing should check the dog’s behavior when it lose the ball.

  • Step I: Modeling the environment as a non-deterministic hybrid automaton.

true?=0

true?d=d-10

true?d=d+10

=0

=0

true?b=b+0.1

true?b=b-0.1

true?a=a+0.005

true?a=a-0.005

true?=20,t=0

Testing and Monitoring at Penn


Modeling tester an example 2

Modeling tester: an example (2)

  • Step II: Select a simulation trace as test case.

time

  • Step III: Determinate environ. model for the test case

u=10?=20,t=0,a=0.025,b=0.2,d=90

Testing and Monitoring at Penn


Outline4

Outline

  • Motivations

  • Overview of our approach

  • Model-based Monitoring.

    • Monitoring hybrid automata

    • From logic specification to model-based monitor

    • Model-based instrument

  • Model-based Testing

    • Create environment model

    • Obtain model-based tester model from environment model

  • Case study on SONY AIBO Dog

    • Design-level validation

    • “on-board” validation

  • Conclusion and related works

Testing and Monitoring at Penn


Design level validation

Design-level validation

  • The composition of instrumented model, tester, and monitor forms a self-validating Charon model

    • Tester supplies test trace during simulation

    • The occurrence of an event is indicated by the value of event variables during simulation

(a) Alarm Detection

Testing and Monitoring at Penn


Design level validation1

Design-level validation

(b) Primitive Events Emitted by Instrumented Model

(c) The simulation trace of monitor

Testing and Monitoring at Penn


Implemtation level validation

Implemtation-level validation

Monitoring automaton

System Model

Testing automaton

Modular compilation

Monitor

Generated Code

Tester

Link as needed

Testing and Monitoring at Penn


Implementation level validation

Implementation-level validation

  • The alarm is used for calling the external functions to report error.

    • “play” function is called when an alarm lostTrack is detected

  • The space overhead of tester and monitor.

Testing and Monitoring at Penn


Conclusion

Conclusion

We proposed a framework for testing and monitoring model-based embedded systems.

  • The approach works directly on models.

    • Monitor and tester tasks are specified in the high-level modeling language.

    • It doesn’t require the changes on simulator etc.

  • The framework is for both design-level and implementation-level validations.

    • The results on implementation-level validation may be linked to design-level validation.

  • It produces a self-testing and self-monitoring code for embedded system

    • Monitor and tester are executable on the targeted hardware platform

    • Validation is done directly on “board”.

Testing and Monitoring at Penn


An integrated framework for validating model based embedded software li tan

Thank you!

Testing and Monitoring at Penn


  • Login