JP2007126044A - 車載分散処理システム - Google Patents

Abstract

【課題】負荷分散を適切に行うことが可能な車載分散処理システムを提供すること。
【解決手段】ネットワーク５０に接続された複数のノードにより車両の車両情報を分散処理する車載分散処理システムにおいて、各ノードは、当該又は他のノードが利用するサービスを起動又は終了するライフサイクル管理部１０Ａ〜１０Ｃを有し、ノードの少なくとも一つが、サービスの動作状況を管理するロケーション管理部２０Ａ、２０Ｂとを有することを特徴とする。
【選択図】図１

Description

本発明は、ネットワークに接続された複数のノードにより車両情報を分散処理する車載分散処理システムに関する。

車両の制御や情報処理を車両の複数の箇所に分散した情報処理装置で行う車載分散処理システムが提案されている（例えば、特許文献１参照。）。特許文献１に記載された車載分散処理システムでは、車両に搭載されるセンサからの車両情報に基づく演算処理を実行し、演算結果にしたがい駆動情報をアクチュエータに出力して車両を制御する。そして、このような処理を行う車両制御プログラムの再利用や複数のＥＣＵによる分散処理が容易になるよう工夫されている。
特開２００１−２７０３９９号公報

しかしながら、従来の分散処理では、分散して存在するＥＣＵが生成する分散オブジェクトのサービスや、分散オブジェクトでない従来の通信アプリケーションを同様に扱い管理できる仕組みがなく、効率のよい分散処理が困難であった。

例えば、分散されたサービス検索の仕組みがなく、また、各サービスの負荷分散や障害切替のために異なるノード上にサービスを生成し管理する仕組みがなかった。このため、複数のノードが存在するネットワーク環境において、実行するノードを変更することや、変更できた場合もそのノードを他のノードから利用することは困難であった。

また、従来の通信アプリケーションと分散オブジェクトとが混在した環境では、負荷分散や障害回復などの処理を行うことが困難で、負荷分散や障害復旧のために多重に起動しているサービスが点在し、システムリソースを浪費する状況が生じていた。

また、システム全体の障害情報を管理し、障害復旧処理を行う機構が一つであったため、その機構が故障した場合システム全体が停止してしまう可能性があった。

本発明は、上記問題に鑑み、負荷分散を適切に行うことが可能な車載分散処理システムを提供することを目的とする。

上記課題に鑑み、本発明は、ネットワークに接続された複数のノードにより車両の車両情報を分散処理する車載分散処理システムにおいて、各ノードは、当該又は他のノードが利用するサービスを起動又は終了するライフサイクル管理部を有し、ノードの少なくとも一つが、サービスの動作状況を管理するロケーション管理部と、を有することを特徴とする。

本発明によれば、ロケーション管理部によりサービスの動作状態を管理して、ライフサイクル管理部によりサービスを起動できるので、ロケーション管理部がサービスの動作状況を管理しながらサービスを起動できる。

また、本発明の一形態において、ライフサイクル管理部は、サービスを起動する場合、予め設定された設定情報に基づき、サービス毎に動的又は非動的に前記サービスを起動し、起動したサービスをロケーション管理部に登録する、ことを特徴とする。

本発明によれば、動的又は非動的にサービスを起動できるので、システムリソースを浪費せずにサービスを起動でき、また、常に起動しておく方が好ましいサービスについて非動的に起動することで、車載分散処理システムの応答性を保つことができる。

また、本発明の一形態において、ロケーション管理部は、サービスを利用するクライアントがサービスを検索する場合、サービスの識別情報をクライアントに返すことを特徴とする。

本発明によれば、サービスを利用するクライアントに識別情報（サービスリファレンス）を返し、クライアントはそのサービスリファレンスに基づきサービスを利用できるので、クライアントはサービスの位置を意識せずにサービスを利用できる（位置透過性）。

また、本発明の一形態において、サービスが動的に起動される場合、ライフサイクル管理部は、クライアントがサービスを検索した場合にサービスを起動することを特徴とする。

本発明によれば、クライアントが利用する場合にサービスを起動するので、システムリソースを有効に利用できる。

また、本発明の一形態において、クライアントとサービスとの接続のポリシが設定された接続ポリシと、サービスの負荷分散のポリシが設定された負荷分散ポリシと、を有し、ロケーション管理部は、クライアントがサービスを検索した場合、接続ポリシ又は負荷分散ポリシをクライアントに設定することを特徴とする。

本発明によれば、接続ポリシと負荷分散ポリシに基づき、障害発生時の例外処理として負荷分散のために多重化されたサービスを利用するのか、障害回復として新規に起動されたサービスを利用するのかを区別し、これらの設定や切替を行うことができる。

また、本発明の一形態において、ノードにデバイス機器が接続されている場合、ライフサイクル管理部は、デバイス機器のドライバをサービスとして起動するデバイス管理部を有する、ことを特徴とする。

本発明によれば、ノードにデバイス機器が接続された場合にデバイス機器のドライバをサービスとして起動され、また、サービスは他のノードからも利用できるので、デバイス機器のその物理的な場所を考慮せずに利用することができ、そのデバイスに障害が発生した場合も効率よく同様のデバイス機器に切り替えてシステムの運用を継続させることができる。

また、本発明の一形態において、設定情報は当該サービスが使用するデバイス機器の一覧を有し、ライフサイクル管理部は、サービスを起動する場合、一覧に記録されたデバイス機器のドライバを起動することを特徴とする。

本発明によれば、サービスを利用する場合にドライバも起動できるので、余分な通信を抑制できる。

また、本発明の一形態において、ロケーション管理部は、ノードで動作しているサービスの稼動状態を示す動作状態情報を各ノードから収集する情報収集部を有する、ことを特徴とする。

本発明によれば、ロケーション管理部が各ノードの負荷率など動作状態を保持することができる。

また、本発明の一形態において、ライフサイクル管理部が自立的に動作状態情報を情報収集部に配信することを特徴とする。

また、少ない通信量でロケーション管理部が動作状態を収集できる。

また、本発明の一形態において、状態収集部は、各ライフサイクル管理部に対し動作状態情報を要求し、ライフサイクル管理部から送信された動作状態情報を受け取ることを特徴とする。

本発明によれば、ロケーション管理部が各ライフサイクル管理部から確実に動作状態情報を取得できる。

また、本発明の一形態において、所定のノードに動作状態情報を中継するイベントサーバを有し、ライフサイクル管理部は自立的に動作状態情報をイベントサーバに配信し、ロケーション管理部は、イベントサーバに対し動作状態情報を要求し、イベントサーバから動作状態を受け取ることを特徴とする。

