Booil Jung

현대 비행제어컴퓨터를 위한 펌웨어 개발 기술

비행제어컴퓨터(Flight Control Computer, FCC)는 현대 항공기, 특히 기계적 연결을 전자 신호로 대체한 플라이 바이 와이어(Fly-By-Wire, FBW) 시스템의 핵심부에 위치한 중추 신경망입니다.1 FCC의 핵심 기능은 조종사의 조종간 입력이나 자동 조종 장치의 명령을 수신하여, 이를 정밀한 계산을 통해 항공기의 제어 표면(에일러론, 엘리베이터, 러더 등)을 움직이는 전기적 신호로 변환하는 것입니다.1 이 과정을 통해 조종사는 항공기를 정확하게 제어할 수 있게 됩니다.1

FCC는 독립적인 장치가 아니라, 항공기 전체의 항공전자(Avionics) 아키텍처 내에서 유기적으로 작동하는 핵심 구성 요소입니다. FCC 펌웨어는 대기자료컴퓨터(Air Data Computer, ADC), 관성항법장치(Inertial Navigation System, INS), GPS 수신기 등 다양한 센서로부터 고도, 속도, 자세, 위치와 같은 비행 데이터를 지속적으로 입력받습니다.3 동시에 추진 기관, 데이터링크, 임무 장비와도 연동하여 비행에 필요한 모든 정보를 통합하고 처리합니다.3 FCC의 오작동은 항공기 추락과 같은 치명적인 사고로 직결될 수 있으므로, 실제 비행 전 완벽한 시험 및 검증은 절대적으로 필수적입니다.5

FCC 펌웨어 개발의 본질적인 복잡성은 단순히 제어 법칙을 계산하는 것을 넘어섭니다. FCC는 본질적으로 ‘시스템의 시스템(System of Systems)’으로서 기능해야 합니다. 즉, FCC는 서로 다른 특성을 가진 수많은 하위 시스템으로부터 들어오는 데이터를 관리하고 검증하는 통합 플랫폼의 역할을 수행합니다. 예를 들어, FCC는 ARINC 429, MIL-STD-1553, CAN 등 각기 다른 프로토콜, 데이터 속도, 포맷을 가진 버스를 통해 데이터를 수신합니다.2 펌웨어는 이 이기종(heterogeneous) 데이터 스트림을 실시간으로 처리해야 할 뿐만 아니라, 데이터의 무결성을 보장해야 합니다. 이를 위해 이중화된 센서로부터 받은 값을 끊임없이 비교하여 어느 한쪽의 고장을 탐지하고, 문제가 발생한 센서를 시스템에서 격리하는 고장 탐지, 격리 및 재구성(Fault Detection, Isolation, and Reconfiguration, FDIR) 로직을 수행합니다.4 결과적으로, FCC 펌웨어의 상당 부분은 핵심 제어 알고리즘 자체보다 이러한 입력 데이터의 유효성 검증, 동기화, FDIR 로직을 구현하는 데 할애됩니다. 시스템의 안전은 결국 외부로부터 들어오는 입력을 불신하고 지속적으로 검증하는 능력에 달려있기 때문입니다.

단일 지점의 고장이 전체 시스템의 마비로 이어지는 것을 방지하기 위해, FCC는 다중화(Redundancy) 설계를 기본으로 채택합니다.5 하나의 채널에 고장이 발생하더라도 다른 채널이 즉시 임무를 이어받아 비행 안전을 보장하는 것이 핵심입니다.

이러한 다중화 모델은 시스템의 중요도와 요구되는 신뢰성 수준에 따라 다양하게 구현됩니다.

고도의 신뢰성이 요구되는 시스템에서는 ‘상이성(Dissimilarity)’ 개념이 도입됩니다. 이는 특정 프로세서 모델의 설계 결함이나 컴파일러 버그와 같은 공통 모드 고장에 대응하기 위한 전략입니다. 예를 들어, 각 채널에 서로 다른 제조사의 프로세서(예: PowerPC와 ARM), 서로 다른 실시간 운영체제(RTOS)(예: VxWorks와 INTEGRITY), 또는 완전히 다른 개발팀이 작성한 소프트웨어를 사용하는 방식입니다.7 또한, 다중화된 채널들은 결과를 비교하고 투표하기 위해 고속의 전용 채널 간 데이터 링크(Cross-Channel Data Link, CCDL)를 통해 지속적으로 통신합니다.7

결함 허용 아키텍처를 설계하는 것은 단순히 동일한 하드웨어를 여러 개 복제하는 것 이상의 의미를 가집니다. 가장 치명적인 고장은 예측하기 어려운 시스템적 결함, 즉 공통 모드 고장입니다. 상이성 설계는 이러한 위험을 줄이기 위한 강력한 수단이지만, 이는 개발 및 검증 과정의 복잡성과 비용을 기하급수적으로 증가시키는 결정입니다. 예를 들어, 하드웨어와 소프트웨어의 상이성을 채택한다는 것은 두 개 이상의 완전히 분리된 개발 환경, 컴파일러, 디버거, 검증 도구 체인을 각각 구축하고 인증받아야 함을 의미합니다. 펌웨어는 이제 핵심 기능 수행뿐만 아니라, 서로 다른 플랫폼에서 발생하는 미세한 타이밍 차이나 부동소수점 연산 오차에도 불구하고 채널 간 결과 값이 비교 가능하도록 보장해야 하는 추가적인 복잡성을 떠안게 됩니다. 따라서 다중화 수준과 상이성 전략의 선택은 펌웨어 개발 프로세스 전체의 비용, 일정, 기술적 난이도를 결정하는 가장 중요한 아키텍처 결정 사항이라고 할 수 있습니다.

