JPH11213031A - ソフトウェアにおけるハードウェアの検証、およびその逆の検証 - Google Patents

Abstract

(57)【要約】 【課題】 本発明は、ハードウェアおよびソフトウェア
の設計の検証に関する。 【解決手段】 静的半順序換算と記号的検証を利用する
方法と装置によって、ハードウェアおよびソフトウェア
の両方を含む設計の検証が可能になる。システムは適切
な方法でハードウェア中心言語およびソフトウェア中心
言語で記載され、特性が同時に検証される。各特性はハ
ードウェア中心かソフトウェア中心かが特定される。わ
ずかしかソフトウェアを含まないハードウェア中心特性
は静的半順序換算を利用しない。ソフトウェア中心特性
と、多くの量のソフトウェアを有するハードウェア中心
特性は静的半順序換算を利用する。半順序換算の後、ソ
フトウェア中心言語の仕様は同期形式に変換され、ハー
ドウェア中心仕様と結合される。結合された仕様は、Ｃ
ＯＳＰＡＮのような記号的検証ツールに適用され、結果
が表示される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ハードウェアおよ
びソフトウェアの設計の検証に関する。 ＜関連出願の参照＞本出願は、１９９７年１１月３日付
けの米国仮特許出願第６０／０６４，０８０号の恩典を
請求する。本出願はまた、同じ発明者による同じ日付け
の「静的半順序換算」と題された第２の出願に関連す
る。

【０００２】

【従来の技術、及び、発明が解決しようとする課題】ハ
ードウェア／ソフトウェアの相互設計の１つの側面とし
てハードウェア／ソフトウェア・インタフェースにおけ
る検証の取り扱いがある。ハードウェアおよびソフトウ
ェアが別個に設計される通常の場合、一般的な問題は各
設計グループの予想が他方のインプリメンテーションと
一致しないことである。これは、ハードウェアおよびソ
フトウェアが広範に対話し、各部分が他の部分の挙動を
制御する状況では特にそうである。こうしたインタフェ
ースが適切に処理されない場合、論理的な障害につなが
ることが多く、費用のかかる製造の遅延を伴う。ハード
ウェアおよびソフトウェアは他方の概略的な理解だけで
それぞれうまく設計できるというありふれた仮定は、複
雑なシステムでは保証されていない。各設計チームに
は、他方の設計によって定義される「環境」の厳密な記
述が必要である。この必要を満たすためにハードウェア
設計とソフトウェア設計の形式モデルが使用される場
合、インタフェース不整合の問題が、形式環境記述の場
合における設計の開発方法の問題に移行する。

【０００３】概念的には、形式的検証がこの問題の解決
法を提供しうる。しかし、この場合にモデル検査を適用
することは、各側が個々に実現可能な検証の限度知覚に
あることが多いため、ほとんど実現不可能である。さら
に、メモリに依存しているため無限状態システムとして
みられることの多いソフトウェアに有限状態検証を適用
することはそれ自体困難である。

【０００４】ハードウェア／ソフトウェアの相互設計は
方法論の観点から広範に扱われてきたが、形式的相互検
証に関しては実行可能な方法は発表されていない。相互
検証の問題は主として試験の問題として扱われており、
ハードウェアでソフトウェアを試験する、またはその逆
の多数の市販のツールが出現した。

【０００５】上記とは別に、半順序換算と記号状態空間
探索が広く適用され、モデル検査に固有の複雑さを扱っ
てきた。通常、これらの技術は、互換性がないと見られ
るため、どちらか１つだけ別個に適用される。文献に見
られる半順序換算アルゴリズムは、本質的に深さ優先探
索の場合における明示状態列挙法に基づいている。従来
技術に見られる半順序換算は、状態を列挙する過程で動
的に導出される。記号検証は、それぞれのブール関数に
よって定義される状態の集合だけを扱う。状態到達可能
性は、状態空間の幅優先探索を実現する単調状態集合演
算子の収束によって表現される。

【０００６】この場合で半順序換算を問題のあるものに
しているのは、状態空間探索の過程で延期される（すな
わち望ましい換算を引き起こす）ある遷移が無期限には
延期されない（不完全な探索に帰結する）ということを
保証することに関連がある。明示状態列挙法でこのこと
が実現される通常の方法は、深さ優先探索中の何れかの
サイクルを閉じる過程でこの遅延遷移をすべて探査する
ことである。

【０００７】それにもかかわらず、半順序換算と記号検
証を結合できないという本質的な理由はない。この結合
のおそらく最初に発表された提案が、「記号状態空間探
査における半順序換算」、コンピュータ支援検証に関す
る会議（ＣＡＶ ９７）、ＬＮＣＳ １２５４、Ｓｐｒ
ｉｎｇｅｒ−Ｖｅｒｌａｇ、（１９９７）３４０〜３５
１ページで、Ｒ．Ａｌｕｒ、Ｒ．Ｋ．Ｂｒａｙｔｏｎ、
Ｔ．Ａ．Ｈｅｎｚｉｎｇｅｒ、Ｓ．Ｑａｄｅｅｒおよび
Ｓ．Ｋ．Ｒａｊａｍａｎｉによって提示されている。こ
の論文では、サイクルを閉じる条件は記号幅優先探索の
過程でいくつかの追加ステップによって置換され、これ
らの追加ステップは標準的なモデル検査アルゴリズムの
変更を必要とする。

【０００８】

【課題を解決するための手段】ハードウェア／ソフトウ
ェア相互検証の障害は、既存のモデル検査アルゴリズム
の変更を必要とせずに半順序閑散と記号検証を利用する
方法によって克服される。すなわち、ハードウェアはハ
ードウェア中心言語によって記載され、ソフトウェアは
ソフトウェア中心言語によって記載され、２つの仕様
が、２つの言語によって動作する１つの設計検証ツール
に適用される。機能的には、相互設計は、検証すべき特
性を特定し、各特性を個別に検証することによって検証
される。各特性を検証する際、特性の挙動に影響する構
成要素だけが、システムのハードウェアおよびソフトウ
ェア部分で検討される。検証過程では、静的半順序換算
が利用され、検討する必要のあるソフトウェア状態を特
定し、他のソフトウェア状態を無視できるようにする。
開示される静的半順序換算はモデル検査アルゴリズムか
ら完全に分離されているので、特定の探索技術に依存し
ない。

【０００９】非同期ソフトウェア・モデルの半順序換算
を同期ハードウェア・モデルと互換性のあるものにする
ために、非同期モデルは同等の同期モデルに変換され、
半順序換算はオートマタによって定義される制約によっ
て実現される。こうしたオートマタはコンパイル時間に
よって定義される。同期変換は非決定性を使用して非同
期性をシミュレートし、制約は半順序換算に関して冗長
な遷移を除去する。すなわち、半順序換算全体の明示的
形態が、検証ツールを修正する必要なしに、コンパイラ
によって静的に生成される。

【００１０】例示としては、ソフトウェア・モデルはＳ
ＤＬ言語を利用する。ハードウェアはＶＨＤＬまたはＶ
ｅｒｉｌｏｇの合成可能下位集合で表現される。２つの
モデルはインタフェースを通じて協調するが、その各々
は、ソフトウェア側に対してはＳＤＬ処理と見られ、ハ
ードウェア側に対してはＨＤＬモジュールとして見られ
る。ソフトウェアとハードウェアのモデルはどちらもそ
の後検証ツールに適用される。例示としては、検証ツー
ルＣＯＳＰＡＮが利用され、ソフトウェアとハードウェ
アのモデルはどちらも、ＣＯＳＰＡＮの入力言語である
Ｓ／Ｒに事前コンパイルされる。換算モデルは同期モデ
ルと同じ方法でＣＯＳＰＡＮによって検査される。

