JPH07307771A - プロトコルの論理検証方法 - Google Patents
プロトコルの論理検証方法Info
- Publication number
- JPH07307771A JPH07307771A JP6098312A JP9831294A JPH07307771A JP H07307771 A JPH07307771 A JP H07307771A JP 6098312 A JP6098312 A JP 6098312A JP 9831294 A JP9831294 A JP 9831294A JP H07307771 A JPH07307771 A JP H07307771A
- Authority
- JP
- Japan
- Prior art keywords
- state
- transition
- protocol
- generated
- system state
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/03—Protocol definition or specification
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Debugging And Monitoring (AREA)
- Communication Control (AREA)
- Maintenance And Management Of Digital Transmission (AREA)
Abstract
(57)【要約】
【目的】 大規模あるいは複雑なプロトコル仕様であっ
ても、大きなメモリを必要とせず、また実用的な時間内
で検証を行うこと。 【構成】 プロトコルの論理検証処理を第１の処理ステ
ップＳ１と第２の処理ステップＳ２の２段階に分け、第
１の処理ステップＳ１ではプロトコル仕様が有する遷移
情報に従って、各プロセスの実行可能な状態遷移のみか
らなるプロセス毎の状態遷移グラフを生成し、同時にプ
ロセスの動作に関連するプロトコル誤りを検出し、第２
の処理ステップＳ２では第１の処理ステップで生成され
たプロセス毎の状態遷移グラフが有する遷移情報に従っ
て、各プロセスの状態と各チャネルの状態との組み合わ
せで定義されるシステム状態のうち到達可能なシステム
状態を順次生成し、生成した到達可能なシステム状態の
うちで、それ以上先へ遷移することができないシステム
の状態をデッドロックとして検出することにより、シス
テム状態の個数を少なくし、また不要なシステム状態を
メモリから消去できるようにし、また検索処理を少なく
する。
ても、大きなメモリを必要とせず、また実用的な時間内
で検証を行うこと。 【構成】 プロトコルの論理検証処理を第１の処理ステ
ップＳ１と第２の処理ステップＳ２の２段階に分け、第
１の処理ステップＳ１ではプロトコル仕様が有する遷移
情報に従って、各プロセスの実行可能な状態遷移のみか
らなるプロセス毎の状態遷移グラフを生成し、同時にプ
ロセスの動作に関連するプロトコル誤りを検出し、第２
の処理ステップＳ２では第１の処理ステップで生成され
たプロセス毎の状態遷移グラフが有する遷移情報に従っ
て、各プロセスの状態と各チャネルの状態との組み合わ
せで定義されるシステム状態のうち到達可能なシステム
状態を順次生成し、生成した到達可能なシステム状態の
うちで、それ以上先へ遷移することができないシステム
の状態をデッドロックとして検出することにより、シス
テム状態の個数を少なくし、また不要なシステム状態を
メモリから消去できるようにし、また検索処理を少なく
する。
Description
【０００１】
【産業上の利用分野】本発明は、プロトコル仕様を入力
として、そのプロトコルを実現した際にシステムが取り
得る動作を調べることにより、入力されたプロトコル仕
様に含まれるプロトコル誤りを検出するための論理検証
方法に関する。
として、そのプロトコルを実現した際にシステムが取り
得る動作を調べることにより、入力されたプロトコル仕
様に含まれるプロトコル誤りを検出するための論理検証
方法に関する。
【０００２】
＜用語の説明＞まず、本明細書に現われる用語のうち、
主なものについて予め説明しておく。 （１）プロトコル：プロトコルとは、複数のモジュール
（交換機、端末等の各種通信装置、あるいは装置内の論
理機能部など）が信号を送受しながら全体として所定の
目的を達成するようなシステムにおける、モジュール間
の通信規約を言う。 （２）プロセス：プロセスとは、プロトコルにおける通
信主体であるモジュールを言う。 （３）チャネル：チャネルとはプロセス間に存在する方
向性を持った信号伝送路を言い、信号の送受は必ず送信
プロセスから受信プロセスへのチャネルを通して行われ
る。 （４）送信と受信：送信とは或るプロセスが相手先プロ
セスへのチャネルに信号を１つ入れることを言い、受信
とは或るプロセスがそのプロセスへのチャネルの先頭か
ら信号を１つ取り出すことを言い、チャネルからの信号
の取り出しはそのチャネルに入れられた順に行われる。
なお、送信された信号が受信されるまでの時間的制約は
なく、従って、原則として送信した信号は必ずいつか受
信される。 （５）プロセスの状態：プロセスの状態とはプロセスが
動作して取る状態を言い、例えば、ＲＥＡＤＹやＩＤＬ
Ｅ，ＷＡＩＴ，ＲＥＧＩＳＴＥＲ，ＳＥＲＶＩＣＥ及び
ＦＡＵＬＴ等の各種状態があり、プロセスは信号の送信
または受信を行う都度その状態を遷移する。どれを初期
状態にするかの設定は自由である。 （６）送信遷移と受信遷移：送信遷移とはプロセスの状
態遷移のうち送信を伴うものを言い、受信遷移とは受信
を伴うプロセスの状態遷移を言う。 （７）プロトコル仕様；プロトコル仕様とは、或るシス
テムにおける各プロセスが取るべき動作を記述したもの
を言う。 （８）チャネルの状態：チャネルの状態とは、チャネル
にどの信号が幾つ、どのような順番で入っているかを示
すものであり、信号の数がゼロの場合にはチャネルが空
であるという。 （９）システム状態：システム状態とは、システム全体
での各プロセスの状態と各チャネルの状態との組として
定義され、送信または受信が実行されると、プロセスの
状態もチャネルの状態も変わるのでシステム状態が遷移
する。 （10）初期システム状態：初期システム状態とは、全て
のプロセスが初期状態にあり、且つ、全てのチャネルが
空であるシステム状態を言う。 （11）安定状態：安定状態とは全てのチャネルが空であ
るシステム状態を言う。 （12）到達可能なシステム状態：到達可能なシステム状
態とは、初期システム状態から実行可能な状態遷移を実
行することにより到達するシステム状態、並びに初期シ
ステム状態自体を言う。 （13）到達可能なプロセス状態：到達可能なプロセス状
態とは、到達可能なシステム状態を構成するプロセスの
状態を言う。 （14）実行可能な状態遷移：実行可能な状態遷移には実
行可能な送信遷移と実行可能な受信遷移とがある。実行
可能な送信遷移とは、到達可能なプロセス状態からの送
信遷移を言う。実行可能な受信遷移とは、到達可能なプ
ロセス状態からの受信遷移のうち、その受信信号がチャ
ネルの先頭にあり、且つ、その到達可能なプロセス状態
を含む到達可能なシステム状態が存在するものを言う。 （15）プロトコル誤り：プロトコル仕様はシステム状態
の到達可能性、あるいはプロセスの状態遷移の実行可能
性などを考慮せずに記述することができる。そのために
プロトコル内部に論理的矛盾を含む可能性があり、プロ
トコル仕様に含まれる論理的内部矛盾をプロトコル誤り
という。プロトコル誤りには、デッドロックと、各プロ
セスの動作に関連するものとがある。 （16）デッドロック：デッドロックとは、システム状態
を構成するいずれのプロセスにも実行可能な状態遷移が
ないため、それ以上先へ遷移することができないシステ
ム状態を言う。 （17）各プロセスの動作に関連するプロトコル誤り：こ
のプロトコル誤りには、例えば定義済み実行不能遷移、
オーバフロー、未定義実行可能受信遷移などがある。定
義済み実行不能遷移とは、プロトコル仕様では定義され
ているが、実行可能ではない状態遷移を言う。オーバフ
ローとは、所定のチャネル容量を越えてプロセスが信号
を送信した状態を言う。未定義実行可能受信遷移とは、
実行可能ではあるが、プロトコル仕様に定義されていな
い受信遷移を言う。
主なものについて予め説明しておく。 （１）プロトコル：プロトコルとは、複数のモジュール
（交換機、端末等の各種通信装置、あるいは装置内の論
理機能部など）が信号を送受しながら全体として所定の
目的を達成するようなシステムにおける、モジュール間
の通信規約を言う。 （２）プロセス：プロセスとは、プロトコルにおける通
信主体であるモジュールを言う。 （３）チャネル：チャネルとはプロセス間に存在する方
向性を持った信号伝送路を言い、信号の送受は必ず送信
プロセスから受信プロセスへのチャネルを通して行われ
る。 （４）送信と受信：送信とは或るプロセスが相手先プロ
セスへのチャネルに信号を１つ入れることを言い、受信
とは或るプロセスがそのプロセスへのチャネルの先頭か
ら信号を１つ取り出すことを言い、チャネルからの信号
の取り出しはそのチャネルに入れられた順に行われる。
なお、送信された信号が受信されるまでの時間的制約は
なく、従って、原則として送信した信号は必ずいつか受
信される。 （５）プロセスの状態：プロセスの状態とはプロセスが
動作して取る状態を言い、例えば、ＲＥＡＤＹやＩＤＬ
Ｅ，ＷＡＩＴ，ＲＥＧＩＳＴＥＲ，ＳＥＲＶＩＣＥ及び
ＦＡＵＬＴ等の各種状態があり、プロセスは信号の送信
または受信を行う都度その状態を遷移する。どれを初期
状態にするかの設定は自由である。 （６）送信遷移と受信遷移：送信遷移とはプロセスの状
態遷移のうち送信を伴うものを言い、受信遷移とは受信
を伴うプロセスの状態遷移を言う。 （７）プロトコル仕様；プロトコル仕様とは、或るシス
テムにおける各プロセスが取るべき動作を記述したもの
を言う。 （８）チャネルの状態：チャネルの状態とは、チャネル
にどの信号が幾つ、どのような順番で入っているかを示
すものであり、信号の数がゼロの場合にはチャネルが空
であるという。 （９）システム状態：システム状態とは、システム全体
での各プロセスの状態と各チャネルの状態との組として
定義され、送信または受信が実行されると、プロセスの
状態もチャネルの状態も変わるのでシステム状態が遷移
する。 （10）初期システム状態：初期システム状態とは、全て
のプロセスが初期状態にあり、且つ、全てのチャネルが
空であるシステム状態を言う。 （11）安定状態：安定状態とは全てのチャネルが空であ
るシステム状態を言う。 （12）到達可能なシステム状態：到達可能なシステム状
態とは、初期システム状態から実行可能な状態遷移を実
行することにより到達するシステム状態、並びに初期シ
ステム状態自体を言う。 （13）到達可能なプロセス状態：到達可能なプロセス状
態とは、到達可能なシステム状態を構成するプロセスの
状態を言う。 （14）実行可能な状態遷移：実行可能な状態遷移には実
行可能な送信遷移と実行可能な受信遷移とがある。実行
可能な送信遷移とは、到達可能なプロセス状態からの送
信遷移を言う。実行可能な受信遷移とは、到達可能なプ
ロセス状態からの受信遷移のうち、その受信信号がチャ
ネルの先頭にあり、且つ、その到達可能なプロセス状態
を含む到達可能なシステム状態が存在するものを言う。 （15）プロトコル誤り：プロトコル仕様はシステム状態
の到達可能性、あるいはプロセスの状態遷移の実行可能
性などを考慮せずに記述することができる。そのために
プロトコル内部に論理的矛盾を含む可能性があり、プロ
トコル仕様に含まれる論理的内部矛盾をプロトコル誤り
という。プロトコル誤りには、デッドロックと、各プロ
セスの動作に関連するものとがある。 （16）デッドロック：デッドロックとは、システム状態
を構成するいずれのプロセスにも実行可能な状態遷移が
ないため、それ以上先へ遷移することができないシステ
ム状態を言う。 （17）各プロセスの動作に関連するプロトコル誤り：こ
のプロトコル誤りには、例えば定義済み実行不能遷移、
オーバフロー、未定義実行可能受信遷移などがある。定
義済み実行不能遷移とは、プロトコル仕様では定義され
ているが、実行可能ではない状態遷移を言う。オーバフ
ローとは、所定のチャネル容量を越えてプロセスが信号
を送信した状態を言う。未定義実行可能受信遷移とは、
実行可能ではあるが、プロトコル仕様に定義されていな
い受信遷移を言う。
【０００３】＜２つの従来方法＞従来のプロトコルの論
理検証方法として、初期システム状態から到達可能なシ
ステム状態を全て、あるいは、そのうちで必要な部分集
合を列挙する方法が多く報告されていた（例えば、C.H.
West："General technique for communicationsprotoco
l validation"，ＩＢＭ J.Res.Devel.,July 1978）。
このような方法を以降、「第１従来方法」と呼ぶ。これ
に対して、各プロセスの状態で信号が送信可能であるた
めの条件及び受信が可能であるための条件に従い、プロ
セス毎に実行可能な状態遷移を調べて、プロセス毎の状
態遷移グラフを生成する方法が報告されている（例え
ば、特公平３−１３７７９号（特許第１６４７４４５
号）の「プロトコルの論理検証方式」、あるいは、D.Br
and and P.Zafiropulo：“On communicating finite-st
ate machine"，ＩＢＭ Res.Rep.ＲＺ 1053,1981）。こ
のような方法を以降、「第２従来方法」と呼ぶ。
理検証方法として、初期システム状態から到達可能なシ
ステム状態を全て、あるいは、そのうちで必要な部分集
合を列挙する方法が多く報告されていた（例えば、C.H.
West："General technique for communicationsprotoco
l validation"，ＩＢＭ J.Res.Devel.,July 1978）。
このような方法を以降、「第１従来方法」と呼ぶ。これ
に対して、各プロセスの状態で信号が送信可能であるた
めの条件及び受信が可能であるための条件に従い、プロ
セス毎に実行可能な状態遷移を調べて、プロセス毎の状
態遷移グラフを生成する方法が報告されている（例え
ば、特公平３−１３７７９号（特許第１６４７４４５
号）の「プロトコルの論理検証方式」、あるいは、D.Br
and and P.Zafiropulo：“On communicating finite-st
ate machine"，ＩＢＭ Res.Rep.ＲＺ 1053,1981）。こ
のような方法を以降、「第２従来方法」と呼ぶ。
【０００４】＜第１従来方法の概要＞以下に第１従来方
法の概要を説明する。第１従来方法では、プロトコル仕
様を基にして、初期システム状態から実行可能な状態遷
移を１つずつ実行して新たな到達可能なシステム状態を
次々に生成し、全てメモリに記憶してゆく。そして、各
システム状態の生成時に、その時点まで既に生成されて
いる全てのシステム状態との比較を行って、等しいシス
テム状態が既に生成されているか否かを調べ、既に生成
されていれば、以降の遷移系列は既に生成されたものの
繰り返しになるため、その遷移系列の新たなシステム状
態の生成を中止し、他の遷移系列でのシステム状態の生
成を行う。このようにして全ての到達可能なシステム状
態を生成しながら、デッドロックを含めてプロトコル誤
りを検出する。
法の概要を説明する。第１従来方法では、プロトコル仕
様を基にして、初期システム状態から実行可能な状態遷
移を１つずつ実行して新たな到達可能なシステム状態を
次々に生成し、全てメモリに記憶してゆく。そして、各
システム状態の生成時に、その時点まで既に生成されて
いる全てのシステム状態との比較を行って、等しいシス
テム状態が既に生成されているか否かを調べ、既に生成
されていれば、以降の遷移系列は既に生成されたものの
繰り返しになるため、その遷移系列の新たなシステム状
態の生成を中止し、他の遷移系列でのシステム状態の生
成を行う。このようにして全ての到達可能なシステム状
態を生成しながら、デッドロックを含めてプロトコル誤
りを検出する。
【０００５】＜第１従来方法の問題点＞前述の通り、シ
ステム状態はプロセスの状態とチャネルの状態との組み
合せで定義される。そのため、到達可能なシステム状態
を列挙する第１従来方法においては、或る１つのプロセ
スの１つの状態遷移に対しても、新たなシステム状態を
生成しなければならない。このことは、プロセスの個数
が少し増えたり、あるいはプロトコル仕様の動作が少し
複雑になるだけで、列挙すべきシステム状態の個数が大
幅に増大することを意味する。従って、第１従来方法で
大規模な、あるいは複雑なプロトコル仕様を検証する場
合には、多数のシステム状態を記憶するための膨大な容
量のメモリ装置が必要となり、また、記憶したシステム
状態の個数が増えるにつれて、等しいシステム状態が既
に生成されているか否かを調べるための検索に莫大な処
理時間がかかるようになる。
ステム状態はプロセスの状態とチャネルの状態との組み
合せで定義される。そのため、到達可能なシステム状態
を列挙する第１従来方法においては、或る１つのプロセ
スの１つの状態遷移に対しても、新たなシステム状態を
生成しなければならない。このことは、プロセスの個数
が少し増えたり、あるいはプロトコル仕様の動作が少し
複雑になるだけで、列挙すべきシステム状態の個数が大
幅に増大することを意味する。従って、第１従来方法で
大規模な、あるいは複雑なプロトコル仕様を検証する場
合には、多数のシステム状態を記憶するための膨大な容
量のメモリ装置が必要となり、また、記憶したシステム
状態の個数が増えるにつれて、等しいシステム状態が既
に生成されているか否かを調べるための検索に莫大な処
理時間がかかるようになる。
【０００６】＜第２従来方法の概要＞次に、第２従来方
法の概要を図２，図３及び図９を参照して説明する。図
２にはプロセスの個数がプロセス１とプロセス２との計
２つの場合のプロトコル仕様の一例が示され、図３には
図２に示されたプロトコル仕様をメモリに記憶する等の
ために電気信号で表現する場合の一記憶形式例が示さ
れ、図９には図２に示されたプロトコル仕様を検証対象
とした場合に第２従来方法により生成されるプロセス毎
の状態遷移グラフが示されている。
法の概要を図２，図３及び図９を参照して説明する。図
２にはプロセスの個数がプロセス１とプロセス２との計
２つの場合のプロトコル仕様の一例が示され、図３には
図２に示されたプロトコル仕様をメモリに記憶する等の
ために電気信号で表現する場合の一記憶形式例が示さ
れ、図９には図２に示されたプロトコル仕様を検証対象
とした場合に第２従来方法により生成されるプロセス毎
の状態遷移グラフが示されている。
【０００７】図２に示されたプロトコル仕様例におい
て、長円は各プロセス１，２の各状態を表わし、長円内
に状態名（ＲＥＡＤＹ，ＷＡＩＴ，ＲＥＧＩＳＴＥＲ，
ＩＤＬＥ，ＳＥＲＶＩＣＥ，ＦＡＵＬＴ）が示されてい
る。ここでは状態名に下線が付いた状態（ＲＥＡＤＹ，
ＩＤＬＥ）は初期状態を表わす。長円を結ぶ矢印は状態
遷移を表わし、矢印上には状態遷移時に送信あるいは受
信される信号名（ＲＥＱ，ＡＣＫ，ＤＯＮＥ，ＡＬＡＲ
Ｍ）が、送信の場合は「−」記号とともに、受信の場合
は「＋」記号とともに付与されている。従って図２のプ
ロトコル仕様では、例えば、プロセス１は初期状態ＲＥ
ＡＤＹからプロセス２に対して信号ＲＥＱを送信するこ
とにより状態ＷＡＩＴに遷移すること、またプロセス１
は信号ＲＥＱの送信前にプロセス２からの信号ＡＬＡＲ
Ｍを受信した際には状態ＲＥＧＩＳＴＥＲに遷移するこ
と、等の通信規約が規定されている。なお、信号名のう
ち、例えば、ＲＥＱは送信要求信号、ＡＣＫは肯定受信
応答信号、ＤＯＮＥは作業終了通知信号、ＡＬＡＲＭは
異常警報信号を表わしている。
て、長円は各プロセス１，２の各状態を表わし、長円内
に状態名（ＲＥＡＤＹ，ＷＡＩＴ，ＲＥＧＩＳＴＥＲ，
ＩＤＬＥ，ＳＥＲＶＩＣＥ，ＦＡＵＬＴ）が示されてい
る。ここでは状態名に下線が付いた状態（ＲＥＡＤＹ，
ＩＤＬＥ）は初期状態を表わす。長円を結ぶ矢印は状態
遷移を表わし、矢印上には状態遷移時に送信あるいは受
信される信号名（ＲＥＱ，ＡＣＫ，ＤＯＮＥ，ＡＬＡＲ
Ｍ）が、送信の場合は「−」記号とともに、受信の場合
は「＋」記号とともに付与されている。従って図２のプ
ロトコル仕様では、例えば、プロセス１は初期状態ＲＥ
ＡＤＹからプロセス２に対して信号ＲＥＱを送信するこ
とにより状態ＷＡＩＴに遷移すること、またプロセス１
は信号ＲＥＱの送信前にプロセス２からの信号ＡＬＡＲ
Ｍを受信した際には状態ＲＥＧＩＳＴＥＲに遷移するこ
と、等の通信規約が規定されている。なお、信号名のう
ち、例えば、ＲＥＱは送信要求信号、ＡＣＫは肯定受信
応答信号、ＤＯＮＥは作業終了通知信号、ＡＬＡＲＭは
異常警報信号を表わしている。
【０００８】図３に示されたプロトコル仕様の記憶形式
例においては、プロセス名（１と２）と、プロセスの状
態名と、その状態からの各状態遷移とを組にして、全て
の組が列挙されている。各状態遷移は括弧（）内に送信
と受信の識別記号「＋」，「−」付きの信号名を入れ、
その次に遷移先の状態名を続けることにより、表わされ
ている。
例においては、プロセス名（１と２）と、プロセスの状
態名と、その状態からの各状態遷移とを組にして、全て
の組が列挙されている。各状態遷移は括弧（）内に送信
と受信の識別記号「＋」，「−」付きの信号名を入れ、
その次に遷移先の状態名を続けることにより、表わされ
ている。
【０００９】図９に示されたプロセス１，２毎の状態遷
移グラフはノードと矢印からなり、長円形のノードはプ
ロセスの状態を表わし、ノードを結ぶ矢印は実行可能な
状態遷移を表わしている。ノードの状態名にはピリオド
「．」と数字が付与されており、この数字は、異なる遷
移系列により到達した同じ名の状態を区別するための識
別子である。矢印上には、図２のプロトコル仕様と同様
に、状態遷移に伴い実行される送信あるいは受信の信号
名が付与されている。
移グラフはノードと矢印からなり、長円形のノードはプ
ロセスの状態を表わし、ノードを結ぶ矢印は実行可能な
状態遷移を表わしている。ノードの状態名にはピリオド
「．」と数字が付与されており、この数字は、異なる遷
移系列により到達した同じ名の状態を区別するための識
別子である。矢印上には、図２のプロトコル仕様と同様
に、状態遷移に伴い実行される送信あるいは受信の信号
名が付与されている。
【００１０】また各ノードには、或るプロセスが当該ノ
ードが表わす状態に到達した時点で、他の各プロセスが
最小限必要な遷移により到達しているはずの状態が付与
されている。この状態を以降簡単のため、或るプロセス
の状態に対する他の各プロセスの「最小状態」と呼ぶ。
例えば図９には、プロセス１の状態ＷＡＩＴ．２に対す
るプロセス２の最小状態として、ＦＡＵＬＴ．０が記さ
れている。これは、プロセス１が状態ＷＡＩＴ．２に到
達するためには、プロセス２は、最小でも信号ＡＬＡＲ
Ｍを送信して、ＦＡＵＬＴ．０に到達していることが必
要であることを意味している。なお、図９の例ではシス
テムのプロセス個数が２つなので、最小状態は相手のプ
ロセスの状態のみとなり、最小状態は各ノードの右上の
括弧（）内に示されている。
ードが表わす状態に到達した時点で、他の各プロセスが
最小限必要な遷移により到達しているはずの状態が付与
されている。この状態を以降簡単のため、或るプロセス
の状態に対する他の各プロセスの「最小状態」と呼ぶ。
例えば図９には、プロセス１の状態ＷＡＩＴ．２に対す
るプロセス２の最小状態として、ＦＡＵＬＴ．０が記さ
れている。これは、プロセス１が状態ＷＡＩＴ．２に到
達するためには、プロセス２は、最小でも信号ＡＬＡＲ
Ｍを送信して、ＦＡＵＬＴ．０に到達していることが必
要であることを意味している。なお、図９の例ではシス
テムのプロセス個数が２つなので、最小状態は相手のプ
ロセスの状態のみとなり、最小状態は各ノードの右上の
括弧（）内に示されている。
【００１１】以下、第２従来方法によるプロトコル論理
検証の処理手順を説明する。
検証の処理手順を説明する。
【００１２】 まず、初期状態を表わす初期ノードを
各プロセスに対して生成し、各プロセスの初期ノードに
それぞれの初期状態に対する他の各プロセスの最小状態
として、他の各プロセスの初期状態を設定する。例えば
プロセス２について言えば、図９で初期状態ＩＤＬＥ．
０を表わす初期ノードを生成した時に、他のプロセス１
の初期状態ＲＥＡＤＹ．０を、プロセス２の初期状態Ｉ
ＤＬＥ．０に対するプロセス１の最小状態として、プロ
セス２の初期ノードに設定する。
各プロセスに対して生成し、各プロセスの初期ノードに
それぞれの初期状態に対する他の各プロセスの最小状態
として、他の各プロセスの初期状態を設定する。例えば
プロセス２について言えば、図９で初期状態ＩＤＬＥ．
０を表わす初期ノードを生成した時に、他のプロセス１
の初期状態ＲＥＡＤＹ．０を、プロセス２の初期状態Ｉ
ＤＬＥ．０に対するプロセス１の最小状態として、プロ
セス２の初期ノードに設定する。
【００１３】 次に、実行可能な送信遷移の付加と、
実行可能な受信遷移の付加を繰り返してプロセス毎に状
態遷移グラフを生成し、それと同時にデッドロック検出
のために安定状態（全てのチャネルが空であるシステム
状態）を全て求める。
実行可能な受信遷移の付加を繰り返してプロセス毎に状
態遷移グラフを生成し、それと同時にデッドロック検出
のために安定状態（全てのチャネルが空であるシステム
状態）を全て求める。
【００１４】 安定状態の求め方としては、まず、プ
ロセス毎の状態遷移グラフの生成のために最初に各プロ
セスの初期ノードを生成した時点で、全プロセスが初期
状態にある初期システム状態（例えばＲＥＡＤＹ．０，
ＩＤＬＥ．０）は安定状態であるから、この安定状態を
生成し、安定状態集合の要素としてメモリに記憶する。
次に、プロセス毎の状態遷移グラフの生成の進行に伴
い、新たな受信遷移の付加によりノードが生成される度
に、既存の安定状態の集合の中から元になる安定状態を
探し、この探し出した安定状態における信号送信前の状
態を信号送信後の状態に置換し、且つ、信号受信前の状
態を信号受信後の状態に置換する形で、新たな安定状態
を生成する。そして、この新たな安定状態をメモリに記
憶して安定状態集合に追加する。例えば、図９におい
て、プロセス２の受信遷移＋ＲＥＱの付加により状態Ｓ
ＥＲＶＩＣＥ．０を表わすノードが生成されたとする
と、元になる安定状態（ＲＥＡＤＹ．０，ＩＤＬＥ．
０）を安定状態集合から探し出し、プロセス１の状態Ｒ
ＥＡＤＹ．０を送信遷移−ＲＥＱの実行後の状態ＷＡＩ
Ｔ．０に置換し、且つ、プロセス２の状態ＩＤＬＥ．０
を受信遷移＋ＲＥＱの実行後の状態ＳＥＲＶＩＣＥ．０
に置換することにより、新たな安定状態（ＷＡＩＴ．
０，ＳＥＲＶＩＣＥ．０）を生成し、安定状態集合に加
える。
ロセス毎の状態遷移グラフの生成のために最初に各プロ
セスの初期ノードを生成した時点で、全プロセスが初期
状態にある初期システム状態（例えばＲＥＡＤＹ．０，
ＩＤＬＥ．０）は安定状態であるから、この安定状態を
生成し、安定状態集合の要素としてメモリに記憶する。
次に、プロセス毎の状態遷移グラフの生成の進行に伴
い、新たな受信遷移の付加によりノードが生成される度
に、既存の安定状態の集合の中から元になる安定状態を
探し、この探し出した安定状態における信号送信前の状
態を信号送信後の状態に置換し、且つ、信号受信前の状
態を信号受信後の状態に置換する形で、新たな安定状態
を生成する。そして、この新たな安定状態をメモリに記
憶して安定状態集合に追加する。例えば、図９におい
て、プロセス２の受信遷移＋ＲＥＱの付加により状態Ｓ
ＥＲＶＩＣＥ．０を表わすノードが生成されたとする
と、元になる安定状態（ＲＥＡＤＹ．０，ＩＤＬＥ．
０）を安定状態集合から探し出し、プロセス１の状態Ｒ
ＥＡＤＹ．０を送信遷移−ＲＥＱの実行後の状態ＷＡＩ
Ｔ．０に置換し、且つ、プロセス２の状態ＩＤＬＥ．０
を受信遷移＋ＲＥＱの実行後の状態ＳＥＲＶＩＣＥ．０
に置換することにより、新たな安定状態（ＷＡＩＴ．
０，ＳＥＲＶＩＣＥ．０）を生成し、安定状態集合に加
える。
【００１５】 一方、プロセス毎の状態遷移グラフの
生成においては、新たな実行可能な状態遷移の付加によ
り新たなノードを生成する度に、そのノードでの状態に
対する他の各プロセスの最小状態をノードに設定する。
例えばプロセス２について言えば、図９で初期ノードに
信号ＲＥＱの受信遷移を付加して状態ＳＥＲＶＩＣＥ．
０を表わすノードを生成したときは、同状態ＳＥＲＶＩ
ＣＥ．０に対するプロセス１の最小状態ＷＡＩＴ．０を
設定する。
生成においては、新たな実行可能な状態遷移の付加によ
り新たなノードを生成する度に、そのノードでの状態に
対する他の各プロセスの最小状態をノードに設定する。
例えばプロセス２について言えば、図９で初期ノードに
信号ＲＥＱの受信遷移を付加して状態ＳＥＲＶＩＣＥ．
０を表わすノードを生成したときは、同状態ＳＥＲＶＩ
ＣＥ．０に対するプロセス１の最小状態ＷＡＩＴ．０を
設定する。
【００１６】また、プロセス毎の状態遷移グラフの生成
中、或るプロセス内の２つのノードが、下記Ａ，Ｂ，Ｃ
全ての条件に該当する場合は、これら２つのノードから
起こり得る状態遷移は等しくなるので、どちらか一方へ
の送信遷移の付加を停止する。 条件Ａ：識別子を除いてノードが表わす状態名が等し
い。 条件Ｂ：識別子を除いてノードに設定されている最小状
態が等しい。 条件Ｃ：ノードが表わす状態と同ノードに設定されてい
る最小状態とからなるシステム状態におけるチャネルの
状態が等しい。
中、或るプロセス内の２つのノードが、下記Ａ，Ｂ，Ｃ
全ての条件に該当する場合は、これら２つのノードから
起こり得る状態遷移は等しくなるので、どちらか一方へ
の送信遷移の付加を停止する。 条件Ａ：識別子を除いてノードが表わす状態名が等し
い。 条件Ｂ：識別子を除いてノードに設定されている最小状
態が等しい。 条件Ｃ：ノードが表わす状態と同ノードに設定されてい
る最小状態とからなるシステム状態におけるチャネルの
状態が等しい。
【００１７】上述したような等価性を理由に以降の送信
遷移の付加を停止したノードが表わす状態を、便宜上
「等価停止状態」と呼ぶことにする。例えば図９のプロ
セス１において、状態ＲＥＡＤＹ．２は状態ＲＥＡＤ
Ｙ．０と等価であるため、等価停止状態となっている。
しかし、状態ＷＡＩＴ．１と状態ＷＡＩＴ．２はチャネ
ルの状態が異なっているので、等価ではない。一方、プ
ロセス２では、状態ＩＤＬＥ．２は状態ＩＤＬＥ．０と
等価であるため、等価停止状態となっている。
遷移の付加を停止したノードが表わす状態を、便宜上
「等価停止状態」と呼ぶことにする。例えば図９のプロ
セス１において、状態ＲＥＡＤＹ．２は状態ＲＥＡＤ
Ｙ．０と等価であるため、等価停止状態となっている。
しかし、状態ＷＡＩＴ．１と状態ＷＡＩＴ．２はチャネ
ルの状態が異なっているので、等価ではない。一方、プ
ロセス２では、状態ＩＤＬＥ．２は状態ＩＤＬＥ．０と
等価であるため、等価停止状態となっている。
【００１８】 以上のようなプロセス毎の状態遷移グ
ラフを生成することにより、プロセスの動作に関連する
プロトコル誤りを検出する。即ち、或るプロセスの状態
遷移グラフを生成する場合、実行可能な状態遷移のうち
受信遷移を付加する際に、その受信遷移がプロトコル仕
様に定義されているか否かを調べ、定義されていなけれ
ば未定義実行可能受信遷移と判定する。また、実行可能
な状態遷移のうち送信遷移を付加する際に、その遷移先
のノードに対する他のプロセスの最小状態に当該他のプ
ロセスが到達した場合の、チャネル内の信号数を調べ、
所定のチャネル容量を越えているならばオーバフローと
判定する。更に、全ての状態遷移グラフの生成終了後
に、プロトコル仕様に定義されてはいるが一度も状態遷
移グラフに付加されなかった状態遷移があるか否かを調
べ、付加されなかったものを定義済み実行不能遷移と判
定する。例えば、図２のプロトコル仕様におけるプロセ
ス２の状態ＳＥＲＶＩＣＥから、信号ＡＣＫの受信によ
り同状態ＳＥＲＶＩＣＥに戻る受信遷移は、図９のプロ
セス２の状態遷移グラフに何も付加されないので、定義
済み実行不能遷移として検出される。
ラフを生成することにより、プロセスの動作に関連する
プロトコル誤りを検出する。即ち、或るプロセスの状態
遷移グラフを生成する場合、実行可能な状態遷移のうち
受信遷移を付加する際に、その受信遷移がプロトコル仕
様に定義されているか否かを調べ、定義されていなけれ
ば未定義実行可能受信遷移と判定する。また、実行可能
な状態遷移のうち送信遷移を付加する際に、その遷移先
のノードに対する他のプロセスの最小状態に当該他のプ
ロセスが到達した場合の、チャネル内の信号数を調べ、
所定のチャネル容量を越えているならばオーバフローと
判定する。更に、全ての状態遷移グラフの生成終了後
に、プロトコル仕様に定義されてはいるが一度も状態遷
移グラフに付加されなかった状態遷移があるか否かを調
べ、付加されなかったものを定義済み実行不能遷移と判
定する。例えば、図２のプロトコル仕様におけるプロセ
ス２の状態ＳＥＲＶＩＣＥから、信号ＡＣＫの受信によ
り同状態ＳＥＲＶＩＣＥに戻る受信遷移は、図９のプロ
セス２の状態遷移グラフに何も付加されないので、定義
済み実行不能遷移として検出される。
【００１９】 一方、プロセス毎の状態遷移グラフの
生成が全て終了後、それまでに求めた安定状態集合の中
から、何れのプロセスも送信遷移を持たないような安定
状態を探し出し、これをデッドロックとして検出する。
例えば、図９の例では、安定状態（ＷＡＩＴ．２，ＦＡ
ＵＬＴ．２）をデッドロックとして検出する。
生成が全て終了後、それまでに求めた安定状態集合の中
から、何れのプロセスも送信遷移を持たないような安定
状態を探し出し、これをデッドロックとして検出する。
例えば、図９の例では、安定状態（ＷＡＩＴ．２，ＦＡ
ＵＬＴ．２）をデッドロックとして検出する。
【００２０】＜第２従来方法の問題点＞第２従来方法
は、システム全体ではなくプロセス毎の状態遷移グラフ
を生成する。従って、到達可能なシステム状態を全て列
挙する第１従来方法が有する問題点を大幅に軽減するこ
とができる。しかし、デッドロック検出のために全ての
安定状態を求めるため、大規模な、あるいは複雑なプロ
トコル仕様に対しては、安定状態の生成処理に依然とし
て、膨大な容量のメモリが必要であり、また莫大な処理
時間がかかる。
は、システム全体ではなくプロセス毎の状態遷移グラフ
を生成する。従って、到達可能なシステム状態を全て列
挙する第１従来方法が有する問題点を大幅に軽減するこ
とができる。しかし、デッドロック検出のために全ての
安定状態を求めるため、大規模な、あるいは複雑なプロ
トコル仕様に対しては、安定状態の生成処理に依然とし
て、膨大な容量のメモリが必要であり、また莫大な処理
時間がかかる。
【００２１】
【発明が解決しようとする課題】本発明は上述した従来
技術の問題点を解消することができるプロトコルの論理
検証方法を提供することを目的とする。
技術の問題点を解消することができるプロトコルの論理
検証方法を提供することを目的とする。
【００２２】
【課題を解決するための手段】上記目的を達成する第１
の発明は、信号により表現されたプロトコル仕様を入力
として、このプロトコル仕様が有する遷移情報に従って
プロトコルの動作を調べることにより、同プロトコル仕
様に含まれるプロトコル誤りを検出するプロトコルの論
理検証方法において： 入力されたプロトコル仕様が有する前記遷移情報に
従って、各プロセスの実行可能な状態遷移のみからなる
プロセス毎の状態遷移グラフを生成し、同時に、各プロ
セスの動作に関連するプロトコル誤りを検出する第１の
処理ステップと； 第１の処理ステップで生成されたプロセス毎の状態
遷移グラフが有する遷移情報に従って、各プロセスの状
態と各チャネルの状態との組み合わせで定義されるシス
テム状態のうち到達可能なシステム状態を順次生成し、
生成した到達可能なシステム状態のうちで、それ以上先
へ遷移することができないシステム状態をデッドロック
として検出する第２の処理ステップと；を含むことを特
徴とするプロトコルの論理検証方法である。
の発明は、信号により表現されたプロトコル仕様を入力
として、このプロトコル仕様が有する遷移情報に従って
プロトコルの動作を調べることにより、同プロトコル仕
様に含まれるプロトコル誤りを検出するプロトコルの論
理検証方法において： 入力されたプロトコル仕様が有する前記遷移情報に
従って、各プロセスの実行可能な状態遷移のみからなる
プロセス毎の状態遷移グラフを生成し、同時に、各プロ
セスの動作に関連するプロトコル誤りを検出する第１の
処理ステップと； 第１の処理ステップで生成されたプロセス毎の状態
遷移グラフが有する遷移情報に従って、各プロセスの状
態と各チャネルの状態との組み合わせで定義されるシス
テム状態のうち到達可能なシステム状態を順次生成し、
生成した到達可能なシステム状態のうちで、それ以上先
へ遷移することができないシステム状態をデッドロック
として検出する第２の処理ステップと；を含むことを特
徴とするプロトコルの論理検証方法である。
【００２３】第２の発明は、第１の発明のプロトコルの
論理検証方法に加えて： 第１の処理ステップでは、前記プロセス毎の状態遷
移グラフの生成に際し、各送信遷移に対してその送信信
号の受信により受信プロセスが遷移する先の状態である
受信先状態を計算し、その情報を保持すること； 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、第１の処理ステップで保持された受
信先状態の情報を利用して、チャネルに未受信の信号を
含むシステム状態から、同信号を受信した後のシステム
状態を生成すること；を特徴とするプロトコルの論理検
証方法である。
論理検証方法に加えて： 第１の処理ステップでは、前記プロセス毎の状態遷
移グラフの生成に際し、各送信遷移に対してその送信信
号の受信により受信プロセスが遷移する先の状態である
受信先状態を計算し、その情報を保持すること； 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、第１の処理ステップで保持された受
信先状態の情報を利用して、チャネルに未受信の信号を
含むシステム状態から、同信号を受信した後のシステム
状態を生成すること；を特徴とするプロトコルの論理検
証方法である。
【００２４】第３の発明は、第１ないし第２いずれか一
つの発明のプロトコルの論理検証方法に加えて： 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルに未受信の信号を複数含む
システム状態から次のシステム状態を生成する場合は、
複数の未受信の信号のうちから最後に送信された信号を
選択し、この選択した信号を受信した後のシステム状態
を次のシステム状態として生成すること；を特徴とする
プロトコルの論理検証方法である。
つの発明のプロトコルの論理検証方法に加えて： 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルに未受信の信号を複数含む
システム状態から次のシステム状態を生成する場合は、
複数の未受信の信号のうちから最後に送信された信号を
選択し、この選択した信号を受信した後のシステム状態
を次のシステム状態として生成すること；を特徴とする
プロトコルの論理検証方法である。
【００２５】第４の発明は、第１ないし第３いずれか一
つの発明のプロトコルの論理検証方法に加えて： 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルが空のシステム状態から或
るプロセスの送信遷移を実行して次のシステム状態を生
成する場合に同送信遷移に続いて１つ以上の送信遷移が
連続して存在するときは、最初の送信遷移とそれに続く
一連の送信遷移を一括して実行した先の状態に当該プロ
セスを進めて、次のシステム状態を生成すること；を特
徴とするプロトコルの論理検証方法である。
つの発明のプロトコルの論理検証方法に加えて： 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルが空のシステム状態から或
るプロセスの送信遷移を実行して次のシステム状態を生
成する場合に同送信遷移に続いて１つ以上の送信遷移が
連続して存在するときは、最初の送信遷移とそれに続く
一連の送信遷移を一括して実行した先の状態に当該プロ
セスを進めて、次のシステム状態を生成すること；を特
徴とするプロトコルの論理検証方法である。
【００２６】第５の発明は、第１ないし第４いずれか一
つの発明のプロトコルの論理検証方法に加えて： 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルに未受信の信号を含むシス
テム状態から次のシステム状態を生成する場合に同信号
を受信すべき或るプロセスが同信号を受信した状態の先
に１つ以上の送信遷移が連続して存在するときは、同信
号の受信に続く一連の送信遷移を一括して実行した先の
状態に当該プロセスを進めて、次のシステム状態を生成
すること；を特徴とするプロトコルの論理検証方法であ
る。
つの発明のプロトコルの論理検証方法に加えて： 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルに未受信の信号を含むシス
テム状態から次のシステム状態を生成する場合に同信号
を受信すべき或るプロセスが同信号を受信した状態の先
に１つ以上の送信遷移が連続して存在するときは、同信
号の受信に続く一連の送信遷移を一括して実行した先の
状態に当該プロセスを進めて、次のシステム状態を生成
すること；を特徴とするプロトコルの論理検証方法であ
る。
【００２７】第６の発明は、第１ないし第５いずれか一
つの発明のプロトコルの論理検証方法に加えて： 第１の処理ステップでは、前記プロセス毎の状態遷
移グラフの生成に際し、各プロセスが各状態に到達する
ために他のプロセスが最小限必要な遷移により到達する
状態を最小状態として計算し、その情報を保持するこ
と； 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルに未受信の信号を含むシス
テム状態から次のシステム状態を生成する場合に、同信
号を受信すべき受信プロセス以外の他のプロセスについ
ては第１の処理ステップで保持された最小状態の情報を
利用して、受信プロセスが遷移先の状態に到達するため
の当該他のプロセスの最小状態が生成元のシステム状態
を構成する状態よりも進んでいれば、当該他のプロセス
の状態を前記最小状態まで進めて、次のシステム状態を
生成すること；を特徴とするプロトコルの論理検証方法
である。
つの発明のプロトコルの論理検証方法に加えて： 第１の処理ステップでは、前記プロセス毎の状態遷
移グラフの生成に際し、各プロセスが各状態に到達する
ために他のプロセスが最小限必要な遷移により到達する
状態を最小状態として計算し、その情報を保持するこ
と； 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルに未受信の信号を含むシス
テム状態から次のシステム状態を生成する場合に、同信
号を受信すべき受信プロセス以外の他のプロセスについ
ては第１の処理ステップで保持された最小状態の情報を
利用して、受信プロセスが遷移先の状態に到達するため
の当該他のプロセスの最小状態が生成元のシステム状態
を構成する状態よりも進んでいれば、当該他のプロセス
の状態を前記最小状態まで進めて、次のシステム状態を
生成すること；を特徴とするプロトコルの論理検証方法
である。
【００２８】第７の発明は、第１ないし第６いずれか一
つの発明のプロトコルの論理検証方法に加えて： 第１の処理ステップでは、前記プロセス毎の状態遷
移グラフの生成に際し、同じプロセス内の２つの状態が
それぞれに続く遷移系列が全く等しくなるという意味で
等価である場合は、後から生成した方の状態については
プロセスの等価停止状態として以後の状態遷移グラフの
生成とプロトコル誤りの検出を中止し、この等価停止状
態の情報を保持すること； 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、第１の処理ステップで保持された等
価停止状態の情報を利用して、元となるシステム状態を
構成するプロセスの状態の中に前記等価停止状態が含ま
れる場合は、次に生成しようとしていたシステム状態の
生成処理を中止すること；を特徴とするプロトコルの論
理検証方法である。
つの発明のプロトコルの論理検証方法に加えて： 第１の処理ステップでは、前記プロセス毎の状態遷
移グラフの生成に際し、同じプロセス内の２つの状態が
それぞれに続く遷移系列が全く等しくなるという意味で
等価である場合は、後から生成した方の状態については
プロセスの等価停止状態として以後の状態遷移グラフの
生成とプロトコル誤りの検出を中止し、この等価停止状
態の情報を保持すること； 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、第１の処理ステップで保持された等
価停止状態の情報を利用して、元となるシステム状態を
構成するプロセスの状態の中に前記等価停止状態が含ま
れる場合は、次に生成しようとしていたシステム状態の
生成処理を中止すること；を特徴とするプロトコルの論
理検証方法である。
【００２９】第８の発明は、第１ないし第６いずれか一
つの発明のプロトコルの論理検証方法に加えて： 第１の処理ステップでは、前記プロセス毎の状態遷
移グラフの生成に際し、同じプロセス内の２つの状態が
それぞれに続く遷移系列が全く等しくなるという意味で
等価である場合は、後から生成した方の状態については
プロセスの等価停止状態として以後の状態遷移グラフの
生成とプロトコル誤りの検出を中止し、この等価停止状
態の情報を保持すること； 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、第１の処理ステップで保持された等
価停止状態の情報を利用して、元となるシステム状態か
ら次に生成するシステム状態の間のいずれかのプロセス
の状態の中に、前記等価停止状態が含まれる場合に、次
に生成しようとしていたシステム状態の生成処理を中止
すること；を特徴とするプロトコルの論理検証方法であ
る。
つの発明のプロトコルの論理検証方法に加えて： 第１の処理ステップでは、前記プロセス毎の状態遷
移グラフの生成に際し、同じプロセス内の２つの状態が
それぞれに続く遷移系列が全く等しくなるという意味で
等価である場合は、後から生成した方の状態については
プロセスの等価停止状態として以後の状態遷移グラフの
生成とプロトコル誤りの検出を中止し、この等価停止状
態の情報を保持すること； 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、第１の処理ステップで保持された等
価停止状態の情報を利用して、元となるシステム状態か
ら次に生成するシステム状態の間のいずれかのプロセス
の状態の中に、前記等価停止状態が含まれる場合に、次
に生成しようとしていたシステム状態の生成処理を中止
すること；を特徴とするプロトコルの論理検証方法であ
る。
【００３０】第９の発明は、第１ないし第８いずれか一
つの発明のプロトコルの論理検証方法に加えて： 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルが空のシステム状態から、
或る送信遷移で始まる遷移系列により到達するシステム
状態とそれに続く一連のシステム状態との検証を行った
場合に、前記送信遷移を検証終了遷移として記憶してお
き、前記チャネルが空のシステム状態から別の送信遷移
で始まる遷移系列についてシステム状態を生成する途中
で前記検証終了遷移として記憶していた送信遷移が現わ
れた場合は、同送信遷移よりも先のシステム状態の生成
処理を中止すること；を特徴とするプロトコルの論理検
証方法である。
つの発明のプロトコルの論理検証方法に加えて： 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルが空のシステム状態から、
或る送信遷移で始まる遷移系列により到達するシステム
状態とそれに続く一連のシステム状態との検証を行った
場合に、前記送信遷移を検証終了遷移として記憶してお
き、前記チャネルが空のシステム状態から別の送信遷移
で始まる遷移系列についてシステム状態を生成する途中
で前記検証終了遷移として記憶していた送信遷移が現わ
れた場合は、同送信遷移よりも先のシステム状態の生成
処理を中止すること；を特徴とするプロトコルの論理検
証方法である。
【００３１】
【作用】上述した構成において、本発明ではプロトコル
の論理検証処理を、各プロセスの動作に関連するプロト
コル誤りを検出する第１の処理ステップと、デッドロッ
クを検出する第２の処理ステップとの２段階に分割して
行う。
の論理検証処理を、各プロセスの動作に関連するプロト
コル誤りを検出する第１の処理ステップと、デッドロッ
クを検出する第２の処理ステップとの２段階に分割して
行う。
【００３２】第１の処理ステップでは、第１従来方法の
ようにプロトコル仕様から到達可能なシステム状態を生
成して列挙するのではなく、第２従来方法と同様に各プ
ロセスの実行可能な状態遷移のみからなるプロセス毎の
状態遷移グラフを生成することにより、未定義実行可能
受信遷移，オーバフローあるいは定義済み実行不能遷移
などを検出する。そのため、大規模なあるいは複雑なプ
ロトコル仕様を検証する場合でも、第１従来方法のよう
に生成したシステム状態を全て記憶する膨大なメモリは
不要であり、また、新たにシステム状態を生成する都度
そのシステム状態が既出か否かを調べるための莫大な時
間がかかる検索処理も不要である。なお、プロセス毎の
状態遷移グラフの生成処理自体は、第２従来方法に限定
されることはなく、それとは異なる処理であっても良
い。
ようにプロトコル仕様から到達可能なシステム状態を生
成して列挙するのではなく、第２従来方法と同様に各プ
ロセスの実行可能な状態遷移のみからなるプロセス毎の
状態遷移グラフを生成することにより、未定義実行可能
受信遷移，オーバフローあるいは定義済み実行不能遷移
などを検出する。そのため、大規模なあるいは複雑なプ
ロトコル仕様を検証する場合でも、第１従来方法のよう
に生成したシステム状態を全て記憶する膨大なメモリは
不要であり、また、新たにシステム状態を生成する都度
そのシステム状態が既出か否かを調べるための莫大な時
間がかかる検索処理も不要である。なお、プロセス毎の
状態遷移グラフの生成処理自体は、第２従来方法に限定
されることはなく、それとは異なる処理であっても良
い。
【００３３】第２の処理ステップでは、第２従来方法の
ように安定状態を全て生成して記憶した後に安定状態集
合の中からデッドロックを検出するのではなく、プロセ
ス毎の状態遷移グラフから到達可能なシステム状態を生
成する都度、それ以上先に遷移できないか否かを調べて
デッドロックを検出する。従って、生成したシステム状
態を全て記憶しておく必要がなく、大規模な、あるいは
複雑なプロトコル仕様を検証する場合でも、第２従来方
法のように生成した安定状態を全て記憶する膨大なメモ
リは不要である。
ように安定状態を全て生成して記憶した後に安定状態集
合の中からデッドロックを検出するのではなく、プロセ
ス毎の状態遷移グラフから到達可能なシステム状態を生
成する都度、それ以上先に遷移できないか否かを調べて
デッドロックを検出する。従って、生成したシステム状
態を全て記憶しておく必要がなく、大規模な、あるいは
複雑なプロトコル仕様を検証する場合でも、第２従来方
法のように生成した安定状態を全て記憶する膨大なメモ
リは不要である。
【００３４】本発明の第２の処理ステップでのデッドロ
ック検出は、到達可能なシステム状態を調べるという意
味では第１従来方法と類似しているが、実質は下記
（Ａ）〜（Ｃ）の点で大いに異なる。 （Ａ）第１従来方法ではプロトコル仕様から直接システ
ム状態を生成するが、本発明では第１の処理ステップで
生成された実行可能な状態遷移のみからなるプロセス毎
の状態遷移グラフを基にしてシステム状態を生成する。
そのため、システム状態の生成処理が第１従来方法に比
べてより効率的な処理を行うための種々の工夫が可能で
あるという利点がある。 （Ｂ）第１従来方法では生成したシステム状態を全てメ
モリに記憶しておく必要があるが、本発明ではシステム
状態の生成の都度それ以上先に遷移できるか否かを調べ
てデッドロックを検出するので、不要となったシステム
状態はメモリに記憶しておく必要がない。 （Ｃ）第１従来方法では新たにシステム状態を生成する
都度その新たなシステム状態が既出か否かを調べる必要
があるため、メモリに記憶されている全システム状態を
検索するが、このような検索処理は本発明は必要としな
い。
ック検出は、到達可能なシステム状態を調べるという意
味では第１従来方法と類似しているが、実質は下記
（Ａ）〜（Ｃ）の点で大いに異なる。 （Ａ）第１従来方法ではプロトコル仕様から直接システ
ム状態を生成するが、本発明では第１の処理ステップで
生成された実行可能な状態遷移のみからなるプロセス毎
の状態遷移グラフを基にしてシステム状態を生成する。
そのため、システム状態の生成処理が第１従来方法に比
べてより効率的な処理を行うための種々の工夫が可能で
あるという利点がある。 （Ｂ）第１従来方法では生成したシステム状態を全てメ
モリに記憶しておく必要があるが、本発明ではシステム
状態の生成の都度それ以上先に遷移できるか否かを調べ
てデッドロックを検出するので、不要となったシステム
状態はメモリに記憶しておく必要がない。 （Ｃ）第１従来方法では新たにシステム状態を生成する
都度その新たなシステム状態が既出か否かを調べる必要
があるため、メモリに記憶されている全システム状態を
検索するが、このような検索処理は本発明は必要としな
い。
【００３５】＜発明の工夫＞上述したプロトコルの基本
的な論理検証処理に加えて、より高速な処理を実現する
ために、次のような工夫（１）〜（８）が行われてい
る。
的な論理検証処理に加えて、より高速な処理を実現する
ために、次のような工夫（１）〜（８）が行われてい
る。
【００３６】＜工夫（１）＞或るチャネルに未受信の信
号を含むシステム状態から同信号が受信された後のシス
テム状態を生成するには、基本的には当該未受信の信号
を含むシステム状態における同信号を受信するプロセス
の状態以降の状態遷移のうちから、同信号の受信遷移を
探し、当該受信プロセスをその遷移先の状態に進めるこ
とになる。しかし、プロセス毎の状態遷移グラフの生成
処理に着目すると、各送信遷移に対してそれの信号を受
信プロセスが受信したらどの状態に遷移するかを容易に
知ることができる。そこで第２の発明では、第１の処理
ステップでプロセス毎の状態遷移グラフを生成する際
に、各送信遷移に対して受信プロセスの受信先状態を予
め計算し、遷移情報の１つとして保持しておく。これに
対応して、第２の処理ステップでチャネルに未受信の信
号を含むシステム状態から同信号を受信した後のシステ
ム状態を生成する際に、同信号を送信したプロセスの送
信遷移に対して予め判明している受信プロセスの受信先
状態を用いて、次のシステム状態を生成する。このよう
な工夫によりシステム状態の生成処理ひいてはデッドロ
ックの検出処理が簡単化して高速化する。
号を含むシステム状態から同信号が受信された後のシス
テム状態を生成するには、基本的には当該未受信の信号
を含むシステム状態における同信号を受信するプロセス
の状態以降の状態遷移のうちから、同信号の受信遷移を
探し、当該受信プロセスをその遷移先の状態に進めるこ
とになる。しかし、プロセス毎の状態遷移グラフの生成
処理に着目すると、各送信遷移に対してそれの信号を受
信プロセスが受信したらどの状態に遷移するかを容易に
知ることができる。そこで第２の発明では、第１の処理
ステップでプロセス毎の状態遷移グラフを生成する際
に、各送信遷移に対して受信プロセスの受信先状態を予
め計算し、遷移情報の１つとして保持しておく。これに
対応して、第２の処理ステップでチャネルに未受信の信
号を含むシステム状態から同信号を受信した後のシステ
ム状態を生成する際に、同信号を送信したプロセスの送
信遷移に対して予め判明している受信プロセスの受信先
状態を用いて、次のシステム状態を生成する。このよう
な工夫によりシステム状態の生成処理ひいてはデッドロ
ックの検出処理が簡単化して高速化する。
【００３７】＜工夫（２）＞或るチャネルに未受信の信
号を含むシステム状態から次のシステム状態を生成する
場合、基本的には信号を１つ受信する毎に順次システム
状態を生成することになる。しかし、デッドロック検出
の観点から見れば、複数の信号を連続して受信しても、
それらの途中にデッドロックは有り得ない。そこで第３
の発明では、複数の未受信の信号のうちで最後に送信さ
れた信号を選択し、この信号を受信した後のシステム状
態だけを生成する。つまり、連続する多数の受信遷移を
一括して全て実行してシステム状態を生成することにな
る。従って、途中のシステム状態の生成が略省できるの
で、システム状態の生成ひいてはデッドロックの検出処
理が高速化する。
号を含むシステム状態から次のシステム状態を生成する
場合、基本的には信号を１つ受信する毎に順次システム
状態を生成することになる。しかし、デッドロック検出
の観点から見れば、複数の信号を連続して受信しても、
それらの途中にデッドロックは有り得ない。そこで第３
の発明では、複数の未受信の信号のうちで最後に送信さ
れた信号を選択し、この信号を受信した後のシステム状
態だけを生成する。つまり、連続する多数の受信遷移を
一括して全て実行してシステム状態を生成することにな
る。従って、途中のシステム状態の生成が略省できるの
で、システム状態の生成ひいてはデッドロックの検出処
理が高速化する。
【００３８】＜工夫（３）＞全チャネルが空のシステム
状態から或るプロセスの送信遷移を実行して次のシステ
ム状態を生成する場合に最初の送信遷移に続いて同じプ
ロセスに１つ以上の送信遷移が連続して存在するとき
は、基本的には送信遷移を１つ実行する毎に順次システ
ム状態を生成することになる。しかし、この場合もデッ
ドロック検出の観点から見れば、連続する複数の送信遷
移を連続して実行しても、それらの途中にデッドロック
は有り得ない。そこで、第４の発明では、プロセスの状
態を、最初の送信遷移とそれに続く一連の送信遷移とを
一括して全て実行した先の状態まで進め、その場合のシ
ステム状態だけを生成し、途中のシステム状態の生成は
行わない。このような工夫により、システム状態の生成
処理ひいてはデッドロックの検出処理が高速化する。但
し、プロセスの状態遷移の途中に分岐がある場合は、そ
の分岐のある状態を遷移先とし、それ以上は進めない。
状態から或るプロセスの送信遷移を実行して次のシステ
ム状態を生成する場合に最初の送信遷移に続いて同じプ
ロセスに１つ以上の送信遷移が連続して存在するとき
は、基本的には送信遷移を１つ実行する毎に順次システ
ム状態を生成することになる。しかし、この場合もデッ
ドロック検出の観点から見れば、連続する複数の送信遷
移を連続して実行しても、それらの途中にデッドロック
は有り得ない。そこで、第４の発明では、プロセスの状
態を、最初の送信遷移とそれに続く一連の送信遷移とを
一括して全て実行した先の状態まで進め、その場合のシ
ステム状態だけを生成し、途中のシステム状態の生成は
行わない。このような工夫により、システム状態の生成
処理ひいてはデッドロックの検出処理が高速化する。但
し、プロセスの状態遷移の途中に分岐がある場合は、そ
の分岐のある状態を遷移先とし、それ以上は進めない。
【００３９】＜工夫（４）＞チャネルに未受信の信号を
含むシステム状態から次のシステム状態を生成する場合
に同信号を受信すべきプロセスが同信号を受信した状態
の先に１つ以上の送信遷移が連続して存在するときも、
基本的には受信に続く送信遷移を１つ実行する毎に順次
システム状態を生成することになる。しかし、この場合
もデッドロック検出の観点から見れば、受信に続く一連
の送信遷移を連続して実行しても、それらの途中にデッ
ドロックは有り得ない。そこで第５の発明では、プロセ
スの状態を、受信遷移とそれに続く一連の送信遷移とを
一括して全て実行した先の状態まで進め、その場合のシ
ステム状態だけを生成して、途中のシステム状態の生成
は行わない。このような工夫により、システム状態の生
成処理ひいてはデッドロックの検出処理が高速化する。
但し、プロセスの状態遷移の途中で分岐がある場合は、
その分岐のある状態を遷移先とし、それ以上進めない。
含むシステム状態から次のシステム状態を生成する場合
に同信号を受信すべきプロセスが同信号を受信した状態
の先に１つ以上の送信遷移が連続して存在するときも、
基本的には受信に続く送信遷移を１つ実行する毎に順次
システム状態を生成することになる。しかし、この場合
もデッドロック検出の観点から見れば、受信に続く一連
の送信遷移を連続して実行しても、それらの途中にデッ
ドロックは有り得ない。そこで第５の発明では、プロセ
スの状態を、受信遷移とそれに続く一連の送信遷移とを
一括して全て実行した先の状態まで進め、その場合のシ
ステム状態だけを生成して、途中のシステム状態の生成
は行わない。このような工夫により、システム状態の生
成処理ひいてはデッドロックの検出処理が高速化する。
但し、プロセスの状態遷移の途中で分岐がある場合は、
その分岐のある状態を遷移先とし、それ以上進めない。
【００４０】＜工夫（５）＞チャネルに未受信の信号を
含むシステム状態から次のシステム状態を生成する場
合、同信号の受信プロセスについてはその信号を受信し
た状態あるいはその先の送信遷移を実行した状態まで進
めるが、プロセスの個数が３つ以上有る場合も含めて受
信プロセス以外の他のプロセスについては、基本的に
は、他のプロセスの状態は元のシステム状態における状
態と同じものとして次のシステム状態を生成することに
なる。しかし、受信プロセスがその遷移先の状態に到達
するために他のプロセスが最小限必要な遷移により到達
する状態が予め判明していれば、予め判明している状態
まで他の全てのプロセスを一括して進めて次のシステム
状態を生成することができる。そこで、第６の発明で
は、第１の処理ステップでプロセス毎の状態遷移グラフ
を生成する際に、各プロセスが各状態に到達するために
他のプロセスが最小限必要な遷移により到達する状態を
「最小状態」として予め計算し、遷移情報の１つとして
保持しておく。これに対応して、第２の処理ステップで
チャネルに未受信の信号を含むシステム状態から次のシ
ステム状態を生成する際に、受信プロセス以外の他の各
プロセスについては、受信プロセスの遷移先状態に対す
る最小状態を生成元のシステム状態を構成するプロセス
の状態と比較して最小状態の方が進んでいれば、その最
小状態まで必ず進むことができるので、他のプロセスを
最小状態まで一括して進めて次のシステム状態を生成す
る。このような工夫により、システム状態の生成処理ひ
いてはデッドロックの検出処理が高速化する。
含むシステム状態から次のシステム状態を生成する場
合、同信号の受信プロセスについてはその信号を受信し
た状態あるいはその先の送信遷移を実行した状態まで進
めるが、プロセスの個数が３つ以上有る場合も含めて受
信プロセス以外の他のプロセスについては、基本的に
は、他のプロセスの状態は元のシステム状態における状
態と同じものとして次のシステム状態を生成することに
なる。しかし、受信プロセスがその遷移先の状態に到達
するために他のプロセスが最小限必要な遷移により到達
する状態が予め判明していれば、予め判明している状態
まで他の全てのプロセスを一括して進めて次のシステム
状態を生成することができる。そこで、第６の発明で
は、第１の処理ステップでプロセス毎の状態遷移グラフ
を生成する際に、各プロセスが各状態に到達するために
他のプロセスが最小限必要な遷移により到達する状態を
「最小状態」として予め計算し、遷移情報の１つとして
保持しておく。これに対応して、第２の処理ステップで
チャネルに未受信の信号を含むシステム状態から次のシ
ステム状態を生成する際に、受信プロセス以外の他の各
プロセスについては、受信プロセスの遷移先状態に対す
る最小状態を生成元のシステム状態を構成するプロセス
の状態と比較して最小状態の方が進んでいれば、その最
小状態まで必ず進むことができるので、他のプロセスを
最小状態まで一括して進めて次のシステム状態を生成す
る。このような工夫により、システム状態の生成処理ひ
いてはデッドロックの検出処理が高速化する。
【００４１】＜工夫（６），（７）＞プロセス毎の状態
遷移グラフを生成する場合、同じプロセスの２つの状態
の間でそれぞれに続く遷移系列が全く等しくなることが
有り得るが、このような同じ遷移系列の繰り返しは無駄
であり、省くことが好ましい。そこで第７及び第８の発
明では、第１の処理ステップでプロセス毎の状態遷移グ
ラフを生成する際に、同じプロセス内の２つの状態がそ
れぞれに続く遷移系列が全く等しくなるという意味で等
価である場合には、例えば後から生成した方の状態より
も以降の状態遷移グラフの生成を中止、従ってプロトコ
ル誤りの検出を中止する。また、例えば後から生成した
方の状態を等価停止状態とし、予め遷移情報の１つとし
て保持しておく。また第２の処理ステップにおけるシス
テム状態の生成において等価停止状態が現われた場合
は、その等価停止状態を含む遷移系列に対するデッドロ
ック検出処理は当該等価停止状態が等価と判定された先
の状態を含む遷移系列において処理されることから、そ
の遷移系列に対する処理は無駄であり省くことが好まし
い。そこで第７の発明では、次のシステム状態の生成に
際し、生成元のシステム状態を構成するプロセスの状態
に等価停止状態が含まれていれば、次に生成しようとし
ていたシステム状態の生成処理を中止する（工夫
（６））。一方、第８の発明では、生成元のシステム状
態だけではなく、生成元のシステム状態から次に生成し
ようとするシステム状態の間のいずれかのプロセスの状
態の中に等価停止状態が含まれる場合も、次に生成しよ
うとしていたシステム状態の生成処理を中止する（工夫
（７））。これらの工夫により、状態遷移グラフの生成
処理が高速化し、且つシステム状態の生成処理ひいては
デッドロックの検出処理が高速化する。
遷移グラフを生成する場合、同じプロセスの２つの状態
の間でそれぞれに続く遷移系列が全く等しくなることが
有り得るが、このような同じ遷移系列の繰り返しは無駄
であり、省くことが好ましい。そこで第７及び第８の発
明では、第１の処理ステップでプロセス毎の状態遷移グ
ラフを生成する際に、同じプロセス内の２つの状態がそ
れぞれに続く遷移系列が全く等しくなるという意味で等
価である場合には、例えば後から生成した方の状態より
も以降の状態遷移グラフの生成を中止、従ってプロトコ
ル誤りの検出を中止する。また、例えば後から生成した
方の状態を等価停止状態とし、予め遷移情報の１つとし
て保持しておく。また第２の処理ステップにおけるシス
テム状態の生成において等価停止状態が現われた場合
は、その等価停止状態を含む遷移系列に対するデッドロ
ック検出処理は当該等価停止状態が等価と判定された先
の状態を含む遷移系列において処理されることから、そ
の遷移系列に対する処理は無駄であり省くことが好まし
い。そこで第７の発明では、次のシステム状態の生成に
際し、生成元のシステム状態を構成するプロセスの状態
に等価停止状態が含まれていれば、次に生成しようとし
ていたシステム状態の生成処理を中止する（工夫
（６））。一方、第８の発明では、生成元のシステム状
態だけではなく、生成元のシステム状態から次に生成し
ようとするシステム状態の間のいずれかのプロセスの状
態の中に等価停止状態が含まれる場合も、次に生成しよ
うとしていたシステム状態の生成処理を中止する（工夫
（７））。これらの工夫により、状態遷移グラフの生成
処理が高速化し、且つシステム状態の生成処理ひいては
デッドロックの検出処理が高速化する。
【００４２】＜工夫（８）＞全てのチャネルが空のシス
テム状態において任意の順序で実行可能な複数の送信遷
移が存在する場合、それらの送信遷移の順序を入れ替え
た遷移系列を全て調べるのは、同じデッドロックの状態
へ至る途中の遷移の順序だけが異なる複数の系列を調べ
ることになり、無駄であり省くことが好ましい。そこで
第９の発明では、第２の処理ステップでシステム状態を
生成する際に、チャネルが空のシステム状態から或る送
信遷移で始まる遷移系列により到達するシステム状態と
それに続く一連のシステム状態との検証を行った場合
は、その遷移系列の始まりの送信遷移を「検証終了遷
移」として記憶しておく。そして、全てのチャネルが空
の前記システム状態から別の送信遷移で始まる遷移系列
についてシステム状態を順次生成する途中に記憶済みの
「検証終了遷移」と同じ送信遷移が現われた場合は、こ
の送信遷移よりも先のシステム状態の生成処理を中止す
る。この工夫により、システム状態の生成処理ひいては
デッドロックの検出処理が高速化する。
テム状態において任意の順序で実行可能な複数の送信遷
移が存在する場合、それらの送信遷移の順序を入れ替え
た遷移系列を全て調べるのは、同じデッドロックの状態
へ至る途中の遷移の順序だけが異なる複数の系列を調べ
ることになり、無駄であり省くことが好ましい。そこで
第９の発明では、第２の処理ステップでシステム状態を
生成する際に、チャネルが空のシステム状態から或る送
信遷移で始まる遷移系列により到達するシステム状態と
それに続く一連のシステム状態との検証を行った場合
は、その遷移系列の始まりの送信遷移を「検証終了遷
移」として記憶しておく。そして、全てのチャネルが空
の前記システム状態から別の送信遷移で始まる遷移系列
についてシステム状態を順次生成する途中に記憶済みの
「検証終了遷移」と同じ送信遷移が現われた場合は、こ
の送信遷移よりも先のシステム状態の生成処理を中止す
る。この工夫により、システム状態の生成処理ひいては
デッドロックの検出処理が高速化する。
【００４３】
【実施例】以下、図面を参照して本発明を実施例ととも
に説明する。図面中、図１に本発明のプロトコルの論理
検証方法の基本的実施例に係る処理フローが示され、図
２には検証対象例のプロトコル仕様が示され、図３には
同プロトコル仕様のメモリへの記憶形式例が示されてい
る。また、図４には本発明のプロトコルの論理検証方法
の具体的実施例に係る第２の処理ステップのフローが示
され、図５には同処理フローの送信遷移先探索に関する
部分の詳細が示され、図６には同処理フローの受信遷移
先探索に関する部分の詳細が示され、図７には図２のプ
ロトコル仕様から生成したプロセス毎の状態遷移グラフ
が示され、図８には同プロセス毎の状態遷移グラフから
生成したシステム状態の遷移グラフが示されている。
に説明する。図面中、図１に本発明のプロトコルの論理
検証方法の基本的実施例に係る処理フローが示され、図
２には検証対象例のプロトコル仕様が示され、図３には
同プロトコル仕様のメモリへの記憶形式例が示されてい
る。また、図４には本発明のプロトコルの論理検証方法
の具体的実施例に係る第２の処理ステップのフローが示
され、図５には同処理フローの送信遷移先探索に関する
部分の詳細が示され、図６には同処理フローの受信遷移
先探索に関する部分の詳細が示され、図７には図２のプ
ロトコル仕様から生成したプロセス毎の状態遷移グラフ
が示され、図８には同プロセス毎の状態遷移グラフから
生成したシステム状態の遷移グラフが示されている。
【００４４】＜基本的実施例＞まず、図１〜図３を参照
して本発明の基本的な実施例を説明する。但し、検証対
象のプロトコル仕様は図２に示したプロセスの個数がプ
ロセス１とプロセス２との計２つの場合のプロトコル仕
様とし、図３に示したような形式で電気信号により表現
されているものとして説明する。なお、図１では長方形
は個々の処理を示し、楕円は各処理の入出力を示し、矢
印はデータの流れを示す。
して本発明の基本的な実施例を説明する。但し、検証対
象のプロトコル仕様は図２に示したプロセスの個数がプ
ロセス１とプロセス２との計２つの場合のプロトコル仕
様とし、図３に示したような形式で電気信号により表現
されているものとして説明する。なお、図１では長方形
は個々の処理を示し、楕円は各処理の入出力を示し、矢
印はデータの流れを示す。
【００４５】図１に示されるように、基本的に本発明の
プロトコルの論理検証方法は第１の処理ステップＳ１
と、第２の処理ステップＳ２との２段階でプロトコル誤
りを検出する方法である。第１の処理ステップを以下の
説明ではプロセス検証と呼ぶこととし、この例のプロセ
ス検証Ｓ１では、図３に示したプロトコル仕様が入力さ
れると、そのプロトコル仕様が有する遷移情報に従っ
て、各プロセスの実行可能な状態遷移のみからなるプロ
セス毎の状態遷移グラフを生成し、同時に、各プロセス
の動作に関連するプロトコル誤りとして、デッドロック
以外のプロトコル誤りを検出するものとしている。ま
た、以下の説明では第２の処理ステップＳ２をグローバ
ル検証と呼ぶこととし、このグローバル検証Ｓ２では、
プロセス毎の状態遷移グラフが有する遷移情報に従っ
て、到達可能なシステム状態を順次生成し、それ以上先
へ遷移できないシステム状態をデッドロックとして検出
する。
プロトコルの論理検証方法は第１の処理ステップＳ１
と、第２の処理ステップＳ２との２段階でプロトコル誤
りを検出する方法である。第１の処理ステップを以下の
説明ではプロセス検証と呼ぶこととし、この例のプロセ
ス検証Ｓ１では、図３に示したプロトコル仕様が入力さ
れると、そのプロトコル仕様が有する遷移情報に従っ
て、各プロセスの実行可能な状態遷移のみからなるプロ
セス毎の状態遷移グラフを生成し、同時に、各プロセス
の動作に関連するプロトコル誤りとして、デッドロック
以外のプロトコル誤りを検出するものとしている。ま
た、以下の説明では第２の処理ステップＳ２をグローバ
ル検証と呼ぶこととし、このグローバル検証Ｓ２では、
プロセス毎の状態遷移グラフが有する遷移情報に従っ
て、到達可能なシステム状態を順次生成し、それ以上先
へ遷移できないシステム状態をデッドロックとして検出
する。
【００４６】次に、図２に示したプロトコル仕様から、
各プロセスの実行可能な状態遷移のみからなるプロセス
毎の状態遷移グラフを生成する手順の基本的な一例を説
明する。なお、先に第２従来方法について行った説明と
一部重複するが、図２に示されたプロトコル仕様例にお
いて、長円は各プロセス１，２の各状態を表わし、長円
内に状態名（ＲＥＡＤＹ，ＷＡＩＴ，ＲＥＧＩＳＴＥ
Ｒ，ＩＤＬＥ，ＳＥＲＶＩＣＥ，ＦＡＵＬＴ）が示され
ている。状態名に下線が付いた状態（ＲＥＡＤＹ，ＩＤ
ＬＥ）は初期状態を表わす。長円を結ぶ矢印は状態遷移
を表わし、矢印上には状態遷移時に送信あるいは受信さ
れる信号名（ＲＥＱ，ＡＣＫ，ＤＯＮＥ，ＡＬＡＲＭ）
が、送信の場合は「−」記号とともに、受信の場合は
「＋」記号とともに付与されている。従って図２のプロ
トコル仕様では、例えば、プロセス１は初期状態ＲＥＡ
ＤＹからプロセス２に対して信号ＲＥＱを送信すること
により状態ＷＡＩＴに遷移すること、またプロセス１は
信号ＲＥＱの送信前にプロセス２からの信号ＡＬＡＲＭ
を受信した際には状態ＲＥＧＩＳＴＥＲに遷移するこ
と、等の通信規約が規定されている。なお、信号名のう
ち、例えばＲＥＱは送信要求信号、ＡＣＫは肯定受信応
答信号、ＤＯＮＥは作業終了通知信号、ＡＬＡＲＭは異
常警報信号を表わしている。図３に示されたプロトコル
仕様の記憶形式例においては、プロセス名（１と２）
と、プロセスの状態名と、その状態からの各状態遷移と
を組にして、全ての組が列挙されている。各状態遷移は
括弧（）内に送信と受信の識別記号付きの信号名を入
れ、その次に遷移先の状態名を続けることにより、表わ
されている。 プロセス毎の状態遷移グラフの生成として、まず、
初期状態を表わす初期ノードを各プロセスに対して生成
する。 次に、実行可能な送信遷移の付加と、実行可能な受
信遷移の付加を繰り返してプロセス毎の状態遷移グラフ
を生成する。 以上のようなプロセス毎の状態遷移グラフを生成す
ることにより、各プロセスの動作に関連するプロトコル
誤りを検出する。即ち、或るプロセスの状態遷移グラフ
を生成する場合、実行可能な状態遷移のうち受信遷移を
付加する際に、その受信遷移がプロトコル仕様に定義さ
れているか否かを調べ、定義されていなければ未定義実
行可能受信遷移と判定する。また、実行可能な状態遷移
のうち送信遷移を付加する際に、チャネル内の信号数を
調べ、所定のチャネル容量を越えているならばオーバフ
ローと判定する。更に、全ての状態遷移グラフの生成終
了後に、プロトコル仕様に定義されてはいるが一度も状
態遷移グラフに付加されなかった状態遷移があるか否か
を調べ、付加されなかったものを定義済み実行不能遷移
と判定する。例えば、図２のプロトコル仕様におけるプ
ロセス２の状態ＳＥＲＶＩＣＥから、信号ＡＣＫの受信
により同状態ＳＥＲＶＩＣＥに戻る受信遷移は、プロセ
ス２の状態遷移グラフに何も付加されないので、定義済
み実行不能遷移として検出される。
各プロセスの実行可能な状態遷移のみからなるプロセス
毎の状態遷移グラフを生成する手順の基本的な一例を説
明する。なお、先に第２従来方法について行った説明と
一部重複するが、図２に示されたプロトコル仕様例にお
いて、長円は各プロセス１，２の各状態を表わし、長円
内に状態名（ＲＥＡＤＹ，ＷＡＩＴ，ＲＥＧＩＳＴＥ
Ｒ，ＩＤＬＥ，ＳＥＲＶＩＣＥ，ＦＡＵＬＴ）が示され
ている。状態名に下線が付いた状態（ＲＥＡＤＹ，ＩＤ
ＬＥ）は初期状態を表わす。長円を結ぶ矢印は状態遷移
を表わし、矢印上には状態遷移時に送信あるいは受信さ
れる信号名（ＲＥＱ，ＡＣＫ，ＤＯＮＥ，ＡＬＡＲＭ）
が、送信の場合は「−」記号とともに、受信の場合は
「＋」記号とともに付与されている。従って図２のプロ
トコル仕様では、例えば、プロセス１は初期状態ＲＥＡ
ＤＹからプロセス２に対して信号ＲＥＱを送信すること
により状態ＷＡＩＴに遷移すること、またプロセス１は
信号ＲＥＱの送信前にプロセス２からの信号ＡＬＡＲＭ
を受信した際には状態ＲＥＧＩＳＴＥＲに遷移するこ
と、等の通信規約が規定されている。なお、信号名のう
ち、例えばＲＥＱは送信要求信号、ＡＣＫは肯定受信応
答信号、ＤＯＮＥは作業終了通知信号、ＡＬＡＲＭは異
常警報信号を表わしている。図３に示されたプロトコル
仕様の記憶形式例においては、プロセス名（１と２）
と、プロセスの状態名と、その状態からの各状態遷移と
を組にして、全ての組が列挙されている。各状態遷移は
括弧（）内に送信と受信の識別記号付きの信号名を入
れ、その次に遷移先の状態名を続けることにより、表わ
されている。 プロセス毎の状態遷移グラフの生成として、まず、
初期状態を表わす初期ノードを各プロセスに対して生成
する。 次に、実行可能な送信遷移の付加と、実行可能な受
信遷移の付加を繰り返してプロセス毎の状態遷移グラフ
を生成する。 以上のようなプロセス毎の状態遷移グラフを生成す
ることにより、各プロセスの動作に関連するプロトコル
誤りを検出する。即ち、或るプロセスの状態遷移グラフ
を生成する場合、実行可能な状態遷移のうち受信遷移を
付加する際に、その受信遷移がプロトコル仕様に定義さ
れているか否かを調べ、定義されていなければ未定義実
行可能受信遷移と判定する。また、実行可能な状態遷移
のうち送信遷移を付加する際に、チャネル内の信号数を
調べ、所定のチャネル容量を越えているならばオーバフ
ローと判定する。更に、全ての状態遷移グラフの生成終
了後に、プロトコル仕様に定義されてはいるが一度も状
態遷移グラフに付加されなかった状態遷移があるか否か
を調べ、付加されなかったものを定義済み実行不能遷移
と判定する。例えば、図２のプロトコル仕様におけるプ
ロセス２の状態ＳＥＲＶＩＣＥから、信号ＡＣＫの受信
により同状態ＳＥＲＶＩＣＥに戻る受信遷移は、プロセ
ス２の状態遷移グラフに何も付加されないので、定義済
み実行不能遷移として検出される。
【００４７】＜具体的実施例＞次に、図２〜図８を参照
して本発明のより具体的な実施例を説明する。本実施例
の場合も、図２に示されたプロセス個数が２のプロトコ
ル仕様を検証対象として説明する。
して本発明のより具体的な実施例を説明する。本実施例
の場合も、図２に示されたプロセス個数が２のプロトコ
ル仕様を検証対象として説明する。
【００４８】＜第１の処理ステップ：プロセス検証の具
体例＞第１の処理ステップ即ちプロセス検証では、前述
した基本的なプロセス毎の状態遷移グラフの生成処理と
デッドロック以外のプロトコル誤りの検出処理とに加え
て、処理の高速化のために下記（Ａ）〜（Ｃ）の処理を
行う。 （Ａ）プロセス毎の状態遷移グラフを生成する際に、各
送信遷移に対してその送信信号の受信により受信プロセ
スが遷移する受信先状態を計算し、遷移情報の１つとし
て保持しておく。 （Ｂ）プロセス毎の状態遷移グラフを生成する際に、各
プロセスが各状態に到達するために他のプロセスが最小
限必要な遷移により到達すべき状態を最小状態として計
算し、これも遷移情報の１つとして保持しておく。 （Ｃ）プロセス毎の状態遷移グラフを生成する際に、同
じプロセス内の２つの状態がそれぞれに続く遷移系列が
全く等しくなるという意味で等価である場合は、後から
生成した方の状態についてはプロセスの等価停止状態と
して以降の状態遷移グラフの生成とプロトコル誤りの検
出とを中止し、この等価停止状態も遷移情報の１つとし
て保持しておく。
体例＞第１の処理ステップ即ちプロセス検証では、前述
した基本的なプロセス毎の状態遷移グラフの生成処理と
デッドロック以外のプロトコル誤りの検出処理とに加え
て、処理の高速化のために下記（Ａ）〜（Ｃ）の処理を
行う。 （Ａ）プロセス毎の状態遷移グラフを生成する際に、各
送信遷移に対してその送信信号の受信により受信プロセ
スが遷移する受信先状態を計算し、遷移情報の１つとし
て保持しておく。 （Ｂ）プロセス毎の状態遷移グラフを生成する際に、各
プロセスが各状態に到達するために他のプロセスが最小
限必要な遷移により到達すべき状態を最小状態として計
算し、これも遷移情報の１つとして保持しておく。 （Ｃ）プロセス毎の状態遷移グラフを生成する際に、同
じプロセス内の２つの状態がそれぞれに続く遷移系列が
全く等しくなるという意味で等価である場合は、後から
生成した方の状態についてはプロセスの等価停止状態と
して以降の状態遷移グラフの生成とプロトコル誤りの検
出とを中止し、この等価停止状態も遷移情報の１つとし
て保持しておく。
【００４９】＜プロセス毎の状態遷移グラフの生成＞次
に、図３のような電気信号で表わされる図２に示したプ
ロトコル仕様から、前記（Ａ）〜（Ｃ）の各処理を含む
プロセス検証処理により図７に示すようなプロセス毎の
状態遷移グラフを生成する例を説明する。なお、図７に
示されたプロセス１，２毎の状態遷移グラフはノードと
矢印からなり、長円形のノードはプロセスの状態を表わ
し、ノードを結ぶ矢印は実行可能な状態遷移を表わして
いる。ノードの状態名にはピリオド「．」と数字が付与
されており、この数字は、異なる遷移系列により到達し
た同じ名の状態を区別するための識別子である。矢印上
には、図２のプロトコル仕様と同様に、状態遷移に伴い
実行される送信あるいは受信の信号名が付与されてい
る。また各ノードのうち送信遷移後のノードの右下に
は、その送信遷移に対する受信プロセスの受信先状態名
と識別子が括弧〔〕付きで示されている。例えば、プロ
セス１の状態ＲＥＡＤＹ．０から状態ＷＡＩＴ．０へ送
信遷移した時は、その送信信号ＲＥＱを受信するプロセ
ス２の受信先状態はＳＥＲＶＩＣＥ．０またはＦＡＵＬ
Ｔ．２であるから、状態ＷＡＩＴ．０を表わすノードの
右下に〔ＳＥＲＶＩＣＥ．０，ＦＡＵＬＴ．２〕と示さ
れている。更に、各ノードの右上には当該ノードが表わ
すプロセスの状態に対する他の各プロセスの最小状態名
が識別子付きで括弧（）内に示されている。例えば図７
には、プロセス１の状態ＷＡＩＴ．２に対するプロセス
２の最小状態として、ＦＡＵＬＴ．０が記されている。
これは、プロセス１が状態ＷＡＩＴ．２に到達するため
には、プロセス２は、最小でも信号ＡＬＡＲＭを送信し
て、ＦＡＵＬＴ．０に到達していることが必要であるこ
とを意味している。なお、図７の例ではシステムのプロ
セス個数が２つなので、最小状態は相手のプロセスの状
態のみである。
に、図３のような電気信号で表わされる図２に示したプ
ロトコル仕様から、前記（Ａ）〜（Ｃ）の各処理を含む
プロセス検証処理により図７に示すようなプロセス毎の
状態遷移グラフを生成する例を説明する。なお、図７に
示されたプロセス１，２毎の状態遷移グラフはノードと
矢印からなり、長円形のノードはプロセスの状態を表わ
し、ノードを結ぶ矢印は実行可能な状態遷移を表わして
いる。ノードの状態名にはピリオド「．」と数字が付与
されており、この数字は、異なる遷移系列により到達し
た同じ名の状態を区別するための識別子である。矢印上
には、図２のプロトコル仕様と同様に、状態遷移に伴い
実行される送信あるいは受信の信号名が付与されてい
る。また各ノードのうち送信遷移後のノードの右下に
は、その送信遷移に対する受信プロセスの受信先状態名
と識別子が括弧〔〕付きで示されている。例えば、プロ
セス１の状態ＲＥＡＤＹ．０から状態ＷＡＩＴ．０へ送
信遷移した時は、その送信信号ＲＥＱを受信するプロセ
ス２の受信先状態はＳＥＲＶＩＣＥ．０またはＦＡＵＬ
Ｔ．２であるから、状態ＷＡＩＴ．０を表わすノードの
右下に〔ＳＥＲＶＩＣＥ．０，ＦＡＵＬＴ．２〕と示さ
れている。更に、各ノードの右上には当該ノードが表わ
すプロセスの状態に対する他の各プロセスの最小状態名
が識別子付きで括弧（）内に示されている。例えば図７
には、プロセス１の状態ＷＡＩＴ．２に対するプロセス
２の最小状態として、ＦＡＵＬＴ．０が記されている。
これは、プロセス１が状態ＷＡＩＴ．２に到達するため
には、プロセス２は、最小でも信号ＡＬＡＲＭを送信し
て、ＦＡＵＬＴ．０に到達していることが必要であるこ
とを意味している。なお、図７の例ではシステムのプロ
セス個数が２つなので、最小状態は相手のプロセスの状
態のみである。
【００５０】 まず、初期状態を表わす初期ノードを
各プロセスに対して生成し、各プロセスの初期ノードに
それぞれの初期状態に対する他の各プロセスの最小状態
として、他の各プロセスの初期状態を設定する。例えば
プロセス２について言えば、図７で初期状態ＩＤＬＥ．
０を表わす初期ノードを生成した時に、他のプロセス１
の初期状態ＲＥＡＤＹ．０を、プロセス２の初期状態Ｉ
ＤＬＥ．０に対するプロセス１の最小状態として、プロ
セス２の初期ノードに設定する。
各プロセスに対して生成し、各プロセスの初期ノードに
それぞれの初期状態に対する他の各プロセスの最小状態
として、他の各プロセスの初期状態を設定する。例えば
プロセス２について言えば、図７で初期状態ＩＤＬＥ．
０を表わす初期ノードを生成した時に、他のプロセス１
の初期状態ＲＥＡＤＹ．０を、プロセス２の初期状態Ｉ
ＤＬＥ．０に対するプロセス１の最小状態として、プロ
セス２の初期ノードに設定する。
【００５１】 次に、実行可能な送信遷移の付加と、
実行可能な受信遷移の付加を繰り返してプロセス毎の状
態遷移グラフを生成する。
実行可能な受信遷移の付加を繰り返してプロセス毎の状
態遷移グラフを生成する。
【００５２】 プロセス毎の状態遷移グラフの生成
中、実行可能な受信遷移により新たなノードを生成する
都度、その受信信号を送信した状態を表わすノードに、
当該新たなノードを受信先状態として設定する。例えば
図７のプロセス２において状態ＩＤＬＥ．０から信号Ａ
ＬＡＲＭを送信した状態ＦＡＵＬＴ．０を表わすノード
には、その信号を受信した状態ＲＥＧＩＳＴＥＲ．０及
びＷＡＩＴ．０を表わすノードを順次付加する度に受信
先状態を追加設定し、最終的な受信先状態は〔ＲＥＧＩ
ＳＴＥＲ．０，ＷＡＩＴ．２〕となる。
中、実行可能な受信遷移により新たなノードを生成する
都度、その受信信号を送信した状態を表わすノードに、
当該新たなノードを受信先状態として設定する。例えば
図７のプロセス２において状態ＩＤＬＥ．０から信号Ａ
ＬＡＲＭを送信した状態ＦＡＵＬＴ．０を表わすノード
には、その信号を受信した状態ＲＥＧＩＳＴＥＲ．０及
びＷＡＩＴ．０を表わすノードを順次付加する度に受信
先状態を追加設定し、最終的な受信先状態は〔ＲＥＧＩ
ＳＴＥＲ．０，ＷＡＩＴ．２〕となる。
【００５３】 一方、プロセス毎の状態遷移グラフの
生成においては、新たな実行可能な状態遷移の付加によ
り新たなノードを生成する度に、そのノードでの状態に
対する他の各プロセスの最小状態をノードに設定する。
例えばプロセス２について言えば、図７で初期ノードに
信号ＲＥＱの受信遷移を付加して状態ＳＥＲＶＩＣＥ．
０を表わすノードを生成したときは、同状態ＳＥＲＶＩ
ＣＥ．０に対するプロセス１の最小状態ＷＡＩＴ．０を
設定する。
生成においては、新たな実行可能な状態遷移の付加によ
り新たなノードを生成する度に、そのノードでの状態に
対する他の各プロセスの最小状態をノードに設定する。
例えばプロセス２について言えば、図７で初期ノードに
信号ＲＥＱの受信遷移を付加して状態ＳＥＲＶＩＣＥ．
０を表わすノードを生成したときは、同状態ＳＥＲＶＩ
ＣＥ．０に対するプロセス１の最小状態ＷＡＩＴ．０を
設定する。
【００５４】 また、プロセス毎の状態遷移グラフの
生成中、或るプロセス内の２つのノードが、下記Ａ，
Ｂ，Ｃ全ての条件に該当する場合は、これら２つのノー
ドから起こり得る状態遷移は等しくなるので、即ちこれ
ら２つのノードが表わす状態はそれぞれに続く遷移系列
が全く等しくなるという意味で等価であるので、例えば
後から生成した方の状態を等価停止状態として記憶し、
その状態以降の送信遷移の付加を停止して以降の状態遷
移グラフの生成と、プロセスの動作に関連するプロトコ
ル誤りの検出を中止する。 条件Ａ：識別子を除いてノードが表わす状態名が等し
い。 条件Ｂ：識別子を除いてノードに設定されている最小状
態が等しい。 条件Ｃ：ノードが表わす状態と同ノードに設定されてい
る最小状態とからなるシステム状態におけるチャネルの
状態が等しい。
生成中、或るプロセス内の２つのノードが、下記Ａ，
Ｂ，Ｃ全ての条件に該当する場合は、これら２つのノー
ドから起こり得る状態遷移は等しくなるので、即ちこれ
ら２つのノードが表わす状態はそれぞれに続く遷移系列
が全く等しくなるという意味で等価であるので、例えば
後から生成した方の状態を等価停止状態として記憶し、
その状態以降の送信遷移の付加を停止して以降の状態遷
移グラフの生成と、プロセスの動作に関連するプロトコ
ル誤りの検出を中止する。 条件Ａ：識別子を除いてノードが表わす状態名が等し
い。 条件Ｂ：識別子を除いてノードに設定されている最小状
態が等しい。 条件Ｃ：ノードが表わす状態と同ノードに設定されてい
る最小状態とからなるシステム状態におけるチャネルの
状態が等しい。
【００５５】前述の如く、等価性を理由に以降の送信遷
移の付加を停止した状態が「等価停止状態」であり、例
えば図７のプロセス１において、状態ＲＥＡＤＹ．２は
ＲＥＡＤＹ．０と等価であるため、等価停止状態となっ
ている。しかし、状態ＷＡＩＴ．１とＷＡＩＴ．２はチ
ャネルの状態が異なっているので、等価ではない。一
方、プロセス２では、状態ＩＤＬＥ．２はＩＤＬＥ．０
と等価であるため、等価停止状態となっている。
移の付加を停止した状態が「等価停止状態」であり、例
えば図７のプロセス１において、状態ＲＥＡＤＹ．２は
ＲＥＡＤＹ．０と等価であるため、等価停止状態となっ
ている。しかし、状態ＷＡＩＴ．１とＷＡＩＴ．２はチ
ャネルの状態が異なっているので、等価ではない。一
方、プロセス２では、状態ＩＤＬＥ．２はＩＤＬＥ．０
と等価であるため、等価停止状態となっている。
【００５６】 以上のようなプロセス毎の状態遷移グ
ラフを生成することにより、各プロセスの動作に関連す
るプロトコル誤りを検出する。即ち、或るプロセスの状
態遷移グラフを生成する場合、実行可能な状態遷移のう
ち受信遷移を付加する際に、その受信遷移がプロトコル
仕様に定義されているか否かを調べ、定義されていなけ
れば未定義実行可能受信遷移と判定する。また、実行可
能な状態遷移のうち送信遷移を付加する際に、その遷移
先のノードに対する他のプロセスの最小状態に当該他の
プロセスが到達した場合の、チャネル内の信号数を調
べ、所定のチャネル容量を越えているならばオーバフロ
ーと判定する。更に、全ての状態遷移グラフの生成終了
後に、プロトコル仕様に定義されてはいるが一度も状態
遷移グラフに付加されなかった状態遷移があるか否かを
調べ、付加されなかったものを定義済み実行不能遷移と
判定する。例えば、図２のプロトコル仕様におけるプロ
セス２の状態ＳＥＲＶＩＣＥから、信号ＡＣＫの受信に
より同状態ＳＥＲＶＩＣＥに戻る受信遷移は、図７のプ
ロセス２の状態遷移グラフに何も付加されていないの
で、定義済み実行不能遷移として検出される。
ラフを生成することにより、各プロセスの動作に関連す
るプロトコル誤りを検出する。即ち、或るプロセスの状
態遷移グラフを生成する場合、実行可能な状態遷移のう
ち受信遷移を付加する際に、その受信遷移がプロトコル
仕様に定義されているか否かを調べ、定義されていなけ
れば未定義実行可能受信遷移と判定する。また、実行可
能な状態遷移のうち送信遷移を付加する際に、その遷移
先のノードに対する他のプロセスの最小状態に当該他の
プロセスが到達した場合の、チャネル内の信号数を調
べ、所定のチャネル容量を越えているならばオーバフロ
ーと判定する。更に、全ての状態遷移グラフの生成終了
後に、プロトコル仕様に定義されてはいるが一度も状態
遷移グラフに付加されなかった状態遷移があるか否かを
調べ、付加されなかったものを定義済み実行不能遷移と
判定する。例えば、図２のプロトコル仕様におけるプロ
セス２の状態ＳＥＲＶＩＣＥから、信号ＡＣＫの受信に
より同状態ＳＥＲＶＩＣＥに戻る受信遷移は、図７のプ
ロセス２の状態遷移グラフに何も付加されていないの
で、定義済み実行不能遷移として検出される。
【００５７】＜第２の処理ステップ：グローバル検証の
具体例＞第２の処理ステップ即ちグローバル検証では、
前述した基本的なシステム状態の生成によるデッドロッ
クの検出処理を高速化するために、図４〜図６に示す手
順によりシステム状態を順次説明する。但し、図４〜図
６において、長方形は処理のステップを表わし、矢印は
処理の流れを表わす。以下の説明において現われる「カ
レント状態」、「未処理遷移」、「未処理遷移スタッ
ク」の各意味は次の通りである。 （Ａ）カレント状態：グローバル検証では、或る一つの
システム状態から到達可能なシステム状態を生成し、更
にそのシステム状態から次の到達可能なシステム状態を
生成するという如く、順次到達可能なシステム状態を生
成してゆく。そこで、次の到達可能なシステム状態を生
成するために、現在、或るシステム状態とそれに続く遷
移を調べているものとすると、この生成元となる現在の
システム状態を「カレント状態」と呼ぶ。 （Ｂ）未処理遷移：一つのシステム状態においてこれに
続く調べるべき遷移が複数存在する場合に、未だ調べて
いない遷移を「未処理遷移」と呼ぶ。未処理遷移には、
信号の送信により遷移する「未処理送信遷移」と、信号
の受信により遷移する「未処理受信先状態」とがある。 （Ｃ）未処理遷移スタック：各未処理遷移を後で処理す
るための一手法として、未処理遷移をカレント状態と合
わせてそれぞれ全てスタックに蓄積しておく方法があ
る。そこで、このような方法に用いるスタックを「未処
理遷移スタック」と呼ぶ。
具体例＞第２の処理ステップ即ちグローバル検証では、
前述した基本的なシステム状態の生成によるデッドロッ
クの検出処理を高速化するために、図４〜図６に示す手
順によりシステム状態を順次説明する。但し、図４〜図
６において、長方形は処理のステップを表わし、矢印は
処理の流れを表わす。以下の説明において現われる「カ
レント状態」、「未処理遷移」、「未処理遷移スタッ
ク」の各意味は次の通りである。 （Ａ）カレント状態：グローバル検証では、或る一つの
システム状態から到達可能なシステム状態を生成し、更
にそのシステム状態から次の到達可能なシステム状態を
生成するという如く、順次到達可能なシステム状態を生
成してゆく。そこで、次の到達可能なシステム状態を生
成するために、現在、或るシステム状態とそれに続く遷
移を調べているものとすると、この生成元となる現在の
システム状態を「カレント状態」と呼ぶ。 （Ｂ）未処理遷移：一つのシステム状態においてこれに
続く調べるべき遷移が複数存在する場合に、未だ調べて
いない遷移を「未処理遷移」と呼ぶ。未処理遷移には、
信号の送信により遷移する「未処理送信遷移」と、信号
の受信により遷移する「未処理受信先状態」とがある。 （Ｃ）未処理遷移スタック：各未処理遷移を後で処理す
るための一手法として、未処理遷移をカレント状態と合
わせてそれぞれ全てスタックに蓄積しておく方法があ
る。そこで、このような方法に用いるスタックを「未処
理遷移スタック」と呼ぶ。
【００５８】（１）図４において、まずステップＳ１０
では、プロセス毎の状態遷移グラフが持つ遷移情報か
ら、各プロセスの初期状態を全て組み合せた初期システ
ム状態を生成し、これをカレント状態としてメモリに記
憶する。
では、プロセス毎の状態遷移グラフが持つ遷移情報か
ら、各プロセスの初期状態を全て組み合せた初期システ
ム状態を生成し、これをカレント状態としてメモリに記
憶する。
【００５９】（２）次のステップＳ２０では、カレント
状態が持つチャネルの状態を調べ、その結果、チャネル
内に送信済みで未受信の信号が無い場合にはステップＳ
３０（送信遷移先探索）に処理を進め、チャネル内に送
信済みで未受信の信号が有る場合にはステップＳ５０
（受信遷移先探索）に処理を進める。
状態が持つチャネルの状態を調べ、その結果、チャネル
内に送信済みで未受信の信号が無い場合にはステップＳ
３０（送信遷移先探索）に処理を進め、チャネル内に送
信済みで未受信の信号が有る場合にはステップＳ５０
（受信遷移先探索）に処理を進める。
【００６０】（３）ステップＳ３０では、図５に詳細を
示す手順（ステップＳ３１〜Ｓ３６）により、各プロセ
ス毎の状態遷移グラフが持つ遷移情報から送信遷移先を
探索して、図４の各ステップＳ４０（次のシステム状態
の生成）、ステップＳ７０（デッドロック検出）及びス
テップＳ８０（未処理遷移を有するシステム状態への復
帰）のうちのいずれに処理を進めるべきかを判定する。
これらＳ４０，Ｓ７０及びＳ８０の各ステップの説明は
後で行う。
示す手順（ステップＳ３１〜Ｓ３６）により、各プロセ
ス毎の状態遷移グラフが持つ遷移情報から送信遷移先を
探索して、図４の各ステップＳ４０（次のシステム状態
の生成）、ステップＳ７０（デッドロック検出）及びス
テップＳ８０（未処理遷移を有するシステム状態への復
帰）のうちのいずれに処理を進めるべきかを判定する。
これらＳ４０，Ｓ７０及びＳ８０の各ステップの説明は
後で行う。
【００６１】（３−１）図５のステップＳ３１では、カ
レント状態中に等価停止状態が含まれているか否かを調
べ、含まれていればカレント状態以降の遷移系列は等価
停止状態が等価と判定した別の状態を含む遷移系列にお
いて調べられるので、カレント状態以降のシステム状態
の生成を中止して他の遷移系列を調べるために図４のス
テップＳ７０を経てステップＳ８０へ処理を進める。カ
レント状態中に等価停止状態が含まれていなければ、図
５の次のステップＳ３２へ処理を進める。
レント状態中に等価停止状態が含まれているか否かを調
べ、含まれていればカレント状態以降の遷移系列は等価
停止状態が等価と判定した別の状態を含む遷移系列にお
いて調べられるので、カレント状態以降のシステム状態
の生成を中止して他の遷移系列を調べるために図４のス
テップＳ７０を経てステップＳ８０へ処理を進める。カ
レント状態中に等価停止状態が含まれていなければ、図
５の次のステップＳ３２へ処理を進める。
【００６２】（３−２）ステップＳ３２では、図４のス
テップＳ８０を経てステップＳ２０及びＳ３０に処理が
進んで来たか否かを調べ、ステップＳ８０を経ていれ
ば、後述する如く同ステップＳ８０で未処理遷移スタッ
クから取り出した１つの未処理送信遷移の遷移先を探す
ことになるので、図５のステップＳ３５（送信遷移が複
数連続する場合の一括実行）へ処理を進める。ステップ
Ｓ８０を経ていなければ、カレント状態が持つ送信遷移
の遷移先を探すために、次のステップＳ３３（送信遷移
数のチェック）へ処理を進める。
テップＳ８０を経てステップＳ２０及びＳ３０に処理が
進んで来たか否かを調べ、ステップＳ８０を経ていれ
ば、後述する如く同ステップＳ８０で未処理遷移スタッ
クから取り出した１つの未処理送信遷移の遷移先を探す
ことになるので、図５のステップＳ３５（送信遷移が複
数連続する場合の一括実行）へ処理を進める。ステップ
Ｓ８０を経ていなければ、カレント状態が持つ送信遷移
の遷移先を探すために、次のステップＳ３３（送信遷移
数のチェック）へ処理を進める。
【００６３】（３−３）ステップＳ３３では、カレント
状態が持つ送信遷移数を調べ、複数個あれば次のステッ
プＳ３４（未処理送信遷移の蓄積）へ処理を進め、１個
であればステップＳ３５に処理を進める。カレント状態
の送信遷移数が０個であれば、図４のステップＳ７０へ
処理を進める。
状態が持つ送信遷移数を調べ、複数個あれば次のステッ
プＳ３４（未処理送信遷移の蓄積）へ処理を進め、１個
であればステップＳ３５に処理を進める。カレント状態
の送信遷移数が０個であれば、図４のステップＳ７０へ
処理を進める。
【００６４】（３−４）ステップＳ３４では、カレント
状態が持つ複数個の送信遷移のうちから任意の１個を選
び、残りはそれを持つカレント状態と合せてそれぞれ未
処理遷移スタックに蓄積し、次のステップＳ３５へ処理
を進める。
状態が持つ複数個の送信遷移のうちから任意の１個を選
び、残りはそれを持つカレント状態と合せてそれぞれ未
処理遷移スタックに蓄積し、次のステップＳ３５へ処理
を進める。
【００６５】（３−５）ステップＳ３５では、１つの送
信遷移に続いて１つ以上の送信遷移が連続して存在する
か否かを調べ、存在しなければそのまま送信遷移を実行
して次のステップＳ３６（検証終了遷移のチェック）に
処理を進め、存在すれば連続する送信遷移も一括して実
行し、その後、次のステップＳ３６へ処理を進める。但
し、途中で遷移に分岐がある場合は、その分岐がある状
態を遷移先とする。
信遷移に続いて１つ以上の送信遷移が連続して存在する
か否かを調べ、存在しなければそのまま送信遷移を実行
して次のステップＳ３６（検証終了遷移のチェック）に
処理を進め、存在すれば連続する送信遷移も一括して実
行し、その後、次のステップＳ３６へ処理を進める。但
し、途中で遷移に分岐がある場合は、その分岐がある状
態を遷移先とする。
【００６６】（３−６）ステップＳ３６では、ステップ
Ｓ３５での送信遷移の実行によりカレント状態とその遷
移先のシステム状態との間に検証終了遷移として記憶し
ていた送信遷移が現われたか否かを調べ、現われたなら
ば図４のステップＳ７０へ処理を進める。検証終了遷移
が現われなければ、次のシステム状態を生成するために
図４のステップＳ４０（遷移先システム状態の生成）へ
処理を進める。
Ｓ３５での送信遷移の実行によりカレント状態とその遷
移先のシステム状態との間に検証終了遷移として記憶し
ていた送信遷移が現われたか否かを調べ、現われたなら
ば図４のステップＳ７０へ処理を進める。検証終了遷移
が現われなければ、次のシステム状態を生成するために
図４のステップＳ４０（遷移先システム状態の生成）へ
処理を進める。
【００６７】（４）図４のステップＳ４０では、上述し
たステップＳ３０で探し出した送信遷移の実行により到
達するシステム状態を生成し、これを新たなカレント状
態としてメモリに記憶し、元のカレント状態をメモリか
ら消去してステップＳ２０（チャネルの状態の判定）に
戻る。
たステップＳ３０で探し出した送信遷移の実行により到
達するシステム状態を生成し、これを新たなカレント状
態としてメモリに記憶し、元のカレント状態をメモリか
ら消去してステップＳ２０（チャネルの状態の判定）に
戻る。
【００６８】（５）図４のステップＳ５０では、図６に
示す詳細を示す手順（Ｓ５１〜Ｓ５９）により、各プロ
セス毎の状態遷移グラフが持つ遷移情報から未受信信号
の受信先状態を探索して、図４の各ステップＳ６０（次
のシステム状態の生成）及びステップＳ８０（未処理遷
移を有するシステム状態への復帰）のうち、いずれに処
理を進めるべきかを判定する。これらＳ６０及びＳ８０
の各ステップの説明は後で行う。
示す詳細を示す手順（Ｓ５１〜Ｓ５９）により、各プロ
セス毎の状態遷移グラフが持つ遷移情報から未受信信号
の受信先状態を探索して、図４の各ステップＳ６０（次
のシステム状態の生成）及びステップＳ８０（未処理遷
移を有するシステム状態への復帰）のうち、いずれに処
理を進めるべきかを判定する。これらＳ６０及びＳ８０
の各ステップの説明は後で行う。
【００６９】（５−１）図６のステップＳ５１では、カ
レント状態中に等価停止状態が含まれているか否かを調
べ、含まれていればカレント状態以降の遷移系列は等価
停止状態が等価と判定した別の状態を含む遷移系列にお
いて調べられ、カレント状態以降のシステム状態の生成
を中止して別の遷移系列を調べるために、図４のステッ
プＳ８０へ処理を進める。カレント状態中に等価停止状
態が含まれていなければ、図６の次のステップＳ５２へ
処理を進める。
レント状態中に等価停止状態が含まれているか否かを調
べ、含まれていればカレント状態以降の遷移系列は等価
停止状態が等価と判定した別の状態を含む遷移系列にお
いて調べられ、カレント状態以降のシステム状態の生成
を中止して別の遷移系列を調べるために、図４のステッ
プＳ８０へ処理を進める。カレント状態中に等価停止状
態が含まれていなければ、図６の次のステップＳ５２へ
処理を進める。
【００７０】（５−２）ステップＳ５２では、図４のス
テップＳ８０を経てステップＳ２０及びＳ５０に処理が
進んで来たか否かを調べ、ステップＳ８０を経ていれ
ば、後述する如く同ステップＳ８０で未処理遷移スタッ
クから取り出した１つの未処理の受信先状態に対する処
理を行うことになるので、図６のステップＳ５５（受信
プロセスの受信先状態までの遷移）へ処理を進める。ス
テップＳ８０を経ていなければ、カレント状態から次の
システム状態を生成するための受信遷移の遷移先を探す
ために、次のステップＳ５３（カレント状態の遷移系列
上の受信先状態数のチェック）へ処理を進める。
テップＳ８０を経てステップＳ２０及びＳ５０に処理が
進んで来たか否かを調べ、ステップＳ８０を経ていれ
ば、後述する如く同ステップＳ８０で未処理遷移スタッ
クから取り出した１つの未処理の受信先状態に対する処
理を行うことになるので、図６のステップＳ５５（受信
プロセスの受信先状態までの遷移）へ処理を進める。ス
テップＳ８０を経ていなければ、カレント状態から次の
システム状態を生成するための受信遷移の遷移先を探す
ために、次のステップＳ５３（カレント状態の遷移系列
上の受信先状態数のチェック）へ処理を進める。
【００７１】（５−３）ステップＳ５３では、信号を含
むチャネルのうち任意のチャネルを選択し、選択したチ
ャネル内の最後尾の信号に対する受信先状態のうちカレ
ント状態の遷移系列上の受信先状態の数を調べ、複数個
あれば次のステップＳ５４（未処理受信先状態の蓄積）
へ処理を進め、１個であればステップＳ５５へ処理を進
める。ここで、チャネルの最後尾の信号に対して処理を
行うのは、同じチャネル内に複数の信号が含まれている
場合にはそれらを連続して受信する途中でデッドロック
にはなり得ないから、一つ一つ受信遷移を実行せずに最
後の受信遷移先状態まで一括して受信プロセスを進める
ためである。
むチャネルのうち任意のチャネルを選択し、選択したチ
ャネル内の最後尾の信号に対する受信先状態のうちカレ
ント状態の遷移系列上の受信先状態の数を調べ、複数個
あれば次のステップＳ５４（未処理受信先状態の蓄積）
へ処理を進め、１個であればステップＳ５５へ処理を進
める。ここで、チャネルの最後尾の信号に対して処理を
行うのは、同じチャネル内に複数の信号が含まれている
場合にはそれらを連続して受信する途中でデッドロック
にはなり得ないから、一つ一つ受信遷移を実行せずに最
後の受信遷移先状態まで一括して受信プロセスを進める
ためである。
【００７２】（５−４）ステップＳ５４では、カレント
状態の遷移系列上にある複数個の受信先状態のうちから
任意の１個を選び、残りはカレント状態と合せてそれぞ
れ未処理遷移スタックに蓄積し、次のステップＳ５５へ
処理を進める。即ち、プロセス毎の状態遷移グラフにお
いてカレント状態と同じ遷移系列上にない受信先状態は
未処理遷移スタックに蓄積しない。
状態の遷移系列上にある複数個の受信先状態のうちから
任意の１個を選び、残りはカレント状態と合せてそれぞ
れ未処理遷移スタックに蓄積し、次のステップＳ５５へ
処理を進める。即ち、プロセス毎の状態遷移グラフにお
いてカレント状態と同じ遷移系列上にない受信先状態は
未処理遷移スタックに蓄積しない。
【００７３】（５−５）ステップＳ５５では、受信プロ
セスを受信先状態まで遷移させ、その後次のステップＳ
５６（受信遷移先以降に送信遷移が連続する場合の一括
実行）へ処理を進める。
セスを受信先状態まで遷移させ、その後次のステップＳ
５６（受信遷移先以降に送信遷移が連続する場合の一括
実行）へ処理を進める。
【００７４】（５−６）ステップＳ５６では、受信先状
態に１つ以上の送信遷移が連続して存在するか否かを調
べ、存在しなければそのままにして次のステップＳ５７
（受信プロセス以外のプロセスの最小状態への遷移）へ
処理を進める。存在すれば、連続する送信遷移も一括し
て実行した先の状態を受信プロセスの遷移先状態とし、
次のステップＳ５７へ処理を進める。但し、途中で遷移
に分岐がある場合は、その分岐がある状態を遷移先とす
る。
態に１つ以上の送信遷移が連続して存在するか否かを調
べ、存在しなければそのままにして次のステップＳ５７
（受信プロセス以外のプロセスの最小状態への遷移）へ
処理を進める。存在すれば、連続する送信遷移も一括し
て実行した先の状態を受信プロセスの遷移先状態とし、
次のステップＳ５７へ処理を進める。但し、途中で遷移
に分岐がある場合は、その分岐がある状態を遷移先とす
る。
【００７５】（５−７）ステップＳ５７では、受信プロ
セス以外の他のプロセス状態について、受信プロセスの
遷移先状態に対する最小状態がカレント状態より進んで
いるならば当該最小状態まで遷移させ、次のステップＳ
５８（検証終了遷移のチェック）へ処理を進める。
セス以外の他のプロセス状態について、受信プロセスの
遷移先状態に対する最小状態がカレント状態より進んで
いるならば当該最小状態まで遷移させ、次のステップＳ
５８（検証終了遷移のチェック）へ処理を進める。
【００７６】（５−８）ステップＳ５８では、ステップ
Ｓ５７までの状態遷移の実行によりカレント状態とその
遷移先のシステム状態との間に検証終了遷移として記憶
していた送信遷移が現われたか否かを調べ、現われなけ
れば次のステップＳ５９（等価停止状態のチェック）へ
処理を進める。検証終了遷移が現われたならば、図４の
ステップＳ８０へ処理を進める。
Ｓ５７までの状態遷移の実行によりカレント状態とその
遷移先のシステム状態との間に検証終了遷移として記憶
していた送信遷移が現われたか否かを調べ、現われなけ
れば次のステップＳ５９（等価停止状態のチェック）へ
処理を進める。検証終了遷移が現われたならば、図４の
ステップＳ８０へ処理を進める。
【００７７】（５−９）ステップＳ５９では、カレント
状態から遷移先のシステム状態の間のいずれかのプロセ
スの状態に等価停止状態が含まれているか否かを調べ、
含まれていれば図４のステップＳ８０へ処理を進め、含
まれていなければ図４のステップＳ６０へ処理を進め
る。
状態から遷移先のシステム状態の間のいずれかのプロセ
スの状態に等価停止状態が含まれているか否かを調べ、
含まれていれば図４のステップＳ８０へ処理を進め、含
まれていなければ図４のステップＳ６０へ処理を進め
る。
【００７８】（６）図４のステップＳ６０では、上述し
たステップＳ５０で探し出した受信遷移の実行により到
達するシステム状態を生成し、これを新たなカレント状
態としてメモリに記憶し、元のカレント状態は不要のた
めメモリから消去して、ステップＳ２０（チャネルの状
態の判定）に処理を戻す。
たステップＳ５０で探し出した受信遷移の実行により到
達するシステム状態を生成し、これを新たなカレント状
態としてメモリに記憶し、元のカレント状態は不要のた
めメモリから消去して、ステップＳ２０（チャネルの状
態の判定）に処理を戻す。
【００７９】（７）ステップＳ７０では、デッドロック
の検出処理を行い、その後、ステップＳ８０に処理を進
める。例えば、ステップＳ３０のうちの送信遷移数のチ
ェック（ステップＳ３３）で送信遷移数が０個と判定さ
れた場合は、カレント状態より先に遷移することができ
ないので、カレント状態をデッドロックとして検出して
メモリに記憶し、次のステップＳ８０へ処理を進める。
の検出処理を行い、その後、ステップＳ８０に処理を進
める。例えば、ステップＳ３０のうちの送信遷移数のチ
ェック（ステップＳ３３）で送信遷移数が０個と判定さ
れた場合は、カレント状態より先に遷移することができ
ないので、カレント状態をデッドロックとして検出して
メモリに記憶し、次のステップＳ８０へ処理を進める。
【００８０】（８）ステップＳ８０では、カレント状態
から次のシステム状態を生成する必要がなくなったの
で、カレント状態をメモリから消去した後、未処理遷移
スタックから１つの未処理遷移とそれを持つシステム状
態を１つ取り出し、このシステム状態を新たなカレント
状態としてメモリに記憶し、ステップＳ２０のチャネル
状態判定に戻る。未処理遷移スタックが空であればシス
テム状態の生成が全て完了したことになるので、次のス
テップＳ９０へ処理を進める。
から次のシステム状態を生成する必要がなくなったの
で、カレント状態をメモリから消去した後、未処理遷移
スタックから１つの未処理遷移とそれを持つシステム状
態を１つ取り出し、このシステム状態を新たなカレント
状態としてメモリに記憶し、ステップＳ２０のチャネル
状態判定に戻る。未処理遷移スタックが空であればシス
テム状態の生成が全て完了したことになるので、次のス
テップＳ９０へ処理を進める。
【００８１】（９）ステップＳ９０では、グローバル検
証処理の全体、即ちプロセスの実行可能な状態遷移のみ
からなるプロセス毎の状態遷移グラフに基づいた到達可
能なシステム状態の生成とデッドロック検出とを全て終
了する。
証処理の全体、即ちプロセスの実行可能な状態遷移のみ
からなるプロセス毎の状態遷移グラフに基づいた到達可
能なシステム状態の生成とデッドロック検出とを全て終
了する。
【００８２】＜システム状態生成の具体例＞次に、図７
に示したプロセス毎の状態遷移グラフを入力として、上
述した図４〜図６の処理によりシステム状態を生成する
様子を、図８を参照して説明する。但し、以下の説明で
はシステム状態を、チャネルの状態を省略して、（プロ
セス１の状態，プロセス２の状態）という形式で表現す
る。このように省略しても、状態名の識別子が異なるた
め、誤解の可能性がない。
に示したプロセス毎の状態遷移グラフを入力として、上
述した図４〜図６の処理によりシステム状態を生成する
様子を、図８を参照して説明する。但し、以下の説明で
はシステム状態を、チャネルの状態を省略して、（プロ
セス１の状態，プロセス２の状態）という形式で表現す
る。このように省略しても、状態名の識別子が異なるた
め、誤解の可能性がない。
【００８３】（Ａ）まず、ステップＳ１０の処理によ
り、プロセス１の初期状態（ＲＥＡＤＹ．０）とプロセ
ス２の初期状態（ＩＤＬＥ．０）との組み合せで、初期
システム状態１０１（ＲＥＡＤＹ．０，ＩＤＬＥ．０）
が生成され、カレント状態としてメモリに記憶される。
り、プロセス１の初期状態（ＲＥＡＤＹ．０）とプロセ
ス２の初期状態（ＩＤＬＥ．０）との組み合せで、初期
システム状態１０１（ＲＥＡＤＹ．０，ＩＤＬＥ．０）
が生成され、カレント状態としてメモリに記憶される。
【００８４】（Ｂ）初期システム状態１０１では全ての
チャネルが空であるので、処理はステップＳ２０からス
テップＳ３０へと進み、初期システム状態１０１からの
送信遷移を探索する。ここでは、仮にプロセス１の送信
遷移−ＲＥＱ、プロセス２の送信遷移−ＡＬＡＲＭとい
う順で送信遷移が見つかったとする。従って、ステップ
Ｓ３３とステップＳ３４の処理により、カレント状態
（ＲＥＡＤＹ．０，ＩＤＬＥ．０）と未処理送信遷移−
ＡＬＡＲＭとを未処理遷移スタックに蓄積し、最初に−
ＲＥＱの送信遷移を処理する。ここで、この送信遷移−
ＲＥＱをどの状態からどの状態へ行ったかということを
状態名の識別子も含めて検証終了遷移として記憶してお
き、（ＲＥＡＤＹ．０，ＩＤＬＥ．０）なるシステム状
態１０１以降の全ての状態遷移系列の検証処理が終了す
るまで保存しておく。
チャネルが空であるので、処理はステップＳ２０からス
テップＳ３０へと進み、初期システム状態１０１からの
送信遷移を探索する。ここでは、仮にプロセス１の送信
遷移−ＲＥＱ、プロセス２の送信遷移−ＡＬＡＲＭとい
う順で送信遷移が見つかったとする。従って、ステップ
Ｓ３３とステップＳ３４の処理により、カレント状態
（ＲＥＡＤＹ．０，ＩＤＬＥ．０）と未処理送信遷移−
ＡＬＡＲＭとを未処理遷移スタックに蓄積し、最初に−
ＲＥＱの送信遷移を処理する。ここで、この送信遷移−
ＲＥＱをどの状態からどの状態へ行ったかということを
状態名の識別子も含めて検証終了遷移として記憶してお
き、（ＲＥＡＤＹ．０，ＩＤＬＥ．０）なるシステム状
態１０１以降の全ての状態遷移系列の検証処理が終了す
るまで保存しておく。
【００８５】（Ｃ）次に、ステップＳ４０の処理によ
り、プロセス１が送信遷移−ＲＥＱを実行した後のシス
テム状態１０２（ＷＡＩＴ．０，ＩＤＬＥ．０）を生成
し、それを新たなカレント状態としてメモリに記憶し、
且つ、元のカレント状態１０１（ＲＥＡＤＹ．０，ＩＤ
ＬＥ．０）をメモリから消去した後、元のステップＳ２
０へ戻る。
り、プロセス１が送信遷移−ＲＥＱを実行した後のシス
テム状態１０２（ＷＡＩＴ．０，ＩＤＬＥ．０）を生成
し、それを新たなカレント状態としてメモリに記憶し、
且つ、元のカレント状態１０１（ＲＥＡＤＹ．０，ＩＤ
ＬＥ．０）をメモリから消去した後、元のステップＳ２
０へ戻る。
【００８６】（Ｄ）このカレント状態１０２（ＷＡＩ
Ｔ．０，ＩＤＬＥ．０）ではチャネルに信号ＲＥＱが残
っているので、ステップＳ２０ではチャネルに未受信の
信号が有ると判定し、ステップＳ５０で未受信の信号Ｒ
ＥＱに対する受信先状態を探索する。送信遷移−ＲＥＱ
に対する受信プロセス２の受信先状態は既にＳＥＲＶＩ
ＣＥ．０とＦＡＵＬＴ．２との２つであるとプロセス検
証で判明している。ここでは仮に、図７に記述されてい
るＳＥＲＶＩＣＥ．０、ＦＡＵＬＴ．２という順で見つ
かったとする。従って、ステップＳ５３とステップＳ５
４の処理により、カレント状態１０２（ＷＡＩＴ．０，
ＩＤＬＥ．０）と未処理受信先状態ＦＡＵＬＴ．２とを
未処理遷移スタックに蓄積し、最初に受信先状態ＳＥＲ
ＶＩＣＥ．０の処理を行う。この受信先状態ＳＥＲＶＩ
ＣＥ．０に対する処理として、ステップＳ５６の処理に
より、その先に連続する２つの送信遷移−ＤＯＮＥ，−
ＡＬＡＲＭを実行した先の状態ＦＡＵＬＴ．１までプロ
セス２を遷移させる。
Ｔ．０，ＩＤＬＥ．０）ではチャネルに信号ＲＥＱが残
っているので、ステップＳ２０ではチャネルに未受信の
信号が有ると判定し、ステップＳ５０で未受信の信号Ｒ
ＥＱに対する受信先状態を探索する。送信遷移−ＲＥＱ
に対する受信プロセス２の受信先状態は既にＳＥＲＶＩ
ＣＥ．０とＦＡＵＬＴ．２との２つであるとプロセス検
証で判明している。ここでは仮に、図７に記述されてい
るＳＥＲＶＩＣＥ．０、ＦＡＵＬＴ．２という順で見つ
かったとする。従って、ステップＳ５３とステップＳ５
４の処理により、カレント状態１０２（ＷＡＩＴ．０，
ＩＤＬＥ．０）と未処理受信先状態ＦＡＵＬＴ．２とを
未処理遷移スタックに蓄積し、最初に受信先状態ＳＥＲ
ＶＩＣＥ．０の処理を行う。この受信先状態ＳＥＲＶＩ
ＣＥ．０に対する処理として、ステップＳ５６の処理に
より、その先に連続する２つの送信遷移−ＤＯＮＥ，−
ＡＬＡＲＭを実行した先の状態ＦＡＵＬＴ．１までプロ
セス２を遷移させる。
【００８７】（Ｅ）ステップＳ６０では、プロセス２の
状態ＦＡＵＬＴ．１を含むシステム状態１０３（ＷＡＩ
Ｔ．０，ＦＡＵＬＴ．１）を生成し、それを新たなカレ
ント状態としてメモリに記憶し、且つ元のカレント状態
１０２（ＷＡＩＴ．０，ＩＤＬＥ．０）をメモリから消
去した後、ステップＳ２０に戻る。
状態ＦＡＵＬＴ．１を含むシステム状態１０３（ＷＡＩ
Ｔ．０，ＦＡＵＬＴ．１）を生成し、それを新たなカレ
ント状態としてメモリに記憶し、且つ元のカレント状態
１０２（ＷＡＩＴ．０，ＩＤＬＥ．０）をメモリから消
去した後、ステップＳ２０に戻る。
【００８８】（Ｆ）ステップＳ２０ではカレント状態１
０３（ＷＡＩＴ．０，ＦＡＵＬＴ．１）のチャネルの状
態を調べると２つの未受信の信号ＤＯＮＥ，ＡＬＡＲＭ
が存在していることが判るので、ステップＳ５０へ進
む。
０３（ＷＡＩＴ．０，ＦＡＵＬＴ．１）のチャネルの状
態を調べると２つの未受信の信号ＤＯＮＥ，ＡＬＡＲＭ
が存在していることが判るので、ステップＳ５０へ進
む。
【００８９】（Ｇ）ステップＳ５０では、２つの未受信
の信号ＤＯＮＥ，ＡＬＡＲＭに対してステップＳ５３〜
Ｓ５５の処理により、受信プロセス１を最後の信号ＡＬ
ＡＲＭに対する受信先状態まで遷移させる。送信遷移−
ＡＬＡＲＭに対する受信プロセス１の受信先状態は既に
ＲＥＧＩＳＴＥＲ．１であると、プロセス検証処理で判
明している。
の信号ＤＯＮＥ，ＡＬＡＲＭに対してステップＳ５３〜
Ｓ５５の処理により、受信プロセス１を最後の信号ＡＬ
ＡＲＭに対する受信先状態まで遷移させる。送信遷移−
ＡＬＡＲＭに対する受信プロセス１の受信先状態は既に
ＲＥＧＩＳＴＥＲ．１であると、プロセス検証処理で判
明している。
【００９０】（Ｈ）しかし、カレント状態１０３（ＷＡ
ＩＴ．０，ＦＡＵＬＴ．１）のプロセス１が状態ＷＡＩ
Ｔ．０から受信先状態ＲＥＧＩＳＴＥＲ．１へ遷移する
途中には、初期状態ＲＥＡＤＹ．０と等価なＲＥＡＤ
Ｙ．２という等価停止状態が存在することが、既にプロ
セス検証処理で判明している。またカレント状態１０３
には他の受信遷移がない。そこで、ステップＳ５９の処
理により、ステップＳ８０に進み、ＲＥＡＤＹ．２以下
の遷移系列はＲＥＡＤＹ．０以下の繰り返しであること
から検証を中止することとし、別の遷移系列の検証に移
る。図８で、システム状態１０３から出た矢印は検証を
中止した遷移系列を示す。
ＩＴ．０，ＦＡＵＬＴ．１）のプロセス１が状態ＷＡＩ
Ｔ．０から受信先状態ＲＥＧＩＳＴＥＲ．１へ遷移する
途中には、初期状態ＲＥＡＤＹ．０と等価なＲＥＡＤ
Ｙ．２という等価停止状態が存在することが、既にプロ
セス検証処理で判明している。またカレント状態１０３
には他の受信遷移がない。そこで、ステップＳ５９の処
理により、ステップＳ８０に進み、ＲＥＡＤＹ．２以下
の遷移系列はＲＥＡＤＹ．０以下の繰り返しであること
から検証を中止することとし、別の遷移系列の検証に移
る。図８で、システム状態１０３から出た矢印は検証を
中止した遷移系列を示す。
【００９１】（Ｉ）ステップＳ８０では、カレント状態
１０３（ＷＡＩＴ．０，ＦＡＵＬＴ．１）をメモリから
消去した後、未処理遷移スタックから未処理の受信先状
態ＦＡＵＬＴ．２とそれをと共に記憶したシステム状態
（ＷＡＩＴ．０，ＩＤＬＥ．０）を１つ取り出すことに
より、システム状態１０２を復帰して、それを新たなカ
レント状態としてメモリに記憶し、ステップＳ２０に戻
る。
１０３（ＷＡＩＴ．０，ＦＡＵＬＴ．１）をメモリから
消去した後、未処理遷移スタックから未処理の受信先状
態ＦＡＵＬＴ．２とそれをと共に記憶したシステム状態
（ＷＡＩＴ．０，ＩＤＬＥ．０）を１つ取り出すことに
より、システム状態１０２を復帰して、それを新たなカ
レント状態としてメモリに記憶し、ステップＳ２０に戻
る。
【００９２】（Ｊ）ステップＳ２０ではカレント状態１
０２（ＷＡＩＴ．０，ＩＤＬＥ．０）のチャネルの状態
を調べると未受信の信号ＲＥＱが有ることが判るので、
ステップＳ５０へ進む。
０２（ＷＡＩＴ．０，ＩＤＬＥ．０）のチャネルの状態
を調べると未受信の信号ＲＥＱが有ることが判るので、
ステップＳ５０へ進む。
【００９３】（Ｋ）ステップＳ５０でカレント状態１０
２以降の未処理の受信先状態を探索するが、これは未処
理遷移スタックから取り出したＦＡＵＬＴ．２として既
に判明している。そこで、ステップＳ５５の処理により
受信プロセス２をＦＡＵＬＴ．２まで遷移させ、次のス
テップＳ６０へ進む。
２以降の未処理の受信先状態を探索するが、これは未処
理遷移スタックから取り出したＦＡＵＬＴ．２として既
に判明している。そこで、ステップＳ５５の処理により
受信プロセス２をＦＡＵＬＴ．２まで遷移させ、次のス
テップＳ６０へ進む。
【００９４】（Ｌ）ステップＳ６０では、プロセス２の
状態ＦＡＵＬＴ．２を含むシステム状態１０４（ＷＡＩ
Ｔ．０，ＦＡＵＬＴ．２）を生成し、それを新たなカレ
ント状態としてメモリに記憶し、且つ、元のカレント状
態１０２をメモリから消去した後、ステップＳ２０に戻
る。
状態ＦＡＵＬＴ．２を含むシステム状態１０４（ＷＡＩ
Ｔ．０，ＦＡＵＬＴ．２）を生成し、それを新たなカレ
ント状態としてメモリに記憶し、且つ、元のカレント状
態１０２をメモリから消去した後、ステップＳ２０に戻
る。
【００９５】（Ｍ）ステップＳ２０ではカレント状態１
０４（ＷＡＩＴ．０，ＦＡＵＬＴ．２）のチャネルの状
態を調べると未受信の信号ＡＬＡＲＭが存在することが
判るので、ステップＳ５０へ進む。
０４（ＷＡＩＴ．０，ＦＡＵＬＴ．２）のチャネルの状
態を調べると未受信の信号ＡＬＡＲＭが存在することが
判るので、ステップＳ５０へ進む。
【００９６】（Ｎ）ステップＳ５０では信号ＡＬＡＲＭ
の受信先状態を探索する。この場合、送信遷移−ＡＬＡ
ＲＭに対する受信プロセス１の受信先状態は既にＲＥＧ
ＩＳＴＥＲ．０とＷＡＩＴ．２との２つであることがプ
ロセス検証処理でプロセス毎の状態遷移グラフを生成す
る際に、判明している。しかし、カレント状態１０４と
同じ遷移系列上にはない受信先状態ＲＥＧＩＳＴＥＲ．
０にはカレント状態１０４から遷移することは有り得な
い。従ってＷＡＩＴ．２だけを受信プロセス１の受信先
状態とし、ステップＳ５５の処理により同プロセス１を
ＷＡＩＴ．２まで遷移させ、ステップＳ６０へ進む。
の受信先状態を探索する。この場合、送信遷移−ＡＬＡ
ＲＭに対する受信プロセス１の受信先状態は既にＲＥＧ
ＩＳＴＥＲ．０とＷＡＩＴ．２との２つであることがプ
ロセス検証処理でプロセス毎の状態遷移グラフを生成す
る際に、判明している。しかし、カレント状態１０４と
同じ遷移系列上にはない受信先状態ＲＥＧＩＳＴＥＲ．
０にはカレント状態１０４から遷移することは有り得な
い。従ってＷＡＩＴ．２だけを受信プロセス１の受信先
状態とし、ステップＳ５５の処理により同プロセス１を
ＷＡＩＴ．２まで遷移させ、ステップＳ６０へ進む。
【００９７】（Ｏ）ステップＳ６０では、プロセス１の
状態ＷＡＩＴ．２を含むシステム状態１０５（ＷＡＩ
Ｔ．２，ＦＡＵＬＴ．２）を生成し、それをカレント状
態としてメモリに記憶し、且つ、元のカレント状態１０
４をメモリから消去した後に、ステップＳ２０に戻る。
状態ＷＡＩＴ．２を含むシステム状態１０５（ＷＡＩ
Ｔ．２，ＦＡＵＬＴ．２）を生成し、それをカレント状
態としてメモリに記憶し、且つ、元のカレント状態１０
４をメモリから消去した後に、ステップＳ２０に戻る。
【００９８】（Ｐ）ステップＳ２０でカレント状態１０
５（ＷＡＩＴ．２，ＦＡＵＬＴ．２）のチャネルの状態
を調べると全てのチャネルが空であることが判るので、
ステップＳ３０に進む。
５（ＷＡＩＴ．２，ＦＡＵＬＴ．２）のチャネルの状態
を調べると全てのチャネルが空であることが判るので、
ステップＳ３０に進む。
【００９９】（Ｑ）ステップＳ３０では送信遷移を探索
するが、カレント状態１０５の各プロセス１，２の状態
ＷＡＩＴ．２及びＦＡＵＬＴ．２以降には送信遷移がな
いため、ステップＳ３３の処理により、ステップＳ７０
へ進む。
するが、カレント状態１０５の各プロセス１，２の状態
ＷＡＩＴ．２及びＦＡＵＬＴ．２以降には送信遷移がな
いため、ステップＳ３３の処理により、ステップＳ７０
へ進む。
【０１００】（Ｒ）その結果、ステップＳ７０では、シ
ステム状態１０５（ＷＡＩＴ．２，ＦＡＵＬＴ．２）を
デッドロックとして検出し、メモリに記憶したり、画面
に表示する等をして、ステップＳ８０に進む。
ステム状態１０５（ＷＡＩＴ．２，ＦＡＵＬＴ．２）を
デッドロックとして検出し、メモリに記憶したり、画面
に表示する等をして、ステップＳ８０に進む。
【０１０１】（Ｓ）ステップＳ８０ではカレント状態１
０５をメモリから消去した後、未処理遷移スタックから
未処理送信遷移−ＡＬＡＲＭとそれを持つシステム状態
（ＲＥＡＤＹ．０，ＩＤＬＥ．０）を１つ取り出すこと
により、システム状態１０１を復帰し、それを新たなカ
レント状態としてメモリに記憶し、ステップＳ２０に戻
る。
０５をメモリから消去した後、未処理遷移スタックから
未処理送信遷移−ＡＬＡＲＭとそれを持つシステム状態
（ＲＥＡＤＹ．０，ＩＤＬＥ．０）を１つ取り出すこと
により、システム状態１０１を復帰し、それを新たなカ
レント状態としてメモリに記憶し、ステップＳ２０に戻
る。
【０１０２】（Ｔ）続いて行われるシステム状態１０６
と１０７の生成、並びにシステム状態１０７以降の遷移
系列の検証中止は、既に説明したシステム状態１０２と
１０３の生成、並びにシステム状態１０３以降の遷移系
列の検証中止と同様の処理である。
と１０７の生成、並びにシステム状態１０７以降の遷移
系列の検証中止は、既に説明したシステム状態１０２と
１０３の生成、並びにシステム状態１０３以降の遷移系
列の検証中止と同様の処理である。
【０１０３】（Ｕ）その後、ステップＳ８０によりカレ
ント状態がシステム状態１０７（ＷＡＩＴ．１，ＦＡＵ
ＬＴ．０）からシステム状態１０６（ＲＥＡＤＹ．０，
ＦＡＵＬＴ．０）に復帰すると、処理はステップＳ２０
からＳ５０へ進み、システム状態１０６からの次の受信
先状態として、チャネル内の未受信の信号ＡＬＡＲＭの
受信先状態ＷＡＩＴ．２が求まる。
ント状態がシステム状態１０７（ＷＡＩＴ．１，ＦＡＵ
ＬＴ．０）からシステム状態１０６（ＲＥＡＤＹ．０，
ＦＡＵＬＴ．０）に復帰すると、処理はステップＳ２０
からＳ５０へ進み、システム状態１０６からの次の受信
先状態として、チャネル内の未受信の信号ＡＬＡＲＭの
受信先状態ＷＡＩＴ．２が求まる。
【０１０４】（Ｖ）ところが、システム状態１０６（Ｒ
ＥＡＤＹ．０，ＦＡＵＬＴ．０）のプロセス１が状態Ｒ
ＥＡＤＹ．０から状態ＷＡＩＴ．２へ遷移する途中に、
既に検証終了遷移として記憶したシステム状態１０１
（ＲＥＡＤＹ．０，ＩＤＬＥ．０）における送信遷移−
ＲＥＱが含まれている。従って、ステップＳ５８の処理
によりステップＳ８０に進むことにより、このような検
証終了遷移を含む状態遷移系列の重複した検証を中止す
る。
ＥＡＤＹ．０，ＦＡＵＬＴ．０）のプロセス１が状態Ｒ
ＥＡＤＹ．０から状態ＷＡＩＴ．２へ遷移する途中に、
既に検証終了遷移として記憶したシステム状態１０１
（ＲＥＡＤＹ．０，ＩＤＬＥ．０）における送信遷移−
ＲＥＱが含まれている。従って、ステップＳ５８の処理
によりステップＳ８０に進むことにより、このような検
証終了遷移を含む状態遷移系列の重複した検証を中止す
る。
【０１０５】（Ｗ）その結果、ステップＳ８０では未処
理遷移スタックから未処理遷移とそれを持つシステム状
態を取り出すことになるが、この場合は未処理遷移スタ
ックが空なので、ステップＳ９０へ進み全ての検証を終
了する。
理遷移スタックから未処理遷移とそれを持つシステム状
態を取り出すことになるが、この場合は未処理遷移スタ
ックが空なので、ステップＳ９０へ進み全ての検証を終
了する。
【０１０６】＜他の実施例＞上述した実施例ではグロー
バル検証処理における未処理遷移の扱いに明示的に未処
理遷移スタックを利用している。しかし、スタックを使
用しなくても、下記に示す基本処理を再帰的に実行する
ことにより、プロトコルの実行可能な状態遷移のみから
なるプロセス毎の状態遷移グラフの情報に従って、到達
可能なシステム状態の遷移系列の展開と削除を行うこと
ができる。
バル検証処理における未処理遷移の扱いに明示的に未処
理遷移スタックを利用している。しかし、スタックを使
用しなくても、下記に示す基本処理を再帰的に実行する
ことにより、プロトコルの実行可能な状態遷移のみから
なるプロセス毎の状態遷移グラフの情報に従って、到達
可能なシステム状態の遷移系列の展開と削除を行うこと
ができる。
【０１０７】＜基本処理＞上述した再帰的実行の基本処
理として、カレント状態において未処理遷移が存在する
場合には、そのうちの１つを実行して当該カレント状態
から到達可能なシステム状態を生成し、これを新たなカ
レント状態とする。新たなカレント状態に未処理遷移が
存在しなければ、デッドロックであるか否かを判定した
後、このカレント状態に至る直前のシステム状態に戻
り、この直前のシステム状態をカレント状態とする。
理として、カレント状態において未処理遷移が存在する
場合には、そのうちの１つを実行して当該カレント状態
から到達可能なシステム状態を生成し、これを新たなカ
レント状態とする。新たなカレント状態に未処理遷移が
存在しなければ、デッドロックであるか否かを判定した
後、このカレント状態に至る直前のシステム状態に戻
り、この直前のシステム状態をカレント状態とする。
【０１０８】
【発明の効果】本発明によるプロトコルの論理検証方法
は、第１従来方法で行っていたようなシステム状態を全
て生成してメモリに記憶することなく、また第２従来方
法で行っていたような全ての安定状態の生成処理を行う
ことなく、第１の処理ステップとしてプロトコル仕様が
有する遷移情報に従って、各プロセスの実行可能な状態
遷移のみからなるプロセス毎の状態遷移グラフを生成
し、同時に各プロセスの動作に関連するプロトコル誤り
を検出し、第２の処理ステップとして第１の処理ステッ
プで生成されたプロセス毎の状態遷移グラフが有する遷
移情報に従って、各プロセスの状態と各チャネルの状態
との組み合わせで定義されるシステム状態のうち到達可
能なシステム状態を順次生成し、生成した到達可能なシ
ステム状態のうちで、それ以上先へ遷移することができ
ないシステム状態をデッドロックとして検出する。従っ
て、本発明方法で調べるシステム状態の数は、第１従来
方法で調べるシステム状態の個数、あるいは第２従来方
法で生成する安定状態の個数に比べると、大幅に少なく
なる。また、本発明方法では検証が終了したシステム状
態全ては保持する必要はないから、検証終了の都度順次
メモリから消去することができ、従って必要とするメモ
リが大幅に減少し、第１，第２両従来方法では検証が困
難であった大規模な、あるいは複雑なプロトコル仕様で
も同じ容量のメモリで検証できる可能性がある。更に、
第１，第２両従来方法で必要であったメモリに記憶した
全てのシステム状態あるいは安定状態の検索処理が本発
明では不要となるため、必要とする処理量が大幅に減少
し、従来方法では実用的な時間内で終了しないような大
規模な、あるいは複雑なプロトコル仕様の検証でも、実
用的な時間内に終了する可能性がある。
は、第１従来方法で行っていたようなシステム状態を全
て生成してメモリに記憶することなく、また第２従来方
法で行っていたような全ての安定状態の生成処理を行う
ことなく、第１の処理ステップとしてプロトコル仕様が
有する遷移情報に従って、各プロセスの実行可能な状態
遷移のみからなるプロセス毎の状態遷移グラフを生成
し、同時に各プロセスの動作に関連するプロトコル誤り
を検出し、第２の処理ステップとして第１の処理ステッ
プで生成されたプロセス毎の状態遷移グラフが有する遷
移情報に従って、各プロセスの状態と各チャネルの状態
との組み合わせで定義されるシステム状態のうち到達可
能なシステム状態を順次生成し、生成した到達可能なシ
ステム状態のうちで、それ以上先へ遷移することができ
ないシステム状態をデッドロックとして検出する。従っ
て、本発明方法で調べるシステム状態の数は、第１従来
方法で調べるシステム状態の個数、あるいは第２従来方
法で生成する安定状態の個数に比べると、大幅に少なく
なる。また、本発明方法では検証が終了したシステム状
態全ては保持する必要はないから、検証終了の都度順次
メモリから消去することができ、従って必要とするメモ
リが大幅に減少し、第１，第２両従来方法では検証が困
難であった大規模な、あるいは複雑なプロトコル仕様で
も同じ容量のメモリで検証できる可能性がある。更に、
第１，第２両従来方法で必要であったメモリに記憶した
全てのシステム状態あるいは安定状態の検索処理が本発
明では不要となるため、必要とする処理量が大幅に減少
し、従来方法では実用的な時間内で終了しないような大
規模な、あるいは複雑なプロトコル仕様の検証でも、実
用的な時間内に終了する可能性がある。
【０１０９】特に、第２の発明では、第１の処理ステッ
プでプロセス毎の状態遷移グラフを生成する際に、各送
信遷移に対して受信プロセスの受信先状態を予め計算
し、遷移情報の１つとして保持しておき、これに対応し
て、第２の処理ステップでチャネルに未受信の信号を含
むシステム状態から同信号を受信した後のシステム状態
を生成する際に、同信号を送信したプロセスの送信遷移
に対して予め判明している受信プロセスの受信先状態を
用いて、次のシステム状態を生成するので、このような
工夫によりシステム状態の生成処理ひいてはデッドロッ
クの検出処理が簡単化して高速化する。
プでプロセス毎の状態遷移グラフを生成する際に、各送
信遷移に対して受信プロセスの受信先状態を予め計算
し、遷移情報の１つとして保持しておき、これに対応し
て、第２の処理ステップでチャネルに未受信の信号を含
むシステム状態から同信号を受信した後のシステム状態
を生成する際に、同信号を送信したプロセスの送信遷移
に対して予め判明している受信プロセスの受信先状態を
用いて、次のシステム状態を生成するので、このような
工夫によりシステム状態の生成処理ひいてはデッドロッ
クの検出処理が簡単化して高速化する。
【０１１０】また、第３の発明では、複数の未受信の信
号のうちで最後に送信された信号を選択し、この信号を
受信した後のシステム状態だけを生成する。つまり、連
続する多数の受信遷移を一括して全て実行してシステム
状態を生成するので、途中のシステム状態の生成が省略
できるので、システム状態の生成ひいてはデッドロック
の検出処理が高速化する。
号のうちで最後に送信された信号を選択し、この信号を
受信した後のシステム状態だけを生成する。つまり、連
続する多数の受信遷移を一括して全て実行してシステム
状態を生成するので、途中のシステム状態の生成が省略
できるので、システム状態の生成ひいてはデッドロック
の検出処理が高速化する。
【０１１１】更に、第４の発明では、プロセスの状態
を、最初の送信遷移とそれに続く一連の送信遷移とを一
括して全て実行した先の状態まで進め、その場合のシス
テム状態だけを生成し、途中のシステム状態の生成は行
わないので、このような工夫により、システム状態の生
成処理ひいてはデッドロックの検出処理が高速化する。
を、最初の送信遷移とそれに続く一連の送信遷移とを一
括して全て実行した先の状態まで進め、その場合のシス
テム状態だけを生成し、途中のシステム状態の生成は行
わないので、このような工夫により、システム状態の生
成処理ひいてはデッドロックの検出処理が高速化する。
【０１１２】また、第５の発明では、プロセスの状態
を、受信遷移とそれに続く一連の送信遷移とを一括して
全て実行した先の状態まで進め、その場合のシステム状
態だけを生成して、途中のシステム状態の生成は行わな
いので、このような工夫により、システム状態の生成処
理ひいてはデッドロックの検出処理が高速化する。
を、受信遷移とそれに続く一連の送信遷移とを一括して
全て実行した先の状態まで進め、その場合のシステム状
態だけを生成して、途中のシステム状態の生成は行わな
いので、このような工夫により、システム状態の生成処
理ひいてはデッドロックの検出処理が高速化する。
【０１１３】更に、第６の発明では、第１の処理ステッ
プでプロセス毎の状態遷移グラフを生成する際に、各プ
ロセスが各状態に到達するために他のプロセスが最小限
必要な遷移により到達する状態を「最小状態」として予
め計算し、遷移情報の１つとして保持しておき、これに
対応して、第２の処理ステップでチャネルに未受信の信
号を含むシステム状態から次のシステム状態を生成する
際に、受信プロセス以外の他の各プロセスについては、
受信プロセスの遷移先状態に対する最小状態を生成元の
システム状態を構成するプロセスの状態と比較して最小
状態の方が進んでいれば、他のプロセスを最小状態まで
一括して進めて次のシステム状態を生成するので、この
ような工夫により、システム状態の生成処理ひいてはデ
ッドロックの検出処理が高速化する。
プでプロセス毎の状態遷移グラフを生成する際に、各プ
ロセスが各状態に到達するために他のプロセスが最小限
必要な遷移により到達する状態を「最小状態」として予
め計算し、遷移情報の１つとして保持しておき、これに
対応して、第２の処理ステップでチャネルに未受信の信
号を含むシステム状態から次のシステム状態を生成する
際に、受信プロセス以外の他の各プロセスについては、
受信プロセスの遷移先状態に対する最小状態を生成元の
システム状態を構成するプロセスの状態と比較して最小
状態の方が進んでいれば、他のプロセスを最小状態まで
一括して進めて次のシステム状態を生成するので、この
ような工夫により、システム状態の生成処理ひいてはデ
ッドロックの検出処理が高速化する。
【０１１４】また、第７及び第８の発明では、第１の処
理ステップでプロセス毎の状態遷移グラフを生成する際
に、同じプロセス内の２つの状態がそれぞれに続く遷移
系列が全く等しくなるという意味で等価である場合に
は、後から生成した方の状態よりも以降の状態遷移グラ
フの生成を中止、従ってプロトコル誤りの検出を中止
し、且つまた、後から生成した方の状態を等価停止状態
とし、予め遷移情報の１つとして保持しておき、これに
対応して、第７の発明では、次のシステム状態の生成に
際し、生成元のシステム状態を構成するプロセスの状態
に等価停止状態が含まれていれば、次に生成しようとし
ていたシステム状態の生成処理を中止し、一方、第８の
発明では、生成元のシステム状態の代りに、生成元のシ
ステム状態から次に生成しようとするシステム状態の間
のいずれかのプロセスの状態の中に等価停止状態が含ま
れる場合も、次に生成しようとしていたシステム状態の
生成処理を中止し、重複した検証処理を避けているの
で、これらの工夫により、状態遷移グラフの生成処理が
高速化し、且つシステム状態の生成処理ひいてはデッド
ロックの検出処理が高速化する。
理ステップでプロセス毎の状態遷移グラフを生成する際
に、同じプロセス内の２つの状態がそれぞれに続く遷移
系列が全く等しくなるという意味で等価である場合に
は、後から生成した方の状態よりも以降の状態遷移グラ
フの生成を中止、従ってプロトコル誤りの検出を中止
し、且つまた、後から生成した方の状態を等価停止状態
とし、予め遷移情報の１つとして保持しておき、これに
対応して、第７の発明では、次のシステム状態の生成に
際し、生成元のシステム状態を構成するプロセスの状態
に等価停止状態が含まれていれば、次に生成しようとし
ていたシステム状態の生成処理を中止し、一方、第８の
発明では、生成元のシステム状態の代りに、生成元のシ
ステム状態から次に生成しようとするシステム状態の間
のいずれかのプロセスの状態の中に等価停止状態が含ま
れる場合も、次に生成しようとしていたシステム状態の
生成処理を中止し、重複した検証処理を避けているの
で、これらの工夫により、状態遷移グラフの生成処理が
高速化し、且つシステム状態の生成処理ひいてはデッド
ロックの検出処理が高速化する。
【０１１５】更に、第９の発明では、第２の処理ステッ
プでシステム状態を生成する際に、チャネルが空のシス
テム状態から或る送信遷移で始まる遷移系列により到達
するシステム状態とそれに続く一連のシステム状態との
検証を行った場合は、その遷移系列の始まりの送信遷移
を「検証終了遷移」として記憶しておき、全てのチャネ
ルが空の前記システム状態から別の送信遷移で始まる遷
移系列についてシステム状態を順次生成する途中に記憶
済みの「検証終了遷移」と同じ送信遷移が現われた場合
は、この送信遷移よりも先のシステム状態の生成処理を
中止するので、この工夫により、システム状態の生成処
理ひいてはデッドロックの検出処理が高速化する。
プでシステム状態を生成する際に、チャネルが空のシス
テム状態から或る送信遷移で始まる遷移系列により到達
するシステム状態とそれに続く一連のシステム状態との
検証を行った場合は、その遷移系列の始まりの送信遷移
を「検証終了遷移」として記憶しておき、全てのチャネ
ルが空の前記システム状態から別の送信遷移で始まる遷
移系列についてシステム状態を順次生成する途中に記憶
済みの「検証終了遷移」と同じ送信遷移が現われた場合
は、この送信遷移よりも先のシステム状態の生成処理を
中止するので、この工夫により、システム状態の生成処
理ひいてはデッドロックの検出処理が高速化する。
【図１】本発明のプロトコルの論理検証方法の基本的実
施例に係る処理フローを示す図。
施例に係る処理フローを示す図。
【図２】検証対象例のプロトコル仕様を示す図。
【図３】プロトコル仕様のメモリへの記憶形式例を示す
図。
図。
【図４】本発明のプロトコルの論理検証方法の具体的実
施例に係る第２の処理ステップ（グローバル検証）の処
理フローを示す図。
施例に係る第２の処理ステップ（グローバル検証）の処
理フローを示す図。
【図５】図４中の送信遷移先探索（ステップＳ３０）の
詳細な処理フローを示す図。
詳細な処理フローを示す図。
【図６】図４中の受信遷移先探索（ステップＳ５０）の
詳細な処理フローを示す図。
詳細な処理フローを示す図。
【図７】本発明のプロトコルの論理検証方法の具体的実
施例に係る第１の処理ステップ（プロセス検証）により
生成されるプロセス毎の状態遷移グラフの一例を示す
図。
施例に係る第１の処理ステップ（プロセス検証）により
生成されるプロセス毎の状態遷移グラフの一例を示す
図。
【図８】図７のプロセス毎の状態遷移グラフから生成さ
れるシステム状態の遷移グラフを示す図。
れるシステム状態の遷移グラフを示す図。
【図９】第２従来方法により生成されるプロセス毎の状
態遷移グラフの一例を示す図。
態遷移グラフの一例を示す図。
Ｓ１ 第１の処理ステップ（プロセス検証） Ｓ２ 第２の処理ステップ（グローバル検証）
フロントページの続き (51)Int.Cl.6 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｈ０４Ｌ 29/08
Claims (9)
- 【請求項１】 信号により表現されたプロトコル仕様を
入力として、このプロトコル仕様が有する遷移情報に従
ってプロトコルの動作を調べることにより、同プロトコ
ル仕様に含まれるプロトコル誤りを検出するプロトコル
の論理検証方法において： 入力されたプロトコル仕様が有する前記遷移情報に
従って、各プロセスの実行可能な状態遷移のみからなる
プロセス毎の状態遷移グラフを生成し、同時に、各プロ
セスの動作に関連するプロトコル誤りを検出する第１の
処理ステップと； 第１の処理ステップで生成されたプロセス毎の状態
遷移グラフが有する遷移情報に従って、各プロセスの状
態と各チャネルの状態との組み合わせで定義されるシス
テム状態のうち到達可能なシステム状態を順次生成し、
生成した到達可能なシステム状態のうちで、それ以上先
へ遷移することができないシステム状態をデッドロック
として検出する第２の処理ステップと；を含むことを特
徴とするプロトコルの論理検証方法。 - 【請求項２】 請求項１記載のプロトコルの論理検証方
法において： 第１の処理ステップでは、前記プロセス毎の状態遷
移グラフの生成に際し、各送信遷移に対してその送信信
号の受信により受信プロセスが遷移する先の状態である
受信先状態を計算し、その情報を保持すること； 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、第１の処理ステップで保持された受
信先状態の情報を利用して、チャネルに未受信の信号を
含むシステム状態から、同信号を受信した後のシステム
状態を生成すること；を特徴とするプロトコルの論理検
証方法。 - 【請求項３】 請求項１から２のうちいずれか一つに記
載のプロトコルの論理検証方法において： 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルに未受信の信号を複数含む
システム状態から次のシステム状態を生成する場合は、
複数の未受信の信号のうちから最後に送信された信号を
選択し、この選択した信号を受信した後のシステム状態
を次のシステム状態として生成すること；を特徴とする
プロトコルの論理検証方法。 - 【請求項４】 請求項１から３のうちいずれか一つに記
載のプロトコルの論理検証方法において： 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルが空のシステム状態から或
るプロセスの送信遷移を実行して次のシステム状態を生
成する場合に同送信遷移に続いて１つ以上の送信遷移が
連続して存在するときは、最初の送信遷移とそれに続く
一連の送信遷移を一括して実行した先の状態に当該プロ
セスを進めて、次のシステム状態を生成すること；を特
徴とするプロトコルの論理検証方法。 - 【請求項５】 請求項１から４のうちいずれか一つに記
載のプロトコルの論理検証方法において： 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルに未受信の信号を含むシス
テム状態から次のシステム状態を生成する場合に同信号
を受信すべき或るプロセスが同信号を受信した状態の先
に１つ以上の送信遷移が連続して存在するときは、同信
号の受信に続く一連の送信遷移を一括して実行した先の
状態に当該プロセスを進めて、次のシステム状態を生成
すること；を特徴とするプロトコルの論理検証方法。 - 【請求項６】 請求項１から５のうちいずれか一つに記
載のプロトコルの論理検証方法において： 第１の処理ステップでは、前記プロセス毎の状態遷
移グラフの生成に際し、各プロセスが各状態に到達する
ために他のプロセスが最小限必要な遷移により到達する
状態を最小状態として計算し、その情報を保持するこ
と； 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルに未受信の信号を含むシス
テム状態から次のシステム状態を生成する場合に、同信
号を受信すべき受信プロセス以外の他のプロセスについ
ては第１の処理ステップで保持された最小状態の情報を
利用して、受信プロセスが遷移先の状態に到達するため
の当該他のプロセスの最小状態が生成元のシステム状態
を構成する状態よりも進んでいれば、当該他のプロセス
の状態を前記最小状態まで進めて、次のシステム状態を
生成すること；を特徴とするプロトコルの論理検証方
法。 - 【請求項７】 請求項１から６のうちいずれか一つに記
載のプロトコルの論理検証方法において： 第１の処理ステップでは、前記プロセス毎の状態遷
移グラフの生成に際し、同じプロセス内の２つの状態が
それぞれに続く遷移系列が全く等しくなるという意味で
等価である場合は、後から生成した方の状態については
プロセスの等価停止状態として以後の状態遷移グラフの
生成とプロトコル誤りの検出を中止し、この等価停止状
態の情報を保持すること； 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、第１の処理ステップで保持された等
価停止状態の情報を利用して、元となるシステム状態を
構成するプロセスの状態の中に前記等価停止状態が含ま
れる場合は、次に生成しようとしていたシステム状態の
生成処理を中止すること；を特徴とするプロトコルの論
理検証方法。 - 【請求項８】 請求項１から６のうちいずれか一つに記
載のプロトコルの論理検証方法において： 第１の処理ステップでは、前記プロセス毎の状態遷
移グラフの生成に際し、同じプロセス内の２つの状態が
それぞれに続く遷移系列が全く等しくなるという意味で
等価である場合は、後から生成した方の状態については
プロセスの等価停止状態として以後の状態遷移グラフの
生成とプロトコル誤りの検出を中止し、この等価停止状
態の情報を保持すること； 第２の処理ステップでは、前記到達可能なシステム
状態に生成に際し、第１の処理ステップで保持された等
価停止状態の情報を利用して、元となるシステム状態か
ら次に生成するシステム状態の間のいずれかのプロセス
の状態の中に、前記等価停止状態が含まれる場合に、次
に生成しようとしていたシステム状態の生成処理を中止
すること；を特徴とするプロトコルの論理検証方法。 - 【請求項９】 請求項１から８のうちいずれか一つに記
載のプロトコルの論理検証方法において： 第２の処理ステップでは、前記到達可能なシステム
状態の生成に際し、チャネルが空のシステム状態から、
或る送信遷移で始まる遷移系列により到達するシステム
状態とそれに続く一連のシステム状態との検証を行った
場合に、前記送信遷移を検証終了遷移として記憶してお
き、前記チャネルが空のシステム状態から別の送信遷移
で始まる遷移系列についてシステム状態を生成する途中
で前記検証終了遷移として記憶していた送信遷移が現わ
れた場合は、同送信遷移よりも先のシステム状態の生成
処理を中止すること；を特徴とするプロトコルの論理検
証方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP6098312A JPH07307771A (ja) | 1994-05-12 | 1994-05-12 | プロトコルの論理検証方法 |
| US08/440,141 US5655075A (en) | 1994-05-12 | 1995-05-12 | Protocol method for validating an input protocol specification |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP6098312A JPH07307771A (ja) | 1994-05-12 | 1994-05-12 | プロトコルの論理検証方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH07307771A true JPH07307771A (ja) | 1995-11-21 |
Family
ID=14216414
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP6098312A Pending JPH07307771A (ja) | 1994-05-12 | 1994-05-12 | プロトコルの論理検証方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5655075A (ja) |
| JP (1) | JPH07307771A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009176081A (ja) * | 2008-01-25 | 2009-08-06 | Canon Inc | システム診断装置、方法およびプログラム |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5933633A (en) * | 1996-11-19 | 1999-08-03 | Good; Sebastian Erich | State table generating system |
| DE19723079C1 (de) * | 1997-06-02 | 1998-11-19 | Bosch Gmbh Robert | Fehlerdiagnosevorrichtung und -verfahren |
| US20030149962A1 (en) * | 2001-11-21 | 2003-08-07 | Willis John Christopher | Simulation of designs using programmable processors and electronically re-configurable logic arrays |
| US7328195B2 (en) * | 2001-11-21 | 2008-02-05 | Ftl Systems, Inc. | Semi-automatic generation of behavior models continuous value using iterative probing of a device or existing component model |
| US8214421B2 (en) * | 2002-06-17 | 2012-07-03 | Ibm International Group Bv | Conformance testing without reference implementation of an XML standard |
| US20040139185A1 (en) * | 2002-12-30 | 2004-07-15 | Wasilios Souflis | Decoupling a protocol from its implementation |
| US7302489B2 (en) * | 2003-08-01 | 2007-11-27 | Sap Ag | Systems and methods for synchronizing data objects among participating systems via asynchronous exchange of messages |
| EP1503310A1 (en) * | 2003-08-01 | 2005-02-02 | Sap Ag | Computer-implemented method and system to support in developing a process specification for a collaborative process |
| US7272614B2 (en) * | 2003-08-01 | 2007-09-18 | Sap Aktiengesellschaft | Computer-implemented method and system to support in developing a process specification for a collaborative process |
| US20050038824A1 (en) * | 2003-08-15 | 2005-02-17 | Joachim Kenntner | Quality of service in asynchronous message transfer |
| US7383289B2 (en) * | 2003-12-02 | 2008-06-03 | Sap Aktiengesellschaft | Updating and maintaining data in a multi-system network using asynchronous message transfer |
| US7392265B2 (en) * | 2003-12-02 | 2008-06-24 | Sap Ag | Updating data in a multi-system network that utilizes asynchronous message transfer |
| US20060004806A1 (en) * | 2004-06-01 | 2006-01-05 | Kraft Frank M | Updating data in a multi-system network that utilizes asynchronous message transfer |
| US20060167905A1 (en) * | 2005-01-27 | 2006-07-27 | Peiya Liu | Method and system for template data validation based on logical constraint specifications |
| US20060248012A1 (en) * | 2005-04-29 | 2006-11-02 | Stefan Kircher | Transmission of messages related to electronic documents |
| US10078575B2 (en) * | 2013-03-13 | 2018-09-18 | Microsoft Technology Licensing, Llc | Diagnostics of state transitions |
| US10164952B2 (en) * | 2016-02-16 | 2018-12-25 | Xerox Corporation | Method and system for server based secure auditing for revisioning of electronic document files |
| US10129032B2 (en) | 2016-02-16 | 2018-11-13 | Xerox Corporation | Secure revisioning auditing system for electronic document files |
| US10216562B2 (en) * | 2016-02-23 | 2019-02-26 | International Business Machines Corporation | Generating diagnostic data |
| CN112866229B (zh) * | 2021-01-13 | 2022-09-06 | 中国人民解放军国防科技大学 | 一种基于状态图的高速网络流量识别方法及*** |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS6171750A (ja) * | 1984-09-17 | 1986-04-12 | Kokusai Denshin Denwa Co Ltd <Kdd> | プロトコル検証回路 |
| CA1224880A (en) * | 1984-12-25 | 1987-07-28 | Yoshiaki Kakuda | Protocol validation system |
| FR2685838B1 (fr) * | 1991-12-27 | 1994-02-25 | Sgs Thomson Microelectronics Sa | Procede pour verifier la conformite a une norme d'une cellule representative d'un circuit dedie a la gestion d'un protocole de communication, et systeme pour sa mise en óoeuvre. |
-
1994
- 1994-05-12 JP JP6098312A patent/JPH07307771A/ja active Pending
-
1995
- 1995-05-12 US US08/440,141 patent/US5655075A/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009176081A (ja) * | 2008-01-25 | 2009-08-06 | Canon Inc | システム診断装置、方法およびプログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| US5655075A (en) | 1997-08-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH07307771A (ja) | プロトコルの論理検証方法 | |
| TW213994B (ja) | ||
| US5551047A (en) | Method for distributed redundant execution of program modules | |
| Attiya et al. | Bounds on the time to reach agreement in the presence of timing uncertainty | |
| CN106502769A (zh) | 分布式事务处理方法、装置及*** | |
| CN107219997A (zh) | 一种用于验证数据一致性的方法及装置 | |
| Koppol et al. | Incremental integration testing of concurrent programs | |
| CN109344208A (zh) | 路径查询方法、装置及电子设备 | |
| Lotker et al. | Distributed MST for constant diameter graphs | |
| Lee et al. | Conformance testing of protocols specified as communicating FSMs | |
| West | Protocol validation—principles and applications | |
| Wheeler et al. | Protocol analysis using numerical Petri nets | |
| CN112637010A (zh) | 一种设备的检查方法及装置 | |
| US10599552B2 (en) | Model checker for finding distributed concurrency bugs | |
| CN116827566A (zh) | 一种设备数据传输方法、装置及*** | |
| US6738936B2 (en) | Method for testing communication line to locate failure according to test point priorities in communication line management system | |
| Bonifácio et al. | Complete test suites for input/output systems | |
| CN114338410B (zh) | 路由路径文件生成方法、装置、***及相关设备 | |
| Duan et al. | Reducing test sequence length using invertible sequences | |
| Cypher et al. | Formal specification, verification, and automatic test generation of atm routing protocol: Pnni | |
| JPH04326433A (ja) | 通信ソフトウェア検証方法 | |
| Boyce et al. | Formalization of ISDN LAPD for conformance testing | |
| CN118413447A (zh) | 网络资产拓扑图的生成方法、装置、电子设备及存储介质 | |
| Rezake | Implementation of a Protocol Conformance Test Sequence Generation Methodology Using Distingushing Sequences | |
| JP3385231B2 (ja) | 通信網評価装置、通信網評価方法および通信網評価プログラムを記録した記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20020723 |