JP2009294745A - モデル検証プログラム及びモデル検証装置 - Google Patents

Abstract

【課題】制御モデルが設計ルールに適合するか否かを検証するにあたって、ユーザによる設計ルールの追加を容易にする。
【解決手段】制御モデルが設計ルールに適合するか否かを検証するために用いられるモデル検証プログラムであって、前記制御モデルを構成するモデル構成要素の中から検証対象のプロパティを有するモデル構成要素を抽出するためのプロパティ抽出条件と、前記検証対象のプロパティが設計ルールに適合するか否かを判定するための適合判定式とを含むユーザ定義可能なルールデータに基づいて、前記制御モデルが設計ルールに適合するか否かを検証するモデル検証機能をコンピュータに実現させることを特徴とする。
【選択図】図１

Description

本発明は、モデル検証プログラム及びモデル検証装置に関する。

近年、車両制御用ＥＣＵ(Electric Control Unit)の開発において、制御プログラムの複雑さが増加し、開発効率の向上が求められている。そこで、ブロック図や状態遷移図などの制御モデルを用いて制御仕様の検討を行い、その制御モデルを基にＥＣＵに実装する制御プログラムを自動生成して効率化を図るモデルベース開発が進められている。

モデルベース開発の設計に用いる商用のシミュレーションツールは汎用性が高く、例えば制御仕様を記述した制御モデルによって、ＥＣＵに実装する制御プログラムの自動生成を行う用途では、効率的で品質の高いソースコードを生成する必要があり、制御モデルの機能に制限を設け、制御モデルの品質を高める必要がある。この手法として、制御モデルの設計ガイドラインを定め、その制御モデルが設計ルールに適合するか否かをチェックする方法がある。制御モデルの設計ガイドラインとしては、ＭＡＡＢ Ｓｔｙｌｅ ＧｕｉｄｅやＭＩＳＲＡ ＡＣＧ Ｇｕｉｄｅｌｉｎｅ等、自動車メーカおよび、サプライヤ間で協議の上合意された基本的な制御仕様モデル作成に関する設計ルール集があり、一般公開されている。また、これら設計ガイドラインに適合するか否かを自動的にチェックするため、モデルチェックツールが使用されている。

図１５は、制御モデルが設計ルールに適合するか否かを検証（チェック）するために、従来から一般的に使用されているモデルチェックツールの機能ブロック図である。この図１５において、符号５００は、ユーザが事前に制御モデリングツール（例えばＴｈｅ Ｍａｔｈｗｏｒｋｓ社のＭａｔｌａｂ／Ｓｉｍｕｌｉｎｋ（登録商標））を使用して作成した制御モデルに関するデータ（制御モデルを構成するモデル構成要素や各モデル構成要素が有するプロパティ等）が格納されているモデルデータ格納部である。このモデルデータ格納部５００は、例えばＰＣ（Personal Computer）に備えられている記憶装置（ハードディスク等）内の一記憶領域に形成されているものである。

符号６００は、モデルデータ格納部５００からチェック対象となる制御モデルのプロパティを読み出し、その制御モデルが設計ルールに適合するか否かをチェックするルールチェック処理部である。なお、各設計ルール毎に、制御モデル（プロパティ）がその設計ルールに適合する否かをチェックするための判定プログラムが予め作成されており、ルールチェック処理部６００は、各設計ルールの判定プログラムを順次実行することにより制御モデルのチェックを行う。符号７００は、ルールチェック処理部６００による制御モデルのチェック結果を、表示装置などの出力装置によって外部に出力する一方、チェック結果が「ＮＧ」となったプロパティ（つまり設計ルールに適合しないプロパティ）に対して自動修正を行うチェック結果出力部である。これらルールチェック処理部６００及びチェック結果出力部７００は、ＰＣのＣＰＵ（Central Processing Unit）がモデルチェックツールプログラムを実行することで実現される一機能要素である。

なお、現在商用化されているモデルチェックツールの詳細は下記非特許文献１に開示されており、また、制御モデル及び当該制御モデルから生成した制御プログラムの動的な検査技術に関しては下記特許文献１に開示されている。
The Mathworks社 Model Advisor http://www.cybernet.co.jp/matlab/products/product_listing/simverification/ 特開２００５−２０２９２５号公報

上述したように、従来のモデルチェックツールでは、各設計ルール毎に、制御モデルがその設計ルールに適合する否かをチェックするための判定プログラムが予め作成されており、これら各設計ルールの判定プログラムが順次実行されることによって制御モデルのチェックが行われる。この場合、ユーザ側で新たな設計ルールを追加するには、新たな設計ルールに従って制御モデルを解析しチェックする判定プログラムをユーザ自身が作成する必要がある。このような判定プログラムのカスタマイズを行うことは、ユーザにとって大きな負担となる。

本発明は、上述した事情に鑑みてなされたものであり、制御モデルが設計ルールに適合するか否かを検証するにあたって、ユーザによる設計ルールの追加を容易にすることが可能なモデル検証プログラム及びモデル検証装置を提供することを目的とする。

上記目的を達成するために、本発明は、モデル検証プログラムに係る第１の解決手段として、制御モデルが設計ルールに適合するか否かを検証するために用いられるモデル検証プログラムであって、前記制御モデルを構成するモデル構成要素の中から検証対象のプロパティを有するモデル構成要素を抽出するためのプロパティ抽出条件と、前記検証対象のプロパティが設計ルールに適合するか否かを判定するための適合判定式とを含むユーザ定義可能なルールデータに基づいて、前記制御モデルが設計ルールに適合するか否かを検証するモデル検証機能をコンピュータに実現させることを特徴とする。

また、モデル検証プログラムに係る第２の解決手段として、上記第１の解決手段において、前記モデル検証機能として、前記制御モデルに関するデータが格納されたモデルデータ格納手段から、制御モデルを構成するモデル構成要素と、各モデル構成要素が有するプロパティとの対応関係を表すモデルデータを読み出すモデルデータ読出機能と、前記ルールデータが格納されたルールデータ格納手段から、検証に使用するルールデータを読み出すルールデータ読出機能と、前記ルールデータ読出機能によって読み出されたルールデータに含まれるプロパティ抽出条件に基づき、前記モデルデータ読出機能によって読み出されたモデルデータから検証対象のプロパティを有するモデル構成要素を抽出するプロパティ抽出機能と、前記ルールデータ読出機能によって読み出されたルールデータに含まれる適合判定式に基づいて、前記プロパティ抽出機能によって抽出されたモデル構成要素毎に、検証対象のプロパティが設計ルールに適合するか否かを判定する適合判定機能とを含むことを特徴とする。

また、モデル検証プログラムに係る第３の解決手段として、上記第２の解決手段において、前記プロパティ抽出条件は、抽出対象のプロパティの名称と、抽出比較データと、両者の関係を規定する関係演算子とによって定義されており、前記プロパティ抽出機能は、前記モデルデータ読出機能によって読み出されたモデルデータに含まれるモデル構成要素の内、前記プロパティ抽出条件における抽出対象のプロパティの名称に対応するプロパティの内容と、前記抽出比較データとの関係が前記関係演算子によって規定される関係を満足するモデル構成要素を抽出することを特徴とする。

また、モデル検証プログラムに係る第４の解決手段として、上記第２または第３の解決手段において、前記適合判定式は、検証対象のプロパティの名称と、検証比較データと、両者の関係を規定する関係演算子とによって定義されており、前記適合判定機能は、前記プロパティ抽出機能によって抽出されたモデル構成要素が有するプロパティの内、前記適合判定式における検証対象のプロパティの名称に対応するプロパティの内容と、前記検証比較データとの関係が前記関係演算子によって規定される関係を満足するか否かを判定することにより、検証対象のプロパティが設計ルールに適合するか否かを判定することを特徴とする。

