JPH07267653A

JPH07267653A - ガラス製品等の形成システム

Info

Publication number: JPH07267653A
Application number: JP7027007A
Authority: JP
Inventors: David K Hwang; デーヴィッド・ケイ・ワン
Original assignee: Emhart Glass Machinery Investments Inc
Current assignee: Emhart Glass Machinery Investments Inc
Priority date: 1994-02-15
Filing date: 1995-02-15
Publication date: 1995-10-17
Also published as: EP0667693A2; EP0667693B1; EP0667693A3; DE69530947T2; DE69530947D1; US5475601A

Abstract

(57)【要約】【目的】遠隔のユーザ・ワークステーションからガラス
形成及び検査マシーンのデータベースへのアクセスを可
能にする。【構成】個別のガラス製品形成機械は、イベント駆動型
のデータベースを含む複数の生産ライン・コンソール
（ＰＬＣ）を有しており、該イベント駆動型データベー
スのための保管データが、制御コンソール（ＣＰＣ）に
記憶されている。ＵＮＩＸ、ＶＡＸ／ＶＭＳ、又はＮｏ
ｖｅｌｌのネットウェアを実行するワークステーション
から、イーサネットとネットワーク・ゲートウェイを介
して、ＱＮＸネットワークのデータベースにアクセスで
きる。また、コールドエンドＰＬＣは、ＡＲＣネット及
びＱＮＸネットの両方とインターフェースし、検査機械
からデータを集め、ネットワーク・ゲートウェイを介し
てワークステーションに転送する。検査接続ソフトウェ
アは、コールドエンドＰＬＣ上で実行される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ガラス製品等の形成シ
ステムに関し、特に、遠隔地のユーザのワークステーシ
ョンからガラス形成及び検査マシーンのデータベースへ
のアクセスを提供するネットワーク・ゲートウェイを備
えたガラス製品等の形成システムに関する。

【０００２】

【従来の技術】ガラス製品工場には多くのコンピュータ
制御されたマシーンがあり、これらのマシーンは共同し
てガラス製品形成プロセスを画定している。これらのマ
シーンには、たとえば、米国特許第４６４１２６９号に
開示されたＩＳ（個別セクション）機械すなわちマシー
ンが含まれ、その複数のセクションはそれぞれが独立の
コントローラによって制御されている。これらのコント
ローラのための保管データは、制御室のコンソールに集
中して記憶されている。形成されたビン等のガラス製品
は、それぞれが自己の独立のコントローラを有する１つ
又は複数のディスクリート・マシーンを有する検査装置
によって検査される。

【０００３】

【発明が解決しようとする課題】本出願の被譲渡人が販
売するこのようなＩＳマシーンや検査装置は、非標準的
なＱＮＸプラットフォーム（クアントゥム・ソフトウェ
ア・システムズ社が売り出した、マイクロコンピュータ
・システムのためのマルチタスク・マルチユーザ・リア
ルタイムのオペレーティング・システム）の基で動作す
る。この非標準的なプラットフォームは、標準的なイー
サネット（ＴＣＰ／ＩＰ）のネットワーク環境における
ＵＮＩＸやＶＡＸ／ＶＭＳやノベル社のネットウェアな
どの標準的なプラットフォーム上で動作している外部の
コンピュータからはアクセスできず、従って、ガラス製
品工場におけるユーザ・ワークステーションが、これら
のＩＳマシーンや検査装置のデータベースにアクセスで
きないという問題点があった。したがって、本発明の目
的は、遠隔地のユーザ・ワークステーションからこれら
のガラス製品形成及び検査マシーンのデータベースへの
アクセスを提供するネットワーク・ゲートウェイを与え
ることができるようにすることである。

【０００４】

【発明の概要】本発明においては、上記した目的を、ネ
ットワーク環境内に分散しているデータベースの地理的
な位置を隠してユーザ・ワークステーションからアクセ
スされた際にはローカルであるかのように見せる分散型
のコンピュータ環境によって達成している。ゲートウェ
イは、機械（マシーン）のデータベースと遠隔のワーク
ステーションとの間の２方向データ通信を提供する。遠
隔のユーザがこのゲートウェイを介して必要とするデー
タを受信することができるだけでなく、データベースが
何らかの自発的変更（ｕｎｓｏｌｉｃｉｔｅｄｃｈａ
ｎｇｅｓ）を有する場合には、このゲートウェイは、そ
の遠隔のユーザに直ちにそれを通信することができるよ
うに構成されている。本発明のこれ以外の目的及び効果
は、本明細書の以下の記述と特許法の命じるところに従
い本発明の原理を組み入れた好適実施例を図解する添付
の図面とから明らかになろう。

