ASAM ODS : MBSEの基盤となる標準。自動車の全ドメインの製品V&Vデータマネジメント（PVM: Product V&V data Management）
Summary
Key Benefits: 会社全体で共通の”エンジニアリング・メタデータ”言語を使って会話をすることができます！どのドメイン、機能グループからも、共通の”エンジニアリング・メタデータ”を使用し、データにアクセスできます！これは、製品開発のライフサイクルを速めます。そして、関連情報へは、時間通りにアクセスでき、素早いエンジニアリングの意思決定を実現します。
これは、ASAM標準が、会社規模での複数の専門分野の
エンジニアリング課題を解決するために使用された、
初めての事例でしょう。
このアプローチのビジネスベネフィットは、エンジニアリング製品の
タイム・トゥ・マーケットを直接改善させる事です。
Puran Parekh, CEO, iASYS Technology Solutions Pvt. Ltd.
Situation
ほとんどのOEMは主要な製品ライフサイクルデータを取得する定義されたプロセスがあります。 しかし、Validationプロセスでは、各エンジニアは自由に実験を行い、好きなフォーマットでデータを保存し、自分で選択したツールを使用し、限定された、もしくは、実質ないに等しいビジネス情報と供に実験データを保存します。これにより、情報のコンテキストが完全に欠落しているため、実験データを再利用することが困難になります。また、Validationプロセスの一貫性を欠き、場合により、一貫性を作る事に多大なコストが必要となります。いくつかのOEMsは、実験データを管理していますが、それは、解析をしたいエンジニア向けにのみアクセスを提供しています。これは、特定のドメインや機能グループ内のエンジニアにのみ役に立ちのであり、他のドメインや機能グループへの接続性は欠いています。
自動車開発のValidationプロセスでは、多くの機能グループが関与していることはよく知られています。 多くの場合、車両の問題を共同で解決する必要があります。例えば、車両実験中に観察される振動の問題を解決する場合です。主に振動減がエンジンまたは、車両構造のいずれかであるため、問題の原因を特定するには、異なるドメインの複数の専門チームが協力します。
複数のチームが協力する場合、データを交換する必要があります。上記の例では、まず、車両実験グループは、計測した振動データを示します。次に、パワートレイングループは、同じ負荷条件で、燃焼データやECUのエンジントルクデータを確認します。異なるドメインからのデータを集めた後、主な振動源を特定することができました。それは、その試験条件下での急なトルク変動でした。
上記の例は、ドメイン機能グループ間で、共同で問題を素早く解決するために、データを交換する必要がある事を明示しています。また、異なるドメインのエンジニアがデータのソースを気にせずにデータを交換できる統合プラットフォームが必要である事も示しています。これは、様々な形式の実験データを格納できるASAM ODS標準により実現可能です。ASAM ODSのベネフィットは、アプリケーションモデル、つまり、データセマンティックを持ち、複数のドメインと機能グループ間のシームレスなデータ交換を実現する事です。
Table: Product Validation Management (PVM) at the Enterprise Level
最初のPOCで、ODS標準が製品のValidationデータを管理するためのベースになりえるといった仮説を検証できた。しかしながら、最大の課題は、標準の命名法がないため、すべての機能グループまたはドメインに対してエンジニアリング・メタデータ・ディクショナリを定義することでした。エンジニアリング・メタデータ・ディクショナリは、ドメイン、機能、テストプラン、テストタイプ、テストコンディション、測定特性、計測ポイントから成り立ちます。これは、各ドメインと機能グループでユニークです。
Success Strategy
通常、これらのプロジェクトはITチームによってIT戦略として推進されます。ただし、この場合、別のアプローチが採用されました。エンジニアリングドメインの専門知識をITソリューションアーキテクチャ適応させるアプローチです。
私たちは、ドメインコンサルティングを提供して、エンジニアリングValidationのノウハウを標準的なValidationライフサイクルプロセスにマッピングしました。最初に、主要なValidationプロセスと、パワートレインドメインの1つの機能グループの外部インターフェイスをキャプチャするプロトタイプを提案しました。エンジニアリング・メタデータ・ディクショナリの重要なスケルトンが作成され、テストタイプ、測定特性、測定条件、測定ポイント定義などの主要なValidationメタデータが作成されました。
次のフェーズでは、同じスケルトンを使用して、異なるドメインおよび機能からのデータをマップしました。すべての機能グループは、エンジニアリング・ディクショナリを定義できました。エンジニアリング・ディクショナリは、ドメインレベルで統合され、エンタープライズレベルまで拡張されました。
Standard Engineering Meta Data: Foundation for Model Based System Engineering (MBSE)
実装プロセスで、ODS標準が使用されました。実装後、命名法は標準化されました。これにより、エンジニアリング・メタデータ・ディクショナリによる、迅速な相関が可能になりました。解決策の発見に関しては、コンサルティングアプローチを採用しました。 さまざまなドメインを考慮して、お客様のユースケースに耳を傾け、UMLモデルを使用してユースケースをマッピングしました。テストデータに対してASAM ODSの明確に定義されたセマンティクスとアプリケーションモデルを使用し、定義されたUML図にマッピングしました。
Challenges During the Project
プロジェクトの最大の課題は、さまざまな分野のエンジニアによる受け入れでした。 彼らは、自分のドメインとデータが、他のドメインとは異なると認識していました。 ただし、ドメインデータを抽象度を上げたレベルでマッピングすると、その利点が理解されました。
2番目の課題は、エンジニアリング・メタデータの標準化でした。当初、エンジニアは最小の標準化レベルを採用することを決めましたが、その後、標準化レベルを徐々に上げてきました。
これは会社全体としてのイニシアチブ（トップダウンアプローチ）であったため、広い範囲での統合戦略が確立されました。 多くのエンジニアは、メタデータ・ディクショナリの概念を理解すると、このアプローチを受け入れました。
Business Benefits
OEMが計測ドメインを超えてデータを保存するために、ODS標準を使用することを、これまでに考えたのは、これが初めてである可能性が高い。私達のクライアントは、今、このアプローチのベネフィットを明確に見えています。それは、タイムトゥマーケットを短縮させ、データを上手に活用する事です。 ODSはすでに、明確に定義されたセマンティクスとアプリケーションモデルを提供しています。これらのモデルは拡張でき、機能グループのValidationライフサイクルデータを保存できます。さらに、ドメイン、および、機能グループは、強力なエンタープライズレベルのメタデータ・ディクショナリにより、結びつきます。