JP2021135807A

JP2021135807A - 車載機器制御装置及び車両制御システム

Info

Publication number: JP2021135807A
Application number: JP2020032209A
Authority: JP
Inventors: 祐介中矢; Yusuke Nakaya
Original assignee: Mazda Motor Corp
Current assignee: Mazda Motor Corp
Priority date: 2020-02-27
Filing date: 2020-02-27
Publication date: 2021-09-13
Also published as: EP3872635A1; CN113386729B; US11831718B2; CN113386729A; US20210273997A1

Abstract

【課題】車種展開時のソフトウェア開発工数を削減する。【解決手段】車載機器制御装置１００において、制御部１５０は、ソフトウェアの構成として、車載機器２０のアプリケーション１２１が実装されたアプリケーション層１２０と、デバイスドライバと、アプリケーション１２１とデバイスドライバとの間の通信経路を生成するミドルウェア層１３０とを有する。ミドルウェア層１３０は、通信経路を伝送されるデータに含まれる物理量データを所定の変換ルールに従って変換する物理量変換モジュール１３５を備える。【選択図】図２Ａ

Description

ここに開示された技術は、車載機器制御装置及び車両制御システムに関する技術分野に属する。

近年では、国家的に自動運転システムの開発が進められており、車両に備えられたアクチュエータのほぼ全てが電子制御されるようになっている。これらアクチュエータの制御を行う制御装置は、ＡＵＴＯＳＡＲ（AUTomotive Open System ARchitecture）の規格に準拠するソフトウェア構造を有することが多い。

例えば特許文献１には、ＡＵＴＯＳＡＲの規格に則ったソフトウェア構造を有する制御システムにおいて、通信データに、予め送信元、受信先、及びデータの種類を示す情報を含ませておき、アプリケーション層において、送信元又は受信先から把握される相手の階層と、データの種類とに応じて選択される通信インターフェースサービスを、当該通信データに適用するものが開示されている。

特開２０１７−１０５３６２号公報

ところで、ＡＵＴＯＳＡＲのような階層的ソフトアーキテクチャにおいて、アプリケーションは、ペリフェラル毎のデバイスドライバが提供しているＡＰＩ（Application Programing Interface)を呼び出し、各Ｉ／Ｏとのやり取りを行う。

ここで、例えば、Ｉ／Ｏに接続される車載機器が変更されて、取得する物理量の変化に対する信号変化の特性が変わる場合がある。このような場合には、アプリケーションのコードを書き換えて物理量の変換処理を行う必要がある。そうすると、アプリケーションのプログラムを再コンパイルしてメモリのデータを置き換える必要があり、ソフトウェアの開発工数及び検証工数が増加してしまう。

ここに開示された技術は、斯かる点に鑑みてなされたものであり、その目的とするところは、ソフトウェアの開発工数を低減させることにある。

前記課題を解決するために、ここに開示された技術では、車載機器を制御する制御部と記憶部とを備える車載機器制御装置を対象として、前記制御部は、ソフトウェアの構成として、前記車載機器についての諸機能を実現するためのアプリケーションが実装されたアプリケーション層と、アプリケーションから受け取ったコマンドをハードウェア用のコマンドに変換するデバイスドライバと、前記アプリケーションと前記デバイスドライバとの間の通信経路を生成するミドルウェア層と、を有し、前記ミドルウェア層は、前記通信経路を伝送されるデータに含まれる物理量データを所定の変換ルールに従って変換する物理量変換モジュールを備える構成とした。

本態様によると、車載機器の変更等により、車載機器制御装置に接続される車載機器の特性が変わった場合においても、アプリケーションのプログラムコードを修正することなく、物理量変換モジュールの変換ルールを書き換えるだけで上記特性変更に対応することができる。これにより、車両のモデルチェンジや車種展開時等におけるソフトウェア開発工数を大幅に低減することができる。

また、ここに開示された技術では、車両制御システムを対象として、車両の所定のゾーン毎に配置された複数のゾーンＥＣＵと、当該複数のゾーンＥＣＵを統括する中央演算装置とを備え、１または複数の前記ゾーンＥＣＵは、上記態様の車載機器制御装置を備える。

車両に複数のゾーンＥＣＵを設けて、それを中央演算装置で管理する場合には、ゾーンＥＣＵに対して車載機器が接続される。このとき、車載機器の変更が行われる場合があるが、本態様の構成を用いることで、中央演算装置及びゾーンＥＣＵの双方において、ソフトウェア開発工数が大幅に低減できる。

以上説明したように、ここに開示された技術によると、車種展開時のソフトウェア開発の工数を大幅に低減することができる。

