JP7415726B2 - 車載情報処理装置、情報処理方法及びサーバプログラム - Google Patents

Description

本開示は、クライアントへサービスを提供する処理を行う車載情報処理装置、情報処理方法及びサーバプログラムに関する。

近年、車両の自動運転機能の開発などが進められ、より高機能な車載システムの制御が求められている。これを実現するサービス指向ミドルウェアのアーキテクチャとして、ＳＯＭＥ／ＩＰ（Scalable service-Oriented MiddlewarE over IP）が注目されている。

特許文献１においては、新規サービスの提供開始前にその識別情報を外部装置へ送信し、外部装置からのテスト指示に応じて新規サービスのテストを行ってテスト結果を外部装置へ送信し、外部装置から新規サービスの提供を許可する旨を示す判定情報を受信した場合に、新規サービスの提供を開始するＥＣＵ（Electronic Control Unit）が提案されている。外部装置は、ＥＣＵから識別情報を受信した後、ＥＣＵにてテスト指示を送信してその結果を受信し、受信した結果に基づいて新規サービスの提供を許可するか否かを判定し、判定情報をＥＣＵへ送信する。

特開２０１６－１６３２４４号公報

ＳＯＭＥ／ＩＰにおいてサーバが提供するサービスには、サービスＩＤ及びバージョン等の情報が設定される。サービスの提供を望むクライアントは、サービスＩＤ及びバージョンを指定してサービスが提供されているか否かを検索する。例えばサービスを提供するサーバプログラムがバージョンアップされ、クライアントプログラムのバージョンアップが未実施である場合、サーバが提供するサービスのバージョンと、クライアントが望むサービスのバージョンとが一致せず、クライアントが所望のサービスを受けることができなくなる事態が発生し得る。

本開示は、斯かる事情に鑑みてなされたものであって、その目的とするところは、バージョンの不一致によりクライアントがサービスを受けることができなくなることをできるだけ回避することが期待できる車載情報処理装置、情報処理方法及びサーバプログラムを提供することにある。

本態様に係る車載情報処理装置は、要求に応じてサービスを提供する処理を行うサーバ処理部を備える車載情報処理装置であって、前記サーバ処理部は、サービスの提供を要求するクライアント処理部から、要求するサービスを検索する検索メッセージを受信し、前記検索メッセージは、要求するサービスの識別情報及びバージョン情報を含み、前記サーバ処理部は、受信した前記検索メッセージに含まれるバージョン情報と、自身が提供するサービスのバージョン情報とが一致するか否かを判定し、両バージョン情報が不一致であると判定した場合に、バージョン情報が異なるサービスを前記クライアント処理部へ提供する可否を検証し、バージョン情報が異なるサービスを提供することが可能である場合に、以後に前記クライアント処理部へ提供するサービスのバージョン情報を、前記検索メッセージに含まれるバージョン情報に変更して、当該サービスを前記クライアント処理部へ提供する。

本願は、このような特徴的な処理部を備える装置として実現することができるだけでなく、かかる特徴的な処理をステップとする方法として実現したり、かかるステップをコンピュータに実行させるためのコンピュータプログラムとして実現したりすることができる。これらの装置の一部又は全部を実現する半導体集積回路として実現したり、これらの装置を含むその他の装置又はシステムとして実現したりすることができる。

上記によれば、バージョンの不一致によりクライアントがサービスを受けることができなくなることをできるだけ回避することが期待できる。

本実施の形態に係る車載情報処理システムの構成を説明するための模式図である。 本実施の形態に係る車載情報処理システムの通信を説明するための模式図である。 本実施の形態に係る車載情報処理システムの通信を説明するための模式図である。 本実施の形態に係るクライアント側のＥＣＵの構成を示すブロック図である。 本実施の形態に係るサーバ側のＥＣＵの構成を示すブロック図である。 本実施の形態に係る車載情報処理システムにて送受信される検索メッセージ及び提供メッセージの一構成例を示す模式図である。 本実施の形態に係る車載情報処理システムにて送受信される要求メッセージ及び応答メッセージの一構成例を示す模式図である。 本実施の形態に係る車載情報処理システムで行われる処理の一例を説明するための模式図である。 本実施の形態に係る車載情報処理システムで行われる処理の一例を説明するための模式図である。 本実施の形態に係るクライアントのＥＣＵが行う処理の手順を示すフローチャートである。 本実施の形態に係るサーバのＥＣＵが行う処理の手順を示すフローチャートである。 本実施の形態に係るサーバのＥＣＵが行う検証処理の手順を示すフローチャートである。 本実施の形態に係るサーバのＥＣＵが行うその他の処理の手順を示すフローチャートである。 変形例１に係る車載情報処理システムで行われる処理の一例を説明するための模式図である。 変形例２に係る車載情報処理システムの構成を説明するための模式図である。

［本開示の実施の形態の説明］
最初に本開示の実施態様を列記して説明する。以下に記載する実施形態の少なくとも一部を任意に組み合わせてもよい。

（１）本態様に係る車載情報処理装置は、要求に応じてサービスを提供する処理を行うサーバ処理部を備える車載情報処理装置であって、前記サーバ処理部は、サービスの提供を要求するクライアント処理部から、要求するサービスを検索する検索メッセージを受信し、前記検索メッセージは、要求するサービスの識別情報及びバージョン情報を含み、前記サーバ処理部は、受信した前記検索メッセージに含まれるバージョン情報と、自身が提供するサービスのバージョン情報とが一致するか否かを判定し、両バージョン情報が不一致であると判定した場合に、バージョン情報が異なるサービスを前記クライアント処理部へ提供する可否を検証し、バージョン情報が異なるサービスを提供することが可能である場合に、当該サービスを前記クライアント処理部へ提供する。

本態様にあっては、車載情報処理装置のサーバ処理部が、サービスの提供を要求するクライアント処理部から、サービスを検索する検索メッセージを受信する。この検索メッセージにはクライアント処理部が必要とするサービスの識別情報及びバージョン情報を含み、サーバ処理部は、受信した検索メッセージに含まれるバージョン情報と自身が提供するサービスのバージョン情報とが一致するか否かを判定する。両バージョン情報が一致する場合、サーバ処理部はこのサービスをクライアント処理部に提供する処理を行う。両バージョン情報が一致しない場合、サーバ処理部は、バージョン情報が異なるサービスの提供をクライアント処理部が受けることが可能であるか否かの検証を行う。検証の結果、バージョン情報が異なるサービスの提供をクライアント処理部が受けることが可能である場合、サーバ処理部は、クライアント処理部が要求するサービスを提供するための情報処理を行う。これにより車載情報処理装置のサーバ処理部は、サービスのバージョン情報の不一致によりクライアント処理部がサービスを受けることができなくなることをできるだけ回避することが期待できる。

（２）前記サーバ処理部は、バージョン情報が異なるサービスを提供することが可能である場合に、以後に前記クライアント処理部へ提供するサービスのバージョン情報を、前記検索メッセージに含まれるバージョン情報に変更することが好ましい。

本態様にあっては、検証の結果、バージョン情報が異なるサービスの提供をクライアント処理部が受けることが可能である場合、サーバ処理部は、以後に自身がこのクライアント処理部へ提供するサービスのバージョン情報を、クライアント処理部から受信した検索メッセージに含まれるバージョン情報に変更する。これにより、以後はバージョン情報の不一致が発生することがなくなり、クライアント処理部の処理を円滑に行うことが期待できる。

（３）前記サーバ処理部は、自身が提供するサービスのバージョン情報を、前記検索メッセージに含まれるバージョン情報に一時的に変更し、一時的に変更したバージョン情報に基づいて前記クライアント処理部との間でメッセージの送受信を行い、前記メッセージの送受信の結果に基づいて、バージョン情報が異なるサービスの提供の可否を検証することが好ましい。

本態様にあっては、バージョン情報が異なるサービスの提供をクライアント処理部が受けることが可能であるか否かの検証を行う際に、サーバ処理部は、まず自身が提供するサービスのバージョン情報を、クライアント処理部から受信した検索メッセージに含まれるバージョン情報に一時的に変更する。その後、サーバ処理部は、変更したバージョン情報に基づいてクライアント処理部との間でサービスの提供に関するメッセージの送受信を行う。サーバ処理部は、このメッセージ送受信の結果に基づいて、バージョン情報が異なるサービスの提供をクライアント処理部が受けることが可能であるか否かを検証する。これにより車載情報処理装置は、クライアント処理部が提供を求めるサービスのバージョン情報に自身が提供するサービスのバージョン情報を変更した場合に、不具合が生じるか否か等を検証することができる。

（４）前記サーバ処理部は、前記クライアント処理部に所定のメッセージを送信させる命令を与え、前記命令に応じて前記クライアント処理部が送信するメッセージを受信し、受信したメッセージに基づいて検証を行うことが好ましい。

本態様にあっては、サーバ処理部がクライアント処理部に所定のメッセージを送信させる命令を与え、この命令に応じてクライアント処理部が送信するメッセージに基づいて検証を行う。これによりサーバ処理部は、バージョン情報が異なるサービスの提供をクライアント処理部が受けることができるか否かを、より精度よく検証することができる。

