Specifications You Should Read: The NASA Workmanship Standards

"This is reflective of the typically idiosyncratic way engineer's of this era explored the human condition. The purple and shitty gradient show's the artists deep struggle with deadlines and his personal philosophy on the tyranny of the bourgeois. " - A segment from a confused student's art history paper
“Reflective of the typically idiosyncratic way engineers of this era explored the human condition. The shitty gradient show’s the deep struggle with deadlines and their personal philosophy on the tyranny of the bourgeois. ” – An excerpt from a confused student’s art history paper after the standard is installed in the Louvre.

The NASA workmanship standards are absolutely beautiful. I mean that in the fullest extent of the word. If I had any say in the art that goes up in the Louvre, I’d put them up right beside Mona. They’re a model of what a standard should be. A clear instruction for construction, design, and inspection all at once. They’re written in clear language and contain all the vernacular one needs to interpret them. They’re unassuming. The illustrations are perfectly communicative.  It’s a monument to the engineer’s art.

Around five years ago I had a problem to solve. Every time a device went into the field happily transmitting magic through its myriad connectors, it would inevitably come back red tagged, dusty, and sad. It needed to stop. I dutifully traced the problem to a connector, and I found the problem. A previous engineer had informed everyone that it was perfectly okay to solder a connector after crimping. This instruction was added because, previously, the crimps were performed with a regular pair of needle nose pliers and they came undone… a lot. Needless to say, the solder also interfered with their reliable operation, though less obviously. Stress failures and intermittent contact was common.

Continue reading “Specifications You Should Read: The NASA Workmanship Standards”

Toyota’s Code Didn’t Meet Standards And Might Have Led To Death

We were initially skeptical of this article by [Aleksey Statsenko] as it read a bit conspiratorially. However, he proved the rule by citing his sources and we could easily check for ourselves and reach our own conclusions. There were fatal crashes in Toyota cars due to a sudden unexpected acceleration. The court thought that the code might be to blame, two engineers spent a long time looking at the code, and it did not meet common industry standards. Past that there’s not a definite public conclusion.

[Aleksey] has a tendency to imply that normal legal proceedings and recalls for design defects are a sign of a sinister and collaborative darker undercurrent in the world. However, this article does shine a light on an actual dark undercurrent. More and more things rely on software than ever before. Now, especially for safety critical code, there are some standards. NASA has one and in the pertinent case of cars, there is the Motor Industry Software Reliability Association C Standard (MISRA C). Are these standards any good? Are they realistic? If they are, can they even be met?

When two engineers sat down, rather dramatically in a secret hotel room, they looked through Toyota’s code and found that it didn’t even come close to meeting these standards. Toyota insisted that it met their internal standards, and further that the incidents were to be blamed on user error, not the car.

So the questions remain. If they didn’t meet the standard why didn’t Toyota get VW’d out of the market? Adherence to the MIRSA C standard entirely voluntary, but should common rules to ensure code quality be made mandatory? Is it a sign that people still don’t take software seriously? What does the future look like? Either way, browsing through [Aleksey]’s article and sources puts a fresh and very real perspective on the problem. When it’s NASA’s bajillion dollar firework exploding a satellite it’s one thing, when it’s a car any of us can own it becomes very real.