Tools for the Model-Based Development of Certifiable, Dependable Systems

1. Tools for the Model-Based Development of Certifiable, Dependable Systems Michaela Huhn Hardi Hungar Doron Peled

2. Tools for the Model-Based Development of Certifiable, Dependable Systems • Certification means • Evidence required • Formal methods recommended for software construction • Alternatives: semi-formal methods, structured methods (SADT, B, …) • Current state: • Juridical proof that everything has been performed: • thoroughly, • with adequate care, • According to guidelines (or good arguments for deviations) • Example: According to the standard EN 50129 conditions for safety acceptance of railway applications are: • Evidence of quality management • Evidence of safety management • Evidence of functional and technical safety Hardi HungarR&D Div. Safety-Critical Systems

3. This means ... • Lots of documentation • On the system requirements • On the development history • Requirement tracking • On the people involveaxsad, their background, their professional skills and their role in the project • Verification and validation activities • On the tests • Requirements coverage • Definitions • Protocols • All of this has to be inspected .... • Very expensive, highly redundant activities, • (successful in practice, though) Hardi HungarR&D Div. Safety-Critical Systems

4. Certification – A Challenge for Formal Methods Hardi Hungar OFFIS Oldenburg Germany Hardi HungarR&D Div. Safety-Critical Systems

5. Certification – A Challenge for Formal Methods • The vision for certification: • Turn the juridical proof into a mathematically rigorous one. Requirements System =| Hardi HungarR&D Div. Safety-Critical Systems

6. Mathematical Rigour – What Does It Take? Complete Rigourous Consistent Requirements System =| Complete Trustworthy or Checkable Hardi HungarR&D Div. Safety-Critical Systems

7. Validation Verification Testing Verification Reports Development Process (Software) System Specification System Requirements System Architecture System Integration Software Specification Software Requirements Test Specification Software Validation SW Architecture & Design Software Architecture Software Design SW Design Test Specification Software Integration SW Coding & Module Test Software SW Module Test Specification Hardi HungarR&D Div. Safety-Critical Systems

8. Illustration: Case Study Level Crossing Supervision signal Activation sensor Gate Lights (yellow,red) Hardi HungarR&D Div. Safety-Critical Systems

9. Level Crossing: Requirements Regular Behaviour • Initial Condition: Lights are off, the gate is open, no train around, the supervision signal is off, the controller is in the unsafe mode • Trigger Condition: A train passes the activation sensor, which sends the occupied signal • The controller enters the saving mode, the yellow light is switched on • Three seconds later, the red light is switched on, the yellow light is switched off, the controller enters the saved mode, the supervision signal is set to show a blinking light • Twelve seconds later, the controller initiates lowering of the gate • The gate reaches its lower position within six seconds, • The controller enters the mode saved and gates closed • The train passes the deactivation sensor which sends the free signal • The controller turns off the supervision signal and the red light and initiates raising the gate • The gate reaches its upper position within six seconds • The controller returns to the unsafe mode. Hardi HungarR&D Div. Safety-Critical Systems

10. Level Crossing: Requirements (2) Exceptional Behaviour • Trigger: the gate does not reach the lower position within six seconds after initiation • The controller remains in the saved mode until the free signal is received • Once the free signal is received, the controller turns off the supervision signal and the red light and initiates raising the gate • The controller turns into failure mode • Trigger: The gate does not reach the upper position within six seconds after initiation • The controller turns into failure mode • Trigger: Some light is reported to be in an error state • The controller turns into failure mode • Initial Condition: The controller is in failure mode • The supervision signal must be switched off during failure mode • It remains in failure mode until maintenance is performed Hardi HungarR&D Div. Safety-Critical Systems

11. Performed Case Study • Goal: Illustrate safety-critical development with UML • Instantiate template process definition • Use industrial development environment (Rhapsody for modelling, Doors for requirement tracing) • [NOT: Mathematically rigorous development] • Template process instantiated • Model checking on early phase • Test Generation on complete model Hardi HungarR&D Div. Safety-Critical Systems

12. Level Crossing: Modelling Phases • Models for each of the phases of the development Courtesy OpRail [Alcatel, IfEV Braunschweig] Hardi HungarR&D Div. Safety-Critical Systems

13. Phase 0: User Requirements Formalisation • Use Cases [Use Case Diagram] (pretty useless, here) Hardi HungarR&D Div. Safety-Critical Systems

14. Phase 0: User Requirements Formalisation • System structure [Object Model Diagram] Hardi HungarR&D Div. Safety-Critical Systems

15. Phase 0: User Requirements Formalisation • Use Case elaboration (Ex: Regular Behaviour) [Sequence Diagram] Hardi HungarR&D Div. Safety-Critical Systems

16. Phase 0: User Requirements Formalisation • Use Case elaboration (Ex: Yellow Light Failure) [Sequence Diagram] Hardi HungarR&D Div. Safety-Critical Systems

17. Phase 0: User Requirements Formalisation • Main Controller (Steuerzentrale) Requirements Model [StateChart] Hardi HungarR&D Div. Safety-Critical Systems

18. Phase 0: User Requirements Formalisation • Test Specification (Ex: generated from the requirements model) [Sequence Diagram] Hardi HungarR&D Div. Safety-Critical Systems

19. Phase 1: System Requirements • Software Components [Object Model Diagram] Hardi HungarR&D Div. Safety-Critical Systems

20. Phase 1: System Requirements • Relation of software components to use cases [Use Case Diagram] Hardi HungarR&D Div. Safety-Critical Systems

21. Phase 1: System Requirements • Test specification (Ex: generated from software requirements model) [Sequence Diagram] Hardi HungarR&D Div. Safety-Critical Systems

