アカウント名:
パスワード:
この人って業界的には有名人なんですか？個人的には、トヨタならあってもおかしくないけど、ちょっと眉唾かなぁと思うんですが･･
ストーリーでは300万ドルの賠償判決に触れていますが、これが突然の和解になったようで： 訂正：トヨタ、米オクラホマ州の急加速めぐる訴訟で和解 [reuters.com]
陪審はこの日、トヨタに対し懲罰的損害賠償を要求するか審議する予定だったが、陪審が評決を下す前にトヨタと原告側弁護士は、和解が成立した（訂正）ことを明らかにした。和解の内容は非公開となっている。
これまで勝訴を続けてきたトヨタが、あわてて和解に持ち込むような瑕疵が見つかったんかなぁ、と思っちゃいます。
EDNの記事は「ソースコードにMISRA-C [wikipedia.org]違反箇所がたんまりある」とか「グローバル変数が11000もあってスパゲッティだ」とか、うーんそれは本質的な問題なの？と素人的には思う点もあるんですが、「メモリがエラー訂正無しだった」とか「スタックオーバーフローなりでタスクが落ちたとき急加速が誘発されて、足を完全にブレーキから外さないと回復しないのが実車テストで確認された(Vehicle tests confirmed that..)」とかは言い訳できない印象です。
「スタックオーバーフローでタスクが落ちる」というのが運転操作で可能なのかが、気になる。
1週間エンジン切らないとかでしょうか。
>1週間エンジン切らないとかでしょうか。
アメリカではありそうだから困る。
Toyota claimed only 41% of the allocated stack space was being used. Barr's investigation showed that 94% was closer to the truth.
トヨタが41%しか使ってないつもりのスタック割り当て領域が実際には94%とか使われていたようで エンジンつけてたのは3日間くらいじゃない？（違 ＃ スタック解放にバグがある上にメモリが保護されてないとか色々書いてあります ＃ 「本当は怖いトヨタ車の世界」ぎみだけど本当だろうか
3日間連続で車を動かすのは無理じゃないですかね。アイドリング1分で約20ccの消費と考えた場合ですが。給油時にはエンジン切りますし。
HEVだと燃費がいいので稼働時間が伸びてファームウェアがスタック食いつぶして暴走というのはあるかもな。
もうこうなると事故の原因究明じゃなくて、バグを必死に見つけてるだけだよね。
> それは本質的な問題なの？
ソフトウェア内部品質的な問題を抱えているシステムと判断しますね。和解の決定的理由は実車テストで確認された瑕疵でしょうが。
リンクを張ってあるMISRA-CのWikipediaのページ、その最初の部分に書いてある事をもう一度読んでみましょう。違反箇所がたんまりあると言う事は、MISRA-Cの目的なんざ知ったこっちゃないね、と言っている様なもの。
グローバル変数が11000という事は、まあ、モジュール間I/Fが11000あるという事で、自由奔放なI/F設計がどの様な影響を与えるかはまず把握する事は難しいでしょう。テストカバレッジを
MISRA-Cって信頼性の証明を文書に残しておけば逸脱許されるんじゃなかったっけ。コードから違反箇所が見つかっただけだとすると、逸脱文書の有無によって話が変わってくるような。
複雑なシステムでリソース制約もあるから仕方ないのかも知れないが。ダイナミックにオブジェクトが生成/消滅する組み込みシステムって怖い。タスク...変数...エントリ...キュー..なにより競合条件をテストするのが不可能に近いのではないだろうか。ええ、いろいろ組み込みシステムやってるけどチキンなので全部スタティックです。OS使ったことないです。#ソースが無いモジュールなぞ怖くて使えるか#最近のECUってuTRONとか使ってるのかしらん
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
ちょっとよく分からないんですが (スコア:0)
この人って業界的には有名人なんですか？
個人的には、トヨタならあってもおかしくないけど、
ちょっと眉唾かなぁと思うんですが･･
Re:ちょっとよく分からないんですが (スコア:2, 参考になる)
ストーリーでは300万ドルの賠償判決に触れていますが、これが突然の和解になったようで：
訂正：トヨタ、米オクラホマ州の急加速めぐる訴訟で和解 [reuters.com]
これまで勝訴を続けてきたトヨタが、あわてて和解に持ち込むような瑕疵が見つかったんかなぁ、と思っちゃいます。
EDNの記事は「ソースコードにMISRA-C [wikipedia.org]違反箇所がたんまりある」とか「グローバル変数が11000もあってスパゲッティだ」とか、うーんそれは本質的な問題なの？と素人的には思う点もあるんですが、「メモリがエラー訂正無しだった」とか「スタックオーバーフローなりでタスクが落ちたとき急加速が誘発されて、足を完全にブレーキから外さないと回復しないのが実車テストで確認された(Vehicle tests confirmed that..)」とかは言い訳できない印象です。
Re: (スコア:0)
「スタックオーバーフローでタスクが落ちる」というのが
運転操作で可能なのかが、気になる。
1週間エンジン切らないとかでしょうか。
Re: (スコア:0)
>1週間エンジン切らないとかでしょうか。
アメリカではありそうだから困る。
Re: (スコア:0)
トヨタが41%しか使ってないつもりのスタック割り当て領域が実際には94%とか使われていたようで
エンジンつけてたのは3日間くらいじゃない？（違
＃ スタック解放にバグがある上にメモリが保護されてないとか色々書いてあります
＃ 「本当は怖いトヨタ車の世界」ぎみだけど本当だろうか
Re: (スコア:0)
3日間連続で車を動かすのは無理じゃないですかね。
アイドリング1分で約20ccの消費と考えた場合ですが。
給油時にはエンジン切りますし。
Re: (スコア:0)
HEVだと燃費がいいので稼働時間が伸びて
ファームウェアがスタック食いつぶして暴走
というのはあるかもな。
Re: (スコア:0)
もうこうなると事故の原因究明じゃなくて、バグを必死に
見つけてるだけだよね。
Re: (スコア:0)
> それは本質的な問題なの？
ソフトウェア内部品質的な問題を抱えているシステムと判断しますね。和解の決定的理由は実車テストで確認された瑕疵でしょうが。
リンクを張ってあるMISRA-CのWikipediaのページ、その最初の部分に書いてある事をもう一度読んでみましょう。違反箇所がたんまりあると言う事は、MISRA-Cの目的なんざ知ったこっちゃないね、と言っている様なもの。
グローバル変数が11000という事は、まあ、モジュール間I/Fが11000あるという事で、自由奔放なI/F設計がどの様な影響を与えるかはまず把握する事は難しいでしょう。テストカバレッジを
Re: (スコア:0)
MISRA-Cって信頼性の証明を文書に残しておけば逸脱許されるんじゃなかったっけ。
コードから違反箇所が見つかっただけだとすると、逸脱文書の有無によって話が変わってくるような。
Re: (スコア:0)
複雑なシステムでリソース制約もあるから仕方ないのかも知れないが。
ダイナミックにオブジェクトが生成/消滅する組み込みシステムって怖い。
タスク...変数...エントリ...キュー..
なにより競合条件をテストするのが不可能に近いのではないだろうか。
ええ、いろいろ組み込みシステムやってるけど
チキンなので全部スタティックです。
OS使ったことないです。
#ソースが無いモジュールなぞ怖くて使えるか
#最近のECUってuTRONとか使ってるのかしらん