JP2010152582A - 情報制御システムおよび制御ソフトウェアの作成方法 - Google Patents

Abstract

【課題】制御対象の機器の状態を規定する条件を明確に定義でき実行できる情報制御システムを提供する。
【解決手段】ＳＩ管理サーバ１００は、オブジェクトの構造および状態のデータ項目を格納するオブジェクト定義表と、オブジェクトを監視・制御する制御要素であるアクタとして、オブジェクトのオブジェクト名、オブジェクトの監視項目、監視項目の設定値、および設定値の監視条件を関連付けるアクタ定義表とを記憶する記憶部２０と、制御対象システムの制御モデルを作成するモデル作成部１３０と、を有し、モデル作成部は、開発ＰＣ１００Ａからアクタの作成要求を受理すると、アクタ定義表を、オブジェクトの監視項目を行に、設定値および監視条件を列として表形式で、クライアント端末の表示部に表示する。
【選択図】図１

Description

本発明は、制御対象の機器の状態を規定する条件を明確に定義でき実行できる情報制御システムおよび制御ソフトウェアの作成方法に関する。

情報制御システムのプログラム開発モデルとしてウォーターフォール・モデルがある。ウォーターフォール・モデルは、プロジェクト全体をいくつかの工程に分割し、各工程での成果物（仕様書や設計書などのドキュメント）を明確に定義し、その成果物に基づいて後工程の作業を順次行っていく。ウォーターフォール・モデルは、「仕様書による定義」という原則を適用することを目的としたドキュメント駆動型の開発プロセスといえる。

例えば、電力システム、列車運行管理システム、上下水管理システムなどの情報制御システムでは、システムの発注・受注時に、発注者と受注者との間で、「システム仕様書」が作成される。このシステム仕様書は、システムを構成する機器（設備）の状態を規定するためのドキュメントである。また、システム仕様書は、発注者、受注者、設計者、及び製作者（コーディング）間の重要なインタフェース文書となる。そのため、システム仕様書は、機器の状態に関する様々な説明が日本語などの文章によって記載される。

また、予約語ごとの構文規則および実行規則を対応付けた予約語ファイルを定義し、業務処理定義ファイルに、予約語を用いたスクリプトを用いて、実行プログラムの処理方法が開示されている（例えば、特許文献１参照）。
特開２００５−１４９３３９号公報

しかしながら、特許文献１の技術では、業務処理定義を簡易なスクリプトで記載されているが、業務処理のシステム仕様書内容について、スクリプトを作成する問題は残る。

システム仕様書は、基本的に説明が曖昧に記載されている場合や記載漏れがある場合がある。例えば、日本語は、一つの文章で複数の解釈がなされることがある。また、例えば、システム仕様書では、日本語の文章によって、「ＸＸの状態でなかった場合ＺＺとする」と記載されていることが多い。

設計者や製作者は、「ＸＸの状態」が不成立になる条件が明確でなければ、制御プログラムを製作できない。そのため、システム仕様書は、不成立になる条件が記載されていることが好ましい。しかしながら、システム仕様書は、「ＸＸの状態」が成立する場合の説明のみが日本語の文章で記載されていて、「ＸＸの状態」が不成立となる場合の説明については記載されていないことが多い。したがって、この点でも、システム仕様書は、説明が曖昧に記載されている場合がある。

また、機器の状態を規定する各条件は成立条件及び不成立条件が不明確な場合が多く、また、全ての条件を日本語の文章で漏れなく記載することは熟練を要する。例えば、システム仕様書では、日本語の文章によって、「ＸＸの状態のときＹＹとする」と記載されていることが多い。「ＸＸの状態」が１つの条件だけで成立する場合は、条件が一意に定まる。そのため、この文章は、明確な記載になっている。しかしながら、「ＸＸの状態」が複数の条件によって成立する場合は、各条件は成立条件及び不成立条件が不明確な場合が多いことが問題である。

前記した通り、従来用いられていたシステム仕様書は、説明が曖昧に記載されている場合や記載漏れがある場合があった。しかも、従来用いられていたシステム仕様書は、説明が曖昧に記載されていても、説明が記載されているだけで、あたかも全ての説明が読み手に明確に理解されるかのように錯誤される場合があった。

そのため、従来用いられていたシステム仕様書は、読み手に曖昧な理解を誘発する場合があるという問題があった。また、例えば、発注者と受注者が仕様を確認したり要件を分析する場合に、仕様の記載漏れや記載の妥当性の判断が困難であるという問題があった。

また、例えば、設計者と製作者が制御プログラムを作成する場合に、仕様毎の各条件の成立条件及び不成立条件のチェックが困難であるという問題があった。さらに、機器（設備）は、従来用いられているシステム仕様書に記載された仕様では適正に動作できない場合があるという問題があった。

本発明は、前記の課題を解決するための発明であって、制御対象の機器の状態を規定する条件を明確に定義でき実行できる情報制御システムおよび制御ソフトウェアの作成方法を提供することを目的とする。

