http://www.asyura2.com/13/hasan83/msg/756.html
| Tweet |
2007年に米国オクラホマ州で、トヨタ自動車の乗用車「カムリ」が急加速したことによる死亡事故が発生した。事故をめぐる訴訟において、原告側証人として事故原因の調査を行った組み込みソフトウェアの専門家は、裁判で「カムリのエンジン制御モジュール（ECM）のファームウェアに重大な欠陥が見つかった」と報告した。
[Michael Dunn，EDN]
2013年10月24日、トヨタ自動車の乗用車の急加速による死亡事故をめぐる米国オクラホマ州での訴訟において、陪審団は同社に対し賠償を命じる評決を下した。なお、本訴訟は、10月25日に和解が成立している。
この事故は、2007年にオクラホマ州で、2005年モデルの「カムリ」が急加速し、運転者と同乗者の2名が死傷したというもの。運転者ら原告側は、運転者の意図しない急加速（UA：Unintended Acceleration）があったと主張し、訴訟では、エンジン制御モジュール（ECM）のファームウェアの欠陥をめぐる論争が繰り広げられた。
組み込みソフトウェアはかつて、C言語またはアセンブリ言語を組み合わせて動作させる低レベルのコードだった。しかし今日では、スロットルコントロールなどのように、重要性が高い割に比較的単純なタスクにおいて、最先端のリアルタイムOS（RTOS）や数万ものコードラインが使われる場合が多い。
高い性能が要求され、特に安全性が最重要視される場合、設計やコーディング、試験に関する評価・基準は最も重要な課題となる。欠陥が生じることは決して許されず、確実な安全性が求められる。
もし自動車メーカーが、このような評価基準を放棄して独自の基準を採用し、ソフトウェア（およびハードウェア）設計に不可欠とされる厳格な基準や成功事例、抑制と均衡などを無視するとしたら、一体どうなるだろうか。企業としての信用を失うばかりか、人命を奪ってしまうことにもなりかねない。ソフトウェア開発において、絶対にあってはならないことだ。
組み込み機器向けのコンサルティングを手掛けるBarr GroupのCTO（最高技術責任者）であり、共同創設者でもあるMichael Barr氏＊）は2013年10月、EDNの問い合わせに対し、今回の調査結果を明らかにした。Barr氏は同僚とともに、裁判の原告側の専門家証人として徹底的な調査を実施した結果を明らかにした。これは、セーフティクリティカルシステム開発に携わる全ての人々に対する教訓となるだろう。自動車業界や医療機器業界、航空宇宙業界などのいずれの分野においても、欠陥が生じることは決して許されない。
＊）Barr氏は、開発者やコンサルタントとしての優れた実績を誇る他、大学教授や編集者、ブロガー、著者として活躍した経歴も持つ。
Barr氏による最終的な調査結果は、以下の通りである。
・トヨタのETCS（電子制御スロットルシステム）のソースコード品質には不備がある
・トヨタのソースコードには欠陥があり、バグも含まれているため、UAを引き起こす可能性がある
・コード品質測定法に基づいた調査の結果、他にもバグが含まれている可能性が明らかになった
・問題となった自動車の安全装備には欠陥があり、品質に不備がある（「不安定なセーフティアーキテクチャ」であると説明）
Barr氏は、これらの結果を基に、「ETCSに欠陥があったことが原因となり、UAが発生した」という結論を出した。
ハードウェア
今回の調査は主にECMのソフトウェアを中心として行われたが、ハードウェアに関連する要因も1つ上げられる。トヨタは、2005年モデルの「カムリ」のメインCPUにはRAMのエラー検出・修正機構（EDAC）を搭載していると主張しているが、実際には搭載されていない、あるいは、低コストのパリティのみに頼っている可能性があるという。この他にも、スロットルに異常が生じる要因として、アクセルペダル位置センサーの内部にSn（スズ）ウィスカが発生するという問題がある。
ソフトウェア
今回の技術調査は、ECMソフトウェアに焦点を絞って行われた。まず、ミラーリングが常時実行されていなかったことが明らかになった。ミラーリングでは通常、重要なデータが冗長変数に書き込まれる。スタックオーバーフローが発生する可能性を考えると、非常に重大な問題だといえる。
トヨタは、割り当てられたスタック領域のうち41％しか使用していないと主張していたが、Barr氏の調査の結果、実際に使われているのは94％だったことが分かった。さらに、コードの内部において、MISRA-Cに違反する再帰が発見された。これは、スタックにとっては致命的な問題だ。またCPUには、スタックオーバーフローを防ぐためのメモリ保護機能も搭載されていないという。
さらに、RTOSのクリティカルな内部データ構造と、スロットル角度関数という2つの重要なアイテムに対して、ミラーリングが不完全だったことが明らかになった。
トヨタはこれまでにスタック分析を実施しているが、それについてBarr氏は、「完全な失敗だ」と結論付けている。同氏はその原因として、ポインターを介して実行された一部のコールや、ライブラリ/アセンブリ関数（合計で約350）を用いたスタック使用量などに関する分析を行っていない点や、タスクの切り替え時にRTOSを使用していなかった点などを指摘する。さらに、ランタイムスタックモニタリングを実行していないという点も挙げている。
トヨタのETCSは、自動車業界の標準規格であるRTOS APIのOSEKバージョンを採用している。しかし何らかの理由で、CPUベンダーから供給されたOSEKバージョンが、認証規格に適合していなかったことが分かった。
RTOSタスクが意図せずにシャットダウンしてしまうという現象に関しては、UAが発生する原因の1つである可能性が高いことから、重点的に調査が行われている。メモリの中のシングルビットによって各タスクが制御されるため、ハードウェアまたはソフトウェアの欠陥によってデータが破損された場合、必要なタスクが一時停止したり、不要なタスクが実行されてしまう可能性があるという。車両テストを行った結果、特定の1つのデッドタスクによってスロットルの制御機能が失われることから、UAが発生した場合には、ブレーキから完全に足を外さなければ加速を止められないことが明らかになった。
この他にもコードに関する欠陥としては、バッファオーバーフローや、キャスティングの安全性が不十分であること、タスク間で競合状態にあることなど、さまざまな欠陥が見つかっている。
数々の問題点が明らかに
カムリのETCSには、グローバル変数が1万1000もあることが判明した。Barr氏は、“スパゲティコード”と評している。ソフトウェアの評価法である「循環的複雑度（Cyclomatic complexity）」で複雑度を計測したところ、67個の関数が“テスト不能”だった（スコアが50を超えるとテスト不能と評価される）。スロットル角度関数にいたっては、スコアが100以上で“メンテナンス不能”と評価された。Barr氏は、「トヨタのプログラムは、自動車業界で広く採用されている『MISRA-C』への対応が不十分だ。準拠していない箇所が8万個も見つかった。トヨタの内部規格には、MISRA-C規格のうち11個のルールしか適用されていなかった。しかも、ETCSのコードは、そのうち5個に準拠していなかった」と述べている。MISRA-Cとは、欧州の自動車業界団体であるMISRA（Motor Industry Software Reliability Association）が策定したC言語のためのソフトウェア設計標準規格である。1998年に発行されたMISRA-Cの初版「MISRA-C:1998」には、93個の必要要件と34個の勧告要件があるが、トヨタはこのうちの6個にしか準拠していなかったのだ。
同氏は、「トヨタは、コードのピアレビューが不十分であるか、まったく行っていなかった可能性がある。バグ管理システムも存在しない」と指摘した。
NASA（米航空宇宙局）は、Barr Groupよりも前にトヨタ車の調査を行い、ETCSに実装された5つのフェイルセーフモードについて報告している。トヨタのフェイルセーフモードは、3つの「リンプホームモード（非常時の動作モード）」と、RPM（1分間当たりの回転数）制限、エンジンの停止で構成されている。だが、これらのフェイルセーフモードはすべて、同一タスクで処理されている。そのタスクが停止したり、故障したりした場合はどうなるのだろうか？
不完全なウォッチドッグ機能
多くの組み込みシステムは、ウォッチドッグタイマーを利用して誤動作したプロセッサの動作を制御している。セーフティクリティカルシステムでは、これは必須の機能である。ただし、システムが複雑になると、ウォッチドッグサブシステムはデータをミラーリングしなければならない。マルチタスクシステムでは、あらゆるアクティブタスクがウォッチドッグの監視下に置かれることが理想的である。トヨタのETCSでは、ウォッチドッグはTimer.Tick割り込みサービスルーチン（ISR）以上の役割を果たしていなかった。Timer.Tickイベントが遅れて、ISRがウォッチドッグのリセットに失敗すると、リセットされるまでの最大1.5秒間CPUがオーバーロードになり、ETCSの異常動作が続く恐れがある。ただし、タスクが誤動作してもほとんどの場合、コントローラをリセットしなくてもISRは適切に動作を続ける。
さらに、タスクの問題を示すリアルタイムOS（RTOS）のエラーコードのほとんどが無視されていることも判明した。これは、間違いなくMISRA-C規格に違反している。
監視用プロセッサを監視する機能がない
トヨタのETCSボードには2つのCPUが搭載されている。2つ目のCPUは、1つ目のCPU（メインCPU）を監視している。この監視用CPUはサードパーティ製で、トヨタの関知しないファームウェアを実行しており、メインCPUのコードに関する詳細な知識がないまま開発されたと思われる。この構成の利点は、監視的な役割を独立させていることである。監視用CPUは、アクセルペダルの位置情報をデジタル化するA-Dコンバータを搭載し、シリアルリンクを介してメインCPUと通信している。
安全システムを扱っている人なら誰でも、何としても単一障害点（SPOF：Single Point of Failure）を回避すべきだと認識しているだろう。だが今回のケースでは、2個のCPUに車両状態情報を供給するA-Dコンバータが、SPOFになっていた。
また、監視用CPUのフェイルセーフコードは、メインCPUのタスクが正常に機能していることを前提にしている。だが、メインCPUのタスクはクルーズコントロールから、アクセルペダルの位置をスロットル角度に変換するという重要な機能まで、非常に幅広いタスクまで担っていた。Barr氏は、ソースコード関連の機密に関わることから、陪審団に対してこのタスクを単に「タスクX」と説明している。タスクXは、もう1つのSPOFと見なされる可能性がある。
結論
ソフトウェアの欠陥が明らかになった今回の問題から、われわれは何を学べるだろうか。・全てはエンジニアリングの文化から始まる。品質を実現するには、適切な相互評価、文書化されたルールの実施、コード品質のツールや基準の使用などに取り組む文化が必要となる
・複雑なシステムでは、ハードウェアやソフトウェアによって引き起こされる可能性のある故障のシナリオを、全てテストするのは不可能だ。欠陥のないコードを作成するには、考えられるあらゆる最善策を施し、使えるツールは全て利用するくらいの心構えで設計しなくてはならない
・適切なところにはモデルベース設計を用いる
・異なるエンジニアリングチームで、徹底的にシステムをテストする必要がある。自分で設計したものを、自らテストするという間違いを犯してはならない（トヨタがどのようにテストを行ったのかは、特に説明されていない）。
・基本となるハードウェアは、ファームウェアと連携して信頼性を実現する必要がある。例えば、SPOFは回避しなければならない。タスクを完全に分離し、保護するために、ロックステップCPU、EDACメモリ、適切なウォッチドッグ、MMU（メモリ管理ユニット）といった技術で、信頼性を向上しなければならない。さらに、故障モードを決定し、設計の改善に結び付けるために、FMEA（Failure Mode Effect Analysis：故障モード影響解析）を徹底的に実施する必要がある。
安全性が最重視されるデバイスの開発に携わっている人は、トヨタの設計工程やBarr氏の調査結果についてどう思うだろうか。自分が行ってきた、あるいは行っている設計工程で、本当に安全性が実現できるのかをもう一度考えてみてほしい。
【翻訳：青山麻由子、滝本麻貴、田中留美、編集：EE Times Japan】
http://eetimes.jp/ee/articles/1311/11/news072.html
---
開いた口がふさがらないとはこのことだ。誰もメンテナンスできないソフトウェアほど危険なものはない。しかし、それでもトヨタのソフトウェア技術者たちは「メンテナンス可能」だと言い張るだろう。
スパムメールの中から見つけ出すためにメールのタイトルには必ず「阿修羅さんへ」と記述してください。すべてのページの引用、転載、リンクを許可します。確認メールは不要です。引用元リンクを表示してください。
