JP7124660B2 - 車載システム - Google Patents

Description

本開示は、システムに含まれる電子制御装置に対してアプリケーションを追加でインストール可能な車載システムに関する。

特許文献１には、複数の情報処理装置を含み、プログラムを追加でインストール可能なインストールシステムが開示されている。プログラムには、インストールシステムに含まれる特定の情報処理装置がインストール対象としてあらかじめ設定されている。特許文献１のインストールシステムは、システムに含まれるある情報処理装置に対する操作に基づいて、インストール対象として設定された特定の情報処理装置にプログラムをインストールする。

特開２０１４－１７８９９８号公報

複数の情報処理装置を含むシステムである車載システムにおいて、アプリケーションを追加でインストール可能とする構成が検討されている。しかし、車載システムに含まれる個別の情報処理装置で利用可能なリソースは、車両の構成や利用状況などに従い、車両によって異なる場合がある。故に、車載システムに含まれる特定の情報処理装置にアプリケーションをインストールする構成の場合、アプリケーションの利用可能なリソースが、インストール先となる特定の情報処理装置で提供可能な提供リソースにより制限されうる。従って、インストールされたアプリケーションの性能が低下するおそれがあった。

本開示は、追加でインストールするアプリケーションの性能低下を抑制可能な車載システムの提供を目的とする。

上記目的は独立請求項に記載の特徴の組み合わせにより達成され、また、下位請求項は、本開示の更なる有利な具体例を規定する。特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本開示の技術的範囲を限定するものではない。

上記目的を達成するための本開示の車載システムは、アプリケーションをインストール可能な複数の情報処理装置（１００）を備え、車両で用いられる車載システムであって、アプリケーションを取得するアプリ取得部（１１０）と、アプリ取得部で取得されたアプリケーションの要求する要求リソースを特定する要求特定部（１３０）と、各情報処理装置で提供可能な提供リソースのそれぞれを特定するリソース特定部（１２０）と、提供リソースが要求リソースを満たしている情報処理装置を、アプリケーションのインストール先として選択する選択部（１４０）と、を備え、リソース特定部は、車両の稼動状態を区別して提供リソースを特定し、要求特定部は、アプリケーションの実行が想定される稼動状態を特定し、選択部は、実行の想定される稼動状態に対応した提供リソースが、要求リソースを満たしている情報処理装置を選択する。

以上の構成によれば、追加アプリの要求する要求リソース、および各情報処理装置の提供可能な提供リソースが、要求特定部およびリソース特定部により特定される。選択部は、複数の情報処理装置のうち、提供リソースが要求リソースを満たす情報処理装置を追加アプリのインストール先として選択する。故に、選択された情報処理装置にインストールされたアプリは、要求するリソースをインストールされた情報処理装置から提供されて作動可能となる。従って車載システムは、追加されたアプリの性能低下を抑制可能となる。

車載システムの構成を示すブロック図である。 インストール割り当てアプリの作動例を示すフローチャートである。 インストール割り当てアプリの通信手順を示すシーケンス図である。 追加アプリの作動例を示すフローチャートである。 追加アプリの通信手順を示すシーケンス図である。

本開示の実施形態による車載システム１０は、図１に示すように、車両１に搭載された複数のＥＣＵ１００を含んで構築されたシステムである。車載システム１０は、車両１に設けられた各種のセンサ、アクチュエータ、およびユーザインタフェースなどを統合的に制御する制御システムとして用いられている。車載システム１０は、中継装置２０を上述した複数のＥＣＵ１００に加えて備えている。

中継装置２０は、各ＥＣＵ１００の間の通信を中継する、いわゆるスイッチングハブとして機能する装置である。中継装置２０には、ＥＣＵ１００や他の中継装置２０と接続するためのポートが複数設けられている。ポートの各々は、ツイストペアケーブルなどの通信ケーブルによりＥＣＵ１００や他の中継装置２０のいずれか一つと接続されている。すなわち中継装置２０は、自身を中心とするスター型のネットワーク構成となるように各ＥＣＵ１００を接続している。

中継装置２０は、各ＥＣＵ１００や中継装置２０のそれぞれに設定された固定アドレスに基づいて通信を中継する。固定アドレスは、例えばＩＰアドレスなどの、車載システム１０内において各装置を一意に識別可能に割り当てられた、原則として変更しないアドレスである。中継装置２０は、例えばＥｔｈｅｒｎｅｔ（登録商標）の通信プロトコルに従って通信を中継する。

