▲

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

 (cacm.acm.org)
1P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • 달 유인 비행선 Orion의 비행 컴퓨터는 Apollo 시대 시스템보다 복원력과 자동 제어 능력이 크게 향상된 구조로, 생명 유지·전력·통신 등 핵심 기능을 모두 관리함
  • 달 궤도 25만 마일 거리에서도 중단 없이 작동하도록, 물리적·논리적 중복 구조와 다중 비행 컴퓨터를 통해 하드웨어 오류와 방사선 영향을 견디도록 설계됨
  • 각 Flight Control Module(FCM) 은 자체 검증 프로세서 쌍으로 구성되어 총 8개의 CPU가 병렬 실행되며, fail-silent 설계와 우선순위 기반 출력 선택 알고리듬으로 오류를 격리함
  • 시스템은 시간 트리거형 이더넷과 결정론적 아키텍처를 통해 완전 동기화 상태를 유지하고, 삼중화된 네트워크와 메모리로 단일 비트 오류까지 자동 수정함
  • 주 시스템이 모두 실패할 경우를 대비해 독립 하드웨어와 운영체제 기반의 Backup Flight Software가 제어권을 인계받으며, 이 구조는 향후 자율 시스템의 항상 가동 복원력 모델로 평가됨

NASA의 Artemis II 내결함성 컴퓨터 설계

  • Artemis II의 비행 컴퓨터는 Apollo 시대 항법 컴퓨터보다 복원력과 자동 제어 능력이 크게 향상된 구조
    • Apollo 컴퓨터는 1MHz 프로세서와 약 4KB 메모리를 사용했으며, 주요 제어는 수동 스위치나 릴레이 기반
    • Artemis II의 Orion 캡슐은 생명 유지, 전력, 통신 등 모든 핵심 기능을 컴퓨터가 직접 관리
  • 달 궤도 25만 마일 거리에서의 임무 실패는 복구 불가능하므로, 시스템은 우주 방사선, 비트 플립, 하드웨어 결함에도 중단 없이 작동해야 함
    • NASA는 물리적 중복 배선, 논리적으로 중복된 네트워크 평면, 다중 비행 컴퓨터를 통해 하드웨어 오류를 대비

  • The Power of Eight

    • Orion은 기존 삼중 중복(triple redundancy) 을 넘어서는 구조를 채택
      • 두 개의 Vehicle Management Computer(VMC) 각각에 두 개의 Flight Control Module(FCM)을 탑재해 총 4개의 FCM 구성
      • 각 FCM은 자체 검증(self-checking) 프로세서 쌍으로 이루어져 총 8개의 CPU가 병렬로 비행 소프트웨어를 실행
    • 시스템은 fail-silent 설계를 기반으로 하며, 오류가 발생한 CPU는 잘못된 출력을 내보내지 않고 즉시 침묵 상태로 전환
    • 다수결 투표 대신 우선순위 기반 소스 선택 알고리듬을 사용해 정상 채널의 출력을 선택
    • NASA는 Van Allen 복사대 통과 중 일시적 오류를 예상하며, 최대 22초 동안 3개의 FCM을 잃어도 마지막 FCM으로 임무를 지속 가능
    • 침묵 상태의 FCM은 재설정 후 다른 모듈과 동기화되어 비행 중 재참여 가능

  • 결정론적 동작 유지

    • 여러 독립 컴퓨터를 완전 동기화(lockstep) 상태로 유지하기 위해 결정론적 아키텍처(deterministic architecture) 를 적용
    • Orion은 시간 트리거형 이더넷(time-triggered Ethernet) 네트워크를 사용해 시스템 전체에 시간을 분배
      • 비행 소프트웨어는 ARINC653 스케줄러가 관리하는 주 프레임(major frame) 과 부 프레임(minor frame) 내에서 실행
      • 시간·공간 분할을 통해 입력과 출력이 네트워크 일정과 완벽히 정렬되도록 보장
    • 각 FCM은 동일한 입력을 받아 동일한 코드를 실행하고 동일한 출력을 생성
    • 각 초마다 FCM의 클록 드리프트를 측정해 네트워크 기준 시간으로 재보정
    • 마감 시간(deadline)을 지키지 못한 애플리케이션은 자동으로 침묵 상태로 전환 후 재동기화
    • 하드웨어는 삼중 모듈 중복 메모리(TMR) 를 사용해 단일 비트 오류를 자동 수정하며, 네트워크 인터페이스 카드도 이중 트래픽 경로를 비교해 오류 발생 시 fail-silent 처리
    • 네트워크는 세 개의 독립 평면으로 삼중화되어 있으며, 모든 스위치는 자체 검증 기능을 가짐

  • 최종 백업 시스템

    • NASA는 모든 주요 채널에 동시에 영향을 줄 수 있는 공통 모드 실패(common mode failure) 에 대비
    • 이를 위해 Backup Flight Software(BFS) 시스템을 별도로 탑재
      • BFS는 다른 하드웨어, 다른 운영체제, 독립적으로 개발된 단순화된 비행 소프트웨어로 구성
      • 주 시스템이 실패하면 자동으로 BFS가 제어권을 인계받아 임무의 동적 구간을 완료 가능
      • 이후 승무원이 주 FCM 복구를 시도할 수 있음
    • fail-silent 논리는 필수이지만, 오류가 감지되지 않은 채 남지 않도록 감시 타이머 및 다층 모니터링이 병행되어야 함
    • 전원 완전 상실(“dead bus”) 시에도 생존 가능하도록 설계
      • 전원 복구 시 자동으로 안전 모드(safe mode) 진입
      • 태양 전지판을 태양 방향으로 조정해 전력 회복 후, 열 안정화를 위해 기체를 태양에 꼬리를 향하게 함
      • 이후 지구와의 통신 재수립 시도, 필요 시 승무원이 수동으로 생명 유지 장치 조정 가능

  • 신뢰성의 미래

    • Apollo에서 Artemis로의 변화는 소프트웨어 복잡성의 비약적 증가를 의미
      • Apollo는 기계적 백업이 존재했지만, Artemis에서는 소프트웨어가 모든 제어를 담당
    • NASA는 전 환경 시뮬레이션, 몬테카를로 스트레스 테스트, 대규모 결함 주입(fault injection) 을 포함한 현대적 검증 워크플로를 사용
      • 슈퍼컴퓨터를 활용해 전체 비행 타임라인을 모의하고, 하드웨어 결함 상황에서도 소프트웨어가 fail-silent로 복구 가능한지 검증
    • Orion의 제로 톨러런스 아키텍처는 향후 자율주행차, 산업 제어망 등에서도 적용 가능한 항상 가동(always-on) 복원력의 모델로 평가됨

