시스템 단계와 모드 및 작동상태

지난 호에서 논의된 시스템 운용 모델은 사용자가 조직 임무를 수행하기 위한 시스템이나 제품을 어떻게 배치하고 운용하며 지원하는가를 보여주는 업무 흐름을 제공해 준다. 일반적으로 이러한 업무 흐름은 수행되어야 할 두 가지 또는 그 이상의 업무를 목표에 근거한 순차적 및 동시적 작동으로 구성되어 있다. 이러한 업무는 순차적으로 하부업무로 나누어진다.
보다 깊이 시스템 운용 모델을 살펴보면, 세 가지 대상 시스템(SOI) 작동 유형으로 구성되어 있음을 알 수 있다. (1) 임무 준비, (2) 임무 수행 및 지원, (3) 임무 수행 이후 조치이다. 이러한 대상 시스템 작동은 임무 시스템과 지원 시스템의 통합 노력으로 수행된다.
시스템이 야전에 배치될 때, 사용자는 운용단계에서 사용자 지침, 참조 매뉴얼, 그리고 체크리스트 절차를 이용해서 시스템, 제품 및 서비스를 어떻게 할 것인가를 포함한 시스템 작동을 위한 기초를 배워야 한다.
수행되어야 할 목표로 나타낸 각 운용단계는 내장된 운용 모드로 구성되어 있다. 각 운용 모드는 특정 임무 작동과 업무를 수행하기 위하여 사용자가 선정한 옵션을 나타낸다. 나아가 사용자는 이러한 운용과 업무를 지원하기 위한 장비 능력, 안전 운용절차, 성능 제한사항을 함께 알아야 한다. 사용자가 바라는 것은 시스템 개발 결과이지만, 시스템 엔지니어링 설계 프로세스가 이러한 결과를 가져오기 위해 수많은 반복 절차와 수많은 시간을 요하는 분석, 그리고 의사결정 프로세스를 사용자는 이해하려 하지 않는다.
이 글에서의 논의 대상은 시스템 단계, 모드 및 작동 상태에 대한 개념을 소개함에 있다. 다음과 같은 시스템 엔지니어의 노력을 통해 유스 케이스, 유스 케이스 시나리오 그리고 시스템 운용 모델 형성의 기초를 만들어 간다.

· 운용단계를 설정한다.
· 유스 케이스로부터 운용모드를 도출한다.
· 시스템 아키텍처 형상과 시스템 운용상태를 나타내는 인터페이스를 도출한다.

한 시스템이 어떻게 구성되어 있는지에 대한 기초를 통해 시스템 운용단계 상호간 그리고 그 내에서 모드 전환이 어떻게 일어나고 있는지를 알아내어야 한다. 최종적으로 모드별 능력이 물리적 형상으로 통합되고 축적되는지 또는 사용자 단계별 목표를 지원하기 위하여 그 아키텍처의 상태를 제시해야 한다.

1. 얻고자 하는 내용

· 운용단계란 무엇인가?
· 임무수행 이전 운용단계 목표는 무엇인가?
· 임무수행 중 운용단계 목표는 무엇인가?
· 임무수행 이후 운용단계 목표는 무엇인가?
· 운용모드란 무엇인가?
· 운용상태란 무엇인가?
· 운용상태와 물리적 상태 간 차이점은 무엇인가?
· 운용단계, 모드 및 상태 상호간 관계란 무엇인가?
· 유스 케이스와 시나리오는 운용모드와 무슨 관계가 있는가?
· 모드를 나타내는 이벤트란 무엇인가?

2. 주요 용어 정의

· 운용모드(Operational Mode) : 특정 단계 목표 달성에 초점을 둔 시스템 운용 능력과 활동 수집에 적용된 추상적인 라벨
· 운용단계(Phase of Operation) : 앞서 시스템 임무분석에서 제공된 정의 참조.
· 운용상태(State of Operation) : 주어진 임무를 안전하게 수행하거나 지속하는 데 필요한 대상 시스템의 운용 또는 작동 시 상태. 예를 들면, 항공기 착륙 시 운용상태는 날게 플랩 상승, 랜딩기어 하강, 랜딩 등 작동과 같은 아키텍처 형상 세팅을 포함한다.
· 상태(State) : “시스템, 컴포넌트, 또는 시뮬레이션이 예를 들면, 항공기 비행 전 상태에서의 항법 프로그램 또는 주어진 채널에서의 입력 상태와 같이 주어진 조건이나 존재하고 있는 모드.” (근거 : IEEE 610.12-1990)
· 상태도(State Diagram) : “한 시스템이나 컴포넌트가 가정할 수 있고, 한 상태에서 다른 상태로 변경할 때 나타나는 결과의 원인이 되는 분위기나 이벤트를 가리킨다.” (근거: IEEE 610.12-1990) 상태도는 상태 전이도라고도 부른다.
· 상태 머신(State Machine) : 조건이나 외부적인 촉발 이벤트(External Triggering Event)가 다른 형상 상태로 전이토록 할 때까지 작동이나 업무를 수행하기 위해 주어진 형상 상태를 적용하는 기기.
· 촉발 이벤트(Triggering Event) : 한 시스템이 현재 모드로부터 새로운 작동 모드로 옮겨가기 위해 거동 반응 발생 원인이 되는 외부적인 운용환경 자극 또는 신호.

