1 / 35

Automated Model-Based Testing of Hybrid Systems

13. Automated Model-Based Testing of Hybrid Systems. Michiel van Osch PROSE January 25, 2007. Motivation. Hybrid Systems Testing might be expensive, dangerous, or resources might be limited Discrete and real-time model-based testing does not test the continuous aspects of the system.

jania
Download Presentation

Automated Model-Based Testing of Hybrid Systems

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 13 Automated Model-Based Testing of Hybrid Systems Michiel van Osch PROSE January 25, 2007

  2. Motivation • Hybrid Systems • Testing might be expensive, dangerous, or resources might be limited • Discrete and real-time model-based testing does not test the continuous aspects of the system

  3. Content • Part I: Theory • Model-based Testing • Input-Output Conformance & Discrete Tests • Hybrid Systems • Hybrid Input-output Conformance • Hybrid Tests • Results • Part II:Tool • Test Architecture • Specification • Tester • The Connection with the Implementation Under Test • Adapter • Limitations and Future Work • Case Study: Vacuum Control

  4. IUTconfmodel test tool test generation tool IUTpassestests  exhaustive sound test execution tool passfail Model-Based Testing model IUT conforms to model SUT

  5. Input-output Conformance for Discrete Systems If there is an output action from state s then out(s) = {o in O| s →} else out(s) = {δ} Furthermore, out(S) = UsS out(s) Impl. ioco Spec. iff for all traces α: out(Impl. after α)  out(Spec. after α)

  6. Test-case Generation and Execution • Terminate with verdict pass • Select an input from the specification and apply it to the implementation • Observe an output or a timeout from the implementation and check if it is allowed according to the specification

  7. t0 ?Activate t1 !XLCoffee !Coffee ! δ Fail t2 Fail ?Button2 t3 !Coffee ! δ !XLCoffee Fail Pass Fail Example s2 !Coffee ?Button1 ?Activate s0 s1 !XLCoffee ?Button2 s3

  8. Hybrid Systems • In Practice: • Discrete behavior plus continuous behavior • Continuous behavior can be input observed through sensors or output generated by actuators • In Theory: • Discrete actions plus flow of continuous variables (trajectories) • Variables can be input variables and output variables • Hybrid Transition Systems

  9. ?Button2 ?Button1 Hybrid Systems (Output Only) s2 Coffee’ = 3 cl/sec. Δt = 5 sec. ?Button1 ?Activate s0 s1 Coffee’ = 0 Δt = 1 sec. Coffee’ = 0 Δt = 1 sec.. Coffee’ = 4 cl/sec. Δt = 8 sec. ?Button2 s3 Coffee 0 Time

  10. Hybrid Systems (Including Input) s2 Water Water’ = 3 cl/sec. Coffee’ = Water’ Δt = 5 sec. ?Button1 ?Activate s0 s1 Water’ = 0 Coffee’ = 0 Δt = 1 sec. Water’ = 0 Coffee’ = 0 Δt = 1 sec.. Water’ = 4 cl/sec. Coffee’ = Water’ Δt = 8 sec. ?Button2 s3

  11. Hybrid Conformance • For every reachable state, the set of output actions possible by the implementation is a subset of the set of output actions possible by the specification • For every reachable state, the set of trajectories possible by the implementation is a subset of the set of trajectories possible by the specification • In contrast to ioco, no quiescence action because there is always continuous output.

  12. Continuous Output Only s2 Coffee’ = 3 cl/sec. Δt = 5 sec. ?Button1 ?Activate s0 s1 Coffee’ = 0 Δt = 1 sec. Coffee’ = 0 Δt = 1 sec.. Coffee’ = 4 cl/sec. Δt = 8 sec. ?Button2 s3 Impl. is input-output conform a Spec. iff for all traces α: out(Impl. after α)  out(Spec. after α) and traj(Impl. after α)  traj(Spec. after α)

  13. Impl. is input-output conform a Spec. iff for all traces α: out(Impl. after α)  out(Spec. after α) and traj(Impl. after α)  traj(Spec. after α) Does not work!! With Continuous Input • The implementation is input enabled (for both discrete behavior and continuous behavior). • We do not require the specification to be input complete. Solution: Look at the trajectories of the Implementation with respect to the trajectories of input variables of the Specification

  14. Still does not work because … u1 s1 Water’ = 0 Coffee’ = 0 Δt = 1 sec.. Water’ = 0 Coffee’ = 0 Δt = 1 sec.. ?Button2 ?Button2 Water’ = 0 Coffee’ = 0 Δt = 1 sec.. u3 s3 Water’ = 0 Coffee’ = 0 Δt = 3 sec.. Water’ = 0 Coffee’ = 0 Δt = 3 sec.. u4 u5 s4 s5 !Out of Cups !Out of Cups Water’ = 0 Coffee’ = 0 Δt = 1 sec.. Water’ = 0 Coffee’ = 0 Δt = 1 sec.. Implementation Specification Hybrid Conformance (Continuous Input plus Output) infilter(traj(Impl. after α), traj(Spec. after α))  traj(Spec. after α)

  15. Hybrid Conformance (continuous input plus output) If there is a trajectory from state s then out(s) = {o in O| s →}  {ξ} else out(s) = {o in O| s →} Impl. hioco Spec. iff for all traces α: out(Impl. after α)  out(Spec. after α) and infilter(traj(Impl. after α), traj(Spec. after α))  traj(Spec. after α)

  16. Hybrid Tests A Special kind of Hybrid Transition Systems: • Tree like structure • Two terminal states: pass and fail • Deterministic for actions • Strongly time deterministic for trajectories

  17. t0 ?Activate s0 s1 Water’ = 0 Coffee’ = 0 ?Activate t1 Specification Test Hybrid Tests • Terminate with verdict pass • Select an input from the specification and apply it to the implementation

  18. Coffee’ = 0 Water’ = 0 Δt = 1 t4 !”Out of Cups” s4 s5 !”Out of Cups” Pass Fail Fail Coffee’ = 0 Water’ = 0 Δt = 1 Specification Test-Case Hybrid Test-case Generation • If an output action has to happen immediately according to the specification then observe an output action and check if it is allowed according to the specification or let time pass by selecting and applying and observing a trajectory

  19. t1 s1 Water’ = 0 Coffee’ = 3 Δt = 1 Water’ = 0 Coffee’ = 0 Δt = 1 !”out of cups” Water’ = 0 Coffee’ = 0 Δt = 1 Fail Fail t2 Fail Fail Specification Test Hybrid Test-case Generation • Select an input trajectory from the specification, apply it to the implementation and observe the output trajectory simultaneous, possibly interrupted by an output action.

  20. Results • A hybrid conformance theory • Proven Sound and exhaustive • A Natural extension of discrete and timed conformance theories

  21. Content • Part I: Theory • Model-based Testing • Input-Output Conformance & Discrete Tests • Hybrid Systems • Hybrid Input-output Conformance • Hybrid Tests • Results • Part II: Tool • Test Architecture • Specification • Tester • The Connection with the Implementation Under Test • Adapter • Limitations and Future Work • Case Study: Vacuum Control

  22. Tester Architecture • Specification: The Model from which Tests are Generated • Tester: Implements The Test Algorithm and Gives the Verdict • Adapter: Translated Input/Output from Model to a format suitable for the Implementation Under Test and vice versa • Medium: The Interface between Tester and Implementation • IUT: The Implementation Under Test Libraries Medium IUT Spec Tester Adapter

  23. Specification Needs to: • Model Discrete behavior and Continuous Behavior • Make Distinction between Input Actions, Output Actions, and Internal Actions • Make Distinction between Input Variables, Output Variables and Internal Variables • Model in an Intuitive way Libraries Medium IUT Spec Tester Adapter

  24. Specification Libraries Medium IUT Spec Tester Adapter proc Control(cont V: real, chan h,out: real)= |[ *(V <= 2 -> h!!1.0; out!!1.0 ; V >= 10 -> h!!0.0; out!!0.0) ]| proc Env(cont V: real, chan h: real)= |[ var n: real = 0.0 :: V’=3.0*n - 1.0 | *(h?n) ]| model Spec()= |[ cont V: real = 10.0, chan h,out: real :: Control(V,h,out)|| Env(V, h) ]|

  25. Tester Implements: • On the Fly Test Generation • Select Input from Specification • Apply Input • Observe Output • Compare the Observed Output with the Output allowed by the Specification • Give a Verdict or Continue Test Libraries Medium IUT Spec Tester Adapter

  26. proc ControlS(cont V: real, chan h: real)= |[ var n: real = 0.0 :: V’=3.0*n - 1.0 | *(V <= 2 -> n:=1.0; h!!1.0 ; V >= 10 -> n:=0.0; h!!0.0) ]| model Spec()= |[ cont V: real = 10.0, chan h: real :: ControlS(V,h) ]| Select Input (χ)(Manually/ Automatic) Apply (Via adapter) V=10 V’=3.0*0.0-1.0 Δt = 8 sec. V=2 Pressure’= -1.0 mbar/sec Δt = 8 sec. IUT Observe (Via adapter) Compare Values (χ , Maple) Continue V=2 h!!0.0 IUT h!!1.0 Pump OFF Give Verdict (with trace) fail pass Pass On the Fly Testing

  27. Additional Libraries • χ–stepper for computing sets of allowed transitions and current state of the specification • E.g. Maple for comparing observed continuous output (samples) with specified trajectories and comparing observed discrete output values with specified send actions Libraries Medium IUT Spec Tester Adapter

  28. Jabber χModel Labview Controller TCP/IP Wires Electronics Buttons/ Sensors Robot Arm The Connection Libraries Medium IUT Spec Tester Adapter

  29. The Adapter • Implements • Mapping of Variables/Actions of Specification to a Implementation and vice versa (e.g. channels to function calls , or variables to wires) • Translating Input/Output of Specification to Implementation and vice versa (e.g. functions to samples, or signals) Libraries Medium IUT Spec Tester Adapter

  30. Limitations and Future Work • This is just a prototype, there are shortcomings! • Real Time Testing is Not Possible Yet • The complexity of Continuous behavior is limited by the Hybrid χ–stepper implementation. E.g. currently only standard differential equations. • Models are not ‘ideal’ for testing. E.g. in case of identifying input and output • For performance reasons we only deal with deterministic specifications. • We assume that the communication medium is reliable • Adaptation of theory for Sampling and Inaccuracy • Case Studies

  31. Real Time • Generating and applying input (e.g. samples) • Observing output and Time at which output Occurred in the Implementation

  32. Limitations and Future Work • This is just a prototype, there are shortcomings! • Real Time Testing is Not Possible Yet • The complexity of Continuous behavior is limited by the Hybrid χ–stepper implementation. • Models are not ‘ideal’ for testing. • For performance reasons we only deal with deterministic specifications. • We assume that the communication medium is reliable • Adaptation of theory for Sampling and Inaccuracy • Case Studies

  33. Lithography Process takes place in vacuum Waferstepper has Five Chambers Chambers are kept in Vacuum by a system of Pumps and Valves Pumps and Valves are Controlled by Software (discrete) Software observes Pressure in Chambers through Sensors (continuous) The Vacuum Case

  34. Activities • Modeling Hardware in Hybrid χ and Stand Alone Simulation • Modeling (translating) Hardware in discrete (timed) χ and Integration with Software Controller • Modeling (translating) in Uppaal for Model Checking • Testing Models and Software Controller with the Hybrid Tester

  35. Questions?

More Related