Why do we need SOTIF?

Recently, I’m learning about SOTIF and I have many questions. So I thought that it would be a good if I ask a question to me and answer the question by myself. So the title is my 1st question. Why do we need SOTIF?

I guess many functional safety experts got lessons that ISO26262 is not enough to achieve functional safety. ISO26262 is a good standard to focus on E/E systems with safety requirements identifications by both hazard analysis/Risk Assessment and safety analysis.

But it is very hard to achieve safety if safety requirements are poorly identified, or safety engineers pretend that safety requirements identificatrion is finished even though it is not enough. SOTIF is in progress to cover this problem, but I’m not sure if it can be resolved….anyway.

By the way, I’d like to introduce CNS/ATM(Communication Navigation Surveillance/ Air Traffic Management) domain to get an insight how their functional safety related process are developed. To do this, I cite a paper whose title is “Evaluation of air traffic management procedures—safety assessment in an experimental environment”

The whole set of ATM services can be seen as a single system: there is a large number of elements (human and organizational actors, but also hardware components) and multiple interactions are taking place between them, with feedback loops and complex causal dependencies. What we deem relevant in this definition is the parallel with natural systems (as opposed to mechanical ones). A natural system is largely unpredictable (non-deterministic) and self-producing the causes of its own development. Each part has to be described on its own (because of its own peculiar behavior), but it is also necessary to refer to the interactions with other system’s elements. This causes the system behavior to be to a certain extent unpredictable and far from perfectly known. Unexpected interactions may occur and, in addition, the system behavior can be affected by external factors. In case of a local malfunction, failures are likely to spread very quickly to other parts of the system.

In this citation, ATM system consists of E/E system, operators, and operational process. To avoid a confusion about a term ‘system’, I will use it to refer “ATM system”. For “E/E system”, I will use “E/E element” instead.

A long time ago, there are many E/E elements in the CNS/ATM systems and they are not integrated. As there is a dramatic improvement in the computing technology, old-fashioned E/E can be smarter and they can be integrated. It essentially leads E/E element to take many activities that should be performed by human, and consequently leads to change operational process.

3 elements in the CNS/ATM system are E/E element, operational process, and operators(or human factor). As machines are getting smarter, there is a need to cover operational process and human factor to reduce catastrophic events. Advanced E/E can reduce accident by human factor by agumenting human’s situation awareness power.

In the CNS/ATM domain, there is a FuSa standard for E/E element, but there is also another standard for overall system. The process perspective, there is a hierarchy between the two. a standard for overall system is a higher than a standard for E/E element. That was a trend in the CNS/ATM system.

Back to Automotive, SOTIF is to cover operational process and human factor. So I thought that SOTIF will make higher layer of ISO26262 process. and I expected that SOTIF will make a higher process like a ConOps(operation concepts, or new driving procedures for automated driving) in the CNS/ATM.

But so far, the standard in progress is deviated from my thought. I will follow how their relation will be. Maybe, there is a reason that I don’t know.

(Paper comment) Toward a Framework for Highly Automated Vehicle Safety Validation

When I read this paper, I focus on the term “validation”. “Verification” is different “Validation”. Verification does not consider whether requirement is not wrong. It just checks if its implements meet its requirements. Weak point of verification can be revealed when the requirements are wrong or incomplete.

My colleague told a story that his customers asked to produce product. They gave a verified SW model and requirement. Even though it worked in the customers’ system architecture, it cannot be guaranteed that it also works in the new system architecture, obviously. He received verified model and verified again, but it failed eventually.

Automated vehicle requires new operation concept. In the CNS/ATM domain, they call it ConOps(Operation concepts). It is higher hierarchy than Item(system) development process. For convenience,  I’d like to distinguish terms with hierarchy.

Vehicle consists of many items. Item is a product that is developed by supplier.

Safety depends on ConOps. How can we validate safety? It means that how ConOps is matured.

And one more comment is that OEM should consider that vehicle accident can be  inevitable, then how OEM should avoid legal responsibility. Enough evidences shall tell that OEM has no fault.

Safety Analysis depends on what you contain in the Architecture. So…

Assuming that FMEA and FTA can be generated from Architecture(Sys/EE/SW), quality and depth of safety analysis depends on what you decide to cover in the architecture.

If your architecture is too detailed contents, then it would be labor intensive work. In the SW safety analysis, detailed SW safety analysis is not recommended. For example, ISO 26262 does not require that variable level fault mode has to be considered. If you refer to some papers, you can see such approaches. They always tell us that such task is time consuming work.

In the sense, granularity of architecture is so important. Because FMEA and FTA are different shapes of the diagram for chosen architecture view point, it is so important what kinds of view point has to be necessary.

If you refer to these safety analysis results to specify safety requirements, it will be clear why this requirement is safety related requirements.

While system in the automotive and aircraft vehicle focus on engineering methods to control vehicle, but socio-technical systems such as CNS/ATM system additionally requires related operation process. In this case, FTA and FMEA can enlarge to the operation process scope.

If you understand the principle, it can be applied to different domains.

Thus, important thing is how to determine what contents have to be contained, and how deep it has to be specified. It sounds like boring, but if you do not consider very carefully, you will have poor results even though you spend too much time.

In general, this consideration is functional safety manager’s role. On the contrary, functional safety engineer who knows deep knowledge about product would be hard these determination. Such person is apt to cover contents that does not have to be covered in the safety analysis.

So such policy is necessary. and it has to be determined by functional safety manager and agreed by related functional safety engineers. If there is no policy, you will face overlapped specification among system, SW and EE level.