FCC 하드웨어는 극한의 환경에서도 안정적으로 작동해야 하며, 고성능과 저전력 특성을 동시에 만족해야 합니다. 프로세서로는 항공우주 분야에서 오랜 기간 사용되어 신뢰성이 검증된 PowerPC나 ARM 계열이 주로 선택됩니다.8 최근에는 증가하는 연산량을 처리하기 위해 멀티코어 시스템 온 칩(System-on-Chip, SoC)의 채택이 늘고 있습니다.8

상호 운용성 확보와 군수 지원의 용이성을 위해, FCC는 ATR(Air Transport Rack)이나 VPX/VME 기반의 표준화된 LRU(Line Replaceable Unit) 형태로 제작됩니다.6 이러한 모듈식 접근법은 고장 시 라인에서 즉시 교체할 수 있게 하여 정비성을 향상시키고, 향후 성능 개선을 용이하게 합니다.6 특히 무인기나 차세대 항공 플랫폼에서는 크기, 무게, 전력(Size, Weight, and Power, SWaP)이 핵심 설계 제약 조건으로 작용하며, 이는 여러 기능을 단일 보드에 집적하고 저전력 부품을 사용하도록 하는 기술적 추세를 이끌고 있습니다.3 고밀도 전자 장비에서 발생하는 열을 효과적으로 관리하는 것 또한 중요한 과제입니다. 팬을 이용한 강제 공랭식 냉각보다는, 열전도판을 통해 열을 외부로 방출하는 전도 냉각(Conduction Cooling) 방식이 열악한 환경에서의 신뢰성을 높이기 위해 선호됩니다.6

FCC 펌웨어는 다양한 종류의 데이터버스를 통해 항공기 내 다른 시스템들과 통신합니다. 이 통신망은 수십 년에 걸친 기술의 진화를 반영하는 하이브리드 형태를 띱니다.

FCC 펌웨어는 단순히 이들 인터페이스를 사용하는 것을 넘어, 정교한 프로토콜 게이트웨이이자 번역가로서 기능해야 합니다. 이는 펌웨어 개발의 숨겨진 복잡성을 드러냅니다. 예를 들어, 최신 FCC는 AFDX 네트워크를 통해 새로운 센서로부터 비행 데이터를 수신하면서 8, 동시에 ARINC 429 신호만 이해하는 구형 액추에이터에 명령을 내려야 할 수 있습니다.6 또한, MIL-STD-1553 버스를 통해 군용 장비의 상태 정보를 받아야 할 수도 있습니다.7 이는 펌웨어 아키텍처 내에 각 프로토콜을 위한 별도의, 종종 격리된 드라이버 스택이 존재해야 함을 의미합니다. 핵심 애플리케이션 로직은 이러한 물리 계층으로부터 분리되어, 통일된 데이터 형식으로 정보를 제공하는 하드웨어 추상화 계층(Hardware Abstraction Layer, HAL)과 상호작용해야 합니다. 이 과정에서 각 프로토콜의 상이한 타이밍, 오류 처리 방식, 다중화 모델을 모두 관리해야 하므로, I/O 및 드라이버 관련 소프트웨어는 전체 펌웨어 개발 및 검증에서 상당한 비중을 차지하게 됩니다.3

FCC는 ‘경성 실시간 시스템(Hard Real-Time System)’으로 분류됩니다. 이는 정해진 시간(deadline) 내에 연산을 마치지 못하는 것이 단순한 성능 저하가 아니라 시스템 전체의 실패로 간주됨을 의미합니다.13 실시간 운영체제(Real-Time Operating System, RTOS)의 가장 중요한 임무는 어떠한 상황에서도 모든 태스크가 주어진 시간 제약 조건을 반드시 만족하도록 보장하는 것입니다.

이를 위해 RTOS는 결정론적 스케줄링 알고리즘, 주로 우선순위 기반의 선점형 스케줄링을 사용합니다. 일반적인 목적의 운영체제(General-Purpose OS)와 달리, RTOS는 복잡한 동적 메모리 할당이나 요구 페이징(demand paging)과 같이 예측 불가능성을 야기할 수 있는 기능들을 의도적으로 배제합니다.15 Linux나 Windows와 같은 표준 운영체제는 평균적인 처리량과 사용자 응답성에 최적화되어 있을 뿐, 최악의 경우(worst-case)에 대한 시간 보장을 제공하지 않습니다. 이들 OS의 스케줄러, 인터럽트 처리, 드라이버 모델에는 예측 불가능한 지연 시간이 존재하여 안전 필수 제어 루프에는 부적합합니다.16

안전 필수 항공전자 시장은 소수의 고도로 전문화된 RTOS 공급업체들이 주도하고 있습니다. 이들 RTOS는 엄격한 안전 인증을 획득했으며, 항공우주 및 국방 분야에서 수십 년간의 운용 실적을 통해 신뢰성을 입증했습니다.

표 2: 안전 필수 RTOS 비교 분석

특성 VxWorks (Wind River) PikeOS (SYSGO) INTEGRITY-178 (Green Hills)
커널 아키텍처 모놀리식 커널 분리 커널 기반 하이퍼바이저 분리 커널
주요 장점 방대한 사용 실적, 성숙한 생태계, 강력한 도구 지원 17 강력한 파티션 격리, 혼합 중요도 시스템 지원, 높은 보안성 9 높은 보안성, 멀티코어 인증 지원, 낮은 커널 오버헤드 21
DO-178C 인증 DAL A 지원 17 DAL A 지원 9 DAL A 지원 21
ARINC 653 지원 VxWorks 653 에디션 제공 17 ARINC 653 페르소나 제공 20 지원
멀티코어 지원 멀티코어 에디션 및 CAST-32A 지원 17 멀티코어 인증 지원, 강력한 파티셔닝으로 간섭 제어 9 CAST-32A 목표 만족 설계 23
대표 적용 사례 NASA 화성 탐사 로버, X-47B, Collins Aerospace 17 Airbus A350, A400M 9 F-35, B-2 Spirit 21