本発明によれば、ロケーション管理部が個々のライフサイクル管理部から呼び出されることがなく、また、ノード間の通信コストを最小化できるので、ロケーション管理部への配信と処理を効率よく行うことができる。

また、本発明の一形態において、ロケーション管理部は、サービスの障害状況を管理する障害管理部を有し、障害管理部が障害を検出した場合、代替となるサービスが既に起動されている場合は識別情報をクライアントに返し、代替となるサービスが起動されていない場合、ライフサイクル管理部にサービスの起動を要求し該サービスの識別情報をクライアントに通知することを特徴とする。

本発明によれば、クライアントが例外処理に移ったときにすぐ新しいインスタンスを利用できるようになり、すばやくサービスの利用を継続することができる。

また、本発明の一形態において、ロケーション管理部が当該車載分散処理システムに複数存在する場合、複数のロケーション管理部はサービスの動作状況を同期して保持する、ことを特徴とする。

本発明によれば、ロケーション管理部のあるノードに障害が生じても他方のロケーション管理部により車載分散処理システムの動作状況を保持でき、また、各ライフサイクル管理部は通信コストの小さい場所のロケーション管理部から動作状況を取得できる。

また、本発明の一形態において、ロケーション管理部は、サービスの障害状況を管理する障害管理部を有し、所定の障害管理部が、複数のロケーション管理部のうちのいずれかのロケーション管理部の障害を検出した場合、障害の生じたロケーション管理部を再起動することを特徴とする。

本発明によれば、障害が生じたロケーション管理部を再起動できるので、車載分散処理システムのロバスト性が向上する。

また、本発明の一形態において、ライフサイクル管理部は、所定時間、クライアントからの処理要求がなかった場合サービスを終了する、ことを特徴とする。

本発明によれば、サービスを動的に終了できるのでシステムリソースの浪費を低減できる。

負荷分散を適切に行うことが可能な車載分散処理システムを提供することができる。

以下、本発明を実施するための最良の形態について図面を参照しながら説明する。図１は、本発明の車載分散処理システムの構成図例を示す。本実施の形態の車載分散処理システムでは、ノード１とノード２、ノード２とノード３がＣＡＮ（Ｃａｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）やＦｌｅｘｌａｙ等の所定のプロトコルで通信可能なようにネットワークを形成している。ノードとは車両情報を処理するホストであり、また、他のノードに処理を依頼するクライアントとなる情報処理装置である。なお、図１ではノードが３つしかないがノードの数は制限されない。

各ノードはライフサイクル管理部１０Ａ〜１０Ｃを有し、また、ノード１とノード２はロケーション管理部２０Ａ、２０Ｂをそれぞれ有している。ライフサイクル管理部１０Ａ〜１０Ｃは、各ノードで動作するサービスを起動しその動作状況を監視し、監視の結果、必要に応じて各ノードで動作するサービスを終了させる。また、ロケーション管理部２０Ａ、２０Ｂはこれら複数のライフサイクル管理部から各ノードの情報を収集し、車載分散処理システム全体の負荷情報や障害情報を管理する。なお、ロケーション管理部は車載分散処理システムに１つだけでもよいし、ノード３がさらにロケーション管理部を有していてもよい。

図１では、ノード１のライフサイクル管理部１０Ａはサービス１及び２を起動し、ノード２のライフサイクル管理部１０Ｂはサービス２及びサービス３を、ノード３のライフサイクル管理部１０Ｃはサービス１とサービス４をそれぞれ起動している。サービスとは、システムを特徴づける一以上の機能を提供するアプリケーションである。

ロケーション管理部２０Ａと２０Ｂは、ライフサイクル管理部１０Ａ〜１０Ｃが起動しているサービスを把握し、クライアントから提供要求が多いサービスがあれば後述するように負荷分散ポリシにしたがい複製を起動する。例えば、ノード２のサービス２はノード１のサービス２の複製であり、ノード３のサービス１はノード１のサービス１の複製である。また、クライアントとは、サービスを利用するアプリケーションであり、クライアントもまたサービスの一部となりうる。

ロケーション管理部２０Ａ、２０Ｂは互いに通信して各サービスの負荷情報や障害情報を同期して保持する。これにより、一つのロケーション管理部に障害が生じても、ロケーション管理部がなくなることがなく、また、ロケーション管理部の再起動も容易になる。

クライントＡはロケーション管理部２０Ａに登録されているサービスを検索し、ロケーション管理部２０Ａが応答して返したサービスリファレンスにより指定されたサービスを利用する。同様に、クライアントＢはロケーション管理部２０Ｂ（２０Ａでもよい）に登録されているサービスを検索し、ロケーション管理部２０Ｂが応答して返したサービスリファレンスにより指定されたサービスを利用する。

ライフサイクル管理部１０Ａ〜１０Ｃは、クライアントによる利用が終了したらサービスを明示的に終了したり、また、暗黙的にサービス自身が一定時間すべてのクライアントからの処理要求が来なかったときにサービスを終了する。

図２は、各ノードのハードウェア構成図の一例を示す。各ノードは、入出力回路１７を介してデバイス１６と接続されている。デバイス１６は、物理的な機器としてのハードウェアであり、例えばディスプレイ、ＡＶ装置、ナビゲーション装置又は電装品のスイッチなどである。なお、デバイス１６はこれらに限られるものではなく、車載分散処理システムに接続されるハードウェアであればよい。

各ノードは、車両を制御するための様々な処理を行うＥＣＵ９を有し、通信線５０を介して他のノードと通信を行うための通信Ｉ／Ｆ１５とを、備えている。この通信線５０にて各ノードが相互に接続されて上述した車両内のネットワークが形成されている。

そして、ＥＣＵ９には、プログラムを実行する周知のＣＰＵ（中央演算処理装置）１１と、ＣＰＵ１１によって実行されるプログラムやそのプログラムの実行時に参照される制御データを記憶するＲＯＭ１２と、ＣＰＵ１１による演算結果等を一時的に記憶するためのＲＡＭ１４と、入出力回路１７及び通信Ｉ／Ｆ１５との間で信号をやり取りするためのＩ／Ｏ１３と、各種レジスタやフリーランカウンタ等（不図示）とが備えられている。

車載分散処理システムに搭載される車両制御プログラムは、各ノードの備えるＥＣＵ９のＲＯＭ１２に分散されて格納されている。そして、このＲＯＭ１２のプログラムをＣＰＵ１１が実行することによって、各ＥＣＵ９が機能し、デバイス機器などを含めた情報処理が実現される。

