欧州の鉄道技術・日本の鉄道技術
【RAMS】4-日本流とRAMS流の比較（第３・第４段階）

次に進む

１つ戻る

目次

0.はじめに、RAMS認証書をすぐ出して

1.機能安全とRAMS、SIL認証

2.マネジメントメカニズムの活用

3.日本流とRAMS流の比較【初期段階】　MS構築

4.日本流とRAMS流の比較【第３段階・第４段階】PRA,SRA,セーフティケース

5.日本流とRAMS流の比較【第５段階〜第７段階】

6.Codes of Practice(実績に基づく評価)

7.テンプレートによる対応

8.HAZOP・FMEAについて

9.認証コストを抑える工夫・プロジェクト体制別認証対応

10.安全関連・非安全関連機能の分別、国際標準化活動

11.セーフティケースの概要(EN 50129)

12.日本流とRAMS流の比較【第８段階以降】

13.EN 50128(IEC 62279)の構造について

14.信頼度と安全性について

15.RAMSクイズ

16.認証書とセーフティケースはセット、参考文献

17.V＆V

18.RAMSに基づくISA

19.RAMS認証についての誤解

20.RAMSの安全性立証戦略

RAMSライフサイクルの１２段階のうち、第３段階（リスク分析・評価）・第４段階（システム要求事項）について、主な相違点について説明します。下の図でいうと、システムの安全性の検討をしているあたりです。

ここで紹介したいのは、下図の「３．初期リスク分析（PHA）」（PRA含む）と「４．安全性論拠（セーフティケース）の作成」についての相違です。この両業務は、日本ではほとんど行われていないためです。

「５．RAMS目標」については、よく、「計算ばかりしている」と指摘されていますので趣旨だけご説明します。

なお鉄道信号メーカーでは、「（第３の）赤本」こと「列車保安制御システムの安全性技術指針」が制定されて以来、意識的にRAMSに基づく仕事の進め方を実践しているため、他の製品分野とは様相が異なっていますのでここでは信号分野には触れません。

　　　

上図は、クリックすることにより全体が表示されます。

ここで紹介したい主な相違点は、上図中で朱書きしている３．と４．の２点です。

• ３．初期リスク分析（PRA／PHA）の実施

初期リスク分析とは、この後に行う詳細なリスク分析（FTA、HAZOPまたはFMEA）の前に、もっと大きなレベルのリスクに対して検討を行う活動です。なお、リスクとは、危険な事象の発生頻度と、その深刻さの組み合わせを指しています。

※FMEAは、深刻さ（Severity）、発生頻度（Occurrence）、検出しやすさ（Detection）の3要素を抽出する手法のため、RAMSの規格要求との整合性があります。

• RAMS流では、自社ではどうにもし難いようなリスクまで幅広く、網羅的に挙げていかなければなりません。
• 日本流では、本当に影響を生じそうな大きな事項だけ取り上げて検討しますが、その他は頭の中で「影響なし」と結論を出してしまうため、ほとんど記録が残らず、検討したのか、見逃したのかが分からない状態です。

• ４．セーフティケースをまとめること

セーフティケース（Safety Case：安全性論拠）は、リスクをどう想定し、製品がそれらのリスクにどのように、どこまで対策するかなどを記述し、安全性を立証するための書類です。
セーフティケースにおける検討事項や責任分担は、第２段階で作成している「セーフティプラン」に基づいて行っていきます。

• RAMS流では、リスクをどう想定し、製品がそれらのリスクにどのように、どこまで対策するかなどを規定した「セーフティケース」という書類を、計画（セーフティプラン）に従ってまとめていきます。
• 日本流では、重要な事項の安全性の検討書類は作られます。ですが、想定したリスクの全体が見えず、また相互のつながりは明示されないため、重要なものだけ検討した（その他は放置）ように見えます。

PRAは、製品を取り巻くリスクを広く網羅的に抽出する活動で、抽出されたリスクがハザードとなる影響を分析するのが初期ハザード解析（PHA）です。これにより製品を取り巻くリスクを網羅的に抽出・把握するために行います。一連の活動ですので、ここでは「PHA」に表現をまとめます。

