JP2011221753A - 機能実行情報収集装置及びシステム - Google Patents

Abstract

【課題】実際の車両で得られる機能実行情報を収集できる機能実行情報収集装置の提供。
【解決手段】本発明は、車載ＥＣＵに組み込まれたプログラム中の機能実行コードの実際の使用状況を評価するための機能実行情報収集装置に関し、車載ＥＣＵに組み込まれたプログラム中の特定の機能実行コードが実際の車両の使用時に実行されたか否かを表す機能実行情報を記録する記録手段と、記録手段に記録された機能実行情報を外部装置に出力する出力手段とを備えることを特徴とする。本発明による機能実行情報収集装置は、車載ＥＣＵに組み込まれたプログラム中に存在しうる不要なコードを特定することを支援するのに好適である。
【選択図】図１

Description

本発明は、車載ＥＣＵに組み込まれたプログラム中の機能実行コードの実際の使用状況を評価するための機能実行情報収集装置及び機能実行情報収集システムに関する。

従来から、検査対象の命令コードの中で実行されない命令を検出する不要コード検出部と、検出された不要コードを削除し、該削除後の命令コード列を所定の規則でアドレス移動して再配置する命令コード再配置部とを備えることで、メモリ容量の縮小とシミュレーション速度の向上を図るプロセッサ・シミュレータが知られている（例えば、特許文献１参照）。

特開２００４−２６５３４４号公報

ところで、車両に搭載される車載ＥＣＵに組み込まれるプログラムにおいては、各種のフェイル又はその類を想定して各種の機能実行コードが組み込まれる。この種の機能実行コードは、冗長なフェールセーフ構造により実際には使用されないコードであったり、想定の仕方に誤りがあって実際には使用されないコードであったりする場合等がある。

しかしながら、市場において実車両で実際に機能実行コードが使用されていないことを調べるためには、機能実行コードが使用されたか否かを表す情報を複数の車両から収集する仕組みが必要である。

この点、上記の特許文献１に記載の技術は、プログラム開発段階でシミュレーションによって不要コード（設計上、不要なコード）を削除するものであり、プログラム開発段階で不要コードを削除して市場に出した後に、実際には使用されていない機能実行コードが存在しうることを考慮していない。

そこで、本発明は、実際の車両で得られる機能実行情報を収集できる機能実行情報収集装置及び機能実行情報収集システムの提供を目的とする。

上記目的を達成するため、本発明の一局面によれば、車載ＥＣＵに組み込まれたプログラム中の機能実行コードの実際の使用状況を評価するための機能実行情報収集装置であって、
車載ＥＣＵに組み込まれたプログラム中の特定の機能実行コードが実際の車両の使用時に実行されたか否かを表す機能実行情報を記録する記録手段と、
前記記録手段に記録された機能実行情報を外部装置に出力する出力手段とを備えることを特徴とする、機能実行情報収集装置が提供される。

本発明によれば、実際の車両で得られる機能実行情報を収集できる機能実行情報収集装置及び機能実行情報収集システムが得られる。

本発明による機能実行情報収集システム１の一実施例を示すシステム構成図である。 機能実行コードの一例を示す図である。 機能実行コードのその他の一例を示す図である。 車載ＥＣＵ７０により実行される機能実行情報生成処理の一例を示すフローチャートである。 車載ＥＣＵ７０により実行される機能実行情報送信処理の一例を示すフローチャートである。 センタ４２の記憶装置４６内に蓄積された機能実行カウント値の集計データの一例を示す図である。

以下、図面を参照して、本発明を実施するための最良の形態の説明を行う。

図１は、本発明による機能実行情報収集システム１の一実施例を示すシステム構成図である。本実施例の機能実行情報収集システム１は、車両に搭載される統合制御装置１０と、車両に搭載される各種ＥＣＵ７０と、車両の外部に設置される外部装置４０とを備える。

