지난 3월 19일(현지시간) 미국 법무부가 토요타와 벌금 12억 달러에 지난 4년 간 이어진 급발진 관련 수사를 종결하는 데 합의했다. 토요타는 벌금을 내는 대신 3년 간 기소유예 처분을 받아 당장은 형사처벌을 면하게 됐다. 본고에서는 소송 과정에서 밝혀진 여러 가지 사안을 토대로 소프트웨어 공학적인 측면에서 토요타 제어 소프트웨어의 문제점을 설명한다.

최근 심심치 않게 자동차 급발진(Unintended Acceleration, UA) 관련 사고 소식을 듣게 된다. 자동차 급발진에 대한 위키피디아(Wikipedia) 정의에 따르면 다음과 같다.

“갑작스런 급발진 사고”는 정지된 상태거나 상대적으로 브레이크 제동력을 잃어버리지 않는 아주 낮은 초기 속도에서 시작된 의도하지 않으며, 기대하지 않은 강력한 가속으로 정의한다.
일반적으로 자동차의 가속 시스템과 브레이크 시스템이 동시에 실패할 경우 급발진 현상이 일어난다. 그렇다면 자동차 급발진을 일으키는 요인은 무엇일까? 다음 네 가지를 생각해보자.

▶ 페달 착각: 브레이크와 가속 페달을 혼동할 경우
▶ 옴짝달싹 하지 않는 페달: 가속 페달을 밟았는데, 발을 땐 상태에서도 계속 눌러진 경우
▶ 전자 스로틀 제어나 크루즈 컨트롤 실패(drive by wire의 경우): 제어 시스템의 오류로 인해 스로틀이나 크루즈 컨트롤이 통제 불능 상태에 빠질 경우
▶ 스로틀 잠김: 가속 페달 위치와 무관하게 스로틀이 고정되는 경우

초기에는 운전자의 운전 미숙이나 실수(예: 페달 착각), 하드웨어 설계 결함(예: 매트가 가속 페달을 계속 눌러 옴짝달싹 하지 않게 만드는 현상)에 초점을 맞췄지만, 자동차의 전자화가 가속화되면서부터 점차 급발진 현상도 늘어나는 상황에 부딪히자 자동차에 탑재된 제어 소프트웨어의 결함을 의심하기 시작했다. 하지만 확실한 원인을 파악하지 못한 상태로 대다수 사건이 종결되는 상황에서, 2007년 10월 20일에 일어난 토요타 2005년식 캠리(Camry)의 급발진으로 인한 사망 사고의 민사 소송 건(Bookout v. Toyota) 하나가 상황을 완전히 바꿔놓았다. 미국 도로교통안전청(NHTSA)과 항공우주국(NASA)의 조사에서도 밝혀내지 못한 중요한 몇 가지 사실들을 임베디드 소프트웨어 전문가인 마이클 바(Michael Barr) 교수가 이끄는 바 그룹(Barr Group)에서 파악하는 데 성공한 것이다. 즉 토요타 제어 소프트웨어가 자동차 급발진의 원인일지도 모른다는 구체적인 분석 결과가 나온 것이다.



예견된 사고

앞서 급발진에 대한 원인을 설명한 내용을 바탕으로 자동차의 전반적인 제어 시스템을 구성해보면 크게 가속 페달 센서, 스로틀 제어 모터, 스로틀 위치 피드백 센서, 스로틀 밸브, 그리고 이 모든 센서와 구동 장비를 제어하는 엔진 제어모듈(Engine Control Module, ECM)이 전면에 등장한다. 여기서 운전자의 제어를 받아들여 내연기관을 제어하는 핵심은 ECM이며, ECM은 소프트웨어로 구동하도록 설계돼 있다는 사실에 주목하자.

그림 1을 보면 스로틀을 제어하는 명령은 크게 페달 입력, 공회전 속도, 크루즈 컨트롤, 변속, 안전성 제어라는 5가지다. 각각에 대해 닫힌 루프(closed loop)를 돌면서 스로틀을 제어하며, 문제가 생겼을 경우에 방어를 위한 안전 시스템 모드(fail safe mode)가 존재한다. 자동차 급발진은 이렇게 구성된 제어 시스템의 어느 한 곳 또는 여러 곳에 문제가 생겼을 경우 발생하지만, 각 구성요소가 단독으로 동작하지 않고 상호작용을 일으키기 때문에 정확한 원인을 찾아내기가 쉽지 않다. 지금까지 ECM은 완전무결한 성역으로 생각하고 페달과 같은 하드웨어 부문에 집중해왔지만, 소프트웨어 부문으로 범위가 넓혀지면서 급발진의 원인 분석이 더욱 복잡해지는 경향이다.

