JPH11203168A

JPH11203168A - ハードウェア併用制御仕様検証装置

Info

Publication number: JPH11203168A
Application number: JP10004560A
Authority: JP
Inventors: Soichi Matsui; 聡一松井; Shigefumi Mori; 重文森; Tadao Harashima; 忠雄原島
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 1998-01-13
Filing date: 1998-01-13
Publication date: 1999-07-30

Abstract

(57)【要約】【課題】ソフトウェアプログラムの上位概念とハード
ウェアを併用して制御仕様を検証する装置を得る。【解決手段】状態遷移図で記述された制御仕様の状態
変化をシミュレーションする状態遷移機械プログラムを
備えた計算機と、状態遷移機械プログラムからのハード
ウェア制御情報を受けて対応するハードウェア部分要素
を駆動制御する通信インターフェースとを備えて、入力
である制御仕様検証手続きに基づいて状態遷移図で記述
された制御仕様を順次動作させて制御仕様検証結果を得
るようにした。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ソフトウェア組
み込み製品のソフトウェア部分の開発に先立って部分的
なハードウェア要素を併用して正しい仕様を確定する装
置に関するものである。

【０００２】

【従来の技術】製品製作の順序としては、（１）設計仕
様の記述、（２）仕様の正しさの検証、（３）仕様に基
づくハードウェア、ソフトウェアの開発、（４）システ
ム試験、を経て、最終製品が確定する。この間に、上述
の工程間で手戻りがあり、この手戻りをできるだけ、初
期のまたは上流の段階で減らすことが高品質の製品を短
時間で生み出すの大切なこととされている。ソフトウェ
ア組み込み製品は、ソフトウェアとこれによって制御さ
れるハードウェアから構成される。これら両者の分担
は、まず最初に制御仕様に基づいて決められ、それぞれ
が機能分担して実現される。

【０００３】ところで、一般的には制御仕様は、自然言
語を主に用いて記述されるが、一部の制御仕様は、形式
的な記述図法を用いて記述される。この形式的な記述図
法の中に、状態遷移図がある。状態遷移図とは、製品が
取り得る状態と、その状態が移り変わる（状態遷移）た
めのイベントや条件、また、状態中での製品の振る舞い
を記述している。状態遷移図に関しては、その後の計算
機によるシミュレーションや解析が容易であり、組み込
み製品の制御仕様を記述するのに適したもである。ま
た、シミュレーションのために、この状態遷移図で記述
された制御仕様を表現する状態遷移機械プログラムが開
発されている。従って、製品の制御仕様を状態遷移図を
用いて記述すれば、この内容を計算機上で等価な状態遷
移機械プログラムで表現でき、計算機によって仕様の検
証を行うことができる。しかし、これはソフトウェアに
よるシミュレーションであり、実際のハードウェアを用
いた場合の微妙な出力変化までもシミュレーションはで
きない。

【０００４】例えば、空調機の場合、実際の風をハード
ウェアから吹き出させることを行わないと、空調機に要
求された快適性の機能仕様が妥当かという検証はできな
い。また、他の例として、洗濯機の場合、実際に洗濯槽
を回転させ、洗濯を行わないと、開発中の洗濯機の洗濯
物に及ぼす性能の検証はできない。上述のハードウェア
部分を全てソフトウェアで模擬する構成も考えられる
が、空調機の場合は風の流れ、洗濯機の場合は水の動き
といったハードウェアに付随する周囲環境を計算機上で
模擬することは大変困難な作業であり、また、その模擬
規模も大きくなる。従って、組み込み製品の機能仕様の
妥当性を検証する場合に、部分的にハードウェアは実物
を用いて、組み込みソフトウェア部分と併用して仕様検
証をすることが望ましい。従来は、この機能仕様の検証
は、仕様満たすソフトウェアが開発された後、この開発
されたソフトウェアと実際のハードウェア部分を組み合
わせて行い、この組み合わせ結果による検証によって機
能仕様に不具合がある場合には、再びソフトウェア開発
を行う。この組み合わせ作業により、製品の開発に時間
がかかっていた。

【０００５】例えば、特開平５−１０８４１１号公報の
制御システムのシミュレーション装置によれば、ハード
ウェア側を全てソフトウェアシミュレーションによって
ハードウェアと組み込みソフトウェアの協調システムを
シミュレートする装置が開示されている。しかし、この
装置も実際のハードウェアを用いてはいないので、ハー
ドウェア環境の正確な模擬ができない。

