車両制御装置、データ通信方法
【課題】統合前のソフトウェアの修正を抑制して複数のＥＣＵが統合された車両制御装置等を提供すること。
【解決手段】第１のコアが実行する第１のアプリと第２のコアが実行する第２のアプリがそれぞれ外部にデータを送信する車両制御装置１００であって、バス３９を介して外部の機器と通信するため通信手段３６と、第1のコアと第２のコアの間でデータ通信する内部通信手段３７と、第２のアプリの第１の送信データを通信手段でなく内部通信手段に出力する出力先変更手段３４（２）と、内部通信手段から取得した第１の送信データを第１のアプリ又は前記通信手段のどちらに出力するかを、前記第１の送信データの送信先情報が登録されたリストテーブルに従い制御するデータ送信先制御手段３４（１）と、を有することを特徴とする。
【解決手段】第１のコアが実行する第１のアプリと第２のコアが実行する第２のアプリがそれぞれ外部にデータを送信する車両制御装置１００であって、バス３９を介して外部の機器と通信するため通信手段３６と、第1のコアと第２のコアの間でデータ通信する内部通信手段３７と、第２のアプリの第１の送信データを通信手段でなく内部通信手段に出力する出力先変更手段３４（２）と、内部通信手段から取得した第１の送信データを第１のアプリ又は前記通信手段のどちらに出力するかを、前記第１の送信データの送信先情報が登録されたリストテーブルに従い制御するデータ送信先制御手段３４（１）と、を有することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車載装置を制御するＥＣＵに関し、特に、複数のＥＣＵが統合された統合ＥＣＵに関する。
【背景技術】
【０００２】
車載されるＥＣＵ（electronic control unit）の数を低減することでＥＣＵの開発費を抑制することができるが、この場合、それまでは別々のＥＣＵに搭載されていたアプリを１つのＥＣＵに搭載する必要が生じる。
【０００３】
図１（ａ）は、ＥＣＵの統合により生じる不都合を説明する図の一例である。ＥＣＵαはマイコン上でアプリＡを、ＥＣＵβはマイコン上でアプリＢをそれぞれ実行している。アプリＡとアプリＢの下部のＲＴＥ（Runtime Environment）はアプリＡ、Ｂが利用する共通の機能を提供したり、アプリ間でデータやイベントを受け渡すレイヤである。
【０００４】
ＲＴＥの下のレイヤはＣＡＮ通信の通信内容に対応した通信モジュールであり、ＣＯＭ、ＮＭ及びＤｉａｇＣＡＮが図示されている。ＣＯＭは一般のデータを通信するモジュールであり、ＮＭはネットワークマネージメント機能を司るモジュールであり、ＤｉａｇＣＡＮはサービスツール（ディーラーの工場などでＣＡＮバスに外部から接続される診断ツール）からのダイアグ情報の要求に対しアプリからダイアグ情報を取得するモジュールである。なお、ＭＣＡＬ（Microcontroller Abstraction Layer）は各種のドライバの集合でありソフトウェア側からハードウェアを隠蔽している。
【０００５】
図１（ｂ）は、ＥＣＵαとＥＣＵβが１つのＥＣＵに統合されたＥＣＵγの構成例を示す。アプリＡ側のＭＣＡＬ及びアプリＢ側のＭＣＡＬは、ＣＯＭ、ＮＭ又はＤｉａｇＣＡＮのいずれかの要求に応じて、ＣＡＮバスにフレームを出力する。図１（ｂ）のようにＥＣＵの統合のためＥＣＵγにチャネルを２つ以上設けておけば、２つのＭＣＡＬはそれぞれＣＡＮバスにＣＡＮフレームを出力できるが、現実には制約が多い。例えば、ＥＣＵαやβのＮＭは機能の一つとして、ＣＡＮバス上の他のＥＣＵにＮＭフレームを定期的に送信する機能を有する。これにより、ＥＣＵγからＮＭフレームを受信できなかった他のＥＣＵは、ＥＣＵγが故障していることを検出できる。このため、規格や社内規定において、ＮＭメッセージは１つのＥＣＵから１つしかＣＡＮバスに出力してはいけないと定められることがある。
【０００６】
この不都合を回避するため、統合時に例えばＥＣＵβのＮＭだけを開発者が削除することが考えらえる。しかし、アプリＡやアプリＢは、元々、ＮＭに対しスリープしてよい状態であることを通知する機能を有しており、逆にＮＭは（他のＥＣＵのＮＭからＮＭメッセージを受信して）アプリＡ、Ｂに対し起床を要求する必要がある。このことは、アプリＡ,ＢはＮＭのＡＰＩ(Application Programming Interface)がないと動作できないことを意味しており、ＮＭだけを削除することが困難であることを意味している（ＮＭを削除するとアプリＡ，Ｂの修正が必要になる）。
【０００７】
ここで、既存のソフトウェアの修正を行うことなく又は修正を抑制して、ソフトウェアの移植性を高める技術が考案されている（例えば、特許文献１参照。）。特許文献１には、シングルプロセッサ用の複数のプログラムを複数のプロセッサに分散した場合に、各プロセッサに各プログラムの疑似部を設け、異なるプロセッサに分散したプログラムと疑似部を介して通信するプロセッサ間通信方式が開示されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平５−３２４５７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、特許文献１に開示されたプロセッサ間通信方式を採用すると、開発者は、元のシングルプロセッサが実行していたプログラムの数だけ疑似部を作成する必要があり、プログラムの数が多くなるほど開発コストが大きくなるという問題が解消されない。また、新しいプログラムを統合することが考慮されておらず、新しいプログラムを統合する場合に、すでに存在するプログラムの疑似部との関係を構築するための開発コストが多大になるおそれがある。
【００１０】
本発明は、上記課題に鑑み、統合前のソフトウェアの修正を抑制して複数のＥＣＵが統合された車両制御装置等を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、第１のコアが実行する第１のアプリと第２のコアが実行する第２のアプリがそれぞれ外部にデータを送信する車両制御装置であって、バスを介して外部の機器と通信するため通信手段と、前記第1のコアと前記第２のコアの間でデータ通信する内部通信手段と、前記第２のアプリの第１の送信データを前記通信手段でなく前記内部通信手段に出力する出力先変更手段と、前記内部通信手段から取得した前記第１の送信データを前記第１のアプリ又は前記通信手段のどちらに出力するかを、前記第１の送信データの送信先情報が登録されたリストテーブルに従い制御するデータ送信先制御手段と、を有することを特徴とする。
【発明の効果】
【００１２】
統合前のソフトウェアの修正を抑制して複数のＥＣＵが統合された車両制御装置等を提供することができる。
【図面の簡単な説明】
【００１３】
【図１】ＥＣＵの統合により生じる不都合を説明する図の一例である。
【図２】統合ＥＣＵに統合されたアプリの通信方法を説明する図の一例である。
【図３】統合ＥＣＵのハードウェア構成図の一例である。
【図４】２つのＥＣＵα、βが統合された１つの統合ＥＣＵの機能ブロック図の一例である。
【図５】ＰＤＵルータが呼び出すドライバとデータの宛先の関係が登録されたドライバテーブルの一例である。
【図６】ＰＤＵルータ１とＰＤＵルータ２がデータを送信又は受信する手順を示すフローチャート図の一例である。
【図７】アプリＡ〜ＣがＲＴＥを介して通信する場合のＥＣＵの構成例を示す図の一例である。
【図８】２つのＥＣＵα、βが統合された１つの統合ＥＣＵの機能ブロック図の一例である（実施例２）。
【図９】ＩＰＣ-ＩＦ／ＩＰＣドライバが通信する手順を模式的に示す図の一例である。
【図１０】ＰＤＵルータ１とＰＤＵルータ２がデータを送信又は受信する手順を示すフローチャート図の一例である（実施例２）。
【図１１】データフローを説明する図の一例である。
【図１２】マルチマイコンの機能ブロック図の一例である。
【図１３】マルチマイコンの機能ブロック図の一例である。
【図１４】ＰＤＵルータ１とＰＤＵルータ２がデータを送信又は受信する手順を示すフローチャート図の一例である（実施例３）。
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための形態について図面を参照しながら説明する。
図２は統合ＥＣＵ１００に統合されたコア同士の通信方法を説明する図の一例である。図２の統合ＥＣＵ（electronic control unit）１００では、ＣＯＭ、ＮＭ及びＤｉａｇＣＡＮ（これらを通信モジュール３３という場合がある）のレイヤとＭＣＡＬ３５（区別する場合ＭＣＡＬ１，２という）のレイヤの間に、ＰＤＵルータ（Protocol Data Unit Router）３４が設けられている。ＰＤＵルータ（区別する場合ＰＤＵルータ１，２という）は、通信データのルーティングを行うレイヤである。
【００１５】
また、ＭＣＡＬ３５にはＤＭＡコントローラ３７に通信を要求するＤＭＡドライバ３８（区別する場合ＤＭＡドライバ１，２という）が配置されている。ＤＭＡドライバ３８は従来のＭＣＡＬにも備えられているが、図２のＤＭＡドライバ３８は統合ＥＣＵ１００においてアプリ３１（区別する場合アプリＡ、Ｂという）間でデータ通信が可能になるように設計されている。
【００１６】
例えば通信モジュール３３がＰＤＵルータ２に通信データの送信を要求すると、ＰＤＵルータ２は送信先がアプリＡであることから、ＤＭＡドライバ２を呼び出す。すなわち、ＣＡＮドライバでなくＤＭＡドライバ２を呼び出すことで、ＤＭＡコントローラ３７がデータを転送し、コア３６（区別する場合コア１，２という）が他方のコア３６と通信することができるようになる。コア２から見ると、ＣＡＮバス３９の代わりに実際には存在しない仮想ＣＡＮバス４０に通信データを出力する態様になる。
【００１７】
アプリＡ側のＤＭＡドライバ１はＤＭＡコントローラ３７の割込み等によりデータを受信したことを検出して、データをＰＤＵルータ１に送信する。ＰＤＵルータ１は送信先がアプリＡであることから、ＲＴＥ３２（区別する場合ＲＴＥ１，２という）を経由してアプリＡにデータを送信する。
【００１８】
また、例えば、アプリＢのデータの宛先が他のＥＣＵである場合、アプリＡ側のＤＭＡドライバ１がデータをＰＤＵルータ１に送信すると、ＰＤＵルータ１は宛先が他のＥＣＵであることからＣＡＮドライバを呼び出す。ＣＡＮドライバを呼び出すことで、ＣＡＮコントローラ２９は、ＣＡＮバス３９にデータを出力することができる。
【００１９】
このように、統合した２つのアプリ側にＰＤＵルータ１，２及びＤＭＡドライバ１，２をそれぞれ設けＤＭＡコントローラ３７を利用することで、アプリＡ,Ｂや通信モジュール３３を修正することなく、アプリＡ、Ｂ間で通信することができる。また、例えば、アプリＢ側のＮＭ２が出力するＮＭメッセージはＣＡＮバス３９から出力されないので、１つのＥＣＵからＮＭメッセージは１つしか出力されないようにすることができる。
【００２０】
〔構成〕
図３は、統合ＥＣＵ１００のハードウェア構成図の一例を示す。統合ＥＣＵ１００は、マルチレイヤバス１４を介して接続されたプロセッサ１１、ＤＭＡコントローラ３７、ＳＤＲＡＭ１２、ＣＡＮコントローラ２９、Ｉ／Ｏ１６及びＲＯＭ１３を有する。プロセッサ１１は、２つのＣＰＵ（以下、区別する場合ＣＰＵ１、２という）１５を有するが、ＣＰＵ１５の数は２つ以上であれば４つ以上でもよい。各ＣＰＵ１、２は、コア３６、コア間通信部２１、及び、ローカルＲＡＭ３６を有する。各ＣＰＵ１、２の機能を区別するため、ＣＰＵ内の各機能にＣＰＵ１、２と同じ番号を付す。
【００２１】
コア１、２は、ＰＣ（プログラムカウンタ）、命令バッファ、ＩＦＵ（Instruction Fetch Unit）、ＤＥＣ（DECoder）、ＲＦ（Register Fetch）、ＲＥＧ（REGister）、ＳＨ（Shifter）、ＡＬＵ、ＭＵＬ及びＦＰＵ等の演算回路、汎用レジスタ、及び、ロード／ストアユニット等を有する。これらが１クロック毎に命令実行段階の各ステージを実行することでいわゆるパイプライン制御が実現されている。
【００２２】
ＲＯＭ１３にはアプリＡ〜Ｃ及びＰＦ（Plat Form）２４が記憶されている。アプリＡ、Ｂは２つのＥＣＵα、βが統合される前の一方のＥＣＵαに搭載されていたアプリであり、アプリＣは他方のＥＣＵβに搭載されていたアプリである。ＰＦ２４は、ハードウェアの違いを吸収してアプリＡ〜Ｃをコア１，２が実行するための実行環境を提供する。本実施例では、ＡＵＴＯＳＡＲ（AUTomotive Open System Architecture）で標準化されている基本ソフトウェアを例にして説明するが、ハードウェアの違いを隠蔽可能であれば単純なＯＳとすることもできる。
【００２３】
ＰＦ２４は、上層から、ＲＴＥ、サービス層、ＥＣＵ抽象化層、及び、ＭＣＡＬ（マイクロコントローラ抽象化層）等の各レイヤによって構成される。サービス層は、ハードウェアから独立した、様々なサービスを提供する層であり、ＯＳ（例えば、ＯＳＥＫ（Open system together with interfaces for automotive electronics）やその他、組み込み用ＯＳ、リアルタイムＯＳ等）、システムサービス（診断ソフト、メモリ管理ソフト等）、メモリサービス、通信サービス（車載ＬＡＮの通信のためのネットワーク管理ソフト（ＣＡＮ、ＦｌｅｘＲａｙ，ＬＩＮ等））を有する。上記のＣＯＭ、ＮＭ及びＤｉａｇＣＡＮの通信モジュール３３はサービス層に含まれる。
【００２４】
ＥＣＵ抽象化層は、搭載機器、メモリハードウェア、通信ハードウェア、及び、Ｉ／Ｏハードウェア等、ＥＣＵの全ての基本コンポーネントを抽象化する。最下層のＭＣＡＬは、ＥＣＵのマイコンの全ての機能と周辺機器を抽象化する層である。ＭＣＡＬより上位のレイヤはマイコンのハードウェアから独立している。ＭＣＡＬは、上記のＤＭＡドライバ３８の他、例えば、メモリドライバ、通信ドライバ及びＩ／Ｏドライバを有する。
【００２５】
図ではＰＦ２４は１つとしたが、統合前のコアやマイコンの種類が異なっている場合、統合前のＰＦ２４も異なっている場合があるので、その場合はそれぞれのＰＦ２４をＲＯＭ１３に記憶しておく。
【００２６】
コア１は、ＲＯＭ１３に記憶されたＰＦ２４、アプリＡ，Ｂを実行し、コア２は、ＲＯＭ１３に記憶されたＰＦ２４、アプリＣを実行する。ローカルＲＡＭ１はコア１に専用のメモリ（一次キャッシュ）であり、ローカルＲＡＭ２はコア２に専用のメモリである。ＳＤＲＡＭ１２は、コア１、２にプログラム又はデータを提供するためのメモリ（二次キャッシュ）である。ＳＤＲＡＭ１２の少なくとも一部はコア１、２により共有される。
【００２７】
コア間通信部１、２は、コア通信バス１６を介してコア１、２が相互に割り込んだり、通信することを可能にする。コア１、２は、コア間通信部１、２により、他のコアの異常の有無を監視したり、ローカルＲＡＭ１，２を介してデータを相互に通信することができる。なお、コア１〜３は、マルチレイヤバス１４を経由して互いに通信することもできる。
【００２８】
マルチレイヤバス１４はＣＰＵ１用、ＣＰＵ２用、及び、ＤＭＡコントローラ３７の読み書き用の計４層のレイヤを備える。ＤＭＡコントローラ３７はマルチレイヤバス１４に接続された各ブロックからのＳＤＲＡＭ１２へのアクセス要求を調停すると共に、ＳＤＲＡＭ１２からローカルＲＡＭ１、２へ（又は、ローカルＲＡＭ１、２からＳＤＲＡＭ）へ、Ｉ／Ｏ１６からＳＤＲＡＭ１２へ（又はＳＤＲＡＭからＩ／Ｏへ）、コア１，２を介在することなくデータを転送する。ＤＭＡコントローラ３７は転送終了によりコア１、２に適宜割込みをかけることできる。
【００２９】
ＣＡＮコントローラ２９はＣＡＮプロトコルに従って通信処理を行う通信コントローラであり、この他、ＦｌｅｘＲａｙやＬＩＮ用の通信コントローラを有していてもよい。Ｉ／Ｏ１６はマイコンと外部の機器を接続するインタフェースであり、各種のセンサ、アクチュエータ等が接続される。
【実施例１】
【００３０】
図４は、２つのＥＣＵα、βが統合された１つの統合ＥＣＵ１００の機能ブロック図の一例である。
【００３１】
アプリＡとアプリＢは、一方が他方の演算結果を利用するようなアプリでもよいし、アプリＢは単なるアイドルタスクのようにアプリＡとＢの結びつきが弱くてもよい。前者の場合、アプリＡ又はＢがＲＴＥ３２を介してイベントやデータを通知することで、互いに呼び出して実行される。アプリＣは、ＥＣＵβに特有のアプリであるが、アプリＡ、Ｂがボデー系ならアプリＣもボデー系のように結びつきの強いアプリであってもよいし、関連のないアプリでもよい。
【００３２】
通信モジュール３３はＣＯＭ、ＮＭ及びＤｉａｇＣＡＮを有し、図１において説明したとおり、ＣＯＭは一般のデータを、ＮＭはネットワークマネージメント機能のためのデータを、ＤｉａｇＣＡＮはサービスツールに必要なデータを、それぞれ送受信するモジュールである。これら通信モジュールは、プロトコルに応じた（例えばＣＡＮ、ＦｌｅｘＲａｙ、Ｌｉｎ）通信の処理を行う。そして、さらに通信モジュールは、ＣＯＭ、ＮＭ、ＤｉａｇＣＡＮなど、通信モジュールに定められたフォーマットでＣＡＮフレーム等を作成する。また、受信時には、ＣＡＮＩＤに基づき受信すべきデータを選択的に受信する。ＣＯＭ、ＮＭ及びＤｉａｇＣＡＮのどの通信モジュールが処理すべきかはＣＡＮＩＤから判定される。
【００３３】
なお、ＮＭはＯＳＥＫ／ＶＤＸ―ＮＭ（Network Management）の規定に基づく通信を行うモジュールである。ＯＳＥＫ−ＮＭでは、１つの車載ＬＡＮに接続された各ＥＣＵが、自身のスリープ可否を判別して、そのスリープ可否を示すＮＭ（Network Management）メッセージを定期的にネットワークバスへ送信するように規定されている。なお、ＮＭメッセージはＣＡＮのメッセージの一表現に過ぎず、フォーマットや送信手順はＣＡＮプロトコルに従うが、周期的に送信されるなどの特徴があるのでＯＳＥＫ−ＮＭに基づくメッセージをＮＭメッセージという。
【００３４】
ＮＭ１，２は、予め定められた周期毎に、アプリＡ、Ｂ又はＣがスリープ可能か否かの判定を行い、スリープ可否を示すＮＭメッセージを、決まった順番で他のＥＣＵに送信する。各ＥＣＵは、ＮＭメッセージを受信すると、他の各ＥＣＵがスリープ可否を記憶しておき、車載ＬＡＮに接続された全てのＥＣＵがスリープ可になると、スリープモードへ移行する処理を開始する。したがって、スリープモードに入っていないのに、自身が受信すべき他のＥＣＵからＮＭメッセージを受信しないことで、他のＥＣＵに異常があることを検出できる。
【００３５】
なお、ＮＭはＮＭメッセージの他にＮＳ（Network Status）メッセージを送信することもがあるが、ＮＭメッセージと同様に取り扱うことができるので省略する。
【００３６】
ＰＤＵルータ３４は、データの送信先を制御する。ＣＡＮコントローラ２９を制御することができるコア１のＰＤＵルータ１と、直接はＣＡＮコントローラ２９を制御できないコア２のＰＤＵルータ２とで機能が異なる。
【００３７】
データの送信時、ＰＤＵルータ２は、ＣＡＮドライバ３８を呼び出せないので、全てのＣＡＮフレームを機械的にＰＤＵルータ１に転送する必要がある。ＰＤＵルータ２はＣＯＭ、ＮＭ及びＤｉａｇＣＡＮのいずれの通信モジュールから通信を要求されても、ＤＭＡドライバ２を呼び出す。
【００３８】
ＰＤＵルータ２がＤＭＡドライバ２からデータを受信した場合は、宛先は通信モジュール３３のいずれかであるので、通信モジュール３３にデータを転送する。
【００３９】
なお、コア２が４つめのアプリＤを実行する場合も、コア２はＣＡＮコントローラ３７を制御できないので、ＰＤＵルータ２の機能は同様である。
【００４０】
次にＰＤＵルータ１について説明する。
・ＰＤＵルータ１の送信時
ＰＤＵルータ１がＣＯＭ、ＮＭ及びＤｉａｇＣＡＮのいずれかの通信モジュール３３からデータの送信を要求された場合、ＣＡＮバス３９に出力するだけでは、ＥＣＵβが受信していたデータをコア２が受信できない。このため、ＰＤＵルータ１は、データの送信時、ＣＡＮドライバ１とＤＭＡドライバ１の両方を呼び出す。データを受信するか否かは、コア２の通信モジュール３３が判定すればよい。
【００４１】
また、統合前のＥＣＵβが受信していたＣＡＮＩＤをリストアップしておき、ＰＤＵルータ１がそのＣＡＮＩＤのデータの送信を受け付けた場合には、ＤＭＡドライバ１を呼び出すようにしてもよい。
・ＰＤＵルータ１の受信時
ＰＤＵルータ１がデータを受信するのはＣＡＮドライバ経由とＤＭＡドライバ１経由の場合がある。ＣＡＮドライバ経由でデータを受信した場合、統合前と同様に、ＣＡＮフレームは受信バッファなどに記憶され、ＣＯＭ、ＮＭ及びＤｉａｇＣＡＮ等の通信モジュール３３が受信すべきか否かを判定する。したがって、ＰＤＵルータ１はＣＡＮドライバ経由で受信した全てのデータを通信モジュール３３に出力する。
【００４２】
また、通信モジュール３３に出力するだけでは、統合前にＥＣＵβがＥＣＵαから受信していたデータをコア２が受信できない。このため、ＰＤＵルータ１は、ＣＡＮドライバ経由でデータを受信した際、ＤＭＡドライバ１にデータを出力する。データを受信するか否かは、コア２の通信モジュール３３が判定すればよい。この場合も、統合前のＥＣＵβが受信していたＣＡＮＩＤをリストアップしておき、ＰＤＵルータ１がそのＣＡＮＩＤのデータの送信を受け付けた場合にだけ、ＤＭＡドライバ１を呼び出すようにしてもよい。
【００４３】
ＤＭＡドライバ１経由でデータを受信した場合、ＰＤＵルータ１は少なくともＮＭメッセージをＣＡＮバスに出力することを禁止する。このため、開発者などが予めＣＡＮバスに転送してよいＣＡＮフレーム（又は転送してはいけないＣＡＮフレーム）を転送リストテーブルに登録しておく。
【００４４】
図５は、転送リストテーブルの一例を示す。転送リストテーブルには、転送してはいけないＣＡＮＩＤが登録されている。このＣＡＮＩＤにはＮＭメッセージのＣＡＮＩＤが含まれることになる。ＰＤＵルータ１は、ＤＭＡドライバ１経由でデータを受信した際、転送リストテーブルにより転送が禁止されていないデータのみＣＡＮドライバを呼び出してＣＡＮバス３９に転送する。
【００４５】
また、ＣＡＮバス３９に出力するだけでは、統合前にＥＣＵαがＥＣＵβから受信していたデータをコア１が受信できない。このため、ＰＤＵルータ１は、ＤＭＡドライバ１経由でデータを受信した際、通信モジュール３３にデータを出力する。データを受信するか否かは、コア１の通信モジュール３３が判定すればよい。
【００４６】
ＣＡＮドライバは統合前と変更がない。ＣＡＮドライバは、ハードウェアであるＣＡＮコントローラ２９から独立したインターフェイスであり、ＣＡＮコントローラ２９の初期化、ＣＡＮメッセージの送信・受信、などの基本的な機能を提供する。
【００４７】
ＤＭＡドライバ１，２は、ハードウェアであるＤＭＡコントローラ３７から独立したインターフェイスであり、ＤＭＡコントローラ３７にデータの送信を実行させ、ＤＭＡコントローラ３７が転送したデータを受信する。
【００４８】
ＤＭＡドライバ１は、通信モジュールから取得したデータをローカルＲＡＭ１に記憶している。したがって、このデータをローカルＲＡＭ２に送信すれば、コア１からコア２にデータを転送したことになる。ＤＭＡドライバ２の場合はこの逆になる。ローカルＲＡＭ１，２のいずれも、ＣＡＮフレームを送信する送信バッファ、及び、受信バッファのアドレスは予め定められている。送信バッファ及び受信バッファはいずれもＦＩＦＯ形式のバッファである。
【００４９】
ＤＭＡドライバ３８は、ＰＤＵルータ３４から呼び出された際に、ＳＤＲＡＭ１２を介してローカルＲＡＭ１からローカルＲＡＭ２へ（又は、その逆に）データを転送できるように修正されている。
【００５０】
ＤＭＡドライバ１は、ローカルＲＡＭ１の送信バッファの先頭アドレスを、ＤＭＡコントローラ３７の転送元アドレスレジスタに、データ長などから必要な転送回数をＤＭＡコントローラ３７の転送回数レジスタに（又は転送終了アドレスレジスタにＣＡＮフレームの最後のアドレスを設定してもよい）、ＳＤＲＡＭ１２の共有領域の先頭アドレスを、ＤＭＡコントローラ３７の転送先アドレスレジスタに、それぞれ設定し、ＤＭＡコントローラ３７に送信させる。
【００５１】
ＤＭＡコントローラ３７は転送が終了すると、コア２に割り込みして通知するので、コア２のＤＭＡドライバ２は、ＳＤＲＡＭ１２の共有領域からＣＡＮフレームを読み出すことができる。
【００５２】
ＤＭＡドライバ２の場合も同様である。ＤＭＡドライバ２は、ＰＤＵルータ２から取得したＣＡＮフレームをローカルＲＡＭ２に記憶している。ＤＭＡドライバ２は、ローカルＲＡＭ２の送信バッファの先頭アドレスを、ＤＭＡコントローラ３７の転送元アドレスレジスタに、データ長などから必要な転送回数をＤＭＡコントローラ３７の転送回数レジスタに、ＳＤＲＡＭ１２の共有領域の先頭アドレスを、ＤＭＡコントローラ３７の転送先アドレスレジスタに、それぞれ設定し、送信させる。
【００５３】
ＤＭＡコントローラ３７は転送が終了すると、コア２に割り込みして通知するので、コア２のＤＭＡドライバ２は、ＳＤＲＡＭ１２の共有領域からＣＡＮフレームを読み出すことができる。
【００５４】
なお、ＳＤＲＡＭ１２を経由することなく、ローカルＲＡＭ１、２間でデータを転送してもよい。この場合、ＤＭＡドライバ３８の代わりに、コア間通信部２１のドライバを使用するなど、コア間通信に必要なドライバを用いればよい。
【００５５】
以上のように、ＰＤＵルータ１，２とＤＭＡドライバ３８を修正するだけで、アプリＡ，Ｂの可搬性や損なうことなく、２つのＥＣＵα、βを統合することができる。
【００５６】
＜動作手順＞
図６は、ＰＤＵルータ１とＰＤＵルータ２がデータを送信又は受信する手順を示すフローチャート図の一例である。図６の手順はＰＤＵルータ１又はＰＤＵルータ２がデータを取得するとスタートする。
【００５７】
ＰＤＵルータ１から説明する。まず、ＰＤＵルータ１がデータを取得する（Ｓ１０）。データを取得する場合には、アプリＡ又はアプリＢから送信用のデータを取得する場合と、ＣＡＮドライバ１又はＤＭＡドライバ１から受信用のデータを取得する場合がある。送信時か受信時かは、ＰＤＵルータ１がアプリ側又はドライバ側のどちらからデータを取得したかにより判定される。
【００５８】
データの受信時（Ｓ２０のＹｅｓ）、ＰＤＵルータ１はＤＭＡドライバ１からデータを取得したか否かを判定する（Ｓ３０）。
【００５９】
ＤＭＡドライバ１からデータを取得した場合（Ｓ３０のＹｅｓ）、ＰＤＵルータ１はＮＭメッセージの転送を禁止するため、転送リストテーブルを参照し、送信禁止のデータを除き、ＣＡＮドライバを呼び出してＣＡＮバスに転送する（Ｓ４０）。
【００６０】
続いて、ＰＤＵルータ１は、ＤＭＡドライバ１から取得したかＣＡＮドライバから取得したかに関係なく、データを通信モジュール３３に出力する（Ｓ５０）。通信モジュール３３は、ＣＡＮＩＤに基づき受信が必要か否かを判定し、必要な場合はＲＴＥ３２を介してアプリＡ又はアプリＢに出力する。
【００６１】
また、ＰＤＵルータ１がＣＡＮドライバから取得したデータはアプリＣ宛の可能性もあるので、ＰＤＵルータ１はＤＭＡドライバ１を呼び出す（Ｓ６０）。これにより、ＤＭＡドライバ１がＤＭＡコントローラ３７を用いてＤＭＡドライバ２にデータを送信する。
【００６２】
データの送信時（Ｓ２０のＮｏ）、ＰＤＵルータ１は、ＣＡＮドライバを呼び出す（Ｓ７０）。これにより、ＣＡＮドライバ１がＣＡＮコントローラ２９を用いてＣＡＮバス３９にデータを送信する。
【００６３】
また、ＰＤＵルータ１が取得した送信用のデータがアプリＣ宛の可能性があるので、ＰＤＵルータ１はＤＭＡドライバ１を呼び出す（Ｓ８０）。これにより、ＤＭＡドライバ１がＤＭＡコントローラ３７を用いてＤＭＡドライバ２にデータを送信する。
【００６４】
次に、ＰＤＵルータ２について説明する。まず、ＰＤＵルータ２がデータを取得する（Ｓ１１０）。ＰＤＵルータ２がデータを取得する場合には、アプリＣから送信用のデータを取得する場合と、ＤＭＡドライバ２から受信用のデータを取得する場合がある。送信時か受信時かは、ＰＤＵルータ２がアプリ側又はドライバ側のどちらからデータを取得したかにより判定される。
【００６５】
データの受信時（Ｓ１１０のＹｅｓ）、ＰＤＵルータ２はデータを通信モジュール３３に出力する（Ｓ１２０）。通信モジュール３３は、ＣＡＮＩＤに基づき受信が必要か否かを判定する。
【００６６】
データの送信時（Ｓ１１０のＮｏ）、ＰＤＵルータ２はＤＭＡドライバ２を呼び出す（Ｓ１３０）。これにより、ＤＭＡドライバ２がＤＭＡコントローラ３７を用いてＤＭＡドライバ１にデータを送信する。
【００６７】
＜効果＞
以上のような統合ＥＣＵ１００によれば、アプリＣが送信したＮＭメッセージはアプリＡ又はアプリＢには送信されても、ＣＡＮバス３９には出力されないので１つのＥＣＵから出力されるＮＭメッセージを１つにすることができる。
【００６８】
また、アプリＡ〜Ｃを修正する必要がなく、修正の対象をＤＭＡドライバ１，２やＰＤＵルータ１、２に限定することができる。したがって、アプリＡ〜Ｃの可搬性を保つことができる。
【００６９】
また、この他の効果としてＣＰＵ１５の利用効率が低下しにくいという効果がある。
図７（ａ）はアプリＡ〜ＣがＲＴＥ３２を介して通信する場合の統合ＥＣＵの構成例を示す図の一例である。ＲＴＥ３２にはイベントやデータをアプリ間で送受信する機能があるので、図示するようにＤＭＡドライバ１，２を用いることなく、２つのＥＣＵを統合することも可能である。
【００７０】
アプリＡはアプリＢと、アプリＡはアプリＣとＲＴＥを介して通信することができる。また、ＣＡＮバス３９から通信モジュール（ＣＯＭ）が受信したデータは、通信モジュールがＲＴＥ３２を介してアプリＣに送信することもできる。しかしながら、ＲＴＥ３２で統合による全ての影響を吸収する方法を採用した場合、アプリＡ、Ｂがコア２のローカルＲＡＭ２に、アプリＣがコア１のローカルＲＡＭ１にアクセスすることを意味しており、アプリＡ〜Ｃに排他制御が必要であることを意味する。排他されたアプリは実行されない（処理を進行できない）ので、ＣＰＵ１５の利用効率が低下する。これに対し、本実施例の統合ＥＣＵ１００ではこのような不都合をもたらすことがない。
【００７１】
また、統合ＥＣＵ１００の消費電力の低消費電力化が図れるという効果がある。
図７（ｂ）は４つのコア１〜４とアプリＡ〜Ｈの関係を模式的に示す図の一例である。コア１はアプリＡ、Ｂを、コア２はアプリＣ、Ｄを、コア３はアプリＥ、Ｆを、コア４はアプリＧ、Ｈを、それぞれ実行する。例えば、アプリＤはアプリＥ，Ｆとしか通信せず、アプリＣはアプリＦとしか通信しない場合（外部とも通信しない）、コア２とコア３の中で通信が完結する。このため、アプリＣ、Ｄ、Ｅ、Ｆでスリープ条件が成立した場合、コア２，３を停止させることができ、低消費電力化を達成しやすい。より具体的には図7（ａ）のようにＲＴＥ３２がアプリＣ、Ｄ、Ｅ、Ｆ間の通信を担うと、アプリＣ、Ｄ、Ｅ、Ｆがスリープ条件を満たしても、通信のためにＲＴＥ３２は起動しておく必要があるので、コア２，３を停止させることができず、低消費電力化が図れない。本実施例ではコア単位でＲＴＥ３２も停止しておくことができるので、統合ＥＣＵ１００の消費電力を低減することが容易になる。
【実施例２】
【００７２】
実施例１ではＤＭＡドライバ１，２によりコア間通信を行うことで統合ＥＣＵ１００を構成した。本実施例では、ＩＰＣ-ＩＦ４１／ＩＰＣドライバ４２によりコア間通信を統合ＥＣＵ１００について説明する。
【００７３】
図８は、２つのＥＣＵα、βを統合して得られた１つの統合ＥＣＵ１００の機能ブロック図の一例である。図８において図４と同一部の説明は省略する。図８ではＤＭＡドライバ１の代わりにＩＰＣ-ＩＦ（InterProcess Communication Inter Face）１／ＩＰＣ（（InterProcess Communication）ドライバ１が、ＤＭＡドライバ２の代わりにＩＰＣ-ＩＦ２／ＩＰＣドライバ２が、配置されている。
【００７４】
また、ＤＭＡコントローラ３７の代わりにローカルＲＡＭ１が配置されている。図８の構成ではコア１とコア２は、ＦＩＦＯ形式の送信キュー、受信キュー、及び、ローカルＲＡＭ１を介して通信する。
【００７５】
ＩＰＣ-ＩＦ４１は送信キュー４３へのデータの登録機能と受信キューにデータが届いた場合にアプリ側に受信完了通知を出力する。
ＩＰＣドライバ４２は、
・送信キューにストックされたデータをローカルＲＡＭ１に登録する。
・共有ＲＡＭにストックされたデータを受信キューに書き込む。
【００７６】
図９は、ＩＰＣ-ＩＦ１／ＩＰＣドライバ１とＩＰＣ-ＩＦ２／ＩＰＣドライバ２とが通信する手順を模式的に示す図の一例である。図９はＮＭの周期的な通信を例にしている。図９（ａ）はコア１からコア２への送信手順を、図９（ｂ）はコア２からコア１への送信手順をそれぞれ示す。
【００７７】
図９（ａ）に基づき説明する。
（１）まず、ＮＭ１からＰＤＵルータ１に送信登録するとＰＤＵルータ内で静的に設定されたＣＡＮＩＤのルーティング情報を元にＩＰＣ-ＩＦ１側にデータを登録する。
（２）コア１のＰＤＵルータ１はＩＰＣドライバ１を起床させる。
（３）ＩＰＣドライバ１は送信キュー４３のデータを読み出しローカルＲＡＭ１に記憶する。
（４）コア２のＰＤＵルータ２はＩＰＣドライバ２を起床させる。
（５）ＩＰＣドライバ２はローカルＲＡＭ１のデータを読み出し、ＰＤＵルータ２にデータを登録する。ＰＤＵルータ側では静的に設定されたＣＡＮＩＤのルーティング情報を元にＩＰＣ-ＩＦ２の受信キュー４４に登録する。
（６）ＰＤＵルータ２は、ＮＭ２に受信完了通知を通知する。
【００７８】
図９（ｂ）は手順が逆になるだけなので説明を省略する。図９（ａ）と（ｂ）のいずれもローカルＲＡＭ１を共有ＲＡＭとして使用しているので、なんらかの排他制御が必要になるが。本実施例では、例えばセマフォを利用し、ＩＰＣドライバ１，２のうちセマフォを取得した方がローカルＲＡＭ１の使用権を得るようになっている。
【００７９】
図１０は、ＰＤＵルータ１とＰＤＵルータ２がデータを送信又は受信する手順を示すフローチャート図の一例である。図１０の手順は図６の手順とほぼ同じであり、ＰＤＵルータ３４がＤＭＡドライバ３８を呼び出すか、ＩＰＣ-ＩＦ４１／ＩＰＣドライバ４２を呼び出すかが異なるだけである。
【００８０】
このように、アプリ間（プロセス間）の通信を可能にするドライバであれば、ＤＭＡコントローラ３７を用いる必要はなく、実施例１と同様にアプリ間の通信が可能な統合ＥＣＵ１００を実現することができる。
【００８１】
図１１は、データフローを説明する図の一例である。図１１では通信モジュール３３のＣＯＭが通信する手順を例にしている。
・アプリＢ→アプリＡ
（Ａ１）アプリＣが送信すべきデータｄａｔａ_ａを生成したため、ＲＴＥ３２を介してＣＯＭに送信する。なお、「共通ＣＳ（Communication Stack）」は各コアで共通の、ＣＯＭやＩＰＣ-ＩＦ４１、ＩＰＣドライバ４２を使用した通信処理を行う機能（ソフトウェア）である。
（Ａ２）ＣＯＭはメッセージを生成し、ＰＤＵルータ２に送信する。
（Ａ３）ＰＤＵルータ２は、メッセージをＩＰＣ-ＩＦ２の送信キュー４３に登録する。
（Ａ４）ＩＰＣドライバ２は送信キュー４３からメッセージを読み出してローカルＲＡＭ１に書き込む。
（Ａ５）ＩＰＣドライバ１はローカルＲＡＭ１からメッセージを読み出し、ＩＰＣ-ＩＦ１の受信キュー４４に登録する。
（Ａ６）ＩＰＣ-ＩＦ１は受信完了通知とメッセージをＰＤＵルータ１に通知する。ＰＤＵルータはデータを振り分けることができるが、図では通信モジュール３３のＣＯＭ側にデータを出力している。
（Ａ７）ＣＯＭ１はデータをアプリＡに出力する。
・アプリＡ→ＣＡＮバス
（Ｂ１）アプリＡが送信すべきデータｄａｔａ_ｂを生成した場合、ＲＴＥ１を介してＣＯＭ１に送信する。
（Ｂ２）ＣＯＭ１はメッセージを生成し、ＰＤＵルータ１に出力する。
（Ｂ３）ＰＤＵルータ１は、メッセージＢをＣＡＮ Ｉ／Ｆ４５とＩＰＣ-ＩＦ１に出力する。図では、ＩＰＣ−ＩＦ１側への出力は省略した。なお、ＣＡＮ
Ｉ／Ｆ４５は、送信キューへのデータの登録機能と受信キューにデータが届いた場合にＰＤＵルータ１側に受信完了通知を出力する
（Ｂ４）ＣＡＮ Ｉ／Ｆ４５はＣＡＮドライバにメッセージＢを出力する。
（Ｂ５）ＣＡＮドライバは、ＣＡＮコントローラ２９を使用してフレームＢをＣＡＮバス３９に出力する。
【００８２】
以上のように、ＤＭＡコントローラ３７を用いなくても、ＩＰＣ-ＩＦ４１／ＩＰＣドライバ４２を用いることで、実施例１と同様に、１つのＥＣＵから出力されるＮＭメッセージを１つにすることができ、アプリＡ〜Ｃの可搬性を保つことができる。また、ＣＰＵ１５の利用効率を低下させることがなく、消費電力も低減しやすい。
【実施例３】
【００８３】
実施例１，２では複数のＥＣＵを、マルチコア型のプロセッサを備えた１つマイコンに統合して１つの統合ＥＣＵ１００を実現した。本実施例では、複数のマイコンを１つのＥＣＵに統合した統合ＥＣＵ１００について説明する。マイコンという枠組みを残したままの統合ＥＣＵ１００には２つの構成がある。
【００８４】
図１２は、マルチマイコンの機能ブロック図の一例である。図１２において図４と同一部の説明は省略する。図１２では、統合ＥＣＵ１００にマイコン５１（区別する場合マイコン１，２という）が搭載されたので、最下層にマイコン１，２が配置されている。マイコン１，２はＤＭＡコントローラ３７により通信するものとするが、マイコン１，２が通信可能であれば共有メモリ（ＩＰＣ-ＩＦ４１／ＩＰＣドライバ４２）、専用の通信線などを介して通信してもよい。図１２のようなマルチマイコンの場合の通信手順は実施例１と同様なので説明は省略する。
【００８５】
図１３は、マルチマイコンの機能ブロック図の一例である。図１３において図４と同一部の説明は省略する。１つのマイコン５１は、通常、複数個のチャネルを有するので、マイコン２側のチャネルの１つをＤＭＡコントローラ３７に割り当てても、チェネルが余る。また、ＮＭメッセージ以外は、１つのＥＣＵが複数個出力しても問題がない。そこで、マイコン２のもう１つのチェネルをＣＡＮコントローラ２９に割り当てる。こうすることで、マイコン１と２は、ＮＭメッセージだけを統合ＥＣＵ１００内で処理すればよいことになる。
【００８６】
すなわち、ＰＤＵルータ２は、ＣＡＮＩＤからＮＭメッセージと判定される場合、又は、通信モジュール３３からデータを受け付けた場合、ＤＭＡドライバ２を呼び出し、それ以外の場合はＣＡＮドライバ２を呼び出す。ＰＤＵルータ１のＤＭＡドライバ１は、実施例１と同様にデータを受信してＰＤＵルータ１に出力する。ＰＤＵルータ１はＮＭメッセージであるのでＣＡＮバス３９に出力することなく、通信モジュール３３にだけデータを出力する。こうすることで、２つのマイコン１，２を有する統合ＥＣＵ１００でも、複数のＮＭメッセージをＣＡＮバス３９に出力することを防止できる。
【００８７】
また、マイコン１及び２の双方がＣＡＮコントローラ２９を有するので、ＰＤＵルータ１は、ＤＭＡドライバ１により内部的にマイコン２と通信することも、ＣＡＮバス３９を介してマイコン２と通信することもできる。マイコン２との通信を、統合前と同様にＣＡＮバス３９を使用するように設計すれば、ＰＤＵルータ１、２が必要なＣＡＮフレームの振り分けをさらに少なくできる。
【００８８】
図１４は、ＰＤＵルータ１とＰＤＵルータ２がデータを送信又は受信する手順を示すフローチャート図の一例である。図１４の手順のうち図６の手順と異なるステップを説明する。
【００８９】
まず、実施例１と同様に、データの受信時、ＰＤＵルータ１はＤＭＡドライバ１からデータを取得した場合（Ｓ３０のＹｅｓ）、ＰＤＵルータ１はＮＭメッセージの転送を禁止するため、転送リストテーブルを参照し、送信禁止のデータを除き、ＣＡＮドライバを呼び出してＣＡＮバス３９に転送する（Ｓ４０）。
【００９０】
また、ＰＤＵルータ１は、ＤＭＡドライバ１から取得したかＣＡＮドライバから取得したかに関係なく、データを通信モジュール３３に出力する（Ｓ５０）。この後、実施例１と異なり、マイコン２がＣＡＮコントローラ２を有しているので、アプリＣ宛のデータはマイコン２が直接受信する。このため、ＰＤＵルータ１がＤＭＡドライバ１を呼び出す必要はない。
【００９１】
データの送信時（Ｓ２０のＮｏ）も同様で、ＰＤＵルータ１はＣＡＮドライバを呼び出すが（Ｓ８０）、アプリＣ宛のデータはＣＡＮバス経由でマイコン２に送信すればよいので、ＰＤＵルータ１がＤＭＡドライバ１を呼び出す必要がない。
【００９２】
ＰＤＵルータ２の場合、データの受信時（Ｓ１２０のＹｅｓ）、ＰＤＵルータ２はデータを通信モジュール３３に出力する（Ｓ１３０）ので、受信時に変更はない。
【００９３】
データの送信時（Ｓ１２０のＮｏ）、ＰＤＵルータ２はＭＮデータをＤＭＡドライバ２に振り分けるため、データがＮＭメッセージか否かを判定する（Ｓ１２５）。そして、ＰＤＵルータ２はＭＮメッセージの場合だけ、ＤＭＡドライバ２を呼び出す（Ｓ１４０）。また、ＰＤＵルータ２はＭＮメッセージ以外のデータの場合、ＣＡＮドライバ２を呼び出す（Ｓ１５０）。これにより、マイコン２はＮＭメッセージだけを内部的にマイコン１に送信することができる。
【００９４】
このように、マルチマイコンの場合、実施例１，２と同様に統合後のアプリが通信することもできるし、実施例１，２よりも容易にアプリの通信を実現することもできる。
【符号の説明】
【００９５】
１１ プロセッサ ２２ ローカルＲＡＭ ２９ ＣＡＮコントローラ
３１ アプリ ３２ ＲＴＥ ３３ 通信モジュール
３４ ＰＤＵルータ ３５ ＭＣＡＬ ３６ コア
３７ ＤＭＡコントローラ ３８ ＤＭＡドライバ
３９ ＣＡＮバス ４０ 仮想ＣＡＮバス ５１ マイコン
１００ 統合ＥＣＵ
【技術分野】
【０００１】
本発明は、車載装置を制御するＥＣＵに関し、特に、複数のＥＣＵが統合された統合ＥＣＵに関する。
【背景技術】
【０００２】
車載されるＥＣＵ（electronic control unit）の数を低減することでＥＣＵの開発費を抑制することができるが、この場合、それまでは別々のＥＣＵに搭載されていたアプリを１つのＥＣＵに搭載する必要が生じる。
【０００３】
図１（ａ）は、ＥＣＵの統合により生じる不都合を説明する図の一例である。ＥＣＵαはマイコン上でアプリＡを、ＥＣＵβはマイコン上でアプリＢをそれぞれ実行している。アプリＡとアプリＢの下部のＲＴＥ（Runtime Environment）はアプリＡ、Ｂが利用する共通の機能を提供したり、アプリ間でデータやイベントを受け渡すレイヤである。
【０００４】
ＲＴＥの下のレイヤはＣＡＮ通信の通信内容に対応した通信モジュールであり、ＣＯＭ、ＮＭ及びＤｉａｇＣＡＮが図示されている。ＣＯＭは一般のデータを通信するモジュールであり、ＮＭはネットワークマネージメント機能を司るモジュールであり、ＤｉａｇＣＡＮはサービスツール（ディーラーの工場などでＣＡＮバスに外部から接続される診断ツール）からのダイアグ情報の要求に対しアプリからダイアグ情報を取得するモジュールである。なお、ＭＣＡＬ（Microcontroller Abstraction Layer）は各種のドライバの集合でありソフトウェア側からハードウェアを隠蔽している。
【０００５】
図１（ｂ）は、ＥＣＵαとＥＣＵβが１つのＥＣＵに統合されたＥＣＵγの構成例を示す。アプリＡ側のＭＣＡＬ及びアプリＢ側のＭＣＡＬは、ＣＯＭ、ＮＭ又はＤｉａｇＣＡＮのいずれかの要求に応じて、ＣＡＮバスにフレームを出力する。図１（ｂ）のようにＥＣＵの統合のためＥＣＵγにチャネルを２つ以上設けておけば、２つのＭＣＡＬはそれぞれＣＡＮバスにＣＡＮフレームを出力できるが、現実には制約が多い。例えば、ＥＣＵαやβのＮＭは機能の一つとして、ＣＡＮバス上の他のＥＣＵにＮＭフレームを定期的に送信する機能を有する。これにより、ＥＣＵγからＮＭフレームを受信できなかった他のＥＣＵは、ＥＣＵγが故障していることを検出できる。このため、規格や社内規定において、ＮＭメッセージは１つのＥＣＵから１つしかＣＡＮバスに出力してはいけないと定められることがある。
【０００６】
この不都合を回避するため、統合時に例えばＥＣＵβのＮＭだけを開発者が削除することが考えらえる。しかし、アプリＡやアプリＢは、元々、ＮＭに対しスリープしてよい状態であることを通知する機能を有しており、逆にＮＭは（他のＥＣＵのＮＭからＮＭメッセージを受信して）アプリＡ、Ｂに対し起床を要求する必要がある。このことは、アプリＡ,ＢはＮＭのＡＰＩ(Application Programming Interface)がないと動作できないことを意味しており、ＮＭだけを削除することが困難であることを意味している（ＮＭを削除するとアプリＡ，Ｂの修正が必要になる）。
【０００７】
ここで、既存のソフトウェアの修正を行うことなく又は修正を抑制して、ソフトウェアの移植性を高める技術が考案されている（例えば、特許文献１参照。）。特許文献１には、シングルプロセッサ用の複数のプログラムを複数のプロセッサに分散した場合に、各プロセッサに各プログラムの疑似部を設け、異なるプロセッサに分散したプログラムと疑似部を介して通信するプロセッサ間通信方式が開示されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開平５−３２４５７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、特許文献１に開示されたプロセッサ間通信方式を採用すると、開発者は、元のシングルプロセッサが実行していたプログラムの数だけ疑似部を作成する必要があり、プログラムの数が多くなるほど開発コストが大きくなるという問題が解消されない。また、新しいプログラムを統合することが考慮されておらず、新しいプログラムを統合する場合に、すでに存在するプログラムの疑似部との関係を構築するための開発コストが多大になるおそれがある。
【００１０】
本発明は、上記課題に鑑み、統合前のソフトウェアの修正を抑制して複数のＥＣＵが統合された車両制御装置等を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、第１のコアが実行する第１のアプリと第２のコアが実行する第２のアプリがそれぞれ外部にデータを送信する車両制御装置であって、バスを介して外部の機器と通信するため通信手段と、前記第1のコアと前記第２のコアの間でデータ通信する内部通信手段と、前記第２のアプリの第１の送信データを前記通信手段でなく前記内部通信手段に出力する出力先変更手段と、前記内部通信手段から取得した前記第１の送信データを前記第１のアプリ又は前記通信手段のどちらに出力するかを、前記第１の送信データの送信先情報が登録されたリストテーブルに従い制御するデータ送信先制御手段と、を有することを特徴とする。
【発明の効果】
【００１２】
統合前のソフトウェアの修正を抑制して複数のＥＣＵが統合された車両制御装置等を提供することができる。
【図面の簡単な説明】
【００１３】
【図１】ＥＣＵの統合により生じる不都合を説明する図の一例である。
【図２】統合ＥＣＵに統合されたアプリの通信方法を説明する図の一例である。
【図３】統合ＥＣＵのハードウェア構成図の一例である。
【図４】２つのＥＣＵα、βが統合された１つの統合ＥＣＵの機能ブロック図の一例である。
【図５】ＰＤＵルータが呼び出すドライバとデータの宛先の関係が登録されたドライバテーブルの一例である。
【図６】ＰＤＵルータ１とＰＤＵルータ２がデータを送信又は受信する手順を示すフローチャート図の一例である。
【図７】アプリＡ〜ＣがＲＴＥを介して通信する場合のＥＣＵの構成例を示す図の一例である。
【図８】２つのＥＣＵα、βが統合された１つの統合ＥＣＵの機能ブロック図の一例である（実施例２）。
【図９】ＩＰＣ-ＩＦ／ＩＰＣドライバが通信する手順を模式的に示す図の一例である。
【図１０】ＰＤＵルータ１とＰＤＵルータ２がデータを送信又は受信する手順を示すフローチャート図の一例である（実施例２）。
【図１１】データフローを説明する図の一例である。
【図１２】マルチマイコンの機能ブロック図の一例である。
【図１３】マルチマイコンの機能ブロック図の一例である。
【図１４】ＰＤＵルータ１とＰＤＵルータ２がデータを送信又は受信する手順を示すフローチャート図の一例である（実施例３）。
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための形態について図面を参照しながら説明する。
図２は統合ＥＣＵ１００に統合されたコア同士の通信方法を説明する図の一例である。図２の統合ＥＣＵ（electronic control unit）１００では、ＣＯＭ、ＮＭ及びＤｉａｇＣＡＮ（これらを通信モジュール３３という場合がある）のレイヤとＭＣＡＬ３５（区別する場合ＭＣＡＬ１，２という）のレイヤの間に、ＰＤＵルータ（Protocol Data Unit Router）３４が設けられている。ＰＤＵルータ（区別する場合ＰＤＵルータ１，２という）は、通信データのルーティングを行うレイヤである。
【００１５】
また、ＭＣＡＬ３５にはＤＭＡコントローラ３７に通信を要求するＤＭＡドライバ３８（区別する場合ＤＭＡドライバ１，２という）が配置されている。ＤＭＡドライバ３８は従来のＭＣＡＬにも備えられているが、図２のＤＭＡドライバ３８は統合ＥＣＵ１００においてアプリ３１（区別する場合アプリＡ、Ｂという）間でデータ通信が可能になるように設計されている。
【００１６】
例えば通信モジュール３３がＰＤＵルータ２に通信データの送信を要求すると、ＰＤＵルータ２は送信先がアプリＡであることから、ＤＭＡドライバ２を呼び出す。すなわち、ＣＡＮドライバでなくＤＭＡドライバ２を呼び出すことで、ＤＭＡコントローラ３７がデータを転送し、コア３６（区別する場合コア１，２という）が他方のコア３６と通信することができるようになる。コア２から見ると、ＣＡＮバス３９の代わりに実際には存在しない仮想ＣＡＮバス４０に通信データを出力する態様になる。
【００１７】
アプリＡ側のＤＭＡドライバ１はＤＭＡコントローラ３７の割込み等によりデータを受信したことを検出して、データをＰＤＵルータ１に送信する。ＰＤＵルータ１は送信先がアプリＡであることから、ＲＴＥ３２（区別する場合ＲＴＥ１，２という）を経由してアプリＡにデータを送信する。
【００１８】
また、例えば、アプリＢのデータの宛先が他のＥＣＵである場合、アプリＡ側のＤＭＡドライバ１がデータをＰＤＵルータ１に送信すると、ＰＤＵルータ１は宛先が他のＥＣＵであることからＣＡＮドライバを呼び出す。ＣＡＮドライバを呼び出すことで、ＣＡＮコントローラ２９は、ＣＡＮバス３９にデータを出力することができる。
【００１９】
このように、統合した２つのアプリ側にＰＤＵルータ１，２及びＤＭＡドライバ１，２をそれぞれ設けＤＭＡコントローラ３７を利用することで、アプリＡ,Ｂや通信モジュール３３を修正することなく、アプリＡ、Ｂ間で通信することができる。また、例えば、アプリＢ側のＮＭ２が出力するＮＭメッセージはＣＡＮバス３９から出力されないので、１つのＥＣＵからＮＭメッセージは１つしか出力されないようにすることができる。
【００２０】
〔構成〕
図３は、統合ＥＣＵ１００のハードウェア構成図の一例を示す。統合ＥＣＵ１００は、マルチレイヤバス１４を介して接続されたプロセッサ１１、ＤＭＡコントローラ３７、ＳＤＲＡＭ１２、ＣＡＮコントローラ２９、Ｉ／Ｏ１６及びＲＯＭ１３を有する。プロセッサ１１は、２つのＣＰＵ（以下、区別する場合ＣＰＵ１、２という）１５を有するが、ＣＰＵ１５の数は２つ以上であれば４つ以上でもよい。各ＣＰＵ１、２は、コア３６、コア間通信部２１、及び、ローカルＲＡＭ３６を有する。各ＣＰＵ１、２の機能を区別するため、ＣＰＵ内の各機能にＣＰＵ１、２と同じ番号を付す。
【００２１】
コア１、２は、ＰＣ（プログラムカウンタ）、命令バッファ、ＩＦＵ（Instruction Fetch Unit）、ＤＥＣ（DECoder）、ＲＦ（Register Fetch）、ＲＥＧ（REGister）、ＳＨ（Shifter）、ＡＬＵ、ＭＵＬ及びＦＰＵ等の演算回路、汎用レジスタ、及び、ロード／ストアユニット等を有する。これらが１クロック毎に命令実行段階の各ステージを実行することでいわゆるパイプライン制御が実現されている。
【００２２】
ＲＯＭ１３にはアプリＡ〜Ｃ及びＰＦ（Plat Form）２４が記憶されている。アプリＡ、Ｂは２つのＥＣＵα、βが統合される前の一方のＥＣＵαに搭載されていたアプリであり、アプリＣは他方のＥＣＵβに搭載されていたアプリである。ＰＦ２４は、ハードウェアの違いを吸収してアプリＡ〜Ｃをコア１，２が実行するための実行環境を提供する。本実施例では、ＡＵＴＯＳＡＲ（AUTomotive Open System Architecture）で標準化されている基本ソフトウェアを例にして説明するが、ハードウェアの違いを隠蔽可能であれば単純なＯＳとすることもできる。
【００２３】
ＰＦ２４は、上層から、ＲＴＥ、サービス層、ＥＣＵ抽象化層、及び、ＭＣＡＬ（マイクロコントローラ抽象化層）等の各レイヤによって構成される。サービス層は、ハードウェアから独立した、様々なサービスを提供する層であり、ＯＳ（例えば、ＯＳＥＫ（Open system together with interfaces for automotive electronics）やその他、組み込み用ＯＳ、リアルタイムＯＳ等）、システムサービス（診断ソフト、メモリ管理ソフト等）、メモリサービス、通信サービス（車載ＬＡＮの通信のためのネットワーク管理ソフト（ＣＡＮ、ＦｌｅｘＲａｙ，ＬＩＮ等））を有する。上記のＣＯＭ、ＮＭ及びＤｉａｇＣＡＮの通信モジュール３３はサービス層に含まれる。
【００２４】
ＥＣＵ抽象化層は、搭載機器、メモリハードウェア、通信ハードウェア、及び、Ｉ／Ｏハードウェア等、ＥＣＵの全ての基本コンポーネントを抽象化する。最下層のＭＣＡＬは、ＥＣＵのマイコンの全ての機能と周辺機器を抽象化する層である。ＭＣＡＬより上位のレイヤはマイコンのハードウェアから独立している。ＭＣＡＬは、上記のＤＭＡドライバ３８の他、例えば、メモリドライバ、通信ドライバ及びＩ／Ｏドライバを有する。
【００２５】
図ではＰＦ２４は１つとしたが、統合前のコアやマイコンの種類が異なっている場合、統合前のＰＦ２４も異なっている場合があるので、その場合はそれぞれのＰＦ２４をＲＯＭ１３に記憶しておく。
【００２６】
コア１は、ＲＯＭ１３に記憶されたＰＦ２４、アプリＡ，Ｂを実行し、コア２は、ＲＯＭ１３に記憶されたＰＦ２４、アプリＣを実行する。ローカルＲＡＭ１はコア１に専用のメモリ（一次キャッシュ）であり、ローカルＲＡＭ２はコア２に専用のメモリである。ＳＤＲＡＭ１２は、コア１、２にプログラム又はデータを提供するためのメモリ（二次キャッシュ）である。ＳＤＲＡＭ１２の少なくとも一部はコア１、２により共有される。
【００２７】
コア間通信部１、２は、コア通信バス１６を介してコア１、２が相互に割り込んだり、通信することを可能にする。コア１、２は、コア間通信部１、２により、他のコアの異常の有無を監視したり、ローカルＲＡＭ１，２を介してデータを相互に通信することができる。なお、コア１〜３は、マルチレイヤバス１４を経由して互いに通信することもできる。
【００２８】
マルチレイヤバス１４はＣＰＵ１用、ＣＰＵ２用、及び、ＤＭＡコントローラ３７の読み書き用の計４層のレイヤを備える。ＤＭＡコントローラ３７はマルチレイヤバス１４に接続された各ブロックからのＳＤＲＡＭ１２へのアクセス要求を調停すると共に、ＳＤＲＡＭ１２からローカルＲＡＭ１、２へ（又は、ローカルＲＡＭ１、２からＳＤＲＡＭ）へ、Ｉ／Ｏ１６からＳＤＲＡＭ１２へ（又はＳＤＲＡＭからＩ／Ｏへ）、コア１，２を介在することなくデータを転送する。ＤＭＡコントローラ３７は転送終了によりコア１、２に適宜割込みをかけることできる。
【００２９】
ＣＡＮコントローラ２９はＣＡＮプロトコルに従って通信処理を行う通信コントローラであり、この他、ＦｌｅｘＲａｙやＬＩＮ用の通信コントローラを有していてもよい。Ｉ／Ｏ１６はマイコンと外部の機器を接続するインタフェースであり、各種のセンサ、アクチュエータ等が接続される。
【実施例１】
【００３０】
図４は、２つのＥＣＵα、βが統合された１つの統合ＥＣＵ１００の機能ブロック図の一例である。
【００３１】
アプリＡとアプリＢは、一方が他方の演算結果を利用するようなアプリでもよいし、アプリＢは単なるアイドルタスクのようにアプリＡとＢの結びつきが弱くてもよい。前者の場合、アプリＡ又はＢがＲＴＥ３２を介してイベントやデータを通知することで、互いに呼び出して実行される。アプリＣは、ＥＣＵβに特有のアプリであるが、アプリＡ、Ｂがボデー系ならアプリＣもボデー系のように結びつきの強いアプリであってもよいし、関連のないアプリでもよい。
【００３２】
通信モジュール３３はＣＯＭ、ＮＭ及びＤｉａｇＣＡＮを有し、図１において説明したとおり、ＣＯＭは一般のデータを、ＮＭはネットワークマネージメント機能のためのデータを、ＤｉａｇＣＡＮはサービスツールに必要なデータを、それぞれ送受信するモジュールである。これら通信モジュールは、プロトコルに応じた（例えばＣＡＮ、ＦｌｅｘＲａｙ、Ｌｉｎ）通信の処理を行う。そして、さらに通信モジュールは、ＣＯＭ、ＮＭ、ＤｉａｇＣＡＮなど、通信モジュールに定められたフォーマットでＣＡＮフレーム等を作成する。また、受信時には、ＣＡＮＩＤに基づき受信すべきデータを選択的に受信する。ＣＯＭ、ＮＭ及びＤｉａｇＣＡＮのどの通信モジュールが処理すべきかはＣＡＮＩＤから判定される。
【００３３】
なお、ＮＭはＯＳＥＫ／ＶＤＸ―ＮＭ（Network Management）の規定に基づく通信を行うモジュールである。ＯＳＥＫ−ＮＭでは、１つの車載ＬＡＮに接続された各ＥＣＵが、自身のスリープ可否を判別して、そのスリープ可否を示すＮＭ（Network Management）メッセージを定期的にネットワークバスへ送信するように規定されている。なお、ＮＭメッセージはＣＡＮのメッセージの一表現に過ぎず、フォーマットや送信手順はＣＡＮプロトコルに従うが、周期的に送信されるなどの特徴があるのでＯＳＥＫ−ＮＭに基づくメッセージをＮＭメッセージという。
【００３４】
ＮＭ１，２は、予め定められた周期毎に、アプリＡ、Ｂ又はＣがスリープ可能か否かの判定を行い、スリープ可否を示すＮＭメッセージを、決まった順番で他のＥＣＵに送信する。各ＥＣＵは、ＮＭメッセージを受信すると、他の各ＥＣＵがスリープ可否を記憶しておき、車載ＬＡＮに接続された全てのＥＣＵがスリープ可になると、スリープモードへ移行する処理を開始する。したがって、スリープモードに入っていないのに、自身が受信すべき他のＥＣＵからＮＭメッセージを受信しないことで、他のＥＣＵに異常があることを検出できる。
【００３５】
なお、ＮＭはＮＭメッセージの他にＮＳ（Network Status）メッセージを送信することもがあるが、ＮＭメッセージと同様に取り扱うことができるので省略する。
【００３６】
ＰＤＵルータ３４は、データの送信先を制御する。ＣＡＮコントローラ２９を制御することができるコア１のＰＤＵルータ１と、直接はＣＡＮコントローラ２９を制御できないコア２のＰＤＵルータ２とで機能が異なる。
【００３７】
データの送信時、ＰＤＵルータ２は、ＣＡＮドライバ３８を呼び出せないので、全てのＣＡＮフレームを機械的にＰＤＵルータ１に転送する必要がある。ＰＤＵルータ２はＣＯＭ、ＮＭ及びＤｉａｇＣＡＮのいずれの通信モジュールから通信を要求されても、ＤＭＡドライバ２を呼び出す。
【００３８】
ＰＤＵルータ２がＤＭＡドライバ２からデータを受信した場合は、宛先は通信モジュール３３のいずれかであるので、通信モジュール３３にデータを転送する。
【００３９】
なお、コア２が４つめのアプリＤを実行する場合も、コア２はＣＡＮコントローラ３７を制御できないので、ＰＤＵルータ２の機能は同様である。
【００４０】
次にＰＤＵルータ１について説明する。
・ＰＤＵルータ１の送信時
ＰＤＵルータ１がＣＯＭ、ＮＭ及びＤｉａｇＣＡＮのいずれかの通信モジュール３３からデータの送信を要求された場合、ＣＡＮバス３９に出力するだけでは、ＥＣＵβが受信していたデータをコア２が受信できない。このため、ＰＤＵルータ１は、データの送信時、ＣＡＮドライバ１とＤＭＡドライバ１の両方を呼び出す。データを受信するか否かは、コア２の通信モジュール３３が判定すればよい。
【００４１】
また、統合前のＥＣＵβが受信していたＣＡＮＩＤをリストアップしておき、ＰＤＵルータ１がそのＣＡＮＩＤのデータの送信を受け付けた場合には、ＤＭＡドライバ１を呼び出すようにしてもよい。
・ＰＤＵルータ１の受信時
ＰＤＵルータ１がデータを受信するのはＣＡＮドライバ経由とＤＭＡドライバ１経由の場合がある。ＣＡＮドライバ経由でデータを受信した場合、統合前と同様に、ＣＡＮフレームは受信バッファなどに記憶され、ＣＯＭ、ＮＭ及びＤｉａｇＣＡＮ等の通信モジュール３３が受信すべきか否かを判定する。したがって、ＰＤＵルータ１はＣＡＮドライバ経由で受信した全てのデータを通信モジュール３３に出力する。
【００４２】
また、通信モジュール３３に出力するだけでは、統合前にＥＣＵβがＥＣＵαから受信していたデータをコア２が受信できない。このため、ＰＤＵルータ１は、ＣＡＮドライバ経由でデータを受信した際、ＤＭＡドライバ１にデータを出力する。データを受信するか否かは、コア２の通信モジュール３３が判定すればよい。この場合も、統合前のＥＣＵβが受信していたＣＡＮＩＤをリストアップしておき、ＰＤＵルータ１がそのＣＡＮＩＤのデータの送信を受け付けた場合にだけ、ＤＭＡドライバ１を呼び出すようにしてもよい。
【００４３】
ＤＭＡドライバ１経由でデータを受信した場合、ＰＤＵルータ１は少なくともＮＭメッセージをＣＡＮバスに出力することを禁止する。このため、開発者などが予めＣＡＮバスに転送してよいＣＡＮフレーム（又は転送してはいけないＣＡＮフレーム）を転送リストテーブルに登録しておく。
【００４４】
図５は、転送リストテーブルの一例を示す。転送リストテーブルには、転送してはいけないＣＡＮＩＤが登録されている。このＣＡＮＩＤにはＮＭメッセージのＣＡＮＩＤが含まれることになる。ＰＤＵルータ１は、ＤＭＡドライバ１経由でデータを受信した際、転送リストテーブルにより転送が禁止されていないデータのみＣＡＮドライバを呼び出してＣＡＮバス３９に転送する。
【００４５】
また、ＣＡＮバス３９に出力するだけでは、統合前にＥＣＵαがＥＣＵβから受信していたデータをコア１が受信できない。このため、ＰＤＵルータ１は、ＤＭＡドライバ１経由でデータを受信した際、通信モジュール３３にデータを出力する。データを受信するか否かは、コア１の通信モジュール３３が判定すればよい。
【００４６】
ＣＡＮドライバは統合前と変更がない。ＣＡＮドライバは、ハードウェアであるＣＡＮコントローラ２９から独立したインターフェイスであり、ＣＡＮコントローラ２９の初期化、ＣＡＮメッセージの送信・受信、などの基本的な機能を提供する。
【００４７】
ＤＭＡドライバ１，２は、ハードウェアであるＤＭＡコントローラ３７から独立したインターフェイスであり、ＤＭＡコントローラ３７にデータの送信を実行させ、ＤＭＡコントローラ３７が転送したデータを受信する。
【００４８】
ＤＭＡドライバ１は、通信モジュールから取得したデータをローカルＲＡＭ１に記憶している。したがって、このデータをローカルＲＡＭ２に送信すれば、コア１からコア２にデータを転送したことになる。ＤＭＡドライバ２の場合はこの逆になる。ローカルＲＡＭ１，２のいずれも、ＣＡＮフレームを送信する送信バッファ、及び、受信バッファのアドレスは予め定められている。送信バッファ及び受信バッファはいずれもＦＩＦＯ形式のバッファである。
【００４９】
ＤＭＡドライバ３８は、ＰＤＵルータ３４から呼び出された際に、ＳＤＲＡＭ１２を介してローカルＲＡＭ１からローカルＲＡＭ２へ（又は、その逆に）データを転送できるように修正されている。
【００５０】
ＤＭＡドライバ１は、ローカルＲＡＭ１の送信バッファの先頭アドレスを、ＤＭＡコントローラ３７の転送元アドレスレジスタに、データ長などから必要な転送回数をＤＭＡコントローラ３７の転送回数レジスタに（又は転送終了アドレスレジスタにＣＡＮフレームの最後のアドレスを設定してもよい）、ＳＤＲＡＭ１２の共有領域の先頭アドレスを、ＤＭＡコントローラ３７の転送先アドレスレジスタに、それぞれ設定し、ＤＭＡコントローラ３７に送信させる。
【００５１】
ＤＭＡコントローラ３７は転送が終了すると、コア２に割り込みして通知するので、コア２のＤＭＡドライバ２は、ＳＤＲＡＭ１２の共有領域からＣＡＮフレームを読み出すことができる。
【００５２】
ＤＭＡドライバ２の場合も同様である。ＤＭＡドライバ２は、ＰＤＵルータ２から取得したＣＡＮフレームをローカルＲＡＭ２に記憶している。ＤＭＡドライバ２は、ローカルＲＡＭ２の送信バッファの先頭アドレスを、ＤＭＡコントローラ３７の転送元アドレスレジスタに、データ長などから必要な転送回数をＤＭＡコントローラ３７の転送回数レジスタに、ＳＤＲＡＭ１２の共有領域の先頭アドレスを、ＤＭＡコントローラ３７の転送先アドレスレジスタに、それぞれ設定し、送信させる。
【００５３】
ＤＭＡコントローラ３７は転送が終了すると、コア２に割り込みして通知するので、コア２のＤＭＡドライバ２は、ＳＤＲＡＭ１２の共有領域からＣＡＮフレームを読み出すことができる。
【００５４】
なお、ＳＤＲＡＭ１２を経由することなく、ローカルＲＡＭ１、２間でデータを転送してもよい。この場合、ＤＭＡドライバ３８の代わりに、コア間通信部２１のドライバを使用するなど、コア間通信に必要なドライバを用いればよい。
【００５５】
以上のように、ＰＤＵルータ１，２とＤＭＡドライバ３８を修正するだけで、アプリＡ，Ｂの可搬性や損なうことなく、２つのＥＣＵα、βを統合することができる。
【００５６】
＜動作手順＞
図６は、ＰＤＵルータ１とＰＤＵルータ２がデータを送信又は受信する手順を示すフローチャート図の一例である。図６の手順はＰＤＵルータ１又はＰＤＵルータ２がデータを取得するとスタートする。
【００５７】
ＰＤＵルータ１から説明する。まず、ＰＤＵルータ１がデータを取得する（Ｓ１０）。データを取得する場合には、アプリＡ又はアプリＢから送信用のデータを取得する場合と、ＣＡＮドライバ１又はＤＭＡドライバ１から受信用のデータを取得する場合がある。送信時か受信時かは、ＰＤＵルータ１がアプリ側又はドライバ側のどちらからデータを取得したかにより判定される。
【００５８】
データの受信時（Ｓ２０のＹｅｓ）、ＰＤＵルータ１はＤＭＡドライバ１からデータを取得したか否かを判定する（Ｓ３０）。
【００５９】
ＤＭＡドライバ１からデータを取得した場合（Ｓ３０のＹｅｓ）、ＰＤＵルータ１はＮＭメッセージの転送を禁止するため、転送リストテーブルを参照し、送信禁止のデータを除き、ＣＡＮドライバを呼び出してＣＡＮバスに転送する（Ｓ４０）。
【００６０】
続いて、ＰＤＵルータ１は、ＤＭＡドライバ１から取得したかＣＡＮドライバから取得したかに関係なく、データを通信モジュール３３に出力する（Ｓ５０）。通信モジュール３３は、ＣＡＮＩＤに基づき受信が必要か否かを判定し、必要な場合はＲＴＥ３２を介してアプリＡ又はアプリＢに出力する。
【００６１】
また、ＰＤＵルータ１がＣＡＮドライバから取得したデータはアプリＣ宛の可能性もあるので、ＰＤＵルータ１はＤＭＡドライバ１を呼び出す（Ｓ６０）。これにより、ＤＭＡドライバ１がＤＭＡコントローラ３７を用いてＤＭＡドライバ２にデータを送信する。
【００６２】
データの送信時（Ｓ２０のＮｏ）、ＰＤＵルータ１は、ＣＡＮドライバを呼び出す（Ｓ７０）。これにより、ＣＡＮドライバ１がＣＡＮコントローラ２９を用いてＣＡＮバス３９にデータを送信する。
【００６３】
また、ＰＤＵルータ１が取得した送信用のデータがアプリＣ宛の可能性があるので、ＰＤＵルータ１はＤＭＡドライバ１を呼び出す（Ｓ８０）。これにより、ＤＭＡドライバ１がＤＭＡコントローラ３７を用いてＤＭＡドライバ２にデータを送信する。
【００６４】
次に、ＰＤＵルータ２について説明する。まず、ＰＤＵルータ２がデータを取得する（Ｓ１１０）。ＰＤＵルータ２がデータを取得する場合には、アプリＣから送信用のデータを取得する場合と、ＤＭＡドライバ２から受信用のデータを取得する場合がある。送信時か受信時かは、ＰＤＵルータ２がアプリ側又はドライバ側のどちらからデータを取得したかにより判定される。
【００６５】
データの受信時（Ｓ１１０のＹｅｓ）、ＰＤＵルータ２はデータを通信モジュール３３に出力する（Ｓ１２０）。通信モジュール３３は、ＣＡＮＩＤに基づき受信が必要か否かを判定する。
【００６６】
データの送信時（Ｓ１１０のＮｏ）、ＰＤＵルータ２はＤＭＡドライバ２を呼び出す（Ｓ１３０）。これにより、ＤＭＡドライバ２がＤＭＡコントローラ３７を用いてＤＭＡドライバ１にデータを送信する。
【００６７】
＜効果＞
以上のような統合ＥＣＵ１００によれば、アプリＣが送信したＮＭメッセージはアプリＡ又はアプリＢには送信されても、ＣＡＮバス３９には出力されないので１つのＥＣＵから出力されるＮＭメッセージを１つにすることができる。
【００６８】
また、アプリＡ〜Ｃを修正する必要がなく、修正の対象をＤＭＡドライバ１，２やＰＤＵルータ１、２に限定することができる。したがって、アプリＡ〜Ｃの可搬性を保つことができる。
【００６９】
また、この他の効果としてＣＰＵ１５の利用効率が低下しにくいという効果がある。
図７（ａ）はアプリＡ〜ＣがＲＴＥ３２を介して通信する場合の統合ＥＣＵの構成例を示す図の一例である。ＲＴＥ３２にはイベントやデータをアプリ間で送受信する機能があるので、図示するようにＤＭＡドライバ１，２を用いることなく、２つのＥＣＵを統合することも可能である。
【００７０】
アプリＡはアプリＢと、アプリＡはアプリＣとＲＴＥを介して通信することができる。また、ＣＡＮバス３９から通信モジュール（ＣＯＭ）が受信したデータは、通信モジュールがＲＴＥ３２を介してアプリＣに送信することもできる。しかしながら、ＲＴＥ３２で統合による全ての影響を吸収する方法を採用した場合、アプリＡ、Ｂがコア２のローカルＲＡＭ２に、アプリＣがコア１のローカルＲＡＭ１にアクセスすることを意味しており、アプリＡ〜Ｃに排他制御が必要であることを意味する。排他されたアプリは実行されない（処理を進行できない）ので、ＣＰＵ１５の利用効率が低下する。これに対し、本実施例の統合ＥＣＵ１００ではこのような不都合をもたらすことがない。
【００７１】
また、統合ＥＣＵ１００の消費電力の低消費電力化が図れるという効果がある。
図７（ｂ）は４つのコア１〜４とアプリＡ〜Ｈの関係を模式的に示す図の一例である。コア１はアプリＡ、Ｂを、コア２はアプリＣ、Ｄを、コア３はアプリＥ、Ｆを、コア４はアプリＧ、Ｈを、それぞれ実行する。例えば、アプリＤはアプリＥ，Ｆとしか通信せず、アプリＣはアプリＦとしか通信しない場合（外部とも通信しない）、コア２とコア３の中で通信が完結する。このため、アプリＣ、Ｄ、Ｅ、Ｆでスリープ条件が成立した場合、コア２，３を停止させることができ、低消費電力化を達成しやすい。より具体的には図7（ａ）のようにＲＴＥ３２がアプリＣ、Ｄ、Ｅ、Ｆ間の通信を担うと、アプリＣ、Ｄ、Ｅ、Ｆがスリープ条件を満たしても、通信のためにＲＴＥ３２は起動しておく必要があるので、コア２，３を停止させることができず、低消費電力化が図れない。本実施例ではコア単位でＲＴＥ３２も停止しておくことができるので、統合ＥＣＵ１００の消費電力を低減することが容易になる。
【実施例２】
【００７２】
実施例１ではＤＭＡドライバ１，２によりコア間通信を行うことで統合ＥＣＵ１００を構成した。本実施例では、ＩＰＣ-ＩＦ４１／ＩＰＣドライバ４２によりコア間通信を統合ＥＣＵ１００について説明する。
【００７３】
図８は、２つのＥＣＵα、βを統合して得られた１つの統合ＥＣＵ１００の機能ブロック図の一例である。図８において図４と同一部の説明は省略する。図８ではＤＭＡドライバ１の代わりにＩＰＣ-ＩＦ（InterProcess Communication Inter Face）１／ＩＰＣ（（InterProcess Communication）ドライバ１が、ＤＭＡドライバ２の代わりにＩＰＣ-ＩＦ２／ＩＰＣドライバ２が、配置されている。
【００７４】
また、ＤＭＡコントローラ３７の代わりにローカルＲＡＭ１が配置されている。図８の構成ではコア１とコア２は、ＦＩＦＯ形式の送信キュー、受信キュー、及び、ローカルＲＡＭ１を介して通信する。
【００７５】
ＩＰＣ-ＩＦ４１は送信キュー４３へのデータの登録機能と受信キューにデータが届いた場合にアプリ側に受信完了通知を出力する。
ＩＰＣドライバ４２は、
・送信キューにストックされたデータをローカルＲＡＭ１に登録する。
・共有ＲＡＭにストックされたデータを受信キューに書き込む。
【００７６】
図９は、ＩＰＣ-ＩＦ１／ＩＰＣドライバ１とＩＰＣ-ＩＦ２／ＩＰＣドライバ２とが通信する手順を模式的に示す図の一例である。図９はＮＭの周期的な通信を例にしている。図９（ａ）はコア１からコア２への送信手順を、図９（ｂ）はコア２からコア１への送信手順をそれぞれ示す。
【００７７】
図９（ａ）に基づき説明する。
（１）まず、ＮＭ１からＰＤＵルータ１に送信登録するとＰＤＵルータ内で静的に設定されたＣＡＮＩＤのルーティング情報を元にＩＰＣ-ＩＦ１側にデータを登録する。
（２）コア１のＰＤＵルータ１はＩＰＣドライバ１を起床させる。
（３）ＩＰＣドライバ１は送信キュー４３のデータを読み出しローカルＲＡＭ１に記憶する。
（４）コア２のＰＤＵルータ２はＩＰＣドライバ２を起床させる。
（５）ＩＰＣドライバ２はローカルＲＡＭ１のデータを読み出し、ＰＤＵルータ２にデータを登録する。ＰＤＵルータ側では静的に設定されたＣＡＮＩＤのルーティング情報を元にＩＰＣ-ＩＦ２の受信キュー４４に登録する。
（６）ＰＤＵルータ２は、ＮＭ２に受信完了通知を通知する。
【００７８】
図９（ｂ）は手順が逆になるだけなので説明を省略する。図９（ａ）と（ｂ）のいずれもローカルＲＡＭ１を共有ＲＡＭとして使用しているので、なんらかの排他制御が必要になるが。本実施例では、例えばセマフォを利用し、ＩＰＣドライバ１，２のうちセマフォを取得した方がローカルＲＡＭ１の使用権を得るようになっている。
【００７９】
図１０は、ＰＤＵルータ１とＰＤＵルータ２がデータを送信又は受信する手順を示すフローチャート図の一例である。図１０の手順は図６の手順とほぼ同じであり、ＰＤＵルータ３４がＤＭＡドライバ３８を呼び出すか、ＩＰＣ-ＩＦ４１／ＩＰＣドライバ４２を呼び出すかが異なるだけである。
【００８０】
このように、アプリ間（プロセス間）の通信を可能にするドライバであれば、ＤＭＡコントローラ３７を用いる必要はなく、実施例１と同様にアプリ間の通信が可能な統合ＥＣＵ１００を実現することができる。
【００８１】
図１１は、データフローを説明する図の一例である。図１１では通信モジュール３３のＣＯＭが通信する手順を例にしている。
・アプリＢ→アプリＡ
（Ａ１）アプリＣが送信すべきデータｄａｔａ_ａを生成したため、ＲＴＥ３２を介してＣＯＭに送信する。なお、「共通ＣＳ（Communication Stack）」は各コアで共通の、ＣＯＭやＩＰＣ-ＩＦ４１、ＩＰＣドライバ４２を使用した通信処理を行う機能（ソフトウェア）である。
（Ａ２）ＣＯＭはメッセージを生成し、ＰＤＵルータ２に送信する。
（Ａ３）ＰＤＵルータ２は、メッセージをＩＰＣ-ＩＦ２の送信キュー４３に登録する。
（Ａ４）ＩＰＣドライバ２は送信キュー４３からメッセージを読み出してローカルＲＡＭ１に書き込む。
（Ａ５）ＩＰＣドライバ１はローカルＲＡＭ１からメッセージを読み出し、ＩＰＣ-ＩＦ１の受信キュー４４に登録する。
（Ａ６）ＩＰＣ-ＩＦ１は受信完了通知とメッセージをＰＤＵルータ１に通知する。ＰＤＵルータはデータを振り分けることができるが、図では通信モジュール３３のＣＯＭ側にデータを出力している。
（Ａ７）ＣＯＭ１はデータをアプリＡに出力する。
・アプリＡ→ＣＡＮバス
（Ｂ１）アプリＡが送信すべきデータｄａｔａ_ｂを生成した場合、ＲＴＥ１を介してＣＯＭ１に送信する。
（Ｂ２）ＣＯＭ１はメッセージを生成し、ＰＤＵルータ１に出力する。
（Ｂ３）ＰＤＵルータ１は、メッセージＢをＣＡＮ Ｉ／Ｆ４５とＩＰＣ-ＩＦ１に出力する。図では、ＩＰＣ−ＩＦ１側への出力は省略した。なお、ＣＡＮ
Ｉ／Ｆ４５は、送信キューへのデータの登録機能と受信キューにデータが届いた場合にＰＤＵルータ１側に受信完了通知を出力する
（Ｂ４）ＣＡＮ Ｉ／Ｆ４５はＣＡＮドライバにメッセージＢを出力する。
（Ｂ５）ＣＡＮドライバは、ＣＡＮコントローラ２９を使用してフレームＢをＣＡＮバス３９に出力する。
【００８２】
以上のように、ＤＭＡコントローラ３７を用いなくても、ＩＰＣ-ＩＦ４１／ＩＰＣドライバ４２を用いることで、実施例１と同様に、１つのＥＣＵから出力されるＮＭメッセージを１つにすることができ、アプリＡ〜Ｃの可搬性を保つことができる。また、ＣＰＵ１５の利用効率を低下させることがなく、消費電力も低減しやすい。
【実施例３】
【００８３】
実施例１，２では複数のＥＣＵを、マルチコア型のプロセッサを備えた１つマイコンに統合して１つの統合ＥＣＵ１００を実現した。本実施例では、複数のマイコンを１つのＥＣＵに統合した統合ＥＣＵ１００について説明する。マイコンという枠組みを残したままの統合ＥＣＵ１００には２つの構成がある。
【００８４】
図１２は、マルチマイコンの機能ブロック図の一例である。図１２において図４と同一部の説明は省略する。図１２では、統合ＥＣＵ１００にマイコン５１（区別する場合マイコン１，２という）が搭載されたので、最下層にマイコン１，２が配置されている。マイコン１，２はＤＭＡコントローラ３７により通信するものとするが、マイコン１，２が通信可能であれば共有メモリ（ＩＰＣ-ＩＦ４１／ＩＰＣドライバ４２）、専用の通信線などを介して通信してもよい。図１２のようなマルチマイコンの場合の通信手順は実施例１と同様なので説明は省略する。
【００８５】
図１３は、マルチマイコンの機能ブロック図の一例である。図１３において図４と同一部の説明は省略する。１つのマイコン５１は、通常、複数個のチャネルを有するので、マイコン２側のチャネルの１つをＤＭＡコントローラ３７に割り当てても、チェネルが余る。また、ＮＭメッセージ以外は、１つのＥＣＵが複数個出力しても問題がない。そこで、マイコン２のもう１つのチェネルをＣＡＮコントローラ２９に割り当てる。こうすることで、マイコン１と２は、ＮＭメッセージだけを統合ＥＣＵ１００内で処理すればよいことになる。
【００８６】
すなわち、ＰＤＵルータ２は、ＣＡＮＩＤからＮＭメッセージと判定される場合、又は、通信モジュール３３からデータを受け付けた場合、ＤＭＡドライバ２を呼び出し、それ以外の場合はＣＡＮドライバ２を呼び出す。ＰＤＵルータ１のＤＭＡドライバ１は、実施例１と同様にデータを受信してＰＤＵルータ１に出力する。ＰＤＵルータ１はＮＭメッセージであるのでＣＡＮバス３９に出力することなく、通信モジュール３３にだけデータを出力する。こうすることで、２つのマイコン１，２を有する統合ＥＣＵ１００でも、複数のＮＭメッセージをＣＡＮバス３９に出力することを防止できる。
【００８７】
また、マイコン１及び２の双方がＣＡＮコントローラ２９を有するので、ＰＤＵルータ１は、ＤＭＡドライバ１により内部的にマイコン２と通信することも、ＣＡＮバス３９を介してマイコン２と通信することもできる。マイコン２との通信を、統合前と同様にＣＡＮバス３９を使用するように設計すれば、ＰＤＵルータ１、２が必要なＣＡＮフレームの振り分けをさらに少なくできる。
【００８８】
図１４は、ＰＤＵルータ１とＰＤＵルータ２がデータを送信又は受信する手順を示すフローチャート図の一例である。図１４の手順のうち図６の手順と異なるステップを説明する。
【００８９】
まず、実施例１と同様に、データの受信時、ＰＤＵルータ１はＤＭＡドライバ１からデータを取得した場合（Ｓ３０のＹｅｓ）、ＰＤＵルータ１はＮＭメッセージの転送を禁止するため、転送リストテーブルを参照し、送信禁止のデータを除き、ＣＡＮドライバを呼び出してＣＡＮバス３９に転送する（Ｓ４０）。
【００９０】
また、ＰＤＵルータ１は、ＤＭＡドライバ１から取得したかＣＡＮドライバから取得したかに関係なく、データを通信モジュール３３に出力する（Ｓ５０）。この後、実施例１と異なり、マイコン２がＣＡＮコントローラ２を有しているので、アプリＣ宛のデータはマイコン２が直接受信する。このため、ＰＤＵルータ１がＤＭＡドライバ１を呼び出す必要はない。
【００９１】
データの送信時（Ｓ２０のＮｏ）も同様で、ＰＤＵルータ１はＣＡＮドライバを呼び出すが（Ｓ８０）、アプリＣ宛のデータはＣＡＮバス経由でマイコン２に送信すればよいので、ＰＤＵルータ１がＤＭＡドライバ１を呼び出す必要がない。
【００９２】
ＰＤＵルータ２の場合、データの受信時（Ｓ１２０のＹｅｓ）、ＰＤＵルータ２はデータを通信モジュール３３に出力する（Ｓ１３０）ので、受信時に変更はない。
【００９３】
データの送信時（Ｓ１２０のＮｏ）、ＰＤＵルータ２はＭＮデータをＤＭＡドライバ２に振り分けるため、データがＮＭメッセージか否かを判定する（Ｓ１２５）。そして、ＰＤＵルータ２はＭＮメッセージの場合だけ、ＤＭＡドライバ２を呼び出す（Ｓ１４０）。また、ＰＤＵルータ２はＭＮメッセージ以外のデータの場合、ＣＡＮドライバ２を呼び出す（Ｓ１５０）。これにより、マイコン２はＮＭメッセージだけを内部的にマイコン１に送信することができる。
【００９４】
このように、マルチマイコンの場合、実施例１，２と同様に統合後のアプリが通信することもできるし、実施例１，２よりも容易にアプリの通信を実現することもできる。
【符号の説明】
【００９５】
１１ プロセッサ ２２ ローカルＲＡＭ ２９ ＣＡＮコントローラ
３１ アプリ ３２ ＲＴＥ ３３ 通信モジュール
３４ ＰＤＵルータ ３５ ＭＣＡＬ ３６ コア
３７ ＤＭＡコントローラ ３８ ＤＭＡドライバ
３９ ＣＡＮバス ４０ 仮想ＣＡＮバス ５１ マイコン
１００ 統合ＥＣＵ
【特許請求の範囲】
【請求項１】
第１のコアが実行する第１のアプリと第２のコアが実行する第２のアプリがそれぞれ外部にデータを送信する車両制御装置であって、
バスを介して外部の機器と通信するため通信手段と、
前記第1のコアと前記第２のコアの間で通信する内部通信手段と、
前記第２のアプリの第１の送信データを前記通信手段でなく前記内部通信手段に出力する出力先変更手段と、
前記内部通信手段から取得した前記第１の送信データを前記第１のアプリ又は前記通信手段のどちらに出力するかを、前記第１の送信データの送信先情報が登録されたリストテーブルに従い制御するデータ送信先制御手段と、
を有する車両制御装置。
【請求項２】
前記データ送信先制御手段は、前記第１のアプリから取得した第２の送信データを前記通信手段及び前記内部通信手段に出力し、
前記通信手段は前記第２の送信データを外部に送信し、前記内部通信手段は前記第２の送信データを前記第２のコアに送信する、
ことを特徴とする請求項１記載の車両制御装置。
【請求項３】
前記通信手段が外部から受信データを受信した際、
前記データ送信先制御手段は、前記受信データを前記第１のアプリに出力すると共に、前記内部通信手段に出力し、
前記内部通信手段は前記受信データを前記第２のコアに送信する、
ことを特徴とする請求項１又は２記載の車両制御装置。
【請求項４】
前記内部通信手段は、ＤＭＡコントローラと共有メモリを使用して、又は、内部通信用のドライバと前記第１又は第２のコアのローカルＲＡＭを使用して、前記第1のコアと前記第２のコアの間で通信する、
ことを特徴とする請求項１〜３いずれか１項記載の車両制御装置。
【請求項５】
前記リストテーブルには、前記通信手段へ出力を禁止する前記第１の送信データとしてＯＳＥＫ／ＶＤＸ―ＮＭ（Network Management）の規定に基づくＮＭメッセージが登録されており、
前記データ送信先制御手段は、ＮＭメッセージを前記通信手段に出力せず、前記第１のアプリにのみ出力する、
ことを特徴とする請求項１〜４いずれか１項記載の車両制御装置。
【請求項６】
当該車両制御装置は、複数のコアを備えるプロセッサが１つのマイコン内に配置された電子制御ユニットである、
ことを特徴とする請求項１〜５いずれか１項記載の車両制御装置。
【請求項７】
当該車両制御装置は、マイコン内に１つ以上のコアを有するプロセッサが配置された複数個のマイコンを備える電子制御ユニットであり、
第１のマイコンと第２のマイコンがそれぞれ別々の前記通信手段と接続されており、
前記出力先変更手段は、前記第１の送信データが予め定められた所定の送信データの場合にのみ前記内部通信手段に出力し、所定の送信データ以外の前記第１の送信データを、前記第２のマイコンに接続された前記通信手段に出力する、
ことを特徴とする請求項１項記載の車両制御装置。
【請求項８】
前記データ送信先制御手段は、前記第１のアプリから取得した第２の送信データを前記第１のマイコンに接続された前記通信手段にのみ出力し、
前記第２のアプリは、前記第２のマイコンに接続された前記通信手段を介して前記第２のデータを受信する、
ことを特徴とする請求項７記載の車両制御装置。
【請求項９】
電子制御装置の１のコアが実行する第１のアプリと第２のコアが実行する第２のアプリがそれぞれ外部とデータ通信するデータ通信方法であって、
前記第２のアプリが第１の送信データを生成するステップと、
出力先変更手段が前記第１の送信データを前記通信手段でなく前記内部通信手段に出力するステップと、
前記内部通信手段が前記第１の送信データを前記第１のコアに送信するステップと、
データ送信先制御手段が、前記第１の送信データを前記第１のアプリ又は前記通信手段のどちらに出力するかを、前記第１の送信データの送信先情報が登録されたリストテーブルに従い制御するステップと、
を有するデータ通信方法。
【請求項１】
第１のコアが実行する第１のアプリと第２のコアが実行する第２のアプリがそれぞれ外部にデータを送信する車両制御装置であって、
バスを介して外部の機器と通信するため通信手段と、
前記第1のコアと前記第２のコアの間で通信する内部通信手段と、
前記第２のアプリの第１の送信データを前記通信手段でなく前記内部通信手段に出力する出力先変更手段と、
前記内部通信手段から取得した前記第１の送信データを前記第１のアプリ又は前記通信手段のどちらに出力するかを、前記第１の送信データの送信先情報が登録されたリストテーブルに従い制御するデータ送信先制御手段と、
を有する車両制御装置。
【請求項２】
前記データ送信先制御手段は、前記第１のアプリから取得した第２の送信データを前記通信手段及び前記内部通信手段に出力し、
前記通信手段は前記第２の送信データを外部に送信し、前記内部通信手段は前記第２の送信データを前記第２のコアに送信する、
ことを特徴とする請求項１記載の車両制御装置。
【請求項３】
前記通信手段が外部から受信データを受信した際、
前記データ送信先制御手段は、前記受信データを前記第１のアプリに出力すると共に、前記内部通信手段に出力し、
前記内部通信手段は前記受信データを前記第２のコアに送信する、
ことを特徴とする請求項１又は２記載の車両制御装置。
【請求項４】
前記内部通信手段は、ＤＭＡコントローラと共有メモリを使用して、又は、内部通信用のドライバと前記第１又は第２のコアのローカルＲＡＭを使用して、前記第1のコアと前記第２のコアの間で通信する、
ことを特徴とする請求項１〜３いずれか１項記載の車両制御装置。
【請求項５】
前記リストテーブルには、前記通信手段へ出力を禁止する前記第１の送信データとしてＯＳＥＫ／ＶＤＸ―ＮＭ（Network Management）の規定に基づくＮＭメッセージが登録されており、
前記データ送信先制御手段は、ＮＭメッセージを前記通信手段に出力せず、前記第１のアプリにのみ出力する、
ことを特徴とする請求項１〜４いずれか１項記載の車両制御装置。
【請求項６】
当該車両制御装置は、複数のコアを備えるプロセッサが１つのマイコン内に配置された電子制御ユニットである、
ことを特徴とする請求項１〜５いずれか１項記載の車両制御装置。
【請求項７】
当該車両制御装置は、マイコン内に１つ以上のコアを有するプロセッサが配置された複数個のマイコンを備える電子制御ユニットであり、
第１のマイコンと第２のマイコンがそれぞれ別々の前記通信手段と接続されており、
前記出力先変更手段は、前記第１の送信データが予め定められた所定の送信データの場合にのみ前記内部通信手段に出力し、所定の送信データ以外の前記第１の送信データを、前記第２のマイコンに接続された前記通信手段に出力する、
ことを特徴とする請求項１項記載の車両制御装置。
【請求項８】
前記データ送信先制御手段は、前記第１のアプリから取得した第２の送信データを前記第１のマイコンに接続された前記通信手段にのみ出力し、
前記第２のアプリは、前記第２のマイコンに接続された前記通信手段を介して前記第２のデータを受信する、
ことを特徴とする請求項７記載の車両制御装置。
【請求項９】
電子制御装置の１のコアが実行する第１のアプリと第２のコアが実行する第２のアプリがそれぞれ外部とデータ通信するデータ通信方法であって、
前記第２のアプリが第１の送信データを生成するステップと、
出力先変更手段が前記第１の送信データを前記通信手段でなく前記内部通信手段に出力するステップと、
前記内部通信手段が前記第１の送信データを前記第１のコアに送信するステップと、
データ送信先制御手段が、前記第１の送信データを前記第１のアプリ又は前記通信手段のどちらに出力するかを、前記第１の送信データの送信先情報が登録されたリストテーブルに従い制御するステップと、
を有するデータ通信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１２−１２８７８８（Ｐ２０１２−１２８７８８Ａ）
【公開日】平成２４年７月５日（２０１２．７．５）
【国際特許分類】
【出願番号】特願２０１０−２８１７２０（Ｐ２０１０−２８１７２０）
【出願日】平成２２年１２月１７日（２０１０．１２．１７）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
【公開日】平成２４年７月５日（２０１２．７．５）
【国際特許分類】
【出願日】平成２２年１２月１７日（２０１０．１２．１７）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
[ Back to top ]