JP5372297B1 - 車載装置及びプログラム - Google Patents

Abstract

ＡＳＬ１０は、既存ＡＰＰ ＳＷ−Ｃ（１）５を通信先とするＡＰＰモジュール９と対応付けられている。バッファ部１３は、既存ＡＰＰ ＳＷ−Ｃ（１）５へのデータと、既存ＡＰＰ ＳＷ−Ｃ（１）５からのデータとを蓄積する。通信処理部１２は、バッファ部１３に蓄積されている既存ＡＰＰ ＳＷ−Ｃ（１）５へのデータを既存ＡＰＰ ＳＷ−Ｃ（１）５に送信し、既存ＡＰＰ ＳＷ−Ｃ（１）５から送信されたデータを受信し、受信したデータをバッファ部１３に格納する。ＡＰＩ処理部１４は、既存ＡＰＰ ＳＷ−Ｃ（１）５へのデータをＡＰＰモジュール９から入力し、入力したデータをバッファ部１３に格納し、既存ＡＰＰ ＳＷ−Ｃ（１）５からのデータをバッファ部１３から入力し、入力したデータをＡＰＰモジュール９に出力する。

Description

本発明は、自動車に搭載される車載装置に関する。

自動車分野でのソフトウェア標準プラットフォームであるＡＵＴＯＳＡＲ（登録商標）（ＡＵＴｏｍｏｔｉｖｅ Ｏｐｅｎ Ｓｙｓｔｅｍ ＡＲｃｈｉｔｅｃｔｕｒｅ）は、アプリケーション層をソフトウェアコンポーネント化し、ソフトウェアコンポーネント（以下、ＳＷ−Ｃともいう）の下位層はＶＦＢ（Ｖｉｒｔｕａｌ Ｆｕｎｃｔｉｏｎａｌ Ｂｕｓ）とするアーキテクチャでソフトウェアの階層化を図っている。
ＶＦＢは、ＳＷ−Ｃにハードウェアやネットワークを意識させることのない環境を提供している。
ＳＷ−Ｃのインタフェースが確定すれば、ソフトウェア開発者は、ＶＦＢがＳＷ−Ｃの間をどのように接続するかを設計し、設計に従って、ＳＷ−Ｃを実装する。
このようにＶＦＢによって、ＳＷ−Ｃの移植性を高めることができる。

ＡＵＴＯＳＡＲ（商標登録） Ｔｅｃｈｎｉｃａｌ Ｏｖｅｒｖｉｅｗ Ｖ２．０．１

従来は、ＳＷ−Ｃの追加によるソフトウェア更新は、ＶＦＢの変更を伴うことから、ＳＷ−Ｃを追加する度にＶＦＢを設計し直す必要があった。
このため、ＳＷ−Ｃの追加の度にＶＦＢを再設計することにより、開発工数が増えてしまうという課題がある。
また、ＶＦＢの設計には設計ツールを必要とし、更に、設計ツールを用いて適正にＶＦＢを設計するためにはＶＦＢの設計方法及び設計ツールの操作方法を熟知している必要がある。
このため、開発環境から離れた後の車載装置に、プラグアンドプレイのようにＳＷ−Ｃを追加するソフトウェア更新を行うことは困難である。

本発明は、上記の事情に鑑みたものであり、ＶＦＢを変更することなく、アプリケーションプログラムを追加できるようにすることを主な目的とする。

本発明に係る車載装置は、
複数のソフトウェアコンポーネントが実装されている車載装置であって、
前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントを通信先とするアプリケーションプログラムと対応付けられたデータ制御部を有し、
前記データ制御部は、
前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータと、前記通信先ソフトウェアコンポーネントからのデータとを蓄積するバッファ部と、
前記バッファ部に蓄積されている前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信し、受信したデータを前記バッファ部に格納する通信処理部と、
前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記通信先ソフトウェアコンポーネントからのデータを前記バッファ部から入力し、入力したデータを出力するデータ中継部とを有することを特徴とする。

本発明によれば、通信先ソフトウェアコンポーネントと通信可能なデータ制御部がアプリケーションプログラムと通信先ソフトウェアコンポーネントとの間に介在することで、ＶＦＢを変更することなく、アプリケーションプログラムを追加することができる。

実施の形態１におけるＥＣＵの構成例を示す図である。 実施の形態１における追加アプリケーションＳＷ−Ｃ内のＡＳＬの構成を示す図である。 実施の形態１における追加アプリケーションＳＷ−Ｃの動作フローを示す図である。 実施の形態１における通信バスの構成要素の例を示す図である。 実施の形態１におけるデータの割り付け例を示す図である。 実施の形態１における既存アプリケーションＳＷ−Ｃの動作フローを示す図である。 実施の形態１におけるアプリケーションモジュールの動作フローを示す図である。 実施の形態２におけるＥＣＵの外部でのＡＰＩ変換の例を示す図である。 実施の形態２におけるＥＣＵの内部でのＡＰＩ変換の例を示す図である。 実施の形態３における通信バスのフレームフォーマットの例を示す図である。 実施の形態３における既存アプリケーションＳＷ−Ｃ及び追加アプリケーションＳＷ−Ｃ内の構成例を示す図である。 実施の形態３における追加アプリケーションＳＷ−Ｃが送信するデータの例を示す図である。 実施の形態３における既存アプリケーションＳＷ−Ｃが送信するデータの例を示す図である。 実施の形態１におけるアプリケーションモジュールの追加を行う際の構成例を示す図である。 実施の形態１における追加アプリケーションＳＷ−Ｃ内のＡＳＬでのデータの流れを示す図である。 実施の形態１における追加アプリケーションＳＷ−Ｃ内のＡＳＬでのデータの流れを示す図である。 実施の形態１における追加アプリケーションＳＷ−Ｃ内のＡＳＬでのデータの流れを示す図である。 実施の形態１における追加アプリケーションＳＷ−Ｃ内のＡＳＬでのデータの流れを示す図である。

実施の形態１．
本実施の形態では、ＶＦＢを変更することなく、アプリケーションプログラムを追加することが可能なソフトウェアプラットフォームを説明する。

図１は、本実施の形態に係るＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）１００の構成例を示す。
ＥＣＵ１００は、車載装置の例に相当する。
図１では、ＥＣＵ１００の構成をハードウェア５０とソフトウェア１に分けて示している。

ハードウェア５０には、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）５０１、通信モジュール５０２、インタフェース５０３、センサ５０４、デバイス５０５が含まれる。

ＣＰＵ５０１には、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）５０６及びＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）５０７が含まれている。
ＲＯＭ５０７には、ソフトウェア１を構成する各種プログラムが記憶されており、これらプログラムがＲＡＭ５０６にロードされ、順次ＣＰＵ５０１に読み込まれ、ＣＰＵ５０１がこれらプログラムを実行する。
本実施の形態及び以降の実施の形態に示す、ソフトウェア１内の各要素の処理内容は、ＣＰＵ５０１によるプログラムの実行により実現される。
また、本実施の形態及び以降の実施の形態の説明において、「〜の判断」、「〜の判定」、「〜の抽出」、「〜の格納」、「〜の蓄積」、「〜の設定」、「〜の更新」、「〜の選択」、「〜の算出」、「〜の書込み」、「〜の読み出し」、「〜の生成」、「〜の入力」、「〜の出力」、「〜の受信」等として説明している処理の結果を示す情報やデータや信号値や変数値がＲＡＭ５０６にファイルとして記憶される。

通信モジュール５０２は、ＥＣＵ１００が搭載されている車両内の機器及び車両の外部にある機器と通信を行う。
インタフェース５０３は、ＥＣＵ１００が搭載されている車両のユーザ（ドライバ及び同乗者）から各種要求を受付け、また、ユーザに各種情報を表示する。
センサ５０４及びデバイス５０５は、車両に関する様々な事象の検知を行う。
インタフェース５０３、センサ５０４及びデバイス５０５は、ＥＣＵ１００の内部に配置されていてもよいし、ＥＣＵ１００の外に配置されていてもよい。
インタフェース５０３、センサ５０４及びデバイス５０５がＥＣＵ１００の外に配置されている場合は、ＣＰＵ５０１とインタフェース５０３、センサ５０４及びデバイス５０５がバスにより接続されている。

なお、図１に示したハードウェア５０の構成は、あくまでも一例を示すものであり、ＥＣＵ１００のハードウェア５０は図１の構成に限らず、他の構成であってもよい。