【０００６】

【発明が解決しようとする課題】上述のように、組み込
みソフトウェアを用いた製品の開発においては、最終的
には、ハードウェア部分を協調動作させないと製品仕様
の検証が終了できない。従来は、この試験をソフトウェ
ア部分の開発後に行うようにしていたので、製品開発ま
でに時間がかかるという課題があった。

【０００７】この発明は、上記の課題を解消するために
なされたもので、制御仕様をソフトウェアの上位概念で
ある状態遷移図で記述し、ハードウェア部分要素と協調
して検証することで、開発期間を短縮する装置を得るこ
とを目的とする。

【０００８】

【課題を解決するための手段】この発明に係るハードウ
ェア併用制御仕様検証装置は、状態遷移図で記述された
制御仕様の状態変化をシミュレーションする状態遷移機
械プログラムを備えた計算機と、状態遷移機械プログラ
ムからのハードウェア制御情報を受けて対応するハード
ウェア部分要素を駆動制御する通信インタフェースとを
備えて、入力である制御仕様検証手続きに基づいて状態
遷移図で記述された制御仕様を順次動作させて制御仕様
検証結果を得るようにした。

【０００９】また更に、状態遷移機械プログラムは、外
部からの状態更新信号があれば状態遷移をシミュレーシ
ョンするようにし、通信インタフェースは、ハードウェ
ア部分要素からの入力情報を受けて対応するハードウェ
ア状態更新信号として状態遷移機械プログラムに送信す
るようにした。

【００１０】また更に、通信インタフェースは、複数の
ハードウェア部分要素の駆動制御と、必要があれば複数
のハードウェア部分要素からの入力情報の送信を行い、
状態遷移機械プログラムとは１つの通信路を介して全て
の情報を送受信するようにした。

【００１１】また更に、制御仕様検証手続きは、結果の
期待値も入力しておき、状態遷移機械プログラムは、動
作させた制御仕様検証結果が結果の期待値と異なる場合
はＮＧ出力をさせるようにした。

【００１２】

【発明の実施の形態】実施の形態１．状態遷移図で記述
された制御仕様の状態変化をシミュレーションする状態
遷移機械プログラムを備えた計算機と、このプログラム
からのハードウェア制御情報を受けて対応するハードウ
ェア部分要素を駆動制御し、また、ハードウェア部分要
素からの入力情報をプログラム部分に送信する通信イン
タフェースを備えた制御仕様検証装置を説明する。図１
は、本実施の形態における制御仕様検証装置の構成図で
ある。図において、１は入出力装置であり、状態遷移図
で記述された制御仕様を入力し、また、その結果を規定
する制御仕様検証手続を入力し、後述の状態遷移機械プ
ログラムを備えた計算機からの出力結果である制御仕様
検証結果を表示するものである。２は計算機であり、以
下の要素から構成される。即ち、３の入力である状態遷
移図で記述された制御仕様を収めたファイル、４の入力
である制御仕様検証手続を収めたファイル、５の検証手
続変換処理プログラム、６の制御仕様検証実行ファイル
で、これは制御仕様検証手続ファイル４中の制御仕様を
検証手続変換処理プログラム５によって変換した計算機
が認識可能な手続である。７の状態遷移機械プログラ
ム、８の制御仕様検証結果を収めたファイルで、これは
状態遷移機械プログラムが制御仕様検証実行ファイル５
の実行結果を収めたものである。９の状態遷移機械の制
御情報管理処理で、これは状態遷移機械プログラム７が
発生するイベント毎に内部の状態を遷移させ、その変化
を基にハードウェア制御情報を更新するものである。１
０のハードウェア制御情報ファイルで、これは状態遷移
機械の制御情報管理処理９のハードウェア対応部分の結
果情報を記憶するファイルである。更に、１１の計算機
側制御情報通信処理部分で構成されている。

