제8부 안전·보안·시스템공학

8.8 소프트웨어·하드웨어 보증: DO-178C·DO-254·DO-330

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

8.2는 고장 조건의 등급에서 개발 보증 수준(DAL)이 정해지는 길을, 8.4는 그 등급과 확률 목표를, 8.7은 증거를 하나의 논증으로 묶는 방법을 다루었다. 이 장은 그 증거 가운데 소프트웨어와 복잡 전자 하드웨어의 개발 증거가 어떤 활동으로 만들어지는지를 본다. 비행 제어, 전력 관리, 비행 종료, 지상 통제 소프트웨어는 모두 이 증거를 요구받는다.

배우는 것:

• 소프트웨어를 확률로 입증할 수 없는 까닭 — 무고장 시험으로 확률 목표를 입증하는 데 필요한 비행시간의 계산과, 그 결과가 개발 보증 방식을 정당화하는 방식.
• DAL 할당표 — AC 23.1309-1E, SC-VTOL-01, EASA 경량 UAS 고위험 입증 방법(MOC)이 같은 고장 조건 등급에 어떤 수준을 배정하는가.
• DO-178C의 구조 — 프로세스, 계획서와 수명주기 자료, 레벨별 목표 수와 독립성, 요구 기반 개발과 추적성.
• 검증과 구조 커버리지 — 레벨별 구조 커버리지 요구, MC/DC에 필요한 시험 수, 시험 집합이 논리 결함을 잡아내는 비율.
• DO-254와 복잡 전자 하드웨어 — 단순·복잡 분류, 맞춤 소자(FPGA·ASIC), COTS 소자와 지식재산(IP), 회로기판.
• 도구 자격 인정, 다중코어, 당국 심사 — DO-330의 TQL, 모델 기반·정형 기법 보충 문서, AC 20-193의 간섭 분석, 심사 단계(SOI)와 참여 수준.

선수 지식: 8.2(DAL·FDAL·IDAL, 독립성), 8.4(FHA, 확률 목표), 8.7(증거의 무결성)을 읽었다고 가정한다. 인증 실무(계획서 제출, 심사 절차)는 20.9이, 환경시험과 전자기 적합성 시험은 8.9·8.10이 다룬다.

특히 중요한 독자: 인증 담당자는 8.8.3과 8.8.11을, 소프트웨어·하드웨어 엔지니어는 8.8.5~8.8.10을, 정책·법무 담당자는 8.8.3과 8.8.12를, 사업 담당자는 8.8.2와 8.8.12(어느 수준으로 준용할 것인가)를 중점적으로 읽는다.

기준 시점과 정직성. 2026년 10월 기준이고 지식은 2026년 중반까지다. 원문을 읽은 것: FAA AC 20-115D(2017-07-21), AC 20-152A(2022-10-07), AC 20-193(2024-01-08), AC 23.1309-1E(2011-11-17)의 그림 2와 21절, FAA Order 8110.49A(2018-03-29), EASA 인증 메모랜덤 CM-SWCEH-002 Issue 01(2011-08-11)의 4.5절·20절·21절, EASA MOC Light-UAS High Risk.2510-01(2025-02-11 최종)의 8.1절·9.3절, EASA SC-VTOL-01 Issue 1(2019-07-02)의 AMC VTOL.2510, JARUS SORA 2.5 본문의 표 14, NASA/TM-2001-210876(MC/DC 해설, 2001-05). 읽지 못한 것: RTCA DO-178C·DO-254·DO-330·DO-331~333·DO-248C(유료)와 EASA AMC 20-115·20-152·20-189·20-193의 본문, SORA 부속서 E. 따라서 DO-178C의 레벨별 목표 수(71·69·62·26)와 독립성 목표 수(30·18·5·2), 검증 목표 수(43·41·34·9)는 2차 출처(Wikipedia, arXiv:2311.04344)에서 가져왔고 원문 미확인이다. 구조 커버리지 요구는 DO-178B 표 A-7을 NASA 문서로 확인했으며 DO-178C 표의 대응은 원문을 보지 못했다. CM-SWCEH-002는 DO-178B 시대(2011) 문서이다. 이 장의 계산은 개념을 보이기 위한 가정 예이다.

8.8.2 개념 — 소프트웨어는 확률이 아니라 개발 보증으로 다룬다

하드웨어 부품의 고장은 마모와 노화에서 무작위로 일어나므로 고장률을 측정하고 목표와 비교할 수 있다. 소프트웨어의 오류는 개발 중에 만들어진 체계적 결함이다. 같은 입력과 같은 상태에서는 같은 결과를 내며, 복제한 채널은 오류까지 복제한다(8.2.6의 공통 원인 비율 $\beta$가 1에 가까워지는 이유이다). 그래서 소프트웨어에는 확률을 할당하지 않고 개발의 엄격함(DAL)을 요구한다.

규정은 이 구분을 문장으로 적는다. AC 23.1309-1E 21절과 EASA의 경량 UAS 고위험 입증 방법 9.3절은 같은 논리를 사용한다. 단순한 시스템은 철저한 시험과 직접 검증으로 개발 오류를 찾아 고칠 수 있다. 복잡하거나 고도로 통합된 시스템은 모든 상태를 알 수 없거나 시험 수가 비현실적이어서, 개발 보증으로 적합성을 보인다. EASA 문서는 소프트웨어나 복잡 전자 하드웨어를 포함한 시스템을 단순하다고 보지 않는다고 명시한다(원문 확인).

8.8.2.1 계산 — 시험 비행으로 입증할 수 있는 확률의 한계

시험으로 확률을 입증하려면 얼마나 비행해야 하는지 계산해 보자. 고장이 0건이면 신뢰도 $C$에서 고장률 $\lambda \le \lambda_0$임을 보이는 데 필요한 누적 시간은 포아송 모형에서 다음과 같다.

$$T = \frac{-\ln(1-C)}{\lambda_0}, \qquad C=0.95 \Rightarrow T = \frac{2.996}{\lambda_0} \approx \frac{3}{\lambda_0}$$