ソフトウェア１は、ドライバ２、ミドルウェア３、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）３００、ＶＦＢ４、既存アプリケーション ＳＷ−Ｃ（１）５、既存アプリケーション ＳＷ−Ｃ（２）６、追加アプリケーション ＳＷ−Ｃ７で構成する。
図１では、便宜的に、既存アプリケーション ＳＷ−Ｃ（１）５、既存アプリケーション ＳＷ−Ｃ（２）６、追加アプリケーション ＳＷ−Ｃ７で構成しているが、ＳＷ−Ｃの数や種類は任意でよい。
つまり、既存アプリケーション ＳＷ−Ｃ（１）５、既存アプリケーション ＳＷ−Ｃ（２）６、追加アプリケーション ＳＷ−Ｃ７以外のＳＷ−ＣがＥＣＵ１００に実装されていてもよい。
なお、以下では、既存アプリケーション ＳＷ−Ｃ（１）５、既存アプリケーション ＳＷ−Ｃ（２）６、追加アプリケーション ＳＷ−Ｃ７は、それぞれ、既存ＡＰＰ ＳＷ−Ｃ（１）５、既存ＡＰＰ ＳＷ−Ｃ（２）６、追加ＡＰＰ ＳＷ−Ｃ７とも表記する。

ＶＦＢ４中の破線で示した通信バス１１は、ＳＷ−ＣとＳＷ−Ｃとの間、及びＳＷ−Ｃとミドルウェアとの間を結ぶ仮想的な通信チャネルである。
ＶＦＢ４は、ＳＷ−ＣとＳＷ−Ｃとの間、及びＳＷ−Ｃとミドルウェアとの間で授受されるデータの内容と実行タイミングを制御する。

一般的に通信バス１１はＶＦＢ設計ツール上で設計され、設計内容に従ってＶＦＢ設計ツールの自動コード生成機能によってプログラムコードが生成される。
つまり、通信バス１１で構成されるＶＦＢ４の実態は、ドライバ２、ミドルウェア３、既存ＡＰＰ ＳＷ−Ｃ（１）５、既存ＡＰＰ ＳＷ−Ｃ（２）６、追加ＡＰＰ ＳＷ−Ｃ７と同様にプログラムコードである。
ＥＣＵ１００に実装するＶＦＢ４の実行可能ファイルを生成する時点では、ドライバ２、ミドルウェア３、ＶＦＢ４、アプリケーションとして機能する既存ＡＰＰ ＳＷ−Ｃ（１）５、既存ＡＰＰ ＳＷ−Ｃ（２）６、追加ＡＰＰ ＳＷ−Ｃ７内のＡＳＬ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｕｂ Ｌａｙｅｒ）１０の全てが必要となる。
なお、ＶＦＢ４は上記のような性質を持つことから、一度既存ＡＰＰ ＳＷ−Ｃ（１）５のみでＶＦＢ４を設計しプログラムコードを生成した後、ＥＣＵ１００に既存ＡＰＰ ＳＷ−Ｃ（２）６を追加しようとすると、通信バス１１の変更が必要になる。
このため、ＶＦＢ４のプログラムコードの生成後に、ＥＣＵ１００に既存ＡＰＰ ＳＷ−Ｃ（２）６を追加しようとすると、ＶＦＢ４の再設計及びプログラムコードの再生成が必要となる。

追加ＡＰＰ ＳＷ−Ｃ７は、アプリケーションモジュール８、アプリケーションモジュール９、ＡＳＬ１０で構成される。
アプリケーションモジュール８、９は、既存ＡＰＰ ＳＷ−Ｃ（１）５及び既存ＡＰＰ ＳＷ−Ｃ（２）６を通信先とするアプリケーションプログラムである。
図１ではアプリケーションモジュールを便宜的に２つ図示しているが、アプリケーションモジュール数は任意でよい。
なお、アプリケーションモジュール８、９は、ＡＰＰモジュール８、９とも表記する。
追加ＡＰＰ ＳＷ−Ｃ７の中でのＡＰＰモジュール８、９とＡＳＬ１０の関係は、ＡＳＬ１０が下位層で、ＡＰＰモジュール８、９が上位層となる。
つまり、ＡＳＬ１０は、既存ＡＰＰ ＳＷ−Ｃ（１）５及び既存ＡＰＰ ＳＷ−Ｃ（２）６を通信先とするＡＰＰモジュール８、９と対応付けられている。
なお、既存ＡＰＰ ＳＷ−Ｃ（１）５及び既存ＡＰＰ ＳＷ−Ｃ（２）６は、通信先ソフトウェアコンポーネントの例に相当する。
また、ＡＳＬ１０は、データ制御部の例に相当する。

図示を省略しているが、既存ＡＰＰ ＳＷ−Ｃ（１）５及び既存ＡＰＰ ＳＷ−Ｃ（２）６にも、それぞれ１つ以上のＡＰＰモジュールが含まれている。
但し、既存ＡＰＰ ＳＷ−Ｃ（１）５及び既存ＡＰＰ ＳＷ−Ｃ（２）６には、ＡＳＬ１０に相当する下位層は含まれていない。
既存ＡＰＰ ＳＷ−Ｃ（１）５及び既存ＡＰＰ ＳＷ−Ｃ（２）６は、ＶＦＢ４の設計段階で既に存在しているＳＷ−Ｃであるため、「既存」と表記している。
一方、追加ＡＰＰ ＳＷ−Ｃ７については、ＶＦＢ４の設計段階では、ＡＳＬ１０のみが存在していればよく、ＡＰＰモジュール８、９は、ＶＦＢ４の設計完了後に追加することができるため、「追加」と表記している。

図２は、追加ＡＰＰ ＳＷ−Ｃ７内のＡＳＬ１０の詳細を示す。
ＡＳＬ１０は、図２に示すように、通信処理部１２、バッファ部１３及びＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）処理部１４から構成される。
以下では、主に、ＡＳＬ１０が、ＡＰＰモジュール９と既存ＡＰＰ ＳＷ−Ｃ（１）５との間の通信を仲介し、ＡＰＰモジュール９とミドルウェア３との間の通信を仲介する動作を説明する。
なお、ＡＳＬ１０がＡＰＰモジュール８と既存ＡＰＰ ＳＷ−Ｃ（２）６との間の通信を仲介し、ＡＰＰモジュール８とミドルウェア３との間の通信を仲介する動作では、以下の説明において、ＡＰＰモジュール９をＡＰＰモジュール８に読み替え、既存ＡＰＰ ＳＷ−Ｃ（１）５を既存ＡＰＰ ＳＷ−Ｃ（２）６に読み替える。
前述したように、ＡＰＰモジュール８とＡＰＰモジュール９は、ＡＳＬ１０をＥＣＵ１００に実装した後に、ＥＣＵ１００に実装することができる。

バッファ部１３は、既存ＡＰＰ ＳＷ−Ｃ（１）５からのデータ（ＳＷ−Ｃ（１）の公開データ）と、既存ＡＰＰ ＳＷ−Ｃ（１）５へのデータ（ＳＷ−Ｃ（１）の取得データ）とを蓄積する。
また、バッファ部１３は、ミドルウェア３からのデータ（ミドルウェアの公開データ）と、ミドルウェア３へのデータ（ミドルウェアの取得データ）とを蓄積する。
なお、図２及び以下の説明では、便宜上、バッファ部１３にＳＷ−Ｃ（１）の公開データ、ＳＷ−Ｃ（１）の取得データ、ミドルウェアの公開データ及びミドルウェアの取得データが記憶されている例を示しているが、物理的には、ＲＡＭ５０６内の記憶領域であるバッファ領域にＳＷ−Ｃ（１）の公開データ、ＳＷ−Ｃ（１）の取得データ、ミドルウェアの公開データ及びミドルウェアの取得データが記憶される。
つまり、バッファ部１３は、厳密には、ＳＷ−Ｃ（１）の公開データ、ＳＷ−Ｃ（１）の取得データ、ミドルウェアの公開データ及びミドルウェアの取得データのバッファ領域への書込み及びバッファ領域からの読み出しを管理している。

