Defence Standard 00-55 Part 2 Issue 2 - Software

1 This Part 2 of Def Stan 00-55 supersedes INTERIM Def Stan 00-55 / Issue 1 dated 5 April 1991 Ministry of Defence Defence Standard 00-55 (PART 2)/ Issue 2 1 August 1997 REQUIREMENTS FOR SAFETY RELATEDSOFTWARE IN Defence EQUIPMENT PART 2: GUIDANCEDEF STAN 00-55 (PART 2)/2 AMENDMENTS ISSUED SINCE PUBLICATIONAMD NODATE OFISSUETEXT AFFECTEDSIGNATURE &DATER evision NoteIssue 2 of this Standard has been prepared to take account of comments received from usersof Interim Issue 1 and to comply with current MOD RecordInterim Issue 1 Initial Publication5 April 1991 DEF STAN 00-55 (PART 2)/21 REQUIREMENTS FOR SAFETY RELATED Software IN DEFENCEEQUIPMENTPART 2.

2 GUIDANCEPREFACEThis Part 2 of Def Stan 00-55 Supersedes INTERIM Def Stan 00-55 (Part 2)iThis Part of the Standard contains guidance on the requirements contained in Part guidance serves two functions: it elaborates on the requirements in order to makeconformance easier to achieve and assess; and it provides technical Standard is one of a family of standards dealing with safety that is being developedor adopted by MOD, taking into account international standardization activities andsupporting research and This Standard has been agreed by the authorities concerned with its use and is intended tobe used whenever relevant in all future designs, contracts, orders etc and wheneverpracticable by amendment to those already in existence.

3 If any difficulty arises whichprevents application of this Defence Standard , the Directorate of Standardization shall beinformed so that a remedy may be enquiries regarding this Standard in relation to an invitation to tender or a contract inwhich it is incorporated are to be addressed to the responsible technical or supervisingauthority named in the invitation to tender or Standard has been devised for the use of the Crown and its contractors in theexecution of contracts for the Crown. The Crown hereby excludes all liability (other thanliability for death or personal injury) whatsoever and howsoever arising (including, butwithout limitation, negligence on the part of the Crown its servants or agents) for any loss ordamage however caused where the Standard is used for any other STAN 00-55 (PART 2)/22 CONTENTSPAGEP reface1 Section One.

4 General0 Introduction41 Scope42 Warning43 Related Documents44 Definitions5 Section Two. Safety Management5 Safety Management Activities66 Software Safety Plan67 Software Safety Case68 Safety Analysis119 Software Safety Records Log1210 Software Safety Reviews1211 Software Safety Audits13 Section Three. Roles and Responsibilities12 General1513 Design Authority1614 Software Design Authority1615 Software Project Manager1616 Design Team1617 V&V Team1718 Independent Safety Auditor1719 Software Project Safety Engineer18 Section Four. Planning Process20 Quality Assurance1921 Documentation1922 development Planning2223 Project Risk2224 Verification and Validation Planning2325 Configuration Management2326 Selection of Methods2427 Code of Design Practice2728 Selection of Language2829 Selection of Tools3030 Use of Previously Developed Software3231 Use of Diverse Software34 DEF STAN 00-55 (PART 2)/23 Section Five.

5 SRS development Process32 development Principles3633 Software Requirement4634 Specification Process4735 Design Process5036 Coding Process5537 Testing and Integration58 Section Six. Certification and In-Service Use38 Certification6339 Acceptance6440 Replication6441 User Instruction6442 In-service65 Section Seven. Application of this Standard Across Differing Safety Integrity Levels43 Software of differing Safety Integrity Levels67 Figure 1. Top Level Document Structure7 Figure 2. Software development Records21 Figure 3. Lifecycle for SRS development (1)37 Figure 4. Context of a development Process39 Figure 5.

6 Lifecycle for SRS development (2)40 Table 1. Safety Arguments10 Table 2. Failure Probability for Different Safety Integrity Levels12 Annex A. BibliographyA-1 Annex B. DocumentationB-1 Annex C. Certificate of DesignC-1 Annex D. Tailoring Guide Across Differing Safety Integrity LevelsD-1 Annex E. Guidance on the Preparation of a Software Safety CaseE-1 Annex F. Process Safety Analysis ProcedureF-1 Annex G. Product EvidenceG-1 Annex H. Process Safety Analysis ExamplesH-1 Annex J. Process EvidenceJ-1 Annex K. SHOLIS Evidence LibraryK-1 Annex L. Fault Tree AnalysisL-1 Annex M. SHOLIS: FMEA WorksheetsM-1 Annex N AbbreviationsN-1 Indexindex iDEF STAN 00-55 (PART 2)/24 REQUIREMENTS FOR SAFETY RELATED Software IN Defence EQUIPMENTPART 2: GUIDANCES ection One.

7 General0 IntroductionThis Part of the Defence Standard provides guidance on the requirements in Part 1. Fromsection two onwards, this guidance is organized by the main clause and subclause headingsused in Part 1; however, subsubclauses do not necessarily correspond exactly between the Part of the Standard provides information and guidance on the procedures necessaryfor the production of Software of all levels of safety integrity. However, it places particularemphasis on describing the procedures necessary for specification, design, coding, productionand in-service maintenance and modification of Safety Critical Software (SCS).

8 Should be emphasized that safety is a system property and achieving and maintainingsafety requires attention to all aspects of the system, including its human, electronic andmechanical components. This Standard addresses only one important component - ie thedevelopment of Software to meet a predetermined safety integrity level. The achievement ofsafety targets by overall design, and in particular whether safety features are to be controlledby hardware, Software or manual procedures, is not addressed. A systems approach to hazardanalysis and safety risk assessment is explained in Def Stan safety is dependent on the safety related Software (SRS) fully meeting itsrequirements, demonstrating safety is equivalent to demonstrating correctness with respect tothe Software Requirement.

9 In other cases, safety may be dependent on the SRS behaving inaccordance with an identifiable set of safety requirements, contained within the SoftwareRequirement, rather than correctness with the total Software Requirement to provide therequired safety integrity level. Because of the difficulties of separating safety properties fromthe other behavioural properties of the SRS and the need to demonstrate adequate partitioningbetween these properties, this Standard tends towards the former approach and assumes thatcorrectness is equivalent to safety. However, providing that safety can be achieved anddemonstrated, overall correctness need not be an objective from a safety point of Standard refers to a number of procedures, techniques, practices and tools which whenfollowed or used correctly will reduce but not necessarily eliminate the probability that thesoftware will contain errors.

10 This Standard refers only to technical suitability and in no wayabsolves either the designer, the producer, the supplier or the user from statutory and all otherlegal obligations relating to health and safety at any DocumentsThe related documents identified in Part 1 also apply to this Part of the STAN 00-55 (PART 2)/254 DefinitionsThe definitions in Part 1 apply also to this Part of the STAN 00-55 (PART 2)/26 Section Two. Safety Management5 Safety Management ActivitiesNo Safety contents of the Software Safety Plan should be as detailed in annex On someprojects with a particularly long timescales it may not be possible to specify CVs of keyindividuals nor specify the qualifications required of all the staff who might be involved withthe production of the SRS.