JP2004027930A

JP2004027930A - 車両用制御装置の評価方法

Info

Publication number: JP2004027930A
Application number: JP2002184155A
Authority: JP
Inventors: Shinichi Soejima; 副島　慎一; Kunihiro Obara; 小原　邦裕; Keisuke Hagiwara; 萩原　啓介; Satoshi Watanabe; 渡辺　智
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2002-06-25
Filing date: 2002-06-25
Publication date: 2004-01-29

Abstract

【課題】本発明は車両用制御装置が仕様を満たしているか否かを検証するための評価方法に関し、その評価を短時間で簡単に実行可能とすることを目的とする。
【解決手段】コンピュータが実行可能な言語（シミュリンク）で仕様書を作成する。その仕様書の内容が実装され、かつ、その内容が実行可能なＲＰＥを用いてＨＩＬＳを準備する（Ｓ１）。ＲＰＥに所定の条件信号を供給してシミュレーションを行い、その結果としてＲＰＥにより生成される基準結果信号を記録する（Ｓ３）。上記仕様書に基づいて作成されたＥＣＵを用いてＨＩＬＳを準備する（Ｓ４）。ＥＣＵに上記の条件信号を供給してシミュレーションを行い、その結果としてＥＣＵにより生成される検証用結果信号を記録する（Ｓ５）。基準結果信号と検証用結果信号とを比較してＥＣＵを評価する（Ｓ６）。
【選択図】　　　　図３

Description

