(57)【要約】【課題】更新または新規追加に相当する新サービスがネットワーク上で正常に動作することを容易に確認する。【解決手段】制御装置は、サービスを有する複数のコントローラと、ネットワークとを備え、複数のコントローラのそれぞれは、複数のサービス間での通信制御を行うことでサービスの組み合わせによる所望の動作を実現する制御部を含み、制御部は、新サービスが正常に動作するか否かの動作確認を実行するに当たり、サービスを起動するプロセス状態を、通常モードから診断モードに遷移させ、新サービスに対してサービスを提供する提供元サービス、および新サービスを利用する利用先サービスを特定し、診断モードにおいて、新サービス、提供元サービス、および利用先サービスにより構成される複数のサービス間で通信制御を行うことで、動作確認を実行する。【選択図】図１
2020141352.tif 000002
【特許請求の範囲】
【請求項１】
所望の機能を処理するソフトウェア要素であるサービスを有する複数のコントローラと、
前記複数のコントローラを相互に接続するネットワークと
を備え、
前記複数のコントローラのそれぞれは、前記ネットワークを介して複数のサービス間での通信制御を行うことでサービスの組み合わせによる所望の動作を実現する制御部を含み、
前記制御部は、更新または新規追加に相当する新サービスが正常に動作するか否かの動作確認を実行するに当たり、
サービスを起動するプロセス状態を、前記新サービスの通常動作を実行する通常モードから、前記通常動作を制限して前記新サービスの前記動作確認を実行するための診断モードに遷移させ、
前記新サービスに対してサービスを提供する提供元サービス、および前記新サービスを利用する利用先サービスを特定し、
前記診断モードにおいて、前記新サービス、前記提供元サービス、および前記利用先サービスにより構成される前記複数のサービス間で通信制御を行うことで、サービスの組み合わせによって前記所望の動作を実現するために前記動作確認を実行する
制御装置。
【請求項２】
前記新サービスは、前記通常動作を行う際に使用されるメインのサービスと、前記診断モード時に使用され、前記通常動作が制限されたダミーのサービスとで構成されており、
前記メインのサービスと前記ダミーのサービスとは、同一の識別子および同一のインタフェースを有しており、
前記制御部は、前記診断モード時に前記ダミーのサービスを起動することで前記新サービスの前記動作確認を実行する
請求項１に記載の制御装置。
【請求項３】
前記複数のコントローラのうちの１以上のコントローラは、前記ネットワーク上に存在するそれぞれのサービスに関して、前記提供元サービスがサービス提供登録として登録され、前記利用先サービスがサービス利用登録として登録されたサービスレジストリをさらに有し、
前記複数のコントローラにおけるそれぞれの制御部は、前記サービスレジストリを参照することで、前記提供元サービスおよび前記利用先サービスを特定する
請求項２に記載の制御装置。
【請求項４】
前記提供元サービスは、前記新サービスに提供すべきデータに対応するテストデータをダミーのサービス内に有し、
前記提供元サービスを有するコントローラは、前記診断モードにおいて、前記新サービスを有するコントローラに対して前記テストデータを送信し、
前記利用先サービスは、前記テストデータに対応する期待値をダミーのサービス内に有し、
前記利用先サービスを有するコントローラに含まれている制御部は、前記新サービスを有するコントローラから前記テストデータを用いた演算結果を取得し、前記演算結果と前記期待値とが一致するか否かを示すテスト結果を出力する
請求項３に記載の制御装置。
【請求項５】
請求項４に記載の制御装置と、
前記制御装置に対して前記新サービスを提供するサーバと
を備え、
前記制御装置に含まれている前記複数のコントローラのうちの１つのコントローラは、公衆通信回線を介して前記サーバと通信可能に接続されるとともに、前記制御装置を統括制御するゲートウェイＥＣＵであり、
前記ゲートウェイＥＣＵは、
前記サーバから取得した前記新サービスに関する前記動作確認を、前記制御装置で実行させ、
前記動作確認を実行したことによる前記テスト結果として、前記演算結果と前記期待値とが一致することを示すテスト結果が得られた場合には、前記プロセス状態を、前記診断モードから前記通常モードに遷移させ、前記新サービスを用いた前記通常動作を開始させる
通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、更新または新規追加に相当する新サービスの動作確認を実行する制御装置および通信システムに関する。
【背景技術】
【０００２】
近年、複数の制御装置をネットワークで接続して通信を行うシステムでは、各制御装置がサービスを提供し、各サービスの組み合わせによって所望の動作が実現されている。このようなシステムは、一例として自動車に適用される。従来、自動車の製造後において、自動車に搭載される制御装置のサービスを変更することはなかった。しかしながら、自動車が外部のネットワークと接続されるようになり、自動車の製造後においても、サービスの変更および追加ができるようになった。
【０００３】
このような状況においては、これまで自動車の製造時に実施していたサービスのテストを、自動車の製造後に新たに追加したサービスに対しても実施し、サービスが正常に動作することを検証することが必要である。
【０００４】
このような検証を行うために、新サービスを新たに提供する前に、新サービスを識別して、新サービスに関するテストを実施し、テスト結果を外部装置に送信する従来技術がある（例えば、特許文献１参照）。特許文献１において、外部装置は、受信したテスト結果に基づいて、新サービスの利用の許可を判断する。さらに、外部装置は、許可が得られた場合に、新サービスの利用を可能とすることで、新たに追加されたサービスが正常に動作する状況を確保している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１６−１６３２４４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来技術には、以下のような課題がある。
特許文献１では、各サービスがＳＯＡ（Ｓｅｒｖｉｃｅ  Ｏｒｉｅｎｔｅｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ：サービス指向型アーキテクチャ）に基づいて構成されている。さらに、テストに用いるテストメッセージも、テスト用のサービスが用意され、このサービスもＳＯＡに基づいている。
【０００７】
つまり、特許文献１では、追加するサービスが正常に動作する状況を確保するテストを実施するために、新たなテスト用のサービスおよび新たなサービスインタフェースを用意する必要がある。従って、特許文献１では、新サービスのテストを実施するために、システムの複雑さが増し、新サービスがネットワーク上で正常に動作することを容易に確認することが困難であった。
【０００８】
本発明は、前記のような課題を解決するためになされたものであり、更新または新規追加に相当する新サービスがネットワーク上で正常に動作することを容易に確認することができる制御装置および通信システムを得ることを目的とする。
【課題を解決するための手段】
【０００９】
本発明に係る制御装置は、所望の機能を処理するソフトウェア要素であるサービスを有する複数のコントローラと、複数のコントローラを相互に接続するネットワークと
を備え、複数のコントローラのそれぞれは、ネットワークを介して複数のサービス間での通信制御を行うことでサービスの組み合わせによる所望の動作を実現する制御部を含み、制御部は、更新または新規追加に相当する新サービスが正常に動作するか否かの動作確認を実行するに当たり、サービスを起動するプロセス状態を、新サービスの通常動作を実行する通常モードから、通常動作を制限して新サービスの動作確認を実行するための診断モードに遷移させ、新サービスに対してサービスを提供する提供元サービス、および新サービスを利用する利用先サービスを特定し、診断モードにおいて、新サービス、提供元サービス、および利用先サービスにより構成される複数のサービス間で通信制御を行うことで、サービスの組み合わせによって所望の動作を実現するために動作確認を実行するものである。
【００１０】
また、本発明に係る通信システムは、本発明に係る制御装置と、制御装置に対して新サービスを提供するサーバとを備え、制御装置に含まれている複数のコントローラのうちの１つのコントローラは、公衆通信回線を介してサーバと通信可能に接続されるとともに、制御装置を統括制御するゲートウェイＥＣＵであり、ゲートウェイＥＣＵは、サーバから取得した新サービスに関する動作確認を、制御装置で実行させ、動作確認を実行したことによるテスト結果として、演算結果と期待値とが一致することを示すテスト結果が得られた場合には、プロセス状態を、診断モードから通常モードに遷移させ、新サービスを用いた通常動作を開始させるものである。
【発明の効果】
【００１１】
本発明によれば、更新するサービスまたは新たに追加するサービスがネットワーク上で正常に動作することを容易に確認することができる制御装置および通信システムを得ることができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施の形態１に係る通信システムの概略を示す図である。
【図２】本発明の実施の形態１に係るゲートウェイＥＣＵの構成を示す図である。
【図３】本発明の実施の形態１に係るドメインコントローラＥＣＵの構成を示す図である。
【図４】本発明の実施の形態１に係るローカルＥＣＵの構成を示す図である。
【図５】本発明の実施の形態１に係るサーバの構成を示す図である。
【図６】本発明の実施の形態１に係るサービスパッケージの構成を示す図である。
【図７Ａ】本発明の実施の形態１に係るセンシングサービスパッケージの構成を示した図である。
【図７Ｂ】本発明の実施の形態１に係るアクチュエータサービスパッケージの構成を示す図である。
【図８Ａ】本発明の実施の形態１に係る通信システムの一連の動作を示したシーケンス図である。
【図８Ｂ】本発明の実施の形態１に係る通信システムの一連の動作を示したシーケンス図である。
【図８Ｃ】本発明の実施の形態１に係る通信システムの一連の動作を示したシーケンス図である。
【図８Ｄ】本発明の実施の形態１に係る通信システムの一連の動作を示したシーケンス図である。
【図９】本発明の実施の形態１におけるマニフェストの具体例を示す図である。
【図１０Ａ】本発明の実施の形態１において、新サービスをテストする際の入力となるテストデータ生成サービスの構成を示す図である。
【図１０Ｂ】本発明の実施の形態１において、新サービスをテストする際の入力となるテストデータ生成サービスの構成を示す図である。
【図１１Ａ】本発明の実施の形態１において、新サービスをテストする際の出力結果からテスト結果を判定するサービスの構成を示す図である。
【図１１Ｂ】本発明の実施の形態１において、新サービスをテストする際の出力結果からテスト結果を判定するサービスの構成を示す図である。
【図１２】本発明の実施の形態１において、テストデータ生成サービスおよびテスト結果判定サービスを管理するテスト管理サービスパッケージの構成を示す図である。
【図１３】本発明の実施の形態１における各制御装置の機能がハードウェアで実現される場合の構成を示す図である。
【発明を実施するための形態】
【００１３】
以下、本発明の制御装置および通信システムの好適な実施の形態につき図面を用いて説明する。
なお、以下では、複数の制御装置がネットワークにより接続された通信システムの一例として、車に搭載される複数の制御装置が車載ネットワークにより接続された通信システムを挙げて説明する。
【００１４】
実施の形態１．
図１は、本発明の実施の形態１に係る通信システムの概略を示す図である。まず、図１を用いて、通信システムの全体構造について説明する。
【００１５】
通信システムは、図１に示すように、車載ネットワーク１００および外部ネットワーク２００で構成されている。車載ネットワーク１００には、ゲートウェイＥＣＵ１１０、ドメインコントローラＥＣＵ１２０、１３０、およびローカルＥＣＵ１４０、１５０、１６０、１７０が、複数の制御装置として含まれている。また、外部ネットワーク２００には、サーバ２１０および公衆通信回線２２０が含まれている。
【００１６】
ここで、ＥＣＵとは、Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ（電子制御ユニット）の略であり、後述するように、相互のＥＣＵ間で通信制御を行う制御部を備えたコントローラに相当する。
【００１７】
ゲートウェイＥＣＵ１１０は、例えば、Ｗｉ−ｆｉ（登録商標）のような無線通信を利用して、公衆通信回線２２０に接続され、公衆通信回線２２０を介してサーバ２１０に接続されている。
【００１８】
車載ネットワーク１００において、ゲートウェイＥＣＵ１１０、ドメインコントローラＥＣＵ１２０、１３０、ローカルＥＣＵ１４０、１５０、１６０、１７０のそれぞれの機器間は、通信バス１８０によって相互に接続されている。通信バス１８０としては、Ｅｔｈｅｒｎｅｔ（登録商標）、ＣＡＮ（Ｃｏｎｔｒｏｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などのネットワークを利用することができる。
【００１９】
従って、ゲートウェイＥＣＵ１１０は、公衆通信回線２２０を介してサーバ２１０と通信可能に接続されるとともに、ドメインコントローラＥＣＵ１２０、１３０、およびローカルＥＣＵ１４０、１５０、１６０、１７０を統括制御する。
【００２０】
図２は、本発明の実施の形態１に係るゲートウェイＥＣＵ１１０の構成を示す図である。ゲートウェイＥＣＵ１１０は、プロセッサ１１１、タイマ１１２、通信インタフェース１１３、外部通信インタフェース１１４、補助記憶装置１１５、およびメモリ１１６の各ハードウェアを備えて構成されている。ゲートウェイＥＣＵ１１０内のこれらのハードウェアは、信号線を介して相互に接続されている。
【００２１】
プロセッサ１１１は、演算処理を行うＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）であり、他のハードウェアを制御する。例えば、プロセッサ１１１は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）、またはＧＰＵ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）である。
【００２２】
タイマ１１２は、発振回路からのクロック信号をカウントする。発振回路は、例えば、水晶発振子またはセラミック振動子である。通信インタフェース１１３は、例えば、ＥｔｈｅｒｎｅｔまたはＣＡＮである。外部通信インタフェース１１４は、例えば、Ｗｉ−ｆｉである。
【００２３】
補助記憶装置１１５は、不揮発性の記憶装置である。例えば、補助記憶装置１１５は、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）、またはフラッシュメモリである。補助記憶装置１１５に記憶されたデータは、必要に応じてメモリ１１６にロードされる。
【００２４】
メモリ１１６は、揮発性の記憶装置である。メモリ１１６は、主記憶装置またはメインメモリとも呼ばれる。例えば、メモリ１１６は、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）である。メモリ１１６に記憶されたデータは、必要に応じて補助記憶装置１１５に保存される。
【００２５】
図３は、本発明の実施の形態１に係るドメインコントローラＥＣＵ１２０、１３０の構成を示す図である。ドメインコントローラＥＣＵ１２０は、プロセッサ１２１、タイマ１２２、通信インタフェース１２３、補助記憶装置１２５、およびメモリ１２６の各ハードウェアを備えて構成されている。ドメインコントローラＥＣＵ１２０内のこれらのハードウェアは、信号線を介して相互に接続されている。
【００２６】
同様に、ドメインコントローラＥＣＵ１３０は、プロセッサ１３１、タイマ１３２、通信インタフェース１３３、補助記憶装置１３５、およびメモリ１３６の各ハードウェアを備えて構成されている。ドメインコントローラＥＣＵ１３０内のこれらのハードウェアは、信号線を介して相互に接続されている。
【００２７】
プロセッサ１２１、１３１、タイマ１２２、１３２、通信インタフェース１２３、１３３、補助記憶装置１２５、１３５、およびメモリ１２６、１３６は、それぞれプロセッサ１１１、タイマ１１２、通信インタフェース１１３、補助記憶装置１１５、およびメモリ１１６と同様のものである。
【００２８】
図４は、本発明の実施の形態１に係るローカルＥＣＵ１４０、１５０、１６０、１７０の構成を示す図である。ローカルＥＣＵ１４０は、プロセッサ１４１、タイマ１４２、通信インタフェース１４３、補助記憶装置１４５、およびメモリ１４６の各ハードウェアを備えて構成されている。ローカルＥＣＵ１４０内のこれらのハードウェアは、信号線を介して相互に接続されている。
【００２９】
同様に、ローカルＥＣＵ１５０は、プロセッサ１５１、タイマ１５２、通信インタフェース１５３、補助記憶装置１５５、およびメモリ１５６の各ハードウェアを備えて構成されている。ローカルＥＣＵ１５０内のこれらのハードウェアは、信号線を介して相互に接続されている。
【００３０】
同様に、ローカルＥＣＵ１６０は、プロセッサ１６１、タイマ１６２、通信インタフェース１６３、補助記憶装置１６５、およびメモリ１６６の各ハードウェアを備えて構成されている。ローカルＥＣＵ１６０内のこれらのハードウェアは、信号線を介して相互に接続されている。
【００３１】
同様に、ローカルＥＣＵ１７０は、プロセッサ１７１、タイマ１７２、通信インタフェース１７３、補助記憶装置１７５、およびメモリ１７６の各ハードウェアを備えて構成されている。ローカルＥＣＵ１７０内のこれらのハードウェアは、信号線を介して相互に接続されている。
【００３２】
プロセッサ１４１、１５１、１６１、１７１、タイマ１４２、１５２、１６２、１７２、通信インタフェース１４３、１５３、１６３、１７３、補助記憶装置１４５、１５５、１６５、１７５、およびメモリ１４６、１５６、１６６、１７６は、それぞれプロセッサ１１１、タイマ１１２、通信インタフェース１１３、補助記憶装置１１５、およびメモリ１１６と同様のものである。
【００３３】
図５は、本発明の実施の形態１に係るサーバ２１０の構成を示す図である。サーバ２１０は、プロセッサ２１１、タイマ２１２、外部通信インタフェース２１４、補助記憶装置２１５、およびメモリ２１６の各ハードウェアを備えて構成されている。サーバ２１０内のこれらのハードウェアは、信号線を介して相互に接続されている。
【００３４】
プロセッサ２１１、タイマ２１２、外部通信インタフェース２１４、補助記憶装置２１５、およびメモリ２１６は、それぞれプロセッサ１１１、タイマ１１２、外部通信インタフェース１１４、補助記憶装置１１５、およびメモリ１１６と同様のものである。
【００３５】
次に、図２〜図５のそれぞれの構成による機能を説明する。図２のゲートウェイＥＣＵ１１０において、プロセッサ１１１は、制御部３１１のソフトウェア要素を有する。ここで、ソフトウェア要素とは、ソフトウェアで実現される要素である。
【００３６】
補助記憶装置１１５には、制御部３１１として機能させるプログラムが記憶されている。プログラムは、メモリ１１６にロードされて、プロセッサ１１１によって実行される。また、補助記憶装置１１５には、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）が記憶されている。ＯＳの少なくとも一部は、メモリ１１６にロードされて、プロセッサ１１１によって実行される。
【００３７】
プログラムを実行して得られるデータは、補助記憶装置１１５、メモリ１１６、あるいはプロセッサ１１１内のレジスタまたはキャッシュメモリといった記憶装置に記憶される。
【００３８】
タイマ１１２は、クロック信号をカウントし、時間へ変換するカウンタ部３１２として機能する。メモリ１１６は、データを記憶する記憶部３１６として機能する。ただし、他の記憶装置が、メモリ１１６の代わりに、あるいはメモリ１１６とともに、記憶部３１６として機能してもよい。
【００３９】
通信インタフェース１１３は、通信部３１３を有している。通信部３１３は、通信バス上に流れるメッセージを受信し、アナログ信号からデジタル信号に変換してデータを取得する機能を有している。さらに、通信部３１３は、デジタル信号をアナログ信号に変換して、規定のプロトコルに準拠したメッセージを通信バス上へ送信する機能を有している。外部通信インタフェース１１４は、無線通信として機能する外部通信部３１４を有している。
【００４０】
図３のドメインコントローラＥＣＵ１２０、１３０に示す各機能、図４のローカルＥＣＵ１４０、１５０、１６０、１７０に示す各機能、および、図５のサーバ２１０に示す各機能は、前述した図２のゲートウェイＥＣＵ１１０が持つ機能３１１〜３１４、３１６と同様のものである。
【００４１】
次に、サービスパッケージについて説明する。図６は、本発明の実施の形態１に係るサービスパッケージ４００の構成を示す図である。サービスパッケージ４００は、サービス４０１、プロバイドサービスインタフェース４０２、リクエストサービスインタフェース４０３、およびマニフェスト４０４で構成される。
【００４２】
サービス４０１は、所望の機能を処理する部位であり、ソフトウェア要素ある。このサービス４０１を提供するプログラムは、ＳＯＡ（Ｓｅｒｖｉｃｅ  Ｏｒｉｅｎｔｅｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ：サービス指向型アーキテクチャ）に基づき構成されている。ここで、ＳＯＡとは、サービスをサービス提供者およびサービス利用者の２種類で定義し、ネットワーク上でそれぞれのサービスを検索して利用する方法に基づいている。
【００４３】
また、サービス４０１は、サービスレジストリに登録される。サービスレジストリは、サービス提供者からのサービス提供登録、およびサービス利用者からのサービス利用登録を行う。そして、サービスレジストリは、提供するサービスと利用するサービスとがそれぞれサービスレジストリ上に存在する場合には、それぞれのサービス間の通信を確立させる。
【００４４】
このサービスレジストリは、車載ネットワーク１００上のいずれかのＥＣＵに１つ以上存在する。本実施の形態１では、各ＥＣＵにサービスレジストリがあることとする。さらに、本実施の形態１では、ゲートウェイＥＣＵ１１０を除く、各ＥＣＵのサービスレジストリをローカルサービスレジストリと呼び、ゲートウェイＥＣＵ１１０のサービスレジストリをグローバルサービスレジストリと呼ぶことにする。
【００４５】
また、サービスレジストリの管理は、各ＥＣＵに備わる制御部によって実施される。また、例えば、サービスの登録情報のようなサービスレジストリが扱うデータは、各ＥＣＵ上のメモリあるいは補助記憶装置に記憶される。
【００４６】
車載ネットワーク１００上の各ＥＣＵには、サービス４０１と同様のサービスが複数配置される。これらのサービスが連動することで、車両は、所望の動作を実現する。ただし、所望の動作を実現させるためには、サービスは、最低１つあればよい。
【００４７】
図６に戻り、説明を続ける。プロバイドサービスインタフェース４０２は、サービス４０１がサービス提供者である場合に実装されるインタフェースである。一方、リクエストサービスインタフェース４０３は、サービス４０１がサービス利用者である場合に実装されるインタフェースである。
【００４８】
ただし、サービス４０１がサービス提供者かつサービス利用者の場合には、プロバイドサービスインタフェース４０２とリクエストサービスインタフェース４０３のそれぞれが実装される。また、１つのサービス４０１に対して、プロバイドサービスインタフェース４０２、およびリクエストサービスインタフェース４０３は、それぞれ１つに限定される必要はなく、複数のインタフェースが実装される構成であってもよい。
【００４９】
プロバイドサービスインタフェース４０２およびリクエストサービスインタフェース４０３は、前述した通信インタフェース、例えば、Ｅｔｈｅｒｎｅｔと接続されることで、車載ネットワーク１００とつながり、ＥＣＵ間のメッセージの授受を実現する。マニフェスト４０４には、サービス４０１が起動する条件が記載されている。
【００５０】
サービス４０１を実行する場合には、サービス４０１が配置されるＥＣＵの制御部に備わるサービス実行管理機能により、マニフェスト４０４が読み込まれる。サービス実行管理機能は、このマニフェスト４０４に記載されている条件を基に、サービス４０１の起動を決定する。
【００５１】
例えば、マニフェスト４０４に、ＥＣＵの状態が“Ｒｕｎｎｉｎｇ”、サービス４０１の起動に必要なサービスが“サービスＡ”と記載されているとする。この場合、サービス実行管理機能は、現在のＥＣＵの状態およびサービスＡの実行状態を監視し、全ての条件が一致すると、サービス４０１を起動させる。また、サービス４０１の起動中に、前述した条件のいずれかが不一致になると、サービス実行管理機能は、サービス４０１を停止させる。
【００５２】
ここで、新しく追加するサービスの構成を、前述した図６とする。すなわち、新しく追加するサービスが、サービスパッケージ４００、サービス４０１、プロバイドサービスインタフェース４０２、リクエストサービスインタフェース４０３、マニフェスト４０４で構成されているとする。
【００５３】
以降、更新または新規追加に相当するサービスのことを、新サービス４０１と呼ぶことにする。また、本実施の形態１において、新サービス４０１は、ドメインコントローラＥＣＵ１２０に追加されるものとする。
【００５４】
新サービス４０１が利用するサービスは、ローカルＥＣＵ１４０上に配置されているものとする。また、新サービス４０１を利用するサービスは、ローカルＥＣＵ１６０上に配置されているものとする。
【００５５】
新サービス４０１が利用するサービスは、例えば、センサ情報を取得するセンシングサービスパッケージ４１０である。図７Ａは、本発明の実施の形態１に係るセンシングサービスパッケージ４１０の構成を示した図である。センシングサービスパッケージ４１０は、センシングサービス４１１、プロバイドサービスインタフェース４１２、およびマニフェスト４１４によって構成されている。
【００５６】
センシングサービス４１１は、自身のプロバイドサービスインタフェース４１２と、新サービス４０１のリクエストサービスインタフェース４０３とを介して、新サービス４０１にサービスを提供する。
【００５７】
一方で、新サービス４０１を利用するサービスは、例えば、アクチュエータを制御するアクチュエータサービスパッケージ４２０である。図７Ｂは、本発明の実施の形態１に係るアクチュエータサービスパッケージ４２０の構成を示す図である。アクチュエータサービスパッケージ４２０は、アクチュエータサービス４２１、リクエストサービスインタフェース４２３、およびマニフェスト４２４によって構成されている。
【００５８】
アクチュエータサービス４２１は、自身のリクエストサービスインタフェース４２３と、新サービス４０１のプロバイドサービスインタフェース４０２とを介して、新サービス４０１の提供を受ける。
【００５９】
次に、図１に示した本実施の形態１に係る通信システムの動作について、詳細に説明する。図８Ａ〜図８Ｄは、本発明の実施の形態１に係る通信システムの一連の動作を示したシーケンス図である。図８Ａの処理から図８Ｂの処理へは「Ｃ１」により接続され、図８Ｂの処理から図８Ｃの処理へは「Ｃ２」により接続され、図８Ｃの処理から図８Ｄの処理へは「Ｃ３」により接続され、図８Ａ〜図８Ｄの全体により、一連の動作が示されている。
【００６０】
まず、ユーザ９００によって自動車が始動されると、各ＥＵＣに配置されたサービスが起動する。図８Ａに示すステップＳ１０１およびステップＳ１０２は、サービス起動後の処理である。
【００６１】
サービスが起動すると、ステップＳ１０１において、新サービス４０１が利用するサービスが配置されているローカルＥＣＵ１４０は、サービス登録を行う。具体的には、新サービス４０１にサービスを提供するセンシングサービス４１１は、グローバルサービスレジストリおよび各ローカルサービスレジストリに、提供元サービスとしてサービス提供登録される。
【００６２】
一方、ステップＳ１０２において、新サービス４０１を利用するサービスが配置されているローカルＥＣＵ１６０は、サービス要求を行う。具体的には、新サービス４０１を利用するアクチュエータサービス４２１は、グローバルサービスレジストリおよび各ローカルサービスレジストリに、利用先サービスとしてサービス利用登録される。
【００６３】
本来、ゲートウェイＥＣＵ１１０、ドメインコントローラＥＣＵ１２０、１３０、ローカルＥＣＵ１５０、１６０、およびセンシングサービス４１１とアクチュエータサービス４２１とを除く他のサービスも、サービスの提供登録および利用登録を開始する。ただし、図８Ａ〜図８Ｄの具体例では不要のため、説明を省略する。
【００６４】
また、ドメインコントローラＥＣＵ１２０配下のローカルＥＣＵ１４０、１５０と、ゲートウェイＥＣＵ１１０あるいはドメインコントローラＥＣＵ１３０との間でデータ授受をする際には、ドメインコントローラＥＣＵ１２０は、ルーティング処理を行う。
【００６５】
同様に、ドメインコントローラＥＣＵ１３０配下のローカルＥＣＵ１６０、１７０と、ゲートウェイＥＣＵ１１０あるいはドメインコントローラＥＣＵ１２０との間でデータ授受をする際には、ドメインコントローラＥＣＵ１３０は、ルーティング処理を行う。ただし、このルーティング処理に関しては、説明を省略する。
【００６６】
次に、ステップＳ２０１において、ユーザ９００は、自動車に追加するサービスを選択する。本実施の形態１では、新サービス４０１を選択するとして、以下の説明を行う。ただし、ここで示すサービスは、自動車に新たに追加するサービスであってもよく、すでに自動車に配置されているサービスを更新するものであってもよい。
【００６７】
ユーザ９００がサービスを選択する手法としては、例えば、ゲートウェイＥＣＵ１１０にディスプレイのような出力装置を備え、ディスプレイ上に、追加可能なサービスを表示させ、ユーザ９００が選択することが考えられる。
【００６８】
次に、ステップＳ２０２において、ゲートウェイＥＣＵ１１０は、ユーザ９００が選択したサービスのサービスパッケージに関する取得要求をサーバ２１０に送信し、追加サービスの問合せをする。ゲートウェイＥＣＵ１１０は、追加サービスの問合せをする際に、例えば、サービスを識別するサービスＩＤを、サーバ２１０に送信する。
【００６９】
サービスＩＤは、サービスパッケージに紐づけられている。従って、サーバ２１０は、例えば、サービスＩＤとサービスパッケージとを、補助記憶装置２１５上のデータベースで管理することができる。
【００７０】
本実施の形態１では、新サービス４０１が選択される。そこで、ゲートウェイＥＣＵ１１０は、ステップＳ２０２において、サーバ２１０に対して、新サービス４０１のサービスＩＤを送信する。
【００７１】
次に、ステップＳ２０３において、サーバ２１０は、ステップＳ２０２によってゲートウェイＥＣＵ１１０から送信されたサービスＩＤを受信する。そして、サーバ２１０内の制御部３８１は、サービスＩＤを基に、補助記憶装置２１５上のデータベースを検索する。
【００７２】
制御部３８１は、検索することで該当するサービスパッケージ４００を検出し、検出したサービスパッケージ４００を、外部通信インタフェース２１４を介してゲートウェイＥＣＵ１１０に送信する。この結果、サーバ２１０は、ゲートウェイ１１０に対して、新サービス４０１に対応するサービスパッケージ４００を提供することができる。
【００７３】
次に、ステップＳ２０４において、ゲートウェイＥＣＵ１１０は、サービスパッケージ４００の取得が完了すると、サービスパッケージ４００に含まれるマニフェスト４０４を抽出し、メモリ１１６に記憶する。その後、ゲートウェイＥＣＵ１１０は、このマニフェスト４０４に記載されているサービスの配置先を参照し、配置先のＥＣＵにサービスパッケージ４００を転送する。
【００７４】
図９は、本発明の実施の形態１におけるマニフェスト４０４の具体例を示す図である。図９に示した新サービス４０１に関するマニフェスト４０４には、以下の内容が記載されている。
サービス配置：新サービスの配置先
実行タイミング：新サービスを実行するタイミング
関連サービス：新サービスの実行に必要な他のサービス
【００７５】
ステップＳ２０４の説明に戻ると、具体的には、ゲートウェイＥＣＵ１１０の制御部３１１は、マニフェスト４０４から、サービスの配置先を読み取る。本実施の形態１では、制御部３１１は、前述した図９のマニフェスト４０４より、サービスの配置先はドメインコントローラＥＣＵ１２０であると読み取る。その後、ゲートウェイＥＣＵ１１０の通信部３１３は、サービスパッケージ４００をドメインコントローラＥＣＵ１２０に転送する。
【００７６】
次に、ステップＳ２０５において、ドメインコントローラＥＣＵ１２０内の制御部３２１は、通信部３３３を介してサービスパッケージ４００を受信し、サービスパッケージ４００を補助記憶装置１２５に記憶させる。さらに、制御部３２１は、サービスパッケージ４００を補助記憶装置１２５に記憶させた後、通信部３３３を介して、転送元のゲートウェイＥＣＵ１１０に転送完了を通知する。
【００７７】
次に、ステップＳ２０６において、ゲートウェイＥＣＵ１１０は、新サービス４０１に関連するサービスが、同一の車載ネットワーク１００上に配置されていることを確認するために、関連サービスの検索を行う。具体的には、ゲートウェイＥＣＵ１１０内の制御部３１１は、メモリ１１６に記憶されたマニフェスト４０４を読み出し、マニフェスト４０４に記載されている関連サービスと、グローバルサービスレジストリに登録されているサービスとを比較する。
【００７８】
本実施の形態１において、ステップＳ１０１により、センシングサービス４１１は、グローバルサービスレジストリに対してサービス提供登録されている。また、ステップＳ１０２により、アクチュエータサービス４２１は、グローバルレジストリに対してサービス利用登録されている。
【００７９】
つまり、グローバルサービスレジストリには、新サービス４０１に対してサービスを提供する提供元サービスとしてセンシングサービス４１１が登録されており、新サービス４０１を利用する利用先サービスとしてアクチュエータサービス４２１が登録されている。
【００８０】
一方で、マニフェスト４０４には、新サービス４０１が利用するサービスにセンシングサービス４１１が記載され、新サービス４０１が提供するサービスにアクチュエータサービス４２１が記載されている。換言すると、マニフェスト４０４の記載内容から、提供元サービスとしてセンシングサービス４１１が特定され、利用先サービスとしてアクチュエータサービス４２１が特定される。
【００８１】
よって、制御部３１１は、グローバルサービスレジストリに登録されているサービスと、マニフェスト４０４に記載されているサービスとが一致していることから、関連するサービスが新サービスを追加する車載ネットワーク１００上に配置されていると判断する。
【００８２】
一方で、関連するサービスがない場合、ゲートウェイＥＣＵ１１０は、ステップＳ２０２と同様の手順で、サービス追加の要求をサーバ２１０に対して行い、後述する新サービス４０１の動作確認のテストと同様のステップで、追加するサービスのテストを実施する。
【００８３】
ここで示した関連サービスの検索は、あくまでも一例である。別の例として、例えば、サーバ２１０で管理された自動車に搭載されているサービスの構成管理情報から、関連サービスの有無を事前に確認しても良い。
【００８４】
次に、ステップＳ２０７において、ゲートウェイＥＣＵ１１０は、新サービス４０１に関連するサービスを診断モードに遷移させる指示を送信する。ここで、診断モードとは、通常動作を制限した状態であり、例えば、センサ情報取得を停止したり、アクチュエータへの入力を停止したりすることを指す。
【００８５】
この診断モードは、自動車が正常動作を確保できる状態で、追加するサービスの動作確認をするために利用される。ただし、関連サービスが自動車の正常動作を確保するために影響を及ぼさないと判断される場合には、関連サービスに関しては必ずしも診断モードに遷移させる必要はない。
【００８６】
次に、ステップＳ２０８において、関連サービスの内、センシングサービス４１１が配置されているローカルＥＣＵ１４０は、センシングサービス４１１を診断モードに遷移させる。
【００８７】
診断モードへの遷移は、例えば、ローカルＥＣＵ１４０の制御部３４１に備えられた、サービスを起動するプロセスの状態を管理するサービス実行管理によって実施される。プロセスの状態には、初期化モード、通常モード、終了モードに加えて、診断モードが含まれる。ゲートウェイＥＣＵ１１０からの診断モード遷移指示を受信したローカルＥＣＵ１４０は、サービス実行管理を実施することで、プロセスを通常モードなどから診断モードに遷移させる。
【００８８】
また、診断モードにおいては、サービスの提供およびサービスの利用要求が停止される。つまり、グローバルサービスレジストリ、あるいは各ローカルサービスレジストリに登録されていたセンシングサービス４１１は、取り消される。
【００８９】
次に、ステップＳ２０９において、ゲートウェイＥＣＵ１１０は、センシングサービス４１１が診断モードに遷移完了したことを確認する。ゲートウェイＥＣＵ１１０は、例えば、自身のグローバルサービスレジストリに登録されているサービスから、センシングサービス４１１が診断モードに遷移完了したか否かを判断する。
【００９０】
さらに、ステップＳ２０８による診断モード遷移により、ローカルＥＣＵに配置されるセンシングサービス４１１の提供が停止される。これにより、グローバルサービスレジストリに登録されていたセンシングサービス４１１のサービス提供登録が取り消される。つまり、ゲートウェイＥＣＵ１１０は、センシングサービス４１１がグローバルサービスレジストリから取り消されたことを利用して、センシングサービス４１１が診断モードに遷移したと判断する。
【００９１】
ステップＳ２１０〜ステップＳ２１２においても、ステップＳ２０７〜ステップＳ２０９と同様の処理を行う。具体的には、ステップＳ２１１において、関連サービスの内、アクチュエータサービス４２１が配置されているローカルＥＣＵ１６０は、アクチュエータサービス４２１を診断モードに遷移させる。
【００９２】
ゲートウェイＥＣＵ１１０からの診断モード遷移指示を受信したローカルＥＣＵ１６０の制御部３６１に備えられたサービス実行管理は、アクチュエータサービス４２１を診断モードに遷移させ、グローバルサービスレジストリへのサービス利用要求を取り下げる。
【００９３】
次に、ステップＳ２１２において、ゲートウェイＥＣＵ１１０は、自身の制御部３１１が管理するグローバルサービスレジストリからアクチュエータサービス４２１が取り消されたことを利用して、アクチュエータサービス４２１が診断モードに遷移したことを判断する。
【００９４】
次に、ステップＳ２１３において、関連サービスが診断モードに遷移後、ゲートウェイＥＣＵ１１０は、サーバ２１０に対して診断サービスの問合せとして、診断サービス取得の要求を行う。ここで、診断サービスとは、新サービス４０１が正しく動作することを確認するテストを実施するサービスであり、例えば、新サービス４０１を開発する過程に利用するテストケースである。
【００９５】
具体的には、診断サービスは、センシングサービス４１１の代わりとなる、テストデータを生成するサービスと、アクチュエータサービス４２１の代わりとなる、テスト結果を判定するサービス、およびテストを管理するサービスを含む。
【００９６】
図１０Ａおよび図１０Ｂは、本発明の実施の形態１において、新サービス４０１をテストする際の入力となるテストデータ生成サービス４３１の構成を示す図である。図１０Ａは、前述したセンシングサービス４１１をメインとし、テストデータ生成サービス４３１をサブとして構成されたサービスである。通常モード時は、メインのサービスであるセンシングサービス４１１が使用され、センシングサービス４１１がプロバイドサービスインタフェース４１２を利用して、サービスを提供する。
【００９７】
一方、診断モード時は、センシングサービス４１１が利用するプロバイドサービスインタフェース４１２を利用して、サブであるテストデータ生成サービス４３１がサービスを提供する、なお、テストデータ生成サービス４３１は、後述するテスト管理サービス４５１のサービスを利用するためのリクエストサービスインタフェース４３３を備えても良い。
【００９８】
ここで、センシングサービス４１１をメインとし、テストデータ生成サービス４３１をサブとして構成されたサービスを含むサービスパッケージを、センシングサービスパッケージ４１５とする。
【００９９】
図１０Ｂは、前述したテストデータ生成サービス４３１のみで構成されたテスト入力サービスパッケージ４３０を示す図である。通常モード時は、図７Ａに示したセンシングサービス４１１が、サービスを提供する。一方、診断モード時は、図１０Ｂに示すテストデータ生成サービス４３１が、サービスを提供する。
【０１００】
これにより、センシングサービス４１１とテストデータ生成サービス４３１とを、独立した形で扱うことが可能となる。また、図１０Ｂにおいては、テストデータ生成サービス４３１をセンシングサービス４１１と同一のＥＣＵに配置する必要はなく、任意のＥＣＵに配置させることができる。
【０１０１】
ただし、テストデータ生成サービス４３１は、メインのサービスであるセンシングサービス４１１の代わりのサービス、つまり、ダミーのサービスである。そこで、テストデータ生成サービス４３１に関するサービスの識別子、およびプロバイドサービスインタフェースは、センシングサービス４１１と同一の構成とする。
【０１０２】
このように、テストデータ生成サービス４３１とセンシングサービス４１１とを同一の構成とすることで、センシングサービス４１１とテストデータ生成サービス４３１とが隠ぺいされる。この結果、新サービス４０１は、利用するサービスを意識する必要がなくなる。
【０１０３】
図１１Ａおよび図１１Ｂは、本発明の実施の形態１において、新サービス４０１をテストする際の出力結果からテスト結果を判定するサービスの構成を示す図である。図１１Ａは、前述したアクチュエータサービス４２１をメインとし、テスト結果判定サービス４４１をサブとして構成されたサービスである。通常モード時は、メインであるアクチュエータサービス４２１が、リクエストサービスインタフェース４２３を介して、新サービス４０１を利用する。
【０１０４】
一方、診断モード時は、アクチュエータサービス４２１が利用するリクエストサービスインタフェース４２３を介して、サブであるテスト結果判定サービス４４１が新サービス４０１を利用する、なお、テスト結果判定サービス４４１は、後述するテスト管理サービス４５１にサービスを提供するためのプロバイドサービスインタフェース４４２を備えても良い。
【０１０５】
ここで、アクチュエータサービス４２１をメインとし、テスト結果判定サービス４４１をサブとして構成されたサービスを含むサービスパッケージを、アクチュエータサービスパッケージ４２５とする。
【０１０６】
図１１Ｂは、前述したテスト結果判定サービス４４１のみで構成されたテスト出力サービスパッケージ４４０を示す図である。通常モード時は、図７Ｂに示したアクチュエータサービス４２１が、サービスを利用する。一方、診断モード時は、図１１Ｂに示すテスト結果判定サービス４４１が、サービスを利用する。
【０１０７】
これにより、アクチュエータサービス４２１とテスト結果判定サービス４４１とを、独立した形で扱うことが可能となる。また、図１１Ｂにおいては、テスト結果判定サービス４４１をアクチュエータサービス４２１と同一のＥＣＵに配置する必要はなく、任意のＥＣＵに配置させることができる。
【０１０８】
ただし、テスト結果判定サービス４４１は、メインのサービスであるアクチュエータサービス４２１の代わりのサービス、つまり、ダミーのサービスである。そこで、テスト結果判定サービス４４１に関するサービスを識別する識別子、およびリクエストサービスインタフェースは、アクチュエータサービス４２１と同一の構成とする。
【０１０９】
このように、アクチュエータサービス４２１とテスト結果判定サービス４４１とを同一の構成とすることで、アクチュエータサービス４２１とテスト結果判定サービス４４１とが隠ぺいされる。この結果、新サービス４０１は、提供するサービスを意識する必要がなくなる。
【０１１０】
図１２は、本発明の実施の形態１において、テストデータ生成サービス４３１およびテスト結果判定サービス４４１を管理するテスト管理サービスパッケージの構成を示す図である。テスト管理サービスパッケージ４５０は、テスト管理サービス４５１、リクエストサービスインタフェース４５２、プロバイドサービスインタフェース４５３、およびマニフェスト４５４によって構成されている。
【０１１１】
ここで、リクエストサービスインタフェース４５２は、テスト結果判定サービスよりテスト結果を取得するためのインタフェースである。また、プロバイドサービスインタフェース４５３は、テストデータ生成サービスへ指示を出すためのインタフェースである。さらに、マニフェスト４５４は、テスト管理サービスを実行管理するものである。
【０１１２】
テスト管理サービスパッケージ４５０は、例えば、車載ネットワーク１００全体のサービスを管理するゲートウェイＥＣＵ１１０に配置される。
【０１１３】
図８Ｂに戻り、通信システムの説明を続ける。ステップＳ２１４において、サーバ２１０は、ゲートウェイＥＣＵ１１０からの診断サービス要求に基づき、前述した新サービス４０１のテストに必要なサービスパッケージを検索する。そして、サーバ２１０は、検索結果として、例えば、センシングサービスパッケージ４１５、アクチュエータサービスパッケージ４２５、およびテスト管理サービスパッケージ４５０を診断サービスとして取得する。そして、サーバ２１０は、取得した診断サービスをゲートウェイＥＣＵ１１０へ転送する。
【０１１４】
次に、ステップＳ２１５において、ゲートウェイＥＣＵ１１０は、診断サービスのインストールを行う。具体的には、ゲートウェイＥＣＵ１１０は、サーバ２１０で取得したサービスパッケージの内、テスト管理サービスパッケージ４５０を補助記憶装置１２５に記憶させる。
【０１１５】
次に、ステップＳ２１６において、ゲートウェイＥＣＵ１１０は、診断サービスを起動する。具体的には、ゲートウェイＥＣＵ１１０は、補助記憶装置１２５に記憶されたテスト管理サービスパッケージ４５０のテスト管理サービス４５１を起動する。
【０１１６】
テスト管理サービス４５１は、起動が完了すると、グローバルサービスレジストリ、および各ローカルサービスレジストリに対して、サービス提供登録およびサービス利用登録を実施する。
【０１１７】
次に、ステップＳ２１７において、ゲートウェイＥＣＵ１１０は、診断サービスの転送を行う。具体的には、ゲートウェイＥＣＵ１１０は、サーバ２１０より取得したサービスパッケージの内、センシングサービスパッケージ４１５をローカルＥＣＵ１４０に転送する。
【０１１８】
より具体的には、ステップＳ２０４と同様に、ゲートウェイＥＣＵ１１０の制御部３１１は、マニフェスト４１４から、サービスの配置先を読み取る。本実施の形態１では、サービスの配置先は、ローカルＥＣＵ１４０である。そこで、ゲートウェイＥＣＵ１１０の通信部３１３は、センシングサービスパッケージ４１５をローカルＥＣＵ１４０に転送する。
【０１１９】
次に、ステップＳ２１８において、ローカルＥＣＵ１４０は、診断サービスのインストールを行う。具体的には、ローカルＥＣＵ１４０は、ゲートウェイＥＣＵ１１０から転送されてきたセンシングサービスパッケージ４１５を、補助記憶装置１４５に記憶させる。
【０１２０】
次に、ステップＳ２１９において、ローカルＥＣＵ１４０は、診断サービスの起動を行う。具体的は、ローカルＥＣＵ１４０は、補助記憶装置１４５に記憶されたセンシングサービスパッケージ４１５のテストデータ生成サービス４３１を起動する。
【０１２１】
テストデータ生成サービス４３１は、起動が完了すると、グローバルサービスレジストリ、および各ローカルサービスレジストリに対して、サービス提供登録およびサービス利用登録を実施する。
【０１２２】
次に、ステップＳ２２０において、ローカルＥＣＵ１４０は、ゲートウェイＥＣＵ１１０に対して、テストデータ生成サービス４３１が起動完了したことを通知する。通知する手法としては、例えば、ゲートウェイＥＣＵ１１０の制御部３１１において、グローバルサービスレジストリに登録されているサービスを検索し、テストデータ生成サービス４３１に関するサービスの有無から判断することが考えられる。
【０１２３】
次に、ステップＳ２２１において、ゲートウェイＥＣＵ１１０は、診断サービスの転送を行う。具体的には、ゲートウェイＥＣＵ１１０は、サーバ２１０より取得したサービスパッケージの内、アクチュエータサービスパッケージ４２５をローカルＥＣＵ１６０に転送する。
【０１２４】
より具体的には、ステップＳ２０４と同様に、ゲートウェイＥＣＵ１１０の制御部３１１は、マニフェスト４２４から、サービスの配置先を読み取る。本実施の形態１では、サービスの配置先は、ローカルＥＣＵ１６０である。そこで、ゲートウェイＥＣＵ１１０の通信部３１３は、アクチュエータサービスパッケージ４２５をローカルＥＣＵ１６０に転送する。
【０１２５】
次に、ステップＳ２２２において、ローカルＥＣＵ１６０は、診断サービスのインストールを行う。具体的には、ローカルＥＣＵ１６０は、ゲートウェイＥＣＵ１１０から転送されてきたアクチュエータサービスパッケージ４２５を、補助記憶装置１６５に記憶させる。
【０１２６】
次に、ステップＳ２２３において、ローカルＥＣＵ１６０は、診断サービスの起動を行う。具体的は、ローカルＥＣＵ１６０は、補助記憶装置１６５に記憶されたアクチュエータサービスパッケージ４２５のテスト結果判定サービス４４１を起動する。
【０１２７】
テスト結果判定サービス４４１は、起動が完了すると、グローバルサービスレジストリ、および各ローカルサービスレジストリに対して、サービス提供登録およびサービス利用登録を実施する。
【０１２８】
次に、ステップＳ２２４において、ローカルＥＣＵ１６０は、ゲートウェイＥＣＵ１１０に対して、テスト結果判定サービス４４１が起動完了したことを通知する。通知する手法としては、例えば、ゲートウェイＥＣＵ１１０の制御部３１１において、グローバルサービスレジストリに登録されているサービスを検索し、テスト結果判定サービス４４１に関するサービスの有無から判断することが考えられる。
【０１２９】
次に、ステップＳ２２５において、ゲートウェイＥＣＵ１１０は、ドメインコントローラＥＣＵ１２０に対して、追加サービスである新サービス４０１の起動を指示する。具体的には、ゲートウェイＥＣＵ１１０の制御部３１１は、新サービス４０１を起動するプロセス状態を初期化モードから通常モードに遷移させる。
【０１３０】
次に、ステップＳ２２６において、ドメインコントローラＥＣＵ１２０は、ゲートウェイＥＣＵ１１０からの新サービス４０１の起動指示に基づき、新サービス４０１の起動を開始する。新サービス４０１は、起動が完了すると、グローバルサービスレジストリおよび各ローカルサービスレジストリに対して、サービス提供登録およびサービス利用登録を実施する。
【０１３１】
次に、ステップＳ２２７において、ドメインコントローラＥＣＵ１２０は、サービス通信を確立する。具体的には、ドメインコントローラＥＣＵ１２０は、ローカルサービスレジストリに登録された、テストデータ生成サービス４３１と、新サービス４０１のテストデータ生成サービス４３１の利用要求とにより、サービス間の通信を確立する。
【０１３２】
同様に、ドメインコントローラＥＣＵ１２０は、サービスレジストリに登録された新サービス４０１と、テスト結果判定サービス４４１の利用要求とにより、サービス間の通信を確立する。
【０１３３】
ただし、テストデータ生成サービス４３１は、センシングサービス４１１のダミーのサービスであり、テスト結果判定サービス４４１は、アクチュエータサービス４２１のダミーのサービスである。従って、新サービス４０１の観点からみると、ステップＳ２２７におけるサービス通信が確立することで、通常のサービス間の通信が確立しているとみなされる。
【０１３４】
次に、ステップＳ２２８において、新サービス４０１は、センシングサービス４１１に対して、サービスを要求する。具体的には、新サービス４０１は、新サービス４０１のテストに必要なテストデータを要求する。なお、実態としては、新サービス４０１は、テストデータ生成サービス４３１に対して、サービスを要求することとなる。
【０１３５】
次に、ステップＳ２２９において、テストデータ生成サービス４３１は、新サービス４０１からのサービス利用要求を受けると、新サービス４０１のテストに必要なテストデータの生成を行う。テストデータは、例えば、新サービス４０１の開発過程で行う単体テストあるいはシステムテストに用いるデータとする。
【０１３６】
次に、ステップＳ２３０において、テストデータ生成サービス４３１は、新サービス４０１の要求に応え、テストデータを新サービス４０１に送信する。つまり、ローカルＥＣＵ１４０は、ドメインコントローラＥＣＵ１２０に対してテストデータを送信する。具体的には、テストデータ生成サービスのプロバイドサービスインタフェース４１２と新サービスのリクエストサービスインタフェース４０３を介して、サービス間の通信が行われることとなる。
【０１３７】
次に、ステップＳ２３１において、ドメインコントローラＥＣＵ１２０上に配置された新サービス４０１は、基本動作を実行する。具体的には、ドメインコントローラＥＣＵ１２０上に配置された新サービス４０１は、テストデータ生成サービスより送信されたテストデータを入力として、新サービス４０１の演算を実施する。
【０１３８】
次に、ステップＳ２３２において、ドメインコントローラＥＣＵ１２０は、新サービス４０１の演算結果を要求するアクチュエータサービス４２１に対して、演算結果を送信する。つまり、ドメインコントローラＥＣＵ１２０は、ローカルＥＣＵ１６０に対して、演算結果を送信する。なお、実態としては、ドメインコントローラＥＣＵ１２０は、テスト結果判定サービス４４１に対して、演算結果を送信する。
【０１３９】
具体的には、新サービス４０１のプロバイドサービスインタフェース４０２とテスト結果判定サービス４４１のリクエストサービスインタフェース４４３とを介して、サービス間の通信が行われることとなる。
【０１４０】
次に、ステップＳ２３３において、テスト結果判定サービス４４１は、新サービス４０１の演算結果が、期待値と一致するか否かを判定することでテスト判定を行う。期待値は、例えば、新サービス４０１の開発過程で行う単体テストあるいはシステムテストに用いる期待値としても良い。
【０１４１】
次に、ステップＳ２３４において、テスト結果判定サービス４４１は、テスト管理サービス４５１にテスト結果を送信する。つまり、ローカルＥＣＵ１６０は、ゲートウェイＥＣＵ１１０に対して、テスト結果を送信する。具体的には、テスト結果判定サービス４４１のプロバイドサービスインタフェース４４２とテスト管理サービス４５１のリクエストサービスインタフェース４５２とを介して、サービス間の通信が行われることとなる。
【０１４２】
次に、ステップＳ２３５およびステップＳ２３６に関しては、テスト結果がＦａｌｓｅ、つまり、新サービス４０１が異常な動作をした場合に実行される。
【０１４３】
ステップＳ２３５において、ゲートウェイＥＣＵ１１０は、ドメインコントローラＥＣＵ１２０に対して、新サービス４０１の削除を指示する。具体的には、ドメインコントローラＥＣＵ１２０の制御部３２１は、新サービス４０１を停止する。その後、制御部３２１は、補助記憶装置１２５に記憶されているサービスパッケージ４００を削除する。
【０１４４】
次に、ステップＳ２３６において、ドメインコントローラＥＵＣ１２０は、ゲートウェイＥＣＵ１１０に対して、新サービス４０１の削除が完了したことを通知する。具体的には、ゲートウェイＥＣＵ１１０は、自身の制御部３１１が管理するグローバルサービスレジストリから新サービス４０１の登録情報が削除されたことで、新サービス４０１が削除されたと判断する。
【０１４５】
テスト結果がＴｒｕｅ、つまり、新サービス４０１が正常な動作をした場合には、ステップＳ２３７において、ゲートウェイＥＣＵ１１０は、ローカルＥＣＵ１４０に対して、診断モードから通常モードに遷移させる指示を送信する。
【０１４６】
次に、ステップＳ２３８において、ローカルＥＣＵ１４０は、センシングサービス４１１を診断モードから通常モードに遷移させる。通常モードに遷移させる手法としては、前述したステップＳ２０８と同様の手法を採用することができる。
【０１４７】
センシングサービス４１１が通常モードに遷移すると、センシングサービス４１１は、グローバルサービスレジストリおよび各ローカルサービスレジストリに対して、センシングサービス４１１のサービス提供登録を行う。
【０１４８】
次に、ステップＳ２３９において、ローカルＥＣＵ１４０は、ゲートウェイＥＣＵ１１０に対して、センシングサービス４１１が、通常モードへ遷移完了したことを通知する。通知する手法としては、例えば、グローバルサービスレジストリにセンシングサービス４１１が登録されていることを利用することが考えられる。
【０１４９】
ステップＳ２４０〜ステップＳ２４２においても、前述したステップＳ２３７〜ステップＳ２３９と同様の手順で、アクチュエータサービス４２１が診断モードから通常モードに遷移される。
【０１５０】
次に、ステップＳ２４３において、ゲートウェイＥＣＵ１１０は、サーバ２１０に対して、ステップＳ２３４において取得した新サービス４０１のテスト結果を送信する。
【０１５１】
次に、ステップＳ２４４において、サーバ２１０は、テスト結果を基に、サーバ２１０上の補助記憶装置２１５で管理する車両情報を更新する。車両情報とは、例えば、各自動車に搭載されているソフトウェアの構成管理情報である。
【０１５２】
車両情報の更新は、具体的には、テスト結果がＴｒｕｅ、つまり、新サービス４０１が正常に追加できた場合には、車両情報に新サービス４０１を追加する。一方、テスト結果がＦａｌｓｅ、つまり、新サービス４０１が適切に動作しなかった場合には、車両情報の更新は行われない。
【０１５３】
次に、ステップＳ２４５において、サーバ２１０は、ゲートウェイＥＣＵ１０１に対して、車両情報の更新が完了したことを通知する。
【０１５４】
最後に、ステップＳ２４６において、ゲートウェイＥＣＵ１１０は、新サービスの追加手続きが全て完了したことを、ユーザ９００に通知する。ユーザ９００へ通知する手法としては、例えば、ゲートウェイＥＣＵ１１０にディスプレイのような出力装置を備え、ディスプレイ上に追加手続きが完了したことを表示させることが考えられる。
【０１５５】
以上のように、実施の形態１に係る通信システムは、自動車に新規に追加するサービスに対して、または、更新する既存のサービスに対して、車載ネットワーク上で正常に動作することを確認できる構成を備えている。このような構成を備えることで、更新または新規追加に相当する新サービスが正常に動作することを容易に確認し、保障することができる。
【０１５６】
なお、実施の形態１において、各制御装置（１１０、１２０、１３０、１４０、１５０、１６０、１７０）の機能は、ハードウェアで実現してもよい。図１３は、本発明の実施の形態１における各制御装置の機能がハードウェアで実現される場合の構成を示す図である。各制御装置は、処理回路５００を備える。処理回路５００は、プロセッシングサーキットともいう。処理回路５００は、各制御装置に備わる制御部（３１１、３２１、３３１、３４１、３５１、３６１、３７１）によって実行される機能を実現する専用の電子回路である。
【０１５７】
例えば、処理回路５００は、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ、ＡＳＩＣ、ＦＰＧＡまたはこれらの組み合わせである。ＧＡは、Ｇａｔｅ  Ａｒｒａｙの略称であり、ＡＳＩＣは、Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔの略称であり、ＦＰＧＡは、Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙの略称である。各制御装置は、処理回路５００を代替する複数の処理回路を備えてもよい。複数の処理回路は、処理回路５００の役割を分担する。
【０１５８】
上述した実施の形態１は、好ましい形態の例示であり、本発明の技術的範囲を制限することを意図するものではない。実施の形態１は、部分的に実施してもよいし、他の形態と組み合わせて実施してもよい。さらに、シーケンス図等を用いて説明した手順は、適宜に変更してもよい。
【符号の説明】
【０１５９】
１００  車載ネットワーク、１１０  ゲートウェイ、１１１、１２１、１３１、１４１、１５１、１６１、１７１、２１１  プロセッサ、１１２、１２２、１３２、１４２、１５２、１６２、１７２、２１２  タイマ、１１３、１２３、１３３、１４３、１５３、１６３、１７３  通信インタフェース、１１４、２１４  外部通信インタフェース、１１５、１２５、１３５、１４５、１５５、１６５、１７５、２１５  補助記憶装置、１１６、１２６、１３６、１４６、１５６、１６６、１７６、２１６  メモリ、１８０  通信バス、２００  外部ネットワーク、２１０  サーバ、２２０  公衆通信回線、３１１、３２１、３３１、３４１、３５１、３６１、３７１、３８１  制御部、３１２、３２２、３３２、３４２、３５２、３６２、３７２、３８２  カウンタ部、３１３、３２３、３３３、３４３、３５３、３６３、３７３  通信部、３１４、３８４  外部通信部、３１６、３２６、３３６、３４６、３５６、３６６、３７６、３８６  記憶部、４００  サービスパッケージ、４０１  サービス（新サービス）、４０２  プロバイドサービスインタフェース、４０３  リクエストサービスインタフェース、４０４  マニフェスト、４１０  センシングサービスパッケージ、４１１  センシングサービス、４１２  プロバイドサービスインタフェース、４１４  マニフェスト、４１５  センシングサービスパッケージ、４２０  アクチュエータサービスパッケージ、４２１  アクチュエータサービス、４２３  リクエストサービスインタフェース、４２４  マニフェスト、４２５  アクチュエータサービスパッケージ、４３０  テスト入力サービスパッケージ、４３１  テストデータ生成サービス、４３３  リクエストサービスインタフェース、４４０  テスト出力サービスパッケージ、４４１  テスト結果判定サービス、４４２  プロバイドサービスインタフェース、４４３  リクエストサービスインタフェース、４５０  テスト管理サービスパッケージ、４５１  テスト管理サービス、４５２  リクエストサービスインタフェース、４５３  プロバイドサービスインタフェース、４５４  マニフェスト、５００  処理回路、９００  ユーザ。
【図１】
2020141352.tif 000003
【図２】
2020141352.tif 000004
【図３】
2020141352.tif 000005
【図４】
2020141352.tif 000006
【図５】
2020141352.tif 000007
【図６】
2020141352.tif 000008
【図７Ａ】
2020141352.tif 000009
【図７Ｂ】
2020141352.tif 000010
【図８Ａ】
2020141352.tif 000011
【図８Ｂ】
2020141352.tif 000012
【図８Ｃ】
2020141352.tif 000013
【図８Ｄ】
2020141352.tif 000014
【図９】
2020141352.tif 000015
【図１０Ａ】
2020141352.tif 000016
【図１０Ｂ】
2020141352.tif 000017
【図１１Ａ】
2020141352.tif 000018
【図１１Ｂ】
2020141352.tif 000019
【図１２】
2020141352.tif 000020
【図１３】
2020141352.tif 000021
【手続補正書】
【提出日】令和2年3月26日(2020.3.26)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】変更
【補正の内容】
【０００９】
本発明に係る制御装置は、所望の機能を処理するソフトウェア要素であるサービスを有する複数のコントローラと、複数のコントローラを相互に接続するネットワークと
を備え、複数のコントローラのそれぞれは、ネットワークを介して複数のサービス間での通信制御を行うことでサービスの組み合わせによる所望の動作を実現する制御部を含み、制御部は、更新または新規追加に相当する新サービスが正常に動作するか否かの動作確認を実行するに当たり、サービスを起動するプロセス状態を、新サービスの通常動作を実行する通常モードから、通常動作を制限して新サービスの動作確認を実行するための診断モードに遷移させ、新サービスに対してサービスを提供する提供元サービス、および新サービスを利用する利用先サービスを特定し、診断モードにおいて、新サービス、提供元サービス、および利用先サービスにより構成される複数のサービス間で通信制御を行うことで、サービスの組み合わせによって所望の動作を実現するために動作確認を実行する制御装置であって、新サービスは、新サービスがサービス提供者である場合にはプロバイドサービスインタフェースが実装され、新サービスがサービス利用者である場合にはリクエストサービスインタフェースが実装され、新サービスがサービス提供者であり、かつサービス利用者である場合にはプロバイドサービスインタフェースとリクエストサービスインタフェースのそれぞれが実装されるとともに、新サービスが起動する条件が記載されたマニフェストを有して構成されているものである。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
所望の機能を処理するソフトウェア要素であるサービスを有する複数のコントローラと、
前記複数のコントローラを相互に接続するネットワークと
を備え、
前記複数のコントローラのそれぞれは、前記ネットワークを介して複数のサービス間での通信制御を行うことでサービスの組み合わせによる所望の動作を実現する制御部を含み、
前記制御部は、更新または新規追加に相当する新サービスが正常に動作するか否かの動作確認を実行するに当たり、
サービスを起動するプロセス状態を、前記新サービスの通常動作を実行する通常モードから、前記通常動作を制限して前記新サービスの前記動作確認を実行するための診断モードに遷移させ、
前記新サービスに対してサービスを提供する提供元サービス、および前記新サービスを利用する利用先サービスを特定し、
前記診断モードにおいて、前記新サービス、前記提供元サービス、および前記利用先サービスにより構成される前記複数のサービス間で通信制御を行うことで、サービスの組み合わせによって前記所望の動作を実現するために前記動作確認を実行する
制御装置であって、
前記新サービスは、
前記新サービスがサービス提供者である場合にはプロバイドサービスインタフェースが実装され、
前記新サービスがサービス利用者である場合にはリクエストサービスインタフェースが実装され、
前記新サービスがサービス提供者であり、かつサービス利用者である場合にはプロバイドサービスインタフェースとリクエストサービスインタフェースのそれぞれが実装される
とともに、前記新サービスが起動する条件が記載されたマニフェストを有して構成されている
制御装置。
【請求項２】
前記新サービスは、前記通常動作を行う際に使用されるメインのサービスと、前記診断モード時に使用され、前記通常動作が制限されたダミーのサービスとで構成されており、
前記メインのサービスと前記ダミーのサービスとは、同一の識別子および同一のインタフェースを有しており、
前記制御部は、前記診断モード時に前記ダミーのサービスを起動することで前記新サービスの前記動作確認を実行する
請求項１に記載の制御装置。
【請求項３】
前記複数のコントローラのうちの１以上のコントローラは、前記ネットワーク上に存在するそれぞれのサービスに関して、前記提供元サービスがサービス提供登録として登録され、前記利用先サービスがサービス利用登録として登録されたサービスレジストリをさらに有し、
前記複数のコントローラにおけるそれぞれの制御部は、前記サービスレジストリを参照することで、前記提供元サービスおよび前記利用先サービスを特定する
請求項２に記載の制御装置。
【請求項４】
前記提供元サービスは、前記新サービスに提供すべきデータに対応するテストデータをダミーのサービス内に有し、
前記提供元サービスを有するコントローラは、前記診断モードにおいて、前記新サービスを有するコントローラに対して前記テストデータを送信し、
前記利用先サービスは、前記テストデータに対応する期待値をダミーのサービス内に有し、
前記利用先サービスを有するコントローラに含まれている制御部は、前記新サービスを有するコントローラから前記テストデータを用いた演算結果を取得し、前記演算結果と前記期待値とが一致するか否かを示すテスト結果を出力する
請求項３に記載の制御装置。
【請求項５】
請求項４に記載の制御装置と、
前記制御装置に対して前記新サービスを提供するサーバと
を備え、
前記制御装置に含まれている前記複数のコントローラのうちの１つのコントローラは、公衆通信回線を介して前記サーバと通信可能に接続されるとともに、前記制御装置を統括制御するゲートウェイＥＣＵであり、
前記ゲートウェイＥＣＵは、
前記サーバから取得した前記新サービスに関する前記動作確認を、前記制御装置で実行させ、
前記動作確認を実行したことによる前記テスト結果として、前記演算結果と前記期待値とが一致することを示すテスト結果が得られた場合には、前記プロセス状態を、前記診断モードから前記通常モードに遷移させ、前記新サービスを用いた前記通常動作を開始させる
通信システム。