Remote controlled recoverable munitions safety architecture development
Sponsored Links
This presentation is the property of its rightful owner.
1 / 17

Remote Controlled & Recoverable Munitions Safety Architecture Development PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Remote Controlled & Recoverable Munitions Safety Architecture Development. 23 rd ISSC/NWSSS Conference C. Forni , B. Blake – 08-23-2005. Remote Controlled & Recoverable Munitions Architecture Design Drivers. Off-On-Off operation drives the design

Download Presentation

Remote Controlled & Recoverable Munitions Safety Architecture Development

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Remote Controlled & Recoverable Munitions Safety Architecture Development

23rd ISSC/NWSSS ConferenceC. Forni, B. Blake – 08-23-2005

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

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

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

Remote Controlled & Recoverable Munitions

Safety Activities within the Development Process

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

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

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

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

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

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

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)

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

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

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)

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)

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.

  • Login