【０００１】
【発明の属する技術分野】
本発明は、車両用制御装置の評価方法に係り、特に、開発の段階で車両用制御装置の機能が仕様を満たしているか否かを検証する方法として好適な評価方法に関する。
【０００２】
【従来の技術】
従来、例えば特開平１１−３２６１３５号公報に開示されるように、仮想的な車両モデルを用いて、シミュレーションにより車両制御装置（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）を評価する方法が知られている。このような評価方法によれば、実車走行を行うことなく、実車走行を行った場合と同等の評価を行うことができ、車両用制御装置の開発効率を高めることができる。
【０００３】
【発明が解決しようとする課題】
シミュレーションによるＥＣＵの評価は、ＥＣＵの開発過程において、そのＥＣＵが仕様書の内容通りに動作するか否かを評価するために用いることができる。このような評価では、具体的には、仕様書に定められた個々の条件について、その条件に対応する信号を試作段階のＥＣＵに入力する処理、および、その結果得られた出力が仕様書の内容に一致しているか否かを判断する処理が実行される。
【０００４】
これらの処理は、何れも評価担当者が手作業で行うことを要する。また、ＥＣＵが仕様通りに機能するか否かを判断するために検証すべき事項を選択したり、その事項を適切に検証するための条件を設定したりする作業には高度の経験が要求される。このため、上述した従来の方法によれば、ＥＣＵが正常に機能しているか否かを評価するために、高度の経験と長い時間が必要とされる。
【０００５】
本発明は、上記のような課題を解決するためになされたもので、車両用制御装置が仕様書の内容通りに機能しているか否かを、短時間で簡単に評価するための評価方法を提供することを目的とする。
【０００６】
【課題を解決するための手段】
第１の発明は、上記の目的を達成するため、車両用制御装置の評価方法であって、
コンピュータが実行可能な言語で仕様書を作成するステップと、
前記仕様書の内容が実装され、かつ、その内容が実行可能な制御装置試作ユニットに所定の条件信号を供給するステップと、
前記条件信号の供給の結果として前記制御装置試作ユニットが生成する基準結果信号を記録するステップと、
前記仕様書に基づいて車両用制御装置を作成するステップと、
前記条件信号を前記車両用制御装置に供給するステップと、
前記条件信号の供給の結果として前記車両用制御装置が生成する検証用結果信号を記録するステップと、
前記基準結果信号と前記検証用結果信号とが一致しているか否かを判断するステップと、
を含むことを特徴とする。
【０００７】
また、第２の発明は、車両用制御装置の評価方法であって、
コンピュータが読み取り可能な言語で仕様書を作成するステップと、
前記仕様書に基づいて車両用制御装置を作成するステップと、
前記仕様書の内容から要検証事項をコンピュータに読み取らせるステップと、前記要検証事項を検証するためのデバッグ条件をコンピュータに作成させるステップと、
前記デバッグ条件に対応する条件信号を生成するステップと、
前記条件信号を用いて前記車両用制御装置の動作を評価するステップと、
を含むことを特徴とする。
【０００８】
また、第３の発明は、第２の発明において、前記車両用制御装置の動作を評価するステップは、
前記条件信号を前記車両用制御装置に供給するステップと、
前記条件信号の供給の結果として前記車両用制御装置が生成する検証用結果信号を計測するステップと、
前記検証用結果信号が、前記仕様書の定める仕様と一致しているか否かを判断するステップと、
を含むことを特徴とする。
【０００９】
また、第４の発明は、第２の発明において、前記車両用制御装置の動作を評価するステップは、
前記条件信号を制御装置試作ユニットに供給するステップと、
前記条件信号の供給の結果として前記制御装置試作ユニットが生成する基準結果信号を記録するステップと、
前記条件信号を前記車両用制御装置に供給するステップと、
前記条件信号の供給の結果として前記車両用制御装置が生成する検証用結果信号を記録するステップと、
前記基準結果信号と前記検証用結果信号とが一致しているか否かを判断するステップと、
を含むことを特徴とする。
【００１０】
また、第５の発明は、第２乃至第４の発明の何れかにおいて、
前記条件信号は、前記車両用制御装置の内部処理により演算されるべきＲＡＭ値を含み、
前記車両用制御装置の動作を評価するステップは、
前記車両用制御装置内部のＲＡＭ値を、前記条件信号に含まれるＲＡＭ値に書き換えるステップと、
書き換えられたＲＡＭ値が、前記車両用制御装置の内部処理により再び書き換えられるのを禁止するステップと、
を含むことを特徴とする。
【００１１】
また、第６の発明は、第１乃至第５の発明の何れかにおいて、前記言語はシミュリンクであることを特徴とする。
【００１２】
また、第７の発明は、第１または第４の発明において、
前記基準結果信号を記録するステップは、当該基準結果信号をコンピュータに記録させるステップを含み、
前記検証用結果信号を記録するステップは、当該検証用結果信号をコンピュータに記録させるステップを含み、
前記基準結果信号と前記検証用結果信号とが一致しているか否かを判断するステップは、当該判断をコンピュータに実行させるステップを含むことを特徴とする。
【００１３】
また、第８の発明は、第３の発明において、前記検証用結果信号が、前記仕様書の定める仕様と一致しているか否かを判断するステップは、
前記検証用結果信号と対比されるべき基準の結果を前記仕様書からコンピュータに読み取らせるステップと、
読み取られた基準の結果と前記検証用結果信号とが一致しているか否かをコンピュータに判断させるステップとを含むことを特徴とする。
【００１４】
【発明の実施の形態】
実施の形態１．
以下、図１乃至図４を参照して、本発明の実施の形態１について説明する。本実施形態は、車両用制御装置（ＥＣＵ）の開発過程で、そのＥＣＵが仕様書の内容通りに動作するか否かを評価するための方法に関する。
【００１５】
図１は、本実施形態における評価の対象であるＥＣＵの仕様書の一部を示す。ＥＣＵの仕様書は、その内容を人間が理解することができ、かつ、その内容をコンピュータが実行することのできる言語で作成される。本実施形態では、図１に示すように、ＥＣＵの仕様書はシミュリンク（Ｓｉｍｕｌｉｎｋ）により作成される。
【００１６】
尚、図１に示す仕様は、内燃機関を制御するためのＥＣＵの仕様書の一部であり、その内容は以下の事項を表している。
「以下の条件全て成立でＦｌａｇ２＝ＯＮ（＝１）
機関廻転数ＮＥ＜８００ｒｐｍ
冷却水温ＴＨＷ≧８０℃
Ｆｌａｇ１＝１」
【００１７】
本実施形態におけるＥＣＵの開発過程では、先ず、図１に示すようにシミュリンクによって仕様書が作成される。次いで、その仕様書に基づいて、ＥＣＵのハードウェアおよびソフトウェアが作製される。ここで、ソフトウェアは、シミュリンクに比してコンピュータ上での実行に適した言語、例えば、Ｃ言語等を用いて、人間の手作業（自動変換ツールの使用を含む）により作製される。このようにして作製されたソフトウェアが、上記のハードウェアに実装されることにより、評価の対象であるＥＣＵ（試作品）が作製される。
【００１８】
上記の手順でＥＣＵが試作される過程には、ソフトウェアの開発者が仕様書の内容に基づいて手作業でソフトウェアを作製する工程が含まれる。仕様書がシミュリンクで書かれている場合、その内容は自動変換ツールを用いてＣ言語に変換することが可能である。しかしながら、自動変換ツールを用いてＣ言語に変換されただけのソフトウェアは、コンピュータ上での効率的な実行を可能とする意味で最適化されたものではない。このため、ＥＣＵを効率的に動作させるソフトウェアを得るためには、必然的に開発者の手作業を介在させる必要が生ずる。
【００１９】
ソフトウェアの開発過程では、そのソフトウェアにバグが混入することがある。特に、そのソフトウェアが手作業で作製される場合には、バグの混入が生じ易い。更に、ＥＣＵの試作段階では、ソフトウェアのみでなく、ハードウェアにも何等かの不具合が生じていることがある。このため、上述した手順でＥＣＵの試作品が作製された後には、そのＥＣＵが仕様書に定められている通りに動作するか否かを評価し、異常が認められた場合には、その異常が解消されるように、ハードウェア或いはソフトウェアを修正することが必要となる。
【００２０】
開発段階のＥＣＵを効率的に評価する手法としては、ＨＩＬＳ（Ｈａｒｄｗａｒｅ　Ｉｎ　ｔｈｅ　ＬｏｏｐＳｉｍｕｌａｔｉｏｎ）を用いた手法が知られている。
図２は、ＨＩＬＳの概要を説明するための図である。図２に示すように、ＨＩＬＳは、評価の対象であるハードウェア、すなわち、開発の過程にあるＥＣＵ１０を含んで構成される。本実施形態において、ＥＣＵ１０は、内燃機関の運転状態を制御するための制御ユニットである。
【００２１】
図２に示すように、ＨＩＬＳは、ＥＣＵ１０をリアルタイムシミュレータ１２に接続することで構成されている。リアルタイムシミュレータ１２は、入出力ポート（Ｉ／Ｏ）１４，１６を備えており、それらを介してＥＣＵ１０との間で信号を授受することができる。
【００２２】
リアルタイムシミュレータ１２には、車両モデル、より具体的には、エンジンモデルが実装されている。また、リアルタイムシミュレータ１２には、アクセルペダル、ブレーキペダル、或いはシフトレバーなどの入力Ｉ／Ｆ（図示せず）、更には、外部から供給される車両の走行パターンや制御信号のパターンを読み込むための入力インターフェースが設けられている。
【００２３】
リアルタイムシミュレータ１２は、上述した種々の入力インターフェースから入力される情報に基づいて、車両（内燃機関）の挙動を模擬することができる。また、リアルタイムシミュレータ１２が動作している間、リアルタイムシミュレータ１２とＥＣＵ１０との間では、実車上でＥＣＵ１０が授受するのと同様の信号が授受される。このため、ＨＩＬＳに組み込まれたＥＣＵ１０は、リアルタイムシミュレータ１２の動作中は、実車に搭載された状態と同様に、車両（内燃機関）の制御に必要な種々の処理を実行する。
【００２４】
ＨＩＬＳを用いたＥＣＵ１０の評価は、基本的には以下のような手順で進められる。すなわち、開発過程にあるＥＣＵ１０が仕様書の内容通りに動作するか否かを評価する際には、先ず、
（１）仕様書に定められている事項のうち、ＥＣＵ１０が仕様を満たしているか否かを検証する必要のある事項（要検証事項）が選択される。
（２）次に、それぞれの要検証事項を検証するために、実行すべきシミュレーションのパターン（車両の走行パターン、或いは、ＥＣＵ１０に対する入力信号のパターンなど）が決定される。
（３）上記のパターンでＨＩＬＳによるシミュレーションを実行する。
（４）シミュレーションの際にＥＣＵ１０で生成される結果信号（アクチュエータへの出力信号、或いは、ＲＡＭ値など）と、仕様書に定められている内容とを比較し、両者が一致していない場合にＥＣＵ１０にバグが生じていると判断する。
【００２５】
上述した一連の手順において、要検証事項の選択、シミュレーションパターンの決定、および結果信号と仕様書との比較（手順（１）、（２）、（４））は、ＥＣＵ１０の評価担当者によって仕様書を参照しながら手作業により行われるのが通常である。このため、その評価には多大な時間が必要とされ、また、上記の評価担当者は、高度の経験を有しＥＣＵ１０の制御を熟知した者に限られるのが現状である。そこで、本実施形態の評価方法は、上記（４）の手順を自動化することで、ＥＣＵ１０の評価に要する時間を短縮し、また、その評価の難易度を下げようとするものである。
【００２６】
図３は、本実施形態において、上記の目的を達成すべく実行されるＥＣＵ１０のデバッグ手順のフローチャートである。尚、図３に示す手順は、ＥＣＵ１０の仕様書が完成した後の手順である。また、完成した仕様書に基づくＥＣＵ１０の作製は、この手順とは別に、この手順と並行して進められるものとする。
【００２７】
図３に示す手順では、先ず、制御装置試作ユニット（ＲＰＥ：　Ｒａｐｉｄ　Ｐｒｏｔｏｔｙｐｉｎｇ　ＥＣＵ）２０を含むＨＩＬＳの準備が行われる（Ｓ１）。
図４は、上記工程Ｓ１により準備されたＨＩＬＳの構成を説明するための図である。図４に示すように、ＲＰＥ２０を含むＨＩＬＳは、ＲＰＥ２０をリアルタイムシミュレータ１２に接続することで実現することができる。
【００２８】
Ｒａｐｉｄ　Ｐｒｏｔｏｔｙｐｉｎｇ　ＥＣＵ、すなわち、ＲＰＥは、仕様書の内容に適合する制御ユニットを短時間で準備するための汎用的なユニットである。ＲＰＥは、通常のＥＣＵに比して高度なコンピュータを備え、かつ、通常のＥＣＵが備えているのと同様の入出力ポート（Ｉ／Ｏ）を備えている。本実施形態で用いられるＲＰＥ２０は、特に、シミュリンクで書かれたプログラムを実行することのできるコンピュータを備えたものである。
【００２９】
仕様書が完成した後、ＥＣＵの試作品ができあがるまでには、ハードウェアやソフトウェアを作製するための時間が当然に必要である。これに対して、ＲＰＥを利用すれば、仕様書の内容に合致した制御ユニットを短時間で準備することができる。このため、ＲＰＥは、ＥＣＵの開発時間を短縮するうえで有効である。
【００３０】
本実施形態の場合は、シミュリンクで書かれたプログラムを実行することのできるＲＰＥに、ＥＣＵ１０の仕様書、すなわち、シミュリンクで書かれた仕様書の内容をそのまま実装することにより、その仕様書の内容に合致した制御ユニットを準備することができる。図４に示すＲＰＥ２０は、このようにして準備された制御ユニットである。
【００３１】
再び図３を参照して、以下の手順を説明する。図３に示す手順では、次に、仕様書内の要検証事項を評価するためのデバッグ条件が決定される（Ｓ２）。
本工程Ｓ２では、より具体的には、要検証事項を評価するためにリアルタイムシミュレータ１２により模擬させるべき車両の走行パターンや、リアルタイムシミュレータに供給すべき各種パラメータ（機関廻転数ＮＥ、冷却水温ＴＨＷ、吸入空気量Ｇａなど）の値が決定される。
尚、本工程Ｓ２と、上記工程Ｓ１との順序は、図３に示す順序に限定されるものではなく、それらの順序は、図３に示す順序と反対の順序であってもよい。
【００３２】
図３に示す手順では、次に、ＲＰＥ２０を含むＨＩＬＳを用いて、上記工程Ｓ２で決定された個々のデバッグ条件でのシミュレーションが実行される（Ｓ３）。
個々のデバッグ条件に応じたシミュレーションでは、リアルタイムシミュレータ１２に対して、そのデバッグ条件に応じた走行パターンの指令や各種パラメータの指令値が供給される。リアルタイムシミュレータ１２は、それらの指令を受けると、その指令に応じた状況を模擬的に作り出し、実車上でＥＣＵ１０が受けるべき信号を生成してＲＰＥ２０に出力する。この際、リアルタイムシミュレータ１２からは、例えば、模擬すべき機関回転数ＮＥに応じた周期で変動するクランクパルス信号や、模擬すべき吸入空気量Ｇａに対応するエアフロメータ（ＡＦＭ）信号、或いは、模擬すべき冷却水温ＴＨＷに対応する水温センサ信号などが出力される。以下、このようにして、個々のデバッグ条件に対応してリアルタイムシミュレータから出力される信号を「条件信号」と称す。
【００３３】
個々のデバッグ条件に応じたシミュレーションの実行過程において、ＲＰＥ２０は、供給される条件信号に応じた動作を行う。その結果、ＲＰＥ２０は、個々のデバッグ条件に応じたアクチュエータ出力（例えば、インジェクタ信号や点火信号）やＲＡＭ値（例えば、各種パラメータの記憶値やフラグ値）を生成する。以下、このようにして、個々のデバッグ条件に対応してＲＰＥ２０により生成される信号やＲＡＭ値を「基準結果信号」と称す。
【００３４】
シミュレーションの過程でＲＰＥ２０がどのように動作しているかは、デバッグ条件に対して、つまり、条件信号に対してＲＰＥ２０がどのような基準結果信号を生成しているかを見ることで把握することができる。そこで、上記工程Ｓ３では、シミュレーションの実行と共に、ＲＰＥ２０で生成される基準結果信号（アクチュエータ出力とＲＡＭ値）の計測と記録とが行われる。
【００３５】
図３に示す手順では、次に、評価の対象であるＥＣＵ１０を含むＨＩＬＳが準備される（Ｓ４）。
ここで用いられるＥＣＵ１０は、ＲＰＥ２０に実装された仕様書の内容に合致するように、人手を介して開発されたものである。本工程Ｓ４では、具体的には、このようにして開発されたＥＣＵ１０をリアルタイムシミュレータ１２に接続する作業が行われる（図２参照）。
【００３６】
次に、ＥＣＵ１０を含むＨＩＬＳを用いて、上記工程Ｓ２で決定された個々のデバッグ条件でのシミュレーション、つまり、上記工程Ｓ３においてＲＰＥ２０を対象として行われたのと同様のシミュレーションが実行される（Ｓ５）。
【００３７】
個々のデバッグ条件に応じたシミュレーションの実行過程において、ＥＣＵ１０は、リアルタイムシミュレータ１２から供給される条件信号を受けて、その条件信号に応じたアクチュエータ出力やＲＡＭ値を生成する。以下、このようにして、個々のデバッグ条件に対応してＥＣＵ１０により生成される信号やＲＡＭ値を「検証用結果信号」と称す。上記工程Ｓ５では、シミュレーションの実行と共に、このようにしてＥＣＵ１０により生成される検証用結果信号（アクチュエータ出力とＲＡＭ値）の計測と記録とが行われる。
【００３８】
図３に示す手順では、次に、上記工程Ｓ３で記録された基準結果信号と、上記工程Ｓ５において記録された検証用結果信号との比較に基づいて、ＥＣＵ１０が仕様書の内容通りに動作しているか否かが判定される（Ｓ６）。
基準結果信号は、仕様書の内容がそのまま搭載されたＲＰＥ２０により生成される結果信号である。つまり、基準結果信号は、個々のデバッグ条件に対する結果として仕様書に定められている信号である。従って、ＥＣＵ１０が仕様書の内容通りに作製されていれば、基準結果信号（ＲＰＥ２０の信号）と検証用結果信号（ＥＣＵ１０の信号）とは一致するはずである。そして、それら両者が一致しない場合は、ＥＣＵ１０が、仕様書の内容通りに機能していないと判断することができる。
本工程Ｓ６では、具体的には、シミュレーションが行われた個々のデバッグ条件毎に、基準結果信号と検証用結果信号とが一致しているか否かが判断される。そして、両者の不一致を生じさせたデバッグ条件が、ＮＧ条件として認識される。
【００３９】
図３に示す手順では、次に、全てのデバッグ条件中にＮＧ条件が存在しているか否かが判別される（Ｓ７）。
【００４０】
その結果、ＮＧ条件が存在すると判別された場合は、そのＮＧの原因となったバグが解析され、更に、そのバグの修正が行われる（Ｓ８）。
その後、再び上記工程Ｓ５以降の作業が行われる。
【００４１】
上記工程Ｓ７において、全てのデバッグ条件中にＮＧ条件が存在しないと判別できた場合は、ＥＣＵ１０のデバッグが終了したものとして、図３に示すデバッグ手順が終了される。
【００４２】
以上説明した通り、図３に示す一連の手順によれば、ＲＰＥ２０を用いたシミュレーションを行うことにより、個々のデバッグ条件毎に、仕様書の内容に合致する結果信号（基準結果信号）を取得することができる。そして、ＥＣＵ１０を用いたシミュレーションの結果として生成される検証用結果信号と、上記の基準結果信号とを比較するだけで、仕様書の参照を要することなく、ＥＣＵ１０が仕様書の内容通りに作製されているか否かを評価することができる。
【００４３】
検証用結果信号と基準結果信号とが一致しているか否かは、高度の経験を要することなく、また、制御内容の熟知を必要とすることなく、短時間で判断することができる。このため、本実施形態の評価方法によれば、ＥＣＵ１０の評価を、短時間で簡単に行うことができる。
【００４４】
ところで、上述した実施の形態１においては、仕様書をシミュリンクで作成することとしているが、仕様書の作成言語はこれに限定されるものではない。すなわち、その言語は、人間が内容を理解することができ、かつ、コンピュータが実行可能なものである限り、他の言語（例えばＣ言語）であってもよい。
【００４５】
また、上述した実施の形態１では、上記工程Ｓ６の作業、すなわち、基準結果信号と検証用結果信号との比較に基づいてＥＣＵ１０のＯＫ・ＮＧを判定する作業を、開発者に手作業で実行させるか、或いはコンピュータに自動実行させるかにつき言及していないが、その作業は、何れの手法で実行させることとしてもよい。
その作業を手作業で行う場合は、基準結果信号および検証用結果信号をそれぞれプリントアウト等して、上記工程Ｓ６において、評価担当者が、それらを目視により比較すればよい。また、上記の作業をコンピュータに実行させる場合は、上記工程Ｓ３において基準結果信号をコンピュータに記録させ、かつ、上記工程Ｓ５において検証用結果信号をコンピュータに記録させたうえで、上記工程Ｓ６において、コンピュータにそれらの一致不一致を判断させればよい。
【００４６】
実施の形態２．
次に、図５乃至図８を参照して、本発明の実施の形態２について説明する。
実施の形態１の説明において記述した通り、ＨＩＬＳを用いて車両用制御装置（ＥＣＵ）を評価する場合は、シミュレーションの実行に先立って、以下の作業を行う必要がある。
（１）仕様書に定められている事項から要検証事項を選択する作業。
（２）それぞれの要検証事項を検証するためのシミュレーションのパターンを決定する作業。
これらの作業は、通常、ＥＣＵの評価担当者によって手作業で行われており、評価時間の短縮および簡単化の妨げとなっている。
【００４７】
また、ＥＣＵが仕様書の内容通りに動作するか否かをＨＩＬＳを用いて評価する場合は、特定のＲＡＭ値（フラグの値など）を、デバッグ条件に応じた値に設定する必要が生ずる。ＥＣＵにおいて、フラグ値等のＲＡＭ値は、その内部処理の結果として設定される。従って、シミュレーションの過程でそれらのＲＡＭ値を所望の値に設定するためには、その設定を実現するための全ての条件を整えることが必要である。
【００４８】
換言すると、ＨＩＬＳを用いたシミュレーションの過程で、ＥＣＵのＲＡＭ値を、単純にデバッグ条件に応じた値に書き換えた場合は、その書き換えの直後に、ＥＣＵの内部処理により、再びそのＲＡＭ値が書き換えられる事態が生じ、デバッグ条件に応じたシミュレーションが実行できない事態が生じ得る。このように、ＨＩＬＳを用いてＥＣＵを評価する場合、デバッグ条件に応じたシミュレーションを実行することは必ずしも容易ではない。
【００４９】
本実施形態の評価方法は、ＨＩＬＳを用いたＥＣＵの評価に伴う上記の不都合の解消を目的としたものである。すなわち、本実施形態の評価方法は、上記（１）および（２）の作業の自動化を可能とし、更に、シミュレーション中におけるＲＡＭ値の直接書き換えを可能とすることで、ＨＩＬＳを用いたＥＣＵの評価を容易化しようとするものである。尚、本実施形態においても、評価の対象は、実施の形態１の場合と同様に、開発過程にあるＥＣＵ１０（内燃機関の制御装置）であるものとする。
【００５０】
図５は、本実施形態の評価方法の概要を説明するためのブロック図である。尚、図５において、実施の形態１で説明した要素と同一物を表すブロックには、実施の形態１の場合と同一の符号を付している。
【００５１】
図５において、Ｓｉｍｕｌｉｎｋ仕様書３０は、シミュリンクで書かれたＥＣＵ１０の仕様書である。Ｓｉｍｕｌｉｎｋ仕様書３０には、例えば、図１に示すような事項が書かれている。Ｓｉｍｕｌｉｎｋ仕様書３０は、ＥＣＵ１０の作成の基礎として用いられると共に、ＥＣＵ１０の評価のために、その内容がパーソナルコンピュータに読み込まれる。
【００５２】
条件読み取りツール３２は、Ｓｉｍｕｌｉｎｋ仕様書３０から、要検証事項を読み取るためのツール（ソフトウェア）である。条件読み取りツール３２は、Ｓｉｍｕｌｉｎｋ仕様書３０の内容と同様に、パーソナルコンピュータに読み込まれている。条件読み取りツール３２によれば、Ｓｉｍｕｌｉｎｋ仕様書３０に書かれている事項から、制御ロジックとして使用されている条件や、条件分岐文を読み取ることができる。
【００５３】
デバッグ条件作成ツール３４は、条件読み取りツール３２によって読み取られた個々の要検証事項について、デバッグ条件を作成するためのツール（ソフトウェア）である。デバッグ条件作成ツール３４は、Ｓｉｍｕｌｉｎｋ仕様書３０の内容や条件読み取りツール３２と同様に、パーソナルコンピュータに読み込まれている。デバッグ条件作成ツール３４によれば、個々の要検証事項を検証するために必要な必要十分なデバッグ条件を自動的に作成することができる。
【００５４】
デバッグ条件出力ツール３６は、デバッグ条件作成ツール３４によって作成されたデバッグ条件を、リアルタイムシミュレータ１２およびＲＡＭ値計測機器３８に出力するためのツール（ソフトウェア）である。デバッグ条件出力ツール３６は、Ｓｉｍｕｌｉｎｋ仕様書３０の内容や条件読み取りツール３２などと同様に、パーソナルコンピュータに読み込まれている。本実施形態において作成されるデバッグ条件には、リアルタイムシミュレータ１２が車両の状態を模擬するために必要とするパラメータ値（機関廻転数ＮＥや、冷却水温ＴＨＷなど）と、ＥＣＵ１０において実現されるべきＲＡＭ値（フラグ値など）とが含まれている。デバッグ条件出力ツール３６は、それらのデバッグ条件のうち、パラメータ値をリアルタイムシミュレータ１２に出力し、ＲＡＭ値をＲＡＭ値計測機器３８に出力する。
【００５５】
ＲＡＭ値計測機器３８は、ＥＣＵ１０のＲＡＭ値を直接的に読み書きするための装置である。ＲＡＭ値計測機器３８によれば、評価対象のＥＣＵ１０内のＲＡＭ値を、デバッグ条件出力ツール３６から供給されるＲＡＭ値に直接的に書き換えることができる。尚、図５に示す例では、ＲＡＭ値計測機器３８が、リアルタイムシミュレータ１２とは別個の装置として表されているが、ＲＡＭ値計測機器３８は、リアルタイムシミュレータ１２に内蔵されていてもよい。
【００５６】
本実施形態において、ＥＣＵ１０は、リアルタイムシミュレータ１２によるシミュレーションの実行中は、ＲＡＭ値計測機器３８により書き換えられたＲＡＭ値を、内部処理に応じた値に書き換えることなく維持することができるように構成されている。このため、図５に示す構成によれば、デバッグ条件作成ツール３４によって作成されたデバッグ条件を、シミュレーションの実行中に、比較的容易にＥＣＵ１０に反映させることができる。
【００５７】
図６は、上述した条件読み取りツール３２、デバッグ条件作成ツール３４、およびデバッグ条件出力ツール３６の内容を詳細に説明するためのフローチャートである。
【００５８】
図６において、符号４０は、Ｓｉｍｕｌｉｎｋ仕様書４０に書かれている条件の１例を示すコンピュータ画面である。画面４０に書かれている条件は、図１に示す事項と同一である。すなわち、その条件は、
「以下の条件全て成立でＦｌａｇ２＝ＯＮ（＝１）
機関廻転数ＮＥ＜８００ｒｐｍ
冷却水温ＴＨＷ≧８０℃
Ｆｌａｇ１＝１」
という条件である。
【００５９】
条件読み取りツール３２によれば、パーソナルコンピュータに読み込まれているＳｉｍｕｌｉｎｋ仕様書３０の内容を検索して、その中から、画面４０に表示されているような条件や、或いは他の条件若しくは条件分岐文を、要検証事項として読み取ることができる。
【００６０】
デバッグ条件作成ツール３４は、要検証事項として読み取られた個々の事項につき、その内容を検証するために実行すべきシミュレーションの条件、すなわち、デバッグ条件を作成する。要検証事項は、それぞれ、画面４０（または図１）に示されるように、パラメータの大小関係を定める条件や、フラグの設定値に関する条件で構成されている。デバッグ条件作成ツール３４は、それらの条件の正否の全てが検証できるようにデバッグ条件を作成する。
【００６１】
より具体的には、デバッグ条件作成ツール３４は、パラメータの大小関係については、原則として、以下の場合についてそれぞれシミュレーションが実行されるように、４通りのデバッグ条件を設定する。
▲１▼パラメータの大小関係についての条件が成立する場合。
▲２▼パラメータの大小関係についての条件が成立しない場合。
▲３▼パラメータの大小関係についての条件が成立から不成立に変化する場合。
▲４▼パラメータの大小関係についての条件が不成立から成立に変化する場合。
【００６２】
デバッグ条件作成ツール３４は、また、フラグの設定値に関する条件についても、原則として、以下に示す４通りのデバッグ条件を設定する。
▲１▼フラグ値についての条件が成立する場合。
▲２▼フラグ値についての条件が成立しない場合。
▲３▼フラグ値についての条件が成立から不成立に変化する場合。
▲４▼フラグ値についての条件が不成立から成立に変化する場合。
【００６３】
従って、画面４０に示される通り、要検証事項に、パラメータの大小関係を規定する２つの条件と、フラグ値に関する１つの条件とが含まれている場合、それぞれの条件について検証すべき場合の組み合わせにより、原則として、４×４×４＝６４通りのデバッグ条件がデバッグ条件作成ツール３４により作成される。図６中に、デバッグ条件作成ツール３４により作成されたデバッグ条件として例示されている４つの条件は、それら６４通りのデバッグ条件の一部である。
【００６４】
尚、上述したデバッグ条件の作成手法は、あくまでも例示であり、その作成手法はこれに限定されるものではない。例えば、上記の例では、パラメータの大小関係についての条件或いはフラグ値に関する条件が、成立から不成立に変化する場合と不成立から成立に変化する場合の双方につきデバッグ条件を作成することとしているが、パラメータやフラグの性質によっては、それらの一方についてはデバッグ条件の作成を省略することとしてもよい。
【００６５】
デバッグ条件出力ツール３６は、上記の如く作成された複数のデバッグ条件を、順次リアルタイムシミュレータ１２およびＲＡＭ値計測機器３８に向けて出力する。この際、デバッグ条件に含まれている条件のうち、機関廻転数ＮＥや冷却水温ＴＨＷなど、車両の制御に必要な条件として予め定められているものは、リアルタイムシミュレータ１２に供給される。一方、デバッグ条件に含まれている条件のうち、車両制御に直接的には必要ないもの、つまり、本来はＥＣＵ１０の内部処理により設定されるべきＲＡＭ値に関するものは、ＲＡＭ値計測機器３８に供給される。
【００６６】
デバッグ条件出力ツール３６から、上記の如くデバッグ条件が出力されると、リアルタイムシミュレータ１２は、個々のデバッグ条件に応じたシミュレーションを実行すべく、機関廻転数ＮＥやＡＦＭ信号、或いは水温信号などの条件信号を生成してＥＣＵ１０に供給する。この際、ＥＣＵ１０には、ＲＡＭ値計測機器３８からデバッグ条件に合致したＲＡＭ値が条件信号の一部として供給される。その結果、ＥＣＵ１０のＲＡＭ値は、デバッグ条件に適合する値に書き換えられる。
【００６７】
ＥＣＵ１０は、リアルタイムシミュレータ１２およびＲＡＭ値計測機器３８から上記の如く条件信号を受信すると、その条件信号に応じた検証用結果信号（アクチュエータ出力、ＲＡＭ値）を生成する。つまり、ＨＩＬＳに組み込まれたＥＣＵ１０では、デバッグ条件出力ツール３６からデバッグ条件が出力される毎に、個々のデバッグ条件に対応する検証用結果信号が生成される。
【００６８】
本実施形態の評価方法では、このようにして生成された検証用結果信号が、全てのデバッグ条件毎に記録される。更に、その検証用結果信号が、仕様書の内容に合致しているか否かを判断することにより、ＥＣＵ１０が、仕様書の内容通りに作成されているか否かが判断される。そして、何れかのデバッグ条件につき、ＥＣＵ１０の動作が仕様書の内容に合致していないと判別された場合は、両者が合致するように、ＥＣＵ１０のハードウェア上、或いはソフトウェア上のバグが修正される。
【００６９】
以上説明した通り、本実施形態の評価方法によれば、ＨＩＬＳを用いてＥＣＵ１０を評価するうえで必要となる要検証事項の決定、およびデバッグ条件の作成を、人手を介することなく、コンピュータに実行させることができる。このため、本実施形態の方法によれば、ＥＣＵ１０が仕様書の内容通りに作成されているか否かを判断するための評価を、短時間で、かつ、簡単に実行することができる。
【００７０】
既述した通り、本実施形態では、リアルタイムシミュレータ１２によるシミュレーションの実行中に、ＥＣＵ１０内のＲＡＭ値がＲＡＭ値計測機器３８により書き換えられた場合は、そのＲＡＭ値がＥＣＵ１０の内部処理により再び書き換えられるのを防止している。以下、この機能を実現するために、リアルタイムシミュレータ１２およびＥＣＵ１０においてそれぞれ実行されている処理の内容について説明する。
【００７１】
図７は、上記の機能を実現するためにリアルタイムシミュレータ１２が実行する一連の処理の流れを説明するためのフローチャートである。
図７に示す一連の処理では、先ず、リアルタイムシミュレータ１２が新たなデバッグ条件を受信したか否かが判別される（ステップ１００）。
【００７２】
上記ステップ１００の処理は、新たなデバッグ信号の受信が判定されるまで繰り返し実行される。そして、新たな条件信号の受信が判定されると、次に、そのデバッグ条件でのシミュレーションが開始されたことを表すべく、デバッグフラグがＯＮとされる（ステップ１０２）。
【００７３】
リアルタイムシミュレータ１２では、次に、ＥＣＵ１０に向けて、デバッグ条件に適合した条件信号（パラメータ信号）が出力される（ステップ１０４）。
【００７４】
次いで、ＥＣＵ１０により生成される検証用結果信号の記録が終了したか否かが判別される（ステップ１０６）。
本ステップ１０６において、検証用結果信号の記録が終了したか否かは、例えば、その記録の終了を意味する信号がＨＩＬＳ側から発せられたか否かに基づいて、或いは、その記録に要する予定の時間が経過したか否かに基づいて、更には、その記録の終了を意味する入力操作が評価担当者によってなされたか否かに基づいて判断することができる。
【００７５】
上記ステップ１０６の処理は、検証用結果信号の記録が終了したと判別されるまで繰り返し実行される。そして、その記録が終了したと判定されると、今回のデバッグ条件でのシミュレーションが終了したことを表すべく、デバッグフラグがＯＦＦとされる（ステップ１０８）。
【００７６】
以上説明した通り、図７に示すルーチンによれば、リアルタイムシミュレータ１２に新たなデバッグ条件が供給された後、そのデバッグ条件に対して、ＥＣＵ１０が生成する検証用結果信号が記録されるまでの間は、デバッグフラグをＯＮとしておくことができる。
【００７７】
図８は、シミュレーション中におけるＲＡＭ値の再書き換えを防止するためにＥＣＵ１０が実行するルーチンのフローチャートを示す。
図８に示すルーチンでは、先ず、デバッグフラグがＯＮであるか否かが判別される（ステップ１１０）。
【００７８】
その結果、デバッグフラグがＯＮであると判別された場合は、リアルタイムシミュレータ１２によるシミュレーションの実行中であり、未だ、新たなデバッグ条件に対する検証用結果信号の記録が終了していないと判断することができる。ＥＣＵ１０では、この場合、外部入力によるＲＡＭ値の書き換えが有効とされ（ステップ１１２）、かつ、内部処理によるＲＡＭ値の書き換えが禁止される（ステップ１１４）。
【００７９】
上記の処理によれば、ＥＣＵ１０のＲＡＭ値は、検証用結果信号の記録が終わるまでは、内部処理の影響を受けることなく、ＲＡＭ値計測機器３８（図５参照）から供給される値、つまり、デバッグ条件に合致した値に維持される。このため、本実施形態の評価方法によれば、シミュレーションの実行時に、ＥＣＵ１０のＲＡＭ値を容易にデバッグ条件に合致させることができ、個々のデバッグ条件に対する正確な検証用結果信号を容易に計測し、かつ、記録することができる。
【００８０】
図８に示すルーチン中、上記ステップ１１０において、デバッグフラグがＯＮでないと判別された場合は、デバッグ条件に対する検証用結果信号の記録を行うべき状況が生じていないと判断することができる。つまり、検証用結果信号を取得するためにＥＣＵ１０の動作を規制する必要が生じていないと判断することができる。ＥＣＵ１０では、この場合、外部入力によるＲＡＭ値の書き換えが無効とされ（ステップ１１６）、かつ、内部処理によるＲＡＭ値の書き換えが許可される（ステップ１１８）。
【００８１】
上記の処理によれば、検証用結果信号を記録する必要のないときは、ＥＣＵ１０のＲＡＭ値を、その内部処理により決められる値に設定することができる。このため、ＥＣＵ１０は、リアルタイムシミュレータ１２によるシミュレーションの実行中であり、かつ、リアルタイムシミュレータ１２の新たなデバッグ条件が供給された後、検証用結果信号が記録されるまでの間を除き、ＲＡＭ値計測機器３８等の外部機器に影響されることなく、通常の動作を行うことができる。
【００８２】
ところで、上記の説明においては、シミュレーションの実行に伴ってＥＣＵ１０により生成される検証用結果信号が、Ｓｉｍｕｌｉｎｋ仕様書３０の内容と合致しているか否かに基づいてＥＣＵ１０を評価することとしているが、その評価の手法はこれに限定されるものではない。すなわち、本実施形態においても、ＥＣＵ１０の評価は、実施の形態１の場合と同様に、Ｓｉｍｕｌｉｎｋ仕様書３０の内容を実装したＲＰＥ２０により生成される基準結果信号と、ＥＣＵ１０により生成される検証用結果信号との比較に基づいて行うこととしてもよい。
【００８３】
また、上記の説明においては、ＥＣＵ１０により生成される検証用結果信号と、Ｓｉｍｕｌｉｎｋ仕様書３０の内容との比較を、開発者に手作業で実行させるか、或いはコンピュータに自動実行させるかにつき言及していないが、その作業は、何れの手法で実行させることとしてもよい。
その作業を手作業で行う場合は、評価担当者が、シミュレーションの結果得られた検証用結果信号と、Ｓｉｍｕｌｉｎｋ仕様書３０の内容とを目視により比較すればよい。また、上記の作業をコンピュータに実行させる場合は、シミュレーションの結果得られた検証用結果信号をコンピュータに記録させ、かつ、個々のデバッグ条件に対する結果としてＳｉｍｕｌｉｎｋ仕様書３０に定められている事項をコンピュータに読み取らせたうえで、それらの一致不一致をコンピュータに判断させればよい。
【００８４】
【発明の効果】
この発明は以上説明したように構成されているので、以下に示すような効果を奏する。
第１の発明によれば、制御装置試作ユニットが仕様書の内容に従って生成する基準結果信号と、評価の対象である車両用制御装置が生成する検証用結果信号とを比較するだけで、車両用制御装置が仕様書の内容通りに機能しているか否かを容易かつ正確に評価することができる。
【００８５】
第２の発明によれば、仕様書がコンピュータ読み取り可能な言語で作成されているため、コンピュータに、その仕様書から要検証事項を読み取らせ、更に、個々の要検証事項の検証に必要なデバッグ条件を作成させることができる。そして、このようにして作成されたデバッグ条件に対応する条件信号を車両用制御装置に供給することで、その装置の評価を容易かつ正確に行うことができる。
【００８６】
第３の発明によれば、条件信号の供給の結果として車両用制御装置が生成する検証用結果信号が、仕様書の定める仕様と一致しているか否かに基づいて、車両用制御装置を評価することができる。
【００８７】
第４の発明によれば、条件信号の供給の結果として制御装置試作ユニットが生成する基準結果信号と、条件信号の供給の結果として車両用制御装置が生成する検証用結果信号とが一致しているか否かに基づいて、車両用制御装置を評価することができる
【００８８】
第５の発明によれば、車両用制御装置の動作を評価する際に、車両用制御装置内部のＲＡＭ値を条件信号に含まれるＲＡＭ値に書き換えることができると共に、そのＲＡＭ値がその後車両用制御装置の内部処理により書き換えられるのを禁止することができる。このため、本発明によれば、車両用制御装置の評価時に、特定のＲＡＭ値を所望の値にするための全条件を成立させることなく、簡易にその評価を行うことができる。
【００８９】
第６の発明によれば、仕様書がシミュリンク言語で作成されるため、その仕様書の内容を人間が理解することができ、かつ、その内容をコンピュータに実行させることができる。
【００９０】
第７の発明によれば、制御装置試作ユニットによって生成される基準結果信号と、車両用制御装置によって生成される検証用結果信号との比較を、コンピュータに実行させることができる。このため、本発明によれば、車両用制御装置の評価に要する手作業を大幅に軽減することができる。
【００９１】
第８の発明によれば、仕様書の内容から読み取られる基準の結果と、車両用制御装置によって生成される検証用結果信号との比較を、コンピュータに実行させることができる。このため、本発明によれば、車両用制御装置の評価に要する手作業を大幅に軽減することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態１において評価の対象とされる車両用制御装置の仕様書の一部である。
【図２】実施の形態１で用いられるＨＩＬＳ（Ｈａｒｄｗａｒｅ　Ｉｎ　ｔｈｅ　Ｌｏｏｐ　Ｓｉｍｕｌａｔｉｏｎ）の概要を説明するための図である。
【図３】実施の形態１で用いられる車両用制御装置のデバッグ手順を説明するためのフローチャートである。
【図４】図３に示す工程Ｓ１において、ＲＰＥ（Ｒａｐｉｄ　Ｐｒｏｔｏｔｙｐｉｎｇ　ＥＣＵ）を含むように準備されるＨＩＬＳの概要を説明するための図である。
【図５】本発明の実施の形態２の評価方法の概要を説明するためのブロック図である。
【図６】図５に示す条件読み取りツール、デバッグ条件作成ツール、およびデバッグ条件出力ツールの内容を説明するためのフローチャートである。
【図７】実施の形態２において、シミュレーション中におけるＲＡＭ値の再書き換えを防止するために、リアルタイムシミュレータによって実行される一連の処理の流れを説明するためのフローチャートである。
【図８】実施の形態２において、シミュレーション中におけるＲＡＭ値の再書き換えを防止するために、評価対象のＥＣＵによって実行される一連の処理の流れを説明するためのフローチャートである。
【符号の説明】
１０　ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）
１２　リアルタイムシミュレータ
３０　Ｓｉｍｕｌｉｎｋ仕様書
３２　条件読み取りツール
３４　デバッグ条件作成ツール
３８　ＲＡＭ値計測機器