外部装置４０は、センタ４２を含む。センタ４２は、処理装置４７及び通信装置４８を備え、後述の機能実行情報を各車両から受信する。センタ４２が受信した機能実行情報は、センタ４２内の記憶装置（データベース）４６に記録され集計され、今後の車両開発に利用される。

統合制御装置１０は、センタ４２との双方向通信（無線通信）が可能な通信モジュール１２と、マスタ制御装置２０とを備える。通信モジュール１２は、マスタ制御装置２０と一体的なモジュールであってよく、若しくは、マスタ制御装置２０に取り外し可能に接続されるユニット（例えば、携帯電話のような情報端末）であってよい。あるいは、通信モジュール１２は、マスタ制御装置２０に無線通信網やLAN等を介して接続されるユニットであってよい。

マスタ制御装置２０には、車内ＬＡＮ（local-area network） を介して車両内の複数の車載ＥＣＵ７０が接続される。車載ＥＣＵ７０は、車両内の全てのＥＣＵを含んでよいし、車両内の全てのＥＣＵのうちの特定の１つ以上のＥＣＵであってもよい。図示の例では、車載ＥＣＵ７０は、ドアロック等のボデー系電子部品を制御するボデーＥＣＵ７４及びメータ表示部を制御するメータＥＣＵ７６等を含む。車内ＬＡＮは、CAN（controller area network）、BEAN（双方向多重通信ネットワークの一種）、LIN等の通信プロトコルに基づくものであってよく、例えば、パワートレイン系の電子部品にはCAN（高速）が用いられ、ボデー系の電子部品にはBEANやCAN（中速）が用いられてよい。

車載ＥＣＵ７０は、マイクロコンピュータによって構成されており、例えば、ＣＰＵ、制御プログラムを格納するＲＯＭ、演算結果等を格納する読書き可能なＲＡＭ、タイマ、カウンタ、入力インターフェース、及び出力インターフェース等を有する。車載ＥＣＵ７０は、ＣＰＵがＲＯＭに記憶された各種のプログラムを実行することで、各種制御を実現する。

車載ＥＣＵ７０は、ＣＰＵがＲＯＭに記憶された各種のプログラムを実行する際、プログラム中に組み込まれた特定の機能実行コードが実行されたか否かを表す機能実行情報を生成・記憶する機能を備える。機能実行コードは、フェイル又はその類を想定してプログラム中に組み込まれる処理プログラム部分である。

図２は、機能実行コードの一例を示す図である。図２には、所定のフェイルが検出されない通常時にはfunc_exe1（）関数が実行され、所定のフェイルが検出されたときにはfunc_fail1（）関数が実行されるプログラムが図示されている。この場合は、func_fail1（）関数に関連する実行部分、特に、func_fail1（）関数の定義部分Ｐが、機能実行コードの一例となる。

図３は、機能実行コードのその他の一例を示す図である。ここでは、ある区間に受信できるデータの数がハードウェアの性能上、５個が限界である場合が想定される。しかし、ソフトウェアとしては、５個以上のデータがきた場合も想定したプログラムが作成されている。この場合、図３に示すように、基本的にはデータの数が５個までの処理があればよいので、通常の処理としてデータの数が５までの処理を規定したプログラム部分を作成すると共に、これに加えて、データの数が５個を超えたときの処理を規定したプログラム部分を作成する。このデータの数が５個を超えたときの処理を規定したプログラム部分、特に、データの数が５個を超えた場合の関数の定義部分Ｐが、機能実行コードのその他の一例となる。

図１に戻る。マスタ制御装置２０と車載ＥＣＵ７０との間では、種々の情報・データがバスを介して送受される。例えば、マスタ制御装置２０には、後述する如く、車載ＥＣＵ７０からそれぞれの車載ＥＣＵ７０に係る機能実行情報がバスを介して送信される。

