このアプリケーションの一部のコンテンツは現時点では利用できません。
このような状況が続く場合は、にお問い合わせくださいフィードバック & お問い合わせ
1. (WO2018212083) 制御装置及び制御方法
Document

明 細 書

発明の名称 制御装置及び制御方法

技術分野

0001  

背景技術

0002  

先行技術文献

特許文献

0003  

発明の概要

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

0004   0005   0006  

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

0007   0008  

発明の効果

0009  

図面の簡単な説明

0010  

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

0011   0012   0013   0014   0015   0016   0017   0018   0019   0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057   0058   0059   0060   0061   0062   0063   0064   0065   0066   0067   0068   0069   0070   0071   0072   0073   0074   0075   0076   0077   0078   0079   0080   0081   0082   0083   0084   0085   0086   0087   0088   0089   0090   0091   0092   0093   0094   0095   0096   0097   0098   0099   0100   0101   0102   0103   0104   0105   0106   0107   0108   0109   0110   0111   0112   0113   0114   0115   0116   0117   0118   0119   0120   0121   0122   0123   0124   0125   0126   0127   0128   0129   0130   0131   0132  

符号の説明

0133  

請求の範囲

1   2   3   4   5  

図面

1   2   3   4   5   6   7   8   9   10   11   12   13   14  

明 細 書

発明の名称 : 制御装置及び制御方法

技術分野

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

背景技術

[0002]
 特許文献1には、車両LAN(Local Area Network)装置を介して車両データを送受信する車両データ通信部と、車両データ及び変換テーブルを記憶する記憶部と、変換テーブルに基づいて車両独自の形式である車両データをアプリケーションで利用可能な実用データ形式に変換するとともに、アプリケーションで算出された実用データ形式の車両データを変換テーブルに基づいて車両独自の形式の車両データに変換する車両データ変換部と、アプリケーションが車両データにアクセスする車両情報I/Fとを備える車載端末が記載されている。特許文献1に記載された車載端末は、センサ等の機器からの車両データを、変換テーブルを用いて、アプリケーションで利用可能な実用データに変換している。

先行技術文献

特許文献

[0003]
特許文献1 : 特願2001-138079号公報

発明の概要

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

[0004]
 ここで、従来例では、例えば、センサ等の補助機器を新たに設置した場合には、新たに設置された機器の車両データを実用データ形式のデータに変換するための変換テーブルを別に用意しなければならない。車両データを実用データ形式のデータに変換する変換テーブルの作成は、煩雑である。さらに、車両データ毎に、このような変換テーブルの作成を行わなければならない。
 このため、従来例では、新たにセンサ等の補助機器を設置する場合に、この補助機器を使用することができるようにするために、多くの労力が必要となる。
[0005]
 また、上位機能部であるアプリケーションが、処理を行うために必要なデータを必要なタイミングで、センサ等の補助機器から取得できるようにするためにも、多くの労力が必要となる。
[0006]
 そこで、本発明の1又は複数の態様は、上位機能部が、所望のデータを所望のタイミングで補助機器から容易に取得できるようにすることを目的とする。

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

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

発明の効果

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

図面の簡単な説明

[0010]
[図1] 実施の形態1及び2に係る車両制御システムの構成の一例を示すブロック図である。
[図2] 実施の形態1及び2における、F/Eボード、B/Eボード及びナビボードの構成の一例を示すブロック図である。
[図3] 実施の形態1及び2における補助機器を自動車に搭載した一例を示す概略図である。
[図4] 実施の形態1におけるCSMWの内部ソフトウェア構造の一例を示すブロック図である。
[図5] 実施の形態1におけるCSMWにて参照するCFGファイルの一例を示す概略図である。
[図6] 実施の形態1におけるCSMWにて参照するMCFGファイルの一例を示す概略図である。
[図7] (A)及び(B)は、実施の形態1及び2におけるハードウェア構成例を示す概略図である。
[図8] 実施の形態1において、CSMWを介して、データを下位機能部から上位機能部に渡す処理の一例を示すステートチャート図である。
[図9] 実施の形態2におけるCSMWの内部ソフトウェア構造の一例を示すブロック図である。
[図10] 実施の形態2におけるアプリケーション管理部の構成を概略的に示すブロック図である。
[図11] 実施の形態2における単位変換テーブルの一例を示す概略図である。
[図12] 実施の形態2における式変換テーブルの一例を示す概略図である。
[図13] 実施の形態2におけるCSMWにて参照するMCFGファイルの一例を示す概略図である。
[図14] 実施の形態2におけるCSMWにて参照するCFGファイルの一例を示す概略図である。

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

[0011]
実施の形態1.
 図1は、実施の形態1に係る車両制御システム100の構成の一例を示すブロック図である。
 車両制御システム100は、補助機器1と、フロントエンドボード(以下、F/Eボードという)110と、車両の挙動判断等を行うバックエンドボード(以下、B/Eボードという)140と、GPS(Global Positioning System)13からの入力データに基づいて動作するナビボード150とを備える。
 そして、F/Eボード110及びB/Eボード140により、車両の制御を行う制御装置105が構成される。制御装置105は、複数の補助機器1を接続し、補助機器1から得られるデータに基づいて車両の制御を行う。
[0012]
 F/Eボード110には、補助機器1として、単眼カメラ2と、ステレオカメラ3と、側方ソナー4と、ミリ波レーダ5と、ソナー6と、LIDAR(Laser Imaging Detection and Ranging)7とが接続されている。ここでは、補助機器1は、単眼カメラ2、ステレオカメラ3、側方ソナー4、ミリ波レーダ5、ソナー6及びLIDAR7といったセンサである。
[0013]
 単眼カメラ2及びステレオカメラ3は、撮像を行い、その映像データを取得する。
 側方ソナー4は、車体の側方から15m程度の遠距離までの間で、他車等の障害物が近づいて来るか否かを判断するため、アナログオーディオ(音波)を用いて計測する。なお、側方ソナー4とF/Eボード110との間には、データのやり取りを行うために必要なアナログデジタル変換器(以下、AD/DAという)8が設けられている。
 ミリ波レーダ5は、電波を周囲に向けて発射し障害物からの反射波を測定することで障害物までの距離及び方向を測り、この障害物までの距離及び方向等の情報を取得する。なお、ミリ波レーダ5は、図示してはいないが、データを取得するミリ波レーダ本体と、そのデータをやり取りするミリ波レーダECUとを備える。
 ソナー6は、音波を用いて車両周辺の障害物を検知する。なお、ソナー6とCAN(Controller Area Network)101との間には、データのやり取りを行うために必要なAD/DA11が設けられている。
 LIDAR7は、レーザー光を用いたリモートセンシング技術の1つで、パルス状に発光するレーザー照射に対する散乱光を測定し、遠距離にある対象物までの距離又はその対象物の性質を分析する。
[0014]
 また、F/Eボード110は、V2Pモジュール9と、V2Iモジュール10と、INS(Inertial Navigation System:慣性航法装置)12と、データのやり取りを行う。
[0015]
 V2Pは、Vehicle to Personの略で、V2Pモジュール9は、自車周辺の歩行者を検知して、その検知結果を示す歩行者動向情報を取得する。V2Iは、Vehicle to Infrastructureの略で、V2Iモジュール10は、自動車と、インフラとして設定してある路側器との通信結果を示す路側器情報を取得する。V2Pモジュール9及びV2Iモジュール10を合わせてV2Xモジュールともいう。
[0016]
 INS12は、地上の航法援助施設からの電波又は地磁気等に頼らずに、移動する自動車の加速度から、移動方向、速度及び距離を求め、位置を特定するための搭載用航法装置である。
[0017]
 B/Eボード140は、SPI(Serial Peripheral Interface)通信経路103を介して、F/Eボード110とデータのやり取りを行う。