결론: 치명적 고장 조건의 목표 $10^{-9}$은 시험 비행으로 입증할 수 없다. 1,000대 기단이 연 3,000 FH씩 비행해도 1,000년이 걸린다. 고장이 한 건이라도 나오면 필요 시간은 더 늘어난다. 이 기단이 10년 동안 쌓는 $3\times10^{7}$ FH로 입증할 수 있는 가장 낮은 목표는 $10^{-7}$이다. EASA 경량 UAS 고위험 MOC의 SAIL VI 치명적 목표 $10^{-8}$도 같은 기단으로 100년이 걸린다.

이 계산은 모든 비행의 사용 환경이 같고 고장이 서로 독립이라는 낙관적 가정을 둔다. 실제는 더 어렵다. 소프트웨어 신뢰도를 시험으로 입증하는 일이 초고신뢰 수준에서는 불가능하다는 결론은 Butler와 Finelli(1993)의 논문으로 널리 알려졌으나, 이 장에서는 원문을 확인하지 못했다 (확인 필요). 8.7의 베이즈 갱신처럼 분석을 사전 정보로 사용하면 필요 시간이 줄지만, 그 사전 정보를 만드는 근거가 다시 개발 증거이다. 이 한계 때문에 AC 20-115D가 정하는 방식은 확률이 아니라 목표·활동·증거이다. 지침은 소프트웨어 수명주기 프로세스의 목표, 목표를 만족하는 활동, 만족했음을 나타내는 증거의 설명으로 구성된다(AC 20-115D 4.a, 원문 확인).

8.8.3 개발 보증 수준의 할당 — 규정이 정하는 표

고장 조건의 등급은 시스템 안전 프로세스가 정하고, 그 등급이 소프트웨어에 요구되는 최소 개발 보증 수준을 정한다(AC 20-115D 9.b(2), 원문 확인). AC 20-115D 6.e는 FAA가 특정 규정에 대해 고장 조건 등급과 소프트웨어 수준의 대응을 별도로 정하면 그 대응이 DO-178C 2.3절보다 우선한다고 밝힌다. 그래서 같은 "치명적"에도 항공기 등급에 따라 다른 수준이 배정된다.

AC 23.1309-1E의 수준은 주 계통(P)과 보조 계통(S) 순서로 읽는다. 표의 확률 목표는 8.4.4.2의 값과 같다. 이 표에서 읽을 수 있는 사실은 다섯 가지이다.

1. DAL은 고장 조건 등급만으로 정해지지 않고 항공기 등급과 확률 목표를 함께 본다. 같은 치명적 고장 조건이 Class I에서는 C, Class IV에서는 A이다. 확률 목표가 낮을수록 높은 수준이 배정된다.
2. 같은 확률 목표에서도 문서마다 수준이 다를 수 있다. $10^{-7}$ 치명적 목표에 AC 23.1309-1E Class II와 SC-VTOL-01의 0~1명 구분은 C를, EASA MOC의 SAIL V는 B를 배정한다. 반대로 중대 고장 조건에는 AC 23.1309-1E와 SC-VTOL-01이 C를, EASA MOC가 D를 배정한다. 이 차이의 이유는 읽은 문서에 설명되어 있지 않다 (확인 필요).
3. 무인 항공기는 탑승자가 없으므로 치명적 고장 조건이 제3자 사망을 뜻한다. EASA MOC는 운용 구역 안에서 기체를 잃는 고장 조건을 치명적으로 분류한다(8.4.4.1). 이 분류에서는 비행 제어·전력 관리·비행 종료 소프트웨어가 치명적 고장 조건에 기여할 가능성이 크다(8.4.4.1의 FHA 예).
4. 아키텍처로 수준을 낮추는 길은 제한적이다. EASA MOC의 주 4는 치명적 고장 조건에 관여하는 두 구성원에 최소 FDAL·IDAL C를, 나머지 구성원에는 D보다 낮지 않은 수준을 요구한다. 위험·중대 고장 조건에도 D보다 낮은 수준은 허용하지 않는다. SC-VTOL-01의 주 A는 기본 범주 2~6명·0~1명 구분에서 아키텍처에 의한 수준 하향을 인정하지 않고, AC 23.1309-1E 21.e는 그림 2에 이미 Class I~III의 하향이 반영되어 있어 추가 하향에 당국 승인을 요구한다.
5. 초기 할당은 기능 수준(FDAL)이고 그 기능에 기여하는 모든 품목의 IDAL은 FDAL과 같다. 대체 방법으로 ED-135·ARP4761A 부록 P의 아키텍처 기반 할당을 사용할 수 있다(EASA MOC 9.3.1, 원문 확인). 독립성과 공통 원인에 의한 하한은 8.2.6에 있다.

참고로 DO-178C 2.3절의 일반적 대응은 치명적=A, 위험=B, 중대=C, 경미=D, 영향 없음=E이며 레벨 E에는 목표가 없다 (원문 미확인, 2차 출처).

8.8.4 DO-178C의 구조 — 목표·활동·자료

AC 20-115D 6.a는 적용자가 할당된 소프트웨어 수준에 해당하는 모든 목표를 만족하고, 부속서 A 표들이 열거하는 수명주기 자료를 작성해 목표 만족을 보이라고 요구한다. 아래 그림은 이 수명주기의 구조와 당국 심사 시점이다.

수명주기는 계획, 개발(요구·설계·코드·통합), 그리고 전 구간에서 병행하는 통합 프로세스(검증, 형상 관리, 품질 보증, 인증 연락)로 나뉜다(AC 20-115D 4.a). 계획 단계의 산출물은 다섯 계획서와 세 표준이다(CM-SWCEH-002 표 4-1, 원문 확인).

수명주기 자료는 심사 단계마다 요구되는 범위가 늘어난다. 아래 표의 절 번호는 CM-SWCEH-002가 인용한 DO-178B의 번호이며, DO-178C의 번호는 원문을 확인하지 못했다 (확인 필요).