各ＥＣＵ１００は、例えばソフトウェアを記憶する記憶装置、ソフトウェアを実行するプロセッサ１０１、および入出力インターフェースなどを備えたマイクロコンピュータを主体とする電子制御装置である。記憶装置は、例えば半導体記憶装置などにより提供される。各ＥＣＵ１００は、記憶装置として、主記憶装置（以下、メモリ）と、補助記憶装置（以下、ストレージ）とを有する。メモリ１０２は、実行中のソフトウェアやそれに関連するデータを一時的に格納する。ストレージ１０３は、実行中でないものを含めたソフトウェアやデータを非一時的に記憶している、非遷移的かつ実体的な記憶媒体である。

各ＥＣＵ１００は、ストレージ１０３に記憶されたソフトウェアをメモリ１０２に読み込んでプロセッサ１０１に実行させることにより、ソフトウェアに対応した機能を発揮する。各ＥＣＵ１００のストレージ１０３には、ＥＣＵ１００ごとに異なるアプリケーションソフトウェア（以下、アプリ）と、各ＥＣＵ１００の間で共通のプラットフォームソフトウェア（以下、プラットフォーム）とがあらかじめ記憶されている。アプリは、プラットフォームソフトウェア上で実行されるソフトウェアである。各ＥＣＵ１００のストレージ１０３にあらかじめ記憶されたアプリには、固有アプリが含まれている。固有アプリは、そのＥＣＵ１００の入出力インターフェースに接続された固有のセンサやアクチュエータなどと協働した処理により、そのＥＣＵ１００に固有の機能を提供する。

プラットフォームは、アプリの実行環境を提供するためのソフトウェアである。プラットフォームは、オペレーティングシステム（以下、ＯＳ）、またはＯＳとミドルウェアとのセットを示す。

ＯＳは、ミドルウェアおよびアプリに対して各種の演算処理などの基本機能を提供し、ミドルウェアおよびアプリを実行させるソフトウェアである。ミドルウェアは、ＯＳ上で実行され、ＯＳからアプリに提供される機能を拡張するソフトウェアである。ミドルウェアは、例えば他のＥＣＵ１００との通信に係る一連の演算処理をパッケージとした通信機能など、汎用的な拡張機能をアプリに提供する。すなわちプラットフォームは、アプリに対して提供可能な機能のセットを定義するソフトウェアと言うこともできる。各ＥＣＵ１００で共通のプラットフォームを実行させることにより、アプリに対して提供可能な機能の種類が各ＥＣＵ１００の間で共通化される。

各ＥＣＵ１００で実行される共通のプラットフォームは、インストール部１０４および通信部１０５としての機能とを提供している。インストール部１０４は、受信したアプリのインストールファイルをストレージ１０３に格納し、インストールファイルの展開により自身に対するアプリのインストールを行う。

通信部１０５は、サービス指向の通信プロトコルに従う通信を提供する。サービス指向の通信プロトコルは、例えばＳＯＭＥ／ＩＰ（Scalable Service-Oriented Middleware on Ethernet/IP）や、ＤＤＳ（Data Distribution Service for Real-time Systems）に定義された仕様を利用可能である。サービスは、相互に呼び出しおよび応答可能なインターフェースを通信プロトコルにおいてあらかじめ定義された、アプリの処理の一構成単位を示す。

サービスには、配信サービスと、受付サービスとが含まれる。配信サービスは、定期的に、または所定のイベント発生時に、アプリの処理の結果としてのデータを配信するサービスである。受付サービスは、コマンドを受付して、コマンドに対応したアプリの処理を実行するサービスである。車載システム１０においては、配信サービスとして、例えば車速を示すデータを定期的に配信するサービスや、ユーザによるシフト操作イベント発生の通知するデータを配信するサービスなどが定義されている。また受付サービスとして、例えば座席やトランクルームのドアロックの開錠、施錠コマンドを受付するサービスなどが定義されている。

共通するプラットフォームを実行させている各ＥＣＵ１００は、そのＥＣＵ１００の提供するサービスと、固定アドレスとのセットを、所定のタイミングで互いに通知する。各ＥＣＵ１００は、通知された配信サービスの受信をアプリが求めた場合には、通知元の固定アドレスに対して、購読の申し込みと自身の固定アドレスとを返信する。申し込みを受けた配信サービスは、申し込みを返信した固定アドレスに対して配信サービスを行う。

各ＥＣＵ１００は、通知された受付サービスの利用をアプリが求めた場合には、通知された受付サービスと固定アドレスとのセットを記憶する。各ＥＣＵ１００は、アプリが受付サービスの利用を求めた場合に、記憶したセットに従い、サービスを固定アドレスに読み替えて通信を行う。この結果、各ＥＣＵで実行されるアプリは、通信相手となるＥＣＵ１００の固定アドレスをあらかじめ特定されていなくても、サービスの種類に従って通信相手を特定可能となる。