【０００５】

【実施例】図１には、ネットワーク・ゲートウェイと、
ローカル・コンピュータと、外部のアプリケーション装
置との関係が示されている。ガラス製品を形成するＩＳ
（個別セクション）機械は、複数の生産ライン・コンソ
ールを有しており、各コンソールは、当該ＩＳ機械への
すべての管理制御情報をサポートするイベント駆動型の
データベースを含んでいる。複数の機械のこれらすべて
のイベント駆動型データベースのための保管（ａｒｃｈ
ｉｖｅ）データは、制御コンソールのハード・ドライブ
（ディスク）データベースに集中的に記憶されている。
また、ＱＮＸネットワーク上で利用可能なのは、ＡＲＣ
ネットワークを介して検査装置データベースにアクセス
する検査接続ソフトウェアを実行するコールドエンド生
産コンソールである。本発明の最終目標は、ユーザのア
プリケーションが、標準的なイーサネットＴＣＰ／ＩＰ
ネットワーク環境においてＵＮＩＸ、ＶＡＸ／ＶＭＳ、
又はＮｏｖｅｌｌ社のネットウェアのいずれかを走らせ
ているワークステーションから、ネットワーク・ゲート
ウェイを介してこれらのＱＮＸ型データベースにアクセ
スすることを可能にすることである。

【０００６】ネットワーク・ゲートウェイは、ＩＢＭ−
ＰＣコンパチブルなコンピュータであり、以下のハード
ウェア及びソフトウェア要素から成る。すなわち、・８ＭＢのメモリを有する４８６／３３ＭＨｚのＩＢＭ
−ＰＣ（ハード・ドライブなし）・Ｖ２．１５Ｆ又はそれ以降のＱＮＸオペレーティング
・システム・ＱＮＸネット・ボード・バークレー・ソケット・ライブラリ及びＣＭＣ−６４
０イーサネット・インターフェース・カードを含むＱＮ
Ｘデバイス・ドライバのためのＦａｓｔｅｃｈ社のＴＣ
Ｐ／ＩＰ接続・データベースへのアクセスのためのゲートウェイ・サ
ーバ・ソフトウェアこれによって、ワークステーションは、イーサネットを
介して、ＱＮＸネットワーク上の要求されたデータベー
ス情報を収集することが可能になる。ただし、ゲートウ
ェイ・トラフィック（伝送路）は、双方向性であり、す
なわち、ネットワーク・ゲートウェイもワークステーシ
ョンへのデータ転送を開始することができる。実際に
は、開始されたイベントは、そのワークステーションに
よって定義され要求されたデータベースのアイテムだけ
に限定される。

【０００７】ネットワーク・ゲートウェイのソフトウェ
アは、１つのユーザ（クライアント）・ワークステーシ
ョン内の複数の処理又は複数のユーザ・ワークステーシ
ョンの間の１つ又は複数の処理の中に存在する複数のユ
ーザ（クライアント）・ポートをサポートする。ネット
ワーク・ゲートウェイ・ソフトウェア自体は、１つのＣ
ＰＵ又はそれぞれが別の名前を有する複数のＰＣの中に
も存在することができる。コールドエンド生産ライン・
コンソール（ＰＬＣ）は、ＡＲＣネットワーク（ＡＲＣ
ネット）及びＱＮＸネットワーク（ＱＮＸネット）の両
方とインターフェースするＩＢＭ−ＰＣコンパチブル・
コンピュータである。ＡＲＣネットワークに対するＡＲ
Ｃネット・インターフェースは、すべての検査装置から
データを集め、他方で、ＱＮＸネットワークは、コール
ドエンドＰＬＣを、ＱＮＸネットワーク上のノードにす
る。検査接続ソフトウェアは、コールドエンドＰＬＣ上
でＱＮＸの下に実行される。

