欧州の鉄道技術・日本の鉄道技術
【RAMS】17-V&V

次に進む

１つ戻る

V&V

RAMSの考え方

日本のメーカー

日本メーカーが苦労する点について、補足します。

（すみません・・・・このページは工事中です。）

仕様書の要求事項の確認

このページ(RAMS−その5) で、トレーサビリティが取れていることを分かりやすく立証する方法ついてご説明しました。
最終的には、V＆Vを行う上で非常に膨大な書類づくりを行うことになります。

再掲【図1】トレーサビリティが取れていることの実証(RAMS−その5より）

V&Vとは、このページで紹介した下の図2の中の、各段階において確認を行うVerification（←日本語訳は未定ですので仮に「確認」）や、節目で行うValidation（これも日本語訳は未定ですが仮に「検証」）を指す略称です。適切な能力を持った方が、計画通りに実行できたかどうかを確認する、機能安全の考え方においてきわめて重要な作業です。

再掲【図2】RAMSライフサイクル（EN50126-1)12段階（RAMS−その1より

ValidatorやVerifierの職能

Verification（確認）とValidation(検証)の違いは、簡単に言うと以下の通りです。

  • Verification（確認）：「正しく行われたかどうか」を判定すること。
  • Validation（検証）：「行われたことが正しいかどうか」を判定すること。

    • いずれも、確認対象の文書がどれで、合否判定時のチェック項目が何であり、誰が、いつ、合否を判断したかがトレース（※後から辿っていける）可能な記録があることが必要。

上記の覚え方だとしっかり身に付きますし、メーカーさんであれば各社さんの社内決裁手続きのどれかに近いと感じていただけるのではないかと思います。

正確には、機能安全（IEC 61508系の規格）の各規格で、それぞれ多少の差異がありますが、以下のようになります。

  • Validation
    • EN 50128:2011の定義：process of analysis followed by a judgment based on evidence to determine whether an item (e.g. process,documentation, software or application) fits the user needs, in particular with respect to safety and quality and with emphasis on the suitability of its operation in accordance to its purpose in its intended environment
    • EN 50129:2018の定義：confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled
  • Verification
    • EN 50128:2011の定義：process of examination followed by a judgment based on evidence that output items (process, documentation, software or application) of a specific development phase fulfils the requirements of that phase with respect to completeness, correctness and consistency
    • EN 50129:2018の定義：confirmation, through the provision of objective evidence, that specified requirements have been fulfilled

RAMS系規格の規格本文にはいつ、何をするかや、その計画をすることが規定されているのですが、大まかには下表のようにまとめられます。

必要な能力については、どう定めて、どう実証するかが迷うと思います。

例えば、〇〇部長だからValidatorだ、と役職で自動的に決まる組織なら、〇〇部長になるのに必要な能力なんて定められない、と感じてしまうのですが、そうではなくて、Validatorは、要求事項に整合していなければ、プロジェクトをストップする責務があるのですから、その責務を理解していること（例えば、「RAMSの研修を受けていること」）や、要求事項に整合している/していないを見極められる者であることを定めればよいのではないでしょうか。

つまり、「なぜ〇〇部長に任命されているか」を悩むのではなくて、「Validator、Verifierの職務を遂行できるかどうか」という観点で考えれば能力要件は定められると思います。

　

くどいですが、「〇〇部長であること」という説明では不十分です。なぜならRAMSは能力があり、中立な者が評価することで安全性（特にシステムマティック故障）を保つという考え方があるので、能力があることを言うできだからです。

【表】V＆V等

　 責任者 　目的 必要な能力
（常識的に必要と考えられるもの）		 成果物
Validation
妥当性確認		 Validator
プロジェクトから独立した有識者		 証拠に基づき、製品が、顧客の要求やニーズに合致することを保証すること ・プロジェクト毎にRAMSマネジメントプランに規定する能力を持つ者。一般的には・・・
・十分な経験（職務経験、又は役職など）
・その能力が実証できること。
・RAMS系の関係規格の理解
・特にRAMS系規格から求められる役割の認識		 Validationレポート等の承認を示す文書
Verification
検証		 Verifier
（プロジェクト参加者も含めて）確認が行える者		 　証拠に基づき、その段階で得られた成果（アウトプット）が、その段階に要求されている要求事項（インプット）に合致していることを確認・検証すること テストレポート、
Verification レポート等の確認したことを示す情報
Design review
デザイン
レビュー		 独立した会議体
（設計委員会）
 得られた結果が、次の段階に進められるものかどうかを評価すること 同上 次の段階に進めることの承認又は取るべき対策（必要なら）