하나의 프로세서 위에서 중요도가 낮은 애플리케이션(예: 정비 데이터 기록)이 어떻게 중요도가 매우 높은 비행 제어 태스크에 전혀 영향을 미치지 않도록 보장할 수 있을까요? 악의적이거나 오류가 있는 저중요도 애플리케이션이 고중요도 애플리케이션의 메모리를 침범하거나 CPU 시간을 독점하는 것을 막아야 합니다.

이 문제에 대한 해답이 바로 ‘파티셔닝(Partitioning)’입니다. RTOS는 엄격한 감독관처럼 작동하여, 각 애플리케이션을 위한 보호된 공간인 파티션을 생성합니다. 각 파티션에는 고정된 메모리 영역(공간 분할, spatial partitioning)과 사전 정의된 스케줄에 따른 고정된 실행 시간(시간 분할, temporal partitioning)이 할당됩니다.9

ARINC 653 표준은 이러한 항공전자 시스템의 공간 및 시간 분할을 위한 소프트웨어 명세를 정의합니다. 이 표준은 APEX(APplication EXecutive)라는 표준화된 API를 제공하여, 애플리케이션이 특정 하드웨어나 RTOS에 종속되지 않고 개발될 수 있도록 합니다.6 이는 소프트웨어의 이식성과 재사용성을 높이는 핵심 요소이며, FACE(Future Airborne Capability Environment) 표준이 추구하는 목표와도 일치합니다.25

ARINC 653 파티셔닝은 단순한 기술적 기능을 넘어, IMA(통합 모듈형 항공전자) 환경에서 인증 비용과 복잡성을 관리하기 위한 근본적인 전략입니다. 최신 항공기는 여러 기능을 소수의 고성능 컴퓨터에 통합하는 IMA 아키텍처를 채택합니다. 이 기능들은 각기 다른 중요도 등급(예: 비행 제어는 DAL A, 객실 압력 조절은 DAL C)을 가집니다.26 만약 이 모든 소프트웨어를 가장 높은 등급인 DAL A 기준으로 인증하려면 천문학적인 시간과 비용이 소요될 것입니다. ARINC 653은 각 기능을 별도의 파티션에 배치하고 RTOS가 이들 간의 완전한 격리를 보장함으로써 이 문제를 해결합니다. 이를 통해 각 파티션의 소프트웨어는 해당 기능에 요구되는 DAL 등급으로만 인증받을 수 있습니다. 즉, DAL C 등급의 객실 압력 조절 애플리케이션은 DAL A 등급의 비행 제어 애플리케이션과 동일한 수준의 엄격한 검증을 거칠 필요가 없습니다. 이처럼 파티셔닝은 가장 높은 중요도 등급이 시스템 전체를 ‘오염’시키는 것을 방지함으로써, 인증 비용을 획기적으로 절감하고 개발 복잡성을 관리 가능한 수준으로 유지하는 핵심적인 비즈니스 및 엔지니어링 동인으로 작용합니다.

펌웨어 개발에 사용할 프로그래밍 언어를 선택하는 것은 개발자 편의성, 도구 지원, 그리고 언어 자체에 내재된 안전성 사이의 신중한 절충 과정입니다.27 항공전자 분야의 언어 선택에서 가장 중요한 철학은 모호함을 최소화하고, 흔히 발생하는 프로그래밍 오류들을 런타임에 발견하는 것이 아니라 컴파일 시점에 원천적으로 방지하는 것입니다.29

Ada는 대규모의 신뢰성 높은 실시간 시스템을 위해 처음부터 설계된 언어입니다.29 Ada가 안전 필수 시스템에 적합한 이유는 다음과 같은 핵심적인 특징 때문입니다.

SPARK는 Ada의 부분집합으로, 정형 기법(formal methods)을 통해 수학적으로 분석 가능한 언어입니다. 개발자는 코드에 특정 주석(annotation)을 추가함으로써 SPARK 도구셋을 사용하여 버퍼 오버플로나 0으로 나누기 같은 특정 런타임 오류가 ‘절대 발생하지 않음’을 수학적으로 증명할 수 있습니다.35 이는 테스트만으로는 도달할 수 없는 수준의 신뢰성을 제공합니다.

이러한 장점 덕분에 Ada는 F-15, F-16, 유로파이터 타이푼 등 수많은 군용기는 물론, Airbus A350의 항공 데이터 관성 기준 장치(ADIRU)와 같은 상용 항공기 핵심 시스템 개발에도 성공적으로 사용되었습니다.27

C와 C++는 방대한 개발자 커뮤니티와 풍부한 도구 지원 덕분에 임베디드 시스템 개발에 널리 사용됩니다.27 하지만 이 언어들은 본질적으로 안전을 위해 설계되지 않았습니다. 특히 포인터 연산, 메모리 관리, 타입 변환 등에서 개발자가 치명적인 실수를 저지르기 쉬운 구조를 가지고 있습니다.28

이러한 위험을 통제하기 위해, 항공전자 산업에서는 C/C++를 사용할 경우 언어의 ‘안전한 부분집합(safe subset)’만을 사용하도록 강제하는 엄격한 코딩 표준을 준수해야 합니다.

이러한 표준들은 일반적으로 다음과 같은 기능의 사용을 금지하거나 강력하게 제한합니다.

표 3: 고신뢰성 시스템을 위한 프로그래밍 언어 선택 트레이드오프

