23
July 30, 2003 SAIC @ NASA Glenn Research Cent er 1 Programmable Logic Devices Building the Case for Software-style Assurance Kalynnda Berens [email protected]

Software Safety Assurance of Programmable Logic

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 1

Programmable Logic Devices

Building the Case for

Software-style Assurance

Kalynnda [email protected]

Page 2: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 2

What is Programmable Logic

• Programmable Logic Controllers (PLC)• Programmable Logic Devices

– Field Programmable Gate Array (FPGA)– Application Specific Integrated Circuit

(ASIC)– System-on-chip (SOC)– Complex PLD (CPLD)– others

Page 3: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 3

The Hardware/Software BoundarySoftware

BIOS/bootstrap

Operating system

Applications

Programmed

Easily changed

Can “do anything”

Cannot be 100%, exhaustively tested

Firmware

Software residing in non-volatile storage

Electronic Hardware

ICs

Microprocessor

A/D, D/A

Sensors

Off-the-shelf components

Exhaustively Tested by Vendor

Programmable Logic Controllers

Special purpose computer (process control)

Uses LadderLogic, other languages for programming

SOC Reconfig. Computing

Programmable Logic Devices

FPGA

CPLD

PAL

ASIC

Designed with HDL

Compiled/Programmed

May be reprogrammable in the field

Cannot be 100%, exhaustively tested

Page 4: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 4

Pushing the Limits• System-on-Chip (SOC)

– Combine microprocessor/input/output, often FPGA for programmability

• Reconfigurable Computing– Morphware, Configware, Flowware– In NASA Strategic Technology Plan

• FPGAs– 30,000 to over a million gates– Complex interactions

Page 5: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 5

Complexity

• Types of faults– Incomplete specifications– Design and Implementation Errors

(Common mode)– Unexpected or unanticipated combinations

of valid operating states. – Unintended interactions– Unknown defects in tools (design or

verification)

Page 6: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 6

Hardware/Software Differences

• Most PL cannot be changed once “burned” (programmed). FPGAs can be programmed on-the-fly.

• Software execution is serial – one instruction after another

• PL execution is parallel – multiple simultaneous signals and processes

• PL designed, verified, tested by engineers

Page 7: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 7

Assurance: Product and Process

Activity Product Process Eng. QARequirements Specification X X RDesign Documentation X X RRequirements, Design Analyses

X X

Inspections, Walkthroughs X X X

Simulation X X W

Testing X X W

Planning (Risk, Management, Development, QA)

X X X

Configuration Management X X X

Audits X X

Page 8: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 8

Current PL Process• Design from system requirements• Functional Simulation

– Includes “corner cases”

• Testing (unit and system)– Simulation and unit test usually performed by

design engineer

• May perform code coverage measurement

• Verification takes 70% of design task

Page 9: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 9

NASA PL Assurance Activities – from the user’s point of view

Yes No

Review source 15 31

Witness Programming 9 38

Witness Testing 16 31

Verify Version 12 34

Audit development 11 34

Audit CM 16 32

Page 10: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 10

NASA PL Assurance Activities – from QA’s point of view

Project SA Other QA Other None

PL Testing 9 1 11

Test Witness 6 2 3 22

Code Review 5 1 2 11 2

Witness Burn 6 1 3 11 3

CM Audit 1 4 1 5

Devel. Audit 2 3 5

FCA 2 3 5

PCA 1 3 1 5

VDD 2 2 1 6

Safety Verif. 8 4 4 32

1 Vendor or contractor 2 Safety personnel

Page 11: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 11

What are others doing?

• Hardware/software co-verification• Industry/Military practices still open issue –

tough nut to crack• ESA – starting to address FPGA/ASIC

through reports and guidance• FAA – DO-254 for Complex Electronic

Hardware, calls for design process assurance

Page 12: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 12

PL-related Standards and Guidelines

