1. 4-15-99 1 Steven F. Mattern Science and Engineering Associates, Inc. (505) 346-9839

2. 4-15-99 2 Todays Topics Software Safety Analysis Software Safety Analysis – A Historical Perspective – A Personal Perspective Elements of Sound Safety Engineering Elements of Sound Safety Engineering Structured Software Safety Object Oriented Software Safety Products Produced (examples)

3. 4-15-99 3 Failures…A Performance Issue UndesiredPerformance UnintendedPerformance Fault-InducedPerformance UnsafePerformance

4. 4-15-99 4 Undesired Event Analysis System Safety Engineering –Hazards –Hazard Causes –Hazard Mitigation and Fault Avoidance Reliability Engineering –Faults and Failure Modes –Fault Pathways to Undesired Events –Fault Detection, Fault Tolerance, and Fault Recovery Operational Effectiveness –Faults and Failure Conditions –Fault Pathways to Undesired Events –Undesired Event Mitigation or Fail Safe/Fail Operational CAUSED BY a Combination of: HardwareSoftware Human Error Software-Influenced HMI Data Input

5. 4-15-99 5 UNDESIRED EVENT Software Hardware Human Error Software Failure Modes and/or Causal Factors System-Level Undesired Events and/or Conditions THIS WAY...VIA System Safety Engineering Analysis Techniques BRIDGING Between System-Level Events and the System Hardware, Software, and the Operator/Maintainer... Top-Down Approach

6. 4-15-99 6 Elements Elements of System Safety Definition of Safety-Critical Functions Tailored Safety Requirements & Guidelines Identification of System/Subsystem Hazards & Failure Modes Determination of System-Level Effects Categorization of Hazard Severity & Likelihood Identification of Hazard Causes (HW/SW/Human Interaction) Derivation of Functional Hazard Mitigation Requirements Determination of Safety Requirements Implementation Determination of Residual Safety Risk Final Categorization Hazard of Severity & Likelihood

7. 4-15-99 7 Sources of System Safety Requirements Generic Software Safety Requirements Guidelines and Specifications Derived Functional Safety Requirements Lessons Learned Design Specifications Similar System Analysis User Inputs Systems Engineering Automated Environment Hazard Causal Factor Analysis SYSTEM SAFETY REQUIREMENTS System & Subsystem Hazard Analysis System Requirements System Architecture Initial Constraints Functional Requirements

8. 4-15-99 8 Causal Factors H/W S/W HE S/WIHE Causal Factors H/W S/W HE S/WIHE Causal Factors H/W S/W HE S/WIHE Causal Factors H/W S/W HE S/WIHE ROOT HAZARD Failure Mode A Failure Mode B Software- Influenced Human Error Failure Mode C Failure Mode D Initial Depth of Analysis To the Depth Required to Mitigate Effectively ~~~~ PDR-Level CDR-Level To The Depth Required

9. 4-15-99 9 Methods For Causal Factor Analyses Safety-Critical Functions Analysis System States/Modes Analysis Hazards Analysis (System & Subsystem Level) Fault Tree Analysis (Usually Limited to System-Level Hazards) Failure Modes & Effects Criticality Analysis Hybrid Event Trees or Reliability Block Diagrams Software Data Flow Analysis Software Functional Flow Analysis Interface Analysis (Hardware/Software/Operator/Maintainer) Tailored For Customer, Program, & Environment

10. 4-15-99 10 A REQUIRED FUNCTION DOES NOT OCCUR Failure of the software to perform a required function; that is, the function is never executed, or no output is produced. AN UNDESIRED EVENT OCCURS The software performs a function not required. (i.e. getting the wrong answer, issuing the wrong control instruction, or doing the right thing but under inappropriate conditions). AN INCORRECT SEQUENCE OF REQUIRED EVENTS The software possesses sequencing problems. For example, failing to ensure that two events happen at the same time, at different times, or in a particular order. TIMING FAILURES IN EVENT SEQUENCES The software exceeds maximum time constraints between events, fails to ensure minimum time constraints between events or possesses duration failures. AN INCORRECT RESPONSE TO A SAFETY-CRITICAL EVENT The software fails to recognize a hazardous condition requiring corrective action, fails to initiate a fault tolerant response to a recognized safety-critical function, or produces the wrong response to a hazardous condition or failure mode. Potential Influence of Software