[0018]
 図2は、実施の形態1における、F/Eボード110、B/Eボード140及びナビボード150の構成の一例を示すブロック図である。
 単眼カメラ2及びステレオカメラ3は、LVDS(Low Voltage Differentian Signaling)で映像データをF/Eボード110のカスタマイザブルミドルウェア(以下、CSMWという)111を介して、センサフュージョン112に伝送する。LVDSは、短距離用のデジタル有線伝送技術で、小振幅及び低消費電力で比較的高速な差動インタフェースである。LVDSは、グラフィックスカードからビデオモニタへの映像データ等のデータの伝送に使用される。
 側方ソナー4における計測結果は、AD/DA8でデジタル変調され、CSMW111を介してセンサフュージョン112に伝送される。
 なお、CSMW111をミドルウェア部ともいう。
[0019]
 F/Eボード110には、補助機器1を動作させるためのドライバ部106が設けられている。例えば、ドライバ部106は、補助機器1を動作させるための変数及びAPI(Application Programming Interface)名を記載するコンフィギュレーションファイル(CFGファイルという)を保持する。また、ドライバ部106は、CSMW111からの指示に応じて、補助機器1を動作させるために必要な変数のシンボル及びAPIのシンボルが記載されたシンボル情報を生成し、生成されたシンボル情報をCSMW111に与える。
 そして、CSMW111は、補助機器1が接続された際に、ドライバ部106からCFGファイルを取得するとともに、ドライバ部106からのシンボル情報を参照して、CFGファイルとシンボル情報との整合性を確認する。例えば、CFGファイルに記載されている変数及びAPIに対応する全てのアドレスがシンボル情報に記載されているか否かを確認する。CFGファイルとシンボル情報との整合性が確認できた場合、言い換えると、CFGファイルに記載されている変数及びAPIに対応する全てのアドレスがシンボル情報に記載されている場合に、CSMW111は、シンボル情報に記載された変数のシンボル及びAPIのシンボルを使用して、補助機器1を動作させる。
 さらに、CSMW111は、所望のデータを所望のタイミングで取得する要求を、図4に示す上位アプリ130から受け付けて、シンボル情報に記載された変数及びAPIを使用して補助機器1を動作させることで、所望のタイミングで、所望のデータを要求元に送信する。
[0020]
 CAN101は、耐ノイズ性強化を考慮して設計された、接続機器相互間のデータ伝送に使用される通信経路である。CAN101は、機器の制御情報の伝送用として普及しており、自動車においては補助機器1との情報のやり取り、エンジン又はブレーキの状態及び故障診断情報等の情報の伝送に使用されている。
 ミリ波レーダ5は、障害物までの距離及び方向等の情報を、CAN101及びCSMW111を介して、センサフュージョン112に伝送する。
 ソナー6からの情報は、AD/DA11でデジタル変調され、CAN101及びCSMW111を介して、センサフュージョン112に伝送される。
 V2Pモジュール9は、路側器情報を、CAN101及びCSMW111を介して、座標変換部113に伝送する。
 V2Iモジュール10は、歩行者動向情報を、CAN101及びCSMW111を介して、ダイナミックマップ部114に伝送する。
[0021]
 イーサネット(登録商標)102は、コンピュータネットワーク規格の1つであるが、車載の場合、自動車の周辺監視用のセンサのデータを伝送する通信ネットワークとして採用される。
 LIDAR7からの情報は、イーサネット102及びCSMW111を介して、センサフュージョン112に伝送される。
[0022]
 INS12からの情報は、CSMW111を介して、ロケータ部115に伝送される。
[0023]
 ナビボード150は、HMI(Human Machine Interface)151と、ナビゲーション部152とを備える。
 HMI151は、ユーザからの指示の入力を受け付ける入力部である。
 ナビゲーション部152は、GPS13からのシリアル信号と、HMI151からの情報に基づいて動作し、F/Eボード110とデータのやり取りを行っている。
 GPS13からの信号は、シリアル通信ケーブル104を介して、ナビボード150上のナビゲーション部152に伝送される。
[0024]
 上述の通り、補助機器1からの種々のデータ、例えば、単眼カメラ2からの映像データ、ステレオカメラ3からの映像データ、ミリ波レーダ5からの電波情報、及び、ソナー6からの音波情報等は、CSMW111を介して、センサフュージョン112に伝送される。補助機器1からの種々のデータは、センサフュージョン112により、統合的に処理され互いに協調されたデータとなってシンクロナイズされる。シンクロナイズされたデータは、センサフュージョン112からその上位アプリであるマップ生成部116に伝送される。
[0025]
 V2Pモジュール9からCSMW111を介して座標変換部113に伝送されたデータは、座標変換部113からマップ生成部116に伝送される。
 V2Iモジュール10からCSMW111を介してダイナミックマップ部114に伝送されたデータは、ダイナミックマップ部114から地図情報としてマップ生成部116及びレーンレベルルート生成部117に伝送される。
 単眼カメラ2の映像データは、LVDS及びCSMW111を介して、ロケータ部115にも入力され、また、INS12からのデータもロケータ部115に入力される。さらに、マップ生成部116からの道路障害物情報が、ロケータ部115に入力される。ロケータ部115に伝送されたデータは、自車位置情報として、マップ生成部116、レーンレベルルート生成部117及びナビゲーション部152に伝送される。
[0026]
 ナビゲーション部152からの誘導情報は、イーサネット102経由でレーンレベルルート生成部117に入力される。その他のECU(Electronic Control Unit)160からは、自車速度情報、自車加速度情報、操舵角情報、アクセル/ブレーキ情報及びウィンカ操作情報が、CAN101経由で運転操作特性部118に入力される。この内、自車速度情報は、CAN101を介して、マップ生成部116にも入力される。
 マップ生成部116からは、3Dマップ情報が、リスクマップ生成部119の死角検出部119a及び移動予測部120に伝送され、また、3Dマップ情報は、イーサネット102を介して、ナビボード150のHMI151に伝送される。
[0027]
 運動モデルデータベース(以下、運動モデルDB)121は、データベース内の情報を運動モデル更新部122からの更新情報で更新し、運動モデル情報を移動予測部120に入力する。
 移動予測部120は、マップ生成部116からの3Dマップ情報と運動モデルDB121からの運動モデル情報とから移動予測情報を生成し、これをリスクマップ生成部119のリスク推定部119bに入力する。リスク推定部119bに入力されたリスク情報を用いて、B/Eボード140が車両の制御を行うことによって、リスクを軽減するように自動運転が行われる。
[0028]
 レーンレベルルート生成部117は、地図情報及びレーンレベルルート情報をパス生成部123に入力する。
 運転操作特性部118は、運転操作特性データベース(以下、運転操作特性DB)124と運転操作特性情報をやり取りし、更新された運転操作特性情報をパス生成部123に入力する。
 パス生成部123は、パス情報を、イーサネット102を介して、ナビボード150のHMI151に入力する。また、パス生成部123は、パス情報をSPI通信経路103経由で、B/Eボード140の判断部141に入力する。
 HMI151は、CAN101からF/E故障情報及びB/E故障情報を取得すると共に、CAN101に運転モード及び緊急停止情報を送信する。
[0029]
 B/Eボード140の判断部141は、自車位置情報、道路勾配情報、カーブ曲率情報をCAN101経由で取得する。また、判断部141は、車両制御情報及びB/E故障情報をCAN101に送信すると共に、車両制御情報及びB/E故障情報を車両制御判断部142に入力する。
 車両制御判断部142は、CAN101から運転モード及びF/E故障情報を取得すると共に、CAN101からセンシング情報を取得した緊急制御部143から緊急制御情報を取得する。
[0030]
 図3は、実施の形態1及び2における補助機器1を自動車に搭載した一例を示す概略図である。
 自動車MOには、車両制御システム100が搭載されている。
 単眼カメラ2は、自動車MOの前方中央と後方中央に取り付けられており、夫々前方及び後方の物体を認識する。
 ステレオカメラ3は、自動車MOのフロントガラス上部に取り付けられ、前方の物体を認識する。
 側方ソナー4は、自動車MOの側方に取り付けられ、夫々右側方及び左側方を認識する。
 ミリ波レーダ5は、自動車MOの前方左右に取り付けられ、夫々前方の左右を走査する。
 ソナー6は、自動車MOの前方左右に取り付けられ、夫々前方の左右を走査する。
 LIDAR7は、自動車MOの屋根中央に取り付けられ、自動車MOの周囲全てを走査する。
