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

(トヨタは社長と副社長が 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 の視点からテストを実施することにより、ユーザーリスクを効果的に低減することができるからある。