Remote Controlled & Recoverable Munitions Safety Architecture Development

1. Remote Controlled & Recoverable Munitions Safety Architecture Development 23rd ISSC/NWSSS ConferenceC. Forni, B. Blake – 08-23-2005

2. Remote Controlled & Recoverable Munitions Architecture Design Drivers • Off-On-Off operation drives the design • For munitions systems, reliably arming, then disarming is a new concept • After a return to safe, it is necessary for the munitions to monitor and report the safety status to the remote controller • Off-On-Off System must support safe operation even when there has been a loss of control functionality. This is necessary whether or not that control is physically separate from the source of hazard

3. Remote Controlled & Recoverable Munitions Architecture Design Drivers (Continued) • For remote controlled systems, safety can’t be allocated to a single isolated component (fuze). Safety critical command and control functions are distributed throughout the system • To address in an efficient and cost effective manner, safety must be involved throughout the concept and early development phase • The following hazardous conditions must be addressed across the distributed control components: • Inadvertent hazardous functions • Unintentional hazardous functions • Failure to return to a non-hazardous state when commanded • Erroneous safety data

4. Remote Controlled & Recoverable Munitions Safety Activities and Development Process • Safety activities needed during the Concept and Early Development Phases • Criticality Assessment • Hazards and Causal Factor Identification • Mitigation Development • Safety activities performed iteratively during both system and subsystem development • Safety activities instrumental in shaping both the architecture of the system and the final criticality of the subsystems

5. Remote Controlled & Recoverable Munitions Safety Activities within the Development Process

6. Remote Controlled & Recoverable Munitions Physical vs Functional Components (Example System) • Functional Components • Remote Control (RC) Subsystem • Communications Subsystem • Munitions Controller (MC) Subsystem • Physical Components • Remote Control Device • Comm relay device (optional) • Munitions

7. Remote Controlled & Recoverable Munitions Architecture Development • Architecture Development Process steps •   Identify any desired system or functional level criticality • Develop the system behavior model (state charts and transition rules) • Identify potential hazards and causal factors • Identity functions and determine their safety criticality • Define / Refine safety architecture • Define mitigations for identified hazards and causal factors • Shape criticality by partitioning and/or mitigation application • Create requirements that implement the needed mitigations • Iterate

8. Remote Controlled & Recoverable Munitions Behavior Modeling • A Concept of Operation (CONOPS) forms the basis for modeling operation of the system •   Defines the interactions between personnel and the system • Provides the context and boundaries for possible hazards situations • Safety involvement in “behavior modeling” is paramount to design safety into the system •   Each model variation must be examined, and sources of hazard and causal factors identified • Must be of sufficient detail to define the major architectural features of the system • Possible mitigations are examined for adequacy • Each component and interface provides an additional source for hazards or their causal factors • Modification of CONOPS and/or behavior models may provide a means for effective and efficient mitigations

9. Remote Controlled & Recoverable Munitions Criticality Analysis • Analysis of criticality serves two purposes •   Identifying safety critical functions • Determining the level of analysis and testing to ensure the design is safe to use • Criticality analysis at the functional level gives insight into what is safety critical and why •   Helps concentrate critical operations to minimize hazard sources • Helps distribute mitigations so loss of a single mitigation merely degrades safety • Aids in examination of adequacy of possible mitigations • Similar techniques allow shaping of functional criticality to meet specific design constraints • To concentrate safety critical functionality into a single processor • To minimize interactions with non-safety critical components • partition functions to minimize analysis or test activity

10. Remote Controlled & Recoverable MunitionsSources of Hazard and Causal Factors - Communications Subsystem • Possible hazards related to application message faults • Corrupted Message data elements during the transfer of a message could result in incorrect safety critical time values, incorrect safety status info, or other erroneous data items • Corruption of an application Message could also result in a message being incorrectly interpreted as a different message, resulting in unexpected behavior • Possible hazards related to delivery fault mechanisms • Message might not be delivered • Message could be delivered to an incorrect address • If multiple message sources are possible, the source identity could be incorrect • The Delivery Mechanism could generate an erroneous message • The Delivery Mechanism could generate a corrupt non-application message • Networking or Prioritization schemes could allow the delivery of messages to occur out of order

