欧州の鉄道技術・日本の鉄道技術
【RAMS】5-日本流とRAMS流の比較（第５〜第７段階）

次に進む

１つ戻る

日本流とRAMS手順との比較

第５段階〜第７段階

RAMSライフサイクルの１２段階のうち、第５段階から第７段階付近の主な相違点について説明します。

　

第５段階は、前の段階で作成されたシステムの基本設計に基づきながら、システムの詳細を決めていく段階です。製品を構成する部品に対してシステムの機能を割付けます。また、システムの目標を分解し、部品の目標値を定めて各部品に割り当てていきます。この目標に対してシステムに求められる要求事項を達成できるかどうかを確認することが行われます。

詳細なリスク分析は、具体的にはFTA,FMEA,HAZOPなど手法はさまざまながら、システムを構成する部品についてシステムは部品のリスク分析・ハザード解析（SHA、SSHA）が詳細に行われることは、日本も欧州も同じです。同じですが、前のページに記述したように前段階で検出したリスクに基づくハザード解析を更新していく点については、RAMS流ならではの業務と言えます。

【図1】　RAMSライフサイクル（RAMSの第5段階〜第7段階〜廃棄）

　　　

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

リスク分析といえば、「実績に基づく評価でもよい」って書かれているんでしょう。

といっても、条件がついていますし、ごく一部分だけです。ときどき都合よく誤解されていましたので、後述しますね。

 

ここでは、上図で赤で書いているうちの６．について記述します。


６．リスク分析について


　リスク分析については、前述の図のように、機能安全の考え方から、想定されるリスクが十分小さくなっているかどうかを判定するのでしたね。 リスク分析のやり方についても、HAZOPの適用が有無の違いや、トレーサビリティに関して下記のような相違が見られます。

  • RAMS流：前後の段階とつながる形で実施されており、どう対策をしたかを評価及びエビデンスが記録されており、すべてのリスクがある程度まで（許容できるところ以下まで）つぶれていることが明確です。
  • 日本流：重要な事項の安全性の検討書類は作られます。ですが、想定したリスクの全体が見えず、また相互のつながりは明示されないため、重要なものだけ検討しており、その他は放置しているかのように見えてしまいます。

前後のつながりを書類に明記していないならば、トレーサビリティが取れていることの説明に苦労することになります。下図2のようなつながりがよく見える資料作りがとても大変になります。

【図2】トレーサビリティ

 　　　　　　※トレーサビリティがある場合でも、上流と下流で「粒度」が違いすぎると、後々苦労します。

トレーサビリティは、上流（システム要求事項）から下流（製品仕様）に至るまでの間に、トレースが取れることというと見逃しが無いことが必要で、それを立証するのが必要です。

具体的には、図3のように各段階において、上流（インプット）側の要求が、下流側に反映されていることを示すことが出来ないと立証することが難しいことから、この後に記述するように、要求事項を整理・管理して番号をつけるソフトウェアや、要求事項の粒度をそろえるようなことも必要になります。

【図3】トレーサビリティが取れていることの実証

 

プロジェクトの開始から最後まで、たくさんの部門の多くの方が関わるのに、トレーサビリティを保つ、ということは非常に難しいことです。

そのため欧州企業では、とりまとめメーカーと、部品メーカーとの間の仕様書において、使用しなければならないRAMS支援ソフトウェア（トレーサビリティーツール）を取り決めて、データを交換することでトレーサビリティを保つことが行われます。データを作ることが手間なように感じますが、元々、図面は電子ファイルのみ正本として、部品メーカーから車両メーカーに提出する書類の多くが電子ファイルになっていることから、社内の仕事の延長で行える仕組みとなっています。

そのような環境ですので、要求事項のリストをとりまとめ企業が作成し、各部品メーカーに電子ファイルで展開して設計に生かす（トレースをとる）ことが行われています。IBM社のDoorsや、ダッソー・システムズのENOVIA（ツールソフト）、３DEXPERIENCE（３Dモデルと紐づく情報の管理ソフト）等、図面上の部品と、要求事項を紐付けて設計を進めることが可能で、もし要求事項に変更が生じた場合でも、関係箇所が自動的に更新され履歴も記録される有用な機能をもっています。