• IEC-61508 - “Functional Safety of Electrical/Electronic/ Programmable Electronic Safety-related Systems”

• DO-254 – “Design Assurance Guidelines for Airborne Electronic Hardware”

• IEC-1131-3 – “PLC Programming Languages”• IEC-61511 – “Functional Safety - Safety Instrumented

Systems For The Process Industry Sector”• IEE SEMSPLC – “Software Engineering Methods for

Safe Programmable Logic Controllers”

Page 13: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 13

PL-related Standards and Guidelines (continued)

• European Space Agency– Space Product Assurance – ASIC Development– VHDL Modeling Guidelines– FPGA report

• EWICS TC7 Guidelines for the use of Programmable Logic Controllers in Safety-related Systems

Page 14: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 14

FAA and DO-254• Complex Electronic Hardware includes FPGA, CPLD,

and ASIC• DO-254 required for Levels A and B (highest criticality)• Defines Hardware Life-Cycle Processes:

– Planning Process– Hardware Design Processes

• Requirements, Design, Implementation, Production, Test

– Validation Process– Verification Process– Configuration Management Process– Process Assurance– Certification Liaison Process

Page 15: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 15

DO-254 at Langley

• Case study on applying DO-254 to SPIDER1

• Implemented process assurance – monitoring the development activities to

assure they are in accordance to plans

• Placed conceptual design in CM

• Used Formal Methods

1 Scalable Processor-Independent Design for Electromagnetic Resilience

Page 16: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 16

FPGA Lessons LearnedEuropean Space Agency, 2002

• Reviewed FPGA’s in ESA/NASA missions– Extensive use in critical systems with little thought to

SEU– Design and verification by same individual– Insufficient verification due to inadequate stimuli

selection– Test only – simulation often skipped– Non-engineers “blessing” design

• FPGA’s are “the software of the hardware world”– Encourage engineers to quickly get to hardware test,

ignoring good design practice

Page 17: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 17

Safety-Related Complex Electronic Systems, 2000

• Simulation alone is not adequate. Exhaustive list of possible failures not possible.– Strengthen system/subsystem tests– Consider origin of faults

• Errors of specification, design, production• Internal faults• External faults

• Quality of vendor-supplied soft core or macro libraries is not guaranteed

• Synthesis tools can generate faults• High fault coverage in test is mandatory

Page 18: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 18

What do we know?

• PLCs use software, just the purpose and language differ

• FPGAs and other Programmable Logic devices are very complex

• Process assurance provides additional value in conjunction with product assurance

• Process assurance currently not applied to most PLD development

Page 19: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 19

What don’t we know?

• Industry and Military QA Best Practices• What level of process assurance is required• Who should do QA on programmable logic

– Hardware QA• More likely to understand PL or quickly learn

• Need to learn process assurance activities

– Software QA• Familiar with process assurance

• Would need to learn PL hardware and language

• How to integrate process assurance in NASA – Software CMM implementation may provide guide

Page 20: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 20

Software->Hardware Assurance• Inspection of HDL code and schematics

– Validated as low-cost, high-probability of catching errors for hardware

• Walkthroughs

• Independent test team

• Formal Methods

• Complexity measurements

• Traceability

• Change impact analysis

• CM tools and processes

• Functional, code coverage analysis

• QA monitoring of development process

Page 21: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 21

Hardware->Software Assurance

• Simulation, test beds are standard operating procedure

• Testing against boundary conditions (“corner cases”)

• Wide variety of available tools for verification

Page 22: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 22

Next steps

• 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– Issue Paper on this topic– Process Assurance guidance for Hw QA– PL/Hardware guidance for Sw QA

Page 23: Software Safety Assurance of Programmable Logic

July 30, 2003 SAIC @ NASA Glenn Research Center 23

Please Take the Survey!

http://osat-ext.grc.nasa.gov/rmo/plcsurvey

If you have industry/military QA or engineering contacts, please email me at:

[email protected]