JP4238258B2 - 車載電子制御ユニットのタスク管理装置及びタスク管理方法 - Google Patents

Description

本発明は、車載電子制御ユニットのタスク管理を行う装置及びその方法に関する。

近年の車両では、車内ネットワークを通じて相互接続された電子制御ユニット（ＥＣＵ）による分散処理を通じて、車両全体の統括的な制御が実現されている。こうした車内ネットワークにおいて、より有機的な電子制御ユニット間の連携を実現させる仕組みとして、ＩＴ分野で実用されている遠隔手続呼出（ＲＰＣ：Remote Procedure Call ）の導入が検討されている。ＲＰＣは、受信したクライアントからの要求（関数コールなど）に対して処理を実施し、その結果をクライアントに応答するクライアント＝サーバモデルでの、クライアント・サーバ間のメッセージ通信に係るプロセス間通信プロトコルであり、分散コンピューティングの基礎技術となっている。

図１０は、車両制御システムにＲＰＣに基づくメッセージ通信機能を設けた場合のシステムのモデル構造を示している。同図に示すように、車内ネットワーク５０を介して互いに接続されたＥＣＵ１，ＥＣＵ２はそれぞれメッセージ通信機構５１，５２を備えている。メッセージ通信機構５１，５２は、クライアント＝サーバ間のメッセージ（処理要求やその処理結果の応答など）の通信を仲介する。より具体的には、メッセージ通信機構５１，５２は、受信したメッセージを、その内容から通知先を判別してその通知先へ送信する処理を行う。なお実際には、メッセージ通信機構５１，５２、クライアント５３、５４及びサーバ５５は、ＥＣＵ１，ＥＣＵ２のハードウェア上で実行されるソフトウェアによってそれぞれその機能が実現されている。

こうした車載制御システムでのサービス実行処理の態様を、図１１に示すタイミングチャートを参照して説明する。ここでは、ＥＣＵ２のサーバ５５が、各クライアント５３，５４に対してサービスＡ、サービスＢを公開しているものとする。

さて同図に示すように、ＥＣＵ２のクライアント５４が上記サービスＡの処理要求を行うと、その処理要求は同じＥＣＵ２のメッセージ通信機構５２に渡される。ここでメッセージ通信機構５２は、要求された処理を行うサービスを起床させるためのメッセージ受信処理を行い、サーバ５５の公開するサービスＡを起床させる。サーバ５５にてその起床されたサービスＡの処理が実行されると、その結果は再びメッセージ通信機構５２を介してクライアント５４に応答される。

一方、同図では、上記クライアント５４のサービスＡの処理要求に若干遅れて、ＥＣＵ１のクライアント５３がサービスＢの処理要求を行っている。この処理要求は、まずＥＣＵ１のメッセージ通信機構５１が受け取り、その通知先の確認がなされた後、メッセージとしてＥＣＵ２に送られる。そのメッセージを受信したＥＣＵ２のメッセージ通信機構５２は、メッセージ受信処理を行ってサービスＢを起床させる。サーバ５５にてその起床されたサービスＢが実行されると、その結果はメッセージ通信機構５１，５２を中継してクライアント５３に応答される。

ここで上記サービスＡの実行は、同じＥＣＵ内のサーバに対するローカルのサービス呼出として、上記サービスＢの実行は、別のＥＣＵのサーバに対するリモートのサービス呼出としてそれぞれ行われている。ただし、ＥＣＵ間のメッセージ（サービスの処理要求や処理結果）の送受はメッセージ通信機構５１，５２に全て委ねられており、各クライアント５３，５４やサーバ５５側からは隠蔽されているため、ローカル、リモートの区別なくサービスの呼出を行うことができるようになっている。

上記のようなＲＰＣに基づいた通信プロトコルを採用すれば、車両制御の分散処理システムを容易に構築可能となるものの、以下のような問題があり、現状では実用に至ってはいない。

上記ＲＰＣに基づくメッセージ通信機能によるサービス実行処理では、起床の単位、すなわち処理プログラムの読み込み及び実行の単位であるタスクには、その１つひとつに、それぞれ１つのサービスが割り当てられており、要求されたサービスの数だけ、タスクの起床が行われるようになっている。こうした仕組みは、機能の並列実行性を高めるには有効となっている。

一方、エンジンルーム等の苛酷な環境下での長年の耐用が必要とされる車載ＥＣＵでは、一般用途に比べて信頼性や耐久性の高い、高価な電子部品が使用されること、設置スペースが限られていること、などのため、ハードウェアリソースの制約は厳しいものとなっている。そのため、車載ＥＣＵでは、処理プログラムの読み込みに伴うメモリ使用量やＣＰＵ負荷の一時的な増大といった、サービス（タスク）起床時のオーバーヘッドは無視し難いものとなっており、タスクの起床が高頻度で行われると、ハードウェアリソースが不足して、処理の停滞を招く虞がある。処理のリアルタイム性が求められる車両制御システムでは、こうしたリソース不足による処理の停滞は致命的な問題となる。