車両制御システムの構成例を示す図である。実施形態の車載機器制御装置の構成例を示す図である。実施形態の車載機器制御装置の構成例を示す図である。物理量変換ルールについて説明するための図である。比較例の車載機器制御装置の構成例を示す図である。比較例の車載機器制御装置の構成例を示す図である。

以下、例示的な実施形態について、図面を参照しながら詳細に説明する。

(車両制御システム)
図１は車両制御システムの構成例を示す図である。図１の車両制御システムは、車両１に搭載されており、車両１の所定のゾーン毎に配置された複数のゾーンＥＣＵ４０と、複数のゾーンＥＣＵ４０を統括する中央演算装置１０とを備える。本実施形態の車両制御システムでは、車両１を６つのゾーンに分け、各ゾーンにゾーンＥＣＵ４０が設けられている例を示している。ゾーンＥＣＵ４０は、車載機器を接続することができるように構成されている。また、ゾーンＥＣＵ４０は、車内のネットワークを介して伝送される情報を中継するネットワークハブ装置としての機能を有する。なお、説明の便宜上、車両１の左前側の左フロントゾーンに配置されたゾーンＥＣＵ４０を第１ゾーンＥＣＵ４１ということがある。

〈車載機器〉
車載機器２０は、センサデバイス２００及び信号受信デバイスを含む入力機器と、アクチュエータ３００とを含む。

《センサデバイス、信号受信デバイス》
センサデバイス２００は、例えば、（１）車両１のボディ等に設けられかつ車外環境を撮影する複数のカメラ２０１、（２）車両１のボディ等に設けられかつ車外の物標等を検知する複数のレーダ２０２、（３）全地球測位システム（Global Positioning System：ＧＰＳ）を利用して、車両１の位置（車両位置情報）を検出する位置センサ（図示省略）、（４）車速センサ、加速度センサ、ヨーレートセンサ等の車両の挙動を検出するセンサ類の出力から構成され車両１の状態を取得する車両状態センサ（図示省略）、（５）車内カメラ２０３等により構成され、車両１の乗員の状態を取得する乗員状態センサ、（６）運転者の運転操作を検出する運転操作センサ２０６、（７）キーレス装置を作動させるためのセンサ２１１（以下、キーレスセンサ２１１という）、（８）車室内の温度を測定する室温センサ２２０を含む。運転操作センサ２０６は、例えば、アクセル開度センサ、操舵角センサ、ブレーキ油圧センサなどを含む。また、センサデバイス２００には、乗員による操作を検出するスイッチを含む。スイッチは、例えば、乗員が電動パワーウィンドウを動作させるためのＰＷスイッチ２１２、ウォッシャーレベルスイッチ、フードスイッチ等を含む。

信号受信デバイスは、例えば、外部のネットワークや、他車両からの信号を受信する受信装置が含まれる。

《アクチュエータ》
アクチュエータ３００は、駆動系のアクチュエータ、操舵系のアクチュエータ、制動系のアクチュエータなどを含む。駆動系のアクチュエータの例としては、エンジン、トランスミッション、モータが挙げられる。制動系のアクチュエータの例としては、ブレーキが挙げられる。操舵系のアクチュエータの例としては、ステアリングが挙げられる。また、アクチュエータ３００は、例えば、サイドドアをロックするためのドアロック装置３０１、電動パワーウィンドウ装置３０２、前照灯ＦＬの点灯を制御する点灯制御装置３１０、エアバック装置３１１、音響装置３１２、エアコン装置３２０等を含む。

〔車載機器制御装置〕
車載機器制御装置１００は、１または複数のゾーンＥＣＵ４０に搭載される。すなわち、車載機器制御装置１００は、すべてのゾーンＥＣＵ４０に搭載されてもよいし、ゾーンＥＣＵ４０の一部に搭載されてもよい。また、車載機器制御装置１００が、（１）中央演算装置１０に搭載されてもよいし、（２）ゾーンＥＣＵ４０の下位に接続された、各アクチュエータ専用に設けられた専用ＥＣＵ（図示省略）に搭載されてもよい。専用ＥＣＵは、例えば、エンジンを駆動するためのエンジン駆動用ＥＣＵが例示される。中央演算装置１０及び各ＥＣＵは、単一のＩＣ（Integrated Circuit）により構成されてもよいし、複数のＩＣにより構成されてもよい。

図２Ａは、車載機器制御装置１００の構成例を示すブロック図である。車載機器制御装置１００は、例えば、ＣＰＵ１５０（プロセッサ）とメモリ１６０とにより構成される。

