デジタル製品パスが具体化すると、IT部門は他の何よりもまず次のような質問を投げかけます。「このプラットフォームは、当社のどのシステムにアクセスする必要があるのか？」これは適切な質問です。その背景には、アクセス権限、ファイアウォールの許可設定、そして誰かが責任を負わなければならないセキュリティ対策があるからです。
私たちの答えは簡潔です。「どのシステムも対象外」です。パスポートにデータを提供するすべてのシステムはソース側にあり、そこに留まります。Transpareoはチェーンの末端にある受信者であり、データフローは一方通行でプラットフォームへと流れ込みます。この記事では、以下の流れを追跡します： 各システムが何を提供するか、各データストリームにどのようなルールが適用されるか、そしてどのような応答が返ってくるかを追跡します。
各システムがパスポートに提供するデータ
パスポートのデータが単一のシステムから得られることはめったにありません。実際には、データは数種類のシステムクラスに分散しており、それぞれが提供するフィールドはごくわずかです：
-ERP- 品目識別情報、材料、サプライヤーおよび原産地、注文およびロット情報、数量。変更されることがほとんどない安定したマスターデータ。 -MES- 生産履歴、シリアル番号およびロット割り当て、品質証明、トレーサビリティ。特定の時点に紐づくイベントデータ。 -APS- 生産タイミングおよびリソースの割り当て。パスには直接関係することは稀であり、重要な情報は通常MES経由で提供される。 -PLM- 構成、部品表、修理可能性、交換部品、設計ステータス。 エコデザイン規則が求める要件に照らすと、最も密接に関連する情報源である。 -PIM- 説明、画像、メンテナンスおよび使用上の注意、言語バージョン。消費者向けのコンテンツ。 -IoT- 使用段階における状態および使用データ。バッテリーなど、特定の製品グループでのみ必要とされる。 -CRM- 個々の顧客のサービスおよび修理履歴。基本的に個人を特定する情報であるため、公開パスには含めない。
管理シェルは各システムの「隣」ではなく、「上」に位置する
他のどの区別よりも重要な点が一つあります。それは、アセット・アドミニストレーション・シェル（AAS）がERP、MES、PIMの「横」にあるのではなく、「上」に位置するということです。AASはデータを生成するのではなく、既存のデータを相互運用可能なサブモデルにカプセル化します。Transpareoへの連携という点では、AASは便利な形式ではありますが、必須の提供形式というわけではありません。 AASを利用している場合は、そのサブモデルからデータパッケージを導出します。利用していない場合は、別の方法で同じフィールドを提供します。それでもなお、なぜ私たちが管理シェルを優れた基盤だと考えているのかについては、AASに関する記事をご覧ください。
あらゆるデータフローに適用される5つのルール
方向。すべての矢印はプラットフォームを指しています。Transpareoはどのソースシステムからもデータを取得せず、またTranspareoはERP、MES、PIM、PLMへのアクセス情報を一切保有していません。 セキュリティ対策が必要なシステム間の接続は存在しません。そもそもそのような接続が存在しないからです。
トリガー。データのプッシュは常にソース側でトリガーされます。つまり、メーカー自身、そのミドルウェア、または委託されたサービスプロバイダーによって行われます。プラットフォームは待機しているだけで、データを取得しに行くことはありません。
目的限定。送信されるのは、パスに必要なデータの一部のみであり、ソースシステムの全データではありません。パスに必要なのは各システムからごく一部のフィールドのみであり、それ以外は元の場所にそのまま残ります。
公開。各データパッケージの選択、範囲、およびタイミングは、ソース側が決定します。 Transpareoは、提供された以上のデータを受け取ることはできません。
権限。プラットフォーム上で提供されたデータをどのように扱えるかは、指定されたアクセス権限によって規定されます。権限は最小限に抑えられ、明示的に許可されていないことはすべて禁止されます。これらのルールはプラットフォーム側で適用され、ソースに対して遡及的に適用されることはありません。
戻ってくるのは受領確認のみ
完全な逆方向通信チャネルなしでは成り立ちませんが、そこを伝送されるのはデータではなく、応答です。具体的には、DPP-URL または GS1 Digital Link、バージョンID、公開ステータス、および検証メッセージです。 ソース側にとって、これらのフィードバックは、ERPやPIM内のパス参照を商品データに直接紐付けられるという点で価値があります。これらはアクセスそのものではありません。受領された納品に対する受領確認に過ぎないのです。
実務で実績のある3つのパターン
-基幹システムから直接。ERPやPLMがコネクタを介してデータをプッシュします 。データソースが1つに明確に限られている場合に、シンプルかつ合理的です。 -アグリゲーション層を経由。ミドルウェアやiPaaSがERP、MES、PIMの各フィールドを統合し、1つのパッケージとして提供します。 複数のデータソースが関与する場合の標準的な手法です。 -AASサブモデル経由。管理シェルはすでに稼働しており、データパッケージはそのサブモデルから導出されます。インダストリー4.0環境において有利です。
どのパターンがどのシステム環境に適しているか、また、そのようなプロジェクトを3ヶ月ではなく2週間で完了させる方法については、ERP連携プレイブックにまとめています。
Transpareoが意図的に採用していないこと
第2の「システム・オブ・レコード」ではありません。このプラットフォームは、パスポートデータセットとその変更不可能なバージョン履歴を保持するものであり、メーカーの運用データを保持するものではありません。ERPで修正された内容は、新しい納品を通じてパスポートに反映されます。これは、既存のデータへの黙示的な変更ではなく、追跡可能な新しいバージョンとして反映されます。 このバージョン履歴がどのように署名され、誰もが検証できるようになるかについては、署名と証明書に関する記事に記載されています。
これにより、お客様のセキュリティ対策において確認すべき事項はほとんどなくなり、まさにそれが意図するところです。 お客様が外部に開示するアクセス情報は存在せず、内部へのファイアウォールの開放もなく、ERPへの読み取り権限を持つ外部システムも存在しません。実際のプロジェクト作業は、本来あるべき場所、つまり「パスにどのフィールドを含めるか」を決定することにシフトし、「誰がどこにログインできるか」を決定することではなくなります。