ソフトウェアの特性を考慮せず事故が起きた事例

【1985年～1987年に起こった放射線治療器 Therac 25（セラック25）の事故】

Therac-25は高エネルギーの透過性放射線を患者の身体の奥に照射し、周囲の組織を傷つけることなくがん細胞を破壊する装置で、巨大なアームの照射口からは、電子線とX線の二種類の放射線が照射される。

 透過性の高いX線を生成するときは、高エネルギーの電子の流れを金属製のターゲットにぶつけ、電子線生成モードのときは、金属のターゲットを自動的に移動して電子線のエネルギーレベルを下げ、直接腫瘍にビームを送る。低エネルギーの電子線はX線より透過性が低いため、皮膚の表層に近いがんの治療に使われた。Therac-25はいわゆる組込みソフトウェアで動く機器だが、1980年台の装置でソフトウェアはPDP-11（※1） というミニコンピュータを使って制御を行っていた。

※1 PDP-11 は、ディジタル・イクイップメント・コーポレーション(DEC)が1970年代から1980年代に販売した16ビットミニコンピュータシリーズ。

Therac-25 の事故では複数の医療機関で放射線治療装置が誤動作し、過大な放射線を浴びた患者に死傷者（6名）がでた。この事故はソフトウェアの不具合が原因であり、見えないソフトウェアのせいで再発防止が進まない中、ナンシー・レブソン（現マサチューセッツ工科大学教授）らの努力により事故原因が詳細に調査され、レポートが発表されており、このレポートは20年以上たった今でも、ソフトウェアエンジニアにとって深い教訓として伝えられてる。（※『セーフウェア』 翔泳社 2009 に詳細が記載されている。インターネット上ならば、こちらでも英文でレポートを読むことができる）

Therac-25 の事故は20年以上も前に起こった事例だが、ナンシー・レブソンの詳細な調査により現代にいろいろな教訓を残した。

【Therac-25 は Therac-20 の後継機だった】

普通、後継機種の場合「枯れた」ソフトウェアを再利用できるため、安全や信頼は増す。実際、ソフトウェアの大半は　Therac-20のソースが使われていた。

それなのに何故事故が起きたのか。誤解されたくないので、ここで注釈を入れておく。ソフトウェアが絡んだ事故は「○○だから××である」といったように簡単には語れない。プリウスのブレーキソフト改変に関する分析だって結構な時間と労力をかけて書いた。（しかも、本当のことは分かっていないし、ソフトウェアの問題ではないかもしれない。）だから、本当に Therac-25 による事故の原因を知り、自分達のドメインの再発防止に利用したいのなら、必ず原本を読んでいただきたい。ここでは、あえて、複雑な問題発生の原因のうちの一端のみを紹介する。努々ここで紹介したことだけで6名もの犠牲者がでるような事故に発展したのではないことを理解していただきたい。20年も前のソフトウェアエンジニアだって、そこまでいい加減ではないということを強調しておく。

さて、枯れたソフトウェア資産を再利用しているのになぜ事故が起こったのかの。そもそも Teharc-20 のソフトウェアに混入していた不具合をハードウェアの安全装置でブロックしていたが、Therac-25 でその安全装置を取ってしまったことが原因の一端となっている。（実際、この安全装置が Therac-25 にも付いていれば最悪の事故は免れたと考えられている）

Therac-6 や Therac-20 では独立した安全装置が異常エネルギーの出力をブロックしていた。

そして、Therac-25 の開発をする際に、経済性の理由（たぶんコストダウンだろう）から、このハードウェアの安全装置をソフトウェアに置き換えた。そして、それによってもともと Therac-20 に内包していた不具合が表面化してしまった。（実際にはそんな簡単な話ではないがここでは簡略化して書いている）

当然のことながら、機器の品質保証担当は「そんなことして大丈夫か？」と思っただろう。そこで、Therac-25 の製造もとである AECL は1983年3月に Therac-25 に対する安全解析を実施した。

この分析は FTA（フォールトツリー解析）で行われた。FTA と FEMA は非常に有名な安全解析の手法なので、初めてこの言葉を聞いた方は インターネットでどんなものか理解しておいて欲しい。

この安全解析の結果 AECL は次のような報告を出した。

【『セーフウェア』 Appendix A.2 より引用】

1. ハードウェアエミュレータ上と遠隔治療装置の照射野条件の下で大規模な試験を行うことにより、プログラミングエラーは減少していた。未解決のソフトウェアエラーは分析には含まない。
   
2. 
   ソフトウェアは長期使用、疲労、あるいは再生産プロセスが原因で品質が低下することはない。
   
3. 
   コンピュータの実行エラーは、ハードウェアコンポーネントの欠陥や、α粒子や電磁ノイズによって引き起こされる「ソフト」（ランダム）エラーが原因である。
   

このレポートは複雑なソフトウェアを作ったことがない人が書いたのだろう。解説すると、1は、「ハード・ソフト込みのシステム（ハードウェアはエミュレータ）でさんざんいろいろな試験を行ったのでバグはほとんど潰した」ということだ。ハードウェアはエミュレータを使っているので異常状態、故障状態も再現できているので心配ないという主張だ。

残念ながらTherac-25 の事故から20年以上たった現在でも、ほとんどの機器がこの方法でシステムの安全を確認している。そして、そこにソフトウェアが絡んでおり、ソフトウェアの規模が大きく、複雑であればあるほど、そのやり方では漏れが生じる。

ちなみに、1で「未解決のソフトウェアエラーは分析には含まない。」は正直な申告だと思う。日本人ならこの一文は削除して報告しただろう。なぜなら、未解決のソフトウェアエラーが既存のシステムに影響を与えないという根拠は何もないからだ。そして、この安全解析報告の作成から実際の製品のリリースまでの間にソフトウェアが改変されたらその改変がデグレードを誘発しない保証はない。

2の「ソフトウェアは長期使用、疲労、あるいは再生産プロセスが原因で品質が低下することはない。」はハード屋さんがソフトウェアをどう見ているか端的に表している。ようするにハードウェアでは部品の故障や生産時のさまざまな問題があり、品質保証の活動とはこれらの問題をいかに押さえ込むかが我々の仕事なのだ、その点ソフトウェアは何回コピーしても品質が劣化しない、すばらしい、品質は完璧だと考えているのだろう。今となってはソフトウェアの不具合で商品をリコールすることは日常茶飯事になっているから、QA担当もそうは思っていないだろうが、多くのQAはソフトウェアは分からない、自分では品質を保証できないから誰かお墨付きをくれ！と考えているような気がする。

3は笑ってしまうが、ソフトウェアの実行エラーは放射線などでメモリーのデータ化けなどが原因であり、バグは1で潰しているから、ハードウェアや外部環境の影響からプログラムやデータを守れば大丈夫だと言っているのだ。

実際この安全分析の FTA には障害を発生させる原因コンポーネントとして、「コンピュータの故障」も含まれている。そして、「コンピュータが誤ったエネルギーを選択する」が発生する確率は 10のマイナス11乗で、「コンピュータが誤ったモードを選択する」が発生する確率は4×10のマイナス9乗となっている。

この発生確率は後にナンシー・レブソンらの分析によって何の根拠もないと結論づけられたが、その当時はおそらく　PDP-11 がハードウェア部品として故障する確率を示したのだろうと予想される。

このことから安全解析実施者はソフトウェアやソフトウェアの不具合についてほとんど知識がなくブラックボックスとして分析をしていることが分かる。

ソフトウェアの恐いところは、どんなに難しいオペレーションでなければ発生しない不具合でも、その通りに操作すると100%確実のその不具合は発生するということだ。その結果、Therac-25の場合は約3年間の間に 6名の犠牲者を出してしまった。

現在、トヨタのリコール問題でアメリカが騒いでいるのは、犠牲者が増えることをできるだけ抑えるための手順、プロセスを組織が定めて、それを確実に実施しなさい、また、その手続きの間に隠蔽や怠慢などがあったら絶対に許さない、責任はトップにあると言っているのだと思う。

事故が発生したときのオペレーションはその通りなのだが、ソフトウェアが絡んでいるときは困ってしまう。原因が簡単にはわからないし、事故の発生確率をはじき出すのが難しいからだ。だから、ソフウェアがらみのときは、事故の重大性だけでランクを判定する。例えば

※仮にソフトが関係していたと仮定して

・アクセルペダルが戻らない→重大

・低速でブレーキが抜ける感覚がある→軽微

・アクセルが急加速する→重大

といった具合だ。（ソフトウェアが原因だった場合は発生する確率は考慮できない）
国際安全規格のリスク(risk)の定義は危害(harm)の発生確率×危害の重大(severity)である。しかし、ソフトウェアに起因するリスクにおいては発生確率はハードウェアの部品故障率のようなものにはできない。原因が分かってしまうと直せるなら直せと言われてしまう。

