次に進む
１つ戻る
- 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認証が使われるとき
タイミングは3回
－－－－－アドバイスを頂きましたので、認証が必要になるタイミングについて補足します－－－－－－
RAMSに関する認証書が必要となるタイミングは、製品を納入する際だというイメージがあると思います。しかし、実際には案件によってマチマチですし、製品の納入時以外にも、下図に示すように①～③の機会があり（案件によって0回の場合もあります）、また契約上のメーカーの立ち位置によって必要な回数や、RAMS関係書類の中でも重点化すべきポイントも異なります。
①入札の際（入札から数か月以内を指定される場合も）、
②納入時
③適合性評価機関の評価を受ける際
もし、納入時に提出が必要だとしても入札の要件書をよく読むと、「○○（部品名）については、IEC○○規格又はこれと同等の最新版への適合性を示すこと」などとあるような案件では、その適合性を示す方法について「第三者による適合性認証」のように明示的に指定されていないため、自己認証（適合宣言書）で足りる可能性もあり、それならば認証書までは必要がない（※スケジュール的には相当助かる）わけです。
また、もし認証が必要だとしてもそのメーカーのサプライチェーン上の立ち位置によっても、認証が求められる内容やタイミングも異なります。
- 部品メーカーの立場の場合
- 元請メーカーの立場の場合
もし下図の「部品メーカー」に相当する部品を納入する立場でおられるなら、いかにさまざまな路線で適用できるGP（Generic Product）を切り出して、事前に認証書を提出できるかが、多くの客先確保のための鍵になります。逆に、GPに対する認証書がなく、プロジェクトが具体化してからその案件向けの製品仕様（Specific）のものに対して認証を得ようとしようとすると、時間的に厳しくなり、手間どっているうちに同業他社に案件を取られてしまう可能性すらあるでしょう。そうならないためには、汎用的な製品を構築し、その認証を得ておくことが幅広い納入先確保策となるため、高い技術を持つ日本のメーカーの場合、重要な戦略ではないかと考えます。
もし、下図の中で「元請け」にあたる、「車両メーカー」やシステムインテグレーターのような、多数のメーカーを束ねるお立場ならば、要求される認証書の種類は多くなるため、その内容の一貫性がより重要となります。後で紹介するように、「客先の要求事項」からのトレーサビリティを説明できることがより重要となります。
提出機会2回目又は3回目の場合、認証書ではなく、EN50128（セーフティケース）のPart5 「related safety case」として納入する部品に関するセーフティケースの提出を求める場合があります。逆にいえばセーフティケースだけあれば良いので、ハザードとその対策が出来ていればいいことになりますが、親システムのハザードとの内容の一貫性は求められます。
このホームページの話は、元請に当たる車両メーカーの立場から展開しております。車両メーカーの場合、客先の鉄道運行事業者の要求事項がよく見える立場ですから、その要求事項を各部品の性能に反映していることを示す、トレーサビリティについて特に述べています。
一方、部品メーカーの場合には、トレーサビリティよりも、ここで後述するような、部品のSIL（安全インテグリティレベル）の達成に手を尽くすことがより重要になるでしょう。 与えられた環境（それを与えるのは元請メーカーや鉄道運行事業者）に対して、標準品（GP)が、万全なセーフティケースを示して手落ちがないことを示すことが求められます。
－－－－－－－－－－－－－－－追記は以上です－－－－－－－－－－－－－－－－－－－－
日本流（暗黙知ベースの流儀）とRAMS手順との比較
初期段階
RAMSライフサイクルの１２段階のうち、第１段階（コンセプト）の主な相違点について説明します。
前にも述べましたが、RAMSはマネジメントの力で業務を確実に動かしていく構造ですから、ライフサイクルの最初の方の段階に書かれていることは基本原理や、基本的なリスクの洗い出しなど、おろそかにすると後で痛い目に遭うものが多いため、注意が必要です。
他方、設計や製造・試験等の後の方の段階になるほど、日本流とRAMS流では同じようなことをしており、差がなくなっていきます。
下の図は、製品開発プロセス（※RAMSライフサイクルに書かれた12段階（旧版では 14段階）のプロセスより、具体的に記載しています）と、RAMS流、日本流の手順の比較をしたものです。RAMSライフサイクルでいうと、第1段階の開始より前の段階から第4段階にあたる業務までを図にしています。
最初の方ほど、日本流とRAMS流との手順の差が大きいです。
ここで紹介したい相違点は、上図の中で朱書きしている1．と2．の2点です。
- 1．概要検討（製品のコンセプト）
- RAMS流ではリスクの検討やシステム設計に活用するために作成されます。
- 日本流では、製品を簡潔に紹介する目的で作成されます。後段の作業とのつながりは意識されません。
- 2．マネジメントシステムの構築
- RAMS流では、これから行われる活動について、誰が、いつ、何をするか、方法や、その結果の確認を行う役割や権限を規定します。
こうして、マネジメントの力で製品の安全を確保していけるように仕組みを決めていきます。 - 日本では、社内も客先（鉄道事業者さん）も、ツーといえばカーで相手のマネジメント方法等は分かりきっているため、わざわざまとめたりしません。
製品コンセプトは日本流でも作成しますが、作成目的が異なります。
製品概要（コンセプト）とは、これから開発、製造する製品がどういうものかを明確にする作業です。
これから製品を作ろうとする場合、プロジェクト関係者共通のイメージのようなものは必ずあるはずですが、日本流では、〇〇秒ヘッドを実現する〇〇システム、というような製品紹介の見出しの内容にとどまっており、RAMSで求められている内容のコンセプトが作りにくそうに見受けられます。もちろん欧州でも、このようなことがかかれますが、それだけではないです。
日本流での概要（コンセプト）が、ちょっと違う理由
- 鉄道事業者が決めた仕様に沿って製品を製造するため、自社では特別なことを考えていない気がするため。
- コンセプト＝製品概要 と考えて作成しているため。
- コンセプトは超上流にあたり、技術との関係が遠いためにおろそかにされるため。
－－－【この部分追記】－－－－－
RAMS流というより欧州メーカーの一例です。仕様書上の「Request」に対応する事項に関することを紹介し、コンセプト→システム要求事項→リスク分析→・・・とつながる工夫がされているようですので紹介します。
・・・と、製品概要を紹介し、
など、装置の役割を示す記述をしています。
では、日本流では製品概要（コンセプト）は重視しなくていいのに、RAMS流では製品コンセプトを作成する理由は何でしょうか？
その前にちょっと余談ですが、上の箇条書きの中の3.の「超上流」の部分については、JIS X0160:2012（ソフトウェアライフサイクルプロセス）をベースに作られた「共通フレーム2013」において、超上流部分をおろそかにするので「使えないシステム」が作られてしまうことが指摘されているのです。これをみて、こういう問題は分野を問わずあることが分かり、個人的にとても納得しています。
まあ、このほかにも理由は様々だと思いますが、RAMS流においては何のためにコンセプトをまとめるか、使途の例をいくつか紹介します。紹介しますけれど、日本流でも内容に問題があるというわけではなく、認証において大きな影響がある訳でもないので、今後の何かの機会における参考情報としてご覧いただく程度で十分と思います。
ａ．リスク分析（※次ページ参照）の検討材料
この段階の次の段階では、「初期リスク分析（PHA)」を行います（←リスク分析（PRA)と、その影響を解析するハザード解析（PHA)の両者をまとめて記述します）。PHAは、製品にハザードを招きそうなリスクのうち、割合大きなレベルのリスクを、できるだけ広く、網羅的に挙げることを目的として行うものです。日本では、以下の事情で普通行うことはありません。
PRA・PHAの要点は、自社では発生をコントロールできないような（考えたくないような）リスクを抽出することと、網羅的にリスクを抽出することです（欧州のメーカーでは、さまざまな列車の状況下でのリスクを挙げていく様式が使われています。）。
大きなレベルのリスクを把握するためには、社会的なリスク（政治やコストなど）や、車両、運転、電力、信号など、一見関係なさそうなさまざまな技術分野側からの知見を集めることが有効です。その検討のインプット（入力）情報となるのが、コンセプトです。
例えばこれまでの製品とどこがどう違うのか、や、個別路線用なのか、汎用の製品なのか、等が書かれているならば、それを読みながら、リスクが生じそうな箇所を挙げていく有用な情報となるでしょう。
なお、このあとに述べますが、こうして挙げられたリスクは網羅的すぎるため、技術者なら「そんなリスクは現実的ではない」と瞬時に分かる変なものも多数出てきます。
日本流では、技術者の頭の中で「問題ない」と秒殺できてしまうため、一瞬思っただけで、形には残りません。
一方RAMS流では、「こんなリスクが挙がった」→「検討し、「影響無い」と結論を出した」と記録します。
秒殺する日本流は、PHAのような活動は行われていません。そのため、①『そんなリスクは問題にならない』と考えたのか、②『見逃した』のか、どちらなのかがわからなくなってしまいます。①と②は過失の有無の差があり、いざというときには雲泥の差となってしまいます。
一方製品の性能に関わるようなリスク源についての対策の検討についても、製品の詳細な構成が決まっていくことに歩調を合わせ、どの部品に何を割り付けるのかなど、だんだんと詳細化していくことになりますが、これは、この後の段階での話ですので後述します。
ｂ．部品のリスク把握
製品には、多数のパーツ（部品）が使用されます。それらの部品の製造メーカーでは、部品が最終的にどこでどう使われるかすべてを正確に把握することは困難で、下図のように、部品のすぐ近くの状況しか見えないでしょう。まして、製品として組み立てられ、鉄道運行事業者の環境で、どのように使われるかまで把握することはさらに困難で、期待できないと考えられます。
一方、ハザードは、これまでの経験上、システムとシステムの境界部のような、ハザマで起こりやすいことがわかっています。
上の図でいうと部品Aは、部品Aとしては万全にリスクへの対策が取られていても、部品Bと組み合わされ、さらに製品となった際に起こるさまざまなリスクや事象に耐えられるかまで、部品Aとしては検討されていないことが一般的です（製品としてはこの後様々なテストで安全性が確認されます）。そんな部品Aに対し、コンセプトは部品Aが部品Bに使われることの妥当性の判断材料として利用することができます。
例えば、「実績重視」というコンセプトの製品に使う部品として、新技術が利用された「部品A」が提案されているならば、本当に妥当なのかどうかという判断の材料に活用する、といった使い方です。
ｃ．認証コストの低減
もし、少しだけ仕様が違う製品ごとに、逐一認証を取得しようとすると、いくら時間とお金があっても足りません。
通常は認証コストを抑制するため、既認証済みの機能（部品）と、今回製造する製品との差分についてだけ認証を取得する、というような認証を組み合わせることもよく行われます（参照）。認証を組み合わせることで認証に要する費用と時間を節約するわけです。
例えば、プロトタイプ型（最も一般的と考えられる普通のタイプ）の製品が、量産前の「先行製品」と呼ぶ段階で既に認証済の場合、今回製造する特定路線向けの製品が認証済みプロトタイプ型製品のアレンジ製品だと分かるように、今回製造する製品のコンセプトとして「認証済みのプロトタイプ型を〇〇線向けにアレンジしたもので、基本機能は変更しない」、というような製品の特長（差分）が明確になっていると、RAMS認証対象製品の「システム設計」の前提が分かるようになるため、認証審査範囲をより限定することが出来るようになります。
製品開発時には「試作品」と、お客さんに提供するために大量生産する「製品」では、仕様が多少異なると思います。そのような差異・製品の位置づけの違いをコンセプトで整理し記述しておくと、両者の差分が分かることから、試作品に行ったテスト結果の再利用も可能になるでしょう。
一般的に、製品開発をする時には以下の3タイプを順々に作っていくと思います。
- （１）試作品 ：耐電圧試験など、壊れかねない種々の厳しい試験を行う
- （２）量産前の先行製品 ：認証審査の対象とする
- （３）大量生産品 ：（2）に対する認証書（差分がある場合、必要なら差分への認証書も）とともに、客先に納入
・・・このように製品を順々に開発を進めると思います。もし認証の対象が上記の（２）であるなら、（１）で厳しい試験を行う製品とは仕様が同じではないのですから、（１）の試作品のテスト結果を活用して、（２）先行製品の開発を進め、（２）について得た認証を崩さないように（３）によって大量生産を製造する・・・といったコンセプトが明確ならば、試作品をベースに今回の製品を作る、等、認証対象製品の位置づけや、既存品との差分を明確にすることができるようになります。
既認証製品が土台だと共通認識されつつ開発が進むと、認証済みの製品と同じ部分には過去の成果を最大限に活用することが正当だと誰からも分かるようになり、認証コストも縮減を図れると期待されます。
ちなみに、鉄道製品ではなく一般的な組み込みソフトウェアを用いた製品では、プラットフォームに依存するか、しないかによって分別しつつモデル化する、モデル駆動型アーキテクチャ（MDA(Model Driven Architecture））が開発技法として取り入れられており、GAの考え方は、組み込みソフトウェアでは一般的な手法になっています（後述します）。
上記のａ．～ｃ．には、わざわざ「コンセプト」にまとめなくても常識的に考えれば分かるようなことがいろいろ入っています。
でも、RAMS流では、製品に対する要求事項が正しく製品の仕様に反映され、完成した製品に採り入れられる「トレーサビリティ」を重視しています。
コンセプトに緻密さは不要ですが、コンセプトと仕様がつながっていることが大切なのです。
製品概要（コンセプト） まとめ
鉄道事業者に言われるままに製造するとしても、既存の製品と比較してみて、今回の製品は、特定路線向けの製品（Specific Application）なのか、それともプロトタイプ的製品（Generic Application)なのか、今後の拡張性はあるのか、実績のある既存製品と比較してどんな開発方針か、・・・など、メーカーとして書くことは多数あり、これを元にシステム設計し、リスク分析を行うことに進んでいけます。
もしこのような観点がコンセプトに無いと、次の段階で、システム設計をどうしてこれに決めたのか（妥当性）や、リスク分析が万全なのか、等の判断のよりどころがなくなってしまいます。次の段階の判断の根拠を、言葉で書くイメージで考えると、製品概要(コンセプト）のイメージが分かるのではないか思います。
日本でも、ＩＳＯ9001取得工場は多く、さまざまなプロジェクト進捗管理が行われています。しかし、誰がどんな権限を持つか、や、どんな基準で試験をするか、というような大枠については、メーカー自身も、お客さんも皆が分かっていることですし、各プロジェクトでほとんど変わりませんから、いちいち作成したりはしないと思います。
他方、海外のメーカーでは、「こんなマネジメントをしている」と、お客さんに見せることが意識されており、日本では、マネジメントよりも、その結果である製品の良さを見てもらおうとしている、とも言えると思います。、
このページの冒頭の図中に×印をつけたものを多くあげていますが、その中からいくつか紹介したいと思います。
マネジメントシステムの構築 -実施体制-
わかりきったことを「見せる」ことが大切
製品開発において誰が何をするか、その承認者は誰かは、社内では分かり切っていますね。
もし、この責任分担が明確に規定されていないと、前述のRAMSの3本柱の「ライフサイクルモデルによる品質確保手順の提供」での手順が、誰が、どんな権限で行ったかが外部の者に説明できず特に重要な結果の承認が適切かどうかが説明できなくなってしまいます。
分かりきったことでも、説明のために書類化しないと説明が成り立たなくなりかねないため、比較的とりかかり易い作業でもありますので、文書化し、権能を明確にすることが重要です。
実施体制の正当さ
例えば、製品出荷時に品質保証部が品質検査を行い、品質保証部長が承認印を押しているとします。なぜ、品質保証部が承認を行うのでしょうか。
その答えは各社で異なると思いますが、「製品に共通な品質基準を定めているのが品質保証部で、その適合性を最終確認するためだ」とだけ説明するようでしたら、その説明の仕方はRAMSの考え方とは合いません。
RAMSでは、しかるべき能力を持った者が、独立の立場でチェックすることで安全性等の結果を担保しようとします。また、そのチェックは、安全性が求められる製品ほど、高い独立性を持つ者がチェックすることで担保しようとしています。
その考え方からみると、品質保証部が確認する理由としては、①製品の設計開発部門とは独立した部署であること ②製品出荷を止めてでも製品品質を守る権限を品質保証部は与えられていること ③品質保証部員及び品質保証部長には、資格や能力が担保されていること 等を社内規定や証拠物の裏付けをもちつつ立証できる必要があります。
またこれとは逆に、権限の範囲が明確になっていることも重要です。
特にソフトウェアのような製品は後から内容を確認することは難しいため、ソフトウェアを開発する上での役割分担や、その確認を行う者のようなマネジメントによって品質を確保することが特に重要になります。
もし実施体制を決めずにソフトウェア開発を行ってしまうと、ソフトウェアがいかに正確に出来たとしても、RAMSの考え方からすると作業が正確に行われた保証がなくなってしまいます。先に大枠を作る（体制・役割・権限を決める）ことは大変重要です。一度作ってしまえば、繰り返し適用できるものでもあります。
マネジメントシステムの構築－結果検証－
RAMSでは各段階ごとに、各段階で行うべき業務が確実に行われ、かつ妥当かどうかを、しかるべき者（※これも決める)が検証することがキモです（後述）。
「しかるべき者」については、 余談ですが徒然草第185段にある乗馬の達人である城陸奥守泰盛が、乗る馬を選ぶのに非常に慎重だったという話も、その道の達人がいかにリスク検出に優れているかを表すエピソードとも考えられます。業務を行う者の妥当性の検証は大切です。
日本流では、今やっている作業がRAMSの段階のどこに相当するか・・・なんてことは意識しながら仕事をしませんので、その検証のタイミングや、検証内容が、RAMS規格の要求とは合わないものになりがちです。
検証したが何も問題が無かった場合や、問題が見つかったが修正してＯＫになった場合はよくあると思います。こんな時、問題があったならば記録し対策を打ちますけれど、問題が何も無かった場合には「問題がなかった」という記録はしませんよね。しかし、記録しないと、確認したという重要な事実が消えてしまい、何もしなかったのと同じになってしまいます。
あるいは、確認を中立性の低い者が行ってしまう場合（上記の実施体制と無関係に行われてしまう場合）、意味が無くなってしまいます。プロジェクトの始めに気をつけて文書化すればいいだけなので、取り組みましょう。
結果を検証したことが分かる事実だけでも何かに記録されていればよいのですが、何も記録がないのは、確認をしていないのと同じに見えるため非常にもったいないと思います。
RAMSの第1段階は製品コンセプト作成や、RAMS計画の作成、実施体制を決めることをしたかどうかですから、やったか、やらなかかったかが問われているようなものです。
RAMSを意識せずに日本流で開発した製品では、RAMSの段階を意識していないわけですから、初めからRAMSに不適合となってしまい、後からはどうすることも出来なくなります（はじめからやり直しになります）。
行ったかどうかが重要な第1段階ですので、是非、機会を捉えて少しずつ、大枠作りに取り組んで頂くことと、行った検討は、たとえ「何も問題なし」であっても記録する、という2点を進めて頂きたいと思います。
「日本の企業が、欧州規格で作ってくれたら最強」という話はよく聞きます。関係者が合意しやすい欧州規格ベースで、かつ日本品質だから、との事。
