Saturday, June 28, 2014

Our code hasn't killed anyone. Yet.

Last year I switched from virtualization software to the automotive industry. The most notable difference for me was the change in scope of projects. While in the virtualization world a project can take a few months (and some can even be shorter), the automotive industry is a sluggishly slow machine. 2 years is considered a quick project and some projects can take even 5 years.

About a year ago I joined a project which directly deals with life endangering code. Such code, can cause the car to hit and kill people. For me, stepping into such a project was extremely interesting. Nobody like bugs in their code, but here bugs can kill! The Automotive Safety Integrity Level (also known by the nickname ASIL) is a classification system derived from ISO 26262 which was created to asses and prevent just those types of bugs. Ensuring that for life endangering code the risk of failure is low to the point of non existent. Various mechanisms are placed that cause overhead (a definite problem for embedded systems), and force redundancy, but their aim is to ensure that if your code outputs 1 it meant to output  that 1.

Some may consider this a boring subject and annoyance. I mean, who would want to have to write code just to make sure his other code was run properly. That his system is still 'sane' and that 1+1 still equals 2, and I'm not even getting into the required documentation! I agree that it certainly complicates things, however I find it fascinating. I mean, somebody actually sat down and wrote hundreds of pages on just how your software and hardware can screw up and what you can do to minimize the risk of that happening, and the best part is – some auto companies are actually enforcing this standard!

So after a while I got thinking, 
“If all this precautions are just for this little code in the car, what requirements exist for the really dangerous stuff like missiles and planes!”
Some of this information is available on wikipedia of course, but it only lists boring data, it doesn't show the action items behind it. This is why I was so excited to hear that the second keynote in CppCon ( this year will be about a closely related subject: C++ on Mars: Incorporating C++ into Mars Rover FlightSoftware. Mark Maimone will speak on the ultimate challenge – how they write C++ code that can reliably recover from errors 225 million kilometers away!

No comments:

Post a Comment