通信処理部１２は、ＶＦＢ４を介して既存ＡＰＰ ＳＷ−Ｃ（１）５及びミドルウェア３と通信する。
ＶＦＢ４には、ＡＰＰモジュール９と既存ＡＰＰ ＳＷ−Ｃ（１）５との通信のための通信バス１１が設定されており、通信処理部１２は、この通信バス１１と論理的に接続されている。
通信処理部１２は、この通信バス１１を用いて、既存ＡＰＰ ＳＷ−Ｃ（１）５から送信されたデータを受信し、受信したデータをバッファ部１３に格納する。
また、通信処理部１２は、バッファ部１３から既存ＡＰＰ ＳＷ−Ｃ（１）５へのデータを入力し、入力したデータを、ＶＦＢ４内の前記通信バス１１を用いて、既存ＡＰＰ ＳＷ−Ｃ（１）５に送信する。
同様に、ＶＦＢ４には、ＡＰＰモジュール９とミドルウェア３との通信のための通信バス１１が設定されており、通信処理部１２は、この通信バス１１と論理的に接続されている。
通信処理部１２は、この通信バス１１を用いて、ミドルウェア３から送信されたデータを受信し、受信したデータをバッファ部１３に格納する。
また、通信処理部１２は、バッファ部１３からミドルウェア３へのデータを入力し、入力したデータを、ＶＦＢ４内の前記通信バス１１を用いて、ミドルウェア３に送信する。

ＡＰＩ処理部１４は、ＡＰＰモジュール９に対してバッファ部１３へのアクセスを可能とする。
つまり、ＡＰＩ処理部１４は、既存ＡＰＰ ＳＷ−Ｃ（１）５へのデータをＡＰＰモジュール９から入力し、入力したデータをバッファ部１３に格納する。
また、ＡＰＩ処理部１４は、既存ＡＰＰ ＳＷ−Ｃ（１）５からのデータをバッファ部１３から入力し、入力したデータをＡＰＰモジュール９に出力する。
また、ＡＰＩ処理部１４は、ミドルウェア３へのデータをＡＰＰモジュール９から入力し、入力したデータをバッファ部１３に格納する。
また、ＡＰＩ処理部１４は、ミドルウェア３からのデータをバッファ部１３から入力し、入力したデータをＡＰＰモジュール９に出力する。
ＡＰＩ処理部１４は、データ中継部の例に相当する。

以上の構成のＡＳＬ１０を例えばＥＣＵ１００の工場出荷段階でＥＣＵ１００に実装しておくことで、ＥＣＵ１００の工場出荷後にＶＦＢ４を再設計することなく、ＡＰＰモジュール９をＥＣＵ１００に追加することができる。
つまり、工場出荷前の開発段階で、ＡＰＰモジュール９と既存ＡＰＰ ＳＷ−Ｃ（１）５との間の通信のための通信バス１１及びＡＰＰモジュール９とミドルウェア３との間の通信のための通信バスをＶＦＢ４内に設定しておき、これら通信バス１１と通信処理部１２とを論理的に接続してＡＳＬ１０をＥＣＵ１００に実装する。
その後、工場出荷後にＡＰＰモジュール９をＥＣＵ１００に実装する際には、通信処理部１２がＶＦＢ４を介して既存ＡＰＰ ＳＷ−Ｃ（１）５及びミドルウェア３と通信可能になっているので、ＶＦＢ４の再設計を伴わずに、ＡＰＰモジュール９はＡＳＬ１０を用いて既存ＡＰＰ ＳＷ−Ｃ（１）５及びミドルウェア３と通信することができる。

次に、図２、図３、図１５〜図１８を用いて、追加ＡＰＰ ＳＷ−Ｃ７の動作を説明する。
なお、図２のデータＡ１〜ＡＮは既存ＡＰＰ ＳＷ−Ｃ（１）５が公開するデータ、データＢ１〜ＢＮは既存ＡＰＰ ＳＷ−Ｃ（１）５が取得するデータ、データＣ１、Ｃ２はミドルウェア３が公開するデータ、データＤ１、Ｄ２はミドルウェア３が取得するデータである。

まず、追加ＡＰＰ ＳＷ−Ｃ７は周期的に起動するものとする。
追加ＡＰＰ ＳＷ−Ｃ７は起動すると、ＡＳＬ１０の通信処理部１２が、ＶＦＢ４の通信バス１１を用いて、既存ＡＰＰ ＳＷ−Ｃ（１）５の公開データ（データＡ１〜ＡＮ）を取得する（図３のステップ１）（図１５）。
更に、ＡＳＬ１０の通信処理部１２は、取得した既存ＡＰＰ ＳＷ−Ｃ（１）５の公開データ（データＡ１〜ＡＮ）を、バッファ部１３に格納する（図３のステップ２）（図１５）。

同様に、ＡＳＬ１０の通信処理部１２が、ＶＦＢ４の通信バス１１を用いて、ミドルウェア３の公開データ（データＣ１、Ｃ２）を取得する（図３のステップ３）（図１５）。
更に、ＡＳＬ１０の通信処理部１２は、取得した既存ミドルウェア３の公開データ（データＣ１、Ｃ２）を、バッファ部１３に格納する（図３のステップ４）（図１５）。

次に、ＡＰＰモジュール９が実行される（図３のステップ５）。
この時点でＡＰＰモジュール９が実装されていなければ、ステップ５をスキップする。
なお、ミドルウェア３を介してＡＰＰモジュール９に所定のハードウェアが割り当てられている場合は、ＡＰＰモジュール９が実装されるまでは、ＡＰＰモジュール９の代わりにスタブモジュールを割り当てておく。
同様に、ＡＰＰモジュール９と連携して動作する既存ＡＰＰ ＳＷ−Ｃ（１）５に対して初期設定が必要な場合は、ＡＰＰモジュール９が実装されるまでは、ＡＰＰモジュール９の代わりにスタブモジュールを割り当てておく。
ＡＰＰモジュール９の代わりにスタブモジュールが割り当てられている場合は、以下の説明においてＡＰＰモジュール９をスタブモジュールと読み替える。
ＡＰＰモジュール９は、既存ＡＰＰ ＳＷ−Ｃ（１）５の公開データ（データＡ１〜ＡＮ）を読み出す際、ＡＰＩ処理部１４が提供するＡＰＩを使用する。
ＡＰＩ処理部１４は、ＡＰＩの内容に従って、既存ＡＰＰ ＳＷ−Ｃ（１）５の公開データ（データＡ１〜ＡＮ）をバッファ部１３より読み出してＡＰＰモジュール９に提供する（図１６）。
同様に、ＡＰＩ処理部１４は、ミドルウェア３の公開データ（データＣ１、Ｃ２）をバッファ部１３より読み出してＡＰＰモジュール９に提供する（図１６）。

また、ＡＰＰモジュール９は、既存ＡＰＰ ＳＷ−Ｃ（１）５に対し、既存ＡＰＰ ＳＷ−Ｃ（１）５の取得データ（データＢ１〜ＢＮ）を送信する場合も、ＡＰＩ処理部１４が提供するＡＰＩを使用する。
ＡＰＩ処理部１４は、ＡＰＰモジュール９が呼び出したＡＰＩの内容に従って、ＡＰＰモジュール９が生成した既存ＡＰＰ ＳＷ−Ｃ（１）５の取得データ（データＢ１〜ＢＮ）をバッファ部１３に書き込む（図３のステップ６）（図１７）。
同様に、ＡＰＩ処理部１４は、ＡＰＰモジュール９が生成したミドルウェア３の取得データ（データＤ１、Ｄ２）をバッファ部１３に書き込む（図３のステップ６）（図１７）。

次に、ＡＳＬ１０の通信処理部１２が、既存ＡＰＰ ＳＷ−Ｃ（１）５の取得データ（データＢ１〜ＢＮ）をバッファ部１３から読み出し、ＶＦＢ４の通信バス１１を用いて、既存ＡＰＰ ＳＷ−Ｃ（１）５に送信する（図３のステップ７）（図１８）。

同様に、ＡＳＬ１０の通信処理部１２がミドルウェア３の取得データ（データＤ１、Ｄ２）をバッファ部１３から読み出し、ＶＦＢ４の通信バス１１を用いて、ミドルウェア３に送信する（図３のステップ８）（図１８）。

なお、図３に示す各ステップの実行順序を変更してもよい。
例えば、ステップ１→ステップ２→ステップ５→ステップ６→ステップ８→ステップ３→ステップ４→ステップ５→ステップ６→ステップ７という順序で各ステップを実行してもよい。