기준 Ada / SPARK C / C++ (MISRA 준수) Rust
내재적 안전성 매우 높음. 언어 설계 자체가 안전을 지향 29 낮음. 엄격한 코딩 표준과 정적 분석 도구를 통해 안전성 확보 28 매우 높음. 소유권(Ownership) 및 빌림(Borrowing) 규칙으로 메모리 안전성 보장 9
검증 용이성 높음. SPARK는 정형 검증 지원 36 중간. 표준 준수 여부 검증 필요. 제어 흐름이 복잡할 수 있음 38 높음. 컴파일러가 많은 오류를 방지. 단, 인증용 도구 생태계는 초기 단계.
개발자 생태계 상대적으로 작지만 고도로 전문화됨 40 매우 큼. 개발자 확보 용이 28 빠르게 성장 중이나, 안전 필수 분야 전문가는 아직 소수.
인증 도구 체인 매우 성숙함. DO-178C 인증 실적 다수 36 매우 성숙함. DO-178C 인증 실적 다수 28 개발 중. 아직 주요 항공전자 인증 실적은 부족함.9
주요 장점 설계 단계에서 오류 방지, 최고의 신뢰성 광범위한 하드웨어 지원, 기존 자산 활용 용이 메모리 안전성 보장, 현대적인 언어 기능
주요 단점 개발자 풀이 작고, 초기 학습 곡선이 있음 언어의 위험성을 통제하기 위한 추가적인 노력과 비용 발생 인증 생태계 미성숙, 기존 C/C++ 코드베이스와의 통합 문제

최근 미국 백악관 등 정부 기관에서 C/C++ 사용을 자제하고 메모리 안전(memory-safe) 언어로 전환할 것을 촉구하는 움직임은 안전과 보안의 관계에 대한 중요한 시사점을 던집니다.39 이는 항공우주 산업의 전통적인 안전 중심 문화와 새로운 사이버 보안 요구사항 사이의 긴장 관계를 보여줍니다. DO-178C는 본질적으로 ‘안전’ 표준으로, 소프트웨어 결함이 사고로 이어지는 것을 막는 데 중점을 둡니다. 이 과정에서 요구되는 극도로 엄격한 검증 절차는 결과적으로 많은 메모리 관련 버그를 잡아내지만, 이는 안전 확보의 부산물에 가깝습니다. 반면, DO-326A와 같은 새로운 표준은 ‘보안’을 정면으로 다루며, 악의적인 공격으로부터 시스템을 보호할 것을 요구합니다.41 Rust와 같은 언어는 설계 단계에서부터 메모리 안전성을 보장하여 보안에 큰 이점을 제공합니다.39 하지만 Rust의 컴파일러와 검증 도구는 아직 Ada나 C++만큼 DO-178C DAL A 인증 분야에서 검증된 실적을 쌓지 못했습니다. 따라서 업계는 ‘프로세스를 통해 안전을 확보한’ 기존의 C/C++를 고수할 것인지, ‘본질적으로 안전하지만 인증 생태계가 미성숙한’ Rust로 전환할 것인지, 혹은 ‘안전성과 검증 실적을 모두 갖춘’ Ada에 다시 주목할 것인지에 대한 복잡한 의사결정에 직면해 있습니다. 이는 언어 선택이 단순한 기술적 문제를 넘어, 안전 문화, 보안 요구, 인증 리스크, 도구 체인의 성숙도를 모두 고려해야 하는 전략적 결정이 되었음을 보여줍니다.

DO-178C, “항공기 시스템 및 장비 인증에 대한 소프트웨어 고려사항”은 미국 연방항공청(FAA), 유럽항공안전청(EASA) 등 전 세계 인증 기관이 상용 항공 소프트웨어를 승인하는 데 사용하는 핵심 표준입니다.43 이 표준은 특정 기술이나 개발 방법을 강요하는 대신, 소프트웨어의 안전성을 보장하기 위해 ‘무엇을(what)’ 달성해야 하는지에 대한 목표(objective) 기반의 프로세스를 정의합니다.43

DO-178C의 핵심은 설계 보증 수준(Design Assurance Level, DAL) 입니다. DAL은 시스템 수준의 안전성 평가를 통해 결정되며, 소프트웨어 고장이 항공기에 미치는 영향의 심각도에 따라 A부터 E까지 5개 등급으로 나뉩니다. 이 등급은 개발 및 검증 과정에 요구되는 엄격함의 수준을 결정합니다.43

표 1: DO-178C 설계 보증 수준(DAL) 목표 및 요구사항

수준 (Level) 고장 상태 (Failure Condition) 결과 목표 수 독립성 요구 목표 수  
A 치명적 (Catastrophic) 항공기 손실 및 다수의 사망자를 유발할 수 있음 71 30  
B 위험 (Hazardous) 안전 여유를 크게 감소시키거나, 심각한 부상 또는 소수의 사망자를 유발할 수 있음 69 18  
C 중대 (Major) 안전 여유를 상당히 감소시키거나, 승무원 작업 부하를 크게 증가시켜 경미한 부상을 유발할 수 있음 62 5  
D 경미 (Minor) 안전 여유를 약간 감소시키거나, 승무원 작업 부하를 약간 증가시킴 26 2  
E 영향 없음 (No Safety Effect) 항공기 운용 능력이나 안전에 영향 없음 0 0  
출처: 43          

DO-178C는 양방향 추적성(bidirectional traceability)을 강력하게 요구합니다. 모든 소스 코드 라인은 그것을 구현하는 저수준 요구사항(Low-Level Requirement)으로, 저수준 요구사항은 상위의 고수준 요구사항(High-Level Requirement)으로 거슬러 올라갈 수 있어야 합니다. 역으로, 모든 요구사항은 그것을 구현하는 코드와 그것을 검증하는 테스트 케이스로 연결되어야 합니다.43 이는 불필요한 코드가 존재하지 않고, 모든 요구사항이 구현되고 테스트되었음을 보장하는 핵심적인 장치입니다.

높은 DAL 등급에서는 특정 검증 목표를 독립성(independence)을 가지고 만족시켜야 합니다. 이는 특정 산출물(예: 소스 코드)을 검증하는 사람이 그것을 작성한 사람과 달라야 함을 의미하며, 인간의 실수를 방지하기 위한 중요한 방어선 역할을 합니다.43