11. Remote Controlled & Recoverable MunitionsSources of Hazard and Causal Factors - Remote Controller • Erroneous command generation • Corrupted message data elements during message generation result in incorrect safety critical values, authorizations, message interpretation, etc. • Unintended or erroneous generation of a valid application message (OS, Operator) • Erroneous transmission of a valid message (out of order, stale, etc) • False Report of Safe to Operator • Display/Processor Hardware and firmware (including memory) • Operating System (could affect data, application execution, etc) • Application SW • Received Data • Operator Inputs

12. Remote Controlled & Recoverable MunitionsSources of Hazard and Causal Factors - Munitions Controller • Unintended Detonation (arm and fire warhead) • Hardware and firmware (including memory) • Application SW • Received Data (including messages from Remote Controller, Comm subsystem) • Operator actions or input • False Report of Safe to Operator • Incorrect safe indication on munition • Hardware/Firmware • SW • Incorrect safe indication reported to Remote Controller • Hardware/Firmware (memory) • SW (bad message data, erroneously generated message)

13. Remote Controlled & Recoverable Munitions Hazard Mitigation Approach • Designing to prevent single point failures from propagating hazards is not adequate • Utilize layered mitigation approach that places mitigation in at least two places in the system • First at the hazard source (munition HW and SW that controls arm/disarm) • Second at source of casual factors (HW failure or SW errors) that had potential to propagate the hazard • At least one mitigation should reside in a hardware element if possible • If no HW mitigation possible, additional mitigation is necessary to reduce the safety criticality of the software element providing the mitigation • Layered mitigations developed for each identified hazard case in the PHA

14. Remote Controlled & Recoverable Munitions Example PHA Hazard Cases requiring Mitigation • Mitigations are necessary for the following issues • The loss of the command channel must not directly result in a hazard • Must address the case of unintended arming and firing • Must address legal commands arriving at the wrong time • Must ensure the munitions can be disarmed (< 1E-6 probability of remaining armed) • Must ensure hazardous command activity was intended (mitigation may require operator confirmation) • Must ensure operator not given false safe indication

15. Remote Controlled & Recoverable Munitions Hazard Mitigation Approach – Communications Subsystem • Communications subsystem designed as a Pipe • Virtual direct connect of RC and MCs • Corrupt application messages that result in incorrect data or an incorrect message are detectable • Application generated 32-bit CRC in message data (separate from packet CRC) • Message ID is duplicated within all Safety-Critical messages • All safety critical data is duplicated with-in Safety-Critical messages • Erroneous messages received due to delivery mechanism faults are detectable (delivered to wrong address, out of order, etc) • Header Information (source, destination, seq #) included in 32-bit CRC • Sequence # can be used to detect out of order (stale) messages • Commands resulting in hazardous actions are self terminating (Loss of communications won’t cause hazard)

16. Remote Controlled & Recoverable Munitions Hazard Mitigation Approach – Remote Controller • Erroneous invocation of the message generation function • Messages generated at each invocation (not canned) • Keys used to verify message is valid for current state/operator/confirmation status (prevents erroneous invocation by a random entry) • Operator must confirm intent to initiate hazardous operations (affects key value) • False display of safe by the RC • Duplicate safety-critical data elements • Broadcast Commands utilized for state control • All displayed munition icons marked as in transition (hazardous) when command is sent. Only updated to valid status when positive confirmation received • Munition Icons drawn (not canned) and are redrawn when data is received or periodically if no other activity is occurring (complete screen redraw) • Multiple independent screen indications for safety status indication of MCs and field (shape, color, text)

17. Remote Controlled & Recoverable Munitions Hazard Mitigation Approach – Munitions Controller • IM Explosives used in warhead, and LEEFI detonator • ESAD architecture (mp generated dynamic signal ) • State machine-based processing allows hazardous action only where authorized • Hazardous operation all self terminating (if not command terminated earlier) • Monitors Safety Critical Signals for validity • Controls both power and MC static switch control signals to the Fireset • Hardware Safety Monitor designed to act as a safety cop • Acts as a watchdog for all Safety Critical timers in the microcontroller • Validates state transitions performed by the microcontroller • Still alive monitoring allows detection of failed microcontroller • Controls SM static switch signals to the Fireset (both MC and SM needed to arm) • Either the microcontroller or Safety monitor can render the munition inoperative • Independent monitor of Safety Critical signals.