JP2012194746A - 機能競合制御装置およびその方法 - Google Patents

Abstract

【課題】対象システムにおける機能競合を防止する。
【解決手段】機能仕様保持手段は、対象システムの機能と前記機能の出力との組を保持する。競合条件保持手段は、前記機能間の前記出力の組み合わせに基づく論理式を保持する。前記実行中機能保持手段は、実行中の機能である実行中機能のリストを保持する。前記待機機能保持手段は、待機中の機能である待機機能のリストを保持する。 前記待機機能実行可否判定手段は、前記待機機能保持手段により保持される待機機能について、前記待機機能と前記実行中機能との出力に基づき、前記論理式が充足されるかを判定し、充足されない場合は前記待機機能の実行指示を出力し、充足される場合は前記待機機能を実行しないことを決定する。
【選択図】図１

Description

本発明の実施形態は、複数の機能が並列で実行されるシステムにおける、機能競合制御装置およびその方法に関する。

システムにおいて複数の機能間の出力の組合せで、望ましくない事象が発生する機能競合という問題がある。機能競合を発生させないためには、各機能のプログラム上で、競合する他の機能が実行中の場合は、その機能を実行しない、という条件を記述する方法がある。

しかし、機能の数が多い場合や、機能ごとに別の開発者が並行開発する場合は他の機能との競合をチェックしきれず、このような条件の記述が漏れる可能性がある。また、システムにおける望ましくない事象自体は、機能の追加や変更によらず、永続的であることが多い。例えばエレベータシステムの場合、地震管制運転や火災時完成運転などさまざまな機能が追加されてきたが、ドアがあいたまま走行する戸開走行は、このような機能の追加・変更によらず不変である。このため、機能競合の排除のために、機能の実行段階で、予め定義された望ましくない事象を引き起こさないかどうかをチェックしてから実行するという方法が考えられる。

特許第3145992号 特許第3283561号

この機能競合を排除するという問題に対し、従来の技術としては、任意の二機能間の組み合わせについての同時実行可否を定義し、競合関係にある一方の機能が動作中には、他方の機能が、実行可能状態となった場合に実行を禁止することにより競合の発生を排除するものがある。また、同一の資源や制御対象への同時アクセスをチェックし排除する技術もある。

これらの従来の技術では、二機能から三機能以上に競合判定を行う機能の組み合わせを増やしたい場合に容易に対応できない、あるいは過剰に同時実行を抑制してしまう、という問題があった。

本発明は、機能の個数に拘わらず、機能競合の発生を容易に防止することを可能にした機能競合制御装置およびその方法を提供する。

本発明の一態様としての機能競合制御装置は、機能仕様保持手段と、競合条件保持手段と、実行中機能保持手段と、待機機能保持手段と、待機機能実行可否判定手段と、実行中機能更新手段と、待機機能保持手段とを備える。

前記機能仕様保持手段は、対象システムの機能と前記機能の出力との組を保持する。

前記競合条件保持手段は、前記機能間の前記出力の組み合わせに基づく論理式を保持する。

前記実行中機能保持手段は、実行中の機能である実行中機能のリストを保持する。

前記待機機能保持手段は、待機中の機能である待機機能のリストを保持する。

前記待機機能実行可否判定手段は、前記待機機能保持手段により保持される待機機能について、前記待機機能と前記実行中機能との出力に基づき、前記論理式が充足されるかを判定し、充足されない場合は前記待機機能の実行指示を出力し、充足される場合は前記待機機能を実行しないことを決定する。

前記実行中機能更新手段は、前記待機機能実行可否判定手段により実行指示が出された前記機能を前記実行中機能保持手段に追加し、実行の終了した前記実行中機能を前記実行中機能保持手段から削除する。

前記待機機能保持手段は、前記待機機能実行可否判定手段により実行指示が出された前記機能を前記待機機能保持手段から削除する。

本発明の実施形態に係る機能競合制御装置のブロック図である。 待機機能実行可否判定手段の動作の流れを示すフローチャートである。 競合発生有無の処理の説明図である。 競合発生有無の処理の説明図である。 競合解消手段が追加された機能競合制御装置のブロック図である。

以下、図面を参照しながら、本発明の実施形態を説明する。

（実施形態1）
図1に、本発明の実施形態に係る機能競合制御装置のブロック構成を示す。

機能仕様保持手段13は、対象システム（例えばエレベータシステム）内で独立に実行される機能の仕様についての情報（機能仕様情報）を保持する。具体的には、各機能について、
・ 機能ID
・ 機能の動作条件
・ 出力（機能の動作結果としての制御指令）
・ 実行優先度
を保持する。

機能仕様情報は、リレーショナルデータベース13に、上記のカラムを持つテーブルとして保持されることができる。

機能仕様入力手段11は、リレーショナルデータベース13への機能仕様情報の追加、変更、削除を行う。