あるいは、要求事項の粒度が大小さまざま混在している場合、ある段階では気にならなくても、そのリスクを受ける次の段階では、粒度が大きいものは対策が多岐にわたってしまいつぶしきれない（対策が完結しない）など、非常に苦労する原因になりかねません。そんな時、トレーサビリティ支援ツールを使うことでは、粒度のバランス調整のような全体を見ながら部分修正をしていくことが容易になる利点もあります。

リスク解析のやり方についても、欧米企業ではIsographのような、fault tree解析を行うことに特化したソフトウェアを利用し、そのデータを納品します。日本ではFTAの図記号を作画するためのソフトウェアが使われていますが、後から何か修正が必要となった場合には、修正の反映が非常に大変で効率が悪いのではないでしょうか。

リスク解析の内容自体は、日本流でも、RAMS流でも技術者の頭の中では同じだと考えられますので「相違」、とまでは言えないのですが以下のようなことが違いとして挙げられます。

  • RAMS流：ソフトウェアは、決定論的に（ソフトウェアに作りこまれたリスクは必ず現実化すると考え）リスク分析する。（どうしてもいつかは必ず起こるリスクのため、マネジメントに力を入れることや、リスクが顕在化した場合も重大な事故にならない対策に力が入っています）
    　　　　　　　：ハードウェアは、確率論により、製品に対する技術要求事項に対してリスク分析する。
  • 　　　　　　（そのため、確率的な故障への対策は冗長化（多重化）や、冗長系であっても共通原因故障を防ぐ（※）ことに神経を使います。）
  • 日本流：機能又はモジュール単位にリスク分析が行われる。　ソフトウェアに対してコーディングミス、プログラム上の欠陥はリスクとして挙げられないことも。
　

※何度も申しますが、暗黙知ベースの業務の進め方のことを端的に「日本流」と表現しております。日本の会社でも当てはまらない方は多くおられますが、どうかご容赦下さい。

追記

ここで申し上げているリスク分析は、前の段階で立てた目標SIL　（又は目標THR（許容ハザード率）。もし「機能に対する目標」（TFFR：許容機能喪失率）としてインテグレーターから与えられている時はTFFR）を達成するかどうか、リスク分析を行うことです。

RAMSはFTAばかりしているというのは、このうち、確率論的な故障に対するTHR（又はTFFR)を達成しているかどうかの話です。

、

　少し細かい話ですが、「共通原因故障」という考え方が機能安全系の規格には必ず規定されています。これは、もし下図５のようなことがあると安全性を高く保つためのANDゲートが突破されてしまい安全が保てないために、独立性を検証するものです。例えば、同じ１本のケーブルに大切な信号を流しているなら、その線が切れてしまったら大変なことになる・・ということを防ごうという話と理解願います。そのため、主に物理的なモジュールの切り分けや、ソフトウェアが使用するデータ等のリソース、ハザードの影響を検証します。

ISO 22163（RQMS)では、外部調達時に調達先への安全性目標とともに伝達が必要な事項です。

（再掲）【図4】目標THR（目標SIL）の決定
【図5】共通原因故障の回避の必要性

追記ここまで

　路線の特質に合わせたリスク分析

鉄道は、路線によって利用形態が大きく異なりますので、発生するリスクは路線によってさまざまに違います。日本（又は欧州）で安全稼働実績がある製品だからといって、外国で安全に稼働できるかどうかは別の話で、素直に受け取ることができない訳です。例えば、欧州で安全に稼働している製品を日本で採用する場合に、「多客で、駅間が短い日本で使って大丈夫か？」と感じますよね？　こう感じるのは、高頻度に加減速を繰り返す過酷な環境の日本では、故障や事故に至る可能性を感じている訳で、つまり、日本特有のリスクに対応しているかどうかが重要であって、欧州での実績はあくまで参考程度な訳です。

RAMSでは、上述のようにトレーサビリティが重視されていますので発生リスクが違う路線に納入される製品であるなら、インプット情報である「リスク」は、使う路線の環境のものに置き換えて、それでもなお対策が十分なのかを改めて検討する必要が生じます。

もっとも、大抵の日本製品は過酷な環境で使われていますから、何もせずとも対応している（製品仕様はそのままで、書類の内容の再構成で対応できるハズ）のではないかと考えますが、例えば「暴力行為（Vandarism）」への対策、「平均気温が高い」ことへの対応、のような部類のリスクについては対策が必要になるかもしれません。
　そのようなリスクに対しては、仕様を追加して対策を取り、許容できないようなハザードが起こらないように対策が取れています、とリスク解析結果を手に説明することが求められます（下図6参照）。こうすることで、製品を受け取る側にとっては、「この路線のリスク対応している製品だ」、と稼働前に確認をすることができることが、RAMSの大きな利点となっている訳です（もっとも、海外の鉄道事業者も初見の製品は厳しく試験すると思います）。
　

