機能安全の意味がわかった(IEC61508とISO26262の最新情報）

クルマ関係の仕事をしている技術者は日経エレクトロニクス　2011.1.10 の特集記事『クルマの電子安全始まる-ISO26262を越えて-』を必ず読んでほしい。

機能安全規格IEC61508と自動車の電子制御系に関する安全規格ISO26262の概念について詳しく解説されている。

自分自身、機能安全ということばがどうしてもすっきり理解できずもやもやしていたが、この記事を読んですっきりした。

だいたい、「機能」と「安全」の結びつきが直感的にイメージできない。Safety は functional ではない、安全は機能的に実現するのではなく、あらゆる使用環境、ハザードを想定してシステム全体で確保するものだと思っていたから、どうしても機能安全(functional safety)ということばがしっくりきていなかった。その疑問点をこの特集記事はクリアにしてくれている。

この記事がいいところは規格の内容を解説するだけでなく、規格の策定メンバーにインタビューして規格が作られた時代背景や思惑にまで突っ込んで書かれてところだ。

【日経エレクトロニクス 2011.1.10 p44　機能安全、素朴な疑問より引用】

機能安全(functional safety)の「機能」とは、制御対象（プラント、EUC: equipment under control)や制御器（コントローラ）を監視する安全装置の役割のことを意味します。通常、安全装置（安全関連系(SRS: safety-related system)にはコンピュータが使われ、いざ制御器に故障などが発生した場合は、このコンピュータが制御対象を停止したり、ユーザーに警告を出したりします。安全装置があることによって実現されているこうした安全性のことを、特に「機能安全」と呼んでいます。機能安全とは、いわばマイコンなどを使った安全装置による安全対策といえます。なお、安全性そのものは、こうした電子的な安全装置の付加によって担保するだけでなく、危機源（ハザード）そのものの設計上の除去（本質安全）や、危機構造的なフィルセーフ機構（構造安全）などによっても担保するのが一般的です。機能安全によって実現できる安全性は、包括的な安全性の、あくまでも一部でしかないといえます。IEC自身も機能安全について、「Functional safety is the part of the overall safety」と明記しています。

【引用終わり】

この特集記事には IEC61508策定時の裏話が書かれている。 IEC61508 はバックグラウンドとなる理論的体系や支柱がほとんどないまま、1990年代初頭に「ともかくPLCなどの電子的な安全装置に関する規格を作らねば」という欧州企業の意向によって策定が始まったというのだ。そして、根拠は後付けでいいからというスタンスが強かったという。何からの裏付けや蓄積を経た上で策定される通常の規格とは真逆の順序で作られたらしい。

機能安全規格のIEC61508と特に強く批判してきたのが、米国を中心とする安全の専門家やソフトウェア工学の専門家だという。ソフトウェアの安全設計の権威であるMITのナンシー・レブソン教授がIEC61508に批判的だというのは知っていたが、米国の多くの専門家が批判的だというのは知らなかった。

IEC61508に対する批判は主に次の4点に集約されている。

1. 安全性の規格でありながら、定量的な故障検出率といった確率論に重きを置きすぎている。
2. 故障率低減のための複雑な機構の導入が、かえってシステム全体の安全性を損なう危険性に配慮していない。
3. 部品ごとに安全性の認証を与え、認証を得た部品の採用によって安全を担保しようとしている。
4. バックグラウンドとなる理論的体系や支柱がなく、規格が膨大で分かりにくい。

あー、それだ。そう、何年も前から自分はこの規格を読んでいてそう思っていたのだ。特に3つめの部品単位での安全性の認証のところ。日経エレの進藤記者、分かりやすく明確に書いてくれてありがとう。この記事読んでいて「がってん」ボタンを何回も押してしまったよ。

さて、IEC61508はそもそも、化学プラント、原子力産業、工作機械などの産業用機器を対象に作られた。だからそこ、ハザード事象が発現したときに、安全装置があることによって実現されているこうした安全性のことを「機能安全」と言ったのだ。

機能安全の説明でよく踏切の例が挙げられる。踏切ではなく高架橋を作ることによって通行者の安全を確保するのが本質安全で、踏切という安全装置によって安全を確保するのが機能安全。

ちなみに、自分がこの機能安全ということばに違和感を覚え続けていたのは、日頃から安全の確保はハザード分析やリスク分析から始まるということが当たり前だと思っていたからだ。

システムを取り巻く環境にあるハザードやリスクを分析して、それらのリスクを受容できるまで低減するのことが重要と教わってきた。リスクを軽減するための手段は、設計上の対策かもしれないし、表記上の対策かもしれないが、手段が先になることはない。

機能安全の規格は安全装置によって安全を確保する狭義の Safety という意味合いが強いということがこの記事を読んでよく分かった。本質安全に対する安全装置による安全（=機能安全）と考えると非常にすっきりする。

そして、安全は安全装置の設置という狭い考えではなく、システム全体を踏まえた包括的な安全性の実現を考える必要がある。

折しも、昨日今日とWOCS 2011（クリティカルソフトウェアワークショップ）が開催され、MITのナンシー・レブソン教授が基調講演に登壇された。その後、トヨタ自動車の川名氏、電通大の西氏、JAXAの片平氏も含めて、口々に「認証されたツールや部品を組み合わせることで安全を確保できると思ってはいけない」と語っていた。

なお、日経エレの特集記事を読んでいただければ分かるように ISO26262 は　IEC61508の問題点をアンチテーゼとして、クルマドメインに合うようにかなりカスタマイズしている。

ISO26262がDIS（Draft International Standard）と呼ばれるドラフト段階のときに、「リスクの高いコンポーネントは形式手法を強く推奨する」という記述があった。これを見た、ツールベンダーや規格認証機関は「形式手法は絶対に使わないといけない」というニュアンスをクルマドメインの人たちに伝え恐怖をあおった。

ところが、FDIS（Final Draft International Standard）では、選択肢を複数に増やしてかつ、代替えの方法でも可という表現に変わっている。わざわざそうしたのは、ソフトウェア部品の信頼性を高めることがシステム全体の安全につながるかのような誤解が開発の現場に蔓延するのをなんとか防ごうとしたからである。

このように ISO26262 は IEC61508で指摘された問題点の多くを積極的に改善してきている。規格の策定委員の一人であるトヨタ自動車の川名氏は「選択肢が増え曖昧さが加味されたことによって骨抜きになったと思う人もいるかもしれない」とWOCS2011で語っていたが、そんなことはない。技術者が「安全を確保するのはどうしたらいいのか」「自分達がやってきた方法は安全にどれくらい寄与しているのか」と正面から考えるきっかけを作ったくれたのだ。

そうではなくて、形式手法を使えばよいとか、規格認証を取れたツールを使ったり、プロセス認証を取ったサプライヤーにソフトウェアを開発委託すれば、安全なシステムを作れるなどと考える者を減らすのを助けてくれたのだと考えて欲しい。

自分は、システムの安全を考えるときには、必ずどんなリスクを回避しようとしているのかを常に思い浮かべて欲しいと思う。例えばクルマなら次のようなことだ。

• 衝突したのにエアバッグが開かない
• 衝突回避のための超音波センサに泥が付いた。
• パワーウインドウに子供の手や首が挟まった。
• エンジンがオーバーヒートしたらどんなときにも止めていいか。
• バッテリ切れのときにブレーキは働くか。

上記のようなリスクを回避するのに、形式手法やメモリ保護、カバレッジ100%のテストはプラスの効果を与えると思うが、安全を確保できているという確固たる根拠にはならない。安全を確保するには想定したリスクをどのようにして安全設計によって回避できるのかを説明しなければいけない。

ソフトウェアは電子部品のようにランダムな故障はしない。Systematic Failure （決定論的故障） といった問題の起こし方をする。想定しきれなかった、テストしきれなかったバグによって問題は起こる。そのようなバグを完全にゼロにすることはソフトウェアの場合困難であると認識しつつ、ハザードが発現しないためにはどうしたらよいのかを考え、できるだけ完全に近づけようと努力する。