（５）前記サーバ処理部は、提供を望むサービスの有無を検索するために前記クライアント処理部が送信する検索メッセージを受信し、前記検索メッセージに対する応答として、自身が提供するサービスの識別情報及びバージョン情報を含む提供メッセージを送信することが好ましい。

本態様にあっては、車載情報処理装置のサーバ処理部は、クライアント処理部から提供を望むサービスの有無を検索する検索メッセージを受信し、この検索メッセージに対する応答として、自身が提供するサービスの識別情報及びバージョン情報を含む提供メッセージを送信する。これによりクライアント処理部は、サーバ処理部の提供メッセージを必要とする際に、検索メッセージを送信して提供メッセージを受信することができる。

（６）前記サーバ処理部は、自身が提供するサービスの識別情報及びバージョン情報を含む提供メッセージを所定周期で繰り返し送信することが好ましい。

本態様にあっては、車載情報処理装置のサーバ処理部は、自身が提供するサービスの識別情報及びバージョン情報を含む提供メッセージを所定周期で繰り返し送信する。これによりクライアント処理部は、周期的に送信される提供メッセージを受信して、自身に必要なサービスが提供されているか否かを判断することができ、サービスを提供するサーバ処理部がいずれであるかを判断することができる。

（７）前記サーバ処理部は、前記クライアント処理部を備える他の装置との間でメッセージの送受信を行うことが好ましい。

本態様にあっては、クライアント処理部を備える他の装置との間で車載情報処理装置のサーバ処理部がメッセージの送受信を行う。これにより車載情報処理装置は、他の装置が必要とするサービスを提供するための処理を行うことができる。

（８）前記クライアント処理部を備えることが好ましい。

本態様にあっては、サーバ処理部を備える車載情報処理装置が、クライアント処理部を備える。これにより車載情報処理装置は、外部の装置へサービスを提供する場合と同様の方法で、装置内部のクライアント処理部へサービスを提供する処理を実施することができる。

（９）本態様に係る情報処理方法は、車載情報処理装置のサーバ処理部が、クライアント処理部からの要求に応じてサービスを提供する処理を行う情報処理方法であって、前記サーバ処理部が、サービスの提供を要求するクライアント処理部から、要求するサービスを検索する検索メッセージを受信し、前記検索メッセージは、要求するサービスの識別情報及びバージョン情報を含み、前記サーバ処理部が、受信した前記検索メッセージに含まれるバージョン情報と、自身が提供するサービスのバージョン情報とが一致するか否かを判定し、前記サーバ処理部が、両バージョン情報が不一致であると判定した場合に、バージョン情報が異なるサービスを前記クライアント処理部へ提供する可否を検証し、前記サーバ処理部が、バージョン情報が異なるサービスを提供することが可能である場合に、当該サービスを前記クライアント処理部へ提供する。

本態様にあっては、態様（１）と同様に、サービスのバージョン情報の不一致によりサービスを受けることができなくなることをできるだけ回避することが期待できる。

（１０）本態様に係るサーバプログラムは、車両に搭載されたコンピュータに、サービスの提供を要求するクライアントプログラムから、要求するサービスを検索する検索メッセージを受信し、前記検索メッセージは、要求するサービスの識別情報及びバージョン情報を含み、受信した前記検索メッセージに含まれるバージョン情報と、自身が提供するサービスのバージョン情報とが一致するか否かを判定し、両バージョン情報が不一致であると判定した場合に、バージョン情報が異なるサービスを前記クライアントプログラムへ提供する可否を検証し、バージョン情報が異なるサービスを提供することが可能である場合に、当該サービスを前記クライアントプログラムへ提供する処理を実行させる。

本態様にあっては、態様（１）と同様に、サービスのバージョン情報の不一致によりサービスを受けることができなくなることをできるだけ回避することが期待できる。

［本開示の実施形態の詳細］
本開示の実施形態に係る車載情報処理システムの具体例を、以下に図面を参照しつつ説明する。本開示はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

＜システム構成＞
図１は、本実施の形態に係る車載情報処理システムの構成を説明するための模式図である。本実施の形態に係る車載情報処理システムは、車両１に搭載された複数のＥＣＵ２，３が中継器４を介して通信を行い、これら複数のＥＣＵ２，３が協働することで車両１の走行制御等に係る種々の情報処理を行うシステムである。図示の車載情報処理システムは、１つのＥＣＵ２と、３つのＥＣＵ３とが１つの中継器４にそれぞれ個別の通信線を介して接続されたスター型のネットワーク構成をなしている。ただし車載情報処理システムに含まれる装置の数及びネットワーク構成等は一例であって、これに限るものではない。車載情報処理システムに含まれるＥＣＵ２，３の数は合計３つ以下であってもよく、５つ以上であってもよい。また複数のＥＣＵ２，３は、バス型又はリング型等のネットワーク構成で接続されていてもよい。

ＥＣＵ２，３は、車両１に搭載された情報処理装置である。例えばＥＣＵ２，３には、車両１の自動運転を制御するＥＣＵ、エンジンの動作を制御するＥＣＵ、ドアのロック／アンロックを制御するＥＣＵ、ライトの点灯／消灯を制御するＥＣＵ、エアバッグの動作を制御するＥＣＵ、及び、ＡＢＳ（Antilock Brake System）の動作を制御するＥＣＵ等の種々のＥＣＵが含まれ得る。なお本実施の形態においては車載情報処理装置をＥＣＵ２，３とするが、これに限るものではなく、車載情報処理装置はＥＣＵ２，３以外の種々の装置であってよい。

中継器４は、通信線を接続するためのポートを複数備え、これらのポートに接続された通信線間のメッセージの送受信を中継する装置である。例えば中継器４は、スイッチングハブ又はゲートウェイ等の装置である。中継器４は、一の通信線にて受信したメッセージを他の通信線から送信することによって、メッセージの送受信を中継する。なお車載情報処理システムは、例えば複数のＥＣＵ２，３が共通の通信線に接続されるバス型のネットワーク構成が採用される場合等には、中継器４を備えていなくてよい。

本実施の形態に係る車載情報処理システムでは、ＥＣＵ２，３の間のメッセージ送受信を、ＳＯＭＥ／ＩＰの通信規格に従って行う。ＳＯＭＥ／ＩＰは、ＯＳＩ参照モデルの第５層以上に分類される規格であり、アプリケーションプログラムの間でサービスの要求及びその応答の態様で通信が行われる。本実施の形態においては、ＥＣＵ２がサービスを提供するサーバ側の装置であり、ＥＣＵ３がサービスの提供を受けるクライアント側の装置であるものとする。ただしこのクライアント及びサーバの関係は一例であり、各ＥＣＵ２，３はクライアント及びサーバのいずれにもなり得る。なおＯＳＩ参照モデルの第４層以下の通信については、どのような規格が採用されてもよいが、例えばイーサネット（登録商標）、ＴＣＰ（Transmission Control Protocol）又はＵＤＰ（User Datagram Protocol）等の規格が採用され得る。

図２及び図３は、本実施の形態に係る車載情報処理システムの通信を説明するための模式図である。本図においては、３つのＥＣＵ３に対してそれぞれＥＣＵ３ａ，３ｂ，３ｃの異なる符号を付して区別している。例えば図２に示すようにＥＣＵ３ａは、起動又は再起動が行われた後等の所定のタイミングで、自身が必要とするサービスを検索する検索メッセージ（検索フレーム）を送信する。本実施の形態においてＥＣＵ３ａは、１つのメッセージを複数の装置に対して同時的に送信する送信方法、いわゆるマルチキャストで検索メッセージを送信する。これによりＥＣＵ３ａが送信した検索メッセージは、ＥＣＵ２，３ｂ，３ｃにて受信される（図２において検索メッセージの送受信を破線の矢印で示す）。

ＥＣＵ３ａが送信する検索メッセージには、ＥＣＵ３ａが必要とするサービスを識別するためのサービスＩＤと、このサービスを提供するソフトウェア（サーバプログラム）のバージョンを識別するサービスバージョンとが含まれている。検索メッセージを受信したＥＣＵ２，３ｂ，３ｃは、受信した検索メッセージに含まれるサービスＩＤ及びサービスバージョンに合致するサービスを提供可能であるか否かを判定する。本例ではＥＣＵ２がこのサービスを提供可能であり、ＥＣＵ２は検索メッセージを送信したＥＣＵ３ａに対して、サービス提供が可能である旨を通知する提供メッセージ（提供フレーム）を送信する。このときにＥＣＵ２は、提供メッセージの送信先をＥＣＵ３ａの１つとする送信方法、いわゆるユニキャストで提供メッセージを送信する（図２において提供メッセージの送受信を一点鎖線の矢印で示す）。

