ケーススタディ中小企業の環境におけるIIoTへの第一歩

IIoTとインダストリー4.0は、今日の業界見本市やブログのトピックとして遍在している。多くの製品が、生産フローやデータ、ERPのような企業ソフトウェアの垂直統合を実現することを約束している。IIoTの完全なベンダー間相互運用性が約束されているにもかかわらず、特に生産機械ベンダーが機器と組み合わせて販売するソフトウェア・ソリューションを検討する場合、ベンダーロックに陥ってしまいます。.

リソースが限られていて、IT 部門が小規模または 1 人しかいない小規模企業にとっては、これはジレンマです。このような企業は、大企業との競争のために柔軟性に依存しているため、Industry 4.0のようなパラダイムを採用する必要がありますが、通常は巨額の投資と、一見すると計り知れないほどの技術的複雑さの壁が付きまといます。

このケーススタディでは、まず、機械データ通信用のコネクタがあらかじめ組み込まれているソフトウェア・インテグレーション・プラットフォームが、どのようにしてこれらの制限を克服できるかを紹介します。そして次に、産業用モノのインターネットへの道を歩み始めた小さな工場における、リアルタイムのマシンデータの最初の実用的なアプリケーションを紹介します。

お客様とご要望について

このお客様は、主にステンレス製のシートメタル製品を提供している中小企業のサプライヤーで、小ロットで複雑な製品ポートフォリオを持っています。

この分野で他のメーカーと競争していくためには、工場には技術的な進歩と生産工程の絶え間ない進化が必要です。そこでお客様は、最先端のロボットによるレーザー溶接を生産工程に導入し始めました。

プロセスそのものもさることながら、このようなロボット溶接ソリューションを生産計画に組み込み、コスト計算や品質管理などに必要なデータを取得することも課題の一つです。

顧客のIT環境

顧客のIT環境は自然に成長したものであり、したがって本質的に複雑である。その基盤として、レガシーERPシステムを使用しており、カスタムPHPウェブベースのアプリケーションや、他のソフトウェア製品（例：CAD、レーザーネスティング・ソフトウェアなどのCAM）や顧客システムとの直接データ交換のためのインターフェイスによって拡張されている。これらはすべて、Windows/Linux混在のサーバー環境と、Active Directory内のほぼWindowsベースのクライアントプールの中で行われています。ファイル・サービスは、主にWindows共有とDropboxに基づいている。.

一般的に、顧客の戦略は、使用するさまざまな技術（LAMPスタック、AD、Windows、O365、レガシーシステムなど）の量を減らすことで、ITインフラの複雑さを減らすことで、管理性を高め、エコシステム全体のメンテナンスコストを削減することです。

生産環境

生産機械は通常、使用期間が長いのが特徴です。そのため、すべての機械がインダストリー4.0アプリケーションに対応しているわけではなく、また、この分野の機能は非常に限られています。そこで、この記事では、ロボット溶接アプリケーションとその統合ニーズにのみ焦点を当てます。

この溶接システムは、固体レーザー光源、ロータリー・チルト・テーブル付きロボット、カメラシステム付き加工ヘッド、高出力レーザーアプリケーションに必要な保護セル、制御システム、補助システム（吸引、集塵、冷却）で構成される有名メーカーのターンキーソリューションです。

このシステムのコンポーネントは、さまざまな標準産業用相互接続（デジタルIO、Profinet、EtherCat、標準イーサネット）を介して通信します。ベンダーの仕様では、顧客のネットワーク・インフラストラクチャに公開されるのは1つの標準イーサネット・インターフェイスだけです。このインターフェースは、機械ベンダーの全体的なPLCシステムに接続されており、機械のデータと制御システムへのアクセスは非常に限られています。このインターフェイスが提供するOPC UAインターフェイスのデータポイントは10個未満で、工場が機械のPLC上で機械ベンダーの生産計画ソフトウェアを使用している場合にのみ入力されます。したがって、このインターフェースは、現在、私の顧客にとってあまり役に立たないことが判明しました。.

最初のステップ

最初のステップとして、目標はマシンのコンポーネントから直接データを取得することだった。.

クライアントは、今日のPLCや機械でますます一般的になっているOPC UA通信プロトコルを選択しました。この規格は、リアルタイム通信を確立するために使用することができ、したがって、産業用フィールド・バス・システムによって現在実装されている機能を置き換えることができますが、私たちのシナリオでは、リアルタイム機能は必要ありません。顧客のアプリケーションにOPC UAスタックを直接統合するためのSDKは入手可能ですが、通常は複雑なため、複雑さを軽減するという目標に反しています。.

そこでクライアントは、カスタム・コーディングの代わりに、使いやすいインターフェイスを備え、ERP、CRM、各種文書管理システム、データベースなどのバックオフィス・システムに接続可能なOPC UAコネクターをあらかじめ構築し、ローカル・ベースやクラウドベースのリーズナブルな価格設定の統合プラットフォームを選択する。.

これらのシステムを統合プラットフォームを介して直接制御することは、機械の安全性に必要なシングルポイントオブコントロールの原則に反する可能性があるため、目標としていません。

