特許 6248008 ソフトウェア検証システムおよび制御装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6248008

(24)【登録日】2017年11月24日

(45)【発行日】2017年12月13日

(54)【発明の名称】ソフトウェア検証システムおよび制御装置

(51)【国際特許分類】

   G06F 11/36 20060101AFI20171204BHJP

【ＦＩ】

   G06F11/36 108

【請求項の数】6

【全頁数】10

(21)【出願番号】特願2014-153420(P2014-153420)

(22)【出願日】2014年7月29日

(65)【公開番号】特開2016-31622(P2016-31622A)

(43)【公開日】2016年3月7日

【審査請求日】2017年2月22日

(73)【特許権者】

【識別番号】509186579

【氏名又は名称】日立オートモティブシステムズ株式会社

(74)【代理人】

【識別番号】100098660

【弁理士】

【氏名又は名称】戸田 裕二

(72)【発明者】

【氏名】成沢 文雄

(72)【発明者】

【氏名】松原 正裕

(72)【発明者】

【氏名】西 昌能

(72)【発明者】

【氏名】蛯名 朋仁

【審査官】 大塚 俊範

(56)【参考文献】

【文献】 特開２０１０−２１８１４８（ＪＰ，Ａ）

【文献】 特開２００８−２０３９７７（ＪＰ，Ａ）

【文献】 国際公開第２０１１／０５２０３０（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １１／２８−１１／３６

(57)【特許請求の範囲】

【請求項1】

入出力に依存関係のある複数の機能を備えた制御プログラムのソースコードを入力し、前記制御プログラムを検証する検査実行部と、
前記ソースコードを前記複数の機能単位で複数の検査部位に分割し抽出する検査部位抽出部と、
前記複数の検査部位のうち一の検査部位に関する検査結果出力に基づき、連続する次の検査部位の検査範囲を規定する第1の制約式を作成する第1の制約式作成部と、を備え、
前記第1の制約式に基づいて前記複数の検査部位を順に検査することを特徴とするソフトウェア検証システム。

【請求項2】

請求項１に記載のソフトウェア検証システムにおいて、
制御対象機器の取り得る状態遷移、制御対象機器の外界情報設定値、制御仕様の少なくとも1つに基づいて、検査部位の検査範囲を規定する第2の制約式を作成する第2の制約式作成部を備え、
第1の制約式と第2の制約式とに基づいて前記複数の検査部位を順に検査することを特徴とするソフトウェア検証システム。

【請求項3】

請求項２に記載のソフウェア検証システムであって、
前記検査部位抽出部はC言語で記述されたソフトウェアのソースコードを対象とし、関数を単位として抽出することを特徴とするソフトウェア検証システム。

【請求項4】

請求項２に記載のソフウェア検証システムであって、
検査対象処理記述と事前条件と事後条件のうち少なくともひとつを入力として、前記複数の検査部位を順に検査することを特徴とするソフトウェア検証システム。

【請求項5】

請求項２に記載のソフウェア検証システムであって、
前記第1の制約式と前記第2の制約式を統合する制約式統合部を備えることを特徴とするソフトウェア検証システム。

【請求項6】

センサおよびアクチュエータに接続され、前記センサの入力をもとに制御演算を行いアクチュエータへ出力する制御装置において、
請求項１に記載の制御プログラムの検証を実行し、検査式による検査結果を保持または出力する制御装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ソフトウェアを検証する検証システムおよびそのソフトウェアを搭載した制御装置に関する。

【背景技術】

【0002】

自動車エンジン制御などの制御装置として、中央演算装置、ROM、RAM、入出力信号処理装置などを内蔵したマイクロコントローラ(以下マイコンと表記)が用いられている。マイコンが実行するソフトウェアは制御対象が目的とする制御動作を行うように、一般的には制御処理を行うアプリケーションプログラムと入出力を行うデバイスドライバやオペレーティングシステム（OS）などによって構成されている（例えば、特許文献１参照）。

【0003】