[0031]
 図4は、実施の形態1におけるCSMW111の内部ソフトウェア構造の一例を示すブロック図である。
 図4では、複数の補助機器1の各々が第1センサ1a、第2センサ1b、第3センサ1c及び第4センサ1dからなるものとして示されている。また、第1センサ1a、第2センサ1b、第3センサ1c及び第4センサ1dは、それぞれ、第1ドライバ部106a、第2ドライバ部106b、第3ドライバ部106c及び第4ドライバ部106dにより動作される。
[0032]
 また、第1上位アプリ130a、第2上位アプリ130b及び第3上位アプリ130cは、補助機器1及びCSMW111よりも上位のアプリケーションである。例えば、上位アプリ130は、CSMW111及びドライバ部106を除いた、図2に示されているF/Eボード110に含まれている機能部を実現するためのアプリケーションである。
[0033]
 CSMW111は、第1インタフェース170と、第2インタフェース171と、メイン部172と、アプリケーション管理部173と、センサ管理部174と、コンフィグレーション生成管理部(以下、CFG生成管理部という)175と、コンフィグレーションファイル記憶部(以下、CFGファイル記憶部という)176とを備える。
[0034]
 第1インタフェース170は、APIである。例えば、上位アプリ130は、第1インタフェース170を介して、CSMW111と通信を行うことができる。
 第2インタフェース171も、APIである。例えば、補助機器1は、対応するドライバ部106を介して、CSMW111と通信を行うことができる。
[0035]
 アプリケーション管理部173は、CSMW111と通信を行う上位アプリ130を管理する。アプリケーション管理部173は、メイン部172に組み込まれており、メイン部172からコールされて処理を実行する。
 アプリケーション管理部173は、アプリ要求受付部173aと、アプリ要求パース部173bと、コンフィグレーション情報処理部(以下、CFG情報処理部という)173cとを備える。
[0036]
 アプリ要求受付部173aは、上位アプリ130から、データを取得する要求を受け付ける受付部である。上位アプリ130は、所望のタイミングで、所望のデータを取得する要求をアプリ要求受付部173aに送る。
 アプリ要求パース部173bは、アプリ要求受付部173aで受け付けられた要求を分析し、その要求内容を分析結果としてCFG情報処理部173cに与える分析部である。
 CFG情報処理部173cは、アプリ要求パース部173bで分析された要求内容に従って、上位アプリ130からの要求内容、例えば、要求されたデータ(所望のデータ)の形式及び通信方法を記載するメタコンフィギュレーションファイル(以下、MCFGファイルという)を生成して、CFG生成管理部175に与える処理部である。なお、MCFGファイルは、メタコンフィギュレーション情報ともいう。
[0037]
 CFG生成管理部175は、ドライバ部106から、補助機器1を動作させるための変数及びAPI(Application Programming Interface)名を記載するコンフィギュレーションファイルを取得して、それをCFGファイル記憶部176に記憶させるファイル管理部である。なお、CFGファイルは、コンフィギュレーション情報(CFG情報)ともいう。
 また、CFG生成管理部175は、CFG情報処理部173cから与えられたMCFGファイルに基づいて、要求されたデータを提供する補助機器を特定するとともに、センサ管理部174に、特定された補助機器1から要求されたデータを取得させる。
[0038]
 センサ管理部174は、補助機器1を、第2インタフェース171を介して管理する補助機器管理部である。例えば、センサ管理部174は、シンボル情報に記載された変数及びAPIを使用して、CFG生成管理部175で特定された補助機器1を動作させることで、その補助機器1から要求されたデータの提供を受ける。
 なお、センサ管理部174は、メイン部172に組み込まれており、メイン部172からコールされて処理を実行する。
[0039]
 なお、CSMW111より下の階層の補助機器1及びドライバ部106を下位機能部131、CSMW111より上位の階層の上位アプリ130を上位機能部132という総称で呼ぶことにする。上位機能部132は、補助機器1から提供されるデータに基づいて、予め定められた制御を行う。
[0040]
 次に、上位アプリ130の内の1つである第2上位アプリ130bが、CSMW111を介して補助機器1から、データの組み合わせを所望のタイミングで取得する例を説明する。
 ここでの、CSMW111を介して、という表現は正確にはCSMW111にて第2上位アプリ130bが受け取れるデータに成型して第2上位アプリ130bにデータの組み合わせを渡すことをいう。
 なお、補助機器1に含まれている第1センサ1a、第2センサ1b、第3センサ1c及び第4センサ1dの各々には、各々を識別するためのセンサ識別情報であるセンサIDが割り振られているものとする。
[0041]
 なお、補助機器1の1つのドライバ部106に対して1つのCFGファイルが対応しており、そのCFGファイルに記載されているデータ形式のデータは、上位機能部132に渡されてはいる。ここでは、これとは別に、例えば、第2上位アプリ130bが、第1センサ1aのあるデータと、第2センサ1bのあるデータとの組み合わせを、データセットとして、所望のタイミングで取得する場合を説明する。
[0042]
 第2上位アプリ130bは、第1センサ1aのあるデータと、第2センサ1bのあるデータとの組み合わせを、所望のタイミングで取得したい旨の要求を、CSMW111の第1インタフェース170を介して、アプリケーション管理部173のアプリ要求受付部173aに送信する。
[0043]
 アプリ要求受付部173aで受け付けられた要求は、アプリ要求パース部173bにて分析され、どのアプリケーションがどのセンサのどのデータを組み合わせて如何なるタイミングで所望しているかといった要求内容が、分析結果として把握される。この要求内容は、CFG情報処理部173cに与えられる。
[0044]
 CFG情報処理部173cは、与えられた要求内容を、MCFGファイルとして整形して、CFG生成管理部175に読み込ませる。
[0045]
 MCFGファイルを読み込んだCFG生成管理部175は、MCFGファイルに従って、要求されたデータの組み合わせをセンサ管理部174に要求する。
 センサ管理部174は、要求されたデータの組み合わせをCFG情報処理部173cに送信する。
 CFG情報処理部173cは、受信されたデータの組み合わせを、要求されたタイミング(所望のタイミング)で、第1インタフェース170を介して第2上位アプリ130bに送信する。
 以上のようにして、第2上位アプリ130bは、第1センサ1aのあるデータと、第2センサ1bのあるデータとの組み合わせを、所望のタイミングで取得することができる。
[0046]
 図5は、実施の形態1におけるCSMW111にて参照するCFGファイルの一例を示す概略図である。
 F/Eボード110に接続する1つの補助機器1に対して1つのCFGファイルが必要である。図5に示されているCFGファイル180は、ミリ波レーダ5を接続する際のものである。
[0047]
 接続するミリ波レーダ5の機種名はMW-Raderであり、それに対応するCFGファイル名は「MW-Rader.ini」である。
 CFGファイル180は、セクションと呼ばれるデータ領域で幾つかのブロックに区切られる。セクションは[]で括られた文字列で定義され、予め名称が規定された機能セクションと、任意の名称を持つデータ内容定義セクションと、データの変換規則を定義するデータ変換定義セクションとがある。
[0048]
 機能セクションは、どの補助機器1が接続されても共通して使用される名称を有する。例えば、図5に示された例では、[_INTERFACE_]、[_STRUCTURE_]及び[_DATA_SPEC_]が機能セクションである。データ内容定義セクションは、接続された補助機器1毎にコーディングする必要があり、そのコード上に表れる変数の名称を示す。例えば、図5に示された例では、[Velocity]、[CurveRadius]及び[RangeDistance]がデータ内容定義セクションである。
 なお、データ変換定義セクションは、[_DATA_SPEC_]である。
[0049]
 CFGファイル180にて最初に記載されているのは、インタフェース情報セクション[_INTERFACE_]である。
 「SensorName」は、接続される補助機器1の名称を示す。ここでは、ミリ波レーダ5の名称「MW-Rader」が定義されている。
 「SensorId」は、接続される補助機器1の識別情報(センサID)を示す。ここでは、ミリ波レーダ5のID「sens1」が定義されている。
 「UpIndMode」は、CSMW111からのデータの通知方式を示す。例えば、データ通知方式は、「0」~「2」の整数で定義されている。図5の例では、「0」が選択され、データが生成されたら、逐一、CSMW111から通知されることが示されている。なお、「1」の場合には、周期コールバックで通知され、「2」の場合には、ポーリングで通知される。