11. 4-15-99 11 Hazards (HAZ) Hazards (HAZ) Software Req (SWR) Software Req (SWR) CSCI Scenario (SCE) Segment Scenario (SSC) Segment Scenario (SSC) Segment Behavior (SBE) Segment Behavior (SBE) Interface (CIM/CID) Interface (CIM/CID) Testing (VER_SWR) Testing (VER_SWR) Object Oriented Design

12. 4-15-99 12 MCS SCE00820 Activate a Scheduled Mission CUI SCE00??? Begin Resupply Mission SAS SCE00899 Perform Docked Resupply (Fwd Veh) #5 <Commence _Execution _Order> #1 MCS< Commence_ Execution_Command> #2 Notify Crew to Begin Resupply Mission (CUI) #3 Uses SAS SCE00882 #1 VMG <Dock_Deploy _Notification> #2 Uses SAS SCE00868 #1 (RPC and ACU) #2 <Ammunition_ Inventory _ Data> (RPC) SAS SCE00882 Develop Resupply Op Request (Fwd Veh) SAS SCE00868 Obtain Vehicle Inventory 2 1 VMG SCE02057 Deploy SPH #6 <Dock_Deploy_Notification 3 1. Can not find the Crew Notification within CUI to begin resupply mission. SCE00899 sends message…but to where? SAS to CUI interfaces describes Resupply_Authorization_Request, but it does not appear in the CUI SRS 2. This Scenario uses the term USES. Is Uses the same as Invokes? 3. It is unsure if SCE00868 and SCE00871 are processed concurrently or are they processed in series 4. This message is used to request resupply guidances. Resupply guidances are provided by the POC, and include substitution rules, end-state guidance, controlled supply rate, and resupply thresholds. However, there is no development of this message in the TDA SRS…No message received and no message provided to SAS 5. AFT SCE01132 does not receive this message from RPC SCE00498, does not obtain inventory data from any know source, nor does it send the data back to RPC SCE00498 6. Same comment as #5 7. Assume the command to Retrieve Projectile Inventory Data is processed internal to RPC SCE00498 8. ACU SCE02338 Has not yet been developed Notes: RPC SCE00489 Provide Inventory Data AFT SCE01132 Provides Propellant Inventory Data #1 #2 <Propellant_Inventory _Request> (AFT) #3 Retrieve the Projectile Inventory Data #4 #5 <Ammunition_Inventory_Data 5 6 7 ACU SCE02338 Perform Resupply Fuel Transfer (Sender) 8 Safety Analysis of Scenarios

13. 4-15-99 13 Contextual Applicability to Hazards

14. 4-15-99 14 Test Requirements Based Upon Causes & Mitigation UNDESIRED EVENT Failure Mode A Failure Mode B Failure Mode C Failure Mode D Hardware Failure Human Error Software Error Timing Error Sequencing Error Algorithm Error What Causes, Initiates, or What Causes, Initiates, or Influences The Undesired Event ? What Requirements Have Been What Requirements Have Been Implemented To Mitigate ? How Will Testing Be Accomplished How Will Testing Be Accomplished to Prove Implementation of Mitigation Requirements ? Testing for Functionality and Loss Testing for Functionality and Loss of Functionality. How Will The System Respond to How Will The System Respond to Failure ? Fault Tolerance/Recovery

15. 4-15-99 15 Hazards (SHZ) Hazards (SHZ) CSCI Scenario (SCE) Testing (VER_SWR) Testing (VER_SWR) Hazards (HAZ) Hazards (HAZ) CSCI Scenario (SCE) CSCI Scenario (SCE) CSCI Scenario (SCE) CSCI Scenario (SCE) CSCI Scenario (SCE) Testing (VER_SWR) Testing (VER_SWR) Testing (VER_SWR) Testing (VER_SWR) Testing (VER_SWR) Testing (VER_SWR) Context DetailCompletenessSegmentElementCSCI Testing Scenario Completeness