このように、本実施形態のいずれのＥＣＵ１００においても、アプリは共通の基本機能および拡張機能を提供されるとともに、車載システム１０内で提供される任意のサービスと連携しうる。故に、あるアプリをこうした各ＥＣＵ１００のいずれにインストールした場合においても、インストールされたアプリは理想的には正常に実行されて動作しうる。従って、これらのＥＣＵ１００のそれぞれが、アプリを追加でインストール可能な「情報処理装置」に相当している。なお、上述したサービス指向の通信プロトコルを用いて各ＥＣＵ１００の機能を連携させることによりシステムを構築する手法は、サービス指向アーキテクチャと称される場合がある。

本実施形態の車載システム１０は、上述したＥＣＵ１００として、統合ＥＣＵ１００ａ、走行制御ＥＣＵ１００ｂ、運転支援ＥＣＵ１００ｃ、トランクＥＣＵ１００ｄ、ボデーＥＣＵ１００ｅ、およびゲートウェイＥＣＵ１００ｆを含んでいる。

統合ＥＣＵ１００ａは、固有アプリの実行により、車両１の状態を統合的に管理する機能を発揮する装置である。統合ＥＣＵ１００ａは、例えば車輪速センサや加速度センサ、ＧＮＳＳロケータなどと協働し、車両１の車速や加速度、位置などを逐次取得する機能を発揮する。統合ＥＣＵ１００ａは、取得した車速や加速度、位置などのそれぞれについて、定期的に通知する配信サービスを提供する。

走行制御ＥＣＵ１００ｂは、固有アプリの実行により、車両１の走行を制御する機能を発揮する装置である。走行制御ＥＣＵ１００ｂは、アクセルポジションセンサやブレーキ踏力センサ、操舵角センサなどと協働し、ユーザによる運転操作を取得する。走行制御ＥＣＵ１００ｂは、電子スロットルやブレーキアクチュエータ、ＥＰＳ（Electric Power Steering）モータなどと協働し、取得した運転操作に従う加減速や操舵を実行する。走行制御ＥＣＵ１００ｂは、加減速や操舵を要求するコマンドを受け付ける受付サービスを提供する。走行制御ＥＣＵ１００ｂは、例えば受け付けたコマンドに基づき、ユーザによる運転操作に従って決定した加減速量や操舵量を補正して実行する。

運転支援ＥＣＵ１００ｃは、固有アプリの実行により、レーンキーピングアシスト、アダプティブクルーズコントロール、またはいわゆる自動運転などのユーザに対する運転支援機能を発揮する装置である。運転支援ＥＣＵ１００ｃは、運転支援を実行する条件が成立している場合、カメラやソナー、ライダなどの車両１周辺の状況を監視する周辺監視装置と協働して車両１の周辺状況を認識する。運転支援ＥＣＵ１００ｃは、認識した周辺状況や、統合ＥＣＵ１００ａからの車速、加速度、および位置などに従って加減速や操舵を要求するコマンドを生成し、コマンドに対応する受付サービスを提供するＥＣＵ１００に送信する。

トランクＥＣＵ１００ｄは、固有アプリの実行により、車両１のトランクルームの開閉を制御する装置である。トランクＥＣＵ１００ｄは、トランクルームのドアロックを駆動するドアロックモータと協働し、トランクルームを開錠および施錠する機能を発揮する。トランクＥＣＵ１００ｄは、トランクルームの施錠および開錠コマンドを受け付ける受付サービスを提供する。

ボデーＥＣＵ１００ｅは、固有アプリの実行により、車両１のドアに設けられたドアロックなどの車体に設けられた装備の制御機能を発揮する装置である。ボデーＥＣＵ１００ｅは、車室内や車外の電子キーと通信可能な無線通信機、および車体の各所に設けられたボタンなどと協働し、ユーザからの装備の操作要求の検知、および操作要求の承認を行う。ボデーＥＣＵ１００ｅは、承認した操作要求に対応した施錠、開錠コマンドなどを生成し、コマンドに対応する受付サービスを提供するＥＣＵ１００に送信する。

ボデーＥＣＵ１００ｅは、機能の関連性の高いＥＣＵ１００と同一の中継装置２０に接続され、中継装置２０を中心とするグループを形成している。具体的には、ボデーＥＣＵ１００ｅは、トランクＥＣＵ１００ｄなどと同一の中継装置２０に接続されている。

