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

次に進む

１つ戻る

V&V

RAMSの考え方

日本のメーカー

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

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

仕様書の要求事項の確認

このページ(RAMS−その5) で、トレーサビリティが取れていることを分かりやすく立証する方法ついてご説明しました。
立証するための書類は、最終的には高い力量のある方の検証（V＆V）を行うことになる書類となるものです。

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

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

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

ValidatorやVerifierの職能

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

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

　※Validationは、例えば、自社で行った試験や試料の選び方が、お客さんの要望と照らして妥当だったのかのような観点で、Verificationより高い目線で行います。

いずれも、確認対象の文書がどれなのか、合否判定時のチェック項目が何であって、誰が、いつ、どんな根拠で合否を判断したかがトレース（※後から辿っていける）可能な記録があることが必要（なので、表のように整理番号を振って、この課題にはこの方法で解決した、というように対比するわけです。後のページで後述するように、FMEA解析をするためのシステムのブレークダウンについても欧州ではある程度目安を示し、粒を揃えるように工夫されています）

日本のメーカー

Validatorは、後から「問題あり」だなんでひどい！　次から会議にも参加させて情報共有しよう。

・・・「今更言うな」と言いたなるし、「手戻り防止のため、事前に根回ししよう」・・・という発想になると思いますが、それではダメです。RAMSでのValidationは、要所要所で入るご意見番（これをValidatorと言います）のチェックです。その方は、不適合事象を見つけたら、プロジェクトを止めてしまえるだけの権限と、判断力とその背景の技術力を持った人でないとならないのです。

日本のメーカーさんで見かける、技術委員会のような集団判断を行う方式や、部署長の決裁のようなものではプロジェクトが止めずに済む妥協策を編み出してしまいますから、当初の計画と異なるものになってしまうだろうという発想です。

この部分追記します
　集団判断の場合には自分の仕事を自分でチェックするため、チェックにならない面があるのです。

現状の集団判断が変えられない組織では、さらにValidation（検証（妥当性確認））に当たる活動を追加的に行うことで、現状のやり方と、RAMSの両立を図ることはいかがでしょうか。

皆さんご多忙ではありますが、Validationは要所だけで行うものですから、ハードウェアでしたら製造・設計と無関係の部署（品証のような）の専門家で、より専門性が必要なソフトウェアの場合でしたら開発チーム同士で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系規格におけるVerificationやValidationについて大まかには下表のようにまとめられると思います。

この表の中で、「必要な能力」については、どう定めて、どう実証すればよいのか迷うと思います。

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

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

　

くどいですが「技術本部長だからValidatorとしての力量がある」「委員会で判断している」という説明だけでは不十分です。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段階の要求事項は、実際のプロジェクトでは仕様書に書かれているわけで、validationで参照すべき書類は（車両電機や電力分野については）要求事項だけでもかなりの多岐にわたる書類に分散していると思います。

一方欧州系プロジェクトにおける発注仕様書では、多数の欧州規格は引用している半面、日本のように具体的な製品指定又は定格の指定せず、大体の性能を示すことにとどめていることや、KPI（Key Performance Indicator)による数値目標の達成を要求されているため、要求事項自体は簡潔でも、要求事項を達成したかどうかを示す証拠は、設計仕様書、設計図書、試験計画書、試験結果等等、膨大になります。でも、無駄に膨大なわけではなく、技術的な合理性から考えると要求事項に対して適合しているかどうかを示す（＝このページ冒頭の図１の、トレーサビリティの説明）ためには当然といえるような内容です。

「RAMSの書類は膨大だ」という話は日本国内で笑い話になっていますが、その書類はトレーサビリティの説明のためです。それだけ要求事項が多い複雑なシステムを作り上げたから書類が多くなった、ということと思います。

海外の鉄道プロジェクトでは、海外企業との競争ですので、「日本製品だから安心」とはならないのです。何かあった時、調達した担当者が責任を問われますからね。

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

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


書類が多い話を述べてきましたが、RAMSにはコストもかかってしまうため、実際にはシステムの中でも、安全に関係する特定の新規開発部分に限定し、RAMS（信頼性、アベイラビリティ、保全性、安全性）の中でもS（Safety)のみ立証させるような使われ方が多いです。●●のソフトウェアのみEN50128（ソフトウェア）を適用する、というような使われ方です。なので、どこまで立証が必要かはよく詰める必要があります。

　※すみませんが、まだ作成できておりません。以下工事中です。

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