ＥＣＵ２から送信された提供メッセージを受信したＥＣＵ３ａは、サービスを提供可能な装置が存在し、且つ、この装置がＥＣＵ２であることを提供メッセージに基づいて判断することができる。提供メッセージには、サービスＩＤ及びサービスバージョンの情報と、サービスを提供するサーバ（ＥＣＵ２）のＩＰアドレス及びポート番号等の情報とが含まれている。以後、ＥＣＵ３ａはこのサービスに関する情報提供の要求等をＥＣＵ２へ送信し、この要求に応じてＥＣＵ２がサービスに関する情報を含む応答をＥＣＵ３ａへ送信する。これによりサーバであるＥＣＵ２からクライアントであるＥＣＵ３ａへサービスが提供され、ＥＣＵ３ａはＥＣＵ２から提供されるサービスを利用した種々の情報処理を行うことができる。

また本実施の形態において、提供メッセージの送信は検索メッセージに対する応答として行われるもののみではなく、サービスを提供するＥＣＵ２が自発的に所定周期で提供メッセージの送信を行っている。サービスを提供することができるＥＣＵ２は、自身が提供するサービスに関する情報を含む提供メッセージを、例えば数ミリ秒～数秒程度の所定周期で繰り返し送信する。図３に示すようにＥＣＵ２は、周期的な提供メッセージの送信を行う場合、１つの提供メッセージを複数の装置に対して同時的に送信する送信方法、いわゆるマルチキャストで送信する。これによりＥＣＵ２が送信した提供メッセージは、ＥＣＵ３ａ，３ｂ，３ｃにて受信される（図３において提供メッセージの送受信を一点鎖線の矢印で示す）。

検索メッセージに対して送信される提供メッセージと、周期的に送信される提供メッセージとは同じものであってよく、これを受信したＥＣＵ３ａは、上述のように、自身が必要とするサービスをＥＣＵ２が提供していることを知ることができ、以後はＥＣＵ２に対してサービスに関する要求を送信することができる。サービスを必要としないＥＣＵ３ｂ，３ｃは、周期的に送信される提供メッセージを受信した場合に、これを破棄（無視）すればよい。

このように本実施の形態に係る車載情報処理システムでは、サービスを必要とするクライアント側のＥＣＵ３ａが、提供メッセージに基づいてこのサービスを提供しているＥＣＵ２を予め知る必要がある。ＥＣＵ２がサービスを提供していることが判明した後、ＥＣＵ３ａは、ＥＣＵ２との間でメッセージの送受信を行い、ＥＣＵ２からサービスの提供を受けて情報処理を行うことができる。ＥＣＵ３ａはサービスの提供を要求する要求メッセージをＥＣＵ２へ送信し、この要求メッセージに対する応答としてＥＣＵ２は応答メッセージをＥＣＵ３ａへ送信する。

なお本実施の形態においてサーバとなるＥＣＵ２が提供するサービスは、ＥＣＵ２が有する情報の提供、例えば車両１の車速又は車両１の周辺の物体検知結果等の種々の情報を含むメッセージを、要求元のＥＣＵ３ａへ送信する処理とすることができる。また例えば、ＥＣＵ２が例えば車両１のライト又はドアのロック等の車載機器を制御する装置である場合に、ＥＣＵ３ａからの要求に応じてこれらの車載機器を制御するサービスをＥＣＵ２が提供することができる。サーバとなるＥＣＵ２が提供するサービスは、上記のものに限らず、種々の処理であってよい。

ここで、車載情報処理システムに含まれるＥＣＵ２，３ａ～３ｃでは、ソフトウェアの更新によりバージョンアップが行われることがあり得る。バージョンアップは車載情報処理システムの全装置で一斉に行われる場合もあるが、個々の装置で個別に行われる場合もある。このため、例えばこのサービスの提供を受けるＥＣＵ３ａのソフトウェアのバージョンアップが行われ、且つ、サービスを提供するＥＣＵ２でソフトウェアのバージョンアップがなされないという状況が発生し得る。このような状況において、ＥＣＵ３ａが新バージョンでサービスを指定した検索メッセージを送信しても、これを受信したＥＣＵ２は自身が提供するサービスとはバージョンが異なるため提供メッセージをＥＣＵ３ａに送信せず、ＥＣＵ３ａがサービスを受けることができなくなる。またＥＣＵ２は周期的に旧バージョンでサービスを指定した提供メッセージを送信するが、これを受信したＥＣＵ３ａは自身が望むサービスのバージョンとは異なるためＥＣＵ２へサービスを要求するメッセージの送信を行わない。即ち、ＥＣＵ２からＥＣＵ３ａへのサービスの提供を行うことができなくなる。

そこで本実施の形態に係る車載情報処理システムでは、自身が提供するサービスとサービスＩＤが同じでサービスバージョンが異なるサービスの提供を望むクライアント側のＥＣＵ３ａが存在する場合に、サーバ側のＥＣＵ２がこのサービスの提供をクライアント側のＥＣＵ３ａが受けることが可能であるか否かの検証を行う。検証の結果、サービスバージョンが異なるサービスの提供をクライアント側のＥＣＵ３ａが受けることが可能であると判断した場合、サーバ側のＥＣＵ２は、このクライアントのＥＣＵ３ａに対してサービスを提供するための処理を行うことができる。

＜装置構成＞
図４は、本実施の形態に係るクライアント側のＥＣＵ３の構成を示すブロック図である。本実施の形態に係るＥＣＵ３は、処理部（プロセッサ）３１、記憶部（ストレージ）３２及び通信部（トランシーバ）３３等を備えて構成されている。処理部３１は、例えばＣＰＵ（Central Processing Unit）又はＭＰＵ（Micro-Processing Unit）等の演算処理装置を用いて構成されている。処理部３１は、記憶部３２に記憶されたクライアントプログラム３２ａを読み出して実行することにより、必要なサービスを提供するサーバを検索する処理及びサーバが提供するサービスに応じた情報処理等の種々の処理を行うことができる。

記憶部３２は、例えばフラッシュメモリ又はＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）等の不揮発のメモリ素子を用いて構成されている。記憶部３２は、処理部３１が実行する各種のプログラム、及び、処理部３１の処理に必要な各種のデータを記憶する。本実施の形態において記憶部３２は、処理部３１が実行するクライアントプログラム３２ａを記憶している。

クライアントプログラム３２ａは、例えばＥＣＵ３の製造段階において記憶部３２に書き込まれてよい。また例えばクライアントプログラム３２ａは遠隔のサーバ装置などにより配信されてもよく、ＥＣＵ３はサーバ装置との通信にてクライアントプログラム３２ａを取得して記憶部３２に書き込んでもよい。また例えばメモリカード又は光ディスク等の記録媒体９９に記録されたクライアントプログラム３２ａをＥＣＵ３が読み出して記憶部３２に記憶してもよい。また例えば記録媒体９９に記録されたクライアントプログラム３２ａを書込装置が読み出してＥＣＵ３の記憶部３２に書き込んでもよい。クライアントプログラム３２ａは、ネットワークを介した配信の態様で提供されてもよく、記録媒体９９に記録された態様で提供されてもよい。

通信部３３は、車両１に配設された通信線が接続され、この通信線を介して他のＥＣＵ２，３との間でメッセージの送受信を行う。本実施の形態において通信部３３は、例えばイーサネットの通信規格に従ってメッセージの送受信を行う。通信部３３は、例えばイーサネットＰＨＹ（physical layer）のＩＣ（Integrated Circuit）等を用いて構成され得る。ただし通信部３３が用いる通信規格はイーサネットに限らず、例えばＣＡＮ（Controller Area Network）又はＦｌｅｘＲａｙ等の種々の通信規格が採用され得る。通信部３３は、処理部３１から与えられたデータを電気信号として通信線へ出力することによりメッセージ送信を行う。また通信部３３は、通信線の電位をサンプリングして取得することにより、通信線上の電気信号をデジタルデータに変換し、変換したデータを受信メッセージとして処理部３１へ与える。

また本実施の形態にＥＣＵ３は、記憶部３２に記憶されたクライアントプログラム３２ａを処理部３１が読み出して実行することにより、クライアント処理部３１０が処理部３１にソフトウェア的な機能部として実現される。クライアント処理部３１０は、ＳＯＭＥ／ＩＰの規格に従って、サービスの提供を受けるクライアントとしての種々の処理を行う。本実施の形態においてクライアント処理部３１０は、サービス検索部３１０ａ及びアプリケーション処理部３１０ｂ等を備えている。

サービス検索部３１０ａは、自身の処理に必要なサービスを提供するサーバを検索する処理を行う。サービス検索部３１０ａは、自身の処理に必要なサービスのサービスＩＤ及びサービスバージョンを指定した検索メッセージを通信部３３からマルチキャストで送信する。サービス検索部３１０ａは、送信した検索メッセージに対してサーバから送信される提供メッセージを受信し、受信した提供メッセージに含まれるＩＰアドレス及びポート番号等の情報を取得することによって、サービスを提供するサーバの有無を判断すると共に、サーバとの通信に必要な情報を取得する。またサービス検索部３１０ａは、サーバが周期的に送信する提供メッセージを受信し、受信した提供メッセージに含まれるＩＰアドレス及びポート番号等の情報を取得することによって、サービスを提供するサーバの有無を判断すると共に、サーバとの通信に必要な情報を取得する。