日本のソフトウェア技術者は世界でも最高レベルの品質を持つ製品を世に送り出してきたのだから、なぜ、それができたのかをよく考えて、その強み・ノウハウを殺すことなく、グローバルな世界に対して説明責任も果たせるようにならないといけない。

規格の翻弄されるのではなく、自分達が安全を実現するためにやっていることを規格を使ってどうどうと説明するにはどうしたらよいかを考えればよい。

ソフトウェア品質を高く保つには哲学が必要

前回の記事『商品リスクを低減するには哲学的思考が必要』に関して、もう一回同じようなことを書いた文章がありますので、ご一読ください。

誰がどこに書いた文章かはご想像にお任せします。

------
明治大学理工学部に向殿政男先生という方がいます。

著書のひとつ『安全設計の基本概念』

向殿 政男
1965年明治大学工学部電気工学科卒業。1967年明治大学大学院工学研究科電気工学専攻修士課程修了。1970年明治大学大学院工学研究科電気工学専攻博士課程修了。明治大学工学部電気工学科専任講師。1973年明治大学工学部電気工学科助教授。1978年明治大学工学部電子通信工学科教授。2005年経済産業大臣表彰受賞(工業標準化功労者)。2006年厚生労働大臣表彰受賞(功労賞)。明治大学理工学部情報科学科教授。明治大学理工学部学部長。明治大学大学院理工学研究科委員長。ISO/TC 199国内審議委員会委員(元主査)。安全技術応用研究会会長。機械の包括的な安全基準に関する指針の改正のための検討委員会委員長。次世代ロボット安全性確保ガイドライン検討委員会委員長ほか(本データはこの書籍が刊行された当時に掲載されていたものです)

その、向殿先生が、日経ものづくり 8月号 で日本のものづくりの歴史的背景を次のように語っています。

【日経ものづくり 8月号 特集 ソフトが揺さぶる製品安全より引用】

信頼性一本やりでは厳しい

明治大学理工学部情報科学課教授の向殿政男氏によれば、そもそも日本の企業は、信頼性を高めることで安全を確保しようとする傾向が強いという。しかし、前述の流れに従えば、そうした考え方は特に修正を迫られることになりそうだ。

「信頼性を高めることで安全を確保する」とは、製品を構成している個々の要素の信頼性をひたすら高めることによって、異常事態が発生する可能性をゼロに近づけようとする考え方である。構成要素に故障がバグがあることは前提としないので、これは「フォールト・アボイダンス」と呼ぶ考え方だといえる。

日本の企業はこれまで、この考え方で実績を積み上げてきた。「日本製品は壊れにくい」という評価は、まさにこのフォールト・アボイダンスを追求してきたたまものといえる。もともと日本の製造業は、欧米で確立された製品の改良設計で成長してきたという経緯がある。製品全体のアーキテクチャが所与の中、改良設計という形で信頼性を高めることに力を注いできたのは、ある意味必然だった。

さらに向殿氏は、信頼性は定量的・純技術的な概念であり、技術者にとって扱いやすい指標だったことも、日本の企業がフォールト・アボイダンスに傾倒した理由に挙げる。「安全を定義するには、社会が許容するリスクとは何かといったことも考えなければならないので、どうしても哲学的な判断が必要になる。それに比べると、信頼性は技術者にとってとっつきやすい概念だった」（同氏）。

だが、ソフトの役割が増すにつれ、フォールト・アボイダンスだけで安全を確保するのは厳しくなってきた。前述の通り、ソフト自体の信頼性を高めるのが困難な上、ソフトやハードといった構成要素同士の関係も複雑になっていることから、構成要素の故障やミスを認めない前提そのものに無理が生じているのだ。

そもそも信頼性（壊れにくいこと）と安全は全く異なる概念である。だが、前述のような経緯から、信頼性を高めることと安全を確保することがほとんど同じ意味になってしまっていたのである。

【引用終わり】

この「今後の安全設計には全体最適の発想が必要であり、安全を定義するには社会が許容するリスクとは何かを組織が考えなければならず、そのためには哲学的判断がいる」、というところに強く共感します。

ようするに、ユーザーリスクとその対策は考えれば考えるほど際限がないので、コストや開発時間とのトレードオフでどこまでやるかを決断しなければならず、その決断をするためには安全や品質に対する哲学が必要だということです。

安全や信頼を実現している「当たり前品質」は、カタログやスペックシートには現れないため、長い間商品を使ってもらったときにお客様から伝わってくる「品質がいいね」という感想や、クレームの少なさなどでしか表面に現れてきません。

クリティカルデバイスではそこが命でもあるので、技術者は当たり前に出来ていることの重要性や、リスクを軽減する対策の大切さは言われなくても分かっていました。

それが、近年、リスク分析の結果や取扱説明書を見ていると、表記上の対策で禁忌・禁止事項として書いておけば、設計上の対策はいいやという技術者が増えてきたようにも感じています。そうなってきた理由のひとつは商品が実際に使われる現場の現実を知らない技術者が増えてきたからでもあります。

これだけ複雑化してしまった製品ソフトウェアに対して、安全に対して哲学を持ってどこまでやるかを決断しなければならなくなっているのです。逆に言うと製品の品質や安全に対して無知であったり、哲学（ポリシー）がない技術者が作る商品、ソフトウェアは危険であると言えます。

そして、技術者に哲学（ポリシー）があっても、組織の上位層に安全や品質に対する哲学がなく、商品のリリースの時期だけを何とかしろと言い、技術者の哲学（ポリシー）がポキッと折れてしまったり、考えてもどうにもならず辛いので考えないようにしている人はいると思っています。

簡単に言えば次のような質問に間髪入れずにはっきり答えられる技術者が少なくなってきていると思うのです。

・自分の商品の品質に自信があるか？
・自信の根拠は何か？

これらを聞くと怒り出す技術者はまだましで、しれっと「自分の守備範囲ではないんで」などと言う人が出てきたらもうおしまい。

そういう人たちで構成された組織において、製品の信頼や安全はプロセスや組織的システムのみで確保しなければならず、そのためには責任と権限が明確な組織的階層構造と徹底的な設計管理が必要です。

そうでない、プロセスやシステムだけで日々の仕事をやっているんじゃない組織において、もし、安全や信頼について自信をもって答えられる技術者、管理者が少なくなっているのだとすると、機器やサービスの安全や品質に対する哲学が個人個人に対しても、プロジェクト、部門にも必要です。

安全や信頼に関する哲学が、すでに組織の中に醸成されているのなら、職制で指揮命令するだけで高品質を維持できるかもしれませんが、安全や信頼に関する哲学が醸成されていない、廃れてしまったのなら意識改革から始めなければ高品質は達成できないと考えます。

これはロジックではなく、哲学やポリシーの問題です。なぜなら、当たり前品質という見えない品質を実現するために、どこまでやるかは常に自分との戦いであり、他人から言われた通りにするだけなら、納期のプレッシャーに負けて、品質は低い方向に傾くからです。

「開発が遅れているかどうか」を聞くのもいいですが、それと同じかそれ以上の熱意、頻度で「自分の商品の品質に自信があるか？」と問う人が増えないと高品質を維持していくのはムリだと思います。

以上

商品リスクを低減するには哲学的思考が必要

日経ものづくり 2010年8月号 の特集記事『ソフトが揺さぶる製品安全』の中で明治大学理工学部情報科学科教授の向殿政男氏が次のように語っている。

日本の企業はこれまで、この考え方で実績を積み上げてきた。「日本製品は壊れにくい」という評価は、まさにこのフォールト・アボイダンスを追求してきたたまものといえる。もともと日本の製造業は、欧米で確立された製品の改良設計で成長してきたという経緯がある。製品全体のアーキテクチャが所与の中、改良設計という形で信頼性を高めることに力を注いできたのは、ある意味必然だった。

さらに向殿氏は、信頼性は定量的・純技術的な概念であり、技術者にとって扱いやすい指標だったことも、日本の企業がフォールト・アボイダンスに傾倒した理由に挙げる。「安全を定義するには、社会が許容するリスクとは何かといったことも考えなければならないので、どうしても哲学的な判断が必要になる。それに比べると、信頼性は技術者にとってとっつきやすい概念だった」