なお、図２では情報処理系の車載分散処理システムについて説明しているが、エンジンや油圧などを制御する車両制御システムにも、同様に適用できる。デバイス６１の代わりにＥＣＵ９からの駆動情報に応じてアクチュエータ駆動される。

本実施の形態の車載分散処理システムでは、エンジン・駆動系の制御においても、複数のノードでの分散処理を行う。例えば、あるノードに接続されたセンサからの車両情報に基づく演算処理を別のノードが実行したり、あるノードに接続されたアクチュエータに対する駆動情報の出力を別のノードが行ったりすることができる。

続いて、ライフサイクル管理部とロケーション管理部について詳細に説明する。ライフサイクル管理部１０Ａ〜Ｃは、各ノードに固有な情報、例えば、稼働させるサービスの種類、サービスの起動方法（サービスがプロセスであれば、そのプロセスへのパス）等を保持している。

ロケーション管理部２０Ａ、２０Ｂは、各ノードにあるライフサイクル管理部が監視している各サービスの動作状況を管理する。各サービスの負荷状況によりサービスを検索するクライアントへ返すサービスの識別情報（以下、サービスリファレンスという）を選択する。ノードやサービスに障害が発生した場合にはこれを検出して、当該ノードを再起動する等の障害復帰処理を実行する。また、ロケーション管理部２０Ａ又は２０Ｂは、各ノード毎の情報ではなく、車載分散処理システム全体としての情報管理を行う。

図３及び４はライフサイクル管理部とロケーション管理部の機能ブロック図を示す。ロケーション管理部１０は、サービス登録、サービス検索、状態収集、負荷管理、障害管理、オブジェクトグループ管理の各機能を有する。

サービス登録部Ａは、ライフサイクル管理部１０Ａ〜１０Ｃ又はサービス自信からのサービス情報をロケーション管理部に登録する。登録により当該サービスを車載分散処理システムにおいて利用可能となる。登録されるサービス情報は、サービス名、メーカＩＤ（ハードウェアのメーカを示す）、バージョンＩＤ（ハードウェアの型番やロット番号）、起動の有無及びオブジェクトリファレンス等である。

サービス検索部Ｂは、クライアントから要求されたサービスを検索し検索結果をクライアントに返す。クライントは、サービスＩＤ、メーカＩＤ若しくはバージョンＩＤ、又は、これらを組み合わせた検索情報をサービス検索部に送出し、サービス検索部は、登録されているサービスから適合するサービスを検索しそのサービスリファレンス（戻り値）をクライアントへ送出する。

サービスリファレンスは、サービスを利用するために使用するリファレンス情報であり、例えば各ノードがCORBA（Common Object Request Broker Architecture）を実装している場合、CORBAオブジェクトを一意に識別するための識別子となる。

クライアントは、サービスリファレンスにより得たサービスが実際のどのノードで動作しているかを意識しないで利用することができるため、車載分散処理システムは位置透過性を有する。

サービスの負荷分散について説明する。クライアントがサービス検索を行うと、利用できるサービスのサービスリファレンスが返される。クライアントはそのサービスにより提供される機能を利用できる。サービス検索を行なうと、各サービスについて異なるインスタンスが複数稼動している場合、それらの負荷状況に応じて使用されるインスタンスが選択され、クライアントに返される。すなわち、車載分散処理システムは負荷分散機能を備える。

負荷分散は、接続するポリシを定める接続ポリシの設定に基づき行われる。クライアントは利用するサービスに応じて、動的に接続ポリシを設定する。

−Per-client：クライアント毎（マシン単位又はオブジェクト単位）
クライアントが接続するインスタンスを固定する接続ポリシである。クライアントを一意に特定する情報（IPアドレス十ポート番号など）を用いて、クライアント毎に接続するインスタンスを固定する。この場合、そのクライアントから同じサービスに対して何回検索を行なっても常に同じインスタンスへのリファレンスが返される。また、このインスタンスに障害が発生して使用できなくなった場合には、インスタンスが変更される。

−Per-session：セッション毎
（ノードの処理がStatefullな場合）
Ｓｔａｔｅｆｕｌｌな場合とは、クライアントとインスタンスとの状態を保持することをいう。したがって、この接続ポリシでは、ある一連の処理の纏まりを実行している間は同じインスタンスに接続する。

−Per-request：リクエスト毎
（ノードの処理がStatelessな場合）
Ｓｔａｔｅｌｅｓｓな場合とは、クライアントとインスタンスとの通信状態を保持しないことをいう。クライアントがサービスの機能（IDL（Interface Definition Language）などのインターフェイス情報により公開されている機能／オペレーション）を利用する度に接続するインスタンスを変更する。

‐on‐demand：クライアントからの（明示的な）要求時に接続先のインスタンスを変更する
サービス検索を行なうだけではインスタンスは切り替えず、特に明示的に切り替えることが指定された場合に切り替える。

また、インスタンスの選択方法は以下のような負荷分散ポリシに基づき切り換える。

‐非適応型：実行時のサーバ負荷情報を見ない。以下の方法から選択して接続先を選定する。
（１）ラウンドロビン（順番に切り替える）
（２）ランダム（ランダムに切り替える）
（３）ハッシュ（クライアント情報（IPアドレス、オブジェクトＩＤなど）を利用して接続先を決定。Ｐｅｒ−ｃｌｉｅｎｔポリシを実現できる）
‐連座型：実行時のサーバ負荷情報を見て接続先を選定する。

負荷設定ポリシはクライアントからロケーション管理部へのサービス検索時に、追加情報（フラグ）として設定される。

負荷分散ポリシは接続ポリシと共にクライアントにより動的に設定されてもよいし、ロケーション管理部が負荷分散行うためにロケーション管理部に設定されてもよい。

クライアントがサービスの機能を利用していた場合に障害が発生した場合、クライアントからサービス検索を再度おこなう。通常、分散している他ノードのサービスでの処理に失敗した場合、サービスが異常終了したか、何らかの理由で通信が失敗したか、などの理由があるため、クライアント側で例外処理として再度サービス検索を行ないサービスリファレンスの再取得を行なう。サービスが異常終了したのであれば異なるインスタンスのリファレンスが上記ポリシに応じて取得されることになる。

状態収集部Ｃは、各ノードが有するライフサイクル管理部から、そのノードで動作しているサービスの稼動状態についてのサービス情報（負荷率、障害有無）を収集する。稼働状態とは、各ノードで動作しているサービスのインスタンスの稼動状態をいう。

