JPH086777A - 情報制御システムの開発システムおよび開発方法 - Google Patents

Abstract

(57)【要約】 【目的】 ソフトウエアの再利用性の向上、設計誤りに
よる手戻りの削減、およびプログラムコードへの自動展
開による工数の削減を目的とする。 【構成】 情報制御システムの開発方法を実現するツー
ルとして、業務類型設定手段１０１、業務入出力モデル
設定手段１０２、定型処理モデル設定手段１０３を設
け、業務類型モデル１１０、業務入出力モデル１１１、
定型処理モデル１１２を生成する。また、設計インタフ
ェースとして業務入出力モデルカスタマイズ手段１０
４、外部インタフェース仕様設計手段１０５、内部処理
仕様設計手段１０６を設ける。１０７、１０８は検証・
製作インタフェースであり、各々機能検証性能評価、設
計仕様プログラム展開の各機能を受け持つ。１０９はモ
デルデータベースであり、部品化インタフェースの各機
能で設定した部品群を格納する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、情報制御システムの開
発システムおよび開発方法に関し、特に、過去に開発し
たシステムと類似した機能を有するシステムを開発する
際に、既存の生産物を再利用することにより、システム
の生産性と信頼性を向上することが可能な情報制御シス
テムの開発システムおよび開発方法に関する。

【０００２】

【従来の技術】近年、バブルの崩壊とともに、消費者の
購買意欲が薄れ、鉄鋼、自動車など各種産業分野におい
て製品売り上げが急落している。これに伴い、メーカの
設備投資額が大幅に削減され、情報制御システムの市場
価格の低下が著しい。ところで、計算機ハードウェア
は、CPU、メモりなどの生産技術の革新により、高機
能、低価格化を推進している。これに対して、ソフトウ
ェアの開発はいまだに開発者個人の能力に依存した手工
業の形態をとっていてエンジニアリングというよりはア
ートという段階である。情報制御システム開発の商売を
優位に進めるためには、このソフトウェア生産をよりシ
ステマティックに効率的に行うことが不可欠となる。現
状の情報制御システムの開発は、先ず顧客要求に従って
機能を設定し、それを段階的に順次詳細化していくアプ
ローチをとっている。そして、機能の設定と詳細化の方
法は開発者個人に一任されており、類似したシステムで
あっても全く異なるソフトウェア構成になる場合も少な
くない。

【０００３】

【発明が解決しようとする課題】上述したように、製品
開発の骨格となるべき製造方法と部品が標準化されてい
ない状況では、既存システム開発の成果物は単なる事例
でしかない。従って、過去の設計仕様書、ソフトウェ
ア、開発ノウハウなどは死蔵され有効活用されていな
い。また、設計は概略仕様から詳細仕様へと進められる
のに対して、テストは単体テストから統合テストへと逆
の方向をたどる。このため、上流の設計仕様ほど開発フ
ェーズの最終段階近くにならなければ確認できず、そこ
で問題が生じた場合には、初期段階の上流の設計の戻っ
て設計をやり直さなければならなく、時間とコストが膨
大にかかってしまうという問題がある。本発明は、上記
の問題点を解決するために、次の（１）〜（３）を目的
としている。 （１）標準的なソフトウェア部品とそれに基づく開発シ
ステムおよび開発方法を設定し、再利用性を向上する。 （２）設計段階で機能と性能の確認を行えるようにし、
設計誤りによる手戻りを撲滅する。 （３）定型処理での仕様からプログラムコードへの自動
展開を実現し、工数を削減する。

【０００４】

【課題を解決するための手段】本発明の情報制御システ
ムの開発システムは、上記の課題を解決するために、業
務処理の機能と情報の流れを類型化して業務群と情報群
の標準的な入出力関係を設定した業務類型化モデル（図
１の１１０）を生成する業務類型設定手段（同１０１）
と、各業務処理の入出力情報構造とその操作方法を標準
化して業務入出力モデル（同１１１）を生成する業務入
出力モデル設定手段（同１０２）と、前記業務入出力モ
デルに基づいて入力情報を出力情報に変換するための定
型的な処理仕様を設定して定型処理モデル（同１１２）
を生成する定型処理モデル設定手段（同１０３）と、前
記業務入出力モデルおよび定型処理モデルを対象システ
ムに適合するように変更する変更手段（同１０５〜１０
６）と、変更した結果を自動的にプログラムコードに展
開するプログラム展開手段（同１０８）を有することを
特徴としている。また、前記変更手段は、外部からの情
報入力あるいは外部への情報出力の処理仕様を定義する
外部インタフェース仕様設計手段（同１０５）と、前記
外部入出力仕様以外の内部処理仕様を定義する内部処理
仕様設計手段（同１０６）からなっていることを特徴と
している。さらに、変更手段による変更結果に対して機
能の検証および性能評価を行なう機能検証性能評価手段
（同１０７）を有することを特徴としている。また、本
発明の情報制御システムの開発方法は、上記各手段が有
する機能を用いることを特徴としている。

【０００５】

【作用】本発明は、上記手段により上記各課題を解決し
ている。具体的には、 （１）ソフトウェア部品の設定 前記の情報制御業務処理の類型化手段と業務入出力モデ
ル設定手段により、入出力情報の標準構造とその操作方
法を設定する。これを業務入出力モデルとよぶ。また、
前記の定型処理モデル設定手段により、入力情報を出力
情報に変換処理のうち定型的なものについてその仕様と
プログラムをパッケージ化する。これを定型処理モデル
とよぶ。 （２）業務処理仕様の設計 対象システムの機能を、各業務処理の入力情報と出力情
報という形で明かにする。そして、業務入出力モデルの
カスタマイズ手段により、標準的な業務入出力モデルを
対象システム向けに変更する。外部インタフェース仕様
の設計手段により、各業務処理について、イベントおよ
びデータの入出力をトリガとした状態遷移モデルを作成
する。この際、入出力の記述は、業務入出力モデルの情
報構造とその操作方法を用いて行う。内部処理仕様の設
計手段により、業務ごとに入力情報から出力情報への変
換仕様を作成する。定型処理に関しては、予め定められ
た記法により仕様を定義する。 （３）機能検証と性能評価 機能検証性能評価手段により、設計結果から検証用のモ
デルを自動生成し、それに基づいて機能検証と性能評価
を行う。ここで設計誤りが検出されたならば、必要な段
階、例えば、（１）、（２）まで戻って再設計をやり直
す。 （４）プログラム展開手段（インプリメント） 上記（３）で設計結果の妥当性が確認されたならば、前
記の設計仕様のプログラム展開手段により、プログラム
コードに展開する。業務入出力モデル、定型処理モデ
ル、外部入出力インタフェースに関しては、自動的にコ
ードを生成する。

