JP6632765B2 - 制御装置及び制御方法 - Google Patents

Description

本発明は、制御装置及び制御方法に関し、特に、複数の補助機器を接続する制御装置及び接続された複数の補助機器を制御する制御方法に関する。

特許文献１には、車両ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）装置を介して車両データを送受信する車両データ通信部と、車両データ及び変換テーブルを記憶する記憶部と、変換テーブルに基づいて車両独自の形式である車両データをアプリケーションで利用可能な実用データ形式に変換するとともに、アプリケーションで算出された実用データ形式の車両データを変換テーブルに基づいて車両独自の形式の車両データに変換する車両データ変換部と、アプリケーションが車両データにアクセスする車両情報Ｉ／Ｆとを備える車載端末が記載されている。特許文献１に記載された車載端末は、センサ等の機器からの車両データを、変換テーブルを用いて、アプリケーションで利用可能な実用データに変換している。

特願２００１−１３８０７９号公報

ここで、従来例では、例えば、センサ等の補助機器を新たに設置した場合には、新たに設置された機器の車両データを実用データ形式のデータに変換するための変換テーブルを別に用意しなければならない。車両データを実用データ形式のデータに変換する変換テーブルの作成は、煩雑である。さらに、車両データ毎に、このような変換テーブルの作成を行わなければならない。
このため、従来例では、新たにセンサ等の補助機器を設置する場合に、この補助機器を使用することができるようにするために、多くの労力が必要となる。

また、上位機能部であるアプリケーションが、処理を行うために必要なデータを必要なタイミングで、センサ等の補助機器から取得できるようにするためにも、多くの労力が必要となる。

そこで、本発明の１又は複数の態様は、上位機能部が、所望のデータを所望のタイミングで補助機器から容易に取得できるようにすることを目的とする。

本発明の１態様に係る制御装置は、複数の補助機器を接続する制御装置であって、前記複数の補助機器の中の対応する補助機器を動作させるための変数及びＡＰＩを記載するコンフィギュレーションファイルを有するとともに、前記対応する補助機器を動作させるために必要な前記変数のシンボル及び前記ＡＰＩのシンボルが記載されたシンボル情報を生成する複数のドライバ部と、前記複数の補助機器の各々が前記制御装置に接続された際に、前記複数の補助機器の各々に対応する前記複数のドライバ部の各々から前記コンフィギュレーションファイルを取得するとともに、前記複数のドライバ部の各々からの前記シンボル情報を参照して、前記コンフィギュレーションファイルと前記シンボル情報との整合性を確認し、前記コンフィギュレーションファイルと前記シンボル情報との整合性が確認できた場合に、前記シンボル情報を使用して前記複数の補助機器の各々を動作させるミドルウェア部と、前記複数の補助機器から提供されるデータに基づいて、予め定められた制御を行う上位機能部と、を備え、前記上位機能部は、前記複数の補助機器から提供されるデータの中の所望のデータを所望のタイミングで取得する要求を、前記ミドルウェア部に送り、前記ミドルウェア部は、前記シンボル情報を使用して前記複数の補助機器の各々を動作させることで、前記要求に応じて、前記所望のタイミングで、前記所望のデータを前記上位機能部に送ることを特徴とする。

本発明の１態様に係る制御方法は、制御装置に接続される複数の補助機器を制御する制御方法であって、前記制御装置の複数のドライバ部が、前記複数の補助機器の中の対応する補助機器を動作させるために必要な変数のシンボル及びＡＰＩのシンボルが記載されたシンボル情報を生成し、前記制御装置のミドルウェア部が、前記対応する補助機器が前記制御装置に接続された際に、前記複数の補助機器の中の対応する補助機器を動作させるための変数及びＡＰＩを記載するコンフィギュレーションファイルと、前記シンボル情報との整合性を確認し、前記ミドルウェア部が、前記コンフィギュレーションファイルと前記シンボル情報との整合性が確認できた場合に、前記シンボル情報を使用して前記対応する補助機器を動作させるとともに、前記複数の補助機器から提供されるデータの中の所望のデータを所望のタイミングで取得する要求を受け付けて、当該要求に応じて、前記シンボル情報を使用して前記複数の補助機器から特定された補助機器を動作させることで、当該所望のタイミングで、当該所望のデータを前記要求の要求元に送ることを特徴とする。

本発明の１又は複数の態様によれば、上位機能部が、所望のデータを所望のタイミングで補助機器から容易に取得することができる。

実施の形態１及び２に係る車両制御システムの構成の一例を示すブロック図である。 実施の形態１及び２における、Ｆ／Ｅボード、Ｂ／Ｅボード及びナビボードの構成の一例を示すブロック図である。 実施の形態１及び２における補助機器を自動車に搭載した一例を示す概略図である。 実施の形態１におけるＣＳＭＷの内部ソフトウェア構造の一例を示すブロック図である。 実施の形態１におけるＣＳＭＷにて参照するＣＦＧファイルの一例を示す概略図である。 実施の形態１におけるＣＳＭＷにて参照するＭＣＦＧファイルの一例を示す概略図である。 （Ａ）及び（Ｂ）は、実施の形態１及び２におけるハードウェア構成例を示す概略図である。 実施の形態１において、ＣＳＭＷを介して、データを下位機能部から上位機能部に渡す処理の一例を示すステートチャート図である。 実施の形態２におけるＣＳＭＷの内部ソフトウェア構造の一例を示すブロック図である。 実施の形態２におけるアプリケーション管理部の構成を概略的に示すブロック図である。 実施の形態２における単位変換テーブルの一例を示す概略図である。 実施の形態２における式変換テーブルの一例を示す概略図である。 実施の形態２におけるＣＳＭＷにて参照するＭＣＦＧファイルの一例を示す概略図である。 実施の形態２におけるＣＳＭＷにて参照するＣＦＧファイルの一例を示す概略図である。

実施の形態１．
図１は、実施の形態１に係る車両制御システム１００の構成の一例を示すブロック図である。
車両制御システム１００は、補助機器１と、フロントエンドボード（以下、Ｆ／Ｅボードという）１１０と、車両の挙動判断等を行うバックエンドボード（以下、Ｂ／Ｅボードという）１４０と、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）１３からの入力データに基づいて動作するナビボード１５０とを備える。
そして、Ｆ／Ｅボード１１０及びＢ／Ｅボード１４０により、車両の制御を行う制御装置１０５が構成される。制御装置１０５は、複数の補助機器１を接続し、補助機器１から得られるデータに基づいて車両の制御を行う。

Ｆ／Ｅボード１１０には、補助機器１として、単眼カメラ２と、ステレオカメラ３と、側方ソナー４と、ミリ波レーダ５と、ソナー６と、ＬＩＤＡＲ（Ｌａｓｅｒ Ｉｍａｇｉｎｇ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｒａｎｇｉｎｇ）７とが接続されている。ここでは、補助機器１は、単眼カメラ２、ステレオカメラ３、側方ソナー４、ミリ波レーダ５、ソナー６及びＬＩＤＡＲ７といったセンサである。

単眼カメラ２及びステレオカメラ３は、撮像を行い、その映像データを取得する。
側方ソナー４は、車体の側方から１５ｍ程度の遠距離までの間で、他車等の障害物が近づいて来るか否かを判断するため、アナログオーディオ（音波）を用いて計測する。なお、側方ソナー４とＦ／Ｅボード１１０との間には、データのやり取りを行うために必要なアナログデジタル変換器（以下、ＡＤ／ＤＡという）８が設けられている。
ミリ波レーダ５は、電波を周囲に向けて発射し障害物からの反射波を測定することで障害物までの距離及び方向を測り、この障害物までの距離及び方向等の情報を取得する。なお、ミリ波レーダ５は、図示してはいないが、データを取得するミリ波レーダ本体と、そのデータをやり取りするミリ波レーダＥＣＵとを備える。
ソナー６は、音波を用いて車両周辺の障害物を検知する。なお、ソナー６とＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０１との間には、データのやり取りを行うために必要なＡＤ／ＤＡ１１が設けられている。
ＬＩＤＡＲ７は、レーザー光を用いたリモートセンシング技術の１つで、パルス状に発光するレーザー照射に対する散乱光を測定し、遠距離にある対象物までの距離又はその対象物の性質を分析する。

また、Ｆ／Ｅボード１１０は、Ｖ２Ｐモジュール９と、Ｖ２Ｉモジュール１０と、ＩＮＳ（Ｉｎｅｒｔｉａｌ Ｎａｖｉｇａｔｉｏｎ Ｓｙｓｔｅｍ：慣性航法装置）１２と、データのやり取りを行う。

Ｖ２Ｐは、Ｖｅｈｉｃｌｅ ｔｏ Ｐｅｒｓｏｎの略で、Ｖ２Ｐモジュール９は、自車周辺の歩行者を検知して、その検知結果を示す歩行者動向情報を取得する。Ｖ２Ｉは、Ｖｅｈｉｃｌｅ ｔｏ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅの略で、Ｖ２Ｉモジュール１０は、自動車と、インフラとして設定してある路側器との通信結果を示す路側器情報を取得する。Ｖ２Ｐモジュール９及びＶ２Ｉモジュール１０を合わせてＶ２Ｘモジュールともいう。

ＩＮＳ１２は、地上の航法援助施設からの電波又は地磁気等に頼らずに、移動する自動車の加速度から、移動方向、速度及び距離を求め、位置を特定するための搭載用航法装置である。

Ｂ／Ｅボード１４０は、ＳＰＩ（Ｓｅｒｉａｌ Ｐｅｒｉｐｈｅｒａｌ Ｉｎｔｅｒｆａｃｅ）通信経路１０３を介して、Ｆ／Ｅボード１１０とデータのやり取りを行う。

図２は、実施の形態１における、Ｆ／Ｅボード１１０、Ｂ／Ｅボード１４０及びナビボード１５０の構成の一例を示すブロック図である。
単眼カメラ２及びステレオカメラ３は、ＬＶＤＳ（Ｌｏｗ Ｖｏｌｔａｇｅ Ｄｉｆｆｅｒｅｎｔｉａｎ Ｓｉｇｎａｌｉｎｇ）で映像データをＦ／Ｅボード１１０のカスタマイザブルミドルウェア（以下、ＣＳＭＷという）１１１を介して、センサフュージョン１１２に伝送する。ＬＶＤＳは、短距離用のデジタル有線伝送技術で、小振幅及び低消費電力で比較的高速な差動インタフェースである。ＬＶＤＳは、グラフィックスカードからビデオモニタへの映像データ等のデータの伝送に使用される。
側方ソナー４における計測結果は、ＡＤ／ＤＡ８でデジタル変調され、ＣＳＭＷ１１１を介してセンサフュージョン１１２に伝送される。
なお、ＣＳＭＷ１１１をミドルウェア部ともいう。

