제2부 비행제어·항공전자·감시

2.10 비행 소프트웨어 구조: 오토파일럿 아키텍처·RTOS·파티셔닝·현장 갱신

2.10.1 이 장에서 배우는 것 / 선수 지식 / 특히 중요한 독자

앞 장(2.9)은 소프트웨어가 올라탈 하드웨어와 자원 분할을 다뤘다. 이 장은 그 위에서 도는 비행 소프트웨어를 다룬다. 비행 소프트웨어는 맞는 답을 내는 것만으로는 부족하고 정해진 시각 안에 내야 한다. 늦은 정답은 제어 루프에서 틀린 답과 같다. 이 장은 시간 제약을 준수하는 구조와 그것이 깨질 때 생기는 일을 숫자로 본다.

배우는 것:

• 계층과 통신 — 드라이버에서 추정기·제어기·출력으로 이어지는 계층, 모듈 사이를 잇는 발행–구독, 자료의 신선도.
• 실시간의 뜻 — 주기·지터·마감, 실행 시간(WCET), 이용률 한계와 응답 시간 해석. 7개 태스크 집합으로 직접 계산한다.
• 지터가 위상 여유를 깎는 계산 — 스케줄 해석이 준 지터 상한이 각속도 루프의 위상 여유에서 몇 도가 되는가.
• 파티셔닝 — ARINC 653의 시간 창이 제어 지연과 맞바꾸는 것.
• 비행 모드와 안전 모니터 — 상태 기계의 설계 원칙, 워치독과 독립 감시기와 런타임 보증.
• 현장 갱신과 오픈소스 — 보안 부팅·이중 이미지·롤백, 오픈소스 오토파일럿을 인증에 사용할 때의 간극, 파라미터·로그·시험.

선수 지식: 멀티콥터의 복원력 없는 구조(1.1.7.1), 샘플링과 앨리어싱(1.29.5), 비행 컴퓨터와 임무 컴퓨터의 구분과 파티셔닝 개요(2.9.3.3·2.9.4). 제어 알고리즘과 지연 기준값은 2.2, 하드웨어 구조는 2.9, 오토파일럿 제품 비교는 24.27, MAVLink는 9.5이 맡는다. 제어이론과 ROS 2의 상세는 자매서 controleng(CE)·ros2(RJ)를 본다.

특히 중요한 독자: 엔지니어는 2.10.5·2.10.6의 계산을 직접 해 본다. 인증 담당자는 2.10.7·2.10.10.1을 본다. 오픈소스가 인증 증거를 어떻게 바꾸는지가 거기 있다. 사업·운영 담당자는 2.10.9의 갱신 정책과 2.10.15의 함정 표를 읽는다. 정책·법무 담당자는 2.10.12의 비교표와 2.10.14만 읽어도 된다.

기준 시점과 정직성. 이 장은 2026년 10월을 기준으로 작성한 기술 장이며 지식은 2026년 중반까지다. 태스크 집합과 실행 시간, 제어 루프의 지연 값은 원리를 보이기 위한 가상 값이며 특정 오토파일럿의 측정이 아니다. 제어 루프의 모터 지연·교차 주파수·위상 여유는 2.2.5의 기준 설계 값을 그대로 이어 사용했다. 오픈소스 오토파일럿의 구조·라이선스·기본 주기는 공개 문서로 확인한 것만 적었고 나머지는 (확인 필요)로 두었다. 수치는 파이썬(math)으로 계산했다.

2.10.2 개념·직관 — 비행 소프트웨어는 시간 제약을 준수해야 하는 소프트웨어다

멀티콥터의 피치 운동은 토크에서 위치까지 적분이 네 번이고 복원력이 없다(1.1.7.1). 그래서 제어 루프가 한 순간도 쉬지 못한다. 루프를 도는 소프트웨어가 입력을 받고 출력을 내는 데 걸리는 시간은 지연이고, 그 시간이 매번 다르면 지터다. 지연은 위상을 $-\omega\tau$만큼 깎고(2.10.6), 지터는 그 깎임이 변하는 것이다. 결론부터: 비행 소프트웨어의 품질은 기능의 개수가 아니라 가장 빠른 루프의 시간 버짓을 얼마나 준수하는가에서 결정된다.

그래서 구조는 세 가지를 충족해야 한다. ① 비행 중요 경로(센서 → 추정 → 제어 → 모터)가 느린 일(로그·통신·영상)에 막히지 않게 한다. ② 시간이 어긋나는 원인(실행 시간 변동·자원 대기·인터럽트 폭주)을 분석으로 막는다. ③ 소프트웨어가 바뀌어도 그 보장이 유지되게 변경을 통제한다(현장 갱신과 형상 관리).

세 축에서 요구가 다르다.

