JP2008030691A - 車両用制御システムのメッセージ管理装置及び車両用制御システム - Google Patents

Abstract

【課題】車両用制御システムにおいてデッドライン監視のための処理負荷を低減する。
【解決手段】ＥＣＵ１１において、アプリケーションコンポーネント（以下、ＡＰ）１が、ＥＣＵ１３のＡＰ３に対する要求メッセージを出すと、メッセージ情報管理部２１が、その要求メッセージを受け付けてＥＣＵ１３へ送信し、その要求メッセージを受けたＡＰ３が該メッセージに対応する処理を実施して、その処理結果を示す応答がＥＣＵ１３からＥＣＵ１１へ返送されると、メッセージ情報管理部２１は、その応答を取得してＡＰ１へ供給する。ここで、メッセージ情報管理部２１は、ＡＰ１から出力され得る複数種類の要求メッセージのうち、ＡＰ１から実際に出力されて受け付けたが未だ応答が取得されていない受付中の要求メッセージのみを記憶するメッセージ処理順序規定部３２を備えており、それに記憶されている要求メッセージについてのみデッドライン監視用の処理を行う。
【選択図】図１

Description

本発明は、複数の制御プログラムが連携する分散型の車両用制御システムに関するものである。

従来より、この種の車両用制御システムでは、あるアプリケーションコンポーネント（以下、ＡＰと記す）が他のＡＰに何らかの処理の実施を要求するための要求メッセージを出すと、その要求メッセージを受けたＡＰが、その要求メッセージに対応する処理を実施して、その処理の結果を示す応答を返す、といった具合に、複数のＡＰがメッセージを用いて連携することにより所定の機能を実現している。

また、ハードウェア面の構成としては、各ＡＰが別々の電子制御装置（以下、ＥＣＵと記す）に搭載されて、その複数のＥＣＵ間で車両内のネットワークを介し通信するもの（例えば、特許文献１参照）や、各ＡＰが１つのＥＣＵに搭載されて、そのＥＣＵ内でメッセージ及び応答をやり取りするものが考えられる。

尚、ＡＰ（アプリケーションコンポーネント）とは、目的の機能を実現するための制御プログラム（アプリケーションプログラムとも呼ばれる）のことであり、更に詳しくは、その制御プログラムを構成するプログラムコード及びその制御プログラムの実行時に参照されるデータからなるソフトウェアのことである。また、本明細書においては、便宜上、「ＡＰが・・・する」といったプログラムを主体とした表現を適宜用いるが、その表現は、そのプログラムをＣＰＵが実行することで実現される機能手段の動作内容（簡単に言えば、そのプログラムの機能の内容）を表している。

ここで、本発明者が本発明に至る前に考えた複数のＥＣＵからなる分散型の車両用制御システムの一例について、図８〜図１０を用いて説明する。
まず、図８に例示する車両用制御システムは、車両のユーザが遠隔地から車両のドアロックなどを行うことができるようにしたリモートコントロールシステムである。

図８のリモートコントロールシステムは、ユーザが携帯する携帯電話などのユーザ端末と直接又は基地局を介して無線通信する車外通信ＥＣＵ１０と、リモートセキュリティＥＣＵ１１と、ユーザ認証用の処理を行う照合ＥＣＵ１２と、車両の運転席（以下、Ｄ席と記す）ドアのロック／アンロック及びウィンドウの開閉を制御するＤ席ドアＥＣＵ１３と、車両の助手席（以下、Ｐ席と記す）ドアのロック／アンロック及びウィンドウの開閉を制御するＰ席ドアＥＣＵ１４と、車両の後右席（以下、ＲＲ席と記す）ドアのロック／アンロック及びウィンドウの開閉を制御するＲＲ席ドアＥＣＵ１５と、車両の後左席（以下、ＲＬ席と記す）ドアのロック／アンロック及びウィンドウの開閉を制御するＲＬ席ドアＥＣＵ１６とを備えている。また、それらＥＣＵ１０〜１６は、車両内ネットワークとしての通信線（図示省略）を介して互いに通信可能に接続されている。

そして、このリモートコントロールシステムにおいて、ユーザ端末から、例えばドアロックを要求する要求メッセージが送信されると、その要求メッセージは、車外通信ＥＣＵ１０を介して、リモートセキュリティＥＣＵ１１に受信される。

すると、リモートセキュリティＥＣＵ１１では、車外通信ＥＣＵ１０から受信した要求メッセージが正規ユーザのユーザ端末から送信されたものであることを確認するため、そのＥＣＵ１１に搭載されたＡＰ１が、照合ＥＣＵ１２に搭載されたＡＰ２にユーザ認証用処理の実施を要求するための要求メッセージ（以下、ユーザ認証要求という）を出力し、そのユーザ認証要求が照合ＥＣＵ１２へと送信される。

照合ＥＣＵ１２では、ユーザ認証要求を受信すると、ＡＰ２が、ユーザ認証用処理を行って、その処理結果を示す応答（つまり、認証ＯＫか否かを示す応答であり、以下、認証結果応答という）を出力する。すると、その認証結果応答が、照合ＥＣＵ１２からリモートセキュリティＥＣＵ１１へ送信される。

尚、ユーザ端末からの要求メッセージには、そのユーザ端末の識別コードが含まれており、その識別コードは、リモートセキュリティＥＣＵ１１から照合ＥＣＵ１２へのユーザ認証要求にも含ませられる。このため、照合ＥＣＵ１２のＡＰ２は、ユーザ認証用処理として、リモートセキュリティＥＣＵ１１からの識別コードが、予め照合ＥＣＵ１２内に記憶されている識別コードと一致しているか否かを判定し、一致していれば照合ＯＫと判断する、といった処理を行う。

そして、リモートセキュリティＥＣＵ１１では、ＡＰ１が、照合ＥＣＵ１２からの認証結果応答を判定し、その認証結果応答が認証ＯＫを示していれば、各ドアＥＣＵ１３〜１６に搭載されたＡＰ３〜６にドアロックを要求するための各ドア毎の要求メッセージ（以下、ドアロック要求という）をそれぞれ出力する。すると、その各ドアロック要求が、リモートセキュリティＥＣＵ１１から該当するドアＥＣＵ１３〜１６へ送信される。

各ドアＥＣＵ１３〜１６では、リモートセキュリティＥＣＵ１１から自ＥＣＵ宛てのドアロック要求を受信すると、ＡＰ３〜６の各々が、そのドアロック要求に従って各ドアをロックするためのドアロック処理を行い、その後、ドアロック処理の結果を示す応答（つまり、ドアロック処理が完了したことを示す応答であり、以下、ドアロック完了応答という）を出力する。すると、そのドアロック完了応答が、各ドアＥＣＵ１３〜１６からリモートセキュリティＥＣＵ１１へ送信される。

リモートセキュリティＥＣＵ１１では、ＡＰ１が、各ドアＥＣＵ１３〜１６からのドアロック完了応答により、各ドアのロックが完了したことを認識する。すると、その後、リモートセキュリティＥＣＵ１１から車外通信ＥＣＵ１０を介してユーザ端末へ、ドアロック完了応答が送信される。

尚、ユーザ端末から、例えばドアのウィンドウを閉じることを要求する要求メッセージが送信されたならば、上記と同様の手順で、各ドアＥＣＵ１３〜１６により各ドアのウィンドウが閉じられることとなる。

