WO2022153708A1 - サービス仲介装置、サービス仲介方法、および、プログラム - Google Patents

Abstract

サービス仲介装置（３００）は、サーバユニットからクライアントユニットへサービス指向型通信によってサービスを提供するサービス提供システムにおいて、サーバユニットおよびクライアントユニットそれぞれに接続され、サーバユニットまたはクライアントユニットから、サービスの提供に用いられるフレームを受信する通信制御部（３０１）と、通信制御部（３０１）が受信したフレームに含まれるサービスの識別子と、フレームの送信元または宛先を示す識別子と、フレームの種別との組合せが適切であるか否かの判定をし、判定の結果の出力をするサービス管理部（３０２）とを備える。

Description

サービス仲介装置、サービス仲介方法、および、プログラム

　本開示は、サービス仲介装置、サービス仲介方法、および、プログラムに関する。

　近年、自動車には、電子制御ユニット（以下、ＥＣＵ：Electronic Control Unit）と呼ばれる装置が多数配置されている。ＥＣＵ間の通信におけるなりすましの脅威に対して、暗号通信を用いて不正なノードによる通信を防ぐ方法が存在する。

ＲＦＣ５４０６：Ｇｕｉｄｅｌｉｎｅｓ　ｆｏｒ　Ｓｐｅｃｉｆｙｉｎｇ　ｔｈｅ　Ｕｓｅ　ｏｆ　ＩＰｓｅｃ　Ｖｅｒｓｉｏｎ２ ＩＥＥＥ　８０２．１ＡＥ：ＭＡＣ　Ｓｅｃｕｒｉｔｙ

　しかしながら、暗号通信を用いると、送受信ノードによる暗号化または復号処理が必要となり、オーバーヘッドが発生してしまう問題がある。

　そこで、本開示は、サービス提供に係る通信のアクセス制御を適切に行うサービス仲介方法を提供する。

　本開示の一態様に係るサービス仲介装置は、サーバユニットからクライアントユニットへサービス指向型通信によってサービスを提供するサービス提供システムにおいて、サーバユニットおよびクライアントユニットそれぞれに接続され、前記サーバユニットまたは前記クライアントユニットから、前記サービスの提供に用いられるフレームを受信する通信制御部と、前記通信制御部が受信した前記フレームに含まれるサービスの識別子と、前記フレームの送信元または宛先を示す識別子と、前記フレームの種別との組合せが適切であるか否かの判定をし、前記判定の結果の出力をするサービス管理部とを備えるサービス仲介装置である。

　なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

　本開示によれば、サービス提供に係る通信のアクセス制御を適切に行うことができる。

図１は、実施の形態における、車載ネットワークシステムの全体構成を示す図である。 図２は、実施の形態における、ＳＯＭＥ／ＩＰ　ＳＤのメッセージフォーマットを示す図である。 図３は、実施の形態における、ＳＯＭＥ／ＩＰ　ＳＤのメッセージの一例を示す図である。 図４は、実施の形態における、サーバＥＣＵの構成を示す図である。 図５は、実施の形態における、仲介ＥＣＵの構成を示す図である。 図６Ａは、実施の形態における、アプリ認証情報の第一例を示す図である。 図６Ｂは、実施の形態における、アプリ認証情報の第二例を示す図である。 図６Ｃは、実施の形態における、アプリ認証情報の第三例を示す図である。 図７は、実施の形態における、サービスポリシの一例を示す図である。 図８Ａは、実施の形態における、サービス情報の一例を示す図である。 図８Ｂは、実施の形態における、アクセス制御情報の一例を示す図である。 図９は、実施の形態における、車両状態の一例を示す図である。 図１０は、実施の形態における、仲介ＥＣＵのサービス情報登録シーケンスを示す図である。 図１１Ａは、実施の形態における、ＳＤ仲介のみを行うサービスの通信シーケンスを示す図である。 図１１Ｂは、実施の形態における、代理送信を行うサービスの通信シーケンスを示す図である。 図１２は、実施の形態における、仲介ＥＣＵのサブサーバ登録シーケンスを示す図である。 図１３は、実施の形態における、仲介ＥＣＵによる代理送信の通信シーケンスを示す図である。 図１４は、実施の形態における、異常発生時の代理送信の通信シーケンスを示す図である。 図１５は、実施の形態における、異常発生時のサブサーバへの切り替えシーケンスを示す図である。 図１６は、実施の形態における、仲介ＥＣＵによるＳＤメッセージに対する処理を示すフローチャートである。 図１７は、実施の形態における、仲介ＥＣＵによるＳＯＭＥ／ＩＰメッセージに対する処理を示すフローチャートである。 図１８は、実施の形態における、メインサーバの通信異常が検知されたときのサーバ切り替え処理を示すフローチャートである。 図１９Ａは、実施の形態の変形例におけるサービス仲介装置の構成を示す図である。 図１９Ｂは、実施の形態の変形例におけるサービス仲介装置を示すフロー図である。 図１９Ｃは、その他の変形例における仲介ＥＣＵによるサービス仲介方法の決定フローチャートである。 図２０は、その他の変形例における異常検知時に通知されるログの一例を示す図である。

　（本発明の基礎となった知見）
　本発明者は、「背景技術」の欄において記載した、サービスの仲介装置などに関し、以下の問題が生じることを見出した。

　自動車において、ＥＣＵをつなぐ車載ネットワークでは、多数の通信プロトコルの規格が存在し、その中でも最も主流な規格の一つは、Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ（以降、ＣＡＮ（登録商標））である。

　ＣＡＮでは、ＥＣＵがセンサ値等の情報をブロードキャスト送信し、センサ値等の情報を取得したいＥＣＵが、そのブロードキャスト送信されたセンサ値等の情報を受信する。

　さらに、自動運転またはコネクテッドカーの普及に伴い、車載ネットワークトラフィックの増大が予想されるため、通信プロトコルとしての車載Ｅｔｈｅｒｎｅｔ（登録商標）の普及も進んでいる。

　車載Ｅｔｈｅｒｎｅｔ（登録商標）では、ＣＡＮのようなシグナル指向型通信に代えて、または、シグナル指向型通信とともに、サービス指向型通信が導入されるようになり、効率的な開発プロセスを実現できる。

　サービス指向型通信の実現方法として、Ｓｅｒｖｉｃｅ　Ｏｒｉｅｎｔｅｄ　Ｍｉｄｄｌｅ　ＷａｒＥ　Ｏｖｅｒ　ＩＰ（以下ＳＯＭＥ／ＩＰ）が、ＡＵＴｏｍｏｔｉｖｅ　Ｏｐｅｎ　Ｓｙｓｔｅｍ　ＡＲｃｈｉｔｅｃｔｕｒｅ（ＡＵＴＯＳＡＲ）で規定されている。

　ＣＡＮにおける不正なノードによるなりすまし攻撃の脅威は、ＳＯＭＥ／ＩＰ通信においても同様に脅威である。このような脅威に対して、Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ（ＩＰ）通信で用いられてきた、暗号通信を用いて不正なノードによる通信を防ぐ方法が存在する（非特許文献１または非特許文献２参照）。

　また、車載ネットワークだけでなく、センサとアクチュエータとを含みシステムの制御を行う制御ネットワークにおいては、セキュリティの担保だけでなく、リアルタイム性または信頼性の担保も重要になり、サービスの特性によって重要な要素が異なるため、サービスに応じて適切なセキュリティポリシ、リアルタイム性などのＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）を設定できることが望ましい。

　このように、車両がネットワーク化し、ＥＣＵが複雑化することで、攻撃者がＥＣＵの脆弱性を悪用し、侵害するという、なりすまし攻撃の可能性がある。

　しかしながら、非特許文献１または非特許文献２の方法では、暗号通信を用いるため、送受信ノードによる暗号化または復号処理が必要となりオーバーヘッドが発生してしまう問題がある。

　そこで、本開示は、サービス提供に係る通信のアクセス制御を適切に行うサービス仲介方法を提供する。

　より具体的には、本開示は、車載ネットワークにおいてサービス指向型通信を行うＥＣＵの通信を仲介する仲介ＥＣＵによって、サービスポリシに基づいて、サービスに対するアクセス制御、または、障害発生時のサービス提供先の切り替えによる柔軟な仲介方法を提供する。

　本開示の一態様に係るサービス仲介装置は、サーバユニットからクライアントユニットへサービス指向型通信によってサービスを提供するサービス提供システムにおいて、サーバユニットおよびクライアントユニットそれぞれに接続され、前記サーバユニットまたは前記クライアントユニットから、前記サービスの提供に用いられるフレームを受信する通信制御部と、前記通信制御部が受信した前記フレームに含まれるサービスの識別子と、前記フレームの送信元または宛先を示す識別子と、前記フレームの種別との組合せが適切であるか否かの判定をし、前記判定の結果の出力をするサービス管理部とを備えるサービス仲介装置である。

　これにより、サービス仲介装置は、サービス指向型通信において、サーバユニットまたはクライアントユニットのなりすましによる不正な通信を検出することが可能となり、サーバユニットまたはクライアントユニットへの適切でないアクセスを未然に防ぐことができる。このように、サービス仲介装置は、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　例えば、前記通信制御部は、さらに、前記サービスの提供の前に、提供される前記サービスを示す第一サービス情報を含むサービス提供フレームを、前記サーバユニットから受信し、前記サービスの提供の前に、サービス探索フレームであって、サービス探索の対象を示す第二サービス情報を含むサービス探索フレームを、前記クライアントユニットから受信し、前記サービス管理部は、さらに、前記通信制御部が受信した前記サービス探索フレームに含まれる前記第二サービス情報と同一の前記第一サービス情報を含む前記サービス提供フレームを、受信した前記サービス探索フレームの送信元である前記クライアントユニットに、前記通信制御部により送信してもよい。

　上記態様によれば、サービス仲介装置は、サーバユニットとクライアントユニットとの間で、サービス提供フレームとサービス探索フレームとを適切に仲介する。これにより、サービス提供フレームとサービス探索フレームとが、当該サービスの提供または享受に無関係の装置に受信されることを未然に防止し、サーバユニットまたはクライアントユニットへのなりすましを適切に防止することができる。このように、サービス仲介装置は、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　例えば、前記サービス提供フレームは、前記サービス提供フレームに含まれる前記第一サービス情報が示すサービスを提供するサーバとしての権限を前記サーバユニットが有することを示す第一認証情報を含み、前記サービス探索フレームは、前記サービス探索フレームに含まれる前記第二サービス情報が示す前記サービスの提供を受けるクライアントとしての権限を前記クライアントユニットが有することを示す第二認証情報を含み、前記サービス管理部は、さらに、前記サービス提供フレームに含まれる前記第一認証情報の検証が成功した場合に、前記サービス提供フレームを有効と判定し、前記サービス探索フレームに含まれる前記第二認証情報の検証が成功した場合に、前記サービス探索フレームを有効と判定し、前記サービス提供フレームおよび前記サービス探索フレームを有効と判定した場合に、前記サービス提供フレームを前記クライアントユニットに、前記通信制御部により送信してもよい。

　上記態様によれば、サービス仲介装置は、サーバユニットがサービスを提供するサーバとしての権限を確かに有すること、および、クライアントユニットがサービスの提供を受けるクライアントとしての権限を確かに有することを認証情報を用いて判定したうえで、そのサーバユニットがそのクライアントユニットにサービスを提供するように制御する。これにより、サーバとしての権限を有しない装置がサービスを提供すること、および、クライアントとしての権限を有しない装置がサービスの提供を受けることを未然に防止することができる。よって、サービス仲介装置は、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　例えば、前記通信制御部は、前記サービスを提供する前記サーバユニットから、前記サービスの提供に用いられる第一フレームを受信した場合に、前記サービスの提供を受ける前記クライアントユニットに前記第一フレームを送信し、前記サービスの提供を受ける前記クライアントユニットから、前記サービスの提供に用いられる第二フレームを受信した場合に、前記サービスを提供する前記サーバユニットに前記第二フレームを送信してもよい。

　上記態様によれば、サービス仲介装置は、サーバユニットとクライアントユニットとの間で、サービスの提供に用いられるフレームを適切に仲介する。これにより、サービスの提供に用いられるフレームが、当該サービスの提供または享受に無関係の装置に受信されることを未然に防止し、サーバユニットまたはクライアントユニットへのなりすましを適切に防止することができる。このように、サービス仲介装置は、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　例えば、前記サービス仲介装置は、代理送信処理を実行する代理送信部を備え、前記代理送信処理は、前記第一フレームを前記通信制御部が受信した場合に、前記第一フレームに含まれる送信元を示す情報を、前記サービス仲介装置の識別子に変更してから、前記第一フレームを前記クライアントユニットに送信する処理、または、前記第二フレームを前記通信制御部が受信した場合に、前記第二フレームに含まれる送信元を示す情報を、前記サービス仲介装置の識別子に変更してから、前記第二フレームを前記サーバユニットに送信する処理を含んでもよい。

　上記態様によれば、サービス仲介装置は、サービスの提供に用いられるフレームを仲介する際に、そのフレームの送信元を自装置の識別子に変更する。そのため、サーバユニットがクライアントユニットの識別子を取得することなく、サービスを提供することができ、また、クライアントユニットがサーバユニットの識別子を取得することなく、サービスの提供を受けることができる。これにより、サーバユニットとクライアントユニットとの識別子が他の装置に取得される機会を、より一層低減することで、サーバユニットまたはクライアントユニットへのなりすましを適切に防止することができる。このように、サービス仲介装置は、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　例えば、前記サーバユニット、前記クライアントユニットおよび前記サービス仲介装置は、車両に搭載されており、前記サービス仲介装置は、さらに、前記車両の状態を示す状態情報を保持している車両状態保持部を備え、前記代理送信部は、前記車両状態保持部が保持している前記状態情報に応じて、前記代理送信処理を実行するか否かを制御してもよい。

　上記態様によれば、サービス仲介装置は、車両の状態に応じて代理送信を実行するか否かを制御する。サービスの提供に求められる信頼性およびリアルタイム性の要件は、そのサービスによって異なる。そのため、サービス仲介装置が車両の状態に応じて代理送信を実行するか否かを制御することにより、サービスの提供に求められる信頼性およびリアルタイム性に応じて代理送信を実行するか否かが制御されることになる。よって、サービス仲介装置は、サービスの提供に求められる信頼性およびリアルタイム性に応じた代理送信の制御を通じて、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　例えば、前記サーバユニットは、第一サーバユニットと第二サーバユニットとを含み、前記通信制御部は、前記第一サーバユニットから前記サービス提供フレームを受信した場合には、所定期間の待機状態をとり、前記待機状態において前記第二サーバユニットから前記サービス提供フレームを受信した場合には、受信した２つの前記サービス提供フレームのいずれかを前記クライアントユニットに送信してもよい。

