2019年8月27日 - リサーチ、インダストリー4.0、テクノロジー、人工知能
ANSI / ISA-95のような国際的な自動化標準は、金属生産をいくつかの層に階層的に編成します。ベースでのプロセス制御（L1）から始まり、プロセス自動化（L2）、製造実行（L3）、最後にビジネス管理（L4）です。 。これらの層が一緒になって、いわゆる「オートメーション階層ピラミッド」を形成します。
"ピラミッドの層に存在する各システムは、特にその含まれる層のそれぞれのプロセスの最適化に焦点を合わせて、過去数年にわたって進化してきました。システムは、データを交換し、隣接する階層間でフローを制御することによってのみ、相互に対話できます。異なる階層の一部がどのように相互作用するかについては「インターフェースマッピング」定義に記述され、各インターフェースは独自の言語（プロトコル）を使用しています。一部のインターフェースの言語は標準化された記述で表現されますが、いくつかのインターフェースは固有の言語を使用しているため、各階層間によって相互作用する部分のみの対話が可能です。"
確立されたオートメーション階層ピラミッドへのAIおよび機械学習(ML)の適応例を模索する中で、固有の問題が明らかになります。 AI、特にそのアプリケーションMLには、取得したデータとその消費プロセスの高度に統合されたビューが必要です。これら手法で入力と見なすことができるデータは、工程設計システムなどのさまざまなソースから取得されますが、粒度の粗い生データを提供するセンサーなどからも取得されます。これらすべてのデータソースからのデータの組み合わせは、今日「ビッグデータ」と呼ばれるものの基礎を形成します。
生産環境でのビッグデータと機械学習の組み合わせの実用的な例は、生産が始まる前にさまざまな生産ラインを経由する通過工程（ルート）に基づいて完成品の品質を予測するというコンセプトです。重要な品質の予測を達成するには、さまざまなデータソースを考慮する必要があります。
影響を与えるさまざまなパラメータの履歴データと、プラントとその周辺の現在の状態に基づいて、生産される品目の品質について事前に予測することができます。予測結果は、結果的に品質を向上させ、欠陥件数と瑕疵の重大性を最小限に抑えるために、生産ルートの選択に影響を与えます。この予測メカニズムには、多種多様なデータソースからの上記のすべてのデータが必要です。これらのソースをオートメーションピラミッドのそれぞれの階層にマッピングすると、ピラミッドのすべての階層間においてまんべんなくデータ分布を持つ画像が描画されることになります。
AIテクノロジーの恩恵を受けるために、アルゴリズムには、作成、変更、処理されたすべての生産データについて、高度に統合された偏りのない視点が不可欠です。
これには、レベル1からL4までのオートメーション階層ピラミッドのすべての階層にわたるデータとそのソースが含まれます。オートメーション階層ピラミッドに基づく現在の情報技術基盤を介してこれらのデータを自由に取得することは困難であるか、不可能ですらあります。
階層性に基づくオートメーション階層ピラミッドのアプローチ、個々の階層における責任の分離、および各階層に適したサービス提供のための高度に専門化された製品は、長年にわたり実証されています。しかし、新しい研究分野、新しい機会、本番環境に対応したソフトウェアコンポーネントなど、IT業界における近年の新しいトレンドにより、このような伝統的アプローチには大きな重圧に直面しています。オートメーションピラミッドを支えてきた基盤技術は、これらの新しい技術的要請に対する妨げとなってしまっています。
この理由の1つは、階層間に導入された隠れた抽象化です。各階層は、主にデータの独自のビューと独自のレベルで必要なプロセスに集中しているため、異なる階層間のインターフェイスで情報が不可分に失われます。
たとえば、生産ラインを介した注文の通過工程（ルーティング）を計画するL3プロセスでは、冷間圧延プロセスを実行するときに上部サポートロールの平均圧力を知る必要はありませんでした。しかし今、このプロセスとそのサポートアルゴリズムは、このデータを同様の以前の状況で行われた選択と関連付けるためにこの情報を必要とします。または、品質の低下が認められた場合に連続鋳造プロセス中に切断時の長さを調整できるようにするために、L2プロセスで直接注文明細の詳細情報を入手することは合理的かもしれません。ストランドで短く切断してしまい、実行するスケジューリング順序がない場合、不要な未割り当ての半完成品になりますが、わずか50センチ後にカットを実行すると、受注済み注文に完全に適合します。
IoT、ビッグデータ、機械学習などが偏りのないデータから利益を得る方法を教えてくれるので、オートメーション階層ピラミッドの既存の階層化は限界に達します。インターフェイスに固有の階層間で抽象化を使用すると、各階層の上下のレベルからデータが隠されます。この効果は、複数の階層を横断する場合でも倍増します。レベル1からの情報は、インターフェイスとその間のL2が抽象化されているため、L3に到達したときに、同じ意味と完全性を持つことはほとんどありません。この情報は、L2が「決定」するため、L3でさえ認識されない場合があります。これをL3に渡すことは役に立ちません。同じことが、上位レベルから下位レベルへの下流方向にも当てはまります。
特に新しいIT分野に関係するのではなく、階層化の側面の継続的な使用に関係するもう1つの問題は、変化に迅速に適応する能力の欠如です。
上記の例で述べたように、連続鋳造機の制御システムに直接、今後の注文に関する詳細情報が必要になる場合があります。オートメーション階層を保持したままこの注文情報を利用するには、まずERP等のL4システムから一旦注文データを取得し、L3システムを通過する必要があります。このようなシステムの構築は最初は容易かもしれませんが、L4の注文情報にキャスト固有の属性情報が追加された場合、どのように対処すれば良いのでしょうか？L4からL2へのデータ移行には、たとえ属性がL3で処理されるプロセスと無関係であっても、常にL3システム内での変更が含まれます。
厳密なオートメーション階層ピラミッドアプローチを使用すると、実行中のシステムに不要な変更が加えられ、外部ベンダーへの依存関係が生じ、リソースを占有し、変更を行う能力が妨げられる傾向があります。
オートメーション階層ピラミッドに関する説明された問題と、新しい領域やテクノロジーに適応する意欲を考慮して、オートメーション階層ピラミッドの階層の異なる編成を見つける必要があります。
私たちの日常生活のさまざまな分野で、さまざまな形態の組織が見られます。一部の企業は、組織構造を厳密な階層レイアウトから、企業の各部分が階層を尊重せずに異なる部分と対話できるマトリックスレイアウトに変更しました。ソフトウェアアプリケーションアーキテクチャは、階層化アーキテクチャから六角形アーキテクチャ、さらには完全なマイクロサービスアーキテクチャに変わります。
したがって、オートメーション階層ピラミッドの階層を小さな部分に分割し、各部分が互いに直接通信することで、新しいアプリケーション領域が可能になる場合があります。これは、階層自体を排除するだけでなく、ビジネスプロセス指向の方法で個々の部分を統合する可能性も示唆しています。要するに、これは、水平面での集約階層を除去し、ビジネスプロセスに沿った垂直統合を可能にすることを意味します。
階層の制約から自由になり、様々なアプリ同士の相互連携を可能にするためには、システム参加者の組織形態をもっとオープンなものに変更し、通信規格とそのセマンティクスを調和させることが必要不可欠です。このような標準化アプローチがなければ、異なる階層間にわたってインタフェース仕様は「固有要件」の性質を帯びてしまいます。更に別の機能を持つアプリを追加するなどということをやると、データ交換用のインタフェース要件は更に増加することになってしまい、導入時の工数は増加の一途をたどってしまいます。
"このようなデータインタフェースの互換性問題に対処するために、PSIメタルズは拡張機能としてMetals Service Busを内包するPSIbusの開発に踏み切ることになったのです。"
"「バス」という用語は、IT業界でほぼ数十年にわたって使用されており、2000年代初頭に頂点に達し、2010年頃に復活を遂げました。これらのシステムは、ほとんどがシンプルで軽量な通信フレームワークとして開発されましたが、時間の経過とともに徐々にインテリジェンスが追加されていきました。しかし、完全なエンタープライズサービスバス（ESB）としてこのバスが技術的に成熟するのを待つ必要がありました。たとえば、特定のシステム機能を実行するために、システムのどの部分を使用するかを選択するタスクも、このバスに配置されるようになりました。ますます多くのドメイン知識が関係する部分からバス自体に加えられていきます。"
"複雑さへのさらなるステップは、ビジネスインフラストラクチャ自体が、参加者（プレーヤー）の持つ異なる方言（プロトコル）間を翻訳（変換）できるようにすることでした。これはまた、プロトコル変換による情報の抽象化と損失につながりました。初期のバスシステムでは無理やりインテリジェンスを追加導入するあまり、バスシステム自体が過負荷になり、操作が複雑になることが散見されました。やがて、「バス」自体はもはや通信技術によるプラットフォームではなく、アプリケーション自体になってしまいました。"
PSIbusとは、金属業界向けに特化したオープン技術に基づくまったく新しいプラットフォームです。
PSIbusのこれらのメリットを総合すると、「メタルズ・サービス・バス(Metals Service Bus)」と呼称しています。
オートメーション階層ピラミッドを分解するための最初のステップは、参加者間のコラボレーションの別の方法を考えることです。階層を個々の部分に分割することにより、関係するすべての部分間の直接通信を可能にすることが設計上推奨されます。コラボレーションは階層型からピア型に移行します。このようにして、すべての参加者は平等に扱われ、同じ豊富なデータにアクセスできます。生産管理ソフトウェア（MES）としてのPSImetalsは、Metals ServiceBusの最初の金属固有のユーザーです。 PSIbusを個々のパーツの相互作用のバックボーンとして使用することにより、MESの「内部」コンポーネントが外部から見えるようになります。 MESの内部コンポーネントは、他のPSIbus参加者と簡単に統合することもできます。これにより、協力の可能性が広がり、貴重な企業間コミュニケーションが可能になります。
さまざまなシステムやコンポーネントを接続する機能に加えて、使用する「言語」は、これらのさまざまな部分をうまく統合するための重要な要素です。 「バビロニア語の混乱」を回避するためには、話される言語を統一することが絶対に必要です。情報技術では、これは「プロトコル」と呼ばれます。 PSIbusは、データとフローの交換のための技術プラットフォームに加えて、標準化の提案として統一されたプロトコルも提供します。プロトコル自体は、人間と機械で読み取り可能なデータのテキスト表現に基づいており、IT全体の標準JavaScript Object Notation（JSON）に従います。
標準プロトコルと相互作用の概念に加えて、PSIbusにはソフトウェアインフラストラクチャも必要です。このようなソフトウェアインフラストラクチャコンポーネントの1つは、PSIメタルズ社の親会社であるPSISoftwareAGによってPSIJavaFrameworkの一部として提供されています。これらインフラストラクチャー層用のシステムコンポーネントは、他業種（ガス、石油輸送監視システム、倉庫管理、その他の製造システムなど）、多くの業界で使用されています。 PSIメタルズ社では、金属生産および生産プロセスの要件に特化した構成でこのPSIbusを機能拡張することにより、これらPSIグループ企業内のコンポーネントとの接続性を具備しています。 また社外のサードパーティーがPSIbusに参加しやすくするため、通信は近年の標準API技術であるRESTやJSON、JMSなどの標準ウェブ技術に基づいています。これらをオープンプロトコルと組み合わせることで、あらゆる業界の垣根を超えて、いかなるシステムともPSIbusに接続することができます。
これらの初期のバスシステム(EAI)と区別するために、金属固有の拡張機能を備えたPSIbusは、関心（ドメイン）との分離を厳密に維持します。 PSIbus自体は、統一された通信用バスとしての仕組みとプロトコルを介して、さまざまなシステムのさまざまな部分同士を疎結合させるためのアーキテクチャ上のアプローチです。このインフラストラクチャ自体に鉄鋼を生産する方法のドメインのインテリジェンスは無関係です。実際、システム参加者はインテリジェントなエンドポイントとして機能し、ビジネスロジックを「サービス」として隔離するような配慮がなされます。
マイクロサービス化を提唱したJames Lewis氏のマントラはこうです。「土管はシンプルに、末端は高機能に！(Dumb pipe - smart endpoints)」
PSImetals フューチャーラボディレクター、ハイコウルフ(Heiko Wolf)
ハイコ氏は、過去12年間、PSIメタルズ社で鉄鋼およびアルミニウム業界向けのソフトウェアを開発してきました。 フューチャーラボプロジェクトの責任者として、彼はソフトウェアアーキテクチャ、継続的デリバリー、アジャイル導入手法、そしてそれらすべてが金属業界にどのように適合するかについて提言しています。
+49 30 2801-1863
hwolf@psi.de