JPWO2015159501A1 - 検証性質統合装置、検証性質統合方法および検証性質統合プログラム - Google Patents

Abstract

形式仕様記述やモデル検査など、異なる形式手法を用いて検証された製品で結合された製品やシステムを検証可能とする検証性質統合装置、検証性質統合方法および検証性質統合プログラムを提供する。定理証明支援系記述に対して与える形式仕様記述およびモデル検査記述の意味論を定義したライブラリ１３と、ライブラリ１３を用いて、形式仕様記述を定理証明支援系上の表現に変換する第１の定理証明支援系記述生成部１１と、ライブラリ１３を用いて、モデル検査記述におけるモデルおよび時相論理式を定理証明支援系上の表現に変換する第２の定理証明支援系記述生成部１２とを含む。

Description

本発明は、異なる形式手法を用いて検証された製品で結合された製品やシステムを検証することが可能な検証性質統合装置、検証性質統合方法および検証性質統合プログラムに関する。

形式手法は、製品の安全性を検証するために、さまざまな国際規格で要求されている。形式手法を大別すると、形式仕様記述やモデル検査、定理証明などがある。

これらの技術は、それぞれ以下のように用いられる。

形式仕様記述は、製品のふるまいを形式的に定義し、定められた仕様を示す事前条件や不変条件または事後条件を満足するかどうかを数学的に示すことで、正しいふるまいを得る技術である。形式仕様記述は、一般に、誤りの余地がない小さな仕様から記述を開始し、制約を充足することを確認しながら仕様を追加していく。この仕様追加の操作に誤りがない限り、ふるまいの正しさが保証される。以下、形式仕様記述による記述を、単に形式仕様記述と呼ぶ。

モデル検査は、製品の状態遷移モデルを記述し、その状態遷移において不都合な状態への遷移の有無を探索する技術である。探索により、そのような不都合な状態への遷移がないとき、そのモデルは数学的に安全性を担保することが可能である。以下、モデル検査による記述を、モデル検査記述と呼ぶ。

定理証明では、目的のふるまいが数学的に定義される。即ち、定理証明は、ある関数の望ましい性質を、数学的に正しい操作を用いて導出することによって、その性質が成立することを証明する。

形式仕様記述に分類される技術を応用したツールとしては、VDM（登録商標；ＳＣＳＫ株式会社）（非特許文献１参照）やEvent-B（非特許文献２参照）が知られている。モデル検査に分類される技術を応用したツールとしては、SPIN（非特許文献３参照）やUPPAAL（非特許文献４参照）が知られている。定理証明に分類される技術を応用したツールとして、Coq（非特許文献５参照）、Isabelle（非特許文献６参照）、PhoX（非特許文献７参照）が知られている。

特許文献１には、既存のプログラムと比較を行い、類似するプログラムに対して差分を合成する方法が記載されている。一方、本発明では、対象とするものには類似性がない。特許文献１に記載された方法と本発明とは前提が異なるため、特許文献１に記載された方法は、本発明が解決しようとする課題（後述）には有効ではない。

特許文献２には、プログラムを入力とし、そのプログラムの状態遷移図を抽出する方法が記載されている。一方、本発明に含まれる状態遷移の変換においては、入力と出力とはそれぞれ表現方法が異なるものの、状態遷移そのものである。そのため、プログラムから状態遷移図を抽出する特許文献２に記載されている方法は、本発明に寄与しない。

特許文献３には、論理回路に対する自動証明の方法が記載されている。しかし、一般に論理回路を構成する部品と、本発明で取り扱う高階述語論理とは、数学的クラスが異なる。そのため、特許文献３に記載された方法を本発明に適用することはできない。また、本発明は、証明の自動化を目的としているのではなく、異なる形式的（数学的）表現方法から、定理証明支援系における表現に変換することを目的としている。

特許文献４には、プログラミング言語間の変換を取り扱う技術が記載されている。特許文献４に記載された技術は、プログラムを実行可能なデータ構造に変換するときの情報を利用し、プログラムを木構造としてモデル化する。一方、本発明は、形式言語を対象とする。また、形式言語の多くはコンパイルし実行形式に変換可能ではない。本発明と特許文献４に記載された技術とでは、記述からその意味を抽出する方式が異なる。
なお、形式手法に関連した技術が、特許文献５、及び、特許文献６に開示されている。特許文献５は、ソフトウェアのソースコードを複数の異なる変換ルールを用いて、検証ツールの入力言語で記述された検査コードに変換する技術を開示する。特許文献５に開示された技術は、ソースコードをモデル検査可能な形式に変換する技術にすぎない。また、特許文献６は、連続値と離散値とを扱うハイブリッドシステムの動作をプログラミング言語を用いてコーディングすると共に、係るコードを形式手法を用いて検証する技術を開示する。特許文献６に開示された技術は、検証対象の動作を記述したコードを、定理証明器を用いて検証するにすぎない。即ち、特許文献５、及び、特許文献６に開示された技術は、いずれも、後述する本願課題を解決するには不十分である。

特開平５−５３７８０号公報 特開平８−２０２５４０号公報 特開平９−３２５９７５号公報 特表平１０−５０８３９８号公報 特開２０１３−１２０４９１号公報 特開２０１３−００３８９７号公報

"VDMToolsマニュアル"、[online]、[平成２６年４月４日検索]、インターネット＜URL：http://www.vdmtools.jp/＞ "Rodin Handbook"、[online]、[平成２６年４月４日検索]、インターネット＜URL：http://handbook.event-b.org＞ "Basic Spin Manual"、[online]、[平成２６年４月４日検索]、インターネット＜URL：http://spinroot.com/spin/Man/Manual.html/＞ "Formal Methods for Real Time Systems: Automatic Verification & Validation"、1998年10月11日、[online]、[平成２６年４月４日検索]、インターネット＜URL：http://people.cs.aau.dk/~kgl/ARTES/index.htm＞ "The Coq Proof Assistant Reference Manual"、[online]、[平成２６年４月４日検索]、インターネット＜URL：http://coq.inria.fr/distrib/current/refman/＞ "Tutorials and manuals for Isabelle"、[online]、[平成２６年４月４日検索]、インターネット＜URL：https://www.cl.cam.ac.uk/research/hvg/Isabelle/documentation.html＞ "The PhoX Proof Assistant"、[online]、[平成２６年４月４日検索]、インターネット＜URL：http://www.lama.univ-savoie.fr/~RAFFALLI/phox.html＞

形式手法の各技術は、それぞれ異なる理論に基づいていて、またそれぞれ得意とする領域が異なる。そのため、異なる製品には、異なる形式手法を適用して検証を行うことが一般的である。