なお、上記のようなＲＰＣに基づくメッセージ通信機能の搭載された車載ＥＣＵ以外でも、タスク呼出に基づく処理の実施を行うことがある。例えば、複数の制御で共通して実施される処理をタスクとして管理し、その処理が必要となる毎にそのタスクを起床して実施することで、共通する処理についてのプログラムコードを共有して、プログラムの軽量化を図ることがある。こうした場合にも、タスクの起床が高頻度でなされれば、やはりハードウェアリソースの不足を招く虞がある。

本発明はこうした実状に鑑みてなされたものであって、その解決しようとする課題は、より少ないハードウェアリソースでタスク呼出に基づく処理を行うことのできる車載電子制御装置のタスク管理装置及びタスク管理方法を提供することにある。

上記課題を解決するため、請求項１に記載の発明では、サービスの処理要求の受信に応じてそのサービスに割り付けられたタスクを起床して該サービスの処理を行わせる車載電子制御ユニットのタスク管理システムにおいて、前記タスクの１つに対して複数のサービスを割り付けるとともに、前記サービスの処理要求の受信時に、その前記サービスに割り
付けられたタスクが既に実行中であるか否かを判定する判定手段と、受信した前記サービスの処理要求をそのサービスの処理が開始されるまで格納する格納手段と、割り当てられたタスクが実行中でないサービスの処理要求がその格納手段に格納されているか否かを定期的に確認し、格納されていることが確認されたときには、そのサービスに割り当てられたタスクを起床するサービス実行状況監視手段と、を備え、前記判定手段が肯定判定したときには、そのときに受信した前記サービスの処理要求に応じた前記タスクの起床を行わずに、前記実行中のタスクにそのまま当該サービスの処理を行わせることとしている。

上記構成では、タスクによるサービスの処理の実行中に、そのタスクに割り当てられた別のサービスの処理要求が受信されると、その新たに受信した処理要求のサービスの処理が、実行中のタスクにより引き続き実行されるようになる。すなわち、一度の起床で複数のサービスを処理することができるようになる。そのため、起床の頻度が抑えられ、タスク起床によるオーバーヘッドが低減されるようになる。
なお、サービスの処理を終え、タスクが将に終了しようとしているタイミングで、そのタスクに割り当てられた別のサービスの処理要求が受信されると、その時点ではタスクは一応は実行中であるので、その受信した処理要求に応じたタスク起床はなされないようになる。しかしながら、その時点でタスクの終了が既に決定されていた場合には、新たに受信した処理要求に応じたサービスの処理を実行しないまま、タスクが終了されてしまうことがある。
その点、上記請求項１によるように、受信した前記サービスの処理要求をそのサービスの処理が開始されるまで格納する格納手段と、割り当てられたタスクが実行中でないサービスの処理要求がその格納手段に格納されているか否かを定期的に確認し、格納されていることが確認されたときには、そのサービスに割り当てられたタスクを起床するサービス実行状況監視手段とを備えることとすれば、タスクが終了してしまい、サービスが処理待ちのまま放置された場合にも、サービス実行状況監視手段が、その放置状態のサービス処理要求を検出して、タスクを再び起床させるため、処理待ちのままサービスの処理が放置される状況が回避されるようになる。

こうしたタスク管理装置での上記判定手段の判定は、請求項２によるように、サービスの識別情報をキー項目とし、各サービスに割り当てられたタスクの識別情報をデータ項目とするサービス割付テーブルを備えるとともに、そのサービス割付テーブルを参照して、前記処理要求を受信したサービスの割り付けられたタスクの識別情報を取得し、その取得した識別情報と現在実行中のタスクの識別情報との対比に基づくことで、容易且つ確実に行うことができる。

また請求項３によるように、サービスの処理を完了する毎に、当該タスクに割り当てられた他のサービスの処理要求が前記格納手段に格納されているか否かを確認し、格納されていることが確認されたときには、その処理要求を読み込んでその処理を引き続き実施し、そうでなければ自身を終了させる処理ルーチンを当該タスク管理装置にて管理される各タスクに組み込むようにすれば、外部に別途の手段を設けずとも、タスク自らが複数サービスの処理を継続実施するようになる。

なお、こうしたタスク管理装置を、請求項４に記載のような、遠隔手続呼出に基づくメッセージ通信機能を備えて他の車載電子制御ユニットとの通信を行う車載電子制御ユニットに適用すれば、低リソースで動作可能な、ＲＰＣに基づく分散処理型の車両制御システムを構築することができる。