시스템 단계와 모드 및 상태 관계

시스템 단계, 모드, 상태에 관하여 좀 더 자세히 알아보기 위해 그림 1에 나타난 속성 관계 구조를 사용해 보도록 하자. 그림 1과 같은 절차는 시스템 복잡도에 따라 매우 시간적 낭비를 초래하는 고도의 반복적인 시스템 단계, 모드, 상태 분석 과정을 수행해야 한다고 볼 수 있다. 그러나 운용의 하부단계와 하부모드 목록을 참조하게 되면 이와 같은 경우를 극복할 수 있다.



각 단계를 보다 잘 이해할 수 있도록 단계별 목적을 다음과 같이 실례로 제시해 본다.

1. 운용단계(1)
· 단계는 하나 또는 그 이상의 운용모드로 구성되어 있다(2).
· 최소한 하나 또는 그 이상의 유스 케이스 적용을 허용한다(3).
· 둘 또는 그 이상의 운용 하부모드를 구성해도 좋다(4).

2. 각 운용 하부모드(4), 적용 시
· 상위레벨 운용단계 요소(1)
· 최소한 하나 또는 그 이상의 유스 케이스를 수용한다(3).
· 최소한 하나 또는 그 이상의 운용모드에 의해 지원 된다(2).

3. 각 유스 케이스(3)
· 최소한 하나 또는 그 이상의 운용단계 적용을 허용한다(1).
· 하나 또는 그 이상의 상위레벨 운용모드(2) 또는 운용 하부모드(5)로 추상적으로 분석되어야 한다(5).
· 하나 또는 그 이상의 물리적 형상을 요구해도 좋다(7).

4. 각 운용모드(2)
· 하나 및 유일한 고유의 운용단계이다(1).
· 하나 또는 그 이상의 유스 케이스를 수용한다(3).
· 최소한 하나 또는 그 이상의 물리적 형상에 의해 지원된다(7).

5. 각 운용 하부모드(적용 시)
· 하나 또는 유일한 운용모드를 가진다(2).
· 최소한 하나 또는 그 이상의 유스 케이스를 수용한다(3).
· 최소한 하나 또는 그 이상의 운용상태에 의해 지원된다(6).

6. 각 운용상태(6)
· 최소한 하나 또는 그 이상의 운용모드(2) 또는 운용 하부모드(5)를 지원한다.
· 최소한 하나 또는 그 이상의 물리적 형상으로 구성된다(7).

7. 각 물리적 형상(7)
· 시스템/품목 아키텍처, 인터페이스 및 세팅에 의해 특성화된다.
· 고유의 운용상태를 지니고 있다(6).
· 최소한 하나 또는 그 이상의 유스 케이스를 적용한다(3).

지금까지 우리의 초점은 시스템 운용단계, 모드, 상태이기 때문에 그림 1은 이러한 요소들로 제시되어 있다. 앞으로 시스템 운용능력 도출과 할당에서 제시하겠지만, 유스 케이스와 모드 그리고 상태 사이의 연결과 물리적 형상상태(예를 들면, 물리적 설계 솔루션)는 성능 요구사항으로 나타날 요구 운용능력을 통해 이행된다.
단계, 모드, 상태란 가끔 사람들이 이를 혼동해서 제시하고 있기 때문에 매우 복잡한 결과를 초래하고 있다. 따라서 우리는 요구 운용능력 차원의 논의를 나중에 하려고 한다.
이러한 속성 관계 구조를 기본으로 시스템 운용단계부터 논의해 보도록 하자.

시스템 운용단계

우리는 시스템 운용 모델에 대한 논의를 통해 어떻게 인공 시스템이 전형적으로 운용되는지를 이해하기 위한 주요 개념을 소개했다.
그림 1과 그림 2에서 제시된 운용은 초기 시스템 엔지니어링 설계 개발과 마찬가지로 시스템 운용능력 요구사항을 수집하고 체계화하는데 초기 구조를 제시해 주고 있다. 이제 단계와 운용에 관한 상호관계를 살펴보자.



