JP6343071B2

JP6343071B2 - システム解析装置、設計不良解析装置、故障モード解析装置、故障ツリー解析装置、自律動作装置及び自律動作制御システム

Info

Publication number: JP6343071B2
Application number: JP2017132621A
Authority: JP
Inventors: 昌能西
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2017-07-06
Filing date: 2017-07-06
Publication date: 2018-06-13
Anticipated expiration: 2034-01-22
Also published as: JP2017174471A

Description

本発明は、システム解析装置、設計不良解析装置、故障モード解析装置、故障ツリー解析装置、自律動作装置及び自律動作制御システムに関する。

近年、モデル検査手法と呼ばれる動的な入出力関係解析手法が効果的であることが知られるようになってきた。これは、各サブシステムの応答時間の不確定性、及び内部状態により入出力関係が動的に決定される構成を組み込み、統合システム全体として取りうる動的挙動を網羅することで、機能要件及び安全性要件に違反する不具合に相当する状態の存在を探索する手法である。

モデル検査手法は、対象とする統合システムの状態を一意に定める状態値と、各サブシステムの入出力関係に対応する状態遷移規則とを併せて構築した状態遷移モデルを用い、この状態遷移モデルの中から不具合に相当する状態遷移列を発見するという意味で、動的な入出力関係解析手法である。

図１では、対象とする状態遷移モデルについて、機能要件および安全性要件に違反する不具合を発見することを、処理開始時点に取りうる状態値の集合を与える開始時条件、処理終了時点にとりうる状態値の集合を与える終了時条件から、二つの状態の集合を結ぶ遷移経路の有無を判定する問題に還元する例を示している。

図２は、状態遷移モデルの構築方法を示している。システムの状態遷移モデルは、システムへの入力、内部状態、およびシステムからの出力を併せて定義される状態値と、内部状態の状態遷移規則とで構成される。また、状態遷移規則は、入力と内部状態から出力値を決定する関数と、内部状態を更新する（即ち、次の内部状態を演算する）関数とで構成される。

図３は、状態遷移モデルが取りうる個々の状態値とその遷移可能性を有向グラフで表現した状態遷移グラフである。この状態遷移モデルを用いた動的な入出力関係解析手法は、適当な開始時条件を満たす初期状態値の集合から、不具合に相当する終了時条件を満たす終状態値の集合に到る状態遷移列の有無を判定する問題に書き換えられる。この例では、あるひとつの内部状態をとる時、入力値によって遷移先状態が異なるため、遷移先状態が複数ある状態遷移グラフとなるという特徴がある。

具体的な適用例として、設計不具合の解析、故障モード影響解析、および故障ツリー解析のような動的な入出力関係解析手法が挙げられる。この場合、機能要件に対応した充足するべき正常時条件を開始時条件として設定し、また、システムの動作形態に即して定義した機能要件および安全性要件の違反に相当するハザード条件を終了時条件として設定する。

そして、開始時条件を満たす始状態の集合から開始していずれの故障モードが発生しなくとも終了時条件を満たす終状態値の集合に到る状態遷移経路があることを発見するのが設計不具合の解析である。

また、開始時条件を満たす始状態の集合から開始して任意のタイミングで発生しうるひとつの故障モードに対し、終了時条件を満たす終状態値の集合に到る状態遷移経路の有無を判定するのが故障モード影響解析である。

さらに、開始時条件を満たす始状態値から開始して任意のタイミングで発生しうる単数または複数の故障モードへの遷移の組み合わせに対して、指定した終了時条件を満たす終状態値の集合に到る状態遷移経路が存在するような故障モードの組み合わせの有無を判定するのが故障ツリー解析である。

図４は、具体的な状態遷移列の探索手順を示す。この手法では、開始時条件を満たす初期状態値の集合からひとつを適当に選択して、入力値の自由度に対応する分だけ複数存在する、到達可能な遷移先状態値を網羅的に探索する。続いて、図５に示されるツリーの形で個々の状態遷移経路を展開していき、終了時条件に違反する終状態値の集合に到達出来る状態遷移経路が存在するか否かを判定する。

以上のような手順で、各サブシステムの入出力関係を変える動的要因である内部状態を組み込み、故障モード影響解析、および故障ツリー解析を用いて行ってきた工程を代替するのが、モデル検査手法である。本明細書ではこれを順方向の状態遷移経路探索法と呼称する。なお、静的な入出力解析手法であるが、類似の方法が特許文献１に記載されている。

特開平０６−０９５８８１号公報

しかし、例えば図６に示すように、システムが取りうる状態値の数が十分に大きく、終了時条件を満たす状態値の数が取りうるすべての状態値に対して十分に少ない場合には、図５に示したような状態遷移経路のツリーの規模が大きくなってしまう。

また、モデル検査手法は、多くの計算機リソース、特に網羅的に到達可能な状態値を評価する高速な計算能力と、前記全状態値を格納する大容量のメモリを必要とする。このため、モデル検査手法を利用するのでは、実際に適用して有限時間で解析出来るシステムの規模が限定されてしまう。

計算量の増加は、状態遷移経路を網羅するために設定する必要がある初期状態値の数が膨大にあり、個別に初期状態値を設定して状態遷移経路を構築していく必要がある点、および、適当に選択した一つの初期状態値から展開した状態遷移経路の数も、探索の深さに相当する状態遷移のステップ数に対応して指数関数的に増加してしまうという、探索方式の課題に起因するものである。

また、システム設計の最終段階で、安全性要件を満たす事を保証するためには、所望の状態遷移経路が無い事を検証する必要がある。順方向の状態遷移経路探索法を用いて、すべての状態遷移経路を網羅し、その内のいずれも終了時条件を満たす終状態の集合に到達しないことを検証する必要がある。従って、結局すべての状態遷移経路を網羅してこれを格納する莫大な量の大容量メモリが必要となってしまう。

なお、動的要因を導入して同様の解析を行う試みとして、シミュレーションも存在する。このシミュレーションは、モデル検査手法で導入した不確定性を排するように不確定要因に対するパラメータを逐一設定して、一つの状態遷移経路を個別評価していく。ところが、このパラメータを網羅設定する為に必要となる計算量が、順方向の状態遷移経路探索法に要する計算量とおよそ一致することから、シミュレーションは、モデル検査手法と同様に、計算リソース量の制約下で実用的な規模のシステムに適用することが困難である。

また、入出力関係が動的に決定されるシステムに対して静的な入出力関係解析手法を適用した場合には、動的要因の為に実際には発生しないはずの不具合を誤って検出してしまったり、動的要因のために実際には発生するはずの不具合を検出出来ずに未検知となり潜在的不具合が残存してしまうといった、検出不良が発生する可能性がある。

そこで、本発明は、入出力関係が動的に決定されるシステムに対して、適切な解析を行うことができるシステム解析装置を提供することを目的とする。

本発明は、入力によって内部状態が変化し、且つ、前記内部状態の変化に応じて入力に対する出力が変化するシステムを対象とし、前記システムの状態遷移規則に基づいて、前記システムが採り得る複数の状態値と各状態値間の遷移経路とを含む状態遷移モデルを構築する状態遷移モデル構築手段と、前記複数の状態値の中から所定の開始時条件を満たす初期状態値を設定する初期状態値設定手段と、前記複数の状態値の中から所定の終了時条件を満たす終状態値を設定する終状態値設定手段と、前記状態遷移モデルの中に、前記終状態値から前記初期状態値に到達する状態遷移経路が存在するか否かを判定する状態遷移経路有無判定手段と、を備え、順方向の状態遷移経路探索手法に対し逆方向の状態遷移経路探索手法を適用し、前記状態遷移経路有無判定手段は、前記状態遷移規則と前記開始時条件及び前記終了時条件を、解として期待する状態遷移列が充足するべき論理式形式の制約条件として設定し、前記制約条件を充足する解を探索し得るＳＡＴソルバを用いて、前記状態遷移経路の有無を判定する。

本発明は、入出力関係が動的に決定されるシステムに対して、適切な解析を行うことができる。