【０００８】このシステムを構築する別の方法は、単に
ＡＲＣネット・カードをゲートウェイＰＣに挿入し、か
つ検査接続及びゲートウェイ・サービス・ソフトウェア
を同じＰＣで実行、すなわち走らせることによって、コ
ールドエンドＰＬＣとネットワーク・ゲートウェイ・ハ
ードウェアとを１つのＰＣボックス内に組み合わせるこ
とである。ある限界までは、このアプローチは、コスト
を減少させ、効率を向上させるという両方の点で効果を
有する。しかし、システムに２つ以上のコールドエンド
検査機械が付加された場合には、検査接続を走らせる別
個のＰＣを有するという通常の構成では、ユーザに、増
加する要求に答えるだけの付加的なＰＣを加えるフレキ
シビリティを与えることになる。

【０００９】ゲートウェイ・ソフトウェアは、クライア
ントすなわちユーザ側（ワークステーション）とサーバ
側（ゲートウェイ）の部分に分けられる。クライアント
のソフトウェアは、Ｃ言語によるソース・コード・フォ
ーマットのＡＰＩライブラリ・ファイルの組を含み、そ
れにより、ユーザは、コンパイルすなわち編集を行って
それを自分自身のアプリケーション・コード及びＴＣＰ
／ＩＰソケット・ライブラリにリンクさせることができ
る。ＱＮＸの下でゲートウェイ上を走っているソフトウ
エアは、クライアントからデータベースへのデータ取得
要求と、データベースからユーザ（クライアント）・ア
プリケーションへのデータベース変更イベントとを与え
る、サーバ・ソフトウェアである。サーバ・ソフトウェ
アは、複数のセッションに加えて複数のクライアント接
続をサポートする。

【００１０】ＱＮＸアプリケーションの開発者に対する
ものとして、本出願の被譲渡人は、イベント駆動型デー
タベース（ＥＤＤＢ）のツール・キットを公知にしてお
り、これは、ＱＮＸ環境におけるＥＤＤＢデータベース
・アクセスのための標準的（ネイティブ）なＥＤＤＢラ
イブラリＡＰＩ（図２）を含んでいる。ＱＮＸ環境にお
いては、アプリケーション・タスクは、ローカルなＥＤ
ＤＢライブラリからＥＤＤＢ・ＡＰＩコールを生じて、
ローカル又は遠隔地のＥＤＤＢデータベースをオープン
（位置指定）にし、その後にそこからのデータにアクセ
スすることができる。このようなネットワーク本来の環
境においては、ユーザは、データベースの位置を知って
いる必要はない。ＥＤＤＢデータベースの地理的な位置
は、ＱＮＸネットワークの設備によって明確に指定され
る。

【００１１】ゲートウェイは、ＥＤＤＢ／ＩＣ（検査接
続）のライブラリＡＰＩをネットワークを横断して延長
しており、該ＥＤＤＢ／ＩＣのプログラミング・インタ
ーフェースを用いて、開発者が、ユーザ・アプリケーシ
ョン・プログラムをＵＮＩＸ、ＶＡＸ／ＶＭＳ／Ｎｏｖ
ｅｌｌワークステーション上で書くことができるように
する。このために、クライアントのノード上のＥＤＤＢ
／ＩＣライブラリは、その下にソフトウェアの層を付加
することによって、ユーザすなわちクライアントとゲー
トウェイとの間のパケット転送をサポートするように強
化されなければならない。また、ソフトウェアの対応す
る組が、ゲートウェイのノード上に存在してその要求に
応じなければならない。図３は、このアプローチによる
分散型のソフトウェア構造を示している。すなわち、ソ
フトウェアの一方の部分であるゲートウェイ・ライブラ
リがユーザのプラットフォーム上に分散しており、他方
の部分であるゲートウェイ・サービスはゲートウェイ上
に存在し、その両者共が、バークレー・ソケット（Ｂｅ
ｒｋｅｌｅｙＳｏｃｋｅｔｓ）・ライブラリ（ＢＳＤ
４．３）を用いて、低レベルのＴＣＰソケット・セット
アップと、セッション接続と、パケット転送タスクとを
実行する。