1. 운용단계 목표
만일 우리가 시스템 작동과 그 목표 세트를 분석한다면, 우리는 작동을 임무수행 전, 수행 중, 수행 후 세 가지 추상적인 단계로 분류하게 된다. 우리는 이를 운용단계라는 추상적 개념을 적용하게 된다.
모든 인공 시스템은 최소한 세 가지 운용단계를 가지고 있다. 어느 시스템이 저장 상태에 있다 할지라도, 운용 용어로는 이를 ‘운용ʼ이라고 표현한다는 사실을 유의하도록 하라. 시스템이 활동하지 않고 있다 할지라도 저장이란 시스템으로 임무를 수행하고 있는 활동으로 표현된다. 그러나 이는 작동으로 볼 수는 없다.

① 임무수행 전 단계 목표 : 임무수행 전 단계 목표는 최소한 임무 시스템과 지원 시스템으로 구성된 대상 시스템이 온전하게 준비, 설계, 작동할 수 있으며 체계적인 임무수행 준비가 되어 있는가를 확인함에 있다.
② 임무수행 중 단계 목표 : 임무수행 중 단계 목표는 최소한 대상 시스템의 임무를 수행함에 있다. 대상 시스템의 임무 목표를 달성하는 것 외에 우리는 임무 위험을 완화해야 하며 시스템이 안전하고 복원할 수 있도록 확인해야 한다.
③ 임무수행 후 단계 목표 : 임무수행 후 단계 목표는 최소한 다음 사항을 수행해야 한다.
· 임무수행 산출물과 성능 목표 달성 결과를 분석
· 필요시 시스템 소모품과 소비 품목을 보충
· 시스템 보완
· 교훈 제시
· 임무 결과를 분석 및 요약
· 향후 시스템과 임무 성능 향상

어떻게 운용단계가 시스템에 적용되고 있는지를 보기 위해 다음 자동차 여행을 예제로 살펴보자.

<예제 1>
(1) 자동차 여행을 떠나기 전, 임무수행 전 단계에서 운전자는 다음 사항을 수행한다.

· 자동차 서비스 (오일 및 필터 교환, 타이어교체, 수리 등) 제공
· 탱크에 연료 주유
· 타이어 압력 체크
· 자동차 검사
· 자동차에 필요한 짐(가방, 옷 등) 싣기

(2) 성공적인 임무수행 전 단계를 이행한 후 다음 자동차 주행단계를 위해 운전자는 다음 사항을 수행한다.

· 출발점에서 여행을 시작
· 자동차 안전운행 절차에 따라 방어운전 수행
· 자동차 법규 이행
· 목적지 방향으로 운행
· 연료와 냉각수를 주기적으로 체크 및 보충
· 목적지 도착

(3) 목적지에 도달한 후, 임무수행 후에 운전자는 다음 사항을 수행한다.

· 허용 장소에 자동차 주차
· 자동차에서 짐 내리기
· 다시 사용할 때까지 안전하게 잠금

2. 운용 하부단계
일부 복합 시스템은 운용 하부단계로 분할될 수 있다. 항공기와 미사일과 같은 항공 시스템은 임무단계 내에서 비행단계를 볼 수 있다. 항공기 시스템의 비행단계는 1) 후방이동, 2) 택시, 3) 이륙, 4) 비상, 5) 항해, 6) 하강, 7) 착륙, 8) 택시, 및 9) 주차 하부단계를 포함하고 있다.
참고로 운용단계를 사용한다면, 비행단계는 운용 임무 수행단계의 하부단계이다. 각 하부 단계는 전반적인 항공기의 출발지점으로부터 도착지점까지 승객을 안전하게 이동하는 시스템 목표에 기여하는 특정 목표에 초점을 두고 있다.
한번 시스템 운용 단계가 설정되고 나면, 우리는 각 단계의 유스 케이스를 서로 맞추어 진행할 수 있다.

3. 유스 케이스를 시스템 운용단계와 맞추기
시스템 유스 케이스가 식별되고 나면, 시스템 엔지니어는 표 1에 나타난 특정 운용단계로 유스 케이스를 정렬해야 한다.

시스템 운용모드

작동면에서 운용모드란 특정 조건과 기준이 주어져 있다고 가정한 상태에서 사용자 관점에서 선정 가능한 옵션을 말한다. 다음 예제를 살펴보자.

<예제 2>
자동차 운전자가 특정 조건과 기준이 주어져 있다고 가정한 상태에서 다음과 같은 분명하게 선정 가능한 운용모드를 볼 수 있다. 주차, 후진, 중립, 전진, 저속 모드이다. 만일 자동차가 운전모드로 주어졌다고 할 때, 운전자는 다음과 같은 조건과 기준을 충족할 때 후진 모드로 옮길 수 있도록 자동차 설계가 되어야 한다.

