Integration of Software Safety into the Systems ... · 7 Software Safety Overview • Software...

UNCLASSIFIED

Integration of Software Safety into the Systems Engineering Process –

DD(X), A Case Study

Integration of Software Safety into the Systems Engineering Process –

DD(X), A Case Study

Dick Church, Raytheon IDS [email protected]

540.469.2784

Dick Church, Raytheon IDS [email protected]

540.469.2784

mailto:[email protected]

mailto:[email protected]

2

Agenda

• System Safety Approach• Software Safety Overview• Software Safety Process

– Safety Requirements Flowdown– Determination of Software Criticality– Application of Safety Work Instructions– Assessment of Software Safety Defects

• Software Safety Results• Accomplishments To Date• Software Safety Summary

3

• DD(X) maintains and is executing a complete set of System and Software Safety Program Plans

• Identify Functional (software), Operational (human error), and physical (hardware) Hazards

• Identify and assess mitigation in design

• Recommend additional mitigation (if needed)

• Ensure hazards are controlled and gain residual risk acceptance

• Track all hazards throughout lifecycle

IDENTIFYHAZARDS

ANALYZE&

ASSESS

MITIGATE&

RESOLVE

CONTROL&

AUTHORIZE

PLAN

TRACKINGSYSTEM

IDENTIFYHAZARDS

ANALYZE&

ASSESS

MITIGATE&

RESOLVE

CONTROL&

AUTHORIZE

PLAN

TRACKINGSYSTEM

System Safety uses Systems Theory and Systems Engineering Approaches to Prevent Foreseeable Accidents and Minimize effects of those Accidents Unforeseen

DD(X) System Safety Approach

4


• System Level Hazard Analysis

– Determined Safety Abstraction of the system by defining System Level Top Level Events (TLEs) and Safety Critical Functions (SCFs)

• Defined 156 DD(X) TLEs

– TLEs are Events that must be avoided to ensure safety of the system

» Of the 156 TLEs, 120 have potential software causal influence

– Encompass Ship and Ordnance safety events

• Defined 68 DD(X) System Level SCFs

– SCFs are Functions that must work properly to ensure safety of the system

Safety Abstraction Defines the Scope of the System and Software Safety Program

5


• DD(X) Mishap Risk Index (MRI) matrix is a tool used to communicate residual risk to the system owner

Mishap Severity Category I Catastrophic II Critical III Marginal IV Negligible

Probability of Occurrence Mishap Risk Index (MRI) Frequent (A) 1 3 7 13 Probable (B) 2 5 9 16

Occasional (C) 4 6 11 18 Remote (D) 8 10 14 19

Improbable (E) 12 15 17 20

MRI Residual Risk Approval Authority 1-5 High: Requires ASN-RDA Risk Acceptance 6-9 Serious: Requires Program Executive Officer (PEO SHIPS) Risk Acceptance

10-17 Medium: Requires Program Manager PMS-500 Risk Acceptance 18-20 Low: Requires Program Manager PMS-500 Risk Acceptance

Address these first1-5

6-9

Save these for last10-1718-20

Risk Acceptance Process Satisfies DoD 5000.2 (System Acquisition)

6

System Safety Approach (Risk Reduction)

• Design for Minimum Hazard– Best to design risk out of System

• Ex: Railroad overpass instead of grade crossing

• Incorporate Safety Devices/Features– If can’t design out, design controls in (H/W

Devices & S/W Features as Interlocks)• Ex: Automatic gates at grade crossing

• Provide Warning Devices– Generate adequate visual or audible warning

signal – Susceptible to Human Error

• Ex: Warning lights at grade crossing• Develop Procedures and Training

– Susceptible to Personnel Turnover– Susceptible to Human Error

• Ex: Teaching drivers to be careful

Hazards and their associated

risks are controlled in

consideration of precedence

and cost effectiveness

Lowest Risk

Highest Risk

7

Software Safety Overview

• Software Safety is a discipline that identifies, analyzes, tracks, mitigates and controls software hazards and hazardous functions (data and commands) to ensure safe operation within a system context.

– Software Safety is a component of Software Assurance

