JP2015154481A - 車両でのイーサネットとｃａｎ通信との間の信号変換を行うプロセッサ及び信号変換方法 - Google Patents

Abstract

【課題】本発明は、車両でのネットワークでイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ及び信号変換方法を提供する。【解決手段】ＣＡＮ通信とイーサネットとの間の信号変換を行う信号変換方法は、ＣＡＮメッセージに含まれた少なくとも一つのＣＡＮ信号のそれぞれに対する開始ビットを判断するステップ、及びそれぞれのＣＡＮ信号及びＣＡＮ信号に対応する開始ビットを互いに異なるフィールドに含むイーサネット信号を生成するステップ、を含み、少なくとも一つのＣＡＮ信号のそれぞれに対応する開始ビットフィールド及び信号フィールドを含むイーサネット信号を獲得するステップ、及び信号フィールドに含まれた信号をそれに対応する開始ビットフィールドが指示する位置に配置し、ＣＡＮメッセージを生成するステップ、を含むことを特徴とする。【選択図】図６

Description

本発明は、車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ及び信号変換方法に係り、より詳しくは、イーサネットとＣＡＮ通信とが共存する車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ及び信号変換方法に関する。

一般に、車両の内部における各制御器（例えば、電子制御装置：ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌ ｕｎｉｔ：ＥＣＵ）間の通信は、コントローラーエリアネットワーク（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ：以下、ＣＡＮという。）を通じて行われてきた。ところが、このようなＣＡＮ通信の速度が比較的遅いため、最近は、商用のイーサネット（登録商標）を車両制御器間の通信に導入しようとする動きが活発である。
商用のイーサネット（登録商標）を使用すると、通信速度を増加させることができると共に、低価の商用構成部品を使用することによってシステムの構成費用も低下させることができ、ＥＣＵローカルネットワークを一つの主システムバスに連結することによって配線及び連結構造を簡潔に維持することができる。
ただし、既設のＣＡＮ通信を基盤とする車両通信は今後も持続されると予想されるので、ＣＡＮとイーサネット（登録商標）とが共存する状態が今後も続くと考えられる。このため、車両ネットワークでイーサネット（登録商標）とＣＡＮ通信との間のデータ変換の技術革新が要求されている（例えば、特許文献１〜３参照）。

特開２０１１−１３８４６８号公報 特表２００９−５３８０７０号公報 特開２００７−２４３３１７号公報

本発明は、上記の問題点を解決するためになされたものであって、その目的とするところは、車両のネットワークでイーサネット（登録商標）とＣＡＮ通信との間の信号変換を行えるプロセッサ（処理器）及び信号変換方法を提供することにある。

上記の目的を達成するためになされた本発明のＣＡＮ（ＣｏｎｔｒｏｌＡｒｅａ Ｎｅｗｏｒｋ）通信とイーサネット（Ｅｔｈｅｒｎｅｔ（登録商標））との間の信号変換を行う方法は、ＣＡＮメッセージに含まれた少なくとも一つのＣＡＮ信号のそれぞれに対する開始ビットを判断するステップ、及びそれぞれのＣＡＮ信号及びＣＡＮ信号に対応する開始ビットを互いに異なるフィールドに含むイーサネット信号を生成するステップ、を含むことを特徴とする。

また、本発明のＣＡＮ通信とイーサネットとの間の信号変換を行う方法は、少なくとも一つのＣＡＮ信号のそれぞれに対応する開始ビットフィールド及び信号フィールドを含むイーサネット信号を獲得するステップ、及び信号フィールドに含まれた信号をそれに対応する開始ビットフィールドが指示する位置に配置し、ＣＡＮメッセージを生成するステップ、を含むことを特徴とする。

また、本発明のＣＡＮ通信とイーサネットとの間の信号変換を行うプロセッサは、ＣＡＮメッセージに含まれた少なくとも一つのＣＡＮ信号のそれぞれに対する開始ビットを判断し、それぞれのＣＡＮ信号及びＣＡＮ信号に対応する開始ビットを互いに異なるフィールドに含むイーサネット信号を生成するＣＡＮ処理モジュールを含むことを特徴とする。