【００１３】ところで、制御仕様の確定までのフローを
図２に示す。制御仕様を検証して正しい制御仕様を確定
するまでには、ステップＳ１０１（以後、ステップの記
述を省略する）〜Ｓ１１２までを繰り返して最終的に確
定する。制御仕様の検証のために、制御仕様をＳＴＡＴ
ＥＣＨＡＲＴで記述する。状態遷移図は、種々の特徴が
あり、近来よく用いられるようになったが、この記述方
式の１つとして、ＳＴＡＴＥＣＨＡＲＴが有力である。
このＳＴＡＴＥＣＨＡＲＴは、オブジェクト指向方法論
の１つで、ＯＭＴ法と呼ばれる手法の中のモデルでも用
いられている方法である。ＳＴＡＴＥＣＨＡＲＴは、例
えば、ＤａｖｉｄＨａｒｅｌａｎｄＮａａｍａ
ｄ：ＴｈｅＳＴＡＴＥＭＡＴＥＳｅｍａｎｔｉｃｓ
ｏｆＳｔａｔｅｃｈａｒｔｓ，ｓｕｂｍｉｔｔｅｄ
ｆｏｒｐｒｂｌｉｃａｔｉｏｎ．（Ｒｅｖｉｓｅｄ
ｖｅｒｓｉｏｎｏｆ “ＴｈｅＳｅｍａｎｔｉｃｓ
ｏｆＳｔａｔｅｃｈａｒｔｓ”，Ｔｅｃｈ．Ｒｅｐｏ
ｒｔ，ｉ−Ｌｏｇｉｘ，Ｉｎｃ．（１９８９））の文献
で紹介されていて、ＳＴＡＴＥＭＡＴＥという商品で実
売されている。このＳＴＡＴＥＣＨＡＲＴは、従来の状
態遷移図に階層性及び並行性の概念を取り入れているの
で、大規模なシステムを記述することもでき、更に、そ
の文法や意味論に関しても研究が進んでいる。また、更
に、計算機上でＳＴＡＴＥＣＨＡＲＴを用いてシステム
の制御仕様記述すると、これを等価な状態遷移機械プロ
グラムに変換する手法も既に開発されている。従って、
本実施の形態において、制御仕様をＳＴＡＴＥＣＨＡＲ
Ｔで記述すると、計算機がこれと等価な状態遷移機械プ
ログラム７に変換してくれる。また、この制御仕様を検
証するために、Ｓ１０２で制御仕様検証手続を記述入力
する。

【００１４】図３は、ＳＴＡＴＥＣＨＡＲＴの例を示す
図である。図１のＳ１０３で、計算機２は制御仕様検証
手続ファイル４を検証手続変換処理プログラムにより制
御仕様検証実行ファイル６に変換する。同様に、Ｓ１０
４でＳＴＡＴＥＣＨＡＲＴで記述された制御仕様を等価
な状態遷移機械プログラム７に変換する。更に、そのプ
ログラムによってＳ１０５で計算機２は、制御仕様検証
実行ファイル６に基づいて、状態遷移機械プログラム７
を実行して制御仕様検証結果ファイル８を得る。この制
御仕様検証結果ファイル８を、例えば、入出力装置１で
出力して、Ｓ１０６で制御仕様結果を確認する。制御仕
様検証結果に誤りがあれば、Ｓ１０８でＳＴＡＴＥＣＨ
ＡＲＴで記述された制御仕様を修正し、再び同じ処理を
繰り返す。Ｓ１０７で制御仕様検証結果に誤りがなくな
ると、例えば、通信インタフェース装置１２を協調動作
させ、Ｓ１０９で制御仕様の妥当性を確認する。通信イ
ンタフェース装置１２は、上述のように、計算機２とハ
ードウェア装置１６との間の入出力装置を行うものであ
り、以下の要素から構成される。即ち、１３のハードウ
ェア側制御情報通信装置と１４のハードウェア制御情報
ファイルと１５のハードウェア駆動装置から構成され
る。図１の構成による具体的な動作は後に詳述するが、
この併用動作により、Ｓ１１０で仕様の妥当性に問題が
ある場合は、Ｓ１１１で再びＳＴＡＴＥＣＨＡＲＴで記
述された制御仕様を修正し、これに基づいて、Ｓ１１２
で計算機２が状態遷移機械プログラムに変換して、制御
仕様検証実行ファイル６を順次実行して制御仕様検証結
果ファイル８を得る。最終的に、Ｓ１１０で仕様の妥当
性に問題がなければ、そこで制御仕様が確定する。以
下、具体的な製品に基づいて、装置の動作を説明する。

