ネットワークアプリケーション

今回の実証システムにおけるネットワーク関係のデモでは(1)稼働管理、(2)リモートモニタリング、(3)TV会議応用、の3つのアプリケーションを試作した。これらは、いずれもインターネット技術を応用したもので、インターネットで標準的に用いられているソフトウェアを中心にシステムを構築した。理論的にはインターネットとの接続により世界中から、今回構築された生産ラインネットワークにアクセスすることも可能である。またパソコン用汎用ソフトを利用してシステム構築することで、安価なシステムであることも特徴の一つである。

まず、全体のシステム構成の概要を図 4-14に示し、次節以降でこれら3つのデモの内容を簡単に紹介する。

4-14 ネットワークシステム全体の構成:
稼働管理アプリケーション 稼働アプリケーションの概要

これは、ある時刻に於ける各ステーションの状態や、通電時間、稼働率などのトレンドを監視する目的のアプリケーションである。

各ステーションのOSECコントローラから、稼働状況をネットワークに送出し、送出されたデータは、ネットワークを経由してライン監視 DBに貯えらる。しかるのち、使用者がラインDBから情報検索するクライアント・サーバの形態により、所望する情報を得る。

サーバ側にはインターネットで標準的に用いられているWWW(World Wide Web)技術を利用した。WWWサーバーソフトとして今回はFree BSD 2.1上のNCSA httpdを用いた。これはCGI(Common Gat eway Interface)と呼ばれる外部プログラムの呼び出し機構の利用の容易性による。今後はWindows系のOS上のWWWサーバ・ソフトウェアへの移行を検討している。

一方クライアントは2種類用意している。1つめは、検索結果からHTML文書を作成し、NetscapeなどのJava対応 WWWブラウザをクライアントとする方式で、これは時々刻々と変化する各ステーションの現在時刻における状態を監視するものである。数秒〜数分程度の時定数で変化する事象のモニタリングを行っている。図 4-15にこの応用例のサンプル画面のハードコピーを示す。

2つめは、ライン監視DBに収集された情報からWWWサーバーにて粗い検索を行なった結果を、クライアント側に転送し、クライアント側のExcelなどの表計算ソフトに読み込んで集計および稼働状態のトレンドを集計しグラフ化する方式で、数時間から数週間以上の事象のモニタリングを行なうものである。図 4-16にExcelにてトレンドグラフを表示しているサンプル画面を示す。

4-15 稼働管理:現在時刻の各ステーションの状態

4-16 稼働状態のトレンドグラフ

稼働監視アプリケーションの仕組み

さて、これら稼働監視アプリケーションの試作例の仕組みについて説明する。まず1つめの現在時刻の稼働ステータスの表示である。アプリケーションを構成する機能を分類すると、 (i) 稼働ステータスの読みだしとネットワークへの送出、<(ii)ネットワークに送出された稼働ステータスの受信とDB化、(iii)DBの検索とクライアントへの検索結果の送出、( iv)クライアントでの集計と表示、の4つになる。

まず (i)であるが、各ステーションにはマシン・リソース・オブジェクト(MMIの章を参照)の内部にネットワーク・オブジェクトと称するイーサネット(業界標準のコンピュータ・ネットワーク)を通じたステータスの送出モジュールを組み込んだ。送出する内容は後述するOFMP(OSE Floor Management Protocol)に拠っている。

次に(ii)であるが、ライン監視DB側には専用の受信プログラムを用意しており、受信された結果をライン監視DBに送信されたステータスが蓄えられていく。今回CSV形式(表計算ソフトやDBソフトにて用いられるファイルフォーマットの一つ)でハードディスクに追記することとした。

(iii)の部分は受信した各ステーションの状態(今回はステーションAからCまでの3台分)HTML形式(Hyper Text Management Language形式)に変換して保持することとした。このHTML形式のファイルは新たなステータスを受信するごとに上書き更新されていく。さらにHTML形式ファイルにはクライアント側に対し、一定時間ごとの再読み込みを指示する命令を埋め込むこととした。表示画面作成にはJava(予定)を用いている。

(iv)の部分はNetscape社のNetscape等、汎用的に用いられているWWWブラウザそのものを利用しており、特殊なソフトは用いていない。もちろん表示を制御するプログラムは必要で、これはあらかじめプログラミングしておき、WWWサーバー側からクライアント側へ送出している。

この結果、通信時々刻々と変化していく各ステーションのステータス情報がWWWサーバからネットワーク経由でWWWブラウザに送信され、ユーザの手元のWWWクライアントで状態が描画され、稼働監視が出来る。