一方、上記課題を達成するため、車載電子制御ユニットのタスク管理方法としての請求項５に記載の発明では、車載された電子制御ユニットでのサービスの処理要求の受信に応じて起床されるタスクの管理を行う方法であって、前記タスクの１つに対して複数のサービスを割り付けるとともに、前記サービスの処理要求の受信時にそのサービスに割り当てられたタスクが実行中であるか否かを判定する工程と、前記判定において前記タスクが実行中でないと判定されたときには、同タスクを起床して前記処理要求を受信したサービスの処理を行わせ、そうでないときには、同タスクを新たに起床せずにその実行中のタスクに前記処理要求を受信したサービスの処理を引き続き実行させる工程と、受信した前記サービスの処理要求をそのサービスが開始されるまで格納するバッファを設けるとともに、そのバッファを定期的に参照し、該バッファに処理要求が格納され、且つ割り当てられたタスクが実行中でないサービスが確認されたときには、そのサービスに割り当てられたタスクを起床する工程と、を備えることとした。

上記方法では、サービスの処理要求の受信時に、そのサービスに割り付けられたタスクが、別のサービスの処理を実行中であると、その実行中のサービスがその別のサービスの処理に引き続き、新たに受信した処理要求のサービスを実行するようになる。そのため、一度の起床で複数のサービスの実行が可能となり、起床の頻度が抑えられることから、タスク起床によるオーバーヘッドが低減されるようになる。
また同請求項５によるように、受信した前記サービスの処理要求をそのサービスが開始されるまで格納するバッファを設けるとともに、そのバッファを定期的に参照し、該バッファに処理要求が格納され、且つ割り当てられたタスクが実行中でないサービスが確認されたときには、そのサービスに割り当てられたタスクを起床する工程を備えることとすれば、サービスが処理されぬまま放置される状況の発生が回避されるようになる。

こうしたタスク管理方法でのタスク実行中の可否判定は、請求項６によるように、サービスの識別情報をキー項目とし、各サービスに割り当てられたタスクの識別情報をデータ項目とするサービス割付テーブルを設けるとともに、前記処理要求を受信したサービスの識別情報をキーとして前記サービス割付テーブルを参照して該サービスに割り付けられたタスクの識別情報を取得する工程、及びその取得した識別情報と現在実行中のタスクの識別情報と対比する工程、を通じて行うことも可能である。

また上記タスク管理方法において請求項７によるように、前記サービスの処理を完了する毎に前記バッファを参照し、当該タスクに割り当てられた他のサービスの処理要求が同バッファに有るか否かを判定する処理と、その判定が肯定判定されたときには、前記バッファから前記処理要求を取得してその処理を引き続き行い、否定判定されたときには、自身を終了させる処理と、からなる処理ルーチンを各タスクに組み込むようにすれば、タスク自らにより、複数サービスの処理を継続実施されるようになる。

なお、こうしたタスク管理方法を、請求項８に記載のような、遠隔手続呼出に基づくメッセージ通信機能を備えて他の車載電子制御ユニットとの通信を行う車載電子制御ユニットのタスク管理に適用すれば、低リソースで動作可能な、ＲＰＣに基づく車載制御の分散処理システムが構築されるようになる。

本発明の車載電子制御装置のタスク管理装置及びタスク管理方法によれば、一度の起床で複数のサービスを処理して、タスクの起床頻度を抑えることで、タスク起床によるオーバーヘッドが低減されるようになる。そのため、より少ないハードウェアリソースでタスク呼出に基づく処理を実施することができる。

以下、本発明を具体化した一実施形態を、図１〜図９を参照して詳細に説明する。ここでは、エンジンと電動機との２つの駆動源を備えるハイブリッド車両の制御システムに本発明を適用した場合を説明する。なお以下の説明では、簡単のため、エンジンＥＣＵとハイブリッドＥＣＵとの２つのＥＣＵのみによって車両制御システムが構成されているものとする。またサービスを公開するサーバも、エンジンＥＣＵに設けられたエンジン制御サーバの一つのみとし、そのエンジン制御サーバは、エンジンを始動させるためのエンジン始動サービス、エンジンの回転速度（ＮＥ）を取得する回転速度取得サービスの２つサービスのみをクライアントに公開するものとする。

まず、こうした車両制御システムの全体構成を説明する。図１は、そうした車両制御システムの模式的なモデル構成を示したものとなっている。この車両制御システムは、遠隔手続呼出（ＲＰＣ）に基づく分散処理にて車両制御を行うシステムとして構成されている。

