最近、同じ内容のサイト（英語サイト）を貼って記事を書いたが、この一連の暴走欠陥の結末は非常に重大であるので再度 他社が書いた日本語サイトを紹介しておく。
下記はeetimesサイトの記事。eetimesは電子技術専門に扱うサイト。
トヨタの急加速事故は欠陥だらけのファームウェアが原因？――原告側調査の詳細
以下、抜粋
■ハードウェア
今回の調査は主に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：故障モード影響解析）を徹底的に実施する必要がある。
以上三ページに渡って書かれたプログラム欠陥もスズウィスカ欠陥も世間に公開しているのは、学会や専門サイトのみである。
トヨタは長期にわたり、数々の欠陥を安全局職員の天下り等で隠蔽し続けてきた。
多額のリコール費用を浮かせられたと本社への連絡メールも見つかり、トヨタは終わりと誰もが思ったはず・・・
しかしながら、暴走騒ぎの真っ最中にテスラとの提携やヌーミー再開、そしてスレーターの国際天下りという手法でコレらの問題を無かった事にしてしまった。
上記欠陥が法廷で明らかにされた後日すぐにトヨタは即座に和解に応じた。すなわち反論の余地が無い。
という事を認めたという事だ。
こんな事をやり続けているトヨタが公道でオートパイロットのテストをしてまた騒ぎになった。
こっそりと電子空間の片隅で発表されるトヨタ欠陥の真実。世間ではトヨタ安全神話は今でも健在。
事故が起きても、ユーザーの責任 或は事故データの捏造というとんでもない方法で隠蔽し続けて来たのも発覚している。
このような状況は、ずっと続いているのだが自民党復権とトヨタ過去最高利益というデジャブのような事が今現在おきている。
Posted at 2013/11/24 00:23:02 | |
トラックバック(0) |
製品欠陥 | クルマ