アプリケーション処理部３１０ｂは、提供されるサービスを利用して、各ＥＣＵ３に特有のアプリケーションに関する情報処理を行う。アプリケーション処理部３１０ｂは、サービス検索部３１０ａが検索したサーバに対して、サービスＩＤ及びサービスバージョンを指定した要求メッセージを送信し、これに応じて送信される応答メッセージを受信する。アプリケーション処理部３１０ｂは、受信した応答メッセージに含まれる情報を取得し、取得した情報に基づいて種々の情報処理を行う。例えばアプリケーション処理部３１０ｂは、車両１の車速の情報送信をサーバに対して要求する要求メッセージを送信し、これに応じてサーバから受信した応答メッセージに含まれる車速の情報を取得して、車速を用いた種々の情報処理を行うことができる。サーバから提供されるサービスを利用してアプリケーション処理部３１０ｂが行う情報処理は、どのような処理であってもよい。

図５は、本実施の形態に係るサーバ側のＥＣＵ２の構成を示すブロック図である。本実施の形態に係るＥＣＵ２は、処理部（プロセッサ）２１、記憶部（ストレージ）２２及び通信部（トランシーバ）２３等を備えて構成されている。処理部２１は、例えばＣＰＵ又はＭＰＵ等の演算処理装置を用いて構成されている。処理部２１は、記憶部２２に記憶されたサーバプログラム２２ａを読み出して実行することにより、サービスの検索に対して提供するサービスを通知する処理及びクライアントに対してサービスを提供する処理等の種々の処理を行うことができる。

記憶部２２は、例えばフラッシュメモリ又はＥＥＰＲＯＭ等の不揮発のメモリ素子を用いて構成されている。記憶部２２は、処理部２１が実行する各種のプログラム、及び、処理部２１の処理に必要な各種のデータを記憶する。本実施の形態において記憶部２２は、処理部２１が実行するサーバプログラム２２ａを記憶している。

サーバプログラム２２ａは、例えばＥＣＵ２の製造段階において記憶部２２に書き込まれてよい。また例えばサーバプログラム２２ａは遠隔のサーバ装置などにより配信されてもよく、ＥＣＵ２はサーバ装置との通信にてサーバプログラム２２ａを取得して記憶部２２に書き込んでもよい。また例えばメモリカード又は光ディスク等の記録媒体９８に記録されたサーバプログラム２２ａをＥＣＵ２が読み出して記憶部２２に記憶してもよい。また例えば記録媒体９８に記録されたサーバプログラム２２ａを書込装置が読み出してＥＣＵ２の記憶部２２に書き込んでもよい。サーバプログラム２２ａは、ネットワークを介した配信の態様で提供されてもよく、記録媒体９８に記録された態様で提供されてもよい。

通信部２３は、車両１に配設された通信線が接続され、この通信線を介して他のＥＣＵ３との間でメッセージの送受信を行う。本実施の形態において通信部２３は、例えばイーサネットの通信規格に従ってメッセージの送受信を行う。通信部２３は、例えばイーサネットＰＨＹのＩＣ等を用いて構成され得る。ただし通信部２３が用いる通信規格はイーサネットに限らず、例えばＣＡＮ又はＦｌｅｘＲａｙ等の種々の通信規格が採用され得る。通信部２３は、処理部２１から与えられたデータを電気信号として通信線へ出力することによりメッセージ送信を行う。また通信部２３は、通信線の電位をサンプリングして取得することにより、通信線上の電気信号をデジタルデータに変換し、変換したデータを受信メッセージとして処理部２１へ与える。

また本実施の形態にＥＣＵ２は、記憶部２２に記憶されたサーバプログラム２２ａを処理部２１が読み出して実行することにより、サーバ処理部２１０が処理部２１にソフトウェア的な機能部として実現される。サーバ処理部２１０は、ＳＯＭＥ／ＩＰの規格に従って、サービスを提供するサーバとしての種々の処理を行う。本実施の形態においてサーバ処理部２１０は、サービス情報提供部２１０ａ、サービス検証部２１０ｂ及びアプリケーション処理部２１０ｃ等を備えている。

サービス情報提供部２１０ａは、自身が提供するサービスに関する情報を含む提供メッセージを送信する処理を行う。サービス情報提供部２１０ａは、クライアントからの検索メッセージを受信した場合に、この検索メッセージに含まれるサービスＩＤ及びサービスバージョンが自身の提供するサービスのサービスＩＤ及びサービスバージョンと一致するか否かを判定する。サービスＩＤ及びサービスバージョンが一致する場合、サービス情報提供部２１０ａは、検索メッセージの送信元のクライアントに対して、ユニキャストで提供メッセージを送信する。またサービス情報提供部２１０ａは、所定の周期で、自身が提供するサービスに関する情報を含む提供メッセージをマルチキャストで送信する。

サービス検証部２１０ｂは、自身が提供するサービスとサービスＩＤが一致し且つサービスバージョンが異なるサービスの提供がクライアントのＥＣＵ３から要求されている場合に、このサービスバージョンが異なるサービスの提供をＥＣＵ３が受ける可否を検証する処理を行う。サービス検証部２１０ｂは、クライアントのＥＣＵ３から受信した検索メッセージに含まれるサービスＩＤ及びサービスバージョンを取得し、検索メッセージのサービスＩＤと自身が提供するサービスのサービスＩＤとが一致し、且つ、検索メッセージのサービスバージョンと自身が提供するサービスのサービスバージョンとが一致しない場合に、検証処理を開始する。サービス検証部２１０ｂは、検証対象のクライアントのＥＣＵ３に対して自身が提供するサービスのサービスバージョンを、検索メッセージのサービスバージョンへ一時的に変更する。サービス検証部２１０ｂは、変更したサービスバージョンが設定された提供メッセージを、検証対象のＥＣＵ３へ送信する。

この提供メッセージを受信したＥＣＵ３は、自身が提供を望むサービスをＥＣＵ２が提供していると判断し、このサービスを利用するための要求メッセージをＥＣＵ２へ送信する。要求メッセージには、自身が要求するサービスのサービスＩＤ及びサービスバージョンの情報が含まれる。ＥＣＵ２のサービス検証部２１０ｂは、ＥＣＵ３からの要求メッセージを受信し、受信した要求メッセージの正否を判定する。サービス検証部２１０ｂは、ＥＣＵ３から所定数（例えば１０）の要求メッセージを受信し、所定数の要求メッセージのうち正しいと判定された要求メッセージの数が閾値（例えば５）を超えた場合に、サービスバージョンが異なるサービスの提供をＥＣＵ３が受けることが可能であると判断する。正しいと判定された要求メッセージの数が閾値を超えない場合、サービス検証部２１０ｂは、サービスバージョンが異なるサービスの提供をＥＣＵ３が受けることが不可能であると判断する。

またサービス検証部２１０ｂは、ＥＣＵ３から受信する各要求メッセージの正否を、例えば以下の方法で判定することができる。
・要求メッセージに含まれる各種のＩＤ情報等が正当な値であるか否か。
・要求メッセージの送信毎にインクリメント又はデクリメント等の変化がなされるセッションＩＤ等の値について、その値の変化が正当であるか否か。
・サービスへの要求に関する引数又は戻り値等の値が正当な範囲内であるか否か。

ただし、要求メッセージの正否の判定方法は上記のものに限らない。例えばＥＣＵ２，３のメッセージ送受信がＳＯＭＥ／ＩＰの規格に従うものである場合に、サービス検証部２１０ｂは、ＳＯＭＥ／ＩＰの規格においてエラーと判定されるか否かを、上述の正否判定としてよい。

サービス検証部２１０ｂは、サービスバージョンが異なるサービスの提供をＥＣＵ３が受けることが不可能であると判断した場合、一時的に変更したサービスのサービスバージョンを元に戻し、以後にこのＥＣＵ３から受信する検索メッセージ及び要求メッセージ（ただし、検証を行ったサービスＩＤと同じサービスＩＤを含むメッセージに限る）に対する応答を行わない。このためクライアントのＥＣＵ３は、このＥＣＵ２からサービスを受けることができなくなる。

サービス検証部２１０ｂは、サービスバージョンが異なるサービスの提供をＥＣＵ３が受けることが可能であると判断した場合、一時的に変更したサービスのサービスバージョンを元に戻すことなく維持する、即ちサービスバージョンを永続的に変更する。サービス検証部２１０ｂは、以後にこのＥＣＵ３から受信する検索メッセージ及び要求メッセージに対して、変更したサービスバージョンでの応答を行う。即ちＥＣＵ２は、このＥＣＵ３へ送信する提供メッセージ及び応答メッセージに含めるサービスバージョンを、変更したサービスバージョンとする。