また、ＥＣＵ１１〜１６の各々には、ＡＰ間のメッセージ（要求メッセージ及び応答）のやり取りを管理するメッセージ情報管理部と、他のＥＣＵと通信するための送信部及び受信部とが備えられている。

そして、メッセージ情報管理部は、自ＥＣＵのＡＰから出力された要求メッセージや応答を、それの送り先である他のＥＣＵへ自ＥＣＵの送信部から送信させ、他のＥＣＵから送信されて自ＥＣＵの受信部により受信された応答や要求メッセージを、自ＥＣＵのＡＰに供給する。

例えば、リモートセキュリティＥＣＵ１１のメッセージ情報管理部は、ＡＰ１がＡＰ２への要求メッセージ（ユーザ認証要求）を出力すると、その要求メッセージを受け付けてＥＣＵ１１の送信部からＥＣＵ１２へ送信させ、また、その要求メッセージに対するＡＰ２からの応答（認証結果応答）がＥＣＵ１１の受信部によって受信されると、その応答を取得してＡＰ１に供給する。

メッセージ情報管理部について更に詳しく説明すると、メッセージ情報管理部は、図９のようなメッセージ情報管理テーブルを有している。
メッセージ情報管理テーブルは、ＡＰ間でやり取りされる複数種類の要求メッセージの識別子である識別番号（ＩＮＤＥＸ）毎に、その要求メッセージのルートと、メッセージ状態（ＭＳＧ状態）と、デッドラインカウンタと、デッドライン値とを記録したテーブルである。

そして、識別番号（ＩＮＤＥＸ）と、ルートと、デッドライン値は、予め静的に定義される情報である。ルートは、該当の要求メッセージが、どのＡＰからどのＡＰへ送信されるものかを示し（換言すれば、その要求メッセージを出す要求側ＡＰと、その要求メッセージを受けて応答を返すべき被要求側ＡＰとを示し）、デッドライン値は、該当の要求メッセージが出されてから応答が返ってくるまでに待つことのできる最大時間に相当する値である。例えば、図９のメッセージ情報管理テーブルにおいて、識別番号が１の要求メッセージ（Ｄ席ドアロック要求）については、ルートとして、要求側ＡＰがＡＰ１で被要求側ＡＰがＡＰ３である（ＡＰ１→ＡＰ３）という情報が記録され、デッドライン値として、１００が記録されている。

一方、メッセージ状態とデッドラインカウンタは、動的に変化する情報である。
メッセージ状態は、該当の要求メッセージがＡＰから出力されていない場合には、初期状態としての「要求待ち」に設定される。そして、該当の要求メッセージが要求側ＡＰから出されてメッセージ情報管理部に受け付けられてから、それに対する被要求側ＡＰからの応答がメッセージ情報管理部により取得されるまでの期間中は、「要求あり」又は「応答待ち」といった他の状態に設定される。その後、被要求側ＡＰからの応答がメッセージ情報管理部により取得されて要求側ＡＰへ出力されると、メッセージ状態は「要求待ち」に戻される。

また、デッドラインカウンタは、該当の要求メッセージについての上記期間を計測するためのカウンタである。具体的には、該当する要求メッセージのメッセージ状態が「要求待ち」から他の状態に変化すると、その要求メッセージに対して定められた上記デッドライン値が、デッドラインカウンタの初期値として設定され、その後、上記期間が終了するまで、デッドラインカウンタは一定時間毎にデクリメント（−１）される。そして、そのデッドラインカウンタの値が０になったら、デッドライン超過（即ち、要求メッセージによって要求された処理が、期待した時間内に完了しなかった）と判定される。

そして、このようなメッセージ情報管理テーブルにおけるメッセージ状態の更新と、デッドラインカウンタの初期値設定及びデクリメントと、デッドライン超過の判定は、メッセージ情報管理部が実施する。

そこで次に、要求メッセージによって要求された処理が期待した時間内に完了したか否かを監視（即ち、デッドライン監視）するために、メッセージ情報管理部が一定時間毎に実施するデッドライン監視処理について、図１０を用い説明する。

図１０に示すデッドライン監視処理では、まずＳ１１０にて、メッセージ情報管理テーブルにおける先頭の要求メッセージ（図９の例では、識別番号が１の要求メッセージ）を調査対象に設定する。

次にＳ１２０にて、調査対象の要求メッセージが受付中であるか否かを判定する。尚、要求メッセージが受付中とは、上記期間中ということであり、メッセージ情報管理テーブルにおけるメッセージ状態が「要求あり」又は「応答待ち」の状態になっているということである。

そして、調査対象の要求メッセージが受付中でなければ（Ｓ１２０：ＮＯ）、そのままＳ１６０へ移行するが、調査対象の要求メッセージが受付中であれば（Ｓ１２０：ＹＥＳ）、次のＳ１３０にて、調査対象の要求メッセージに対応するデッドラインカウンタをデクリメントする。尚、受付中の要求メッセージ（即ち、ＡＰから出力されてメッセージ情報管理部に受け付けられたが未だ応答が取得されていない要求メッセージであり、以下単に、受付中メッセージともいう）に対応するデッドラインカウンタには、前述したように、その要求メッセージが要求側ＡＰから出されてメッセージ情報管理部に取得された時点で、その要求メッセージに対して定められたデッドライン値が、初期値として設定されており、このＳ１３０にて、そのデッドラインカウンタのデクリメントが行われる。

そして、次のＳ１４０にて、デクリメントしたデッドラインカウンタの値が０になったか否かを判定し、０でなければ（Ｓ１４０：ＮＯ）、そのままＳ１６０へ移行するが、デッドラインカウンタの値が０になったならば（Ｓ１４０：ＹＥＳ）、Ｓ１５０に進んで、デッドライン超過処理を実施し、その後、Ｓ１６０に進む。尚、デッドライン超過処理は、例えば、調査対象の要求メッセージについて、メッセージ情報管理テーブルのメッセージ状態を「デッドライン超過」に設定すると共に、その調査対象の要求メッセージを出した要求側ＡＰに対してエラーを通知する、といった処理である。すると、要求側ＡＰは、その要求メッセージに対する応答を待たなくなり、それ以上の処理の停滞が防止される。

Ｓ１６０では、メッセージ情報管理テーブルに記録されている全ての要求メッセージについて調査（即ちＳ１２０の判定）が終了したか否かを判定し、終了していなければ（Ｓ１６０：ＮＯ）、次のＳ１７０にて、調査対象の要求メッセージをメッセージ情報管理テーブルにおける次の要求メッセージに設定し、その後、Ｓ１２０へ戻る。

また、上記Ｓ１６０にて、全ての要求メッセージについて調査が終了したと判定したならば（Ｓ１６０：ＹＥＳ）、そのまま当該デッドライン監視処理を終了する。
つまり、図１０のデッドライン監視処理では、メッセージ情報管理テーブルに記録されている全ての要求メッセージ（換言すれば、ＡＰから出力され得る全ての要求メッセージ）の各々についてメッセージ状態に基づき受付中であるか否かを判定することにより、受付中メッセージを検索し（Ｓ１１０，Ｓ１２０，Ｓ１６０，Ｓ１７０）、その検索した受付中メッセージについて、デッドラインカウンタをデクリメントする時間計測用の処理（Ｓ１３０）と、デッドラインカウンタの値が０になったか否かの判定処理（Ｓ１４０）とを行うようになっている。

尚、図８〜図１０の例において、メッセージ情報管理部も実際にはソフトウェアからなり、上述したメッセージ情報管理部の機能は、その機能を実現するためのプログラムをＣＰＵが実行することで実現される。
特開２００１−２７０３９９号公報