【０００６】

【実施例】以下、本発明の実施例を図面に基づいて詳細
に説明する。図１は、本発明の一実施例を示す情報制御
システム開発支援ツールの機能構成を示す図である。同
図において、１０１、１０２、１０３は情報制御システ
ムの共通部分を抽出して部品化する部品化インタフェー
スであり、各々、業務類型設定、業務入出力モデル設
定、定型処理モデル設定の各機能を受け持つ。１０４、
１０５、１０６は設計インタフェースであり、各々、業
務入出力モデルカスタマイズ、外部インタフェース仕様
設計、内部処理仕様設計の各機能を受け持つ。１０７、
１０８は検証・製作インタフェースであり、各々、機能
検証性能評価、設計仕様プログラム展開の各機能を受け
持つ。１０９はモデルデータベースであり、部品化イン
タフェースの各機能で設定した部品群を格納する。部品
群は、業務類型モデル（１１０）、業務入出力モデル
（１１１）および定型処理モデル（１１２）である。

【０００７】まず、図１の実施例の構成要素について説
明しておく。 （１）情報制御業務処理の類型設定手段 情報制御システムにおける業務は、プラントで計測され
た種々の情報をトリガーとして進められる。プラント計
測情報と生産計画情報に基づいてプラント内の設備と製
品の状態を把握するのが状態推定業務である。状態情報
と計画情報に基づいて設備への制御指示を作成し出力す
るのが制御業務である。品質管理を目的として計測情報
を統計処理し実績情報として蓄積するのがデータ収集業
務である。また、プラント内監視を目的として捜査員に
計画情報、状態情報、品質情報を知らせるのが監視業務
である。このように、情報制御システムは基本的な４つ
の業務処理から構成される。これらの業務処理の機能
は、設備、製品、運用方法に応じて変わる。しかし、分
野を限定することにより、類似したシステムを比較し、
業務群と情報群との標準的な入出力関係を設定すること
が可能である。 （２）業務入出力モデル設定手段 前記の類型化手段で明かになった業務と情報との入出力
関係に基づいて、各情報については構造と操作方法の標
準仕様を定義する。情報の種類としては、計測情報、計
画情報、状態情報、制御情報、実績情報、監視情報の６
つがある。これらの各情報について、それを構成するデ
ータの属性、型などを定義し、また、データ参照、更
新、検索のための操作ルーチンを定義する。このように
して設定した情報構造とその操作方法のカプセルを入出
力情報部品とよび、その集合体を業務入出力モデルとよ
ぶ。 （３）定型処理モデル設定手段 前記の業務入出力モデル設定手段により、各類型化業務
の入出力情報の標準構造が明らかになった。本手段で
は、業務処理のうちデータ変換、分類などの定型処理に
ついて、その処理仕様とプログラムを定義する。処理仕
様は、対象分野の仕様記述に用いられる記法で定義でき
るようにし、仕様書を書けばそれに対応するプログラム
が自動生成されるようにする。定型処理の仕様とプログ
ラムのパッケージを定型処理部品とよび、その集合体を
定型処理モデルとよぶ。

【０００８】以上に述べた業務入出力モデルと定型処理
モデルを用いて、対象システムの業務処理を開発する方
法について以下に説明する。 （４）業務入出力モデルのカスタマイズ手段 各業務処理について、何をしたいか（WHAT）を入力情報
と出力情報という形で明かにし業務入出力モデルをカス
タマイズする。これは以下の手順で行う。 a) 業務概略仕様の設計：業務をサブ業務に分割し入出
力情報を明らかにする。 b) 情報構造のカスタマイズ：前記の入出力情報に基づ
いて、標準構造を対象システム向けに変更する。 c) 操作処理の作成：入出力情報構造の変更に伴う新た
な操作処理を作成する。 （５）外部インタフェース仕様の設計手段 各業務処理について、対象システム向けの業務入出力モ
デルを用いてイベントおよびデータの入出力をトリガと
した状態遷移モデルを定義する。これは以下の手順で行
う。 a) 業務状態遷移モデルの作成：状態の設定は、その遷
移が業務処理外部のイベントとデータの入出力をトリガ
として生起するように行う。 b) 詳細入出力処理の記述：状態遷移モデルの遷移また
は状態において、業務入出力モデルのどのデータ項目を
入出力するかを記述する。 （６）内部処理仕様の設計手段 状態遷移モデルの状態において、入力情報をどのように
変換して出力情報を作成するのかを記述する。定型処理
に関しては、予め定められた記法により仕様を定義す
る。その他の処理に関しては、従来通りの方法で設計を
行う。 （７）機能検証性能評価手段 本手段では、外部インタフェース仕様と内部処理仕様の
設計結果に基づいて、その機能検証と性能評価を行う。
外部インタフェース仕様の機能検証は、業務ごとに作成
した状態遷移を解析あるいはシミュレーションすること
により行う。たとえば、各情報の入出力関係をチェック
し、入力側と出力側とでデータ構造に不整合がないかを
確認する。また、複数業務間のイベント発生系列をチェ
ックし、システムの挙動に矛盾がないかを確認する。内
部処理仕様の機能検証は、定型処理に限定して次のよう
に行う。すなわち、予め定められた記法により定義され
た内部処理仕様について、それに文法的あるいは意味的
に誤りがないかをチェックする。また、性能評価では、
各業務処理の見積もり時間と計算機構成を与えることに
より、各種イベントに応じたシステムの応答性能、処理
性能を算出する。 （８）設計仕様のプログラム展開手段 以上の設計結果に基づき、業務処理をプログラムコード
に展開する。業務入出力モデル、定型処理モデル、外部
入出力インタフェースに関しては、自動的にコードを生
成する。

