"外部機器との通信を行うためのバスに接続され、複数のアプリケーションプログラムを実行する情報処理装置であって、前記複数のアプリケーションプログラムからの命令を実行する命令実行手段と、前記外部機器との通信において採用される通信プロトコルに基づく制御を行うコントローラと、前記コントローラを制御するドライバと、を備え、前記ドライバは、前記複数のアプリケーションプログラムに対応した複数のインターフェース部と、前記複数のアプリケーションプログラムからの指示を実行する共通処理部と、を有し、前記複数のアプリケーションプログラム間の通信は、前記ドライバの制御下で行われることを特徴とする、情報処理装置。請求項1に記載の情報処理装置であって、前記外部機器との通信に用いられる送信バッファ及び受信バッファを備え、前記複数のアプリケーションプログラム間の通信は、前記複数のアプリケーションプログラムのうち送信側のアプリケーションプログラムの指示により前記送信バッファに書き込まれたデータを、前記ドライバが前記受信バッファにコピーし、前記ドライバが前記複数のアプリケーションプログラムのうち受信側のアプリケーションプログラムに受信通知を行うことによって実行される、情報処理装置。請求項2に記載の情報処理装置であって、受信識別子と受信対象の関係を規定したテーブルを備え、前記ドライバは、前記送信バッファに書き込まれたデータに含まれる受信識別子を用いて前記テーブルを検索することにより、前記受信側のアプリケーションプログラムを特定する、情報処理装置。しかしながら、上記従来の制御装置においては、統合されたECUにより実行されるアプリケーションプログラム間の通信を、どのようにして行うかについての考慮がなされていない。仮に、内部バスを用いてアプリケーションプログラム間の通信を行う場合、アプリケーションプログラム毎に二重化されたハードウエアを備える必要があり、ECUの統合によるコスト低減の効果が限定的になる場合がある。本発明はこのような課題を解決するためのものであり、アプリケーションプログラム間の通信を低コストで行うことが可能な情報処理装置を提供することを、主たる目的とする。上記目的を達成するための本発明の一態様は、外部機器との通信を行うためのバスに接続され、複数のアプリケーションプログラムを実行する情報処理装置であって、前記複数のアプリケーションプログラムからの命令を実行する命令実行手段と、前記外部機器との通信において採用される通信プロトコルに基づく制御を行うコントローラと、前記コントローラを制御するドライバと、を備え、前記ドライバは、前記複数のアプリケーションプログラムに対応した複数のインターフェース部と、前記複数のアプリケーションプログラムからの指示を実行する共通処理部と、を有し、前記複数のアプリケーションプログラム間の通信は、前記ドライバの制御下で行われることを特徴とする、情報処理装置である。この本発明の一態様によれば、アプリケーションプログラム間の通信を低コストで行うことができる。本発明の一態様において、前記外部機器との通信に用いられる送信バッファ及び受信バッファを備え、前記複数のアプリケーションプログラム間の通信は、前記複数のアプリケーションプログラムのうち送信側のアプリケーションプログラムの指示により前記送信バッファに書き込まれたデータを、前記ドライバが前記受信バッファにコピーし、前記複数のアプリケーションプログラムのうち受信側のアプリケーションプログラムに受信通知を行うことによって実行されるものとしてもよい。この場合、受信識別子と受信対象の関係を規定したテーブルを備え、前記ドライバは、前記送信バッファに書き込まれたデータに含まれる受信識別子を用いて前記テーブルを検索することにより、前記受信側のアプリケーションプログラムを特定するものとしてもよい。本発明によれば、アプリケーションプログラム間の通信を低コストで行うことが可能な情報処理装置を提供することができる。以下、本発明を実施するための形態について、添付図面を参照しながら実施例を挙げて説明する。以下、図面を参照し、本発明の一実施例に係る情報処理装置1について説明する。情報処理装置1は、車両に搭載された制御装置ECUとして好適に用いられるものであるが、これに限定されず、種々の用途に適用可能である。[ハードウエア構成、基本機能]図1は、本発明の一実施例に係る情報処理装置1のハードウエア構成例である。情報処理装置1は、主要な構成として、CPU10と、プログラムメモリ20と、主記憶装置30と、CANControllerAreaNetworkコントローラ40と、CANトランシーバ50と、周辺I/O60と、周辺機器70と、を備える。また、情報処理装置1は、図示された構成の他にも、HDDHardDiskDrive等の補助記憶装置、ドライブ装置等を備えてもよい。CPU10は、例えば、プログラムカウンタ、命令フェッチユニット、命令キュー、命令発行部、汎用レジスタ、ALUArithmeticLogicUnit、MUL乗算器、DIV除算器、LSULoadStoreUnitその他の演算器を備える。CPU10は、プログラムメモリ20から命令をフェッチし、演算結果や他の機器からロードした結果等を、内蔵する汎用レジスタや主記憶装置30等に格納する。プログラムメモリ20は、例えば、ROMReadOnlyMemoryやEEPROMElectronicallyErasableandProgrammableReadOnlyMemoryである。プログラムメモリ20には、BIOS等の初期処理用プログラムの他、アプリケーションプログラムA21、アプリケーションプログラムB22以下、単にアプリA、Bと表記する、通信ミドルウエアA23、通信ミドルウエアB24、CANドライバ25、その他の各種プログラムが格納されている。各プログラムの内容については後述する。ここで、アプリケーションプログラム及び対応する通信ミドルウエア等が二個存在するのはあくまで例示であり、本発明の適用上、アプリケーションプログラム等は複数であれば如何なる個数であってもよい。主記憶装置30は、例えばRAMRandomAccessMemoryである。主記憶装置30には、アプリA、Bの演算結果等が格納されるワーキングメモリとして機能する他、送信PDUProtocolDataUnitバッファA31、送信PDUバッファB32、送信PDUフラグA33、送信PDUフラグB34、受信PDUバッファ35、受信識別子テーブル36等が格納される。以下、数値符号を省略し、単に通信ミドルウエアA、B、送信PDUバッファA、B、送信PDUフラグA、B等と表記する。送信PDUバッファA、B、送信PDUフラグA、B、及び受信PDUバッファ35は、例えば専用領域として確保された主記憶装置30上の領域である。受信識別子テーブル36は、ROM等に記憶されており、情報処理装置1の起動時等に主記憶装置にコピーされて用いられる。なお、これらのデータ領域又はデータのうち一部は、レジスタ、キャッシュメモリ、フラッシュメモリ等の他の記憶装置に設定格納されてもよい。CANコントローラ40は、CANドライバ25によって制御され、CANトランシーバ50を介して、CANバス80との間で種々のデータを送受信する。CANバス80は、例えばツイストペアケーブルであり、差動電圧方式によって信号を伝達する。CANバス80には、例えば情報処理装置1以外の車載制御装置ECUが通信ノードとして接続され、CANバス80を流れる信号を各通信ノードが参照できる構成となっている。CANバス80では、車両内通信として用いられているCANプロトコルに従って、情報の送受信が行われている。CANプロトコルでは、ビットスタッフィングルール等の特徴的なルールが採用されている。なお、CANバス80として例示した外部バスでは、CANに限らず、LINLocalInterconnectNetworkに代表される低速なボデー系通信プロトコル、MOSTMediaOrientedSystemsTransportに代表されるマルチメディア系通信プロトコル、FlexRay等の通信プロトコルが採用されても構わない。CANバス80に情報を出力する際には、CANコントローラ40は、送信PDUバッファA又はBに格納されたフレームを、NRZNon‐Return‐to‐Zero方式でシリアルの送信信号に変換し、CANトランシーバ50に出力する。CANコントローラ40は、変換後の信号が0ドミナントのビットには論理レベルがLowの電圧を、1リセッシブのビットには論理レベルがHighの電圧を出力する。CANトランシーバ50は、CANコントローラ40から取得した送信信号を差動電圧に変換してCANバス80に出力する。すなわち、CANトランシーバ50は、送信データが0の時に、Hラインの電圧をハイレベル例えば3.5[V]にするとともにLラインの電圧をローレベル例えば1.5[V]にし、送信データが1の時にHラインの電圧をローレベル例えば2.5[V]にするとともにLラインの電圧をハイレベル例えば2.5[V]にする。CANバス80から情報を取得する際には、CANトランシーバ50は、CANバス80の差動電圧を読み取り、所定の電圧範囲に含まれるように整形した受信信号をCANコントローラ40に出力する。CANコントローラ40の受信端子Rxにはコンパレータが取り付けられており、所定の閾値電圧とCANトランシーバ50からの受信信号とを比較して1、0のデジタルデータを生成して受信PDUバッファ35に格納する。周辺I/O60は、例えば周辺機器70とのインターフェースとして機能する。周辺機器70は、例えば各種車載センサに接続されたA/D変換器であり、センサ出力値をデジタル値に変換して周辺I/O60に出力する。周辺I/O60に入力されたデータはCPU10に伝達され、車両制御に用いられる。このほか、周辺機器70としては、アクチュエータ、スイッチ等が該当し得る。[ソフトウエア構成等]図2は、本発明の一実施例に係る情報処理装置1の機能構成例である。図中、破線で示すブロックはソフトウエア機能であり、実線で示すブロックはハードウエア機能である。アプリA、Bは、それぞれ異なるタスクを処理するアプリケーションである。例えば、情報処理装置1が車両のエンジン制御装置である場合、アプリAが点火時期制御を行い、アプリBがスロットル開度制御やスタータモータ制御を行う等、役割が分担されている。通信ミドルウエアA、B、及びCANドライバ25は、オペレーティングシステムの一部として機能する。CANドライバ25は、CANコントローラ40に依存する下位層のソフトウエアであり、アプリA、B及び通信ミドルウエアA、Bは、CANコントローラ40に依存しない上位層のソフトウエアである。通信ミドルウエアA、Bは、例えば、アプリA、Bからの処理要求をCANドライバ25に対応した形式に変換し、CANドライバ25に出力する。また、通信ミドルウエアA、Bは、CANドライバ25から入力されるデータを受け付け、アプリA,Bが解釈可能な形式に変換等を行なってアプリA、Bに出力する。CANドライバ25は、例えば、アプリA用インターフェース部25Aと、アプリB用インターフェース部25Bと、共通処理部25Cと、を備える。アプリA用インターフェース部25Aは、通信ミドルウエアAからの処理要求を共通処理部25Cに伝達し、共通処理部25Cから入力されるデータを通信ミドルウエアAに出力する。アプリB用インターフェース部25Bは、通信ミドルウエアBからの処理要求を共通処理部25Cに伝達し、共通処理部25Cから入力されるデータを通信ミドルウエアBに出力する。共通処理部25Cは、CANコントローラ40に対しては、CANコントローラ40を制御するためのレジスタへの書き込み等を行う。以下、CANドライバ25による送受信処理について、より詳細に説明する。CANドライバ25は、受信識別子テーブル36を参照して、データを受信するアプリケーションプログラムを特定する。図3は、受信識別子テーブル36の一例である。図中、IF-AはアプリA用インターフェース部25Aを示し、IF-BはアプリB用インターフェース部25Bを示している。すなわち、CANドライバ25は、識別子が0x10であれば、アプリA用インターフェース部25A、通信ミドルウエアAを介してアプリAにデータを受信させると共に、アプリB用インターフェース部25B、通信ミドルウエアBを介してアプリBにもデータを受信させる。また、CANドライバ25は、識別子が0x120であれば、アプリA用インターフェース部25A、通信ミドルウエアAを介してアプリAにデータを受信させる。また、CANドライバ25は、識別子が0x205であれば、アプリB用インターフェース部25B、通信ミドルウエアBを介してアプリBにデータを受信させる。受信識別子テーブル36は、いずれのアプリケーションプログラムも受信しないデータについての識別子は登録していない。これによって、テーブルのデータサイズを低減することができる。なお、CANドライバ25がテーブルを参照して受信先を特定する構成に代えて、通信ミドルウエアA、Bがそれぞれ個別にテーブルを管理し、入力されたデータに付随する識別子を判別してアプリA、Bにデータを受信させるかどうかを判断してもよい。送信PDUフラグA、Bは、例えば、何も処理を行っていないことを表すEmpty、送信中であることを表すSending、送信待ちであることを表すWaitingの三値をとり得る。CANドライバ25は、送信PDUフラグA、Bの内容を参照し、各アプリによるデータ送信段階を判別する。以下、処理フローを示しながらCANドライバ25の処理について説明する。[処理フロー]CANドライバ25は、1アプリケーションプログラムから送信指示がなされたとき、2CANコントローラ40から送信確認割り込みを受けたとき、3CANコントローラ40から受信通知割り込みを受けたときに、以下に説明する処理を行う。送信確認割り込みとは、CANコントローラ40が送信動作を完了したときにCANコントローラ40からCANドライバ25に出力される通知である。1アプリケーションプログラムから送信指示がなされたときこの場合、CANドライバ25は、送信処理を行う。図4は、CANドライバ25により実行される送信処理の流れを示すフローチャートである。ここでは、アプリAから送信指示がなされたものとするが、アプリBから送信指示がなされた場合は、フローの説明中のアプリAとアプリBをそっくり入れ替えればよい。まず、CANドライバ25は、送信PDUフラグAがEmptyであるか否かを判定するS100。CANドライバ25は、送信PDUフラグAがEmptyである場合は、アプリAから通信ミドルウエアA、アプリA用インターフェース25Aを介して入力された送信PDUデータを、送信PDUバッファAにコピーするS102。次に、CANドライバ25は、送信PDUフラグBがSendingであるか否かを判定するS104。送信PDUフラグBがSendingでない場合は、アプリBの指示によるデータ送信中ではないため、送信PDUフラグAをSendingに変更しS106、CANコントローラ40に対して送信PDUバッファAに格納されているID、長さ、データを設定し、送信のトリガーをかけるS108。送信のトリガーは、前述のように、CANコントローラ40内のレジスタに値を書き込むこと等によって行われる。一方、CANドライバ25は、送信PDUフラグBがSendingである場合は、アプリBの指示によるデータ送信中であるため、送信PDUフラグAをWaitingに変更するS110。S104でいずれの判定を得た場合も、CANドライバ25は、戻り値CAN_OKをアプリAに返すS112。CANドライバ25は、S100において送信PDUフラグAがEmptyでないと判定された場合は、戻り値CAN_BUSYをアプリAに返すS114。戻り値CAN_BUSYがアプリAに返されるのは、アプリA自身が、直前に指示した送信処理が未だ完了していない場面であり、アプリAの設計上、想定内の場面である。一方、他のアプリアプリBのための送信処理途中にアプリAから送信指示がなされた場合には、送信PDUフラグAがWaitingに変更され、後に図5のフローで待ち状態が解除されて送信が行われる。この結果、アプリAから見ると、単に処理がある程度遅延したのに過ぎず、戻り値CAN_BUSYが返されることもないため、アプリAの設計上、想定外の事象は生じない。これによって、後述する機能統合前のソフトウエアに大きな変更をすることなく、機能統合を行うことができる。2CANコントローラ40から送信確認割り込みを受けたときこの場合、CANドライバ25は、送信確認処理を行う。図5は、CANドライバ25により実行される送信確認処理の流れを示すフローチャートである。まず、CANドライバ25は、送信PDUフラグAがSendingであるか否かを判定するS200。送信PDUフラグAがSendingである場合は、図6に示す疑似受信処理Aを行うS210~S220。図6は、CANドライバ25により実行される疑似受信処理Aの流れを示すフローチャートである。疑似受信処理とは、アプリケーションプログラム間の送受信を、CANバス80を介した通信に擬して行う処理であり、これを採用することによって、後述する機能統合が容易となる。CANドライバ25は、疑似受信処理において、まず送信PDUバッファAから受信識別子を読み出しS210、読み出した受信識別子を用いて図3に示す受信識別子テーブル36を検索するS212。そして、対応行が存在するか否かを判定するS214。対応行が存在する場合、受信対象としてアプリBが指定されているか図3の例では、識別子が0x10又は0x205であるか否かを判定するS216。受信対象としてアプリBが指定されている場合、アプリAからアプリBへのデータ送信であるため、疑似受信を行う。すなわち、送信PDUバッファAに格納されたデータを受信PDUバッファ35にコピーしS218、アプリB用インターフェース部25Bを介して通信ミドルウエアBに受信通知呼び出しを行うことにより、アプリBに受信PDUバッファ35の内容を読み出させるS220。なお、本実施例ではアプリA、Bしか存在しないため、対応行が存在する=アプリBへのデータ送信であるとみなしてもよく、S216の判定は省略することができる。アプリAからアプリA自身へのデータ送信が行われることは考えにくいからである。一方、S214において対応行が存在しないと判定された場合、及びS216において受信対象としてアプリBが指定されていないと判定された場合は、疑似受信を行わない。これらを満たす場合とは、アプリAから外部機器へのデータ送信が指示されたことを意味する。CANドライバ25は、疑似受信処理Aを終了すると、CANドライバ25は、図7に示す送信確認バッファ処理Aを行うS230~S236。図7は、CANドライバ25により実行される送信確認バッファ処理Aの流れを示すフローチャートである。CANドライバ25は、送信確認バッファ処理において、まず送信PDUフラグBがWaitingであるか否かを判定するS230。送信PDUフラグBがWaitingである場合、送信PDUフラグBをSendingに変更しS232、CANコントローラ40に対して送信PDUバッファBに格納されているID、長さ、データを設定し、送信のトリガーをかけるS234。そして、送信PDUフラグAをEmptyに変更しS236、送信確認バッファ処理を終了する。S230において送信PDUフラグBがWaitingでなければ、単にS236の処理を行って送信確認バッファ処理を終了する。CANドライバ25は、送信確認バッファ処理Aを終了すると、アプリA用インターフェース部25Aを介して通信ミドルウエアAに受信通知呼び出しを行うS240。図中に呼び出し関数を例示する。S200において送信PDUフラグAがSendingでないと判定された場合、CANドライバ25は、送信PDUフラグBがSendingであるか否かを判定するS250。なお、本実施例ではアプリケーションプログラムはAとBのみであるため、S250の判定は省略しても構わない。送信PDUフラグAがSendingでない場合は、疑似受信処理Bを行いS260、次に送信確認バッファ処理Bを行うS270。疑似受信処理Bは、図6に示した疑似受信処理AにおいてAとBの関係をそっくり入れ替えたものであるため、説明を省略する。また、送信確認バッファ処理Bについても、図7に示した送信確認バッファ処理AにおいてAとBの関係をそっくり入れ替えたものであるため、説明を省略する。CANドライバ25は、送信確認バッファ処理Bを終了すると、アプリB用インターフェース部25Bを介して通信ミドルウエアBに受信通知呼び出しを行うS280。3CANコントローラ40から受信通知割り込みを受けたときこの場合、CANドライバ25は、受信処理を行う。図8は、CANドライバ25により実行される受信処理の流れを示すフローチャートである。まず、CANドライバ25は、CANコントローラ40の受信データをロックするS300。次に、CANドライバ25は、CANコントローラ40から受信識別子を読み出しS302、読み出した受信識別子を用いて図3に示す受信識別子テーブル36を検索するS304。そして、対応行が存在するか否かを判定するS306。対応行が存在する場合、CANコントローラ40の受信データを受信PDUバッファ35にコピーするS308。そして、受信対象としてアプリAが指定されているか図3の例では、識別子が0x10又は0x120であるか否かを判定するS310。受信対象としてアプリAが指定されている場合、アプリA用インターフェース部25Aを介して通信ミドルウエアAに受信通知呼び出しを行うことにより、アプリAに受信PDUバッファ35の内容を読み出させるS312。続いて、CANドライバ25は、受信対象としてアプリBが指定されているか図3の例では、識別子が0x10又は0x205であるか否かを判定するS314。受信対象としてアプリBが指定されている場合、アプリB用インターフェース部25Bを介して通信ミドルウエアBに受信通知呼び出しを行うことにより、アプリBに受信PDUバッファ35の内容を読み出させるS316。そして、CANドライバ25は、CANコントローラ40の受信データを解放しS318、受信処理を終了する。ここで、図4~8のフローを実行する前に、CANドライバ25は、CANコントローラ40を送受信可能な状態に遷移させる必要がある。CANドライバ25の共通処理部25Cは、アプリA用インターフェース部25A又はアプリB用インターフェース部25Bが受け付けたアプリA又はBからの指示によって、CANドライバ25及びCANコントローラ40の状態を図9に示すように遷移させる。図9は、アプリケーションプログラムからの指示によるCANドライバ25及びCANコントローラ40の状態遷移を示す図である。アプリA、Bは、CANドライバ25に対して、例えば図中Scoreと表記した状態指示信号を送信する。CANドライバ25は、アプリA、Bから受信したScoreのうち最も値の大きいものに対応する状態に、CANドライバ25及びCANコントローラ40の状態を遷移させる。なお、上記処理フローは、アプリ間の通信であってもCANバス80にデータを出力するCANバス80からの受信はしない処理の流れとなっているが、CANドライバ25及びCANコントローラ40の設定によって、係るデータ出力をしない構成としてもよい。例えば、CANドライバ25が受信識別子を判別して内部通信であると判定した場合には、CANコントローラ40に対して所定領域のレジスタ書き込み等を行い、これを受けたCANコントローラ40は、CANバス80へのデータ出力を行わず送信確認割り込みを擬似的に行うように設定してもよい。また、上記処理フローは、InnerPriorityInversionの問題について考慮していないが、係る問題は、アプリA用インターフェース部25A、アプリB用インターフェース部25Bの下位層に位置づけられる機能によって解決できる。具体的には、送信PDUバッファA、Bをそれぞれ多重化し、送信時にはバッファ上にあるWaiting状態のデータ間で優先順位を判定して最も優先順位の高いデータをCANコントローラ40に設定して送信トリガをかけ、Sending状態に移行させる。また、Sending状態のデータについても、バッファ上にあるWaiting状態のデータ中で、Sending状態のデータよりも優先順位が高いデータが存在する場合には、Sending状態のデータの送信を中止し、優先順位の高いデータをCANコントローラ40に設定して送信トリガをかけ、Sending状態に移行させてもよい。[機能統合との関係]本実施例の情報処理装置1は、前述のように、元々別体として存在していた複数の制御装置等以下、ECUと称するを一個の装置に統合した統合ECUに、好適に適用される。図10は、統合前の複数のECUの接続関係を例示した図である。図示するように、統合前の構成では、ECU_A、ECU_B、ECU‐CがCANバスに接続され、CANバスによってECU間の通信が可能な構成となっている。係る構成では、各ECUは、それぞれ通信ミドルウエア、CANドライバ、CANコントローラ、CANトランシーバを備えている。図11は、本実施例とは異なるアーキテクチャによりECU_AとECU_Bを統合した場合の統合ECUの構成を例示した図である。係る構成では、ECU_A、ECU_Bに搭載されていたアプリA、Bは、それぞれ専用の通信ミドルウエア、CANドライバ、CANコントローラを備えており、CANトランシーバのみが共通化されている。この結果、通信ミドルウエアやCANドライバに関しては統合前後で余り修正を加える必要が無いものの、CANコントローラを二個備えることにより、コスト低減の効果が十分でない。更に、図11の構成では、アプリAからアプリBにデータ送信する場合、内部バス80を備える必要がある。CANトランシーバは共通化されているため、アプリAのための送信動作と、アプリBのための受信動作を同時に行うことができないからである。このように、内部バスを備える必要性等が、ECUの統合においてコスト低減の面からネックとなる場合があった。図11における太線矢印は、アプリ間の通信の流れを示し、太線破線の矢印は、統合ECUと他のECUとの間の通信の流れを示している。図12は、本実施例の情報処理装置1によるアプリ間の通信の流れ等を示している。図12における太線矢印は、アプリ間の通信の流れを示し、太線破線の矢印は、統合ECUと他のECUとの間の通信の流れを示している。また、図13は、本実施例の情報処理装置1を、統合ECUとして実現するための開発処理の流れを示すフローチャートである。まず、ECU_Aが実行していたアプリケーションプログラム及び通信ミドルウエアを抽出しS400、次いでECU_Bが実行していたアプリケーションプログラム及び通信ミドルウエアを抽出するS402。次に、マイコン初期設定をコーディングするS404。係る処理は、CANドライバ25におけるアプリケーションプログラム及び通信ミドルウエアの設定部分を含む。次に、CANドライバ25と、抽出したソフトウエアと、初期設定部分を対象マイコンに実装するS406。そして、動作確認を行いS408、開発処理を終了する。[まとめ]本実施例の情報処理装置1では、上位層のアプリA、B及び通信ミドルウエアA、Bに関しては統合前のものに余り修正を加える必要が無く、CANドライバ25にのみ特徴的な修正を加えることでアプリケーションプログラム間の通信を実現することができる。また、内部バスを用いる必要が無く、メモリ上に設定されたバッファやフラグを用いてアプリケーションプログラム間の通信を行うため、アプリケーションプログラム間の通信を低コストで実現することができる。更に、本実施例の情報処理装置1では、受信識別子テーブル36を用いてCANドライバ25が受信アプリの判別を行うため、上位層の通信ミドルウエアが受信可否の判別をする必要が無く、上位層のソフトウエア負荷を軽減することができる。以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。"