このような制御装置は、車両の制御を行うことで車両乗員の安全性に直接係る制御を行うことから、高い安全性を要求されている（例えば、特許文献２参照）。また、近年制御の高度化と規模の増大に伴い、安全に関わるシステムが第三者から見ても必要とされる高い安全性を満足する開発を行うためには、開発工程のうち検証工程において網羅率のより高い検証を求められており、安全に関わらないシステムと比べて、大きな開発工数を要することが課題となっている。

【0004】

網羅的な検証を可能とする技術として、形式検証技術と呼ばれる技術が近年注目されている。形式検証技術は網羅的な検証が可能となる。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特許第3460593号公報

【特許文献2】特開2002-14839号公報

【非特許文献】

【0006】

【非特許文献1】Edmund Clarke著 ANSI-C Bounded Model Checker User Manual 2006

【非特許文献2】frama-c Value Analysis http://frama-c.com/download/frama-c-value-analysis.pdf

【非特許文献3】Pascal Cuoq他著, Frama-C: A Software Analysis Perspective, in LNCS7504 Software Engineering and Formal Methods, p233

【非特許文献4】Jeffrey E.F. Friedl著, 詳説 正規表現, オライリージャパン

【発明の概要】

【発明が解決しようとする課題】

【0007】

形式検証技術によれば網羅的な検証が可能となるものの、検証対象ソフトウェア規模が増大すると、検証に要する計算時間やメモリ、やディスクなどの計算資源が指数関数的に増大するため検証がし切れなくなるという、状態爆発と呼ばれる問題がある。このため、現実に用いられるソフトウェア全体を一度に検証することは現実的には実現できない。

【0008】

大規模で形式検証適用が困難なソフトウェアを検証するためには、ソフトウェアを小さな検証単位に分割することと、探索範囲となる検証すべき条件を可能な限り限定することが有効である。

【0009】

このため本発明の目的は、大きなソフトウェアを小さな部分に分けて部分毎に検証し、その結果をシステム全体で組み合わせ、部分毎の検証結果を統合しながら検証を進めることにある。

【0010】

また、本発明の他の目的は、検証対象ソフトウェアに存在する条件だけでなく、設計情報としての条件を検証条件に与えることで検証範囲を限定し規模の大きなソフトウェアへの網羅的検証を可能とすることにある。

【課題を解決するための手段】

【0011】

前記目的を実現するために、本発明のソフトウェア検証システムは、入出力に依存関係のある複数の機能を備えた制御プログラムのソースコードを入力し、前記制御プログラムを検証する検査実行部と、前記ソースコードを前記複数の機能単位で複数の検査部位に分割し抽出する検査部位抽出部と、前記複数の検査部位のうち一の検査部位に関する検査結果出力に基づき、連続する次の検査部位の検査範囲を規定する第1の制約式を作成する第1の制約式作成部と、を備え、前記第1の制約式に基づいて前記複数の検査部位を順に検査することを特徴とする。

【発明の効果】

【0012】

上記構成にてソフトウェア検証装置を作成すると、大規模なソフトウェアを小さな単位で分割しながら、ひとつの検証部位の検証結果と設計者が与えた検証条件を次の検証部位に適用していくことにより、状態爆発を抑制しながら大規模なソフトウェアの検証が可能となる。

【図面の簡単な説明】

【0013】

【図1】システムの構成を示した図である。

【図2】装置の構成を示した図である。

【図3】制御装置の構成を示した図である。

【図4】検査式挿入の実行手順を示した図である。

【図5】検査器投入ソフトウェアを示した図である。

【図6】制約式統合の実行手順を示した図である。

【図7】検査式情報を示した図である。

【図8】検査手段実行部、検査器、および検査結果を示した図である。

【図9】検査式出力パターンを示した図である。

【発明を実施するための形態】

【0014】

以下、図面を参照しながら本発明の実施形態について説明する。

【実施例1】

【0015】

(ハードウェア構成)
図1は本発明の実施形態のソフトウェア検証システムの構成を示す構成図である。検査装置（検査ツール）0102はソフトウェア0106を全体を検査することを目的としている。ここでいう検査とは、ソフトウェア0106のソースコードに挿入された検査式で定義される検証範囲内において、ソースコードが取り得る状態を網羅的に探索し、所望の状態になることを検証することをいう。