• Others Components include: Software Quality, Software Reliability, Software Verification and Validation, and IV&V

– Software Assurance is a component of Mission Assurance

• The execution of a well-defined software safety program enhances Mission Assurance

Software Safety Contributes to Mission Assurance by Ensuring theWarfighter has “No Doubt” that the System will Work, and Work Safely

8


• Software Safety Focus– Identify, analyze, and assess in a system context, all potential

mishap software contribution pathways• Software Influence to Human Error• Software Subsystem Functions• Software Interfaces

HUMAN SUBSYSTEM INTERFACE

HAZARD

TLE

CAUSAL FACTORS

HARDWAREHARDWARESOFTWARESOFTWARE HARDWAREHARDWARESOFTWARESOFTWARESOFTWARE INFLUENCE

SOFTWARE INFLUENCEHUMAN

MACHINEHUMAN

MACHINE

SOFTWARE ANALYSISSOFTWARE ANALYSIS

9


• Software outside the system context is 100% SAFE– Software’s interaction with hazardous hardware or

operations, provide the venue for safety risk– Software can affect system safety in three basic

ways: • Exhibit behavior in terms of output values and

timing that contribute to the system reaching a hazardous state;

• Fail to recognize or control hardware failures, and • Provide erroneous or misleading information to an

operator that could lead to an human error. Software is an abstraction, and its “failures” are therefore due to

inadequate requirements definition, design, or logic errors

10


• Software Safety Program Scope (TSCE End-to-End)

Redundant High Speed Network

Processors Processors Processors

OE Operating Environment (OE) OE

Infrastructure Infrastructure Infrastructure

Common Srvc Common Services Common Srvc

Common Apps Common Applications Common Apps

Applications Sense, C3I, Engage, Ship, SupportApplications Applications

Embedded Systems

DecoysDecoys

NULKANULKA

CIGS 57MMCIGS 57MM

AGSAGS

TLAMTLAMSM-2SM-2VLAVLA

ESSMESSM

Operators(Multi-Modal Workstations)

DBRDBR

IFFIFF

HF ArrayHF Array

MF ArrayMF Array

MF Towed Array

MF Towed Array

Weapon Systems

Sensors

SATCOM SATCOM

UCARSUCARS

CDL-NCDL-N

LOS/BLOS (VHF, UHF, HF, LINK 11, 16, 22)

LOS/BLOS (VHF, UHF, HF, LINK 11, 16, 22)

ExComms

IntegratedBridge

IntegratedBridge

IPSIPS

AuxiliariesAuxiliaries

Ship SystemsDamage

Decision and Assessment

Damage Decision and Assessment

Adaptation Tier Core Processing Tier Presentation Tier

MK 57 VLSMK 57 VLS

Software Safety Employs a System-of-Systems Approach with Emphasis on Safety Critical Function Threads

11

Software Safety Overview Integration with Software Development

Software Requirement Definition & Synthesis

Code, Unit Test & Data Population

Design Definition & Synthesis

Concept Exploration & Functional Analysis

Functional Design Definition & Synthesis


Software Coding


Subsystem Integration & Test

Functional Qualification Test

System Integration& Test





Unit Test


Initial OperationalCapability

Software Safety Requirements

Analysis

Software Safety Design Analysis

Software Safety Code Analysis

Software Safety Test Verification

System Definition and Design Computer Program Definition and Design

Computer Program Implementation Computer Program Testing System Integration TestingSystem Definition and Design Computer Program Definition

and DesignComputer Program

Implementation Computer Program Testing System Integration Testing







Software Coding









Unit Test









Software Coding











Unit TestSubsystem Integration & Test

Unit Test




Analysis

Software Safety Design Analysis

Software Safety Code Analysis

Software Safety Test Verification

System Definition and Design Computer Program Definition and Design

Computer Program Implementation Computer Program Testing System Integration TestingSystem Definition and Design Computer Program Definition

and DesignComputer Program

Implementation Computer Program Testing System Integration Testing

Per S/W Release

SR Vision / Build Definition Document

SSR

Code & Unit Test

PQT / FQT

S-PDR / S-CDR

SWIT / SAT