【０００９】図２は、本設計支援ツールに基づく情報制
御システムの開発手順を示す。以下、同図に従って手順
を説明する。 （１）まず、ソフトウェア部品の設定手順から説明す
る。 手順２０１：「業務類型の設定」では、情報制御システ
ムにおける代表的な業務である「状態推定業務」、「工
程制御業務」、「実績収集業務」、「工程監視業務」に
関して、対象とする分野ごとに、その標準的な機能を設
定する。ここで、「状態推定業務」とは、プラント計測
状態と生産計画状態に基づいてプラント内の設備と製品
の状態を把握する業務であり、「工程制御業務」とは、
プラント計測状態と生産計画状態に基づいてプラント内
の設備への制御指示を作成して出力する業務であり、、
「実績収集業務」とは、品質管理を目的として計測情報
を統計処理し実績情報として蓄積する業務であり、「工
程監視業務」とは、プラント内監視を目的として捜査員
に計画情報、状態情報、品質情報を知らせる業務であ
る。この際に必要ならば、さらに詳細なサブ業務、ある
いは、分野で特殊な業務を設定する。その結果、各業務
と情報の入出力関係を明かにする。このようにして得ら
れたソフトウエア部品を「業務類型モデル」とよぶ。 手順２０２：「業務入出力モデルの設定」では、前記で
明らかになった業務と入出力情報の関係に基づき、各入
出力情報の構造と操作方法を定義する。このようにして
得られたソフトウエア部品を「業務入出力モデル」とよ
ぶ。 手順２０３：各業務処理のうち、データ変換、分類など
の定型処理について、その処理仕様の標準形を定義す
る。この際、前記で定義した標準的な入出力情報部品を
前提とすることにより、入力情報から出力情報への変換
処理を部品化する。処理仕様は、対象分野の仕様記述に
用いられる記法で定義できるようにする。このようにし
て得られたソフトウエア部品を「定型処理モデル」とよ
ぶ。

【００１０】（２）次に、以上のようにして得られたソ
フトウェア部品（業務類型モデル、業務入出力モデル、
定型処理モデル）を利用して、対象とする制御システム
の設計製作を行う手順を説明する。 手順２０４：「業務入出力モデルのカスタマイズ」で
は、各業務処理について、その機能を入力情報と出力情
報という形で明かにする。そして、その機能を実現する
ために、前記の入出力情報部品をカスタマイズする。 手順２０５：「外部インタフェース仕様の設計」では、
各業務でいつどのような条件で入出力を行うかを定義す
る。すなわち、イベントおよびデータ入出力をトリガと
した状態遷移モデルを定義する。 手順２０６：「外部インタフェース仕様の検証」では、
上記手順２０４と手順２０５での設計結果に基づき、各
業務の入出力仕様、業務間の情報授受関係、イベントの
発生系列などを検証する。また、業務内の個々の処理の
見積もり時間を与えることにより、各種イベントに応じ
たシステムの応答性能、処理性能を評価する。 手順２０７：上記検証により、設計結果がＯＫとなった
ならば手順２０８に進み、ＮＧならば手順２０５に戻
る。 手順２０８：「内部処理仕様の設計」では、状態遷移の
各状態において、入力情報をどのように変換して出力情
報を作成するのかを記述する。定型処理に関しては予め
定められた記法により仕様を定義する。その他の処理に
関しては、従来通りの設計を行う。 手順２０９：「内部処理仕様の検証」では、定型的な内
部処理に関して、仕様レベルの検証を行う。 手順２１０：上記仕様レベルの検証により、設計結果が
ＯＫとなったならば手順２１１に進み、ＮＧならば手順
２０８に戻る。 手順２１１：「インプリメント」では、以上の設計結果
に基づき、業務処理をプログラムコードに展開する。業
務入出力情報、定型処理、外部入出力インタフェースの
設計結果に関しては、自動的にコードを生成する。

【００１１】以下に、図１を用いて説明した各機能の実
現方法を具体的に説明する。 （Ａ）まず、図１の業務類型設定（１０１）における業
務類型の設定方法を図３〜図７に従って説明する。図３
〜図７は、情報制御システムが具備すべき業務群と、そ
れらの間で授受される情報群との関係を示すためのもの
であり、図３は標準形類型（Ａ）とそれをアレンジした
各種業務類型、プロセス制御型システム（Ｂ）、プロセ
ス・離散混合型システム（Ｃ）、離散制御型システム
（Ｄ）を示している。標準形類型（Ａ）は、図４に示す
ように、上述した４つの業務、すなわち「状態推定」、
「工程制御」、「実績収集」、「工程監視」に、上位情
報系システムとのインタフェースと下位コントローラと
のインタフェースを追加したものである。

【００１２】プロセス制御型システム（Ｂ）は、図５に
示すように、石油、石油化学、鉄鋼、ガスなどの連続流
体からなるプラントの状態（例えば、温度、圧力、流量
など）の計測値を下位インタフェースであるＰ Ｉ／Ｏ
（プロセスＩ／Ｏ）入出力インタフェースから取り込
み、プラントを効率よく制御するものであり、通常、シ
ステムの状態推定を微分方程式などの数学的モデルによ
り行う。従って、この場合の「状態推定」を“モデル計
算”と呼ぶ。また、プロセス制御型システムにおいて
は、「工程制御」は“プロセス制御”と呼ばれる。な
お、「工程監視」は“モニタリング”と呼ばれ、ＣＲＴ
入出力業務を介してＣＲＴに接続されている。このタイ
プをＰＡ形すなわちプロセス・オートメーション形とい
う。

【００１３】これに対して、離散制御システム（Ｄ）
は、図７に示すように、例えば、自動車の組立などのよ
うに扱われるものが個別的なものであり、計算機内に仮
想的に生産ラインモデルを設定し、プラントで発生する
イベント（下位インタフェースであるＤＤＣ（ダイレク
ト・ディジタル・コントローラ）入出力業務からの計測
情報）に応じて該生産ラインモデル上で製品位置を追跡
する。従って、この場合の「状態推定」を“トラッキン
グ”と呼ぶ。また、離散制御システムにおいては、「工
程制御」を“物流制御”と呼ぶ。このタイプをＦＡ形す
なわちファクトリ・オートメーション形という。さら
に、鉄、紙、食品、薬品などの多くのプラントにおいて
は、上流の原料に近い工程では製品を連続的に扱い、下
流の最終製品に近い工程では離散的に扱う。このよう
に、連続制御と離散制御の混合形態も必要になる。これ
が、図６に示すプロセス・離散混合型システム（Ｃ）で
ある。このシステムでは、「状態推定」として、“トラ
ッキング”と“モデル計算”の両方を有する。更に、
「工程制御」として“設備制御”も備えている。このタ
イプを混合形という。上記３つの業務類型を、更に具体
的な分野へと展開していくことにより、業務間で授受す
る情報の構造と操作方法の標準形を設定できるようにな
る。例えば、プロセス・離散混合型システムは、鉄鋼シ
ステム、圧延システム、冷間圧延システムというように
徐々に業務を絞っていき、共通の情報構造を導き出すこ
とができる。以上の方法で明らかにした、分野ごとの業
務群と情報群との入出力関係を、業務類型モデルとして
ライブラリ化する。