併せて、本発明のＣＡＮ通信とイーサネットとの間の信号変換を行うプロセッサは、少なくとも一つのＣＡＮ信号のそれぞれに対応する開始ビットフィールド及び信号フィールドを含むイーサネット信号を獲得し、信号フィールドに含まれた信号をそれに対応する開始ビットフィールドが指示する位置に配置し、ＣＡＮメッセージを生成するＣＡＮ処理モジュールを含むことを特徴とする。

本発明によれば、本発明のネットワークでイーサネットとＣＡＮ通信との間の信号変換方法は効率の良い信号変換方法であり、本発明のプロセッサを通じて、ＣＡＮとイーサネットとの間のデータ交換をより効率的に行うことができる。

一般的な車両用プロトコル構成の一例を示す図である。 ＣＡＮ通信とイーサネットとの間の信号変換を行うプロセッサの構成を例示する図であって、（ａ）は、二つのＣＡＮネットワークがイーサネットを介して連結されたネットワーク構成の一例を示し、（ｂ）は、一つのプロセッサがＣＡＮ通信とイーサネットとの間の信号変換を双方向に行うプロセッサの構成を示す例を示す。 ＣＡＮ網とイーサネット網との間でデータフォーマット変換を行うプロセッサのプロトコルスタック構造及びその構造でのデータの変換過程の一例を示す図である。 本発明の一実施例に係るプロセッサのプロトコルスタック構造の一例を示す図であり、プロセッサのプロトコルスタックのアプリケーション階層の下位にそれぞれ（ａ）ＣＡＮ処理階層が設けられた場合、（ｂ）ＣＡＮ／イーサネット変換ＣＯＭ階層が設けられた場合を示す。 二つのＣＡＮネットワークがイーサネットを介して連結されたネットワークで本発明の一実施例に係るデータフォーマット変換が行われる過程の一例を示す図である。 本発明の一実施例に係るイーサネット信号フォーマットの一例を示す図である。 本発明の一実施例に係るイーサネット信号フォーマットが使用されるパケットのヘッダーフォーマットを説明するための図である。 本発明の一実施例に係るイーサネット信号フォーマットが適用され得るＩＥＥＥ １７２２．１標準によるフレーム構造の一例を示す図である。 本発明の一実施例に係るイーサネット信号フォーマットが適用され得るインターネットプロトコルによるフレーム構造の一例を示す図である。 ＣＡＮ信号が本発明の一実施例に係るイーサネット信号に変換される形態の一例を示す図であり、（ａ）は、合計３６ビットサイズの９個のＣＡＮ信号を含むＣＡＮメッセージフォーマットであり、（ｂ）は、各信号別にチャンネル番号、ターゲットＩＤ、開始ビット及びシグナルフィールドへの変換を示す。

以下、本発明に関連した車両用制御器について、図面を基により詳細に説明する。
以下の説明において使用される、構成要素に対する接尾辞“モジュール”及び“部”は、明細書の作成の容易さを考慮して付与または混用されたものであって、それ自体で互いに区別される意味または役割を有するものではない。

本発明に係るＣＡＮとイーサネットとの間の信号変換の方法を説明する前に、まず、ＣＡＮ通信とイーサネットとの間の信号変換が必要な理由を説明する。
イーサネットの場合、一般に車両の通信速度は１００Ｍｂｐｓ（メガバイト毎秒）または１Ｇｂｐｓ（ギガバイト毎秒）に固定されており、最大のフレームサイズは１５１８バイトである。これに比べて、ＣＡＮ通信の場合、１００ｋｂｐｓ〜５００ｋｂｐｓ（キロバイト毎秒）の速度を有し、１１ビットのＩＤ領域及び８バイトのデータ領域で構成されている。ＣＡＮデータは１０４ビットで構成されている。また、ＣＡＮメッセージは複数の信号で構成され、複数の信号を一つのメッセージにマッピングするためにデータリンク領域を有する。
さらに、イーサネットとＣＡＮ通信は、プロトコルスタックでメッセージの処理主体も異なっている。これを図１を基に説明する。図１は、一般的な車両用プロトコル構成の一例を示す図である。図１に示した車両用イーサネットのプロトコルスタックにおいて、ＣＡＮメッセージは、イーサネットＡＶＢ（オーディオビデオブリッジング）でないコマンド アンド シグナル（Ｃｏｍｍａｎｄ＆Ｓｉｇｎａｌ）部分で担当する。すなわち、ＣＡＮメッセージは、非ＡＶＢ（Ｎｏｎｅ ＡＶＢ）であって、インターネットプロトコル（ＩＰ）を用いた通信である。

