software guidance for ds 00-56 issue 3 john mcdermid

Click here to load reader

Post on 21-Dec-2015

217 views

Category:

Documents

3 download

Embed Size (px)

TRANSCRIPT

  • Slide 1
  • Software Guidance for DS 00-56 Issue 3 John McDermid
  • Slide 2
  • 2 Contents Introduction and Objectives Overview of MoD/Dstl work Available Standards and Guidance MoD Requirements Representing Guidance Legacy and COTS Developing Guidance
  • Slide 3
  • 3 Introduction IDS 00-56 Issue 3 was issued in December 2004 Goal-setting standard, emphasising safety cases Formally superseded DS 00-55 (and DS 00-54) At the time there was an intent to issue software guidance This was seen as an urgent requirement Software guidance Draft material was produced but not issued Agreed to be inappropriate (re-inventing 00-55) Several other activities Currently, Dstl task for MoD Late, but dont blame Dstl Probably still the most urgent need Considerable use of DS 00-55, despite its obsolescence
  • Slide 4
  • 4 Objectives Primary objectives Determine what is needed in the way of software guidance Identify best way of producing and maintaining guidance Secondary objectives Gain understanding of key issues, e.g. ALARP and software Not very hidden agenda Appropriate for MoD to define standards Especially where goal-setting Guidance should reflect best practice Knowledge on best practice lies with industry Development of guidance should involve industry
  • Slide 5
  • 5 Contents Introduction and Objectives Overview of MoD/Dstl work Available Standards and Guidance MoD Requirements Representing Guidance Legacy and COTS Developing Guidance
  • Slide 6
  • 6 Contents Introduction and Objectives Overview of MoD/Dstl work Available Standards and Guidance MoD Requirements Representing Guidance Legacy and COTS Developing Guidance
  • Slide 7
  • 7 Defence Standards and Guidance Available documents include: Software System Safety Allied Ordnance Proceedings (AOP) Work done by US, UK and Australia Intended to be a how to guide Def Aust 5679 Very demanding standard, with new concepts, e.g. Levels of Trust MIL-STD-498 General software standard, but addresses safety Guidance linked to MIL-STD-882 Including Swedish software safety handbook (has been translated into English) Others? AOP and Swedish work most complete/pragmatic
  • Slide 8
  • 8 Aerospace Standards and Guidance Available documents include: DO 178B Perhaps the most widely used software guidance Being updated to produce DO 178C NASA NSS 1740.13 Guidance intended to fit in with NASA safety standards ESA PSS-05-01 General guidance, but covers with safety critical software Some relevant systems documents/requirements, e.g. FAA Order 8000.70, ARP 4754 etc. Others? Opportunity to influence DO178C But how can DALs be interpreted for non-aeropsace systems?
  • Slide 9
  • 9 Other Standards and Guidance Available documents include: IEC (BS EN) 61508 Intended to be a generic standard BS EN 50128 Railway signalling interpretation of 61508 MISRA guidelines Guidance for automotive systems Canadian Nuclear Regulatory framework Requires use of formal methods CAA SW 01, another goal-setting standard Others? Standards are wonderful things there are so many, so if you dont like one you can always choose another
  • Slide 10
  • 10 Contents Introduction and Objectives Overview of MoD/Dstl work Available Standards and Guidance MoD Requirements Representing Guidance Legacy and COTS Developing Guidance
  • Slide 11
  • 11 Civil vs Military MoD principle that standards should be as civil as possible, only as military as necessary Reasons for this principle Perceived to be cheaper Industry more familiar Greater ability to use COTS products Interpretation needs to be sector specific DO 178B in aerospace BS EN 50128 in railway signalling Note: legally, it is likely that such standards would take precedence over UK standards anyway
  • Slide 12
  • 12 Are Military Systems Different? Generally dealing with weapons systems No civil counterpart To gain military advantage, may push technology Aerodynamically unstable aircraft Autonomous vehicles/systems May operate systems with less margin Single engined aircraft Flying nap of the earth Much longer operational periods (for crew) Yes, but how much does it matter for the software?
  • Slide 13
  • 13 Contents Introduction and Objectives Overview of MoD/Dstl work Available Standards and Guidance MoD Requirements Representing Guidance Legacy and COTS Developing Guidance
  • Slide 14
  • 14 Safety Case Fragments Can represent requirements for evidence as patterns Top Level Software Failure Mode Decomposition Pattern Failure Mode Classification Pattern Absence of Service Provision Hazard Pattern Absence of Service Timing Hazard Pattern Absence of Value Hazard Pattern Handling Patterns Argument Approach Pattern
  • Slide 15
  • 15 Other Approaches Provide more pragmatic guidance Current best practice Can we agree? Is it sector specific? How do we keep it up to date? Refer to standards Is this sufficient? Do we need to provide add ons for the most stringent situations? When military is necessary Worked examples Education and training What is most effective and cost-effective?
  • Slide 16
  • 16 Contents Introduction and Objectives Overview of MoD/Dstl work Available Standards and Guidance MoD Requirements Representing Guidance Legacy and COTS Developing Guidance
  • Slide 17
  • 17 Strategies Use operational data If it is compelling If it has been adequately collected Reverse engineer to appropriate standard What does this mean in a goal setting context? Is MoDs current SOUP guidance too stringent? How do we judge ALARP? Rely on the ISA All have pros and cons How do we choose the most appropriate strategy?
  • Slide 18
  • 18 Contents Introduction and Objectives Overview of MoD/Dstl work Available Standards and Guidance MoD Requirements Representing Guidance Legacy and COTS Developing Guidance
  • Slide 19
  • 19 Principle and Strategies Knowledge of best practice is in industry But MoD have a duty of care so need to be involved Possible strategies MoD and industry working party Perhaps the best, if practicable MoD sponsor development SSRC or ASEG fund industry/MoD committee Make a task on the SSEI Influence other standards, e.g. DO178C, but How can MoD specifics be addressed? How can this apply across sectors? What is the best approach?
  • Slide 20
  • 20 Contents Introduction and Objectives Overview of MoD/Dstl work Available Standards and Guidance MoD Requirements Representing Guidance Legacy and COTS Developing Guidance
  • Slide 21
  • 21 Feedback 1 Feedback reflects consensus items More detail recorded Who is the guidance intended for? Four possibilities Developers Desk officers in IPTs ISAs Regulators Consensus Primary guidance is for desk officers in IPTs This will have some value for the other communities, e.g. setting expectations for developers
  • Slide 22
  • 22 Feedback 2 Principle underlying IDS 00-56 Issue 3 as civil as possible, only as military as necessary Question For software, is civil (level of evidence) sufficient? Consensus Military systems are more demanding, hence we have to look at more demanding forms of evidence Levels of criticality NB 56 Issue 3 Part 2 has High, Medium, Low Consensus, need to distinguish Safety critical Safety related Not safety related (none) May also need strong arguments supporting non-interference
  • Slide 23
  • 23 Feedback 3 Question about how guidance should be represented Consensus Example safety case patterns, with evidence types Need to be multiple examples, to avoid risk of examples becoming the default Also produced some illustrative examples Top level argument Product Process Continuous independent assessment Specific issues Freedom from run-time failures Satisfaction of functional and safety requirements
  • Slide 24
  • 24 Feedback 4 Discussion of legacy and COTS As 56 Issue is goal-based, approach still applies Consensus need Guidance on data collection for proven in service arguments Guidance on making arguments comprising direct evidence and service data especially on what is ALARP Legal guidance on grandfather rights, and how access to data, IP etc. impacts argument, especially ALARP Development of guidance Needs MoD and industry working together Industry group excluding MoD possible, but less valuable Ideally a task for the SSEI