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