(57)【要約】【課題】処理装置が、より確実に特定のデータの中継をゲートウェイ装置に行わせること。【解決手段】ゲートウェイ装置がデータを中継し、優先度に基づく通信調停が行われる複数のバスのうち一のバスにデータを出力する出力部と、前記出力部を制御する制御部であって、前記出力部に、前記ゲートウェイ装置を通過する特定のデータを前記バスに出力させる際に、前記ゲートウェイ装置を通過しないダミーデータを前記バスに出力させる制御部と、を備える処理装置。【選択図】図７
2014036417.tif 000002
【特許請求の範囲】
【請求項１】
ゲートウェイ装置がデータを中継し、優先度に基づく通信調停が行われる複数のバスのうち一のバスにデータを出力する出力部と、
前記出力部を制御する制御部であって、前記出力部に、前記ゲートウェイ装置を通過する特定のデータを前記バスに出力させる際に、前記ゲートウェイ装置を通過しないダミーデータを前記バスに出力させる制御部と、
を備える処理装置。
【請求項２】
請求項１記載の処理装置であって、
前記ダミーデータは、固定の優先度を有するものとして前記バスに出力される、
処理装置。
【請求項３】
請求項１又は２記載の処理装置であって、
前記ダミーデータは、前記出力部がデータを出力するバスを流れるデータの中で、最高優先度を有するものとして前記バスに出力される、
処理装置。
【請求項４】
請求項１ないし３のいずれか１項記載の処理装置であって、
前記制御部は、前記出力部に、前記ゲートウェイ装置を通過しないダミーデータを、前記特定のデータの前後に前記バスに出力させる、
処理装置。
【請求項５】
請求項１ないし３のいずれか１項記載の処理装置であって、
前記制御部は、前記出力部に、前記ゲートウェイ装置を通過しないダミーデータを、前記特定のデータの前に前記バスに出力させる、
処理装置。
【請求項６】
請求項１ないし３のいずれか１項記載の処理装置であって、
前記制御部は、前記出力部に、前記ゲートウェイ装置を通過しないダミーデータを、前記特定のデータの後に前記バスに出力させる、
処理装置。
【請求項７】
ゲートウェイ装置がデータを中継し、優先度に基づく通信調停が行われる複数のバスのうち一のバスに接続された処理装置であって、
規定回数以上、バスへのデータの出力ができなかった場合に、前記バスに流れるデータがゲートウェイ装置を通過しないダミーデータであるか否かを判定し、前記バスに流れるデータがゲートウェイ装置を通過しないダミーデータでない場合には通信に関する設定を初期化する処理を行い、前記バスに流れるデータがゲートウェイ装置を通過しないダミーデータである場合には前記通信に関する設定を初期化する処理を行わない、
処理装置。
【請求項８】
複数のバスと、
前記複数のバスを中継するゲートウェイ装置と、
前記複数のバスのいずれかに接続され、優先度による通信調停を行って前記バスにデータを出力する複数の処理装置と、
を備え、
前記複数の処理装置のうち少なくとも一部は、前記ゲートウェイ装置を通過する特定のデータを前記バスに出力する際に、前記ゲートウェイ装置を通過しないダミーデータを前記バスに出力する、
ネットワークシステム。
【請求項９】
請求項８記載のネットワークシステムであって、
前記複数の処理装置のうち少なくとも一部は、規定回数以上、バスへのデータの出力ができなかった場合に、前記バスに流れるデータが前記ゲートウェイ装置を通過しないダミーデータであるか否かを判定し、前記バスに流れるデータが前記ゲートウェイ装置を通過しないダミーデータでない場合には通信に関する設定を初期化する処理を行い、前記バスに流れるデータが前記ゲートウェイ装置を通過しないダミーデータである場合には前記通信に関する設定を初期化する処理を行わない、
ネットワークシステム。
【請求項１０】
ゲートウェイ装置がデータを中継し、優先度に基づく通信調停が行われる複数のバスのうち一のバスに接続された処理装置に、
バスに出力しようとするデータが、前記ゲートウェイ装置を通過する特定のデータであるか否かを判定させ、
前記バスに出力しようとするデータが、前記ゲートウェイ装置を通過する特定のデータである場合に、前記ゲートウェイ装置を通過しないダミーデータを前記バスに出力させる、
通信制御プログラム。
【請求項１１】
ゲートウェイ装置がデータを中継し、優先度に基づく通信調停が行われる複数のバスのうち一のバスに接続された処理装置に、
規定回数以上、バスへのデータの出力ができなかった場合に、前記バスに流れるデータがゲートウェイ装置を通過しないダミーデータであるか否かを判定させ、
前記バスに流れるデータがゲートウェイ装置を通過しないダミーデータでない場合には通信に関する設定を初期化する処理を行わせ、前記バスに流れるデータがゲートウェイ装置を通過しないダミーデータである場合には前記通信に関する設定を初期化する処理を行わせない、
通信制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、処理装置、ネットワークシステム、及び通信制御プログラムに関する。
【背景技術】
【０００２】
従来、ＥＣＵ（Electronic  Control  Unit）等の処理装置が複数個、バスに接続された構成のネットワークシステムが普及している。こうしたネットワークシステムにおける複数のＥＣＵは、それぞれが自己に割り当てられた情報処理を行い、処理結果をバスに出力して他のＥＣＵに提供することができる。
【０００３】
また、ネットワークシステムにおいて、通信速度やプロトコルが異なる（これらが同じであることもあり得る）バスが二系統以上存在する場合に、それぞれのバスに接続された処理装置群の通信を中継するゲートウェイ装置が知られている。
【０００４】
これに関連し、優先度による調停が行われるバスに接続されたゲートウェイ装置が知られている（例えば、特許文献１参照）。このゲートウェイ装置は、原則としてＩＤコードの優先度に従ってデータをバスに出力するが、優先度の低いデータについても待ち時間が設定時間を超過した場合には優先的に出力する処理を行う。
【０００５】
また、ネットワーク間を接続するネットワーク接続装置が知られている（例えば、特許文献２参照）。このネットワーク接続装置は、ネットワーク１からネットワーク２にデータを中継しようとする際に、自己のバッファの残り量が設定値よりも少なくなると、ネットワーク１にダミーデータを送出して、ネットワーク２に中継すべきデータの入力を抑止し、バッファあふれを防止する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００７−３６９０７号公報
【特許文献２】特開平８−３２８９８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記各特許文献に記載の技術は、ゲートウェイ装置自己が、データの中継を、より確実に行うためのものであり、ゲートウェイ装置に中継を依頼する処理装置側で何らかの動作を行うものではない。このため、処理装置が、例えば特定のデータを通常のデータよりも確実に、ゲートウェイ装置に中継させる必要があったとしても、処理装置側で何らかのアクションを起こすことができない。
【０００８】
一つの側面によれば、処理装置が、より確実に特定のデータの中継をゲートウェイ装置に行わせることを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するための本発明の一態様は、
ゲートウェイ装置がデータを中継し、優先度に基づく通信調停が行われる複数のバスのうち一のバスにデータを出力する出力部と、
前記出力部を制御する制御部であって、前記出力部に、前記ゲートウェイ装置を通過する特定のデータを前記バスに出力させる際に、前記ゲートウェイ装置を通過しないダミーデータを前記バスに出力させる制御部と、
を備える処理装置である。
【００１０】
この本発明の一態様によれば、処理装置が、より確実に特定のデータの中継をゲートウェイ装置に行わせることができる。
【００１１】
本発明の一態様において、
前記ダミーデータは、固定の優先度を有するものとして前記バスに出力されるものとしてもよい。
【００１２】
この場合、
前記ダミーデータは、前記出力部がデータを出力するバスを流れるデータの中で、最高優先度を有するものとして前記バスに出力されるものとしてもよい。
【００１３】
本発明の一態様において、
前記制御部は、前記出力部に、前記ゲートウェイ装置を通過しないダミーデータを、前記特定のデータの前後に前記バスに出力させるものとしてもよいし、前記制御部は、前記出力部に、前記ゲートウェイ装置を通過しないダミーデータを、前記特定のデータの前に前記バスに出力させるものとしてもよいし、前記制御部は、前記出力部に、前記ゲートウェイ装置を通過しないダミーデータを、前記特定のデータの後に前記バスに出力させるものとしてもよい。
【００１４】
本発明の他の態様は、
ゲートウェイ装置がデータを中継し、優先度に基づく通信調停が行われる複数のバスのうち一のバスに接続された処理装置であって、
規定回数以上、バスへのデータの出力ができなかった場合に、前記バスに流れるデータがゲートウェイ装置を通過しないダミーデータであるか否かを判定し、前記バスに流れるデータがゲートウェイ装置を通過しないダミーデータでない場合には通信に関する設定を初期化する処理を行い、前記バスに流れるデータがゲートウェイ装置を通過しないダミーデータである場合には前記通信に関する設定を初期化する処理を行わない、
処理装置である。
【００１５】
また、本発明の他の態様は、
複数のバスと、
前記複数のバスを中継するゲートウェイ装置と、
前記複数のバスのいずれかに接続され、優先度による通信調停を行って前記バスにデータを出力する複数の処理装置と、
を備え、
前記複数の処理装置のうち少なくとも一部は、前記ゲートウェイ装置を通過する特定のデータを前記バスに出力する際に、前記ゲートウェイ装置を通過しないダミーデータを前記バスに出力する、
ネットワークシステムである。
【００１６】
この場合、
前記複数の処理装置のうち少なくとも一部は、規定回数以上、バスへのデータの出力ができなかった場合に、前記バスに流れるデータが前記ゲートウェイ装置を通過しないダミーデータであるか否かを判定し、前記バスに流れるデータが前記ゲートウェイ装置を通過しないダミーデータでない場合には通信に関する設定を初期化する処理を行い、前記バスに流れるデータが前記ゲートウェイ装置を通過しないダミーデータである場合には前記通信に関する設定を初期化する処理を行わないものとしてもよい。
【００１７】
また、本発明の他の態様は、
ゲートウェイ装置がデータを中継し、優先度に基づく通信調停が行われる複数のバスのうち一のバスに接続された処理装置に、
バスに出力しようとするデータが、前記ゲートウェイ装置を通過する特定のデータであるか否かを判定させ、
前記バスに出力しようとするデータが、前記ゲートウェイ装置を通過する特定のデータである場合に、前記ゲートウェイ装置を通過しないダミーデータを前記バスに出力させる、
通信制御プログラムである。
【００１８】
また、本発明の他の態様は、
ゲートウェイ装置がデータを中継し、優先度に基づく通信調停が行われる複数のバスのうち一のバスに接続された処理装置に、
規定回数以上、バスへのデータの出力ができなかった場合に、前記バスに流れるデータがゲートウェイ装置を通過しないダミーデータであるか否かを判定させ、
前記バスに流れるデータがゲートウェイ装置を通過しないダミーデータでない場合には通信に関する設定を初期化する処理を行わせ、前記バスに流れるデータがゲートウェイ装置を通過しないダミーデータである場合には前記通信に関する設定を初期化する処理を行わせない、
通信制御プログラムである。
【発明の効果】
【００１９】
一実施態様によれば、処理装置が、より確実に特定のデータの中継をゲートウェイ装置に行わせることができる。
【図面の簡単な説明】
【００２０】
【図１】一実施例に係るネットワークシステム１の構成例である。
【図２】ＥＣＵ３０の構成例である。
【図３】各ＥＣＵがバスに出力するフレームの形式例である。
【図４】ゲートウェイ装置４０の構成例である。
【図５】ゲートウェイ装置４０内においてフレームが滞留するという現象を模式的に示す図である。
【図６】特定のフレームＦ*の前後にダミーフレームＤＦがバスに出力される様子を示す図である。
【図７】ダミーフレームの出力に関してＥＣＵ３０により実行される処理の流れを示すフローチャートである。
【図８】通信イニシャライズ処理に関してＥＣＵ３０により実行される処理の流れを示すフローチャートである。
【図９】通信イニシャライズ処理に関してＥＣＵ３０により実行される処理の流れを示すフローチャートの他の例である。
【発明を実施するための形態】
【００２１】
以下、本発明を実施するための形態について、添付図面を参照しながら実施例を挙げて説明する。
【実施例】
【００２２】
以下、図面を参照し、本発明の処理装置、ネットワークシステム、及び通信制御プログラムの実施例について説明する。
【００２３】
［全体構成］
図１は、一実施例に係るネットワークシステム１の構成例である。ネットワークシステム１は、バス１０に接続されたＥＣＵ３０＃０、３０＃１と、バス２０に接続されたＥＣＵ３０＃２、３０＃３、３０＃４と、バス１０及びバス２０に接続されたゲートウェイ装置４０とを備える。なお、特許請求の範囲における「処理装置」は、例えば「ＥＣＵ」に対応する。
【００２４】
バス１０及びバス２０では、例えば、ＣＡＮ（Controller  Area  Network）に基づく通信が行われ、各ＥＣＵは、バスを流れるデータを取得することができる。バス１０及びバス２０は、例えば、ツイストペアケーブルであり、差動電圧方式によって信号を伝達する。
【００２５】
［ＥＣＵ］
図２は、各ＥＣＵ（以下、ＥＣＵを区別しないときはＥＣＵ３０と表記して説明する）の構成例である。なお、各ＥＣＵのうち一部が、図２に示す構成、又は以下に説明する機能の一部を備えないものとしても構わない。
【００２６】
ＥＣＵ３０は、例えば、ＣＰＵ（Central  Processing  Unit）３１と、ＣＰＵ３１が実行するプログラムを格納したプログラムメモリ３２と、ワーキングメモリとして機能するＲＡＭ（Random  Access  Memory）３３と、周辺機器とのインターフェースとなる周辺Ｉ／Ｏ３４と、ＣＡＮコントローラ３５と、ＣＡＮトランシーバ３６とを備える。
【００２７】
プログラムメモリ３２は、例えば、ＲＯＭ（Read  Only  Memory）、ＥＥＰＲＯＭ（Electrically  Erasable  and  Programmable  Read  Only  Memory）、ＨＤＤ（Hard  Disk  Drive）等であり、制御アプリ３２Ａ、通信ミドルウェア３２Ｂ、ＣＡＮドライバ３２Ｃ等のプログラムを格納する。
【００２８】
制御アプリ３２Ａは、各ＥＣＵに割り当てられた制御を行うためのプログラムである。例えば、ネットワークシステム１が車両に搭載される場合、制御アプリ３２Ａは、例えば、エンジン制御を実行するためのプログラム、ブレーキ制御を実行するためのプログラム、ステアリング制御を実行するためのプログラム、空調制御を実行するためのプログラム等である。ＥＣＵ３０は、制御アプリ３２Ａが制御演算を行った結果を、例えば周期的にバスに出力する。
【００２９】
通信ミドルウェア３２Ｂは、例えば、制御アプリ３２Ａから送信処理要求を受けたデータをＣＡＮドライバ３２Ｃに対応した形式に変換し、ＣＡＮドライバ３２Ｃに出力する。また、通信ミドルウェア３２Ｂは、ＣＡＮドライバ３２Ｃから入力されるデータを受け付け、制御アプリ３２Ａが解釈可能な形式に変換等を行なって制御アプリ３２Ａに出力する。
【００３０】
ＲＡＭ３３には、送信バッファ３３Ａと受信バッファ３３Ｂが設定される。
【００３１】
ＣＡＮコントローラ３５は、プロトコルコントローラや、ＣＰＵクロックを分周する分周器等を備える。ＣＡＮコントローラ３５は、ＣＡＮトランシーバ３６を介して、バス１０又はバス２０との間で種々のデータを送受信する。
【００３２】
ＣＡＮコントローラ３５は、バスにデータ（フレーム）を出力する際には、送信バッファ３３Ａに格納されたフレームを、ＮＲＺ（Non‐Return‐to‐Zero）方式でシリアルの送信信号に変換し、ＣＡＮトランシーバ３６に出力する。ＣＡＮコントローラ３５は、変換後の信号が"０（ドミナント）"のビットには論理レベルがLowの電圧を出力し、"１（リセッシブ）"のビットには論理レベルがHighの電圧を出力する。
【００３３】
ＣＡＮトランシーバ３６は、ＣＡＮコントローラ３５から取得した送信信号を差動電圧に変換してバスに出力する。また、ＣＡＮトランシーバ３６は、バスからデータを取得する際には、バスの差動電圧を読み取り、所定の電圧範囲に含まれるように整形した受信信号をＣＡＮコントローラ３５に出力する。ＣＡＮコントローラ３５の受信端子Ｒｘにはコンパレータが取り付けられており、所定の閾値電圧とＣＡＮトランシーバ３６からの受信信号とを比較して"１"、"０"のデジタルデータを生成して受信バッファ３３Ｂに格納する。
【００３４】
図３は、各ＥＣＵがバスに出力するフレームの形式例である。１回の送信において出力されるフレームは、フレームの開始を表すスタートオブフレーム（ＳＯＦ）、データの識別子であるＩＤ、データフレームとリモートフレームを識別するためのリモートトランスミッションリクエスト（ＲＴＲ）、データのバイト数等を表すコントロールフィールド、転送するデータの実体であるデータフィールド、フレームの誤りをチェックするためのＣＲＣを付加するＣＲＣシーケンス、正しいメッセージを受信したユニットからの通知（ＡＣＫ）を受けるＡＣＫスロット及びＡＣＫデリミタ、フレームの終了を表すエンドオブフレーム（ＥＯＦ）等を含む。
【００３５】
バス１０及びバス２０では、ＩＤとＲＴＲにより表される優先度に基づく通信調停が行われる。複数のＥＣＵから同時にフレームが送信される場合、各ＥＣＵは、自己が送信したデータとバス状態をモニターした結果を比較する。ここで、リセッシブとドミナントが別々のＥＣＵから同時に送信された場合、ドミナントが優先され、バスの状態はドミナントとなる。このとき、リセッシブを送信したノードは自己が送信したものとバス状態の違いにより、通信調停に負けたと判断して送信を停止する。係る原理により、複数のＥＣＵから同時にフレームが送信開始された場合、他ノードがリセッシブ送信を行っているときにドミナントを送信したノードが通信調停に勝つことになるので、ＩＤの値が小さいフレームほど、優先度が高いということになる。優先度すなわちＩＤは、例えば、ＥＣＵ毎に固有の値が割り当てられる。
【００３６】
［ゲートウェイ装置］
図４は、ゲートウェイ装置４０の構成例である。ゲートウェイ装置４０は、例えば、ＣＰＵ４１と、ＣＰＵ４１が実行するプログラムを格納したプログラムメモリ４２と、ワーキングメモリとして機能するＲＡＭ４３と、バス１０に対応するＣＡＮコントローラ４４及びＣＡＮトランシーバ４５と、バス２０に対応するＣＡＮコントローラ４６及びＣＡＮトランシーバ４７とを備える。
【００３７】
プログラムメモリ４２は、例えばＲＯＭ、ＥＥＰＲＯＭ、ＨＤＤ等であり、中継制御プログラム４２Ａ、通信ミドルウェア４２Ｂ、ＣＡＮドライバ４２Ｃ等のプログラムを格納する。中継制御プログラム４２Ａの機能については後述する。通信ミドルウェア４２ＢやＣＡＮドライバ４２Ｃの基本的機能についてはＥＣＵ３０と同様である。
【００３８】
ＲＡＭ４３には、送信バッファ（１０側）４３Ａ及び受信バッファ（１０側）４３Ｂと、送信バッファ（２０側）４３Ｃ及び受信バッファ（２０側）４３Ｄと、ＩＤ毎バッファ４３Ｅ＃０、４３Ｅ＃１、…４３Ｅ＃ｋ（ｋは中継を行うフレームに対応したＩＤの数）と、が設定される
ＣＡＮコントローラ４４は、ＣＡＮトランシーバ４５を介して、バス１０との間で種々のデータを送受信する。ＣＡＮコントローラ４４は、バスにフレームを出力する際には、送信バッファ（１０側）４３Ａに格納されたフレームをシリアルの送信信号に変換し、ＣＡＮトランシーバ４５に出力する。ＣＡＮコントローラ４４は、変換後の信号が"０（ドミナント）"のビットには論理レベルがLowの電圧を出力し、"１（リセッシブ）"のビットには論理レベルがHighの電圧を出力する。
【００３９】
ＣＡＮトランシーバ４５は、ＣＡＮコントローラ４４から取得した送信信号を差動電圧に変換してバスに出力する。また、ＣＡＮトランシーバ４５は、バスからデータを取得する際には、バスの差動電圧を読み取り、所定の電圧範囲に含まれるように整形した受信信号をＣＡＮコントローラ４４に出力する。ＣＡＮコントローラ４４の受信端子Ｒｘにはコンパレータが取り付けられており、所定の閾値電圧とＣＡＮトランシーバ４５からの受信信号とを比較して"１"、"０"のデジタルデータを生成して受信バッファ（１０側）４３Ｂに格納する。
【００４０】
同様に、ＣＡＮコントローラ４６は、ＣＡＮトランシーバ４７を介して、バス２０との間で種々のデータを送受信する。ＣＡＮコントローラ４６は、バスにフレームを出力する際には、送信バッファ（２０側）４３Ｃに格納されたフレームをシリアルの送信信号に変換し、ＣＡＮトランシーバ４７に出力する。ＣＡＮコントローラ４６は、変換後の信号が"０（ドミナント）"のビットには論理レベルがLowの電圧を出力し、"１（リセッシブ）"のビットには論理レベルがHighの電圧を出力する。
【００４１】
ＣＡＮトランシーバ４７は、ＣＡＮコントローラ４６から取得した送信信号を差動電圧に変換してバスに出力する。また、ＣＡＮトランシーバ４７は、バスからデータを取得する際には、バスの差動電圧を読み取り、所定の電圧範囲に含まれるように整形した受信信号をＣＡＮコントローラ４６に出力する。ＣＡＮコントローラ４６の受信端子Ｒｘにはコンパレータが取り付けられており、所定の閾値電圧とＣＡＮトランシーバ４７からの受信信号とを比較して"１"、"０"のデジタルデータを生成して受信バッファ（２０側）４３Ｄに格納する。
【００４２】
受信バッファ（１０側）４３Ａにフレームが格納されると、割り込みが発生し、中継制御プログラム４２Ａが動作する。中継制御プログラム４２Ａを実行するＣＰＵ４１は、受信バッファ（１０側）４３Ｂに格納されたフレームのＩＤを参照し、バス２０側に中継すべきフレームであるか否かを判定する。そして、バス２０側に中継すべきフレームである場合は、ＩＤ毎バッファ４３ＥのうちＩＤに対応するものに当該フレームを移動させ、バス２０側に中継すべきフレームでない場合は、受信バッファ（１０側）４３Ｂから削除する。
【００４３】
また、ＣＰＵ４１は、受信バッファ（２０側）４３Ｄに格納されたフレームのＩＤを参照し、バス１０側に中継すべきフレームであるか否かを判定する。そして、バス１０側に中継すべきフレームである場合は、ＩＤ毎バッファ４３ＥのうちＩＤに対応するものに当該フレームを移動させ、バス１０側に中継すべきフレームでない場合は、受信バッファ（２０側）４３Ｄから削除する。
【００４４】
なお、このような中継有無の判定機能を、ＣＡＮコントローラやＣＡＮトランシーバが備えるものとしてもよい。この場合、受信バッファ（１０側）４３Ｂや受信バッファ（２０側）４３Ｄには、他のバスに中継すべきフレームのみが格納される。
【００４５】
そして、ＣＰＵ４１は、ＩＤ毎バッファ４３Ｅに格納されたフレームを、所定のアルゴリズムに基づく順序で、送信バッファ（１０側）４３Ａ又は送信バッファ（２０側）４３Ｃに移動させる。これによって、ＣＡＮコントローラ４４により、送信バッファ（１０側）４３Ａに格納されたフレームがバス１０に出力され、ＣＡＮコントローラ４６により、送信バッファ（２０側）４３Ａに格納されたフレームがバス２０に出力される。
【００４６】
ここで、出力順を決定するための所定のアルゴリズムについては任意に決定することができる。例えば、簡易な例では、ＣＰＵ４１は、バスに中継すべき全てのフレームについて単にＦＩＦＯ（First  In,  First  Out）に従って出力順を決定してもよい。また、ＣＰＵ４１は、ＩＤにより決定される優先度に応じて出力順を修正してもよい。後者の場合、待ち時間が一定時間以上となったフレームを優先的に出力するようにしてもよい。
【００４７】
［ゲートウェイ装置におけるフレームの滞留］
ゲートウェイ装置４０は、ＥＣＵ３０と同様、バス１０又は２０における通信調停に従う。すなわち、中継するデータのＩＤ及びＲＴＲにより表される優先度に従って、バス１０又はバス２０にデータを出力する。
【００４８】
従って、ゲートウェイ装置４０内においてフレームが滞留するという現象が生じ得る。図５は、ゲートウェイ装置４０内においてフレームが滞留するという現象を模式的に示す図である。特に、ゲートウェイ装置４０のＣＰＵ４１が、バスに中継すべき全てのフレームについて単にＦＩＦＯに従って出力順を決定する場合に、係る現象は生じやすいものとなる。図５に示すように、バス１０側に中継されるフレームのうち、出力順が最も早い先頭のフレームＡの優先度が低ければ、後続のフレームＢ、Ｃの優先度が高いものであっても、フレームＡがバス１０における通信調停に負け続ける結果、フレームＡ、Ｂ、Ｃの全てが長い時間、中継待ちとなる可能性がある。
【００４９】
このような現象が続くと、フレームＡ、Ｂ、ＣのいずれかとＩＤが同じフレームが例えばバス２０からゲートウェイ装置４０に入力されると、ＩＤ毎バッファ４３Ｅのうち該当するＩＤに対応するものにフレームが蓄積されることになる。ＩＤ毎バッファ４３Ｅとして十分な領域が確保されていれば、中継待ちによって処理が遅延すること以外の問題は生じないが、特に各種装置に組み込まれる組込コンピュータにおいては、リソースを無制限に使用するのは難しいというのが実際のところである。特にリソース制限が厳しい装置に適用された場合、ＩＤ毎バッファ４３Ｅの各ＩＤに対応した領域が１フレーム分しかないということもあり得る。この結果、ＩＤ毎バッファ４３Ｅのうち、あるＩＤに対応したものにフレームが蓄積されると、中継待ち状態であったフレームが上書きによって消去されるという不都合も生じ得る。
【００５０】
［ダミーフレームの出力］
上記のようなゲートウェイ装置４０におけるフレームの滞留によって、反対側のバスに中継を依頼したいフレームが消失することを予防するために、ＥＣＵ３０は、以下に説明するようなダミーデータの出力処理を行う。
【００５１】
ＥＣＵ３０の制御アプリ３２Ａは、自ＥＣＵがバスに出力するフレームのうち、特に確実にゲートウェイ装置４０に中継させる必要がある特定のフレームについて、例えば特定のフラグを付与して通信ミドルウェア３２Ｂに出力する。通信ミドルウェア３２Ｂは、特定のフラグが付与された特定のフレームをバスに出力する際には、例えば特定のフレームをバスに出力する前後に、ダミーフレームをバスに出力する。
【００５２】
図６は、特定のフレームＦ*の前後にダミーフレームＤＦがバスに出力される様子を示す図である。ダミーフレームＤＦは、例えば、特定のフレームＦ*の前に数フレーム分、特定のフレームＦ*の後に１フレーム分、出力される。ダミーフレームＤＦは、固定の優先度すなわちＩＤ（例えば最高優先度のＩＤ［０］）を有するものとしてバスに出力され、この結果、通信調停に勝ちやすい（或いは必ず勝つ）ように設定される。また、ダミーフレームＤＦは、ゲートウェイ装置４０により中継されないように、予めゲートウェイ装置４０の設定がなされている。すなわち、ゲートウェイ装置４０は、ダミーフレームの固定ＩＤを参照すると、ダミーフレームＤＦをＩＤ毎バッファ４３Ｅに移動させずに消去する処理を行う。ダミーフレームＤＦのＩＤを固定とし、通常のフレームとＩＤが重ならないようにすることで、ゲートウェイ装置４０においてダミーフレームＤＦを中継しないという制御を容易に行うことができる。
【００５３】
この結果、ゲートウェイ装置４０においてフレームの滞留が生じることにより、特定のフレームＦ*がゲートウェイ装置４０で消失するという不都合が生じるのを、抑制することができる。
【００５４】
なお、ダミーフレームを出力する処理は、ネットワークシステム１が有する全てのＥＣＵ３０が行う必要はなく、一部のＥＣＵ３０のみが係る機能を有する場合もあり得る。
【００５５】
以下、ＥＣＵ３０がバス２０に接続されたものと仮定して説明する。ＥＣＵ３０がダミーフレームＤＦをバス２０に出力すると、ゲートウェイ装置４０では、バス１０に中継されるべきフレームの流入が減少（ダミーフレームＤＦが最高優先度であれば停止）する。
【００５６】
従って、ＥＣＵ３０がダミーフレームＤＦを特定のフレームＦ*の前にバス２０に出力することにより、特定のフレームＦ*がゲートウェイ装置４０に入力されたタイミングでは、ゲートウェイ装置４０内でバス１０に中継されるのを待つフレームの数が少なくなっている（或いはゼロになっている）可能性を高めることができる。これによって、特定のフレームＦ*は、バス１０に出力される出力順が、ＩＤ毎バッファ４３Ｅに格納された当初から早いものとなるため、中継待ち時間が短くなり、中継待ちの時間の間に後続のフレームによって上書き消去される可能性を低くすることができる。
【００５７】
一方、ＥＣＵ３０がダミーフレームＤＦを特定のフレームＦ*の後にバス２０に出力することにより、特定のフレームＦ*がゲートウェイ装置４０内でバス１０に中継されるのを待っている間において、バス１０に中継されるべきフレームのゲートウェイ装置４０への流入が減少又は停止する。この結果、例えば、特定のフレームＦ*よりも優先度の高いフレームがゲートウェイ装置４０内に流入し、バス１０への出力順が追い越されることによって、特定のフレームＦ*の中継待ち時間が長くなるのを抑制することができる。これによって、特定のフレームＦ*は、中継待ち時間が短くなり、中継待ちの時間の間に後続のフレームによって上書き消去される可能性が低くなる。
【００５８】
このように、ダミーフレームＤＦを特定のフレームＦ*の前にバス２０に出力することと、ダミーフレームＤＦを特定のフレームＦ*の後にバス２０に出力することは、それぞれにメリットがある。このため、図６に示したようにダミーフレームＤＦを特定のフレームＦ*の前後にバス２０に出力するのに限らず、ダミーフレームＤＦを特定のフレームＦ*の前にのみバス２０に出力してもよいし、ダミーフレームＤＦを特定のフレームＦ*の後にのみバス２０に出力しても構わない。
【００５９】
係る処理によって、ＥＣＵ３０は、特定のフレームＦ*を、保護された状態でゲートウェイ装置４０に送信することができる。この結果、ＥＣＵ３０は、より確実に特定のフレームＦ*の中継をゲートウェイ装置４０に行わせることができる。
【００６０】
図７は、ダミーフレームの出力に関してＥＣＵ３０により実行される処理の流れを示すフローチャートである。
【００６１】
まず、ＥＣＵ３０のＣＰＵ３１は、制御アプリ３２Ａによりフレームのバスへの出力が行われるタイミングが到来するまで待機する（Ｓ１００）。
【００６２】
制御アプリ３２Ａによりフレームの出力が行われるタイミングが到来すると、ＣＰＵ３１は、当該フレームが、特定のフレームＦ*であるか否かを判定する（Ｓ１０２）。特定のフレームＦ*は、前述のように、例えば制御アプリ３２Ａによって特定のフラグ等が付与されているため、Ｓ１０２の判定は、係るフラグ等を参照して行うことができる。
【００６３】
バスへの出力が行われるフレームが、特定のフレームＦ*でない場合、通常の出力処理を行う（Ｓ１０４）。
【００６４】
一方、バスへの出力が行われるフレームが、特定のフレームＦ*である場合は、ダミーフレームＤＦと特定のフレームＦ*をバスに出力する（Ｓ１０６）。
【００６５】
図７に示すフローチャートの処理は、例えば、通信ミドルウェア３２Ｂに記述されている。また、これに限らず、図７に示すフローチャートの処理は、制御アプリ３２Ａ又はＣＡＮドライバ３２Ｃに記述されていてもよい。
【００６６】
［通信イニシャライズ処理の回避］
ここで、他のＥＣＵ３０がダミーフレームＤＦをバスに出力する可能性があることに対応して、ＥＣＵ３０が実行する処理について説明する。
【００６７】
前述のように、ＥＣＵ３０は、制御アプリ３２Ａが制御演算を行った結果を、例えば周期的にバスに出力する。これに関連し、ＥＣＵ３０は、規定回数以上、連続してバスへのフレームの出力ができなかった場合に、通信イニシャライズ処理を行う。通信イニシャライズ処理は、通信に関する設定を初期化する処理であり、例えば、送信バッファ３３Ａのクリア、ボウレートやサンプリング周期等を含む通信設定を格納した図示しないレジスタの再設定（ＲＯＭからの再ロード）等が含まれる。
【００６８】
しかしながら、ダミーフレームＤＦが頻繁にバスに出力され得る環境では、通信イニシャライズ処理が頻発する可能性がある。通信イニシャライズ処理を行っている間は、ＥＣＵ３０からバスへのフレームの出力が停止してしまうため、ダミーフレームＤＦがバスに出力されることにより、他のＥＣＵ３０において通信イニシャライズ処理が頻発し、通信処理が滞るという不都合が生じうる。
【００６９】
これに対応するために、ＥＣＵ３０は、規定回数以上、連続してバスへのフレームの出力ができなかった場合であっても、バスを流れるフレームがダミーフレームＤＦである場合には、通信イニシャライズ処理を回避する処理を行う。
【００７０】
係る処理によって、ＥＣＵ３０は、通信イニシャライズ処理が頻発し、通信処理が滞るという不都合が生じるのを抑制することができる。
【００７１】
図８は、通信イニシャライズ処理に関してＥＣＵ３０により実行される処理の流れを示すフローチャートである。
【００７２】
まず、ＥＣＵ３０のＣＰＵ３１は、制御アプリ３２Ａによりフレームのバスへの出力が行われるタイミングが到来するまで待機する（Ｓ２００）。
【００７３】
制御アプリ３２Ａによりフレームの出力が行われるタイミングが到来すると、ＣＰＵ３１は、当該フレームのバスへの出力が、通信調停に勝ったか負けたかを判定する（Ｓ２０２）。
【００７４】
通信調停に勝った場合、ＣＰＵ３１は、カウント値Ｃｔをゼロクリアし（Ｓ２０４）、本フローチャートの１ルーチンを終了する。カウントＣｔは、例えばＣＰＵ３１が有する図示しないレジスタ等に格納される値である。
【００７５】
通信調停に負けた場合、ＣＰＵ３１は、カウント値Ｃｔを１増加させ（Ｓ２０６）、カウント値Ｃｔが規定値Ｔｈ以上であるか否かを判定する（Ｓ２０８）。
【００７６】
カウント値Ｃｔが規定値Ｔｈ未満である場合、ＣＰＵ３１は、本フローチャートの１ルーチンを終了する。一方、カウント値Ｃｔが規定値Ｔｈ以上である場合、ＣＰＵ３１は、通信調停に負けた相手がダミーフレームＤＦであったか否かを判定する（Ｓ２１０）。
【００７７】
通信調停に負けた相手がダミーフレームＤＦでなかった場合、ＣＰＵ３１は、通信イニシャライズ処理を行い（Ｓ２１２）、カウント値Ｃｔをゼロクリアし（Ｓ２１４）、本フローチャートの１ルーチンを終了する。
【００７８】
通信調停に負けた相手がダミーフレームＤＦであった場合、ＣＰＵ３１は、通信イニシャライズ処理を行わず、カウント値Ｃｔを１減少させ（Ｓ２１６）、本フローチャートの１ルーチンを終了する。なお、Ｓ２１６の処理は省略しても構わない。
【００７９】
図８に示すフローチャートの処理は、例えば、通信ミドルウェア３２Ｂに記述されている。また、これに限らず、図８に示すフローチャートの処理は、制御アプリ３２Ａ又はＣＡＮドライバ３２Ｃに記述されていてもよい。
【００８０】
なお、図８に示すフローチャートは、「通信調停負けが規定回数に達したときに、相手がダミーフレームＤＦであれば通信イニシャライズを回避する」ものであるが、そもそも、「通信調停負けの相手がダミーフレームＤＦであればカウント値Ｃｔをインクリメントしない」という処理を行ってもよい。図９は、通信イニシャライズ処理に関してＥＣＵ３０により実行される処理の流れを示すフローチャートの他の例である。
【００８１】
図９のフローチャートを実行する場合、まず、ＥＣＵ３０のＣＰＵ３１は、制御アプリ３２Ａによりフレームのバスへの出力が行われるタイミングが到来するまで待機する（Ｓ３００）。
【００８２】
制御アプリ３２Ａによりフレームの出力が行われるタイミングが到来すると、ＣＰＵ３１は、当該フレームのバスへの出力が、通信調停に勝ったか負けたかを判定する（Ｓ３０２）。
【００８３】
通信調停に勝った場合、ＣＰＵ３１は、カウント値Ｃｔをゼロクリアし（Ｓ３０４）、本フローチャートの１ルーチンを終了する。
【００８４】
通信調停に負けた場合、ＣＰＵ３１は、通信調停に負けた相手がダミーフレームＤＦであったか否かを判定する（Ｓ３０６）。通信調停に負けた相手がダミーフレームＤＦであった場合、ＣＰＵ３１は、本フローチャートの１ルーチンを終了する。
【００８５】
通信調停に負けた相手がダミーフレームＤＦでなかった場合、ＣＰＵ３１は、カウント値Ｃｔを１増加させ（Ｓ３０８）、カウント値Ｃｔが規定値Ｔｈ以上であるか否かを判定する（Ｓ３１０）。
【００８６】
カウント値Ｃｔが規定値Ｔｈ未満である場合、ＣＰＵ３１は、本フローチャートの１ルーチンを終了する。一方、カウント値Ｃｔが規定値Ｔｈ以上である場合、ＣＰＵ３１は、通信イニシャライズ処理を行い（Ｓ３１２）、カウント値Ｃｔをゼロクリアし（Ｓ３１４）、本フローチャートの１ルーチンを終了する。
【００８７】
［まとめ］
以上説明した処理装置、ネットワークシステム、及び通信制御プログラムの実施例によれば、特定のフレームＦ*をバスに出力する際に、ダミーフレームＤＦを併せてバスに出力するため、特定のフレームＦ*の中継を、より確実にゲートウェイ装置４０に行わせることができる。
【００８８】
また、ダミーフレームＤＦとの調停に負けた場合に通信イニシャライズ処理を行わないように制御するため、通信イニシャライズ処理が頻発し、通信処理が滞るという不都合が生じるのを抑制することができる。
【００８９】
なお、ダミーフレームＤＦは、例えば「ゲートウェイ装置を通過しないダミーデータ」の一例であり、特定のフレームＦ*は、例えば「ゲートウェイ装置を通過する特定のデータ」の一例である。
【００９０】
以上、本発明を実施するための形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
【００９１】
例えば、上記実施例では、ＣＡＮに基づく通信が行われるシステムに適用された例について説明したが、優先度に基づく通信調停が行われるプロトコルであれば、如何なるプロトコルを採用したシステムにも適用可能である。
【符号の説明】
【００９２】
１      ネットワークシステム
１０、２０  バス
３０    ＥＣＵ
３１    ＣＰＵ
３２    プログラムメモリ
３２Ａ  制御アプリ
３２Ｂ  通信ミドルウェア
３２Ｃ  ＣＡＮドライバ
３３    ＲＡＭ
３３Ａ  送信バッファ
３３Ｂ  受信バッファ
３４    周辺Ｉ／Ｏ
３５    ＣＡＮコントローラ
３６    ＣＡＮトランシーバ
４０    ゲートウェイ装置
４１    ＣＰＵ
４２    プログラムメモリ
４２Ａ  中継制御プログラム
４２Ｂ  通信ミドルウェア
４２Ｃ  ＣＡＮドライバ
４３    ＲＡＭ
４３Ａ  送信バッファ（１０側）
４３Ｂ  受信バッファ（１０側）
４３Ｃ  送信バッファ（２０側）
４３Ｄ  受信バッファ（２０側）
４３Ｅ  ＩＤ毎バッファ
４４、４６  ＣＡＮコントローラ
４５、４７  ＣＡＮトランシーバ
【図１】
2014036417.tif 000003
【図２】
2014036417.tif 000004
【図３】
2014036417.tif 000005
【図４】
2014036417.tif 000006
【図５】
2014036417.tif 000007
【図６】
2014036417.tif 000008
【図７】
2014036417.tif 000009
【図８】
2014036417.tif 000010
【図９】
2014036417.tif 000011