[0050]
 「AutoStart」は、接続される補助機器1が、CSMW111を実行するアプリケーションが起動したときに自動的に起動するか否かを示す。例えば、「0」の場合には、自動的に起動しないことを示し、「1」の場合には、自動的に起動することを示す。
 「DnIfType」は、補助機器1からデータを取得するインタフェースの種別を示す。例えば、インタフェースの種別は、「0」~「3」の整数で定義されている。「0」はライブラリ、「1」はメモリ、「2」はCAN101、及び、「3」はイーサネット102を示す。図5の例では、インタフェースとして、CAN101が選択されている。
[0051]
 「DnIfParam」及び「DnCanID」は、インタフェースとしてCAN101が選択されたために定義されたものである。
 「DnIfParam」は、CAN101を使用する場合のCAN101の系統番号を示す。
 「DnCanID」は、データファイリング用のCAN101のメッセージIDであるCAN IDを示す。図5の例では、CAN IDとして「h730」又は「h731」の何れかが用いられることが示されている。
[0052]
 次に、[_STRUCTURE_]セクションは、上位提供データ構造定義セクションであり、補助機器1から取得されたデータを、CSMW111が上位アプリ130に提供するデータの構造を定義する。[_STRUCTURE_]セクションにより、補助機器1(ここでは、ミリ波レーダ5)が提供するデータを特定することができる。
 図5では、[_STRUCTURE_]セクションで定義されるデータ構造体のメンバ変数として、「Velocity(速度)」、「CarveRadius(転回半径)」、「RangeDistance(物体距離)」、「RangeRate(物体速度)」及び「Angle(物体角度)」が含まれており、それぞれ、32ビットで構成されている。
[0053]
 次に、[_DATA_SPEC_]セクションは、補助機器1から取得されたデータの形式を、CSMW111が上位アプリ130に提供するデータの形式に変換する変換規則を定義するデータ変換定義セクションである。
 図5に示されている例では、[_DATA_SPEC_]セクションは、[_STRUCTURE_]セクションで定義された構造体メンバの各々に対して、変換規則が定義されている。
 例えば、[_STRUCTURE_]の構造体メンバである[Velocity]では、「IdF」は、データを取得するインタフェースの種別を示し、図5の例では、CAN101からデータを取得することが示されている。「Id」は、CAN IDを示し、「Ox730」のCAN IDで送られてきたデータが速度を格納していることを示している。「F」は、上述のように変数そのものを示し、「#2」は、データの2バイト目の1バイトが変数の値であることを示している。
[0054]
 以上のように、CFGファイル180には、使用するAPI群の定義、メンバ変数の宣言及び定義等の情報が記載される。
[0055]
 なお、従来例では上位のアプリケーションを変えることなくドライバからのセンサデータをその上位のアプリケーションで利用可能なデータにするためには、そのセンサデータに即した変換テーブルを作成し、ドライバからのセンサデータの変換部が変換テーブルを参照して変換しなければならない。この変換テーブルの作成は、煩雑であり、変換テーブルの作成は、異なるセンサ毎に行われなければならない。
 それに対し、実施の形態1では、各種センサ等の補助機器1と、上位アプリ130との間にCSMW111が備えられ、各センサを動作させるのに用いるドライバ部106の処理に必要な構造体及び関数の定義がCFGファイルに記載されている。このため、CSMW111は、CFGファイルにアクセスすることで、対応するドライバ部106からの情報を上位アプリ130に与えることができる。
[0056]
 図6は、実施の形態1におけるCSMW111にて参照するMCFGファイルの一例を示す概略図である。
 図6に示されているMCFGファイル181は、第2上位アプリ130b(アプリケーションID:app2)が、センサIDとして「sens1」が割り当てられている補助機器1と、センサIDとして「sens2」が割り当てられている補助機器1とから、それぞれのデータの組み合わせを要求した際に、CFG情報処理部173cで生成されたものである。
[0057]
 ここでは、「meta-Cfig1.ini」というファイル名が付されたMCFGファイル181として説明するが、同様の内容の情報(メタコンフィギュレーション情報)が、単なるデータとして図示されていないメモリ内に展開されていてもよい。
[0058]
 MCFGファイル181は、セクションと呼ばれるデータ領域で幾つかのブロックに区切られる。セクションは[]で括られた文字列で定義され、予め名称が規定された機能セクションがある。
 図6に示されている例では、[_INTERFACE_]セクション及び[_STRUCTURE_]セクションが、予め名称が規定された機能セクションである。
[0059]
 MCFGファイル181にて最初に記載されているのは、インタフェース情報セクション[_INTERFACE_]である。
 「AppliId」は、要求元のアプリケーションである上位アプリ130を識別するための識別情報(アプリケーションID)を示す。ここでは、第2上位アプリ130bのアプリケーションID(app2)が示されている。
 「SensorId」は、データの要求対象である補助機器1の識別情報(センサID)を示す。ここでは、「sens1」及び「sens2」のセンサIDが示されている。
 「UpSndTiming」は、要求されたデータを要求元アプリケーションへ送信する際の送信タイミングを示す。ここでは、データの送信周期([ms]単位)が示されている。
 「UpSndWait」は、データの送信が、「UpSndTiming」で示されているタイミングから遅れる場合に、許容される遅延時間を示す値である送信ウェイト間隔を示す。
 「UpIfType」は、要求元の上位アプリ130へ送信する際に使用されるインタフェースの種別を示す。
[0060]
 「AppliId」、「SensorId」、「UpSndTiming」、「UpSndWait」及び「UpIfType」は、その文字列が予め決められた固定文字列であり、CFG生成管理部175は、その固定文字列から内容を把握することができる。
[0061]
 次に、[_STRUCTURE_]セクションは、上位提供データ構造定義セクションであり、補助機器1から提供されたデータの組み合わせを、CSMW111が上位アプリ130に提供するデータの構造を定義する。
 図6では、[_STRUCTURE_]セクションで定義されるデータ構造体のメンバ変数として、「sens1.Velocity」、「sens1.CarveRadius」、「sens1.RangeDistance」、「sens2.RangeRate」及び「sens2.Angle」が含まれており、それぞれ32ビットで構成されている。
[0062]
 「sens1.Velocity」は、「sens1」で識別される補助機器1から提供される速度のデータを示す。
 「sens1.CarveRadius」は、「sens1」で識別される補助機器1から提供される転回半径のデータを示す。
 「sens1.RangeDistance」は、「sens1」で識別される補助機器1から提供される物体距離のデータを示す。
 「sens2.RangeRate」は、「sens2」で識別される補助機器1から提供される物体速度のデータを示す。
 「sens2.Angle」は、「sens2」で識別される補助機器1から提供される物体角度のデータを示す。
[0063]
 以上のようなMCFGファイル181は、CFG生成管理部175によって読み込まれ、CFG情報処理部173cは、センサ管理部174から、MCFGファイル181で示されたデータの組み合わせを受け取り、第1インタフェース170を介して、それを構造体として第2上位アプリ130bへ送信することができる。
[0064]
 以上に記載されたF/Eボード110、B/Eボード140及びナビボード150のそれぞれの一部又は全部は、例えば、図7(A)に示されているように、メモリ190と、メモリ190に格納されているプログラムを実行するCPU(Central Processing Unit)等のプロセッサ191とにより構成することができる。このようなプログラムは、ネットワークを通じて提供されてもよく、また、記録媒体に記録されて提供されてもよい。
[0065]
 また、F/Eボード110、B/Eボード140及びナビボード150のそれぞれの一部又は全部は、例えば、図7(B)に示されているように、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ASIC(Application Specific Integrated Circuits)又はFPGA(Field Programmable Gate Array)等の処理回路192で構成することもできる。
[0066]
 図8は、実施の形態1において、CSMW111を介して、データを下位機能部131から上位機能部132に渡す処理の一例を示すステートチャート図である。
 CSMW111は、機能部又はドライバ部106との間でデータの入出力を行う。具体的には、機能部にデータを提供する「データ通知」であり、実施の形態1では同期方式でデータを下位機能部131から上位機能部132へ渡す例を説明する。