• 군용 드론은 소형 소모성은 오픈소스나 자체 코드로 빠르게 만들고, 대형 MALE·HALE과 무인 전투기급은 이중·삼중 비행 컴퓨터와 군 감항 요건(12.3)에 맞춘 개발을 한다. 노획되면 코드가 노출되므로 갱신 보안과 기술 보호가 따라온다(8.17).
• 민간 UAS는 PX4·ArduPilot 같은 오픈소스 스택과 그 상용 포크가 대부분이다. 갱신이 잦고(펌웨어 공중 배포) 인증 증거 대신 운용 한계로 위험을 관리한다. 제품 보안 규제(8.13)가 갱신 체계를 정한다.
• AAM은 비행 중요 소프트웨어에 DO-178C의 개발 보증 수준(DAL)이 붙고, 파티션 실시간 운영체제(RTOS) 위에 올리며, 갱신은 형상 관리와 계속감항 절차를 거친다(8.22·20.23).

2.10.3 계층 구조와 모듈 간 통신

2.10.3.1 계층 — 드라이버에서 임무 관리까지

오토파일럿의 소프트웨어는 센서를 읽는 쪽에서 모터를 돌리는 쪽까지 하나의 사슬이다. 사슬의 마디가 계층이고 각 계층의 주기가 다르다.

ArduPilot의 멀티콥터는 기본 주 루프가 400 Hz이고 SCHED_LOOP_RATE 매개변수로 바꾼다. 4.7판에서는 각속도 PID를 자이로 속도에 가깝게 돌리는 선택지가 생겼다(공식 문서에 따름, 값은 판마다 다르다 (확인 필요)). 위 표의 주기는 이런 설정의 대략이다. 같은 계층도 기체와 기체의 크기에 따라 주기가 달라진다. 시간 척도가 느린 큰 기체(1.1.7.3)는 더 낮은 주기로도 충분한 경우가 많다.

2.10.3.2 모듈 사이를 잇는 방식

계층을 잇는 방식은 크게 셋이다.

PX4는 모듈이 uORB라는 발행–구독 메시지 버스로 대화한다(공식 문서에 따름). ArduPilot은 기능 라이브러리를 주기 스케줄러가 호출하는 구조에 가깝다 (구조 요지, 상세는 9.6). 어느 쪽이든 비행 중요 경로는 호출 순서와 최대 지연을 분석할 수 있게 해야 한다. 임무 컴퓨터와의 연결은 좁은 메시지 인터페이스(9.5)나 미들웨어(9.6)로 한다.

2.10.3.3 시간 기준과 자료의 신선도

센서 값은 측정한 순간의 값이다. 사용하는 순간에는 이미 낡았다. 제어에 사용하는 값의 나이 $a=t_{\text{사용}}-t_{\text{측정}}$는 사슬의 단계마다 쌓인다(센서 내부 필터, 읽기, 추정, 제어). 그래서 모든 메시지에 측정 시각의 타임스탬프를 붙이고, 가능하면 하드웨어 타이머가 인터럽트 순간에 직접 찍는다. 타임스탬프가 틀리면 적분 오차가 생긴다. 자세 적분의 오차는 각속도에 시각 오차를 곱한 값이라, 100°/s로 도는 기체에서 1 ms 시각 오차는 0.1°다. 시각 동기와 센서 보정은 2.1이 다룬다.

구독 방식에는 두 의미가 있다. 최신 값(제어용: 늦게 온 옛 값은 버리고 가장 새 값만 사용한다)과 큐(로그용: 모든 값을 순서대로 받는다). 제어 경로에 큐를 사용하면 부하가 몰릴 때 낡은 값을 계속 처리하느라 나이가 쌓인다. ARINC 653의 샘플링 포트(최신 값과 유효 표시)와 큐잉 포트가 같은 구분이다(2.10.7).

2.10.4 실시간과 스케줄 가능성 — 원리

실시간은 빠르다는 뜻이 아니라 마감을 보증한다는 뜻이다. 마감을 놓쳤을 때의 결과로 세 가지로 나눈다.

태스크 $i$를 주기 $T_i$, 최악 실행 시간 $C_i$(WCET), 마감 $D_i$(대개 주기와 같다)로 둔다. 출력이 나오는 시각의 변동폭이 지터($J$)다. 스케줄링은 세 방식이 사용된다. 주기 실행기는 시간표대로 호출해 분석이 쉽지만 한 곳을 바꾸면 전체를 다시 짠다. 고정 우선순위 선점은 주기가 짧은 태스크에 높은 우선순위를 주는 비율 단조(RM) 방식으로, 대부분의 RTOS 오토파일럿이 이 방식이다. EDF(가장 이른 마감 우선)는 이용률 100 %까지 사용하지만 과부하일 때 어디서 깨질지 예측하기 어렵다.

이용률 한계(Liu–Layland, 1973). 마감이 주기이고 태스크가 독립이면, 이용률 $U=\sum C_i/T_i$가 다음 한계 이하면 비율 단조로 반드시 스케줄된다.

$$U\le n\left(2^{1/n}-1\right),\qquad n\to\infty:\ \ln 2\approx0.693$$

결론부터: 이 식은 충분조건이다. 넘었다고 실패가 아니고, 주기가 서로의 배수(하모닉)이면 1까지 가능하다. 넘으면 정확한 판정이 필요하다.

