際際滷

際際滷Share a Scribd company logo

On the Transition from Design Time to Runtime Model-Based Assurance Cases

Download as PPTX, PDF
R
Ran Wei

Presentation slides for the paper "On the Transition from Design Time to Runtime Model-Based Assurance Cases" at 13th International Workshop on Models@Runtime

1 of 38
Downloaded 20 times
On the Transition from Design Time to Runtime Model-Based Assurance Cases Ran Wei1, Jan Reich2, Tim Kelly1 and Simos Gerasimou1 University of York1 Fraunhofer IESE2 MRT Workshop, October 2018
Typical Safety Arguments - 2 Overview A Brief History of Assurance Cases Model-Based Assurance Cases The Need for Model-Based Assurance Cases@Runtime The Structured Assurance Case Metamodel (SACM) SACM and Assurance Cases @ Runtime
Typical Safety Arguments - 3 A Brief History of Assurance Case Long established in the safety-related domain (Safety- Critical System) Perform critical functions Failure = financial loss, casualties, catastrophe The need to justify safety Safety Case A Safety Case should communicate a clear, comprehensible and defensible argument that a system is acceptably safe to operate in a particular context. Regulatory process: Development, Review and acceptance of a Safety Case Nuclear, defense, civil aviation and railway
Typical Safety Arguments - 4 A Brief History of Assurance Case Historically communicated through free text Unclear, poorly structured Poor in expressing cross-references Reference from evidence claim to the actual artefact Reference from claim to another claim Graphical Notations to overcome difficulties encountered using free text Goal Structuring Notation (GSN) Claims-Arguments-Evidence (CAE) Improves the comprehension of the safety argument amongst all of the key project stakeholders -> improve the quality of debate and discussion Reduce time to reach agreements on the argument
Typical Safety Arguments - 5 A Brief History of Assurance Case Structured Argumentation based on the Goal Structuring Notation (GSN)
Typical Safety Arguments - 6 A Brief History of Assurance Case Structured Argumentation applied to other domains, to justify system security. Assurance Case Safety case + security case Communicate a clear, comprehensible and defensible argument that a system/service is acceptably safe and/or secure to operate in a particular context
Typical Safety Arguments - 7 Model-Based Assurance Cases Benefits of Model-Driven Engineering when applied to Assurance Cases Consistency Model management operations Model Validation: check against well-formedness Model-to-text transformation: automated assurance case report Model-to-model transformation: migration from legacy assurance case models/files Model merging: automated assurance case composition GSN/CAE Lack of metamodels Inconsistency among metamodels Invisibility of models and model management operations
Typical Safety Arguments - 8 Model-Based Assurance Cases @ Runtime Assuring Open Adaptive Systems becomes difficult Open: systems connect to each other Adaptive: systems adapt to a changing context Increasing challenges in emerging concepts: Cyber-Physical Systems Need to monitor system state Need to reason about the overall safety/security of composed system. Proposed solution Models@Runtime SafetyCertificate@Runtime AssuranceCase@Runtime V&V-Model@Runtime HRA@Runtime
Typical Safety Arguments - 9 Different levels of safety intelligence @ runtime
Typical Safety Arguments - 10 Models@Runtime For Open Adaptive Systems SafetyCertificate@Runtime Safety demands and guarantees Modular and contract-based definitions of safety certificates AssuranceCase@Runtime Assurance case, argument over safety/security, with supporting evidence, and corresponding system models Executable automated reasoning of arguments V&V-Model@Runtime System adaptation -> invalidated evidence -> Verification and validation -> shifted from design time to runtime HRA@Runtime Change of requirements -> Hazard Analysis and Risk Assessment (HARA) model
Typical Safety Arguments - 11 Structured Assurance Case Metamodel (SACM) OMG Standard Based on existing (well-established) assurance case approaches GSN and CAE Promote standardisation and interoperability No formal GSN/CAE metamodels No means of interchange between GSN and CAE More powerful in expressiveness Modularity Multiple Language Support Controlled Vocabulary Level of Trust Evidence-Artefact Traceability
Typical Safety Arguments - 12 Structured Assurance Case Metamodel (SACM)
Typical Safety Arguments - 13 SACM AssuranceCase Component
Typical Safety Arguments - 14 SACM Base Component
Typical Safety Arguments - 15 SACM Artifact Component
Typical Safety Arguments - 16 SACM Terminology Component
Typical Safety Arguments - 17 SACM Argumentation Component
Typical Safety Arguments - 18 Supporting Modularity / Packaging Modular assurance case management: Managing the division of assurance case arguments and evidence into modules / packages E.g. aligned with architecture, or with supply chain
Typical Safety Arguments - 19 Supporting Modularity / Packaging
Typical Safety Arguments - 20 Supporting Modularity / Packaging
Typical Safety Arguments - 21 Multiple Language Support SACM models are machine processable Standardised format for model interchange But reasoning is limited by ability to process expressions
Typical Safety Arguments - 22 Multiple Language Support SACM models are machine processable Standardised format for model interchange But reasoning is limited by ability to process expressions
Typical Safety Arguments - 23 Support beyond Natural Language MultiLangString could support several dialects Formal expressions OCL (e.g. for ImplementationConstraints) Languages that could support machine evaluation Powerful combination with abstract argumentation, and evidence, structures (and appropriate ImplementationConstraints)
Typical Safety Arguments - 24 Controlled Vocabulary
Typical Safety Arguments - 25 Controlled Vocabulary
Typical Safety Arguments - 26 Supporting Dialectic Arguments Neglected aspect of assurance cases Dialectic argumentation is healthy
Typical Safety Arguments - 27 Describing Level of Trust Example: Argumentation about the adequacy of the claims, inferences, evidential links
Typical Safety Arguments - 28 Supporting Patterns Patterns are abstract argument structures with appropriate constraints E.g. long history in GSN (1997) Useful to capture reusable, typical argument structures Patterns in SACM generalised beyond simply argumentation (also Artefact and Terminology)
Typical Safety Arguments - 29 Example: Expression Patterns
Typical Safety Arguments - 30 Evidence-Artefact Reference
Typical Safety Arguments - 31 Cyber-Physical System Integration of Computation, Communication and Control Open & adaptive Connection to each other at runtime Adaptation to a changing context Number of configurations at design time: unknown Challenge: assuring the safety/dependability of CPS
Typical Safety Arguments - 32 H2020 ICT-01-2016 DEIS Dependability Engineering Innovation for CPS Address the challenge of assurance of CPS at runtime Core concept: Digital Dependability Identity (DDI) Composable and executable Contains system attributes and dependability behaviour Failure mode Fault propagation Contains dependability requirements when interacting with other systems Produced during design, issued when the component is release, and continuously maintained over the complete lifetime of a component or system Model@runtime
Typical Safety Arguments - 33 Objective 1: An open model for specifying Digital Dependability Identities enabling the efficient integration of modular dependability assurance cases (Open Dependability Exchange Metamodel) Objective 2: Semi-automated framework for the generation and evaluation of DDIs Objective 3: A framework for the in-the-field dependability assurance in CPS Objective 4: autonomous and connected CPS use cases DEIS technical approach the DDI
Typical Safety Arguments - 34 Open Dependability Exchange Metamodel
Typical Safety Arguments - 35 Overall Idea
Typical Safety Arguments - 36
Typical Safety Arguments - 37 Summary Assurance Case is important in certifying the safety/security of systems Existing Assurance Case Approach Manual, lengthy Design time only (Mostly) non-model-based SACM Supports existing assurance case approaches Model-based system assurance Additional features to support models at runtime Key to assure open adaptive systems
Typical Safety Arguments - 38 Thank you Questions?