【００１１】

【発明の実施の形態】抽象挙動設計モデルから始まる設
計方法論を考えることができるだろう。このモデルはハ
ードウェアをソフトウェアと区別しなくともよい。区別
する場合、それは統辞論的に反映される必要や、アーキ
テクチャ的に明らかである必要はなく、おそらく注釈と
してだけ現れる。こうした統一抽象挙動モデルは公式に
検証された後公式に（検証可能な方法で）改良され、ハ
ードウェアおよびソフトウェアの構成要素を分離する。
改良の検証によって抽象設計モデルで検証された特性が
ハードウェアおよびソフトウェアのインプリメンテーシ
ョン・モデルの調整された挙動によって継承され、改良
の際これらの特性をさらに検査する必要を軽減する。

【００１２】こうしたアプローチの利点は、現在合成可
能なレベルで行われている機能的検証が抽象挙動レベル
で行われ、設計モデルがより簡単になることである。こ
れは検証処理の助けになるだけでなく、設計誤りを固定
するために変更しなければならない制約が少ないため、
機能的デバッグ自体を単純化し促進する。設計開発のこ
の早い段階で、検証が使用され、予備的アーキテクチャ
の論理的弱点にスポットを当てることによってアーキテ
クチャ設計の進展をサポートする。さらに、設計サイク
ルの早い段階のデバッグをサポートすることは設計開発
全体を加速する周知の方法である。それと対照的に、従
来の設計方法論は通常、合成可能モデルが完成したより
後の段階でだけ試験および機能的デバッグをサポートす
る。すなわち、連続的な改良設計開発方法論が設計過程
を加速し、かつより信頼性の高い設計を行う。

【００１３】しかし、少なくとも当面は、ハードウェア
およびソフトウェアは抽象化の異なったレベルで見ら
れ、概念的に設計の異なった態様を含むので、それらを
それぞれの適用業務に合わせた異なった言語で表すこと
は不自然ではない。すなわち、ハードウェアはハードウ
ェア中心の形式言語で表すことができ、同様にソフトウ
ェアはソフトウェア中心の形式言語で表すことができ、
両方の言語を受け入れることのできる検証ツールに２つ
のシステムの定義を適用することができる。しかし、必
要なのは適切な言語を利用することであり、修正の必要
なしに既存の検証ツールの何れか１つを利用することが
望ましい。

【００１４】ハードウェア記述言語の選択は、現在の用
途によって決定される面が強い。すなわち、ＶＨＤＬま
たはＶｅｒｉｌｏｇの使用が有利である。これらの言語
は使用の際形式記述技術より低レベルプログラミング言
語に近いが、より構造的な構成体の知覚されたサポート
と同様、合成からそれらに準拠する強力な意味論がそれ
らをより適切な形式記述言語にしている。

【００１５】ハードウェアの場合と異なって、ソフトウ
ェアには広く受け入れられた形式記述言語はない。ソフ
トウェア・プロジェクトの規模がその管理を次第に困難
にするにつれて、ソフトウェア開発で形式言語や形式的
検証を使用する価値が理解されるようになった。企業が
設計した形式言語やツールもあれば、国際標準化によっ
て推進される言語もあった。 ＩＴＵ−Ｔ（かつてのＣ
ＣＩＴＴ）の標準言語である仕様記述言語（ＳＤＬ）
は、これらの言語の中で最も有望なものの１つである。
これはＩＴＵ−Ｔによって定期的にアップデートされ、
すでにソフトウェア・プロジェクトの中でいくつかの用
途を見いだしている。従って、本発明の第１商業的実施
形態は現在定義されているＳＤＬの利用を見込んでいる
が、ここで開示される原理に適合する装置の成功した実
施形態にとって、ＶＨＤＬまたはＶｅｒｉｌｏｇの使
用、またはＳＤＬの使用が義務づけられるわけでも、必
要なわけでもないということを理解されたい。

【００１６】ハードウェア／ソフトウェアの設計が検証
されると、システムのＳＤＬ記述が形式文書化として機
能し、ソフトウェアの開発段階で使用され、ＶＨＤＬが
使用されてハードウェアを合成する。形式的検証のサポ
ートによって、改良が抽象ＳＤＬモデルに対して検査さ
れ、Ｈ．Ｈａｒｄｉｎ、Ｚ．Ｈａｒ’ＥｌおよびＲ．
Ｐ．Ｋｕｒｓｈａｎ、「ＣＯＳＰＡＮ」、コンピュータ
支援検証に関する会議（ＣＡＶ ９６）、ＬＮＣＳ １
１０２、Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ、（１９９６
年）、４２３〜４２７ページによって説明されているＣ
ＯＳＰＡＮのような何らかの検証ツールによって生成さ
れるＣコードの助けによって自動的に合成される。ＣＯ
ＳＰＡＮは、Ｌｕｃｅｎｔ Ｔｅｃｈｎｏｌｏｇｉｅｓ
によってライセンス供与され、ＣＯＳＰＡＮを利用する
機器はＣａｄｅｎｃｅ Ｄｅｓｉｇｎ Ｓｙｓｔｅｍ
ｓ，Ｉｎｃ．からライセンス供与される。

【００１７】ＳＤＬの利用はさらに、ＳＤＬをＳ／Ｒに
変換するコンパイラが存在するという利点を有するが、
後者はＣＯＳＰＡＮの本来の言語である。このコンパイ
ラもＬｕｃｅｎｔ Ｔｅｃｈｎｏｌｏｇｉｅｓからライ
センスされる。ＶＨＤＬからＳ／Ｒへの変換器は、Ｃａ
ｄａｎｃｅ Ｄｅｓｉｇｎ Ｓｙｓｔｅｍｓ，Ｉｎｃ．
から、ＦｏｒｍａｌＣｈｅｃｋ^TMと呼ばれるツールの一
部として入手可能である。

【００１８】ハードウェアおよびソフトウェアのインタ
フェースはＳＤＬでも記述できるが、「ＳＤＬとＣＯＳ
ＰＡＮを使用する検証可能なソフトウェア／ハードウェ
アの相互設計」、システム設計における応用形式方法に
関する国際ワークショップＣＯＳＴ ２４７会報、Ｍａ
ｒｉｂｏｒ、Ｓｌｏｖｅｎｉａ、１９９８年、６〜１６
ページでＶ．Ｌｅｖｉｎ、Ｅ．Ｂｏｕｎｉｍｏｖａ、
Ｏ．ＢａｓｂｕｇｏｇｌｕおよびＫ．Ｉｎａｎによって
説明されているように、意味論のわずかな修正を伴う。
本質において、それはインタフェース処理がハードウェ
ア部分から（組合せ）信号を読み出しおよび書き込みで
きるようにする。ソフトウェア処理および他のインタフ
ェース処理とのインタフェース処理の協調は、ＳＤＬの
通信機構、すなわちバッファとの信号交換によって完全
に処理される。従って、インタフェース処理は、ソフト
ウェア部分の視点から別のソフトウェア処理のように見
える。インタフェース処理は、ハードウェアの同期的な
形でインタフェース変数と呼ばれる共用変数を使用して
ハードウェアと対話する。従って、それはシステムのハ
ードウェア部分には別のハードウェア・モジュールのよ
うに見える。相互設計システムのハードウェア、ソフト
ウェアおよびインタフェース部分はＳ／Ｒに変換され
る。これによって異なった性質の異なった部分を有する
完全な相互設計システムが可能になり、１つの同期シス
テムとして扱われる。