【図6】路線のリスクに対して対策を検討

 

ということは、日本で長年リスクに耐えた、というような外国の話をするのではなく、「納入先路線（A国）で通常考えられるリスクに対応している製品だ」と説明できることのほうがずっと重要になります。

実績による評価の活用と条件

ところで、RAMS流においても、RAMSを行ったからといって不具合を発見することは難しく、例えば、ソフトウェア内の作り込まれたバグを見つけることは困難です。日本流ではリスク分析が行われていない（ように見える）ため、不具合の発見は要所要所で行ってはいますが、最終的には完成した製品に対する試験で確認しようとすることから、完成試験の工数が膨大になってしまいます。

ところがリスク分析を行う具体的なやり方の一つとして、RAMSには「実績に基づく評価（CoP：Code of Practice）」が掲載されておりまして、これをうまく適用すればRAMSに基づく試験（特に完成時の試験）が減らせられることから、どのような場合に適用できるかという点に関心が高くなっています。これについては近年、次ページのように欧州鉄道庁や英国から適用ガイドラインが発行されたことで、CoPが適用できる条件が明確になりました。

古い話ですが2000年代までは安全な稼働実績が説明できるならば割合何でもよかったのですが、もともと既存路線で使われていた装置を継続的に利用するための激変緩和措置の面があるため、現状の欧州では過去の話になっています。現状では実績に基づく評価が行える場合には条件があり、同じ環境で使われ、同じようなハザードが使用実績において網羅されていることが実績から実証できる場合、などが書かれています。そのため、単に何十年使用実績があるというだけでは根拠として弱くなっています。この使用実績に基づく評価については、次のページで紹介します。 

 

設計・製造・試験について

第6・第7段階は、これまでの段階で計画してきた設計や製造がいよいよ（やっと？）実行されて、計画どおりに実行できたことが確認される段階です。

日本流とRAMS流の違いについては、マネジメントの力を使って業務が行われたかや、実行結果の検証(Verify)と妥当性確認(Validate)をする者の可否判断をした者の適切(ICP)さや、その理由が明確になっているか、という点に違いがありますが、それについては前述のとおりです。

日本でも行われている、節目で行われているデザインレビューについても、IEC 61508（機能安全）の規定を受けてRAMSにも引き継がれているものであり、事実上義務づけられています。そのため、デザインレビューを行う者の資格を定めることや、行ったけれどもいつ、何について、デザインレビューとしての観点で行ったことが明確に分かる必要があります。何らか改善する必要がある場合に、その改善についてだけ記録しがちだと思いますので注意が必要です。

また、これも既述ですが、RAMSライフサイクル上、この後段階に当たる業務への引き継ぎが行われるかどうかも、違いがあります。例えば、この図に挙げた、SRAC(取扱条件書）への漏れなく製品使用者に伝えるべき事項が記載されているかトレースがとれない点等に違いが生じます。

  • RAMS流：判断を下した理由を記録する。例え何の問題がない場合も、問題がないことを確認したことが分かる記載があること。
  • 日本流：結果確認（Verify)をした者の適切さや、判断の根拠はわざわざ記録しない。計画どおりに実施されたかどうかの観点から検証が行われない（別の観点から検証されている）。

 

一方、RAMSだからといって製品に試験を膨大に行って安全性の数字を得る・・・などということはありません。もしそうだとすると、そのような試験計画が立てられていることが原因ですので、なぜそのような試験計画になっているのか（必然性があるのか）を調べるべきです。例えば、IEC 62279（ソフトウェア安全）に準拠するため、や、安全関連機能に分類した部品の安全性は、すべて試験で確認する計画になっている、等、何かしら必然性があると考えられます。

そのような意味では、日本流でもRAMS流でも製品の設計・試験等は、必要な業務が必要なだけ行われる点では変わりはありません。


ここまでRAMSライフサイクルの段階を追ってきました。この後のページからは、鉄道技術者として見聞きしたことから、かなり細かい話を書かせて頂きます（興味がある方向けの特殊な内容です）ので、メインストーリーは、9まで飛びます。

→次ページ　6-実績による評価(CoP: Code of Practice)