· 자동차가 자동차 법규 및 안전규정에 따라 안전한 가용장소에 있다.
· 자동차가 안전하게 정지되고 브레이크 페달을 밟고 있다.
· 운전자는 모든 방향으로부터 접근하고 있는 교통 상황을 볼 수 있다.
· 그 활동이 다른 차가 오기 전에 안전하게 완료될 수 있다.

1. 운용모드 도출
우리가 특정 운용단계로 맞추어진 유스 케이스를 분석할 때, 이 유스 케이스는 목표 또는 산출물을 서로 공유할 수 있다는 것을 곧 알 수 있다. 목표를 서로 공유할 수 있는 세트나 유스 케이스 묶음으로 충분한 공통성이 있다고 하는 곳에 우리는 이를 상위레벨 운용모드로 구상하게 된다. 그림 2는 유스 케이스(UCs)가 어떻게 운용모드로 구상되는지를 보여주고 있다.
당신은 상위레벨 모드로 더 추상화될 수 있는 모드가 있을 수 있다는 사실을 보게 된다. 만일 이러한 경우라면, 우리는 모드 계층구조를 설정하여 운용모드의 하부모드로 지정할 수 있다. 간단하게 보면, 모든 유스 케이스는 그림 2에서와 같이 동일레벨에 놓여 있다고 가정한다.
운용모드를 식별하기 위한 특별한 지침이 없는 경우가 있다. 이러한 경우 동일한 수의 시스템 엔지니어링 분석가와 개발자로 구성된 별개의 독립적인 팀으로 하여금 사용자 능력과 성능 요구사항 세트로 나타나는 시스템이나 제품을 가정해서 설계하고 생산할 수 있다. 각 팀은 서로 다른 시스템 운용모드로 구상해도 좋다. 주요한 점은 시스템 단계와 운용모드에 관하여 팀 내에서 일치된 의견을 만들고 이해하며 인식하는 방법을 배우는 데 있다. 그리고 팀은 함께 구상된 작동을 운용모드로 추상화함에 있어서 공통된 의견으로 적용할 수 있다.

2. 운용모드 형성 이해
운용모드는 도표형식의 그래프로 만들어질 수 있다. 시스템 엔지니어는 그래프로 서로 협의함으로 그림 3에 나타난바와 같이 기본적인 형성을 만들 수 있다.

형성 내용은 왼쪽에서 오른쪽으로 임무수행 전, 수행 중, 수행 후 운용단계로 나누어진다. 이러한 각 운용단계는 하나 또는 그 이상의 운용모드로 구성되어 있지만, 오직 한 모드만 단순하게 각 단계에서 보여주고 있다.
일반적인 왼쪽에서 오른쪽으로 즉, 임무수행 전에서 임무수행 후로 진행되는 것과 달리 운용모드는 시간에 의존적이면서도 독립적이다. 대부분의 시스템은 임무 이벤트 시계열(METs)을 형성하고 있어 1) 임무수행 전에서 수행단계로 전환, 2) 임무 수행단계에서 임무수행 후 단계로 전환, 3) 시스템이 반전하는 동안 임무수행 후 단계에서 임무수행 전 단계 전환에 제약이 있다. 각 운용모드 내에서 MET 이벤트 제약사항은 하부단계로 더 분할된다.

3. 시스템 모드 전환 이해
앞에서 논의된 중점사항은 단계별 시스템 운용모드 식별과 모드 상호관계에 사용되는 전이도이다. 이러한 이해 가운데 하나의 모드로부터 다른 모드로 전환해 가는 자극, 또는 시작 이벤트 및 조건을 알아보아야 할 단계가 되었다.
그림 3에서의 각 모드는 하나의 모드로부터 다른 모드로 전환하기 위한 화살표에 따라 연결된 라인을 볼 수 있다. 이러한 전환은 사전에 정의된 초기 이벤트나 조건에 따라 시작된다.
지금까지 우리가 살펴본 내용은 단계, 모드, 유스 케이스 시나리오, 요구 운용능력에 대한 속성 관계에 초점을 두고 있다. 그러면 임무수행 중의 하나의 단계, 모드, 유스 케이스에서 다른 단계로 전환하기 위하여 시스템, 제품 또는 서비스에 무엇을 해야 하는지에 대한 질문이 발생한다. 이를 답하기 위해 시작 이벤트를 살펴보도록 하자.
1) 시작 이벤트 중심으로의 전환
상태 머신처럼 대부분의 시스템은 운용자가 새로운 운용모드로 전환을 시도하는 것과 같은 외부적인 자극이 있을 때까지 주어진 운용모드 내에서 순환되도록 설계되어 있다. 외부 자극 발생은 시작 이벤트로 표시된다.
앞에서 논의된 바와 같이 시작 이벤트는 다음과 같이 유도된 데이터나 방해 요소이다. 그 시스템이 외부 시스템으로부터 데이터를 수신한다. 