〈ＣＰＵ〉
ＣＰＵ１５０は、メモリ１６０からプログラム１６２を読み出して実行することにより各種の処理をおこなう。具体的には、例えば、センサデバイス２００で検出された検出データを読み取ったり、諸機能を実現するために各種の演算処理を行ったり、アクチュエータ３００を制御するための制御信号を生成して出力する。ＣＰＵ１５０は、制御部の一例である。なお、ＣＰＵ１５０の具体的な態様は、特に限定されない。例えば、マイクロコンピュータ（いわゆるマイコン）で実現されていてもよいし、ＳｏＣ（System-on-Chip）で実現されてもよい。

《ハードウェア》
ＣＰＵ１５０は、ハードウェアの構成として、メモリ１６０に格納されたプログラムにしたがって各種の演算処理を実行する演算部と、ペリフェラル機能ユニット１８０とを備える。ここでいうペリフェラルとは、中央演算装置１０及び／またはゾーンＥＣＵ４０と組み合わせて利用される車載機器２０を指すものとする。

ペリフェラル機能ユニット１８０は、ペリフェラル、すなわち、車載機器２０を機能させるための１または複数のペリフェラル機能部１８１を備える。図２Ａに示すように、ペリフェラル機能部１８１には、例えば、アナログデジタルコンバータ１８１ａ（以下、ＡＤＣ１８１ａという）、デジタル入力部１８１ｂ、デジタル出力部１８１ｃ及びＰＷＭ制御部１８１ｄが含まれる。なお、ペリフェラル機能部１８１として、図２Ａの構成１８１ａ〜１８１ｄの一部が搭載されてもよいし、他の構成が含まれていてもよい。なお、以下において、ＡＤＣ１８１ａ、デジタル入力部１８１ｂ、デジタル出力部１８１ｃ及びＰＷＭ制御部１８１ｄの各ペリフェラル機能を特に区別しないで説明する場合、単にペリフェラル機能部１８１と記載する。

ペリフェラル機能部１８１は、それぞれ、複数のチャネルを有する。各チャネルには、車載機器２０の入出力部（例えば、Ｉ／Ｏ接続用のコネクタ）が接続できるように構成されている。図２Ａでは、上記チャネルとして、ＡＤＣ１８１ａに入力用のチャネルＣＨａ１，ＣＨａ２が、デジタル入力部１８１ｂに入力用のチャネルＣＨｂ１，ＣＨｂ２が、デジタル出力部１８１ｃに出力用のチャネルＣＨｃ１，ＣＨｃ２が、ＰＷＭ制御部１８１ｄに出力用のチャネルＣＨｃ１，ＣＨｃ２が、それぞれ設けられている例を示している。なお、各ペリフェラル機能部１８１のチャネル数は、２つに限定されず、３つ以上であってもよい。また、単一のペリフェラル機能部１８１に、入力用及び出力用の両方のチャネルが設けられていてもよい。

《ソフトウェア》
ＣＰＵ１５０は、ソフトウェアの構成として、最上位のアプリケーション層１２０と、アプリケーション層の下位にあるミドルウェア層１３０と、ミドルウェア層１３０の下位にある基本ソフトウェア層１４０とを有する。ＣＰＵ１５０は、いわゆるＡＵＴＯＳＡＲに準拠したソフトウェア構造を採用してもよい。この場合、アプリケーション層１２０は、ＡＵＴＯＳＡＲのアプリケーション層に対応し、例えば、１または複数のＳＷＣ（Software Component）モジュールで構成される。基本ソフトウェア層１４０及びミドルウェア層１３０は、ＡＵＴＯＳＡＲのＢＳＷ（Basic Software）に相当し、基本ソフトウェア層１４０はＡＵＴＯＳＡＲのＭＣＡＬ（Microcontroller Abstraction Layer）に相当する。なお、ミドルウェア層１３０をＣｏｍｐｌｅｘＤｒｉｖｅｒとして実装してもよい。

アプリケーション層１２０は、車載機器２０に対する諸機能が実装されたアプリケーション１２１が実装されている。アプリケーション１２１には、周知構成のものが採用できる。アプリケーション１２１の具体例について、後ほど説明する。

基本ソフトウェア層１４０は、アプリケーション１２１から受け取ったコマンドをハードウェア用のコマンドに変換するデバイスドライバユニット１４１が実装される。デバイスドライバユニット１４１には、ペリフェラル機能ユニット１８０に含まれるペリフェラル機能部１８１毎のデバイスドライバが実装される。前述のとおり、図２Ａの例では、ペリフェラル機能部１８１として、ＡＤＣ１８１ａ、デジタル入力部１８１ｂ、デジタル出力部１８１ｃ及びＰＷＭ制御部１８１ｄが含まれる。そこで、デバイスドライバユニット１４１には、ＡＤＣ１８１ａのためのデバイスドライバであるＡＤＣドライバ１４１ａと、デジタル入力部１８１ｂ及びデジタル出力部１８１ｃのためのデバイスドライバであるＤＩＯドライバ１４１ｂと、及びＰＷＭ制御部１８１ｄのためのデバイスドライバであるＰＷＭドライバ１４１ｄとが含まれる。すなわち、ＡＤＣドライバ１４１ａはＡＤＣ１８１ａに接続され、ＤＩＯドライバ１４１ｂはデジタル入力部１８１ｂ及びデジタル出力部１８１ｃに接続され、ＰＷＭドライバ１４１ｄはＰＷＭ制御部１８１ｄに接続される。