Claims

コンピュータが実行可能な言語で仕様書を作成するステップと、
前記仕様書の内容が実装され、かつ、その内容が実行可能な制御装置試作ユニットに所定の条件信号を供給するステップと、
前記条件信号の供給の結果として前記制御装置試作ユニットが生成する基準結果信号を記録するステップと、
前記仕様書に基づいて車両用制御装置を作成するステップと、
前記条件信号を前記車両用制御装置に供給するステップと、
前記条件信号の供給の結果として前記車両用制御装置が生成する検証用結果信号を記録するステップと、
前記基準結果信号と前記検証用結果信号とが一致しているか否かを判断するステップと、
を含むことを特徴とする車両用制御装置の評価方法。
コンピュータが読み取り可能な言語で仕様書を作成するステップと、
前記仕様書に基づいて車両用制御装置を作成するステップと、
前記仕様書の内容から要検証事項をコンピュータに読み取らせるステップと、前記要検証事項を検証するためのデバッグ条件をコンピュータに作成させるステップと、
前記デバッグ条件に対応する条件信号を生成するステップと、
前記条件信号を用いて前記車両用制御装置の動作を評価するステップと、
を含むことを特徴とする車両用制御装置の評価方法。
前記車両用制御装置の動作を評価するステップは、
前記条件信号を前記車両用制御装置に供給するステップと、
前記条件信号の供給の結果として前記車両用制御装置が生成する検証用結果信号を計測するステップと、
前記検証用結果信号が、前記仕様書の定める仕様と一致しているか否かを判断するステップと、
を含むことを特徴とする請求項２記載の車両用制御装置の評価方法。
前記車両用制御装置の動作を評価するステップは、
前記条件信号を制御装置試作ユニットに供給するステップと、
前記条件信号の供給の結果として前記制御装置試作ユニットが生成する基準結果信号を記録するステップと、
前記条件信号を前記車両用制御装置に供給するステップと、
前記条件信号の供給の結果として前記車両用制御装置が生成する検証用結果信号を記録するステップと、
前記基準結果信号と前記検証用結果信号とが一致しているか否かを判断するステップと、
を含むことを特徴とする請求項２記載の車両用制御装置の評価方法。
前記条件信号は、前記車両用制御装置の内部処理により演算されるべきＲＡＭ値を含み、
前記車両用制御装置の動作を評価するステップは、
前記車両用制御装置内部のＲＡＭ値を、前記条件信号に含まれるＲＡＭ値に書き換えるステップと、
書き換えられたＲＡＭ値が、前記車両用制御装置の内部処理により再び書き換えられるのを禁止するステップと、
を含むことを特徴とする請求項２乃至４の何れか１項記載の車両用制御装置の評価方法。
前記言語はシミュリンクであることを特徴とする請求項１乃至５の何れか１項記載の車両用制御装置の評価方法。
前記基準結果信号を記録するステップは、当該基準結果信号をコンピュータに記録させるステップを含み、
前記検証用結果信号を記録するステップは、当該検証用結果信号をコンピュータに記録させるステップを含み、
前記基準結果信号と前記検証用結果信号とが一致しているか否かを判断するステップは、当該判断をコンピュータに実行させるステップを含むことを特徴とする請求項１または４記載の車両用制御装置の評価方法。
前記検証用結果信号が、前記仕様書の定める仕様と一致しているか否かを判断するステップは、
前記検証用結果信号と対比されるべき基準の結果を前記仕様書からコンピュータに読み取らせるステップと、
読み取られた基準の結果と前記検証用結果信号とが一致しているか否かをコンピュータに判断させるステップとを含むことを特徴とする請求項３記載の車両用制御装置の評価方法。