また、モデル検証プログラムに係る第５の解決手段として、上記第２〜第４のいずれかの解決手段において、前記ルールデータには、前記プロパティ抽出条件及び適合判定式の他、前記適合判定機能によって設計ルールに適合しないと判定された検証対象のプロパティを自動修正するための自動修正方法が定義されており、前記モデル検証機能として、前記ルールデータに含まれる自動修正方法に従って、前記適合判定機能によって設計ルールに適合しないと判定された検証対象のプロパティを自動修正するプロパティ修正機能をさらに含むことを特徴とする。

また、モデル検証プログラムに係る第６の解決手段として、上記第５の解決手段において、前記自動修正方法は、検証対象のプロパティの名称及び指定修正データによって定義されており、前記プロパティ修正機能は、前記適合判定機能によって設計ルールに適合しないと判定された検証対象のプロパティの内容を前記指定修正データに自動修正することを特徴とする。

また、モデル検証プログラムに係る第７の解決手段として、上記第２〜第６のいずれかの解決手段において、前記モデル構成要素が有するプロパティには、自己のモデル構成要素に直接関連する標準プロパティの他、自己のモデル構成要素の前段または後段に存在するモデル構成要素のプロパティが拡張プロパティとして含まれており、前記モデルデータ読出機能は、前記モデルデータ格納手段から、制御モデルを構成するモデル構成要素と、各モデル構成要素が有する標準プロパティ及び拡張プロパティを読み出すことを特徴とする。

また、モデル検証プログラムに係る第８の解決手段として、上記第２〜第７のいずれかの解決手段において、前記モデル検証機能として、前記ルールデータの新規入力画面を表示手段に表示させ、前記新規入力画面を介して入力された情報に基づいて、新規のルールデータを作成して前記ルールデータ格納手段に格納するルールデータ作成機能をさらに含むことを特徴とする。

また、モデル検証プログラムに係る第９の解決手段として、上記第２〜第８のいずれかの解決手段において、前記モデル検証機能として、前記ルールデータ格納手段に格納済みのルールデータの内、編集対象のルールデータの編集画面を表示手段に表示させ、前記編集画面を介して入力された編集内容に従って、前記編集対象のルールデータを編集するルールデータ編集機能をさらに含むことを特徴とする。

また、モデル検証プログラムに係る第１０の解決手段として、上記第２〜第９のいずれかの解決手段において、前記モデル検証機能として、出力手段を介し、前記適合判定機能による適合判定結果を、前記プロパティ抽出機能によって抽出したモデル構成要素及び当該モデル構成要素が有するプロパティと対応付けて出力する検証結果出力機能をさらに含むことを特徴とする。

また、モデル検証プログラムに係る第１１の解決手段として、上記第２〜第１０のいずれかの解決手段において、前記モデル検証機能として、出力手段を介して、前記ルールデータ読出機能によって読み出されたルールデータを可視化して出力するルールデータ出力機能をさらに含むことを特徴とする。

また、モデル検証プログラムに係る第１２の解決手段として、上記第２〜第１１のいずれかの解決手段において、前記モデル検証機能として、出力手段を介して、前記モデルデータ読出機能によって読み出されたモデルデータを基に各モデル構成要素のプロパティを可視化して出力するモデルデータ出力機能をさらに含むことを特徴とする。

さらに、本発明では、モデル検証装置に係る解決手段として、制御モデルが設計ルールに適合するか否かを検証するモデル検証装置であって、前記制御モデルを構成するモデル構成要素の中から検証対象のプロパティを有するモデル構成要素を抽出するためのプロパティ抽出条件と、前記検証対象のプロパティが設計ルールに適合するか否かを判定するための適合判定式とを含むルールデータに基づいて、前記制御モデルが設計ルールに適合するか否かを検証するモデル検証手段を備えることを特徴とする。

本発明によれば、制御モデルが設計ルールに適合するか否かを検証するにあたって、新たな設計ルールを追加する場合、ユーザは従来のような複雑な判定プログラムを作成する必要はなく、少なくともプロパティ抽出条件及び適合判定式を含むルールデータを定義するだけで良いため、設計ルールの追加を容易にすることが可能となる。

以下、図面を参照して、本発明の一実施形態について説明する。
図１は、本実施形態に係るモデル検証装置１の機能ブロック図である。本実施形態に係るモデル検証装置１は、例えばＰＣ（Personal Computer）であり、入力装置１０、記憶装置２０、ＣＰＵ（Central Processing Unit）３０、表示装置５０から概略構成されている。なお、本実施形態に係るモデル検証装置１として、車両制御用ＥＣＵ(Electric Control Unit)に実装する制御プログラムのモデルベース開発において、その制御プログラムの基となる制御モデルが設計ルールに適合するか否かを検証するものを例示して説明する。

入力装置１０は、例えばキーボードやマウス等から構成されており、ユーザによる操作入力に応じた信号（以下、操作入力信号と称す）をＣＰＵ３０に出力する。記憶装置２０は、例えばハードディスクであり、モデル検証プログラム２０ａを記憶していると共に、制御モデルに関するデータの格納領域であるモデルデータ格納部２０ｂと、制御モデルの検証に用いられるルールデータの格納領域であるルールデータ格納部２０ｃを有している。
表示装置５０は、例えば液晶ディスプレイ等であり、入力画面や適合判定結果を出力する。

モデル検証プログラム２０ａは、ＣＰＵ３０によって読み出されて実行され、制御モデルが設計ルールに適合するか否かを検証するモデル検証機能をモデル検証装置１に実現させるためのプログラムである。モデルデータ格納部２０ｂには、ユーザが事前に制御モデリングツール（例えばＴｈｅ Ｍａｔｈｗｏｒｋｓ社のＭａｔｌａｂ／Ｓｉｍｕｌｉｎｋ（登録商標））を使用して作成した制御モデルに関するデータ、具体的には制御モデルを構成するモデル構成要素や各モデル構成要素が有するプロパティ等が格納されている。

ここで、制御モデルとは、ブロック図や状態遷移図等を用いて制御仕様を記述したものである。また、モデル構成要素とは、上記ブロック図や状態遷移図を構成するブロック、サブシステム、ライン、ジャンクション、ステート等の要素であり、プロパティとは、それらモデル構成要素の性質を表すデータである。また、本実施形態では、モデル構成要素が有するプロパティとして、自己のモデル構成要素に直接関連するプロパティ（標準プロパティ）と、自己のモデル構成要素の前段または後段に存在するモデル構成要素のプロパティ（拡張プロパティ）とが含まれている。図２（ａ）に標準プロパティの一例を示し、図２（ｂ）に拡張プロパティの一例を示す。

ルールデータ格納部２０ｃには、ルールタイトル、プロパティ抽出条件、適合判定式及び自動修正方法を１組とするルールデータが格納されている。図３（ａ）に、ルールデータのフォーマット例を示す。図３（ａ）に示すように、ルールタイトルは、そのルールデータを使用して検証する設計ルールを記述した任意のテキストデータによって定義されている。

プロパティ抽出条件は、制御モデルを構成するモデル構成要素の中から検証対象のプロパティを有するモデル構成要素を抽出するための条件を記述したデータであり、抽出対象のプロパティの名称と、抽出比較データと、これら両者の関係を規定する関係演算子とによって定義されている。ここで、抽出比較データとしては、プロパティの名称や具体的な数値、記号等が使用され、また、関係演算子としては、図３（ｂ）に示すような記号やテキストデータが使用される。

適合判定式は、検証対象のプロパティが設計ルールに適合するか否かを判定するための判定式を記述したデータであり、検証対象のプロパティの名称と、検証比較データと、これら両者の関係を規定する関係演算子とによって定義されている。ここで、プロパティ抽出条件と同様に、検証比較データとしては、プロパティの名称や具体的な数値、記号等が使用され、また、関係演算子としては、図３（ｂ）に示す記号やテキストデータが使用される。

