JPH1011274A - 通信ソフトウェア設計検証方式 - Google Patents

Abstract

(57)【要約】 【課題】 通信ソフトウェア設計の検証範囲を改善す
る。 【解決手段】トリガ定義表ファイル6 は、想定している
エンティティの状態、並びにトリガに応じて決まるエン
ティティの次動作内容をすべて定義したものである。状
態定義表ファイル7 は、想定しているエンティティの状
態、並びにトリガに応じて決まるエンティティの遷移先
次状態をすべて定義したものである。履歴管理表ファイ
ル8 は、前述トリガ、並びに前述状態により決まる試験
シナリオが記されている。検証プロバイダ処理手段5
は、トリガ定義表ファイル6 および状態定義表ファイル
7 に基き、試験シナリオに従って予め定められたフロー
チャート手順で検証を行い、通信ソフトウェアの停止
性、完全性、網羅性、などのチェックを行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、形式記述言語を用
いて設計される通信ソフトウェアの設計検証方式に関す
る。

【０００２】

【従来の技術】従来の通信ソフトウェアの設計検証方式
を公開特許公報「特願平3-27862 ；通信サービス仕様検
証方式」を例に説明する。図８は、該公報に記載の当該
技術のブロック図である。従来の通信ソフトウエアの設
計検証方式は、通信サービス仕様記述６００から、通話
中、保留中、初期状態を含む通信中状態を示す記述要素
６０６、およびこの通信中状態間を遷移させる要因とな
る記述である遷移トリガ６０７を出力する読み込み処理
手段６０１と、抽出した通信中状態の内「通話中」、
「保留中」、「初期状態」のそれぞれを、通信中状態パ
ラメータ６０８に変換する状態記述変換処理手段６０２
と、遷移トリガを予め定められた通信中状態間の遷移を
表す数値である遷移手順パラメータ６０９に変換するト
リガ記述変換処理手段６０３と、変換された通信中状態
パラメータ６０８と遷移手順パラメータ６０９とを演算
して、次通信中状態パラメータ６１０を算出する演算処
理手段６０４と、算出した次通信中状態の通信中状態パ
ラメータ６１０が、予め定められた禁止的な通信中と一
致するか、もしくは算出した次通信中状態パラメータ６
１０と通信サービス仕様記述６００から抽出して数値表
現した次通信中状態の通信中状態パラメータとの不一致
が生じるかを判定して通信サービス仕様記述６００内の
仕様誤りを検出する誤り検出処理手段６０５を備えてい
る。

【０００３】特に演算処理手段６０４の処理は、以下の
様に為される。読み込み処理手段６０１が抽出した「通
信中状態を示す記述要素６０６」「遷移トリガ６０７」
は、状態記述変換処理手段６０２、並びにトリガ記述変
換処理手段６０３により以下の様な式(1) 、並びに式
(2) に示すパラメータ表現として変換される。

【０００４】 通信中状態パラメータ8 （ｓ１, ｈ１｜ｓ２, ｈ２｜・・・ ｜ｓｎ, ｈｎ） （ｉ= １, ２,・・・, ｎ） (1) ｓｉ→１ ：通信回線ｉが通話中 ０ ：通信回線ｉが非通話中 ｈｉ→１ ：通信回線ｉが保留中 ０ ：通信回線ｉが非通話中 遷移手順パラメータ9 （Ｔｓ１, Ｔｈ１｜Ｔｓ２, Ｔｈ２｜・・・ ｜Ｔｓｎ , Ｔｈｎ） (2) （ｉ= １, ２,・・・, ｎ） Ｔｓｉ→＋１：通信回線ｉを通話中に遷移 −１：通信回線ｉを非通話中に遷移 ０：遷移を行わない Ｔｈｉ→＋１：通信回線ｉを保留中に遷移 −１：通信回線ｉを非通話中に遷移 ０：遷移を行わない 通信中状態パラメータ６０８は、各通信回線ｉごとの通
話中に関する表示値ｓｉと、保留中に関する表示値ｈｉ
との２つの表示値から構成される。通話中に関する表示
値ｓｉは、通話中、もしくは非通話中を表し、保留中に
関する表示値ｈｉは、保留中、もしくは非保留中を表
す。この２パラメータの組み合わせで通話中、保留中、
初期状態の３状態を表現する。ここでｉは、使用される
通信回線に関して割り当てられるｉｄ番号である。

【０００５】遷移手順パラメータ６０９は、通信中状態
パラメータ６０８内の２つの表示値の遷移を表す表示か
ら構成される。通話中に関する表示値の遷移を表す表示
値Ｔｓｉは、通話中に遷移、非通話中に遷移、遷移なし
の３つの状態を表し、保留中に関する表示値の遷移を表
す表示値Ｔｈｉは、保留中に遷移、非保留中に遷移、遷
移なしの３つの場合を表す。この２つの表示値で通信中
状態の遷移を表現する。

【０００６】演算処理手段６０４は次通信中状態の算出
する為に、通信中状態パラメータ６０８に遷移手順パラ
メータ６０９を加算する方法で求める。つまり式(3) 〜
(5)が成立する。

【０００７】 現通信中状態：（ｓｉ ，ｈｉ ） (3) 遷移手順 ：＜Ｔｓｉ，Ｔｈｉ＞ (4) 次通信中状態：（ｓｉ＋Ｔｓｉ、ｈｉ＋Ｔｈｉ） (5) 誤り検出処理手段６０５は、演算処理手順６０４からの
結果６１０を受けて、通信中状態に対する禁止的な遷移
トリガ、および遷移トリガと次通信中状態間の不整合を
検出する。この誤り検出処理手段６０５には、禁止的な
通信中状態に関する知識が保持されている。これは通信
中状態パラメータ６０８を用いた判定式として表現され
ている。この禁止的な通信中状態に関する知識の例を以
下の表に記す。

【０００８】

【０００９】通信中状態に対する禁止的な遷移トリガ６
０７は、演算処理手段６０４で求められた次通信中状態
パラメータ６１０が上記判定式を満足していれば検出さ
れる。遷移トリガ６０７と次通信中状態間との不整合
は、演算処理手段６０４で求められた次通信中状態の通
信中状態パラメータ６１０と、サービス仕様から抽出し
て数値表現した次通信中状態の通信中状態パラメータと
の不一致が生じていれば検出される。

【００１０】

【発明が解決しようとする課題】従来の通信ソフトウェ
ア設計検証方式には、以下５点の問題点が存在する。第
１の問題は状態量の記述能力が低く、状態数が４通りま
でしか表現出来ないことである。その為、電話サービス
の仕様記述では満足するが、コンピュータ間通信のプロ
トコル設計の検証には能力不足である。

【００１１】第２の問題は、記述検証能力が低い点にあ
る。通信ソフトウェアでは機能を階層表現して、各層で
の通信手順、プロトコルを設計するのが一般的な方法で
ある。設計の検証を行う場合は、各層毎の機能手順の確
認をすると共に、層に跨る手順確認も必要になる場合が
ある。しかし従来の通信ソフトウェア設計検証方式で
は、機能層の概念が無い為、上記の検証能力が低いもの
に止まっている。

【００１２】第３の問題は、検証が正常系処理のみを対
象としており、予期しない外部トリガ、外部イベントが
発生した場合の対処方法を全く考慮していない点にあ
る。通常、通信ソフトウェアは予期しないメッセージを
受けた場合でも、予め決められた手順で通信を収束させ
る必要があるが、従来の方法では、その停止性の保証が
出来ない。

【００１３】第４の問題は、仕様記述の完全性、健全
性、並びに網羅性の確認が出来ないことである。あるイ
ベントが発生した場合に、１つの遷移先、並びに処理手
続きが必ず決められるのが完全性である。また、あるイ
ベントが発生した場合に、決められる遷移先、並びに処
理手続きが妥当なものであることを保証するのが健全性
である。また、仕様記述に記載されたことが、必ず発生
することが網羅性である。従来の方式では、そのいずれ
も保証することは出来ない。

【００１４】第５の問題は、通信は複数の有限状態遷移
機械間で為されると見做し得るが、その停止性の検出が
出来ないということである。会話処理を繰り返した後、
必ず通信回線を正常に開放出来る必要があるが、従来の
方法はこの検出は出来ない。

【００１５】

【課題を解決するための手段】第１の発明は、通信ソフ
トウェア設計検証方式において、エンティティの状態並
びにトリガに応じて決まる該エンティティの次動作内容
をすべて定義したトリガ定義表ファイルと、前記エンテ
ィティの状態並びに前記トリガに応じて決まる該エンテ
ィティの遷移先次状態をすべて定義した状態定義表ファ
イルと、前記トリガ定義表ファイルおよび前記状態定義
表ファイルの内容に基き前記エンティティの状態遷移と
該状態遷移に応じた前記トリガの発生を繰返すことによ
り通信ソフトウェアの設計の検証を行う検証プロバイダ
処理手段を備えたことを特徴とする。

【００１６】また、第２の発明は、前記トリガ及び前記
エンティティの状態により決まる試験シナリオが記され
た履歴表管理ファイルを予め具備し、第１の発明におけ
る前記検証プロバイダ処理手段は前記通信ソフトウェア
の設計検証における前記トリガ及び前記エンティティの
状態に対応する前記試験シナリオに指定された前記トリ
ガを発生させることにより前記通信ソフトウェアの設計
検証を行うことを特徴とする。

【００１７】また、第３の発明は、第１の発明および第
２の発明における前記検証プロバイダ処理手段が、発呼
側から着呼側を経由して再び該発呼側に戻るまでの遷移
における該発呼側および該着呼側の前記エンティティの
状態および該エンティティの状態に対応して発生される
前記トリガの組が、前記遷移終了までに２組以上発生し
ていれば前記通信ソフトウェアは停止性エラーを有する
ものとすることを特徴とする。

【００１８】また、第４の発明は、第３の発明における
前記検証プロバイダ処理手段は、前記発呼側および前記
着呼側の前記エンティティの状態および該エンティティ
の状態に対応して発生される前記トリガの組が前記遷移
終了までに２組以上発生していても前記発呼側および前
記着呼側間でのバースト転送である場合は、前記通信ソ
フトウェアは前記停止性エラーを有しないとすることを
特徴とする。

【００１９】また、第５の発明は、第２の発明における
前記試験シナリオには、エラートリガを発生させるため
のシナリオを含むことを特徴とする。

【００２０】また、第６の発明は、第１の発明における
前記検証プロバイダ処理手段が前記トリガ定義表ファイ
ルに前記エンティティの次動作内容が一意に定義されて
いない場合または前記状態定義表ファイルに前記エンテ
ィティの遷移先次状態が一意に定義されていない場合は
前記通信ソフトウェアの設計内容をエラーとすることを
特徴とする。

【００２１】また、第７の発明は、第３の発明における
前記検証プロバイダ処理手段が前記発呼側および前記着
呼側の前記エンティティの状態および該エンティティの
状態に対応して発生される前記トリガの組をビット表現
し、前記遷移における任意の該組と該組の以前の全ての
該組のビット表現と排他論理割演算を行い、該演算の結
果に０の場合があれば前記通信ソフトウェアは停止性エ
ラーを有するものとすることを特徴とする。