DO-178C는 본래 단일 코어 프로세서를 가정하고 작성되었습니다. 하지만 최신 FCC에 널리 사용되는 멀티코어 프로세서(MCP)는 L2/L3 캐시, 메모리 컨트롤러, I/O 버스 등 여러 코어가 공유하는 자원을 가지고 있습니다. 이 공유 자원은 ‘간섭 채널(interference channels)’을 생성하여, 한 코어의 활동이 다른 코어의 실행 시간을 예측 불가능하게 지연시켜 시스템의 결정성을 파괴할 수 있습니다.23

이 문제를 해결하기 위해, 인증 기관 소프트웨어 팀(CAST)은 CAST-32A라는 지침 문서를 발표했으며, 이는 이후 FAA와 EASA에 의해 공식적인 수용 가능한 규정 준수 수단(Acceptable Means of Compliance)인 AC/AMC 20-193으로 발전했습니다.48 이 지침들은 기존 DO-178C 프로세스에 멀티코어 관련 목표들을 추가합니다.

이러한 목표를 달성하기 위한 완화 기법은 하드웨어에 대한 깊은 이해, RTOS 수준의 자원 관리(예: 캐시 컬러링, 메모리 대역폭 제한), 그리고 최대의 간섭을 유발하도록 설계된 ‘스트레스’ 애플리케이션을 이용한 광범위한 테스트를 포함합니다.23

CAST-32A의 등장은 검증의 패러다임을 근본적으로 바꾸었습니다. 이제는 단일 코어 상에서 코드의 ‘논리적 정확성’을 증명하는 것만으로는 충분하지 않으며, 하드웨어로 인해 유발되는 간섭 속에서 전체 시스템의 ‘시간적 정확성’을 증명해야 합니다. 단일 코어 환경에서 태스크의 최악 실행 시간(WCET)은 코드 자체의 로직과 프로세서 파이프라인의 동작으로 결정되어 분석이 어렵지만 한정적이었습니다.53 하지만 멀티코어 환경에서는 1번 코어에서 실행되는 태스크의 WCET가 2, 3, 4번 코어에서 동시에 어떤 태스크가 실행되는지에 따라 달라집니다.23 이는 분석해야 할 상태 공간을 폭발적으로 증가시켜 순수한 정적 분석을 거의 불가능하게 만듭니다.51 따라서 검증 접근법은 경험적이고 반복적인 방식으로 전환될 수밖에 없습니다. 즉, 특정 태스크의 실행 시간을 측정하면서, 의도적으로 다른 코어들에서 최악의 간섭을 유발하는 ‘스트레스’ 소프트웨어를 실행하여 최악의 경우를 찾아내는 방식입니다.23 이는 더 이상 검증이 단순한 소프트웨어 활동이 아님을 의미합니다. 이제 검증은 프로세서 마이크로아키텍처에 대한 깊은 지식과 측정 및 분석을 위한 전문 도구를 요구하는, 하드웨어-소프트웨어 통합의 복잡한 문제가 되었습니다.

최악 실행 시간(Worst-Case Execution Time, WCET)은 특정 하드웨어에서 특정 태스크가 실행되는 데 걸릴 수 있는 최대 시간을 의미합니다.13 이는 모든 태스크가 마감 시간 내에 완료될 수 있는지를 증명하는 스케줄링 가능성 분석(schedulability analysis)의 핵심 입력값입니다.53

하지만 캐시, 파이프라인, 분기 예측과 같은 현대 프로세서의 복잡한 기능들로 인해, 단일 명령어의 실행 시간조차 수백 배까지 차이 날 수 있어 WCET 분석은 매우 어려운 과제입니다.53

이러한 분석을 위해, 가능한 실행 경로를 파악하는 흐름 분석(flow analysis), 프로세서의 타이밍 동작을 모델링하는 저수준 분석(low-level analysis), 그리고 최종 WCET 경계값을 계산하는 전문 도구들이 사용됩니다.14

항공기가 인터넷 및 외부 네트워크와 점점 더 많이 연결되면서, 과거에는 고려되지 않았던 사이버 보안 위협에 노출되고 있습니다.42 사이버 공격은 항공기의 안전을 직접적으로 위협할 수 있습니다.

이러한 새로운 위협에 대응하기 위해, DO-326A/ED-202A 세트(DO-326A, DO-355, DO-356A 포함)는 DO-178C의 안전 프레임워크를 보완하는 감항 보안(airworthiness security) 프레임워크를 제공합니다.42 이 프레임워크는 보안 위협 식별, 위험 평가, 보안 보호 수단 구현 및 검증을 포함하는 감항 보안 프로세스(Airworthiness Security Process, AWSP)를 도입합니다.42

DO-326 프로세스는 DO-178C의 개발 수명주기와 통합되도록 설계되었습니다. DO-178C에서 요구하는 엄격한 형상 관리, 품질 보증, 검증 프로세스들은 보안 목표를 달성하는 데에도 효과적으로 활용될 수 있습니다.41 예를 들어, 보안 요구사항이 DO-178C 프로세스의 입력이 되고, 기존의 검증 활동에 위협 완화 테스트나 오용 사례(abuse case) 테스트와 같은 보안 테스트가 추가되는 방식입니다.42

모델 기반 설계(Model-Based Design, MBD)는 MATLAB/Simulink와 같은 도구를 사용하여 시스템의 실행 가능한 그래픽 모델을 설계의 중심으로 삼는 개발 방법론입니다.59

