ASAM ODS : MBSEの基盤となる標準。自動車の全ドメインの製品V&Vデータマネジメント(PVM: Product V&V data Management)

Summary

Challenges: 近年、多くのOEMが下記の課題に直面しています。

・数百種類の計測機器から出てくる、さまざまなファイル形式やデータ構造の実験データをどのようにしてモデルの世界に持ち込むか?

・どのようにしてビジネス情報を実験データに結びつけ、データをナレッジとして会社に残すか?

・V&Vプロセスの効率を向上させるため、個々の機能グループがもつValidationノウハウを全社のV&Vプロセスレベルでどのようにして、つなげるか?

iASYSは、日本の大手自動車会社と協力し、同様の課題の解決に、取り組みました。それは、野心的なプロジェクトであり、まずは、1ドメインのプロトタイプの作成から取り組みました。現在、このアプリケーションをドメインや機能グループに展開しています。

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ライフサイクルデータを保存できます。さらに、ドメイン、および、機能グループは、強力なエンタープライズレベルのメタデータ・ディクショナリにより、結びつきます。