ところで、上記の車両用制御システムでは、メッセージ情報管理部が図１０のデッドライン監視処理を行うため、デッドライン監視のための処理負荷が増大してしまうという問題がある。

具体的には、メッセージ情報管理テーブルに登録されている全ての要求メッセージの各々について、メッセージ状態をチェックすることにより、その全要求メッセージの中から受付中メッセージを検索するため、受付中でない要求メッセージについても処理が発生するからである。例えば、図９の例では、識別番号が３や５の要求メッセージは、メッセージ状態が「要求待ち」であるため、本来ならばデッドライン監視の対象ではないが、それらの要求メッセージも処理対象となってしまう。特に、全ての要求メッセージのメッセージ状態が「要求待ち」である場合（つまり、受付中メッセージが１つも無い場合）には、検索のための処理が全て無駄になる。そして、ＡＰ間でやり取りするメッセージの数が増加するほど、デッドライン監視のための処理負荷が増大し、リアルタイム性が求められる制御処理の妨げになる可能性が生じる。

本発明は、こうした問題に鑑みなされたものであり、デッドライン監視のための処理負荷を低減することを目的としている。

上記目的を達成するためになされた請求項１のメッセージ管理装置は、複数の処理手段を備えた車両用制御システムに用いられるものであり、その車両用制御システムでは、処理手段の各々が制御プログラムに従って動作すると共に、車両における所定の機能を実現するための処理を連携して行う。尚、処理手段は、ＣＰＵが制御プログラムを実行することで実現される機能手段であり、実体としては、その制御プログラムである。また、各処理手段は、それぞれ異なるＣＰＵによって実現されても良いし、１つのＣＰＵによって実現されても良い。

そして、請求項１のメッセージ管理装置は、他の処理手段へ処理の実施を要求する処理手段（以下、要求側処理手段という）が、その処理の実施を要求するための要求メッセージを出力すると、その要求メッセージを受け付けて該要求メッセージの送り先である処理手段（以下、被要求側処理手段という）へ供給し、その要求メッセージを受けた被要求側処理手段が該要求メッセージに対応する処理を実施して該処理の結果を示す応答を出力すると、その応答を取得して前記要求側処理手段へ供給する。

ここで特に、請求項１のメッセージ管理装置では、受付中メッセージ記憶手段が、要求側処理手段から出力され得る複数種類の要求メッセージのうち、要求側処理手段から実際に出力されて受け付けたが、その要求メッセージに対する応答が未だ取得されていない要求メッセージ（以下、受付中メッセージという）のみを記憶する。

そして、デッドライン監視手段が、受付中メッセージ記憶手段に記憶されている受付中メッセージについて、その受付中メッセージが受け付けられた時から該受付中メッセージに対する応答が取得されるまでの経過時間を計測する計測処理と、その計測処理による計測時間が規定値に達したか否かによりデッドライン超過したか否かを判定する判定処理とを行う。

このような請求項１のメッセージ管理装置によれば、複数種類の要求メッセージのうち、実際に受け付けて処理完了待ちの受付中メッセージについてのみ、デッドライン監視手段が処理（計測処理及び判定処理）を行うこととなるため、デッドライン監視のための処理負荷を低減することができる。そして、このため、デッドライン監視手段を処理手段と同じＣＰＵで実現するように構成しても、処理手段の処理（即ち、制御プログラムによる処理）に支障をきたすことを回避することができる。

次に、請求項２のメッセージ管理装置では、請求項１のメッセージ管理装置において、受付中メッセージ記憶手段には、受付中メッセージと共に、デッドライン監視手段が前記計測処理及び判定処理を行う受付中メッセージの順序を示す順序情報も記憶される。そして、デッドライン監視手段は、受付中メッセージ記憶手段に複数の受付中メッセージが記憶されている場合には、その各受付中メッセージについての計測処理及び判定処理を、前記順序情報が示す順序で行う。

この構成によれば、デッドライン監視手段の処理対象となる受付中メッセージの順序（即ち、処理順序）を、受付中メッセージ記憶手段に記憶させる順序情報によって任意に設定することができる。

そこで、請求項３のメッセージ管理装置では、請求項２のメッセージ管理装置において、前記順序情報として、受付中メッセージの受け付け順（即ち、受け付けた順序）を示す情報を、受付中メッセージ記憶手段に記憶させるようになっている。

このようにすれば、順序情報の更新記憶を簡単に行うことができる。新たに受け付けた要求メッセージの順序を最後に設定すれば良いからである。
また、早期に出力された要求メッセージであって、出力されてからの経過時間が長い受付中メッセージほど、早い順序でデッドライン監視手段の処理（即ち、計測処理及び判定処理）が行われることとなるため、前記判定処理で用いる規定値が全ての要求メッセージで同じならば、デッドライン超過になる可能性の高い受付中メッセージほど、早い順序でデッドライン監視手段の処理が行われることとなり、その結果、デッドライン超過の発生を早期に検知することができるようになる。

一方、前記規定値が、要求メッセージの種別毎に定められる場合には、請求項４のように構成することが好ましい。
即ち、請求項４のメッセージ管理装置では、請求項２のメッセージ管理装置において、前記規定値は、要求メッセージの種別毎に定められており、前記順序情報として、前記計測処理による計測時間が前記規定値に近い受付中メッセージの順序を示す情報を、受付中メッセージ記憶手段に記憶させるようになっている。

このようにすれば、前記規定値が要求メッセージの種別毎に定められていても、デッドライン超過になる可能性の高い受付中メッセージほど、早い順序でデッドライン監視手段の処理が行われることとなり、その結果、デッドライン超過の発生を早期に検知することができるようになる。

ところで、請求項２〜４のメッセージ管理装置において、受付中メッセージ記憶手段は、請求項５に記載のように、前記順序情報を双方向リストのデータ構造で記憶するように構成するのが好ましい。双方向リストのデータ構造とは、リストの各要素が、直後の要素へのポインタだけでなく、直前の要素へのポインタも持っているデータ構造である。

そして、双方向リストのデータ構造であれば、そのリストにおける要素の追加及び削除や順序の入れ替えを行うための処理が簡単になるため、受付中メッセージに対する応答が取得されて、その受付中メッセージを受付中メッセージ記憶手段から削除する場合の処理や、新たな要求メッセージを受け付けて、その要求メッセージを受付中メッセージとして追加記憶する場合の処理が簡単になる。例えば、処理順序が先頭でも最後でもない受付中メッセージに対する応答が取得されて、その受付中メッセージを受付中メッセージ記憶手段から削除する場合には、その削除対象の受付中メッセージに対応する要素のポインタから、その要素の前後の要素を特定し、その特定した前後の要素のポインタを変更すれば良い。

また、順序情報を記憶するための双方向リストのデータ構造としては、請求項６に記載のように、受付中メッセージ記憶手段が記憶している受付中メッセージの個数が記録される領域（以下、個数領域という）と、順序が先頭である受付中メッセージの識別子が記録される領域と、複数種類の各要求メッセージの識別子毎にそれぞれ設けられる第１ポインタ領域及び第２ポインタ領域とを有し、受付中メッセージの識別子に対応する第１ポインタ領域には、その受付中メッセージよりも順序が１つ前の受付中メッセージの識別子が記録され、受付中メッセージの識別子に対応する第２ポインタ領域には、その受付中メッセージよりも順序が１つ後の受付中メッセージの識別子が記録される、というデータ構造が考えられる。