上述したとおり、フレーム構造、速度、プロトコルスタック上のメッセージ処理主体などが異なる二つの方式が車両内に存在する場合に発生する問題を、図２を基に説明する。
図２は、ＣＡＮ通信とイーサネットとの間の信号変換を行うプロセッサの構成を例示する図である。
図２に示すとおり、ネットワークの種類が変更されるとき、各ネットワークに適する形にデータフォーマットを変換する過程が“プロセッサ”で行われると仮定する。一般的な“プロセッサ”は、ＣＡＮ網とイーサネット網との間で二つの方式のうちいずれか一つによるデータフォーマットを他の一つによるデータフォーマットに変換することができ、後述する図３のようなプロトコルスタック構造を有することができる。

図２の（ａ）は、二つのＣＡＮネットワークがイーサネットを介して連結されたネットワーク構成の一例であり、（ｂ）は、一つのプロセッサがＣＡＮ通信とイーサネットとの間の信号変換を双方向に行うプロセッサの構成の一例である。図２（ａ）に示すとおり、一つのＣＡＮ（ＣＡＮ１）からイーサネットを経て他のＣＡＮ（ＣＡＮ２）にＣＡＮデータが伝達される場合、ＣＡＮ１からイーサネットに、次いで再びイーサネットからＣＡＮ２に２回のデータフォーマット変換が要求される。このとき、ネットワークが効率的に動作するためには、プロセッサでの最小限のハードウェア／ソフトウェア資源で最小の時間内に各通信プロトコルに適したデータフォーマット変換が行われなければならない。このとき、図中第１の経路の場合は、低速の小さなデータが高速の大きなデータフレームに連結される場合であるので、第２の経路に比べて大きな問題は発生しない。その一方、第２の経路の場合は、高速の大きなデータが低速の小さなデータフレームに保存されなければならない場合であるので、問題が発生することが予想される。
上記の問題は、図２の（ｂ）に示した同一のプロセッサでイーサネットとＣＡＮネットワークとの間の双方向に変換する場合にも発生し得る。すなわち、図中第１の経路の場合は、低速の小さなデータが高速の大きなデータフレームに連結される場合であるので、大きな問題は発生しない。その一方、第２の経路の場合は、高速の大きなデータが低速の小さなデータフレームに保存されなければならない場合であるので、問題が発生することが予想される

図２に基づき説明したデータ経路について、図３を基にしてプロセッサのプロトコルスタックで説明する。
図３は、ＣＡＮ網とイーサネット網との間でデータフォーマット変換を行うプロセッサのプロトコルスタック構造及びその構造でのデータの変換過程の一例を示す図である。
図３に示したとおり、プロセッサのプロトコルスタックは、ＣＡＮネットワークのプロトコルスタック（図中左側）及びイーサネットのプロトコルスタック（図中右側）の構成要素を全て備えて、一つの最上層のアプリケーション階層を共有する形態で構成される。ここで、図２（ｂ）の第１の経路、すなわち、ＣＡＮデータがイーサネットによるデータフォーマットに変更される過程を見ると、ＣＡＮ送受信（ＣＡＮトランシーバ）階層で受信されたＣＡＮデータは、上位階層に順次上昇しながらデカプセル化（ｄｅｃａｐｓｕｌａｔｉｏｎ）され、ＣＡＮデータを生成したソースから目的地に伝送しようとしたデータ自体がアプリケーション階層に伝達される。伝達されたデータは、再びイーサネットプロトコルによるカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）手順に従ってイーサネットフレームに変換され、積層された階層を通じてイーサネット網に送られる。第２の経路の場合、第１の経路と反対の順に変換が行われる。一方、図３では、フレーム変換過程でＣＡＮデータがＩＰ階層を経てイーサネットフレームに変換されると仮定したが、本発明は、必ずしもこれに限定されるものではなく、ＩＰ階層の代わりにイーサネットＡＶＢを経る場合（すなわち、第１’の経路及び第２’の経路）にも適用可能であることは当然である。