　上記態様によれば、サービス仲介装置は、サービス提供システムにおいてサーバユニットを冗長化する。これにより、サービス仲介装置は、サービス提供システムが単一のサーバユニットを備える場合と互換性のある通信を維持しながら、堅牢性がより高いシステム構成の実現に寄与する。よって、サービス仲介装置は、システムの堅牢性を高めながら、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　例えば、前記通信制御部は、前記待機状態において前記第二サーバユニットから前記サービス提供フレームを受信しない場合には、前記第一サーバユニットから受信した前記サービス提供フレームを前記クライアントユニットに送信し、かつ、前記第二サーバユニットに異常が発生した場合に行う所定の処理を実行してもよい。

　上記態様によれば、サービス仲介装置は、冗長構成をとっているサーバユニットのうちの一方に異常が発生した場合に、他方のサーバユニットによるサービスの提供に寄与することで、サーバユニットの冗長構成を維持する。よって、サービス仲介装置は、システムの堅牢性を高めながら、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　例えば、前記通信制御部は、前記待機状態において前記第二サーバユニットから前記サービス提供フレームを受信しない場合には、前記第一サーバユニットから受信した前記サービス提供フレームを前記クライアントユニットに送信するか否かを、前記サービスの種別に応じて制御してもよい。

　上記態様によれば、サービス仲介装置は、冗長構成をとっているサーバユニットのうちの一方に異常が発生した場合における他方のサーバユニットによるサービスの提供を、サービスの種別に応じて制御する。サービスの提供に求められる信頼性およびリアルタイム性の要件は、そのサービスの種別によって異なるので、サービス仲介装置が上記制御を行うことで、サービスの提供に求められる信頼性およびリアルタイム性に応じて、上記他方のサーバユニットによるサービスの提供を制御することに寄与する。よって、サービス仲介装置は、サービスの提供に求められる信頼性およびリアルタイム性に応じて冗長構成におけるサービス提供を制御することを通じて、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　例えば、前記サーバユニット、前記クライアントユニットおよび前記サービス仲介装置は、車両に搭載されており、前記サービス仲介装置は、さらに、前記車両の状態を示す状態情報を保持している車両状態保持部を備え、前記通信制御部は、前記待機状態において前記第二サーバユニットから前記サービス提供フレームを受信しない場合には、前記第一サーバユニットから受信した前記サービス提供フレームを前記クライアントユニットに送信するか否かを、前記車両状態保持部が保持している前記状態情報に応じて制御してもよい。

　上記態様によれば、サービス仲介装置は、冗長構成をとっているサーバユニットのうちの一方に異常が発生した場合における他方のサーバユニットによるサービスの提供を、車両の状態に応じて制御する。サービスの提供に求められる信頼性およびリアルタイム性の要件は、車両の状態によって異なるので、サービス仲介装置が上記制御を行うことで、サービスの提供に求められる信頼性およびリアルタイム性に応じて、上記他方のサーバユニットによるサービスの提供を制御することに寄与する。よって、サービス仲介装置は、サービスの提供に求められる信頼性およびリアルタイム性に応じて冗長構成におけるサービス提供を制御することを通じて、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　例えば、前記サーバユニットは、第一サーバユニットと第二サーバユニットとを含み、前記通信制御部は、前記クライアントユニットから前記サービス探索フレームを受信した場合には、受信した前記サービス探索フレームを、前記第一サーバユニットおよび前記第二サーバユニットの両方に送信してもよい。

　上記態様によれば、サービス仲介装置は、サーバユニットが冗長構成をとっているときにサービス探索フレームを適切に仲介する。よって、サービス仲介装置は、システムの堅牢性を高めながら、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　例えば、前記サーバユニットは、複数のサーバユニットを含み、前記サービス管理部は、前記複数のサーバユニットが通信可能状態にあるか否かを示す通信状態情報を保持していて、保持している前記通信状態情報を前記クライアントユニットに送信してもよい。

　上記態様によれば、サービス仲介装置は、サービスを提供可能なサーバユニットを示す情報をクライアントユニットに適切に把握させる。これにより、サービス仲介装置は、車載ネットワークシステムのセキュリティと堅牢性を向上させながら、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　例えば、前記サービス管理部は、前記複数のサーバユニットのうちの一のサーバユニットが通信不可能状態であることを検出した場合に、前記通信状態情報を参照して、前記複数のサーバユニットのうち通信可能状態であるサーバユニットから受信した前記サービス提供フレームを前記クライアントユニットに送信してもよい。

　上記態様によれば、サービス仲介装置は、一のサーバユニットによるサービス提供の継続が困難な場合に、代替のサーバユニットの情報をクライアントユニットに把握させることができる。これにより、サービス仲介装置は、車載ネットワークシステムのセキュリティと堅牢性をより一層向上させながら、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　例えば、前記判定の結果の出力は、前記判定の結果を示す情報を表示画面に表示すること、または、前記判定の結果を示す情報をネットワークを介して外部装置に送信することを含んでもよい。

　上記態様によれば、サービス仲介装置は、判定の結果を示す情報を画面への表示、または、外部装置に送信することで、判定の結果を示す情報を、より容易に、出力することができる。よって、サービス仲介装置は、サービス提供に係る通信のアクセス制御を適切に行うことができる。

　なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。

　以下、実施の形態について、図面を参照しながら具体的に説明する。

　なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。

　（実施の形態）
　本実施の形態において、サービス提供に係る通信のアクセス制御を適切に行うサービス仲介装置について説明する。より具体的には、複数の電子制御ユニット（ＥＣＵ）がイーサネット（登録商標）を介したサービス指向型通信を行う車載ネットワークシステムにおける、サービス仲介方法について説明する。車載ネットワークシステムは、サービス提供システムの一例である。なお、サービス提供システムの別の例として、ロボット制御ネットワークシステム、または、モビリティ制御ネットワークシステムなどの制御ネットワークシステムがある。

　［１．１　車載ネットワークシステムの全体構成］
　図１は、本実施の形態における、車載ネットワークシステムの全体構成を示す図である。車載ネットワークシステムは、サーバＥＣＵ１００ａおよび１００ｂと、クライアントＥＣＵ１００ｃおよび１００ｄと、仲介ＥＣＵ２００とを備えて構成される。

　サーバＥＣＵ１００ａは、クライアントＥＣＵ１００ｃまたは１００ｄに対してサービスを提供する装置である。サーバＥＣＵ１００ｂは、サーバＥＣＵ１００ａと同様にサービスを提供する装置である。サーバＥＣＵ１００ａおよび１００ｂをサーバユニットともいう。

　クライアントＥＣＵ１００ｃは、サーバＥＣＵ１００ａまたは１００ｂによるサービスの提供を受ける装置である。クライアントＥＣＵ１００ｄは、クライアントＥＣＵ１００ｃと同様に、サービスの提供を受ける装置である。クライアントＥＣＵ１００ｃおよび１００ｄをクライアントユニットともいう。

　サービスは、例えば、センサ値等の情報を提供すること、または、要求に応じて所定の演算処理を行い、演算結果を出力すること、などを含む。

　仲介ＥＣＵ２００は、サーバＥＣＵ１００ａまたは１００ｂからクライアントＥＣＵ１００ｃまたは１００ｄへのサービスの提供を仲介する装置である。仲介ＥＣＵ２００は、サーバＥＣＵ１００ａおよび１００ｂ、ならびに、クライアントＥＣＵ１００ｃおよび１００ｄと、イーサネットによって通信可能に接続されている。

　サーバＥＣＵ１００ａおよび１００ｂと、クライアントＥＣＵ１００ｃおよび１００ｄとは、ＳＯＭＥ／ＩＰを用いて通信を行うことで、車両の機能の実現に寄与する。

　なお、本実施の形態では車両ネットワークシステムは、説明を簡略にするためサーバＥＣＵ１００ａおよび１００ｂと、クライアントＥＣＵ１００ｃおよび１００ｄと、仲介ＥＣＵ２００のみを備える構成としているが、他のＥＣＵまたはネットワークが存在していてもよい。

　［１．２　ＳＯＭＥ／ＩＰメッセージフォーマット］
　ＳＯＭＥ／ＩＰには、Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ、Ｆｉｒｅ／Ｆｏｒｇｅｔ、Ｅｖｅｎｔｓ、Ｇｅｔ／Ｓｅｔ／Ｎｏｔｉｆｉｅｒの４種類の通信方法が規定されている。サーバＥＣＵ１００ａおよび１００ｂ、ならびに、クライアントＥＣＵ１００ｃおよび１００ｄは、これらの通信方法を組み合わせることで、サービス指向型通信を実現する。ＳＯＭＥ／ＩＰでは、通信相手とセッションを確立する方法も準備されており、この方法は、Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙ（ＳＤ）とよばれる。

　図２は、本実施の形態における、ＳＯＭＥ／ＩＰ　ＳＤに用いられるメッセージのフォーマットを示す図である。

　図２のメッセージフォーマットは、イーサネットのペイロード部に格納される。図２において、１つの行は３２ビット長であり、前半はＳＯＭＥ／ＩＰヘッダ、後半がＳＯＭＥ／ＩＰ　ＳＤのペイロードである。

　ＳＯＭＥ／ＩＰヘッダは、Ｍｅｓｓａｇｅ　ＩＤ、Ｌｅｎｇｔｈ、Ｒｅｑｕｅｓｔ　ＩＤ、Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎ、Ｉｎｔｅｒｆａｃｅ　Ｖｅｒｓｉｏｎ、Ｍｅｓｓａｇｅ　Ｔｙｐｅ、および、Ｒｅｔｕｒｎ　Ｃｏｄｅのフィールドを含む。

　Ｍｅｓｓａｇｅ　ＩＤは、当該メッセージの識別子が格納される。Ｍｅｓｓａｇｅ　ＩＤは、ＳＯＭＥ／ＩＰ　ＳＤの場合は０ｘＦＦＦＦ８１００である。

　Ｌｅｎｇｔｈは、Ｌｅｎｇｔｈフィールドより後のデータのバイト数が格納される。

　Ｒｅｑｕｅｓｔ　ＩＤは、Ｃｌｉｅｎｔ　ＩＤとＳｅｓｓｉｏｎ　ＩＤをあわせた数値が格納される。

　Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙの場合は、Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎが０ｘ０１に、Ｉｎｔｅｒｆａｃｅ　Ｖｅｒｓｉｏｎが０ｘ０１に、Ｍｅｓｓａｇｅ　Ｔｙｐｅが０ｘ０２に、Ｒｅｔｕｒｎ　Ｃｏｄｅが０ｘ００に、それぞれ設定される。

　ＳＯＭＥ／ＩＰ　ＳＤのペイロードは、Ｆｌａｇｓ、Ｒｅｓｅｒｖｅｄ、Ｌｅｎｇｔｈ　ｏｆ　Ｅｎｔｒｉｅｓ　Ａｒｒａｙ　ｉｎ　Ｂｙｔｅｓ、Ｅｎｔｒｉｅｓ　Ａｒｒａｙ、Ｌｅｎｇｔｈ　ｏｆ　Ｏｐｔｉｏｎｓ　Ａｒｒａｙ　ｉｎ　Ｂｙｔｅｓ、および、Ｏｐｔｉｏｎｓ　Ａｒｒａｙのフィールドを含む。

　図３は、本実施の形態における、ＳＯＭＥ／ＩＰ　ＳＤのメッセージの一例を示す図である。図３のＳＯＭＥ／ＩＰ　ＳＤメッセージは、サービスＩＤが０ｘ１０００番のサービスを提供可能であることを示すメッセージの一例である。

　Ｆｌａｇｓには０ｘ８０が設定されており、Ｒｅｂｏｏｔ　Ｆｌａｇが設定されている。Ｒｅｓｅｒｖｅｄ領域は０に設定されている。

　Ｌｅｎｇｔｈ　ｏｆ　Ｅｎｔｒｉｅｓ　Ａｒｒａｙ　ｉｎ　Ｂｙｔｅｓには、Ｅｎｔｒｙのバイト数が格納されており、図３では１６バイトに設定されている。

　Ｔｙｐｅは、０ｘ００または０ｘ０１の設定が可能である。０ｘ００は、Ｆｉｎｄを意味し、０ｘ０１は、Ｏｆｆｅｒを意味する。Ｆｉｎｄは、サービスの提供を受けるクライアントＥＣＵが、必要なサービスの提供を要求するときに用いられる。Ｏｆｆｅｒは、サービスの提供を行うサーバＥＣＵが、自身の提供可能なサービスを通知する場合に用いられる。図３では、Ｔｙｐｅが０ｘ０１となっており、図３に示されるメッセージは、サーバＥＣＵが自身の提供可能なサービスに関する情報を通知しているメッセージである。

　Ｉｎｄｅｘ　１ｓｔ　ｏｐｔｉｏｎｓは、最初のオプションの位置を示している。図３では、Ｉｎｄｅｘ　１ｓｔ　ｏｐｔｉｏｎｓに０が設定されていて、つまり、最初のオプションがオプション領域の最初に配置されていることを示している。

　Ｉｎｄｅｘ　２ｎｄ　ｏｐｔｉｏｎｓは、２つ目のオプションの位置を示している。図３では、Ｉｎｄｅｘ　２ｎｄ　ｏｐｔｉｏｎｓに０が設定されている。なお、後述するように、図３に示されるメッセージではオプション２が用いられないので、Ｉｎｄｅｘ　２ｎｄ　ｏｐｔｉｏｎｓに設定されている値は用いられない。

　＃ｏｆ　ｏｐｔ１は、オプション１の個数を示している。図３では、＃ｏｆ　ｏｐｔ１に１が格納されている。

　＃ｏｆ　ｏｐｔ２は、オプション２の個数を示している。図３では、＃ｏｆ　ｏｐｔ２に０が格納されており、オプション２が用いられないことを示している。

　Ｓｅｒｖｉｃｅ　ＩＤは、サービスの種類を示すＩＤを示している。図３では、Ｓｅｒｖｉｃｅ　ＩＤに０ｘ１０００が格納されている。

　Ｉｎｓｔａｎｃｅ　ＩＤは、サービスのインスタンスを示すＩＤであり、図３では０ｘ０００１のインスタンスであることを示している。

　Ｍａｊｏｒ　Ｖｅｒｓｉｏｎは、サービスのバージョン管理に用いる情報であり、図３では０ｘ０１に設定されている。

　ＴＴＬは、サービスの有効期限を、秒を単位として設定するフィールドであり、図３では０ｘＦＦＦＦが設定されている。ＴＴＬに０ｘＦＦＦＦが設定されていることは、ＥＣＵの次の起動タイミングまでサービスが有効であることを意味する。

　Ｍｉｎｏｒ　Ｖｅｒｓｉｏｎは、サービスのバージョン管理に用いられる情報であり、図３では０ｘ０００００００２に設定されている。

　次に、Ｏｐｔｉｏｎの領域は、Ｌｅｎｇｔｈ　ｏｆ　Ｏｐｔｉｏｎｓ　Ａｒｒａｙ　ｉｎ　Ｂｙｔｅｓ、Ｌｅｎｇｔｈ、Ｔｙｐｅ、Ｒｅｓｅｒｖｅｄ、ＩＰｖ４アドレス、Ｒｅｓｅｒｖｅｄ、Ｌ４－Ｐｒｏｔｏ、および、Ｐｏｒｔ番号のフィールドを含む。