참고로 2005년식 토요타 캠리의 스로틀 제어 시스템인 ETCS-i(Electronic Throttle Control System-intelligence)는 접촉 타입 가속 페달과 스로틀 위치 센서를 장착한 모델로 비접촉식 가속 페달과 스로틀 위치 센서를 장착한 최신 모델과는 기계적인 구조가 조금 다르다. 하지만, 제어에 ECM이 적극적으로 개입한다는 점은 동일하다.

NASA에 따르면, 토요타 ETCS-i는 안전성이 중요한 경성 실시간 시스템(hard real-time system)으로 분류된다. 해당 시스템이 실패할 경우 금전/인명 피해를 일으키며, 시스템이 반응하는 속도가 정해진 기준을 넘어서면 실패한다는 의미이다. ETCS-i의 소프트웨어 품질에 따라 실시간 시스템의 속성을 충족하는지 여부가 판가름 나므로 NHTSA와 NASA에서 소스 코드 검토를 결정한 것은 우연이 아니다.


그림 2는 토요타 캠리 2008년식 ECM (Engine Control Module)이며, 여기서 가장 중요한 부품은 바로 덴소에서 제작한 모니터 칩(ESP-B2)과 NEC(지금은 르네사스)에서 제작한 32비트 RISC 메인 CPU(V850)다. 캠리 2005년식 ECM도 부품 위치만 조금 다를 뿐 사실상 동일한 구조다. 각 마이크로프로세서는 독자적인 소프트웨어로 구동하도록 돼 있다. NHTSA의 의뢰를 받아 NASA에서 수행한 작업은 바로 메인 CPU에서 구동하는 임베디드 소프트웨어의 분석이었으며, 다음과 같은 몇 가지 사실을 밝혀냈다.

▶ 메인 CPU에 탑재된 소프트웨어는 대부분 ANSI C로 작성됐으며 그린힐스 소프트웨어(Green Hills Software) C 컴파일러를 사용해서 컴파일했다.
▶ 실시간 태스크를 관리하기 위해 OSEK 표준을 따르는 실시간 운영체제의 고정 우선순위 선점형 스케줄링 기법을 사용했다.
▶ 실제 펌웨어 개발(설계, 코딩, 단위 테스트)은 덴소에 외주를 줬으며, 토요타는 통합 테스트와 몇 가지 사용/내부 정적 도구를 사용한 검증을 수행했다.

아쉽게도 분석시간 부족 등의 이유로 인해 NASA는 캠리의 급발진을 일으키는 정확한 원인을 특정하는데 실패했지만, 다음과 같은 사안에 대해서는 잠재적인 문제점으로 지적하고 넘어 갔다.

▶ 보고된 사고 중 절반 이상이 알 수 없는 원인으로 인해 스로틀이 과도하게 개방되어 있는(25도 이상) 상태다.
▶ 엄청나게 많은 전역 자료를 줄여야 하며, 죽은 코드(dead code: 수행 과정에서 실행되지 않는 코드 영역)를 제거해야 한다.
▶ 재귀적으로 중첩된 인터럽트 마스킹으로 인한 경쟁 조건이 우려된다.
▶ 멀티 프로세싱과 비동기식 소프트웨어 제어 흐름에서 비현실적인 타이밍 지연이 개입돼 있다.
▶ 표준 gcc 컴파일러(버전 4)를 사용할 경우 컴파일 과정에서 (11가지 경고 범주에 걸쳐 100가지가 훨씬 넘는) 엄청나게 많은 경고가 나온다.

그렇다면 바 그룹에서는 NASA의 작업을 출발점으로 토요타 ETCS-i 소프트웨어에서 어떤 문제점을 추가로 발견할 수 있었는가?

공포의 스파게티 코드와 기준 미달의 코드 품질

