(57)【要約】【課題】通信線を介してフレームを送受信する通信装置において、データの伝送効率の低下を抑制しつつ、多くの種別領域を確保できるようにする。【解決手段】通信システム１において、ＥＣＵ２０，３０，４０は、フレーム生成部２３と、送信部２４とを備える。フレーム生成部２３は、データの種別を表す種別領域、およびデータの長さを示すデータ長領域、が含まれるフレームであって、データ長領域の少なくとも一部を種別領域の一部としたフレームを生成する。そして、送信部２４は、フレーム生成部２３によって生成されたフレームを通信線５上に送信する。【選択図】図１
2017118317.tif 000002
【特許請求の範囲】
【請求項１】
通信線を介してフレーム（６０）の送受信を行う通信装置（２０，３０，４０）であって、
データの種別を表す種別領域（６２）、およびデータの長さを示すデータ長領域（６６）、が含まれるフレームであって、前記データ長領域の少なくとも一部を前記種別領域の一部としたフレームを生成するフレーム生成部（２３）と、
前記フレーム生成部によって生成されたフレームを前記通信線上に送信する送信部（２４）と、
を備えた通信装置。
【請求項２】
請求項１に記載の通信装置であって、
他の通信装置から送信されたフレームを受信する受信部（２６）と、
受信したフレームから前記種別領域および前記データ長領域を抽出し、前記種別領域および前記データ長領域に含まれるデータに基づいてデータの種別を認識するデータ認識部（２７）と、
をさらに備えた通信装置。
【請求項３】
請求項２に記載の通信装置であって、
前記データ長領域は、データ長が特定の値である際に、データ値が無効となる無効領域を有するよう設定されており、
前記フレーム生成部は、前記データ長領域に前記無効領域を有する際に、前記データ長領域の少なくとも一部を前記種別領域の一部としたデータを生成し、
前記データ認識部は、受信したデータのデータ長領域に前記無効領域を有する際に、前記種別領域および前記無効領域に含まれるデータに基づいてデータの種別を認識する
通信装置。
【請求項４】
請求項１〜請求項３の何れか１項に記載の通信装置であって、
当該通信装置はＣＡＮ（Controller Area Network：登録商標）プロトコルにより通信を行い、
前記データ長領域として、４ビットのＤＬＣ（Data Length Code）の領域が設定されている
通信装置。
【請求項５】
請求項４に記載の通信装置であって、
前記ＤＬＣの領域における下位３ビットが種別領域の一部として設定されている
通信装置。
【請求項６】
請求項４または請求項５に記載の通信装置であって、
前記ＤＬＣの領域における下位３ビットは、相手先を特定するために領域として用いられる
通信装置。
【請求項７】
データの種別を表す種別領域と、データの長さを示すデータ長領域とが含まれるフレームであって、前記データ長領域の少なくとも一部を前記種別領域の一部としたフレームを受信する受信部（２６）と、
受信したフレームから前記種別領域および前記データ長領域を抽出し、前記種別領域および前記データ長領域に含まれるデータに基づいてデータの種別を認識するデータ認識部（２７）と、
を備えた通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、通信線を介してフレームを送受信する通信装置に関する。
【背景技術】
【０００２】
特許文献１には、上記通信装置として、送受信する実質的なデータを表す実データが含まれるフレームのうちの、データ長を示す情報が格納されるデータ長領域を、実データを格納するための領域にも利用している。この構成では、データ長領域の一部を用いて実データを送ることができるので、実データの通信効率を向上させることができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１４−２０４２８７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、上記のような通信装置には、フレームの一部にデータの種別を表す種別領域を持たせたものがある。種別領域として多くの領域を確保し、より多くのデータの種別を識別できるようにすることへの要求があるが、種別領域として多くの領域を確保すると実データの通信効率が低下するという問題がある。
【０００５】
本開示の一局面は、通信線を介してフレームを送受信する通信装置において、データの伝送効率の低下を抑制しつつ、多くの種別領域を確保できるようにすることが望ましい。
【課題を解決するための手段】
【０００６】
本開示の一側面の通信装置において、フレーム生成部（２３）と、送信部（２４）とを備える。
フレーム生成部は、データの種別を表す種別領域（６２）、およびデータの長さを示すデータ長領域（６６）、が含まれるフレーム（６０）であって、データ長領域の少なくとも一部を種別領域の一部としたフレームを生成する。そして、送信部は、フレーム生成部によって生成されたフレームを通信線上に送信する。
【０００７】
また、本開示の一側面の通信装置において、受信部（２６）とデータ認識部（２７）とを備える。受信部は、データの種別を表す種別領域と、データの長さを示すデータ長領域とが含まれるフレームであって、データ長領域の少なくとも一部を種別領域の一部としたフレームを受信する。また、データ認識部は、受信したフレームから種別領域およびデータ長領域を抽出し、種別領域およびデータ長領域に含まれるデータに基づいてデータの種別を認識する。
【０００８】
これらのような通信装置によれば、データ長領域の少なくとも一部を種別領域の一部として利用するので、データの伝送効率の低下を抑制しつつ、多くの種別領域を確保することができる。なお、この欄および特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本開示の技術的範囲を限定するものではない。
【図面の簡単な説明】
【０００９】
【図１】通信システムの構成を示すブロック図である。
【図２】通信フレームの構成例を示す説明図である。
【図３】ＤＬＣを宛先に利用する際のデータ設定例である。
【図４】ＤＬＣを利用できない場合のデータ設定例である。
【図５】ＥＣＵのデータ認識部が実行する受信処理を示すフローチャートである。
【発明を実施するための形態】
【００１０】
以下、本開示の例示的な実施形態について図面を参照しながら説明する。
［１．第１実施形態］
［１−１．構成］
図１に示す通信システム１は、例えば乗用車等の車両に搭載されたものであり、テスタ１０と、複数のＥＣＵ２０，３０，３５，３６，３７，４０と、を備える。テスタ１０は、１または複数のＥＣＵ２０，３０，３５，３６，３７，４０を指定し、指定したＥＣＵに対してデータを要求したり、指定したＥＣＵにおけるプログラムを書き換えたりする機能を有する。また、テスタ１０は、通信線５に対して着脱自在に構成されており、通信線５に接続されたときに、通信線５を介した通信を実施する。
【００１１】
複数のＥＣＵのうちのＥＣＵ２０，４０は、通信線５に接続されており、複数のＥＣＵのうちのＥＣＵ３５，３６，３７は、通信線５とは異なる通信線６に接続されている。ＥＣＵ３０は、通信線５，６の両方に接続されており、通信線５，６間でデータを中継する中継装置として機能する。
【００１２】
テスタ１０およびＥＣＵ２０，３０，４０は、通信線５を介してＣＡＮ（Controller Area Network：登録商標）プロトコルにより通信を行うよう。また、ＥＣＵ３０，３５，３６，３７は、通信線６を介してＬＩＮ（Local Interconnect Network）プロトコルによって通信を行う。
【００１３】
各ＥＣＵ２０，３０，３５，３６，３７，４０は、ＥＣＵ毎に予め設定された周知の電子制御装置としての機能を有する。例えば、エンジン、ブレーキ、エアコン、カーナビ等、車両に搭載された構成要素を制御する機能を個々に有する。
【００１４】
以下においては、テスタ１０および複数のＥＣＵ２０，３０，３５，３６，３７，４０についての通信に関する機能について説明する。なお、通信線６に接続されたＥＣＵ３５，３６，３７については、ＬＩＮによる通信を行う周知の構成を有しているため説明を省略し、通信線５に接続されたＥＣＵ２０，３０，４０および通信線５に接続されうるテスタ１０について説明する。ただし、テスタ１０およびＥＣＵ２０，３０，４０については同等の通信に関する機能を有するため、これらを代表してＥＣＵ２０について説明する。
【００１５】
ＥＣＵ２０は、ＣＰＵ２１と、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の半導体メモリ（以下、メモリ２２）と、を有する周知のマイクロコンピュータを中心に構成される。ＥＣＵ２０の各種機能は、ＣＰＵ２１が非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、メモリ２２が、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。なお、ＥＣＵ２０を構成するマイクロコンピュータの数は１つでも複数でもよい。
【００１６】
ＥＣＵ２０は、ＣＰＵ２１がプログラムを実行することで実現される機能の構成として、図１に示すように、フレーム生成部２３と、送信部２４と、受信部２６と、データ認識部２７とを備える。ＥＣＵ２０を構成するこれらの要素を実現する手法はソフトウェアに限るものではなく、その一部または全部の要素を、論理回路やアナログ回路等を組み合わせたハードウェアを用いて実現してもよい。
【００１７】
［１−２．処理］
フレーム生成部２３は、ＥＣＵ２０においてイベントが発生した場合等、送信すべきデータについてのデータフレーム６０を生成し、送信部２４に送る。データフレーム６０は、送受信されるデータの全てを表し、データフレーム６０には、図２に示すように、ＩＤ６２、コントロールフィールド６４、およびデータフィールド６８が含まれる。
【００１８】
ＩＤ６２は、例えば１１ビットの領域が準備されており、データの種別を表す情報が格納される。コントロールフィールド６４は、８ビットの領域が準備されており、そのうちの下位４ビットにデータの長さを示すＤＬＣ（Data Length Code）６６が割り当てられる。データの長さとは、フレームにおいて送信されるデータの大きさを示す。ＤＬＣ６６においては、４ビットで表現できる０−１５の数のうち、０−８を用いてデータフィールド６８のデータの長さをバイト数で表現する。
【００１９】
すなわち、例えばＤＬＣ６６におけるビット値が１であればデータフィールド６８が１バイトのデータ長であり、例えばＤＬＣ６６におけるビット値が８であればデータフィールド６８が８バイトのデータ長であることを示す。
【００２０】
なお、データフィールド６８は、フレームのうちのヘッダ部分およびフッタ部分を除く実データが格納される領域である。実データとは、送受信する実質的なデータを表す。例えば、センサ値等の状態値、プログラムの書き換え等の指令を表す指令値、書き換え用のプログラムそのもの等が含まれる。
【００２１】
ここで、ＤＬＣ６６は、データ長が特定の値である際に、データ値が無効となる無効領域を有するよう設定されている。すなわち、ＤＬＣ６６におけるビット値が８−１５である場合、言い換えれば、ＤＬＣ６６を示す４ビットのうちの最上位のビットであるｄ３が１である場合には、このビット値だけでデータ長が８バイトと認識されるため、ＤＬＣ６６を示す４ビットのうちの下位３ビットであるｄ２、ｄ１、ｄ０はデータ長を示す上では無意味となる。つまり、下位３ビットが無効領域となる。
【００２２】
このため、フレーム生成部２３は、データフィールド６８のデータ長が８バイトとなり、ＤＬＣ６６に無効領域を有する際に、ＤＬＣ６６の少なくとも一部である下位３ビットを、データ種別を示す領域（すなわちＣＡＮＩＤを示す領域）の一部としたデータフレーム６０を生成する。つまり、ＩＤ６２の１１ビットとＤＬＣ６６の下位３ビットとの１４ビットの領域を用いてデータの種別を表現する。
【００２３】
なお、通信システム１においては、ＩＤ６２の１１ビットの領域だけを用いてデータ種別を表現するデータ（以下、データ群Ａに属する種別のデータ）と、ＩＤ６２およびＤＬＣ６６の１４ビットの領域を用いてデータの種別を表現するデータ（以下、データ群Ｂに属する種別のデータとをそれぞれ生成できる。
【００２４】
フレーム生成部２３は、データ種別がデータ群Ａに属する場合には、送信する実データのサイズに応じて任意のＤＬＣ６６の値を設定する。つまり、データフィールド６８のデータ長を０−８に設定できる。一方、フレーム生成部２３は、データ種別がデータ群Ｂに属する場合には、送信する実データのサイズに拘わらず、ＤＬＣ６６の値を８に設定する。そして、データ種別を示すデータの上位１１ビットをＩＤ６２の領域に格納し、下位３ビットをＤＬＣ６６の下位３ビットに格納する。
【００２５】
特に、ＤＬＣ６６の領域における下位３ビットは、相手先を特定するために領域として用いることができる。例えば、図３に示すように、ＩＤ６２の領域においては、「０ｘ１Ｆ１」という同一のデータの種別を示す情報を格納し、ＤＬＣ６６の下位３ビットに、宛先のＥＣＵに応じて異なる値を格納する。具体的には、宛先がＥＣＵ［Ｂ−１］３５であれば、「０ｘ１」を格納し、宛先がＥＣＵ［Ｂ−２］３６であれば、「０ｘ２」を格納し、宛先がＥＣＵ［Ｂ−３］３８であれば、「０ｘ３」を格納する。
【００２６】
従来構成では、図４に示すように、ＩＤ６２の領域においてデータの種別および宛先を含むようにする必要があったため、宛先が３か所であれば、ＩＤ６２の領域において例えば「０ｘ１Ｆ１」「０ｘ１Ｆ２」「０ｘ１Ｆ３」の３つのＩＤが必要であった。しかし、本実施形態の通信システム１では、ＤＬＣ６６の下位３ビットにて宛先を表現しているので、ＩＤ６２の領域においては１つのＩＤだけを必要とすることができる。このようにしてフレーム生成部２３にてデータフレーム６０が生成される。
【００２７】
送信部２４は、フレーム生成部２３によって生成されたデータフレーム６０を通信線上に送信する。また、受信部２６は、データフレーム６０を受信し、データ認識部２７に送る。なお、送信部２４および受信部２６は周知の構成とすることができる。
【００２８】
データ認識部２７は、受信部２６にて受信されたデータフレーム６０からＩＤ６２およびＤＬＣ６６を抽出し、ＩＤ６２およびＤＬＣ６６に含まれるデータに基づいてデータの種別を認識する。受信したデータのＤＬＣ６６に無効領域を有する際、つまり、ＤＬＣ６６の最上位ビットが１であるときに、ＩＤ６２およびＤＬＣ６６の下位３ビットに含まれるデータに基づいてデータの種別を認識する。
【００２９】
ここで、データ認識部２７において実行される受信処理について図５に示すフローチャートを用いて説明する。受信処理は、データフレーム６０に含まれるデータ種別を認識する際の処理である。受信処理は、受信部２６からデータが送られる度に実行される。
【００３０】
受信処理では、図５に示すように、Ｓ１１０にて、ＤＬＣ６６領域の値が９以上であるか否かを判定する。ＤＬＣ６６領域の値が８以下であれば、Ｓ１２０にて、通常のＣＡＮＩＤとしてデータ種別を認識し、認識した値を通知する。通知の対象は、例えば、データの種別および実データを認識する機能を有するＥＣＵ２０内の部位である。
【００３１】
なお、通常のＣＡＮＩＤとしてデータ種別を認識する処理とは、ＤＬＣ６６の領域を含まず、ＩＤ６２の１１ビットだけでデータ種別を認識する周知のＣＡＮにおいて実施される処理を表す。
【００３２】
また、Ｓ１１０にてＤＬＣ６６領域の値が９以上であれば、Ｓ１３０にて、ＤＬＣ６６領域の下位３ビットを抽出する。ここでは、この下位３ビットをＣＡＮＩＤβとする。
続いて、Ｓ１４０にてＩＤ６２領域に含まれる値をＣＡＮＩＤαとして、このＣＡＮＩＤαとＣＡＮＩＤβとを結合し、得られた値をＣＡＮＩＤγとする。そして、Ｓ１５０にてＣＡＮＩＤγをデータ種別を表す値として通知する。
【００３３】
このような処理が終了すると受信処理を終了する。なお、ＣＡＮＩＤγは、データ量が１１ビットから１４ビットに変更されただけであり、データ型式が変更されたものでないため、本処理においては一般的なＣＡＮソフトを修正することなく利用できる。
【００３４】
［１−３．効果］
以上詳述した第１実施形態によれば、以下の効果が得られる。
（１ａ）上記の通信システム１のＥＣＵ２０，３０，４０において、フレーム生成部２３は、データの種別を表すＩＤ６２、およびデータの長さを示すＤＬＣ６６、が含まれるデータフレーム６０であって、ＤＬＣ６６の少なくとも一部をデータ種別を表す領域の一部としたデータフレーム６０を生成する。そして、送信部２４は、フレーム生成部２３によって生成されたデータフレーム６０を通信線上に送信する。
【００３５】
また、上記の通信システム１のＥＣＵ２０，３０，４０において、受信部２６は、ＩＤ６２と、ＤＬＣ６６とが含まれるデータフレーム６０であって、ＤＬＣ６６の少なくとも一部をデータ種別を表す領域の一部としたデータフレーム６０を受信する。また、データ認識部２７は、受信したデータフレーム６０からＩＤ６２およびＤＬＣ６６を抽出し、ＩＤ６２およびＤＬＣ６６に含まれるデータに基づいてデータの種別を認識する。
【００３６】
このような通信システム１によれば、ＤＬＣ６６の少なくとも一部をデータ種別を表す領域の一部として利用するので、データの伝送効率の低下を抑制しつつ、多くのＩＤ６２を確保することができる。また、データフィールド６８の一部をデータ種別を表す領域とする構成と比較してもデータの伝送効率の低下を抑制できる。
【００３７】
また、このような通信システム１によれば、他のＥＣＵから送信されたデータフレーム６０において、ＤＬＣ６６内にデータ種別を示すデータが含まれている場合であっても良好に認識することができる。
【００３８】
（１ｂ）上記の通信システム１において、ＤＬＣ６６は、データ長が特定の値である際に、データ値が無効となる無効領域を有するよう設定されている。そして、フレーム生成部２３は、ＤＬＣ６６に無効領域を有する際に、ＤＬＣ６６の少なくとも一部をＩＤ６２の一部としたデータを生成する。また、データ認識部２７は、受信したデータのＤＬＣ６６に無効領域を有する際に、ＩＤ６２および無効領域に含まれるデータに基づいてデータの種別を認識する。なお、無効となるとは、データを読み出す処理の際に、特定のビットにおけるビット値が意味を持たないことを示す。また、データ値とは１または複数のビット値を示す。
【００３９】
このような通信システム１によれば、ＤＬＣ６６のうちの無効領域をデータ種別を表す領域の一部として用いるので、ＤＬＣ６６によるデータ長の識別に影響を与えることなくデータ種別を表す領域を拡張することができる。
【００４０】
（１ｃ）上記の通信システム１においては、ＣＡＮプロトコルにより通信を行い、ＤＬＣ６６として、４ビットのＤＬＣの領域が設定されている。
このような通信システム１によれば、ＣＡＮにおけるＤＬＣの領域を用いるので、確実にデータの伝送効率の低下を抑制しつつ、多くのＩＤを確保することができる。
【００４１】
（１ｄ）上記の通信システム１においては、ＤＬＣの領域における下位３ビットがデータ種別を表す領域の一部として設定されている。
このような通信システム１によれば、データ長が８バイトである際に無効となるＤＬＣの下位３ビットをＩＤ６２として用いるので、ＤＬＣの下位１ビットや２ビットを利用する構成と比較して、より多くのデータ種別を表す領域を確保することができる。
【００４２】
（１ｅ）上記の通信システム１においては、ＤＬＣの領域における下位３ビットは、相手先を特定するために領域としても用いられる。
このような通信システム１によれば、データ種別を表す領域に相手先を特定する情報を含む場合においても、より多くの相手先を対応付けることができる。
【００４３】
特に、テスタ１０等の外部装置を接続可能な構成など、より多くのデータ種別と宛先との組み合わせを利用したい場合に特に有効である。例えば、上記実施形態において、ＥＣＵ３０がＣＡＮの通信線５を介してあるデータを受信し、かつこのデータをＬＩＮの通信線６に中継する場合、メッセージとして特定のＣＡＮＩＤを１つ付与する。ＥＣＵ３０がＬＩＮバスに中継するＬＩＮフレームのＣＡＮＩＤには上記のようにＤＬＣ領域の下位３ビットに割り付けて送信する構成とすることで、ＩＤ６２の領域の枯渇を抑制することができる。
【００４４】
また、テスタ１０を用いた診断通信では、使用できるＣＡＮＩＤが７ｘｘ番台と規格上決められている。このため、昨今のＥＣＵ数の増加により診断通信に用いるＣＡＮＩＤの枯渇がより現実的である。診断通信ではＣＡＮＩＤを機能アドレスとし、同アドレスを受診対象とする複数のＥＣＵが機能アドレスを受診した際に、同時にアクションを取る仕様がある。この仕様においては多くの場合、全ＥＣＵが反応する全ＥＣＵ指定用ＩＤと、１つのＩＤに対し予め決められた複数のＥＣＵが反応するグループ指定用ＩＤと、というように、機能アドレスとしても複数のＣＡＮＩＤが割り当てられて運用されている。
【００４５】
このような場合でも上記実施形態の構成を用いればＤＬＣの下位３ビットでグループ(全ＥＣＵ、特定のグループ)を指定し、機能アドレスとしての意味付けはＣＡＮＩＤ１つの割り当てで済ませることができる。
【００４６】
［２．他の実施形態］
以上、本開示を実施するための形態について説明したが、本開示は上述の実施形態に限定されることなく、種々変形して実施することができる。
【００４７】
（２ａ）上記実施形態では、ＤＬＣ６６の一部をデータ種別を表す領域の一部とする場合について説明した。すなわち、ＤＬＣ６６のうちの予め定められた１または複数のビット値が予め定められた値である際に、ＤＬＣ６６のうちの他のビットをデータ種別を表す領域の一部として利用した。しかし、ＤＬＣ６６の全部をデータ種別を表す領域の一部としてもよい。このようにする場合には、予め固定化されたデータ長を利用すればよい。
【００４８】
（２ｂ）上記実施形態における１つの構成要素が有する機能を複数の構成要素として分散させたり、複数の構成要素が有する機能を１つの構成要素に統合させたりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加または置換してもよい。なお、特許請求の範囲に記載した文言のみによって特定される技術思想に含まれるあらゆる態様が本開示の実施形態である。
【００４９】
（２ｃ）上述した通信システム１の他、当該通信システム１の構成要素となる装置、当該通信システム１としてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実態的記録媒体、通信方法など、種々の形態で本開示を実現することもできる。
【符号の説明】
【００５０】
１…通信システム、５，６…通信線、１０…テスタ、２０，３０，３５，３６，３７，４０…ＥＣＵ、２１…ＣＰＵ、２２…メモリ、２３…フレーム生成部、２４…送信部、２６…受信部、２７…データ認識部、６０…データフレーム、６４…コントロールフィールド、６８…データフィールド。
【図１】
2017118317.tif 000003
【図２】
2017118317.tif 000004
【図３】
2017118317.tif 000005
【図４】
2017118317.tif 000006
【図５】
2017118317.tif 000007