Four automotive functional safety mistakes that must be avoided

Article By : Poornima Jha and Vaibhav Anand

The FuSa mismanagement can be related to a lack of safety awareness in the organization or poor coordination among different teams.

Automotive stakeholders such as OEMs and Tier-1 suppliers must observe functional safety (FuSa) as a practice across their organization. Easier said than done, implementing ISO 26262 compliant FuSa comes with its own set of challenges. And these challenges, when not addressed, lead to project management mistakes that burden the project with delays and cost escalation. The mismanagement instances can be related to an overall lack of safety awareness in the organization or poor coordination among cross-functional teams.

In an automotive ecosystem, the negligence committed by one stakeholder trickles down to others as well. If the Tier-1 supplier does not perform hazard analysis in an extensive manner, the architecture design might turn out to be riddled with unidentified hazards and associated risks. Similarly, working on a safety-critical project with resources that have not been trained on ISO 26262 standard comes with its own perils. In this article, we have compiled a set of such FuSa management mistakes that must be avoided at all costs.

1. Lack of safety awareness in the organization

Functional safety is not restricted to the safety team working on a safety-critical automotive project. From developers and testing engineers to project managers, each team member must be aware of the ISO 26262 standard and its guidelines. Let’s look at some of the FuSa mistakes that are committed when there is an overall lack of safety awareness in the organization.

• The missing safety culture: Safety culture essentially means that every stakeholder in the development of an automotive software or hardware is serious about functional safety. No hazards are ignored, every stage in the safety lifecycle is taken care of, and resources coordinate with each other and work in collaboration. Merely having a functional safety manager/consultant while not focusing on building a safety culture is the most common mistake that is committed by organizations.
• Focus on documentation rather than safety: Documentation is an essential part of the ISO 26262 compliance. These documents act as evidence when the OEM goes for certifications. However, focusing solely on the documentation rather than the actual safety requirements, goals, and mechanism is counterproductive.
• ASIL determination based on assumptions: Determining the automotive safety integrity level (ASIL) value of an automotive module without performing hazard analysis and risk assessment (HARA) has been observed as a common practice which must be avoided. Assuming the ASIL based on industry norm is not recommended since it might lead to hazards being missed out. For instance, an infotainment system is usually considered to be ASIL B. Hence, a lot of infotainment development companies do not perform HARA and consider ASIL B for their solution to be sufficient. What if the infotainment system also incorporates the camera data that might be used to automate certain actions in the vehicle? This is a serious safety hazard that got ignored due to assumptions.

Figure 1 HARA, as a process, is a culmination of both the ISO 26262 prescribed framework and the team’s understanding of functional safety and automotive functions. Source: Embitel

2. Safety mismanagement instances triggered by undermining functional safety

Some automotive suppliers or technology providers are aware of ISO 26262 standards and its nuances. However, to avoid cost and reduce time-to-market, they tend to undermine functional safety of certain safety-critical components. What seems to be a casual ignorance of safety requirements or hazards might turn out to be life-threatening for the vehicle occupants.

• Underestimating timeline/efforts for the overall project: Once you bring safety criticality into the picture, and ISO 26262 standard along with it, the effort increases for obvious reasons. And with the effort, the timeline also extends. Usually, ASIL A implies 10-15% increase in the effort, which goes up to 100% for ASIL D compliant projects. Underestimating this effort without taking the safety requirements and goals into consideration is another ISO 26262 compliance mistake to avoid. When companies try to squeeze in the implementation part to adhere to a pre-determined and arbitrary deadline, the project starts to suffer.
• Thinking of safety at the end of product lifecycle: As mentioned earlier, the architecture design of an ISO 26262 solution is created based on software requirements as well as safety requirements. When you develop an automotive solution that is intended to be ISO 26262 compliant, the standard guidelines must be followed from the onset of the product lifecycle. Incorporating these guidelines at the end of the lifecycle or in the second iteration proves to be a huge mistake due to the following factors:

