Considering Safety Requirements

I understand that SOTIF came out to make up for the deficiencies of FuSa. I hope that there is no overlap or contradiction or omission between the two and they are used to achieve overall safety.

Recently I read such a similar meanings in the FuSa and SOTIF, that is the purpose of FuSa is to cover random hardware faults and systematic faults and SOTIF is to cover limitation of performance that leads to accident.

Regarding it, I had questions about identifying safety requirements.
Question 1) What safety requirements in the FuSa means?
Question 2) What is the difference between FuSa safety requirements and SOTIF safety requirement?
Question 3) What can be happened if we apply FuSa only and if we neglect SOTIF?

I checked 2nd edition of ISO 26262-4 to find out what safety requirements specification means. In the system development process, TSRs are derived from FSR. Then what if FSR is not offered from OEM? What if FSRs consist of very general requirements that are not requirements for the product, but requirements for the process?

Or what if OEM demands to apply FuSa, but the product that supplier provide is a sub-system level and supplier does not receive any information except safety goal in the item level. the supplier does not know how the item behaves.

In fact, I had experienced both cases in a company before. What would be possible answer if we apply FuSa only (i.e. we do not consider SOTIF)

I’d like to point out that we should consider safety attribute that the product has. Safety attribute can be varied if the products (that the supplier provides) are differently used in the vehice level.

Even the same function may or may not be a safety requirement depending on how it is used at the vehicle level. If the radar sensing value is used for braking or steering, the radar sensing-related functions should be safety-related functions, even if such requirements are not in the FSR. If the radar sensing value is used to provide a warning to the user, the radar sensing-related functions are not safety related. We will not identify such safety requirements if there are no such safety requirements in the FSRs.

OEMs would like to write this requirement on the FSR, but even if they don’t, the supplier should be able to distinguish which functions of their products are safety related. It would be nice to get an FSR from OEM, but I think it’s problematic to miss the requirement to identify it as a safety attribute if it doesn’t.

In this situation, What does mean to apply only FuSa (and to neglect SOTIF) means?

It is the conclusion of my thoughts. I think it would be possible to apply it in such a crappy way.
1) If the OEM does not create an FSR and only has an SG

Supplier can choose to perform safety anlaysis in the System, HW, and SW level and related safety mechanisms are listed up. It can be argued that specification of safety requirements have been fulfilled. (Of course, if I’m a demanding examiner of an OEM or a certifier/regulator examiner, I’ll reject it right away.)

2) If the OEM directly sourcing the product corresponding to the sub-system of the item, SG is the item level and ASIL’s decomposed ASIL is assigned to the sub-system, but there are no related requirements…Hardware architecture metric It meets the FIT for ASIL, adds some safety mechanisms, and only conforms to the process for ASIL. (I don’t think that it is a good practice for the supplier)

I think the above two cases are actually applied by the supplier in a wrong way that is not enough to achieve safety.

I posted specification of safety requirements in the blog in the past, but I realized that the practice that I posted expands scope than FuSa.

Related post: Specification of safety requirements