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)
- Systems Engineering Design Through Failure Mode Avoidance: An Automotive Industry Perspective
- 2014-01-0740 A Systems Approach to the Development and Use of FMEA in Complex Automotive Applications
- 2011-01-1268 A Structured Approach for Function Analysis of Complex Automotive Systems
- 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와 관련된 참고자료(일부분만)
- Systems Engineering Design Through Failure Mode Avoidance: An Automotive Industry Perspective
- 2014-01-0740 A Systems Approach to the Development and Use of FMEA in Complex Automotive Applications
- 2011-01-1268 A Structured Approach for Function Analysis of Complex Automotive Systems
- 2009-01-0990 Implementing Failure Mode Avoidance
이런 concept을 실행하기 위해 medini도구를 사용하여 어느 정도는 구현하는 것이 가능하다. medini의 기능 중 일부분이 부족한 점이 있기는 하지만, 시스템 분석 단계에서 필요한 활동들은 어느정도 커버할 수 있다. 다른 도구는 사용해 본 적이 없어서 얼마나 유용한지는 모르겠지만, medini는 정말 훌륭한 도구이다.