More Related Content

On the Transition from Design Time to Runtime Model-Based Assurance Cases

  • 1. On the Transition from Design Time to Runtime Model-Based Assurance Cases Ran Wei1, Jan Reich2, Tim Kelly1 and Simos Gerasimou1 University of York1 Fraunhofer IESE2 MRT Workshop, October 2018
  • 2. Typical Safety Arguments - 2 Overview A Brief History of Assurance Cases Model-Based Assurance Cases The Need for Model-Based Assurance Cases@Runtime The Structured Assurance Case Metamodel (SACM) SACM and Assurance Cases @ Runtime
  • 3. Typical Safety Arguments - 3 A Brief History of Assurance Case Long established in the safety-related domain (Safety- Critical System) Perform critical functions Failure = financial loss, casualties, catastrophe The need to justify safety Safety Case A Safety Case should communicate a clear, comprehensible and defensible argument that a system is acceptably safe to operate in a particular context. Regulatory process: Development, Review and acceptance of a Safety Case Nuclear, defense, civil aviation and railway
  • 4. Typical Safety Arguments - 4 A Brief History of Assurance Case Historically communicated through free text Unclear, poorly structured Poor in expressing cross-references Reference from evidence claim to the actual artefact Reference from claim to another claim Graphical Notations to overcome difficulties encountered using free text Goal Structuring Notation (GSN) Claims-Arguments-Evidence (CAE) Improves the comprehension of the safety argument amongst all of the key project stakeholders -> improve the quality of debate and discussion Reduce time to reach agreements on the argument
  • 5. Typical Safety Arguments - 5 A Brief History of Assurance Case Structured Argumentation based on the Goal Structuring Notation (GSN)
  • 6. Typical Safety Arguments - 6 A Brief History of Assurance Case Structured Argumentation applied to other domains, to justify system security. Assurance Case Safety case + security case Communicate a clear, comprehensible and defensible argument that a system/service is acceptably safe and/or secure to operate in a particular context
  • 7. Typical Safety Arguments - 7 Model-Based Assurance Cases Benefits of Model-Driven Engineering when applied to Assurance Cases Consistency Model management operations Model Validation: check against well-formedness Model-to-text transformation: automated assurance case report Model-to-model transformation: migration from legacy assurance case models/files Model merging: automated assurance case composition GSN/CAE Lack of metamodels Inconsistency among metamodels Invisibility of models and model management operations
  • 8. Typical Safety Arguments - 8 Model-Based Assurance Cases @ Runtime Assuring Open Adaptive Systems becomes difficult Open: systems connect to each other Adaptive: systems adapt to a changing context Increasing challenges in emerging concepts: Cyber-Physical Systems Need to monitor system state Need to reason about the overall safety/security of composed system. Proposed solution Models@Runtime SafetyCertificate@Runtime AssuranceCase@Runtime V&V-Model@Runtime HRA@Runtime
  • 9. Typical Safety Arguments - 9 Different levels of safety intelligence @ runtime
  • 10. Typical Safety Arguments - 10 Models@Runtime For Open Adaptive Systems SafetyCertificate@Runtime Safety demands and guarantees Modular and contract-based definitions of safety certificates AssuranceCase@Runtime Assurance case, argument over safety/security, with supporting evidence, and corresponding system models Executable automated reasoning of arguments V&V-Model@Runtime System adaptation -> invalidated evidence -> Verification and validation -> shifted from design time to runtime HRA@Runtime Change of requirements -> Hazard Analysis and Risk Assessment (HARA) model
  • 11. Typical Safety Arguments - 11 Structured Assurance Case Metamodel (SACM) OMG Standard Based on existing (well-established) assurance case approaches GSN and CAE Promote standardisation and interoperability No formal GSN/CAE metamodels No means of interchange between GSN and CAE More powerful in expressiveness Modularity Multiple Language Support Controlled Vocabulary Level of Trust Evidence-Artefact Traceability
  • 12. Typical Safety Arguments - 12 Structured Assurance Case Metamodel (SACM)
  • 13. Typical Safety Arguments - 13 SACM AssuranceCase Component
  • 14. Typical Safety Arguments - 14 SACM Base Component
  • 15. Typical Safety Arguments - 15 SACM Artifact Component
  • 16. Typical Safety Arguments - 16 SACM Terminology Component
  • 17. Typical Safety Arguments - 17 SACM Argumentation Component
  • 18. Typical Safety Arguments - 18 Supporting Modularity / Packaging Modular assurance case management: Managing the division of assurance case arguments and evidence into modules / packages E.g. aligned with architecture, or with supply chain
  • 19. Typical Safety Arguments - 19 Supporting Modularity / Packaging
  • 20. Typical Safety Arguments - 20 Supporting Modularity / Packaging
  • 21. Typical Safety Arguments - 21 Multiple Language Support SACM models are machine processable Standardised format for model interchange But reasoning is limited by ability to process expressions
  • 22. Typical Safety Arguments - 22 Multiple Language Support SACM models are machine processable Standardised format for model interchange But reasoning is limited by ability to process expressions
  • 23. Typical Safety Arguments - 23 Support beyond Natural Language MultiLangString could support several dialects Formal expressions OCL (e.g. for ImplementationConstraints) Languages that could support machine evaluation Powerful combination with abstract argumentation, and evidence, structures (and appropriate ImplementationConstraints)
  • 24. Typical Safety Arguments - 24 Controlled Vocabulary
  • 25. Typical Safety Arguments - 25 Controlled Vocabulary
  • 26. Typical Safety Arguments - 26 Supporting Dialectic Arguments Neglected aspect of assurance cases Dialectic argumentation is healthy
  • 27. Typical Safety Arguments - 27 Describing Level of Trust Example: Argumentation about the adequacy of the claims, inferences, evidential links
  • 28. Typical Safety Arguments - 28 Supporting Patterns Patterns are abstract argument structures with appropriate constraints E.g. long history in GSN (1997) Useful to capture reusable, typical argument structures Patterns in SACM generalised beyond simply argumentation (also Artefact and Terminology)
  • 29. Typical Safety Arguments - 29 Example: Expression Patterns
  • 30. Typical Safety Arguments - 30 Evidence-Artefact Reference
  • 31. Typical Safety Arguments - 31 Cyber-Physical System Integration of Computation, Communication and Control Open & adaptive Connection to each other at runtime Adaptation to a changing context Number of configurations at design time: unknown Challenge: assuring the safety/dependability of CPS
  • 32. Typical Safety Arguments - 32 H2020 ICT-01-2016 DEIS Dependability Engineering Innovation for CPS Address the challenge of assurance of CPS at runtime Core concept: Digital Dependability Identity (DDI) Composable and executable Contains system attributes and dependability behaviour Failure mode Fault propagation Contains dependability requirements when interacting with other systems Produced during design, issued when the component is release, and continuously maintained over the complete lifetime of a component or system Model@runtime
  • 33. Typical Safety Arguments - 33 Objective 1: An open model for specifying Digital Dependability Identities enabling the efficient integration of modular dependability assurance cases (Open Dependability Exchange Metamodel) Objective 2: Semi-automated framework for the generation and evaluation of DDIs Objective 3: A framework for the in-the-field dependability assurance in CPS Objective 4: autonomous and connected CPS use cases DEIS technical approach the DDI
  • 34. Typical Safety Arguments - 34 Open Dependability Exchange Metamodel
  • 35. Typical Safety Arguments - 35 Overall Idea
  • 37. Typical Safety Arguments - 37 Summary Assurance Case is important in certifying the safety/security of systems Existing Assurance Case Approach Manual, lengthy Design time only (Mostly) non-model-based SACM Supports existing assurance case approaches Model-based system assurance Additional features to support models at runtime Key to assure open adaptive systems
  • 38. Typical Safety Arguments - 38 Thank you Questions?

Editor's Notes

  • #6: Introduce GSN: Goal Structures expressed through Goals, Strategy + Solution. The MRT community might need a refresher on that, so maybe show it based on the example.
  • #8: Benefits of model-based AC How are they realized? -> SACM Explore the most important features of SACM on the next slides
  • #12: SACM Overview image -> the nice colored package structure from the standard?
  • #13: SACM Overview image -> the nice colored package structure from the standard?
  • #14: SACM Overview image -> the nice colored package structure from the standard?
  • #15: SACM Overview image -> the nice colored package structure from the standard?
  • #16: SACM Overview image -> the nice colored package structure from the standard?
  • #17: SACM Overview image -> the nice colored package structure from the standard?
  • #18: SACM Overview image -> the nice colored package structure from the standard?