【００２２】また、第８の発明は、第１の発明における
前記検証プロバイダ処理手段が前記通信ソフトウェアの
設計検証時に前記トリガ定義表ファイルにおける前記エ
ンティティの次動作内容および前記状態定義表ファイル
における前記エンティティの遷移先次状態で参照されて
いないものがあれば前記通信ソフトウェアは網羅性エラ
ーを有するものとすることを特徴とする。

【００２３】〔作用〕図１は、本発明の通信ソフトウェ
ア設計検証方式の基本原理を説明するためのブロック図
である。ここでは基本原理を中心に説明するため、検証
機構に関連する部分のみを記す。この基本原理の説明
は、開放型システム間相互接続（Open Systems Interco
nnection：ＩＳＯにより制定された国際通信規約、略称
はOSI ）の定義に基づく。

【００２４】図１中のトリガ定義表ファイル6 は、想定
しているエンティティの状態、並びにトリガに応じて決
まるエンティティの次動作内容をすべて定義したもので
あり、動作内容は符号化してビット列で表現される。前
述エンティティとは、OSI の定義に従い、メモリ上に常
駐する通信を行うプロセスに相当する。また、前述トリ
ガとは主にプリミティブであり、OSI の定義に従うもの
である。これは、通信機能層<i> のエンティティに対し
ては、通信機能層<i+1> 、もしくは通信機能層<i-1> か
らの処理要求のことである。状態定義表ファイル7 は、
想定しているエンティティの状態、並びにトリガに応じ
て決まるエンティティの遷移先次状態をすべて定義した
ものであり、動作内容は符号化してビット列で表現され
る。

【００２５】図１中の履歴管理表ファイル8 は、前述ト
リガ、並びに前述状態により決まる試験シナリオが記さ
れており、検証プロバイダ処理手段5 は、その試験シナ
リオに従い、図４および図５に記されるような予め定め
られたフローチャート手順で検証処理準備を行う。試験
シナリオとは、前述トリガ定義表ファイル6 、並びに状
態定義表ファイル7 をもとに「試験条件の設定」を記し
たものであり、先のトリガが発生する箇所での「設定条
件」を表形式で指定したものである。「設定条件」の中
には、敢えてエラーが発生する様なものも記載されてお
り、検証プロバイダ処理手段5 がその様な条件を選択し
た場合は、予め定められた方法で誤信号を作成して入力
し、プロトコル仕様記述に記載された手続きで後処理が
対応されていることの検証を行う。試験シナリオは、次
の４種類に分類される。「正常系シナリオ」「外部イベ
ントエラー系シナリオ」「ＰＤＵパラメータエラー系シ
ナリオ」「無起動ＰＤＵエラー系シナリオ」である。こ
のうち、「正常系シナリオ」以外の３つが、先のエラー
を発生させるための試験シナリオである。

【００２６】検証プロバイダ処理手段5 は試験シナリオ
を受けると、トリガ定義表ファイル6 から試験シナリオ
で指定されたプリミティブに相当するトリガデータビッ
ト列74を取り出し、メモリ上の状態管理テーブル9 の発
呼側（Sender側）の領域の１番の行にセットする。次に
検証プロバイダ処理手段5 は、状態定義表ファイル7で
指定された状態データビット列75を検索して取り出し、
発呼側（Sender側）の領域の２番の行にセットする。検
証プロバイダ処理手段5 は、発呼側（Sender側）から起
動したプリミティブに対する確認プリミティブが、着呼
側（Receiver側）を介して、再度、発呼側（Sender側）
に戻される迄、トリガデータビット列74と状態データビ
ット列75の状態管理テーブル9 における発呼側（Sender
側）の領域および着呼側（Receiver側）の領域の老番の
行へのセットを続ける。尚、検証プロバイダ処理手段5
が、状態定義表ファイル7 で指定された状態データビッ
ト列75と、トリガ定義表ファイル6 で指定されたトリガ
データビット列74を検索して取り出せない場合は、完全
性エラーを通知する。また、１件以上取り出される場合
は、健全性エラーを通知する。

【００２７】次に検証プロバイダ処理手段5 は、またト
リガ定義表ファイル6 に定義されたトリガデータビット
列74、並びに状態定義表ファイル7 に定義された状態デ
ータビット列75を参照する度に、そのレコードに含まれ
る試験パスカウンタビットを「TRUE（１）」にすること
で、「参照済」の印を付け、以後の試験実施の履歴管理
を行う。

【００２８】メモリ上の状態管理テーブル9 で、発呼側
（Sender側）から起動したプリミティブが、着呼側（Re
ceiver側）を介して、再度、発呼側（Sender側）に戻っ
て来たことと等価な状態になった場合、検証プロバイダ
処理手段5 は、状態管理テーブル9 の「メモリ領域の開
始アドレスポイント」と「試験開始行」の指定を引き数
として検証チェッカー処理手段起動イベント60を発行
し、検証チェッカー処理手段10を起動させる。検証チェ
ッカー処理手段10が起動すると、引き数で指定された状
態管理テーブル9 のメモリ領域の参照76を行う。その
後、検証対象であるプロトコル仕様記述の停止性判定を
以下の原理に基づく論理演算で行う。

【００２９】即ち、発呼側のエンティティの状態、指示
プリミティブに相当するトリガ、並びに着呼側のエンテ
ィティの状態、確認プリミティブに相当するトリガをま
とめてビット列（便宜上、組合せビット列と呼ぶ）で表
現し、有限回数で通信が停止出来ることの判定を排他論
理和演算で求める。バースト転送の様な意図的に複数Ｐ
ＤＵを集団転送する処理以外は、プロトコル仕様記述に
欠陥が無ければ、有限回数のＰＤＵのやり取りで通信が
完了するはずである。従って、バースト転送の様な意図
的に複数ＰＤＵを集団転送する処理以外は、プロトコル
仕様記述に欠陥が存在しない場合、組合せビット列は、
有限回数内で同じものが出現しないはずである。そこ
で、ある通信処理中断時点で、状態管理テーブル9 の組
合わせビット列を、状態管理テーブルの全行に渡り遡
り、最終行の組合わせビット列と比較する。バースト転
送の様な意図的に複数ＰＤＵを集団転送する処理以外で
同じビット列が出現することはないことから、比較の結
果、もし同一の組合せビット列が存在した場合は、通信
はエラーとなり処理は停止出来ないことになる。その様
な事態が発生するプロトコル仕様記述は間違いである。
従って、組合わせビット例を全行に渡り、最終行のそれ
と排他論理和演算すれば、仕様の停止性に関して検証出
来ることになる。

【００３０】バースト転送の様な意図的に複数ＰＤＵを
集団転送する処理を含めて、通信が停止出来ることの判
定計算には、含意演算を組み合わせて用いれば良い。含
意演算とは、命題論理の演算で、命題Ａと命題Ｂが与え
られた場合、「命題Ａならば命題Ｂである。（Ａ→
Ｂ）」という命題の真偽判定を行う演算である。ここ
で、命題Ａが「FAILURE(0)」である場合は、含意演算Ａ
→Ｂは必ず「TRUE(1) 」となり、命題Ｂは真偽に{don't
care}となる。ここで命題Ａは「ＰＤＵの有限回のやり
取りで、同一のものが出現する」を意味する。また命題
Ｂとは「バースト転送の様な意図的に複数ＰＤＵを集団
転送する処理中である」を意味する。その結果、バース
ト転送の様な意図的に複数ＰＤＵを集団転送する処理を
含めて、有限回数のＰＤＵのやり取りで通信が停止出来
ることの判定計算が可能となる。

【００３１】検証チェッカー処理手段10が、エラーを検
出した場合、停止性エラーの旨を検証プロバイダ処理手
段5 に報告する。検証プロバイダ処理手段5 は、履歴管
理ファイル8 に記された試験シナリオを全て終了した場
合は、トリガ定義表ファイル6 に定義されたトリガデー
タビット列74、並びに状態定義表ファイル7 に定義され
た状態データビット列75が全て参照されているか、否か
の網羅性判定を行い、無駄なプリミティブ、無駄なエン
ティティの状態が存在していないことを確認する。 〔目的〕本発明の目的は、従来、時間と労力を要するプ
ロトコル仕様記述に含まれる誤りの検出を自動的行うよ
うにすることにより、誤り検出を容易にし、また検出時
間の短縮を図ることにある。

【００３２】

【発明の実施の形態】次に、本発明について図面を参照
して説明する。

【００３３】図２は本発明の一実施例を示すブロック図
である。

【００３４】尚、本実施例における通信システムは、開
放型システム相互接続（Open Systems Interconnectio
n：ＩＳＯにより制定された国際通信規約、略称はＯＳ
Ｉ）の定義に基づく。

【００３５】図２において、通信ソフトウェアを形式記
述言語を用いて設計する場合、設計者は起動管理処理手
段1 へプロトコル仕様記述エディタ処理手段起動要求50
を入力する。その後、起動管理処理手段1 は、エディタ
起動要求イベント51を発行する。プロトコル仕様記述エ
ディタ処理手段2 は、エディタ起動要求イベント51を受
けると起動し、設計者から対象ソフトウェアを定義した
形式記述言語による仕様記述入力52を受ける。図３は、
形式記述言語による仕様記述入力52の例である。

【００３６】その後、設計者はプロトコル仕様記述エデ
ィタ処理手段2 に対し、入力対象ソフトウェアを定義し
た形式記述言語による仕様記述入力52に対するファイル
保存要求53を発行するので、プロトコル仕様記述エディ
タ処理手段2 は、入力された対象ソフトウェアを定義し
た形式記述言語による仕様記述入力52をテキストファイ
ルに総て書き移し、プロトコル仕様記述ファイル3 とし
て作成保存する。設計者がプロトコル仕様記述コンパイ
ラ処理手段4 の起動を要求する場合は、起動管理処理手
段1 へプロトコル仕様記述コンパイラ起動要求54を入力
する。その後、起動管理処理手段1 は、プロトコル仕様
記述エディタ処理手段2 で作成したプロトコル仕様記述
ファイル3 の名を引き数にコンパイラ起動要求イベント
55を発行する。

【００３７】プロトコル仕様記述コンパイラ処理手段4
は、起動管理処理手段1 から、コンパイラ起動要求イベ
ント55を受けると、トリガ定義表ファイル6 、状態定義
表ファイル7 、履歴管理表ファイル8 を生成するために
起動する。

【００３８】トリガ定義表ファイル6 は、想定している
エンティティの状態、並びにトリガに応じて決まるエン
ティティの次動作内容を、表形式ですべて定義したもの
であり、動作内容は符号化したビット列で表現される。
前述エンティティとは、OSIの定義に従い、メモリ上に
常駐する通信を行うプロセスに相当する。ここで、前述
トリガはOSI の定義に従うプリミティブに相当するもの
であり、通信機能層<i> のエンティティに対しては、通
信機能層<i+ 1>、もしくは通信機能層<i-1> からの処理
要求、並びに応答を意味する。

