Functional Safety – The Road Not Taken

Robert Frost’s timeless poem "The Road Not Taken" (https://www.poetryfoundation.org/poems/44272/the-road-not-taken) resonates deeply with me, often echoing in my mind as I navigate the challenges of functional safety in autonomous vehicle projects. Frost paints a vivid image of standing at a crossroads, surrounded by dense forest, each path offering a distinct journey. One road, wide and well-traveled, promises ease, predictability, and structured support, albeit at a cost. The other, narrow and less trodden, is fraught with uncertainties and risks but offers the allure of discovery and unique experiences.

This metaphor aptly captures the dilemmas functional safety (FuSa) professionals face, especially in the context of ISO 26262—a standard that provides guidance but stops short of prescribing exact solutions. The complexity of large-scale software projects in the automotive domain often leads to an overwhelming number of potential approaches. Selecting the right path becomes a critical decision, where missteps can result in wasted resources or reaching a dead end or not passing an assessment.

Navigating ISO 26262 Challenges

ISO 26262 Chapter 6, which outlines the software requirements for ASIL (Automotive Safety Integrity Level) compliance, is a prime example of this challenge. One of its most demanding requirements is achieving Full Branch Coverage for unit testing (Table 9, line 1b). Meeting this single specification can be a significant challenge for anyone involved, requiring substantial effort and resources.

The Role of Tools in Compliance

Upon deeper exploration of the standard, you realize that tools can assist in measuring and generating unit test coverage. Yet, ISO 26262 stipulates that these tools themselves must be qualified (detailed in Chapter 8, Clause 11, and Chapter 10, Clause 13). The market offers both open-source tools like GTest and GCov, While other, proprietary which are certified tools that come with advanced features like continuous integration support and even partial automation of unit tests creation (though such automation for unit test creation isn’t really allowed).

Choosing the Certified Path

One path involves opting for certified, proprietary tools that simplify compliance at a cost. This choice offers reliability, reduced risk and resources, and a structured framework that aligns seamlessly with ISO 26262 requirements, but it also requires an additional financial investment.

Exploring the Road Less Traveled

The alternative is to venture down the more challenging route: qualifying open-source tools independently. While this approach demands significant effort and expertise, it could contribute to the broader community, perhaps even paving the way for others by sharing the qualification process.

A Decision That Shapes the Future

The decision isn’t straightforward. Choosing the well-trodden road offers certainty and time efficiency but requires financial investment. Taking the less-traveled road entails embracing risk and investing in tool qualification efforts, which may ultimately yield significant cost savings and foster innovation—but only if executed effectively.

Your Turn to Choose the Path

To my readers, I pose this question: which road would you take? Have you navigated this decision before? If so, what was your experience, and what lessons did you learn along the way?