SCP

Software Safety Continues to Work Hand-In-Hand and “In-Phase” with Systems and Software Engineering

12

Software Safety Overview Integration with Software Development

ID Name Start Finish Duration

2 SW Release 4 8/23/04 4/23/08 958 days3 SW Release 4 Rqrmnts Development 8/23/04 9/30/05 290 days4 Release 4 SSR 9/26/05 9/26/05 0 days

5 SW Release 4 DCTI 10/3/05 10/1/07 521 days6 Release 4 S-PDR Completed by all DE's 3/17/06 3/17/06 0 days

7 Release 4 S-CDR Completed by all DE's 9/15/06 9/15/06 0 days8 Delta R4/SCS Req & Architecture 5/23/05 1/27/06 180 days

9 Delta R4/SCS R4 Requirements Development 10/3/05 8/11/06 225 days10 Delta R4 SSR Start 7/10/06 7/10/06 0 days

11 Delta R4/SCS R4 DCTI 6/27/06 10/1/07 330 days12 Delta R4/SCS R4 S-PDR Completed by all DE's 11/13/06 11/13/06 0 days

13 Delta R4/SCS R4 S-CDR Completed by all DE's 3/5/07 3/5/07 0 days14 SW Release 4 SWIT 1/15/07 2/22/08 290 days

15 Release 4 SAT/SCP 1/3/08 4/23/08 80 days16 SW Release 5 12/1/05 4/16/09 881 days17 SW Release 5 Rqrmnts Development 12/1/05 12/5/06 264 days18 Release 5 SSR Start 11/3/06 11/3/06 0 days

19 SW Release 5 DCTI 9/25/06 10/23/08 544 days20 Release 5 S-PDR Completed by all DE's 4/13/07 4/13/07 0 days

21 Release 5 S-CDR Completed by all DE's 1/11/08 1/11/08 0 days22 SW Release 5 SWIT 4/1/08 1/22/09 213 days

23 SW Release 5 SAT/SCP 11/14/08 4/16/09 110 days24 System Integration Need Date 7/20/09 7/20/09 0 days

25 SW Release 6 9/27/06 3/12/10 903 days26 SW Release 6 Rqrmnts Development 9/27/06 7/30/07 219 days

27 Release 6 SSR Start 6/26/07 6/26/07 0 days28 SW Release 6 DCTI 6/13/07 9/16/09 591 days

29 Release 6 S-PDR Completed by all DE's 1/21/08 1/21/08 0 days30 Release 6 S-CDR Completed by all DE's 10/27/08 10/27/08 0 days

31 SW Release 6 SWIT 2/25/09 12/23/09 216 days

32 SW Release 6 SAT/SCP 10/15/09 3/12/10 107 days33 System Integration Need Date 6/21/10 6/21/10 0 days

8/23/04 9/30/059/26/05

10/3/05 10/1/073/17/06

9/15/065/23/05 1/27/06

10/3/05 8/11/067/10/06

6/27/06 10/1/0711/13/06

3/5/071/15/07 2/22/08

1/3/08 4/23/08

12/1/05 12/5/0611/3/06

9/25/06 10/23/084/13/07

1/11/084/1/08 1/22/09

11/14/08 4/16/097/20/09

9/27/06 7/30/076/26/07

6/13/07 9/16/091/21/08

10/27/082/25/09 12/23/09

10/15/09 3/12/106/21/10

Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q12004 2005 2006 2007 2008 2009 2010

13

Software Safety Process

Test Plans ProceduresTest Plans Procedures

COTS/NDI Selection Artifacts

COTS/NDI Selection Artifacts

Code ArtifactsCode Artifacts

Tier 1 System

Safety &

Environmental

Specification

Tier 1 System

Safety &

Environmental

Specification

–Lessons Learned

–Mil-Std-882D

–DD(X) ESHMP

–DD(X) SSSPP

–Lessons Learned

–Mil-Std-882D

–DD(X) ESHMP

–DD(X) SSSPP

Hazard Tracking SystemHazard Tracking System

Develop DD(X) System Level PHA

Identify:–Top-Level Events–System Level SCF’s

