トヨタ車リコール問題、米交通安全局には調査に十分な専門スタッフが足りない？ 68
ストーリー by hylom
あるAnonymous Coward 曰く、
国家道路交通安全局（NHTSA：National Highway Traffic Safety Administration）の関係者によると、NHTSAにはトヨタ車リコール問題を調査するに必要な電気技師やソフトウエアエンジニアがいないそうだ（The Car Connection、本家記事）
昨今の高級車には70～100個ものマイクロプロセッサが搭載されており、ソフトウエアのコードは1億行近くにも上ると言われている。今後数年でコードは2～3億行へと膨れ上がるであろうと著名な市場調査・コンサルティング企業フロスト&サリバン社のコンサルタントは予測する。今回のリコール問題では消費者から「急激な加速」の報告があがっており、機械ではなく電気信号によってアクセル－スロットル制御を行う「drive-by-wire」システムのソフトウエア調査が一つの大きな焦点となると考えられている。しかしNHTSAには契約や外部委託などを含め、これを調査できるソフトウエアエンジニアがいないそうだ。
公聴会で (スコア:2)
公聴会で黒人の議員がグダグダ質問した事について
ウダウダと説明してた社長の言葉を遮るように
「ＹＥＳかＮＯで答えろ」と言われたシーンはムカついたよ
俺なら、彼の発言以降は 「ＹＥＳ」 「ＮＯ」しか言わないだろうなｗ
あんなマジキチの公聴会の後で
仲間に「１００％支持する」って言われておもわず泣いちゃった気持もわからんでもないな
Re:公聴会で (スコア:2)
＞「ＹＥＳかＮＯで答えろ」と言われたシーンはムカついたよ
公聴会なんてそんなものでしょ。
和気あいあいと歓談を楽しむ場だとでも？
そのくらいでムカついて逆ギレするようなら大企業の社長は務まらないし、
公聴会にも出席しない方がいい。キレたら、そこでトヨタの負けです。
Re: (スコア:0)
>和気あいあいと歓談を楽しむ場だとでも？
gdgd書いてないでYESかNOで返事しろ
Re:公聴会で (スコア:1)
逆の立場なら (スコア:0)
調査の方法 (スコア:1)
＞ソフトウエアのコードは1億行近くにも上ると言われている。
どういう調査をするのか知らないんだけど、一行ずつコードを追っていくのか？
最近の組込み、特に自動車なんかは制御系をモデリングしてC++コードを自動生成して流し込むとかそんな話を聞くけど。
大規模コードを追って行って制御系を検証するとか可能なのだろうか。
テストツールとかあるの？
そうそう (スコア:4, すばらしい洞察)
第三者が膨大なソースコードを解析してバグだしするなんて無理だろ。
逐一そういう検証をするなんて現実的ではないから、
(必要ないとは言わないけど)
ソフトウェアエンジニア以外のリソースの方が必要では？
Re:調査の方法 (スコア:1, 参考になる)
http://www.etas.com/ja/products/applications_ecu_development-testing.php [etas.com]
http://www.fujitsu-ten.co.jp/cramas/products/hils.php [fujitsu-ten.co.jp]
http://www.dspace.com/ww/ja/jap/home/applicationfields/automotive/ecu_... [dspace.com]
この辺が主な手法かと。
#もと業界の中の人なのでAC
Re: (スコア:0)
それ調査が目的じゃなくて「ソースを全部寄越せ」と要求して「それは出来ません」と言わせるのが目的だから。
素直にソース渡されたら逆に困るｗ
Re: (スコア:0)
一般的にはデバッグはツールが備えるデータロギング等の機能を使っておこないます
今は自動車屋さんも（いや、金持ってる業界と会社は）みんなMATLABベースのツール使ってるんですよね
フィーリングの問題 (スコア:1, おもしろおかしい)
トヨタ 「これはソフトウェアの欠陥ではなく仕様なのです」
米公聴会「ふざけんな。安全意識が足りない、誠意が足りない。すぐにでも撤退しろ」
マイクロソフト「これはソフトウェアの欠陥ではなく仕様なのです」
米公聴会 「そうか、じゃあ仕方ないな。あなた方の決めたルールに従おうじゃないか」
Re:フィーリングの問題 (スコア:2, すばらしい洞察)
Re:フィーリングの問題 (スコア:1, 参考になる)
公聴会での証言で、「トヨタは恥を知るべきだ」と強く非難した
スミス夫妻の暴走レクサスES350、現在の所有者は異常なく使用中。 [47news.jp]
利用者側にも何か原因があるのかもしれない。
使い方を間違えているとか。
Re:フィーリングの問題（オフトピ） (スコア:1)
利用者側にも何か原因があるのかもしれない。
使い方を間違えているとか。
利用者は間違ってるわけ無いと思うことが多いんですよねぇ・・・
お前の所で作った機械が調子悪いっていうんで、電話サポートの努力もむなしく、
遠路はるばる日帰り出張してみたら、非常停止が復帰してなかったりするんですよねぇ・・・
一番最初に、電話で確認してもらったのになぁ・・・
# 今回の件がどうこう言う訳じゃないですよ。
# ちょっと愚痴が言いたかっただけなんです。
答えはある。それを見つける能力が無いだけだ。
使い方は正しかったのか？ (スコア:1)
先日、職場の車を運転することがあったんだけど、運転席が
すごくふんぞり返った状態で運転する位置に設定されてた。
普段、この車を使っているのが女性職員だから、あのシート
ポジションだと、ほとんど前が見えてない状態だと思うんだ
よね。
私が免許をとって十数年になるけど、AT限定免許がでてきた
あたりから、ふんぞり返って、かつぞんざいな運転をするド
ライバーが増えてきたと思う。
車の運転操作自体にスキルが必要なくなってきたら、周囲に
対する気配りと言うか安全意識まで落ちてきたような感じ。
車って、１トン以上もある金属の固まりが時速数十キロで動
くもので、本質的に危険であるという意識が薄い人が多くなっ
てるんじゃないと思う。
普及して一般的になって、生活に必要なものだからこそ、取り
扱いに注意が必要だし、安全に使うためのリテラシーが求めら
れると思うけど。
・・マイカーがMTなので、MT車は使い方がすぐわかるけど、AT
は難しいですね。操作体系が車ごとに違うし、走ると車の状態
がわかりにくいし。
Re: (スコア:0)
Re: (スコア:0)
Re:フィーリングの問題 (スコア:1)
私は、バックはともかくニュートラルには入れられるだろうと思ってたんですが、
ニュートラルには入らない可能性 [shiwaza.com]もあるようです。そんな仕様ならバックにも入らなくて当然な気がします。
パーキングブレーキは効きが弱いので、走行中なら焼け石に水 [srad.jp]
トヨタは今後は「ブレーキ操作を最優先にして、それでアクセルをキャンセルするような仕様」にすると言ってますが、このあたりが安全に傾けた仕様としては無難な落としどころじゃないでしょうか。
Re: (スコア:0)
たぶんローにだってはいりません。
もしかしたらニュートラルにも入らないです。
サイドブレーキってのは弱いので、高速走行するくらいに駆動力が
働いていたら無意味です。
パニクってブレーキとアクセルを間違えていた場合、道路事情の違いで
日本とアメリカとでは事故が違うのかもしれないですね。
アメリカは160km/hまで加速しちゃう。
日本だとコンビニに突っ込んじゃう。
Re:フィーリングの問題 (スコア:2, 興味深い)
かなり以前に、AT車で走行中にバックに入れる実験をやってみたことがあります。
(ニュートラルに入るというのは変な表現ですが)
そのときは、急停止するでもなく、車輪がロックするでもなく、そろそろと減速し、
停止したと思ったら、これまたそろそろとバックを始めました。
もちろん怖いので、高速走行というほどスピードは出してなかったと思いますし、
バックに入れるときはアクセルを抜いていたと思います。
制御系がどうであれ、走行中にバックギアは機械的につながらないので、
駆動の伝達は切ることはできても、急停止に用いることはできないでしょう。
今回の話題とはズレますが、走行中になんとしてでもバックギアに入れたいのであれば、
MT車で走行中に何らかの方法で後輪をロックさせて、その瞬間にバックに叩き込むことは可能ですね。
いわゆる、神岡ターンというやつです。
http://ja.wikipedia.org/wiki/%E7%A5%9E%E5%B2%A1%E3%82%BF%E3%83%BC%E3%83%B3 [wikipedia.org]
Re:フィーリングの問題 (スコア:2)
軽四での例ですが、坂道での低速走行中2ndへ入れるつもりが何をトチ狂ったか
N→Rと逆に操作して入ってしまった事があります。
そのときはガンッという衝撃とともに緊急停止及びエンストしてしまいました。
低速走行時ならではの事象かもしれませんが、平成初期の車でもこういう例が
あるということで。
Re:参考記事 (スコア:0)
http://www.zakzak.co.jp/society/foreign/news/20100226/frn1002261124000-n2.htm
Re:参考記事 (スコア:0)
Re: (スコア:0)
って意見があったのを見たな
諦めて最期に声を聞こうと夫に電話したら車が止まったらしいし
Re:フィーリングの問題 (スコア:1)
十分に可能性はあると思います。
Re:では (スコア:1, おもしろおかしい)
米公聴会 「・・・・」
Re: (スコア:0)
ここはマイクロソフトではなく、エアバス社（或いはボーイング社）の方がいいのではないかな。
いくら仕様通りでも、誤操作すれば墜落する危険が高い仕様は妥当といえるのかどうか。
一方、国土交通省は (スコア:0)
Re:一方、国土交通省は (スコア:1)
------------
惑星ケイロンまであと何マイル？
Re: (スコア:0)
もしかしてこれ [sponichi.co.jp]のこと？
一方、トヨタは (スコア:0)
以下同文。
＃子会社／孫会社や、インドあたりのオフショア先に丸投げしてたりしないよね？？
＃頼むから、そういう悪い所はIT業界の真似をしないで欲しい。
Re:一方、トヨタは (スコア:1)
インドあたりはエンジニアの水準自体は高いと聞いたんですけど、どうなんですかね？
まぁ、オフショアでコスト削減万歳！と諸手を挙げて自社開発のノリで突っ込んで行ったらヤケドするのは間違いなさそうですが。
Re:一方、トヨタは (スコア:1, 参考になる)
完成車メーカーが書いて検証するのは基本的に仕様書だけです。
その代わり仕様書だけで全てを検証出来るだけの内容になってます。
それを元にコーディングするのはシステムメーカーでした。
ただし、トヨタの場合だとハイブリッドのように外に技術漏らしたくない場合は、内部でコーディングまですると思います。
Re: (スコア:0)
ブレーキシステムは共同開発で、そのうちECUはトヨタだそうです。
http://techon.nikkeibp.co.jp/article/FEATURE/20100208/180034/ [nikkeibp.co.jp]
Re: (スコア:0)
『共同開発』と言われて嫌な予感しかしないのは、きっと私がIT業界の人間だからだな。
こっちの世界だと、名目上は「きょーどーかいはつ」と言いつつ、実際の作業は全部下請けで、
親会社の人間は何もわからずに、厄介ごとは全部下請けに丸投げするイメージしかないから。ｗ
Re: (スコア:0)
＞ただし、トヨタの場合だとハイブリッドのように外に技術漏らしたくない場合は、
ハイブリッドも外注 [google.co.jp]ですよ。
ソフトエンジニアが必要? (スコア:0)
よくわからないのですが
ECUも部品として完成された装置なわけだから、仕様に基づいて入力信号を振って挙動を確認すれば
いいように思えるのだけど、
これはワザワザ、トヨタからソースコードもらってバグ解析しようとしているということかな。
もしかしてトヨタのレクサスは全部の制御をひとつのプロセッサで処理してて分離できていない？
Re:ソフトエンジニアが必要? (スコア:4, 参考になる)
（急加速する）バグをソースから全て調査するなんて、できっこない。机上の空論。
電気信号だけで急加速など問題ある動作をしないような、
セーフティがあったかが問題なんじゃないの？あくまでソフトだけのせい？
Re:ソフトエンジニアが必要? (スコア:2, おもしろおかしい)
今回の話だと、むしろ仕様や挙動そのものの妥当性の方を検証しなければならないのでは。
「仕様にバグが含まれるはずがない(キリッ)」なんてのは、
ソフトウエアを作ったことがないプロマネの幻想です。
仕様が適切と判断するのは誰？ (スコア:1, 興味深い)
仕様通りがどうかはある程度見ているでしょうが、仕様が正しい、もしくは適切であるかどうかは
別問題ですよ。
具体例で申し上げれば1994年4月、名古屋空港での中華航空エアバスA300-600R墜落事故などは
その一例です。
Re: (スコア:0)
>仕様に基づいて入力信号を振って
不具合検証は、正しくない入力があった時に例外処理がきちんと行われるかも見ないと怖い。
通信路(CANとか？)にノイズが乗って通信こけるとか、接続先がアーパーになって途絶しちゃうとか。
ミッションクリティカルじゃない組込系だと相手が正常である前提で例外処理入れてなくて(ROM容量とかマンパワー的に入らないんだけど)、外来ノイズでコケても異常を検知しないからそのまま応答待ちに入って一旦パワーオフして初期化処理からやり直さないとダメなんて事例も。まぁ根本的にコケないような対策は入れるんだけど・・・
Re: (スコア:0)
仕様書に「こういう条件ならブレーキの介入を排除してヨシ！」
なんてロジックが入っているとは思えないので（あったらコワイ）、
仕様書の通りに追っかけてもわからないとおもうなぁ。
数十年前に遭遇したトラブルでは、「その先の処理がぶっつり途切れている」
条件にすっぽりハマった、ということがありましたけど、そういうのならあり得る？
>>不具合検証は、正しくない入力があった時に例外処理がきちんと行われるかも見ないと怖い。
ここですよね。いわゆる異常系のテストだとおもうんですけど、どういう前提で異常状態を
作り出すか、それをどこから入力するのか、が問題な気がします。
＃そもそもそこまでやる気がないんじゃね？と思ったり。
Re: (スコア:0)
資料を検証するにしても、担当者は泣きが入ると思うな。
でも、不完全なままの車を売ったり、リコールしなかったりしたことが問題なわけだから、技術資料を見るのは時間と労力の無駄だと思う。技術資料を見たところで、トヨタとその下請けの技術者に対する同情しか出てこないと思う。
アメリカの自動車メーカーのヘッドハンティングが来たり、、、しないか。
Re: (スコア:0)
なにも受け入れテストをしてるわけじゃないのだから、技術資料なんてチェックしない。
「トヨタが検証をした内容を説明して、それが妥当と納得できれば無罪。さもなくば有罪」
みたいな感じになるんじゃないかと。そして妥当かどうかを判断するためにも、ハードの
技術者に加えてソフトウエア技術者も必要になるというだけ。
「アカウンタビリティー」ってそういうことなんでしょ。トヨタも大変だ。
このへんでいつものアレが出てくるかなｗ (スコア:0)
区別して欲しい (スコア:0)
ドライブ・バイ・ワイヤというと、飛行機におけるフライ・バイ・ワイヤと同様に「自動車の操作全般の電気信号化」という意味合い。今回槍玉に挙げられている「機械ではなく電気信号によるアクセル－スロットル制御」は、通常「スロットル・バイ・ワイヤ」もしくは「アクセル・バイ・ワイヤ」と呼ばれる、ドライブ・バイ・ワイヤの１カテゴリに過ぎない。
ドライブ・バイ・ワイヤの中には、スロットルだけじゃなくて
なども含まれるんで、「ドライブ・バイ・ワイヤ」＝「電気信号によるアクセル－スロットル制御」と言い切ってしまうのは、いくらなんでも極論過ぎ。
とはいえ、自動車の操作でワイヤ化が一番進んでるのはスロットル(次がシフト)なんで、実情を表すという意味では、必ずしも間違いとは言い切れないんだけど。
どれだけの費用と期間が必要でしょうか (スコア:0)
ソフトウェアに問題があったから暴走した？ (スコア:0)
そもそも、ソフトウェアの問題を探すなら、まず「何をしたらどうなったのか」を特定してから。
今回であれば、どういう条件で暴走したのか、を特定しなきゃならない。
少なくとも可能性レベルの検討からしないと始まらない。
全てのソースを洗って、ロジックやデータに問題がないか探せば、そりゃきっとあるさ問題。
OSとかの脆弱性もそれだ。それを見つけて叩きたいんだろう。
でもそれらの多くは他のロジックやデータによって回避され、実行時には問題起こさないんだ。
そのためにテストするんだから。
「ソフトウェアに問題があったから暴走した」ことにしたいのは誰？
Re:ソフトウェアに問題があったから暴走した？ (スコア:1)
そういうソフトウェア技術を持っていない他の（自国の？）自動車会社、
じゃないですかねぇ。
今から開発するより相手がそういうの使えなくした方が楽でしょうし。
# 憶測ですよ、憶測。あくまでも憶測。
どこから手をつけるんでしょうか (スコア:0)
すべての検証は無理でしょ。現象を手がかりに検証するのでしょうけど、証言にしてもどこまで本当
（記憶してるかという意味でも）かで検証のありかたもかわるしょうし大変でしょうね。
車がこれだけ電子化されてるのだったらログやフライトレコーダーのような記録がないと（あるのかな？）
難しそうですね。