インダストリー 4.0 資産管理シェルの検討ノート (3) - アプリケーション シナリオとアーキテクチャ

        資産管理シェル (AAS) はインダストリー 4.0 の重要な概念であり、AAS は本質的に、デジタル モデルの「シェル」を物理的な機器 (いわゆる資産) に追加して、資産情報の交換を実現します。AAS は、ハードウェア デバイスをサービス (サービス) に変換し、ソフトウェアを通じて要求および提供できるようにします。例えば、CNC工作機械に「ある位置に穴を開けてほしい」と依頼するのもサービスです。I4.0 の観点では、デバイスはサービスプロバイダー (Service Provider) になります。PLC は生産プロセスの一部を実行するのではなく、明確に定義されたインターフェイスを備えた生産サービスを提供します。人と機械が完結する本来の生産プロセスをITシステムのデータフローと制御フローに変換し、その処理がネットワーク上のソフトウェアの呼び出しとなります。また、これらのデータストリームや制御ストリームは統一規格に準拠しており、メーカーとは一切関係がありません。すべてのデバイスに標準準拠の AAS が追加されると、「プラグ アンド プロダクション」の目標を実現できます。

簡単なシーンから始めましょう

        ここでは、ロボット アームを使用して CNC 工作機械のロードとアンロードを実現し、コントローラとして PLC を使用する例を示します。I4.0 管理シェルが CNC とマニピュレータ コントローラの両方に実装された後、コントローラ プログラムは CNC 管理シェルにアルミニウム シェルの処理を要求できます (一種のサービス)または、ロボット アームに原材料パレットから原材料を取り出して (サービス)、CNC 工作機械に配置するように要求します。CNC 管理シェルが完了イベントを送信すると、ロボット アームは加工されたアルミニウム シェルを取り外します (サービス) )完成したトレイに置きます。プロセス全体を次の図に示します。

上記の処理手順は次のとおりです。

  1. 原料を取る
  2. 処理
  3. 完成品を手に取る

        この制御方式はマスター/スレーブ構造であり、従来の制御技術を使用する場合、コントローラーは PLC または産業用コンピューター (HMI インターフェイスが必要な場合) によって実現されます。

        実際の生産工程では、CNCの加工プログラムやロボットの動作、ロボットとパレット間の位置認識などの詳細も必要となります。これらのタスクは、CNC プログラムを産業用コンピューターに手動でインポートしたり、数量を処理したりするなど、手動で実行できます。上位MESソフトウェアを使用して、各種パラメータをリモートからダウンロードすることも可能です。したがって、アーキテクチャは次のようになります。

          この種のマスター/スレーブ アーキテクチャ システムは自動システムで一般的であり、生産プロセスの制御はコントローラー内で完了し、CNC とロボット アームはマスター コントローラーからのサービス コールを受け入れ、ステータス情報をマスター コントローラーに提供します。CNC とロボット アームには独自のプログラムがあり、コントローラによってダウンロードされるか、他のコンピュータ (CNC プログラミング ワークステーションなど) によってダウンロードされます。

        CNCやマニピュレータにAASが搭載されている場合、コントローラのプログラムはCNCやマニピュレータのメーカーや機種とは関係ありません。各メーカーのハードウェア製品の AAS は同一モデルであるため、統一されたアクセス プロトコルが採用されています。現在、CNCコントローラやロボットアームコントローラにはさまざまなプロトコルがあり、メーカー独自のプロトコルやパラメータに慣れるまでに多くの時間がかかります。ロボットアームのフィールドバスインターフェースカードやAPIドライバーをCNCに適合させるには多額の費用がかかります。これは、AAS がシステム統合にもたらす直接的な利点です。

        余談になりますが、多くの場合、自動化システムの新技術は、エンドユーザー(CNC加工工場)にとって直接的な価値はあまりありませんが、システム統合の開発コストを節約することができます。最終ユーザーに送信されます。

分散型 AAS アーキテクチャ

        AASはマスタ・スレーブ方式以外にも分散制御方式を採用することができ、例えば上記のCNC演算装置を以下のような方式に変更することも可能です。

このプロセスはシリアルに分散されます

1 ロボットアームに原料を取り出して CNC 操作テーブルに設置するように通知します。

2 ロボット アームは CNC に加工開始を通知します。

3 CNC はロボット アームに、加工されたアルミニウム ケーシングを取り外すように通知します。

      この構造はさらに複雑になります。ロボット アーム AAS は CNC AAS と通信する必要があります。ロボット AAS は CNC AAS に「おい、処理しましょう」と伝え、CNC の処理が完了すると、CNC AAS はロボット AAS に「おじいさん、取りに来て」と伝えます。

では、CNC とロボット アームにプログラムをダウンロードするにはどうすればよいでしょうか? 明らかに、次の 2 つの方法があります。