　Ｌｅｎｇｔｈ　ｏｆ　Ｏｐｔｉｏｎｓ　Ａｒｒａｙ　ｉｎ　Ｂｙｔｅｓは、Ｏｐｔｉｏｎ領域の長さを示している。図３では、Ｌｅｎｇｔｈ　ｏｆ　Ｏｐｔｉｏｎｓ　Ａｒｒａｙ　ｉｎ　Ｂｙｔｅｓは、１２バイトであることを示している。

　Ｌｅｎｇｔｈは、このオプション領域のバイト数を示している。Ｌｅｎｇｔｈは、オプションの種類に応じて設定される値が決まる。

　Ｔｙｐｅは、このオプション領域のタイプを示している。

　Ｒｅｓｅｒｖｅｄ領域は、０が格納される。

　図３では、ＩＰｖ４を用いた通信例を示しており、Ｌｅｎｇｔｈは９、Ｔｙｐｅは０ｘ０４、Ｒｅｓｅｒｖｅｄ領域は０ｘ００に設定される。

　ＩＰｖ４アドレスは、サーバのＩＰアドレスを示している。図３では、ＩＰｖ４アドレスは、１９２．１６８．０．１が設定されている。

　Ｒｅｓｅｒｖｅｄ領域は、０が格納される。

　Ｌ４－Ｐｒｏｔｏは、Ｌａｙｅｒ４つまりトランスポート層のプロトコルを示している。Ｌ４－Ｐｒｏｔｏは、０ｘ１１が格納されており、Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ（ＵＤＰ）を用いることを示している。

　ポート番号は、使用するトランスポート層のポート番号を示している。ポート番号は、図３では、３５０００番ポートであることを示している。

　［１．３　サーバＥＣＵ１００ａの構成］
　図４は、本実施の形態における、サーバＥＣＵ１００ａの構成を示す図である。サーバＥＣＵ１００ａは、例えばプロセッサ、メモリおよび通信インタフェース等を備えるコンピュータにより実現され、通信部１０１と、アプリ部１０２と、アプリ認証情報保持部１０３と、サービスポリシ保持部１０４とを備えて構成される。

　なお、サーバＥＣＵ１００ｂ、クライアントＥＣＵ１００ｃ、または、クライアントＥＣＵ１００ｄは、サーバＥＣＵ１００ａと同様の構成であるため、これらの説明を省略する。

　通信部１０１は、他のＥＣＵとの通信を行う通信インタフェースである。例えば、通信部１０１は、イーサネットの通信インタフェースであり、この場合、イーサネットを介して仲介ＥＣＵ２００に接続している。通信部１０１は、イーサネットからメッセージを受信し、アプリ部１０２へ通知する。また、通信部１０１は、アプリ部１０２からの要求に応じたメッセージをイーサネットへ送出する。

　アプリ部１０２は、サーバＥＣＵ１００ａのメインの機能を実現するアプリケーションを実行する。例えばサーバＥＣＵ１００ａまたはＥＣＵ１００ｂの場合は、アプリ部１０２は、サービス指向型通信のサービスの提供をするアプリケーションを含む。例えばクライアントＥＣＵ１００ｃまたはＥＣＵ１００ｄの場合は、アプリ部１０２は、サービスの提供を受けるアプリケーションを含む。

　またアプリ部１０２は、アプリ認証情報保持部１０３に格納されている情報を参照し、仲介ＥＣＵ２００に対して、自身のサービスへのアクセス権限を認証する情報を送信する。さらにアプリ部１０２は、サービスポリシ保持部１０４を参照して、サービスポリシを仲介ＥＣＵ２００へ通知する。

　アプリ認証情報保持部１０３は、アプリ部１０２が持つサービスに対するアクセス権限を証明するサービス権限証明書に関する情報を保持している。アプリ認証情報の詳細は後述する。

　サービスポリシ保持部１０４は、サービスに対するセキュリティポリシ、リアルタイム性または信頼性に関わるポリシを示した情報を保持している。サービスポリシの詳細は後述する。

　［１．４　仲介ＥＣＵ２００の構成］
　図５は、本実施の形態における、仲介ＥＣＵ２００の構成を示す図である。

　図５において仲介ＥＣＵ２００は、通信制御部２０１と、サービス管理部２０２と、代理送信部２０３と、異常監視部２０４と、サービス情報保持部２０５と、車両状態保持部２０６とを備えて構成される。

　通信制御部２０１は、他のＥＣＵとの通信を行う通信インタフェースである。通信制御部２０１は、例えば、４つのイーサネットポートをもち、それぞれのイーサネットポートがサーバＥＣＵ１００ａおよび１００ｂ、ならびに、クライアントＥＣＵ１００ｃおよび１００ｄと通信可能に接続されている。通信制御部２０１は、サーバＥＣＵ１００ａおよび１００ｂ、ならびに、クライアントＥＣＵ１００ｃおよび１００ｄとの間で、イーサネットのフレームを送信または受信する。

　また、通信制御部２０１は、ネットワークに流れるフレームに含まれるメッセージを受信し、サービス管理部２０２に通知するとともに、サービス管理部２０２からの送信要求を受けて、イーサネットにメッセージを含むフレームを送信する。通信制御部２０１は、受信したメッセージに含まれる宛先に応じて、適切なポートへとメッセージの転送を行うイーサネットスイッチの役割をもつ。

　通信制御部２０１は、サーバＥＣＵ１００ａおよび１００ｂが冗長構成をとっている場合には、サーバＥＣＵ１００ａからサービス提供フレームを受信したときには、所定期間の待機状態をとり、待機状態においてサーバＥＣＵ１００ｂからサービス提供フレームを受信した場合には、受信した２つのサービス提供フレームのいずれかをクライアントＥＣＵ１００ｃまたはＥＣＵ１００ｄに送信してもよい。

　また、サーバＥＣＵ１００ａおよび１００ｂが冗長構成をとっている場合には、クライアントＥＣＵ１００ｃまたはＥＣＵ１００ｄからサービス探索フレームを受信した場合には、受信したサービス探索フレームを、サーバＥＣＵ１００ａおよび１００ｂの両方に送信してもよい。

　なお、サーバＥＣＵ１００ａおよび１００ｂが冗長構成をとる場合、例えばサーバＥＣＵ１００ａが第一サーバユニットまたはメインサーバに相当し、サーバＥＣＵ１００ｂが第二サーバユニットまたはサブサーバに相当する。

　サービス管理部２０２は、受信したサービス指向型通信のメッセージに対して、サービス情報保持部２０５に格納されているサービスポリシ、および、車両状態保持部２０６に格納される車両状態に基づいて、サービスの仲介を実行する。サービスの仲介は、サーバＥＣＵとクライアントＥＣＵとの間で、サービス提供に係るフレームを中継（または転送）することで、サーバＥＣＵからクライアントＥＣＵへのサービス提供を成立させることをいう。

　サービス管理部２０２は、サービスの仲介において、通信制御部２０１が受信したフレームに含まれるサービスの識別子と、フレームの送信元または宛先を示す識別子と、フレームの種別との組合せが適切であるか否かの判定をし、判定の結果の出力をする。サービスの仲介に係る処理については後で詳しく説明する。

　サービスの仲介方法が、代理送信「有り」である場合は、サービス管理部２０２は、代理送信に対応するサービスに関するメッセージを代理送信部２０３に提供する。また、代理送信部２０３からの送信要求にしたがって、サービス管理部２０２は、通信制御部２０１にメッセージの送信を要求する。

　さらにサービス管理部２０２は、サービスの通信に異常が発生していないかを監視するためにメッセージを異常監視部２０４に通知する。

　サービス管理部２０２は、サーバＥＣＵ１００ａおよび１００ｂが通信可能状態にあるか否かを示す通信状態情報を保持していて、保持している通信状態情報をクライアントＥＣＵ１００ｃおよび１００ｄに送信してもよい。

　このとき、サービス管理部２０２は、サーバＥＣＵ１００ａおよび１００ｂのうちの一のサーバＥＣＵが通信不可能状態であることを検出した場合に、通信状態情報を参照して、通信可能状態であるサーバＥＣＵから受信したサービス提供フレームをクライアントＥＣＵ１００ｃおよび１００ｄに送信してもよい。

　また、サービス管理部２０２が行う判定の結果の出力は、判定の結果を示す情報を表示画面に表示すること、または、判定の結果を示す情報をネットワークを介して外部装置に送信することを含み得る。外部装置は、車載ネットワークシステムの外部の装置であり、車載ネットワークシステムにネットワークにより接続されている装置である。

　代理送信部２０３は、サーバＥＣＵ１００ａもしくはＥＣＵ１００ｂ、または、クライアントＥＣＵ１００ｃもしくはＥＣＵ１００ｄを代理して通信フレームを送信する処理である代理送信処理を実行する。

　代理送信部２０３は、サービスポリシの仲介方法が、代理送信「有り」である場合に、サーバＥＣＵ１００ａまたはＥＣＵ１００ｂに代わり、仲介ＥＣＵ２００がメッセージの送受信の主体となる。具体的には、代理送信部２０３は、サーバＥＣＵ１００ａまたはＥＣＵ１００ｂからサービスの提供情報を含むＯｆｆｅｒメッセージを受信した場合には、サーバＥＣＵ１００ａまたはＥＣＵ１００ｂの代理として仲介ＥＣＵ２００をサービスの提供者として、クライアントＥＣＵ１００ｃまたはＥＣＵ１００ｄにサービスの提供情報を含むＯｆｆｅｒを送信することで転送する。

　また、代理送信部２０３は、クライアントＥＣＵ１００ｃまたはＥＣＵ１００ｄからサービスの要求メッセージを受信した場合には、クライアントＥＣＵ１００ｃまたはＥＣＵ１００ｄの代理として仲介ＥＣＵ２００をサービスの享受者として、サーバＥＣＵ１００ａまたはＥＣＵ１００ｂに送信することで、転送する。

　さらに、代理送信部２０３は、サーバＥＣＵ１００ａまたはＥＣＵ１００ｂからの返信または通知メッセージを受信した場合には、サーバＥＣＵ１００ａまたはＥＣＵ１００ｂの代理として仲介ＥＣＵ２００が送信者となって、上記返信または通知メッセージをクライアントＥＣＵ１００ｃまたはＥＣＵ１００ｄに転送する。

　このようにサービスポリシの仲介方法が、代理送信「有り」である場合は、仲介ＥＣＵ２００は、サーバＥＣＵ１００ａまたはＥＣＵ１００ｂに対してはクライアントＥＣＵ１００ｃまたはＥＣＵ１００ｄとして振る舞い、クライアントＥＣＵ１００ｃまたはＥＣＵ１００ｄに対してはサーバＥＣＵ１００ａまたはＥＣＵ１００ｂとして振る舞うことで仲介を行う。

　代理送信部２０３は、サービスの信頼性向上のために、サーバＥＣＵ１００ａおよびＥＣＵ１００ｂが冗長構成をとっている場合は、サーバＥＣＵ１００ａまたはＥＣＵ１００ｂに対してクライアントＥＣＵ１００ｃまたはＥＣＵ１００ｄからのメッセージを転送する。代理送信部２０３は、サーバＥＣＵ１００ａまたはＥＣＵ１００ｂからのメッセージについては、メインサーバのメッセージを転送することがあるが、サブサーバのメッセージを転送してもよい。また、代理送信部２０３は、メインサーバとサブサーバの両方のメッセージの受信を待ってから、受信した両方のメッセージを比較して適切な内容のメッセージをクライアントＥＣＵ１００ｃまたはＥＣＵ１００ｄに転送することがある。サーバＥＣＵ１００ａまたはＥＣＵ１００ｂからのメッセージの転送は、サービスポリシに応じて決定される。

　代理送信部２０３は、車両状態保持部２０６が保持している状態情報に応じて、代理送信処理を実行するか否かを制御してもよい。

　異常監視部２０４は、サービス指向型通信に異常が発生していないかを確認する。具体例として、異常監視部２０４は、サーバＥＣＵ１００ａもしくはＥＣＵ１００ｂ、または、クライアントＥＣＵ１００ｃもしくはＥＣＵ１００ｄからの通信が所定期間途絶え、サーバＥＣＵ１００ａもしくはＥＣＵ１００ｂ、または、クライアントＥＣＵ１００ｃもしくはＥＣＵ１００ｄからサービスの提供または購読を停止するメッセージ、通信エラー、侵入検知システムによる異常アラート、サブサーバ起動時のメインサーバとサブサーバとの出力の不整合等を検出したか否かを判定する。異常監視部２０４は、これらの事象を検出したと判定した場合に、ＥＣＵ１００ａまたはＥＣＵ１００ｂに異常が発生していると判断し、サービス情報保持部２０５に格納されているサービスポリシ、および、車両状態保持部２０６に格納されている車両状態に基づいて、安全にサービスの提供を継続させるためにサブサーバへの切り替えを行うかを判断する。

　サービス情報保持部２０５は、各サービスに関するサーバＥＣＵ１００ａまたはＥＣＵ１００ｂ、および、クライアントＥＣＵ１００ｃまたはＥＣＵ１００ｄの情報と、サービスポリシとが格納されている。サービス情報の詳細は後述する。

　車両状態保持部２０６は、車両の状態を示す状態情報を保持している。車両状態保持部２０６は、状態情報の一例である、車両走行に関わる状態を保持することで、サービスの特性に応じて、安全にサービスを継続すべきか停止すべきかを判断するための情報を保持する。車両状態の詳細は後述する。

　［１．５　アプリ認証情報保持部に格納されるアプリ認証情報の一例］
　図６Ａは、アプリ認証情報保持部１０３に格納されているアプリ認証情報の第一例を示す図である。具体的には、図６Ａに示されるアプリ認証情報は、メインサーバであるサーバＥＣＵ１００ａのアプリ認証情報保持部１０３に格納されているアプリ認証情報である。

　図６Ａに示されるように、アプリ認証情報にはサービスに対するアクセス権限（言い換えれば、サービスを提供するサーバとしての権限）を持つことを示す秘密情報が保持されている。

　メインサーバ公開鍵は、メインサーバ秘密鍵で生成される署名を検証するための鍵であり、この鍵を用いてアプリ部１０２はサブサーバの公開鍵などに署名を生成し、仲介ＥＣＵ２００が生成した署名を検証することで、冗長構成をとるサブサーバの権限をメインサーバから付与することができる。

　セッション鍵は、仲介ＥＣＵ２００と共有することで、ペイロードの暗号化に用いる。

　サブサーバ公開鍵とサブサーバ秘密鍵とは、メインサーバが生成する、あるいは予め保持しているもので、サブサーバにメインサーバのもつサービスに対するアクセス権限を付与するために利用する。