そして、このデータ構造によれば、デッドライン監視手段は、個数領域に記録されている情報により、受付中メッセージの数が０であるか否かを判定することができ、受付中メッセージの数が０である場合には、何もしなくても済むため、無駄な処理を効率的に低減することができる。

次に、請求項７の車両用制御システムは、請求項１〜６のメッセージ管理装置を備えた車両用制御システムである。そして、この車両用制御システムによれば、前述した請求項１〜６のメッセージ管理装置による効果を得ることができる。

また、請求項７の車両用制御システムは、例えば請求項８又は請求項９に記載のように構成することができる。
即ち、請求項８又は請求項９の車両用制御システムでは、要求側処理手段と被要求側処理手段とが、車両に搭載された別々の電子制御装置に設けられると共に、要求側処理手段が設けられた電子制御装置（以下、要求側装置という）と、被要求側処理手段が設けられた電子制御装置（以下、被要求側装置という）とが、車両内のネットワークを介して通信するように構成されている。

そして、請求項８の車両用制御システムでは、メッセージ管理装置が要求側装置に設けられ、そのメッセージ管理装置から被要求側処理手段への要求メッセージの供給が、前記ネットワークを介して行われると共に、メッセージ管理装置は、被要求側処理手段が出力する応答を、被要求側装置から前記ネットワークを介して受け取るように構成されている。

また、請求項９の車両用制御システムでは、メッセージ管理装置が被要求側装置に設けられ、そのメッセージ管理装置は、要求側処理手段が出力する要求メッセージを、要求側装置から前記ネットワークを介して受け取ると共に、そのメッセージ管理装置から要求側処理手段への応答の供給が、前記ネットワークを介して行われるように構成されている。

そして、このような請求項８又は請求項９の車両用制御システムによれば、前述した請求項１〜６のメッセージ管理装置による効果を得ることができる。
また、メッセージ管理装置は、要求側装置と被要求側装置との両方に設けても良い。この場合、要求側装置の要求側処理手段が出力した要求メッセージは、「要求側装置のメッセージ管理装置→車両内のネットワーク→被要求側装置のメッセージ管理装置→被要求側装置の被要求側処理手段」の順に伝達されることとなり、同様に、被要求側装置の被要求側処理手段が出力した応答は、「被要求側装置のメッセージ管理装置→車両内のネットワーク→要求側装置のメッセージ管理装置→要求側装置の要求側処理手段」の順に伝達されることとなる。

以下に、本発明が適用された実施形態の車両用制御システムについて説明する。
尚、実施形態の車両用制御システムは、図８〜図１０を用いて説明した車両用制御システムと比較すると、ＥＣＵに備えられるメッセージ情報管理部だけが異なっている。そこで、以下では、主にメッセージ情報管理部について説明する。また以下では、説明を簡略化するために、図８に示したＥＣＵのうち、リモートセキュリティＥＣＵ１１とＤ席ドアＥＣＵ１３との２つに着目すると共に、ＥＣＵ１１が、要求メッセージを出す方の要求側ＥＣＵであり、ＥＣＵ１３が、要求メッセージを受けて応答する方の被要求側ＥＣＵであるものとして説明する。

まず図１（Ａ）に示すように、本実施形態の車両用制御システムにおいても、ＥＣＵ１１には、ＡＰ１と、メッセージ情報管理部２１と、送信部Ｔ１及び受信部Ｒ１とが備えられており、ＥＣＵ１３には、ＡＰ３と、メッセージ情報管理部２３と、送信部Ｔ３及び受信部Ｒ３とが備えられている。そして、ＥＣＵ１１，１３は、車両内ネットワークとしての通信線Ｌを介して互いに通信可能に接続されている。

尚、本実施形態においても、各ＥＣＵ１１，１３に搭載されるメッセージ情報管理部２１，２３は、処理手段としてのＡＰ１，ＡＰ３と同様に、実際にはソフトウェアからなり、それらの機能は、その機能を実現するためのプログラムを、ＥＣＵ１１，１３に搭載されたＣＰＵ（図示省略）が実行することで実現される。また、各ＥＣＵ１１，１３に搭載されたメッセージ情報管理部２１，２３の構成及び機能は、基本的に同じであるが、以下では、ＥＣＵ１１のメッセージ情報管理部２１を例に挙げて説明する。

ここで、図１（Ｂ）に示すように、メッセージ情報管理部２１には、図９を用いて前述したメッセージ管理テーブル（本実施形態では、符号として３１を用いる）に加えて、メッセージ処理順序規定部３２が備えられている。

メッセージ処理順序規定部３２は、メッセージ情報管理部２１が、受付中の要求メッセージ（受付中メッセージ）と、その受付中メッセージに対して処理する順序（処理順序）とを記憶するために用いるリストであり、具体的には、図２に示すような双方向リストのデータ構造となっている。

尚、識別番号（ＩＮＤＥＸ）がＮ（Ｎは整数）の要求メッセージを、「要求メッセージ・Ｎ」と記載すると、図１（Ｂ）及び図２は、ＥＣＵ１１のＡＰ１から出された要求メッセージ・２（ＲＬ席ドアロック要求）と要求メッセージ・４（Ｐ席ドアロック要求）とが、メッセージ処理順序規定部３２に受付中メッセージとして既に記憶されている状態で、新たにＡＰ１から要求メッセージ・１（Ｄ席ドアロック要求）が出されて、その要求メッセージ・１がメッセージ処理順序規定部３２に受付中メッセージとして追加記憶される場合を例示している。また、本実施形態において、メッセージ処理順序規定部３２には、受付中メッセージの処理順序として、そのメッセージがＡＰから出されてメッセージ情報管理部２１に受け付けられた順序（つまり、そのメッセージの受付順）が記憶される。

図２に示すように、メッセージ処理順序規定部３２は、現在記憶している受付中メッセージの個数が記録される領域である「ＭＳＧ数」と、処理順序が先頭の受付中メッセージの識別番号が記録される領域である「ＴＯＰ」と、要求メッセージの識別番号毎にそれぞれ設けられる２つの領域である「前」及び「後」とを有している。そして、受付中メッセージの識別番号（ＩＮＤＥＸ）に対応する「前」の領域には、その受付中メッセージよりも処理順序が１つ前の受付中メッセージの識別番号が記録され、また、受付中メッセージの識別番号に対応する「後」の領域には、その受付中メッセージよりも順序が１つ後の受付中メッセージの識別番号が記録される。尚、本実施形態では、「前」の領域が第１ポインタ領域に相当し、「後」の領域が第２ポインタ領域に相当しており、また、それらが、処理順序を示す順序情報を記憶するための領域になっている。

このため、例えば、メッセージ処理順序規定部３２に、受付中メッセージとして、要求メッセージ・２と要求メッセージ・４とが記憶されると共に、それらの処理順序として「２→４」という順序が記憶されている場合、メッセージ処理順序規定部３２の記録状態は、図２（Ａ）のようになる。尚、処理順序が先頭の受付中メッセージ（図２（Ａ）では要求メッセージ・２）に対応する「前」の領域には、デフォルト値としての“０”が記録され、処理順序が最後の受付中メッセージ（図２（Ａ）では要求メッセージ・４）に対応する「後」の領域には、デフォルト値としての“１００”が記録される。