前記目的を達成するため、情報制御システムは、制御対象システムを構成する対象物であるオブジェクトと、オブジェクトの状態を監視しオブジェクトへの状態変化を指令するアクタという考えを導入する。

制御対象システムの制御ソフトウェアを管理する管理サーバ（例えば、ＳＩ管理サーバ１００）は、オブジェクトを監視・制御する制御要素であるアクタとして、オブジェクトのオブジェクト名、オブジェクトの監視項目、監視項目の設定値、および設定値の監視条件を関連付けるアクタ定義情報とを記憶する記憶部（例えば、記憶部２０）と、制御対象システムの制御モデルを作成するモデル作成部（例えば、モデル作成部１３０）を有し、
モデル作成部は、クライアント端末(例えば、開発ＰＣ１００Ａ)からアクタの作成要求を受理すると、アクタ定義情報を、オブジェクトの監視項目を行に、設定値および監視条件を列として表形式で、クライアント端末の表示部に表示することを特徴とする。

本発明によれば、制御対象の機器の状態を規定する条件を明確に定義でき実行できる。

以下、図面を参照して、本発明の実施の形態（以下、「本実施形態」と称する。）につき詳細に説明する。なお、各図において、共通する構成要素や同様な構成要素については、同一の符号を付し、それらの重複する説明を省略する。

本実施形態に係る情報制御システムは、従来の曖昧なシステム仕様書をもとに、プログラム開発者が仕様書を解読しプログラムを作成する方法ではない。すなわち、システム仕様書に基づいてプログラムを作成し実行するのではなく、システムの定義書に基づいたプログラムレスの開発手法を採用する。そのために、制御対象システムのモデル化が重要となる。

制御対象システムのモデル化には、「操作員の業務」および業務で用いている「判断基準、運用手順」をモデル化したものと、「設備の値」や「運転計画」といった運転（制御）を行う上で必要となるものとを要する。これらは、それぞれ、「アクタ」と「オブジェクト」と以後称する。詳細は後述する。

図１は、本実施形態に係る情報制御システムの構成を示すブロック図である。情報制御システムＳは、ＳＩ管理サーバ１００（管理サーバ）、開発者用のＰＣ（Personal Computer）である開発ＰＣ１００Ａ（クライアント端末）、実機サーバ４００、制御対象システム２００の制御状態を監視するＰＣである監視ＰＣ４００Ａ、制御対象システム２００の運転計画者（制御計画者）用のＰＣである運転計画ＰＣ４００Ｂなどを有しており、各サーバおよび各ＰＣは、ネットワーク３００を介して接続されている。なお、ＳＩは、System Integratorの略である。

ＳＩ管理サーバ１００は、情報制御の処理を行う処理部１０、情報制御の処理を行う際にデータを格納する記憶部２０、データを入力する入力部３１、データを出力する出力部３２、およびネットワーク３００を介して開発ＰＣ１００Ａ、実機サーバ４００などと通信を行う通信部３３から構成される。

記憶部２０は、ＲＡＭ（Random Access Memory）やＨＤＤ（Hard disk drive）装置などにより構成される。処理部１０は、ひとつ以上のＣＰＵ（Central Processing Unit）によって、ＲＡＭやＨＤＤ上のプログラムを実行することで実現される。入力部３１は、キーボードやマウスなどのコンピュータに指示を入力するための装置であり、プログラム起動などの指示を入力する。出力部３２は、ディスプレイなどであり、ＳＩ管理サーバ１００による処理の実行状況や実行結果などを表示する。通信部３３は、ネットワーク３００を介して、実機サーバ４００と各種データやコマンドを交換する。なお、制御対象システム２００とは、例えば、電力システム、列車運行管理システム、上下水管理システムがある。

処理部１０は、制御対象システムの制御モデルを作成するモデル作成部１３０、モデル作成部１３０で作成されたモデルを検証するモデル検証部１４０、モデル検証部１４０で確認されたモデルをテストデータを用いて動作検証する動作検証部１５０、動作検証部１５０で検証された実行モジュールを実機サーバ４００に配布する実行モジュール配布部１６０を有している。

処理部１０のモデル作成部１３０は、アクタ設定部１３１、オブジェクト設定部１３２、アクタコントロール設定部１３３、オブジェクトコントロール設定部１３４、辞書設定部１３５を有する。

記憶部２０には、アクタの情報（アクタ定義情報、アクタ定義表）を格納するアクタＤＢ２１、オブジェクトの情報（オブジェクト定義情報、オブジェクト定義表）を格納するオブジェクトＤＢ２２、アクタおよびオブジェクトで使用される用語が定義されている辞書ＤＢ２３、アクタおよびオブジェクトを設定する上でのテンプレート（定義表）を格納するテンプレートＤＢ２４、およびモデル検証部１４０での検証結果、動作検証部１５０で検証する場合のテストデータ、検証結果を格納する検証部ＤＢ２５が格納されている。アクタ定義表は、図３から図６を参照して後述する。また、オブジェクト定義表は、図７および図８を参照して後述する。