[0067]
 同期方式でデータを下位機能部131から上位機能部132へ渡すにあたって、まず、CSMW111は、F/Eボード110に接続されている各種補助機器1の構成を把握するため、機器構成情報を取得する。この際、接続されている各種補助機器1毎にCFGファイルが用意されており、下位機能部131は、対応するCFGファイルをロードする(S10)。
[0068]
 そして、CSMW111が各々の補助機器1の実体を提供する機器登録処理を上位機能部132がコールし(S11)、機器登録メッセージ(登録命令)をCSMW111が受信する(S12)。
[0069]
 下位機能部131は、CSMW111がインタフェース仕様を提示したフィルタ設定処理をコールし(S13)、機器動作に必要なメンバ変数のシンボル及びAPIのシンボルが記載されたシンボル情報を取得する(S14)。シンボル情報は、変数のシンボル及びAPIのシンボルとそのアドレスとを対応付けた情報である。
 CSMW111は、このシンボル情報を取得して(S15)、取得されたシンボル情報とロードされたCFGファイルとを比較して、機器動作に必要なメンバ変数のシンボル及びAPIのシンボルを把握することが可能となる。例えば、CSMW111は、CFGファイルで把握された変数及びAPIと、シンボル情報に含まれている変数のシンボル及びAPIのシンボルとを比較し、これらが一致した場合には、対応するアドレスから変数のシンボル及びAPIのシンボルを呼び出すことができるようになる。
[0070]
 続いて、CSMW111が実体を提供する機器開始処理を上位機能部132がコールし(S16)、機器開始メッセージ(開始命令)をCSMW111が受信する(S17)。
[0071]
 下位機能部131は、CSMW111がインタフェース仕様を提示した機器受信開始処理をコールし(S18)、補助機器1からのデータ受信を開始するのに必要な処理を行う(S19)。
[0072]
 CSMW111は、FIFO(First In First Out)バッファ生成処理を行い、上りFIFOバッファ134を生成する(S20)。
[0073]
 そして、機器受信開始処理(S19)を行った下位機能部131は、データDDを受信してフィルタリング処理を行い(S21)、バッファ135にデータDDをPUSHする(S22)。
[0074]
 さらに、CSMW111は、機器データリード処理をコールし(S23)、下位機能部131のバッファ135にPUSHされたデータDDをPULLして読み込み、データDDをCSMW111が取り込む(S24)。
[0075]
 所望のデータDDを取り込んだCSMW111は、データ変換処理を行い(S25)、ステップS20で生成された上りFIFOバッファ134にデータDDをPUSHする(S26)。
[0076]
 ここで上位機能部132は、CSMW111が実体を提供する機器データリード処理をポーリングで行い(S27)、上りFIFOバッファ134からPULLしてデータDDを取得する(S28)。
[0077]
 以上説明した本実施の形態1によれば、下記(1)及び(2)の効果が得られ得る。
 (1)実施の形態1では、車両制御システム100は、自動車MOに搭載された単眼カメラ2、ステレオカメラ3、ミリ波レーダ5、ソナー6又はLIDAR7といった各種補助機器1、これら各種補助機器1を動作させる機能部、及び、下位機能部131から上位機能部132へデータを受け渡すCSMW111から構成される。各種補助機器1は、自動車MOに搭載されているが、常に同じ機器に置換されるとは限らず、異なるバージョンの機器又は仕様の異なる他社の機器に置換されることもある。例えば、ミリ波レーダ5が他社製のミリ波レーダに置き換えられることもある。この場合、この補助機器1のCFGファイルに、この補助機器1を動作させるための構造体及びAPIを定義すれば、CSMW111は、起動時にそのCFGファイルを読み込むだけで、CSMW111及びその上位機能部132を変更することなく、上位機能部132は下位機能部131からのデータを、同期方式で取得することができる。なお、この場合、この補助機器1のドライバ部106に相当する下位機能部131のみを改修するだけで、補助機器1の置換ができ、CSMW111の上位アプリ130は変える必要がないため、様々な開発現場でドライバ部106に相当する機能部のみを開発するだけで済む。このため、車両制御システム100は、アプリケーションサポートパッケージとして製品化することが可能である。
[0078]
 (2)さらに、特定の上位アプリ130が、指定したデータ又は指定したデータの組み合わせを所望の周期で取得する場合、その特定の上位アプリ130は、アプリケーション管理部173にこれら要求を送信し、その要求を基にアプリケーション管理部173にて自動生成されたMCFGファイルを基にセンサ管理部174から所望のデータ又は所望のデータの組み合わせが取得される。このため、アプリケーション管理部173は、その特定の上位アプリ130が所望するデータ又は所望するデータの組み合わせを所望の周期で送信することが可能である。なお、この場合、この補助機器1のドライバ部106に相当する下位機能部131のみを改修するだけで、補助機器1の置換ができ、CSMW111の上位アプリ130は変える必要がないため、様々な開発現場でドライバ部106に相当する機能部のみを開発するだけで済む。このため、車両制御システム100は、アプリケーションサポートパッケージとして製品化することができる。
[0079]
実施の形態2.
 以下、実施の形態2を示す。
 図1に示されているように、実施の形態2に係る車両制御システム200は、補助機器1と、F/Eボード210と、B/Eボード140と、ナビボード150とを備える。
 そして、F/Eボード210及びB/Eボード140により、車両の制御を行う制御装置205が構成される。制御装置205は、補助機器1を接続し、補助機器1から得られる情報に基づいて制御を行う。
 実施の形態2に係る車両制御システム200は、F/Eボード210を除いて、実施の形態1に係る車両制御システム100と同様に構成されている。
[0080]
 図2に示されているように、実施の形態2におけるF/Eボード210は、CSMW211を除いて、実施の形態1におけるF/Eボード110と同様に構成されている。
[0081]
 図9は、実施の形態2におけるCSMW211の内部ソフトウェア構造の一例を示すブロック図である。
 図9では、複数の補助機器1の各々が第1センサ1a、第2センサ1b、第3センサ1c及び第4センサ1dからなるものとして示されている。また、第1センサ1a、第2センサ1b、第3センサ1c及び第4センサ1dは、それぞれ、第1ドライバ部106a、第2ドライバ部106b、第3ドライバ部106c及び第4ドライバ部106dにより動作される。
[0082]
 また、第1上位アプリ130a、第2上位アプリ130b及び第3上位アプリ130cは、補助機器1及びCSMW211よりも上位のアプリケーションである。例えば、上位アプリ130は、CSMW211及びドライバ部106を除いた、図2に示されているF/Eボード210に含まれている機能部を実現するためのアプリケーションである。
[0083]
 CSMW211は、第1インタフェース170と、第2インタフェース171と、メイン部172と、アプリケーション管理部273と、センサ管理部274と、CFG生成管理部275と、CFGファイル記憶部176とを備える。
 実施の形態2におけるCSMW211の第1インタフェース170、第2インタフェース171、メイン部172及びCFGファイル記憶部176は、実施の形態1におけるCSMW111の第1インタフェース170、第2インタフェース171、メイン部172及びCFGファイル記憶部176と同様である。
[0084]
 アプリケーション管理部273は、CSMW211と通信を行う上位アプリ130を管理する。アプリケーション管理部273は、メイン部172に組み込まれており、メイン部172からコールされて処理を実行する。
[0085]
 図10は、アプリケーション管理部273の構成を概略的に示すブロック図である。
 アプリケーション管理部273は、アプリ要求受付部273aと、アプリ要求パース部273bと、アプリ要求整合管理部273cと、変換部273dと、メタコンフィギュレーション情報生成部(以下、MCFG情報生成部という)273gと、アプリ要求情報伝達部273hとを備える。
[0086]
 アプリ要求受付部273aは、上位アプリ130から、データを取得する要求を受け付ける受付部である。上位アプリ130は、所望のデータを所望のタイミングで取得するように要求を行うものとする。
 アプリ要求パース部273bは、アプリ要求受付部173aで受け付けられた要求を分析し、その要求内容を分析結果としてアプリ要求整合管理部273cに与える分析部である。
