Take Another Look at Your Functional Safety Practices: Part 1 in an Automotive Functional Safety Series

Blog by Matt Klassen, Solutions & Product Marketing Manager, PTC

Functional safety is not a new concept, so why is it such an important topic in the automotive world these days?  The short answer is the complexity of the modern automobile coupled with recent high profile systematic failures have demanded a more thorough, more detailed, and more domain specific functional safety standard.
That being said, it is helpful to understand the answer in more detail by looking at:

  • A brief history of functional safety
  • What functional safety is in simple terms, with pictures
  • The role of software in embedded system complexity and functional safety

A brief history of functional safety
The notion of functional safety was introduced in the 1980’s as a means to evaluate complex devices as part of the overall safety function. In 1998 the IEC published a document, IEC 61508, entitled: “Functional safety of electrical/electronic/programmable electronic safety-related systems.” IEC 61508 was originally developed for industrial machinery and chemical plants and remains the relevant standard for many industries.  In recent years, however, many industries have looked to develop domain specific standards that are better suited to their application and can handle the immense rise in system complexity driven by many factors including the exponential growth of software. Specifically, the automotive industry is set to launch the new ISO 26262 standard, which is an adaptation of IEC 61508 for road vehicles. ISO 26262 takes a lifecycle approach and focuses significantly on development processes as a means to proactively design safer automobiles.

What is functional safety?
According to IEC 61508, functional safety is freedom from unacceptable risk of physical injury or of damage to the health of people, either directly, or indirectly as a result of damage to property or to the environment. Functional safety is part of the overall safety that depends on a system or equipment operating correctly in response to its inputs. In more simple terms, it provides the assurance that the safety-related systems will reduce the risk of injury to a tolerable level. Figure 1 does a good job of illustrating this. ISO 26262 focuses on the Electronics and Software Systems more specifically.

Figure 1: Functional Safety

Furthermore, it is important to note that functional safety relies on active systems, not passive. For example a sensor actuated fire sprinkler system is a functional safety system, whereas, spray-on fire retardant is passive and therefore not a functional safety system.

The Role of Software
Software is fundamentally changing the way products are engineered, manufactured, serviced, and used. Software is growing at an incredible rate in almost every manufacturing industry, but automotive is arguably in the lead pack. Software brings with it many significant benefits, such as late design flexibility, an almost limitless capacity for innovation, reduced manufacturing costs, improved product variability and product line support, and significantly improved product serviceability. Unfortunately, as with most things in life, these benefits do not come for free, or even cheaply — software drives incredible product complexity and high velocity change that must be managed.

Software within electronic systems is also playing a larger and larger role in functional safety and must be a major design consideration from the beginning. Hardware-centric systems engineering practices are a thing of the past for market leading organizations. ISO 26262 addresses this with a balanced triple V model approach, such that system, software and hardware are all accounted for within the standard.

Conclusion and Recommendations
In this short entry, I have barely scratched the surface of this important topic and therefore will be addressing several other areas in upcoming installments in this series.

Here are a few recommendations I have gathered from current customers in this industry:

  • Take a close look at ISO 26262 and begin to address this standard in your development processes sooner than later
  • Look at your tool chain and consider consolidation as a means to better support critical requirements such as traceability and also as a way to streamline compliance
  • Consider the growth of software in your products and how you might proactively address software driven challenges in your lifecycle management practices

Let me know if you found this post useful and please come back for future installments in this series. I would also invite you to a follow me on twitter @mfklassen.