응답 시간 해석(Joseph·Pandya 1986, Audsley 등 1993). 태스크 $i$의 최악 응답 시간 $R_i$는 자기 실행, 낮은 우선순위가 쥔 자원 때문에 기다리는 블로킹 $B_i$, 높은 우선순위의 방해로 구한다.

$$R_i=C_i+B_i+\sum_{j\in hp(i)}\left\lceil\frac{R_i}{T_j}\right\rceil C_j$$

양변에 $R_i$가 있어 $R_i=C_i+B_i$에서 시작해 값이 변하지 않을 때까지 되풀이한다. $R_i\le D_i$이면 통과다. 정확하고 태스크별 여유를 준다.

블로킹과 우선순위 역전. 높은 우선순위 태스크가 낮은 태스크가 쥔 뮤텍스를 기다리는데, 그 사이 중간 우선순위 태스크가 낮은 태스크를 계속 선점하면 높은 태스크가 무한정 기다릴 수 있다. 1997년 화성 탐사선 패스파인더는 이 우선순위 역전으로 감시 타이머가 시스템을 리셋했고, 뮤텍스의 우선순위 상속을 켜서 해결했다고 공개 보고되었다. 우선순위 상속은 역전을 유한하게 만들 뿐 기다림이 사라지지 않는다. 임계 구역이 길면 여전히 문제다(2.10.5).

WCET는 어떻게 아는가. 두 가지다. 정적 분석은 코드 경로와 하드웨어 모형으로 상한을 구하고 캐시·파이프라인이 복잡하면 보수적이 된다. 측정 기반은 시험으로 최댓값을 잰다. 그런데 측정한 최댓값은 상한이 아니다. 발생 확률 $p$인 느린 경로(캐시 충돌 연쇄, 드문 분기)를 $N$번 시험에서 못 볼 확률은 $(1-p)^N$이다.

읽는 법: 만 번 재서 최댓값이 안정되어 보여도 $10^{-4}$짜리 느린 경로를 놓칠 확률이 37 %다. 그래서 측정 기반 WCET에는 안전 배율을 곱한다. 다음 절은 그 배율을 얼마로 해야 하는지를 스케줄 계산에서 읽는다.

2.10.5 수치 예시 I — 스케줄 가능성

가상의 비행 컴퓨터(수백 MHz급 MCU)에서 도는 7개 태스크를 가정한다. 각속도·자세 루프(추정 예측과 믹서 포함)는 2.2.5의 기준 설계에 맞춰 400 Hz(2.5 ms)로 돌고 위치·속도 제어는 50 Hz(20 ms)다. WCET는 측정 기반으로 얻었다고 본다. 우선순위는 비율 단조다.

① 이용률 한계는 판정하지 못한다. $U=0.791$이고 $n=7$의 한계는 $0.729$다. 한계를 넘었으므로 이용률만으로는 "스케줄 가능"을 보증할 수 없다. 그러나 응답 시간 해석으로는 모든 태스크가 마감의 39 % 이내에 끝난다. 한계를 넘은 것과 실패는 다르다.

② 여유는 병목이 정한다. 모든 실행 시간을 같은 배율 $\alpha$로 키우면 $\alpha=1.26$까지 통과하고 병목은 가장 낮은 우선순위의 로그 태스크다. 태스크 하나만 키우면 각속도·자세 루프는 1.75배(0.70 → 1.22 ms), 추정 보정은 2.3배(1.6 → 3.7 ms)까지 여유가 있다. 따라서 모든 실행 시간이 한꺼번에 26 % 넘게 늘면 깨진다는 것이 이 집합의 안전 배율 요구다.

③ 기능을 추가하면 여유가 사라진다. 영상 위치 보정(30 Hz, 6 ms)을 비행 컴퓨터에 더하면 $U=0.971$이다. 응답 시간 해석은 여전히 통과(로그의 $R/D=0.96$)지만 여유 배율 $\alpha_{\max}$는 1.03으로 줄어든다. 측정이 3 %만 틀려도 마감을 놓치는 태스크가 생긴다(처음에는 로그, 8 % 틀리면 페일세이프).

④ 깨질 때 무엇이 먼저 마감을 놓치는가. 위 집합(영상 보정 포함)에서 실행 시간을 $\alpha$배로 키웠을 때 마감을 놓치는 태스크는 다음과 같다.

비율 단조는 위험도를 모른다. 페일세이프 태스크는 50 ms 주기라 우선순위가 낮고, 과부하가 오면 안전망이 영상 보정보다 먼저 마감을 놓친다(배율 1.08). 이 태스크는 실행이 0.8 ms로 짧아 높은 우선순위에 올려도 다른 태스크에 주는 방해가 작다. 올리면 영상 보정과 로그가 먼저 희생되고 안전망은 남는다. 우선순위를 주기가 아니라 위험도와 실행 시간으로 정하라는 교훈이다. 각속도·자세 루프는 어느 쪽에서도 마지막까지 마감을 준수한다.

