• 車種別
  • パーツ
  • 整備手帳
  • ブログ
  • みんカラ+
イイね!
2013年11月01日

ついに見つかったトヨタ暴走の本丸欠陥〜キラーファームウェアー〜

私の知る限り例のトヨタ車暴走の原因は・・・
「ガスペダル」
形状、長さ が不正であるためフロアやマットと干渉する。
フリクションレバーの設計不良で戻らない、或は戻りにくい。
という政府見解で決着がついた項目。

そして、NASAが政府安全宣言後に出した スズのウィスカ欠陥。
(学会で発表、政府筋会見では未発表という不思議な欠陥。)

そしてついに、本丸であるソフトウェアのプログラミング欠陥が見つかりました。

全文引用

Toyota's killer firmware: Bad design and its consequences
Michael Dunn - October 28, 2013

On Thursday October 24, 2013, an Oklahoma court ruled against Toyota in a case of unintended acceleration that lead to the death of one the occupants. Central to the trial was the Engine Control Module's (ECM) firmware.
Embedded software used to be low-level code we'd bang together using C or assembler. These days, even a relatively straightforward, albeit critical, task like throttle control is likely to use a sophisticated RTOS and tens of thousands of lines of code.
With all this sophistication, standards and practices for design, coding, and testing become paramount – especially when the function involved is safety-critical. Failure is not an option. It is something to be contained and benign.
So what happens when an automaker decides to wing it and play by their own rules? To disregard the rigorous standards, best practices, and checks and balances required of such software (and hardware) design? People are killed, reputations ruined, and billions of dollars are paid out. That's what happens. Here's the story of some software that arguably never should have been.
For the bulk of this research, EDN consulted Michael Barr, CTO and co-founder of Barr Group, an embedded systems consulting firm, last week. As a primary expert witness for the plaintiffs, the in-depth analysis conducted by Barr and his colleagues illuminates a shameful example of software design and development, and provides a cautionary tale to all involved in safety-critical development, whether that be for automotive, medical, aerospace, or anywhere else where failure is not tolerable. Barr is an experienced developer, consultant, former professor, editor, blogger, and author.
Barr's ultimate conclusions were that:
Toyota’s electronic throttle control system (ETCS) source code is of unreasonable quality.
Toyota’s source code is defective and contains bugs, including bugs that can cause unintended acceleration (UA).
Code-quality metrics predict presence of additional bugs.
Toyota’s fail safes are defective and inadequate (referring to them as a “house of cards” safety architecture).
Misbehaviors of Toyota’s ETCS are a cause of UA.

A damning summary to say the least. Let's look at what lead him to these conclusions:

Hardware
Although the investigation focused almost entirely on software, there is at least one HW factor: Toyota claimed the 2005 Camry's main CPU had error detecting and correcting (EDAC) RAM. It didn't. EDAC, or at least parity RAM, is relatively easy and low-cost insurance for safety-critical systems.
Other cases of throttle malfunction have been linked to tin whiskers in the accelerator pedal sensor. This does not seem to have been the case here.


The Camry ECM board. U2 is a NEC (now Renesas) V850 microcontroller.
Software
The ECM software formed the core of the technical investigation. What follows is a list of the key findings.
Mirroring (where key data is written to redundant variables) was not always done. This gains extra significance in light of …
Stack overflow. Toyota claimed only 41% of the allocated stack space was being used. Barr's investigation showed that 94% was closer to the truth. On top of that, stack-killing, MISRA-C rule-violating recursion was found in the code, and the CPU doesn't incorporate memory protection to guard against stack overflow.
Two key items were not mirrored: The RTOS' critical internal data structures; and—the most important bytes of all, the final result of all this firmware—the TargetThrottleAngle global variable.
Although Toyota had performed a stack analysis, Barr concluded the automaker had completely botched it. Toyota missed some of the calls made via pointer, missed stack usage by library and assembly functions (about 350 in total), and missed RTOS use during task switching. They also failed to perform run-time stack monitoring.
Toyota's ETCS used a version of OSEK, which is an automotive standard RTOS API. For some reason, though, the CPU vendor-supplied version was not certified compliant.
Unintentional RTOS task shutdown was heavily investigated as a potential source of the UA. As single bits in memory control each task, corruption due to HW or SW faults will suspend needed tasks or start unwanted ones. Vehicle tests confirmed that one particular dead task would result in loss of throttle control, and that the driver might have to fully remove their foot from the brake during an unintended acceleration event before being able to end the unwanted acceleration.
A litany of other faults were found in the code, including buffer overflow, unsafe casting, and race conditions between tasks.


一部抜粋

トヨタの電子スロットル制御システム( ETCS )ソースコードは不当な品質である。
トヨタのソースコードに欠陥があると(UA )意図しない加速を引き起こす可能性がありますバグを含むバグが含まれています。
コード品質のメトリックは、追加のバグの存在を予測する。

何でこれらの結論に彼を導くのは、見てみましょう:


ハードウェア
調査は、ソフトウェアにほぼ完全に焦点を当てていますが、少なくとも一つのHW要因があります:トヨタは、2005年カムリのメインCPUはエラーがRAMを検出して( EDAC )を補正していたと主張した。それはしませんでした。 EDAC 、または少なくともパリティRAMが、比較的簡単かつ低コストの保険セーフティクリティカルなシステムのためである。
スロットル誤動作の他の場合は、アクセルペダルセンサにスズウィスカにリンクされている。ここにケースをされているように見えません。


カムリECMボード。 U2は、NEC (現在はルネサス) V850マイクロコントローラです。
ソフトウェア
ECMソフトウェアは、技術的な調査のコアを形成した。以下は、主な調査結果のリストです。
ミラーリングは、 (キー、データが冗長変数に書き込まれている)は、常に行われていませんでした。に照らして、この利益余分意義...
スタックオーバーフロー。トヨタは、割り当てられたスタック領域のわずか41%が使用されていたと主張した。バールの調査は94%が真実に近いことを示した。その上で、スタック殺害、 MISRA -Cのルール違反再帰はコード内に発見され、 CPUはスタックオーバーフローを防ぐためのメモリ保護を内蔵していません。
2つの主要な項目はミラーリングされませんでした

トヨタはスタック分析を行ったが、彼はそれを完全にしくじったと結論付けた。トヨタはポインタを介して行われたコールの一部、ライブラリ、アセンブリ関数によって逃したスタック使用量(合計で約350 )逃しタスク切り替え時に使用RTOSを逃した。彼らはまた、ランタイムスタックの監視を実行できませんでした。
トヨタのETCSは、自動車の標準RTOS APIですOSEKのバージョンを使用していました。しかし、いくつかの理由について CPUベンダーが提供するバージョンは、適合認定されませんでした。
意図しないRTOSタスクのシャットダウンは重くUAの潜在的な供給源として検討した。メモリ内の単一のビットはHWやSWの故障が原因で、各タスク、腐敗制御するように必要なタスクを中断するか、不要なものを起動します。車両テストは、ある特定のデッドタスクがスロットル制御の喪失につながることを確認し、ドライバが完全に不要な加速を終了できるようになる前に、意図しない加速のイベント中にブレーキから自分の足を除去する必要がある場合がある。
その他の障害の連祷は、バッファオーバーフロー、危険なキャスティング、およびタスク間の競合状態を含め発見された。
ブログ一覧 | 製品欠陥 | クルマ
Posted at 2013/11/01 23:01:08

イイね!0件



今、あなたにおすすめ

ブログ人気記事

「カーくる新舞子サンデー」って言う ...
P.N.「32乗り」さん

愛車と出会って3年!
KimuKouさん

ほとんどの事故やケガは、油断、過信 ...
ウッドミッツさん

左後方のオートバイ接触予防で、広角 ...
トホホのおじさん

GW~北海道食い倒れデスマーチ20 ...
ELMO246さん

祝・みんカラ歴15年!
ケロはちさん

この記事へのコメント

2013年11月4日 17:37
ハードもソフトにも問題があったってことですね^^;
散々ドライバーの責任にしておいてコノ始末。。。。

阪急阪神ホテルズみたく、言い訳のオンパレードを早く見たいですな。
コメントへの返答
2013年11月5日 13:32
もっと言い訳して、もっと墓穴掘れば面白い。

この件も、例の安全宣言以後に本丸の欠陥がひっそり発見発表され海外メディアでさえ大きく取り上げてないのが如何に問題が根深いか解りました。

切るだのアッシーごと交換だの表面上やってましたが、コッソリプログラムインストールしてたってのもあり、必ずソフト、ハードの問題有ると見てましたからスッキリしました。

やはり某国と違って、科学の聖域があちらにはあるようです。



プロフィール

「中央省庁の統計偽装と隠蔽は日本のスタンダード http://cvw.jp/b/985301/42447130/
何シテル?   01/28 21:29
Hang off+です。 トヨタの本性を暴き トヨタに関する悪辣極まりない所業を暴露しております。 当ブログを通してトヨタの様々な行為を知っていただき、世間...
みんカラ新規会員登録

ユーザー内検索

<< 2024/5 >>

   1234
567891011
12131415161718
19202122232425
262728293031 

リンク・クリップ

過去のブログ

2019年
01月02月03月04月05月06月
07月08月09月10月11月12月
2018年
01月02月03月04月05月06月
07月08月09月10月11月12月
2017年
01月02月03月04月05月06月
07月08月09月10月11月12月
2014年
01月02月03月04月05月06月
07月08月09月10月11月12月
2013年
01月02月03月04月05月06月
07月08月09月10月11月12月
2012年
01月02月03月04月05月06月
07月08月09月10月11月12月
2011年
01月02月03月04月05月06月
07月08月09月10月11月12月
ヘルプ利用規約サイトマップ

あなたの愛車、今いくら?

複数社の査定額を比較して愛車の最高額を調べよう!

あなたの愛車、今いくら?
メーカー
モデル
年式
走行距離(km)
© LY Corporation