この、「哲学的」というキーワードを見て「なるほど」と思った。もしかすると、これまでなぜソフトウェア開発やソフトウェア品質がなかなかよくならないのか、それはソフトウェア開発には哲学的な判断が必要なのに、それをしない、できない人が増えているからだと思った。

なぜ、ソフトウェアと哲学が関係するのか。安全を定義するには、社会が許容するリスクとは何かを考えそこに線を引かなければならない。商品やサービスの周りにはリスクが無限に存在する。

悪意を持った行為を含む Abnormal Use を除いても、誤使用(Use Error), うっかりミス(Slip), 過失(Lapse), 誤り(Mistake) は必ず起こる。

それらのリスクに対してどこまで企業は対処すべきか。リスクの基となるハザードは危害に発展しなければ表面化しない。だからこそ、作る側と使う側で認識のギャップが生まれる。

正しい使用と異常な使用の間にはグレーゾーン（メーカーが考える正しさ、異常さと、ユーザーが考える正しさ、異常さのギャップ）が存在する。

このグレーゾーンをメーカーが都合のよい解釈で広げていくと、ハザードが危害になる危険性が高まる。メーカーは製造物責任を回避するために大量の警告や注意を取扱説明書に記載することよって、責任を回避できると思いがちだが、世の中はそう甘くはない。

ユーザーが取扱説明書を読まずに禁忌事項を実施した場合は、事故の発生はユーザー側に責任があるから、メーカーは製造物責任を問われることはない。しかし、社会通念上、多くの人の認識と合わないような要求を製品の利用者に強いている場合、適正なラベリングを行っていなければ、製造業者は社会的責任を追求される。

ようするににニュースになるような事故が起こると表記上の対策で刑事責任は逃れられても、設計上の対策=リスクコントロール手段を実装していなけば世間が許してくれず信用ががた落ちになり、企業の対応によっては市場から No を突きつけられるということだ。

そうなると、企業はユーザーの安全のためにグレーゾーンのどこに線を引くのか決断しなければならない。これはそんなに簡単なことではない。数式で計算できるようなものでもない。

その組織やそのプロジェクト、その技術者のポリシーに寄るところが大きい。組織的なポリシーが確立されていれば、商品間、サービス間でのばらつきは少ない。プロジェクトや技術者個人に依存していてば、そのプロジェクトやその技術者が関わった製品のみグレーゾーンのユーザー部分が小さいことになる。

リスクを起こさない仕組み=リスクコントロール手段を実装するにはコストがかかる。ソフトウェアで実施する場合、材料費はかからないが分析や実装の時間を要する。ソフトウェアは常に納期を迫れれているから、納期とのトレードオフでリスクコントロール手段は省略される危険性があり、ソフトは見えにくいので省略してもその事実を確認しにくいという特徴がある。

障害の発生確率が低ければ「どうせ、そんなこと起こらないよ」という気持ちになり、対策を実装しない技術者がいても不思議ではない。そして、障害の発生確率が高くても、納期が迫っていると「どうせ、そんなこと起こらないよ」と考えたい悪魔の気持ちが大きくなっていく。

悪魔の気持ちを抑えるのが、エンジニアの倫理観であり、組織の品質保証の仕組みである。エンジニアの倫理観は、哲学的な思考で鍛えられると自分は思っている。何も考えていなければ、エンジニアの倫理観は醸成されない。1か0ではない物事に対して、何が正しいのか、何を持って正しいと考えるのかについて深く掘り下げていくことで、哲学的な思考能力は高まると思う。

そうなると、前述のグレーゾーンをユーザーのリスクを最小限にするためにかかる工数（行為）と納期やコストとのトレードオフをする際に、なぜ自分または自分たちはその選択をしたのか自信を持って言えるようになる。

それが言えないのなら、その人は組織の言われた通りにものづくりをしているだけなのであって、グレーゾーンはメーカーの都合のよい解釈になっている可能性が高い。

その危険を組織で抑えるか、エンジニアのコンプライアンス教育で抑えるのか、それとも両方かを選択するのは自由だが、技術者がやりたいようにものづくりする方がいいものができると考えているプロジェクトほど、エンジニアの哲学的思考能力は高くないと安全で信頼できる商品は作れない。

自分自身はマイケル・サンデル先生の『これからの「正義」の話をしよう――いまを生き延びるための哲学』と読んで、哲学的思考能力を高めようとしている。

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