同図に示すように、ハイブリッドＥＣＵ１０及びエンジンＥＣＵ１１は、車内ネットワーク１２を介して相互通信可能に接続されている。ハイブリッド車両の駆動源間の協調制御を司るハイブリッドＥＣＵ１０には、上記ＲＰＣに基づく分散処理に必要なメッセージ通信機能を担うメッセージ通信機構１３が設けられるとともに、協調制御に係る各種処理を行うクライアント１４が稼働されている。一方、エンジン制御を司るエンジンＥＣＵ１１には、やはりメッセージ通信機構１５が設けられ、またエンジン制御に係る各種処理を行うクライアント１６と、上記２つのサービスをクライアント１４．１６に公開するエンジン制御サーバ１７とが稼働されている。このエンジンＥＣＵ１１のメッセージ通信機構１５は、上記メッセージ通信機能を担うとともに、エンジン制御サーバ１７の公開するサービスの呼出に係る処理を担ってもいる。ちなみに実際には、上記メッセージ通信機構１３，１５、クライアント１４，１６及びエンジン制御サーバ１７はそれぞれ、各ＥＣＵのハードウェア上で実行されるソフトウェアによってその機能が実現されるようになっている。

続いて、上記エンジンＥＣＵ１１のメッセージ通信機構１５の詳細を、図２を参照して説明する。本実施形態では、こうしたメッセージ通信機構１５に、本発明に係るタスク管理装置、タスク管理方法を適用する構成となっている。なお図２は、メッセージ通信機構１５のサービス呼出に係る構成要素の相関をブロック図にて模式的に示したものである。

本実施形態では、クライアントによる処理要求の単位であるサービスと、その処理要求に応じたサーバのプロセスの起床、実行の単位であるタスクとを別々に管理するようにしている。そして、高いリアルタイム性が必要とされるサービス以外は、単一のタスクに複数のサービスを割り付けるようにしている。例えば上述したエンジン始動サービス、及びエンジン回転速度取得サービスは、双方共にエンジン制御タスクに割り付けられている。すなわち、エンジン始動サービス、及び回転速度取得サービスのいずれの処理要求に対しても、エンジン制御サーバ１７からはエンジン制御タスクが起床されるようにしている。そして本実施形態では、同一のタスクに割り当てられた複数のサービスを、起床された同一のタスク内で処理させることで、タスク起床の頻度を抑え、その起床によるオーバーヘッドを低減するようにしている。

さて、同図２に示すように、エンジンＥＣＵ１１のメッセージ通信機構１５には、メッセージ受信処理部２０、エンジン始動サービス用、及び回転速度取得サービス用の受信キュー２１，２２、サービス割付テーブル２３及びサービス実行状況監視部２４が設けられている。メッセージ受信処理部２０は、クライアント１４，１６からのサービスの処理要求のメッセージを受信するとともに、要求されたサービスに割り当てられたタスクを起床させる処理を実行する。受信キュー２１，２２は、メッセージ受信処理部２０により受信された各サービスの処理要求のメッセージを、そのメッセージに対する処理が開始されるまで格納するバッファとなっている。

一方、サービス割付テーブル２３は、サービスの識別番号（ＩＤ）をキー項目とし、各サービスに割り当てられたタスクのＩＤをデータ項目とするデータテーブルであり、サービスに割り当てられたタスクの調査に使用される。ここでのサービス割付テーブル２３は、図３のように構成されている。ちなみに、ここでは、エンジン制御タスクのＩＤには「０ｘ０１」が、エンジン始動サービスのＩＤには「０ｘＦ１」が、回転速度取得サービスのＩＤには「０ｘＦ２」が、それぞれ設定されている。ちなみに、タスクのＩＤには「０ｘ０１」から始まる通番が、サービスのＩＤには「０ｘＦ１」から始まる通番が、それぞれ割り振られるようになっている。なお、ここでは、「＊」を１６進数表記の「０」〜「Ｆ」（１０進数表記の「１５」）の任意の数値としたとき、「０ｘ＊＊」は、１６進数表記の数値「＊＊」を示すこととする。

更にサービス実行状況監視部２４は、処理要求がなされたものの、処理が行われないまま放置されたサービスの有無を監視し、放置されたサービスの確認に応じてそのサービスに割り当てられたタスクを起床させるタスクを実行する。なお、このサービス実行状況監視部２４の詳細については後述することとする。

次に、以上のように構成されたメッセージ通信機構１５でのサービス実行処理の詳細を、図４を参照して説明する。図４は、メッセージ通信機構１５によるサービス実行の処理態様の一例を示している。