Ｆ／Ｅボード１１０には、補助機器１を動作させるためのドライバ部１０６が設けられている。例えば、ドライバ部１０６は、補助機器１を動作させるための変数及びＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）名を記載するコンフィギュレーションファイル（ＣＦＧファイルという）を保持する。また、ドライバ部１０６は、ＣＳＭＷ１１１からの指示に応じて、補助機器１を動作させるために必要な変数のシンボル及びＡＰＩのシンボルが記載されたシンボル情報を生成し、生成されたシンボル情報をＣＳＭＷ１１１に与える。
そして、ＣＳＭＷ１１１は、補助機器１が接続された際に、ドライバ部１０６からＣＦＧファイルを取得するとともに、ドライバ部１０６からのシンボル情報を参照して、ＣＦＧファイルとシンボル情報との整合性を確認する。例えば、ＣＦＧファイルに記載されている変数及びＡＰＩに対応する全てのアドレスがシンボル情報に記載されているか否かを確認する。ＣＦＧファイルとシンボル情報との整合性が確認できた場合、言い換えると、ＣＦＧファイルに記載されている変数及びＡＰＩに対応する全てのアドレスがシンボル情報に記載されている場合に、ＣＳＭＷ１１１は、シンボル情報に記載された変数のシンボル及びＡＰＩのシンボルを使用して、補助機器１を動作させる。
さらに、ＣＳＭＷ１１１は、所望のデータを所望のタイミングで取得する要求を、図４に示す上位アプリ１３０から受け付けて、シンボル情報に記載された変数及びＡＰＩを使用して補助機器１を動作させることで、所望のタイミングで、所望のデータを要求元に送信する。

ＣＡＮ１０１は、耐ノイズ性強化を考慮して設計された、接続機器相互間のデータ伝送に使用される通信経路である。ＣＡＮ１０１は、機器の制御情報の伝送用として普及しており、自動車においては補助機器１との情報のやり取り、エンジン又はブレーキの状態及び故障診断情報等の情報の伝送に使用されている。
ミリ波レーダ５は、障害物までの距離及び方向等の情報を、ＣＡＮ１０１及びＣＳＭＷ１１１を介して、センサフュージョン１１２に伝送する。
ソナー６からの情報は、ＡＤ／ＤＡ１１でデジタル変調され、ＣＡＮ１０１及びＣＳＭＷ１１１を介して、センサフュージョン１１２に伝送される。
Ｖ２Ｐモジュール９は、路側器情報を、ＣＡＮ１０１及びＣＳＭＷ１１１を介して、座標変換部１１３に伝送する。
Ｖ２Ｉモジュール１０は、歩行者動向情報を、ＣＡＮ１０１及びＣＳＭＷ１１１を介して、ダイナミックマップ部１１４に伝送する。

イーサネット（登録商標）１０２は、コンピュータネットワーク規格の１つであるが、車載の場合、自動車の周辺監視用のセンサのデータを伝送する通信ネットワークとして採用される。
ＬＩＤＡＲ７からの情報は、イーサネット１０２及びＣＳＭＷ１１１を介して、センサフュージョン１１２に伝送される。

ＩＮＳ１２からの情報は、ＣＳＭＷ１１１を介して、ロケータ部１１５に伝送される。

ナビボード１５０は、ＨＭＩ（Ｈｕｍａｎ Ｍａｃｈｉｎｅ Ｉｎｔｅｒｆａｃｅ）１５１と、ナビゲーション部１５２とを備える。
ＨＭＩ１５１は、ユーザからの指示の入力を受け付ける入力部である。
ナビゲーション部１５２は、ＧＰＳ１３からのシリアル信号と、ＨＭＩ１５１からの情報に基づいて動作し、Ｆ／Ｅボード１１０とデータのやり取りを行っている。
ＧＰＳ１３からの信号は、シリアル通信ケーブル１０４を介して、ナビボード１５０上のナビゲーション部１５２に伝送される。

上述の通り、補助機器１からの種々のデータ、例えば、単眼カメラ２からの映像データ、ステレオカメラ３からの映像データ、ミリ波レーダ５からの電波情報、及び、ソナー６からの音波情報等は、ＣＳＭＷ１１１を介して、センサフュージョン１１２に伝送される。補助機器１からの種々のデータは、センサフュージョン１１２により、統合的に処理され互いに協調されたデータとなってシンクロナイズされる。シンクロナイズされたデータは、センサフュージョン１１２からその上位アプリであるマップ生成部１１６に伝送される。

Ｖ２Ｐモジュール９からＣＳＭＷ１１１を介して座標変換部１１３に伝送されたデータは、座標変換部１１３からマップ生成部１１６に伝送される。
Ｖ２Ｉモジュール１０からＣＳＭＷ１１１を介してダイナミックマップ部１１４に伝送されたデータは、ダイナミックマップ部１１４から地図情報としてマップ生成部１１６及びレーンレベルルート生成部１１７に伝送される。
単眼カメラ２の映像データは、ＬＶＤＳ及びＣＳＭＷ１１１を介して、ロケータ部１１５にも入力され、また、ＩＮＳ１２からのデータもロケータ部１１５に入力される。さらに、マップ生成部１１６からの道路障害物情報が、ロケータ部１１５に入力される。ロケータ部１１５に伝送されたデータは、自車位置情報として、マップ生成部１１６、レーンレベルルート生成部１１７及びナビゲーション部１５２に伝送される。

ナビゲーション部１５２からの誘導情報は、イーサネット１０２経由でレーンレベルルート生成部１１７に入力される。その他のＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）１６０からは、自車速度情報、自車加速度情報、操舵角情報、アクセル／ブレーキ情報及びウィンカ操作情報が、ＣＡＮ１０１経由で運転操作特性部１１８に入力される。この内、自車速度情報は、ＣＡＮ１０１を介して、マップ生成部１１６にも入力される。
マップ生成部１１６からは、３Ｄマップ情報が、リスクマップ生成部１１９の死角検出部１１９ａ及び移動予測部１２０に伝送され、また、３Ｄマップ情報は、イーサネット１０２を介して、ナビボード１５０のＨＭＩ１５１に伝送される。

運動モデルデータベース（以下、運動モデルＤＢ）１２１は、データベース内の情報を運動モデル更新部１２２からの更新情報で更新し、運動モデル情報を移動予測部１２０に入力する。
移動予測部１２０は、マップ生成部１１６からの３Ｄマップ情報と運動モデルＤＢ１２１からの運動モデル情報とから移動予測情報を生成し、これをリスクマップ生成部１１９のリスク推定部１１９ｂに入力する。リスク推定部１１９ｂに入力されたリスク情報を用いて、Ｂ／Ｅボード１４０が車両の制御を行うことによって、リスクを軽減するように自動運転が行われる。

レーンレベルルート生成部１１７は、地図情報及びレーンレベルルート情報をパス生成部１２３に入力する。
運転操作特性部１１８は、運転操作特性データベース（以下、運転操作特性ＤＢ）１２４と運転操作特性情報をやり取りし、更新された運転操作特性情報をパス生成部１２３に入力する。
パス生成部１２３は、パス情報を、イーサネット１０２を介して、ナビボード１５０のＨＭＩ１５１に入力する。また、パス生成部１２３は、パス情報をＳＰＩ通信経路１０３経由で、Ｂ／Ｅボード１４０の判断部１４１に入力する。
ＨＭＩ１５１は、ＣＡＮ１０１からＦ／Ｅ故障情報及びＢ／Ｅ故障情報を取得すると共に、ＣＡＮ１０１に運転モード及び緊急停止情報を送信する。

Ｂ／Ｅボード１４０の判断部１４１は、自車位置情報、道路勾配情報、カーブ曲率情報をＣＡＮ１０１経由で取得する。また、判断部１４１は、車両制御情報及びＢ／Ｅ故障情報をＣＡＮ１０１に送信すると共に、車両制御情報及びＢ／Ｅ故障情報を車両制御判断部１４２に入力する。
車両制御判断部１４２は、ＣＡＮ１０１から運転モード及びＦ／Ｅ故障情報を取得すると共に、ＣＡＮ１０１からセンシング情報を取得した緊急制御部１４３から緊急制御情報を取得する。

図３は、実施の形態１及び２における補助機器１を自動車に搭載した一例を示す概略図である。
自動車ＭＯには、車両制御システム１００が搭載されている。
単眼カメラ２は、自動車ＭＯの前方中央と後方中央に取り付けられており、夫々前方及び後方の物体を認識する。
ステレオカメラ３は、自動車ＭＯのフロントガラス上部に取り付けられ、前方の物体を認識する。
側方ソナー４は、自動車ＭＯの側方に取り付けられ、夫々右側方及び左側方を認識する。
ミリ波レーダ５は、自動車ＭＯの前方左右に取り付けられ、夫々前方の左右を走査する。
ソナー６は、自動車ＭＯの前方左右に取り付けられ、夫々前方の左右を走査する。
ＬＩＤＡＲ７は、自動車ＭＯの屋根中央に取り付けられ、自動車ＭＯの周囲全てを走査する。

図４は、実施の形態１におけるＣＳＭＷ１１１の内部ソフトウェア構造の一例を示すブロック図である。
図４では、複数の補助機器１の各々が第１センサ１ａ、第２センサ１ｂ、第３センサ１ｃ及び第４センサ１ｄからなるものとして示されている。また、第１センサ１ａ、第２センサ１ｂ、第３センサ１ｃ及び第４センサ１ｄは、それぞれ、第１ドライバ部１０６ａ、第２ドライバ部１０６ｂ、第３ドライバ部１０６ｃ及び第４ドライバ部１０６ｄにより動作される。

また、第１上位アプリ１３０ａ、第２上位アプリ１３０ｂ及び第３上位アプリ１３０ｃは、補助機器１及びＣＳＭＷ１１１よりも上位のアプリケーションである。例えば、上位アプリ１３０は、ＣＳＭＷ１１１及びドライバ部１０６を除いた、図２に示されているＦ／Ｅボード１１０に含まれている機能部を実現するためのアプリケーションである。

ＣＳＭＷ１１１は、第１インタフェース１７０と、第２インタフェース１７１と、メイン部１７２と、アプリケーション管理部１７３と、センサ管理部１７４と、コンフィグレーション生成管理部（以下、ＣＦＧ生成管理部という）１７５と、コンフィグレーションファイル記憶部（以下、ＣＦＧファイル記憶部という）１７６とを備える。

第１インタフェース１７０は、ＡＰＩである。例えば、上位アプリ１３０は、第１インタフェース１７０を介して、ＣＳＭＷ１１１と通信を行うことができる。
第２インタフェース１７１も、ＡＰＩである。例えば、補助機器１は、対応するドライバ部１０６を介して、ＣＳＭＷ１１１と通信を行うことができる。