自社では発生をコントロールできないような（考えたくないような）リスクも抽出することで、網羅的に検討して（重大な）ハザードを起こさせないことを目的として行います。

−−−【この部分追記】−−−−−−−

なかなかイメージがつかみずらいと思いますので、欧州の企業での鉄道信号製品についてPRAに書かれる例を挙げると以下のようなものです。

• 車両や車庫への技術要求が変わるあおりを受け、信号製品への技術要求が複雑化する。
• 運行ルールが、信号製品として受け入れられない内容に変わる。
• 追加的な技術要求が加わり、信号製品の守備範囲が変わる、業務量が増大する。

　　　・・このような、鉄道信号業界では「あるある、そういうの困るよね。でも、製品の技術の問題じゃないでしょ？」と感じるようなリスク、そのような製品を取り巻くリスクが初期リスク分析（PRA)の対象と考えてください。
　ちなみに対策としては、リスクをなくすことは難しいため、リスクの影響を減少させる（mitigate）対策を挙げていきます。コミュニケーションをとるとか、代替できる方針を試験して提案するとか、そんな当たり前なことでいいのです。その対策で十分かどうかは、後で分析し検証しますから。このような内容なので、メーカーさんにおかれては、定式化しておくと便利です。さらに、メーカーによってはプレミア感のある立派な名前をつけている場合もあります（このページにあるSPHもその一つといえそうです）。
−−−−−−−−−−−−−−−−−−−
　この後の段階では、日本流でもRAMS流でも部品単位でのリスク分析（SubSystem Risk Analysis)が行われます。これよりも大きなレベルのリスクを網羅的に把握することが必要であり、かつ、リスク分析には以下のような「リスク」があると考えられますので、その点からも、車両、運転、電力、信号など、一見関係なさそうなさまざまな分野の専門家を加えて実施することが必要です。
　　　　リスク分析のリスク

• リスクを認知するかどうかは個人の経験、考え方によって異なる場合がある
• 考えたくないようなリスク（自社の責任ではないものや、発生頻度が低いが被害が大きなリスク）が抽出されない。
• 一見小さなリスクをきっかけとする、大きなリスクの存在を見落とす。

 

こうして抽出したリスクは、さまざまな列車の状況下を想定し、ハザードとなるか、ならないかを検討していきます。

分析の方法はさまざまにありますが、欧州のメーカーでは、駅停車、駅間停車、駅場内走行中・・などの列車位置や、列車の運転状況と、技術分野（線路、土木構造部、信号、車両など）を表の形式にしておき、該当する状況においてリスクとなるかどうかを評価する様式が使われています。見逃しをしていないことが見えるためです。

一方、あまりに網羅的すぎるため、技術者なら「そんなハザード（リスク）は起こらないだろう」と瞬時に分かる変なものも多数出てきます。そのため、

• 日本流では、大きなリスクのみ自社内または設計会議で検討する。頭の中で「影響がない」と分かるようなリスクは、わざわざリストにしたり、記録したりしないため、ほぼ記録が残らない。
• RAMS流では、「こんなリスクが挙がった」→「検討して、『影響無し』と結論を出した」ことをすべて記録し、対策が終わる（あるいは対策が不要と確認される）まで検討を続ける。

日本流の場合、このレベルのリスクアセスメントは、常識的に判断できる事項と考えられるため、わざわざ行いません。そのため、何も記録が残らないために、関係者以外からは、�@そのリスクを見落としたのか、�A検討したが影響ないと結論づけたか、どちらなのかは一見分からない状態となります。�@と�Aは、過失の有無の差があり、いざというときには雲泥の差となってしまいます。

ただし、日本流では安全性が劣るのかというとそうではなく、設計会議（Workshop)が開催され（入札前のことも多いのですが）鉄道事業者と、鉄道事業者に召集されたメーカー各社が、過去の苦い経験も含めて真摯に検討を重ねるため、製品の品質は高品質に出来上がります。面談（やweb会議）による課題解決力、すり合わせ力が十分に発揮されています。