【００１２】ＥＤＤＢ／ＩＣコールを行うことによっ
て、ＵＮＩＸ／ＶＭＳ／Ｎｏｖｅｌｌアプリケーション
・プログラムは、遠隔地のデータベースにそれらがあた
かもローカルに利用可能であるかのようにアクセスする
ことができる。ユーザ・アプリケーションは、ＥＤＤＢ
／ＩＣ・ＡＰＩコールを行うが、ゲートウェイ・ライブ
ラリは、そのＱＮＸ環境に対して一意的である「ネーム
位置指定（ｎａｍｅｌｏｃａｔｅ）」、「送出（ｓｅ
ｎｄ）」、「ｖｃリリース（ｒｅｌｅａｓｅ）」のシス
テム・コールを、ＴＣＰ／ＩＰコマンド・パケットに変
換し、そのパケットをゲートウェイに送る。ＱＮＸの下
で走っているゲートウェイ・サービスは、次に、実際の
「ネーム位置指定」、「送出」、「ｖｃリリース」コー
ルを提供してＥＤＤＢデータベースの情報にアクセス
し、そのデータ及び状態を、同じ対のネットワーク・ソ
ケット上をユーザ（クライアント）・アプリケーション
・プログラムに送り返す。すべてのパケット転送メカニ
ズムは開発者には自明であり、あたかも、データがその
ユーザに対して該ユーザの機械上でローカルに利用可能
であるかのようであることが明らかであろう。ゲートウ
ェイ・ライブラリは、ＡＮＳＩ“Ｃ”で書かれており、
開発者のターゲット・システムに利用可能にするために
は最小のポーティング（ｐｏｒｔｉｎｇ）・ワークを要
求する。ゲートウェイ・サービスでは変更は全く不要で
あり、ゲートウェイ・サービスは、実行可能な形式でだ
け利用可能であり、ゲートウェイＰＣが動いている限り
ゲートウェイ・メモリに関連して永久に動作する。ソフ
トウェアの観点からすると、ゲートウェイは、分散環境
における、非標準的なＴＣＰ／ＩＰプロトコル・アプリ
ケーションである。

【００１３】ゲートウェイの構成においては、ユーザ
は、通信要求を開始しかつサーバからの応答を待つ、第
３の部分を構成するアプリケーションである。ユーザ
は、ユーザ・機械の中に“生きている”すなわち存在す
るものである。これと比較すると、サーバは、ゲートウ
ェイの中に（永久に）存在してユーザから来る通信要求
を待つものである。サーバは、ユーザからの要求を受信
した際には、必要なデータベース・アクセスを行い、そ
の結果をユーザに返送する。本質的に、サーバは、ゲー
トウェイの中に存在して（生きて）おり、普遍的なデー
タベース・エンジンのように振る舞う。ゲートウェイ
は、データ・アイテムがユーザ（クライアント）・アプ
リケーションによって結合されている限り、データベー
スからのダイナミックなイベント駆動データ更新をユー
ザに提供する。ユーザ・プログラムは、したがって、選
択されたデータベース・アイテムにおいて実際の変更が
あった場合のみ、（最初にＥＤＤＢ／ＩＣデータベース
によって告知された）サーバによって告知される。この
付加的な要求によって、ゲートウェイ及びユーザ（クラ
イアント）・ノード上の１対の専用のソケットがコール
すなわち呼び出され、（ゲートウェイからユーザへ接続
する）相互通信ができる。ＴＣＰトランスポート・プロ
トコルが用いられる。ゲートウェイは、複数のユーザ・
ノードをＥＤＤＢデータベースに接続するサービスを提
供する。各接続は、セッションを通じてユーザと共に確
立されるそれ自身の一意的なソケットを有する。セッシ
ョンは、ユーザによってなされる、要求情報へのゲート
ウェイの接続として定義される。セッションが終了する
と、ソケットがそれ以降の使用のためにシステムに解放
される。利用可能なソケットの数は、ＴＣＰ／ＱＮＸデ
バイス・ドライバが提供できるものによって、制限され
るだけである。