競合条件論理式保持手段12は、対象システム内で起きてはいけない機能の出力の同時実行の論理的組み合わせを表現する競合条件を保持する。具体的に、競合条件論理式保持手段12は、
・ 競合条件論理式ID
・ 競合条件論理式（単に論理式とも称される）
を保持する。

競合条件論理式の記述例として、エレベータシステムにおける戸開走行を挙げる。

エレベータシステムで、機能Aはある動作条件で、出力としてドアを開ける制御指令openを出力するとする。機能Bはある動作条件で、出力としてかごを走行させる制御指令runを出力するとする。エレベータはドアが開いたまま走行（戸開走行）してはいけないから、openとrunの同時実行は、システムでおきてはいけない競合状態である。この競合を表現する競合条件論理式は、
open AND run
と記述される。

従来技術では、サービス論理競合管理表により、2機能の組み合わせについて実行可否を定義しているが、本実施形態では、機能の出力の望ましくない論理的組み合わせを競合条件論理式で定義する。

競合条件論理式は、リレーショナルデータベース13に、上記のカラムを持つテーブルとして保持されることができる。

競合条件論理式入力手段12は、リレーショナルデータベース13への競合条件論理式の追加、変更、削除を行う。

実行中機能保持手段21はシステムで実行中の機能（実行中機能）のIDのリスト（実行中機能IDリスト）を保持する。

ある待機機能が、待機機能の実行可否を判定する待機機能実行可否判定手段17により実行可と判定され、実行されると実行中機能IDリストに、その待機機能のIDが追加される。あるいは待機機能実行可否判定手段17が、その待機機能を実行可と判定した時点で、その待機機能のIDを追加してもよい。また、実行中の機能の処理が完了した時点で、その機能のIDが実行中機能IDリストから削除される。

待機機能保持手段22は、実行を待機している機能（待機機能）のIDのリスト（待機機能IDリスト）を保持する。ある待機機能が待機機能実行可否判定手段17により実行可と判定され、実行されると待機機能IDリストから、その待機機能のIDが削除される。あるいは待機機能実行可否判定手段17が、その待機機能を実行可と判定した時点で、その待機機能のIDを削除してもよい。

機能起動判定手段23は、外部環境についてのセンサーの計測値（環境情報）や、システム状態（システム変数の値）が動作条件を満たすと、起動すべき機能を決定し、当該機能を、待機機能保持手段22に追加する。

待機機能実行可否判定手段17は、上記の実行中機能IDリストと、待機機能IDリストと、機能仕様情報と、競合条件論理式を読み出す。待機機能実行可否判定手段17は、各待機機能について、その待機機能を、実行中機能と同時に実行した場合に、いずれかの競合条件論理式が充足されるかどうかをチェックする。いずれかの競合条件論理式が充足される場合は、その待機機能を実行不可と判定し、いずれの競合条件論理式も充足しない場合は、その待機機能を実行可と判定する。実行可と判定した機能について、当該機能の実行指示を対象システムに出力する。対象システムでは、実行指示された機能を実行する。

実行中機能更新手段18は、待機機能実行可否判定手段17により実行可と判定された機能を、実行中機能保持手段21に追加する。また実行が終了した機能を、実行中機能保持手段21から削除する。実行の終了の通知は、機能を実行した対象システムから受ける。

待機機能更新手段19は、待機機能実行可否判定手段17により実行可と判定された機能を、待機機能保持手段22から削除する。

待機機能実行可否判定手段17、実行中機能更新手段18および待機機能更新手段19の各機能は、CPU16によりプログラムを実行させることにより実現される。このプログラムは、CD-ROM、USBメモリー等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。この記録媒体は、着脱可能なものに限定されず、ハードディスク装置やメモリーなどの固定型の記録媒体でもよい。このプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。

実行中機能保持手段21および待機機能保持手段22は、メモリー20により実現される。メモリー20は、コンピュータ内蔵のメモリーでも良いし、脱着可能なメモリーでもよい。またはネットワークを介してアクセス可能なリモートの装置内のメモリーでもよい。

図2に、待機機能実行可否判定手段17が実行する、待機機能実行可否判定のフローを示す。

ステップS1では、実行中機能の出力を保持する実行中機能出力マップに、待機機能の出力を追加する。より詳細には、待機機能IDリストから、待機の機能IDを取得し、そのIDをキーとして、その機能の出力を、機能仕様情報から取得し、実行中機能出力マップに追加する。なお待機機能の取り出し順は、待機機能の優先度の高い順とすればよい。

ステップS2では、実行中機能出力マップ（実行機能の出力群）が、競合条件論理式を充足するかをチェックする。