Develop DD(X) System Level PHA

Identify:–Top-Level Events–System Level SCF’s

Develop SR/CAPer Segment /

Element -Map SCF’s

Develop SR/CAPer Segment /

Element -Map SCF’s

Identify Safety Critical

Computing Software Functions (SCCSFs)

Identify Safety Critical

Computing Software Functions (SCCSFs)

Allocate / Map Software

Mitigations to Top-Level

Events

Allocate / Map Software

Mitigations to Top-Level

Events

Conduct Design & Code Analysis & Safety Testing based on SMRI

Conduct Design & Code Analysis & Safety Testing based on SMRI

Flow Down / Allocate To Segment

Specifications (6)

Flow Down / Allocate To Segment

Specifications (6)

Flow Down / Allocate To

Element Specifications

(37)

Flow Down / Allocate To


(37)

Derive Software Safety

Requirements in SRS’s / IRS’s Per Software

Release

Derive Software Safety

Requirements in SRS’s / IRS’s Per Software

Release

Define Software Safety Design / Implementation

Constraints / Requirements

Define Software Safety Design / Implementation

Constraints / Requirements

Develop Safety Design, Coding, COTS/NDI, &

Test Work Instructions

(W/I’s)

Develop Safety Design, Coding, COTS/NDI, &

Test Work Instructions

(W/I’s)

Invoke Safety Design, Coding, COTS/NDI, &

Test W/I’s based on SMRI by Developers

Invoke Safety Design, Coding, COTS/NDI, &

Test W/I’s based on SMRI by Developers

Identify & Tag Software Safety Requirements

(SMRI’s)

Identify & Tag Software Safety Requirements

(SMRI’s)

Design ArtifactsDesign ArtifactsSoftware Safety /

Software Engineering

Software Safety / Requirements Engineering

Software Safety Analysis

Per Software ReleaseOnce with Updates

PHA SR/CASSHA SHA O&SHA

InitialRisk

Risk(+/-)

Risk(+/-)

Risk(+/-)

S/WOnly

Risk(+/-)Develop

HTS

Software Safety

Assessment(Per S/W Release)

Software Safety

Assessment(Per S/W Release)

Software Certification / IV&V / SQASoftware Certification / IV&V / SQA

DD(X) System /

Segment / Element /

Component -----------

Integration & Test

DD(X) System /

Segment / Element /

Component -----------

Integration & Test

Integration of Software Safety with

Systems Engineering Provides the

Lowest Software

Safety Risk

Res

ults

(SC

Rs/

STR

s)

14

Software Safety ProcessSafety Requirements Flowdown

Tier 1 Safety Specification

Segment Specifications


Hazard Monitor & Mitigation Software Requirements Specifications

Software Release Vision Safety Critical Functions

Top Level EventsSystem Architecture

Element Level Hazards

Flow Down / Allocation

Flow Down / Allocation

Flow Down / SRS Derivation

System Engineering Inputs Hazard Analysis Inputs

Use Cases

Per S/W Release

CompleteUp To SR4

In-Place

Complete

Complete

CompleteUp To SR4

In-Place

Complete

Complete

15

Software Safety ProcessDetermination of Software Criticality

• Software Criticality Matrix (SCM) dictates software development & software safety analytical rigor

Mishap Severity Category I Catastrophic II Critical III Marginal IV Negligible Software Control Category A Autonomous control with

no outside intervention SMRI 1 SMRI 1 SMRI 2 SMRI 4

B Semi-Autonomous control with outside intervention

SMRI 1 SMRI 2 SMRI 3 SMRI 4

C Semi-Autonomous control with redundant backup


D Influential with no direct control


E No involvement with Safety functions or data

SMRI/Risk Required Software Safety Analysis and Test

1 HIGH

• All Safety Work Instructions Apply. • Requirements analysis, design analysis, code analysis and safety specific testing. • Requires ASN-RDA Risk Acceptance if requisite analysis & test not conducted.

2 SERIOUS

• All Safety Work Instructions Apply. • Requirements analysis, design analysis & in-depth safety specific testing. • Requires Program Executive Officer (PEO SHIPS) Risk Acceptance if requisite

