特表-14097442IP Force 特許公報掲載プロジェクト 2015.5.11 β版

▶ 三菱電機株式会社の特許一覧
<>
  • 再表WO2014097442-車載装置及びプログラム 図000003
  • 再表WO2014097442-車載装置及びプログラム 図000004
  • 再表WO2014097442-車載装置及びプログラム 図000005
  • 再表WO2014097442-車載装置及びプログラム 図000006
  • 再表WO2014097442-車載装置及びプログラム 図000007
  • 再表WO2014097442-車載装置及びプログラム 図000008
  • 再表WO2014097442-車載装置及びプログラム 図000009
  • 再表WO2014097442-車載装置及びプログラム 図000010
  • 再表WO2014097442-車載装置及びプログラム 図000011
  • 再表WO2014097442-車載装置及びプログラム 図000012
  • 再表WO2014097442-車載装置及びプログラム 図000013
  • 再表WO2014097442-車載装置及びプログラム 図000014
  • 再表WO2014097442-車載装置及びプログラム 図000015
  • 再表WO2014097442-車載装置及びプログラム 図000016
  • 再表WO2014097442-車載装置及びプログラム 図000017
  • 再表WO2014097442-車載装置及びプログラム 図000018
  • 再表WO2014097442-車載装置及びプログラム 図000019
  • 再表WO2014097442-車載装置及びプログラム 図000020
< >
(19)【発行国】日本国特許庁(JP)
【公報種別】再公表特許(A1)
(11)【国際公開番号】WO/0
(43)【国際公開日】2014年6月26日
【発行日】2017年1月12日
(54)【発明の名称】車載装置及びプログラム
(51)【国際特許分類】
   G06F 9/54 20060101AFI20161216BHJP
【FI】
   G06F9/46 480A
   G06F9/46 480F