【００１４】図８は、以降に本発明の説明のために引用
する離散制御システムの業務類型モデルを示す。同図に
おいて、４０１はトラッキング業務、４０２は物流制御
業務、４０３は状態表示業務、４０４は状態変更業務、
４０５は計画表示業務、４０６はスケジュール管理業
務、４０７はＤＤＣ入出力業務、４０８はＣＲＴ入出力
業務であり、４０９は状態情報、４１０は計画情報、４
１１は計測情報、４１２は制御情報、４１３は監視情報
である。これらの各情報は上記業務間で授受される情報
である。本業務類型モデルは、図７の離散制御システム
（Ｄ）の変形であり、それとの違いは次の２点である。 ・工程監視業務が、状態表示、状態変更、計画表示の３
つの業務に分割されている。 ・計画情報と状態情報がファイルに格納されている。

【００１５】以下、図８の業務類型モデルにおける各業
務間の情報の流れを説明する。トラッキング業務４０１
は、ＤＤＣ（ダイレクト・ディジタル・コントローラ）
入出力業務４０７から計測情報４１１を入力し、図７で
述べた生産ラインモデルに基づいて製品の位置と設備の
状態を推定する。その結果得られた状態情報４０９を、
ファイルに格納するとともに、物流制御業務４０２、状
態表示業務４０３、スケジュール管理業務４０６に出力
する。物流制御業務４０２は、スケジュール管理業務４
０６から計画情報４１０を入力し、トラッキング業務か
ら入力した状態情報４０９とＤＤＣ入出力業務から入力
した計測情報４１１を用いて、次にどの製品をどの設備
で処理するかを決定し、物流制御情報４１２としてＤＤ
Ｃ入出力業務に出力する。状態表示情報４０３は、トラ
ッキング業務から状態情報４０９を入力し、それをもと
に監視情報４１３を作成してＣＲＴ入出力業務４０８に
出力する。状態変更業務４０４は、ＣＲＴ入出力業務４
０８から設定情報を入力し、それをファイルに格納され
た状態情報に反映させる。計画表示業務４０５は、スケ
ジュール管理業務から計画情報４１０を入力し、それを
もとに監視情報４１３を作成してＣＲＴ入出力業務４０
８に出力する。スケジュール管理業務４０６は、上位計
算機から長期的な計画情報を入力し、トラッキング業務
から入力した状態情報４０９に応じて短期的な計画情報
４１０を物流制御業務に出力する。また、計画表示業務
４０５にも計画情報を出力する。ＤＤＣ入出力業務は、
下位のコントローラであるＤＤＣから生の計画情報を入
力し、情報の形式を変換した後に計画情報４１１として
トラッキング業務４０１、物流制御業務４０２に出力す
る。また、物流制御業務４０２から制御情報４１２を入
力し、下位のコントローラに出力する。ＣＲＴ入出力業
務４０８は、状態表示業務４０３と計画表示業務４０５
から監視情報を入力し、情報の形式を変換した後に下位
のＣＲＴ装置に出力する。また、ＣＲＴ装置から設定情
報を入力し、状態変更業務４０４に出力する。

【００１６】（Ｂ）次に、図８の離散制御システムを前
提として、図１の業務入出力モデル設定（１０２）で行
われる業務入出力モデルの設定方法を図９と図１０に従
って説明する。（１）で述べた方法により、対象分野の
業務類型すなわち業務群と情報群との入出力関係が設定
されているものとする。ここでは、各情報についてその
構造と操作方法の標準仕様を詳細に定義する。情報構造
は、データ項目ごとに以下の属性を記述する。 ・データ名称 ・型 ・値の範囲 ・初期値 情報の操作方法は、どのデータ項目にどんな操作を行い
たいのか、を以下のような記述形式のメソッドで指定す
る。 「コマンド＿データ項目名称（値）」 例えば、ある設備Ａに関して、位置、動作、処理という
データ項目を入力する操作は、 「ｇｅｔ＿設備状態（“設備Ａ”，位置，動作，処
理）」 と記述する。

【００１７】図９は監視情報の一例であり、工程状態変
更情報と工程状態表示情報とからなる。白丸印は情報の
個々の属性を示し、黒丸印は情報参照、更新などの操作
関数を示す。属性の右に記述された括弧内の値は、対応
した属性がとりうる値の範囲を示す。“common attribu
te”および“common method”は監視情報共通の属性と
メソッド（操作方法）を示し、“individual attribut
e”および“individualmethod”は個々の情報により異
なる属性とメソッドを示す。図９の左側の工程状態変更
情報を例にあげて詳細に説明する。監視情報内で共通の
属性として画面名称と操作モードがあり、工程状態変更
情報だけの固有の属性としてエリア、指示、エリア予約
結果、状態変更結果、指示欄モードがある。各属性の右
側の括弧内の値は、その属性の取りうる値を示す。例え
ば、画面名称の値はsetting，trackingなどの文字列で
あり、エリアは１yard,2yard,3yardの何れかの値をとる
ことを意味している。また、指示という属性のうち、コ
マンドという項目はmove,change,haltの何れかの値をと
り、製品という項目は１文字目がアルファベットのａか
らｄまでの何れかで、２文字目と３文字目が数字の０を
とり、４〜６文字目で１００から９９９までの３桁の数
字をとる。一方、メソッドは以下のように記述する。監
視情報内で共通のメソッドとして、起動する画面名称の
入力（！get_起動指示）、操作モードの入力（get_操作
モード）、表示指示の出力（put_表示指示）、指示欄の
出力（put_指示欄）があり、工程状態変更情報だけの固
有の属性としてエリアの入力（get_エリア）、設備変更
の入力（get_設備変更）などがある。ここで、メソッド
の前に「！」がついている場合は入出力の対象となるデ
ータが更新された場合に自動的に起動される処理である
ことを示す。例えば、「！get_起動指示」は、名称とい
う属性の値が更新されたことをトリガとしてその値の入
出力処理を開始する。また、メソッドの右側の括弧内は
引数を示し、処理に必要な情報あるいは処理結果の受け
渡しのために使用する。図１０は状態情報およびタイマ
ー情報の例を示す。本例の状態表示業務では、状態情報
を周期的に参照し、変更があった場合に情報を取り込ん
で表示する。そこで、予め定めた時間経過後にこの業務
処理を起動させるためにタイマーを用いている。また、
状態が更新されているか否かを判定するために、状態情
報に更新識別子を設けている。