1 コントローラはプログラムをロボット アームにダウンロードし、ロボット アームは CNC にダウンロードします。

2 AAS 通信を通じてコン​​トローラによって 2 つの AAS に直接ダウンロードされます。

        1 つ目の方法は比較的単純で、デバイスのメーカーがデバイスの特性や提供するサービスに応じて AAS を構築し、上位層のソフトウェアがデバイスを制御します。前工程や後工程の設備の状態を知る必要も、隣との連携も必要なく、上記の意味だけを見ればわかります。ただし、分散型 AAS ネットワークは、複数のユニットが連携する生産ラインでは一般的な構造でもあります。たとえば、缶詰ラインや自動ハンドリングトロリーと生産ユニット間のドッキングなどで飲料にさまざまなラベルが貼られています。分散型協調ネットワークは、デバイスのプログラミングと展開が容易です。

AASの2つの通信方式

 この観点から、AAS には 2 つの通信方式があります。

   垂直通信: 上位層ソフトウェアと AAS の間の通信プロトコル。OPC UA プロトコル、HTTP プロトコルなどがあります。

  水平通信:  AAS と AAS 間の通信プロトコルは、インダストリー 4.0 プラットフォームでは I4.0 言語と呼ばれます。

AAS が導入されている場所

        AAS は資産の管理シェルであり、いわゆる資産は広範なオブジェクトです。ビジネスにとって価値のあるものなら何でも構いません。具体的には、PLC サーボ ドライブやセンサーなどのフィールド デバイス、または MES、ERP ソフトウェア、デバイス内のメイン コントローラーなどです。理論的には、各オブジェクトに AAS を追加できます。

       デジタル製造システムを構築する過程で、すべての物理的な機器とソフトウェアに対して AAS を構築するのでしょうか? それとも AAS を選択的に構築しますか? トレードオフの問題があります。AAS の実装には追加のコンピューティング能力が必要となり、初期のエンジニアリング作業が増加します。

      たとえば、CNC 工作機械の内部は、Windows ベースのメイン コントローラー、複数の PLC、サーボ モーター、センサー、およびアクチュエーターで構成されている場合があります。CNC 内の制御機器 PLC は AAS を実装する必要はなく、従来のフィールド バスと制御プロトコルを使用してデータ通信を実現します。AAS は、従来のフィールド制御バスを介して内部資産とデータを交換する必要があります。

        もちろん、AAS を備えた一部のコンポーネントは、エンジニアリング設計プロセス中に生産ユニットとして形成できます。すべてのデバイスとコンポーネントには AAS があります。

        このようにして、AAS を使用したデバイスの通信はより柔軟かつ複雑になります。上位層の AAS は、下位層の AAS の SubModule を呼び出すことができます。

各 AAS はサービス プロバイダーでもあり、サービス リクエスターでもあります。 

I4.0言語

        I4.0 の観点では、水平協定は I4.0 言語と呼ばれ、VDI/VDE 2193 標準に準拠しています。これは、メッセージベースの通信プロトコル (MQTT プロトコルなど) に基づいて構築されています。JSON形式で。

AAS はメッセージを通じて通信します。

現在、i4,0 言語の仕様には MQTT プロトコルのみがあります。ネットワークの階層構造を次の図に示します。 

 

         I4.0 言語は OPCUA の SUB/PUB プロトコルと互換性がありません。OPCUA の SUB/PUB プロトコルを使用して I4.0 言語を送信できるかどうかわかりません。MQTT ベースのプロトコルはリアルタイムではありません。フィールド制御の分野では、フィールド制御バスとして OPC UA SUB/PUB プロトコルを採用することが開発の方向性です。しかし、それを AAS レベルのコミュニケーションと組み合わせる方法は研究する価値があります。

管理シェル (AAS) のソフトウェア アーキテクチャ

        前回のブログ投稿で述べたように、AAS は、AAS As File、静的パラメーター AAS、プログラマブル AAS (proAAS)、および動的 AAS に分類できます。AAS ファイルはエンジニアリング設計プロセスで使用される AAS ですが、他の AAS はデバイスに埋め込まれています。

静的 AAS

     スタティック AAS は比較的シンプルで、内部に垂直プロトコル スタック (AAS スタック) と AAS モデルがあります。これは OPC UA に似ています。実際、AAS モデルは OPC UA 情報モデルを使用して構築でき、OPC UA プロトコルを使用してアクセスできます。

アクティブAAS

 アクティブ AAS のネットワーク プロトコルは比較的複雑です。

1 他の AAS のサブモジュールにアクセスできます。

アクティブな AAS ノードは、サービス プロバイダーとサービス リクエスターの両方です。OPCUA の観点からは、これらは OPCUA サーバーと OPCUA クライアントの両方です。

2 他の AAS サービスを呼び出す機能