そして、図２（Ａ）の状態で、ＡＰ１から新たに要求メッセージ・１が出されたとすると、メッセージ処理順序規定部３２の記録状態は図２（Ｂ）のようになる。即ち、「ＭＳＧ数」の領域に記録される値が“２”から“３”に変更されると共に、識別番号＝４に対応する「後」の領域に記録される値が“１００”から“１”に変更され、更に、識別番号＝１に対応する「前」と「後」の各領域に“４”と“１００”がそれぞれ新たに記録されることとなる。

次に、ＥＣＵ１１，１３間でのメッセージ通信の流れ及びメッセージ状態の遷移について、図１及び図３を用い説明する。尚、図１及び図３における〈〉内の数字は、以下の説明における〈１〉〜〈１０〉にそれぞれ対応している。また、ここでは、ＥＣＵ１１におけるメッセージ情報管理部２１のメッセージ処理順序規定部３２に、ＡＰ１から出された要求メッセージ・２と要求メッセージ・４とが受付中メッセージとして既に記憶されている状態で、新たにＡＰ１から要求メッセージ・１が出され、その要求メッセージ・１に対応する処理（即ち、Ｄ席のドアロック処理）が、要求メッセージ・２と要求メッセージ・４とのそれぞれに対応する各処理よりも先に実施された場合を例に挙げて説明する。
〈１〉：まず、ＥＣＵ１１において、ＡＰ１は、Ｄ席のドアロックを要求する際に、Ｄ席ドアロック要求である要求メッセージ・１を、メッセージ情報管理部２１に対して発行する。

すると、メッセージ情報管理部２１は、その要求メッセージ・１を受け付けて、当該メッセージ情報管理部２１のメッセージ処理順序規定部３２に、その要求メッセージ・１を受付中メッセージとして追加記憶すると共に、その要求メッセージ・１の処理順序も追加記憶する。具体的には、メッセージ処理順序規定部３２の記録状態を、前述した図２（Ａ）の状態から図２（Ｂ）の状態に変更する。

そして更に、メッセージ情報管理部２１は、自己のメッセージ情報管理テーブル３１も更新する。具体的には、今回受け付けた要求メッセージ・１のメッセージ状態を、「要求待ち」から「要求あり」に変更する。
〈２〉：その後、メッセージ情報管理部２１は、今回受け付けた要求メッセージ・１をＡＰ３が搭載されたＥＣＵ１３へ送信するために、その要求メッセージ・１と、その要求メッセージ・１の送り先のＡＰ（この例ではＡＰ３）を示す送り先情報とを送信部Ｔ１に出力する。尚、ＡＰから出される要求メッセージには、それの識別番号が付加されており、メッセージ情報管理部２１は、ＡＰから受け付けた要求メッセージの識別番号に対応するルートを、自己のメッセージ情報管理テーブル３１から読み出すことで、その要求メッセージの送り先を特定する。

そして更に、メッセージ情報管理部２１は、メッセージ情報管理テーブル３１を更新する。具体的には、要求メッセージ・１の配信処理が完了したことから、その要求メッセージ・１のメッセージ状態を、「要求あり」から「応答待ち」に変更する。
〈３〉：そして、送信部Ｔ１は、メッセージ情報管理部２１から出力された要求メッセージ・１を、通信線Ｌを介してＥＣＵ１３へ送信する。尚、送信部Ｔ１は、例えば、どのＡＰがどのＥＣＵに搭載されているかを示す情報テーブルを備えており、その情報テーブルにメッセージ情報管理部２１からの送り先情報を適用することで、送信先のＥＣＵを特定する。
〈４〉：一方、ＥＣＵ１３において、受信部Ｒ３は、ＥＣＵ１１（ＡＰ１）からの要求メッセージ・１を受信してメッセージ情報管理部２３へ送る。

すると、ＥＣＵ１３においても、メッセージ情報管理部２３は、その要求メッセージ・１を受け付けて、自己のメッセージ処理順序規定部３２に、その要求メッセージ・１を受付中メッセージとして追加記憶すると共に、その要求メッセージ・１の処理順序も追加記憶する。例えば、記憶された受付中メッセージが要求メッセージ・１だけであれば、メッセージ処理順序規定部３２においては、「ＭＳＧ数」の領域に記録される値が“０”から“１”に変更され、「ＴＯＰ」の領域に記録される値が“０”から“１”に変更され、識別番号＝１に対応する「前」と「後」の各領域に“０”と“１００”がそれぞれ記録されることとなる。

そして更に、メッセージ情報管理部２３は、自己のメッセージ情報管理テーブル３１も更新する。具体的には、今回受け付けた要求メッセージ・１のメッセージ状態を、「要求待ち」から「要求あり」に変更する。
〈５〉：その後、メッセージ情報管理部２３は、今回受け付けた要求メッセージ・１をＡＰ３に出力すると共に、自己のメッセージ情報管理テーブル３１を更新する。具体的には、要求メッセージ・１のＡＰ３への配信が完了したことから、その要求メッセージ・１のメッセージ状態を、「要求あり」から「応答待ち」に変更する。
〈６〉：ＡＰ３は、要求メッセージ・１を受けると、その要求メッセージ・１に対応するＤ席のドアロック処理を実施し、その処理が完了すると、メッセージ情報管理部２３に対してＤ席のドアロック処理が完了したことを示すＤ席ドアロック完了応答を出す。

すると、メッセージ情報管理部２３は、そのＤ席ドアロック完了応答を取得し、自己のメッセージ処理順序規定部３２から、要求メッセージ・１を削除する。例えば、記憶されていた受付中メッセージが要求メッセージ・１だけであったならば、メッセージ処理順序規定部３２においては、「ＭＳＧ数」の領域に記録される値が“１”から“０”に変更され、「ＴＯＰ」の領域に記録される値が“１”から“０”に変更され、識別番号＝１に対応する「前」と「後」の各領域から数値が削除されることとなる。

そして更に、メッセージ情報管理部２３は、自己のメッセージ情報管理テーブル３１も更新する。具体的には、ＡＰ３からの応答を取得した要求メッセージ・１のメッセージ状態を、「応答待ち」から「応答あり」に変更する。
〈７〉：その後、メッセージ情報管理部２３は、ＡＰ３から取得したＤ席ドアロック完了応答をＡＰ１が搭載されたＥＣＵ１１へ送信するために、そのＤ席ドアロック完了応答と、その応答の送り先のＡＰ（この例ではＡＰ１）を示す送り先情報とを送信部Ｔ３に出力する。尚、ＡＰから出される応答にも、それに対応する要求メッセージの識別番号が付加されており、メッセージ情報管理部２３は、ＡＰから取得した応答の識別番号に対応するルートを、自己のメッセージ情報管理テーブル３１から読み出すことで、その応答の送り先（即ち、その応答に対応する要求メッセージの送信元）を特定する。

そして更に、メッセージ情報管理部２３は、自己のメッセージ情報管理テーブル３１を更新する。具体的には、要求メッセージ・１に対応する応答の送信処理が完了したことから、その要求メッセージ・１のメッセージ状態を、「応答あり」から初期状態の「要求待ち」に変更する。
〈８〉：そして、送信部Ｔ３は、メッセージ情報管理部２３から出力されたＤ席ドアロック完了応答を、通信線Ｌを介してＥＣＵ１１へ送信する。尚、送信部Ｔ３における送信先の特定手法は、前述した送信部Ｔ１と同様である。即ち、送信部Ｔ３も、例えば、どのＡＰがどのＥＣＵに搭載されているかを示す情報テーブルを備えており、その情報テーブルにメッセージ情報管理部２３からの送り先情報を適用することで、送信先のＥＣＵを特定する。
〈９〉：ＥＣＵ１１において、受信部Ｒ１は、ＥＣＵ１３（ＡＰ３）からのＤ席ドアロック完了応答を受信すると、その応答をＥＣＵ１１のメッセージ情報管理部２１へ送る。

