“I test, therefore I exist.”

Paraphrasing René Descartes, what do you do if you’ve been conditioned from your engineering “birth” to test, and test everything.

This session is a fit for you if you program systems that require safety as one of its most important features (think 911 Public Safety, Avionics, Automotive), if not the most important. Additionally, if you’ve worked on a company that has a development process compliant with ISO 9001, then this session is for you, too.

Having worked for two companies that implemented ISO 900x, I’m very familiar with the intricacies that are needed to implement even simple changes. Often times the issue is not the change, but what it triggers (e.g., a system recertification, or an infinite number of tests; in other words, change is expensive). On the other hand, I’m grateful that such standards exist and that companies follow it.

Michael Wong starts the session with testing this type of systems for parallel/concurrent/manycore/multicore/{add your term here} systems. How do you do it? Well, it’s a tough question to answer.

So, now that we’re trusting our lives to compute systems controlling our cars, planes and toasters, wouldn’t you want to know that such systems have been tested exhaustively and meet standards for safety? Me too.

Enter SIL (Safety Integrity Level), “bins for levels of safety based on effects if the fault is not mitigated”. Reminds me of the Titanic blueprints shown in the movie that water would spill into another level, and another, until it would become “uncontrollable”

Meet MISRA, too, a suite of software required guidelines that you can apply to C++ to develop systems that are SAFE to use.

The slide on Unintended Acceleration brought bad, related memories: we have a Nissan Armada that one good day my wife said it would not stop after she stepped on the brakes. Being the engineer, I said that most likely it was the ABS and there’s no need to step on the brakes repeatedly…until it happened to me, on the freeway. Sure enough, the problem was firmware and there was a recall. Researching on the Internet, I learned of other drivers that had had an accident due to that error (calling it a bug is very nice).

Michael starts with the C++ Core Guidelines, identifying a gap in the rules that have to do with concurrency. Quickly he moves on to rulesets/standards that make more sense–Joint Strike Fighter Air Vehicle C++, MISRA, Autosar.

Ilya takes care of the second part of the session, and he shared the document that they’re working on. That got me doubly interested.

In the past I’ve worked in what I consider large designs using UML, and making use of use cases, business rules, and so on. Having the formality of writing this type of guideline is a lot of work, and I appreciate that effort by Mike and Ilya and all that are involved, whether it is in providing feedback, the definitions and the implementations to detect whether the rules are correctly applied or broken when writing real software.

What I liked about this session is that it is for software that will be running for quite a few years–say, a decade? two decades? You’d be surprised the longevity that your written code may have. I have been, and I wish these types of guides and standards were around at the time.

A virtual “tip my hat” to Michael and Ilya.