[0087]
 アプリ要求整合管理部273cは、CFG生成管理部275と連携して、アプリ要求パース部273bから与えられた要求内容を確認し、上位アプリ130から要求されたデータ(所望のデータ)に一致するデータが、補助機器1から提供されるデータ(提供データ)にあるか否かを判断する。そして、上位アプリ130から要求されたデータに一致するデータが、補助機器1から提供されるデータにない場合には、アプリ要求整合管理部273cは、変換部273d及びMCFG情報生成部273gに指示することで、補助機器1から提供される特定のデータを上位アプリ130から要求されたデータに変換するための変換方法を含むMCFGファイルを生成させる。なお、上位アプリ130から要求されたデータが、補助機器1から得られるデータにある場合には、アプリ要求整合管理部273cは、MCFG情報生成部273gに指示することで、実施の形態1と同様のMCFGファイルを生成させる。
[0088]
 また、アプリ要求整合管理部273cは、CFG生成管理部275と連携して、補助機器1が取り替えられた後に、上位アプリ130から要求されたデータと一致するデータが、補助機器1から提供されるデータにあるか否かを判断する。そして、上位アプリ130から要求されたデータと一致するデータが、補助機器1から提供されるデータにない場合には、アプリ要求整合管理部273cは、変換部273d及びMCFG情報生成部273gに指示することで、補助機器1から提供される特定のデータを上位アプリ130から要求されたデータに変換するための変換方法を含むMCFGファイルを生成させる。
[0089]
 変換部273dは、補助機器1から提供される特定のデータを上位アプリ130から要求されたデータに変換するための変換方法を特定する。
 変換部273dは、単位変換部273eと、式変換部273fとを備える。
[0090]
 単位変換部273eは、アプリ要求整合管理部273cからの指示に従って、補助機器1から提供される特定のデータの単位を、上位アプリ130から要求されたデータの単位に変換する変換規則を特定し、特定された変換規則を変換方法としてMCFG情報生成部273gに通知する。例えば、単位変換部273eは、単位の変換規則を示す単位変換テーブルを参照することで、単位の変換規則を特定する。
[0091]
 図11は、単位変換テーブルの一例を示す概略図である。
 単位変換テーブル136は、単位を変更する際の変換規則を示す。
 例えば、図11に示されている「速度」の項目の「1km/h」及び「1000/3600m/s」は、速度の単位である「km/h」と「m/s」との変換規則を示している。補助機器1から提供される速度のデータが、従来km/h単位であったが、補助機器1の置換等により、m/s単位になった場合には、補助機器1から提供されるm/s単位のデータに、(3600/1000)を掛ける必要がある。一方、補助機器1から提供される速度のデータが、従来m/sであったが、補助機器1の置換等により、km/hになった場合には、補助機器1から提供されるkm/h単位のデータに、(1000/3600)を掛ける必要がある。
 その他にも、図11では、「緯度、経度」、「高度」及び「角度」の単位の変換規則を示しているが、実施の形態2においては、その他考えられる単位の変換規則を網羅して単位変換テーブルに格納しておく必要がある。
[0092]
 図10に戻り、式変換部273fは、アプリ要求整合管理部273cからの指示に従って、上位アプリ130から要求されたデータを、補助機器1から提供される特定のデータから算出するための算出式を特定し、特定された算出式を変換方法としてMCFG情報生成部273gに通知する。例えば、式変換部273fは、算出式を示す式変換テーブルを参照することで、算出式を特定する。
[0093]
 図12は、式変換テーブルの一例を示す概略図である。
 式変換テーブル137は、複数の特定のデータを用いて別のデータを算出する算出式を示す。
 例えば、図12に示されている「絶対速度」の項目の「absltVelocity」及び「relativeVelocity+ownVelocity」は、絶対速度を相対速度から算出する算出式を示している。補助機器1から提供される速度のデータが、従来絶対速度であったが、補助機器1の置換等により、相対速度になった場合には、補助機器1から提供される相対速度(relativeVelocity)に自車速度(ownVelocity)を加える必要がある。
 また、図12に示されている「1trip平均速度」の項目の「avrgVelocity」及び「1tripDistance/1tripTime」は、1回の走行における平均速度を、1回の走行における走行距離及び走行時間から算出する算出式を示している。
 その他にも、図12では、「1trip後累積距離」を算出する算出式を示しているが、実施の形態2においては、その他考えられる内容の算出式を網羅して式変換テーブルに格納しておく必要がある。
[0094]
 図10に戻り、MCFG情報生成部273gは、アプリ要求整合管理部273cからの指示に応じて、アプリ要求整合管理部273cから与えられた要求内容を、MCFGファイルとして整形して、CFG生成管理部275に読み込ませる処理部である。
 ここで、MCFG情報生成部273gは、アプリ要求整合管理部273cからの指示に応じて、上位アプリ130から要求されたデータが補助機器1から提供されるデータにある場合には、実施の形態1と同様のMCFGファイルを生成する。
 一方、MCFG情報生成部273gは、アプリ要求整合管理部273cからの指示に応じて、上位アプリ130から要求されたデータが補助機器1から提供されるデータにない場合には、MCFGファイルに変換部273dから通知される変換方法を含める。
[0095]
 なお、MCFG情報生成部273gは、CFG生成管理部275に問い合わせることにより、式変換部273fから与えられる算出式で用いられる特定のデータを提供する補助機器1を特定し、MCFGファイルにおいて、特定された補助機器1を示す。
 さらに、MCFG情報生成部273gは、複数のデータを用いて、算出式により算出されたデータの単位を変更する必要がある場合等、単位変換部273eから通知される変換規則と、式変換部273fから通知される算出式とを組み合わせる必要がある場合には、これらを組み合わせた変換方法をMCFGファイルに示す。
[0096]
 図13は、実施の形態2におけるCSMW211にて参照するMCFGファイルの一例を示す概略図である。
 図13に示されているMCFGファイル281は、第1上位アプリ130a(アプリケーションID:app1)及び第2上位アプリ130b(アプリケーションID:app2)が、センサIDとして「sens1」が割り当てられている補助機器1と、センサIDとして「sens3」が割り当てられている補助機器1と、センサIDとして「sens4」が割り当てられている補助機器1とから、それぞれのデータの組み合わせを要求した際に、MCFG情報生成部273gで生成されたものである。
 また、図13に示されているMCFGファイル281は、上位アプリ130から要求されたデータと一致するデータが補助機器1から提供されるデータにない場合に生成されるファイルである。
[0097]
 ここでは、「meta-Cfig2.ini」というファイル名が付されたMCFGファイル281として説明するが、同様の内容の情報(メタコンフィギュレーション情報)が、単なるデータとして図示されていないメモリ内に展開されていてもよい。
[0098]
 MCFGファイル281は、セクションと呼ばれるデータ領域で幾つかのブロックに区切られる。セクションは[]で括られた文字列で定義され、予め名称が規定された機能セクションと、任意の名前を持つデータ内容定義セクション、及び、データの変換方法を定義するデータ変換定義セクションがある。
 図13に示されている例では、[_INTERFACE_]セクション、[_STRUCTURE_]セクション及び[_DATA_SPEC_]セクションが、予め名称が規定された機能セクションであり、[absltVelocity]セクション及び[avrgVelocity]セクションが、任意の名前を持つデータ内容定義セクションであり、[_DATA_SPEC_]セクションが、データの変換方法を定義するデータ変換定義セクションである。
[0099]
 MCFGファイル281にて最初に記載されているのは、インタフェース情報セクション[_INTERFACE_]である。
 「AppliId」は、要求元のアプリケーションである上位アプリ130を識別するための識別情報(アプリケーションID)を示す。ここでは、第1上位アプリ130aのアプリケーションID(app1)及び第2上位アプリ130bのアプリケーションID(app2)が示されている。
 「SensorId」は、データの要求対象である補助機器1の識別情報(センサID)を示す。ここでは、「sens1」、「sens3」及び「sens4」のセンサIDが示されている。
 「UpSndTiming」は、要求されたデータを要求元アプリケーションへ送信する際の送信タイミングを示す。ここでは、データの送信周期([ms]単位)が示されている。
 「UpSndWait」は、データの送信が、「UpSndTiming」で示されているタイミングから遅れる場合に、許容される遅延時間を示す値である送信ウェイト間隔を示す。
 「UpIfType」は、要求元の上位アプリ130へ送信する際に使用されるインタフェースの種別を示す。