制約条件下での状態遷移経路の探索を示す図。動的な入出力関係を有するシステムを示す図。有向グラフとして表現した状態遷移モデルを示す図。順方向の状態遷移経路探索法を示す図。順方向の状態遷移経路探索法の結果得られる探索木を示す図。大規模な状態遷移モデルを示す図。逆方向の状態遷移経路探索法の結果得られる探索木を示す図。逆方向の状態遷移経路探索法を示す図。ＳＡＴに変換した逆方向の状態遷移経路探索法を示す図。状態遷移モデル上に表現した状態遷移規則を示す図。状態遷移規則から論理式への変換を示す図。複数のサブシステムを相互接続して構成した統合システムを示す図。統合システムの入出力信号一覧を示す図。サブシステムの入出力信号一覧とサブシステムいだ接続信号名を示す図。サブシステム毎の状態遷移規則を示す図。統合システム全体の状態値の構成を示す図。非同期動作する複数のサブシステムに適用可能な逆方向の状態遷移経路探索法を示す図。統合システムの一例を示す図。オペレータが意図した統合システムの起動・終了シーケンスを示す図。オペレータの意図に反する統合システムの起動・終了の不良を示す図。自動復旧機能を搭載した自律システムの状態遷移モデルを示す図。サブシステムの故障後の自動復旧可能性の判定処理フローを示す図。起動可能性の判定処理フローを示す図。停止可能性の判定処理フローを示す図。通常動作時のハザード発生可能性の判定処理フローを示す図。動作継続可能性の判定処理フローを示す図。自律動作制御システムを示す図。オペレータと自律システムの連携を示す図。システム故障時の自律システムの動作を示す図。システム解析装置を示す図。

以下、本発明を用いたシステム解析装置の実施例について説明する。

本実施例の説明に先立って、そのコンセプトを説明する。

まず、状態遷移モデルを用いると、機能要件および安全性要件を統一的に記述出来る。つまり、機能要件は主として、ハードウェア障害が無い通常動作状態にあるシステム全体の入出力関係に対する制約条件とみなせる。また、このように状態遷移モデルとして抽象化することで、機能要件の実現手段がハードウェアであるのか、ソフトウェアであるのかを区別する必要が無くなる。特に、ソフトウェアは各時刻で一つの処理しか実現できないため、ソフトウェア処理自体がそのまま状態遷移モデルになっている。

一方、安全性要件は、ハードウェア障害が発生した場合のシステム全体の入出力関係および状態値に対する制約条件とみなせる。例えば、個々のハードウェア毎に定義した故障モードを切り替える信号を一種の外部からの入力信号として取り込むと、故障時の入出力関係を正常動作時の入出力関係に追加できる。これに留意すれば、安全性要件は、故障モードを選択的に発生させるための外部入力が追加されたシステムの入出力応答に関する制約条件として統一的に記述できる。このようにして、故障モード解析装置や故障ツリー解析装置は、システム解析装置の一実現形態であることが理解される。

このように統一すれば、入出力応答の形で表現された機能要件および安全性要件に違反する不具合とは、処理開始時点から処理終了時点までの過程で、これらの制約条件を満たさない場合となる。従って、このような不具合を発見することは、所定の制約条件下での状態遷移経路の探索問題として再定義出来る。

システムを表現した状態遷移モデルには、継続動作が可能な状態にある時には成立している開始時条件を満たす状態値の数に対して、システムの動作形態に基づいて設定した個々の終了時条件を満たす状態値の数が十分に少なくなるという特徴がある。

実際、システムが取りうる全状態値の内、開始時条件を満たす始状態値の集合から遷移可能な遷移先の状態値の数は、入力値の自由度と開始時条件を満たす範囲で変化可能な内部状態の自由度の数だけ大きくなる。従って、開始時条件を満たす状態値の数が大きくなる。

一方、終了時条件を満たす状態値から遷移可能な遷移先状態値の数は、入力値に関わらず内部状態の更新を伴う継続動作が出来ないために遷移先状態値が同じ状態値のままであるか、または終了時条件を満たす少数の状態値の集合内部に留まる。従って、終了時条件を満たす状態値の数が少数に留まる。

この場合には、モデル検査手法で用いられる順方向の状態遷移経路探索手法の代わりに、逆方向の状態遷移経路探索手法を用いた方が、状態遷移経路のツリーの規模が十分に小さくなる。この性質を利用することで、所望の状態遷移経路を逆探索するために必要となる計算リソース量を低減出来る。

実際、図７に示す通り、逆順で辿る状態遷移経路の数は、終了時条件を満たす少数の状態値の数と、逆順で辿り開始時条件を満たす状態値に辿りつくまでの遷移ステップ数により決まる。状態遷移グラフにおいて、終了時条件を満たす終状態値の集合の内部から外部に抜けて、開始時条件を満たす始状態値の集合の内部に到達するステップ数が少なければ、遷移ステップ数が少なくなる。よって、開始時条件を満たす始状態値の数が、取りうるすべての状態値の空間の多くを占める一方、かつ終了時条件を満たす終状態値の数が十分に少ない場合には、遷移ステップ数が十分に少なくなり、結果として少ない計算リソース量で所望の状態遷移経路を逆探索出来る。

このようなコンセプトに従って作成されたシステム解析装置について、以下に具体的に説明する。本実施例では、入出力、および内部状態を含むシステム一つのみで構成されるシステムを解析対象とする。このシステムは、入力によって内部状態が変化し、且つ、前記内部状態の変化に応じて入力に対する出力が変化するものである。

そして、本実施例に係るシステム解析装置は、システムの状態遷移規則に基づいて、システムが採り得る複数の状態値と各状態値間の遷移経路とを含む状態遷移モデルを構築する状態遷移モデル構築手段（図３０の解析部に相当）と、複数の状態値の中から所定の開始時条件を満たす初期状態値を設定する初期状態値設定手段と、複数の状態値の中から所定の終了時条件を満たす終状態値を設定する終状態値設定手段と、状態遷移モデルの中に、終状態値から初期状態値に到達する状態遷移経路が存在するか否かを判定する状態遷移経路有無判定手段とを備える。これらシステムの状態遷移規則や、開始時条件や、終了時条件や、任意の制約条件は、図３０に示す設定部から入力される。

ところで、終了時条件を満たす状態値の集合から状態遷移経路を逆順に辿り、開始時条件を満たす始状態値の集合を探索する手法としては、順方向の状態遷移経路探索方法で用いた図３のような状態遷移モデルを利用して、グラフ探索手法に帰着させる方法もある。但し、この手法では、依然として多くの計算リソースが必要となる場合がある。これは、所与の状態遷移規則は、順方向には一意に遷移先状態を規定しているが、逆方向に一意に遷移元状態を与えるわけではないことに起因する。そのため、状態遷移グラフを生成して、遷移元状態を逆探索する問題を、グラフ探索問題に帰着させてしまうと、システムが取りうる全状態値の数が十分に大きい場合、この状態遷移モデルをグラフの形式で格納する際に必要な計算機のメモリの量が、状態値の数と、２状態間の遷移可否を示すエッジの数に比例して、莫大となるためである。

代わりに、状態遷移規則と終了時条件、開始時条件を、解として期待する状態遷移列が充足するべき論理式形式の制約条件として設定し、これらの制約条件を充足する解を効率的に探索出来るＳＡＴソルバを用いれば、この状態遷移列の有無を判定すれば、少ない計算リソース量で済む。

このことから実施例のシステム解析装置は、ＳＡＴソルバを援用した逆方向の状態遷移経路探索を行うものとして構成され、システムの状態遷移規則を論理式に変換する手段を備え、論理式と、開始時条件と、終了時条件とを制約条件として構築された充足可能性判定問題の充足解をＳＡＴソルバを用いて算出し、充足解を状態遷移経路として出力する。上述の論理式変換手段や、ＳＡＴソルバは解析部に備えられる。所与の状態遷移モデル、開始時条件、終了時条件を用いて、終了時条件を満たす任意の状態値から逆方向に状態遷移経路を探索し、開始時条件を満たす状態値に到る状態遷移経路の有無を判定する方法の一例を図８に示す。