【００１８】図１１は、図９と図１０に示した４つの情
報部品の挙動を示す状態遷移図である。円形の枠で囲ま
れた部分は外部からの情報入力に基づく処理あるいは外
部への情報出力のための処理である。外部との入出力
は、各情報部品に設定したメソッドを介して行われ、破
線矢印で示している。例として、工程情報変更画面の挙
動を詳細に説明する。 手順７０１：“get_起動指示”というメソッドにより、
状態変更業務に対して、操作員から状態表示画面の表示
を指示されたことを伝える。 手順７０２：“put_表示指示”により、状態変更業務か
ら画面情報を入力しそれを表示する。そして、“get_操
作モード”により、状態変更業務に対して、操作員から
受付モードへの移行を指示されたことを伝える。 手順７０３：“put_操作モード”により、状態変更業務
から操作モードの変更指示を入力し受付モードに移行す
る。そして、“get_エリア”により、状態変更業務に対
して、操作員からエリアの予約を指示されたことを伝え
る。 手順７０４：“put_エリア予約結果”により、状態変更
業務から予約結果がＯＫであるという回答を入力した場
合、それを画面に表示する。そして、“get_変更”によ
り、状態変更業務に対して、操作員から状態の変更を指
示されたことを伝える。 手順７０５：“put_エリア予約結果”により、状態変更
業務から予約結果がＮＧであるという回答を入力した場
合、それを画面に表示する。そして、手順７０３に戻
る。 手順７０６：“put_状態変更結果”により、状態変更業
務から変更結果がＯＫであるという回答を入力した場
合、それを画面に表示する。そして、手順７０２に戻
る。 手順７０７：“put_状態変更結果”により、状態変更業
務から変更結果がＮＧであるという回答を入力した場
合、それを画面に表示する。そして、手順７０４に戻
る。

【００１９】（Ｃ）次に、図１の定型処理モデル設定
（１０３）の処理を説明する。図１２および図１３は、
画面処理、上位インタフェース処理、下位インタフェー
ス処理などの定型的な処理を対象として、その処理仕様
を定義するための部品を示したものである。先にも述べ
たように、これを定型処理モデルとよぶ。定型処理モデ
ルは大きく２つに分類できる。一つは、入力情報の値、
型などを変換して出力情報を算出する処理である（図１
２）。他の一つは、入力情報の値を予め定めた規則によ
り、判定したり分類したりする処理である（図１３）。
前者の変換処理には、さらに、四則演算、型変換、フォ
ーマット変換、文字列操作などがある。各々の処理に対
して、表に示すような仕様書の記述形式に近い記法を設
定する。例えば、図１２の型変換では、文字型のコイル
番号を整数型のコイル番号に変換し、整数型のコイル番
号を文字型のコイル番号に変換することを示す。また、
フォーマット変換では、製品コードを、文字型の種別と
いう変数と、整数型の日付けという変数等に変換して格
納することを示し、また、文字型の設備Ｎoと文字型の
指示等を結合して制御データという変数に格納すること
を示す。また、文字列分離では、製品コードの上桁を種
別という変数に格納し、設備コードの下５桁を位置とい
う変数に格納することを示す。さらに、文字列結合で
は、種別という２桁の文字列と向け先という３桁の文字
列を結合して搬送コードという変数に格納することを示
す。

【００２０】後者の判定処理には、上下限チェック、デ
ータ値の分類などの処理がある。上下限チェック処理で
は、上限値と下限値を与え、判定結果とその戻り値との
対応を記述する。例えば、図１３のデータ値チェックで
は、日付という変数の値が０より小さいか、３１よりも
大きい場合は設定誤りであり、０ならば未設定であると
判定する。データ値の分類処理では、その分類方法をデ
ィシジョンテーブル形式で記述する。すなわち、同図に
示すように、横軸に入力情報の値を、縦軸に出力情報の
値をとり、分類条件をマトリクス上に丸印で示す。丸が
横軸上に複数個並んだ場合は条件の連接を示す。例え
ば、図１３のディシジョンテーブルでは、設備状態が
「故障」ならば最優先で表示色を赤にする。それ以外
で、設備状態が「稼働」で製品有無が「無し」ならば表
示色を黄色とする。以降同様に優先順位に従って表示色
を判定する。

【００２１】（Ｄ）次に、以上に述べた部品群（入出力
情報モデル、定型処理モデル）を前提として、図１の業
務入出力モデルカスタマイズ（１０４）および外部イン
タフェース仕様設計（１０５）における、業務の入出力
モデルのカスタマイズと外部入出力インタフェースの設
計方法を、図１４〜図１８を用いて説明する。図１４
は、入出力モデルをカスタマイズし、外部入出力インタ
フェースを定義する一連の設計手順を示したものであ
る。本発明によるシステム開発は、既に述べたように、
対象とするシステムの業務処理の機能を、その入出力情
報に着目して定義する。すなわち、「個々の業務でどん
な情報をいつ入力し出力するかを定義する」ことを中心
として設計を進める。以下に、その詳細な設計手順を説
明する。 手順９０１：各業務処理について、その機能を入力情報
と出力情報という形で明かにする。入出力情報が各々複
数個ある場合は、その業務をさらにサブ業務に分割する
ことにより、各サブ業務の入出力情報を明かにする。 手順９０２：前記で明かにした入出力情報に基づき、業
務入出力モデルを対象システム向けにカスタマイズす
る。すなわち、データ項目の変更、追加、削除と、それ
に伴うメソッドの作成を行う。 手順９０３：各業務処理について、イベントおよびデー
タの入出力をトリガとした状態遷移モデルを作成する。
すなわち、ある情報の入力とそれに基づく処理、あるい
は、ある処理と結果の出力を１つの単位として状態を設
定し、それらの遷移関係を定義する。 手順９０４：各状態において、入出力モデルの情報のど
のデータ項目を入力または出力するのかを、予め定めた
メソッドにより定義する。