同図では、まずハイブリッドＥＣＵ１０のクライアント１４により、エンジン始動サービスの処理要求が行われている。この処理要求のメッセージを受信するとメッセージ受信処理部２０は、メッセージ受信処理を実行する。そしてこのメッセージ受信処理においてメッセージ受信処理部２０は、受信したメッセージを受信キュー２１に格納する。またメッセージ受信処理部２０は、サービス割付テーブル２３を参照して要求されたサービス（エンジン始動サービス）に割り付けられたタスク（エンジン制御タスク）を確認し、そのタスクを起床させる。エンジン制御サーバ１７にて起床されたエンジン制御タスクは、受信キュー２１からメッセージを読み込んで、エンジン始動サービスの処理を実施する。

また同図では、上記クライアント１４のエンジン始動サービスの処理要求に続いて、回転速度取得（ＮＥ）サービスの処理要求が、エンジンＥＣＵ１１のクライアント１６により行われている。この処理要求に対してもメッセージ受信処理部２０は、メッセージ受信処理を実行し、受信キュー２２へのメッセージの格納、及び割り当てられたタスクの確認を行う。ただし、このときには、先のエンジン始動サービスの処理要求により、このとき要求された回転速度取得サービスに割り当てられたエンジン制御タスクは既に起床された状態となっている。そのため、メッセージ受信処理部２０は、タスク起床を行わず、単にメッセージを受信キュー２２に格納しただけで、このときのメッセージ受信処理を終了する。先に要求されたエンジン始動サービスの処理を終え、その結果をクライアント１４に応答したエンジン制御タスクは、受信キュー２２からメッセージを読み込んで、そのまま引き続き、回転速度取得サービスの処理を行い、その処理の結果をクライアント１６に応答する。これにより、１度のエンジン制御タスクの起床で、エンジン始動サービスと回転速度サービスとの２つのサービスの処理が行われる。

続いて、上記メッセージ受信処理部２０のメッセージ受信処理の詳細を説明する。図５は、メッセージ受信処理の処理手順を示すフローチャートを示している。この処理は、サービスの処理を要求するメッセージの受信の都度、メッセージ受信処理部２０により実行される。

さてサービスの処理要求のメッセージを受信すると（Ｓ１０１）、メッセージ受信処理部２０はまず、そのメッセージを、該当するサービスの受信キュー２１，２２に格納する（Ｓ１０２）。

続いてメッセージ受信処理部２０は、サービス割付テーブル２３を参照して、要求されたサービスに割り付けられたタスクを確認し（Ｓ１０３）、そのタスクが、現在実行中であるか否かを判定する（Ｓ１０４）。より具体的には、処理を要求されたサービスに割り付けられたタスクのＩＤをサービス割付テーブル２３から取得するとともに、現在実行中のタスクのＩＤと対比する。そして現在実行中のタスクの中に、取得したタスクと同じＩＤのものがあれば（Ｓ１０４：ＹＥＳ）、メッセージ受信処理部２０はそのまま今回の処理を終了する。一方、同じＩＤのものが無ければ、メッセージ受信処理部２０は、エンジン制御サーバ１７への割り込みをかけ、処理を要求されたサービスに割り付けられたタスクを起床させる（Ｓ１０５）。

次に、こうしたメッセージ受信処理を通じて起床されるタスクのサービス実行の処理に係る処理ルーチンについて説明する。図６は、起床されてから終了するに至るまでの、タスクの処理ルーチンを示している。この処理ルーチンは、上記メッセージ受信処理のステップＳ１０５の処理によるタスク起床の開始と共に実行される。

起床されたタスクは、ステップＳＳ２０１〜Ｓ２０４の処理を通じて、そのタスクに割り当てられたサービスのＩＤの若い順に受信キューを走査しながら、空きでない、すなわちメッセージの格納された受信キューがないか確認する。なお、同図のステップＳ２０１に記載の定数「ＩＤＳＴＡ」は、そのタスクに割り当てられたサービスのＩＤの初番を、ステップＳ２０３に記載の定数「ＩＤＥＮＤ」は、同サービスのＩＤの末番をそれぞれ指している。例えばＩＤが「０ｘＦ１」のエンジン始動サービスとＩＤが「０ｘＦ２」の回転速度取得サービスとが割り当てられたエンジン制御タスクの場合、「ＩＤＳＴＡ＝０ｘＦ１」、「ＩＤＥＮＤ＝０ｘＦ２」となる。

ここでタスクは、メッセージの格納された受信キューが確認されると（Ｓ２０４：ＮＯ）、その都度、その受信キューから処理要求のメッセージを取得して（Ｓ２０５）、そのメッセージの要求するサービスの処理を実行する（Ｓ２０６）。そして実行した処理の結果をクライアントに応答する（Ｓ２０７）と、タスクは再び、上記空きでない受信キューの確認を再開し、すべての受信キューが空であることが確認されると自身を終了させる。すなわち、一旦起床されたタスクは、同タスクを呼び出したサービスの処理を完了しても、そのタスクに割り当てられたサービスの処理要求が他にもないか確認し、そうした処理要求が有ればそのサービスの処理を引き続き実行する。