このような高品質な日本流による製品でも、海外のお客さんに「わかってくれ」といったところでRAMSに関する証拠物が無いと、理解されることはもはや難しいかと感じます。

一方、RAMS流では、さまざまなメーカーが1つのシステムを作り上げるため、PHAによりリスクを潰していく活動を、データを共有しながら実行します。また図面データも電子ファイルにて交換します。そのため、PHAはエクセルではなく、プロジェクトマネージャの指示されるトレーサビリティ管理ソフトで入力したリスクが潰れるまで管理し、共有します。またその一方で図面をモデリングソフトによって製作しますので、お客さんにリスク管理について説明するための図も、設計業務のための設計図も、同時に作業が進められるので効率がいいです。また第3段階だけではなく、その後の段階でもリスクを検出してはハザード解析を行い、それがハザードに至らないように潰したことを記録していきます(下図）。

 

 

このような形の記録が無い場合には、RAMSにおいてやるべきことを（見た目上は）行っていないと見なされるため、不適合となってしまいます。

順番は前後しますが、上図の「5　RAMS目標」のうち安全性（Safety）の目標の趣旨を簡単に申し上げます。

目標SIL　（又は目標THR（許容ハザード率）、あるいはTFFR（許容機能喪失率)がインテグレーター（＝車両メーカー）から与えられていることが多いと思います。一方、日本流の場合は、定性的な目標になっていることが多いです。目標がはっきりしなくても、メーカーでは自分の技術力や過去の同様製品を踏まえてベストを尽くします。

日本流は一見理想的で効率がよいのですが、ISO9001のようなマネジメント規格や、RAMSでも「そのやり方が組織に定着しているかどうか」（安定しているか）、という観点で評価しますので「人によってはその業務、行わない可能性があるのでは？」と疑われるかもと思ってください。

RAMS流では、部品メーカーのお立場では、割り当てられた目標を達成するように製品に使うパーツの選定や設計・製造を行い、目標を達成したことを証明します。一方インテグレーターのお立場では、全体の目標を決定して、各部品（サブシステム）にそれぞれ目標を割り当てなければなりません。

目標を決める手順を図3に示しますが、故障解析をわざわざ行わずに初めからSIL2、等と鉄道事業者（ユーザー）から指定される場合もありますし、初品でなければ故障解析を行わない事もあります。

ですが、基本的には各機能についてハザードに対する許容ハザード率（THR)又は、許容機能喪失率（TFFR)を全体からパーツへと割り当てていき、システムによってはその割合をSILで表します(SIL4、等）。故障には種類があり、ランダムに起きるものであればFTAで概算することも可能ですが、ソフトウェアに関するシステマティック故障（決定論的故障）に対しては効果が未知のため、管理方法の質を高めることが取り入れられています（詳しくはソフトウェアに対する規格であるEN50128についてのところで説明します）。

細かい話ではありますが、RAMS(EN 50126-1:2017)では、RAMS目標は機能に対して割り当てることが基本ですので、モノではなく、そのモノの持つ機能にそれぞれTFFR（許容機能喪失率）を決めることとされていますので、EN 50129:2018 Figure A.4などではTFFRを割り当てますが、概念上はTHRと同じものです。

セーフティケースは、安全性に関して立証し、その証拠が盛り込まれている膨大な書類の総称です。後述するように、製品のハードウェア・ソフトウェアが安全性について管理されていることを証明する書類であることから、行政の認可審査や、メーカーさん同士の製品の安全性を立証する書類などとして利用されています。

安全性、といっても、RAMSは機能安全に基づいていますから、予想されるリスクを、許容される程度まで小さくしていることの証明のことです。過去何十年間事故が無い、という類いのことではありません。

ただし、欧州では、欧州法に基づく「CSM−RA」という法令により、新規設備導入等の何らかの変更があった際に行うリスク分析（一般的には鉄道運行事業者や、インフラ管理会社が行う）において、製品の使用実績に基づく実証も、既存路線の既存設備の変更であり、ハザードがきちんと整理されている、等一定要件を満たす場合には認められることがあります。これをCoP（Code of Practice）と呼んでおります。詳しくはこちらで後述します。

 

RAMS流との違い

日本流でも、RAMS（より正確にはRAMSのシリーズであるIEC 62425)に基づく「セーフティケース」に書かれるような、安全性を立証する活動自体は行われています。