デバイスドライバは、ハードウェア依存性のあるソフトウェアである。一般的に、基本ソフトウェア層１４０には、ハードウェアに依存しないソフトウェア（例えば、オペレーティングシステム等）も実装されるが、本願発明との関連性が低いので、本実施形態では、図示及び説明を省略している。

ミドルウェア層１３０は、マッピングモジュール１３３と、物理量変換モジュール１３５とが実装されている。マッピングモジュール１３３は、アプリケーション１２１とデータをやり取りするための１または複数の第１通信パケット１３１と、デバイスドライバとデータをやり取りするための１または複数の第２通信パケット１３２とを有する。

図２Ａの例では、第１通信パケット１３１として、ＩＯ＿１，ＩＯ＿２，…ＩＯ＿Ｘ（Ｘは自然数）が実装されている。また、第２通信パケット１３２として、（１）ＡＤＣドライバ１４１ａとデータをやり取りするためのＡＤＣ＿１，ＡＤＣ＿２，…ＡＤＣ＿Ｌ（Ｌは自然数）、（２）ＤＩＯドライバ１４１ｂとデータをやり取りするためのＤＩ＿１，ＤＩ＿２，…ＤＩ＿Ｍ（Ｍは自然数）及びＤＯ＿１，ＤＯ＿２，…ＤＯ＿Ｎ（Ｎは自然数）、（３）ＰＷＭドライバ１４１ｄとデータをやり取りするためのＰＷＭ＿１，ＰＷＭ＿２，…ＰＷＮ＿Ｑ（Ｑは自然数）が実装されている。なお、第１通信パケット１３１または第２通信パケット１３２のいずれか一方が単一のパケットであってもよい。

マッピングモジュール１３３は、メモリ１６０に格納されたマッピングテーブル１６６に基づいて、アプリケーション層１２０とデバイスドライバとの通信経路を生成する。マッピングテーブル１６６では、第１通信パケット１３１と第２通信パケット１３２との接続関係が規定されている。より具体的には、例えば、複数の第１通信パケット１３１と複数の第２通信パケット１３２がある場合に、それぞれの接続対象となる通信パケットが規定されている。図２Ａのケースでは、通信パケットＩＯ＿１の接続対象が通信パケットＡＤＣ＿１であり、通信パケットＩＯ＿２の接続対象が通信パケットＤＩ＿２であり、通信パケットＩＯ＿２の接続対象が通信パケットＤＯ＿１であり、通信パケットＩＯ＿Ｘの接続対象が通信パケットＰＷＭ＿２であることが規定されている。

物理量変換モジュール１３５は、マッピングモジュール１３３で生成された通信経路を伝送されるデータに含まれる物理量データをメモリ１６０に格納された物理量変換ルール１６７に従って変換する。図２Ａの例では、物理量変換モジュール１３５は、通信パケットＩＯ＿１と通信パケットＡＤＣ＿１との間で伝送されるデータ、及び、通信パケットＩＯ＿３と通信パケットＤＯ＿１との間で伝送されるデータについて、物理量を変換する。また、通信パケットＩＯ＿２と通信パケットＤＩ＿２との間で伝送されるデータ、及び、通信パケットＩＯ＿Ｘと通信パケットＰＷＭ＿２との間で伝送されるデータについては、物理量の変換を行わないようになっている。このように、物理量変換モジュール１３５は、第１通信パケット１３１と第２通信パケット１３２との間の一部の通信経路に配置されてもよいし、第１通信パケット１３１と第２通信パケット１３２との間のすべての通信経路が物理量変換モジュール１３５を通過するようにしてもよい。

物理量変換モジュール１３５の適用方法は、特に限定されないが、例えば、図２Ａに示すように、マッピングテーブル１６６において、第１通信パケット１３１が物理量変換モジュール１３５を介して第２通信パケット１３２と接続されるように接続経路が生成される。そして、物理量変換モジュール１３５において、第１通信パケット１３１と第２通信パケット１３２との間の通信データが通過する際にその通信データに含まれる物理量データに対して物理量変換ルール１６７に従った演算が適用される。具体的な接続例及び動作例については、後ほど説明する。なお、上記の通信データには、物理量データの他に、パケット長やパケットの種別を示す形式データや、各種のフラグデータ等が含まれ得る。