上記のＣＡＮ／イーサネット間のフレーム変換手順で生ずる問題を説明する。
上述のとおり、イーサネットは、ＣＡＮに比べて大きなフレーム構造を有するので、ＣＡＮメッセージ全体をイーサネットフレームのペイロードに含ませることができる。しかし、ＣＡＮ１網からＣＡＮ２網にメッセージがそのまま複製される事例では、ＣＡＮ１のメッセージを含むイーサネットフレームが再びＣＡＮ２フレームに変換されるとき、大きなデータフレームから小さなデータフレームに変換される過程でのデータ分割／マッピングの問題が発生し得る。また、変換時ごとに最上位階層であるアプリケーション階層まで経るので、速度面でも問題が発生する。
したがって、本発明の一実施例では、最小限のハードウェア／ソフトウェア資源で最小の変換所要時間を有するように、新たなプロセッサのプロトコルスタック構造及びこれに適用されるＣＡＮデータと関連したイーサネットシグナルのフォーマットを提案する。

具体的に、本発明に係るプロセッサは、アプリケーション階層の下位に別途にフォーマット変換過程を処理するＣＡＮ処理階層を有し、これを通じてデータフォーマット変換を行うことを提案する。これを図４に基づいて説明する。
図４は、本発明の一実施例に係るプロセッサのプロトコルスタック構造の一例を示す図であり、プロセッサのプロトコルスタックのアプリケーション階層の下位にそれぞれ（ａ）ＣＡＮ処理階層が設けられた場合、（ｂ）ＣＡＮ／イーサネット変換ＣＯＭ階層が設けられた場合を示す。
本発明に係るプロセッサのプロトコルスタックには、アプリケーション階層の下位にＣＡＮ処理階層４０１が備えられる。一方、ＣＡＮ処理階層とＣＯＭ／データリンク階層が一つの変換処理単位４１０として具現される場合、図４の（ｂ）のとおり、ＣＡＮ／イーサネット変換ＣＯＭ階層４２０を備えることもできる。

図４に示す構造が適用される場合、図２（ａ）のネットワーク構成でのデータフォーマット変換過程は、図５のとおり行うことができる。
図５は、二つのＣＡＮネットワークがイーサネットを介して連結されたネットワークで本発明の一実施例に係るデータフォーマット変換が行われる過程の一例を示す図である。
図５に示すとおり、第１の経路の場合、プロセッサのプロトコルスタックでＣＡＮに対応するスタックのＣＯＭ階層までは図３に示す構成と類似しているが、その後、アプリケーション階層を経る代わりにＣＡＮ処理階層を経るという点において相違している。また、反対（第２の経路）の場合、プロトコルスタックでイーサネットに対応するスタックのコマンド アンド シグナル（Ｃｏｍｍａｎｄ＆Ｓｉｇｎａｌ）階層までは図３に示す構成と類似しているが、その後、アプリケーション階層を経る代わりにＣＡＮ処理階層を経るという点において相違している。このとき、具現によってＣＡＮ処理階層を経て変換されたＣＡＮデータは、ＣＯＭ階層とデータリンク階層を経ずに直ぐＣＡＮドライバー階層に伝達されることもある。