[0100]
 次に、[_STRUCTURE_]セクションは、上位提供データ構造定義セクションであり、補助機器1から提供されたデータの組み合わせを、CSMW211が上位アプリ130に提供するデータの構造を定義する。
 図13では、[_STRUCTURE_]セクションで定義されるデータ構造体のメンバ変数として、「absltVelocity」、「avrgVelocity」、「sens1.RangeDistance」、「sens4.sheetPosition」及び「sens4.sheetTemp」が含まれている。
 「absltVelocity」、「avrgVelocity」及び「sens1.RangeDistance」は、それぞれ32ビットで構成されており、「sens4.sheetPosition」及び「sens4.sheetTemp」は、それぞれ16ビットで構成されている。
[0101]
 「absltVelocity」は、対象となる補助機器1から提供される絶対速度のデータを示す。
 「avrgVelocity」は、対象となる補助機器1から提供される、1tripにおける平均速度のデータを示す。1tripは、1回の走行を示し、例えば、自動車MOのエンジンをかけてから、それを停止するまでの間を示す。
 「sens1.RangeDistance」は、「sens1」で識別される補助機器1から提供される物体距離のデータを示す。
 「sens4.sheetPosition」は、「sens4」で識別される補助機器1から提供されるシート位置のデータを示す。
 「sens4.sheetTemp」は、「sens4」で識別される補助機器1から提供されるシート温度のデータを示す。
[0102]
 次に、[_DATA_SPEC_]セクションは、データ変換定義セクションであり、単位変換及び式変換を使用して、ある補助機器1から提供されるデータの単位又は内容を変換したり、補助機器1から提供される複数のデータから1つのデータを作成したりする際の変換方法を定義する。
[0103]
 ここでは、[_DATA_SPEC_]セクションは、[_STRUCTURE_]で定義された構造体メンバの内、単位変換及び式変換を使用して提供データ形式へ変換する場合の変換方法を定義する。図13では、[_STRUCTURE_]で定義された「absltVelocity」及び「avrgVelocity」について、図12に示されている式変換テーブル137を参照することにより特定された変換式が示されている。
[0104]
 例えば、「absltVelocity」には、「sens1」で識別される補助機器1から提供される「relativeVelocity(相対速度)」の値と、「sens3」で識別される補助機器1から提供される「ownVelocity(自車速度)」の値とを用いて、絶対速度を算出する算出式が変換方法として示されている。
 「avrgVelocity」には、「sens1」で識別される補助機器1から提供される「1tripDistance」の値と、「sens1」で識別される補助機器1から提供される「1tripTime」の値とを用いて、平均速度を算出する算出式が変換方法として示されている。
[0105]
 図10に戻り、アプリ要求情報伝達部273hは、センサ管理部274から受信されたデータの組み合わせを、要求されたタイミング(所望のタイミング)で、第1インタフェース170を介して上位アプリ130に送る伝送部である。
[0106]
 図9に戻り、CFG生成管理部275は、ドライバ部106から、補助機器1を動作させるための変数及びAPIを記載するコンフィギュレーションファイルを取得して、それをCFGファイル記憶部176に記憶させるファイル管理部である。ここでは、CFG生成管理部275は、補助機器1の各々に対応する1つのドライバ部106を解析して自動的に定型文形式のCFGファイルを生成しているが、管理者等の人が、適宜、ドライバ部106に対応するCFGファイルを作成してもよい。
[0107]
 図14は、実施の形態2におけるCSMW211にて参照するCFGファイルの一例を示す概略図である。
 F/Eボード210に接続する1つの補助機器1に対して1つのCFGファイルが必要である。図14に示されているCFGファイル280は、ミリ波レーダ5を接続する際のものである。
[0108]
 接続するミリ波レーダ5の機種名はMW-Raderであり、それに対応するCFGファイル名は「MW-Rader.ini」である。
 CFGファイル280は、セクションと呼ばれるデータ領域で幾つかのブロックに区切られる。セクションは[]で括られた文字列で定義され、予め名称が規定された機能セクションと、任意の名称を持つデータ内容定義セクションと、データの変換規則を定義するデータ変換定義セクションとがある。
[0109]
 機能セクションは、どの補助機器1が接続されても共通して使用される名称を有する。例えば、図14に示された例では、[_INTERFACE_]、[_STRUCTURE_]及び[_DATA_SPEC_]が機能セクションである。データ内容定義セクションは、接続された補助機器1毎にコーディングする必要があり、そのコード上に表れる変数の名称を示す。例えば、図14に示された例では、[absltVelocity]、[CurveRadius]及び[RangeDistance]がデータ内容定義セクションである。
 なお、データ変換定義セクションは、[_DATA_SPEC_]である。
[0110]
 CFGファイル280にて最初に記載されているのは、インタフェース情報セクション[_INTERFACE_]である。[_INTERFACE_]については、図5に示されているCFGファイル180と同様である。
[0111]
 次に、[_STRUCTURE_]セクションは、上位提供データ構造定義セクションであり、補助機器1から取得されたデータを、CSMW211が上位アプリ130に提供するデータの構造を定義する。
 図14では、[_STRUCTURE_]セクションで定義されるデータ構造体のメンバ変数として、「absltVelocity(絶対速度)」、「CarveRadius(転回半径)」、「RangeDistance(物体距離)」、「RangeRate(物体速度)」及び「Angle(物体角度)」が含まれており、それぞれ、32ビットで構成されている。
[0112]
 次に、[_DATA_SPEC_]セクションは、補助機器1から取得されたデータの形式を、CSMW211が上位アプリ130に提供するデータの形式に変換する変換規則を定義するデータ変換定義セクションである。
 図14に示されている例では、[_DATA_SPEC_]セクションは、[_STRUCTURE_]セクションで定義された構造体メンバの各々に対して、変換規則が定義されている。
 例えば、[_STRUCTURE_]の構造体メンバである[absltVelocity]では、「IdF」は、データを取得するインタフェースの種別を示し、図14の例では、CAN101からデータを取得することが示されている。「Id」は、CAN IDを示し、「Ox730」のCAN IDで送られてきたデータが絶対速度を格納していることを示している。「F」は、上述のように変数そのものを示し、「#2」は、データの2バイト目の1バイトが変数の値であることを示している。
[0113]
 以上のように、CFGファイル280には、使用するAPI群の定義、メンバ変数の宣言及び定義等の情報が記載される。
[0114]
 図9に戻り、CFG生成管理部275は、MCFG情報生成部273gから与えられたMCFGファイルに基づいて、上位アプリ130から要求されたデータ又は上位アプリ130から要求されたデータを算出するための特定のデータを提供する補助機器1を特定するとともに、センサ管理部274に、特定された補助機器1からデータを取得させるファイル管理部である。ここで、実施の形態2では、CFG生成管理部275は、MCFG情報生成部273gから与えられたMCFGファイルに変換方法が含まれている場合には、その変換方法もセンサ管理部274に通知し、センサ管理部274に特定のデータの変換を行わせる。
[0115]
 センサ管理部274は、補助機器1を、第2インタフェース171を介して管理する補助機器管理部である。例えば、センサ管理部274は、シンボル情報に記載された変数及びAPIを使用して、CFG生成管理部275で特定された補助機器1を動作させることで、その補助機器1から必要なデータの提供を受ける。なお、CFG生成管理部275から変換方法が通知された場合には、センサ管理部274は、補助機器1から取得された特定のデータを変換方法に従って変換する。
 そして、センサ管理部274は、CFG生成管理部275から要求されたデータの組み合わせをアプリ要求情報伝達部273hに送信する。
[0116]
 次に、第1上位アプリ130a及び第2上位アプリ130bが、CSMW211を介して、補助機器1から複数のデータの組み合わせを取得する場合において、補助機器1に含まれるセンサが別のセンサに置き換えられ、従来のセンサから供給されるデータと、置き換えられた別のセンサから供給されるデータとが異なるときのCSMW211の動作を説明する。