【００３９】状態定義表ファイル7 は、想定しているエ
ンティティ状態、並びにトリガに応じて決まるエンティ
ティの遷移先次状態を、表形式ですべて定義したもので
あり、エンティティ状態は符号化したビット列で表現さ
れる。

【００４０】履歴管理表ファイル8 には、前述トリガ、
並びに前述エンティティ状態により決まる試験シナリオ
が記されており、後述する検証プロバイダ処理手段5
は、その試験シナリオに従い、検証処理準備を行う。

【００４１】プロトコル仕様記述コンパイラ処理手段4
が、トリガ定義表ファイル6 、状態定義表ファイル7 、
履歴管理表ファイル8 を作成する場合は、コンパイラ起
動要求イベント55の引き数として指定されたプロトコル
仕様記述ファイル3 を開き、当該プロトコル仕様記述フ
ァイル3 に形式記述言語で記述された通信機能層<i>の
プロトコル仕様の内、エンティティ状態数70、並びにプ
リミティブ数72を数え上げて、エンティティの状態総
数、プリミティブ総数を求める。尚、通信機能層<i> の
エンティティ状態は、通信機能層<i+1> 、通信機能層<i
-1> からの要求、指示、応答、確認の４種類のプリミテ
ィブ待ち状態を明示的に定義する。その後、求めたエン
ティティの状態総数から、その状態総数を２進数で表現
する際に必要な最少桁数以上のビット列群を求め、各ビ
ット列にエンティティの各状態を割り振り、各状態を符
号化する。これを状態ビット列と称する。要求プリミテ
ィブ、応答プリミティブ、指示プリミティブ、確認プリ
ミティブに対しても、プリミティブ総数を求め、その総
数から２進数で表現する際に必要な最少桁数以上のビッ
ト列群を求め、各プリミティブを割り振り、符号化す
る。これをプリミティブビット列と称する。

【００４２】その後、プロトコル仕様記述コンパイラ処
理手段4 は、前述履歴管理表ファイル8 が管理する試験
シナリオ総数を減らす為に、プリミティブ内のパラメー
タ73について以下のルールで分類し、等価なものは纏め
る。この分類作業により、履歴管理表ファイル8 に記さ
れる試験シナリオ総数を減らすことが可能となり、検証
作業量を最少なものにすることが出来る。 （１）文字列：マスクパラメータとする。 （２）範囲規定数値：上限、下限を抽出して、上限、下
限のみ非マスクパラメータとする。 （３）範囲未規定数値：マスクパラメータとする。 （４）アサイン数値：非マスクパラメータとする。 （５）アサイン数値を含む構造体：アサイン数値の組み
合わせで、非マスクパラメータとする。

【００４３】その後、プロトコル仕様記述コンパイラ処
理手段4 は、すべての非マスクパラメータをメンバとす
る構造体を構成し、その構造体表現に含まれる非マスク
パラメータの組み合わせ総数を求める。その後、その組
み合わせ総数を２進数で表現する際に必要な最少桁数以
上のビット列で、前述の一覧に含まれる各メンバである
非マスクパラメータ値を割り振り、非マスクパラメータ
値を符号化する。尚、このビット列を非マスクパラメー
タビット列と定義する。また、マスクパラメータとして
扱われるものに対してもマスクパラメータビット列を１
つだけ定義する。

【００４４】その後、プロトコル仕様記述コンパイラ処
理手段4 は、トリガ定義表ファイル6 を作成する為に、
形式記述言語によるプロトコル仕様と、前述状態ビット
列、前述プリミティブビット列、前述非マスクパラメー
タビット列、前述マスクパラメータビット列から、状態
ビット列、２種類の要求応答プリミティブビット列、２
種類の指示確認プリミティブビット列、２種類の非マス
クパラメータビット列、２つのマスクパラメータビット
列、並びに後述する検証プロバイダ処理手段5が、試験
パスの履歴管理として利用する試験パスカウンタビット
で構成され、式(6) のレコード形式で定義されるトリガ
表を成すトリガ定義表ファイル6 を生成する。式(6) は
レコード構成のメンバを定義した式であり、”/**/”は
コメントを、”Structure of ”は構造体を意味する。
尚、(6) 式で表現されるビット列はトリガデータビット
列74とも称する。

【００４５】 TDT(Trigger Definition Table)::= {CS,In<n+1>,In<n-1>,In_Mask,In_Unmask,Out<n+1>,Out<n-1>,Out_Mask,Out_U nmask,Pass} (6) CS :Current_Situation_bits_sequence /* エンティテ ィの状態ビット列*/ In<n+1> :<n+1>layer_Primitive_bits_sequence /*n+1 層要求、応答プリミ ティブビット列*/ In<n-1> :<n-1>layer_Primitive_bits_sequence /*n-1 層指示、確認プリミ ティブビット列*/ In_Mask :Structure of Masked_parametor_bits_sequence /*プリミティブのマスクハ゜ラメータ を構造化したビット列*/ In_Unmask:Structure of Unmasked_parametor_bits_sequence /*プリミティブの非マスクハ゜ラメータ を構造化したビット列*/ Out<n+1> :<n+1>layer_Primitive_bits_sequence /*n+1 層指示、確認プリミ ティブビット列*/ Out<n-1> :<n-1>layer_Primitive_bits_sequence /*n-1 層要求、応答プリミ ティブビット列*/ Out_Mask :Structure of Masked_parametor_bits_sequence /*プリミティブのマスクハ゜ラメータ を構造化したビット列*/ Out_Unmask:Structure of Unmasked_parametor_bits_sequence /*プリミティブの非マスクハ゜ラメータ を構造化したビット列*/ Pass :Passing_Management_bit /*試験ハ゜スカウンタ ビット*/ このトリガ定義表ファイル6 は、想定しているエンィテ
ィの状態、並びにトリガに応じて決まるエンティティの
次動作内容をすべて定義したものであり、ある時点のエ
ンティティの状態を、{CS}のビット列で表現する。また
動作内容は、{Out<n+1> + Out<n-1> + Out_Mask + Out_
Unmask} の組み合わせビット列で表現される。また、主
にプリミティブであるトリガは、{In<n+1>+In_Mask+In_
Unmask}の組み合わせビット列、もしくは{In<n-1>+In _
Mask+In_Unmask}の組み合わせビット列で表現される。
プリミティブはOSI の定義に従うものであり、通信機能
層<i> のエンティティに対しては、通信機能層<i+1> 、
もしくは通信機能層<i-1>からの処理要求のことを意味
する。

【００４６】このトリガ定義表ファイル6 を参照する場
合は、エンティティの状態ビット列{CS}、並びにトリガ
である{In<n+1>+In_Mask+In_Unmask} の組み合わせビッ
ト列、もしくは{In<n-1>+In_Mask+In_Unmask} の組み合
わせビット列で表現されるプリミティブの具体的内容を
指定することで、動作内容である発行プリミティブの具
体値{Out<n+1>+Out<n-1>+Out_Mask+Out_Unmask} の組み
合わせビット列を得ることが出来る。

【００４７】その後、プロトコル仕様記述コンパイラ処
理手段4 は、状態定義表ファイル7を作成する為に、形
式記述言語によるプロトコル仕様と、前述状態ビット
列、前述プリミティブビット列、前述非マスクパラメー
タビット列、前述マスクパラメータビット列から、状態
ビット列、要求確認プリミティブビット列、指示確認プ
リミティブビット列、非マスクパラメータビット列、マ
スクパラメータビット列、遷移状態ビット列、並びに後
述する検証プロバイダ処理手段5 が、試験パスの履歴管
理として利用する試験パスカウンタビットで構成され、
式(7) のレコード形式で定義される状態遷移表を成す状
態定義表ファイル7 を生成する。式(7) はレコード構成
のメンバを定義した式であり、”/**/”はコメント
を、”Structure of”は構造体を意味する。尚、(7) 式
のビット列は状態データビット列75とも称する。

【００４８】 SDT(Situation Definition Table)::= {CS,In<n+1>,In<n-1>,In_Mask,In_Unmask,Pass} (7) CS :Current_Situation_bits_sequence /* エンティテ ィの状態ビット列*/ In<n+1> :<n+1>layer_Primitive_bits_sequence /*n+1 層要求、応答プリミ ティブビット列*/ In<n-1> :<n-1>layer_Primitive_bits_sequence /*n-1 層指示、確認プリミ ティブビット列*/ In_Mask :Structure of Masked_parametor_bits_sequence /* プリミティブのマスクハ゜ラメータ を構造化したビット列*/ In_Unmask:Structure of Unmasked_parametor_bits_sequence /* プリミティブの非マスクハ゜ラメータ を構造化したビット列*/ NS :Next_Situation_bits_sequence /* エンティティの 遷移先状態ビット列*/ Pass :Passing_Management_bit /*試験ハ゜スカウンタ ビット*/ この状態定義表ファイル7 は、想定しているエンティテ
ィの状態、並びにトリガに応じて決まるエンティティの
遷移先次状態をすべて定義したものであり、開始時点の
状態は、{CS}のエンティティの状態ビット列で表現され
る。

【００４９】遷移先次状態は、{NS}のビット列で表現さ
れる。またプリミティブであるトリガは、{In<n+1>+ In
_Mask+In_Unmask}の組み合わせビット列、もしくは{In<
n-1>+In_Mask+In_Unmask} の組み合わせビット列で表現
される。プリミティブはOSIの定義に従うものであり、
通信機能層<i> のエンティティに対しては、通信機能層
<i+1> もしくは通信機能層<i-1> からの処理要求、もし
くは応答のことである。

【００５０】この状態定義表ファイル7 を参照する場合
は、エンティティ状態ビット列{CS}、並びに{In<n+1>+
In_Mask+In_Unmask}の組み合わせビット列、もしくは{I
n<n-1>+In_Mask+In_Unmask} の組み合わせビット列で表
現されるプリミティブの具体的内容を指定することで、
エンティティの次状態である{NS}ビット列を得ることが
出来る。

【００５１】その後、プロトコル仕様記述コンパイラ処
理手段4 は、試験シナリオを定義管理する履歴管理ファ
イル8 を作成する。その為に、形式記述言語によるプロ
トコル仕様と、前述プリミティブビット列、前述非マス
クパラメータビット列、前述マスクパラメータビット
列、並びに後述する検証プロバイダ処理手段5 が、試験
パスの履歴管理として利用する試験パスカウンタビット
等から式(8) のレコード形式で定義される履歴管理ファ
イル8 を生成する。式(8) はレコード構成のメンバを定
義した式であり、”/**/”はコメントを、”Structure
of ”は構造体を、”Sequence of ”は順序付き構成を
意味する。履歴管理ファイル8 には、前述トリガ、並び
に前述エンティティの状態により決まる試験シナリオが
記されており、後述する検証プロバイダ処理手段5 は、
その試験シナリオで、どの様な試験内容か、を確認した
後、図４および図５のフローチャート手順により検証処
理を行う。検証の手順は全て、図４および図５の方法に
従う。