ステップ１、３、７、８は、ステップ５の実行結果に関わらず、またバッファ部１３の値に関わらず常に実行するものとする。
このような動作とすることで、ＶＦＢ４の通信バス１１に関連するステップ１、３、７、８の処理は、ステップ５の内容に依存しない構成となる。

次に、ＶＦＢ４内の追加ＡＰＰ ＳＷ−Ｃ７が利用する通信バス１１の設計方法について説明する。
ＶＦＢ４内の追加ＡＰＰ ＳＷ−Ｃ７が利用する通信バス１１は、図３のステップ１、ステップ３、ステップ７、ステップ８の処理で利用される。
追加ＡＰＰ ＳＷ−Ｃ７と既存ＡＰＰ ＳＷとの通信に着目すると、ＶＦＢ４内の追加ＡＰＰ ＳＷ−Ｃ７が利用する通信バス１１では、既存ＡＰＰ ＳＷ−Ｃ（１）５の公開データ及び取得データ、既存ＡＰＰ ＳＷ−Ｃ（２）６の公開データ及び取得データが送受信される。
既存ＡＰＰ ＳＷ−Ｃ（１）５の公開データ及び取得データ、既存ＡＰＰ ＳＷ−Ｃ（２）６の公開データ及び取得データの具体例を、図４に示す。

既存ＡＰＰ ＳＷ−Ｃ（１）５には、例えば、ワイパを制御するアプリケーションモジュールが含まれており、既存ＡＰＰ ＳＷ−Ｃ（２）６には、例えば、車両のギアを制御するアプリケーションモジュールが含まれている。
既存ＡＰＰ ＳＷ−Ｃ（１）５は、公開データとしてワイパ動作状態情報を送信し、取得データとして雨状態情報を受信する。
既存ＡＰＰ ＳＷ−Ｃ（２）６は、公開データとしてギア情報を送信し、取得データとしてコーナーセンサー情報と温度情報を受信する。
そして、追加ＡＰＰ ＳＷ−Ｃ７の取得データはワイパ動作状態情報、ギア情報であり、追加ＡＰＰ ＳＷ−Ｃ７の公開データは雨状態情報、コーナーセンサー情報、温度情報である。
つまり、既存ＡＰＰ ＳＷ−Ｃ（１）５が追加ＡＰＰ ＳＷ−Ｃ７にワイパ動作状態情報を送信し、追加ＡＰＰ ＳＷ−Ｃ７が既存ＡＰＰ ＳＷ−Ｃ（１）５に雨状態情報を送信する。
また、既存ＡＰＰ ＳＷ−Ｃ（２）６が追加ＡＰＰ ＳＷ−Ｃ７にギア情報を送信し、追加ＡＰＰ ＳＷ−Ｃ７が既存ＡＰＰ ＳＷ−Ｃ（２）６にコーナーセンサー情報、温度情報を送信する。
これらの情報の組み合せを用いて、ＶＦＢ４の設計者が、追加ＡＰＰ ＳＷ−Ｃ７が利用する通信バス１１を設計する。

既存ＡＰＰ ＳＷ−Ｃ（１）５の公開データと取得データ、既存ＡＰＰ ＳＷ−Ｃ（２）６の公開データと取得データ、及び追加するＡＰＰモジュール８、９向けに割り当てられたミドルウェアの公開データと取得データから、ＶＦＢ４の設計者が、ＶＦＢ４の設計を行う。
従って、この時点で追加ＡＰＰ ＳＷ−Ｃ７に含ませるのは、ＡＳＬ１０のみである。
ＡＰＰモジュール８、９はこの時点で並行して用意してもよいし、以後に、用意してもよい。

次に、具体例として、ＥＣＵ１００にオプションとしてＡＰＰモジュール９を追加する例を用いて、既存ＡＰＰ ＳＷ−Ｃ（１）５と追加ＡＰＰ ＳＷ−Ｃ７の動作を説明する。

まず、ＡＰＰモジュール９の追加方法について説明する。
ＡＰＰモジュール９は、図１４に示す外部端末装置４１に保存しておく。
外部端末装置４１は、例えばＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの通信手段４２を介してＥＣＵ１００に接続される。
図１４のソフトウェア１及びハードウェア５０は、一部の図示を省略しているが、図１に示すソフトウェア１及びハードウェア５０である。
ソフトウェア１は、ＥＣＵ１００のハードウェア５０内の通信モジュール５０２を介して通信手段４２の先に接続される機器と通信可能である。
このような構成において、ＡＰＰモジュール９は、外部端末装置４１から追加ＡＰＰ ＳＷ−Ｃ７にアドオンされる。

次に、ＡＰＰモジュール９が追加ＡＰＰ ＳＷ−Ｃ７にアドオンされた後の動作について説明する。
以下では、既存ＡＰＰ ＳＷ−Ｃ（１）５がワイパ制御アプリケーションモジュールである例を用いて説明を進める。
既存ＡＰＰ ＳＷ−Ｃ（１）５は、Ｈｉｇｈモード（Ｈｉモードともいう）、Ｌｏｗモード、間欠モードのいずれかでワイパを動作させる。
Ｈｉモードでは、既存ＡＰＰ ＳＷ−Ｃ（１）５は、ワイパを高速で連続して動作させる。
Ｌｏｗモードでは、既存ＡＰＰ ＳＷ−Ｃ（１）５は、ワイパを低速で連続して動作させる。
間欠モードでは、既存ＡＰＰ ＳＷ−Ｃ（１）５は、ワイパを一定の間隔で間欠的に動作させる。

ＥＣＵ１００は、オプションとして雨滴検知デバイスの装着を可能とする。
雨滴検知デバイスの装着の際には、同時に雨滴検知デバイス用制御アプリケーションをＡＰＰモジュール９として追加する。
雨滴検知デバイス用制御アプリケーション（ＡＰＰモジュール９）は、雨滴検知デバイスが検出したセンサ値に応じて雨状態を算出する。
雨滴検知デバイス用制御アプリケーション（ＡＰＰモジュール９）は、ミドルウェア３から雨滴検知デバイスのセンサ値を取得して、雨状態を算出する。
既存ＡＰＰ ＳＷ−Ｃ（１）５は、雨滴検知デバイスが装着されると、雨滴検知デバイス用制御アプリケーション（ＡＰＰモジュール９）が算出した雨状態に応じて間欠モードにおけるワイパの動作周期を変える。

本例では、図５に示すように、データＡ１（図２のデータＡ１に相当）として、雨滴検知デバイス用制御アプリケーションへのリクエスト情報が、既存ＡＰＰ ＳＷ−Ｃ（１）５から追加ＡＰＰ ＳＷ−Ｃ７に送信される。
また、データＢ１（図２のデータＢ１に相当）として、雨滴検知デバイスの追加の有無情報、雨状態の有効／無効情報、雨滴検知デバイス用制御アプリケーションが提供するデータ（雨状態）が、追加ＡＰＰ ＳＷ−Ｃ７から既存ＡＰＰ ＳＷ−Ｃ（１）５に送信される。
また、データＣ１（図２のデータＣ１に相当）として、データの有効／無効情報、雨滴検知デバイスからのデータ（センサ値）が、ミドルウェア３から追加ＡＰＰ ＳＷ−Ｃ７に送信される。
また、データＤ１（図２のデータＤ１に相当）として、雨滴検知デバイスへのリクエスト情報が、追加ＡＰＰ ＳＷ−Ｃ７からミドルウェア３に送信される。

既存ＡＰＰ ＳＷ−Ｃ（１）５の動作例を図６に示す。

既存ＡＰＰ ＳＷ−Ｃ（１）５は、起動すると車両のユーザによりワイパスイッチ操作がされたかどうかをチェックする（ステップ２０）。
ワイパスイッチ操作がされている場合（ステップ２０でＹＥＳ）は、既存ＡＰＰ ＳＷ−Ｃ（１）５は、ユーザにより選択されているモードが間欠モードかどうかをチェックする（ステップ２１）。
ユーザにより選択されているモードが間欠モードでない場合（ステップ２１でＮＯ）は、既存ＡＰＰ ＳＷ−Ｃ（１）５は、ユーザにより選択されているモードがＬｏｗモードかどうかをチェックする（ステップ２２）。
ユーザにより選択されているモードがＬｏｗモードであれば（ステップ２２でＹＥＳ）既存ＡＰＰ ＳＷ−Ｃ（１）５は、Ｌｏｗモードでワイパを動作させる（ステップ２３）。
ユーザにより選択されているモードがＬｏｗモードでなければ（ステップ２２でＮＯ）既存ＡＰＰ ＳＷ−Ｃ（１）５は、Ｈｉモードでワイパを動作させる（ステップ２４）。