⑤ 블로킹은 이용률에 나타나지 않는다. 로그 태스크가 센서와 공유하는 SPI 버스의 뮤텍스를 CPU 시간 3 ms 동안 쥔다고 하자. 각속도·자세 루프의 마감은 2.5 ms다(집합 A).

우선순위 상속 없이는 중간 태스크들이 임계 구역을 늘려 15.9 ms까지 기다린다(패스파인더와 같은 유형). 상속을 켜도 3 ms 구역은 2.5 ms 루프에 너무 길다. 고칠 곳은 구역의 길이다. 이용률은 세 경우 모두 같다. 이 지터 0.13·3.4·17.4 ms가 다음 절의 입력이다.

2.10.6 수치 예시 II — 지터가 위상 여유를 깎는다

앞 절의 스케줄 해석이 준 지터가 각속도 루프의 위상 여유에서 몇 도가 되는지 본다. 루프는 2.2.5의 기준 설계를 그대로 사용한다. 각속도 루프는 적분기(1.1.7.1)에 모터·프로펠러의 1차 지연과 순수 지연이 더해진 모양이고 PID의 미분 항이 위상 앞섬 $\phi_D$를 더한다. 교차 주파수 $\omega_c$에서의 위상 여유는

$$\mathrm{PM}\approx90^{\circ}-\arctan(\omega_c\tau_m)-\omega_c\,T_d\cdot\frac{180^{\circ}}{\pi}+\phi_D$$

이다. $\tau_m$은 모터 1차 지연, $T_d$는 순수 지연의 합이다. 지터는 최악의 경우 순수 지연을 $J$만큼 늘리는 것으로 본다. 순수 지연은 이득을 바꾸지 않으므로 교차 주파수는 그대로이고 위상만 $\omega_c J$ 라디안 깎인다.

$$\mathrm{PM}(J)=\mathrm{PM}_0-\omega_c\,J\cdot\frac{180^{\circ}}{\pi}$$

식의 검증. 2.2.5는 총 지연을 5·10·20 ms 늘리면 위상 여유가 48°·41°·27°로 준다고 계산했다. 위 식은 $55^{\circ}-1.43^{\circ}\times J$로 47.9°·40.7°·26.5°를 준다. 같은 값이다. 제어 주기를 400 Hz에서 100 Hz로 낮추면 샘플 지연과 영차 유지가 $1.5\times(10-2.5)=11.25$ ms 늘고(2.2.5의 "약 11 ms"와 같다) 위상이 16° 줄어든다.

세 모터 지연(2.2.5의 표에서 교차 주파수와 위상 여유를 가져왔다)에 대해 지터별 위상 여유는 다음과 같다. 마지막 열은 위상 여유를 30°까지 허용하는 지터다.

읽을 것 넷.

1. 지터 1 ms가 가져가는 위상은 $\omega_c$에 비례해 기준 설계에서 1.43°다. 지터 버짓 17.5 ms는 얼핏 넉넉하지만 소프트웨어가 만든 지터는 이보다 훨씬 클 수 있다.
2. 스케줄 해석이 준 최악 지터가 위상 여유 버짓으로 들어간다. 앞 절 ⑤의 0.13·3.4·17.4 ms는 위상 여유를 54.8°·50.1°·30.2°로 만든다. 3 ms 구역은 위상 손실로는 4.9°뿐이지만 마감(2.5 ms)을 놓치는 별개의 문제다. 마감을 놓치면 출력이 한 주기 늦거나 건너뛰어 이 식의 가정보다 나쁘다 (구현에 따라 다르다). 우선순위 역전은 위상 여유를 하한 30°까지 내린다.
3. 느린 모터(큰 기체)는 지터 버짓이 더 작다. 모터 지연 60 ms에서는 8 ms, 90 ms에서는 이미 0이다. 교차 주파수가 낮아 지터 1 ms당 손실(1.12°·0.95°)은 작지만 출발점 여유가 작기 때문이다. 큰 기체(1.7.6)일수록 소프트웨어의 시간 규율이 중요하다.
4. 주기는 두 제약이 정한다. 위상만 보면 샘플 지연($T_s$)과 영차 유지($T_s/2$)가 위상을 $1.5\,\omega_cT_s$ 라디안 깎으므로 손실 5° 이내는 $T_s\le\dfrac{5^{\circ}(\pi/180^{\circ})}{1.5\,\omega_c}=2.3$ ms(약 430 Hz)다. 400 Hz는 이 버짓의 약 5.4°를 사용한다. 그런데 앨리어싱이 다른 제약을 건다. 호버 4P(374 Hz, 1.29.3)는 400 Hz 제어 주기의 나이퀴스트 주파수(200 Hz)보다 높아 그대로 표본하면 접힌다(1.29.5). 그래서 IMU는 제어 주기보다 훨씬 빠르게 읽고 저역통과로 걸러 낮춘다. 필터가 위상을 더 가져가는 대가(저역통과 2.8 ms)는 이 표에 이미 들어 있다.

2.10.7 파티셔닝 — ARINC 653의 시간 창