시스템 사용자가 앞서 제시된 표준 운용 프락티스 및 절차(SOPPs) 또는 다음 단계 또는 운용모드로 전환하기 위한 관련 규정에 따라 그 시스템으로 데이터를 입력한다.
데이터 입력을 통한 시작 이벤트는 주기적 동기나 랜덤 비동기로 발생해도 좋다. 하나의 모드로부터 다른 모드로 전환할 때 사용자는 특정 시간 요구사항과 제약사항을 부과해도 좋다.
그림 4는 시작 이벤트 1이 발생할 때 모드 1로부터 모드 2로, 시작 이벤트 2에서 모드 2로부터 모드 1로 되돌아갈 때 전환하는 간단한 두 개의 모드 시스템에 관한 사례를 보여주고 있다. 모드 1로부터 모드 2 및 모드 1로 되돌아가는 시작 이벤트 전환은 서로 다른 가정과 조건 세트를 요구한다.

이 그래프는 두 가지 분리된 전환인 T1과 T2를 가진 양방향 전환을 보여주고 있다. T1의 경우, 외부 시작 이벤트 t1이 모드 1로부터 모드 2로 전환이 시작되고, 모드 2로 전환은 이벤트 t2에서 종료된다. 조금 후에 다른 시작 이벤트 t3가 자극으로 나타나면, 모드 2로부터 모드 1로 되돌아간다. 모드 1로 전환되면 이벤트 t4가 종료된다.
시스템 개발팀은 하나의 운용모드로부터 다른 모드로 전환하는 사례를 설정해야 한다. 예를 들면, 당신은 현재 모드에서 출구 기준이나 다음 모드를 위한 입구 기준을 제시하고 있는가? 전형적으로 모드는 입구 및 출구에 관한 기준을 가지고 있지 않다. 왜냐하면, 현재 모드 n으로부터 다음 모드 n+1로의 전환은 단일 전환이다. 당신은 현재 모드에 대한 출구 기준을 제시할 필요가 없으며 모드 상호간 인터페이스에 대한 다른 편 출구 기준과 같은 동일한 조건을 제시하면 되기 때문이다.
2) 모드 전환 기술
당신이 개념적인 시스템 단계와 모드를 설정하고 나면 다음 단계는 모드 전환을 위한 시작 이벤트와 조건을 제시하는 것이다. 이를 달성하는 한 방법은 표 2에 나타난 모드 전환 도표를 사용하는 길이다. 

일반적으로 표 2는 현재 모드로부터 어떻게 시스템 전환이 이루어지고 있는지를 보여준다. 즉, 왼쪽 끝에 있는 열로부터 오른쪽 끝에 있는 열로 나타난 다음 모드로의 전환이다. 내부 열은 전환조건과 연관된 정보사항을 알려준다. 표에 있는 각 줄은 단일 운용모드를 나타내며 수치적 ID 전환을 포함하고 있다.
전환정보는 시작 근거나 이벤트, 동기 또는 비동기로 나타낸 이벤트 유형, 그리고 전환자원이나 전환종료를 위한 시간적 제약사항 식별을 포함하고 있다. 표 2로부터 다음 예제를 생각해 보자.

<예제 3>
시스템이 오프 모드에 있다면, 온 위치(예를 들면, 비동기 시작 이벤트)에 있는 전력 스위치는 전환 ID T1 을 시작한다. 오프 모드로부터 전력공급 모드로의 전환은 최대 30초 내로 제약되어 있다. 이는 다양한 전력 시스템 안정 능력과 성능 요구사항을 나타낸다.