ゲートウェイＥＣＵ１００ｆは、固有アプリの実行により、車載システム１０の外部との接続機能を発揮する装置である。ゲートウェイＥＣＵ１００ｆは、例えば無線通信機と協働し、無線基地局および公衆通信回線網を介した通信により、データセンタに設けられたサーバ装置などと接続する機能を発揮する。ゲートウェイＥＣＵ１００ｆは、例えば車載システム１０の外部へのメッセージと、外部への送信コマンドを受け付ける受付サービスを提供する。またゲートウェイＥＣＵ１００ｆは、外部からのメッセージ受信イベント発生の通知と、そのメッセージの転送を行う配信サービスを提供する。

ゲートウェイＥＣＵ１００ｆのストレージ１０３には、インストール割り当てアプリが記憶されている。ゲートウェイＥＣＵ１００ｆは、インストール割り当てアプリの実行により、アプリ取得部１１０、要求特定部１３０、リソース特定部１２０、および選択部１４０としての機能を発揮する。なお、インストール割り当てアプリの実行によりゲートウェイＥＣＵ１００ｆの発揮する機能の一部または全部が、一つまたは複数のＩＣによる論理回路などによりハードウェア的に実現される構成でもよい。

アプリ取得部１１０は、車載システム１０に含まれるＥＣＵ１００のいずれかに追加でインストールする追加アプリを、車載システム１０の外部から取得する。アプリ取得部１１０は、例えばゲートウェイＥＣＵ１００ｆの通信機能により、サーバ装置から追加アプリのインストールファイルを取得する。

リソース特定部１２０は、各ＥＣＵ１００で提供可能なリソースを示す提供リソースを特定する。リソースは、各ＥＣＵ１００においてアプリに割り当てられるハードウェア資源を示す。リソースは、例えばプロセッサ１０１の空き時間、メモリ１０２の空き容量、ストレージ１０３空き容量、ネットワークにアクセス可能な時間、通信可能なサービスなどで表すことができる。

リソース特定部１２０は、各ＥＣＵ１００との通信により、リソース情報を所定のタイミングで収集する。リソース情報は、提供リソースの算出を可能とするデータである。例えばプロセッサ１０１の使用率（いわゆるＣＰＵ利用率）、メモリ１０２使用率、クロック周波数、ストレージ１０３空き容量、ネットワーク利用率、およびサービスの提供数や利用数などをリソース情報として用いることができる。リソース特定部１２０は、収集したリソース情報に基づいて提供リソースを特定する。

本実施形態のリソース特定部１２０は、車両１の稼動状態を走行状態、停車状態、駐車状態の三つの状態に区別し、稼動状態ごとに各ＥＣＵ１００の提供リソースを特定する。またリソース特定部１２０は、車両１の稼動状態が走行状態である場合には、稼動状態が停車状態となるまでリソース情報の収集を待機する。走行状態は、車両１が走行している状態である。走行状態は、例えば車速が時速１ｋｍ以上などの所定の走行速度閾値以上となっている状態として設定されている。

停車状態は、車両１が走行を停止し、かつユーザが車両に留まっている状態を示す。停車状態は、例えば車速が走行速度閾値未満であり、かつアクセサリ電源オンまたはイグニッションオンである状態として設定されている。停車状態においては、走行状態と比較して走行に関与する固有アプリや通信による各ＥＣＵ１００やネットワークの負荷が低下する傾向にある。従って停車状態においては、走行状態と比較して各ＥＣＵ１００の提供リソースが増大する傾向にある。

駐車状態は、車両が走行を停止し、かつユーザが車両を離れうる状態である。駐車状態は、例えば車両１がアクセサリ電源を含めオフとなっている状態として設定されている。駐車状態においては、車載システム１０に含まれるＥＣＵ１００の一部が、電源を供給されていない電源断状態となっている。この結果、一部のＥＣＵ１００では電源断状態に伴い提供リソースがゼロとなる。例えば、運転支援ＥＣＵ１００ｃや走行制御ＥＣＵ１００ｂなどの走行に係るＥＣＵ１００が、電源断状態に伴い提供リソースがゼロの状態となっている。また、駐車状態においては、消費電力を走行状態および停車状態よりも軽減する省電力状態となっているＥＣＵ１００が存在しうる。従って駐車状態では、停車状態よりも提供リソースが制限される傾向にある。

要求特定部１３０は、アプリ取得部１１０で取得された追加アプリの要求するリソースである要求リソースを特定する。要求特定部１３０は、例えば追加アプリのインストールファイルに付属したアプリの実行環境を指定する情報を読み込むことにより要求リソースを特定する。実行環境を指定する情報としては、例えば実行の想定される車両１の稼動状態、プロセッサ１０１のクロック周波数、実行された場合のプロセッサ１０１やメモリ１０２の使用率、インストールに要するストレージ１０３空き容量、ネットワーク利用率などがあらかじめ設定されている。