しかし、これらの技術で検証された性質を別のシステムにおいて取り扱うことを可能とする産業的な着想は、なされてこなかった。製品開発の規模が大きくなれば、既存の製品を組合せて別の製品に組込むという用途が生じる。しかし、既存の製品がそれぞれ異なる形式手法を適用して検証されている場合には、それらを結合した製品やシステムを検証することは困難である。その理由は、既存の製品はそれぞれ相異なる表現で異なる理論に基づいて検証されているためである。例えば、形式仕様記述は集合論、モデル検査は時相論理に基づいている。単一のシステム、方式、装置、システムまたはプログラムでこれらの表現および理論を扱うことが可能な技術は提供されていない。

定理証明支援系は、再帰的型付きラムダ計算を表現することが可能であることから、集合論および時相論理を表現することが原理的には可能である。しかしながら、定理証明支援系では、これらに付随する理論を実装する方法や、変換方法は提供されていない。

また、製品の性質とは、製品の数学的な定義に対する数学的な述語である。そのため、この述語のみを変換するだけでなく、製品の数学的な定義を変換することが、性質をもとに検証を行うためには重要である。

そこで、本発明は、形式仕様記述やモデル検査など、異なる形式手法を用いて検証された製品で結合された製品やシステムを検証可能とする検証性質統合装置、検証性質統合方法および検証性質統合プログラムを提供することを目的とする。

つまり、本発明は、第１に、形式仕様記述を定理証明支援系の上で表現する方法および変換方法を構築することを技術的課題とする。また、本発明は、第２に、モデル検査記述を定理証明支援系の上で表現する方法および変換方法を構築することを技術的課題とする。

本発明の一態様に係る検証性質統合装置は、定理証明支援系記述に対して与える形式仕様記述およびモデル検査記述の意味論を定義したライブラリと、ライブラリを用いて、形式仕様記述を定理証明支援系上の表現に変換する第１の定理証明支援系記述生成手段と、ライブラリを用いて、モデル検査記述におけるモデルおよび時相論理式を定理証明支援系上の表現に変換する第２の定理証明支援系記述生成手段とを含む。

本発明の一態様に係る検証性質統合方法は、定理証明支援系記述に対して与える形式仕様記述およびモデル検査記述の意味論を定義したライブラリを用いて、形式仕様記述を定理証明支援系上の表現に変換し、ライブラリを用いて、モデル検査記述におけるモデルおよび時相論理式を定理証明支援系上の表現に変換することにより、形式仕様記述およびモデル検査記述を用いて定義および検証された性質を定理証明支援系上の記述に変換する。

本発明の一態様に係る検証性質統合プログラムは、コンピュータに、定理証明支援系記述に対して与える形式仕様記述およびモデル検査記述の意味論を定義したライブラリを用いて、形式仕様記述を定理証明支援系上の表現に変換する処理と、ライブラリを用いて、モデル検査記述におけるモデルおよび時相論理式を定理証明支援系上の表現に変換する処理とを実行させる。また、上記本発明の目的は、係る検証性質統合プログラムが格納（記録）された、コンピュータ読み取り可能な記憶媒体によっても実現可能である。

本発明によれば、形式仕様記述やモデル検査など、異なる形式手法を用いて検証された製品で結合された製品やシステムを検証することができる。

図１は、本発明による検証性質統合システムの第１の実施形態の構成を示すブロック図である。 図２は、第１の定理証明支援系記述生成部の動作を示すフローチャートである。 図３は、第２の定理証明支援系記述生成部の動作を示すフローチャートである。 図４は、本発明実施前における、形式仕様記述およびモデル検査記述の相互関係を模式的に示す説明図である。 図５は、本発明実施後における、変換された形式仕様記述と変換されたモデル検査記述の相互関係と結合の定義を模式的に示す説明図である。 図６は、変換前のAxiomsの記述の一例を示す説明図である。 図７は、変換後のAxiomsの記述の一例を示す説明図である。 図８は、変換前のTheoremsの記述の一例を示す説明図である。 図９は、変換後のTheoremsの記述の一例を示す説明図である。 図１０は、Event-Bにおけるモデルの拡張と詳細化の関係を示す説明図である。 図１１は、変換前のMachinesの記述の一例を示す説明図である。 図１２は、変換後のMachinesの記述の一例を示す説明図である。 図１３は、ステップＳ２０５において生成される公理の記述の一例を示す説明図である。 図１４は、変換前のEventsの記述の一例を示す説明図である。 図１５は、変換後のEventsの記述の一例を示す説明図である。 図１６は、変換後のbyteの定義の一例を示す説明図である。 図１７は、変換前の列挙型および配列型の定義の一例を示す説明図である。 図１８は、変換後の列挙型および配列型の定義の一例を示す説明図である。 図１９は、変換前の通信チャネルの定義の一例を示す説明図である。 図２０は、変換後の通信チャネルの定義の一例を示す説明図である。 図２１は、変換前の状態遷移の定義の一例を示す説明図である。 図２２は、変換前のLTL式の定義の一例を示す説明図である。 図２３は、変換後のLTL式の定義の一例を示す説明図である。 図２４は、本発明による検証性質統合装置の最小構成を示すブロック図である。

実施形態１．
以下、本発明の第１の実施形態を図面を参照して説明する。

図１は、本発明による検証性質統合システムの第１の実施形態の構成を示すブロック図である。

検証性質統合システムは、検証性質統合装置１００と、形式仕様記述装置１０１と、モデル検査器１０２とを備える。

検証性質統合装置１００は、形式仕様記述装置１０１から形式仕様記述（具体的には、形式仕様記述により記述された仕様を含む情報）を入力する。

形式仕様記述は、環境定義およびシステム定義から構成される。環境定義は、型定義、定数定義、公理およびモジュール依存性から構成される。システム定義は、詳細化関係、参照、変数、不変条件、操作（イベント）から構成される。

検証性質統合装置１００は、モデル検査器１０２からモデル検査記述（具体的には、モデル検査により記述されたモデルを含む情報）を入力する。

モデル検査記述は、データ型宣言、通信チャネル、状態遷移および検査式から構成される。

検証性質統合装置１００は、図１に示すように、第１の定理証明支援系記述生成部１０３と、第２の定理証明支援系記述生成部１０４と、定理証明支援系１０５と、ライブラリ１０６とを含む。

第１の定理証明支援系記述生成部１０３は、形式仕様記述装置１０１から入力した形式仕様記述を定理証明支援系上の表現に変換する。つまり、第１の定理証明支援系記述生成部１０３は、形式仕様記述から定理証明支援系記述への変換を行う。本実施形態では、第１の定理証明支援系記述生成部１０３により、上記の第１の技術的課題が解決される。