【００５２】 HMT(Testing History Management Table)::= {Start_In<n+1>,Start_In<n-1>,Cnt,Req,Up_p,Resp,Down_p,Return,TimeOut,P ass} (8) Start_In<n+1>：Start_<n+1>_layer_Primitive_bits_sequence /*開始<n+1> 層プリミティブビット列*/ Start_In<n-1>：Start_<n-1>_layer_Primitive_bits_sequence /*開始<n-1> 層プリミティブビット列*/ Cnt :Contine_Count_bits_sequence /* バースト転送回 数の指定ビット列*/ Req ：Start_<n+1>_layer_Primitive_Error_bit /* 開始<n+1> 層プリミティブのエラー設定の有無ビット*/ Up_p ：RequestPDU_Error_bits_sequence /* 要求PDU のエラー設 定の有無ビット列*/ Resp ：Response_Primitive_Error_bits_sequence /*応答のエラー設定の有無ビット列*/ Down_p ：ResponsePDU_Error_bits_sequence/* 応答PDU のエラー設 定の有無ビット列*/ Return ：Return_Primitive_Error_bits_sequence /*再発行PDU のエラー設定の有無ビット列*/ TimeOut ：TimeOut_bits_sequence /*タイムアウトエラーの設 定有無ビット列*/ Pass :Passing_Management_bit /* 試験ハ゜スカウンタ ビット*/ 試験シナリオには、正常系シナリオ、外部イベントエラ
ー系シナリオ、ＰＤＵパラメータエラー系シナリオ、無
起動ＰＤＵエラー系シナリオの４通りのものが存在して
いる。詳細は図６および図７に記す。正常系シナリオと
は、エラーが生じていない正常系処理の試験シナリオを
記したものである。それに対して、外部イベントエラー
系シナリオとは、応答処理が遅れたことでタイムアウト
処理が実行されることを模した試験シナリオであり、タ
イムアウト処理の後処理の検証を行う。

【００５３】ＰＤＵパラメータエラー系シナリオとは、
発呼側、着呼側の各々でエラーの含まれたＰＤＵを受理
した場合の後処理を検証するためのものである。無起動
ＰＤＵエラー系シナリオでは、発呼側エンティティ無し
に着呼側がＰＤＵを受けた場合の後処理の検証を行う。

【００５４】{Start_In<n+1>} とは、正常系シナリオ、
外部イベントエラー系シナリオ、ＰＤＵパラメータエラ
ー系シナリオで利用される試験シナリオの開始プリミテ
ィブビット列である。通常、通信機能層<i> は、上位の
通信機能層<i+1> から処理要求を受けて起動する。その
ため、開始プリミティブビット列を指定しなければなら
ない。それに対して、{Start_In<n-1>} とは、無起動Ｐ
ＤＵエラー系シナリオで利用される開始プリミティブビ
ット列である。これは、着呼側の通信機能層<i> が、突
然ＰＤＵを受けた場合の後処理の検証を行う際に利用す
る開始プリミティブを意味する。

【００５５】{Cnt} とは、複数の要求ＰＤＵを連続的に
受けてから、応答ＰＤＵが発行される様なバースト転送
の検証をするか、否かを指定するもので、要求ＰＤＵの
連続転送回数が、２進数ビット列で表現されている。こ
れは、正常系シナリオ以外は利用されない。

【００５６】{Req} は、先の開始プリミティブにエラー
が存在しているか、否かを指定するものである。また{U
p_p}、{Down_p}は発呼側、着呼側の通信機能層<i> でや
り取りされるＰＤＵにエラーを含めるか、否かを指定す
るものである。エラーを含める場合は、エラーが各パラ
メータに排他的に１つづつ含まれることが出来るだけの
シナリオ数が作成される。

【００５７】{Resp}は、着呼側エンティティの応答にエ
ラーが存在しているか、否かを指定するものである。{R
eturn}は、発呼側エンティティのＰＤＵ再発行処理で、
エラーが存在しているか、否かを指定するものである。
これらもエラーを含める場合は、エラーが各パラメータ
に排他的に１つづつ含めることが出来るだけのシナリオ
数が作成される。{TimeOut} は、外部イベントエラー系
シナリオで利用されるものである。尚外部イベントエラ
ー系シナリオ、ＰＤＵパラメータエラー系シナリオ、無
起動ＰＤＵエラー系シナリオで、エラーを指定する場合
は、必ず１箇所のみがエラーとなる様に相当分の試験シ
ナリオ本数が作成される。

【００５８】また１つの試験シナリオの終了は、「発呼
側エンティティが通信機能層<i+1>からの要求プリミテ
ィブを受付可能な状態にあること」かつ「着呼側エンテ
ィティが通信機能層<i-1> からの指示プリミティブを受
付可能な状態にあること」で、始めて可能となる。

【００５９】プロトコル仕様記述コンパイラ処理手段4
はトリガ定義表ファイル6 、並びに状態定義表ファイル
7 、履歴管理表ファイル8 を作成した後、処理終了のイ
ベント56を発行する。その結果、検証可能な状態に遷移
する。

【００６０】設計者が検証を開始する場合は、起動管理
処理手段1 に検証開始要求57を入力する。起動管理処理
手段1 は、検証開始要求57の入力を受けるとプロバイダ
起動要求イベント58を発行する。検証用プロバイダ処理
手段5 は、起動管理処理手段1 からプロバイダ起動要求
イベント58を受けると、メモリ上に通信機能層<i> の状
態管理テーブル9 を作成する為、十分な領域を確保す
る。状態管理テーブル9の実装にメモリが不足となった
場合は、検証用プロバイダ処理手段5 はメモリの追加確
保を実行するか、不要となったメモリ部分を仮想メモリ
にスワップアウトする様に、オペレーティングシステム
に依頼する。

【００６１】メモリ上に実装される状態管理テーブル9
は、発呼側、着呼側で生じるトリガであるプリミティ
ブ、並びにエンティティの状態を連続的に記録するもの
で、式(9) に記す様なレコード構成を持ったビット列で
構成される。

【００６２】 SMT(j)（Situation Management Table at Low = j 、ｊ means times of Se quence):: = {Sender_In<n+1>_Primitive_bits_sequence, /*n+1 層要求プリミテ ィブビット列*/ Sender_Out<n+1>_Primitive_bits_sequence, /*n+1 層確認プリミ ティブビット列*/ Structure of{Sender_masked_parametor_bits_sequence}, /* プリミティブのマスクハ゜ラメータ を構造化したビット列*/ Structure of{Sender_unmasked_parametor_bits_sequence}, /* プリミティブの非マスクハ゜ラメータ を構造化したビット列*/ Sender_Situation_bits_sequence, /* 発呼側状態ビット列*/ Sender_In<n-1>_Primitive_bits_sequence, /*n-1 層確認プリミテ ィブビット列*/ Sender_Out<n-1>_Primitive_bits_sequence, /*n-1 層要求プリミ ティブビット列*/ Sender_Window_bits_sequence, /* 発呼ウインドウパラ メータビット列*/ Structure of{Sender_masked_parametor_bits_sequence}, /* プリミティブのマスクハ゜ラメータ を構造化したビット列*/ Structure of{Sender_unmasked_parametor_bits_sequence}, /* プリミティブの非マスクハ゜ラメータ を構造化したビット列*/ Receiver_In<n+1>_Primitive_bits_sequence, /*n+1層応答プリミティ ブビット列*/ Receiver_Out<n+1>_Primitive_bits_sequence,/*n+1層指示プリミティ ブビット列*/ Structure of{Receiver_masked_parametor_bits_sequence}, /* プリミティブのマスクハ゜ラメータ を構造化したビット列*/ Structure of{Receiver_unmasked_parametor_bits_sequence}, /* プリミティブの非マスクハ゜ラメータ を構造化したビット列*/ Receiver_Situation_bits_sequence, /* 着呼側状態ビット列*/ Receiver_In<n-1>_Primitive_bits_sequence, /*n-1 層指示プリミテ ィブビット列*/ Receiver_Out<n-1>_Primitive_bits_sequence, /*n-1 層応答プリミテ ィブビット列*/ Receiver_Window_bits_sequence, /* 着呼ウインドウパラ メータビット列*/ Structure of{Receiver_masked_parametor_bits_sequence}, /* プリミティブのマスクハ゜ラメータ を構造化したビット列*/ Structure of{Receiver_unmasked_parametor_bits_sequence} /* プリミティブの非マスクハ゜ラメータ を構造化したビット列*/ } (9) 検証用プロバイダ処理手段5 は、前述履歴管理表ファイ
ル8 の試験シナリオに従い、トリガ定義表ファイル6 か
らトリガデータビット列74、並びに状態定義表ファイル
7 から状態データビット列75を取り出し、メモリ上にセ
ットする様にして検証を進めていく。検証の手順は、大
別すると発呼側のエンティティの状態ビット列、要求プ
リミティブビット列、および確認プリミティブビット
列、並びに着呼側のエンティティの状態ビット列、指示
プリミティブビット列、応答プリミティブビット列を試
験シナリオと、図４および図５で記されたフローチャー
トに従って、前述状態管理テーブル9 へセットするこ
と、並びに検証チェッカー処理手段10を起動し、前述作
用欄に記した排他論理和演算、および含有演算処理を施
すこと、並びに試験シナリオ実施後の確認をすることか
ら構成される。

【００６３】発呼側のエンティティの状態ビット列、要
求プリミティブビット列、および確認プリミティブビッ
ト列、並びに着呼側のエンティティの状態ビット列、指
示プリミティブビット列、および応答プリミティブビッ
ト列を、試験シナリオに従って前述状態管理テーブル9
へセットすることにより完全性、並びに健全性の検証を
行うことになる。また、検証チェッカー処理手段10を起
動し、前述状態管理テーブル9 へ参照76を行い、作用欄
に記した排他論理和演算、および含有演算処理を施すこ
とにより停止性の検証を行うことになる。また、試験シ
ナリオ実施後の確認をすることで網羅性の検証を行うこ
とになる。履歴管理表ファイル8 に記された試験シナリ
オを逐次参照しながら、具体的には図４および図５のフ
ローチャートで記された検証手順により検証が為され
る。以下、その具体的な説明を記す。

【００６４】ステップ１）検証用プロバイダ処理手段5
が、発呼側の最初の通信を起動する場合は、まずデリミ
タ行をSMT(j)にコピーする。このデリミタ行とは、履歴
管理表ファイル8の試験シナリオ毎に追加され、検証の
区切りを意味する。従って、検証する場合に最初になさ
れる手続きである。