すると、メッセージ情報管理部２１は、受信部Ｒ１からＤ席ドアロック完了応答を取得し、自己のメッセージ処理順序規定部３２から、要求メッセージ・１を削除する。具体的には、メッセージ処理順序規定部３２の記録状態を、前述した図２（Ｂ）の状態から図２（Ａ）の状態に書き換える。

そして更に、メッセージ情報管理部２１は、自己のメッセージ情報管理テーブル３１も更新する。具体的には、ＡＰ３からの応答を取得した要求メッセージ・１のメッセージ状態を、「応答待ち」から「応答あり」に変更する。
〈１０〉：その後、メッセージ情報管理部２１は、ＡＰ３からのＤ席ドアロック完了応答をＡＰ１に出力すると共に、自己のメッセージ情報管理テーブル３１を更新する。具体的には、要求メッセージ・１に対応する応答の送信処理が完了したことから、その要求メッセージ・１のメッセージ状態を、「応答あり」から初期状態の「要求待ち」に変更する。そして、ＡＰ１は、Ｄ席ドアロック完了応答により、ＥＣＵ１３のＡＰ３によるＤ席のドアロックが完了したことを認識する。

次に、ＥＣＵ１１のメッセージ情報管理部２１によって実施される各処理について、図４〜図７を用い説明する。
まず図４は、メッセージ情報管理部２１を構成する各タスクの実行タイミングを示している。

メッセージ情報管理部２１は、メッセージ情報送信処理のタスクと、メッセージ情報受信処理のタスクと、デッドライン監視処理のタスクとを有している。そして、メッセージ情報送信処理のタスクは一定時間Ｔ１毎に起床され、メッセージ情報受信処理のタスクは、受信部Ｒ１によって他のＥＣＵからの情報が受信されると起床される。また、デッドライン監視処理のタスクは、要求メッセージについてのデッドライン監視を行うためのものであり、上記一定時間Ｔ１よりも短い一定時間Ｔ２毎に起床される。

そして、図５に示すように、メッセージ情報送信処理では、まずＳ２１０にて、ＡＰ１が発行した要求メッセージを受け付ける。尚、ＡＰ１が発行した要求メッセージは、ＥＣＵ１１に搭載されたメモリにおける所定の記憶領域に記憶されるようになっており、Ｓ２１０では、その記憶領域からＡＰ１が発行した要求メッセージを読み込むことで、その要求メッセージを受け付ける。

次にＳ２２０にて、上記〈１〉で述べたように、メッセージ処理順序規定部３２に、今回受け付けた要求メッセージを受付中メッセージとして追加記憶すると共に、その要求メッセージの処理順序も追加記憶する。更に、Ｓ２２０では、今回受け付けた要求メッセージについて、メッセージ情報管理テーブル３１に記録されているデッドライン値を、デッドラインカウンタの初期値として設定する。例えば、今回要求メッセージ・１を受け付けた場合には、その要求メッセージ・１のデッドラインカウンタに、要求メッセージ・１のデッドライン値である１００が、初期値として設定されることとなる（図１（Ｂ）参照）。

そして、続くＳ２３０にて、上記〈１〉，〈２〉で述べたように、メッセージ情報管理テーブル３１を更新して、今回受け付けた要求メッセージのメッセージ状態を「要求待ち」→「要求あり」→「応答待ち」の順に遷移させると共に、今回受け付けた要求メッセージを送信する処理を行う。その後、当該メッセージ情報送信処理を終了する。

また、図６に示すように、メッセージ情報受信処理では、まずＳ３１０にて、他のＥＣＵのＡＰが出した応答（処理結果）を受信部Ｒ１から取得する。
次にＳ３２０にて、上記〈９〉で述べたように、メッセージ処理順序規定部３２から、今回取得した応答に対応する要求メッセージを削除する。

そして、続くＳ３３０にて、上記〈９〉，〈１０〉で述べたように、メッセージ情報管理テーブル３１を更新して、今回取得した応答に対応する要求メッセージのメッセージ状態を「応答待ち」→「応答あり」→「要求待ち」の順に遷移させると共に、今回取得した応答をＡＰ１に出力（通知）し、その後、当該メッセージ情報受信処理を終了する。

次に、図７に示すように、デッドライン監視処理では、まずＳ４１０にて、メッセージ処理順序規定部３２に受付中の要求メッセージ（受付中メッセージ）が記憶されているか否かを、メッセージ処理順序規定部３２の「ＭＳＧ数」を参照して判定する。つまり、「ＭＳＧ数」の値が“０”であれば、受付中メッセージが記憶されていないと判定する。

そして、メッセージ処理順序規定部３２に受付中メッセージが記憶されていないと判定した場合には（Ｓ４１０：ＮＯ）、そのまま当該デッドライン監視処理を終了する。
また、メッセージ処理順序規定部３２に受付中メッセージが記憶されていると判定した場合には（Ｓ４１０：ＹＥＳ）、Ｓ４２０に進み、メッセージ処理順序規定部３２に処理順序と共に記憶されている受付中メッセージのうち、処理順序が先頭のメッセージを、処理対象に設定する。つまり、メッセージ処理順序規定部３２の「ＴＯＰ」に記録されている識別番号の要求メッセージを処理対象に設定する。

そして、次のＳ４３０にて、メッセージ情報管理テーブル３１において処理対象の要求メッセージに対応するデッドラインカウンタをデクリメントする。尚、処理対象の要求メッセージに対応するデッドラインカウンタの値は、その処理対象の要求メッセージがメッセージ情報管理部２１に受け付けられた際に、前述した図５におけるＳ２２０の処理により、その要求メッセージに対応するデッドライン値に初期化されている。

次にＳ４４０にて、上記Ｓ４３０でデクリメントしたデッドラインカウンタの値が０になったか否かを判定し、０でなければ（Ｓ４４０：ＮＯ）、そのままＳ４６０へ移行するが、デッドラインカウンタの値が０になったならば（Ｓ４４０：ＹＥＳ）、Ｓ４５０に進んで、デッドライン超過処理を実施し、その後、Ｓ４６０に進む。尚、この要求側ＥＣＵでのデッドライン超過処理は、既述したように、処理対象の要求メッセージについて、メッセージ情報管理テーブル３１のメッセージ状態を「デッドライン超過」に設定すると共に（図３参照）、その要求メッセージを出したＡＰ（この例ではＡＰ１）に対してエラーを通知することにより、そのＡＰに、デッドライン超過となった要求メッセージに対する応答を待つのを止めさせて、次の処理へ移行させる。

Ｓ４６０では、メッセージ処理順序規定部３２に記憶されている全ての受付中メッセージについてＳ４３０及びＳ４４０の処理が終了したか否かを判定し、終了していなければ（Ｓ４６０：ＮＯ）、次のＳ４７０にて、メッセージ処理順序規定部３２に記憶されている受付中メッセージのうち、処理順序が現在の処理対象の次であるメッセージを、新たな処理対象に設定し、その後、上記Ｓ４３０へ戻る。