追加アプリとして宅配トランクアプリを取得した場合を例に、要求リソースの設定を説明する。宅配トランクアプリは、自宅で駐車中の車両１のトランクルームを、宅配ボックス、すなわち宅配された荷物の受付スペースとして利用可能とするためのアプリである。宅配トランクアプリは、ＥＣＵ１００で実行されることにより、車両の外部からの宅配トランク要求コマンドを受け付け、トランクルームのドアロックを制御する機能を発揮する。

宅配トランクアプリは、車両１が駐車状態である場合に実行されるアプリである。従って宅配トランクアプリの要求リソース情報には、駐車状態における要求リソースが設定されている。具体的には、駐車状態におけるプロセッサ１０１やメモリ１０２の利用率が要求リソース情報として設定されている。また、駐車状態において、トランクルームの開錠および施錠コマンドの受付サービスへとの通信が提供されるＥＣＵ１００をインストール先とするように要求リソース情報が設定されている。

選択部１４０は、アプリ取得部１１０の取得したアプリのインストール先となるＥＣＵ１００を選択する。選択部１４０は、各ＥＣＵ１００のうち、提供リソースが要求リソースを満たしているＥＣＵ１００を、アプリのインストール先として選択する。選択部１４０はリソース特定部１２０で特定された提供リソースのうち、追加アプリの作動する稼動状態に対応する提供リソースに基づいてインストール先を選択する。すなわち、追加アプリの作動する稼動状態に対応する提供リソースが、要求リソースを満たしているＥＣＵ１００を選択する。

選択部１４０は、要求リソースを満たすＥＣＵ１００が複数存在する場合には、あらかじめ設定された選択の指針に基づいてインストール先を選択する。例えば選択部１４０は、プロセッサ１０１またはメモリ１０２の使用率の最も低いＥＣＵ１００、あるいはストレージ１０３空き容量の大きいＥＣＵ１００を優先して選択する。また選択部１４０は、追加アプリの利用するサービスを提供するＥＣＵ１００とネットワーク上で近接したエリアに位置するＥＣＵ１００を優先してもよい。すなわち、通信にあたって経由する中継装置２０の少ないＥＣＵ１００を優先してもよい。選択部１４０は、インストール先として選択されたＥＣＵ１００に対してアプリ取得部１１０の取得したインストールファイルを転送する。また選択部１４０は、追加アプリのインストールの成否をサーバ装置に通知する。

［インストール割り当てアプリの作動］
インストール割り当てアプリの作動例を、図２および図３に沿って説明する。ゲートウェイＥＣＵ１００ｆで実行されたインストール割り当てアプリは、サーバ装置から追加アプリを配信された場合に、図２のフローチャートに示す処理をＳ１０１から実行する。

Ｓ１０１では、統合ＥＣＵ１００ａから送信される車速を受信する。Ｓ１０２では、Ｓ１０１で受信した車速に基づいて、車両１が停止しているか否かを判断する。車両１が停止している場合はＳ１０３に進み、停止していない場合にはＳ１０１に戻る。

Ｓ１０３では、各ＥＣＵ１００に対して、リソース情報の送信を要求する。Ｓ１０４では、各ＥＣＵから送信されたリソース情報を受信する。

Ｓ１０５では、Ｓ１０４で受信したリソース情報から各ＥＣＵ１００の提供リソースを特定すると共に、追加アプリの要求リソースを特定する。Ｓ１０６では、要求リソースを満たす提供リソースとなっているＥＣＵ１００から、インストール先となるＥＣＵ１００を選択する。

Ｓ１０７では、Ｓ１０６でインストール先を選択できているか否かを判断する。選択できている場合にはＳ１０８に進み、選択できていない場合にはＳ１０９に進む。Ｓ１０８では、Ｓ１０６で選択したインストール先のＥＣＵ１００に追加アプリを転送する。

Ｓ１０９では、インストールの結果、すなわちインストールが成功したか否かをサーバに通知し、インストール割り当てアプリの作動を終了する。

インストール割り当てアプリの作動に伴うリソース情報収集のための通信例を図３のシーケンス図に示す。ゲートウェイＥＣＵ１００ｆは、事前に統合ＥＣＵ１００ａからの車速の配信サービスの通知に対して申し込みを行っている。

Ｓ２０１に、事前の申し込みにより、統合ＥＣＵ１００ａはゲートウェイＥＣＵ１００ｆに対して速度の定期的な配信を行っている。

Ｓ２０２に、サーバ装置がゲートウェイＥＣＵ１００ｆに対してアプリの配信を行うことにより、ゲートウェイＥＣＵ１００ｆはインストール割り当てアプリに係る処理を開始する。