したがって、各ノードのライフサイクル管理１０Ａ〜１０Ｃから、一つのロケーション管理部へこれら情報が収集される。図１のようにロケーション管理部が車載分散処理システムに複数ある場合は、これらロケーション管理部間で同期を取る形で共有される。

サービス情報の収集の方法には次の方法があり、情報配信ポリシとしてＲＡＭ１４等に設定されている。
‐Push型；各ライフサイクル管理部が自立的に情報をロケーション管理部の情報収集部に定期的又は非定期に配信する。Ｐｕｓｈ型はUDP（User Datagram Protocol）によるマルチキャスト通信に好適である、TCPによる通信で行なってもよい。
‐Pull型：ロケーション管理部の状態収集部Ｃが各ライフサイクル管理部に対して情報を要求し、結果を受け取る。

また、これらの配信方法は、別途イベント管理との連携も考慮する必要がある。詳しくは後述するが、イベント管理のイベントサーバを用いる構成では、これらの情報配信ポリシの混在化もシステム構成や処理シーケンスを簡略化する上で有効である。

負荷管理部Ｄは、集められたサービス情報の中の負荷情報を用いて、各サービスの負荷状況を把握し、オブジェクトグループ管理部Ｆが使用する管理テーブルの該当部分を更新する。

障害管理部Ｅは、集められたサービス情報の中の障害情報を用いて、各サービスの障害状況を把握し、オブジェクトグループ管理部Ｆが使用する管理テーブルの該当部分を更新する。

通常、サービスが障害で終了した場合は、クライアントが障害による例外処理に移行し、その中で再度サービス検索を行なうことでインスタンスの切り替え／再起動を行なう。しかし、この方法ではクライアントが例外処理を行う時にはじめて障害回復処理（インスタンスの切り替え／再起動）が行なわれるため、障害が発生してから回復するまでに時間がかかる。

本実施の形態では、ロケーション管理部が障害を検出した場合、代替となるインスタンスが既に起動されていればそのリファレンスを、起動されていなければ動的に起動してそのリファレンスを、そのサービスを利用しているクライアントに通知（サービスリファレンスのPush更新）することで、クライアントが例外処理に移ったときにすぐ新しいインスタンスを利用できるようになり、すばやくサービスの利用を継続することができる。このような障害対策によりMTBF（Ｍｅａｎ Ｔｉｍｅ Ｂｅｔｗｅｅｎ Ｆａｉｌｕｒｅ）を短縮できる。

オブジェクトグループ管理部Ｆは本システムの中心的な機能を提供する。まず、本実施の形態では負荷分散や障害対策のために、一つのサービスについて複数のインスタンスが異なったノードに存在するが、オブジェクトグループとはそれらのまとまりを表すものである。1サービスで1オブジェクトグループとなる。サービスの数だけオブジェクトグループが存在する。サービスはサービスＩＤにより特定される。

1オブジェクトグループ内には（あるサービスの）複数のインスタンスが含まれ、各インスタンスは以下の情報を持つ。
・インスタンスＩＤ（登録時に自動的に設定される。そのノードで一意であればよい）
・サービスＩＤ
・メーカＩＤ
・バージョンＩＤ
・ホストＩＤ（ノードが属するホストの識別ＩＤ）
・起動モード（起動有無、稼動系／待機系とも言う）：あらかじめ起動しておく（稼動系）か、動的起動とする（待機系）かを定める
・負荷情報（ＣＰＵ使用率など）
・障害情報（無事に動作中／障害により動作停止、など）
・起動されている場合にはサービスリファレンス
・ＣＰＵＩＤ（オプションであり必ずしも必要ない。ＣＰＵの性能を表すためのＩＤである）
ＣＰＵＩＤについて補足する。例えば同じサービスの二つのインスタンスが異なるノードで動作しており、それぞれの負荷（ＣＰＵ使用率）が同じ50％であり、それぞれのＣＰＵＩＤが例えばPentium（登録商標）4／3GHZとPentium（登録商標）3／1GHZであったとき、ＣＰＵＩＤがPentium（登録商標）4のノードのサービスを使用した方が応答性が良いことが期待できる。ＣＰＵＩＤはこの様にＣＰＵの処理性能を相対的に比較できるものであればよい。実際にはＣＰＵＩＤは係数のようなものとし、負荷率に掛けることで“実質的な負荷率”（実行値）が求められるようにする。これにより、使用されているＣＰＵが異なるノードの混在した分散環境で、有効に負荷分散を実現することが出来る。

ところで、上述した各インスタンスが有する情報は、必ずしも一つのテーブルとして保持されている必要は無く、一連の処理を行なう中でこれらの情報が利用可能であればよい。

サービス登録部Ａは、クライアントからのリクエストを受け、オブジェクトグループ管理部Ｆにそのサービス情報の登録を行なう。サービス検索部Ｂは、クライアントからのリクエストを受け、利用可能なサービスのリファレンスを返す。このとき、利用できるサービスのインスタンスが複数ある場合は、クライアントに指定された接続ポリシ、負荷分散ポリシにしたがい、適切なサービスのリファレンスを返す。また、障害により利用できるインスタンスがシステム内に存在しない場合は、起動可能なノードでサービスのインスタンスの起動を行い、そのリファレンスを返す。すなわち、オブジェクトグループ管理部Ｆがライフサイクル管理にサービスの起動を要求し、その起動後にそのリファレンスを取得し、クライアントに返却する。

サービスリファレンスは、各サービスの実装方法に依存しない形とすることで、CORBAやＡＣＥ（Ａｄａｐｔｉｖｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ）という異なるハードウェアアーキテクチャで実装されたサービスをシステム内で利用可能としている。実際には文字列により、CORBAではそのオブジェクトリファレンスの文字列表現、ＡＣＥはＩＰアドレスとポート番号のペアを文字列で表記し、使用している。

続いてライフサイクル管理部１０Ａ〜１０Ｃについて説明する。
デバイス管理Ｇは、車載分散処理システム内のいずれかのノードに物理的な何らかのデバイス機器が追加（または削除）された時に、その追加（または削除）を知らせるハードウェア的な割り込みが発生され、それを受けてデバイス機器追加（または削除）処理を管理するものである。運用中にデバイスが追加された場合、システム内のアプリケーションに対して、デバイスが追加されたことを通知する。そして必要に応じて、デバイスサービスをライフサイクル管理部１０Ａ〜１０Ｃに登録する。デバイスサービスとはサービスの一形態で特にデバイスが利用するサービスである。

デバイス機器追加・終了部Ｉは、デバイス管理部Ｇからの指示を受けて、実際の追加・終了を必要に応じて行なう。例えば、いわゆるＯＳに対するデバイスドライバに順ずるソフトウエア（ドライバ）の追加・削除、設定などを必要に応じて行なう。

