System vs System of systems; what are different?

When I was thinking about V2I or V2X, the motivation that led me to the concept of system of systems was just vaguely the system of systems (SoS),
Something like that term came up tremendously and made a huge system.
However, looking at this paper, my prejudice was completely shattered.

In fact it was a little shocking. This paper appeared a long time ago. Nevertheless, I couldn’t grasp the concept yet, so I still had a lot to learn.

First, I created a table to compare the system and SoS.

	System	SoS
characteristics	Each component is not considered to be a system individually.	Each of the components can be considered as a system individually, and each individual system can be managed independently from the operation.
controllability	controllable. Centralized	It is not fully controllable. Excessive attempts to control fail due to lack of authority.
plan	planned	evolutionary. There is no guarantee that system components will continue to cooperate. The system may initially flow in unintended directions.
operation and management independence	Components within the system scope cannot operate independently.	Components within the system scope can operate independently.
Key point in the architecture	components in the system	interfaces between systems

It was important to know whether the target was an ‘a system’ or a ‘a SoS (system of systems)’. If you think that the system is ‘a system’ and develop it, but the property of the system is ‘a SoS’
It is not possible to develop it sufficiently deliberately, so it can evolve in unexpected ways and cause the project to run out of control.
If the designer thought the target would be fully controllable, and development would have to be done in a collaborative manner, that would make the project very difficult.

The opposite is also true. If the individual components are independent and each moves cooperatively, but each has its own operating rights within the individual category, then it is not suitable for a centrally controlled model.

Also, if the related technology has not been developed yet, and if only the interface is made and the design is not designed in a way that allows any way, the related technology can be developed together with the details and the details can not be used when new technologies are released.

In the end, it is necessary to understand the property of the system to be developed in depth. If it is a system, it is planned and centrally controlled. If it is a system of systems, it should be developed as an evolutionary and cooperative model.

I think the distinction between the two must be understood to make a big system.

Back in v2x and v2I, mentioned in the introduction, do you think they should be concepts? Although we still need additional studies for the concrete concept, I think it would be better to see it as a cooperative model (hence a SoS).

Related papers: Architecting Principles for Systems-of-Systems (1998)

---

 

system of systems라는 개념에 관심을 두게 된 동기는 V2I나 V2X에 대해 생각해 봤을때, 그냥 막연하게 SoS(system of systems)라고 생각했었고,
뭔가 그 용어가 굉장히 거창하게 다가와서 거대한 시스템을 만드는 것 같은 느낌을 받았다.
하지만, 이 논문을 보고 내가 가진 편견은 완전히 산산조각이 났다.

사실 좀 충격이었다. 이 논문이 나온것은 굉장히 오래전에 나왔다. 그런데도 아직 개념을 못잡고 있는 것을 보니 아직도 배울게 많다는 생각이 들었다.

일단 시스템과 SoS를 비교할 수 있는 표를 만들어보았다.

	System	SoS
특징	구성요소 각각은 개별적으로 시스템으로 간주되지 않는다.	구성요소 각각은 개별적으로 시스템으로 간주될 수 있고, 각 개별 시스템은 운영 독립성과 독립적 관리의 특성을 갖는다.
제어가능성	통제 가능하다.	fully 통제 가능하지 않다. 과도한 통제 시도는 권한 부족으로 실패한다.
계획성	계획적이다.	진화적이다. 시스템 구성요소가 지속적 협력한다는 것을 보장하지 못함. 시스템이 초기에 의도하지 않은 방향으로도 흘러갈 수 있다.
운영 및 관리독립성	시스템 범위내의 구성요소들은 독립적으로 작동할 수 없다.	시스템 범위내의 시스템들은 독립적으로 작동할 수 있다.
관리의 중앙집중화	중앙집권적	보이지 않는 손에 의한 관리
아키텍처의 Key point	시스템 내의 컴포넌트	시스템들간의 인터페이스

 

그 target이 ‘a system’인지 아니면 ‘a SoS(system of systems)’인지를 파악하는 것이 중요함을 알았다. 만약 해당 시스템을 ‘a system’이라고 생각하고 개발을 했으나, 실제 해당 시스템의 속성이 ‘a SoS’라면
충분히 계획적으로 개발하는 것이 불가능하고, 그렇기에 예상치 못한 방향으로 진화가 되어 통제가 불가능하게 프로젝트가 폭주할 수가 있게 되는 것이다.
만약 설계자가 그 target이 fully controllable할 것으로 생각했는데, 그렇지 않고 협력적인 방식으로 개발이 이루어져야 한다면 그것도 프로젝트가 매우 어려워지게 되는 것이다.