【審査請求】有
【予備審査請求】未請求
【全頁数】33
【出願番号】特願2013-518885(P2013-518885)
(21)【国際出願番号】PCT/0/0
(22)【国際出願日】2012年12月20日
(11)【特許番号】特許第5372297号(P5372297)
(45)【特許公報発行日】2013年12月18日
(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IS,JP,KE,KG,KM,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LT,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US,UZ,VC
(71)【出願人】
【識別番号】000006013
【氏名又は名称】三菱電機株式会社
【住所又は居所】東京都千代田区丸の内二丁目7番3号
(74)【代理人】
【識別番号】100099461
【弁理士】
【氏名又は名称】溝井 章司
(74)【代理人】
【識別番号】100152881
【弁理士】
【氏名又は名称】山地 博人
(72)【発明者】
【氏名】伊藤 益夫
【住所又は居所】日本国東京都千代田区丸の内二丁目7番3号 三菱電機株式会社内
(72)【発明者】
【氏名】川上 武
【住所又は居所】日本国東京都千代田区丸の内二丁目7番3号 三菱電機株式会社内
(72)【発明者】
【氏名】片山 吉章
【住所又は居所】日本国東京都千代田区丸の内二丁目7番3号 三菱電機株式会社内
【テーマコード(参考)】
5B376
【Fターム(参考)】
5B376BC16
5B376GA08
(57)【要約】
ASL10は、既存APP SW−C(1)5を通信先とするAPPモジュール9と対応付けられている。バッファ部13は、既存APP SW−C(1)5へのデータと、既存APP SW−C(1)5からのデータとを蓄積する。通信処理部12は、バッファ部13に蓄積されている既存APP SW−C(1)5へのデータを既存APP SW−C(1)5に送信し、既存APP SW−C(1)5から送信されたデータを受信し、受信したデータをバッファ部13に格納する。API処理部14は、既存APP SW−C(1)5へのデータをAPPモジュール9から入力し、入力したデータをバッファ部13に格納し、既存APP SW−C(1)5からのデータをバッファ部13から入力し、入力したデータをAPPモジュール9に出力する。
【特許請求の範囲】
【請求項1】
複数のソフトウェアコンポーネントが実装されている車載装置であって、
前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントを通信先とするアプリケーションプログラムと対応付けられたデータ制御部を有し、
前記データ制御部は、
前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータと、前記通信先ソフトウェアコンポーネントからのデータとを蓄積するバッファ部と、
前記バッファ部に蓄積されている前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信し、受信したデータを前記バッファ部に格納する通信処理部と、
前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記通信先ソフトウェアコンポーネントからのデータを前記バッファ部から入力し、入力したデータを出力するデータ中継部とを有することを特徴とする車載装置。
【請求項2】
前記データ制御部は、
前記車載装置に前記アプリケーションプログラムが実装される前に、前記アプリケーションプログラムに対応付けられて前記車載装置に実装されており、
前記データ中継部は、
前記車載装置に前記アプリケーションプログラムが実装された後に、
前記アプリケーションプログラムから、前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記通信先ソフトウェアコンポーネントからのデータを前記アプリケーションプログラムに出力することを特徴とする請求項1に記載の車載装置。
【請求項3】
前記データ中継部は、
前記車載装置に前記アプリケーションプログラムが実装される前は、
前記アプリケーションプログラムのスタブモジュールから、前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記通信先ソフトウェアコンポーネントからのデータを前記スタブモジュールに出力することを特徴とする請求項2に記載の車載装置。
【請求項4】
前記車載装置は、
ミドルウェアが実装されており、
前記バッファ部は、
前記ミドルウェアへのデータと、前記ミドルウェアからのデータとを蓄積し、
前記通信処理部は、
前記バッファ部に蓄積されている前記ミドルウェアへのデータを前記ミドルウェアに送信し、前記ミドルウェアから送信されたデータを受信し、受信したデータを前記バッファ部に格納し、
前記データ中継部は、
前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記ミドルウェアからのデータを前記バッファ部から入力し、入力したデータを出力することを特徴とする請求項1〜3のいずれかに記載の車載装置。
【請求項5】
前記データ制御部は、
前記車載装置に前記アプリケーションプログラムが実装される前に、前記ミドルウェアに対応付けられて前記車載装置に実装されており、
前記データ中継部は、
前記車載装置に前記アプリケーションプログラムが実装された後に、
前記アプリケーションプログラムから、前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記ミドルウェアからのデータを前記アプリケーションプログラムに出力することを特徴とする請求項4に記載の車載装置。
【請求項6】
前記データ中継部は、
前記車載装置に前記アプリケーションプログラムが実装される前は、
前記アプリケーションプログラムのスタブモジュールから、前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記ミドルウェアからのデータを前記スタブモジュールに出力することを特徴とする請求項5に記載の車載装置。
【請求項7】
前記通信処理部は、
AUTOSAR(登録商標)(AUTomotive Open System ARchitecture)のVFB(Virtual Function Bus)に含まれる、前記通信先ソフトウェアコンポーネントと前記アプリケーションプログラムとの間の通信のために設定されている通信バスと接続されており、
前記通信バスを用いて、前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信することを特徴とする請求項1〜6のいずれかに記載の車載装置。
【請求項8】
前記通信処理部は、
AUTOSAR(登録商標)のVFBに含まれる、前記ミドルウェアと前記アプリケーションプログラムとの間の通信のために設定されている通信バスと接続されており、
前記通信バスを用いて、前記ミドルウェアへのデータを前記ミドルウェアに送信し、前記ミドルウェアから送信されたデータを受信することを特徴とする請求項4〜6のいずれかに記載の車載装置。
【請求項9】
前記データ制御部が前記アプリケーションプログラムのASL(Application Sub Layer)であり、
前記データ制御部と前記アプリケーションプログラムとによりソフトウェアコンポーネントが構成されていることを特徴とする請求項1〜8のいずれかに記載の車載装置。
【請求項10】
前記データ制御部は、
前記複数のソフトウェアコンポーネントの中から指定された前記通信先ソフトウェアコンポーネント以外のソフトウェアコンポーネントである指定ソフトウェアコンポーネントと対応付けられ、
前記バッファ部は、
前記指定ソフトウェアコンポーネントから前記通信先ソフトウェアコンポーネントへのデータと、前記通信先ソフトウェアコンポーネントから前記指定ソフトウェアコンポーネントへのデータとを蓄積し、
前記通信処理部は、
前記バッファ部に蓄積されている前記指定ソフトウェアコンポーネントからのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信された前記指定ソフトウェアコンポーネントへのデータを受信し、受信したデータを前記バッファ部に格納し、
前記データ中継部は、
前記指定ソフトウェアコンポーネントから、前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記指定ソフトウェアコンポーネントへのデータを前記バッファ部から入力し、入力したデータを前記指定ソフトウェアコンポーネントに出力することを特徴とする請求項1〜9のいずれかに記載の車載装置。
【請求項11】
前記車載装置は、更に、
前記指定ソフトウェアコンポーネントがデータの入出力に用いるAPI(Application Program Interface)と、前記データ中継部がデータの入出力に用いるAPIとが異なる場合に、
前記指定ソフトウェアコンポーネントが用いるAPIを用いて前記指定ソフトウェアコンポーネントからデータを入力し、入力したデータを、前記データ中継部が用いるAPIを用いて前記データ中継部に出力し、
前記データ中継部が用いるAPIを用いて前記データ中継部からデータを入力し、入力したデータを、前記指定ソフトウェアコンポーネントが用いるAPIを用いて前記指定ソフトウェアコンポーネントに出力するAPI変換部を有することを特徴とする請求項10に記載の車載装置。
【請求項12】
前記通信処理部は、
AUTOSAR(登録商標)のVFBに含まれる、通信対象のデータが定義されていない予備の通信バスを用いて、前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信することを特徴とする請求項1に記載の車載装置。
【請求項13】
複数のソフトウェアコンポーネントが実装されている車載装置で実行されるプログラムであって、
前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントを通信先とするアプリケーションプログラムと対応付けられ、
前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ領域に格納し、前記バッファ領域に格納されている前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、
前記通信先ソフトウェアコンポーネントから送信されたデータを受信し、受信したデータを前記バッファ領域に格納し、前記バッファ領域に格納されている前記通信先ソフトウェアコンポーネントからのデータを出力することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、自動車に搭載される車載装置に関する。
【背景技術】
【0002】
自動車分野でのソフトウェア標準プラットフォームであるAUTOSAR(登録商標)(AUTomotive Open System ARchitecture)は、アプリケーション層をソフトウェアコンポーネント化し、ソフトウェアコンポーネント(以下、SW−Cともいう)の下位層はVFB(Virtual Functional Bus)とするアーキテクチャでソフトウェアの階層化を図っている。
VFBは、SW−Cにハードウェアやネットワークを意識させることのない環境を提供している。
SW−Cのインタフェースが確定すれば、ソフトウェア開発者は、VFBがSW−Cの間をどのように接続するかを設計し、設計に従って、SW−Cを実装する。
このようにVFBによって、SW−Cの移植性を高めることができる。
【先行技術文献】
【非特許文献】
【0003】
【非特許文献1】AUTOSAR(商標登録) Technical Overview V2.0.1
【発明の概要】
【発明が解決しようとする課題】
【0004】
従来は、SW−Cの追加によるソフトウェア更新は、VFBの変更を伴うことから、SW−Cを追加する度にVFBを設計し直す必要があった。
このため、SW−Cの追加の度にVFBを再設計することにより、開発工数が増えてしまうという課題がある。
また、VFBの設計には設計ツールを必要とし、更に、設計ツールを用いて適正にVFBを設計するためにはVFBの設計方法及び設計ツールの操作方法を熟知している必要がある。
このため、開発環境から離れた後の車載装置に、プラグアンドプレイのようにSW−Cを追加するソフトウェア更新を行うことは困難である。
【0005】
本発明は、上記の事情に鑑みたものであり、VFBを変更することなく、アプリケーションプログラムを追加できるようにすることを主な目的とする。
【課題を解決するための手段】
【0006】
本発明に係る車載装置は、
複数のソフトウェアコンポーネントが実装されている車載装置であって、
前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントを通信先とするアプリケーションプログラムと対応付けられたデータ制御部を有し、
前記データ制御部は、
前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータと、前記通信先ソフトウェアコンポーネントからのデータとを蓄積するバッファ部と、
前記バッファ部に蓄積されている前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信し、受信したデータを前記バッファ部に格納する通信処理部と、
前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記通信先ソフトウェアコンポーネントからのデータを前記バッファ部から入力し、入力したデータを出力するデータ中継部とを有することを特徴とする。
【発明の効果】
【0007】
本発明によれば、通信先ソフトウェアコンポーネントと通信可能なデータ制御部がアプリケーションプログラムと通信先ソフトウェアコンポーネントとの間に介在することで、VFBを変更することなく、アプリケーションプログラムを追加することができる。
【図面の簡単な説明】
【0008】
図1】実施の形態1におけるECUの構成例を示す図である。
図2】実施の形態1における追加アプリケーションSW−C内のASLの構成を示す図である。
図3】実施の形態1における追加アプリケーションSW−Cの動作フローを示す図である。
図4】実施の形態1における通信バスの構成要素の例を示す図である。
図5】実施の形態1におけるデータの割り付け例を示す図である。
図6】実施の形態1における既存アプリケーションSW−Cの動作フローを示す図である。
図7】実施の形態1におけるアプリケーションモジュールの動作フローを示す図である。
図8】実施の形態2におけるECUの外部でのAPI変換の例を示す図である。
図9】実施の形態2におけるECUの内部でのAPI変換の例を示す図である。
図10】実施の形態3における通信バスのフレームフォーマットの例を示す図である。
図11】実施の形態3における既存アプリケーションSW−C及び追加アプリケーションSW−C内の構成例を示す図である。
図12】実施の形態3における追加アプリケーションSW−Cが送信するデータの例を示す図である。
図13】実施の形態3における既存アプリケーションSW−Cが送信するデータの例を示す図である。
図14】実施の形態1におけるアプリケーションモジュールの追加を行う際の構成例を示す図である。
図15】実施の形態1における追加アプリケーションSW−C内のASLでのデータの流れを示す図である。
図16】実施の形態1における追加アプリケーションSW−C内のASLでのデータの流れを示す図である。
図17】実施の形態1における追加アプリケーションSW−C内のASLでのデータの流れを示す図である。
図18】実施の形態1における追加アプリケーションSW−C内のASLでのデータの流れを示す図である。
【発明を実施するための形態】
【0009】
実施の形態1.
本実施の形態では、VFBを変更することなく、アプリケーションプログラムを追加することが可能なソフトウェアプラットフォームを説明する。
【0010】
図1は、本実施の形態に係るECU(Electronic Control Unit)100の構成例を示す。
ECU100は、車載装置の例に相当する。
図1では、ECU100の構成をハードウェア50とソフトウェア1に分けて示している。
【0011】
ハードウェア50には、例えば、CPU(Central Processing Unit)501、通信モジュール502、インタフェース503、センサ504、デバイス505が含まれる。
【0012】
CPU501には、RAM(Random Access Memory)506及びROM(Read Only Memory)507が含まれている。
ROM507には、ソフトウェア1を構成する各種プログラムが記憶されており、これらプログラムがRAM506にロードされ、順次CPU501に読み込まれ、CPU501がこれらプログラムを実行する。
本実施の形態及び以降の実施の形態に示す、ソフトウェア1内の各要素の処理内容は、CPU501によるプログラムの実行により実現される。
また、本実施の形態及び以降の実施の形態の説明において、「〜の判断」、「〜の判定」、「〜の抽出」、「〜の格納」、「〜の蓄積」、「〜の設定」、「〜の更新」、「〜の選択」、「〜の算出」、「〜の書込み」、「〜の読み出し」、「〜の生成」、「〜の入力」、「〜の出力」、「〜の受信」等として説明している処理の結果を示す情報やデータや信号値や変数値がRAM506にファイルとして記憶される。
【0013】
通信モジュール502は、ECU100が搭載されている車両内の機器及び車両の外部にある機器と通信を行う。
インタフェース503は、ECU100が搭載されている車両のユーザ(ドライバ及び同乗者)から各種要求を受付け、また、ユーザに各種情報を表示する。
センサ504及びデバイス505は、車両に関する様々な事象の検知を行う。
インタフェース503、センサ504及びデバイス505は、ECU100の内部に配置されていてもよいし、ECU100の外に配置されていてもよい。
インタフェース503、センサ504及びデバイス505がECU100の外に配置されている場合は、CPU501とインタフェース503、センサ504及びデバイス505がバスにより接続されている。
【0014】
なお、図1に示したハードウェア50の構成は、あくまでも一例を示すものであり、ECU100のハードウェア50は図1の構成に限らず、他の構成であってもよい。
【0015】
ソフトウェア1は、ドライバ2、ミドルウェア3、OS(Operating System)300、VFB4、既存アプリケーション SW−C(1)5、既存アプリケーション SW−C(2)6、追加アプリケーション SW−C7で構成する。
図1では、便宜的に、既存アプリケーション SW−C(1)5、既存アプリケーション SW−C(2)6、追加アプリケーション SW−C7で構成しているが、SW−Cの数や種類は任意でよい。
つまり、既存アプリケーション SW−C(1)5、既存アプリケーション SW−C(2)6、追加アプリケーション SW−C7以外のSW−CがECU100に実装されていてもよい。
なお、以下では、既存アプリケーション SW−C(1)5、既存アプリケーション SW−C(2)6、追加アプリケーション SW−C7は、それぞれ、既存APP SW−C(1)5、既存APP SW−C(2)6、追加APP SW−C7とも表記する。
【0016】
VFB4中の破線で示した通信バス11は、SW−CとSW−Cとの間、及びSW−Cとミドルウェアとの間を結ぶ仮想的な通信チャネルである。
VFB4は、SW−CとSW−Cとの間、及びSW−Cとミドルウェアとの間で授受されるデータの内容と実行タイミングを制御する。
【0017】
一般的に通信バス11はVFB設計ツール上で設計され、設計内容に従ってVFB設計ツールの自動コード生成機能によってプログラムコードが生成される。
つまり、通信バス11で構成されるVFB4の実態は、ドライバ2、ミドルウェア3、既存APP SW−C(1)5、既存APP SW−C(2)6、追加APP SW−C7と同様にプログラムコードである。
ECU100に実装するVFB4の実行可能ファイルを生成する時点では、ドライバ2、ミドルウェア3、VFB4、アプリケーションとして機能する既存APP SW−C(1)5、既存APP SW−C(2)6、追加APP SW−C7内のASL(Application Sub Layer)10の全てが必要となる。
なお、VFB4は上記のような性質を持つことから、一度既存APP SW−C(1)5のみでVFB4を設計しプログラムコードを生成した後、ECU100に既存APP SW−C(2)6を追加しようとすると、通信バス11の変更が必要になる。
このため、VFB4のプログラムコードの生成後に、ECU100に既存APP SW−C(2)6を追加しようとすると、VFB4の再設計及びプログラムコードの再生成が必要となる。
【0018】
追加APP SW−C7は、アプリケーションモジュール8、アプリケーションモジュール9、ASL10で構成される。
アプリケーションモジュール8、9は、既存APP SW−C(1)5及び既存APP SW−C(2)6を通信先とするアプリケーションプログラムである。
図1ではアプリケーションモジュールを便宜的に2つ図示しているが、アプリケーションモジュール数は任意でよい。
なお、アプリケーションモジュール8、9は、APPモジュール8、9とも表記する。
追加APP SW−C7の中でのAPPモジュール8、9とASL10の関係は、ASL10が下位層で、APPモジュール8、9が上位層となる。
つまり、ASL10は、既存APP SW−C(1)5及び既存APP SW−C(2)6を通信先とするAPPモジュール8、9と対応付けられている。
なお、既存APP SW−C(1)5及び既存APP SW−C(2)6は、通信先ソフトウェアコンポーネントの例に相当する。
また、ASL10は、データ制御部の例に相当する。
【0019】
図示を省略しているが、既存APP SW−C(1)5及び既存APP SW−C(2)6にも、それぞれ1つ以上のAPPモジュールが含まれている。
但し、既存APP SW−C(1)5及び既存APP SW−C(2)6には、ASL10に相当する下位層は含まれていない。
既存APP SW−C(1)5及び既存APP SW−C(2)6は、VFB4の設計段階で既に存在しているSW−Cであるため、「既存」と表記している。
一方、追加APP SW−C7については、VFB4の設計段階では、ASL10のみが存在していればよく、APPモジュール8、9は、VFB4の設計完了後に追加することができるため、「追加」と表記している。
【0020】
図2は、追加APP SW−C7内のASL10の詳細を示す。
ASL10は、図2に示すように、通信処理部12、バッファ部13及びAPI(Application Program Interface)処理部14から構成される。
以下では、主に、ASL10が、APPモジュール9と既存APP SW−C(1)5との間の通信を仲介し、APPモジュール9とミドルウェア3との間の通信を仲介する動作を説明する。
なお、ASL10がAPPモジュール8と既存APP SW−C(2)6との間の通信を仲介し、APPモジュール8とミドルウェア3との間の通信を仲介する動作では、以下の説明において、APPモジュール9をAPPモジュール8に読み替え、既存APP SW−C(1)5を既存APP SW−C(2)6に読み替える。
前述したように、APPモジュール8とAPPモジュール9は、ASL10をECU100に実装した後に、ECU100に実装することができる。
【0021】
バッファ部13は、既存APP SW−C(1)5からのデータ(SW−C(1)の公開データ)と、既存APP SW−C(1)5へのデータ(SW−C(1)の取得データ)とを蓄積する。
また、バッファ部13は、ミドルウェア3からのデータ(ミドルウェアの公開データ)と、ミドルウェア3へのデータ(ミドルウェアの取得データ)とを蓄積する。
なお、図2及び以下の説明では、便宜上、バッファ部13にSW−C(1)の公開データ、SW−C(1)の取得データ、ミドルウェアの公開データ及びミドルウェアの取得データが記憶されている例を示しているが、物理的には、RAM506内の記憶領域であるバッファ領域にSW−C(1)の公開データ、SW−C(1)の取得データ、ミドルウェアの公開データ及びミドルウェアの取得データが記憶される。
つまり、バッファ部13は、厳密には、SW−C(1)の公開データ、SW−C(1)の取得データ、ミドルウェアの公開データ及びミドルウェアの取得データのバッファ領域への書込み及びバッファ領域からの読み出しを管理している。
【0022】
通信処理部12は、VFB4を介して既存APP SW−C(1)5及びミドルウェア3と通信する。
VFB4には、APPモジュール9と既存APP SW−C(1)5との通信のための通信バス11が設定されており、通信処理部12は、この通信バス11と論理的に接続されている。
通信処理部12は、この通信バス11を用いて、既存APP SW−C(1)5から送信されたデータを受信し、受信したデータをバッファ部13に格納する。
また、通信処理部12は、バッファ部13から既存APP SW−C(1)5へのデータを入力し、入力したデータを、VFB4内の前記通信バス11を用いて、既存APP SW−C(1)5に送信する。
同様に、VFB4には、APPモジュール9とミドルウェア3との通信のための通信バス11が設定されており、通信処理部12は、この通信バス11と論理的に接続されている。
通信処理部12は、この通信バス11を用いて、ミドルウェア3から送信されたデータを受信し、受信したデータをバッファ部13に格納する。
また、通信処理部12は、バッファ部13からミドルウェア3へのデータを入力し、入力したデータを、VFB4内の前記通信バス11を用いて、ミドルウェア3に送信する。
【0023】
API処理部14は、APPモジュール9に対してバッファ部13へのアクセスを可能とする。
つまり、API処理部14は、既存APP SW−C(1)5へのデータをAPPモジュール9から入力し、入力したデータをバッファ部13に格納する。
また、API処理部14は、既存APP SW−C(1)5からのデータをバッファ部13から入力し、入力したデータをAPPモジュール9に出力する。
また、API処理部14は、ミドルウェア3へのデータをAPPモジュール9から入力し、入力したデータをバッファ部13に格納する。
また、API処理部14は、ミドルウェア3からのデータをバッファ部13から入力し、入力したデータをAPPモジュール9に出力する。
API処理部14は、データ中継部の例に相当する。
【0024】
以上の構成のASL10を例えばECU100の工場出荷段階でECU100に実装しておくことで、ECU100の工場出荷後にVFB4を再設計することなく、APPモジュール9をECU100に追加することができる。
つまり、工場出荷前の開発段階で、APPモジュール9と既存APP SW−C(1)5との間の通信のための通信バス11及びAPPモジュール9とミドルウェア3との間の通信のための通信バスをVFB4内に設定しておき、これら通信バス11と通信処理部12とを論理的に接続してASL10をECU100に実装する。
その後、工場出荷後にAPPモジュール9をECU100に実装する際には、通信処理部12がVFB4を介して既存APP SW−C(1)5及びミドルウェア3と通信可能になっているので、VFB4の再設計を伴わずに、APPモジュール9はASL10を用いて既存APP SW−C(1)5及びミドルウェア3と通信することができる。
【0025】
次に、図2図3図15図18を用いて、追加APP SW−C7の動作を説明する。
なお、図2のデータA1〜ANは既存APP SW−C(1)5が公開するデータ、データB1〜BNは既存APP SW−C(1)5が取得するデータ、データC1、C2はミドルウェア3が公開するデータ、データD1、D2はミドルウェア3が取得するデータである。
【0026】
まず、追加APP SW−C7は周期的に起動するものとする。
追加APP SW−C7は起動すると、ASL10の通信処理部12が、VFB4の通信バス11を用いて、既存APP SW−C(1)5の公開データ(データA1〜AN)を取得する(図3のステップ1)(図15)。
更に、ASL10の通信処理部12は、取得した既存APP SW−C(1)5の公開データ(データA1〜AN)を、バッファ部13に格納する(図3のステップ2)(図15)。
【0027】
同様に、ASL10の通信処理部12が、VFB4の通信バス11を用いて、ミドルウェア3の公開データ(データC1、C2)を取得する(図3のステップ3)(図15)。
更に、ASL10の通信処理部12は、取得した既存ミドルウェア3の公開データ(データC1、C2)を、バッファ部13に格納する(図3のステップ4)(図15)。
【0028】
次に、APPモジュール9が実行される(図3のステップ5)。
この時点でAPPモジュール9が実装されていなければ、ステップ5をスキップする。
なお、ミドルウェア3を介してAPPモジュール9に所定のハードウェアが割り当てられている場合は、APPモジュール9が実装されるまでは、APPモジュール9の代わりにスタブモジュールを割り当てておく。
同様に、APPモジュール9と連携して動作する既存APP SW−C(1)5に対して初期設定が必要な場合は、APPモジュール9が実装されるまでは、APPモジュール9の代わりにスタブモジュールを割り当てておく。
APPモジュール9の代わりにスタブモジュールが割り当てられている場合は、以下の説明においてAPPモジュール9をスタブモジュールと読み替える。
APPモジュール9は、既存APP SW−C(1)5の公開データ(データA1〜AN)を読み出す際、API処理部14が提供するAPIを使用する。
API処理部14は、APIの内容に従って、既存APP SW−C(1)5の公開データ(データA1〜AN)をバッファ部13より読み出してAPPモジュール9に提供する(図16)。
同様に、API処理部14は、ミドルウェア3の公開データ(データC1、C2)をバッファ部13より読み出してAPPモジュール9に提供する(図16)。
【0029】
また、APPモジュール9は、既存APP SW−C(1)5に対し、既存APP SW−C(1)5の取得データ(データB1〜BN)を送信する場合も、API処理部14が提供するAPIを使用する。
API処理部14は、APPモジュール9が呼び出したAPIの内容に従って、APPモジュール9が生成した既存APP SW−C(1)5の取得データ(データB1〜BN)をバッファ部13に書き込む(図3のステップ6)(図17)。
同様に、API処理部14は、APPモジュール9が生成したミドルウェア3の取得データ(データD1、D2)をバッファ部13に書き込む(図3のステップ6)(図17)。
【0030】
次に、ASL10の通信処理部12が、既存APP SW−C(1)5の取得データ(データB1〜BN)をバッファ部13から読み出し、VFB4の通信バス11を用いて、既存APP SW−C(1)5に送信する(図3のステップ7)(図18)。
【0031】
同様に、ASL10の通信処理部12がミドルウェア3の取得データ(データD1、D2)をバッファ部13から読み出し、VFB4の通信バス11を用いて、ミドルウェア3に送信する(図3のステップ8)(図18)。
【0032】
なお、図3に示す各ステップの実行順序を変更してもよい。
例えば、ステップ1→ステップ2→ステップ5→ステップ6→ステップ8→ステップ3→ステップ4→ステップ5→ステップ6→ステップ7という順序で各ステップを実行してもよい。
【0033】
ステップ1、3、7、8は、ステップ5の実行結果に関わらず、またバッファ部13の値に関わらず常に実行するものとする。
このような動作とすることで、VFB4の通信バス11に関連するステップ1、3、7、8の処理は、ステップ5の内容に依存しない構成となる。
【0034】
次に、VFB4内の追加APP SW−C7が利用する通信バス11の設計方法について説明する。
VFB4内の追加APP SW−C7が利用する通信バス11は、図3のステップ1、ステップ3、ステップ7、ステップ8の処理で利用される。
追加APP SW−C7と既存APP SWとの通信に着目すると、VFB4内の追加APP SW−C7が利用する通信バス11では、既存APP SW−C(1)5の公開データ及び取得データ、既存APP SW−C(2)6の公開データ及び取得データが送受信される。
既存APP SW−C(1)5の公開データ及び取得データ、既存APP SW−C(2)6の公開データ及び取得データの具体例を、図4に示す。
【0035】
既存APP SW−C(1)5には、例えば、ワイパを制御するアプリケーションモジュールが含まれており、既存APP SW−C(2)6には、例えば、車両のギアを制御するアプリケーションモジュールが含まれている。
既存APP SW−C(1)5は、公開データとしてワイパ動作状態情報を送信し、取得データとして雨状態情報を受信する。
既存APP SW−C(2)6は、公開データとしてギア情報を送信し、取得データとしてコーナーセンサー情報と温度情報を受信する。
そして、追加APP SW−C7の取得データはワイパ動作状態情報、ギア情報であり、追加APP SW−C7の公開データは雨状態情報、コーナーセンサー情報、温度情報である。
つまり、既存APP SW−C(1)5が追加APP SW−C7にワイパ動作状態情報を送信し、追加APP SW−C7が既存APP SW−C(1)5に雨状態情報を送信する。
また、既存APP SW−C(2)6が追加APP SW−C7にギア情報を送信し、追加APP SW−C7が既存APP SW−C(2)6にコーナーセンサー情報、温度情報を送信する。
これらの情報の組み合せを用いて、VFB4の設計者が、追加APP SW−C7が利用する通信バス11を設計する。
【0036】
既存APP SW−C(1)5の公開データと取得データ、既存APP SW−C(2)6の公開データと取得データ、及び追加するAPPモジュール8、9向けに割り当てられたミドルウェアの公開データと取得データから、VFB4の設計者が、VFB4の設計を行う。
従って、この時点で追加APP SW−C7に含ませるのは、ASL10のみである。
APPモジュール8、9はこの時点で並行して用意してもよいし、以後に、用意してもよい。
【0037】
次に、具体例として、ECU100にオプションとしてAPPモジュール9を追加する例を用いて、既存APP SW−C(1)5と追加APP SW−C7の動作を説明する。
【0038】
まず、APPモジュール9の追加方法について説明する。
APPモジュール9は、図14に示す外部端末装置41に保存しておく。
外部端末装置41は、例えばCAN(Controller Area Network)などの通信手段42を介してECU100に接続される。
図14のソフトウェア1及びハードウェア50は、一部の図示を省略しているが、図1に示すソフトウェア1及びハードウェア50である。
ソフトウェア1は、ECU100のハードウェア50内の通信モジュール502を介して通信手段42の先に接続される機器と通信可能である。
このような構成において、APPモジュール9は、外部端末装置41から追加APP SW−C7にアドオンされる。
【0039】
次に、APPモジュール9が追加APP SW−C7にアドオンされた後の動作について説明する。
以下では、既存APP SW−C(1)5がワイパ制御アプリケーションモジュールである例を用いて説明を進める。
既存APP SW−C(1)5は、Highモード(Hiモードともいう)、Lowモード、間欠モードのいずれかでワイパを動作させる。
Hiモードでは、既存APP SW−C(1)5は、ワイパを高速で連続して動作させる。
Lowモードでは、既存APP SW−C(1)5は、ワイパを低速で連続して動作させる。
間欠モードでは、既存APP SW−C(1)5は、ワイパを一定の間隔で間欠的に動作させる。
【0040】
ECU100は、オプションとして雨滴検知デバイスの装着を可能とする。
雨滴検知デバイスの装着の際には、同時に雨滴検知デバイス用制御アプリケーションをAPPモジュール9として追加する。
雨滴検知デバイス用制御アプリケーション(APPモジュール9)は、雨滴検知デバイスが検出したセンサ値に応じて雨状態を算出する。
雨滴検知デバイス用制御アプリケーション(APPモジュール9)は、ミドルウェア3から雨滴検知デバイスのセンサ値を取得して、雨状態を算出する。
既存APP SW−C(1)5は、雨滴検知デバイスが装着されると、雨滴検知デバイス用制御アプリケーション(APPモジュール9)が算出した雨状態に応じて間欠モードにおけるワイパの動作周期を変える。
【0041】
本例では、図5に示すように、データA1(図2のデータA1に相当)として、雨滴検知デバイス用制御アプリケーションへのリクエスト情報が、既存APP SW−C(1)5から追加APP SW−C7に送信される。
また、データB1(図2のデータB1に相当)として、雨滴検知デバイスの追加の有無情報、雨状態の有効/無効情報、雨滴検知デバイス用制御アプリケーションが提供するデータ(雨状態)が、追加APP SW−C7から既存APP SW−C(1)5に送信される。
また、データC1(図2のデータC1に相当)として、データの有効/無効情報、雨滴検知デバイスからのデータ(センサ値)が、ミドルウェア3から追加APP SW−C7に送信される。
また、データD1(図2のデータD1に相当)として、雨滴検知デバイスへのリクエスト情報が、追加APP SW−C7からミドルウェア3に送信される。
【0042】
既存APP SW−C(1)5の動作例を図6に示す。
【0043】
既存APP SW−C(1)5は、起動すると車両のユーザによりワイパスイッチ操作がされたかどうかをチェックする(ステップ20)。
ワイパスイッチ操作がされている場合(ステップ20でYES)は、既存APP SW−C(1)5は、ユーザにより選択されているモードが間欠モードかどうかをチェックする(ステップ21)。
ユーザにより選択されているモードが間欠モードでない場合(ステップ21でNO)は、既存APP SW−C(1)5は、ユーザにより選択されているモードがLowモードかどうかをチェックする(ステップ22)。
ユーザにより選択されているモードがLowモードであれば(ステップ22でYES)既存APP SW−C(1)5は、Lowモードでワイパを動作させる(ステップ23)。
ユーザにより選択されているモードがLowモードでなければ(ステップ22でNO)既存APP SW−C(1)5は、Hiモードでワイパを動作させる(ステップ24)。
【0044】
ユーザにより選択されているモードが間欠モードである場合(ステップ21でYES)は、既存APP SW−C(1)5は、データA1である雨滴検知デバイス用制御アプリケーションへのリクエスト情報に「雨状態情報の要求」を書き込む(ステップ25)。
次に、既存APP SW−C(1)5は、雨滴検知デバイス用制御アプリケーションへのリクエスト情報(データA1)を、VFB4内の該当する通信バス11を介して追加APP SW−C7に送信する。
【0045】
次に、既存APP SW−C(1)5は、データB1を受信し、データB1内の雨滴検知デバイスの追加の有無情報の読み出しを行う(ステップ26)。
雨滴検知デバイスの追加の有無情報は、追加APP SW−C7から送信された情報である。
ECU100に雨滴検知デバイスが装着されていない場合は、APPモジュール9も実装されていないため、APPモジュール9のスタブモジュールがデータB1内の雨滴検知デバイスの追加の有無情報に「無」を書き込む。
既存APP SW−C(1)5は、データB1内の雨滴検知デバイスの追加の有無情報を解析して雨滴検知デバイスがECU100に装着されているかどうかをチェックする(ステップ27)。
雨滴検知デバイスがECU100に装着されていない場合(ステップ27でNO)は、既存APP SW−C(1)5は、一定間隔でワイパを間欠的に動作させる(ステップ28)。
【0046】
雨滴検知デバイスがECU100に装着されている場合(ステップ27でYES)は、既存APP SW−C(1)5は、データB1内の雨状態の有効/無効情報が「有効」であるかどうかをチェックする(ステップ29)。
データB1内の雨状態の有効/無効情報が「有効」であれば(ステップ29でYES)、既存APP SW−C(1)5は、データB1内の雨滴検知デバイス用制御アプリケーションが提供するデータ(雨状態)から「雨状態」の値を読み出し(ステップ30)、「雨状態」の値に応じた間隔でワイパを間欠的に動作させる(ステップ31)。
例えば、「雨状態」の値を「強」、「中」、「弱」の3段階とし、既存APP SW−C(1)5は、ワイパの動作周期を各段階に合わせて調整する。
【0047】
次に、雨滴検知デバイス用制御アプリケーションであるAPPモジュール9を含む追加APP SW−C7の動作例を図7に示す。
【0048】
先ず、ASL10の通信処理部12が、既存APP SW−C(1)5からのデータA1をVFB4の通信バス11から受信する。
そして、バッファ部13及びAPI処理部14を経由して、データA1がAPPモジュール9に入力される。
APPモジュール9は、データA1の雨滴検知デバイス用制御アプリケーションへのリクエスト情報を解析して、雨滴検知デバイス用制御アプリケーションへのリクエスト情報(データA1)に「雨状態情報の要求」があるかどうかをチェックする(ステップ40)。
【0049】
雨滴検知デバイス用制御アプリケーションへのリクエスト情報に「雨状態情報の要求」がある場合(ステップ40でYES)は、APPモジュール9は、データD1である雨滴検知デバイスへのリクエスト情報に「デバイス起動要求」を書き込む(ステップ41)。
そして、APPモジュール9は、雨滴検知デバイスへのリクエスト情報(データD1)をAPI処理部14に出力し、バッファ部13を経由して雨滴検知デバイスへのリクエスト情報(データD1)が通信処理部12からVFB4を介してミドルウェア3に送信される。
なお、ここまでの処理は、図3のステップ1、ステップ2、ステップ5、ステップ6及びステップ8に相当する。
【0050】
次に、通信処理部12が、VFB4を介して、ミドルウェア3からのデータC1をVFB4を介して受信し、データC1をバッファ部13に格納する。
次に、API処理部14が、バッファ部13からデータC1を読み出し、読み出したデータC1をAPPモジュール9に出力する。
APPモジュール9は、データC1内のデータの有効/無効情報をチェックする(ステップ42)。
データC1内のデータの有効/無効情報が「無効」の場合(ステップ42でNO)は、APPモジュール9は、データB1内の雨滴検知デバイスの追加の有無情報に「有」を書き込む(ステップ43)。
更に、APPモジュール9は、データB1内の雨状態の有効/無効情報に「無効」を書き込む(ステップ44)。
なお、データB1内の雨滴検知デバイス用制御アプリケーションが提供するデータ(雨状態)には、なにも記述しない。
その後、データB1がAPPモジュール9からAPI処理部14に出力され、API処理部14及びバッファ部13を経由して、通信処理部12からデータB1がVFB4を介して既存APP SW−C(1)5に送信される。
なお、ここまでの処理は、図3のステップ3、ステップ4、ステップ5ステップ6及びステップ8に相当する。
【0051】
一方、データC1内のデータの有効/無効情報をチェックした結果、データの有効/無効情報が「有効」の場合(ステップ42でYES)は、APPモジュール9は、データC1内の雨滴検知デバイスからのデータ(センサ値)からセンサ値を読み出し(ステップ45)、読み出したセンサ値から雨状態を算出する(ステップ46)。
次に、APPモジュール9は、データB1内の雨滴検知デバイスの追加の有無情報に「有」を書き込む(ステップ47)。
また、APPモジュール9は、データB1内の雨状態の有効/無効情報に「有効」を書き込む(ステップ48)。
更に、APPモジュール9は、データB1内の雨滴検知デバイス用制御アプリケーションが提供するデータ(雨状態)にステップ46で算出した「雨状態」を書き込む(ステップ49)。
その後、データB1がAPPモジュール9からAPI処理部14に出力され、API処理部14及びバッファ部13を経由して、通信処理部12からデータB1がVFB4を介して既存APP SW−C(1)5に送信される。
なお、ここまでの処理は、図3のステップ3、ステップ4、ステップ5ステップ6及びステップ8に相当する。
【0052】
そして、既存APP SW−C(1)5では、図6のステップ26以降の動作が行われる。
【0053】
以上のように、本実施の形態では、APPモジュール9の実装前に、APPモジュール9と既存APP SW−C(1)5との間の通信のための通信バス11及びAPPモジュール9とミドルウェア3と間の通信のための通信バスをVFB4内に設定しておき、これら通信バス11と通信処理部12を論理的に接続してASL10をECU100に実装する。
そして、APPモジュール9がECU100に実装された際には、通信処理部12がVFB4を介して既存APP SW−C(1)5及びミドルウェア3と通信可能になっているので、VFB4の再設計を伴わずに、APPモジュール9はASL10を用いて既存APP SW−C(1)5及びミドルウェア3と通信することができる。
つまり、本実施の形態によれば、ASL10がAPPモジュール9と既存APP SW−C(1)5との間に介在することで、VFB4を変更することなく、APPモジュール9を追加することができる。
このため、ECU100の開発時にVFB4の設計を一度すると、SW−Cの追加の際のVFB4の再設計の手間が省ける。
さらに、SW−Cの追加にVFB設計ツールを必要としないことから、開発から離れた実フィールドでのECU100の運用中においても、簡単にソフトウェア更新を行うことができる。
【0054】
以上、本実施の形態では、
ソフトウェアのアーキテクチャとして、既存アプリケーションSW−Cとは別に、追加アプリケーションSW−Cが実装された車載装置を説明した。
そして、追加アプリケーションSW−Cは、上位層に追加するアプリケーションモジュール、下位層にASLが配置されていることを説明した。
更に、ASLは、VFBを介して他のSW−C及びミドルウェアと通信する通信処理部と、通信処理部が他のSW−C及びミドルウェアから得た情報の格納及び他のSW−C及びミドルウェアに対して送信する情報を格納するためのバッファ部と、アプリケーションモジュールに対してバッファ部へのアクセスを可能とするAPI処理部とを有することを説明した。
【0055】
実施の形態2.
図8は、ECU−A30で使用している既存APP SW−C(2)6をECU−B31に移植する動作を説明している。
ECU−A30には、既存APP SW−C(1)5と既存APP SW−C(2)6の二つのSW−Cが実装され、二つのSW−CはVFB4を介して通信している。
ECU−B31には、既存APP SW−C(1)5と追加APP SW−C7の二つのSW−Cが実装され、二つのSW−CはVFB4を介して通信している。
追加APP SW−C7のASL10は、実施の形態1で説明したように、既存APP SW−C(1)5との通信に用いられる通信バス11と論理的に接続されている。
【0056】
ECU−B31のVFB4には、追加APP SW−C7のASL10と既存APP SW−C(2)6が通信を行うための通信バス11が存在しないため、既存APP SW−C(2)6をECU−B31のVFB4に直接実装することができない。
そこで、既存APP SW−C(2)6は、追加APP SW−C7のアプリケーションモジュールとして実装する。
但し、既存APP SW−C(2)6が使用するAPIとAPI処理部14が提供しているAPIが異なっている場合は、APIの差異を吸収するためのAPI変換部20を設ける。
例えば、既存APP SW−C(2)6はデータの読み込みに、Vfb_ReadDataというAPIを使用しているとする。
API処理部14は、アプリケーションモジュールに対してデータの読み込みにAsl_ReadDataというAPIを提供しているとする。
この場合、API変換部20は、既存APP SW−C(2)6のソースコード内のVfb_ReadDataの記述をAsl_ReadDataに変更して、Asl_ReadDataに対応した既存APP SW−C(2)β21を生成する。
API変換部20が変更するのは、ソースコード中のAPIの名称のみであり、既存APP SW−C(2)β21の制御ロジックはAPP SW−C(2)6と同じである。
このようにすることで、ECU−B31は、既存APP SW−C(2)6の実装に際し、VFB4を変更することなく、既存APP SW−C(2)6のロジック変更を行うことなく、追加APP SW−C7のアプリケーションモジュールとして実装することが可能となる。
【0057】
APIの変更は、車載装置の中で実施してもよい。
図9は、ASL10の中にAPI変換部22を置く構成を示す。
図9のECU−B31は、図1のECU100である。
図9では、ハードウェア50の記述及び追加APP SW−C7内の通信処理部12、バッファ部13、APPモジュール8、9の記述は省略している。
API変換部22には、既存APP SW−C(2)6が使用するAPIを用意しておく。
API変換部22は、既存APP SW−C(2)6が使用するAPIを用いて既存APP SW−C(2)6からデータを入力し、入力したデータをAPI処理部14が使用するAPIを用いてAPI処理部14に出力する。
また、API変換部22は、API処理部14が使用するAPIを用いてAPI処理部14からデータを入力し、入力したデータを既存APP SW−C(2)6が使用するAPIを用いて既存APP SW−C(2)6に出力する。
API変換部22は、既存APP SW−C(2)6がデータの入出力に使用するAPIを、API処理部14がデータ入出力に使用するAPIに定義しなおしてもよいし、API処理部14のAPIを直接呼び出してもよい。
【0058】
なお、追加APP SW−C7に実装された既存APP SW−C(2)6は、指定ソフトウェアコンポーネントの例に相当する。
【0059】
API変換部22によるAPIの変換動作を除けば、図9の既存APP SW−C(1)5と既存APP SW−C(2)6との間の通信の手順は、実施の形態1で説明した既存APP SW−C(1)5とAPPモジュール9との間の通信の手順と同じである。
つまり、通信処理部12が、既存APP SW−C(1)5からのデータをVFB4の該当する通信バス11から受信し、受信したデータをバッファ部13に格納し、API処理部14がバッファ部13から既存APP SW−C(1)5からのデータを入力し、入力したデータをAPI変換部22を介して既存APP SW−C(2)6に出力する。
また、API処理部14が、API変換部22を介して既存APP SW−C(2)6からのデータを入力し、入力したデータをバッファ部13に格納し、通信処理部12がバッファ部13から既存APP SW−C(2)6からのデータを入力し、入力したデータをVFB4の該当する通信バス11を介して既存APP SW−C(1)5に送信する。
【0060】
実施の形態3.
VFB4の通信バス11には、VFB4を変更することなしに将来的な拡張性を持たせることが可能である。
実施の形態1で説明したVFB4では、APPモジュールと既存APP SW−C(1)5との間で既定の公開データ及び取得データを通信するための通信バス11と、APPモジュールと既存APP SW−C(2)6との間で公開データ及び取得データを通信するための通信バス11が設けられている。
これら公開データ及び取得データは、VFB4の設計段階で定義されているデータであり、実施の形態1で説明した通信バス11を以下では既定のバスと呼ぶ。
本実施の形態では、VFB4の設計段階では通信対象のデータが定義されていない予備の通信バス11を設ける。
予備の通信バス11は、換言すると、データの内容が指定されていない通信バスである。
予備の通信バス11を、以下では、汎用のバスと呼ぶ。
【0061】
図10は、既定のバスと汎用のバスの例を示す。
既定のバスは、通信される公開データ及び取得データが予め定義されているため、それぞれのデータに対応するデータ型でバスのフレームフォーマットが形成される。
図10では、1ビットのデータが送受信される既定のバス、4ビットのデータが送受信される既定のバス、1バイトのデータが送受信される既定のバスが例示されている。
汎用のバスでは、適当なサイズの配列データが送受信される。
この汎用のバス内は、ASN.1、JSONといった抽象構文定義でデータが送受信される。任意のプロトコルでデータを送受信しても良い。
抽象構文定義では、例えば、ペイロードデータの前にペイロードデータのデータサイズが記述されるデータサイズ情報が付加される。
抽象構文定義は、通信するSW−C間で同様に解釈する必要があるため、図11に示す通り、本実施の形態では、既存APP SW−C(1)5と追加APP SW−C7に抽象構文定義処理部32を配置する。
なお、図11では、ECU100の構成のうち、既存APP SW−C(1)5と追加APP SW−C7のみを抜き出して図示している。
また、図11では、追加APP SW−C7内の通信処理部12の図示を省略している。
【0062】
既存APP SW−C(1)5には、図11に示す通り、控えの公開データリスト33を用意しておく。
控えの公開データリスト33は、公開データとして未使用のデータであるが、将来的に公開データとして使用する可能性のあるデータの集合である。
例えば、ECU100に新たなアプリケーションモジュールが実装された場合に、控えの公開データリスト33内のデータが、この新たなアプリケーションモジュールの公開データとして利用される。
控えの公開データリスト33に含まれるデータは、例えば、パワーシート位置の情報、サイドエアバッグの搭載の有無の情報である。
なお、アプリケーションモジュールの設計ツールにも、控えの公開データリスト33と同様のリストを配備しておく。
【0063】
図12は、APPモジュール8が、汎用のバスを用いて、既存APP SW−C(1)5の持つパワーシート位置の情報(控えの公開データリスト33内の情報)を要求するデータを送信していることを示す。
設計者は、APPモジュール8の設計の段階で控えの公開データリスト33を参照することで、汎用のバスを用いれば、既存APP SW−C(1)5からパワーシート位置の情報が取得できることがわかる。
これをもとに、設計者は、APPモジュール8を設計する。
追加APP SW−C7に追加されたAPPモジュール8は、API処理部14に、控えの公開データを要求するAPIを用いてパワーシート位置の情報を要求する。
API処理部14は、控えの公開データを要求するAPIが呼び出されたら、抽象構文定義処理部32を用いてデータを変換し、変換後のデータをバッファ部13の所定の位置に書き込む。
抽象構文定義処理部32は、例えば、パワーシート位置の情報を要求するペイロードデータに、このペイロードデータのデータサイズ情報を付加する変換を行う。
通信処理部12は、抽象構文定義処理部32で変換されたデータをバッファ部13から入力し、入力したデータを汎用のバスに送出する。
汎用のバスの配列データには、追加APP SW−C7の抽象構文定義処理部32で変換されたデータが設定される。
【0064】
既存APP SW−C(1)5では、汎用のバスからデータを受信し、受信したデータを既存APP SW−C(1)5の抽象構文定義処理部32で変換し、データの内容を解釈する。
既存APP SW−C(1)5の抽象構文定義処理部32では、例えば、受信したデータからデータサイズ情報を除去する変換を行う。
既存APP SW−C(1)5では、APPモジュール8から要求されたデータが控えの公開データリスト33にあれば応答する。
そして、抽象構文定義処理部32は、ペイロードデータ(パワーシート位置の情報)に、このペイロードデータのデータサイズ情報を付加する変換を行う。
図13は、既存APP SW−C(1)5が、汎用のバスを用いて、パワーシート位置の情報を送信していることを示す。
追加APP SW−C7では、通信処理部12が汎用のバスを用いて、既存APP SW−C(1)5からのデータを受信し、抽象構文定義処理部32が、受信したデータからデータサイズ情報を除去する変換を行う。
そして、通信処理部12は変換後のデータ(パワーシート位置の情報)をバッファ部13に格納し、API処理部14がバッファ部13からデータ(パワーシート位置の情報)を入力し、入力したデータ(パワーシート位置の情報)をAPPモジュール8に出力する。
【0065】
以上の構成により、本実施の形態では、VFB4を変更することなく、将来登場するアプリケーションモジュールに対して拡張性を持った通信バス11を実現することができる。
【0066】
以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、2つ以上を組み合わせて実施しても構わない。
あるいは、これらの実施の形態のうち、1つを部分的に実施しても構わない。
あるいは、これらの実施の形態のうち、2つ以上を部分的に組み合わせて実施しても構わない。
なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。
【符号の説明】
【0067】
1 ソフトウェア、2 ドライバ、3 ミドルウェア、4 VFB、5 既存アプリケーションSW−C(1)、6 既存アプリケーションSW−C(2)、7 追加アプリケーションSW−C、8 アプリケーションモジュール、9 アプリケーションモジュール、10 ASL、11 通信バス、12 通信処理部、13 バッファ部、14 API処理部、20 API変換部、22 API変換部、30 ECU−A、31 ECU−B、32 抽象構文定義処理部、33 控えの公開データリスト、50 ハードウェア、100 ECU、300 OS、501 CPU、502 通信モジュール、503 インタフェース、504 センサ、505 デバイス、506 RAM、507 ROM。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18

【手続補正書】
【提出日】2013年4月22日
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
複数のソフトウェアコンポーネントが実装されている車載装置であって、
前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントを通信先とするアプリケーションプログラムと対応付けられたデータ制御部を有し、
前記データ制御部は、
前記アプリケーションプログラムのASL(Application Sub Layer)であり、
前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータと、前記通信先ソフトウェアコンポーネントからのデータとを蓄積するバッファ部と、
前記バッファ部に蓄積されている前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信し、受信したデータを前記バッファ部に格納する通信処理部と、
前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記通信先ソフトウェアコンポーネントからのデータを前記バッファ部から入力し、入力したデータを出力するデータ中継部とを有することを特徴とする車載装置。
【請求項2】
前記データ制御部は、
前記車載装置に前記アプリケーションプログラムが実装される前に、前記アプリケーションプログラムに対応付けられて前記車載装置に実装されており、
前記データ中継部は、
前記車載装置に前記アプリケーションプログラムが実装された後に、
前記アプリケーションプログラムから、前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記通信先ソフトウェアコンポーネントからのデータを前記アプリケーションプログラムに出力することを特徴とする請求項1に記載の車載装置。
【請求項3】
前記データ中継部は、
前記車載装置に前記アプリケーションプログラムが実装される前は、
前記アプリケーションプログラムのスタブモジュールから、前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記通信先ソフトウェアコンポーネントからのデータを前記スタブモジュールに出力することを特徴とする請求項2に記載の車載装置。
【請求項4】
前記車載装置は、
ミドルウェアが実装されており、
前記バッファ部は、
前記ミドルウェアへのデータと、前記ミドルウェアからのデータとを蓄積し、
前記通信処理部は、
前記バッファ部に蓄積されている前記ミドルウェアへのデータを前記ミドルウェアに送信し、前記ミドルウェアから送信されたデータを受信し、受信したデータを前記バッファ部に格納し、
前記データ中継部は、
前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記ミドルウェアからのデータを前記バッファ部から入力し、入力したデータを出力することを特徴とする請求項1〜3のいずれかに記載の車載装置。
【請求項5】
前記データ制御部は、
前記車載装置に前記アプリケーションプログラムが実装される前に、前記ミドルウェアに対応付けられて前記車載装置に実装されており、
前記データ中継部は、
前記車載装置に前記アプリケーションプログラムが実装された後に、
前記アプリケーションプログラムから、前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記ミドルウェアからのデータを前記アプリケーションプログラムに出力することを特徴とする請求項4に記載の車載装置。
【請求項6】
前記データ中継部は、
前記車載装置に前記アプリケーションプログラムが実装される前は、
前記アプリケーションプログラムのスタブモジュールから、前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記ミドルウェアからのデータを前記スタブモジュールに出力することを特徴とする請求項5に記載の車載装置。
【請求項7】
前記通信処理部は、
AUTOSAR(登録商標)(AUTomotive Open System ARchitecture)のVFB(Virtual Function Bus)に含まれる、前記通信先ソフトウェアコンポーネントと前記アプリケーションプログラムとの間の通信のために設定されている通信バスと接続されており、
前記通信バスを用いて、前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信することを特徴とする請求項1〜6のいずれかに記載の車載装置。
【請求項8】
前記通信処理部は、
AUTOSAR(登録商標)のVFBに含まれる、前記ミドルウェアと前記アプリケーションプログラムとの間の通信のために設定されている通信バスと接続されており、
前記通信バスを用いて、前記ミドルウェアへのデータを前記ミドルウェアに送信し、前記ミドルウェアから送信されたデータを受信することを特徴とする請求項4〜6のいずれかに記載の車載装置。
【請求項9】
記データ制御部と前記アプリケーションプログラムとによりソフトウェアコンポーネントが構成されていることを特徴とする請求項1〜8のいずれかに記載の車載装置。
【請求項10】
前記データ制御部は、
前記複数のソフトウェアコンポーネントの中から指定された前記通信先ソフトウェアコンポーネント以外のソフトウェアコンポーネントである指定ソフトウェアコンポーネントと対応付けられ、
前記バッファ部は、
前記指定ソフトウェアコンポーネントから前記通信先ソフトウェアコンポーネントへのデータと、前記通信先ソフトウェアコンポーネントから前記指定ソフトウェアコンポーネントへのデータとを蓄積し、
前記通信処理部は、
前記バッファ部に蓄積されている前記指定ソフトウェアコンポーネントからのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信された前記指定ソフトウェアコンポーネントへのデータを受信し、受信したデータを前記バッファ部に格納し、
前記データ中継部は、
前記指定ソフトウェアコンポーネントから、前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記指定ソフトウェアコンポーネントへのデータを前記バッファ部から入力し、入力したデータを前記指定ソフトウェアコンポーネントに出力することを特徴とする請求項1〜9のいずれかに記載の車載装置。
【請求項11】
前記車載装置は、更に、
前記指定ソフトウェアコンポーネントがデータの入出力に用いるAPI(Application Program Interface)と、前記データ中継部がデータの入出力に用いるAPIとが異なる場合に、
前記指定ソフトウェアコンポーネントが用いるAPIを用いて前記指定ソフトウェアコンポーネントからデータを入力し、入力したデータを、前記データ中継部が用いるAPIを用いて前記データ中継部に出力し、
前記データ中継部が用いるAPIを用いて前記データ中継部からデータを入力し、入力したデータを、前記指定ソフトウェアコンポーネントが用いるAPIを用いて前記指定ソフトウェアコンポーネントに出力するAPI変換部を有することを特徴とする請求項10に記載の車載装置。
【請求項12】
前記通信処理部は、
AUTOSAR(登録商標)のVFBに含まれる、通信対象のデータが定義されていない予備の通信バスを用いて、前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信することを特徴とする請求項1に記載の車載装置。
【請求項13】
複数のソフトウェアコンポーネントが実装されている車載装置で実行されるプログラムであって、
前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントを通信先とするアプリケーションプログラムと対応付けられ、
前記アプリケーションプログラムのASL(Application Sub Layer)において、
前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ領域に格納し、前記バッファ領域に格納されている前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、
前記通信先ソフトウェアコンポーネントから送信されたデータを受信し、受信したデータを前記バッファ領域に格納し、前記バッファ領域に格納されている前記通信先ソフトウェアコンポーネントからのデータを出力することを特徴とするプログラム。

【手続補正書】
【提出日】2013年7月18日
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
複数のソフトウェアコンポーネントが実装されている車載装置であって、
前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントを通信先とするアプリケーションプログラムと対応付けられたデータ制御部を有し、
前記データ制御部は、
前記アプリケーションプログラムのASL(Application Sub Layer)であり、
前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータと、前記通信先ソフトウェアコンポーネントからのデータとを蓄積するバッファ部と、
前記バッファ部に蓄積されている前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信し、受信したデータを前記バッファ部に格納する通信処理部と、
前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記通信先ソフトウェアコンポーネントからのデータを前記バッファ部から入力し、入力したデータを出力するデータ中継部とを有することを特徴とする車載装置。
【請求項2】
前記データ制御部は、
前記車載装置に前記アプリケーションプログラムが実装される前に、前記アプリケーションプログラムに対応付けられて前記車載装置に実装されており、
前記データ中継部は、
前記車載装置に前記アプリケーションプログラムが実装された後に、
前記アプリケーションプログラムから、前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記通信先ソフトウェアコンポーネントからのデータを前記アプリケーションプログラムに出力することを特徴とする請求項1に記載の車載装置。
【請求項3】
前記データ中継部は、
前記車載装置に前記アプリケーションプログラムが実装される前は、
前記アプリケーションプログラムのスタブモジュールから、前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記通信先ソフトウェアコンポーネントからのデータを前記スタブモジュールに出力することを特徴とする請求項2に記載の車載装置。
【請求項4】
前記車載装置は、
ミドルウェアが実装されており、
前記バッファ部は、
前記ミドルウェアへのデータと、前記ミドルウェアからのデータとを蓄積し、
前記通信処理部は、
前記バッファ部に蓄積されている前記ミドルウェアへのデータを前記ミドルウェアに送信し、前記ミドルウェアから送信されたデータを受信し、受信したデータを前記バッファ部に格納し、
前記データ中継部は、
前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記ミドルウェアからのデータを前記バッファ部から入力し、入力したデータを出力することを特徴とする請求項1〜3のいずれかに記載の車載装置。
【請求項5】
前記データ制御部は、
前記車載装置に前記アプリケーションプログラムが実装される前に、前記ミドルウェアに対応付けられて前記車載装置に実装されており、
前記データ中継部は、
前記車載装置に前記アプリケーションプログラムが実装された後に、
前記アプリケーションプログラムから、前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記ミドルウェアからのデータを前記アプリケーションプログラムに出力することを特徴とする請求項4に記載の車載装置。
【請求項6】
前記データ中継部は、
前記車載装置に前記アプリケーションプログラムが実装される前は、
前記アプリケーションプログラムのスタブモジュールから、前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記ミドルウェアからのデータを前記スタブモジュールに出力することを特徴とする請求項5に記載の車載装置。
【請求項7】
前記通信処理部は、
AUTOSAR(登録商標)(AUTomotive Open System ARchitecture)のVFB(Virtual Function Bus)に含まれる、前記通信先ソフトウェアコンポーネントと前記アプリケーションプログラムとの間の通信のために設定されている通信バスと接続されており、
前記通信バスを用いて、前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信することを特徴とする請求項1〜6のいずれかに記載の車載装置。
【請求項8】
前記通信処理部は、
AUTOSAR(登録商標)のVFBに含まれる、前記ミドルウェアと前記アプリケーションプログラムとの間の通信のために設定されている通信バスと接続されており、
前記通信バスを用いて、前記ミドルウェアへのデータを前記ミドルウェアに送信し、前記ミドルウェアから送信されたデータを受信することを特徴とする請求項4〜6のいずれかに記載の車載装置。
【請求項9】
前記データ制御部と前記アプリケーションプログラムとによりソフトウェアコンポーネントが構成されていることを特徴とする請求項1〜8のいずれかに記載の車載装置。
【請求項10】
前記データ制御部は、
前記複数のソフトウェアコンポーネントの中から指定された前記通信先ソフトウェアコンポーネント以外のソフトウェアコンポーネントである指定ソフトウェアコンポーネントと対応付けられ、
前記バッファ部は、
前記指定ソフトウェアコンポーネントから前記通信先ソフトウェアコンポーネントへのデータと、前記通信先ソフトウェアコンポーネントから前記指定ソフトウェアコンポーネントへのデータとを蓄積し、
前記通信処理部は、
前記バッファ部に蓄積されている前記指定ソフトウェアコンポーネントからのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信された前記指定ソフトウェアコンポーネントへのデータを受信し、受信したデータを前記バッファ部に格納し、
前記データ中継部は、
前記指定ソフトウェアコンポーネントから、前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記指定ソフトウェアコンポーネントへのデータを前記バッファ部から入力し、入力したデータを前記指定ソフトウェアコンポーネントに出力することを特徴とする請求項1〜9のいずれかに記載の車載装置。
【請求項11】
前記車載装置は、更に、
前記指定ソフトウェアコンポーネントがデータの入出力に用いるAPI(Application Program Interface)と、前記データ中継部がデータの入出力に用いるAPIとが異なる場合に、
前記指定ソフトウェアコンポーネントが用いるAPIを用いて前記指定ソフトウェアコンポーネントからデータを入力し、入力したデータを、前記データ中継部が用いるAPIを用いて前記データ中継部に出力し、
前記データ中継部が用いるAPIを用いて前記データ中継部からデータを入力し、入力したデータを、前記指定ソフトウェアコンポーネントが用いるAPIを用いて前記指定ソフトウェアコンポーネントに出力するAPI変換部を有することを特徴とする請求項10に記載の車載装置。
【請求項12】
前記通信処理部は、
AUTOSAR(登録商標)のVFBに含まれる、通信対象のデータが定義されていない予備の通信バスを用いて、前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信することを特徴とする請求項1に記載の車載装置。
【請求項13】
複数のソフトウェアコンポーネントが実装されている車載装置で実行されるプログラムであって、
前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントを通信先とするアプリケーションプログラムと対応付けられ、
前記アプリケーションプログラムのASL(Application Sub Layer)において、
前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータをバッファ領域に格納し、前記バッファ領域に格納されている前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、
前記通信先ソフトウェアコンポーネントから送信されたデータを受信し、受信したデータを前記バッファ領域に格納し、前記バッファ領域に格納されている前記通信先ソフトウェアコンポーネントからのデータを出力することを実行させることを特徴とするプログラム。
【請求項14】
複数のソフトウェアコンポーネントが実装されている車載装置であって、
前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントを通信先とするアプリケーションプログラムと対応付けられたデータ制御部を有し、
前記データ制御部は、
前記アプリケーションプログラムのASL(Application Sub Layer)であって、前記アプリケーションプログラムと前記複数のソフトウェアコンポーネントとの間の通信を仲介するものであり、
前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータと、前記通信先ソフトウェアコンポーネントからのデータとを蓄積するバッファ部を有することを特徴とする車載装置。
【請求項15】
複数のソフトウェアコンポーネントと、ミドルウェアとが実装されている車載装置であって、
前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントまたは前記ミドルウェアを通信先とするアプリケーションプログラムと対応付けられたデータ制御部を有し、
前記データ制御部は、
前記アプリケーションプログラムのASL(Application Sub Layer)であって、前記アプリケーションプログラムと前記ソフトウェアコンポーネントまたは前記ミドルウェアとの間でデータを中継するものであり、
前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータまたは通信先ミドルウェアへのデータと、前記通信先ソフトウェアコンポーネントからのデータまたは前記通信先ミドルウェアからのデータとを蓄積するバッファ部とを有することを特徴とする車載装置。
【請求項16】
複数のソフトウェアコンポーネントと、ミドルウェアとが実装されている車載装置であって、
前記ミドルウェアを通信先とするアプリケーションプログラムと対応付けられたデータ制御部を有し、
前記データ制御部は、
前記アプリケーションプログラムのASL(Application Sub Layer)であり、
前記ミドルウェアへのデータと、前記ミドルウェアからのデータとを蓄積するバッファ部と、
前記バッファ部に蓄積されている前記ミドルウェアへのデータを前記ミドルウェアに送信し、前記ミドルウェアから送信されたデータを受信し、受信したデータを前記バッファ部に格納する通信処理部と、
前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記ミドルウェアからのデータを前記バッファ部から入力し、入力したデータを出力するデータ中継部とを有することを特徴とする車載装置。
【国際調査報告】