AC 20-115D 6.b는 DO-178C 9.3절이 정한 자료를 인증 담당 부서에 제출하라고 하고, 11절의 나머지 자료는 요청 시 제공하라고 한다(6.d). 레벨 D에서는 설계 기술서와 소스 코드가 형식증명 설계 자료에 포함되지 않는다(6.c). 당국이 인증 연락에 참여하지 않기로 하면 표 A-10의 자료를 작성한 때 인증 연락 목표가 충족된 것으로 본다(6.a).

8.8.4.1 레벨별 목표 수와 독립성

DO-178C 부속서 A는 표 A-1(계획)부터 A-10(인증 연락)까지 열 개이고, 레벨별 목표 수는 아래와 같다 (2차 출처, 원문 미확인).

결론: A에서 B로 내려가는 효과는 목표 수보다 독립성과 구조 커버리지에서 크게 나타나고, C에서 D로 내려가는 효과는 목표 수에서 가장 크다. A에서 B로 내려가면 목표는 2개 줄지만 독립성 목표가 12개 줄고 MC/DC 요구가 사라진다. C에서 D로 내려가면 목표가 36개 줄어든다. A에서 D까지는 전체 목표가 63 %, 독립성 목표가 93 % 줄어든다. 독립성은 검증 활동을 개발자가 아닌 사람이 수행하는 것이 기본이다(정의의 요지, 원문 미확인).

8.8.5 요구 기반 개발과 추적성

DO-178C의 개발은 요구에서 출발해 아래로 추적되는 구조이다. 시스템 요구가 소프트웨어에 할당되고, 고수준 요구(HLR)가 되며, 설계 중에 저수준 요구(LLR)와 구조가 나오고, 소스 코드와 객체 코드로 이어진다. CM-SWCEH-002 21절은 HLR이 "무엇을" 설계할지를, LLR이 "어떻게" 설계할지를 나타낸다고 설명한다(원문 확인). 추적성은 요구와 구현 같은 항목 사이의 연관을 보이는 증거이며, 위로도 아래로도 연결되어야 한다.

세 가지가 중요하다.

1. 파생 요구는 안전성 평가로 되돌린다. 설계에서 생긴 요구는 상위 요구로 추적되지 않으므로, 안전성 평가로 되돌리지 않으면 그 요구의 안전 영향이 평가되지 않는다. CM 21절은 파생 요구가 안전성 평가 프로세스에 피드백되어야 한다고 적는다. 8.4의 FHA·FTA가 소프트웨어 설계의 새 요구를 다시 평가하는 경로이다.
2. HLR과 LLR을 한 문서로 합치는 것을 EASA는 권고하지 않는다. DO-178B 5.0절은 소스 코드가 고수준 요구에서 곧바로 만들어지면 그 요구를 저수준 요구로도 본다고 적는다. EASA는 이 문장을 두 요구를 합치는 근거로 사용하는 것을 오용으로 본다. CM은 합치면 추적성이 약해지고, 변경 영향 분석이 어려워지며, 파생 요구를 놓칠 수 있고, 검증 목표의 만족을 보이기 어렵다고 열거한다. 합친 경우에도 두 요구를 따로 둔 개발과 같은 수준의 검증 활동을 유지해야 한다.
3. 매개변수 자료 항목(PDI)은 별도 프로세스가 필요하다. 실행 코드와 분리된 구성 자료(예: 제어 이득, 지오펜스, 배터리 곡선 파일)가 비행 거동을 바꾸면 DO-178C의 PDI 규정을 따른다. AC 20-115D는 DO-178B 프로세스를 신규 개발에 계속 사용하는 조건의 하나로, 구성 자료를 다루는 기존 프로세스가 이전 인증에서 FAA의 승인을 받았어야 하고 그런 프로세스가 없으면 DO-178C의 PDI 규정에 따라 새로 세우라고 한다(5.a(4), 원문 확인).

AC 20-115D 8.b·8.c는 두 형태의 소프트웨어에 추가 지침을 둔다. 현장 적재 소프트웨어(FLS) 는 손상이나 부분 적재에 대한 보호, 적재된 부품 번호의 확인 수단, 비행 중이나 안전 임계 단계에서 적재 기능이 의도치 않게 활성화되는 것을 막는 방호를 갖추어야 한다. 사용자 수정 가능 소프트웨어(UMS) 는 수정 가능한 부분을 할당된 소프트웨어 수준 이상으로 개발해야 한다. 무선 갱신(OTA)과 임무 데이터 갱신이 이 규정의 대상이 될 수 있다(8.13).

8.8.6 검증과 구조 커버리지

검증은 검토·분석·시험의 조합이며, 시험은 요구에서 출발한다. CM-SWCEH-002 4.5.3은 검증 심사의 목적을 소프트웨어 요구·설계·코드 통합이 검증되었고, 요구 기반 시험 커버리지와 구조 커버리지 기준을 달성할 것임을 확인하는 것으로 적는다. 요구 기반 시험은 정상 범위뿐 아니라 강건성 시험(비정상 입력, 경계값)을 포함한다. SOI 3의 심사 항목이 "요구의 시험 커버리지(정확성과 강건성)"이다.

구조 커버리지 분석은 요구 기반 시험을 보완한다. NASA 문서가 인용한 DO-248A 질의응답 43번은 목적을 세 가지로 적는다. 코드 구조가 소프트웨어 수준이 요구하는 정도로 검증되었다는 증거를 제공하고, 의도하지 않은 기능이 없음의 입증을 뒷받침하며, 요구 기반 시험의 철저함을 확립한다. 요구에 연결되지 않고 구현된 코드는 요구 기반 시험이 실행하지 않을 수 있고, 그런 코드가 의도하지 않은 기능이 될 수 있다는 것이 근거이다. 여기서 "요구 기반 시험이 실행했다"는 코드가 실행되었을 뿐 아니라 그 동작이 추적되는 요구와 비교되었다는 뜻이다.