アプリケーション管理部１７３は、ＣＳＭＷ１１１と通信を行う上位アプリ１３０を管理する。アプリケーション管理部１７３は、メイン部１７２に組み込まれており、メイン部１７２からコールされて処理を実行する。
アプリケーション管理部１７３は、アプリ要求受付部１７３ａと、アプリ要求パース部１７３ｂと、コンフィグレーション情報処理部（以下、ＣＦＧ情報処理部という）１７３ｃとを備える。

アプリ要求受付部１７３ａは、上位アプリ１３０から、データを取得する要求を受け付ける受付部である。上位アプリ１３０は、所望のタイミングで、所望のデータを取得する要求をアプリ要求受付部１７３ａに送る。
アプリ要求パース部１７３ｂは、アプリ要求受付部１７３ａで受け付けられた要求を分析し、その要求内容を分析結果としてＣＦＧ情報処理部１７３ｃに与える分析部である。
ＣＦＧ情報処理部１７３ｃは、アプリ要求パース部１７３ｂで分析された要求内容に従って、上位アプリ１３０からの要求内容、例えば、要求されたデータ（所望のデータ）の形式及び通信方法を記載するメタコンフィギュレーションファイル（以下、ＭＣＦＧファイルという）を生成して、ＣＦＧ生成管理部１７５に与える処理部である。なお、ＭＣＦＧファイルは、メタコンフィギュレーション情報ともいう。

ＣＦＧ生成管理部１７５は、ドライバ部１０６から、補助機器１を動作させるための変数及びＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）名を記載するコンフィギュレーションファイルを取得して、それをＣＦＧファイル記憶部１７６に記憶させるファイル管理部である。なお、ＣＦＧファイルは、コンフィギュレーション情報（ＣＦＧ情報）ともいう。
また、ＣＦＧ生成管理部１７５は、ＣＦＧ情報処理部１７３ｃから与えられたＭＣＦＧファイルに基づいて、要求されたデータを提供する補助機器を特定するとともに、センサ管理部１７４に、特定された補助機器１から要求されたデータを取得させる。

センサ管理部１７４は、補助機器１を、第２インタフェース１７１を介して管理する補助機器管理部である。例えば、センサ管理部１７４は、シンボル情報に記載された変数及びＡＰＩを使用して、ＣＦＧ生成管理部１７５で特定された補助機器１を動作させることで、その補助機器１から要求されたデータの提供を受ける。
なお、センサ管理部１７４は、メイン部１７２に組み込まれており、メイン部１７２からコールされて処理を実行する。

なお、ＣＳＭＷ１１１より下の階層の補助機器１及びドライバ部１０６を下位機能部１３１、ＣＳＭＷ１１１より上位の階層の上位アプリ１３０を上位機能部１３２という総称で呼ぶことにする。上位機能部１３２は、補助機器１から提供されるデータに基づいて、予め定められた制御を行う。

次に、上位アプリ１３０の内の１つである第２上位アプリ１３０ｂが、ＣＳＭＷ１１１を介して補助機器１から、データの組み合わせを所望のタイミングで取得する例を説明する。
ここでの、ＣＳＭＷ１１１を介して、という表現は正確にはＣＳＭＷ１１１にて第２上位アプリ１３０ｂが受け取れるデータに成型して第２上位アプリ１３０ｂにデータの組み合わせを渡すことをいう。
なお、補助機器１に含まれている第１センサ１ａ、第２センサ１ｂ、第３センサ１ｃ及び第４センサ１ｄの各々には、各々を識別するためのセンサ識別情報であるセンサＩＤが割り振られているものとする。

なお、補助機器１の１つのドライバ部１０６に対して１つのＣＦＧファイルが対応しており、そのＣＦＧファイルに記載されているデータ形式のデータは、上位機能部１３２に渡されてはいる。ここでは、これとは別に、例えば、第２上位アプリ１３０ｂが、第１センサ１ａのあるデータと、第２センサ１ｂのあるデータとの組み合わせを、データセットとして、所望のタイミングで取得する場合を説明する。

第２上位アプリ１３０ｂは、第１センサ１ａのあるデータと、第２センサ１ｂのあるデータとの組み合わせを、所望のタイミングで取得したい旨の要求を、ＣＳＭＷ１１１の第１インタフェース１７０を介して、アプリケーション管理部１７３のアプリ要求受付部１７３ａに送信する。

アプリ要求受付部１７３ａで受け付けられた要求は、アプリ要求パース部１７３ｂにて分析され、どのアプリケーションがどのセンサのどのデータを組み合わせて如何なるタイミングで所望しているかといった要求内容が、分析結果として把握される。この要求内容は、ＣＦＧ情報処理部１７３ｃに与えられる。

ＣＦＧ情報処理部１７３ｃは、与えられた要求内容を、ＭＣＦＧファイルとして整形して、ＣＦＧ生成管理部１７５に読み込ませる。

ＭＣＦＧファイルを読み込んだＣＦＧ生成管理部１７５は、ＭＣＦＧファイルに従って、要求されたデータの組み合わせをセンサ管理部１７４に要求する。
センサ管理部１７４は、要求されたデータの組み合わせをＣＦＧ情報処理部１７３ｃに送信する。
ＣＦＧ情報処理部１７３ｃは、受信されたデータの組み合わせを、要求されたタイミング（所望のタイミング）で、第１インタフェース１７０を介して第２上位アプリ１３０ｂに送信する。
以上のようにして、第２上位アプリ１３０ｂは、第１センサ１ａのあるデータと、第２センサ１ｂのあるデータとの組み合わせを、所望のタイミングで取得することができる。

図５は、実施の形態１におけるＣＳＭＷ１１１にて参照するＣＦＧファイルの一例を示す概略図である。
Ｆ／Ｅボード１１０に接続する１つの補助機器１に対して１つのＣＦＧファイルが必要である。図５に示されているＣＦＧファイル１８０は、ミリ波レーダ５を接続する際のものである。

接続するミリ波レーダ５の機種名はＭＷ−Ｒａｄｅｒであり、それに対応するＣＦＧファイル名は「ＭＷ−Ｒａｄｅｒ．ｉｎｉ」である。
ＣＦＧファイル１８０は、セクションと呼ばれるデータ領域で幾つかのブロックに区切られる。セクションは［］で括られた文字列で定義され、予め名称が規定された機能セクションと、任意の名称を持つデータ内容定義セクションと、データの変換規則を定義するデータ変換定義セクションとがある。

機能セクションは、どの補助機器１が接続されても共通して使用される名称を有する。例えば、図５に示された例では、［＿ＩＮＴＥＲＦＡＣＥ＿］、［＿ＳＴＲＵＣＴＵＲＥ＿］及び［＿ＤＡＴＡ＿ＳＰＥＣ＿］が機能セクションである。データ内容定義セクションは、接続された補助機器１毎にコーディングする必要があり、そのコード上に表れる変数の名称を示す。例えば、図５に示された例では、［Ｖｅｌｏｃｉｔｙ］、［ＣｕｒｖｅＲａｄｉｕｓ］及び［ＲａｎｇｅＤｉｓｔａｎｃｅ］がデータ内容定義セクションである。
なお、データ変換定義セクションは、［＿ＤＡＴＡ＿ＳＰＥＣ＿］である。

ＣＦＧファイル１８０にて最初に記載されているのは、インタフェース情報セクション［＿ＩＮＴＥＲＦＡＣＥ＿］である。
「ＳｅｎｓｏｒＮａｍｅ」は、接続される補助機器１の名称を示す。ここでは、ミリ波レーダ５の名称「ＭＷ−Ｒａｄｅｒ」が定義されている。
「ＳｅｎｓｏｒＩｄ」は、接続される補助機器１の識別情報（センサＩＤ）を示す。ここでは、ミリ波レーダ５のＩＤ「ｓｅｎｓ１」が定義されている。
「ＵｐＩｎｄＭｏｄｅ」は、ＣＳＭＷ１１１からのデータの通知方式を示す。例えば、データ通知方式は、「０」〜「２」の整数で定義されている。図５の例では、「０」が選択され、データが生成されたら、逐一、ＣＳＭＷ１１１から通知されることが示されている。なお、「１」の場合には、周期コールバックで通知され、「２」の場合には、ポーリングで通知される。

「ＡｕｔｏＳｔａｒｔ」は、接続される補助機器１が、ＣＳＭＷ１１１を実行するアプリケーションが起動したときに自動的に起動するか否かを示す。例えば、「０」の場合には、自動的に起動しないことを示し、「１」の場合には、自動的に起動することを示す。
「ＤｎＩｆＴｙｐｅ」は、補助機器１からデータを取得するインタフェースの種別を示す。例えば、インタフェースの種別は、「０」〜「３」の整数で定義されている。「０」はライブラリ、「１」はメモリ、「２」はＣＡＮ１０１、及び、「３」はイーサネット１０２を示す。図５の例では、インタフェースとして、ＣＡＮ１０１が選択されている。

「ＤｎＩｆＰａｒａｍ」及び「ＤｎＣａｎＩＤ」は、インタフェースとしてＣＡＮ１０１が選択されたために定義されたものである。
「ＤｎＩｆＰａｒａｍ」は、ＣＡＮ１０１を使用する場合のＣＡＮ１０１の系統番号を示す。
「ＤｎＣａｎＩＤ」は、データファイリング用のＣＡＮ１０１のメッセージＩＤであるＣＡＮ ＩＤを示す。図５の例では、ＣＡＮ ＩＤとして「ｈ７３０」又は「ｈ７３１」の何れかが用いられることが示されている。

次に、［＿ＳＴＲＵＣＴＵＲＥ＿］セクションは、上位提供データ構造定義セクションであり、補助機器１から取得されたデータを、ＣＳＭＷ１１１が上位アプリ１３０に提供するデータの構造を定義する。［＿ＳＴＲＵＣＴＵＲＥ＿］セクションにより、補助機器１（ここでは、ミリ波レーダ５）が提供するデータを特定することができる。
図５では、［＿ＳＴＲＵＣＴＵＲＥ＿］セクションで定義されるデータ構造体のメンバ変数として、「Ｖｅｌｏｃｉｔｙ（速度）」、「ＣａｒｖｅＲａｄｉｕｓ（転回半径）」、「ＲａｎｇｅＤｉｓｔａｎｃｅ（物体距離）」、「ＲａｎｇｅＲａｔｅ（物体速度）」及び「Ａｎｇｌｅ（物体角度）」が含まれており、それぞれ、３２ビットで構成されている。