第２の定理証明支援系記述生成部１０４は、モデル検査器１０２から入力したモデル検査記述におけるモデルおよび時相論理式を定理証明支援系の上の表現に変換する。つまり、第２の定理証明支援系記述生成部１０４は、モデル検査記述から定理証明支援系記述への変換を行う。本実施形態では、第２の定理証明支援系記述生成部１０４により、上記の第２の技術的課題が解決される。

定理証明支援系１０５は、第１の定理証明支援系記述生成部１０３および第２の定理証明支援系記述生成部１０４から出力された定理証明支援系記述について、それらの記述の結合を定義し、検証を行う。

ライブラリ１０６は、定理証明支援系１０５に対して証明を支援するためのライブラリである。具体的には、ライブラリ１０６は、形式仕様記述およびモデル検査記述の意味論を定理証明支援系１０５に与え、証明による検査を補助するためのライブラリである。ライブラリ１０６は、検証性質統合装置１００が含む光ディスク装置や磁気ディスク装置、メモリ等の記憶装置（図示せず）に格納される。

なお、第１の定理証明支援系記述生成部１０３および第２の定理証明支援系記述生成部１０４は、例えば、検証性質統合プログラムに従って動作するコンピュータによって実現される。この場合、ＣＰＵ（中央演算装置：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）が検証性質統合プログラムを読み込み、そのプログラムに従って、第１の定理証明支援系記述生成部１０３および第２の定理証明支援系記述生成部１０４として動作する。なお、係る検証性質統合プログラムは、任意の記憶媒体（例えば、光ディスク、半導体記憶装置、磁気ディスク等）に記憶されてもよい。そして、上記ＣＰＵは、例えば係る記憶媒体の読み取り装置等を介して、係る記憶媒体に記憶されたプログラムを読み込んでもよい。また、第１の定理証明支援系記述生成部１０３および第２の定理証明支援系記述生成部１０４が別々のハードウェア（例えば、コンピュータ装置や、論理回路等）により実現されていてもよい。

次に、本実施形態の動作を説明する。

図２は、第１の定理証明支援系記述生成部１０３の動作を示すフローチャートである。

第１の定理証明支援系記述生成部１０３は、入力された形式仕様記述に対して、形式仕様記述の環境定義を定理証明支援系の記述に変換する処理（図２に示すステップＳ１）を実行する。また、第１の定理証明支援系記述生成部１０３は、入力された形式仕様記述に対して、形式仕様記述のシステム定義を定理証明支援系の記述に変換する処理（図２に示すステップＳ２）を実行する。

形式仕様記述の環境定義に対する変換（ステップＳ１）では、第１の定理証明支援系記述生成部１０３は、以下に示すステップＳ２０１〜Ｓ２０４の変換を行う。

まず、第１の定理証明支援系記述生成部１０３は、型定義の変換（ステップＳ２０１）を行う。変換された結果は、定理証明支援系上における単一のモジュール構造であり、そのモジュールの命名には、元の形式仕様記述のプロジェクト（ファイル）名が使用される。形式仕様記述の多くは、一般的なプログラミング言語や、定理証明のような型をもたないため、例えば、変数や参照等は集合の包含関係を用いて表現することが多い。一方で、定理証明の場合には、強い静的型制約を有することが多いため、型定義の生成は重要である。本実施形態では、第１の定理証明支援系記述生成部１０３は、集合の包含関係からグラフを生成し、生成したグラフの構造を維持するように定理証明支援系用の型の定義を生成する。

定数定義の変換（ステップＳ２０２）では、構文に基づく逐語的な変換が可能である。公理の変換（ステップＳ２０３）では、ステップＳ２０１で生成された型の定義に基づいて型の情報を補完することによって、構文上の違いもほぼ解消され、逐語的変換が可能である。モジュールの変換（ステップＳ２０４）は、モジュール依存性を解決する仕組みであり、第１の定理証明支援系記述生成部１０３は、形式仕様記述の環境定義に含まれるモジュール定義を定理証明支援系上のモジュール読み込み文に変換する。

第１の定理証明支援系記述生成部１０３は、拡張モジュールに対してステップＳ１の処理（ステップＳ２０１〜S２０４の処理）を実行してから、ステップＳ２０５の処理に移行する（ステップＳ３）。

形式仕様記述のシステム定義に対する変換（ステップＳ２）では、第１の定理証明支援系記述生成部１０３は、以下に示すステップＳ２０５〜Ｓ２０９の変換を行う。

詳細化関係の変換（ステップＳ２０５）では、第１の定理証明支援系記述生成部１０３は、形式仕様記述のシステム定義に含まれる詳細化関係を、定理証明支援系の表現である、型拡張の記述に変換する。詳細化関係は、形式仕様記述のうち、システム定義に分類される記述である。係る詳細化関係は、既存のシステムに対する変数、参照、不変条件および操作（イベント）の追加を表わす。逆に、詳細化対象のシステムに存在し、詳細化された結果のシステムにこれら全てが定義されない場合には、これは不正な詳細化となり、検証失敗として異常処理される。そのため、定理証明支援系でも同様にこうした異常な詳細化が発生していないことを明確に提示し、脱落を防止する必要があり、型拡張の概念を用いるのが妥当である。

第１の定理証明支援系記述生成部１０３は、詳細化対象に対してステップＳ２の処理（ステップＳ２０５〜Ｓ２０９の処理）を実行してから、ステップＳ２０６の処理に移行する（ステップＳ４）。

形式仕様記述のうち、システム定義に分類される参照とは、存在する変数を操作（イベント）において読み取り、その値を使用することを意味する。一方、定理証明支援系においては、対応する仕組みが存在しないため、参照は、操作（イベント）の引数へ変換される。形式仕様記述における変数や参照は型を有さず、集合の要素として定義される。一方で、定理証明支援系では変数や引数は、厳密に型を有する必要がある。そのため、変数の変換（ステップＳ２０６）および参照の変換（ステップＳ２０７）では、第１の定理証明支援系記述生成部１０３は、集合の包含関係から、その変数または引数の型を決定する計算を行う。

形式仕様記述のうち、システム定義に分類される不変条件とは、操作（イベント）が発生し、それが処理される任意の時点において充足する必要がある制約である。不変条件の変換（ステップＳ２０８）では、第１の定理証明支援系記述生成部１０３は、形式仕様記述のシステム定義に含まれる不変条件を定理証明支援系上の公理に変換する。この変換は、形式仕様記述上で既に検証された性質を、変換後の定理証明支援系上において検証する義務を回避するための処理である。

