Certifiable Software

Be afraid.

Be very afraid.

That car you’re driving? There’s probably a bug in the control software that could, at any moment, introduce you to that big rig over there at 70 mph. Oh, that would be 140-mph closing speed. Woohoo!

The power grid that’s supplying the juice to the computer you’re reading this on? (Or supplied it yesterday if you’re on battery power, wise guy?) Don’t count on it when the going gets rough… Someone has assuredly planted electronic time bombs that will kill the current to your refrigerator right before you’ll need that cold beer at 2:01 AM when the liquor store has just closed.

And that electronic toy your child is playing with? You don’t want to know.

Just… pack up everything, find a small cabin deep in the woods, collect everyone and everything you love, and get off the grid and live the way folks are supposed to live.

OK, that needs some touching up, but yeah, I’ve been working on a brochure to unload this ugly cabin I ended up with that, so far, no one wants. And the best way to sell it is fear. Fear is awesome. People will do the stupidest things if you can convince them they’re in danger. Things that amount to pouring out all your beer so that no one can steal your beer.

In fact, the greatest thing you should fear is fear itself. (Wow, that’s an awesome concept. I should save that for some important occasion…)

That said, it is a bit sobering to think that people just like you and me – yes, go ahead and shudder, I said “me” – are writing the software that runs pretty much everything these days. Worse yet, much of that code is written in C. Think of it. I know the kinds of things I did when writing C… Wasn’t always pretty.

And my health and happiness hinge on this?

But, on the bright side, there are folks out there working to make our electronic world a safer place. At least where it really matters. (On your phone? The one that restarts for no particular reason now and then? Meh… not so much… you’ll get over it…) We’ve written about bits and pieces of this world before over the last few years, but never from on high, trying to gauge the entire landscape.

In case you think that this landscape may have evolved into a nice, neat set of organizations with clear agendas and well-defined boundaries, think again. Someone might decide to create a committee for safe standards for electronic toys, and that’s not going to stop someone else from starting a completely different committee for safe standards for electronic tchotchkes. (Which are NOT toys: they’re the ones that get put on a shelf and don’t ever get played with and are worth WAY more HEY DON’T TOUCH THAT!!!) Or maybe one for toys sold in, I don’t know, Armenia, which would, of course, be different from the standards for toys sold in Azerbaijian.

I’m making these up. Just in case that’s not clear. But you get the point. (I hope.)

So let’s take a walk through the world of the standards working to keep the software in our world on the straight and narrow. I use the word “standard” loosely here, since not all of these are formally ratified by ANSI-accredited organizations. But they’re honored nonetheless by practitioners, so I’m not going to quibble.

And I’ll be honest: when I started wading into this, I found the number of different organizations and documents almost bewildering. No matter how complete a list I thought I had, I could find yet another standard or organization that seemed to be coming at things from their own unique angle and with no real rationalization as to: a) why a different standard was needed and b) why the differences between it and the other standard made sense. It may be that, deep in the heart of these documents this information can be found, but it would take some searching (and sometimes in languages other than English… yes, we acknowledge that such languages exist…).

I was able to get some initial guidance from Chris Rommell, an analyst with VDC, who helped me to place some initial order on things. They do a study each year, and it shows increasing use of standards, with half of respondents using some kind of standard for their current project and 55% expecting to use one in two years. Exactly what that means can vary: for coding standards, the largest chunk, around 36%, were using an in-house standard, followed by selective adherence to a formal standard (21%) and then strict adherence (14%). But less than 20% of all the respondents were using no coding standard at all.*

This is consistent with the apparent haziness of this world, so the intent here is to survey the standards as well as some of the companies trying to help out with all this. The coverage will undoubtedly be incomplete, since it’s impossible to overturn every rock, and any rock could be hiding yet another company or organization. So feel free to supplement or clarify in the comments.

First of all, there are, roughly speaking, four different kinds of standard with four slightly different goals.

The first is simply about software “quality” in general: getting rid of bugs no matter the purpose of the software. These are coding standards.
The second is for coding standards aimed more specifically at “safety-critical” applications, where problems can lead to injury or loss of life (or severe economic pain).
The third are coding standards that target security, making sure that your code isn’t vulnerable to electronic breach.
And the fourth is different from the others: it concerns itself not with coding per se, but with the processes required to prove that you’ve taken into account whichever of the above are needed.

There is, of course, overlap between these, so this tidy list is merely my meager attempt to impose some order on the mish-mash.

When it comes to the first category, simple quality, there really aren’t standards per se. Netrino wrote a book on programming practices for embedded systems. High-Integrity C++ is another quality-oriented set of recommended practices.