16. 4-15-99 16 System Safety Requirement Software Requirement Description Affected CSCI Test Procedure Requirement Test Results Software Requirements Traceability Matrix 1.2.3.1 1.2.3.3 1.3.4.1 The WCS Shall Monitor the Status of the JWS Missiles That Are Powered up. The WCS Shall Safe and Deselect Any JWS Missile That Fails BIT The JWS Missile Shall Withhold Active RF Emissions Until Terminal Impact Phase System Safety Requirement Test or Analysis Activity Verified DateComments System Safety Requirements Verification Matrix The JWS WCS Shall Include Processing Elements to Verify IPL Results The JWS WCS Shall Include Software Elements to Safe the RM During Unsafe States The JWS Missile Shall Include Software to Prevent Active RF Until Terminal Phase JWS WCS JWS Missile FTH WDC FIC VU0012 VU10002 VU234003 FAIL PASS 5/7/02 5/9/02 6/3/02 Failed 1ST Attempt See Test Log 1001 None Evidence of Hazard Control

17. 4-15-99 17 EXAMPLE 1.0 Man Machine Interface (MMI) 1.1 PROCESS CANCELLATION 1.1.1 The System shall be designed such that the operator may exit from a potentially unsafe state with a single action 1.1.2 Exiting from an unsafe state or condition shall place the system in a known safe state, report the failure, and display the system status to the operator. 1.2 SAFETY-CRITICAL PROCESS INITIATION 1.2.1 Safety-Critical operator displays, legends, and other interface functions shall be clear concise, and unambiguous. 1.2.2 Safety-Critical displays shall be duplicated, where possible, on separate display devices. 1.2.3 Safety-Critical alerts to the crew shall be readily distinguishable from routine alerts. 1.2.4 Upon detection of an unsafe state, the system shall alert the operator to the anomaly detected, the action taken, and the resulting system configuration and status. 1.3 OPERATOR ENTRY ERRORS 1.3.1 The software shall be capable of detecting improper operator entries, or sequence of entries, and thereby prevent the the execution of safety-critical functions. 1.3.2 The software shall alert the operator to an erroneous entry. 1.3.3 Operator alerts shall indicate the error and corrective action. 1.3.4 After operator corrective action to an erroneous entry, the software shall provide positive confirmation of a valid data entry, and a real-time indication that the system is functioning properly. 1.3.5 Safety-Critical functions which require several seconds or longer to process shall provide a status indicator to the operator during processing. 1.4 POSITIVE FEEDBACK 1.4.1 Software control of safety-critical functions shall have positive feedback indicators to the operator to provide assurance that the system is functioning properly. 1.5 SAFETY-CRITICAL ALERTS 1.5.1 The operator shall not be able to clear a safety-critical alert without taking corrective action. Initial Software Safety Constraints

18. 4-15-99 18 Safety-Critical Function Analysis System Function Ramification of Failure Relevant SubSystems Tactical & Technical Software Data Displays & Controls Control (Armament) Tactical & Technical Software Data Displays & Controls Training Maintenance Fail to define baseline data - Results in weapon firing into friendly forces Tactical & Technical Software Data Displays & Controls General Processing Mass Memory Sensor/Actuator Interface Servo Amplifier Fail to define baseline data - Results in weapon firing into friendly forces (dependent on modes and states of the weapon system) Fail to protect self from friendly forces Fire projectile into friendly forces Tactical & Technical Software Data Display & Controls General Processing Mass Memory Sensor/Actuator Interface Servo Amplifier Sensors & Peripherals Tactical & Technical Software 1. Engagement Control A. Check-Fire; Manual B. Cease-Fire; Automatic Safety Significance Fail to break engagement of an incorrectly designated target; Fire projectile into friendly Forces if incorrectly identified friendly target as hostile Safety-Critical Function 2. Mode Control A. Tactical: move, shoot, resupply B. Support: training, test, & maintenance Inadvertent weapon firing Safety-Critical Function 3. Initialization, Re-Initialization 4. Re-Configuration Safety-Critical Function 5. Transmit Friend Signal To Friendly Forces 6. Target Integrity Improper actions leading to designation of incorrect target. Fail to accomplish offensive or defensive operation. Fail to protect self or friendly forces Tactical & Technical Software Data Displays & Controls Safety-Critical Function 7. Receive, Verify, & Process Battlefield InformationExample 2. Determine Ramifications of Function Failure 2. Determine Ramifications of Function Failure 3. Determine Subsystems Impacted 3. Determine Subsystems Impacted 4. Determine Safety Significance 1. Define System Function