形式仕様記述のうち、システム定義に分類される操作（イベント）は、ある条件（事前条件）を充足したとき、システムに与える変化（操作）を定義する。操作（イベント）の変換（ステップＳ２０９）では、第１の定理証明支援系記述生成部１０３は、以下のようにこの定義を生成する。一般に操作（イベント）の意味は、操作的意味論により定義されるが、本実施形態では、操作（イベント）を、定理証明支援系上の帰納的な集合および集合に対する帰納的な述語論理として定義する。この述語論理は、操作（イベント）の操作的意味論を定義する。この述語論理は、ある状態Ｘにおいて操作Ｙが発生した結果、状態がＺとなるために成立するための制約を表す。この制約は事前条件および操作を構文についてのみ変換した述語論理である。この変換の作り方そのものは自明であるが、操作的意味論を帰納的な述語論理として定義すると決めるには一定の着想が必要である。この工夫によって、任意の操作（イベント）定義に対応する定理証明支援系上の意味論の表現を生成することができる。

図３は、第２の定理証明支援系記述生成部１０４の動作を示すフローチャートである。第２の定理証明支援系記述生成部１０４は、入力されたモデル検査記述に対して、図３に示す、以下の処理を実行する。即ち、第２の定理証明支援系記述生成部１０４は、データ型宣言の変換（ステップＳ３０１）、通信チャネルの変換（ステップＳ３０２）、状態遷移の変換（ステップＳ３０３）および検査式の変換（ステップＳ３０４）を実行する。これにより、第２の定理証明支援系記述生成部１０４は、モデル検査記述のそれぞれの記述を定理証明支援系上の対応する記述へと変換する。

モデル検査記述のうち、データ型宣言の記述の目的は、プリミティブな型を組合せ、複合データ型を構築することである。構築されたデータ型は、状態遷移および通信チャネルの定義に使用される。このデータ型宣言の変換（ステップＳ３０１）を行うためには、第１に全てのプリミティブ型の変換が可能であり、第２に任意の複合データ型から構築される複合データ型の変換が可能である必要がある。

プリミティブ型の変換には工夫が必要である。一般に定理証明支援系で扱う型は、帰納的に構築された無限のサイズを有する型である。具体的には、そのような型は、例えば、自然数や有理数などである。一方、モデル検査記述では有限サイズの型のみが、使用可能である。具体的には、そのような型は、例えば、３２ｂｉｔ整数値型や文字型、これらの配列などである。プリミティブ型の変換においてはこの違いを考慮する必要がある。なぜなら、有限サイズの型に閉じたモデルの中で成立する性質は、無限のサイズを有する型を許容するモデルでは成立しないことがあり、その逆も考えられるためである。一例として、変数のオーバーフロー時の動作を前提とした性質をオーバーフローが発生しないモデルに適用した場合、この性質は成立しない可能性がある。逆の例として、有限サイズの型で表現できない数値の比較などが考えられる。

以上の理由から、厳密な検証を行うためには、定理証明支援系上に有限サイズの型を構築する必要がある。そのためには、第１にプリミティブな有限の型、演算およびそれらの性質に関する定理を定義したライブラリ、第２に変換を行うための対応ルールが必要である。定理証明支援系において、有限のサイズを有することを必須とする型の定義はその桁数を明示することによって実現される。また、これらの型に関する演算を定義として与え、それら演算の定義に関する定理について証明を与えることで、定理証明支援系における有限サイズの型が実現される。

ただし、有限の型およびその演算を用いる場合には、定理証明支援系上では証明のステップ数が大幅に増加することがある。そのため、本実施形態では、厳密な検証を犠牲にする代わりに、定理証明による検査を容易にするために、第２の定理証明支援系記述生成部１０４は、無限のサイズを有する帰納的な型の使用も可能とする。つまり、データ型宣言の変換（ステップＳ３０１）では、第２の定理証明支援系記述生成部１０４は、利用者の利便性に合せて、定理証明支援系上の変数の型を選択可能とする。

モデル検査記述における任意の複合データ型に対しては、複合データ型を構築する基底のプリミティブなデータ型について、上記の変換が行われる。その複合構造は帰納的データ構造へと変換される。

モデル検査記述では、通信チャネルはイベント通信を表現するために使用される。通信チャネルはバッファを有しており、あるプロセスが対象の通信チャネルに送信を行うと、そのバッファにメッセージが追加される。プロセスが対象の通信チャネルからメッセージを受信すると、このバッファから先頭のメッセージが削除される。このことを定理証明支援系の上で表現するために、通信チャネルの変換（ステップＳ３０２）では、第２の定理証明支援系記述生成部１０４は、通信チャネルの宣言をそれぞれ独立したキュー構造に変換する。

モデル検査では、システムは複数のプロセスから構成され、通信チャネルを用いた協調動作を検査の対象とする。それぞれのプロセスは、動作のシーケンスを用いて定義される。その構文はBNF（バッカス・ナウア記法）を用いて表現することができ、BNFにおける各要素について変換を定義することで、定理証明支援系における表現に変換することが可能である。状態遷移の変換（ステップＳ３０３）では、第２の定理証明支援系記述生成部１０４は、この変換の定義に基づいて変換を行う。

ステップＳ３０３において、第２の定理証明支援系記述生成部１０４は、まずプロセス名を抽出し、プロセス名の集合を構築する。つづいて、第２の定理証明支援系記述生成部１０４は、定義される変数および通信チャネルとその型の情報から、状態の型を構築する。そして、第２の定理証明支援系記述生成部１０４は、プロセスがシーケンスとして定義された動作を、その状態型上の関数として変換する。最後に、第２の定理証明支援系記述生成部１０４は、状態遷移の制約を帰納的な述語論理式に変換する。

モデル検査記述に対してその性質を検査するために、検査式と呼ばれる時相論理式（時相論理に基づいた数式）が用いられる。そのため、検査された性質を定理証明支援系で使用するためには、この数式を変換する必要がある。この変換先の表現には独自のライブラリ（例えば、図１に示すライブラリ１０６）への呼び出しが使用される。検査式は状態空間上での到達可能性を表現する作用素の組合せによって記述されることから、このライブラリは、その意味を定義し証明を支援するために構築される。このライブラリは、各作用素の意味の定義と、作用素の変換を行うための定理を保持する。このライブラリを使用することにより、変換を逐語的に行うことが可能である。検査式の変換（ステップＳ３０４）では、第２の定理証明支援系記述生成部１０４は、このライブラリを使用して定理証明支援系記述への変換を行う。

ライブラリ１０６は、証明を支援するための仕組みである。具体的には、ライブラリ１０６は、形式仕様記述およびモデル検査記述で頻出する性質について、その証明を行う上での利便性を考慮した定理およびその証明を保存している。例えば二重否定の除去についての定理が一般的な論理学で使用されるように、モデル検査では時相論理の作用素間の関係を定める定理などがある。ライブラリ１０６は一般に知られる定理をもとに、定理証明支援系上で検証性質統合装置１００が使用する独自の表現により意味論を定義する。