The choice of language can be a start. If you really want to be finicky about bugs, plain old ANSI C may not be your first choice, even though it’s what everybody knows and there’s tons of it out there. Even C++ can be an improvement (if you ignore the fact that C is legitimate in a C++ program). Java and Ada have, in their own ways, tried to create paradigms that are less prone to boneheadedness (although I dare you to try to convince someone to use Ada if they don’t have to…).

This is also the category for which the most tools are available. Not even counting the freeware linters and checkers of various sorts, you can buy tools from PRQA, Coverity, and GrammaTech for a start, just to root out likely problematic code.

Safety and Security

Most everyone can agree that good code is a good thing, and “best practices” are legion. But it usually takes more than just good intentions to bring busy people together to spend extra time developing something more formal. Keeping airplanes from falling out of the sky is something that really motivates people. This has resulted in substantial effort to corral some of the less disciplined aspects of programming languages for use where life and limb are at stake.

You’ve got Cert C, MISRA C, MISRA C++, JSF++ AV, HIS (German automotive subset of MISRA), JPL, and IPA/SEC C (Japanese). Of those, MISRA dominates; it started as automotive and is now used elsewhere (sometimes selectively). There’s SPARK, a subset of Ada and the related Ravenscar Profile (now part of Ada 2005); the Java world has JSR-302.

There are also safety-critical protocols and stacks like OSEK, upon which the familiar AUTOSAR was based, as well as the ECU engine control unit and OIL OSEK implementation language, used at the architectural level.

There are a number of ways in which companies try to address these standards.

Companies like LDRA, PRQA, and Coverity can do certification checks.
Some provide development environments that aid in the creation of safe code. These include DDC-I and Adacore.
Then there are providers of operating systems and runtime environments targeting the safety-critical market. These include Green Hills, Wind River, LynuxWorks, and Atego/Aonix.
There are also design environments that start with a modeling paradigm to create safe code by design. Esterel and Atego’s Artisan are of note here.
Finally, there are services companies specializing in safety-critical projects. Atego’s HighRely and IBM are notable examples.

For security, the Common Weakness Enumeration, or CWE, aka ISO/IEC 15408, which has several levels of adherence, appears to get most of the attention. Certification and services are the rule here as well. Klocwork has a focus on security; Coverity and LDRA also perform security analysis.

It’s all about process

When it comes to process, there are tons of different ways to turn. From an industry-focused view, you’ve got EN 50128 for rail. ISO 14971, IEC 62304, and IEC 60601 for medical. IEC 61508 for heavy equipment and energy. IEC 60880 for nuclear energy. ISO 26262 for automotive. IEC 61508 for industrial automation. ISO 26262, in particular, is picking up momentum as it approaches ratification, with tool vendors getting a jump on certification and nascent processes in the automotive supply chain.

And then there’s the big kahuna: DO-178B (moving to C) for software in airborne equipment, along with its sibling DO-278 for the ground-based software that influences what happens to the folks in the air. Think air traffic control, for instance.

More generally, there’s ISO 12207 as a general software lifecycle standard, from which ISO 15504 was derived, more commonly known as Software Process Improvement and Capability Determination, or SPICE (not to be confused with circuit simulation SPICE).

Yeah, it’s an absolute head-spinning number of ISO/IEC numbers. There are other acronyms and numbers out there for which I could find little information.

These have everything to do with how you write your software. Much of it ties to requirements – there’s even a ReqIF requirements interchange format. Put simply, every requirement should be tied to specific code, and all code should be tied to a requirement. Formalizing this process is big business.

Companies certifying processes include LDRA, Atego, and MKS.

In case this all seems overwhelming, the tags you see most are MISRA and DO-178/278, with ISO 26262 ascendant. All of the others seem much more specialized or localized.

The work that these organizations do is never complete; standards, once ratified, are usually out of date. So it’s an ongoing effort to keep up with the increasing improvements (assuming that the changes are making things better). The bad news is that this means constantly having to revise tools and buy upgrades. Which turns into good news for the companies making the tools and providing services. It’s also good for everyone that, hopefully, a limited number of people have to track it all; if they do a good job, then the tools make life easier for everyone else.

So, while I should be concerned that all of this will reduce the overall level of fear and hurt my chances of selling that stupid cabin, I should be ok as long as people keep thinking of other ways that stuff could go wrong. I’m not really worried.

Oh, and I’m sure you’re not naïve enough to think that software is the only thing in a system that can cause problems. People are equally adept at creating crappy hardware. Which will be the subject of a future discussion.

*VDC Research, 2010 Software & System Lifecycle Management Market Intelligence Service, Volume 5: Engineering Design Methodologies, Processes, & Standards

Links to companies mentioned: