組み込みソフトウェアの品質、または混乱は 2012 年にトヨタ カムリで発生しました

すぐに警告します。神経質でない場合は、このテキストを読まないでください。まるでスティーブン・キングの物語のようです。それは恐ろしいことになるだろう - そしてかなり.

6年以上続いた警告的で非常に悲しい話が、ついに論理的な結論に達しました.そこから重要なことを学ぶことができますが、個人的には以前のブログ投稿の続きをここに書く機会があります。 があるからです。

物語は 6 年前、オクラホマ州の 2 人の年配の女性がトヨタ カムリのどこかで運転していたときに始まりましたが、彼らの旅は悲劇的に終わりました。そのうちの 1 人 (同乗者) が衝突で死亡し、もう 1 人が重傷を負いました。

彼らの由緒ある年齢が事件を複雑にし、弁護士は何年にもわたって裁判を引き延ばし、車の奇妙な行動をドライバーのミスのせいにすることができました(しかし、それは彼女にとって不運だった.カムリは軽くて速い車とはかけ離れており、柔らかいソファ付きの戦車を所有し、何らかの理由でこれらの戦車をほとんど「スポーツカー」として扱うロシアのドライバーがごく普通の速度であるとは言えません)。

車の挙動の奇妙な点は、ドライバーが止めようとしたにもかかわらず、予期せず加速し始めたことです。

トヨタの弁護士の最初の反応は明白でした。

しかし、後で不快なことが起こりました。頑固なカムリが意図せず制御不能な加速をする傾向を示した場合、多くのケースが発生しました。何百もの新しい訴訟が続いた。ドライバーを非難することは今や不可能であり、トヨタは非難した... サイズが正しくなく、十分に柔軟でないネイティブのフロア マットがアクセル ペダルを引っ掛け、意図しない加速を引き起こした.

2012 年、トヨタは数百件の訴訟を解決するために総額 10 億ドル以上を支払ったが、いくつかの州でいくつかの事件が未解決のまま残されている。彼女の 2006 カムリは、予期せぬ制御不能な加速によって引き起こされたクラッシュで死亡しました。

NASA のスペシャリストは、カムリの奇妙な動作を調査することに惹かれ、加速制御サブシステムで考えられるすべての問題を調査するのに 10 か月かかりました。彼らの要約は、非常にあいまいな結論を暗示していました (NASA チームのレポートを含むこの大きな PDF ファイルを参照してください):

NESC (NASA エンジニアリングおよびセーフティ センター) の研究チームは、ETSC-i スロットル バルブ コントローラーで、診断コードを生成せずに車両の予期しない加速を引き起こす可能性のある 2 つの障害シナリオ (機械に関係なく…) を発見しました。アクセルペダル位置検出システムの特定のエラー。 2つ目は、車の診断システムでは検出できなかった加速コントローラープロセッサーの通常のソフトウェアエラーです。 2 番目のシナリオは、燃料噴射システムと点火システムがまだ作動している間に、スロットル バルブが意図せずに開くことを意味します。チームは、これらの失敗が実際に事故を引き起こしたという直接的な証拠を見つけられませんでしたが、それでも、それが不可能だったことを意味するわけではありません.

10 月 24 日、オクラホマ州の陪審は、6 年前に起こった自動車事故の責任をトヨタに負わせ、会社に 150 万ドルの違約金を課した。

トライアルが終了した後、組込みソフトウェア プログラマーのコミュニティは、不運なスロットル バルブ コントローラーのファームウェアの専門知識に関連するデータを公開する機会を得ました。

これらのデータは決して慰めにはなりませんでした.

専門家チーム (ウェブサイト「EmbeddedGurus」でそれらについて読むことができます) は、スロットル バルブ コントローラーのファームウェアをチェックし、(文字通り)「ソフトウェアの設計と開発の恥ずべき例」を発見しました。

彼らの結論では、コードの全体的な品質が低く、意図しない車の加速を引き起こす可能性のある多くのバグが指摘されました。コード実行制御および保護システムの一般的なアーキテクチャは、「トランプの家」の原則に基づいて構築されており、最終的に陪審員を納得させる評決が下されました。ファームウェアのソフトウェアの欠陥が自動車事故の原因であり、深刻な結果をもたらしました。

コントローラの調査中、専門家は、NEC (ルネサス) V850 マイクロコントローラのハードウェア障害が原因であると主張するトヨタの多くの推測を確認し、否定しました。 .ルネサス (以前は NEC として知られていました) のコントローラーは、自動車産業 (および他の産業も) の一種のリファレンス モデルであり、多種多様な自動車モデルで使用されているため、そうではないことは調査しなくても明らかです。このような深刻な欠陥 (明らかにメモリの破損を引き起こす) について世界はずっと前に知っていたはずであり、ハードウェア レベルで修正されるか、少なくとも製造元によって正誤表 (検出された欠陥のリスト) で言及されていたはずです。

以下は、すべての混乱の原因となっているプロセッサの写真です。これは非常に一般的な小型組み込みコンピューターであり、ロケット科学はまったくありません。自動車業界で一般的なコンポーネントを備えた単なるソリッド ボードです (最大のチップはまさに NEC-Renesas V850 マイクロコントローラーです):

スロットルバルブコントローラーは、危険な欠陥が発生する可能性が最も高い要素ではありません。少なくともそうであってはなりません。ペダルの位置を読み取るだけです (または、CAN や FlexRay などのオンボード ネットワークを介して他のコントローラーから値を受信します。これは、CAN を介したより複雑な上部構造です)。データ自体を読み取る場合は、他のコントローラー用の CAN データグラムを生成し、スロットルのステッピング モーター用の制御信号を形成します。また、当然のことながら、クルーズ コントロール システム (車両の速度を一定に保つシステム) に組み込まれています。それで全部です。上記のことは、昨年トヨタ自身が発表したこの件に関する巨大な文書によって確認されています (ハードコアな詳細のファンのみを対象とした大きな PDF ファイル。同社が昨年に固執していた説明のために興味深いものです)。 /P>

専門家の要約によると、このタスクの処理を担当し、リアルタイム オペレーティング システムの上部構造として実装されたファームウェアには、次のものが含まれていました… 11,000 のグローバル変数 .ファームウェア実装のコードは、すべてのプログラマーによく知られている名前「スパゲッティ」と呼ばれています。 」。プログラムの循環的複雑度の分析により、 が報告されました 、一方、スロットルバルブの角度を読み取るキー関数は、絶対に信じられないほどの値を示しました。これにより、このプログラムをテストするだけでなく、維持することさえ不可能になります.ソフトウェアが業界コーディング標準 (自動車業界には MISRA と呼ばれる一連の標準があります) にどの程度準拠しているかは、標準違反の数によって決まります。私たちの話では 80,000 これらのうち (ちなみに、トヨタは MISRA から 11 のルールのみを採用する独自の内部標準を持っていますが、コードが書かれた時点で必要な最小数は 93 です)。さらに、調査の結果、この複雑なシステムには障害やエラーを監視するメカニズムがないことが明らかになりました。このような良好な状態に加えて、コントローラのファームウェアには、単一のプロセスによって実装されたセキュリティ メンテナンスを担当するすべての機能がありました。議論すべきもう1つのことは、ウォッチドッグです。これはデスクトップ システムでは珍しいコンポーネントですが、組み込みシステムの世界では重要な機能です。ウォッチドッグ (ウォッチドッグ タイマー) は、プロセッサの外部にあるデバイスであり (同じチップに実装されている場合もあります)、その動作原理は非常に単純です。以前に特定の時間に設定されたタイマーをリセットしていないプロセスがある場合、タイマーは、ハードウェア割り込みを発生させてプロセッサに障害を報告するか、即時のシステム リセットを開始します。専門家は、そのファームウェアのウォッチドッグ タイマーがほとんど役に立たないことを発見しました。それが制御していたのは、ウォッチドッグ タイマーのまれな割り込みを処理する 1 つのプロセスだけだったためです。プロセッサがウォッチドッグによってリセットされるまでの約 1 秒半。ただし、専門家は、その間隔の後にリセットが発生するかどうかさえ確信が持てませんでした。まったく発生しなかった可能性があります.もう 1 つの優れた点:エラー メッセージを生成することを目的としたほとんどの RTOS 呼び出しのリターン コードが、ファームウェアで完全に無視されていました。

それでは、アーキテクチャ関連のさまざまなトラブルについて説明しましょう。メインプロセッサ(トヨタが最初にすべてを不当に非難したNEC-Renesas V850)は、サードパーティメーカーによるファームウェアを備えた追加のマイクロコントローラによって監視されていますが、これはトヨタの責任を超えています。独立した監視システムがあるのはもちろん素晴らしいことですが、アクセル ペダル位置のアナログ信号を読み取る唯一のアナログ - デジタル コンバーターが冗長ではなく、それに統合されているように見えるのはどうしてですか?追加のマイクロコントローラ?それが誰にどのように起こるか想像さえできません。このクラスのコンバーターは、非常に正確である必要はありません (結局のところ、アクセルペダルをどれだけ正確に踏むことができますか?)。かなり安価で定評があります。しかし、製造業者は依然として節約することを決定したため、非常に危険な単一障害点が作成されました。このようなスマートなソリューションは、コード レベルで適切にサポートされていました。監視コプロセッサのフェイルセーフ コードは、メイン マイクロコントローラによって実行される関数に依存していることが判明しました。関数の名前は、商業上の機密性のために隠されていました。ちなみに、エンジニアはこの機能で、ペダル角度からスロットルバルブ角度への変換から、クルーズ コントロール モードでの車両制御、さらには診断まで、多種多様なタスクを処理できるようにしました。

率直に申し上げて、元の論文を読んでいて、ファームウェアで使用されている 11,000 個のグローバル変数に関する段落を読んだとき、私は少し興奮しました。リアルタイム システムのすべてのプロセスで共有される 1 つの間違った状態は、それ自体が大きな問題です。このことを念頭に置いて、前回書いたことを思い出していただきたいと思います。

間違いなく、トヨタのために奇妙なコードを書き、そのような風変わりなプロセッサ アーキテクチャを設計したのは、学生でも新入社員でもありませんでした。もちろん、神に感謝しますが、これらのトラブルはごくわずかな車種で発生し、すべての障害が発見されました。トヨタは、これらすべての悪夢を受けて、今後ファームウェアの開発とテストを真剣に改善する必要があります (会社には特別なスタッフがいます)。仕事は評判を管理することです – まあ、トヨタでこの仕事をしている人々をうらやましいとは思いません.

しかし、あらゆる方向に急速に拡大している IoT (モノのインターネット) に照らして、この特定の例を忘れてはなりません。メーカーがそれを無視しないことを願っています。結局、スキャンダルが全世界を騒がせたので、彼らはできません.

敬具

アンドレイ・ズビンスキー

この記事はもともと公開されたものです ウェブサイト「Kompyuternoe Obozrenie」で;編集者の許可を得てコピーおよび翻訳されています。 Kompyuternoe Obozrenie