(57)【要約】【課題】通信ミドルウェアの変更を少なくして機能を統合可能な電子制御装置を提供すること。【解決手段】ネットワークに接続された機器と通信する電子制御装置１００において、複数のアプリケーションプログラム及び複数の通信ミドルウェアを記憶したプログラム記憶手段１１と、プログラムを実行するプログラム実行手段１３と、通信プロトコルに基づく処理を行う複数の通信コントローラ１５と、通信コントローラの送信端子Ｔｘの接続先を第１の接続先又は第２の接続先のどちらかに切り替える複数の送信切り替え手段１７と、入力側が複数の前記第１の接続先と接続され、出力側が第１のＤ／Ａ変換器２００を介して前記ネットワークに接続された通信データ選択手段２３と、前記送信切り替え手段に接続先を切り替えさせる接続先制御手段１６と、を有する。【選択図】図２
2012114724.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された機器と通信する電子制御装置において、
複数のアプリケーションプログラム及び複数の通信ミドルウェアを記憶したプログラム記憶手段と、
プログラムを実行するプログラム実行手段と、
通信プロトコルに基づく処理を行う複数の通信コントローラと、
通信コントローラの送信端子の接続先を第１の接続先又は第２の接続先のどちらかに切り替える複数の送信切り替え手段と、
入力側が複数の前記第１の接続先と接続され、出力側が第１のＤ／Ａ変換器を介して前記ネットワークに接続された通信データ選択手段と、
前記送信切り替え手段に接続先を切り替えさせる接続先制御手段と、
を有する電子制御装置。
【請求項２】
前記接続先制御手段は、第１の通信プロトコルに基づく処理を行う全ての通信コントローラの送信端子が前記第１の接続先に接続されるよう前記送信切り替え手段を制御する、
ことを特徴とする請求項１記載の電子制御装置。
【請求項３】
前記第２の接続先を前記ネットワークに接続する第２のＤ／Ａ変換器を有し、
前記接続先制御手段は、第２の通信プロトコルに基づく処理を行う通信コントローラの送信端子が前記第２の接続先に接続されるよう前記送信切り替え手段を制御する、
ことを特徴とする請求項２記載の電子制御装置。
【請求項４】
前記第２の接続先を前記ネットワークに接続する第２のＤ／Ａ変換器を有し、
前記接続先制御手段は、第２の通信プロトコルに基づく処理を行う全ての通信コントローラの送信端子が前記第２の接続先に接続されるよう前記送信切り替え手段を制御する、
ことを特徴とする請求項２記載の電子制御装置。
【請求項５】
複数の通信コントローラの受信端子を第３の接続先又は第４の接続先のどちらかに切り替える複数の受信切り替え手段と、
前記第１のＤ／Ａ変換器がネットワークから受信した受信データを出力する受信端子と複数の前記第３の接続先をそれぞれ接続する受信バスと、を有し、
前記接続先制御手段は、前記第１の通信プロトコルに基づく処理を行う全ての通信コントローラの受信端子が前記第３の接続先に接続されるよう前記送信切り替え手段を制御する、
ことを特徴とする請求項２記載の電子制御装置。
【請求項６】
前記通信データ選択手段は、複数の通信コントローラから同時期にデータを受け付けた場合、前記第１の通信プロトコルにより優先されるＨｉｇｈ又はＬｏｗの信号を通過させ、
複数の通信コントローラは受信端子が受信したデータの監視結果に応じて、データの送信を停止する、
ことを特徴とする請求項５記載の電子制御装置。
【請求項７】
前記接続先制御手段は、当該電子制御装置の起動時に各通信コントローラのレジスタに設定された制御情報に基づき、各通信コントローラの送信端子が前記第１の接続先又は前記第２の接続先のどちらかに接続されるように前記送信切り替え手段を制御する、
ことを特徴とする請求項１〜６いずれか１項記載の電子制御装置。
【請求項８】
前記第１の通信プロトコルはＣＡＮプロトコルである、ことを特徴とする請求項１〜７いずれか１項記載の電子制御装置。
【請求項９】
前記プログラム記憶手段は、別々の電子制御装置に搭載されていた複数のアプリケーションプログラム、及び、別々の電子制御装置に搭載されていた複数の通信ミドルウェアを記憶している、ことを特徴とする請求項１〜８いずれか１項記載の電子制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車載機器を制御する電子制御装置に関し、特に、機能統合後の電子制御装置に関する。
【背景技術】
【０００２】
多くの車載装置が電子制御ユニット（ＥＣＵ）により制御されるようになり、これらＥＣＵが車載ＬＡＮを介して相互にデータ通信することで、より高度な制御が可能となっている。しかし、非常に多くのＥＣＵが車載ＬＡＮに接続されることは、データの伝送時の遅延や再送信が増大することが知られており、また、数多くのＥＣＵを開発することはコスト増となっている。このため、複数のＥＣＵが提供していた機能を１つのＥＣＵに機能統合する試みが行われるようになった（例えば、特許文献１参照。）。特許文献１には、複数の車載ＬＡＮを相互に接続するゲートウェイ機能と、特定処理を実現するアプリケーション機能とが１つに統合されたＥＣＵが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−１６５８８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、特許文献１のようにゲートウェイ機能とアプリケーション機能を統合するのでなく、別々のＥＣＵが提供していたアプリケーション機能同士を統合することも考えられている。しかしながら、アプリケーション同士を統合すると次のような問題が生じる。
【０００５】
図１は、複数のＥＣＵを統合した際の構成例を説明する図の一例である。図１（ａ）に示すように、統合前にＥＣＵ‐Ａ、ＥＣＵ‐Ｂ、及び、ＥＣＵ‐ＣがＣＡＮバスに接続されており、ＥＣＵ‐Ａ、ＥＣＵ‐Ｂ及びＥＣＵ‐Ｃが互いに通信可能である。ＥＣＵ‐Ａ〜ＥＣＵ‐Ｂは共にＣＡＮ通信のための通信ミドルウェアＡ，Ｂを実装している（ＥＣＵ‐Ｃについては不図示）。通信ミドルウェアＡ，Ｂは、アプリＡ又はアプリＢが送信要求したデータをＣＡＮ  Ｈ／Ｗのバッファに設定するプログラムである。また、通信ミドルウェアＡ，Ｂは、ＣＡＮプロトコルに従ったフォーマットのフレームを送受信するので、フレームにＩＤ等を設定する処理を行う。なお、通信ミドルウェアＡ，Ｂは、ＯＳＥＫ（Offene  Systeme  und  deren  schnittstellen  fur  die  Elektronik  im  Kraftfahrzeug）／ＶＤＸ―ＮＭ（Network  Management）の規格に基づく通信処理も行う。
【０００６】
図１（ｂ）は、ＥＣＵ‐ＡとＥＣＵ‐Ｂの統合例を模式的に示す。ＥＣＵ‐Ａは固定のＣＡＮ  ＩＤを有するので通信ミドルウェアＡはアプリＡの専用であり、ＥＣＵ‐Ｂは固定のＣＡＮ  ＩＤを有するので通信ミドルウェアＢはアプリＢの専用である。そのため２つの通信ミドルウェアＡ，Ｂは２つともそのまま統合後のＥＣＵに実装する方がソフトウェアの変更が少ない。
【０００７】
これにより、アプリＡは通信ミドルウェアＡを介してＣＡＮバス上にフレームを送信でき、アプリＢは通信ミドルウェアＢを介してＣＡＮバス上にフレームを送信できる。しかし、１つのＥＣＵには１つのＣＡＮ  Ｈ／Ｗが搭載されることが好ましいとされているため、アプリＡがアプリＢに送信するフレームをＣＡＮバス上に出力してしまうと、アプリＢがフレームを受信することが困難になる。この逆の場合も同様である。このため、アプリＡとアプリＢが通信するために、通信ミドルウェＡ，Ｂが通信できるように内部通信機能が必要になる。内部通信機能は、アプリＡが送信するフレームのＣＡＮ  ＩＤがアプリB宛の場合に、ＣＡＮ  Ｈ／Ｗを介することなく通信ミドルウェアＢに出力し、アプリＢが送信するフレームのＣＡＮ  ＩＤがアプリＡ宛の場合に、ＣＡＮ  Ｈ／Ｗを介することなく通信ミドルウェアＡに出力する。
【０００８】
このように、機能統合によりＣＡＮ通信を内部通信に置き換えると通信ミドルウェアＡ，Ｂに大規模なソフト変更が発生し、ソフトの再設計・再評価等の工程が増え、機能統合によるコスト低減効果が小さくなってしまう。
【０００９】
本発明は、上記課題に鑑み、通信ミドルウェアの変更を少なくして機能を統合可能な電子制御装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明は、ネットワークに接続された機器と通信する電子制御装置において、複数のアプリケーションプログラム及び複数の通信ミドルウェアを記憶したプログラム記憶手段と、プログラムを実行するプログラム実行手段と、通信プロトコルに基づく処理を行う複数の通信コントローラと、通信コントローラの送信端子の接続先を第１の接続先又は第２の接続先のどちらかに切り替える複数の送信切り替え手段と、入力側が複数の前記第１の接続先と接続され、出力側が第１のＤ／Ａ変換器を介して前記ネットワークに接続された通信データ選択手段と、前記送信切り替え手段に接続先を切り替えさせる接続先制御手段と、を有する。
【発明の効果】
【００１１】
通信ミドルウェアの変更を少なくして機能を統合可能な電子制御装置を提供することができる。
【図面の簡単な説明】
【００１２】
【図１】複数のＥＣＵを統合した際の構成例を説明する図の一例である。
【図２】ＣＡＮ通信の機能統合を模式的に説明する図の一例である。
【図３】統合ＥＣＵの機能ブロック図の一例である。
【図４】ＣＡＮプロトコルのフレームのフォーマットの一例である。
【図５】ＯＲ回路が出力するＬｏｗアクティブな信号を模式的に説明する図の一例である。
【図６】初期設定プログラムが設定する項目が登録された初期設定テーブルの一例を示す図である。
【図７】統合ＥＣＵの開発者の作業手順について説明する図の一例である。
【図８】統合ＥＣＵの動作手順の一例を示す図である。
【図９】統合ＥＣＵの機能ブロック図の一例である。
【発明を実施するための形態】
【００１３】
以下、本発明を実施するために形態について図面を参照しながら説明する。
【００１４】
図２は、本実施形態のＣＡＮ通信の機能統合を模式的に説明する図の一例である。図２（ａ）は図１（ａ）と同様に機能統合前の構成であり、ＥＣＵ‐Ａ、ＥＣＵ‐Ｂ及びＥＣＵ‐Ｃが互いにＣＡＮバスを介して通信している。
【００１５】
図２（ｂ）は機能統合後の内部のＣＡＮ通信を模式的に説明する図の一例である。本実施形態では機能統合後のＥＣＵ（electronic  control  unit）に複数のＣＡＮ  Ｈ／Ｗを接続する内部バスを設けることが特徴の１つである（以下、機能統合後のＥＣＵを統合ＥＣＵ１００という。）。内部バスの作用により、内部通信機能を実装する必要がなくなり、通信ミドルウェアＡ，Ｂに変更が生じることも防止できる。したがって、機能統合によるコスト低減効果が得られ易くなる。
【００１６】
〔構成例〕
図３は、本実施形態の統合ＥＣＵ１００の機能ブロック図の一例を示す。まず、統合ＥＣＵ１００はマイコン部９９とトランシーバＩＣ２００を有する。マイコン部９９は一般的な構成としてＣＰＵ１３、ＲＡＭ１２、周辺ＩＯ１４、及び、ＲＯＭ１１を有する。
【００１７】
ＲＯＭ１１には、統合前のＥＣＵ‐Ａが実装していたアプリＡ、統合前のＥＣＵ‐Ｂが実装していたアプリＢ、統合前のＥＣＵ‐Ａが実装していた通信ミドルウェアＡ、統合前のＥＣＵ‐Ｂが実装していた通信ミドルウェアＢ、及び、初期設定プログラムを記憶している。また、必要であればＯＳやデバイスドライバも記憶される。統合ＥＣＵ１００にｎ個のＥＣＵの機能が統合されている場合、ＲＯＭ１１にはｎ個以上のアプリや通信ミドルウェアが記憶されるが、図２との整合性を考慮して以下では主にアプリＡ，Ｂと通信ミドルウェアＡ，Ｂを用いて説明する。
【００１８】
ＣＰＵ１３は好ましくはマルチコア型のＣＰＵ１３であり、複数のコアがそれぞれアプリＡ，Ｂや通信ミドルウェアＡ，Ｂを実行することができる。コア間はハード的又はソフト的（ＯＳの提供する機能）により通信可能であるため、アプリＡ，Ｂ間で通信することも可能であるが、この場合はアプリＡ，Ｂに変更が必要になるため本実施形態では、上記の内部バスを介して通信するものとする。各コアは、命令バッファ、プログラムカウンタ、デコーダ、レジスタファイル、各種の演算器（ＬＳＵ：Load  Store  Unit、ＳＨ：ＳＨｉｆｔｅｒ、ＡＬＵ：Arithmetic  and  Logic  Unit、ＭＵＬ：multiply  integer)、ＦＰＵ：Floating  Point  number  processing  Unit）等を有し、パイプライン制御により１クロックで１命令以上実行することができる。ＲＡＭ１２は、各コアの作業メモリであり、一部を各コアが共有することができる。
【００１９】
また、周辺ＩＯ１４は不図示のバスブリッジを介してＣＰＵ１３等と接続されており、周辺ＩＯ１４には、センサ、スイッチ、アクチュエータ等の周辺機器が接続されている。そして、ＣＰＵ１３等にはバスを介して、通信コントローラ１５（以下、区別する場合通信コントローラ１〜ｎという）が接続されている。
【００２０】
通信ミドルウェアＡ，Ｂについて簡単に説明する。通信ミドルウェアＡ，Ｂは、アプリＡ，Ｂが送信要求したデータを通信コントローラＡ，Ｂのバッファに設定するプログラムである。
図４は、ＣＡＮプロトコルのフレームのフォーマットの一例を示す。「Start  of  Frame」はフレームの送信開始時にドミナント”１“となることで、受信側のＥＣＵに同期を取らせるフィールドである。「Control  Filed」には通信コントローラ１〜ｎに固有のＣＡＮ‐ＩＤが設定される。「Data  Length」には送信されるデータのバイト数が設定される。「Data  Field」にはアプリＡ，Ｂが送信要求したデータが設定される。「CRC  Field」にはCRC符号が設定される。「ACK」には１ビットのリセッシブ（送信の場合）が設定される。「End  of  Frame」には7ビットのリセッシブが設定される。通信ミドルウェアＡ，Ｂは、それぞれ統合前のＣＡＮ  ＩＤを「Control  Filed」に設定するなど、フレームの各フィールドに適切な値を設定する。通信ミドルウェアＡ，Ｂがフレームを通信コントローラＡ，Ｂの送信バッファに記憶すると、通信コントローラＡ，ＢはトランシーバＩＣ２００を介してＣＡＮバスから送信を開始する。
【００２１】
なお、通信ミドルウェアＡ，Ｂは、ＯＳＥＫ／ＶＤＸ（Offene  Systeme  und  deren  schnittstellen  fur  die  Elektronik  im  Kraftfahrzeug／Vehicle  Distributed  eX  ecutive）仕様に含まれるＯＳＥＫ／ＶＤＸ―ＮＭ（Network  Management）の規定に基づく通信を行う。この通信は各ＥＣＵが定期的に通信することで互いに他のＥＣＵの異常を検出したり、スリープ可否判定などを行うためのものである。
【００２２】
通信コントローラは従来のＣＡＮ  Ｈ／Ｗに相当するものであり、統合された機能の数に等しいｎ個の通信コントローラ１〜ｎが実装される。
【００２３】
通信コントローラ１〜ｎは、ＣＡＮの通信プロトコルに従って送信バッファのフレームをＮＲＺ（Non‐Return‐to‐Zero）方式でシリアルの送信信号に変換してトランシーバＩＣ２００に向けて出力する。すなわち、変換後の信号が“０（ドミナント）”のビットには論理レベルがLowの電圧を、“１(リセッシブ)”のビットには論理レベルがHighの電圧を出力する。
【００２４】
トランシーバＩＣ２００は通信コントローラ１〜ｎから取得した論理レベルの送信信号を対応する差動電圧に変換してＣＡＮバスに送信する。ＣＡＮバスは各ＥＣＵに接続されているので、各ＥＣＵ１００が同時に同じフレームを取得することができる。また、トランシーバＩＣ２００は、ＣＳＭＡ／ＣＤ（Carrier  Sense  Multiple  Access/Collision  Detection）に基づきＬｏｗをＨｉｇｈよりも優先して、ＣＡＮバスに送信する。
【００２５】
データの受信時、トランシーバＩＣ２００はＣＡＮバスの差動電圧を読み取り、所定の電圧範囲に含まれるように整形した受信信号を通信コントローラ１〜ｎに出力する。このように、トランシーバＩＣ２００はＤ／Ａ変換器及びＡ／Ｄ変換器の一種でもある。通信コントローラ１〜ｎの受信用の端子はコンパレータを有しており、所定の閾値電圧とトランシーバＩＣ２００からの受信信号とを比較して“１”、“０”のデジタルデータを生成して受信バッファに記憶する。通信コントローラ１〜ｎは、送信したデータと受信したデータを比較して、“１”が“０”に変化すると衝突を検知して送信を停止する。
【００２６】
なお、通信ミドルウェアＡ，Ｂにとって受信すべきフレームはＣＡＮ‐ＩＤ等により特定されており、通信ミドルウェアＡ，Ｂは、ＣＡＮ  ＩＤに基づき受信すべきフレームを選択している。
【００２７】
＜内部バス＞
通信コントローラ１〜ｎとトランシーバＩＣ２００との接続について説明する。通信コントローラ１〜ｎはそれぞれ送信端子Ｔｘ及び受信端子Ｒｘを有する。そして、送信端子Ｔｘは送信側ＳＷ１７と、受信端子Ｒｘは受信側ＳＷ１８とそれぞれ接続されている。送信側ＳＷ１７と受信側ＳＷ１８はそれぞれ通信コントローラ１〜ｎの数だけ存在する。送信側ＳＷ１７とＯＲ回路２３は送信バス２２により接続され、受信側ＳＷ１８とトランシーバＩＣ２００は受信バス２１により接続されている。送信側ＳＷ１７，受信側ＳＷ１８、送信バス２２、受信バス２１及びＯＲ回路２３が図２の内部バスに相当する。
【００２８】
送信側ＳＷ１７は、送信端子Ｔｘの接続先をＯＲ回路側とそれ以外に静的に切り替える。「静的に」とは、接続先は統合ＥＣＵ１００の起動時に固定され、起動中に動的には変化しないことをいう。また、ＯＲ回路以外の側とは、後述する別ネットワーク又は未使用端子の側である。
【００２９】
送信側ＳＷ１７がＯＲ回路側に接続された場合、送信端子ＴｘはＯＲ回路２３に接続された状態となる。ＯＲ回路２３は、各通信コントローラ１〜ｎの論理和を出力する回路である。ただし、ＣＡＮプロトコルでは、ドミナント“０”がリセッシブ“１”よりも優先されるので、ＯＲ回路２３はＬｏｗアクティブなＯＲ回路である。すなわち、複数の通信コントローラ１〜ｎが同時に“１”と”０“が混在する信号を送信した場合、ＯＲ回路２３は“０”の信号を選択してトランシーバＩＣ２００に出力する。したがって、一般的なＯＲ回路２３の作用（１つでも１が入力されると１を出力する）とは論理が逆になっている。
【００３０】
図５は、ＯＲ回路２３が出力するＬｏｗアクティブな信号を模式的に説明する図の一例である。図５（ａ）では４つの通信コントローラ１〜４がＣＡＮバスに接続されており、そのうちの３つの通信コントローラ１、２、３がデータを送信している。１つのＥＣＵに１つの通信コントローラしか搭載されない場合には、同時に２つのＥＣＵが送信を開始してデータが衝突しても、トランシーバＩＣ２００がドミナントを優先してＣＡＮバスに出力するので、２つのデータが互いに破壊し合うようなことは生じ得ない。
【００３１】
しかしながら、本実施形態の統合ＥＣＵ１００は、トランシーバＩＣ２００にデータが到達する前にデータを１つに集約しないと、データの相互破壊が生じてしまう。このようにトランシーバＩＣ２００よりも内側でデータを破壊することなく取捨するため、ＯＲ回路２３はＣＡＮプロトコルと同様にＬｏｗアクティブなデータを選択して出力する。
【００３２】
図５（ｂ）は通信コントローラ１〜３が出力したデータをビット単位で示す。ある時刻のデータを「通信コントローラ１
通信コントローラ２ 通信コントローラ３」の順に表すと、通信コントローラ１〜３が出力したデータは、時刻順に1「１１１」、２「１００」、３「０００」、４「１００」、５「１１１」、６「０１１」、７「１００」、８「０１０」、９「１１１」である。
・１ビット目では３つの信号が同じなので、いずれか1つを選択すればよい。
・２ビット目では通信コントローラ１のデータがリセッシブなので、ＯＲ回路２３は通信コントローラ１のデータを送信しない（遮断する）。これにより、ＯＲ回路２３は通信コントローラ２，３のどちらか1つの「０」を選択して出力するが、通信コントローラ１は、受信端子ＲＸから受信したデータが、送信したデータと異なることから送信を停止させる。
・３ビット目では通信コントローラ２，３のデータは共にドミナントなので、ＯＲ回路２３は通信コントローラ２，３のデータのどちらか1つを選択して出力する。
・４ビット目では通信コントローラ２，３のデータは共にドミナントなので、ＯＲ回路２３は通信コントローラ２，３のデータのどちらか1つを選択して出力する。
・５ビット目では通信コントローラ２，３のデータは共にリセッシブなので、ＯＲ回路２３は通信コントローラ２，３のデータのどちらか1つを選択して出力する。
・６ビット目では通信コントローラ２，３のデータは共にリセッシブなので、ＯＲ回路２３は通信コントローラ２，３のデータのどちらか1つを選択して出力する。
・７ビット目では通信コントローラ２，３のデータは共にドミナントなので、ＯＲ回路２３は通信コントローラ２，３のデータのどちらか1つを選択して出力する。
・８ビット目では通信コントローラ２のデータがリセッシブなので、ＯＲ回路２３は通信コントローラ２のデータを送信しない（遮断する）。これにより、ＯＲ回路２３は通信コントローラ３のデータの「０」を選択して出力するが、通信コントローラ２は、受信端子ＲＸから受信したデータが、送信したデータと異なることから送信を停止させる。
・９ビット目以降、ＯＲ回路２３は通信コントローラ３のみが送信するデータを出力する。
【００３３】
したがって、３つの通信コントローラ１〜３が同時にデータを送信しても、ＯＲ回路２３により通信コントローラ３のデータを破壊することなくトランシーバＩＣ２００に出力することができる。
【００３４】
なお、通信コントローラ３のデータが、ＣＡＮバスで他のＥＣＵのデータと衝突した場合は、通信コントローラ３は、受信端子ＲＸから受信したデータが、送信したデータと異なる場合に送信を停止させる。このように、ＣＡＮバス上では従来のＣＡＮプロトコルに従って、ＣＡＮバスの使用権が調停される。
【００３５】
トランシーバＩＣ２００の受信端子は、並列に全ての受信側ＳＷ１８に接続されている。このため、トランシーバＩＣ２００がＣＡＮバスからデータを受信した場合、トランシーバＩＣ２００は差動電圧をデジタルデータに変換して、全ての受信側ＳＷ１８に出力する。よって、トランシーバＩＣ２００側に切り替えられている受信側ＳＷ１８と接続された全ての通信コントローラ１〜ｎの受信端子Ｒｘがデータを受信する。したがって、複数の通信コントローラ１〜ｎがデータを受信しうるが、上記のように、データは通信ミドルウェア１〜ｎにより取捨される。
【００３６】
＜別のネットワーク＞
別ネットワークは、例えば、ＦｌｅｘＲａｙやＬＩＮなどのＣＡＮプロトコルとは異なる通信プロトコルのネットワークである。統合対象として検討されるＥＣＵが別の通信プロトコルで通信していても、例えば機能的に近いＥＣＵや、処理負荷が小さいため統合することが好ましいＥＣＵが存在すると考えられる。このような場合、本実施形態の統合ＥＣＵ１００は、通信プロトコルが異なっても、送信側ＳＷ１７と受信側ＳＷ１８を適切に切り替えることで、機能統合することが可能になる。したがって、本実施形態では、統合前のＥＣＵが他のＥＣＵと異なる通信プロトコルで通信していてもよい。
【００３７】
プロトコルが異なるとバスも異なるので、別ネットワーク側に切り替えられた送信側ＳＷ１７と受信側ＳＷ１８は、ＣＡＮプロトコルのトランシーバＩＣ２００とは別のトランシーバＩＣ２０１に接続される。図３では、通信コントローラｎと接続された送信側ＳＷ１７と受信側ＳＷ１８が別のネットワーク側（トランシーバＩＣ２０１側）に切り替えられている。
【００３８】
なお、送信側ＳＷ１７と受信側ＳＷ１８がＯＲ回路側に切り替えられた場合、送信側ＳＷ１７と受信側ＳＷ１８の別のネットワーク側の端子は未使用端子に接続され、送信側ＳＷ１７と受信側ＳＷ１８が別のネットワーク側に切り替えられた場合、送信側ＳＷ１７と受信側ＳＷ１８のＯＲ回路側の端子は未使用端子に接続される。
【００３９】
＜送信側ＳＷ１７と受信側ＳＷ１８の制御＞
続いて、送信側ＳＷ１７と受信側ＳＷ１８の接続先の切り替えについて説明する。通信コントローラ１〜ｎはそれぞれレジスタ（以下、区別するレジスタ１〜ｎという）１６を有している。レジスタ１〜ｎは送信側ＳＷ１７と受信側ＳＷ１８の接続先を指定する制御情報が設定される。例えば、レジスタ１〜ｎの制御情報が「１」に設定されていると、通信コントローラ１〜ｎは送信側ＳＷ１７をＯＲ回路側に切り替え、レジスタ１〜ｎの制御情報が「０」に設定されていると、通信コントローラ１〜ｎは送信側ＳＷ１７を別ネットワーク側に切り替える。
【００４０】
送信側ＳＷ１７と受信側ＳＷ１８は常に同じ側に切り替わるので、通信コントローラ１〜ｎはレジスタの制御情報の状態に応じて、受信側ＳＷ１８を送信側ＳＷ１７と同じ方向に切り替える。上述したように、統合ＥＣＵ１００は起動時に送信側ＳＷ１７と受信側ＳＷ１８を切り替えると、起動中はその状態を保つ。
【００４１】
レジスタ１〜ｎに制御情報を設定するのは初期設定プログラムである。従って、開発者はレジスタ操作のための変更を通信ミドルウェア１〜ｎに施すことも不要である。
図６は、初期設定プログラムが設定する項目が登録された初期設定テーブルの一例を示す図である。図６では通信コントローラ１〜ｎ毎に、動作クロック、出力端子の割り当て、レジスタ内容が登録される。「動作クロック」は通信コントローラ１〜ｎの初期の動作クロックであり、「出力端子の割り当て」は各通信コントローラ１〜ｎに割り当てられるマイコンの出力端子の番号であり、「レジスタ内容」はレジスタの制御情報の状態である。初期設定プログラムは統合ＥＣＵ１００の起動時に初期設定テーブルを読み出し、初期設定を行う。
【００４２】
レジスタ１〜ｎに制御情報が設定されると、通信コントローラ１〜ｎは送信側ＳＷ１７と受信側ＳＷ１８を切り替えてその状態を維持する。
【００４３】
〔作業フロー〕
図７に基づき、統合ＥＣＵ１００の開発者の作業手順について説明する。ここでは、ＥＣＵ‐ＡとＥＣＵ‐Ｂの機能を統合するものとする。
【００４４】
まず、開発者はＥＣＵ‐Ａをパーソナルコンピュータ等に接続し、ＥＣＵ‐Ａに搭載されているアプリＡ及び通信ミドルウェアＡを読み出して不揮発メモリに記憶する（Ｓ１０）。
【００４５】
同様に、開発者はＥＣＵ‐Ｂをパーソナルコンピュータ等に接続し、ＥＣＵ‐Ｂに搭載されているアプリＢ及び通信ミドルウェアＢを読み出して不揮発メモリに記憶する（Ｓ２０）。
【００４６】
開発者は、プログラムの開発環境を利用して初期設定プログラムをコーディングする（Ｓ３０）。すなわち、初期設定テーブルに新たにレジスタ内容の項目を設け、通信コントローラ１〜ｎ毎に１又は０の制御情報を設定する。また、初期設定プログラムに、レジスタに制御情報を設定する記述を追加する。
【００４７】
次に、開発者は統合ＥＣＵ１００をパーソナルコンピュータ等に接続し、機能統合後の１つのマイコン９９のＲＯＭ１１にアプリＡ，Ｂ、通信ミドルウェアＡ，Ｂ、初期設定プログラム及び初期設定テーブルを記憶させる（Ｓ４０）。
【００４８】
この後、開発者は統合ＥＣＵ１００を用いた様々な動作確認を行う（Ｓ５０）。
この作業フローからも明らかなように、アプリＡ，Ｂや通信ミドルウェアＡ，Ｂには何ら変更を加えることなく、開発者は初期設定テーブルに項目を追加し初期設定プログラムを修正するだけでよいので、アプリや通信ミドルウェアの再設計はほぼ不要であり、内部通信機能を追加する場合に比べて、機能統合によるコスト低減効果を十分に期待できるようになる。
【００４９】
〔動作手順〕
図８は、統合ＥＣＵ１００の動作手順の一例を示す図である。図８（ａ）は初期設定時の動作手順である。車両のスタートボタンがオンされたりＩＧ（イグニッション）がオンされると、統合ＥＣＵ１００がリセットされ、初期設定プログラムが起動される（Ｓ１１０）。ＣＰＵ１３は初期設定プログラムを実行して種々の初期設定を行う（Ｓ１２０）。これにより、通信コントローラ１〜ｎのレジスタ１〜ｎに制御情報が設定される。
【００５０】
レジスタ１〜ｎに制御情報が設定されと、通信コントローラ１〜ｎが送信側ＳＷ１７と受信側ＳＷ１８を切り替える（Ｓ１３０）。図８（ａ）は初期設定時の動作手順なので、起動時に１度実行されると終了する。
【００５１】
図８（ｂ）は、ＯＲ回路２３の動作手順の一例を示す図である。ＯＲ回路２３は同時に複数のデータを受け付けると作用する（Ｓ２１０）。すでに、いずれかの通信コントローラ１〜ｎがデータの送信を開始している場合、その他の通信コントローラ１〜ｎがデータを送信することはないので、ＯＲ回路２３は、同時に複数の通信コントローラ１〜ｎがデータの送信を開始した場合にだけ処理を開始し、そのうちの１つの通信コントローラ１〜ｎだけがデータを送信するようになると処理を終了する。
【００５２】
したがって、ＯＲ回路２３が同時に複数のデータを受け付けない場合（Ｓ２１０のＮｏ）、ＯＲ回路２３はデータを通過させる（Ｓ２３０）。
【００５３】
ＯＲ回路２３が同時に複数のデータを受け付けた場合（Ｓ２１０のＹｅｓ）、ＯＲ回路２３はドミナント“０”のデータを通過させる（Ｓ２２０）。こうすることで、送信されるデータをＬｏｗアクティブにすることができる。ドミナント“０”以外のデータを送信した通信コントローラ１〜ｎは、送信データと受信データの違いを検出する毎にデータの送信を停止するので、最終的にデータを送信する通信コントローラ１〜ｎは１つだけになる。送信を停止した通信コントローラ１〜ｎは不作為な時間、待機した後、データを再送信する。
【００５４】
〔変形例〕
ＯＲ回路２３はＬｏｗアクティブという調停論理でデータを通過させると説明した。こうすることでＣＡＮプロトコルとデータの優先度を一致させることができるため好ましいと考えられる。しかしながら、ＯＲ回路２３の調停論理はＥＣＵ内の調停論理なので、必ずしもＣＡＮプロトコルに従う必要はない。ＯＲ回路２３の調停論理として、例えば次のような調停論理がある。
・データが衝突した際に、送信を停止した通信コントローラ１〜ｎを記憶しておき、ＯＲ回路２３が空き次第、ＯＲ回路２３が送信を停止した通信コントローラ１〜ｎにデータの送信を許可する調停論理。
・データの衝突に関係なく、ＯＲ回路２３が予め定められた優先度に応じて通信コントローラ１〜ｎにポーリングする調停方法。
【００５５】
＜別ネットワークに複数の通信コントローラ１〜ｎが接続される場合＞
別ネットワークに接続される通信コントローラ１〜ｎが複数の場合、通信コントローラ１〜ｎをトランシーバＩＣ２０１に接続するために、ＯＲ回路２３に対応する調停手段が必要になる。
【００５６】
図９は、統合ＥＣＵ１００の機能ブロック図の一例を示す。図９は図３とほぼ同様であるがＯＲ回路２３以外にデータ中継回路２４を有する。データ中継回路２４は、通信コントローラ１〜ｎとトランシーバＩＣ２０１の送信端子の数の整合を取り、また、ＯＲ回路２３と同様に通信プロトコルに応じてデータを取捨する。
【００５７】
別ネットワークがＦｌｅｘＲａｙの通信プロトコルの場合、通信コントローラ１〜ｎ毎にデータを送信可能なタイムスロットが定められている。このため、通信コントローラ１〜ｎはマクロティックレベル（グローバル同期クロック）で常に同期を取りながら、自己が有するクロックでローカル時間を計測し、割り当てられたタイムスロットが到来するとデータを送信する。
【００５８】
このため、ＦｌｅｘＲａｙの通信コントローラ１〜ｎが複数ある場合、グローバル同期クロックが全ての通信コントローラ１〜ｎに供給される必要があるが、トランシーバＩＣ２０１が受信したデータは全ての通信コントローラ１〜ｎに提供されるので、受信側の不都合はない。
【００５９】
一方、送信時について、原則的にタイムスロットに調停は不要であるが、トランシーバＩＣ２０１の送信端子は１つなので複数の送信バス２２を集約するためにデータ中継回路２４を配置することが好ましい。また、ＦｌｅｘＲａｙではイベントドリブン型の送信も可能なので、データ中継回路２４は複数の送信端子ＴｘとトランシーバＩＣ２０１の間でＯＲ回路２３と同様に調停する。
【００６０】
また、別ネットワークがＬＩＮの通信プロトコルの場合、こちらもタイムスロット方式だが、送信するタイミングを制御するマスターノードが別ネットワーク上に接続されている。したがって、通信コントローラ１〜ｎはマスターノードから通信タイミングの指示を受けることが必要だが、受信時にはＦｌｅｘＲａｙと同様の理由で不都合はない。
【００６１】
また、ＬＩＮの通信コントローラ１〜ｎはイベントドリブンでデータを送信することはない。したがって、データ中継回路２４は複数の送信バス２２を集約するために配置される。
【００６２】
このように、別ネットワークに接続される通信コントローラ１〜ｎが複数ある場合は、通信コントローラ１〜ｎが従う通信プロトコルに適切なデータ中継回路２４を配置することで、送信バス２２を集約しながら通信プロトコルに従うことができる。
【００６３】
以上説明したように、本実施形態の統合ＥＣＵ１００は、機能統合により通信ミドルウェアＡ，Ｂに大規模なソフト変更を生じさせることなくＣＡＮ通信の機能を統合できる。このため、機能統合によるコスト低減効果を十分に期待できるようになる。
【符号の説明】
【００６４】
１１    ＲＯＭ
１２    ＲＡＭ
１３    ＣＰＵ
１４    周辺ＩＯ
１５    通信コントローラ
１６    レジスタ
１７    送信側ＳＷ
１８    受信側ＳＷ
２１    受信バス
２２    送信バス
２３    ＯＲ回路
１００    統合ＥＣＵ
２００、２０１  トランシーバＩＣ
【図１】
2012114724.tif 000003
【図２】
2012114724.tif 000004
【図３】
2012114724.tif 000005
【図４】
2012114724.tif 000006
【図５】
2012114724.tif 000007
【図６】
2012114724.tif 000008
【図７】
2012114724.tif 000009
【図８】
2012114724.tif 000010
【図９】
2012114724.tif 000011