ところが、上記のＣＡＮ処理階層での変換効率を増大させる（例えば、速度を高め、ハードウェア／ソフトウェア要求事項を低下させる）ためには、イーサネットネットワーク５００で使用されるＣＡＮデータと関連したイーサネットシグナルのフォーマットの構造が重要である。このために、本発明では、ＣＡＮメッセージを、これを構成する信号単位に分割し、イーサネットシグナルに変換することを提案する。また、分割された各信号を再びＣＡＮメッセージに復元するために、各信号別に元のＣＡＮメッセージで配置される位置を示すビット番号を用いることを提案する。これを図６を参照して説明する。
図６は、本発明の一実施例に係るイーサネット信号フォーマットの一例を示す図である。
図６に示したとおり、本発明に係るＣＡＮと関連したイーサネット信号フォーマットは、ＣＡＮメッセージの信号のそれぞれに対応するチャンネル番号フィールド、ターゲットＩＤフィールド、開始ビットフィールド及びシグナルフィールドを含むことができる。すなわち、一つのＣＡＮ信号は、復元のために最大４個のフィールドを用いてイーサネット信号に変換される。

各フィールドに対する説明は、次の通りである。
チャンネル番号（Ｃｈａｎｎｅｌ Ｎｕｍｂｅｒ）フィールドは、プロセッサが有している複数の（ハードウェア）ＣＡＮチャンネルのうちターゲットチャンネルを意味する。本フィールドは、ネットワーク構成に応じて省略が可能である。
ターゲットＩＤフィールドは、マッピングされるＣＡＮメッセージのＩＤであって、標準（Ｓｔａｎｄａｒｄ）フォーマットの場合は１１ビットで、拡張（Ｅｘｔｅｎｄｅｄ）フォーマットの場合は２９ビットで構成することができる。
開始ビット（Ｓｔａｒｔ ｂｉｔ）フィールドは、マッピング情報であって、信号がＣＡＮメッセージにマッピングされたとき、ＣＡＮメッセージでの開始位置を示す。
シグナル（Ｓｉｇｎａｌ）フィールドはＣＡＮ信号と一致する。
以上の内容をまとめると、チャンネル番号及びターゲットＩＤフィールドを通じてＣＡＮメッセージが伝達されるべきターゲットチャンネル及びメッセージＩＤが特定されることによって、ＣＡＮヘッダーを構成することができ、シグナルフィールドに含まれるシグナルが、ＣＡＮメッセージ内で開始ビットフィールドが指示するビットから配置されることによって、ＣＡＮメッセージを構成することができる。したがって、イーサネット信号をＣＡＮメッセージに効率的に変換することができる。

以下に、上記のイーサネット信号フォーマットが使用される具体的な適用例を説明する。
図７は、本発明の一実施例に係るイーサネット信号フォーマットが使用されるパケットのヘッダーフォーマットを説明するための図である。
図７に示したとおり、イーサネットの共用パケットのヘッダーフォーマットは、共用パケットのパケットヘッダーフォーマットと共用ストリームデータのパケットヘッダーフォーマットとに大きく区分することができる。ここで、共用パケットのパケットヘッダーフォーマットは、インターネットプロトコルを介したＣＡＮデータのカプセル化（７１０）に使用することができ、共用ストリームデータのパケットヘッダーフォーマットは、ＩＥＥＥ １７２２．１標準によるＣＡＮデータのカプセル化（７２０）に使用することができる。

上記の各方式による各カプセル化の具体的な適用例は、図８及び図９を参照して説明する。
図８は、本発明の一実施例に係るイーサネット信号フォーマットが適用され得るＩＥＥＥ １７２２．１標準によるフレーム構造の一例を示す図であり、図９は、本発明の一実施例に係るイーサネット信号フォーマットが適用され得るインターネットプロトコルによるフレーム構造の一例を示す図である。
ＩＥＥＥ １７２２．１標準によるＣＡＮデータのカプセル化には、図８に示すフレーム構造を使用することができる。ヘッダーの場合、ＩＥＥＥ ８０２．３標準によるＭＡＣヘッダーを使用することができ、本発明に係るイーサネット信号フォーマットを構成する各フィールドは、ペイロード８１０部分に含ませることができる。ヘッダーを構成する各フィールドの説明は、ＩＥＥＥ １７２２．１及びＩＥＥＥ ８０２．３標準に明示されており、ここでは、本発明の一実施例に係るイーサネット信号フォーマットが適用され得るＩＥＥＥ １７２２．１標準によるフレーム構造の一例を示す。
次に、インターネットプロトコルによるＣＡＮデータのカプセル化には、図９に示すフレーム構造が使用される。ＩＰヘッダーを使用するフレームでも、本発明に係るイーサネット信号フォーマットを構成する各フィールドはペイロード９１０部分に含ませることができる。このとき、ペイロードには、サブタイプフィールド及びサブタイプデータフィールドをさらに含ませることもできる。サブタイプフィールドはプロトコルタイプを定義し、サブタイプデータフィールドはタイプ特定データ（ｔｙｐｅ ｓｐｅｃｉｆｉｃ ｄａｔａ）を含むことができる。