本手法は、状態遷移経路を構成する個々の状態値を明示的に保持するようなグラフ探索問題を基礎とするものである。つまり、状態遷移経路の始点として終了時条件を満たす終状態値を設定し、当該終状態に１ステップで到達可能な遷移元状態を再帰的に逆探索していき、開始時条件を満たす遷移元状態を発見するまで状態遷移列を網羅展開していく。

前述の通りグラフ探索法は多量の計算リソースを要するため、これと同等の処理を、充足可能性判定問題に変換して計算リソース量を低減する代替法を図９に示す。

ステップ９０１において、入出力信号値、及び内部状態を併せて状態値を定義する。ステップ９０２では、逆探索する範囲を設定する。一例として、終状態から逆探索する状態遷移ステップ数の上限を指定する方法が挙げられる。また特定の状態値の集合を探索しないように、状態遷移列に対して制約条件を追加する方法も挙げられる。

ステップ９０３では、ステップ９０２で指定した探索範囲内で所望とする状態遷移列を不定値のまま宣言する。後述のステップ９１０で、この状態遷移列をＳＡＴソルバで算出する。

ステップ９０４からステップ９０５では、システムの入出力関係に相当する状態遷移規則から、前記不定値のまま宣言した状態遷移列を構成する連続した二つの状態値x[t]とx[t+1]の間の制約条件を、t=1からt=Tまでそれぞれ設定する。

図１０に示されるような状態値及び遷移条件が与えられた状態遷移グラフにおいて、状態遷移規則に相当する制約条件を示したのが図１１である。図１１は、現在の状態値x[t]と遷移条件との組み合わせから遷移先状態値x[t+1]を与える関係が論理式の形で例示されている。一般に、ステップ９１０で用いる多くのＳＡＴソルバは、図１１に例示した論理式の形での入力を受け付けることが多い。

ステップ９０６からステップ９０７では、前記状態遷移列の各状態値x[t=1…T]に対して、システムの機能要件および動作上の限界に相当する制約条件を設定する。制約条件の設定方法としては、一般的には、状態値の一構成要素である入力値に対して許容範囲を追加設定することや、ステップ９０２で例示したように、逆探索の範囲を限定するための制約を状態遷移列の各状態値に設定することが挙げられる。

ステップ９０８では、前記状態遷移列の始状態に対して、開始時条件を満たすことを制約条件として設定する。ステップ９０９では、前記状態遷移列の終状態に対して、終了時条件を満たすことを制約条件として設定する。

ステップ９１０では、ＳＡＴソルバを用いて、本ステップまでに設定したすべての制約条件を満たし、ステップ９０３で不定値のまま宣言した状態遷移列の有無を探索する。

ＳＡＴソルバがそのような状態遷移列は無いと判定した場合、つまり制約条件を充足できない場合には、ステップ９１１に進む。この場合は、所定の終了時条件を満たす状態値の集合にいたる状態遷移列が無いことから、ステップ９０２で指定した探索範囲内では、開始時条件を満たす任意の初期条件から始めて終了時条件を満たす状態値に到達しない（つまり、終了時条件を満たす事象が起きない）ことを検証出来る。

逆に、ＳＡＴソルバが前記の制約条件をすべて満たす状態遷移列を発見した場合にはステップ９１２に進む。この場合は、開始時条件を満たす任意の状態値から開始して、終了時条件を満たす状態値に到達する、つまり終了時条件を満たす不具合事象が起きることを検証出来る。ＳＡＴソルバは９０３で宣言した不定値の具体的な値を返すため、遷移ステップ毎に状態値を表示したタイムチャートなどの形式で不具合事象を報告する。

以上のように、本実施形態によれば、入出力関係が動的に決定されるシステムに対して、適切な解析を行うことができる。

特に、個々の入出力関係を規定する動作モードを切り替えるための内部状態を導入した動的な入出力関係解析手法であって、順方向の状態遷移経路探索法で必要となる計算リソース量よりも少ない計算リソース量で、指定した開始時条件を満たす始状態の集合から、指定した終了時条件を満たす終状態の集合に到達可能な状態遷移経路の有無を判定し、存在すれば具体的な状態遷移経路を出力することが出来る。

本実施例では、入出力、および内部状態を含む複数のサブシステムを相互接続して構成される統合システムに、逆方向の状態遷移経路探索法を適用する例を示す。

ここで、サブシステムとは、入力によって内部状態が変化し、且つ、前記内部状態の変化に応じて入力に対する出力が変化するシステムを意味する。また、統合システムとは、互いに必ずしも同期して動作することが保証されないサブシステムが相互接続されたシステムを意味する。

このような統合システムの場合には、上述した問題がさらに顕著となる。即ち、動的な統合システムの場合には、各状態値から１状態遷移ステップで遷移可能な遷移先状態値の数はさらに増加し、状態遷移経路のツリーがさらに大規模になってしまう。また、静的な入出力関係解析手法は、各サブシステムの応答時間及び入出力関係が静的である場合、つまり所定の機能要件を満たすサブシステムへの入力に対して一意に所定の機能要件を満たす出力が決まることを前提と出来る場合に有効であるが、動的な統合システムではこの前提が成り立たない。従って、動的な統合システムに静的な入出力関係解析手法を適用することは実用的ではなく、検出不良の問題がさらに顕著となる。

以上のことから、並行動作する複数のサブシステムによって構成されるような統合システムに対しても、既存のモデル検査手法で必要とされるような膨大な計算リソース量を低減でき、検出不良を抑えることができる手法が有効である。

本実施例の説明に先立って、そのコンセプトを説明する。

図１２は、ｎ個のサブシステムを相互接続した統合システムを示す。統合システム全体として有する入出力信号一覧、また統合システム内の内部信号一覧との接続関係を図１３に示す。

図１４は、個々のサブシステムの入出力信号の一覧、および統合システム内の内部信号値との接続関係を示す。統合システム全体への入力は必ずいずれかのサブシステムへの入力になっており、同時に統合システムからの出力は必ずいずれかのサブシステムからの出力になっている。

図１５は個々のサブシステムの入出力関係を示す。サブシステム毎に、入力値と内部状態の組み合わせに対して一意に出力信号値と遷移先内部状態値を与える状態遷移規則（伝達関数）を設計しておく。ステップ９０１で示した通り、図１２の統合システムの内部状態値は、図１６のように定義出来る。

次に、統合システムの状態遷移モデルは、これら複数のサブシステムが非同期で並行動作する自由度を有するものとして表現してよい事を説明する。

実際の統合システムに対して定義した状態値は、元来リアルタイムで変化するため、無条件で離散時間での状態遷移モデルに対応付けられるわけではない。しかし、各サブシステムに対応付けられた状態値がデジタル値で表現されるならば、各サブシステムに対応付けられた状態値の更新順序だけを抽出することで、実際にはリアルタイムで変化する統合システムの状態値遷移経路を、離散時間で状態値が変化する離散時間状態遷移モデルにおける状態遷移経路に一対一で対応付けられるようになる。

なお、状態値は、アナログ値である連続値であっても良い。実際、連続な状態空間を区間分割して個々の区間に離散値を割り振ることで、前記連続値を離散値と一対一対応させることが出来る。

システムがサブシステム単体で構成される場合、またはすべてのサブシステムが同程度の入出力応答時間で、同期して状態値を更新する場合には、実施例１で提示した通り、状態値の一部である入力値の不確定性だけを考慮しておけばよい。また、入出力関係に相当する状態遷移規則がハードウェアで実現されているサブシステム群は、入力値の更新に対して十分に短い時間で出力値が一意に決まるため入出力応答時間が十分に短く、これらのサブシステム群は各離散時間で必ず状態値を更新することから、各離散時間で同期して状態値を更新するように対応付けられる。

一方、入出力関係に相当する状態遷移規則がソフトウェアで実装されている場合には、個々のソフトウェアの入出力応答時間は、有限ではあるが、リアルタイムで入出力応答をするサブシステムの入出力応答時間と比較して同程度に短いわけでも、固定の入出力応答時間でもないという意味で不確定である。このようなサブシステム群に対応付けられた状態値は、すべての離散時間ステップで更新されるわけではないという意味で非同期であり、この、状態値の更新時点に関する不確定性、つまり更新順序の自由度を組み込む必要がある。

