One of the most challenging topics for Tier 1s in a Safety program is the Integration of “ASIL” micro(s) into the System and fulfilling the Assumptions of Use (AoUs) provided in the Safety manual to ‘truly’ achieve the ASIL-ness of the Micro. Despite our experience over years integrating different ASIL Micros, we have, time and again, been surprised at what we have found. In this article, we have talked about the top 4 pitfalls we fell into. In the conclusion, we have given our recommendations on how to avoid these pitfalls.
Even though we have focused only on ASIL Micros in this article, you may fall into the same pitfalls while integrating any other ASIL HW Components such as PMICs, Sensor ICs etc.
Since the subject of our article is the Tier 1, wherever we have used the “you” pronoun, it refers to a person in the shoes of a Tier 1.
Micro is “ASIL” suitable but not “ASIL” compliant
- If the Micro’s documentation states that it is “ASIL suitable”, you could assume that it is an ASIL Micro. If you do not clarify the ASIL level of the Micro upfront, you may find out the gap only after the program has started and it will be too late to go back and ask for a Micro change. You may be forced to either take approaches like HW Component Qualification, which is tedious and highly not recommended. Or worst, you may have to deem the System itself as Not-Safety compliant, which leads to loosing your reputation with the OEM.
- If the Micro’s “safety” concept has used an ASIL Decomposition strategy, you need to think about and question the technical correctness of that solution for your system. Can you decompose all the Safety related failures of your QM Micro with an External monitoring? For e.g., if the Safety functionality still runs in this “ASIL suitable” QM Micro and you use its inbuilt mechanisms like MPU or ECC to protect your ASIL SW, what happens if these mechanisms don’t work correctly? How can the failure of MPU or ECC be detected by External monitoring?
The Supporting SW (Drivers, stack, libraries) provided for the Micro are not ASIL compliant
Challenges when using higher ASIL Micro for a lower ASIL System
Difficulties in balancing Safety and Performance
- Check if the ECC mechanism works correctly.
- Check if clock monitoring works correctly.
- Check if MPU works correctly.
- Check if all the Safety relevant peripherals of the Micro are working correctly.
- Ask the supplier about the ASIL level of the Micro and associated SW, and whether it is already certified, or if not, its plan for certification. Clarify this topic right at quote stage of the program.
- Create an agreement with the Micro Supplier right at program start and state your expectations on the Micro-related SW, FMEDA expectations etc.
- Ask the Micro Supplier about the very high-level assumptions made for the Micro SEooC and the constraints that it will place in your System (such as assumed external System/HW requirements, rough estimate on required start up time or run time for Assumed Safety mechanisms, restrictions in using peripherals when implementing some of the safety mechanisms etc.). Evaluate right at start if these constraints are acceptable for your system and identify alternate solutions if it is not.
- Discuss about the communication model to be followed between Tier 1 and Tier 2 during the program. In the phase of Safety mechanisms Implementation and Integration, Tier 1 will often need speedy support from the Tier 2. There may be also several technical questions on the safety mechanisms or how a HW’s inbuilt mechanism works, and this kind of support might require a different communication model. Think about all possible use cases upfront and agree on the best working model for a timely and successful integration of the ASIL Micro into the System.