アプリケーション処理部２１０ｃは、ＥＣＵ２に特有のサービスを提供するための情報処理を行う。アプリケーション処理部２１０ｃは、クライアントのＥＣＵ３からの要求メッセージを受信し、受信した要求メッセージに含まれるサービスＩＤ及びサービスバージョンを取得する。アプリケーション処理部２１０ｃは、取得したサービスＩＤ及びサービスバージョンに対応するサービスを提供するための情報処理を行う。アプリケーション処理部２１０ｃは、情報処理の結果として得られる情報を含む応答メッセージを生成し、要求メッセージの送信元のクライアントに対して応答メッセージを送信する。

＜クライアント及びサーバの処理＞
図６は、本実施の形態に係る車載情報処理システムにて送受信される検索メッセージ及び提供メッセージの一構成例を示す模式図である。本実施の形態に係るクライアントのＥＣＵ３が送信する検索メッセージ、及び、サーバのＥＣＵ２が送信する提供メッセージは、ヘッダ情報、メッセージタイプ、サービスＩＤ、サービスバージョン及びオプション情報等の情報を含んで構成されている。

メッセージのヘッダ情報は、例えばイーサネットヘッダ、ＩＰヘッダ、ＴＣＰ／ＵＤＰヘッダ及びＳＯＭＥ／ＩＰヘッダ等であり、通信規格で定められる情報を格納するためのものである。ヘッダ情報には、例えばＭＡＣアドレス、イーサネットタイプ、ＩＰアドレス又はポート番号等の情報が格納され得る。ヘッダ情報の形式はどのようなものであってもよく、ヘッダ情報に格納される情報はどのようなものであってもよい。

メッセージタイプは、このメッセージが検索メッセージ又は提供メッセージのいずれであるかを示す情報が格納される。例えばこのメッセージは、メッセージタイプに「０」が設定された場合に検索メッセージとなり、「１」が設定された場合に提供メッセージとなる。

サービスＩＤは、サーバが提供するサービスに対して一意に付される識別情報である。サービスバージョンは、提供するサービスのバージョンを識別する情報であり、例えばサービスＩＤで識別されるサービスを提供するためにサーバが動作させるソフトウェアのバージョンである。本実施の形態においてサービスバージョンは、その数値が大きいほど新しいバージョンを示すものとする。検索メッセージに含まれるサービスＩＤ及びサービスバージョンは、クライアントがサーバに提供を望むサービスのサービスＩＤ及びサービスバージョンである。提供メッセージに含まれるサービスＩＤ及びサービスバージョンは、サーバが提供することができるサービスのサービスＩＤ及びサービスバージョンである。

オプション情報は、本実施の形態においては提供メッセージに付される情報であり、サービスを提供するサーバのＩＰアドレス及びポート番号等の情報が含まれる。ただし、検索メッセージについても同様に、クライアントのＩＰアドレス及びポート番号等の情報をオプション情報としてメッセージに付してもよい。

図７は、本実施の形態に係る車載情報処理システムにて送受信される要求メッセージ及び応答メッセージの一構成例を示す模式図である。要求メッセージは、クライアントがサーバに対してサービスの提供を要求するためのメッセージである。また応答メッセージは、サーバがクライアントからの要求メッセージに対する応答として送信するメッセージである。本実施の形態に係るクライアントのＥＣＵ３が送信する要求メッセージ及びサーバのＥＣＵ２が送信する応答メッセージは、ＳＯＭＥ／ＩＰの規格のためのヘッダ情報及びその他の規格のためのヘッダ情報を含むヘッダ情報と、ＳＯＭＥ／ＩＰのペイロードとが含まれる。ＳＯＭＥ／ＩＰのヘッダ情報には、例えばサービスＩＤ、メソッドＩＤ、サービスバージョン、セッションＩＤ及びメッセージ種別等の情報が含まれ得る。ＳＯＭＥ／ＩＰのペイロードには、サービスの要求に関する引数、又は、サービスの要求に関する戻り値等の情報が含まれ得る。

ＳＯＭＥ／ＩＰのヘッダ情報に含まれるサービスＩＤ及びサービスバージョンは、上述の通りである。メソッドＩＤは、サービスＩＤで指定されるサービスについて提供される複数のメソッドのうち、いずれのメソッドを用いるかを指定するＩＤである。例えば、サービスＩＤとして車両情報提供サービスを指定する数値が設定された場合、メソッドＩＤとして車速を提供するメソッド、加速度を提供するメソッド又は舵角を提供するメソッド等を指定する数値が設定され得る。

セッションＩＤは、例えばサービスの要求及び提供毎にインクリメントされる（その値が１増加される）数値情報である。例えば、クライアントがセッションＩＤ＝１としてサービス要求を送信し、これに対してセッションＩＤ＝１のサービス応答を受信した場合に、クライアントは次の要求をセッションＩＤ＝２としてサービス要求を送信する。クライアントは、所望のサービス応答を受信しない場合には、同じセッションＩＤを設定してサービス要求の再送信を行うことができる。

メッセージ種別は、例えばこのメッセージがクライアントからサーバへの要求メッセージであるか、又は、サーバからクライアントへの応答メッセージであるかを示す数値が設定される。

ＳＯＭＥ／ＩＰのペイロードに含まれるサービス要求の引数は、クライアントからサーバへの要求メッセージに含まれる情報である。サービス要求の引数は、クライアントが実施するサービスに関する処理に用いられる数値等の情報であり、クライアントがサービスの処理に対する条件等を設定するために用いられる。引数が必要でないサービスについては、要求メッセージに引数の情報が含まれていなくてもよい。

サービス要求の戻り値は、サーバからクライアントへの応答メッセージに含まれる情報である。例えば、要求メッセージにおいて車速の情報送信が要求された場合には、車速の情報が戻り値として応答メッセージに設定される。また例えば、要求メッセージにおいて情報送信ではなく、車載機器の制御等のサービスに対する要求がなされた場合、応答メッセージには要求された制御等が正常に行われたか否かを示す値が戻り値として設定される。

図８及び図９は、本実施の形態に係る車載情報処理システムで行われる処理の一例を説明するための模式図である。本図では、サーバのＥＣＵ２が提供するサービスのサービスバージョンが「１．１」であり、クライアントのＥＣＵ３が要求するサービスのサービスバージョンが「１．１」から「１．２」へバージョンアップされる例を示している。バージョンアップ前においてクライアントのＥＣＵ３は、サービスバージョンを「１．１」に設定した要求メッセージをサーバのＥＣＵ２へ送信する。サーバのＥＣＵ２は、この要求メッセージの受信に対してサービスバージョンが「１．１」のサービスを提供するための情報処理を実施し、情報処理の結果を含む応答メッセージを要求元のＥＣＵ３へ送信する。このときにＥＣＵ２が送信する応答メッセージのサービスバージョンは「１．１」である。

その後、クライアントのＥＣＵ３においてサービスを利用して情報処理を行うためのソフトウェア（クライアントプログラム３２ａ）のバージョンアップが実施され、サービスバージョンが「１．１」から「１．２」へ更新される。これに対してサービスを提供するサーバのＥＣＵ２のソフトウェア（サーバプログラム２２ａ）はバージョンアップが行われておらず、ＥＣＵ２はサービスバージョンが「１．１」のサービスを提供する。この状況において、ＥＣＵ３がサービスバージョンを「１．２」に設定した検索メッセージ及び要求メッセージをＥＣＵ２へ送信しても、ＥＣＵ２はサービスバージョンが異なるため提供メッセージ及び応答メッセージをＥＣＵ３へ送信できない虞がある。

バージョンアップの完了後に、クライアントのＥＣＵ３は、サービスバージョンを「１．２」に設定した検索メッセージを送信する。本実施の形態に係るサーバのＥＣＵ２は、この検索メッセージを受信することによって、自身が提供するサービスのサービスＩＤが一致し、且つ、サービスバージョンが異なるサービスがＥＣＵ３により要求されていることを認識できる。

そこでＥＣＵ２は、ＥＣＵ３に対して提供するサービスのバージョンを一時的に「１．１」から「１．２」へ変更する。ＥＣＵ２は、サービスバージョンを「１．２」に設定した提供メッセージを、検索メッセージを送信したＥＣＵ３に対して送信する。その後、ＥＣＵ２は、自身が提供するサービスバージョンが「１．１」のサービスを、サービスバージョンが「１．２」のサービスを要求するＥＣＵ３の情報処理に利用することが可能であるか否かを検証する検証処理を開始する。

ＥＣＵ２は、その後にＥＣＵ３から送信されるサービスバージョンが「１．２」の要求メッセージを受信し、受信した要求メッセージの正否を判定すると共に、要求メッセージに対する応答メッセージを要求元のＥＣＵ３へ送信する。このときにＥＣＵ２が送信する応答メッセージのサービスバージョンは「１．２」に設定される。ＥＣＵ２は、ＥＣＵ３から受信した要求メッセージの正否を、例えば要求メッセージに含まれる各種のＩＤ情報等が正当な値であるか否か、要求メッセージのセッションＩＤの変化が正当であるか否か、及び、要求メッセージのペイロードの値が正当な範囲内であるか否か等に基づいて判定する。