デバイスサービス起動・終了部Ｈは、デバイス機器を他のノードからも利用できるように、分散環境に対応したインターフェイスをサービスとしてシステムに対して公開する。これにより、デバイスを利用するアプリケーションは、そのデバイスのシステム内の物理的な位置を意識することなく（位置透過性）、その機能を利用することが出来るようになる。また、システム内に同等のデバイスがある場合は、障害管理機能により、所定のデバイスに障害が発生した場合は、他方のデバイスに自動的に切り替わる。

サービス起動・終了部Ｊは、各ノードにおいてサービスの起動や終了を実際に行なう。サービスの起動は、サービスについての設定情報（サービスレポジトリ（Repository）として格納されている）を用いて行なう。

起動時に利用される設定情報としては、
・起動モード（起動有無、稼動系／待機系とも言う）
・起動プロセス実装バイナリへの実行パス（PATH）
・使用するデバイスの一覧
「使用するデバイスの一覧」を利用し、サービスを起動する場合、使用するデバイス（デバイスサービス）が起動されていなければそれらを起動していく。

また、サービス起動・終了部Ｊは「起動モード」と次の情報とを合わせてサービスの登録を行なう。これは起動されたサービスから行なう場合（サービス自身が動的にこれらの値を生成して設定する）と、ライフサイクル管理部１０Ａ〜１０Ｃから行なう場合（あらかじめ設定情報などで指定された値を用いる）とがある。
・インスタンスＩＤ
・サービスＩＤ
・メーカＩＤ
・バージョンＩＤ
・ホストＩＤ
・ＣＰＵＩＤ（オプションであり必ずしも必要ない。上述したように、ＣＰＵＩＤがない場合、全て同じＣＰＵにより構成される分散環境とみなされる）
・起動されている場合サービスリファレンス
また、サービス起動・終了部Ｊが行うサービスの終了方法として以下の2種類ある。
・明示的にライフサイクル管理部１０Ａ〜１０Ｃからサービスへ終了要求を送り、サービスが終了処理をしてから終了する場合（システム全体の終了処理など）、
・暗黙的にサービス自身が一定時間すべてのクライアントからの処理要求が来なかったときに終了処理を行い終了する場合。

どちらも終了後は待機系とする。この暗黙的な終了と動的起動とにより、システムリソースをより有効に利用することができる。

状態監視部Ｋは、そのノードで稼動している各サービスに対して、稼動しているかどうか、負荷がどれだけであるか、等の動作状態情報を問い合わせて取得する。負荷情報は、そのノードのＣＰＵ使用率で代用してもよい。状態監視部Ｋはこれらの情報をロケーション管理部２０Ａ又は２０Ｂに通知する。

また、これらの動作状態情報を通知する際に、負荷が一定値より低い場合（または高い場合）は負荷情報を通知せず、そうでなかった場合のみ負荷情報を含めることで通信量を軽量化する。

続いて、ロケーション管理部が車載分散処理システムに複数配置されている場合の動作について説明する。

〔ロケーション管理部同士の障害管理〕
ロケーション管理部２０Ａと２０Ｂとが複数配置されている場合、互いに障害監視することができる。いずれかのロケーション管理部の障害を他方のロケーション管理部が検知した場合、障害により終了したロケーション管理部の再起動を行なう。再起動する場合、同じノードで行ってもよいし、他のノードで行ってもよい（ロケーション管理部が待機系として設定されているノード）。再起動するノードは、接続ポリシにより切り替える。

〔ロケーション管理同士の情報同期〕
システム内に複数のロケーション管理部を配置した場合、複数のロケーション管理部の間で情報の同期を行なう。それぞれのロケーション管理部には、それぞれに接続したライフサイクル管理部からのサービス登録、サービス参照、情報収集、などのためのアクセスが行なわれる。これらの中で、以下の情報が更新された場合は、他のロケーション管理部に同期のための情報更新処理を行なう。

… 新規サービスの追加
新規サービスが追加された場合、
・インスタンスＩＤ（登録時に自動的に設定される。そのノードで一意に決まればよい）、・サービスＩＤ
・メーカＩＤ
・バージョンＩＤ
・ホストＩＤ
・ＣＰＵＩＤ
・起動モード（起動有無、稼動系／待機系とも言う）
… 既存サービスの情報更新
・負荷情報（ＣＰＵ使用率など）
・障害情報（無事に動作中／障害により動作停止、など）
・動的起動されて作成されたサービスリファレンス
〔ロケーション管理の複数起動による負荷分散〕
車載分散処理システムに複数のロケーション管理部を配置した場合、ライフサイクル管理部やクライアント、サービスは、自分にネットワーク的に近い（通信コストが低い）ロケーション管理部を利用する。これによりシステム内での通信コストの最適化と、処理の負荷分散を行なう。

〔ロケーション管理部のプロキシモードによる起動〕
続いて、ロケーション管理部のプロキシモードについて説明する。プロキシモードとはロケーション管理部を代理する不完全なロケーション管理部を起動することである。

ロケーション管理部を各ノードに一つ配置する。ただし、ロケーション管理部としての全機能を持つものはこの中に一つあればよい。全機能を持たないものはインターフェイスとして全機能相当のものを持つが、実際の処理は全機能を持つロケーション管理に委譲する。

このように全機能を持つロケーション管理部以外のロケーション管理部は単なるインターフェイスとすることで、システム構成を単純化し、各ノードのライフサイクル管理部やクライアント、サービスは、自ノードのロケーション管理部（又はプロキシ）を利用すればよく、他ノードにのみ完全なロケーション管理部がある場合でも他ノードへの通信処理を行なわなくて良くなる。

ただし、これまではライフサイクル管理部やクライアント、サービスが各ノードのロケーション管理部（およびプロキシ）を利用する必要があったが、プロキシモードの場合、各ロケーション管理部が他ノードのロケーション管理部（全機能版）を知る必要がある。

また、この様なプロキシモードのロケーション管理部を用いるのであれば、ロケーション管理部とライフサイクル管理部とを一つのプロセスとすることで、障害監視とその復帰処理が簡略化され、また、ロケーション管理部とライフサイクル管理部間の通信処理がプロセス内処理となることで、システムとしての信頼性と性能を向上させることができる。

〔コンテナによるサービスの起動と、「状態監視」と「サービスリファレンスのPush更新」への対応〕
コンテナと称する機能について説明する。コンテナはサービスを効率よく実現するための機能であり、以下の動作を実現する。

