欧州の鉄道技術・日本の鉄道技術
【RAMS】13-EN50128（ソフトウェア規格）の構造

次に進む

１つ戻る

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

ソフトウェア安全規格

ソフトウェア安全規格の目的

EN50128:2011は、ソフトウェア安全に関する規格です。2011年の改定時に具体的な書類名を記載した要求事項（第６章から附属書Dに至るまで、大量に文書名が書かれている）が大幅に増える一方で、規格の体系が非常に整理されました。この構造を把握していると、内容を大づかみできると思います。

※ここで紹介しているEN 50128:2011は2022年1月発行のprEN 50716により今後置き換わることが予告されています。

※（追記）2023年11月　EN 50716:2023”ソフトウェア開発の要件”が発行されました。EN 50128は今時点では廃止されていませんがいずれは廃止されます（2023年11月20日時点）。

 

まず、規格の序章に、RAMSの関連規格であること、およびSIL 0(いずれはBasic SILとなる）からSIL 4までの 5段階の安全性について、それぞれのSILに合う手法（Technique）と手段（Mesure)を定めていることが書かれています。規格を引用することははばかられるのでイメージで示すと、図１のようなことが規定されており、目標とするインテグリティが高いほど厳格なTechniqueとMesureの適用が要求されています。これがこの規格の中身です。

【図1】EN 50128:2011 (ソフトウェア）のSIL別の要求事項

図1に書き忘れましたが、本当の必須事項（「M」）もあります。例えばプログラムを構造化すること（表A.4）、大域変数の使用の制限（表A.12。SIL3・4の場合）といったことが必須事項ということになります。
一方、この規格には「このソフトウェアはSIL4でなければならない」というような、どのSILにすべきか、という推奨は規定されておりません。そのため、ソフトウェアに必要な具体的なSILの値自体は、この規格の利用者自身が目的に合うように決める必要があります。


もう一つの内容・・といいますかメインの内容になりますが、RAMS規格に定められている製品ライフサイクル段階ごとに、その段階で行うべき業務について規定しています。上述した「適用すべき手法と手段（Techniques and Mesures)」は、この業務の一部分である附属書A、C、Dに該当します。規格の全体の体系を把握しているとEN 50128の理解が容易になりますので、図2を示します。ここに最近まで、旧版のEN 50128:2001の図を掲載しておりましたが、今回時間が出来たためEN 50128:2011に書き換えました。なお、IEC 62279:2015年版も同じです。図2にあるように、第6章に骨格を示し、具体的な手順は7章、8章、さらには附属書に規定して、行ったりきたりしながら読む構成になり、旧版に比べると本文がスッキリしています。

例えば、「開発すべきプログラム言語が決まっている」という話がこの規格に関して言及されることが多いのですが、本文の6.7と7.3に関して附属書AのTable A.15 「Textual Programming Languages」 にプログラミング言語のリストがあり、C言語が「R」（推奨）と、他の言語より低く位置づけられていることについて言われています。

 

【図2】ソフトウェア安全規格の構成

図2において赤で囲んでいる第6章が、ソフトウェアの安全性・信頼性などを保障（assure)するための規定が書かれている、いわば中心的な内容です。

この第6章には確実に実施されるべき項目が書かれており、第7章に補足情報としてGeneric Software（という概念で示される。製品の使用場所のような読み込ませるデータに依存しないソフトウェアの基本機能）の開発手順が書かれています。第8章にはそのデータの開発手順が書かれております。第7章・第8章は、第6章から時々参照される構造である点に注意が必要です。

附属書A、附属書Dには、上述のソフトウェアSIL（SSIL)ごとに適切と考えられている具体的な手法と手段が書かれていますので、それぞれ記載箇所ごと対応する項目を参照しながら進める必要があります。