【００１９】我々は相互設計システムにおける２つの種
類の広域遷移を区別する。１つのＳＤＬ処理の遷移はソ
フトウェア遷移と呼ばれる。もう１つの種類の広域遷移
はハードウェア遷移と呼ばれる。ハードウェアは同期的
性質を有するので、ハードウェア遷移は同期ハードウェ
ア構成要素におけるすべてのハードウェア・モジュール
の同時遷移に対応する。インタフェース処理は両方の種
類の遷移を有しうる。インタフェース変数が参照される
インタフェース処理の遷移はハードウェア遷移とみなさ
れる。さもなければ、それはソフトウェア遷移とみなさ
れる。ハードウェアおよびソフトウェアについて異なっ
た抽象レベルが使用されうるので、ソフトウェアとハー
ドウェアの相対速度に関する仮定は行わない。

【００２０】上記で示したように、ハードウェアはハー
ドウェア中心の形式言語で表すことができ、同様にソフ
トウェアはソフトウェア中心の形式言語で表すことがで
き、両方の言語を受け入れることのできる検証ツールに
２つのシステムの定義を適用することができる。しか
し、実質的な設計を扱う場合それは十分ではない。純粋
にハードウェアまたは純粋にソフトウェアのシステムの
従来の検証もすでに複雑さを扱う大きな問題に直面して
いる。ハードウェアおよびソフトウェアのシステムが一
緒に検討される場合のはるかに大きな複雑さを扱えるよ
うにするため、さらに新しいアプローチがなされる。す
なわち、検証すべきソフトウェア／ハードウェアのシス
テムが検証を必要とする特性によって表され、検証され
る各特性がソフトウェア中心（主としてシステムのソフ
トウェア部分に関する）またはハードウェア中心（主と
してシステムのハードウェア部分に関する）として特定
される。その後特性の検証がこの特定に従って進められ
る。

【００２１】図１はシステムのソフトウェア中心の図を
示す。この図では、ソフトウェア・モジュール１０〜１
３は互いに通信する処理であり、各処理は関連するハー
ドウェア要素または下位システムと何らかの対話を有す
る。これらの対話はソフトウェア／ハードウェア・イン
タフェースを通じて実行される。すなわち、図１では、
ソフトウェア処理１０がソフトウェア／ハードウェア・
インタフェース２０を通じてハードウェア要素３０とイ
ンタフェースを有することが示され、ソフトウェア処理
１１がソフトウェア／ハードウェア・インタフェース２
１を通じてハードウェア要素３１とインタフェースを有
することが示され、ソフトウェア処理１２がソフトウェ
ア／ハードウェア・インタフェース２２を通じてハード
ウェア要素３２とインタフェースを有することが示さ
れ、ソフトウェア処理１３がソフトウェア／ハードウェ
ア・インタフェース２３を通じてハードウェア要素３２
とインタフェースを有することが示される。円によって
表されるソフトウェア・システムは純粋なＳＤＬシステ
ムを形成し、すべての処理は非同期的に協調する。イン
タフェース処理はハードウェア構成要素と共にこのＳＤ
Ｌシステムの環境を形成する。従って、環境の概念はＳ
ＤＬシステムの挙動に制約を加える構造的世界となる。
ソフトウェア中心アプローチの目的はソフトウェア特性
の検証であるので、ハードウェア部分は通常、引用によ
って本明細書の記載に援用する、「調整処理の計算機支
援検証：オートマタ理論的アプローチ」、Ｐｒｉｎｃｅ
ｔｏｎＵｎｉｖ．ＰｒｅｓｓでＲ．Ｐ．Ｋｕｒｓｈａｎ
によって説明されているローカライズ換算を通じて自動
的に抽象化の高いレベルに換算される。ハードウェア部
分の役割は、その検証を通じてソフトウェア部分を十分
に制約することである。

【００２２】図２は、システムのハードウェア中心の図
を示す。この図では、ハードウェア構成要素と下位シス
テムが互いに相互接続され、各構成要素またはシステム
もソフトウェア・モジュールと通信する。この通信はハ
ードウェア／ソフトウェア・インタフェースを通じて実
行される。すなわち、図２では、ハードウェア下位シス
テム３４はインタフェース要素２４を通じてソフトウェ
ア処理１４と通信し、ハードウェア下位システム３５は
インタフェース要素２５を通じてソフトウェア処理１５
と通信し、ハードウェア下位システム３６はインタフェ
ース要素２６を通じてソフトウェア処理１６と通信し、
ハードウェア下位システム３７はインタフェース要素２
７を通じてソフトウェア処理１７と通信する。ＳＤＬシ
ステムとして表される各処理は１つのインタフェース処
理だけを有する。対になるソフトウェア中心の図と異な
って、ハードウェア中心の図では、同じ下位システムの
一部であるハードウェア・モジュールだけが一時に検討
される。言い換えれば、ソフトウェアを通じて互いに間
接的にだけ結合される２つかそれ以上の異なったハード
ウェア・システムを含む装置では、検証問題は２つかそ
れ以上の個別の検証問題を含むものとして扱われる。す
なわち、図２の破線の四角形２００の中で、すべてのモ
ジュールは同期的に協調する。より大きなシステムに他
のハードウェア構成要素がある場合、それらは別個のハ
ードウェア中心モデルで扱われなければならない。イン
タフェース処理は純ＳＤＬシステムと共にハードウェア
部分のための環境を形成し、ハードウェアの１次入力へ
の制約を確立する。

【００２３】完全なシステムは必ずしも明確にハードウ
ェア中心またはソフトウェア中心として示されるもので
ないことが認識されるべきである。従って、ここで開示
される原理の１つによれば、検証されるシステムはシス
テムを特徴付ける特性の各集合について別個に扱われ
る。その論点は、システムは、すべての望ましい特性に
ついて適切に検証される場合、意図されたように動作す
るということである。

【００２４】図３は、おそらく非常に複雑な方法で対話
するソフトウェアとハードウェアの要素を有するシステ
ム１００を示す。ここでもシステムはソフトウェア部分
１１０とハードウェア部分１２０を含むと考えることが
できる。上記で示すように、検証すべき特定の特性につ
いて、システムのある部分は無関係である。これは図３
で、閉じた曲線１３１の内外の範囲によって示される。
閉じた曲線１３１の内側の範囲は対象となる特定の特性
に包含されるシステム要素を取り囲んでいたのに対し、
閉じた曲線１３１の外側の範囲は、特定の特性を検証す
る処理に参加せず、従ってその処理の中で考慮する必要
のないシステム要素に対応する。閉じた曲線１３１によ
って特定される対象となる特定の特性は、システムの大
部分のソフトウェア要素、すなわち、処理と、システム
の少数のハードウェア要素すなわち構成要素または下位
システムを包含することを留意されたい。従って、有利
にも、この特定の特性はとりわけソフトウェア中心であ
ると考えられる。図に示すように試験される必要のある
図３のシステムの別の特性は閉じた曲線１３２の中のシ
ステム要素によって包含され、その特性は大部分ハード
ウェア要素を含む。従って、この特性はとりわけハード
ウェア中心であると考えられる。