なお、状態遷移規則がソフトウェアで実装されたサブシステムの入出力応答時間の上下限値が既知であるか、または指定されている場合には、各サブシステムに対応付けられた状態値の更新時点に関する自由度に対して制約条件を追加する。この入出力応答時間の制約下で、スケジューリング可能な更新順序のみに限定すれば良い。

図９で示した状態遷移列の算出フローを拡張したものが図１７に相当する。

ステップ１７０１〜１７０３はステップ９０１〜９０３に対応する。

ステップ１７０４では、離散時間の状態遷移モデルに対応付けられるように、各サブシステムの状態値の更新順序に関する自由度を網羅するように同期実行集合を構築していく。ここで、同期実行集合とは、統合システムを構成するｎ個のサブシステムの内、各離散時間において同期して状態値が更新されるサブシステムの集合である。そして、同期実行集合を網羅選択し、同期実行リストに追加していく。

各離散時間において同期実行集合に含めるべきサブシステムの一覧は、リアルタイムでの入出力応答をするサブシステムの応答時間を基準として、各サブシステムの入出力応答時間の相対的な長さ、および不確定性を考慮して決定する。

ステップ１７０５では、離散時間ｔのそれぞれについて、同期実行リストに登録された同期実行集合を一つ選択して、ステップ１７０６において同期実行集合に登録されているサブシステムに対応付けられた状態値は更新し、登録されていないサブシステムに対応付けられた状態値は更新せず、同じ状態値を引き継ぐ。このようにして、離散時刻ｔにおける状態遷移規則と同期実行集合から遷移元状態値と遷移先状態値の間の制約条件の論理式表現Ｗを設定する。

ステップ１７０６，１７０７を、離散時刻ｔに対応した同期実行リストのすべての同期実行リストに対して行い、生成したこれらの制約条件の論理式表現Ｗの論理和をとる。これをすべての離散時刻ｔについて設定する。

ステップ１７０８では、同期実行リストのエントリごとに得られた論理式の論理和を制約条件に設定する。ステップ１７０９では、同期実行リストの中から同期実行集合を一つ選択する。

ステップ１７１０は、ステップ９０６に対応し、ステップ１７１１は、ステップ９０７に相当する。ステップ１７１１は、ステップ９０８に、ステップ１７１２はステップ９０９に相当する。ステップ１７１４はステップ９１０に相当し、ステップ１７０７，１７０９，１７１０〜１７１３で設定した論理式の論理積を設定し、ＳＡＴソルバを用いて、すべての制約条件を満たす、ステップ１７０３で不定値のまま宣言した状態遷移列の有無を探索する。ステップ１７１５はステップ９１１、ステップ１７１６はステップ９１２に相当する。

本実施例では、図１８に示すような統合システム１８０１を対象とし、逆方向の状態遷移経路探索法を応用して、設計不具合を解析する方法を示す。

本実施例の説明に先立って、その背景を説明する。

従来、高度な情報処理機能、および多種多様な機能を有するサブシステム群を相互接続することで構成される統合システムが存在する。このような統合システムを設計する際、個々のサブシステムの機能要件を個別に定義している段階では容易に発見出来ず、システム統合の段階に到り、サブシステム群を相互接続して稼働させた時点で初めて露呈する不具合がある。この不具合は、当該システムに課された機能要件を満たさない場合、および安全性要件を損なう場合に大別される。

このような不具合を招くシステム設計上の複雑さは、システムの規模だけでなく、ハードウェアを汎用化し、所定の機能要件、および安全性要件を実現するための仕組みをソフトウェアに集約させる設計思想に端を発するものである。

とは言え、多種多様な機能毎に専用ハードウェアを設計する代わりに、汎用化したハードウェアを再利用して構築したプラットフォーム上に各種機能要件をソフトウェアで実装するアーキテクチャとすることで得られるコスト削減効果は大きく、この傾向は今後も継続していく。

設計情報の再利用を視野に入れて大規模なシステムを短期間で設計するためには、サブシステム毎の分業により並行して設計作業をすることが有効である。その為に、分割した機能要件を各サブシステムに割り当て、適当なインターフェースを介して相互接続する設計手法が取られてきた。しかし、統合システム全体の機能要件を、各サブシステムの機能要件に分解した時点では明確にされていない、複数機能要件間の競合、または接続元サブシステムおよび接続先サブシステムを連結するインターフェースを介して実現される処理内容の統合時不整合が、前述の不具合を招いてしまう場合がある。

主たる機能要件を実現する手段を専用ハードウェアに依存してきた既存システムの設計では、個々のハードウェアサブシステムに割り当てる機能要件の数は単数または少数であり、また各サブシステムの入出力関係や応答時間、およびサブシステム間のインターフェースの入出力仕様は、共に明確に規定されてきた。このため、確定的な応答時間、予測可能な入出力応答動作しかしないことから、機能要件間の競合、およびインターフェースの不整合に起因する不具合は顕在化しにくかった。

しかし、主要な機能要件をソフトウェアに多数集積していく過程では、多くの機能要件を複数のサブシステムに分割して割り当てることから、一つのサブシステムに複数の機能要件をソフトウェアで実現していくことになる。この際には、ソフトウェアで実現可能な処理の性質を考慮した設計が求められる。

第一の性質は、一度に一つの入出力処理動作しかできないことである。このため、個々のサブシステムに割り当てた複数の機能要件を同時に実行できない場合には、機能要件間の競合という形で不具合が顕在化し、規定外の入出力は入出力インターフェースの不整合という形で不具合が顕在化する。

第二の性質は、応答時間が非決定的であることである。特に、統合システムの機能要件は、ソフトウェアで実装した複数のサブシステム群を並行動作させて実現されることになるが、各サブシステムの応答時間が非決定的であるために、システム統合時点で、各サブシステムの挙動の総体として実現されるはずの統合システム全体の動作が、非確定的になってしまうことがある。これも不具合を招く原因となり得る。

第三の性質は、ソフトウェア自体の不具合、または規定外の入力に対して、ソフトウェア実装部の出力が予測不能となる点である。これは、特に系統化した統合システムのテストをして機能要件または安全性要件に対する違反を検証する際に、これらの不具合を発見することを困難にし得る。

実際、これらの不具合が発見された場合にも、各サブシステムの応答時間の予測性の為に不具合を再現することが困難な場合が多い。

高安全性を要求される統合システムにおいてこのような不具合が無いことを確認することは、高信頼システム設計上の課題の一つである。このようなシステムでは、ハードウェア故障に対処するために内部冗長性を備え、障害発生時に安全状態に留まるか、または動作継続を可能とする事を安全性要件として設定して、これをソフトウェアで実装する。ハードウェア故障に対して、冗長化したハードウェアが有効に機能するようにソフトウェア処理を実現する場合には、前記のようなソフトウェア実装に伴う副作用なく、耐障害機能に関する安全性要件に違反する不具合を発見し、対処することが好ましい。

本実施例の設計不良解析装置は、上述の状況に対して効果を奏するものであり、以下に具体的に説明する。

本実施例の設計不良解析装置は、システムが複数相互接続される統合システムを対象とし、統合システムが正常時に充足するべき機能要件を開始時条件として設定し、統合システムの異常状態を終了時条件とし、状態遷移経路有無判定手段は、状態遷移モデルの中に、終状態値から初期状態値に到達する状態遷移経路が存在するか否かを判定し、状態遷移経路有無判定手段によって、終状態値から初期状態値に到達する状態遷移経路が存在すると判定される場合には、統合システムの設計不良が存在すると判定する。

まず、本実施例の設計不良解析装置の解析対象となる図１８の統合システム１８０１について説明する。統合システム１８０１は、コントローラ１８０３、アクチュエータ１８０４、制御対象１８０６、センサ１８０７、およびセーフティモニタ１８０５を相互接続して構成され、この統合システム１８０１がオペレーション装置１８０２によって操作される。なお、オペレーション装置１８０２は、操作者からの入力によって操作内容が決定される場合と、オペレーション装置１８０２内の処理によって操作内容が決定される場合とがある。