例えば、メッセージ処理順序規定部３２に、図２（Ｂ）の如く、要求メッセージ・２と要求メッセージ・４と要求メッセージ・１とが「２→４→１」の処理順序となるように記憶されていたとすると、Ｓ４２０では、メッセージ処理順序規定部３２の「ＴＯＰ」に記録されている識別番号＝２の要求メッセージ・２が最初の処理対象に設定される。そして、次のＳ４７０では、メッセージ処理順序規定部３２において、識別番号＝２に対応する「後」の領域に記録されている識別番号＝４の要求メッセージ・４が、次の処理対象に設定され、更に次のＳ４７０では、メッセージ処理順序規定部３２において、識別番号＝４に対応する「後」の領域に記録されている識別番号＝１の要求メッセージ・１が、次の処理対象に設定されることとなる。

また、上記Ｓ４６０にて、全ての受付中メッセージについて処理が終了したと判定したならば（Ｓ４６０：ＹＥＳ）、そのまま当該デッドライン監視処理を終了する。
一方、被要求側のＥＣＵ１３においても、メッセージ情報管理部２３が、図５〜図７と同様の処理を実施する。

例えば、ＥＣＵ１３において、メッセージ情報管理部２３は、受信部Ｒ３によって他のＥＣＵからの要求メッセージが受信されると、図５のメッセージ情報送信処理を実行する。そして、そのメッセージ情報送信処理では、Ｓ２１０にて、受信部Ｒ３が受信した要求メッセージを受け付け、次のＳ２２０にて、上記〈４〉で述べたように、メッセージ処理順序規定部３２に、今回受け付けた要求メッセージを受付中メッセージとして追加記憶すると共に、その要求メッセージの処理順序も追加記憶する。また、今回受け付けた要求メッセージに対応するデッドラインカウンタの値を、その要求メッセージに対応するデッドライン値に設定する。そして、続くＳ２３０にて、上記〈４〉，〈５〉で述べたように、メッセージ情報管理テーブル３１におけるメッセージ状態を遷移させると共に、今回受け付けた要求メッセージをＡＰ３に出力する。

また、ＥＣＵ１３において、メッセージ情報管理部２３は、ＡＰ３から要求メッセージに対する応答が出されると、図６のメッセージ情報受信処理を実行する。そして、そのメッセージ情報受信処理では、まずＳ３１０にて、ＡＰ３が出した応答（処理結果）を取得し、次にＳ３２０にて、上記〈６〉で述べたように、メッセージ処理順序規定部３２から、今回取得した応答に対応する要求メッセージを削除する。そして、続くＳ３３０にて、上記〈６〉，〈７〉で述べたように、メッセージ情報管理テーブル３１におけるメッセージ状態を遷移させると共に、今回取得した応答を、その応答に対応する要求メッセージの送信元へ送信するための処理を行う。

そして更に、ＥＣＵ１３においても、メッセージ情報管理部２３は、一定時間毎に図７のデッドライン監視処理を実施する。尚、そのＥＣＵ１３側のデッドライン監視処理におけるＳ４５０のデッドライン超過処理では、処理対象の要求メッセージについて、メッセージ情報管理テーブル３１のメッセージ状態を「デッドライン超過」に設定するだけである。

つまり、ＥＣＵ１１側のメッセージ情報管理部２１は、ＡＰ１からの要求メッセージをＥＣＵ１１内で受け取って、その要求メッセージのＡＰ３への供給を通信線Ｌを介して行うと共に、ＡＰ３が出力する応答もＥＣＵ１３から通信線Ｌを介して受け取るようになっており、このため、図１（Ａ）における〈１〉から〈９〉までの期間を対象としてデッドライン監視を行っている。

これに対して、ＥＣＵ１３側のメッセージ情報管理部２３は、要求側のＡＰ１が出力する要求メッセージをＥＣＵ１１から通信線Ｌを介して受け取ってＡＰ３に供給すると共に、ＡＰ３が出力する応答はＥＣＵ１３内で受け取って、その応答のＡＰ１への供給を通信線Ｌを介して行うようになっており、このため、図１（Ａ）における〈４〉から〈６〉までの期間を対象としてデッドライン監視を行っている。

尚、上記実施形態では、ＥＣＵ１１が要求側装置に相当し、ＥＣＵ１３が被要求側装置に相当し、ＡＰ１が要求側処理手段に相当し、ＡＰ３が被要求側処理手段に相当し、メッセージ情報管理部２１，２３が、メッセージ管理装置に相当している。そして、メッセージ処理順序規定部３２が、受付中メッセージ記憶手段に相当し、図７のデッドライン監視処理が、デッドライン監視手段に相当している。また、図７のデッドライン監視処理においては、Ｓ４３０の処理が計測処理に相当し、Ｓ４４０の処理が判定処理に相当している。

以上のような本実施形態の車両用制御システムでは、各ＥＣＵ１１，１３のメッセージ情報管理部２１，２３が、ＡＰ間でやり取りされる複数種類の要求メッセージ（メッセージ情報管理テーブル３１に登録された要求メッセージ）のうち、受付中の要求メッセージをメッセージ処理順序規定部３２に記憶し、そのメッセージ処理順序規定部３２に記憶されている要求メッセージについてのみ、図７のデッドライン監視処理を行うようになっており、また、メッセージ処理順序規定部３２に要求メッセージが記憶されていない場合は、デッドライン監視処理は実質的に行われないため、デッドライン監視のための処理負荷を低減することができる。

つまり、メッセージ情報管理テーブル３１に静的に登録された要求メッセージ全てを対象に「要求あり」又は「応答待ち」状態のメッセージを定期的に検索してデッドライン監視する方式よりも、定期的に検索する処理及び時間を省くことができる。

このため、本実施形態によれば、ＥＣＵにおけるＡＰの処理（上記例では、リモートコントロールシステムを実現するための制御処理）に支障をきたすことを回避することができる。

また、本実施形態では、メッセージ処理順序規定部３２に、受付中メッセージの処理順序も記憶するようにしているが、そのためにメッセージ処理順序規定部３２のデータ構造を、図２に示した双方向リストのデータ構造としている。

このため、応答の取得が完了した要求メッセージをメッセージ処理順序規定部３２から削除する場合の処理や、新たに受け付けた要求メッセージをメッセージ処理順序規定部３２に追加記憶する場合の処理が簡単になる。

更に、図２のデータ構造によれば、「ＭＳＧ数」の領域に記録されている値を参照することで、受付中メッセージの数が０であるか否かを即座に判定することができる。そして、受付中メッセージの数が０である場合には、図７のＳ４２０以降の処理をしなくても済むため、無駄な処理を効率的に低減することができる。

以上、本発明の一実施形態について説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲において、種々なる態様で実施し得ることは勿論である。

例えば、各ＥＣＵのメッセージ情報管理部２１，２３は、図５のＳ２２０にて、今回受け付けた要求メッセージに対応するデッドラインカウンタの値を、その要求メッセージに対応するデッドライン値に設定した後、或いは図７のデッドライン監視処理を行う直前に、メッセージ処理順序規定部３２に記憶される受付中メッセージの処理順序（具体的には、図２のメッセージ処理順序規定部３２における「前」及び「後」の値）を、デッドラインカウンタの値が０に近い受付中メッセージの順序に設定する処理を行うようにしても良い。つまり、図７におけるＳ４３０のダウンカウントにより計測される時間がデッドライン値（規定値に相当）に近い受付中メッセージの順序の情報を、処理順序を示す順序情報としてメッセージ処理順序規定部３２に記憶させるのである。そして、このようにすれば、デッドラインカウンタの値が０になる（即ち、デッドライン超過になる）可能性の高い受付中メッセージほど、早い順序でデッドライン監視処理（図７）におけるＳ４３０及びＳ４４０の処理が行われることとなり、その結果、デッドライン超過の発生をより早期に検知することができるようになる。