このように本実施形態では、一つのタスクに複数のサービスを割り当てるとともに、同一のタスクに割り当てられた複数のサービスを、起床された同一のタスク内で処理させるようにしている。そしてこれにより、起床の頻度を抑えて、タスク起床によるオーバーヘッドを低減するようにしている。そのため、ＲＰＣに基づくメッセージ通信機能を利用した車両制御の分散処理でのタスク呼出に基づく処理を、より少ないハードウェアリソースで実施することができるようになる。

ただし、以上説明した処理態様だけでは、確率的には低いものの、要求されたサービスの処理が実行されずに放置されてしまう可能性がある。図７は、そうした事態が生じる状況を示している。上述したようにタスクは、サービスの処理を完了した時点で、自身に割り当てられたサービスの処理要求が他に無いことが確認されれば（図６のＳ２０２：ＹＥＳ）、自身を終了させるようにしている。このときの上記確認がなされる時点と実際にタスクが終了される時点とには若干のタイムラグが存在している。このタイムラグの期間には、タスクの内部では既に終了することが決定されているにも拘わらず、外部から見ればタスクは実行中となっている。このタイミングにメッセージ受信処理が行われると、サービスの処理が行われないようになってしまう。

例えば図７では、エンジン始動サービスの処理を終えたエンジン制御タスクがこの終了待ちの状態となっているタイミングで、クライアント１６からの回転速度取得サービスの処理要求に対するメッセージ受信処理が行われている。この場合、メッセージ受信処理部２０から見れば、エンジン制御タスクは実行中であるため、タスクの起床は行わずにメッセージ受信処理が終了される。しかしながら、エンジン制御タスクは既に終了作業を開始しており、メッセージ受信処理にて受信キュー２２に格納されたメッセージは、同タスクに顧みられることなく、放置されてしまうようになる。そしてこのメッセージは、別の処理要求によりエンジン制御タスクが再び起床されるまで、受信キュー２２に格納されたままとなる。

そこで本実施形態では、上述したサービス実行状況監視部２４が、こうしてサービスが処理されないまま放置された処理要求の救済を図るようにしている。具体的には、サービス実行状況監視部２４は、メッセージ通信機構１５にタスクとして常駐されており、定期的に受信キューを確認して、サービスが処理されぬまま放置された処理要求のメッセージが無いか監視する。そしてそうしたメッセージの存在が確認されれば、そのメッセージが処理を要求するサービスに割り当てられたタスクを起床させるようにしている。

こうしたサービス実行状況監視部２４の処理の詳細を説明する。図８は、こうしたサービス実行状況監視部２４の行われるサービス実行状況監視処理のフローチャートを示している。サービス実行状況監視部２４は、この処理を定時割込処理として周期的に実行する。

本処理が開始されると、サービス実行状況監視部２４は、ステップＳＳ３０１〜Ｓ３０５の処理を通じて、メッセージ通信機構１５に設けられたすべての受信キューをサービスのＩＤの若い順に走査しながら、上記のような放置されたサービス処理要求のメッセージがないか確認する。具体的には、受信キューに処理要求のメッセージが格納され（Ｓ３０４：ＮＯ）、且つそのサービスに割り当てられたタスクが実行中（厳密にはそのサービスの処理要求の受信処理中も含む）ではない（Ｓ３０５：ＮＯ）場合に、その受信キューに格納されたメッセージの処理要求が上記放置状態にあると判定するようにしている。

そしてサービス実行状況監視部２４は、そうした放置状態の処理要求のメッセージが確認されると、その都度、そのメッセージが処理を要求するサービスに割り当てられたタスクを起床する（Ｓ３０６）。サービス実行状況監視部２４は、以上の処理を、そうしたメッセージが何れの受信キューにも存在しないことが確認されるまで継続した後、処理を一旦終了する。

図９に、こうしたサービス実行状況監視部２４の処理態様の一例を示す。先の図７の状況と同様に、同図においても、エンジン制御タスクが終了待ちの状態となっているタイミングで、クライアント１６からの回転速度取得サービスの処理要求に対するメッセージ受信処理が行われている。そのため、この回転速度取得サービスの処理要求のメッセージは、受信キュー２２内に格納のまま、放置されてしまうようになる。その点、上記サービス実行状況監視部２４があれば、そうした放置状態のメッセージが検出されてエンジン制御タスクが再び起床されるため、回転速度取得サービスの処理を実行できるようになる。