大きな違いがあるのは、�@セーフティケースの前提とするリスクが、すべてのリスクを網羅していない点です。一つ前の段階では、上述のとおり初期リスク分析（PRA）を行いますので、初期リスク分析において挙がったリスクすべてに対して、どのように安全性を保つか、という観点でセーフティ−ケースが作られていることが重要です。このような、前の段階での検討結果を、次の段階で検討していくことを、追跡可能性（トレーサビリティ）、といい、RAMSではトレーサビリティが確認できることが重要とされています。

リスク分析に関しては、対応する前後の段階で一対一で対応している必要はありませんが、部品がブレークダウンされるに従って、リスク分析もより詳細に行われていることで網の目のようにもれなくリスクを救いとったことを立証するわけです。

・製品を取り巻くレベル：PHA(PRAも）

・システムレベル（信号、運行管理装置、ブレーキ系統、といったレベル）：SHA

・サブシステム（Subsystem)、構成品レベル：SSHA

・インターフェース仕様レベル：IHA

　　以上をDHA(DRAとも）といいます。詳細リスク分析です。

・運行環境で生じるレベル：OHA

・・・とだんだんと、段階を追ってブレークダウンしていくことで、RAMSの元になる「機能安全」の考え方（前掲の図の青丸に入っているかどうか検証していく）に基づき、前の段階で網羅的に把握されたリスクや、お客さんの要求事項に対して十分に安全になっているかどうかを文書で立証して、すべてのリスクを、一定水準まで潰していきます。

RAMSは、大きな項目から小さな項目へ、・・と、だんだんとブレークダウンしていく構造ですので、初期段階では、まだ製品のシステム構成や各システムの機能が決まっていませんので、対策をたてようにも方針のようなものだけになりますが、製品構成がはっきりしてくるにしたがって、リスクに対する対策についてもサブシステム単位→部品単位、・・と、より具体的に決められるようになってくると思います。

例えば、「人間の取り扱いミス」というハザード源に対する対策は、最初のほうの段階では「システムで矛盾を検知して防ぐ」という方針で、システム構成が決まってくると「〇〇システムで矛盾を検出して防ぐ」→「〇〇装置の入力画面で、〇〇ボタンと、〇〇ボタンの両方の操作が〇秒以内に入力されなければ受け付けない」・・などと具体化していき、その対策の効果を検討し、かつ、記録していくわけです。

こうして、RAMSにまつわる書類がどんどん増大していきますけれど、その一方で、リスクが、許容されない深刻なハザードまでは至らないことが証明されていくのです。

一方、日本流では、網羅的に検討されていない（又はその証拠がない）など、RAMSを意識して実施していないことから、外見上は、前後の工程での検討結果とのつながらない（追跡可能性（トレーサビリティ）がない）状態になっています。

仮に、日本流でもPHA（初期リスク分析）のようなことが行われていたとしても、セーフティケースのようなまとまった形式ではなく、「●●に関する検討」「●●のリスク分析」「●●のFTA解析結果」などのように、あちこちの書類に散らばって書かれているならば、 トレーサビリティを調べるだけでも時間がかかってしまいます。例えるなら、割れたグラスの破片を示して、「割れているが、全部あるから同じだ」といわれても、確認するためには組み立てる必要があり、無駄に時間を費やすことになるため、認証コスト増となります。

トレーサビリティが取れていたとしても、他の鉄道システムとの間で異なる手法がとられるなど、異質なセーフティケースが混ざっている場合には、やはり問題となる可能性があります。下の図は、リスク分析手法が違い、生じるおそれのあるハザードが異なるシステムが混ざっている鉄道システムを模式図です。事故が起こるのはシステム境界部だ、という経験則があるため、隙間なくリスクはつぶしたいところです。

一方日本流でも広くリスクを分析する取り組みも行われています。鉄道運行中に検出されたハザードについては、当該メーカー以外のメーカーにも保安情報として情報が伝えられ、業界として再発防止策を検討することが行われております。RAMS流ではOperational and Support Hazard Analysis (OSHA)が行われていますが、あくまでメーカーごとの情報共有にとどまっています。

 

さて、次の図2は、セーフティケースを組み立てている例です。これは、図3のシステムA（部品ｂ〜ｄから構成）について、部品ｂ（青）は主契約者が、部品ｃ（ピンク）は一部（ｃ2）を部品メーカーから調達、部品ｄ（黄緑）は部品メーカーから調達するので、調達品はその部品メーカーにセーフティケースを作って頂き提出して頂くことで、システムA全体のセーフティケースが完成する様子について示しています。

例えば図2の中の「ユニットｃ2」のメーカーにおいては、ユニットｃ2をそのまま販売するので、ユニットｃ2の基本構成（GP)に関するセーフティケースだけを提出しています。一方「ユニットｄ1」は路線に合わせて一部改修するため、ユニットｄ1のGPのセーフティケースと、改変する差分に関するセーフティケースの2つを提出しています。GP（Generic Product)については事前に準備しておくことができますから、個別の鉄道プロジェクト案件で取り組まなければならないセーフティケース作りは、仕様変更する部分（SA（Specific Application)）の部分（赤枠）だけになるため、何がGAなのかうまく切り分けられると、認証コストや時間節約の面でかなり有利となります。

 

 