　なお、サブサーバが当初よりサブサーバ公開鍵とサブサーバ秘密鍵とを保持している場合には、メインサーバであるサーバＥＣＵ１００ａのアプリ認証情報保持部１０３に、サブサーバ公開鍵とサブサーバ秘密鍵とが格納されている必要はない。

　サービス権限証明書は、アプリベンダまたは車両メーカ等によって作成され、サービスＩＤごとに、サービスに対するアクセス権限が記載されている。

　図６Ａにおいて、メインサーバ公開鍵は０ｘ１２３４５６７８９・・・であり、メインサーバ秘密鍵は０ｘａｂｃｄｅｆａｂｃｄｅｆ・・・であり、セッション鍵は０ｘａ７８７ｃ８９ｄｅ９８９・・・であり、サブサーバ公開鍵は０ｘ１ａ２ｂ３ｃ４ｄ５ｅ６ｆ・・・であり、サブサーバ秘密鍵は０ｘｆｅｄｃｂａ・・・である。サービス権限証明書には、サービスＩＤが１０のサービスに対するサーバ権限（「サーバとしての権限」ともいう）が記載されている。これは、サーバＥＣＵ１００ａが、上記サービスを提供するサーバとしての権限を有することがアプリベンダまたは車両メーカ等により証明されていることを示す記載であるとも言える。

　なお、本実施の形態では、アプリ認証情報が平文で保持されている場合を例として示しているが、アプリ認証情報が暗号化されて保持されていてもよい。また、アプリ認証情報がアプリ部１０２から直接読み出すことができないセキュアなメモリに格納されていてもよい。

　図６Ｂは、本実施の形態における、アプリ認証情報保持部１０３に格納されているアプリ認証情報の第二例を示す図である。具体的には、図６Ｂに示されるアプリ認証情報は、サブサーバであるサーバＥＣＵ１００ｂのアプリ認証情報保持部１０３に格納されているアプリ認証情報である。

　図６Ｂに示されるアプリ認証情報は、図６Ａに示されるアプリ認証情報のうち、メインサーバ公開鍵とメインサーバ秘密鍵とを除く情報を含んでいる。

　図６Ｂに示されるアプリ認証情報に含まれる各情報は、図６Ａに示されるアプリ認証情報に含まれるものと同様であるので、詳細な説明を省略する。

　なお、クライアントＥＣＵも、サーバＥＣＵが保持しているアプリ認証情報と同様のアプリ認証情報を保持している。

　図６Ｃは、本実施の形態における、アプリ認証情報の第三例を示す図である。具体的には、図６Ｃに示されるアプリ認証情報は、クライアントＥＣＵ１００ｃまたは１００ｄが保持しているアプリ認証情報である。

　図６Ｃに示されるように、アプリ認証情報にはサービスに対するアクセス権限（言い換えれば、サービスの提供を受けるクライアントとしての権限）を持つことを示す秘密情報が保持されている。

　図６Ｃに示されるアプリ認証情報に含まれる各情報は、図６Ａに示されるアプリ認証情報に含まれるものと同様であるが、メインサーバ公開鍵およびメインサーバ秘密鍵に代えて、それぞれ、クライアント公開鍵およびクライアント秘密鍵が含まれる点で異なる。また、サービス権限証明書には、サービスＩＤが１０のサービスに対するクライアント権限（「クライアントとしての権限」ともいう）が記載されている。これは、クライアントＥＣＵ１００ｃまたは１００ｄが、上記サービスの提供を受けるクライアントとしての権限を有することがアプリベンダまたは車両メーカ等により証明されていることを示す記載であるとも言える。

　［１．６　サービスポリシ保持部に格納されるサービスポリシの一例］
　図７は、サービスポリシ保持部１０４に格納されるサービスポリシの一例を示す図である。サービスポリシは、サービスＩＤごとに、サブサーバ候補の有無とアドレス、代理送信の有無、冗長構成をとるサブサーバへの異常発生時における切り替え方法、切り替え時の車両状態と切り替え方法とを示した切り替えポリシ、および、セキュリティポリシが格納されている。

　図７に示されるサービスＩＤが０ｘ１０であるサービスについて説明する。

　０ｘ１０のサービスＩＤについて、サブサーバの候補は「有り」であり、１９２．１６８．１．ＸＸのアドレスのＥＣＵがサブサーバの候補であることを示している。代理送信は「有り」であり、切り替え方法はホットスタンバイであり、つまりメインサーバが起動している際に、サブサーバも起動している場合に切り替えが可能であることを示している。また、切り替えポリシは「いつでも可」であり、車両の走行状態によらず、サービスを提供するサーバＥＣＵが切り替わることを許容している。セキュリティポリシとしては、ＳＤのメッセージの仲介と、監視とが設定されている。

　セキュリティポリシとしてのＳＤメッセージの仲介は、仲介ＥＣＵ２００により実施される。仲介ＥＣＵ２００は、通常時はブロードキャストで送信されるＯｆｆｅｒメッセージを終端し、適切なサーバＥＣＵおよびクライアントＥＣＵを検証することで、ネットワーク上に存在する攻撃者が、サービスＩＤの情報を不正に取得することを防止することができる。仲介ＥＣＵ２００は、サービスにアクセス可能なクライアントＥＣＵのみが、Ｆｉｎｄメッセージを仲介ＥＣＵ２００に送信し、認証されることで、適切なサーバＥＣＵの情報を取得できるようにアクセス制御を行う。

　仲介ＥＣＵ２００は、ＳＤメッセージの仲介の際に、Ｏｆｆｅｒメッセージのペイロードを、予め共有したセッション鍵により暗号化していてもよい。これによりネットワーク上のメッセージを不正に取得する攻撃者が存在したとしても、サービスＩＤに関わる情報の漏洩を防止できる。

　セキュリティポリシとしての監視は、当該サービスＩＤのメッセージに異常が発生していないかを監視することである。Ｅｔｈｅｒｎｅｔ（登録商標）では、ＣＡＮに比べて高速・大容量の通信が発生するため、監視対象を絞ることで、仲介ＥＣＵ２００の処理負荷を低減させつつ、安全性に影響のあるメッセージなどを効率的に監視することが可能になる。

　次に０ｘ２０のサービスＩＤについては、サブサーバの候補が「有り」（１９２．１６８．１．２０）であり、代理送信は「無し」であり、切り替え方法はａｎｙ（つまりホットスタンバイ、コールドスタンバイともに可能）であり、切り替えポリシについては、走行中の場合はホットスタンバイのみを許可している。また、セキュリティポリシについてはＳＤの仲介のみが設定されている。

　次に、０ｘ３０のサービスＩＤについては、サブサーバの候補が「有り」（１９２．１６８．１．ＸＸ）で、代理送信は「無し」であり、切り替え方法はコールドスタンバイであり、切り替えポリシは停車中のみサーバＥＣＵの切り替えを許可している。また、セキュリティポリシは、初回の登録時のみＳＤの仲介が設定されている。

　仲介ＥＣＵ２００は、初回の登録時のみＳＤの仲介が設定されていることにより初回登録時以外はＳＤの送信に仲介ＥＣＵ２００を介する必要がなくなる。そのため、上記設定がなされていると、サーバＥＣＵとクライアントＥＣＵとが、直接に、サービス検出のメッセージをやり取りすることが可能になり、通信のリアルタイム性が向上する。一方で、不正なＥＣＵによるなりすましの発生リスクが高まるため、セキュリティが求められないサービスまたはリアルタイム性が重要なサービスに適した設定となる。

　［１．７　サービス情報保持部に格納されるサービス情報の一例］
　図８Ａは、仲介ＥＣＵ２００のサービス情報保持部２０５に格納されるサービス情報の一例を示す図である。図８Ａに示すようにサービス情報は、サーバＥＣＵまたはクライアントＥＣＵから通知されるサービスポリシに含まれる情報に基づき設定される。サービス情報は、サービスＩＤごとにメインサーバのアドレスと状態、サブサーバのアドレスと状態、サービスについて発生している異常の有無、クライアントＥＣＵのアドレス、および、サーバＥＣＵから受信したサービスポリシ（代理送信の有無、切り替えポリシ、セキュリティポリシ）を含む。サービスポリシは、サーバＥＣＵ１００ａおよび１００ｂと仲介ＥＣＵ２００とで共有しており、その他の情報は、ネットワークの状態に応じて変化し得る。

　図８Ａでは、サービスＩＤが０ｘ１０であるサービスのメインサーバのアドレスは１９２．１６８．１．１０であり、メインサーバの状態はアクティブであり、サブサーバのアドレスは１９２．１６８．１．２０であり、サブサーバの状態はアクティブであり、異常発生は「無し」であり、クライアントＥＣＵは１９２．１６８．１．３０である。サービスポリシは図７と同様であるので説明および記載を省略している。

　次に、サービスＩＤが０ｘ２０であるサービスのメインサーバのアドレスは１９２．１６８．１．１０であり、メインサーバの状態はアクティブであり、サブサーバのアドレスは１９２．１６８．１．２０であり、サブサーバの状態は停止であり、異常発生は「無し」であり、クライアントＥＣＵは１９２．１６８．１．３１である。サービスポリシは記載が省略されている。

　サービスＩＤが０ｘ３０であるサービスのメインサーバのアドレスは１９２．１６８．１．１０であり、メインサーバの状態はアクティブであり、サブサーバのアドレスは１９２．１６８．１．２０であり、サブサーバの状態は停止であり、異常発生は「無し」であり、クライアントＥＣＵは特に該当なしである。認証を必要とせずにサービスの提供を受けられるため、仲介ＥＣＵ２００ではクライアントＥＣＵの管理を行っていないことを示している。サービスポリシは記載が省略されている。

　［１．８　アクセス制御情報の一例］
　図８Ｂは、仲介ＥＣＵ２００のサービス管理部２０２が有するアクセス制御情報の一例を示す図である。図８Ｂに示されるアクセス制御情報は、通信制御部２０１が受信したフレームを仲介することが適切であるか否かを、サービス管理部２０２が判定する際に用いられる情報である。図８Ｂに示されるアクセス制御情報は、一例として、仲介すべきであるフレームについての、サービスの識別子と、送信元または宛先を示す識別子と、種別との組合せを示す情報である。サービス管理部２０２は、アクセス制御情報に示される組合せのいずれかに該当するフレームの仲介を許可し、アクセス制御情報に示される組合せのいずれにも該当しないフレームの仲介を禁止する。

　図８Ｂに示されるアクセス制御情報は、サービスＩＤが０ｘ１０であるサービスについて、仲介すべきであるフレームについての、サービスの識別子と、送信元または宛先を示す識別子と、種別との組合せを示している。

　例えば、送信元アドレスが１９２．１６８．１．１０（つまりメインサーバのアドレス）であり、フレームの種別がＯｆｆｅｒメッセージであるフレームは、仲介すべきであることが示されている。送信元アドレスが１９２．１６８．１．２０（つまりサブサーバのアドレス）であり、フレームの種別がＯｆｆｅｒメッセージであるフレームは、仲介すべきであることが示されている。宛先アドレスが１９２．１６８．１．３０（つまりクライアントＥＣＵのアドレス）であり、フレームの種別がＯｆｆｅｒメッセージであるフレームは、仲介すべきであることが示されている。

　また、送信元アドレスが１９２．１６８．１．３０（つまりクライアントＥＣＵのアドレス）であり、フレームの種別がＦｉｎｄメッセージであるフレームは、仲介すべきであることが示されている。宛先アドレスが１９２．１６８．１．１０（つまりメインサーバのアドレス）であり、フレームの種別がＦｉｎｄメッセージであるフレームは、仲介すべきであることが示されている。宛先アドレスが１９２．１６８．１．２０（つまりサブサーバのアドレス）であり、フレームの種別がＦｉｎｄメッセージであるフレームは、仲介すべきであることが示されている。

　なお、図８Ｂに示されるアクセス制御情報において、「ａｎｙ」と記載されている欄は、どのようなアドレスであってもよいことを示している。

　なお、アクセス制御情報として、仲介すべきでないフレームについての、サービスの識別子と、送信元または宛先を示す識別子と、種別との組合せを示す情報を用いることもできる。その場合、サービス管理部２０２は、アクセス制御情報に示される組合せのいずれかに該当するフレームの仲介を禁止し、アクセス制御情報に示される組合せのいずれにも該当しないフレームの仲介を許可する。

　なお、ここでは、アクセス制御情報をテーブルの形式で示したが、アクセス制御情報は、テーブルの形式に限定されない。サービス管理部２０２が上記と同様の判定をすることができる根拠となる情報であれば、他の形式でもよく、例えば、アルゴリズムとして表現されてもよい。

　［１．９　車両状態保持部に格納される車両状態の一例］
　図９は、仲介ＥＣＵ２００の車両状態保持部２０６に格納される車両状態の一例を示す図である。図９に示されるように、車両状態には当該車載ネットワークを備えている車両の状態が格納されている。

　図９では車両状態が、走行中であることを示している。車両の走行状態は車載ネットワークを通じて他のＥＣＵから仲介ＥＣＵ２００に通知され得る。

　仲介ＥＣＵ２００が車両状態を把握することで、サービスの特性に応じてサービス指向型通信のメッセージを仲介すること、または、サブサーバへの切り替えタイミングを制御することが可能になる。

　なお、本実施の形態では、車両状態が走行中である例を示したが、車両状態はこれだけに限らない。車両状態は、例えば停止中、走行中、高速走行中など車両が走行しているかどうかの状態を含み得る。また、車両状態は、特定の機能が動作しているかの状態を付け加えてもよい。機能の例としては自動運転機能、クルーズコントロール、自動駐車機能、または、緊急自動ブレーキ等がある。また、車両が充電中または放電中であるなど、電力に関する状態が加わってもよい。

　例えば、車両状態が自動運転機能である場合は、特定のサービスのリアルタイム性（またはセキュリティ）の重要性が高まるため、仲介ＥＣＵ２００は、代理送信の有無を切り替えることで、リアルタイム性またはセキュリティを向上させることが可能となる。具体的には、仲介ＥＣＵ２００は、代理送信を「無し」とすることで、サーバＥＣＵとクライアントＥＣＵとが直接に通信を行うようにしてリアルタイム性を向上させることができる。また、仲介ＥＣＵ２００は、代理送信を「有り」とすることで、仲介ＥＣＵ２００がメッセージの検証を行うようにしてセキュリティを向上させることができる。

　また、サービスによっては継続的な動作が必要となる場合があり、メインサーバに異常が発生した場合でも、サブサーバをスタンバイさせておくことで、シームレスにサブサーバを切り替え、堅牢性を高めることができる。このようなサービスにおいて、安全性を重視するため、車両状態が停車時または特定の機能が停止している時のみに、仲介ＥＣＵ２００はサブサーバへの切り替えを行うようにしてもよい。

　［１．１０　仲介ＥＣＵのサービス情報登録シーケンス］
　図１０は、本実施の形態における、仲介ＥＣＵ２００のサービス情報登録シーケンスを示す図である。