ARINC 653은 IMA의 파티션을 위한 응용 인터페이스(APEX)와 구성 방식을 정한 규격이다(Part 1 보충판 5, 2019). 구조 요지는 다음과 같다.

• 파티션이 공간(메모리)과 시간(창)의 단위다. 파티션 안에서는 여러 프로세스(태스크)가 우선순위로 선점 스케줄된다.
• 모듈 스케줄은 정적 시간표다. 한 번 도는 주 프레임 안에 파티션마다 하나 이상의 창이 정해져 있고 창이 끝나면 강제로 다음 파티션으로 넘어간다.
• 포트가 파티션 사이 통신의 유일한 통로다. 샘플링 포트는 최신 메시지 하나와 유효 표시를 포함하고, 큐잉 포트는 순서대로 쌓는다.
• 건전성 감시(HM)가 프로세스·파티션·모듈 수준의 오류를 정해진 대응(재시작·정지)으로 처리한다.

같은 역할을 하는 분리 커널과 하이퍼바이저를 상용 항공용 RTOS가 제공한다 (제품은 예시이며 인증 현황은 확인 필요). 소형 UAS는 대부분 이런 분리 없이 단일 RTOS 위에 모듈을 올리고, 비행과 임무를 물리적으로 다른 칩(2.9.3.3)으로 분리해 같은 효과를 얻는다.

시간 창의 비용. 창은 격리를 주지만 지연과 맞바꾼다. 각속도·자세 루프(400 Hz, $\omega_c=24.9$ rad/s)를 가진 비행 제어 파티션을 두 방식으로 배치해 본다.

앞의 배치는 비행 파티션이 4 ms 창 안에서 루프를 한두 번 돌고 6 ms를 쉰다. 센서 값이 창 시작을 기다리는 동안 낡고 위상이 8.6° 줄어든다. 뒤의 배치는 창이 루프 주기마다 열려 지연 손실이 2.1°로 줄지만 전환 비용으로 처리 시간의 2.4 %가 나간다. 격리를 위한 시간 분할이 제어 루프의 주기와 연동되도록 창을 쪼개야 한다는 뜻이다. 멀티코어에서는 코어를 분할하여 사용하는 방식도 가능하지만 공유 자원 간섭(2.9.4)이 따라온다.

2.10.8 비행 모드 상태 기계와 안전 모니터

2.10.8.1 비행 모드

비행 모드는 누가·어느 수준으로 기체를 몰고 있는가의 약속이다. 상태 기계로 만들어야 모든 전환이 명시된다.

설계 원칙 다섯 가지다. ① 한 순간에 명령 권한은 하나다. ② 진입과 이탈 조건을 표로 작성한다. ③ 안전 전환이 임무 전환보다 우선한다. ④ 전환 때 명령이 급변하지 않게(적분기·설정값을 현재 상태로 초기화) 한다. ⑤ 현재 모드를 조종사와 운용자가 오해하지 않게 표시한다(8.18의 모드 혼동). 비상 대응 모드의 로직은 2.6이 다룬다.

2.10.8.2 안전 모니터 구조

주 소프트웨어가 틀릴 수 있다는 전제에서 독립 감시를 둔다. 세 방식이다.

① 워치독. 주기 신호를 받지 못하면 리셋하거나 안전 출력을 낸다. 가장 간단하지만 살아 있다는 신호가 곧 정상이라는 뜻은 아니다. 주 루프가 멈춰도 그와 무관한 타이머 인터럽트가 신호를 주면 소용없다. 그래서 신호는 핵심 태스크가 모두 진행했을 때만 낸다(창이 있는 워치독, 진행 점검).

② 독립 감시기. 별도 MCU가 같은 센서나 주 컴퓨터의 출력을 받아 범위·변화율을 검사하고, 어기면 안전 상태로 보낸다. 주 프로세서와 별도의 입출력 코프로세서를 둔 보드 구성이 있다 (구조 요지, 제품별 확인). 감시기가 주 계통과 다른 하드웨어·소프트웨어·팀이어야 공통 원인이 줄어든다(1.16.7.1, 2.5).

③ 런타임 보증(심플렉스 구조). 고성능 제어기(복잡하고 검증이 어렵다) 옆에 검증된 단순한 안전 제어기를 두고, 결정 모듈이 고성능 제어기의 출력이 안전 영역을 벗어나려 하면 안전 제어기로 넘긴다. 복잡한 기능(기계학습)을 사용할 때 보증을 감시기 쪽에 모으는 방법이다. ASTM F3269-21이 이 접근을 다룬다(7.8).

감시의 대가는 오경보와 미탐지의 교환이다. 문턱을 조이면 정상 비행을 끊고 풀면 고장을 놓친다(2.5).

2.10.9 현장 갱신 — 보안 부팅·이중 이미지·롤백

비행 소프트웨어는 출고 뒤에도 바뀐다. 오류 수정·기능·보안 패치다. 갱신은 가장 흔한 안전 사건의 출발점이기도 하다. 잘못된 이미지, 전원이 끊긴 갱신, 설정 불일치가 모두 기체를 못 날게 하거나 위험하게 한다. 구조는 다음 사슬이다.

