396.56 비상 체계(Fail-Safe)와 임무 관리의 연동

1. 개요

자율 로봇 시스템에서 비상 체계(Fail-Safe)는 시스템 고장, 환경 이상, 또는 예기치 못한 상황 발생 시 로봇과 주변 환경의 안전을 보장하기 위한 핵심 메커니즘이다. 비상 체계와 임무 관리 시스템의 긴밀한 연동은 단순한 안전 장치의 차원을 넘어, 자율 시스템의 신뢰성(reliability)과 가용성(availability)을 결정짓는 구조적 요소로 기능한다. 본 절에서는 비상 체계의 이론적 기초, 임무 관리 시스템과의 통합 아키텍처, 그리고 실제 연동 메커니즘을 체계적으로 분석한다.

2. 비상 체계의 정의와 분류

2.1 Fail-Safe의 개념

Fail-Safe란 시스템의 구성 요소가 고장(failure)을 일으킬 때, 해당 고장이 전체 시스템의 안전에 위협이 되지 않도록 미리 정의된 안전 상태(safe state)로 전이하는 설계 원칙을 말한다. IEC 61508(Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems) 표준에서는 이를 기능 안전(functional safety)의 핵심 개념으로 정의하며, 위험(hazard)이 시스템 고장에 의해 발생하는 것을 방지하는 체계적 접근을 요구한다.

수학적으로, Fail-Safe 상태 전이는 다음과 같이 정식화할 수 있다. 시스템 상태 공간 $\mathcal{S}$ 에서 안전 상태 집합 $\mathcal{S}_{\text{safe}} \subset \mathcal{S}$ 와 위험 상태 집합 $\mathcal{S}_{\text{hazard}} \subset \mathcal{S}$ 를 정의할 때, Fail-Safe 조건은 다음을 만족해야 한다:

$\forall s \in \mathcal{S}_{\text{hazard}}, \quad \exists \delta: \mathcal{S}_{\text{hazard}} \rightarrow \mathcal{S}_{\text{safe}} \quad \text{such that} \quad \delta(s) \in \mathcal{S}_{\text{safe}}$

여기서 $\delta$ 는 비상 전이 함수(emergency transition function)이며, 유한 시간 $T_{\text{safe}}$ 내에 실행이 완료되어야 한다.

2.2 Fail-Safe, Fail-Secure, Fail-Operational의 구분

비상 체계는 고장 발생 시 시스템의 반응 방식에 따라 세 가지 주요 유형으로 분류된다.

유형	정의	적용 사례
Fail-Safe	고장 시 안전 상태로 전이하며 동작을 중단	산업용 매니퓰레이터의 긴급 정지
Fail-Secure	고장 시 보안 상태를 유지하며 외부 접근을 차단	군사 로봇의 통신 두절 시 데이터 암호화 유지
Fail-Operational	고장 발생에도 불구하고 성능 저하(degradation)를 감수하며 운용 지속	자율 주행 차량의 이중화 조향 시스템

로봇 임무 관리의 맥락에서, 이 세 가지 유형은 상호 배타적이지 않으며 하이브리드 형태로 구현되는 것이 일반적이다. 예를 들어, 무인 항공 시스템(UAS)에서는 주 센서 고장 시 Fail-Operational 모드로 보조 센서를 활용하되, 보조 센서마저 고장할 경우 Fail-Safe 모드로 전환하여 사전 정의된 귀환(Return-to-Launch, RTL) 임무를 실행한다.

3. 비상 체계와 임무 관리의 통합 아키텍처

3.1 계층적 안전 관리 모델

비상 체계와 임무 관리의 연동은 계층적 아키텍처를 통해 구현된다. 전형적인 3계층 아키텍처(3-Tier Architecture)에서 안전 관리는 각 계층을 관통하는 수직적 관심사(cross-cutting concern)로 작용한다.

**의사결정 계층(Deliberative Layer)**에서는 임무 수준의 비상 전략을 관리한다. 이 계층은 현재 임무의 위험도(risk level)를 평가하고, 대체 임무(alternative mission)의 가용성을 판단하며, 임무 수준의 비상 전환(mission-level failover)을 결정한다. 임무 수준 위험도 평가 함수 $R_{\text{mission}}$ 은 다음과 같이 정의된다:

$R_{\text{mission}}(t) = \sum_{i=1}^{N} w_i \cdot P(\text{failure}_i \mid t) \cdot C(\text{failure}_i)$

여기서 $w_i$ 는 가중치, $P(\text{failure}_i \mid t)$ 는 시간 $t$ 에서의 고장 확률, $C(\text{failure}_i)$ 는 고장 비용을 나타낸다.