【００１５】図４は、計算機２が行う主として状態遷移
機械プログラム７部分が行う処理フローチャートの図で
ある。図５は、通信インタフェース装置１２が行う処理
フローチャートの図である。図６は、図１の構成を具体
的にハードウェア要素部分として空調機の室内機を用い
た場合の構成図である。また、図７は、以下に説明する
入力としての検証前のＳＴＡＴＥＣＨＡＲＴの例を示す
図である。図８は、ＳＴＡＴＥＣＨＡＲＴに付随して入
力される空調機のリアクションの例を示す図である。計
算機２の状態遷移機械プログラム７は、図７のＳＴＡＴ
ＥＣＨＡＲＴと図８の空調機のリアクションに基づい
て、これを模擬し、ＳＴＡＴＥＣＨＡＲＴ上で記入され
ている電源ＯＮ、電源ＯＦＦなどのイベントを全て状態
遷移機械プログラムで発生させる。

【００１６】図９は、制御仕様検証手続ファイルの例を
示す図である。図に示すように、例えば、図７のＳＴＡ
ＴＥＣＨＡＲＴで示される各種の運転モードの確認、リ
セット、電源ＯＮ、異常発生のようにイベントによる遷
移をそれぞれ表示確認をしたり、電源ＯＮの運転モード
の状態の確認を指定している。即ち、（１）初期の状態から電源をＯＮにすることで、運転モ
ードが「正常運転中」になり、異常を発生させることで
運転モードが「異常運転中」になり、リセットすること
で運転モードが「停止中」になることを確認するもので
ある。（２）（１）に続いて、電源をＯＮすることで運転モー
ドが「正常運転中」になり、異常を発生させることで運
転モードが「異常運転中」になり、電源をＯＦＦするこ
とで運転モードが「停止中」となることを確認するもの
である。図９の制御仕様検証手続ファイル４は、開始、
終了宣言部分の追加と以下のキーワードが変換される
と、図１０ないし図１２に示される制御仕様検証実行フ
ァイル６に変換される。即ち、表示（Ｘ）−〉ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘Ｘ’，‘＝’，Ｘ，‘＼ｎ’）；確認（ＤＡＴ，ＣＯＭＰ＿ＤＡＴ）−〉ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘＼ｎ＊＊’，‘ＤＡＴ’，‘ＫＡＫＵＮＩＮ＊＊＼ｎ’）；ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘ＤＡＴ’，‘＝’，ＤＡＴ，‘＼ｎ’）；ＩＦ（ＤＡＴ＝ＣＯＭＰ＿ＤＡＴ）ＴＨＥＮＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘／＊＊＊＊＊Ｏ．Ｋ．＊＊＊＊＊／＼ｎ’）；ＥＬＳＥＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘／＊＊＊＊＊Ｎ．Ｇ．＊＊＊＊＊／＼ｎ’）；ＥＮＤＩＦ；ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘＼ｎ’）；

【００１７】試験−〉ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，［ＴＥＳＮｏ．‘ＮＯ’，‘Ｊ＼ｎ’）；電源ＯＮ−〉ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘／＊＊＊＊＊ＰＯＷ＿ＯＮ＊＊＊＊＊／＼ｎ＼ｎ＼’）；ＰＯＷ＿ＯＮ；ＧＯＳＴＥＰｓｔｅｐ＿ｃｏｕｎｔ；電源ＯＦＦ−〉ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘／＊＊＊＊＊ＰＯＷ＿ＯＦＦ＊＊＊＊＊／＼ｎ＼ｎ＼’）；ＰＯＷ＿ＯＦＦ；ＧＯＳＴＥＰｓｔｅｐ＿ｃｏｕｎｔ；リセット−〉ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘／＊＊＊＊＊ＲＥＳＥＴ＊＊＊＊＊／＼ｎ＼ｎ＼’）ＲＥＳＥＴ；ＧＯＳＴＥＰｓｔｅｐ＿ｃｏｕｎｔ；異常発生−〉ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘／＊＊＊＊＊ＡＢＮＯＲＭ＊＊＊＊＊／＼ｎ＼ｎ＼’）ＲＥＳＥＴ；ＡＢＮＯＲＭ＿ＥＶ；ＧＯＳＴＥＰｓｔｅｐ＿ｃｏｕｎｔ；