【００６５】次にメモリ上で管理しているバースト転送
カウンタ「count 」の値を「０」にセットする。その
後、履歴管理表ファイル8 から試験パスカウンタビット
の付加していない最初の試験シナリオレコードを読み出
し、エラー発生箇所の確認記憶、並びに開始<n+1> 層プ
リミティブビット列を取り出す。その後、検証用プロバ
イダ処理手段5 は、トリガデータビット列の一部である 「エンティティ状態ビット列」{CS}と 「<n+1> 層要求、応答プリミティブビット列」{In<n+1
>} 「マスクパラメータビット列」{In_mask} 、 「非マスクパラメータビット列」{In_Unmask}をトリガ
定義表ファイル6 から取出し、状態管理テーブル9 の次
行であるSMT(j+4*count+1)行の 「発呼側状態ビット列」{Sender_Situation_bits_seque
nce}、 「<n+1> 層要求プリミティブビット列」{Sender_In<n+1
>_Primitive_bits_sequence}、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Sender_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Sender_unmasked_parametor_bits_seque
nce}}にセットする。その際、状態管理テーブル9 の他
の項目はFAILURE(0)にする。このステップを「初期ステ
ップ」と称する。

【００６６】ステップ２）次に検証用プロバイダ処理手
段5 は、状態管理テーブル9 のSMT(j+4*count+1)の 「発呼側状態ビット列」{Sender_Situation_bits_seque
nce}、 「<n+1> 層要求プリミティブビット列」{Sender_In<n+1
>_Primitive_bits_sequence}、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Sender_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Sender_unmasked_parametor_bits_seque
nce}}とトリガ定義表ファイル6 からトリガデータビッ
ト列の一部である 「n+1 層指示、確認プリミティブビット列」{Out<n+1
>}、 「n-1 層指示、確認プリミティブビット列」{Out<n-1
>}、 「マスクパラメータビット列」{Out_mask}、 「非マスクパラメータビット列」{Out_Unmask}、並びに
前述のSMT(j+4*count+1)上のパラメータと状態定義表フ
ァイル7 から状態データビット列の一部である「遷移エ
ンティティ状態ビット列」{NS}を検索する。検索の結
果、可能な場合はステップ３に遷移する。また異常な場
合はステップ１５に遷移する。このステップを「発呼要
求検索検査ステップ」と称する。

【００６７】ステップ３）検証用プロバイダ処理手段5
が、ステップ２にて正常に検索出来た場合は、前述トリ
ガ定義表ファイル6 と状態定義表ファイル7 から得た、 「n+1 層指示、確認プリミティブビット」{Out<n+1>}、 「n-1 層指示、確認プリミティブビット」{Out<n-1>}、 「マスクパラメータビット列」{Out_mask}、 「非マスクパラメータビット列」{Out_Unmask}、 「遷移エンティティ状態ビット列」{NS}、を状態管理テ
ーブル9 の次行であるSMT(j+4*c ount+2) 行の 「n+1 層確認プリミティブビット列」{Sender_Out<n+1>
_Primitive_bits_sequence} 、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Sender_masked_parametor_bits_sequenc
e}}、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Sender_unmasked_parametor_bits_seque
nce}}、 「発呼側状態ビット列」{Sender_Situation_bits_seque
nce}、 「n-1 層要求プリミティブビット列」{Sender_Out<n-1>
_Primitive_bits_sequence}にセットする。

【００６８】また、検証用プロバイダ処理手段5 が記憶
して試験シナリオが、正常系シナリオである場合、「バ
ースト転送回数の指定ビット列」を判定する。もし「バ
ースト転送回数の指定ビット列」が、バースト転送回数
である{0x01 〜0xFF} で指定されている場合は、メモリ
上で管理しているバースト転送カウンタ「count 」との
比較を行い、「バースト転送回数の指定ビット列」に達
していない場合は、SMT(j+4*count+2)行の「発呼ウイン
ドウパラメータビット列」 {Sender_Window_bits_seque
nce} の第１ビット列部分に「count 」値をセットす
る。

【００６９】また、「バースト転送回数の指定ビット
列」が「0x00{FAILURE(0)}」で指定されている場合は、
SMT(j+4*count+2)行の「発呼ウインドウパラメータビッ
ト列」{Sender_Window_bits_sequence} には、第１ビ
ット列部分、第２ビット列部分全て「FAILURE(0)」をセ
ットする。

【００７０】また、試験シナリオの「再発行ＰＤＵのエ
ラー設定の有無」{Return}で「Error Off && No Retur
n 」が指定されている場合は、第３ビット列部分には全
て「FAILURE(0)」をセットする。それに対し、エラー指
定を含めて「Return in 0x01〜0xFF Times」が指定され
ていて、かつ第３ビット列部分値が初期値でない場合
は、特に、第３ビット列部分は操作しない。

【００７１】他の項目については、「バースト転送回数
の指定ビット列」が指定されていない場合、SMT(j+4*co
unt+1)行のものをコピーする。また「バースト転送回数
の指定ビット列」が指定されている場合は、SMT(j+1)行
のものをコピーする。このステップを「発呼要求設定ス
テップ」と称する。

【００７２】ステップ４）検証用プロバイダ処理手段5
は、試験シナリオの記憶をしている。そこで試験シナリ
オのエラー判定を行い、正常系の場合は、状態管理テー
ブル9 のSMT(j+4*count+2)行を次行であるSMT(j+4*coun
t+3)行にコピーする。その上、 「n-1 層要求プリミティブビット列」{Sender_Out<n-1>
_Primitive_bits_sequence} 、 「発呼ウインドウパラメータビット列」 {Sender_Windo
w_bits_sequence}、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Sender_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Sender_unmasked_parametor_bits_seque
nce}}の各値をSMT(j+3)の 「n-1 層指示プリミティブビット」{Receiver_In<n-1>_
Primitive_bits_sequence}、 「発呼ウインドウパラメータビット列」{Receiver_Wind
ow_bits_sequence} 、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Receiver_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Receiver_unmasked_parametor_bits_seq
uence}}をそのままコピーする。

【００７３】また試験シナリオでＰＤＵパラメータエラ
ー系シナリオの場合は、試験シナリオで指定されている
非マスクパラメータに該当する一部のビットを意図的に
反転させた「プリミティブの非マスクハ゜ラメータ を構造化した
ビット列」、もしくは、一部のビットを反転させた「n-
1 層指示プリミティブビット」をコピーする。それ以外
は正常系処理と同じである。このステップを「発呼要求
伝送路変換ステップ」と称する。

【００７４】ステップ５）次に検証用プロバイダ処理手
段5 は、SMT(j+4*count+3)行の 「n-1 層指示プリミティブビット列」{Receiver_In<n-1
>_Primitive_bits_sequence}、 「着呼ウインドウパラメータビット列」{Receiver_Wind
ow_bits_sequence} 、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Receiver_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Receiver_unmasked_parametor_bits_seq
uence}}をもとに、トリガ定義表ファイル6 からトリガ
データビット列の一部である 「n+1 層指示、確認プリミティブビット」{Out<n+1>}、 「n-1 層指示、確認プリミティブビット」{Out<n-1>}、 「マスクパラメータビット列」{Out_mask}、 「非マスクパラメータビット列」{Out_Unmask}、並びに
前述の複数パラメータと状態定義表ファイル7 から状態
データビット列の一部である「遷移エンティティ状態ビ
ット列」{ NS} を検索する。検索の結果、可能な場合は
ステップ６に遷移する。また異常な場合はステップ１５
に遷移する。このステップを「着呼指示検索検査ステッ
プ」と称する。

【００７５】ステップ６）ステップ５で検証用プロバイ
ダ処理手段5 が検索出来た場合は状態管理テーブル9 の
SMT(j +4*count+3) 行を次行SMT(j+4*count+4)行にコピ
ーする。その際、SMT(j+4*count+4)行には、トリガ定義
表ファイル6 から得たトリガデータビット列の一部であ
る 「n+1 層指示、確認プリミティブビット」{Out<n+1>}、 「n-1 層要求、応答プリミティブビット」{Out<n-1>}、 「マスクパラメータビット列」{Out_mask}、 「非マスクパラメータビット列」{Out_Unmask}、並びに
前述の複数パラメータと状態定義表ファイル7 から得た
状態データビット列の一部である「遷移エンティティ状
態ビット列」{NS}を 「n-1 層応答プリミティブビット列」{Receiver_Out<n-
1>_Primitive_bits_sequence} 、 「n+1 層指示プリミティブビット列」{Receiver_Out<n+
1>_Primitive_bits_sequence} 、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Receiver_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Receiver_unmasked_parametor_bits_seq
uence}、 「着呼側状態ビット列」{Receiver_Situation_bits_seq
uence}にコピーする。 このステップを「着呼指示設定ステップ」と称する。

【００７６】ステップ７）次に検証用プロバイダ処理手
段5 は、状態管理テーブル9 のSMT(j+4*count+4)行に設
定されている 「n-1 層応答プリミティブビット列」{Receiver_Out<n-
1>_Primitive_bits_sequence} 、 「n+1 層指示プリミティブビット列」{Receiver_Out<n+
1>_Primitive_bits_sequence} 、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Receiver_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Receiver_unmasked_parametor_bits_seq
uence}、 「着呼側状態ビット列」{Receiver_Situation_bits_seq
uence}とトリガ定義表ファイル6 から、トリガデータビ
ット列の一部である 「n+1 層要求、応答プリミティブビット列」{In<n+1>}
、 「n-1 層指示、確認プリミティブビット列」{In<n-1>}
、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{I
n_Mask} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{In_Unmask}を読み出す。また、状態定義表ファイル7
から状態データビット列の一部である 「遷移エンティティ状態ビット列」{NS}を読み出す。
次に検証用プロバイダ処理手段5 は、記憶している試験
シナリオのエラー判定を行う。

【００７７】正常系シナリオの場合は、更に「バースト
転送回数の指定ビット列」の判定を行う。もし、「バー
スト転送回数の指定ビット列」が「FAILURE(0)」でな
く、且つメモリ上で管理しているバースト転送カウンタ
「count 」の値よりも「バースト転送回数の指定ビット
列」の２進数の方が大きい場合は、バースト転送しなけ
ればならないので、バースト転送カウンタ「count 」の
値をインクリメントする。

【００７８】その後、検証用プロバイダ処理手段5 は、
状態定義表ファイル7 の状態データビット列の一部であ
る 「遷移エンティティ状態ビット列」{NS}と 「<n+1> 層要求、応答プリミティブビット列」{In<n+1
>} 「マスクパラメータビット列」{In_mask} 、 「非マスクパラメータビット列」{In_Unmask} を状態管
理テーブル9 のSMT(j+4*(count-1)+5)行の 「着呼側状態ビット列」{Receiver_Situation_bits_seq
uence}、 「<n+1> 層要求プリミティブビット列」{Receiver_In<n
+1>_Primitive_bits_sequence}、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Receiver_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Receiver_unmasked_parametor_bits_seq
uence}}にセットして、ステップ２に戻る。

【００７９】また、「バースト転送回数の指定ビット
列」が「FAILURE(0)」である、もしくはメモリ上で管理
しているバースト転送カウンタ「count 」の値よりと
「バースト転送回数の指定ビット列」の２進数が等しい
場合は、状態管理テーブル9 のSMT(j+4*count+4)行を次
行であるSMT(j+4*count+5)行にコピーする。その際、検
証用プロバイダ処理手段5 は、前述の 「遷移エンティティ状態ビット列」{NS}と 「<n+1> 層要求、応答プリミティブビット列」{In<n+1
>} 「マスクパラメータビット列」{In_mask} 、 「非マスクパラメータビット列」{In_Unmask} を状態管
理テーブル9 のSMT(j+4*count+5)行の 「着呼側状態ビット列」{Receiver_Situation_bits_seq
uence}、 「<n+1> 層要求プリミティブビット列」{Receiver_In<n
+1>_Primitive_bits_sequence}、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Receiver_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Receiver_unmasked_parametor_bits_seq
uence}}にセットする。その際、他の項目は「FAILURE
(0)」にする。