**실행 계층(Executive Layer)**에서는 행동 수준의 비상 제어를 담당한다. 행동 트리(Behavior Tree) 또는 상태 머신(FSM)의 실행 흐름에 비상 노드를 삽입하여, 특정 조건에서 현재 행동을 강제 종료하고 비상 행동으로 전환하는 메커니즘을 구현한다.

**반응 계층(Reactive Layer)**에서는 하드웨어 수준의 즉각적 안전 응답을 처리한다. 하드웨어 인터럽트(hardware interrupt), 워치독 타이머(watchdog timer), 안전 PLC(Safety PLC) 등의 기법을 통해 소프트웨어 계층의 응답 지연을 보상한다.

3.2 안전 감시자(Safety Monitor) 아키텍처

비상 체계와 임무 관리의 연동에서 안전 감시자(Safety Monitor)는 핵심적인 중재 역할을 수행한다. 안전 감시자는 시스템의 모든 계층으로부터 상태 정보를 수집하고, 사전 정의된 안전 규칙(safety invariant)의 위반 여부를 실시간으로 검사하며, 위반 감지 시 적절한 비상 조치를 임무 관리 시스템에 지시한다.

안전 불변식(safety invariant)의 형식적 표현은 시간 논리(temporal logic)를 활용하여 다음과 같이 기술된다. LTL(Linear Temporal Logic)을 사용하면:

$\Box(\phi_{\text{safe}}) \quad \text{즉,} \quad \text{항상(always) } \phi_{\text{safe}} \text{가 참이어야 한다}$

여기서 $\phi_{\text{safe}}$ 는 안전 조건을 나타내는 명제이다. 예를 들어, 무인 항공기의 경우 $\phi_{\text{safe}}$ 는 “배터리 잔량 > 귀환 필요 에너지 + 안전 여유“로 정의될 수 있다.

안전 감시자의 동작을 오토마타 이론(automata theory)으로 모델링하면, 비결정적 뷔히 오토마톤(nondeterministic Büchi automaton) $\mathcal{A}_{\text{safety}} = (Q, \Sigma, \delta, q_0, F)$ 으로 표현할 수 있다. 여기서 $Q$ 는 상태 집합, $\Sigma$ 는 관측 알파벳, $\delta: Q \times \Sigma \rightarrow 2^Q$ 는 전이 함수, $q_0$ 는 초기 상태, $F \subseteq Q$ 는 수용 상태 집합이다. 안전 위반은 오토마톤이 수용하지 않는 무한 실행(non-accepting run)의 발생으로 감지된다.

4. 비상 이벤트의 분류와 대응 전략

4.1 비상 이벤트의 심각도 분류

비상 이벤트는 심각도(severity)에 따라 계층적으로 분류되며, 각 수준에 대응하는 임무 관리 전략이 정의된다. DO-178C(Software Considerations in Airborne Systems and Equipment Certification) 및 ISO 26262(Road Vehicles – Functional Safety) 표준을 참조하여 다음과 같이 분류한다.

심각도 수준	설명	임무 관리 대응
Level 1 (Advisory)	정보 제공 수준의 경고	임무 계속, 운영자 알림
Level 2 (Caution)	주의 필요한 이상 상태	임무 파라미터 조정, 모니터링 강화
Level 3 (Warning)	즉각적 주의가 필요한 상태	임무 수정 또는 대체 임무 전환
Level 4 (Critical)	시스템 안전에 영향을 미치는 상태	비상 임무 전환, 안전 귀환 개시
Level 5 (Catastrophic)	치명적 위험 상태	즉각적 비상 정지 또는 비상 착륙

4.2 비상 대응 정책 매트릭스

임무 관리 시스템은 비상 이벤트의 유형과 현재 임무 상태의 조합에 따라 적절한 대응 정책을 선택한다. 이를 비상 대응 정책 매트릭스(Emergency Response Policy Matrix)로 형식화할 수 있다:

$\Pi: \mathcal{E} \times \mathcal{M} \rightarrow \mathcal{A}_{\text{response}}$

여기서 $\mathcal{E}$ 는 비상 이벤트 공간, $\mathcal{M}$ 은 현재 임무 상태 공간, $\mathcal{A}_{\text{response}}$ 는 가용한 대응 행동의 집합이다.

대응 행동 집합 $\mathcal{A}_{\text{response}}$ 는 다음과 같은 원소들로 구성된다:

임무 계속(Continue): 현재 임무를 변경 없이 계속 수행
임무 축소(Degrade): 임무 목표를 축소하여 안전 범위 내에서 수행
임무 전환(Switch): 사전 정의된 대체 임무로 전환
안전 귀환(Return-to-Base): 발사 지점 또는 지정된 안전 지점으로 귀환
비상 착륙/정지(Emergency Land/Stop): 현 위치에서 즉각적 종료
비상 투하(Emergency Jettison): 탑재물을 안전하게 분리

5. 비상 체계의 구현 메커니즘

5.1 행동 트리에서의 비상 체계 연동

행동 트리(Behavior Tree) 기반 임무 관리에서 비상 체계는 주로 루트 노드 근방에 배치되는 안전 검사(safety check) 서브트리를 통해 구현된다. 이 구조에서는 안전 조건이 매 틱(tick)마다 평가되며, 안전 위반 시 전체 임무 트리의 실행을 선점(preempt)한다.

전형적인 구현 패턴은 다음과 같다:

Root (Selector)
├── Safety Subtree (Sequence)
│   ├── [Condition] Battery Critical?
│   └── [Action] Emergency Return-to-Launch
├── Safety Subtree (Sequence)
│   ├── [Condition] Communication Lost > Timeout?
│   └── [Action] Execute Comm-Loss Protocol
├── Safety Subtree (Sequence)
│   ├── [Condition] Geofence Violated?
│   └── [Action] Immediate Hover & Report
└── Mission Subtree (Sequence)
    ├── [Action] Navigate to Waypoint
    ├── [Action] Execute Survey
    └── [Action] Return to Base

이 패턴에서 Selector 노드는 왼쪽에서 오른쪽 순으로 자식 노드를 평가하므로, 안전 서브트리가 미션 서브트리보다 항상 우선적으로 평가된다. 안전 조건이 활성화되면 해당 비상 행동이 즉시 실행되고, 미션 서브트리의 평가는 건너뛴다.

5.2 상태 머신에서의 비상 체계 연동

유한 상태 머신(FSM) 기반 임무 관리에서 비상 체계는 전역 전이(global transition)를 통해 구현된다. 전역 전이란 현재 상태와 무관하게 특정 이벤트 발생 시 지정된 비상 상태로 즉시 전환하는 메커니즘이다.

형식적으로, 확장된 FSM $\mathcal{M}_{\text{ext}} = (S, \Sigma, \delta, s_0, F, \Gamma)$ 에서 전역 비상 전이 $\Gamma$ 는 다음과 같이 정의된다:

$\Gamma = \{(e_j, s_{\text{emergency}_j}) \mid e_j \in \mathcal{E}_{\text{critical}}, \; s_{\text{emergency}_j} \in \mathcal{S}_{\text{safe}}\}$

여기서 $e_j$ 가 감지되면, 현재 상태 $s_{\text{current}}$ 와 무관하게 $s_{\text{emergency}_j}$ 로 전이한다. 이는 일반 전이 함수 $\delta$ 보다 높은 우선순위를 가진다.

5.3 워치독 타이머 기반 안전 보장

소프트웨어 수준의 비상 체계가 정상적으로 동작하지 못하는 상황(예: 소프트웨어 교착 상태, 프로세스 크래시)에 대비하여 워치독 타이머(Watchdog Timer)를 활용한 하드웨어 수준의 안전 보장 메커니즘을 구현한다.

워치독 타이머의 동작 원리는 다음과 같다. 임무 관리 소프트웨어는 주기적으로 워치독 타이머를 리셋(kick)해야 하며, 지정된 시간 $T_{\text{wd}}$ 내에 리셋이 이루어지지 않으면 하드웨어 수준에서 비상 동작(예: 모터 전원 차단, 안전 착륙 시퀀스 개시)이 자동으로 실행된다. 이를 수학적으로 표현하면:

$\text{if} \quad (t - t_{\text{last\_kick}}) > T_{\text{wd}} \quad \Rightarrow \quad \text{Execute}(\text{HW\_Emergency\_Action})$

여기서 $t_{\text{last\_kick}}$ 은 마지막 워치독 리셋 시각이다.

6. 비상 전환의 시간적 제약과 인증 요구사항

6.1 비상 응답 시간 분석

비상 체계의 신뢰성은 비상 이벤트 감지로부터 안전 상태 도달까지의 응답 시간(response time)에 의해 결정된다. 총 비상 응답 시간 $T_{\text{response}}$ 는 다음의 구성 요소들로 분해된다:

$T_{\text{response}} = T_{\text{detect}} + T_{\text{decide}} + T_{\text{transition}} + T_{\text{stabilize}}$

