(57)【特許請求の範囲】
【請求項１】
バス調停が行われるバスを介して接続された複数のノードからなり、前記ノードの一つであるマスタノードが前記ノードのいずれかを順次指定し、指定されたノードがデータを送信する受動通信と、前記マスタノード以外のノードであるスレーブノードが能動的に通信を行う能動通信とを併用し、
前記受動通信では、前記マスタノードが、前記受動通信の実行タイミングであることを示す識別情報である第１の識別情報に続けて、データの送信を許可するノードを指定するための指定情報を送信し、
前記能動通信では、前記マスタノードが、前記能動通信の実行タイミングであることを示す識別情報である第２の識別情報を送信すると共に、前記能動通信の要求が発生したノードである要求ノードが、前記第２の識別情報に続けて、データの送信を許可するノードを指定するための指定情報を送信し、
前記ノードは、前記指定情報が自ノードを指定するものである場合に、該指定情報に続けてデータを送信する通信システムにおいて、
前記識別情報は、前記第１の識別情報であるか前記第２の識別情報であるかを、該識別情報の前半部分で判断可能に設定され、
前記要求ノードは、前記識別情報の前半部分から前記第１の識別情報を受信したと判断した場合に、前記バス調停を利用して該識別情報の書き換えを行う衝突ヘッダを、該識別情報の後半部分と衝突するタイミングで送信し、該衝突ヘッダにより書き換えられた識別情報を前記第２の識別情報と見なして、前記能動通信を実行することを特徴とする通信システム。
【請求項２】
前記第１の識別情報に前記指定情報としての機能を持たせ、
前記マスタノードは、前記受動通信での前記指定情報の送信を省略することを特徴とする請求項１に記載の通信システム。
【請求項３】
バス調停が行われるバスを介して接続された複数のノードからなり
前記ノードの一つであるマスタノードが、データの送信を許可するノードを指定するための指定情報を送信し、
前記ノードは、前記指定情報が自ノードを指定するものである場合に、該指定情報に続けてデータを送信する受動通信を実行する通信システムにおいて、
前記マスタノードは、前記指定情報を送信する前に前記受動通信の実行タイミングであることを示す識別情報を送信し、
前記マスタノード以外のノードであるスレーブノードが能動的に行う通信を能動通信として、該能動通信の要求が発生したノードである要求ノードは、前記識別情報と衝突すると前記バス調停を利用して該識別情報を書き換える衝突ヘッダを、前記指定情報や前記データを送受信している期間以外の期間を用いて送信し、該衝突ヘッダまたは該衝突ヘッダにより書き換えられた識別情報を、前記能動通信の実行タイミングであることを示す識別情報として、該識別情報に続けて、前記能動通信の要求に応じた指定情報を送信することを特徴とする通信システム。
【請求項４】
請求項１または請求項２に記載の通信システムを構成するノードであって、
自ノードを指定する指定情報を受信した場合に、該指定情報に続けてデータを送信する応答送信手段と、
自ノードにおいて前記能動通信の要求が発生すると、前記識別情報の前半部分から前記第１の識別情報を受信したと判断した場合に、該識別情報の後半部分と衝突するタイミングで前記衝突ヘッダを送信し、該衝突ヘッダにより書き換えられた識別情報に続けて前記指定情報を送信する能動通信要求手段と、
を備えることを特徴とするノード。
【請求項５】
請求項３に記載の通信システムを構成するノードであって、
自ノードを指定する指定情報を受信した場合に、該指定情報に続けてデータを送信する応答送信手段と、
自ノードにおいて前記能動通信の要求が発生すると、前記指定情報や前記データを送受信している期間以外の期間を用いて前記衝突ヘッダを送信し、該衝突ヘッダまたは該衝突ヘッダにより書き換えられた識別情報を、前記能動通信の実行タイミングであることを示す識別情報として、該識別情報に続けて、前記能動通信の要求に応じた指定情報を送信する能動通信要求手段と、
を備えることを特徴とするノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マスタノードから指定されたスレーブノードがデータを送信する受動通信と、スレーブノードが能動的にデータを送信する能動通信とを併用する通信システムに関する。
【背景技術】
【０００２】
従来、マスタノード（以下「マスタ」という）からヘッダを送信し、そのヘッダに対応付けられたスレーブノード（以下「スレーブ」という）が、ネットワーク上にデータを送出するマスタスレーブ方式の通信プロトコルが知られている。
【０００３】
マスタフレーブ方式の通信プロトコルでは、スレーブは、通常、予め設定されたスケジュールに従ってマスタから送信されてくるヘッダに従って、受動的にデータの送信を行っている。しかし、あるスレーブにてイベントが発生した場合に、これを速やかに他のノードに伝えたい等の要求があり、こういった要求を実現するために、上述のスケジュールに従ったデータ送信のタイミングを待つことなく、スレーブから能動的にデータを送信する仕組みを組み込むことが考えられている。
【０００４】
例えば、車載ネットワークに適用されるＬＩＮ（Local Interconnect Network）プロトコルでは、指定したスレーブだけにレスポンスを送信させるためのヘッダ（いわゆる無条件フレーム用のヘッダ）の他に、イベントの発生を検出したスレーブにレスポンスを送信させるためのヘッダ（いわゆるイベントトリガフレーム用のヘッダ）が用意されている。
【０００５】
そして、スレーブは、イベントの発生を検出すると、イベントトリガフレームを用いてレスポンスを送信するようにされている（例えば、非特許文献１参照）。
また、次のような通信方法も提案されている。即ち、マスタからスレーブへの出力データは、一つのＯＵＴフレームで一括して転送し、スレーブからマスタへの入力データは、各スレーブに互いに重複しないように割り当てられた時間帯にＩＮフレームをそれぞれ返送することで、定期的な通信を実現する。これと共に、ＯＵＴフレームにてマスタがメッセージ通信要求の有無を確認したい単数または複数のスレーブを指定し、その指定されたスレーブがメッセージ送信要求を示す応答フレームを返送すると、マスタは、応答フレームを返送してきたスレーブに対してメッセージ送信許可フレームを送信することでバス権を渡し、バス権を持ったスレーブがマスタに対してメッセージを送信することにより、スレーブから能動的にデータを送信することを可能としている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００７−６６１１１号公報
【非特許文献】
【０００７】
【非特許文献１】佐藤道夫著「車載ネットワークシステム徹底解説」ＣＱ出版株式会社、２００５年１２月１日発行
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、ＬＩＮでは、イベントトリガフレーム用のヘッダ（以下「イベントヘッダ」という）は、無条件フレーム用のヘッダとは異なり、同一のヘッダが複数のスレーブに対応付けられているため、図１５に示すように、その同一のイベントヘッダに対応付けられた複数のスレーブが同時にレスポンスを送信した場合には衝突が発生する。
【０００９】
なお、図中では、スレーブ＿１，スレーブ＿２に共通のイベントヘッダとしてＩＤ＝０Ｘ１０を用い、スレーブ＿１，スレーブ＿２を個別に指定するヘッダとしてＩＤ＝０ｘ２０、ＩＤ＝０ｘ３０を用いるものとする。
【００１０】
このようなレスポンスの衝突を検出した場合（衝突発生時の最初のスロット）、衝突したレスポンスが破棄されると共に、マスタは、再度の衝突を避けるために、衝突を引き起こしたイベントヘッダに対応付けられている個々のスレーブに対して、レスポンスするスレーブを指定したヘッダ（無条件フレーム用のヘッダ）を順次送信することになり（衝突発生時の２番目および３番目のスロット）、通信効率を低下させてしまうという問題があった。
【００１１】
また、特許文献１に記載の通信方法では、スレーブが能動的にマスタに対してデータを送信するためには、マスタからスレーブにＯＵＴフレーム（スレーブ指定）を送信し、スレーブからマスタに応答フレーム（メッセージ送信要求）を送信し、マスタからスレーブにメッセージ送信許可フレームを送信するという３個のフレームのやり取りが必要であり、その後、やっとスレーブからの能動的なメッセージを送信することが可能となる。
【００１２】
このように特許文献１に記載の方法では、メッセージをやり取りする手順が複雑であり、そのやり取りによってバス上の通信効率を悪化させるだけでなく、イベントの発生を速やかにマスタに通知することができないという問題があった。
【００１３】
本発明は、上記問題点を解決するために、マスタスレーブ方式の通信プロトコルが適用される通信システムにおいて、通信効率を低下させることなく、少ない待ち時間でスレーブからの能動的なフレームの送信を可能とすることを目的とする。
【課題を解決するための手段】
【００１４】
上記目的を達成するためになされた発明である請求項１に記載の通信システムは、バス調停が行われるバスを介して接続された複数のノードからなり、ノードの一つであるマスタノードがノードのいずれかを順次指定し、指定されたノードがデータを送信する受動通信と、マスタノード以外のノードであるスレーブノードが能動的に通信を行う能動通信とを併用する。
【００１５】
受動通信では、マスタノードが、受動通信の実行タイミングであることを示す識別情報である第１の識別情報に続けて、データの送信を許可するノードを指定するための指定情報を送信し、能動通信では、マスタノードが、能動通信の実行タイミングであることを示す識別情報である第２の識別情報を送信すると、能動通信の要求が発生したノードである要求ノードが、第２の識別情報に続けて、データの送信を許可するノードを指定するための指定情報を送信する。なお、能動通信では、複数の要求ノードが同時に識別情報を送信する可能性があるが、バス調停により、勝ち残った識別情報に従って通信が実行される。
【００１６】
そして、受動通信か能動通信かによらず、各ノードは、指定情報が自ノードを指定するものである場合に、その指定情報に続けてデータを送信する。
また、本発明の通信システムでは、識別情報は、第１の識別情報であるか第２の識別情報であるかを、その識別情報の前半部分で判断可能に設定されており、要求ノードは、識別情報の前半部分から第１の識別情報を受信したと判断した場合に、バス調停を利用して識別情報の書き換えを行う衝突ヘッダを、その識別情報の後半部分と衝突するタイミングで送信し、該衝突ヘッダにより書き換えられた識別情報を第２の識別情報と見なして能動通信を実行する。
【００１７】
このように構成された本発明の通信システムでは、各ノードは、マスタノードから送信される識別情報によって、受動通信の実行タイミングか能動通信の実行タイミングかを識別しており、受動通信と能動通信との切り替えのためにノード間で特別なフレームをやり取りする必要がないため、各ノードが能動的に通信を行う必要がある場合に、その通信を速やかに実行することができる。
【００１８】
しかも、本発明の通信システムでは、受動通信のタイミングで能動通信の要求が発生した時には、衝突ヘッダを送信することで識別情報を書き換えて、能動通信を実行するため、受動通信より優先して能動通信を実行することができる。
【００１９】
更に、本発明の通信システムによれば、複数のノードにて能動通信の要求が発生し、これらのノードから同時に指定情報が送信されたとしても、バス調停に勝ち残った指定情報に従って通信が実行されるため、効率よく通信を行うことができる。
【００２０】
なお、指定情報としては、例えば、ノードを識別するものや、データの種類を識別するもの（データの送信元となるノードを間接的に指定することになる）を用いることができる。
【００２１】
ところで、本発明の通信システムは、請求項２に記載のように、第１の識別情報に指定情報としての機能を持たせることにより、マスタノードは、受動通信での指定情報の送信を省略するように構成されていてもよい。
【００２２】
このように構成された本発明の通信システムによれば、受動通信でのメッセージ長が短くなるため、バスの通信効率をより向上させることができる。
次に、請求項３に記載の通信システムは、バス調停が行われるバスを介して接続された複数のノードからなり、ノードの一つであるマスタノードが、データの送信を許可するノードを指定するための指定情報を送信し、各ノードは、指定情報が自ノードを指定するものである場合に、その指定情報に続けてデータを送信する受動通信を実行する。
【００２３】
そして、マスタノードは、指定情報を送信する前に受動通信の実行タイミングであることを示す識別情報を送信する。
また、マスタノード以外のノードであるスレーブノードが能動的に行う通信を能動通信として、能動通信の要求が発生したノードである要求ノードは、識別情報と衝突するとバス調停を利用して該識別情報を書き換える衝突ヘッダを、指定情報やデータを送受信している期間以外の期間を用いて送信し、衝突ヘッダまたは衝突ヘッダにより書き換えられた識別情報を、能動通信の実行タイミングであることを示す識別情報として、その識別情報に続けて、能動通信の要求に応じた指定情報を送信する。
【００２４】
このように構成された本発明の通信システムによれば、能動通信の要求が発生したノードが、衝突ヘッダを送信することで指定情報を書き換えて能動通信を実行するため、能動通信を優先的に且つ速やかに実現することができる。
【００２５】
しかも、本発明の通信システムでは、マスタノードは、能動通信の実行タイミングを確保するための識別情報を送信する必要がないため、請求項１に記載の通信システムと比較して、より通信効率を向上させることができる。
【００２６】
次に請求項４に記載のノードでは、応答送信手段が、自ノードを指定する指定情報を受信した場合に、その指定情報に続けてデータを送信する。また、能動通信要求手段が、自ノードにおいて能動通信の要求が発生すると、識別情報の前半部分から第１の識別情報を受信したと判断した場合に、該識別情報の後半部分と衝突するタイミングで衝突ヘッダを送信し、この衝突ヘッダにより書き換えられた識別情報に続けて指定情報を送信する。
【００２７】
このように構成された本発明のノードは、請求項１または請求項２に記載の通信システムを構築する際に好適に用いることができる。
また請求項５に記載のノードでは、応答送信手段が、自ノードを指定する指定情報を受信した場合に、その指定情報に続けてデータを送信する。また、能動通信要求手段が、自ノードにおいて能動通信の要求が発生すると、指定情報やデータを送受信している期間以外の期間を用いて衝突ヘッダを送信し、この衝突ヘッダまたは衝突ヘッダにより書き換えられた識別情報を、能動通信の実行タイミングであることを示す識別情報として、該識別情報に続けて能動通信の要求に応じた指定情報を送信する。
【００２８】
このように構成された本発明のノードは、請求項３に記載の通信システムを構築する際に好適に用いることができる。
【図面の簡単な説明】
【００２９】
【図１】第１実施形態の通信システムおよびその一部であるノードの構成を示すブロック図。
【図２】通信システムで使用するフレームの構成、マイコンとトランシーバとの間で送受信するデータの構成、符号化されたデータの構成を示す説明図。
【図３】衝突ヘッダ生成回路の動作を示すフローチャート。
【図４】衝突ヘッダの作用を示す説明図。
【図５】マスタタスクの処理内容を示すフローチャート。
【図６】スレーブタスクの処理内容を示すフローチャート。
【図７】ヘッダ応答処理の詳細を示すフローチャート。
【図８】イベント処理の詳細を示すフローチャート。
【図９】第１実施形態の通信システムにおける基本動作を示すタイミング図。
【図１０】複数のスレーブでイベント通信要求が発生した場合の動作例を示すタイミング図。
【図１１】第１実施形態の変形例における基本動作を示すタイミング図。
【図１２】第２実施形態の通信システムおよびその一部であるノードの構成を示すブロック図。
【図１３】スレーブタスクの処理内容を示すフローチャート。
【図１４】衝突ヘッダの作用を示す説明図。
【図１５】従来技術の問題点を示すタイミング図。
【発明を実施するための形態】
【００３０】
以下に本発明の実施形態を図面と共に説明する。
［第１実施形態］
＜全体構成＞
図１は、マスタスレーブ方式の通信プロトコルが適用された車載用の通信システム１の構成を示すブロック図である。
【００３１】
図１に示すように、通信システム１は、車両の状態を検出したり車両の状態を制御したりするため設けられた各種機器（以下「制御対象機器」という）に搭載されるスレーブノード１０ｂと、バスＢＳを介して接続されたスレーブノード１０ｂとの通信により、制御対象機器が検出した車両の状態を取得したり、制御対象機器に対する各種指令を生成して車両制御を行うマスタノード１０ａとを備えている。以下では、マスタノード１０ａをマスタ、スレーブノード１０ｂをスレーブと称し、両者を総称する場合はノード１０と称する。
【００３２】
マスタ１０ａは、車載ネットワーク（図示せず）に接続され、ボディ系のアプリケーションを実現する電子制御装置（ＥＣＵ）からなる。例えば、マスタ１０ａが、ドアに関するアプリケーションを制御するＥＣＵである場合、スレーブ１０ｂを搭載する制御対象機器としては、ミラー、ドアロック、ウィンドウ等を制御する機器が考えられる。
【００３３】
なお、スレーブ１０ｂを搭載する制御対象機器としては、例えば、サンルーフ、ワイパ、パワーシート、エアコン、ステアリング、ライト等を制御する機器であってもよい。
＜フレームフォーマット＞
ここで、図２は、通信システムにおいてデータの送受信に使用するフレームの構成を示す説明図である。
【００３４】
ノード１０間の通信は、マスタ１０ａがノード１０を順次指定（いわゆるポーリング）して、指定されたノード１０がレスポンス（データ）を送信する受動通信（以下「定期通信」という）と、マスタ１０ａが指定する期間を利用して、各ノード１０が能動的にデータを送信する能動通信（以下「イベント通信」という）とを行う。
【００３５】
そして、図２（ａ）に示すように、定期通信では、マスタ１０ａが、定期通信の実行タイミングであることを示すヘッダ（識別情報）Ｈである定期ヘッダＨｃ、およびレスポンスＲを返すスレーブを指定するための指定情報ＩＤを続けて送信する。この定期ヘッダＨｃおよび指定情報ＩＤを受信したノード１０は、指定情報ＩＤが自ノード１０を指定するものである場合に、受信した指定情報ＩＤに続けてレスポンスＲを送信する。
【００３６】
一方、イベント通信では、マスタ１０ａが、イベント通信の実行タイミングであることを示すヘッダＨであるイベントヘッダＨｅのみを送信し、このイベントヘッダＨｅを受信した各ノード１０は、自ノード１０においてイベント通信の要求が発生している場合に、その要求に応じた指定情報ＩＤを、受信したイベントヘッダＨｅに続けて送信する。更に、各ノード１０は、指定情報ＩＤが自ノード１０を指定するものである場合、受信した指定情報ＩＤに続けてレスポンスＲを送信する。
【００３７】
なお、イベント通信の要求は、例えば、ドライバの操作（例えば、ドアの開閉操作等）によって制御対象機器の状態が変化し、その状態の変化（イベント要因）を速やかにマスタ１０ａに通知する必要がある場合等に発生する。
【００３８】
また、ヘッダＨは１バイトのビットデータで表され、定期ヘッダＨｃには０ｘＦＦ、イベントヘッダＨｅには０ｘ００が用いられる。また、後述する衝突ヘッダによって０ｘＦＦから０ｘＦ０に書き換えられた定期ヘッダＨｃを、書換イベントヘッダＨｘと呼ぶ。
【００３９】
但し、バスＢＳ上では、ビット０とビット１とが同時に送信された場合（衝突した場合）、ビット０が優先されるものとする。
また、指定情報ＩＤは、ノード１０を直接指定するものであってもよいし、レスポンスＲとして送信するデータの種類を指定することによって、そのデータの送信元となるノード１０を間接的に指定するものであってもよい。
【００４０】
＜ノード＞
次に、ノード１０の構成について説明する。但し、マスタ１０ａとスレーブ１０ｂとは、同様の構成を有している。
【００４１】
図１に示すように、ノード１０は、通信システム１を介した他のノード１０との通信を行うための処理等を実行するマイクロコンピュータ（以下「マイコン」という）１１と、バスＢＳに接続されて、マイコン１１から与えられるデータＴｘを符号化した送信データＴｘＤをバスＢＳに出力すると共に、バスＢＳ上のデータ（受信データ）ＲｘＤを受信し、復号したデータＲｘをマイコン１１に入力するトランシーバ１２とを備えている。
【００４２】
＜マイコン＞
マイコン１１は、ＣＰＵ，ＲＯＭ，ＲＡＭ，ＩＯポート等からなるマイコンにおける周知の構成に加えて、調歩同期（非同期）方式のシリアル通信を実現するＵＡＲＴ（汎用非同期受信・送信機：Universal Asynchronous Receiver Transmitter ）１１ａを備えていると共に、トランシーバ１２に対して、後述する衝突ヘッダの送信を要求する送信要求ＲＱを出力するための出力ポートが設けられている。
【００４３】
ＵＡＲＴ１１ａが送受信するデータＴｘ，Ｒｘは、図２（ｂ）に示すように、データの開始を示す１ビット長のスタートビット（ロウレベル）と、データの終了を示すストップビット（ハイレベル）とで挟まれた８ビットのデータとで構成された合計１０ビットのブロックデータからなり、主要部となる８ビートのデータは、ＬＳＢが先頭、ＭＳＢが末尾となるように設定されている。
【００４４】
本実施形態では、ヘッダＨ，指定情報ＩＤは、いずれも、ＵＡＲＴ１１ａが１度に送受信可能な１０ビットのブロックデータで構成され、レスポンスＲは、レスポンスＲの中で設定されるデータ長に相当する個数（１ないし複数個）のブロックデータで構成されている。
【００４５】
そして、ノード１０のマイコン１１では、ノード１０のそれぞれに個別に割り当てられた機能を実現するための処理を実行し、その処理の中でレスポンスＲとして送信するデータを生成したり、イベント通信の要求を発生させたりする。
【００４６】
また特に、スレーブ１０ｂのマイコン１１では、受信した指定情報ＩＤに従ったレスポンスＲの送信や、イベント通信を実行するための処理であるスレーブタスクを実行する。
一方、マスタ１０ａのマイコン１１では、予め設定されたスケジュールに従って、ヘッダＨの送信を制御することで、バスＢＳ上の通信を制御する処理であるマスタタスク、および、マスタ１０ａをスレーブとしても機能させるために、スレーブ１０ｂが実行するものと同様のスレーブタスクを実行する。
【００４７】
＜トランシーバ＞
図１に戻り、トランシーバ１２は、マイコン１１から供給されるデータＴｘ（ＮＲＺ符号）を、バスＢＳ上で用いる符号に符号化する符号化回路１３と、符号化回路１３にて符号化された送信データＴｘＤをバスＢＳに出力する送信バッファ１４と、バスＢＳ上のデータを取り込む受信バッファ１５と、受信バッファ１５が取り込んだ受信データＲｘＤを復号し、復号したデータＲｘをマイコン１１に供給する復号回路１６とを備えている。
【００４８】
また、トランシーバ１２は、送信データＴｘＤまたは受信データＲｘＤのスタートビットを検出するとブロックデータの長さ（１０ビットの期間）だけ、送信バッファ１４への送信データＴｘＤの供給を許可すると共に、送信データＴｘＤと受信データＲｘＤとで信号レベルの不一致を検出した場合には、送信バッファ１４への送信データＴｘＤの供給を直ちに禁止する調停回路１７と、マイコン１１からの送信要求ＲＱが入力されると、受信データＲｘＤから抽出されるタイミングに基づき、予め設定されたタイミングで衝突ヘッダを符号化回路１３に供給する衝突ヘッダ生成回路１８とを備えている。
【００４９】
送信バッファ１４は、複数のノードからバスＢＳに信号が同時に出力された場合、いずれか一つでもロウレベルであれば、バスＢＳの信号レベルがロウレベルとなるように構成され、また、調停回路１７によって送信データＴｘＤの供給が禁止されている時には、ハイレベルを出力するように構成されている。
【００５０】
このような構成は、例えば、周知のオープンコレクタ回路を用いて構成することができる。以下では、バスＢＳ上のハイレベルをレセッシブ、ロウレベルをドミナントともいう。
【００５１】
受信バッファ１５は、バスＢＳの信号レベルが、予め設定された閾値より大きければハイレベル、閾値より低ければロウレベルを出力する周知のコンパレータによって構成することができる。
【００５２】
符号化回路１３は、図２（ｃ）に示すように、データＴｘの１ビットの長さを４等分し、データＴｘがロウレベル（０）の時には、１ビット中の前３／４期間がロウレベル、後１／４期間がハイレベルとなる第１符号に変換し、データＴｘがハイレベル（１）の時には、１ビット中の前１／４期間がロウレベル、後３／４期間がハイレベルとなる第２符号に変換する。つまり、符号化回路１３は、ＮＲＺ符号をＰＷＭ符号に変換し、復号回路１６は、ＰＷＭ符号をＮＲＺ符号に変換するように構成されている。
【００５３】
つまり、バスＢＳ上で、第１符号（Ｔｘ＝‘Ｌ’）と第２符号（Ｔｘ＝‘Ｈ’）とが衝突した場合、第１符号はそのまま送信され（バス調停で勝ち残り）、第２符号は第１符号に書き換えられる（バス調停で負ける）。従って、この場合、第２符号を送信したノードでは、送信した信号の信号レベルとバスＢＳから取り込んだ信号の信号レベルが不一致となり、その時点で、調停回路１７によって、送信バッファ１４への送信データＴｘＤの供給が禁止されることになる。
【００５４】
調停回路１７は、例えば、送信データＴｘＤと受信データＲｘＤを入力とする排他的論理和回路（ＸＯＲゲート）、送信データＴｘＤの送信を許可／禁止するゲート回路、スタートビットを検出するスタートビット検出回路、スタートビットを検出してからの１０ビットに相当する時間を計測する計測回路等を組み合わせることによって容易に実現することができるため、ここではその詳細な構成についての説明は省略する。
【００５５】
＜衝突ヘッダ生成回路＞
ここで、衝突ヘッダ生成回路１８の動作を、図３に示すフローチャートに沿って説明する。なお、衝突ヘッダ生成回路１８は、論理回路によって容易に実現することができるため、その回路の詳細についての説明は省略する。
【００５６】
図３に示すように、衝突ヘッダ生成回路１８は、まず、送信要求ＲＱがセットされているか否かを判断し（Ｓ１０）、送信要求ＲＱがセットされていなければ（Ｓ１０：ＮＯ）、セットされるまで待機する。
【００５７】
送信要求ＲＱがセットされると（Ｓ１０：ＹＥＳ）、復号回路１６によって、ヘッダＨの前半４ビット（スタートビットを含めると５ビット）を受信したか否かを判断し（Ｓ２０）、受信していなければ（Ｓ２０：ＮＯ）Ｓ１０に戻る。
【００５８】
ヘッダＨの前半４ビットを受信すると（Ｓ２０：ＹＥＳ）、受信したヘッダＨは、定期ヘッダＨｃであるか否かを判断する（Ｓ３０）。ここでは、受信した４ビットが全て‘Ｈ（第２符号）’であれば定期ヘッダＨｃであると判断する。
【００５９】
そして、定期ヘッダＨｃであれば（Ｓ３０：ＹＥＳ）、全てのビットが‘Ｌ（第１符号）’で構成された４ビットの衝突ヘッダを、受信したヘッダＨの後半４ビットと重なるタイミングで、符号化回路１３に送信させた（Ｓ４０）後に、送信要求ＲＱをリセットして（Ｓ５０）、Ｓ１０に戻る。
【００６０】
一方、受信したヘッダＨが定期ヘッダＨｃでなければ（Ｓ３０：ＮＯ）、即ち、イベントヘッダＨｅであれば、衝突ヘッダを送信することなく、送信要求ＲＱをリセットだけを行って（Ｓ５０）、Ｓ１０に戻る。
【００６１】
つまり、図４に示すように、衝突ヘッダ生成回路１８が衝突ヘッダを送信すると、定期ヘッダＨｃ（０ｘＦＦ）は、８ビットのデータのうち後半部分の４ビットが全て０に書き換えられることにより、書換イベントヘッダＨｘ（０ｘＦ０）となる。
【００６２】
＜マスタタスク＞
次に、マスタ１０ａのマイコン１１が実行するマスタタスクの内容を、図５に示すフローチャートに沿って説明する。
【００６３】
マスタタスクは、マスタ１０ａに電源が投入され、初期化処理等が実行されることによって、バスＢＳの使用が可能となると起動する。
本処理が起動すると、定期ヘッダＨｃの送信タイミングであるか否かを判断し（Ｓ１１０）、定期ヘッダＨｃの送信タイミングでなければ（Ｓ１１０：ＮＯ）、イベントヘッダＨｅの送信タイミングであるか否かを判断し（Ｓ１９０）、イベントヘッダＨｅの送信タイミングでなければ（Ｓ１９０：ＮＯ）、Ｓ１１０に戻る。
【００６４】
なお、定期ヘッダＨｃおよびイベントヘッダＨｅは、予め設定されたスケジュールに従って送信される。具体的には、例えば、定期ヘッダＨｃとイベントヘッダＨｅとを交互に送信するようなスケジュールであってもよいし、定期ヘッダＨｃおよびイベントヘッダＨｅのいずれか一方をＭ（Ｍは２以上の整数）回続ける毎に、他方を１回だけ挿入するようなスケジュールであってもよい。
【００６５】
そして、定期ヘッダＨｃの送信タイミングであると判断した場合（Ｓ１１０：ＹＥＳ）、定期ヘッダＨｃをＵＡＲＴ１１ａに送信させる（Ｓ１２０）共に、ＵＡＲＴ１１ａが受信したヘッダＨが、送信した定期ヘッダＨｃと一致しているか否かを判断する（Ｓ１３０）。
【００６６】
受信したヘッダＨが送信したヘッダＨｃと一致していなければ（Ｓ１３０：ＮＯ）、衝突ヘッダによる定期ヘッダＨｃの書き換えが行われたものとして、Ｓ１７０に移行する。
一方、受信したヘッダＨが送信した定期ヘッダＨｃと一致していれば（Ｓ１３０：ＹＥＳ）、衝突ヘッダによるヘッダの書き換えが行われていないものとして、続けて、レスポンスＲの送信を許可するノード１０を指定するための指定情報ＩＤをＵＡＲＴ１１ａに送信させて（Ｓ１６０）、Ｓ１１０に戻る。
【００６７】
先のＳ１５０にて、イベントヘッダＨｅの送信タイミングであると判断した場合（Ｓ１５０：ＹＥＳ）、イベントヘッダＨｅをＵＡＲＴ１１ａに送信させる（Ｓ１６０）。
イベントヘッダＨｅの送信時（Ｓ１６０）、または衝突ヘッダによる定期ヘッダＨｃの書き換えが行われた時、即ち書換イベントヘッダＨｘの送信時（Ｓ１３０：ＮＯ）には、指定情報ＩＤの受信を待つ最大許容時間を計測するようにタイマをセットし（Ｓ１７０）、指定情報ＩＤを受信したか否かを判断する（Ｓ１８０）。
【００６８】
なお、指定情報ＩＤを受信したか否かの判断は、ＵＡＲＴ１１ａが復号回路１６を介して受信した、スタートビットとストップビットに挟まれた８ビットのデータが、指定情報ＩＤを表すものであるか否かによって判断する。
【００６９】
そして、指定情報ＩＤを受信したと判断した場合（Ｓ１８０：ＹＥＳ）は、そのままＳ１１０に戻り、指定情報ＩＤを受信していないと判断した場合（Ｓ１８０：ＮＯ）は、先の１７０にてセットしたタイマがタイムアウトしたか否かを判断する（Ｓ１９０）。
【００７０】
タイマがタイムアウトしていなければ（Ｓ１９０：ＮＯ）、Ｓ１８０に戻って、引き続き指定情報ＩＤの受信を待ち、タイマがタイムアウトしていれば（Ｓ１９０：ＹＥＳ）、どのノード１０からもイベント通信の要求がなかったものとして、Ｓ１１０に戻る。
【００７１】
＜スレーブタスク＞
次に、全てのノード１０のマイコン１１が実行するスレーブタスクの内容を、図６に示すフローチャートに沿って説明する。
【００７２】
なお、スレーブタスクは、ノード１０に電源が投入され、初期化処理等が実行されることによって、バスＢＳの使用が可能となると起動する。
スレーブタスクでは、まず、イベント通信の要求が発生している否かを判断する（Ｓ２１０）。イベント通信の要求は、上述したように、スレーブタスクとは別途実行される処理により設定される。
【００７３】
イベント通信の要求が発生している場合は、衝突ヘッダ生成回路１８に対する衝突ヘッダの送信要求ＲＱをセットし（Ｓ２２０）、その後、ＵＡＲＴ１１ａにてヘッダＨを受信したか否かを判断する（Ｓ２３０）。
【００７４】
ヘッダＨを受信してなければ（Ｓ２３０：ＮＯ）受信するまで待機し、ヘッダＨを受信すると（Ｓ２３０：ＹＥＳ）、イベント通信を実現するための処理であるイベント処理を実行する（Ｓ２４０）。
【００７５】
なお、衝突ヘッダの送信要求ＲＱがセットされている状態で、マスタ１０ａからイベントヘッダＨｅが送信されると、衝突ヘッダ生成回路１８から衝突ヘッダが送信されないため、各ノード１０ではイベントヘッダＨｅがそのまま受信されることになり、マスタ１０ａから定期ヘッダＨｃが送信されると、衝突ヘッダ生成回路１８から衝突ヘッダが送信されるため、書換イベントヘッダＨｘが受信されることになる。このとき、送信要求ＲＱは、衝突ヘッダの送信の有無に関わらずリセットされる（図３参照）。
【００７６】
その後、イベント処理によってイベント通信の要求がクリアされたか否かを判断し（Ｓ２５０）、クリアされていなければ（Ｓ２５０：ＮＯ）、Ｓ２２０に戻ってイベント通信を再度試みる。
【００７７】
一方、イベント通信の要求がクリアされていれば（Ｓ２５０：ＹＥＳ）Ｓ２１０に戻る。
先のＳ２１０にて、イベント通信の要求が発生していないと判断した場合（Ｓ２１０：ＮＯ）は、ＵＡＲＴ１１ａにてヘッダＨを受信したか否かを判断し（Ｓ２６０）、ヘッダＨを受信していなければ（Ｓ２６０：ＮＯ）Ｓ２１０に戻る。
【００７８】
一方、ヘッダＨを受信していれば（Ｓ２６０：ＹＥＳ）、ヘッダＨに応じてレスポンスＲを返送する等の処理を行うヘッダ応答処理を実行して（Ｓ２７０）、Ｓ２１０に戻る。
なお、衝突ヘッダの送信要求ＲＱがリセットされている場合、受信するヘッダＨは、定期ヘッダＨｃ，イベントヘッダＨｅ，他のノード１０によって書き換えられた書換イベントヘッダＨｘのいずれかとなる。
【００７９】
＜ヘッダ応答処理＞
次に、先のＳ２７０で実行するヘッダ応答処理の詳細を、図７に示すフローチャートに沿って説明する。
【００８０】
本処理が起動すると、まず、指定情報ＩＤの受信を待つ最大許容時間を計測するようにタイマをセットし（Ｓ３１０）、指定情報ＩＤを受信したか否かを判断する（Ｓ３２０）。
【００８１】
指定情報ＩＤを受信していない場合（Ｓ３２０：ＮＯ）、先のＳ３１０にてセットしたタイマがタイムアウトしたか否かを判断する（Ｓ３６０）。
タイマがタイムアウトしていなければ（Ｓ３６０：ＮＯ）、Ｓ３２０に戻って、引き続き指定情報ＩＤの受信を待ち、タイマがタイムアウトしていれば（Ｓ３６０：ＹＥＳ）、何等かのエラーが発生したものとして、予め用意されているエラー処理を実行して（Ｓ３７０）本処理を終了する。
【００８２】
指定情報ＩＤを受信した場合（Ｓ３２０：ＹＥＳ）、受信した指定情報ＩＤから自ノード１０への要求であるか否かを判断し（Ｓ３３０）、自ノード１０への要求であれば（Ｓ３３０：ＹＥＳ）、別途実行される処理によって用意された指定情報ＩＤに対応するデータを、レスポンスＲとして送信するレスポンス送信処理を実行して（Ｓ３４０）本処理を終了する。なお、レスポンス送信処理は、送信するデータの長さに応じた数（回数）だけ、ＵＡＲＴ１１ａにブロックデータを繰り返し送信させることによって実現する。
【００８３】
一方、受信した指定情報ＩＤが自ノード１０への要求でなければ（Ｓ３３０：ＮＯ）、他ノード１０が送信するレスポンスＲを受信するレスポンス受信処理を実行して（Ｓ３５０）本処理を終了する。なお、レスポンス受信処理では、受信したレスポンスＲに示されているデータの長さに応じた数だけブロックデータの受信を繰り返すことで実現する。
【００８４】
但し、ブロックデータを受信する毎に、受信を待つ最大許容時間を計測するようにタイマをセットし、最大許容時間内にブロックデータの受信があった場合には、同じレスポンスＲを構成する連続したデータとして処理する。また、タイマがタイムアウトした時に、レスポンスＲを構成する全てのデータの受信を完了していなければ、それまでに受信したデータを破棄してエラー処理を実行する。
【００８５】
＜イベント処理＞
次に、先のＳ２４０で実行するイベント処理の詳細を、図８に示すフローチャートに沿って説明する。
【００８６】
本処理では、まず、受信したヘッダＨがイベントヘッダＨｅまたは書換イベントヘッダＨｘのいずれかであるか否かを判断し（Ｓ４１０）、いずれでもなければ（Ｓ４１０：ＮＯ）、何等かのエラーが発生したものとして、予め用意されているエラー処理を実行して（Ｓ４９０）本処理を終了する。
【００８７】
一方、受信したヘッダＨがイベントヘッダＨｅまたは書換イベントヘッダＨｘのいずれかであれば（Ｓ４１０：ＹＥＳ）、発生したイベント通信の要求に対応した指定情報ＩＤを、ＵＡＲＴ１１ａに送信させ（Ｓ４２０）、バスを経由した指定情報ＩＤがＵＡＲＴ１１ａにて受信されるまで待機する（Ｓ４３０：ＮＯ）。
【００８８】
ＵＡＲＴ１１ａが指定情報ＩＤを受信すると（Ｓ４３０：ＹＥＳ）、受信した指定情報ＩＤと送信した指定情報ＩＤをと比較することによって、バス調停に負けているか否かを判断し（Ｓ４４０）、両指定情報ＩＤが一致しており調停負けしていない（Ｓ４４０：ＮＯ）と判断した場合は、自ノード１０が要求したイベント通信が受け付けられたものとして、イベント通信要求をクリアする（Ｓ４５０）。
【００８９】
そして、受信した指定情報ＩＤが、自ノード１０への要求であるか否かを判断し（Ｓ４６０）、自ノード１０への要求であれば（Ｓ４６０：ＹＥＳ）、別途実行される処理によって用意された指定情報ＩＤに対応するデータを、レスポンスＲとして送信するレスポンス送信処理を実行して（Ｓ４７０）本処理を終了し、一方、受信した指定情報ＩＤが自ノード１０への要求でなければ（Ｓ４６０：ＮＯ）、他ノード１０が送信するレスポンスＲを受信するレスポンス受信処理を実行して（Ｓ４８０）本処理を終了する。
【００９０】
なお、Ｓ４７０のレスポンス送信処理およびＳ４８０のレスポンス受信処理は、先のＳ３４０およびＳ３５０にて説明したものと同様の処理である。
＜動作＞
図９は、通信システム１の基本動作を表すタイミング図である。
【００９１】
図９に示すように、マスタ１０ａのマスタタスクは、予め設定されたスケジュールに従って、定期ヘッダＨｃまたはイベントヘッダＨｅのいずれかを、予め設定された１スロット毎に送信する。図では、定期ヘッダＨｃとイベントヘッダＨｅを交互に送信する場合を示す。そして、定期ヘッダＨｃを送信する時には続けて指定情報ＩＤも送信する。指定情報ＩＤの値は、予め設定されたスケジュールに従って、ノード１０間で共有する必要のある全てのデータが順次選択されるように設定される。
【００９２】
各ノード１０のスレーブタスクは、定期ヘッダＨｃに続く指定情報ＩＤが自ノード１０を指定するものである場合、用意されているレスポンスＲを、受信した指定情報ＩＤに続けて送信する。このレスポンスＲは、全てのノード１０で受信され、必要に応じて使用される（図中、１番目および５番目のスロット参照）。
【００９３】
マスタ１０ａのマスタタスクによって、イベントヘッダＨｅが送信された場合、イベント通信要求が発生しているノード１０（図ではスレーブノード＿２）のスレーブタスクは、イベントヘッダＨｅに続けて、そのイベント通信要求に応じた指定情報ＩＤを送信する。
【００９４】
各ノード１０のスレーブタスクは、その指定情報ＩＤが自ノード１０を指定するものである場合に、用意されているレスポンスＲを、受信した指定情報ＩＤに続けて送信する（図中、２番目のスロット参照）。
【００９５】
ここでは、指定情報ＩＤが、指定情報ＩＤを送信した自ノードを指定するものであった場合を示している。なお、イベント通信においては、必ずしも自ノード１０を指定した指定情報ＩＤを送信する必要はなく、他ノード１０を指定した指定情報ＩＤを送信してもよい。
【００９６】
イベント通信要求が発生している時に、定期ヘッダＨｃを受信したノード１０（図ではスレーブノード＿３）のスレーブタスクは、衝突ヘッダを送信することで、定期ヘッダＨｃを書換イベントヘッダＨｘに書き換える。この時、定期ヘッダＨｃの書き換えを検出したマスタ１０ａの調停回路１７は、直ちにヘッダＨの送信を中止する。その後、各ノード１０は、通常のイベントヘッダＨｅを受信した時と同様の動作を実行する（図中、３番目のスロット参照）。
【００９７】
また、マスタ１０ａのマスタタスクによってイベントヘッダＨｅが送信された時に、いずれのノード１０でもイベント通信要求が発生していなかった場合、マスタタスクは、指定情報ＩＤの受信を待つ最大許容時間だけ待った後、次のヘッダＨを送信することになる（図中、４番目のスロット参照）。
【００９８】
図１０は、複数のノード１０で同時にイベント通信要求が発生した場合の動作を表すタイミング図である。なお、図中、１番目のスロットと２番目のスロットは、図９の場合と同様の動作である。
【００９９】
複数のノード１０（図では、スレーブノード＿１，スレーブノード＿３）で同時にイベント通信要求が発生している状態で、マスタ１０ａのマスタタスクによって定期ヘッダＨｃが送信されると、イベント通信要求が発生しているノード１０である要求ノードは、それぞれが衝突ヘッダを送信して、定期ヘッダＨｃを書換イベントヘッダＨｘに書き換え、これに続けて、それぞれが指定情報ＩＤを送信する。これによりバスＢＳ上では指定情報ＩＤの衝突が発生するが、バス調停が行われ、これに勝ち残った指定情報ＩＤ（図ではスレーブノード＿１）に従って、イベント通信が実行される（図中の３番目のスロット参照）。
【０１００】
バス調停に負けた指定情報ＩＤの送信元となった要求ノード（図ではスレーブノード＿３）は、イベント通信要求がクリアされないため、次のスロットで再びイベント通信を試みる。ここでは、マスタタスクがイベントヘッダＨｅを送信するため、前のスロットでバス調停に負けた要求ノードは、このイベントヘッダＨｅに続けて指定情報ＩＤを送信することになる（図中、４番目のスロット参照）。
【０１０１】
＜効果＞
以上説明したように、通信システム１における各ノード１０は、マスタ１０ａから送信されるヘッダＨによって、定期通信の実行タイミングかイベント通信の実行タイミングかを識別しており、定期通信とイベント通信との切替のためにノード１０間で特別なフレームをやり取りする必要がないため、ノード１０にてイベント通信の要求が発生した場合に、定期通信での順番を待つことなく、イベントの発生を速やかに他のノード１０に通知することができる。
【０１０２】
しかも、通信システム１では、定期通信の実行タイミングでイベント通信の要求が発生している時には、衝突ヘッダを送信することで定期ヘッダＨｃを書換イベントヘッダＨｘに書き換えて、イベント通信を実行するため、イベント通信を優先的に実行することができる。
【０１０３】
更に、通信システム１によれば、複数のノード１０にてイベント通信の要求が発生し、イベント通信のタイミングで、複数のノード同時に１０から同時に指定情報ＩＤが送信された時には、バス調停に勝ち残った指定情報ＩＤに従って通信が実行され、指定情報ＩＤの衝突が生じたスロットでも通信が有効に行われるため、効率よく通信を行うことができる。
【０１０４】
＜発明との対応＞
本実施形態において、定期ヘッダＨｃが第１の識別情報、イベントヘッダＨｅが第２の識別情報、指定情報ＩＤが指定情報に相当し、Ｓ２７０が応答送信手段、衝突ヘッダ生成回路１８およびＳ２２０〜Ｓ２４０（Ｓ２４０では、特にＳ４１０〜Ｓ４２０）が能動通信要求手段に相当する。
【０１０５】
＜変形例＞
上記実施形態では、衝突ヘッダによって書き換えられる定期ヘッダＨｃの後半部分が４ビットに設定されているが、４ビットに限るものではなく、１ビット以上７ビット以下であればよい。
【０１０６】
上記実施形態では、定期通信およびイベント通信のいずれの場合も、ヘッダＨの後に指定情報ＩＤを送信するように構成されているが、定期ヘッダＨｃに指定情報ＩＤとしての機能を持たせ、マスタノードは、定期通信の時には、指定情報ＩＤの送信を省略するように構成してもよい。
【０１０７】
この場合、０ｘ００をイベントヘッダＨｅ、後半部分４ビットが０となる０ｘ１０，０ｘ２０，…０ｘＥ０，０ｘＦ０を書換イベントヘッダＨｘとして、これら以外の値を指定情報ＩＤとして用いると共に、ヘッダＨに指定情報ＩＤで許容される値が設定されている場合には、これを定期ヘッダＨｃとして扱うように構成すればよい。
【０１０８】
図１１は、この変形例の場合の基本動作を表すタイミング図である。図示されているように、マスタタスクが定期ヘッダＨｃを送信する場合、指定情報ＩＤの送信が省略される以外は、図９に示したものと同様のタイミングで動作する。
【０１０９】
つまり、この変形例では、定期通信で指定情報ＩＤの送信が省略される分だけ、バスＢＳの通信効率をより向上させることができる。
［第２実施形態］
次に、第２実施形態について説明する。
【０１１０】
＜全体構成＞
図１２は、本実施形態の通信システム２の全体構成を示す説明図である。
図１２に示すように、本実施形態の通信システム２は、第１実施形態の通信システム１と同様に、バスＢＳを介して接続された複数のノード２０からなり、その一つがマスタノード（マスタ）２０ａ、それ以外がスレーブノード（スレーブ）２０ｂとして構成されている。そして、ノード２０は、ノード１０と同様に、マイコン２１とトランシーバ２２とを備えている。
【０１１１】
このうち、トランシーバ２２は、符号化回路２３，送信バッファ２４，受信バッファ２５，復号回路２６，調停回路２７を備えている。なお、これらは、トランシーバ１２の符号化回路１３，送信バッファ１４，受信バッファ１５，復号回路１６，調停回路１７と同様のものであるため、その構成や動作についての説明は省略する。
【０１１２】
また、ノード２０は、衝突ヘッダ生成回路１８の代わりにＩＦＳ検出回路２８を備えている。
そして、受信データＲｘＤの信号レベル（即ち、バスＢＳ上の信号レベル）が予め設定された許容ビット（例えば、１０ビット）以上継続する期間をＩＦＳ（Inter Frame Space ）と呼び、ＩＦＳ検出回路２８は、ＩＦＳを検出するとマイコン２１に対してＩＦＳ検出信号ＩＤＬを出力するように構成されている。
【０１１３】
＜マスタタスク＞
マスタ２０ａのマイコン２１が実行する処理であるマスタタスクでは、マスタ１０ａのマイコン２１が実行するマスタタスク（図５）とは、一部の処理が異なるだけであり、具体的には、Ｓ１５０，Ｓ１６０が省略されている。
【０１１４】
つまり、マスタタスクでは、予め設定されたタイミング毎に、定期ヘッダＨｃ（０ｘＦＦ）だけを送信し、バスＢＳを介して受信したヘッダＨが、送信した定期ヘッダＨｃと一致している場合には、そのまま定期通信を行い、一致していない場合には、定期ヘッダＨｃが書き換えられたものとして、イベント通信の実行を許可する。
【０１１５】
但し、ヘッダＨの送信は、ＩＦＳが検出されている時には、送信タイミングに従って直ちに行い、ＩＦＳが検出されていない時には、ＩＦＳの検出を待って行う。
＜スレーブタスク＞
次に、ノード２０のマイコン２１が実行する処理であるスレーブタスクを、図１３に示すフローチャートに沿って説明する。
【０１１６】
なお、マイコン２１が実行するスレーブタスクは、マイコン１１が実行するスレーブタスク（図６参照）とは、一部の処理が異なるだけであり、具体的には、イベント通信要求がセットされると（Ｓ２１０：ＹＥＳ）、衝突ヘッダ送信要求ＲＱをセットする（Ｓ２２０）代わりに、衝突ヘッダを送信する（Ｓ２２５）点が異なっている。但し、衝突ヘッダの送信は、ＩＦＳが検出されている時には、直ちに行い、ＩＦＳが検出されていない時には、ＩＦＳの検出を待って行う。
【０１１７】
なお、衝突ヘッダは、ノード１０の場合とは異なり、ヘッダＨや指定情報ＩＤ等と同様に、ＵＡＲＴ２１ａを介して送信される。具体的には、図１４に示すように、８ビットのデータが０ｘ００（ビットパターン「００００００００」）を、スタートビットおよびストップビットで挟んだブロックデータからなる。
【０１１８】
そして、衝突ヘッダは、指定情報ＩＤやレスポンスＲの送受信が行われていない期間の任意のタイミングで送信される。このため、衝突ヘッダと衝突した定期ヘッダＨｃは、衝突した部分以降のビットが、ストップビットも含めて全て「０」（ドミナント）に書き換えられることになり、その書き換えられることによって生じる可能性のある全てのビットパターン（「１０００００００」「１１００００００」「１１１０００００」「１１１１００００」「１１１１１０００」「１１１１１１００」「１１１１１１１０」）が、書換イベントヘッダＨｘとなる。また、衝突ヘッダが定期ヘッダＨｃと衝突しなかった場合は、衝突ヘッダそのもの（「００００００００」）が書換イベントヘッダＨｘとなる。
【０１１９】
なお、定期ヘッダＨｃのスタートビットから１０ビット分の期間が経過すると、調停回路２７が送信バッファ２４への送信データＴｘＤの供給を停止するように構成されているため、定期ヘッダＨｃに衝突した衝突ヘッダのうち、定期ヘッダＨｃのスタートビットから１０ビット（ブロックデータ送信許容期間）を越える部分が、バスＢＳに送出されることはない。
【０１２０】
但し、上述したように衝突ヘッダによって、定期ヘッダＨｃ（ひいては書換イベントヘッダＨｘ）のストップビットも「０」に書き換えられてしまうため、ヘッダＨの受信時には、ストップビットを検出できなくてもエラーとならないように構成しておく必要がある。
【０１２１】
＜効果＞
このように構成された通信システム２によれば、イベント通信は、その必要が生じた場合にだけ、衝突ヘッダを送信することによって実行され、イベント通信用の期間を確保するために、マスタ２０ａから定期的にイベントヘッダＨｅを送信する必要がないため、バスＢＳの通信効率をより向上させることができる。
【０１２２】
［他の実施形態］
以上本発明の実施形態について説明したが、本発明は上記実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において様々な態様にて実施することが可能である。
【０１２３】
例えば、上記実施形態では、本発明を車載用の通信システムに適用したが、車載用に限るものではなく、定期通信とイベント通信とをいずれも実現する必要がある通信システムでありさえすれば適用することができる。
【０１２４】
上記実施形態では、符号化回路１３，２３や復号回路１６，２６を用いて、バスＢＳ上ではＰＷＭ符号に符号化されたデータを伝送しているが、これら符号化回路１３，２３や復号回路１６，２６を省略して、ＮＲＺ符号のデータを伝送するように構成してもよい。
【符号の説明】
【０１２５】
１，２…通信システム  １０，２０…ノード  １０ａ，２０ａ…マスタノード  １０ｂ，２０ｂ…スレーブノード  １１，２１…マイクロコンピュータ（マイコン）  １２，２２…トランシーバ  １３，２３…符号化回路  １４，２４…送信バッファ  １５，２５…受信バッファ  １６，２６…復号回路  １７，２７…調停回路  １８…衝突ヘッダ生成回路  ２８…ＩＦＳ検出回路
【図１】
0005510286.tif 000002
【図２】
0005510286.tif 000003
【図３】
0005510286.tif 000004
【図４】
0005510286.tif 000005
【図５】
0005510286.tif 000006
【図６】
0005510286.tif 000007
【図７】
0005510286.tif 000008
【図８】
0005510286.tif 000009
【図９】
0005510286.tif 000010
【図１０】
0005510286.tif 000011
【図１１】
0005510286.tif 000012
【図１２】
0005510286.tif 000013
【図１３】
0005510286.tif 000014
【図１４】
0005510286.tif 000015
【図１５】
0005510286.tif 000016