図２Ａでは、具体的に図示していないが、上記の他に以下の接続関係がある。通信パケットＡＤＣ＿１はＡＤＣ１８１ａのチャネルＣＨａ１に、通信パケットＡＤＣ＿２はＡＤＣ１８１ａのチャネルＣＨａ２にそれぞれ接続される。通信パケットＤＩ＿１はデジタル入力部１８１ｂのチャネルＣＨｂ１に、通信パケットＤＩ＿２はデジタル入力部１８１ｂのチャネルＣＨｂ２にそれぞれ接続される。通信パケットＤＯ＿１はデジタル出力部１８１ｃのチャネルＣＨｃ１に、通信パケットＤＯ＿２はデジタル出力部１８１ｃのチャネルＣＨｃ２にそれぞれ接続される。通信パケットＰＷＭ＿１はＰＷＭ制御部１８１ｄのチャネルＣＨｄ１に、通信パケットＰＷＭ＿２はＰＷＭ制御部１８１ｄのチャネルＣＨｄ２にそれぞれ接続される。

なお、ミドルウェア層１３０において、アプリケーション層１２０とマッピングモジュール１３３との間に、ランタイム環境（ＲＴＥ）が実装されていてもよい。ランタイム環境は、例えば、アプリケーション１２１と、基本ソフトウェア層１４０に実装されたソフトウェアとを抽象化して接続する。この場合、第１通信パケット１３１は、ランタイム環境とマッピングモジュール１３３との間のデータのやり取りをするために用いられる。

〈メモリ〉
メモリ１６０は、記憶領域として、ＣＰＵ１５０を動作させるためのプログラム１６２が記憶されたコード領域１６１と、ＣＰＵ１５０での処理結果、マッピングテーブル１６６及び物理量変換ルール１６７等のデータを記憶する書き換え可能なデータ領域１６５とを備える。コード領域には、例えば、車載機器制御装置１００の設計段階において、あらかじめ作成されたプログラム１６２がコンパイルされて実装されている。前述のとおり、マッピングテーブル１６６には、第１通信パケット１３１と第２通信パケット１３２との接続関係を特定するためのデータが格納される。また、物理量変換ルール１６７には、ミドルウェア層１３０に生成された通信経路を伝送されるデータに含まれる物理量データを変換する変換ルール（例えば、演算式）が格納される。メモリ１６０は記憶部の一例である。

〔車載機器制御装置の動作例〕
次に、図２Ａ及び図２Ｂを用いて、車載機器制御装置１００の動作の一例を説明する。ここでは、第１ゾーンＥＣＵ４１に車載機器制御装置１００が実装されているものとして説明する。第１ゾーンＥＣＵ４１には、主に車両１の左フロントゾーンに配置されたセンサデバイス２００及びアクチュエータ３００が接続される。図１に示すように、第１ゾーンＥＣＵ４１には、例えば、車外左側方を撮像するカメラ２０１、キーレスセンサ２１１、ＰＷスイッチ２１２、ドアロック装置３０１、電動パワーウィンドウ装置３０２、室温センサ２２０及びエアコン装置３２０が接続されている。

図２Ａ及び図２Ｂは、各車載機器２０と各ペリフェラル機能部１８１との接続状態の一例を示している。

図２Ａのケースでは、第１室温センサ２２１がＡＤＣ１８１ａのチャネルＣＨａ１、キーレスセンサ２１１がデジタル入力部１８１ｂのチャネルＣＨｂ１、第１エアコン装置３２１がデジタル出力部１８１ｃのチャネルＣＨｃ１、ドアロック装置３０１がＰＷＭ制御部１８１ｄのチャネルＣＨｄ１にそれぞれ接続されているものとする。図２Ａにおいて、カメラ２０１、ＰＷスイッチ２１２及び電動パワーウィンドウ装置３０２の図示を省略している。図２Ｂについても同様である。

そして、図２Ｂのケースでは、ＡＤＣ１８１ａのチャネルＣＨａ１に第２室温センサ２２２が接続され、デジタル出力部１８１ｃのチャネルＣＨｃ２に第２エアコン装置３２２が接続されている点で図２Ａと異なっている。このような車載機器２０の変更は、例えば、車両のモデルチェンジや設計変更、サプライヤー変更等が発生する場合、互いにグレードや車体の大きさ等が異なる車種に対して共通のプログラムを使用する場合等に発生し得る。