実機サーバ４００は、制御対象システム２００の処理部（図示せず）に、制御対象システムのオブジェクトの状態変化の監視をする監視機能部４１０、監視機能部４１０の制御指令に基づきオブジェクトへの制御指令を行う制御機能部４２０、制御対象システム２００の運転管理を行う運転管理機能部４３０を有する。

なお、監視機能部４１０は、ＳＩ管理サーバ１００から配布された、アクタ定義表およびオブジェクト定義表に基づいて制御対象となるオブジェクトを監視する機能を有している。

アクタおよびオブジェクトの内容、およびアクタ設定部１３１、オブジェクト設定部１３２、アクタコントロール設定部１３３、オブジェクトコントロール設定部１３４について、図２を参照して説明する。

図２は、アクタとオブジェクトとの関係を示す説明図である。本実施形態では、電力システムの電気所の事故監視を例に説明する。電気所とは、発電所、変電所などである。オブジェクトとは、業務（制御）を行う上で必要となるものである。電気所の場合、オブジェクトは、電気所、電気所を構成する母線、リレー、遮断器などが存在する。また、監視画面の描画パタン、監視を行う上での警報もオブジェクトといえる。アクタとは、操作員の業務あるいは制御の機能をいい、指示操作機能、画面監視機能、状態変化時の対応機能である。図２においては、アクタとして、例えば、描画パタンの操作指示、電気所状態の対応、母線状態の対応、リレー状態の対応、遮断器状態の対応などがある。すなわち、制御対象システムとして要求されている機能はアクタとして、アクタが利用するデータはオブジェクトとして定義される。

図１に戻り、アクタ設定部１３１は、テンプレートＤＢ２４内のアクタの定義表に基づいて設定され、定義されたアクタ定義表をアクタＤＢ２１に格納する。同様に、オブジェクト設定部１３２は、テンプレートＤＢ２４内のオブジェクトの定義表に基づいて設定され、定義されたオブジェクト定義表をオブジェクトＤＢ２２に格納する。

アクタコントロール設定部１３３は、アクタ全体の動作を設定する部分であり、制御対象システム２００の機能毎に複数のアクタをアクタ群として設定し、アクタの実行順序、オブジェクトデータの取り込みタイミングなどを設定する。また、アクタコントロール設定部１３は、複数のアクタ群を設定する。

オブジェクトコントロール設定部１３４は、オブジェクト全体の動作を設定する部分であり、制御対象システムの機能毎に複数のオブジェクトをオブジェクト群として設定し、ＣＰＵ間に跨る同一オブジェクト間でのデータの反映コントロールなどを設定する。また、オブジェクトコントロール設定部１３４は、複数のオブジェクト群を設定する。

設定されたアクタ群とオブジェクト群は、それぞれアクタコントロール、オブジェクトコントロールに規定されたルールに従い、情報制御システムＳ内で実行することとなる。

情報制御システムＳは、アクタおよびオブジェクトにより制御され、以下に特徴と具体的な方法を説明する。
（１）モデル論理と実装連携との分離実行
・モデルをベースとして仕様定義されるものが動作する範囲と、周辺との連携が必要で動作する部分とを分離する。
・モデル論理と実装連携のインタフェースはデータを介してのみ実現する。すなわち実装連携に関する手続きなどはオブジェクトにより隠蔽される。

（２）機能の独立性確保
・走りきりで動作する単位を、アクタの単位とし、実装する上での１単位とする。なお、走りきりとは、その単位で独立して実行でき「条件が成立すると動作する」ことをいう。
・アクタは、自分が動作すべき条件が成立した時点で動作する。
・アクタは、アクタの実行中において他のアクタとの同期型の実行は実装しない。すなわち、他アクタに実行依頼をして、依頼先のアクタからの応答を待つようなロジックとはしない。
・実行は、全てのアクタに対して、周期的に実行可能かの検証を行い、実行可能となるアクタを順次実行する振る舞いとする。

（３）ロジックとデータの分離
・走りきる単位内には、次回のためのデータや状態は持たない。走りきるもの同士や、走りきる上で継続する必要のある値や状態は、値や状態を管理する別な実装を行う。
（４）データ単位の独立性確保。
・データはオブジェクトにより規定する。このため外部と連携しているオブジェクトは、アクタや、外部からのデータ更新に基づき、相手方のデータ更新を行う。
・オブジェクトの外部との連携のためのデータ更新については、アクタの実行周期の前に取り込み、実行後に反映する。このデータ更新を実現するための関数群をオブジェクト内に規定する。

上記の特徴を満足するアクタとオブジェクトの動作モデルを規定する。すなわち、
（１）アクタコントロールに基づき実行する前に、オブジェクトのデータに実データを反映する。オブジェクトに規定されている、参照するときに実行する関数群を実行する。
（２）アクタコントロールで規定されたアクタの実行順番に従い、アクタを順次起動を行う。具体的には、
（２−１）アクタは、自身が実行すべき条件を満たしているかを判断する。
（２−２）条件を満たしているアクタは、記載された仕様に基づき実行する。具体的には、オブジェクトから必要なデータを参照し、決められたルールに従いオブジェクトへデータの設定を行う。
（２−３）全てのアクタの実行が終了した時点で、値に変更があったオブジェクトの値を実データに反映する。オブジェクトに規定されている、更新されたときに実行する関数群を実行する。