【0016】

ソフトウェア0106は、例えば図３で後述するような、自動車を制御するコントロールユニットに搭載される制御ソフトウェアである。検査条件設定部0103では、まず検査部位抽出部0110により106から検査対象ソフトウェア0108を一定の検査単位でソフトウェア部品として抽出し、次に検査式挿入部0111により検査式を挿入する。

【0017】

前記検査式は0108中で所定の処理を行う処理部の実行前または実行後に、事前事後条件判定部0107と、判定結果を出力する判定結果出力部0109として挿入する。上述した自動車を制御する制御ソフトウェアの例では、処理部（所定の入力値に対して出力値を演算する処理等）の実行前に、センサ値などの入力値の取り得る値（検証範囲）が事前条件として挿入される。また、事前条件で指定された入力値に対する処理部の出力値の取り得る値（設計値等）が事後条件として挿入される。

【0018】

次に検査実行部0104は検査手段実行部0112により、前記検査式を挿入した前記ソフトウェア部品を検査器投入ソフトウェア0101として検査器0113を用いて網羅的に検証する。

【0019】

検査結果出力部0114は検査器0113から得た検査結果をユーザ或いは出力装置に出力するとともに、要求仕様入力部0105に出力する。

【0020】

要求仕様入力部0105は前記検査結果を制約式入力部0118を用いて第一の制約式として入力する。また検査式入力部0105はユーザから入力した検査式を前記検査式保持部0116に第2の制約式として保持する。制約統合部0117は前記第1の制約式と前記第2の制約式を統合し検査式挿入部に出力する。

【0021】

なお、前記検査単位とはソフトウェアを構成する構成要素を示しており、C言語のひとつの関数が前記単位の一例であるが、その他の粒度に設定することも可能であり、この例に特定されるものではない。

【0022】

図2は本発明を実現するためのシステム構成図である。計算機の演算装置などからなる処理装置301と、ディスク装置やメモリ装置からなる記憶装置302と、モニタ、キーボード、ネットワーク、プリンタなどからなる入出力装置303から構成される。処理装置301には、前記検査部位抽出部305,検査式挿入部306, 検査手段起動部307, 検査結果出力部308、検査式入力部309、制約統合部310,検査式入力部311が配置される。記憶装置には前記、ソフトウェア0106を格納するプログラムコード312、前記検査式保持部313、検査結果格納部314、検査対象ソフトウェア315が配置される。

【0023】

図3は本発明の対象とする制御システムのひとつである自動車エンジン制御システムの構成を示すものである。

【0024】

コントロールユニット301はマイクロコントローラ 302 (CPU)、信号入力回路309、アクチュエータ駆動回路 312、通信回路 311 から構成され、センサ1311、 センサ2 316から信号入力回路309を介して得た外界の情報に基づき、駆動回路310を介してアクチュエータ 314を駆動することで制御を行う。また、一部の信号については通信回路311を介して通信線217から得た他の制御装置316からの入出力を用いて制御処理を行う。

【0025】

前記マイクロコントローラ302は、入力回路 303、演算装置 304、揮発性読み書きメモリ305(RAM)、読み出し専用メモリ306(ROM)、割込み制御装置 307、メモリ保護装置 308、出力回路 309、通信制御装置 310、から構成される。

【0026】

ソフトウェア0106は読み出し専用メモリ306に格納され、マイクロコントローラ302によって実行され、所定の制御処理を行う。

【0027】

(ソフトウェアの処理詳細)
図4aに示すのが、検査部位抽出部の動作である。検査部位抽出部はプログラムコード格納部312からソフトウェア0106のプログラムコードの特定部位を抽出し部分的なプログラム構成要素を出力する部分である。まず抽出を開始する点である抽出始点を検索401し、次に抽出の終点を検索402する。始点から終点に相当するプログラムコードを検査部位として切り出し403、検査式生成部を呼出し404、検査部位として抽出したプログラムコード中に検査式を挿入する。全ての対象モジュールを抽出し終えたか否かを判定405し、全ての対象の抽出を終了していれば動作を終了405する。