さて、2つめの仕組みであるが、(i)(ii)の部分は1つめの試作例と同じなので省略する。(iii)の部分であるが、WWWサーバのCGI機能を用いて、たとえば本日一日分などの粗い検索を行なった結果としてライン監視DBの一部が切り出しクライアント側に送出する機能を実装している。

(iv)の部分であるが、手元にある Excelにて情報の集計計算を行ない結果をグラフ化する。この機能はExcelマクロ言語とVBA言語によりExcel上でプログラミングされている。集計計算の結果には、電源ON/OFF時間の累積、加工時間の累積、アラーム時間の累積などがあり、さらにこれらを元にした稼働率、故障率、(生産実績、加工条件の良否)を集計出来る。

なお、集計する情報はバージョンアップを予定しており、その内容として工具使用実績管理(寿命)、加工条件、加工した環境(室温、主軸温度など)、加工結果(精度など)の情報などを検討中である。

リモートモニタリングアプリケーション

リモートモニタリングアプリケーションの概要

本アプリケーションは工作機械のコントローラの画面を、ユーザの手元にあるWWWブラウザで同じ画面を表示するためのものである。サンプル画面例を図 4-17に示す。 WWWサーバから送られた時々刻々と変化するコントローラ画面をJavaで表示しているものである(予定)

4-17 リモートモニタリングのサンプル画面


リモートモニタリングアプリケーションの仕組み

リモートモニタリングアプリケーションの機能は、(i)稼働ステータスの読みだしとネットワークへの送出、(ii) ネットワークに送出された稼働ステータスの受信、(iii) クライアントへのデータとプログラム送出、(iv)クライアントでの表示、に分類できる。

(i)の部分であるが、前述の稼働監視アプリケーションのネットワークモジュールで実現している。送出する内容と周期は前述のそれが、数秒から数時間以上の時定数で変化する事象を送出していたのに対し、こちらは数秒以下の時定数で変化する事象を取り扱う点が異なる。主軸の現在値をはじめとする各種座標値、主軸ロード値、実行中プログラムブロック、などが対象となる。したがって送出周期もそれなりの間隔で行なわれる。

(ii)および(iii)の部分であるが、これらは同一のプログラムとして実装した。各ステーションからの送出データを本プログラムで受信、後述のクライアントから転送要求を受け、クライアントに向け、再送出する動作を行なっている。

(iv)の部分であるが、WWWブラウザの描画機能を利用し、Java(予定)HTML拡張機能で受信した情報を画面に描画するプログラムを記述することで実現している。


TV会議応用アプリケーション


TV会議応用アプリケーションの概要

4-18 TV会議応用アプリケーションの例

設計と製造でのコミュニケーションなどを行なうTV会議、加工ラインの監視TV、などに応用可能であるが、今回は監視TVに応用した事例を展示する。なかでもステーションBにはテーブル・オンボード・カメラが取りつけられており、加工中のワークの様子を観察することが出来る。図 4-18に実行中の画面例を示す。

TV会議応用アプリケーションの仕組み

実装は米国コーネル大学が開発したCU-SeeMeによる。これは簡易TV会議システムとして広く用いられているフリーソフトである。ただし、ネットワーク・トラフィックに対する負担を避けるため、画像サイズと質および音声の品質はそれなりに抑えられているが、専用のTV会議回線、ビデオ回線を増設せずともコンピュータ・ネットワークを接続することで利用できることの簡便さは魅力的である。

会場内各カメラからの画像と音声はCU-SeeMeの中継サーバーを経由させており、ネットワークに接続されたコンピュータにクライアントを用意することでアクセスすることが可能でクライアントの台数は複数設置することが出来る。中継サーバーをカスケード接続することで理論上は無限に近い台数が可能である。

OFMP(Osec Floor Managemrnt Protocol)について

現在その名称自体仮称ではあるが、今後要求される機能を盛り込み発展を期している。今回の実証システムでは、稼働監視アプリケーションとリモートモニタリングアプリケーションで用いている。ここでは前者の物を紹介する。


おわりに

以上、本実証システムに於けるネットワーク関連のデモについて述べた。我々OSEC研究会でのネットワーク応用は実際のところ、検討を始めて日が浅い。従って、未完成の部分、検討不足の部分も多々ある。今後さらなる研究を進め、必要な機能の抽出とその適切な規約化を進め、オープン・コントローラに相応しい切り口を見出す予定である。