オペレーション装置１８０２と統合システム１８０１とは、図示されたインターフェースを介して非同期で接続されている。オペレーション装置１８０２は、操作者が規定された操作手順に従って入力を行うことや、オペレーション装置１８０２内の処理によって動作順序が変化するものであるため、動作順序毎に割り当てた内部状態を遷移する状態遷移モデルとして表現することができる。

オペレーション装置１８０２と統合システムとの間のインターフェースについて説明する。boot信号は、統合システムの起動・停止を制御するレベル信号である。grant信号は、起動後の動作開始と終了を指示するパルス信号であり、command信号は動作開始後に制御命令を行うパルス信号である。オペレーション装置１８０２からコントローラにcommand信号が入力されると、これを受け付けたコントローラは、アクチュエータに対して制御コマンドControl input信号を出力する。error信号は、統合システム内でエラーが発生した場合に、オペレーション装置１８０２が受け取るエラー情報に関するパルス信号である。

統合システムを構成する個々のサブシステムはそれぞれの動作モード毎に内部状態を有している。また、アクチュエータ、制御対象、センサの入出力応答時間は十分に短いため、リアルタイムで同期動作するものとみなされる。

一方、コントローラ、セーフティモニタの入出力応答はソフトウェアで実装されているため、入出力応答時間が不確定となる。そのため、この二つのサブシステムと、同期動作する前記３つのサブシステムとは、互いに非同期で動作する状態で相互接続されている。

オペレーション装置１８０２は、所定の操作手順に対応した内部状態を有しており、状態値がOffから、状態値Bootに遷移して、boot信号を１にセットする。続いて状態値Grantに遷移して、boot信号を１にしたまま、パルス信号であるgrant信号に１をセットする。状態値をOperateに遷移している間は、command信号値に適当な制御命令を設定し続ける。統合システム１８０５を停止させたい場合には、状態値Shutdownに遷移して、再度パルス信号であるgrant信号に１をセットし、最後に状態値Offに遷移してboot信号値を０にクリアする。状態値がOperateにある時に、error信号を経由してパルス信号であるエラー情報を受け取ると、状態値Error_handlingに遷移して、統合システムの動作を終了させるために、パルス信号であるgrant信号値に１をセットし、続いて状態値Shutdownに遷移する。

コントローラ１８０３は、内部状態が停止状態（Off）にある時に、オペレーション装置１８０２からboot信号を受け付けると内部状態値をIdleに更新する。この時点では、出力信号Control_input,monitor_enable共に0とする。内部状態がIdleにある時にオペレーション装置１８０２からgrant信号を受け取ると、内部状態値をOperateに遷移させ、monitor_enable信号を1にセットする。

セーフティモニタ１８０５は、コントローラ１８０３から動作開始・終了を指示するレベル信号であるmonitor_enable信号を受け取り、内部状態値をOffからOnに遷移させる。内部状態値がOnの時のみ、アクチュエータの動作を許可するために、レベル信号であるactuator_enable信号を１にセットする。

アクチュエータ１８０４は、セーフティモニタからのレベル信号であるactuator_enableが1にセットされている時のみ内部状態値をOnに遷移させ、コントローラからの入力信号Control_inputを受け付けてPhysical_effect信号を出力する。

コントローラの内部状態値がOperateにある限りは、オペレーション装置１８０２から受け付けたcommand信号値を、Control_inputにセットする。アクチュエータは、このControl_input信号に対して、制御対象に対してPhysical_effect信号を入力し、センサは制御対象の状態を計測して、Y_out信号値をセーフティモニタに出力する。セーフティモニタは、センサから受け取った値を適当に処理して、Y_out_mon信号をコントローラに出力する。

セーフティモニタがセンサから受け取った計測値が異常である場合には、内部状態値をStopに遷移させ、レベル信号であるactuator_enable信号を０にクリアし、コントローラに対して異常値を知らせるY＿out_mon信号を出力する。併せて内部状態値をOffに更新して、アクチュエータを継続動作出来ないようにして統合システム全体の安全を図る。

コントローラは、Y_out_mon信号値が異常でなければ内部状態値をOperateのまま維持して動作を継続し、異常値であれば内部状態値をError_handling値に更新する。また、内部状態値がOperateの時に、パルス信号であるgrant信号をオペレーション装置１８０２から受け取った場合には、内部状態値をIdleに更新し、動作を終了する。引き続いてレベル信号であるboot信号値が0にセットされた場合には内部状態値をOffに更新し、コントローラは動作停止させ、統合システム全体を停止させる。

このように設計された統合システム１８０１に対して、本実施例のシステム解析装置によるシステム解析を説明する。検証者は、センサ故障が発生しても統合システム全体が安全である、という安全性要件を設定し、これが実現されることを検証したいとする。具体的には、検証者は、センサ故障に伴いセーフティモニタが異常値を検出すると、オペレータが統合システムからerror信号値を受け取り、所定の操作手順に従ってboot信号値を０にクリアして統合システムを停止させることにより、統合システムが安全である事を検証したいとする。

設計時点で想定していた、この安全性要件を満たすような動作順序のタイムチャートを図１９に示す。図１９によると、オペレータの内部状態State_Operator値は、Off、Boot、Grant、Operateと遷移していき、統合システム動作中に発生したセンサ故障を経て、Error_handling、Shutdown、Offへと遷移して終了することを想定して設計されている。

しかし、この統合システムがこのように想定した通りの動作をしない場合があることを本システム解析装置によって発見出来ることを示したのが、図２０である。

この検証例では、検証者は、故障が無い通常動作時に取りうるすべての内部状態のいずれかをとることを開始時条件とし、また、オペレータの内部状態State_OperatorがOff状態にあり、かつ統合システムが動作継続状態にあること、つまりコントローラの内部状態値State_ControlがOperateとなっていることを終了時条件として設定する。

検証者がこのような条件の設定を入力装置を用いてシステム解析装置に入力すると、システム解析装置は図１７に示した手順で解析を行う。

なお、図１７のステップ１７０４における同期実行集合、及び、同期実行リストについて説明する。まず、オペレーション装置１８０２と、コントローラ１８０３と、セーフティモニタ１８０５は、それそれが非同期で動作し得るサブシステムである。また、アクチュエータ、センサ（場合によっては制御対象）等のリアルタイムで応答するシステムも一つのアナログなサブシステム（リアルタイム応答サブシステム）とみなすことができる。従って、図１８に示す統合システム１８０１には、サブシステムとして、コントローラ１８０３と、セーフティモニタ１８０５と、上述したリアルタイム応答サブシステムが含まれている。

なお、オペレーション装置１８０２は、統合システム１８０１に含まれるサブシステムではないが、操作者の操作と統合システム１８０１とが非同期であるという点で、非同期で動作するサブシステムとみなすことができる。

そして、これら４つのサブシステムは、互いに動作が同期する場合と、同期しない場合とがあり、同期して動作する場合にはこれを一つの同期実行集合として括る。このような同期実行集合のパターンとしては、表１に示すように８つあり、これが同期実行リストに登録されている。

そして、システム解析装置は、図２０に示すタイムチャートの形式で出力装置に結果を出力する。図２０は、終了時条件を満たす終状態に到る状態遷移経路がタイムチャートの形で提示されている。

ここで、統合システム１８０１はサブシステム及び統合システムがとり得る状態値が十分多く、これらの状態値を例えば図８に示すような有向グラフで表そうとすると複雑になるため、タイムチャートの形式が採用されている。但し、有向グラフとタイムチャートとは、状態値及び状態遷移経路を表示するという意味で本質的には同様であり、例えば、タイムチャートを離散時間ごとに縦割りにして得られる一列の各信号値のセットが一つの状態値を表している。また、このタイムチャートは、指定した開始時条件、終了時条件の元で逆方向の状態遷移経路探索の結果得られる状態遷移経路の一つであり、同様の検索条件を用いてＳＡＴソルバが複数の状態遷移経路を発見した場合にはそれぞれの状態遷移経路に対応するタイムチャートが出力される。

図２０では、オペレーション装置１８０２が統合システムの動作を終了させるために、パルス信号であるgrant信号を１にセットした時点と、統合システム内部でセンサ故障が発生し、続いてオペレーション装置１８０２にエラー情報を伝達するためにerror信号値を１にセットした時点とが、図１９のように想定していた更新順序と異なっていることが見いだせる。