自動修正方法は、設計ルールに適合しないと判定された検証対象のプロパティを自動修正するための修正方法を記述したデータであり、検証対象のプロパティの名称及び指定修正データによって定義されている。ここで、指定修正データとしては、プロパティの名称や具体的な数値、記号等が使用される。また、検証対象のプロパティが自動修正不可能な種類であれば、この自動修正方法の定義データを空欄、または「修正無し」等のテキストデータを用いることにより、自動修正が実行されないようにすることができる。

上記のようなルールタイトル、プロパティ抽出条件、適合判定式及び自動修正方法を含むルールデータが、検証すべき設計ルールの数に応じて複数作成されており、予めルールデータ格納部２０ｃに格納されている。また、ユーザは本モデル検証装置１のルールデータ作成機能（ＣＰＵ３０におけるルールデータ作成部４５）を用いて、任意に新規のルールデータを作成・追加することができる。

なお、図３（ａ）では、１組のルールデータにおいて、プロパティ抽出条件と適合判定式がそれぞれ１つだけ定義されている場合を例示しているが、異なるプロパティ抽出条件を複数定義して各プロパティ抽出条件のＡＮＤまたはＯＲを取ったり、異なる適合判定式を複数定義して各適合判定式のＡＮＤまたはＯＲを取るようにルールデータのフォーマットを変更しても良い。また、自動修正方法についても、１つだけでなく複数定義可能なフォーマットとしても良い。

ＣＰＵ３０は、記憶装置２０に記憶されているモデル検証プログラム２０ａ及び入力装置１０から入力される操作入力信号に従って、モデル検証装置１の全体動作を統括的に制御する。なお、記憶装置２０には不図示のＯＳ(Operation System)プログラムやアプリケーションプログラムが記憶されており、ＣＰＵ３０はこのＯＳプログラムを実行することにより、モデル検証プログラム２０ａを実行可能としている。

より具体的には、ＣＰＵ３０が記憶装置２０に記憶されているモデル検証プログラム２０ａを読み出して実行することにより、制御モデルが設計ルールに適合するか否かを検証するモデル検証機能を有するモデル検証部４０が実現される。このモデル検証部４０には、その機能要素として、モデルデータ読出部４１、ルールチェック処理部４２、チェック結果出力部４３、自動修正部４４及びルールデータ作成部４５が含まれる。さらに、ルールチェック処理部４２には、その機能要素として、ルールデータ読出部４２ａ、プロパティ抽出部４２ｂ及び適合判定部４２ｃが含まれる。

モデルデータ読出部４１は、記憶装置２０のモデルデータ格納部２０ｂから、検証対象の制御モデルを構成するモデル構成要素と、各モデル構成要素が有するプロパティ（汎用プロパティ及び拡張プロパティを含む）との対応関係を表すモデルデータを読み出し、その読み出したモデルデータを基に、図５（ｂ）の例のような行方向にモデル構成要素、列方向にプロパティを２次元配列したプロパティ表を作成する。

ルールチェック処理部４２のルールデータ読出部４２ａは、記憶装置２０のルールデータ格納部２０ｃから、検証に使用するルールデータを読み出す。プロパティ抽出部４２ｂは、ルールデータ読出部４２ａによって読み出されたルールデータに含まれるプロパティ抽出条件に基づいて、モデルデータ読出部４１によって作成されたプロパティ表から検証対象のプロパティを有するモデル構成要素を抽出する。適合判定部４２ｃは、ルールデータ読出部４２ａによって読み出されたルールデータに含まれる適合判定式に基づいて、プロパティ抽出部４２ｃによって抽出されたモデル構成要素毎に、検証対象のプロパティが設計ルールに適合するか否かを判定する。

チェック結果出力部４３は、プロパティ抽出部４２ｂによって抽出したモデル構成要素及び当該モデル構成要素が有するプロパティと対応付けて、図６（ｃ）の例のような適合判定結果（つまり制御モデルの検証結果）を表示させる。自動修正部４４は、ルールデータに含まれる自動修正方法に従って、適合判定部４２ｃによって設計ルールに適合しないと判定された検証対象のプロパティを自動修正する。

ルールデータ作成部４４は、ルールデータ作成を行う為のＧＵＩ（グラフィカルユーザインタフェース）等であり、表示装置５０にルールデータの新規入力画面を表示させ、新規入力画面を介して入力された情報に基づいて、新規のルールデータを作成してルールデータ格納部２０ｃに追加する。この他、ルールデータ格納部２０ｃに格納済みのルールデータの内、編集対象のルールデータの編集画面を表示装置５０に表示させ、その編集画面を介して入力された編集内容に従って、編集対象のルールデータを編集するルールデータ編集機能を設けるようにしても良い。

次に、上記のように構成されたモデル検証装置１において、ＣＰＵ３０がモデル検証プログラム２０ａを実行することで実現されるモデル検証部４０の動作について図４〜図１４を参照して説明する。

図４は、モデル検証部４０の動作を表すフローチャートである。図４に示すように、まず、モデルデータ読出部４１は、ユーザから入力装置１０を介して指定された検証対象の制御モデルのモデルデータを、記憶装置２０のモデルデータ格納部２０ａから読み出し、
その読み出したモデルデータを基に、図５（ｂ）のような行方向にモデル構成要素、列方向にプロパティを２次元配列したプロパティ表を作成する（ステップＳ１）。

図５（ａ）は検証対象の制御モデルの一例であり、図５（ｂ）は図５（ａ）に示す制御モデルより抽出したプロパティ表の一例である。図５（ａ）に示すように、検証対象の制御モデルは、モデル構成要素として、ブロック「Ｉｎ１」、「Ｏｕｔ１」、「Ｃｏｎｓｔａｎｔ」、「Ｃｏｎｓｔａｎｔ１」、「Ｓｕｍ」、「Ｓｗｉｔｃｈ１」、「ＵｎｉｔＤｅｌａｙ」から構成されるブロック図によって記述されているものとする。このような制御モデルについて作成されたプロパティ表では、図５（ｂ）に示すように、行方向にモデル構成要素（制御モデルの階層とブロック名）が配列され、列方向に各モデル構成要素が有するプロパティ「ｂｌｏｃｋｔｙｐｅ（ブロックのタイプ）」、「Ｏｕｔｐｕｔ．ｔｙｐｅ（ブロック出力の演算型）」、「ｉｎｉｔｉａｌ（初期値）」が配列される。

つまり、図５（ｂ）のプロパティ表から、ブロック名「Ｉｎ１」は、プロパティ「ｂｌｏｃｋｔｙｐｅ＝Ｉｎｐｏｒｔ（入力端子）」、「Ｏｕｔｐｕｔ．ｔｙｐｅ＝“−”（プロパティ無し）」、「ｉｎｉｔｉａｌ＝“−”」のブロックであることがわかる（記号“−”は プロパティが存在しないことを表し、設定値無し“ ”と区別するために用いている）。また、ブロック名「Ｏｕｔ１」は、プロパティ「ｂｌｏｃｋｔｙｐｅ＝Ｏｕｔｐｏｒｔ（出力端子）」、「Ｏｕｔｐｕｔ．ｔｙｐｅ＝“−”」、「ｉｎｉｔｉａｌ＝“−”」のブロックであることがわかる。また、ブロック名「Ｃｏｎｓｔａｎｔ」及び「Ｃｏｎｓｔａｎｔ１」は、プロパティ「ｂｌｏｃｋｔｙｐｅ＝Ｃｏｎｓｔａｎｔ（定数）」、「Ｏｕｔｐｕｔ．ｔｙｐｅ＝“−”（プロパティ無し）」、「ｉｎｉｔｉａｌ＝“−”」のブロックであることがわかる。