ユーザにより選択されているモードが間欠モードである場合（ステップ２１でＹＥＳ）は、既存ＡＰＰ ＳＷ−Ｃ（１）５は、データＡ１である雨滴検知デバイス用制御アプリケーションへのリクエスト情報に「雨状態情報の要求」を書き込む（ステップ２５）。
次に、既存ＡＰＰ ＳＷ−Ｃ（１）５は、雨滴検知デバイス用制御アプリケーションへのリクエスト情報（データＡ１）を、ＶＦＢ４内の該当する通信バス１１を介して追加ＡＰＰ ＳＷ−Ｃ７に送信する。

次に、既存ＡＰＰ ＳＷ−Ｃ（１）５は、データＢ１を受信し、データＢ１内の雨滴検知デバイスの追加の有無情報の読み出しを行う（ステップ２６）。
雨滴検知デバイスの追加の有無情報は、追加ＡＰＰ ＳＷ−Ｃ７から送信された情報である。
ＥＣＵ１００に雨滴検知デバイスが装着されていない場合は、ＡＰＰモジュール９も実装されていないため、ＡＰＰモジュール９のスタブモジュールがデータＢ１内の雨滴検知デバイスの追加の有無情報に「無」を書き込む。
既存ＡＰＰ ＳＷ−Ｃ（１）５は、データＢ１内の雨滴検知デバイスの追加の有無情報を解析して雨滴検知デバイスがＥＣＵ１００に装着されているかどうかをチェックする（ステップ２７）。
雨滴検知デバイスがＥＣＵ１００に装着されていない場合（ステップ２７でＮＯ）は、既存ＡＰＰ ＳＷ−Ｃ（１）５は、一定間隔でワイパを間欠的に動作させる（ステップ２８）。

雨滴検知デバイスがＥＣＵ１００に装着されている場合（ステップ２７でＹＥＳ）は、既存ＡＰＰ ＳＷ−Ｃ（１）５は、データＢ１内の雨状態の有効／無効情報が「有効」であるかどうかをチェックする（ステップ２９）。
データＢ１内の雨状態の有効／無効情報が「有効」であれば（ステップ２９でＹＥＳ）、既存ＡＰＰ ＳＷ−Ｃ（１）５は、データＢ１内の雨滴検知デバイス用制御アプリケーションが提供するデータ（雨状態）から「雨状態」の値を読み出し（ステップ３０）、「雨状態」の値に応じた間隔でワイパを間欠的に動作させる（ステップ３１）。
例えば、「雨状態」の値を「強」、「中」、「弱」の３段階とし、既存ＡＰＰ ＳＷ−Ｃ（１）５は、ワイパの動作周期を各段階に合わせて調整する。

次に、雨滴検知デバイス用制御アプリケーションであるＡＰＰモジュール９を含む追加ＡＰＰ ＳＷ−Ｃ７の動作例を図７に示す。

先ず、ＡＳＬ１０の通信処理部１２が、既存ＡＰＰ ＳＷ−Ｃ（１）５からのデータＡ１をＶＦＢ４の通信バス１１から受信する。
そして、バッファ部１３及びＡＰＩ処理部１４を経由して、データＡ１がＡＰＰモジュール９に入力される。
ＡＰＰモジュール９は、データＡ１の雨滴検知デバイス用制御アプリケーションへのリクエスト情報を解析して、雨滴検知デバイス用制御アプリケーションへのリクエスト情報（データＡ１）に「雨状態情報の要求」があるかどうかをチェックする（ステップ４０）。

雨滴検知デバイス用制御アプリケーションへのリクエスト情報に「雨状態情報の要求」がある場合（ステップ４０でＹＥＳ）は、ＡＰＰモジュール９は、データＤ１である雨滴検知デバイスへのリクエスト情報に「デバイス起動要求」を書き込む（ステップ４１）。
そして、ＡＰＰモジュール９は、雨滴検知デバイスへのリクエスト情報（データＤ１）をＡＰＩ処理部１４に出力し、バッファ部１３を経由して雨滴検知デバイスへのリクエスト情報（データＤ１）が通信処理部１２からＶＦＢ４を介してミドルウェア３に送信される。
なお、ここまでの処理は、図３のステップ１、ステップ２、ステップ５、ステップ６及びステップ８に相当する。

次に、通信処理部１２が、ＶＦＢ４を介して、ミドルウェア３からのデータＣ１をＶＦＢ４を介して受信し、データＣ１をバッファ部１３に格納する。
次に、ＡＰＩ処理部１４が、バッファ部１３からデータＣ１を読み出し、読み出したデータＣ１をＡＰＰモジュール９に出力する。
ＡＰＰモジュール９は、データＣ１内のデータの有効／無効情報をチェックする（ステップ４２）。
データＣ１内のデータの有効／無効情報が「無効」の場合（ステップ４２でＮＯ）は、ＡＰＰモジュール９は、データＢ１内の雨滴検知デバイスの追加の有無情報に「有」を書き込む（ステップ４３）。
更に、ＡＰＰモジュール９は、データＢ１内の雨状態の有効／無効情報に「無効」を書き込む（ステップ４４）。
なお、データＢ１内の雨滴検知デバイス用制御アプリケーションが提供するデータ（雨状態）には、なにも記述しない。
その後、データＢ１がＡＰＰモジュール９からＡＰＩ処理部１４に出力され、ＡＰＩ処理部１４及びバッファ部１３を経由して、通信処理部１２からデータＢ１がＶＦＢ４を介して既存ＡＰＰ ＳＷ−Ｃ（１）５に送信される。
なお、ここまでの処理は、図３のステップ３、ステップ４、ステップ５ステップ６及びステップ８に相当する。

一方、データＣ１内のデータの有効／無効情報をチェックした結果、データの有効／無効情報が「有効」の場合（ステップ４２でＹＥＳ）は、ＡＰＰモジュール９は、データＣ１内の雨滴検知デバイスからのデータ（センサ値）からセンサ値を読み出し（ステップ４５）、読み出したセンサ値から雨状態を算出する（ステップ４６）。
次に、ＡＰＰモジュール９は、データＢ１内の雨滴検知デバイスの追加の有無情報に「有」を書き込む（ステップ４７）。
また、ＡＰＰモジュール９は、データＢ１内の雨状態の有効／無効情報に「有効」を書き込む（ステップ４８）。
更に、ＡＰＰモジュール９は、データＢ１内の雨滴検知デバイス用制御アプリケーションが提供するデータ（雨状態）にステップ４６で算出した「雨状態」を書き込む（ステップ４９）。
その後、データＢ１がＡＰＰモジュール９からＡＰＩ処理部１４に出力され、ＡＰＩ処理部１４及びバッファ部１３を経由して、通信処理部１２からデータＢ１がＶＦＢ４を介して既存ＡＰＰ ＳＷ−Ｃ（１）５に送信される。
なお、ここまでの処理は、図３のステップ３、ステップ４、ステップ５ステップ６及びステップ８に相当する。

そして、既存ＡＰＰ ＳＷ−Ｃ（１）５では、図６のステップ２６以降の動作が行われる。

以上のように、本実施の形態では、ＡＰＰモジュール９の実装前に、ＡＰＰモジュール９と既存ＡＰＰ ＳＷ−Ｃ（１）５との間の通信のための通信バス１１及びＡＰＰモジュール９とミドルウェア３と間の通信のための通信バスをＶＦＢ４内に設定しておき、これら通信バス１１と通信処理部１２を論理的に接続してＡＳＬ１０をＥＣＵ１００に実装する。
そして、ＡＰＰモジュール９がＥＣＵ１００に実装された際には、通信処理部１２がＶＦＢ４を介して既存ＡＰＰ ＳＷ−Ｃ（１）５及びミドルウェア３と通信可能になっているので、ＶＦＢ４の再設計を伴わずに、ＡＰＰモジュール９はＡＳＬ１０を用いて既存ＡＰＰ ＳＷ−Ｃ（１）５及びミドルウェア３と通信することができる。
つまり、本実施の形態によれば、ＡＳＬ１０がＡＰＰモジュール９と既存ＡＰＰ ＳＷ−Ｃ（１）５との間に介在することで、ＶＦＢ４を変更することなく、ＡＰＰモジュール９を追加することができる。
このため、ＥＣＵ１００の開発時にＶＦＢ４の設計を一度すると、ＳＷ−Ｃの追加の際のＶＦＢ４の再設計の手間が省ける。
さらに、ＳＷ−Ｃの追加にＶＦＢ設計ツールを必要としないことから、開発から離れた実フィールドでのＥＣＵ１００の運用中においても、簡単にソフトウェア更新を行うことができる。

