次に進む
1つ戻る
- 0.はじめに、RAMS認証書をすぐ出して
- 1.機能安全とRAMS、SIL認証
- 2.マネジメントメカニズムの活用
- 3.日本流とRAMS流の比較【初期段階】 MS構築
- 4.日本流とRAMS流の比較【第3段階・第4段階】PRA,SRA,セーフティケース
- 5.日本流とRAMS流の比較【第5段階〜第7段階】
- 6.Codes of Practice(実績に基づく評価)
- 7.テンプレートによる対応
- 8.HAZOP・FMEAについて
- 9.認証コストを抑える工夫・プロジェクト体制別認証対応
- 10.安全関連・非安全関連機能の分別、国際標準化活動
- 11.セーフティケースの概要(EN 50129)
- 12.日本流とRAMS流の比較【第8段階以降】
- 13.EN 50128(IEC 62279)の構造について
- 14.信頼度と安全性について
- 15.RAMSクイズ
- 16.認証書とセーフティケースはセット、参考文献
- 17.V&V
- 18.RAMSに基づくISA
- 19.RAMS認証についての誤解
- 20.RAMSの安全性立証戦略
目次
RAMS認証についての誤解
RAMSはプロセス重視で安全を実現

誤解されています
「製品評価」とは違います
RAMS認証について一般製品の制度と同じように誤解されている方が多いため、ここで改めて図解します。
図1は一般消費者の手に渡る製品にみられる〇〇マーク(例えばSGマーク) の製品を評価する制度の模式図です。
全部が全部ということではありませんが、一般的には製品を作った上で、その製品や製品の試験データを示すことで「〇〇マーク認証」等を取得していますので、製品の設計段階のような上流についての審査を行っていません。
ただ、SGマークでも大量生産品に対する「型式認証」を行うタイプの場合にはもう少し上流にあたる製造段階も審査を受ける必要があるのですが、いずれにしましても製造段階以降を主に審査しています。
RAMSについても、このような審査をするように考えられている方が非常に多いのですが、これは誤解です。

RAMSのような機能安全規格に基づく仕組みでは、より見る範囲が広くなっています。考えられるリスク(受容できない危害が起こるリスク)が生じない状態、すなわち安全な状態になるように製品開発に当たったか、という観点から確認をします。
図1の一般製品よりずっと上流段階において、どのような手順でどうリスクを潰していったか(図3参照)というプロセスを確認します。この段階ではこの手順、という必要な手順はEN50126-1(RAMS)等の規格に書かれていますので、そのとおりに行っているかどうかを見る訳です。
もし途中で何か手順が抜けていた場合には、基本的にはその段階まで戻って正しい手順を行い、再度やり直していくことになります。プロセス重視なため、「途中の手順は違うけれど結果は同じだ」、とか、「製品は立派にできている」というようなこことはRAMSの考え方と整合しないわけです。
リスクが潰されていない製品は、使っているうちに潜んでいた思わぬリスクが出てくる可能性がある、と思いませんでしょうか。例え日本で50年使っていても、その製品と違うソフトウェアが組み込まれた製品は、ある時、違う挙動をする製品かもしれないです。むしろ機能安全を意識していない製品の方が怖く感じる感覚さえ、あるのです。

ここまでのRAMSの紹介で触れてきたとおり、機能安全規格のキモは、図2または図3のような安全対策を製品開発時に検討し、施してきたかどうか、です。
この際に想定すべきリスクは、確率的に生じる「ランダムハードウェア故障」と、原因を取り除かない限りいつかは必ず生じる「決定論的原因故障」・・などという予見可能性が異なる2種類があったりするのですが、ともかくもこうした考慮をして設計を進め、その対策をしたことを記録(トレースを取る、といいます)することが、RAMSの最低限の流儀です。
繰り返しますが、RAMSは、図1のような製品を見る審査ではなく、図2のような開発手順を行っているかどうかをみるのが流儀だ、ということがポイントです。
メーカーさん以外の方はよく誤解されており、安全な仕様実績がある製品だからといって認証を取れない、という理由を誤解されているようですので次の項でももう少し補足します。

