コンピュータ（ハード・ソフト）の信頼性向上
プリウス問題を引き摺ってまた少々堅苦しい話をしますが、ちょっと辛抱してくりゃれ。
3年前に書いた以下のエントリ。
私がUNIXミニコンの仕事をしていた頃は、タンデム社のノンストップ・コンピュータが話題になった時期でもあり、ハード屋さんが頑張って、凄いマシンを送り出してきた。
まず、あらゆる部分が二重化されている。 電源・バス・I/Oその他全てで、どちらか一方が故障しても止まらないようになっている。 しかもホットスワップに対応していて、稼動中でも（つまり電源を入れたまま）故障部位の交換ができる。
CPU部は、3つのマイクロプロセッサが互いの結果を照合しながら並行処理をしていて、もし結果が食い違えば多数決をとって処理を続行する設計。 お値段は億の大台に乗ってましたね。
フォールト・トレラント・コンピュータ - しまうま技研
関連情報がネットにアップされてました。 その名はFT-6100。
HITAC FT6100は，フォールトトレラントサーバとして，1991年10月に発表された．ハードウェアが二重化されており，一部に障害が発生しても他方の系で処理を続行できる．特にプロセッサは，三重化された演算器が1つのプロセッサボードに実装され，保守・増設が容易となっている．このボードを追加していくことにより，マルチプロセッシングによる処理能力の向上が図れる．
HITAC FT6100-コンピュータ博物館
FT6100って書かれてますが、正式名称はFT-6100です念の為。 学術論文もあるでよ。
（前略）
CiNii 論文 - フォールトトレラントサーバFT6100の高信頼化技術
コンピュータを無停止化するために,システム信頼性を上げて障害による停止を防止するいわゆるフォールトトレランス機能に加えて,システムを稼働させたままオンラインで保守,点検,拡張できる機能、オープン性を備えたTPR(Triple Processor check Redundancy)方式によるフォールトトレラントサーバHITAC FT-6100シリーズについて述べる。
3台搭載されたマイクロプロセッサ、実はモトローラのMC68040*1。
まぁ細かいことはともかく、ハードの信頼性向上は冗長化により実現されているわけです。 ではソフトはどうか？
実は、ソフトウェアも冗長化というアプローチにより信頼性を向上させた事例があるのです。 スペースシャトルの航法システムがその代表例。
（前略）
スペースシャトル - Wikipedia
シャトルはIBM製32ビット汎用コンピュータのAP-101を合計5台搭載し、冗長性を持たせた一種の組み込みシステム(embedded system)を構成している。このうちの4台はPASS（Primary Avionics Software System, 主電子航法ソフトウェアシステム）と呼ばれる特製のソフトウェアで稼働し、残りの1台はこれとは全く別の、BFS（Backup Flight System, バックアップ航法システム）というソフトを使用している。またこれらを全体をDPS（Data Processing System, データ処理システム）と呼ぶ。
（中略）
DPSでは、主システムたる4台のPASSは基本的に同一の固定された手順で稼働し、相互に監視し合う。もしその中の1台が他と違う動作をしたら、残りの3台が「投票」をして、異端者である1機をシステムから除外して運行に関わらせなくする。
（中略）
バックアップにあたるBFSは、PASSとは別個に開発されたソフトで、5台目のコンピュータで動作し、すべてのPASSが故障した時に使用される。PASSはハードウェア的には冗長性を持たせているものの、全く同じソフトを使用しているため、何か一つのソフト上の問題が発生した場合、4台すべてが稼働しなくなってしまう可能性がある。そのため、万が一の対策としてBFSが準備された。
PASSにある（かも知れない）バグが発現した場合に備え、同じ役割を担う別プログラム（BFS）を用意してあるんですよね。 幸いなことに、これまでBFSの出番は一度もなかったそうですが。
しかし、こうした手法は信頼性が最重要視される分野（航空宇宙・医療・原子力・軍事 etc.）だからこそ出来るのであって、コストを度外視できない民生用システムでは、冗長化ではなく構成要素の品質を上げることで実現するしかありません。
そしてソフトウェア（プログラム）というのは実は手作りの工芸品のようなもので、開発者のスキルが品質となってモロに出てしまうものなのです。
しかも、回生ブレーキやABS制御といった複雑な処理を行うプログラムは数多の条件分岐のカタマリで、開発難易度はさらに高くなります。 ごく稀にしか起きない事象も考慮しなければならず（ここには設計時に検討が漏れてしまう危険性あり）、またそのような事象のテストも難しくなります（テスト漏れの危険性）。
私が大型汎用機の仕事に関わっていた頃は、テスト漏れを防ぐためにカバレージ（網羅性）テストでC0メジャー（measure）・C1メジャーを100%にすることが求められていましたが…PCが主流の時代になってから、そういうテストはあまり行われなくなってしまっているのかも知れません。
もっとも、自動車のように人命に関わる製品の場合、一般的には十分なテストが行われているはずです。 今回の問題は、はやり公表の仕方の問題でしょう。 何しろ、問題が露見する前からファームウェアに"改良"を加えていたのですから。
