bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin


Wiki Markup
{alias:SWE-133}
Tabsetup
Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned1. The Requirement


{div3:id=} h1.
Wiki Markup
Div
idtabs-1

1.

Requirements

2.2.8.3

The

project,

in

conjunction

with

the

Safety

and

Mission

Assurance

organization,

shall

determine

the

software

safety

criticality

in

accordance

with

NASA-STD-8739.8.

h2. {color:#003366}{*}

1.1

Notes{*}{color} Software safety criticality is initially determined in the formulation phase using the NASA Software Assurance Standard,

Notes

Software safety criticality is initially determined in the formulation phase using the NASA Software Assurance Standard, NASA-STD-8739.8.

{sweref:278}As the software is developed or changed and the computer software configuration items

sweref
278
278
As the software is developed or changed and the computer software configuration items (CSCI),

models,

and

simulations

are

identified,

the

safety-critical

software

determination

can

be

reassessed

and

applied

at

lower

levels.

The

software

safety

assessment

and

planning

are

performed

for

each

software

acquisition,

development,

and

maintenance

activity,

and

for

changes

to

legacy\heritage

systems.

When

software

in

a

system

or

subsystem

is

found

to

be

safety

critical,

additional

requirements

in

the

NASA

Software

Safety

Standard

{sweref:271} will augment those associated with the software class requirements found in this document. The software assurance organization is required by NASA Software Assurance Standard,

sweref
271
271
will augment those associated with the software class requirements found in this document. The software assurance organization is required by NASA Software Assurance Standard, NASA-STD-8739.8,

{sweref:278}to perform an independent software safety criticality assessment and work with the project to resolve any differences. Engineering and software assurance must reach agreement on safety-critical determination of software. Disagreements are elevated via both the Engineering Technical Authority and Safety and Mission Assurance Technical Authority chains. h2. 1.2 Applicability Across Classes {applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=1|cnsc=1|dsc=1|dnsc=1|esc=1|ensc=1|f=1|g=1|h=1} {div3}
Wiki Markup
{div3:id=tabs-2} h1. 2. Rationale Each project, with the responsible Software Assurance organization, evaluates the project software to determine if the software is safety-critical.  If the software is determined to be safety critical, the software safety requirements within NPR 7150.2, NASA Software Engineering Requirements, and

sweref
278
278
to perform an independent software safety criticality assessment and work with the project to resolve any differences. Engineering and software assurance must reach agreement on safety-critical determination of software. Disagreements are elevated via both the Engineering Technical Authority and Safety and Mission Assurance Technical Authority chains.

1.2 Applicability Across Classes


applicable
f1
g1
h1
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc1
dnsc1
dsc1
ensc1



Div
idtabs-2

2. Rationale

Each project, with the responsible Software Assurance organization, evaluates the project software to determine if the software is safety-critical.  If the software is determined to be safety critical, the software safety requirements within NPR 7150.2, NASA Software Engineering Requirements, and NASA-STD-8719.13,

NASA

Software

Safety

Standard,

{sweref:271} are applied to the

sweref
271
271
are applied to the safety-critical

project

software.

{div3}
Wiki Markup
{div3:id=


} h1.
Div
idtabs-3

3.

Guidance

The

project

can

use

NASA-STD-8739.8

{sweref:278}to perform its determination of the software safety criticality. The software safety litmus test in Appendix A.1 of the Standard is applicable to all projects. The software is considered safety critical if it meets any of the three major criteria listed in the appendix. If the project is determined to be safety critical, then the project must adhere to the applicable statements in

sweref
278
278
to perform its determination of the software safety criticality. The software safety litmus test in Appendix A.1 of the Standard is applicable to all projects. The software is considered safety critical if it meets any of the three major criteria listed in the appendix. If the project is determined to be safety critical, then the project must adhere to the applicable statements in NASA-STD-8719.13.

  {sweref:271} As noted in

 

sweref
271
271

As noted in NASA-STD-8719.13,

{sweref:271}non

sweref
271
271
non safety-critical

software

residing

with

safety-critical

software

is

a

concern

because

it

may

fail

in

a

way

that

it

disables

or

impairs

the

functioning

of

the

safety-critical

software.

When

methods

to

separate

the

code,

such

as

partitioning,

can't

be

used

to

limit

the

software

defined

as

safety

critical,

care

must

be

exercised

to

assure

safety

for

a

block

of

software

(multiple

CSCI)

where

only

a

portion

are

safety

critical,

and

or

for

individual

safety

critical

CSC's

within

a

larger

CSCI.

NASA-STD-8719.13

{sweref:271}requires the software safety criticality to be

sweref
271
271
requires the software safety criticality to be re-assessed

periodically

(typically

at

each

major

milestone

review)

by

the

project's

responsible

software

assurance

engineer.

This

individual

evaluates

the

project

software

for

determination

of

safety

criticality

utilizing

the

Software

Safety

Litmus

Test

within

NASA-STD-8719.13.

{sweref:271}This allows the software safety requirements to be refined and applied to the required areas (preventing a possibly costly over-application or a non-compliant and risky under application). It also assures that requirements are met and/or changes to the software are addressed and checked for safety criticality. The software safety criticality assessment process and the location of the assessment results are documented within the Software Safety Plan (or equivalent). Most projects document the software safety criticality with the software classification. The project's system safety documentation also addresses it. A best practice is to document the software safety criticality assessment results with the software classification assessment, with local S&MA and the Engineering TA both approving the results.  An example form is provided in

sweref
271
271
This allows the software safety requirements to be refined and applied to the required areas (preventing a possibly costly over-application or a non-compliant and risky under application). It also assures that requirements are met and/or changes to the software are addressed and checked for safety criticality.

The software safety criticality assessment process and the location of the assessment results are documented within the Software Safety Plan (or equivalent). Most projects document the software safety criticality with the software classification. The project's system safety documentation also addresses it.

A best practice is to document the software safety criticality assessment results with the software classification assessment, with local S&MA and the Engineering TA both approving the results.  An example form is provided in NASA-STD-8719.13.

{sweref:271}\\ {div3}

Wiki Markup
{div3:id=tabs-4}

h1. 4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.
{div3}
Wiki Markup
{div3:id=tabs-5}

h1. 5. Resources



{refstable}

{toolstable}
{div3}
Wiki Markup
{div3:id=tabs-6} h1. 6. Lessons Learned A documented lesson from the NASA Lessons Learned database notes the following:  *Mars Global Surveyor (MGS) Spacecraft Loss of Contact. Lesson Number 1805:*  "Contact was lost with the Mars Global Surveyor (MGS) spacecraft in November 2006 during its 4th extended mission. A routine memory load command sent to an incorrect address 5 months earlier corrupted positioning parameters, and their subsequent activation placed MGS in an attitude that fatally overheated a battery and depleted spacecraft power. The report by the independent MGS Operations Review Board listed 10 key recommendations to strengthen operational procedures and processes, correct spacecraft design weaknesses, and assure that economies implemented late in the course of long-lived missions do not impose excessive risks."  {sweref:569} {div3}

sweref
271
271


Div
idtabs-4

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.


Div
idtabs-5

5. Resources


refstable

toolstable


Div
idtabs-6

6. Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following: 

Mars Global Surveyor (MGS) Spacecraft Loss of Contact. Lesson Number 1805:  "Contact was lost with the Mars Global Surveyor (MGS) spacecraft in November 2006 during its 4th extended mission. A routine memory load command sent to an incorrect address 5 months earlier corrupted positioning parameters, and their subsequent activation placed MGS in an attitude that fatally overheated a battery and depleted spacecraft power. The report by the independent MGS Operations Review Board listed 10 key recommendations to strengthen operational procedures and processes, correct spacecraft design weaknesses, and assure that economies implemented late in the course of long-lived missions do not impose excessive risks." 

sweref
569
569