Automobile safety recalls made big news this year. Did you know that in the first six months of 2014 alone, U.S. automakers broke the record for vehicle recalls in a single year? The total is 39.85 million vehicles, which trumps the previous 2004 record of 33.01 million. Embedded software was the culprit in many cases.
Despite these dismal statistics, demand for “smart” technology in cars – as well as and other devices with safety-critical components like insulin pumps, pacemakers and home heating systems — is continuing to rise. It will keep climbing as microprocessors become more powerful, and consumers develop bigger appetites for the perks and conveniences of smart technology.
This brings new challenges to manufacturers of automobiles, aircraft, medical devices and other products that need to function predictably and be understood by customers to protect life and property.
In this post, we look at how the preponderance of embedded software in safety-critical systems is changing perceptions of quality and manufacturers’ approaches to delivering it.
Consumer products have always featured safety-critical components. When they were mechanical or physical, identifying and testing potential causes of failure was a straightforward engineering function. Safety was closely linked to the reliability of the component, which manufacturers could qualify based on proven patterns of wear and tear. Assessing software’s impact on safety is more complicated.
With cars, the challenge stems from ever-growing volumes of embedded software, as well as from the complexity of the operations the software controls. Today’s late-model cars are essentially high-tech devices on wheels.
A luxury car contains about 100 million lines of code and 20 million controls the navigation system alone.
Embedded software also controls brakes and complex cruise control systems that use cameras and sensors to adapt speed to changing road conditions. In some car models, embedded software operates as many as 11 airbags that have to deploy at exactly the right moment to protect everything from head to knees.
The more variations, the more difficult it is to predict its behavior in every possible situation.
Another complication is that software-driven safety components rarely function in isolation. A driver’s behavior can impact the performance of the airbag. The ways in which a nurse interacts with the interface of an electronic infusion pump affects dosage rates. Components can fail when users don’t invoke the software that controls them in a predictable manner.
With so many unknowns being compounded by by rising budget and first-to-market pressures, manufacturers recognize that they can no longer sustain the exhaustive testing needed to identify every possible cause of failure.
Still, they have a responsibility to mitigate and minimize product safety risks and alert customers of potential hazards. (Otherwise, we wouldn’t be talking about this year’s record number of auto safety recalls.)
To bridge these competing realities, new safety standards such as ISO 26263 for auto manufacturers have emerged to guide a smarter approach to product development and testing. Based on risk, these industry-specific standards associate testing requirements to a component’s impact on safety.
In the case of a car, a DVD player is classified as a low-risk component; navigation system, moderate; electronic brakes, high. The rigor of testing and process control applied to each component is tied to the severity of the consequences should it fail.
The adoption of risk-based safety standards shifts the focus of product development from preventing failure to protecting safety. This challenges manufacturers to rethink the long-held idea that quality and reliability are one and the same.
It adds a whole new dimension to the development lifecycle by expanding the scope of requirements gathering to include hazard analysis and product functionality.
The overriding goal of a hazard analysis is to identify and design ways to mitigate risk. The approach is to gain a full grasp of the various environmental, user- and process-related factors that contribute to these risks.
This analysis informs design decisions not only for software, but also for the protective hardware and labeling that can reduce the impact or instances of harm. It also blurs the lines between software, hardware and systems engineering teams that need to understand the effects of change and the impact of design decisions on overall product safety.
For manufacturers, this means adopting agile product development practices to support seamless cross-discipline collaboration, integrate hardware and software, manage software variants across product lines and streamline regulatory approvals.
By investing in ALM, many manufacturers are benefiting from improved traceability enabled by effective process control. This is especially vital to teams that develop software for safety-critical systems with a large number of variations—like a supplier of electronic braking systems to multiple automotive OEMs.
Tracing and correcting problems that are a potential safety risk before products are released is a smart move. I’m sure that’s the new attitude of the automakers behind this year’s safety recalls.
Learn more about PTC’s ALM Solutions.