질의응답 44번은 구조 분석과 구조 시험을 구분한다. 구조 시험은 코드에서 시험을 작성하는 방식이어서 구현되지 않은 요구를 찾지 못하고, 코드의 출력을 기대 결과로 삼는 편향을 낳는다. 구조 커버리지 분석이 시험되지 않은 코드를 발견하면 DO-178B 6.4.4.3에 따라 원인을 검토하고, 추가 시험이 필요하면 요구 기반으로 한다.

레벨별 요구는 다음과 같다(DO-178B 표 A-7의 목표 5~8, NASA/TM-2001-210876 확인).

DO-178C의 표 A-7에는 레벨 A에 대해 "소스 코드로 추적되지 않는 추가 코드의 검증" 목표(목표 9)가 명시되었다고 2차 출처가 전한다 (원문 미확인). 커버리지 기준의 정의는 아래와 같다.

MC/DC가 중요한 이유는 문장 커버리지가 약하기 때문이다. NASA 문서의 예에서 if (x > 1) and (y = 0)의 and를 or로 잘못 코딩해도 모든 문장을 한 번 실행하는 시험 하나가 이를 잡지 못한다. 판정 커버리지도 (A or B)에서 B의 영향을 시험하지 못한다.

소스 코드 대 객체 코드. 레벨 A~C의 구조 커버리지 분석은 소스 코드에서 할 수 있다(DO-178B 6.4.4.2b). 소스에서 얻은 커버리지가 객체 코드의 커버리지를 보장하지는 않는다. NASA 문서는 Beizer를 인용해, 소스 문장을 100 % 커버하는 시험이 논리 중심의 현대 코드에서 객체 코드 문장은 75 % 이하만 커버할 수 있다고 적는다. 그래서 레벨 A에서는 컴파일러가 소스 문장과 직접 추적되지 않는 객체 코드를 만들면 그 부분을 추가로 검증한다. 컴파일러의 단락 평가를 이용해 객체 코드에서 MC/DC와 같은 효과를 내려는 제안에는 소스 수준과 같은 효과의 분석이 필요하다(DO-248A 질의응답 42번). CM-SWCEH-002 20절은 당시 객체 코드 커버리지를 MC/DC의 대안으로 인정하는 지침이 없다고 적고, 소스 수준과 같은 최소 시험 수, 요구에서 만든 시험, 컴파일러 동작의 입증, 소스·설계·요구와의 추적성을 요구한다(DO-178B 기준, 2011). 최적화가 강한 컴파일러는 동작이 예측 불가능해질 수 있다는 점도 밝힌다.

하드웨어에서도 같은 구분이 있다. AC 20-152A 5.7은 HDL 코드 커버리지가 코드 요소가 요구 기반 시뮬레이션으로 실행되었는지 평가하는 요소 분석 방법으로 인정되지만, 요구 기반 시험의 완결성이나 요구 커버리지의 효과성을 평가하지는 않는다고 명시한다.

8.8.7 워크스루 — 시험 집합이 논리 결함을 잡는 정도

판정 Z = (A or B) and (C or D)(조건 4개, 입력 16가지)를 대상으로 구조 커버리지 기준을 만족하는 모든 최소 시험 집합이 단일 논리 결함을 잡는 비율을 계산했다. 결함은 조건 부정(4), 조건을 참·거짓으로 고정(8), 연산자 교체(3), 변수 자리 대체(12)의 27개이며 모두 원래 판정과 다른 함수이다(동치 변이 0개). 결함이 일으키는 결과 차이가 시험 집합의 어느 벡터에서든 나타나면 잡힌 것으로 센다.

MC/DC를 만족하는 최소 시험 집합은 $n+1=5$개이며 서로 다른 집합이 4개 있다. 한 예는 아래와 같다.

결론: 판정 커버리지를 만족하는 시험 집합 중 가장 나쁜 집합은 결함 27개를 하나도 잡지 못하고, MC/DC를 만족하는 모든 최소 집합은 27개를 모두 잡는다. 가장 나쁜 판정 집합은 모든 조건이 참인 벡터와 모든 조건이 거짓인 벡터의 쌍(TTTT와 FFFF)뿐이다. 이 쌍은 판정이 참과 거짓을 모두 내므로 판정 커버리지를 만족하지만, 어떤 조건도 독립적으로 시험하지 못한다. 가장 좋은 판정 집합(FFTT와 FTFT)도 17개(63 %)를 잡는다. 기준은 평균이 아니라 최악의 시험 집합에 대한 보장으로 비교해야 한다.

더 간단한 판정 A or B에서도 같은 경향이 나온다(결함 7개: 문장 0~42.9 %, 판정 57.1~85.7 %, MC/DC 100 %). 판정의 조건 수에 따른 시험 수는 아래 그림과 같다.

다중 조건 커버리지가 비현실적인 이유는 실제 코드의 판정 분포로 확인된다. NASA 문서의 표 2는 레벨 A 계통 5개 LRU의 Ada 코드(1995년)에서 조건 수별 판정의 개수를 센 값이다.

전체 판정은 20,256개이고 조건이 하나인 판정이 81.4 %이다. 조건이 6개 이상인 판정은 296개(1.46 %), 11개 이상은 77개, 21개 이상은 6개이다. 조건이 36개인 판정 하나의 다중 조건 커버리지는 $2^{36}=6.9\times10^{10}$개 시험이고, 초당 100개를 실행해도 $6.9\times10^{8}$초, 곧 21.8년이다. MC/DC는 같은 판정에 37개이다. 조건이 76개인 판정은 MC/DC가 77개, 다중 조건이 $7.6\times10^{22}$개이다.

이 계산의 한계가 있다. 결함 모형이 한 판정 안의 단일 논리 결함에 한정되고, 시험 값에 대한 기대 결과의 정확성은 가정하며, 반복 조건이 있는 판정(예: (A and B) or (A and C))은 다루지 않았다. MC/DC가 모든 결함 종류를 잡는다는 일반 결론은 이 계산에서 나오지 않는다. 반복 조건에서는 조건 하나의 독립 효과를 보이는 방식(유일 원인, 마스킹)의 선택이 필요하고, 구조 커버리지 도구의 판정 정의는 도구마다 다를 수 있다 (확인 필요).

