※ご注意：本内容にはネタバレが入っています。
逃げ恥、いかがでしたか。ドラマも漫画も当然終わりが来るわけですし、結末に向かってゆくプロセスが物語なのですから、楽しめたならロスがやってくるのはやむをえません。しかし寂しいですね。平匡氏にもう一度会いたいです。そこで機能安全関係者の皆様と、すこしでも逃げ恥を仕事につなげて思い出をつなげ、ロスの緩和を試みたいと思います。
逃げ恥には様々なキーワードがありますが、注目すべきは最終回の言葉です。「また火曜日から始めよう！」これは喧嘩をしたり面倒があっても、ハグの日を起点にリセットして、いつでも二人で乗り越えてゆこう！というメッセージなのですが、このハグの日を機能安全的に考察するとどのようなことが学べるでしょうか。
みくりと平匡のシステムの再構築の会話には、機能安全的にどのような意味があるのでしょうか。
ハグの日は定期的
最初は周囲の目を気にして始まったハグの日ですが、途中二人の気持ちが近づくことでシステム（仕組み）としては解体され、ハグは日常の一部になりました。しかし気持ちの赴くままのハグは、ケンカをして「心が離れれば手も触れない」ことにつながり、二人の関係の修復には役に立たなくなります。このため最後に平匡はハグの日というシステムの復活を提案します。つまり、ハグの日は「万一の障害発生時」のためのシステム（安全機能）に変化しました。
機能安全に携わる方ならピンとくるでしょう。そうです。PFD計算式の中のＴ１（Proof Test Interval）がこれに相当する気がします。週に一度というインターバルも、Proof Testっぽいです。では改めてPFDの式を見てみましょう。
ですから簡略化して
ここ出てくるλDUとは故障してもその発生を検知することができない故障の故障率です。λDDとは発生したことが検知できる故障の故障率です。各故障率を故障している時間（機能不全の状態の期間時間：MDT（Mean Down Time））をかけて平均的なPFDを算出しています。式はλDUに基づく前項と、λDDに基づく後項の合計になっていることがわかります。検知できない（検査しないとわからない）障害の発生を確認し修復の機会を得るのがProof Testの役割です。そのインターバルを式ではT1で示しています。2で割っているのは、検査期間の1/2の時間は期待値として故障しているかもしれない時間と考えることと同じです。
※本書でいう故障率λは、すべて単位時間当たりの故障率：FITを意味します。
2000年版のIEC-61508では、前項も後項もMTTRでしたが、2010年の改定で前項がMRT（修復時間）、後項がMTTRとなりました。前項にはProof Test Interval (T1)が明示的に入っていますから、修理の実質的な時間（MRT）だけがMean Down Timeです。一方後項は、検知できる故障の場合を示していますが、いくら検知できる故障といえど、発生から検知まで多少なりとも短い時間は入っていると考えるため、修復時間に検知に要する微小時間を加えたMTTRを用います。
２つの周期時間パラメータT1とT2
さてここで式にT１という「１」というサフィックスがついていますね。機能安全のPFDおよびPFHの計算式には、T1とT2が出てきます。では、T2は何でしょうか。PFDの計算式には出てきません。これはPFHの計算式に出てくる時間インターバルで、自己診断(Diagnositc)の時間インターバルです。Proof Testが「長い期間」「人の手が介在する」という特徴を持つ一方、自己診断は、「きわめて短い」「自動的」「定期的」という特徴を持つものを指します。人間の意志で行うものではないことが大切です。人が介在するとやらなかったり間違える可能性が出てくるからです。
「短い」というのは、危険なイベントが発生したときに対象に事件が起こるまでの時間よりも短いことが目標です。その範囲の短さならば、もしも「故障が起こって不能なること」と「危険なイベントが発生」が同時に発生というクリティカルなタイミングでも、事件になるまでに自己診断で故障を察知しシステムを安全な状態に移行させることができるからです。これはシステムがシングルの時の場合です。二重化を組んで修復できる場合は、MTTRの時間よりも十分に短ければよいことになっています。修理中に生き残った方がさらに故障になる可能性が無視できるほどの時間内であればよいからです。
PFHの式も示します。これは後程使う二重化したシステムのPFHの算出式です。IEC-62061（機能安全規格の機械安全セクター規格）の6.7.8.2.5章式(D.1)を加工しています。この式はまた後半で使用します。ここではT1とT2が登場していることだけ確認してください。
このように機能安全には、Proof Test Interval（T1）とDiagnositic Interval（またはSelf Test Intervalともいう）（T2）という２つの周期時間を表すパラメータが登場します。
Proof TestとDiagnositicの効果の違い
T1とT2の制約の違いは前述のとおりですが、もう一つ違いがあります。これはそのテストを行ったときに「効果」に違いがあるのです。Proof Test（T1）は、確定的な故障を検査することに使います。たとえば蛇口がさびて固まる、このようなものは実際に回して確認すれば壊れていないことが明確になります。電子回路でも、一旦電源を止めて回路を取り出し電子部品をはずして抵抗やコンデンサの値を検査すれば正常であることがわかります。このような試験を定期的にするのならば、それはProof Testです。
Proof Testは特定の故障モードを直接観測するため、試験直後にＯＫなら、その瞬間その該当部品の該当故障モードの発生可能性は「０」に落ちます。PFDのグラフが61508 Part6に載っていますが、上がって下がってを繰り返すイメージなっているのは、Proof Testのたびに該当の部位の故障率が０に落ちるためです。Proof Testの効果は、数値的にはその部分の故障確率が完全に０になることがポイントです。
一方電子回路の中の電子部品の故障は、前述のように解体して検査するなんて事実上できません。機能的な検査が精一杯です。機能的な検査をしても完全にはわかりません。電源回路部分の試験を定期的にやっても、「機能が動作しているから、多分、中の電子部品も故障していないだろう」という推測ができるだけです。このためコンピュータシステムではProof Testは現実的にできないと考え、T1の部分に10年とか20年つまり105hrなどの数値を入れることになります。これがPFDでλDUが支配的になる理由でしたね。このような場合に備え、電子部品では機能的な試験を自動的に短時間で行うことで、λDUを事実上λDDと同じように扱うと考えることが必要です。これによって、PFDの値を小さくできます。これが自己診断（Diagnositic：T2）です。
加えてDiagnositicはProof Testと大きく異なる点があります。前述の通り、機能的な試験をしても100%完全に正常かどうかはわからないということです。「たぶん大丈夫だろう」です。この「たぶん」の割合をDiagnostic Coverageといい、「こんな自己診断ならば検知効果は60%」のように考えることが規格で決まっています。決まっているといっても、特に数学的な根拠はありません。IEC委員のコモンセンスのようなものです。値も60%、90%、99%の３種類です。「それほどでも（Low）」「まあまあ（Middle）」「かなり正確（High）」の目安だと思ってください。大切なことは100%ではなく「疑わしさが残る」という点です。ここがProof Testと大きく異なります。Diagnositicの効果は、しょせん設計的なパラメータでしかなく「疑わしさが残る」のです。
ハグの日はProof TestかDiagnositicか
さてここで「ハグの日」というシステムが、冒頭に感じた通りProof Testなのか、それともDiagnositicなのかを考えてみましょう。３０３号室を１つのシステムとしてみた場合、みくりと平匡のどちらかが正気を保っていれば、相手が閉ざした扉を叩いて、何度も何度も叩いて関係の修復ができるでしょう。「いまさらです。大したことじゃありません。」なんて泣けるセリフが言えます。相手に障害が起こったことを知れば修復できます。問題はそれをどうやって知ることができるかです。そのためにハグの日を設定したとしたならば、これは機能安全的には少し考え直さなければなりません。
ハグの日のハグで、どのようなことも確実にわかり、関係が完全にリセットできるのならば、これはProof Testだと考えていいです。週に1度の長いインターバルでも、そこで確実に元通りになる（元通りだと宣言できる）なら心強いです。しかし、ハグの日にハグしたたからといって完全にリセットだといえない場合、つまりそこに「疑わしさ」が残るならば、これはProof Testとは言えません。そのハグはDiagnositic Coverage程度の期待効果を持つ、単なるDiagnositicだということになります。その場合、週に一度というインターバルは少し長いように思えます。
３０３カンパニーはPFHで評価するべき
ここでハグの日のインターバルをT2だとした場合、周期はどのぐらいならばよいのかを、T2が登場するPFHの式で確認してみましょう。事件がめったに起こらない場合の故障確率を評価するのがPFDでしたが、事件が頻繁に起こるまたは修復のために止めることができなシステムは連続系とみなし、PFHで評価します。様々な分野の機能安全のお手伝いをしていますが、実は機能安全のセクター規格での評価はほとんどPFHです。鉄道、産業機械、ロボット、自動車、いずれも呼称は多少異なりますが、評価次元は時間あたりの故障確率PFHです。
３０３号室カンパニーまたは婚姻をシステムとしてみなした場合、ケンカして一旦別居して互いに修復するようなケースがあるなら修復系とみなしてもよいですが、多くの場合決定的な事件があれば婚姻関係は即解体します。このような場合両方が故障状態に陥ればシステムは重大な危機を迎えます。こう考えれば３０３号室カンパニーまたは婚姻という関係は、PFHで評価した方がよいように思えます。ではPFHの式を見てみましょう。これは冒頭に書いたIEC-62061に掲載されているPFHの式です。
複雑そうな式ですが単純です。前項は、２人が同時に故障する確率を計算しています。後項はなにか共通の要因で、同時に2人が故障する確率です。え、同じではないか？違います。前項は異なる要因でも偶然同時に発生してしまう確率です。後項はたとえば同じご飯を食べて食中毒になるようなケースです。今回は婚姻継続が不可能な確率を想定していますから、前項は2人の別な職場が原因の場合、後項は同じ1つの理由をめぐっての見解の相違、という感じでしょうか。さて、T2は前項に出てきます。前項をもう少し解体してみます。
※βとはみくりと平匡が同じ原因で事件になる要因の割合です。共通要因割合。子供が多いと揉め易いのように考えましょう。したがって共通性がない故障の割合は（1-β）です。
※DCはDiagnositic Coverageです。自己診断の効果です。60%、90%、99%という値を取ります。したがって自己診断で見つけられないかもしれない故障の想定割合は（1-DC）になります。
両方が同時に拗（こじ）らせると３０３カンパニーは経営破たん
このように分解するとこの式の意味が分かりやすくなります。T2が入っている前項は、上記のカコミのように、4つの式に分割して考えることができます。このうち1つ目と２つ目は、「みくり」が故障状態（故障状態かもしれないも含む）の場合に「平匡」も偶然同時に拗らせてしまう確率です。3つ目と4つ目は、「平匡」が故障状態の場合に「みくり」も偶然拗らせてしまう確率です。どちらがが健全なら、ドアをノックし「いまさらですよっ！」と言葉をかけられますが、両方が故障していたら「じゃぁ、私たち終わりにしましょう」となりますからカンパニーは経営破たんを迎えます。この「偶然同時にこじらせてしまう確率」はとても深刻です。そうなれば神社のイベントに平匡さんや同僚は来ないでしょうから、梅原君は沼田さんに会えず終わっていたことでしょう。
この式をさらによく見てみます。「みくり」が故障状態の場合に「平匡」が故障する確率をどのように計算しているでしょうか。ここでDiagnositic Interval（T2）が登場します。自己診断は極めて短い時間を想定しますが、とはいえ自己診断のインターバルの期間は「故障しているかもしれない疑いがある」ことになります。これはPFD計算におけるT1と同じ考え方です。つまり期待値としてT2の1/2の時間の間は「みくり」は故障しているかもしれません。もやもやしているかもしれないのです。PFDの計算式の解説で出てきたMDT（Mean Down Time）です。MDTにみくりの故障率を掛ければ、その期間のみくりの平均故障確率になります。この状態になっている期間の確率に平匡の故障率をかけたものが、「みくり→平匡」同時故障発生確率になります。当然平匡→みくりの順番で発生することも予想できます。これによって、両方の故障確率を足すことで、自己診断していても異なる理由で偶然同時に故障する確率が求まります。
だいぶ本質に近づいてきました。ハグの日のハグが、【もしも完全にリセットするものではなく、ある程度の健全性を確認するきっかけを作る程度のもの】ならば、ハグの日はDiagnositic（T2）とみなすべきです。この場合、１週間に1度のハグでは「同時にこじらせる確率」を大きくします。ドラマの時間推移は現実とあまり変わらないようです。夏から秋にかけての１シーズンの出来事だと推測できます。その期間に平匡は、何度も何度も扉を閉ざしましたし、みくりも実家に帰ったりもやもやしたりと故障モードに陥っています。つまり１週間に１度のハグでは、週の半ばに「どちらも故障」という状況になることは間違いありません。T2としては長すぎます。
ハグの日を効果的にするシステムの再構築
ハグの日を効果的にする仕組み、または別な何かが必要です。ハグの日を完全リセットのタイミングとして活用することは有効でしょう。つまりどんなにケンカしてもハグしたらとにかくリセット、というルールにするのです。ハグの日をDiagnositic(T2)ではなく、Proof Test（T1）の位置づけにするのです。
しかしこの場合、ハグの日以外で互いに互いの状態を知って修復する機会をもつ仕組みが別に必要です。ドラマでは毎朝みくりが平匡を起こすと提案しています。寝る前のハグも希望しています。1日に2回状況確認のすべが生まれています。毎日ということは1週間に比べ時間のパラメータが1/10になりますから発生確率は1/10になります。これはSIL2をSIL3にするだけのインパクトがあるといっても過言ではありません。とても良いシステムの再構築だといえそうです。ただしDiagnositicは「周期的」「自動的」である必要があります。毎日ルーチンとしてとにかく実施することが必要条件です。気分でするとかしない、という人為的な要素が介在するのは、自己診断（Diagnositic）の要件に合わないからです。結構ムカついていても必ず実施することが大切でしょう。
機能安全に携わる技術者の多くはそれなりに高年齢でしょうから、こんなシステムの再構築、家庭では「いまさらですよ！勘弁してください！」と言いたくなりそうです。しかしそこは相手がガッキーだと仮定して納得してください。ガッキーが相手ならSIL2いやSIL1以下のシステムもSIL3にシステムを再構築できるということが機能安全的に証明できるのです。
結論
最終話最後のシステムの再構築提案は機能安全的にとても理にかなったものだとわかりました。1日未満のインターバルで互いの状態を確認しあい（Diagnositic）、異常に気づけばどちらかが修復に努め両方が同時にこじらせる確率を減らす。そしてそれでも存在する残存する潜在故障（（1-DC)×λDU）が発生してケンカになりそうなったら、週に1度のハグの日（Proof Test）でとにかく初心を再確認して洗い流す。このDiagnositicとProof Testの組み合わせが、SILのレベルを確実に高めることにつながります。さすが平匡氏。ひょっとすると機能安全のスペシャリストかもしれません。
う～ん。平匡さんと機能安全の話がしたかったです。残念ながらここまで考察したことで、さらに逃げ恥ロスを拗らせそうです。
逃げ恥に学ぶ機能安全でした。