(57)【要約】【課題】通信調停に係る優先度が高いデータを、装置の負担を過大にすることなく、優先的にバスに出力すること。【解決手段】バスにデータを出力する出力部であって、前記バスに出力されようとしている他の競合データとの間で、自己が前記バスに出力しようとしているデータに付与された優先度情報を用いて通信調停を行った結果に基づき、前記バスにデータを出力するか否かを決定する出力部と、領域優先度の高い領域から低い領域まで複数の領域が設定された記憶部と、送信要求がなされたデータを、該データに付与された優先度情報が高いものである程、前記記憶部における領域優先度の高い領域に書き込む分配部と、を備え、前記出力部は、前記複数の領域に格納されたデータのうち、前記領域優先度の高い領域に格納されたデータを優先的に前記バスに出力する、データ送信装置。【選択図】図２
2014033339.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の電圧を出力する。
【００３２】
ＣＡＮトランシーバ１６は、ＣＡＮコントローラ１５から取得した送信信号を差動電圧に変換してバスに出力する。また、ＣＡＮトランシーバ１６は、バスからデータを取得する際には、バスの差動電圧を読み取り、所定の電圧範囲に含まれるように整形した受信信号をＣＡＮコントローラ１５に出力する。ＣＡＮコントローラ１５の受信端子Ｒｘにはコンパレータが取り付けられており、所定の閾値電圧とＣＡＮトランシーバ１６からの受信信号とを比較して"１"、"０"のデジタルデータを生成して受信バッファ１３Ｃに格納する。
【００３３】
図３は、各ＥＣＵがバスに出力するフレームの形式例である。１回の送信において出力されるフレームは、フレームの開始を表すスタートオブフレーム（ＳＯＦ）、データの識別子であるＩＤ、データフレームとリモートフレームを識別するためのリモートトランスミッションリクエスト（ＲＴＲ）、データのバイト数等を表すコントロールフィールド、転送するデータの実体であるデータフィールド、フレームの誤りをチェックするためのＣＲＣを付加するＣＲＣシーケンス、正しいメッセージを受信したユニットからの通知（ＡＣＫ）を受けるＡＣＫスロット及びＡＣＫデリミタ、フレームの終了を表すエンドオブフレーム（ＥＯＦ）等を含む。
【００３４】
バス２及びバス３では、ＩＤとＲＴＲにより表される優先度に基づく通信調停が行われる。複数のＥＣＵから同時にフレームが送信される場合、各ＥＣＵは、自己が送信したデータとバス状態をモニターした結果を比較する。ここで、リセッシブとドミナントが別々のＥＣＵから同時に送信された場合、ドミナントが優先され、バスの状態はドミナントとなる。このとき、リセッシブを送信したノードは自己が送信したものとバス状態の違いにより、通信調停に負けたと判断して送信を停止する。係る原理により、複数のＥＣＵから同時にフレームが送信開始された場合、他ノードがリセッシブ送信を行っているときにドミナントを送信したノードが通信調停に勝つことになるので、ＩＤの値が小さいフレームほど、優先度が高いということになる。
【００３５】
［送信制御］
以下、通信ミドルウェア１２Ｂ、ＣＡＮドライバ１２Ｃ、及びＣＡＮコントローラ１５による送信制御について、より詳細に説明する。
【００３６】
〔通信ミドルウェア１２Ｂ、及びＣＡＮドライバ１２Ｃの処理〕
通信ミドルウェア１２Ｂは、アプリケーションプログラム１２Ａの依頼に応じて、共用領域１３Ａに格納されたデータを送信バッファ１３Ｂに格納する。ここで、共用領域１３Ａに格納されたデータには、フレームの形式における「ＩＤ」に相当する情報（以下、単にＩＤと表記する）がアプリケーションプログラム１２Ａによって付与されている。ＩＤは、例えば１〜１０のいずれかの整数をとるものとする。
【００３７】
ＣＡＮドライバ１２Ｃは、送信バッファ１３Ｂに格納されたデータを、フレームとして必要なデータを付加しつつ、データに付与されたＩＤに応じた送信ＭＢＯＸに格納する。図４は、送信ＭＢＯＸとＩＤの対応関係の一例である。各送信ＭＢＯＸには、１フレーム分のデータが格納され、既に送信ＭＢＯＸにデータが格納されている場合、ＣＡＮドライバ１２Ｃは、当該送信ＭＢＯＸへのデータの格納を行わない。図４に示す対応関係から分かるように、送信ＭＢＯＸ１３Ａａには、通信調停における優先度が高いデータが格納される。また、送信ＭＢＯＸ１３Ａｂには、通信調停における優先度が中程度のデータが格納される。また、送信ＭＢＯＸ１３Ａｃには、通信調停における優先度が低いデータが格納される。
【００３８】
更に、ＣＡＮドライバ１２Ｃは、送信ＭＢＯＸ１３Ａａにデータを格納すると、送信要求レジスタ１５Ａａに、例えばフラグ「１」を立てる。また、ＣＡＮドライバ１２Ｃは、送信ＭＢＯＸ１３Ａｂにデータを格納すると、送信要求レジスタ１５Ａｂに、例えばフラグ「１」を立てる。ＣＡＮドライバ１２Ｃは、送信ＭＢＯＸ１３Ａｃにデータを格納すると、送信要求レジスタ１５Ａｃに、例えばフラグ「１」を立てる。すなわち、送信要求レジスタ１５Ａａは送信ＭＢＯＸ１３Ａａに対応し、送信要求レジスタ１５Ａｂは送信ＭＢＯＸ１３Ａｂに対応し、送信要求レジスタ１５Ａｂは送信ＭＢＯＸ１３Ａｂに対応する。
【００３９】
図５は、ＣＡＮドライバ１２Ｃにより実行される処理の流れを示すフローチャートの一例である。本フローチャートは、例えば所定周期で繰り返し実行される。
【００４０】
まず、ＣＡＮドライバ１２Ｃは、送信バッファ１３Ｂにデータが格納されているか否かを判定する（Ｓ１００）。送信バッファ１３Ｂにデータが格納されていない場合、ＣＡＮドライバ１２Ｃは、本フローチャートの１ルーチンを終了する。
【００４１】
送信バッファ１３Ｂにデータが格納されている場合、ＣＡＮドライバ１２Ｃは、送信バッファ１３Ｂに格納されたデータのＩＤを読み込み（Ｓ１０２）、ＩＤが４以下であるか否かを判定する（Ｓ１０４）。
【００４２】
ＩＤが４以下である場合、ＣＡＮドライバ１２Ｃは、送信ＭＢＯＸ１３Ｄａが「空き」状態であるか否かを判定する（Ｓ１０６）。送信ＭＢＯＸ１３Ｄａが「空き」状態である場合、ＣＡＮドライバ１２Ｃは、送信バッファ１３Ｂに格納されたデータを送信ＭＢＯＸ１３Ｄａに書き込み（Ｓ１０８）、送信要求レジスタ１５Ａａにフラグ「１」を立てる（Ｓ１１０）。送信ＭＢＯＸ１３Ｄａが「空き」状態でない場合、ＣＡＮドライバ１２Ｃは、本フローチャートの１ルーチンを終了する。
【００４３】
ＩＤが４を超える場合、ＣＡＮドライバ１２Ｃは、ＩＤが７以下であるか否かを判定する（Ｓ１１２）。
【００４４】
ＩＤが７以下である場合、ＣＡＮドライバ１２Ｃは、送信ＭＢＯＸ１３Ｄｂが「空き」状態であるか否かを判定する（Ｓ１１４）。送信ＭＢＯＸ１３Ｄｂが「空き」状態である場合、ＣＡＮドライバ１２Ｃは、送信バッファ１３Ｂに格納されたデータを送信ＭＢＯＸ１３Ｄｂに書き込み（Ｓ１１６）、送信要求レジスタ１５Ａｂにフラグ「１」を立てる（Ｓ１１８）。送信ＭＢＯＸ１３Ｄｂが「空き」状態でない場合、ＣＡＮドライバ１２Ｃは、本フローチャートの１ルーチンを終了する。
【００４５】
ＩＤが７を超える場合、ＣＡＮドライバ１２Ｃは、送信ＭＢＯＸ１３Ｄｃが「空き」状態であるか否かを判定する（Ｓ１２０）。送信ＭＢＯＸ１３Ｄｃが「空き」状態である場合、ＣＡＮドライバ１２Ｃは、送信バッファ１３Ｂに格納されたデータを送信ＭＢＯＸ１３Ｄｃに書き込み（Ｓ１２２）、送信要求レジスタ１５Ａｃにフラグ「１」を立てる（Ｓ１２４）。送信ＭＢＯＸ１３Ｄｃが「空き」状態でない場合、ＣＡＮドライバ１２Ｃは、本フローチャートの１ルーチンを終了する。
【００４６】
〔ＣＡＮコントローラ１５の処理〕
ＣＡＮコントローラ１５は、フラグ「１」が立っている送信要求レジスタに対応する送信ＭＢＯＸに格納されたデータ（フレーム）を、ＣＡＮトランシーバ１６を介してバスに出力する。このとき、ＣＡＮコントローラ１５は、複数の送信要求レジスタにフラグ「１」が立っている場合には、送信ＭＢＯＸ１３Ａａに格納されたデータを最優先にバスに出力しようとし（通信調停に勝った場合に実際に出力する；以下同じ）、次いで送信ＭＢＯＸ１３Ａｂに格納されたデータをバスに出力しようとし、送信ＭＢＯＸ１３Ａａにも送信ＭＢＯＸ１３Ａｂにもデータが格納されていない場合に送信ＭＢＯＸ１３Ａｃに格納されたデータをバスに出力しようとする。ＣＡＮコントローラ１５は、送信ＭＢＯＸに格納されたデータをバスに出力できた場合、対応する送信要求レジスタのフラグをゼロクリアする。
【００４７】
図６は、ＣＡＮコントローラ１５により実行される処理の流れを示すフローチャートの一例である。本フローチャートは、例えば所定周期で繰り返し実行される。
【００４８】
ＣＡＮコントローラ１５は、まず、送信要求レジスタ１５Ａａにフラグ「１」が立っているか否かを判定する（Ｓ２００）。
【００４９】
送信要求レジスタ１５Ａａにフラグ「１」が立っている場合、ＣＡＮコントローラ１５は、送信ＭＢＯＸ１３Ｄａからデータを読み込み、バスへの出力を試行する（Ｓ２０２）。そして、ＣＡＮコントローラ１５は、通信調停に勝ち、バスへの出力が成功した場合には、送信要求レジスタ１５Ａａのフラグをゼロクリアする（Ｓ２０４、２０６）。
【００５０】
送信要求レジスタ１５Ａａにフラグ「１」が立っていない場合、ＣＡＮコントローラ１５は、送信要求レジスタ１５Ａｂにフラグ「１」が立っているか否かを判定する（Ｓ２０８）。
【００５１】
送信要求レジスタ１５Ａｂにフラグ「１」が立っている場合、ＣＡＮコントローラ１５は、送信ＭＢＯＸ１３Ｄｂからデータを読み込み、バスへの出力を試行する（Ｓ２１０）。そして、ＣＡＮコントローラ１５は、通信調停に勝ち、バスへの出力が成功した場合には、送信要求レジスタ１５Ａｂのフラグをゼロクリアする（Ｓ２１２、２１４）。
【００５２】
送信要求レジスタ１５Ａｂにフラグ「１」が立っていない場合、ＣＡＮコントローラ１５は、送信要求レジスタ１５Ａｃにフラグ「１」が立っているか否かを判定する（Ｓ２１６）。
【００５３】
送信要求レジスタ１５Ａｃにフラグ「１」が立っている場合、ＣＡＮコントローラ１５は、送信ＭＢＯＸ１３Ｄｃからデータを読み込み、バスへの出力を試行する（Ｓ２１８）。そして、ＣＡＮコントローラ１５は、通信調停に勝ち、バスへの出力が成功した場合には、送信要求レジスタ１５Ａｃのフラグをゼロクリアする（Ｓ２２０、２２２）。
【００５４】
係る処理によって、低優先度のフレームが通信調停に負け続けることによって、後続の高優先度のフレームの待ち状態が長時間継続するという不都合が生じるのを抑制することができる。
【００５５】
［他の構成との比較等］
図７は、単独の送信ＭＢＯＸのみ設定される比較例のＥＣＵ*において、上記の不都合が生じる様子を示す図である。ＥＣＵ*では、送信ＭＢＯＸを一つのみ設定する、送信バッファに格納されたデータを、ＦＩＦＯ（First  In,  First  Out）に従い、或いはＩＤが小さい順に送信ＭＢＯＸに格納する。しかしながら、ＩＤが大きいデータを送信ＭＢＯＸに格納した直後に、ＩＤが小さいデータが送信バッファに格納されることも当然に生じうる。この場合、先に送信ＭＢＯＸに格納されたデータが通信調停に負け続けると、後続のＩＤが小さいデータは送信ＭＢＯＸに格納されず、待ち状態を継続せざるを得ないことになる。
【００５６】
この点、本実施例のＥＣＵ１０では、送信ＭＢＯＸをＩＤに応じて複数設定し、ＩＤが小さい、すなわち通信調停に係る優先度が高いデータを優先的にバスに出力しようとする。この結果、先にバスへの出力が試行されるデータは通信調停に勝つ可能性が高くなり、前述のような不都合が生じるのを抑制することができる。図８は、本実施例のＥＣＵ１０が通信調停に係る優先度が高いデータを優先的にバスに出力する様子を示す図である。
【００５７】
また、本実施例のＥＣＵ１０では、ＣＡＮコントローラ１５は、送信要求レジスタの値に応じて自動的に、いずれの送信ＭＢＯＸからデータを読み込んでバスに出力すればよいかを判断することができるため、例えば送信ＭＢＯＸに格納された全てのデータの内容を参照してＩＤをチェックするといった処理を行う必要が無い。この結果、ＣＡＮコントローラ１５における処理負荷を過大にすることなく、通信調停に係る優先度が高いデータを、優先的にバスに出力することができる。
【００５８】
また、本実施例のＥＣＵ１０では、通信調停に係る優先度が高いデータを、優先的にバスに出力するための処理は、通信ミドルウェア１２Ｂ以下の階層で行われるため、アプリケーションプログラム１２Ａに改変を行う必要が無い。このため、既存のＥＣＵその他の装置に適用する際に、ソフトウェア改変の負担が小さい。
【００５９】
［まとめ］
以上説明した本実施例のＥＣＵ１０によれば、通信調停に係る優先度が高いデータを、処理負荷を過大にすることなく、優先的にバスに出力することができる。
【００６０】
以上、本発明を実施するための形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
【００６１】
例えば、通信調停に係る優先度が高いデータを、優先的にバスに出力することを原則としつつ、一定期間、送信ＭＢＯＸに格納されたままバスに出力されないデータ（以下、「待ち時間超過データ」と称する）については、ＩＤに関わらず、最優先でバスへの出力を試行するものとしてもよい。この場合、こうした例外措置専用の送信ＭＢＯＸを設定しておき、待ち時間超過データを、当初格納された送信ＭＢＯＸから例外措置専用の送信ＭＢＯＸに移動させる。図９は、例外措置を行う場合の送信ＭＢＯＸとＩＤ、送信要求レジスタの対応関係の一例である。送信ＭＢＯＸに格納されてからの経過時間の監視は、通信ミドルウェア１２Ｂが行い、通信ミドルウェア１２Ｂは、待ち時間超過データが発生すると、当該待ち時間超過データを図９における送信ＭＢＯＸ１３Ｄａに移動させるようにＣＡＮドライバ１２Ｃに指示する。ＣＡＮドライバ１２Ｃは、待ち時間超過データを送信ＭＢＯＸ１３Ｄａに移動させると共に、待ち時間超過データが当初格納された送信ＭＢＯＸに対応する送信要求レジスタのフラグをゼロクリアし、送信ＭＢＯＸ１３Ｄａに対応する送信要求レジスタ１５Ａａにフラグ「１」を立てる。なお、係る処理は、送信ＭＢＯＸ間のデータの移動を行わず、ＣＡＮコントローラ１５の内部フラグを変更すること等によって実現されても構わない。
【００６２】
また、実施例では、送信ＭＢＯＸを３つ（例外措置専用の送信ＭＢＯＸを設定する場合は４つ）設定することを例示したが、これに限らず、例えば、全てのＩＤ（１、２、…ｎ）に対応する送信ＭＢＯＸを設定してもよい。図１０は、全てのＩＤに対応する送信ＭＢＯＸを設定した場合のＥＣＵ１０の構成例である。図１０に示す構成に対し、更に例外措置専用の送信ＭＢＯＸ、及び対応する送信要求レジスタを設定してもよい。
【符号の説明】
【００６３】
１      ネットワークシステム
２、３  バス
１０    ＥＣＵ
１１    ＣＰＵ
１２    プログラムメモリ
１２Ａ  アプリケーションプログラム
１２Ｂ  通信ミドルウェア
１２Ｃ  ＣＡＮドライバ
１３    ＲＡＭ
１３Ａ  共用領域
１３Ｂ  送信バッファ
１３Ｃ  受信バッファ
１３Ｄ  コントローラ読出領域
１３Ｄａ、１３Ｄｂ、１３Ｄｃ、…  送信ＭＢＯＸ
１４    周辺Ｉ／Ｏ
１５    ＣＡＮコントローラ
１５Ａａ、１５Ａｂ、１５Ａｃ、…  送信制御レジスタ
１６    ＣＡＮトランシーバ
５０    ゲートウェイ装置
【図１】
2014033339.tif 000003
【図２】
2014033339.tif 000004
【図３】
2014033339.tif 000005
【図４】
2014033339.tif 000006
【図５】
2014033339.tif 000007
【図６】
2014033339.tif 000008
【図７】
2014033339.tif 000009
【図８】
2014033339.tif 000010
【図９】
2014033339.tif 000011
【図１０】
2014033339.tif 000012