시스템 운용모드와 모드 전환을 식별하는 프로세스는 매우 반복적인 고정을 통해 성숙해 간다는 사실을 유의토록 하라. 후속적인 기술에 관한 결정은 시스템 모드 결정에 달려있기 때문에 시스템 엔지니어로서의 해야 할 역할은 팀을 수렴시켜 최종 의사를 결정해가는 길이다.
3) 모드 전환 분석
모드 전환은 한 모드로부터 다른 모드로 통제 흐름을 통한 인터페이스를 가져온다. 모드 전환은 시스템 차원의 작동을 가져오는 한편, 서로 다른 제품이나 하부 시스템이 모드의 일차 능력을 제공하게 된다.
서로 분할된 시스템 개발팀이 동일한 모드로 움직인다고 하면, 두 개의 팀이 동일한 가정과 결정 기준을 적용하고 있는지를 확인토록 해야 한다. 그렇지 않으면 불일치로 인해 시스템 통합이나 시험과정 이전까지는 문제가 나타나지 않을 가능성이 높다. 또한 왼쪽에서 발견되지 않고 시험 되지 않았다면, 잠재적 위험이 야전 운용시험에서 결함을 가져와 심지어 재해를 불러올 수 있다.
시스템 엔지니어의 도전은 한 모드에 대하여 설정된 초기 시작과 조건이 후속 진행 모드 과정에 잘 연결되어 있는지를 두 가지 모드 사이에 일치성을 확인함에 있다. 이와 같은 노력은 모드 전환이 쉼 없이 발생하고 있음을 보여주고 있다. 당신은 어떻게 일치성을 점검할 수 있는가? 운용모드, 임무 이벤트 시계열(MET), 그리고 모드 전환을 시스템 ConOps나 운용개념서(OCD)에 문서화 하도록 해야 한다.
4) 모드 전환에 대한 정리
우리가 시스템 운용과 애플리케이션을 논의함에 있어서 시스템 애플리케이션 측면에서 일회 사용, 재사용, 재활용 등에 대하여 여러 모양으로 다루어 왔다. 대부분 재사용 시스템은 순환적인 운용 특성을 지니고 있다. 순환 시스템은 전력이 끊어지거나 다음 단계 임무를 준비하는 경우, 임무수행 전 단계로 되돌아가는 통제흐름이나 전형적 업무흐름을 지닌 피드백 루프를 가지고 있다.
이제 우주선의 외부 탱크(ET)와 같은 시스템을 생각해 보자. 임무 관점에서 ET의 연료 자원은 소비성 품목이며 ET의 속성은 소비품목에 해당된다. 특정 비행단계 및 MET 이벤트에서 ET는 궤도차량으로부터 분리되어 지구로 돌아온다. 그리고 대기권으로 진입하면서 타 버린다.
ET와 같은 소비 시스템의 경우, 운용모드는 이전 모드로 피드백 루프를 따르지 않고 순서적으로 진행된다. 그러나 시스템 엔지니어링 설계 관점에서 ET 작동은 ‘scrubbedʼ 발사에 따른 초기 모드로 다시 돌아가는 순환을 요구하는 시스템을 포함하고 있다. 따라서 소비 시스템은 궁극적으로 재진입과 같은 종료 모드 시점으로 전환되는 운용모드를 요구하고 있다.
5) 대형 복합 시스템의 일반화된 운용모드
앞서 우리가 논의한 대상 시스템은 주로 시스템 운용모드를 이해하기 쉽게 단순 제품 사례를 제시했다. 대형 복합 시스템에 대한 운용모드를 고려할 경우, 다중 목적, 재사용 시스템, 추가적인 요소들이 함께 고려되어야 한다.

<예제 4>
대상 시스템에서 고려되어야 할 요소는 재형상설계, 보정, 정렬, 소비재 보충, 소모품 등이다.

시스템 운용모드에서처럼 우리는 모드의 종류를 식별하기 위해 초기 시작점으로 사용될 수 있는 템플릿을 정의할 수 있다.
6) 일반화된 운용모드 템플릿
이론적으로 운용단계 모드 세트로 유스 케이스를 구상하고 분석함에 있어서 많은 시간을 들여야 한다. 한번 여러 시스템을 개발하고 나면, 시스템 모드는 여러 시스템에 유사하고 공통적인 패턴을 발견할 수가 있다. 따라서 다음과 같은 질문을 하게 된다. 모든 시스템 모드에 대하여 유형의 유스 케이스 분석을 수행하기보다 표준 모드 세트로 적용 가능성을 살펴보고 이를 특정 시스템 애플리케이션으로 테일러링하는 방법을 찾아보는 것이 바람직하다. 만일 이것이 가능하다면 공통 모드 세트란 무엇일까?
표 3은 이러한 공통 운용모드 목록을 제공하고 있다. 나아가 이러한 모드는 상호 의존적 관계를 맺고 있음을 분석할 수 있다. 

이러한 관계를 그림 5에 보여주고 있다. 출발점에서 이러한 템플릿은 모든 시스템에 적용 가능한가? 일반적으로 그렇다. 이는 출발점이지 최종 결과는 아니라는 사실을 유의하기 바란다.

시스템 운용상태

과학적인 용어로 상태란 고체, 액체 또는 기체와 같은 물리적 형태를 말한다. 여기에서 상태란 형상을 나타내는 구조와 연관되어 있으며 활동레벨은 구조 내에서 나타난다. 따라서 상태는 다음과 같다.

· 관측, 시험, 측정, 예측 및 검증할 수 있어야 한다.
· 시간에 따라 무한정의 다양한 상태를 가진 동적 또는 정적 상태이어야 한다.

여기서 무한정 상태란 잔여 자원의 양이 물리적 상태를 나타내는 소비재와 같은 상황을 말한다. 예를 들면, 유량 수준, 제동 패드 마모, 타이어 마모와 같다. 하나의 전문영역으로서의 시스템 엔지니어는 시스템, 제품 또는 서비스 상태를 정의하기 위하여 물리적 형상으로 나타낼 수 있어야 한다. 따라서 상태는 형상과 인터페이스 세트와 시간 또는 기간 내 주어진 사례의 물리적 컴포넌트 수락 오차범위처럼 시스템의 물리적 아키텍처를 나타낸다.