8.8.8 DO-254와 복잡 전자 하드웨어

AC 20-152A는 DO-254(ED-80)를 인정하면서 맞춤 소자 개발, COTS IP 사용, COTS 소자 사용, 회로기판(CBA) 개발에 대한 추가 목표를 정한다. 적용 대상은 하드웨어 DAL A·B·C에 기여하는 전자 하드웨어이고, DAL D에는 이 AC의 사용이 요구되지 않는다(AC 00-72의 모범 사례를 사용할 수 있다). 다만 AC 23.1309-1E 21.d는 복잡 하드웨어 레벨 D의 검토 면제가 경미한 고장 조건에만 해당하며, 중대·위험 고장 조건에 낮춘 D에는 적용되지 않는다고 적는다(원문 확인). 단일 사건 영향(SEE)은 이 AC의 범위가 아니다.

8.8.8.1 단순과 복잡의 분류

맞춤 소자(PLD, FPGA, ASIC)는 설계 내용을 기술적으로 평가해 결정론적 시험과 분석의 포괄적 조합으로 모든 예측 가능한 운용 조건에서 정확한 기능 수행을 입증할 수 있을 때만 단순하다고 본다. 평가 기준은 기능의 수와 단순성, 인터페이스의 수와 단순성, 신호 처리·전달 함수의 단순성, 기능·블록 간 독립성이다. 디지털 부분에는 동기·비동기 여부, 독립 클럭의 수, 상태 기계의 수와 상태·전이의 수, 상태 기계 사이의 독립성이 추가된다. 단순 항목만으로 구성된 항목도 복잡할 수 있다.

단순 소자는 CD-2에 따라 기능 정의, 시험과 분석에 의한 완전한 검증, 소자를 재현하는 지침을 포함한 형상 관리, 제작 적합성 평가만 갖추면 된다. 복잡 소자는 DO-254와 AC의 추가 목표를 모두 따른다. 분류 근거는 하드웨어 인증 측면 계획서(PHAC)에 기록한다(CD-1).

8.8.8.2 AC 20-152A의 목표(원문 확인)

COTS 소자는 기능 요소들이 서로 상호작용하고, 상당한 수의 모드를 제공하며, 구성에 따라 데이터·자원 공유가 달라지는 경우 복잡하다. 다중코어 프로세서, 그래픽 처리, 네트워킹, 복잡한 버스 스위칭, 다중 마스터 상호연결 패브릭 같은 고급 처리 소자는 그 자체로 복잡하다(AC 20-152A 6.3). 다중코어 시스템 온 칩을 비행 제어 컴퓨터에 사용하면 이 기준에 해당할 가능성이 높다(추정). 복잡 COTS 소자는 가능한 모든 구성을 검증하기 어렵고 모든 잠재 고장을 식별하기 어렵다는 것이 이 AC의 전제이다. 그래서 정오표와 고장 모드를 안전성 평가로 되돌리고(COTS-5, COTS-6), 사용하지 않는 기능이 사용하는 기능의 무결성을 해치지 않음을 보이게(COTS-7, DAL A·B) 한다.

8.8.9 도구 자격 인정(DO-330)과 보충 문서

개발·검증 도구가 오류를 만들거나 오류 검출에 실패할 수 있으면 그 도구의 출력은 증거가 되지 못한다. AC 20-115D 10은 DO-178C 12.2절과 DO-330이 도구 자격 인정의 수용 가능한 방법이고, DO-330에 목표·활동·수명주기 자료가 따로 있다고 적는다. 자격 인정이 필요하면 시스템 안전성 평가가 할당한 소프트웨어 수준으로 도구 자격 인정 수준(TQL)을 정한다.

DO-330은 도구를 세 기준으로 분류한다 (기준 정의의 문구는 2차 출처, 원문 미확인). 기준 1은 출력이 비행 소프트웨어의 일부여서 오류를 삽입할 수 있는 도구(코드 생성기), 기준 2는 검증을 자동화해 오류를 못 찾을 수 있고 그 출력이 다른 검증·개발 프로세스를 줄이는 근거로 사용되는 도구, 기준 3은 사용 범위 안에서 오류를 못 찾을 수 있는 그 밖의 도구이다. TQL은 아래와 같다. 이 표는 AC 20-115D 표 2가 DO-178B의 도구 유형과 DO-330 기준·TQL을 대응시킨 값과 같다(원문 확인).

하드웨어는 DO-254의 도구 평가 흐름을 사용하고, AC 20-152A가 세 가지를 명확히 한다. 도구 출력을 완전하고 독립적으로 평가하면 도구 문제 보고서의 정식 평가가 필요 없다(CD-10). 설계 도구의 이력은 도구 자격 인정의 단독 근거가 되지 못한다(CD-11과 5.8). 코드 커버리지 도구가 요소 분석에만 사용되면 도구 평가를 면제하지만, 커버리지로 시험 사례를 자동 생성하고 요구 검증의 완료를 판단하면 검증 도구로 본다.

보충 문서. DO-331(모델 기반 개발·검증), DO-332(객체 지향 기술), DO-333(정형 기법)은 DO-178C와 함께 사용하며 단독 문서로 사용할 수 없다(AC 20-115D 8.a). 보충 문서를 사용하면 PSAC에 DO-178C와 보충 문서를 함께 적용하는 방법, 어느 목표가 어느 소프트웨어 구성요소에 적용되는지를 기술해야 한다. 모델로 코드를 만들 때 시뮬레이션만으로 만족하려는 검토·분석 목표는 식별하고 각각 시뮬레이션이 목표를 완전히 만족함을 상세히 정당화해야 한다(8.a(3)). 7.8의 정형 검증과 8.1의 모델 기반 시스템공학이 이 보충 문서와 연결된다.

