토요타 unintended acceleration 사례 연구


아직도 paper가 나오는 것을 보니 토요타 UA(unintended acceleration) 사건은 끝나지 않았나보다. 원문: embedded software under the courtroom microscope

background:

task x가 죽어서 다음의 effect가 연속적으로 일어났다고 판단하고 있음

  1. vacuum loss 발생
  2. throttle control loss유발
  3. 차량 정지 불가

 

task x는 주기적인 task이고 throttle angle setting을 보정하는 것을 결정하는 task임.  여기에 사용된 os는 multi tasking os임. 그런데, 이 embedded system은 monitoring concept을 가지고 있기 때문에 별도의 system에서 monitoring을 하고 계산값의 정확성을 검산하는 구조였음.

그러므로 software bug가 SEU(single event upset)에 의해 문제가 발생시 다른 쪽(secondary CPU)에서 발견할 수 밖에 없는 구조임.

 

task x의 death와 관련된 이론

a. task x의 birth/death를 관리하는 bit가 flip이 발생하여 task가 죽음

b. bit flip 발생 시점에서 task x는 throttle value값이 매우 큰 값이었음. 그래서 task가 죽어서 그 값이 계속 큰 상태로 유지됨

c. brake echo check가(secondary CPU) 브레이크를 밟았을 때, 어떤 이유인지 동작하지 못하고 점검을 실패함. 그래서 풀가속 상태가 됨.

 

  • 위의 이론에서 a는 어디까지나 가설에 의한 것임
  • a가 사실이라고 할 때, b는 상황에 맞지 않는 situation임. 램프를 통과하기 위해 감속을 하고 있는 상황이었으니까. 혹시 initial-D의 타쿠미처럼 드리프트를 하기 위해서 ???
  • c도 역시 가설적임. secondary cpu는 항상 동작중이었다는 것이 밝혀졌음.

 

Lesson

개인적인 생각으로, 정확하게 동작한다는 것을 입증하기 위한 증거 사례들을 소프트웨어 내부에 기록을 하는 기능이 있다면, 나중에 사고가 났을 때 보다 정확한 판단을 할 수 있지 않을까 한다. 정확한 사고 매커니즘이 규명이 되지 않은 상태이기 때문에 그런 사고가 발생할 수 있는 가능성이 있다. (물론 기술력있는 업체에서는 이것을 빌미로 brand-new 제품으로 급발진 안일어나는 제품을 비싸게 팔 수 도 있을 것이라고 생각을 함. 이미 그러고 있는 거 아닌가?)

스스로 정확하게 동작함을 입증할 수 있는 기능. 그렇다면 나중에 사고가 나도 당당할 수 있지 않겠는가?

쫄리면 뒈지시던가에 대한 이미지 검색결과

근데 아마 현실적으로는 100% 확신할 수 없고 후달려서 그런 것일거라고 생각이 되기는 한다. 그래도 보다 적극적인 자세가 필요하지 않을까?

관련 이미지

 

 

 

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중