1. 운용상태와 물리적 상태
운용상태의 개념은 물리적 또는 운용상태처럼 두 가지 콘텍스트로 인해 가끔 혼돈을 가져온다.
(1) 운용상태 : 우리는 온(운용) 및 오프(정지)와 같이 단순한 표현으로 시스템이나 제품 상태를 기술한다. 사용조직에서는 인력과 장비와 같은 통합 시스템 요소 세트의 준비상태나 운용준비를 나타내기 위하여 상태를 사용하기도 한다. 이는 통합 시스템과 각 시스템 요소가 다음과 같은 경우를 의미한다.

· 특정 임무 형태를 수행하는 데 필요 충분한 능력으로 나타낸 물리적 형상 아키텍처와 인터페이스
· 임무와 목적을 주어진 시점에서 안전하고 믿고 수행하기 위해 충분히 수용 가능한 조건이나 건강

운용상태란 일반적으로 “…된” 또는 “…하고 있는”과 같은 끝말로 식별할 수 있다. 다음 예제를 살펴보자.

<예제 5>
항공기(장비, 조종사 등)의 운용상태란 주차, 택시, 비상, 상승, 비행, 하강, 랜딩하고 있는 상태를 포함하고 있다.

<예제 6>
충분한 연료와 오일 공급과 효율적인 작동을 위해 튜닝된 제초기는 다음과 같은 운용상태로 기술된다.

· 정지/준비 : 집주인이 잔디를 깎거나 제초기를 저장하기 위해 준비된 상태
· 공회전(날개 회전 없이 엔진 작동) : 제초기가 정지된 상태
· 작동(엔진 작동과 함께 날개 회전) : 제초기가 잔디밭을 이동하고 있는 상태
· 저장 : 탱크 연료 추출 등 수행 후 저장하는 상태

<예제 7>
평평한 도로를 달리고 있는 자동차를 생각해보자. 운전자가 드라이브 모드로 맞추고 있을 때, 자동차의 물리적 설계는 운전자 입력에 따른다. 그래서 자동차는 그 자극에 따라 하부 시스템을 움직인다. 엔진과 트랜스미션과 같은 동력계통은 다음과 같은 자동차 운용상태를 통제하기 위해 가용하도록 설계된다. 주차, 정지, 가속, 주행, 감속, 그리고 제동하는 작동을 말한다.

(2) 물리적 형상 상태 : 시스템이나 제품의 운용상태는 수많은 물리적 형상 상태로 구성된다. 앞서 논의된 상황을 참조하여 다음 예제를 살펴보자.

<예제 8>
자동차 물리적 시스템 설계는 동력전달, 전기, 환경, 연료, 내장과 같은 여러 가지 하부 시스템으로 구성되어 있다. 앞에서 논의된 상태를 고려하여 자동차 설계는 이러한 하부 시스템들이 상호 독립적으로 또는 동시적으로 작동하도록 설계되어야 한다. 이리하여 자동차가 정지 및 주행과 같은 운용상태에 있을 때 운전자는 다음과 같은 작동을 수행하게 된다.

· 음향 시스템을 온 또는 오프
· 윈드 실드 웨이퍼 온, 오프 또는 원하는 간격으로 조정
· 냉방온도 레벨 조정
· 시트 위치 조정
· 가속 여부 조정
· 제동 적용

이러한 물리적 조정은 한정으로부터 무한정한 물리적 형상 상태까지 이루어질 수 있다.
앞의 예제를 통해 시스템 운용상태가 하나 또는 둘 이상의 물리적 형상 상태를 가지고 있는 이유를 볼 수 있다. 그러면 시스템 단계, 모드, 운용상태와 물리적 형상 상태와의 관계는 무엇인지에 대한 질문이 생긴다. 그림 6에 나타난 시스템 운용을 표 4에 열거된 설계법칙 세트와 비교하여 속성 관계를 정의해 볼 수 있다. 

이러한 속성이 어떻게 적용되고 있는지를 보기 위해 다음 예제를 살펴보자.

<예제 9>
자동차 운전자가 드라이브(모드)에 두고 앞으로 나아가는 상태(운용상태)로 전진하게 될 때 이는 동시적인 허용 활동이다. 자동차가 최고 속도로 전진(운용상태)함에 따라 자동차 컴퓨터 시스템은 자동적으로 차 문이 열려 떨어지지 않도록(금지 행위) 문을 잠근다(허용 행위).

시스템 능력을 모드로 전환