今後、ソフトウェアをブラックボックスにしかとらえられないハードウェア出身の組織上位層や品質保証担当が、自組織や協力会社が作ったソフトウェアの安全性や信頼性について第三者に安全性や信頼性についてお墨付きを付けてもらおうという動きが増えることが目に見えているが、ここではっきり言っておくがその考え方では絶対に安全は確保できない。

なぜなら、大規模複雑化したソフトウェアの各サブシステムの統合時のわずかな検証漏れ、設計コンセプトの考え方の違いなど、設計者達のヒューマンエラーに起因した問題は、設計サイドの技術者がアーキテクチャを可視化して、自分達で問題点を見つけないと見つからない可能性が高いからである。

アメリカ人に責められたらサムライになれ

20年以上前アメリカ人の監査官とソフトウェア品質についてやり合ったことがある。自分の作ったソフトウェアに対していろいろ質問され、こんな性格だから自信持ってキッチリ答えたつもりだった。

だけど、判定はクロだった。そのときはなぜダメなのかまったく理解できなかったが、後から彼らが求めていることについて調べていくうちにだんだん分かってきた。

【判定クロの理由】

• エンジニア個人の成果はその個人に由来するものであって、組織的な安全性や信頼性を担保するものではない。検証結果があるだけではダメで、検証の範囲、合否判定基準を明確化し、漏れなく実施するという組織的ルールが存在し、それが実行されていることが求められる。
• アメリカ人はあらかじめルールを公開している。そのルールを事前に読んでいない、知らなかったは許されない。フェアーに対してアンフェアーな対応は絶対に許されない。
• 責任あるものの承認行為が必要である。責任あるものはその責務を全うするための資格を持ちトレーニングを受けている必要がある。

自分は20年前の若かりし頃、エンジニア個人としての自信を打ち砕かれる出来事があってから、猛然とアメリカ人が求めていることを学習し理解することに務めた。そして、学習すればするほどアメリカ人の考え方と日本人のエンジニアの考え方に大きなギャップがあることを痛感した。

だから、それ以後ずーっと、アメリカ人と日本人の違い、欧米で体系化された方法論が日本で形骸化する理由について考えてきた。

アメリカ人はフェアーとアンフェアーに非常にこだわる。特に瑕疵（欠陥）があることを知っていたのに隠していたりすることは絶対に許さない。そして、それを見つけたとき末端の作業者ではなく必ず責任者を非難し罰する。

だから、疑いをもたれたら自分達の正当性を責任者が自信を持って説明しなければいけない。日本人はなかなかこれをとっさにはできない。常日頃、責任と権限について考え、アンフェアーを許さないスタンス、言動と行動をとっている必要がある。

曖昧でどっちつかずの対応をしている日本のエンジニアはアメリカ人に責められると徹底的に守勢に回ってしまう。そしてびくびく、おどおどしだし、いろいろな質問に対してグレーなことを指摘されると YES / NO を答えずに言い訳をし始める。そんなシーンをこれまで何度見てきたことか。

品質問題に関してアメリカ人に対峙するときのポイントはつぎの5点だ。

1. アメリカにおけるルールをおさらいし頭にたたき込んでおく。
2. そのルールに逸脱しているのかしていないのかという視点だけで物事を考えるようにする。
3. 質問の意味が曖昧だったり、個人の主観に見えたときは臆せずにどのルールに基づいた質問であるかを聞く。
4. ルールに反していないのなら自信を持ってその正当性を主張する。
5. グレーだと思ったら白の要素の根拠を説明し、言い訳はしない。

好き嫌いは別にして、こういう訓練をしているとだんだん日本人の問題点が見えてくるのと同時に、自分自身に武士の魂が宿ってくるような気がするから不思議だ。

豊田社長にはアメリカ議会の公聴会でサムライとして堂々と質問に答えてもらいたい。

※『サムライエンジニア再び』も参照されたし。

P.S.

現在、ソフトウェアの安全と信頼を実現する方法について書いた本を執筆していて、最終段階の校正をしている。3月の終わりの方には書店に並ぶようなスケジュールとなっている。それまでこのブログサイトで少しずつ本のコンセプトや内容の一端を紹介していこうと思う。

もちろん、このブログで主張していること、解説していることも随所に取り入れているので、ブログの読者の方々の期待を裏切らない内容となっていると思っている。

『組込みソフトエンジニアを極める』第4章「品質の壁を越える」にも結構書いているんですけどね。

“品質の壁” は、組込みソフトに求められる安全性や信頼性をクリアするために越えなければならない目標です。組込み製品は人の生活に密着しており、組込みソフトは組込み製品をコントロールする頭脳となっているため、そこに不具合があるとユーザーに迷惑がかかるだけでなく、企業全体の信用も失墜してしまいます。企業にとっては製品回収の費用が利益を圧迫しているという現状もあります。組込みソフトエンジニアは、ソフトウェアの品質向上についての理論を理解し、プロジェクトや組織としてその理論を実践することで、製品の安全性や信頼性を確保します。組込みソフトを取り巻く世界は、グローバル化しつつあります。世界全体に広がった市場で、日本の組込み製品、日本の組込みソフトは品質が高いというブランドイメージを守り続けなければ、私たち組込みソフトエンジニアの足下も揺らいでいくでしょう。


『組込みソフトエンジニアを極める外伝』より

プリウスブレーキ制御ソフト改変についての考察 （訂正）

プリウスのブレーキ制御に関しては次々に新しい事実が分かるので過去の考察を訂正していかないといけない。

【いろいろな事実を総合して分かったこと（訂正を含む）】

• この問題はたぶんソフトウェアのデグレード（変更によって今まで動いていたところが動かなくなるミス）ではない。
• この問題は複雑化していたブレーキシステムの軽量化、低コスト化により、ブレーキシステムのハード・ソフトが変わった際に Validation（妥当性確認）の 漏れが生じたことからきている。
• 漏れがあったからといってトヨタやアドヴィックスがV&V(Validation & Verification)を十分に行っていなかった訳ではなく普通の企業に比べればよっぽど念入りにやっていた。（と予想する。）
• 軽量化やコストダウンの検討は悪ではなくエンジニアがトライすべきことだから、その流れは間違っていない。（だからデグレードではない。もとに戻してしまうと重量が重くなり、コストアップしてしまう。それは商品の価値を下げ、結果的に顧客満足度も下げてしまう）
• 結果的にソフトウェアの改変で問題を解決しようとしたがソフトウェア技術者のミスともいいきれない。（Validation のステージにおいてすべてのシチュエーションを想定して確認することは不可能）
• この問題は設計の工程で見つけられた可能性は低く、ユーザークレーム→原因分析→是正→水平展開という CAPA（Corrective Action & Preventive Action：是正処置及び予防措置）で改善する種別のものである。
• 結果的に今回の問題は受容可能なリスクと判断される。（実質的な安全性の確保とユーザーの気持ち悪さ、不安とは異なる）
• 上記のことから、今回の問題はエンジニアの過失はとは言い難い。

【Tech-On! 記事『汎用部品の活用で回生協調機能を低コスト化』を読み解く】

Tech-On! 記事『汎用部品の活用で回生協調機能を低コスト化』の記事を落ち着いてじっくり繰り返し読んでみた。日経Automotive Technology はすごい。どうして、トヨタのエンジニアでもないのにここまで詳しくブレーキシステムのメカニズムが分かってしまうのだろうと思う。

この記事をエンジニアではない一般の読者が読んでもよく分からないと思うので解説しながら内容を理解したいと思う。（途中、Tech-On!の記事をところどころで参照している）

【とんでもなく複雑化しているハイブリッド車のブレーキシステム】

プリウスは燃費を向上させるために、制動時に車両の運動エネルギーを回収する機能を備えた「回生協調ブレーキ」システムを搭載している。

ガソリンエンジンの車ではブレーキによって削減された運動エネルギーは全部熱エネルギーに変わる。プリウスは制動時の運動エネルギーでモーターを回し発電し発電した電気エネルギーをバッテリに蓄えることでエネルギーを回収している。

自転車のライトを光らせるときにこぎ手は負荷を感じるだろう。運動エネルギーの一部でモーターを回しそれを光に変えているからだ。でも坂道にさしかかると漕がなくてもモーターはまわりライトは光る。プリウスはいわばこのときのエネルギーをバッテリに蓄え燃費向上に使っているのだ。

回生協調ブレーキの基本的な作動原理は次の通りだ。まず、ドライバーがアクセルペダルから足を離した段階で、ドライバーに違和感がない程度に、軽い回生ブレーキをかけ、運動エネルギを回収する。次に、ドライバーがブレーキペダルを踏むと、ペダルを踏む速度と、ペダルの踏み込み量から、ドライバーが要求する制動力がどの程度かを判断する。この制動力の範囲内で、最大限の回生ブレーキをかける。そのうえで、回生ブレーキでは足りない分を油圧ブレーキで補う。