なお、本実施形態のタスク管理装置及びタスク管理方法を、車両制御システムに実際に採用する場合には、より多くのＥＣＵがシステムに設けられ、サービスを公開するサーバ機能を持つＥＣＵも複数となる。またより多くのサービスやタスクが必要にもなる。そうした場合にも、上記エンジンＥＣＵ１１のメッセージ通信機構１５と同様或いはそれに準じた構成を、サーバ機能を有した他のＥＣＵにも適用することで、低リソースで動作するＲＰＣに基づく分散処理にて車両制御を行うシステムを構築することができる。

また上記構成では、タスクのサービス割付を任意自在に設定することができ、その設定を工夫することで柔軟な運用を行うことができる。例えば単一のタスクに複数のサービスを割り付けると、先行サービスの処理が終わるまでサービスの処理が遅れることがあるため、リアルタイム性の要求されるサービスは、単独でタスクに割り当てるようにすると良い。またリソースに比較的余裕のあるＥＣＵでは、単一のサービスのみが割り付けられたタスクの比率を高め、余裕の少ないＥＣＵでは、複数のサービスが割り付けられたタスクの比率を高めるといったように、各ＥＣＵのリソース状況に合わせた運用も可能である。

以上説明した本実施形態では、メッセージ受信処理部２０による図５のステップＳ１０３、１０４の処理にて上記判定手段の処理が行われている。また受信キュー２１，２２が上記格納手段に、サービス実行状況監視部２４が上記サービス実行状況監視手段にそれぞれ相当する構成となっている。

こうした本実施形態では、以下に記載する効果を奏することができる。
（１）本実施形態では、単一のタスクに複数のサービスを割り付けるとともに、同一のタスクに割り当てられた複数のサービスを、起床された同一のタスク内で処理させるようにしている。そのため、タスク起床の頻度を抑え、その起床によるオーバーヘッドを低減することができ、ＲＰＣに基づく分散処理におけるタスク呼出に基づく処理を、より少ないハードウェアリソースで実施することができる。

（２）サービス割付テーブル２３を用いることで、サービスとタスクとの関係を容易且つ迅速に確認することが可能となる。
（３）本実施形態では、受信したサービスの処理要求のメッセージを受信キュー２１，２２に格納するとともに、タスク自らがその受信キュー２１，２２を参照して、自身に割り当てられた他の処理要求の有無を確認するようにしている。そのため、同一タスクによる複数サービスの継続実行を、簡易な処理構造で行うことができる。

（４）サービス実行状況監視部２４が、処理待ちのまま放置された状態のサービスの処理要求の有無を確認し、必要に応じてタスクを起床させているため、サービスが処理されずに放置されてしまう事態の発生を回避することができる。

（５）タスク割付を任意自在に設定することができるため、各ＥＣＵのリソース状況や個々のサービスの利用形態に合わせた柔軟な運用が可能である。
なお上記実施形態は、以下のように変更して実施することもできる。

・サービス実行状況監視部２４及びそのタスク、処理を割愛するようにしても良い。そうした場合にも、タスク終了時の上記タイムラグの解消などの別の手法でサービスの未処理放置を回避することはできる。

・上記実施形態では、処理待ちのサービス処理要求の確認や、複数サービスの継続実行の判定をタスク内部の処理として行うようにしていたが、タスク外部に別途設けられた他の手段にそうした処理を行わせるようにしても良い。

本発明の一実施形態の適用される車両制御システムの全体構造を模式的に示すブロック図。 同車両制御システムのエンジンＥＣＵのメッセージ通信機構１５の内部構造を模式的に示すブロック図。 同メッセージ通信機構１５に設けられるサービス割付テーブルの一例を示す図。 同実施形態でのサービス実行処理の一例を示すタイミングチャート。 同実施形態において採用されるメッセージ受信処理のフローチャート。 同実施形態において採用されるタスクのサービス実行処理ルーチンのフローチャート。 サービス実行状況監視部２４がない場合のサービス実行処理の一例を示すタイミングチャート。 同実施形態において採用されるサービス実行状況監視処理のフローチャート。 サービス実行状況監視部２４が設けられた本実施形態でのサービス実行処理の一例を示すタイミングチャート。 ＲＰＣに基づく車両制御システムの構成例を模式的に示すブロック図。 上記車両制御システムでのサービス実行処理の一例を示すタイミングチャート。

符号の説明

１０…ハイブリッドＥＣＵ、１１…エンジンＥＣＵ、１２…車内ネットワーク、１３，１５，５１，５２…メッセージ通信機構、１４，１６，５３，５４…クライアント、１７…エンジン制御サーバ、２０…メッセージ受信処理部、２１…エンジン始動サービス用の受信キュー、２２…回転速度取得サービス用の受信キュー、２３…サービス割付テーブル、２４…サービス実行状況監視部、５５…サーバ。