コンテナはプロセスに一つ存在し、サービスをスレッドとして起動および終了させる。起動および終了はライフサイクル管理部からの要求により行なう。

上述したコンテナを用いない場合の状態監視は、サービス本体に対して行なわれ、サービス本体に監視に対応するためのインターフェイスと機能を備える必要があるが、コンテナがこの状態監視による問い合わせに対応することで、サービス本体に機能を持たせる必要がなくなる。

また、上述した「サービスリファレンスのPush更新」を受ける機能をコンテナに持たせ、通常のサービス検索もコンテナ経由で行なうことで、Push更新されていればそれを返し、されていなければ通常のロケーション管理部への問い合わせを行なうようにすることで、サービスリファレンス取得方法の違いを意識せず障害発生時でも効率よく本システムの機能を利用できる。

以上の様に、コンテナを用いることで、過去に開発した機能をサービスとして本システムに組み込む場合や、新規に開発して組み込む場合でも、本システムと連携して動作するために必要な機能をコンテナが実現しているために、効率よく組み込むことが出来る。また、本システムの各機能（サービス検索や障害回復など）の構造やインターフェイスなどが変わったときに、コンテナでそれらに対応するための差異を吸収することで、サービスの実装の変更を最小限に抑えることができる。

続いて、以上の構成に基づいてライフサイクル管理部１０Ａ〜１０Ｃ及びロケーション管理部２０Ａ、２０Ｂの動作について説明する。

〔各ノードでの起動シーケンス（動的起動なし）〕
図５はライフサイクル管理部１０Ａがノード内でプロセスを起動するシーケンス図の一例を示す。なお、以降では図１の構成図に基づき説明する。
まず、各ノード上のＯＳの起動シーケンスの最終段階で、ライフサイクル管理が起動される（Ｓ１０１）。

ついで、ライフサイクル管理部１０Ａがロケーション管理部２０Ａを起動する（Ｓ１０２）。なお、ロケーション管理部２０ＡもＯＳの起動シーケンスの最終段階で起動されてもよい。

ついで、ライフサイクル管理部１０Ａは設定情報（サービスレポジトリ）ファイルを読み込む（Ｓ１０３）。設定情報には起動するサービス毎にサービスに関する情報が記録されている。ライフサイクル管理部１０Ａのサービス起動・終了部Ｊは、上述した、
・起動モード（起動有無、稼動系／待機系とも言う）
・起動プロセス実装バイナリへの実行パス（PATH）
・使用するデバイスの一覧
を設定情報から取得する。

図５のシーケンス図は動的起動なしの場合なので、設定情報を取得したらサービス起動・終了部Ｊはサービス１を起動する（Ｓ１０４）。動的起動なしの場合、このようにサービスが利用されるか否かにかかわらず予めサービスが起動される。

ついで、ライフサイクル管理部１０Ａがロケーション管理部２０Ａのサービス登録部Ａに、サービス情報を登録する（Ｓ１０５）。登録されるサービス情報は、上述のとおり、サービス名、メーカＩＤ、バージョンＩＤ、起動の有無及びオブジェクトリファレンス等である。また、サービス情報には、そのサービスが既に起動されているか否かをという情報も登録される。なお、サービス情報はサービス自身が登録してもよい。

同様にして、サービス起動・終了部Ｊは設定情報（サービスレポジトリ）ファイルに記録されているサービスを起動し（Ｓ１０６）、そのサービス情報をロケーション管理部２０Ａに登録する（Ｓ１０７）。

ライフサイクル管理部１０Ａは、設定情報の「使用するデバイスの一覧」を利用し、サービス１又は２で使用するデバイス（デバイスサービス）が起動されていなければそれらを起動していく。

また、ライフサイクル管理部１０Ａは、サービスを利用するクライアントＡを起動する（Ｓ１０８）。クライアントＡはサービスリファレンスに応じて他のノードのサービスを利用することもある。以上のようにして、各ノードにおいてサービスが起動される。

〔各ノードでの起動シーケンス（動的起動あり）〕
続いて、動的起動によりサービスを起動する場合について説明する。図６は、ライフサイクル管理部１０Ａがノード内でプロセスを起動するシーケンス図の一例を示す。なお、図６において図５と同一のステップには同一の符号を付しその説明は省略する。

図６ではライフサイクル管理部１０Ａとロケーション管理部２０Ａが起動され、ライフサイクル管理部１０Ａが設定情報を読み込むまでは図５と同じである。

サービスが動的に起動される場合、サービス起動のトリガーは、
・クライアントからサービスの検索がされた場合に利用できるサービスが起動されていない場合、
・あるサービスに障害が発生した場合にそのサービスを同じか別のノードで新規に起動する場合、
・サービスが起動されているが、その負荷が高い場合、
である。

したがって、サービス起動・終了部Ｊは、トリガーが発生するまでサービスを起動せず、起動可能なサービスのサービス情報を起動の有無と共に登録する（Ｓ２０１、２０２）。

以降は、ライフサイクル管理部１０Ａがサービスを利用するクライアントＡを起動する（Ｓ１０７）。

なお、ロケーション管理部２０Ａを動的に起動してもよい。例えば図１ではノード３にロケーション管理部が起動されていない。この場合、ノード３がロケーション管理部を待機系（動的起動）のサービスとしてノード２のロケーション管理部２０Ｂに登録しておくことで、ノード１又は２に障害が発生した場合、ノード３はロケーション管理部の再起動をノード３で行うことができる。すなわち、待機系であれば必要な場合にサービスを起動できる。

〔サービス検索（動的起動なし）〕
続いて、動的起動がない場合のサービス検索について説明する。図７はサービス検索のシーケンス図を示す。

まず、クライアントＡがロケーション管理部２０Ａのサービス検索部Ｂに対しサービス検索する（Ｓ３０１）。クライアントＡはサービスＩＤ、メーカＩＤ又はバージョンＩＤをサービス検索部Ｂへ送出する。

ロケーション管理部２０Ａのサービス検索部Ｂは、サービスリファレンス（戻り値）をクライアントへ送出する（Ｓ３０２）。クライアントは、サービスリファレンスによりサービス１を一意に特定できる。

ついで、クライアントＡは、サービス１が実際のどのノードで動作しているかを意識せずにサービス１を利用して任意の処理を依頼できる（Ｓ３０３）。

〔サービス検索（動的起動あり）〕
続いて、動的起動がある場合のサービス検索について説明する。図８はサービス検索のシーケンス図を示す。

動的起動がある場合、ライフサイクル管理部１０Ａは上記のトリガーが発生した場合にサービスを起動する。図８では一例としてサービス検索があった場合にサービスを起動する場合を示す。

