RAMS[31] Safety Case 2

前回はSafety Caseとはどんなものでどんな意味を持つのかについて書きました。今度は、そのSafety Caseは具体的にどのようなもので、どのように書かなければいけないかを少しずつ書いていきたいと思います。それは決して難しいことではないと思っています。ちょっと古いですが、2007年9月版のIEC62425をベースに話していきます。今は新しいENも策定していますが、基本は変わらないのでこれで十分理解できると思います。また、何回も同じことを言ってしまうかもしれませんが、そんなときはそこは重要だと思ってください（笑）。

第5章にSafety Caseの受け入れの条件が書かれています。つまり、Safety Caseとして認められるための条件です。

２．品質管理の証拠　→　Quality Management Planを作ることは知っていると思いますが、この計画が正しく実行されている証拠です。

３．安全管理の証拠　→　品質管理と同じようにSafety Management Plan 通りに管理が正しく実行されている証拠です。

４．機能と技術安全の証拠　→これは開発製品そのものの安全性を証明するための証拠です。

この3本柱がRAMS規格の本質です。簡単でしょ？　そしてそのSafety Caseの構成もIEC62425に規定されています。

この規格にさりげなく表れているのがこんな文章です。「define or reference the system/sub-system/equipment」安全装置は階層があります。多くの場合はユニット、装置、システムでしょう。当然システムは複数の装置を持ち装置は複数のユニットを持ちます。なので、ターゲットスコープが大きければ大きいほど、安全性を証明するドキュメント（Safety Case）は膨大になるという事です。なので、既に書いたようにRAMSはGP、GA、SAと階層化すると書かれているわけです。

Safety Caseは6部構成で成り立っています。上記の「品質管理の証拠」「安全管理の証拠」「機能と技術安全の証拠」の他にあと3つあるという事ですね。それでは順番に見ていきましょう。

１．Definition of System

色々なSafety Caseを見てきましたが、得てしてDefinition of Systemを御座なりにしている人が多いです。多分、Definition of Systemは安全性に関係ないので設計図書からコピペしてOKとしている。ページ数も非常に少ないですね。確かに、規格上もほんの数行しか書かれていないので手を抜いてしまうのでしょうか。どうしてDefinition of Systemがそんなに重要なのでしょうか？

それは、Safety Caseは第三者が見るものだからです。当然、認証機関も見ますが、顧客、当局、事故が起きれば裁判官など、鉄道システムに詳しくない人も見ます。なので、このSafety Caseの範囲は何処？　この製品・システムは何をするものなのか？　どうして安全性が要求されるのか？　などをここから読み解きます。また、Definition of Systemは責任の範囲を明確にするためにも必要です。なので、システムの定義は自製品にとどまらず、本製品がどのように使われるかがわかるようにある程度広範囲から説明することが重要です。説明も専門用語だけではなく平文で容易にわかるように書くことも大事なことです。そうでないと、その後に続くリスク分析も全く理解されません。説明はできるだけ図を用いるのがいいでしょう。設計図書はその製品を熟知した人たちが分かればいいので、即専門用語、文字が小さくても十分理解できます。でも、それはSafety Caseに関しては駄目なのです。

Safety Caseを作成する前に計画図書を作りますが、それも同じでその時から人に説明するシステム定義を作ってしまいましょう。そうすれば、Safety Caseを作るときに新たに作成する必要はありません。重要なのは社内図面をそのまま流用せずに、非専門家でも理解できるという事です。

余談ですが、Definition of Systemのように種々のドキュメントで使用されるもの、他にもabbreviationなど、そのドキュメントを読むにあたって近くにあったほうがいいものは、本来であればそのドキュメントそのものに書かれているのが良いとは思っています。しかし、それは色々なドキュメントで使用されるので変更があった場合にすべてのドキュメントの修正が発生するという事にもなります。この辺は考え方もあるでしょうが、参照するのもありだとは思いますが、より良いのは、はめ込み文書で管理するのが個人的には良いと思っています。そうすれば大本を直せばすべての文章が治る。まあ、そういうツールはあるかもしれませんが、ワードの機能だけで十分できます。

2. Evidence of quality management