ステップS3では、当該実行機能の出力群が、いずれの競合条件論理式も充足しなければ、その待機機能を実行可と判定する。待機機能実行可否判定手段17は、この時点で、その待機機能IDを、待機機能IDリストから削除し、実行中機能IDリストに追加してもよいし、対象システムへの実行指示が出された後、もしくは実際に対象システムでの実行が開始された時点で、この処理を行っても良い。

ステップS4では、当該実行機能の出力群が、いずれかの競合条件を充足するならば、その待機機能を実行不可と判定する。

ステップS2において行う競合発生有無のチェック方法について、詳細に説明する。

競合条件論理式は、出力のシンボルで構成される論理式である。具体的には、競合条件論理式は、出力のシンボルがANDやOR、あるいはシンボルの否定（¬）といった論理演算子で結合されたものである。

例えば、w、x、y、zをシステム内の機能の出力のシンボルとすると、
(w OR x) AND (y OR ¬z) （1）
というように、シンボルと論理演算子の組み合わせで、競合条件論理式を記述できる。

ところでこのような論理式は、加法標準形（Disjunctive normal form：DNF）に変形できる。加法標準形は、シンボルもしくはその否定（リテラルという）の論理積の論理和として表現された論理式である。

例えば、上記の論理式（1）の加法標準形は、
(w AND y) OR (w AND ¬z) OR (x AND y) OR (x AND ¬z) （2）
である。

ここで(w AND y)など、加法標準形に表れる、リテラルの積のみからなる項を最小項という。

加法標準形の論理式は、そのいずれかの最小項が真ならば、論理式自体も真となる。

例えば、(w AND y)が真ならば（つまりwとyがどちらも真ならば）、論理式（2）も真である。つまりwとyが同時に出力されると、競合が発生する。

以下では、この加法標準形の最小項を用いたビットマップにより、競合発生有無を効率的にチェックする方法について説明する。

[競合発生有無チェック時の競合条件論理式等のデータ形式]
競合条件論理式を加法標準形に変形し、全ての最小項を列挙する（図 3の“競合条件論理式（最小項）”を参照）。

システム内の出力の種類は有限個であるから、出力に番号を付け、番号順に整列することができる。各最小項について、バイナリベクトル（要素の値が0もしくは1）を対応付ける。バイナリベクトルの次元数は、システム内の全出力の個数である。具体的には、ある最小項にn番目の出力が含まれるならば、当該ある最小項に対応するバイナリベクトルのn番目の要素を1とし、n番目の出力が含まれないならば、n番目の要素を0とする。

例えばシステム内の出力が、y1、y2、y3、y4、y5、y6であるとすると、バイナリベクトルは6次元となり、最小項 y1 AND y2に対応するバイナリベクトルは、
(1, 1, 0, 0, 0, 0)
と表現できる。

また、最小項 y2 AND y4に対応するベクトルは、
(0, 1, 0, 1, 0, 0)
と表現できる。

このように各競合条件論理式（加法標準形）の各最小項のバイナリベクトルを競合条件ベクトルという。図 3に示すように、競合条件ベクトルの集合をP＝{Pi}（各Pi（i=1,2,…）が各競合条件論理式の最小項に対応する）と表す。

また、実行中機能IDリストの機能IDをキーとして、機能仕様保持手段13から、全ての実行中機能の全ての出力を取り出すことができる。取り出された全出力の組を、一つのバイナリベクトルで表現できる。このバイナリベクトルを実行中機能出力ベクトルという。図3に示すように、実行中機能出力ベクトル（唯一）をQと表す。

例えば、機能Aの出力がy1で、機能Bの出力がy2、y4で、機能Aと機能Bが実行中の場合、システム内では、y1、y2、y4が同時に出力されていることになる。この時、実行中機能出力ベクトルQは、
(1, 1, 0, 1, 0, 0)
となる。

待機機能IDリストの機能IDをキーとして、機能仕様保持手段13から、各待機機能の出力を取り出すことができる。各待機機能が実行された場合の出力を、バイナリベクトルにより表現できる。このバイナリベクトルを待機機能出力ベクトルという。待機機能毎に待機機能出力ベクトルが得られる。機能Cの出力がy3で、機能Dの出力がy5、y6の場合、
機能Cの待機機能出力ベクトル：(0. 0, 1, 0, 0, 0)
機能Dの待機機能出力ベクトル：(0. 0, 0, 0, 1, 1)
と表現できる。

図3に示すように、待機機能出力ベクトルの集合をR={Rj}（各Rj（j=1,2,…）が各待機機能の出力ベクトルに対応する）と表す。

[バイナリベクトルを用いた競合発生有無チェック方法]
ある待機機能を実行したときに競合が発生するかどうかをチェックするには、その待機機能を実行中機能と同時に実行した場合に、競合条件論理式のいずれかの最小項が充足されるかどうかを、チェックすればよい（これは上述したとおりである）。最小項はシンボルの積なので、以下のようにベクトルの論理和および比較により、簡単にチェックできる。