1. Design rework is heavy since the original design does not incorporate safety aspects.
2. Reuse of legacy code is not possible as it is non-ISO 26262 compliant. Checking the pre-conditions, using wrapper between modules that send/receive signals, and introduction of new modules mean that a lot of new code might need to be written.
3. At times, the entire design needs to be changed and that might lead to changes in the microcontroller platform. This implies designing the product from scratch.

• Underinvestment in tools and engineering skillsets: A lot of organizations feel that having a functional safety manager is enough to ensure ISO 26262 compliance. There is often a certain degree of insensitivity in the attitude toward safety. This could be in terms of usage of qualified tools or upskilling of resources. It is always recommended to train every resource associated with each ISO 26262 compliant project. From developer and tester to the project manager, every stakeholder must have a good command over practices enlisted in the ISO 26262 standard.

Figure 2 Functional safety, no more an afterthought, has life of its own in an automotive design. Source: Embitel

3. FuSa mismanagement from poor coordination among stakeholders

ISO 26262 compliant projects involve resources from different teams and with varied skillsets. There are developers, testing engineers, hardware experts, project managers, functional safety managers, and so on.

• Lack of coordination among teams: Different teams within an organization need to coordinate for completion of various safety activities. For instance, to perform hardware failure mode effects and diagnostic analysis (FMEDA), the software team must provide a clear understanding of the safety mechanisms. At times, the teams do not understand the importance of such cooperation.
• Poor coordination between OEMs and Tier-1s: There are instances where the OEMs are not able to provide sufficient support and readiness in terms of safety compliance. Hazards are skipped, safety analyses are not performed properly, and various such instances of mismanagement ensue. Also, failing to evaluate the Tier-1 suppliers’ tool competency by the OEM proves to be detrimental to the project.

4. A mix of technical and management mistakes

There are certain limitations caused due to lack of budget or common ISO 26262 knowledge that transcends project management and starts to disturb the technical aspects. Let’s have a look at them.

• Setting the bar too low for safety-critical systems: When you begin to ignore the hazards and relax the acceptance criteria, the project is jeopardized. For example, there may be just one safety issue in a module that warrants ASIL C. However, you choose to ignore it and stick to ASIL B. It’s a serious mistake that organizations commit. Escalation of cost is a major reason for such mistakes. Testing all extreme test cases, performing additional safety analyses, and investment in tool licenses increase the project cost. There is also a risk of burning the board, LEDs and motors while testing. Still, these failures must be checked for the sake of safety.
• Underestimating the importance of related standards like SOTIF and ASPICE: In addition to functional safety, there are other standards like ASPICE and Cybersecurity (ISO/SAE 21434) that are followed based on the project’s requirements. Since all these standards involve guidelines on coding and testing, there are lot of overlaps between them. The most common mistake in this regard is not considering the inter-relations between these standards while creating the safety plan. There are scores of activities that can run in parallel and even merged to save time. For instance, ASPICE recommends software qualification test which is similar to software integration test recommended by ISO 26262 and capability maturity model integration (CMMI). In principle, all of them check the high-level architecture of the software. The template for such similar processes can be merged to save a lot of time and effort. Another common mistake committed while working with different standards is ignoring the implication of one standard on the other.

• Overengineering: Every automotive module is not equally safety critical. You would know the degree of criticality only when you perform HARA. Organizations at times do not wish to perform all safety activities and assume a higher ASIL for a module just to be on the safe side. This leads to implementation of safety mechanisms that are not even required. Such practices must be avoided to keep the cost and time-to-market optimized.

ISO 26262 is an extensive standard, and an organization cannot attain maturity in functional safety practices in a short span of time. However, by avoiding the mistakes listed above, they can expedite this process.

This article was originally published on EDN.

Poornima Jha, a functional safety manager and FSCP-L2 certified ISO 26262 expert, is a project manager at Embitel.

Vaibhav Anand, a digital marketing professional with a deep-rooted interest in everything automotive, is a content writer at Embitel.

Subscribe to Newsletter