【００２５】他の可能性を示すために、閉じた曲線１３
３および１３４は、あるソフトウェア処理を共有する２
つのソフトウェア中心特性を示す。それらはハードウェ
ア・インタフェースの一部も共有している。

【００２６】要約すると、本開示によれば、システムの
検証は検証すべき特性の集合によって定義される。各特
性は、ソフトウェア中心言語で表された協調するソフト
ウェア処理と、ハードウェア中心言語で表された対話す
るハードウェア構成要素を含む。各特性は個別に検証さ
れる。各特性の検証は試験される特性の動作に参加する
システム要素だけを包含するので、検証の複雑さを低減
する（すなわち、計算の負担を低減する）。

【００２７】これは図４の流れ図で示されるが、そこで
は検証すべきシステムの特性がブロック２０１で特定さ
れ、検証すべき特性がブロック２０２で選択され、その
特性に含まれるシステム要素がブロック２０３で特定さ
れる。処理は特性が検証されるブロック２０４に進み、
検証が肯定的な場合、制御はブロック２０２に戻って別
の特性を検証する。さもなければ、制御はブロック２０
５に進み、そこで設計またはブロック２０３で利用され
た仮定の一部が修正され、別の検証試行のためにブロッ
ク２０４に戻る。

【００２８】ブロック２０４の動作を詳細に説明する
と、特性はソフトウェア中心またはハードウェア中心と
して特定される。図に示すように、これは特定を行い特
性をソフトウェア中心またはハードウェア中心であると
指定するユーザによって行われる。しかし、特性がソフ
トウェア中心であるかハードウェア中心であるかとは無
関係に、特性がソフトウェア部分とハードウェア部分の
両方を有したという予想は２つの問題を提起する。１つ
は設計の記号検証を利用したいということであり、もう
１つは検証ソフトウェアが大きな計算上の問題を示すこ
とである。

【００２９】これらの問題は、ソフトウェアによって表
されるグラフを換算する修正静的半順序換算を利用し
て、ソフトウェアを同期モデルにコンパイルし、ハード
ウェア部分とソフトウェア部分の表示を共通言語表示に
結合し、結合された表示を記号検証ツールに適用するこ
とによって取り組まれる。

【００３０】特性のソフトウェア部分で静的半順序換算
を行う際、ソフトウェアおよびハードウェア部分のイン
タフェースでシステムの挙動に関するある仮定を行うこ
とは有用であるが、それはこうした仮定が計算の複雑さ
と必要な計算の量を低減するからである。例えば、ソフ
トウェア・モジュールへの特定の入力がある選択された
状態でフリーズすると仮定することによって、モジュー
ルに含まれるコードのかなりの部分が無関係になる。こ
うした仮定を行うことは、ハードウェアが信号をソフト
ウェアに供給するある時点でシステムの接続を断ち、代
わりに外部信号を供給することと同等である。もちろ
ん、これはソフトウェアのある挙動に影響し、それがハ
ードウェアに影響し、特に通常特定の入力に適用される
信号を生成するハードウェア部分に影響することがあ
る。従って、検証処理の一部はハードウェアが特定の入
力で選択された状態を生じる検証を必要とする。この検
証が失敗する場合、ユーザは２つの選択肢に直面する。
すなわち、仮定された入力条件について検証を行うよう
設計を修正するか、または入力に関するより弱い仮定が
許容できるか評価することである。後者が選択される場
合、より弱い仮定がなされ検証が繰り返される。すなわ
ち、相互設計が安定する前に、検証の若干の反復が必要
である。

【００３１】状態到達可能性の間に動的に換算を実現す
る半順序換算技術の従来の実施形態と異なって、修正さ
れた実現の際に必要なのは、対になるハードウェア部分
の同期的性質と互換性を有し、到達可能性分析に記号的
に適用できるようなアルゴリズムである。このため半順
序換算を、記号的探索と互換性を有する方法で静的に
（コンパイル時間中に）実現できる方法が必要になる。

【００３２】半順序換算が、換算されないシステムの遷
移関係への制約として見られるという考え方から出発す
ると、こうした制約はＣＯＳＰＡＮの根底にあるオート
マタ−理論的基礎と互換性のあるオートマトンとして同
期的に表されることが発見された。さらに、ＣＯＳＰＡ
Ｎは許容されていないトレースの探査を防止する方法で
安全制約を有効に実現する。さらに、上記で論じられた
サイクルの閉じた条件を実現するために、ＣＯＳＰＡＮ
の中心的なアルゴリズムを増加する必要があることが最
初に考えられたが、これを避ける方法が発見されたこと
は明らかに大きな利点である。その代わり、サイクルの
閉じた条件は同様に静的に定義された制約オートマトン
として実現される。

【００３３】ＳＤＬ仕様を対になるハードウェア部分の
同期的性質と互換性のあるものにするために、半順序換
算の結果として生じたＳＤＬ仕様は同等の同期仕様に変
換される。これは、引用によって本明細書の記載に援用
する、「同期モデルによる非同期性のモデル化」、コン
ピュータ支援検証に関する会議（ＣＡＶ ９５）、ＬＮ
ＣＳ ９３９、Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ、（１
９９５年）、３３９〜３５２ページ、Ｒ．Ｐ．Ｋｕｒｓ
ｈａｎ、Ｍ．Ｍｅｒｒｉｔｔ、Ａ．ＯｒｄａおよびＳ．
Ｓａｃｈｓで説明されているように、非同期性をシミュ
レートする非決定性を使用して達成される。静的半換算
と同期形式への変換は、前に言及したように、Ｌｕｃｅ
ｎｔ Ｔｅｃｈｎｏｌｏｇｉｅｓによってライセンス供
与されるＳＤＬコンパイラに組み込まれている。

【００３４】ハードウェア中心検証が使用され、主とし
て相互設計のハードウェア側に関する特性が試験され
る。この特性に関連して、図２に示されるシステムのハ
ードウェア中心の図のソフトウェア・モジュールは、ハ
ードウェアを通じてだけ協調する別個のＳＤＬシステム
に対応する。ソフトウェア中心システムの場合と同様、
半順序換算と後続のローカライズ換算が適用される。し
かし、ハードウェア中心検証に伴うソフトウェア側が少
ない場合、ローカライズ換算だけで十分であり、半順序
換算アルゴリズムと後続のローカライズ換算アルゴリズ
ムを実行するよりも高速である。