この不具合を招いた原因は、オペレーション装置１８０２と統合システムは互いに非同期で動作しており、オペレーション装置１８０２がエラー情報を取得する前に統合システムの終了処理を試行するが、この際、コントローラがオペレーション装置１８０２からgrant信号を受け取る処理と、エラー情報をオペレーション装置１８０２に送信する処理の更新順序について自由度があるためである。

特に、コントローラの入出力関係を制御する内部状態が、error信号値を１にセットした後すぐにオペレーション装置１８０２からのgrant信号値を受け取っているにも関わらず、これを受け取ることが出来ずに状態値Idleに遷移してしまっている。

これは、コントローラの内部状態値を更新するソフトウェアが、error信号値を１にセットする処理を実行している途中で、オペレーション装置１８０２から受け取ったgrant信号値が１であることを同時に取得して、適切な状態値に遷移させることが出来ていないというソフトウェア実装上の性質による。

そのため、この時点で受け取るパルス信号grant値は、コントローラの内部状態値をIdleからOperateに遷移させてしまっている。

一方、オペレーション装置１８０２若しくは操作者はこの事を知ることが出来ず、コントローラの状態値State_ControlをOperateからIdleに遷移させて、boot信号値を0にクリアすることで停止させるようとしている。しかし、状態値State_ControlがOperateに遷移してしまったコントローラは、オペレーション装置１８０２からのレベル信号であるboot信号が0であることを取得しても、状態値Offに遷移することが出来ないまま、状態値Operateを維持し続けてしまっている。生成されたタイムチャートから、たしかに前述の安全性要件に違反してしまっていることが明らかになる。

この設計上の不具合を招いた一つの要因は、オペレーション装置１８０２と統合システムとを接続するインターフェースの設計にあり、特に統合システムの動作開始と終了を制御するために、パルス信号としてgrant信号値を実装してしまったことにある。

本実施例では、実施例３で説明したような設計不具合の解析方法を用いて、統合システムを構成するサブシステムに障害が発生した後、障害部位を除いた統合システムの動作継続可能性を判定し、可能であれば自動復旧をさせる機能を有する自律動作装置を示す。

本実施例の自律動作装置は、他の実施例で説明されたようなシステム解析装置を含むものであり、システムが複数相互接続される統合システムと、統合システムの動作中に、システムの故障を検出する故障検出手段と、故障が発生したシステムの排除を制約条件として追加する制約条件追加手段と、システム解析装置によって故障したシステムを排除した状態での動作継続可能性を判定する動作継続可能性判定手段とを備え、統合システムが正常時に充足する機能要件を開始時条件として設定し、システムの故障によって発生する統合システムの異常状態を終了時条件とし、動作継続可能性判定手段は、状態遷移経路有無判定手段によって、終状態値から初期状態値に到達する状態遷移経路が存在すると判定される場合には、動作継続可能と判定する。

図２１は、停止状態から起動処理を経て、通常動作時の状態遷移までの過程、さらにサブシステムの障害によりハザードに相当する終了時条件ＥＮＤ１、ＥＮＤ２を満たす状態を含む、統合システム全体の状態遷移グラフを示したものである。

実施例３に示した不具合解析を経て、設計時点で想定するサブシステムの障害の組み合わせでは、終了時条件ＥＮＤ１、ＥＮＤ２を満たす状態に到る状態遷移経路が無いことが検証されているとする。

この時、この統合システムを構成するサブシステムが何らかの障害を起こし、予測不能な動作をした事を検出した時点から、障害要因を除去し、動作継続の可否を自律的に判定する機能を実現したい。

少なくとも想定した故障モードのいずれかが発生した場合には、ハザード状態に到ることは無い事は設計段階で検証出来る。しかし、障害の形態、および障害を起こしたサブシステムの組み合わせによっては、この統合システムが継続動作できるかどうかは定かではない。

事前に明示的な障害復旧処理の手順を組み込んでいない場合には、実際には動作継続可能なシステムの再構成方法があったとしても、安全性要件を満たすように動作停止せざるを得ず、結果としてこの統合システムの稼働率を十分に高められないおそれがある。

しかし、障害を起こしたサブシステムに適切な処理、例えば機能停止を施した上で、「停止状態から通常動作状態に必ず到達出来ること」、「通常動作状態から停止状態に到達出来ること」、「障害を起こしたサブシステムの内部状態を機能停止状態に指定した上で、通常動作状態からハザード条件に相当する終了時条件ＥＮＤ１，ＥＮＤ２に相当する状態に到達する状態遷移経路が存在しないこと」が検証できるならば、当該サブシステムの障害にも関わらず、安全性要件を満たしながら継続動作出来ることとなる。従って、これを統合システムに自力で判断させれば、オペレータや設計者のマニュアル操作を介すること無く、自力復旧・動作を再開出来る。

図２２は、具体的な判定手順を示す。

ステップ２２０１では、まず故障したサブシステムｋを特定する。続いて、ステップ２２０２、ステップ２２０３で、故障したサブシステムｋの影響を排除出来る状態（例えば停止状態）に指定する制約条件ＲＥＭＯＶＥ＿ＦＡＵＬＴを設定する。そして、以降の処理においてサブシステムｋの影響を排除させたままで、動作継続可能であるか判定する。

ステップ２２０４では、起動可能性を判定する。つまり、停止状態から起動処理開始条件を満たし、且つ通常動作状態に遷移出来ない状態が継続するような状態遷移列Ｘ（ｔ）が存在するか否かを判定する。詳細な処理手順は、図２３に記載の通りである。ステップ２２０４に記載の制約条件を満たす状態遷移列が存在する場合には、起動できない場合があることを意味するため、動作継続不能であると判定出来ることから、ステップ２２０８に遷移し、処理を終了する。逆に、ステップ２２０４に記載の制約条件を満たす状態遷移列が存在しない場合には、少なくとも停止状態から必ず起動処理を開始出来ることが分かる。

この場合には、引き続いてステップ２２０５で、停止可能性を判定する。つまり、通常動作状態から停止処理開始条件を満たし、且つ停止状態に遷移出来ない状態が継続するような状態遷移列Ｘ（ｔ）が存在するか否か判定する。

詳細な処理手順は、図２４に記載の通りである。ステップ２２０５に記載の制約条件を満たす状態遷移列が存在する場合には、安全に停止出来ない場合があることを意味するため、ステップ２２０８に遷移し、処理を終了する。

逆に、ステップ２２０５に記載の制約条件を満たす状態遷移列が存在しない場合には、少なくとも通常動作状態から必ず停止処理を完了出来ることが分かる。この場合には、引き続いてステップ２２０６で、ハザード条件１，２に相当する安全性要件違反を招く状態遷移列の有無を判定する。

詳細な処理手順は図２５に記載の通りである。ステップ２２０６に記載の制約条件を満たす状態遷移列が存在する場合には、通常動作中にハザード状態に遷移する場合があるため、動作継続不能であると判定出来ることから、ステップ２２０８に遷移し、処理を終了する。

逆に、ステップ２２０６に記載の制約条件を満たす状態遷移列が存在しない場合には、少なくとも通常動作中にはハザードが起こらないことが分かる。

この場合には、引き続いてステップ２２０７で、通常動作の継続可能性を判定する。

詳細な処理手順は図２６に記載の通りである。ステップ２２０７に記載の制約条件を満たす状態遷移列が存在する場合には、動作中に、通常動作状態を逸脱する形で通常動作が中断する場合がある事が分かるため、ステップ２２０８に遷移し、処理を終了する。

逆に、ステップ２２０７に記載の制約条件を満たす状態遷移列が存在しない場合には、通常動作を継続出来るため、ステップ２２０９に遷移し、動作を再開する過程である一連の起動処理を開始し、通常動作状態に到達した時点で自動復旧を終了する。

図２３は、ステップ２２０４において評価対象となる制約条件を構築する具体的な手順を示す。

ステップ２３０１では、統合システムの起動を指示する制約条件を設定する。

