WO2006114880A1 - 情報連携ウィンドウシステム - Google Patents

Abstract

［課題］　アプリケーションソフトウエア間の情報連携を簡易・柔軟に実現する。 ［解決手段］　計算機画面上のウィンドウシステムにおいて、複数のプログラム間にＸＭＬその他のメタ言語で記述したデータ構造でやり取りするもので、必要な情報を通信する手段と当該情報に基づいて画面表示を行なう手段とから構成される。 例えば生産、製造管理用のコンピュータシステムではtag識別子に設備名、ポイント名などの論理名称をデータ構造に定義し、送り手プログラム上の任意ポインティング操作で、マウス等のドラッグ操作から引き続いて受け手プログラム領域へドロップ操作が行なわれることで、メタで記述したデータをプログラム間で通信する。その結果、受け手プログラムは自律的にスキーマ解釈をして目的とされた画面表示動作を実行する。

Description

明 細 書

情報連携ウィンドウシステム

技術分野

[0001] コンピュータヒューマンインタフェースにかかる技術に関するものであり、製造業にお ける生産管理、製造管理用のシステムその他のビジネスポータルとして多種多様の 情報表示画面に力かるウィンドウシステムに用いられる。

従来の技術

[0002] 昨今、コンピュータハードウェアおよびソフトウェアの進歩により、その端末表示画 面は高精細になり表示画素数も向上したために、一画面上に複数のウィンドウを構 成することが可能になり、そのウィンドウ毎に独立したプログラムが其々の機能を果せ るようになってきた。

しかし、それらプログラムはほぼ独立の設計形態をなしており、プログラム間の連携は 必ずしも取られておらず、連携を取ろうとするとそれぞれのプログラムの設計から見直 しが必要であるが如くあり、密に情報連携を図ることは相当困難なものであった。

[0003] 計算機内に存在する 2つの機能を実行するものをプログラム A、およびプログラム Bと よぶと、それらの間でドラッグ &ドロップなどの操作でデータの通信をする場合、通信 されるデータのフォーマットは固定であり、受け渡しされるデータの意味、データ型、 データ長、渡されるデータの配置順番など、 2つのプログラム Α,Β間で厳密に規定さ れた形式を取る必要があった。従来では確かに、画面のウィンドウの切り方、タイリン グ貼付およびオーバーラップ割り付け等について、多くの技術が考え出されており、 特許文献 1の例もその好適な例の一つであつたが、これは本発明の課題を解決する ものではない。