• 보안 부팅. 변경할 수 없는 첫 코드(ROM)가 다음 단계의 서명을 검증하고, 각 단계가 다음 단계를 검증한다. 서명이 틀리면 실행하지 않고 복구 상태로 간다. 서명 키의 보관과 폐기는 8.13·9.19가 다룬다.
• 이중 슬롯(A/B). 새 이미지를 비활성 슬롯에 기록하고 검증한 뒤 다음 부팅 때 전환한다. 기록하는 중에 전원이 끊겨도 기존 슬롯이 남아 벽돌이 되지 않는다.
• 확정과 롤백. 새 이미지가 부팅한 뒤 자체 시험을 통과해야 확정(commit)한다. 통과하지 못하거나 감시 타이머가 리셋하면 이전 슬롯으로 돌아간다.
• 롤백 방지 카운터와의 충돌. 보안은 옛 취약 버전으로 되돌아가지 못하게 버전 카운터를 둔다. 안전은 새 버전이 나쁠 때 옛 버전으로 돌아갈 수 있기를 요구한다. 카운터는 새 이미지가 확정된 뒤에만 올리고, 직전 슬롯은 최소 허용 버전을 만족하도록 관리한다.
• 갱신 정책. 비행 중에는 하지 않는다. 지상에서 전원 여유(배터리 하한)·기체 정지·구성 일치를 확인하고 한다. 적용된 버전·파라미터를 로그에 남긴다(8.23).
• 갱신 중 오염 방지. 이미지는 해시·서명으로 무결성을 확인하고 전송 중 끊김은 재개한다. 항공 분야에는 갱신 가능 소프트웨어의 적재 체계(ARINC 665 적재 소프트웨어 표준, ARINC 615A 적재 장치)가 있다 (소형 UAS에는 거의 쓰이지 않는다).

전송 시간은 링크가 정한다. 유효 처리율을 공칭 속도의 절반으로 가정하면(프로토콜 오버헤드·재전송) 다음과 같다.

읽을 것: 작은 텔레메트리 무선으로 큰 이미지를 갱신하는 것은 현실적이지 않다. 큰 이미지는 지상 연결(이더넷·USB)이나 델타 갱신으로 하고, 무선 갱신은 작은 MCU 이미지와 설정에 사용한다. 내부 플래시가 수 MB인 MCU는 이중 슬롯을 두기 어려워 외부 저장소에 이미지를 받아 두었다가 부트로더가 옮겨 사용하는 설계가 흔하다.

2.10.10 오픈소스·파라미터·로그·시험

2.10.10.1 오픈소스를 인증에 사용할 때

PX4와 ArduPilot은 오래 사용되어 온 성숙한 소프트웨어다(비행 이력의 규모는 공개 자료로 확인하지 못했다). 그러나 인증 증거는 성숙도와 다르다. DO-178C의 객체 목표는 DAL별로 A 71·B 69·C 62·D 26개이고(2차 자료), 구조적 커버리지는 DAL A에서 MC/DC, B에서 결정 커버리지, C에서 구문 커버리지다.

현실적 경로는 셋이다. ① 비행 중요 기능에는 사용하지 않고 임무·보조 기능에만 사용한다. ② 오픈소스를 감시기로 감싼다(2.10.8.2의 런타임 보증). 그것이 운용 승인에서 완화 수단으로 인정되는지는 당국과 운용 위험 평가에 달려 있다(17.17). ③ 인증 가능한 작은 코어를 새로 만들고 오픈소스는 그 바깥에서 사용한다. 두 번째 경로가 소형·중형 UAS의 현실이고, 세 번째가 AAM의 현실이다(20.9).

2.10.10.2 설정과 파라미터 관리

오토파일럿은 같은 펌웨어라도 파라미터에 따라 다른 기체다. 이득·한계·센서 보정·페일세이프 정책이 모두 파라미터에 들어 있다. 그래서 파라미터는 코드와 같은 형상 항목이다(8.22). 기본 규칙은 다섯이다. ① 기체별 기준선을 두고 변경 이력을 남긴다. ② 범위·단위를 검증한다. ③ 해시나 서명으로 무결성을 확인한다. ④ 비행 전 점검에서 펌웨어 판과 파라미터 해시를 지상국이 확인한다(16.5). ⑤ 로그에 파라미터의 값과 변경 시각을 기록한다.

파라미터가 안전 여유를 움직이는 크기는 2.2.11이 계산했다. 모터 지연이 30 ms에서 60 ms로 바뀌면(프로펠러·ESC 교체) 위상 여유가 55°에서 39°로, 자이로 저역통과를 80 Hz에서 20 Hz로 낮추면 43°로, 필터를 추가해 지연이 10 ms 늘면 41°로 준다. 이득과 필터 하나가 여유를 10~20° 움직이므로 사용자가 설정을 바꿔 인증 범위를 벗어나는 일을 막는 구조가 필요하다. 파라미터를 세 등급으로 나눈다. ① 잠금(필터·안전 한계·페일세이프 정책. 서명된 변경만 받고 변경하면 안정 여유를 다시 입증한다, 20.6). ② 범위 제한(사용자가 조정하되 허용 범위 안에서만). ③ 자유(표시·편의 설정). 오픈소스 오토파일럿은 대부분의 파라미터를 비행 중에도 바꿀 수 있게 열어 두므로, 인증이나 운용 승인을 받는 제품은 등급 구분을 소프트웨어가 강제해야 한다.