一方、メッセージ情報管理部２１，２３は、要求側のＥＣＵ１１と被要求側のＥＣＵ１３との一方だけに設けても良い。
また、車両用制御システムの形態としては、複数のＡＰが１つのＥＣＵに搭載されて、その各ＡＰが同じＥＣＵ内でメッセージ情報管理部２１（又は２３）を介し要求メッセージ及び応答をやり取りする形態でも良い。

尚、ＥＣＵに搭載される送信部と受信部は、ハードウェア回路のみからなるものでも良いし、その一部がソフトウェアからなるものでも良い。

実施形態の車両用制御システムの構成を説明する説明図である。 メッセージ処理順序規定部を説明する説明図である。 メッセージ状態の遷移を表す状態遷移図である。 メッセージ情報管理部を構成する各タスクの実行タイミングを示す説明図である。 メッセージ情報送信処理の内容を表すフローチャートである。 メッセージ情報受信処理の内容を表すフローチャートである。 デッドライン監視処理の内容を表すフローチャートである。 車両用制御システムの一例であるリモートコントロールシステムの構成を表す構成図である。 メッセージ情報管理テーブルの内容を表す説明図である。 解決したい課題を有するデッドライン監視処理の内容を表すフローチャートである。

符号の説明

１〜６…アプリケーションコンポーネント（ＡＰ）、１０〜１６…電子制御装置（ＥＣＵ）、２１，２３…メッセージ情報管理部、３１…メッセージ情報管理テーブル、３２…メッセージ処理順序規定部、Ｌ…通信線（車両内のネットワーク）、Ｒ１，Ｒ３…受信部、Ｔ１，Ｔ３…送信部

Claims (9)

1. それぞれが制御プログラムに従って動作すると共に、車両における所定の機能を実現するための処理を連携して行う複数の処理手段を備えた車両用制御システムに用いられ、
   他の処理手段へ処理の実施を要求する処理手段（以下、要求側処理手段という）が、その処理の実施を要求するための要求メッセージを出力すると、その要求メッセージを受け付けて該要求メッセージの送り先である処理手段（以下、被要求側処理手段という）へ供給し、その要求メッセージを受けた被要求側処理手段が該要求メッセージに対応する処理を実施して該処理の結果を示す応答を出力すると、その応答を取得して前記要求側処理手段へ供給するメッセージ管理装置であって、
   前記要求側処理手段から出力され得る複数種類の要求メッセージのうち、前記要求側処理手段から実際に出力されて受け付けたが、その要求メッセージに対する応答が未だ取得されていない要求メッセージ（以下、受付中メッセージという）のみを記憶する受付中メッセージ記憶手段と、
   前記受付中メッセージ記憶手段に記憶されている受付中メッセージについて、その受付中メッセージが受け付けられた時から該受付中メッセージに対する応答が取得されるまでの経過時間を計測する計測処理と、その計測処理による計測時間が規定値に達したか否かによりデッドライン超過したか否かを判定する判定処理とを行うデッドライン監視手段と、
   を備えていることを特徴とする車両用制御システムのメッセージ管理装置。
2. 請求項１に記載の車両用制御システムのメッセージ管理装置において、
   前記受付中メッセージ記憶手段には、前記受付中メッセージと共に、前記デッドライン監視手段が前記計測処理及び判定処理を行う受付中メッセージの順序を示す順序情報も記憶され、
   前記デッドライン監視手段は、前記受付中メッセージ記憶手段に複数の受付中メッセージが記憶されている場合には、その各受付中メッセージについての前記計測処理及び判定処理を、前記順序情報が示す順序で行うこと、
   を特徴とする車両用制御システムのメッセージ管理装置。
3. 請求項２に記載の車両用制御システムのメッセージ管理装置において、
   前記順序情報として、前記受付中メッセージの受け付け順を示す情報を、前記受付中メッセージ記憶手段に記憶させること、
   を特徴とする車両用制御システムのメッセージ管理装置。
4. 請求項２に記載の車両用制御システムのメッセージ管理装置において、
   前記規定値は、要求メッセージの種別毎に定められており、
   前記順序情報として、前記計測処理による計測時間が前記規定値に近い受付中メッセージの順序を示す情報を、前記受付中メッセージ記憶手段に記憶させること、
   を特徴とする車両用制御システムのメッセージ管理装置。
5. 請求項２ないし請求項４の何れか１項に記載の車両用制御システムのメッセージ管理装置において、
   前記受付中メッセージ記憶手段は、前記順序情報を、双方向リストのデータ構造で記憶すること、
   を特徴とする車両用制御システムのメッセージ管理装置。
6. 請求項５に記載の車両用制御システムのメッセージ管理装置において、
   前記双方向リストのデータ構造は、
   前記受付中メッセージ記憶手段が記憶している受付中メッセージの個数が記録される領域と、順序が先頭である受付中メッセージの識別子が記録される領域と、前記複数種類の各要求メッセージの識別子毎にそれぞれ設けられる第１ポインタ領域及び第２ポインタ領域とを有し、前記受付中メッセージの識別子に対応する第１ポインタ領域に、その受付中メッセージよりも順序が１つ前の受付中メッセージの識別子が記録され、前記受付中メッセージの識別子に対応する第２ポインタ領域に、その受付中メッセージよりも順序が１つ後の受付中メッセージの識別子が記録されるデータ構造であること、
   を特徴とする車両用制御システムのメッセージ管理装置。
7. 請求項１ないし請求項６の何れか１項に記載のメッセージ管理装置を備えた車両用制御システム。
8. 請求項７に記載の車両用制御システムにおいて、
   前記要求側処理手段と前記被要求側処理手段とが、車両に搭載された別々の電子制御装置に設けられると共に、
   前記要求側処理手段が設けられた電子制御装置（以下、要求側装置という）と、前記被要求側処理手段が設けられた電子制御装置（以下、被要求側装置という）とが、車両内のネットワークを介して通信するように構成されており、
   更に、前記メッセージ管理装置は、前記要求側装置に設けられ、
   前記メッセージ管理装置から前記被要求側処理手段への前記要求メッセージの供給が、前記ネットワークを介して行われると共に、前記メッセージ管理装置は、前記被要求側処理手段が出力する前記応答を、前記被要求側装置から前記ネットワークを介して受け取るように構成されていること、
   を特徴とする車両用制御システム。
9. 請求項７に記載の車両用制御システムにおいて、
   前記要求側処理手段と前記被要求側処理手段とが、車両に搭載された別々の電子制御装置に設けられると共に、
   前記要求側処理手段が設けられた電子制御装置（以下、要求側装置という）と、前記被要求側処理手段が設けられた電子制御装置（以下、被要求側装置という）とが、車両内のネットワークを介して通信するように構成されており、
   更に、前記メッセージ管理装置は、前記被要求側装置に設けられ、
   前記メッセージ管理装置は、前記要求側処理手段が出力する前記要求メッセージを、前記要求側装置から前記ネットワークを介して受け取ると共に、前記メッセージ管理装置から前記要求側処理手段への前記応答の供給が、前記ネットワークを介して行われるように構成されていること、
   を特徴とする車両用制御システム。

Images