この規格をめぐっては、先ほども少し触れましたが一般的なプログラミング手法である変数のポインター渡しや、関数の再帰的呼び出しを制限することが推奨されていたり 、COTS(市販ソフト）のSILはどうするかが曖昧な点、などがよく指摘されています。こうした議論は、附属書Aや附属書Dに具体的なTecuniques and Mesures（手法と手段）に書かれている内容の適切さについての議論といえますが、ソフトウェアの技術進歩は早く、また、一概には決められないことを附属書ではＮＲ，Ｒ，ＨＲ，Ｍと割り切っているゆえに現実と合わない点が生じているための議論といえます。

もしこの規格と現実が合わないのであれば、その合理的な理由を示すことで正当化していけばよく、理由を考えずに規格にさえあっていればよい、というものではないと考えています。

第5章と附属書Bには、ソフトウェアSILごとに決めるべき、ソフトウェア開発者の役割が規定されています。大変細かく書かれているため、このまま社内規定にできるのでは・・・というほど詳細な内容ですから、本規格はソフトウェアを対象にしていますが、RAMS（EN 50126,IEC 62278)についての書類作成の上でも、役立つ情報ではないかと思います。

ソフトウェア安全規格の個別書類

EN50128:2011では、5.3の図3や、附属署A.1において具体的な書類名が多数上がっております。文書は多数上がっていますが、作成するフェーズや、作成・照査すべき者が示されている点、および「Planning」「Software requirement」・・など主なジャンル分けが示されていましたので、ジャンル分けを参考にしながら作成していく必要があります。もちろん実際の製品とは合わない（不要な文書がある）場合には、その合理性を示すことが必要となります。

多数の文書が必要ではありますが、ソフトウェアはどうしても頻繁に更新が必要になる性質がありますので、更新された際には、更新されて差分を生じた部分(Δ）だけを認証する、delta cetificationが頻繁に行われます。EN50128の認証で多数書類が必要ですが、その多くは最初の認証時にあればよく、他のプロジェクトに共通して使うことが可能です。

この部分を追記します

EN 50128（IEC 62279)に無い手法の利用

EN50128では、特定のテクニック＆手法の利用に踏み込んでいるため、ここに書かれていない手法を利用するのは絶対だめなのか？　という疑問が生じます。

この点、欧州の認定機関にヒアリング調査をしたことがあります。コンプライアンス上の問題があるので詳しく書けませんが、何が何でも規格に合わせればいいものではない、というのはコンセンサスです。同じ趣旨の話はISO 9001の多くの解説本にも書かれています。

ただし、安全に関わる話ですから、その判断を誤ったり、「前の同様製品でもそうだったから」という程度の判断根拠ではないのかどうか、本当に安全上の問題について疑念を招かないのかは立ち止まってお考え下さい。

お勧めしたいのが、以下のような報道をされた場合に「それは違う」と申し開きが出来るかどうかを考えることです。

品質の不祥事を起こしたメーカーさんのお話を伺う機会が多かったのですが、騙そうという悪意は極めて乏しく、みなさん「過去の製品と同じことを踏襲しただけです」・・とおっしゃっています。客観的に指摘されて段々と問題点に気づくそうですので、以下のケースの場合に、不正ではない、と言えるだけの合理性が説明できるかどうかを考えてみて頂けるとよいと思います。

【ケース１　製品品質不正】

「A社は、鉄道安全に関する製品について、国際規格で義務づけられた試験や手順と異なる手法を行っているにもかかわらず、長年出荷していたことを明らかにしました」


【ケース２　責任問題】

「先週B国で起きた大規模な列車運行トラブルについて、B国の運輸省は、列車に使われている製品の一部に仕様と異なる試験や手順が行われていたと発表しました。」

参考文献の紹介にてご紹介している、「Mise en œuvre des normes CENELEC 50128 et IEC 62279」（Author: Jean-Luoise Boulangerさん)において，この論点が紹介されています。

IEC62279では箇条4.9にもし手法が無い場合という項があります。それに関係する解説のうちプログラミング言語に関する部分の概略です。詳しくは上記の本を参照下さい。

    規格の表A.15にない言語を選択することは可能。しかし、規格の要件を満たしていること、実行するアプリケーションに適していること、そのプログラミング言語で実行しなければならないことを実証する必要がある。

    またその言語に分析ツールを適用し、注意が必要な特別な構造を特定することも必要。

    プログラム言語の選択は、PAQL(※英語でいうSQAP（ソフトウェア品質保証計画））で正当化される必要がある。

    また、コーディングルールとそのプログラミング言語の構造が、実装上関連付いている必要がある。

・・と述べた上で、「8.3.2.6.4　プログラミング規則」の表8.8に、例示をしています｡この表には「Bombardier」というメーカー名が残っています．

太字にしているところは、実際やってみると大変だと思います｡


→次ページ 　14-信頼性と安全性について