次に、［＿ＤＡＴＡ＿ＳＰＥＣ＿］セクションは、補助機器１から取得されたデータの形式を、ＣＳＭＷ１１１が上位アプリ１３０に提供するデータの形式に変換する変換規則を定義するデータ変換定義セクションである。
図５に示されている例では、［＿ＤＡＴＡ＿ＳＰＥＣ＿］セクションは、［＿ＳＴＲＵＣＴＵＲＥ＿］セクションで定義された構造体メンバの各々に対して、変換規則が定義されている。
例えば、［＿ＳＴＲＵＣＴＵＲＥ＿］の構造体メンバである［Ｖｅｌｏｃｉｔｙ］では、「ＩｄＦ」は、データを取得するインタフェースの種別を示し、図５の例では、ＣＡＮ１０１からデータを取得することが示されている。「Ｉｄ」は、ＣＡＮ ＩＤを示し、「Ｏｘ７３０」のＣＡＮ ＩＤで送られてきたデータが速度を格納していることを示している。「Ｆ」は、上述のように変数そのものを示し、「＃２」は、データの２バイト目の１バイトが変数の値であることを示している。

以上のように、ＣＦＧファイル１８０には、使用するＡＰＩ群の定義、メンバ変数の宣言及び定義等の情報が記載される。

なお、従来例では上位のアプリケーションを変えることなくドライバからのセンサデータをその上位のアプリケーションで利用可能なデータにするためには、そのセンサデータに即した変換テーブルを作成し、ドライバからのセンサデータの変換部が変換テーブルを参照して変換しなければならない。この変換テーブルの作成は、煩雑であり、変換テーブルの作成は、異なるセンサ毎に行われなければならない。
それに対し、実施の形態１では、各種センサ等の補助機器１と、上位アプリ１３０との間にＣＳＭＷ１１１が備えられ、各センサを動作させるのに用いるドライバ部１０６の処理に必要な構造体及び関数の定義がＣＦＧファイルに記載されている。このため、ＣＳＭＷ１１１は、ＣＦＧファイルにアクセスすることで、対応するドライバ部１０６からの情報を上位アプリ１３０に与えることができる。

図６は、実施の形態１におけるＣＳＭＷ１１１にて参照するＭＣＦＧファイルの一例を示す概略図である。
図６に示されているＭＣＦＧファイル１８１は、第２上位アプリ１３０ｂ（アプリケーションＩＤ：ａｐｐ２）が、センサＩＤとして「ｓｅｎｓ１」が割り当てられている補助機器１と、センサＩＤとして「ｓｅｎｓ２」が割り当てられている補助機器１とから、それぞれのデータの組み合わせを要求した際に、ＣＦＧ情報処理部１７３ｃで生成されたものである。

ここでは、「ｍｅｔａ−Ｃｆｉｇ１．ｉｎｉ」というファイル名が付されたＭＣＦＧファイル１８１として説明するが、同様の内容の情報（メタコンフィギュレーション情報）が、単なるデータとして図示されていないメモリ内に展開されていてもよい。

ＭＣＦＧファイル１８１は、セクションと呼ばれるデータ領域で幾つかのブロックに区切られる。セクションは［］で括られた文字列で定義され、予め名称が規定された機能セクションがある。
図６に示されている例では、［＿ＩＮＴＥＲＦＡＣＥ＿］セクション及び［＿ＳＴＲＵＣＴＵＲＥ＿］セクションが、予め名称が規定された機能セクションである。

ＭＣＦＧファイル１８１にて最初に記載されているのは、インタフェース情報セクション［＿ＩＮＴＥＲＦＡＣＥ＿］である。
「ＡｐｐｌｉＩｄ」は、要求元のアプリケーションである上位アプリ１３０を識別するための識別情報（アプリケーションＩＤ）を示す。ここでは、第２上位アプリ１３０ｂのアプリケーションＩＤ（ａｐｐ２）が示されている。
「ＳｅｎｓｏｒＩｄ」は、データの要求対象である補助機器１の識別情報（センサＩＤ）を示す。ここでは、「ｓｅｎｓ１」及び「ｓｅｎｓ２」のセンサＩＤが示されている。
「ＵｐＳｎｄＴｉｍｉｎｇ」は、要求されたデータを要求元アプリケーションへ送信する際の送信タイミングを示す。ここでは、データの送信周期（［ｍｓ］単位）が示されている。
「ＵｐＳｎｄＷａｉｔ」は、データの送信が、「ＵｐＳｎｄＴｉｍｉｎｇ」で示されているタイミングから遅れる場合に、許容される遅延時間を示す値である送信ウェイト間隔を示す。
「ＵｐＩｆＴｙｐｅ」は、要求元の上位アプリ１３０へ送信する際に使用されるインタフェースの種別を示す。

「ＡｐｐｌｉＩｄ」、「ＳｅｎｓｏｒＩｄ」、「ＵｐＳｎｄＴｉｍｉｎｇ」、「ＵｐＳｎｄＷａｉｔ」及び「ＵｐＩｆＴｙｐｅ」は、その文字列が予め決められた固定文字列であり、ＣＦＧ生成管理部１７５は、その固定文字列から内容を把握することができる。

次に、［＿ＳＴＲＵＣＴＵＲＥ＿］セクションは、上位提供データ構造定義セクションであり、補助機器１から提供されたデータの組み合わせを、ＣＳＭＷ１１１が上位アプリ１３０に提供するデータの構造を定義する。
図６では、［＿ＳＴＲＵＣＴＵＲＥ＿］セクションで定義されるデータ構造体のメンバ変数として、「ｓｅｎｓ１．Ｖｅｌｏｃｉｔｙ」、「ｓｅｎｓ１．ＣａｒｖｅＲａｄｉｕｓ」、「ｓｅｎｓ１．ＲａｎｇｅＤｉｓｔａｎｃｅ」、「ｓｅｎｓ２．ＲａｎｇｅＲａｔｅ」及び「ｓｅｎｓ２．Ａｎｇｌｅ」が含まれており、それぞれ３２ビットで構成されている。

「ｓｅｎｓ１．Ｖｅｌｏｃｉｔｙ」は、「ｓｅｎｓ１」で識別される補助機器１から提供される速度のデータを示す。
「ｓｅｎｓ１．ＣａｒｖｅＲａｄｉｕｓ」は、「ｓｅｎｓ１」で識別される補助機器１から提供される転回半径のデータを示す。
「ｓｅｎｓ１．ＲａｎｇｅＤｉｓｔａｎｃｅ」は、「ｓｅｎｓ１」で識別される補助機器１から提供される物体距離のデータを示す。
「ｓｅｎｓ２．ＲａｎｇｅＲａｔｅ」は、「ｓｅｎｓ２」で識別される補助機器１から提供される物体速度のデータを示す。
「ｓｅｎｓ２．Ａｎｇｌｅ」は、「ｓｅｎｓ２」で識別される補助機器１から提供される物体角度のデータを示す。

以上のようなＭＣＦＧファイル１８１は、ＣＦＧ生成管理部１７５によって読み込まれ、ＣＦＧ情報処理部１７３ｃは、センサ管理部１７４から、ＭＣＦＧファイル１８１で示されたデータの組み合わせを受け取り、第１インタフェース１７０を介して、それを構造体として第２上位アプリ１３０ｂへ送信することができる。

以上に記載されたＦ／Ｅボード１１０、Ｂ／Ｅボード１４０及びナビボード１５０のそれぞれの一部又は全部は、例えば、図７（Ａ）に示されているように、メモリ１９０と、メモリ１９０に格納されているプログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等のプロセッサ１９１とにより構成することができる。このようなプログラムは、ネットワークを通じて提供されてもよく、また、記録媒体に記録されて提供されてもよい。

また、Ｆ／Ｅボード１１０、Ｂ／Ｅボード１４０及びナビボード１５０のそれぞれの一部又は全部は、例えば、図７（Ｂ）に示されているように、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔｓ）又はＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等の処理回路１９２で構成することもできる。

図８は、実施の形態１において、ＣＳＭＷ１１１を介して、データを下位機能部１３１から上位機能部１３２に渡す処理の一例を示すステートチャート図である。
ＣＳＭＷ１１１は、機能部又はドライバ部１０６との間でデータの入出力を行う。具体的には、機能部にデータを提供する「データ通知」であり、実施の形態１では同期方式でデータを下位機能部１３１から上位機能部１３２へ渡す例を説明する。

同期方式でデータを下位機能部１３１から上位機能部１３２へ渡すにあたって、まず、ＣＳＭＷ１１１は、Ｆ／Ｅボード１１０に接続されている各種補助機器１の構成を把握するため、機器構成情報を取得する。この際、接続されている各種補助機器１毎にＣＦＧファイルが用意されており、下位機能部１３１は、対応するＣＦＧファイルをロードする（Ｓ１０）。

そして、ＣＳＭＷ１１１が各々の補助機器１の実体を提供する機器登録処理を上位機能部１３２がコールし（Ｓ１１）、機器登録メッセージ（登録命令）をＣＳＭＷ１１１が受信する（Ｓ１２）。

下位機能部１３１は、ＣＳＭＷ１１１がインタフェース仕様を提示したフィルタ設定処理をコールし（Ｓ１３）、機器動作に必要なメンバ変数のシンボル及びＡＰＩのシンボルが記載されたシンボル情報を取得する（Ｓ１４）。シンボル情報は、変数のシンボル及びＡＰＩのシンボルとそのアドレスとを対応付けた情報である。
ＣＳＭＷ１１１は、このシンボル情報を取得して（Ｓ１５）、取得されたシンボル情報とロードされたＣＦＧファイルとを比較して、機器動作に必要なメンバ変数のシンボル及びＡＰＩのシンボルを把握することが可能となる。例えば、ＣＳＭＷ１１１は、ＣＦＧファイルで把握された変数及びＡＰＩと、シンボル情報に含まれている変数のシンボル及びＡＰＩのシンボルとを比較し、これらが一致した場合には、対応するアドレスから変数のシンボル及びＡＰＩのシンボルを呼び出すことができるようになる。

続いて、ＣＳＭＷ１１１が実体を提供する機器開始処理を上位機能部１３２がコールし（Ｓ１６）、機器開始メッセージ（開始命令）をＣＳＭＷ１１１が受信する（Ｓ１７）。

下位機能部１３１は、ＣＳＭＷ１１１がインタフェース仕様を提示した機器受信開始処理をコールし（Ｓ１８）、補助機器１からのデータ受信を開始するのに必要な処理を行う（Ｓ１９）。

ＣＳＭＷ１１１は、ＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）バッファ生成処理を行い、上りＦＩＦＯバッファ１３４を生成する（Ｓ２０）。

そして、機器受信開始処理（Ｓ１９）を行った下位機能部１３１は、データＤＤを受信してフィルタリング処理を行い（Ｓ２１）、バッファ１３５にデータＤＤをＰＵＳＨする（Ｓ２２）。