　図１０は、仲介ＥＣＵ２００が、サーバＥＣＵ１００ａとクライアントＥＣＵ１００ｃとの通信を仲介することにより、サービス検出が行われるまでのシーケンスを示している。このときに仲介ＥＣＵ２００は、サービス情報の更新を行う。

　仲介ＥＣＵ２００は、具体的には、以下の処理を実行する。

　すなわち、通信制御部２０１は、サービスの提供の前に、提供されるサービスを示す第一サービス情報を含むＯｆｆｅｒメッセージを、サーバＥＣＵ１００ａから受信する。また、通信制御部２０１は、サービスの提供の前に、Ｆｉｎｄメッセージであって、サービス探索の対象を示す第二サービス情報を含むＦｉｎｄメッセージを、クライアントＥＣＵ１００ｃから受信する。サービス管理部２０２は、通信制御部２０１が受信したＦｉｎｄメッセージに含まれる第二サービス情報と同一の第一サービス情報を含むＯｆｆｅｒメッセージを、受信したＦｉｎｄメッセージの送信元であるクライアントＥＣＵ１００ｃに、通信制御部２０１により送信する。ここで、Ｏｆｆｅｒメッセージがサービス提供フレームに相当し、Ｆｉｎｄメッセージがサービス探索フレームに相当する。

　上記処理を以下で詳細に説明する。

　ステップＳ１０１において、サーバＥＣＵ１００ａは、自身が提供するサービスを示す情報を含むＯｆｆｅｒメッセージ（単に「Ｏｆｆｅｒ」とも表記する）を仲介ＥＣＵ２００に送信する。このとき、サーバＥＣＵ１００ａは、サービスに関するアクセス権限を示したサービス権限証明書（図６Ａ参照）と、サービスのポリシに関する情報とをＯｆｆｅｒメッセージに含めて送信する。

　ステップＳ１０２において、仲介ＥＣＵ２００は、ステップＳ１０１でサーバＥＣＵ１００ａが送信したＯｆｆｅｒメッセージを受信し、サービス権限証明書を検証し、サーバＥＣＵ１００ａが当該サービスに対するサーバの権限を持つことを確認する。仲介ＥＣＵ２００は、検証が成功した場合に、当該Ｏｆｆｅｒフレームを有効と判定する。

　ステップＳ１０３において、仲介ＥＣＵ２００は、ステップＳ１０１でサーバＥＣＵ１００ａが送信したＯｆｆｅｒメッセージに含まれるサーバＥＣＵ１００ａの情報（ＩＰアドレス、ポート番号等）とサービスポリシとに基づいてサービス情報を更新する。

　ステップＳ１０４において、クライアントＥＣＵ１００ｃは、提供を受けたいサービスの情報を含むＦｉｎｄメッセージ（単に「Ｆｉｎｄ」とも表記する）を仲介ＥＣＵ２００に送信する。このとき、クライアントＥＣＵ１００ｃは、サービスの提供を受けたいサービスのクライアント権限を持つことを示すサービス権限証明書（図６Ｃ参照）を、Ｆｉｎｄメッセージに含めて送信する。

　ステップＳ１０５において、仲介ＥＣＵ２００は、ステップＳ１０４でクライアントＥＣＵ１００ｃが送信したＦｉｎｄメッセージを受信し、サービス権限証明書を検証し、クライアントＥＣＵ１００ｃが当該サービスに対するクライアントの権限をもつことを確認する。仲介ＥＣＵ２００は、検証が成功した場合に、当該Ｆｉｎｄフレームを有効と判定する。

　ステップＳ１０６において、仲介ＥＣＵ２００は、サービス情報にクライアントの情報を追加する。

　ステップＳ１０７において、仲介ＥＣＵ２００は、ＯｆｆｅｒメッセージをクライアントＥＣＵ１００ｃに送信する。このとき、当該サービスの代理送信が「有り」である場合は、仲介ＥＣＵ２００は、仲介ＥＣＵ２００をサービス提供者として、ＯｆｆｅｒメッセージをクライアントＥＣＵ１００ｃに送信する。代理送信が「無し」である場合は、サーバＥＣＵ１００ａをサービス提供者として、ＯｆｆｅｒメッセージをクライアントＥＣＵ１００ｃに送信する。

　ステップＳ１０８において、クライアントＥＣＵ１００ｃは、ステップＳ１０７で仲介ＥＣＵ２００が送信したＯｆｆｅｒメッセージを受信し、受信したＯｆｆｅｒメッセージに基づいてサーバ情報を登録する。

　［１．１１　仲介ＥＣＵ２００によるＳＤ仲介のみの場合の通信シーケンス］
　図１１Ａは、本実施の形態における、ＳＤ仲介のみを行うサービスの通信シーケンスを示す図である。

　図１１Ａは、仲介ＥＣＵ２００が、セキュリティポリシにおいてＳＤ仲介のみと設定されており、代理送信が「無し」と設定されている場合の通信シーケンスの一例を示している。なお、図１１Ａに示されるシーケンスは図１０で示すＳＤ仲介が完了した後のシーケンスを示している。

　ステップＳ１０９において、クライアントＥＣＵ１００ｃは、登録したサーバ情報に基づいてサービスのＳｕｂｓｃｒｉｂｅメッセージをサーバＥＣＵ１００ａに送信する。送信されたＳｕｂｓｃｒｉｂｅメッセージは、仲介ＥＣＵ２００の通信制御部２０１の一のポートにより受信され別のポートから送信されることで、サーバＥＣＵ１００ａに転送される。このように、クライアントＥＣＵ１００ｃから仲介ＥＣＵ２００を経由してサーバＥＣＵ１００ａに送信されるメッセージは、仲介ＥＣＵ２００の通信制御部２０１のポートによる受信及び送信により転送される。以降でも同様とする。

　ステップＳ１１０において、サーバＥＣＵ１００ａは、ステップＳ１０９でクライアントＥＣＵ１００ｃが送信したＳｕｂｓｃｒｉｂｅを受信し、ＳｕｂｓｃｒｉｂｅＡｃｋメッセージをクライアントＥＣＵ１００ｃに返信する。送信されたＳｕｂｓｃｒｉｂｅＡｃｋメッセージは、仲介ＥＣＵ２００の通信制御部２０１の一のポートにより受信され別のポートから送信されることで、クライアントＥＣＵ１００ｃに転送される。このように、サーバＥＣＵ１００ａがクライアントＥＣＵ１００ｃに送信するメッセージは、仲介ＥＣＵ２００の通信制御部２０１のポートによる受信及び送信により転送される。以降でも同様とする。

　ステップＳ１１１において、サーバＥＣＵ１００ａは、クライアントＥＣＵ１００ｃにサービスを提供するＳＯＭＥ／ＩＰメッセージを送信する。

　ステップＳ１１２において、クライアントＥＣＵ１００ｃは、ステップＳ１１１でサーバＥＣＵ１００ａが送信したＳＯＭＥ／ＩＰメッセージを受信する。

　ステップＳ１１３において、サーバＥＣＵ１００ａは、ステップＳ１１２のＳＯＭＥ／ＩＰメッセージの受信から所定期間経過後にＳＯＭＥ／ＩＰメッセージを送信する。

　ステップＳ１１４において、クライアントＥＣＵ１００ｃは、ステップＳ１１３でサーバＥＣＵ１００ａが送信したメッセージを受信する。ステップＳ１１４の後、サーバＥＣＵ１００ａとクライアントＥＣＵ１００ｃとの通信が続く。

　［１．１２　仲介ＥＣＵ２００による代理送信を行う場合の通信シーケンス］
　図１１Ｂは、本実施の形態における、代理送信を行うサービスの通信シーケンスを示す図である。

　図１１Ｂは、仲介ＥＣＵ２００が代理送信「有り」と設定されている場合の通信シーケンスの一例を示している。なお、図１１Ｂに示されるシーケンスは図１０で示すＳＤ仲介が完了した後のシーケンスを示している。

　図１１Ｂにおいて、図１１Ａにおける処理と同じ処理については、同じ符号を付し、詳細な説明を省略する。

　ステップＳ１２１において、仲介ＥＣＵ２００の代理送信部２０３は、ステップＳ１０９でクライアントＥＣＵ１００ｃが送信したＳｕｂｓｃｒｉｂｅメッセージを受信し、受信したＳｕｂｓｃｒｉｂｅメッセージの送信元（つまりサービス享受者）を仲介ＥＣＵ２００のＩＰアドレスに変更し、変更後のＳｕｂｓｃｒｉｂｅメッセージをサーバＥＣＵ１００ａに送信する。なお、ステップＳ１２１において、サーバ側のＩＰアドレスが変更され、クライアント側のＩＰアドレスが変更されないようにしてもよい。また、ステップＳ１２１において、クライアント側のＩＰアドレスが変更され、サーバ側のＩＰアドレスが変更されないようにしてもよい。なお、ＩＰアドレスに代えて任意の識別子が用いられてもよい。以降でも同様である。

　ステップＳ１２２において、仲介ＥＣＵ２００の代理送信部２０３は、ステップＳ１１０でサーバＥＣＵ１００ａが送信したＳｕｂｓｃｒｉｂｅＡｃｋメッセージを受信し、受信したＳｕｂｓｃｒｉｂｅＡｃｋメッセージの送信元（つまりサービス提供者）を仲介ＥＣＵ２００のＩＰアドレスに変更し、変更後のＳｕｂｓｃｒｉｂｅＡｃｋメッセージをクライアントＥＣＵ１００ｃに送信する。

　ステップＳ１２３において、仲介ＥＣＵ２００の代理送信部２０３は、ステップＳ１１１でサーバＥＣＵ１００ａが送信したメッセージを受信し、受信したメッセージの送信元（つまりサービス提供者）を仲介ＥＣＵ２００に変更し、変更後のメッセージをクライアントＥＣＵ１００ｃに送信する。

　ステップＳ１２４において、仲介ＥＣＵ２００の代理送信部２０３は、ステップＳ１１３でサーバＥＣＵ１００ａが送信したメッセージを受信し、受信したメッセージの送信元（つまりサービス提供者）を仲介ＥＣＵ２００に変更し、変更後のメッセージをクライアントＥＣＵ１００ｃに送信する。

　［１．１３　サブサーバによるホットスタンバイ開始時の登録シーケンス］
　図１２は、本実施の形態における、仲介ＥＣＵ２００のサブサーバ登録シーケンスを示す図である。図１２は、サブサーバであるサーバＥＣＵ１００ｂがホットスタンバイを行う時のサブサーバ登録シーケンスを示している。

　なお、図１２に示される処理は、サーバＥＣＵ１００ａおよび１００ｂが冗長構成をとり始めるときの処理であるとも言える。

　ステップＳ２０１において、メインサーバであるサーバＥＣＵ１００ａは、サブサーバであるサーバＥＣＵ１００ｂに対して、サブサーバ起動メッセージを送信する。このときサーバＥＣＵ１００ａは、サービスに対するサブサーバの権限がメインサーバより与えられたことを示すサブサーバ証明書をサブサーバ起動メッセージに含める。

　ステップＳ２０２において、サーバＥＣＵ１００ｂは、ステップＳ２０１でサーバＥＣＵ１００ａが送信したサブサーバ起動メッセージを受信し、受信したサブ起動メッセージに対応するサービスを提供するアプリを起動する。

　ステップＳ２０３において、サブサーバであるサーバＥＣＵ１００ｂは、Ｏｆｆｅｒメッセージを仲介ＥＣＵ２００に送信する。このときサーバＥＣＵ１００ｂは、サブサーバの権限を持つことを示す認証情報をＯｆｆｅｒメッセージに含めて送信する。

　ステップＳ２０４において、仲介ＥＣＵ２００は、ステップＳ２０３でサーバＥＣＵ１００ｂが送信したＯｆｆｅｒを受信し、受信したＯｆｆｅｒメッセージに含まれるサービス情報と認証情報とを検証する。

　ステップＳ２０５において、仲介ＥＣＵ２００は、サービス情報のサブサーバの状態をアクティブに更新し、サブサーバのアドレスを登録する。

　［１．１４　代理送信有の時の通信シーケンス］
　図１３は、本実施の形態における、仲介ＥＣＵ２００による代理送信の通信シーケンスを示す図である。図１３は、仲介ＥＣＵ２００による代理送信が「有り」となっているサービスに関する通信シーケンスを示す。なお、図１３に示されるシーケンスは、図１０におけるサービス情報登録シーケンス、および、図１２のサブサーバの起動シーケンスが完了した後のシーケンスを示す。

　図１３において、サーバＥＣＵ１００ａおよび１００ｂは冗長構成をとっている。

　また、クライアントＥＣＵ１００ｃがＳｕｂｓｃｒｉｂｅメッセージを仲介ＥＣＵ２００に送信し、仲介ＥＣＵ２００がクライアントＥＣＵとしてＳｕｂｓｃｒｉｂｅメッセージをサーバＥＣＵに送信したことで、クライアントＥＣＵ１００ｃと仲介ＥＣＵ２００とのセッションと、サーバＥＣＵ１００ａおよびサーバＥＣＵ１００ｂと仲介ＥＣＵ２００とのセッションが確立しているものとする。

　ステップＳ２０６において、メインサーバであるサーバＥＣＵ１００ａは、サービスＩＤが１０であるメッセージを仲介ＥＣＵ２００へ送信する。仲介ＥＣＵ２００は、送信されたメッセージを受信し、所定期間の待機状態をとる。

　ステップＳ２０７において、サブサーバであるサーバＥＣＵ１００ｂは、上記と同様にサービスＩＤが１０のメッセージを仲介ＥＣＵ２００へ送信する。

　ステップＳ２０８において、仲介ＥＣＵ２００は、メインサーバであるサーバＥＣＵ１００ａからステップＳ２０６で受信したメッセージと、サブサーバであるサーバＥＣＵ１００ｂからステップＳ２０７で受信したメッセージとの比較を行う。仲介ＥＣＵ２００によるメッセージの比較は、例えばメッセージに含まれるペイロードが一致する、または、差異が所定の誤差の範囲内に収まっていること等の検証を行う。

　ステップＳ２０９において、仲介ＥＣＵ２００は、サーバＥＣＵとして、クライアントＥＣＵ１００ｃに対してサービスＩＤが１０であるメッセージを送信する。このときに送信されるメッセージは、メインサーバであるサーバＥＣＵ１００ａから受信したメッセージが転送されたものであってもよい。また、上記メッセージは、サブサーバであるサーバＥＣＵ１００ｂから受信したメッセージが転送されたものであってもよい。ただし、サーバＥＣＵ１００ａから受信したメッセージに不整合が発生している場合などは、仲介ＥＣＵ２００は、メッセージを破棄することがある。また、所定期間の間にメインサーバあるいはサブサーバのみからメッセージを受信した場合は、仲介ＥＣＵ２００は受信したメッセージに含まれるペイロードをそのまま転送する場合もあり得る。詳細は、図１４で説明する。

