Category Archives: 07. Validation

Fault injection test vs safety analysis


What do you think the purpose of the fault injection test is? Why do safety analysis?

Why do I talk these two together? Of course they are related.

In conclusion, the list or type of faults required in the fault injection test and the location and timing of the fault injection should be based on the results obtained during the safety analysis.

Suppose we have identified a list of faults that affect the safety performed in the safety analysis, and we have identified how to handle such faults as safety requirements (we call this the safety mechanism).

How can you verify them? Naturally, you will have to create a condition for the safety requirement to become active, which is the situation where the fault is injected.

So the two are related.


fault injection test의 목적이 무엇이라고 생각하는가? safety analysis는 왜 하는가? 왜 나는 이 둘을 엮을라고 하는 것인가? 당연히 관련성이 있기 때문에 그런 것이다

결론을 말하면 fault injection test에서 필요한 fault의 list나 type 및 fault를 injection하는 위치나 시점 등은 safety analysis에서 수행하는 동안 얻은 결과를 바탕으로 해야 한다.

safety analysis에서 수행한 안전에 영향을 끼치는 fault list를 식별을 했고, 그런 fault들을 처리하는 방법을 안전 요구사항으로 식별했다고 치자(우리는 이것을 안전 매커니즘이라고 부른다.)

여기서 그 안전 매커니즘에 대한 검증을 어떻게 할 것인가? 당연히 safety requirement가 활성화되기 위한 조건을 만들어줘야 할 것이다, 그것이 바로 fault가 inject된 상황이 된다.

그래서 둘은 이렇게 연관이 있다.

Failure Mode Avoidance


It is a framework for developing systematic system modeling, safety analysis and safety mechanisms. If you search the data, you will find several papers. Interested in the overall content of this framework, detailed data were not available, so that the whole was not understood.

For a complete picture, see the data at
https://www.through-life-engineering-services.org/downloads/campean.pdf.

If you look at this data you can get a sense of the approximate flow.

In the figure below, there are four steps, and the first step is to analyze the function. To do this, define the state of the system at the top level, identify the environment involved, and define the interface. Based on this analysis, we create a function decomposition tree. Personally, I have used function decomposition from other sources, and when I looked at the paper, I thought it was a good practice.

State flow diagrams may be hierarchical diagram in the stateflows or in the statecharts. Another useful point here is interface analysis and boundary analysis. It may not be necessary if you analyze and develop the system by yourself, but if you need to work together, I think it is necessary.

Surprisingly, other people’s minds are not the same as mys, and if you pretend that they are clearly defined in scope, others are often not. Therefore, it is necessary to define clearly. It is also needed to split the system up and hand it over to another department. At this point, what matters is the boundaries, clearly defining what is ambiguous, and therefore need an interface.

Based on these analyzes, we define the decomposition of the function. Functions can be considered as requirements. This enables the representation of requirements and system components to which they are assigned. In this case, if the system function is complicated, it can be expressed hierarchically and expressed in multi level instead of one level. In other words, if the system architecture is organized hierarchically, it is much clearer and more intuitive to configure the corresponding requirements hierarchically. Of course, you will also need to define interfaces for each layer.

That’s the first stage of functional analysis,

Next is the functional failure analysis phase, FMEA. The FMEA is taken at the same hierarchy level as the previous step. Then, in step n, the influence on the failure mode of the element E is configured to be associated with the failure mode of the upper element E_upper in step n-1. That way the FMEA can be configured to allow the fault to be propagated.

This is what I found through FMA and I haven’t confirmed any details since P diagram.

FMA-related papers(not exhaustive)

  1. Systems Engineering Design Through Failure Mode Avoidance: An Automotive Industry Perspective
  2. 2014-01-0740 A Systems Approach to the Development and Use of FMEA in Complex Automotive Applications
  3. 2011-01-1268 A Structured Approach for Function Analysis of Complex Automotive Systems
  4. 2009-01-0990 Implementing Failure Mode Avoidance

To implement this concept it is possible to implement to some extent using the medini tool. Although some of medini’s features are lacking, some of the activities needed during the system analysis phase can be covered. I don’t know how useful other tools are, so medini is a great tool.

 

 

 

FMA는 체계적인 시스템 모델링 및 안전분석, 안전 매커니즘을 개발하기 위한 프레임워크이다. 자료를 검색해보면 여러 paper들이 나온다. 이 framework에 대한 전반적인 내용에 관심이 생겼으나, 자세하게 다룬 자료는 구하지 못해서 전체적인 것을 파악하지는 못하였다.

전체적인 그림은 https://www.through-life-engineering-services.org/downloads/campean.pdf에 있는 자료를 보면 대략적인 flow는 감을 잡을 수 있을 것이다.

아래 그림을 보면 4 단계로 이루어져 있고, 첫번째는 기능을 분석하는 단계이다. 이것을 위해서 top level에서 시스템의 상태를 정의하고, 관련 환경을 파악하고 인터페이스를 정의한다. 그리고 이 분석한 내용을 바탕으로 function decomposition tree를 만든다. 개인적으로 다른 자료를 통해 function decomposition을 활용해 봤고, 그 논문을 봤을때부터 이건 괜찮은 practice라고 생각을 했었다.