マスタ制御装置２０は、センタ４２から機能実行情報の送信要求を通信モジュール１２により受信した際、当該要求内容に応じて車載ＥＣＵ７０に対して機能実行情報を要求し、当該要求に対する車載ＥＣＵ７０の応答により得た機能実行情報を、通信モジュール１２を介してセンタ４２に送信する。尚、センタ４２からの送信要求は、定期的に実行されてもよいし、例えば廃車時のような特定の事象発生時に実行されてもよい。また、センタ４２からの送信要求は、車載ＥＣＵ７０のうちの特定のＥＣＵ（例えばボデーＥＣＵ７４）のみを対象とするものであってもよい。

外部装置４０は、更に、カーディーラ等にカーメーカーから支給されるサービスツール、カーメーカーの生産ライン等において検査のために用いられる検査ツールのような、専用ツール４４を含む。専用ツール４４は、センタ４２と同様、後述の機能実行情報を車両から受信する。専用ツール４４が受信した機能実行情報は、好ましくは、センタ４２に通信により供給される。このようにして、専用ツール４４を介してセンタ４２が受信した機能実行情報は、センタ４２内の記憶装置（データベース）４６に記録され集計され、今後の車両開発に利用される。

専用ツール４４は、センタ４２と同様に、機能実行情報の送信要求を車載ＥＣＵ７０に対して行うことができる。マスタ制御装置２０は、専用ツール４４から機能実行情報の送信要求を通信モジュール１２により受信した際、当該要求内容に応じて車載ＥＣＵ７０に対して機能実行情報を要求し、当該要求に対する車載ＥＣＵ７０の応答により得た機能実行情報を、専用ツール４４に送信する。尚、専用ツール４４からの送信要求は、定期的に実行されてもよいし、例えば廃車時のような特定の事象発生時に実行されてもよい。また、専用ツール４４からの送信要求は、車載ＥＣＵ７０のうちの特定のＥＣＵ（例えばボデーＥＣＵ７４）のみを対象とするものであってもよい。また、専用ツール４４からの送信要求は、マスタ制御装置２０を介さずに（例えばＬＡＮ接続用インターフェース６０を介して）車載ＥＣＵ７０に直接送信されてもよい。この場合、専用ツール４４は、当該要求に対する車載ＥＣＵ７０の応答により得た機能実行情報をマスタ制御装置２０を介さずに（例えばＬＡＮ接続用インターフェース６０を介して）直接受信してもよい。

図１に示す実施例では、専用ツール４４として、ＬＡＮ接続用インターフェース６０への有線接続（例えばＵＳＢ接続のようなコネクタ接続）を介して通信可能な専用ツール４４ａや、統合制御装置１０と無線通信（例えば狭帯域を利用した通信）が可能な専用ツール４４ｂが示されている。何れの場合も、専用ツール４４は、カーディーラ等において専門のサービスマンによる使用が想定され、人が携帯操作できる小型の端末であってよい。尚、専用ツール４４の使用は、不特定人による使用を防止するため、パスワードの入力やＩＤ照合等の認証を必要とするものであってよい。

図４は、車載ＥＣＵ７０により実行される機能実行情報生成処理の一例を示すフローチャートである。図４に示すフローチャートは、実質的に図２に示したプログラムに対応したフローである。

Ｓ４００では、フェイル情報が読み込まれ、フェイルが検出されたか否かが判定される。フェイルが検出された場合は、Ｓ４０２に進み、フェイルが検出されない場合は、Ｓ４０４に進む。

Ｓ４０２では、検出されたフェイルに対応した機能実行コードが実行される。図２に示すプログラムでは、func_fail1（）関数が実行される。機能実行コードが実行されると、Ｓ４０６に進み、Ｓ４０６では、機能実行コードが実行された回数を表すカウンタ（機能実行カウント）が１ずつインクリメントされる。この機能実行カウントの初期値は、ゼロであってよい。従って、機能実行コードが未だ一度も実行されたことがない場合は、機能実行カウントはゼロに維持されたままとなる。尚、この機能実行カウントは、機能実行コード毎に用意される。機能実行カウントの値は、車載ＥＣＵ７０内の不揮発メモリ（例えばＥＥＰＲＯＭ）又は車載ＥＣＵ７０がアクセス可能な不揮発メモリ（複数も可）に記憶される。