以上、本実施の形態では、
ソフトウェアのアーキテクチャとして、既存アプリケーションＳＷ−Ｃとは別に、追加アプリケーションＳＷ−Ｃが実装された車載装置を説明した。
そして、追加アプリケーションＳＷ−Ｃは、上位層に追加するアプリケーションモジュール、下位層にＡＳＬが配置されていることを説明した。
更に、ＡＳＬは、ＶＦＢを介して他のＳＷ−Ｃ及びミドルウェアと通信する通信処理部と、通信処理部が他のＳＷ−Ｃ及びミドルウェアから得た情報の格納及び他のＳＷ−Ｃ及びミドルウェアに対して送信する情報を格納するためのバッファ部と、アプリケーションモジュールに対してバッファ部へのアクセスを可能とするＡＰＩ処理部とを有することを説明した。

実施の形態２．
図８は、ＥＣＵ−Ａ３０で使用している既存ＡＰＰ ＳＷ−Ｃ（２）６をＥＣＵ−Ｂ３１に移植する動作を説明している。
ＥＣＵ−Ａ３０には、既存ＡＰＰ ＳＷ−Ｃ（１）５と既存ＡＰＰ ＳＷ−Ｃ（２）６の二つのＳＷ−Ｃが実装され、二つのＳＷ−ＣはＶＦＢ４を介して通信している。
ＥＣＵ−Ｂ３１には、既存ＡＰＰ ＳＷ−Ｃ（１）５と追加ＡＰＰ ＳＷ−Ｃ７の二つのＳＷ−Ｃが実装され、二つのＳＷ−ＣはＶＦＢ４を介して通信している。
追加ＡＰＰ ＳＷ−Ｃ７のＡＳＬ１０は、実施の形態１で説明したように、既存ＡＰＰ ＳＷ−Ｃ（１）５との通信に用いられる通信バス１１と論理的に接続されている。

ＥＣＵ−Ｂ３１のＶＦＢ４には、追加ＡＰＰ ＳＷ−Ｃ７のＡＳＬ１０と既存ＡＰＰ ＳＷ−Ｃ（２）６が通信を行うための通信バス１１が存在しないため、既存ＡＰＰ ＳＷ−Ｃ（２）６をＥＣＵ−Ｂ３１のＶＦＢ４に直接実装することができない。
そこで、既存ＡＰＰ ＳＷ−Ｃ（２）６は、追加ＡＰＰ ＳＷ−Ｃ７のアプリケーションモジュールとして実装する。
但し、既存ＡＰＰ ＳＷ−Ｃ（２）６が使用するＡＰＩとＡＰＩ処理部１４が提供しているＡＰＩが異なっている場合は、ＡＰＩの差異を吸収するためのＡＰＩ変換部２０を設ける。
例えば、既存ＡＰＰ ＳＷ−Ｃ（２）６はデータの読み込みに、Ｖｆｂ＿ＲｅａｄＤａｔａというＡＰＩを使用しているとする。
ＡＰＩ処理部１４は、アプリケーションモジュールに対してデータの読み込みにＡｓｌ＿ＲｅａｄＤａｔａというＡＰＩを提供しているとする。
この場合、ＡＰＩ変換部２０は、既存ＡＰＰ ＳＷ−Ｃ（２）６のソースコード内のＶｆｂ＿ＲｅａｄＤａｔａの記述をＡｓｌ＿ＲｅａｄＤａｔａに変更して、Ａｓｌ＿ＲｅａｄＤａｔａに対応した既存ＡＰＰ ＳＷ−Ｃ（２）β２１を生成する。
ＡＰＩ変換部２０が変更するのは、ソースコード中のＡＰＩの名称のみであり、既存ＡＰＰ ＳＷ−Ｃ（２）β２１の制御ロジックはＡＰＰ ＳＷ−Ｃ（２）６と同じである。
このようにすることで、ＥＣＵ−Ｂ３１は、既存ＡＰＰ ＳＷ−Ｃ（２）６の実装に際し、ＶＦＢ４を変更することなく、既存ＡＰＰ ＳＷ−Ｃ（２）６のロジック変更を行うことなく、追加ＡＰＰ ＳＷ−Ｃ７のアプリケーションモジュールとして実装することが可能となる。

ＡＰＩの変更は、車載装置の中で実施してもよい。
図９は、ＡＳＬ１０の中にＡＰＩ変換部２２を置く構成を示す。
図９のＥＣＵ−Ｂ３１は、図１のＥＣＵ１００である。
図９では、ハードウェア５０の記述及び追加ＡＰＰ ＳＷ−Ｃ７内の通信処理部１２、バッファ部１３、ＡＰＰモジュール８、９の記述は省略している。
ＡＰＩ変換部２２には、既存ＡＰＰ ＳＷ−Ｃ（２）６が使用するＡＰＩを用意しておく。
ＡＰＩ変換部２２は、既存ＡＰＰ ＳＷ−Ｃ（２）６が使用するＡＰＩを用いて既存ＡＰＰ ＳＷ−Ｃ（２）６からデータを入力し、入力したデータをＡＰＩ処理部１４が使用するＡＰＩを用いてＡＰＩ処理部１４に出力する。
また、ＡＰＩ変換部２２は、ＡＰＩ処理部１４が使用するＡＰＩを用いてＡＰＩ処理部１４からデータを入力し、入力したデータを既存ＡＰＰ ＳＷ−Ｃ（２）６が使用するＡＰＩを用いて既存ＡＰＰ ＳＷ−Ｃ（２）６に出力する。
ＡＰＩ変換部２２は、既存ＡＰＰ ＳＷ−Ｃ（２）６がデータの入出力に使用するＡＰＩを、ＡＰＩ処理部１４がデータ入出力に使用するＡＰＩに定義しなおしてもよいし、ＡＰＩ処理部１４のＡＰＩを直接呼び出してもよい。

なお、追加ＡＰＰ ＳＷ−Ｃ７に実装された既存ＡＰＰ ＳＷ−Ｃ（２）６は、指定ソフトウェアコンポーネントの例に相当する。

ＡＰＩ変換部２２によるＡＰＩの変換動作を除けば、図９の既存ＡＰＰ ＳＷ−Ｃ（１）５と既存ＡＰＰ ＳＷ−Ｃ（２）６との間の通信の手順は、実施の形態１で説明した既存ＡＰＰ ＳＷ−Ｃ（１）５とＡＰＰモジュール９との間の通信の手順と同じである。
つまり、通信処理部１２が、既存ＡＰＰ ＳＷ−Ｃ（１）５からのデータをＶＦＢ４の該当する通信バス１１から受信し、受信したデータをバッファ部１３に格納し、ＡＰＩ処理部１４がバッファ部１３から既存ＡＰＰ ＳＷ−Ｃ（１）５からのデータを入力し、入力したデータをＡＰＩ変換部２２を介して既存ＡＰＰ ＳＷ−Ｃ（２）６に出力する。
また、ＡＰＩ処理部１４が、ＡＰＩ変換部２２を介して既存ＡＰＰ ＳＷ−Ｃ（２）６からのデータを入力し、入力したデータをバッファ部１３に格納し、通信処理部１２がバッファ部１３から既存ＡＰＰ ＳＷ−Ｃ（２）６からのデータを入力し、入力したデータをＶＦＢ４の該当する通信バス１１を介して既存ＡＰＰ ＳＷ−Ｃ（１）５に送信する。