図２Ａ及び図２Ｂのケースに共通して、コード領域１６１のプログラム１６２として、例えば、室温センサ２２０の測定温度の読み出し処理、及び、キーレスセンサ２１１からの入力信号の読み出し処理についてプログラミングされている。また、プログラム１６２として、室温センサ２２０の測定温度に応じたエアコン装置３２０の送風温度及び風量調整処理、キーレスセンサ２１１からの入力信号に応じたドアロック装置３０１の施錠／開錠処理についてプログラミングされている。

《動作例１：ドアロック》
図２Ａ及び図２Ｂにおいて、アプリケーション１２１は、キーレスセンサ２１１からの入力信号の読み出し処理についての命令をパケット化し、マッピングモジュール１３３に通信パケットＩＯ＿２として送信する。前述のとおり、マッピングモジュール１３３において、通信パケットＩＯ＿２は、通信パケットＤＩ＿２に接続されている。これにより、アプリケーション１２１の命令に基づいてＤＩＯドライバ１４１ｂが動作し、デジタル入力部１８１ｂで取得されたキーレスセンサ２１１の受信信号がミドルウェア層１３０の通信パケットＤＩ＿２に送信される。通信パケットＤＩ＿２は、通信パケットＩＯ＿２に送信される。

そして、アプリケーション１２１は、通信パケットＩＯ＿２として、キーレスセンサ２１１からの入力信号を受信すると、その入力信号に基づいてドアロック装置３０１の施錠／開錠処理についての命令をパケット化し、マッピングモジュール１３３に通信パケットＩＯ＿Ｘとして送信する。前述のとおり、マッピングモジュール１３３において、通信パケットＩＯ＿Ｘは、通信パケットＰＷＭ＿２に接続されている。これにより、アプリケーション１２１の命令に基づいてＰＷＭドライバ１４１ｄが動作し、ＰＷＭ制御部１８１ｄを介してドアロック装置３０１の施錠または開錠が実行される。

《動作例２：エアコン装置》
図２Ａにおいて、アプリケーション１２１は、室温センサ２２０の操作情報の読み出し処理についての命令をパケット化し、マッピングモジュール１３３に通信パケットＩＯ＿１として送信する。通信パケットＩＯ＿１は、マッピングモジュール１３３において、通信パケットＡＤＣ＿１に接続されている。これにより、アプリケーション１２１の命令に基づいてＡＤＣドライバ１４１ａが動作し、ＡＤＣ１８１ａで取得された第１室温センサ２２１の測定温度データがミドルウェア層１３０の通信パケットＡＤＣ＿１に送信される。通信パケットＡＤＣ＿１は、物理量変換モジュール１３５に送信される。

物理量変換モジュール１３５では、物理量変換ルール１６７に基づく変換処理が実行される。例えば、メモリ１６０には、物理量変換ルール１６７として、第１室温センサ２２１について、図３上段のグラフに示す演算式が格納されているとする。そうすると、物理量変換モジュール１３５では、室温センサ２２０での測定温度Ｄ１に対して「（Ｄ１×２）−１」の変換演算が実行される。変換演算の結果は、通信パケットＩＯ＿２を介して、アプリケーション１２１に送信される。測定温度Ｄ１は物理量の一例であり、上記演算式は所定の一次関数の一例である。

アプリケーション１２１は、通信パケットＩＯ＿２として、物理量変換モジュール１３５から変換演算済の測定温度データを受信すると、その測定温度データに基づいてエアコン装置３２０の送風温度及び送風量についての命令をパケット化し、マッピングモジュール１３３に通信パケットＩＯ＿３として送信する。前述のとおり、通信パケットＩＯ＿３は、マッピングモジュール１３３において、物理量変換モジュール１３５を介して通信パケットＤＯ＿１に接続されている。送風温度及び送風量は、物理量の一例である。ここでは、送風温度及び送風量をまとめて「送風制御量Ｄ２」と呼ぶものとする。すなわち、送風制御量Ｄ２は、物理量の一例である。

物理量変換モジュール１３５では、物理量変換ルール１６７に基づく変換処理が実行される。例えば、メモリ１６０には、物理量変換ルール１６７として、第１エアコン装置３２１の送風制御量Ｄ２について、「Ｄ２／２」の演算式が格納されているとする。そうすると、物理量変換モジュール１３５では、アプリケーション１２１から出力された送風制御量Ｄ２を１／２にする変換演算を実行する。変換演算の結果は、通信パケットＤＯ＿１を介してＤＩＯドライバ１４１ｂに入力される。これにより、アプリケーション１２１の命令に基づいてＤＩＯドライバ１４１ｂが動作し、デジタル出力部１８１ｃを介して第１エアコン装置３２１の送風温度及び送風量の設定が実行される。上記の演算式は、所定の一次関数の一例である。