　ステップＳ２１０において、クライアントＥＣＵ１００ｃは、ステップＳ２０９で仲介ＥＣＵ２００が送信したメッセージを受信する。

　［１．１５　代理送信において異常発生時の通信シーケンス］
　図１４は、本実施の形態における、異常発生時の代理送信の通信シーケンスを示す図である。図１４は、仲介ＥＣＵ２００による代理送信が「有り」となっているサービスに関して、通信の異常が発生した場合の通信シーケンスを示している。なお、図１４に示されるシーケンスは、図１０におけるサービス情報登録シーケンス、および、図１２のサブサーバの起動シーケンスが完了した後のシーケンスを示す。

　また、クライアントＥＣＵ１００ｃがＳｕｂｓｃｒｉｂｅメッセージを仲介ＥＣＵ２００に送信し、仲介ＥＣＵ２００がクライアントＥＣＵとして、ＳｕｂｓｃｒｉｂｅメッセージをサーバＥＣＵに送信することで、クライアントＥＣＵ１００ｃと仲介ＥＣＵ２００とのセッション、および、サーバＥＣＵ１００ａおよびサーバＥＣＵ１００ｂと仲介ＥＣＵ２００とのセッションが、確立しているものとする。

　図１４において、サーバＥＣＵ１００ａおよび１００ｂは冗長構成をとっている。

　ステップＳ２１１において、サーバＥＣＵ１００ｂは、サービスＩＤが１０のメッセージを仲介ＥＣＵ２００に送信する。仲介ＥＣＵ２００は、送信されたメッセージを受信し、所定期間の待機状態をとる。

　ステップＳ２１２において、仲介ＥＣＵ２００は、メインサーバであるサーバＥＣＵ１００ａとの通信の途絶を検知する。仲介ＥＣＵ２００は、所定期間の待機状態において、メインサーバのサーバＥＣＵ１００ａからのメッセージを受信していないことを検知することで、メインサーバとの通信の途絶を検知する。

　ステップＳ２１３において、仲介ＥＣＵ２００は、サブサーバであるサーバＥＣＵ１００ｂのメッセージに基づいて、サービスＩＤが１０のメッセージをクライアントＥＣＵ１００ｃに送信する。

　なお、仲介ＥＣＵ２００は、上記メッセージを送信するか否かを、サービスの種別に応じて制御してもよい。また、仲介ＥＣＵ２００は、上記メッセージを送信するか否かを、車両の状態を示す状態情報に応じて制御してもよい。

　ステップＳ２１４において、仲介ＥＣＵ２００は、サービス情報を異常発生「有り」に更新し、また、メインサーバの状態を「停止」に更新する。また、仲介ＥＣＵ２００は、サブサーバに異常が発生した場合に行う所定の処理を実行してもよい。上記更新処理が、上記所定の処理に含まれていてもよい。

　ステップＳ２１５において、クライアントＥＣＵ１００ｃは、メッセージを受信する。

　［１．１６　異常発生時のサブサーバへの切り替えシーケンス］
　図１５は、本実施の形態における、異常発生時のサブサーバへの切り替えシーケンスを示す図である。図１５は、仲介ＥＣＵ２００が、サーバＥＣＵ１００ａの異常を検出し、サブサーバへ切り替えることで、サービスの提供を継続する時のシーケンスを示している。なお、図１５に示されるシーケンスは、図１０で示すＳＤ仲介が完了した後のシーケンスを示す。また車両状態は「停車中」であるとする。

　図１５において、サーバＥＣＵ１００ａおよび１００ｂは冗長構成をとっている。

　ステップＳ３０１において、サーバＥＣＵ１００ａは、何らかの原因によりサービスの提供を停止するとき、ＳｔｏｐＯｆｆｅｒメッセージ（単に「ＳｔｏｐＯｆｆｅｒ」とも表記する）をブロードキャストすることでクライアントＥＣＵ１００ｃに受信させる。

　ステップＳ３０２において、クライアントＥＣＵ１００ｃは、ステップＳ３０１でＳｔｏｐＯｆｆｅｒを受信したことに応じて、サービスの提供を受けるのを停止する。

　ステップＳ３０３において、仲介ＥＣＵ２００は、ＳｔｏｐＯｆｆｅｒメッセージを受信したことに基づいて、メインサーバであるサーバＥＣＵ１００ａに異常が発生していることを検出する。

　ステップＳ３０４において、仲介ＥＣＵ２００は、サーバの切り替えを実施するために、現在の車両状態を取得する。

　ステップＳ３０５において、仲介ＥＣＵ２００は、車両状態が「停車中」である場合、サーバの切り替えが可能と判断し、サービス情報に基づきサブサーバを起動させるメッセージである起動メッセージをサーバＥＣＵ１００ｂに送信する。また、仲介ＥＣＵ２００は、車両状態が「走行中」である場合は、サーバの切替が不可と判断し、処理を終了する。

　ステップＳ３０６において、サーバＥＣＵ１００ｂは、仲介ＥＣＵ２００が送信した起動メッセージを受信したことに応じて、サービスＩＤが３０であるサービスを提供するためのアプリを起動する。

　ステップＳ３０７において、サーバＥＣＵ１００ｂは、Ｏｆｆｅｒメッセージをブロードキャストすることで、クライアントＥＣＵ１００ｃにサーバ情報を通知する。

　ステップＳ３０８において、クライアントＥＣＵ１００ｃは、ステップＳ３０７でＯｆｆｅｒメッセージを受信したことに応じて、サーバ情報をサブサーバであるサーバＥＣＵ１００ｂに更新する。これにより、クライアントＥＣＵ１００ｃは、ステップＳ３０１で停止されたサービスＩＤ３０のサービスの提供を再度受けることが可能になる。

　［１．１７　仲介ＥＣＵのＳＤ処理フローチャート］
　図１６は、仲介ＥＣＵ２００によるＳＤメッセージに対する処理を示すフローチャートである。

　ステップＳ４００において、仲介ＥＣＵ２００は、サーバＥＣＵ１００ａもしくは１００ｂ、または、クライアントＥＣＵ１００ｃもしくは１００ｄからメッセージを受信する。

　ステップＳ４０１において、仲介ＥＣＵ２００は、ステップＳ４００で受信したメッセージがサービスのＯｆｆｅｒメッセージであるか否かを判定する。Ｏｆｆｅｒメッセージであると判定した場合は、仲介ＥＣＵ２００はステップＳ４０２を実行し、Ｏｆｆｅｒメッセージでないと判定した場合は、仲介ＥＣＵ２００はステップＳ４１０を実行する。

　ステップＳ４０２において、仲介ＥＣＵ２００は、ステップＳ４００で受信したＯｆｆｅｒメッセージに関連するサービス情報が、自身の保持するサービス情報保持部２０５にすでに登録されているサービスであるかを判断する。登録済みのサービスである場合は、仲介ＥＣＵ２００はステップＳ４０３を実行する。そうでない場合は、仲介ＥＣＵ２００は、ステップＳ４０７を実行する。

　ステップＳ４０３において、仲介ＥＣＵ２００は、ステップＳ４００で受信したＯｆｆｅｒメッセージに関するサービスが既にサービス情報保持部２０５に登録されている場合は、サービス情報保持部２０５に保持されている対応するサービスについてＳＤの仲介の有無を確認する。ＳＤ仲介が「有り」である場合は、仲介ＥＣＵ２００はステップＳ４０５を実行する。そうでない場合は、仲介ＥＣＵ２００はステップＳ４０４を実行する。

　ステップＳ４０４において、仲介ＥＣＵ２００は、ステップＳ４００で受信したＯｆｆｅｒメッセージを、ヘッダ情報に従って転送する。

　ステップＳ４０５において、仲介ＥＣＵ２００は、ステップＳ４００で受信したＯｆｆｅｒメッセージに含まれる情報がサービス情報保持部２０５に格納されているサービス情報と整合するか否かを判定する。具体的には、仲介ＥＣＵ２００は、Ｏｆｆｅｒメッセージに含まれるサービスＩＤと、サービス情報に含まれるサーバのサービスＩＤが整合しているか否かを判定する。

　Ｏｆｆｅｒメッセージに含まれる情報がサービス情報と整合すると判定した場合は、仲介ＥＣＵ２００は、ステップＳ４０６を実行し、そうでない場合は、ステップＳ４０８を実行する。

　ステップＳ４０６において、仲介ＥＣＵ２００は、ステップＳ４００で受信したＯｆｆｅｒメッセージに含まれる情報に基づいてサービス情報を更新し、処理を終了する。

　ステップＳ４０７において、仲介ＥＣＵ２００は、ステップＳ４００で受信したＯｆｆｅｒメッセージに含まれる認証情報を検証し、検証が成功するか否かを判定する。認証情報の検証に成功した場合は、仲介ＥＣＵ２００は、ステップＳ４０９を実行し、そうでない場合は、ステップＳ４０８を実行する。

　ステップＳ４０８において、仲介ＥＣＵ２００は、ステップＳ４００で受信したＯｆｆｅｒメッセージを破棄する。

　ステップＳ４０９において、仲介ＥＣＵ２００は、ステップＳ４００で受信したＯｆｆｅｒメッセージに含まれるサービスポリシに基づいて、サービス情報保持部２０５に格納されるサービス情報を更新し、処理を終了する。

　ステップＳ４１０において、仲介ＥＣＵ２００は、ステップＳ４００で受信したメッセージがＦｉｎｄメッセージであるか否を判定する。Ｆｉｎｄメッセージであると判定した場合は、仲介ＥＣＵ２００は、ステップＳ４１１を実行し、そうでない場合は、処理を終了する。

　ステップＳ４１１において、仲介ＥＣＵ２００は、サービス情報保持部２０５に、ステップＳ４００で受信したＦｉｎｄメッセージの送信元であるクライアントＥＣＵの情報が登録されているか否かを判定する。クライアントＥＣＵの情報が登録されていると判定した場合は、仲介ＥＣＵ２００は、ステップＳ４１２を実行し、そうでない場合には、ステップＳ４１３を実行する。

　ステップＳ４１２において、仲介ＥＣＵ２００は、サービス情報に基づきサーバ情報を含むＯｆｆｅｒメッセージをクライアントＥＣＵに対して送信し、終了する。

　ステップＳ４１３において、仲介ＥＣＵ２００は、ステップＳ４００で受信したＦｉｎｄメッセージに含まれる認証情報を検証し、検証が成功するか否かを判定する。認証情報の検証に成功した場合は、仲介ＥＣＵ２００は、ステップＳ４１４を実行し、そうでない場合は、ステップＳ４１５を実行する。

　ステップＳ４１４において、仲介ＥＣＵ２００は、サービス情報保持部２０５に格納されるサービス情報に、クライアント情報を登録し、ステップＳ４１２を実行する。

　ステップＳ４１５において、仲介ＥＣＵ２００は、ステップＳ４００で受信したＦｉｎｄメッセージを破棄する。

　なお、本実施の形態では、サービス情報の整合の判定が成功した場合にサーバ情報を更新している（ステップＳ４０６）が、サービス情報の整合の判定（ステップＳ４０５）の代わりに認証情報の検証（ステップＳ４０７）を実施し、検証に成功した場合にサーバ情報を更新してもよい。

　［１．１８　仲介ＥＣＵのメッセージ送信処理フローチャート］
　図１７は、本実施の形態における、仲介ＥＣＵ２００によるＳＯＭＥ／ＩＰメッセージ（より具体的には、ＳＤメッセージ以外のＳＯＭＥ／ＩＰメッセージ）に対する処理を示すフローチャートである。

　ステップＳ５０１において、仲介ＥＣＵ２００は、ＳＤメッセージ以外のＳＯＭＥ／ＩＰメッセージを受信する。

　ステップＳ５０２において、仲介ＥＣＵ２００は、ステップＳ５０１で受信したメッセージに対応するサービスが監視対象であるか否かを判定する。監視対象であると判定した場合は、仲介ＥＣＵ２００は、ステップＳ５０３を実行し、そうでない場合は、仲介ＥＣＵ２００は、ステップＳ５０５を実行する。

　ステップＳ５０３において、仲介ＥＣＵ２００は、ステップＳ５０１で受信したメッセージがサービス情報保持部２０５に格納されているサービス情報に合致するか否かを判定する。具体的には、仲介ＥＣＵ２００は、ステップＳ５０１で受信したメッセージが、サーバから送信されるメッセージ（Ｎｏｔｉｆｉｃａｔｉｏｎ、または、Ｒｅｓｐｏｎｓｅ）であれば、そのメッセージの送信元が、登録されたサーバ情報と合致し、かつ、そのメッセージの宛先が、登録されたクライアント情報と合致するか否かを判定する。仲介ＥＣＵ２００は、ステップＳ５０１で受信したメッセージが、クライアントから送信されるメッセージ（Ｒｅｑｕｅｓｔ、または、Ｒｅｑｕｅｓｔ　ｎｏ　Ｒｅｓｐｏｎｓｅ）であれば、そのメッセージの送信元が、登録されたクライアント情報に合致し、かつ、そのメッセージの宛先が、登録されたサーバの情報と合致するか否かを判定する。メッセージがサービス情報に合致すると判定した場合は、仲介ＥＣＵ２００は、ステップＳ５０４を実行し、サービス情報に合致しない場合は、ステップＳ５０６を実行する。

　ステップＳ５０４において、仲介ＥＣＵ２００は、対象のサービスの代理送信の有無を、サービス情報保持部２０５に格納されるサービス情報を参照することで取得する。代理送信が「無し」である場合は、仲介ＥＣＵ２００は、ステップＳ５０５を実行する。代理送信が「有り」である場合は、仲介ＥＣＵ２００は、ステップＳ５０７を実行する。

　ステップＳ５０５において、仲介ＥＣＵ２００は、受信したメッセージを転送する。

　ステップＳ５０６において、仲介ＥＣＵ２００は、受信したメッセージを破棄する。

　ステップＳ５０７において、仲介ＥＣＵ２００は、受信したメッセージのサービスが代理送信「有り」である場合、受信したメッセージの種類がＲｅｑｕｅｓｔであるか否かを判定する。受信したメッセージの種類がＲｅｑｕｅｓｔである場合は、仲介ＥＣＵ２００は、ステップＳ５０８を実行する。受信したメッセージの種類がＲｅｑｕｅｓｔでない場合は、仲介ＥＣＵ２００は、ステップＳ５０９を実行する。

　ステップＳ５０８において、仲介ＥＣＵ２００は、サービス情報保持部２０５に格納されるサービス情報を参照し、アクティブなサーバに対して、受信したＲｅｑｕｅｓｔメッセージを転送し、処理を終了する。このとき、仲介ＥＣＵ２００は、Ｒｅｑｕｅｓｔメッセージに含まれる送信元を、仲介ＥＣＵ２００に書き換えて、Ｒｅｑｕｅｓｔメッセージを転送する。