図４は、本発明実施前における、形式仕様記述４０１とモデル検査記述４０４との相互関係を模式的に示す説明図である。図４に示すように、形式仕様記述４０１はその構文・意味論（形式仕様記述の構文・意味論４０２）に基づいて記述され、その数学的根拠は集合論４０３である。一方で、モデル検査記述４０４はその構文・意味論（モデル検査記述の構文・意味論４０５）に基づいて記述され、その数学的根拠は時相論理４０６である。そのため、形式仕様記述４０１とモデル検査記述４０４の関係は互いに異なる根拠に基づいていることから、その記述の統合を行うための共通理論は存在しない。そのため、形式仕様記述４０１とモデル検査記述４０４とのそれぞれによって検証された製品の結合において、その性質をどちらか、または別の手段に統一する必要があった。

本発明により、形式仕様記述およびモデル検査記述を、定理証明支援系上の記述に変換することができる。図５は、本発明実施後における、変換された形式仕様記述５０１（以下、単に形式仕様記述５０１と呼ぶ）と変換されたモデル検査記述５０２（以下、単にモデル検査記述５０２と呼ぶ）の相互関係と結合の定義５０５を模式的に示す説明図である。形式仕様記述５０１は、入力された形式仕様記述４０１を定理証明支援系上の表現に変換した記述である。モデル検査記述５０２は、入力されたモデル検査記述４０４を定理証明支援系上の表現に変換した記述である。形式仕様記述５０１およびモデル検査記述５０２については、それぞれ定理証明支援系上に意味論（定理証明支援系での構文・意味論５０３）が構築されている。また、形式仕様記述５０１およびモデル検査記述５０２は、これらに対して証明を用いてその性質を検査する場合に利用する定理をまとめたライブラリ（変換された形式仕様記述・モデル検査記述向けライブラリ５０４）の定義に依存する。そのため、本発明の第１の効果は、変換された形式仕様記述およびモデル検査記述について定理証明支援系上で結合を定義し、この結合を検査することが可能となることである。

第２の効果は、既製の製品をより容易に組合せることが可能で、それらを安全に統合することが可能となることである。その理由は、既存の形式仕様記述やモデル検査で検証を行った製品について、再度別の形式手法に基づいて検査する必要がなくなるためである。

また、安全性を定めるための様々な国際標準の中には、形式手法適用の有無、その範囲を審査するものがある。本発明の第３の効果は、定められた安全基準を満足することが容易になるとともに、その審査が容易になることである。その理由は、部品となる既製製品のみ検査し、既製製品を結合した製品やシステムの性質を検査しない場合と比較して、より安全性や信頼性の担保が容易になり、また、その性質の範囲の追跡が可能となるためである。

以上のように、本発明は、既存の形式仕様記述、モデル検査または定理証明により検証されたソフトウェア、システムまたは装置を、結合または組合せて使用するときの性質を検査する用途に適用することができる。

以下、本発明を適用可能な具体例について説明する。
<具体例１>

本具体例では、単一または複数のシステムについての形式仕様記述Event-Bの記述および単一または複数のシステムについてのモデル検査器SPINの記述（Promela言語を用いて記述される）が入力される。そして、それぞれの入力が定理証明支援系Coq（Gallina言語を用いて記述される）上の記述に変換される。

本具体例では、図１における、形式仕様記述装置１０１の出力は、単一または複数のEvent-Bによる記述であり、それぞれが第１の定理証明支援系記述生成部１０３により定理証明支援系記述へと変換される。

各Event-Bの記述は、ContextsおよびMachinesの記述により構成される。Contextsには、Sets、Constants、Axioms、TheoremsおよびExtendsについて定義が記述される。Machinesには、Refines、Sees、Variables、InvariantsおよびEventsについて定義が記述される。

次に、本具体例の動作を説明する。

Contexts（コンテキスト記述ブロック）は、環境について定義を記述する。Contexts内には、１つまたは複数のコンテキスト記述（Context）が含まれる。Contextsに対する変換は、形式仕様記述の環境定義に対する変換（ステップＳ１）に含まれるステップＳ２０１〜Ｓ２０４によって単一のクラス（Class）宣言およびインスタンス（Instance）定義に変換される。Class名、Instance名はそれぞれプロジェクト名に文字列「ContextsType」「Contexts」を付加したものを使用する。Contextsが入力に含まれない場合、第１の定理証明支援系記述生成部１０３は、ステップＳ１の変換をスキップし、ステップＳ２０５から変換を開始する。

Setsは、集合の定義を行う記述ブロックである。第１の定理証明支援系記述生成部１０３は、当該Setsに記述された集合の定義を型定義の変換（ステップＳ２０１）においてCoq上の型定義へと変換する。一例として、Aという定義がSetsに含まれ、Axiomsに“A=Z”という制約があれば、その記述は、Coq上で“Definition A := Z.”へと変換される。すなわち、第１の定理証明支援系記述生成部１０３は、「集合Aが存在し、これが整数の集合である」という記述から、「型Aは整数型である」という記述への変換を行う。

Constantsは、定数の宣言を行う記述ブロックである。第１の定理証明支援系記述生成部１０３は、当該Constantsにおける定数を定数定義の変換（ステップＳ２０２）においてCoq上の定数へと変換する。一例として、Bobという定数が定義され、Axiomsに“Bob∈Person”という制約が含まれていれば、その記述は“Variable Bob: Person.”という記述に変換される。

AxiomsおよびTheoremsは、それぞれ公理と定理を宣言する記述ブロックである。当該記述ブロックには、集合や定数の制約が記述される。第１の定理証明支援系記述生成部１０３は、公理および定理をそれぞれ、公理の変換（ステップＳ２０３）において定理証明支援系上の記述に変換する。Axiomsの一例として、図６に示す記述があれば、第１の定理証明支援系記述生成部１０３は、図７に示す記述へと変換を行う。

Theoremsは定理を宣言する記述ブロックである。Theoremsは、Axiomsと同様に成立するべき性質を記述するが、同時に証明責務を生成する点においてAxiomと異なる。そのため、Axiomと同様の変換が可能である。一例として、図８に示す記述があれば、第１の定理証明支援系記述生成部１０３は、図９に示す記述へと変換を行う。

Extendsは、単一または複数の既存のContextに対する拡張を宣言する記述ブロックである。この記述ブロックに対して、第１の定理証明支援系記述生成部１０３は、モジュールの変換（ステップＳ２０４）において、まずExtends宣言の対象のContextについての変換（ステップＳ１）を実行する。

