********************************************************************** セッションS3-b チュートリアル1 テーマ:システムが安全とは何かを考える(トヨタ急加速問題のNASA分析を題材にして) 講師:間瀬順一(アイシン・コムクルーズ) アドバイザ:高田広章(名古屋大学) 日時:2011/9/2 10:30〜11:50 参加人数:約60名(終了時) ********************************************************************** 本日の進行 ・自己紹介 ・トヨタ車急加速問題の概要 ・検証方法 ・所感とまとめ アイシングループ ・売上2兆544億円 ・世界で4位(自動車部品メーカー) ・主な製品は機械(車関係) アイシングループの主な製品 ・ドライブトレイン系 ・情報系 ・ブレーキ、シャシー系 ・ボディ系 ・エンジン系 自己紹介 ・いままでやっていた仕事 - ソフトウェア開発会社で、ネットワークアプリケーション開発 ・アイシン精機転職後 - バス・トラック向けATの制御ソフトウェア開発の要求分析から設計、実装、テストまで一通り経験 ・いまやっている仕事 - ソフトウェアの専門としてアイシンコムクルーズ はじめに ・トヨタ急加速問題でNASAが行った分析を下敷きに、システムの安全について考える ・システムはメカ、エレキも含むがソフトウェア中心 ・セミナー形式で行う 注意 ・トヨタ急加速問題についてはNHTSAおよびNASAが公開しているレポートを原典としている ・新聞などの報道機関の作成記事も引用 ・アイシン精機の内部的な情報は利用していない ・アクセルの部分はデンソーが担当していた 引用HP ・この問題に関するNHTSAのページ - http://www.nhtsa.gov/UA ・プレスリリース - http://www.nhtsa.gov/PR/DOT-16-11 そもそもトヨタ急加速問題とは ・米カリフォルニアのディーラーが貸し出した車(レクサス)で事故、4人が亡くなった(2009年8月) ・実際には車が暴走している中で電話をかけることができた⇒これがネットで流れた ・アクセルペダルの問題は多数あった⇒フロアマットが引っ掛かってアクセルペダルが踏みっぱなしになる可能性をトヨタが指摘(2009年9月) ・アクセルペダルの材質の問題の可能性 ・ユーザーの踏み間違えも疑われた⇒公の場で言うのは問題があると判断 米下院公聴会(2010年2月) ・フロアマットおよびアクセルペダルの材質関係のリコール ・問題ないと考えられた 公的な機関で調べるため米運輸省(NHTSA)とNASAが調査 ・調査開始(2010年3月) ・問題なしと中間報告で発表(2010年8月) ・電子制御系には欠陥なしと最終報告(2011年2月) 調査結果の主な内容 ・トヨタ車の急加速を引き起こす電子制御上の問題は発見されなかった ・判明した原因⇒アクセルペダルをめぐる2種類の欠陥(リコール済み) ・ユーザーがアクセルとブレーキを踏み間違えた可能性が高い 技術的な視点で振り返る ・NHTSAとNASAの報告書は、いくつかの手法で調査を行ったが、問題は見つからなかったというもの ・ソフトウェアの正しさを証明するのは難しい ・エレキと機械の関係について絶対正しいかどうかの証明は無理だと考えられる ・使われている手法や考え方を知ることが今後の開発の参考になる どのような観点で調べたのか ・ソフトウェア、メカ、エレキ ・ETC(Electronic Throttle Control:電子スロットル制御システム)に意図しない急加速を引き起こす可能性があるか 特性要因図の作成 ・特性要因図⇒フィッシュボーン(石川チャートと日本語で呼ばれている) ・右から書いて左に伸ばしていくことで、不具合を階層的かつ網羅的に探している ・システム面から多数の要因の可能性があるがソフトウェア要因は少なかった ソフトウェア不具合 ・コーディングの不具合 ・アルゴリズムの間違い ・タスクの干渉 ・不十分な故障からの保護 実施した検証 ・静的解析ツールを使った実装コードの解析 ・ロジックモデル検査 ・MATLABを使ったアルゴリズムの検証 ・最悪時間(WCET)の検証 静的解析ツールを使った実装コードの解析 ・NASAは同じツールからでは不具合は見つからないとして、トヨタと異なるツールを使用 ・gcc bersion4による警告を調査 ・Coverityによる調査 - メモリリークのような問題も見つかる、バグ検出ツール - 動的解析で見つからなかったような問題も見つかる(静的解析によって) - 初期化されてない変数、配列のアクセスミスといった問題を検出 ・CodeSonar、Uno(ベル研究所)による調査 ロジックモデル検査 ・SPINを用いたモデル検査 - 6つのロジックに対して、モデル検査を実施 ・SPINのフロントエンドとして、Swarmを利用した ・前提条件、事後条件を書いて普遍式が変わらないか検証 - 3つのロジックは問題なし - 1つのロジックは解析不能と判断 - 2つのロジックは問題を検出したが、実際に起こらないことを確認 MATLAB(Simulink)を使ったアルゴリズムの検証 ・かなり時間を使った検証である ・モデルを作成して以下の3点について調査を行った。 - ペダルセンサー⇒入力電圧を変えてスロットルにどのような影響があるか - クルーズコントロール⇒意図せずにon又はoff出来ないことがないかを確認 - アイドルスピードコントロール(ISC)⇒最大の影響はどれくらいの大きさか パラメータを変化させながら次ののテスト件数で検証を行った ・ペダルセンサについて11万4224件⇒全て合格 ・クルーズコントロールについて16384件(意図せずON)+24576件(off出来ない)⇒全て合格 .アイドルスピードコントロールについて258048件⇒影響は問題ないほどの大きさ トヨタとNASAの合同のモデリング検証について ・4506個Simulinkでモデリング ・約70の状態遷移 ・約300時間によりモデリング ・モデリングについてはかなり情報が隠されている ・ハイスペックのパソコンを使っているが、簡単に入手可能で同様の検証は可能 最悪時間(WCET)の検証 ・デッドラインに間に合わない可能性があるか解析を行った ・トヨタが提供したデータをもとに解析を行う ・aiT(商用ツール)を使う - CPUモデルに対して制限あり - マルチタスクと割り込みは、対応していない - 周期実行だけでなくイベント発生にも対応 - 時間あふれは検出されず - 工夫の余地あり NASAの検証について ・問題となる事象が分かっているため、特性要因図から事象の原因となる可能性を探した ・ツールを駆使した検証 ・特性要因図にはユーザーの操作ミスを入れた 標準ソフトウェアの準拠 ・トヨタのRTOSはOSEK準拠 ・アーキテクチャについてトヨタの部品は世界でも標準的な部品 ・可能な限り、標準ソフトウェアに準拠しておくとよい - それほど複雑な機能を使わない - 説明責任の際、世界標準である方が有利 製造物責任法について ・製品の欠陥によって生命、身体又は財産に損害を被ったことを証明した場合に、被害者は製造会社などに対して損害賠償を求めることができる法律 ・日本では1995年に成立 ・民法の規定の範囲では、壊れたものがあって損害があった際、被害者方が訴える ・製品の欠陥があっても過失がない場合、民法ではグレーゾーン ・アメリカでは早くから成立 - 挑発的な損害賠償を言われる可能性 - 当時の日本の300億円相当のの判決もあり 開発危険の抗弁 ・人類の科学・技術には常に一定の限界がある ・防止するすべのない危険について責任を負わされる事は製造者にとって納得いかない ・研究開発や技術革新の意欲阻害につながる ⇒つまり、民法の責任はあるが製造物責任法は良くないというもの 科学・技術の水準 ・特定の製造者の水準や業界の平均的水準ではない ・製品が流通に置かれた時点での世界最高の科学・技術の水準 具体的に「科学又は技術に関する知見」とは ・法では具体的な解釈を定めていない ・ある種の認証に準拠したら、製造物責任法には問わないという合意はあり得る NHTSAとNASAのレポートについて ・コードに関しては複数のツールを使って静的解析 - SPIN、MATLAB、Simulinkなどでシミュレーション ・科学・技術最高水準のNASAが調べて出した結果ならば間違いないだろうという見解 まとめと所感 ・提示された検証手段 - ソースコードに対する静的解析 - モデル検査 - MBDを用いたアルゴリズムの検証 - 最悪時間の解析 ・ツールをたくさん使っている - ツールを使っておけば安全というのは危険な考え方 - 大きなことを扱う際には有効 ・NASAの検証は特殊な検証ではない - 解析については商用ツールを使っている - とんでもなく高性能なPCを使っているわけではなく我々でも再現可能な範囲 ・システムの完全な検証を行うことは難しい問題だが技術者には次のようなことが求められる - システムが考える想定範囲を明らかにする - 追試可能な検証結果を残す ・NASAに証拠がしっかりと提出できたことはよい アドバイザからの補足 ・NASAが行ったのはソフトの検証というより事故分析 ・スペースシャトルの事故後の分析のようなもの ・検証と言うには甘い ○質疑応答 <質問者1> トヨタはソースコードをNASAに提出したのか? <回答> 提出しました。 ただし、公開に関してはかなり気を使って提出しました。(重要事項を黒色で塗りつぶしたりなど) <質問者2> 手作業でSPIN等を用いる際、バグが入る可能性があるが、NASAがバグの入ったコードで検証を行っていた可能性はないのか? <回答> 今回の検証自体、間違いが起こる可能性を秘めている。 検証に間違いがないかの検証を証明するのは困難。 つまり完全に正しいとは言えない。 <質問者3> 今回の問題についてプロセスについて問題はないか? <回答> プロセスについてはラフな説明がレポートの中に書かれていた。 厳密なことはわからない。 世界的な標準に準拠していかなければないが、まだ100%ではない。 <N氏からのコメント> グローバル時代で製品が海外へ出ていく中で、品質の説明、ツールを用いることの有用性といったことが重要となるが、これから我々はどうしていけばよいか。 <回答> 検証をするコストは必要なコストとして考える必要がある。 品質説明力が上がればコストも上がる。 品質説明を高めることが、実質的に品質を上げることに寄与しない限り高まらない。 我々の商品力を高め、トータルコストで安くなるようにする必要がある。 <質問者4>我々がこの先このレポートをどう生かしていくかは、ただ品質が高いことを説明すればよいだけではなく、品質がもっと高まる方向に向けて行くような品質、サイクルを生み出していく必要があるということか? <回答> そういうことです。 できたもので品質がはかられてしまう。 <S氏からのコメント> ・品質を追っかけて行くとどんどん負荷がかかり、足かせとなりそう ・発想の違うところからもっといいものが作れるのではないのだろうか ・テストに依存しないで発想力の転換を図れないか。 <回答> 危ないのは盲目的にやってしまうこと。 本質的な品質につながる活動を心掛ける。 最後に… 車は、ソフトウェアで走っている!!