また、ブロック名「Ｓｕｍ」は、プロパティ「ｂｌｏｃｋｔｙｐｅ＝Ｓｕｍ（加算）」、「Ｏｕｔｐｕｔ．ｔｙｐｅ＝ＵＩｎｔ１６」、「ｉｎｉｔｉａｌ＝“−”」のブロックであることがわかる。また、ブロック名「Ｓｗｉｔｃｈ」は、プロパティ「ｂｌｏｃｋｔｙｐｅ＝Ｓｗｉｔｃｈ（スイッチ）」、「Ｏｕｔｐｕｔ．ｔｙｐｅ＝ＵＩｎｔ１６」、「ｉｎｉｔｉａｌ＝“−”」のブロックであることがわかる。また、ブロック名「ＵｎｉｔＤｅｌａｙ」は、プロパティ「ｂｌｏｃｋｔｙｐｅ＝ＵｎｉｔＤｅｌａｙ（遅延）」、「Ｏｕｔｐｕｔ．ｔｙｐｅ＝ＵＩｎｔ１６」、「ｉｎｉｔｉａｌ＝“０”」のブロックであることがわかる。

なお、上記のようなモデル構成要素が有するプロパティを可視化したプロパティ表を、表示装置５０に表示させるモデルデータ出力機能をモデル検証部４０の一機能要素として設けても良い。このようなモデルデータ出力機能を設けることにより、ユーザは現在検証中の制御モデルの構成や各モデル構成要素が有するプロパティを視覚的に容易に把握することができる。

続いて、ルールチェック処理部４２のルールデータ読出部４２ａは、記憶装置２０のルールデータ格納部２０ｃに格納されているルールデータの内、予め設定されている使用順序がｉ番目（ｉの初期値は「１」）のルールデータを読み出す（ステップＳ２）。そして、プロパティ抽出部４２ｂは、ルールデータ読出部４２ａにて読み出されたルールデータに含まれるプロパティ抽出条件に基づいて、モデルデータ読出部４１にて作成されたプロパティ表から検証対象のプロパティを有するモデル構成要素を抽出する（ステップＳ３）。

そして、適合判定部４２ｃは、ルールデータ読出部４２ａにて読み出されたルールデータに含まれる適合判定式に基づいて、プロパティ抽出部４２ｂにて抽出されたモデル構成要素毎に、検証対象のプロパティが設計ルールに適合するか否かを判定する（ステップＳ４）。チェック結果出力部４３は、適合判定部４２ｃによる適合判定結果を、プロパティ抽出部４２ｂによって抽出したモデル構成要素及び当該モデル構成要素が有するプロパティと対応付けて表示するための画像データを生成し、この画像データを表示装置５０に出力することにより、表示装置５０を介して適合判定結果（つまり制御モデルの検証結果）を表示させる（ステップＳ５）。さらに、自動修正部４４は、ルールデータに含まれる自動修正方法に従って、適合判定部４２ｃによって設計ルールに適合しないと判定された検証対象のプロパティを自動修正する（ステップＳ６）。

そして、ルールチェック処理部４２は、現在使用しているｉ番目のルールデータが最終番目である否か（ｉ＝Ｎか否か）を判定し（ステップＳ７）、ｉ＝Ｎではない場合（「Ｎｏ」）、ステップＳ２の処理に戻り、次番目（ｉ＋１番目）のルールデータを使用して、制御モデルが別の設計ルールに適合するか否かを検証する一方、ｉ＝Ｎの場合（「Ｙｅｓ」）、モデル検証動作を終了する。
以下、上記のステップＳ３〜Ｓ６の処理について具体例を挙げて詳細に説明する。

＜具体例１＞
図６（ａ）は、本具体例１において検証対象として選択した制御モデル（ブロック図で記述したモデル）であり、図６（ｂ）は、本具体例１において検証に使用するルールデータであり、図６（ｃ）は、本具体例１における適合判定結果の表示例を示すものである。図６（ａ）に示すように、本具体例１における制御モデルとして、プロパティ「ｔｙｐｅ（モデル構成要素の種別）」が「“ｂｌｏｃｋ”（ブロック）」であり、その他のプロパティ「ｆｏｎｔｎａｍｅ（フォント名）」、「ｆｏｎｔｓｉｚｅ（フォントサイズ）」を有する「ｉｎ」、「ｏｕｔ」、「定数」、「Ｓｕｍ」という４つのブロックから構成されたモデルを想定する。また、図６（ｂ）に示すように、本具体例１において使用するルールデータは、「ルールタイトル」に記述されているように「ブロックのフォントは“Ａｒｉａｌ”１０ｐｔである」という設計ルールに適合するか否かを検証するためのものである。

ルールデータのプロパティ抽出条件は、抽出対象のプロパティの名称として「ｔｙｐｅ」、抽出比較データとして「“ｂｌｏｃｋ”」、これら両者の関係を規定する関係演算子として「と等しい（＝）」が設定されているものとする。この場合、上記ステップＳ３では、制御モデルからプロパティ「ｔｙｐｅ」が「“ｂｌｏｃｋ”」と等しいモデル構成要素が抽出されることになる。つまり、図６（ｃ）に示すように、制御モデルを構成する全てのブロック「ｉｎ」、「ｏｕｔ」、「定数」、「Ｓｕｍ」が抽出される。

一方、適合判定式は、検証対象のプロパティの名称として「ｆｏｎｔｎａｍｅ」、検証比較データとして「“Ａｒｉａｌ”」、これら両者の関係を規定する関係演算子として「と等しい（＝）」が設定されている第１判定式と、検証対象のプロパティの名称として「ｆｏｎｔｓｉｚｅ」、検証比較データとして「１０」、これら両者の関係を規定する関係演算子として「と等しい（＝）」が設定されている第２判定式との２つの判定式のＡＮＤ（「且つ」）を取るように定義されているものとする。

この場合、ステップＳ４では、ステップＳ３で抽出されたモデル構成要素「ｉｎ」、「ｏｕｔ」、「定数」、「Ｓｕｍ」の内、プロパティ「ｆｏｎｔｎａｍｅ」が「“Ａｒｉａｌ”」と等しく、且つ「ｆｏｎｔｓｉｚｅ」が「１０」と等しいものは「ＯＫ（設計ルールに適合する）」と判定され、そうでないものは「ＮＧ（設計ルールに適合しない）」と判定される。つまり、図６（ｃ）に示すように、プロパティ「ｆｏｎｔｎａｍｅ」が「“ＭＳゴシック”」であるブロック「定数」が「ＮＧ」と判定されることになる。

ステップＳ５では、図６（ｃ）に示すように、適合判定結果がプロパティ抽出部４２ｂによって抽出したモデル構成要素及び当該モデル構成要素が有するプロパティと対応付けられて表示される。なお、ステップＳ２で読み出したルールデータを、図６（ｂ）に示すように可視化して表示装置５０に表示させるルールデータ出力機能をモデル検証部４０の一機能要素として設けても良い。このように適合判定結果と共に、検証に使用したルールデータを表示することにより、ユーザに対して設計ルールの自動チェック方法を明示することができ、ユーザはチェック過程の仕組みを容易に理解することができるようになる。

さらに、図６（ｂ）に示すように、ルールデータの自動修正方法は、検証対象のプロパティの名称として「ｆｏｎｔｎａｍｅ」、指定修正データとして「“Ａｒｉａｌ”」が設定されている第１修正方法と、検証対象のプロパティの名称として「ｆｏｎｔｓｉｚｅ」、指定修正データとして「１０」が設定されている第２修正方法との２つの修正方法によって定義されている。すなわち、ステップＳ６では、「ＮＧ」と判定されたブロック「定数」のプロパティ「ｆｏｎｔｎａｍｅ」が「“ＭＳゴシック”」から「“Ａｒｉａｌ”」に自動修正されることになる。