state flow diagram은 아마도 stateflow나 statecharts로 hierarchical하게 표현을 해도 괜찮을 것이다. 여기서 또 유용하다고 생각되는 점은 interface analysis와 boundary analysis이다. 혼자 시스템을 분석하고 개발한다면 굳이 필요하지는 않을지도 모르나, 여럿이서 협업을 해야 한다면 반드시 필요한 작업이라고 생각된다,

의외로 다른 사람의 마음은 내 마음과 같지 않고, 척하면 범위가 명확하게 정의가 되었다고 생각하는데, 다른 사람들은 그렇지 않을 때도 많다. 그렇기 때문에 명확하게 정의하는 것이 필요하다. 시스템을 쪼개서 다른 부서에 넘겨줄 때에도 필요하다. 이 때에 중요한 것이 경계상에 있는 것들이다, 애매할 수 있는 것들을 명확하게 정의해야 하고, 그런 이유로 인터페이스가 필요하다.

이런 분석들을 기반으로 기능에 대한 decomposition을 정의한다. 기능은 요구사항으로 간주할 수 있다. 그렇게 되면, 요구사항과 그 요구사항이 할당된 시스템 구성요소를 표현할 수 있게 된다. 여기서 시스템의 기능이 복잡한 경우 하나의 수준으로 표현하지 않고 계층적으로 구성해서 multi level로 표현할 수 있다. 즉, 시스템 아키텍처를 계층적으로 구성한다면 그에 걸맞는 요구사항도 계층적으로 구성하는 것이 훨신 명확하고 직관적이다. 물론 각 계층마다 인터페이스에 대한 정의도 필요할 것이다.

여기까지가 첫번째 단계인 기능 분석 단계이다,

다음으로는 기능 고장 분석단계인데, FMEA이다. FMEA는 이전 단계에서 수행했던 계층 수준과 동일하게 가져간다. 그리고, n단계에서 어떤 엘리먼트 E의 고장 모드에 대한 영향이 n-1단계의 상위 엘리먼트 E_upper의 고장 모드와 연계되도록 구성한다. 그런식으로 fault가 propagation될 수 있도록 FMEA가 구성될 수 있도록 분석을 한다.

여기까지가 내가 FMA를 통해 파악한 내용이고 P diagram이후부터는 아직 구체적인 내용을 확인하지 못했다.

FMA와 관련된 참고자료(일부분만)

  1. Systems Engineering Design Through Failure Mode Avoidance: An Automotive Industry Perspective
  2. 2014-01-0740 A Systems Approach to the Development and Use of FMEA in Complex Automotive Applications
  3. 2011-01-1268 A Structured Approach for Function Analysis of Complex Automotive Systems
  4. 2009-01-0990 Implementing Failure Mode Avoidance

이런 concept을 실행하기 위해 medini도구를 사용하여 어느 정도는 구현하는 것이 가능하다. medini의 기능 중 일부분이 부족한 점이 있기는 하지만, 시스템 분석 단계에서 필요한 활동들은 어느정도 커버할 수 있다. 다른 도구는 사용해 본 적이 없어서 얼마나 유용한지는 모르겠지만, medini는 정말 훌륭한 도구이다.

SW partitioning – why do you try to implement it?


SW partitioning is seems to be a very useful approach to decompose ASIL in SW. I understand that if it is implemented, some SW parts can be excluded in the FuSa scope. But I have a different point of view. My question is that is it really give us benefit to reduce our resources?

Regarding to applying SW partitioning, its motivation is to reduce resource. It was my involved project’s interest. If some SW components are excluded as QM, then we have reduced scope for FuSa, and it is benefit to us. When I heard its trials, it sounds good, but I realized that its result would not be good. I’ll tell you what should be considered additionally.

Let’s assume that we should apply a watchdog. It requires many technical consideration and it does not mean just add watchdog in a circuit. Even if watchdog is added, main purposes cannot be achieved if it is not implemented smartly. (reference; proper watchdog timer use in Korean)

Similarly if we implement SW partitioning, design should be verified. At least, task scheduling plan should be specified in a SW design, its design should be reviewed, and its effectiveness should be tested during or after SW integration.

if critical faults occur in a QM side, it shall be ensured that OS catches such exceptions and manages as we intended. it is one side of SW partitioning.

The other consideration is a space partition. A SW component in one partition can try to access memory region or resources that are allocated to other partition. In this case, it shall be ensured that such trials are not succeed. And such trials are invalid, exceptions or any error events should be triggered. Then exception handling should be considered. How will you do if such exceptions are occured? SW reset? Are you sure?

For now, I don’t think that SW partitioning will save our resource. It is a safety design concept, not a method to save our resources. But I may change my mind if I will experience more, but this idea is my latest idea for SW partitioning.