以下に図１０を基に、ＣＡＮメッセージを構成する各信号が本発明に係るイーサネット信号に変換される具体的な例を説明する。
図１０は、ＣＡＮ信号が本発明の一実施例に係るイーサネット信号に変換される形態の一例を示す図であり、（ａ）は、合計３６ビットサイズの９個のＣＡＮ信号を含むＣＡＮメッセージフォーマットであり、（ｂ）は、各信号別にチャンネル番号、ターゲットＩＤ、開始ビット及びシグナルフィールドへの変換を示す。
図１０において、ＣＡＮメッセージに含まれる各信号は０番のターゲットチャンネルに向かい、メッセージＩＤは３であると仮定する。
図１０（ａ）には、合計３６ビットサイズの９個のＣＡＮ信号を含むＣＡＮメッセージフォーマットが示される。このようなＣＡＮメッセージは、本発明に係るイーサネット信号に変換される場合、図１０（ｂ）のとおり、各信号別にチャンネル番号、ターゲットＩＤ、開始ビット及びシグナルフィールドに変換される。例えば、ＤＶＤタイムアワー（ＤＶＤ＿ｔｉｍｅｈｏｕｒ）シグナルは、ＣＡＮメッセージで最初のビットから配置されるので、開始ビットフィールド値は０になり、ＤＶＤタイムミニット（ＤＶＤ＿ＴｉｍｅＭｉｎ）シグナルは、９番目のＣＡＮメッセージで９番目のビットから配置されるので、開始ビットフィールド値は８になる。その一方、図１０（ｂ）に示した信号フォーマットが再びＣＡＮメッセージに変換される場合は、各信号が開始ビットフィールドを通じて指示される位置に順次配置されることによって、ＣＡＮメッセージを復元することができる。

以上に説明したフォーマット変換方法を順序に沿ってまとめると、次の通りである。
まず、フォーマット変換を行うプロセッサでＣＡＮネットワークからＣＡＮフレームを受信する。受信されたＣＡＮフレームは、ＣＡＮプロトコルスタックの上位に伝達されることによってデカプセル化され、少なくとも一つのＣＡＮ信号を含むＣＡＮメッセージを獲得することができる。ＣＡＮ処理階層では、ＣＡＮメッセージに含まれる少なくとも一つのＣＡＮ信号のそれぞれに対する開始ビットを判断し、上記それぞれのＣＡＮ信号及びＣＡＮ信号に対応する開始ビットを互いに異なるフィールドに含むイーサネット信号を生成する。生成されたイーサネット信号は、再びイーサネットプロトコルスタックの下位階層に伝達されながらカプセル化され、イーサネットフレームが生成される。生成されたイーサネットフレームは、イーサネットネットワークに伝送することができる。このように伝送されたイーサネットフレームは、再び反対の過程を経てＣＡＮフレームに変換することができる。

上記のとおり、プロセッサのプロトコルスタック構造及びこのためのイーサネット信号フォーマットを通じて、ＣＡＮ／イーサネット間のデータフォーマット変換を効率的に行うことができる。上記のプロトコルスタック構造における各階層は、一つ以上のモジュールによって具現することもでき、複数の階層を一つのモジュールとして具現することもできる。例えば、図４において、ＣＯＭ階層、データリンク階層及びＣＡＮ処理階層は、三つの互いに異なるモジュールとして具現することもでき、一つのモジュールを通じてＣＡＮ／イーサネット変換ＣＯＭ階層の形態に具現することもでき、その中間の形態に二つのモジュールとして具現することもできる。