[0004] 図 1にウィンドウシステムのイメージ図を示す力 ここで、中央から右側の領域におい て、上側のプラントのグラフィック画面を実行するプログラム Α、下側のプロセス変数の トレンド (履歴グラフ）画面を実行するプログラム Βとすると、プログラム Αウィンドウ上に ある図形オブジェクトを選択し、そこに定義されて 、るプロセス変数の遷移を見た!/、こ とが多々ある。その操作としては、当該グラフィック 'オブジェクトをドラッグ、ドロップ操 作することが望まれる（図中点線で表示のオペレーションで示す)。そのためには、プ ログラム Aとプログラム Bの間で通信規約が定められ、それに則りプログラム Aからプロ グラム Bにその旨のデータを通信すれば実現できる。実際に、特許文献 2にあるような ソフトウェアインタフェース機能を利用して設計すれば、高度な機能を実現することは 可能である。

なお、マウス等のポインティングデバイス操作の用語として、「選択」はあるオブジェク ト領域でボタン押下げすること、「ドラッグ」はボタンを押下げたまま勾引すること、およ び「ドロップ」はある画面領域でボタンを離すこと、などを一般的に意味するものである

[0005] しかし、このようなやり方では仕様が固定的で、システムとしての拡張性からは問題が ある。例えば、情報の受け手となるプログラムがトレンド画面ではなぐ例えば別途の 設備用保全管理画面であったような場合、そこではもつと上位概念の設備名などが 望まれる場合があり、引き渡されるデータはプロセスのポイント名だけでは不充分で エリア名、装置名などのより上位論理名称が必要である。この場合、情報の送り手と なるプログラム力 相手である受け手プログラムごとに通信データを切り替えれば可 能であろうが、それでは送り手プログラムの負担が重い。他方、受け手プログラムにと つても、例えばトレンド画面はプロセスアラーム一覧画面などからも連携を望まれるも のであるが、その際、アラーム一覧画面プログラムなど力 通信されてくるデータには 、アラーム発生時刻などで記された時刻の近傍のトレンド表示が要求され、これを利 用するために時刻データまで受信できることが望まれる。このように、複数のプロダラ ムがランダムに送り手受け手の関係になるシステムでは、情報のやり取りを固定的な データ通信フォーマットに依存する形では対応が極めてむつ力しいものであった。 特許文献 1 :特開平 7— 44351号公報

特許文献 2：特開 2005— 11355公報

発明の開示

発明が解決しょうとする課題

[0006] アプリケーションソフトウェア間の情報連携を簡易'柔軟に実現することにある。

すなわち、プログラム同士が相手に依存しない形で、一定の基準に従ったデータ及 びプログラム構造を具備することだけで、相互に情報を連携して、情報総合的な画面 環境を提供する。

これにより、操作者にとって任意にプログラム間の連携機能を得ることができ、一方、 ソフトウェア作成者にとっては従来よりも比較的簡単に機能の実現を図れることを目 的とする。

課題を解決するための手段

[0007] 第一の特徴はデータ構造にある。本発明は画面を表示するプログラムに依存しない 形のデータ構造をシステムで定め、各プログラムがその仕様に応じて必要な箇所だ けデータを設定し解読してさらに表示実行できる手段を具備することに特徴がある。 そこでは、送り手プログラムは受け手プログラムを意識しな 、でデータを送信できるよ うにし、他方、受け手プログラムは送り手プログラムを意識しないでデータを受信し、 必要かつ共通な部分を解読した後に画面表示が実現できるように、基本的なデータ 構造のみを定めるものである。

そのため、メタ言語を用いる。メタ言語とは、言語を記述するための言語という意味で ある。 Webページを記述する HTMLや C言語などがある力 最近では HTMLを拡張し た XML (extensible Markup Language)が挙げられる。

メタ言語は基本構造のみ規定されたものであり、その範囲内で構造を自由に決める ことができる。言語ユーザが自由にできるのは、要素や属性を定めること、またその並 び順も任意である。

[0008] 第二の特徴はプログラム構造にある。本発明は、プログラムカゝら構成されるソフトゥェ ァ構造を規定し、それぞれのプログラムが簡単な仕組みを備えることだけで情報連携 したウィンドウシステムを築くことができるように、プログラム構造の基準を定めることを 特徴とする。

各プログラムは、少なくともポインティングデバイスからのオブジェクト（画面上の選択 可能な対象単位を意味する）の選択、ドラッグ、ドロップ操作に対応する処理を実行 するルーチンを備えることで、あるプログラムは送り手にも受け手にもなれる構造を有 する。

[0009] 以上の二点を発明の要旨として、 請求項 1記載の発明は、メタ言語で記述したデータ構造をドラッグ時記憶にストアし、 ドロップ時記憶をロードし、その解読の結果として画面描画に供するウィンドウシステ ム上の複数のプログラムにかかる物の発明を示す。

請求項 2記載の発明は、操作面から観たドラッグ、ドロップの各操作ステップ力も成り 立つウィンドウシステムにかかる方法の発明を示す。

請求項 3および 4は、各々請求項 1および 2に記載の発明において、メタ言語を XML に限定した発明を示す。

[0010] 請求項 5記載の発明は、請求項 1の発明において、前記記憶手段に一つの機能をさ らに追加した発明である。その附加機能をリフレクト機能とここでは呼ぶが、これは予 めすべてのプログラムの受け入れ属性を調べておくことで、ドラッグ開始時にドロップ 受け入れ可能なプログラムを探し、受け入れ可能なプログラムの表示枠を他のものと 区別するべく誇張表示するものを意味する。

発明の実施の形態

[0011] メタ言語で記述したデータ構造は平坦なテキスト文書で作成されることが基本とする だけで、どのメタ言語を用いても本発明に差はないため、以下は XMLの例のみを用 いて説明する。

XMLの要素は、く要素名〉で始まり、く/要素名〉で終わる一単位の情報である。要素 名はプログラムが自由に定めることができるものである。（また、内容が存在しない要 素は <要素名/ >で示す。）

一方、要素の名前を自分で考え、それをコンピュータに伝えるには、スキーマというも のを記述する場合もある。スキーマも一種の言語であり、それを記述するルールが存 在する。 XML用のスキーマにはいくつかの種類がある。主要なものとしては、 XML 1.0仕様書の一部として記述されている DTD (Document Type Definition)などがある。 通常は、このスキーマで定めたルールに従って要素や属性を記述した XML文書を作 成する。作成された XML文書は、スキーマと照合して、本当にルール通りに記述され TV、る力チェックすることができる。

ただし、 XMLのシンプルさを利用して敢えてスキーマを使わずに、受け手プログラム 力 ¾ML文書を逐一、要素の単位で解読することでも、本発明の実施には十分である ので、スキーマについてはこれ以上触れない。

(1)データ構造

(a)実施例 1

イメージ図 1の説明のために、同一レイアウトで示す図 2を例に取ると、一つの端末画 面 10上に、分割されたウィンドウで動作する送り手と受け手のプログラムが各々対応 する、グラフィック図形で描画された系統図画面 11とプロセス変数を表示できるトレン ド画面 12が在る場合、系統図画面 11の中の選択可能オブジェクト 21にあるグラフイツ ク部品（本例:蒸留塔）が持っているデータを XMLで記述し、以下のとおりとする。

疋我 1

<設備名>

<エリア名 > A < /エリア名 >

<装置名 >蒸留塔 A102 < /装置名 >

<監視ポイント >

くポイント名 > A102-FLOW.PVく/ポイント名 >

くポイント名 > A102-TEMP1.PVく/ポイント名 >

くポイント名 > A102-LEVEL.PVく/ポイント名 >

くポイント名 > A102-TEMP2.PVく/ポイント名 >

< /監視ポイント >

< /設備名 > 他方、当該トレンド画面 12が処理できるデータを XMLで定義すると、以下となる。

<エネルギー使用量トレンド >

<表示ペン >

<ペン番号/ >

<ポイント名/ >

<ペン色/ >

<上限値/ > <下限値/ >

<工業単位/ >

< /表示ペン >

< /エネルギー

[0013] ここで、系統図画面 11の中のオブジェクト 21 (蒸留塔）をマウス等のポインティングデ バイスで選択しドラッグし、そこに属するプロセス変数の履歴グラフを表示するようトレ ンド画面 12にドロップした場合 (その操作を矢印 31で示す)、定義 1で示された情報が データとして送信される。トレンド画面 12はこの情報のうち定義 2で定義された <ボイ ント名 >を共通の要素名定義として理解できるため、トレンド画面は 4つのポイント名 をトレンドの表示ペン 1から 4に自動的に割付し、現在時刻でのトレンドを表示するよう 動作する。

このように、く要素名〉く/要素名〉で挟んだところの論理名称が画面プログラム間で 通信される。系統図画面 11の送り手プログラムがオブジェクトに定義された XMLを送 信し、トレンド画面 12の受け手プログラムが受信した XMLから両者に共通の論理名 称のみを取り出し、その指定に従った表示を実行し、それ以外のデータは無視するこ とでよいわけである。

[0014] (b)実施例 2

別のプログラムとして保全管理画面 14があった場合、このプログラム 14で処理できる データ力 ¾MLで、

―定義 3―

<保全情報 >

<設備名>

<エリア名/ >

く装置名/〉

<保全履歴 >

<点検日時/ >

<点検者/ > <点検結果/ >

<点検記録/ >

< /保全履歴 >

く管理者名/〉

< /設備名 >

< /保全情報 > と定義される場合、前例と同じく系統図画面 11の中のオブジェ外 21 (蒸留塔)をマウ スで選択しドラッグし、次に保全管理画面 14にドロップした場合 (操作 32)、定義 1で 示された情報がデータとして受け渡しされるが、保全管理画面 14はこの情報の中の 定義 3にあるくエリア名 >と<装置名 >を共通定義として理解できるため、保全管理 画面 14はエリア名：A、装置名：蒸留塔 A102の現在までの保全状況履歴に関する表 示ができること〖こなる。

(c)実施例 3

さらに例えば、別のプログラムとしてアラーム一覧画面 13があったと仮定すると、この プログラムで管理するある一つのプロセス変数のアラーム事象を選択し、それをトレン ド画面 12に送信できるデータを XMLで定義する場合、その XMLは次のようになる。 ―定義 4―

<設備名>

<エリア名 > A < /エリア名 >

<装置名 >蒸留塔 A102 < /装置名 >

<監視ポイント >

くポイント名 > A102-FLOW.PVく/ポイント名 >

<時刻 > 2005.04.28 11 : 25 </時刻 >

<事象 > アラーム HI発生 く/事象 >

< /監視ポイント >

< /設備名 > この場合、アラーム一覧画面 13の中のポイント名にある行オブジェクト 22を選択しドラ ッグし、トレンド画面 12にドロップした場合 (操作 33)、定義 4で定義された情報がデー タとして送信される。ここでは監視ポイントに従属した時刻データによりアラーム発生 時刻などを送信できる。

他方、トレンド画面に力かるプログラムをバージョンアップし XML定義を下記のように 拡張する。

―定義 5―

<エネルギー使用量トレンド >

<表示ペン >

<ペン番号/ >

<ポイント名/ >

<時刻/ >

<ペン色/ >

<上限値/ >

<下限値/ >

<工業単位/ >

< /表示ペン >

< /エネルギー使用量トレンド > この情報の中でくポイント名 >およびく時刻 >を共通定義として理解できるので、新 プログラムのトレンド画面 12はポイント A102-FLOW.PVのアラーム発生時刻のデータ を受信して、表示のパラメータとして利用する。これを例えば時間軸の中心時刻に設 定することで、アラーム発生時刻前後近傍のトレンド画面を表示することができるよう になる。

(2)プログラム構造

次に、送り手プログラムおよび受け手プログラムの構造設計の例を示す。

図 3におけるプログラムフローと記憶情報の遷移図で説明する。プログラムの構造は

、送り手または受け手のプログラム双方に共通である。 なお、以降説明の簡略化のため、「メタ言語で定義するデータ構造」を「メタデータ」と 呼ぶことにする。

[0017] プログラムは、 ENTRY100で呼び出されると、初期起動された場合を除けば、大方の 起動方法は何らかの事象力ものイベント起動となる。定周期イベント、通常のキーボ ード、マウス等の操作イベント、その他のイベントを受け付ける分岐 110を経由する。 本発明に係る情報連携のためのイベントは 111, 112,113の少なくとも三つの判別分岐 でブランチすることで十分である（それ以外のイベントは Other方向へ流れるもので図 示しない)。

さて、送り手プログラムの動作フローでは、オブジェクトの選択時は分岐 111で下流の オブジェクト選択処理 121へ行きメタデータのリセットおよび準備などをする。ドラッグ 時は分岐 112でメタデータストア処理 122へ行き当該メタデータを記憶手段 200にスト ァする。

逆に、受け手プログラムの動作フローでは、ドロップ時は分岐 113でメタデータのロー ドおよび解読の処理 123へ行く。ここで適宜必要な処理を行ない、表示更新のメイン ルーチン 130へ描画などの実行を委ねる。解読手法は、前述の実施例 (a)ないし ( に あるように、記憶されているメタデータを自己のメタ言語定義での共通な定義要素に 当てはめて、自己の処理に用いることが主で、それは各プログラム毎に定まるもので ある。

[0018] メタデータ記憶手段 200は、クリップボードその他の単なるメモリから構成される力、或 いは別プログラムモジュールなどの能動部品で構成されるか自由である力 メタデー タ記憶部 210の構成が必須である。これは各プログラムからの Store/Loadを受け付け 、メタ言語で記述したデータ構造の保存/読出しに対処するものである。

また、送り手プログラムでのドラッグ操作時に、このドラッグに引き続くドロップ操作を 受付可能なプログラム群及びその画面領域がどこかを示す機能を提供するところの、 いわゆるリフレクト機能を実行するリフレクト処理部 220は、記憶手段 200にオプション として位置付けられる。

リフレクト処理部 220は、メタデータ記憶部 210への記憶処理が実行されたタイミングで 実行され (メモリ書き込みを検知してか或いはモジュール起動のタイミングを捉えるか などして）、ウィンドウシステム全体のデータベース（図外)を調べ、当該メタ言語定義 と共通する記述定義を有する受け手プログラムの領域の画面枠を、例えば赤枠表示 するなどして、ノ、イライト表示する。これにより、操作の効率が図れる。

[0019] 図 4に概略フローを示し説明する。リフレクト処理部 220はメタデータ記憶手段から呼 び出され、まず処理 221でメタデータ記憶部 210にストアされたば力りのメタデータを取 得する。次いで、システムにある受け手候補のプログラムの領域を得る（処理 222)。そ こで受け手プログラムのメタデータを取出す (処理 223)。ここで両方のメタデータの比 較を行 、共通の定義された要素名があるかどうかを照合する（処理 224)。それが有 ればその受け手プログラムの枠表示を、例えば赤表示にする（処理 225)。無ければ 何もしな 、でスキップする。ループのエンド処理 226でまだ受け手となりうるプログラム が有る力調べる。プログラムがあれば処理 227でプログラム領域ポインタを順次に進 めて処理 223から繰り返す。すべての受け手候補プログラムを調べ終えたら終了であ る（229)。

