Software Safety Assurance of Programmable Logic


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Safety Assurance of Programmable Logic

  1. 1. Programmable Logic Devices Building the Case for Software-style Assurance Kalynnda Berens [email_address]
  2. 2. What is Programmable Logic <ul><li>Programmable Logic Controllers (PLC) </li></ul><ul><li>Programmable Logic Devices </li></ul><ul><ul><li>Field Programmable Gate Array (FPGA) </li></ul></ul><ul><ul><li>Application Specific Integrated Circuit (ASIC) </li></ul></ul><ul><ul><li>System-on-chip (SOC) </li></ul></ul><ul><ul><li>Complex PLD (CPLD) </li></ul></ul><ul><ul><li>others </li></ul></ul>
  3. 3. The Hardware/Software Boundary SOC Reconfig. Computing Programmed Easily changed Can “do anything” Cannot be 100%, exhaustively tested BIOS/bootstrap Operating system Applications Software Software residing in non-volatile storage Firmware Off-the-shelf components Exhaustively Tested by Vendor ICs Microprocessor A/D, D/A Sensors Electronic Hardware Special purpose computer (process control) Uses LadderLogic, other languages for programming Programmable Logic Controllers Designed with HDL Compiled/Programmed May be reprogrammable in the field Cannot be 100%, exhaustively tested FPGA CPLD PAL ASIC Programmable Logic Devices
  4. 4. Pushing the Limits <ul><li>System-on-Chip (SOC) </li></ul><ul><ul><li>Combine microprocessor/input/output, often FPGA for programmability </li></ul></ul><ul><li>Reconfigurable Computing </li></ul><ul><ul><li>Morphware, Configware, Flowware </li></ul></ul><ul><ul><li>In NASA Strategic Technology Plan </li></ul></ul><ul><li>FPGAs </li></ul><ul><ul><li>30,000 to over a million gates </li></ul></ul><ul><ul><li>Complex interactions </li></ul></ul>
  5. 5. Complexity <ul><li>Types of faults </li></ul><ul><ul><li>Incomplete specifications </li></ul></ul><ul><ul><li>Design and Implementation Errors (Common mode) </li></ul></ul><ul><ul><li>Unexpected or unanticipated combinations of valid operating states. </li></ul></ul><ul><ul><li>Unintended interactions </li></ul></ul><ul><ul><li>Unknown defects in tools (design or verification) </li></ul></ul>
  6. 6. Hardware/Software Differences <ul><li>Most PL cannot be changed once “burned” (programmed). FPGAs can be programmed on-the-fly. </li></ul><ul><li>Software execution is serial – one instruction after another </li></ul><ul><li>PL execution is parallel – multiple simultaneous signals and processes </li></ul><ul><li>PL designed, verified, tested by engineers </li></ul>
  7. 7. Assurance: Product and Process X X X X X X X Eng. X X Audits X X Configuration Management X X Planning (Risk, Management, Development, QA) W X Testing W X Simulation X X Inspections, Walkthroughs X X Requirements, Design Analyses R X Design Documentation R X Requirements Specification QA Process Product Activity
  8. 8. Current PL Process <ul><li>Design from system requirements </li></ul><ul><li>Functional Simulation </li></ul><ul><ul><li>Includes “corner cases” </li></ul></ul><ul><li>Testing (unit and system) </li></ul><ul><ul><li>Simulation and unit test usually performed by design engineer </li></ul></ul><ul><li>May perform code coverage measurement </li></ul><ul><li>Verification takes 70% of design task </li></ul>
  9. 9. NASA PL Assurance Activities – from the user’s point of view 32 16 Audit CM 34 11 Audit development 34 12 Verify Version 31 16 Witness Testing 38 9 Witness Programming 31 15 Review source No Yes
  10. 10. NASA PL Assurance Activities – from QA’s point of view 1 Vendor or contractor 2 Safety personnel 3 2 1 1 1 1 2 2 1 1 Other 4 4 8 Safety Verif. 6 1 2 2 VDD 5 1 3 1 PCA 5 3 2 FCA 5 3 2 Devel. Audit 5 1 4 1 CM Audit 3 3 1 6 Witness Burn 2 2 1 5 Code Review 3 2 6 Test Witness 1 9 PL Testing None Other QA SA Project
  11. 11. What are others doing? <ul><li>Hardware/software co-verification </li></ul><ul><li>Industry/Military practices still open issue – tough nut to crack </li></ul><ul><li>ESA – starting to address FPGA/ASIC through reports and guidance </li></ul><ul><li>FAA – DO-254 for Complex Electronic Hardware, calls for design process assurance </li></ul>
  12. 12. PL-related Standards and Guidelines <ul><li>IEC-61508 - “Functional Safety of Electrical/Electronic/ Programmable Electronic Safety-related Systems” </li></ul><ul><li>DO-254 – “Design Assurance Guidelines for Airborne Electronic Hardware” </li></ul><ul><li>IEC-1131-3 – “PLC Programming Languages” </li></ul><ul><li>IEC-61511 – “ Functional Safety - Safety Instrumented Systems For The Process Industry Sector ” </li></ul><ul><li>IEE SEMSPLC – “ Software Engineering Methods for Safe Programmable Logic Controllers ” </li></ul>
  13. 13. PL-related Standards and Guidelines (continued) <ul><li>European Space Agency </li></ul><ul><ul><li>Space Product Assurance – ASIC Development </li></ul></ul><ul><ul><li>VHDL Modeling Guidelines </li></ul></ul><ul><ul><li>FPGA report </li></ul></ul><ul><li>EWICS TC7 Guidelines for the use of Programmable Logic Controllers in Safety-related Systems </li></ul>
  14. 14. FAA and DO-254 <ul><li>Complex Electronic Hardware includes FPGA, CPLD, and ASIC </li></ul><ul><li>DO-254 required for Levels A and B (highest criticality) </li></ul><ul><li>Defines Hardware Life-Cycle Processes: </li></ul><ul><ul><li>Planning Process </li></ul></ul><ul><ul><li>Hardware Design Processes </li></ul></ul><ul><ul><ul><li>Requirements, Design, Implementation, Production, Test </li></ul></ul></ul><ul><ul><li>Validation Process </li></ul></ul><ul><ul><li>Verification Process </li></ul></ul><ul><ul><li>Configuration Management Process </li></ul></ul><ul><ul><li>Process Assurance </li></ul></ul><ul><ul><li>Certification Liaison Process </li></ul></ul>
  15. 15. DO-254 at Langley <ul><li>Case study on applying DO-254 to SPIDER 1 </li></ul><ul><li>Implemented process assurance </li></ul><ul><ul><li>monitoring the development activities to assure they are in accordance to plans </li></ul></ul><ul><li>Placed conceptual design in CM </li></ul><ul><li>Used Formal Methods </li></ul>1 Scalable Processor-Independent Design for Electromagnetic Resilience
  16. 16. FPGA Lessons Learned European Space Agency, 2002 <ul><li>Reviewed FPGA’s in ESA/NASA missions </li></ul><ul><ul><li>Extensive use in critical systems with little thought to SEU </li></ul></ul><ul><ul><li>Design and verification by same individual </li></ul></ul><ul><ul><li>Insufficient verification due to inadequate stimuli selection </li></ul></ul><ul><ul><li>Test only – simulation often skipped </li></ul></ul><ul><ul><li>Non-engineers “blessing” design </li></ul></ul><ul><li>FPGA’s are “the software of the hardware world” </li></ul><ul><ul><li>Encourage engineers to quickly get to hardware test, ignoring good design practice </li></ul></ul>
  17. 17. Safety-Related Complex Electronic Systems, 2000 <ul><li>Simulation alone is not adequate. Exhaustive list of possible failures not possible. </li></ul><ul><ul><li>Strengthen system/subsystem tests </li></ul></ul><ul><ul><li>Consider origin of faults </li></ul></ul><ul><ul><ul><li>Errors of specification, design, production </li></ul></ul></ul><ul><ul><ul><li>Internal faults </li></ul></ul></ul><ul><ul><ul><li>External faults </li></ul></ul></ul><ul><li>Quality of vendor-supplied soft core or macro libraries is not guaranteed </li></ul><ul><li>Synthesis tools can generate faults </li></ul><ul><li>High fault coverage in test is mandatory </li></ul>
  18. 18. What do we know? <ul><li>PLCs use software, just the purpose and language differ </li></ul><ul><li>FPGAs and other Programmable Logic devices are very complex </li></ul><ul><li>Process assurance provides additional value in conjunction with product assurance </li></ul><ul><li>Process assurance currently not applied to most PLD development </li></ul>
  19. 19. What don’t we know? <ul><li>Industry and Military QA Best Practices </li></ul><ul><li>What level of process assurance is required </li></ul><ul><li>Who should do QA on programmable logic </li></ul><ul><ul><li>Hardware QA </li></ul></ul><ul><ul><ul><li>More likely to understand PL or quickly learn </li></ul></ul></ul><ul><ul><ul><li>Need to learn process assurance activities </li></ul></ul></ul><ul><ul><li>Software QA </li></ul></ul><ul><ul><ul><li>Familiar with process assurance </li></ul></ul></ul><ul><ul><ul><li>Would need to learn PL hardware and language </li></ul></ul></ul><ul><li>How to integrate process assurance in NASA </li></ul><ul><ul><li>Software CMM implementation may provide guide </li></ul></ul>
  20. 20. Software->Hardware Assurance <ul><li>Inspection of HDL code and schematics </li></ul><ul><ul><li>Validated as low-cost, high-probability of catching errors for hardware </li></ul></ul><ul><li>Walkthroughs </li></ul><ul><li>Independent test team </li></ul><ul><li>Formal Methods </li></ul><ul><li>Complexity measurements </li></ul><ul><li>Traceability </li></ul><ul><li>Change impact analysis </li></ul><ul><li>CM tools and processes </li></ul><ul><li>Functional, code coverage analysis </li></ul><ul><li>QA monitoring of development process </li></ul>
  21. 21. Hardware->Software Assurance <ul><li>Simulation, test beds are standard operating procedure </li></ul><ul><li>Testing against boundary conditions (“corner cases”) </li></ul><ul><li>Wide variety of available tools for verification </li></ul>
  22. 22. Next steps <ul><li>Goal is not to provide the answers to how PL is assured, but to set the parameters for constructive discussion within NASA and provide a common information base </li></ul><ul><ul><li>Issue Paper on this topic </li></ul></ul><ul><ul><li>Process Assurance guidance for Hw QA </li></ul></ul><ul><ul><li>PL/Hardware guidance for Sw QA </li></ul></ul>
  23. 23. Please Take the Survey! <ul><li> </li></ul><ul><li>If you have industry/military QA or engineering contacts, please email me at: </li></ul><ul><li>[email_address] </li></ul>