【００３５】図５は、図４の流れ図をより詳細に説明す
る流れ図を示す。ブロック４０１を実行する前に、検証
すべきシステムのソフトウェア部分に関する仕様が、例
えばＳＤＬ言語で得られ、検証すべきシステムのハード
ウェア部分に関する仕様が、例えばＶＨＤＬ言語で得ら
れ、検証すべき特性の集合がハードウェア中心またはソ
フトウェア中心の特性と共に得られ、システムの挙動に
関する仮定が提供され、システムの初期制約を形成す
る。各特性に参加するシステム要素はこれらの仕様の一
部として含まれる。ブロック４０１は検証すべき特性を
選択し、特性に参加するシステム構成要素を特定して制
御をブロック４０２に進めるが、ここでは検証すべき特
性に関連するシステムの挙動に関する仮定が検索され
る。制御は決定ブロック４０４に進み、試験される特性
がハードウェア中心かソフトウェア中心かが判断され
る。ブロック４０４の判断に基づいて、制御はブロック
４０５かブロック４０６に進む。検証すべき特性がハー
ドウェア中心の場合、ブロック４０５はこの特性のソフ
トウェア部分が半順序換算を行うに値するほど大きいか
を判断する。大きいと判断された場合、制御はブロック
４０６に進む。さもなければ、制御はブロック４０７に
進む。ブロック４０６は検査される特性に関連する制約
を利用し、静的半順序換算を行い、結果として生じた状
態空間グラフを同期形式に変換し、それをハードウェア
部分と共に同期システムと互換性のある何らかの選択さ
れた言語にコンパイルする。図に示すように、これは検
証ツールＣＯＳＰＡＮの本来の言語であるＳ／Ｒであ
る。ブロック４０７は、ソフトウェア部分に対して半順
序換算を行わない点以外は同じことをする。ブロック４
０６および４０７の結果はブロック４０８に適用され、
そこでやはり試験される特性に関連する制約を利用する
ローカライズ換算が行われ、その後検証が行われるブロ
ック４０９に進む。検証結果は決定ブロック４１０に適
用され、そこで検証が成功したか否かが判断される。検
証が成功しない場合、検証処理を制御するユーザに情報
が提供される（ブロック４１１）。ユーザは別の検証を
試みるか否かを決定する。試みる場合、ユーザは仮定を
変更する（一般に弱くする）か、設計を変更し、制御を
ブロック４０４に戻す。特性が検証されると、制御はブ
ロック４０３に進み、検証の必要のある特性が残ってい
るかが評価され、残っている場合、制御はブロック４０
１に戻る。さもなければ、処理は終了する。

【００３６】図６はソフトウェア／ハードウェア設計を
検証するハードウェア装置の機能図を示す。直線５０１
は、ＶＨＤＬのようなハードウェア中心言語の、検証す
べきシステムのハードウェア部分の仕様を提供するが、
これは要素３０１に保存される。直線５０２は、ＳＤＬ
のようなソフトウェア中心言語の検証すべきシステムの
ソフトウェア部分の仕様を提供するが、これは要素３０
２に保存される。制御装置３０４は直線５０３のユーザ
入力に応答するが、これらの入力の一部は、システムの
様々な特性に関連する、検証すべきシステムの挙動に関
する仮定またはそれに対する制約である。検証すべき特
定の特性を選択すると、制御装置３０４は要素３０２か
らの関連するＳＤＬ仕様、要素３０１からの関連するＶ
ＨＤＬ仕様および制約を検索し、それらを要素３０３に
適用する。要素３０３は上記で説明したブロック４０６
および４０７の機能を行い、結果として生じた仕様を要
素３０５に送信するが、これはローカライズ換算を行
い、その出力を形式的検証ツールである要素３０６に提
供する。形式的検証ツールがＣＯＳＰＡＮである場合、
要素３０３は好適にはＳ／Ｒの出力を生じ、要素３０５
と３０６は（ＣＯＳＰＡＮはローカライズ換算を含むた
め）結合される。

【００３７】要素３０６は提示された仕様の検証を行
い、設計が検証されたことを確認するか、または失敗を
表示し、特性が失敗であり、正しく動作するものとして
検証することができない状況または条件を特定する出力
を提供する。この出力は有利にもＶＣＤのような標準化
形式で提供され、検証後ユーザ表示ツール３０７に適用
される。図に示すように、ツール３０７は、Ｌｕｃｅｎ
ｔ Ｔｅｃｈｎｏｌｏｇｉｅｓから入手可能なＯＤＡＮ
モジュールである。

【００３８】もちろん、熟練した当業者は、図６の様々
な処理要素によって行われる機能は、付随的メモリおよ
び制御要素を有する適切なプロセッサによって実現でき
ることを認識するだろう。

【００３９】＜静的半順序換算＞半順序換算技術に関し
ては広範な文献がある。例えば、Ｐ．Ｇｏｄｅｆｒｏｉ
ｄおよびＰ．Ｗｏｌｐｅｒ、「モデル検査への半順序ア
プローチ」、コンピュータ・サイエンスにおける論理に
関する第６回年次米国電気電子通信学会シンポジウム、
１９９１年、アムステルダム、４０８〜４１５ページ、
Ｄ．Ｐｅｌｅｄ、「半順序換算とオンザフライ・モデル
検査の結合」、システム設計Ｕにおける形式的方法（１
９９６年）、３９〜６４ページおよび、Ａ．Ｖａｌｍａ
ｕｉ、「換算状態空間生成のためのｓｔｕｂｂｏｒｎ集
合」、ペトリ・ネットの応用と理論に関する第１０回国
際会議、ボン、ドイツ、ＬＮＣＳ ４８３、Ｓｐｒｉｎ
ｇｅｒ−Ｖｅｒｌａｇ、（１９８９年）、４９１〜５１
５ページを参照されたい。半順序換算は、一般に、イン
タリーブされた事象の意味論との協調のモデルにおい
て、すべての可能な順序で事象を実行することによって
平行する事象がモデル化されるという観測を活用する。
換算は、元のシステムの状態と遷移の下位集合だけを含
む検査されたシステムの表示を生じる異なった順序の中
でこのシステムの特性は区別できないという事実を活用
する。この表示は換算されないモデルの商であり、特性
に関する換算されないモデルと同等である。換算状態グ
ラフの経路である、この商における挙動の下位集合は検
査された特性の保存だけを必要とする。すなわち、モデ
ル検査アルゴリズムは、換算状態グラフに適用される場
合、特性が保持される時は正の応答に帰結し、保持され
ない時は逆の例に帰結する。

【００４０】例えば、上記の刊行物の中でＰｅｌｅｄに
よって提起されるアプローチはアンプル（十分な）集合
法を利用する。この方法では、モデル化されたシステム
の各状態について、次に実行される、またはイネーブル
な（原子）遷移の集合が存在する。これらはイネーブル
（ｓ）として表される。簡単なモデル検査アルゴリズム
が、通常深さまたは幅優先探索である探索を行うことに
よって試験されるプログラムの状態グラフを構成する。
探索は初期状態から開始され、イネーブルな遷移を適用
することによってすぐ次の状態を探査し、また次の状態
を探査するというように進められる。探索戦略は次の状
態が探索される順序によって互いに異なっている。

【００４１】所与の状態ｓから、半順序換算はイネーブ
ルな遷移の下位集合である集合アンプル（ｓ）だけを探
査する。こうしたアンプル集合は、結果として生じる商
において検査された特性の保存を保証するいくつかの条
件を強制するように選択される。すべての状態は検査さ
れた特性の公式に現れる原子命題のある下位集合によっ
てラベル付けされ、Ｌ（ｓ）がｓに保持される命題の集
合を示すと仮定する。

【００４２】アンプル（ｓ）を選択するために使用する
条件を提示する前に、２つかそれ以上の概念が定義され
る。第１の概念は、１組の遷移は、任意の状態ｓから開
始する１つを実行しその後別のものを実行することが実
行の順序と無関係に同じ次の状態ｓ’に帰結する場合独
立であると言われることである。さらに、それらの最初
の１つがイネーブルならば、２番目のものを実行した
後、最初の１つはイネーブルのままである。第２の概念
は見えない遷移というものである。遷移が実行される際
状態ラベルが変化しない場合、それは見えない遷移であ
る。すなわち、状態ｓとｓ’の各組合せについて、ｓか
らｓ’に見えない遷移が実行されるならば、ラベルは同
じまま、すなわちＬ（ｓ）＝Ｌ（ｓ’）である。

