トヨタの急加速事故は欠陥だらけのファームウェアが原因？――原告側調査の詳細：ビジネスニュース 企業動向（3/3 ページ）

[Michael Dunn，EDN]

不完全なウォッチドッグ機能

　多くの組み込みシステムは、ウォッチドッグタイマーを利用して誤動作したプロセッサの動作を制御している。セーフティクリティカルシステムでは、これは必須の機能である。ただし、システムが複雑になると、ウォッチドッグサブシステムはデータをミラーリングしなければならない。

　マルチタスクシステムでは、あらゆるアクティブタスクがウォッチドッグの監視下に置かれることが理想的である。トヨタの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】

原文へのリンク