Believe it or not, Software Assurance Affects You Too

1. Believe it or not, Software Assurance Affects You Too Martha S. Wetherholt NASA Office of Safety & Mission Assurance mwetherh@hq.nasa.gov

2. What is Software Assurance Software Assurance (SA) includes: • Software Quality Engineering • Software Assurance of Product and Processes • Software Safety • Software Independent Verification & Validation (IV&V) • Software Reliability It is, Software Risk Management

3. What Makes Software, Safety Critical? Software that directly or indirectly contributes to the occurrence of a hazardous system state

4. What Makes Software Hazardous? Software is hazardous if it: • Controls hazardous or safety critical hardware • Monitors safety critical hardware as part of a hazard control • Provides information upon which a safety-related decision is made • Performs analysis that impacts automatic or manual hazardous operations • Verifies hardware hazard controls • Is used to verify safety critical hardware and/or software • Is used to model or simulate safety critical applications

5. Software Safety - Why care? • One or more people are injured or worse • Regulatory requirements (e.g. OSHA, UL, etc.) • NASA requirements • Liability if software fails • Reputation (business or personal) • “Good practice” for mission critical or business critical software

6. Why Should We Care, What does it have to do with me? • Software control of facilities • Wind tunnels • Simulators • Centrifuges • Shake & Bake • EMI testing • Engine Checkout • Etc. • Software control and monitoring of safety critical projects which run in changeable labs • Labs/Tools • Vibe tables ……..

7. What should be done • Train Area Safety Managers/Health and Safety Personnel • Invite Software Assurance along on Facility set up and changes • Ask the right Questions • How is this experiment/facility controlled • How is it monitored • What is the human interface • Does software detect and react to safety critical situations • How – what is it expected to do • What testing was performed on the Consumer Off the Shelf (COTS) Software Purchased to operate the Facility/Experiment • What software development processes are to be used to develop the software – including Application SW • How are the COTS and Applications written Configuration Managed • Does the Software perform a logging function to track faults, failures, errors, etc. How often is it viewed? By who?

8. Creating Safer Software & Safer Systems • Good SW Development Process • Development Tools • Appropriate Reviews • Diverse Review Teams • Formal Inspections • Communication • Appropriate Analysis, both Safety & Development • Caveat Emptor

9. Safety Verification Testing • Safety tests designated for each hazard control. • Verify partitions, firewalls, or other software constructs that isolate safety critical code. • “Fail” the hazard controls in a multi-tolerant system. For example, in a two-fault-tolerant system (three controls), try all combinations of two failures. • Verify hazardous commands. • Verify software correctly handles out of sequence commands, hazardous commands issued in an incorrect state, and other possible errors. • Software Safety (usually SQA) should witness all software safety testing.

10. When COTS Software Is UsedSOUP (SW of Uncertain Parentage) • Is this a case of Reuse? • Previous environmental criteria may or may not be valid in the new system. • Must test COTS for ways it can fail. STAND-ALONE • Must test for how system faults/failures affect the COTS and the applications they run on. • How does your application software respond to those failures – how does it effect the system, humans, etc.? • What of unused portions/features of COTS software? Can they influence the safety critical operations & monitoring. • Stand-alone testing of all functionality prior to integration in lab or facility. • How much Glue-ware and/or wrappers.

11. What are we asking you to do? • Be AWARE • Know what to look for • What Questions to ask • What are you buying • Be Proactive • Put Software into Assessment process & plan • Train your people • Document safety requirements then Test for them • Work with SW Assurance

12. Background/Extras

13. What Software is included • Software • Firmware • Programmable Logic Devices • ASICs - Application Specific Integrated Circuits • FPGAs - Field Programmable Gate Arrays • COTS Software • Program Logic Control • Databases • Operating Systems • Ad infinitum

14. Categories of S/W Safety Functions • Caution And Warning Functions • Failure Detection, Isolation, and R--------- • Recovery • Restart • Reduced operation • Automatic safing software • Hot, Warm, Cold Backup • Autonomous Decision Making & Operation

15. Safety critical software is: • Software which controls or monitors safety critical functions including mitigation of hazards • Software which runs on the same system as safety critical software or impacts systems which run safety critical software • Software which handles safety critical data • Software used to verify and validate safety critical hardware and software

16. Categories of S/W Safety Functions • Must work/must not work functions • Mode and State Dependent • Must never work • Must never fail to work • Fault tolerance • Redundancy • How many levels and where are they best put • Multiple Commanding (Ready, Arm, Fire)

17. Stability/Reliability Testing • How well does the system operate for extended periods of time? • System is run in normal mode of operation - occasional peak performance allowed, but not stress testing the system. • Can the system handle intermittent bad data? • Is there a sensitivity to event sequences? • Does memory leakage cause problems after a period of time?

18. Summary • Determine software control and complexity • Determine each software portions’ contribution to safety • Establish categories with a cross index to hazard level • Determine a level of effort needed to assure safer software • Further tailor the effort to your particular needs and situation