【００８０】また試験シナリオのエラー判定を行い、Ｐ
ＤＵパラメータエラー系シナリオ系の場合は、前述の 「遷移エンティティ状態ビット列」{NS}と 「<n+1> 層要求、応答プリミティブビット列」{In<n+1
>} 「マスクパラメータビット列」{In_mask} 、 「非マスクパラメータビット列」{In_Unmask} の内、該
当するもののビット列の一部を反転して状態管理テーブ
ル9 のSMT(j+4*count+5)行の前述項目にセットしてステ
ップ１６に遷移する。

【００８１】また、試験シナリオのエラー判定を行い、
外部イベントエラー系シナリオの場合は、何も処理をせ
ずにステップ１７に遷移する。このステップを「着呼応
答判定ステップ」と称する。

【００８２】ステップ８）次に検証用プロバイダ処理手
段5 は、状態管理テーブル9 のSMT(j+4*count+5)行の 「着呼側状態ビット列」{Receiver_Situation_bits_seq
uence}、 「<n+1> 層指示プリミティブビット列」{Receiver_In<n
+1>_Primitive_bits_sequence}、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Receiver_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Receiver_unmasked_parametor_bits_seq
uence}}とトリガ定義表ファイル6 から、トリガデータ
ビット列の一部である 「n+1 層指示、確認プリミティブビット」{Out<n+1>}、 「n-1 層要求、応答プリミティブビット」{Out<n-1>}、 「マスクパラメータビット列」{Out_mask}、 「非マスクパラメータビット列」{Out_Unmask}、並びに
前述のSMT(j+4*count+5)行のパラメータと状態定義表フ
ァイル7 から状態データビット列の一部である 「遷移エンティティ状態ビット列」{NS}を検索する。検
索可能な場合はステップ９に遷移する。また異常な場合
はステップ１５に遷移する。このステップを「着呼応答
検索検査ステップ」と称する。

【００８３】ステップ９）検証用プロバイダ処理手段5
が、ステップ８にて正常に検索出来た場合は、前述トリ
ガ定義表ファイル6 と状態定義表ファイル7 から得た、
状態データビット列の一部である 「遷移エンティティ状態ビット列」{NS}、 「n+1 層指示、確認プリミティブビット」{Out<n+1>}、 「n-1 層要求、応答プリミティブビット」{Out<n-1>}、 「マスクパラメータビット列」{Out_mask}、 「非マスクパラメータビット列」{Out_Unmask}を状態管
理テーブル9 の次行であるSMT(j+4*count+6)行の 「着呼側状態ビット列」{Receiver_Situation_bits_seq
uence}、 「n+1 層指示プリミティブビット列」{Receiver_Out<n+
1>_Primitive_bits_sequence} 、 「n-1 層応答プリミティブビット列」{Receiver_Out<n-
1>_Primitive_bits_sequence} 、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Receiver_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Receiver_unmasked_parametor_bits_seq
uence}} 、にセットする。また検証用プロバイダ処理手
段5 は、記憶している試験シナリオの「バースト転送回
数の指定ビット列」の判定を行う。もし「バースト転送
回数の指定ビット列」が「FAILURE(0)」でない場合は、
「着呼ウインドウパラメータビット列」{Receiver_Wind
ow_bits_sequence} の第１ビット列部分には、SMT(j+4*
count+5)行の「発呼ウインドウパラメータビット列」{S
ender_Window_bits_sequence} の第１ビット列部分のも
のをコピーし、第２ビット列部分は「戻り」を意味する
「TRUE(1) 」を全ビットにセットする。

【００８４】また、「バースト転送回数の指定ビット
列」が「FAILURE(0)」の場合は、「着呼ウインドウパラ
メータビット列」{Receiver_Window_bits_sequence} の
全ビットには、「FAILURE (0) 」をセットする。 ま
た、他の項目はSMT(j+4*count+5)行のものをコピーす
る。このステップを「着呼応答設定ステップ」と称す
る。

【００８５】ステップ１０）検証用プロバイダ処理手段
5 は、試験シナリオの記憶をしている。そこで試験シナ
リオのエラー判定を行い、正常系の場合は、状態管理テ
ーブル9 のSMT(j+4*count+6)行を次行であるSMT(j+4*co
unt+7)行にコピーする。その上、 「n-1 層応答プリミティブビット列」{Receiver_Out<n-
1>_Primitive_bits_sequence} 、 「着呼ウインドウパラメータビット列」{Receiver_Wind
ow_bits_sequence} 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Receiver_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Receiver_unmasked_parametor_bits_seq
uence}} 、の各値をSMT(j+4*count+7)行の 「n-1 層確認プリミティブビット」{Sender_In<n-1>_Pr
imitive_bits_sequence}、 「発呼ウインドウパラメータビット列」{Sender_Window
_bits_sequence} 、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Sender_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Sender_unmasked_parametor_bits_seque
nce}}をそのままコピーする。

【００８６】また試験シナリオでＰＤＵパラメータエラ
ー系シナリオの場合は、シナリオで指定されている非マ
スクパラメータに該当する一部のビット列を意図的に反
転した「プリミティブの非マスクハ゜ラメータ を構造化したビッ
ト列」、もしくは、一部のビットを反転させた「n-1 層
確認プリミティブビット」をコピーする。それ以外は正
常系処理と同じである。このステップを「着呼応答伝送
路変換ステップ」と称する。 ステップ１１）次に検証用プロバイダ処理手段5 は、SM
T(j+4*count+7)行の 「n-1 層確認プリミティブビット」{Sender_In<n-1>_Pr
imitive_bits_sequence}、 「発呼ウインドウパラメータビット列」{Sender_Window
_bits_sequence} 、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Sender_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Sender_unmasked_parametor_bits_seque
nce}} 並びに、既に設定されていた「発呼側状態ビット列」{S
ender_Situation_bits_sequence}をもとに、トリガ定義
表ファイル6 から、トリガデータビット列の一部である 「n+1 層指示、確認プリミティブビット」{Out<n+1>}、 「n-1 層要求、応答プリミティブビット」{Out<n-1>}、 「マスクパラメータビット列」{Out_mask}、 「非マスクパラメータビット列」{Out_Unmask}、 並びに前述の複数パラメータと状態定義表ファイル7 か
ら、状態データビット列の一部である 「遷移エンティティ状態ビット列」{NS} を検索する。検索の結果、可能な場合はステップ１２に
遷移する。また異常な場合はステップ１５に遷移する。
このステップを「発呼確認検索検査ステップ」と称す
る。

【００８７】ステップ１２）前ステップで検証用プロバ
イダ処理手段5 が検索出来た場合は状態管理テーブル9
のSMT(j +4*count+7) 行を次行SMT(j+4*count+8)行にコ
ピーする。その際SMT(j+4*count+8)行には、トリガ定義
表ファイル6 から得た 「n+1 層指示、確認プリミティブビット」{Out<n+1>}、 「n-1 層要求、応答プリミティブビット」{Out<n-1>}、 「マスクパラメータビット列」{Out_mask}、 「非マスクパラメータビット列」{Out_Unmask}、並びに
前述の複数パラメータと状態定義表ファイル7 から得た
「遷移エンティティ状態ビット列」{NS}を 「n-1 層要求プリミティブビット」{Sender_Out<n-1>_P
rimitive_bits_sequence} 、 「n+1 層確認プリミティブビット列」{Sender_Out<n+1>
_Primitive_bits_sequence} 、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Sender_masked_parametor_bits_sequenc
e}}、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Sender_unmasked_parametor_bits_seque
nce} 、 「発呼側状態ビット列」{Sender_Situation_bits_seque
nce}にセットする。このステップを「発呼確認設定ステ
ップ」と称する。

【００８８】ステップ１３）次に検証用プロバイダ処理
手段5 は、記憶している試験シナリオのエラー判定を行
い、連続して再要求を行うか、否かを確認する。もし連
続要求を行うシナリオである場合は、バースト転送カウ
ンタ「count 」の値を「０」に再設定し、「発呼ウイン
ドウパラメータビット列」{Sender_Window_bits_sequen
ce} の第３ビット列部分をインクリメントして、再度ス
テップ２から、同様のことを繰り返す。その際、再要求
プリミティブにエラーの設定をするか、否かの判断も合
わせて実施する。

【００８９】また、連続して再要求を行わない場合は、
「発呼側エンティティが通信機能層<i+1> からの要求プ
リミティブを受付可能な状態にあること」かつ「着呼側
エンティティが通信機能層<i-1> からの指示プリミティ
ブを受付可能な状態にあること」を確認する。このステ
ップを「再要求判定ステップ」と称する。

