NASA's first-ever Software Engineering Handbook (SWEHB) released to the public

After years in the making, NASA has now released to the public their first-ever Software Engineering Handbook (SWEHB); NASA-HDBK-2203 (2013-02-28).

YouTube video showing how a person can navigate through the NASA Software Engineering Handbook to find software engineering related information. This video is about ten minutes long and can be used as a good training or awareness tool.

Each section of the SWEHB provides six areas of information per entry: the requirement, its rationale, guidance for implementation, notes for small projects, associated resources, and related lessons learned.

The 135 software engineering requirements for NASA projects are listed in a small, blue booklet, seventy pages long, called NASA Procedural Requirement (NPR) 7150.2 AKA NASA Software Engineering Requirements; View all pages in PDF. The new handbook is "A sort of hitchhiker's guide to the NPR". The handbook does not impose additional requirements; it is meant to be an assist.

Haley Stephenson explains how the SWEHB was developed as a collaborative Wiki in The Hitchhiker's Guide to Software Engineering at NASA. Many mangers do not seem to appreciate the value of using something like Dokuwiki to collaborate and document the development of a project. Without such documentation, years later, we are left to wonder "why did we use the red widget, rather than the better blue widget?". Perhaps they are afraid of Federal Rule of Civil Procedure Rule 26; Duty to Disclose; General Provisions Governing Discovery? See also Michael Barr's Dead Code, the Law, and Unintended Consequences.

Always keep in mind that Software never works in isolation. Safe Software is useless if the system as a whole is not safe. To that end make sure that NASA Systems Engineering Handbook (in PDF here) has a place on your desk or bookcase.

Related Documents:

• Standard for Software Assurance with Requirements Compliance Matrix [MS_Word] and Requirements Compliance Matrix [MS_Excel].
• Software assurance standard; NASA-STD-8739.8 (2004-07-28)
• Software Safety Standard; NASA-STD-8719.13 (2013-05-07)
• Software Formal Inspections Standard; NASA-STD-8739.9 (2013-06-17)

NASA's video on LENR AKA Cold Fusion.

A video was uncovered a few days ago on NASA's Technology Gateway that seems to be supporting "Cold Fusion": NASA's Method for a Clean Nuclear Energy For Your Power Operated Technology, (which I covered last year: Will Cold Fusion or the solar powered bikini, the iKini, power your next embedded system?). Today Cold Fusion goes by the moniker of Low Energy Nuclear Reactions or Chemically Assisted Nuclear Reaction, or simply LENR-CANR, to get away from the political baggage the term Cold Fusion brings. Best to snag a copy of the site before 'They' wake-up...

Actually what I find of most interest is the picture shown at time mark 1:55 from the Space and Naval Warfare Systems Center. SPAWAR's first papers on Cold Fusion have been listed on my, long neglected, Unusual Research site since 2002. Makes you wonder what does the Navy and NASA really have after ten years of research? It has not been a question of 'if' Cold Fusion works for years, but a question of 'how' it works... Pick up a set of back issues of, the out of print, Wayne Green's Cold Fusion Journal to see where we've been and where we might be headed....

Anyone want to sponsor my trip to the The 17th International Conference on Cold Fusion being held August 12 - 17, 2012, in Daejeon, Korea? :-)

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

Counterfeit ESD products. Guide on EMC for Functional Safety.

Interference Technology of ITEM Publications, has released their 2010 EMC Directory and Design Guide - Digital Edition. [Alas the Digital Edition is an annoying FlipBook that does not render correctly in Opera. Using FireFox you can find the link to the PDF version.]

Several interesting articles, but there are two in particular I wanted to bring to your attention:

• The Dip Tube by Robert J. Vermillion.
• The IET’s Guide on EMC for Functional Safety by Keith Armstrong.

To the first one you've got to be wondering whats a Dip Tube? Properly rendered as DIP, Dual Inline Package, it makes more sense to you I'm sure. Those long plastic rails that our ICs are supplied to us in from the factory. It seems that not only do we have to worry about counterfeit parts. We now have to also worry about real parts coming in counterfeit anti-static protection, making the real parts unusable junk. Also offers some words of wisdom on reusing anti-static protection. The words are "don't do it".

The lengthy second article is an introduction to the Guide on EMC for Functional Safety, August 2008, ISBN 978-0-9555118-2-0. Available from The Institution of Engineering and Technology as a PDF, or as a real book (colored chemicals on dead trees). Checklists are found here.

The guide is a 9-step Process to Functional Safety taking EMC in to account. It even includes useful checklists to aid project management, design and compliance assessment.

I'll quote Mr. Armstrong introduction directly:

"Electronic complexity is increasing with no end in sight, increasing self-generated noise levels, while the feature sizes in silicon integrated circuits continue to shrink, making them emit more noise while at the same time more susceptible to noise. The use of electronics in safety related applications is growing very rapidly indeed, with (once again) no end in sight.

We have already reached the point where the normal testing-based approach to electromagnetic compatibility (EMC) is totally inadequate where safety is concerned, as current media interest in automobiles with malfunctioning 'electronic throttles' shows. [The Toyota problem seems like a classic case of Priority Inversion to me.]

...

It comprehensively describes practical and cost-effective procedures for both management and engineering, and can be used immediately to help to save lives and reduce injuries, whenever electronic technologies are used in safety-implicated products, systems or installations of any kind. It is so practical that it even includes useful checklists to aid project management, design and compliance assessment.

...

The IET Guide can also be used to improve reliability, for example in high-reliability, mission-critical, or legal metrology applications.

...

EMC immunity testing is never sufficient on its own for safety I hope I have shown that EMC testing can never be sufficient - on its own - to demonstrate that functional safety risks are low-enough, or that risk-reduction will be high enough, over the life-cycle of an EFS, taking its physical and climatic environments (including wear and aging) into account. The number of variables is simply too large. Test plans could be drawn up which would provide the necessary design confidence, but no-one (even governments) could afford their cost, or the very long time they would take. But we’ve been here before! In the 1990s it was realised that testing was not sufficient to demonstrate that software programs were reliable enough for use in safety systems. After many hundreds of man-years of work by academia and industry, the result was Part 3 of IEC 61508."

While on the subject of EMC, Mr. Armstrong is a frequent contributor to the EMC Journal freely available from the Compliance Club. Do check out the past archives of the Journal.