AAS仕様からのAPI生成の自動化

インダストリー4.0の台頭により、システム同士のコミュニケーションをより良くするための新しい標準が導入されました。その一つがアセット管理シェル（AAS）で、産業機械や製品が情報を共有する方法を改善することを目的としています。2024年初頭、産業デジタルツイン協会（IDTA）はAASのさまざまなサブモデル仕様を発表しました。

これらの多くの仕様を効果的に管理するためには、アプリケーションプログラミングインターフェース（API）と呼ばれる特別なツールが必要です。仕様の数や複雑さを考えると、手作業でAPIを作成するのは現実的ではありません。代わりに、仕様を機能するコードに変換する自動化されたアプローチを取ることで、多くの時間と労力を節約できます。

この記事では、サブモデル仕様からAPIを自動的に生成する方法について説明します。このプロセスで直面した成功と課題を探ります。

#アセット管理シェルの理解

アセット管理シェルは、物理資産（機械など）に関するデータを整理する構造化モデルです。サブモデルで構成されており、資産に関する重要な情報を含んでいます。各サブモデルには、プロパティ、データ要素、操作、他の要素との関係などの要素が含まれます。

サブモデルの要素はさまざまな形式で定義できます。各要素には特定のタイプ、値があり、複数の言語での説明も含まれることがあります。AASはJSONやAASXというバンドルXML形式など、異なる形式で共有でき、すべてを体系的に整理します。

#自動化アプローチの目標

自動化アプローチの目的は、サブモデル仕様からAPIを作成するプロセスを効率化することです。これにはいくつかの目標があります：

1. コード生成: 仕様の構造に基づいてAPIのソースコードを自動的に作成します。
2. 検証: 生成されたAPIが仕様に従っていることを確認します。
3. 情報追加: APIの使用方法に関する追加情報を含めます。
4. タイプ解決: 要素のタイプが一貫して正しく定義されていることを確認します。
5. テスト: 仕様に基づいた例を元に生成コードのテストを作成します。

これらの目標を達成することで、開発者は機能的で使いやすいAPIを作成できます。

#三段階アプローチ

提案された自動API生成の方法は、主に三つのステップで動作します：

1. 入力のパース: AASXまたはPDF形式の仕様から情報を読み取り、抽出します。
2. 変換: 抽出された情報をコード生成に適した中間モデルに変換します。
3. コード生成: 変換された中間モデルに基づいてAPIコードを作成します。

#ステップ1: 入力のパース

最初のステップでは、指定された仕様からデータを収集します。仕様はPDFのような直感的でない形式や、AASXのような機械可読形式で提示されることがあります。

PDFでは、情報がテーブルに整理されていることが多く、抽出が難しくなります。初期段階では、PDF形式を読み取るためにいくつかのライブラリを試みましたが、壊れたテーブルなどの問題が発生しました。最終的に、PDFをExcelテーブルに変換できるクラウドサービスが見つかり、処理が楽になりました。

AASXファイルは機械可読性を考えて設計されていますが、問題もあります。AASXの異なるバージョンは情報の構造が異なるため、これらの違いを効果的に扱うためのカスタムパーサーを作成する必要があります。

#ステップ2: 変換

データを抽出したら、次は中間モデルに再構築する必要があります。生データが必ずしもコーディングに最適な基盤になるわけではありません。

この変換ステップでは、入力から抽出した情報を補強し、コーディングに使いやすくします。一貫性のない情報や欠落情報を解決し、モデルをAASフレームワークで定められた要件や概念に aligned します。

#ステップ3: コード生成

最後のステップでは、中間モデルをAPIコードに変換します。目的は、指定されたAAS構造を作成または操作できる一貫したコードを生成することです。

APIコードに加えて、ユニットテストも自動的に作成されます。これらのテストは、生成されたAPIが期待通りに機能するかどうかを確認するために設計されています。全体の目的は、生成されたコードが各サブモデルの仕様に従っていることを確認することです。

#結果: 成功と課題

自動化アプローチは、有望な結果を示しました。18の仕様のために、50,000行以上の使用可能なコードを生成することができました。しかし、いくつかの課題も発生しました。

#課題の特定

• 仕様のバリエーション: 仕様が常に一貫しているわけではありません。同じ情報を異なる方法で書くことが複雑さを生み、手動での介入が必要な場合もありました。

• 欠落情報: PDFおよびAASX形式の両方で、重要な詳細が欠如していたり誤って表現されていることがありました。これにより、パースおよび変換ステップで修正が必要になりました。

• タイプと定義: タイプの定義のバリエーションがさらなる不一致を生み出しました。同じ概念に異なる用語を使用する仕様があり、統一された理解を確立することが重要でした。

• AIとの適応: データの抽出や解釈を助けるためにAIを使用する初期の実験は期待通りの結果が得られませんでした。AIには可能性がありますが、AAS仕様の特性には常に一貫したレベルが求められました。

#学んだ教訓

この経験からいくつかの重要な教訓が得られました：

• 一貫性が重要: すべての仕様で情報を表現する統一された方法を持つことは、自動化プロセスを大いに容易にします。これには明確な定義、一貫した用語、標準化されたフォーマットが含まれます。

• バージョン管理の必要性: 仕様のさまざまなバージョンを追跡することが不可欠でした。各AASXファイルがどのバージョンの仕様に従っているかを明記する必要があります。

• 検証のためのより良いツール: 問題が主に人為的なミスや不明確な仕様から発生したため、仕様のフォーマットや意味をチェックするツールが役立つでしょう。

• 文書が重要: 特に制約や要件についての追加メモを仕様に提供することで、生成されたコードが意図した目標を満たすのを助けることができます。

#今後の方向性

この自動化アプローチの開発はまだ進行中です。今後の計画には以下が含まれます：

• 継続的な改善: IDTAの仕様が更新されるにつれて、手動介入の必要を減らすように自動化方法を改善できます。

• 既存プラットフォームとの統合: 生成されたコードは、実際のテストおよび検証を可能にするために、既存のインダストリー4.0プラットフォームに統合されます。

• AIサポートの向上: 今後の改善には、パースや抽出を支援するためのAIツールの利用促進が含まれるかもしれません。指定されたフォーマットが一貫して解釈されるようにします。

• 他の形式への拡張: 新しい仕様が導入されるにつれて、近くこのアプローチが適応できるようにする必要があります。追加の要素や属性も含まれるようにします。

#結論

IDTAのサブモデル仕様からAPIを自動的に生成するプロセスは、その効果を示しましたが、課題も少なくありませんでした。これらの仕様を機能するコードに変換する能力は、インダストリー4.0における相互運用性をサポートできます。一貫性、明確な文書、検証のための適切なツールに焦点を当てることで、アプローチをさらに洗練させることができます。産業デジタルツインの風景が進化する中で、この自動化された方法はプログラマーやエンジニアにとって重要なツールとなり、未来の基準が効率的かつ正確に満たされることを保証します。