＜具体例２＞
図７（ａ）は、本具体例２において検証対象として選択した制御モデル（ブロック図で記述したモデル）であり、図７（ｂ）は、本具体例２において検証に使用するルールデータであり、図７（ｃ）は、本具体例２における適合判定結果の表示例を示すものである。図７（ａ）に示すように、本具体例２における制御モデルは、プロパティ「ｂｌｏｃｋｔｙｐｅ（ブロックの種類）＝“Ｓｗｉｔｃｈ”」、及びプロパティ「Ｏｕｔｐｕｔ．ｔｙｐｅ（出力演算型）＝Ｉｎｔ１６」を有するブロック「Ｓｗｉｔｃｈ１」と「Ｓｗｉｔｃｈ２」をモデル構成要素として含んでいる。

なお、ブロック「Ｓｗｉｔｃｈ１」の前段には、「Ｏｕｔｐｕｔ．ｔｙｐｅ＝Ｉｎｔ１６」のブロック「Ｇａｉｎ」と、「Ｏｕｔｐｕｔ．ｔｙｐｅ＝ＵＩｎｔ１６」のブロック「Ｇａｉｎ１」とが存在するため、ブロック「Ｓｗｉｔｃｈ１」は、拡張プロパティとして「ｐｒｅｏｐｅｒａｔｏｒ．ｏｕｔｐｕｔ．ｔｙｐｅ（前段の演算ブロックの出力演算型）＝｛Ｉｎｔ１６ ＵＩｎｔ１６｝」を有している。また、ブロック「Ｓｗｉｔｃｈ２」の前段には、「Ｏｕｔｐｕｔ．ｔｙｐｅ＝Ｉｎｔ１６」のブロック「Ｇａｉｎ」と、ブロック「Ｓｕｂｓｙｓｔｅｍ（サブシステム）」内における「Ｏｕｔｐｕｔ．ｔｙｐｅ＝Ｉｎｔ１６」のブロック「Ｇａｉｎ」とが存在するため、ブロック「Ｓｗｉｔｃｈ２」は、拡張プロパティとして「ｐｒｅｏｐｅｒａｔｏｒ．ｏｕｔｐｕｔ．ｔｙｐｅ＝｛Ｉｎｔ１６ Ｉｎｔ１６｝」を有している。

図７（ｂ）に示すように、本具体例２において使用するルールデータは、「ルールタイトル」に記述されているように「Ｓｗｉｔｃｈブロックの出力演算型は、入力される演算型と一致する」という設計ルールに適合するか否かを検証するためのものである。ルールデータのプロパティ抽出条件は、抽出対象のプロパティの名称として「ｂｌｏｃｋｔｙｐｅ」、抽出比較データとして「“Ｓｗｉｔｃｈ”」、これら両者の関係を規定する関係演算子として「と等しい（＝）」が設定されているものとする。この場合、上記ステップＳ３では、制御モデルからプロパティ「ｂｌｏｃｋｔｙｐｅ」が「“Ｓｗｉｔｃｈ”」と等しいモデル構成要素が抽出されることになる。つまり、図７（ｃ）に示すように、制御モデルを構成するモデル構成要素の内、ブロック「Ｓｗｉｔｃｈ１」及び「Ｓｗｉｔｃｈ２」が抽出される。

一方、適合判定式は、検証対象のプロパティの名称として「ｐｒｅｏｐｅｒａｔｏｒ．ｏｕｔｐｕｔ．ｔｙｐｅ」、検証比較データとして「ｏｕｔｐｕｔ．ｔｙｐｅ」、これら両者の関係を規定する関係演算子として「と等しい（＝）」が設定されているものとする。この場合、ステップＳ４では、抽出されたモデル構成要素の内、プロパティ「ｐｒｅｏｐｅｒａｔｏｒ．ｏｕｔｐｕｔ．ｔｙｐｅ」が「ｏｕｔｐｕｔ．ｔｙｐｅ」と等しいものは「ＯＫ」と判定され、そうでないものは「ＮＧ」と判定される。つまり、図７（ｃ）に示すように、拡張プロパティ「ｐｒｅｏｐｅｒａｔｏｒ．ｏｕｔｐｕｔ．ｔｙｐｅ＝｛Ｉｎｔ１６ ＵＩｎｔ１６｝」であるブロック「Ｓｗｉｔｃｈ１」が「ＮＧ」と判定されることになる。

ステップＳ５では、図７（ｃ）に示すように、適合判定結果がプロパティ抽出部４２ｂによって抽出したモデル構成要素及び当該モデル構成要素が有するプロパティと対応付けられて表示される。また、図７（ｂ）に示すように、本具体例２における自動修正方法は、「修正無し」と定義されている。つまり、本具体例２の場合では、ステップＳ６における「ＮＧ」プロパティの自動修正は実施されない。

＜具体例３＞
図８（ａ）は、本具体例３において検証対象として選択した制御モデル（状態遷移図で記述したモデル）であり、図８（ｂ）は、本具体例３において検証に使用するルールデータであり、図８（ｃ）は、本具体例３における適合判定結果の表示例を示すものである。図８（ａ）に示すように、本具体例３における制御モデルは、プロパティ「ｓｆｃｌａｓｓ（状態遷移図の要素の種類）＝“ｊｕｎｃｔｉｏｎ”」を有する６個のジャンクションをモデル構成要素として備えている。また、図８（ｂ）に示すように、本具体例３において使用されるルールデータは、「ルールタイトル」に記述されているように「状態遷移図のジャンクションは、条件のない遷移が必ず１つだけ存在する」という設計ルールに適合するか否かを検証するためのものである。

ルールデータのプロパティ抽出条件は、抽出対象のプロパティの名称として「ｓｆｃｌａｓｓ」、抽出比較データとして「“ｊｕｎｃｔｉｏｎ”」、これら両者の関係を規定する関係演算子として「と等しい（＝）」が設定されている。この場合、上記ステップＳ３では、制御モデルからプロパティ「ｓｆｃｌａｓｓ」が「“ｊｕｎｃｔｉｏｎ”」と等しいモデル構成要素が抽出されることになる。つまり、図８（ｃ）に示すように、制御モデルを構成する全てのジャンクションが抽出される。

一方、適合判定式は、検証対象のプロパティの名称として「ｓｆｏｕｔ．ｃｏｎｄｉｔｉｏｎ（遷移条件：矢印に記述された条件）」、検証比較データとして「“”（条件無し）」、これら両者の関係を規定する関係演算子として「を１つだけ含む」が設定されている。この場合、ステップＳ４では、抽出されたモデル構成要素の内、プロパティ「ｓｆｏｕｔ．ｃｏｎｄｉｔｉｏｎ」が「“”」を１つだけ含むものが「ＯＫ」と判定され、そうでないものは「ＮＧ」と判定される。つまり、図８（ｃ）に示すように、プロパティ「ｓｆｏｕｔ．ｃｏｎｄｉｔｉｏｎ＝｛“〔ｉｎ＝＝１〕” “〔ｉｎ＝＝０〕”｝」であるジャンクションが「ＮＧ」と判定されることになる。

ステップＳ５では、図８（ｃ）に示すように、適合判定結果がプロパティ抽出部４２ｂによって抽出したモデル構成要素及び当該モデル構成要素が有するプロパティと対応付けられて表示される。また、図８（ｂ）に示すように、本具体例３における自動修正方法は、「修正無し」と定義されている。つまり、本具体例３の場合では、ステップＳ６における「ＮＧ」プロパティの自動修正は実施されない。