Tech-On! の記事には図が載っているのでそれも見ていただくとして、この部分を読んだだけでもとてつもなく複雑で繊細な制御をハード・ソフトでやっているのがわかる。以前読んだ記事ではプリウスは回生ブレーキと油圧ブレーキを切り替えていると書いてあったがそれは間違いで、回生ブレーキでエネルギーを最大限回収しておいて、それだけではドライバーが想定する制動力には足らないのでその不足ぶんを油圧の制動力で補っているのだ。

回生（モーターによる制動力）はリニアではない。ハイブリッドではない車のブレーキペダルを踏んぶんだけリニアに制動する感覚を再現するためには、リアルタイムかつセンシングとアクチュエータのフィードバックのハード・ソフトが必要になる。

この時点で安全アーキテクチャの基本であるシンプルデザインと安全をつかさどる機能・性能のアイソレーションは崩れかけている。しかし、これはしょうがないのだ。ユーザーニーズは多様化し、多様化したニーズを実現するためにシステムは複雑にならざるを得ない。

しかし、複雑にも程度はあって、ソフトウェアの場合指数関数的にぐちゃぐちゃにすることが簡単にできるので、ユーザー要求を満たすための最低限の複雑さにとどめておく必要がある。

そういう努力をおそらくアドヴィックスやトヨタはしており、たぶん、他の業界よりも進んだ取り組みをしていると予想する。それでもこぼれ落ちる問題は発生するのだ。

【なぜ、先代プリウスでは発生せず、新型プリウスでは問題が起こったか】

Tech-On! の記事によると、先代プリウスは回生協調ブレーキの機能を専用設計のシステムにより実現していた。これに対して新型プリウスでは、汎用的な横滑り防止装置（ESC）と部品の共通化を進めたらしい。

ちなみに、この取り組み自体はシンプルデザインと安全機能・安全性能のアイソレーションとは逆行しているから、ユーザーに対する価値（主にコストダウン）の向上を目指した取り組みであったとはいえ危険な領域に一歩踏み出しているといえる。（『セーフウェア』で解説されている放射線治療器セラック25の事故がセラック20のコストダウンがきっかけになって起こったのに状況はよく似ている）

トヨタは部品の共通化を進めた結果、ブレーキシステムの重量を29%も減らし、低コスト化も実現した。これは想像だが、メカとエレキのコストダウンを実現して、結果としてソフトウェアの負担（複雑性、規模）が増えることがある。コストダウンを達成して、めでたしめでたしの裏にソフトウェアの問題によるリスクの高まりが見落とされていることがあるので、ハードウェア出身の組織の上位層の方達はその点をよく認識しておいて欲しい。部品のコストダウンで一見成功したに見えた利益アップはソフトのリコールで一気になくなりマイナスになる可能性もあるということだ。（だからコストダウンをやめた方がいいのではなく、そういうリスクがあることを認識した上で慎重にソフトのV&Vを行う必要がある）

【新型ブレーキシステムの構成】

新型ブレーキシステムは次の部品から構成されている。

• 油圧ブースタ
• ブレーキアクチュエータ
• ストロークエミュレータ
• ECU（Electric Control Unit)ようするに頭脳の部分でここにソフトが入っている。

従来のブレーキシステムのと違い

従来のプリウスに搭載していた回生協調ブレーキは「ECB (Electronically Controlled Brake System)2 」と呼ばれているそうで、ブレーキペダルを踏む力が、通常走行時は直接各車輪には伝わらない「ブレーキ・バイ・ワイヤ」となっている。

※ECB2 というくらいだから ECB1 もあったのだろう。回生協調ブレーキとしてECB1→ECB2 と改善しながらハード・ソフトを枯れさせていったが、新型ブレーキシステムではコストダウンのために大幅に変更した。（一般的にそういうところに問題:Anomaly は潜んでいる）

先代プリウスではブレーキペダルからの油圧配管は、ブレーキ配管からは遮断されている。ドライバーが要求する制動力は、ブレーキペダルを踏む速度と、ペダルの角度をセンサによってセンシングしてコンピュータ制御＋モーター駆動の油圧ポンプで制動する。

このとき発生した油圧は、各輪に装備したリニア・ソレノイド・バルブによって制御し、必要な制動力を生み出している。

※このリニア・ソレノイド・バルブが高価で大きい部品らしく、新型プリウスではこの部品をデューティ型ソレノイドに変えてコストダウンをはかった。

【従来ブレーキシステムの欠点】

リニア・ソレノイド・バルブは内部のスプールバルブを高い精度で位置決めすることで、精密に油圧を制御できるとう特徴を持っている。ようするに高価だが性能のよい部品ということ。

これに対して、デューティ型ソレノイドは基本的にはオンとオフしかできないが、オン時間とオフ時間の比率を変えることで油圧を制御できる。その精度はリニアソレノイドほどではない。

※ここは今回の問題が発生した原因の中核となる部分だ。デューティ型ソレノイドはリニアソレノイドのように滑らかに制御できない。オンとオフを繰り返すことで制御するので振動が発生する。この振動を抑えるために変えた制御方法が今回の問題を生んだ。（たぶん）

リニアソレノイドは各輪にリニアソレノイドと圧力センサを備えることで、各輪のブレーキ油圧を独立して制御することができるので、ハイブリッドでない車種にも採用されている。そんな高価で高性能な部品を先代プリウスでは使っていた。ホンダのインサイトに価格対向するために新型プリウスでは高価な部品を使わないで要求されている機能や性能を実現する必要があり、結果的にこぼれ落ちた滴があった？のかもしれない。

【新型プリウスのブレーキシステム】

新型プリウスではシステム全体の油圧を決定する部分だけにリニアソレノイドを使い、この油圧を検知するセンサも一箇所だけ、そして、各輪には安価なデューティ型ソレノイドを使っている。

なお、もうひとつ新型プリウスでは低コストの取り組みをしている。従来型のブレーキ・バイ・ワイヤのシステムでは、電源が落ちるとポンプを駆動するモータが動かず、制動力を発生できないため、バックアップ電源としてのキャパシタ（一時的な蓄電池）が装備されていた。新型プリウスではブレーキシステムのくふうでキャパシタをなくしコストダウンを実現した。（くわしくは Tech-On!の記事を参照のこと）

この設計の変更により、新型プリウスはブレーキ・バイ・ワイヤとドライバの踏み力を直接各輪に伝える切り替えが可能になった。（と予想している）　そして、このメカニズムの変更を利用して、リニアソレノイドからデューティ型ソレノイドにコストダウンしたことによって低速で発生する振動ノイズを減らす制御を採用した。そこに落とし穴があったのではないだろうか。

前回の記事で、リコールによる改変で先代プリウスの性能にもどった→デグレードしたと書いたが、ブレーキシステム自体大幅に変わっているので、先代プリウスの性能にもどった訳ではない。

デューティ型ソレノイドを使っているぶん、ABS作動時に発生すると言われるノイズや振動は先代プリウスではなかった問題なのだろう。それが今回のソフトウェアの改変で復活したと思われる。そのノイズや振動は許容できるかどうかといえば、リスクとしては許容できるレベルであり、快適性とう点から考えると今後の検討課題になると思われる。（一度は低減する方向性を出している）

【従来ブレーキシステムから新型ブレーキシステムへの変更点】

• 従来ブレーキシステムではレクサスHS250h や SAI などにも搭載されているリニア・ソレノイド・バルブを使っていた。
• 従来ブレーキシステムではドライバーとブレーキが直接つながっていないブレーキ・バイ・ワイヤのシステムだった。
• そのため従来ブレーキシステムでは電源が落ちたときのバックアップとしてキャパシタが載っていた。
• 新型プリウスでは、リニア・ソレノイドの使用を減らし、デューティ型ソレノイドを採用し、さまざまな変更を行った結果 29%の軽量化、コストダウンに成功した。（キャパシタもなくなった）
• 変更を行ったことで、低速でのABS始動時にデューティ型ソレノイドによるノイズ・振動がブレーキペダルを通じてドライバに伝わるようになった。
• その問題を解決するシステム制御に今回の問題があった。（どちらも許容できるリスク）

【商品の価値を高めるためにコストダウンは必要】

コストダウンによるシステムの変更。それもメカもエレキも大幅に変えるとなると、ソフトウェアエンジニアはそれは危ないからやめましょうとはいえないし、変更をやらないという選択肢はない。やらなければ他社に勝てない。

だから、コストダウンの取り組みはメカもエレキもソフトも協力して実現しなければならず、かつ、安全性・信頼性も確保しなければいけない。

たぶん、今回の問題は受容できるリスクの範疇であったと思われる。低速でABSが働くときにしか起こらない。制動距離は70cm 伸びるが本当にドライバが危ないと感じればブレーキペダルを強く踏み込むので制動距離は縮まる。

こう理解すると、これまでのトヨタの記者会見では発表内容は逐一納得できる。ただ、コストダウンが目的によるブレーキシステムの設計変更が問題の発生を誘発したとは絶対に言いたくないだろう。そんなことを言おうものなら『コストダウンにより不具合混入』などという超短絡的な見出しだけが一人歩きする。