ステップ２３０２では、停止状態を定義する制約条件ＮＯＲＭ２と、起動処理状態を定義する制約条件ＮＯＲＭ３を設定する。
ステップ２３０３ではさらに、故障したサブシステムｋを排除する制約条件を追加して、ＳＡＴソルバを用いてこの制約条件を充足する状態遷移列の有無を判定する。充足解が無ければステップ２３０６に遷移して処理を終了する。

逆に充足解がある場合には少なくとも停止状態から起動処理を開始出来ることが分かった為、ステップ２３０４に進む。

ステップ２３０４では、故障したサブシステムｋを排除して、ハザード条件１，２に対応する制約条件を満たさないこと、通常動作状態を与える制約条件を併せて、一つ以上の状態値が存在するか否かを、ＳＡＴソルバを用いて判定する。

ステップ２３０４に記載の制約条件を満たす状態値が存在しない場合にはステップ２３０６に遷移して処理を終了する。

逆に存在する場合には、ハザード条件１，２を満たさずに動作継続可能な状態が存在するため、ステップ２３０５に遷移する。

ステップ２３０５では、故障したサブシステムｋを排除した上で、起動した後に、通常動作状態に遷移出来ない状態が継続するような状態遷移列の有無を判定する。

そのような状態遷移列が存在する場合には、停止状態から抜けて起動処理を開始しても、継続して動作継続状態を維持できないことが分かるため、ステップ２３０６に遷移して処理を終了する。

逆に、そのような状態遷移列が存在しない場合には、必ず起動後には通常動作状態に到達することが出来ることが分かるため、ステップ２３０７に遷移して処理を終了する。

図２４は、ステップ２２０５において評価対象となる制約条件を構築する具体的な手順を示す。

ステップ２４０１では、統合システムの停止を指示する制約条件を設定する。

ステップ２４０２では、故障したサブシステムｋを排除しながら、ハザード条件１，２に対応する制約条件を満たさない通常動作状態に相当する状態値の有無を判定する。

そのような状態値が存在しない場合には、通常動作中にハザード１または２を招くことが分かるため、ステップ２４０５に遷移して処理を終了する。

逆にそのような状態値が存在する場合には、ハザード条件１，２を満たさずに動作継続可能な状態値が少なくとも一つ以上存在することが分かるため、ステップ２４０３に遷移する。

ステップ２４０３では、故障したサブシステムｋを排除しながら、ハザード条件１，２を満たさない停止状態に相当する状態値の有無を判定する。

そのような状態値が存在しない場合には安全に停止出来ないことが分かるため、ステップ２４０５に遷移して処理を終了する。

逆にそのような状態値が存在する場合には、ハザード条件１，２を満たさない停止状態が少なくとも一つ以上存在することが分かるため、ステップ２４０４に遷移する。

ステップ２４０４では、故障したサブシステムｋを排除しながら、ハザード条件１，２を満たさない通常動作状態から、同様にハザード条件１，２を満たさない安全な停止状態に到らないまま留まる状態遷移列の有無を判定する。

そのような状態遷移列が存在する場合には、通常動作状態から抜けても停止状態に到達出来ないという意味で安全に停止出来ないことが分かるため、ステップ２４０５に遷移して処理を終了する。

逆にそのような状態遷移列が存在しない場合には、停止処理を開始すれば必ず安全に停止状態に到達出来ることが分かるため、ステップ２４０６に遷移して処理を終了する。

図２５は、ステップ２２０６において評価対象となる制約条件を構築する具体的な手順を示す。

ステップ２５０１では、故障したサブシステムｋを排除しながら、通常動作状態であってハザード条件１，２を満たさない状態値の有無を判定する。

そのような状態値が存在しない場合には、ステップ２５０４に遷移して処理を終了する。

逆にそのような状態値が存在する場合には、ハザード条件１，２を満たさずに動作継続可能な状態が少なくとも一つ以上存在することが分かるため、ステップ２５０２に遷移する。

ステップ２５０２では、故障したサブシステムｋを排除しながら、通常動作状態では無くハザード条件１または２を満たす状態値の有無を判定する。

そのような状態値が存在しない場合には、そもそもハザード状態を満たす状態が存在しなくなるため、ステップ２５０５に遷移して処理を終了する。

逆にそのような状態値が存在する場合には、通常動作時にハザード条件１，または２に相当する状態に到達する状態遷移列が存在することが分かるため、ステップ２５０４に遷移して処理を終了する。

図２６は、ステップ２２０７において評価対象となる制約条件を構築する具体的な手順を示す。

ステップ２６０１では、故障したサブシステムｋを排除しながら、ハザード条件１，２を満たさない通常動作状態に相当する状態値の有無を判定する。

そのような状態値が存在しない場合は、ステップ２６０３に遷移して処理を終了する。

逆にそのような状態値が存在する場合は、ステップ２６０２に遷移する。

ステップ２６０２では、故障したサブシステムｋを排除しながら、停止処理の開始を指示する入力をセットしないという追加条件の下で、ハザード条件１，２を満たさない通常動作状態から外れるような状態遷移経路の有無を判定する。

そのような状態遷移経路が存在する場合には、ハザード１または２により通常動作を中断される場合が存在することが分かるため、ステップ２６０３に遷移して処理を終了する。

逆にそのような状態遷移経路が存在しない場合には、ハザード条件１，２に相当する状態に到達せずに、通常動作を継続し続けられることが分かるため、ステップ２６０４に遷移して処理を終了する。

このように、本実施例によれば、サブシステム毎に定義した故障モードを動作モードに追加することで、静的な入出力関係解析手法では課題であった不具合の誤検出・未検出無く、統合システムの設計不具合の解析、故障モード影響解析や故障ツリー解析を行える。

本実施例では、実施例４に記載の自律動作装置を操作者がオペレーション装置を介して操作し、操作者と自律動作装置が連携して、サブシステムの故障時に動作を継続させるか、マニュアル操作をして安全に停止させる操作者との連携機能を実現する自律動作制御システムを示す。

本実施例の自律動作制御システムは、図２７に示すように、自律動作装置と、自律動作装置を操作するオペレーション装置とを備え、自律動作装置は、動作継続可能性判定手段によって動作継続不能と判定された場合には、オペレーション装置に対してエラー信号を送信し、動作継続可能性判定手段によって動作継続可能と判定された場合には、オペレーション装置に警告信号を送信し、且つ、自律動作を継続する。

一例として、自動走行機能を有する車両を自律動作装置とし、乗客を操作者としても良い。また、別の例では、遠隔制御用の通信経路を介して動作する建設作業機械を自律動作装置とし、遠隔地にいる作業者を操作者としても良い。

図２８は、操作者及び自律システムの動作モードを示す。

自律システム（統合システム）は、自律動作モード、マニュアル操作モード、および停止状態の３種類の動作モードを内部状態の一部として有する。オペレーション装置は、内部状態が自律動作モードの時には統合システムの監視を行い、停止状態の場合は待機し、マニュアル操作モードの時には、マニュアル操作モードに遷移して、操作者からの適切な制御内容を統合システムに入力する。オペレーション装置は、必要に応じて停止を指示する入力を入れ、統合システムの内部状態を停止状態に遷移させることもできる。

統合システムが自律動作モードにある時にサブシステムの故障が発生した場合には、図２９に記載の通り、第４の実施例に記載の自律動作装置の自動復旧機能を用いて、オペレーション装置が統合システムを構成するサブシステムの故障により自律動作を継続できなくなるか否かを判定する。動作継続を出来なくなった場合には、自律動作装置がエラー情報の一形態として停止要請を伝達し、待機または監視状態にあるオペレーション装置がマニュアル操作を開始して統合システムを停止させる。

逆に動作継続を出来る場合には、自律動作装置は自動復旧処理を完了させ、オペレーション装置には警告情報を送信した上で、自律動作を継続する。操作者は、必要に応じて統合システムを停止させても良い。

本発明は、耐障害機能を備えた高信頼な冗長化計算機システム、および電気・機械・情報制御系を統合した大規模制御システムの安全性解析に利用出来る。また、ハードウェア、ソフトウェア統合設計環境において、不具合を招く根源要因の特定、特に設計不良の解析にも利用できる。さらに、自律動作装置を構成するサブシステムが規定外の障害を起こした後、自律的に障害要因の診断、障害要因を処置して、動作継続を出来るシステム状態に自動復旧させる機能にも利用出来る。