【００２２】図１５は、ある対象分野の工程監視業務の
うち、工程状態変更機能について、イベントおよびデー
タの入出力をトリガとした状態遷移を示したものであ
る。角の丸い四角形で示された部分は先に述べた入出力
情報部品である。円形の枠で囲まれた部分は外部からの
情報入力に基づく処理あるいは外部への情報出力のため
の処理である。円形枠が入れ子になっている部分は処理
の階層関係を示す。例えば、エリア予約処理における入
れ子は、この処理がエリア受付、予約依頼、ＯＫ通知、
ＮＧ通知の各処理により構成されることを示す。また、
実線の矢印は処理の制御の流れを示し、破線の矢印は情
報の流れを示す。破線矢印に記述された番号は、下表に
おいて、情報入出力の際に利用する操作関数を示す。さ
らに、表中の関数の前に記された「！」は、その関数で
情報を入力することにより処理が開始されること、すな
わち、起動イベントの入力であることを示す。図１６に
図１５の入出力の仕様を入出力処理内容とその具体的な
記述方法（メソッド）の一覧として示しておく。例え
ば、図１５の＃１は状態変更画面指定を意味し、具体的
には「変更画面．！get_起動指示」と記述されることを
意味している。図１７は工程状態表示機能の状態遷移を
示したものである。図１８は図１７の入出力の仕様を入
出力処理内容とその具体的な記述方法（メソッド）の一
覧として示したものである。例として、図１５の状態変
更業務の状態遷移を詳細に説明する。

【００２３】手順１００１：工程状態変更画面から“状
態変更画面指定”イベントを取り込み、そのタイミング
で状態変更業務を開始する。まず、入力したイベントが
何であるかを解釈した後、工程状態変更画面に対して
“状態変更画面表示”情報を出力する。前者の情報の入
力は、図９の工程状態変更画面のメソッドである“get_
起動指示”で行い、後者の情報の出力は、“put_表示指
示”で行う。状態遷移の入出力処理とメソッドとの対応
は図１６の表に示されている。“get_起動指示”はイベ
ント駆動であるから、それを明記するために記号「！」
を付ける。 手順１００２：工程状態変更画面から“指示欄設定要
求”情報を入力し、どの指示欄を入力可能とするかを決
定する。そして、工程状態変更画面に対して“指示欄設
定”情報を出力する。 手順１００３：工程状態変更画面から“エリア予約”指
示情報を入力する。 手順１００４：工程状態情報に対して“エリア予約依
頼”情報を出力し、指定されたエリア予約が可能かどう
かの判定を依頼する。 手順１００５：工程状態情報からの予約回答がＯＫの場
合は、工程状態変更画面に対して“ＯＫ表示情報”を出
力し、手順１００７に進む。 手順１００６:工程状態情報からの予約回答がＮＧの場
合は、工程状態変更画面に対して“ＮＧ表示情報”を出
力し、手順１００３に戻る。 手順１００７：工程状態変更画面から“状態変更”指示
情報を入力する。 手順１００８：工程状態情報に対して“状態変更依頼”
情報を出力し、指定されたエリア予約が可能かどうかの
判定を依頼する。 手順１００９：工程状態情報からの予約回答がＯＫの場
合は、工程状態変更画面に対して“ＯＫ表示情報”を出
力し、手順１００１に戻る。 手順１０１０：工程状態情報からの予約回答がＮＧの場
合は、工程状態変更画面に対して“ＮＧ表示情報”を出
力し、手順１００７に戻る。

【００２４】（Ｅ）次に、図１の内部処理仕様設計にお
ける、定型処理の設計方法を、図１９に従って説明す
る。前記の方法により、各業務ごとに、外部とやりとり
する情報の構造と入出力タイミングは既に定義されてい
る。ここでは、与えられた入力情報から出力情報を導出
するための変換仕様の定義方法を説明する。通常、定型
処理の仕様定義は、分野ごとに決められた記法を用いて
行う。例えば、工程監視業務における画面表示仕様は、
図１９に示すような表形式で仕様定義を行う。本表で
は、出力情報のデータ項目ごとに、入力情報源、属性
（型、桁数）、とりうる値の制約条件、入力データから
出力データへの変換方法などを記述する。この表を、図
１２、図１３で説明した部品と記法によりうめていく。
例えば、表の項目番号＃１の設備番号は、状態情報を変
換して生成され、文字型２桁のデータである。その変換
は、設備情報の中のデータ項目の１つである設備名称の
下２桁を、文字列分離部品により抽出して行う。また、
表の項目番号２の設備状態は、同じく状態情報を変換し
て生成され、色コードである。その変換方法はデータ値
分類部品である図１９中に示されたマトリクス図を用い
て行われる。すなわち、設備情報の中のデータ項目であ
る設備動作、設備処理の値に従って、色コードの値を分
類定義する。

【００２５】（Ｆ）次に、図１の機能検証性能評価（１
０７）における、設計結果の検証方法について、図２０
〜図２４を用いて説明する。既に述べたように、入出力
情報モデルとして、入出力情報の構造と操作メソッドを
定義した。また、操作メソッドを実行する際の個々の入
出力情報部品の挙動モデルも定義した。さらに、業務処
理の外部インタフェース仕様として、外部入出力をトリ
ガとする状態遷移を記述した。以上により、システム開
発に必要な仕様のうち、情報の授受に関する仕様は完全
に記述されたことになる。従って、システム全体のデー
タフローあるいはイベントフローを解析することが可能
となる。以下に、データフローあるいはイベントフロー
の検証方法を説明する。本例では、ペトリネットにより
検証モデルを記述し、そのツールにより解析あるいはシ
ミュレーションを行う方法を説明する。ただし、検証は
この方法に限定されるものではなく、例えば、オートマ
トン、ＧＰＳＳなどのモデル化手法を用いても同様の結
果が得られる。ペトリネットは、有向グラフの１つであ
り、プレースとトランジションという２種類のノードを
もつ。アークはプレースからトランジションを結ぶか、
あるいは、トランジションからプレースを結ぶ。グラフ
表現では、プレースは丸、トランジションは箱で表す。
計算機処理では、通常、トランジションにより処理過程
を示し、プレースにより処理の前提条件または後提条件
を示す。条件の成立はプレース内にトークンを置くこと
により表す。トランジションは、その入力プレースの全
てにトークンが存在するときに限り発火可能となる。そ
して、全ての入力プレースのトークンを取り去り、全て
の出力プレースにトークンを加える。システムの挙動
は、初期マーキングから上記の発火規則に従ってトーク
ンを移動させ、マーキングの変化を観察することにより
解析できる。ペトリネットの詳細な説明は、例えば、
「村田忠夫著、ペトリネットの解析と応用、近代科学社
刊、１９９３年」を参照のこと。

