RAMS[18] 実際はどうしたらいいか

RAMSは階層化を想定しているので、1からの開発を考えたときの規格になっています。なので、途中段階から実行しようとするとそもそも無理があります。現実には最終システムを想定して開発をゼロからやるケースはまれで、特に日本の企業にとっては既に何十年も鉄道製品を売っているのですから、資産も沢山あります。大きなシステムになればなるほど階層化が必要で、ユニットのような共通LRUを使用しながら装置を作っていき、最終的には現場向けに設計した設置するという流れが普通です。日本のメーカーにとって、RAMSが必要になる時は、海外に製品を納める時です。単品機器であれば階層化もそれほどないでしょうから、ゼロからの開発をするとしてもそれほど大きな後戻りにはならないかもしれませんが、信号システムを一括して受ける場合は、サブシステムだけでも相当数ありますし、そのサブシステムが使用しているユニットや基本ソフトも多数あるので、総数は数えるのも嫌になるくらいあるでしょう。RAMSを適正に対応させるためには、階層化の根っこの部分もRAMS規格に準拠して作らないと、その上の装置を如何にRAMS規格対応で作っても、出来上がった製品は完ぺきではありません。そもそも、そのような開発を想定しいない規格なのです。正論を言えば、途中からやるのはあきらめて、ゼロから開発しなさいと言いたいです。まあ、現実にはそれは許されないでしょうから、どうするかというと、既に開発が終わったものに対して、もう一度RAMSプロセスを行うということになります。それでも、システムとなれば上記のようにVモデルは相当数あるので、これをやるだけでも大変ですし、認証機関費用も莫大になります。それに加えて、アーキテクチャーに問題(規格上の)問題が発見さればそこは作り直しということになります。

まず、時間がかかるということを理解することが重要です。そして、それに気が付いたなら、認証が必要な製品だけではなく、これから新たに開発される新規製品、モジュールにもRAMSの仕組みを行う事です。せっかく、サブシステムやシステムがRAMSプロセスを行っているのに、新たに出てくる基本モジュールがRAMSに基づいていないと、いつまでも同じことの繰り返しです。もし、同時に改革ができれば、10年以内にちゃんとしたRAMSに準拠したシステム製品を世の中に出すことができるでしょう。しかし、バケツの底に穴をあけたまま水を入れても、いつまでも水はいっぱいになりません。まずは、バケツの底穴をふさぎませんか。

日本の鉄道は安全で信頼できるものです。だからと言ってそれで海外の事業者は買ってくれません。最低限のやるべきことをやっていないのだから、その時点で負けです。日本のメーカが今までやってきたことと、RAMSが行っていることは大きく変わりません。拒む理由はないと思っています。RAMSをやるとドキュメントが膨大でコスト的に合わないという人がいます。でも、それでは売れないのです。あきらめて、国内市場だけ、もしくはRAMSを要求しない顧客だけに販売するならよいでしょうが。

私はRAMS規格そのものにも問題があると思っています。RAMS規格はIEC 61508をベースに作られています。IEC 61508は全ての電子安全機器に対する要求規格で、原子炉、宇宙、航空、防衛などすべてのもとになっています。IEC61508からその業界の安全規格ができる仕組みは良いと思いますが、規格作成者がその規格の許容リスク分析を担うべきと思っています。なぜなら、その業界によって社会が受け入れるリスクは異なり、その違いは規格の中で明確にするべきだと考えるからです。簡単にいうと、かけられるコストが異なるということは、当然できる対策にも違いが出るということです。今は、規格作成のメンバーはこのような課題に目を向けずに、自分の考えで規格を作成していると思っています。規格はできればそれがスタンダードとなり、独り歩きします。その時には、規格を作ったメンバーはなんらの責任も持たない。それほど、国際規格を作るということは責任が重いとも思います。ただ単に、安全であればいい信頼性が上がればいいというものではないと思います。

さて、変な方向に話が行ったので話を元に戻します。

既に開発が終わっている製品はどこまでか、これから行うRAMSプロセスは何処かを明確にする必要があります。大体の場合はGAあたりから弄ろうとするのではないかと思います。当然、GAと言っても機能修正は入るでしょうから、少なくともターゲットをGAからSAにしてRAMSプロセスを実行することです。まじめにやればそこそこのプロセスを行う事が出来ます。しかし、最後まで残るのはそのGAを構成しているGPです。ここまで手を入れたら素晴らしいですが、そこまでやりますか??

もし、そこまでできないというなら、認証を依頼するISAに相談してください。それぞれのISAの方針があるのですが、ある程度は譲歩してくれるかもしれません。所詮は彼らも商売です。くれぐれも、あとで何とかなると思って進めないでください。最後で駄目とわかったらもう何もできません。GAのアプリケーションの変更や、追加機能、人間系のプロセス追加などでできる場合もあります。最終判断はISAになります。ちなみに、大手ISAはとても大きいし、asessor も沢山います。この判断はasessorが変わると変わります。最初に訊いた営業、もしくはAsessorが良いと言っても実際に担当したasessorは認めないということもあります。ISAは必ず、本契約の前に事前の打ち合わせを実施します。彼らは彼らで本当にこの製品が認証取得できる可能があるのかを知りたいのです。彼らにとっても、認証を取得できないものを受けることは避けたいものです。なので、依頼するほうも隠すことなく、懸念事項は正直に話してください。これが重要です。

ISAについてはまだ別途ブログを書きます。