実施の形態３．
ＶＦＢ４の通信バス１１には、ＶＦＢ４を変更することなしに将来的な拡張性を持たせることが可能である。
実施の形態１で説明したＶＦＢ４では、ＡＰＰモジュールと既存ＡＰＰ ＳＷ−Ｃ（１）５との間で既定の公開データ及び取得データを通信するための通信バス１１と、ＡＰＰモジュールと既存ＡＰＰ ＳＷ−Ｃ（２）６との間で公開データ及び取得データを通信するための通信バス１１が設けられている。
これら公開データ及び取得データは、ＶＦＢ４の設計段階で定義されているデータであり、実施の形態１で説明した通信バス１１を以下では既定のバスと呼ぶ。
本実施の形態では、ＶＦＢ４の設計段階では通信対象のデータが定義されていない予備の通信バス１１を設ける。
予備の通信バス１１は、換言すると、データの内容が指定されていない通信バスである。
予備の通信バス１１を、以下では、汎用のバスと呼ぶ。

図１０は、既定のバスと汎用のバスの例を示す。
既定のバスは、通信される公開データ及び取得データが予め定義されているため、それぞれのデータに対応するデータ型でバスのフレームフォーマットが形成される。
図１０では、１ビットのデータが送受信される既定のバス、４ビットのデータが送受信される既定のバス、１バイトのデータが送受信される既定のバスが例示されている。
汎用のバスでは、適当なサイズの配列データが送受信される。
この汎用のバス内は、ＡＳＮ．１、ＪＳＯＮといった抽象構文定義でデータが送受信される。任意のプロトコルでデータを送受信しても良い。
抽象構文定義では、例えば、ペイロードデータの前にペイロードデータのデータサイズが記述されるデータサイズ情報が付加される。
抽象構文定義は、通信するＳＷ−Ｃ間で同様に解釈する必要があるため、図１１に示す通り、本実施の形態では、既存ＡＰＰ ＳＷ−Ｃ（１）５と追加ＡＰＰ ＳＷ−Ｃ７に抽象構文定義処理部３２を配置する。
なお、図１１では、ＥＣＵ１００の構成のうち、既存ＡＰＰ ＳＷ−Ｃ（１）５と追加ＡＰＰ ＳＷ−Ｃ７のみを抜き出して図示している。
また、図１１では、追加ＡＰＰ ＳＷ−Ｃ７内の通信処理部１２の図示を省略している。

既存ＡＰＰ ＳＷ−Ｃ（１）５には、図１１に示す通り、控えの公開データリスト３３を用意しておく。
控えの公開データリスト３３は、公開データとして未使用のデータであるが、将来的に公開データとして使用する可能性のあるデータの集合である。
例えば、ＥＣＵ１００に新たなアプリケーションモジュールが実装された場合に、控えの公開データリスト３３内のデータが、この新たなアプリケーションモジュールの公開データとして利用される。
控えの公開データリスト３３に含まれるデータは、例えば、パワーシート位置の情報、サイドエアバッグの搭載の有無の情報である。
なお、アプリケーションモジュールの設計ツールにも、控えの公開データリスト３３と同様のリストを配備しておく。

図１２は、ＡＰＰモジュール８が、汎用のバスを用いて、既存ＡＰＰ ＳＷ−Ｃ（１）５の持つパワーシート位置の情報（控えの公開データリスト３３内の情報）を要求するデータを送信していることを示す。
設計者は、ＡＰＰモジュール８の設計の段階で控えの公開データリスト３３を参照することで、汎用のバスを用いれば、既存ＡＰＰ ＳＷ−Ｃ（１）５からパワーシート位置の情報が取得できることがわかる。
これをもとに、設計者は、ＡＰＰモジュール８を設計する。
追加ＡＰＰ ＳＷ−Ｃ７に追加されたＡＰＰモジュール８は、ＡＰＩ処理部１４に、控えの公開データを要求するＡＰＩを用いてパワーシート位置の情報を要求する。
ＡＰＩ処理部１４は、控えの公開データを要求するＡＰＩが呼び出されたら、抽象構文定義処理部３２を用いてデータを変換し、変換後のデータをバッファ部１３の所定の位置に書き込む。
抽象構文定義処理部３２は、例えば、パワーシート位置の情報を要求するペイロードデータに、このペイロードデータのデータサイズ情報を付加する変換を行う。
通信処理部１２は、抽象構文定義処理部３２で変換されたデータをバッファ部１３から入力し、入力したデータを汎用のバスに送出する。
汎用のバスの配列データには、追加ＡＰＰ ＳＷ−Ｃ７の抽象構文定義処理部３２で変換されたデータが設定される。

既存ＡＰＰ ＳＷ−Ｃ（１）５では、汎用のバスからデータを受信し、受信したデータを既存ＡＰＰ ＳＷ−Ｃ（１）５の抽象構文定義処理部３２で変換し、データの内容を解釈する。
既存ＡＰＰ ＳＷ−Ｃ（１）５の抽象構文定義処理部３２では、例えば、受信したデータからデータサイズ情報を除去する変換を行う。
既存ＡＰＰ ＳＷ−Ｃ（１）５では、ＡＰＰモジュール８から要求されたデータが控えの公開データリスト３３にあれば応答する。
そして、抽象構文定義処理部３２は、ペイロードデータ（パワーシート位置の情報）に、このペイロードデータのデータサイズ情報を付加する変換を行う。
図１３は、既存ＡＰＰ ＳＷ−Ｃ（１）５が、汎用のバスを用いて、パワーシート位置の情報を送信していることを示す。
追加ＡＰＰ ＳＷ−Ｃ７では、通信処理部１２が汎用のバスを用いて、既存ＡＰＰ ＳＷ−Ｃ（１）５からのデータを受信し、抽象構文定義処理部３２が、受信したデータからデータサイズ情報を除去する変換を行う。
そして、通信処理部１２は変換後のデータ（パワーシート位置の情報）をバッファ部１３に格納し、ＡＰＩ処理部１４がバッファ部１３からデータ（パワーシート位置の情報）を入力し、入力したデータ（パワーシート位置の情報）をＡＰＰモジュール８に出力する。

以上の構成により、本実施の形態では、ＶＦＢ４を変更することなく、将来登場するアプリケーションモジュールに対して拡張性を持った通信バス１１を実現することができる。

以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、２つ以上を組み合わせて実施しても構わない。
あるいは、これらの実施の形態のうち、１つを部分的に実施しても構わない。
あるいは、これらの実施の形態のうち、２つ以上を部分的に組み合わせて実施しても構わない。
なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。

１ ソフトウェア、２ ドライバ、３ ミドルウェア、４ ＶＦＢ、５ 既存アプリケーションＳＷ−Ｃ（１）、６ 既存アプリケーションＳＷ−Ｃ（２）、７ 追加アプリケーションＳＷ−Ｃ、８ アプリケーションモジュール、９ アプリケーションモジュール、１０ ＡＳＬ、１１ 通信バス、１２ 通信処理部、１３ バッファ部、１４ ＡＰＩ処理部、２０ ＡＰＩ変換部、２２ ＡＰＩ変換部、３０ ＥＣＵ−Ａ、３１ ＥＣＵ−Ｂ、３２ 抽象構文定義処理部、３３ 控えの公開データリスト、５０ ハードウェア、１００ ＥＣＵ、３００ ＯＳ、５０１ ＣＰＵ、５０２ 通信モジュール、５０３ インタフェース、５０４ センサ、５０５ デバイス、５０６ ＲＡＭ、５０７ ＲＯＭ。

Claims (16)

1. 複数のソフトウェアコンポーネントが実装されている車載装置であって、
   前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントを通信先とするアプリケーションプログラムと対応付けられたデータ制御部を有し、
   前記データ制御部は、
   前記アプリケーションプログラムのＡＳＬ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｕｂ Ｌａｙｅｒ）であり、
   前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータと、前記通信先ソフトウェアコンポーネントからのデータとを蓄積するバッファ部と、
   前記バッファ部に蓄積されている前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信し、受信したデータを前記バッファ部に格納する通信処理部と、
   前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記通信先ソフトウェアコンポーネントからのデータを前記バッファ部から入力し、入力したデータを出力するデータ中継部とを有することを特徴とする車載装置。
2. 前記データ制御部は、
   前記車載装置に前記アプリケーションプログラムが実装される前に、前記アプリケーションプログラムに対応付けられて前記車載装置に実装されており、
   前記データ中継部は、
   前記車載装置に前記アプリケーションプログラムが実装された後に、
   前記アプリケーションプログラムから、前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記通信先ソフトウェアコンポーネントからのデータを前記アプリケーションプログラムに出力することを特徴とする請求項１に記載の車載装置。
