FPGABased Control for SafetyRelated Applications

1
FPGA-Based Controlfor Safety-Related Applications
Richard A. Cobley Lockheed Martin
Corporation Systems Engineer, Senior Staff
2
Introduction

• This presentation discusses FPGA-based controls
  in high-consequence applications
• The approach herein is presented as an effective
  method of addressing the inherent complexities of
  modern digital systems and the safety-related
  nature of such applications

3
High-Consequence Applications
Electronics in High-Consequence Aerospace
Defense Applications
4
Background

• Technology Refresh of the Guidance Control
  Electronics
• Objectives
• Overcome component obsolescence
• Improve performance
• Reduce cost
• Improve reliability
• Maintain or enhance safety
• Solution
• FPGA-based Processing Platform
• A single Computer Software Configuration Item
  (CSCI)
• CSCI is embedded within the system hardware
• CSCI host device is an FPGA
• Very High Speed Integrated Circuit Hardware
  Description Language (VHDL)

5
Software Safety Aspects

• Software Safety is a Subset of System Safety
• System Safety Guidelines
• MIL-STD 882, System Safety Program Requirements
• Weapons System Safety Guidelines Handbook
• Joint Software System Safety Handbook
• Navy Software Safety Certification Process
• Safety Review Authority
• U.S. Navy
• Weapon System Explosives Safety Review Board
  (WSESRB)
• Software System Safety Technical Review Panel
  (SSSTRP)
• Provides an independent technical safety
  evaluation

Firmware Software
6
Software Safety Certification Process
SSSTRP Software Safety Certification Process1
7
Software Safety Certification Process

• What the Process Will Do for You
• Guide your program in implementing a viable
  software safety program
• Identify possible deficiencies in your current
  software safety program
• Put your program in the best position for
  concurrence by your Risk Authority (e.g., WSESRB)
  through the application of a standardized process
  understood by that Risk Authority
• What the Process Wont Do for You
• This process is not a cure-all talented System
  / Software Safety Engineers and Safety Program
  Managers are needed to execute the process

SSSTRP Software Safety Certification Process1
8
Level of Rigor Determination
Software Criticality Matrix
SSSTRP Software Safety Certification Process1
9
Software Safety Categories

• Safety-Critical
• Serves as an autonomous control of a safety
  critical function, which, if performed
  incorrectly or not performed, may result in a
  catastrophic or critical mishap
• Safety-Related
• Influences safety critical functions but failure
  will not result in a hazardous condition in the
  safety critical function

10
Safety Illustration

• The hazard risk probability of the system
  striking the aircraft during jettison as a result
  of a failure shall be very low.

Safe Jettison is the System Safety-critical
Function
11
Hazard Analysis Approach

• Identifies potentially hazardous conditions
  associated with the design, support and operation
  of the system
• Provides a formal assessment of the identified
  hazards
• Identifies requisite hazard controls and tracks
  follow-on actions to closure
• Fault Tree Analysis
• System Hazard Analysis
• Sub-System Hazard Analysis
• Software Safety Hazard Analysis
• Operating Support Hazard Analysis

Structured Engineering Analysis Achieves Safety
Requirements
12
Hazard Controls

• Derived Safety Requirement
• The system shall not command aerodynamic
  maneuvers for a minimum time after release
• Hazard Control Strategy
• Simplicity
• Mitigate the hazard risk via hardware
• Implement the safety-critical function in
  hardware
• Avoid safety-critical firmware
• Hardware Design Features
• No single-point failure will render the system
  unsafe
• Implement system and sub-system level diverse
  functional interlocks
• Diverse inputs and diverse interlocked actuation
  mechanisms
• Hardware design rigor mitigates the firmware
  hazard risk

Avoid Safety-critical Firmware
13
Hazard Controls

• Firmware Design Features
• Flash-based technology
• instant on and immune to firm errors
• No operating system (embedded application)
• Statically defined functions (pre-configured and
  live at power-up)
• No dynamic memory allocation
• Calibration data stored externally on Non
  Volatile Memory (NVM) allows calibration without
  modifying FPGA configuration
• Global reset input tied to power monitor ensures
  safe operation during start up sequence or brown
  outs
• All safety-related outputs go through internal
  safety checks before exiting the FPGA
• Safety-related checks operate independent of and
  in parallel to other functions
• No single-point failure will render the system
  unsafe
• FPGA Firmware are treated as a Black Box
• Safety-related FPGA outputs are interlocked with
  a hardware permissive

14
Hazard Controls
Firmware / Hardware Interlock
Reset
Output 1
Output 1
Reset
FPGA Ready
Output 2
Output 2

• Power Sequencer feeds Hardware Interlock directly
  to block FPGA outputs until power is stable
• Power Sequencer feeds FPGA to guarantee reliable
  reset operation during power-up and brown outs
• Hardware Permissive feeds Hardware Interlock
  directly to block FPGA outputs until permitted
• Hardware Permissive feeds FPGA to hold off
  outputs while blocked by the Hardware Interlock

No Safety-critical Firmware Functions
15
System Qualification

• Design Verification Testing (DVT)
• Sub-system
• System
• Firmware Testing
• Firmware Simulation Testing of Safety-related
  Items
• Environmental Qualification Testing
• Acceptance testing after each environmental test
  verifies operation of safety-critical and
  safety-related functions
• Operational Qualification Testing
• Flight Testing

16
Design Verification Testing
Electrical Interfaces
Visualization Workstation
Mechanical Interfaces
Embedded Product
Simulation, Visualization, and
Interface Computers
Operator Workstations
Manual Controls
The embedded product in this example contains the
firmware component.
17
Firmware Documentation

• Firmware Development Plan (FDP)
• Safety involvement specified
• Firmware Requirements Specification (FRS)
• Safety-related requirements called out through
  use of FRS
• Verification methods specified
• Traceability included
• Design Requirement Specification (DRS)
• Detailed system design information
• Firmware Test Plan (FTP)
• Follows-up on verification requirements of FRS
• Traceability included
• Firmware Test Report (FTR)
• Per FTP
• Provided for Safety Engineer review

18
Conclusion

• A comprehensive and rigorous safety program
  combined with a disciplined system engineering
  approach yields a best value solution that
  achieves safety requirements.

INCOSE System Engineering Handbook, Systems
Engineering Process Overview2
19
References

• 1 Software Safety Certification, A Weapon System
  Explosives Safety Review Board (WSESRB) Approved
  Process (Naval Ordnance Safety Security
  Activity (NOSSA) presentation, Indian Head, MD,
  USA, 12 April 2004).
• 2 International Council on Systems Engineering
  (INCOSE) the Systems Engineering (SE) Handbook
  Working Group (SEH WG), System Engineering
  Handbook. July 2000.

20
CLEARED FOR PUBLIC RELEASE