さらに、ＣＳＭＷ１１１は、機器データリード処理をコールし（Ｓ２３）、下位機能部１３１のバッファ１３５にＰＵＳＨされたデータＤＤをＰＵＬＬして読み込み、データＤＤをＣＳＭＷ１１１が取り込む（Ｓ２４）。

所望のデータＤＤを取り込んだＣＳＭＷ１１１は、データ変換処理を行い（Ｓ２５）、ステップＳ２０で生成された上りＦＩＦＯバッファ１３４にデータＤＤをＰＵＳＨする（Ｓ２６）。

ここで上位機能部１３２は、ＣＳＭＷ１１１が実体を提供する機器データリード処理をポーリングで行い（Ｓ２７）、上りＦＩＦＯバッファ１３４からＰＵＬＬしてデータＤＤを取得する（Ｓ２８）。

以上説明した本実施の形態１によれば、下記（１）及び（２）の効果が得られ得る。
（１）実施の形態１では、車両制御システム１００は、自動車ＭＯに搭載された単眼カメラ２、ステレオカメラ３、ミリ波レーダ５、ソナー６又はＬＩＤＡＲ７といった各種補助機器１、これら各種補助機器１を動作させる機能部、及び、下位機能部１３１から上位機能部１３２へデータを受け渡すＣＳＭＷ１１１から構成される。各種補助機器１は、自動車ＭＯに搭載されているが、常に同じ機器に置換されるとは限らず、異なるバージョンの機器又は仕様の異なる他社の機器に置換されることもある。例えば、ミリ波レーダ５が他社製のミリ波レーダに置き換えられることもある。この場合、この補助機器１のＣＦＧファイルに、この補助機器１を動作させるための構造体及びＡＰＩを定義すれば、ＣＳＭＷ１１１は、起動時にそのＣＦＧファイルを読み込むだけで、ＣＳＭＷ１１１及びその上位機能部１３２を変更することなく、上位機能部１３２は下位機能部１３１からのデータを、同期方式で取得することができる。なお、この場合、この補助機器１のドライバ部１０６に相当する下位機能部１３１のみを改修するだけで、補助機器１の置換ができ、ＣＳＭＷ１１１の上位アプリ１３０は変える必要がないため、様々な開発現場でドライバ部１０６に相当する機能部のみを開発するだけで済む。このため、車両制御システム１００は、アプリケーションサポートパッケージとして製品化することが可能である。

（２）さらに、特定の上位アプリ１３０が、指定したデータ又は指定したデータの組み合わせを所望の周期で取得する場合、その特定の上位アプリ１３０は、アプリケーション管理部１７３にこれら要求を送信し、その要求を基にアプリケーション管理部１７３にて自動生成されたＭＣＦＧファイルを基にセンサ管理部１７４から所望のデータ又は所望のデータの組み合わせが取得される。このため、アプリケーション管理部１７３は、その特定の上位アプリ１３０が所望するデータ又は所望するデータの組み合わせを所望の周期で送信することが可能である。なお、この場合、この補助機器１のドライバ部１０６に相当する下位機能部１３１のみを改修するだけで、補助機器１の置換ができ、ＣＳＭＷ１１１の上位アプリ１３０は変える必要がないため、様々な開発現場でドライバ部１０６に相当する機能部のみを開発するだけで済む。このため、車両制御システム１００は、アプリケーションサポートパッケージとして製品化することができる。

実施の形態２．
以下、実施の形態２を示す。
図１に示されているように、実施の形態２に係る車両制御システム２００は、補助機器１と、Ｆ／Ｅボード２１０と、Ｂ／Ｅボード１４０と、ナビボード１５０とを備える。
そして、Ｆ／Ｅボード２１０及びＢ／Ｅボード１４０により、車両の制御を行う制御装置２０５が構成される。制御装置２０５は、補助機器１を接続し、補助機器１から得られる情報に基づいて制御を行う。
実施の形態２に係る車両制御システム２００は、Ｆ／Ｅボード２１０を除いて、実施の形態１に係る車両制御システム１００と同様に構成されている。

図２に示されているように、実施の形態２におけるＦ／Ｅボード２１０は、ＣＳＭＷ２１１を除いて、実施の形態１におけるＦ／Ｅボード１１０と同様に構成されている。

図９は、実施の形態２におけるＣＳＭＷ２１１の内部ソフトウェア構造の一例を示すブロック図である。
図９では、複数の補助機器１の各々が第１センサ１ａ、第２センサ１ｂ、第３センサ１ｃ及び第４センサ１ｄからなるものとして示されている。また、第１センサ１ａ、第２センサ１ｂ、第３センサ１ｃ及び第４センサ１ｄは、それぞれ、第１ドライバ部１０６ａ、第２ドライバ部１０６ｂ、第３ドライバ部１０６ｃ及び第４ドライバ部１０６ｄにより動作される。

また、第１上位アプリ１３０ａ、第２上位アプリ１３０ｂ及び第３上位アプリ１３０ｃは、補助機器１及びＣＳＭＷ２１１よりも上位のアプリケーションである。例えば、上位アプリ１３０は、ＣＳＭＷ２１１及びドライバ部１０６を除いた、図２に示されているＦ／Ｅボード２１０に含まれている機能部を実現するためのアプリケーションである。

ＣＳＭＷ２１１は、第１インタフェース１７０と、第２インタフェース１７１と、メイン部１７２と、アプリケーション管理部２７３と、センサ管理部２７４と、ＣＦＧ生成管理部２７５と、ＣＦＧファイル記憶部１７６とを備える。
実施の形態２におけるＣＳＭＷ２１１の第１インタフェース１７０、第２インタフェース１７１、メイン部１７２及びＣＦＧファイル記憶部１７６は、実施の形態１におけるＣＳＭＷ１１１の第１インタフェース１７０、第２インタフェース１７１、メイン部１７２及びＣＦＧファイル記憶部１７６と同様である。

アプリケーション管理部２７３は、ＣＳＭＷ２１１と通信を行う上位アプリ１３０を管理する。アプリケーション管理部２７３は、メイン部１７２に組み込まれており、メイン部１７２からコールされて処理を実行する。

図１０は、アプリケーション管理部２７３の構成を概略的に示すブロック図である。
アプリケーション管理部２７３は、アプリ要求受付部２７３ａと、アプリ要求パース部２７３ｂと、アプリ要求整合管理部２７３ｃと、変換部２７３ｄと、メタコンフィギュレーション情報生成部（以下、ＭＣＦＧ情報生成部という）２７３ｇと、アプリ要求情報伝達部２７３ｈとを備える。

アプリ要求受付部２７３ａは、上位アプリ１３０から、データを取得する要求を受け付ける受付部である。上位アプリ１３０は、所望のデータを所望のタイミングで取得するように要求を行うものとする。
アプリ要求パース部２７３ｂは、アプリ要求受付部１７３ａで受け付けられた要求を分析し、その要求内容を分析結果としてアプリ要求整合管理部２７３ｃに与える分析部である。

アプリ要求整合管理部２７３ｃは、ＣＦＧ生成管理部２７５と連携して、アプリ要求パース部２７３ｂから与えられた要求内容を確認し、上位アプリ１３０から要求されたデータ（所望のデータ）に一致するデータが、補助機器１から提供されるデータ（提供データ）にあるか否かを判断する。そして、上位アプリ１３０から要求されたデータに一致するデータが、補助機器１から提供されるデータにない場合には、アプリ要求整合管理部２７３ｃは、変換部２７３ｄ及びＭＣＦＧ情報生成部２７３ｇに指示することで、補助機器１から提供される特定のデータを上位アプリ１３０から要求されたデータに変換するための変換方法を含むＭＣＦＧファイルを生成させる。なお、上位アプリ１３０から要求されたデータが、補助機器１から得られるデータにある場合には、アプリ要求整合管理部２７３ｃは、ＭＣＦＧ情報生成部２７３ｇに指示することで、実施の形態１と同様のＭＣＦＧファイルを生成させる。

また、アプリ要求整合管理部２７３ｃは、ＣＦＧ生成管理部２７５と連携して、補助機器１が取り替えられた後に、上位アプリ１３０から要求されたデータと一致するデータが、補助機器１から提供されるデータにあるか否かを判断する。そして、上位アプリ１３０から要求されたデータと一致するデータが、補助機器１から提供されるデータにない場合には、アプリ要求整合管理部２７３ｃは、変換部２７３ｄ及びＭＣＦＧ情報生成部２７３ｇに指示することで、補助機器１から提供される特定のデータを上位アプリ１３０から要求されたデータに変換するための変換方法を含むＭＣＦＧファイルを生成させる。

変換部２７３ｄは、補助機器１から提供される特定のデータを上位アプリ１３０から要求されたデータに変換するための変換方法を特定する。
変換部２７３ｄは、単位変換部２７３ｅと、式変換部２７３ｆとを備える。

単位変換部２７３ｅは、アプリ要求整合管理部２７３ｃからの指示に従って、補助機器１から提供される特定のデータの単位を、上位アプリ１３０から要求されたデータの単位に変換する変換規則を特定し、特定された変換規則を変換方法としてＭＣＦＧ情報生成部２７３ｇに通知する。例えば、単位変換部２７３ｅは、単位の変換規則を示す単位変換テーブルを参照することで、単位の変換規則を特定する。

図１１は、単位変換テーブルの一例を示す概略図である。
単位変換テーブル１３６は、単位を変更する際の変換規則を示す。
例えば、図１１に示されている「速度」の項目の「１ｋｍ／ｈ」及び「１０００／３６００ｍ／ｓ」は、速度の単位である「ｋｍ／ｈ」と「ｍ／ｓ」との変換規則を示している。補助機器１から提供される速度のデータが、従来ｋｍ／ｈ単位であったが、補助機器１の置換等により、ｍ／ｓ単位になった場合には、補助機器１から提供されるｍ／ｓ単位のデータに、（３６００／１０００）を掛ける必要がある。一方、補助機器１から提供される速度のデータが、従来ｍ／ｓであったが、補助機器１の置換等により、ｋｍ／ｈになった場合には、補助機器１から提供されるｋｍ／ｈ単位のデータに、（１０００／３６００）を掛ける必要がある。
その他にも、図１１では、「緯度、経度」、「高度」及び「角度」の単位の変換規則を示しているが、実施の形態２においては、その他考えられる単位の変換規則を網羅して単位変換テーブルに格納しておく必要がある。

図１０に戻り、式変換部２７３ｆは、アプリ要求整合管理部２７３ｃからの指示に従って、上位アプリ１３０から要求されたデータを、補助機器１から提供される特定のデータから算出するための算出式を特定し、特定された算出式を変換方法としてＭＣＦＧ情報生成部２７３ｇに通知する。例えば、式変換部２７３ｆは、算出式を示す式変換テーブルを参照することで、算出式を特定する。

