自動機と言えば、制御にはFAコンピュータかPLCが使われるのが一般的だ。
動作の見通しの良さや安定性、電源事情の影響が少ない事からもPLCを使う事が多いと思われる。
IoTシステムを構築するには、ネットワークと接続しデータベースへのアクセスが必要となる。
ただしデータベースに接続さえすればIoTシステムが構築できる訳では無い。
どの様な条件の時にどの様なデータを書き出すのかは予めPLC側で準備しておく必要がある。
ここに多くのノウハウが存在する。（改めて纏めておく予定）
一方、PTCのThingworx等のIoTプラットフォームを活用する手段もある。
PLCに接続された各種センサーの値をPLC上のメモリに展開しておけば、Thingworx側で勝手にデータを吸い上げ、元々用意されている、様々なグラフ等で表示や管理が出来る物である。
非常に簡単に見栄えの良いシステムを短期間で構築する事が出来る。
＜Thingworx デモ画面＞
しかし、基本的にはPLCに対するポーリングとなる為、我々の様に海外にある大量の設備が対象となると、ネットワーク負荷の問題を避ける為に、通常は各工場毎に装置を導入する事が必須となり、当然ランニングコストも高額になってくる。
今回我々はThingworxの表示機能のみを活用するとともに、PLC側からのPUSHによるデータの登録手法を実現してみた。
PLCとデータベースを接続する上で大事な事として、一方向のデータのやり取りだけではだめだ。
自動機においては、前工程が確実に終了しているかどうかを必ず確認した上で加工に進む必要がある為だ。
この事を踏まえた上で代表的なPLCの接続方法を比較して見る。
◆サーバーポーリング方式
先に説明したThingworx同様サーバー側がPLCにデータを取りに行く方式だ。
PLCのメモリアドレスを介してのやり取りになる為PLC側の負担は少なくて済むが、サーバ側の負担が大きくなりネットワーク負荷も増大する。
なお、必要なデータはサーバー側がPLCに書き込みに行く事に成る。
◆直接アクセス方式
PLCが直接SQLを発行しデータベースとアクセスするものだ。
当然サーバー側にプログラムは不要だが、PLC側の負担が多くなる。
最近は面倒なSQLを介さなくても、データのやり取りを簡単に行えるPLCも存在する。
しかしネットワーク環境が変わった場合など、全てのPLC側のソフトを修正する必要が発生する為、運用面で面倒な事例に遭遇する事も多々ある。
◆ファイルI/O方式
PLCからサーバーの指定フォルダにファイルを転送する方式だ。
サーバーには転送されたファイルを解析し、データベースに書き込むソフトを用意しておく必要がある。
比較的容易にシステムを構築する事が出来るが、構造上リアルタイム性に欠け、双方向の通信が困難である。
そこで我々は以下の２種類の転送方式を実用化した。
【１】マスターPLC中継方式
各設備のPLCは、１ラインに１台ずつ用意したマスターPLCに対しデータの読み込み要求を出し、マスターPLCが予め用意された各設備のメモリーマップを一括で読み込む方式だ。
その後マスターPLCは代表してデータベースにデータを書き込む事に成る。
この方式は設備側PLCのプログラム変更を最小限にとどめ、ネットワーク環境の変化への対応はマスターPLC１台が全てを引き受ける事でメンテナンス性を引き上げる物だ。
データベースには無料のMySQLを使用しており、設備毎にテーブルを用意している。
これは弊社のタイ工場において実際に導入している物で、約7,000台/日の生産量を実現しているラインを7ライン、問題なく稼動させている。
因みに、このラインでは前工程確認を行っていない為、このシステムが成り立っていると言える。
問題や不良が発生した場合は、その場でラインが停止する方式を取っているためだ。
つまり双方向のデータのやり取りが必要なシステムには不向きとも言える。
なお、導入当初は先に説明した「ファイルI/O方式」を採用していた。
後に、次に説明する「サーバースクリプト方式」が上手く立ち上がった事を受けて「ファイルI/O方式」を止め、「サーバースクリプト方式」とのハイブリッドシステムとして稼働を続けている。
【２】サーバースクリプト方式
マスターPLC方式を拡張した物で、用意されたメモリーマップのデータを、サーバーに用意されたスクリプト（バッチ）に送る物だ。
このスクリプトは、受け取ったデータを指定のデータテーブルに記録する。
どの装置から送られたデータは、どのデータベースに書き込むかは、すべてスクリプトが判断し実行する。
つまりネットワーク環境の変化にはこのスクリプトが総て対応する事に成る。
設備PLCのメモリマップには予め多くの情報が割り当てられており、設備の動きに合わせた様々な情報をセットする様にプログラムが組まれている。
この方式の良い所はスクリプトが希望のデータを返して来る事だ。
これを見込んで、大きく分けると、前工程確認用のスクリプトとデータ書き込み用の２つのスクリプトを用意し活用している。
これにより前工程の確認も可能となった為、自動化設備のフリーフローラインに向いている。
設備毎にテーブルを用意しているのは先のシステムと同様だが、どの製品がどこまで進んでいるのかは別途用意したProcessテーブルで管理されていおり、前工程管理は基本的にこのテーブルで行っている。
本システムは弊社の中国工場の大型電子機器組み立てラインで導入しており、７本の自動組み立てラインで想定通りに問題なく稼動している。
少し前まではPLCとデータベースの接続は中々進まなかったが、上記２種類の方式を実用化した事により一気にIoT化が進んだと言える。
なお中国工場では、イラストの様にサーバーを２台使用している。これは社内LANと異なったセグメントに自動化設備を繋ぎたかった為だが、データベースのバックアップも兼ねている他に、多岐にわたるサーバーの仕事を分散させる事に役立っている。
なお、これらのシステムの実現には、（株）キーエンス殿に多大なる御協力を頂いた事を付け加えておく。
