2. Structure of Complex systems

1. Hierarchy of complex systems

 

우리는 Complex system의 한가지 Model을 정의할 것이다.

계층적 구조로 다음과 같고, 상위 요소는 하위 요소들로 분할가능하다.

Hierarchy	Example
Systems	Communication system, Information system, Aerospace system
Subsystems	Signal Network, Database, Engines
Components	Signal Receiver, Data display, Data programs, Thrust generator
Subcomponents	Signal amplifier, Library utilities, Reactive valve, Rocket nozzles
Parts	Transformer, LED, Algorithms, Coupling, Seals

 

여기서 Component는 system engineering process에서 중심적인 역할을 한다.

Component는 각 domain의 design specialist들에 의해 구현된다. 하지만 System engineer는 각각의 Component들을 정의하고, 그것의 performance, compatible interface들을 정의하는 역할을 한다. 따라서, System engineer은 Component level의 이해를 가지고 있어야 한다. 이렇게 영역이 overlap되는 component level은 system engineer와 design specialist가 효과적으로 communication하는 부분이다.

 

2. System building blocks

 

우리는 System을 기능적관점에서 Functional building block으로 decomposition할 수 있고, 물리적 관점에서 Hhysical building block으로 decomposition할 수 있다. Functional building block은 Signal elements, Data elements, Material elements, Energy element 로 분류될 수 있다.

예를 들어, Signal elements에는 Input signal, Receive signal, Transmit Signal 등등이 있고, Data elements에는 Input data, Control data, Control processing, Control system 등이 있다.

이러한 building block이 되기 위해서는 다음의 3가지 기준을 충족해야 한다.

 

Significance : 구분되고 중요한 기능을 수행해야 한다.

Singuarity : 하나의 기술적인 엔지니어링 영역이 될 수 있어야 한다

Commonality : 다양한 시스템에서 발견되는 기능이여야 한다

 

Physical building block은 complex system hierarchy에서 Component에 해당하며, 하나의 component는 하나의 functional building block에 mapping된다. 따라서, Component는 동일하게 Significance, Singuarity, Commonality를 만족시켜야 한다. 예를 들어, Component인 Operating System은 Data elements로 분류되는 Functional elements인 Control system에 mapping된다.

 

이렇듯 Component가 system engineering의 basic system building block으로서 중심적인 역할을 하기 때문에, 우리는 System의 physical, functional attribute들을 이해하고 그것을 명확하게 identification하는 것이 중요하다.

 

3. System Environment

 

System environment란 시스템과 상요작용하는 외부의 모든것들로 정의된다. 따라서, System boundary를 명확하게 설정해야 시스템 외부인지 내부인지를 명확히 구분할 수 있을 것이다.

 

이를 구분지을 수 있는 몇가지 기준이 있다.

 

Development control : 시스템 개발자가 Entity의 개발을 통제할 수 있는가?

Operational control : Entity가 시스템을 control하는 구성에 포함되어 control되는가? 

Functional allocation : 시스템 엔지니어가 Entity에 기능을 할당하는 것이 허용되는가?

Unity of purpose :  Entity가 시스템의 성공에 전념하는가?

 

대부분의 경우에, user와 operator는 외부의 Entity로 간주된다.

 

Context Diagram은 system engineering과정에서 의사소통을 위한 하나의 도구로서 사용가능하다. 이것은 External entities, Interactions, System 으로 구성된다. Interaction은 Data, Signals, Materials, Energy, Activities 로 분류될 수 있다.

 

위의 모델을 사용하여, Context diagram을 그림으로서 외부와 시스템의 상호작용을 표현할 수 있다.

Interaction의 경우, primary interaction, secondary interaction으로 구분할 수도 있다.

primary interation은 environment가 input/output/human control interface인 것이다. secondary interaction은 indirect interaction이 일어나는 것이다.

 

4. Interfaces and Interactions

 

System environment와 interaction하는 boundary를 external interface라고 한다.

반면, component들끼리 interaction하는 boundary를 interal interface라고 한다.

 

이러한 Interface의 정의는 system engineer의 역할이다.

한가지 중요하게 다루어져야하지만, 간과되는 것은 시스템 유지보수하는 동안에 발생하는 외부와의 상호작용이다. 이것은 테스트 목적의 중요한 기능들에 대한 접근을 요구한다. 이러한 Interface의 정의도 고려되어야 한다.

 

Interface는 다음과 같이 분류될 수 있다.

Connector : 전기, 유체, 힘 등을 전달함

Isolator : 상호작용을 제한함

Convertor : 상호작용 매개체의 형태를 변화시킴

 

여기에는 몇가지 중요한 특징들이 있다. 

1) Connection을 맺고 끝는 기능은 중요한 디자인 요소이다.

2) 인접하지 않은 Component들을 연결하는 cable, pipe 등을 component가 아니다.

3) Interface의 relative simplicity는 시스템의 performance, reliability를 위한 매우 중요한 요소이다.

 

5. Complexity in modern systems

 

현대의 system engineering은 complexity를 다루기 위해 고안되었다. System of System(SoS)는 US Department of Defence로부터 왔다. 이것은 시스템들을 하나로 모은 시스템의 집합이다. 이것보다 상위의 level로 enterprise가 있다. Enterprise로 engineering의 대상으로 본 enterprise system engineering은 다양한 시스템과 프로세스를 통합하는 것을 목표로 한다. 이것은 System of System의 통합으로 간주할 수 있다.