【００１８】この実行ファイルに記述されているコマン
ドには、以下の意味がある。（ａ）ＧＯＳＴＥＰｓｔｅｐ＿ｃｏｕｎｔ；ｓｔｅ
ｐ＿ｃｏｕｎｔ；分だけ状態遷移を実行させる。（ｂ）ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，文字列ｏｒ変数）ｏｕｔ＿ｄａｔ（制御仕様検証結果ファイル）に文字列
または変数の値を書き込む。（ｃ）ＩＦ条件文ＴＨＥＮコマンド１ＥＬＳＥ
コマンド２ＥＮＤＩＦ条件文が真の時はコマンド１を、偽の時はコマンド２を
実行する。（ｄ）ＰＯＷ＿ＯＮ，ＰＯＷ＿ＯＦＦ，ＡＢＮＯＲＭ＿
ＥＶ，ＲＥＳＥＴそれぞれ電源ＯＮ、電源ＯＦＦ、異常発生、リセットイ
ベントの発生。

【００１９】検証作業は、上記のコマンドの組み合わせ
で実行され、典型的な検証作業は、次のステップで実行
される。（１）（ｄ）のイベント発生コマンドを発行し、状態遷
移機械プログラムに対し、電源ＯＮ、電源ＯＦＦなどの
イベントを発生させる。（２）（ａ）を使用して、状態遷移機械プログラムに対
し、状態遷移を起こさせ、状態を変化させる。（３）検証したいデータ（変数）が期待値と同じかを
（ｃ）を使用して比較し、期待値と同じ（検証結果が正
しい）場合は、（ｂ）を用いて制御仕様検証結果ファイ
ルに／＊＊＊＊＊ＯＫ＊＊＊＊＊／を表示し、期待値と
異なる（検証結果が正しくない）場合は、（ｂ）を用い
て制御仕様検証結果ファイルに／＊＊＊＊＊ＮＧ＊＊＊
＊＊／を表示する。（４）その他、適宜（ｂ）を使用して、データを制御仕
様検証結果ファイルに書き込む。

【００２０】図９，図１０の例の場合、試験（１．１）；電源ＯＮ；確認（運転モード，‘正常運転中’）；の部分は、試験（１．１）が、ＷＲＩＴＥ（ｏｕｔ＿ｄ
ａｔ，［ＴＥＳＮｏ．‘，’１．１‘，’］＼ｎ’）
に変換され、これが実行されると、制御仕様検証結果フ
ァイルに、［ＴＥＳＮｏ．１．１］を書き込む。電源
ＯＮは、ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘／＊＊＊＊＊ＰＯＷ＿ＯＮ＊＊＊＊＊／＼ｎ＼ｎ’）；ＰＯＷ＿ＯＮ；ＧＯＳＴＥＰｓｔｅｐ＿ｃｏｕｎｔに変換され、こ
れが実行されると、電源ＯＮ（ＰＯＷ＿ＯＮ）のイベン
トが実行され、ｓｔｅｐ＿ｃｏｕｎｔ（３０）だけ状態
遷移機械プログラムがステップ実行される。

【００２１】更に、確認（運転モード，‘正常運転
中’）は、ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘＼ｎ＊＊’，‘ＲＵＮ＿ＭＤ’，‘ＫＡＫＵＮＩＮ＊＊＼ｎ’）；ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘ＲＵＮ＿ＭＤ’，‘＝’，ＲＵＮ＿ＭＤ，‘ ＼ｎ’）；ＩＦ（ＲＵＮ＿ＭＤ＝‘ＮＯＲＭ＿ＲＵＮ’）ＴＥＨＮＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘／＊＊＊＊＊ＯＫ＊＊＊＊＊／＼ｎ’）；ＥＬＳＥＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘／＊＊＊＊＊ＮＧ＊＊＊＊＊／＼ｎ’）；ＥＮＤＩＦ；ＷＲＩＴＥ（ｏｕｔ＿ｄａｔ，‘＼ｎ’）に変換され、
これが実行されると、制御仕様検証結果ファイルに、＊
＊ＲＵＮ＿ＭＤＫＡＫＵＮＩＮ＊＊、ＲＵＮ＿ＭＤ＝
運転モードの値（ＮＯＲＭＲＵＮ）が書き込まれ、運
転モードの値がＮＯＲＭ＿ＲＵＮの場合は、／＊＊＊＊
＊ＯＫ＊＊＊＊＊／が、運転モードの値がＮＯＲＭ＿Ｒ
ＵＮ以外の場合は、／＊＊＊＊＊ＮＧ＊＊＊＊＊／が、
制御仕様検証結果ファイルに書き込まれる。