アウトプットとの追跡可能性（トレーサビリティ）

RAMS流では、インプットに加えて、アウトプットについてもトレーサビリティ（追跡可能性）が必要です。

上図のように、リスク分析結果記録や、製品仕様書に引き継がれることや、使用者が注意すべきリスクがあるなら取扱条件書（SRAC）へ記載されるべきです。　例えば、「無線が使えない」というハザードが生じる可能性が残っていて、ユーザーが対策を取らなければならないならば、SRACには、「無線が使えない場合には、列車は常に速度を落として走行する必要がある」などを書かなければ、安全性が保てないはずです。

日本だと当然鉄道事業者が仕様書を作成し、技術力もありますから、ユーザー側はメーカーから何も言われなくてもどうすべきか分かっています。しかし海外では、鉄道事業者が何も言わなくても分かっていることは期待できませんので、このような記述がSRACに無いなら、メーカーの責任問題になってしまいます。

ところが日本流ではこれらの書類はそれぞれ独立してしまっており、トレースが無い状態のことが多いです。リスク分析の結果が、どこにどうつながっているのかが分かるような書類構成になっていないのです。

セーフティケースまとめ

まとめると、日本流（※くどいようですが、暗黙知をベースとした業務のやり方を「日本流」と言っています）は、・・・

• 安全性の確認をしているが、前の段階までに挙がったリスクを検討するようなトレーサビリティが確認できない（あるいはPHAを行っていない）。
• 　セーフティケースのようなまとまった書類が作成されないため、さまざまな書類に散らばっている。
• 　後の段階の書類（SRACなど）とのつながりがない。
• 一方、運行中に生じたリスクは業界として対応するなど実質的な安全性を保つ活動はさかんであり、その結果、製品の安全性は十二分に高い。

　これに対してRAMS流では

• 前の段階までに挙がったリスクを検討し、許容されるレベルまでリスクを下げる対策をとったことを証明する書類を作成し、後の段階に引き継いている。
• 利用者が注意すべきリスクは分析（OSHA）され、説明書（SRAC）へ引き継ぐなど、前後のトレーサビリティーが確保されている。トレーサビリティが確認できる書式（リスクマトリクス）を使うようにしている。