【００１４】図４には、トップレベルのゲートウェイ・
ソフトウェアを示しており、該ソフトウェアは、生産ラ
イン・コンソール（ＰＬＣ）とユーザのＵＮＩＸ／ＶＭ
Ｘ／Ｎｏｖｅｌｌワークステーションとの間の接続をサ
ポートするものである。ユーザ・アプリケーションは、
ＥＤＤＢ／ＩＣ・ＡＰＩコール（呼び出し）を行い、Ｅ
ＤＤＢ／ＩＣデータベースを位置付け（位置指定）して
それを読み出す。ファンクション・コールは、データベ
ース扱いとユーザ・アプリケーションに対するアイテム
内容と共に返送される。ゲートウェイは、また、非同期
イベント更新のためのユーザのタスクへの信号としてＰ
ＬＣ又は検査接続から到来したＥＤＤＢ／ＩＣ例外（ｅ
ｘｃｅｐｔｉｏｎｓ）をサポートする。たとえば、これ
らの外部イベントは、イベント・アングル変更パケット
又は検査結果パケットである。このようにして、ゲート
ウェイ構成には、以下のような２つの主なデータの流れ
がある。（１）ＵＮＩＸ／ＶＭＳ／Ｎｏｖｅｌｌワークステーシ
ョンからＰＬＣへのデータ取得（２）反対にＰＬＣからＵＮＩＸ／ＶＭＳ／Ｎｏｖｅｌ
ｌワークステーションへの二次的なイベント更新ゲートウェイは、すべての詳細な接続と、２つの異なる
オペレーティング・システム（ＵＮＩＸ／ＶＭＳ／Ｎｏ
ｖｅｌｌ及びＱＮＸ）とネットワーク環境（イーサネッ
ト上のＴＣＰ／ＩＰと、ＡＲＣネット上のＱＮＸネッ
ト）との間のデータ・パケット転送とを扱う。

【００１５】ゲートウェイ構成は、図５に示されている
ように２つの部分で構成される。ゲートウェイ・ライブ
ラリ（ユーザ・アプリケーション・ライブラリ）は、ユ
ーザ・ノード上で生きている（使用可能な）部分であ
る。該ゲートウェイ・ライブラリは、ユーザ・アプリケ
ーションとインターフェースして、イーサネット・ネッ
トワーク上のＴＣＰパケットを介して、ゲートウェイに
おけるゲートウェイ・サービス（サーバ・アプリケーシ
ョン・ソフトウェア）と会話する。ゲートウェイ・サー
ビスは、ユーザ・アプリケーション・タスクの組で構成
され、ＱＮＸ環境において、ＥＤＤＢデータベースを位
置指定してアクセスする。サーバ・アプリケーション
は、この結果をＴＣＰパケットを介してクライアント・
アプリケーションに返送する。この結果は、データベー
ス問い合わせ（ｉｎｑｕｉｒｙ）又はＥＤＤＢ例外に依
存するものである。ゲートウェイ・ライブラリは、ユー
ザ・アプリケーションのプログラマがデータベースにア
クセスするためにリンクさせる、ソフトウェアの層であ
る。図６は、アプリケーションによって用いられるゲー
トウェイ・ライブラリの種々のモジュールの間のデータ
の流れを示している。

【００１６】ユーザ・インターフェースのための関数
は、以下のモジュールに含まれている。すなわち、ネー
ム位置指定すなわち位置付け（ＮａｍｅＬｏｃａｔ
ｅ）、送出（Ｓｅｎｄ）、及びイベント準備（Ｐｒｅｐ
ａｒｅＦｏｒＥｖｅｎｔ）である。ユーザ（クライアン
ト）・コール・モジュールは、バークレー・ソケット・
ライブラリにおける「送出」及び「受信」コールを行う
ことによって、ＴＣＰパケット転送を扱う。イベント準
備の機能（ファンクション）は、ユーザのノード上での
データ転送のためのソケットを初期化し、別個のイベン
ト・キュー・ソケットを確立することによって、ユーザ
・イベント信号扱いメカニズムをセットアップする。ユ
ーザがゲートウェイ・サービスとの接続を行った後で、
ゲートウェイ・サービスは、他の必要な仕事を実行する
と共に、それ自身のイベント・キュー・ソケットをセッ
トアップし、そのユーザのイベント・キュー・ソケット
への接続を行うことを試みる。この接続が確立された場
合には、ＥＤＤＢ／ＩＣにおける付加されたデータベー
ス・アイテム変更は、イベント・キュー・ソケットを介
してユーザに送り戻される。メッセージはローカルにパ
ッケージされ、ユーザからゲートウェイ・サーバに送ら
れ、そこで、パケットは、ＱＮＸ「送出」メッセージの
通過が行われる前に、パックが解かれデコードされる。
受信されたパケットは、次に、ＥＤＤＢ／ＩＣライブラ
リにおけるユーザ（クライアント）・アプリケーション
・タスク・バッファ空間に返送され、最終的には、ユー
ザ・アプリケーションに転送される。