次に、具体的なアクタ定義表およびオブジェクト定義表を説明する。
図３から図６は、アクタ定義表であり、図７および図８は、オブジェクト定義表である。本実施形態では、電気所の事故監視機能を定義するアクタおよびオブジェクトについて説明する。

図３は、アクタ定義表の事故監視機能を示す構成図である。アクタ定義表は、名称部、コントロール部、実行部から構成されている。名称部は、アクタを識別する名称で構成され、アクタ種別、アクタ名称１、アクタ名称２を有している。コントロール部は、アクタが動作を行う上での監視項目（オブジェクト名）と、実行部で記述した条件が有効となるための条件である開始条件を定義する部分である。

実行部（アクタの実行部）は、監視項目と設定値を含む結果と、その結果を得るための条件から構成される。条件とは、制御対象システムに反映する操作員のノウハウや、運転（制御）する上での制約条件を表すものである。実行部は、複数の監視項目に対し、表形式で、夫々条件式を定義している。具体的には、処理部１０により、［電気所］の［今回］の［動作状態］が［事故発生］の条件を満たすならば、監視項目の［描画パタン］は、［ブリンク］の指令されることを意味する。また、上記以外の場合（［電気所］の［今回］の［動作状態］が［事故発生］の条件を満たさないならば）、監視項目の［描画パタン］は、［ブリンク停止］の指令されることを意味する。さらに、図３に示す例では、［電気所］の［今回］の［動作状態］が［事故発生］の条件を満たすならば、監視項目の［描画パタン］は、［ブリンク］の指令され、［警報］は［出力］の指令され、［マンマシン釦］は［フリッカ］の指令されることになる。

なお、表形式の実行部中、“［”および“］”で囲まれた各用語は、情報制御システムＳ上の定義語を表している。以下、“［”および“］”で囲まれた各用語を、「定義語」と称する。この定義語は、他のアクタ内でも共通の意味を持つ定義語として用いられる。この定義語は、各アクタ間を関連付けるために使用される。

また、図３に示すように、情報制御システムＳには、時間要素を考慮する必要があるため、条件式には［今回］などの定義語が使用される。時間要素は、他のアクタで定義されているものとして、説明を省略する。

図４は、アクタ定義表の電気所状態を示す構成図である。図４に示すアクタ定義表は、図３と同様であり説明は省略するが、複数の条件のＯＲ条件の定義が示されている。具体的には、監視項目（オブジェクト名）である［電気所］は、所定の動作条件を満たすならば、［動作状態］が［事故発生］と設定される。所定の動作条件とは、［電気所に属する］［母線］の［今回］の［動作状態］が［事故発生］の条件、または、［電気所に属する］［線路］の［今回］の［動作状態］が［事故発生］の条件、または、［電気所に属する］［変圧器］の［今回］の［動作状態］が［事故発生］の条件、または、［電気所に属する］［発電機］の［今回］の［動作状態］が［事故発生］の条件を満たした場合である。なお、各［監視対象］（例えば、［電気所に属する］［母線］）は、図７（ｂ）に示すオブジェクト定義表（設備構造オブジェクト）に関連付けがされている。

図５は、アクタ定義表の母線事故状態および母線動作状態を示す構成図である。図５（ａ）、図５（ｂ）に示すアクタ定義表は、図３と同様であり説明は省略するが、実行部の条件は、複数の条件のＡＮＤ条件が示されている。具体的には、図５（ａ）に示すように、監視項目（オブジェクト名）である［母線］は、［母線］の［今回］の［事故監視状態］が［監視中］の条件、かつ、［母線］の［遮断器状態］が［トリップ］の条件を満たすならば、［動作状態］が［事故発生］と設定される。同様に、図５（ａ）に示す監視項目（オブジェクト名）である［母線］は、［母線］の［前回］の［リレー状態］が［トリップ］の条件、かつ、［母線］の［今回］の［リレー状態］が［トリップ］の条件を満たすならば、［事故監視状態］が［監視中］と設定される。

また、具体的には、図５（ｂ）に示すように、監視項目（オブジェクト名）である［母線］は、［母線に属する］［リレー］の［前回］の［状態］が［接続］の条件、かつ、［母線に属する］［リレー］の［今回］の［状態］が［遮断］の条件を満たすならば、［リレー状態］が［トリップ］と設定される。