【安全を脅かす落とし穴はどこに存在するか】

• システムやソフトウェアの大規模化、複雑化に潜む
• コストダウンでメカ・エレキを省略する行為の中に潜む
• ソフトウェアが見えないというところに潜む
• ソフトウェアが見えないことを認識しないで問題を単純化するところに潜む

冒頭に書いたことを繰り返すと、今回の問題は結果的にソフトウェアを修正したが、ソフトウェアだけの問題ではなく、ブレーキシステムのメカ・エレキ・ソフトを変更した際の Validation （妥当性確認）に漏れがあったということだ。

そして、その漏れは受容できるリスクの範囲ではあったが、ユーザーの気持ち悪さと不安を取り除くためにリコールにした。

トヨタが反論しない理由は、説明しても一般の人が簡単に理解できるような内容ではないことと、説明すればするほど技術的な背景を理解できない者が「トヨタはいい訳をしている」と批判するからだろう。

この問題を通じて再認識したのは、一つの問題や事故の後ろには非常に複雑でテクニカルな内容と組織判断が含まれているということだ。今回の問題は事故ではないが、仮に複雑なシステムで事故が起こった場合、その深層に一般のジャーナリズムが切り込んで解明することはおそらく不可能だということだ。日経BPの記者だって、ソフトの中に問題があれば分析のしようがない。

そう考えると、日本も複雑なシステムの事故を客観的に調査する機関があるべきだと思う。航空機や鉄道にはあると聞いたことがあるが、専門分野のエキスパートが客観的に問題を調査できるようでないとまずいだろう。

P.S.