以上のとおり説明した車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ及び信号変換方法は、上述した各実施例の構成と方法が限定的に適用されるものではなく、各実施例の多様な変形が可能になるように各実施例の全部または一部を選択的に組み合わせて構成することもできる。

４０１ ＣＡＮ処理階層
４１０ 変換処理単位
４２０ ＣＡＮ／イーサネット変換ＣＯＭ階層
５００ イーサネットネットワーク
７１０ インターネットプロトコルを介したＣＡＮデータのカプセル化
７２０ ＩＥＥＥ １７２２．１標準によるＣＡＮデータのカプセル化
８１０，９１０ ペイロード

Claims (24)

1. ＣＡＮ（Ｃｏｎｔｒｏｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）通信とイーサネット（Ｅｔｈｅｒｎｅｔ（登録商標））との間の信号変換を行う方法において、
   ＣＡＮメッセージに含まれた少なくとも一つのＣＡＮ信号のそれぞれに対する開始ビットを判断するステップ、及び
   それぞれの前記ＣＡＮ信号及び該ＣＡＮ信号に対応する前記開始ビットを互いに異なるフィールドに含むイーサネット信号を生成するステップを含むことを特徴とする車両でのイーサネットとＣＡＮ通信との間の信号変換方法。
2. ＣＡＮネットワークからＣＡＮフレームを受信するステップ、
   前記ＣＡＮフレームをデカプセル化して前記ＣＡＮメッセージを獲得するステップ、
   前記イーサネット信号をカプセル化してイーサネットフレームを生成するステップ、及び
   生成した前記イーサネットフレームをイーサネットネットワークに伝送するステップ、をさらに含むことを特徴とする請求項１に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換方法。
3. 前記開始ビットを判断するステップ及び前記イーサネット信号を生成するステップは、
   アプリケーション階層の下位に位置するＣＡＮ処理階層で行われることを特徴とする請求項１に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換方法。
4. 前記イーサネット信号は、
   前記ＣＡＮメッセージのＩＤに対応するフィールド、及び前記ＣＡＮメッセージのターゲットチャンネルを指示するフィールドをさらに含むことを特徴とする請求項１に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換方法。
5. 前記ＣＡＮメッセージのＩＤに対応するフィールド及び前記ＣＡＮメッセージのターゲットチャンネルを指示するフィールドは、
   少なくとも一つの信号のそれぞれごとに前記イーサネット信号に含まれることを特徴とする請求項４に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換方法。
6. 前記イーサネット信号は、
   前記イーサネットフレームのペイロードに含まれることを特徴とする請求項２に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換方法。
7. ＣＡＮ（Ｃｏｎｔｒｏｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）通信とイーサネット（登録商標）との間の信号変換を行う方法において、
   少なくとも一つのＣＡＮ信号のそれぞれに対応する開始ビットフィールド及び信号フィールドを含むイーサネット信号を獲得するステップ、及び
   前記信号フィールドに含まれた信号をそれに対応する開始ビットフィールドが指示する位置に配置し、ＣＡＮメッセージを生成するステップ、を含むことを特徴とする車両でのイーサネットとＣＡＮ通信との間の信号変換方法。
8. イーサネットネットワークからイーサネットフレームを受信するステップ、
   前記イーサネットフレームをデカプセル化するステップ、
   前記ＣＡＮメッセージをカプセル化してＣＡＮフレームを生成するステップ、及び
   生成された前記ＣＡＮフレームをＣＡＮネットワークに伝送するステップ、をさらに含むことを特徴とする請求項７に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換方法。
9. 前記ＣＡＮメッセージを生成するステップは、
   アプリケーション階層の下位に位置するＣＡＮ処理階層で行われることを特徴とする請求項７に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換方法。
10. 前記イーサネット信号は、
    前記ＣＡＮメッセージのＩＤに対応するフィールド、及び前記ＣＡＮメッセージのターゲットチャンネルを指示するフィールドをさらに含むことを特徴とする請求項７に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換方法。