2.10.10.3 로그

로그는 사고 조사의 증거이고 진동·성능 분석의 자료다(8.23). 로그를 사용하는 일이 제어를 막아서는 안 된다. 비트율과 버퍼를 계산해 본다.

저장 매체가 사용하기를 잠깐 멈추는(블록 지우기·SD 카드 내부 정리) 시간이 50~100 ms라면 필요한 링 버퍼는 비트율에 지연을 곱해 약 4~8.5 kB다. 진동 진단을 위해 IMU 원시 신호를 8 kHz로 기록하면(24 B, 192 kB/s) 100 ms 지연에서 다른 항목과 합쳐 약 28 kB가 필요하다. 이 버퍼가 부족하면 자료가 빠지고, 로그 태스크가 버퍼를 기다리며 높은 우선순위 태스크를 막으면(2.10.5 ⑤) 제어가 깨진다. 로그 쓰기는 낮은 우선순위 태스크로 두고 센서 버스와 임계 구역을 공유하지 않으며, 버퍼가 차면 로그를 버리지 제어를 막지 않는다.

2.10.10.4 시험 — SITL·HITL과 WCET

시험은 네 층이다. 단위·정적 분석(코드 규칙 검사 포함), SITL(소프트웨어를 시뮬레이터에 붙여 비행 로직을 반복 시험), HITL(실제 비행 컴퓨터를 시뮬레이터에 붙여 실시간·인터럽트·드라이버 시험), 비행시험(8.20)이다. 방법과 도구는 8.19가 다룬다. 이 장의 관점에서 놓치기 쉬운 점은 둘이다. 첫째, SITL은 실시간성을 시험하지 못한다. 개인용 컴퓨터는 마감과 지터가 다르다. 시간 문제는 HITL과 실기에서 보인다. 둘째, WCET를 시험으로 재는 일은 2.10.4의 확률 문제다. 느린 경로를 일부러 일으키는 시험(캐시 비우기, 최대 부하의 동시 실행)을 추가하고, 부하를 가한 상태에서 측정한 최댓값에 안전 배율을 곱한다.

SITL·HITL의 연결 방식과 록스텝 시각 동기화는 8.28.7이 다룬다.

2.10.11 설계 트레이드오프

① 오픈소스 스택을 사용하고 독립 감시기로 감싼다. 개발이 빠르고 기능이 풍부하며 비용이 낮다. 감시기가 비행 종료·귀환 같은 안전 행동을 맡는다. 대가는 비행 중요 경로 자체의 인증 증거가 없다는 점과 업스트림 변경의 추적 부담이다. 소형·중형 UAS와 운용 승인 경로의 현실이다.

② 인증형 코어(파티션 RTOS와 DO-178C)를 직접 만든다. 증거가 완결되고 파티셔닝으로 임무 소프트웨어와 한 칩을 안전하게 나눠 사용한다. 대가는 비용과 시간, 기능 확장이 느린 것이다. 대형 AAM과 군 감항 대상 기체가 이 길이다.

③ 나눠 사용한다. 작은 인증 코어가 비행 중요 기능(각속도·자세·페일세이프)을, 오픈소스나 상용 스택이 고수준 기능(경로·임무)을 맡고 둘 사이를 좁은 인터페이스로 잇는다.

견해: 인증 목표가 있는 UAS와 AAM은 ③으로 가는 편이 낫다고 본다. 근거는 이 장의 계산 두 가지다. 첫째, 지터 버짓(2.10.6)은 각속도 루프가 정한다. 이 루프와 페일세이프만 시간 분석 대상으로 삼으면 증거 범위가 작다. 둘째, 영상 보정을 비행 컴퓨터에 탑재하면 여유 배율이 1.26에서 1.03으로 줄고 안전망이 먼저 깨진다(2.10.5 ③④). 고수준 기능을 인증 코어 밖에 두면 이 문제가 증거의 범위 밖으로 나간다. 반대로 소형 UAS 제조사는 ①의 속도와 비용을 포기하기 어렵다. 이때도 페일세이프와 각속도 루프의 우선순위와 마감 분석, 파라미터 기준선, 갱신의 롤백은 ①에서도 유지해야 할 최소선이다. 이 판단은 가정한 태스크 집합에 기대며 실제 기체의 측정으로 확인해야 한다.

2.10.12 세 축 비교

2.10.13 관련 규격·프로토콜

판 기호를 확인하지 못한 문서는 해당 장에서 확인한다. 유료 표준의 본문은 옮기지 않았다.

2.10.14 관련 규제·인증 요구와의 연결

2.10.15 함정과 한계