Ｓ２０３に、再び統合ＥＣＵ１００ａがゲートウェイＥＣＵ１００ｆに対して速度の定期的な配信を行う。ゲートウェイＥＣＵ１００ｆは、車両１が走行状態であると判断したことにより、リソース情報の要求を行わず待機する。

Ｓ２０４に、再び統合ＥＣＵ１００ａがゲートウェイＥＣＵ１００ｆに対して速度の定期的な配信を行う。ゲートウェイＥＣＵ１００ｆは、車両１が停車状態であると判断したことにより、Ｓ２０５にリソース情報の送信を各ＥＣＵ１００に対して要求する。

Ｓ２０６、Ｓ２０７、Ｓ２０８、Ｓ２０９、およびＳ２１０に、各ＥＣＵ１００がそれぞれゲートウェイＥＣＵ１００ｆに対してリソース情報を提供する。

受信したリソース情報に基づく提供リソースを用いてインストール先を選択したゲートウェイＥＣＵ１００ｆは、Ｓ２１１にアプリをボデーＥＣＵ１００ｅに転送する。Ｓ２１２に、ゲートウェイＥＣＵ１００ｆは、インストールの成功をサーバ装置に通知する。

［追加アプリの作動］
選択されたＥＣＵ１００にインストールされた追加アプリの作動例を図４および図５に沿って説明する。インストールされた追加アプリは、実行されると図４のフローチャートに示す処理をＳ３０１から実行する。

Ｓ３０１では、車載システム１０の他のサービスとの提携処理、すなわち提供するサービスの相互通知が完了しているか否かを判断する。完了している場合にはＳ３０６に進み、完了していない場合はＳ３０２に進む。

Ｓ３０２では、追加アプリが利用する、換言すれば享受するサービスがあるか否かを判断する。利用するサービスがある場合にはＳ３０３に進み、ない場合にはＳ３０４に進む。

Ｓ３０３では、利用するサービスを提供しているＥＣＵ１００の探索を行う。具体的には、各ＥＣＵ１００に対し、利用するサービスを提供しているか否かの問い合わせを行い、提供している場合には返信を要求する。

Ｓ３０４では、追加アプリの提供するサービスがあるか否かを判断する。追加アプリの提供するサービスがある場合にはＳ３０５に進み、ない場合にはＳ３０６に進む。

Ｓ３０５では、追加アプリの提供するサービスの通知を行う。具体的には、追加アプリの提供するサービスの利用を希望するか否かを各ＥＣＵ１００に対して問い合わせする。提供するサービスが配信サービスである場合には、申し込みの返信要求も行う。Ｓ３０６では、追加アプリの機能に係る処理の実行を開始する。

追加アプリの通信例を図５のシーケンス図に示す。ボデーＥＣＵ１００ｅに対して、追加アプリとして宅配トランクアプリがインストールされた場合を例に説明する。

Ｓ４０１に、ボデーＥＣＵ１００ｅで実行された宅配トランクアプリは、サービスの探索を行う。宅配トランクアプリは、利用するサービスであるトランクルームの施錠および開錠コマンドの受付サービスを探索する。

Ｓ４０２に、トランクルームの施錠および開錠コマンドの受付サービスを提供するトランクＥＣＵが、サービスの提供を通知する返信を行う。

Ｓ４０３に、宅配トランクアプリは、自身の提供する宅配トランク要求コマンドの受付サービスを各ＥＣＵに通知する。

Ｓ４０４に、サーバ装置からゲートウェイＥＣＵ１００ｆに対して宅配トランク要求コマンドが送信される。Ｓ４０５に、ゲートウェイＥＣＵ１００ｆは、Ｓ４０３のサービス通知に基づいて受信した宅配トランク要求コマンドをボデーＥＣＵ１００ｅに通知する。

Ｓ４０６に、ボデーＥＣＵ１００ｅは、Ｓ４０２で返信を受けた受付サービスの提供先に基づいて、トランクルームの開錠コマンドをトランクＥＣＵ１００ｄに送信する。

［実施形態のまとめ］
以上、説明した実施形態によれば、追加アプリの要求する要求リソース、および各ＥＣＵの提供可能な提供リソースが、要求特定部１３０およびリソース特定部１２０により特定される。選択部１４０は、複数のＥＣＵ１００のうち、提供リソースが要求リソースを満たすＥＣＵ１００を追加アプリのインストール先として選択する。故に、選択されたＥＣＵ１００にインストールされたアプリは、要求するリソースをインストールされたＥＣＵ１００から提供されて作動可能となる。従って車載システム１０は、追加されたアプリの性能低下を抑制可能となる。

