これまでブラックボックスだったNC装置の内部の制御系ソフトウェアを整理・部品化することでアーキテクチャ化を行った。具体的には、国際ロボットFA技術センター(IROFA)のNCオープン化政策委員会ワーキンググループで報告された制御階層（図 3-1）を実装可能なレベルまでブレークダウンし、目的・処理内容・要求される実時間性などの点から機能毎に分類し、一つ一つの機能のまとまりを『機能ブロック』と呼ばれるソフトウェア部品として再構成した。制御系ソフトウェアが機能ブロック単位でプラグアンドプレイできることを目指している。またOSEC-Iの階層に対応するものとして、機能ブロックのうち同じレベルにあるものをまとめた『機能群』を規定した。
図
3-1 制御階層（IROFAの報告書より）
各機能群および機能ブロックのサービスの概略を表 3-1に示す。参考のため、各機能ブロックを再構成する上で想定した、要求される実時間性も併せて表す。応答のタイプを基準に、これら機能群のうちリソースマネージメントと動作生成はランダムイベント型、機械制御とデバイス制御は周期イベント型と区別することもできる。
|
|
|
|
|
| リソース
マネージメント |
リソース制御 | (32〜100msec) | 機械資源および操作系ソフトウェアからのイベントを処理する。 |
| 動作生成 | OSEL実行系 | OSELによる加工プログラムの最終出力であるOSEL-Xを解釈し動作生成をを行う。 | |
| EIAコードデコーダ | EIAコードによる加工プログラムを解釈し動作生成を行う。 | ||
| 手動制御 | ジョグやダイアルなどマニュアル入力による動作生成を扱う。 | ||
| 機械制御 | マシン制御 | 8〜16msec | 補間と加減速処理、サーボとI/Oの同期などを行う。 |
| デバイス制御 | サーボ制御 | 1〜2msec | 各軸のサーボ制御を行う。 |
| PLC制御 | 20〜50msec | DIからの信号入力を受けてラダープログラムを解釈しDOに信号を出力する。 |
各機能ブロックはオブジェクトの形でソフトウェア部品化され、これらオブジェクトに対するメッセージをインターフェイスプロトコル(OSEC API)として定義した（付録A参照）。各機能ブロックはオブジェクトとしてカプセル化されているので、機能ブロックがメッセージを受けて処理をどのように行うべきかはアーキテクチャとして規定されていない。つまり処理の実装に関しては機能ブロックの開発者に任されている。こうしたカプセル化により、企業や個人が個別に独自の付加価値を加えやすくなる。また処理方法を規定しないことは、各機能ブロック間の結合関係を規定しないことも意味する。OSECアーキテクチャではあくまで論理的な機能ブロックのサービスの内容とそれら機能ブロックに対する論理的なメッセージを定めているだけである。このためOSECアーキテクチャモデルとしては、各機能ブロックは図 3-1のような階層構造にはならず、各機能ブロックに対するメッセージ(OSEC API)を介して並列に接続される形となる（図 3-2）。
またモータ・I/Oといった制御コンポーネントハードウェアのプラグアンドプレイを可能にするため、各ハードウェアはデバイス制御機能群の中に隠蔽される。サーボ制御・PLC制御などの対応した機能ブロックへのメッセージがこうしたハードウェアへの唯一のインターフェイスとなっている。
図
3-2 OSECアーキテクチャモデル
論理的な機能ブロックから構成されるOSECアーキテクチャは一意に規定されるものである。しかしこれらの各機能ブロックを物理的に実装するときには、デバイスドライバ・プロセス・プロセス間通信といったシステムの機能、静的なライブラリ・DLLといった組込の手法、利用する制御カードなどのハードウェア要因、あるいは各種ソフトウェアの実行制御・監視用に追加されるソフトウェアモジュールなどの実装方式に依存したものとなる。そのためアーキテクチャを実装するための実装モデルとしては１つには限定されず、システムの規模や構成するハードウェアなど実装の形態あるいは使われ方に応じて複数存在することになる。図 3-3は特に各機能ブロック間の結合関係を明示的にした実装モデルである。
図
3-3 OSEC実装モデル
図 3-4は各機能ブロックを実装した一つの構成例である。また実証システムの各ステーションの説明でも、実装例が詳しく述べれれている。
コントローラのマンマシンインターフェースは、それぞれの機械に適した操作環境を実現するという点で機械メーカやエンドユーザなどにとって非常に関心の高い部分である。しかしながら、こうしたマンマシンインターフェイスを実現するソフトウェアとしては、これまではコントローラメーカが作った基本的な操作環境を利用するしか方法がなかった。同様に、機械運用のためのアプリケーションソフトウェアも、機械に対する標準的なインターフェイスの欠如から、個別の作り込みを行ってきていた。オープンコントローラでは機械メーカやエンドユーザなどが自由に操作系ソフトウェアを構築・改良できるものと期待を集めている。
機械メーカ・エンドユーザなどが自由に操作系ソフトウェアを構築・改良していくためには、以下の事項を考慮する必要がある。
操作系ソフトウェアに関するOSECアーキテクチャでは、こうした要求事項を満たすための手段としてアプリケーションフレームワークというソフトウェア開発手法を全面的に取り入れた。従来のソフトウェア開発手法では、ソフトウェアの大部分は一つ一つ積み重ねていくようにして開発する。そこでの開発労力は、あらかじめ用意されたソフトウェアライブラリを呼び出すことで低減できるが、あらかじめ用意された部分に比べて新規に開発する部分の比率はかなり多い（図 3-5(a)）。一方、アプリケーションフレームワーク手法では、ソフトウェアは今までのような積み重ねによっては開発しない。あらかじめアプリケーションソフトウェアのひな型が用意されていて、目的に合わせてそのひな型を変更したり拡張するのが開発作業の主となる（図 3-5(b)）。当然こうした改良にはあらかじめ提供されるライブラリが利用できる。このようにアプリケーションソフトウェアのひな型、すなわちアプリケーションフレームワークを利用することで機械に対する操作系ソフトウェアの開発を効率よく行えるよう目指したのである。
(a) 従来の手法 (b) アプリケーションフレームワークを用いる手法
一般に、操作画面に関するソフトウェアのひな型としては『モデル(Model)・ビュー(View)・コントローラ(Controller)』という３つの部分(MVC)に分けて考えると効率的である。機械の操作系ソフトウェアの場合、『モデル』は操作する対象である機械のモデルに、『ビュー』は画面およびGUI部品など画面要素に、『コントローラ』は操作系ソフトウェアでのロジック、すなわちGUI部品のボタンが押されたときの処理や機械の状態が変わったときの処理に相当する。このうち機械をオブジェクトの形で『モデル』化したものが『マシンリソースオブジェクト』であり、OSECアーキテクチャとして標準化がすすめられた。
こうした工場内の事物のオブジェクトによるモデル化は、分散オブジェクト技術の業界標準であるOMG (Object Management Group)などでも『生産オブジェクト』として取り組まれ始めた。またコンピュータを利用した半導体製造システム(SEMI)では、最近、ホストコンピュータとその管理下にある装置群との間の関係を標準化するために、ホストコンピュータから見た下位の装置群との共通部分をGEM (Generic Equipment Model：包括的な装置モデル)と呼ばれるモデルで規定する方法が用いられている。これまで装置のベンダはホストコンピュータとの接続のために個々のソフトウェアを開発する必要があったが、ホストコンピュータとの接続に必要な共通部分がGEMに組込まれ標準化されたため、ホストコンピュータと各装置はGEMを介して独立することになり、システムインテグレータや装置ベンダはGEMとのインターフェイスを遵守している限り、独立にアプリケーションソフトウェアを開発することが可能となった。
図
3-6 マシンリソースオブジェクトの概念
同様に、マシンリソースオブジェクトも機械とアプリケーションの間のインターフェイスの標準化を図ることによって、ソフトウェアの可搬性・移植性・再利用性・拡張性の向上を狙ったものである。マシンリソースオブジェクトの標準的なインターフェイスとして、表示操作関係のアプリケーションインターフェイス・生産管理など上位プラントフロアアプリケーションとのインターフェイス・NC制御部（NC制御カード・PLC・サーボなど）とのインターフェイスの3つの切り口を備えたモデルを採用している（図 3-6）。
図 3-7は工作機械を対象としたマシンリソースオブジェクトにおける機械資源のクラスの概略図である。軸・スピンドル・ツール・PLCなど工作機械の持つ様々な資源を論理的に分析し、各資源の属性・機能を明示的に定義してオブジェクト指向関連図(ORD)としてまとめたものである。これらの資源に対する指令と状況の問い合わせが各資源オブジェクトに対するメソッドの形で定義されている。操作系ソフトウェアとしては、機械の各資源オブジェクトにメッセージを投げる形で機械に指令を与えたり機械の状況を知ったりする。
図
3-7 マシンリソースオブジェクトのクラス概略図（Coadの記法による）
現行のマシンリソースオブジェクトは工作機械をオブジェクトの形でモデル化したものだが、同じ工作機械といってもマシニングセンタ・旋盤など機種の違いや同じ機種でも軸の数・パトライトなど付属品の有無といった構成の違いなどによって機械資源が異なってくる。そこでマシンリソースオブジェクトとしては抽象的な工作機械の一般的なモデルを一つ用意しておいて、機種や構成の違いはその一般モデルから派生されたオブジェクト群を個別の機械に対して構成し直すことで対応している。ここではオブジェクト指向での継承の概念が利用されている。
操作系ソフトウェアからはマシンリソースオブジェクトにより標準的な工作機械が一意に見えるようになったが、実世界である制御系とインターフェイスすることを考えると、制御系としては制御ボードなどに応じて様々な実装形態が存在するため、一意というわけにはいかない。OSECアーキテクチャでは、抽象的な仮想世界であるマシンリソースオブジェクトから実世界である制御系への展開を行うために、コントローラの内部構造(制御実行部)へアクセスするためのリソース制御という概念が導入されている。
図
3-8 マシンフレームワークによる操作盤画面作成の例
最近のソフトウェア開発環境やツールの動向として、アプリケーションフレームワークを備え、ソフトウェアを部品化することで効率的に開発が行えるものが注目を集めている。こうした統合環境のもとで、マシンリソースオブジェクトを中心とする、工作機械の操作系ソフトウェアのためのアプリケーションフレームワーク（マシンフレームワーク）によって操作盤画面を作成した例を紹介する（図 3-8）。この例で使用したマシンフレームワークは、ビジュアルビルダや高機能コンパイラなどを備え効率良くC++アプリケーションソフトウェアを開発するための統合環境であるVisualAge C++を基盤としていて、次のような特徴を持つ。
この環境のもとでの工作機械の操作用ソフトウェアの開発は以下のように行う（図 3-9参照）。
現在のNC装置で一般的に利用されているEIAコード（Gコード）の体系は1960年代に開発されたもので、ISOなどにより工作機械のための標準データフォーマットとして国際的に標準化が行われた。その結果、技術開発の出発点がそのレベルに合わされ、NC装置が今日のようにブラックボックス化して発展したというのも事実である。しかし、当時の技術レベルに合わせて設計されたものが陳腐化し、それを防ぐために改良を重ねられてきた結果、次のような問題点が指摘されている。
こうした問題点の解決に加え、エンドユーザや機械メーカなどにあまた蓄積されている固有の生産技術を、ソフトウェアの形でパッケージ化し、再利用可能にするための手法を提案することが加工法記述言語OSEL (OSE Language)の目的である。これはさらに、ネットワークを中心とするであろう将来の産業社会の中で、ソフトウェア化された固有の生産技術が流通し調達できるような新たなビジネス環境への転換という大きなパラダイムシフトへの提言をも行うものである。これは、産業のグローバル化により空洞化が叫ばれている昨今、現場での「もの作り」を中心としたビジネスから、「もの作り」で得られた生産にかかわる知識やノウハウをもとにした新たなビジネス環境への転換を促すものである。
加工法記述言語OSELの特徴を以下に列挙する。
OSELにおける処理の流れの概略を図 3-10に示す。
図
3-10 OSELにおける処理の流れ
最上位レベルでの記述であるOSEL-F (Feature OSEL)では、加工プログラムは穴・溝といった加工特徴の記述、例えば「貫通穴をドリルで開けよ」といった形で入力される。OSEL-Fは加工特徴クラスライブラリと工具クラスライブラリを利用して、機械独立な中間記述である OSEL-I (Intermediate OSEL)に展開される。OSEL-Iは機械クラスライブラリを利用して、 機械に依存した実行フォーマットであるOSEL-X (eXecutable OSEL)に展開される。実時間で処理する必要のあるのは、このOSEL-Xプログラムの解釈処理部（OSEL実行系：OSEL-EX）以降である。
加工特徴クラスライブラリでは、機械に依存しない加工方法が、穴・溝・側面といった加工特徴に基づくクラス毎のメソッドの形で定義されている。図 3-11に加工特徴クラスの基底クラスの概略図を示す。機械メーカ・エンドユーザなどは、この基底クラスの派生クラスを自由に加えることによって、独自の加工ノウハウを加えていくことが可能である。
機械クラスライブラリでは仮想的なプログラム座標系から物理的な機械座標系への変換や実I/O指令など、機械に依存した処理への展開がメソッドの形で記述されている。工具クラスライブラリは工具に関するデータライブラリで、加工特徴クラスライブラリからは工具の寸法や加工条件を得るために、機械クラスライブラリからは実際の工具の名称を得るために参照される。
図
3-11 加工特徴クラスの基底クラスの概略図（Coadの記述による）
オープンコントローラへのOSEL処理系の実装としては、コントローラのシステム構成やユーザ要求などに応じて、図 3-10の実装モデルA・B・Cと示された3つのモデルから選択できる。実装モデルAでは、コントローラは一番抽象度の高いOSEL-Fプログラムを受け取り、軸制御まで一貫して行う。CAD/CAMの機能を備えた高度なコントローラではこの構成になると思われる。実装モデルBでは、コントローラは機械独立な中間記述である OSEL-Iを受け取る。機械依存部分以下をコントローラが受けもつ形態である。実装モデルCでは、コントローラは実行フォーマットであるOSEL-Xプログラムを受け取る。低機能なシステムでも実装可能な構成である。
穴明け加工を行う加工プログラムOSEL-F（図 3-12）とそこで使われている『貫通穴』加工特徴クラスライブラリ（図 3-13）をプログラミング言語Javaを用いてを実装した例を添付する。この例では理解を容易にするため一部簡略化してある。
public class Sample { // サンプルプログラム public static void main(String args[]) { // // 本来、この部分で位置・直径・深さの定義が行われる
// ThroughHole hole = new ThroughHole(pos, dia, depth); // 加工特徴『貫通穴』の定義 hole.centerdrilling(); // センタドリル加工 hole.drilling(); // ドリリング加工 } } |
public class ThroughHole extends Hole { // 加工特徴『貫通穴』クラスの定義 Vect3 position; // 属性：位置 double diameter; // 属性：直径
double depth; // 属性：深さ public ThroughHole(Vect3 pos, double dia, double d) { // 『貫通穴』のコンストラクタ position = pos; diameter = dia; depth = d;
} public void drilling() { // 加工法『ドリリング』メソッドの定義 Tool tool = toolfordrilling(diameter); // 穴明け用工具選定
machining_center.toolchange(tool);
// 工具交換 Vect3 initial = getinitial(); // 逃げ点 Vect3 reference = getreference(); // 加工開始点
Vect3 target = gettarget(); // 貫通穴の底の位置 machining_center.toolmove(initial); // 逃げ点へ移動 machining_center.toolmove(reference); // 加工開始点へ移動 machining_center.spindle_on(Osel.CW); // スピンドル・正転 machining_center.coolant_on(); // クーラント・オン machining_center.toolline(target); // 貫通穴の底へ直線移動 machining_center.toolmove(reference); // 加工開始点へ戻る machining_center.spindle_off(); // スピンドル・停止 machining_center.coolant_off(); // クーラント・オフ } } |