すなわち、待機機能実行可否判定手段17は、図4に示すように、各待機機能出力ベクトル（Rj）に対して、以下を行う。

1. 待機機能出力ベクトル（Rj）と実行中機能出力ベクトル（Q）の成分ごとの論理和をとることにより、対応する待機機能を仮に実行した場合の実行中機能出力ベクトル

を求める。

2. 実行中機能出力ベクトル

の成分の中で1である成分が、競合条件ベクトル（Pi）の成分を全て含むならば、実行中機能出力ベクトル

は競合条件ベクトル（Pi）を充足するので、待機機能出力ベクトル（Rj）に対応する待機機能は実行不可と判定する。

具体的には、

とPiとの成分ごとの論理積を求め、この論理積とPiとの成分ごとの論理差（排他的論理和）Sijをもとめ、この論理差Sijの成分が全てゼロかどうかをチェックすればよい。すべてゼロならば、実行不可である。

3. 排他的論理和の成分がすべてゼロであるとの条件が、どの競合条件ベクトルについても成立しないならば、待機機能出力ベクトル（Rj）に対応する待機機能を実行しても競合は発生しない。よって、当該待機機能は、実行可と判定する。

[競合の充足状況に応じた機能の実行可否判定]
ここで、Qの中の、いずれかの0の成分を1にした場合に、ある競合条件ベクトルRiを充足する場合は、その成分に対応する出力が実行されると競合が発生することを意味する。従って、その成分に対応する出力をもつ機能は、待機中か否かによらず、実行不可である。この場合、待機機能実行可否判定手段17は、当該機能に対して、待機中か否かによらず予め実行可否と判定しておくことにより、いざその機能が待機中になった時点で、上記1〜3の計算を行うことなく、高速に実行可否を判定することができる。

つまり実行中機能IDリストが更新されるごとに、実行中機能以外の機能について、競合条件論理式が充足されるかに応じて実行可否を判定して、当該機能のあるいは実行可否を示したリストを作成しておく。そして、実際に、待機機能について、実行可否を判定する際は、このリストに基づいて、判定を行う。これにより、高速な判定が可能となる。

[バイナリベクトルを用いない場合]
競合条件論理式や、機能の出力が、単にシンボルだけでなく、数値などを含む場合もありうる。たとえば、エレベータシステムの場合、かごを2階に移動させる制御指令として、go(2)などといった表現や、モーターの回転速度kを、ある値Lに設定する指令として、k = Lなどといった表現が考えられる。数値が連続値をとる場合は、競合条件論理式などを上記のように有限次元のバイナリベクトルでは表現できない。このような場合は、実行中機能の出力と、待機機能の出力が同時に実行された場合に、競合条件論理式を充足するかどうかを、自動定理証明技術（Satisfiabiliy Modulo Theory）を用いて、直接チェックすればよい。

たとえば、go(2) AND (k = L)
という論理式について、go(2)や(k = L)といった部分は、その内部にANDやORといった論理演算子を含まず、これ以上分解できないため、シンボルと同じくリテラルと考えてよい。従って、このような数値などを含む部分からなる競合条件論理式も、加法標準形に変形でき、最小項を列挙することができる。

（実施形態2：エレベータシステムのシステム内の機能競合）
本実施形態では、エレベータシステムにおける競合を例に、本システムの競合排除の動作を示す。

一般に、エレベータシステムには、洪水などによりエレベータの最下部（ピット）が浸水した場合、かごを特定の階に強制的に移動させ、特定階に到着後、ドアを自動的に開けるという、ピット浸水時運転がある。また、特定の階について、かご内での行き先指定を不可とするサービス階切り離し機能がある。

この例では、ピット浸水時運転時に、かごをk階に移動させるとする。またサービス階切り離し機能により、k階が不停止であるとする。かごがk階に到着すると、ドアを開くための戸開指令が出力されるが、これはサービス階切り離し機能により禁止される。

一般にエレベータは、戸開指令出力後、ドアが開いて、一定時間経つとドアが閉じ、戸閉完了を検知した時点で走行可能となる。この例では戸開指令出力後、ドアが開くことは無いので、このプロセスが実行されないため走行可能とならず、閉じ込めとなる。つまり、
・ 機能1：かごをk階に移動させる
・ 機能2：戸開指令を出力する
・ 機能3：k階を不停止とする
という3つの機能が競合して、閉じ込めが発生している。

ここで、機能1〜3の中の2機能のみが実行される場合には、競合が発生しないことを以下に示す。まず、機能1と2のみが動作し、機能3が動作していなければ、k階に到着後、ドアが開くので閉じ込めは発生しない。機能1と機能3のみが動作している場合は、戸開指令が出力されないので、かごはk階に到着後、別の階に移動できるため、閉じ込めは発生しない。