DO-331은 DO-178C의 공식 보충 문서로, 인증 프로세스에서 MBD와 자동 코드 생성을 사용하는 방법에 대한 구체적인 지침을 제공합니다. 이는 모델 검증, 코드 생성 검증, 도구 인증에 대한 목표를 정의합니다.61 MBD에 사용되는 코드 생성기나 정적 분석기와 같은 도구들은 그 자체로 신뢰할 수 있음을 증명해야 하며(도구 인증, DO-330), MathWorks와 같은 공급업체는 이 과정을 돕기 위한 문서와 테스트 케이스가 포함된 “DO 인증 키트(DO Qualification Kit)”를 제공합니다.61

펌웨어 개발의 마지막 단계는 작성된 코드가 실제 하드웨어와 통합되어 시스템으로서 올바르게 작동하는지 증명하는 것입니다.

비행제어컴퓨터(FCC)의 펌웨어 개발 기술은 단순한 코딩을 넘어, 하드웨어 아키텍처, 실시간 운영체제, 프로그래밍 언어, 그리고 엄격한 인증 프로세스가 유기적으로 결합된 고도의 공학 분야입니다. 본 보고서에서 분석한 바와 같이, FCC 펌웨어 개발의 모든 측면은 ‘안전성’과 ‘결정성’이라는 두 가지 절대적인 가치를 중심으로 수렴됩니다.

결함 허용을 위한 다중화 아키텍처와 상이성 설계는 펌웨어의 구조와 복잡성을 근본적으로 결정하며, ARINC 653 기반의 파티셔닝은 혼합 중요도 시스템의 구현과 인증 비용 절감을 가능하게 하는 핵심 전략입니다. 프로그래밍 언어의 선택은 내재적 안전성과 검증 가능성을 최우선으로 고려하며, Ada/SPARK와 MISRA C/C++와 같은 안전한 부분집합의 사용은 필수적입니다.

이 모든 기술적 선택은 DO-178C라는 강력한 프로세스 프레임워크 안에서 이루어지며, 모든 개발 산출물은 양방향 추적성을 통해 요구사항과 연결되고 독립적인 검증을 통해 신뢰성을 보증받아야 합니다. 최근에는 멀티코어 프로세서의 도입으로 인한 간섭 채널 문제(CAST-32A)와 사이버 보안 위협(DO-326A)이라는 새로운 도전 과제가 등장했으며, 이는 검증의 패러다임을 코드의 논리적 정확성에서 시스템 전체의 시간적, 보안적 강건함을 증명하는 방향으로 변화시키고 있습니다.