変換されたContextはClassである。次に、第１の定理証明支援系記述生成部１０３は、そのClassの中身を現在変換対象とするContextのClass定義中にコピーする。続いて、第１の定理証明支援系記述生成部１０３は、Extends宣言対象のInstanceから定義を本Contexts（変換した結果であるCoq側のContexts）のInstanceにコピーする。最後に、第１の定理証明支援系記述生成部１０３は、変換対象のContextのClassから、既存ContextのClassに対する型拡張（Coercion）を生成する。入力が有効なEvent-B記述であれば、上記した型拡張（Coercion）は、Extendsブロックに記述されたContextsに対しては純粋な拡張（既存のContextsが有する要素は全て新規Context）である。これより、入力（Ｅｖｅｎｔ−Ｂ記述）に含まれるＣｏｎｔｅｘｔｓに対して、型拡張（Coercion）を用いてＣｏｑにおけるＣｏｎｔｅｘｔｓを必ず自動的に生成することが可能である。

図１０は、Event-Bにおけるモデルの拡張と詳細化の関係を示す説明図である。図１０に示す下段Contextは、上段のContextに対する拡張を示す。モジュールの変換（ステップＳ２０４）、定数定義の変換（ステップＳ２０２）および公理の変換（ステップＳ２０３）は順序を入れ替えても良い。

Machinesは、対象システムの挙動を定義する記述ブロックである。Machines内には、１つまたは複数のマシン記述（Machine）が含まれる。Machinesは、形式仕様記述のシステム定義に対する変換（ステップＳ２）に含まれるステップＳ２０５〜Ｓ２０９を使用してClassおよびInstanceとして変換される。それぞれの名前には、Machineにつけられた名前に文字列「MachinesType」「Machines」を付加した表記（文字列等）が使用される。

Refinesは、既存のMachineに対する精錬である。精錬とは、既存Machineに制約を付加した記述、または既存Machineの制約を強化した記述である。また、精錬時に導入される新規変数と既存変数と間の関係を定める連結不変条件（gluing invariantと呼ばれる）が成立している必要がある。変換対象がRefines（既存のMachineに対する精錬）であるときには、第２の定理証明支援系記述生成部１０４は、ステップＳ２０５の処理を開始することができないため、ステップＳ２０５の処理を中断し、ステップＳ２０１の処理へジャンプする。そして、第２の定理証明支援系記述生成部１０４は、依存する精錬対象についてステップＳ２０１〜Ｓ２０９を実行したのち、中断していたステップＳ２０５の処理を再開する。再開されたステップＳ２０５の処理において、第２の定理証明支援系記述生成部１０４は、Refinesが既存のMachineに対する精錬であるという事実に加え、精錬が有する性質を適切に形式的に表現するために、RefinesをCoq上のAxiomとして変換する。すなわち、係るAxiomは、イベントそれぞれについて、精錬結果の事前条件が成立するならば、精錬対象のイベントの事前条件が成立する、という公理である。

例えば、図１１に示す既存のMachinesが存在しているとする。

また、図１１に示すMACHINEに対して、図１２に示す精錬があるとする。

このときのgluing invariantは、図１２に示す10〜11行の記述であり、このgluing invariantから図１３に示す公理が生成される。

一方で、既存のイベントに対する精錬は存在しないため、事前条件の強弱関係について生成される公理はない。

Variablesは、Machineが有すべき変数を定義する記述ブロックである。その変換は変数の変換（ステップＳ２０６）を用いて行われるが、技術的にはContextに含まれる定数定義の変換（ステップＳ２０２）と同様の変換である。この変換と、詳細化関係の変換（ステップＳ２０５）とは、順序を入れ替えてもよい。

Seesは、既存のContextに対して参照を行うことを示す記述ブロックである（図１０に示す右向き矢印）。Seesに対する参照の変換（ステップＳ２０７）では、第２の定理証明支援系記述生成部１０４は、対象のContextに対してステップＳ１で生成されたClassおよびInstance記述を、それぞれ生成するMachineに対するClassおよびInstance記述の中に配置する。これにより、対象のMachineは指定されるContext中の記述を参照することが可能となる。

Invariantsは、後述のイベントの実行により破壊されたくない性質を宣言するための記述ブロックである。Invariantsは、不変条件の変換（ステップＳ２０８）によってAxiomに変換される。技術的には、この変換は公理の変換（ステップＳ２０３）と同一であり、定義されるClassが異なる（InvariantsはMachineに対するClass中に配置される）。

Eventsは、Machineに対して実行される操作を定義するための記述ブロックである。Eventsは、操作（イベント）の変換（ステップＳ２０９）によって、Coq上のイベント集合およびイベント集合の要素に与えられる意味論に変換される。イベント集合は、Eventsに含まれるイベント名から構成され、意味論は、イベントの定義から帰納的な述語に変換される。

一例として、図１４に示すような定義があるとする。

この定義で使用するイベントはset_peds_go，set_peds_stop，set_carsの3つである。そのため、第２の定理証明支援系記述生成部１０４は、これらからなる集合と、その意味論を示す述語を図１５に示すように生成する。

図１において、モデル検査器１０２の出力は、単一または複数のSPIN（Promela言語）による記述であり、第２の定理証明支援系記述生成部１０４は、係る記述それぞれを定理証明支援系記述へと変換する。

SPINにおけるシステムは４つの部分から構成される。型定義、通信チャネル定義、プロセス定義に加え、システムの性質を検査するLTL（線形時相論理：Ｌｉｎｅａｒ Ｔｅｍｐｏｒａｌ Ｌｏｇｉｃ）検査式が変換対象である。それぞれの構成要素についての変換は、図３を参照して説明する。

SPINにおける型定義は、データ型宣言の変換（ステップＳ３０１）においてCoq上の型定義に変換される。SPINにおける基底型として、真偽値を保持するbitおよびbool型、8ビット正の整数を示すbyte型、符号付き8ビット整数を示すshort型、符号付き16ビット整数を示すint型を使用することが可能である。これらのデータ型は、データサイズが固定の値を表現する。図１で入力として与えられる数学的厳密性レベルが「高」のとき、第２の定理証明支援系記述生成部１０４は、これらのデータ型に対応するCoq側のデータ型として、それぞれに対応する型を使用する。一方で、低レベルが指定されたときは、第２の定理証明支援系記述生成部１０４は、証明による検査がより容易な、有限でない整数型（Z）を使用する。

数学的厳密性レベルが「高」の場合の一例として、byteを図１６に示すような定義に変換することが可能である。

図１６に示す定義では任意のshort型のデータを表現することができると同時に、任意のshort型の値の範囲の制約を必須とする。その結果として、short型に対する演算の挙動（オーバーフロー等）を定義することが可能である。しかし、short型に対する演算の挙動を定義するためには、演算毎にオーバーフローしないことの根拠を与えるか、オーバーフロー時の場合分けをすることが必要となる。