続いて、車両制御用ＥＣＵのモデルベース開発への適用例について説明する。一般的に、車両制御システムの開発では、ＥＣＵを含めた制御システム全体のシミュレーションモデルをブロック図や状態遷移図を用いて記述し、このシミュレーションモデルをシミュレータに組み込むことにより、制御システムの動作について検証している。シミュレーションモデルは、プラントモデル、センサモデル、アクチュエータモデル等の制御対象モデルと、制御ロジックやフィードバック制御を行う制御仕様モデル（ＥＣＵに相当するモデル）とに分類され、本実施形態のモデル検証装置１における検証対象の制御モデルとは、この制御仕様モデルを指す。

＜適用例１＞
図９は、エアバッグ点火用の衝突判定を行うエアバッグ制御システムのオープンループシミュレーションモデルである。この図９に示すように、エアバッグ制御システムのシミュレーションモデルは、制御対象モデルであるセンサモデル部１００と、制御仕様モデルである衝突判定アルゴリズム部２００とから構成されている。

センサモデル部１００は、車両に作用する加速度を検出するサテライト加速度センサ１０１及びメイン加速度センサ１０２から構成されている。衝突判定アルゴリズム部２００は、ＬＰＦ２０１、ＬＰＦ２０２、セーフィング判定部２０３、中高速衝突判定部２０４、低速衝突判定部２０５、ＯＲ処理部２０６及びＡＮＤ処理部２０７から構成されている。

ＬＰＦ２０１は、サテライト加速度センサ１０１から出力される加速度信号に含まれる高周波ノイズ成分を除去する。ＬＰＦ２０２は、メイン加速度センサ１０２から出力される加速度信号に含まれる高周波ノイズ成分を除去する。セーフィング判定部２０３は、ＬＰＦ２０１から出力される加速度信号の区間積分処理を行うと共に、区間積分値とセーフィング判定閾値とを比較することでセーフィング判定を行う。

中高速衝突判定部２０４は、ＬＰＦ２０２から出力される加速度信号の区間積分処理を行うと共に、区間積分値と中高速衝突判定閾値とを比較することで衝突判定を行う。低速衝突判定部２０５は、ＬＰＦ２０２から出力される加速度信号の累積積分処理を行うと共に、累積積分値と低速衝突判定閾値とを比較することで衝突判定を行う。ＯＲ処理部２０６は、中高速衝突判定部２０４及び低速衝突判定部２０５の衝突判定結果の論理和処理を行う。ＡＮＤ処理部２０７は、セーフィング判定部２０３のセーフィング判定結果とＯＲ処理部２０６の論理和処理結果との論理積処理を行い、論理積処理結果をエアバッグ点火信号として出力する。

図１０は、上記のように構成された衝突判定アルゴリズム部２００を、制御モデリングツールを使用して記述した制御モデルである。図１０の制御モデルにおいて、ブロック「Ｓａｔｅｌｉｔｅ ＬＰＦ」はＬＰＦ２０１に相当し、ブロック「Ｍａｉｎ ＬＰＦ」はＬＰＦ２０２に相当し、ブロック「Ｓａｆｉｎｇ Ｄｅｔｅｃｔｉｏｎ」はセーフィング判定部２０３に相当し、ブロック「ＭｉｄＳｐｅｅｄ Ｄｅｔｅｃｔｉｏｎ」は中高速衝突判定部２０４に相当し、ブロック「ＬｏｗＳｐｅｅｄ Ｄｅｔｅｃｔｉｏｎ」は低速衝突判定部２０５に相当し、ブロック「Ｌｏｇｉｃａｌ Ｏｐｅｒａｔｏｒ」はＯＲ処理部２０６に相当し、ブロック「Ｌｏｇｉｃａｌ Ｏｐｅｒａｔｏｒ１」はＡＮＤ処理部２０７に相当する。

また、図１０において、ブロック「Ｓａｔ＿Ｇ」は、サテライト加速度センサ１０１の加速度信号を入力とする入力ポート（プロパティ「ｂｌｏｃｋｔｙｐｅ＝Ｉｎｐｏｒｔ」）である。ブロック「Ｍａｉｎ＿Ｇ」は、メイン加速度センサ１０２の加速度信号を入力とする入力ポートである。ブロック「ＦｉｒｅＦｌａｇ」は、ブロック「Ｌｏｇｉｃａｌ Ｏｐｅｒａｔｏｒ１」の論理積処理結果（ＦｉｒｅＦｌａｇ）を出力する出力ポート（プロパティ「ｂｌｏｃｋｔｙｐｅ＝Ｏｕｔｐｏｒｔ」）である。

ブロック「Ｓａｆｉｎｇ Ｄｅｔｅｃｔｉｏｎ」、「ＭｉｄＳｐｅｅｄ Ｄｅｔｅｃｔｉｏｎ」及び「ＬｏｗＳｐｅｅｄ Ｄｅｔｅｃｔｉｏｎ」は、積分処理と閾値比較判定処理を行うサブシステムブロックであり、図１０では、「ＬｏｗＳｐｅｅｄ Ｄｅｔｅｃｔｉｏｎ」の内部ブロック構成を代表的に図示している。すなわち、「ＬｏｗＳｐｅｅｄ Ｄｅｔｅｃｔｉｏｎ」は、「ＭａｉｎＬＰＦ＿Ｇ」、「Ｃｏｎｓｔａｎｔ」、「Ｓｕｍ１」、「積分」、「Ｕｎｉｔ Ｄｅｌａｙ」、「Ｓａｔｕｒａｔｉｏｎ」、「Ｃｏｎｓｔａｎｔ１」、「Ｒｅｌａｔｉｏｎａｌ Ｏｐｅｒａｔｏｒ」、「ＬｏｗＦｌａｇ」のブロックから構成されている。

図１１（ａ）は、本適用例１において検証に使用するルールデータであり、図１１（ｂ）は、本適用例１における適合判定結果の表示例を示すものである。図１１（ａ）に示すように、本適用例１において使用するルールデータは、図６（ｂ）に示すルールデータと同じものである。従って、ステップＳ３では、図１０に示す制御モデルからプロパティ「ｔｙｐｅ」が「“ｂｌｏｃｋ”」と等しいモデル構成要素が抽出されることになる。この場合、図１０に示す制御モデルを構成する全てのモデル構成要素が抽出されるが、説明の都合上、図１１（ｂ）では、「ＬｏｗＳｐｅｅｄ Ｄｅｔｅｃｔｉｏｎ」と、その内部のモデル構成要素「ＭａｉｎＬＰＦ＿Ｇ」、「Ｃｏｎｓｔａｎｔ」、「Ｓｕｍ１」、「積分」、「Ｕｎｉｔ Ｄｅｌａｙ」、「Ｓａｔｕｒａｔｉｏｎ」、「Ｃｏｎｓｔａｎｔ１」、「Ｒｅｌａｔｉｏｎａｌ Ｏｐｅｒａｔｏｒ」、「ＬｏｗＦｌａｇ」のみを抽出結果として図示している。

また、ステップＳ４では、ステップＳ３で抽出されたモデル構成要素の内、プロパティ「ｆｏｎｔｎａｍｅ」が「“Ａｒｉａｌ”」と等しく、且つ「ｆｏｎｔｓｉｚｅ」が「１０」と等しいものは「ＯＫ」と判定され、そうでないものは「ＮＧ」と判定される。つまり、図１１（ｂ）に示すように、プロパティ「ｆｏｎｔｎａｍｅ」が「“ＭＳゴシック”」であるブロック「積分」が「ＮＧ」と判定されることになる。

＜適用例２＞
図１２は、エンジン燃料噴射の空燃比フィードバック制御を行うエンジン制御システムのクローズドループシミュレーションモデルである。この図１２に示すように、エンジン制御システムのシミュレーションモデルは、制御対象モデルであるエンジンモデル部３００と、制御仕様モデルである燃料噴射制御部４００とから構成されている。