Ｓ４０４では、通常時用のコードが実行される。図２に示すプログラムでは、func_exe1（）関数が実行される。

尚、機能実行カウントは、機能実行コードが実行される回数を表すものであるが、ゼロである機能実行カウント値は、機能実行コードが実行されていないことを表すので、機能実行カウントは、機能実行情報として機能する。尚、機能実行カウントは、単に機能実行コードが実行されたか否かを２値的に表すフラグによって代替されてもよい。

尚、図４に示した機能実行情報生成処理は、上述の如く、実質的に図２に示したプログラムに対応したフローである。図２に示したプログラムには、Ｓ４０６の機能実行カウントのインクリメント処理に対応したプログラム部分が、参照符号Ｑにより指示されている。尚、Ｓ４０６の機能実行カウントのインクリメント処理に対応するプログラム部分は、機能実行コードを含む任意のプログラムに同様に組み込むことができる。例えば、図３に示したプログラムには、Ｓ４０６の機能実行カウントのインクリメント処理に対応したプログラム部分が、参照符号Ｑにより指示されている。

図５は、車載ＥＣＵ７０により実行される機能実行情報送信処理の一例を示すフローチャートである。

Ｓ５００では、機能実行情報の送信条件が成立したか否かが判定される。機能実行情報の送信条件は、例えば上述の如く外部装置４０から直接的に若しくはマスタ制御装置２０を介して送信要求が送られてきた場合に成立するものであってよい。また、機能実行情報の送信条件は、外部装置４０からの要求とは無関係に、定期的（例えば所定時間経過毎、又は所定距離走行毎）に成立するものであってよい。また、機能実行情報の送信条件は、イグニッションスイッチのオン時やオフ時のような特定の事象発生時に成立するものであってよい。機能実行情報の送信条件が成立した場合は、Ｓ５０２に進み、機能実行情報の送信条件が成立しない場合は、そのまま終了する。

Ｓ５０２では、図４で示した機能実行カウントの値がメモリから読み出される。この際、全ての機能実行コードに対応する各機能実行カウント値がメモリから読み出されてもよい。或いは、上述の如く特定の機能実行コードに対応する機能実行情報が要求されている場合は、当該要求された特定の機能実行コードに対応する機能実行カウント値がメモリから読み出されてもよい。

Ｓ５０４では、メモリから読み出された機能実行カウント値が外部装置４０に直接的に若しくは外部装置４０にマスタ制御装置２０を介して送信される。機能実行カウント値は、対応する機能実行コードを特定する情報と共に送信される。また、機能実行カウント値は、車両を特定する情報（例えば、車両ＩＤや車体番号等）と共に送信される。尚、車両を特定する情報は、マスタ制御装置２０からセンタ４２に送信する際にマスタ制御装置２０にて付加されてもよいし、専用ツール４４からセンタ４２に送信する際に専用ツール４４にて付加されてもよい。

このようにして、車載ＥＣＵ７０からセンタ４２に機能実行カウント値が送信される。機能実行カウント値は、上述の機能を備える各車両の車載ＥＣＵ７０からセンタ４２に送信される。これにより、センタ４２は、複数の車両から機能実行カウント値（機能実行情報）を収集することができる。

センタ４２は、各車両の車載ＥＣＵ７０から送信される機能実行カウント値（機能実行情報）を通信装置４８により受信し、機能実行カウント値を処理装置４７により処理して、機能実行カウント値を記憶装置（データベース）４６に記録・蓄積する。

図６は、センタ４２の記憶装置４６内に蓄積された機能実行カウント値（機能実行情報）の集計データの一例を示す図である。