機能2と機能3のみが動作している場合は、k階には移動せず、走行中もしくは別の階に停止中に、戸開指令が出力されていることになる。走行中の戸開指令は、別の階（機能3によりk階には停止しないので）に到着後実行され、別の階に停止中の戸開指令はそのまま実行され、いずれの場合もドアは開くため、閉じ込めは発生しない。

従って、上記3つの機能による機能競合は、従来技術で用いられる2つの機能の組み合わせについての競合条件では排除できない（3つの機能用に装置を作り直す必要があり、対応が容易でない）ことが分かる。本実施形態ではどのような機能の個数でも競合を排除可能であり、以下では、上記3つの機能の実行による競合を排除する例を示す。

機能1の出力である、エレベータのかごをk階に移動させる制御指令をgo(k)とする。

機能2の出力である、k階での戸開指令をopen(k)とする。

機能3の出力である、ｋ階を不停止とする制御指令をnonstop(k)とする。

この時、機能1〜3による競合条件論理式Fは、
F = go(k) AND open(k) AND nonstop(k) （3）
と表現できる。

サービス階切り離し機能によりk階を不停止階に設定しているビルで、浸水が発生し、ピット浸水運転機能が起動する場合を考える。

サービス階切り離し機能（機能3）が実行されているので、実行中機能保持手段21に機能3が保持されている。

浸水の発生が検知されると、機能起動条件判定手段23により、機能1と機能2が待機状態として、待機機能保持手段22に格納される。

待機機能実行可否判定手段17は、機能1の実行可否を判定する。実行中である機能3と、待機中の機能1を同時に実行しても、その出力は競合条件論理式（3）を満たさないので、機能1は実行可と判定され、実行される。待機機能保持手段22から機能1が削除される。

ここで機能1の出力の制御指令go(k)は、かごがk階に着いたあと、別の階への移動指令が出力されるまで、実行中であるとする。このため、機能1は実行中機能保持手段21に継続的に保持される。

次いで、待機機能実行可否判定手段17は、機能2の実行可否を判定する。この時点で、機能1と機能3が実行中であり、ここで機能2を実行すると、競合条件論理式（3）を満たすため、機能2は実行不可と判定され、実行されず待機中のままとなり、競合は発生しない。機能1と機能3が実行されている状態では、上記のとおり、別の階に移動させることが可能である。

あるいは、この時点で、サービス切り離し機能（機能3）を停止することにより、実行中機能保持手段21から機能3が削除され、待機機能保持手段22に保持されている機能2は、待機機能実行可否判定手段17により、実行可と判定され、実行されるようにすることも可能である。これについては、実施形態5で詳述する。

（実施形態3：エレベータシステムとビルセキュリティシステムのシステム間の機能競合）
本実施形態では、エレベータシステムと、ビルのセキュリティシステム、具体的にはオートロック（電子錠）の機能の間の競合を例に、本システムの競合排除の動作を示す。

ビル内で火災が発生した場合、火災検知器が煙や熱などを検知すると、エレベータシステムは火災時管制運転に移行する。火災時管制運転では、エレベータは一般に、乗り場や、かご内からの呼びを無効化し、避難階に移動する、という動作をする。

一方、ビルセキュリティシステムは、火災検知器が火災を検知すると、避難経路上のドアのオートロックを解錠する（パニックオープン）するものがある。

ここで、エレベータが複数台あり、あるエレベータが避難階に到着後、乗客が降りて、自動的に解錠された避難経路上のドアから外部に出て、その後ドアが閉まったとする。この戸閉時に、ビルセキュリティシステムが、オートロック機能を停止させていないと、ドアは再び施錠されてしまう。その後、別のエレベータが避難階に到着した時点では、避難経路上のドアが施錠されており、かつエレベータは呼びが無効化されているので、別の階にも移動できず、避難が困難になってしまう。

・ 機能1：エレベータの乗り場や、かご内からの呼びを無効化する
・ 機能2：かごを避難階に移動させる
・ 機能3：（解錠後再び）避難階のドアを施錠する
という3つの機能の間の競合が起こっていることになる。

ここで、機能1と機能2のみが動作し、機能3が動作していなければ、避難階のドアは解錠されているので問題ない、また機能1と機能3のみが動作している場合は、エレベータは、ドアが施錠された階には移動しないことになる。施錠されていない別の避難階に移動すれば問題ない。機能2と機能3のみが動作し、機能1が動作していなければ、別の階に移動することができ（エレベータを避難用に用いる場合など）、問題ない。

従って、上記3機能による機能競合は、2機能の組み合わせについての競合条件では排除できないことが分かる。本実施形態により、このような3機能の実行による競合を排除できることを以下に示す。

機能1の出力である、エレベータの乗り場やかご内からの呼びを無効化する制御指令をclearとする。

