Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software Safety Assurance of Programmable Logic

1,112 views

Published on

  • Be the first to comment

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>http://osat-ext.grc.nasa.gov/rmo/plcsurvey </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>

×