analysis & test not conducted.

3 MEDIUM

• COTS/NDI & Testing Work Instructions Apply. • Requirements analysis & safety specific testing. • Requires Program Manager PMS-500 Risk Acceptance if requisite analysis & test not

conducted.

4 LOW

• COTS/NDI & Testing Work Instructions Apply. • Requirements analysis & standard testing process. • Requires Program Manager PMS-500 Risk Acceptance if requisite analysis & test not

conducted.

Software Mishap Risk Index (SMRI)

No Safety Analysis Required

16

Software Safety ProcessApplication of Safety Work Instructions

• Software Criticality Matrix purpose is twofold:– Dictates Level of Analysis & Test Rigor Software Safety must conduct to

ensure safe implementation of design & code in a System Context– Invokes Safety Work Instructions for designers, developers, & testers

based on software criticality (Software Mishap Risk Index (SMRI))• Four (4) Software Safety Work Instructions invoked based on software

safety criticality (Level of Autonomous Control)– DDX-SWI 5.011.001: Software Safety Design

» Invoked if SMRI = 1 or 2– DDX-SWI 5.011.002: Software Safety Coding

» Invoked if SMRI = 1 or 2– DDX-SWI 5.011.003: Software Safety Testing

» Invoked for all SMRI values (SMRI 1-4)– DDX-SWI 5.011.004: Software Safety COTS/NDI

» Invoked for all SMRI values (SMRI 1-4)

Compliance with Software Safety Work Instructions Ensure Safety is “Designed Into” the Software System

17


• A Work Instruction requirements checklist is provided at the end of each W/I requirements section:

• Example:Degree of Compliance /

Applicability Section Shall Compliance Statement FC N/A PC NC

6.1.1 Y Does the design define safe states? X

6.1.2 Y Does the software design support aborting safety critical processes to return to a defined safe state?

X

6.1.3 Y Does the process begin and end in a safe state? X

6.1.4 Y

Does the software design mitigate against hardware faults (power loss, hardware failure, computer failure, etc) by going to a safe state?

X

6.1.5 Y Does the software design support fail operate behavior? X

6.1.6 N Does the software design support instrumentation of discrete events that occur during safety critical processes?

X

No further action required

Waiver required

Completed Checklist’s are maintained as part of the Software Development File as Artifact Evidence

18


• Computer Based Software Safety W/I Training Modules– SPE CPT Rolled out to DA Community – 10/26/05

19

Software Safety ResultsSoftware Safety Requirements Verification

Release 3 Software Safety Requirements (SSRs)

050

100150200250300350400450

TSCEI Sense Engage C3I Ship

SSR

s

Software SafetyRequirements (SSRs)Verified in Design

Verified inImplementation

Verified in Design

Verified in Implementation

TSCEI 15 11 1358 404 404 392Sense 3 3 265 163 163 163Engage 5 5 219 59 59 59C3I 25 25 1505 229 229 229Ship 3 3 69 25 25 25

Release 3

Segment SCIs

Safety Critical SCIs Requirements


(SSRs)

Safety Requirements Verified

Of 890 SR3 Software Safety Requirements

(SSRs), 12 either failed or could not

be tested

20

Software Safety ProcessSafety Requirements Flowdown

• Due to the spiral development nature of DD(X) software releases,full software mitigation to TLE may not be realized in a single build– Full software mitigation of an individual TLE typically requires

multiple mitigations across a safety critical thread • Most TLEs have multiple failure paths that require unique

mitigations• Collective implementation of Partial (P) mitigations across

multiple software releases form “full software mitigation”

Partial Software Mitigation

Additional Partial Software Mitigation

Full Software Mitigation Realization

Key

S/W Releases R1 R2 R3 R4 R5 R6 Spiral 1

Top Level Event: Ship Run Aground

Integrated Bridge (Ship)

Situational Awareness (C2)

Precision GPS Navigation

(TSCEI)

P(SR2) + P(SR3) + P(SR5) = Full Mitigation

21

Software Safety ResultsTLE Full Mitigation Outlook (Excerpt)

