(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-10-07
(45)【発行日】2024-10-16
(54)【発明の名称】車載機器制御装置及び車両制御システム
(51)【国際特許分類】
G06F 9/54 20060101AFI20241008BHJP
【FI】
G06F9/54 F
(21)【出願番号】P 2020032209
(22)【出願日】2020-02-27
【審査請求日】2022-08-23
(73)【特許権者】
【識別番号】000003137
【氏名又は名称】マツダ株式会社
(74)【代理人】
【識別番号】110001427
【氏名又は名称】弁理士法人前田特許事務所
(72)【発明者】
【氏名】中矢 祐介
【審査官】坂東 博司
(56)【参考文献】
【文献】米国特許出願公開第2017/0028993(US,A1)
【文献】特開2017-157004(JP,A)
【文献】特開2013-171547(JP,A)
【文献】米国特許出願公開第2001/0025216(US,A1)
【文献】米国特許出願公開第2007/0073944(US,A1)
【文献】特開2010-286935(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/54
(57)【特許請求の範囲】
【請求項1】
車載機器を制御する制御部と記憶部とを備える車載機器制御装置であって、
前記制御部は、ソフトウェアの構成として、
前記車載機器についての諸機能を実現するためのアプリケーションが実装されたアプリケーション層と、
アプリケーションから受け取ったコマンドをハードウェア用のコマンドに変換するデバイスドライバと、
前記アプリケーションと通信パケットをやり取りする1または複数の第1通信パケットと、前記デバイスドライバと通信パケットをやり取りする1または複数の第2通信パケットとが実装され、前記第1通信パケットと前記第2通信パケットとの接続関係を特定するマッピングテーブルに基づいて前記アプリケーション層と前記デバイスドライバとの間の通信経路を生成するミドルウェア層と、
を有し、
前記記憶部は、前記制御部を動作させるためのプログラムが記憶されたコード領域と、データ領域とを備え、
前記記憶部のデータ領域には、所定の物理量の変換ルールを示す物理量変換ルール
と前記マッピングテーブルが格納され、
前記ミドルウェア層は、
前記第1通信パケットと前記第2通信パケットとの間を通信データが通過する際に、当該通信データに含まれる物理量データ
に対して前記物理量変換ルールに従った
演算を適用することで、前記物理量データを変換する物理量変換モジュールを備える、車載機器制御装置。
【請求項2】
請求項1に記載の車載機器制御装置において、
前記所定の変換ルールは、所定の一次関数であり、
前記物理量変換モジュールは、前記所定の一次関数を用いて前記物理量データの変換演算をする、車載機器制御装置。
【請求項3】
車両の所定のゾーン毎に配置された複数のゾーンECUと、当該複数のゾーンECUを統括する中央演算装置とを備え、
1または複数の前記ゾーンECUは、請求項1または2に記載の車載機器制御装置を備える、車両制御システム。
【発明の詳細な説明】
【技術分野】
【0001】
ここに開示された技術は、車載機器制御装置及び車両制御システムに関する技術分野に属する。
【背景技術】
【0002】
近年では、国家的に自動運転システムの開発が進められており、車両に備えられたアクチュエータのほぼ全てが電子制御されるようになっている。これらアクチュエータの制御を行う制御装置は、AUTOSAR(AUTomotive Open System ARchitecture)の規格に準拠するソフトウェア構造を有することが多い。
【0003】
例えば特許文献1には、AUTOSARの規格に則ったソフトウェア構造を有する制御システムにおいて、通信データに、予め送信元、受信先、及びデータの種類を示す情報を含ませておき、アプリケーション層において、送信元又は受信先から把握される相手の階層と、データの種類とに応じて選択される通信インターフェースサービスを、当該通信データに適用するものが開示されている。
【先行技術文献】
【特許文献】
【0004】
【発明の概要】
【発明が解決しようとする課題】
【0005】
ところで、AUTOSARのような階層的ソフトアーキテクチャにおいて、アプリケーションは、ペリフェラル毎のデバイスドライバが提供しているAPI(Application Programing Interface)を呼び出し、各I/Oとのやり取りを行う。
【0006】
ここで、例えば、I/Oに接続される車載機器が変更されて、取得する物理量の変化に対する信号変化の特性が変わる場合がある。このような場合には、アプリケーションのコードを書き換えて物理量の変換処理を行う必要がある。そうすると、アプリケーションのプログラムを再コンパイルしてメモリのデータを置き換える必要があり、ソフトウェアの開発工数及び検証工数が増加してしまう。
【0007】
ここに開示された技術は、斯かる点に鑑みてなされたものであり、その目的とするところは、ソフトウェアの開発工数を低減させることにある。
【課題を解決するための手段】
【0008】
前記課題を解決するために、ここに開示された技術では、車載機器を制御する制御部と記憶部とを備える車載機器制御装置を対象として、前記制御部は、ソフトウェアの構成として、前記車載機器についての諸機能を実現するためのアプリケーションが実装されたアプリケーション層と、アプリケーションから受け取ったコマンドをハードウェア用のコマンドに変換するデバイスドライバと、前記アプリケーションと前記デバイスドライバとの間の通信経路を生成するミドルウェア層と、を有し、前記ミドルウェア層は、前記通信経路を伝送されるデータに含まれる物理量データを所定の変換ルールに従って変換する物理量変換モジュールを備える構成とした。
【0009】
本態様によると、車載機器の変更等により、車載機器制御装置に接続される車載機器の特性が変わった場合においても、アプリケーションのプログラムコードを修正することなく、物理量変換モジュールの変換ルールを書き換えるだけで上記特性変更に対応することができる。これにより、車両のモデルチェンジや車種展開時等におけるソフトウェア開発工数を大幅に低減することができる。
【0010】
また、ここに開示された技術では、車両制御システムを対象として、車両の所定のゾーン毎に配置された複数のゾーンECUと、当該複数のゾーンECUを統括する中央演算装置とを備え、1または複数の前記ゾーンECUは、上記態様の車載機器制御装置を備える。
【0011】
車両に複数のゾーンECUを設けて、それを中央演算装置で管理する場合には、ゾーンECUに対して車載機器が接続される。このとき、車載機器の変更が行われる場合があるが、本態様の構成を用いることで、中央演算装置及びゾーンECUの双方において、ソフトウェア開発工数が大幅に低減できる。
【発明の効果】
【0012】
以上説明したように、ここに開示された技術によると、車種展開時のソフトウェア開発の工数を大幅に低減することができる。
【図面の簡単な説明】
【0013】
【
図2A】実施形態の車載機器制御装置の構成例を示す図である。
【
図2B】実施形態の車載機器制御装置の構成例を示す図である。
【
図3】物理量変換ルールについて説明するための図である。
【
図4A】比較例の車載機器制御装置の構成例を示す図である。
【
図4B】比較例の車載機器制御装置の構成例を示す図である。
【発明を実施するための形態】
【0014】
以下、例示的な実施形態について、図面を参照しながら詳細に説明する。
【0015】
(車両制御システム)
図1は車両制御システムの構成例を示す図である。
図1の車両制御システムは、車両1に搭載されており、車両1の所定のゾーン毎に配置された複数のゾーンECU40と、複数のゾーンECU40を統括する中央演算装置10とを備える。本実施形態の車両制御システムでは、車両1を6つのゾーンに分け、各ゾーンにゾーンECU40が設けられている例を示している。ゾーンECU40は、車載機器を接続することができるように構成されている。また、ゾーンECU40は、車内のネットワークを介して伝送される情報を中継するネットワークハブ装置としての機能を有する。なお、説明の便宜上、車両1の左前側の左フロントゾーンに配置されたゾーンECU40を第1ゾーンECU41ということがある。
【0016】
〈車載機器〉
車載機器20は、センサデバイス200及び信号受信デバイスを含む入力機器と、アクチュエータ300とを含む。
【0017】
《センサデバイス、信号受信デバイス》
センサデバイス200は、例えば、(1)車両1のボディ等に設けられかつ車外環境を撮影する複数のカメラ201、(2)車両1のボディ等に設けられかつ車外の物標等を検知する複数のレーダ202、(3)全地球測位システム(Global Positioning System:GPS)を利用して、車両1の位置(車両位置情報)を検出する位置センサ(図示省略)、(4)車速センサ、加速度センサ、ヨーレートセンサ等の車両の挙動を検出するセンサ類の出力から構成され車両1の状態を取得する車両状態センサ(図示省略)、(5)車内カメラ203等により構成され、車両1の乗員の状態を取得する乗員状態センサ、(6)運転者の運転操作を検出する運転操作センサ206、(7)キーレス装置を作動させるためのセンサ211(以下、キーレスセンサ211という)、(8)車室内の温度を測定する室温センサ220を含む。運転操作センサ206は、例えば、アクセル開度センサ、操舵角センサ、ブレーキ油圧センサなどを含む。また、センサデバイス200には、乗員による操作を検出するスイッチを含む。スイッチは、例えば、乗員が電動パワーウィンドウを動作させるためのPWスイッチ212、ウォッシャーレベルスイッチ、フードスイッチ等を含む。
【0018】
信号受信デバイスは、例えば、外部のネットワークや、他車両からの信号を受信する受信装置が含まれる。
【0019】
《アクチュエータ》
アクチュエータ300は、駆動系のアクチュエータ、操舵系のアクチュエータ、制動系のアクチュエータなどを含む。駆動系のアクチュエータの例としては、エンジン、トランスミッション、モータが挙げられる。制動系のアクチュエータの例としては、ブレーキが挙げられる。操舵系のアクチュエータの例としては、ステアリングが挙げられる。また、アクチュエータ300は、例えば、サイドドアをロックするためのドアロック装置301、電動パワーウィンドウ装置302、前照灯FLの点灯を制御する点灯制御装置310、エアバック装置311、音響装置312、エアコン装置320等を含む。
【0020】
〔車載機器制御装置〕
車載機器制御装置100は、1または複数のゾーンECU40に搭載される。すなわち、車載機器制御装置100は、すべてのゾーンECU40に搭載されてもよいし、ゾーンECU40の一部に搭載されてもよい。また、車載機器制御装置100が、(1)中央演算装置10に搭載されてもよいし、(2)ゾーンECU40の下位に接続された、各アクチュエータ専用に設けられた専用ECU(図示省略)に搭載されてもよい。専用ECUは、例えば、エンジンを駆動するためのエンジン駆動用ECUが例示される。中央演算装置10及び各ECUは、単一のIC(Integrated Circuit)により構成されてもよいし、複数のICにより構成されてもよい。
【0021】
図2Aは、車載機器制御装置100の構成例を示すブロック図である。車載機器制御装置100は、例えば、CPU150(プロセッサ)とメモリ160とにより構成される。
【0022】
〈CPU〉
CPU150は、メモリ160からプログラム162を読み出して実行することにより各種の処理をおこなう。具体的には、例えば、センサデバイス200で検出された検出データを読み取ったり、諸機能を実現するために各種の演算処理を行ったり、アクチュエータ300を制御するための制御信号を生成して出力する。CPU150は、制御部の一例である。なお、CPU150の具体的な態様は、特に限定されない。例えば、マイクロコンピュータ(いわゆるマイコン)で実現されていてもよいし、SoC(System-on-Chip)で実現されてもよい。
【0023】
《ハードウェア》
CPU150は、ハードウェアの構成として、メモリ160に格納されたプログラムにしたがって各種の演算処理を実行する演算部と、ペリフェラル機能ユニット180とを備える。ここでいうペリフェラルとは、中央演算装置10及び/またはゾーンECU40と組み合わせて利用される車載機器20を指すものとする。
【0024】
ペリフェラル機能ユニット180は、ペリフェラル、すなわち、車載機器20を機能させるための1または複数のペリフェラル機能部181を備える。
図2Aに示すように、ペリフェラル機能部181には、例えば、アナログデジタルコンバータ181a(以下、ADC181aという)、デジタル入力部181b、デジタル出力部181c及びPWM制御部181dが含まれる。なお、ペリフェラル機能部181として、
図2Aの構成181a~181dの一部が搭載されてもよいし、他の構成が含まれていてもよい。なお、以下において、ADC181a、デジタル入力部181b、デジタル出力部181c及びPWM制御部181dの各ペリフェラル機能を特に区別しないで説明する場合、単にペリフェラル機能部181と記載する。
【0025】
ペリフェラル機能部181は、それぞれ、複数のチャネルを有する。各チャネルには、車載機器20の入出力部(例えば、I/O接続用のコネクタ)が接続できるように構成されている。
図2Aでは、上記チャネルとして、ADC181aに入力用のチャネルCHa1,CHa2が、デジタル入力部181bに入力用のチャネルCHb1,CHb2が、デジタル出力部181cに出力用のチャネルCHc1,CHc2が、PWM制御部181dに出力用のチャネルCHc1,CHc2が、それぞれ設けられている例を示している。なお、各ペリフェラル機能部181のチャネル数は、2つに限定されず、3つ以上であってもよい。また、単一のペリフェラル機能部181に、入力用及び出力用の両方のチャネルが設けられていてもよい。
【0026】
《ソフトウェア》
CPU150は、ソフトウェアの構成として、最上位のアプリケーション層120と、アプリケーション層の下位にあるミドルウェア層130と、ミドルウェア層130の下位にある基本ソフトウェア層140とを有する。CPU150は、いわゆるAUTOSARに準拠したソフトウェア構造を採用してもよい。この場合、アプリケーション層120は、AUTOSARのアプリケーション層に対応し、例えば、1または複数のSWC(Software Component)モジュールで構成される。基本ソフトウェア層140及びミドルウェア層130は、AUTOSARのBSW(Basic Software)に相当し、基本ソフトウェア層140はAUTOSARのMCAL(Microcontroller Abstraction Layer)に相当する。なお、ミドルウェア層130をComplex Driverとして実装してもよい。
【0027】
アプリケーション層120は、車載機器20に対する諸機能が実装されたアプリケーション121が実装されている。アプリケーション121には、周知構成のものが採用できる。アプリケーション121の具体例について、後ほど説明する。
【0028】
基本ソフトウェア層140は、アプリケーション121から受け取ったコマンドをハードウェア用のコマンドに変換するデバイスドライバユニット141が実装される。デバイスドライバユニット141には、ペリフェラル機能ユニット180に含まれるペリフェラル機能部181毎のデバイスドライバが実装される。前述のとおり、
図2Aの例では、ペリフェラル機能部181として、ADC181a、デジタル入力部181b、デジタル出力部181c及びPWM制御部181dが含まれる。そこで、デバイスドライバユニット141には、ADC181aのためのデバイスドライバであるADCドライバ141aと、デジタル入力部181b及びデジタル出力部181cのためのデバイスドライバであるDIOドライバ141bと、及びPWM制御部181dのためのデバイスドライバであるPWMドライバ141dとが含まれる。すなわち、ADCドライバ141aはADC181aに接続され、DIOドライバ141bはデジタル入力部181b及びデジタル出力部181cに接続され、PWMドライバ141dはPWM制御部181dに接続される。
【0029】
デバイスドライバは、ハードウェア依存性のあるソフトウェアである。一般的に、基本ソフトウェア層140には、ハードウェアに依存しないソフトウェア(例えば、オペレーティングシステム等)も実装されるが、本願発明との関連性が低いので、本実施形態では、図示及び説明を省略している。
【0030】
ミドルウェア層130は、マッピングモジュール133と、物理量変換モジュール135とが実装されている。マッピングモジュール133は、アプリケーション121とデータをやり取りするための1または複数の第1通信パケット131と、デバイスドライバとデータをやり取りするための1または複数の第2通信パケット132とを有する。
【0031】
図2Aの例では、第1通信パケット131として、IO_1,IO_2,…IO_X(Xは自然数)が実装されている。また、第2通信パケット132として、(1)ADCドライバ141aとデータをやり取りするためのADC_1,ADC_2,…ADC_L(Lは自然数)、(2)DIOドライバ141bとデータをやり取りするためのDI_1,DI_2,…DI_M(Mは自然数)及びDO_1,DO_2,…DO_N(Nは自然数)、(3)PWMドライバ141dとデータをやり取りするためのPWM_1,PWM_2,…PWN_Q(Qは自然数)が実装されている。なお、第1通信パケット131または第2通信パケット132のいずれか一方が単一のパケットであってもよい。
【0032】
マッピングモジュール133は、メモリ160に格納されたマッピングテーブル166に基づいて、アプリケーション層120とデバイスドライバとの通信経路を生成する。マッピングテーブル166では、第1通信パケット131と第2通信パケット132との接続関係が規定されている。より具体的には、例えば、複数の第1通信パケット131と複数の第2通信パケット132がある場合に、それぞれの接続対象となる通信パケットが規定されている。
図2Aのケースでは、通信パケットIO_1の接続対象が通信パケットADC_1であり、通信パケットIO_2の接続対象が通信パケットDI_2であり、通信パケットIO_2の接続対象が通信パケットDO_1であり、通信パケットIO_Xの接続対象が通信パケットPWM_2であることが規定されている。
【0033】
物理量変換モジュール135は、マッピングモジュール133で生成された通信経路を伝送されるデータに含まれる物理量データをメモリ160に格納された物理量変換ルール167に従って変換する。
図2Aの例では、物理量変換モジュール135は、通信パケットIO_1と通信パケットADC_1との間で伝送されるデータ、及び、通信パケットIO_3と通信パケットDO_1との間で伝送されるデータについて、物理量を変換する。また、通信パケットIO_2と通信パケットDI_2との間で伝送されるデータ、及び、通信パケットIO_Xと通信パケットPWM_2との間で伝送されるデータについては、物理量の変換を行わないようになっている。このように、物理量変換モジュール135は、第1通信パケット131と第2通信パケット132との間の一部の通信経路に配置されてもよいし、第1通信パケット131と第2通信パケット132との間のすべての通信経路が物理量変換モジュール135を通過するようにしてもよい。
【0034】
物理量変換モジュール135の適用方法は、特に限定されないが、例えば、
図2Aに示すように、マッピングテーブル166において、第1通信パケット131が物理量変換モジュール135を介して第2通信パケット132と接続されるように接続経路が生成される。そして、物理量変換モジュール135において、第1通信パケット131と第2通信パケット132との間の通信データが通過する際にその通信データに含まれる物理量データに対して物理量変換ルール167に従った演算が適用される。具体的な接続例及び動作例については、後ほど説明する。なお、上記の通信データには、物理量データの他に、パケット長やパケットの種別を示す形式データや、各種のフラグデータ等が含まれ得る。
【0035】
図2Aでは、具体的に図示していないが、上記の他に以下の接続関係がある。通信パケットADC_1はADC181aのチャネルCHa1に、通信パケットADC_2はADC181aのチャネルCHa2にそれぞれ接続される。通信パケットDI_1はデジタル入力部181bのチャネルCHb1に、通信パケットDI_2はデジタル入力部181bのチャネルCHb2にそれぞれ接続される。通信パケットDO_1はデジタル出力部181cのチャネルCHc1に、通信パケットDO_2はデジタル出力部181cのチャネルCHc2にそれぞれ接続される。通信パケットPWM_1はPWM制御部181dのチャネルCHd1に、通信パケットPWM_2はPWM制御部181dのチャネルCHd2にそれぞれ接続される。
【0036】
なお、ミドルウェア層130において、アプリケーション層120とマッピングモジュール133との間に、ランタイム環境(RTE)が実装されていてもよい。ランタイム環境は、例えば、アプリケーション121と、基本ソフトウェア層140に実装されたソフトウェアとを抽象化して接続する。この場合、第1通信パケット131は、ランタイム環境とマッピングモジュール133との間のデータのやり取りをするために用いられる。
【0037】
〈メモリ〉
メモリ160は、記憶領域として、CPU150を動作させるためのプログラム162が記憶されたコード領域161と、CPU150での処理結果、マッピングテーブル166及び物理量変換ルール167等のデータを記憶する書き換え可能なデータ領域165とを備える。コード領域には、例えば、車載機器制御装置100の設計段階において、あらかじめ作成されたプログラム162がコンパイルされて実装されている。前述のとおり、マッピングテーブル166には、第1通信パケット131と第2通信パケット132との接続関係を特定するためのデータが格納される。また、物理量変換ルール167には、ミドルウェア層130に生成された通信経路を伝送されるデータに含まれる物理量データを変換する変換ルール(例えば、演算式)が格納される。メモリ160は記憶部の一例である。
【0038】
〔車載機器制御装置の動作例〕
次に、
図2A及び
図2Bを用いて、車載機器制御装置100の動作の一例を説明する。ここでは、第1ゾーンECU41に車載機器制御装置100が実装されているものとして説明する。第1ゾーンECU41には、主に車両1の左フロントゾーンに配置されたセンサデバイス200及びアクチュエータ300が接続される。
図1に示すように、第1ゾーンECU41には、例えば、車外左側方を撮像するカメラ201、キーレスセンサ211、PWスイッチ212、ドアロック装置301、電動パワーウィンドウ装置302、室温センサ220及びエアコン装置320が接続されている。
【0039】
図2A及び
図2Bは、各車載機器20と各ペリフェラル機能部181との接続状態の一例を示している。
【0040】
図2Aのケースでは、第1室温センサ221がADC181aのチャネルCHa1、キーレスセンサ211がデジタル入力部181bのチャネルCHb1、第1エアコン装置321がデジタル出力部181cのチャネルCHc1、ドアロック装置301がPWM制御部181dのチャネルCHd1にそれぞれ接続されているものとする。
図2Aにおいて、カメラ201、PWスイッチ212及び電動パワーウィンドウ装置302の図示を省略している。
図2Bについても同様である。
【0041】
そして、
図2Bのケースでは、ADC181aのチャネルCHa1に第2室温センサ222が接続され、デジタル出力部181cのチャネルCHc2に第2エアコン装置322が接続されている点で
図2Aと異なっている。このような車載機器20の変更は、例えば、車両のモデルチェンジや設計変更、サプライヤー変更等が発生する場合、互いにグレードや車体の大きさ等が異なる車種に対して共通のプログラムを使用する場合等に発生し得る。
【0042】
図2A及び
図2Bのケースに共通して、コード領域161のプログラム162として、例えば、室温センサ220の測定温度の読み出し処理、及び、キーレスセンサ211からの入力信号の読み出し処理についてプログラミングされている。また、プログラム162として、室温センサ220の測定温度に応じたエアコン装置320の送風温度及び風量調整処理、キーレスセンサ211からの入力信号に応じたドアロック装置301の施錠/開錠処理についてプログラミングされている。
【0043】
《動作例1:ドアロック》
図2A及び
図2Bにおいて、アプリケーション121は、キーレスセンサ211からの入力信号の読み出し処理についての命令をパケット化し、マッピングモジュール133に通信パケットIO_2として送信する。前述のとおり、マッピングモジュール133において、通信パケットIO_2は、通信パケットDI_2に接続されている。これにより、アプリケーション121の命令に基づいてDIOドライバ141bが動作し、デジタル入力部181bで取得されたキーレスセンサ211の受信信号がミドルウェア層130の通信パケットDI_2に送信される。通信パケットDI_2は、通信パケットIO_2に送信される。
【0044】
そして、アプリケーション121は、通信パケットIO_2として、キーレスセンサ211からの入力信号を受信すると、その入力信号に基づいてドアロック装置301の施錠/開錠処理についての命令をパケット化し、マッピングモジュール133に通信パケットIO_Xとして送信する。前述のとおり、マッピングモジュール133において、通信パケットIO_Xは、通信パケットPWM_2に接続されている。これにより、アプリケーション121の命令に基づいてPWMドライバ141dが動作し、PWM制御部181dを介してドアロック装置301の施錠または開錠が実行される。
【0045】
《動作例2:エアコン装置》
図2Aにおいて、アプリケーション121は、室温センサ220の操作情報の読み出し処理についての命令をパケット化し、マッピングモジュール133に通信パケットIO_1として送信する。通信パケットIO_1は、マッピングモジュール133において、通信パケットADC_1に接続されている。これにより、アプリケーション121の命令に基づいてADCドライバ141aが動作し、ADC181aで取得された第1室温センサ221の測定温度データがミドルウェア層130の通信パケットADC_1に送信される。通信パケットADC_1は、物理量変換モジュール135に送信される。
【0046】
物理量変換モジュール135では、物理量変換ルール167に基づく変換処理が実行される。例えば、メモリ160には、物理量変換ルール167として、第1室温センサ221について、
図3上段のグラフに示す演算式が格納されているとする。そうすると、物理量変換モジュール135では、室温センサ220での測定温度D1に対して「(D1×2)-1」の変換演算が実行される。変換演算の結果は、通信パケットIO_2を介して、アプリケーション121に送信される。測定温度D1は物理量の一例であり、上記演算式は所定の一次関数の一例である。
【0047】
アプリケーション121は、通信パケットIO_2として、物理量変換モジュール135から変換演算済の測定温度データを受信すると、その測定温度データに基づいてエアコン装置320の送風温度及び送風量についての命令をパケット化し、マッピングモジュール133に通信パケットIO_3として送信する。前述のとおり、通信パケットIO_3は、マッピングモジュール133において、物理量変換モジュール135を介して通信パケットDO_1に接続されている。送風温度及び送風量は、物理量の一例である。ここでは、送風温度及び送風量をまとめて「送風制御量D2」と呼ぶものとする。すなわち、送風制御量D2は、物理量の一例である。
【0048】
物理量変換モジュール135では、物理量変換ルール167に基づく変換処理が実行される。例えば、メモリ160には、物理量変換ルール167として、第1エアコン装置321の送風制御量D2について、「D2/2」の演算式が格納されているとする。そうすると、物理量変換モジュール135では、アプリケーション121から出力された送風制御量D2を1/2にする変換演算を実行する。変換演算の結果は、通信パケットDO_1を介してDIOドライバ141bに入力される。これにより、アプリケーション121の命令に基づいてDIOドライバ141bが動作し、デジタル出力部181cを介して第1エアコン装置321の送風温度及び送風量の設定が実行される。上記の演算式は、所定の一次関数の一例である。
【0049】
ここで、
図2Aから
図2Bへの接続変更があったとする。このような場合に、本実施形態では、コード領域161のプログラム162は変更せずに、データ領域165のマッピングテーブル166及び/または物理量変換ルール167の書き換えが行われる。
【0050】
具体的に、
図2Bの例では、まず、マッピングテーブル166において、通信パケットIO_3の接続先が通信パケットDO_2に変更される。これにより、マッピングモジュール133において、通信パケットIO_3の接続先が通信パケットDO_2に変更される。また、物理量変換ルール167において、室温センサ220に適用される変換ルールCAL1について、第2室温センサ222に応じたルール変更が実施される。同様に、エアコン装置320に適用される変換ルールCAL2について、第2エアコン装置322に応じたルール変更が実施される。
【0051】
設定が終了すると、
図2Bでは、以下の動作が行われるようになる。
【0052】
具体的に、アプリケーション121は、
図2Aの場合と同様に、室温センサ220の操作情報の読み出し処理についての命令をパケット化し、マッピングモジュール133に通信パケットIO_1として送信する。通信パケットIO_1は、通信パケットADC_1に伝送される。そうすると、アプリケーション121の命令に基づいてADCドライバ141aが動作し、ADC181aで取得された第2室温センサ222の測定温度データがミドルウェア層130の通信パケットADC_1に送信される。通信パケットADC_1は、物理量変換モジュール135に送信される。
【0053】
物理量変換モジュール135では、物理量変換ルール167として、第2室温センサ222ついて、
図3下段のグラフに示す演算式が格納されているとする。そうすると、物理量変換モジュール135では、第2室温センサ222での測定結果D2に対して、「(D1/2)+2」の変換演算が実行される。変換演算の結果は、通信パケットIO_2を介して、アプリケーション121に送信される。
【0054】
ここで、物理量変換ルール167は、アプリケーション121が受信するデータが同じ尺度のデータとなるように変換するためのものである。より具体的には、例えば、
図3のグラフのように、第1室温センサ221と第2室温センサ222とにおいて、その傾きや切片が互いに異なる場合に、それぞれの特性に応じた変換ルールを適用することで、測定値を基準となる尺度にあわせてアプリケーション121に提供することができるようになる。換言すると、物理量変換ルール167により、互いに感度や特性等の異なるセンサデバイス200やアクチュエータ300についてのその感度や特性等の違いを吸収することができる。なお、物理量変換ルール167は、一次関数に限定されず、高次の関数や三角関数等の他の関数を用いたルールを作成してもよい。
【0055】
アプリケーション121は、通信パケットIO_2として、物理量変換モジュール135から変換演算がされた測定温度データを受信すると、その測定温度データに基づいてエアコン装置320の送風制御量D2についての命令をパケット化し、マッピングモジュール133に通信パケットIO_3として送信する。
【0056】
物理量変換モジュール135では、物理量変換ルール167に基づく変換処理が実行される。例えば、メモリ160には、物理量変換ルール167として、第2エアコン装置322の送風制御量D2について、「D2×2+2」の演算式が格納されているとする。そうすると、物理量変換モジュール135では、アプリケーション121から出力された送風制御量D2に対して「D2×2+2」の変換演算が実行される。変換演算の結果は、通信パケットDO_1を介してDIOドライバ141bに入力される。これにより、アプリケーション121の命令に基づいてDIOドライバ141bが動作し、デジタル出力部181cを介して第2エアコン装置322の送風温度及び送風量の設定が実行される。
【0057】
〔比較例〕
図4A及び
図4Bに比較例を示す。
図4A及び
図4Bでは、ミドルウェア層530として単一の通信パケットが実装されているものとする。また、それに応じてプログラム562の構成が異なっている。それ以外の構成は、
図2A及び
図2Bと共通であるものとする。
図2(2A,2B)と
図4(4A,4B)で共通する構成については、下2桁の数字または下2桁及びその後ろの符号を共通にしている。例えば、車載機器制御装置500は、車載機器制御装置100に相当する。
【0058】
具体的に、
図4Aのプログラム562では、コード領域561において、CPU550を動作させるため処理内容が実装される。さらに、プログラム562には、各処理内容を送信するミドルウェア層130での通信パケットについて、ペリフェラル機能部181での接続先チャネル及び必要に応じて物理量に対する演算があわせて設定されることになる。このような構成にすることで、上記実施形態と同様の動作を実現している。
【0059】
そして、
図4Aの構成から
図4Bの構成への変更があった場合、比較例では、コード領域561のプログラム562を変更する必要がある。具体的に、
図4Bのプログラム562において下線を引いた太字部分のように、測定温度の演算式と制御量の演算式を変更する必要がある。
【0060】
以上のように、本実施形態の車載機器制御装置100において、CPU150は、ソフトウェアの構成として、アプリケーション121が実装されたアプリケーション層120と、各種のデバイスドライバが実装されたデバイスドライバユニット141と、アプリケーション121とデバイスドライバとの間の通信経路を生成するミドルウェア層130とを有する。そして、ミドルウェア層130は、通信経路を伝送されるデータに含まれる物理量データを物理量変換ルール167に従って変換する物理量変換モジュール135を備える。
【0061】
このような構成にすることにより、ペリフェラル機能部181に接続されるセンサデバイス200やアクチュエータ300等の車載機器20の特性が変わった場合においても、コード領域161のプログラムを変更することなく、物理量変換ルール167を変更することで、車載機器20の特性変更に対応できるようになる。コード領域161のプログラム162を変更した場合には、その変更が少ない場合においても、全コードについてコンパイルをし直してメモリ160への再書き込みが必要であるが、本実施形態の構成とすることでそのような必要がない。これにより、ソフトウェアの開発工数を大幅に低減することができる。
【0062】
さらに、本実施形態では、ミドルウェア層130に、アプリケーション121とデータをやり取りする第1通信パケット131と、デバイスドライバとデータをやり取りする第2通信パケット132とが実装されている。そして、メモリ160に第1通信パケット131と第2通信パケット132との接続関係を特定する書き換え可能なマッピングテーブル166を格納して、ミドルウェア層130において、マッピングテーブル166に基づいて、アプリケーション層120とデバイスドライバユニット141との通信経路を生成するようにしている。
【0063】
これにより、ペリフェラル機能ユニット180において車載機器20の接続先が変更された場合においても、コード領域161のプログラムを変更することなく、マッピングテーブル166を変更することで、車載機器20の接続先の変更に対応できるようになる。
【0064】
ここに開示された技術は、前述の実施形態に限られるものではなく、請求の範囲の主旨を逸脱しない範囲で代用が可能である。また、前述の実施形態は単なる例示に過ぎず、本開示の範囲を限定的に解釈してはならない。本開示の範囲は請求の範囲によって定義され、請求の範囲の均等範囲に属する変形や変更は、全て本開示の範囲内のものである。
【産業上の利用可能性】
【0065】
ここに開示された技術は、車載機器制御装置を設計するのに有用である。
【符号の説明】
【0066】
10 中央演算装置
40 ゾーンECU
100 車載機器制御装置
120 アプリケーション層
121 アプリケーション
130 ミドルウェア層
135 物理量変換モジュール
141a ADCドライバ(デバイスドライバ)
141b DIOドライバ(デバイスドライバ)
141d PWMドライバ(デバイスドライバ)
150 CPU(制御部)
160 メモリ(記憶部)
167 物理量変換ルール