【００２６】図２０〜図２２は、外部インタフェースの
設計結果と入出力モデルの挙動モデルを、ペトリネット
に変換したものである。図２０は状態変更業務および工
程状態変更業務、図２１は状態表示業務、図２２は工程
状態表示画面、タイマー情報、工程状態情報に関連する
ものである。その変換規則は以下の通りである。図２３
のフローチャートに従って変換規則を説明する。 手順１５０１：状態遷移図の丸枠で囲まれた処理を、ペ
トリネットのトランジションに変換する。 手順１５０２：状態遷移図のアーク（実線矢印）を、ペ
トリネットのプレースに変換する。ただし、状態遷移図
の処理が分岐する（１つの処理から複数のアークが出
る）部分は、共通のプレースとする。また、状態遷移図
の処理が合流する（１つの処理へ複数のアークが入る）
部分も、共通のプレースとする。 手順１５０３：状態遷移のアークの起点に相当するトラ
ンジションと、先に設定したプレースをペトリネットの
アークで結ぶ。また、プレースとアークの終点となるト
ランジションもペトリネットのアークで結ぶ。 手順１５０４：状態遷移図の入出力アーク（破線矢印）
を、ペトリネットのプレースに変換する。 手順１５０５：状態遷移の入出力アークの起点に相当す
るトランジションと、先に設定したプレースをペトリネ
ットのアークで結ぶ。また、プレースとアークの終点と
なるトランジションもペトリネットのアークで結ぶ。 次に、以上の方法で自動生成した検証モデルに基づい
て、設計結果の妥当性を調べる方法を説明する。検証
は、初期イベントに相当するプレースにトークンをセッ
トし、そこからのトークンの動きを追うことにより行
う。例えば、工程状態変更業務の検証を行う場合、本例
では、図２０〜図２２の黒丸で示すように、全てのペト
リネットの一番上のプレースに初期トークンを配置して
おき、工程状態変更画面のペトリネットの一番上のプレ
ースを起点としたトークンの動きをトレースしていく。
また、ペトリネットの各トランジションに発火遅延時間
を設定することにより、応答性能、処理性能の評価を行
うことができる。

【００２７】（Ｇ）最後に、図１の設計仕様プログラム
展開（１０８）における、設計結果をプログラムコード
に展開する方法を説明する。まず、業務入出力モデルで
は、前記のように定義した結果のうち、情報構造はプロ
グラムのテーブルに展開し、メソッドはサブルーチンに
展開する。特に、オブジェクト指向言語の場合は、情報
構造とメソッドを合わせてオブジェクトとする。一方、
外部インタフェースは、設計時に定義したメソッドを用
いてコードに展開する。すなわち、次の手順に従って行
う（図２４）。 手順１６０１：個々の状態はサブルーチン化する。状態
遷移の階層関係は、サブルーチンの階層構造により記述
する。 手順１６０２：入出力部分は、対応するメソッドをコー
ルする。 手順１６０３：状態遷移部分は、分岐処理はｉｆ文、合
流処理はｇｏｔｏ文などを用いて記述する。 手順１６０４：入力時にイベント駆動の指定が有る場合
は、入力対象とする情報の更新時に該当する業務処理を
起動するようにする。これは、例えば、割り込み処理に
より実現する。 定型処理仕様のコード展開は、定型処理モデルの記法
を、部品に対応したサブルーチンに翻訳することで実現
する。そのコンパイラは、例えば、ＵＮＩＸの簡易コン
パイラ開発ツールであるｙａｃｃを用いて容易に開発で
きる。

【００２８】

【発明の効果】本発明によれば、以下の効果をあげるこ
とができ、システムの生産性を向上できる。 （１）ソフトウェア部品とそれに基づく開発システムお
よび開発方法を提供できるため、設計手順を標準化でき
ると共に、ソフトウェアの再利用性を向上できる。 （２）設計段階で機能と性能の確認を行えるため、設計
誤りによる手戻りがなくなり、設計、製作工数を削減で
きる。 （３）定型処理での仕様からプログラムコードへの自動
展開を行えるため、製作誤りを低減すると共に、製作工
数を削減できる。

【図面の簡単な説明】

【図１】本発明の情報制御システム開発方法を実現する
ためのツールの機能構成図である。

【図２】本発明の方法によるシステム開発手順を示す図
である。

【図３】業務類型の設定方法を示す図である。

【図４】業務類型の設定方法を示す図である（標準形類
型）。

【図５】業務類型の設定方法を示す図である（ＰＡ形類
型）。

【図６】業務類型の設定方法を示す図である（混合形類
型）。

【図７】業務類型の設定方法を示す図である（ＦＡ形類
型）。

【図８】業務類型モデルの例を示す図である。

【図９】業務入出力モデルの記述例を示す図である。

【図１０】業務入出力モデルの記述例を示す図である。

【図１１】業務入出力モデルの挙動モデルを示す図であ
る。

【図１２】定型処理の例（データ変換）を示す図であ
る。

【図１３】定型処理の例（データ判定）を示す図であ
る。

【図１４】業務入出力モデルのカスタマイズと業務外部
インタフェースの設計方法を示す図である。

【図１５】外部インタフェースの設計例を示す図であ
る。

【図１６】図１５の入出力仕様の記述方法を示す図であ
る。

【図１７】定型処理仕様の設計例を示す図である。

【図１８】図１７の入出力仕様の記述方法を示す図であ
る。