図１２は、式変換テーブルの一例を示す概略図である。
式変換テーブル１３７は、複数の特定のデータを用いて別のデータを算出する算出式を示す。
例えば、図１２に示されている「絶対速度」の項目の「ａｂｓｌｔＶｅｌｏｃｉｔｙ」及び「ｒｅｌａｔｉｖｅＶｅｌｏｃｉｔｙ＋ｏｗｎＶｅｌｏｃｉｔｙ」は、絶対速度を相対速度から算出する算出式を示している。補助機器１から提供される速度のデータが、従来絶対速度であったが、補助機器１の置換等により、相対速度になった場合には、補助機器１から提供される相対速度（ｒｅｌａｔｉｖｅＶｅｌｏｃｉｔｙ）に自車速度（ｏｗｎＶｅｌｏｃｉｔｙ）を加える必要がある。
また、図１２に示されている「１ｔｒｉｐ平均速度」の項目の「ａｖｒｇＶｅｌｏｃｉｔｙ」及び「１ｔｒｉｐＤｉｓｔａｎｃｅ／１ｔｒｉｐＴｉｍｅ」は、１回の走行における平均速度を、１回の走行における走行距離及び走行時間から算出する算出式を示している。
その他にも、図１２では、「１ｔｒｉｐ後累積距離」を算出する算出式を示しているが、実施の形態２においては、その他考えられる内容の算出式を網羅して式変換テーブルに格納しておく必要がある。

図１０に戻り、ＭＣＦＧ情報生成部２７３ｇは、アプリ要求整合管理部２７３ｃからの指示に応じて、アプリ要求整合管理部２７３ｃから与えられた要求内容を、ＭＣＦＧファイルとして整形して、ＣＦＧ生成管理部２７５に読み込ませる処理部である。
ここで、ＭＣＦＧ情報生成部２７３ｇは、アプリ要求整合管理部２７３ｃからの指示に応じて、上位アプリ１３０から要求されたデータが補助機器１から提供されるデータにある場合には、実施の形態１と同様のＭＣＦＧファイルを生成する。
一方、ＭＣＦＧ情報生成部２７３ｇは、アプリ要求整合管理部２７３ｃからの指示に応じて、上位アプリ１３０から要求されたデータが補助機器１から提供されるデータにない場合には、ＭＣＦＧファイルに変換部２７３ｄから通知される変換方法を含める。

なお、ＭＣＦＧ情報生成部２７３ｇは、ＣＦＧ生成管理部２７５に問い合わせることにより、式変換部２７３ｆから与えられる算出式で用いられる特定のデータを提供する補助機器１を特定し、ＭＣＦＧファイルにおいて、特定された補助機器１を示す。
さらに、ＭＣＦＧ情報生成部２７３ｇは、複数のデータを用いて、算出式により算出されたデータの単位を変更する必要がある場合等、単位変換部２７３ｅから通知される変換規則と、式変換部２７３ｆから通知される算出式とを組み合わせる必要がある場合には、これらを組み合わせた変換方法をＭＣＦＧファイルに示す。

図１３は、実施の形態２におけるＣＳＭＷ２１１にて参照するＭＣＦＧファイルの一例を示す概略図である。
図１３に示されているＭＣＦＧファイル２８１は、第１上位アプリ１３０ａ（アプリケーションＩＤ：ａｐｐ１）及び第２上位アプリ１３０ｂ（アプリケーションＩＤ：ａｐｐ２）が、センサＩＤとして「ｓｅｎｓ１」が割り当てられている補助機器１と、センサＩＤとして「ｓｅｎｓ３」が割り当てられている補助機器１と、センサＩＤとして「ｓｅｎｓ４」が割り当てられている補助機器１とから、それぞれのデータの組み合わせを要求した際に、ＭＣＦＧ情報生成部２７３ｇで生成されたものである。
また、図１３に示されているＭＣＦＧファイル２８１は、上位アプリ１３０から要求されたデータと一致するデータが補助機器１から提供されるデータにない場合に生成されるファイルである。

ここでは、「ｍｅｔａ−Ｃｆｉｇ２．ｉｎｉ」というファイル名が付されたＭＣＦＧファイル２８１として説明するが、同様の内容の情報（メタコンフィギュレーション情報）が、単なるデータとして図示されていないメモリ内に展開されていてもよい。

ＭＣＦＧファイル２８１は、セクションと呼ばれるデータ領域で幾つかのブロックに区切られる。セクションは［］で括られた文字列で定義され、予め名称が規定された機能セクションと、任意の名前を持つデータ内容定義セクション、及び、データの変換方法を定義するデータ変換定義セクションがある。
図１３に示されている例では、［＿ＩＮＴＥＲＦＡＣＥ＿］セクション、［＿ＳＴＲＵＣＴＵＲＥ＿］セクション及び［＿ＤＡＴＡ＿ＳＰＥＣ＿］セクションが、予め名称が規定された機能セクションであり、［ａｂｓｌｔＶｅｌｏｃｉｔｙ］セクション及び［ａｖｒｇＶｅｌｏｃｉｔｙ］セクションが、任意の名前を持つデータ内容定義セクションであり、［＿ＤＡＴＡ＿ＳＰＥＣ＿］セクションが、データの変換方法を定義するデータ変換定義セクションである。

ＭＣＦＧファイル２８１にて最初に記載されているのは、インタフェース情報セクション［＿ＩＮＴＥＲＦＡＣＥ＿］である。
「ＡｐｐｌｉＩｄ」は、要求元のアプリケーションである上位アプリ１３０を識別するための識別情報（アプリケーションＩＤ）を示す。ここでは、第１上位アプリ１３０ａのアプリケーションＩＤ（ａｐｐ１）及び第２上位アプリ１３０ｂのアプリケーションＩＤ（ａｐｐ２）が示されている。
「ＳｅｎｓｏｒＩｄ」は、データの要求対象である補助機器１の識別情報（センサＩＤ）を示す。ここでは、「ｓｅｎｓ１」、「ｓｅｎｓ３」及び「ｓｅｎｓ４」のセンサＩＤが示されている。
「ＵｐＳｎｄＴｉｍｉｎｇ」は、要求されたデータを要求元アプリケーションへ送信する際の送信タイミングを示す。ここでは、データの送信周期（［ｍｓ］単位）が示されている。
「ＵｐＳｎｄＷａｉｔ」は、データの送信が、「ＵｐＳｎｄＴｉｍｉｎｇ」で示されているタイミングから遅れる場合に、許容される遅延時間を示す値である送信ウェイト間隔を示す。
「ＵｐＩｆＴｙｐｅ」は、要求元の上位アプリ１３０へ送信する際に使用されるインタフェースの種別を示す。

次に、［＿ＳＴＲＵＣＴＵＲＥ＿］セクションは、上位提供データ構造定義セクションであり、補助機器１から提供されたデータの組み合わせを、ＣＳＭＷ２１１が上位アプリ１３０に提供するデータの構造を定義する。
図１３では、［＿ＳＴＲＵＣＴＵＲＥ＿］セクションで定義されるデータ構造体のメンバ変数として、「ａｂｓｌｔＶｅｌｏｃｉｔｙ」、「ａｖｒｇＶｅｌｏｃｉｔｙ」、「ｓｅｎｓ１．ＲａｎｇｅＤｉｓｔａｎｃｅ」、「ｓｅｎｓ４．ｓｈｅｅｔＰｏｓｉｔｉｏｎ」及び「ｓｅｎｓ４．ｓｈｅｅｔＴｅｍｐ」が含まれている。
「ａｂｓｌｔＶｅｌｏｃｉｔｙ」、「ａｖｒｇＶｅｌｏｃｉｔｙ」及び「ｓｅｎｓ１．ＲａｎｇｅＤｉｓｔａｎｃｅ」は、それぞれ３２ビットで構成されており、「ｓｅｎｓ４．ｓｈｅｅｔＰｏｓｉｔｉｏｎ」及び「ｓｅｎｓ４．ｓｈｅｅｔＴｅｍｐ」は、それぞれ１６ビットで構成されている。

「ａｂｓｌｔＶｅｌｏｃｉｔｙ」は、対象となる補助機器１から提供される絶対速度のデータを示す。
「ａｖｒｇＶｅｌｏｃｉｔｙ」は、対象となる補助機器１から提供される、１ｔｒｉｐにおける平均速度のデータを示す。１ｔｒｉｐは、１回の走行を示し、例えば、自動車ＭＯのエンジンをかけてから、それを停止するまでの間を示す。
「ｓｅｎｓ１．ＲａｎｇｅＤｉｓｔａｎｃｅ」は、「ｓｅｎｓ１」で識別される補助機器１から提供される物体距離のデータを示す。
「ｓｅｎｓ４．ｓｈｅｅｔＰｏｓｉｔｉｏｎ」は、「ｓｅｎｓ４」で識別される補助機器１から提供されるシート位置のデータを示す。
「ｓｅｎｓ４．ｓｈｅｅｔＴｅｍｐ」は、「ｓｅｎｓ４」で識別される補助機器１から提供されるシート温度のデータを示す。

次に、［＿ＤＡＴＡ＿ＳＰＥＣ＿］セクションは、データ変換定義セクションであり、単位変換及び式変換を使用して、ある補助機器１から提供されるデータの単位又は内容を変換したり、補助機器１から提供される複数のデータから１つのデータを作成したりする際の変換方法を定義する。

ここでは、［＿ＤＡＴＡ＿ＳＰＥＣ＿］セクションは、［＿ＳＴＲＵＣＴＵＲＥ＿］で定義された構造体メンバの内、単位変換及び式変換を使用して提供データ形式へ変換する場合の変換方法を定義する。図１３では、［＿ＳＴＲＵＣＴＵＲＥ＿］で定義された「ａｂｓｌｔＶｅｌｏｃｉｔｙ」及び「ａｖｒｇＶｅｌｏｃｉｔｙ」について、図１２に示されている式変換テーブル１３７を参照することにより特定された変換式が示されている。

例えば、「ａｂｓｌｔＶｅｌｏｃｉｔｙ」には、「ｓｅｎｓ１」で識別される補助機器１から提供される「ｒｅｌａｔｉｖｅＶｅｌｏｃｉｔｙ（相対速度）」の値と、「ｓｅｎｓ３」で識別される補助機器１から提供される「ｏｗｎＶｅｌｏｃｉｔｙ（自車速度）」の値とを用いて、絶対速度を算出する算出式が変換方法として示されている。
「ａｖｒｇＶｅｌｏｃｉｔｙ」には、「ｓｅｎｓ１」で識別される補助機器１から提供される「１ｔｒｉｐＤｉｓｔａｎｃｅ」の値と、「ｓｅｎｓ１」で識別される補助機器１から提供される「１ｔｒｉｐＴｉｍｅ」の値とを用いて、平均速度を算出する算出式が変換方法として示されている。