なお、受け手候補のプログラムの持つメタデータはその起動のタイミングで、通常ウイ ンドウシステムの管理領域に設定されるものであるので、その詳細は省略した。

[0020] 本発明の構成は本実施例に挙げられた構成に限定されない。例えば、ポインティン グデバイスはマウス以外も含む。図 3に示したプログラムまた記憶手段の実装方法は 任意で、一つの実行モジュールで構成されるカゝもしれないし、複数に分割されたマル チタスクで実行される力もしれな ヽ。

また、言語定義の例は XMLをベースに示した力 他のメタ言語として定義される言語 の仕様に依存して種種の変形は可能で、そのような変更があっても本発明の範囲に 属するものとする。

[0021] 以上のとおり、本発明によれば、共通的仕様のみシステムで定義し、メタ言語で記述 したデータ構造は各プログラムで独立的に定義かつ処理できるので、プログラムの負 担は軽ぐまたバージョンアップ、追加等に左右されない効果がある。

図面の簡単な説明

[0022] [図 1]ウィンドウシステムのイメージ図を示す。

[図 2]ウィンドウシステムのプログラム、対応する画面の配置および操作概要を示す。 [図 3]プログラムのフローおよびメタデータ記憶の遷移状態を示す。

[図 4]リフレクト処理部のフロー