기존 DO-178 계열로 승인된 소프트웨어의 재사용·수정에는 AC 20-115D 9가 사용 이력, 미해결 문제 보고서, 변경 영향 분석, 수준의 대응(표 1)을 요구한다. 이 규정은 이전에 DO-178 계열로 승인된 소프트웨어에 대한 것이며 승인 이력이 없는 소프트웨어(공개 소스 비행 제어 소프트웨어 등)에는 적용되지 않는다.

8.8.10 다중코어 프로세서와 COTS 소프트웨어

UAS와 eVTOL의 비행 제어 컴퓨터에도 다중코어 시스템 온 칩을 사용하는 설계가 늘고 있다(추정). 다중코어는 한 코어의 소프트웨어가 다른 코어와 공유 자원(메모리, 캐시, 상호연결, 주변장치)을 놓고 경합하게 하여 시간 간섭과 새로운 자료·제어 결합 경로를 만든다. AC 20-193은 이 간섭이 안전 임계 소프트웨어를 비결정적으로 거동시키거나 실행을 끝낼 시간을 빼앗을 수 있다고 적는다(3.4).

AC 20-193(2024-01-08, 원문 확인)의 적용 범위는 이렇다.

• 활성화된 코어가 둘 이상이고, 탑재 소프트웨어나 프로세서를 포함한 하드웨어 품목의 IDAL 중 하나라도 A·B·C이면 적용한다. 모두 D 또는 E이면 적용하지 않는다(2.2·2.3).
• 코어가 락스텝이거나, 공유 메모리·공유 캐시·일관성 패브릭이 없이 통상의 항공전자 데이터버스로만 연결된 경우의 상호작용은 대상에서 제외한다(2.7).
• 운영체제나 하이퍼바이저가 소프트웨어를 코어 사이에서 동적으로 재배치하는 플랫폼과 동시 다중 스레딩은 다루지 않는다(2.6.4·2.6.5). 소프트웨어는 기동 때 코어에 정적으로 배정된다고 가정한다.

목표는 계획(MCP_Planning_1·2), 자원 사용(MCP_Resource_Usage_1~4), 소프트웨어 검증(MCP_Software_1·2), 오류 처리(MCP_Error_Handling_1), 완료 요약서 자료(MCP_Accomplishment_Summary_1)이다. 핵심은 간섭 채널의 식별과 완화 검증(Resource_Usage_3)과 자원 수요가 가용량을 넘지 않음의 검증(Resource_Usage_4), 그리고 모든 탑재 소프트웨어가 의도한 최종 구성에서 충분한 시간에 실행을 끝낸다는 검증(Software_1)이다. 강건한 자원 분할과 시간 분할(robust partitioning)을 입증한 플랫폼은 소프트웨어를 따로 검증하고 WCET를 따로 구할 수 있지만, 그렇지 않은 플랫폼은 간섭이 회피·완화되지 않은 구성요소를 모든 소프트웨어가 실행되는 최종 구성에서 시험하고 WCET를 분석과 시험으로 확인해야 한다. IDAL C만 있으면 Resource_Usage_4와 Error_Handling_1은 요구되지 않고, 강건한 분할이 안전 분석에서 요구되지 않으면 간섭 분석을 생략할 수 있지만 그 경우 소프트웨어를 따로 검증할 수 없다(5.8과 주석).

8.8.10.1 어림 — 코어를 늘리면 WCET는 얼마나 늘어나는가

공정한 순환 중재기를 가정하면 공유 자원 접근 한 번은 최악의 경우 다른 코어의 접근 $(N-1)$번만큼 지연된다. 단독 실행 WCET를 $C_0$, 공유 자원 접근 횟수를 $a$, 중재 한 번의 지연을 $t_s$, 코어 수를 $N$이라 하면 상한은 다음과 같다.

$$C_N = C_0 + a\,(N-1)\,t_s$$

결론: 코어 6개가 모두 같은 자원을 경합하면 이 가정에서 마감 4 ms를 넘는다(4.60 ms). 마감을 만족하는 최대 코어 수는 5이다. 코어 하나일 때 25 %이던 주기 점유가 코어 수에 비례해 늘어나는 구조이므로, 단독 측정으로 구한 WCET는 다중코어 구성에서 효력이 없다. 이 모형은 AC의 방법이 아니라 어림이며, 캐시 일관성과 메모리 뱅크 충돌처럼 지연을 더 키우는 효과는 반영하지 않았다. AC 3.2는 소프트웨어가 단독 실행보다 훨씬 오래 걸릴 수 있다고 적는다. 그래서 AC는 간섭 분석을 하고 모든 코어가 실행되는 구성에서 시험하라고 요구한다.

COTS 소프트웨어. EASA MOC 9.3.3은 제어·감시 장치(CMU)의 COTS 소프트웨어 품목에 AMC 20-115( )에 더해 ED-109A·DO-278A 12.4절의 지침을 대안으로 인정한다. 소프트웨어 수준과 DO-278A 보증 수준의 대응은 DO-278A 표 2-2에 있다(원문 미확인). 미해결 문제 보고서(OPR)의 관리는 AMC 20-189가 다루나 본문은 읽지 못했다 (확인 필요).

8.8.11 당국 심사 — SOI와 참여 수준

EASA의 CM-SWCEH-002는 소프트웨어 수명주기 심사를 네 단계(SOI 1~4)로 정의한다. 이 메모랜덤은 FAA Order 8110.49의 같은 구조를 따르되, 각 심사 시점의 진행률 기준을 FAA 요구보다 높게 정했다(2.1절, 원문 확인). 아래는 그 정의이며 DO-178B 시대 문서이다. 2018년 판 Order 8110.49A의 2장에는 네 단계의 정의가 없다(본문에서 확인). 현재 EASA와 FAA가 같은 단계를 어떤 문서로 운영하는지는 확인하지 못했다 (확인 필요).