図１０に戻り、アプリ要求情報伝達部２７３ｈは、センサ管理部２７４から受信されたデータの組み合わせを、要求されたタイミング（所望のタイミング）で、第１インタフェース１７０を介して上位アプリ１３０に送る伝送部である。

図９に戻り、ＣＦＧ生成管理部２７５は、ドライバ部１０６から、補助機器１を動作させるための変数及びＡＰＩを記載するコンフィギュレーションファイルを取得して、それをＣＦＧファイル記憶部１７６に記憶させるファイル管理部である。ここでは、ＣＦＧ生成管理部２７５は、補助機器１の各々に対応する１つのドライバ部１０６を解析して自動的に定型文形式のＣＦＧファイルを生成しているが、管理者等の人が、適宜、ドライバ部１０６に対応するＣＦＧファイルを作成してもよい。

図１４は、実施の形態２におけるＣＳＭＷ２１１にて参照するＣＦＧファイルの一例を示す概略図である。
Ｆ／Ｅボード２１０に接続する１つの補助機器１に対して１つのＣＦＧファイルが必要である。図１４に示されているＣＦＧファイル２８０は、ミリ波レーダ５を接続する際のものである。

接続するミリ波レーダ５の機種名はＭＷ−Ｒａｄｅｒであり、それに対応するＣＦＧファイル名は「ＭＷ−Ｒａｄｅｒ．ｉｎｉ」である。
ＣＦＧファイル２８０は、セクションと呼ばれるデータ領域で幾つかのブロックに区切られる。セクションは［］で括られた文字列で定義され、予め名称が規定された機能セクションと、任意の名称を持つデータ内容定義セクションと、データの変換規則を定義するデータ変換定義セクションとがある。

機能セクションは、どの補助機器１が接続されても共通して使用される名称を有する。例えば、図１４に示された例では、［＿ＩＮＴＥＲＦＡＣＥ＿］、［＿ＳＴＲＵＣＴＵＲＥ＿］及び［＿ＤＡＴＡ＿ＳＰＥＣ＿］が機能セクションである。データ内容定義セクションは、接続された補助機器１毎にコーディングする必要があり、そのコード上に表れる変数の名称を示す。例えば、図１４に示された例では、［ａｂｓｌｔＶｅｌｏｃｉｔｙ］、［ＣｕｒｖｅＲａｄｉｕｓ］及び［ＲａｎｇｅＤｉｓｔａｎｃｅ］がデータ内容定義セクションである。
なお、データ変換定義セクションは、［＿ＤＡＴＡ＿ＳＰＥＣ＿］である。

ＣＦＧファイル２８０にて最初に記載されているのは、インタフェース情報セクション［＿ＩＮＴＥＲＦＡＣＥ＿］である。［＿ＩＮＴＥＲＦＡＣＥ＿］については、図５に示されているＣＦＧファイル１８０と同様である。

次に、［＿ＳＴＲＵＣＴＵＲＥ＿］セクションは、上位提供データ構造定義セクションであり、補助機器１から取得されたデータを、ＣＳＭＷ２１１が上位アプリ１３０に提供するデータの構造を定義する。
図１４では、［＿ＳＴＲＵＣＴＵＲＥ＿］セクションで定義されるデータ構造体のメンバ変数として、「ａｂｓｌｔＶｅｌｏｃｉｔｙ（絶対速度）」、「ＣａｒｖｅＲａｄｉｕｓ（転回半径）」、「ＲａｎｇｅＤｉｓｔａｎｃｅ（物体距離）」、「ＲａｎｇｅＲａｔｅ（物体速度）」及び「Ａｎｇｌｅ（物体角度）」が含まれており、それぞれ、３２ビットで構成されている。

次に、［＿ＤＡＴＡ＿ＳＰＥＣ＿］セクションは、補助機器１から取得されたデータの形式を、ＣＳＭＷ２１１が上位アプリ１３０に提供するデータの形式に変換する変換規則を定義するデータ変換定義セクションである。
図１４に示されている例では、［＿ＤＡＴＡ＿ＳＰＥＣ＿］セクションは、［＿ＳＴＲＵＣＴＵＲＥ＿］セクションで定義された構造体メンバの各々に対して、変換規則が定義されている。
例えば、［＿ＳＴＲＵＣＴＵＲＥ＿］の構造体メンバである［ａｂｓｌｔＶｅｌｏｃｉｔｙ］では、「ＩｄＦ」は、データを取得するインタフェースの種別を示し、図１４の例では、ＣＡＮ１０１からデータを取得することが示されている。「Ｉｄ」は、ＣＡＮ ＩＤを示し、「Ｏｘ７３０」のＣＡＮ ＩＤで送られてきたデータが絶対速度を格納していることを示している。「Ｆ」は、上述のように変数そのものを示し、「＃２」は、データの２バイト目の１バイトが変数の値であることを示している。

以上のように、ＣＦＧファイル２８０には、使用するＡＰＩ群の定義、メンバ変数の宣言及び定義等の情報が記載される。

図９に戻り、ＣＦＧ生成管理部２７５は、ＭＣＦＧ情報生成部２７３ｇから与えられたＭＣＦＧファイルに基づいて、上位アプリ１３０から要求されたデータ又は上位アプリ１３０から要求されたデータを算出するための特定のデータを提供する補助機器１を特定するとともに、センサ管理部２７４に、特定された補助機器１からデータを取得させるファイル管理部である。ここで、実施の形態２では、ＣＦＧ生成管理部２７５は、ＭＣＦＧ情報生成部２７３ｇから与えられたＭＣＦＧファイルに変換方法が含まれている場合には、その変換方法もセンサ管理部２７４に通知し、センサ管理部２７４に特定のデータの変換を行わせる。

センサ管理部２７４は、補助機器１を、第２インタフェース１７１を介して管理する補助機器管理部である。例えば、センサ管理部２７４は、シンボル情報に記載された変数及びＡＰＩを使用して、ＣＦＧ生成管理部２７５で特定された補助機器１を動作させることで、その補助機器１から必要なデータの提供を受ける。なお、ＣＦＧ生成管理部２７５から変換方法が通知された場合には、センサ管理部２７４は、補助機器１から取得された特定のデータを変換方法に従って変換する。
そして、センサ管理部２７４は、ＣＦＧ生成管理部２７５から要求されたデータの組み合わせをアプリ要求情報伝達部２７３ｈに送信する。

次に、第１上位アプリ１３０ａ及び第２上位アプリ１３０ｂが、ＣＳＭＷ２１１を介して、補助機器１から複数のデータの組み合わせを取得する場合において、補助機器１に含まれるセンサが別のセンサに置き換えられ、従来のセンサから供給されるデータと、置き換えられた別のセンサから供給されるデータとが異なるときのＣＳＭＷ２１１の動作を説明する。

例えば、ソナー６が、従来のソナーＡから新たなソナーＢに置換され、それに伴い対応するドライバ部１０６もソナーＡのドライバ部１０６からソナーＢのドライバ部１０６に置き換わったものとする。
従来のソナーＡのドライバ部１０６は、ソナーＡでセンシングした対象物の絶対速度を「ａｂｓｌｔＶｅｌｏｃｉｔｙ＝〜ｋｍ／ｈ」なる時速情報で、また、自車の１トリップ平均速度を「ａｖｒｇＶｅｌｏｃｉｔｙ＝〜ｋｍ／ｈ」なる時速情報で上位アプリ１３０に提供していたものとする。
一方、新たなソナーＢのドライバ部１０６は、ソナーＢでセンシングした対象物の速度を絶対速度では無く相対速度「ｒｅｌａｔｉｖｅＶｅｌｏｃｉｔｙ＝〜ｍ／ｓ」なる秒速情報で、また、自車の平均速度の代わりに、１トリップの走行距離「１ｔｒｉｐＤｉｓｔａｎｃｅ＝〜ｍ」及び１トリップの所要時間「１ｔｒｉｐＴｉｍｅ＝〜ｓ」を上位アプリ１３０に提供するものとする。
また、新たに置換された訳ではないが、ミリ波レーダ５は、その時その時の自車速度を、「ｏｗｎＶｅｌｏｃｉｔｙ＝〜ｋｍ／ｈ」なる時速情報で、上位アプリ１３０に提供しているものとする。

今回、第１上位アプリ１３０ａ及び第２上位アプリ１３０ｂは、センシングした対象物の絶対速度を時速で、自車の１トリップ平均速度を時速で、第１センサ１ａの物体距離、第４センサ１ｄのシート位置及びシート温度を要求するものとし、これらのデータを１００ｍｓの周期で要求するものとする。

このような場合、第１上位アプリ１３０ａ及び第２上位アプリ１３０ｂは、絶対速度、１トリップ平均速度、物体距離、シート位置及びシート温度のデータの組み合わせを、１００ｍｓの周期で取得したい旨の要求を、ＣＳＭＷ２１１の第１インタフェース１７０を介して、アプリ要求受付部２７３ａに送信する。

アプリ要求受付部２７３ａで受け付けられた要求は、アプリ要求パース部２７３ｂにて分析され、どの上位アプリ１３０が、どの様なデータの組み合わせを、如何なるタイミングで所望しているかを要求内容として把握する。このようにして把握された要求内容は、アプリ要求整合管理部２７３ｃに送信される。

アプリ要求整合管理部２７３ｃは、第１上位アプリ１３０ａ及び第２上位アプリ１３０ｂが補助機器１から取得すべきデータが変化していないか、ＣＦＧ生成管理部２７５と連携をとりながら、常にチェックしている。なお、ＣＦＧ生成管理部２７５は、全てのドライバ部１０６に対応する定型文形式のＣＦＧファイルを生成及び管理しているので如何なるデータがドライバ部１０６から取り出せるか把握している。

対応する補助機器１から取得すべきデータが変化していない場合は、アプリ要求整合管理部２７３ｃは、その旨をＭＣＦＧ情報生成部２７３ｇに通知する。この場合には、ＭＣＦＧ情報生成部２７３ｇは、実施の形態１と同様のＭＣＦＧファイルを生成して、ＣＦＧ生成管理部２７５に与える。