X=Segment has Causal or Mitigation Requirements P=Partial Causal or Mitigation RequirementsP+=Additional Partial Causal or Mitigation RequirementsF=Full Causal or Mitigation Requirements RealizedN=No Causal or Mitigation Requirements in Release

SEGMENT APPLICABILITY

SOFTWARE RELEASE MITIGATION (PLANNED)

HAZARD TRACKING

SYSTEM IDENT

TOP LEVEL EVENT (TLE) TITLE TLE SEVERITY

SHIP

TSC

EI

SUPP

OR

T

SEN

SE

C3I

ENG

AG

E

R1 R2 R3 R4 R5 R6 S1

SYS-001 Engagement of Airborne Friendly (ESSM)` I X X X X N P P+ P+ F F F

SYS-005 Engagement of Surface Friendly (ESSM) I X X X X N P P+ P+ F F F

SYS-014 Launch Into Own Ship (ESSM) I X N P P P+ F F F

SYS-018 Debris from Launch contacts Own Ship or Friendly Asset (ESSM) II X X N P P P+ F F F

SYS-022 Firing Into Own Ship (AGS) I X N N P P+ F F F

SYS-028 Failure to Halt Launch (ESSM) I X X X X N P P+ P+ F F F

SYS-029 Failure to Break Engagement (ESSM) I X X X X N P P+ P+ F F F

SYS-030 Failure to Halt Firing (AGS) I X X X N N P P+ F F F

SYS-037 Inadvertent ESSM Launch (Tactical, Training, Test, & Maintenance) I X X X X N P P P+ P+ P+ F

SYS-042 Inadvertent AGS Firing (Tactical, Training, Test, & Maintenance) I X X X X N N P P+ P+ P+ F

SYS-044 Inadvertent radiation of DBR or NAV Radar (Tactical, Training, Test, & Maintenance) I X X P P+ P+ P+ F F F

SYS-046 Inadvertent initiation of active Sonar (Tactical, Training, Test, & Maintenance) I X X N N P P+ F F F

SYS-054 Restrained Firing (ESSM) I X N N P P+ F F F

SYS-062 AGS to VLS Launched Ordnance Fratricide I X X N N P P+ P+ P+ F

22

Software Safety ResultsSR4 Safety Critical Software Functions

Initial Program Load Processing Weapon Display Status Processing

Stable State Processing No Radiate Zone Processing

ESSM Engagement Processing RF System Control Processing

SM Engagement Processing* No Point No Fire Zone Processing

Break Engagement-ESSM Processing Break Engagement-SM Processing*

Airspace De-confliction* Ordnance System De-confliction*

Navigation Control Processing* Ship Rudder Control Processing*

Ship Speed Control Processing* Fuel Level Monitor/Control Processing*

Target Identification Processing AGS Mount Movement Processing

IFF Processing Break Engagement-AGS Processing

Situational Awareness Processing Engagement Doctrine Verification Processing

System Display Status Processing Return To Force De-confliction Processing*

Tactical / Training / Test Data Separation Processing*

Ownship Helo Control Processing*

Fire Detection Monitor Processing* Fire Suppression Control Processing*

* New to SR4

23

Software Safety ResultsSR4 TLEs with Software Causal Influence

SYS-0144 Unknown Processing State SYS-0087

SYS-0145 SYS-0046

SYS-0014

SYS-0018

SYS-0022

SYS-0030

SYS-0054

SYS-0062

SYS-0064

SYS-0095

SYS-0097

SYS-0013

SYS-0053

SYS-0036

SYS-0037

SYS-0050

SYS-0105

SYS-0148

SYS-0001

SYS-0028

SYS-0029

SYS-0147

SYS-0087

SYS-0037

SYS-0042

SYS-0044

SYS-0045

SYS-0002

SYS-0026

SYS-0027

SYS-0051

SYS-0117

Personnel Exposure to Radio Frequencies (HERP)

Unknown Weapon Status Inadvertent Initiation of Active Sonar

Hazardous Misleading Information Launch into Own Ship (ESSM)

Engagement of Friendly (ESSM) Debris from Launch Contacts Own Ship or Friendly Asset (ESSM)

Failure to Halt Launch (ESSM) Firing into Own Ship (AGS)

Failure to Break Engagement (ESSM) Failure to Halt Firing (AGS)

Loss of Weapon Past Safe Separation Restrained Firing (ESSM)

Inadvertent Exposure to Radio Frequencies AGS to VLS Launched Ordnance Fratricide

Inadvertent ESSM Launch VLS Weapon and VLS Weapon Fratricide

Inadvertent AGS Firing Inadvertent Movement of AGS Magazine Hoist

Inadvertent Radiation of DBR Inadvertent VLS Hatch Movement

Inadvertent Radiation of IFF Launch into Own Ship (SM)

Engagement of Friendly (SM) Restrained Firing (SM)

Failure to Break Engagement (SM) Inadvertent ESSM Launch (Tactical, Training, Test, & Maintenance)

Inadvertent Propulsion (thrust) Control (Tactical, Training, Test, & Maintenance)

Inadvertent Steering Control (Tactical, Training, Test, & Maintenance)

Uncontrolled Flooding from Fire Suppression System

Inadvertent Discharge of Fire Suppression System

Failure to Halt Launch (SM) Inadvertent SM Launch (Tactical, Training, Test, & Maintenance)

24

Software Safety ProcessAssessment of Software Safety Defects

• Software Defect Assessment Criteria– Criteria Safety Risk maps directly to the DD(X) MRISafety STR

Priority Safety Risk Description of Safety Criteria

1 HIGH A software implementation, design, or requirement defect that: • leads directly to a catastrophic or critical mishap, or • subjects the system to a single point (1) failure that would lead to a catastrophic or

critical mishap.

2 SERIOUS A software implementation, design, or requirement defect that: • influences a catastrophic or critical mishap, but where two (2) independent

functioning interlocks or human actions remain, or • leads directly to a marginal or negligible mishap.

3 MEDIUM A software implementation, design, or requirement defect that: • influences a catastrophic or critical mishap, but where three (3) independent

functioning interlocks, or human actions remain, or • influences a marginal or negligible mishap, reducing the system to a single point (1)

of failure.

4 LOW A software implementation, design, or requirement defect that: • influences a catastrophic or critical mishap, but four (4) or more independent

functioning interlocks or human actions remain. • A problem that would be a causal factor for a marginal or negligible mishap, but two

(2) independent functioning interlocks, or human actions remain. - A requirement that, if implemented, would negatively impact safety, however code is correct. - Non, or partial compliance of Software Work Instruction generic safety requirements.

25

Accomplishments To Date

• Independent Software Safety Review Boards– Successful Software Systems Safety Technical Review Panels (SSSTRP)

and Software Certification Panels (SCPs)• SSSTRPs

– TSCEI SSSTRP – 9 Dec 04» SSSTRP stated process presented was comprehensive

and sufficient to mitigate risk associated with TSCEI software

– System Level Pre-CDR SSSTRP – 1 Jun 05» SSSTRP Concurred with Software Safety Design

Approach and Program Readiness for System CDR– SR 3 SSSTRP – 30 Sept 05

» SSSTRP Concurred to continue S/W development using SR 3 as baseline

• SCPs– Software Release 2 SCP – 29 Apr 05– Software Release 3 SCP – 24 Oct 05

SSSTRPs Scheduled for all Future DD(X) Software Releases (4, 5, and 6)

26

Summary

• Software Safety integrated across DD(X) Software Product Teams• A Proactive and Integrated Software Safety process is being

executed using Mil-Std-882D & CMMI® initiatives as framework– Traditional Software Hazard Analysis techniques / processes – Software Safety embedded with Requirements Engineering

through Tier 1 Safety Specification Flow Down Process– Software Safety embedded with Software Engineering through

application of Work Instructions– Software Safety embedded with T&E through development of

safety specific test plans/procedures and validation of SSRsduring test execution

The DD(X) Software Safety Program Emphasizes Building in Safety,Not Adding it to a Completed Design

Integration of Software Safety into the Systems ... · 7 Software Safety Overview • Software...

Documents

Transcript of Integration of Software Safety into the Systems ... · 7 Software Safety Overview • Software...