　ステップＳ５０９において、仲介ＥＣＵ２００は、ステップＳ５０１で受信したメッセージがサーバから送信されたものであるとして、対象のサービスについて他にアクティブなサーバが存在するか否かを判定する。このとき、仲介ＥＣＵ２００は、サービス情報保持部２０５に格納されるサービス情報を参照することで上記判定をする。他にアクティブなサーバが存在しないと判定した場合は、仲介ＥＣＵ２００は、ステップＳ５１１を実行する。アクティブなサーバが存在する場合は、仲介ＥＣＵ２００は、ステップＳ５１０を実行する。

　ステップＳ５１０において、仲介ＥＣＵ２００は、他のアクティブなサーバからメッセージを既に受信しているか否かを判定する。メッセージの受信確認は、例えば、あらかじめサーバからの受信メッセージを所定期間保持しておくようにしておき、保持しているメッセージ内に、該当するサーバからのメッセージが存在するか否かを判定することで行う。他のアクティブなサーバＥＣＵからメッセージを受信した場合は、仲介ＥＣＵ２００は、ステップＳ５１１を実行し、そうでない場合は、ステップＳ５１３を実行する。

　ステップＳ５１１において、仲介ＥＣＵ２００は、メッセージの選択を行う。メッセージの選択方法は、例えば、メインサーバのメッセージをより優先的に選択する方法、より最近に受信したメッセージをより優先的に選択する方法、および、複数のメッセージの比較を行い、中間値に該当するものまたは中間値に近いものをより優先的に選択する方法などが考えられる。

　ステップＳ５１２において、仲介ＥＣＵ２００は、メッセージを代理送信する。

　ステップＳ５１３において、仲介ＥＣＵ２００は、所定期間待ち、他のアクティブなサーバＥＣＵからメッセージを受信するか否かを判定する。

　ステップＳ５１４において、仲介ＥＣＵ２００は、サーバに異常が発生したとして、サービス情報保持部２０５に保持されているサーバ情報のうち、アクティブになっており、かつメッセージの受信がなかったサーバについて、サーバ情報を停止に更新する。

　［１．１９　メインサーバの通信異常検知時の切り替えフローチャート］
　図１８は、本実施の形態における、メインサーバの通信異常が検知されたときのサーバ切り替え処理を示すフローチャートである。

　ステップＳ６０１において、仲介ＥＣＵ２００は、メインサーバの通信異常を検知し、サービス情報保持部２０５に格納されているサービス情報のうちメインサーバの情報、および、異常検知情報を更新する。メインサーバの通信異常は、例えばメインサーバからのエラーメッセージの通知、ＳｔｏｐＯｆｆｅｒメッセージの通知、または、所定期間の通信途絶等により検知され得る。

　ステップＳ６０２において、仲介ＥＣＵ２００は、サービス情報保持部２０５に格納されているサービス情報を参照し、サブサーバがアクティブであるか否かを判定する。サブサーバがアクティブであると判定した場合は、仲介ＥＣＵ２００は、ステップＳ６０３を実行する。そうでない場合は、仲介ＥＣＵ２００は、ステップＳ６０６を実行する。

　ステップＳ６０３において、仲介ＥＣＵ２００は、車両状態保持部２０６に格納されている車両状態と、サービス情報のうちのサービスポリシとを参照し、車両状態が切り替えポリシ（ホットスタンバイ）に合致しているか否かを判定する。車両状態が切り替えポリシに合致したと判定した場合は、仲介ＥＣＵ２００は、ステップＳ６０４を実行する。そうでない場合は、仲介ＥＣＵ２００は、何もせずに処理を終了する。

　ステップＳ６０４において、仲介ＥＣＵ２００は、対象サービスの代理送信の有無を取得する。対象サービスが代理送信「有り」である場合は、仲介ＥＣＵ２００は、何もせずに、終了する、すなわち、サブサーバによりサービスを継続する。対象サービスが代理送信「無し」である場合は、仲介ＥＣＵ２００は、ステップＳ６０５を実行する。

　ステップＳ６０５において、仲介ＥＣＵ２００は、クライアントＥＣＵに対して、サービスの提供元としてサブサーバの情報を含めたＯｆｆｅｒメッセージを送信することで、サーバＥＣＵの切り替えを通知し、処理を終了する。

　ステップＳ６０６において、仲介ＥＣＵ２００は、車両状態が切り替えポリシ（コールドスタンバイ）に合致するか否かを確認する。車両状態が切り替えポリシ（コールドスタンバイ）に合致した場合は、仲介ＥＣＵ２００は、ステップＳ６０７を実行する。そうでない場合は、仲介ＥＣＵ２００は、処理を終了する。

　ステップＳ６０７において、仲介ＥＣＵ２００は、サブサーバの起動を行う。サブサーバの起動は、例えば当該サービスを提供するアプリケーションの起動を、サブサーバへ要求するメッセージを送信することによって行う。

　ステップＳ６０８において、仲介ＥＣＵ２００は、サブサーバ起動後に送信されるＯｆｆｅｒメッセージに基づいて認証情報を検証し、サーバ情報を取得することで、サービス情報保持部２０５のサービス情報を更新する。

　ステップＳ６０９において、仲介ＥＣＵ２００は、クライアントＥＣＵに対して、サービスの提供元としてサブサーバの情報を含めたＯｆｆｅｒメッセージを送信する。

　［１．２０　実施の形態の効果］
　実施の形態に係る車載ネットワークシステムでは、仲介ＥＣＵ２００がＳＯＭＥ／ＩＰ　ＳＤ通信に関して、認証情報を検証することで、正規のサーバまたはクライアントであるかを認証する。これにより、不正なＥＣＵによるサービスへのアクセス権を管理することが可能になり不正なＥＣＵによるなりすましを防止し、セキュリティが高まる。

　さらに、仲介ＥＣＵ２００は、サービスポリシに応じて、サービス指向型通信の仲介方法を変更する。これにより、高いセキュリティが要求されるメッセージについては、仲介ＥＣＵ２００による監視および代理送信を行うことで、当該サービスに関するメッセージを監視しつつ、サーバの情報を秘匿することが可能になる。また、高いリアルタイム性が要求されるメッセージについては、サービスの検出時のみ仲介を行うことで、セキュリティを高めつつ、リアルタイム性を維持することが可能となる。

　さらに、仲介ＥＣＵ２００は、サービスポリシおよび車両状態に応じて、サービスの提供元に異常が発生した場合にサブのサーバへ切り替える方法を選択する。これによりサービスの種類によって、サービスが車両走行に与える影響を考慮しつつ、サービスの堅牢性を高めることが可能になる。

　（実施の形態の変形例）
　本実施の形態において、サービス提供に係る通信のアクセス制御を適切に行うサービス仲介装置の別の形態について説明する。

　図１９Ａは、本変形例におけるサービス仲介装置３００の構成を示す図である。サービス仲介装置３００は、上記実施の形態の仲介ＥＣＵ２００に相当する。

　図１９Ａに示されるように、サービス仲介装置３００は、通信制御部３０１と、サービス管理部３０２とを備える。

　通信制御部３０１は、サーバユニットからクライアントユニットへサービス指向型通信によってサービスを提供するサービス提供システムにおいて、サーバユニットおよびクライアントユニットそれぞれに接続され、サーバユニットまたはクライアントユニットから、サービスの提供に用いられるフレームを受信する。通信制御部３０１は、上記実施の形態の通信制御部２０１に相当する。

　サービス管理部３０２は、通信制御部３０１が受信したフレームに含まれるサービスの識別子と、フレームの送信元または宛先を示す識別子と、フレームの種別との組合せが適切であるか否かの判定をし、判定の結果の出力をする。サービス管理部３０２は、上記実施の形態のサービス管理部２０２に相当する。

　なお、サービス仲介装置３００は、上記実施の形態の仲介ＥＣＵ２００が備える代理送信部２０３に相当する代理送信部３０３を備えてもよい。

　また、サービス仲介装置３００は、上記実施の形態の仲介ＥＣＵ２００が備える車両状態保持部２０６に相当する車両状態保持部３０４を備えてもよい。

　図１９Ｂは、本変形例におけるサービス仲介装置３００の処理を示すフロー図である。

　ステップＳ１において、通信制御部３０１は、サーバユニットまたはクライアントユニットから、サービスの提供に用いられるフレームを受信する。

　ステップＳ２において、サービス管理部３０２は、通信制御部３０１がステップＳ１で受信したフレームに含まれるサービスの識別子と、フレームの送信元または宛先を示す識別子と、フレームの種別との組合せが適切であるか否かの判定をする。

　ステップＳ３において、サービス管理部３０２は、ステップＳ２における判定の結果を出力する。

　以上の一連の処理により、サービス仲介装置３００は、サービス提供に係る通信のアクセス制御を適切に行う。

　（その他の変形例）
　なお、本開示を上記実施の形態に基づいて説明してきたが、本開示は、上記実施の形態に限定されないのはもちろんである。以下のような場合も本開示に含まれる。

　（１）上記の実施の形態では、ＳＯＭＥ／ＩＰ通信の例として処理動作を説明したが、これに限定されることなく、その他のサービス指向型通信、または、Ｐｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ型通信であってもよい。例えばＤａｔａ　Ｄｉｓｔｉｒｉｂｕｔｉｏｎ　Ｓｅｒｖｉｃｅ（ＤＤＳ）通信であってもよい。

　（２）上記の実施の形態では、ＳＤメッセージの処理においてＯｆｆｅｒとＦｉｎｄとの処理例を図１６に示したが、別のＳＤメッセージの種類を処理してもよい。例えば、Ｓｕｂｓｃｒｉｂｅについても同様に、クライアント情報の確認を行ってもよい。これによりメッセージの監視の対象範囲が広まりセキュリティ向上が期待できる。

　（３）上記の実施の形態では、車載ネットワークシステムとして、サーバＥＣＵとクライアントＥＣＵとに、ＥＣＵの種類を分けたが、実際にはサーバＥＣＵがクライアントＥＣＵであってもよいし、クライアントＥＣＵがサーバＥＣＵの役割を担ってもよい。本実施の形態では、特定のサービスに注目してサーバＥＣＵまたはクライアントＥＣＵと呼んでいるに過ぎない。

　（４）上記の実施の形態では、アプリ認証情報をＥＣＵが通知し、仲介ＥＣＵ２００が認証情報を検証していたが、認証情報を予め仲介ＥＣＵ２００が保持していてもよい。または、工場の組み立て段階で初回起動時に、通知された認証情報を検証し、不揮発メモリに保持していてもよい。これにより、車両起動時に毎回認証情報の検証を行う必要がなくなり、車載ネットワークの通信量削減および、仲介ＥＣＵ２００の処理負荷低減に効果的である。

　（５）上記の実施の形態では、アプリ認証情報は平文で保持されていたが、暗号化されて保持されていてもよい。同様にサービスポリシも暗号化されて保持されていてもよい。

　（６）上記の実施の形態では、仲介ＥＣＵ２００に複数ポートを持つイーサネットスイッチが存在し、各ＥＣＵは仲介ＥＣＵ２００を介した通信を行う例を示したが、仲介ＥＣＵ２００にイーサネットスイッチが存在しなくてもよい。例えば、サーバＥＣＵとクライアントＥＣＵは、仲介ＥＣＵ２００のみと通信することで、サービスの提供を行ってもよい。これにより仲介ＥＣＵ２００の物理的な配置によらず、サービスの仲介を実現することが可能となる。

　（７）上記の実施の形態では、記載が省略されているが、カーメーカやアプリベンダの公開鍵が保持されており、アプリ認証情報の正当性を検証する。

　（８）上記の実施の形態では、イーサネットの通信は平文で行われているとしているが、ＩＰｓｅｃ、ＭＡＣｓｅｃまたはＴＬＳ等の暗号化通信をしていてもよい。また、事前に共有したセッション鍵を用いてペイロードを暗号化してもよい。これによりネットワークにアクセスし、盗聴を行う攻撃者に対して、サービスに関する情報を秘匿することが可能となり効果的である。

　（９）上記の実施の形態では、全てのネットワークが接続されている例を示したが、Ｖｉｒｔｕａｌ　ＬＡＮ（ＶＬＡＮ）によって論理的に分離してもよい。これにより、セキュリティ強度が高まり効果的である。

　（１０）上記の実施の形態では、アプリ認証情報の一例にセッション鍵が保持されている例を示したが、セッション鍵は必須の構成ではない。

　（１１）上記の実施の形態では、サービス情報の一例に、メイン状態としてＩＰアドレスと状態を保持する例を示したが、保持する情報はこれに限らない。例えばサービスを提供するポート番号が含まれてもよい。同様にクライアントの情報としてポート番号が含まれてもよい。これにより、例えば正規のＩＰアドレスのサーバ上に不正なアプリケーションが動作し、不正なポート番号からの通信を検知することが可能となり、セキュリティ向上に効果的である。

　（１２）上記の実施の形態では、代理送信の有無は、サービスポリシにより決定されていたが、車両状態と組み合わせて決定されてもよい。例えば、車両状態に応じてリアルタイム性の要求が変更されるようなサービスについては、車両状態に応じて代理送信の有無を切り替えてもよい。

　（１３）上記の実施の形態では、代理送信の有無は、サービスポリシにより決定されていたが、メッセージの種類に応じて決定されてもよい。図１９Ｃに、仲介ＥＣＵ２００によりサービス仲介方法が決定されるフローチャートを示す。図１９Ｃでは、サービスごとに設定される属性に基づいて、仲介方法が決定される例を示している。サービスの属性としては、サービスの種類（状態通知、制御信号、診断、アップデート）、状態信号の属性（公開・非公開、制御判断情報、ユーザ通知情報）であってもよい。

　ステップＳ７０１において、仲介ＥＣＵ２００は、サービスの属性を受信する。サービスの属性は、Ｏｆｆｅｒメッセージに含まれてもよいし、ＳＯＭＥ／ＩＰメッセージ以外でやりとりされてもよいし、予め保持しているサービスごとのマニフェストファイルに記載してあってもよい。

　ステップＳ７０２において、仲介ＥＣＵ２００は、サービスの種類が状態通知であるか否かを判定する。状態通知の種類のサービスであると判定した場合は、仲介ＥＣＵ２００は、ステップＳ７０３を実行する。状態通知のサービスでない場合は、ステップＳ７１０を実行する。

　ステップＳ７０３において、仲介ＥＣＵ２００は、サービスの状態信号の属性が公開情報であるか否かを判定する。サービスの状態信号の属性が公開情報であると判定した場合は、仲介ＥＣＵ２００は、ステップＳ７０４を実行する。サービスの状態信号の属性が公開情報でないと判定した場合は、仲介ＥＣＵ２００は、ステップＳ７０５を実行する。