【００４３】ここで、所与の特性を保存する半順序換算
に帰結する集合アンプル（ｓ）の十分な条件が与えられ
る。これらの条件の説明とそれらが所与の特性を保存す
る換算状態グラフを保証するという証明は、上記のＰｅ
ｌｅｄの刊行物に見られる。アンプル（ｓ）＝イネーブ
ル（ｓ）、すなわちすべての遷移が選択される場合、状
態ｓは完全に展開されたと言われる。 ・Ｃ０：［空のない条件］イネーブル（ｓ）が空の場
合、かつその場合のみ、アンプル（ｓ）は空である。 ・Ｃ１：［アンプル分解］状態ｓから始まるシステムの
すべての挙動について、アンプル（ｓ）中のある遷移に
依存する遷移が、アンプル（ｓ）からの遷移の前に（換
算されないモデルに）現れない。 ・Ｃ２：［見えない条件］ｓが完全に展開されない場
合、その中の遷移はどれも見えない。 ・Ｃ３：［サイクルの閉じる条件］換算状態グラフの各
サイクルに沿った少なくとも１つの状態が完全に展開さ
れる。

【００４４】これらの条件を実現する最初のモデル検査
システムはＳＰＩＮであったが、これは「形式的検証の
改善」、形式記述技術に関する第７回国際会議、ベル
ン、スイス、１９９４年、１７７〜１９４ページで、
Ｇ．Ｊ．ＨｏｌｚｍａｎｎおよびＤ．Ｐｅｌｅｄによっ
て説明されている。これらの条件を保証するために、Ｓ
ＰＩＮの探索機構が換算のために変更され特殊化され
た。条件Ｃ０およびＣ２の検査は自明である。Ｃ０はロ
ーカル統辞論的検査であり、Ｃ２は設計に対して統辞論
的に課される適用範囲規則を通じて保証される。条件Ｃ
１は現行状態ｓでイネーブルな遷移に対する検査の集合
に変換可能である。例えば、ある処理がその現行プログ
ラム・カウンタから、広域変数またはメッセージの交換
を含まないローカル遷移だけを実行できる場合、この遷
移の集合は条件Ｃ１を満たすことが保証される。条件Ｃ
３は、選択されたアンプル集合がサイクルを閉じたか
（深さ優先探索ではこれはすでに探索スタックにある状
態に到達している場合に起こる）を検査することによっ
て処理される。その場合、現在選択されたアンプル集合
は代わりの選択を優先して廃棄される。

【００４５】ＳＤＬからＳ／Ｒに変換するコンパイラを
作成する際、半順序換算を使用することが望ましいが、
すでに論じたように、目標によってはＳＰＩＮで使用さ
れるものと異なったソリューションを命じるものが多数
存在する。特に、記号状態空間探索を使用できるように
するために、深さ優先探索の使用に依存しない換算アル
ゴリズムを使用することが望まれた。

【００４６】次に説明される換算は、モデル検査アルゴ
リズムの一切の修正なしに、同期モデルのための何らか
のモデル検査アルゴリズムと共に使用できるというさら
なる利点を有する。さらに、この新しい半順序換算アル
ゴリズムは非常に一般的で、利用される状態空間探索の
モードの影響を受けない。

【００４７】幅優先探索で換算を実現する際の主な障害
は、完全に展開される状態がないサイクルの可能性を回
避する必要があることである。一見して、条件Ｃ３は、
これを幅優先探索で達成するにはモデル検査アルゴリズ
ムのかなりの変更が必要であることを示唆している。実
際には、我々はこれが、モデル検査アルゴリズムの修正
なしに、非常に簡単かつ一般的に達成されることを発見
した。

【００４８】原則として、このアルゴリズムは、上記の
論文のＨｏｌｔｚｍａｎｎおよびＰｅｌｅｄ、または上
記のＬＮＣＳ １２５４刊行物のＡｌｕｒ他によって説
明されたものと少なくとも同程度に良好な（到達した状
態によって測定された）換算を生じることができるべき
であるが、記号分析によっては、到達した状態の数は複
雑さの乏しい測定である。さらに、換算の大きさと換算
を生じるコストの間との兼ね合いが存在するが、これら
も一般にアルゴリズムを通じて比較することが困難であ
る。

【００４９】改善された半順序換算アルゴリズムによれ
ば、Ｃ３条件は次の条件によって置換される。 ・Ｃ３’：換算された状態空間中の各サイクルがＴから
の少なくとも１つの遷移を含むような遷移の集合Ｔが存
在する。アンプル（ｓ）がＴからの遷移を含む場合、ｓ
は完全に展開される。遷移の集合Ｔは、ある意味で、す
べての他のイネーブルな遷移に粘着するため、粘着性遷
移と呼ばれる。

【００５０】こうした集合Ｔを発見する容易な方法は、
検査されるシステムの各処理の静的制御流れグラフを見
ることである。広域状態空間中の何らかのサイクルが各
構成要素処理中のサイクル（または自己ループのことも
ある）に投影される。各ローカル・サイクルを断つこと
によって、各広域サイクルも確実に断たれる。これは以
下のように上記の条件Ｃ３がさらに確実に保証されるこ
とを示唆する。すなわち、 ・Ｃ３”：モデル化されたシステムの処理の静的制御流
れにおける各サイクルが少なくとも１つの粘着性遷移を
含み、アンプル（ｓ）が粘着性遷移を含む場合、ｓは完
全に展開される。

【００５１】状態Ｃ３”は、（小さい）成分の処理に対
して静的分析アルゴリズムを使用し、それぞれの成分処
理の各々から広域状態空間に上昇した粘着性遷移Ｔの集
合を発見することによって満足される。最小粘着性集合
がＮＰ困難であることが発見されても（これは静的制御
流れグラフにサイクルが残らなくなるまで遷移（粘着性
のもの）を除去することと同じである）、小さく、あま
り大きな広域状態グラフでないローカル制御流れグラフ
のサイズではＮＰ困難である。さらに、最小Ｔを発見す
る必要はない。ローカル制御グラフ中に粘着性遷移の集
合を発見する１つの方法は、深さ優先探索の過程にある
すべてのバックエッジ、すなわち、現在探索されている
状態から現在探索スタックにある状態へのエッジを選択
することである。結果として生じるＴは各ローカル・バ
ックエッジの上昇である。ローカル制御グラフは小さい
ので、コンパイル時間に、知覚できるコストなしに探索
できる（統辞論的遷移はいずれもローカル制御グラフの
エッジにあると仮定される。この発見的方法は多くの満
足されない遷移によって損なわれることがあるが、それ
は一般的でなく、処理は小さいだけでなく、遷移の疎集
合を有するものとして見られる）。

【００５２】粘着性でない遷移に優先が与えられること
に留意されたい。粘着性遷移は延期されるが、少なくと
も１つの粘着性遷移を通過せずに閉じられるサイクルは
ない。異なった処理から上昇した粘着性遷移によって、
広域サイクルに１つより多い完全に展開した状態が含ま
れることはあり得る。しかし、粘着性遷移は優先が低
く、変換アルゴリズムは他の遷移を最初に選択しようと
するので、それらのいくつかをそれらが同じ状態から得
られる時点まで延期することは意味がある。これは粘着
性遷移の展開はサイクル中いつでも起こり得るため可能
である。