クライアントＡは、ロケーション管理部２０Ａのサービス検索部Ｂにサービス検索を依頼する（Ｓ４０１）。

サービス検索部Ｂは、検索されたサービスが起動されているか否かをオブジェクトグループ管理Ｆが保持している管理テーブルから抽出し、起動されていない場合、ライフサイクル管理部１０Ａに起動要求する（Ｓ４０２）。

ライフサイクル管理部１０Ａは起動要求されたサービス１を起動する（Ｓ４０３）。なお、動的起動ありの場合、起動シーケンスにおいて既にサービス情報が登録されているためここではサービス情報は登録しない。

ついで、ライフサイクル管理部１０Ａは、サービス１のサービスリファレンス（戻り値）をロケーション管理部２０Ａに送出する（Ｓ４０４）。これにより、ロケーション管理部２０Ａのサービス検索部ＢはサービスリファレンスをクライアントＡに戻す（Ｓ４０５）。

サービスが起動されたらクライアントＡはサービスリファレンスに基づき任意の処理を依頼することができる（Ｓ４０６）。このように、クライアントＡは、サービス１が予め起動されていたか動的に起動されたかを意識する必要がない。

〔サービスの動作状況の収集（Ｐｕｌｌ型）〕
Ｐｕｌｌ型において各サービスの動作状況を収集する場合、ロケーション管理部２０Ａの状態収集部Ｃが各ライフサイクル管理部１０Ａに対して情報を要求し、結果を受け取る。図９は、一例として、各サービスの動作状況を収集するシーケンス図を示す（Ｐｕｌｌ型）。

まず、ロケーション管理部２０Ａの状態収集部Ｃがライフサイクル管理部１０Ａに動作状態情報を要求する（Ｓ５０１）。ライフサイクル管理部１０Ａの状態監視部Ｋは、サービス１及び２の負荷率、障害有無状況等の動作状態情報を取得する（Ｓ５０２〜Ｓ５０５）。ここで、負荷率を取得できなかったサービスは障害が発生し動作していないものと見なす。

ライフサイクル管理部１０Ａは、各サービスのサービス情報を取得したら、動作状態情報をロケーション管理部２０Ａに送出する（Ｓ５０６）。

また、ロケーション管理部１０Ａはすべてのノードに対し同様の動作状態情報の収集を行う。ロケーション管理部１０Ａは各ノードでのサービスの負荷率等を集計し、車載分散処理システムとして利用可能なサービスとその付加情報を更新し保持する。

ところで、動作状態情報の収集を行うとノード間の通信量が増大してしまう。図１０は、動作状態情報を収集する際の通信量を説明するための図である。

図１０はロケーション管理部２０Ｂがライフサイクル管理部１０Ｂ及び１０Ｃに動作状態情報を要求している。また、ライフサイクル管理部１０Ｂはサービス２（複製）とサービス３の動作状態を取得し、ライフサイクル管理部１０Ｃはサービス１（複製）とサービス４の動作状態を取得する。

ノード内の通信コストはノード間の通信コストよりも小さいと想定されるため、動作状態情報の収集においてもノード間の通信を低減する方が好ましい。図１０では、ライフサイクル管理部１０Ｂ、１０Ｃが行うサービスの状態監視はノード内での通信であり、ロケーション管理部２０Ｂとライフサイクル管理部１０Ｂ、１０Ｃとの通信はノード間通信を含むものとなる。図１０ではノード２がロケーション管理部２０Ｂとライフサイクル管理部１０ｂを有するため、ノード２内ではノード内通信となるが、ノードの数が増えるとノード間通信の割合が増大する。

ここでＰｕｓｈ型とＰｕｌｌ型を比較すると、Ｐｕｌｌ型では動作状態情報の収集に要求と応答の２回の通信が必要となり、Ｐｕｓｈ型では各ライフサイクル管理部が自立的に動作状態情報をロケーション管理部に配信するため１回の通信でよい。

しかしながら、Ｐｕｓｈ型であってもライフサイクル管理部からロケーション管理部への通信は呼び出しとして発生するため、個々のライフサイクル管理部からの呼び出しによる処理を低減することが好適である。

図１１はイベントサーバを用いてノード間の通信コストを低減するための車載分散処理システムの構成図を示す。なお図１１において図１０と同一部分には同一の符号を付した。イベントサーバとはコンテナによって管理されるサービスの一形態である。

図１１ではロケーション管理部２０Ｂとライフサイクル管理部１０Ｂ又は１０Ｃの間にイベントサーバ３０が介在している。イベントサーバ３０は、例えばＯＳの起動シーケンスの終了時に起動されるアプリケーション（サービス）である。イベントサーバが起動されるノードは、通信コストが最も小さくなる位置に配置する。

そして、ライフサイクル管理部１０Ｂ、１０ＣはＰｕｓｈ型により動作状態情報を収集し、イベントサーバ３０へ配信し、その時点での動作状態情報を集めておく。そして、以降はロケーション管理部２０ＢがＰｕｌｌ型によりイベントサーバ３０に動作状態情報を要求してもよいし、イベントサーバ３０がＰｕｓｈ型により動作状態情報をロケーション管理部２０Ｂへ配信してもよい。

このようなシステム構成であれば、ロケーション管理部が個々のライフサイクル管理部から呼び出されることがなく、また、ノード間の通信コストを最小化できるので、ロケーション管理部への配信と処理を効率よく行うことができる。

以上のように本実施の形態の車載分散処理システムによれば、ロケーション管理部が車載分散処理システム全体のサービスを収集し管理しているので、負荷分散や障害普及が可能となる。また、ロケーション管理部にサービスの情報が集約されているため、負荷分散や障害復旧を容易に実現できる。また、サービス情報には、ＣＰＵＩＤが含まれるので、性能の異なるＣＰＵが混在していても効率的に負荷分散を行うことができる。

また、サービス毎に動的又は非動的に起動できるので、システムリソースを浪費せずにサービスを起動でき、また、常に起動しておく方が好ましいサービスについて非動的に起動することで、車載分散処理システムの応答性を保つことができる。

クライアントが利用するサービスはサービス検索部により検索できその検索結果がサービスリファレンスとして返信されるため、クライアントはサービスの位置を意識せずにサービスを利用できる。

また、デバイスサービス起動・終了部Ｈによりデバイス機器を他のノードからも利用できるため、実行するノードが固定されるデバイス機器のその物理的な場所を考慮せずに利用することができ、そのデバイスに障害が発生した場合も効率よく同様のデバイス機器に切り替えてシステムの運用を継続させることができる。