データポーリングの頻度

この工場では、新技術の適応プロセスが進行中であるため、ロボット溶接システムは単一シフトでしか稼働せず、機械は就業時間中であっても常時稼働していない。したがって、この時点で取得されたデータは有用かもしれないが、将来的な使用や予測目的には信頼できないかもしれない。これは、他の生産機械（レーザー切断機など）から取得したデータに関する顧客の経験に基づいている。ある要因（生産サイクルが終了したときに機械オペレーターがその場にいたかどうか、データ取得がトリガーされたときかどうか）によって、一見高精度に見えるデータでも間違った絵を描く可能性があり、生産工程の効率を判断するために細かい粒度が必ずしも必要ではないことが証明された。.

そのため、現在は30秒というかなり低いポーリング頻度でデータを取得しています。

この最初のステップでは、お客様はこれら3つの主要コンポーネントからデータをポーリングしたいと考えています。

レーザー光源を使用しています。

ロボットのPLC,

カメラシステム。

しかし、現時点ではレーザー光源しか接続できません。ロボットのPLCはOPCクラシック・インターフェースしか持っておらず、ユニファイド・アーキテクチャーへの移行は現時点では困難である。.

レーザー光源用OPC UA

残るはレーザー光源です。幸いなことに、このシステムには最新のコントローラが搭載されており、洗練されたOPC UAインターフェイスが組み込まれています。このインターフェイスにはいくつかのレベルのアクセス権がありますが、そのレベルは、読み取り機能を制限した匿名アクセス、読み取り専用、読み取りと書き込みです。前述のように、機械の安全性の観点から、読み書き可能なアクセスは問題外であった。そのため、読み取り専用のアクセスを選択しました。

このインターフェイスは、豊富なデータを提供します。

レーザーシステムの全体的な状態

運転期間、使用電力、...

エラーとメンテナンスのメッセージ

この統合プラットフォームを使って、顧客はC#でWindowsサービスを開発し、データを定期的にポーリングして、将来使用するためにいくつかのSQLデータベーステーブルにコンパイルしました。このテーブルには、一般的なデータ、機器の使用状況、メンテナンス用のテーブル、レーザー光源で生成されるエラーメッセージなどの情報が含まれます。

この機械のデータをどう使うかが大きな課題です。

最初の貴重な洞察は、マシンのログメッセージのコンパイルである。私の顧客が過去に経験したのは、すべての機械が再起動までログファイルを保持するとは限らないということだった。また、機械のオペレーターが、故障やエラーを正確に上司に報告するとは限らない。その結果、重大な故障が発生した場合、機械のダウンタイムが必要以上に長くなることがある。この日、機械が稼動していたかどうか、これは重要な問題である。.

会社の技術管理者が簡単にアクセスできるように、このような日報はPDFファイルとして作成され、機械ベンダーへのサポートコールが必要な場合に備えて、共有のDropboxに保存される。.

もちろん、これはOPC UAコネクタの膨大な機能の中でもごく限られたアプリケーションに過ぎない。お客様が開発している次のステップは

生産サイクルの正確なスタート/ストップタイミングを得るために、ロボットのPLCに接続（他に不可能な場合はデジタルIO経由で）。.

会社のタイムシートシステムと連動させることで、マシンが実際に生産に使われている時間と、ティーチング（ロボットプログラミング）やロード／アンロード／メンテナンスに使われている時間をよりよく把握できるようになる；;

カメラ・システムへのアクセス：レーザー溶接は異なる溶接プロセスであるため、私のクライアントの顧客は、実際の製品が納品される前に、この生産方法を認証する必要があります。このような工程は、溶接工程の完全なドキュメントを常時自動配信できれば、はるかに容易に達成できます。.

さらに、計画的な複雑さと使用するサービスの削減により、Dropbox-SharedからOneDriveへの移行は、関係するすべてのクライアントに展開された後に差し迫っています。また、お客様は、予知保全のためのデータ分析の可能性にも興味を持っています。

結論

前述したように、このプロジェクトはまだ初期段階であり、完全に機能するIIoTソリューションになるまでにはまだ時間がかかります。統合全体をプログラミングするのではなく、あらかじめコネクタが組み込まれている統合プラットフォームを利用することで、別の接続スタック（OPC UAやDropbox APIなど）の詳細を知る必要がなくなりました。また、私の顧客にとっては、将来のアプリケーションのための集中的な通信スタックを提供してくれました。

リチャード・マイヤーについて

リチャード・マイヤー、中小企業向け産業ITおよびオートメーション技術に特化したflupo Systemtechnik e.U.の創設者。起業以前は、高出力レーザー・アプリケーションの研究開発機関に勤務し（レーザー技術、FEMシミュレーション、産業用ロボット、PLCプログラミング、産業用フィールドバスシステムの経験を積む）、中小企業環境におけるソフトウェア開発（主に異なるソフトウェア製品や生産計画アプリケーション間のインターフェース）を中心に、一般的なIT分野で10年以上の経験を積む。ウィーン大学で数学の修士号を取得。.