Formal Foundation to Systematic Development of Simulink/Stateflow Models

1. Formal Foundation to Systematic Development of Simulink/Stateflow Models Manoranjan (Mannu) Satpathy, S. Ramesh General Motors India Science Lab Bangalore, India

2. India Science Lab • Set up in 2003 in Bangalore • Three major groups related to Computer Science • Control Software Engineering Methods and Tools Group • Vehicular Communication & Info. Management • System and SW Architectures • Control Software Engineering Methods and Tools Group • 10 PhDs + 6 Masters

3. Automotive Control S/W: Future Trends • Feature enhancement • X-by-wire systems • Lane, obstacle and occupant aware • Limited Autonomy to Complete Autonomy • DARPA Grand Urban Challenge • Hybrid vehicles

4. Current Process e.g. Cruise ControllerX-by-Wire FEATURES DESIGNMODELS C code UML Simulink/Stateflow Distributed Implementation:FlexRay, CAN, Autosar

5. Outline • Simulink/Stateflow Models • Problems with Current Process • Linking Event-B & Simulink/Stateflow • An Example

6. Simulink/Stateflow Simulink/Stateflow environment from Mathworks is now the de-facto standard in industry for model based development of hybrid controllers automotive & aerospace All critical automotive s/w, written using SL/SF Engine control, Chassis control etc.

7. Simulink/Stateflow (SL/SF) SL/SF is a block structured language; a model consists of blocks (either Simulink or Stateflow); blocks are connected by wires which carry signals Blocks are functions that compute outputs depending upon inputs and state Simulink: modeling of continuous dynamics Stateflow: modeling of discrete control logic

8. A SL/SF Model

9. Discrete behaviour in Stateflow

10. Validation Numerical simulation is the primary mechanism for model validation and analysis by engineers SL/SF blocks are executed in a pre-defined ordr in each simulation step. This is repeated for a certain duration. Sampling interval Of late tools like Design Verifier –performs bounded & unbounded MC to prove properties

11. Feature to Design: Problems FEATURES • Obtaining a design model from feature requirements is a big step • Mostly manual, trial-and-error approach, based on experience, and errors may creep in • Intermediate steps are primarily mental models which usually do not have representations • A lot of testing/ simulation are performed on the model to have a confidence in design MANUALPROCESS UML/C-code

12. Our Aim FEATURES • To systematize the FEATURE-TO-DESIGN step • To formalize the FEATURE-TO-DESIGN step • Technique: Use of ANALYSIS MODELS MANUALPROCESS UML/C-code

13. Analysis models • Primary purpose is formal verification • SYSTEMATIC: A chain of incremental steps; so likelihood of error is less • FORMAL: Rigorous correctness preserving transformations • Intermediate artifacts have clear mathematical representations • Allow multiple design choices (CAN based, FlexRay based, Autosar based designs) • Incremental steps are manual, but rigorous verification using tool support (technique: theorem proving) • Design models can also be obtained from analysis models • No testing/simulation is necessary FEATURES DESIGNMODEL

14. Automatic finite-state verification techniques like model checkingface the state space explosion problem. Such techniques also may not be practical for complex or parametric designs • Theorem provingtechniques are inevitable to cope with new verification Challenges. • [Berezin, CMU PhD thesis] • Ed Clarke: supervisor

15. Integration of Event-B method to current process Control System Requirements Model M1 (in B) Model M2 (in B) Model Mk (in B) SL/SF model will be correct w.r.t. requirements. B-to-SL/SFTranslation

16. Why SL/SF? • Practitioners understand it well • One way of convincing the client • Existing Mathworks infrastructure • HLL (Hardware in Loop) testing • AUTOSAR bench • FlexRay bench

17. Cruise Control

18. Cruise Controller cc_switch throttle_angle brakeP throttleP vspeed resume set accl dccl

19. INITIAL MODEL : Pictorial presentation Depending on cc_switch state, the abstract model outputs  cc_witch (switch)   [0,90] throttle_angle () Next refinement : switch determines cc is in active or passive mode;  depends on mode

20. 1st Refinement switch determines cc_active;  depends on cc_active. cc_active switch    [0,90] Next refinement: cc_active depends on other inputs

21. 2nd Refinement switch & cc_cond determines cc_active.  depends on cc_active. cc_active switch    [0,90] cc_cond Next refinement: cc_cond depends on other inputs

22. 3rd Refinement 1  switch cc_active brakeP cc_cond throttleP 2 vspeed Next refinement: CC_active depends on other inputs

23. 4th Refinement 1  switch cc_active brakeP tspeed throttleP 2 cc_cond vspeed Next refinement:  & vspeed are unrelated

24. 5th Refinement 1  switch cc_active brakeP tspeed throttleP 2 cc_cond vspeed PLANT vs’ = f(vs,) Next refinement: plant is not a part of the controller

25. Final Refinement 1 cc_cond  switch  cc_active brakeP tspeed 2 throttleP vspeed resume set accl dccl PLANT vs’ = f(vs,) sensed_speed actuator_signal

26. B2SLSF • Close correspondence between the diagrams discussed and the Event-B models • Diagrams have a Simulink/Stateflow flavour • Sequencing structure in an Event-B model can be automatically derived • Similar to the sequencing structure in our diagrammatic notation

27. Translation to Stateflow block Sequencing structure can be derived from Event-B models Sequencing is similar to diagrams

28. Pattern-driven SL/SF block generation Any brp, thpWHERE brp BOOL thp  BOOLTHEN brakeP := brp throttleP := thpEND brakeP cc_cond throttleP vspeed Any vvWHERE vv  0 .. MAXSPEEDTHEN vspeed := vvEND brakeP, throttleP & vspeed become inputs to the SL/SF model PLANT vs’ = f(vs,)

29. Computation becomes Simulink Block brakeP F(brakeP, throttleP,vspeed) throttleP cc_cond vspeed cc_cond = brakeP=F  throttleP = F  vspeed >= MINCSPEED

30. Translation to Stateflow block Each function has form F(x,y,z) = (x,y) with x enumerated

31. sw sw=off (sw = on  (cond=F  set=F)) cond state = init state sw=on  cond=T  set=T vspeed tspeed switch=off switch=off set sw=on  state = active sw=on  cond=F sw=on  state = inactive tspeed accl / tspeed := vspeed dccl (sw = on  (accl=T  dccl=T) sw=on  cond=T  resume=T res

32. SL/SF Model state sw brP F(brP,thP,vspeed) STATEFLOW cond tspeed thP vspeed in 1/S PLANT vs’ = f(vs,) (tspeed–vspeed)/2) IF (state=active) out

34. State behaviour in Stateflow

35. Future Work • Development of an Automatic Translator from Event-B to SL/SF models • Other Challenges • Modeling of continuous dynamics • Distributed Modeling • Timing issues • Feature Interaction

36. Thank You.