August 11, 2011

Certifiable Software

Trying to Make Sense of the Dizzying Number of Language and Coding Standards

by Bryon Moyer

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:







Green Hills







WindRiver (now part of Intel)



Total Posts: 5
Joined: Aug 2011

Posted on August 15, 2011 at 3:21 AM

Systems/software engineering and certification are two different things but related. We spend 2 years extracting some 3800 semi-atomic process requirements from standards like IEC 61508, IEC 62061, ISO DIS 26262, ISO 13849, ISO DIS 25119 and ISO 15998 and mapping them to a common V-model. we also took some input from other references. All these standards are indeed very confusing, very heuristic and 80% overlapping when analysing them. The worst is the "mother of all safety standards (IEC-61508)", the most practical one is ISO-26262.
But now that this done, the next step is to integrate or create your own process. Therefore we created an web portal, called GödelWorks, that allows to define your own process and project, based on a formalised common systems/software engineering model. It imports the 3800 standards requirements as references. We are also involved in an EU level project to now harmonise standards from railway and avionics as well. The main problem is that different sectors have different maturity levels and different heuristics (a lot!) and don't speak the same language. But at the end of the day, good systems engineering is the same every where. And yes, this is not what they teach you at school.
More info at Seehttp://www.altreonic.com/content/product-overview.... See GödelWorks.
You must be logged in to leave a reply. Login »

Related Articles

Dont Pass Me By

Project Ara Dev Boards and the Internet of Moving Things

by Amelia Dalton

The pedal is to the metal, our motor is running, and Fish Fry is hitting the open road. At the wheel this week is mCube...

Off to the Android Races

New EEMBC Benchmark Measures Android Speed

by Jim Turley

I dont always benchmark my Android devices. But when I do, I prefer AndEBench-Pro. The Most Boring Man in the WorldBenchmarking,...

And Then There Was One

InvenSense Scoops up Movea, Trusted Positioning

by Bryon Moyer

Once upon a time, roughly a month ago, there were sensor makers, who made sensors and did some amount of their own sensor fusion software,...

X Marks the Spot

Thwarting Pirates with AI and X-fest 2014

by Amelia Dalton

At Attention Ye Salty Dogs! Hoist the mizzen mast, Fish Fry is ready to set sail! This week Jim Beneke comes aboard our mighty Fish...

Wireless Wramblings

Changing the World with Cell Phones?

by Dick Selwood

Deciding what to write about for EEJournal is difficult. It is not that there is a lack of stories, but picking just one topic out...

Related Blog Posts

A New IoT Platform: RuBAN

by Bryon Moyer

Davra Networks focuses on far-away things that move.

When Wireless Means Cellular in the IoT

by Bryon Moyer

Some internet-of-things networks will be out of range of WiFi or BlueTooth. They might just have to make a cell call to get their data...

IoT Via WiFi

by Bryon Moyer

Modules are increasing being made available to simplify the process of connecting Things to a WiFi network.

How Does Multicore Affect Code Coverage?

by Bryon Moyer

Analysis tools can help identify whether code gets executed. LDRA recently added multicore coverage; what does this mean?

IoT Paranoia Not a Bad Thing

by Bryon Moyer

A recent presentation on IoT security tried to put a real-world face on the abstract notion of IoT security.

  • Feature Articles RSS
  • Comment on this article
  • Print this article

Login Required

In order to view this resource, you must log in to our site. Please sign in now.

If you don't already have an acount with us, registering is free and quick. Register now.

Sign In    Register