ＥＣＵ２は、ＥＣＵ３から所定数の要求メッセージを受信するまで検証処理を継続して行い、所定数の要求メッセージを受信した場合に、各要求メッセージの正否判定結果に基づいて、サービスバージョンが異なるサービスの提供をＥＣＵ３が受けることができるか否かの最終的な判断を行う。ＥＣＵ２は、例えば受信した所定数の要求メッセージのうち、正当と判定したメッセージ数が閾値を超える場合に、サービスバージョンが異なるサービスの提供をＥＣＵ３が受けることが可能であると判断する。正当と判定したメッセージ数が閾値を超えない場合、ＥＣＵ２は、サービスバージョンが異なるサービスの提供をＥＣＵ３が受けることが不可能であると判断する。

検証処理において、サービスバージョンが「１．１」のサービスをＥＣＵ３が利用可能であると判断した場合（図８参照）、ＥＣＵ２は、ＥＣＵ３に対して提供するサービスのバージョンを永続的に「１．２」へ変更する。その後、ＥＣＵ２は、このＥＣＵ３から送信されるサービスバージョンが「１．２」に設定された要求メッセージを受信し、サービスバージョンが「１．１」のサービスを提供するための情報処理を行い、この処理結果を含む応答メッセージのサービスバージョンを「１．２」に設定してＥＣＵ３へ送信する。

検証処理において、サービスバージョンが「１．１」のサービスをＥＣＵ３が利用不可能であると判断した場合（図９参照）、ＥＣＵ２は、検証処理のために一時的に変更したサービスバージョンを「１．２」から「１．１」へと戻す。その後、ＥＣＵ２は、ＥＣＵ３からサービスバージョンが「１．２」に設定された要求メッセージ及び検索メッセージを受信した場合、これに対して応答メッセージ及び提供メッセージを送信しない。即ちＥＣＵ２は、検証処理においてサービス提供が不可能と判断したＥＣＵ３に対しては、以後に受信するサービスバージョンが異なる要求メッセージ及び検索メッセージに対して応答を行わず、検証処理を繰り返して行うことはない。

図１０は、本実施の形態に係るクライアントのＥＣＵ３が行う処理の手順を示すフローチャートである。本実施の形態に係るＥＣＵ３は、例えば車両１のイグニッションスイッチがオフ状態からオン状態へ切り替えられたタイミングで起動される（ステップＳ１）。起動後にＥＣＵ３の処理部３１のサービス検索部３１０ａは、自身が必要とするサービスを提供するサーバを検索するための検索メッセージをマルチキャストで送信する（ステップＳ２）。その後、サービス検索部３１０ａは、送信した検索メッセージに対する応答としてサーバが送信する提供メッセージ、又は、サーバが周期的に送信する提供メッセージを受信したか否かを判定する（ステップＳ３）。提供メッセージを受信していない場合（Ｓ３：ＮＯ）、サービス検索部３１０ａは、提供メッセージを受信するまで待機する。

提供メッセージを受信した場合（Ｓ３：ＹＥＳ）、アプリケーション処理部３１０ｂは、提供メッセージの送信元のＥＣＵ２が提供するサービスを利用した情報処理を開始し、サーバのＥＣＵ２へ要求メッセージを送信する（ステップＳ４）。アプリケーション処理部３１０ｂは、ステップＳ４にて送信した要求メッセージに対するサーバのＥＣＵ２からの応答メッセージを受信したか否かを判定する（ステップＳ５）。応答メッセージを受信していない場合（Ｓ５：ＮＯ）、アプリケーション処理部３１０ｂは、応答メッセージを受信するまで待機する。応答メッセージを受信した場合（Ｓ５：ＹＥＳ）、アプリケーション処理部３１０ｂは、受信した応答メッセージに含まれる情報に応じた情報処理を行い（ステップＳ６）、ステップＳ４へ処理を戻す。

図１１は、本実施の形態に係るサーバのＥＣＵ２が行う処理の手順を示すフローチャートである。本実施の形態に係るサーバのＥＣＵ２の処理部２１のサービス情報提供部２１０ａは、クライアントのＥＣＵ３が送信する検索メッセージを受信したか否かを判定する（ステップＳ１１）。検索メッセージを受信した場合（Ｓ１１：ＹＥＳ）、サービス情報提供部２１０ａは、検索メッセージに含まれるサービスＩＤが、自身の提供するサービスのサービスＩＤと一致するか否かを判定する（ステップＳ１２）。サービスＩＤが一致しない場合（Ｓ１２：ＮＯ）、サービス情報提供部２１０ａは、提供メッセージを送信せずに、処理を終了する。

サービスＩＤが一致する場合（Ｓ１２：ＹＥＳ）、サービス情報提供部２１０ａは、受信した検索メッセージに含まれるサービスバージョンが、自身の提供するサービスのサービスバージョンと一致するか否かを判定する（ステップＳ１３）。サービスバージョンが一致する場合（Ｓ１３：ＹＥＳ）、サービス情報提供部２１０ａは、検索メッセージの送信元のＥＣＵ３へ、提供メッセージを送信し（ステップＳ１４）、処理を終了する。

サービスバージョンが一致しない場合（Ｓ１３：ＮＯ）、サービス情報提供部２１０ａは、自身が提供するサービスのサービスバージョンを、受信した検索メッセージに含まれるサービスバージョンへ一時的に変更する（ステップＳ１５）。その後、サービス情報提供部２１０ａは、一時的に変更したサービスバージョンが設定された提供メッセージを、検索メッセージの送信元のＥＣＵ３へ送信する（ステップＳ１６）。

その後、処理部２１のサービス検証部２１０ｂは、ＥＣＵ３との間で送受信される要求メッセージ及び応答メッセージに基づく検証処理を行う（ステップＳ１７）。サービス検証部２１０ｂは、ステップＳ１７の検証処理の結果に基づいて、検索メッセージに含まれるサービスバージョンとは異なるサービスバージョンのサービス、即ちＥＣＵ２が提供可能なサービスバージョンのサービスを、ＥＣＵ３に提供することが可能であるか否かを判定する（ステップＳ１８）。サービスを提供可能と判定した場合（Ｓ８：ＹＥＳ）、サービス検証部２１０ｂは、クライアントのＥＣＵ３に対して提供するサービスのサービスバージョンを永続的に変更し（ステップＳ１９）、処理を終了する。

サービスを提供不可能と判定した場合（Ｓ１８：ＮＯ）、サービス検証部２１０ｂは、ステップＳ１５にて一時的に変更したサービスバージョンを、元のサービスバージョンへ戻す（ステップＳ２０）。サービス検証部２１０ｂは、検証処理の対象としてクライアントのＥＣＵ３から以後に受信するサービスバージョンが異なる検索メッセージ及び要求メッセージについて、メッセージの受け付けを禁止して（ステップＳ２１）、処理を終了する。

なおＥＣＵ２は、検証処理を行ったクライアントのＥＣＵ３の識別情報と、このＥＣＵ３が要求するサービスのサービスＩＤ及びサービスバージョン等の情報と、検証処理の結果とを対応付けたテーブル等を記憶部２２に記憶し、検証済みのＥＣＵ３から同様の検索メッセージ又は要求メッセージを受信した場合に、このテーブルを参照して受信したメッセージに対する応答を行うか否かを判断してよい。上記のフローチャートにおいて、ステップＳ１９のサービスバージョンを永続的に変更する処理、及び、ステップＳ２１の以後のメッセージの受け付けを禁止する処理等は、ＥＣＵ２がこのテーブルに適切な情報を設定することで行われ得る。

図１２は、本実施の形態に係るサーバのＥＣＵ２が行う検証処理の手順を示すフローチャートであり、図１１に示したフローチャートのステップＳ１７において行う処理の詳細である。本実施の形態に係るＥＣＵ２の処理部２１のサービス検証部２１０ｂは、検証対象のＥＣＵ３から要求メッセージを受信したか否かを判定する（ステップＳ３１）。要求メッセージを受信していない場合（Ｓ３１：ＮＯ）、サービス検証部２１０ｂは、要求メッセージを受信するまで待機する。

要求メッセージを受信した場合（Ｓ３１：ＹＥＳ）、サービス検証部２１０ｂは、受信した要求メッセージの正否を判定する（ステップＳ３２）。このときにサービス検証部２１０ｂは、例えば要求メッセージに含まれる各種のＩＤ情報等が正当な値であるか否か、要求メッセージのセッションＩＤの変化が正当であるか否か、及び、要求メッセージのペイロードの値が正当な範囲内であるか否か等に基づいて、受信した要求メッセージの正否を判定することができる。サービス検証部２１０ｂは、受信した要求メッセージに対する応答メッセージを、要求メッセージの送信元のＥＣＵ３へ送信する（ステップＳ３３）。このときにＥＣＵ２が送信する応答メッセージは、正規の情報が格納された応答メッセージであってもよく、検証用に所定の値が格納された応答メッセージであってもよい。サービス検証部２１０ｂは、検証対象のＥＣＵ３から所定回数の要求メッセージの受信を終えたか否かを判定する（ステップＳ３４）。所定回数の要求メッセージの受信を終えていない場合（Ｓ３４：ＮＯ）、サービス検証部２１０ｂは、ステップＳ３１へ処理を戻す。

