JP2016082296A - 通信システム及びノード - Google Patents
通信システム及びノード Download PDFInfo
- Publication number
- JP2016082296A JP2016082296A JP2014208937A JP2014208937A JP2016082296A JP 2016082296 A JP2016082296 A JP 2016082296A JP 2014208937 A JP2014208937 A JP 2014208937A JP 2014208937 A JP2014208937 A JP 2014208937A JP 2016082296 A JP2016082296 A JP 2016082296A
- Authority
- JP
- Japan
- Prior art keywords
- mode
- frame
- transmission
- slave
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/462—LAN interconnection over a bridge based backbone
- H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40143—Bus networks involving priority mechanisms
- H04L12/40163—Bus networks involving priority mechanisms by assigning priority to messages according to a message field
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40267—Bus for use in transportation systems
- H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L2012/4629—LAN interconnection over a backbone network, e.g. Internet, Frame Relay using multilayer switching, e.g. layer 3 switching
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
Abstract
【課題】マスタノード(以下、マスタ)から定期的に送信される定期フレームよりも、スレーブノード(以下、スレーブ)からイベントの発生に伴って送信されるイベントフレームの方が、バス調停での優先度を高くしつつ、マスタによる定期フレームの送信が滞ってしまうことを防止する。
【解決手段】マスタは、送信を試みた定期フレームがイベントフレームに調停負けしたことに伴って送信待ちの定期フレームが溜まってしまった送信滞留状態になったことを検出すると(時刻t1)、スレーブへのモード切替フレームを送信すると共に、自身のモードを、「定期フレームを送信する合間に、スレーブに対して送信許可を通知するためのイベントヘッダを送信するモード」に切り替える。スレーブは、モード切替フレームを受信すると、自身の動作モードを、「イベントが発生し且つ上記イベントヘッダを受信した場合に、イベントフレームの送信を実施するモード」に切り替える。
【選択図】図5
【解決手段】マスタは、送信を試みた定期フレームがイベントフレームに調停負けしたことに伴って送信待ちの定期フレームが溜まってしまった送信滞留状態になったことを検出すると(時刻t1)、スレーブへのモード切替フレームを送信すると共に、自身のモードを、「定期フレームを送信する合間に、スレーブに対して送信許可を通知するためのイベントヘッダを送信するモード」に切り替える。スレーブは、モード切替フレームを受信すると、自身の動作モードを、「イベントが発生し且つ上記イベントヘッダを受信した場合に、イベントフレームの送信を実施するモード」に切り替える。
【選択図】図5
Description
本発明は、通信システム及びその通信システムを構成するノードに関する。
複数のノードがバスを介して接続される通信システムとして、各ノードが、バスに送信するフレームの先頭部分であるヘッダを用いたバス調停を実施すると共に、送信しようとして調停負けしたフレームの再送信を新規のフレームの送信よりも優先して実施する通信システムがある(例えば、特許文献1参照)。また、特許文献1には、マスタノードとスレーブノードとのうち、スレーブノードにも、自律的に送信する機能を持たせることが記載されている。自律的に送信する機能を持つノードは、バスのアイドル状態を確認した上で、フレームの送信を開始し、調停負けしなければ、そのまま送信を続ける。また、調停負けした場合には、送信を中止し、その後、バスのアイドル状態を確認してから、同じフレームの再送信を行うこととなる。
例えば、車両における通信システムにおいて、ドアミラーやパワーウィンドウ等の機器を制御する電子制御装置(以下、ECUという)を、マスタノードとし、上記機器を動かすためのスイッチの状態を検出する装置を、スレーブノードとしたとする。
その場合、スレーブノードは、例えば、スイッチの状態が変化した場合に、そのスイッチの状態を示すフレームを送信し、マスタノードは、スレーブノードから受信したフレームの内容に応じて機器を動作させることとなる。
そして、ユーザ(車両の使用者)の利便性の観点からは、スイッチの状態が変化した(換言すれば、スイッチが操作された)というイベントに対して、機器が素速く動作を開始することが重要となる。このため、スレーブノードからマスタノードへの通信の応答性が重視される。
また、マスタノードからは、他のノードへ、予め設定されたスケジュールに従って、定期的にフレームを送信したい、という要望もある。
その場合、スレーブノードからマスタノードへの通信の応答性を考慮すると、スレーブノードは、フレームを送信すべきイベントが発生した場合に自律的にフレームを送信することができるノードにすべきである。そして更に、マスタノードが定期的に送信するフレームよりも、スレーブノードが送信するフレームの方が、バス調停における優先度を高く設定することが考えられる。
その場合、スレーブノードからマスタノードへの通信の応答性を考慮すると、スレーブノードは、フレームを送信すべきイベントが発生した場合に自律的にフレームを送信することができるノードにすべきである。そして更に、マスタノードが定期的に送信するフレームよりも、スレーブノードが送信するフレームの方が、バス調停における優先度を高く設定することが考えられる。
しかし、スレーブノードからの自律的なフレームの送信と、マスタノードからの定期的なフレームの送信とが、同時に実施される可能性があり、その場合、マスタノードは、調停負けによってフレームを送信することができない。このため、スレーブノードにおいてイベントが多発して、スレーブノードの送信頻度が上がると、マスタノードがスケジュール通りにフレームを送信することができない、という状態が継続することになる。
そして、マスタノードにおいて、送信できないフレームが滞留すると、定期的なフレームの送信スケジュールが崩れてしまい、その定期的なフレームを受信する他のノードにおいて、不都合が生じることとなる。例えば、他のノードへ定期的に送信されていた制御データが送信されなくなることで、その制御データを用いるノードにおいて、制御処理を正しく実施することができなくなったり、他のノードにおける異常検出機能により、異常であると誤検出されてしまったりすることとなる。
そこで、本発明は、マスタノードから定期的に送信されるフレームよりも、スレーブノードからイベントの発生に伴って送信されるフレームの方が、バス調停での優先度を高くしつつ、マスタノードによる定期的なフレームの送信が滞ってしまうことを防止すること、を目的としている。
第1発明の通信システムでは、バスを介して接続された複数のノードが、バスに送信するフレームの先頭部分であるヘッダを用いたバス調停を実施すると共に、送信しようとして調停負けしたフレームの再送信を新規のフレームの送信よりも優先して実施する。
そして、複数のノードのうちの1つは、予め設定されたスケジュールに従って、定期的に送信すべきフレームである定期フレームの送信を実施するマスタノードである。また、複数のノードのうち、マスタノード以外のノードは、予め定められたイベントが発生した場合に、そのイベントに関連する情報を含むフレームであるイベントフレームの送信を実施するスレーブノードである。更に、バス調停における優先度は、定期フレームよりもイベントフレームの方が高く設定されている。
この通信システムにおいて、マスタノードの動作モードとしては、スケジュールに従って定期フレームの送信を実施する基本モードとしてのマスタ側第1モードと、定期フレームを送信する合間にスレーブノードに対する送信許可通知を送信するマスタ側第2モードと、がある。
そして、スレーブノードの動作モードとしては、イベントが発生した場合に自律的にイベントフレームの送信を実施する基本モードとしてのスレーブ側第1モードと、イベントが発生し且つマスタノードからの前記送信許可通知を受信した場合にイベントフレームの送信を実施するスレーブ側第2モードと、がある。
更に、マスタノードは、スレーブノードの動作モードがスレーブ側第1モードになっていると共に、当該マスタノードの動作モードがマスタ側第1モードになっている場合に動作する手段として、状態判定手段と、第2モード切替指令手段と、マスタ側第2モード切替手段と、を備える。状態判定手段は、送信を試みた定期フレームがイベントフレームに調停負けしたことに伴って、送信待ちの定期フレームが溜まってしまった送信滞留状態になったか否かを判定する。第2モード切替指令手段は、状態判定手段により肯定判定された場合(即ち、送信滞留状態になったと判定された場合)に、スレーブノードに対してスレーブ側第2モードへの切り替えを指令するための第2モード切替指令を送信する。マスタ側第2モード切替手段は、第2モード切替指令手段が第2モード切替指令を送信した場合に、当該マスタノードの動作モードを、マスタ側第1モードからマスタ側第2モードに切り替える。
そして、スレーブノードは、スレーブ側第2モード切替手段を備える。そのスレーブ側第2モード切替手段は、当該スレーブノードの動作モードがスレーブ側第1モードになっている場合に、当該スレーブノードがマスタノードからの第2モード切替指令を受信すると、当該スレーブノードの動作モードを、スレーブ側第1モードからスレーブ側第2モードに切り替える。
以下では、マスタノードがマスタ側第1モードで、スレーブノードがスレーブ側第1モードである場合の、通信システムのモードを、第1モードと言う。また、マスタノードがマスタ側第2モードで、スレーブノードがスレーブ側第2モードである場合の、通信システムのモードを、第2モードと言う。
通信システムが第1モードの場合には、スレーブノードからのイベントフレームの送信と、マスタノードからの定期フレームの送信とが、同時に実施されて、マスタノードが、調停負けにより定期フレームを送信することができない可能性がある。このため、スレーブノードにおいてイベントが多発して、スレーブノードの送信頻度が上がると、マスタノードがスケジュール通りに定期フレームを送信することができない、という状態が継続することになる。
そして、マスタノードにおいて、調停負けによって送信できない定期フレーム(即ち、送信待ちとなった定期フレーム)が溜まると、状態判定手段が、送信滞留状態になったと肯定判定する。
すると、マスタノードは、第2モード切替指令手段により、スレーブノードに対して第2モード切替指令を送信すると共に、マスタ側第2モード切替手段により、動作モードが、マスタ側第1モードからマスタ側第2モードに切り替わる。そして、スレーブノードは、マスタノードからの第2モード切替指令を受信することにより、動作モードが、スレーブ側第1モードからスレーブ側第2モードに切り替わる。よって、通信システムは、第2モードとなる。
通信システムが第2モードになると、マスタノードは、定期フレームを送信する合間にスレーブノードに対する送信許可通知を送信する。そして、スレーブノードは、その送信許可通知を受信することによって、イベントフレームの送信が許可されることとなる。よって、スレーブノードからのイベントフレームの送信及び送信頻度が、マスタノードによってコントロールされる。
そして、マスタノードは、スレーブノードからのイベントフレームの送信頻度を抑制した状態で、滞留していた送信待ちの定期フレームを送信することができる。このため、定期フレームをスケジュール通りに送信できる状態へと復帰することができる。また、スレーブノードからのイベントフレームの送信は、頻度が抑制されるだけであり、完全に禁止されるわけではないため、イベントフレームが送信されることによる機能も確保される。
以上のことから、本発明によれば、マスタノードからの定期フレームよりも、スレーブノードからのイベントフレームの方が、バス調停での優先度を高くしつつ、マスタノードによる定期フレームの送信が滞ってしまうことを防止することができる。
一方、第2発明のノードは、上記マスタノードとして使用可能なノードである。
このため、第2発明のノードの動作モードとしては、前述のマスタ側第1モードとマスタ側第2モードとがある。そして、第2発明のノードは、当該ノードの動作モードがマスタ側第1モードになっている場合に動作する手段として、前述の状態判定手段、第2モード切替指令手段及びマスタ側第2モード切替手段を備える。
このため、第2発明のノードの動作モードとしては、前述のマスタ側第1モードとマスタ側第2モードとがある。そして、第2発明のノードは、当該ノードの動作モードがマスタ側第1モードになっている場合に動作する手段として、前述の状態判定手段、第2モード切替指令手段及びマスタ側第2モード切替手段を備える。
また、第3発明のノードは、上記スレーブノードとして使用可能なノードである。
このため、第3発明のノードの動作モードとしては、前述のスレーブ側第1モードとスレーブ側第2モードとがある。そして、第3発明のノードは、前述のスレーブ側第2モード切替手段を備える。
このため、第3発明のノードの動作モードとしては、前述のスレーブ側第1モードとスレーブ側第2モードとがある。そして、第3発明のノードは、前述のスレーブ側第2モード切替手段を備える。
なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。
以下に、本発明が適用された実施形態の通信システムについて説明する。本実施形態の通信システムは、例えば、車両に搭載された複数の装置をノードとして備える車載用の通信システムである。
[第1実施形態]
<全体構成>
図1に示すように、実施形態の通信システム11は、バス5を介して接続された複数のノードとして、マスタノード(以下単に、マスタという)1と、スレーブノード(以下単に、スレーブという)3とを備える。スレーブ3は、1つでも良いが、この例では複数ある。そして、図1では、3つのスレーブ3を図示している。以下において、3つのスレーブ3を区別して説明する場合には、符号として、「3a」,「3b」,「3c」のそれぞれを用いる。
<全体構成>
図1に示すように、実施形態の通信システム11は、バス5を介して接続された複数のノードとして、マスタノード(以下単に、マスタという)1と、スレーブノード(以下単に、スレーブという)3とを備える。スレーブ3は、1つでも良いが、この例では複数ある。そして、図1では、3つのスレーブ3を図示している。以下において、3つのスレーブ3を区別して説明する場合には、符号として、「3a」,「3b」,「3c」のそれぞれを用いる。
マスタ1は、例えばドアミラー、パワーウィンドウ、ドアロック等の機器(いわゆるボデー系機器)を制御するECUである。
スレーブ3は、マスタ1の制御対象である機器を操作するためのスイッチの状態を検出する装置である。例えば、スレーブ3aは、ドアミラーを操作するためのスイッチ(ミラースイッチ)7aの状態を検出する。スレーブ3bは、パワーウィンドウを操作するためのスイッチ(パワーウィンドウスイッチ)7bの状態を検出する。スレーブ3cは、ドアの開/閉に応じてオン/オフするスイッチ(ドアスイッチ)7cの状態を検出する。
スレーブ3は、マスタ1の制御対象である機器を操作するためのスイッチの状態を検出する装置である。例えば、スレーブ3aは、ドアミラーを操作するためのスイッチ(ミラースイッチ)7aの状態を検出する。スレーブ3bは、パワーウィンドウを操作するためのスイッチ(パワーウィンドウスイッチ)7bの状態を検出する。スレーブ3cは、ドアの開/閉に応じてオン/オフするスイッチ(ドアスイッチ)7cの状態を検出する。
スレーブ3は、例えば自身に接続されたスイッチ(7a〜7cの何れか)の状態が変化した場合に、通信実施トリガとしてのイベントが発生したとして、そのイベントに関連する情報を含むフレーム(例えば、変化したスイッチの状態を示すフレーム)を送信する。つまり、スレーブ3は、少なくとも、車両の使用者によるスイッチ操作を検出して、マスタ1に通知する機能を有している。以下では、スレーブ3がイベントの発生に伴って送信するフレームのことを、イベントフレームと言う。また、スレーブ3が行うイベントフレームの送信のことを、イベント送信と言う。
マスタ1は、スレーブ3からのイベントフレームの内容に応じて機器を動作させる。
更に、マスタ1は、スレーブ3が検出する情報とは別の車両状態を検出すると共に、スレーブ3へ、予め設定されたスケジュール(以下、送信スケジュールとも言う)に従って定期的にフレームを送信する。その定期的なフレームには、例えば、マスタ1が検出した車両状態に基づく制御データや故障診断情報等が含まれる。以下では、マスタ1が定期的に送信するフレームのことを、定期フレームと言う。また、マスタ1が行う定期フレームの送信のことを、定期送信と言う。
更に、マスタ1は、スレーブ3が検出する情報とは別の車両状態を検出すると共に、スレーブ3へ、予め設定されたスケジュール(以下、送信スケジュールとも言う)に従って定期的にフレームを送信する。その定期的なフレームには、例えば、マスタ1が検出した車両状態に基づく制御データや故障診断情報等が含まれる。以下では、マスタ1が定期的に送信するフレームのことを、定期フレームと言う。また、マスタ1が行う定期フレームの送信のことを、定期送信と言う。
そして、スレーブ3は、例えば、自身に接続されているアクチュエータ(図示省略)をマスタ1からの定期フレームの内容に応じて動作させたり、マスタ1からの定期フレームに含まれている情報を記憶したりする機能も有している。
バス5では、レセッシブ、ドミナントと呼ばれる二つの信号レベルが用いられる。そして、複数のノードが同時に送信を開始した場合、いずれか一つでもドミナントが含まれていると、バス5の信号レベルはドミナントとなる。つまり、バス5上で信号が衝突した場合、バス調停によって、レセッシブを送信した側が調停負けする(逆に言えば、ドミナントを送信した側が調停勝ちする)ようになっている。以下では、バス5において、レセッシブが予め設定されたビット数(例えば11ビット)以上継続した状態を、バスアイドル状態という。バスアイドル状態は、どのノードも送信していない状態である。
<フレームフォーマットの説明>
通信システム11において、データの送受信に使用されるフレーム(定期フレーム及びイベントフレーム)は、フレームの先頭部分であるヘッダと、そのヘッダに続くデータ部分とからなる。
通信システム11において、データの送受信に使用されるフレーム(定期フレーム及びイベントフレーム)は、フレームの先頭部分であるヘッダと、そのヘッダに続くデータ部分とからなる。
ヘッダは、フレームの受け取り先であるノードや、データ部分に含まれるデータの種類等を示す複数ビット(例えば1バイト)のID(識別子)からなり、そのヘッダの値(IDの値)によって優先度が変わる。
データ部分には、ノード間でやり取りされる実質的なデータの他に、例えば、データ部分のサイズを示すサイズ情報や、エラーの有無をチェックするための誤り訂正符号等も含まれる。
また、通信システム11において、バス調停における優先度は、マスタ1からの定期フレームよりも、スレーブ3からのイベントフレームの方が、高く設定されている。
<マスタの構成>
マスタ1は、当該マスタ1の動作を司るマイクロコンピュータ(以下、マイコンと言う)21と、通信回路23と、を備える。
<マスタの構成>
マスタ1は、当該マスタ1の動作を司るマイクロコンピュータ(以下、マイコンと言う)21と、通信回路23と、を備える。
マイコン21は、CPU25と、CPU25が実行するプログラムが記憶されたROM26と、CPU25による演算結果が記憶されるRAM27と、を備える。また例えば、RAM27における所定の記憶領域は、後述する定期送信キュー28として使用される。
通信回路23は、下記〈a〉〜〈f〉の機能を備える。但し、〈a〉,〈f〉の機能は、マイコン21に備えても良い。
〈a〉バス5の電圧レベルからバスアイドル状態であるか否かを判断して、バスアイドル状態である場合には、マイコン21へアイドル検出信号IDLを出力するアイドル検出機能。
〈a〉バス5の電圧レベルからバスアイドル状態であるか否かを判断して、バスアイドル状態である場合には、マイコン21へアイドル検出信号IDLを出力するアイドル検出機能。
〈b〉マイコン21から供給されるNRZ符号の送信データTxを、バス5上で用いる伝送符号に符号化する符号化機能。伝送符号は、例えばPWM符号である。
〈c〉符号化機能で符号化された送信データTxDをバス5に出力する送信機能。
〈c〉符号化機能で符号化された送信データTxDをバス5に出力する送信機能。
〈d〉バス5上のデータを取り込む受信機能。
〈e〉受信機能で取り込まれたPWM符号の受信データRxDをNRZ符号に復号し、復号後の受信データRxをマイコン21に供給する復号機能。
〈e〉受信機能で取り込まれたPWM符号の受信データRxDをNRZ符号に復号し、復号後の受信データRxをマイコン21に供給する復号機能。
〈f〉送信機能でバスに出力される送信データTxDと、受信機能で取り込まれた受信データRxDとを比較して、両データTxD,RxDの信号レベルが不一致であれば、マイコン21へ衝突検出信号CDを出力すると共に、送信機能による送信を中止させる調停機能。
<スレーブの構成>
スレーブ3も、当該スレーブ3の動作を司るマイコン31と、マスタ1における通信回路23と同様の通信回路33と、を備えている。そして、マイコン31は、CPU35と、CPU35が実行するプログラムが記憶されたROM36と、CPU35による演算結果が記憶されるRAM37と、を備える。また例えば、RAM37における所定の記憶領域は、後述するイベント送信キュー38として使用される。また、スレーブ3はマイコン31を備えず、通信回路33のみで構成しても良い。
スレーブ3も、当該スレーブ3の動作を司るマイコン31と、マスタ1における通信回路23と同様の通信回路33と、を備えている。そして、マイコン31は、CPU35と、CPU35が実行するプログラムが記憶されたROM36と、CPU35による演算結果が記憶されるRAM37と、を備える。また例えば、RAM37における所定の記憶領域は、後述するイベント送信キュー38として使用される。また、スレーブ3はマイコン31を備えず、通信回路33のみで構成しても良い。
尚、通信回路23,33において、送信機能を担う送信回路(図示省略)は、複数のノードから同時に信号が出力された場合、いずれか1つでもローレベルであれば、バス5の信号レベルがローレベルとなるように構成されている。つまり、この例において、バス5上では、ハイレベルがレセッシブ、ローレベルがドミナントである。
<調停負けした場合のノードの動作>
各ノードは、バスアイドル状態を確認した上で、フレームの送信を開始するが、他のノードと送信が重なって、ヘッダの送信段階で調停負けした場合、つまり、ヘッダの送信データTxDと受信データRxDとが不一致になった場合には、フレームの送信(ヘッダの送信)を中止する。その場合、バス5への出力レベルは、ハイレベル(レセッシブ)にする。そして、調停負けしたノードは、その後、バスアイドル状態であることを確認した後、送信しようとして調停負けしたフレームの再送信を実施する。その再送信は、新規のフレームの送信よりも優先して実施する。つまり、ノードは、送信したヘッダが調停負けした場合には、その後、送信が成功するまでヘッダの再送を繰り返し、ヘッダの送信が完了すると、そのヘッダに続いてデータ部を送信する。
各ノードは、バスアイドル状態を確認した上で、フレームの送信を開始するが、他のノードと送信が重なって、ヘッダの送信段階で調停負けした場合、つまり、ヘッダの送信データTxDと受信データRxDとが不一致になった場合には、フレームの送信(ヘッダの送信)を中止する。その場合、バス5への出力レベルは、ハイレベル(レセッシブ)にする。そして、調停負けしたノードは、その後、バスアイドル状態であることを確認した後、送信しようとして調停負けしたフレームの再送信を実施する。その再送信は、新規のフレームの送信よりも優先して実施する。つまり、ノードは、送信したヘッダが調停負けした場合には、その後、送信が成功するまでヘッダの再送を繰り返し、ヘッダの送信が完了すると、そのヘッダに続いてデータ部を送信する。
<マスタにおける送信スケジュールの説明>
例えば図2に示すように、マスタ1は、定期フレームとして、送信タイミングが異なる5種類のフレーム〈1〉〜〈5〉を送信する。フレーム〈1〉,〈2〉の送信周期は50msであり、フレーム〈3〉の送信周期は100msであり、フレーム〈4〉の送信周期は200msであり、フレーム〈5〉の送信周期は500msである。
例えば図2に示すように、マスタ1は、定期フレームとして、送信タイミングが異なる5種類のフレーム〈1〉〜〈5〉を送信する。フレーム〈1〉,〈2〉の送信周期は50msであり、フレーム〈3〉の送信周期は100msであり、フレーム〈4〉の送信周期は200msであり、フレーム〈5〉の送信周期は500msである。
各フレーム〈1〉〜〈5〉の送信順序及び送信間隔は、図3に示す通りである。
図3において、「No」の欄に記載した番号は、各フレーム〈1〉〜〈5〉の送信スケジュールにおける送信順序であり、図2において各フレーム〈1〉〜〈5〉の下に記載した「NoX:Xは1〜23の何れか」に対応している。そして、図3において、「間隔」の欄に記載した時間は、1つ前の定期フレームの送信タイミングから、その欄に対応する定期フレームの送信タイミングまでの、時間間隔を示している。
図3において、「No」の欄に記載した番号は、各フレーム〈1〉〜〈5〉の送信スケジュールにおける送信順序であり、図2において各フレーム〈1〉〜〈5〉の下に記載した「NoX:Xは1〜23の何れか」に対応している。そして、図3において、「間隔」の欄に記載した時間は、1つ前の定期フレームの送信タイミングから、その欄に対応する定期フレームの送信タイミングまでの、時間間隔を示している。
つまり、図3は、スケジュールにおける最初の定期フレーム(No1のフレーム〈1〉)の送信タイミングから15ms後に、2番目の定期フレーム(No2のフレーム〈2〉)の送信タイミングが到来し、2番目の定期フレームの送信タイミングから15ms後に、3番目の定期フレーム(No3のフレーム〈3〉)の送信タイミングが到来する、といった内容を示している。また、図3は、スケジュールにおける最後の定期フレーム(No23のフレーム〈5〉)の送信タイミングから10ms後に、最初の定期フレーム(No1のフレーム〈1〉)の送信タイミングが到来する、という内容も示している。この例では、No1からNo23までのフレームを、1スケジュール分として、繰り返し送信するスケジュールとなっている。
そして、マスタ1のマイコン21においては、図3に示す間隔で、フレーム〈1〉〜〈5〉の送信タイミングを示す定期送信要求が発生するようになっている。
<モードの説明>
通信システム11のモード(マスタ1とスレーブ3との通信方式のモードでもある)は、第1モードと第2モードとに切り替わるようになっている。
<モードの説明>
通信システム11のモード(マスタ1とスレーブ3との通信方式のモードでもある)は、第1モードと第2モードとに切り替わるようになっている。
第1モードは、マスタ1の動作モードがマスタ側第1モードで、スレーブ3の動作モードがスレーブ側第1モードである場合の、通信システム11のモードである。第2モードは、マスタ1の動作モードがマスタ側第2モードで、スレーブ3の動作モードがスレーブ側第2モードである場合の、通信システム11のモードである。
マスタ1は、マスタ側第1モードの場合には、前述の送信スケジュールに従って定期フレームの送信を実施する。
そして、スレーブ3は、スレーブ側第1モードの場合には、イベントが発生した場合に、自律的にイベントフレームの送信を実施する。
そして、スレーブ3は、スレーブ側第1モードの場合には、イベントが発生した場合に、自律的にイベントフレームの送信を実施する。
マスタ側第1モードは、マスタ1の基本モードであり、スレーブ側第1モードは、スレーブ3の基本モードである。基本モードとは、通信システム11が起動してから最初のモード(初期のモード)に該当する。
一方、マスタ1は、マスタ側第2モードの場合には、定期フレームを送信する合間に、スレーブ3に対する送信許可通知を送信する。本実施形態において、マスタ1は、送信許可通知として、イベントフレームの送信許可を意味するヘッダ(通常のフレームにおけるヘッダと同じビット数のデータであり、以下、イベントヘッダと言う)を送信する。
そして、スレーブ3は、スレーブ側第2モードの場合には、イベントが発生し且つマスタ1からのイベントヘッダを受信した場合に、イベントフレームの送信を実施する。つまり、スレーブ3は、スレーブ側第2モードの場合には、マスタ1から送信許可通知としてのイベントヘッダが送信されることで、イベントフレームの送信が許可される。
尚、マスタ1の動作モードは、マイコン21の動作モードでもあり、スレーブ3の動作モードは、マイコン31の動作モードでもある。
そして、マスタ1がマスタ側第1モードの場合、マイコン21は、フレームを送信するためのフレーム送信処理として、後述する図7の処理を行い、スレーブ3がスレーブ側第1モードの場合、マイコン31は、フレーム送信処理として、後述する図8の処理を行う。一方、マスタ1がマスタ側第2モードの場合、マイコン21は、フレーム送信処理として、後述する図9の処理を行い、スレーブ3がスレーブ側第2モードの場合、マイコン31は、フレーム送信処理として、後述する図10の処理を行う。
そして、マスタ1がマスタ側第1モードの場合、マイコン21は、フレームを送信するためのフレーム送信処理として、後述する図7の処理を行い、スレーブ3がスレーブ側第1モードの場合、マイコン31は、フレーム送信処理として、後述する図8の処理を行う。一方、マスタ1がマスタ側第2モードの場合、マイコン21は、フレーム送信処理として、後述する図9の処理を行い、スレーブ3がスレーブ側第2モードの場合、マイコン31は、フレーム送信処理として、後述する図10の処理を行う。
換言すれば、マイコン21が図7の処理を行う場合のマスタ1の動作モード(=マイコン21の動作モード)が、マスタ側第1モードであり、マイコン31が図8の処理を行う場合のスレーブ3の動作モード(=マイコン31の動作モード)が、スレーブ側第1モードである。また、マイコン21が図9の処理を行う場合のマスタ1の動作モードが、マスタ側第2モードであり、マイコン31が図10の処理を行う場合のスレーブ3の動作モードが、スレーブ側第2モードである。
<比較例>
図4は、通信システム11において、第2モードを備えないと仮定した場合(つまり、第1モードのままである場合)の動作を、比較例として表している。尚、図4では、スレーブ3として、2つのスレーブ3a,3bの動作を例示している。そして、このことは、後述する図5についても同様である。
図4は、通信システム11において、第2モードを備えないと仮定した場合(つまり、第1モードのままである場合)の動作を、比較例として表している。尚、図4では、スレーブ3として、2つのスレーブ3a,3bの動作を例示している。そして、このことは、後述する図5についても同様である。
図4に示すように、マスタ1からの定期フレームの送信と、スレーブ3(3a,3b)からのイベントフレームの送信とが、同時に実施された場合、マスタ1は、イベントフレームとの調停負けによって定期フレームの送信を中止する。前述の通り、定期フレームよりもイベントフレームの方が、バス調停における優先度が高く設定されているからである。
そして、マスタ1は、その後、バスアイドル状態になったことを確認してから、調停負けした定期フレームの再送信を試みる。尚、図4において、「マスタ」の段に示した曲線の矢印は、調停負けした定期フレームの再送信を表している。このことは、後述する図5についても同様である。
スレーブ3においてイベントが多発し、スレーブ3の送信頻度が上がると、マスタ1は、調停負けした同じ定期フレームの再送信を繰り返し試みることとなる。
そして、マスタ1においては、調停負けした定期フレームの再送信を繰り返している間に、次に送信すべき新規の定期フレームの送信タイミングが到来することで、送信待ちの定期フレーム(具体的には、送信タイミングが到来したものの、送信が未実施の定期フレーム)が滞留していく。
そして、マスタ1においては、調停負けした定期フレームの再送信を繰り返している間に、次に送信すべき新規の定期フレームの送信タイミングが到来することで、送信待ちの定期フレーム(具体的には、送信タイミングが到来したものの、送信が未実施の定期フレーム)が滞留していく。
マスタ1において、送信待ちの定期フレームが滞留すると、送信スケジュールが崩れてしまい、定期フレームを受信するスレーブ3において、不都合が生じる。例えば、マスタ1からの定期フレームに含まれる制御データを用いるスレーブ3において、制御処理を正しく実施することができなくなったり、スレーブ3における異常検出機能により、異常であると誤検出されてしまったりすることとなる。
<実施形態の特徴の概要>
一方、図5に示すように、本実施形態の通信システム11では、第1モードの場合に、マスタ1は、送信待ちの定期フレームが溜まってしまった送信滞留状態になったことを検出すると(時刻t1)、スレーブ3に対してモード切替フレームを送信する。
一方、図5に示すように、本実施形態の通信システム11では、第1モードの場合に、マスタ1は、送信待ちの定期フレームが溜まってしまった送信滞留状態になったことを検出すると(時刻t1)、スレーブ3に対してモード切替フレームを送信する。
モード切替フレームは、全てのスレーブ3に対して動作モードの切り替えを指令するためのフレームである。そして、この場合、マスタ1は、モード切替フレームとして、スレーブ側第2モードへの切り替えを指令するためのフレーム(第2モード切替指令に相当するフレームであり、以下、第2モード切替フレームと言う)を送信する。尚、第2モード切替フレームは、イベントフレームよりも、バス調停における優先度が高く設定されている。このため、全てのスレーブ3に対して、スレーブ側第2モードへの切り替えを、調停負けが発生することなく確実に通知することができる。
マスタ1は、第2モード切替フレームを送信すると、自身の動作モードを、マスタ側第1モードからマスタ側第2モードに切り替える。また、スレーブ3は、第2モード切替フレームを受信すると、自身の動作モードを、スレーブ側第1モードからスレーブ側第2モードに切り替える。このため、通信システム11は、第1モードから第2モードに切り替わる。
第2モードにおいて、マスタ1は、定期フレームを送信する合間に、スレーブ3に対する前述のイベントヘッダを送信する。本実施形態において、マスタ1は、イベントヘッダを定期的に(一定時間毎に)送信する。
そして、スレーブ3は、マスタ1からのイベントヘッダを受信することによって、イベントフレームの送信が許可される。つまり、スレーブ3は、イベントが発生しても、マスタ1からのイベントヘッダを受信しない限り、イベントフレームを送信しない。
よって、スレーブ3からのイベントフレームの送信及び送信頻度が、マスタ1によってコントロールされることとなり、マスタ1からの定期フレームが調停負けすることが無い。そして、マスタ1は、スレーブ3からのイベントフレームの送信頻度を抑制した状態で、滞留していた送信待ちの定期フレームを順次送信する。このため、定期フレームをスケジュール通りに送信することが可能な状態(以下単に、正常状態とも言う)へと復帰することができる。また、スレーブ3からのイベントフレームの送信を完全に禁止するわけではないため、イベントフレームが送信されることによる機能も確保される。これにより、スレーブ3のイベント送信を実現しつつ、マスタ1における定期送信の停滞を解消することができる。
そして、第2モードの場合に、マスタ1は、送信滞留状態が解消したことを検出すると(時刻t2)、スレーブ3に対してモード切替フレームを送信する。この場合、マスタ1は、モード切替フレームとして、スレーブ側第1モードへの切り替えを指令するためのフレーム(第1モード切替指令に相当するフレームであり、以下、第1モード切替フレームと言う)を送信する。
マスタ1は、第1モード切替フレームを送信すると、自身の動作モードを、マスタ側第2モードからマスタ側第1モードに切り替える。また、スレーブ3は、第1モード切替フレームを受信すると、自身の動作モードを、スレーブ側第2モードからスレーブ側第1モードに切り替える。このため、通信システム11は、第2モードから第1モードに戻る。
つまり、マスタ1において滞留した定期フレームの送信が全て完了して、定期送信をスケジュール通りに実施することができる状態になったら、スレーブ3のイベント送信が自由に実施できる元の第1モード(換言すれば、イベントフレームの送信応答性を高くした第1モード)に復帰する。
<各ノードで実施される処理の説明>
マスタ1のマイコン21が行う処理(実際には、CPU25がROM26内のプログラムに従って行う処理)と、スレーブ3のマイコン31が行う処理(実際には、CPU35がROM36内のプログラムに従って行う処理)とについて、説明する。
マスタ1のマイコン21が行う処理(実際には、CPU25がROM26内のプログラムに従って行う処理)と、スレーブ3のマイコン31が行う処理(実際には、CPU35がROM36内のプログラムに従って行う処理)とについて、説明する。
《スレーブ側のモード切替処理》
スレーブ3のマイコン31は、通信回路33によって他のノードからのフレームが受信されたことを検知すると、図6に示すモード切替処理を実行する。
スレーブ3のマイコン31は、通信回路33によって他のノードからのフレームが受信されたことを検知すると、図6に示すモード切替処理を実行する。
図6に示すように、スレーブ3のマイコン31は、モード切替処理を開始すると、S210にて、通信回路33から受信データを取得する。マイコン31は、次のS220にて、S210で取得した受信データに基づいて、今回受信したフレームがマスタ1からの第2モード切替フレームであるか否か(即ち、第2モード切替フレームを受信したか否か)を判定する。
マイコン31は、第2モード切替フレームを受信したと判定した場合には(S220:YES)、S230にて、当該スレーブ3の動作モードをスレーブ側第2モードに設定する処理を行い、その後、当該モード切替処理を終了する。マイコン31は、S230では、具体的には、フレーム送信処理として図10の処理を行うように、内部設定を行う。
このため、スレーブ3の動作モードがスレーブ側第1モードである場合に、スレーブ3が第2モード切替フレームを受信すると、S230の処理により、スレーブ3の動作モードは、スレーブ側第1モードからスレーブ側第2モードに切り替わる。
また、マイコン31は、上記S220にて、第2モード切替フレームを受信していないと判定した場合には、S240に移行する。
マイコン31は、S240では、S210で取得した受信データに基づいて、今回受信したフレームがマスタ1からの第1モード切替フレームであるか否か(即ち、第1モード切替フレームを受信したか否か)を判定する。
マイコン31は、S240では、S210で取得した受信データに基づいて、今回受信したフレームがマスタ1からの第1モード切替フレームであるか否か(即ち、第1モード切替フレームを受信したか否か)を判定する。
マイコン31は、第1モード切替フレームを受信したと判定した場合には(S240:YES)、S250にて、当該スレーブ3の動作モードをスレーブ側第1モードに設定する処理を行い、その後、当該モード切替処理を終了する。マイコン31は、S250では、具体的には、フレーム送信処理として図8の処理を行うように、内部設定を行う。
このため、スレーブ3の動作モードがスレーブ側第2モードである場合に、スレーブ3が第1モード切替フレームを受信すると、S250の処理により、スレーブ3の動作モードは、スレーブ側第2モードからスレーブ側第1モードに切り替わる。
一方、マイコン31は、上記S240にて、第1モード切替フレームを受信していないと判定した場合には、そのまま当該モード切替処理を終了する。この場合、マイコン31は、受信したデータの種類に応じて定められている処理を行うこととなる。
尚、前述したように、通信システム11の起動直後におけるマスタ1とスレーブ3との動作モードは、マスタ側第1モードとスレーブ側第1モードであるが、通信システム11の起動時において、マスタ1が第1モード切替フレームを送信することで、スレーブ3がスレーブ側第1モードになるように構成しても良い。
《マスタ側第1モードでのフレーム送信処理》
マスタ1がマスタ側第1モードの場合に、マイコン21は、フレーム送信処理として、図7に示す「マスタ側第1モードでのフレーム送信処理」を一定時間毎に実行する。尚、その一定時間は、図2,図3で説明した送信スケジュールにおける定期フレームの送信間隔の最小値(この例では10ms)よりも十分に短い。
マスタ1がマスタ側第1モードの場合に、マイコン21は、フレーム送信処理として、図7に示す「マスタ側第1モードでのフレーム送信処理」を一定時間毎に実行する。尚、その一定時間は、図2,図3で説明した送信スケジュールにおける定期フレームの送信間隔の最小値(この例では10ms)よりも十分に短い。
図7に示すように、マイコン21は、マスタ側第1モードでのフレーム送信処理を開始すると、S310にて、送信要求があるか否かを判定する。このS310にて、送信要求があると判定される条件は、下記3つの条件の何れかである。
・当該図7の処理を前回開始してから今回開始するまでの間に、新規の定期送信要求が発生した、という条件。
尚、「新規の定期送信要求が発生した」とは、送信スケジュールで定められている何れかの定期フレーム(フレーム〈1〉〜〈5〉)の送信タイミングが到来した、ということである。
尚、「新規の定期送信要求が発生した」とは、送信スケジュールで定められている何れかの定期フレーム(フレーム〈1〉〜〈5〉)の送信タイミングが到来した、ということである。
・定期送信キュー28にフレーム情報が格納されている、という条件。
尚、定期送信キュー28は、送信スケジュールに基づく送信タイミングが到来したものの、送信が未実施である定期フレームを示す情報(識別情報)が、フレーム情報として格納されるキューである。定期送信キュー28は、フレーム情報をN個(Nは2以上の整数)格納できるようになっている。また例えば、定期送信キュー28には、フレーム情報として、定期フレームのヘッダを成すデータが格納される。
尚、定期送信キュー28は、送信スケジュールに基づく送信タイミングが到来したものの、送信が未実施である定期フレームを示す情報(識別情報)が、フレーム情報として格納されるキューである。定期送信キュー28は、フレーム情報をN個(Nは2以上の整数)格納できるようになっている。また例えば、定期送信キュー28には、フレーム情報として、定期フレームのヘッダを成すデータが格納される。
・再送キューに再送情報が格納されている、という条件。
尚、再送キューは、送信を試みた(実施した)ものの、ヘッダの送信時点で調停負けして、送信が中止されたフレーム(即ち、マスタ1においては、調停負けして再送すべき定期フレーム)を示す情報(識別情報)が、再送情報として格納されるキューである。再送キューは、再送情報を1個格納できるようになっている。また例えば、定期送信キュー28と同様に、再送キューには、再送情報として、再送すべきフレームのヘッダを成すデータが格納される。
尚、再送キューは、送信を試みた(実施した)ものの、ヘッダの送信時点で調停負けして、送信が中止されたフレーム(即ち、マスタ1においては、調停負けして再送すべき定期フレーム)を示す情報(識別情報)が、再送情報として格納されるキューである。再送キューは、再送情報を1個格納できるようになっている。また例えば、定期送信キュー28と同様に、再送キューには、再送情報として、再送すべきフレームのヘッダを成すデータが格納される。
マイコン21は、S310にて、送信要求がないと判定した場合には、そのまま当該図7の処理を終了するが、S310にて、送信要求があると判定した場合には、S315に進む。
マイコン21は、S315では、当該図7の処理を前回開始してから今回開始するまでの間に、新規の定期送信要求が発生したか否かを判定し、新規の定期送信要求が発生した場合には、S320に進む。
マイコン21は、S320では、発生した新規の定期送信要求に対応する定期フレーム(つまり、送信タイミングが到来した定期フレーム)の識別情報を、フレーム情報として、定期送信キュー28にエンキューする(つまり、定期送信キュー28に格納する)。その後、マイコン21は、S325に進む。
また、マイコン21は、S315にて、新規の定期送信要求が発生していないと判定した場合には、そのままS325に進む。
マイコン21は、S325では、定期送信キュー28がフルになったか否か(つまり、定期送信キュー28に格納されたフレーム情報の数が最大数のN個になったか否か)を判定し、定期送信キュー28がフルになっていなければ、S330に進む。
マイコン21は、S325では、定期送信キュー28がフルになったか否か(つまり、定期送信キュー28に格納されたフレーム情報の数が最大数のN個になったか否か)を判定し、定期送信キュー28がフルになっていなければ、S330に進む。
マイコン21は、S330では、通信回路23からのアイドル検出信号IDLに基づいて、バスアイドル状態であるか否かを判定し、バスアイドル状態でなければ、そのまま当該図7の処理を終了するが、バスアイドル状態であれば、S335に進む。
マイコン21は、S335では、再送キューに再送情報が入っているか否かを判定し、再送キューに再送情報が入っている場合には、S340に進む。
マイコン21は、S340では、再送キューから再送情報をデキューする。つまり、再送キュー内の再送情報を読み出した後、その読み出した再送情報を再送キューから削除する。その後、マイコン21は、S350に進む。
マイコン21は、S340では、再送キューから再送情報をデキューする。つまり、再送キュー内の再送情報を読み出した後、その読み出した再送情報を再送キューから削除する。その後、マイコン21は、S350に進む。
また、マイコン21は、上記S335にて、再送キューに再送情報が入っていないと判定した場合には、S345に進み、定期送信キュー28からフレーム情報をデキューする。つまり、定期送信キュー28内の最も古いフレーム情報を読み出した後、その読み出したフレーム情報を定期送信キュー28から削除する。その後、マイコン21は、S350に進む。
マイコン21は、S350では、S340から当該S350に進んだ場合には、S340で再送キューから読み出した再送情報が示す定期フレームを、送信対象のフレームとする。また、マイコン21は、S345から当該S350に進んだ場合には、S345で定期送信キュー28から読み出したフレーム情報が示す定期フレームを、送信対象のフレームとする。
そして、マイコン21は、S350では、送信対象のフレームを送信するための送信処理を実施する。具体的には、マイコン21は、まず、フレームのヘッダを成すデータを、通信回路23に送信データTxとして供給する。そして、マイコン21は、通信回路23から前述の衝突検出信号CDが出力されなければ(つまり、通信回路23によってバス5に出力されたヘッダが調停負けしなければ)、フレームのデータ部分を成すデータを、通信回路23に送信データTxとして供給する。尚、通信回路23に供給するデータのうち、フレームのデータ部分を成すデータとしては、例えば、当該S350の実行時における最新のデータを用いるが、そのフレームの送信タイミングが到来したときのデータを用いても良い。
マイコン21は、次のS355にて、調停負けしたか否かを判定する。具体的には、通信回路23から衝突検出信号CDが出力されたか否かを判定する。そして、マイコン21は、調停負けしていないと判定した場合には、そのまま当該図7の処理を終了するが、調停負けしたと判定した場合には、S360に進む。
尚、実際には、マイコン21は、S350にて、ヘッダの送信を実施している途中で、通信回路23から衝突検出信号CDが出力されると、送信処理を中止して、S355に進み、そのS355にて、調停負けしたと判定する。また、マイコン21は、S350にて、ヘッダの送信を実施している途中で、通信回路23から衝突検出信号CDが出力されなければ、フレームの送信を全て完了してから、S355に進み、そのS355にて、調停負けしていないと判定することとなる。
マイコン21は、S360では、今回送信対象とした定期フレーム(即ち、調停負けによって送信に失敗した定期フレーム)の識別情報を、再送情報として、再送キューにエンキューする(つまり、格納する)。その後、マイコン21は、当該図7の処理を終了する。
一方、マイコン21は、上記S325にて、定期送信キュー28がフルになったと判定した場合には、前述の送信滞留状態(送信待ちの定期フレームが溜まってしまった状態)になったと判断して、S365に進む。
そして、マイコン21は、S365では、通信回路23からのアイドル検出信号IDLに基づきバスアイドル状態であることを確認した上で、前述の第2モード切替フレームを送信するための送信処理を実施する。その送信処理の内容は、S350での送信処理と同様である。このS365にて、スレーブ3へ第2モード切替フレームが送信されることにより、スレーブ3の動作モードがスレーブ側第1モードからスレーブ側第2モードに切り替わる。
更に、マイコン21は、次のS370にて、当該マスタ1の動作モードを、マスタ側第1モードからマスタ側第2モードに切り替える処理を行う。具体的には、マイコン21は、フレーム送信処理として当該図7の処理を行うモードから、フレーム送信処理として図9の処理を行うモードへと、切り替えるための内部設定を行う。このため、マイコン21は、以後は、一定時間毎に、当該図7の処理に代えて、図9の処理を実行することとなる。
そして更に、マイコン21は、次のS375にて、イベントヘッダの送信間隔を計測するためのイベントヘッダ送信タイマをスタートさせ、その後、当該図7の処理を終了する。尚、イベントヘッダ送信タイマは、図示しないタイマ処理によって一定の時間毎にカウントアップされるタイマである。そして、マイコン21は、S375では、イベントヘッダ送信タイマの値を0にリセットすることで、そのイベントヘッダ送信タイマをスタートさせる。
マスタ1では、マイコン21が図7の処理を実行することにより、下記の機能が実現される。
・送信スケジュールで定められた何れかの定期フレームの送信タイミングが到来すると、送信タイミングが到来した定期フレームの識別情報が、フレーム情報として定期送信キュー28に格納される(S320)。そして、定期送信キュー28に格納されたフレーム情報のうち、最も古い(つまり、最も前に格納された)フレーム情報が示す定期フレームの送信が実施されると共に、送信が実施された定期フレームのフレーム情報は定期送信キュー28から削除される(S345,S350)。このため、送信スケジュールに従って定期フレームの送信が実施される。
・送信スケジュールで定められた何れかの定期フレームの送信タイミングが到来すると、送信タイミングが到来した定期フレームの識別情報が、フレーム情報として定期送信キュー28に格納される(S320)。そして、定期送信キュー28に格納されたフレーム情報のうち、最も古い(つまり、最も前に格納された)フレーム情報が示す定期フレームの送信が実施されると共に、送信が実施された定期フレームのフレーム情報は定期送信キュー28から削除される(S345,S350)。このため、送信スケジュールに従って定期フレームの送信が実施される。
・但し、定期フレームの送信を実施した際に、ヘッダの送信段階で調停負けした場合には(S355:YES)、その調停負けした定期フレームの識別情報が、再送情報として再送キューに格納される(S360)。そして、再送キュー内に再送情報が格納されると、定期送信キュー28よりも再送キューの方が優先してデキューの対象となり、定期送信キュー28内のフレーム情報が示す定期フレームよりも、再送キュー内の再送情報が示す定期フレームの方が、優先して送信対象とされる(S335:YES,S340,S350)。つまり、調停負けした定期フレームの再送信が、新規の定期フレームの送信よりも優先して実施される。このため、調停負けした定期フレームの再送信を試みている間に、次に送信すべき定期フレームの送信タイミングが到来すると、定期送信キュー28にフレーム情報が蓄積されていく。
・定期送信キュー28に複数個のフレーム情報が蓄積されても、調停負けした定期フレームの再送信に成功して再送キュー内の再送情報が無くなれば、定期送信キュー28内のフレーム情報が古いものから1つずつデキューされる(S335:NO,S345)。そして、そのデキューされたフレーム情報が示す定期フレーム(即ち、送信待ちとなっていた定期フレーム)の送信が実施される(S350)。
・一方、定期フレームの再送信が調停負けによって繰り返されて、定期送信キュー28内のフレーム情報がN個になった場合には(S325:YES)、マスタ1からスレーブ3へ第2モード切替フレームが送信される(S365)。すると、スレーブ3がスレーブ側第1モードからスレーブ側第2モードに遷移する。また、マスタ1もマスタ側第1モードからマスタ側第2モードに遷移する(S370)。更に、その場合には、イベントヘッダ送信タイマがスタートされる(S375)。
《スレーブ側第1モードでのフレーム送信処理》
スレーブ3がスレーブ側第1モードの場合に、マイコン31は、フレーム送信処理として、図8に示す「スレーブ側第1モードでのフレーム送信処理」を一定時間毎に実行する。
スレーブ3がスレーブ側第1モードの場合に、マイコン31は、フレーム送信処理として、図8に示す「スレーブ側第1モードでのフレーム送信処理」を一定時間毎に実行する。
図8に示すように、マイコン31は、スレーブ側第1モードでのフレーム送信処理を開始すると、S410にて、送信要求があるか否かを判定する。このS410にて、送信要求があると判定される条件は、下記3つの条件の何れかである。
・当該図8の処理を前回開始してから今回開始するまでの間に、新規のイベント(通信実施トリガとしてのイベント)が発生した、という条件。
・イベント送信キュー38にフレーム情報が格納されている、という条件。
・イベント送信キュー38にフレーム情報が格納されている、という条件。
尚、イベント送信キュー38は、イベントが発生したものの、送信が未実施であるイベントフレームを示す情報(識別情報)が、フレーム情報として格納されるキューである。イベント送信キュー38は、フレーム情報をM個(Mは2以上の整数)格納できるようになっている。また例えば、イベント送信キュー38には、フレーム情報として、イベントフレームのヘッダを成すデータが格納される。
・再送キューに再送情報が格納されている、という条件。
尚、再送キュー及び再送情報は、マスタ1のマイコン21に関して説明した再送キュー及び再送情報と同様のものである。但し、スレーブ3のマイコン31において、再送キューには、調停負けして送信が中止されたイベントフレームを示す情報(識別情報)が、再送情報として格納される。また、スレーブ3からのイベントフレームが調停負けする可能性がある相手は、他のスレーブ3が送信するイベントフレームか、マスタ1が送信する第2モード切替フレームである。
尚、再送キュー及び再送情報は、マスタ1のマイコン21に関して説明した再送キュー及び再送情報と同様のものである。但し、スレーブ3のマイコン31において、再送キューには、調停負けして送信が中止されたイベントフレームを示す情報(識別情報)が、再送情報として格納される。また、スレーブ3からのイベントフレームが調停負けする可能性がある相手は、他のスレーブ3が送信するイベントフレームか、マスタ1が送信する第2モード切替フレームである。
マイコン31は、S410にて、送信要求がないと判定した場合には、そのまま当該図8の処理を終了するが、S410にて、送信要求があると判定した場合には、S415に進む。
マイコン31は、S415では、当該図8の処理を前回開始してから今回開始するまでの間に、新規のイベントが発生したか否かを判定し、新規のイベントが発生した場合には、S420に進む。
マイコン31は、S420では、発生した新規のイベントに対応するイベントフレームの識別情報を、フレーム情報として、イベント送信キュー38にエンキューする(つまり、イベント送信キュー38に格納する)。その後、マイコン31は、S430に進む。
また、マイコン31は、S415にて、新規のイベントが発生していないと判定した場合には、そのままS430に進む。
マイコン31は、S430では、通信回路33からのアイドル検出信号IDLに基づいて、バスアイドル状態であるか否かを判定し、バスアイドル状態でなければ、そのまま当該図8の処理を終了するが、バスアイドル状態であれば、S435に進む。
マイコン31は、S430では、通信回路33からのアイドル検出信号IDLに基づいて、バスアイドル状態であるか否かを判定し、バスアイドル状態でなければ、そのまま当該図8の処理を終了するが、バスアイドル状態であれば、S435に進む。
マイコン31は、S435では、再送キューに再送情報が入っているか否かを判定し、再送キューに再送情報が入っている場合には、S440に進む。
マイコン31は、S440では、再送キューから再送情報をデキューする。つまり、再送キュー内の再送情報を読み出した後、その読み出した再送情報を再送キューから削除する。その後、マイコン31は、S450に進む。
マイコン31は、S440では、再送キューから再送情報をデキューする。つまり、再送キュー内の再送情報を読み出した後、その読み出した再送情報を再送キューから削除する。その後、マイコン31は、S450に進む。
また、マイコン31は、上記S435にて、再送キューに再送情報が入っていないと判定した場合には、S445に進み、イベント送信キュー38からフレーム情報をデキューする。つまり、イベント送信キュー38内の最も古いフレーム情報を読み出した後、その読み出したフレーム情報をイベント送信キュー38から削除する。その後、マイコン31は、S450に進む。
マイコン31は、S450では、S440から当該S450に進んだ場合には、S440で再送キューから読み出した再送情報が示すイベントフレームを、送信対象のフレームとする。また、マイコン31は、S445から当該S450に進んだ場合には、S445でイベント送信キュー38から読み出したフレーム情報が示すイベントフレームを、送信対象のフレームとする。
そして、マイコン31は、S450では、送信対象のフレームを送信するための送信処理を実施する。その送信処理の内容は、マスタ1のマイコン21が図7のS350で実施する送信処理と同様である。尚、S450の送信処理において、通信回路33に供給するデータのうち、イベントフレームのデータ部分を成すデータとしては、そのイベントフレームに対応するイベントが発生した時点でのデータを用いる。
マイコン31は、次のS455にて、調停負けしたか否かを判定する。具体的には、通信回路33から衝突検出信号CDが出力されたか否かを判定する。そして、マイコン31は、調停負けしていないと判定した場合には、そのまま当該図8の処理を終了するが、調停負けしたと判定した場合には、S460に進む。
尚、図7のS350及びS355について説明したのと同様に、マイコン31は、実際には、S450にて、ヘッダの送信を実施している途中で、通信回路33から衝突検出信号CDが出力されると、送信処理を中止して、S455に進み、そのS455にて、調停負けしたと判定する。また、マイコン31は、S450にて、ヘッダの送信を実施している途中で、通信回路33から衝突検出信号CDが出力されなければ、フレームの送信を全て完了してから、S455に進み、そのS455にて、調停負けしていないと判定することとなる。
マイコン31は、S460では、今回送信対象としたイベントフレーム(即ち、調停負けによって送信に失敗したイベントフレーム)の識別情報を、再送情報として、再送キューにエンキューする(つまり、格納する)。その後、マイコン31は、当該図8の処理を終了する。
スレーブ3では、マイコン31が図8の処理を実行することにより、下記の機能が実現される。
・予め定められたイベントが発生すると、発生したイベントに対応するイベントフレームの識別情報が、フレーム情報としてイベント送信キュー38に格納される(S420)。そして、イベント送信キュー38に格納されたフレーム情報のうち、最も古いフレーム情報が示すイベントフレームの送信が実施されると共に、送信が実施されたイベントフレームのフレーム情報はイベント送信キュー38から削除される(S445,S450)。このため、イベントが発生する毎に、その発生したイベントに関連する情報をデータ部分に含むイベントフレームの送信が実施される。
・予め定められたイベントが発生すると、発生したイベントに対応するイベントフレームの識別情報が、フレーム情報としてイベント送信キュー38に格納される(S420)。そして、イベント送信キュー38に格納されたフレーム情報のうち、最も古いフレーム情報が示すイベントフレームの送信が実施されると共に、送信が実施されたイベントフレームのフレーム情報はイベント送信キュー38から削除される(S445,S450)。このため、イベントが発生する毎に、その発生したイベントに関連する情報をデータ部分に含むイベントフレームの送信が実施される。
・但し、イベントフレームの送信を実施した際に、ヘッダの送信段階で調停負けした場合には(S455:YES)、その調停負けしたイベントフレームの識別情報が、再送情報として再送キューに格納される(S460)。そして、再送キュー内に再送情報が格納されると、イベント送信キュー38よりも再送キューの方が優先してデキューの対象となり、イベント送信キュー38内のフレーム情報が示すイベントフレームよりも、再送キュー内の再送情報が示すイベントフレームの方が、優先して送信対象とされる(S435:YES,S440,S450)。つまり、調停負けしたイベントフレームの再送信が、新規のイベントフレームの送信よりも優先して実施される。このため、調停負けしたイベントフレームの再送信を試みている間に、新たにイベントが発生すると、イベント送信キュー38にフレーム情報が蓄積されていく。
・イベント送信キュー38に複数個のフレーム情報が蓄積されても、調停負けしたイベントフレームの再送信に成功して再送キュー内の再送情報が無くなれば、イベント送信キュー38内のフレーム情報が古いものから1つずつデキューされる(S435:NO,S445)。そして、そのデキューされたフレーム情報が示すイベントフレーム(即ち、送信待ちとなっていたイベントフレーム)の送信が実施される(S450)。
・イベント送信キュー38に複数個のフレーム情報が蓄積されても、調停負けしたイベントフレームの再送信に成功して再送キュー内の再送情報が無くなれば、イベント送信キュー38内のフレーム情報が古いものから1つずつデキューされる(S435:NO,S445)。そして、そのデキューされたフレーム情報が示すイベントフレーム(即ち、送信待ちとなっていたイベントフレーム)の送信が実施される(S450)。
《マスタ側第2モードでのフレーム送信処理》
マスタ1がマスタ側第2モードの場合に、マイコン21は、図7の処理に代えて、図9に示す「マスタ側第2モードでのフレーム送信処理」を実行する。
マスタ1がマスタ側第2モードの場合に、マイコン21は、図7の処理に代えて、図9に示す「マスタ側第2モードでのフレーム送信処理」を実行する。
図9に示すように、マイコン21は、マスタ側第2モードでのフレーム送信処理を開始すると、S510にて、イベントヘッダ送信タイマのスタート時から規定時間が経過したか否かを判定する。具体的には、イベントヘッダ送信タイマの値が規定値以上になったか否かを判定する。尚、イベントヘッダ送信タイマは、前述した図7のS375でスタートされるが、図9における後述のS560でもスタート(この場合は再スタート)される。
マイコン21は、S510にて、イベントヘッダ送信タイマのスタート時から規定時間が経過していないと判定した場合には、S520に進む。
マイコン21は、S520では、図7のS310と同様に、送信要求があるか否かを判定する。但し、マスタ側第2モードの場合、マスタ1からの定期フレームが調停負けする可能性は無いため、S510にて、送信要求があると判定される条件は、下記2つの条件の何れかである。
マイコン21は、S520では、図7のS310と同様に、送信要求があるか否かを判定する。但し、マスタ側第2モードの場合、マスタ1からの定期フレームが調停負けする可能性は無いため、S510にて、送信要求があると判定される条件は、下記2つの条件の何れかである。
・当該図9の処理を前回開始してから今回開始するまでの間に、新規の定期送信要求が発生した、という条件。
・定期送信キュー28にフレーム情報が格納されている、という条件。
・定期送信キュー28にフレーム情報が格納されている、という条件。
マイコン21は、S520にて、送信要求がないと判定した場合には、そのままS565に進むが、S520にて、送信要求があると判定した場合には、S525に進む。
マイコン21は、S525では、図7のS315と同様に、当該図9の処理を前回開始してから今回開始するまでの間に、新規の定期送信要求が発生したか否かを判定し、新規の定期送信要求が発生した場合には、S530に進む。
マイコン21は、S525では、図7のS315と同様に、当該図9の処理を前回開始してから今回開始するまでの間に、新規の定期送信要求が発生したか否かを判定し、新規の定期送信要求が発生した場合には、S530に進む。
マイコン21は、S530では、図7のS320と同様に、発生した新規の定期送信要求に対応する定期フレーム(つまり、送信タイミングが到来した定期フレーム)の識別情報を、フレーム情報として、定期送信キュー28にエンキューする(格納する)。その後、マイコン21は、S535に進む。
また、マイコン21は、S525にて、新規の定期送信要求が発生していないと判定した場合には、そのままS535に進む。
一方、マイコン21は、S510にて、イベントヘッダ送信タイマのスタート時から規定時間が経過したと判定した場合には、S515に進み、イベントヘッダの送信タイミングが到来したことを示すイベントヘッダ送信フラグをオンした後、S535に進む。
一方、マイコン21は、S510にて、イベントヘッダ送信タイマのスタート時から規定時間が経過したと判定した場合には、S515に進み、イベントヘッダの送信タイミングが到来したことを示すイベントヘッダ送信フラグをオンした後、S535に進む。
マイコン21は、S535では、図7のS330と同様に、バスアイドル状態であるか否かを判定し、バスアイドル状態でなければ、そのままS565に進むが、バスアイドル状態であれば、S540に進む。
マイコン21は、S540では、イベントヘッダ送信フラグがオンであるか否かを判定し、イベントヘッダ送信フラグがオンでなければ、S545進み、図7のS345と同様に、定期送信キュー28からフレーム情報をデキューする。つまり、定期送信キュー28内の最も古いフレーム情報を読み出した後、その読み出したフレーム情報を定期送信キュー28から削除する。そして、マイコン21は、次のS550にて、S545で定期送信キュー28から読み出したフレーム情報が示す定期フレームを送信するための送信処理を実施する。その送信処理の内容は、図7のS350で実施する送信処理と同様である。その後、マイコン21は、S565に進む。
また、マイコン21は、S540にて、イベントヘッダ送信フラグがオンであると判定した場合には、S555に進み、イベントヘッダの送信を実施する。具体的には、マイコン21は、イベントヘッダを成すデータを、通信回路23に送信データTxとして供給する。そして、マイコン21は、次のS560にて、イベントヘッダ送信フラグをオフすると共に、イベントヘッダ送信タイマの値を0にリセットすることで、そのイベントヘッダ送信タイマを再スタートさせ、その後、S565に進む。
マイコン21は、S565では、定期送信キュー28が空である(つまり、定期送信キュー28に格納されているフレーム情報が0個である)か否かを判定する。
そして、マイコン21は、定期送信キュー28が空でなければ、そのまま当該図9の処理を終了するが、定期送信キュー28が空であれば、送信滞留状態から正常状態(定期フレームをスケジュールの通りに送信することが可能な状態)に復帰したと判断して、S570に進む。
そして、マイコン21は、定期送信キュー28が空でなければ、そのまま当該図9の処理を終了するが、定期送信キュー28が空であれば、送信滞留状態から正常状態(定期フレームをスケジュールの通りに送信することが可能な状態)に復帰したと判断して、S570に進む。
マイコン21は、S570では、通信回路23からのアイドル検出信号IDLに基づきバスアイドル状態であることを確認した上で、前述の第1モード切替フレームを送信するための送信処理を実施する。その送信処理の内容は、図7のS350で実施する送信処理と同様である。このS570にて、スレーブ3へ第1モード切替フレームが送信されることにより、スレーブ3の動作モードがスレーブ側第2モードからスレーブ側第1モードに切り替わる。尚、第2モード切替フレームと同様に、第1モード切替フレームのバス調停における優先度も、イベントフレームより高く設定しておくことができる。また、第1モード切替フレームのバス調停における優先度が、イベントフレームより低く設定されていても、例えば、S555でイベントヘッダを送信してから所定時間が経過していることを確認した上でS570の処理を実施すれば、第1モード切替フレームとイベントフレームとが衝突する可能性を無くすことができる。
更に、マイコン21は、次のS575にて、当該マスタ1の動作モードを、マスタ側第2モードからマスタ側第1モードに切り替える処理を行う。具体的には、マイコン21は、フレーム送信処理として当該図9の処理を行うモードから、フレーム送信処理として図7の処理を行うモードへと、切り替えるための内部設定を行う。その後、マイコン21は、当該図9の処理を終了する。マイコン21は、以後は、一定時間毎に、当該図9の処理に代えて、図7の処理を実行することとなる。
マスタ1では、マイコン21が図9の処理を実行することにより、下記の機能が実現される。
・定期送信キュー28内の複数の各フレーム情報が古いものから1つずつデキューされて(S545)、その各フレーム情報が示す定期フレームの送信が順次実施される(S550)。このため、送信待ちとなっていた定期フレームが本来の送信順で送信される。また、送信待ちとなっていた定期フレームを順次送信している間に、新たな定期フレームの送信タイミングが到来した場合には、その新たな定期フレームの識別情報が最新のフレーム情報として定期送信キュー28に格納される(S525:YES、S530)。このため、その新たな定期フレームの送信も実施される。
・定期送信キュー28内の複数の各フレーム情報が古いものから1つずつデキューされて(S545)、その各フレーム情報が示す定期フレームの送信が順次実施される(S550)。このため、送信待ちとなっていた定期フレームが本来の送信順で送信される。また、送信待ちとなっていた定期フレームを順次送信している間に、新たな定期フレームの送信タイミングが到来した場合には、その新たな定期フレームの識別情報が最新のフレーム情報として定期送信キュー28に格納される(S525:YES、S530)。このため、その新たな定期フレームの送信も実施される。
よって、マスタ1がマスタ側第2モードの場合でも、送信スケジュールに従って定期フレームの送信が実施される。
・定期フレームが送信される合間に、スレーブ3に対するイベントヘッダが送信される(S540:YES、S555)。この例では、マスタ1がマスタ側第2モードになってから、S510で判定される一定の規定時間毎に、イベントヘッダが送信される。
・定期フレームが送信される合間に、スレーブ3に対するイベントヘッダが送信される(S540:YES、S555)。この例では、マスタ1がマスタ側第2モードになってから、S510で判定される一定の規定時間毎に、イベントヘッダが送信される。
・定期送信キュー28内のフレーム情報が0個になると(S565:YES)、マスタ1からスレーブ3へ第1モード切替フレームが送信される(S570)。すると、スレーブ3がスレーブ側第2モードからスレーブ側第1モードに遷移する。更に、マスタ1もマスタ側第2モードからマスタ側第1モードに遷移する(S575)。
《スレーブ側第2モードでのフレーム送信処理》
スレーブ3がスレーブ側第2モードの場合に、マイコン31は、フレーム送信処理として、図10に示す「スレーブ側第2モードでのフレーム送信処理」を一定時間毎に実行する。尚、図10において、図8と同じ処理のステップについては、同じステップ番号を付しているため、説明を省略する。
スレーブ3がスレーブ側第2モードの場合に、マイコン31は、フレーム送信処理として、図10に示す「スレーブ側第2モードでのフレーム送信処理」を一定時間毎に実行する。尚、図10において、図8と同じ処理のステップについては、同じステップ番号を付しているため、説明を省略する。
図10に示すように、スレーブ側第2モードでのフレーム送信処理は、図8の処理と比較すると、S420とS430との間にS425が追加されている。
マイコン31は、S420の処理を行った後、あるいは、S415にて、新規のイベントが発生していないと判定した場合には、S425に進み、マスタ1からのイベントヘッダを受信したか否かを判定する。そして、マイコン31は、イベントヘッダを受信したと判定した場合には、S430に進み、バスアイドル状態であることを確認した上でイベントフレームの送信を実施するが(S450)、イベントヘッダを受信していないと判定した場合には、そのまま当該図10の処理を終了する。
マイコン31は、S420の処理を行った後、あるいは、S415にて、新規のイベントが発生していないと判定した場合には、S425に進み、マスタ1からのイベントヘッダを受信したか否かを判定する。そして、マイコン31は、イベントヘッダを受信したと判定した場合には、S430に進み、バスアイドル状態であることを確認した上でイベントフレームの送信を実施するが(S450)、イベントヘッダを受信していないと判定した場合には、そのまま当該図10の処理を終了する。
尚、スレーブ3では、イベントヘッダを受信すると、マイコン31において、イベントヘッダの受信履歴がセットされる。そして、マイコン31は、S425では、その受信履歴がセットされているか否かにより、イベントヘッダの受信有無を判定する。また、イベントヘッダの受信履歴は、イベント送信キュー38に格納されている1つのフレーム情報が示すイベントフレームの送信が完了するか、またはイベント送信キューと再送キューが共に空の場合、消去される。
スレーブ3では、スレーブ側第2モードの場合に、マイコン31が図10の処理を実行することにより、イベントフレームの送信実施がマスタ1からのイベントヘッダによって許可されることとなる。
<実施形態の効果>
マスタ1のマイコン21が図7又は図9の処理を実行し、スレーブ3のマイコン31が図8又は図10の処理を実行することで、図5を用いて説明した通信システム11の動作が実現される。
マスタ1のマイコン21が図7又は図9の処理を実行し、スレーブ3のマイコン31が図8又は図10の処理を実行することで、図5を用いて説明した通信システム11の動作が実現される。
このため、マスタ1は、送信停滞状態になった場合には、通信システム11を第1モードから第2モードに切り替えて、滞留していた送信待ちの定期フレームを送信することができ、定期フレームをスケジュール通りに送信できる状態へと復帰することができる。また、第2モードにおいて、スレーブ3からのイベントフレームの送信は、マスタ1によって頻度が抑制されるだけであるため、イベントフレームが送信されることによる機能(この例では、マスタ1が制御する機器の動作)も確保される、このため、スレーブ3のイベント送信を実現しつつ、マスタ1による定期フレームの送信が滞ってしまうことを防止することができる。
また、通信システム11が第2モードの場合に、マスタ1は、定期フレームをスケジュール通りに送信できる状態に復帰したと判定すると、通信システム11を第1モードに戻す。このため、イベントフレームの送信応答性が高い状態に復帰することができる。
また、マスタ1からスレーブ3への第2モード切替フレームは、スレーブ3からのイベントフレームよりもバス調停における優先度が高く設定されているフレームである。このため、全てのスレーブ3に対してスレーブ側第2モードへの切り替えを確実に通知することができる。
また、マスタ1のマイコン21は、マスタ側第1モードでのフレーム送信処理(図7)では、定期送信キュー28に格納されたフレーム情報の数が、定期送信キュー28に格納可能な最大数であるN個になった場合に(S325:YES)、送信滞留状態になったと判定する。このため、通信システム11のモードを第1モードから第2モードに切り替えるべきタイミングを適切に判断することができる。尚、例えば、上記Nが3以上であれば、マイコン21は、図7のS325では、定期送信キュー28内のフレーム情報の数が、Nよりも小さい2以上の所定数になったか否かを判定し、肯定判定した場合に、送信滞留状態になったと判断するようになっていても良い。
また、マスタ1のマイコン21は、マスタ側第2モードでのフレーム送信処理(図9)では、定期送信キュー28が空になった場合に(S565:YES)、定期フレームをスケジュールの通りに送信することが可能な状態に復帰したと判定する。このため、通信システム11のモードを第2モードから第1モードに戻すべきタイミングを適切に判断することができる。
[第2実施形態]
第2実施形態の通信システムについて説明するが、通信システムの符号としては、第1実施形態と同じ“11”を用いる。また、第1実施形態と同様の構成要素や処理についても、第1実施形態と同じ符号を用いる。そして、このことは、後述する他の実施形態についても同様である。
第2実施形態の通信システムについて説明するが、通信システムの符号としては、第1実施形態と同じ“11”を用いる。また、第1実施形態と同様の構成要素や処理についても、第1実施形態と同じ符号を用いる。そして、このことは、後述する他の実施形態についても同様である。
第2実施形態の通信システム11は、第1実施形態と比較すると、マスタ1のマイコン21が、マスタ側第1モードでのフレーム送信処理として、図7の処理に代えて、図11の処理を実行する。図11の処理は、図7の処理と比較すると、S325の代わりにS327が設けられており、更に、S380,S385,S387が追加されている。
図11に示すように、マイコン21は、この図11の処理を終了する前に、S380に進む。
マイコン21は、S380では、定期送信キュー28にフレーム情報が格納されているか否かを判定し、定期送信キュー28にフレーム情報が格納されていなければ、S385に進んで、定期送信キュータイマをクリアした後、当該図11の処理を終了する。定期送信キュータイマは、定期送信キュー28にフレーム情報が格納されている継続時間を計測するためのカウンタである。
マイコン21は、S380では、定期送信キュー28にフレーム情報が格納されているか否かを判定し、定期送信キュー28にフレーム情報が格納されていなければ、S385に進んで、定期送信キュータイマをクリアした後、当該図11の処理を終了する。定期送信キュータイマは、定期送信キュー28にフレーム情報が格納されている継続時間を計測するためのカウンタである。
また、マイコン21は、S380にて、定期送信キュー28にフレーム情報が格納されていると判定した場合には、S387に進んで、定期送信キュータイマのカウントアップ(この例では+1するインクリメント)を行い、その後、当該図11の処理を終了する。
よって、定期送信キュー28にフレーム情報が格納されていれば、当該図11が実行される一定時間毎に、定期送信キュータイマの値が1ずつ増加していく。
そして、マイコン21は、図11の処理では、S315にて、新規の定期送信要求が発生していないと判定した場合、あるいは、S320にて、定期送信キュー28にフレーム情報をエンキューした後、S327に進む。
そして、マイコン21は、図11の処理では、S315にて、新規の定期送信要求が発生していないと判定した場合、あるいは、S320にて、定期送信キュー28にフレーム情報をエンキューした後、S327に進む。
マイコン21は、S327では、定期送信キュータイマの値が規定値以上になったか否かを判定する。そして、マイコン21は、定期送信キュータイマの値が規定値以上ではないと判定した場合には、S330に進むが、定期送信キュータイマの値が規定値以上であると判定した場合には、送信滞留状態になったと判断してS365に進む。
つまり、マイコン21は、定期送信キュー28にフレーム情報が格納されている継続時間を計測し(S380〜S387)、その継続時間の計測値に相当する定期送信キュータイマの値が規定時間以上になった場合に、送信滞留状態になったと判定して、通信システム11の第2モードへの切り替えを実施する。そして、このような第2実施形態によっても、通信システム11のモードを第1モードから第2モードに切り替えるべきタイミングを適切に判断することができる。
[第3実施形態]
第3実施形態の通信システム11は、第1実施形態と比較すると、マスタ1のマイコン21が、マスタ側第1モードでのフレーム送信処理として、図7の処理に代えて、図12の処理を実行する。図12の処理は、図7の処理と比較すると、S325の代わりにS328が設けられており、更に、S390,S395,S397が追加されている。
第3実施形態の通信システム11は、第1実施形態と比較すると、マスタ1のマイコン21が、マスタ側第1モードでのフレーム送信処理として、図7の処理に代えて、図12の処理を実行する。図12の処理は、図7の処理と比較すると、S325の代わりにS328が設けられており、更に、S390,S395,S397が追加されている。
図12に示すように、マイコン21は、この図12の処理を終了する前に、S390に進む。
マイコン21は、S390では、送信スケジュールで定められた1スケジュール分の定期フレームの送信が完了したか否かを判定する。具体的には、マイコン21は、S350の送信処理が今回実施され、且つ、その今回の送信処理により送信スケジュールにおける最後の定期フレーム(図3におけるNo23のフレーム〈5〉)の送信が完了したか否かを判定する。
マイコン21は、S390では、送信スケジュールで定められた1スケジュール分の定期フレームの送信が完了したか否かを判定する。具体的には、マイコン21は、S350の送信処理が今回実施され、且つ、その今回の送信処理により送信スケジュールにおける最後の定期フレーム(図3におけるNo23のフレーム〈5〉)の送信が完了したか否かを判定する。
そして、マイコン21は、S390にて、1スケジュール分の定期フレームの送信が完了していないと判定した場合には、S397に進んで、スケジュール計測タイマのカウントアップ(この例では+1するインクリメント)を行い、その後、当該図12の処理を終了する。尚、スケジュール計測タイマは、送信スケジュールで定められた1スケジュール分の定期フレームの送信が完了するのに要する時間(以下、1スケジュール分の送信所要時間という)を計測するためのカウンタである。そして、スケジュール計測タイマは、マイコン21が起動してから、送信スケジュールにおける最初の定期フレームの送信タイミングが最初に到来したとき(つまり、送信スケジュールの1回目の開始時)にクリアされる。
また、マイコン21は、S390にて、1スケジュール分の定期フレームの送信が完了したと判定した場合には、S395に進んで、スケジュール計測タイマをクリアした後、当該図12の処理を終了する。尚、マイコン21は、S395において、次のスケジュールにおける最初の定期フレームの送信タイミングが既に到来していた場合には、その到来していた最初の定期フレームの送信タイミングから現在までの経過時間に相当する分の値を、スケジュール計測タイマにプリセットしても良い。
そして、マイコン21は、図12の処理では、S315にて、新規の定期送信要求が発生していないと判定した場合、あるいは、S320にて、定期送信キュー28にフレーム情報をエンキューした後、S328に進む。
マイコン21は、S328では、スケジュール計測タイマの値が規定値以上になったか否かを判定する。そして、マイコン21は、スケジュール計測タイマの値が規定値以上ではないと判定した場合には、S330に進むが、スケジュール計測タイマの値が規定値以上であると判定した場合には、送信滞留状態になったと判断してS365に進む。尚、S328での判定に用いる規定値は、送信スケジュールの1スケジュール時間(即ち、図2における「スケジュール開始」から「スケジュール終了」までの時間)よりも長い時間に相当する値に設定されている。
つまり、マイコン21は、1スケジュール分の送信所要時間を計測し(S390〜S397)、その1スケジュール分の送信所要時間の計測値に相当するスケジュール計測タイマの値が規定値以上になった場合に、送信滞留状態になったと判定して、通信システム11の第2モードへの切り替えを実施する。調停負けによって送信待ちの定期フレームが複数滞留すると、1スケジュール分の送信所要時間が長くなるからである。そして、このような第3実施形態によっても、通信システム11のモードを第1モードから第2モードに切り替えるべきタイミングを適切に判断することができる。
[第4実施形態]
第4実施形態の通信システム11は、第1〜第3実施形態と比較すると、マスタ1のマイコン21が、マスタ側第2モードでのフレーム送信処理として、図9の処理に代えて、図13の処理を実行する。図13の処理は、図9の処理と比較すると、S566,S567が追加されている。
第4実施形態の通信システム11は、第1〜第3実施形態と比較すると、マスタ1のマイコン21が、マスタ側第2モードでのフレーム送信処理として、図9の処理に代えて、図13の処理を実行する。図13の処理は、図9の処理と比較すると、S566,S567が追加されている。
図13に示すように、マイコン21は、S565にて、定期送信キュー28が空であると判定した場合には、S566に進み、バスアイドル状態であることを確認した上で、S555と同様にイベントヘッダの送信を実施する。
そして、マイコン21は、次のS567にて、スレーブ3からのイベントフレームを所定時間以内に受信したか否かを判定し、イベントフレームを受信した場合には、そのまま当該図13の処理を終了する。また、マイコン21は、S567にて、スレーブ3からのイベントフレームを受信しないと判定した場合には、送信滞留状態から正常状態に復帰したと判断して、S570に進む。
つまり、マイコン21は、定期送信キュー28が空になった場合に(S565:YES)、イベントヘッダの送信を実施して(S566)、スレーブ3がイベントフレームを送信しないことを確認したならば(S567:NO)、正常状態に復帰したと判定して、通信システム11の第1モードへの切り替えを実施するようになっている。
このような第4実施形態によれば、スレーブ3においてイベントが発生しておらず送信すべきイベントフレームがないことを確認した上で、通信システム11を第1モードに戻すことができる。つまり、ある程度の時間は定期送信を正常に実施し続けることができると予想される状況であることを確認した上で、通信システム11を第1モードに戻すことができる。
[第5実施形態]
第5実施形態の通信システム11は、第1〜第3実施形態と比較すると、スレーブ3のマイコン31が、スレーブ側第2モードでのフレーム送信処理として、図10の処理に代えて、図14の処理を実行する。更に、マスタ1のマイコン21が、マスタ側第2モードでのフレーム送信処理として、図9の処理に代えて、図15の処理を実行する。
第5実施形態の通信システム11は、第1〜第3実施形態と比較すると、スレーブ3のマイコン31が、スレーブ側第2モードでのフレーム送信処理として、図10の処理に代えて、図14の処理を実行する。更に、マスタ1のマイコン21が、マスタ側第2モードでのフレーム送信処理として、図9の処理に代えて、図15の処理を実行する。
まず、図14の処理は、図10の処理と比較すると、S431,S432が追加されている。
図14に示すように、スレーブ3のマイコン31は、S430にて、バスアイドル状態であると判定した場合には、S431に進み、イベント送信キュー38がフルになったか否か(つまり、イベント送信キュー38に格納されたフレーム情報の数が、最大数のM個になったか否か)を判定する。マイコン31は、イベント送信キュー38がフルになっていないと判定した場合には、既述したS435に進むが、イベント送信キュー38がフルになったと判定した場合には、S432に進む。
図14に示すように、スレーブ3のマイコン31は、S430にて、バスアイドル状態であると判定した場合には、S431に進み、イベント送信キュー38がフルになったか否か(つまり、イベント送信キュー38に格納されたフレーム情報の数が、最大数のM個になったか否か)を判定する。マイコン31は、イベント送信キュー38がフルになっていないと判定した場合には、既述したS435に進むが、イベント送信キュー38がフルになったと判定した場合には、S432に進む。
そして、マイコン31は、S432では、イベント送信キュー38内のフレーム情報の数が所定数(この例ではM個)になったことを示すフレームであるキュー通知を、マスタ1へ送信するための送信処理を実施し、その後、当該図14の処理を終了する。尚、キュー通知のバス調停における優先度は、マスタ1からの定期フレームよりも高く設定しておくことができる。また、キュー通知のバス調停における優先度が、マスタ1からの定期フレームよりも低く設定されていても、マスタ1から定期フレームが送信されていないバスアイドル状態のときに、S432の処理が実行されれば、マスタ1にキュー通知が伝達されることとなる。
一方、図15の処理は、図9の処理と比較すると、S563が追加されている。
図15に示すように、マスタ1のマイコン21は、S520又はS535で「NO」と判定した場合、あるいは、S550又はS560の処理を実行した後に、S565ではなく、S563に進む。
図15に示すように、マスタ1のマイコン21は、S520又はS535で「NO」と判定した場合、あるいは、S550又はS560の処理を実行した後に、S565ではなく、S563に進む。
そして、マイコン21は、S563にて、スレーブ3からのキュー通知を受信したか否かを判定し、キュー通知を受信していないと判定した場合には、当該図15の処理を終了するが、キュー通知を受信したと判定したと判定した場合には、S565に進む。
つまり、マイコン21は、スレーブ3からのキュー通知を受信し、且つ、定期送信キュー28が空になった場合に、送信滞留状態から正常状態に復帰したと判定して、通信システム11の第1モードへの切り替えを実施するようになっている。
このような第5実施形態によれば、第2モードから第1モードへの復帰を、スレーブ3において送信待ちのイベントフレームが所定数滞留するまで遅らせて、定期送信の正常化を最優先させることができる。
尚、例えば、上記M(イベント送信キュー38に格納可能なフレーム情報の最大数)が3以上であれば、スレーブ3のマイコン31は、図14のS431では、イベント送信キュー38内のフレーム情報の数が、Mよりも小さい2以上の所定数になったか否かを判定し、肯定判定した場合にS432へ進むようになっていても良い。
以上、本発明の実施形態について説明したが、本発明は上記実施形態に限定されることなく、種々の形態を採り得る。また、前述の数値も一例であり他の値でも良い。例えば、本発明は、車載用の通信システム以外についても適用することができる。
また、上記実施形態における1つの構成要素が有する機能を複数の構成要素として分散させたり、複数の構成要素が有する機能を1つの構成要素に統合させたりしてもよい。また、上記実施形態の構成の少なくとも一部を、同様の機能を有する公知の構成に置き換えてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加又は置換してもよい。なお、特許請求の範囲に記載した文言によって特定される技術思想に含まれるあらゆる態様が本発明の実施形態である。また、上述したマスタ1又はスレーブ3としてコンピュータを機能させるためのプログラム、このプログラムを記録した媒体、通信システムのモード切替方法など、種々の形態で本発明を実現することもできる。
1…マスタノード(マスタ)、3…スレーブノード(スレーブ)、5…バス、11…通信システム、21,31…マイコン
Claims (14)
- バス(5)を介して接続された複数のノード(1,3)が、前記バスに送信するフレームの先頭部分であるヘッダを用いたバス調停を実施すると共に、送信しようとして調停負けしたフレームの再送信を新規のフレームの送信よりも優先して実施し、
前記複数のノードのうちの1つは、予め設定されたスケジュールに従って、定期的に送信すべきフレームである定期フレームの送信を実施するマスタノード(1)であり、
前記複数のノードのうち、前記マスタノード以外のノードは、予め定められたイベントが発生した場合に、そのイベントに関連する情報を含むフレームであるイベントフレームの送信を実施するスレーブノード(3)であり、
バス調停における優先度が、前記定期フレームよりも前記イベントフレームの方が高く設定されている通信システム(11)において、
前記マスタノードの動作モードとしては、前記スケジュールに従って前記定期フレームの送信を実施する基本モードとしてのマスタ側第1モードと、前記定期フレームを送信する合間に前記スレーブノードに対する送信許可通知を送信するマスタ側第2モードと、があり、
前記スレーブノードの動作モードとしては、前記イベントが発生した場合に自律的に前記イベントフレームの送信を実施する基本モードとしてのスレーブ側第1モードと、前記イベントが発生し且つ前記マスタノードからの前記送信許可通知を受信した場合に前記イベントフレームの送信を実施するスレーブ側第2モードと、があり、
前記マスタノードは、前記スレーブノードの動作モードが前記スレーブ側第1モードになっていると共に、当該マスタノードの動作モードが前記マスタ側第1モードになっている場合に動作する手段として、
送信を試みた前記定期フレームが前記イベントフレームに調停負けしたことに伴って、送信待ちの前記定期フレームが溜まってしまった送信滞留状態になったか否かを判定する状態判定手段(S325,S327,S328)と、
前記状態判定手段により肯定判定された場合に、前記スレーブノードに対して前記スレーブ側第2モードへの切り替えを指令するための第2モード切替指令を送信する第2モード切替指令手段(S365)と、
前記第2モード切替指令手段が前記第2モード切替指令を送信した場合に、当該マスタノードの動作モードを、前記マスタ側第1モードから前記マスタ側第2モードに切り替えるマスタ側第2モード切替手段(S370)と、を備え、
前記スレーブノードは、
当該スレーブノードの動作モードが前記スレーブ側第1モードである場合に、当該スレーブノードが前記第2モード切替指令を受信すると、当該スレーブノードの動作モードを、前記スレーブ側第1モードから前記スレーブ側第2モードに切り替えるスレーブ側第2モード切替手段(S230)、を備えること、
を特徴とする通信システム。 - 請求項1に記載の通信システムにおいて、
前記第2モード切替指令は、前記イベントフレームよりも、バス調停における優先度が高く設定されているフレームであること、
を特徴とする通信システム。 - 請求項1又は請求項2に記載の通信システムにおいて、
前記マスタノードは、
前記スケジュールに基づく送信タイミングが到来したものの、送信が未実施である前記定期フレームを示す情報が格納される定期送信キューを備え、
前記状態判定手段(S325)は、前記定期送信キューに格納された前記情報の数が所定数になった場合に、前記送信滞留状態になったと判定すること、
を特徴とする通信システム。 - 請求項1又は請求項2に記載の通信システムにおいて、
前記マスタノードは、
前記スケジュールに基づく送信タイミングが到来したものの、送信が未実施である前記定期フレームを示す情報が格納される定期送信キューと、
前記定期送信キューに前記情報が格納されている継続時間を計測する継続時間計測手段(S380,S385,S387)と、を備え、
前記状態判定手段(S327)は、前記継続時間計測手段による計測値が規定値以上になった場合に、前記送信滞留状態になったと判定すること、
を特徴とする通信システム。 - 請求項1又は請求項2に記載の通信システムにおいて、
前記マスタノードは、
前記スケジュールで定められた1スケジュール分の前記定期フレームの送信が完了するのに要する時間を計測する所要時間計測手段(S390,S395,S397)を備え、
前記状態判定手段(S328)は、前記所要時間計測手段による計測値が規定値以上になった場合に、前記送信滞留状態になったと判定すること、
を特徴とする通信システム。 - 請求項1ないし請求項5の何れか1項に記載の通信システムにおいて、
前記マスタノードは、前記スレーブノードの動作モードが前記スレーブ側第2モードになっていると共に、当該マスタノードの動作モードが前記マスタ側第2モードになっている場合に動作する手段として、
前記定期フレームを前記スケジュールの通りに送信することが可能な状態に復帰したか否かを判定する復帰判定手段(S563,S565,S566,S567)と、
前記復帰判定手段により肯定判定された場合に、前記スレーブノードに対して前記スレーブ側第1モードへの切り替えを指令するための第1モード切替指令を送信する第1モード切替指令手段(S570)と、
前記第1モード切替指令手段が前記第1モード切替指令を送信した場合に、当該マスタノードの動作モードを、前記マスタ側第2モードから前記マスタ側第1モードに切り替えるマスタ側第1モード切替手段(S575)と、を備え、
前記スレーブノードは、
当該スレーブノードの動作モードが前記スレーブ側第2モードである場合に、当該スレーブノードが前記第1モード切替指令を受信すると、当該スレーブノードの動作モードを、前記スレーブ側第2モードから前記スレーブ側第1モードに切り替えるスレーブ側第1モード切替手段(S250)、を備えること、
を特徴とする通信システム。 - 請求項6に記載の通信システムにおいて、
前記マスタノードは、
前記スケジュールに基づく送信タイミングが到来したものの、送信が未実施である前記定期フレームを示す情報が格納される定期送信キューを備え、
前記復帰判定手段(S565)は、前記定期送信キューが空になった場合に、前記定期フレームを前記スケジュールの通りに送信することが可能な状態に復帰したと判定すること、
を特徴とする通信システム。 - 請求項7に記載の通信システムにおいて、
前記復帰判定手段(S565,S566,S567)は、前記定期送信キューが空になった場合に、前記送信許可通知の送信を実施して、前記スレーブノードが前記イベントフレームを送信しないことを確認したならば、前記定期フレームを前記スケジュールの通りに送信することが可能な状態に復帰したと判定すること、
を特徴とする通信システム。 - 請求項7に記載の通信システムにおいて、
前記スレーブノードは、
前記イベントが発生したものの、送信が未実施である前記イベントフレームを示す情報が格納されるイベント送信キューと、
前記イベント送信キューに格納された前記情報の数が所定数になった場合に、そのことを示すキュー通知を前記マスタノードへ送信する通知手段(S432)と、を備え、
前記マスタノードの前記復帰判定手段(S563,S565)は、当該マスタノードが前記スレーブノードからの前記キュー通知を受信し、且つ、前記定期送信キューが空になった場合に、前記定期フレームを前記スケジュールの通りに送信することが可能な状態に復帰したと判定すること、
を特徴とする通信システム。 - 請求項1ないし請求項9の何れか1項に記載の通信システムにおいて、
当該通信システムが起動してから最初の前記マスタノードの動作モードは、前記マスタ側第1モードであり、当該通信システムが起動してから最初の前記スレーブノードの動作モードは、前記スレーブ側第1モードであること、
を特徴とする通信システム。 - バス(5)を介して接続された複数のノード(1,3)が、前記バスに送信するフレームの先頭部分であるヘッダを用いたバス調停を実施すると共に、送信しようとして調停負けしたフレームの再送信を新規のフレームの送信よりも優先して実施し、
前記複数のノードのうちの1つは、予め設定されたスケジュールに従って、定期的に送信すべきフレームである定期フレームの送信を実施するマスタノード(1)であり、
前記複数のノードのうち、前記マスタノード以外のノードは、予め定められたイベントが発生した場合に、そのイベントに関連する情報を含むフレームであるイベントフレームの送信を実施するスレーブノード(3)であり、
バス調停における優先度が、前記定期フレームよりも前記イベントフレームの方が高く設定されている通信システム(11)において、
前記マスタノードとして使用されるノードであって、
当該ノードの動作モードとしては、前記スケジュールに従って前記定期フレームの送信を実施する基本モードとしてのマスタ側第1モードと、前記定期フレームを送信する合間に前記スレーブノードに対する送信許可通知を送信するマスタ側第2モードと、があり、
当該ノードの動作モードが前記マスタ側第1モードになっている場合に動作する手段として、
送信を試みた前記定期フレームが前記イベントフレームに調停負けしたことに伴って、送信待ちの前記定期フレームが溜まってしまった送信滞留状態になったか否かを判定する状態判定手段(S325,S327,S328)と、
前記状態判定手段により肯定判定された場合に、前記スレーブノードに対して、前記スレーブノードの動作モードを、前記イベントが発生した場合に自律的に前記イベントフレームの送信を実施するスレーブ側第1モードから、前記イベントが発生し且つ前記送信許可通知を受信した場合に前記イベントフレームの送信を実施するスレーブ側第2モードへと切り替えさせるための第2モード切替指令を送信する第2モード切替指令手段(S365)と、
前記第2モード切替指令手段が前記第2モード切替指令を送信した場合に、当該ノードの動作モードを、前記マスタ側第1モードから前記マスタ側第2モードに切り替えるマスタ側第2モード切替手段(S370)と、を備えること、
を特徴とするノード。 - 請求項11に記載のノードにおいて、
当該ノードの動作モードが前記マスタ側第2モードになっている場合に動作する手段として、
前記定期フレームを前記スケジュールの通りに送信することが可能な状態に復帰したか否かを判定する復帰判定手段(S563,S565,S566,S567)と、
前記復帰判定手段により肯定判定された場合に、前記スレーブノードに対して前記スレーブ側第1モードへの切り替えを指令するための第1モード切替指令を送信する第1モード切替指令手段(S570)と、
前記第1モード切替指令手段が前記第1モード切替指令を送信した場合に、当該ノードの動作モードを、前記マスタ側第2モードから前記マスタ側第1モードに切り替えるマスタ側第1モード切替手段(S575)と、を備えること、
を特徴とするノード。 - バス(5)を介して接続された複数のノード(1,3)が、前記バスに送信するフレームの先頭部分であるヘッダを用いたバス調停を実施すると共に、送信しようとして調停負けしたフレームの再送信を新規のフレームの送信よりも優先して実施し、
前記複数のノードのうちの1つは、予め設定されたスケジュールに従って、定期的に送信すべきフレームである定期フレームの送信を実施するマスタノード(1)であり、
前記複数のノードのうち、前記マスタノード以外のノードは、予め定められたイベントが発生した場合に、そのイベントに関連する情報を含むフレームであるイベントフレームの送信を実施するスレーブノード(3)であり、
バス調停における優先度が、前記定期フレームよりも前記イベントフレームの方が高く設定されている通信システム(11)において、
前記スレーブノードとして使用されるノードであって、
当該ノードの動作モードとしては、前記イベントが発生した場合に自律的に前記イベントフレームの送信を実施する基本モードとしてのスレーブ側第1モードと、前記イベントが発生し且つ前記マスタノードからの送信許可通知を受信した場合に前記イベントフレームの送信を実施するスレーブ側第2モードと、があり、
当該ノードの動作モードが前記スレーブ側第1モードである場合に、当該ノードが前記マスタノードから送信される第2モード切替指令を受信すると、当該ノードの動作モードを、前記スレーブ側第1モードから前記スレーブ側第2モードに切り替えるスレーブ側第2モード切替手段(S230)、を備えること、
を特徴とするノード。 - 請求項13に記載のノードにおいて、
当該ノードの動作モードが前記スレーブ側第2モードである場合に、当該ノードが前記マスタノードから送信される第1モード切替指令を受信すると、当該ノードの動作モードを、前記スレーブ側第2モードから前記スレーブ側第1モードに切り替えるスレーブ側第1モード切替手段(S250)、を備えること、
を特徴とするノード。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014208937A JP2016082296A (ja) | 2014-10-10 | 2014-10-10 | 通信システム及びノード |
DE102015219587.2A DE102015219587A1 (de) | 2014-10-10 | 2015-10-09 | Kommunikationssystem und Netzwerkknoten |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014208937A JP2016082296A (ja) | 2014-10-10 | 2014-10-10 | 通信システム及びノード |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2016082296A true JP2016082296A (ja) | 2016-05-16 |
Family
ID=55644362
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014208937A Pending JP2016082296A (ja) | 2014-10-10 | 2014-10-10 | 通信システム及びノード |
Country Status (2)
Country | Link |
---|---|
JP (1) | JP2016082296A (ja) |
DE (1) | DE102015219587A1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020150444A (ja) * | 2019-03-14 | 2020-09-17 | パナソニックIpマネジメント株式会社 | 通信装置および通信システム |
-
2014
- 2014-10-10 JP JP2014208937A patent/JP2016082296A/ja active Pending
-
2015
- 2015-10-09 DE DE102015219587.2A patent/DE102015219587A1/de not_active Withdrawn
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020150444A (ja) * | 2019-03-14 | 2020-09-17 | パナソニックIpマネジメント株式会社 | 通信装置および通信システム |
JP7165882B2 (ja) | 2019-03-14 | 2022-11-07 | パナソニックIpマネジメント株式会社 | 通信装置および通信システム |
Also Published As
Publication number | Publication date |
---|---|
DE102015219587A1 (de) | 2016-04-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5510275B2 (ja) | 通信システム、マスタノード、スレーブノード | |
JP4766160B2 (ja) | 通信システムおよび通信ノード | |
US10404721B2 (en) | Communication device for detecting transmission of an improper message to a network | |
JP4683346B2 (ja) | マスタ・スレーブ通信システムおよびマスタ・スレーブ通信方法 | |
US20090080455A1 (en) | Systems and methods for reducing data collisions in wireless network communications | |
US10873591B2 (en) | Device and method for detecting attack in network | |
CN104956626A (zh) | 网络装置以及数据收发系统 | |
JP5811140B2 (ja) | 通信システム | |
JP2011040886A (ja) | 診断装置および診断システム | |
US9197373B2 (en) | Method, apparatus, and system for retransmitting data packet in quick path interconnect system | |
JP2012080360A (ja) | 通信システム、マスタノード、スレーブノード | |
JP2009253557A (ja) | 車載用の中継接続ユニット | |
JPWO2017154828A1 (ja) | 通信システム | |
JP2013106200A (ja) | 車両用通信中継装置、スリープ制御方法 | |
JP2016082296A (ja) | 通信システム及びノード | |
WO2010102551A1 (zh) | 应用于mp组的报文处理方法及装置 | |
JP5510192B2 (ja) | 通信装置 | |
JP6028717B2 (ja) | 通信システムおよびゲートウェイ装置並びに通信方法 | |
US8989203B2 (en) | Electronic device, communication control method, and recording medium | |
JP5123968B2 (ja) | 通信制御方法、通信制御プログラムおよびマスタ通信装置 | |
US7406531B2 (en) | Method and communication system for data exchange among multiple users interconnected over a bus system | |
JP2009171310A (ja) | 通信装置、及び通信装置における故障判定方法 | |
JP4826405B2 (ja) | ネットワークシステム,ネットワークデバイスおよびプログラム | |
JP6365876B2 (ja) | ノード | |
JP2008005342A (ja) | 制御コントローラ |