1 / 53

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

Tools for the Model-Based Development of Certifiable, Dependable Systems. Michaela Huhn Hardi Hungar Doron Peled. Tools for the Model-Based Development of Certifiable, Dependable Systems. Certification means Evidence required Formal methods recommended for software construction

tamah
Download Presentation

Tools for the Model-Based Development of Certifiable, Dependable 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. 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

More Related