[0117]
 例えば、ソナー6が、従来のソナーAから新たなソナーBに置換され、それに伴い対応するドライバ部106もソナーAのドライバ部106からソナーBのドライバ部106に置き換わったものとする。
 従来のソナーAのドライバ部106は、ソナーAでセンシングした対象物の絶対速度を「absltVelocity=~km/h」なる時速情報で、また、自車の1トリップ平均速度を「avrgVelocity=~km/h」なる時速情報で上位アプリ130に提供していたものとする。
 一方、新たなソナーBのドライバ部106は、ソナーBでセンシングした対象物の速度を絶対速度では無く相対速度「relativeVelocity=~m/s」なる秒速情報で、また、自車の平均速度の代わりに、1トリップの走行距離「1tripDistance=~m」及び1トリップの所要時間「1tripTime=~s」を上位アプリ130に提供するものとする。
 また、新たに置換された訳ではないが、ミリ波レーダ5は、その時その時の自車速度を、「ownVelocity=~km/h」なる時速情報で、上位アプリ130に提供しているものとする。
[0118]
 今回、第1上位アプリ130a及び第2上位アプリ130bは、センシングした対象物の絶対速度を時速で、自車の1トリップ平均速度を時速で、第1センサ1aの物体距離、第4センサ1dのシート位置及びシート温度を要求するものとし、これらのデータを100msの周期で要求するものとする。
[0119]
 このような場合、第1上位アプリ130a及び第2上位アプリ130bは、絶対速度、1トリップ平均速度、物体距離、シート位置及びシート温度のデータの組み合わせを、100msの周期で取得したい旨の要求を、CSMW211の第1インタフェース170を介して、アプリ要求受付部273aに送信する。
[0120]
 アプリ要求受付部273aで受け付けられた要求は、アプリ要求パース部273bにて分析され、どの上位アプリ130が、どの様なデータの組み合わせを、如何なるタイミングで所望しているかを要求内容として把握する。このようにして把握された要求内容は、アプリ要求整合管理部273cに送信される。
[0121]
 アプリ要求整合管理部273cは、第1上位アプリ130a及び第2上位アプリ130bが補助機器1から取得すべきデータが変化していないか、CFG生成管理部275と連携をとりながら、常にチェックしている。なお、CFG生成管理部275は、全てのドライバ部106に対応する定型文形式のCFGファイルを生成及び管理しているので如何なるデータがドライバ部106から取り出せるか把握している。
[0122]
 対応する補助機器1から取得すべきデータが変化していない場合は、アプリ要求整合管理部273cは、その旨をMCFG情報生成部273gに通知する。この場合には、MCFG情報生成部273gは、実施の形態1と同様のMCFGファイルを生成して、CFG生成管理部275に与える。
[0123]
 一方、対応する補助機器1から取得すべきデータが変化している場合には、変化前のデータと同義にするために、アプリ要求整合管理部273cは、変換部273dに変換方法を特定するように指示する。例えば、データの単位の変換が必要な場合は、アプリ要求整合管理部273cは、単位変換テーブル136を持った単位変換部273eに変換すべき単位を通知して、変換規則の特定を指示する。このような指示を受けた単位変換部273eは、対応する変換規則を特定して、MCFG情報生成部273gに通知する。また、データの算出が必要な場合は、アプリ要求整合管理部273cは、式変換テーブル137を持った式変換部273fに算出すべきデータを通知して、算出式の特定を指示する。このような指示を受けた式変換部273fは、対応する算出式を特定して、MCFG情報生成部273gに通知する。
[0124]
 そして、MCFG情報生成部273gは、実施の形態1とは異なり、変換方法を含むMCFGファイルを生成して、CFG生成管理部275に与えて、読み込ませる。
[0125]
 MCFGファイルを読み込んだCFG生成管理部275は、MCFGファイルに従って、データの組み合わせをセンサ管理部274に要求する。この際、MCFGファイルに変換方法が記載されている場合には、CFG生成管理部275は、その変換方法についてもセンサ管理部274に通知する。
[0126]
 センサ管理部274は、要求されたデータの組み合わせをアプリ要求情報伝達部273hに送信する。この際、CFG生成管理部275から変換方法が通知されている場合には、補助機器1から提供されるデータに変換方法を適用して、要求されたデータを生成する。
[0127]
 そして、アプリ要求情報伝達部273hは、送信されたデータの組み合わせを所望のタイミングで第1インタフェース170を介して、第1上位アプリ130a及び第2上位アプリ130bに送る。
[0128]
 以上のようにして、第1上位アプリ130a及び第2上位アプリ130bは、絶対速度、1トリップ平均速度、物体距離、シート位置及びシート温度のデータの組み合わせを所望のタイミングで取得することができる。
[0129]
 なお、アプリ要求整合管理部273cは、上位アプリ130から要求されたデータが変化していないか、CFG生成管理部275と連携をとりながら、常にチェックする。例えば、アプリ要求パース部273bから与えられた要求内容をメモリ273c#に記憶しておき、補助機器1が取り替えられた等により、補助機器1から得られるデータが変化した場合には、単位変換部273e、式変換部273f及びMCFG情報生成部273gに指示することで、再度、MCFGファイルを生成させる。ここで、補助機器1が取り替えられても、上位アプリ130から要求されたデータが変化していない場合には、MCFGファイルの再生成は行われない。
[0130]
 以上説明した本実施の形態2によれば、上記(1)及び(2)の効果の他に、下記(3)の効果が得られる。
[0131]
 (3)実施の形態2では、車両制御システム200は、自動車MOに搭載された単眼カメラ2、ステレオカメラ3、ミリ波レーダ5、ソナー6又はLIDAR7といった各種補助機器1、これら各種補助機器1を動作させる機能部、及び、下位機能部131から上位機能部132へデータを受け渡すCSMW211から構成される。各種補助機器1は、自動車MOに搭載されているが、常に同じ機器に置換されるとは限らず、異なるバージョンの機器又は仕様の異なる他社の機器に置換されることもある。例えば、ミリ波レーダ5が他社製のミリ波レーダに置き換えられることもある。そして、特定の上位アプリ130が、下位機能部131である特定の補助機器1から、所望のデータの組み合わせを所望の周期で取得する場合において、上位アプリ130へ送信されるデータが、補助機器1の置換前と同じではないときには、単位変換部273eによる単位変換及び式変換部273fによる式変換の少なくとも何れか一方が行われる。これにより、上位アプリ130は、補助機器1の置換前後において、所望するデータの組み合わせを所望の周期で取得することができる。なお、このような場合、補助機器1のドライバ部106に相当する下位機能部131のみを改修するだけで、補助機器1の置換が可能であり、CSMW211の上位アプリ130は変える必要がないため、様々な開発現場でドライバ相当機能ユニットのみを開発するだけで済む。このため、車両制御システム100は、アプリケーションサポートパッケージとして製品化することが可能である。
[0132]
 なお、本発明は、上記実施の形態1及び2に限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の態様で実施することができる。

符号の説明

[0133]
 100,200 車両制御システム、 1 補助機器、 2 単眼カメラ、 3 ステレオカメラ、 4 側方ソナー、 5 ミリ波レーダ、 6 ソナー、 7 LIDAR、 105,205 制御装置、 106 ドライバ部、 110,210 F/Eボード、 111,211 CSMW、 130 上位アプリ、 131 下位機能部、 132 上位機能部、 140 B/Eボード、 150 ナビボード、 170 第1インタフェース、 171 第2インタフェース、 172 メイン部、 173,273 アプリケーション管理部、 173a,273a アプリ要求受付部、 173b,273bアプリ要求パース部、 CFG情報処理部、 273c アプリ要求整合管理部、 273e 単位変換部、 273f 式変換部、 273g MCFG情報生成部、 273h アプリ要求情報伝達部、 174,274 センサ管理部、 175,275 CFG生成管理部、 176 CFGファイル記憶部。

請求の範囲

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

図面

[ 図 1]

[ 図 2]

[ 図 3]

[ 図 4]

[ 図 5]

[ 図 6]

[ 図 7]

[ 図 8]

[ 図 9]

[ 図 10]

[ 図 11]

[ 図 12]

[ 図 13]

[ 図 14]