対象とするシステムが安全だと受け入れる最初の条件が品質が満足されているという事と規格に書かれています。そして、それは過去ではなくライフサイクルを通して継続して効果的に品質が管理されていなくてはならないとも書かれています。Systematic Errorを排除するためには品質管理で行うしかありません。よって、RAMSの一翼は品質管理なのです。では、この章には何が書かれるのでしょうか？　タイトルにあるように、品質管理のEvidenceを示すのがこの章の目的です。これもよくあるのは、Quality Assurance Plan で書いた内容を一つずつやったと書く形式です。Planが表になっていればその横にチェック欄を設けてやりましたチェックを付けるもの。確かに品質管理の実行した証拠と言えば証拠かもしれませんが、これをもって自信をもって品質管理は大丈夫だと言えますか？　簡単に言ってしまえば、自信をもって説明すればそれがこの章の答えです。ただ、客観的な証拠は示す必要があります。あと、もの作りは品質管理の範疇です。例えば要求管理などは品質管理で行います。では、安全要求はどうでしょうか？　基本は安全要求も品質管理で管理します。安全性はハザードログでクローズを管理するので一部ラップしているところがないとは言えませんが、あくまでももの作りは安全機能を含めて品質管理で行うものです。

品質管理で行わなければならないことは沢山あり、SILによっても変わりますが、規格に書かれている（Table E.1 とTable E.8）のでそこから必要な実施項目をQuality Assurance Planで計画します。なので、品質管理のスタートはQuality Assurance Planを作成することから始まります。では、Quality Assurance PlanとSafety Caseの関係はどういう関係でしょうか？Quality Assurance Planとは品質を確保するための計画です。未来形ですね。そして、Safety Caseは結果です。過去形ですね。つまり、今回のプロジェクトでは品質を管理するためにこうするという計画がQuality Assurance Planに書かれます。そして、その計画に基づいて開発が行われる。Quality Assurance Planを行えば目標の品質が確保できるとすれば、開発が終わった時にはその製品は目標とする品質を確保できているはずということです。Quality Assurance Planをどのように書けばいいかはまた別のブログで書くことにします。

繰り返しになりますが、Quality Assurance Planで書いてあることを一つずつ、〇　OKとかだけを書くのは本項目の答えにはなっていません。

Quality Assurance Planと一対でquality management reportがあります。これが品質管理の最終報告書になります。なので、結論と証拠（quality management report）をこの章に示せばよいという事になります。

３．Evidence of safety management

この章は本来の目的である安全管理の証拠を書く章になります。品質管理と安全管理とはどういう関係にあるのでしょうか？　ちょっとわかりにくいですよね。もし、この装置が安全に関与しないものであればその装置は機能が正しく動くこと、つまり品質管理が大丈夫なら製品として問題ありません。しかし、いま貴方が開発しようとする製品は安全を司る製品です。安全装置としての機能の管理が必要です。この違いが分かるでしょうか？　普通の製品は機能を満足させるように作ります。そしてその機能は製品としての機能なので、全てが明らかになっています。要求機能が明確であれば、後は正しく設計する（品質管理）を行えばその製品は目的を達したことになります。

しかし、安全にかかわる装置はその安全機能は未知です。つまりその安全機能を見つけることから始まります。そして、その安全機能を必要なレベルまで上げなくてはなりません。この一連の管理が安全管理になります。やることが決まれば後は品質管理の仕事です。なので、最初に上げた3つの柱が安全関連装置作るうえで必要になり、それぞれは密接に関係し、利害関係が発生するのでそれぞれに独立性を持たせるわけです。

ここで良く聞かれるのに安全機能は未知ではなく、既知ではないですか？と聞かれます。また、リスク分析をしている段階で安全機能があるからこのハザードは問題ありませんと分析するケースです。この違いは何なのでしょう？　それは既に経験から安全機能が見えているということです。例えば、大昔、鉄道ができた100年前、運転士が速度を出し過ぎで脱線したとしましょう。そんなとき、速度に制限をかける機能をいれたらいいんじゃないですか？　とか、列車同士が正面衝突したから、進路を排他的に制御できる連動装置をいれたどうだろうと。。。。こういう経験のもと信号装置が装備されていきました。そもそも、列車の運行に必要でない機能を持つ装置が追加されたのですから、この装置を開発しようとした場合はそもそも安全機能の塊なので機能そのものに見えてしまうわけです。かといって、違いがあるわけではありません。安全装置の安全機能は既知だろうが未知だろうが機能です。ただ、分析するときに、どの視点で行うかは変わります。私としては既知な安全機能であれば、機能としてあげて分析しても問題はないと思っています。

安全管理も同じようにドキュメントをもって安全であるという証拠を説明する必要があります。安全管理には以下のような注釈があります。「Large volumes of detailed evidence and supporting documentation need not be included, provided precise references are given to such documents.　」つまり、資料が膨大になるのでリファレンスを付けることによってSafetyCaseそのものには記載する必要はないという事です。繰り返しますが、参照先には容易にたどり着くようにしておく必要があります。

規格ではSafety life-cycleと定義していますが、いわゆるV字モデルのことを示しています。また、この章ではSafety life-cycleで行うべきことが記載されています。