스파게티 코드란, 흔히 자료와 코드 흐름을 뒤죽박죽으로 만들어 분석이나 수정이 쉽지 않은 코드를 얽히고설킨 스파게티 면발에 비유해 일컫는 용어다. 스파게티 코드가 현실에 미치는 영향이 중요한데, 코드 품질을 떨어뜨린다는 측면에서 간과할 수 없다. 스파게티 코드는 크게 다음 두 가지 유형이 존재한다.

1. 자료 흐름 스파게티
소프트웨어 모듈 사이나 태스크 사이에 복잡한 결합도가 존재하는 경우를 일컫는다. 소프트웨어에 존재하는 전역 변수의 수를 세보면 어느 정도 코드가 복잡한지 파악할 수 있는데, NASA가 분석한 결과에 따르면 캠리 2005년식 모델의 ETCS-i 소프트웨어에는 무려 1만 1,000개가 넘는 전역 변수가 존재하고 있었다.

2. 제어 흐름 스파게티
매우 길고 복잡하게 중첩된 함수가 존재하는 경우를 일컫는다. 순환 복잡도는 테스트가 어느 정도 용이한 지를 파악하는 기준이 되는데, 캠리 2005년식의 경우에는 67개 함수의 점수가 50점을 넘어섰고(“테스트 불가” 판정), 스로틀 각도 함수는 무려 100점을 넘어섰다(“유지보수 불가” 판정).

스파게티 코드 자체가 급발진의 직접적인 원인이 되지 않더라도 간접적인 원인을 제공하기 때문에 매우 중요하다. NASA 조사 결과에 따르면, 토요타의 ETCS-i C 소스 코드는 구조적인 설계 방식을 따르지 않았으며, 통신 관련 명세서가 존재하지 않고, 크루즈 컨트롤 관련 명세는 1:1로 대응되지 않는 문제점이 있었다. 이와 관련한 지적사항이 나오고 나서야 스파게티와 같은 엔진 제어 소프트웨어를 개선하기 위한 활동이 시작됐다.

코드 품질과 관련해 토요타는 차량용 운영체제를 위한 표준 소프트웨어 아키텍처인 OSEK 표준을 준수한다고 했지만, 토요타의 Rx-OSEK850은 2002년 V850으로 인증 받고 나서 확장이 가해지는 바람에 비표준 상태였다. 토요타는 안전한 소프트웨어 제작을 위한 표준인 MISRA-C를 따른다고 했지만 7,000건(NASA 자료)에서 8만 건(바 그룹 자료)에 이르는 위반사항이 있었다고 한다. 바 그룹의 조사 결과, 최소한 32%에 이르는 ETCS-i C 소스 코드에서 MISRA-C 위반이 발견됐다고 하니 잠재적인 문제점을 무시할 수 없는 수준이라고 할 수 있다.

코딩 표준과 관련해서도 토요타는 내부적으로 ECM 소프트웨어 개발자들(특히 파워트레인 관련 부문)이 따라야 하는 코딩 규칙을 유지한다고 했으나, NASA 조사 결과 이렇게 제정된 규칙 위반이 여러 곳에서 일어났음이 밝혀졌다. 동료 간 검토 작업이 부족했고, 추적되지 않았으며, 버그 추적 시스템도 제대로 운영되지 않았다.

이런 복합적인 요인으로 인해 토요타의 ETCS-i 소프트웨어는 합리적인 품질을 보증하는 데 실패함으로써 급발진을 일으킬 수 있는 버그를 포함하게 됐다고 할 수 있다. 또한 “카드를 쌓아 집을 만드는 식의” (위험한) 안전관련 아키텍처를 수립함으로써 하드웨어와 소프트웨어 결함이 발생했을 경우 적절히 대처하는데 실패했다. 결국 토요타 ETCS-i의 이상 동작이 급발진을 일으킨 한 가지 원인이 됐다.

SW 오류를 찾아서

NASA는 토요타 ETCS-i와 관련해 스파게티 코드와 품질 문제를 밝혀냈지만, 직접적인 급발진과 연관 관계를 밝혀내지 못했다. 그렇다면 바 그룹은 2005년형(L4) 캠리 소스 코드 분석과 자동차 테스트에서 어떤 사실을 찾아낸 것인가? 바 그룹이 토요타 ETCS-i 소프트웨어에서 찾아낸 결함은 크게 두 가지 대분류로 나뉜다.