【００２２】同様に、図１０ないし図１２の制御仕様検
証実行ファイルに従って、ＳＴＡＴＥＣＨＡＲＴで記述
された仕様から変換された状態遷移機械プログラムを実
行すると、図１３のような仕様検証結果ファイルが出力
される。図１３より、最後の検証結果が正しくない（Ｎ
Ｇ）が判る。これは、電源をＯＦＦしても運転モードが
「停止中」にならなかったためである。この原因を分析
すると、電源ＯＦＦのイベントが「正常運転中」の状態
からでているためであるということが判る。設計者の本
来意図は、「運転中」の状態から電源ＯＦＦのイベント
が発生すると常に「停止中」になるというものであり、
これに基づいて、制御仕様検証手続ファイルは作業され
ていたが、この意図通りにＳＴＡＴＥＣＨＡＲＴが記述
されていなかった。検証結果が異常になってしまってい
た。分析の結果より、図７のＳＴＡＴＥＣＨＡＲＴを、
図１４のように修正を行った。ここで、上記と同様に、
図９の制御仕様検証実行ファイルに従って、図１４のＳ
ＴＡＴＥＣＨＡＲＴで記述された仕様から変換された状
態遷移機械プログラムを実行すると、図１５のような仕
様検証結果ファイルが出力される。この結果、図１４の
ＳＴＡＴＥＣＨＡＲＴで記述された仕様は、図９の制御
仕様検証手続ファイルの内容に関しては、全て正しいこ
とが判る。

【００２３】続いて、空調機が要求されている機能仕様
の妥当性を満たすかの検討を行う。例えば、冷房運転中
に空調機の風向を制御するフラップ部分に露がついては
製品として好ましくないため、これを防止する露付防止
機能が必要であったとする。フラップ部分に露が付きや
すくなる条件としては、条件１がある。そこで、条件１
がＡ分間継続すると保護が働き、フラップの位置を、通
常（保護なし）の時の位置をＦ０からＦ１に変更させ、
更に、条件１が満たされなくなると、保護なしの状態に
なるという露付防止機能が仕様に存在していたとする。
この内容をＳＴＡＴＥＣＨＡＲＴで記述すると、図１４
になる。そこで、この機能の妥当性としては、（１）この露付防止機能を実際実行することで、露が付
かないか。（２）機能が働く条件として、条件１は妥当か。計算機上でこの機能の妥当性の検証を行うには、空調機
の周辺の温度や湿度及びフラップの表面温度などをシミ
ュレートする必要がある。しかし、このシミュレートを
精度よく行うことは、大変困難である。このため、実際
の空調機の室内機を運転して、これを検証することが現
実的であり必要である。そこで、フラップに露がつきや
すい室温及び湿度の環境で実際の室内機を連続運転し、
フラップに露が付かないかを検証作業者が定期的に観察
した。この結果、保護中のフラップ位置Ｆ１では露が付
く可能性があることが判り、もう少し値が大きいＦ２の
方が露が付きにくいのではないかという代案がでた。こ
の場合、図１６のＳＴＡＴＥＣＨＡＲＴの「露保護中」
状態中のリアクションの記述のＦ１をＦ２に変更し、こ
れを状態遷移機械に変換するだけで、この案を試行する
ことが即座に可能になり、再び連続運転を行って妥当性
を検討した結果、Ｆ２の方が好ましいことが判った。

【００２４】また、値を変更するだけでなく、制御方法
自体の変更もこの環境を用いれば容易に行える。例え
ば、先ほどの露付防止機能において、保護待ちの条件は
条件１のままにておいて、保護の解除としては条件２を
追加した方がよいのではないかという代案がでた。この
条件を追加することで、保護の働く時間が短くなる。こ
れは、空調機としてはできるだけ保護が働かないまま、
運転を続けることが好ましいためである。この条件に制
御方法を変更しても露が付かないか検証し、露が付かな
ければ、この方式に変更した方がよい。そこで、この仕
様になるように、ＳＴＡＴＥＣＨＡＲＴの図１６を図１
７に変更し、上記と同様、図１７を状態遷移機械に変換
して、この代案を試行した。よりよい製品を作成するた
めには、このような値や制御方法を変更しながら、仕様
の検討をできるだけ多く行うことが好ましいが、仕様の
変更の度に、これに対応したプログラムコードを変更す
るといった作業は、一般的に時間がかかり、誤りも発生
しやすい。そこで、本制御仕様検証装置を用いれば、Ｓ
ＴＡＴＥＣＨＡＲＴで仕様を記述しているため、このプ
ログラムコードの修正が不要になる。また、ハードウェ
ア要素を併用しているため、空調機に要求されている機
能仕様の妥当性が満たされれば、検証処理は終了する。