【0028】

図4bに示すのが検査式生成部の動作である。検査式生成部は、プログラムコードあるいはプログラムコードの一分を入力し、検査式を挿入したプログラムコードを出力する部分である。検査式格納部313から条件式パターンをそれぞれ入力し、検査式情報を作成し制約統合部310へ格納することが目的である。処理が開始406されると、検査式格納部313から検査式を読み込み407、プログラムコード格納部312からプログラムコードを一行づつ入力する407。読み込んだ部位が検査式を挿入すべき位置か判定する409。挿入部位に該当する場合には、検査式を抽出し410、検査式を生成する411。対象モジュールの読み込みが終端に達っしているか判定し412、終端に達していれば終了413し、対象モジュール全体への検査式挿入判定と挿入が完了するまで繰り返す。

【0029】

図5に示すのが検査器が検査する対象とする検査器投入ソフトウェア0101の例である。検査対象となる検査対象ソフトウェア0108の例が、図5(a)の関数501とその処理内容503、ならびに図5(b)関数505とその処理内容507である。502が事前・事後条件判定部0107の例であり、507によると、符号なし2バイト長の変数"ETH" はソースコードの情報のみからは、0以上65535以下の値を取り得る、と判断できるが、さらに設計上の情報を与えたことにより、0以上50以下の値のみを取り得る、という前提条件を課すことができる。

【0030】

このように変数の取り得る値を限定することにより、検証時の探索範囲を削減することができ、前述の状態爆発を避けることが可能となる。同様に変数 "WTP" は0以上150以下の範囲であることを示している。504は関数501の処理内容503を実行後に満すべき条件を記述した事前・事後条件判定部0107の例である。実行後に変数SINJWが0以上150以下の範囲であることを検査条件として示している。

【0031】

506は関数505に対する事前・事後条件判定部0107の例であり、502に加えて変数"SINJW"が0以上150以下であるという条件が追加されている。これは、504で検証した関数501の事後条件を関数505の事前条件として追加したものであり、関数501と関数505が、その呼出し元関数509から前後順に呼び出されている情報を用いることにより、関数501の次に続く関数505の条件を、関数501の検証結果と事前の設計情報である事前条件502を統合した条件として、制約統合部0117により統合された場合の例である。連続する検査対象の検査結果と設計情報として与えた条件を統合することにより、検査範囲をより限定できる。508は事前・事後条件判定部0107および判定結果出力部0109の例であり、検査を行い違反が見付かった場合にはその情報を出力する。この判定および結果出力は検証時に処理装置301上で実行し入出力装置303から結果を出力する実施形態と、制御装置301上のROM306に搭載するソフトウェアとして実装し、301上で実施し結果を通信線316を介し診断端末314あるいは制御装置315に出力する実施形態がある。自動車等の制御ソフトウェアでは、ある関数の出力結果を用いて続く関数が演算処理を行い、複数の関数が連続して処理を行って機器を制御する場合が多い。本発明では、このように入出力値に依存関係のある連続した関数において、前の関数の検証結果を続く関数の制約式として用いることにより、個々の関数の検証範囲を抑えつつも制御ソフトウェア全体を網羅的に検証することが出来る。

【0032】

図6は制約統合部0117の処理手順である。検査対象ソフトウェアの検査式挿入位置に関する情報を入力する601。挿入位置に関する情報とは、ソフトウェアのソースコードを含むファイル名や行番号、関数などのモジュール名、その実行前、実行後などの具体的な位置を示す情報である。次に検査式格納部0116から第１の検査式を入力する602。次に制約式入力部0118から第2の検査式を入力する603。第2の検査式は、要求仕様入力部0105に入力された制御仕様等に基づいて設定されている。制御仕様としては、例えば自動車の制御ソフトウェアの場合、車両の取り得る状態遷移、車両の外界情報設定値、所定の車載機器が所定の条件で取るべき仕様等である。次に602、603によって入力した各々の検査式について検査式の種別を判定し604、この種別に基づき検査式同士の結合条件を決定する605。最後に605で決定した結合条件を表す条件結合子を用いて検査式を連結し、統合した制約式として出力する606。