22. Phase 3: Software Architecture • Test specification regular behaviour (generated from statecharts) Hardi HungarR&D Div. Safety-Critical Systems

23. Phase 1: Software Requirements • Test specification regular behaviour (generated from statecharts) Hardi HungarR&D Div. Safety-Critical Systems

24. Phase 2: Software Requirements • Gate controller [Object Model Diagram] Hardi HungarR&D Div. Safety-Critical Systems

25. Phase 2: Software Requirements • Gate controller [Sequence Diagram] Hardi HungarR&D Div. Safety-Critical Systems

26. Phase 3: Software Architecture • Interface view of gate controller implementation [Object Model Diagram] Hardi HungarR&D Div. Safety-Critical Systems

27. Phase 3: Software Architecture • Internals of gate controller implementation [Object Model Diagram] Hardi HungarR&D Div. Safety-Critical Systems

28. Phase 4: Software Coding • Main Controller [Statechart] Hardi HungarR&D Div. Safety-Critical Systems

29. Phase 4: Software Coding • Protocol Components [Object Model Diagram] Hardi HungarR&D Div. Safety-Critical Systems

30. Formal Methods Employed • Model checking: Systematic and exhaustive behaviour analysis • Test generation: Systematic way of generating stimuli sequences covering the model • State coverage • Transition coverage • MCDC condition coverage Hardi HungarR&D Div. Safety-Critical Systems

31. Level Crossing: Model Checking Invariant: If the controller is in the saved mode, the red light is on • root->p_UeS->IS_IN(BUe_1) -> root->p_LzA->IS_IN(rot_leuchtend) • !root->p_UeS->IS_IN(BUe_1) || root->p_LzA->IS_IN(rot_leuchtend) Hardi HungarR&D Div. Safety-Critical Systems

32. ues Supervision Signal as indication for saved mode Hardi HungarR&D Div. Safety-Critical Systems

33. formula Hardi HungarR&D Div. Safety-Critical Systems

34. lza itsUeS-> (GEN(ev_BUe1_schalten) Hardi HungarR&D Div. Safety-Critical Systems

35. Output Hardi HungarR&D Div. Safety-Critical Systems

36. LSC Trace as LSC Hardi HungarR&D Div. Safety-Critical Systems

37. Trace as Timing Diagram Red Lightoff, Supervision Signalon Hardi HungarR&D Div. Safety-Critical Systems

38. lza Source of (transient) error Hardi HungarR&D Div. Safety-Critical Systems

39. Case Study: Model Checking • Model checkers find even hidden errors! Hardi HungarR&D Div. Safety-Critical Systems

40. Model-Based Development: The Promise Booch, Grady et al: The Unified Modeling Language User Guide. Addison Wesley 2001 • “We build models so that we can better understand the system we are developing.“ • “We build models of complex systems because we cannot comprehend such a system in its entirety.” Pretty far from completeness and consistency ... ... but may help in • Achieving consistency • Detect severe omissions • Produce good test specifications Hardi HungarR&D Div. Safety-Critical Systems

41. Tools • Verification: Model Checking, Theorem Proving • System model versus (temporal) logic specification • Model versus model (refinement) • Systematic Test Generation • Coverage wrt. • Statements • Conditions • States and Transitions Hardi HungarR&D Div. Safety-Critical Systems

42. Achievements and Limits: Model Checking Rhapsody LSC Viewer TD Viewer *Ernst-Rüdiger Olderog: „What does the answer ‚system verified‘ help me?“ simulation code generation visualisation trace C++ code false / true Formula compilation * Model-check engine Hardi HungarR&D Div. Safety-Critical Systems

43. Achievements Error traces are nice • Externally usable • Can be validated • Basis for test generation / model animation ... but do not prove correctness Rhapsody LSC Viewer TD Viewer simulation visualisation trace Hardi HungarR&D Div. Safety-Critical Systems

44. Problems ambiguous Rhapsody code generation complex transformation C++ code compilation large program Model-check engine efficient implementation Hardi HungarR&D Div. Safety-Critical Systems

45. Solution Approaches (1): Safe-UML UML • Large number of diagrams • Many concepts for specification • Semantic variation points • Semantically unclean instantiations Hardi HungarR&D Div. Safety-Critical Systems

46. Solution Approaches (1): Safe-UML Safe-UML • UML for safety-critical systems • EN 50126, 50128 – SIL 3, SIL 4 • Three types of diagrams: • Class diagrams • Statecharts • Activity diagrams • Four guiding principles: • Unambiguity • Determinacy • Clarity • Boundedness Hardi HungarR&D Div. Safety-Critical Systems

47. Solution Approaches (2): Compiler Verification • Complex transformation (including simplification, abstraction, ...) • To be verified: • pimg(UML). [cmp(p)] = [p] • Compilers are • Large programs • Often modified • Some „validated“ compilers do exist • Compilers may be „proven in use“ C++ code compilation transition system Hardi HungarR&D Div. Safety-Critical Systems

48. Solution Approaches (2): Compiler Run Verification • Verify relevant instances: • pSystem. [cmp(p)] = [p] • Much simpler problem • [Pnueli, Strichman] • Several instantiations C++ code compilation transition system Hardi HungarR&D Div. Safety-Critical Systems

49. Solution Approaches (3): Engine Verification • Large programs geared towards efficiency • Nontrivial data structures • Complex algorithms • Abstractions on the fly • ... Model-check engine Hardi HungarR&D Div. Safety-Critical Systems

50. Solution Approaches (3): Engine Verification • p,. MC(p, ) p|=  • Correctness Bootstrapping • Small core engine/rule set • verifiable • All critical operations performed by core engine • [Computational Logic] • Everything derived from core proof rules • [some theorem provers] Model-check engine Hardi HungarR&D Div. Safety-Critical Systems