【００９０】ステップ１４）ステップ１からステップ１
３、および後述ステップ１６、後述ステップ５１〜後述
ステップ６５の各々で検証用プロバイダ処理手段5 は、
各データビット列を状態管理テーブル9 の各行SMT(j+4*
count+1)〜SMT(j+4*count+n)にセットすると、参照され
たトリガ定義表ファイル6 、および状態定義表ファイル
7 の参照レコードに付加している試験パスカウンタビッ
ト{Passing_Management_bits_sequence ｝をTRUE(1) に
変更し、検証済みとする。

【００９１】また履歴管理ファイル8 の試験パスカウン
タビット{Passing_Management_bits_sequence ｝も同様
にTRUE(1) に変更し、検証済みとする。その後、ステッ
プ１８へ遷移する。このステップを「参照済設定ステッ
プ」と称する。

【００９２】ステップ１５）検証用プロバイダ処理手段
5 が、ステップ２、ステップ５、ステップ８、ステップ
１１、および後述ステップ１６で検索した結果、該当す
るレコード、並びにビット列が取り出せない場合は、完
全性エラー発生イベント59を発行して、ステップ２３へ
遷移する。

【００９３】また、該当するレコード、並びにビット列
が複数件、取り出される場合は、健全性エラー発生イベ
ント63を発行して、ステップ２３へ遷移する。このステ
ップを「エラー判定ステップ」と称する。

【００９４】ステップ１６)ステップ７で、試験シナリ
オのエラー判定を行い、ＰＤＵパラメータエラー系シナ
リオ系の場合は、 「遷移エンティティ状態ビット列」{NS}と 「<n+1> 層要求、応答プリミティブビット列」{In<n+1
>} 「マスクパラメータビット列」{In_mask} 、 「非マスクパラメータビット列」{In_Unmask} の内、該
当するもののビット列の一部を反転して状態管理テーブ
ル9 のSMT(j+4*count+5)行の 「着呼側状態ビット列」{Receiver_Situation_bits_seq
uence}、 「<n+1> 層指示プリミティブビット列」{Receiver_In<n
+1>_Primitive_bits_sequence}、 「プリミティブのマスクハ゜ラメータ を構造化したビット列」{S
tructure of{Receiver_masked_parametor_bits_sequenc
e}} 、 「プリミティブの非マスクハ゜ラメータ を構造化したビット列」
{Structure of{Receiver_unmasked_parametor_bits_seq
uence}}項目にセットすると共に、トリガ定義表ファイ
ル6 から、トリガデータビット列の一部である 「n+1 層指示、確認プリミティブビット」{Out<n+1>}、 「n-1 層要求、応答プリミティブビット」{Out<n-1>}、 「マスクパラメータビット列」{Out_mask}、 「非マスクパラメータビット列」{Out_Unmask}、並びに
前述のSMT(j+4*count+5)行のパラメータと状態定義表フ
ァイル7 から、状態データビット列の一部である 「遷移エンティティ状態ビット列」{NS}を検索する。検
索の結果、「n+1 層指示、確認プリミティブビット」{O
ut<n+1>}で着呼側の通信機能層<i+1> のエンティティに
エラー応答をする様になっている場合はステップ７に戻
る。その場合、ＰＤＵパラメータエラー系シナリオに
は、エラー処理の後に正常系処理をする様に設定してあ
る。それ故、ステップ７を再度、実施することで、ステ
ップ８に戻ることになる。また検索の結果、異常な場合
はステップ１５に遷移する。このステップを「ＰＤＵパ
ラメータエラー系処理ステップ」と称する。

【００９５】ステップ１７）ステップ７で、試験シナリ
オのエラー判定を行い、外部イベントエラー系シナリオ
が指定されている場合、検証プロバイダ処理手段5 は、
状態管理テーブルの全行、SMT(all)行をコピーして全く
同一の状態管理テーブル9 をメモリ上に新たに作成し、
一方を発呼側、もう一方を着呼側と見なす。

【００９６】着呼側の後処理の試験は、無起動ＰＤＵエ
ラー系シナリオに基づいて実施される。発呼側では、SM
T(j+4*count+5)行で、一連の処理を暫定的に打ち切り、
外部イベントエラー系処置の開始<n+1> プリミティブを
指定して、履歴管理ファイル8 から試験シナリオを取り
出し、ステップ１〜ステップ１５の処理と等価な手続き
を持つステップ５１〜ステップ６５をSMT(j+4*count+6)
行から実施する。尚、ステップ１４で起動されるステッ
プ１８は、ステップ１４と等価なステップ６４からも同
様に起動される。尚、ステップ５１〜ステップ６５の名
称は、それぞれステップ１〜ステップ１５の名称に「サ
ブ」の接頭子を付けた名称で命名される。このステップ
を「外部イベントエラー系処理ステップ」と称する。

【００９７】ステップ１８）検証プロバイダ処理手段5
は、ステップ１４を完了した段階で、被検通信機能層<i
> の指定を引き数として検証チェッカー処理手段起動イ
ベント60を発行し、停止性の検証を行う。その後、前述
検証プロバイダ処理手段5 は、前述検証チェッカー処理
手段10の停止性エラーイベント61、もしくは正常終了イ
ベント62待ちに状態遷移する。このステップを「検証チ
ェッカー起動ステップ」と称する。

【００９８】ステップ１９）検証チェッカー処理手段10
は、状態管理テーブル9 の「メモリ領域の開始アドレス
ポインタ」と「試験開始行」の指定を引き数として、検
証チェッカー処理手段起動イベント60を受けると起動す
る。起動した時点で、状態管理管理テーブル9 のメモリ
領域の参照76を行う。その後、式(11)〜式(17)で構成さ
れる式(10)の計算をすることで、このプロトコル仕様記
述における処理の停止性を判定する。もしProtocol_sta
tus が「TRUE(1) 」であれば、停止性が確保されるので
検証チェッカー処理手段10は、正常終了イベント62を発
行して、再度検証チェッカー処理手段起動イベント60待
ちとなる。それに対して、Protocol_status が「FAILUR
E(0)」であれば、このプロトコル仕様記述では処理要求
の発振が発生することを意味するので、停止性が確保さ
れない。その場合は検証チェッカー処理手段10は、停止
性エラーイベント61を発行して、再度検証チェッカー処
理手段起動イベント60待ちとなる。これを「停止性検証
ステップ」と称する。ここで、式(10)〜式(17)の意味
は、以下の２点に集約される。

【００９９】発呼側のエンティティの状態、指示プリミ
ティブに相当するトリガ、発呼ウインドウパラメータ、
並びに着呼側のエンティティの状態、確認プリミティブ
に相当するトリガ、着呼ウインドウパラメータをまとめ
てビット列で表現し、有限回数で通信が停止出来ること
の判定を排他論理和演算で求める。バースト転送の様な
意図的に複数ＰＤＵを集団転送する処理以外は、プロト
コル仕様記述に欠陥が無ければ、有限回数のＰＤＵのや
り取りで通信が完了するはずである。従って、バースト
転送の様な意図的に複数ＰＤＵを集団転送する処理以外
は、プロトコル仕様記述に欠陥が存在しない場合、発呼
側のエンティティの状態、指示プリミティブに相当する
トリガ、発呼ウインドウパラメータ、着呼側のエンティ
ティの状態、確認プリミティブに相当するトリガ、着呼
ウインドウパラメータをまとめたビット列は、有限回数
内で同じものが出現しないはずである。そこで、ある通
信処理中断時点で、状態管理テーブル9 のビット列から
取り出した発呼側のエンティティの状態、指示プリミテ
ィブに相当するトリガ、発呼ウインドウパラメータ、並
びに着呼側のエンティティの状態、確認プリミティブに
相当するトリガ、着呼ウインドウパラメータをまとめた
ビット列を、状態管理テーブルの全行に渡り遡り、最終
行のビット列と比較する。バースト転送の様な意図的に
複数ＰＤＵを集団転送する処理以外で同じビット列が出
現することはないことから、比較の結果、もし同一のビ
ット列が存在した場合は、通信はエラーとなり処理は停
止出来ないことになる。その様な事態が発生するプロト
コル仕様記述は間違いである。従って、発呼側のエンテ
ィティの状態、指示プリミティブに相当するトリガ、そ
して発呼ウインドウパラメータ、並びに着呼側のエンテ
ィティの状態、確認プリミティブに相当するトリガ、着
呼ウインドウパラメータをまとめたビット列で表現され
たものを全行に渡り、最終行のそれと排他論理和演算す
れば、仕様の停止性に関して検証出来ることになる。

【０１００】バースト転送の様な意図的に複数ＰＤＵを
集団転送する処理を含めて、通信が停止出来ることの判
定計算には、含意演算を組み合わせて用いれば良い。含
意演算とは、命題論理の演算で、命題Ａと命題Ｂが与え
られた場合、「命題Ａならば命題Ｂである。（Ａ→
Ｂ）」という命題の真偽判定を行う演算である。ここ
で、命題Ａが「FAILURE(0)」である場合は、含意演算Ａ
→Ｂは必ず「TRUE(1) 」となり、命題Ｂの真偽に{don't
care}となる。ここで命題Ａは「ＰＤＵの有限回のやり
取りで、同一のものが出現する」を意味する。また命題
Ｂとは「バースト転送の様な意図的に複数ＰＤＵを集団
転送する処理中である」を意味する。その結果、バース
ト転送の様な意図的に複数ＰＤＵを集団転送する処理を
含めて、有限回数のＰＤＵのやり取りで通信が停止出来
ることの判定計算が可能となる。

【０１０１】式(10)は、バースト転送の様な意図的にＰ
ＤＵを繰り返し転送する処理を含めて、有限回数のＰＤ
Ｕのやり取りで通信が停止出来ることの判定計算を行う
式である。これは、式(11)〜式(17)で組み立てられる。

【０１０２】式(11)〜(12)は、停止性の判定式である。
より具体的に言えば、前述命題Ａの「ＰＤＵの有限回の
やり取りで、同一のものが出現する」を意味する。式(1
1)は式(12)から計算される。式(11)式(12)では、一つの
試験シナリオでやり取りされるＰＤＵを全て対象として
いるので、「バースト転送」の部分も含まれることにな
るが、式(12)では「ウインドウパラメータビット列」を
含めているので、バースト転送の場合、式(12)が同一に
なることはない。

【０１０３】式(13)は、バースト転送等、エンティティ
の状態が「定期的に同じもの」になる処理の存在判定式
である。これは式(14)〜式(17)で組み立てられる。

【０１０４】前述のとおり、状態管理テーブル9 中の２
つの「ウインドウパラメータビット列」{Sender_Window
_bits_sequence} と{Receiver_Window_bits_sequence}
は、３つの部分から構成される。第１ビット列部分は
「バースト転送時のＰＤＵ識別子」に該当し、「バース
ト転送」の場合のみ有効である。それに対して、第２ビ
ット列部分は「ＰＤＵの方向性識別子」に該当する。第
３ビット列部分は「繰り返し処理ＰＤＵ識別子」に該当
する。ここで、式(13)の対象となるものは第１ビット列
部分、ならびに第３ビット列部分である。式(13)は、
「意図的なバースト転送中、もしくは意図的な繰り返し
転送中」である場合は、「TRUE(1) 」となり、それ以外
の通常処理では、「FAILURE(0)」となる。

【０１０５】式(14)は、「ウインドウパラメータビット
列」から第３ビット列部分を取出す関数定義式である。
また、式(15)は、「ウインドウパラメータビット列」か
ら第１ビット列部分を取出す関数定義式である。式(16)
および式(17)は定数であり、全ビットが「FAILURE(0)」
となったものである。式(16)は、第３ビット列部分長と
同一のビット長を持ち、式(17)は、第１ビット列部分長
と同一のビット長を持つ。また、式(10)の排他論理和計
算は、試験シナリオ毎に実施され、式(10)中の「LastRo
w 」とは、最後に状態管理テーブル9 に設定した行に相
当する。それ故、式(10)に従えば、バースト転送を含め
た停止性に対するが可能となる。

【０１０６】 Termination_protocol(k)::=exor(Term_bits(j+LastRow),Term_bits(j+k)) (11) Term_bits(x)::={ {Sender_Situation_bits_sequence in Row x}+ {Sender_In<n-1>_Primitive_bits_sequence in Row x}+ {Sender_Out<n-1>_Primitive_bits_sequence in Row x}+ {Sender_Window_bits_sequence in Row x}+ {Structure of{Sender_unmasked_parametor_bits_sequence} i n Row x}+ {Receiver_Situation_bits_sequence in Row x}+ {Receiver_In<n-1>_Primitive_bits_sequence in Row x}+ {Receiver_Out<n-1>_Primitive_bits_sequence in Row x}+ {Receiver_Window_bits_sequence in Row x}+ {Structure of{Receiver_unmasked_parametor_bits_sequence} in Row x} } (x|j+1 ≦ x ≦ LastRow) (12) Local_Loop::={exor(Third(Sender_Window_bits_sequence(LastRow)),ZERO_th ird)∨exor(First(Sender_Window_bits_sequence(LastRow)),ZER O_first)} (13) Function Third : Sender_Window_bits_sequence(x) →Third_part_bits_sequ ence(x) (14) Function First : Sender_Window_bits_sequence(x) →First_part_bits_sequ ence(x) (15) (x|j+1 ≦ x ≦ LastRow) ZERO_third: Sequence of "FAILURE bit(0)" in the same length of bits sequence with Function Third (16) ZERO_first: Sequence of "FAILURE bit(0)" in the same length of bits sequence with Function First (17) ステップ２０）前述検証プロバイダ処理手段5 は、検証
チェッカー処理手段10の停止性エラーイベント61、もし
くは正常終了イベント62を検出した後、イベント内容を
判定してステップ２１、もしくはステップ２２に遷移す
る。このステップを「イベント判定ステップ」と称す
る。

【０１０７】ステップ２１）前述検証プロバイダ処理手
段5 は、正常終了イベント62を検出した場合、前述履歴
管理ファイル8 から次の試験シナリオを選択し、同じ手
順で試験を繰り返すためにステップ１に戻るか、終了す
るためにステップ２４に遷移する。その際、外部イベン
トエラー系シナリオの試験を実施の結果、２つの状態管
理テーブル9が作成され、かつ通信が収束している場合
は、一方の状態管理テーブル9 を削除し、残りの状態管
理テーブル9 のみ存在する様に戻す。このステップを
「正常終了イベント後処理ステップ」と称する。

【０１０８】ステップ２２）前述検証プロバイダ処理手
段5 は、停止性エラーイベント61を検出した場合、内容
を判断の上、起動管理処理手段1 にエラー箇所を引き数
としたエラー通知イベント64を発行し、処理を中断す
る。このステップを「停止性エラーイベント後処理ステ
ップ」と称する。 ステップ２３）検索プロバイダ処理手段5 自身が、完全
性エラーイベント59、健全性エラーイベント63を発行し
たことを認識した場合、検索プロバイダ処理手段5 は、
起動管理処理手段1 に、エラー箇所を引き数としたエラ
ー通信イベント64を発行し、処理を中断する。このステ
ップを「完全性エラーイベント後処理ステップ」と称す
る。

【０１０９】ステップ２４）前述検索プロバイダ処理手
段5 が、前述履歴管理表ファイル8 から次の試験シナリ
オを選択出来ず、総て終了した場合は、トリガ定義表フ
ァイル6 と状態定義表ファイル7 を検索し、式(18)の計
算を行う。式(18)は、トリガ定義表ファイル6 と状態定
義表ファイル7 の全てのレコードが参照されたか、否か
を判定するものである。もし、トリガ定義表ファイル6
と状態定義表ファイル7 の全てのレコードが参照された
場合は、式(18)は「TRUE(1) 」となるので、定義された
要求プリミティブ、指示プリミティブ、応答プリミティ
ブ、確認プリミティブ、外部イベント、並びにエンティ
ティの状態総てが網羅されていることになる。それ故、
網羅性を満足することになる。しかし「FALURE(0) 」の
場合は、網羅性を満たさないので、網羅性エラーイベン
ト65を発行して、処理を終了する。このステップを「網
羅性エラー検査ステップ」と称する。

【発明の効果】以上説明したように、本発明の通信ソフ
トウェア設計検証方式により、第１に、プロトコル仕様
記述を形式記述言語表現で行う故、エンティティの状態
数は無限大迄定義可能である。それ故、コンピュータ間
通信のプロトコル設計の検証が可能になる効果がある。

【０１１０】第２に、各通信機能層毎の機能手順の確認
をすると共に、複数の通信機能層に跨る手順の確認が可
能になる効果がある。

【０１１１】第３に、本発明は、プロトコル仕様記述を
形式記述言語表現で行う故、異常系も記述出来、その結
果予期しない外部イベントが発生した場合にも、停止性
の保証が出来る効果がある。もし異常系の記述が為され
ていない場合は後述の仕様記述の完全性、健全性、並び
に網羅性の検証手続きで検出出来る。

【０１１２】第４に、仕様記述の完全性、健全性、並び
に網羅性の確認が出来る効果がある。あるイベントが発
生した場合に、１つの遷移先、並びに処理手続きが必ず
決められるのが完全性である。また、あるイベントが発
生した場合に、決められる遷移先、並びに処理手続きが
妥当なものであることを保証するのが健全性である。ま
た、仕様記述に記載されたことが、必ず発生することが
網羅性である。

【０１１３】第５に、通信は複数の有限状態遷移機械間
で為されると見做し得るが、検証チェッカー処理手段の
処理手続き中に、排他論理和演算、並びに含意演算が施
されることにより、停止性の検証を行うことが出来る効
果がある。

【０１１４】その他にも、自動的に検証出来る適用範囲
が広がったことで、プロトコル仕様記述に含まれる誤り
の検出に掛かる時間、労力を更に削減出来る効果もあ
る。

【図面の簡単な説明】

【図１】本発明の通信ソフトウェア設計検証方式の基本
原理を示す説明図である。

【図２】本発明の通信ソフトウェア設計検証方式の一つ
の実施形態のブロック図である。

【図３】本発明の通信ソフトウェア設計検証方式で採用
する形式記述言語による仕様記述入力例を示す図であ
る。

【図４】本発明の通信ソフトウェア設計検証方式の一実
施例を示すフローチャートである。

【図５】図４の後半に続くフローチャートである。

【図６】本発明の通信ソフトウェア設計検証方式で採用
する試験シナリオの内容例を示す図である。

【図７】図６の後半に続く試験シナリオの内容例を示す
図である。

【図８】従来の通信ソフトウェア設計検証装置を示すブ
ロック図である。

【符号の説明】

１ 起動管理処理手段 ２ プロトコル仕様記述エディタ処理手段 ３ プロトコル仕様記述ファイル ４ プロトコル仕様記述コンパイラ処理手段 ５ 検証プロバイダ処理手段 ６ トリガ定義表ファイル ７ 状態定義表ファイル ８ 履歴管理表ファイル ９ 状態管理テーブル １０ 検証チェッカー処理手段 ５０ プロトコル仕様記述エディタ処理手段起動要求 ５１ エディタ起動要求イベント ５２ 仕様記述入力 ５３ ファイル保存要求 ５４ プロトコル仕様記述コンパイラ起動要求 ５５ コンパイラ起動要求イベント ５６ 処理終了のイベント ５７ 検証開始要求 ５８ プロバイダ起動要求イベント ５９ 完全性エラー発生イベント ６０ 検証チェッカー処理手段起動イベント ６１ 停止性エラーイベント ６２ 正常終了イベント ６３ 健全性エラーイベント ６４ エラー通知イベント ６５ 網羅性エラーイベント ７０ エンティティ状態数 ７２ プリミティブ数 ７３ 各プリミティブ内のパラメータ ７４ トリガデータビット列 ７５ 状態データビット列 ７６ 参照 ６０１ 読み込み処理手段 ６０２ 状態記述変換処理手段 ６０３ トリガ記述変換処理手段 ６０４ 演算処理手段 ６０５ 誤り検出処理手段 ６０６ 記述要素 ６０７ 遷移トリガ ６０８ 通信中状態パラメータ ６０９ 遷移手順パラメータ ６１０ 結果

Claims (8)

【特許請求の範囲】
1. 【請求項１】 通信ソフトウェア設計検証方式におい
   て、エンティティの状態並びにトリガに応じて決まる該
   エンティティの次動作内容をすべて定義したトリガ定義
   表ファイルと、前記エンティティの状態並びに前記トリ
   ガに応じて決まる該エンティティの遷移先次状態をすべ
   て定義した状態定義表ファイルと、前記トリガ定義表フ
   ァイルおよび前記状態定義表ファイルの内容に基き前記
   エンティティの状態遷移と該状態遷移に応じた前記トリ
   ガの発生を繰返すことにより通信ソフトウェアの設計の
   検証を行う検証プロバイダ処理手段を備えたことを特徴
   とする通信ソフトウェア設計検証方式。
2. 【請求項２】 前記トリガ及び前記エンティティの状態
   により決まる試験シナリオが記された履歴表管理ファイ
   ルを予め具備し、前記検証プロバイダ処理手段は前記通
   信ソフトウェアの設計検証における前記トリガ及び前記
   エンティティの状態に対応する前記試験シナリオに指定
   された前記トリガを発生させることにより前記通信ソフ
   トウェアの設計検証を行うことを特徴とする請求項１記
   載の通信ソフトウェア設計検証方式。
3. 【請求項３】 前記検証プロバイダ処理手段は、発呼側
   から着呼側を経由して再び該発呼側に戻るまでの遷移に
   おける該発呼側および該着呼側の前記エンティティの状
   態および該エンティティの状態に対応して発生される前
   記トリガの組が、前記遷移終了までに２組以上発生して
   いれば前記通信ソフトウェアは停止性エラーを有するも
   のとすることを特徴とする請求項１および請求項２記載
   の通信ソフトウェア設計検証方式。
4. 【請求項４】 前記検証プロバイダ処理手段は、前記発
   呼側および前記着呼側の前記エンティティの状態および
   該エンティティの状態に対応して発生される前記トリガ
   の組が前記遷移終了までに２組以上発生していても前記
   発呼側および前記着呼側間でのバースト転送である場合
   は、前記通信ソフトウェアは前記停止性エラーを有しな
   いとすることを特徴とする請求項３記載の通信ソフトウ
   ェア設計検証方式。
5. 【請求項５】 前記試験シナリオには、エラートリガを
   発生させるためのシナリオを含むことを特徴とする請求
   項２記載の通信ソフトウェア設計検証方式。
6. 【請求項６】 前記検証プロバイダ処理手段は前記トリ
   ガ定義表ファイルに前記エンティティの次動作内容が一
   意に定義されていない場合または前記状態定義表ファイ
   ルに前記エンティティの遷移先次状態が一意に定義され
   ていない場合は前記通信ソフトウェアの設計内容をエラ
   ーとすることを特徴とする請求項１記載の通信ソフトウ
   ェア設計検証方式。
7. 【請求項７】 前記検証プロバイダ処理手段は前記発呼
   側および前記着呼側の前記エンティティの状態および該
   エンティティの状態に対応して発生される前記トリガの
   組をビット表現し、前記遷移における任意の該組と該組
   の以前の全ての該組のビット表現と排他論理割演算を行
   い、該演算の結果に０の場合があれば前記通信ソフトウ
   ェアは停止性エラーを有するものとすることを特徴とす
   る請求項３記載の通信ソフトウェア設計検証方式。
8. 【請求項８】 前記検証プロバイダ処理手段は前記通信
   ソフトウェアの設計検証時に前記トリガ定義表ファイル
   における前記エンティティの次動作内容および前記状態
   定義表ファイルにおける前記エンティティの遷移先次状
   態で参照されていないものがあれば前記通信ソフトウェ
   アは網羅性エラーを有するものとすることを特徴とする
   請求項１記載の通信ソフトウェア設計検証方式。