"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.

NASA Goddard Space Flight Center (GSFC) Software Assurance

Back in the blog I wrote, The Anatomy of a Race Condition: Toyota vs AVR XMega I mentioned the NASA Software Safety Guidebook. Seems that link went viral, as it popped up lots of other places the next day as people spread it around.

I was a bit surprised, but glad, to find that the Software Safety site and this Software Safety blog are listed number one and number two by SEMRush (a 'Competitor Research Service'), beating out NASA themselves at number four, for the term "Software Safety".

Will today's link to NASA's Goddard Space Flight Center's Software Assurance page go viral as well?

"The NASA Goddard Space Flight Center (GSFC) Software Assurance Website provides tools, procedures and training materials for software and safety assurance personnel, software engineers, as well as program and project managers."

Of the most practical day to day value are the numerous Checklists, for example one on Code Inspections, and the Forms and Templates. There are also examples of Procedures, Guidelines, Work Instructions, links to tools etc. The Automated Requirement Measurement (ARM) Tool has been developed as aid to "writing the requirements right," not "writing the right requirements". As of this moment Humans still create the initial requirements for any device or Embedded System, and Humans are prone to errors. Unless an other Human catches the error(s) in a requirement document early in the development life cycle, no downstream tool will clean up the mess or mitigate the cost overruns.

NASA Site for On-line Learning and Resources (SOLAR), has some on line training as well. The Defense Acquisition Guidebook also has a section on Software Safety online training; MIL-STD-882D, "DoD Standard Practice for System Safety".

While in the Software Safety area of space flight check out Software Safety and Rocket Science by Gerard J. Holzmann in ERCIM News. Issue #75 covered Safety-Critical Software.

In my last blog entry I mentioned Circuit Cellar Magazine. In the April 2011 issue George Novacek took on the DO-178B software assurance standard. George details the standard, as best as you can in the allowed couple of pages, then seemed to imply at the end, that doing all of this paper work doesn't make the system much safer. Over the years I've seen both sides. Not having good written requirements leads to nothing but never ending project changes (changes are normal, but if you don't know what your setting out to make, you never know when you are done), cost overruns, and missed deadlines. On the other side having so much paper work that you can never actually ship a product out the door puts any company selling Embedded Systems out of business.

Congratulations Circuit Cellar!

I want to congratulate Circuit Cellar Magazine on reaching issue number 250. When almost all other print magazines (you can get CC as a PDF too) are shrinking and/or dieing, Circuit Cellar is actually increasing in circulation and the number of pages.

I still remember the rush I got when I unexpectedly came across my own name in Issue #2, and many other issues. Check out the magazine for yourself and see what kind of rush you can get out of it each month.