【００２５】

【発明の効果】以上のように、この発明によれば、ソフ
トウェアプログラムの上位概念である状態遷移図とハー
ドウェア部分要素を併用して制御仕様を検証するように
したので、部分的に実物を用いた微妙で正しい検証が行
え、また、開発期間を短縮する効果がある。

【図面の簡単な説明】

【図１】この発明の実施の形態１におけるハードウェ
ア併用制御仕様検証装置の構成図である。

【図２】本発明の実施の形態１における検証処理のフ
ローチャート図である。

【図３】実施の形態１における入力のＳＴＡＴＥＣＨ
ＡＲＴ図の例を示す図である。

【図４】図１における計算機が行う処理フローチャー
ト図である。

【図５】実施の形態１における通信インタフェース装
置が行う処理フローチャート図である。

【図６】実施の形態１における空調機の室外機をハー
ドウェア部分要素として用いた構成図である。

【図７】入力の修正前のＳＴＡＴＥＣＨＡＲＴ図であ
る。

【図８】空調機のリアクションの例を示す図である。

【図９】制御仕様検証手続ファイルの例を示す図であ
る。

【図１０】制御仕様検証実行ファイルの例を示す図で
ある。

【図１１】制御仕様検証実行ファイルの例を示す図で
ある。

【図１２】制御仕様検証実行ファイルの例を示す図で
ある。

【図１３】修正前の制御仕様検証結果ファイルの例を
示す図である。

【図１４】入力の修正後のＳＴＡＴＥＣＨＡＲＴ図で
ある。

【図１５】修正後の制御仕様検証結果ファイルの例を
示す図である。

【図１６】原案の露付防止機能のＳＴＡＴＥＣＨＡＲ
Ｔの例を示す図である。

【図１７】代案としての露付防止機能のＳＴＡＴＥＣ
ＨＡＲＴの例を示す図である。

【符号の説明】

１入出力装置、２計算機、３状態遷移図で記述さ
れた制御仕様、４制御仕様検証手続ファイル、５検
証手続変換処理プログラム、６制御仕様検証実行ファ
イル、７状態遷移機械プログラム、８制御仕様検証
結果ファイル、９状態遷移機械の制御情報管理処理
部、１０ハードウェア制御情報ファイル、１２通信
インタフェース装置、１３ハードウェア側制御情報通
信装置、１４ハードウェア制御情報ファイル、１５
ハードウェア駆動装置、１６ハードウェア装置。

Claims

【特許請求の範囲】

【請求項１】状態遷移図で記述された制御仕様の状態
変化をシミュレーションする状態遷移機械プログラムを
備えた計算機と、上記状態遷移機械プログラムからのハードウェア制御情
報を受けて対応するハードウェア部分要素を駆動制御す
る通信インタフェースとを備えて、入力である制御仕様検証手続きに基づいて上記状態遷移
図で記述された制御仕様を順次動作させて制御仕様検証
結果を得るようにしたハードウェア併用制御仕様検証装
置。
【請求項２】状態遷移機械プログラムは、外部からの
状態更新信号があれば状態遷移をシミュレーションする
ようにし、通信インタフェースは、ハードウェア部分要素からの入
力情報を受けて対応するハードウェア状態更新信号とし
て上記状態遷移機械プログラムに送信するようにしたこ
とを特徴とする請求項１記載のハードウェア併用制御仕
様検証装置。
【請求項３】通信インタフェースは、複数のハードウ
ェア部分要素の駆動制御と、必要があれば複数のハード
ウェア部分要素からの入力情報の送信を行い、状態遷移
機械プログラムとは１つの通信路を介して全ての情報を
送受信するようにしたことを特徴とする請求項１記載の
ハードウェア併用制御仕様検証装置。
【請求項４】制御仕様検証手続きは、結果の期待値も
入力しておき、状態遷移機械プログラムは、動作させた制御仕様検証結
果が上記結果の期待値と異なる場合はＮＧ出力をさせる
ようにしたことを特徴とする請求項１記載のハードウェ
ア併用制御仕様検証装置。