避難階をk階とし、機能2の出力である、エレベータのかごをk階に移動させる制御指令をgo(k)とする。

また機能3の出力である、k階のドアを施錠する制御指令をlock(k)とする。

また火災発生時に、k階のドアを解錠する（機能4とする）制御指令をunlock(k)とする。

この時、機能1〜3による競合条件論理式Fは、
F = clear AND go(k) AND lock(k) （4）
と表現できる。

火災検知器が火災を検知すると、機能起動条件判定手段23により、機能1（呼びの無効化指令：clear）、機能2（かごの移動指令：go(k)）、機能4（ドアの解錠指令：unlock(k)）が待機状態となり、待機機能保持手段22に格納される。

この時点で、実行中機能は無いので、まず機能1を実行したとしても競合条件論理式を満たすことは無い。したがって、待機機能実行可否判定手段17は、機能1を実行可と判定し、機能1が実行される。待機機能保持手段22から機能1が削除される。ここで呼びの無効化は継続的に実行される機能なので、clearは実行中機能保持手段21に保持され、待機機能保持手段22には、機能2と機能4が保持されている。

次いで、待機機能実行可否判定手段17は、機能2（go(k)）の実行可否を判定する。実行中機能保持手段21には、機能1（clear）のみが保持されている。機能1と機能2を同時に実行しても、競合条件論理式（4）を満たさないので、待機機能実行可否判定手段17は機能2を実行可と判定し、機能2が実行される。待機機能保持手段22から機能2が削除される。ここで機能2の出力の制御指令go(k)は、かごがk階に着いたあと、別の階への移動指令が出力されるまで、実行中であるとする。このため、機能1は実行中機能保持手段21に継続的に保持される。

次いで、待機機能実行可否判定手段17は、機能2（unlock(k)）の実行可否を判定する。実行中機能保持手段21には、機能1（clear）と機能2（go(k)）が保持されている。これらとunlock(k)を同時に実行しても、競合条件論理式（4）を満たさないので、待機機能実行可否判定手段17は機能4を実行可と判定し、機能4が実行される。待機機能保持手段22から機能4が削除され、待機機能保持手段22は空となる。unlock(k)は、解錠が完了すると実行終了となり、実行中機能保持手段21から削除されるとする。この時点で、実行中機能保持手段21には、機能1と機能2が保持されている。

次いで、避難者によりk階のドアが開かれたあと、再び閉じられたとすると、ドアが閉じたことをドアに設置されたセンサーが検知する。機能起動条件判定手段23により、セキュリティシステムの機能3が待機状態となり、待機機能保持手段22に保持される。待機機能保持手段22には機能3のみが保持されている。待機機能実行可否判定手段17は、機能3の実行可否を判定する。実行中機能保持手段21には機能1と機能2が保持されており、これらの出力clear、go(k)と、機能3の出力lock(k)が同時出力されると、競合条件論理式（4）を満たすので、待機機能実行可否判定手段17は、機能3を実行不可と判定する。このため機能3は実行されず、lock(k)は出力されないので、ドアは解錠されたままとなり、競合は発生しない。

［実施形態4：競合条件論理式の表現にシステム変数を用いる場合］
実施形態3で例示した競合条件論理式は、機能の出力である制御指令だけでなく、制御指令の動作結果としてのシステム内の設備や機器の状態を表す変数（システム変数）を用いて記述してもよい。

例えば、k階のドアの施錠状態を表す変数をlock_kとし、lock_k = 0はｋ階のドアが解錠状態であること、lock_k = 1はｋ階のドアが施錠状態であることを示すとする。またかごの位置（階）を表す変数をpos、かごの走行状態を表す変数をrun（0：停止中、1：走行中）とすると、かごがk階に停止している状態は、
pos = k AND run = 0
と表せる。

この時、競合条件論理式Fを次のように書くこともできる。
F = clear AND (go(k) OR ((pos= k) AND (run = 0))) AND (lock_k = 1) （5）
(go(k) OR ((pos= k) AND (run = 0)))は、かごにk階への走行指令が出ている、もしくは、k階で停止している、ということを意味する。また、この例では機能3の出力はlock(k)ではなく、変数lock_kへの値の代入（lock = 1）であるとする。同様に、機能4の出力はunlock(k)ではなく、変数lock_kへの値の代入（lock = 0）であるとする。

待機機能実行可否判定手段17は、実行中機能だけでなく、システム変数も参照して、待機機能を実行した場合の競合条件論理式の成否を判定し、実行可否を判定する。

火災発生の検知により、機能1、2、4が待機状態となって、待機機能保持手段22に保持される。火災発生時には、機能4による解錠が実行される前は施錠状態（lock_k = 1）である。待機機能実行可否判定手段17が、機能1の実行可否を判定する。機能1を実行しても、競合条件論理式（5）は満たさないので、機能1は実行可となる。機能1は継続的に実行中であり、実行中機能保持手段21に保持され、また待機機能保持手段22から削除される。