11. 前記ＣＡＮメッセージのＩＤに対応するフィールド及び前記ＣＡＮメッセージのターゲットチャンネルを指示するフィールドは、
    少なくとも一つの信号のそれぞれごとに前記イーサネット信号に含まれることを特徴とする請求項１０に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換方法。
12. 前記イーサネット信号は、
    前記イーサネットフレームのペイロードに含まれることを特徴とする請求項８に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換方法。
13. ＣＡＮ（Ｃｏｎｔｒｏｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）通信とイーサネット（登録商標）との間の信号変換を行うプロセッサにおいて、
    ＣＡＮメッセージに含まれた少なくとも一つのＣＡＮ信号のそれぞれに対する開始ビットを判断し、それぞれの前記ＣＡＮ信号及び該ＣＡＮ信号に対応する開始ビットを互いに異なるフィールドに含むイーサネット信号を生成するＣＡＮ処理モジュールを含むことを特徴とする車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ。
14. ＣＡＮネットワークからＣＡＮフレームを受信し、前記ＣＡＮフレームをデカプセル化して前記ＣＡＮメッセージを獲得するＣＡＮモジュール及び
    前記イーサネット信号をカプセル化してイーサネットフレームを生成し、生成した前記イーサネットフレームをイーサネットネットワークに伝送するイーサネットモジュールをさらに含むことを特徴とする請求項１３に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ。
15. 前記ＣＡＮ処理モジュールは、
    プロトコルスタックでアプリケーション階層の下位に位置することを特徴とする請求項１３に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ。
16. 前記イーサネット信号は、
    前記ＣＡＮメッセージのＩＤに対応するフィールド、及び前記ＣＡＮメッセージのターゲットチャンネルを指示するフィールドをさらに含むことを特徴とする請求項１３に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ。
17. 前記ＣＡＮメッセージのＩＤに対応するフィールド及び前記ＣＡＮメッセージのターゲットチャンネルを指示するフィールドは、
    少なくとも一つの信号のそれぞれごとに前記イーサネット信号に含まれることを特徴とする請求項１６に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ。
18. 前記イーサネット信号は、
    前記イーサネットフレームのペイロードに含まれることを特徴とする請求項１４に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ。
19. ＣＡＮ（Ｃｏｎｔｒｏｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）通信とイーサネット（登録商標）との間の信号変換を行うプロセッサにおいて、
    少なくとも一つのＣＡＮ信号のそれぞれに対応する開始ビットフィールド及び信号フィールドを含むイーサネット信号を獲得し、前記信号フィールドに含まれた信号をそれに対応する前記開始ビットフィールドが指示する位置に配置し、ＣＡＮメッセージを生成するＣＡＮ処理モジュールを含むことを特徴とする車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ。
20. イーサネットネットワークからイーサネットフレームを受信し、前記イーサネットフレームをデカプセル化するイーサネットモジュール、及び
    前記ＣＡＮメッセージをカプセル化してＣＡＮフレームを生成し、生成された前記ＣＡＮフレームをＣＡＮネットワークに伝送するＣＡＮモジュール、をさらに含むことを特徴とする請求項１９に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ。
21. 前記ＣＡＮ処理モジュールは、
    プロトコルスタックでアプリケーション階層の下位に位置することを特徴とする請求項１９に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ。
22. 前記イーサネット信号は、
    前記ＣＡＮメッセージのＩＤに対応するフィールド、及び前記ＣＡＮメッセージのターゲットチャンネルを指示するフィールドをさらに含むことを特徴とする請求項１９に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ。
23. 前記ＣＡＮメッセージのＩＤに対応するフィールド及び前記ＣＡＮメッセージのターゲットチャンネルを指示するフィールドは、
    少なくとも一つの信号のそれぞれごとに前記イーサネット信号に含まれることを特徴とする請求項２２に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ。
24. 前記イーサネット信号は、
    前記イーサネットフレームのペイロードに含まれることを特徴とする請求項２０に記載の車両でのイーサネットとＣＡＮ通信との間の信号変換を行うプロセッサ。

Images