【0033】

図7は、検査式格納部0116に格納される検査式情報の例である。0705から0708まで4つの検査式情報の例を示している。各検査式情報は、起動条件0701、条件種別0702、結合子0703、0704条件の項目を含む。起動条件0701は、どのような条件で検査を行うかを定めたものであり、0705の例では指定した関数"INJWCALC" の実行前であることを指定した例である。この他に常に検査する"always" 0706, 0707指定したファイル "module1.c" の指定した行番号 "110"のようなファイル位置の指定 0701 を行う。条件種別0702は、その検査式が常に成り立つ "hold" 0705, 0706, 0707, あるいはその条件が成立してはならないという安全条件 "do not hold" 0708、 を指定する。結合子0703は、複数の検査式を連結する際には何らかの論理演算子で結合する必要があるが、それらの条件には、常に成立するべき仕様や、その条件に陥ってはならない安全仕様などがあり、これらを統合し連接するたには個別に異なるため、これを指定するためのものである。条件0704は、各検査式情報が示す具体的な条件である。

【0034】

図8は検査器0113から出力された検査結果の出力例である。図8(a)801は検査器0113として、非特許文献1に記載のCBMCを利用した場合の検証器の起動および検証結果の例である。801は検証器を起動するコマンドである。803は検証器の出力であり、検証すべき項目が全て正しい結果であったことが得られたことを示している。

【0035】

図8(a)804は検証器に検証した項目を明示的に表示させた出力結果である。0805はその検証項目の一例であり、そのうちの0805は変数 "SINJW" と 変数"rinjw" の加算結果の値が0以上65535以下であることが証明されたことが出力されている。

【0036】

図8(b)は、0808の検査器投入ソフトウェア0101の例を、非特許文献2, 非特許文献3に示す検証器である "frama-c" で検証した際の出力例である。

【0037】

検証の結果変数 "INJW" の取り得る値が0~10であることが示された様子を示している。

【0038】

これらの検査器の出力は検査結果出力部0114により検証支援装置の画面やプリンタなどの入出力装置303から表示させる。また、この出力はつぎの検査単位の検査条件として制約式入力部0118から入力し、制約統合部0117として統合することで、より限定された検査範囲での検査を可能とし、検証時間の短縮や、同一検証環境の計算機資源においてより多くのソフトウェアの検証を可能とすることができる。

【0039】

また、検査器の出力に代えて、コントロールユニット301によって、ソフトウェア0106を実行した時に、ソフトウェア0106に記述された検査式の検査結果をRAM305に保持するようにしてもよい。これにより、車両の運転中に実行された処理結果を機能単位で保持または出力出来て、エラーが生じた際の原因特定に役立てることが出来る。

【0040】

図9は検査式挿入部011の処理フロー図４のステップ411、検査式生成の工程で使用する出力文字列を具体的に記載した例である。挿入する文字列は検査器0113の仕様に依存するため、適切な検査式となる文字列への変換が必要である。図9 901は前記CBMCに適した検査式文字列の生成パターンを示しており、正規表現を用いた記載例である。固定部前半902と可変部903、固定部後半904を指定し、条件を可変部903に埋め込むことにより実際に選択した検査器0113に対応した検査式記述を出力できる。このような正規表現を用いた固定文字列と可変文字列の組み合わせは非特許文献4に示されている。

【0041】

(実施例による効果)
これにより、検証時の検証対象ソフトウェアを入出力値に依存関係のある複数の機能単位で分割し、探索範囲である検証条件を限定することが可能となり、より大規模なソフトウェアに対し、網羅的検証が可能となる。

【符号の説明】

【0042】

０１０２・・・検査装置、０１０３・・・検査条件設定部、０１０４・・・検査実行部、０１０５・・・要求仕様入力部、０１０６・・・ソフトウェア、０１０８・・・検査対象ソフトウェア

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】