NASA가 Artemis II의 내결함성 컴퓨터를 구축한 방법

Apollo의 1MHz 컴퓨터와 약 4KB의 erasable memory와 달리, Orion은 우주선의 대부분의 안전 핵심 기능을 소프트웨어가 직접 관리한다.

핵심은 fail-silent 설계다. Orion은 Vehicle Management Computer 2대, 각 컴퓨터당 Flight Control Module 2개, 그리고 각 FCM 내부의 self-checking pair processor까지 합쳐 사실상 8개의 CPU가 비행 소프트웨어를 병렬 실행한다. 방사선으로 계산값이 틀리면 해당 채널은 잘못된 답을 내지 않고 조용히 사라지며, 시스템은 우선순위가 매겨진 건강한 채널에서 다음 출력을 선택한다.

이 구조는 특히 Van Allen belts 통과 중의 일시적 오류를 염두에 둔 것이다. NASA는 3개의 FCM을 22초 안에 잃어도 마지막 1개로 안전하게 버틸 수 있다고 설명한다. 사라진 FCM은 완전히 버려지지 않고, 상태를 다시 맞춘 뒤 비행 중 복귀할 수 있다.

동기화는 time-triggered Ethernet과 ARINC653 기반 스케줄링으로 맞춘다. 시스템은 major frame / minor frame 단위로 동작하고, 모든 FCM이 같은 입력을 받고 같은 애플리케이션 코드를 실행하며 같은 출력을 내도록 강제된다. 각 FCM의 시계 드리프트는 매초 재보정되며, 마감 시간을 놓치면 해당 모듈은 자동으로 silence/reset/resync 된다.

하드웨어와 네트워크도 다중 방어층으로 구성된다.

• triple-modular-redundant memory가 단일 비트 오류를 읽을 때마다 정정한다.
• 네트워크 인터페이스 카드는 2개 lane을 계속 비교해 비트 플립을 fail-silent 사건으로 바꾼다.
• 네트워크는 3개의 separate planes로 중복화돼 있다.

주 시스템이 공통 모드 실패를 겪을 가능성에 대비해, Orion은 완전히 분리된 Backup Flight Software (BFS) 를 별도 하드웨어와 별도 OS, 단순화된 독립 코드로 탑재한다. BFS는 항상 대기하다가 주 컴퓨터가 모두 실패하면 자동 전환되고, 비행의 동적 구간을 끝까지 이어갈 수 있다.

전원 상실인 dead bus 상황도 가정한다. 전원이 복구되면 차량은 safe mode로 들어가 먼저 안정화한 뒤 태양전지를 태양으로 향하게 하고, 꼬리 방향을 태양 쪽으로 두어 열 안정성을 확보한 다음 지구와의 통신을 재수립한다. 승무원은 그 사이 수동으로 life support를 재구성하거나 우주복을 착용할 수 있다.

Apollo 이후 Artemis로 오면서 소프트웨어 복잡도는 크게 증가했다. 이제는 열 밸브와 전력 릴레이까지 소프트웨어가 관리하므로, NASA는 full-environment simulation, Monte Carlo stress testing, 대규모 fault injection으로 극한 지연과 통신 장애를 검증한다. 이 글은 우주선의 항상성 설계가 자율주행차, 산업 그리드 같은 지상 시스템의 신뢰성 설계에도 참고가 될 수 있다고 정리한다.