RAMS流
世の中に、製品の安全を保つための方法は無数にあります。
細かく見れば会社の数だけあるかもしれません。さりながら、WTO(世界貿易機関)のTBT協定があるため、外国の公的機関が入札をする案件の入札仕様書では、技術的な理由がない限りは国際規格があるものは国際規格を使用することが義務となっています(拙著(冒頭の国交省のもの)も参照ください)。
そのため、鉄道安全を謳うRAMS(IEC 62278)や、ソフトウェア安全(IEC 62279)、国際規格ではないですが鉄道車上ソフトウェア(EN 50657(※今後EN50716に置き換わる予定))等の規格は、仕様書に挙げられがちです。
その場合、例えば、IEC 62279:2011 or its equivalent(※同等のもの) ・・・というように要求されますので、日本の●●と同等だと主張する方法もあり得ますし、某省ではだいぶ力を入れていますが、技術の問題としてみると、かえって困難な道かと思います。
民間の調達であっても、欧州の技術規格TSIではRAMSが要求されているため、海外の車両メーカーに納入するような案件ではRAMS系の規格が要求されているものと考えます。
RAMS系の規格をフルに適用すると調達コストがかさむため、特に安全性が必要な部品に限定してRAMS系規格であるEN50657やEN50128(IEC 62279)を適用することを求める場合が多い現状ですので、RAMSが要求されたからといってあきらめる必要はありません。発注者の考え方によって適用範囲は相当狭い可能性もありますし、実績がある製品との差分だけでいい場合や、冒頭で申し上げたようにセーフティーケースの提出だけで済む場合もあります。また、2回目からは客先も厳しい要求をしないケースもあるため、現在の開発手法に限界を感じた場合には、RAMS流の方法にトライするのはいかがでしょうか。
※これを書いている私は、ある日本の会社の若手職員の技術的に未熟な方法に起因する品質不良に対応中です。RAMSだからといって、あるいは日本の優秀な技術者を前提とする方式だからといって、不祥事が起きないとは思っていません。
ここまで述べてきたことの繰り返しになりますが、まず製品のもつ機能をブレークダウンしてみて、その機能に必要な安全性とリスクを挙げてみます。そして安全性が必要なものとそうではないものに分別します。また、安全性が必要なものには対策を行う(行われているか)を考えることと、Validationのようなそして気な役割を検討すること、といったところです。安全性については次のページに補足情報を書いてみます。

・・と、上の図のように安全に関する手法は多数ありますが、国際規格であるRAMS又はIEC 61508(機能安全規格)は要求されやすいことから、これらの規格に基づいて製品開発を行えるものは行うべきではないでしょうか。
一部繰り返しになりますが、もし既製品であるならば、例えば相手国向けにアレンジする部分だけや、安全に関する機能だけでもRAMSによる手法で開発をやり直すことで、何とかして相手国の理解を得るような説得が必要ではないかと思います。
適合性認証以外のRAMS適合性の立証
EN50126-1、EN50128等のRAMS系規格に適合した製品開発を行うとするとき、製品が大規模になるほど、RAMSが要求する作業は指数関数的に増大します。
これでは、時間・コストはいくらあっても足りませんから、製品のうちでも大切な機能の開発・製造だけRAMSに適合した方式で進め、また適合性認証まで至らない方法で立証されることも多いのですが、あまり知られていません。この、認証以前、又は一部だけ適合性認証する、ということについて必要なことを述べたいのですが、RAMSコンサルタントの方が最も得意とする分野ですので、「さわり」だけ述べます。
実績ある日本の鉄道製品を海外に販売すべく、製品の認証を取る方法を調べ、次に既に開発済みの製品を何とかしてRAMS認証を得る方法を調べる方が多いようです。
製品の一部だけ適合(適合性認証)が必要だというのは、裏を返すとプロジェクトによってその必要範囲が変わるということでもあり、相手先との交渉次第です。しかし、製品のパンフレットはまだいいとして、日本の新幹線が優れている、という使い方の話をするのはちょっとあれです。
私の提案としては、製品の素性を機能ベースで説明できるように機能ブレークダウンした上で、相手先の必要最小限な安全性評価方法が何かを交渉する方式です。
客先としても必要以上にコストはかけたくないので必要最小限を決めることは双方のためになるのですが、政府系の海外プロジェクト案件ではこうした地道なことには目が向いておらず、製品に認証を付与することだけを見ているようですのでご提案したいです。
- セーフティーケース(リスク分析表)の提出のみ
- セーフティケースの提出
- セーフティケース(リスク分析表の第三者技術評価)
- 製品の一部に限った第三者アセスメントレポートの提出
- 製品の一部に限ったRAMS系規格との第三者適合性評価レポートの提出
- GP部分のISAレポートの提出
以下略します。
「適合性認証」より負荷の軽い安全性立証方法はいろいろ考えられるということだけご理解下さい。
表1にある製品の一部、というのは安全上の重要機能です。その「製品」を頭の中で分解してください。
どのような機能があるかざっくり大分類した上で、詳細機能を書き出します。この際、機械的な構造やソフトウェアの働きは気にせずに、〇〇を〇〇する機能、というリストを書きだします(後からでも加除訂正できます)。鉄道車両のようなシステム化されたものは、サブシステム(ブレーキ装置等)別に大分類した上で、詳細機能を考える感じです。
その機能の直接の入力元、出力先の機能を特定し、その機能が誤作動した場合の安全性評価をおこないます。この分析結果から、本当に必要な「安全」を維持するために安全上必要な部品(正確には「機能」)が、システムの中のどれなのかを特定することが製造側・使用者側の双方にとって重要です。
安全に100%関わらない部品は無いのですが、ハザード時の被害の深刻度(Severity)、発生頻度(Frequency)(場合によっては検出可能性(Detection))による優先順位と、製造物責任法及び社会常識を照らし合わせると、起きたら本当に困るけれど安全は保てるのか、安全が保てないのか判断できます。
この判断はかなりの責任を伴います。技術者一人の責任に押し付けずに、この判断の手順を明文にしたのがRAMS系の規格とも言えます。
機能の洗い出しについては次のページに続きます。