"共通のバス通信路に接続され、当該バス通信路を介して相互に通信を行う通信装置であって、汎用非同期送受信回路を有するマイコンと、前記汎用非同期送受信回路からのフレームを前記バス通信路へ出力すると共に前記バス通信路を介して受信したフレームを前記汎用非同期送受信回路へ出力するトランシーバと、を備え、前記マイコンは、前記バス通信路を介して受信したフレームが正常であるか否かの情報を、前記汎用非同期送受信回路が送受信可能なブロック単位の情報として送信する受信側処理を実行可能であることを特徴とする通信装置。請求項1に記載の通信装置において、前記受信側処理では、直前に受信したフレームが正常である場合に、ACK用IDを含むブロック単位の情報を送信することを特徴とする通信装置。請求項2に記載の通信装置において、前記受信側処理では、直前に受信したフレームが正常でない場合に、NACK用IDを含むブロック単位の情報を送信することを特徴とする通信装置。請求項3に記載の通信装置において、前記受信側処理では、直前に受信したフレームが正常である場合で、かつ、先にACK用ID及びNACK用IDのいずれも受信していない場合に、ACK用IDを含むブロック単位の情報を送信することを特徴とする通信装置。請求項3又は4に記載の通信装置において、前記受信側処理では、直前に受信したフレームが正常でない場合で、かつ、先にNACK用IDを受信していない場合に、NACK用IDを含むブロック単位の情報を送信することを特徴とする通信装置。請求項1に記載の通信装置において、前記マイコンは、前記受信側処理に加え、到達確認のための到達確認用フレームを送信する送信側処理を実行可能であることを特徴とする通信装置。請求項6に記載の通信装置において、前記受信側処理では、前記到達確認用フレームを受信すると、当該到達確認用フレームの受信以前の到達確認の対象となる到達確認対象フレームに関する到達応答を含む到達応答用フレームを送信することを特徴とする通信装置。請求項7に記載の通信装置において、前記到達確認用フレームには、前記到達確認対象フレームを特定するためのフレームIDが含まれており、前記受信側処理では、前記フレームIDにより前記到達確認対象フレームを特定することを特徴とする通信装置。請求項7又は8に記載の通信装置において、前記送信側処理では、前記到達確認対象フレームに対し前記到達確認用フレームを1度だけ送信するようになっており、前記受信側処理では、前記到達確認対象フレームの受信後に前記到達確認用フレームを2度以上受信した場合、前記到達確認対象フレームを正常に受信していないと判断することを特徴とする通信装置。請求項1に記載の通信装置において、前記マイコンは、前記受信側処理に加え、到達確認のための確認用IDを送信する送信側処理を実行可能であることを特徴とする通信装置。請求項10に記載の通信装置において、前記受信側処理では、前記確認用IDを受信すると、当該確認用IDの受信以前の到達確認の対象となる到達確認対象フレームに関する到達応答を含むレスポンスを送信することを特徴とする通信装置。請求項11に記載の通信装置において、前記確認用IDは、前記到達確認対象フレームに対応させて割り当てられており、前記受信側処理では、前記確認用IDにより前記到達確認対象フレームを特定することを特徴とする通信装置。請求項11又は12に記載の通信装置において、前記送信側処理では、前記到達確認対象フレームに対し前記確認用IDを1度だけ送信するようになっており、前記受信側処理では、前記到達確認対象フレームの受信後に前記確認用IDを2度以上受信した場合、前記到達確認対象フレームを正常に受信していないと判断することを特徴とする通信装置。しかしながら、汎用非同期送受信回路を有するマイコンを用いて通信を行うことを考えた場合、汎用非同期送受信回路がいわゆる調歩同期であるため、CANプロトコルと同様の方式でACK情報を返すことはできない。これを実現するためには、マイコンとバス通信路とに介在するトランシーバにACKを返す機能を持たせる必要があり、結果として、トランシーバの規模が大きくなってしまう。本発明は、上述した課題を解決するためになされたものであり、その目的は、汎用非同期送受信回路を有するマイコンを用いて通信を行う場合に、トランシーバの規模を大きくすることなく、フレームの正常な到達を判断可能な通信装置を提供することにある。上述の目的を達成するためになされた請求項1の通信装置は、共通のバス通信路に接続されるものであり、当該バス通信路を介して相互に通信を行う。通信装置は、汎用非同期送受信回路を有するマイコンと、トランシーバとを備えている。トランシーバは、汎用非同期送受信回路からのフレームをバス通信路へ出力すると共にバス通信路を介して受信したフレームを汎用非同期送受信回路へ出力する。ここで特に、マイコンが、受信側処理を実行可能となっている。この受信側処理によって、バス通信路を介して受信したフレームが正常であるか否かの情報が、汎用非同期送受信回路が送受信可能なブロック単位の情報として送信される。このようにすれば、送信側のマイコンは受信側のマイコンからのブロック単位の情報を受信することで、フレームの正常な到達を判断することができる。その結果、トランシーバの規模を大きくすることなく、フレームの正常な到達を判断することができる。例えば請求項2に示すように、受信側処理では、直前に受信したフレームが正常である場合に、ACK用IDを含むブロック単位の情報を送信することが考えられる。具体的には、1ブロック10ビットの情報にACK用IDを含めて送信することが考えられる。例えば、スタートビット及びストップビット以外の8ビットの情報のうち、パリティビット1ビットを除く7ビットでACK用IDを表現するという具合である。このようにすれば、送信側の通信装置にてフレームの正常な到達を判断することができる。また例えば請求項3に示すように、受信側処理では、直前に受信したフレームが正常でない場合に、NACK用IDを含むブロック単位の情報を送信することが考えられる。上述の構成と同様、1ブロック10ビットの情報にNACK用IDを含めて送信することが考えられる。このようにすれば、送信側の通信装置にてフレームの正常でない異常到達を判断することができる。さらにまた例えば請求項4に示すように、受信側処理では、直前に受信したフレームが正常である場合で、かつ、先にACK用ID及びNACK用IDのいずれも受信していない場合に、ACK用IDを含むブロック単位の情報を送信することが考えられる。先に他の通信装置がACK用IDを送信している場合、重ねてACK用IDを送信する必要はないからである。また、先に他の通信装置がNACK用IDを送信している場合、当該他の通信装置にてエラーが生じているため、ACK用IDを送信することが無駄になるからである。このようにすれば、バス通信路の効率的な利用に寄与する。また例えば請求項5に示すように、受信側処理では、直前に受信したフレームが正常でない場合で、かつ、先にNACK用IDを受信していない場合に、NACK用IDを含むブロック単位の情報を送信することが考えられる。先に他の通信装置がNACK用IDを送信している場合、当該他の通信装置にてエラーが生じているため、重ねてNACK用IDを送信する必要はないからである。このようにすれば、バス通信路の効率的な利用に寄与する。ところで、請求項6に示すように、マイコンが、到達確認のための到達確認用フレームを送信する送信側処理を実行可能であることとしてもよい。このようにすれば、送信側の通信装置が、受信側の通信装置に対し、フレームが正常に到達したかどうかの確認を要求することができる。この場合、受信側処理では、到達確認用フレームを受信した場合に、当該到達確認用フレームに対する応答を行う。すなわち、請求項7に示すように、受信側処理では、到達確認用フレームを受信すると、当該到達確認用フレームの受信以前の到達確認の対象となる到達確認対象フレームに関する到達応答を含む到達応答用フレームを送信することが考えられる。ここで到達確認対象フレームに関する到達応答とは、正常に受信しているか否かの応答であってもよいし、受信した到達確認対象フレームの内容そのものの応答であってもよい。後者の場合は、送信側の通信装置で送信したフレームの内容との比較を行うことで正常に受信されているか否かを送信側で判断する。このようにすれば、送信側の通信装置から到達確認用フレームが送信されたときにだけ、受信側の通信装置から到達応答用フレームが送信されるため、バス通信路の効率的な利用が実現できる。このときは、請求項8に示すように、到達確認用フレームには、到達確認対象フレームを特定するためのフレームIDが含まれるようにするとよい。この場合、受信側処理では、フレームIDにより到達確認対象フレームを特定する。このようにすれば、到達確認対象フレームがフレームIDから特定されるため、他のフレームが途中で送信された場合であっても、到達確認が容易に実現される。ただし、1つのフレームに対し到達確認用フレームを2度以上送信すると、どのフレームに対する到達確認用フレームであるのかが分からなくなる可能性がある。請求項9に示すように、送信側処理では、到達確認対象フレームに対し到達確認用フレームを1度だけ送信するようにし、受信側処理では、到達確認対象フレームの受信後に到達確認用フレームを2度以上受信した場合、到達確認対象フレームを正常に受信していないと判断することが好ましい。この場合、到達確認と到達応答とが1対1に対応しない場合には異常受信との判断がなされる。このようにすれば、何らかの要因で到達確認対象フレームを受信できなかった場合に異常受信と判断することができる。ところで、上記構成では、送信側の通信装置が到達確認用フレームを送信し、これに対して受信側の通信装置が到達応答用フレームを送信している。したがって、到達確認及び到達応答を合計2フレームで行っている。これに対し、請求項10に示すように、マイコンが、到達確認のための確認用IDを送信する送信側処理を実行可能であることとしてもよい。このようにしても同様に、送信側の通信装置が、受信側の通信装置に対し、フレームが正常に到達したかどうかの確認を要求することができる。この場合、受信側処理では、確認用IDに続けて到達応答を含むレスポンスを送信する。すなわち、請求項11に示すように、受信側処理では、確認用IDを受信すると、当該確認用IDの受信以前の到達確認の対象となる到達確認対象フレームに関する到達応答を含むレスポンスを送信することが考えられる。ここで到達確認対象フレームに関する到達応答とは、正常に受信しているか否かの応答であってもよいし、受信した到達確認対象フレームの内容そのものの応答であってもよい。後者の場合は、送信側の通信装置で送信したフレームの内容との比較を行うことで正常に受信されているか否かを送信側で判断する。このようにすれば、送信側の通信装置から確認用IDが送信されたときにだけ、受信側の通信装置から到達応答を含むレスポンスが送信され、しかも、到達確認及び到達応答が1フレームで実現されるため、バス通信路のより効率的な利用が実現できる。このときは、請求項12に示すように、確認用IDが、到達確認対象フレームに対応して割り当てられるようにするとよい。この場合、受信側処理では、確認用IDにより到達確認対象フレームを特定する。このようにすれば、到達確認対象フレームが確認用IDから特定されるため、到達確認が容易に実現される。ただし、1つのフレームに対し確認用IDを2度以上送信すると、どのフレームに対する確認用IDであるのかが分からなくなる可能性がある。そこで、請求項13に示すように、送信側処理では、到達確認対象フレームに対し確認用IDを1度だけ送信するようにし、受信側処理では、到達確認対象フレームの受信後に確認用IDを2度以上受信した場合、到達確認対象フレームを正常に受信していないと判断することが好ましい。この場合、到達確認と到達応答とが1対1に対応しない場合には異常受信との判断がなされる。このようにすれば、何らかの要因で到達確認対象フレームを受信できなかった場合に異常受信と判断することができる。以下に本発明の実施形態を図面と共に説明する。[第1実施形態]図1は、車両に搭載される通信システムの概略構成を示すブロック図である。通信システムは、複数の通信装置以下ECUという10を備えている。これらのECU10は、バス通信路40を介して相互に接続されている。通信システムを構成するECU10は、例えばボデー系ECUであることが考えられる。具体的には、ボデーワイパECU,シートECU,スライドドアECU,ミラーECU,バックドアECU,ライトECU,チルテレ電動ステアリング位置調整装置ECU等がある。なお、ここではECU10が相互に接続される態様を示したが、ボデー系ECUと共に、関連機器としてのライトSW,ワイパSW,ライトセンサ,レインセンサ等を通信装置として接続することも考えられる。バス通信路40は、異なるECU10からハイレベルの信号とロウレベルの信号とが同時に出力されると、バス通信路40上の信号レベルがロウレベルとなるように構成されており、この機能を利用してバス調停を実現する。ここで図2aは、バス通信路40で使用する伝送路符号を示す説明図である。図2aに示すように、バス通信路40では、伝送路符号として、ビットの途中で信号レベルがロウレベルからハイレベルに変化するPWM符号が用いられ、ドミナント本実施形態では0に対応およびレセッシブ本実施形態では1に対応からなる二値の信号を2種類のデューティ比で表現する。具体的には、ドミナントの方がレセッシブよりロウレベルの比率が長くなるよう本実施形態では、ドミナントが1ビットの2/3の期間、レセッシブが1ビットの1/3の期間に設定され、バス通信路40上でドミナントとレセッシブとが衝突すると、ドミナントが調停勝ちするようにされている。そして、通信システムでは、調停負けしたECU10は送信を直ちに停止し、調停勝ちしたECU10のみが送信を継続する、いわゆるCSMA/CA方式のアクセス制御方式が用いられている。また、図2bは、ECU10間の通信に使用するレームの構成を示す説明図である。図2bに示すように、フレームは、送信を許可するデータを指定するためのヘッダと、ヘッダによって指定されたデータを送信するための可変長のレスポンスからなる。このうち、ヘッダは、識別子IDを含み、IDの値が小さいほど、バス調停で勝ち残るように設定されている。一方、レスポンスは、データ以外に、データレスポンスのサイズを示すサイズ情報、エラーの有無をチェックするためのCRC符号が少なくとも含まれている。各ECU10は、予め割り当てられた全ての機能を実行可能な動作モードであるウェイクアップモード、消費電力を抑えるために一部の機能を停止した動作モードであるスリープモードで動作する。また、ECU10の一つをマスタ、他のECU10をスレーブとして、マスタがヘッダを送信することによって、送信を許可するデータひいてはデータの送信元となるスレーブを順次指定し、ヘッダによって指定されたデータの送信元となるスレーブがレスポンスデータを送信するポーリング定期通信と、マスタからの指示によらずスレーブが自律的に通信を制御するイベント通信とを実行する。次にECU10の構成を説明する。図1に示したように、ECU10は、マイコン20と、トランシーバ30とを備えている。マイコン20は、バス通信路40を介した他ECU10との通信によって得られた情報等に基づき、自ECU10に割り当てられた各種処理を実行する。したがって、マイコン20は、CPU、ROM、RAM、I/Oポート等からなる周知のマイクロコンピュータを中心に構成されている。また、マイコン20は、UART汎用非同期送受信回路:UniversalAsynchronousReceiverTransmitter21、及び、発信回路22を有している。このUART21により、調歩同期非同期方式のシリアル通信が実現される。また、発信回路22は、マイコン20を動作させるための動作クロック及び、トランシーバ30へ供給される内部クロックを発生させる。この内部クロックは、UART21の通信速度と同じ速度本実施形態では20Kbpsに設定されている。図2cは、UART21が送受信するデータの構成を示す説明図である。図2cに示すように、UART21は、データの開始を示す1ビット長のスタートビットロウレベルと、データの終了を示すストップビットハイレベルと、これらスタートビット,ストップビットに挟まれた8ビットのデータとで構成された合計10ビットのブロック単位のデータを送受信する。なお、前述のフレーム図2b参照を構成するヘッダは、単一のブロックデータで構成され、スタートビット,ストップビットを除く8ビットのデータのうち、7ビットはIDとして用いられ、1ビットはパリティビットとして用いられる。また、レスポンスは、1ないし複数個のブロックデータで構成され、最初のブロックに、サイズ情報が設定される。一方、トランシーバ30は、マイコン20から供給される送信データを符号化してバス通信路40に出力すると共に、バス通信路40から取り込んだPWM符号の受信データを復号化してマイコン20に供給する。次に、ECU10のマイコン20にて実行される受信側処理を図3に基づき説明する。この受信側処理は、他ECU10からの送信データの受信に際し実行される。ここでは、受信側の自ECU10が、受信したデータのエラーの有無に応じ、ACKAcknowledgment又はNACKNegativeAcknowledgmentを返すようになっている。最初のS100では、フレーム受信完了か否かを判断する。ここでフレームの受信が完了したと判断された場合S100:YES、S110へ移行する。一方、フレームの受信が完了していないうちはS100:NO、S100の判断処理を繰り返す。S110では、受信エラーが無いか否かを判断する。ここで受信エラーが無いと判断された場合S110:YES、S120へ移行する。一方、受信エラーが有ると判断された場合S110:NO、S140へ移行する。受信エラー無しの場合に移行するS120では、先にACK又はNACKを受信したか否かを判断する。この処理は、他ECU10がACK又はNACKを先に送信し、当該他のECU10からのACK又はNACKを受信したたか否かを判断するものである。ここで先にACK及びNACKを受信していないと判断された場合S120:NO、S130にてACKを送信し、その後、受信側処理を終了する。一方、先にACK又はNACKを受信したと判断された場合S120:YES、S130の処理を実行せず、受信側処理を終了する。また、受信エラー有りの場合に移行するS140では、先にNACKを受信したか否かを判断する。ここで先にNACKを受信していないと判断された場合S140:NO、S150にてNACKを送信し、その後、受信側処理を終了する。一方、先にNACKを受信したと判断された場合S140:YES、S150の処理を実行せず、受信側処理を終了する。つまり、受信エラーが無い場合で先にACKを受信した場合S110:YES,S120:YES、改めて受信エラーが無かったことを送信側のECU10へ通知する必要はないため、ACKを送信しない。また、受信エラーが無い場合で先にNACKを受信した場合S110:YES,S120:YES、受信エラーが受信側の他ECU10で生じているため、受信エラーが無かったことを送信側のECU10へ通知することは無駄であるため、この場合も、ACKを送信しない。さらにまた、受信エラーが有る場合で先にNACKを受信した場合S110:NO,S140:YES、受信エラーが受信側の他ECU10で生じているため、受信エラーが有ったことを重ねて送信側のECU10へ通知することは無駄であるため、NACKを送信しない。ここで特に、本実施形態では、ACK及びNACKが、UART21が送受信するブロックデータの構成をとっている。すなわち、図2cに示すように、スタートビットと、ストップビットと、これらスタートビット及びストップビットに挟まれた8ビットのデータとで構成されている。詳しくは、8ビットのデータのうち、1ビットのパリティビットを除く7ビットがACK用ID又はNACK用IDとなっている。以上詳述したように本実施形態によれば、受信側のECU10がフレームの受信が完了したか否かを判断し図3中のS100、受信エラーが無い場合S110:YES、ブロックデータで構成されるACKを送信するS130。一方、受信エラーが有る場合S110:NO、ブロックデータで構成されるNACKを送信するS150。これにより、送信側のECU10は、これらACK及びNACKをUART21で受信してマイコン20にて処理することができ、フレームの正常な到達を判断可能となる。その結果、トランシーバ30の規模を大きくすることなく、フレームの正常な到達を判断することができる。また、本実施形態では、受信エラーが無い場合で先にACKを受信した場合S110:YES,S120:YES、受信エラーが無い場合で先にNACKを受信した場合S110:YES,S120:YES、ACKを送信しない。これにより、バス通信路40の効率的な利用に寄与する。さらにまた、本実施形態では、受信エラーが有る場合で先にNACKを受信した場合S110:NO,S140:YES、NACKを送信しない。これにより、バス通信路40の効率的な利用に寄与する。なお、本実施形態におけるECU10が通信装置を構成し、UART21が汎用非同期送受信回路を構成し、マイコン20がマイコンを構成し、トランシーバ30がトランシーバを構成し、バス通信路40がバス通信路を構成する。また、図2に示した受信側処理が受信側処理に相当する。[第2実施形態]上記第1実施形態では、データ受信側のECU10が、フレームの受信に続けて、ACK又はNACKを返す構成であった。これに対し、第2実施形態では、データ送信側のECU10が到達確認を行い、データ受信側のECU10が到達応答を行う。したがって、上記第1実施形態とは、ECU10のマイコン20で実行される処理のみが相違する。そこで上記第1実施形態との相違部分のみを説明する。まずはデータ送信側のECU10のマイコン20で実行される送信側処理を説明する。図4は、送信側処理を示すフローチャートである。最初のS200では、到達確認を実施するか否かを判断する。ここで到達確認を実施すると判断された場合S200:YES、S210にて確認用ID及び到達確認を送信し、その後、送信側処理を終了する。一方、到達確認を実施しないと判断された場合S200:NO、S200の判断処理を繰り返す。ここで確認用IDは1ブロックのヘッダに含まれ、到達確認は、レスポンスのデータに含まれる。到達確認には、到達確認の対象となる到達確認対象フレームのフレームIDが含まれる。そして、到達確認は、単一又は複数のブロックデータの構成をとっている。なお、確認用ID及び到達確認を含むレスポンスが、到達確認用フレームを構成する。次にデータ受信側のECU10のマイコン20で実行される受信側処理を説明する。図5は、受信側処理を示すフローチャートである。最初のS300では、到達確認用フレームを受信したか否かを判断する。到達確認用フレームは、確認用ID及び到達確認を含むレスポンスで構成される。ここで到達確認用フレームを受信したと判断された場合S300:YES、S310へ移行する。一方、到達確認用フレームを受信していないうちはS300:NO、S300の判断処理を繰り返す。S310では、到達確認対象フレームを正常に受信したか否かを判断する。ここで到達確認対象フレームを正常に受信したと判断された場合S310:YES、S320にて応答用ID及び到達応答で正常受信を送信し、その後、受信側処理を終了する。一方、到達確認対象フレームを正常に受信していないと判断された場合S310:NO、すなわち受信エラーの場合には、S330にて応答用ID及び到達応答で異常受信を送信し、その後、受信側処理を終了する。ここで応答用IDは1ブロックのヘッダに含まれ、到達応答は、レスポンスのデータに含まれる。到達応答には、少なくとも正常受信又は異常受信の情報が含まれる。そして、到達応答は、単一又は複数のブロックデータの構成をとっている。以上詳述したように本実施形態によれば、送信側のECU10が確認用ID及び到達確認を含むレスポンスからなる到達確認用フレームを送信する図4中のS210。これに対し、受信側のECU10は、到達確認用フレームの受信を判断し図5中のS300、到達確認対象フレームが正常に受信されている場合S310:YES、応答用ID及び正常受信を示す到達応答を含むレスポンスからなる到達応答用フレームを送信するS320。一方、到達確認対象フレームが正常に受信されていない場合S310:NO、応答用ID及び異常受信を示す到達応答を含むレスポンスからなる到達応答用フレームを送信するS330。このとき、到達確認及び到達応答は、単一又は複数のブロックデータで構成されているため、UART21での送受信が可能でありマイコン20で処理できる。これにより、トランシーバ30の規模を大きくすることなく、フレームの正常な到達を判断することができる。また、送信側のECU10は、受信側のECU10に対し、フレームが正常に到達したかどうかの確認を要求することができ、送信側のECU10から到達確認用フレームが送信されたときにだけ、受信側のECU10から到達応答用フレームが送信されるため、バス通信路40の効率的な利用が実現できる。また、本実施形態では、レスポンスに含まれる到達確認に、到達確認の対象となる到達確認対象フレームのフレームIDが含まれている。これにより、到達確認対象フレームがフレームIDから特定されるため、他のフレームが途中で送信された場合であっても、到達確認が容易に実現される。なお、本実施形態におけるECU10が通信装置を構成し、UART21が汎用非同期送受信回路を構成し、マイコン20がマイコンを構成し、トランシーバ30がトランシーバを構成し、バス通信路40がバス通信路を構成する。また、図4に示した送信側処理が送信側処理に相当し、図5に示した受信側処理が受信側処理に相当する。[第3実施形態]第3実施形態も、第2実施形態と同様、データ送信側のECU10が到達確認を行い、データ受信側のECU10が到達応答を行う。ただし、第2実施形態では到達確認及び到達応答を2フレームで行っていたのに対し、本実施形態では、到達確認及び到達応答を1フレームで行う。まずはデータ送信側のECU10のマイコン20で実行される送信側処理を説明する。図6は、送信側処理を示すフローチャートである。最初のS400では、到達確認を実施するか否かを判断する。ここで到達確認を実施すると判断された場合S400:YES、S410にて確認用IDを送信し、その後、送信側処理を終了する。一方、到達確認を実施しないと判断された場合S400:NO、S400の判断処理を繰り返す。つまり、上記第2実施形態と異なるのは、確認用IDのみを送信する点である。ここで確認用IDは1ブロックのヘッダに含まれる。次にデータ受信側のECU10のマイコン20で実行される受信側処理を説明する。図7は、受信側処理を示すフローチャートである。最初のS500では、確認用IDを受信したか否かを判断する。ここで確認用IDを受信したと判断された場合S500:YES、S510へ移行する。一方、確認用IDを受信していないうちはS500:NO、S500の判断処理を繰り返す。S510では、到達確認対象フレームを正常に受信したか否かを判断する。なお、到達確認対象フレームに対応して確認用IDが用意されているものとする。ここで到達確認対象フレームを正常に受信したと判断された場合S510:YES、S520にて到達応答で正常受信を送信し、その後、受信側処理を終了する。一方、到達確認対象フレームを正常に受信していないと判断された場合S510:NO、すなわち受信エラーの場合には、S530にて到達応答で異常受信を送信し、その後、受信側処理を終了する。ここで、到達応答は、レスポンスのデータに含まれる。また、到達応答には、少なくとも正常受信又は異常受信の情報が含まれる。そして、到達応答は、単一又は複数のブロックデータの構成をとっている。以上詳述したように本実施形態によれば、送信側のECU10が確認用IDを送信する図6中のS410。これに対し、受信側のECU10は、確認用IDの受信を判断し図7中のS500、到達確認対象フレームが正常に受信されている場合S510:YES、正常受信を示す到達応答を含むレスポンスを確認用IDに続けて送信するS520。一方、到達確認対象フレームが正常に受信されていない場合S510:NO、異常受信を示す到達応答を含むレスポンスを確認用IDに続けて送信するS530。このとき、到達確認及び到達応答は、単一又は複数のブロックデータで構成されているため、UART21での送受信が可能である。これにより、トランシーバ30の規模を大きくすることなく、フレームの正常な到達を判断することができる。また、送信側のECU10は、受信側のECU10に対し、フレームが正常に到達したかどうかの確認を要求することができ、送信側のECU10から確認用IDが送信されたときにだけ、受信側のECU10から到達応答を含むレスポンスが送信されるため、バス通信路40の効率的な利用が実現できる。また、本実施形態では、到達確認対象フレームに対応して確認用IDが用意されている。これにより、到達確認対象フレームが確認用IDから特定されるため、他のフレームが途中で送信された場合であっても、到達確認が容易に実現される。さらにまた、本実施形態では、到達確認及び到達応答が1フレームで実現されるため、バス通信路のより効率的な利用が実現できる。なお、本実施形態におけるECU10が通信装置を構成し、UART21が汎用非同期送受信回路を構成し、マイコン20がマイコンを構成し、トランシーバ30がトランシーバを構成し、バス通信路40がバス通信路を構成する。また、図6に示した送信側処理が送信側処理に相当し、図7に示した受信側処理が受信側処理に相当する。[他の実施形態]1つのフレームに対し到達確認到達確認用フレーム又は確認用IDを2度以上送信すると、どのフレームに対する確認であるのかが分からなくなる可能性がある。そこで、第2実施形態及び第3実施形態の構成において、到達確認対象フレームに対する到達確認を1度だけ行う構成とすることが好ましい。この場合、第2実施形態の受信側処理図5におけるS310にて肯定判断された後、直前に受信した到達確認対象フレームの後に、到達確認フレームを2度以上受信したか否かを判断し、2度以上受信している場合にはS330へ移行し、1度だけ受信している場合にはS320へ移行するようにする。また、第3実施形態の受信側処理図7におけるS510にて肯定判断された後、直前に受信した到達確認対象フレームの後に、確認用IDを2度以上受信したか否かを判断し、2度以上受信している場合にはS530へ移行し、1度だけ受信している場合にはS520へ移行するようにする。このようにすれば、何らかの要因で到達確認対象フレームを受信できなかった場合に異常受信と判断することができる。また、上記実施形態では、受信側のECU10にて到達確認対象フレームを正常に受信したか否かを判断し図5中のS310,図7中のS510、正常受信又は異常受信を応答していた図5中のS320,S330,図7中のS520,530。これに対し、到達確認対象フレームの内容をそのまま応答し、送信側のECU10が、送信したフレームの内容と比較することで正常受信又は異常受信を判断するようにしてもよい。以上本発明は、上述した実施形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において種々なる形態で実施可能である。"