また本実施形態では、リソース特定部１２０は各ＥＣＵ１００との通信によりリソース情報を収集し、収集したリソース情報に基づいて提供リソースを特定する。故にリソース特定部１２０は、各ＥＣＵ１００の提供リソースが経時的に変化した場合であっても、変化した提供リソースを特定可能となる。この結果、選択部１４０は、各ＥＣＵ１００の提供リソースが経時的に変化する場合においても、提供リソースが要求リソースを満たしているＥＣＵ１００をインストール先として選択しうる。従って車載システム１０は、追加されたアプリケーションの性能低下をより抑制可能となる。

さらに本実施形態では、リソース特定部１２０は、車両１の稼動状態が走行状態である場合には、停止状態となるまでリソース情報の収集を停止する。ここで、車載システム１０におけるネットワーク利用率、および各ＥＣＵ１００のプロセッサ１０１やメモリ１０２の使用率は、車両の走行中よりも停止中において小さくなると見込まれる。故に、車両１の停止まで提供リソースの収集を待機する構成によれば、提供リソースの収集にあたってネットワークや各ＥＣＵ１００に生じる負荷が、車載システム１０で提供する他の機能に係る負荷と競合しにくい。故に、車載システム１０で提供する他の機能の性能低下を抑制して、リソース情報を収集可能となる。

加えて本実施形態では、リソース特定部１２０は、車両１の稼動状態を区別して、稼動状態ごとに提供リソースを特定する。また、要求特定部１３０は、追加アプリの実行される車両の稼動状態を特定する。選択部１４０は、稼動状態ごとの提供リソースのうち、追加アプリの実行される稼動状態に対応した提供リソースが、要求リソースを満たすＥＣＵ１００をインストール先として選択する。故に追加アプリは、車両１の稼動状態変化に従い各ＥＣＵ１００の提供リソースが変動する場合においても、提供リソースが要求リソースを満たしているＥＣＵ１００をインストール先として選択されうる。従って車載システム１０は、追加されたアプリケーションの性能低下をさらに抑制可能となる。

＜他の実施形態＞
以上、本開示の実施形態を説明したが、本開示は上述の実施形態に限定されるものではなく、次の変形例も本開示の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施できる。なお、以下の説明において、それまでに使用した符号と同一番号の符号を有する要素は、特に言及する場合を除き、それ以前の実施形態における同一符号の要素と同一である。また、構成の一部のみを説明している場合、構成の他の部分については先に説明した実施形態を適用できる。

上述の実施形態においては、ゲートウェイＥＣＵ１００ｆが、アプリ取得部１１０や要求特定部１３０、リソース特定部１２０などのアプリケーションソフトウェアのインストール先を選択するための機能を発揮していた。しかし、これらの機能は、車載システム１０に含まれるいずれのＥＣＵ１００において発揮されていてもよく、また複数のＥＣＵ１００で分担されていてもよい。さらに、いずれのＥＣＵ１００において発揮される場合であっても、機能の一部または全部がハードウェア的に構成されていてもよい。

上述の実施形態においては、車載システム１０は、機能に関連性のある複数のＥＣＵをグループとして中継装置２０を中心とするスター型に接続し、各グループを中継装置２０同士の接続により結合したネットワーク構成であった。しかし、車載システム１０のネットワーク構成や各ＥＣＵ１００の担う機能はこれに限られず、適宜変更可能である。例えば車載システム１０は、いわゆるバス型を中心としてグループ内を接続するネットワーク構成とすることができる。また車載システム１０は、グループ間の通信を、中継装置２０ではなくグループ内のいずれかのＥＣＵ１００で中継する構成を採用してもよい。

さらに車載システム１０は、各ＥＣＵの間について、スター型に接続すると共にバス型にも接続するなど、複数の接続経路を提供するネットワーク構成となっていてもよい。また、ネットワーク上に、サービス指向の通信プロトコルに対応せず、固定アドレスに従って通信先を特定する通信プロトコルにのみ対応したＥＣＵが部分的に存在する構成でもよい。

上述の実施形態においては、リソース特定部１２０は、稼動状態ごとに、各ＥＣＵに対して一つの提供リソースを特定していた。すなわち、各ＥＣＵの既存のアプリケーションの機能を制限しない状態で提供可能なリソースを提供リソースとして特定していた。しかし、既存のアプリケーションに自身の機能の制限を許容しているアプリケーションが含まれていれば、その機能を制限した場合に提供可能な提供リソースについても特定することができる。こうした場合、選択部１４０は、機能を制限しない状態での提供リソースで要求リソースを満たすＥＣＵが存在しなければ、機能を制限した状態での提供リソースを満たすＥＣＵをインストール先として選択する構成とすることができる。