앞서 논의된 사항은 시스템 운용, 단계, 모드 및 상태와 연결할 수가 있다. 궁극적으로 이러한 연결은 안전 및 적합 운용 프락티스에 대한 사용자 매뉴얼에 문서화한 바와 같이 허용과 금지 행위를 지닌 납품 시스템에 명료하게 나타난다. 허용 행위는 계약 비용, 일정, 기술 및 위험 제약사항에 대하여 시스템이 제공하는 물리적 능력을 나타낸다.
앞서 시스템 운용모드에서 우리는 주어진 시스템 요소, 운용환경 및 설계수행, 제약사항에 대한 능력을 구성하여 나타내는 필요성을 제시했다. 각 능력 형태에 대하여 운용능력이 어떻게 제시될 것인지를 기술했다.

· 통합 요구 세트의 합산으로 제시
· 시스템 성능 규격(SPS)으로 문서화
· 다중 시스템 구상 레벨로 할당 및 분할

만일 시스템 능력 매트릭스를 운용 모드 관점에서 분석한다면, 그 매트릭스는 각 운용 모드에 대한 요구 운용능력을 제공하기 위해 통합해야 할 복합 시스템 요소를 나타내게 된다. 이러한 요소와 상호관계 통합은 시스템 물리적 형상이나 아키텍처와 연관되어 있다. 따라서 각 운용모드는 시스템 요소에 대한 아키텍처 형상에 따라 수행된다. 이를 다음 그림 7에 의해 좀 더 살펴보자.

차트의 좌상단에 나타난 아이콘은 시스템 능력 매트릭스를 나타낸다. 화살표는 각 운용모드에 대하여 특정 물리적 (아키텍처) 상태로의 능력의 수평선과 연결된다는 사실을 유의하기 바란다. 이리하여 전원 오프 모드에 대하여 그 모드를 지원하기 위해 필요한 고유의 물리적 아키텍처가 있다. 유사하게 정상 운용모드에 대하여 각 구상 레벨에서의 시스템 속성은 정상 운용모드 형상을 만들기 위해 통합되는 고유의 아키텍처 형상을 하고 있다.

1. 개념조합
요약해서 그림 7은 운용 요구능력이 시스템 능력 매트릭스로부터 SPS로 어떻게 연결되는지를 보여준다. 그리고 후속적으로 각 운용모드에 대하여 시스템 아키텍처 물리적 운용상태에 의해 제공되고 할당되는지를 제시해 준다.

기본 원칙

요약해서 이상 논의된 내용은 시스템 단계, 모드, 운용상태 개발에 적용된 기본 원칙을 설정하는 데 기반을 제시해 주고 있다.

· 원칙 1 : 모든 시스템 운용단계는 최소한 둘 또는 그 이상의 사용자 선정 운용모드로 구성되어 있다.
· 원칙 2 : 모든 시스템 운용모드는 하나 또는 그 이상의 유스 케이스를 수용할 수 있는 능력을 나타낸다. 각 유스 케이스는 하나 또는 그 이상의 가정 시나리오를 가지고 있다.
· 원칙 3 : 각 시스템 운용모드는 다른 운용모드로 전환하기 위하여 이미 정의된 조건 기반 시작 이벤트 기준 세트를 요구한다.
· 원칙 4 : 모든 시스템 운용모드는 성능 기반 목표를 이행하기 위하여 최소한 하나 또는 그 이상의 능력 기반 운용상태를 요구한다.
· 원칙 5 : 각 운용상태는 최소한 하나 또는 그 이상의 물리적 운용 형상 상태로 지원된다.
· 원칙 6 : 각 물리적 운용상태는 최소한 하나 또는 그 이상의 허용 행위와 최소한 하나 또는 그 이상의 금지 행위로 나타내어야 한다.

요약

우리는 시스템 운용모드가 시스템 요소능력에 의해서 어떻게 지원되는지를 살펴보았다. 그리고 능력은 시스템 성능 규격(SPS)에 구속된 성능 레벨로 나타낸 능력 세트로 문서화된다. 그리고 다양한 추상적 구상 레벨로 시스템 요소 추상적 레벨로 분할되고 할당된다.

1. 일반적 예제

(1) 개요에서 제시된 이 장에서 무엇을 배울 것인가에 대한 답을 해보라.
(2) 앞서 생각해 보았던 시스템이나 새로운 시스템을 선정하여 이 장에서 제시된 내용을 적용해 보라.
(3) 다음과 같은 시스템에 대하여 다양한 운용상태를 식별해 보라.
· 데이터 커뮤니케이션
· 항공기 운용
· 컴퓨터 시스템 상태
· 패키지 운송 서비스
· 조직 운영
· 빌딩 환경 통제
· 음식 서비스 운영
· 자연환경
· 자동차 운용

민성기  시스템체계공학원장(ise@seinstitute.co.kr)