SPINにおける型にはこの他に列挙型および配列型がある。列挙型は、帰納的な集合に変換される。配列型は、先述の基底型に対する、有限長のリスト構造に変換される。一例として、図１７に示す列挙型および配列型の定義を考える。

図１７に示す記述はそれぞれ図１８に示すように変換される。

SPINによる任意の通信チャネルは図１９に示す構文により定義される。

図１９に示す構文では、nameという名前の通信チャネルを、type型の要素の受け渡しに使用し、そのバッファサイズはsizeであることを意味する。通信チャネルの宣言は、通信チャネルの変換（ステップＳ３０２）においてCoq上の表現（図２０に示す構文）に変換される。

SPINによる状態遷移の定義は、単一または複数のプロセスと、初期化により記述される。プロセスの定義は、図２１に示すように、プロセス名、パラメータ、命令の列により構成される。

状態遷移の変換（ステップＳ３０３）では、まず、第２の定理証明支援系記述生成部１０４は、各プロセス定義から、各プロセスの命令位置を示す有向グラフを生成する。有向グラフの辺には命令が記述される。次に、第２の定理証明支援系記述生成部１０４は、パラメータおよびローカル変数を抽出し、抽出したパラメータおよびローカル変数から構成されるレコード型を定義する。このレコード型のインスタンスと、有向グラフ上のプロセスの命令位置の組が、このプロセスの状態を示す。

各命令は、代入（算術演算の有無を問わない）、選択、反復、無条件ジャンプおよびメッセージ送受信から構成される。これらのうち、選択、反復、無条件ジャンプおよびメッセージ受信は、プロセスの有向グラフの構造として抽出される。そのため、第２の定理証明支援系記述生成部１０４は、代入とメッセージ送信の意味論のみを定義すればよい。ローカル変数への代入はプロセスの状態の変化として、レコード上の値の書き換えと、命令位置を進める意味を有する。グローバル変数への代入およびメッセージ送信は、次に述べるシステム全体の状態を変化させる。

システム全体の状態は、各プロセスの状態とグローバル変数の値およびチャネルの状態の組から構成される。グローバル変数への代入およびメッセージ送信は、それぞれグローバル変数、チャネルの状態の書き換えを行うと同時に、プロセス上の命令位置を進める意味を有する。

SPINではLTL検査式を用いて検査が行われる。SPINが使用するLTL式は図２２に示すBNFで定義されている。

図２２に示す表現と同様の構文をCoq上に定義可能であり、LTL式の変換は、検査式の変換（ステップＳ３０４）において行われる。ここで出現するオペレータの意味を、システムの状態に対し、ライブラリ上に定義することが可能である。ライブラリでは、一例として”[]”の意味は、図２３に示すように定義される。ただし、図２３における、”s.(cur)”はState上の現在の状態であり、”s.(next)”は、”s.(cur)”からの非決定的に遷移可能な状態の集合である。

図１において、定理証明支援系１０５は、ライブラリ１０６の定義を利用した記述として変換されたEvent-BおよびSPINの記述を入力とする。利用者は、複数の製品の結合を検証するときは、この定理証明支援系（本具体例の場合はCoq）を使用して証明による検査を行う。

次に、本発明の概要を説明する。図２４は、本発明による検証性質統合装置の最小構成を示すブロック図である。本発明による検証性質統合装置（図１に示す検証性質統合装置１００に相当）は、定理証明支援系記述に対して与える形式仕様記述およびモデル検査記述の意味論を定義したライブラリ１３（図１に示す検証性質統合装置１００におけるライブラリ１０６に相当）を含む。また、本発明による検証性質統合装置は、ライブラリ１３を用いて、形式仕様記述を定理証明支援系上の表現に変換する第１の定理証明支援系記述生成部１１（第１の定理証明支援系記述生成手段、図１に示す検証性質統合装置１００における第１の定理証明支援系記述生成部１０３に相当）を含む。また、本発明による検証性質統合装置は、ライブラリ１３を用いて、モデル検査記述におけるモデルおよび時相論理式を定理証明支援系上の表現に変換する第２の定理証明支援系記述生成部１２（第２の定理証明支援系記述生成手段、図１に示す検証性質統合装置１００における第２の定理証明支援系記述生成部１０４に相当）とを含む。

そのような構成によれば、変換された形式仕様記述およびモデル検査記述について定理証明支援系上で結合を定義し、この結合を検査することが可能となる。また、既存の形式仕様記述やモデル検査で検証を行った製品について、再度別の形式手法に基づいて検査する必要がなくなり、より容易に既製の製品を組合せて安全な統合が可能となる。また、部品となる既製製品のみ検査し、結合の性質を検査しない場合と比較して、より安全性や信頼性の担保が容易となる他、その性質の範囲の追跡が可能となり、定められた安全基準を満足することが容易となると同時に、その審査が容易となる。

また、第１の定理証明支援系記述生成部１１は、形式仕様記述に含まれる詳細化関係について型拡張を使用し、精錬であることを示す公理を生成し、定理証明支援系には存在しない概念である事前条件や不変条件または事後条件を意味論上において扱うようにしてもよい。そのような構成によれば、形式仕様記述上で既に検証された性質を、変換後の定理証明支援系上において検証する義務を回避することができる。

また、第２の定理証明支援系記述生成部１２は、定理証明支援系上の変数の型を、数学的な厳密性または証明の容易さに応じて選択可能であってもよい。そのような構成によれば、例えば、有限の型およびその演算を用いると定理証明支援系上における証明のステップ数が大幅に増加する可能性がある場合に、厳密な検証を犠牲にする代わりに無限のサイズをもつ帰納的な型の使用を可能とすることができる。これより、定理証明による検査が容易になる。

また、第２の定理証明支援系記述生成部１２は、モデル検査におけるシステム全体の状態を個々のプロセスの状態、通信チャネルおよび変数の状態として構築し、モデル検査に使用する検査式を定理証明支援系上の述語として定義してもよい。そのような構成によれば、モデル検査記述で検証された性質を定理証明支援系で上で取り扱うことが可能となる。

また、第１の定理証明支援系記述生成部１１には、Event-Bによる記述が入力され、第２の定理証明支援系記述生成部１２には、SPINによる記述が入力されてもよい。そして、第１の定理証明支援系記述生成部１１および第２の定理証明支援系記述生成部１２は、入力された記述を定理証明支援系Coq上の記述に変換してもよい。そのような構成によれば、Event-B、SPINで検証された性質をCoq上で取り扱うことが可能となる。

