How to manage specific ASIL requirements when they only apply to one function?

[Xtian]

My question is a general question on how to  boil down "system level" ASIL requirements down to MCU ASIL requirements.

I have the following situation with a customer:  Initially, ASIL-B was defined as a requirement.  We therefore proposed an ASIL-B capable product. (MPC574xG)   In the meantime, the customer added ASIL-C requirements for some specific functions. ( in particular, some Digital I/Os and CAN communication is  requested to be ASIL-C) .  

Question: Do we require then an ASIL-C capable microcontroller?

It is my understanding that our safety concept does not address  peripherals or I/Os functions, since the use of these is highly  application dependent and therefore requires system-level strategies for fault monitoring.

Therefore, am I correct in thinking that even if we delivered an ASIL-C/D microcontroller, these I/O and CAN functions need to be dealt at system-level.   Could we then keep the current ASIL-B product and tell the customer to strengthen the safety level of the ASIL-C functions by software or something else?

[aarul]

Hi Christian

ASIL x is an attribute of a requirement and so it is possible to have a system level ASIL C safety requirement decomposed into hardware level requirements having lower ASIL. ISO26262-2018: Part 9, Clause 5 deals with the topic of decomposition.

And so in the your case it is possible that while the system safety requirement for the function (CAN communication) is ASIL C, the hardware safety requirement allocated to micro-controller is ASIL B(C). In this case it is OK to meet this requirement with the device certified to meet ASIL B safety integrity. The system integrator must ensure that they meet the criteria for co-existence of elements (ISO26262-2018: Part 9, Clause 6).

Hope this helps,

Regards

-Aarul