(57)【要約】【課題】  汎用非同期送受信回路を有するマイコンを用いて通信を行う場合に、トランシーバの規模を大きくすることなく、フレームの正常な到達を判断可能な通信装置を提供する。【解決手段】  受信側のＥＣＵがフレームの受信が完了したか否かを判断し（Ｓ１００）、受信エラーが無い場合（Ｓ１１０）、ブロックデータで構成されるＡＣＫを送信する（Ｓ１３０）。一方、受信エラーが有る場合（Ｓ１１０：ＮＯ）、ブロックデータで構成されるＮＡＣＫを送信する（Ｓ１５０）。また、受信エラーが無い場合で先にＡＣＫを受信した場合（Ｓ１１０：ＹＥＳ，Ｓ１２０：ＹＥＳ）、受信エラーが無い場合で先にＮＡＣＫを受信した場合（Ｓ１１０：ＹＥＳ，Ｓ１２０：ＹＥＳ）、ＡＣＫを送信しない。さらにまた、受信エラーが有る場合で先にＮＡＣＫを受信した場合（Ｓ１１０：ＮＯ，Ｓ１４０：ＹＥＳ）、ＮＡＣＫを送信しない。【選択図】図３
2013026835.tif 000002
【特許請求の範囲】
【請求項１】
共通のバス通信路に接続され、当該バス通信路を介して相互に通信を行う通信装置であって、
汎用非同期送受信回路を有するマイコンと、
前記汎用非同期送受信回路からのフレームを前記バス通信路へ出力すると共に前記バス通信路を介して受信したフレームを前記汎用非同期送受信回路へ出力するトランシーバと、を備え、
前記マイコンは、前記バス通信路を介して受信したフレームが正常であるか否かの情報を、前記汎用非同期送受信回路が送受信可能なブロック単位の情報として送信する受信側処理を実行可能であること
を特徴とする通信装置。
【請求項２】
請求項１に記載の通信装置において、
前記受信側処理では、直前に受信したフレームが正常である場合に、ＡＣＫ用ＩＤを含むブロック単位の情報を送信すること
を特徴とする通信装置。
【請求項３】
請求項２に記載の通信装置において、
前記受信側処理では、直前に受信したフレームが正常でない場合に、ＮＡＣＫ用ＩＤを含むブロック単位の情報を送信すること
を特徴とする通信装置。
【請求項４】
請求項３に記載の通信装置において、
前記受信側処理では、直前に受信したフレームが正常である場合で、かつ、先にＡＣＫ用ＩＤ及びＮＡＣＫ用ＩＤのいずれも受信していない場合に、ＡＣＫ用ＩＤを含むブロック単位の情報を送信すること
を特徴とする通信装置。
【請求項５】
請求項３又は４に記載の通信装置において、
前記受信側処理では、直前に受信したフレームが正常でない場合で、かつ、先にＮＡＣＫ用ＩＤを受信していない場合に、ＮＡＣＫ用ＩＤを含むブロック単位の情報を送信すること
を特徴とする通信装置。
【請求項６】
請求項１に記載の通信装置において、
前記マイコンは、前記受信側処理に加え、到達確認のための到達確認用フレームを送信する送信側処理を実行可能であること
を特徴とする通信装置。
【請求項７】
請求項６に記載の通信装置において、
前記受信側処理では、前記到達確認用フレームを受信すると、当該到達確認用フレームの受信以前の到達確認の対象となる到達確認対象フレームに関する到達応答を含む到達応答用フレームを送信すること
を特徴とする通信装置。
【請求項８】
請求項７に記載の通信装置において、
前記到達確認用フレームには、前記到達確認対象フレームを特定するためのフレームＩＤが含まれており、
前記受信側処理では、前記フレームＩＤにより前記到達確認対象フレームを特定すること
を特徴とする通信装置。
【請求項９】
請求項７又は８に記載の通信装置において、
前記送信側処理では、前記到達確認対象フレームに対し前記到達確認用フレームを１度だけ送信するようになっており、
前記受信側処理では、前記到達確認対象フレームの受信後に前記到達確認用フレームを２度以上受信した場合、前記到達確認対象フレームを正常に受信していないと判断すること
を特徴とする通信装置。
【請求項１０】
請求項１に記載の通信装置において、
前記マイコンは、前記受信側処理に加え、到達確認のための確認用ＩＤを送信する送信側処理を実行可能であること
を特徴とする通信装置。
【請求項１１】
請求項１０に記載の通信装置において、
前記受信側処理では、前記確認用ＩＤを受信すると、当該確認用ＩＤの受信以前の到達確認の対象となる到達確認対象フレームに関する到達応答を含むレスポンスを送信すること
を特徴とする通信装置。
【請求項１２】
請求項１１に記載の通信装置において、
前記確認用ＩＤは、前記到達確認対象フレームに対応させて割り当てられており、
前記受信側処理では、前記確認用ＩＤにより前記到達確認対象フレームを特定すること
を特徴とする通信装置。
【請求項１３】
請求項１１又は１２に記載の通信装置において、
前記送信側処理では、前記到達確認対象フレームに対し前記確認用ＩＤを１度だけ送信するようになっており、
前記受信側処理では、前記到達確認対象フレームの受信後に前記確認用ＩＤを２度以上受信した場合、前記到達確認対象フレームを正常に受信していないと判断すること
を特徴とする通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、共通のバス通信路に接続され、当該バス通信路を介して相互に通信を行う通信装置に関する。
【背景技術】
【０００２】
従来、ローカルエリアネットワーク（ＬＡＮ）、特に車内ＬＡＮに多用されている通信プロトコルとして、ＣＳＭＡ／ＣＡ方式のＣＡＮ（Controller Area Network ）プロトコルが知られている（特許文献１参照）。
【０００３】
ＣＡＮプロトコルで規定されたフレームの先頭部分には、後続のデータ領域にどのようなメッセージが割り付けられたフレームであるかを識別するための識別コード（ＩＤ）が含まれており、通信システムを構成する通信装置は、受信したフレームの種別を、そのフレームに含まれているＩＤに基づき識別する。
【０００４】
また、複数の通信装置が共通のバス通信路を介して通信を行うため、送信すべきフレームを有する通信装置は、バス通信路が使用中でなければ直ちにフレームの送信を開始し、バス通信路が使用中であればバス通信路が解放（フレームの送信が終了）されてからフレームの送信を開始する。このため、送信すべきフレームを有する通信装置が複数存在すると、複数の通信装置が同時にフレームの送信を開始することがあり、この場合、バス通信路上でフレームの衝突が発生する。このようなフレームの衝突が発生した場合、ＣＡＮプロトコルでは、どのフレームを優先的に処理するかを決定する調停処理を、前述のＩＤを用いて行うように規定されている。
【０００５】
ところで、送信側の通信装置から受信側の通信装置へのフレームの正常な到達を判断するための情報としてＡＣＫと呼ばれる情報を返すことが行われている。具体的に、ＣＡＮプロトコルでは、フレームを正常に受信したことを示すＡＣＫ情報が、例えばフレームの特定ビット（ＡＣＫスロット）に割り当てられている。このとき送信側の通信装置は、フレームの送信中にフレームの信号レベルとバス通信路上の信号レベルとをビットごとに比較しているため、フレームの正常な受信が行われなかった場合に受信側の通信装置がフレームの特定ビットを書き換えることで、送信側の通信装置へＡＣＫ情報を返すことができる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−２８７７３８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、汎用非同期送受信回路を有するマイコンを用いて通信を行うことを考えた場合、汎用非同期送受信回路がいわゆる調歩同期であるため、ＣＡＮプロトコルと同様の方式でＡＣＫ情報を返すことはできない。これを実現するためには、マイコンとバス通信路とに介在するトランシーバにＡＣＫを返す機能を持たせる必要があり、結果として、トランシーバの規模が大きくなってしまう。
【０００８】
本発明は、上述した課題を解決するためになされたものであり、その目的は、汎用非同期送受信回路を有するマイコンを用いて通信を行う場合に、トランシーバの規模を大きくすることなく、フレームの正常な到達を判断可能な通信装置を提供することにある。
【課題を解決するための手段】
【０００９】
上述の目的を達成するためになされた請求項１の通信装置は、共通のバス通信路に接続されるものであり、当該バス通信路を介して相互に通信を行う。
通信装置は、汎用非同期送受信回路を有するマイコンと、トランシーバとを備えている。トランシーバは、汎用非同期送受信回路からのフレームをバス通信路へ出力すると共にバス通信路を介して受信したフレームを汎用非同期送受信回路へ出力する。
【００１０】
ここで特に、マイコンが、受信側処理を実行可能となっている。この受信側処理によって、バス通信路を介して受信したフレームが正常であるか否かの情報が、汎用非同期送受信回路が送受信可能なブロック単位の情報として送信される。
【００１１】
このようにすれば、送信側のマイコンは受信側のマイコンからのブロック単位の情報を受信することで、フレームの正常な到達を判断することができる。その結果、トランシーバの規模を大きくすることなく、フレームの正常な到達を判断することができる。
【００１２】
例えば請求項２に示すように、受信側処理では、直前に受信したフレームが正常である場合に、ＡＣＫ用ＩＤを含むブロック単位の情報を送信することが考えられる。具体的には、１ブロック（１０ビット）の情報にＡＣＫ用ＩＤを含めて送信することが考えられる。例えば、スタートビット及びストップビット以外の８ビットの情報のうち、パリティビット（１ビット）を除く７ビットでＡＣＫ用ＩＤを表現するという具合である。このようにすれば、送信側の通信装置にてフレームの正常な到達を判断することができる。
【００１３】
また例えば請求項３に示すように、受信側処理では、直前に受信したフレームが正常でない場合に、ＮＡＣＫ用ＩＤを含むブロック単位の情報を送信することが考えられる。上述の構成と同様、１ブロック（１０ビット）の情報にＮＡＣＫ用ＩＤを含めて送信することが考えられる。このようにすれば、送信側の通信装置にてフレームの正常でない（異常）到達を判断することができる。
【００１４】
さらにまた例えば請求項４に示すように、受信側処理では、直前に受信したフレームが正常である場合で、かつ、先にＡＣＫ用ＩＤ及びＮＡＣＫ用ＩＤのいずれも受信していない場合に、ＡＣＫ用ＩＤを含むブロック単位の情報を送信することが考えられる。先に他の通信装置がＡＣＫ用ＩＤを送信している場合、重ねてＡＣＫ用ＩＤを送信する必要はないからである。また、先に他の通信装置がＮＡＣＫ用ＩＤを送信している場合、当該他の通信装置にてエラーが生じているため、ＡＣＫ用ＩＤを送信することが無駄になるからである。このようにすれば、バス通信路の効率的な利用に寄与する。
【００１５】
また例えば請求項５に示すように、受信側処理では、直前に受信したフレームが正常でない場合で、かつ、先にＮＡＣＫ用ＩＤを受信していない場合に、ＮＡＣＫ用ＩＤを含むブロック単位の情報を送信することが考えられる。先に他の通信装置がＮＡＣＫ用ＩＤを送信している場合、当該他の通信装置にてエラーが生じているため、重ねてＮＡＣＫ用ＩＤを送信する必要はないからである。このようにすれば、バス通信路の効率的な利用に寄与する。
【００１６】
ところで、請求項６に示すように、マイコンが、到達確認のための到達確認用フレームを送信する送信側処理を実行可能であることとしてもよい。このようにすれば、送信側の通信装置が、受信側の通信装置に対し、フレームが正常に到達したかどうかの確認を要求することができる。この場合、受信側処理では、到達確認用フレームを受信した場合に、当該到達確認用フレームに対する応答を行う。
【００１７】
すなわち、請求項７に示すように、受信側処理では、到達確認用フレームを受信すると、当該到達確認用フレームの受信以前の到達確認の対象となる到達確認対象フレームに関する到達応答を含む到達応答用フレームを送信することが考えられる。ここで到達確認対象フレームに関する到達応答とは、正常に受信しているか否かの応答であってもよいし、受信した到達確認対象フレームの内容そのものの応答であってもよい。後者の場合は、送信側の通信装置で送信したフレームの内容との比較を行うことで正常に受信されているか否かを送信側で判断する。このようにすれば、送信側の通信装置から到達確認用フレームが送信されたときにだけ、受信側の通信装置から到達応答用フレームが送信されるため、バス通信路の効率的な利用が実現できる。
【００１８】
このときは、請求項８に示すように、到達確認用フレームには、到達確認対象フレームを特定するためのフレームＩＤが含まれるようにするとよい。この場合、受信側処理では、フレームＩＤにより到達確認対象フレームを特定する。このようにすれば、到達確認対象フレームがフレームＩＤから特定されるため、他のフレームが途中で送信された場合であっても、到達確認が容易に実現される。
【００１９】
ただし、１つのフレームに対し到達確認用フレームを２度以上送信すると、どのフレームに対する到達確認用フレームであるのかが分からなくなる可能性がある。請求項９に示すように、送信側処理では、到達確認対象フレームに対し到達確認用フレームを１度だけ送信するようにし、受信側処理では、到達確認対象フレームの受信後に到達確認用フレームを２度以上受信した場合、到達確認対象フレームを正常に受信していないと判断することが好ましい。この場合、到達確認と到達応答とが１対１に対応しない場合には異常受信との判断がなされる。このようにすれば、何らかの要因で到達確認対象フレームを受信できなかった場合に異常受信と判断することができる。
【００２０】
ところで、上記構成では、送信側の通信装置が到達確認用フレームを送信し、これに対して受信側の通信装置が到達応答用フレームを送信している。したがって、到達確認及び到達応答を合計２フレームで行っている。
【００２１】
これに対し、請求項１０に示すように、マイコンが、到達確認のための確認用ＩＤを送信する送信側処理を実行可能であることとしてもよい。このようにしても同様に、送信側の通信装置が、受信側の通信装置に対し、フレームが正常に到達したかどうかの確認を要求することができる。この場合、受信側処理では、確認用ＩＤに続けて到達応答を含むレスポンスを送信する。
【００２２】
すなわち、請求項１１に示すように、受信側処理では、確認用ＩＤを受信すると、当該確認用ＩＤの受信以前の到達確認の対象となる到達確認対象フレームに関する到達応答を含むレスポンスを送信することが考えられる。ここで到達確認対象フレームに関する到達応答とは、正常に受信しているか否かの応答であってもよいし、受信した到達確認対象フレームの内容そのものの応答であってもよい。後者の場合は、送信側の通信装置で送信したフレームの内容との比較を行うことで正常に受信されているか否かを送信側で判断する。このようにすれば、送信側の通信装置から確認用ＩＤが送信されたときにだけ、受信側の通信装置から到達応答を含むレスポンスが送信され、しかも、到達確認及び到達応答が１フレームで実現されるため、バス通信路のより効率的な利用が実現できる。
【００２３】
このときは、請求項１２に示すように、確認用ＩＤが、到達確認対象フレームに対応して割り当てられるようにするとよい。この場合、受信側処理では、確認用ＩＤにより到達確認対象フレームを特定する。このようにすれば、到達確認対象フレームが確認用ＩＤから特定されるため、到達確認が容易に実現される。
【００２４】
ただし、１つのフレームに対し確認用ＩＤを２度以上送信すると、どのフレームに対する確認用ＩＤであるのかが分からなくなる可能性がある。そこで、請求項１３に示すように、送信側処理では、到達確認対象フレームに対し確認用ＩＤを１度だけ送信するようにし、受信側処理では、到達確認対象フレームの受信後に確認用ＩＤを２度以上受信した場合、到達確認対象フレームを正常に受信していないと判断することが好ましい。この場合、到達確認と到達応答とが１対１に対応しない場合には異常受信との判断がなされる。このようにすれば、何らかの要因で到達確認対象フレームを受信できなかった場合に異常受信と判断することができる。
【図面の簡単な説明】
【００２５】
【図１】通信システムの概略構成を示すブロック図である。
【図２】（ａ）はバス通信路で使用する伝送路符号の構成を示す説明図であり、（ｂ）はバス通信路を介して送受信されるフレームの構成を示す説明図であり、（ｃ）はＵＡＲＴが送受信するブロックデータの構成を示す説明図である。
【図３】マイコンが実行する受信側処理を示すフローチャートである。
【図４】第２実施形態における送信側処理を示すフローチャートである。
【図５】第２実施形態における受信側処理を示すフローチャートである。
【図６】第３実施形態における送信側処理を示すフローチャートである。
【図７】第３実施形態における受信側処理を示すフローチャートである。
【発明を実施するための形態】
【００２６】
以下に本発明の実施形態を図面と共に説明する。
［第１実施形態］
図１は、車両に搭載される通信システムの概略構成を示すブロック図である。
【００２７】
通信システムは、複数の通信装置（以下「ＥＣＵ」という）１０を備えている。これらのＥＣＵ１０は、バス通信路４０を介して相互に接続されている。
通信システムを構成するＥＣＵ１０は、例えばボデー系ＥＣＵであることが考えられる。具体的には、ボデー・ワイパＥＣＵ，シートＥＣＵ，スライドドアＥＣＵ，ミラーＥＣＵ，バックドアＥＣＵ，ライトＥＣＵ，チルテレ（電動ステアリング位置調整装置）ＥＣＵ等がある。なお、ここではＥＣＵ１０が相互に接続される態様を示したが、ボデー系ＥＣＵと共に、関連機器としてのライトＳＷ，ワイパＳＷ，ライトセンサ，レインセンサ等を通信装置として接続することも考えられる。
【００２８】
バス通信路４０は、異なるＥＣＵ１０からハイレベルの信号とロウレベルの信号とが同時に出力されると、バス通信路４０上の信号レベルがロウレベルとなるように構成されており、この機能を利用してバス調停を実現する。
【００２９】
ここで図２（ａ）は、バス通信路４０で使用する伝送路符号を示す説明図である。
図２（ａ）に示すように、バス通信路４０では、伝送路符号として、ビットの途中で信号レベルがロウレベルからハイレベルに変化するＰＷＭ符号が用いられ、ドミナント（本実施形態では０に対応）およびレセッシブ（本実施形態では１に対応）からなる二値の信号を２種類のデューティ比で表現する。
【００３０】
具体的には、ドミナントの方がレセッシブよりロウレベルの比率が長くなるよう（本実施形態では、ドミナントが１ビットの２／３の期間、レセッシブが１ビットの１／３の期間）に設定され、バス通信路４０上でドミナントとレセッシブとが衝突すると、ドミナントが調停勝ちするようにされている。
【００３１】
そして、通信システムでは、調停負けしたＥＣＵ１０は送信を直ちに停止し、調停勝ちしたＥＣＵ１０のみが送信を継続する、いわゆるＣＳＭＡ／ＣＡ方式のアクセス制御方式が用いられている。
【００３２】
また、図２（ｂ）は、ＥＣＵ１０間の通信に使用するレームの構成を示す説明図である。
図２（ｂ）に示すように、フレームは、送信を許可するデータを指定するためのヘッダと、ヘッダによって指定されたデータを送信するための可変長のレスポンスからなる。
【００３３】
このうち、ヘッダは、識別子（ＩＤ）を含み、ＩＤの値が小さいほど、バス調停で勝ち残るように設定されている。一方、レスポンスは、データ以外に、データ（レスポンス）のサイズを示すサイズ情報、エラーの有無をチェックするためのＣＲＣ符号が少なくとも含まれている。
【００３４】
各ＥＣＵ１０は、予め割り当てられた全ての機能を実行可能な動作モードであるウェイクアップモード、消費電力を抑えるために一部の機能を停止した動作モードであるスリープモードで動作する。
【００３５】
また、ＥＣＵ１０の一つをマスタ、他のＥＣＵ１０をスレーブとして、マスタがヘッダを送信することによって、送信を許可するデータ（ひいてはデータの送信元となるスレーブ）を順次指定し、ヘッダによって指定されたデータの送信元となるスレーブがレスポンス（データ）を送信するポーリング（定期通信）と、マスタからの指示によらずスレーブが自律的に通信を制御するイベント通信とを実行する。
【００３６】
次にＥＣＵ１０の構成を説明する。
図１に示したように、ＥＣＵ１０は、マイコン２０と、トランシーバ３０とを備えている。
【００３７】
マイコン２０は、バス通信路４０を介した他ＥＣＵ１０との通信によって得られた情報等に基づき、自ＥＣＵ１０に割り当てられた各種処理を実行する。したがって、マイコン２０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏポート等からなる周知のマイクロコンピュータを中心に構成されている。
【００３８】
また、マイコン２０は、ＵＡＲＴ（汎用非同期送受信回路：Universal Asynchronous Receiver Transmitter ）２１、及び、発信回路２２を有している。このＵＡＲＴ２１により、調歩同期（非同期）方式のシリアル通信が実現される。また、発信回路２２は、マイコン２０を動作させるための動作クロック及び、トランシーバ３０へ供給される内部クロックを発生させる。この内部クロックは、ＵＡＲＴ２１の通信速度と同じ速度（本実施形態では２０Ｋｂｐｓ）に設定されている。
【００３９】
図２（ｃ）は、ＵＡＲＴ２１が送受信するデータの構成を示す説明図である。図２（ｃ）に示すように、ＵＡＲＴ２１は、データの開始を示す１ビット長のスタートビット（ロウレベル）と、データの終了を示すストップビット（ハイレベル）と、これらスタートビット，ストップビットに挟まれた８ビットのデータとで構成された合計１０ビットのブロック単位のデータを送受信する。
【００４０】
なお、前述のフレーム（図２（ｂ）参照）を構成するヘッダは、単一のブロックデータで構成され、スタートビット，ストップビットを除く８ビットのデータのうち、７ビットはＩＤとして用いられ、１ビットはパリティビットとして用いられる。また、レスポンスは、１ないし複数個のブロックデータで構成され、最初のブロックに、サイズ情報が設定される。
【００４１】
一方、トランシーバ３０は、マイコン２０から供給される送信データを符号化してバス通信路４０に出力すると共に、バス通信路４０から取り込んだＰＷＭ符号の受信データを復号化してマイコン２０に供給する。
【００４２】
次に、ＥＣＵ１０のマイコン２０にて実行される受信側処理を図３に基づき説明する。この受信側処理は、他ＥＣＵ１０からの送信データの受信に際し実行される。ここでは、受信側の自ＥＣＵ１０が、受信したデータのエラーの有無に応じ、ＡＣＫ（Acknowledgment）又はＮＡＣＫ（Negative Acknowledgment ）を返すようになっている。
【００４３】
最初のＳ１００では、フレーム受信完了か否かを判断する。ここでフレームの受信が完了したと判断された場合（Ｓ１００：ＹＥＳ）、Ｓ１１０へ移行する。一方、フレームの受信が完了していないうちは（Ｓ１００：ＮＯ）、Ｓ１００の判断処理を繰り返す。
【００４４】
Ｓ１１０では、受信エラーが無いか否かを判断する。ここで受信エラーが無いと判断された場合（Ｓ１１０：ＹＥＳ）、Ｓ１２０へ移行する。一方、受信エラーが有ると判断された場合（Ｓ１１０：ＮＯ）、Ｓ１４０へ移行する。
【００４５】
受信エラー無しの場合に移行するＳ１２０では、先にＡＣＫ又はＮＡＣＫを受信したか否かを判断する。この処理は、他ＥＣＵ１０がＡＣＫ又はＮＡＣＫを先に送信し、当該他のＥＣＵ１０からのＡＣＫ又はＮＡＣＫを受信したたか否かを判断するものである。ここで先にＡＣＫ及びＮＡＣＫを受信していないと判断された場合（Ｓ１２０：ＮＯ）、Ｓ１３０にてＡＣＫを送信し、その後、受信側処理を終了する。一方、先にＡＣＫ又はＮＡＣＫを受信したと判断された場合（Ｓ１２０：ＹＥＳ）、Ｓ１３０の処理を実行せず、受信側処理を終了する。
【００４６】
また、受信エラー有りの場合に移行するＳ１４０では、先にＮＡＣＫを受信したか否かを判断する。ここで先にＮＡＣＫを受信していないと判断された場合（Ｓ１４０：ＮＯ）、Ｓ１５０にてＮＡＣＫを送信し、その後、受信側処理を終了する。一方、先にＮＡＣＫを受信したと判断された場合（Ｓ１４０：ＹＥＳ）、Ｓ１５０の処理を実行せず、受信側処理を終了する。
【００４７】
つまり、受信エラーが無い場合で先にＡＣＫを受信した場合（Ｓ１１０：ＹＥＳ，Ｓ１２０：ＹＥＳ）、改めて受信エラーが無かったことを送信側のＥＣＵ１０へ通知する必要はないため、ＡＣＫを送信しない。
【００４８】
また、受信エラーが無い場合で先にＮＡＣＫを受信した場合（Ｓ１１０：ＹＥＳ，Ｓ１２０：ＹＥＳ）、受信エラーが受信側の他ＥＣＵ１０で生じているため、受信エラーが無かったことを送信側のＥＣＵ１０へ通知することは無駄であるため、この場合も、ＡＣＫを送信しない。
【００４９】
さらにまた、受信エラーが有る場合で先にＮＡＣＫを受信した場合（Ｓ１１０：ＮＯ，Ｓ１４０：ＹＥＳ）、受信エラーが受信側の他ＥＣＵ１０で生じているため、受信エラーが有ったことを重ねて送信側のＥＣＵ１０へ通知することは無駄であるため、ＮＡＣＫを送信しない。
【００５０】
ここで特に、本実施形態では、ＡＣＫ及びＮＡＣＫが、ＵＡＲＴ２１が送受信するブロックデータの構成をとっている。すなわち、図２（ｃ）に示すように、スタートビットと、ストップビットと、これらスタートビット及びストップビットに挟まれた８ビットのデータとで構成されている。詳しくは、８ビットのデータのうち、１ビットのパリティビットを除く７ビットがＡＣＫ用ＩＤ又はＮＡＣＫ用ＩＤとなっている。
【００５１】
以上詳述したように本実施形態によれば、受信側のＥＣＵ１０がフレームの受信が完了したか否かを判断し（図３中のＳ１００）、受信エラーが無い場合（Ｓ１１０：ＹＥＳ）、ブロックデータで構成されるＡＣＫを送信する（Ｓ１３０）。一方、受信エラーが有る場合（Ｓ１１０：ＮＯ）、ブロックデータで構成されるＮＡＣＫを送信する（Ｓ１５０）。これにより、送信側のＥＣＵ１０は、これらＡＣＫ及びＮＡＣＫをＵＡＲＴ２１で受信してマイコン２０にて処理することができ、フレームの正常な到達を判断可能となる。その結果、トランシーバ３０の規模を大きくすることなく、フレームの正常な到達を判断することができる。
【００５２】
また、本実施形態では、受信エラーが無い場合で先にＡＣＫを受信した場合（Ｓ１１０：ＹＥＳ，Ｓ１２０：ＹＥＳ）、受信エラーが無い場合で先にＮＡＣＫを受信した場合（Ｓ１１０：ＹＥＳ，Ｓ１２０：ＹＥＳ）、ＡＣＫを送信しない。これにより、バス通信路４０の効率的な利用に寄与する。
【００５３】
さらにまた、本実施形態では、受信エラーが有る場合で先にＮＡＣＫを受信した場合（Ｓ１１０：ＮＯ，Ｓ１４０：ＹＥＳ）、ＮＡＣＫを送信しない。これにより、バス通信路４０の効率的な利用に寄与する。
【００５４】
なお、本実施形態におけるＥＣＵ１０が「通信装置」を構成し、ＵＡＲＴ２１が「汎用非同期送受信回路」を構成し、マイコン２０が「マイコン」を構成し、トランシーバ３０が「トランシーバ」を構成し、バス通信路４０が「バス通信路」を構成する。また、図２に示した受信側処理が「受信側処理」に相当する。
【００５５】
［第２実施形態］
上記第１実施形態では、データ受信側のＥＣＵ１０が、フレームの受信に続けて、ＡＣＫ又はＮＡＣＫを返す構成であった。これに対し、第２実施形態では、データ送信側のＥＣＵ１０が到達確認を行い、データ受信側のＥＣＵ１０が到達応答を行う。
【００５６】
したがって、上記第１実施形態とは、ＥＣＵ１０のマイコン２０で実行される処理のみが相違する。そこで上記第１実施形態との相違部分のみを説明する。
まずはデータ送信側のＥＣＵ１０のマイコン２０で実行される送信側処理を説明する。図４は、送信側処理を示すフローチャートである。
【００５７】
最初のＳ２００では、到達確認を実施するか否かを判断する。ここで到達確認を実施すると判断された場合（Ｓ２００：ＹＥＳ）、Ｓ２１０にて確認用ＩＤ及び到達確認を送信し、その後、送信側処理を終了する。一方、到達確認を実施しないと判断された場合（Ｓ２００：ＮＯ）、Ｓ２００の判断処理を繰り返す。
【００５８】
ここで確認用ＩＤは１ブロックのヘッダに含まれ、到達確認は、レスポンスのデータに含まれる。到達確認には、到達確認の対象となる到達確認対象フレームのフレームＩＤが含まれる。そして、到達確認は、単一又は複数のブロックデータの構成をとっている。なお、確認用ＩＤ及び到達確認を含むレスポンスが、到達確認用フレームを構成する。
【００５９】
次にデータ受信側のＥＣＵ１０のマイコン２０で実行される受信側処理を説明する。図５は、受信側処理を示すフローチャートである。
最初のＳ３００では、到達確認用フレームを受信したか否かを判断する。到達確認用フレームは、確認用ＩＤ及び到達確認を含むレスポンスで構成される。ここで到達確認用フレームを受信したと判断された場合（Ｓ３００：ＹＥＳ）、Ｓ３１０へ移行する。一方、到達確認用フレームを受信していないうちは（Ｓ３００：ＮＯ）、Ｓ３００の判断処理を繰り返す。
【００６０】
Ｓ３１０では、到達確認対象フレームを正常に受信したか否かを判断する。ここで到達確認対象フレームを正常に受信したと判断された場合（Ｓ３１０：ＹＥＳ）、Ｓ３２０にて応答用ＩＤ及び到達応答で「正常受信」を送信し、その後、受信側処理を終了する。一方、到達確認対象フレームを正常に受信していないと判断された場合（Ｓ３１０：ＮＯ）、すなわち受信エラーの場合には、Ｓ３３０にて応答用ＩＤ及び到達応答で「異常受信」を送信し、その後、受信側処理を終了する。
【００６１】
ここで応答用ＩＤは１ブロックのヘッダに含まれ、到達応答は、レスポンスのデータに含まれる。到達応答には、少なくとも「正常受信」又は「異常受信」の情報が含まれる。そして、到達応答は、単一又は複数のブロックデータの構成をとっている。
【００６２】
以上詳述したように本実施形態によれば、送信側のＥＣＵ１０が確認用ＩＤ及び到達確認を含むレスポンスからなる到達確認用フレームを送信する（図４中のＳ２１０）。これに対し、受信側のＥＣＵ１０は、到達確認用フレームの受信を判断し（図５中のＳ３００）、到達確認対象フレームが正常に受信されている場合（Ｓ３１０：ＹＥＳ）、応答用ＩＤ及び「正常受信」を示す到達応答を含むレスポンスからなる到達応答用フレームを送信する（Ｓ３２０）。一方、到達確認対象フレームが正常に受信されていない場合（Ｓ３１０：ＮＯ）、応答用ＩＤ及び「異常受信」を示す到達応答を含むレスポンスからなる到達応答用フレームを送信する（Ｓ３３０）。
【００６３】
このとき、到達確認及び到達応答は、単一又は複数のブロックデータで構成されているため、ＵＡＲＴ２１での送受信が可能でありマイコン２０で処理できる。これにより、トランシーバ３０の規模を大きくすることなく、フレームの正常な到達を判断することができる。また、送信側のＥＣＵ１０は、受信側のＥＣＵ１０に対し、フレームが正常に到達したかどうかの確認を要求することができ、送信側のＥＣＵ１０から到達確認用フレームが送信されたときにだけ、受信側のＥＣＵ１０から到達応答用フレームが送信されるため、バス通信路４０の効率的な利用が実現できる。
【００６４】
また、本実施形態では、レスポンスに含まれる到達確認に、到達確認の対象となる到達確認対象フレームのフレームＩＤが含まれている。これにより、到達確認対象フレームがフレームＩＤから特定されるため、他のフレームが途中で送信された場合であっても、到達確認が容易に実現される。
【００６５】
なお、本実施形態におけるＥＣＵ１０が「通信装置」を構成し、ＵＡＲＴ２１が「汎用非同期送受信回路」を構成し、マイコン２０が「マイコン」を構成し、トランシーバ３０が「トランシーバ」を構成し、バス通信路４０が「バス通信路」を構成する。また、図４に示した送信側処理が「送信側処理」に相当し、図５に示した受信側処理が「受信側処理」に相当する。
【００６６】
［第３実施形態］
第３実施形態も、第２実施形態と同様、データ送信側のＥＣＵ１０が到達確認を行い、データ受信側のＥＣＵ１０が到達応答を行う。ただし、第２実施形態では到達確認及び到達応答を２フレームで行っていたのに対し、本実施形態では、到達確認及び到達応答を１フレームで行う。
【００６７】
まずはデータ送信側のＥＣＵ１０のマイコン２０で実行される送信側処理を説明する。図６は、送信側処理を示すフローチャートである。
最初のＳ４００では、到達確認を実施するか否かを判断する。ここで到達確認を実施すると判断された場合（Ｓ４００：ＹＥＳ）、Ｓ４１０にて確認用ＩＤを送信し、その後、送信側処理を終了する。一方、到達確認を実施しないと判断された場合（Ｓ４００：ＮＯ）、Ｓ４００の判断処理を繰り返す。
【００６８】
つまり、上記第２実施形態と異なるのは、確認用ＩＤのみを送信する点である。ここで確認用ＩＤは１ブロックのヘッダに含まれる。
次にデータ受信側のＥＣＵ１０のマイコン２０で実行される受信側処理を説明する。図７は、受信側処理を示すフローチャートである。
【００６９】
最初のＳ５００では、確認用ＩＤを受信したか否かを判断する。ここで確認用ＩＤを受信したと判断された場合（Ｓ５００：ＹＥＳ）、Ｓ５１０へ移行する。一方、確認用ＩＤを受信していないうちは（Ｓ５００：ＮＯ）、Ｓ５００の判断処理を繰り返す。
【００７０】
Ｓ５１０では、到達確認対象フレームを正常に受信したか否かを判断する。なお、到達確認対象フレームに対応して確認用ＩＤが用意されているものとする。ここで到達確認対象フレームを正常に受信したと判断された場合（Ｓ５１０：ＹＥＳ）、Ｓ５２０にて到達応答で「正常受信」を送信し、その後、受信側処理を終了する。一方、到達確認対象フレームを正常に受信していないと判断された場合（Ｓ５１０：ＮＯ）、すなわち受信エラーの場合には、Ｓ５３０にて到達応答で「異常受信」を送信し、その後、受信側処理を終了する。
【００７１】
ここで、到達応答は、レスポンスのデータに含まれる。また、到達応答には、少なくとも「正常受信」又は「異常受信」の情報が含まれる。そして、到達応答は、単一又は複数のブロックデータの構成をとっている。
【００７２】
以上詳述したように本実施形態によれば、送信側のＥＣＵ１０が確認用ＩＤを送信する（図６中のＳ４１０）。これに対し、受信側のＥＣＵ１０は、確認用ＩＤの受信を判断し（図７中のＳ５００）、到達確認対象フレームが正常に受信されている場合（Ｓ５１０：ＹＥＳ）、「正常受信」を示す到達応答を含むレスポンスを確認用ＩＤに続けて送信する（Ｓ５２０）。一方、到達確認対象フレームが正常に受信されていない場合（Ｓ５１０：ＮＯ）、「異常受信」を示す到達応答を含むレスポンスを確認用ＩＤに続けて送信する（Ｓ５３０）。
【００７３】
このとき、到達確認及び到達応答は、単一又は複数のブロックデータで構成されているため、ＵＡＲＴ２１での送受信が可能である。これにより、トランシーバ３０の規模を大きくすることなく、フレームの正常な到達を判断することができる。また、送信側のＥＣＵ１０は、受信側のＥＣＵ１０に対し、フレームが正常に到達したかどうかの確認を要求することができ、送信側のＥＣＵ１０から確認用ＩＤが送信されたときにだけ、受信側のＥＣＵ１０から到達応答を含むレスポンスが送信されるため、バス通信路４０の効率的な利用が実現できる。
【００７４】
また、本実施形態では、到達確認対象フレームに対応して確認用ＩＤが用意されている。これにより、到達確認対象フレームが確認用ＩＤから特定されるため、他のフレームが途中で送信された場合であっても、到達確認が容易に実現される。
【００７５】
さらにまた、本実施形態では、到達確認及び到達応答が１フレームで実現されるため、バス通信路のより効率的な利用が実現できる。
なお、本実施形態におけるＥＣＵ１０が「通信装置」を構成し、ＵＡＲＴ２１が「汎用非同期送受信回路」を構成し、マイコン２０が「マイコン」を構成し、トランシーバ３０が「トランシーバ」を構成し、バス通信路４０が「バス通信路」を構成する。また、図６に示した送信側処理が「送信側処理」に相当し、図７に示した受信側処理が「受信側処理」に相当する。
【００７６】
［他の実施形態］
１つのフレームに対し到達確認（到達確認用フレーム又は確認用ＩＤ）を２度以上送信すると、どのフレームに対する確認であるのかが分からなくなる可能性がある。そこで、第２実施形態及び第３実施形態の構成において、到達確認対象フレームに対する到達確認を１度だけ行う構成とすることが好ましい。
【００７７】
この場合、第２実施形態の受信側処理（図５）におけるＳ３１０にて肯定判断された後、直前に受信した到達確認対象フレームの後に、到達確認フレームを２度以上受信したか否かを判断し、２度以上受信している場合にはＳ３３０へ移行し、１度だけ受信している場合にはＳ３２０へ移行するようにする。
【００７８】
また、第３実施形態の受信側処理（図７）におけるＳ５１０にて肯定判断された後、直前に受信した到達確認対象フレームの後に、確認用ＩＤを２度以上受信したか否かを判断し、２度以上受信している場合にはＳ５３０へ移行し、１度だけ受信している場合にはＳ５２０へ移行するようにする。
【００７９】
このようにすれば、何らかの要因で到達確認対象フレームを受信できなかった場合に異常受信と判断することができる。
また、上記実施形態では、受信側のＥＣＵ１０にて到達確認対象フレームを正常に受信したか否かを判断し（図５中のＳ３１０，図７中のＳ５１０）、正常受信又は異常受信を応答していた（図５中のＳ３２０，Ｓ３３０，図７中のＳ５２０，５３０）。
【００８０】
これに対し、到達確認対象フレームの内容をそのまま応答し、送信側のＥＣＵ１０が、送信したフレームの内容と比較することで正常受信又は異常受信を判断するようにしてもよい。
【００８１】
以上本発明は、上述した実施形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において種々なる形態で実施可能である。
【符号の説明】
【００８２】
１０：通信装置（ＥＣＵ）、２０：マイコン、２１：ＵＡＲＴ（汎用非同期送受信回路）、２２：発振回路、３０：トランシーバ、４０：バス通信路
【図１】
2013026835.tif 000003
【図２】
2013026835.tif 000004
【図３】
2013026835.tif 000005
【図４】
2013026835.tif 000006
【図５】
2013026835.tif 000007
【図６】
2013026835.tif 000008
【図７】
2013026835.tif 000009