"Case Studies in Software Safety: Accidents and Lessons Learned", Aug 2nd 2011, by Hardy at NASA GSFC

If you happen to be in the area of NASA Goddard Space Flight Center (GSFC) Building 3 Auditorium on August 2nd, 2011 stop in for the Systems Engineering Seminar on Software Safety. You must register at least four days in advance, see below. For those that can't make it will be available on-line sometime after the 2nd.

The Mission Engineering and Systems Analysis Division (MESAD) of the Applied Engineering and Advanced Technology Directorate(AETD), the Office of Human Capital Management, and the Innovative Partnerships Program (IPP) Office of NASA Goddard Space Flight Center (GSFC) are co-sponsoring a series of seminar presentations on Systems Engineering concepts, philosophies, principles, and practices.

NASA
Goddard Space Flight Center

Systems Engineering Seminar

Case Studies in Software Safety: Accidents and Lessons Learned

Presented by:

Terry Hardy, Director, Safety & Risk Management, Great Circle Analytics, LLC

August 2,
2011, 1:00 p.m.

Building 3 Auditorium

Abstract:

Case Studies in Software Safety: Accidents and Lessons Learned

The complexity of our systems is increasing, especially with the use of software and computing systems. System safety approaches are therefore necessary to help manage risk and prevent accidents in these complex systems. An essential element in preventing accidents in the future is learning from past failures. This lecture will present case studies from many different industries describing accidents and mishaps related to software and computing systems. Such case studies can help us identify what can go wrong in our own systems. The focus of the talk will be on software safety as part of a broader system safety effort, and lessons learned will be discussed related to the system safety process. Recommendations will be provided based on lessons learned from those accidents as well as personal experience.

Biography:

Terry Hardy leads efforts in system safety and software assurance at Great Circle Analytics. Mr. Hardy has over 25 years of experience and numerous publications in the areas of launch vehicles, space propulsion, cryogenics, software, safety analysis, and risk management. Prior to founding Great Circle Analytics, he led software safety and assurance efforts at Special Aerospace Services and at NASA Goddard Space Flight Center; responsibilities included membership on the Constellation Safety Engineering Review Panel. Mr. Hardy also was the Principal Engineer for Reliability in FAA’s Office of Commercial Space Transportation, leading efforts to develop safety, reliability, and risk management regulations, guidance documents, and training. Mr. Hardy holds a BS degree in chemical engineering, an MS degree in chemical engineering, and an MS degree in civil engineering. He also has been certified as a Reliability Engineer, Quality Engineer, and Software Quality Engineer through the American Society for
Quality.

The Fine Print:

• ***YOU MUST STOP AND SIGN IN AT THE MAIN GATE***
• ***BRING PHOTO IDENTIFICATION***
• ***ALL VISITOR CARS WILL BE INSPECTED BY GSFC SECURITY***
• Please allow 30 minutes for security check in.
• Please bring a photo identification.
• Badging for special situations may be at the Visitor Center Badging Trailer

The really important fine print:

Registration for a visitor badge:

• Employees and visitors with a Goddard badge need not register.
• Visitors without a GSFC badge must register for a visitor badge.
• To register, please send your Name, Citizenship, Organization, Phone, and Email at least FOUR days prior to seminar to: Lindsay Macleod, 301.286.6493, Lindsay.B.Macleod [At] nasa.gov
• The SE Seminar Committee is only able to process Visitor Registrations for US Citizens.

Always fully specify requirements; Software Quality Assurance. Why can't I turn off the headlights??

I had mentioned not long ago that I was shopping for a new car, due to my GM rusting, failing transmission and failing fuel pump. I ended up buying a used 2010 Toyota Corolla.

One of the things purchasing the vehicle did was to remind me of how important it is to always fully specify requirements for both hardware and software. You see, it simply never occurred to me to have on my checklist, the requirement of "Does the headlight switch work?". The answer is no! Understand that it is not a broken switch, it is designed not to work!