계획서와 소프트웨어 완료 요약서(SAS)는 심사 15 근무일 전까지 제출한다(표 4-1·4-4 주석). 자료가 불완전해도 심사할 수 있을 만큼 성숙해야 한다는 것이 진입 기준의 취지이다. 설계 심사(SOI 2)에서는 계획·표준의 변경이나 일탈에 대한 합의가 이루어질 수 있다.

8.8.11.1 당국 참여 수준(FAA Order 8110.49A)

Order 8110.49A(2018)는 이전 판의 5~16장을 중복과 충돌을 없애기 위해 삭제했다. 그 주제는 AC 20-115D·AC 00-69가 다루거나 제거되었다. 남은 것은 심사 절차(2장), 적합성 검사(4장), 참여 수준 워크시트(부록 A)이다. 참여 수준은 가능한 한 일찍 결정하고 기록해야 하며, 영향 요인은 소프트웨어 수준, 제품 속성(규모·복잡도·기능의 새로움·설계), 새 기술, 새로운 방법, 적용자의 경험, 대리인의 가용성이다. 워크시트는 예시이며 사용이 의무가 아니다.

워크시트 2는 적용자의 경험·개발 역량·서비스 이력, 현재 시스템의 복잡도·새로움, 대리인의 경험을 5개 범주 26개 기준으로 점수화한다. 만점은 212점이다(범주별 29·44·42·42·55점). 워크시트 3은 총점(TSR)과 소프트웨어 수준으로 참여 수준을 정한다.

결론: 첫 인증을 받는 개발자는 총점이 낮아 같은 소프트웨어 수준에서 당국이 더 깊이 참여한다. 레벨 B에서 TSR이 60이면 높음이고, 150이면 중간이다. 인쇄된 표는 TSR이 정확히 80이거나 130인 경우를 정하지 않았다. 이 점수의 정당화(각 항목의 척도가 어떻게 정해졌는가)는 문서에 없다. 소프트웨어 개발 경험이 없는 UAS·AAM 신생 기업은 경험 항목(1·2·5 범주)에서 점수가 낮아 높은 참여 수준을 예상해야 한다.

8.8.12 설계 트레이드오프 — 어느 수준으로 준용할 것인가

1. ① 완전 준용. DO-178C·DO-254와 보충 문서의 모든 목표를 만족하고 SOI 심사를 받는다. 장점은 증거가 가장 완전하고 당국의 수용이 쉽다는 점이다. 단점은 비용과 일정이 크고 개발 방식(애자일, 오픈소스 부품, 모델 기반)에 제약이 생긴다는 점이다. 형식증명을 목표로 하는 eVTOL과 EASA MOC의 SAIL V·VI 운용에 맞다.
2. ② 규모에 맞춘 준용과 아키텍처 감시기. 소프트웨어를 안전 기능(작은 코드)과 복잡 기능으로 분리하고 안전 기능에만 높은 수준을 적용한다. 장점은 높은 수준의 검증 노력이 작은 코드에 집중된다는 점이다. 단점은 분리(분할)의 독립성을 입증해야 하며, 입증 못 하면 전체에 높은 수준이 적용된다는 점이다. 중형 UAS, 학습 기반 기능을 사용하는 UAS에 맞다(7.1.9, 7.8).
3. ③ 산업 표준과 자체 프로세스. ASTM F3201(UAS 소프트웨어 신뢰성 확보 관행) 같은 산업 표준과 자체 프로세스로 개발하고 SORA OSO 수준에서 입증한다. 장점은 비용이 낮다는 점이다. 단점은 당국 수용이 사업별 협의에 달려 있고 형식증명으로 올릴 때 증거를 다시 만들어야 한다는 점이다. 소형·저위험 UAS에 맞다. ASTM F3201의 본문은 읽지 못했다 (확인 필요).

견해: 안전 기능의 소프트웨어를 최소로 줄여 높은 수준을 적용할 대상을 작게 유지한다. 근거는 세 가지이다. 첫째, 구조 커버리지와 독립 검증은 코드와 요구의 단위로 수행하므로 높은 수준의 대상이 작을수록 해당 활동이 줄어든다(논리적 추론이며 정량 자료는 확인하지 못했다). 둘째, AC 20-193은 탑재 소프트웨어와 하드웨어의 IDAL이 모두 D·E이면 다중코어 목표를 요구하지 않고, AC 20-152A는 하드웨어 DAL D에 이 AC의 사용을 요구하지 않는다. 셋째, EASA MOC의 주 4는 아키텍처를 고려하는 할당에서 치명적 고장 조건에 기여하는 두 구성원을 C로, 나머지를 D로 할 수 있게 한다. 다만 이 방식은 분할과 독립성의 입증이 필요하며, 공유 메모리·같은 프로세서·같은 라이브러리는 독립성을 약하게 한다(8.2.6).

공개 소스 비행 소프트웨어와 학습 기반 기능. EASA MOC는 공개 소스 소프트웨어를 정의하지만(5절 정의 (q)), 읽은 문서에는 이를 인증 증거로 인정하는 방법이 따로 없다 (확인 필요). DO-178C의 수명주기 증거는 만든 이의 계획·표준·검증 기록에 의존하므로, 공개 소스 코드를 사용하려면 같은 목표를 사후에 입증해야 한다. 학습된 가중치가 요구를 만족함을 보이는 목표는 DO-178C에 없다(7.4.8, 20.10).

8.8.13 세 축 비교

SORA 2.5 본문 표 14의 OSO#04(핵심 구성요소가 감항 설계 표준으로 설계됨)는 SAIL IV에서 낮음, V에서 중간, VI에서 높음이고, OSO#05(시스템 안전과 신뢰성을 고려한 설계)는 SAIL III에서 낮음, IV에서 중간, V·VI에서 높음이다(원문 확인). 각 수준의 세부 요구는 부속서 E에 있으며 읽지 못했다 (확인 필요).

8.8.14 관련 규격·프로토콜

전체 지도는 A.6에 있다.

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

