2014년 12월 영국 항공 교통 관제 시스템 장애

컴퓨터 시스템 장애로 인한 런던 항공 교통 정체

• 2014년 12월 12일 금요일 오후, 영국 Hampshire의 Swanwick에 위치한 영국 항공 교통 관제 서비스(National Air Traffic Services: NATS) 본부에서 항공 교통 관제사들이 사용하는 컴퓨터 시스템에 기술 실패가 발생
• 런던과 영국 남동부 영공이 일시적으로 제한 운행됨에 따라(영공 폐쇄는 아니지만 장애 상황을 관리하기 위해 수용력을 줄임) 런던 주변 주요 공항(Heathrow, Gatwick, Stansted, Luton, London City)에서 일부 비행이 취소 및 지연됨
• 유럽에서 가장 바쁜 공항으로 알려진 Heathrow 공항의 경우 금요일 약 1,300건의 계획된 비행 중 70건이 취소되었으며, 100,000여 명의 승객이 영향을 받음
• 항공 교통 정체가 3:30pm 부터 4:30pm 까지 약 1시간 가량 지속되다가 금요일 저녁 “완전 운행 수용력(full operational capability)”으로 복구되었지만, 도미노 효과로 인해 일부 공항에서는 다음날 오전까지도 예정된 비행이 일부 취소됨

 

[2014년 12월 13일자 Sky News의 보도]

 

NATS 시스템 장애 원인

• 항공 교통 관제 서비스 실패의 근본원인을 밝히기 위한 민간항공국(the Civil Aviation Authority: CAA)의 조사가 2015년 1월 13일 공식적으로 시작되었고, 2015년 5월 13일 최종 조사 보고서가 발표됨
• 이 보고서에 따르면 2014년 12월 12일 발생된 실패가 1990년대부터 SFS(System Flight Server) 소프트웨어에 존재했던 잠복 결함 때문이라고 함. 2002년 Swanwick 관제 센터에서 SFS 시스템이 첫 운영에 들어가기 시작한 시점부터 이 버그가 존재했지만, 시스템 운영에서 전에는 발생하지 않았던 상황들의 조합이 일어나면서 트리거 됨(아래 더 자세한 설명)

 

NERC(New En-Route Centre)

• NERC(The New En-Route Centre)는 잉글랜드 및 웨일즈 영공의 고고도 비행 관제를 담당하는 런던 지역 관제소(London Area Control: LAC)를 위한 컴퓨터 시스템 프로젝트. Swanwick 관제 센터에서 NATS의 관제 활동을 지원하는 NERC 시스템이 2002년 이후로 서비스 중임
• NERC는 레이더 및 비행 데이터 처리, 음성 통신 및 지원 정보, 테스팅/개발/훈련 지원을 위한 시뮬레이션 기능 등을 포함한 다양한 기능을 커버하는 완전 통합 시스템임. NERC 시스템의 주 공급 업체는 Lockheed Martin이며, Ada 언어로 소프트웨어가 작성됨
• 아래 그림은 NERC 시스템 아키텍쳐의 단순화된 뷰. 중심부에 위치한 SFS(System Flight Server)는 중앙 비행 계획 시스템인 NAS(National Airspace System)로 부터 비행 계획을 입력 받고, 이를 처리하고, 적절한 관제사 워크스테이션으로 배포함

 

[LAC를 지원하는 주요 시스템들 – 단순화된 버전]

 

SFS(System Flight Server)

• Swanwick 관제 영역에서의 앞으로 4시간 동안의 비행 데이터를 저장하고 분배하는 소프트웨어. 어떤 섹터가 어떤 워크스테이션에서 관리되고 있는지 기록. SFS는 또한 비행 계획 데이터에 동적 정보(예, 관제사로부터의 간격 및 조정 데이터)를 덧붙임
• LAC의 안전한 운영을 위해서는 워크스테이션 상의 정보가 SFS에 있는 정보와 일관성을 유지하는 것이 중요. 각 관제사가 착수한 활동이 ‘Atomic Function’으로 알려진 고유한 식별자로 레이블이 주어져 있기 있기 때문에 SFS가 정확한 워크스테이션으로 정보를 보낼 수 있음
• 중복성(Redundancy)을 위해 두 개의 SFS가 가동됨(하나는 주 시스템 다른 하나는 2차 시스템). 보통은 주 시스템이 관제를 담당하며, 주 시스템이 실패하면 2차 시스템이 인계 받음. 주 SFS가 복구될 때까지는 시스템이 단일 SFS 만으로 운영됨

 

시스템 실패의 원인

