Category Archives: ISO 26262

(GRVA-06-02r4e) Uniform provisions Concerning the Approval of ALKS

Regulations on the Automated Lane Keeping Systems (ALKS) feature appear to be under discussion. There seems to be some difference from the regulation so far. In this document, evaluation by third-party organizations seems to be considered through the type certification procedure. There are statements in the Clause 7 of Annex D that Audit or Assessments are required by Auditor or Assessor with knowledge of ISO 26262, SOTIF and Cyber ​​Security.

I heard that a standardization trend in the Cyber ​​Security area presents a closer requirement to regulation. But looking at this document, it looks that FuSa and SOTIF are likely to follow a similar trend on topics related to ALKS.

As this policy is not yet decided, it may be considered to be quick, but we can prospect Audit/Assessment by 3rd party, which has been slightly loosened by the OEM, may be strengthened in the future.

On the regulatory side, there is some preparation, and on the side of defense, it seems to try hard to standardize through ISO standard activities and try to perform according to the standard as an approach of standard conformity.

This is an interesting change that was not found in functional safety in the past.

Click to access GRVA-06-02r4e.pdf

(paper comment) Analysis of Safety of The Intended Use(SOTIF)

This paper was published at the time of ISO/PAS 21448. I have never seen anything about ISO/PAS 21448. It is only known that the ongoing ISO 21448 will replace it. Looking at this paper, it seems that the earliest SOTIF focused on vehicle level safety. The ongoing ISO 21448 seems to cover not only the vehicle level, but also the entire lifecycle of FuSa’s systems, hw and sw. (That’s because the standard hasn’t been finalized yet, and I think it will be better later.)

When I first read the CD version of SOTIF, there were so many things that I didn’t understand and the relationship between FuSa and SOTIF wasn’t exactly understood. So it is dim to know that the concept of SOTIF is needed to achieve safety, but it was not clear. (I think it will be because it is still a CD version.)

However, after reading this paper, I came to understand the direction that SOTIF aims to pursue. Also, the concept of known/unknown and hazardous/non-hazardous models, which were newly introduced in SOTIF, couldn’t understand why the concept was introduced and how such a conceptual model could be practically used. For example, it was like this. Testing something in the Known domain is easy to understand, but what does it mean to test something in the Unknown domain? If you already have a test scenario, isn’t it supposed to be already known? What on earth does unknown mean?

Setting a validation target seems to use a statistical approach, but how can a quantitative figure be derived?

Of course, I am still not clearly understanding everything about SOTIF, but I am still studying. And what I realized now may be misunderstanding by’misunderstanding’, so my thoughts may change over time.

This paper contains examples of quantifying validation targets with the statistical approach mentioned above, and some explanations on how the concepts of known/unknown and hazardous/not hazardous apply.

Personally, I think the above two confusing concepts have been materialized through this paper. Of course, I’m still not sure how validation targets can be applied at the lower level, not at the vehicle level. It is expected that the standard will be more specific or practical examples will come from other papers.

It is worth reading this article to understand SOTIF. I think it will not be too difficult to understand

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