여기서:

$T_{\text{detect}}$ : 이상 상태 감지 시간 (센서 처리 및 판정 지연 포함)
$T_{\text{decide}}$ : 비상 대응 결정 시간 (정책 매트릭스 조회 및 경로 계산 포함)
$T_{\text{transition}}$ : 임무 전환 실행 시간 (현재 행동 중단 및 비상 행동 개시)
$T_{\text{stabilize}}$ : 안전 상태 안정화 시간 (물리적 정지, 착륙 등)

각 구성 요소에 대해 최악의 경우 실행 시간(WCET; Worst-Case Execution Time) 분석을 수행하여, 전체 응답 시간이 안전 요구사항에서 규정하는 허용 한계 $T_{\text{max}}$ 이내에 있음을 보장해야 한다.

6.2 안전 무결성 수준(SIL) 연계

IEC 61508 표준에서 정의하는 안전 무결성 수준(SIL; Safety Integrity Level)은 비상 체계의 설계와 검증에 직접적인 영향을 미친다. SIL 등급에 따라 요구되는 고장 확률(PFD; Probability of Failure on Demand) 범위가 결정되며, 이는 임무 관리 시스템의 이중화(redundancy) 수준과 검증 강도를 규정한다.

SIL 등급	PFD 범위	요구되는 이중화 수준
SIL 1	$10^{-1}$ ~ $10^{-2}$	단일 채널 + 자가 진단
SIL 2	$10^{-2}$ ~ $10^{-3}$	단일 채널 + 외부 모니터링
SIL 3	$10^{-3}$ ~ $10^{-4}$	이중 채널(1oo2)
SIL 4	$10^{-4}$ ~ $10^{-5}$	이중/삼중 채널(2oo3)

7. 통신 두절 시의 비상 임무 관리

7.1 통신 손실 감지 메커니즘

원격 관제 기반 로봇 시스템에서 통신 두절(communication loss)은 가장 빈번하게 발생하는 비상 시나리오 중 하나이다. 통신 손실 감지는 하트비트(heartbeat) 프로토콜을 통해 구현되며, 다음의 판정 기준을 적용한다:

경고 임계값(Warning Threshold): 연속 $N_w$ 개의 하트비트 누락 시 통신 품질 저하 경고
비상 임계값(Emergency Threshold): 연속 $N_e$ 개의 하트비트 누락 시 통신 두절 판정

$\text{Comm\_Status} = \begin{cases} \text{Normal} & \text{if } n_{\text{miss}} < N_w \\ \text{Degraded} & \text{if } N_w \leq n_{\text{miss}} < N_e \\ \text{Lost} & \text{if } n_{\text{miss}} \geq N_e \end{cases}$

7.2 통신 두절 시 자율 비상 프로토콜

통신 두절이 확정되면, 임무 관리 시스템은 사전 프로그래밍된 비상 프로토콜(contingency plan)에 따라 자율적으로 행동한다. MAVLink 프로토콜 기반 무인 항공 시스템에서는 다음과 같은 단계적 프로토콜이 적용된다:

대기 단계(Loiter Phase): 통신 두절 직후 현재 위치에서 일정 시간 $T_{\text{loiter}}$ 동안 대기하며 통신 복구를 시도
귀환 단계(RTL Phase): $T_{\text{loiter}}$ 경과 후 통신이 복구되지 않으면, 사전 정의된 귀환 경로를 따라 발사 지점으로 귀환
비상 착륙 단계(Emergency Landing Phase): 귀환 중 배터리 부족 등 추가 비상 상황 발생 시, 가장 가까운 안전 착륙 지점에 자동 착륙

8. 에너지 기반 비상 체계

8.1 배터리 기반 비상 판정

전기 구동 로봇 시스템에서 에너지 잔량은 가장 중요한 안전 파라미터 중 하나이다. 배터리 기반 비상 판정은 잔여 에너지와 임무 완료에 필요한 에너지의 비교를 통해 이루어진다.

안전 귀환에 필요한 최소 에너지 $E_{\text{RTL}}$ 은 다음과 같이 추정된다:

$E_{\text{RTL}} = \int_0^{T_{\text{RTL}}} P_{\text{flight}}(t) \, dt + E_{\text{reserve}}$

여기서 $P_{\text{flight}}(t)$ 는 비행 소비 전력, $T_{\text{RTL}}$ 은 귀환 예상 소요 시간, $E_{\text{reserve}}$ 는 안전 여유 에너지이다. 비상 전환 조건은 다음과 같다:

