JP2021158517A - 車載情報処理装置、情報処理方法及びクライアントプログラム - Google Patents

Abstract

【課題】バージョンの不一致によりクライアントがサービスを受けることができなくなることをできるだけ回避できる車載情報処理装置、情報処理方法及びクライアントプログラムを提供する。【解決手段】本実施の形態に係る車載情報処理装置は、サービスの提供を受けて処理を行うクライアント処理部を備える車載情報処理装置であって、前記クライアント処理部は、サービスを提供するサーバ処理部から、提供するサービスの識別情報及びバージョン情報を含む提供メッセージを受信し、受信した前記提供メッセージに含まれるバージョン情報と、自身が提供を望むサービスのバージョン情報とが一致するか否かを判定し、両バージョン情報が不一致であると判定した場合に、バージョン情報が異なるサービスの提供を受ける可否を検証し、検証結果に基づいてバージョン情報が異なるサービスの提供を受けることが可能である場合に、当該サービスの提供を受けて処理を行う。【選択図】図７

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 (11)

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

Images