エンジンモデル部３００は、エンジン３０１と、エンジン３０１の回転数を検出する回転センサ３０２と、エンジン１の吸入空気量を検出するエアフローメータ３０３と、エンジン１の排気ガスを清浄化するための触媒３０４と、触媒３０４を通過した排気ガスから空燃比を検出するＡ／Ｆセンサ３０５とから構成されている。

燃料噴射制御部４００は、基本燃料噴射量演算部４０１、空燃比フィードバック制御部４０２及び加算処理部４０３から構成されている。基本燃料噴射量演算部４０１は、回転センサ３０２にて検出された回転数及びエアフローメータ３０３にて検出された吸入空気量に基づいて基本燃料噴射量を算出する。空燃比フィードバック制御部４０２は、Ａ／Ｆセンサ３０５にて検出された空燃比が目標空燃比と一致するようにフィードバック制御（例えばＰＩＤ制御）を行う。加算処理部４０３は、基本燃料噴射量演算部４０１にて算出された基本燃料噴射量と、空燃比フィードバック制御部４０２におけるＰＩＤ演算によって算出された燃料噴射量とを加算し、その加算値を燃料噴射量の最終的な制御量としてエンジン１に出力する。

図１３は、上記のように構成された燃料噴射制御部４００を、制御モデリングツールを使用して記述した制御モデルである。図１３の制御モデルにおいて、ブロック「Ｅｓｔｉｍａｔｅ Ｂａｓｉｃ Ｆｕｅｌ Ｖｏｌ」は基本燃料噴射量演算部４０１に相当し、ブロック「ＡＦ ｒａｔｉｏ Ｃｏｎｔｒｏｌ」は空燃比フィードバック制御部４０２に相当し、ブロック「Ｓｕｍ」は加算処理部４０３に相当する。

また、図１３において、ブロック「Ａｉｒ＿Ｖｏｌ」は、エアフローメータ３０３にて検出された吸入空気量を入力とする入力ポート（プロパティ「ｂｌｏｃｋｔｙｐｅ＝Ｉｎｐｏｒｔ」）である。ブロック「Ｎｅ」は、回転センサ３０２にて検出された回転数を入力とする入力ポートである。ブロック「ＡＦ」は、Ａ／Ｆセンサ３０５にて検出された空燃比を入力とする入力ポートである。ブロック「Ｆｕｅｌ Ｖｏｌ」は、ブロック「Ｓｕｍ」の加算値を出力する出力ポート（プロパティ「ｂｌｏｃｋｔｙｐｅ＝Ｏｕｔｐｏｒｔ」）である。

ブロック「Ｅｓｔｉｍａｔｅ Ｂａｓｉｃ Ｆｕｅｌ Ｖｏｌ」及び「ＡＦ ｒａｔｉｏ Ｃｏｎｔｒｏｌ」はサブシステムブロックであり、図１３では、「ＡＦ ｒａｔｉｏ Ｃｏｎｔｒｏｌ」の内部ブロック構成を代表的に図示している。すなわち、「ＡＦ ｒａｔｉｏ Ｃｏｎｔｒｏｌ」は、プロパティ「ｂｌｏｃｋｔｙｐｅ＝“Ｕｎｉｔ Ｄｅｌａｙ”」及びプロパティ「Ｏｕｔｐｕｔ．ｔｙｐｅ＝ＵＩｎｔ１６」を有するブロック「Ｕｎｉｔ Ｄｅｌａｙ」と、プロパティ「ｂｌｏｃｋｔｙｐｅ＝“Ｕｎｉｔ Ｄｅｌａｙ”」及びプロパティ「Ｏｕｔｐｕｔ．ｔｙｐｅ＝Ｉｎｔ１６」を有するブロック「Ｕｎｉｔ Ｄｅｌａｙ１」とをモデル構成要素として含んでいる。

なお、ブロック「Ｕｎｉｔ Ｄｅｌａｙ」の前段には、「Ｏｕｔｐｕｔ．ｔｙｐｅ＝Ｉｎｔ１６」のブロック「Ｓｕｍ１」が存在するため、ブロック「Ｕｎｉｔ Ｄｅｌａｙ」は、拡張プロパティとして「ｐｒｅｏｐｅｒａｔｏｒ．ｏｕｔｐｕｔ．ｔｙｐｅ＝Ｉｎｔ１６」を有している。また、ブロック「Ｕｎｉｔ Ｄｅｌａｙ１」の前段には、「Ｏｕｔｐｕｔ．ｔｙｐｅ＝Ｉｎｔ１６」のブロック「Ｓｕｍ」が存在するため、ブロック「Ｕｎｉｔ Ｄｅｌａｙ１」は、拡張プロパティとして「ｐｒｅｏｐｅｒａｔｏｒ．ｏｕｔｐｕｔ．ｔｙｐｅ＝Ｉｎｔ１６」を有している。

図１４（ａ）は、本適用例２において検証に使用するルールデータであり、図１４（ｂ）は、本適用例２における適合判定結果の表示例を示すものである。図１４（ａ）に示すように、本適用例２において使用するルールデータは、「ルールタイトル」に記述されているように「Ｕｎｉｔ Ｄｅｌａｙブロックの出力演算型は、入力される演算型と一致する」という設計ルールに適合するか否かを検証するためのものである。ルールデータのプロパティ抽出条件は、抽出対象のプロパティの名称として「ｂｌｏｃｋｔｙｐｅ」、抽出比較データとして「“Ｕｎｉｔ Ｄｅｌａｙ”」、これら両者の関係を規定する関係演算子として「と等しい（＝）」が設定されているものとする。この場合、図１４（ｂ）に示すように、サブシステムブロック「ＡＦ ｒａｔｉｏ Ｃｏｎｔｒｏｌ」からブロック「Ｕｎｉｔ Ｄｅｌａｙ」及び「Ｕｎｉｔ Ｄｅｌａｙ１」が抽出されることになる。

一方、適合判定式は、検証対象のプロパティの名称として「ｐｒｅｏｐｅｒａｔｏｒ．ｏｕｔｐｕｔ．ｔｙｐｅ」、検証比較データとして「ｏｕｔｐｕｔ．ｔｙｐｅ」、これら両者の関係を規定する関係演算子として「と等しい（＝）」が設定されているものとする。この場合、抽出されたモデル構成要素の内、プロパティ「ｐｒｅｏｐｅｒａｔｏｒ．ｏｕｔｐｕｔ．ｔｙｐｅ」が「ｏｕｔｐｕｔ．ｔｙｐｅ」と等しいものが「ＯＫ」と判定され、そうでないものは「ＮＧ」と判定される。つまり、図１４（ｂ）に示すように、ブロック「Ｕｎｉｔ Ｄｅｌａｙ１」が「ＮＧ」と判定されることになる。

以上のように、本実施形態に係るモデル検証装置１によれば、制御モデルが設計ルール
に適合するか否かを検証するにあたって、新たな設計ルールを追加する場合、ユーザは従来のような複雑な判定プログラムを作成する必要はなく、「ルールタイトル」、「プロパティ抽出条件」、「適合判定式」、「自動修正方法」を含むルールデータを定義するだけで良いため、設計ルールの追加を容易にすることが可能となる。

なお、上記実施形態では、検証対象の制御モデルとして、車両制御用ＥＣＵに実装する制御プログラムの基となる制御モデルを例示して説明したが、このような車両制御に関する制御モデルに限らず、他の制御システムにおいて作成された制御モデルを検証対象とすることも勿論可能である。