また、接続ポリシ、負荷分散ポリシを設定できるので、負荷分散や障害復旧が可能なシステムにより提供される機能をクライアントが利用する場合に、障害発生時の例外処理として負荷分散のために多重化されたサービスを利用するのか、障害回復として新規に起動されたサービスを利用するのかを区別し、これらの設定や切替を行うことができる。

また、サービスの検索の際には、接続ポリシ、負荷分散ポリシがクライアントに設定されるので、クライアントはこれらのポリシにしたがいサービスに接続できる。すなわち、負荷分散が可能な場合、クライアントが必ず同じサービスに接続する必要があるのか、負荷の軽いサービスを利用するほうが好ましいのかを設定や切替を行うことができる。

また、ロケーション管理部が動作状態情報を収集する場合、収集の通信方法としてＰｕｓｈ方式又はＰｕｌｌ方式を選択でき、通信経路を効率よく実現することができ、また、イベントサーバを備えれば、通信コストを最適化できる。

車載分散処理システムの構成図例である。 各ノードのハードウェア構成図の一例である。 ライフサイクル管理部の機能ブロック図である。 ロケーション管理部の機能ブロック図である。 ライフサイクル管理部がノード内でプロセスを起動するシーケンス図の一例である。 ライフサイクル管理部がノード内でプロセスを起動するシーケンス図の一例である。 サービス検索のシーケンス図の一例である。 サービス検索のシーケンス図の一例である。 各サービスの動作状況を収集するシーケンス図の一例である。 動作状態情報を収集する際の通信量を説明するための図である。 イベントサーバを用いてノード間の通信コストを低減するための車載分散処理システムの構成図である。

符号の説明

１０Ａ〜１０Ｃ ライフサイクル管理部
２０Ａ、２０Ｂ ロケーション管理部
Ａ サービス登録部
Ｂ サービス検索部
Ｃ 状態収集部
Ｄ 負荷管理部
Ｅ 障害管理部
Ｆ オブジェクトグループ管理部
Ｇ デバイス管理部
Ｈ デバイスサービス起動・終了部
Ｉ デバイス機器追加・削除部
Ｊ サービス起動・終了部
Ｋ 状態監視部

Claims (15)

1. ネットワークに接続された複数のノードにより車両の車両情報を分散処理する車載分散処理システムにおいて、
   前記各ノードは、当該又は他のノードが利用するサービスを起動又は終了するライフサイクル管理部を有し、
   前記ノードの少なくとも一つが、前記サービスの動作状況を管理するロケーション管理部と、を有する
   ことを特徴とする車載分散処理システム。
2. 前記ライフサイクル管理部は、
   前記サービスを起動する場合、予め設定された設定情報に基づき、サービス毎に動的又は非動的に前記サービスを起動し、
   起動した前記サービスを前記ロケーション管理部に登録する、
   ことを特徴とする請求項１記載の車載分散処理システム。
3. 前記ロケーション管理部は、前記サービスを利用するクライアントが前記サービスを検索する場合、前記サービスの識別情報を前記クライアントに返す、
   ことを特徴とする請求項２記載の車載分散処理システム。
4. 前記サービスが動的に起動される場合、
   前記ライフサイクル管理部は、前記クライアントが前記サービスを検索した場合に、前記サービスを起動する、
   ことを特徴とする請求項３記載の車載分散処理システム。
5. 前記クライアントと前記サービスとの接続のポリシが設定された接続ポリシと、
   前記サービスの負荷分散のポリシが設定された負荷分散ポリシと、を有し、
   前記ロケーション管理部は、前記クライアントが前記サービスを検索した場合、前記接続ポリシ又は前記負荷分散ポリシを前記クライアントに設定する、
   ことを特徴とする請求項３記載の車載分散処理システム。
6. 前記ノードにデバイス機器が接続されている場合、
   前記ライフサイクル管理部は、前記デバイス機器のドライバを前記サービスとして起動するデバイス管理部を有する、
   ことを特徴とする請求項１記載の車載分散処理システム。
7. 前記設定情報は当該サービスが使用する前記デバイス機器の一覧を有し、
   前記ライフサイクル管理部は、前記サービスを起動する場合、前記一覧に記録された前記デバイス機器の前記ドライバを起動する、
   ことを特徴とする請求項６記載の車載分散処理システム。
8. 前記ロケーション管理部は、前記ノードで動作している前記サービスの稼動状態を示す動作状態情報を各ノードから収集する情報収集部を有する、
   ことを特徴とする請求項１記載の車載分散処理システム。
9. 前記ライフサイクル管理部が自立的に前記動作状態情報を前記情報収集部に配信する、
   ことを特徴とする請求項８記載の車載分散処理システム。
10. 前記状態収集部は、各ライフサイクル管理部に対し前記動作状態情報を要求し、前記ライフサイクル管理部から送信された前記動作状態情報を受け取る、
    ことを特徴とする請求項８記載の車載分散処理システム。
11. 所定の前記ノードに前記動作状態情報を中継するイベントサーバを有し、
    前記ライフサイクル管理部は自立的に前記動作状態情報を前記イベントサーバに配信し、
    前記ロケーション管理部は、前記イベントサーバに対し前記動作状態情報を要求し、前記イベントサーバから前記動作状態を受け取る、
    ことを特徴とする請求項８記載の車載分散処理システム。
12. 前記ロケーション管理部は、前記サービスの障害状況を管理する障害管理部を有し、
    前記障害管理部が障害を検出した場合、代替となる前記サービスが既に起動されている場合は前記識別情報を前記クライアントに返し、
    代替となる前記サービスが起動されていない場合、前記ライフサイクル管理部に前記サービスの起動を要求し該サービスの識別情報を前記クライアントに通知する、
    ことを特徴とする請求項３記載の車載分散処理システム。
13. 前記ロケーション管理部が当該車載分散処理システムに複数存在する場合、
    複数の前記ロケーション管理部は前記サービスの動作状況を同期して保持する、
    ことを特徴とする請求項１記載の車載分散処理システム。
14. 前記ロケーション管理部は、前記サービスの障害状況を管理する障害管理部を有し、
    所定の前記障害管理部が、複数の前記ロケーション管理部のうちのいずれかのロケーション管理部の障害を検出した場合、
    障害の生じた前記ロケーション管理部を再起動する、
    ことを特徴とする請求項１３記載の車載分散処理システム。
15. 前記ライフサイクル管理部は、所定時間、前記クライアントからの処理要求がなかった場合前記サービスを終了する、
    ことを特徴とする請求項１記載の車載分散処理システム。

Images