1 / 14

Propose Safety Case Architecture

Propose Safety Case Architecture. 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

zandra
Télécharger la présentation

Propose Safety Case Architecture

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. 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

More Related