図６では、複数の機能実行コードＣ１，Ｃ２，Ｃ３，・・・に関する機能実行カウント値の集計結果が車種毎に示されている。このように、センタ４２の処理装置４７は、各車両の車載ＥＣＵ７０から機能実行カウント値を取得すると、例えば車体番号等から車種を特定し、車種毎に分けて機能実行カウント値の集計（記録）を行ってもよい。尚、必ずしも全車種に同一（共通）の機能実行コードが実装される必要はなく、例えば特定の車種にだけ実装される機能実行コードが存在してもよいし、若しくは、同一車種の特定のタイプの車両にだけ実装される機能実行コードが存在してもよい。

機能実行カウント値の集計は、機能実行コード毎及び車種毎に、例えば、図４で示した機能実行カウントの値を全車両で積算する方法で実行されてもよい。この場合、図６に示す例では、例えば機能実行コードＣ１が、車種Ａでは２０回実行され、車種Ｂでは１０回実行され、車種Ｃでは５０回実行され、車種Ｄでは１０回実行されたことが示される。或いは、機能実行カウント値の集計は、機能実行コード毎及び車種毎に、例えば、図４で示した機能実行カウントの値が１以上である車両の数を集計する方法で実行されてもよい。この場合、図６に示す例では、例えば機能実行コードＣ１が、車種Ａでは２０台の車両で実行され、車種Ｂでは１０台の車両で実行され、車種Ｃでは５０台の車両で実行され、車種Ｄでは１０台の車両で実行されたことが示される。いずれにしても、機能実行カウント値の集計は、機能実行コードＣ１，Ｃ２，Ｃ３等のうち、どの車種のどの車両でも実行されていない機能実行コードが特定できる態様で実行されればよい。

図６に示す例では、機能実行コードＣ１，Ｃ２，Ｃ３等のうち、機能実行コードＣ２及び機能実行コードＣ５が、どの車種のどの車両でも実行されていないことが分かる。この場合、機能実行コードＣ２及び機能実行コードＣ５は、実際の市場においては必要でなかった機能実行コード（即ち不要コード）である又はその可能性が高いと判断して、次の車両開発にフィードバックすることが可能となる。例えば、不要コードは、削除や簡素化されてもよい。

図６に示す例において、センタ４２における機能実行カウント値の集計は、好ましくは、機能実行カウント値をセンタ４２に提供した車両の台数を併せて考慮できる態様で実行される。例えば、図６に示す例では、機能実行コードＣ１，Ｃ２，Ｃ３等のうち、機能実行コードＣ２及び機能実行コードＣ５の機能実行カウント値が、ゼロであるが、例えば２，３台の車両からの集計結果である場合と、何千台や何万台の車両からの集計結果である場合とで信頼性が異なる。機能実行カウント値をセンタ４２に提供した車両の台数を考慮する場合は、例えば何万台の車両において例えば１０年間の走行実績中に実行されなかった機能実行コードを、実際の市場においては必要でなかった機能実行コードであると判断して、次の車両開発にフィードバックすることが可能となる。

以上説明した本実施例の機能実行情報収集システム１によれば、とりわけ、以下のような優れた効果が奏される。

上述の如く、設計段階で用意された各種機能実行コードが実際の車両で使用されたか否かを表す機能実行情報を車載ＥＣＵ７０で記憶し、その機能実行情報をセンタ４２で収集することで、実際には必要でなかった機能実行コードを高い信頼性で特定することができる。これにより、次の車両開発にフィードバックすることが可能となり、実際には必要でなかった機能実行コードを次期の車両において無くすこと（或いは簡素化すること）で、車載ＥＣＵ７０のＲＯＭの容量を小さくすることができ、コストダウンを図ることができる。

尚、本実施例の機能実行情報収集システム１は、上述の如く、車載ＥＣＵに組み込まれたプログラム中に存在しうる不要なコードを設計者等のユーザが特定することを支援するのに好適であるが、他の用途（例えば、どの機能実行コードが高頻度で実行されているかを評価して今後の設計に反映させる用途等）に使用されてもよい。

以上、本発明の好ましい実施例について詳説したが、本発明は、上述した実施例に制限されることはなく、本発明の範囲を逸脱することなく、上述した実施例に種々の変形及び置換を加えることができる。