ここで、図２Ａから図２Ｂへの接続変更があったとする。このような場合に、本実施形態では、コード領域１６１のプログラム１６２は変更せずに、データ領域１６５のマッピングテーブル１６６及び／または物理量変換ルール１６７の書き換えが行われる。

具体的に、図２Ｂの例では、まず、マッピングテーブル１６６において、通信パケットＩＯ＿３の接続先が通信パケットＤＯ＿２に変更される。これにより、マッピングモジュール１３３において、通信パケットＩＯ＿３の接続先が通信パケットＤＯ＿２に変更される。また、物理量変換ルール１６７において、室温センサ２２０に適用される変換ルールＣＡＬ１について、第２室温センサ２２２に応じたルール変更が実施される。同様に、エアコン装置３２０に適用される変換ルールＣＡＬ２について、第２エアコン装置３２２に応じたルール変更が実施される。

設定が終了すると、図２Ｂでは、以下の動作が行われるようになる。

具体的に、アプリケーション１２１は、図２Ａの場合と同様に、室温センサ２２０の操作情報の読み出し処理についての命令をパケット化し、マッピングモジュール１３３に通信パケットＩＯ＿１として送信する。通信パケットＩＯ＿１は、通信パケットＡＤＣ＿１に伝送される。そうすると、アプリケーション１２１の命令に基づいてＡＤＣドライバ１４１ａが動作し、ＡＤＣ１８１ａで取得された第２室温センサ２２２の測定温度データがミドルウェア層１３０の通信パケットＡＤＣ＿１に送信される。通信パケットＡＤＣ＿１は、物理量変換モジュール１３５に送信される。

物理量変換モジュール１３５では、物理量変換ルール１６７として、第２室温センサ２２２ついて、図３下段のグラフに示す演算式が格納されているとする。そうすると、物理量変換モジュール１３５では、第２室温センサ２２２での測定結果Ｄ２に対して、「（Ｄ１／２）＋２」の変換演算が実行される。変換演算の結果は、通信パケットＩＯ＿２を介して、アプリケーション１２１に送信される。

ここで、物理量変換ルール１６７は、アプリケーション１２１が受信するデータが同じ尺度のデータとなるように変換するためのものである。より具体的には、例えば、図３のグラフのように、第１室温センサ２２１と第２室温センサ２２２とにおいて、その傾きや切片が互いに異なる場合に、それぞれの特性に応じた変換ルールを適用することで、測定値を基準となる尺度にあわせてアプリケーション１２１に提供することができるようになる。換言すると、物理量変換ルール１６７により、互いに感度や特性等の異なるセンサデバイス２００やアクチュエータ３００についてのその感度や特性等の違いを吸収することができる。なお、物理量変換ルール１６７は、一次関数に限定されず、高次の関数や三角関数等の他の関数を用いたルールを作成してもよい。

アプリケーション１２１は、通信パケットＩＯ＿２として、物理量変換モジュール１３５から変換演算がされた測定温度データを受信すると、その測定温度データに基づいてエアコン装置３２０の送風制御量Ｄ２についての命令をパケット化し、マッピングモジュール１３３に通信パケットＩＯ＿３として送信する。

物理量変換モジュール１３５では、物理量変換ルール１６７に基づく変換処理が実行される。例えば、メモリ１６０には、物理量変換ルール１６７として、第２エアコン装置３２２の送風制御量Ｄ２について、「Ｄ２×２＋２」の演算式が格納されているとする。そうすると、物理量変換モジュール１３５では、アプリケーション１２１から出力された送風制御量Ｄ２に対して「Ｄ２×２＋２」の変換演算が実行される。変換演算の結果は、通信パケットＤＯ＿１を介してＤＩＯドライバ１４１ｂに入力される。これにより、アプリケーション１２１の命令に基づいてＤＩＯドライバ１４１ｂが動作し、デジタル出力部１８１ｃを介して第２エアコン装置３２２の送風温度及び送風量の設定が実行される。

〔比較例〕
図４Ａ及び図４Ｂに比較例を示す。図４Ａ及び図４Ｂでは、ミドルウェア層５３０として単一の通信パケットが実装されているものとする。また、それに応じてプログラム５６２の構成が異なっている。それ以外の構成は、図２Ａ及び図２Ｂと共通であるものとする。図２（２Ａ，２Ｂ）と図４（４Ａ，４Ｂ）で共通する構成については、下２桁の数字または下２桁及びその後ろの符号を共通にしている。例えば、車載機器制御装置５００は、車載機器制御装置１００に相当する。