1. 메모리 손상을 일으키는 원인이 존재했다.
   - 스택 오버플로(stack overflow)가 발행할 수 있다(NASA는 스택의 절반 이하만 사용된다고 들었다).
   - 소프트웨어 버그가 있다(NASA에서도 찾긴 했지만, 바 그룹에서 추가로 문제점을 찾았다).
2. 몇몇 중요한 변수가 손상에서 보호받지 못했다.
   - 변수 복제(mirroring)가 항상 수행되지 않았다(NASA는 변수 복제가 항상 수행된다고 믿고 있었다).
   - 비트 뒤집기에 대한 하드웨어 보호가 없었다(NASA는 메인 CPU의 RAM에 EDAC가 있었다고 들었다).

스택 오버플로 오류

먼저 메모리 손상부터 살펴보자. 표 1은 메모리 손상을 일으키는 소프트웨어 결함 유형을 정리한 내용이며, 캠리 2005년식 ETCS-i에 모두 존재하는 상황이다. 그 중에서도 특히 스택 오버플로 오류는 NASA도 발생 가능성을 인지했지만, 토요타 쪽 설명을 듣고서 안전하다고 믿어버리는 실수를 범했다.

NASA는 깊숙하게 중첩된 재귀호출이 스택 공간을 소비하며, 결국 테스트 과정에서 감지하기 어려울지도 모르는 메모리 손상과 실행 시점의 실패를 초래한다고 파악했다. 스택 오버플로가 생길 경우 ETCS-i의 CPU에 메모리 보호 기능이 없기 때문에 정밀하게 감지할 수 없다는 문제점 역시 인지하고 있었다. 하지만 토요타 쪽에서 안전을 위해 ETCS-i 소프트웨어에 여분으로 4,096바이트 정도 메모리를 더 할당한다는 말을 듣고서 스택 오버플로가 일어나지 않을 것으로 생각했다.

그러나 토요타의 스택 분석 작업에는 심각한 문제점이 있었다. 포인터를 사용한 함수 호출을 고려하지 않았고(이는 자동화된 도구로 파악하기 어렵다), 라이브러리와 어셈블리 함수에서 사용된 스택을 포함하지 않았다. 결국 대략 함수 350개를 누락시키는 실수를 저질렀다. 또한 문맥 전환(context switching)을 위한 운영체제의 스택 사용을 고려하지 않는 결정적인 실수를 저지르고 만다. 심지어 하위 모델인 토요타 코롤라(Toyota Corolla) 2005년식 ECM에도 들어있는 실행 시점 스택 감시 기능이 빠진 상황에서 위험한 재귀호출을 사용한 결과 스택 한계를 넘어 OSEK의 주요 자료 영역을 침범하는 상황이 벌어졌던 것이다.

그림 3은 토요타가 NASA에 언급한 41%라는 스택 사용률을 넘어 94%까지 사용하는 상황을 보여준다. 커널이나 시스템 소프트웨어를 작성할 때 피해야 하는(MISRA-C 규칙에서도 이를 규정하고 있다) 재귀호출 결과로 인해 얼마 남지 않은 스택 공간을 소진해 오버플로가 발생하는 문제가 있었지만 토요타는 이를 심각하게 생각하지 않았다고 볼 수 있다.

변수 복제

메모리 오류를 살펴봤으므로, 변수 손상에 대한 오류 중 첫 번째인 변수 복제 문제를 설명한다. 토요타 엔지니어들은 소프트웨어와 하드웨어 손상으로부터 여러 변수를 보호하기 위한 방법을 찾았다. 복제(mirroring)는 특정 변수 내용을 원본과 다른 위치에 둠으로써 손상이 일어났을 때 복원하게 만드는 기법이다. 하지만 토요타 엔지니어들은 몇 가지 핵심 변수를 복제하지 않았는데, 그 중에는 OSEK의 중요한 내부 자료 구조와 목표 스로틀 각도를 담은 전역 변수도 포함돼 있었다.

모든 태스크가 살아 있을 때, 목표 스로틀 각도는 매 8밀리 초(ms)마다 다시 계산돼 스로틀을 개방하는 일종의 명령으로 동작한다. 하지만 변수 복제에 실패함으로써 사용자가 가속 페달을 밟아서 값이 설정됐는지, 아니면 손상에 의해 값이 설정됐는지를 구분할 수 없게 됐다. 일반적인 경우라면 다른 오류 감지 시스템과 맞물려 해결될 수도 있는 문제였지만, 안전 시스템의 설계 결함으로 인해 걷잡을 수 없는 파급효과가 발생했다. 이는 뒤에 이어지는 ‘결함 있는 안전 계층’에서 다시 설명한다.