3. 前記データ中継部は、
   前記車載装置に前記アプリケーションプログラムが実装される前は、
   前記アプリケーションプログラムのスタブモジュールから、前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記通信先ソフトウェアコンポーネントからのデータを前記スタブモジュールに出力することを特徴とする請求項２に記載の車載装置。
4. 前記車載装置は、
   ミドルウェアが実装されており、
   前記バッファ部は、
   前記ミドルウェアへのデータと、前記ミドルウェアからのデータとを蓄積し、
   前記通信処理部は、
   前記バッファ部に蓄積されている前記ミドルウェアへのデータを前記ミドルウェアに送信し、前記ミドルウェアから送信されたデータを受信し、受信したデータを前記バッファ部に格納し、
   前記データ中継部は、
   前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記ミドルウェアからのデータを前記バッファ部から入力し、入力したデータを出力することを特徴とする請求項１〜３のいずれかに記載の車載装置。
5. 前記データ制御部は、
   前記車載装置に前記アプリケーションプログラムが実装される前に、前記ミドルウェアに対応付けられて前記車載装置に実装されており、
   前記データ中継部は、
   前記車載装置に前記アプリケーションプログラムが実装された後に、
   前記アプリケーションプログラムから、前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記ミドルウェアからのデータを前記アプリケーションプログラムに出力することを特徴とする請求項４に記載の車載装置。
6. 前記データ中継部は、
   前記車載装置に前記アプリケーションプログラムが実装される前は、
   前記アプリケーションプログラムのスタブモジュールから、前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記バッファ部から入力した前記ミドルウェアからのデータを前記スタブモジュールに出力することを特徴とする請求項５に記載の車載装置。
7. 前記通信処理部は、
   ＡＵＴＯＳＡＲ（登録商標）（ＡＵＴｏｍｏｔｉｖｅ Ｏｐｅｎ Ｓｙｓｔｅｍ ＡＲｃｈｉｔｅｃｔｕｒｅ）のＶＦＢ（Ｖｉｒｔｕａｌ Ｆｕｎｃｔｉｏｎ Ｂｕｓ）に含まれる、前記通信先ソフトウェアコンポーネントと前記アプリケーションプログラムとの間の通信のために設定されている通信バスと接続されており、
   前記通信バスを用いて、前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信することを特徴とする請求項１〜６のいずれかに記載の車載装置。
8. 前記通信処理部は、
   ＡＵＴＯＳＡＲ（登録商標）のＶＦＢに含まれる、前記ミドルウェアと前記アプリケーションプログラムとの間の通信のために設定されている通信バスと接続されており、
   前記通信バスを用いて、前記ミドルウェアへのデータを前記ミドルウェアに送信し、前記ミドルウェアから送信されたデータを受信することを特徴とする請求項４〜６のいずれかに記載の車載装置。
9. 前記データ制御部と前記アプリケーションプログラムとによりソフトウェアコンポーネントが構成されていることを特徴とする請求項１〜８のいずれかに記載の車載装置。
10. 前記データ制御部は、
    前記複数のソフトウェアコンポーネントの中から指定された前記通信先ソフトウェアコンポーネント以外のソフトウェアコンポーネントである指定ソフトウェアコンポーネントと対応付けられ、
    前記バッファ部は、
    前記指定ソフトウェアコンポーネントから前記通信先ソフトウェアコンポーネントへのデータと、前記通信先ソフトウェアコンポーネントから前記指定ソフトウェアコンポーネントへのデータとを蓄積し、
    前記通信処理部は、
    前記バッファ部に蓄積されている前記指定ソフトウェアコンポーネントからのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信された前記指定ソフトウェアコンポーネントへのデータを受信し、受信したデータを前記バッファ部に格納し、
    前記データ中継部は、
    前記指定ソフトウェアコンポーネントから、前記通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータを前記バッファ部に格納し、前記指定ソフトウェアコンポーネントへのデータを前記バッファ部から入力し、入力したデータを前記指定ソフトウェアコンポーネントに出力することを特徴とする請求項１〜９のいずれかに記載の車載装置。
11. 前記車載装置は、更に、
    前記指定ソフトウェアコンポーネントがデータの入出力に用いるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）と、前記データ中継部がデータの入出力に用いるＡＰＩとが異なる場合に、
    前記指定ソフトウェアコンポーネントが用いるＡＰＩを用いて前記指定ソフトウェアコンポーネントからデータを入力し、入力したデータを、前記データ中継部が用いるＡＰＩを用いて前記データ中継部に出力し、
    前記データ中継部が用いるＡＰＩを用いて前記データ中継部からデータを入力し、入力したデータを、前記指定ソフトウェアコンポーネントが用いるＡＰＩを用いて前記指定ソフトウェアコンポーネントに出力するＡＰＩ変換部を有することを特徴とする請求項１０に記載の車載装置。
12. 前記通信処理部は、
    ＡＵＴＯＳＡＲ（登録商標）のＶＦＢに含まれる、通信対象のデータが定義されていない予備の通信バスを用いて、前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、前記通信先ソフトウェアコンポーネントから送信されたデータを受信することを特徴とする請求項１に記載の車載装置。
13. 複数のソフトウェアコンポーネントが実装されている車載装置で実行されるプログラムであって、
    前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントを通信先とするアプリケーションプログラムと対応付けられ、
    前記アプリケーションプログラムのＡＳＬ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｕｂ Ｌａｙｅｒ）において、
    前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータを入力し、入力したデータをバッファ領域に格納し、前記バッファ領域に格納されている前記通信先ソフトウェアコンポーネントへのデータを前記通信先ソフトウェアコンポーネントに送信し、
    前記通信先ソフトウェアコンポーネントから送信されたデータを受信し、受信したデータを前記バッファ領域に格納し、前記バッファ領域に格納されている前記通信先ソフトウェアコンポーネントからのデータを出力することを実行させることを特徴とするプログラム。
14. 複数のソフトウェアコンポーネントが実装されている車載装置であって、
    前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントを通信先とするアプリケーションプログラムと対応付けられたデータ制御部を有し、
    前記データ制御部は、
    前記アプリケーションプログラムのＡＳＬ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｕｂ Ｌａｙｅｒ）であって、前記アプリケーションプログラムと前記複数のソフトウェアコンポーネントとの間の通信を仲介するものであり、
    前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータと、前記通信先ソフトウェアコンポーネントからのデータとを蓄積するバッファ部を有することを特徴とする車載装置。
15. 複数のソフトウェアコンポーネントと、ミドルウェアとが実装されている車載装置であって、
    前記複数のソフトウェアコンポーネントの中のいずれかのソフトウェアコンポーネントまたは前記ミドルウェアを通信先とするアプリケーションプログラムと対応付けられたデータ制御部を有し、
    前記データ制御部は、
    前記アプリケーションプログラムのＡＳＬ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｕｂ Ｌａｙｅｒ）であって、前記アプリケーションプログラムと前記ソフトウェアコンポーネントまたは前記ミドルウェアとの間でデータを中継するものであり、
    前記アプリケーションプログラムの通信先のソフトウェアコンポーネントである通信先ソフトウェアコンポーネントへのデータまたは通信先ミドルウェアへのデータと、前記通信先ソフトウェアコンポーネントからのデータまたは前記通信先ミドルウェアからのデータとを蓄積するバッファ部とを有することを特徴とする車載装置。
16. 複数のソフトウェアコンポーネントと、ミドルウェアとが実装されている車載装置であって、
    前記ミドルウェアを通信先とするアプリケーションプログラムと対応付けられたデータ制御部を有し、
    前記データ制御部は、
    前記アプリケーションプログラムのＡＳＬ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｕｂ Ｌａｙｅｒ）であり、
    前記ミドルウェアへのデータと、前記ミドルウェアからのデータとを蓄積するバッファ部と、
    前記バッファ部に蓄積されている前記ミドルウェアへのデータを前記ミドルウェアに送信し、前記ミドルウェアから送信されたデータを受信し、受信したデータを前記バッファ部に格納する通信処理部と、
    前記ミドルウェアへのデータを入力し、入力したデータを前記バッファ部に格納し、前記ミドルウェアからのデータを前記バッファ部から入力し、入力したデータを出力するデータ中継部とを有することを特徴とする車載装置。

Images