図６は、アクタ定義表のリレー状態および遮断器状態を示す構成図である。図６（ａ）、図６（ｂ）に示す定義表は、制御対象システムのひとつであるオブジェクトの信号ビット（制御信号）と、「監視項目」の「設定値」との関連付けをする定義表である。具体的には、図６(ａ）に示すように、監視項目（オブジェクト名）である［リレー］は、「０」の条件のとき、［状態］が［接続］と設定され、「１」の条件のとき、［状態］が［遮断］と設定される。同様に、図６(ｂ）に示すように、監視項目（オブジェクト名）である［遮断器］は、「０」の条件のとき、［状態］が［接続］と設定され、「１」の条件のとき、［状態］が［遮断］と設定される。制御信号は、制御対象システム２００から、通信部３３を介して、監視機能部４１０が受信する。

図７は、オブジェクト定義表の電気所を示す構成図である。オブジェクト定義表には、図７（ａ）に示す設備状態を示すオブジェクト定義表、図７（ｂ）に示す設備構造を示すオブジェクト定義表がある。オブジェクト定義表は、オブジェクトの属性を定義する共通部と、オブジェクトが管理するデータ項目部を有している。

共通部には、オブジェクトを識別するオブジェクト名称、当該オブジェクトのクラス（グループ）を指定する上位クラス、当該オブジェクトをクラスとして扱うか否かを指定するクラス指定がある。なお、クラスとは、複数のオブジェクト群としてまとめるときのグループの識別子を意味する。

データ項目部には、データを識別する名称であるデータ項目名称、格納するデータのデータ形式を指定するデータ形式、複数のデータを持つ場合の配列の意味の構造形式、データのとりうる値（状態値）を指定する値域、初期値などを有する。

具体的には、図７（ａ）に示すように、電気所の設備状態のデータ項目部には、［描画パタン］、［動作状態］などが指定され、図７（ｂ）に示すように、電気所の設備構造のデータ項目部には、［電気所に属する］［母線］、［電気所に属する］［線路］、［電気所に属する］［変圧器］、［電気所に属する］［発電機］が指定されている。

図８は、オブジェクト定義表の母線を示す構成図である。オブジェクト定義表には、図７と同様に、図８（ａ）に示す設備状態を示すオブジェクト定義表、図８（ｂ）に示す設備構造を示すオブジェクト定義表がある。具体的には、図８（ａ）に示すように、母線の設備状態のデータ項目部には、［母線状態］、［事故監視状態］、［リレー状態］、［遮断器状態］が指定され、図８（ｂ）に示すように、母線の設備構造のデータ項目部には、［母線に属する］［リレー］、［母線に属する］［遮断器］が指定されている。

次に処理フローについて説明する。
図９は、ＳＩ管理サーバから実機サーバへ実行モジュールの配布の処理を示すフローチャートである。適宜図１を参照して説明する。開発者は、開発ＰＣ１００Ａにモデル作成画面５０（図１０および図１１参照）を呼び出し、モデル作成部１３０は、登録要求を受理すると、入力されたアクタ、辞書、オブジェクトの定義を、それぞれアクタＤＢ２１、オブジェクトＤＢ２２、辞書ＤＢ２３に登録する（ステップＳ１１）。

図１０は、アクタの定義画面例を示す説明図である。モデル作成画面５０ａ（５０）には、メニュー部５１、定義表を設定する設定部５２、設定部５２に入力された入力をキャンセルするキャンセルボタン５３、既に登録済みの定義表を読み込む読込みボタン５４、設定部５２に入力された登録内容を登録する登録ボタン５５を有している。図１０に示す設定部５２には、アクタ定義表をオブジェクトの監視項目を行または列、設定値および監視条件を列または行として表形式で表示している。図１０において、アクタ定義表の設定の途中状態を示し、具体的には、監視項目の［描画パタン］まで入力している状態である。

メニュー部５１には、アクタ定義表、オブジェクト定義表を設定する「モデル作成部」、設定（作成）された定義表を検証する「モデル検証」、設定されたモデルの動作検証をする「動作検証」、実機サーバ４００に実行モジュールを配布する「配布部」、モデル作成などにおいて操作機能について説明する「ヘルプ」のメニューがある。また、「モデル作成部」中に「アクタ」、「オブジェクト」、「アクタコントロール」、「オブジェクトコントロール」、「辞書」のメニューがあり、マウスなどでクリックすると、設定画面が表示される。具体的には、「アクタ」のメニューをクリックすると、アクタ設定部１３１は、テンプレートＤＢ２４から、アクタ定義表のテンプレートを読込み、設定部５２に表示する。

また、「モデル検証」メニューには、さらに詳細なメニューがある。具体的には、「実行」、「関連表表示（鳥瞰図）」、「関連表表示（ツリー表示）」、「不整合表示」、「不整合非表示」などのメニューがある。

また、既に登録済みのアクタ定義表を読み込む場合は、開発者が設定部５２に表示されたアクタ定義表のテンプレート表に、アクタ種別、アクタ名称１、監視項目（オブジェクト名）を入力後、読込みボタン５４をマウスなどでクリックすると、アクタ設定部１３１は、アクタ種別、アクタ名称１、監視項目（オブジェクト名）をキーとして、アクタＤＢ２１を検索し設定部５２に表示する。

図１１は、オブジェクトの定義画面例を示す説明図である。モデル作成画面５０ｂ（５０）には、図１０と同様に、メニュー部５１、定義表を設定する設定部５２、設定部５２に入力された入力をキャンセルするキャンセルボタン５３、既に登録済みの定義表を読み込む読込みボタン５４、設定部５２に入力された登録内容を登録する登録ボタン５５を有している。図１１の設定部５２には、オブジェクト定義表の設定の途中状態を示し、具体的には、監視項目の［描画パタン］まで入力している状態である。

メニュー部５１の「モデル作成部」中に「オブジェクト」をマウスなどでクリックすると、設定画面が表示される。オブジェクト設定部１３２は、テンプレートＤＢ２４から、オブジェクト定義表のテンプレートを読込み、設定部５２に表示する。また、既に登録済みのオブジェクト定義表を読み込む場合は、開発者が設定部５２に表示されたオブジェクト定義表のテンプレート表に、オブジェクト名称、少なくともひとつのデータ項目名称を入力すると、オブジェクト設定部１３２は、オブジェクト名称、データ項目名称をキーとして、オブジェクトＤＢ２２を検索し設定部５２に表示する。なお、オブジェクト設定部１３２が複数の該当するオブジェクト定義表を検索した場合、モデル作成画面５０と異なる定義表選択画面（図示せず）が表示され、開発者へ選択するように指示してもよい。

図９に戻り、ステップＳ１１後、モデル作成画面５０のメニュー部５１の「モデル検証」内の「実行」をマウスなどでクリックされると、モデル検証部１４０は、図１２に示すモデル検証の処理により、モデル作成部１３０で作成されたモデルを検証する（ステップＳ１２）。

図１２は、モデル検証の処理を示すフローチャートである。モデル検証部１４０は、設定部５２からアクタ種別、アクタ名称を受理すると（ステップＳ４１）、監視項目（オブジェクト名）、監視項目、設定値に対して、ステップＳ４２からステップＳ４６を繰り返す。ステップＳ４３において、条件の定義語群（用語群）を抽出し（ステップＳ４３）、抽出された定義語群（用語群）に合致したアクタを抽出（ステップＳ４４）する。また、モデル検証部１４０は、抽出された定義語群（用語群）に合致するオブジェクト（ステップＳ４５）を抽出する。なお、条件の定義語群（用語群）とは、例えば、図１０に示す［電気所］［動作状態］［事故発生］である。

そして、モデル検証部１４０は、関連表（関連情報）（図１３および図１４参照）を作成し（ステップＳ４７）、検証部ＤＢ２５に格納するとともに、関連表を画面に表示する。関連表において、ループをしているなど不具合がある箇所（不整合）を検出し（ステップＳ４８）、表示画面の結線色を変えるなどして告知する。

なお、ステップＳ４３において、抽出されたアクタに関しては、ステップＳ４１からステップＳ４６と同様に、条件の定義語群に合致する、アクタおよびオブジェクトの抽出を繰り返すとよい。

図９に戻り、開発者は、定義誤りがないか否かを判定し（ステップＳ１３）、定義誤りがある場合（ステップＳ１３，Ｎｏ）、ステップＳ１１に戻る。定義誤りがない場合は（ステップＳ１３，Ｙｅｓ）、メニュー部５１の「モデル検証」内の「登録」をマウスなどでクリックすると、モデル検証部１４０は、ＳＩ管理サーバ１４の検証部ＤＢ２５にアクタ、辞書、オブジェクトの定義を登録し（ステップＳ１４）、ドキュメント、ソース、実行モジュールを生成する（ステップＳ１５）。

開発者が、メニュー部５１の「動作検証」内の「実行」をマウスなどでクリックすると、動作検証部１５０は、モデル検証部１４０で確認されたモデルをテストデータを用いて動作検証する（ステップＳ１６）。動作検証部１５０は、動作検証結果を動作検証画面（図示せず）に表示する。開発者は、不具合がないか否かを判定する（ステップＳ１７）。不具合がある場合には（ステップＳ１７，Ｎｏ）、ステップＳ１１に戻る。不具合がない場合には（ステップＳ１７，Ｙｅｓ）、開発者は、メニュー部５１の「配布部」内の「実行」をマウスなどでクリックすると、実行モジュール配布部１６０は、検証部ＤＢ２５に格納されている検証済みの実行モジュールを、通信部３３を介して実機サーバ４０に配布し（ステップＳ１８）、一連の処理を終了する。

図１３は、関連表を示す俯瞰図（鳥瞰図）である。図１３には、複数のアクタ定義表を俯瞰図（鳥瞰図）として、図１３（ａ）から図１３（ｅ）に示している。図１３（ａ）は、事故監視機能（図３参照）を示し、図１３（ｂ）は、電気所状態（図４参照）を示し、図１３（ｃ）および図１３（ｄ）は、母線状態（図５参照、母線事故状態、母線動作状態）を示し、１３（ｅ）は、リレー状態（図６参照）を示す。図１３には、複数のアクタの関連する定義語のみを記載し、他の記載は省略するとよい。また、定義語の関連は、破線または実線で関連付けられている。

図１３（ａ）に示す［電気所］［動作状態］［事故発生］の定義語群は、図１３（ｂ）と関連付けされており、図１３（ｂ）に示す［母線］［動作状態］［事故発生］の定義語群は、図１３（ｃ）と関連付けられている。また、図１３（ｃ）内の［母線］［事故監視状態］［監視中］は、図１３（ｃ）内で関連付けられている。

同様に、図１３（ｃ）に示す［母線］［リレー状態］［トリップ］は、図１３（ｄ）と関連付けられており、図１３（ｄ）に示す［リレー］［状態］［接続］または、［リレー］［状態］［遮断］は、図１３（ｅ）と関連付けられている。

このとき、モデル検証部１４０は、例えば、図１３（ｃ）に示す［母線］［リレー状態］［トリップ］は、図１３（ｄ）に示す［母線］［リレー状態］はあるが、［トリップ］がない場合には、関連付けの不整合であるとして判定する。

図１４は、関連表を示すツリー図である。図１４には、他の関連表の表示方法としてツリー形式で表示した場合について説明する。図１４（ａ）には、複数のアクタ定義表の関連を示している。具体的には、監視項目のオブジェクト名である［電気所］（図３）は、［電気所］（図４）と関連付けられ、［電気所］（図４）は、［母線］（図５（ａ））、［線路］、［変圧器］、［発電機］と関連付けられ、また、［母線］（図５（ａ））は、［母線］（図５（ｂ））と関連付けられている。さらに、［母線］（図５（ｂ））は、［リレー］（図６（ａ））、［遮断器］（図６（ｂ））と関連付けられている。

図１４（ｂ）には、オブジェクト名と、オブジェクト定義表との関連を示す。具体的には、監視項目のオブジェクト名である［電気所］は、複数のオブジェクト定義表（図７（ａ）、図７（ｂ））で構成されている。また、［母線］は、複数のオブジェクト定義表（図８（ａ）、図８（ｂ））で構成されている。

図１５は、監視機能の処理を示すフローチャートである。実機サーバ４００の監視機能部４１０は、アクタの状態を監視する。図２に示すように、アクタ群として複数のアクタが登録されていても、個々のアクタは、基本的に独立であり、「条件が成立すると動作する」という処理である。図１５には、アクタの処理を示している。

監視機能部４１０は、アクタの監視をする（ステップＳ１）。アクタの監視とは、アクタの条件項目の状態が変化したか否かを監視する。状態が変化しない場合（ステップＳ２，Ｎｏ）、ステップＳ１に戻りアクタの監視を続ける。状態が変化した場合（ステップＳ２，Ｙｅｓ）、アクタの条件を満たすか否かを判定する（ステップＳ３）。アクタの条件を満たさない場合（ステップＳ３，Ｎｏ）、ステップＳ１に戻りアクタの監視を続ける。アクタの条件を満たす場合（ステップＳ３，Ｙｅｓ）、対象オブジェクトの監視項目の設定値を設定する（ステップＳ４）。以後、ステップＳ１に戻り処理を継続する。

本実施形態では、アクタ定義表およびオブジェクト定義表について、電力システムを例について説明したが、これに限るものではない。アクタおよびオブジェクトとして定義できる制御対象システムであれば、列車運行管理システム、上下水管理システムなどの他の情報制御システムにも利用できる。

本実施形態によれば、発注者と受注者間の仕様確認や要件分析において、曖昧な記載をしたドキュメントを用いることなく、制御対象の機器の状態を規定する条件を明確に定義でき実行できる情報制御システムＳを提供することができる。

本実施形態によれば、アクタ定義表、オブジェクト定義表、辞書定義表にわけることにより、各定義表が大きくならずに、行と列が抑えることができる。また、機能変更などの場合には、個々のアクタ定義表、オブジェクト定義表、辞書定義表の変更で対応することができる。また、一つのアクタが実行されるとき、アクタ間、オブジェクト、辞書との関係が、例えば、ツリー図、俯瞰図（鳥瞰図）で表示することで全体を把握することが容易にできる。さらに、モデル検証の不整合検出により、定義が未完なアクタ、オブジェクト、辞書の定義を抽出することができる。

本実施形態によれば、下記のような効果も有する。
（１）独立して実行できるアクタを採用しているため、機能変更や、対象物の部分修正に対して迅速に対応することができる。
（２）制御対象システムの装置の構成が変化しても、影響度が少ない。
（３）将来的な設備増加や機能増加に対しての影響度が少ない。
（４）ハードウェアやＯＳ（Operation System）、ミドルウェアの違いに影響を受けない。
（５）通信部にテスト環境システムを、容易に連携できる。
（６）アクタ群の部分テストが容易にできる。
（７）アクタ群の応答性、信頼性の検証および制御をすることができる。

本実施形態に係る情報制御システムの構成を示すブロック図である。 アクタとオブジェクトとの関係を示す説明図である。 アクタ定義表の事故監視機能を示す構成図である。 アクタ定義表の電気所状態を示す構成図である。 アクタ定義表の母線事故状態および母線動作状態を示す構成図である。 アクタ定義表のリレー状態および遮断器状態を示す構成図である。 オブジェクト定義表の電気所を示す構成図である。 オブジェクト定義表の母線を示す構成図である。 ＳＩ管理サーバから実機サーバへ実行モジュールの配布の登録の処理を示すフローチャートである。 アクタの定義画面例を示す説明図である。 オブジェクトの定義画面例を示す説明図である。 モデル検証の処理を示すフローチャートである。 関連表を示す俯瞰図（鳥瞰図）である。 関連表を示すツリー図である。 監視機能の処理を示すフローチャートである。

符号の説明

１０ 処理部
２０ 記憶部
２１ アクタＤＢ
２２ オブジェクトＤＢ
２３ 辞書ＤＢ
２４ テンプレートＤＢ
２５ 検証部ＤＢ
３１ 入力部
３２ 出力部
３３ 通信部
１００ ＳＩ管理サーバ（管理サーバ）
１００Ａ 開発ＰＣ（クライアント端末）
１３０ モデル作成部
１３１ アクタ設定部
１３２ オブジェクト設定部
１３３ アクタコントロール設定部
１３４ オブジェクトコントロール設定部
１３５ 辞書設定部
１４０ モデル検証部
１５０ 動作検証部
１６０ 実行モジュール配布部
２００ 制御対象システム
３００ ネットワーク
４００ 実機サーバ
４１０ 監視機能部
４２０ 制御機能部
４３０ 運転管理機能部
Ｓ 情報制御システム

Claims (6)

1. 制御対象システムの制御ソフトウェアを管理する管理サーバを有し、前記制御対象システムを構成する対象物であるオブジェクトの状態を監視し前記オブジェクトへの制御指令を行う情報制御システムであって、
   前記管理サーバは、
   前記オブジェクトを監視・制御する制御要素であるアクタとして、前記オブジェクトのオブジェクト名、前記オブジェクトの監視項目、前記監視項目の設定値、および前記設定値の監視条件を関連付けるアクタ定義情報を記憶する記憶部と、
   前記制御対象システムの制御モデルを作成するモデル作成部と、を有し、
   前記モデル作成部は、
   クライアント端末から前記アクタの作成要求を受理すると、前記アクタ定義情報を、前記オブジェクトの監視項目を行または列、前記設定値および前記監視条件を列または行として表形式で、前記クライアント端末の表示部に表示し、前記クライアント端末から前記アクタの登録要求を受理すると、前記表示部に表示されているアクタ定義情報をアクタとして前記記憶部に記憶する
   ことを特徴とする情報制御システム。
2. 前記アクタ定義情報には、監視対象のオブジェクト名、変化状態名、状態の変化名に対応する用語が、定義語の形式で記載されており、
   前記管理サーバは、さらに、
   前記モデル作成部で作成されたモデルの検証を行うモデル検証部を有し、
   前記モデル検証部は、
   前記クライアント端末からモデル検証要求を受理すると、
   前記監視条件から、複数の用語を抽出して用語群とし、
   前記用語群に合致するアクタ定義情報を抽出し、
   前記複数のアクタを順次関連付けて関連情報を作成する
   ことを特徴とする請求項１に記載の情報制御システム。
3. 前記モデル検証部は、前記関連情報を、俯瞰図、または、ツリー図として前記クライアント端末の表示部に表示する
   ことを特徴とする請求項２に記載の情報制御システム。
4. 記憶部を有する、制御対象システムの制御ソフトウェアを管理する管理サーバにおいて、前記制御対象システムの制御モデルを作成するモデル作成部により、前記制御対象システムを構成する対象物であるオブジェクトの状態を監視し前記オブジェクトへの制御指令を行う制御ソフトウエアの作成方法であって、
   前記記憶部には、
   前記オブジェクトを監視・制御する制御要素であるアクタとして、前記オブジェクトのオブジェクト名、前記オブジェクトの監視項目、前記監視項目の設定値、および前記設定値の監視条件を関連付けるアクタ定義情報が記憶されており、
   前記モデル作成部は、クライアント端末から前記アクタの作成要求を受理すると、前記アクタ定義情報を、前記オブジェクトの監視項目を行または列、前記設定値および前記監視条件を列または行として表形式で、前記クライアント端末の表示部に表示し、前記クライアント端末から前記アクタの登録要求を受理すると、前記表示部に表示されているアクタ定義情報をアクタとして前記記憶部に記憶する
   ことを特徴とする制御ソフトウェアの作成方法。
5. 前記管理サーバは、さらに、前記モデル作成部で作成されたモデルの検証を行うモデル検証部を有し、前記アクタ定義情報には、監視対象のオブジェクト名、変化状態名、状態の変化名に対応する用語が、定義語の形式で記載されており、
   前記モデル検証部は、
   前記クライアント端末からモデル検証要求を受理すると、
   前記監視条件から、複数の用語を抽出して用語群とし、
   前記用語群に合致するアクタ定義情報を抽出し、
   前記複数のアクタを順次関連付けて関連情報を作成する
   ことを特徴とする請求項４に記載の制御ソフトウェアの作成方法。
6. 前記モデル検証部は、前記関連情報を、俯瞰図、または、ツリー図として前記クライアント端末の表示部に表示する
   ことを特徴とする請求項４に記載の制御ソフトウェアの作成方法。

Images