integration of software safety into the systems ... · 7 software safety overview • software...
Post on 16-May-2018
219 Views
Preview:
TRANSCRIPT
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 Richard_Church@Raytheon.com
540.469.2784
Dick Church, Raytheon IDS Richard_Church@Raytheon.com
540.469.2784
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
DD(X) System Safety Approach
• 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) System Safety Approach
• 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 Overview
• 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 Safety Overview
• 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 Overview
• 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 Requirement Definition & Synthesis
Software Coding
Design Definition & Synthesis
Subsystem Integration & Test
Functional Qualification Test
System Integration& Test
System Integration& Test
Concept Exploration & Functional Analysis
Functional Design Definition & Synthesis
Subsystem Integration & Test
Unit Test
System Integration& 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 Requirement Definition & Synthesis
Code, Unit Test & Data Population
Design Definition & Synthesis
Concept Exploration & Functional Analysis
Functional Design Definition & Synthesis
Software Requirement Definition & Synthesis
Software Coding
Design Definition & Synthesis
Subsystem Integration & Test
Functional Qualification Test
System Integration& Test
System Integration& Test
Concept Exploration & Functional Analysis
Functional Design Definition & Synthesis
Subsystem Integration & Test
Unit Test
System Integration& Test
Initial OperationalCapability
Software Requirement Definition & Synthesis
Code, Unit Test & Data Population
Design Definition & Synthesis
Concept Exploration & Functional Analysis
Functional Design Definition & Synthesis
Software Requirement Definition & Synthesis
Software Coding
Design Definition & Synthesis
Subsystem Integration & Test
Functional Qualification Test
Subsystem Integration & Test
Functional Qualification Test
System Integration& Test
System Integration& Test
Concept Exploration & Functional Analysis
Functional Design Definition & Synthesis
Subsystem Integration & Test
Unit TestSubsystem Integration & Test
Unit Test
System Integration& 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
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
Element Specifications
(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
Element 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
SMRI 2 SMRI 3 SMRI 4 SMRI 4
D Influential with no direct control
SMRI 3 SMRI 3 SMRI 4 SMRI 4
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
Software Safety ProcessApplication of Safety Work Instructions
• 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
Software Safety ProcessApplication of Safety Work Instructions
• 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
Software Safety 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
top related