例えば、上述した実施例において、機能実行情報の収集対象の機能実行コードは、開発者が不必要でありえると考える機能実行コードに限定してもよい。また、機能実行情報の収集対象の機能実行コードは、車両の利便性機能に関する制御プログラム中の機能実行コードに限定してもよい。

また、上述した実施例において、マスタ制御装置２０の機能の一部又は全部は、車載ＥＣＵ７０（複数のＥＣＵの場合は、それぞれのＥＣＵ又は特定のＥＣＵ）に組み込まれてもよい。

また、上述した実施例において、車載ＥＣＵ７０からセンタ４２への機能実行情報の送信は、例えば家庭用ＬＡＮやＰＬＣ（Power Line Communication）のような有線通信が利用されてもよい。例えば、プラグインハイブリッド車の場合、充電コードを電源に接続して充電する間に、車載ＥＣＵ７０からセンタ４２への機能実行情報の送信を行うことも可能である。

また、上述した実施例において、センタ４２の処理装置４７は、記憶装置４６内に蓄積されたデータに基づいて、ユーザが指定する条件を満たす機能実行コードを探索し抽出する機能を有してもよい。例えば、ユーザが、「５万台以上の車両において１０年間の走行実績中に実行されなかった機能実行コード」という条件を入力した場合に、当該条件を満たす機能実行コードを探索し抽出する機能を有してもよい。これにより、次の車両開発時のフィードバックを効率的に支援することができる。また、センタ４２の処理装置４７は、定期的に又は機能実行情報の受信毎に、記憶装置４６内に蓄積されたデータに基づいて、機能実行コードが所定の条件（例えば、「５万台以上の車両において１０年間の走行実績中に実行されなかった機能実行コード」という条件）を満たしたか否かを判断し、当該条件を満たした段階で、その旨をユーザに提示する機能を有してもよい。例えば、図６に示した表図の態様で表示を行い、当該条件を満たした機能実行コードをハイライト表示してもよい（例えば、図６の機能実行コードＣ２及び機能実行コードＣ５の網掛け表示参考）。この場合、所定の条件は、機能実行コード毎に異なる態様で設定されてもよい。例えば、車両の走行機能（安全性に係る機能）に関する制御プログラム中の機能実行コードに対しては、その他の制御プログラム中の機能実行コード（例えば、車両の利便性機能に関する制御プログラム中の機能実行コード）よりも、厳しい条件（成立し難い条件）に設定されてもよい。

１ 機能実行情報収集システム
１０ 統合制御装置
１２ 通信モジュール
２０ マスタ制御装置
４０ 外部装置
４２ センタ
４４ 専用ツール
４６ 記憶装置
４７ 処理装置
４８ 通信装置
７０ ＥＣＵ
７４ ボデーＥＣＵ
７６ メータＥＣＵ

Claims (4)

1. 車載ＥＣＵに組み込まれたプログラム中の機能実行コードの実際の使用状況を評価するための機能実行情報収集装置であって、
   車載ＥＣＵに組み込まれたプログラム中の特定の機能実行コードが実際の車両の使用時に実行されたか否かを表す機能実行情報を記録する記録手段と、
   前記記録手段に記録された機能実行情報を外部装置に出力する出力手段とを備えることを特徴とする、機能実行情報収集装置。
2. 前記出力手段は、所定期間経過時若しくは外部装置からの要求に応じて前記機能実行情報を出力する、請求項１に記載の機能実行情報収集装置。
3. 前記出力手段は、車内ＬＡＮに接続された外部装置に前記機能実行情報を出力する、請求項１又は２に記載の機能実行情報収集装置。
4. 複数の車両にそれぞれ搭載される請求項１に記載の機能実行情報収集装置と、
   前記機能実行情報収集装置から出力される機能実行情報を受信する外部装置とを備え、
   前記外部装置は、複数の車両から収集した前記機能実行情報を記憶する記憶手段を備える、機能実行情報収集システム。

Images