Safety-critical software: more, not less certification ahead?

September 09, 2013

Bernard Cole-September 09, 2013

As the microprocessors embedded developers use get more powerful and the software they design and write gets more complex and increases in size, they are faced with not just increasing opportunities, but also with the need to make the code as safe as is possible to use.

This is first being driven by such traditional application segments such as military-aerospace, automotive and medical, which all have strict software certification requirements testing standards in place. The second driver is the uncertain nature of the interactions between these segments with the totally unregulated nature of much of the current consumer and mobile market. And as far as newly burgeoning embedded consumer apps opening up in home electronics, safety does not seem to even be on the radar map.

However, according to Mark Pitchford and Bill St. Clair, LDRA, authors of a two part series featured in this week’s Tech Focus Newsletter, an ever-increasing reliance on software control and the nature of the applications has led many companies to undertake safety-related analysis and testing.

Consider the antilock braking and traction control of today’s automobile,” they write. “These safety systems are each managed by software running on a networked set of processors; the failure of any of these systems sparks major safety concerns that could lead to recalls and lawsuits.

“Companies concerned about safety in their products are looking outside their own market sector for best practice approaches, techniques, and standards. Examples of such industry crossover have been seen in the automotive and avionics industries with the adoption of elements of the DO-178C standard by automotive and a similar adoption of the MISRA standards by avionics.”

Such crossovers are likely to become more common, placing additional challenges before not only individual developers, but the certification standards groups in various industries as well.

In automobile environment, for example, increasing computerization of not only engine and power train electronics but the infotainment systems, and interactions between them means software safety will be an on-going challenge. And when you add in such things as vehicle-to-vehicle wireless networks, it seems to me that automotive developers have a real can of worms to deal with as far as safety is concerned.

In medical designs, for another example, there is an aging population in many countries where there is considerable effort underway to adapt software and devices originally designed for consumer environments to health and medical applications, forcing standards groups – and the FDA - to go back to the drawing board to come up with specifications and certification requirements that deal with such issues

Fortunately, as noted in this week’s Tech Focus Newsletter, there are a wide range of tools, RTOS alternatives and requirements and specification testing procedures available. Among my Editor’s Top Picks are:

Using static analysis to diagnose & prevent failures in safety-critical device designs,” which David Kleidermacher reviews various static analysis tools and their usefulness in safety-critical embedded applications and what remains to be done to address future challenges.  ,

"Using certified operating systems effectively in safety critical embedded designs, "  which includes tips on the safety certifications for many embedded applications and advice on how to select and use a certified RTOS in your safety critical application,

"Think ahead about coding standards,” in which LDRA’s Chris Tapp, outlines why it is important to think through carefully ahead of time which coding standard or subset to use for compliance before making a final decision, and,

"Applying Bayesian belief networks to fault tree analysis of safety critical software," which explains how to express fault tree analysis that takes into account both hard and soft evidence in a way that is quantifiable and usable in a larger model that expresses a full, quantified safety case for a design.

Despite this range of tools, capabilities and industry specifications to guide developers, there remain considerable uncertainties ahead as embedded systems become more connected and the Internet of Things phenomenon takes hold.

Already the auto industry is looking for ways to deal with the intrusion of a variety of mobile smartphones and mobile computing platforms into the automobile and the security issues that raises. Added to that are the moves toward vehicle to vehicle wireless connectivity. Unless there are strict dividing lines between an automobile’s entertainment systems, the information systems on which the driver relies and the body/engine electronics, the ultimate safety of any of these subsystems remains open.

In medical applications, the impact of network security on device safety is already raising concerns. Users of medical devices (such as yours-truly) who place their lives in the hands of the safety standards the FDA imposes, are continually bombarded on a month by month basis with offers of the newest smartphone app and wireless device add-ons to complement the operation of their medical devices.  And the rate at which they are being offered tells me that many of them have not gone though any sort of FDA approval, which traditionally can take years.

The dividing line between the methods for developing software for use in a secure environment and for use in a safety-critical design is razor thin. And it is apt to get thinner and more ambiguous unless safety standards organizations also start taking the impact of connectivity and security in how they evaluate safety.

To my mind at least, an insecure network-connected device or application by definition is not safe: if you do not have rock-solid security protecting every connection to your design, you have a system that you cannot be sure is safe.

Fortunately though, while waiting for the grey areas between security and safety to eventually be sorted out by standards groups, the embedded developer still has at hand a range of options. Although the details differ in the two environments, the tools and methodologies for such things as software requirements testing and compliance remain the same. Some recent articles that seem to me to be useful in both environments include:

"Using requirements traceability with model-driven development,"
"Automated tools streamline software test and certification,"
"Bug killing standards for firmware coding," and,
"Firmware forensics: best practices in embedded software source-code discovery." 

Embedded.com Site Editor Bernard Cole is also editor of the twice-a-week Embedded.com newsletters as well as a partner in the TechRite Associates editorial services consultancy. He welcomes your feedback. Send an email to bccole@acm.org, or call 928-525-9087.

See more articles and columns like this one on Embedded.com. Sign up for the Embedded.com newsletters. Copyright © 2013 UBM--All rights reserved.

Loading comments...

Parts Search Datasheets.com

KNOWLEDGE CENTER