Propose Safety Case Architecture - PowerPoint PPT Presentation

propose safety case architecture n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Propose Safety Case Architecture PowerPoint Presentation
Download Presentation
Propose Safety Case Architecture

play fullscreen
1 / 14
Propose Safety Case Architecture
126 Views
Download Presentation
zandra
Download Presentation

Propose Safety Case Architecture

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Propose Safety Case Architecture 18/04/07

  2. What is a ‘Safety Case Architecture (SCA)’? • Top level view of the Modular Safety Argument • A Safety Case Architecture includes • Overview of the major SC Modules • Detailed definition of the interfaces between SC Modules • Each SC Module can be either • A standard Safety Case Module • A Safety Case Contract Module • Each SC Module provides either • Argument over elements within the Software System • Integration Arguments • Linking Modular Arguments • Goals requiring Support from Other Modules • Module Reference • Away Goal Reference • Safety Case Contract 18/04/07

  3. Modularity in the Safety Case (SC) • Success of containing change strongly influenced by the Modularity in the design • More difficult to define SC boundaries for a legacy system that does not strongly feature modularity in the design • SC module boundaries should be influenced by the design • SC boundaries should yield SC modules that typically exhibit • High cohesion • Low Coupling • Well defined boundaries • Information hiding • Other factors • Anticipated future change • Use of COTs • Granularity of the safety case • Few modules limits ability to deal with change • Many modules could significantly increase complexity (and costs) 18/04/07

  4. Modular Safety Argument Overview • Argument over elements within the Software System • Blocks in the Application Layer • OSL • MSL • Integration Arguments regarding • Architecture • Integration of OSL and MSL • Provision and performance of services • Application Layer • Integration of the Software Applications • Integration of the Arguments for each Block • Overall Integration • Integration of the Applications with the Architecture 18/04/07

  5. Safety Case Argument Modules Safety Requirements APOS Applications Application Integration Operating System Layer MOS Architecture Integration Module Support Layer RTBP 18/04/07

  6. Safety Requirements Application 1 Application 2 Application 3 Application Integration Operating System Layer Architecture Integration RTBP Module Support Layer Example Safety Case Architecture – Argument Modules 18/04/07

  7. Application Layer Application Layer App R App S App P App Q R 3 R P Q R S P 1 1 1 1 1 1 P Q R S 2 2 2 2 R P 2 2 P Q R S 3 3 3 3 P 3 Q 3 Q Q 1 2 P Q R S n n n n Application Layer (AL) Partitioning (1) – Physical Domain CELL: All the inter-cell interactions are via the architecture 18/04/07

  8. AL Partitioning (2) – Safety Domain Regions: Blocks: Block High High High Assurance Assurance Low Change High Change Region Cell Assurance Low Low Assurance Assurance Low Change High Change Block Interactions – Contracted Behaviour Low Extensible Core Low Susceptibility to Change High 18/04/07

  9. AL Partitioning (3) – Logical Partitioning Rationale Assurance Assurance Assurance Change Change Change Too many blocks - Very Extensible - Expensive to set-up contracts between blocks Compromise - Extensible in HC/HA - Some extensibility in HC/LA & LA/HC Too Coarse - Limited Extensibility - Reduced set-up costs 18/04/07

  10. AL Partitioning (4) – Partitioning Guidelines • Assurance • Each LA cell, map to block in LA regions • HA/mixed assurance cells, map to blocks in HA regions • Susceptibility to Change • Each LC cell, map to block in LC regions • HC/mixed susceptibility to change cells, map to blocks in HC regions • All cells that are LC & LA, map to one Block in LCLA region • Example considerations for grouping cells into Blocks • Impact of Change Scenario • Isolate sets of cells that are affected by groups of changes • Likelihood of future change in assurance • Impact of future change uncertain • Synergy 18/04/07

  11. HCHA1 HCLA2 HCHA4 HCHA3 HCHA2 HCLA1 HCHA6 HCLA4 HCLA3 HCHA5 HCHA{N} AL Partitioning (5) – Example Partitioning Assurance LCHA1 LCHA3 LCHA2 Susceptibility To Change LCLA1 18/04/07

  12. OSL MSL Arch Int AL Int RTBP {Block X} Safety_Req IMSSC Process - Modules APOS MOS 18/04/07

  13. Safety Case Architecture for IMSCC Process • A basic set of SC Modules are specified • Modules names may be varied to meet project preferences, but the intent and underlying meaning should be maintained • Modules may be created iteratively, in parallel and in any order • Product and Process argument may be included, as required • Flexibility to facilitate optimisation of the SCA • Additional SC Modules may be added to cover the arguments described for each of the specified SC Modules • Containment may be employed to scope the argument • Tailoring possible e.g. the whole application layer could be argued about should this be required to meet design constraints 18/04/07

  14. Safety Case Architecture – Initial Proposal Safety_Req Block X Block Y Block Z OSL AL Int Arch Int RTBP MSL 18/04/07