一方、対応する補助機器１から取得すべきデータが変化している場合には、変化前のデータと同義にするために、アプリ要求整合管理部２７３ｃは、変換部２７３ｄに変換方法を特定するように指示する。例えば、データの単位の変換が必要な場合は、アプリ要求整合管理部２７３ｃは、単位変換テーブル１３６を持った単位変換部２７３ｅに変換すべき単位を通知して、変換規則の特定を指示する。このような指示を受けた単位変換部２７３ｅは、対応する変換規則を特定して、ＭＣＦＧ情報生成部２７３ｇに通知する。また、データの算出が必要な場合は、アプリ要求整合管理部２７３ｃは、式変換テーブル１３７を持った式変換部２７３ｆに算出すべきデータを通知して、算出式の特定を指示する。このような指示を受けた式変換部２７３ｆは、対応する算出式を特定して、ＭＣＦＧ情報生成部２７３ｇに通知する。

そして、ＭＣＦＧ情報生成部２７３ｇは、実施の形態１とは異なり、変換方法を含むＭＣＦＧファイルを生成して、ＣＦＧ生成管理部２７５に与えて、読み込ませる。

ＭＣＦＧファイルを読み込んだＣＦＧ生成管理部２７５は、ＭＣＦＧファイルに従って、データの組み合わせをセンサ管理部２７４に要求する。この際、ＭＣＦＧファイルに変換方法が記載されている場合には、ＣＦＧ生成管理部２７５は、その変換方法についてもセンサ管理部２７４に通知する。

センサ管理部２７４は、要求されたデータの組み合わせをアプリ要求情報伝達部２７３ｈに送信する。この際、ＣＦＧ生成管理部２７５から変換方法が通知されている場合には、補助機器１から提供されるデータに変換方法を適用して、要求されたデータを生成する。

そして、アプリ要求情報伝達部２７３ｈは、送信されたデータの組み合わせを所望のタイミングで第１インタフェース１７０を介して、第１上位アプリ１３０ａ及び第２上位アプリ１３０ｂに送る。

以上のようにして、第１上位アプリ１３０ａ及び第２上位アプリ１３０ｂは、絶対速度、１トリップ平均速度、物体距離、シート位置及びシート温度のデータの組み合わせを所望のタイミングで取得することができる。

なお、アプリ要求整合管理部２７３ｃは、上位アプリ１３０から要求されたデータが変化していないか、ＣＦＧ生成管理部２７５と連携をとりながら、常にチェックする。例えば、アプリ要求パース部２７３ｂから与えられた要求内容をメモリ２７３ｃ＃に記憶しておき、補助機器１が取り替えられた等により、補助機器１から得られるデータが変化した場合には、単位変換部２７３ｅ、式変換部２７３ｆ及びＭＣＦＧ情報生成部２７３ｇに指示することで、再度、ＭＣＦＧファイルを生成させる。ここで、補助機器１が取り替えられても、上位アプリ１３０から要求されたデータが変化していない場合には、ＭＣＦＧファイルの再生成は行われない。

以上説明した本実施の形態２によれば、上記（１）及び（２）の効果の他に、下記（３）の効果が得られる。

（３）実施の形態２では、車両制御システム２００は、自動車ＭＯに搭載された単眼カメラ２、ステレオカメラ３、ミリ波レーダ５、ソナー６又はＬＩＤＡＲ７といった各種補助機器１、これら各種補助機器１を動作させる機能部、及び、下位機能部１３１から上位機能部１３２へデータを受け渡すＣＳＭＷ２１１から構成される。各種補助機器１は、自動車ＭＯに搭載されているが、常に同じ機器に置換されるとは限らず、異なるバージョンの機器又は仕様の異なる他社の機器に置換されることもある。例えば、ミリ波レーダ５が他社製のミリ波レーダに置き換えられることもある。そして、特定の上位アプリ１３０が、下位機能部１３１である特定の補助機器１から、所望のデータの組み合わせを所望の周期で取得する場合において、上位アプリ１３０へ送信されるデータが、補助機器１の置換前と同じではないときには、単位変換部２７３ｅによる単位変換及び式変換部２７３ｆによる式変換の少なくとも何れか一方が行われる。これにより、上位アプリ１３０は、補助機器１の置換前後において、所望するデータの組み合わせを所望の周期で取得することができる。なお、このような場合、補助機器１のドライバ部１０６に相当する下位機能部１３１のみを改修するだけで、補助機器１の置換が可能であり、ＣＳＭＷ２１１の上位アプリ１３０は変える必要がないため、様々な開発現場でドライバ相当機能ユニットのみを開発するだけで済む。このため、車両制御システム１００は、アプリケーションサポートパッケージとして製品化することが可能である。

なお、本発明は、上記実施の形態１及び２に限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の態様で実施することができる。

１００，２００ 車両制御システム、 １ 補助機器、 ２ 単眼カメラ、 ３ ステレオカメラ、 ４ 側方ソナー、 ５ ミリ波レーダ、 ６ ソナー、 ７ ＬＩＤＡＲ、 １０５，２０５ 制御装置、 １０６ ドライバ部、 １１０，２１０ Ｆ／Ｅボード、 １１１，２１１ ＣＳＭＷ、 １３０ 上位アプリ、 １３１ 下位機能部、 １３２ 上位機能部、 １４０ Ｂ／Ｅボード、 １５０ ナビボード、 １７０ 第１インタフェース、 １７１ 第２インタフェース、 １７２ メイン部、 １７３，２７３ アプリケーション管理部、 １７３ａ，２７３ａ アプリ要求受付部、 １７３ｂ，２７３ｂアプリ要求パース部、 ＣＦＧ情報処理部、 ２７３ｃ アプリ要求整合管理部、 ２７３ｅ 単位変換部、 ２７３ｆ 式変換部、 ２７３ｇ ＭＣＦＧ情報生成部、 ２７３ｈ アプリ要求情報伝達部、 １７４，２７４ センサ管理部、 １７５，２７５ ＣＦＧ生成管理部、 １７６ ＣＦＧファイル記憶部。

Claims (5)

1. 複数の補助機器を接続する制御装置であって、
   前記複数の補助機器の中の対応する補助機器を動作させるための変数及びＡＰＩを記載するコンフィギュレーションファイルを有するとともに、前記対応する補助機器を動作させるために必要な前記変数のシンボル及び前記ＡＰＩのシンボルが記載されたシンボル情報を生成する複数のドライバ部と、
   前記複数の補助機器の各々が前記制御装置に接続された際に、前記複数の補助機器の各々に対応する前記複数のドライバ部の各々から前記コンフィギュレーションファイルを取得するとともに、前記複数のドライバ部の各々からの前記シンボル情報を参照して、前記コンフィギュレーションファイルと前記シンボル情報との整合性を確認し、前記コンフィギュレーションファイルと前記シンボル情報との整合性が確認できた場合に、前記シンボル情報を使用して前記複数の補助機器の各々を動作させるミドルウェア部と、
   前記複数の補助機器から提供されるデータに基づいて、予め定められた制御を行う上位機能部と、を備え、
   前記上位機能部は、前記複数の補助機器から提供されるデータの中の所望のデータを所望のタイミングで取得する要求を、前記ミドルウェア部に送り、
   前記ミドルウェア部は、前記シンボル情報を使用して前記複数の補助機器の各々を動作させることで、前記要求に応じて、前記所望のタイミングで、前記所望のデータを前記上位機能部に送ること
   を特徴とする制御装置。
2. 前記コンフィギュレーションファイルは、前記対応する補助機器が提供するデータをさらに記載しており、
   前記ミドルウェア部は、
   前記要求を受け付ける受付部と、
   前記要求を分析して要求内容を特定する分析部と、
   前記要求内容を示すメタコンフィギュレーション情報を生成する処理部と、
   前記コンフィギュレーションファイル及び前記メタコンフィギュレーション情報を参照することで、前記複数の補助機器の中から、前記所望のデータを提供する補助機器を特定するファイル管理部と、
   前記シンボル情報を使用して、前記特定された補助機器を動作させることで、前記特定された補助機器から前記所望のデータの提供を受ける補助機器管理部と、を備え、
   前記処理部は、前記補助機器管理部が提供を受けた前記所望のデータを前記上位機能部に送ること
   を特徴とする請求項１に記載の制御装置。
3. 前記コンフィギュレーションファイルは、前記対応する補助機器が提供するデータをさらに記載しており、
   前記ミドルウェア部は、
   前記要求を受け付ける受付部と、
   前記要求を分析して要求内容を特定する分析部と、
   前記コンフィギュレーションファイル及び前記要求内容を参照して、前記所望のデータに一致するデータが、前記複数の補助機器が提供するデータである提供データにあるか否かを判断する整合管理部と、
   前記整合管理部が前記所望のデータに一致するデータが前記提供データにないと判断した場合に、前記提供データの中の特定のデータを前記所望のデータに変換するための変換方法を特定する変換部と、
   前記要求内容及び前記変換方法を示すメタコンフィギュレーション情報を生成する処理部と、
   前記コンフィギュレーションファイル及び前記メタコンフィギュレーション情報を参照することで、前記複数の補助機器の中から、前記所望のデータに変換する特定のデータを提供する補助機器を特定するファイル管理部と、
   前記シンボル情報を使用して前記特定された補助機器を動作させることで、前記特定された補助機器から前記特定のデータの提供を受けて、前記変換方法に従って、前記特定のデータを前記所望のデータに変換する補助機器管理部と、
   前記補助機器管理部で変換された前記所望のデータを前記上位機能部に送る伝送部と、を備えること
   を特徴とする請求項１に記載の制御装置。
4. 前記変換部は、
   前記所望のデータの単位と、前記提供データの単位とが異なる場合に、前記特定のデータの単位を、前記所望のデータの単位に変換するための変換規則を前記変換方法として特定する単位変換部と、
   前記特定のデータから前記所望のデータを算出する必要がある場合に、前記特定のデータから前記所望のデータを算出するための算出式を前記変換方法として特定する式変換部と、を備えること
   を特徴とする請求項３に記載の制御装置。
5. 制御装置に接続される複数の補助機器を制御する制御方法であって、
   前記制御装置の複数のドライバ部が、前記複数の補助機器の中の対応する補助機器を動作させるために必要な変数のシンボル及びＡＰＩのシンボルが記載されたシンボル情報を生成し、
   前記制御装置のミドルウェア部が、前記対応する補助機器が前記制御装置に接続された際に、前記複数の補助機器の中の対応する補助機器を動作させるための変数及びＡＰＩを記載するコンフィギュレーションファイルと、前記シンボル情報との整合性を確認し、
   前記ミドルウェア部が、前記コンフィギュレーションファイルと前記シンボル情報との整合性が確認できた場合に、前記シンボル情報を使用して前記対応する補助機器を動作させるとともに、前記複数の補助機器から提供されるデータの中の所望のデータを所望のタイミングで取得する要求を受け付けて、当該要求に応じて、前記シンボル情報を使用して前記複数の補助機器から特定された補助機器を動作させることで、当該所望のタイミングで、当該所望のデータを前記要求の要求元に送ること
   を特徴とする制御方法。

Images