이 장의 한계다.

• 태스크 집합과 WCET는 가정이다. 실제 값은 대상 칩에서 측정해야 한다. 응답 시간 해석은 인터럽트 지연·문맥 교환·캐시·DMA 간섭을 단순화했다(2.9.4).
• 응답 시간 해석은 단일 코어·고정 우선순위를 가정한다. 멀티코어와 파티션 스케줄은 별도의 분석이 필요하다.
• 위상 여유 모형은 1차 지연과 순수 지연의 합이다. 진동 필터의 위상, 비선형(포화·양자화), 참 모터 모형, 자세 루프의 상호작용은 넣지 않았다. 교차 주파수·모터 지연·위상 여유 값은 2.2.5의 기준 설계를 그대로 사용했으므로 그 설계의 가정(2 kg 쿼드, 모터 지연 30 ms)에 같이 묶인다.
• 오픈소스 구조의 요지는 공개 문서의 범위다. 기본 주기와 모듈 구성은 판마다 다르다.
• DO-178C 객체 목표 수는 2차 자료의 값이다. 규정 원문은 읽지 못했다.

2.10.16 체크포인트·연구 질문

체크포인트

1. 7개 태스크의 이용률이 0.79이고 $n=7$의 Liu–Layland 한계가 0.73일 때 스케줄 가능 여부를 어떻게 판정하는가? 응답 시간 해석의 식을 작성하고 한 태스크에 적용하라.
2. 측정 기반 WCET에 안전 배율이 필요한 이유를 느린 경로의 확률로 설명하라.
3. 각속도 루프(교차 주파수 24.9 rad/s, 위상 여유 55°)에서 지터 3.4 ms는 위상 여유를 몇 도 깎는가? 모터 지연 60 ms 기체의 지터 버짓은 얼마인가?
4. 비율 단조 우선순위에서 과부하 때 페일세이프 태스크가 먼저 마감을 놓치는 이유와 해결 방법을 말하라.
5. 보안 부팅·이중 슬롯·확정·롤백이 각각 막는 위험을 말하고, 롤백 방지 카운터와 안전 롤백의 충돌을 푸는 방법을 설명하라.
6. 오픈소스 오토파일럿을 비행 중요 경로에 사용할 때 DO-178C가 요구하는데 없는 것 세 가지와 현실적 대응 경로를 말하라.

연구 질문 — 이 장에서 파생되는 열린 주제(25.7에 모은다)

1. 상용 SoC의 시간 보증 — 멀티코어 응용 SoC에서 임무 부하가 비행 제어 루프의 응답 시간에 주는 영향을 공개 벤치마크로 어떻게 상한 짓는가? 분리 방법(코어 고정·캐시 분할)의 효과는 얼마인가?
2. 위험도 기반 우선순위 — 임무의 위험도와 실행 시간을 함께 반영한 우선순위 할당이 비율 단조보다 과부하에서 얼마나 안전한가? 인증에서 어떻게 입증하는가?
3. 오픈소스의 사후 인증 비용 — PX4·ArduPilot의 특정 판에 대한 요구사항 역설계와 시험 자산 보강의 비용·기간을 공개 사례에서 추정할 수 있는가(20.9)?
4. 갱신의 안전 사건 데이터 — 현장 갱신이 원인이 된 무인기·eVTOL 사건의 공개 사례를 모아 갱신 절차의 약점을 분류할 수 있는가(8.24·8.25)?

1차 출처(이 장)

• Liu, C. L.; Layland, J. W., "Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment," Journal of the ACM, 20(1), 1973.
• Joseph, M.; Pandya, P., "Finding Response Times in a Real-Time System," The Computer Journal, 29(5), 1986.
• Audsley, N.; Burns, A.; Richardson, M.; Tindell, K.; Wellings, A., "Applying New Scheduling Theory to Static Priority Pre-emptive Scheduling," Software Engineering Journal, 8(5), 1993.
• Wilhelm, R. 외, "The worst-case execution-time problem — overview of methods and survey of tools," ACM Transactions on Embedded Computing Systems, 7(3), 2008.
• Burns, A.; Wellings, A., Real-Time Systems and Programming Languages, Addison-Wesley(판 확인 필요).
• Åström, K. J.; Wittenmark, B., Computer-Controlled Systems, Prentice Hall(판 확인 필요).
• Beard, R. W.; McLain, T. W., Small Unmanned Aircraft: Theory and Practice, Princeton University Press, 2012.
• RTCA DO-178C·DO-330, ARINC 653 Part 1, ASTM F3269-21, NIST SP 800-193, PX4·ArduPilot 공식 문서.

출처를 찾고 판을 추적하는 방법은 0.9에서 다룬다.

다음 장: 2.11에서 사람이 기체를 만나는 자리, 곧 지상통제소(GCS)와 원격조종국(RPS)의 설계를 본다. 정보 요구와 경보 체계, 영상·링크·표시를 합친 지연 버짓이 조종 한계를 어떻게 정하는지, 1대 조종과 1:N 운용의 차이를 다룬다.