また、第１の定理証明支援系記述生成部１１には、Event-Bによる記述とVDMによる記述のいずれか一方または両方が入力され、第２の定理証明支援系記述生成部１２には、SPINによる記述とUPPAALによる記述のいずれか一方または両方が入力されてもよい。そして、第１の定理証明支援系記述生成部１１および第２の定理証明支援系記述生成部１２は、入力された記述を定理証明支援系であるCoq、IsabelleまたはPhoXのうちのいずれかの表現に変換してもよい。そのような構成によれば、Event-B、VDM、SPIN、UPPAALで検証された性質をCoq、IsabelleまたはPhoX上で取り扱うことが可能となる。
以上、上述した実施形態を模範的な例として本発明を説明した。しかしながら、本発明は、上述した実施形態には限定されない。即ち、本発明は、本発明のスコープ内において、当業者が理解し得る様々な態様を適用することができる。
この出願は、２０１４年４月１７日に出願された日本出願特願２０１４−０８５２７０を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１１、１０３ 第１の定理証明支援系記述生成部
１２、１０４ 第２の定理証明支援系記述生成部
１３、１０６ ライブラリ
１００ 検証性質統合装置
１０１ 形式仕様記述装置
１０２ モデル検査器
１０５ 定理証明支援系
４０１ 形式仕様記述
４０２ 形式仕様記述の構文・意味論
４０３ 集合論
４０４ モデル検査記述
４０５ モデル検査記述の構文・意味論
４０６ 時相論理
５０１ 変換された形式仕様記述
５０２ 変換されたモデル検査記述
５０３ 定理証明支援系での構文・意味論
５０４ 変換された形式仕様記述・モデル検査記述向けライブラリ
５０５ 結合の定義

Refinesは、既存のMachineに対する精錬である。精錬とは、既存Machineに制約を付加した記述、または既存Machineの制約を強化した記述である。また、精錬時に導入される新規変数と既存変数と間の関係を定める連結不変条件（gluing invariantと呼ばれる）が成立している必要がある。変換対象がRefines（既存のMachineに対する精錬）であるときには、第１の定理証明支援系記述生成部１０３は、ステップＳ２０５の処理を開始することができないため、ステップＳ２０５の処理を中断し、ステップＳ２０１の処理へジャンプする。そして、第１の定理証明支援系記述生成部１０３は、依存する精錬対象についてステップＳ２０１〜Ｓ２０９を実行したのち、中断していたステップＳ２０５の処理を再開する。再開されたステップＳ２０５の処理において、第１の定理証明支援系記述生成部１０３は、Refinesが既存のMachineに対する精錬であるという事実に加え、精錬が有する性質を適切に形式的に表現するために、RefinesをCoq上のAxiomとして変換する。すなわち、係るAxiomは、イベントそれぞれについて、精錬結果の事前条件が成立するならば、精錬対象のイベントの事前条件が成立する、という公理である。

Claims (10)

1. 定理証明支援系記述に対して与える形式仕様記述およびモデル検査記述の意味論を定義したライブラリと、
   前記ライブラリを用いて、形式仕様記述を定理証明支援系上の表現に変換する第１の定理証明支援系記述生成手段と、
   前記ライブラリを用いて、モデル検査記述におけるモデルおよび時相論理式を定理証明支援系上の表現に変換する第２の定理証明支援系記述生成手段とを含む
   検証性質統合装置。
2. 前記第１の定理証明支援系記述生成手段は、形式仕様記述に含まれる詳細化関係について型拡張を使用し、精錬であることを示す公理を生成し、定理証明支援系には存在しない概念である事前条件や不変条件または事後条件を意味論上において扱う
   請求項１に記載の検証性質統合装置。
3. 前記第２の定理証明支援系記述生成手段は、定理証明支援系上の変数の型を、数学的な厳密性または証明の容易さに応じて選択可能である
   請求項１または請求項２に記載の検証性質統合装置。
4. 前記第２の定理証明支援系記述生成手段は、モデル検査におけるシステム全体の状態を個々のプロセスの状態、通信チャネルおよび変数の状態として構築し、モデル検査に使用する検査式を定理証明支援系上の述語として定義する
   請求項１から請求項３のうちのいずれか１項に記載の検証性質統合装置。
5. 前記第１の定理証明支援系記述生成手段には、Event-Bによる記述が入力され、
   前記第２の定理証明支援系記述生成手段には、モデル検査器であるPINによる記述が入力され、
   前記第１の定理証明支援系記述生成手段および前記第２の定理証明支援系記述生成手段は、入力された前記記述を定理証明支援系Coq上の記述に変換する
   請求項１から請求項４のうちのいずれか１項に記載の検証性質統合装置。
6. 前記第１の定理証明支援系記述生成手段には、Event-Bによる記述とVDMによる記述のいずれか一方または両方が入力され、
   前記第２の定理証明支援系記述生成手段には、SPINによる記述とUPPAALによる記述のいずれか一方または両方が入力され、
   前記第１の定理証明支援系記述生成手段および前記第２の定理証明支援系記述生成手段は、入力された記述を定理証明支援系であるCoq、IsabelleまたはPhoXのうちのいずれかの表現に変換する
   請求項１から請求項５のうちのいずれか１項に記載の検証性質統合装置。
7. 定理証明支援系記述に対して与える形式仕様記述およびモデル検査記述の意味論を定義したライブラリを用いて、形式仕様記述を定理証明支援系上の表現に変換し、前記ライブラリを用いて、モデル検査記述におけるモデルおよび時相論理式を定理証明支援系上の表現に変換することにより、
   形式仕様記述およびモデル検査記述を用いて定義および検証された性質を定理証明支援系上の記述に変換する
   検証性質統合方法。
8. 形式仕様記述のシステム定義に含まれる詳細化関係について型拡張を使用し、精錬であることを示す公理を生成し、定理証明支援系には存在しない概念である事前条件や不変条件または事後条件を、定理証明支援系の意味論上において扱う
   請求項７に記載の検証性質統合方法。
9. 定理証明支援系上の変数の型を、数学的な厳密性または証明の容易さに応じて切り替え可能とし、
   モデル検査におけるシステム全体の状態を個々のプロセスの状態、通信チャネルおよび変数の状態として構築し、モデル検査に使用する検査式を定理証明支援系上の述語として定義する
   請求項７または請求項８に記載の検証性質統合方法。
10. コンピュータに、
    定理証明支援系記述に対して与える形式仕様記述およびモデル検査記述の意味論を定義したライブラリを用いて、形式仕様記述を定理証明支援系上の表現に変換する処理と、
    前記ライブラリを用いて、モデル検査記述におけるモデルおよび時相論理式を定理証明支援系上の表現に変換する処理と、を実行させる
    検証性質統合プログラムが記録された記憶媒体。

Images