次いで待機機能実行可否判定手段17は、機能2の実行可否を判定する。この時点で、
clear AND (lock_k = 1) （6）
が成立しており、機能2を実行すると、go(k)が出力されるので、式（6）とgo(k)が同時に成立すると、競合条件論理式（5）を満たすため、機能2は実行不可と判定され待機状態となる。

次いで、待機機能実行可否判定手段17は機能4の実行可否を判定する。機能4を実行しても（lock_k = 0）、競合条件論理式（5）は満たさないので、機能4は実行可となり実行される。待機機能保持手段22には、機能2が保持されているので、待機機能実行可否判定手段17は再び機能2の実行可否を判定する。この時点では、
clear AND (lock_k = 0) （7）
が成立しており、機能2を実行しても、競合条件論理式（5）は満たさないので、機能2は実行可となり実行され、かごはk階に移動する。

その後、ドアが再び閉じたとして、機能3（施錠）が待機状態となったとしても、
clear AND (go(k) OR ((pos= k) AND (run = 0)))
が成立しているので、さらに施錠が実行されると、競合条件論理式（5）を満たすため、機能3は実行されず、競合を排除できる。

[実施形態5：競合解消]
実施形態2では、浸水機能によりk階に到着後、機能2（open(k)）は、待機機能実行可否判定手段17により、競合条件論理式（3）を満たすため実行不可と判定され、待機状態となった。しかし、機能2が機能3（サービス切り離し機能）より優先度が高いとすると、機能3を停止して機能2を実行すべきである。

この動作を自動的に実行させる方法を示す。機能1と機能3が実行中で、機能2が実行不可と判定された時点で、競合解消手段31は、該当する競合条件論理式を構成する機能の出力について、それらの優先度を比較し、待機機能に比較して優先度の低い機能を一つ選出し、その機能を停止するように構成すればよい。

競合解消手段31は、競合条件論理式ごとに、“最小優先度機能出力”を保持しておく。最小優先度機能出力は、競合条件論理式を構成する実行中の機能の出力の中で優先度の最小のものである。

競合解消手段31は、待機中のある機能について、実行可と判定された場合、その機能の出力を含む全ての競合条件論理式について、最小優先度機能出力の優先度とその待機機能の優先度を比較し、もしその待機機能の優先度の方が、現状優先度より小さければ、現状優先度とその機能の優先度で置き換える。

また実行中機能からある機能が削除される場合には、その機能の出力を含む全ての競合条件論理式について、その競合条件を構成する他の実行中の機能の出力の中で優先度が最小のものを最小優先度機能出力とする。

競合解消手段31は、待機中のある機能について、いくつかの競合条件論理式に関して実行不可と判定された場合、それらの全ての競合条件論理式の最小優先度機能出力の優先度と、待機中の機能の優先度を比較する。そして、いずれの最小優先度機能出力の優先度よりも、待機中の機能の優先度が大きい場合は、それらの全ての最小優先度機能出力を停止することを決定し、その待機中の機能を実行可とし、上記と同様に競合条件論理式の最小優先度機能出力を更新する。

より詳細には、競合解消手段31は、停止を決定した機能については、対象システムに当該機能の停止指示を出力する。実行中機能更新手段18は、当該停止決定された機能を、実行中機能保持手段21から削除する。待機機能更新手段19は、当該停止決定された機能を待機機能保持手段22に追加する。待機機能実行可否判定手段は、上記待機中の機能について、再度、実行可否の判定を行う。実行可の決定が得られるため、上記待機中の機能を実行中機能保持手段21に追加し、当該待機中の機能を待機機能保持手段22から削除する。実行可の決定が得られることは分かっているため、実行可否の判定は省略しても良い。

Claims (10)

1. 対象システムの機能と前記機能の出力との組を保持する機能仕様保持手段と、
   前記機能間の前記出力の組み合わせに基づく論理式を保持する競合条件保持手段と、
   実行中の機能である実行中機能のリストを保持する実行中機能保持手段と、
   待機中の機能である待機機能のリストを保持する待機機能保持手段と、
   前記待機機能保持手段により保持される待機機能について、前記待機機能と前記実行中機能との出力に基づき、前記論理式が充足されるかを判定し、充足されない場合は前記待機機能の実行指示を前記対象システムに出力し、充足される場合は前記待機機能を実行しないことを決定する待機機能実行可否判定手段と、
   前記待機機能実行可否判定手段により実行指示が出された前記待機機能を前記実行中機能保持手段に追加し、また実行の終了した前記実行中機能を前記実行中機能保持手段から削除する実行中機能更新手段と、
   前記待機機能実行可否判定手段により実行指示が出された前記待機機能を前記待機機能保持手段から削除する待機機能保持手段と、
   を備えた機能競合制御装置。
