1、 NASA TECHNICAL STANDARD NASA-STD-8719.13C National Aeronautics and Space Administration Approved: 05-07-2013 Washington, DC 20546-0001 Superseding NASA-STD-8719.13B SOFTWARE SAFETY STANDARD MEASUREMENT SYSTEM IDENTIFICATION: NOT MEASUREMENT SENSITIVE Provided by IHSNot for ResaleNo reproduction or
2、networking permitted without license from IHS-,-,-2 of 57 DOCUMENT HISTORY LOG Status Document Revision Approval Date Description Baseline 02-12-1996 Initial Release as NSS 1740.13. Revision A 09-15-1997 Replaced NSS 1740.13. (White) Change 1 09-15-1997 Headquarters documentation numbering (White) C
3、hange 2 09-15-1997 Paragraph 3.1(e); access scope and level of IV file space; bandwidth). Safety could potentially be compromised if software executes a command unexpectedly, executes the wrong command, generates the wrong data, uses unplanned resources, or uses resources incorrectly. Software safet
4、y requirements must encompass all these aspects, covering both action (must-work) and inaction (must not work). There are two kinds of software safety requirements: process and technical. Both need to be addressed and properly documented within a program, project, or facility. This Standard contains
5、 process-oriented requirements (what needs to be done to ensure software safety). Technical requirements are those that specify what the system includes or implements (e.g., two-fault tolerance). Use of this Standard does not preclude the necessity to follow applicable technical standards. Some typi
6、cal technical software safety requirements are provided as examples in Appendix D of this document. NPR 7150.2, NASA Software Engineering Requirements (section 2.2.12, requirement SWE-0134 in Revision A) contains some minimum technical safety requirements. Software safety requirements do more than p
7、rohibit unsafe system behavior. Software is used to command critical, must-work functions. Software can be used proactively to monitor the system, analyze critical data, look for trends, and signal when events occur that may be precursors to a hazardous state. Software can also be used in the contro
8、l or mitigation of a hazard, event, or condition. Therefore, program, project, and facility software safety requirements include those requirements that will embody these behaviors, both proactive and reactive, and include the system and software states where they are valid. Provided by IHSNot for R
9、esaleNo reproduction or networking permitted without license from IHS-,-,-7 of 57 The requirements specified in this Standard obligate the program, project, and facility, and safety and mission assurance organizations to: Identify when software plays a part in system safety and generate appropriate
10、requirements to ensure safe operation of the system. Ensure that software is considered within the context of system safety, and that appropriate measures are taken to create safe software. Ensure that software safety is addressed in project acquisition, planning, management, and control activities.
11、 Ensure that software safety is considered throughout the system life-cycle, including mission concept, generation of requirements, design, coding, test, maintenance and operation of the software. Ensure that the acquisition of software, whether off-the-shelf or contracted, includes evaluation, asse
12、ssment, and planning for addressing and mitigating risks due to the softwares contribution to safety and any limitations of the software. Ensure that software verification and validation activities include software safety verifications and validations. Ensure that the proper certification requiremen
13、ts are in place and accomplished prior to the actual operational use of the software. Ensure that changes and reconfigurations of the software, during development, testing, and operational use of the software, are analyzed for their impacts to system safety. 1.2 Applicability This Standard applies t
14、o all software (see definition of software in section 3 of this Standard) that is determined to be safety critical per the Software Safety Litmus Test in Appendix A. Software includes software tools (e.g. simulators, models, emulators, compiler libraries, built in memory checkers, materials analysis
15、, trajectory analysis, and those used for generation and testing of both hardware and software), are assessed for any contributions to hazards to the extent possible. Commercial Off The Shelf (COTS) software is used within some of NASAs projects as well as constituting the majority of the tools NASA
16、 uses. See sections 6.5 and 6.6 as well as Appendix F for the approaches to addressing software safety of COTS software and software tools. This Standard applies to all software within a program, project, and facility life-cycle activities started after the date of issuance. If development started p
17、rior to this versions date of issuance, the previous version applies but the program, project, or facility can choose to use this revision. This Standard can be (but not required to be) retroactively applicable to the software within the programs, projects, or facilitys development, maintenance, ope
18、rations, management, acquisition, and assurance activities started prior to the initial issuance of this Standard. This Standard is approved for use by NASA Headquarters and NASA Centers, including Component Facilities and Technical and Service Support Centers, and may be cited in contract, program,
19、 and other Agency documents as a technical requirement. This Standard may also apply to the Jet Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-8 of 57 Propulsion Laboratory or to other contractors, grant recipients, or parties to agreements only to
20、the extent specified or referenced in their contracts, grants, or agreements. For the purposes of this Standard, any software to be executed on a processor embedded within a programmable logic device (PLD) will be evaluated from a software safety perspective. The design and resulting hardware will b
21、e evaluated from a system safety perspective and is not the purview of this standard. The software tools used to generate safety critical PLDs configuration files will be evaluated from a limited COTS safety perspective as per sections 6.5 and 6.6 of this standard. Safety and Mission Assurance of PL
22、Ds/CEs is performed per NASA-HDBK-8739.23, NASA Complex Electronics Handbook for Assurance Professionals. NASA HDBK-4008R, Programmable Logic Devices (PLD) Handbook addresses the engineering processes for developing PLDs. Software covered by this Standard is also required to implement the NASA softw
23、are engineering requirements of NPR 7150.2, NASA Software Engineering Requirements, and the NASA software assurance requirements of NASA-STD-8739.8, NASA Software Assurance Standard. This Standard stresses coordination between software engineering and software safety assurance, as well as with syste
24、m safety and software development, to maintain the system perspective and minimize duplication of effort. Requirementsi.e., mandatory actionsare denoted by statements containing the term “shall,“ are identified by “(Requirement),” and are numbered SSS-#. The terms: “may“ or “can“ denote discretionar
25、y privilege or permission, “should“ denotes a good practice and is recommended, but not required, “will“ denotes expected outcome, and “are/is“ denotes descriptive material. This Standard often refers to recording information in an “appropriate document.” It is not the intent of this Standard to des
26、ignate what documents a program, project, organization, or facility must generate. The software safety information is recorded within the program, project, organization, or facility documentation as a quality record, but the exact type of documentation is left to the program, project, or facility. T
27、he SMA organization needs to keep their own records, reports, metrics, as well as analyses, lessons learned, and trending results. When specific plans are mentioned (e.g., a software safety plan), they can be standalone documents or incorporated within other documents (e.g., a system safety plan, a
28、software management plan, a software development plan, or a software or system assurance plan). However, both the program, project, or facility, and the SMA have sign-off authority on safety planning and documentation. 1.3 Requirement Relief Relief from requirements in this Standard for application
29、to a specific program or project shall be formally documented as part of program or project requirements and approved by the Technical Authority in accordance with procedures in NPR 8715.3, paragraph 1.13 and NASA-STD 8709.20, Management of Safety and Mission Assurance Technical Authority. Provided
30、by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-9 of 57 2. APPLICABLE DOCUMENTS 2.1 General The documents listed in this section contain provisions that constitute requirements of this Standard as cited in the text. The latest issuances of cited documents app
31、ly unless specific versions are designated. Non-use of specific versions as designated shall be approved by the responsible Technical Authority. The applicable documents are accessible via the NASA Standards and Technical Assistance Resource Tool at http:/standards.nasa.gov or may be obtained direct
32、ly from the Standards Developing Organizations or other document distributors. NASA Directives are available at: http:/nodis3.gsfc.nasa.gov/. 2.2 Government Documents National Aeronautics and Space Administration NPD 7120.4 NASA Engineering and Program/Project Management Policy NPR 7120.5 NASA Progr
33、am loss of major system; loss of vehicle; loss of ground facility; severe environmental damage. Concur: The term concur or concurrence means to agree and accept, via signature, the readiness and content of a condition, requirement, report, deviation, document, etc. This also implies that if the stak
34、eholder (e.g. SMA) does not concur, that their sign-off is withheld and the document, waiver, deviation package, test report, hazard report, etc. is not to be considered acceptable until such changes are made to achieve agreement on the deliverable. Programmable Logic Devices (PLD) or Complex Electr
35、onics (CE): A programmable logic device or PLD is an electronic component used to implement user-defined functions into digital circuits. Unlike a logic gate, which has a fixed function, a PLD has an undefined function at the time of manufacture. PLD functionality is typically described using a hard
36、ware description language (HDL), such as Verilog or VHDL, which is then converted, using PLD vendor-specific tools, into the hardware gate structure of the PLD to implement the function. PLDs can be implemented one-time or can be reconfigurable. While PLD functionality is generally described using a
37、n HDL, it can also be written in specialized variations of other programming languages. The functionality can range from a simple set of gates to a very complex set of gates (i.e. an embedded processor). The compilation of gates is hardware (regardless of the complexity) including the development of
38、 the embedded processor. For the purposes of this Standard, any software to be executed on a processor embedded within a PLD will be evaluated from a software safety perspective. The design and resulting hardware will be evaluated from a system safety perspective and is not the purview of this stand
39、ard. The software tools used to generate safety critical PLDs configuration files will be evaluated from a limited COTS safety perspective as per sections 6.5 and 6.6 of this standard. Critical: 1 The condition where failure to comply with prescribed contract requirements can potentially result in l
40、oss of life, serious personal injury, loss of mission, or loss of a significant mission resource. Common uses of the term include critical work, critical processes, critical attributes, and critical items. 2 A condition that may cause severe injury or occupational illness, or major property damage t
41、o facilities, systems, or flight hardware. Firmware: The combination of a hardware device and computer instructions and data that reside as read-only software on that device. This term is sometimes used to refer only to the hardware device or only to the computer instructions or data, but these mean
42、ings are deprecated. The confusion surrounding this term has led some to suggest that it be avoided altogether. For the purposes of this Standard: Firmware is considered as software. Firmware is NOT the same as Programmable Logic Devices/Complex Electronics. Hazard Analysis: 1 Identification and eva
43、luation of existing and potential hazards and Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-12 of 57 the recommended mitigation for the hazard sources found. 2 The process of identifying hazards and their potential causal factors. Likelihood: Likel
44、ihood is the chance that something might happen. Likelihood can be defined, determined, or measured objectively or subjectively and can be expressed either qualitatively or quantitatively (using mathematics). From ISO 31000 2009 Plain English Risk Management Dictionary. For this document looking at
45、the software contribution; likelihood does not solely represent a probability of the initiating software cause, as these are systematic faults; it is a qualitative estimate of the likelihood of the software fault to propagate to the hazard (top level event). Factors such as control autonomy are roll
46、ed into that likelihood. Off-The-Shelf (OTS) software: Includes Commercial Off-The-Shelf (COTS), Government Off-The-Shelf (GOTS), and Modified Off-The-Shelf (MOTS) software. OTS software may also be legacy, heritage, and re-use software. Refer to section 6.6 of this Standard for applicability to COT
47、S. Preliminary Hazard Analysis: A gross study of the initial system concepts. It is used to identify all of the energy sources that constitute inherent hazards. The energy sources are examined for possible accidents in every mode of system operation. The analysis is also used to identify methods of
48、protection against all of the accident possibilities. Softwares high level roles in contributing to or protecting the system should be considered and recorded (e.g. softwares inadvertent release of an energy source or the detection and inhibit of an energy source). Provider: The entities or individu
49、als that design, develop, implement, test, operate, and maintain the software products. A provider may be a contractor, a university, a separate organization within NASA, or within the same organization as the acquirer. Safety Critical: Term describing any condition, event, operation, process, equipment, or system that could cause or lead to severe injury, major damage, or mission failure if performed or built improper