The car has a light sensor that turns on the headlights anytime the engine is running and it is dark, per some light sensors and computer algorithm hidden away in the Engine Control Unit. Here in cold Pennsylvania I get my car out of the garage to warm it up, before adventuring out on the daily commute to work, while playing Russian Roulette with the local deer population (Hunters complaining there are not enough deer are not hunting around here!). Anyway, my now impossible to turn off head lights are now shining directly into the neighbors bed room window, as the car warms up. While I've seen far to many people driving around here with their headlights off in the dark, would not a simple LED on the instrument panel have been sufficient? A complex device like a automobile should never over ride the judgment of its user. Do we really need technology to control impulses, enforce good behavior? What happens when all technologies fail?

I think "Smart Cars" are about to get to smart. I once almost had a accident on Interstate 80, in a construction zone.

Somehow a car that was over packed pulled from between some construction equipment, in front of me.

This driver could not see out any window but right in front of him, and he was pulling across the interstate traffic, not going with the flow. He could not see out the passenger window, that was facing me.

He shot out from between the construction equipment about twenty feet in front of me, while I was doing 45 MPH, remember it was a construction zone.

The correct solutions to the problem was to floor the gas, so that I could get in front of him while there was still space, and get off on the right hand brim of the road.

Toyota's system, Toyota cars to monitor driver's eyes for safety, would have guaranteed that a crash happened in that situation by applying the breaks.

"Toyota will start building a safety system into some of its cars this year that monitors if a driver is clearly watching the road during situations when a crash may occur. The system is based around a camera that watches the driver's upper and lower eye lids to evaluate how attentive he or she is to the road ahead. It builds on a current system that measures the driver's head direction when driving. The car's safety system continuously monitors the road ahead using a radar system, and if it determines a crash may be possible, it matches this with the driver evaluation gathered from the camera. If the driver doesn't appear to be paying attention it sounds a buzzer and warning light. If things progress and a crash becomes probable then it also tries to gain attention of the driver by quickly applying and releasing the brakes. At this point the car's pre-crash brake assist system is also readied. When a crash is judged to be unavoidable the safety system engages the brakes and seat-belts for the collision."

Moving from Requirements to Software Quality, the January 2010 issue of PragPub Magazine from Pragmatic Programmers, has an article that you should checkout: Rediscovering QA; Three Unusual Attributes for Software Quality Assurance by Chris McMahon.

PragPro Magazine is edited by Michael Swaine who was the long time editor of Dr. Dobb's Journal, giving PragPro the flavor of Dr. Dobb's in its hayday.

Also this week Walter Bright wrote a piece Patterns of Bugs, where he covers several common bug patterns he has encountered over the years. Take note of the articles comments as they point to some interesting sounding papers and tools. For example one of the commenter's, Kennn [SIC], to Walter's piece points out Andrew Koenig classic paper C Traps and Pitfalls, at Literate Programming.

Literate Programming is one of those things that sounds great in theory but I've personally seen it fall apart in practice. In a nutshell Literate Programming is where you write the documentation for the program, and that documentation is then transformed into executable code.

The Open Source schematic capture package gEDA was originally written in NOWEB (which has nothing to do with the Internet Web). Many people wanted to contribute to the gEDA project, but few wanted to be bothered to learn this obscure language. Only after NOWEB was abandoned in favor of straight C code did the project start to advance significantly.

Walter makes a case for creating an Open Source repository for bugs, where people can see the mistakes others have made. Add a rating system, as in which bug happens the most like, '=' rather than '==', and we have the makings for yet an other social networking site to consume our time, distract us from our goals in life, and make some extremely wealthy. Who wants in? :-)

Perhaps NASA's Lessons Learned site would be a good example? Contrast the space and aviation industry with how they learn from their mistakes and share the knowledge, with that of the medical industry, of hospitals and doctors, where they get to bury their mistakes. Those mistakes get covered up, literally and figuratively, so no one learns from them and they are repeated over and over. For inexplicable reasons my wife's hobbies are to collect medical and insurance horror stories, and there are more every day. She could make a career out of it if anyone paid for such a thing. I keep trying to get her to blog about it, but can't get her interested, so far.

Wonder if I'll void the remaining warranty by installing an old fashion low tech. toggle switch...