비트 뒤집기

계속해서 변수 손상과 관련한 두 번째 오류인 태스크 관리 자료 구조체의 비트 설정 문제를 설명한다. 토요타의 ETCS-i 소프트웨어는 다양한 작업을 위해 태스크가 총 24개 돌아가고 있다. 태스크는 몇 개씩 묶여 그룹을 이루며, 해당 그룹에 대한 작업 관리는 비트맵 형태의 자료 구조를 사용한다.

그림 4를 보면 상단의 Top-Tier Bitmap이 바로 태스크 관리를 위한 비트맵 자료 구조이며, Middle-Tier Array와 Bottom Tier Queues가 태스크 그룹을 담기 위한 배열과 큐 자료 구조다. Top-Tier Bitmap에서 상단의 18에 대응하는 비트를 뒤집으면 대응하는 태스크 그룹에 속한 태스크가 중단된다. 문제는 메모리 손상으로 인해 비트가 뒤집힐 경우에 태스크 그룹이 모두 중단될 수 있다는 점이다. 태스크 그룹이 잘 분산돼 있는 경우라면 다행이지만, 그렇지 않은 경우에는 정상 동작에 심각한 영향을 미칠 수도 있다.

예를 들어, 스로틀 각도를 바꾸는 태스크와 가속 페달을 감지하는 태스크가 하나의 그룹으로 묶여 있다고 가정하면, 두 태스크가 동시에 중단될 경우에는 가속 페달의 변화에 무관하게 스로틀 각도가 고정돼 버린다. 그림 5를 보면 태스크가 죽은 직후 30초 동안 급발진이 이뤄지는 데, 브레이크를 밟았음에도 스로틀이 잠긴 상태로 유지된다.

그림 6에 의하면, 태스크의 중단을 일으키는 상황이 브레이크 페달을 밟음으로써 시작되면 운전자의 의도와 무관하게 급발진 현상이 발생하게 된다. 이런 상황에서는 운전자가 직관에 반하는 행동(즉, 급가속 상태에서 벗어나 안전 시스템이 동작하기 위해서는 브레이크 페달에서 발을 완전히 때야 한다)을 취해야 상황을 바꿀 수 있다. 이는 급발진 상황에서 브레이크 페달을 밟고 있으면 계속해서 자동차에 가속이 붙는 아이러니한 현상을 명확하게 설명한다.

결함 있는 안전 계층

소프트웨어 오류가 하나만 발생할 경우에는 큰 문제가 되지 않을지도 모른다. 그림 7과 같이 토요타 ETCS-i 시스템에는 총 4층으로 이뤄진 안전 시스템이 장착돼 있기 때문에, 토요타 엔지니어들은 오류에 대한 방어가 가능하다고 생각했다. 하지만 만일 찰스 페로가 주창한 정상 사고(Normal Accident) 상황에서는 복잡하고 밀접하게 결합된 시스템에서 예상하지 못한 실패의 연쇄반응이 일어나 전체 시스템을 붕괴시킬 수도 있다. 지금부터는 결함 있는 안전 계층이라는 주제를 놓고 각 층이 급발진 사례와 관련해 어떻게 안전을 담보하는데 실패했는지를 설명한다.



1층

1층은 중요한 변수를 복제함으로써 변수 손상을 방지하는 방식을 사용하고 있다. 하지만 앞서 설명했듯이 몇 가지 중요한 변수를 복제하지 않는 문제가 있었다. 토요타의 스로틀 명령 설계에 따르면, 가속기 페달 각도를 태스크 X가 읽어서 스로틀 각도를 담는 전역 변수에 쓰고, 모니터 제어 태스크는 이 스로틀 값을 읽어서 스로틀 각도를 조절하도록 돼 있다. 만일 태스크 X가 중단되거나 전역 변수가 손상당할 경우에 어떤 현상이 벌어질까? 태스크 X가 중단될 경우에는 운전자가 스로틀을 제어할 수 없는 상황에 직면하게 된다.