미래의 FCC 펌웨어 개발은 모델 기반 설계(MBD)와 자동화된 검증 도구의 활용이 더욱 보편화될 것이며, 이를 통해 복잡성 증가에 대응하고 개발 효율성을 높일 것입니다. 또한, Rust와 같은 메모리 안전 언어의 등장은 기존의 안전 중심 개발 문화에 보안이라는 새로운 차원을 더하며, 이들 신기술을 인증 프레임워크 내에 어떻게 통합할 것인지가 업계의 중요한 화두가 될 것입니다. 궁극적으로, FCC 펌웨어 기술의 발전은 가장 진보된 컴퓨팅 기술을 가장 보수적이고 엄격한 안전 공학 원칙과 결합하여, 하늘의 안전을 보장하는 방향으로 계속 진화할 것입니다.

  1. 항공기 비행 제어 시스템 시장 규모, 공유 트렌드 [2032] - Fortune Business Insights, accessed July 3, 2025, https://www.fortunebusinessinsights.com/ko/aircraft-flight-control-system-market-104067
  2. Flight Control Computers - BETA Technologies, accessed July 3, 2025, https://beta.team/flight-control-computers
  3. 무인항공기용 비행제어컴퓨터 아키텍처 최적화 설계 및 성능 평가 …, accessed July 3, 2025, https://koreascience.kr/article/JAKO202303149919456.pub?&lang=ko
  4. 무인항공기 이중화 대기자료시스템 설계 및 통합 연구 Design and Integration of a Dual Redundancy Air Data Sy, accessed July 3, 2025, https://jkimst.org/upload/pdf/KIMST-2020-23-6-639.pdf
  5. 비행 조종 시스템 - 위키백과, 우리 모두의 백과사전, accessed July 3, 2025, https://ko.wikipedia.org/wiki/%EB%B9%84%ED%96%89%EC%A1%B0%EC%A2%85%EC%8B%9C%EC%8A%A4%ED%85%9C
  6. Flight Control Computers Curtiss-Wright Defense Solutions, accessed July 3, 2025, https://www.curtisswrightds.com/products/computing-systems/program-specific/flight-control-computer
  7. FLIGHT CONTROL COMPUTERS FAMILY - Leonardo - Electronics, accessed July 3, 2025, [https://electronics.leonardo.com/documents/16277707/21368964/Flight_Control_Computer_Family_%28MM09114%29HQ.pdf?t=1675076733426](https://electronics.leonardo.com/documents/16277707/21368964/Flight_Control_Computer_Family(MM09114)_HQ.pdf?t=1675076733426)
  8. Advanced Distributed Flight Control System Architecture with Prognosis for High Performance Fighter Aircraft, accessed July 3, 2025, https://ijettjournal.org/assets/year/2016/volume-42/number-8/IJETT-V42P272.pdf
  9. PikeOS RTOS & Hypervisor - SYSGO, accessed July 3, 2025, https://www.sysgo.com/pikeos
  10. KR101418488B1 - 무인기용 통합 비행제어 컴퓨터시스템 및 그 검증방법 - Google Patents, accessed July 3, 2025, https://patents.google.com/patent/KR101418488B1/ko
  11. Avionics Systems Integration & Test - Avionics Interface Technologies - A Teradyne Company, accessed July 3, 2025, https://aviftech.com/systems-integration-test-3/
  12. Avionics Systems Integration & Test - Avionics Interface Technologies - A Teradyne Company, accessed July 3, 2025, https://aviftech.com/systems-integration-test/
  13. Worst-case execution time - Wikipedia, accessed July 3, 2025, https://en.wikipedia.org/wiki/Worst-case_execution_time
  14. Worst-Case Execution Time (WCET) and execution time analysis in critical embedded systems - LDRA, accessed July 3, 2025, https://ldra.com/capabilities/wcet/
  15. real-time, safe and certified os - Department of Distributed and Dependable Systems, accessed July 3, 2025, https://d3s.mff.cuni.cz/files/teaching/nswi133/SYSGO-Introduction_with_cert-public.pdf
  16. What Are the Most Popular Real-Time Operating Systems in 2024?, accessed July 3, 2025, https://www.lynx.com/blog/most-popular-real-time-operating-systems-rtos
  17. VxWorks Industry Leading RTOS for Embedded Systems, accessed July 3, 2025, https://www.windriver.com/products/vxworks
  18. PikeOS - Certified RTOS with hypervisor functionality for mission-critical systems - Third-Party Products & Services - MATLAB & Simulink - MathWorks, accessed July 3, 2025, https://it.mathworks.com/products/connections/product_detail/pikeos.html
  19. PikeOS -Hypervisor and RTOS in the same product. Aerospace and Defense, Automotive for Safety and Security systems and Multi-Core certification - Sightsys, accessed July 3, 2025, https://www.sightsys.co.il/product/sysgo-pikeos-hypervisor-rtos-for-aerospace-defense-and-automotive-for-safety-and-security-systems-and-multi-core-certification/
  20. Integrating PikeOS With Microchip’s RISC-V Based PolarFire® SoC FPGA, accessed July 3, 2025, https://www.microchip.com/en-us/about/media-center/blog/2023/integrating-pikeos-with-microchip-risc-v-based-polarfire-soc-fpga
  21. 9 Best VxWorks Alternatives & Competitors in (Jun 2025) - SoftwareSuggest, accessed July 3, 2025, https://www.softwaresuggest.com/vxworks/alternatives
  22. new version of the Phoenix-RTOS operating system dedicated for implementation of systems compliant with the guidelines of the DO-178C safety standard, accessed July 3, 2025, https://phoenix-rtos.com/tenders?id=2
  23. CAST-32A Guidance for Multicore Processorss - Green Hills Software, accessed July 3, 2025, https://www.ghs.com/products/safety_critical/integrity_178_standards_cast-32A.html
  24. SYSGO introduces DO-178C / ED-12C DAL A Certification Kit for Hypervisor-based Real-Time Operating System PikeOS 5.1, accessed July 3, 2025, https://www.sysgo.com/press-releases/sysgo-introduces-do-178c-ed-12c-dal-a-certification-kit-for-hypervisor-based-real-time-operating-system-pikeos-51
  25. FACE Developing Technical Standards & Updates - Avionics and Testing Innovations, accessed July 3, 2025, https://avionicsandtesting-innovations.com/session/face-developing-technical-standards-updates/
  26. Decoding DO-178C Software Levels: A Comprehensive Guide - TheCloudStrap, accessed July 3, 2025, https://thecloudstrap.com/decoding-do-178c-software-levels/
  27. What programming languages are used for equipment onboard aircraft?, accessed July 3, 2025, https://aviation.stackexchange.com/questions/3608/what-programming-languages-are-used-for-equipment-onboard-aircraft
  28. C++ for Safety-Critical Systems, accessed July 3, 2025, https://www.appinf.com/download/SafetyCriticalC++.pdf
  29. Ada (programming language) - Wikipedia, accessed July 3, 2025, https://en.wikipedia.org/wiki/Ada_(programming_language)
  30. SAFETY CRITICAL DESIGN - AdaCore, accessed July 3, 2025, https://www.adacore.com/uploads/techPapers/Safety-Critical_Design.pdf
  31. Using Ada in the Real-Time Avionics Environment. Issues and Conclusions. - DTIC, accessed July 3, 2025, https://apps.dtic.mil/sti/citations/tr/ADA163844
  32. Ada Advantages - Ada Resource Association, accessed July 3, 2025, https://www.adaic.org/advantages/
  33. Chapter 0: ADA Programming Language: Power, Safety, and Scalability - TheCloudStrap, accessed July 3, 2025, https://thecloudstrap.com/ada-programming-language-introduction/
  34. What makes (or at least made) Ada the language of choice for the ISS’s safety-critical systems? - Space Exploration Stack Exchange, accessed July 3, 2025, https://space.stackexchange.com/questions/36538/what-makes-or-at-least-made-ada-the-language-of-choice-for-the-isss-safety-cr
  35. Disruptive Technology for Military-Grade Software - AdaCore, accessed July 3, 2025, https://www.adacore.com/disruptive-technology-military-grade-software
  36. AdaCore + Avionics, accessed July 3, 2025, https://www.adacore.com/industries/avionics
  37. How is Ada a ‘safety critical’ language? - Stack Overflow, accessed July 3, 2025, https://stackoverflow.com/questions/7814869/how-is-ada-a-safety-critical-language
  38. C vs C++ for safety critical software : r/embedded - Reddit, accessed July 3, 2025, https://www.reddit.com/r/embedded/comments/1ka1drv/c_vs_c_for_safety_critical_software/
  39. White House C++ and C to be Removed from Embedded Systems - CodeSecure, accessed July 3, 2025, https://codesecure.com/learn/white-house-urges-tossing-c-and-c-from-critical-infrastructure-systems-and-why-this-is-not-a-good-idea/
  40. Programming languages used in Aviation : r/ada - Reddit, accessed July 3, 2025, https://www.reddit.com/r/ada/comments/1h4751m/programming_languages_used_in_aviation/
  41. Mastering Aviation Safety & Cybersecurity: DO-178C & DO-326A - YouTube, accessed July 3, 2025, https://www.youtube.com/watch?v=5T33gtoFv4E
  42. DO-326A/ED-202A Trusted Aerospace Cybersecurity Framework Guide - LDRA, accessed July 3, 2025, https://ldra.com/aerospace-security-framework/
  43. DO-178C - Wikipedia, accessed July 3, 2025, https://en.wikipedia.org/wiki/DO-178C
  44. What Is DO-178C? - Wind River Systems, accessed July 3, 2025, https://www.windriver.com/solutions/learning/do-178c
  45. Making DO with Safety Standards - Aerospace Innovations, accessed July 3, 2025, https://aerospace-innovations.com/making-do-with-safety-standards/
  46. I’m so confused by DO-178 and determing Development Assurance Levels - Reddit, accessed July 3, 2025, https://www.reddit.com/r/AerospaceEngineering/comments/1k4l2o2/im_so_confused_by_do178_and_determing_development/
  47. Model-Based Design for DO-178C Software Development with MathWorks Tools, Part 2, accessed July 3, 2025, https://www.mathworks.com/videos/do-178b-software-development-02-requirements-based-modeling-and-traceability-81664.html
  48. CAST-32A: Development of avionics software for single-core processors, accessed July 3, 2025, https://www.cast32a.com/
  49. Understanding CAST-32A and A(M)C 20-193 - LDRA, accessed July 3, 2025, https://ldra.com/amc20-193/
  50. Mitigate Timing and Interference Issues on Multicore Processors - LDRA, accessed July 3, 2025, https://ldra.com/mitigate-timing-and-interference-issues-on-multicore-processors/
  51. What is CAST-32A? - Rapita Systems, accessed July 3, 2025, https://www.rapitasystems.com/cast-32a
  52. RTOS & FAA CAST-32 MCP Training for Safety-Critical Systems - AFuzion, accessed July 3, 2025, https://afuzion.com/safety-critical-real-time-operating-systems-rtos-training/
  53. The Worst-Case Execution Time Problem - Overview of Methods and Survey of Tools - Department of Computer Science, accessed July 3, 2025, https://www.cs.fsu.edu/~whalley/papers/tecs07.pdf
  54. Worst–Case Execution Time Analysis Approach for Safety–Critical Airborne Software, accessed July 3, 2025, https://www.researchgate.net/publication/296679506_Worst-Case_Execution_Time_Analysis_Approach_for_Safety-Critical_Airborne_Software
  55. Worst Case Execution Time Prediction (Techniques) - UPenn CIS, accessed July 3, 2025, https://www.cis.upenn.edu/~alur/CIS670/wilhelm.ppt
  56. Approximate Worst-Case Execution Time Analysis for Early Stage Embedded Systems Development., accessed July 3, 2025, https://dl.ifip.org/db/conf/seus/seus2009/GustafssonAEL09.pdf
  57. Cybersecurity Engineering: Bridging the Security Gaps in Avionics Architectures and DO-326A/ED-202A - ResearchGate, accessed July 3, 2025, https://www.researchgate.net/profile/Fahad-Siddiqui-3/publication/375573553_Cybersecurity_Engineering_Bridging_the_Security_Gaps_in_Avionics_Architectures_and_DO-326AED-202A/links/6553226bce88b87031e54c3a/Cybersecurity-Engineering-Bridging-the-Security-Gaps-in-Avionics-Architectures-and-DO-326A-ED-202A.pdf
  58. Safety versus Security in Aviation, Comparing DO-178C with Security Standards, accessed July 3, 2025, https://elib.dlr.de/133710/1/SafetyVersusSecurityStandards.pdf
  59. 성공적인 임베디드 시스템 개발을 위한 모델 기반 설계 가이드: 기초부터 적용까지 - YouTube, accessed July 3, 2025, https://www.youtube.com/watch?v=Is1xyN0nWws
  60. Best Practices for Developing DO-178 Compliant Software Using Model-Based Design, accessed July 3, 2025, https://www.mathworks.com/company/technical-articles/best-practices-for-developing-do-178-compliant-software-using-model-based-design.html
  61. Model-Based Design for DO-178C/DO-331 Compliance - MATLAB & Simulink - MathWorks, accessed July 3, 2025, https://www.mathworks.com/learn/training/model-based-design-for-do-178c-do-331-compliance.html
  62. Introduction to Model-Based Development for DO-178C Using Qualified Tools in a DO-178C Development Process, Part 1 - MATLAB & Simulink - MathWorks, accessed July 3, 2025, https://www.mathworks.com/videos/using-qualified-tools-in-a-do-178c-development-process-part-1-introduction-to-model-based-development-for-do-178c-1509375492551.html
  63. DO-178C Model-Based Design support released by MathWorks, accessed July 3, 2025, https://militaryembedded.com/avionics/safety-certification/do-178c-model-based-design-support-released-by-mathworks
  64. Model To Code Using Qualified Tools in a DO-178C Development Process, Part 6 - MATLAB & Simulink - MathWorks, accessed July 3, 2025, https://www.mathworks.com/videos/using-qualified-tools-in-a-do-178c-development-process-part-6-qualified-code-verification-model-to-code-1509537112307.html
  65. Avionics Systems, Software, and Hardware Verification/Testing - ENSCO, Inc., accessed July 3, 2025, https://www.ensco.com/aerospace/avionics-systems-software-and-hardware-verification-testing
  66. Avionics software - Wikipedia, accessed July 3, 2025, https://en.wikipedia.org/wiki/Avionics_software
  67. Hardware-in-the-Loop and Automated Testing for Aerospace - YouTube, accessed July 3, 2025, https://www.youtube.com/watch?v=h0vdgt7C4KA
  68. Avionics Test & Simulation Software Astronics, accessed July 3, 2025, https://www.astronics.com/avionics-test-simulation-software
  69. Avionics Test Equipment Catalog - VIAVI Solutions, accessed July 3, 2025, https://www.viavisolutions.com/en-us/literature/viavi-avionics-test-equipment-catalog-selection-guides-en.pdf