Category Archives: ARP 4754a

TMR(triple module redundancy) for fail operation


That’s when I was appointed as a reviewer for the UAV project. The project planned to design by TMR. At that time, I was thinking. ‘why does he design TMR? Is TMR a practically widely used design?’. At that time, I was going to ask you why there was a basis for that part, but unfortunately I missed that opportunity. And since that day, I kept on asking myself questions about this part, and I thought I would try to solve it someday.

I recently read a paper on fault tolerant and came up with the story I just mentioned. Throughout the paper, I have been interested in how it relates. And finally, I found a source that mentioned it directly today.

In conclusion, it was found that designing with TMR is not just research but practical design. The researcher’s plan was correct.

Perhaps if future autonomous cars need the fail operation attribute, those heavy designs in a fault tolerant will emerge. In recent fault tolerant papers, it appears that semiconductor companies are already preparing to support such attributes with strong computing power.

In the automotive side, it may be the day when triple redundancy is reflected in the design rather than dual redundancy. Not if you need to achieve fail safe, but if you need to accomplish a fail operation.

reference papers; The following papers are super. Recommend me if there are other good papers.

  • Design by Extrapolation; An Evaluation of Fault Tolerant Avionics
  • Fault Tolerant Computing: Fundamental Concepts
  • A novel approach to fault tolerant computing

내가 무인기 과제에 대한 과제 심사위원으로 위촉되었을 때의 일이다. 해당 과제에서는 TMR로 설계를 한다고 계획을 세웠다. 그때에 생각이, 왜 TMR오 디자인을 할까? 그게 실용적으로 널리 사용되는 디자인인가? 라는 생각을 했었다. 그 당시 그 부분에 대해서 어떤 근거가 있어서 그렇게 결정한 것인지 물어보려고 했었는데 안타깝게도 그 기회를 놓치고 말았다. 그리고 그날 이후로 이 부분에 대한 질문을 자신에게 계속하면서 마음속에 기억해 두었다가 언젠가는 해결해 볼 생각이었다.

최근에 fault tolerant에 대한 논문을 보다가 방금 언급한 스토리가 생각이 났다. 여러 논문을 보는 내내 그것이 어떻게 관련이 있을지에 대해서 관심을 가지고 읽게 되었다. 그리고, 드디어 오늘 그것에 대한 언급을 직접적으로 한 자료를 찾게 되었다.

그리고 결론적으로 TMR로 설계하는 것이 그저 연구만을 위한 연구가 아닌 실제적으로 사용되는 설계라는 것도 알게 되었다. 그 연구자의 계획이 맞았던 것이다.

아마도 미래의 자율 자동차가 fail operation 속성이 필요하게 된다면 fault tolerant에 있는 그런 무거운 디자인들이 나오게 되지 않을까 생각한다. 최근의 fault tolerant논문들을 찾아보니 이미 반도체 회사에서는 강력한 컴퓨팅파워를 바탕으로 그러한 속성들까지도 support하려고 준비중인 것으로 보인다.

자동차쪽에서도 dual redundancy가 아닌 triple redundancy가 설계에 반영되는 날이 올 수 있지 않을까 한다. fail safe를 달성해야 하는게 아니라 fail operation을 달성해야 한다면 말이다.

reference papers; 다음의 paper들은 정말 최고라고 생각하는 paper들이다. 다른 좋은 paper들이 있다면 추천해주기 바랍니다.

  • Design by Extrapolation; An Evaluation of Fault Tolerant Avionics
  • Fault Tolerant Computing: Fundamental Concepts
  • A novel approach to fault tolerant computing

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는 정말 훌륭한 도구이다.

(paper comment) Writing Good Technical Safety Requirements


It seems that a few people know how to specify safety requirements. The reason that I was surprised in the FuSa project was that many engineers don’t understand what our safety requirement shall be.

if you have a trouble with writing safety requirements, then this paper will give you a benefit how to start.

It is not enough though, but it is useful. Example in this paper helps you to understand better. but it is somewhat simplified, so it looks less practical.

reference

Specification of Safety Requirements

Functional safety project without safety requirement