가속 페달을 조작하더라도 스로틀 각도를 바꾸지 못하며 크루즈 컨트롤 스위치도 영향을 미치지 못한다. 따라서 모터 제어 태스크는 마지막으로 계산된 스로틀 전역 변수 값이나 손상된 스로틀 전역 변수 값을 토대로 스로틀 각도를 제어하므로 엔진을 가동 상태로 만든다. 다시 말해 손상을 일으키는 이벤트 하나만으로도 태스크를 중단하게 만들고 스로틀을 열린 상태로 유지할 수 있다.

그림 8은 태스크 X가 죽은 상태에서 메모리 손상이 발생했을 경우 일어나는 상황을 보여준다. 스로틀 명령을 담은 전역 변수가 복제되지 않았기 때문에 메모리 손상이 발생하더라도 이를 감지할 방법은 없다. 게다가 태스크 X는 가속기, 크루즈 컨트롤, 브레이크 오버라이드(brake override) 동작과 같은 온갖 기능이 다 담겨 있으므로 상황을 더욱 심각하게 만들었다.

2층

1층에서 오류가 발생할 경우 2층에서 방어에 들어가게 돼 있다. 토요타 ETCS-i와 관련해 NASA가 분석한 5가지 안전 시스템은 다음과 같다.

▶ Limp home modes 1-3: 가속 페달 센서와 관련해 신뢰하지 못하는 각도 감시
▶ 공회전 시 연료 차단: 2,500 PRM 제한
▶ 엔진 중단: 심각한 결함을 발견했을 경우

하지만, 이 모든 5가지 안전 시스템과 진단 안전 코드 시스템이 앞서 언급한 태스크 X에서 수행한다는 점이 문제다. 스로틀 컨트롤과 안전 시스템이 동일한 결함을 내포하고 있는 영역에 위치하므로 일단 문제가 생기면 스스로 이를 감지해 복구할 방법이 없다.

3층

2층까지 통과한 문제는 원칙적으로 워치독 관리자(또는 타이머)가 걸러내야 마땅하다. 워치독 타이머(Watchdog Timer)는 자동으로 소프트웨어를 재설정하는 하드웨어로, 건강한 소프트웨어라면 재설정을 막기 위해 주기적으로 워치독에 체크인해야 한다. 태스크가 여러 개 존재할 경우 모든 태스크가 반드시 체크인 작업을 수행해야 한다. 하지만 그림 9를 보면 워치독이 상당수 태스크의 이상 상황을 감지하지 못했다.

와치독이 대다수 주요 태스크의 중단을 감지할 능력이 없었으며, CPU 부하를 적절하고 안정적으로 감지할 능력도 없었다. 부하로 인해 발생한 오동작이 1.5초 이상 지속되도록 허용했으며, 대다수 운영체제 시스템 오류 코드를 무시해 버렸다(이는 MISRA-C 규칙을 위반한다). 프리어스 2005년식 HV-ECU 워치독은 여러 태스크 중단을 눈치채지 못하는 문제점을 해결한 버전으로 알려져 있다. 하지만 캠리 2005년식 모델의 워치독은 그렇지 못했다.

4층

여기까지 오면 태스크 X의 중단 직후 3개 층이 모두 뚫리는 상황에 직면했다. 운전자의 의도를 모르는 상태에서 자동차의 급발진이 시작되었을 때 최후의 방어 층은 ESP-B2 모니터 CPU다. 모니터 CPU는 브레이크 반향(Brake Echo) 검사라는 기법을 사용하며, 운전자가 브레이크 페달을 밟고 있지만 스로틀이 열린 상태가 되면 ECM을 재시작 하도록 설계돼 있다. 하지만 메인 CPU를 재시작한다고 해서 눈에 띄게 속도가 줄어들지는 않는다(RPM이 조금 떨어질 뿐이다). 따라서 이런 동작 방식은 100% 안정성을 담보해주지 못하며, 경우에 따라 태스크 X와 같은 주요 태스크의 중단 상황에서 오히려 역효과를 불러일으킬 수도 있다.




