JP6731062B2 - 設計検証装置 - Google Patents

設計検証装置 Download PDF

Info

Publication number
JP6731062B2
JP6731062B2 JP2018543570A JP2018543570A JP6731062B2 JP 6731062 B2 JP6731062 B2 JP 6731062B2 JP 2018543570 A JP2018543570 A JP 2018543570A JP 2018543570 A JP2018543570 A JP 2018543570A JP 6731062 B2 JP6731062 B2 JP 6731062B2
Authority
JP
Japan
Prior art keywords
design
requirement
specifications
inspection
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018543570A
Other languages
English (en)
Other versions
JPWO2018066140A1 (ja
Inventor
正裕 松原
正裕 松原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Publication of JPWO2018066140A1 publication Critical patent/JPWO2018066140A1/ja
Application granted granted Critical
Publication of JP6731062B2 publication Critical patent/JP6731062B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/20Design optimisation, verification or simulation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3604Software analysis for verifying properties of programs
    • G06F11/3608Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Description

本発明は、要求仕様と設計仕様との間の整合性を検証する技術に関する。
システム開発においては、初期の段階で要求仕様が定義される。要求仕様に基づき、システム、ハードウェア、ソフトウェアが設計される。設計結果は要求仕様を満たす必要がある。
下記特許文献1は、鉄道保安機能を実現する連動装置の設計を検証する技術を開示している。同文献においては、要求仕様と設計仕様を形式的言語による記述に変換し、両者の内容の等価性を形式的に検証する。両者が等価であれば設計が正しく、等価でなければ設計に誤りがあると判定し、その判定結果を出力する。
下記特許文献2は、プラントの安全を保護するための保護論理を検証する技術を開示している。同文献においては、要求仕様にしたがって設計され代数仕様を用いて記述された設計仕様が、要求仕様と適合しているか否かを検証する。
設計が要求仕様に適合しているか否かを検証する際には、要求仕様の記述が正確かつ十分に記載されていることも重要である。下記特許文献3においては、要求仕様を上位要件(例えばシステムの機能の観点)から下位要件(例えばハードウェアやソフトウェアの機能に関する要件)に分解するツリー形式でモデル化し、さらに命題論理を用いて各要件を記述することにより、要件をあいまいさなく表現し、かつ上位要件に対する下位要件の完全性を自動検証している。このようにツリー形式で要件を表現することは、システムに対する要件をあますことなく記載する上で有効である。
特開平10−16776号公報 特開平6−274562号公報 特開2014−174730号公報
要求仕様と設計仕様は、それぞれに適した記法で表現されるので、多くの場合において異なる記法で表現される。例えば要求仕様は振る舞いを1つの記号で表現しているのに対し、設計仕様は状態を1つの変数で表現し、振る舞いを手続き的に表現している場合がある。この場合、両者を自動的に対応付けることが困難である。例えば1つの要件内の記号と、設計内の記号との間の対応付けができない場合、その要件の論理式は、設計に対する検査式として用いることができない。また、同一の対象・振る舞いが、要求仕様と設計仕様との間で異なる記号によって表現されることも多々ある。
本発明は、上記のような課題に鑑みてなされたものであり、要求仕様と設計仕様が互いに異なる記法によって表現されている場合であっても、設計仕様が要求仕様に適合しているか否かを自動的に検査することを促進する技術を提供することを目的とする。
本発明に係る設計検証装置は、要求仕様と設計仕様との間の記号が対応付けされている論理式を用いて、設計仕様が要求仕様に適合しているか否かを検査する。
本発明に係る設計検証装置によれば、要求仕様と設計仕様が互いに異なる記法によって記述されている場合であっても、設計仕様が要求仕様を満たしているか否かを自動的に検査することができる。
実施形態1に係る設計検証装置100の構成図である。 要求仕様データ210が記述している要求仕様の例を示すツリー構造である。 設計仕様データ220が記述している設計仕様の例を示すブロック図である。 設計仕様データ220の振る舞いをプログラミング言語(C言語)で表現した例である。 対応関係データ230の具体例である。 設計検証装置100の動作を説明するフローチャートである。 ステップS601において生成される記号対応表の例である。 ステップS2602の詳細を説明するフローチャートである。 出力部140が検査部130による検査結果を画面表示した例である。 設計仕様データ220をモデル検査器SPINの記述言語Promelaで表現した例である。 コンピュータを用いて設計検証装置100を実装した場合におけるシステム構成図である。
<実施の形態1>
図1は、本発明の実施形態1に係る設計検証装置100の構成図である。設計検証装置100は、設計仕様が要求仕様を満たしているか否かを検証する装置である。設計検証装置100は、要求仕様データ210、設計仕様データ220、対応関係データ230を入力データとして受け取る。設計検証装置100は、記号対応付け部110、検査式定義部120、検査部130、出力部140を備える。
要求仕様データ210は、設計対象であるシステムに対する要件の集合を記述したデータである。各要件は命題変数などの記号を用いて形式仕様記述言語で表現することができる。要求仕様データ210は、上位要件を下位要件に分解するツリー形式で表現されている。ツリーのノードが各要件に相当する。ツリー形式で記述された要件の例については後述する。
設計仕様データ220は、設計対象システムの設計仕様を記述したデータである。設計仕様データ220の具体例としては、システムアーキテクチャ、ソフトウェアアーキテクチャ、ハードウェア仕様、ソフトウェア仕様などを記述したデータが挙げられる。設計仕様データ220は、シミュレーション可能なプログラミング言語、形式仕様記述言語などによって表現することができる。
対応関係データ230は、要求仕様データ210が用いている記号と、設計仕様データ220が用いている記号との間の論理的な対応関係を記述したデータである。ここでいう記号とは、各仕様が要件を記述するために用いている論理式、またはその論理式内で用いているプログラム変数、などのことである。例えば各仕様が同一の要素を異なる記号・変数で表現している場合や、同一の振る舞いについて異なる表現をしたりしている場合において、対応関係データ230はこれらの間の対応関係を記述することができる。対応関係データ230の具体例については後述する。
記号対応付け部110は、要求仕様データ210が用いている記号と、設計仕様データ220が用いている記号とを対応付け、その対応関係を記号対応表として出力する。記号対応表の具体例については後述する。
検査式定義部120は、設計仕様データ220によって記述されている設計仕様が要求仕様データ210によって記述されている要求仕様に適合しているか否かを検査するための検査式を定義する。検査式は、例えばプログラムの一部として組み込んで実行することによりその検査式が表す論理が成立するか否かを検証する論理式として定義することができる。その他、形式仕様記述言語として検査式を定義することもできる。検査式を定義する手順については後述する。
検査部130は、検査式定義部120が定義した検査式を用いて、設計仕様データ220を検査する。設計仕様データ220がプログラミング言語によって記述されている場合はそのプログラムをシミュレーション実行することにより検査する。設計仕様データ220が形式仕様記述言語によって記述されている場合は形式検証によって検査する。検査式定義部120は、設計仕様データ220の記述形式に応じて検査式を定義する。
出力部140は、検査部130による検査結果を出力する。例えば検査結果を記述したデータを出力することもできるし、検査結果を画面表示することもできる。その他適当な出力形式を用いることもできる。検査結果の出力例については後述する。
図2は、要求仕様データ210が記述している要求仕様の例を示すツリー構造である。要求仕様データ210は、最上位の要件211をルートとするツリー構造を有する。要件211〜216は、命題論理を用いて、“A→B”の形で記述されている(AとBは命題変数)。Aを前件、Bを後件と呼ぶ。この記述方法は、時相論理式“A→◇B”(◇は「いつか」の意味)に対してシンタックスシュガー(糖衣構文)を導入して簡略化したものである。各要件の論理式は、複数の命題を論理和や論理積によって論理的に結合したものであってもよい。
要件211〜216の記述に用いられる命題変数は、記号辞書59に定義されている。ここでは命題変数の例として、E「電源に異常がある」、D「異常が検出される」、M「警告表示が指示される」、WN「警告が表示される」、Z「駆動回路が停止する」を例示した。
要件211は“E→WN&&Z”と記述されている。この意味は「電源に異常があれば、警告が表示され、かつ、駆動回路が停止する」である。要件211は、下位の要件212〜214に分解されている。要件212は“E→M”「電源に異常があれば、警告表示が指示される」、要件213は“M→WN”「警告表示が指示されれば、警告が表示される」、要件214は「電源に異常があれば、駆動回路が停止する」である。要件212は、下位の要件5215〜216に分解されている。要件215は“E→D”「電源に異常があれば、異常が検出される」、要件216は“D→M”「異常が検出されれば、警告表示が指示される」である。
図3は、設計仕様データ220が記述している設計仕様の例を示すブロック図である。設計仕様データ220が記述している機能ブロックは、電源221、駆動回路222、診断223、表示224を有する。電源線228は、電源221と駆動回路222の間、および電源221と診断223の間を接続する。表示224に対する電源供給は簡単のため省略している。
電圧225は、電源線228の電圧を通知する信号線である。停止指示226は、駆動回路222に対して停止指示を送信する信号線である。警告指示227は、表示224に対して警告指示を送信する信号線である。電圧225は電圧v、停止指示226は停止指示(の有無)s、警告指示227は警告指示(の有無)cとして表現されている。電圧225は電源線228から診断223に接続され、停止指示226は診断223から駆動回路222に接続され、警告指示227は診断223から表示224に接続されている。
図4は、設計仕様データ220の振る舞いをプログラミング言語(C言語)で表現した例である。図4に示すプログラムは、設計仕様データ220に内包されるものであってもよいし、設計仕様データ220とは別に記述したものであってもよい。ただし設計検証装置100に対して設計仕様データ220として入力される実質的な内容は、図4に示すように検査部130が検査することができるプログラム言語や仕様記述言語によって記述されたものである。
図4のプログラムは、関数power()、diag()、disp()を有する。これら関数はそれぞれ電源221、診断223、表示224に対応している。駆動回路222に対応する関数は、便宜上省略した。関数main()は、1回分のシミュレーションを実行する関数である。電圧vは実システムの10倍の値を取るようにスケーリングされている。
関数power()において、電圧vが0〜100の値を取り、その初期値は50、±2の範囲で変動するように更新される。関数diag()において、診断223の動作可否を示すフラグ変数enaが、電圧vが30より大きく60未満のときにTRUE(動作可)、それ以外ではFALSE(動作不可)にセットされる。診断223が動作可であり電圧vが40以下または60以上であれば、電圧異常を示すフラグerrをTRUE(異常あり)にセットする。さらに、警告指示の有無を示すフラグcをerrと同じ値にセットする。関数disp()において、警告指示フラグcがTRUEであれば、警告表示の有無を示すフラグWNをTRUEにセットする。
図5は、対応関係データ230の具体例である。対応関係データ230は、要求仕様データ210と同じ記法を用いて記述される。対応関係231は、論理式“E==(v>=60||v<=40)”を定義している。すなわち、要求仕様データ210が記述している記号“E”が表す論理命題は、設計仕様データ220においては“電圧vが60以上または電圧vが40以下”と等価であることを示す。対応関係232は、論理式“M==c”を定義している。すなわち、要求仕様データ210が記述している記号“M”が表す論理命題は、設計仕様データ220においては警告指示cと等価であることを示す。
図6は、設計検証装置100の動作を説明するフローチャートである。記号対応付け部110は、記号対応表を生成する(S601)。検査式定義部120は、設計仕様データ220を検証するための検査式を定義する(S602)。ステップS602の詳細は後述する。検査部130は、検査式定義部120が定義した検査式を用いて設計仕様データ220を検査する(S603)。出力部140は、検査部130による検査結果を出力する(S604)。
図7は、ステップS601において生成される記号対応表の例である。図7に示す記号対応表によれば、要求仕様データ210が記述している記号E、WN、Mは、それぞれ設計仕様データ220が記述している記号v、WN、cに対応するものとして取り扱われることになる。1行目は対応関係231に基づき生成したものである。3行目は対応関係232に基づき生成したものである。
記号対応表を生成する方法は次の通りである。記号対応付け部110は、対応関係データ230の各論理式(図5の対応関係231と232)について、式に含まれる記号それぞれが、要求仕様データ210と設計仕様データ220のいずれかに含まれているか否かを検索する。当該論理式に含まれる記号が全て、要求仕様データ210と設計仕様データ220のいずれかに存在するのであれば、当該論理式に含まれる記号のうち要求仕様データ210に含まれる記号を要求仕様側に分類し、設計仕様データ220に含まれる記号を設計仕様側に分類し、これらを記号対応表の1行分のレコードとして登録する。
要求仕様データ210の記号と設計仕様データ220の記号が1対1に対応している場合のみならず、1対複数(例として、論理式がE=v1+v2)、複数対1、複数対複数である場合であっても、同様の手法により記号対応表を生成することができる。例えば対応関係データ230が記述している論理式がE=v1+V2である場合、要求仕様側として“E”、設計仕様側として“v1,v2”などと記述したレコードを記号対応表に記録すればよい。後述するように、記号対応表は要求仕様と設計仕様との間で対応する記号が存在することが確認できれば足りるからである。
さらに記号対応付け部110は、要求仕様データ210と設計仕様データ220が同じ記号を用いている場合も、それらの記号は対応しているものとしてその対応関係を記号対応表に登録する。図7の2行目(WN)がこれに該当する。
図8は、ステップS602の詳細を説明するフローチャートである。検査式は要件仕様と同様に、“X→Y”(XならばY)の形で定義される。XとYは命題を表す変数である。検査式は、要求仕様データ210が記述している要件と同様に時相論理式を簡略化して記述されている。以下図8にしたがって検査式定義部120の動作を説明する。
(図8:ステップS801)
検査式定義部120は、初期設定を実施する。具体的には、検査式や仮検査式を初期化するなどの処理がこれに相当する。仮検査式とは、以後のステップにおいて検査式の候補となる論理式である。
(図8:ステップS802)
検査式定義部120は、要求仕様データ210に含まれる要件のうち、前件の記号が全て記号対応表に登録されているものを抽出する。検査式定義部120は、抽出された要件の論理式を仮検査式として一時保存する。
(図8:ステップS802:補足)
設計検証装置100は、要求仕様データ210が記述している記号と設計仕様データ220が記述している記号との間の対応関係が取れている論理式を、検査式として用いる。本ステップは、前件について対応関係が取れているか否かをいったんチェックすることにより、検査式の候補を絞り込むためのものである。
(図8:ステップS803)
検査式定義部120は、仮検査式の数を調べる。仮検査式の数が0より大きい場合は、ステップS804〜S809を各仮検査式について実施する。仮検査式の数が0である場合は、検査式なしとして本フローチャートを終了する。
(図8:ステップS804〜S805)
検査式定義部120は、現在処理している仮検査式の後件を前件として有する要件を、要求仕様データ210から1つ検索する。ただしステップS802やステップS804においてこれまで取り扱った要件は検索対象から除く。条件に該当する要件が存在する場合はステップS806へ進み、存在しない場合はステップS807へ進む。
(図8:ステップS806)
検査式定義部120は、仮検査式の後件を、ステップS804において検索により得られた要件が有する後件と置き換える。例えば、仮検査式が“X→Y”であり、ステップS804において得られた要件が“Y→Z”である場合は、仮検査式を“X→Z”に更新する。これにより、論理式“X→Y”と“Y→Z”を結合して新たな論理式“X→Z”を得たことになる。この結合された論理式を検査式として用いることにより、要件“X→Y”と“Y→Z”を一括して検証することができる。より詳細な例については後述する。
(図8:ステップS807)
検査式定義部120は、仮検査式の後件の記号が全て記号対応表に登録されているか否かを照合する。後件の全記号が登録されていればステップS808に進み、そうでなければステップS809に進む。本ステップにより、前件と後件ともに記号が対応付けられている論理式を、検査式として抽出することができる。
(図8:ステップS808〜S809)
検査式定義部120は、ステップS807において記号が対応していると判断された仮検査式を、正式な検査式として登録する。ただし、既に登録済である場合は重複登録する必要はない。検査式定義部120は、ステップS807において記号が対応していないと判断された仮検査式を、検査式の候補から破棄する。
以下では、検査式定義部120が図2の要求仕様データ210から検査式を抽出する手順を説明する。説明の簡易のため、図5の対応関係231のみが与えられ、対応関係232は与えられていないことを前提とする。したがって記号対応表は、図7の1行目と2行目のみとなる。
ステップS802において、検査式定義部120は、記号対応表内に含まれる記号EまたはWNを前件として有する要件を、要求仕様データ210から抽出する。抽出された要件は仮検査式として取り扱われる。ここでは要件211、212、214、215がこれに該当する。これら要件について、図8のフローチャートにしたがってどのように処理されるかを説明する。
要件211については、その後件(WN&&Z)を前件として有するその他要件が存在しないので、ステップS804において抽出されないので、ステップS805とステップS807の判定結果がNoとなり、ステップS809において破棄される。
要件212については、その後件(M)を前件として有する要件213がステップS804において抽出されることになる。したがって、論理式“E→M”と“M→WN”を結合することができるので、ステップS806において仮検査式が “E→WN”に更新される。ステップS808において、“E→WN”が検査式として登録される。
要件214については、要件211と同様にステップS809において破棄される。
要件215については、その後件(D)を前件として有する要件216がステップS804において抽出されることになる。したがって、ステップS806において仮検査式が “E→M”に更新される。さらに更新後の仮検査式の後件(M)を前件として有する要件213が抽出されるので、仮検査式は“E→WN”となる。ただしこの仮検査式は既に登録されているので、ステップS808において登録されない。
対応関係232がさらに与えられている場合は、記号対応表内に含まれる記号Mを前件として有する要件213が仮検査式として抽出される。この場合、最終的な検査式は“E→M”および“M→WN”となる。
以下では、検査部130が設計仕様データ220を検査する方法を説明する。検査部130は、検査実行前に、記号対応表を用いて検査式を書き換える。“E→WN”は、“(v<=40||v>=60)→WN”と書き換えられる。検査部130は、設計仕様データ220の挙動をシミュレーションするために、設計仕様データ220をコンパイルし、所定回数だけ繰り返し実行する。検査部130は、1回の実行ごとに、検査式が成立するか否かを判定する。前件(v<=40||v>=60)が真であるのに後件(WN)が偽であるケースが1回でも生じた場合は、検査式“E→WN”を不合格と判定する。シミュレーション中に前件(E)が1度も真にならない場合は、検査結果は「確認不可」とする。不合格でも確認不可でもなくシミュレーションを完了したら、検査式は合格と判定する。
図4に示した設計仕様データ220は、電圧vが60のときerr=TRUEとなるように記述されているので、本来であれば電圧異常とみなされるはずである。他方で電圧vが60のときena=FALSEとなるので、err=TRUEが実行されず、したがってc=FALSEのままなので、WN=FALSEとなる。そうすると電圧vが60のとき、要件E(v<=40||v>=60)がTRUEであってもWN=FALSEとなるので、検査式は成立しないことになる。すなわち、検査式“E→WN”は不合格と判定される。出力部140は、検査式が満たされなかった条件(ここでは電圧v=60)を、検査結果と併せて出力する。電圧vのその他の値についても同様に検査式が成立するか否かを検証する。
検査部130が設計仕様データ220を検査することにより、要求仕様データ210と設計仕様データ220との整合性(矛盾の有無)を、自動的に検査することができる。また、要求仕様データ210と設計仕様データ220は同一の対象・振る舞いを異なる記号で表現しているが、このような場合であっても、両者の記号の対応付け、確認可能な検査式の生成、検査実行を自動的に実施することができる。
図9は、出力部140が検査部130による検査結果を画面表示した例である。ここでは図2で説明した要求仕様データ210を入力として検査し、検査式“E→WN”が満たされた例を示した(検査式欄142)。
要求仕様欄141は、要求仕様データ210のツリー構造に対して、検査結果を反映したものである。記号対応表に記載のある記号は、下線が引かれている。満たされた検査式を生成する際に使用した要件(先に説明した例においては要件212と213)は太線枠で囲まれている。さらに検査式が満たされることによりこれらの下位要件(要件215と216)も間接的に満たされたものとみなすことができるので、同様に太線枠で囲まれている。下位要件が全て満たされている要件は、満たされたものとして表示してもよい。例えば要件215と要件216が検査式として取り扱われて満たされた場合、要件212は満たされたものとして表示してもよい。
要求仕様欄141により、上位要件を下位要件に分解するツリー形式の要求仕様データ210について、設計仕様データ220が要件を満たす範囲を提示するとともに、検査されていない範囲を提示することができる。これによりユーザは、要求仕様データ210や設計仕様データ220の確認・見直しを効率的にすることができる。例えばユーザは、満たされていない要件については、要求仕様データ210または設計仕様データ220を修正することができる。また、検査式に関係していない要件(すなわち検査されていない要件)については、必要に応じて、対応関係データ230を増補することにより、検査されるようにすることができる。
<実施の形態2>
実施形態1においては、命題論理を用いて要件や検査式を記述しているが、これに代えて時相論理式を用いて記述してもよい。時相論理式を用いて要件を記述する場合、図8で説明した検査式定義部120の処理手順が若干変わる。例えば時相論理としてLTL(Linear Temporal Logic)が用いられており、要件が例えば“X→◇Y”の形で記述されている場合、ステップS804において“X→◇Y”と“Y→◇Z”が論理的につながり、ステップS806において仮検査式は“X→◇Z”に更新される。対応関係231を与えて対応関係232を与えない場合、ステップS808において登録される検査式は“E→◇WN”となる。さらに検査式定義部120は、図8のフローチャートによって得られた検査式を□(いつも)で囲い、最終的な検査式は“□(E→◇WN)”とする。
図10は、設計仕様データ220をモデル検査器SPINの記述言語Promelaで表現した例である。ここでは図4と同じ振る舞いを記述した例を示した。形式検証の一種であるモデル検査は、シミュレーションより厳密な検査を実施することができる。
検査部130は、設計仕様データ220と、時相論理による検査式“□(E→◇WN)”とを併せてモデル検査器SPINに入力して実行可能な検査器を生成させ、検査を実行させる。モデル検査器は、検査式の合否と、検査式が満たされない場合は検査式に違反する実行パスを反例として出力する。図10に示す設計仕様データ220については、電圧vが60以上になってもWNが真とならない場合が反例として得られるので、検査結果は不合格である。出力部140は、図9と同様に検査式、検査結果、反例を出力する。
<実施の形態3>
実施形態1〜2で説明した設計検証装置100の各機能部(記号対応付け部110〜出力部140)は、ソフトウェアとして実装することができる。設計検証装置100は、各機能部を実行するプロセッサ、表示画面、主演算装置、主記憶装置(メインメモリ)、記憶媒体(ハードディスク等)、入力装置(キーボードやポインティングデバイス等)を備えるコンピュータを用いて構成することができる。
図11は、コンピュータを用いて設計検証装置100を実装した場合におけるシステム構成図である。記号対応付け部110〜出力部140は、設計検証プログラム3131として実装されている。設計検証プログラム3131は、例えばコンピュータ21上のROM(Read Only Memory)313に格納されており、CPU(Central Processing Unit)311によって読み出され、RAM(Random Access Memory)312を一時記憶領域として実行される。コンピュータ21は、設計検証プログラム3131によって規定された処理を実行する。各入力データ(要求仕様データ210〜対応関係データ230)、検査部130からの出力データ、中間処理結果などの電子データは、コンピュータ31上のハードディスク314に格納される。検査実行指示などのユーザ操作は、入力装置22から実施できる。
出力部140からの出力は、例えばディスプレイなどの表示装置33やハードディスク314に対して出力されるが、これに限られるものではない。例えば出力部140は、図示しない外部コンピュータへのネットワークを介した出力、CD−ROMなどの外部記憶媒体へのデータファイル形式での出力、などの出力形式を用いてもよい。
<本発明の変形例について>
本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
以上の実施形態において、要求仕様データ210と設計仕様データ220とで同じ記号を利用している場合、これらの記号は対応しているものとして取り扱うことを説明した。ただしこれらの記号間に対応関係があるとするか否かは、設計検証装置100の設計者や利用者に選択させてもよい。
以上の実施形態において、要求仕様欄141は、検査結果として図9以外の適当な表示形式を用いてもよい。例えば検査式を生成する際に関係した要件(説明した例においては、要件212、213、215、216)について、検査式が満たされたことを示す印(例:チェックマーク)、満たされなかったことを示す印(例:×印)を付与してもよい。いずれの検査式にも関係していない要件については、その旨を示す印(例:クエスチョンマーク)を付けて表示してもよい。
以上の実施形態において、対応関係データ230は、例えば要求仕様データ210または設計仕様データ220の設計者が与えることもできるし、適当な手段によって要求仕様データ210と設計仕様データ220を比較することにより自動生成することができるのであればそれによって与えてもよい。
100:設計検証装置
110:記号対応付け部
120:検査式定義部
130:検査部
140:出力部
210:要求仕様データ
220:設計仕様データ
230:対応関係データ

Claims (9)

  1. 仕様記述言語を用いて表した仕様要件を論理的に結合することにより記述された要求仕様と、前記要求仕様をソフトウェアとして設計した設計仕様との間の整合性を検証する、設計検証装置であって、
    前記要求仕様において用いている記号と、前記設計仕様において用いている記号との間の対応関係を記述した記号対応表を生成する、記号対応付け部、
    前記設計仕様が前記要求仕様を満たしているか否かを検査するための検査式として、前記仕様要件のうち前記記号対応表が記述している記号を含むものを抽出する、検査式定義部、
    前記検査式を用いて前記設計仕様が前記要求仕様を満たしているか否かを検査する検査部、
    を備え
    前記要求仕様は、前記仕様要件として、第1前件と第1後件を有する第1要件、第2前件と第2後件を有する第2要件、を記述しており、
    前記検査式定義部は、前記第1後件と前記第2前件が同じ論理式を表している場合は、前記第1前件を前件として有し前記第2後件を後件として有する結合論理式を、前記検査式として抽出する
    ことを特徴とする設計検証装置。
  2. 仕様記述言語を用いて表した仕様要件を論理的に結合することにより記述された要求仕様と、前記要求仕様をソフトウェアとして設計した設計仕様との間の整合性を検証する、設計検証装置であって、
    前記要求仕様において用いている記号と、前記設計仕様において用いている記号との間の対応関係を記述した記号対応表を生成する、記号対応付け部、
    前記設計仕様が前記要求仕様を満たしているか否かを検査するための検査式として、前記仕様要件のうち前記記号対応表が記述している記号を含むものを抽出する、検査式定義部、
    前記検査式を用いて前記設計仕様が前記要求仕様を満たしているか否かを検査する検査部、
    を備え
    前記記号対応付け部は、前記要求仕様が記述している論理式と前記設計仕様が記述している論理式との間の対応関係を記述した対応関係データを受け取り、
    前記記号対応付け部は、前記対応関係データが記述している対応関係から、前記要求仕様において用いている記号と、前記設計仕様において用いている記号との間の対応関係を抽出することにより、前記記号対応表を生成する
    ことを特徴とする設計検証装置。
  3. 仕様記述言語を用いて表した仕様要件を論理的に結合することにより記述された要求仕様と、前記要求仕様をソフトウェアとして設計した設計仕様との間の整合性を検証する、設計検証装置であって、
    前記要求仕様において用いている記号と、前記設計仕様において用いている記号との間の対応関係を記述した記号対応表を生成する、記号対応付け部、
    前記設計仕様が前記要求仕様を満たしているか否かを検査するための検査式として、前記仕様要件のうち前記記号対応表が記述している記号を含むものを抽出する、検査式定義部、
    前記検査式を用いて前記設計仕様が前記要求仕様を満たしているか否かを検査する検査部、
    を備え
    前記要求仕様は、前件と後件によって表される論理式を、前件と後件によって表される複数の別の論理式へ分割することによって形成される、ツリー形式の論理構造によって記述されている
    ことを特徴とする設計検証装置。
  4. 前記検査式定義部は、前記結合論理式のうち前記第1前件と前記第2後件が前記記号対応表のなかに記述されているものを、前記検査式として抽出する
    ことを特徴とする請求項記載の設計検証装置。
  5. 前記検査部は、前記結合論理式を前記検査式として用いることにより、前記第1要件と前記第2要件を一括して検査する
    ことを特徴とする請求項記載の設計検証装置。
  6. 前記検査部は、前記検査式を埋め込んだプログラムを実行することにより前記検査式が表す現象が実行過程において成立するか否かを検証するか、または、前記検査式が論理的に成立するか否かを形式検証することにより、前記設計仕様が前記要求仕様を満たしているか否かを検査する
    ことを特徴とする請求項1から3のいずれか1項記載の設計検証装置。
  7. 前記設計検証装置は、前記検査部による検査結果を出力する出力部を備える
    ことを特徴とする請求項1から3のいずれか1項記載の設計検証装置。
  8. 前記出力部は、前記要求仕様において用いている記号のうち前記記号対応表が記述しているものについて、その旨を前記検査結果に加えて出力する
    ことを特徴とする請求項記載の設計検証装置。
  9. 前記設計検証装置は、前記検査部による検査結果を出力する出力部を備え、
    前記出力部は、前記結合論理式を前記検査式として用いることにより、前記第1要件と前記第2要件を一括して検査した旨を、前記検査結果として出力する
    ことを特徴とする請求項記載の設計検証装置。
JP2018543570A 2016-10-07 2016-10-07 設計検証装置 Active JP6731062B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/080016 WO2018066140A1 (ja) 2016-10-07 2016-10-07 設計検証装置

Publications (2)

Publication Number Publication Date
JPWO2018066140A1 JPWO2018066140A1 (ja) 2019-08-22
JP6731062B2 true JP6731062B2 (ja) 2020-07-29

Family

ID=61830911

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018543570A Active JP6731062B2 (ja) 2016-10-07 2016-10-07 設計検証装置

Country Status (3)

Country Link
EP (1) EP3525114A4 (ja)
JP (1) JP6731062B2 (ja)
WO (1) WO2018066140A1 (ja)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016051234A (ja) * 2014-08-29 2016-04-11 株式会社日立製作所 要求仕様の記述と検証のためのシステム

Also Published As

Publication number Publication date
WO2018066140A1 (ja) 2018-04-12
JPWO2018066140A1 (ja) 2019-08-22
EP3525114A4 (en) 2020-05-06
EP3525114A1 (en) 2019-08-14

Similar Documents

Publication Publication Date Title
EP2876519B1 (en) Safety analysis of a complex system using component-oriented fault trees
Nair et al. An extended systematic literature review on provision of evidence for safety certification
Campos et al. Model checking interactor specifications
Bahig et al. Formal verification of automotive design in compliance with ISO 26262 design verification guidelines
WO2016174743A1 (ja) ソースコード等価性検証装置、および、ソースコード等価性検証方法
Wei et al. Architecture-level hazard analysis using AADL
Tundis et al. Modeling system requirements in modelica: definition and comparison of candidate approaches
Fu et al. LLM4SecHW: Leveraging domain-specific large language model for hardware debugging
JP2007011605A (ja) ソフトウェア動作仕様のモデル検査支援装置およびこれを備えたモデル検査システム並びにモデル検査支援プログラム
Müller et al. The hazard analysis profile: Linking safety analysis and SysML
Luo et al. Safety-driven development and ISO 26262
Jayakumar Systematic model-based design assurance and property-based fault injection for safety critical digital systems
Abdulkhaleq A system-theoretic safety engineering approach for software-intensive systems
JP6731062B2 (ja) 設計検証装置
Fan et al. Empirical analysis of software-induced failure events in the nuclear industry
Manolios et al. A model-based framework for analyzing the safety of system architectures
CN116802640A (zh) 用于确定安全相关逻辑中的故障类型的结构分析
Hecht et al. Using SysML to automatically generate of failure modes and effects analyses
Sawhney et al. Automatic construction of runtime monitors for FPGA based designs
Shaikh et al. A feedback technique for unsatisfiable UML/OCL class diagrams
Cha et al. Systematic evaluation of fault trees using real-time model checker UPPAAL
Langari et al. Quality, cleanroom and formal methods
Singh et al. Stateflow to tabular expressions
Antonino et al. Automatic detection of incomplete and inconsistent safety requirements
Saifan et al. Using formal methods for test case generation according to transition-based coverage criteria

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190314

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200414

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200604

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200616

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200703

R150 Certificate of patent or registration of utility model

Ref document number: 6731062

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150