所定回数の要求メッセージの受信を終えた場合（Ｓ３４：ＹＥＳ）、サービス検証部２１０ｂは、受信した所定数の要求メッセージのうち、正当と判定した要求メッセージの数が閾値を超えるか否かを判定する（ステップＳ３５）。正当な要求メッセージの数が閾値を超える場合（Ｓ３５：ＹＥＳ）、サービス検証部２１０ｂは、検証対象のＥＣＵ３に対してこのサービスを提供することが可能であると判定し（ステップＳ３６）、検証処理を終了して図１１のフローチャートへ処理を戻す。正当な要求メッセージの数が閾値を超えない場合（Ｓ３５：ＮＯ）、サービス検証部２１０ｂは、検証対象のＥＣＵ３に対してこのサービスを提供することが不可能であると判定し（ステップＳ３７）、検証処理を終了して図１１のフローチャートへ処理を戻す。

図１３は、本実施の形態に係るサーバのＥＣＵ２が行うその他の処理の手順を示すフローチャートである。本実施の形態に係るサーバのＥＣＵ２の処理部２１のアプリケーション処理部２１０ｃは、クライアントのＥＣＵ３が送信する要求メッセージを受信したか否かを判定する（ステップＳ５１）。要求メッセージを受信した場合（Ｓ５１：ＹＥＳ）、アプリケーション処理部２１０ｃは、受信した要求メッセージに含まれるサービスＩＤ及びサービスバージョンが、自身の提供するサービスのサービスＩＤ及びサービスバージョンと一致するか否かを判定する（ステップＳ５２）。サービスＩＤ及びサービスバージョンが一致しない場合（Ｓ５２：ＮＯ）、アプリケーション処理部２１０ｃは、ステップＳ５１へ処理を戻す。

サービスＩＤ及びサービスバージョンが一致する場合（Ｓ５２：ＹＥＳ）、アプリケーション処理部２１０ｃは、受信した要求メッセージに含まれる情報に基づいて、要求されたサービスを提供するための情報処理を行う（ステップＳ５３）。アプリケーション処理部２１０ｃは、情報処理の結果として得られる情報を含む応答メッセージを、要求メッセージの送信元のＥＣＵ３へ送信し（ステップＳ５４）、ステップＳ５１へ処理を戻す。

要求メッセージを受信していない場合（Ｓ５１：ＮＯ）、処理部２１のサービス情報提供部２１０ａは、周期的な提供メッセージの送信について、前回の送信から所定期間が経過したか否かを判定する（ステップＳ５５）。所定期間が経過した場合（Ｓ５５：ＹＥＳ）、サービス情報提供部２１０ａは、周期的な提供メッセージの送信を行い（ステップＳ５６）、ステップＳ５１へ処理を戻す。所定期間が経過していない場合（Ｓ５５：ＮＯ）、サービス情報提供部２１０ａは、ステップＳ５１へ処理を戻す。

＜まとめ＞
以上の構成の本実施の形態に係るサーバのＥＣＵ２のサーバ処理部２１０は、サービスの提供を要求するクライアントのＥＣＵ３のクライアント処理部３１０から、サービスを検索する検索メッセージを受信する。この検索メッセージにはクライアント処理部３１０が必要とするサービスのサービスＩＤ及びサービスバージョンを含み、サーバ処理部２１０は、受信した検索メッセージに含まれるサービスバージョンと自身が提供するサービスのサービスバージョンとが一致するか否かを判定する。両サービスバージョンが一致する場合、サーバ処理部２１０は、このサービスをクライアント処理部３１０へ提供するための情報処理を行う。両サービスバージョンが一致しない場合、サーバ処理部２１０は、サービスバージョンが異なるサービスの提供をクライアント処理部３１０が受けることが可能であるか否かの検証処理を行う。検証処理の結果、サービスバージョンが異なるサービスの提供をクライアント処理部３１０が受けることが可能である場合、サーバ処理部２１０は、クライアント処理部３１０が要求するサービスを提供するための情報処理を行う。これによりサーバのＥＣＵ２のサーバ処理部２１０は、サービスのサービスバージョンの不一致によりクライアント処理部３１０がサービスを受けることができなくなることをできるだけ回避することができる。

また本実施の形態においては、検証処理の結果、サービスバージョンが異なるサービスの提供をクライアント処理部３１０が受けることが可能である場合、サーバ処理部２１０は、まず自身が提供するサービスのサービスバージョンを、クライアント処理部３１０から受信した検索メッセージに含まれるサービスバージョンに変更する。これにより、以後はサービスバージョンの不一致が発生することがなくなり、クライアント処理部３１０の処理を円滑に行うことができる。

また本実施の形態においては、サービスバージョンが異なるサービスの提供をクライアント処理部３１０が受けることが可能であるか否かの検証を行う際に、サーバ処理部２１０は、まず自身が提供するサービスのサービスバージョンを、クライアント処理部３１０から受信した検索メッセージに含まれるサービスバージョンに一時的に変更する。その後、サーバ処理部２１０は、変更したサービスバージョンに基づいてクライアント処理部３１０との間でサービスの提供に関するメッセージの送受信を行う。サーバ処理部２１０は、このメッセージの送受信の結果に基づいて、サービスバージョンが異なるサービスの提供をクライアント処理部３１０が受けることが可能であるか否かを検証する。これによりＥＣＵ２は、ＥＣＵ３のクライアント処理部３１０が提供を求めるサービスのサービスバージョンに自身が提供するサービスのサービスバージョンを変更した場合に、不具合が生じるか否か等を検証することができる。

また本実施の形態においてＥＣＵ２のサーバ処理部２１０は、ＥＣＵ３のクライアント処理部３１０から提供を望むサービスの有無を検索する検索メッセージを受信し、この検索メッセージに対する応答として、自身が提供するサービスのサービスＩＤ及びサービスバージョン等の情報を含む提供メッセージを送信する。これによりクライアント処理部３１０は、サーバ処理部２１０の提供メッセージを必要とする際に、検索メッセージを送信して提供メッセージを受信することができる。

また本実施の形態においてはＥＣＵ２のサーバ処理部２１０は、自身が提供するサービスのサービスＩＤ及びサービスバージョン等の情報を含む提供メッセージを所定周期で繰り返し送信する。これによりクライアント処理部３１０は、周期的に送信される提供メッセージを受信して、自身に必要なサービスが提供されているか否かを判断することができ、サービスを提供するサーバ処理部２１０がいずれであるかを判断することができる。

また本実施の形態に係る車載情報処理システムでは、サーバ処理部２１０がＥＣＵ２に備えられ、クライアント処理部３１０がＥＣＵ３に備えられる。ＥＣＵ２のサーバ処理部２１０は、クライアント処理部３１０を備えるＥＣＵ３との間でメッセージの送受信を行う。これによりＥＣＵ２は、他の装置が必要とするサービスを提供するための情報処理を行うことができる。

なお本実施の形態においては、車載情報処理システムのＥＣＵ２，３がＳＯＭＥ／ＩＰの規格に従ってサービスに関するメッセージの送受信を行う構成としたが、これに限るものではなく、ＳＯＭＥ／ＩＰ以外の規格に従ってメッセージの送受信を行う構成であってよい。本実施の形態において説明した技術は、サーバ及びクライアントがメッセージの送受信を行うシステムであれば、どのようなシステムであっても利用することが可能な技術である。

（変形例１）
図１４は、変形例１に係る車載情報処理システムで行われる処理の一例を説明するための模式図である。変形例１に係る車載情報処理システムでは、サーバのＥＣＵ２は、サービスバージョンが異なるサービスをＥＣＵ３に対して提供可能であるか否かを検証する際に、まず検証命令メッセージを検証対象のＥＣＵ３へ送信する。検証命令メッセージは、ＥＣＵ３に対して通常の情報処理を一時的に停止させ、ＥＣＵ２が検証処理に必要な要求メッセージの送信をＥＣＵ３に行わせるためのメッセージである。検証命令メッセージには、例えばＥＣＵ３が送信すべきメッセージの種別及び送信の順序等の情報が含まれ得る。

検証命令メッセージを受信したクライアントのＥＣＵ３は、自身の情報処理を一時的に停止し、検証命令メッセージに含まれる情報に基づいて、要求メッセージの送信と応答メッセージの受信とを繰り返し行う。サーバのＥＣＵ２は、ＥＣＵ３が送信する要求メッセージを受信して正否を判定すると共に、要求メッセージに対する応答メッセージをＥＣＵ３へ送信する。このときに送受信される要求メッセージ及び応答メッセージのサービスバージョンは「１．２」に設定される。