【００１７】図７は、ゲートウェイ・サービスとその外
部のリソース（資源）との間のデータ・インターフェー
スに加えて、ゲートウェイ・サービス内のタスク間通信
を表している。ゲートウェイ・サーバは、普遍的でセッ
ション適用型のデータベース・サーバとして機能し、そ
の構成は、以下の協調タスク（ｃｏｏｒｄｉｎａｔｉｎ
ｇｔａｓｋｓ）を備えている。・「サーバ」タスクのメイン・プログラムは、ファイア
・アップされたときに実行を開始し、永遠にランしつづ
ける。該プログラムにより、プロトコル・ポートを取得
し、プログラムをポート・マッパ（ｍａｐｐｅｒ）に登
録し、次に、データ・ソケットからのＴＣＰ／ＩＰメッ
セージ・パケットとして到来するユーザ要求を受信する
ために待機（リッスン）する。複数のユーザが一度に１
６のＰＬＣまでアクセスできるようにしたことにより、
メイン・プログラムは、チャネル上のデータが子（ｃｈ
ｉｌｄ）処理によって同時に処理される間に、より多く
の入力接続を待たなければならない。作られる（ｓｐａ
ｗｎｅｄｏｆｆ）子処理の組は、「コムズ（ｃｏｍ
ｓ）」と「データ」とを含む。各セッション接続に１つ
である。これらのタスクは、ＱＮＸローカル・ネーム登
録を介して相互に通信する。

【００１８】・通信タスクの「コムズ」が、最初にそれ
自身を、ローカルなＱＮＸクリアリングハウスに結び付
ける。次に、永久実行（ドゥー・フォーエバー）ループ
内に留まり、ブロッキング・モードの任意の入力データ
・パケットを受信する。パケットを受信した後で、コム
ズは、最初に動作コードをチェックしてそれがポート・
ナンバー（番号）パケットであるかどうかを見る。この
ポート・ナンバー・パケットは、ユーザによってセッシ
ョンの確立処理の初期に送られて、ゲートウェイ・サー
ビスに、データベース例外イベントにどのポートを送出
すべきかを伝達する。このポート番号パケットによっ
て、コムズがラッシュ・タスクを作ることになり、イベ
ント・キュー・ソケット上のユーザに接続する。他のサ
ポートされている動作コード（ｏｐ−ｃｏｄｅ）は、ネ
ーム位置指定、送出、ｖｃリリースである。これらのＱ
ＮＸ動作の間の相違は、返答パケット・サイズにある。
コムズ・タスクは、次に、パケットを、ＱＮＸメッセー
ジ転送を介して、データ・タスクに送る。ＱＮＸ送出コ
ールはメッセージを受信することもするので、送信コー
ルが戻るとすぐに、プログラムは、返答ＴＣＰパケット
を、ＴＣＰ／ＩＰネットワークを介してユーザに返送す
る。

【００１９】・データベース・リンク・タスクの「デー
タ」が、それ自身をローカルにその名前の下にあるクリ
アリングハウスと結び付けることによって開始する。次
に、受信ブロック・ループに次の時まで永久に留まる。
すなわち、コムズ・タスクが、ユーザ・アプリケーショ
ンからデータ・パケットを受信した後でそれにメッセー
ジを送るまでか、又は、データベースに結び付いたアイ
テムに信号を与えるＥＤＤＢ／ＩＣ例外が変更されるま
でである。タスクは、コムズがメッセージ上を送られた
ために生じた場合には、動作コード（ネーム位置指定、
送出、又はｖｃリリース）を最初にデコードし、それに
したがってＱＮＸ動作を実行する。次にタスクは、送り
手のコムズ・タスクにその結果を返答する。タスクは、
ＥＤＤＢ／ＩＣデータベース例外信号を受信する場合に
は、ＱＮＸメッセージを直ちにラッシュ・タスクに送
り、イベント・ソースを告知する。