【００５３】実際には、条件Ｃ３”は次のように弱めら
れる。すべてのメッセージ待ち行列は最後には空にな
り、送信メッセージ（「送信」イベント）の中にはサイ
クルを閉じる必要があるものがあるため、換算された状
態グラフ中のサイクルは受信メッセージだけからなるこ
とはできない。すなわち、メッセージ受信だけを伴うロ
ーカル制御流れサイクルは粘着性遷移を含む必要はな
い。それは広域状態グラフ中のサイクルから投影された
別のサイクルの一部分でなければならない（これは送信
メッセージについても言えることであり、待ち行列は最
後には満たされる。同じ緩和法が同時に送信と受信のメ
ッセージに許容される場合、それらは互いの影響を打ち
消し、広域状態グラフ・サイクルの一部になりうる）。
この観測は各処理の制御グラフのサイズにおいて直線的
なアルゴリズムの設計に使用される。処理の制御グラフ
から受信遷移を除去した後、残りの遷移に対して線形時
間探索が行われ、バックエッジを特定し、それらを粘着
性遷移としてマークする。

【００５４】さらに条件Ｃ３”を緩和する多数の方法が
ある。１つはユーザにある程度さらに粘着性遷移をマー
クさせることである。これは、上記で開示されたよう
に、すべてのバックエッジを選択することから生じるよ
り多くの任意割当てを減少させる。もう１つの方法はい
くつかの処理を結合した後バックエッジ分析を行うこと
で、大きな構造のサイクルだけを切断する必要がある。

【００５５】ＣＯＳＰＡＮにおいて探索制御と無関係な
半順序換算を達成するためにＳ／Ｒの選択機構が利用さ
れる。この機構は選択変数の使用からなる。この変数は
組合せ的で、状態の一部ではないので、メモリ・オーバ
ヘッドを招くことはない。後続状態を決定する際、各処
理はその選択変数のいくつかの可能な数値の中で非決定
論的に選択する。処理の選択は（この関係が非周期的で
ある限り）他の処理の選択に依存する。すなわち、アン
プル（ｓ）のサイズは、できる限り小さいアンプル
（ｓ）集合、すなわち最小数のイネーブルな遷移を有す
る処理を選択することによって発見的に最適化される。

【００５６】処理の各ローカル状態において、現在イネ
ーブルな遷移が条件Ｃ１を満たすかが判断される。満た
す場合、処理はこの状態でアンプルであると結論され
る。これを決定する１つの方法は以下の通りである。イ
ネーブルな粘着性遷移を有さず、そのすべてのイネーブ
ルな遷移が受信または内部遷移である場合、処理はある
状態でアンプルであると考えられる。処理が内部遷移だ
けを有する場合（ローカル変数だけが参照される遷
移）、他の処理はローカル変数を参照しないので、処理
のイネーブルな遷移がＣ１を満たすことが明らかであ
る。同様に、処理が受信遷移だけを有する場合、処理の
イネーブルな遷移はやはりＣ１を満たす。他の処理の送
信遷移が受信遷移の読み取り元である同じメッセージ待
ち行列を変更することがあるが、それらの実行順序は重
要でない。問題は、多数の処理が場合によってはアンプ
ル集合であるイネーブルな遷移を有することである。す
べての集合を選択することは、選択される遷移を最小に
するという目標と相反する。実際には、この問題を解決
する選択機構が使用される。処理がアンプルである場
合、広域選択変数を使用して他の処理にこの事実につい
て知らせることができる。多数の処理が同時にアンプル
である場合、静的（インデックス番号）優先を通じてそ
れらの１つを選択することができる。他のアンプル処理
は、選択変数を通じて、それらはアンプル集合を提供す
る選択された候補者でなく、この集合への遷移に貢献し
ないことを知らされる。

【００５７】上記が本発明の原理を開示したことと、様
々な修正と変更が、以下の請求項で定義される、本発明
の精神および範囲から逸脱することなく他の実施形態に
組み込まれることを理解されたい。

【図面の簡単な説明】

【図１】ソフトウェアとハードウェア両方の部分を有す
るシステムのソフトウェア中心の図を示す図である。

【図２】ソフトウェアとハードウェア両方の部分を有す
るシステムのハードウェア中心の図を示す図である。

【図３】ソフトウェアとハードウェア両方の構成要素を
有するシステムのある特性が大部分のハードウェアまた
は大部分のソフトウェアを含むことを示す図である。

【図４】ソフトウェアとハードウェア両方の部分を有す
るシステムの設計検証処理の流れ図を示す図である。

【図５】ソフトウェアとハードウェア両方の部分を有す
る検証過程のより詳細な流れ図である。

【図６】ソフトウェアとハードウェア両方の部分を有す
るシステムの設計検証を行う装置の機能図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ヴラッドミール レヴィン アメリカ合衆国 ニュージャーシィ，ニュ ープロヴィデンス，セントラル アヴェニ ュー 449 (72)発明者 マリウス ミネア アメリカ合衆国 ペンシルヴァニア，ピッ ツバーグ，エルスワース アヴェニュー 5807 (72)発明者 ドロン エー． ペレド アメリカ合衆国 ニュージャーシィ，ギレ ット，サンライズ ドライヴ 109 (72)発明者 ハスヌ エニガン アメリカ合衆国 ニュージャーシィ，ダネ レン，マウンテン ヴュー テラス 413

Claims (27)

【特許請求の範囲】
1. 【請求項１】 ソフトウェアとハードウェア両方の部分
   を有するシステムの設計を検証する方法であって、 ソフトウェア中心言語の前記ソフトウェアの第１仕様の
   入力を受け入れるステップと、 前記第１仕様のサイズを換算するために半順序換算を行
   うステップと、 前記第１仕様を同期形式に変換するステップと、 ハードウェア中心言語の前記ハードウェア部分の第２仕
   様の入力を受け入れるステップと、 前記換算された第１仕様と前記変換された第１仕様によ
   って表される設計を検証するステップと、 前記検証ステップの結果を提示するステップとを含む方
   法。
2. 【請求項２】 請求項１に記載の方法において、前記検
   証ステップが、 前記検証ツールが前記ソフトウェア中心言語で提示され
   た入力に対して動作できない場合、前記変換された第１
   仕様を検証ツールの仕様言語に変換するステップと、 前記検証ツールが前記ハードウェア中心言語で提示され
   た入力に対して動作できない場合、前記第２仕様を前記
   検証ツールの仕様言語に変換するステップとを含む方
   法。
3. 【請求項３】 請求項１に記載の方法において、前記半
   順序換算が静的半順序換算である方法。
4. 【請求項４】 請求項１に記載の方法において、結果を
   提示する前記ステップが、前記設計が予想されたように
   動作することを示す確認的出力を提示するステップか、
   またはシステムがある特定の組合せの状況の下では動作
   できないことを示す逆の例を提示するステップを含む方
   法。
5. 【請求項５】 請求項１に記載の方法において、前記検
   証ツールがＣＯＳＰＡＮであり、前記第１仕様を変換す
   る前記ステップが前記第１仕様をＳ／Ｒ仕様言語に変換
   する方法。
6. 【請求項６】 請求項１に記載の方法において、前記検
   証ツールがＣＯＳＰＡＮであり、前記第２仕様を変換す
   る前記ステップが前記第２仕様をＳ／Ｒ仕様言語に変換
   する方法。
7. 【請求項７】 請求項１に記載の方法において、前記第
   １仕様がＳＤＬ仕様言語で書かれている方法。
8. 【請求項８】 請求項１に記載の方法において、前記第
   ２仕様がＶＨＤＬまたはＶｅｒｉｌｏｇ仕様言語で書か
   れている方法。