• 개발 프로세스와 안전성 평가(8.2·8.4). FDAL이 이 장의 IDAL로 내려가고, 파생 요구는 FHA·FTA로 돌아간다. 독립성과 공통 원인 비율은 8.2.6이다.
• 안전 사례(8.7). 이 장의 SAS·검증 결과·도구 자격 인정 자료가 증거의 무결성과 보증의 재료이다.
• 형식증명과 TSO(20.4~20.6). 인증기준이 DAL 표를 정하고, 적합성 입증이 소프트웨어·하드웨어 증거를 참조한다. TSO 장비는 소프트웨어 수준과 하드웨어 DAL을 함께 선언한다.
• 소프트웨어·하드웨어 인증 실무(20.9). 계획서 제출과 SOI 심사의 절차이다.
• 설계 변경(20.7·8.22). 소프트웨어 수정은 변경 영향 분석(AC 20-115D 9.b(4))으로 재검증 범위를 정하고 형상 관리 기록이 이를 뒷받침한다.
• 사이버보안(8.11·8.13). 현장 적재 소프트웨어와 OTA는 이 장의 FLS 규정과 보안 규정이 함께 적용된다.
• 환경·전자기(8.9·8.10). 하드웨어의 환경 시험과 HIRF·낙뢰는 이 장과 별도 입증 항목이다. AC 23.1309-1E 22절은 DAL이 HIRF·낙뢰 방호 수준에는 적용되지 않는다고 명시한다.
• 신뢰성(8.21). 하드웨어 부품의 무작위 고장률은 확률 입증으로, 체계적 오류는 이 장의 개발 보증으로 다룬다.
• 학습 기반 기능(7.4·7.8·20.10). 요구 기반 검증이 적용되지 않는 부분은 런타임 보증과 별도 보증 표준이 맡는다.

8.8.16 함정과 한계

미해결 문제. 학습 기반 구성요소에 대한 DO-178C 목표의 부재, GPU·NPU가 포함된 시스템 온 칩의 간섭 분석, 공개 소스 비행 소프트웨어의 인증 증거 방법, EASA MOC가 SAIL V·VI에 AC 23.1309-1E·SC-VTOL-01과 다른 수준을 배정한 이유, DAL을 높일 때 실제 오류율이 줄어드는 정도는 이 장의 자료로 답할 수 없다 (확인 필요). 개발 보증이 소프트웨어 오류율을 낮추는 효과를 정량 측정한 공개 자료를 확인하지 못했다.

8.8.17 체크포인트·연구 질문

체크포인트:

1. 무고장 시험으로 $10^{-9}$을 신뢰도 95 %로 입증하는 데 필요한 시간과, 연 3,000 FH씩 비행하는 1,000대 기단이 그 시간을 누적하는 데 걸리는 햇수를 계산하라.
2. 같은 치명적 고장 조건이 AC 23.1309-1E의 Class IV, SC-VTOL-01의 0~1명 구분, EASA MOC의 SAIL VI에서 어떤 수준을 받는지 말하고, EASA MOC의 주 4가 아키텍처로 수준을 낮추는 조건을 설명하라.
3. 레벨 A와 레벨 B의 차이를 목표 수·독립성·구조 커버리지 세 면에서 설명하라.
4. 판정 (A or B) and (C or D)에서 MC/DC 최소 시험 수가 5인 까닭과, 판정 커버리지만으로는 결함을 잡지 못하는 시험 쌍의 예를 들라.
5. HLR과 LLR을 한 문서로 합치는 것을 EASA가 권고하지 않는 이유를 세 가지 말하라.
6. 다중코어에서 코어 5개일 때 WCET 3.88 ms가 4 ms 마감을 만족하는데도 AC 20-193이 간섭 분석을 요구하는 이유를 설명하라.

연구 질문(25.7에 모은다):

• 학습 기반 구성요소를 포함한 시스템에서 FDAL·IDAL 할당과 독립성 입증을 어떻게 정의할 것인가.
• SAIL V·VI의 FDAL 표가 AC 23.1309-1E·SC-VTOL-01과 다른 근거와 그 안전 영향은 무엇인가.
• 공개 소스 비행 소프트웨어의 사후 증거를 DO-178C의 목표에 어떻게 대응시킬 것인가.
• 개발 보증 수준과 운용 중 소프트웨어 사고율의 관계를 어떤 공개 자료로 측정할 수 있는가.

1차 출처(이 장):

• FAA, AC 20-115D (2017-07-21), AC 20-152A (2022-10-07), AC 20-193 (2024-01-08), AC 23.1309-1E (2011-11-17), Order 8110.49A (2018-03-29) — 원문을 읽고 목표·적용 범위·표를 확인. 모두 faa.gov 무료 공개.
• EASA, Certification Memorandum EASA CM-SWCEH-002 Issue 01 (2011-08-11) — 4.5절(SOI)·20절·21절 확인. DO-178B 기준.
• EASA, MOC Light-UAS High Risk.2510-01 (2025-02-11)과 SC-VTOL-01 Issue 1 (2019-07-02) — FDAL 표와 개발 보증 절 확인.
• JARUS, SORA Main Body 2.5 (2024-05-13) — 표 14 확인.
• K. Hayhurst 외, NASA/TM-2001-210876, "A Practical Tutorial on Modified Condition/Decision Coverage" (2001-05) — 구조 커버리지 정의와 DO-178B 표 A-7 대응 확인.
• Wikipedia "DO-178C", arXiv:2311.04344 — 레벨별 목표 수의 2차 출처. 원문 대조 필요 (확인 필요).
• RTCA DO-178C·DO-254·DO-330~333, EUROCAE ED-12C·ED-80·ED-215~218, EASA AMC 20-115·20-152·20-189·20-193 본문 — 읽지 못함 (확인 필요).

다음 장: 8.9 — 환경시험: DO-160·MIL-STD-810. 이 장이 소프트웨어와 전자 하드웨어의 개발 증거를 다루었다면, 8.9는 그 하드웨어가 온도·진동·습도·고도·낙뢰 같은 환경에서 견디는 증거를 시험으로 만드는 방법을 본다.