VerificationもValidationも、どちらも節目で、高い能力のある方が行いますのでV＆Vと通称されますが、Validation（検証）はVerification（確認）より高い観点から行います。そのため、Verification report(※確認記録）をチェックし、もし確認者（Verifier）が木で鼻を括るようなチェックをしているならば、それを見破って「大切な点が抜けている・・」と指摘するのが検証者（Validator）の役割です。

なお、デザインレビューはRAMS系規格ではV＆Vとは別に規定されています。さらにEN50126-3では、デザインレビューを行うべきタイミングも書かれています。デザインレビューは、Verification・Varidationと目的が違います。V＆Vについては前述のような実施結果の達成度をみて、レポートを作成することがアウトプットですが、デザインレビューは、さまざまな関係者（大概は委員会形式）から節目の段階で指摘をもらい、次に進むことの是非を判断しています。ISO 9001でもdesign reviwsとV＆Vは別に書かれていますので、区別して行う必要があります。

  • Design review：ISO 9001　8.3.2 b) the required process stages, including applicable design and development reviews

    • EN50126（RAMS)ではB.5及びEN50126-3に、EN50129では表E.8に、EN50128では表D.56等に、安全性を高めるための手法としてdesign reviewが規定されています。

要求事項は複雑

RAMSの第9段階では、第4段階で特定した要求事項について、validationを行うことが規定されています。

しかし第4段階の要求事項は、実際のプロジェクトにおいては仕様書に書かれているわけですが、車両電機や電力分野についてはかなり多岐にわたる書類に分散していると思います。

なぜなら欧州系プロジェクトにおける発注仕様書では、多数の欧州規格は引用してはいる半面、日本のように具体的な製品指定又は定格の指定せず、大体の性能を示すことにとどめていることや、KPI（Key Performance Indicator)による数値目標の達成を要求されているためです。

例えばパンタグラフについてはこのページ(日欧の比較その20）"で紹介しているように、欧州規格で定める条件下でシミュレーションを実施して、架線の張力やパンタグラフの押上力の数値が、要求されている集電性能を満たすかどうかを立証する必要があります。けん引装置のような車両の運動性能やEMCに関しては、シミュレーションに加えて、実際の路線上での走行試験で立証することになります。発注仕様書では数行かかれているだけの、例えば「離線回数」に対する要求事項に対して、詳細設計において細分化した要求事項に対して、その立証のためにシミュレーションの結果、走行試験の結果等、場合によって数百以上の多数の試験結果を添付する必要が生じます。

これを図にしたものが図3です。要求仕様に関する資料（左側）も、要求仕様を証明する資料（右側）も、もれなく添付することになるため双方膨大な書類になるはずです。

Requirement Management(仕様要求管理)とValidation ＆ verification （検証、妥当性確認)

発注仕様書との対応性

発注仕様書上では、要求事項が法令に基づく義務事項か、法令は特にないけれども鉄道事業者の必須要求事項なのか、等、要求事項の元についてはそもそも明確になっておらず、渾然としていると思います。

日本の鉄道事業者さんの調達する製品（特に車両）では、政府調達の対象の公的な鉄道事業者さん以外の場合には、往々にして使用するサブシステムの製品型番まで指定する場合が見られますが、欧州の鉄道事業者さんの場合には、このような値で、という要求したい性能の目安だけを示し、受託者では、その製品の試験結果によって、仕様書の要求を満たしていること説明する・・・ということが行われています。すなわち、立証する活動はメーカーさん側に任されています。

したがって、モノづくりはしたけれども性能不足で鉄道事業者さんが受け取ってくれない→納期が遅れる→違約金が発生する・・・ということが起こりやすくなります。欧州のメーカーでも鉄道事業者さんの定める所定の性能が満たせず、製品の引き渡しができないということも生じています。

System Performance and Failure Management Analysis(SPFMA)

システム性能分析

  • 〇仕様決定側
    • Outline Design 概略設計
    • Definitive Design 仕様決定
    • DD Detailed Design　詳細設計
    • シミュレーションを行い仕様を決定する。
    • Definitive Design　仕様決定
  • 〇立証側
    • FAT Factory Acceptance Test 工場立ち会い試験
    • SIT System Integration Test　現地組み合わせ試験
    • Test Trial Running 現地走行試験
→次ページ　　18-ISA