【図１９】工程監視業務における画面表示仕様の定義を
示す図である。

【図２０】検証モデルの例（状態変更業務、工程状態変
更画面）を示す図である。

【図２１】検証モデルの例（状態表示業務）を示す図で
ある。

【図２２】検証モデルの例（工程状態表示画面、タイマ
ー情報、工程状態情報）を示す図である。

【図２３】設計仕様から検証モデルへの展開方法を示す
図である。

【図２４】設計仕様からプログラムコードへの展開方法
を示す図である。

【符号の説明】

１０１：業務類型設定、１０２：業務入出力モデル設
定、１０３：定型処理モデル設定、１０４：業務入出力
モデルカスタマイズ、１０５：外部インタフェース仕様
設計、１０６：内部処理仕様設計、１０７：機能検証性
能評価、１０８：設計仕様プログラム展開、１０９：モ
デルデータベース、１１０：業務類型モデル、１１１：
業務入出力モデル、１１２：定型処理モデル

───────────────────────────────────────────────────── フロントページの続き (72)発明者 舩橋 誠壽 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 川嶋 一宏 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内

Claims (7)

【特許請求の範囲】
1. 【請求項１】 制御対象とするプラントからの情報を入
   力し、それに基づいて設定した複数の業務処理を、必要
   ならば業務間で情報を交換しながら実行し、予め定めら
   れた情報を生成してプラントに対して出力し、あるいは
   系内に蓄積し、あるいは系外に通信する情報制御システ
   ムの開発システムにおいて、 業務処理の機能と情報の流れを類型化して業務群と情報
   群の標準的な入出力関係を設定した業務類型モデルを生
   成する業務類型設定手段と、各業務処理の入出力情報構
   造とその操作方法を標準化して業務入出力モデルを生成
   する業務入出力モデル設定手段と、前記業務入出力モデ
   ルに基づいて入力情報を出力情報に変換するための定型
   的な処理仕様を設定して定型処理モデルを生成する定型
   処理モデル設定手段と、前記業務入出力モデルおよび定
   型処理モデルを対象システムに適合するように変更する
   変更手段と、変更した結果を自動的にプログラムコード
   に展開するプログラム展開手段を有することを特徴とす
   る情報制御システムの開発システム。
2. 【請求項２】 請求項１記載の情報制御システムの開発
   システムにおいて、前記変更手段は、外部からの情報入
   力あるいは外部への情報出力の処理仕様を定義する外部
   インタフェース仕様設計手段と、前記外部入出力仕様以
   外の内部処理仕様を定義する内部処理仕様設計手段とか
   らなることを特徴とする情報制御システムの開発システ
   ム。
3. 【請求項３】 請求項２記載の情報制御システムの開発
   システムにおいて、さらに、前記変更手段による変更結
   果に対して機能の検証および性能評価を行なう機能検証
   性能評価手段を有することを特徴とする情報制御システ
   ムの開発システム。
4. 【請求項４】 制御対象とするプラントからの情報を入
   力し、それに基づいて予め設定した複数の業務処理を、
   必要ならば業務間で情報を交換しながら実行し、予め定
   められた情報を生成してプラントに対して出力し、ある
   いは系内に蓄積し、あるいは系外に通信する情報制御シ
   ステムの開発方法において、 予め業務処理の機能と情報の流れを類型化し、各業務処
   理の入出力情報構造とその操作方法を標準化して業務入
   出力モデルとして蓄積し、該業務入出力モデルにより、
   各業務処理のうち、外部からの情報入力あるいは外部へ
   の情報出力の処理仕様を外部入出力仕様として定義し、
   また、前記業務入出力モデルに基づいて入力情報を出力
   情報に変換するための定型的な処理仕様を設定して定型
   処理モデルとして蓄積し、該定型処理モデルにより、前
   記の外部入出力仕様以外の内部処理仕様を定義すること
   を特徴とする情報制御システムの開発方法。
5. 【請求項５】 制御対象とするプラントからの情報を入
   力し、それに基づいて予め設定した複数の業務処理を、
   必要ならば業務間で情報を交換しながら実行し、予め定
   められた情報を生成してプラントに対して出力し、ある
   いは系内に蓄積し、あるいは系外に通信する情報制御シ
   ステムの開発方法において、 予め業務処理の機能と情報の流れを類型化し、各業務処
   理の入出力情報構造とその操作方法を標準化して蓄積
   し、各業務処理のうち、外部からの情報入力あるいは外
   部への情報出力の処理と、入力情報を出力情報に変換す
   るための内部処理とを分離して設計し、その設計結果に
   基づいて業務処理間の情報授受の仕様と内部処理仕様と
   を独立に検証することを特徴とする情報制御システムの
   開発方法。
6. 【請求項６】 制御対象とするプラントからの情報を入
   力し、それに基づいて予め設定した複数の業務処理を、
   必要ならば業務間で情報を交換しながら実行し、予め定
   められた情報を生成してプラントに対して出力し、ある
   いは系内に蓄積し、あるいは系外に通信する情報制御シ
   ステムの開発方法において、 予め業務処理の機能と情報の流れを類型化し、各業務処
   理の入出力情報構造とその操作方法を標準化して業務入
   出力モデルとして蓄積し、該業務入出力モデルにより、
   各業務処理のうち、外部からの情報入力あるいは外部へ
   の情報出力の処理仕様を定義し、その結果を自動的にプ
   ログラムコードに展開することを特徴とする情報制御シ
   ステムの開発方法。
7. 【請求項７】 制御対象とするプラントからの情報を入
   力し、それに基づいて予め設定した複数の業務処理を、
   必要ならば業務間で情報を交換しながら実行し、予め定
   められた情報を生成してプラントに対して出力し、ある
   いは系内に蓄積し、あるいは系外に通信する情報制御シ
   ステムの開発方法において、 予め業務処理の機能と情報の流れを類型化し、各業務処
   理の入出力情報構造とその操作方法を標準化して業務入
   出力モデルとして蓄積し、該業務入出力モデルに基づい
   て入力情報を出力情報に変換するための定型的な処理仕
   様を設定して定型処理モデルとして蓄積し、該定型処理
   モデルにより、外部入出力仕様以外の内部処理仕様を定
   義し、その結果を自動的にプログラムコードに展開する
   ことを特徴とする情報制御システムの開発方法。