9. 【請求項９】 請求項１に記載の方法において、前記検
   証ステップが前記システムを特徴付ける特性の集合を含
   む方法。
10. 【請求項１０】 ソフトウェアとハードウェア両方の部
    分を有するシステムの設計を検証する方法であって、 記憶装置に、ソフトウェア中心言語の前記ソフトウェア
    部分の仕様、ハードウェア中心言語の前記ハードウェア
    部分の仕様、前記システムが処理される特性の仕様およ
    び制約の初期集合の入力を受け入れるステップと、 検証すべき特性を選択するステップと、 前記選択された特性を検証するステップと、 前記検証ステップが失敗する場合、前記失敗を表示し、
    前記制約および／または仕様に対する修正を提供する機
    会を提供するステップと、 前記修正を受け入れるステップと、 前記検証ステップに戻るステップと、 前記検証ステップが成功する場合、検証すべき別の特性
    を選択するステップとを含む方法。
11. 【請求項１１】 請求項１０に記載の方法において、前
    記ソフトウェア部分の前記仕様とハードウェア中心言語
    の前記ハードウェア部分の前記仕様が仕様の収集を含
    み、その各々が前記特性の特定の１つに関連する前記シ
    ステムの要素の仕様を表す方法。
12. 【請求項１２】 請求項１０に記載の方法において、前
    記検証ステップが、 前記記憶装置から、前記選択された特性に属するハード
    ウェア仕様とソフトウェア仕様部分を検索するステップ
    と、 前記検索されたソフトウェア仕様部分を同期形式に変換
    するステップと、 前記検証ツールが前記ソフトウェア中心言語で提示され
    た入力に対して動作できない場合、前記変換された仕様
    を検証ツールの仕様言語に変換するステップと、 前記検証ツールが前記ハードウェア中心言語で提示され
    た入力に対して動作できない場合、前記検索されたハー
    ドウェア仕様部分を前記検証ツールの仕様言語に変換す
    るステップとを含む方法。
13. 【請求項１３】 請求項１２に記載の方法において、前
    記検証ステップがさらにローカライズ換算を行うステッ
    プを含む方法。
14. 【請求項１４】 請求項１２に記載の方法において、前
    記検証ステップがさらに、前記記憶装置から、前記選択
    された特性に関連する制約を検索するステップと、前記
    検索された制約に応答してローカライズ換算を行うステ
    ップとを含む方法。
15. 【請求項１５】 請求項１０に記載の方法において、前
    記検証ステップがさらに、 前記記憶装置から、前記選択された特性に属するハード
    ウェア仕様とソフトウェア仕様の部分を検索するステッ
    プと、 前記選択された特性がハードウェア中心かソフトウェア
    中心かを確認するステップと、 前記選択された特性がソフトウェア中心である場合、前
    記検索されたソフトウェア仕様部分に半順序換算を適用
    するステップと、 前記選択された特性がハードウェア中心であるが、前記
    検索されたソフトウェア仕様部分が予め選択された条件
    に一致する場合、前記検索されたソフトウェア仕様部分
    に半順序換算を適用するステップと、 前記選択された特性がハードウェア中心であり、前記検
    索されたソフトウェア仕様部分が前記予め選択された条
    件に一致しない場合、前記ソフトウェア部分の前記検索
    された仕様を同期形式に変換し、前記選択された特性が
    ソフトウェア中心またはハードウェア中心で、前記検索
    されたソフトウェア仕様部分が前記予め選択された条件
    に一致しない場合、前記半順序換算の結果を同期形式に
    変換するステップと、 前記検証ツールが前記ソフトウェア中心言語で提示され
    た入力に対して動作できない場合、前記変換された仕様
    を検証ツールの仕様言語に変換するステップと、 前記検証ツールが前記ハードウェア中心言語で提示され
    た入力に対して動作できない場合、前記検索されたハー
    ドウェア部分の前記仕様を前記検証ツールの仕様言語に
    変換するステップとを含む方法。
16. 【請求項１６】 請求項１５に記載の方法において、特
    性がハードウェア中心かの前記確認が前記記憶装置に見
    られる情報に基づいてなされる方法。
17. 【請求項１７】 請求項１５に記載の方法において、前
    記半順序換算が静的半順序換算である方法。
18. 【請求項１８】 請求項１５に記載の方法において、前
    記検索ステップが前記選択された特性に関連する制約を
    も検索し、半順序換算を適用する前記ステップが前記検
    索された制約を利用する方法。
19. 【請求項１９】 請求項１５に記載の方法において、前
    記検証ステップがさらにローカライズ換算を行うステッ
    プを含む方法。
20. 【請求項２０】 請求項１９に記載の方法において、前
    記検証ステップがさらに、前記記憶装置から、前記選択
    された特性に関連する制約を検索するステップを含み、
    ローカライズ換算を行うステップが前記検索された制約
    に応答する方法。
21. 【請求項２１】 ソフトウェアを含むシステムの設計を
    検証する方法であって、 前記システムの仕様に対して静的半順序換算を行うステ
    ップと、 前記静的半順序換算の結果を同期形式に変換するステッ
    プと、 前記変換ステップの結果によって表示される設計を検証
    するステップと、 前記検証ステップの視覚的結果を提示するステップとを
    含む方法。
22. 【請求項２２】 請求項２１に記載の方法において、前
    記検証ステップがローカライズ換算とそれに続く記号的
    検証を行う方法。
23. 【請求項２３】 請求項２２に記載の方法において、前
    記記号的検証が状態到達可能性分析を利用する方法。
24. 【請求項２４】 請求項２２に記載の方法において、前
    記記号的検証が記号的状態空間探索を利用する方法。
25. 【請求項２５】 設計を検証する装置であって、 前記設計の仕様、特性の収集および制約を保存するメモ
    リと、 制御装置と、 前記メモリから得られた、前記仕様中のソフトウェアを
    記述する部分に応答して、前記制御装置の制御の元で静
    的半順序換算分析を行う第１プロセッサと、 前記制御装置からの制御信号に応答して、前記仕様中の
    ソフトウェアを記述する部分を同期形式に変換するか、
    または前記第１プロセッサの出力信号を同期形式に変換
    する第２プロセッサと、 前記メモリから得られた前記仕様中のハードウェアを記
    述する部分と、前記第２プロセッサの出力信号に応答す
    る検証ツールと、 前記検証ツールに応答するディスプレイとを含む装置。
26. 【請求項２６】 設計を検証する装置であって、 前記設計の仕様、特性の収集および制約を保存するメモ
    リと、 前記メモリに保存された信号に応答し、前記設計に対す
    る静的半順序換算とそれに続く記号的検証を行う保存プ
    ログラム・プロセッサと、 前記設計が検証されたかを示す前記プロセッサによって
    提供される信号に応答するディスプレイとを含む装置。
27. 【請求項２７】 設計を検証する装置であって、 前記設計の仕様、特性の収集および制約を保存するメモ
    リと、 制御装置と、 前記メモリから得られた前記仕様中のソフトウェアを記
    述する部分に応答して、静的半順序換算分析を行う第１
    手段と、 前記仕様中のソフトウェアを記述する部分を同期形式に
    変換するか、または前記第１プロセッサの出力信号を同
    期形式に変換する第２手段と、 前記メモリから得られた、前記仕様中のハードウェアを
    記述する部分と、前記第２プロセッサの出力信号に応答
    する第３手段と、 前記第１手段、前記第２手段および前記第３手段を制御
    する第４手段と、 前記第３手段に応答するディスプレイとを含む装置。