【００２０】・イベント告知タスクの「ラッシュ」は、
コムズ・タスクによって作られ、最初にそれ自身をロー
カルにクリアリングハウスに結び付ける。次にそれは、
例外イベント・キュー・ソケットをサーバにおいてイベ
ント告知のためにセットアップする。イベント告知にお
いては、ゲートウェイ・サーバは、実際には、ユーザの
ように振る舞い、それによって、それが作り出したソケ
ットは接続をコールして、ユーザ（クライアント）・モ
ード上のイベント・キュー・ソケットとの接続をしなけ
ればならない。次にタスクは、永久動作（ドゥー・フォ
ーエバー）ループに入り、データ・タスクからデータを
任意の例外イベントのために受信する。例外を受信した
際には、次の２つのことを直ちに行う。すなわち、１．返答メッセージを、単にそのブロックを解く（ｕｎ
ｂｌｏｃｋｉｎｇ）目的でデータ・タスクに送り戻す。２．イベント告知パケットを、イベント・キュー・ソケ
ットを介して、処理のためにユーザ・ノードに送る。

【００２１】図８は、ユーザ（クライアント）接続要求
に対する「リスニング・モード」において、ソケットを
最初にセットアップするメイン・プログラムのためのプ
ログラム構造図を示している。一旦タスクが永久動作ル
ープ内に入り多くの接続を受け入れる場合には、到来す
る各接続は、結果的に、異なるソケット識別（ｉｄ）と
子タスク拡張数を生じることになる。これらの２つのパ
ラメータは、次に、特定のセッションを与えるコムズ及
びデータの子タスクの組を作るのに用いられる。複数の
セッションがゲートウェイ内にオープン状態に開かれ得
るので、コムズ又はデータの複数のコピーが同時にタス
ク・テーブル上に存在することになる。タスク間の通信
は、したがって、タスク名ではなくタスク登録名に従っ
て扱われなければならない。

【００２２】図９は、別個のタスクとして構成された、
ユーザからのパケットを処理し同じオープン状態のチャ
ネル上で返答するタスクの「コムズ」のためのプログラ
ム構造図を示している。登録タスク・ネーム・セクショ
ンは、ＱＮＸシステム・コールの「ネーム付け」から成
り、それ自身をローカルなクリアリングハウスに結び付
けることによってデータ・タスクが通信できるようにす
る。準備段階の間は、コムズもまた、「ネーム位置付け
（ネーム位置指定）」をコールすることによって対応す
る「データ」タスク名を位置指定しようとする。タスク
名登録と位置指定とは、ソケットｉｄと子タスク数とか
ら成る同じコマンド・ライン・パラメータを用いること
によってなされる。受信パケットは、ソケット接続が存
在するユーザ・アプリケーションによって中断されるま
で永久に継続すると考えられ、その場合には、コムズ・
タスクはメッセージをデータ・タスクに送ってタスク自
体が終了する前に存在させなければならない。これは、
セッションが終了する場合にシステム内に残る「ゾン
ビ」処理を避けるために必要とされる。パケットを受信
した後では、コムズ・タスクは、最初に動作コードをデ
コードし、それが「ネーム位置付け（ネーム位置指
定）」、「送出」、又は「ｖｃ受信」であるかどうかを
判断する。送出メッセージと返答パケットのサイズは異
なっており、それに応じて識別特定されなければならな
い。プログラムは、次に、メッセージを処理のためにデ
ータ・タスクに与え、その結果を取得し、それをユーザ
・アプリケーションにネットワーク上を返却する。

