(57)【特許請求の範囲】
【請求項１】
複数のスレーブ通信装置（３）とバス（５）を介して通信可能に接続されるマスタ通信装置（２）であって、
当該マスタ通信装置によってデータを送信すべき装置が指定された指令を表す送信指令に応じてデータを送信し、かつ当該マスタ通信装置からの送信指令が無い場合であっても予め設定された送信条件が成立したときにデータを送信する通信装置をスレーブ通信装置として、前記複数のスレーブ通信装置のうちいずれのスレーブ通信装置に異常が生じたかを特定可能な特定情報を取得する特定情報取得手段（Ｓ１１０、Ｓ１１５）と、
前記特定情報に基づいて、異常が生じたスレーブ通信装置を表す異常装置が送信元となるデータを破棄させるための破棄情報を、少なくとも該異常装置以外のスレーブ通信装置に送信する破棄情報送信手段（Ｓ１５０、Ｓ１６０）と、
を備え、
前記特定情報取得手段（Ｓ１１０）は、前記スレーブ通信装置がウェイクアップパルスを送信した否かを示す情報であるウェイクアップパルス送信情報を前記特定情報として取得する
ことを特徴とするマスタ通信装置
【請求項２】
複数のスレーブ通信装置（３）とバス（５）を介して通信可能に接続されるマスタ通信装置（２）であって、
当該マスタ通信装置によってデータを送信すべき装置が指定された指令を表す送信指令に応じてデータを送信し、かつ当該マスタ通信装置からの送信指令が無い場合であっても予め設定された送信条件が成立したときにデータを送信する通信装置をスレーブ通信装置として、前記複数のスレーブ通信装置のうちいずれのスレーブ通信装置に異常が生じたかを特定可能な特定情報を取得する特定情報取得手段（Ｓ１１０、Ｓ１１５）と、
前記特定情報に基づいて、異常が生じたスレーブ通信装置を表す異常装置が送信元となるデータを破棄させるための破棄情報を、少なくとも該異常装置以外のスレーブ通信装置に送信する破棄情報送信手段（Ｓ１５０、Ｓ１６０）と、
を備え、
前記特定情報取得手段（Ｓ１１５）は、前記スレーブ通信装置のスリープが許可されているか禁止されているかを示す情報であるスリープ可否情報を前記特定情報として取得する
ことを特徴とするマスタ通信装置
【請求項３】
請求項１または請求項２に記載のマスタ通信装置であって、
前記破棄情報送信手段（Ｓ１５０）は、前記破棄情報に、前記特定情報にて特定された異常装置を識別するための識別情報を含めて送信する
ことを特徴とするマスタ通信装置。
【請求項４】
請求項１または請求項２に記載のマスタ通信装置であって、
前記破棄情報送信手段（Ｓ１６０）は、当該マスタ通信装置から前記送信指令が送信されないスレーブ通信装置を前記異常装置であると認識する機能を有するスレーブ通信装置に対して、前記破棄情報として、前記異常装置以外のスレーブ通信装置のみに対して、データを送信させるための送信指令を送信する
ことを備えることを特徴とするマスタ通信装置。
【請求項５】
マスタ通信装置および複数のスレーブ通信装置を含む通信システムであって、前記マスタ通信装置がデータを送信すべき装置が指定された送信指令を送信して前記スレーブ通信装置が前記送信指令に応じてデータを送信し、かつ前記スレーブ通信装置は前記マスタ通信装置からの前記送信指令が無い場合であっても予め設定された送信条件が成立したときにデータを送信し、前記マスタ通信装置が前記複数のスレーブ通信装置のうちの異常が生じたスレーブ通信装置を表す異常装置に前記送信指令を送信しない通信システム、において用いられる前記スレーブ通信装置であって、
前記異常装置が送信元となるデータを破棄するための破棄情報を前記マスタ通信装置から受信する破棄情報受信手段であって、前記マスタ通信装置が前記異常装置以外の前記スレーブ通信装置に送信した前記送信指令を前記破棄情報として受信する破棄情報受信手段（Ｓ４００、Ｓ４０５）と、
前記破棄情報に基づいて、予め定められた期間である判定期間内に、前記マスタ通信装置が前記送信指令を送信しなかったスレーブ通信装置を前記異常装置として特定する異常装置特定手段（Ｓ４１５）と、
前記破棄情報に基づいて、前記異常装置特定手段によって前記異常装置として特定された前記スレーブ通信装置が送信元となるデータを破棄するよう設定するデータ破棄手段（Ｓ４２０）と、
を備えることを特徴とするスレーブ通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マスタ通信装置からの指令に応じてスレーブ通信装置がデータを出力する方式であるマスタ・スレーブ方式の通信技術に関する。
【背景技術】
【０００２】
従来、マスタ・スレーブ方式で通信を行うマスタ通信装置及びスレーブ通信装置において、マスタ通信装置が、異常が生じたスレーブ通信装置から出力されるデータを少なくとも他のスレーブ通信装置に受信させないようにする技術が知られている。
【０００３】
特許文献１には、マスタ通信装置からの指令に応じたスレーブ通信装置によるデータの送信が無い場合に、送信が無いスレーブ通信装置に異常が生じたとして、マスタ通信装置から該スレーブ通信装置に対する指令の送信を中止する技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−３１２０４３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、特許文献１に記載の技術では、スレーブ通信装置は、マスタ通信装置から送信された指令に応じてデータを送信するものであった。このようなスレーブ通信装置に対して、近年では、マスタ通信装置からの指令が送信されない場合であってもスレーブ通信装置から能動的にデータを送信させたいという、ユーザからの要求が有る。
【０００６】
そこで、マスタ通信装置から指令が送信されない場合であっても、例えばスレーブ通信装置において所定のイベントが発生したとき等に、該スレーブ通信装置から能動的にデータを送信可能な新たなマスタ・スレーブ方式の通信技術が考えられている。
【０００７】
しかしながら、スレーブ通信装置から能動的にデータを送信可能なマスタ・スレーブ方式の通信技術では、仮にスレーブ通信装置に異常が生じたとすると、異常が生じたスレーブ通信装置から出力されたデータが他のスレーブ通信装置に受信されて、例えば該データに基づく誤った制御等が行われるおそれがあった。
【０００８】
本発明は、マスタ・スレーブ通信方式で通信を行うマスタ通信装置及びスレーブ通信装置において、異常が生じたスレーブ通信装置から送信されたデータが他のスレーブ通信装置に利用されることを抑制する技術を提供することを目的としている。
【課題を解決するための手段】
【０００９】
本発明の一側面は、マスタ通信装置であって、該マスタ通信装置は、複数のスレーブ通信装置とバスを介して通信可能に接続される。マスタ通信装置は、特定情報取得手段と破棄情報送信手段とを備える。特定情報取得手段は、当該マスタ通信装置によってデータを送信すべき装置が指定された指令を表す送信指令に応じてデータを送信し、かつ当該マスタ通信装置からの送信指令が無い場合であっても予め設定された送信条件が成立したときにデータを送信する通信装置をスレーブ通信装置として、複数のスレーブ通信装置のうちいずれのスレーブ通信装置に異常が生じたかを特定可能な特定情報を取得する。破棄情報送信手段は、特定情報に基づいて、異常が生じたスレーブ通信装置を表す異常装置が送信元となるデータを破棄させるための破棄情報を、少なくとも該異常装置以外のスレーブ通信装置に送信する。
【００１０】
このような構成のマスタ通信装置によれば、正常なスレーブ通信装置に、異常なスレーブ通信装置を送信元とするデータを破棄させるため、該データが他のスレーブ通信装置に利用されることを抑制することができる。この結果、該データに基づいて正常なスレーブ通信装置に対する誤った制御等が行われることを抑制することができる。
【００１１】
また、本発明の別の側面はスレーブ通信装置であって、該スレーブ通信装置は、マスタ通信装置および１または複数の他のスレーブ通信装置を通信相手として含み、マスタ通信装置によってデータを送信すべき装置が指定された指令を表す送信指令に応じてデータを送信し、かつマスタ通信装置からの送信指令が無い場合であっても予め設定された送信条件が成立したときにデータを送信する。スレーブ通信装置は、破棄情報受信手段とデータ破棄手段とを備える。破棄情報受信手段は、他のスレーブ通信装置のうちの異常が生じたスレーブ通信装置を表す異常装置が送信元となるデータを破棄するための破棄情報をマスタ通信装置から受信する。データ破棄手段は、破棄情報に基づいて、異常装置が送信元となるデータを破棄するよう設定する。
【００１２】
このような構成のスレーブ通信装置によれば、破棄情報に基づいて異常なスレーブ通信装置を送信元とするデータを破棄するため、正常なスレーブ通信装置において該データに基づく誤った制御等が行われることを抑制することができる。
【００１３】
なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。
【図面の簡単な説明】
【００１４】
【図１】通信システム、マスタ通信装置、及びスレーブ通信装置の構成を示すブロック図。
【図２】マスタとスレーブとの通信に使用される通信フレームの構成の一例を示す図。
【図３】スレーブに異常が発生していない場合のスケジュールテーブルの一例を示す図。
【図４】（ａ）はマスタの対応管理テーブルの一例を示す図であり、（ｂ）はスレーブ３ａの対応管理テーブルの一例を示す図。
【図５】マスタ及びスレーブの動作の一例を示す図。
【図６】第１実施形態のマスタ定期処理のフローチャート。
【図７】過剰ウェイクアップ検出処理のフローチャート。
【図８】スリープ禁止継続検出処理のフローチャート。
【図９】第１実施形態のスレーブ定期処理のフローチャート。
【図１０】異常ノードに異常フラグがセットされる様子を示す図。
【図１１】第２実施形態のマスタ定期処理のフローチャート。
【図１２】新たなスケジュールテーブルの一例を示す図。
【図１３】第２実施形態のスレーブ定期処理のフローチャート。
【図１４】フレーム途絶検出処理のフローチャート。
【発明を実施するための形態】
【００１５】
以下、本発明が適用された実施形態について、図面を用いて説明する。
［１．第１実施形態］
［１−１．構成］
［１−１−１．全体構成］
図１に示す通信システム１は、車両に搭載されたシステムであって、通信装置（ノード）としてのマスタノード（以下、単にマスタという）２と、３つのスレーブノード（以下、単にスレーブという）３とを備える。これらの各ノードは、バス５を介して互いに通信可能に接続される。スレーブノードは、本実施形態では３つであるが、複数であればいくつでもよい。以下において、３つのスレーブ３を区別して説明する場合は、それぞれについて、３ａ、３ｂ、３ｃを符号として用いる。
【００１６】
はじめに、マスタ２の構成について説明する。マスタ２は、トランシーバ２３と制御部２１とを備える。
トランシーバ２３は、回路から構成され、バス５を介したデータの送受信を行う、周知の通信用のモジュールである。つまり、トランシーバ２３は、制御部２１から供給されたデータをバス５上に出力し、バス５上から入力されたデータを制御部２１へ供給する。
【００１７】
制御部２１は、ＣＰＵ２１１、ＲＯＭ２１２、ＲＡＭ２１３等を有する周知のマイクロコンピュータを備える。
ＣＰＵ２１１は、ＲＯＭ２１２やＲＡＭ２１３に記録されたプログラムを実行することにより、例えば、ボディ系やエンジン系の制御などのように、車両を制御するための各種機能を実現する処理を行う。
【００１８】
具体的には、制御部２１は、スレーブ３との通信に基づいて車両を制御するための各種機能を実現する。
ここで、マスタ２とスレーブ３との通信に使用される通信フレームについて、図２を用いて説明する。以下、通信フレームを単にフレームという。フレームは、ヘッダとレスポンスとにより構成される。
【００１９】
ヘッダは、基本的に、マスタ２から、後述するスケジュールテーブルに従って送信される。
ただし、後述するイベントが発生したときは、該イベントに対応するスレーブ３からも送信される。
【００２０】
ヘッダは、フレームごとに固有の８ビットで表される識別番号であり、レスポンスを送信させるべきノードを指定している番号である。つまり、ヘッダに基づいて、レスポンスの送信が許可されたノード（以下応答ノードという）を特定可能である。なお、本実施形態では、ヘッダは、スレーブ３と自マスタ２とを応答ノードとして指定可能となっている。
【００２１】
レスポンスは、基本的に、スケジュールテーブルに従ってマスタ２から送信されたヘッダによって特定されたスレーブ３又はマスタ２から送信される。ただし、レスポンスは、イベントが発生したときは、該イベントに対応するスレーブ３が送信したヘッダによって特定されたスレーブ３から送信されてもよい。該イベントに対応するスレーブ３は、自スレーブ３（該イベントに対応するスレーブ３）を応答ノードとして指定してもよいし、他のスレーブ３を応答ノードとして指定してもよい。なお、本実施形態では、イベントが発生したときに、自スレーブ３を応答ノードとして指定する例について説明する。
【００２２】
以下では、スケジュールテーブルに従ってマスタ２が送信したヘッダ及び該ヘッダに対応するレスポンスからなるフレームを定期フレームという。また、イベントが発生したときに該イベントに対応するスレーブ３が送信したヘッダ及びレスポンスからなるフレームを、イベントフレームという。
【００２３】
レスポンスはフレーム情報部とデータ部とからなる。フレーム情報部は、１ビットのウェイクアップパルス送信情報と、１ビットのスリープ可否情報とを少なくとも含む。
ウェイクアップパルス送信情報は、ウェイクアップパルスを送信したか否かを示す情報である。ウェイクアップパルス送信情報は、該ウェイクアップパルス送信情報を含むレスポンスを送信したノードがウェイクアップパルスを送信した場合に１に設定され、送信していない場合に０に設定される。以下、ウェイクアップパルス送信情報を、ＷＵＰ送信情報という。
【００２４】
スリープ可否情報は、スリープ状態に遷移可能か否かを示す情報である。スリープ可否情報は、該スリープ可否情報を含むレスポンスを送信したノードが、スリープを許可されている場合に１に設定され、許可されていない場合に０に設定される。
【００２５】
データ部は、ヘッダごとに予め指定されている種類のデータを含む。
図１に戻り、説明を続ける。制御部２１（ＣＰＵ２１１）は、例えば、定期送信処理、定期受信処理、マスタ定期処理を実行する。
【００２６】
定期送信処理は、送信指令を、予め設定されたスケジュールであるスケジュールテーブルに従って定期的に送信する処理である。送信指令とは、データを送信させるべきスレーブ３装置に対して該スレーブ３を指定する指令であり、前述のヘッダに相当する。また、ここでいうデータは、前述のレスポンスに相当する。つまり、定期送信処理は、ヘッダをスケジュールテーブルに従って定期的に送信する処理である。
【００２７】
図３に一例として示すように、スケジュールテーブルＳＴ0には、ヘッダの送信順を示す送信順情報と、ヘッダを含むフレームの名称を示すフレーム名情報と、ヘッダに対応する応答ノードを示す応答ノード情報と、ヘッダの送信間隔を示す要求送信間隔情報との対応関係が設定されている。なお、ヘッダの送信間隔とは、ヘッダが送信されてから次のヘッダを送信するまでの送信間隔をいう。
【００２８】
スケジュールテーブルＳＴ0は、まずマスタ２を応答ノードとするヘッダ（１番目）を送信するように設定されている。そして、スケジュールテーブルＳＴ0は、１番目のヘッダが送信されてから１０００ｍｓが経過した後に、スレーブ３ａを応答ノードとするヘッダ（２番目）を送信するように設定されている。
【００２９】
スケジュールテーブルＳＴ0は、さらに２番目のヘッダが送信されてから２０００ｍｓが経過した後にスレーブ３ａを応答ノードとするヘッダ（３番目）を送信し、３番目のヘッダが送信されてから１０００ｍｓが経過した後にマスタ２を応答ノードとするヘッダ（４番目）を送信するように設定されている。
【００３０】
スケジュールテーブルＳＴ0は、同様に５００ｍｓが経過した後にスレーブ３ｂを応答ノードとするヘッダ（５番目）を送信し、同様に５００ｍｓが経過した後にスレーブ３ｃを応答ノードとするヘッダ（６番目）を送信するように設定されている。
【００３１】
スケジュールテーブルＳＴ0は、さらに６番目のヘッダが送信されてから１０００ｍｓが経過した後に、マスタ２を応答ノードとするヘッダ（１番目）を送信するように設定されている。
【００３２】
定期受信処理は、スケジュールテーブルＳＴ0に従って定期的に送信したヘッダに対応するレスポンスを受信する処理である。制御部２１は、受信したレスポンスに基づいて、レスポンスのデータ部に含まれるデータを用いて、車両を制御するための各種機能を実現する処理を行う。
【００３３】
マスタ定期処理は、スレーブ３に異常が生じた場合に、異常が生じたスレーブ３を応答ノードとするイベントフレームが他の正常なノードに利用されないようにするための処理である。マスタ定期処理の詳細については、後述する。
【００３４】
図１に戻り説明を続ける。ＲＯＭ２１２は、前述の処理を実行するためのプログラムの他、スケジュールテーブルＳＴ0、ノード識別番号、対応管理テーブルＫＴ0（図４（ａ）参照）、等を記録している。
【００３５】
ノード識別番号は、マスタ２、及びスレーブ３毎に付与された、それぞれを識別可能な識別番号である。
対応管理テーブルＫＴ0は、スレーブ３との通信で用いる全ての定期フレーム及びイベントフレームについてのヘッダと応答ノードとの関係を示すテーブルである。
【００３６】
図４（ａ）に一例として示すように、対応管理テーブルＫＴ0には、ヘッダと、ヘッダを含むフレームの名称を示すフレーム名情報と、ヘッダに対応する応答ノードを示す応答ノード情報と、定期フレームであるかイベントフレームであるかの種別を示す種別情報との対応関係が設定されている。
【００３７】
具体的には、対応管理テーブルＫＴ0は、０ｘ０１というヘッダを、フレーム名称がＡ１であり、応答ノードがマスタ２であり、定期フレームである、と設定している。
また、対応管理テーブルＫＴ0は、０ｘ０５というヘッダを、フレーム名称がＣ１であり、応答ノードがスレーブ３ｂであり、定期フレームであると設定し、０ｘ０６というヘッダを、フレーム名称がＣ２であり、応答ノードがスレーブ３ｂであり、イベントフレームであると設定している。
【００３８】
つまり、対応管理テーブルＫＴ0は、スレーブ３ｂ及びスレーブ３ｃのみがイベントフレームを送信可能であると設定している。なお、以下では、フレーム名称がＡ１のフレームを単にフレームＡ１のように記載する。
【００３９】
次に、図１に戻り、スレーブ３の構成について説明する。
スレーブ３は、トランシーバ３３と制御部３１とスイッチ７とを備える。
トランシーバ３３は、マスタ２が備えるトランシーバ２３と同様の通信用のモジュールであり、制御部３１から供給されたデータをバス５上に出力し、バス５から入力されたデータを制御部３１へ供給する。
【００４０】
スイッチ７は、制御部３１に接続されており、例えば、ドアロックの解錠や施錠、電動シートの移動等のような予め設定されたイベントが発生したときに、制御部３１にイベント信号を出力する。
【００４１】
制御部３１は、ＣＰＵ３１１、ＲＯＭ３１２、ＲＡＭ３１３等を有する周知のマイクロコンピュータを備える。ＣＰＵ３１１は、ＲＯＭ３１２やＲＡＭ３１３に記録されたプログラムを実行することにより、予め割り当てられた各種機能を実現する処理を行う。
【００４２】
例えば、マスタ２がボディ系の制御を行う場合、スレーブ３は、ドアの施錠及び解錠、パワーウィンドウの制御のようなドアのまわりに関する制御や、エアコンに関する制御、電動シートに関する制御等のような予め割り当てられた各種機能を実現する処理を行う。
【００４３】
具体的には、制御部３１は、マスタ２および１または複数の他のスレーブ３を通信相手として含み、これらの通信相手との通信に基づいて、各種機能を実現する。
制御部３１は、例えば、レスポンス送信処理、フレーム受信処理、イベントフレーム送信処理、スレーブ定期処理を実行する。
【００４４】
レスポンス送信処理は、自ノードであるスレーブ３を応答ノードとして指定するヘッダに応じてレスポンスを送信する処理である。
フレーム受信処理は、自ノードを受信ノードとするヘッダを受信した場合に、ヘッダ続いて送信されたレスポンスを取り込み、取り込んだフレーム（レスポンス）を利用して、各種機能を実現する処理である。受信ノードとは、ヘッダと該ヘッダ続いて送信されたレスポンスとを取り込むノードのことをいう。
【００４５】
なお、受信したヘッダが自ノードを受信ノードとするか否かは、後述する対応管理テーブルに基づいて判断される。
イベントフレーム送信処理は、予め設定された送信条件が成立した場合に、イベントフレームを送信する処理である。予め設定された送信条件が成立したときとは、スイッチ７からイベント信号が出力されたとき、つまり、予め設定されたイベントが発生したときをいう。
【００４６】
このようなイベントの発生に応じてスレーブ３が送信するイベントフレームは、該イベントに関連する他のスレーブ３を受信ノードとするフレームであり、データ部に該他のスレーブ３を制御するための制御データを含む。
【００４７】
スレーブ定期処理は、他のスレーブ３に異常が生じた場合に、異常が生じた他のスレーブ３から送信されるイベントフレームを、正常な自ノードにて利用しないようにするための処理である。スレーブ定期処理の詳細については、後述する。
【００４８】
ＲＯＭ３１２は、前述の処理を実行するためのプログラムの他、ＲＯＭ２１２と同様に、ノード識別番号、対応管理テーブルＫＴ1（図４（ｂ）参照）、等を記録している。
ただし、スレーブ３の対応管理テーブルＫＴ1は、マスタ２の対応管理テーブルＫＴ0とは異なり、自ノードが送受信する定期フレーム及びイベントフレームのみが示されるテーブルである。
【００４９】
図４（ｂ）に一例として示すように、スレーブ３ａの対応管理テーブルＫＴ1では、自ノードであるスレーブ３ａを応答ノードとして指定するヘッダは、０ｘ０３及び０ｘ０４のみである。つまり、スレーブ３ａについては、対応管理テーブルＫＴ1に基づいて、０ｘ０３及び０ｘ０４以外のヘッダが自ノード（スレーブ３ａ）を受信ノードとするヘッダであると判断される。
【００５０】
［１−１−２．動作状態］
次に、マスタ２及びスレーブ３の動作状態について説明する。
マスタ２において、制御部２１は、マスタ２としての動作状態をウェイクアップ状態とスリープ状態との間で変更する処理を行う。なお、スレーブ３において、制御部３１も、制御部２１と同様に、スレーブ３としての動作状態をウェイクアップ状態とスリープ状態との間で変更する処理を行う。このため、以下では、マスタ２についての動作状態について説明する。ただし、説明において、括弧内には、スレーブ３における対応する構成を記載する。
【００５１】
ウェイクアップ状態は、マスタ２（スレーブ３）に予め割り当てられた全ての機能を実行可能な通常の動作状態であり、スリープ状態は、消費電力を抑えるために、マスタ２（スレーブ３）に予め割り当てられた機能のうちの一部の機能を停止した動作状態である。
【００５２】
具体的には、制御部２１（制御部３１）は、スリープ状態であるとき、自ノードであるマスタ２（スレーブ３）に予め定められたウェイクアップ要因が発生した場合に、ウェイクアップし、バス５にウェイクアップパルスを送信する。ウェイクアップとは、動作状態をスリープ状態からウェイクアップ状態に設定することをいう。ウェイクアップパルスとは、これを受信した全てのノードをウェイクアップさせることが可能な信号をいう。つまり、制御部２１（制御部３１）は、バス５を介して他のノードからウェイクアップパルスを受信した場合にも、ウェイクアップすることが可能である。
【００５３】
［１−１−３．マスタ及びスレーブの作動例］
次に、マスタ２及びスレーブ３の作動の一例を説明する。なお、ここでは、正常時の作動の一例を説明する。正常時とは、スレーブ３に異常の生じていないときをいう。
【００５４】
マスタ２は、スケジュールテーブルＳＴ0に従って順番にヘッダを送信する（定期送信処理）。
スレーブ３は、マスタ２送信されたヘッダが自ノードを応答ノートとして指定するものである場合に、レスポンスを送信する（レスポンス送信処理）。
【００５５】
つまり、図５に示すように、バス５には、スケジュールテーブルＳＴ0に従い、フレームＡ１、Ｂ１、ｂ２、Ａ２、Ｃ１、Ｄ１が、順に、繰り返し出力される。
ただし、スレーブ３ｃまたはスレーブ３ｂに予め設定されたイベントが発生したときは、イベントが発生したスレーブ３ｃまたはスレーブ３ｂがイベントフレームを送信する。
【００５６】
［１−１−４．異常ノードの検出］
ところで、仮に、イベントフレームを送信したスレーブ３に何らかの異常が生じていた場合は、このイベントフレームに異常が生じているおそれがある。仮に、イベントフレームに異常が生じていたとすると、異常が生じているイベントフレームを取り込んだ他の正常なスレーブ３が、該イベントフレームを利用して誤った制御を行ってしまう等の問題が生じるおそれがある。
【００５７】
そこで、通信システム１では、マスタ２、及びスレーブ３は、いずれかのスレーブ３に異常が生じた場合に、異常が生じたスレーブ３から送信されるイベントフレームが正常なスレーブ３にて利用されないようにするために、それぞれ、マスタ定期処理、スレーブ定期処理を実行する。以下では、異常が生じたスレーブ３を異常ノードという。
【００５８】
［１−２．処理］
［１−２−１．マスタ定期処理］
マスタ２（制御部２１）が実行するマスタ定期処理について、図６のフローチャートを用いて説明する。マスタ定期処理は、マスタ２の電源がオンされている間（例えばＡＣＣスイッチがオンされている間）、所定の周期で繰り返し実行される。マスタ定期処理は、定期送信処理を実行するとともに、異常が生じたスレーブ３を特定し、異常が生じたスレーブ３から送信されるイベントフレームを他の正常なスレーブ３にて利用されないようにする処理である。
【００５９】
なお、以下の説明文において主語が省略されている場合、制御部２１（ＣＰＵ２１１）を主語とする。
はじめに、Ｓ（ステップ）１１０では、過剰ウェイクアップ検出処理を実行する。過剰ウェイクアップ検出処理は、スレーブ３が送信したレスポンスに含まれるＷＵＰ送信情報に基づいて、異常ノードを特定する処理である。
【００６０】
次にＳ１１５では、スリープ禁止継続検出処理を実行する。スリープ禁止継続検出処理は、スレーブ３が送信したレスポンスに含まれるスリープ可否情報に基づいて、異常ノードを特定する処理である。
【００６１】
続くＳ１２０では、異常ノードが発生したか否かを判断する。具体的には、過剰ウェイクアップ検出処理またはスリープ禁止継続検出処理において異常ノードを特定した場合に、異常ノードが発生したと判断する。異常ノードが発生しなかった場合は処理をＳ１２５へ移行させ、異常ノードが発生した場合は処理をＳ１４５へ移行させる。
【００６２】
Ｓ１２５では、スリープ条件が成立しているか否かを判断する。ここでは、一例として、スケジュールテーブルＳＴ0に示されている１周分の全てのフレームにおけるスリープ可否情報がスリープ許可を示している場合に、スリープ条件が成立していると判断する。スリープ条件が成立していない場合は処理をＳ１３０へ移行させ、スリープ条件が成立している場合は処理をＳ１３５へ移行させる。
【００６３】
Ｓ１２５にてスリープ条件が成立していないと判断された場合に移行するＳ１３０では、スケジュールテーブルＳＴ0に従ってヘッダを送信する定期送信処理を実行する。そして、本マスタ定期処理を終了する。
【００６４】
Ｓ１２５にてスリープ条件が成立していると判断された場合に移行するＳ１３５では、スリープフレームを送信する。スリープフレームは、バス５に接続されている全てのスレーブ３をスリープ状態に遷移させるためにマスタ２（制御部２１）が送信するフレームである。
【００６５】
続くＳ１４０では、マスタ２の動作状態をウェイクアップ状態からスリープ状態に遷移させる。そして、本マスタ定期処理を終了する。
Ｓ１２０にて異常ノードが発生したと判断されて移行するＳ１４５では、異常ノードを応答ノードとするフレーム及び異常ノードのイベントフレームを破棄する設定を行う。具体的には、対応管理テーブルＫＴ0に基づいて、異常ノードを応答ノードとするヘッダ及び異常ノードのイベントフレームのヘッダを特定し、特定したヘッダをＲＡＭ２１３に記録する。
【００６６】
これにより、制御部２１は、ＲＡＭ２１３に記録されているヘッダに基づいて、異常ノードを応答ノードとするフレーム及び異常ノードのイベントフレームを廃棄することが可能となる。
【００６７】
続くＳ１５０では、バス５にエラー通知フレームを送信し、本マスタ定期処理を終了する。エラー通知フレームは、前述の図４に示す対応管理テーブルには記載されていないが、全てのスレーブ３を受信ノードとするフレームである。エラー通知フレームは、データ部に、異常ノードのノード識別番号を含む。この異常ノードのノード識別番号は、特許請求の範囲における識別情報に相当する。
【００６８】
つまり、本マスタ定期処理では、異常ノードが発生しておらず、且つスリープ条件が成立していない場合に、定期送信処理を実行する（Ｓ１３０）。また、異常ノードが発生しておらず、且つスリープ条件が成立している場合に、マスタ２及びスレーブ３をスリープ状態に遷移させる（Ｓ１３５、Ｓ１４０）。そして、異常ノードが発生している場合に、エラー通知フレームを出力する（Ｓ１５０）。
【００６９】
次に、マスタ定期処理のＳ１１０で実行される過剰ウェイクアップ検出処理について、図７のフローチャートを用いて説明する。
過剰ウェイクアップ検出処理は、スレーブ３から送信されたレスポンスに含まれるＷＵＰ送信情報に基づいて、予め定められた期間である監視期間内に予め定められたウェイクアップ閾値以上の回数、ウェイクアップパルスを送信したスレーブ３を異常ノードとして特定する処理である。
【００７０】
過剰ウェイクアップ検出処理では、マスタ２と通信可能に接続されている全てのスレーブ３ａ、３ｂ、３ｃごとに、図７のフローチャートに示す処理が実行される。つまり、図７のフローチャートにおける「スレーブｘ」の記載は、スレーブ３ａ、３ｂ、３ｃのそれぞれに置換される。以下では、「スレーブｘ」がスレーブ３ａである場合について説明する。
【００７１】
Ｓ２１０では、マスタ２の電源がオンされてから予め定められた時間である監視時間が経過したか否かを判断する。図示していないが、制御部２１は、マスタ２の電源がオンされてからの経過時間を測定する処理を本過剰ウェイクアップ検出処理とは別処理として実行しており、本ステップでは該経過時間を取得する。そして、該経過時間が監視時間以上である場合に、監視時間が経過したと判断する。
【００７２】
監視時間は、一例として数時間程度に設定される。ただし、監視時間は、通信システム１に応じて任意に設定されてよい。
監視時間が経過したと判断した場合は処理をＳ２１５へ移行させ、経過していないと判断した場合は処理をＳ２２０へ移行させる。
【００７３】
Ｓ２１０にて監視時間が経過したと判断された場合に移行するＳ２１５では、全てのスレーブ３ａ〜３ｃのウェイクアップ回数を初期化する。すなわち、ウェイクアップ回数の値として０を代入する。
【００７４】
Ｓ２１０にて監視時間が経過したと判断された場合に移行するＳ２２０では、ウェイクアップパルスを受信したか否かを判断する。
ウェイクアップパルスを受信しなかったと判断した場合は、本過剰ウェイクアップ検出処理を終了し、受信したと判断した場合は処理をＳ２２５へ移行させる。
【００７５】
Ｓ２２５では、スレーブ３ａのレスポンスを確認する。具体的にはレスポンスに含まれるＷＵＰ送信情報を取得する。
Ｓ２３０では、スレーブ３ａがウェイクアップパルスを送信したか否かを判断する。具体的には、ＷＵＰ送信情報の値が１である場合に、スレーブ３ａがウェイクアップパルスを送信したと判断する。スレーブ３ａがウェイクアップパルスを送信していない場合は本過剰ウェイクアップ検出処理を終了し、ウェイクアップパルスを送信した場合は処理をＳ２３５へ移行させる。
【００７６】
Ｓ２３５では、スレーブ３ａのウェイクアップ回数をカウントアップする、つまりウェイクアップ回数を１増加させる。
Ｓ２４０では、スレーブ３ａのウェイクアップ回数が予め定められた閾値であるウェイクアップ閾値以上であるか否かを判断する。スレーブ３ａのウェイクアップ回数がウェイクアップ閾値未満である場合は本過剰ウェイクアップ検出処理を終了し、ウェイクアップ閾値以上である場合は処理をＳ２４５へ移行させる。
【００７７】
ウェイクアップ閾値は、スレーブ３ａの異常を検出するために、スレーブ３ａが正常であるときのウェイクアップ回数を大きく越えた値に設定される。ウェイクアップ閾値は、通信システム１に応じて適当な値に設定されてよい。
【００７８】
Ｓ２４５では、スレーブ３ａを異常ノードとしてＲＡＭ２１３に記録する。そして、本過剰ウェイクアップ検出処理を終了する。
なお、制御部２１は、スレーブ３ｂ、スレーブ３ｃをスレーブｘとして、スレーブ３ｂ、スレーブ３ｃについても同様の処理を実行した後に、マスタ定期処理へ処理を復帰させる。
【００７９】
次に、マスタ定期処理のＳ１１５で実行されるスリープ禁止継続検出処理について、図８のフローチャートを用いて説明する。
スリープ禁止継続検出処理は、スレーブ３から送信されるレスポンスに含まれるスリープ可否情報に基づいて、予め定められた期間である継続期間以上スリープが禁止されているスレーブ３を異常ノードとして特定する処理である。
【００８０】
スリープ禁止継続検出処理は、過剰ウェイクアップ検出処理と同様に、マスタ２と通信可能に接続されている全てのスレーブ３ａ、３ｂ、３ｃに対して実行される処理である。つまり、図８のフローチャートにおける「スレーブｘ」の記載は、スレーブ３ａ、３ｂ、３ｃのそれぞれに置換される。以下では、「スレーブｘ」がスレーブ３ａである場合について説明する。
【００８１】
Ｓ３１０では、スレーブ３ａのレスポンスを確認する。具体的にはレスポンスに含まれるスリープ可否情報を取得する。
Ｓ３１５では、スレーブ３ａがスリープを許可されているか否かを判断する。具体的には、スリープ可否情報の値が１である場合に、スレーブ３ａがスリープを許可されていると判断する。スレーブ３ａがスリープを許可されている場合は処理をＳ３３５へ移行させ、許可されていない場合は処理をＳ３２０へ移行させる。
【００８２】
Ｓ３１５にてスレーブ３ａがスリープを許可されていない（スリープ禁止）と判断された場合に移行するＳ３２０では、スレーブ３ａのスリープ禁止タイマが停止中であるか否かを判断する。スリープ禁止タイマは、制御部２１が本スリープ禁止継続検出処理とは別処理として実行する処理であり、スレーブ３ａがスリープ禁止に設定されている継続時間であるスリープ禁止継続時間を測定する処理である。
【００８３】
スレーブ３ａのスリープ禁止タイマが停止中である場合は処理をＳ３３０へ移行させ、作動中である場合は処理をＳ３２５へ移行させる。
Ｓ３２０にてスレーブ３ａのスリープ禁止タイマが作動中であると判断されて移行するＳ３２５では、スレーブ３ａのスリープ禁止タイマの処理を継続させる。そして処理をＳ３４０へ移行させる。
【００８４】
Ｓ３２０にてスレーブ３ａのスリープ禁止タイマが停止中であると判断されて移行するＳ３３０では、スレーブ３ａのスリープ禁止タイマの処理を開始させる。そして処理をＳ３４０へ移行させる。
【００８５】
Ｓ３１５にてスレーブ３ａがスリープを許可されていると判断された場合に移行するＳ３３５では、スレーブ３ａのスリープ禁止タイマを停止させて、スリープ禁止タイマによる測定値であるスリープ禁止継続時間を初期化する、つまりスリープ禁止継続時間を０にする。そして、処理をＳ３４０へ移行させる。
【００８６】
Ｓ３４０では、スレーブ３ａのスリープ禁止継続時間が予め定められた閾値である継続閾値以上であるか否かを判断する。スレーブ３ａのスリープ禁止継続時間が継続閾値未満である場合は本スリープ禁止継続検出処理を終了し、継続閾値以上である場合は処理をＳ３４５へ移行させる。
【００８７】
継続閾値は、スレーブ３ａの異常を検出するために、スレーブ３ａが正常であるときのスリープ禁止継続時間を大きく越えた値に設定される。継続閾値は、通信システム１に応じて適当な値に設定されてよい。
【００８８】
Ｓ３４５では、スレーブ３ａを異常ノードとしてＲＡＭ２１３に記録する。
なお、制御部２１は、スレーブ３ｂ、スレーブ３ｃをスレーブｘとして、スレーブ３ｂ、スレーブ３ｃについても同様の処理を実行した後に、マスタ定期処理へ処理を復帰させる。
【００８９】
［１−２−２．スレーブ定期処理］
次に、スレーブ３（制御部３１）が実行する処理であるスレーブ定期処理について、図９のフローチャートを用いて説明する。スレーブ定期処理は、スレーブ３の電源がオンされている間（例えばＡＣＣスイッチがオンされている間）、所定の周期で繰り返し実行される。スレーブ定期処理は、フレーム受信処理を実行するとともに、異常ノードを送信元とするイベントフレーム破棄するための処理である。以下では、スレーブ３ａを例として説明する。
【００９０】
なお、以下の説明文において主語が省略されている場合、制御部３１（ＣＰＵ３１１）を主語とする。
Ｓ４００では、破棄情報としてのエラー通知フレームを受信したか否かを判断する。破棄情報とは、マスタ２から送信される情報であって、自ノードであるスレーブ３ａ以外の、他のスレーブ３（スレーブ３ｂ、３ｃ）のうちの異常が生じたスレーブ３である異常ノードが送信元となるデータを破棄するための情報をいう。エラー通知フレームを受信した場合に処理をＳ４２０へ移行させ、受信していない場合に処理をＳ４３０へ移行させる。
【００９１】
Ｓ４００にて破棄情報であるエラー通知フレームを受信した場合に移行するＳ４２０では、エラー通知フレームに基づいて、異常ノードを応答ノードとするデータであるイベントフレームを破棄する設定を行う。
【００９２】
具体的には、エラー通知フレームに含まれるノード識別番号に基づいて、異常ノードであるスレーブ３を特定する。そして、例えば、スレーブ３ｂが異常ノードとして特定された場合であれば、一例として図１０に示すように、スレーブ３ｂについての異常フラグをセットする。異常フラグは、セットされている場合に異常ノードであることを示すフラグである。
【００９３】
そして、対応管理テーブルＫＴ1に基づいて、異常ノードを応答ノードとするヘッダを特定し、特定したヘッダをＲＡＭ３１３に記録する。
Ｓ４００にてエラー通知フレームを受信していない場合に移行するＳ４３０では、受信したフレームが破棄対象であるか否かを判断する。具体的には、受信したフレームのヘッダが、現サイクルより前のＳ４２０にて異常ノードを応答ノードとするヘッダであるとしてＲＡＭ３１３に記録されている場合に、破棄対象であると判断する。受信したフレームが破棄対象である場合に処理をＳ４３５へ移行させ、破棄対象でない場合に処理をＳ４４０へ移行させる。
【００９４】
受信したフレームが破棄対象である場合に移行するＳ４３５では、受信したフレームを破棄し、本スレーブ定期処理を終了する。
受信したフレームが破棄対象でない場合に移行するＳ４４０では、受信フレームがスリープフレームであるか否かを判断する。スリープフレームでない場合は処理をＳ４５０へ移行させ、スリープフレームである場合は処理をＳ４６０へ移行させる。
【００９５】
Ｓ４４０にてスリープフレームでないと判断された場合に移行するＳ４５０では、フレーム受信処理を実行し、本スレーブ定期タスクを終了する。
Ｓ４４０にてスリープフレームであると判断された場合に移行するＳ４６０では、自ノードをスリープ状態に遷移させ、本スレーブ定期タスクを終了する。
【００９６】
次に、このように構成されたマスタ２及びスレーブ３の作動の一例を説明する。マスタ２及びスレーブ３は、スレーブ３のうちいずれのスレーブ３に異常が生じたかを特定可能な情報である特定情報、すなわちスリープ可否情報、ＷＵＰ送信情報に基づいて、例えば次のように作動する。
【００９７】
スレーブ３ｂにおいてスリープを許可しない状態が継続閾値以上継続した場合、マスタ２は、バス５にスレーブ３ｂを異常ノードとして特定したエラー通知フレームを送信する。これにより、このエラー通知フレームが送信された以降は、マスタ２及びスレーブ３ａ、スレーブ３ｃでは、異常ノードであるスレーブ３ｂが送信するイベントフレームは廃棄され、該イベントフレームは受信されない（図４参照）。
【００９８】
また、例えば、スレーブ３ｂにおいてウェイクアップパルスが送信された回数であるウェイクアップ回数がウェイクアップ閾値以上である場合、マスタ２及びスレーブ３ａ、３ｃでは、同様に、異常ノードであるスレーブ３ｂが送信するイベントフレームは廃棄され、該イベントフレームは受信されない。
【００９９】
このように構成されたマスタ２及びスレーブ３は、次のように作動する。
マスタ２は、正常時よりも頻繁にウェイクアップパルスを送信しているスレーブ３、又は、正常時よりも長期間にわたって自ノードのスリープを許可しない期間を継続しているスレーブ３を、異常ノードとして特定する。一例として示す図５では、スレーブ３ｂが正常時よりも長期間にわたって自ノードのスリープを許可しない期間を継続している例を示している。図５の場合、マスタ２は、スレーブ３ｂを異常ノードとして特定する。
【０１００】
マスタ２は、異常ノード（図５ではスレーブ３ｂ）以外の他の正常なスレーブ３に、異常ノードから送信されるイベントフレームを破棄させるように、エラー通知フレームを送信する。エラー通知フレームは、異常ノードを応答ノードとするフレームを、正常なスレーブ３に破棄させるためのフレームであるといえる。
【０１０１】
正常なスレーブ３であるスレーブ３（図５ではスレーブ３ａ、３ｃ）は、エラー通知フレームの送信というマスタ２の作動に応じて、異常ノードであるスレーブ３ｂを応答ノードとするイベントフレームを破棄する。
【０１０２】
［１−３．効果］
以上詳述した第１実施形態によれば、以下の効果が得られる。
［１Ａ］マスタ２（制御部２１）は、少なくとも正常なスレーブ３に、異常ノードを応答ノードとするイベントフレームを破棄させる。これによれば、異常ノードを応答ノードとするイベントフレームが他の正常なスレーブ３に利用されることを抑制できる。この結果、異常ノードを応答ノードとするイベントフレームに基づいて他の正常なスレーブ３に対する誤った制御等が行われることを抑制することができる。
【０１０３】
［１Ｂ］マスタ２（制御部２１）は、具体的には、異常ノードを特定可能な情報であるノード識別番号を含むエラー通知フレームを送信する。これによれば、スレーブ３側で異常ノードを特定する手段を備える必要が無いため、スレーブ３（制御部３１）を簡易に構成できる。
【０１０４】
［１Ｃ］マスタ２（制御部２１）は、ＷＵＰ送信情報を、特定情報として用いる。これによれば、頻繁にウェイクアップパルスを送信することにより通信システム１の省電力化を妨げる状態にあるスレーブ３を、異常ノードとして特定することができる。
【０１０５】
［１Ｄ］マスタ２（制御部２１）は、スリープ可否情報を、特定情報として用いる。これによれば、スリープが許可されない期間の継続により通信システム１の省電力化を妨げる状態にあるスレーブ３を、異常ノードとして特定することができる。
【０１０６】
［１Ｅ］スレーブ３（制御部３１）は異常ノードを送信元（応答ノード）とするイベントフレームを破棄する。これによれば、正常なスレーブ３において、異常ノードを送信元とするイベントフレームに基づく誤った制御等が行われることを抑制することができる。
【０１０７】
［１Ｆ］スレーブ３は、異常ノードを特定可能な情報であるノード識別番号を含むエラー通知フレームに基づいて、異常ノードから送信されるイベントフレームを破棄する。これによれば、異常ノードの特定を簡易に行うことができるため、スレーブ３（制御部３１）を簡易に構成できる。
【０１０８】
なお、第１実施形態では、マスタ２がマスタ通信装置の一例に相当し、スレーブ３がスレーブ通信装置の一例に相当する。また、制御部２１が特定情報取得手段、破棄情報送信手段、としての一例に相当し、Ｓ１１０、Ｓ１１５が特定情報取得手段としての処理の一例に相当し、Ｓ１５０が破棄情報送信手段としての処理の一例に相当する。
【０１０９】
また、制御部３１が破棄情報受信手段、データ破棄手段としての一例に相当し、Ｓ４００が破棄情報受信手段としての処理の一例に相当し、Ｓ４２０がデータ破棄手段としての処理の一例に相当する。また、ＵＷＰ送信情報及びスリープ可否情報が特定情報としての一例に相当し、異常通知フレームが破棄情報の一例に相当する。
【０１１０】
［２．第２実施形態］
［２−１．第１実施形態との相違点］
第２実施形態は、基本的な構成は第１実施形態と同様であるため、共通する構成については説明を省略し、相違点を中心に説明する。
【０１１１】
前述した第１実施形態では、マスタ２は、エラー通知フレームを、正常なスレーブ３に異常が生じたスレーブ３が応答ノード（送信元）となるイベントフレームを破棄させるための情報である破棄情報として送信した。
【０１１２】
これに対し、第２実施形態では、マスタ２からヘッダが送信されないスレーブ３を異常ノードであると認識する機能を有するスレーブ３に対して、破棄情報として、異常ノード以外のスレーブ３のみに対してレスポンスを送信させるためのヘッダを送信する点で、第１実施形態と相違する。
【０１１３】
なお、この相違点によって、本実施形態のマスタ２が実行するマスタ定期処理（図１１）では、図６に示すフローチャートに対してＳ１５０がＳ１６０に置換される点が相違する。また、本実施形態のスレーブ３が実行するスレーブ定期処理（図１３）では、図９に示すフローチャートに対してＳ４０５、Ｓ４１５、Ｓ４２５が追加され、Ｓ４００がＳ４１０に置換される点が相違する。
【０１１４】
［２−２．処理］
［２−２−１．マスタが実行する処理］
本実施形態において、マスタ２（制御部２１）が実行するマスタ定期処理について、図１１のフローチャートを用いて説明する。
【０１１５】
制御部２１はＳ１６０以外は第１実施形態と同様の処理を実行するため、異常ノードが発生した場合（Ｓ１２０；ＹＥＳ）、異常ノードからのフレームの破棄を設定した（Ｓ１４５）後に移行する、Ｓ１６０についてのみ説明する。
【０１１６】
Ｓ１６０では、スケジュール切替処理を実行する。スケジュール切替処理とは、異常ノード以外のスレーブ３のみに対して、つまり、正常なスレーブ３に対してのみ、レスポンスを送信させるためのヘッダを送信する処理である。
【０１１７】
具体的には、スケジュール切替処理では、スケジュールテーブルＳＴ0から、異常ノードとして特定されたスレーブ３を応答ノードとするヘッダを削除した、新たなスケジュールテーブルを生成する。
【０１１８】
図１２に一例として、スレーブ３ｂが異常ノードとして特定された場合の、新たなスケジュールテーブルＳＴ1を示す。新たなスケジュールテーブルＳＴ1では、スケジュールテーブルＳＴ0からフレームＣ１が削除され、マスタ２を応答ノードとするヘッダ（４番目）を送信し、さらに５００ｍｓが経過した後にスレーブ３ｃを応答ノードとするヘッダ（５番目）を送信するように設定される。スケジュールテーブルＳＴ1は、さらに１０００ｍｓが経過した後に、マスタ２を応答ノードとするヘッダ（１番目）を送信するように設定される。
【０１１９】
つまり、本実施形態では、異常ノードが発生すると、異常ノードとして特定されたスレーブ３ｂを応答ノードとするヘッダを削除した、新たなスケジュールテーブルＳＴ1を生成する。これにより、新たなスケジュールテーブルＳＴ1が設定された以降は、定期送信処理（Ｓ１３０）において、異常ノードとして特定されたスレーブ３ｂを応答ノードとするヘッダが送信されないようになる。
【０１２０】
［２−２−２．スレーブが実行する処理］
次に、本実施形態において、スレーブ３（制御部３１）が実行するスレーブ定期処理について、図１３のフローチャートを用いて説明する。なお以下では、より具体的な例を説明する必要がある場合には、スレーブ３ａを例として説明する。
【０１２１】
Ｓ４０５では、フレーム途絶検出処理を実行する。フレーム途絶検出処理は、新たなスケジュールテーブルＳＴ1に基づいて異常ノードであるスレーブ３にレスポンスを要求するヘッダを送信しないよう設定されたマスタ２が、異常ノードであるスレーブ３以外のスレーブ３に送信したヘッダを破棄情報として受信し、該ヘッダに基づいて異常ノードを特定する処理である。
【０１２２】
つまり、フレーム途絶検出処理は、定期的に受信するはずのフレームの受信が途絶したことを検出する。フレーム途絶検出処理では、受信が途絶したフレームがある場合に通信途絶検出フラグをセットし、受信が途絶したフレームである通信途絶フレームを示す情報をＲＡＭ３１３に記録する。
【０１２３】
続くＳ４１０では、受信が途絶したフレームがあるか否かを判断する。具体的には、通信途絶検出フラグがセットされている場合に、受信が途絶したフレームがあると判断する。受信が途絶したフレームがある場合に処理をＳ４１５へ移行させ、無い場合に処理をＳ４３０へ移行させる。
【０１２４】
受信が途絶したフレームがある場合に移行するＳ４１５では、異常ノードを特定する。具体的には、例えばスレーブ３aは、受信が途絶したフレームのヘッダが０ｘ０５である場合は、対応管理テーブルＫＴ1に基づいて、スレーブ３ｂを異常ノードとして特定する。そして、スレーブ３ｂの異常フラグをセットする（図１０参照）。
【０１２５】
次にＳ４２０では、図９に示すＳ４２０と同様に、Ｓ４１５にて特定された異常ノードを応答ノードとするフレームを破棄する設定を行う。
続くＳ４２５では、通信途絶検出フラグをリセットし、本スレーブ定期処理を終了する。
【０１２６】
なお、受信が途絶したフレームがある場合に移行するＳ４３０以降は、図９と同様の処理を実行する。
次に、スレーブ定期処理のＳ４０５で実行されるフレーム途絶検出処理について、図１４のフローチャートを用いて説明する。フレーム途絶検出処理は、スレーブ３の対応管理テーブルに設定されている定期フレームのそれぞれについて、フレームの受信の途絶があったか否かを検出するための処理である。具体的には、例えばスレーブ３ａの場合、対応管理テーブルＫＴ1に基づいて、フレームＡ１、Ｂ１、Ｂ２、Ｃ１、Ｄ１のそれぞれについて、フレーム途絶検出処理を実行した後に、スレーブ定期処理へ処理を復帰させる。
【０１２７】
Ｓ５１０では、フレームを正常に受信したか否かを判断する。ヘッダ及びレスポンスの両方を正常に受信した場合に、フレームを正常に受信したと判断する。フレームを正常に受信した場合に処理をＳ５３０へ移行させ、正常に受信しなかった場合に処理をＳ５１５へ移行させる。
【０１２８】
Ｓ５１０にてフレームを正常に受信しなかったと判断された場合に移行するＳ５１５では、フレームの通信途絶タイマが停止中であるか否かを判断する。以下では、フレームＡ１をフレームの一例として説明する。
【０１２９】
フレームＡ１の通信途絶タイマが停止中である場合は処理をＳ５２５へ移行させ、作動中である場合は処理をＳ５２０へ移行させる。通信途絶タイマは、制御部３１が本フレーム途絶検出処理とは別処理として実行する処理であり、フレームＡ１が受信されてから次に受信されるまでの時間である通信途絶時間を測定する処理である。
【０１３０】
Ｓ５１５にてフレームＡ１の通信途絶タイマが作動中であると判断されて移行するＳ５２０では、フレームＡ１の通信途絶タイマの処理を継続させる。そして処理をＳ５３５へ移行させる。
【０１３１】
Ｓ５１５にてフレームＡ１の通信途絶タイマが停止中であると判断されて移行するＳ５２５では、通信途絶タイマの処理を開始させる。そして処理をＳ５３５へ移行させる。
Ｓ５１０にてフレームを正常受信したと判断されて移行するＳ５３０では、フレームＡ１の通信途絶タイマを停止させて、通信途絶時間を初期化する、つまり測定値を０にする。そして、処理をＳ５３５へ移行させる。
【０１３２】
Ｓ５３５では、フレームＡ１が受信が途絶したフレームであるか否かを判断する。具体的には、通信途絶時間が予め定められた判定期間である通信途絶閾値以上である場合に、フレームＡ１が、受信が途絶したフレームであると判断する。通信途絶閾値は、例えば、スケジュールテーブルＳＴ0を一巡する期間の十〜数十倍というように、フレームＡ１が受信される周期よりも十分長い時間に設定される。ただし、通信途絶閾値は、通信システム１に応じて任意の値に設定されてよい。
【０１３３】
受信が途絶したフレームであると判断された場合に処理をＳ５４０へ移行させ、受信が途絶したフレームであると判断されなかった場合に本フレーム途絶検出処理を終了する。
Ｓ５４０では、フレームＡ１を通信途絶フレームとしてＲＡＭ３１３に記録する。
【０１３４】
Ｓ５４５では、通信途絶検出フラグをセットする。そして、本フレーム途絶検出処理を終了する。
そして、このようにフレームＡ１についてのフレーム途絶検出処理を終了した後は、前述のように、フレームＢ１、Ｂ２、Ｃ１、Ｄ１のそれぞれについても同様にフレーム途絶検出処理を実行した後に、スレーブ定期処理へ処理を復帰させる。
【０１３５】
このように構成されたスレーブ３の作動について説明する。一例としてスレーブ３ａでは、通信途絶閾値で示される判定期間内にヘッダ０ｘ０５が受信されない場合、次のように作動する。
【０１３６】
つまり、スレーブ３aは、通信途絶閾値で示される判定期間内にヘッダ０ｘ０５が受信されない場合、すなわちフレームＣ１が受信されない場合、スレーブ３ｂを異常ノードとして特定する（Ｓ４１５）。そして、スレーブ３aは、スレーブ３ｂを異常ノードとして特定した以降は、異常ノードであるスレーブ３ｂが送信するイベントフレームを受信しないように、つまり廃棄するように作動する（Ｓ４３５）。
【０１３７】
［２−３．効果］
以上詳述した第２実施形態によれば、前述した第１実施形態の効果［１Ａ］、［１Ｃ］〜［１Ｅ］に加え、以下の効果が得られる。
【０１３８】
［２Ａ］スレーブ３は、マスタ２がヘッダを送信しないスレーブ３を異常ノードとして認識するよう構成されている。マスタ２は、スケジュールテーブルに基づいて、破棄情報として、異常ノード以外のスレーブ３のみに対してレスポンスを送信させるための送信指令であるヘッダを送信する（Ｓ１６０）。
【０１３９】
これによれば、第１実施形態におけるエラー通知フレームを用いること無く異常ノードの特定が可能になるため、エラー通知フレームに割り当てられていたヘッダを他の制御等に用いることができる。
【０１４０】
［２Ｂ］マスタ２は異常ノードにヘッダを送信しないように構成される。スレーブ３は、このように構成されたマスタ２から異常ノード以外のスレーブ３に送信されたヘッダを破棄情報として受信する（Ｓ４０５）。スレーブ３は、破棄情報としての前述のように送信されたヘッダに基づいて、通信途絶閾値で表される期間である判定期間以内にマスタ２からヘッダが送信されなかったスレーブ３を異常ノートとして特定する（Ｓ４１５）。そして、スレーブ３は、異常ノードとして特定されたスレーブ３が送信元となるイベントデータを破棄するよう設定する。
【０１４１】
これによれば、上記［２Ａ］と同様の効果が奏される。
なお、第２実施形態では、Ｓ１６０が破棄情報送信手段の処理としての一例に相当し、Ｓ４０５（Ｓ５１０）が破棄情報受信手段の処理としての一例に相当し、Ｓ４１５が異常装置特定手段としての一例に相当する。
【０１４２】
［３．他の実施形態］
以上、本発明の実施形態について説明したが、本発明は、上記実施形態に限定されることなく、種々の形態を採り得ることは言うまでもない。
【０１４３】
［３Ａ］上記実施形態では、スレーブ３は、イベントが発生したときにイベントフレームを送信する構成であった。具体的には、スレーブ３は、イベントが発生したときに、バス５が該バス５上へのフレームの出力が行われていないアイドル状態となった場合に、イベントフレームを送信するように構成されてもよい。または、スレーブ３は、マスタ２からイベントフレームの送信を許可する情報がバス５に出力されている場合に、イベントフレームを送信するように構成されてもよい。
【０１４４】
［３Ｂ］通信システム１にて用いられるフレーム構成を一例として図２に示したが、フレーム構成はこれに限るものではなく、通信システム１に応じて適宜設定されてよい。
［３Ｃ］通信システム１は、マスタ−スレーブ方式やＣＳＭＡ／ＣＡ方式やこれらを融合した方式であるＣＸＰＩ（Clock Extension Peripheral Interface）方式等に従って作動する通信システムであってよい。
【０１４５】
［３Ｄ］上記実施形態における１つの構成要素が有する機能を複数の構成要素として分散させたり、複数の構成要素が有する機能を１つの構成要素に統合させたりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加又は置換してもよい。なお、特許請求の範囲に記載した文言のみによって特定される技術思想に含まれるあらゆる態様が本発明の実施形態である。
【０１４６】
［３Ｅ］本発明は、前述した通信システム１、マスタ２、スレーブ３、制御部２１、制御部３１、当該制御部２１または制御部３１を機能させるためのプログラム、このプログラムを記録した媒体、通信方法など、種々の形態で実現することができる。
【符号の説明】
【０１４７】
１…通信システム  ２…マスタ  ３…スレーブ  ２１…制御部  ３１…制御部  ２１１…ＣＰＵ  ３１１…ＣＰＵ。
【図１】
0006569407.tif 000002
【図２】
0006569407.tif 000003
【図３】
0006569407.tif 000004
【図４】
0006569407.tif 000005
【図５】
0006569407.tif 000006
【図６】
0006569407.tif 000007
【図７】
0006569407.tif 000008
【図８】
0006569407.tif 000009
【図９】
0006569407.tif 000010
【図１０】
0006569407.tif 000011
【図１１】
0006569407.tif 000012
【図１２】
0006569407.tif 000013
【図１３】
0006569407.tif 000014
【図１４】
0006569407.tif 000015