Should a functional requirement to prevent unintended misuse of a product be developed as ASIL?

During the FuSa Connect, we had an interesting question from one of the functional safety managers. "I have functional requirements provided by the Customer for preventing foreseeable misuse by the driver. However, the OEM insists that I implement these with ASIL compliance. Aren't these requirements related to SOTIF? If so, should I implement them as ASIL? I also have a separate set of functional safety requirements/safety goals which needs to be implemented as ASIL" 

This is a valid question, because, quite often, requirements provided by OEM to prevent misuse may be crucial for the safe functioning of the ECU. However, from an other perspective, functional safety is focussed on internal E/E failures arising within the system and not necessarily on misuse of the item. 

We would like to answer this question by taking two different examples.

Example 1:

Analysis:

In this case, the OEM foresees that due to a partial blockage of the camera, it may lead to an incorrect detection of an object. For e.g., if even there is no object in front of the car, the blockage leads to interpreting some valid object in front of the car, which leads to provide a braking command. In such a case, the OEM foresees the misuse, directly violating the safety goals. 

Now, let’s tweak the Customer requirement for the above example as written below:

Analysis:

In this case, the OEM provides a requirement to deactivate the AEB feature if the camera is blocked. i.e., if the camera is partially or significantly blocked but diagnosed as not blocked, the AEB will be activated – this may lead to detecting an unintended activation of AEB (which itself is not a safety goal for this context) but it may also lead to a wrong object detection. If the camera is not blocked but detected as blocked, the AEB will be deactivated and notified to the driver – not a direct safety goal violation, only a loss of feature. 

Based on a deeper understanding of the camera blockage failure mode and its impact on object detection, it needs to be concluded if the misuse requirement can be implemented as ASIL or QM.

Example 2:

Analysis:

If the EPB switch is pulled up while the vehicle is moving at full speed, this can lead to applying full clamp force during driving and lead to sudden deceleration and loss of vehicle control, thereby directly violating the safety goal. Hence, such a requirement to disregard an accidental misuse of EPB switch must be considered safety relevant. In this case, the EPB switch pull request can be validated against vehicle speed, to ensure that it is considered only during vehicle static conditions and not when the vehicle is in movement.

Summary

The top-level Safety requirements for an ECU are typically always the functional safety requirements derived from the Safety goals. If OEM provides additional requirements (such as misuse related requirements) as ASIL, outside the scope of FSRs, it is useful to understand what is the intend of the Customer behind that. 

The Tier 1 needs to analyse the misuse requirements at a system level, if there is a possibility that there is a safety goal violation due to incorrect detection or implementation of a “Misuse”. It is possible that a misuse requirement comes from OEM as ASIL but Tier 1 concludes it as QM (based on internal safety analysis) or vice-versa. In either case, the Tier 1 needs to come to an alignment with the OEM – both technically and process wise. i.e., regarding the technical argumentation of the failure modes of misuse, as well as an alignment on the ASIL level of the requirements.