【００２３】図１０は、コムズ・タスクからのメッセー
ジ又はデータベース（ＥＤＤＢ又はＣＩ）例外のどちら
かを処理するデータ・タスクのためのプログラム構造図
である。（例外ハンドラをセットアップするための）タ
スク登録及びイベント準備の後に、データベース・イベ
ントが結び付けられたデータベース・アイテムから入力
されるか、またはコムズ・タスクからのメッセージを取
得するかまで、イベント取得ルーチンが受信をブロック
すなわち阻止される。データベース・イベントを処理す
るために、データは、名前によってラッシュ・タスクを
位置指定し、例外を位置指定されたものに送ろうとす
る。コムズから来たメッセージを処理するには、できる
可能性がある。データは、最初に、コマンド・メッセー
ジをデコードし、次に、それにしたがってＱＮＸコール
を実行する。この動作の結果は返答メッセージとしてコ
ムズに送り返され、そのブロック（阻止）を解除する。
コムズは、返答メッセージを取得するとすぐに、ユーザ
・アプリケーションに戻るためにパケットを発生する。
図１１に示すようなラッシュ・タスクの場合には、デー
タからの例外メッセージの受信を待ち、各メッセージを
ユーザ・アプリケーションにイベント・キュー・ソケッ
ト上を送り、データに返答してその送り手をブロック解
除する。

【図面の簡単な説明】

【図１】本発明によるネットワーク・ゲートウェイとロ
ーカル・コンピュータと外部のアプリケーション環境と
の間の関係を示したシステム・アーキテクチャを示すブ
ロック図である。

【図２】ＱＮＸ環境におけるイベント駆動型データベー
スのＡＰＩ構成を示すブロック図である。

【図３】ネットワーク・ゲートウェイの分散型ソフトウ
ェア構成を示すブロック図である。

【図４】生産ライン・コンソールとホストとの間の接続
をサポートするネットワーク・ゲートウェイ・ソフトウ
ェアを示したトップレベル・コンテントのデータ・フロ
ー図である。

【図５】ネットワーク・ゲートウェイに対する次のレベ
ルのデータ・フロー図である。

【図６】図５に示したゲートウェイ・ライブラリの種々
のモジュール間のデータの流れを示すデータ・フロー図
である。

【図７】図５に示したゲートウェイ・サービスとそのリ
ソースとの間の、タスク間通信及びデータ・インターフ
ェースを示すデータ・フロー図である。

【図８】ゲートウェイ・サービス関するメイン・プログ
ラム構造を示すブロック図である。

【図９】ゲートウェイ通信タスク構造を示すブロック図
である。

【図１０】ゲートウェイ・タスク・データ構造を示すブ
ロック図である。

【図１１】ゲートウェイ・タスク・ラッシュ構造を示す
ブロック図である。

Claims

【特許請求の範囲】

【請求項１】ガラス製品等の形成システム（ａ）第１のプロトコルの上で動作する少なくとも１つ
のイベント駆動型データベースと、（ｂ）第２のプロトコルの上で動作する少なくとも１つ
のワークステーションであって、前記第１のプロトコルにおけるＡＰＩコールのライブラ
リと、前記第２のプロトコルにおけるコール・パケットを送る
ソケット・ライブラリと、前記第１のプロトコルにおけるＡＰＩコールを前記第２
のプロトコルにおけるコール・パケットに翻訳するゲー
トウェイ・ライブラリと、を含むワークステーションと
を含むワークステーションと、（ｃ）ネットワーク・ゲートウェイであって、前記第２のプロトコルにおけるコール・パケットを受け
取るソケット・ライブラリと、前記第２のプロトコルにおける前記ネットワーク・ゲー
トウェイのソケット・ライブラリを、前記第１のプロト
コルにおけるＡＰＩコールに翻訳し、前記翻訳コールを
前記イベント駆動型データベースに搬送するネットワー
ク・ゲートウェイとを含むネットワーク・ゲートウェイ
とを備えていることを特徴とするガラス製品等の形成シ
ステム。
【請求項２】請求項１記載のガラス製品等の形成シス
テムにおいて、前記ゲートウェイ・サービスはさらに、前記イベント駆
動型データベースから受信された前記第１のプロトコル
におけるデータを、前記第２のプロトコルにおけるデー
タに翻訳する手段を含み、前記ネットワーク・ゲートウェイはさらに、前記第２の
プロトコルにおけるデータのパケットを前記ワークステ
ーションのソケット・ライブラリに搬送する手段を含
み、前記ゲートウェイ・ライブラリはさらに、前記第２のプ
ロトコルにおける前記搬送されたデータを前記第１のプ
ロトコルを有するデータに翻訳する手段を含んでいるこ
とを特徴とするガラス製品等の形成システム。