本発明の一実施形態に係るモデル検証装置１の機能ブロック図である。 制御モデルを構成するモデル構成要素が有するプロパティ（標準プロパティ、拡張プロパティ）の一例である。 本発明の一実施形態に係るルールデータに関する説明図である。 本発明の一実施形態に係るモデル検証装置１の動作フローチャートである。 本発明の一実施形態に係るモデル検証装置１の動作に関する第１説明図（プロパティ表）である。 本発明の一実施形態に係るモデル検証装置１の動作に関する第２説明図（具体例１）である。 本発明の一実施形態に係るモデル検証装置１の動作に関する第３説明図（具体例２）である。 本発明の一実施形態に係るモデル検証装置１の動作に関する第４説明図（具体例３）である。 本発明の一実施形態に係るモデル検証装置１の動作に関する第５説明図（適用例１）である。 本発明の一実施形態に係るモデル検証装置１の動作に関する第６説明図（適用例１）である。 本発明の一実施形態に係るモデル検証装置１の動作に関する第７説明図（適用例１）である。 本発明の一実施形態に係るモデル検証装置１の動作に関する第８説明図（適用例２）である。 本発明の一実施形態に係るモデル検証装置１の動作に関する第９説明図（適用例２）である。 本発明の一実施形態に係るモデル検証装置１の動作に関する第１０説明図（適用例２）である。 従来のモデルチェックツールに関する説明図である。

符号の説明

１…モデル検証装置、１０…入力装置、２０…記憶装置、３０…ＣＰＵ（Central Processing Unit）、５０…表示装置、４０…モデル検証部、４１…モデルデータ読出部、４２…ルールチェック処理部、４３…チェック結果出力部、４４…自動修正部、４５…ルールデータ作成部、４２ａ…ルールデータ読出部、４２ｂ…プロパティ抽出部、４２ｃ…適合判定部、２０ａ…モデル検証プログラム、２０ｂ…モデルデータ格納部、２０ｃ…ルールデータ格納部

Claims (13)

1. 制御モデルが設計ルールに適合するか否かを検証するために用いられるモデル検証プログラムであって、
   前記制御モデルを構成するモデル構成要素の中から検証対象のプロパティを有するモデル構成要素を抽出するためのプロパティ抽出条件と、前記検証対象のプロパティが設計ルールに適合するか否かを判定するための適合判定式とを含むルールデータに基づいて、前記制御モデルが設計ルールに適合するか否かを検証するモデル検証機能をコンピュータに実現させることを特徴とするモデル検証プログラム。
2. 前記モデル検証機能として、
   前記制御モデルに関するデータが格納されたモデルデータ格納手段から、制御モデルを構成するモデル構成要素と、各モデル構成要素が有するプロパティとの対応関係を表すモデルデータを読み出すモデルデータ読出機能と、
   前記ルールデータが格納されたルールデータ格納手段から、検証に使用するルールデータを読み出すルールデータ読出機能と、
   前記ルールデータ読出機能によって読み出されたルールデータに含まれるプロパティ抽出条件に基づき、前記モデルデータ読出機能によって読み出されたモデルデータから検証対象のプロパティを有するモデル構成要素を抽出するプロパティ抽出機能と、
   前記ルールデータ読出機能によって読み出されたルールデータに含まれる適合判定式に基づいて、前記プロパティ抽出機能によって抽出されたモデル構成要素毎に、検証対象のプロパティが設計ルールに適合するか否かを判定する適合判定機能と、
   を含むことを特徴とする請求項１記載のモデル検証プログラム。
3. 前記プロパティ抽出条件は、抽出対象のプロパティの名称と、抽出比較データと、両者の関係を規定する関係演算子とによって定義されており、
   前記プロパティ抽出機能は、前記モデルデータ読出機能によって読み出されたモデルデータに含まれるモデル構成要素の内、前記プロパティ抽出条件における抽出対象のプロパティの名称に対応するプロパティの内容と、前記抽出比較データとの関係が前記関係演算子によって規定される関係を満足するモデル構成要素を抽出することを特徴とする請求項２記載のモデル検証プログラム。
4. 前記適合判定式は、検証対象のプロパティの名称と、検証比較データと、両者の関係を規定する関係演算子とによって定義されており、
   前記適合判定機能は、前記プロパティ抽出機能によって抽出されたモデル構成要素が有するプロパティの内、前記適合判定式における検証対象のプロパティの名称に対応するプロパティの内容と、前記検証比較データとの関係が前記関係演算子によって規定される関係を満足するか否かを判定することにより、検証対象のプロパティが設計ルールに適合するか否かを判定することを特徴とする請求項２または３に記載のモデル検証プログラム。
5. 前記ルールデータには、前記プロパティ抽出条件及び適合判定式の他、前記適合判定機能によって設計ルールに適合しないと判定された検証対象のプロパティを自動修正するための自動修正方法が定義されており、
   前記モデル検証機能として、前記ルールデータに含まれる自動修正方法に従って、前記適合判定機能によって設計ルールに適合しないと判定された検証対象のプロパティを自動修正するプロパティ修正機能をさらに含むことを特徴とする請求項２〜４のいずれか一項に記載のモデル検証プログラム。
6. 前記自動修正方法は、検証対象のプロパティの名称及び指定修正データによって定義されており、
   前記プロパティ修正機能は、前記適合判定機能によって設計ルールに適合しないと判定された検証対象のプロパティの内容を前記指定修正データに自動修正することを特徴とする請求項５記載のモデル検証プログラム。
7. 前記モデル構成要素が有するプロパティには、自己のモデル構成要素に直接関連する標準プロパティの他、自己のモデル構成要素の前段または後段に存在するモデル構成要素のプロパティが拡張プロパティとして含まれており、
   前記モデルデータ読出機能は、前記モデルデータ格納手段から、制御モデルを構成するモデル構成要素と、各モデル構成要素が有する標準プロパティ及び拡張プロパティを読み出すことを特徴とする請求項２〜６のいずれか一項に記載のモデル検証プログラム。
8. 前記モデル検証機能として、前記ルールデータの新規入力画面を表示手段に表示させ、前記新規入力画面を介して入力された情報に基づいて、新規のルールデータを作成して前記ルールデータ格納手段に格納するルールデータ作成機能をさらに含むことを特徴とする請求項２〜７のいずれか一項に記載のモデル検証プログラム。
9. 前記モデル検証機能として、前記ルールデータ格納手段に格納済みのルールデータの内、編集対象のルールデータの編集画面を表示手段に表示させ、前記編集画面を介して入力された編集内容に従って、前記編集対象のルールデータを編集するルールデータ編集機能をさらに含むことを特徴とする請求項２〜８のいずれか一項に記載のモデル検証プログラム。
10. 前記モデル検証機能として、出力手段を介し、前記適合判定機能による適合判定結果を、前記プロパティ抽出機能によって抽出したモデル構成要素及び当該モデル構成要素が有するプロパティと対応付けて出力する検証結果出力機能をさらに含むことを特徴とする請求項２〜９のいずれか一項に記載のモデル検証プログラム。
11. 前記モデル検証機能として、出力手段を介して、前記ルールデータ読出機能によって読み出されたルールデータを可視化して出力するルールデータ出力機能をさらに含むことを特徴とする請求項２〜１０のいずれか一項に記載のモデル検証プログラム。
12. 前記モデル検証機能として、出力手段を介して、前記モデルデータ読出機能によって読み出されたモデルデータを基に各モデル構成要素が有するプロパティを可視化して出力するモデルデータ出力機能をさらに含むことを特徴とする請求項２〜１１のいずれか一項に記載のモデル検証プログラム。
13. 制御モデルが設計ルールに適合するか否かを検証するモデル検証装置であって、
    前記制御モデルを構成するモデル構成要素の中から検証対象のプロパティを有するモデル構成要素を抽出するためのプロパティ抽出条件と、前記検証対象のプロパティが設計ルールに適合するか否かを判定するための適合判定式とを含むルールデータに基づいて、前記制御モデルが設計ルールに適合するか否かを検証するモデル検証手段を備えることを特徴とするモデル検証装置。

Images