$E_{\text{current}} \leq E_{\text{RTL}} + E_{\text{margin}} \quad \Rightarrow \quad \text{Trigger RTL}$

$E_{\text{margin}}$ 은 바람, 기온 변화 등의 불확실성을 고려한 추가 여유 에너지이다.

9. 지오펜스(Geofence) 기반 비상 체계

9.1 지오펜스의 정의와 유형

지오펜스(Geofence)는 로봇의 운용 범위를 물리적 공간 상에서 제한하는 가상 경계(virtual boundary)이다. 지오펜스 위반은 비상 이벤트로 취급되며, 임무 관리 시스템에 의한 즉각적 대응이 요구된다.

지오펜스는 다음의 유형으로 구분된다:

포함 지오펜스(Inclusion Geofence): 로봇이 해당 영역 내에 있어야 하는 경계 (위반 = 영역 이탈)
배제 지오펜스(Exclusion Geofence): 로봇이 진입해서는 안 되는 금지 영역 (위반 = 영역 진입)
고도 제한 지오펜스(Altitude Geofence): 수직 방향의 운용 한계 설정

9.2 지오펜스 위반 감지와 대응

지오펜스 위반 감지는 로봇의 현재 위치 $\mathbf{p}(t) = (x(t), y(t), z(t))$ 와 지오펜스 경계 $\mathcal{G}$ 사이의 포함 관계를 실시간으로 평가하여 수행한다. 포함 지오펜스의 경우:

$\mathbf{p}(t) \notin \mathcal{G}_{\text{inclusion}} \quad \Rightarrow \quad \text{Geofence Violation}$

지오펜스 위반 시의 대응 전략은 위반의 심각도와 속도 벡터의 방향에 따라 결정된다:

접근 경고(Proximity Warning): 경계까지의 거리가 임계값 $d_{\text{warn}}$ 이하일 때 경고 발생
연성 위반(Soft Violation): 경계 초과 시 속도를 제한하고 경계 안으로 복귀 유도
경성 위반(Hard Violation): 즉각적 비상 정지 또는 최소 안전 기동 실행

10. 비상 체계의 검증과 시험

10.1 고장 주입 시험(Fault Injection Testing)

비상 체계의 신뢰성을 검증하기 위해 고장 주입 시험(Fault Injection Testing, FIT)을 수행한다. 이는 의도적으로 시스템에 고장을 주입하여 비상 체계가 설계대로 동작하는지 확인하는 방법이다.

고장 주입의 주요 기법에는 다음이 포함된다:

하드웨어 고장 주입(Hardware Fault Injection): 물리적 신호 교란, 전원 차단, 센서 출력 왜곡
소프트웨어 고장 주입(Software Fault Injection): 변수 값 변이(mutation), 프로세스 강제 종료, 통신 지연 시뮬레이션
모델 기반 고장 주입(Model-Based Fault Injection): 시뮬레이션 환경에서의 가상 고장 시나리오 실행

10.2 시뮬레이션 기반 검증(SITL/HITL)

비상 체계의 포괄적 검증을 위해 Software-In-The-Loop(SITL) 및 Hardware-In-The-Loop(HITL) 시뮬레이션을 활용한다. SITL은 비상 시나리오의 초기 검증에, HITL은 하드웨어 연동을 포함한 통합 검증에 적합하다. 특히, 비상 체계의 시간적 제약 검증은 HITL 환경에서의 실시간 시뮬레이션을 통해 수행하는 것이 권장된다.

11. 참고 문헌

IEC 61508, “Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems,” International Electrotechnical Commission, 2010.
ISO 26262, “Road Vehicles – Functional Safety,” International Organization for Standardization, 2018.
DO-178C, “Software Considerations in Airborne Systems and Equipment Certification,” RTCA, 2012.
M. Colledanchise and P. Ögren, “Behavior Trees in Robotics and AI: An Introduction,” CRC Press, 2018.
R. Alami, R. Chatila, S. Fleury, M. Ghallab, and F. Ingrand, “An Architecture for Autonomy,” International Journal of Robotics Research, vol. 17, no. 4, pp. 315–337, 1998.
S. Bensalem, K. Havelund, and A. Orlandini, “Verification and Validation Meet Planning and Scheduling,” International Journal of Software Tools for Technology Transfer, vol. 16, no. 1, pp. 1–12, 2014.
PX4 Development Team, “PX4 Autopilot User Guide: Safety Configuration,” https://docs.px4.io, 2024.
ArduPilot Development Team, “ArduPilot Failsafe Documentation,” https://ardupilot.org, 2024.

version: 1.0