Imagine that supplier ABC just won a prestigious project from a global OEM to develop safety-critical electronics. The atmosphere in the supplier’s office is one of celebration and excitement. Now, fast forward a year – the engineering manager is in the supplier’s office, fraught with angst and confusion. The supplier quoted for the project without realizing that the product required a high integrity ASIL to be achieved during engineering.
Even though the supplier was very knowledgeable in this product, he had limited experience with functional safety engineering. During the project quote phase, the supplier underestimated the extra effort required to adhere to the additional engineering activities for achieving functional safety. Therefore, they were having constant cost overruns and were behind schedule because they did not have enough engineers trained on functional safety.
Managing functional safety starts before the project kicks off and could extend long after the product has left the engineering group. The challenges for a project manager or safety manager vary from lack of past data to special dynamics that are introduced in specific project situations. The first and most challenging tasks for the project manager or safety manager is to estimate the cost, time and effort required to implement functional safety in a project. After the product is introduced into production, a dedicated safety manager is typically responsible for tracking safety anomalies that could be reported from the field for multiple products.
These situations show why it is important for an organization to capture data and lessons learned from past projects. It is important that the effort data is also captured based on the effort spent for each safety goal in various phases of product development. For example, concept phase, system development, hardware development, software development, verification, assessment, safety validation etc. can each be tracked independently.
Data that is captured with this level of granularity provide much-needed preparedness. Organizations may need this level of preparation to react swiftly with competitive effort estimates. A supplier may need to quote based on multiple scenarios prescribed by an OEM in the RFQ. For example, an OEM may ask the supplier to define the safety goals. Which means the supplier would need to estimate the time and effort for activities like item definition, HARA, and FSC. Another scenario could be when the OEM agrees to provide a production intent vehicle for safety validation but requires the Tier 1 supplier to do the actual validation.
There is always scope for further refinement of this based on finer decisions in the project. Examples of important topics for refinement include:
- Will FMEDA be performed (for example, in an ASIL B project where such an analysis is optional)?
- How many elements are there in the Bill of Materials?
- Does the Microcontroller support functional safety? (For example, does it have an MPU? which may reduce the effort required to prove freedom from interference).
Sometimes organizations understand the importance and need to capture data, but fail to take the first steps as they seek to find the elusive formula that could help them estimate effort without going through the grind of capturing data and constant learning. In some ways, this is like a person who is trying to lose a few pounds but does not want to eat better or exercise and is constantly on the lookout for that magical pill that’s going to help them achieve that. Organizations that have a good grip on their efforts will not only be able to quote realistically but also build and retain customer confidence in the long run.
- George, A. and Nelson, J., “Managing Functional Safety (ISO26262) in Projects,” SAE Technical Paper 2017-01-0064, 2017, https://doi.org/10.4271/2017-01-0064
- ISO 26262-1:2011, Road vehicles – Functional Safety – Part 1: Vocabulary