3. 他の AAS から送信されたサービス リクエストに応じてアルゴリズムを調整できます。

     機能のこの部分は AAS 内のアルゴリズムに対応しており、これらのアルゴリズムは機器制御プログラムの一部ではなく、追加プログラムです (産業用の最適化、スケジューリング、パラメーター構成などを完了するための元の主制御機器プログラムの一部です) 。)。ソフトウェアのこの部分を作成するのは誰ですか、機器プロバイダー、またはシステム インテグレーターですか? それを書くためにどのような言語が使用されますか? これらはすべて議論する価値のある問題です。

したがって、AAS 内のプログラムは次のようになります。

AAS は 2 つの部分に分かれており、1 つは静的 AAS モデル、もう 1 つはサービス要求に応答する動的 AAS モデルです。

 より詳細な内訳として、AAS のソフトウェア アーキテクチャは次のとおりです。

 より複雑なシナリオ

        実際の生産現場は非常に複雑です。上記のCNC加工装置を例に挙げると、実際の現場では原材料や製品のパレットも必要です。ロボットアームは、画像認識装置や相互作用方法(RFIDなど)を通じてワークピースを識別する必要があります。 )どこに置くか。相互に対話するには、パレットに AAS シェルが必要です。また、部品を掴むためには素材の幾何学的形状などの情報が必要となるため、素材のAAS(静的AAS)が必要となりますが、素材が外部調達や社内での粗加工を伴う場合には、素材のAAS(静的AAS)も必要となります。原材料仕様の分類番号の技術。理想的には、生産プロセスに関与するすべての機器と材料にはデジタル モデル (いわゆる管理シェル) が必要です。

      すべての技術的改善は、生産効率の向上、生産コストの削減、製品品質の向上を目的としています。ロボットアームとCNCだけが作業場に設置されている場合は、パレットの積み下ろし、ハンドリング、サプライチェーンの外部調達などを行います。これらの作業を依然として人手に頼っていては、投資に比べて生産効率はあまり向上しません。したがって、企業は生産ラインを変革するためにデジタル技術を導入することに積極的ではありません。

       サプライヤー間で AAS コミュニケーションを実現するには、用語、属性、指標を標準化する必要があります。これには、Ecl@ss 辞書サーバーをインポートする必要があります。

コンセンサス

        現在の I4.0 の発展状況から判断すると、I4.0 は新たな IT 技術を開発するものではなく、さまざまな情報モデルの確立と言語の標準化の確立と推進が鍵となります。技術の実現は難しいことではなく、I4.0のビジョンを実現するには相互接続の実現が鍵であるということで業界全体のコンセンサスが得られています。標準化は、コンセンサスを見つけ、競合他社間の利益相反に対処し、さらには国際的な調整までに長い時間がかかるため、非常に困難で時間のかかるプロセスです。プロモーションの過程で「標準の硬直性」という現象が現れ、一般に受け入れられるまでユーザーはその標準を採用しません。しかし、全員が停滞して他の全員が進歩するのを待っていると、時間が無駄になってしまいます。

        そのため、開発の初期段階で標準化された内容の一部をどのように採用するか、現地の製造業にどのように利益をもたらすかなど、標準の硬直性を克服する方法を見つける必要があります。標準化を利用して新しいビジネス モデルを開発することで、開発者は商業的な利益を得ることができます。これらは、エンジニアと経営陣が熟考すべき質問です。これは技術的な問題だけでなく、社会的、ビジネス的な問題でもあります。

結論

        インダストリー 4.0 管理シェルは、新しい概念を備えたまったく新しいデジタル製造手法です。ドイツに拠点を置く外国機関が提案する未来のデジタルマニュファクチャリングのビジョンマップですが、彼らが解決したい問題と私たちが直面している問題は異なり、言語や文化的背景も異なります。したがって、私たちは多くの概念や概念を完全には理解していませんが、現在の状況に直面すると、イノベーションの機会がたくさんあります。他人を真似する必要はありません。

         インダストリー 4.0 のあらゆる取り組みは、イノベーション サイクルの短縮、よりパーソナライズされた製品、より柔軟な生産を実現することを目的としています。この車はさまざまな色とトリム構成を提供していることがよく言われます。生産ラインは生産する製品に応じて頻繁に調整する必要があります。生産ラインが単一の製品のために設定された専用の生産ラインの場合。たとえば、フォードは1色しか生産されません。インダストリー 4.0 はあまり活用されていません。人工知能技術の導入や制御アルゴリズムの最適化などがインダストリー4.0で解決すべき課題ではないはずだ。これはよく誤解される質問です。

        私が書いたブログ記事には理解の逸脱が多数あります。あくまで参考として、一緒に話し合うためのものです。

おすすめ

転載: blog.csdn.net/yaojiawan/article/details/126984360