마지막 방어선인 ESP-B2 소프트웨어는 메인 CPU 소프트웨어를 제작한 덴소에서 제작했지만, 토요타는 자체 검토를 수행하기는커녕 소스 코드조차 확보하지 못했다. NASA 역시 이 코드를 제공받지 못했기에 원인 분석 과정에서 모니터 CPU 동작을 검토하지 않았다. 하지만 바 그룹에서 검토한 결과 모니터 CPU의 성능 부족으로 인해 메인 CPU에서 일어나는 모든 오동작을 감지해내지 못하며, 그 결과 급발진에 효과적으로 대응하지 못했다는 사실이 밝혀졌다.

이렇게 안전 계층을 구성하는 마지막인 4층까지 뚫리고 나면 남는 것은 바로 운전자가 의도하지 않은 가속 상태인 ‘급발진’이다.

“위험한 선택”의 결론 

지금까지 설명한 소프트웨어의 버그와 안전 시스템 아키텍처 설계 결함이 토요타 캠리 모델에서 발생한 급발진 현상의 한 가지 원인이 됐다. 그렇다면 어떤 문제가 있었기에 이런 상황이 벌어졌는지 근본 원인을 파악할 필요가 있다. 토요타의 내부 문서와 소프트웨어 공학 프로세스를 검토하면 몇 가지 중요한 원인을 추론할 수 있다.
토요타의 소프트웨어 프로세스에는 다음과 같은 결함이 있었다.

▶ FMEA(Failure Mode and Effect Analysis)가 불완전했으며, 단일 실패 지점(Single Point of Failure)이 존재한다. 토요타가 공식적인 안전 관련 프로세스를 채택하지 않았기 때문이다.
▶ 운영체제 코드와 ESP-B2 코드에 대한 동료 간 검토가 없었다. 토요타는 동료 간 검토를 수행하지 않았으며, 비표준 OSEK을 사용했기 때문이다.
▶ 토요타의 독자적인 “파워트레인” 코드 표준도 지켜지지 않았다. 토요타가 소프트웨어 공급자에 의존했기 때문이다.

토요타는 소프트웨어의 안전을 담보하기 위한 표준 규약을 실천하지 못했다. 외부 업체에 지나치게 의존했으며 내부 전문가도 부족했다. 또한 소프트웨어 관리가 부족했고 소프트웨어 교육 역시 부족했다. 2007년 9월 26일 토요타 사내 편지 내용에 따르면, “안전 시스템과 같은 기술은 토요타 엔지니어링 부서의 DNA의 일부가 아니다”라는 문구가 나온다.

토요타 같은 글로벌 자동차 회사에서 이런 어처구니없는 실수를 저질렀다는 사실이 시사하는 바는 크다. 모든 자동차의 소프트웨어 비중이 커지고 있는 상황에서 현실안주는 너무나 위험하다. 결론적으로 현재뿐만 아니라 다가오는 미래를 위해서라도 소프트웨어 프로세스를 고도화하고 소프트웨어 아키텍처를 정교하게 수립하는 동시에 실제 프로그램 작성 과정에서도 필요한 절차와 규칙을 지키고, 동료 간 검토를 도입해 (특히) 안전과 관련해 잠재적인 문제점이 없는지 확실하게 짚고 넘어가는 문화가 정착돼야할 것이다.  AE

참고 문헌
* 위키피디아 UA 정의  http://en.wikipedia.org/wiki/Sudden_unintended_acceleration
* 토요타 ETCS-i 소개 자료
http://media.lexus.ca/internal_redirect/cms.ipressroom.com.s3.amazonaws.com/197/files/20144/Tab_9_-_Electronic_Throttle_Control_System_-_How_it_works.pdf
* 역사 속의 소프트웨어 오류
에이콘출판, 2014년 출간
* NHTSA의 UA 조사 자료
http://www.nhtsa.gov/UA
* BOOKOUT V. TOYOTA 분석 자료
Michael Barr
http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf
* BOOKOUT V. TOYOTA 소송 관련 eetimes 기사
http://www.eetimes.com/document.asp?doc_id=1319952
http://www.eetimes.com/document.asp?doc_id=1319966
http://www.eetimes.com/document.asp?doc_id=1319936
* embeddedgurus.com 기사
http://embeddedgurus.com/barr-code/2011/03/unintended-acceleration-and-other-embedded-software-bugs/
http://embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration/
* OSEK 설명
http://en.wikipedia.org/wiki/OSEK
* MISRA-C 설명
http://en.wikipedia.org/wiki/MISRA_C
* 정상 사고 설명
http://en.wikipedia.org/wiki/Normal_Accidents