그 반대도 마찬가지가 된다. 개별 컴포넌트가 독립적이고 각각이 상호 협력적으로 움직이되 개별 범주내에서는 독자적인 운영권한이 있게 된다면 중앙통제적인 모델에는 적합하지 않게 된다.

또한 아직 관련 기술이 개발되지 않아서 인터페이스만 만들어놓고 어떤 방식이든 허용하는 방향으로 설계를 하지 않고 관련 기술도 함께 개발하고 디테일 한 것 까지 세부적으로 개발을 하게 된다면 새로운 기술이 나올때 그것을 활용할 수 없게 된다.

결국 개발하고자 하는 시스템의 속성을 깊이 있게 파악을 해야 하며, 그것이 a system이면 계획적이면서 중앙통제적으로 개발을 하는 것이고, a system of systems이면 진화적이면서 상호협력적인 모델로 개발을 해야 하는 것이다.

그 둘의 구별은 큰 시스템을 만들려면 반드시 이해하고 있어야 한다고 생각한다.

서론에 언급했었던 v2x와 v2I로 돌아와서, 그렇다면 그들은 그럼 컨셉이 되어야 한다고 생각하는가? 비록 아직 구체적인 컨셉에 대해서는 추가적인 스터디가 필요할 것으로 생각하지만, 현재로서는 상호협력적 모델(그러므로 a SoS)로 보는게 더 낫지 않을까 생각한다.

관련 논문: Architecting Principles for Systems-of-Systems (1998)

 

system of systems라는 개념에 관심을 두게 된 배경은 V2I나 V2X가 되면 그냥 막연하게 system of systems라고 생각했었고, 뭔가 그 용어가 굉장히 거창하게 다가와서 거대한 시스템을 만드는 것 같은 느낌을 받았다. 하지만, 이 논문을 보고 내가 가진 편견은 완전히 산산조각이 났다.

사실 좀 충격이었다. 이 논문이 나온것은 굉장히 오래전에 나왔다. 그런데도 아직 개념을 못잡고 있는 것을 보니 아직도 배울게 많다는 생각이 들었다.

일단 시스템과 SoS를 비교할 수 있는 표를 만들어보았다.

설계자가 개발하고자 하는 범위에서 그 시스템이 a system인지 아니면 system of systems인지를 파악하는 것이 중요함을 알았다. 만약 해당 시스템을 a system이라고 생각하고 개발을 했으나, 실제 해당 시스템의 속성이 SoS라면 충분히 계획적으로 개발하는 것이 불가능하고, 그렇기에 예상치 못한 방향으로 진화가 되어 통제가 불가능하게 프로젝트가 폭주할 수가 있게 되는 것이다. fully controllable할 것으로 생각했는데, 그렇지 않고 협력적인 방식으로 개발이 이루어져야 한다면 그것도 프로젝트가 매우 어려워지게 되는 것이다.

그 반대도 마찬가지가 된다. 개별 컴포넌트가 독립적이고 각각이 상호 협력적으로 움직이되 개별 범주내에서는 독자적인 운영권한이 있게 된다면 중앙통제적인 모델에는 적합하지 않게 된다, 또한 아직 관련 기술이 개발되지 않아서 인터페이스만 만들어놓고 어떤 방식이든 허용하는 방향으로 설계를 하지 않고 관련 기술도 함께 개발하고 디테일 한 것 까지 세부적으로 개발을 하게 된다면 새로운 기술이 나올때 그것을 활용할 수 없게 된다.

결국 개발하고자 하는 시스템의 속성을 깊이 있게 파악을 해야 하며, 그것이 a system이면 계획적이면서 중앙통제적으로 개발을 하는 것이고, a system of systems이면 진화적이면서 상호협력적인 모델로 개발을 해야 하는 것이다.

그 둘의 구별은 큰 시스템을 만들려면 반드시 이해하고 있어야 한다고 생각한다.

서론에 언급했었던 v2x와 v2I는 그럼 무엇으로 보아야 할까? 그러고 보니 내가 v2I나 v2x에 대한 컨셉이 없다는 것을 알았다. 상호협력적 모델로 보는게 더 낫지 않을까 생각한다.

관련 논문: Architecting Principles for Systems-of-Systems (1998)

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

Guide to Functional Decomposition – ppt video online download

Contents What is functional decomposition? Why is functional decomposition used? When is functional decomposition used? How to perform functional decomposition A sample functional decomposition – step 1 A sample functional decomposition – step 2 A sample functional decomposition – step 3 What level to decompose functions to? Further assistance

소스: Guide to Functional Decomposition – ppt video online download

It is posed for functional FTA.