19. 4-15-99 19 2. Define Primary Capabilities of the System State 2. Define Primary Capabilities of the System State 3. Identify Prohibited Functions of the System State 3. Identify Prohibited Functions of the System State 4. Identify Essential Functions of the System State 1. Define System States and Substates Safe States & Modes Analysis SYSTEM STATE PRIMARY CAPABILITIES PROHIBITED FUNCTIONS 1. Unpowered State 2. Maintenance State 3. Test State 4. Training State 5. Tactical State Weapon System Is Shut Down and Powered off Perform Intrusive Fault Protection and Isolation. Perform Servicing, Repair, And LRU Replacement Actions, Etc Test WCS software and hardware end-to-end using synthetic training targets and Operational Software Perform WCS Operator Training using Simulated Environments Using Training Software. No Live-fire, Simulated Target Weapon System Active for Live-fire System Operation of any kind Weapon Control System Test, Training, and Tactical Operation Tactical Links Installed Arm/Enable Switch On Tactical Links Installed Arm/Enable Switch On Training, Maintenance, and Test Modes ESSENTIAL FUNCTIONS Weapon System Physical Security Primary Power On Break-Engage Active Primary Power On Training Software Load Primary Power On Sim Software Loaded Fire Command Cleared Primary Power On Example

20. 4-15-99 20 LTE Controller Unit LCR LEELRELBE LSP Event Queue Processing Unit LCR Event Queue Processing Unit LCR Bearing/Jam Line Event Queue Processing LCR Sector Processing Unit LCR LGDLTP LME Get Data Unit LCR Processing Unit LCR Modification Event Processing LCR LNE LNWLRWLSD Track Not Eligible Unit LCR #1 Solution Processing Unit LCR #2 Solution Processing Unit LCR Save Data Unit LCR A 40 B 40 C 40 Functional Analysis of Software Architecture Graphical Representation Graphical Representation for Each Hazard or Failure Mode Links Specific Software Links Specific Software Modules to Undesired Events Safety Implication/Effects Safety Implication/Effects Communicated to the Design/Domain Expert Example Analysis

21. 4-15-99 21 Do SILs Make Sense? Definition of Safety-Critical Functions Tailored Safety Requirements & Guidelines Identification of System/Subsystem Hazards & Failure Modes Determination of System-Level Effects Categorization of Hazard Severity & Likelihood Identification of Hazard Causes (HW/SW/Human Interaction) Derivation of Functional Hazard Mitigation Requirements Determination of Safety Requirements Implementation Determination of Residual Safety Risk Final Categorization Hazard of Severity & Likelihood Elements of System Safety

22. 4-15-99 22 The Role of SILs Forces the Functional Linking of Software Architecture to Undesired Events or Hazards of the System Forces Cause Analysis to be Accomplished to Prove Software Influences or Causes the Hazard to Initiate Forces the Software Development Team to Interact with the Safety Team Forces a Defined Protocol of Software Development Activity in the Design, Code, Test, V&V, and Configuration Management for each of the SIL Categories

23. 4-15-99 23 Issues To Consider Solving Problems = High Visibility Preventing Problems = Low Visibility Size and Complexity of the Software Software Development Life Cycle, Tools/Techniques –Structured Design –Object Oriented Design Interfaces (Hardware, Software, Human) –Functionality of Interface –Ramification of Loss of Interface Role of Systems Engineering Requirements versus Recommendations/Considerations Budgets for Specialty Engineering