함께 보면 좋은 글 β

▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 1989년부터 95년까지 Stratus에서 VOS와 데이터베이스 성능 관련 일을 했음
    Stratus는 하드웨어 기반의 결함 허용(fault-tolerant) 시스템 회사였고, 경쟁사 Tandem은 소프트웨어 기반 접근을 했음
    Stratus의 구조는 “pair and spare”로, 모든 보드가 이중화되어 있었고 각 핀 출력을 매 틱마다 비교했음
    Motorola 68K에서 Intel로 전환할 때, 일부 명령어의 미사용 핀이 떠버리는 문제로 하드웨어 팀이 큰 어려움을 겪었음

  • CMU 연구자가 말한 “Agile과 DevOps가 아키텍처적 규율을 약화시켰다”는 표현이 인상적이었음
    요즘은 결정론적 시스템을 만드는 법을 잊은 것 같음
    Time-triggered Ethernet의 엄격한 프레임 스케줄링은 지금의 소프트웨어 개발 방식과는 완전히 다른 세계처럼 느껴짐

    • 아직도 실시간 보장이 필요한 임베디드 시스템을 다루는 사람들이 있음
      최신 개발 관행 중 일부(단위 테스트, CI 등)는 이런 환경에서도 긍정적인 영향을 줌
    • 아폴로 시절에는 국방부 중심의 연구 자금 덕분에 WCET(최악 실행 시간) 기반의 결정론적 컴퓨팅이 주류였음
      지금은 상업 시장 중심으로 바뀌며 투자가 줄었지만, 여전히 흥미로운 알고리즘이 많음
      Frank Mueller나 Johann Blieberger의 연구를 참고할 만함
    • Time-triggered Ethernet은 항공기 인증용 데이터 버스의 일부로, INRIA와 Airbus가 관련 연구를 했음
      항공기처럼 입력·출력이 한정된 환경에서는 결정론적 설계가 완벽히 들어맞음
      실제로는 이더넷이라기보다 전용 하드웨어 버스에 가까움
    • Tesla Cybertruck도 이 방식을 이더넷에 사용한다고 들었음
    • 아마도 그가 말한 것은 SpaceWire일 것 같음

  • Code Golf의 ‘radiation hardening’ 챌린지를 보며
    이런 접근이 실제로 쓸모가 있을까 궁금했음
    현실적으로는 너무 많은 층위의 문제가 얽혀 있어서 어렵겠지만, 그래도 흥미로운 아이디어라고 생각함

  • 기사에서 설명된 “fail-silent” 설계는 흥미로웠음
    하지만 두 CPU가 동시에 잘못된 계산을 하고 그 결과가 일치하면 어떻게 감지할지 궁금했음

    • 방사선으로 인한 동일 비트 오류가 동시에 두 CPU에서 발생할 확률은 극도로 낮음
    • 이런 CPU들은 lockstep 구조로 같은 연산을 동시에 수행하며 결과를 비교함
      두 CPU가 동시에 같은 오류를 내는 확률은 단일 CPU의 FIT보다 훨씬 낮음
    • 두 CPU가 동시에 같은 비트를 뒤집을 확률은 차라리 소행성 충돌이 일어날 확률보다 낮음
      그래도 우주에서는 Murphy의 법칙이 통하니 장담은 못 함
    • 사실 3중 다수결 구조에서도 두 CPU가 같은 오류를 내면 같은 문제가 생김
    • 시스템 1과 2가 동시에 잘못되고 나머지 6개가 정상이라면,
      “25% 다수결”로 잘못된 결과가 선택될 수도 있음

  • 이 시스템의 CPU, RAM, OS, 언어 등에 대한 구체적인 정보가 궁금함
    얼마나 자주 FCM이 “fail-silent” 되었는지도 알고 싶음

    • NASA cFS는 C로 작성되었고, GitHub에 공개되어 있음
      보통 FreeRTOS나 RTEMS 위에서 동작함
      개인적으로는 프로젝트 구조가 너무 복잡해서 다루기 힘들었음
    • BFS는 cFS를 사용하며, YouTube 영상에서도 볼 수 있음
      NASA의 핵심 코드는 대부분 비공개지만, cFS는 고전적인 비행 소프트웨어 설계를 배울 수 있는 좋은 자료임

  • 기사에서는 실제 RTOS와 아키텍처에 대한 세부 내용이 빠져 있음
    Orion의 주 비행 제어는 Green Hills INTEGRITY RTOS와 BAE RAD750 프로세서 기반의 4중 중복 구조임
    BFS는 완전히 다른 LEON3 + VxWorks 하드웨어에서 동작하며, NASA의 cFS 프레임워크를 사용함
    이는 James Webb 망원경과 Mars Rover에도 쓰인 모듈형 재사용 아키텍처임
    이런 구조는 단순한 “주 시스템 + 백업”이 아니라, 이기종 중복(dissimilar redundancy) 개념임
    자세한 내용은 NASA 기술 문서 1, 문서 2에서 볼 수 있음

    • 하지만 완전히 다른 팀이라 해도, 같은 교재나 알고리즘 출처를 쓰면 동일한 오류가 생길 수 있음

  • 실제 제작은 Lockheed Martin과 하청업체들이 담당했음
    언론이 NASA가 직접 만든 것처럼 표현하는 건 오해를 부름

    • Lockheed가 NASA 요청 없이 이런 고가의 4중 중복 PowerPC 시스템을 만들었을 리는 없다고 생각함
    • BFS는 NASA 내부에서 주로 개발되었음 (직접 참여한 친구의 증언)
    • 실제로는 NASA와 Lockheed 간에 긴밀한 협업이 있었을 것임
    • “메가코프를 생각해보라”는 농담도 나왔음

  • 25년 전 웹 개발자로 일할 때, NASA 출신 친구에게 “버그는 어떻게 처리했냐”고 물었더니
    그가 웃으며 “버그가 없었음”이라고 답했음
    오늘날의 개발자들은 실패해도 사람 목숨이 걸리지 않는 환경에 익숙해져 있음

    • 산업마다 “충분히 괜찮음”의 기준이 다름
      웹 서비스는 매출 손실 정도지만, 우주선은 인명이 걸려 있음

  • 예전에 방사선 내성 컴퓨터를 개발한 적이 있는데,
    단순한 중복 외에도 비중복적 오류 검출 기법을 썼음
    이번 시스템은 그런 접근이 보이지 않아 아쉬움

    • 셔틀 시절에는 5대의 컴퓨터를 서로 다른 위치와 방향에 설치해서
      방사선 충돌 단면을 분산시키는 물리적 하드닝도 했었음

  • 여러 중복 구조가 훌륭하긴 하지만, 수동 조종(Manual Override) 기능이 여전히 가능한지 궁금함
    아폴로 11과 13처럼 필요할 때 직접 제어할 수 있는지 알고 싶음
    여전히 테스트 파일럿 출신 우주비행사들이 조종하니 가능할 것 같음

답변달기