Claims

請求の範囲

[1] 計算機画面上のウィンドウシステムにおいて、

ポインティングデバイスにより選択されかつドラッグされたオブジェクトに定義されたメ タ言語で記述したデータ構造をストアする手段を有する送り手プログラムと、 該データ構造を記憶する手段と、

ポインティングデバイスによりドロップされたときに記憶されているメタ言語で記述した データ構造をロードする手段および該データ構造を解読して画面表示を行なう手段 を有する受け手プログラムと、

力 構成されたウィンドウシステム。

[2] 計算機画面上のウィンドウシステムにおいて、

送り手プログラムのウィンドウ上でポインティングデバイスによりオブジェクトを選択しド ラッグするステップと、

ドラッグされたオブジェクトに定義されたメタ言語で記述したデータ構造を記憶するス テツプと、

受け手プログラムのウィンドウ上にポインティングデバイスをドロップするステップと、 受け手プログラムが記憶されているメタ言語で記述したデータ構造をロードし解読す るステップと、

受け手プログラムがウィンドウに描画するステップと、

力 なるウィンドウシステムの情報連携の方法。

[3] 請求項 1にお 、て、メタ言語を XMLとしたウィンドウシステム。

[4] 請求項 2において、メタ言語を XMLとしたウィンドウシステムの情報連携の方法。

[5] 請求項 1のウィンドウシステムにおいて、

前記記憶手段がリフレクト処理部を持ち、

リフレクト処理部は

予めすベてのプログラムの受け手属性を調べておくことでドロップ受け入れ可能なプ ログラムを探し、かつ受け入れ可能なプログラムの表示枠をハイライト表示すること を特徴とするウィンドウシステム。