上述の実施形態においては、車両１の稼動状態は、三つの状態に分けられていた。しかし、車両１の稼動状態は、区分されていなくてもよく、三つ以外の数に区分されてもよい。例えば、車速などに基づいて、走行状態をさらに高速走行状態と低速走行状態とに区分してもよい。また、車両の稼動状態を判断する基準は適宜変更可能である。例えば、走行状態であるかの判断は、シフトポジションや、パーキングブレーキの作動状態などに基づいて行ってもよい。

上述の実施形態においては、リソース特定部１２０は、各ＥＣＵ１００との通信によりリソース情報を収集して提供リソースを特定していた。しかし、リソース特定部１２０は、テーブルなどの形であらかじめストレージ１０３に記憶した提供リソースを各ＥＣＵ１００の提供リソースとして用いる構成でもよい。例えばリソース特定部１２０は、経時的な変動の実質的に生じない提供リソースを参照する場合、あらかじめストレージ１０３に記憶した提供リソースを用いる構成とすることができる。リソース特定部１２０はアプリ取得部１１０による追加アプリの受信時に各ＥＣＵ１００の提供リソースを特定していた。しかし、リソース特定部は、追加アプリの受信と独立して周期的に提供リソースを特定する構成でもよい。

上述の実施形態においては、各ＥＣＵ１００では、共通のプラットフォームソフトウェアが実行されていた。しかし、各ＥＣＵ１００において追加アプリで利用される機能を提供可能であれば、プラットフォームソフトウェアは完全に同一でなくてもよい。例えば、一部のＥＣＵ１００において、他のＥＣＵ１００で用いられていない、追加アプリには不要なミドルウェアが用いられていてもよい。あるいは、一部のＥＣＵ１００において、他のＥＣＵ１００とＯＳなどのバージョンが異なっていてもよい。

また車載システム１０には、共通のプラットフォームソフトウェアを実行しないＥＣＵ１００が含まれていてもよい。例えば、車載システム１０に含まれるＥＣＵ１００には、発揮する機能の一部または全部が、一つあるいは複数のＩＣ等によりハードウェア的に実現される構成であるものも含まれていてもよい。

上述の実施形態においては、追加アプリとして宅配トランクアプリを説明した。しかし、車載システム１０の通信プロトコルで定義されるサービスを利用して実現可能であれば、追加アプリはこれに限られない。例えば車両１の位置の提供サービスを用いて自宅周辺エリアへの進入を検知し、自宅の装置に帰宅の通知メッセージを送信する帰宅連絡アプリなどを追加アプリとしてインストールしうる。

上述の実施形態においては、要求特定部１３０は、追加アプリの実行に必要なリソースの最低ラインを要求リソースとし、追加アプリのインストールファイルに付属した実行環境を指定する情報に基づき特定していた。しかし、要求リソースの形式や、特定方法はこれに限られず適宜変更可能である。例えば要求リソースは、最低ラインを指定せず、メモリの空き容量が最大のＥＣＵ１００を選択するなどの、優先順の方針のみ設定する形式とすることもできる。また、要求特定部１３０は、追加アプリに実行環境を指定する情報が付属していない場合、あらかじめ設定された最低ラインや優先順の方針などを、その追加アプリの要求リソースとして用いる構成を採用できる。

１０ 車載システム、 １００ 情報処理装置、 １１０ アプリ取得部、 １２０ リソース特定部、 １３０ 要求特定部、 １４０ 選択部

Claims (3)

1. アプリケーションをインストール可能な複数の情報処理装置（１００）を備え、車両で用いられる車載システムであって、
   前記アプリケーションを取得するアプリ取得部（１１０）と、
   前記アプリ取得部で取得された前記アプリケーションの要求する要求リソースを特定する要求特定部（１３０）と、
   各前記情報処理装置で提供可能な提供リソースのそれぞれを特定するリソース特定部（１２０）と、
   前記提供リソースが前記要求リソースを満たしている前記情報処理装置を、前記アプリケーションのインストール先として選択する選択部（１４０）と、を備え、
   前記リソース特定部は、前記車両の稼動状態を区別して前記提供リソースを特定し、
   前記要求特定部は、前記アプリケーションの実行が想定される前記稼動状態を特定し、
   前記選択部は、実行の想定される前記稼動状態に対応した前記提供リソースが、前記要求リソースを満たしている前記情報処理装置を選択する車載システム。
2. 前記リソース特定部は、前記提供リソースを算出するためのリソース情報を各前記情報処理装置との通信により収集し、収集した前記リソース情報に基づいて前記提供リソースを特定する請求項１に記載の車載システム。
3. 前記リソース特定部は、前記車両が走行中の場合、前記リソース情報の収集を前記車両の停止まで待機する請求項２に記載の車載システム。

Images