• 관제사 역할과 감독관 역할(Atomic Functions으로 불림)의 최대 허용 가능한 수에 대한 체크를 하는데 있어 결함이 있었음. Atomic Function 식별자는 SFS의 데이터 테이블에 인덱스(액세스)하거나 각 역할에게 정확하고 관련 있는 데이터를 분배하는데 사용됨. 최대 허용치 체크에서 민간용 역할과 군용 역할의 총 한계치인 193 Atomic Functions에 도달했는지 아닌지를 확인해야 했지만 소프트웨어가 대신 민간용 역할 한계치인 151에 대한 체크를 수행함
• 사고가 발생했을 당시 사용 중인 Atomic Functions의 총 수가 153이였음(사고 하루 전날인 12월 11일에 추가적인 군용 관제사 역할을 포함하기 위한 시스템 변경이 시행되었기 때문에 처음으로 이런 수치에 도달하게 됨). 이 변경 자체로는 실패를 야기시키기에 충분하지 않았지만 실패로 이어지게 만든 특정한 트리거가 있었음
• LAC 오퍼레이션 룸의 워크스테이션은 지켜보는 사람이 없을 때도 보통은 “Signed On” 상태로 남겨짐(언제든 바로 사용 가능하도록 하기 위해). 하지만 관제사가 “Signed On”이 아닌 워크스테이션 상에서 “Select Sectors” 버튼을 누르면 해당 워크스테이션이 “Watching Mode”로 들어가게 됨. SFS가 Watching 모드에 들어가라는 커맨드를 받으면 일부 시스템 데이터의 복사본을 담기 위한 내부 테이블을 생성함(단지 “Watching” 일뿐 실제 관제가 아니므로 이게 복사본임). 이 테이블에 인덱스(액세스)하는데 Atomic Functions이 사용됨
• 12월 11일 발생한 추가적인 군용 관제사 역할의 포함과 12월 12일 14:44분 당시의 영공 관제 상황 때문에 Watching 모드로 진입하라는 의도치 않은 리퀘스트가 153개 엔트리를 가진 Atomic Functions 테이블 생성으로 이어짐(즉, 그 시점의 모든 관제사와 감독관 역할을 반영). 이게 테이블의 허용되는 최대 크기에 대한 체크를 실패하게 만들었고(한계치로 193이 아닌 151이 사용되었기 때문), 그 결과 소프트웨어 실행 내에서 제기되는 “exception”으로 알려진 내부 에러가 발생
• 워크스테이션 상태와 SFS 상태 간의 불일치는 잠재적으로 불안전함(관제사에게 잘못된 데이터가 주어질 수도 있으므로). 따라서 SFS가 이런 “exception”에 대응하여 주 SFS를 셧다운하도록 설계되고 구현됨. 하지만 SFS의 가용성을 보존하는 것도 중요하므로 컨트롤이 2차 SFS에게로 넘겨지게 되었고, 2차 SFS가 워크스테이션으로부터의(“보류된 커맨드” 리스트로부터의) 커맨드를 재처리 함. 만약 하드웨어 결함이 주 SFS의 실패를 야기한 것이라면 이런 실패 처리(failure handling) 방식이 적절하지만, 이 경우는 결함이 SFS 코드에 있었고 이게 워크스테이션으로부터의 커맨드에 의해 트리거 되었기 때문에 2차 SFS의 소프트웨어에서 동일한 exception이 제기되었고 마찬가지로 셧다운 됨. 이런 이중 SFS 실패가 12월 12일 14:44분에 발생했고, 이것이 각 관제사의 화면에 보고되면서 항공기 움직임(규정) 상에 제한이 가해지게 됨

 

[관제사 워크스테이션의 스크린 레이아웃]

 

시스템 실패의 기여 요인

2014년 12월 12일 시스템 실패의 가장 근접한 원인은 위에 설명된 대로 SFS 소프트웨어에 있는 결함(구체적으로는 관제사 및 감독관 역할의 최대 허용 수에 대한 잘못된 체크 사용). 하지만 이 결함 단독으로 SFS의 실패를 초래했다고 보기 어려우며, 아래의 여러 요인이 종합적으로 작용했음

• 2014년 12월 11일 추가적인 군용 관제사 역할을 포함하는 변경이 생김
• 한 관제사가 의도치 않게 “Watching Mode”를 선택함
• 워크스테이션의 HMI(Human Machine Interface) 설계: “Watching Mode”로 들어가라는 커맨드가 우발적으로 주어진 점에 비춰 HMI 설계도 이 실패에 기여함. 사고 후 조사에 따르면 워크스테이션이 우연히 “Signed Off” 상태로 남겨지는 바람에 관제사가 무심코 Watching 모드로 들어가는 일이 전에도 심심찮게 있었음(2014년 12월 12일 사건이 있기 전까지는 수 차례 이런 일이 있었어도 그게 서비스 방해로까지 이어지지는 않았음)
• 시스템 아키텍쳐(특히 실패 처리 방법)

 

로그 활용을 통한 실패 원인 특정

• 이렇게 큰 시스템(애플리케이션 전체 규모가 소스 코드 2백만 라인이 넘음)에서 단 몇 시간 만에 소프트웨어 결함 식별이 가능했던 데는 로그가 잘 보존되고 분석되었기 때문임. 이 로그가 워크스테이션에서의 상호작용에 대한 상세사항들을 포함(예, 디스플레이 상의 “soft keys” 선택, 워크스테이션과 SFS 간 전송된 메시지, 시스템 실패나 소프트웨어 예외 같은 주요 이벤트 기록 등)
• 로그가 사람이 읽고 이해할 수 있는 형식이기는 하지만 부피가 커서 완전히 수동으로 분석되기는 어려우며, NATS가 로그 분석에 사용되는 표준 기능 집합을 가지고 있었음. 이 기능들의 일부는 지속적으로 실행되며 자동으로 에러 보고서를 생성함(예, SFS 실패가 있으면 담당 엔지니어와 관리자가 이메일 알림을 받음). 또한 근무 중인 엔지니어가 로그에 적용할 수 있는 쿼리 및 기타 기능들도 존재해 특정 상황에 대한 분석을 가능케 함. 이것이 12월 12일 실패를 트리거한 이벤트들을(“Watching Mode” 소프트키를 누르고 2차 SFS에서 이 커맨드가 리플레이 됨) 빠르게 식별하는 것을 가능하게 함
• 이 로그가 또한 실행 코드(엄밀히 말하자면 실행 코드를 생성하도록 작성된 소스 프로그램)로 연결되어 있음. 따라서 로그의 예외 기록으로부터 결함의 위치로 판단되는 특정한 SFS 소프트웨어 모듈로 역추적하는 것이 가능했으며, 이후 이 모듈의 소스 코드에 대한 수작업 인스펙션을 통해 결함을 찾아냄

 

 

 

참고자료: NATS System Failure on 12 December 2014 – Final Report dated 13 May 2015