ＥＣＵ３は、検証命令メッセージに従って所定数の要求メッセージを送信する。所定数の要求メッセージを送信した後、ＥＣＵ３は、一時的に停止した自身の情報処理を再開してよい。ＥＣＵ２は、ＥＣＵ３から所定数の要求メッセージを受信するまで検証処理を継続して行い、所定数の要求メッセージを受信した場合に、各要求メッセージの正否判定結果に基づいて、サービスバージョンが異なるサービスの提供をＥＣＵ３が受けることができるか否かの最終的な判断を行う。検証処理において、サービスバージョンが「１．１」のサービスをＥＣＵ３が利用可能であると判断した場合、ＥＣＵ２は、ＥＣＵ３に対して提供するサービスのバージョンを永続的に「１．２」へ変更する。その後、ＥＣＵ２は、このＥＣＵ３から送信されるサービスバージョンが「１．２」に設定された要求メッセージを受信し、サービスバージョンが「１．１」のサービスを提供するための情報処理を行い、この処理結果を含む応答メッセージのサービスバージョンを「１．２」に設定してＥＣＵ３へ送信する。

以上の構成の変形例１に係る車載情報処理システムでは、サーバのＥＣＵ２のサーバ処理部２１０が、クライアントのＥＣＵ３のクライアント処理部３１０に対して、所定の要求メッセージを送信させる検証命令メッセージを送信する。クライアント処理部３１０は、この検証命令メッセージに応じて要求メッセージを送信する。サーバ処理部２１０は、検証命令メッセージに応じてクライアント処理部３１０が送信する要求メッセージに基づいて検証を行う。これによりサーバ処理部２１０は、サービスバージョンが異なるサービスの提供をクライアント処理部３１０が受けることができるか否かを、より精度よく検証することができる。

（変形例２）
図１５は、変形例２に係る車載情報処理システムの構成を説明するための模式図である。変形例２に係る車載情報処理システムでは、１つのＥＣＵ５がクライアント処理部３１０及びサーバ処理部２１０の両方を備える。変形例２に係るＥＣＵ５は、処理部５１、記憶部５２及び通信部５３等を備えて構成されている。記憶部５２には、クライアントプログラム３２ａ及びサーバプログラム２２ａが記憶されている。ＥＣＵ５では、処理部５１が記憶部５２に記憶されたクライアントプログラム３２ａを読み出して実行することにより、処理部５１にクライアント処理部３１０がソフトウェア的な機能部として実現される。同様にＥＣＵ５では、処理部５１がサーバプログラム２２ａを読み出して実行することにより、処理部５１にサーバ処理部２１０がソフトウェア的な機能部として実現される。処理部５１は、例えばタイムシェアリング等により複数のプログラムを並列的に動作させることができ、クライアント処理部３１０及びサーバ処理部２１０は並列的に動作している。

変形例２に係るＥＣＵ５では、通信部５３による外部の装置との通信を行うことなく、クライアント処理部３１０及びサーバ処理部２１０が要求メッセージ及び応答メッセージの授受を行うことができ、検索メッセージ及び提供メッセージの授受を行うことができる。クライアント処理部３１０は、サーバ処理部２１０が装置の内部又は外部のいずれに存在するかに関係なく、自身の処理に必要なサービスを提供するサーバ処理部２１０を検索する処理、サービスバージョンが異なるサービスの提供を受けることができるか否かを検証する処理、及び、サーバ処理部２１０に対してサービスの提供を要求する処理等を行うことができる。

以上の構成の変形例２に係る車載情報処理システムでは、サーバ処理部２１０を備えるＥＣＵ５が、クライアント処理部３１０を持備える。これによりＥＣＵ５のサーバ処理部２１０は、外部の装置へサービスを提供する場合と同様の方法で、装置内部のクライアント処理部３１０へサービスを提供することができる。

車載システムにおける各装置は、マイクロプロセッサ、ＲＯＭ及びＲＡＭ等を含んで構成されるコンピュータを備える。マイクロプロセッサ等の演算処理部は、図１０～図１３に示すような、シーケンス図又はフローチャートの各ステップの一部又は全部を含むコンピュータプログラムを、ＲＯＭ、ＲＡＭ等の記憶部からそれぞれ読み出して実行してよい。これら複数の装置のコンピュータプログラムは、それぞれ、外部のサーバ装置等からインストールすることができる。また、これら複数の装置のコンピュータプログラムは、それぞれ、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、半導体メモリ等の記録媒体に格納された状態で流通する。

今回開示された実施形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本開示の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１ 車両
２ ＥＣＵ（車載情報処理装置）
３，３ａ～３ｃ ＥＣＵ
４ 中継器
５ ＥＣＵ
２１ 処理部
２２ 記憶部
２２ａ サーバプログラム
２３ 通信部
３１ 処理部
３２ 記憶部
３２ａ クライアントプログラム
３３ 通信部
５１ 処理部
５２ 記憶部
５３ 通信部
９８，９９ 記録媒体
２１０ サーバ処理部
２１０ａ サービス情報提供部
２１０ｂ サービス検証部
２１０ｃ アプリケーション処理部
３１０ クライアント処理部
３１０ａ サービス検索部
３１０ｂ アプリケーション処理部

Claims (9)

1. 要求に応じてサービスを提供する処理を行うサーバ処理部を備える車載情報処理装置であって、
   前記サーバ処理部は、サービスの提供を要求するクライアント処理部から、要求するサービスを検索する検索メッセージを受信し、
   前記検索メッセージは、要求するサービスの識別情報及びバージョン情報を含み、
   前記サーバ処理部は、
   受信した前記検索メッセージに含まれるバージョン情報と、自身が提供するサービスのバージョン情報とが一致するか否かを判定し、
   両バージョン情報が不一致であると判定した場合に、バージョン情報が異なるサービスを前記クライアント処理部へ提供する可否を検証し、
   バージョン情報が異なるサービスを提供することが可能である場合に、以後に前記クライアント処理部へ提供するサービスのバージョン情報を、前記検索メッセージに含まれるバージョン情報に変更して、当該サービスを前記クライアント処理部へ提供する、
   車載情報処理装置。
2. 前記サーバ処理部は、
   自身が提供するサービスのバージョン情報を、前記検索メッセージに含まれるバージョン情報に一時的に変更し、
   一時的に変更したバージョン情報に基づいて前記クライアント処理部との間でメッセージの送受信を行い、
   前記メッセージの送受信の結果に基づいて、バージョン情報が異なるサービスの提供の可否を検証する、
   請求項１に記載の車載情報処理装置。
3. 前記サーバ処理部は、
   前記クライアント処理部に所定のメッセージを送信させる命令を与え、
   前記命令に応じて前記クライアント処理部が送信するメッセージを受信し、
   受信したメッセージに基づいて検証を行う、
   請求項２に記載の車載情報処理装置。
4. 前記サーバ処理部は、
   提供を望むサービスの有無を検索するために前記クライアント処理部が送信する検索メッセージを受信し、
   前記検索メッセージに対する応答として、自身が提供するサービスの識別情報及びバージョン情報を含む提供メッセージを送信する、
   請求項１から請求項３までのいずれか１つに記載の車載情報処理装置。
5. 前記サーバ処理部は、自身が提供するサービスの識別情報及びバージョン情報を含む提供メッセージを所定周期で繰り返し送信する、
   請求項１から請求項４までのいずれか１つに記載の車載情報処理装置。
6. 前記サーバ処理部は、前記クライアント処理部を備える他の装置との間でメッセージの送受信を行う、
   請求項１から請求項５までのいずれか１つに記載の車載情報処理装置。
7. 前記クライアント処理部を備える、
   請求項１から請求項５までのいずれか１つに記載の車載情報処理装置。
8. 車載情報処理装置のサーバ処理部が、クライアント処理部からの要求に応じてサービスを提供する処理を行う情報処理方法であって、
   前記サーバ処理部が、サービスの提供を要求するクライアント処理部から、要求するサービスを検索する検索メッセージを受信し、
   前記検索メッセージは、要求するサービスの識別情報及びバージョン情報を含み、
   前記サーバ処理部が、受信した前記検索メッセージに含まれるバージョン情報と、自身が提供するサービスのバージョン情報とが一致するか否かを判定し、
   前記サーバ処理部が、両バージョン情報が不一致であると判定した場合に、バージョン情報が異なるサービスを前記クライアント処理部へ提供する可否を検証し、
   前記サーバ処理部が、バージョン情報が異なるサービスを提供することが可能である場合に、以後に前記クライアント処理部へ提供するサービスのバージョン情報を、前記検索メッセージに含まれるバージョン情報に変更して、当該サービスを前記クライアント処理部へ提供する、
   情報処理方法。
9. 車両に搭載されたコンピュータに、
   サービスの提供を要求するクライアントプログラムから、要求するサービスを検索する検索メッセージを受信し、
   前記検索メッセージは、要求するサービスの識別情報及びバージョン情報を含み、
   受信した前記検索メッセージに含まれるバージョン情報と、自身が提供するサービスのバージョン情報とが一致するか否かを判定し、
   両バージョン情報が不一致であると判定した場合に、バージョン情報が異なるサービスを前記クライアントプログラムへ提供する可否を検証し、
   バージョン情報が異なるサービスを提供することが可能である場合に、以後に前記クライアントプログラムへ提供するサービスのバージョン情報を、前記検索メッセージに含まれるバージョン情報に変更して、当該サービスを前記クライアントプログラムへ提供する
   処理を実行させる、サーバプログラム。

Images