日経ものづくりはソフトウェアには関係ないと思っている人も日経ものづくり8月号は単品(1400円）でも買った方がよい。

なぜなら、プリウスのブレーキ制御問題について、これまでになく詳細な情報が掲載されており、問題がなぜ起こったのかを推察できるからだ。

詳しくは 日経ものづくり8月号の特集記事『ソフトが揺さぶる製品安全』を読んでいただくとして、この記事のコラム「プリウスに見る、ソフトの落とし穴」の感想を書いてみたい。

まず、このブログの『プリウスブレーキ制御ソフト改変についての考察』の記事でも書いたように、何しろプリウスのブレーキシステムは非常に複雑だ。

これはプリウスだからではなく、現在のハイブリッド車はみな、このように複雑な制御でブレーキの機能や性能を実現しているのだと思う。

何が複雑化というとざっとこんなところだ。

• そもそもブレーキペダルを踏むとブレーキオイルの圧力が伝達されブレーキパッドを押し当てると思ったら大間違い。ブレーキペダルとブレーキパッドの間にはさまざまな構造物が間に入っている。
• ブレーキペダルを踏むとピストンのような油圧ブースターを押すような構造になっている。
• ピストンも密閉されているのではなく、リザーバタンクからブレーキオイルが補給されるようになっており、アキュームレータとポンプが接続されていて、ブレーキの圧力をモータとポンプの制御で高めることができる。
• ブレーキオイルの圧力はストローク・シミュレータに送られて、ここでドライバが要求する制動力とペダルに対する反力を計算している。
• ようするにドライバがあたかも、ブレーキペダルとブレーキパッドが直につながっているような感覚になるように、油圧を制御しているのだ。
• 強く踏めばブレーキは強く効き、弱く踏めば弱く効く。そこにタイムラグ（例えば0.5秒）があればドライバは強い違和感を感じるので、ハードリアルタイムの制御が必要となる。

日経ものづくりに掲載されているプリウスのブレーキシステムの構造図を眺めていると、ブレーキががこんなに複雑な構造になっていることに恐ろしさを感じる。車メーカーに全幅の信頼を寄せられなければ恐くて車には乗ってられない。個人的には、電気自動車の時代になっても新規参入してきた会社の車には10年間は乗りたくないと思う。それくらいソフトウェア制御が絡む複雑なブレーキシステムにはノウハウがないと危ないと直感する。

さて、プリウスのブレーキ問題は低速走行で緩やかに減速しているときにアンチロック・ブレーキ・システム(ABS）が動作すると、一瞬制動力が低下し、その結果、制動距離が延びる、または、運転手がペダルを踏み増さなければいけないという問題だった。

この問題が起こった流れを書くと次のようになる。

【新型プリウスのブレーキ問題が起こった背景】

1. プリウスは燃費を稼ぐために回生ブレーキを利用しジェネレータを回して発電する。（エンジンブレーキのようなもの）
2. しかし、回生ブレーキの制動力は弱いので、油圧によって制動力を足してやらなければいけない。（だから、構造が複雑になり、制御も複雑になる）
3. やっていることは超複雑なのに、ドライバには違和感を感じさせないように繊細な制御をすることが要求される。
4. ABSが作動するときは、回生ブレーキは使わずに油圧ブレーキだけで制動力を確保する。（回生ブレーキでは断続的なブレーキングは不得意だから）
5. ABSが作動するときは、ブレーキの油圧の供給方法を切り換えてドライバーが踏んだペダルの油圧を使うようにしている。
6. 先代プリウスではペダル油圧ではなくモーターとポンプで作り出すアキュームレータ油圧を使っている。（新型プリウスのブレーキ問題の後トヨタはペダル油圧から先代プリウスで実績のあるアキュームレータ油圧に制御を変えている）
7. なぜ、先代プリウスではアキュームレータ油圧を使っていたのに、新型プリウスではペダル油圧に変えたのか？
8. それは、ブレーキングの際に増圧デューティ制御弁から生じる騒音・振動を低減させようとしたからでもある。（先代プリウスでは高価な増圧リニア制御弁を各車輪ごとに使っていたが、新型プリウスではコストダウンのために安価だがノイズの大きい増圧デューティ制御弁に一部変更している）
9. 先代プリウスに比べて新型プリウスではペダル油圧の特性が強化されており、モーターとポンプを使わなくても、ペダルの踏み力でブレーキを動作させやすくなった。
10. これは、先代プリウスでは電源が故障するとブレーキが効かなくなるときの対策として予備電源のキャパシタを載せていたが、新型プリウスではこのキャパシタもなくしてコストダウンをはかり、電源が壊れていてもペダル油圧だけで制動できるようにした。（電源が死んだときは、ドライバの踏み力でブレーキを作動させやすくなった。）
11. そして、ABS動作時にアキュームレータ油圧を使うと増圧デューティ制御弁から発生する騒音や振動が目立つ（らしい）。（たぶん、ディーティ型は弁をパタパタさせる周期を変えることで制御をしているのでそのパタパタがうるさいのだろう）
12. この微妙な乗り心地感を向上させるために、改善したペダル油圧を使うように制御メカニズム（ECUのソフトウェア）を変更した。
13. ところが、低速で減速しているときのペダル油圧はアキュームレータ油圧よりも若干低い。（そこに落とし穴があった）
14. この差がドライバに微妙な「スカッ」という抜け感を生じさせてしまった。

ブレーキ制御ソフトの改変後、ABS動作時の制御をアキュームレータ油圧に戻したことから、騒音・振動は大した問題ではなかったのだと想像できる。

99.8% の満足度を 99.9% にするというトヨタの0.1%のコストダウン、乗り心地の改善が、結果的にブレーキシステムという基本性能に問題を発生させてしまった。

コストダウンや乗り心地のよさを追求した結果、すべての機能・性能に問題がないことを精査しきれないほどシステムが複雑になってしまったといえるのではないだろうか。

不具合が発生するメカニズムは分かってしまえば簡単だが、誰かから指摘される前にこのような問題を見つけるのは至難の業だ。特に複雑なシステムでは難しい。だから、メカもエレキもソフトもできるだけシンプルな構造（アーキテクチャ）を採用した方が安全面では有利だ。

シンプルであればあるほど、テストの網羅性を高めるととができる。妥当性を確認するために時間をかければかけただけの安心につながる。しかし、システムを複雑にすると、テストのカバレッジはいつまでたっても100%になならず、妥当性確認の時間は無限に必要になる。

このような　Systematic Failure を防ぐには個別最適の発想ではだめで、全体最適の発想が必要だ。

【日経ものづくり 2010年8月号 p39 図3 製品安全の方針より 引用】

明治大学理工学部情報科学科教授の向殿政男氏によれば、そもそも日本の企業は、信頼性を高めることで安全を確保しようとする傾向が強いといいう。しかし、前述の流れに従えば、そうした考え方は特に修正を迫られることになりそうだ。

「信頼性を高めることで安全を確保する」とは、製品を構成している個々の要素の信頼性をひたすら高めることによって、異常事態が発生する可能性をゼロに近づけようとする考え方である。構成要素に故障やバグがあることは前提としないので、これは「フォールト・アボイダンス」と呼ぶ考え方だという。

日本の企業はこれまで、この考え方で実績を積み上げてきた。「日本製品は壊れにくい」という評価は、まさにこのフォールト・アボイダンスを追求してきたたまものといえる。もともと日本の製造業は、欧米で確立された製品の改良設計で成長してきたという経緯がある。製品全体のアーキテクチャが所与の中、改良設計という形で信頼性を高めることに力を注いできたのは、ある意味必然だった。

さらに向殿氏は、信頼性は定量的・純技術的な概念であり、技術者にとって扱いやすい指標だったことも、日本の企業がフォールト・アボイダンスに傾倒した理由に挙げる。「安全を定義するには、社会が許容するリスクとは何かといったことも考えなければならないので、どうしても哲学的な判断が必要になる。それに比べると、信頼性は技術者にとってとっつきやすい概念だった」（同氏）

だが、ソフトの役割が増すにつれ、フォールト・アボイダンスだけで安全を確保するのは、難しくなってきた。前述の通り、ソフト自体の信頼性を高めるのが困難な上、ソフトやハードといった構成要素同士の関係も複雑になっていることから、構成要素の故障やミスを認めない前提そのものに無理が生じているのだ。

そもそも信頼性（壊れにくいこと）と安全は全く異なる概念である。だが、前述のような経緯から、信頼性を高めることと安全を確保することがほとんど同じ意味になってしまっていたのである。

ソフトによって「信頼性≒安全」という認識は崩れつつある。ある意味では、本質的な安全に取り組む上で良い機会といえる。そこで重要になるのが「フェイルセーフ」や「フォールト・トレランス」といった概念だ。

フェイルセーフは、構成要素に故障やバグがあっても、安全側に落ち着くようにする設計である。例えば鉄道の踏み切りでは、遮断棒を支持する機構に何らかの故障が発生すれば、遮断棒が自重で落ちてくる。このとき、人や自動車は必要以上に足止めされるので信頼性という点では低下しているが、安全は確保できている。このように信頼性を犠牲にしてでも安全を最優先にするのがフェイルセーフとである。

ただし、製品や使用状況によって、明確な安全状態が存在しなかったり、コストなどの制約でフェイルセーフを盛り込めなかったりすることがある。その場合は、冗長化や多重化といったフォールト・トレランスを検討する。フォールト・トレランスは、信頼性を高めて昨日の継続を目指すという意味ではフォールト・アボイダンスと同じだが、欠陥やバグの存在を前提としている点が決定的に異なる。

構成要素ごとに信頼性を高めることが可能なフォールト・アボイダンスに対し、フェイルセーフやフォールト・トレランスは製品全体（システム）やサブシステムといった、大きな視点で見なければ実現できない。それには、製品開発の在り方を大幅に見直す必要がある。

【引用終わり】

日本のリスク分析の大家である向殿先生の主張が、アメリカの安全設計の大家であるナンシー・レブソン教授と根底でつながっているのはとても興味深い。

「日本の製造業は、欧米で確立された製品の改良設計で成長してきた」というくだりは、まさに目から鱗が落ちた。「だから全体最適や安全アーキテクチャの話しが通じないんだ」と思い当たるふしがある。日本の製造業の歴史的要因があるとなると、根が深いので安全アーキテクチャをシステム開発の上流で分析させるためには、攻め方を変えなければいけない。

全体最適の発想で安全アーキテクチャを考えなければ、どんなにがんばっても大きな問題を抑えきれない時代はすぐそこまで来ている。

レクサスのパワーステアリング不具合の原因分析について

トヨタ自動車は19日、ハンドルが一時的にタイヤと連動しなくなる不具合があるとして、レクサス4車種のリコールを決めた。

今回もプリウスのときと同様にソフトウェアの複雑性が絡んだ問題のようだ。

【レクサスホームページより引用】

レクサスLS460、600hのお客様へのお詫びとお願い

本日、レクサスLSのVGRSに関する報道により、お客様にご心配をお掛けすることになり、申し訳なく存じます。
現在、リコールの準備を進めておりますので、LSのお客様には次の項目に注意して運転していただきますようお願いいたします。
なお準備が整い次第 販売店よりあらためてご連絡申し上げます。

●注意していただく運転状況
・右左折やＵターン等でハンドルを据え切り状態にしたのち、急ハンドルのような素早い戻し操作をすると一部報道されましたハンドルの中立位置ずれが発生しやすいので、急な操作はできるだけ避けていただきますようお願いします。

●運転中にハンドルの中立位置ずれが発生した場合
・車両の進行方向に注意してハンドルを操作するとともに、急な発進や加速は行わないようにお願いします。
・車両が直進状態でハンドルの中立位置がずれていることに気づいた時はハンドルに軽く手を添えていると車両の直進状態に合わせてVGRSシステムが自動的に中立位置ずれを補正（ハンドルが微動しながらズレを修正）します。
・ハンドルを中立位置にしたのに車両が直進状態でないことに気づいた時はハンドル位置に関係なく、車両が直進状態になるようハンドルを操作して いただきますようお願いします。

●当該現象は急ハンドルに相当するような素早い戻し操作をした場合に発生する場合があるものですが、走行中に現象を確かめるような運転は危険ですので絶対におやめください。

2010年5月19日
トヨタ自動車株式会社

【引用終わり】

なお、相変わらず報道各社の情報は問題の本質を分析するための材料となる情報が乏しい。Tech-On! のような技術寄りのサイトが解説してくれるとよいのだが、5/22現在ではこの件に関する記事はなかった。

一番詳しいと思われる記事が毎日jp に載っていた。

【『トヨタ：レクサスをリコールへ　信頼回復途上に痛手　イメージ低下、不可避』 毎日jp より引用】

トヨタ自動車は19日、ハンドルが一時的にタイヤと連動しなくなる不具合があるとして、レクサスの旗艦車種「LS460」など４車種のリコール（回収・無償修理）を決めた。台数は国内で約4000～4500台、海外分を合わせても１万台余と少ない。しかし、米国を中心に延べ約1000万台に及んだ大規模リコール問題の衝撃がようやく沈静化してきただけに、新たなリコールの発生は、ブランドイメージの低下など痛手となりそうだ。【米川直己】

「信頼回復には、顧客の不安に瞬時に対応する必要がある」－－。トヨタ幹部は、今回のレクサスのリコール決定をそう説明する。一連の大規模リコール問題で、対応の遅れを厳しく批判されたトヨタ。豊田章男社長は再生に向けて「顧客の安心・安全を最優先する」との方針を掲げ、リコールを躊躇（ちゅうちょ）しない姿勢を示している。

ただ、今回、リコールの対象となったのは、高級車ブランド「レクサス」の中でも最上位クラスのLSシリーズ。セダンタイプの「LS600hL」は１台1000万円以上。メルセデス・ベンツなどに対抗するトヨタの看板高級車種だけに、リコール対象台数以上に、富裕層など顧客へのイメージダウンの影響が懸念されそうだ。

リコールの原因となったのは、ハンドル操作と前輪の動きを適切に調整する電子制御装置「ギア比可変ステアリングシステム（VGRS）」。もともとトヨタがベンツなど欧州の高級ブランドに対抗する武器の一つとして導入したものだが、今回はその自慢の高度なハイテク装置に落とし穴があった。

LSのパワーステアリングは電動式で、ハンドルを切るとモーターに熱が発生する。ハンドルをいっぱいまで切った状態を保った場合や、何度もハンドルを切ってモーターが一定以上の熱を持つと、故障を防ぐためVGRSが停止する仕組み。1～2秒でVGRSは再び作動するが、作動前にハンドルを戻し始めると、ハンドルを切る量と実際のタイヤの角度が一致しない状況が一瞬発生する現象が起きた。VGRS作動後はハンドルとタイヤ角度のズレを検知する装置が働き、通常に戻るが、この際のタイムラグが顧客に不安を与えていたという。

今回の問題は通常の運転ではほとんど起こらないといい、トヨタは説明書に注意書きを入れていた。しかし、顧客からの不安の声が相次いだ以上、信頼回復途上のトヨタにはリコール以外の選択肢は無かった。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝

■ことば

◇ギア比可変ステアリングシステム（VGRS）
車の速度に応じてハンドル操作を補助し、前輪の動きを最適に調整する電子制御装置。低速走行時には、ハンドルを少し切るだけで前輪が左右に大きく動くようにし、駐車やＵターン時の操作を容易にする。一方、高速走行時にはハンドルを動かす角度に対する前輪の動きを小さくし、急ハンドルによるスピンなどを回避する機能がある。トヨタは02年、SUV「ランドクルーザー100」に初搭載。「クラウンマジェスタ」や「レクサスGS」などにも採用を広げた。

【引用終わり】

断片的に次のような情報も流れている。

トヨタは昨秋、VGRSの制御プログラムを変更。その際に不具合を把握していたが、「安全性には問題がない」として取り扱い説明書への記載で済ませた。しかし、今年3月以降、トヨタに対して12件の苦情が寄せられた。

トヨタ幹部によると、ハンドルが一時的に戻りすぎるのは機構上の特性で、説明書に注意書きも入れていた。しかし「対象の車は戻り方が極端で、顧客に不安を与えてしまった。より運転しやすくするために昨年秋の一部改良でプログラムを変更したことが裏目に出た」と説明している。

「運転しやすくするため、モデルチェンジにあわせてプログラムを改良したのだが…」。トヨタのある幹部は、電子制御の改良が、リコールにつながったことを嘆いた。同時に「機構上の特性」としたことに対する悔恨もにじんだ。

このような情報を総合すると、次のような経緯があったのではないかと予測される。

【レクサスのパワーステアリング問題発生の経緯（予測）】

1. メルセデス・ベンツなどに対抗するため、トヨタは低速走行時には、ハンドルを少し切るだけで前輪が左右に大きく動き駐車やＵターン時の操作を容易にし、一方、高速走行時にはハンドルを動かす角度に対する前輪の動きを小さくし、急ハンドルによるスピンなどを回避する機能「ギア比可変ステアリングシステム（VGRS）」をレクサスに搭載した。
2. VGRSではハンドルを切るとモーターに熱が発生する。ハンドルをいっぱいまで切った状態を保った場合や、何度もハンドルを切ってモーターが一定以上の熱を持つので、熱による故障を防ぐため（ある一定以上の熱を帯びると？）VGRSが停止する。1～2秒でVGRSは再び作動する。
3. VGRSが作動前にハンドルを戻し始めると（当初、この行為は取扱説明書上の禁止事項としていた）、ハンドルを切る量と実際のタイヤの角度が一致しない状況が一瞬発生する現象が起きた。
4. 2009年の秋にレクサスのモデルチェンジに合わせてより、快適な運転ができるようにVGRSのソフトウェアを変更したところ、3の角度不一致の度合いが大きくなり最大で90度までずれるようになった。（角度のズレは自動的に補正される）
5. 今年3月以降12件の苦情が寄せられたため、ソフトウェアを改変（どのような改変かという情報はまだキャッチできていない）し、約4000台の回収に踏み切った。

メーカーは想定されるリスクは軽減のため機器に対して設計上の対策を講じる。しかし、どうしても設計でリスクを回避できないとき、効果効能に対してリスク回避の対策に莫大なコストがかかるようなとき、表記上の対策、すなわち取扱説明書に禁忌事項を掲載したり、機器にラベルを貼ったりしてユーザーに注意を喚起することでリスクを回避する場合もある。

あってはならないのだが、エンジニアが設計上の対策を講じるのが面倒（正確にはそこに注力を注いでいると期限が間に合わない）と考えたとき、「これは表記上の対策にしよう！」と問題に正面からぶつかるのではなく、逃げるケースがある。リスクの度合いにもよるが個人的にこのようなことを自分は絶対に許さない。「何のために、誰のために開発をしているの」か技術者に問うことにしている。

今回のレクサスのパワーステアリングの不具合のケースは表記上の対策で済ませるべきか、設計上の対策まで講じるべきが微妙なところだ。こんなことで、いちいちリコールしていたらたまったもんじゃないと思っている自動車メーカーはたくさんあるはずだ。現に、プリウスのリコールが話題になっていたときあまり大きく取り上げられなかったがいろいろな自動車メーカーが（裏で）リコールをしていた。

トヨタはプリウスのリコールの件で信用を失墜しかけたので、今はグレーでもある一定数のユーザーから黒ではないかと言われたら躊躇せずに「黒でした。設計上の対策を講じます。」というようにしている。

ソフトウェアのリスクとその回避の手段を常に考えている分析者としては、それはやり過ぎではないかと感じている。グレーか黒かの切り分けは、ユーザーリスクの大きさで判断するべきであってユーザーのクレームの強さで判断するべきではないと思う。顧客の感覚は主観的である場合も少なくなく、客観的な判断ができないこともあるからだ。

ただ、このブログでも何度も言っているがソフトウェアの不具合はハードウェアの部品ように故障率のような概念がないため、不具合に至る手順が分かると、確実に不具合を再現することができてしまう。（システマティックエラー）

だから、ユーザーが滅多にやらない行為であっても、「こんな風になります」と実験報道することが簡単にできる。これをやられるとマイナスイメージが瞬く間に広がる。

だからこそ、ソフトウェアが起因する不具合は表記上の対策では片付けられない。ユーザーは許してくれない。滅多にやらないからといって対策を取らなくていい、「発生確率が低いので安心してください」とは言えない。だから、実際に問題が起こってもリスクは小さいと言えるのなら、ユーザーがちょっとだけ不快に思うだけなのなら誠意をもって説明し、不快な気持ちを和らげる努力として何ができるか考えた方がいい。いろいろ考えても、それが設計上の対策になるのならはじめからヤレということになる。

■不具合が発覚したとの組織がエンジニアに取る態度について

今回もプリウスのブレーキのソフトウェア改変のときと同様に、ソフトウェアの複雑性が絡んでいるため問題を分析するとき「ソフトウェアのバグ」「検証し忘れ」などと短絡的に原因を決めつけてはいけない。

ソフトウェア絡みのリコールが発生すると組織内で鬼の首も取ったように「それ見たことか」という態度を取る人たちがいるが、自分はそういう人たちに言いたい。「では、同様の問題がリコールを実施する機種や他の機種にないかどうか調べる方策は考えているのか」「再発防止についてどんなアイディアがあるのか」と。

問題が明らかになってから大騒ぎするのは誰でもできる。ソフトウェア品質保証担当の重要な役目は是正と予防だ。なぜ、そのような問題が起こるのかを分析し、どうすれば今後起こさなくできるのか対策を立案し、実行し、うまくいったかどうかを継続的にウォッチすることがソフトウェアQAには求められる。

■顕在的価値(Real Value)と潜在的価値(Potential Value)のトレードオフ関係

プリウスのブレーキにせよ、レクサスのパワーステアリングにせよ、問題の原因には、ユーザー要求の多様化とソフトウェアの複雑化のトレードオフが関係していると思っている。『組込みソフトエンジニアを極める』でも『リコールを起こさないソフトウェアのつくり方』でも、組込み機器にはカタログに載せるような「顕在的価値(Real Value)」と、ユーザーが当たり前に確保されていると思っている「潜在的価値(Potential Value)」の両方の価値が存在し、そのバランスが保たれていないと長い目で見たときに顧客から信頼を得て高い業績を上げることはできないと書いた。

簡単に言えば、ユーザー要求は多様かつ複雑になっているので、その多様性や複雑性に起因する顕在的価値をソフトウェアで実現しようとすると、やり方によっては潜在的な価値が下がってしまう可能性があるということだ。

通常はその2つは、トレードオフの関係にある。多用で複雑なものが当たり前に動くことを実証するのは難しい。だから、安全や信頼が求められる潜在的価値の高い機能や性能は、多用で複雑にはせず、多用で複雑なものは安全や信頼とは切り離しておく方がよい。カーナビのように多用で複雑なものは安全や信頼と切り離しておかないと危ない。

■ギア比可変ステアリングシステム（VGRS）は顧客にとってどんな価値がある？

そこでまずは、ギア比可変ステアリングシステム（VGRS）の顕在的価値について考えてみたい。

<ギア比可変ステアリングシステム（VGRS）のポイント>

• 低速走行時には、ハンドルを少し切るだけで前輪が左右に大きく動くようにし、駐車やＵターン時の操作を容易にする。
• 一方、高速走行時にはハンドルを動かす角度に対する前輪の動きを小さくし、急ハンドルによるスピンなどを回避する機能がある。
• レクサスやクラウン、マークXなどの一部に採用しており、高級車としての差別化を図るために採用した機能だと思われる。

さて、上記の機能、性能は顧客満足にどれくらい貢献しているといえるだろうか。分析にはQFD（品質機能展開＝組込みプレス Vol.8 の特集記事参照のこと）を使うとよいのだが、まあ、普通に考えて他社と差別化するための付け足しの機能、性能であり、車としての本質的な機能や性能ではないことは明らかだ。個人的にはパワーステアリングが基本的な機能だけあれば十分ではないかと思う。

そして問題は、この付け足しの機能を実現するためにソフトウェアが複雑化し、ハンドルが曲がっている状態で直進してしまうという、車としての基本機能を損なう問題を埋め込んでしまったという点だ。基本使用における安全性は確保されていようだが、0.1%の品質にこだわるトヨタとしてはユーザーに不安を与える可能性があるので回収を決めた。

トヨタは今後、検査態勢を強化することで再発を防止するとニュースサイトに書かれていたが、それは本質的な改善策にはならないと思っている。なぜなら、これほどに複雑化したソフトウェアシステムを完全に検査するためのテストケースは爆発的に増えてしまっており、テストケースと結果が妥当かどうかを完全に検証していたら設計するときよりも時間がかかってしまうからだ。

検査で何とかなると考えていること自体、21世紀のソフトウェアシステムの品質管理の概念ではない。Verification（検証）でソフトウェアの完全性を追い込めるのは規模や複雑性が小さいときだけであり、10万行を超えるサブシステム、そして、サブシステム同士が相互の作用しあって動くシステムでは、Verification（検証）は安全や信頼の確率を高める効果でしかなく、絶対に安全である、信頼できるというお墨付きは出せない。

それを理解した上で、いかにユーザーリスクを受容できレベルまで引き下げるかという取り組みがSoftware Validation（妥当性確認）である。

■大規模複雑化したソフトウェアシステムの潜在的価値を高めるには

トヨタのみならず、多くの組込み機器メーカーの組織上層部は複雑化したソフトウェアの怖さ、当たり前にできていることの価値、すなわち潜在的価値(Potential Value）を高くキープすることも難しさを認識できていない。

そして、他社と商品を差別化する際に部品代がかからないからという理由ではソフトウェアによる機能追加を考える。それにより潜在的価値が犯される可能性など予想もしないし、不具合が発見されるとそれはプログラマのうっかりミスと決めつけられる。それで不具合の発生する確率が下がるのならいいが、ソフトウェアの規模が大きくなるにつれ、逆に確率は上がっていくだろう。

多くの組込み機器の開発に関わる組織は当たり前にできていることの価値、すなわち潜在的価値(Potential Value）を過小評価している。というよりは、細かい顕在的価値(Real Value）を積み重ねることでシステムが複雑化し、そのことによって当たり前に出来ていることに問題が起こることを想定できていない。

特にトヨタはその認識が不足しているのではないかと思う。それはなぜかと言えば、これまでは徹底的に顧客要求のチューニングのためにソフトウェアを変更しまくることで、98%の顧客満足度を0.1%刻みで100%に近づけることに成功してきており、その成功体験がリスクを見えなくしていると思うからだ。

トヨタはユーザーの使用環境を想定したソフトウェアのシステムテストとソフトウェア部品を供給するサプライヤーに対する厳しい検証要求で問題を潰しきれると思ってはいないだろうか。

日本のたたき上げの組込み機器産業ではよく見られる光景だ。顧客満足を高めるために尽力を注ぐことは正しい。しかし、ユーザーが当然できていると思っていること、すなわち安全や信頼がシステムが複雑になることで脅かされるリスクについてはみな鈍感だ。

理由は簡単。日本のたたき上げの組込み機器産業の組織上位層はソフトウェアはハードウェアを制御するつなぎ役として長い間見てきており、現在のように巨大化して複雑になったソフトウェアシステムに内在する爆弾の怖さを実感できていないからだ。

爆弾をサプライヤの管理とカイゼンの積み重ねでつぶせると思っているのなら、それは間違いであり、MISRA SA（『リコールを起こさないソフトウェアのつくり方』のAppendix B に概要を書いた）をよく読んだ方がよい。安全は上流の要求分析とアーキテクチャで押さえ込まなければならない時代になっている。

安全なアーキテクチャ、基本機能が脅かされない信頼性の高いアーキテクチャでソフトウェアが設計されているかどうかをソフトウェア開発の上流で検証する必要がある。それをせずにすり合わせ的手法、付け足し手法でソフトウェアを作って、徹底的にテストで爆弾を見つけようとしてもムリである。

■シンプルデザインの価値とは？

シンプルデザインの価値は有限なテストケースで Validation ができるということだ。一流の職人（ソフトウェア技術者）はシンプルなアーキテクチャを評価できるが、セールスマン、マーケットプランナーは一流でも、シンプルなアーキテクチャを評価できない。要求を実現できれば、シンプルなデザインになっているかどうかは気にしない。ソフトウェアの見えなさの弊害だ。

安全や信頼だ求められるソフトウェアはシンプルなアーキテクチャで潜在的価値を最大にする。どうしても複雑にならざるを得ないときは0.1%の表面的な顧客満足度よりも、数10%の潜在的価値＝当たり前品質につながるシンプルアーキテクチャの方を取る。それができるのは、数々のものづくりを経験してきた職人（＝システムアーキテクト）だけだ。

顧客の要求を取り入れメーカーが自分でアーキテクチャを設計せず、サプライヤーにものづくりを任せて何年もたつとその感覚はどこかに飛んでしまう。

自分はクルマ屋さんは頼むからカーナビとブレーキの機能を連動させるような複雑なシステムを作らないで欲しいと思う。時代は進化しているから、新しい機能がないとユーザーが買ってくれないからといって、システムを複雑にし、わざわざリスクを盛り込んでいったらシステムアーキテクチャはシンプルデザインとは言えなくなってしまうのではないか。（洗練されたアーキテクチャで、安全と複雑性の高い要求を実現できていると言えるようなら脱帽だが、本当にそうなっているだろうか）

真の銘品には洗練された美しさがあり、経験を積んだ仕事人はそれをかぎ分けることができるのだが、ソフトウェアは見えないからそう簡単にはいかない。できるといっていることが多用で複雑で使いそうにもない機能満載の場合、怪しいと感じる。

一時の快楽＝おいしいカタログのうたい文句が顧客に効き、売り上げに貢献するのは最初だけであり、潜在的な価値のよさは長年使い込んだ時にはじめてユーザーに理解され、そして、それが理解されるとユーザーはそのブランドやメーカーのファンになる。長く惚れ込んでくれるファンを増やすためには、シンプルなアーキテクチャが美しいと感じる感性と、複雑よりもシンプルを選択する組織の分析力、決断力がいる。

フィールドで問題が起こったときメーカーはサプライヤに「コラー！なんてことしてくれたんだ！」と言っているだけではダメで、ユーザーニーズと安全が確保できるアーキテクチャであるかどうかを判断できなければいけない。そのためには自分自身でものづくりを主導し続けなければいけない。サプライヤーから提供された部品を組み合わせているだけでは安全アーキテクチャができているかどうかを見極めるスキルはつかない。

アーキテクチャの分析能力が大事であり、くるまドメインの方は、まずは、MISRA SA（Safety Analysis）を読むとよいと思う。

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

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

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

• この問題はたぶんソフトウェアのデグレード（変更によって今まで動いていたところが動かなくなるミス）ではない。
• この問題は複雑化していたブレーキシステムの軽量化、低コスト化により、ブレーキシステムのハード・ソフトが変わった際に 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社、ハイブリッド車の回生ブレーキのソフトウエアを書き換え』という記事があった。これってプリウスのソフト改変とまったく同じに見える。同じブレーキシステムをトヨタやアドヴィックスが提供していたならともかく、そうでないのだとしたらプリウスをバラバラに分解してデッドコピーしたのでは？と思わせる。なんで、こっちはリコールじゃないんだろうか。

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

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)を分析し、それを満たすために回生ブレーキと油圧ブレーキを使う場合どんなリスクがあるかを考え、リスクが最少になるためにはどのようなアーキテクチャが必要か、どんなリスクコントロール手段があるかを考える。

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

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

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

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

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

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

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

セーフウェアの解説その二

『セーフウェア』の解説その二として、【安全性と信頼性は別なものであって、混同してはならない】を説明しようと思う。

安全性：Safety と 信頼性：Reliability は異なる。異なるというよりは区別して考える理由がある。ナンシー・レブソンが言いたいのは、信頼性：Reliability を高めることで安全性：Safety が確保されると考えてはいけないということだ。

多くの人は「なぜ」って思い、ピンとこないかもしれない。でも、「このソフトウェアに何か問題があると、人を傷つける可能性がある」というソフトウェアを一度でも作ったことがある人には分かると思う。それだけ重要なソフトウェアであっても、問題を起こさないという絶対的な自信はなかなか生まれてこないのだ。責任感が強いエンジニアほど、この現実は辛い。テストをいくら積み重ねても、100%の安心にはつながらないことは直感的に分かる。ソフトウェアの規模が大きくなればなるほどエンジニア個人の無力さを感じると共に、個人の範囲を超えたときから「自分だけではどうしようもない」を考えるようになり責任感も薄れていく。

ソフトウェアの規模が大きくなると、完成度を高めても、悪意がなくとも誰も気づかないうちにプログラムが修正されてしまう危険もある。

ソフトウェアを部品と考え、十分に信頼性を高めたと思われる部品を結合したソフトウェアシステムは必ずしも安全ではないことは、このような経験から感じるのだ。

もちろん、ソフトウェアモジュールの信頼性を高めることは、ソフトウェアシステム全体の安全性を高めることに貢献する。しかし、それでもなおナンシー・レブソンが「安全性と信頼性は別なものであって、混同してはならない」と言うのは、信頼性の高いソフトウェア部品をつなぎ合わせて作ったソフトウェアシステムが、システムとしてのユーザーリスク、プロダクトリスクを分析して対処する、もしくは、リスクを制御するシステムアーキテクチャを採用していないのであれば、安全なシステムであるとはいえないからである。

そこには次のような具体的な要因が考えられる。

• AモジュールとBモジュールの制御判断が背反した場合のシステムとしての動作をモジュールは規定できない（部品の信頼性では解決出来ない）
• 検証が終わり信頼性を高めたモジュールが改変できなようにすることは難しい
• システム全体でリスクを軽減しようとしても、部品が完成してしまっていると実現しにくい。
• ソフトウェアを変更しないで再利用できるようにするためには、高度なスキルが必要であり、簡単ではない
• システム全体のリスクを分析してコントロールしようとしない者は、すでに存在するソフトウェア部品の組み合わせでシステムを構築しようとし、リスク低減よりもソフトウェアの早期リリースが優先する

開発効率やコストダウンを優先するあまり、信頼性の高いソフトウェア部品を組み合わせてシステムを構築したいと考える者は必ず存在し、その考え方が事故を誘発する。

このことが分かっているからセーフウェアには「安全性と信頼性は別なものであって、混同してはならない」と書かれているのだ。

これは手段が目的になってしまい、本来の目的が忘れ去れれてしまうこととよく似ていて、「物事の本質を見極めない」、「どうして今これをやらなければいけないのか」と考える習慣がないと陥る危険性のある心理的なトラップである。

「信頼性を高める」ことは手段だと思う。一方で「安全性を高める」とは目的だ。「安全」と言う言葉の後ろには、人や財産など失ってはいけない重要なものがはっきり見える。

「信頼」は誰のための「信頼」かがはっきりしない。クライアントがサプライヤーに求める「信頼」は、エンドユーザーの「信頼」であるとは限らない。例えば、産地偽装を指示したクライアントに対して、言われた通りにラベルを偽装したサプライヤーはクライアントの信頼を得るが、エンドユーザーの信頼は裏切っている。

安全は常にエンドユーザー（場合によってはオペレータも含まれる）が対象になる。安全は誰も裏切らないが、信頼は場合によってはだれかを裏切る可能性がある。

「安全性と信頼性は別なものであって、混同してはならない」の深い意味をお分かりいただけただろうか。『セーフウェア』を読む方はこの点について気にしながら読んでいただきたい。

P.S.

Dependability や Functional Safety ということばも最近 ISO規格の中で出てきており、

Wikipedia によると  Dependability は

Dependability is a value showing the reliability of a person to others because of his/her integrity, truthfulness, and trustfulness, traits that can encourage someone to depend on him/her.

とあり、 次の要素を含むとある。なんと Safety も Reliability も含まれている。

Availability - readiness for correct service
Reliability - continuity of correct service
Safety - absence of catastrophic consequences on the user(s) and the environment
Integrity - absence of improper system alteration
Maintainability - ability to undergo modifications and repairs

こうやって、いろいろな視点をまとめて体系化することで、特定のドメインにおける安全または実際に起きた事故の再発防止策が抽象化されてすべてのドメインに通用する銀の弾丸があるかのように思われることを自分は心配している。

また、Wikipedia によると Functional Safety は

Functional safety is the part of the overall safety of a system or piece of equipment that depends on the system or equipment operating correctly in response to its inputs, including the safe management of likely operator errors, hardware failures and environmental changes.

となっている。この Functional safety（日本語では機能安全）が、なぜ Functional を Safety にくっつけたのか未だにその真意を理解していない。いずれこのブログで話題にしたいと思う。

セーフウェアの解説その一

安全ソフトウェアの教科書的な存在であるセーフウェアを読み始めた。656ページもある分厚い本なので、まずは30分くらいで斜め読みした。

自分は約20年近くクリティカルデバイスの開発に携わってきたので、書いてあることがよく分かったが純粋なソフトウェアエンジニアにはピンとこないかもしれないとも感じた。

具体的な事故の事例も多く掲載されているので、取っつきやすいと思うがやっぱり解説が必要にも思える。

そこで、できるところからこの本に書いてあることの意味について解説してみようと思う。

どこがいいかざっと見ていたら、エピローグ「これからの展望」にいいことが書いてあったので、ここからいこう。

【『セーフウェア』エピローグ これからの展望 より引用】

• 安全をより確かなものにする最も効果的な方法は、単純であることと、知的に処理できるシステムを構築することである。

• 安全性と信頼性は別なものであって、混同してはならない。

• 確率論的リスクアセスメントに依存し過ぎるのは賢明ではない。

• システムに安全を組み込むことは、完成した設計に防護装置を加えるよりも、はるかに効果的である。安全が、開発プロセスのより早い段階で考慮されるほど、より良い結果が得られる。

• 進歩するためには、事故を単純化しすぎるのを止め、事故の、複雑で複数の要素がからんでいるという本質を認めなければいけない。根本原因に手を着けずに、症状だけを処置しても、事故の再発はほとんど防げない。問題の数少ない側面だけに集中しても、望ましい効果は得られない。特に、技術的問題だけに着目して、管理上や組織上の欠陥を無視したのでは、有効な安全プログラムは得られない。

• 単に人間をコンピュータに置き換えても安全問題は解決しない。人間の「エラー」は人間の柔軟性と創造性に不可避に結び付いている。人間をコンピュータに置き換えるのではなく、むしろコンピュータを用いて人間の能力を増強する方法に取り組むべきである。

• 安全はシステムの問題であるので、異なる分野の専門家が共同して働くことによってのみ解決することができる。特にソフトウェアは、システムの他の部分から独立していては、効率よく開発できない。ソフトウェア技術者は、システム安全の概念と技法を理解しなければならない。同時に、システム安全担当者は、より深くソフトウェア開発にかかわり、システム安全のプロセスにソフトウェアを取り込むようにしなければならない。

• そのソフトウェアが動作するシステムという状況の中でのみ、ソフトウェアの安全性を評価することができる。ソフトウェア単独で見るだけでは、一片のソフトウェアの安全性も評価できない。

• 自己満足はおそらくシステムで最も重要なリスク要因であり、それを最小にする安全文化が確立されなければならない。

• 事故につながる事象が予測できないからといって、事故が予防できないということにはならない。ハザードは、通常分かっていて、しばしば、除去され、かなり軽減される。必要な機能性や費用の低さのような、他の目標とのトレードオフが最も少ないために、（ハザードよりも）先行する事象を除去しようとする決定がしばしば下される。複雑な決定は科学を超越したものである。しかし、技術者には、上位の意思決定者のためにリスクを明らかにし、自己満足または他の要因、または圧力が、意思決定において当然の考慮されるべき工学上の問題またはリスクを妨害しないようにする義務がある。

• われわれは同じ過ちを繰り返さないよう、過去から学ばなければならない。

【引用終わり】

これらを全部解説していたら終わらないので、まずは『安全をより確かなものにする最も効果的な方法は、単純であることと、知的に処理できるシステムを構築することである。』から

【安全をより確かなものにする最も効果的な方法は、単純であることと、知的に処理できるシステムを構築することである】

「安全」と「シンプル」は親和性が高い。特にソフトウェアは見えにくいので単純か複雑化を見分けるのも難しい。だからこそ、クリティカルデバイスのソフトウェアエンジニアは常にシンプルなアーキテクチャを目指す必要がある。

単純の最大のメリットは何だろうか。単純なソフトウェアはテストケースを有限にできる可能性がある。テストケースが有限ならば、テストに漏れがないと言える確率が上がる。

ちなみに、仮にテストケースが有限でテストに漏れがなくても安全とは言えないということは『安全性と信頼性は別なものであって、混同してはならない。』の解説で述べたいと思う。

でも、シンプルなアーキテクチャである方がテストもしやすいし、より安全に近づけることが可能であることは直感的に分かると思う。

さて、「知的に処理できるシステムを構築することである」の意味は英語の原文が手元にないので絶対そうだとはいえないが、たぶんこういうことだろうと思う。

要するに、安全を実現するアーキテクチャ、別な言い方をすればリスクコントロール手段を実現するアーキテクチャがある＝きちんと設計されているということだと想像する。

世の中、ソフトウェア搭載デバイスへの要求はどんどん多様化している。車だってセンサが障害物を感知して自動でブレーキをかける時代はすぐそこにきている。しかし、便利と安全は少なからず背反する部分がある。便利にしようとすればするほど、ソフトウェアは複雑になりユーザーの安全を確保するのが難しくなる。

センサーが障害物を感知したからといって、自動でブレーキをかけるとかえって危ないケースをあなたは簡単に想定できるだろうか。（日頃から訓練しているとできるようになる）

例えば突然ボールが自分の車の前50mくらいのところに転がってきたとする。冷静なあなたはバックミラーを見て、後ろから来ている大型トラックがよそ見をしているのを確認した。ここで自分の車が急停車すると後ろのトラックからかなりのスピードで追突される可能性がある。この場合、あなたの車はブレーキをかけないでボールをはね飛ばすか踏みつぶす方がリスクが低い。

ユーザーはいろいろなシチュエーションを想像することもなく、安易に車が自動でブレーキをかけてくれる機能があるといいと言うが、上記のような複雑なシチュエーションでその自動システムが働きかえって事故が起こったりすると、「そんな事態も想定して対策しておくのがメーカーの役目であり、過失だ」と結果論でものをいう。高い金を払って買っているのだから、どんなに複雑でも安全にできていて当然だという論理だ。ちなみに、その考え方は正しい。安全はタダでは確保できない。安全には価値があり、その価値を実現するにはそれなりの対価が必要だ。安全の対価をユーザーからいただいたメーカーは安全を確保する責務がある。しかし、システムが複雑になればなるほど、当たり前品質を確保するのは難しくなり、安全を確保する技術が必要になってくる。

だからこそ、「知的に（安全を）処理できるシステムを構築すること」は価値がある。システムを複雑に作ってしまってから、後からとってつけたようにリスクコントロールのソフトウェアを付けることは、目的を果たせない穴ができる可能性がある。

リスクコントロール手段は、最初からきちんと分析設計されたものであり、かつ、できるだけシンプルなアーキテクチャであることがいいのだ。単純で分かりやすいアーキテクチャであれば、ソフトウェア変更時の影響範囲の分析や、テストのポイントも絞り込むことができる。総当たりでテストすればよいという考え方では必ず漏れがでる。構造をシンプルにして抑えるべきポイントを絞り込むことが有効である。

こんな感じで、今後も、機会があるごとにセーフウェアのエピローグを解説していこうと思う。