今回は、Node-REDを使ってOPC UAでPLCの値を読み書きした際に気づいたことをまとめる。
前回やったこと
下図のようにCODESYSをインストールしたラズパイでシーケンス制御を実行し、制御内で使用されている変数をOPC UAでPCに読み出し、読み出した値を表示した。
気づき
OPC UAでPLCから情報を収集するような以下のシーンを想定する。
このシーンを想像しながら、データ収集と表示までの手順を振り返ると、下記困りそう。
PC設計者：
- どのデータを読み出せば良いかわからない。
- 対象データの表示方法を決めるために、サイズ、更新頻度などデータの仕様理解が必要。
- デバッグが困難。PLCが止められないため。
PLC設計者：
- データを公開するには、変数追加や設定変更が必要。PLCを止めたくない
- そもそも対象データ自体取れない。センサ取り付け、プログラム変更、変数公開が必要。PLCは止めたくない
- そもそもプログラム変更でサイクルタイムが変わって欲しくない
じゃあどう進めるのだろうか？こんな感じ？
①PLC設計者が公開するデータ仕様を決定し、仕様書に記載
②PC設計者は仕様書をもとにNode-REDで読み出すデータを追加
③PC設計者はスタブで、データ読み出しをデバッグ(スタブ面倒)
④PLC設計者は仕様に従いセンサを追加(んーPLC電源落としたくない)
⑤PLC設計者は仕様に従いプログラムを変更し、変数を公開する(んーPLC電源落としたくない)
⑥PLC設計者は仕様に従い変更内容(プログラム)をデバッグする(PLCは稼働させたままにしたい)
⑦PC設計者はNode-REDで作成したデータ読み出しをデプロイし動作検証(ちゃんと動作するか不安)
①〜⑦をPC側とPLC側で並行作業する。
①→④→⑤→⑥↘︎
↘︎②→③→→→⑦
とここまで考えて、重要なことは、当たり前だが
「何が目的かを明確にすること」 だと思う。
PLCで制御する設備のチョコ停など内部の問題を見える化するのであればPLCの変数を見る必要があり、 そうではなく、製造したモノの検査結果などPLC外部でも取得できるものは、PLCではなくラズパイなどを使った データ収集で構わない。上記シーンを前者とすると、これを実現するためには、以下のようなことが必要そう。
- ③でスタブが簡単に作成できる
- ④で部分的に電源OFFできる。PLCとは別の電源系統で、そこを止めてもシーケンス制御に影響しない。
- ⑤でシーケンス制御を止めずに、プログラム変更ができる
- ⑥で実機PLCと同様の振る舞いができるシミュレータ
- ⑦でデプロイ先と同様の環境での事前検証機能
こういった機能が世の中にあるかというとまだ十分ではなさそう。 データ活用という点で、機能の充実を図って行くことも重要と感じた。