具体的に、図４Ａのプログラム５６２では、コード領域５６１において、ＣＰＵ５５０を動作させるため処理内容が実装される。さらに、プログラム５６２には、各処理内容を送信するミドルウェア層１３０での通信パケットについて、ペリフェラル機能部１８１での接続先チャネル及び必要に応じて物理量に対する演算があわせて設定されることになる。このような構成にすることで、上記実施形態と同様の動作を実現している。

そして、図４Ａの構成から図４Ｂの構成への変更があった場合、比較例では、コード領域５６１のプログラム５６２を変更する必要がある。具体的に、図４Ｂのプログラム５６２において下線を引いた太字部分のように、測定温度の演算式と制御量の演算式を変更する必要がある。

以上のように、本実施形態の車載機器制御装置１００において、ＣＰＵ１５０は、ソフトウェアの構成として、アプリケーション１２１が実装されたアプリケーション層１２０と、各種のデバイスドライバが実装されたデバイスドライバユニット１４１と、アプリケーション１２１とデバイスドライバとの間の通信経路を生成するミドルウェア層１３０とを有する。そして、ミドルウェア層１３０は、通信経路を伝送されるデータに含まれる物理量データを物理量変換ルール１６７に従って変換する物理量変換モジュール１３５を備える。

このような構成にすることにより、ペリフェラル機能部１８１に接続されるセンサデバイス２００やアクチュエータ３００等の車載機器２０の特性が変わった場合においても、コード領域１６１のプログラムを変更することなく、物理量変換ルール１６７を変更することで、車載機器２０の特性変更に対応できるようになる。コード領域１６１のプログラム１６２を変更した場合には、その変更が少ない場合においても、全コードについてコンパイルをし直してメモリ１６０への再書き込みが必要であるが、本実施形態の構成とすることでそのような必要がない。これにより、ソフトウェアの開発工数を大幅に低減することができる。

さらに、本実施形態では、ミドルウェア層１３０に、アプリケーション１２１とデータをやり取りする第１通信パケット１３１と、デバイスドライバとデータをやり取りする第２通信パケット１３２とが実装されている。そして、メモリ１６０に第１通信パケット１３１と第２通信パケット１３２との接続関係を特定する書き換え可能なマッピングテーブル１６６を格納して、ミドルウェア層１３０において、マッピングテーブル１６６に基づいて、アプリケーション層１２０とデバイスドライバユニット１４１との通信経路を生成するようにしている。

これにより、ペリフェラル機能ユニット１８０において車載機器２０の接続先が変更された場合においても、コード領域１６１のプログラムを変更することなく、マッピングテーブル１６６を変更することで、車載機器２０の接続先の変更に対応できるようになる。

ここに開示された技術は、前述の実施形態に限られるものではなく、請求の範囲の主旨を逸脱しない範囲で代用が可能である。また、前述の実施形態は単なる例示に過ぎず、本開示の範囲を限定的に解釈してはならない。本開示の範囲は請求の範囲によって定義され、請求の範囲の均等範囲に属する変形や変更は、全て本開示の範囲内のものである。

ここに開示された技術は、車載機器制御装置を設計するのに有用である。

１０中央演算装置
４０ゾーンＥＣＵ
１００車載機器制御装置
１２０アプリケーション層
１２１アプリケーション
１３０ミドルウェア層
１３５物理量変換モジュール
１４１ａＡＤＣドライバ（デバイスドライバ）
１４１ｂＤＩＯドライバ（デバイスドライバ）
１４１ｄＰＷＭドライバ（デバイスドライバ）
１５０ＣＰＵ（制御部）
１６０メモリ（記憶部）
１６７物理量変換ルール

Claims

車載機器を制御する制御部と記憶部とを備える車載機器制御装置であって、
前記制御部は、ソフトウェアの構成として、
前記車載機器についての諸機能を実現するためのアプリケーションが実装されたアプリケーション層と、
アプリケーションから受け取ったコマンドをハードウェア用のコマンドに変換するデバイスドライバと、
前記アプリケーションと前記デバイスドライバとの間の通信経路を生成するミドルウェア層と、
を有し、
前記ミドルウェア層は、前記通信経路を伝送されるデータに含まれる物理量データを所定の変換ルールに従って変換する物理量変換モジュールを備える、車載機器制御装置。
請求項１に記載の車載機器制御装置において、
前記所定の変換ルールは、所定の一次関数であり、
前記物理量変換モジュールは、前記所定の一次関数を用いて前記物理量データの変換演算をする、車載機器制御装置。
車両の所定のゾーン毎に配置された複数のゾーンＥＣＵと、当該複数のゾーンＥＣＵを統括する中央演算装置とを備え、
１または複数の前記ゾーンＥＣＵは、請求項１または２に記載の車載機器制御装置を備える、車両制御システム。