１８０１統合システム
１８０２統合システムのオペレータ
１８０３コントローラ
１８０４アクチュエータ
１８０５セーフティモニタ
１８０６統合システムの一部である制御対象
１８０７センサ

Claims

入力によって内部状態が変化し、且つ、前記内部状態の変化に応じて入力に対する出力が変化するシステムを対象とし、
前記システムの状態遷移規則に基づいて、前記システムが採り得る複数の状態値と各状態値間の遷移経路とを含む状態遷移モデルを構築する状態遷移モデル構築手段と、
前記複数の状態値の中から所定の開始時条件を満たす初期状態値を設定する初期状態値設定手段と、
前記複数の状態値の中から所定の終了時条件を満たす終状態値を設定する終状態値設定手段と、
前記状態遷移モデルの中に、前記終状態値から前記初期状態値に到達する状態遷移経路が存在するか否かを判定する状態遷移経路有無判定手段と、を備え、
順方向の状態遷移経路探索手法に対し逆方向の状態遷移経路探索手法を適用し、
前記状態遷移経路有無判定手段は、前記状態遷移規則と前記開始時条件及び前記終了時条件を、解として期待する状態遷移列が充足するべき論理式形式の制約条件として設定し、前記制約条件を充足する解を探索し得るＳＡＴソルバを用いて、前記状態遷移経路の有無を判定することを特徴とするシステム解析装置。
請求項１に記載のシステム解析装置であって、
前記システムの状態遷移規則を論理式に変換する手段を備え、
前記論理式と、前記開始時条件と、前記終了時条件とを制約条件として構築された充足可能性判定問題の充足解を前記ＳＡＴソルバを用いて算出し、前記充足解を前記状態遷移経路として出力することを特徴とするシステム解析装置。
請求項１に記載のシステム解析装置を含む設計不良解析装置であって、
前記システムが複数相互接続される統合システムを対象とし、
前記統合システムが正常時に充足するべき機能要件を前記開始時条件として設定し、
前記統合システムの異常状態を前記終了時条件とし、
前記状態遷移経路有無判定手段は、前記状態遷移モデルの中に、前記終状態値から前記初期状態値に到達する状態遷移経路が存在するか否かを判定し、
前記状態遷移経路有無判定手段によって、前記終状態値から前記初期状態値に到達する状態遷移経路が存在すると判定される場合には、前記統合システムの設計不良が存在すると判定することを特徴とする設計不良解析装置。
請求項１に記載のシステム解析装置を含む故障モード解析装置であって、
前記システムが複数相互接続される統合システムを対象とし、
前記システムの内部状態に故障状態を追加する故障状態追加手段を備え、
前記故障状態を前記開始時条件とし、
前記統合システムの異常状態を前記終了時条件とし、
前記状態遷移経路有無判定手段によって、前記終状態値から前記初期状態値に到達する状態遷移経路が存在すると判定される場合には、前記システムの故障によって前記統合システムの異常状態が発生すると判定することを特徴とする故障モード解析装置。
請求項１に記載のシステム解析装置を含む故障ツリー解析装置であって、
前記システムが複数相互接続される統合システムを対象とし、
前記システムを故障状態に設定する故障状態設定手段を備え、
前記統合システムが正常時に充足する機能要件を前記開始時条件として設定し、
前記統合システムの異常状態を前記終了時条件とし、
前記状態遷移経路有無判定手段によって、前記終状態値から前記初期状態値に到達する状態遷移経路が存在すると判定される場合には、前記システムの故障によって前記統合システムの異常状態が発生すると判定することを特徴とする故障ツリー解析装置。
請求項１に記載のシステム解析装置を含む自律動作装置であって、
前記システムが複数相互接続される統合システムと、
前記統合システムの動作中に、前記システムの故障を検出する故障検出手段と、
前記故障が発生したシステムの排除を制約条件として追加する制約条件追加手段と、
前記システム解析装置によって前記故障したシステムを排除した状態での動作継続可能性を判定する動作継続可能性判定手段とを備え、
前記統合システムが正常時に充足する機能要件を前記開始時条件として設定し、
前記システムの故障によって発生する前記統合システムの異常状態を前記終了時条件とし、
前記動作継続可能性判定手段は、前記状態遷移経路有無判定手段によって、前記終状態値から前記初期状態値に到達する状態遷移経路が存在すると判定される場合には、動作継続可能と判定することを特徴とする自律動作装置。
請求項６に記載の自律動作装置と、
前記自律動作装置を操作するオペレーション装置とを備え、
前記自律動作装置は、前記動作継続可能性判定手段によって動作継続不能と判定された場合には、前記オペレーション装置に対してエラー信号を送信し、
前記動作継続可能性判定手段によって動作継続可能と判定された場合には、前記オペレーション装置に警告信号を送信し、且つ、自律動作を継続することを特徴とする自律動作制御システム。
請求項１に記載のシステム解析装置であって、
前記状態遷移経路有無判定手段により判定された前記状態遷移経路に対応するタイムチャートを表示することを特徴とするシステム解析装置。
請求項１に記載のシステム解析装置であって、
前記システムは複数のサブシステムを有し、サブシステム毎に定義した故障モードを、前記内部状態である動作モードに追加することを特徴とするシステム解析装置。
請求項１に記載のシステム解析装置であって、
入出力信号値及び内部状態を併せて状態値を定義し、
逆探索する範囲を設定すると共に、前記設定された逆探索する範囲内で所望とする状態遷移列を不定値のまま維持し、当該状態遷移列を前記ＳＡＴソルバを用いて算出し、
前記不定値のまま維持される状態遷移列を構成する連続した二つの状態値の間の制約条件を設定し、
前記状態遷移列の各状態値に対して、システムの機能要件及び動作上の限界に相当する制約条件を設定し、
前記状態遷移列の始状態に対して、開始時条件を満たすことを制約条件として設定し、
前記状態遷移列の終状態に対して、終了時条件を満たすことを制約条件として設定し、
前記ＳＡＴソルバを用いて、前記設定されたすべての制約条件を満たし、前記不定値のまま維持される状態遷移列の有無を探索することを特徴とするシステム解析装置。
入力によって内部状態が変化し、且つ、前記内部状態の変化に応じて入力に対する出力が変化するシステムを対象とし、前記システムの状態遷移規則に基づいて、前記システムが採り得る複数の状態値と各状態値間の遷移経路とを含む状態遷移モデルを構築する状態遷移モデル構築手段と、前記複数の状態値の中から所定の開始時条件を満たす初期状態値を設定する初期状態値設定手段と、前記複数の状態値の中から所定の終了時条件を満たす終状態値を設定する終状態値設定手段と、前記状態遷移モデルの中に、前記終状態値から前記初期状態値に到達する状態遷移経路が存在するか否かを判定する状態遷移経路有無判定手段と、を有するシステム解析装置と、
前記システムが複数相互接続される統合システムと、
前記統合システムの動作中に、前記システムの故障を検出する故障検出手段と、
前記故障が発生したシステムの排除を制約条件として追加する制約条件追加手段と、
前記システム解析装置によって前記故障したシステムを排除した状態での動作継続可能性を判定する動作継続可能性判定手段と、を備え、
前記統合システムが正常時に充足する機能要件を前記開始時条件として設定し、
前記システムの故障によって発生する前記統合システムの異常状態を前記終了時条件とし、
前記動作継続可能性判定手段は、前記状態遷移経路有無判定手段によって、前記終状態値から前記初期状態値に到達する状態遷移経路が存在すると判定される場合には、動作継続可能と判定することを特徴とする自律動作装置。
請求項１１に記載の自律動作装置と、
前記自律動作装置を操作するオペレーション装置とを備え、
前記自律動作装置は、前記動作継続可能性判定手段によって動作継続不能と判定された場合には、前記オペレーション装置に対してエラー信号を送信し、
前記動作継続可能性判定手段によって動作継続可能と判定された場合には、前記オペレーション装置に警告信号を送信し、且つ、自律動作を継続することを特徴とする自律動作制御システム。