やっぱり、コストを含む市場要求と顕在的価値、潜在的価値（安全・信頼）とのバランス、トレードオフ及び、成果物の V&V(Validation & Verification）がこれからの複雑化するソフトウェア搭載システムの課題だと思う。

Tech-On!を見ていたら『Ford社、ハイブリッド車の回生ブレーキのソフトウエアを書き換え』という記事があった。これってプリウスのソフト改変とまったく同じに見える。同じブレーキシステムをトヨタやアドヴィックスが提供していたならともかく、そうでないのだとしたらプリウスをバラバラに分解してデッドコピーしたのでは？と思わせる。なんで、こっちはリコールじゃないんだろうか。

プリウスブレーキ制御ソフト改変についての考察 （まとめ）

(トヨタは社長と副社長が 2月9日の記者会見で、今回の問題について客観的なデータをもとに論理的に発生する現象及び原因を説明していた。

新聞やテレビの記者はエンジニアではないから、この技術的な説明の部分を全部すっ飛ばしてしまう。ラジオで聞いた制動力がが回復するまでの時間 0.4秒 というキーワード＋プリウス＋ABS で検索したら、今回の記者会見の技術的な説明が書かれている記事を見つけた。

Car Watch というサイトだ。この記事を読んでエンジニアとしては分からなかったことが全部分かってスッキリした。Car Watch さんありがとう。

詳細はこの記事を読んでもらうとして、自分が理解したポイントを書いていきたいと思う。

【今回の問題で制動距離が伸びるのか】

→想定する条件下において70cm伸びる

ブレーキペダルの踏力をそのまました場合、通常のABSが0.4秒で作動するところ、0.46秒かかるので、通常のABSでは60cmのオーバーラン（タイヤがロックしないようにするため）に対して、今回の問題が起こるとさらに70cmの距離が必要になる。

ちなみに、この説明だと 0.06秒 = 60msec しか遅れはないように見える。60ms という時間は人間が感じるのは難しいくらいの短い間隔だ。


【本当の問題】

本当の問題はこのABSの立ち上がり時間の遅れではない。実はユーザーのためによかれと思って変更したソフトウェアの改変が、非常に見つけにくい問題を生んだ。

そもそも、昔の車はブレーキを踏むとその圧力がダイレクトにブレーキパッドに伝わるようなシンプルな構造であった。圧力の伝達は油圧で行われていた。

しかし、車の制御のほとんどが電子制御になった今、先進の車ではブレーキペダルが踏まれた圧力をセンサーを使ってセンシングし電子データに変換してそのデータのデータ量をもとに電気式のポンプによって制動力をソフトウェアでコントロールしている。

ブレーキペダルとブレーキパッドは直接つながっておらず、その間にコンピュータとソフトウェアが入っているということだ。自分はソフトウェアが完璧にはならないことを知っているので、この事実は正直言って恐ろしい。ただ、恐ろしいからといっていつも車を運転しているときに不安に思っているかと言えばそうではない。いつも期待通りに動いていてくれるのでその恐れは忘れ去っている。本当に怖いと感じるのは実際に自分が問題を体感したときだろう。

昔なら、メカニカルな整備をきっちりやっていれば安心だということはユーザーにも確信があった。ブレーキの構造は教習所で教えてもらったとおり単純だったから、ユーザーと整備工場の信頼関係で安全・安心は確保できたのだ。しかし、今はメカの間にエレキとソフトが入っており、エレキはまだしもソフトは外からでは目に見えないから問題があるのかないのかはユーザーには分からない。ソフトウェアを作ったメーカーやサプライヤを信じるしかない。

さて、プリウスのブレーキ制御構造はかなり高度にできていて、電気式ポンプによる制御と運転手がペダルを踏んだときの圧力をダイレクトに伝える方法を切り替えられるようになっている。（信用できない新参メーカーが電子制御のブレーキシステムだけを搭載して、そこに怪しいソフトが入っていたらそれは本当の恐怖となるだろう）

プリウスではABSが作動した際には、この電気式ポンプで発生していた油圧から、実際にペダルを踏んだ力で発生する油圧へと切り替える制御をしていた。

その様子を説明したスライドはこちら。

なぜ、そうしたのか。

ABSが作動した際には電動ポンプやソレノイドを使った場合、ノイズや振動が発生し、従来のモデルではそうした部分に対し不満の声があったためとのこと。

→これはおそらく相当微妙な感覚で、ABSが働くときのガガガッという動作を考えればノイズも何もないだろうと思う。結果的に今回の改変でこの修正をやめたのでたいした要求ではなかったのだと考えられる。

そして本当の問題は電動ポンプの場合、軽い踏力の際にはブレーキの効きが悪くなるという感覚があるため、若干油圧を増すようにしていたことと関連している。

油圧ブレーキの場合、踏んだ力と実際の油圧はリニアに変化するのに対し、電動ポンプを使っているとブレーキの効きが悪くなる感覚がある？（回生ブレーキ＋電動ポンプになっている）ため、回生ブレーキ動作時には電動ポンプで油圧を増している。このようなソフトウェアを組み込んでおいて回生ブレーキ＋電動ポンプからユーザーダイレクトの油圧ポンプに切り替えると当たり前だが、切り替わった後で若干油圧と踏みの反発力が下がる。

だから、ABSの立ち上がりの遅れ 0.06秒は問題の本質ではなく、回生ブレーキ＋電動ポンプから油圧ポンプに切り替わったときの油圧の低下がスカッという抜け感覚を助長しているのだと思う。

油圧が低下する様子を示したスライドはこちら

【問題が発生するまでの系譜】

1. 先代プリウスでは回生ブレーキ動作中は回生ブレーキに油圧ブレーキを足して制動を制御していた。（回生協調ブレーキ）
2. 先代プリウスではABSに切り替わった際電動ポンプによる電子制御のブレーキングを行っていた。
3. 新型プリウスでは「ABSが作動時、電動ポンプで油圧を発生させていると、低速走行時にはユーザーが分かる程度の振動が発生していたため」油圧ポンプ制御に切り替えるソフトウェアの改変し、ABS動作時にはブレーキをユーザーの踏み込み力で油圧発生に伴う振動音を減らしていた。
4. しかし、新型プリウスの場合、低速でブレーキを踏むとそれまで油圧+回生を併用した状態からユーザーの踏み込み分の油圧のみにかわることで油圧が若干下がり制動力が低下してしまう。（低下するのは回生ブレーキのぶんだろうか）
5. この油圧の低下によりABSの立ち上がりの遅れ制動距離が70cm伸びる。
6. 回生協調ブレーキからABSの起動、油圧ブレーキへの切り替えが起こると油圧が低下し一瞬（感覚的には1秒くらいなのだろうか）「スカッ」というブレーキ抜けの感覚が感じられる。そのとき、スピードメーターも数km/h上がる。
7. 実際の制動には大きな影響はないが気持ちが悪いかつ、運転手に不安を与えるため、ABSに切り替わるときにも電動ブレーキのままにすることにした。（先代プリウスと同じ制御に戻した）
8. 「ABSが作動時、電動ポンプを使った場合、ノイズや振動が発生する」という問題は結果的には修正しなくても顧客満足には大きな影響を与えない程度のものだった。（予想）

2月4日の品質保証担当役員の方が記者会見で「ブレーキを踏み増せば問題ない」といったのはこの電動ポンプから油圧ポンプへの切り替えの際の油圧低下分を踏みましてくれれば同じ感覚になりますよといっているのである。問題発生のメカニズムが分かってしまうと「それはないだろう」と思うし、この圧力低下の状態はエンジニアの設計意図とは違うはずだ。より顧客満足度を高めようとして従来の枯れた制御方法から新しいソフトウェアの改変を行ったときに、油圧が低下し踏力とブレーキの効きのリニアリティが僅かながら崩れることは分かっていなかった、意識していなかったと思う。

大事なのは、そこでエンジニアを責めるのではなく、なぜ、見落としが発生するのか、見落としををなくすようにするにはどのような取り組みをしなければいけないのかを考えることだ。

残念ながら、複雑なシステムのソフトウェアを改変すると、このような分析漏れは発生する。システムやソフトウェアが複雑であればあるほどよかれと思って行ったソフトウェアの変更が悪影響をもたらす可能性は排除できない。

今回のリコール対策では、ABS作動時にメカニカルな油圧へと切り替えるシステムを廃し、従来のものと同様、ABS作動時も電動ポンプを使った油圧のままにし、こうした制動力の変化をなくしたということなので、ユーザーのためによかれと思って実施したソフトウェアの改変により問題が発生し、結果的に従来機種と同様のソフトウェアに戻しましたということになる。

酷なようだが、これはソフトウェアの変更管理的にいうとソフトウェアの変更によるデグレードだと思う。

【どうすれば同じ失敗を防ぐことはできるか】

1. クリティカルな機能や性能に関する要求分析をし、要求に優先度を付ける。
2. クリティカルな機能や性能を実現するソフトウェアの構造をできるだけシンプルにする。
3. それをモデルに示し可視化する。
4. V&V(Verification & Validation)を実施する
5. クリティカルなサブシステムへの変更時には変更の影響範囲を分析し、どのような影響があるか分析する。
6. それでも漏れと問題は発生するので、起こってしまった問題に関するデータをアーカイブして組織内で共有し、次回のソフトウェア改変時に同じような問題がないかどうかを水平展開する。

ちなみに感覚的には1～4で90%の品質が確保でき、5で97%の品質が確保でき、6で99%の品質が確保できるように思う。そして、ユーザーは1%の品質の違いを敏感に感じ取る。

ソフトウェア絡みの問題は恐ろしい。なぜなら、どんな問題でも修正すると100%現象を起こさないようにできてしまうからだ。故障率に起因する問題であれば確率が低いということで回収をしないという選択肢も取れる。

しかし、ソフトウェアの場合は発生するシチュエーションがどんなに希であっても、ソフトウェアの改変によって現象発生を0%にできるとわかれば、ユーザーは決して許してくれない。

ソフトウェアの変更容易性はソフトウェアのメリットであるとともに、機能や性能をデグレードさせる要因にもなるので最大のデメリットでもある。

そして、問題が発覚すると完璧な対応をしなければいけないので調査に時間がかかるが、対応策が分かるまで問題を公表しないと情報を隠蔽していると言われてしまう。問題があることを公開してしまうと対応策を実施するまでの猶予はあまりなく、その間エンジニアを含む関係者はフル稼働を強いられる。

そうならないようにするには余裕のあるときにきっちりと上記の1～6を実施しておくことが大事だと思う。エンジニアにとっての悲劇は1%の品質向上のためによかれと思って行ったソフトウェアの改変が、エンジニアの意志に反して逆に顧客満足を下げてしまう危険があるということである。

それを防ぐためには、品質を心配する強い意識と安全や信頼を達成するために必要なスキルの両方を備えておく必要がある。

P.S.

自分は一消費者として、企業を評価するとき不具合を起こしたかどうかではなく、不具合をどのように説明するのか、どのように再発防止に取り組むのかといった部分で評価する。

ユーザーとしては問題があったときに隠蔽せずキチンと対応してくれれば、何もないときよりも場合によっては信頼が増すことだってある。

そう考えると2月4日の記者会見の際には客観的なデータがなかったのでやや信頼を失いかけたが2月9日の会見で正直に問題発生のメカニズムをデータとともに説明してくれたので自分の中でのトヨタの信頼は高まった。今回の問題の分析と再発防止策について品質管理学会や情報処理学会などで発表してくれるとなおよいと思う。

その後、Tech-On! のサイトにとんでもなく詳しいメカニズムの解説があった。さすが日経BP。ちなみに、ソフトウェアの問題に関する考察はなかった。

Tech-On! 記事『トヨタ新型「プリウス」の不具合、快適性を高めるため油圧ブレーキの制御変更が原因』
Tech-On! 記事『プリウスのブレーキはこうなっている，汎用部品の活用で回生協調機能を低コスト化』

これらの記事を読むと、今回の問題はとてつもなく複雑化しているブレーキシステムにおいてメカとエレキとソフトの間に生まれた僅かな隙間から発生した見落としだったように思える。

ソフト絡みの問題を短絡的に考えてはいけないと主張している『セーフウェア』をやっぱり読んだ方がいいと思った。

プリウスブレーキ制御ソフト改変についての考察 （その後）

2月7日、フジテレビの夜『情報エンタメLIVEジャーナる!』で、プリウスのブレーキ問題を再現していた。テレビはすごい。現象を再現できるユーザーを捜し出したのだ。

場所は完全な雪道でスピードは30km/h くらいからゆっくり減速している状況で、カーブなどにさしかかったり、ブレーキを軽く踏んだりしたときに現象は起きる。

運転手の横に座っているカメラマンやディレクター、車を外から撮っているカメラマンにはその現象が起こったことは分からない。

運転手が「ほら、これ」といっても違いがわからないのだ。しかし、スピードメーターをプレイバックしてスローで見てみると30km/h からゆっくり減速しているのに、22km/h くらいのときに約1秒くらい数km/h くらいスピードメーターの値がアップする。これが1秒間の空白で、スカッと抜けた感覚なのだという。

20～30km/h 程度の低速走行時の雪道でブレーキを踏んだときの1秒間の抜ける感覚。確かに危険性は小さいのかもしれないが、効くはずのブレーキが一瞬でも効かない感覚はさぞ気持ち悪いだろうと想像する。

さて、2月9日に豊田社長は記者会見で、以下のように語っている。

私自身、プリウスを運転した。対策前の車は滑りやすい路面を走ると、（ブレーキを踏んでも）「抜ける」という表現が一番しっくりくる。速やかに直すのが、信頼回復の第一歩と思った。

自分自身で現象を確認するとは、さすがだと思った。ただ、正確には下記のような現象のようなので、制動距離はわずかだが長くなっているという事実はきちんととらえておく必要がある。

今回の不具合は、寒冷地の凍結路などで横滑りを防止するためＡＢＳ（アンチロック・ブレーキ・システム）が作動することでブレーキがかかりにくくなるというもの。氷の上など横滑りしやすい路面で時速２０キロメートルと低速で走行しながらブレーキを踏み込む場合、クルマが停止するまでに必要な距離が１３．６メートルと従来型プリウスよりも１割程度長くなる。従来よりも滑らかに停止できる一方で、ブレーキの立ち上がりが一瞬遅れる。

「快適性を追及しすぎた面があるかもしれない」というのはたぶん違うように思える。スカッと抜ける感覚は決して快適ではないからだ。

ただ、豊田社長が自ら記者会見にのぞみ、トヨタは「全能ではないが、失敗は必ず修正・改善してきた強い自信ある」とし、信頼回復のために全社一丸となりまい進する姿勢を強調したのはさすが並の会社ではないと思った。

新しい取り組みの中には必ず見落としや失敗はある。我々は全く新しい取り組みを行う際には、まず、ユーザーに対して大きな不利益にならないようにリスク軽減策に万全を尽くす。しかし、必ずこぼれ落ちる不具合はあるので、それが発現してしまったら修正と改善を粛々と行う。その際に反省は必要だが、くよくよしてはいけない。過去のことを考えるのではなく未来に同じ失敗を繰り返さないように再発防止の取り組みに邁進することが最も重要だ。

そのような再発防止の取り組みを続け水平展開してゆけば、技術は枯れ、信頼性・安全性は増す。ソフトウェア的に言えば堅牢な再利用資産になっていくのだ。

不具合が発見されたときはシステマティックに原因を追及し、是正・予防処置をし、再発防止策をノウハウとして蓄積し、再利用資産の構築の際にそのノウハウを使う。これによって、商品の潜在的価値が高まる。実際には、その価値をモデルや分析結果という形で可視化しないと組織の資産にはならない。トヨタの中で今回の件の再発防止策が可視化された形で組織内に蓄積されるかどうかは外側からは分からない。

業界的には分析結果を公表してくれれば再発防止に役立つのだろうが、残念ながらトヨタにその義務はない。

検証と妥当性確認は異なる

EDN Japanという雑誌に『コンプライアンステストだけでは不十分！半導体IPの検証手法』という記事が載っていた。

近年、電気回路は SoC(System On Chip) 、FPGA(Field Programmable Gate Array)上にIP(Intellectual Property) と呼ばれる電子部品を組み合わせて集積して、部品点数を減らしている。

いろいろな部品が用意されているからかなり自由なカスタマイズが可能となっている。ARMなどのCPUでさえ IP の一つとして扱われる。もう、こうなるとエレキとはいえソフトウェアと同じように自由度が高くなってきた。一度作ったら変えられないハードウェアというよりはハードとソフトの中間のようなものだ。

この記事は、完成度が高いとされる IP がコンプライアンステストと呼ばれる IP単体のテストで検証が済んでいればチップ上で期待通りに動作するかといえば「そうであるとは言えない」と言っている。

【『コンプライアンステストだけでは不十分！半導体IPの検証手法』より引用】

　何らかの標準規格に即した半導体IP（Intellectual Property）を開発したら、コンプライアンステストを実施することになる。それにより、そのIPが仕様どおりに機能するか否かを詳細に検査することができる。では、コンプライアンステストを実施しさえすれば、IP事業における最も重要な疑問に対する答えが得られるのだろうか。その疑問とは、「コンプライアンステストに合格すれば、そのIPが『チップ上で期待どおりに動作する』ことが保証されるのか」というものである。

　筆者は、長年にわたってチップ設計者にIPを提供してきた。その経験に基づいてこの疑問に答えるなら、「そうであるとは言えない」ということになる。実際、コンプライアンステストだけでは品質や性能を保証できないことを示す理由がいくつもある。

【引用終わり】

この記事はインターネットで全文公開されているので是非読んでいただきたい。

筆者は機能検証の基本的な問題やテストでは検証できない構造上のばらつきの問題などさまざまな不確定要素があるため、コンプライアンステストや相互運用性テストに合格しても、そのIPがチップ上で正しく動作することは保証できないと言っている。

コンプライアンステストでは限られた動作シナリオしかチェックされず、テストにすべての条件が含まれているわけではないとも言っている。

これは、ソフトウェアを部品化して組み合わせるときにもまったく同じことが言える。部品としてのソフトウェアは一通りのテストが実施される筈だが、それはすべてのシナリオが網羅されているとは限らない。テストカバレッジだって100%でないこともあるだろう。

だから、検証済みのソフトウェア部品を組み合わせたら、半導体IPと同じように期待通りに動かないことだってあるに違いない。シミュレーションでの結果と実際に動かしてみた結果が違うこともある。

現場の組込みソフトのインテグレータは、長年の経験からそんなことは百も承知だから、ソフトウェアを組み合わせてからが勝負だということは分かっている。分かっていないのはソフトウェアを組み上げてシステムを作り上げたことのない「部品をくっつけたら仕様通りに動くでしょ」と考える人たち、部品だけしか供給したことのない人たちだ。

しかし、ソフトウェアシステムを苦労して仕上げた経験があるエンジニアでも、ソフトウェアの複雑性が増していくと長年の勘と経験ではシステムに潜む問題を見つけられないこともある。

だからこそ、問題が起こったときはその原因を徹底的に分析して再発防止策を組織の知見として残す。これも大事な再利用資産だ。

これができるのは、システム全体を見渡せるエンジニアだけだが、システムの規模が大きくなってくると一人のエンジニアではシステム全体を見渡せなくなってくるから、システムはモデルによって可視化する必要があり、モデルレベルで安全上の問題がないかどうかを検証しないといけない。

そのとき考えるのはシステムがユーザーの本質的な要求を満たしているかどうかという視点であり、これが妥当性確認 = Validation である。

仕様を満たしているかどうかを検証する Verification と ユーザー要求を満たしているかどうかを確認する Validation を分けて考えるべきと言われる理由は、Verification は完全に実施するのは難しいため、本来の目的の妥当性を確認する Validation の視点からテストを実施することにより、ユーザーリスクを効果的に低減することができるからある。

プリウスブレーキ制御ソフト改変についての考察 （その3）

プリウスのブレーキ制御のソフト改変についての状況が徐々にわかってきた。

エンジニアはエンジニアらしく現象を客観的にロジカルに考えて、憶測の部分は憶測として断りを入れながら語っていきたい。

まず、問題を分析する前に、ABS（アンチロック・ブレーキ・システム）についておさらいしておく。

Wikipedia によれば、ABSの構造はこうだ。

1. ブレーキペダルを踏むことによって、油圧発生装置 (2) から油圧配管 (5) を通じて油圧がブレーキキャリパ (4) に伝えられ、ブレーキバッドがブレーキディスクに押し付けられて制動力が生じる。
2. 制御装置 (1)は回転センサ (3) により車輪の回転をモニターしており、他の車輪が回転しているのにこの車輪だけ回転していないことを検出するとブレーキがロックしたものと判断し、油圧発生装置 (2) から発する油圧を下げる。
3. 油圧が下がると制動力が弱くなるのでブレーキロックから復帰する。
4. ブレーキロックから復帰すると車輪の回転が生じるので制御装置 (1) は回転センサ (3) によりブレーキロックではないと判断し、油圧発生装置 (2) から発する油圧を上げ制動力を強くする。

制御装置 (1) は、この一連の操作を数ミリ秒という短時間で行うため、運転者がポンピングブレーキを行うよりも高精度な制御が可能となる。

この説明が難しいと思ったかたは、ABSが非常に分かりやすく解説されているページも見つけたのでこちらもどうぞ。

ハイブリッドではない車で油圧ブレーキ+ABSの組み合わせであれば、この説明の機能が正しく動作していており、技術も枯れているから問題はない。

つぎに今回のプリウスの問題について、正確と思われる技術的な情報を見てみよう。

以下は2010年2月5日現在の最新の情報を正確に表していると思われる記事（中日新聞）である。元ネタはトヨタの品質保証担当役員 横山裕行常務 の記者会見である。

【中日新聞：『トヨタ、ブレーキ欠陥を否定　プリウス苦情で会見』より引用】

プリウスはガソリン車と同じ「油圧ブレーキ」と、ハイブリッド車特有の「回生ブレーキ」を併用。走行状態に合わせ、自動的に車自体が最善の組み合わせを選ぶ仕組みだ。
ただ、凍結など滑りやすい路面で車体をコントロールするアンチロック・ブレーキ・システム（ＡＢＳ）が作動すると、回生ブレーキとの併用から油圧ブレーキ単独への切り替えに、時間差が生じるという。

【引用終わり】

もう一つ、朝日新聞より追加情報

【朝日新聞：『トヨタ、新型プリウス全車を無償改修へ　欠陥は認めず』より引用】

多くは、滑りやすい路面を低速で走行中、１秒前後、ブレーキが利かなくなるというもので、トヨタの調査では、車輪がロックしてハンドル操作が不能にならないようにするアンチロック・ブレーキ・システム（ＡＢＳ）の制御ソフトの問題という。

【引用終わり】

これ以外の NHKのニュース等も総合すると次のようなときに起こる現象のようだ。

回生ブレーキが効いているとき（減速中）にブレーキを踏んで油圧ブレーキに切り替えわろうとする際、たまたま路面が滑りやすい状態であるとABSを効かせる（切り替わる）のに約1秒かかる。

ここからは憶測が入る。

この問題では「回生ブレーキ」と「油圧ブレーキ」と「ABS」の3つの機能の微妙なバランスが絡み合っている。そもそも「油圧ブレーキ」単独のシステムは非常にシンプルで正しく動いていることもテストしやすい。

つぎに、「油圧ブレーキ」+「ABS」の組み合わせは冒頭のABSの仕組みを見てもらえればわかるように結構複雑であり、ソフトウェアの制御が入ってくるが、ガソリン車においてすでに枯れた技術となっている。

ハイブリッド車における「回生ブレーキ」と「油圧ブレーキ」の切り替えはさらに難しいソフトウェアの制御になっていると予想される。しかし、それが難しいのはトヨタだってホンダだって分かっていて、徹底的にテストしていたと思う。一節によると、トヨタは新しい技術の検証には5年以上かけているらしい。

だから「回生ブレーキ」と「油圧ブレーキ」の切り替えは正常に動いていて、例えば坂道で減速中に回生ブレーキが効いている状態で、運転者がブレーキを踏むとタイムラグなく油圧ブレーキに切り替わるのだろう。

同様に、「油圧ブレーキ」＋「ABS」の組み合わせもガソリン車で培った長年の技術の蓄積があるため枯れており問題はなかったのだと思う。

しかし、今回の状況は「回生ブレーキ」と「油圧ブレーキ」と「ABS」という3つの要素の境界領域の問題であり、レアなケースのように思える。ソフトウェアの機能のテストを考えるときに、一つのシステムのテストが100項目だったとする。2つの機能を組み合わせるとテストケースは1万になる。3つの機能を組み合わせるとテストケースは100万だ。100のテストはちょっと頑張れば検証可能。1万のテストはシステマティックにやならいと漏れが発生する。100万のテストはどんなに頑張っても漏れや抜けが出る。

もう一つの憶測は、「回生ブレーキ」チームと「油圧ブレーキ」チームと「ABS」チームが別々だった場合、それぞれのサブシステムの完成度は高くても、各サブシステムを組み合わせたときに想定される問題の追求には他のチームへの遠慮があるため徹底的に突っ込めない、突っ込みがあまくなる可能性だ。他のチームにケチをつける、すでに枯れていると思われるシステムをバラバラにする、疑いを持って検証のし直しを迫るのは勇気がいる。そこに遠慮があるとテストに漏れがでる可能性もある。

「回生ブレーキ」から「油圧ブレーキ」もしくは「回生ブレーキ」から「ABS」への切り替えに1秒かかるというのはあきらかに遅い。当初エンジニアが意図していた性能要求からは外れていると思う。

結果的に回生ブレーキが効いている減速中にしか、1秒の切り替えディレイが発生しないのであれば、ユーザーリスクは小さいのかもしれないが、100Km/h 以上の高速走行中に減速して回生ブレーキ中に滑りやすいところに入って思いっきりブレーキを踏んで油圧ブレーキが効くのに1秒かかったら、制動距離に変化はないとは言えないだろう。

Wikipediaによると、そもそも、ABSには下記のような注意点があるようだから、さらに問題の現象は複雑になる。

凍結路面（凍結状況によって左右される・ミラーバーンでは制動距離が延びる場合がある）や砂利道などの非舗装路面などではABSを解除した状態の方が制動距離が短くなる傾向が強い。理由の一つに、ABS作動時は一時的にせよタイヤが空転するからである。
凍結道路において乾燥路面と混在状態の時は、制動距離がABS非作動時の倍以上になることがあるので、低速走行時（時速40 km以下）においてはABSが自動的に解除される機構が必要である。

また、ABSはタイヤがロックしているかどうかを関知するセンサは最近は4輪独立しているらしいので、その点もソフトウェアを複雑化させているのかもしれない。

複雑化したシステムの境界領域の問題は、これからますます増えてくる。だからこそ、安全アーキテクチャを実践するにはシンプルな構造を目指すのが不可欠なのだが、だからといって機能を削ることは許されないのが現実だ。

ハイブリッド車において、回生ブレーキをあきらめればブレーキシステムはガソリン車と同じ構造になり枯れた再利用資産を使える。しかし、燃費向上のためには回生ブレーキも使わないといけない。安全のためにエコを捨てることは社会やユーザーが許してくれない。だからこそ、トップダウンの安全アーキテクチャ解析が必要になってくる。

ところで、ソフトウェアが絡んだリコールの問題、大企業で社会が注目しているリコールの処理の難しさは、一度改修を行ったら、同じ問題で二度三度とリコールを繰り返すことはできないということだ。そんなことをしたら信用ががた落ちになるだけでなく、マスコミから一斉に叩かれる。

だから、今トヨタと関連会社の一部のエンジニアは、この問題の検証と、これ以外にも問題がないかどうかここ数日間、徹夜で働いているに違いない。

安全や信頼は、表面に見えているところ以外にも幅広くケアしておかないと保証できないという事実をエンドユーザーやマスコミは知らない。

マスコミや評論家は何か問題が起こったときにはみんなで大騒ぎするが、同じような別な問題はないか、違うシチュエーションでは発生しないのかといった、隠れている部分を洗い出す力はない。

クリティカルデバイスに携わるエンジニアは見えないところの問題も改善する道筋をつけていかなければ、潜在的な価値（当たり前品質）を高くキープし続けることができないのだ。

サブシステムの完成度を高めても、単純にサブシステムを結合したのでは安全は保証されないということをこのブログで言い続けている。もしかしたら、今回のブレーキ問題はその例のひとつなのかもしれない。

P.S.

その後日経ものつくりにこんな記事が載っていた。

新型プリウスはABSが動作してから油圧ブレーキが作動するまでの時間が従来型に比べて若干長く，このことがドライバーに「ブレーキが利きにくい」と感じさせていたというのが同社の見解だ。同社に寄せられたブレーキが利きにくいという現象は，基本的にABS動作時にだけ起きるものだという。また，そうした現象が起きたとしても，フットブレーキを十分に踏み込めば問題なく停止できると横山氏は説明する。
改善策としてABS動作後に油圧ブレーキが動作するまでの時間を短くした。

• 若干が1秒だとしたら長い。人間が我慢できるレスポンスの限界はだいたい500ms。
• たぶん、回生ブレーキ動作中でない場合は反応が早い
• ABSはロックしないための機能だから、ABSの動作と油圧ブレーキの作動は同じ事を意味しているはず。正確に言うと、回生ブレーキがかかっているときにABSが動作するまで1秒かかっていたので、その時間を短くした？
• ソフト修正前と後では制動距離が異なるのではないだろうか？ ソフトの修正で制動距離が短くなっているのなら・・・

さらに、こちらの記事（一番参考になる）によると、ブレーキの踏み加減によってABSの効かせ方を調節している可能性がある。結果的には、単純な単機能の油圧のディスクブレーキの時代から比べたら遙かに複雑なソフトウェア制御の時代に変わっており、安全アーキテクチャ分析をしないと安全は確保できないところまで来ているということだろう。MISRA-SA （MISRA Safety Analysis）の出番かもしれない。

プリウスの場合は低速でブレーキを踏むと回生ブレーキのみで制動する。（この時油圧ブレーキは作動していない）
その状態でABSが作動するような状態になると、回生ブレーキを切って油圧ブレーキに切り換えABSを作動させるんだが、この切り替えに1秒程度かかる。すなわちその1秒間は何のブレーキも効いていない状態になる。

という記事も発見。回生ブレーキが作動する低速というのがどれくらいのスピードまでかが問題。回生ブレーキになる最大のスピードでの1秒間でどれくらい制動距離が伸び、ABSが働くのに時間がかかることで車の姿勢が崩れないのか否か。

プリウスブレーキ制御ソフト改変についての考察 （つづき）

『プリウスブレーキ制御ソフト改変についての考察』の記事で、情報が確定していないのでトヨタを養護するようなことを書いたら、その後、記者会見があったらしく次のようなニュースが流れた。

【中日新聞：『新型プリウス無料改修　先月下旬まで販売分』より引用】

トヨタ自動車のハイブリッド車「プリウス」の最新モデルに顧客の苦情が相次いでいる問題で、トヨタは４日、２００９年５月の発売から１０年１月下旬に国内で販売した車両を対象に、ブレーキ制御のコンピューターを改良ソフトに書き換える無料改修を実施する方針を明らかにした。同日午後に会見、これらの対応を説明する。
車両欠陥によるリコール（無料の回収・修理）ではなく、顧客からの要望に応じるサービスの位置付けで、苦情が多い米国でも同じ対応を検討する。トヨタは改修の理由を、ブレーキ時のタイヤロックなどを防ぐ「アンチロックブレーキシステム（ＡＢＳ）」の作動時に「油圧の立ち上がりが一瞬遅れるため」と説明している。

【引用終わり】

このニュースから読み取れるのは、

・ABSの「油圧の立ち上がりが一瞬遅れる」問題があった。
・この問題を解決するためにソフトウェアを改良した。
・車両欠陥ではない→ユーザーリスクはない（もしくはリスクはあるが受容できるレベルである）

ということのようだ。「油圧の立ち上がりが一瞬遅れる」ことがリスクにつながらないかどうか、受容できるレベルかどうかは、これだけの情報ではわからない。

いろいろ憶測するよりも正しい情報が発信されるのを待った方がよさそうだ。もしも、回生ブレーキサブシステムと油圧ブレーキサブシステムとABS機能を統合したのであれば、安全アーキテクチャの分析の問題になると思う。

プリウスブレーキ制御ソフト改変についての考察

トヨタ製自動車の品質問題が話題になっている。ブレーキペダルの件はメカ、部品、材質の問題だが、ブレーキ制御の問題はソフトウェアが絡んでいると思うので、この問題をどうとらえるべきかについて自分の考えを書こうと思う。

【実際のところどうなっているのか？】

この手の技術がからむ、特にソフトウェアが絡む問題の報道は不正確なことが多い。特にセンセーショナルな記事で読者を引きつけたいという潜在意識を持っている記者は、悪者を仕立てて責任を追及するような記事を書く。

自分はいろいろな記事を眺めてみたが、“「ブレーキが一時的に利かなくなることがある」など、ブレーキの不具合を伝える苦情が１９０件以上に上っていたことが３日、分かった”ということと、「構造上の問題なのか、使い方の問題なのか一つ一つ検証している。今年に入って製造した車は、すでにブレーキのシステムを調整して改善した」ということを並べて書いて、ブレーキに欠陥があってそれをトヨタが黙って直したかのように思わせる流れにしている。

本当にそうだとしたら問題であり、そのようなユーザーの利益を一番に考えない姿勢と、そのような問題が起きたときの技術的な対応の仕方についてブログを書こうと思った。

ところが、いくつもの記事やニュースを聞いて見ると1月のソフトウェアの改変は技術的には次のようなことだったように報じているものもある。

【トヨタ：国に報告「先月改善」　新型プリウス、ＡＢＳを修正より引用】

調整したのは、スリップしやすい路面で、ブレーキと解除を繰り返すＡＢＳ（アンチロック・ブレーキ・システム）のコンピューター。旧型に比べ、ブレーキが解除されている時間が若干長く、運転者に違和感を与えていたことが分かり、解除時間を短くするよう修正したという。

【引用おわり】

これが本当なら、自分は今回の修正は不具合ではない可能性がかなり高く、「ブレーキが一時的に利かなくなることがある」というユーザーの意見とソフトウェアの修正を結びつけて、あたかも欠陥があったかのように報道している記事は事態を正確に伝えていないと感じる。

エンジニアの方はよくご存じのとおりABS（アンチロック・ブレーキ・システム）は、ブレーキをかける、解除するを短い時間で繰り返すことで、タイヤがロックして車が滑ったり、スピンしたりするのを防ぐ機能だ。

ABSがないとき、雪国のドライバーはこの動作を運転手自身がブレーキを踏んだりゆるめたりしてロックしないようにしていた。

現在のほとんどの車にはABSが付いているので、雪道で思いっきりブレーキを踏むと「ガガガッと」ABSが作動し最短の距離で車がスピンせずに止まってくれる。

これはブレーキをかける、解除するを非常に早い時間間隔でコンピュータ制御によって繰り返している。おそらく、1月のソフトウェア変更は、プリウスのABSのブレーキをかける、解除するという間隔が他の車種よりもやや長めに設定していた、もしくは同じ間隔だったものを、間隔を短くしたのだろう。もし、そうであれば、「ブレーキが一時的に利かなくなることがある」という問題とはまったく関係ない修正である可能性が高い。

ABSという機能自体が「ブレーキを一時的に解除することで、タイヤロックを防ぐ機能」であるからだ。ABSが搭載されていない車種で、ドライバーがABSの機能と同じ事をやる場合、隣に乗っている教官が、「もっと早く踏んだり、ゆるめたりしろ」と叫ぶ。結果的に制動距離はほとんどかわらなかったら、それはフィーリングの問題だ。

だから、もしトヨタが ABS のソフトウェアを修正をしたのであれば、その修正をする前と後で制動距離がどれくらい変わったのかという実験データを公表し、制動という基本性能には影響を与えない改変であったことを示せばいいと思う。

【回生ブレーキと油圧ブレーキの組み合わせによる問題？】

エンジンとモーターを併用して走るＨＶは、通常の油圧ブレーキに加え、減速時に発電・充電するための回生ブレーキを備えており、２つのブレーキの切り替えに何らかの問題があるのではとの見方もある。

という記事もあった。回生ブレーキとはガソリン車でいうところの坂道でわざとギヤをローにすることで制動がかかるエンジンブレーキのようなものだと認識している。油圧ブレーキを使わずに、モータを回すことで減速しこのときに発電・充電する仕組みだ。これをやらない場合は油圧ブレーキによってエネルギーは熱になって消えてなくなるためエコにならない。

素人が考えるに、回生ブレーキは油圧ブレーキよりもレスポンスが悪い。回生ブレーキと油圧ブレーキをソフトウェアで切り替えているとしたら、そこにはリスクが潜んでいる可能性がある。急いで車を停めたいときはエコが大事などといっている場合じゃないから、油圧ブレーキを使う。時間をかけて減速すればいいときは回生ブレーキを使えばエネルギーが無駄にならない。

この切り替えを車速で切り替えているとしたら、ある程度のスピードで走っていてブレーキを踏めば油圧ブレーキが作動するようにソフトウェアを制御するだろう。ブレーキが踏み込まれるときの速さ、時間間隔で判断するのかもしれない。

一方、低速走行中は回生ブレーキと油圧ブレーキのバランスが微妙だとすると、雪道や砂利道など滑りやすい状況であれば、切り替えの遅れが追突を生む危険がある。

1月のプリウスのソフトウェアの改変が、回生ブレーキと油圧ブレーキの切り替え制御を調整する変更だったとしたら、その部分の検証が十分でなかった可能性はある。

【ソフトウェアが絡んだ事故が起こったときのメーカーの対応について】

ソフトウェアが絡んだ事故が起こったときのメーカーの対応方法はセオリーがある。

1. 被害の重要度（ランク）を品質保証部門が客観的に判断する。判断基準をあらかじめ作っておくとよい。
2. 原因を調べる。
3. 被害の重要度に応じてリコールをするか否か判断する。（この判断が非常に難しい）
4. リコールを行うと決めた場合は情報を開示して、改修の作業を行う
5. 再発防止策を策定し、組織の中で水平展開する
6. 是正・予防処置が行われているかどうかを監視する

このような品質保証の対応をするときのポイントは、感情を入れないでシステマティックに粛々とやることだ。日本人には恥の文化があるので、失敗は恥ずかしいと思い恥ずかしい思いをしたくない、恥をさらしたくないという心理が働くことが多い。

しかし、エンドユーザーの利益を最大に考えるのであれば、恥をかなぐり捨てて、というよりは恥だなどとは考えずに淡々と処理をして、是正・予防処置に力を入れることが重要だ。そうしないと、エンジニアは問題や問題に結びつく予兆を隠蔽するようになる。そのような隠蔽は結果的に組織を弱体化させ、商品の品質を押し下げることにつながる。

そして、不当な非難に対しては毅然として立ち向かい自分達の正当性を主張すべきだである。ただ、白黒はっきりしないケースが多いので、白い部分は白、黒い部分は黒、グレーの部分はグレーと正直に言わなけばいけない。

そして、ソフトウェア特有の問題としてはハードウェアの部品のように故障率が低いことを根拠に危険が少ないことを主張することのは難しいという点がある。

仮に20万台の出荷に対して200件に問題があったとする。部品の故障率で言えば 1/1000 の確率だ。ソフトウェアの場合「1000回に一回しか発生しないので大丈夫ですよ」とは言えない。なぜなら、ソフトウェアの場合はアップグレードすることよって確実に確率を 0% にすることができるからだ。改善できることを知りながら実施しない場合確信犯だと言われてしまう。

このようなソフトウェアに起因する不具合を確か Systematic Error と呼んでいたと思う。普段簡単にはユーザーが行わないような手順でしか発生しない不具合でもソフトウェアに起因する場合は、その手順を実施すると 100% の再現率で不具合を起こせる。

これを放っておいていいんですかと言われたら、直そうか直すまいか迷うだろう。だからこそ、ソフトウェアが起因する不具合は、それによって生じるユーザーリスクの大きさによってのみ対応を決めるべきなのだ。確率が低いかどうかは考えてはいけない。

【部品の信頼性はシステムの安全性を保証しない】

機能安全の国際規格 IEC 61508 の車向け規格 ISO 26262  がまだ正式に発行されてもいないのにちまたで話題になっている。機能安全の世界で、暗に部品の信頼性を高めることがシステムの安全につながるという方向に持って行こうとしている人たちがいるように聞いたことがあるが、それは間違いであり非常に危険な考え方だと思う。

なぜなら、完璧な回生ブレーキサブシステムと、完璧な油圧ブレーキサブシステムは、それらを組み合わせてハイブリッド車としてのブレーキシステムとしても安全とはいえないからだ。

回生ブレーキシステムと油圧ブレーキシステムを作ってしまってから、それらを切り替えるソフトウェアを考えるのでは遅いし、順番が逆である。ブレーキに求められる本質的な機能と性能(Essential Performance)を分析し、それを満たすために回生ブレーキと油圧ブレーキを使う場合どんなリスクがあるかを考え、リスクが最少になるためにはどのようなアーキテクチャが必要か、どんなリスクコントロール手段があるかを考える。

安全アーキテクチャにボトムアップはない。商品から見たトップダウンのアプローチが絶対に必要だ。再発防止もトップダウンで考えないと有効ではない。

【日本の安全分析の弱さ】

事故が起こったとき再発防止の効果を上げるためには、第三者による調査と情報の開示、水平展開が大事である。ソフトウェアは見えにくいので調査が難しいし、何か起こったときにメーカーが再発防止の情報を自ら開示するのは現実的ではない。なぜなら、再発防止策自体がその組織のコア資産になるからだ。

だから、事故調査と情報の開示、水平展開の取り組みは国が主導して行う必要がある。日本の役所には研究者がほとんどいないので、そのような取り組みが苦手である。

だったら、産総研のような独立行政法人がこのような事故調査と再発防止案を業界全体に提示するようなことをやったらいいと思う。

メーカーも自組織だけでなく、業界全体の利益を考える度量があるのなら、新しい技術領域において分かったリスクとリスクコントロール手段については積極的に情報を開示して欲しいと思う。

その行為こそがエンドユーザーの信頼を得るのだと感じる。