Claims (8)

1. サービスの処理要求の受信に応じてそのサービスに割り付けられたタスクを起床して該サービスの処理を行わせる車載電子制御ユニットのタスク管理システムにおいて、
   前記タスクの１つに対して複数のサービスを割り付けるとともに、
   前記サービスの処理要求の受信時に、その前記サービスに割り付けられたタスクが既に実行中であるか否かを判定する判定手段と、
   受信した前記サービスの処理要求をそのサービスの処理が開始されるまで格納する格納手段と、
   割り当てられたタスクが実行中でないサービスの処理要求がその格納手段に格納されているか否かを定期的に確認し、格納されていることが確認されたときには、そのサービスに割り当てられたタスクを起床するサービス実行状況監視手段とを備え、
   前記判定手段が肯定判定したときには、そのときに受信した前記サービスの処理要求に応じた前記タスクの起床を行わずに、前記実行中のタスクにそのまま当該サービスの処理を行わせる
   ことを特徴とする車載電子制御ユニットのタスク管理装置。
2. サービスの識別情報をキー項目とし、各サービスに割り当てられたタスクの識別情報をデータ項目とするサービス割付テーブルを備え、
   前記判定手段は、そのサービス割付テーブルを参照して、前記処理要求を受信したサービスの割り付けられたタスクの識別情報を取得し、その取得した識別情報と現在実行中のタスクの識別情報との対比に基づき前記判定を行う
   請求項１に記載の車載電子制御ユニットのタスク管理装置。
3. 当該タスク管理装置にて管理される各タスクには、サービスの処理を完了する毎に、当該タスクに割り当てられた他のサービスの処理要求が前記格納手段に格納されているか否かを確認し、格納されていることが確認されたときには、その処理要求を読み込んでその処理を引き続き実施し、そうでなければ自身を終了させる処理ルーチンが組み込まれてな
   る
   請求項１又は２に記載の車載電子制御ユニットのタスク管理装置。
4. 当該タスク管理装置は、遠隔手続呼出に基づくメッセージ通信機能を備えて他の車載電子制御ユニットとの通信を行う車載電子制御ユニットに適用されてなる
   請求項１〜３のいずれか１項に記載の車載電子制御ユニットのタスク管理装置。
5. 車載された電子制御ユニットでのサービスの処理要求の受信に応じて起床されるタスクの管理を行う方法であって、
   前記タスクの１つに対して複数のサービスを割り付けるとともに、
   前記サービスの処理要求の受信時にそのサービスに割り当てられたタスクが実行中であるか否かを判定する工程と、
   前記判定において前記タスクが実行中でないと判定されたときには、同タスクを起床して前記処理要求を受信したサービスの処理を行わせ、そうでないときには、同タスクを新たに起床せずにその実行中のタスクに前記処理要求を受信したサービスの処理を引き続き実行させる工程と、
   受信した前記サービスの処理要求をそのサービスが開始されるまで格納するバッファを設けるとともに、そのバッファを定期的に参照し、該バッファに処理要求が格納され、且つ割り当てられたタスクが実行中でないサービスが確認されたときには、そのサービスに割り当てられたタスクを起床する工程と、
   を備えることを特徴とする車載電子制御ユニットのタスク管理方法。
6. サービスの識別情報をキー項目とし、各サービスに割り当てられたタスクの識別情報をデータ項目とするサービス割付テーブルを設けるとともに、
   前記処理要求を受信したサービスの識別情報をキーとして前記サービス割付テーブルを参照して該サービスに割り付けられたタスクの識別情報を取得する工程、及びその取得した識別情報と現在実行中のタスクの識別情報と対比する工程、を通じて前記判定を行う
   ことを特徴とする請求項５に記載の車載電子制御ユニットのタスク管理方法。
7. 前記サービスの処理を完了する毎に前記バッファを参照し、当該タスクに割り当てられた他のサービスの処理要求が同バッファに有るか否かを判定する処理と、
   その判定が肯定判定されたときには、前記バッファから前記処理要求を取得してその処理を引き続き行い、否定判定されたときには、自身を終了させる処理と、
   からなる処理ルーチンを各タスクに組み込む
   ことを特徴とする請求項５又は６に記載の車載電子制御ユニットのタスク管理方法。
8. 遠隔手続呼出に基づくメッセージ通信機能を備えて他の車載電子制御ユニットとの通信を行う車載電子制御ユニットのタスク管理に適用した
   ことを特徴とする請求項５〜７のいずれか１項に記載の車載電子制御ユニットのタスク管理方法。

Images