　ここで、サービスの状態信号は、サービスにより通知される状態通知をいう。状態信号は属性を有する。例えば、状態信号が、ネットワークシステムに参加するすべてのＥＣＵに取得可能な情報であれば、「公開情報」の属性が付与される。また、制御ＥＣＵが、状態信号を基に制御を行う場合は、「制御指示情報（コマンド情報）」、または、「制御判断情報（センサ情報）」の属性が付与される。また、制御ＥＣＵの制御に、直接には関係しない情報として、ドライバーなどのユーザに対して音声または画面を通して情報を通知するための信号には、「ユーザ通知情報」の属性が付与される。これら状態信号の属性に応じて、セキュリティレベル（つまり、サービス仲介、または、代理送信の有無）が決定されてもよい。

　ステップＳ７０４において、仲介ＥＣＵ２００は、サービスがどのクライアントに提供されても問題がないことから、当該サービスの仲介方法を、サービス仲介「無し」、かつ、代理送信「無し」、と設定し、処理を終了する。

　ステップＳ７０５において、仲介ＥＣＵ２００は、サービスの状態信号の属性が、制御の判断に用いられる情報であるか否かを判定する。サービスの状態信号の属性が、制御の判断に用いられる情報であると判定した場合は、仲介ＥＣＵ２００は、ステップＳ７０７を実行する。サービスの状態信号の属性が、制御の判断に用いられる情報でないと判定した場合は、仲介ＥＣＵ２００は、ステップＳ７０８を実行する。

　ステップＳ７０７において、仲介ＥＣＵ２００は、リアルタイム性が要求されることから、当該サービスの仲介方法を、代理送信「無し」、かつ、サービスの仲介「有り」、と設定し、処理を終了する。

　ステップＳ７０８において、仲介ＥＣＵ２００は、サービスの状態信号の属性がユーザ通知情報であるか否かを判定する。サービスの状態信号の属性がユーザ通知情報であると判定した場合は、ステップＳ７０９を実行する。状態がユーザ通知情報でない場合は、仲介ＥＣＵ２００は、ステップＳ７１０を実行する。

　ステップＳ７０９において、仲介ＥＣＵ２００は、リアルタイム性よりも情報の信頼性が求められることから、当該サービスの仲介方法を、代理送信「有り」、かつ、サービス仲介「有り」と設定し、処理を終了する。

　ステップＳ７１０において、仲介ＥＣＵ２００は、デフォルトの設定として、サービス仲介「有り」、かつ、代理送信「無し」を当該サービスの仲介方法として設定する。

　（１４）上記の実施の形態では、仲介ＥＣＵ２００が認証情報を検証することで、アクセス権限を管理したが、認証情報の検証を行わなくてもよい。

　（１５）上記の実施の形態では、サービス情報の不整合が発生したときに、仲介ＥＣＵ２００はメッセージを破棄したが、サービス情報の不整合が発生したときの処理は、メッセージの破棄に限らない。例えば、仲介ＥＣＵ２００は、不整合に関する情報をログとして保存してもよいし、外部へ通知してもよい。図２０に、外部へ通知されるログの一例を示す。外部に通知されるログは、ディスプレイに可視化のために表示されてもよい。

　図２０では、異常検知ログのシリアルＩＤであるログＩＤが１００２００であり、異常の種類を伝える異常コードが０ｘ１０（サービスポリシ違反）であることを示している。また検出内容の詳細については、サービスＩＤが０ｘ１０のサービスにおいて、アクセス元情報の異常を検出したことを示している。異常を検出したオリジナルのパケットもログに含まれており、異常検知時に行った対応については、オリジナルパケットの破棄と、サブサーバへの切り替えを試みたが車両状態が切り替えポリシの条件を満たさなかったため、未切り替えの状態であることを示している。

　（１６）上記の実施の形態では、メインサーバの異常検知時に仲介ＥＣＵ２００がサブサーバへ切り替える処理を示したが、異常検知時以外にも仲介ＥＣＵ２００はサブサーバの切り替えを行ってもよい。例えば、メインサーバの処理負荷や、通信帯域の増加に応じて、仲介ＥＣＵ２００はサブサーバへ切り替えることで負荷分散を行ってもよい。また、車両状態に応じてサブサーバを選択してもよい。例えば車両状態ごとにサーバの負荷を保持しており、仲介ＥＣＵ２００は最も負荷の低いサーバへ切り替えるとしてもよい。また、サーバの優先度が設けられており、仲介ＥＣＵ２００はサーバの優先度に従ってサーバが選択してもよい。例えば車両状態、通信帯域、サーバ負荷、動作中の機能に応じて仲介ＥＣＵ２００は優先度を算出し、優先度に従って適切なサーバが選択されるとしてもよい。

　（１７）上記の実施の形態では、サブサーバは１つである例を示したが、サブサーバは複数あってもよい。

　（１８）上記の実施の形態では、代理送信時に、仲介ＥＣＵ２００は複数のサーバからのメッセージの受信を待っていたが、最初に受信したメッセージをクライアントに転送してもよい。これにより通信の遅延が少なくなり効果的である。また、メッセージの転送後に、仲介ＥＣＵ２００は他サーバからのメッセージとの比較を行うことで異常な通信の発生を検知してもよい。これにより不正な通信を検知することも可能となりセキュリティ向上に効果的である。

　（１９）上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。

　（２０）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ　Ｓｃａｌｅ　Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。

　また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又はすべてを含むように１チップ化されてもよい。

　また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。

　さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

　（２１）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。

　（２２）本開示は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムからなるデジタル信号であるとしてもよい。

　また、本開示は、コンピュータプログラムまたはデジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ（登録商標）　Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されているデジタル信号であるとしてもよい。

　また、本開示は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。

　また、本開示は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記録しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。

　また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。

　（２３）上記実施の形態では、自動車を対象としたサイバーフィジカルシステムのセキュリティ対策として説明したが、適用範囲はこれに限られない。従って、自動車を対象とした攻撃の可視化のためのユーザインタフェース（ＵＩ）についても適用範囲はこれに限られない。自動車に限らず、建機、農機、船舶、鉄道、飛行機などのモビリティにも適用してもよく、また、工場やビルなどの産業制御システムで利用される通信ネットワークや、組込みデバイスを制御するための通信ネットワークに適用してもよい。

　（２４）上記実施の形態では、自動車を対象としたサイバーフィジカルシステムのセキュリティ対策として説明したが、セキュリティ機能の各処理の判断結果や出力結果をサイバーフィジカルシステムにおける攻撃の可視化のためのユーザインタフェース（ＵＩ）として表示しても良い。自動車に限らず、建機、農機、船舶、鉄道、飛行機などのモビリティにも適用してもよく、また、工場やビルなどの産業制御システムで利用される通信ネットワークや、組込みデバイスを制御するための通信ネットワークに適用してもよい。

　（２５）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。

　本開示は、サービス指向型通信を採用した車載ネットワークにおいて、攻撃者が不正なフレームを送信したとしても、仲介者による認証情報の検証を行う。さらに、サービスポリシと車両状態に応じた仲介方法を提供することで、サービスに応じたセキュリティとリアルタイム性を実現することが可能となり効果的である。

　１００ａ、１００ｂ　サーバＥＣＵ
　１００ｃ、１００ｄ　クライアントＥＣＵ
　１０１　通信部
　１０２　アプリ部
　１０３　アプリ認証情報保持部
　１０４　サービスポリシ保持部
　２００　仲介ＥＣＵ
　２０１、３０１　通信制御部
　２０２、３０２　サービス管理部
　２０３、３０３　代理送信部
　２０４　異常監視部
　２０５　サービス情報保持部
　２０６、３０４　車両状態保持部
　３００　サービス仲介装置

Claims (16)

1. 　サーバユニットからクライアントユニットへサービス指向型通信によってサービスを提供するサービス提供システムにおいて、サーバユニットおよびクライアントユニットそれぞれに接続され、前記サーバユニットまたは前記クライアントユニットから、前記サービスの提供に用いられるフレームを受信する通信制御部と、
   　前記通信制御部が受信した前記フレームに含まれるサービスの識別子と、前記フレームの送信元または宛先を示す識別子と、前記フレームの種別との組合せが適切であるか否かの判定をし、前記判定の結果の出力をするサービス管理部とを備える
   　サービス仲介装置。
2. 　前記通信制御部は、さらに、
   　前記サービスの提供の前に、提供される前記サービスを示す第一サービス情報を含むサービス提供フレームを、前記サーバユニットから受信し、
   　前記サービスの提供の前に、サービス探索フレームであって、サービス探索の対象を示す第二サービス情報を含むサービス探索フレームを、前記クライアントユニットから受信し、
   　前記サービス管理部は、さらに、
   　前記通信制御部が受信した前記サービス探索フレームに含まれる前記第二サービス情報と同一の前記第一サービス情報を含む前記サービス提供フレームを、受信した前記サービス探索フレームの送信元である前記クライアントユニットに、前記通信制御部により送信する
   　請求項１に記載のサービス仲介装置。
3. 　前記サービス提供フレームは、前記サービス提供フレームに含まれる前記第一サービス情報が示すサービスを提供するサーバとしての権限を前記サーバユニットが有することを示す第一認証情報を含み、
   　前記サービス探索フレームは、前記サービス探索フレームに含まれる前記第二サービス情報が示す前記サービスの提供を受けるクライアントとしての権限を前記クライアントユニットが有することを示す第二認証情報を含み、
   　前記サービス管理部は、さらに、
   　前記サービス提供フレームに含まれる前記第一認証情報の検証が成功した場合に、前記サービス提供フレームを有効と判定し、
   　前記サービス探索フレームに含まれる前記第二認証情報の検証が成功した場合に、前記サービス探索フレームを有効と判定し、
   　前記サービス提供フレームおよび前記サービス探索フレームを有効と判定した場合に、前記サービス提供フレームを前記クライアントユニットに、前記通信制御部により送信する
   　請求項２に記載のサービス仲介装置。
4. 　前記通信制御部は、
   　前記サービスを提供する前記サーバユニットから、前記サービスの提供に用いられる第一フレームを受信した場合に、前記サービスの提供を受ける前記クライアントユニットに前記第一フレームを送信し、
   　前記サービスの提供を受ける前記クライアントユニットから、前記サービスの提供に用いられる第二フレームを受信した場合に、前記サービスを提供する前記サーバユニットに前記第二フレームを送信する
   　請求項１～３のいずれか１項に記載のサービス仲介装置。
5. 　前記サービス仲介装置は、代理送信処理を実行する代理送信部を備え、
   　前記代理送信処理は、
   　前記第一フレームを前記通信制御部が受信した場合に、前記第一フレームに含まれる送信元を示す情報を、前記サービス仲介装置の識別子に変更してから、前記第一フレームを前記クライアントユニットに送信する処理、または、
   　前記第二フレームを前記通信制御部が受信した場合に、前記第二フレームに含まれる送信元を示す情報を、前記サービス仲介装置の識別子に変更してから、前記第二フレームを前記サーバユニットに送信する処理を含む
   　請求項４に記載のサービス仲介装置。
6. 　前記サーバユニット、前記クライアントユニットおよび前記サービス仲介装置は、車両に搭載されており、
   　前記サービス仲介装置は、さらに、前記車両の状態を示す状態情報を保持している車両状態保持部を備え、
   　前記代理送信部は、前記車両状態保持部が保持している前記状態情報に応じて、前記代理送信処理を実行するか否かを制御する
   　請求項５に記載のサービス仲介装置。
7. 　前記サーバユニットは、第一サーバユニットと第二サーバユニットとを含み、
   　前記通信制御部は、
   　前記第一サーバユニットから前記サービス提供フレームを受信した場合には、所定期間の待機状態をとり、
   　前記待機状態において前記第二サーバユニットから前記サービス提供フレームを受信した場合には、受信した２つの前記サービス提供フレームのいずれかを前記クライアントユニットに送信する
   　請求項２～６のいずれか１項に記載のサービス仲介装置。
8. 　前記通信制御部は、
   　前記待機状態において前記第二サーバユニットから前記サービス提供フレームを受信しない場合には、前記第一サーバユニットから受信した前記サービス提供フレームを前記クライアントユニットに送信し、かつ、前記第二サーバユニットに異常が発生した場合に行う所定の処理を実行する
   　請求項７に記載のサービス仲介装置。
9. 　前記通信制御部は、
   　前記待機状態において前記第二サーバユニットから前記サービス提供フレームを受信しない場合には、前記第一サーバユニットから受信した前記サービス提供フレームを前記クライアントユニットに送信するか否かを、前記サービスの種別に応じて制御する
   　請求項７に記載のサービス仲介装置。
10. 　前記サーバユニット、前記クライアントユニットおよび前記サービス仲介装置は、車両に搭載されており、
    　前記サービス仲介装置は、さらに、前記車両の状態を示す状態情報を保持している車両状態保持部を備え、
    　前記通信制御部は、
    　前記待機状態において前記第二サーバユニットから前記サービス提供フレームを受信しない場合には、前記第一サーバユニットから受信した前記サービス提供フレームを前記クライアントユニットに送信するか否かを、前記車両状態保持部が保持している前記状態情報に応じて制御する
    　請求項７に記載のサービス仲介装置。
11. 　前記サーバユニットは、第一サーバユニットと第二サーバユニットとを含み、
    　前記通信制御部は、
    　前記クライアントユニットから前記サービス探索フレームを受信した場合には、受信した前記サービス探索フレームを、前記第一サーバユニットおよび前記第二サーバユニットの両方に送信する
    　請求項２～１０のいずれか１項に記載のサービス仲介装置。
12. 　前記サーバユニットは、複数のサーバユニットを含み、
    　前記サービス管理部は、
    　前記複数のサーバユニットが通信可能状態にあるか否かを示す通信状態情報を保持していて、
    　保持している前記通信状態情報を前記クライアントユニットに送信する
    　請求項２～１１のいずれか１項に記載のサービス仲介装置。
13. 　前記サービス管理部は、前記複数のサーバユニットのうちの一のサーバユニットが通信不可能状態であることを検出した場合に、前記通信状態情報を参照して、前記複数のサーバユニットのうち通信可能状態であるサーバユニットから受信した前記サービス提供フレームを前記クライアントユニットに送信する
    　請求項１２に記載のサービス仲介装置。
14. 　前記判定の結果の出力は、
    　前記判定の結果を示す情報を表示画面に表示すること、または、
    　前記判定の結果を示す情報をネットワークを介して外部装置に送信することを含む
    　請求項１～１３のいずれか１項に記載のサービス仲介装置。
15. 　サーバユニットからクライアントユニットへサービス指向型通信によってサービスを提供するサービス提供システムにおいて、サーバユニットおよびクライアントユニットそれぞれに接続される通信制御部により、前記サーバユニットまたは前記クライアントユニットから、前記サービスの提供に用いられるフレームを受信し、
    　前記通信制御部が受信した前記フレームに含まれるサービスの識別子と、前記フレームの送信元または宛先を示す識別子と、前記フレームの種別との組合せが適切であるか否かの判定をし、前記判定の結果の出力をする
    　サービス仲介方法。
16. 　請求項１５に記載のサービス仲介方法をコンピュータに実行させるプログラム。

Images