2. 前記待機機能実行可否判定手段は、前記実行中機能更新手段が更新されるごとに、前記機能仕様保持手段に保持される前記実行中機能以外の機能について、前記機能と前記実行中機能との出力に基づき前記論理式が充足されるかをチェックし、チェックの結果に基づき前記機能の実行可否のリストを生成し、前記実行可否のリストに基づき前記待機機能の実行可否を判定する
   ことを特徴とする請求項1に記載の機能競合制御装置。
3. 競合解消手段をさらに備え、
   前記機能仕様保持手段により保持される機能には、優先度が設定されており、
   前記競合解消手段は、前記待機機能実行可否判定手段により充足すると判定された論理式について、前記論理式に含まれる出力を有する実行中機能のうち、前記待機機能の優先度より低い実行中機能の停止指示を出力し、前記待機機能の実行指示を出力し、
   前記実行中機能保持手段は、前記停止指示が出力された前記実行中機能を前記実行中機能のリストから削除し、前記実行中機能のリストに前記待機機能を追加し、
   前記待機機能保持手段は、前記停止指示が出力された前記実行中機能を前記待機機能のリストに追加し、前記待機機能のリストから前記待機機能を削除する
   ことを特徴とする請求項1または2に記載の機能競合制御装置。
4. 前記機能仕様保持手段により保持される機能には、優先度が設定されており、
   前記待機機能保持手段は、複数の待機機能を保持しており、
   前記待機機能実行可否判定手段は、優先度の高い順に、各前記待機機能の実行可否を判定する
   ことを特徴とする請求項1ないし3のいずれか一項に記載の機能競合制御装置。
5. 前記対象システムの状態または環境情報に応じて機能を起動することを決定する機能起動条件判定手段をさらに備え、
   前記待機機能保持手段は、前記機能起動条件判定手段により決定された機能を前記待機機能のリストに追加する
   ことを特徴とする請求項1ないし4のいずれか一項に記載の機能競合制御装置。
6. 対象システムの機能と前記機能の出力との組を機能仕様保持手段から読み出すステップと、
   前記機能間の前記出力の組み合わせに基づく論理式を競合条件保持手段から読み出すステップと、
   実行中の機能である実行中機能を保持するリストと、待機中の機能である待機機能を保持するリストを用いて、前記待機機能と前記実行中機能との出力に基づき、前記論理式が充足されるかを判定し、充足されない場合は前記待機機能の実行指示を出力し、充足される場合は前記待機機能を実行しないことを決定する待機機能実行可否判定ステップと、
   前記実行指示が出された前記待機機能を前記実行中機能のリストに追加し、実行の終了した前記実行中機能を前記実行中機能のリストから削除する実行中機能更新ステップと、
   前記実行指示が出された前記待機機能を前記待機機能のリストから削除する待機機能更新ステップと、
   をコンピュータが実行する機能競合制御方法。
7. 前記待機機能実行可否判定ステップは、前記実行中機能更新手段が更新されるごとに、前記機能仕様保持手段に保持される前記実行中機能以外の機能について、前記機能と前記実行中機能との出力に基づき前記論理式が充足されるかをチェックし、チェックの結果に基づき前記機能の実行可否のリストを生成し、前記実行可否のリストに基づき前記待機機能の実行可否を判定する
   ことを特徴とする請求項6に記載の機能競合制御方法。
8. 前記機能仕様保持手段により保持される機能には、優先度が設定されており、
   前記待機機能実行可否判定ステップにより充足すると判定された論理式について、前記論理式に含まれる出力を有する実行中機能のうち、前記待機機能の優先度より低い実行中機能の停止指示を出力し、前記待機機能の実行指示を出力する競合解消ステップと、
   前記停止指示が出力された前記実行中機能を前記実行中機能のリストから削除し、前記実行中機能のリストに前記待機機能を追加するステップと、
   前記停止指示が出力された前記実行中機能を前記待機機能のリストに追加し、前記待機機能のリストから前記待機機能を削除するステップと
   をさらに前記コンピュータが実行することを特徴とする請求項6または7に記載の機能競合制御方法。
9. 前記機能仕様保持手段により保持される機能には、優先度が設定されており、
   前記待機機能のリストは、複数の待機機能を保持しており、
   前記待機機能実行可否判定ステップは、優先度の高い順に、各前記待機機能の実行可否を判定する
   ことを特徴とする請求項6ないし8のいずれか一項に記載の機能競合制御方法。
10. 前記対象システムの状態または環境情報に応じて機能を起動することを決定する機能起動条件判定ステップをさらに前記コンピュータが実行し、
    前記待機機能のリストは、前記機能起動条件判定ステップにより決定された機能を保持する
    ことを特徴とする請求項6ないし9のいずれか一項に記載の機能競合制御方法。

Images