JP7828268B2 - ネットワークシステム、およびネットワーク管理方法 - Google Patents

Description

本発明は、ネットワーク上に存在する複数の演算装置へのアプリケーションの配置を行うネットワークシステムおよびネットワーク管理方法に関する。

自動運転や安全運転支援技術は日進月歩であり、今後も進化が続く。自動車メーカにおいてはこれらの技術進歩を新型車両へ適用するだけでなく、販売済み車両にも適用することを検討している。そのための技術にＯＴＡ（Over-the-Air）アップデート技術がある。

ＯＴＡでは新規または更新された車載アプリケーション（以降、単にアプリと呼ぶ）を、クラウド等のサーバから無線ネットワークを介して車両へ配信する。車両側では配信されたアプリを車両システムに展開し適用・実行する。

車両システムは複数の電子制御ユニット（ＥＣＵ：Electronic Control Unit）がネットワークにより接続された構成となっている。ここでＥＣＵはカメラ等のセンサ、エンジンやステアリング等を操作するアクチュエータ、および制御のための演算を実行する装置の総称として用いる。ＥＣＵでは車載ネットワークを介してデータを送受信し、アプリによりデータを演算することで車両制御のための情報を得る。データの送受信により車載ネットワークには負荷がかかるが、アプリの配置状況によって車載ネットワークの負荷状況は異なる。

ここでＯＴＡにより新規アプリが追加された場合、車両システムは新規アプリを実行するＥＣＵを選択する必要がある。特許文献１にはアプリ追加時にアプリを実行するＥＣＵを選択する方法が開示されている。これは、アプリ取得部の取得した追加アプリをインストール可能なＥＣＵを複数備えた車載システムは、要求特定部、リソース特定部、および選択部を備える。要求特定部は、追加アプリの要求するリソースである要求リソースを特定する。リソース特定部は、各ＥＣＵの提供可能なリソースである提供リソースを特定する。選択部は、提供リソースが要求リソースを満たしているＥＣＵを追加アプリのインストール先として選択する。

特開２０２０－８６５２２号公報

特許文献１に記載の発明ではＥＣＵの演算リソースに基づいてアプリ配置先のＥＣＵを選択することができるが、車載ネットワークの負荷状況などＥＣＵ間の通信リソースを考慮したアプリ配置を行うことができない。

本発明は、上記課題に鑑みてなされたものであり、その目的は、ネットワーク上に存在する各演算装置の演算リソースおよび演算装置間の通信リソースを考慮したアプリケーションの配置が可能なネットワークシステムおよびネットワーク管理方法を提供することにある。

上記目的を達成するために、本発明は、アプリの実行要件を満たすように、ネットワーク上に存在する複数の演算装置のいずれかへ前記アプリを配置するネットワークシステムにおいて、前記アプリの実行要件および通信要件を保持するアプリ要件保持部と、前記複数の演算装置の空きリソース情報を保持する空きリソース情報保持部と、前記実行要件と前記空きリソース情報とに基づいて、前記複数の演算装置の中から前記アプリを実行可能な演算装置を選択し、アプリ配置先演算装置候補リストを作成するアプリ配置選択部と、前記複数の演算装置の通信接続関係を示すトポロジ情報を保持するトポロジ情報保持部と、前記ネットワークの各リンクの通信性能情報を保持する通信性能情報保持部と、前記トポロジ情報に基づいて、前記アプリ配置先演算装置候補リスト内の各演算装置に前記アプリを配置した場合の前記アプリの通信経路を選択して通信経路候補リストを作成する通信経路選択部と、前記通信性能情報と前記通信要件とに基づいて、前記通信経路候補リスト内の各通信経路にて前記通信要件が満たされるか否かを検証する性能検証部と、前記アプリ配置先演算装置候補リスト内の演算装置のうち、前記性能検証部によって前記通信要件が満たされることが検証された通信経路に対応する演算装置に前記アプリを配置する設定適用部と、前記ネットワークのトポロジ変化を検出して前記ネットワーク上の前記リンクが正常に通信可能な状態であるか否かを監視し、前記リンクに異常が検出された場合、異常が検出された前記リンクの情報を前記トポロジ情報保持部が使用しないこととするトポロジ変更監視部と、を備え、前記リンクに異常が検出された場合、前記通信経路選択部、前記性能検証部および前記設定適用部により、異常が検出された前記リンクを避けたアプリ配置および通信経路を設定し、配置済み前記アプリを含めて前記アプリの再配置を行う。

本発明によれば、ネットワーク上に存在する複数の演算装置のいずれかへアプリを配置する際に、各演算装置の演算リソースおよび演算装置間の通信リソースを考慮することにより、アプリの実行性能および通信性能を確保することができるため、アプリを安定的に動作させることが可能となる。

本発明による車載ネットワークシステムを搭載する車載装置の電気電子アーキテクチャの図 ドメインＥＣＵ、ゾーンＥＣＵ、セントラルＥＣＵ、およびゲートウェイのハードウェア構成図 本発明による車載ネットワークシステムの機能ブロック図 空きリソース情報保持部の保持するＥＣＵ内空きリソース情報テーブル アプリ要件保持部がＴＣＵ経由で受信するＯＴＡデータの構成例 アプリ要件保持部の保持するアプリ要件テーブル トポロジ情報保持部の保持するトポロジ情報テーブル 通信性能情報保持部の保持する通信性能情報テーブルの抜粋 アプリ配置選択部の動作を表すフローチャート アプリ配置選択部の出力であるアプリ配置先ＥＣＵ候補リスト 通信経路選択部の動作を表すフローチャート 図１１中ステップＳ２０９の詳細な処理の一例を示すフローチャート 図１２中ステップＳ２２１の詳細な処理の一例を示すフローチャート 図１３の処理をゾーンアーキテクチャのネットワークに対して実行した結果の例 通信経路選択部から出力され性能検証部へ入力される、アプリの通信経路候補リスト 性能検証部の動作を表すフローチャート 図１６中ステップＳ３０２の詳細な処理の一例を表すフローチャート 図１６中ステップＳ３０３の詳細な処理の一例を表すフローチャート 図１６中ステップＳ３０５の詳細な処理の一例を表すフローチャート 性能検証部から出力され設定適用部へ入力される通信経路リスト 設定適用部の動作を表すフローチャート 設定適用部で使用する通信経路設定テーブルの構成例 第２の実施例における性能検証部の構成図 第２の実施例における性能検証部の動作のうち、図１６中ステップＳ３０５の動作を示すフローチャート 第３の実施例における車載ネットワークシステムの機能ブロック図 第４の実施例におけるアプリ要件保持部の保持するアプリ要件テーブル 第４の実施例におけるアプリ要件保持部の保持するアプリ要件テーブル 第５の実施例におけるアプリ要件保持部の保持するアプリ要件テーブル 性能検証部の動作を表すフローチャート

以下、本発明の実施形態について図面を用いて説明する。なお、各図中、同等の要素には同一の符号を付し、重複した説明は適宜省略する。

以下、図を用いて車載ネットワークシステムの第１の実施例を説明する。

図１は本発明による車載ネットワークシステムを搭載する車載装置の電気電子アーキテクチャを示す図である。ここでは代表的な電気電子アーキテクチャとして２つの構成を取り上げるが、本発明の適用先はこれに限定されるものではない。

図１（ａ）はドメイン別アーキテクチャと呼ばれるアーキテクチャの論理的構成を示す図である。これは車両１内部のＥＣＵ（車載電子制御装置）をドメインと呼ばれる機能別区分に分類し、同一ドメインに属するＥＣＵを体系的に接続する方式である。ドメイン毎にそのドメインを統括するドメインＥＣＵ３が置かれる。またドメイン間で通信を行うために、ドメインＥＣＵ３はゲートウェイ２を介して相互に接続される。ドメインには例えば安全運転支援を司るＡＤＡＳ（Advanced Driver Assistance System）ドメイン、車両の前後方向および左右方向の運動を制御するＰＴ／ＣＨ（Power Train/Chassis）ドメイン、パワーウィンドウ等の電装機器を制御するＢＯＤＹドメイン、ナビゲーションやオーディオを制御するＩｎｆｏｔａｉｎｍｅｎｔドメインなどがある。それぞれのドメインに対してＡＤＡＳ ＥＣＵ３ａ、ＰＴ／ＣＨ ＥＣＵ３ｂ、ＢＯＤＹ ＥＣＵ３ｃ、Ｉｎｆｏｔａｉｎｍｅｎｔ ＥＣＵ３ｄ（以下これらをまとめて３とも表記する）が設置される。ドメインＥＣＵ３にはセンサ４ａ～４ｄ（以下まとめて４とも表記する）やアクチュエータ５ａ～５ｄ（以下まとめて５とも表記する）などのＥＣＵ４，５がＣＡＮ（Controller Area Network）、ＬＩＮ（Local Interconnect Network）等、ドメイン毎に適したリンク６ａ～６ｄ（以下まとめて６とも表記する）により接続される。単一のリンク６に複数のＥＣＵ４，５が接続される場合がある。またゲートウェイ２には、車外のサーバやクラウド等と無線ネットワークを介して通信を行うＴＣＵ（Telematics Control Unit）７が接続される。

ドメインＥＣＵはどのドメインごとに性能や機能要件が異なることがある。例えばＡＤＡＳ ＥＣＵやＩｎｆｏｔａｉｎｍｅｎｔ ＥＣＵはビデオ等の大容量データを扱うため処理性能の高いハードウェアが用いられる。一方ＰＴ／ＣＨ ＥＣＵは安全に直結するため信頼性の高いハードウェアが用いられる。

図１（ｂ）はゾーンアーキテクチャと呼ばれるアーキテクチャの物理的構成を示す図である。これはＥＣＵ４，５を車両１内部の空間的な位置によって分類し、その位置を統括するゾーンＥＣＵ９ａ～９ｄ（以下まとめて９とも表記する）へ接続する方式である。１つ以上のゾーンＥＣＵ９、ゾーンＥＣＵ９に接続し複数ドメインにまたがる複数のアプリを実行するセントラルＥＣＵ８、ゾーンＥＣＵ９に接続するセンサ４およびアクチュエータ５などから構成される。このゾーンＥＣＵ９はその名の通り、車両内での前後左右等の位置（ゾーン）に対応して配置されており、その設置位置に近接するセンサ４またはアクチュエータ５、あるいはその両方と接続される。またゾーンＥＣＵ９はドメイン間で共通通信方式を用いた共有リンク１０により他のゾーンＥＣＵ９と接続される。共通通信方式はＥｔｈｅｒｎｅｔ（登録商標）によるスイッチングネットワークが想定される。ＴＣＵ７はセントラルＥＣＵ８または任意のゾーンＥＣＵ９に接続されるが、図１（ｂ）ではセントラルＥＣＵ８に接続する例を示している。

図２はドメインＥＣＵ３、ゾーンＥＣＵ９、セントラルＥＣＵ８、およびゲートウェイ２のハードウェア構成である。図２中の太線はゾーンアーキテクチャまたはドメインアーキテクチャにおける通信装置２間の接続方式である共通通信方式を表しており、細線はその他の通信方式を表している。

図２（ａ）はドメインＥＣＵ３のハードウェア構成である。ドメインＥＣＵ３は内部に、センサ４およびアクチュエータ５あるいはゲートウェイ２から受信した情報を処理するためのＣＰＵ（Central Processing Unit）１１、およびＣＰＵ１１で演算を行うために用いるデータを保持するメモリ１２を持ち、ＣＰＵ１１からはゲートウェイ２へ接続するためのリンクおよびセンサ４やアクチュエータ５へ接続するためのリンクが出ている。

図２（ｂ）はゾーンＥＣＵ９のハードウェア構成である。ゾーンＥＣＵ９は他のゾーンＥＣＵ９へ接続するため、あるいはセンサ４やアクチュエータ５へ接続するための共有リンク１０を収容するネットワークスイッチ１３を備える。またゾーンＥＣＵ９は、センサ４およびアクチュエータ５、あるいは共有リンク１０から受信した情報を処理するためのＣＰＵ１１を備え、ネットワークスイッチ１３と接続される。またＣＰＵ１１はメモリ１２とも接続される。センサ４およびアクチュエータ５が共通通信方式に対応している場合はネットワークスイッチ１３へ直接接続してよい。センサ４およびアクチュエータ５が共通通信方式に対応していない場合はＣＰＵ１１へと接続した上で共通通信方式へ変換することができる。

図２（ｃ）はドメイン別アーキテクチャにおけるゲートウェイ２のハードウェア構成である。ゲートウェイ２は、ＣＰＵ１１、メモリ１２、およびドメインＥＣＵ３へ接続するためのネットワークスイッチ１３を備える。

図２（ｄ）はゾーン別アーキテクチャにおけるセントラルＥＣＵ８のハードウェア構成である。セントラルＥＣＵ８は、ゲートウェイ２と概ね同様の構成となっており、ＣＰＵ１１、メモリ１２、およびゾーンＥＣＵ９へ接続するためのネットワークスイッチ１３を備える。

図３は本発明による車載ネットワークシステムの機能ブロック図である。なお機能ブロックは図１に表示のない独立した装置として実装してもよいし、ソフトウェアとして実装し図１中いずれかのＥＣＵにて実行してもよい。ソフトウェアとして実装する場合、図１中の任意のＥＣＵにて機能を損なうことなく実行可能であるが、典型的には車載ネットワーク全体を管理するために、ドメイン別アーキテクチャであればゲートウェイに、ゾーンアーキテクチャであればセントラルＥＣＵに実装されると想定される。

本発明は空きリソース情報保持部２０、アプリ要件保持部２１、トポロジ情報保持部２２、通信性能情報保持部２３、アプリ配置選択部２４、通信経路選択部２５、性能検証部２６、設定適用部２７の機能ブロックからなる。

空きリソース情報保持部２０は各ＥＣＵ内部のリソース状況、例えばＣＰＵ空き容量やメモリ空き容量に関する情報を定期的に収集して保持する。

アプリ要件保持部２１は車内の各ＥＣＵで実行するアプリに関する実行要件を保持する。アプリ要件保持部２１には車両の出荷時においてプリインストールされるアプリの要件は出荷時に格納されているものとし、ＯＴＡにより追加されるアプリの要件はＯＴＡデータとともにＴＣＵ７を介して受信するものとする。要件の具体例については図６を用いて説明する。

トポロジ情報保持部２２では車載ネットワークの接続関係を表すトポロジ情報を保持する。

通信性能情報保持部２３では車載ネットワーク内の各リンクごとに、現在行われている通信の性能情報、つまりＥＣＵ間の通信リソース状況を保持する。

アプリ配置選択部２４は空きリソース情報保持部２０から取得する各ＥＣＵ内部のリソース状況およびアプリ要件保持部２１から取得するアプリのＥＣＵ内部リソース（演算リソース）に関する実行要件情報をもとに、アプリの配置先ＥＣＵ候補を決定する。

通信経路選択部２５はアプリ配置選択部２４の決定したアプリの配置先ＥＣＵ候補、アプリ要件保持部２１から取得したアプリの通信先情報、およびトポロジ情報保持部２２から取得する車載ネットワークのトポロジ情報をもとに、アプリが行う通信の通信経路候補を決定する。

性能検証部２６は通信経路選択部２５の決定したアプリの通信経路候補に対し、アプリ要件保持部２１から取得するアプリの通信要件および通信性能情報保持部２３から取得した通信の性能情報をもとに、通信経路候補を選択した場合のアプリの通信性能を検証する。検証の結果アプリが通信性能を満たす経路候補より、実際に使用する通信経路を１つ選択する。

設定適用部２７では性能検証部２６が決定した通信経路を車載ネットワークへ適用する。そのためにアプリ要件保持部２１からアプリのデータ送受信先アドレス等を取得し、経路上のＥＣＵ内部にあるネットワークスイッチ１３に転送ルールを設定する。

以降、各機能ブロックの詳細について説明する。

図４は空きリソース情報保持部２０の保持するＥＣＵ内空きリソース情報テーブル３０である。ＥＣＵ内空きリソース情報テーブル３０はＥＣＵ列３１に対し、計算リソース列３２、記憶リソース列３３、およびスペック列３４の情報を保持する。スペックは高性能、高信頼等のＥＣＵが持つ特性を意味する。

図５はアプリ要件保持部２１がＴＣＵ７経由で受信するＯＴＡデータ４０の構成例である。ＯＴＡデータ４０はアプリのＩＤ、バージョン情報などを含むヘッダ４１、バイナリ形式等でアプリ本体のコードを格納したアプリデータ４２、および本発明にて参照するアプリに関するメタデータ４３を含む。メタデータ４３には当該アプリにおける通信の識別番号である通信ＩＤ５４に対応して、図６に記載するアプリ要件テーブル５０と同様の実行要件５３、通信仕様５８および通信要件６４を保持する。アプリが複数の通信を行う場合は通信ＩＤ、実行要件５３、通信仕様５８および通信要件６４の組を複数持つ。実行要件５３、通信仕様５８および通信要件６４の詳細は図６と同様であるので、図６とともに説明する。

図６はアプリ要件保持部２１の保持するアプリ要件テーブル５０である。アプリ要件テーブル５０はアプリのＩＤを保持するアプリ列５１に対し、アプリがいずれかのＥＣＵに配置済みであることを示す配置済みフラグ５２、ＥＣＵ内部リソース（演算リソース）に関する要件を保持する実行要件５３、ＥＣＵ間通信の仕様を保持する通信仕様５８およびＥＣＵ間の通信リソースに関する要件を保持する通信要件６４を保持する。実行要件５３は計算リソース列５５、記憶リソース列５６、スペック列５７を含む。また通信仕様５８はＥＣＵ間通信に関するアプリの要件として、アプリから見た場合の送信または受信の別を表す通信方向列５９、アプリの通信相手を特定する通信相手列６０、通信周期列６１、パケットサイズ列６２、および通信パケットからアプリを特定するための情報であるアプリ識別情報６３を含む。アプリ識別情報は例えばＣＡＮのＣＡＮ ＩＤ、イーサネットにおける送信元・宛先ＭＡＣアドレス、ＩＰ（Internet Protocol）における送信元・宛先ＩＰアドレス、ＴＣＰ（Transmission Control Protocol）またはＵＤＰ（User Datagram Protocol）における送信元・宛先ポート番号などがある。通信要件６４は通信帯域列６５、通信遅延列６６、ジッタ列６７、および廃棄率列６８を含む。なお単一のアプリが複数の通信を行う場合、当該アプリはアプリＡ３のように複数の行を用いて複数の通信を表現する。また、アプリが通信を行わない場合、当該アプリはアプリＡ４のように実行要件のみ設定することができる。

図７はトポロジ情報保持部２２の保持するトポロジ情報テーブル７０である。トポロジ情報テーブル７０は車載ネットワーク内のＥＣＵ間を接続する各リンクを表すリンク列７１に対して、当該リンクの種別がバス型（複数のＥＣＵが一つの共通の通信路に接続する形態）であるかメッシュ型（１つのＥＣＵが他のＥＣＵと一対一で接続する形態）であるかを記載する種別列７２および当該リンクに接続されるＥＣＵのＩＤを保持する接続情報列７３を持つ。

図８は通信性能情報保持部２３の保持する通信性能情報テーブル８０の一部を抜粋したものである。通信性能情報テーブル８０はリンク列８１に対し、通信方向８２を持ち、リンクおよび当該通信方向ごとにリンクの総帯域を表す総帯域列８３、既存のアプリによって使用されている帯域を表す使用済み帯域列８４、最大の遅延時間を表す遅延時間列８５、ジッタ列８６、廃棄率列８７、およびバッファ使用量列８８を持つ。

図９はアプリ配置選択部２４の動作を表すフローチャートである。本フローチャートはＯＴＡによるアプリの追加によるアプリ要件テーブル５０の更新を契機として開始される。まずステップＳ１００にてアプリ要件保持部２１からアプリ要件テーブル５０を取得する。続いてＳ１０１にて、アプリ要件テーブル５０に登録されているアプリ毎に以下の処理をループする。ステップＳ１０２にて対象アプリの配置済みフラグをしらべ、配置済みである場合（Ｙｅｓ）には何も行わず次のアプリの処理へ移る。配置済みでない場合（Ｎｏ）は、ステップＳ１０３以降を実行する。ステップＳ１０３では対象アプリの実行要件がアプリ要件テーブル５０に登録済みであるかを調べる。登録済みでない場合（Ｎｏ）、ステップＳ１０８にて事前に定義されたＥＣＵ候補リストを総リソースの大きい順にソートしアプリの配置先ＥＣＵ候補として、次のアプリの処理へ移る。登録済みの場合（Ｙｅｓ）、以下の処理を行う。ステップＳ１０４にて空きリソース情報保持部２０からＥＣＵ内空きリソース情報テーブル３０を取得する。続くステップＳ１０５にて、ＥＣＵ内空きリソース情報テーブル３０内のＥＣＵのうち、計算リソースおよび記憶リソースがアプリの実行要件にある計算リソースおよび記憶リソースより大きく、かつ、アプリの要求するスペックを満足するＥＣＵを選択することにより、アプリの要求する実行要件を満たすＥＣＵを選択し、配置先ＥＣＵ候補リストを作成する。そしてステップＳ１０６にてＥＣＵ候補リストを空きリソースの大きい順にソートしてアプリの配置先ＥＣＵ候補とする。ステップＳ１０７にてアプリに対するループの終了判定を行い、全アプリに対して処理が完了した場合は本処理を終了する。

図１０はアプリ配置選択部２４の出力であるアプリ配置先ＥＣＵ候補リスト９０である。アプリ配置先ＥＣＵ候補リスト９０はアプリ列９１ごとに配置先ＥＣＵ候補９２を保持する。アプリ配置先ＥＣＵ候補リスト９０は次の通信経路選択部２５の入力となる。

図１１は通信経路選択部２５の動作を表すフローチャートである。本フローチャートはアプリ配置選択部２４からのアプリ配置先ＥＣＵ候補リスト９０の入力を契機として開始される。まずステップＳ２００にてアプリ配置選択部２４からのアプリ配置先ＥＣＵ候補リスト９０を取得する。ステップＳ２０１にてトポロジ情報保持部２２より車載ネットワークのトポロジ情報テーブル７０を取得する。ステップＳ２０２にてトポロジ情報テーブル７０に車載ネットワークのトポロジ情報が含まれているか確認し、含まれていない場合（Ｎｏ）はステップＳ２０４にて事前に定義されたデフォルトのトポロジ情報を使用する。ステップＳ２０２にてトポロジ情報が含まれる場合（Ｙｅｓ）は、ステップＳ２０３にてトポロジ情報テーブル７０のトポロジ情報を使用する。
続くステップＳ２０５ではアプリ配置先ＥＣＵ候補リスト９０のアプリ列９１にあるアプリ毎に以下のループ処理を行う。まずステップＳ２０６にてアプリ要件保持部２１からアプリの通信データ（パケット）ごとに、通信相手情報を取得する。ここで通信相手情報とは、受信データにおけるデータ送信元、ならびに送信データにおけるデータ宛先を総称していう。ステップＳ２０７では前記通信相手情報を調べ、通信相手に関する情報が含まれない場合（Ｎｏ）は通信が行われないものと判断して次のアプリに関する処理に移る。ステップＳ２０７で通信相手に関する情報が含まれる場合（Ｙｅｓ）、ステップＳ２０８以降に進む。
ステップＳ２０８ではアプリ配置先ＥＣＵ候補リスト９０の配置先ＥＣＵ候補９２に対するループを開始する。ステップＳ２０９では別途定義する処理によりデータの送信元から受信先までの経路候補を求める。すべての配置先ＥＣＵ候補に関してＳ２０９の処理が完了した場合、Ｓ２１０にて配置先ＥＣＵ候補に関するループを終了する。

アプリ配置先ＥＣＵ候補リスト９０のすべてのアプリに関して処理が完了した場合、ステップＳ２１１にてループを終了し、通信経路選択部２５の処理を終了する。

図１２は図１１中ステップＳ２０９の詳細な処理の一例を示すフローチャートである。まずステップＳ２２０にてアプリに属する通信ごとにループを開始する。続くステップＳ２２１では別途定義する処理にて送信元ＥＣＵから宛先ＥＣＵまでの経路を探索する。そしてステップＳ２２２では宛先ＥＣＵに到達した場合は探索した経路を経路候補リストへ追加する。すべての通信データに対して処理が完了した場合、ステップＳ２２３にてループを終了し、本処理を終了する。

図１３は図１２中ステップＳ２２１の詳細な処理の一例を示すフローチャートである。ここでは幅優先探索にて送信元ＥＣＵから宛先ＥＣＵまでの経路を探索するが、深さ優先探索など他の探索アルゴリズムにて実施してもよい。また図１４は本探索処理で用いる探索リスト１００の例である。探索リスト１００は探索の段階を示すフェーズ１０１、送信元ＥＣＵから宛先ＥＣＵまでのすでに探索した経路候補を示す通信経路候補１０２、および通信経路候補１０２の状態を示す状態１０３を持つ。

まずステップＳ２３０にて変数「フェーズ」を０に設定、状態を未完了として送信元ＥＣＵを選択し、探索リストの最初のエントリに追加する。続くステップＳ２３１ではフェーズを１だけ増加する。次いでステップＳ２３２では前フェーズの探索リストで状態が未完了である通信経路候補１０２のうち、経路候補の末尾にあるＥＣＵからトポロジ上で直結するＥＣＵを抽出の上、通信経路候補１０２の末尾に追加したものを、現フェーズの探索リスト１００に追加する。

ステップＳ２３３では前記のようにして作成した現フェーズの探索リスト１００に対してループを開始する。ステップＳ２３４にて通信経路候補１０２の状態をチェックする。まず通信経路候補１０２の末尾が宛先ＥＣＵであった場合（Ｓ２３４ａ）はステップＳ２３５にて通信経路の状態１０３を「宛先到達」に設定し、ステップＳ２３６にて通信経路選択部２５の出力である経路候補リストへ追加する。次にステップＳ２３４にて通信経路候補１０２の末尾が探索済みＥＣＵであった場合（Ｓ２３４ｂ）、つまり通信経路候補に同一ＥＣＵが複数含まれる場合は、ステップＳ２３７にて通信経路候補の状態１０３を「探索済み到達」に設定する。ステップＳ２３４にてそれ以外であった場合（Ｓ２３４ｃ）、ステップＳ２３８にて通信経路候補の状態１０３を未完了に設定する。そして現フェーズの探索リスト末尾まで処理が完了した場合、ステップＳ２３９にてループを終了する。

最後にステップＳ２４０にて現フェーズの探索リストに状態が未完了の通信経路候補１０２があるか否かを確認し、状態が未完了の通信経路候補１０２がある場合はステップＳ２３１に戻って処理を継続する。状態が未完了の通信経路候補１０２がない場合、つまり車載ネットワークのトポロジに対する探索を完了した場合は、本処理を終了する。

図１４は図１３の処理をゾーンアーキテクチャのネットワークに対して実行した結果の例である。前フェーズで状態が未完了となったものに対し、現フェーズでは次に到達可能なＥＣＵを追加した通信経路候補をリスト化する。そしてフェーズ５にて状態が宛先到達の場合（下線で示すＥＣＵ Ｃの箇所）または探索済み到達（イタリック体で示すＥＣＵ Ａの箇所）となり、探索を完了する。

図１５は通信経路選択部２５から出力され性能検証部２６へ入力される、アプリの通信経路候補リスト１１０である。アプリの通信経路候補リスト１１０はアプリ列１１１に対する通信経路候補１１２を保持する。

図１６は性能検証部２６の動作を表すフローチャートである。まずステップＳ３００にて、通信経路選択部２５からアプリの通信経路候補リスト１１０を受信する。次にステップＳ３０１にて通信経路候補リスト１１０に記載のアプリについてループする。次にステップＳ３０２では別途定義する手順にてアプリ要件保持部２１よりアプリの通信要件情報を取得する。次にステップＳ３０３では別途定義する手順にて通信性能情報保持部２３より車載ネットワーク上の各リンクにおける通信性能情報を取得する。次にステップＳ３０４にて通信経路候補リスト１１０に記載の当該アプリに対する経路候補についてループする。次にステップＳ３０５にて別途定義する手順により、経路候補の通信性能情報とアプリの通信要件から、選択経路使用時の当該アプリの通信性能を評価する。この評価結果をステップＳ３０６にて判定し、アプリの通信要件を満たせない場合（Ｎｏ）は経路候補リストに関するループを継続する。ステップＳ３０６にてアプリの通信要件を満たせる通信経路が存在した場合（Ｙｅｓ）、ステップＳ３１０にてアプリの配置成功とし、設定適用部２７へ通信経路情報を出力する。続いてステップＳ３１１にて空きリソース情報保持部お２０よび通信性能情報保持部２３の情報を更新する。アプリの通信要件を満たせる通信経路が存在せずステップＳ３０７にてループが終了した場合、ステップＳ３０８にてアプリ配置を失敗とする。最後にこれらの処理をステップＳ３０９にてアプリ毎のループが終了するまで実行する。

図１７は図１６中ステップＳ３０２の詳細な処理の一例を表すフローチャートである。この処理次点で特定アプリに関する処理となっている。まずステップＳ３２０にてアプリ要件保持部２１より当該アプリの各通信データについて通信要件を取得する。なお通信を行わないアプリについては通信要件を取得しないものとする。次にステップＳ３２１にて取得した通信要件データに、通信帯域や遅延などアプリの通信要件が含まれるか否かを調べる。通信要件が含まれる場合（Ｙｅｓ）、ステップＳ３２２にてアプリ要件保持部２１より取得したアプリの通信要件を使用する。ステップＳ３２１にて通信要件が含まれない場合（Ｎｏ）、ステップＳ３２３にて事前に定義されたデフォルトの通信要件を使用する。

図１８は図１６中ステップＳ３０３の詳細な処理の一例を表すフローチャートである。まずステップＳ３３０にて、通信性能情報保持部２３より車載ネットワーク上の各リンクにおける通信性能情報を取得する。次にステップＳ３３１にて車載ネットワーク上のリンクごとにループを開始する。ステップＳ３３２にてリンクごとの取得した通信性能情報に何かしらの通信性能情報が含まれるか否かを調べる。通信性能情報が含まれる場合（Ｙｅｓ）、ステップＳ３３３にて通信性能情報保持部２３より取得した通信性能情報を使用する。ステップＳ３３２にて通信性能情報が含まれない場合（Ｎｏ）、ステップＳ３３５にて当該リンク上では通信が行われていないものと仮定する。全リンクについて処理を完了すれば、ステップＳ３３４にてループを終了する。

図１９は図１６中ステップＳ３０５の詳細な処理の一例を表すフローチャートである。ここではアプリごとにリンク上の通信性能として、通信帯域、遅延、ジッタ、パケット廃棄率の４つの値を数値計算により求める。前記４つの値は独立に計算可能であるため、以下のステップは連続でも並列でも実行することが許可される。まずステップＳ３４０で経路候補を構成する各リンクについてループを開始する。ステップＳ３４１からステップＳ３４４は独立に実行可能である。ステップＳ３４１ではリンク上の使用帯域にアプリの通信帯域を加算することにより、アプリを追加した場合の通信帯域を求める。ステップＳ３４２ではリンク上の遅延にアプリのパケット長を加算することにより、アプリを追加した場合の遅延を求める。ステップＳ３４３では、ジッタがリンク上に送信されるパケット長の最大値で規定されることより、リンク上のジッタとアプリのパケット長を比較し、リンク上のジッタよりもアプリのパケット長が大きい場合、ジッタをアプリのパケット長に更新する。ステップＳ３４４では、パケット廃棄率がリンク上の送信バッファあふれにより発生することより、リンク上のバッファ使用量にアプリのパケット長を加算した値をＳＵＭとし、ＳＵＭがバッファサイズよりも大きい場合、パケット廃棄率を（ＳＵＭ－バッファサイズ）／ＳＵＭの式により求める。ステップＳ３４５にて経路候補を構成する各リンクについてループを終了する。

図２０は性能検証部２６から出力され設定適用部２７へ入力される通信経路リスト１２０である。通信経路リスト１２０はアプリ列１２１ごとに性能検証部２６によって選択された通信経路１２２を保持する。

図２１は設定適用部２７の動作を表すフローチャートである。まずステップＳ４００にて、性能検証部２６より受信した通信経路リスト１２０から、含まれるアプリを抽出しアプリ一覧を取得する。次にステップＳ４０１にて前記取得したアプリ一覧に含まれるアプリについて、その識別情報をアプリ要件保持部２１より取得する。次にステップＳ４０２にて、通信経路情報を再構成し、ＥＣＵごとに、通信データが通過するアプリの識別情報と当該通信データの次の転送先ＥＣＵとを対応付けた通信経路設定テーブル１３０を生成する。通信経路設定テーブル１３０の構成例は図２２を用いて説明する。次にステップＳ４０３では、通信経路設定テーブル１３０のＥＣＵごとにステップＳ４０４の処理をループする。ステップＳ４０４では当該ＥＣＵに対し、アプリ識別情報と次の転送先ＥＣＵを設定する。ステップＳ４０５では通信経路設定テーブル１３０中のＥＣＵに関するループを終了する。最後にアプリ一覧に含まれるアプリについて、配置先ＥＣＵへ配置する。配置先ＥＣＵはアプリの通信経路において、送信データの先頭または受信データの末尾にあるＥＣＵである。

図２２は設定適用部２７内部で使用する通信経路設定テーブル１３０の構成例である。通信経路設定テーブル１３０はＥＣＵ列１３１に対し、通信データが通過するアプリのアプリ識別情報１３２および次の転送先ＥＣＵ１３３を保持する。なおアプリの配置先ＥＣＵにおいてアプリが受信するデータは転送先をＣＰＵと表現する。

以上の動作により、車載ネットワークシステムはＯＴＡによる新規アプリの追加に伴うアプリのＥＣＵへの配置を、ＥＣＵ内の計算・記憶リソースおよびＥＣＵ間の通信リソースを考慮して行うことができる。またＯＴＡによる既存アプリ更新時にも同様の方法にてアプリ配置を行うことができる。

（まとめ）
本実施例では、アプリの実行要件５３を満たすように、ネットワーク上に存在する複数の演算装置３，９のいずれかへ前記アプリを配置するネットワークシステムにおいて、前記アプリの実行要件５３および通信要件６４を保持するアプリ要件保持部２１と、複数の演算装置３，９の空きリソース情報を保持する空きリソース情報保持部２０と、実行要件５３と空きリソース情報とに基づいて、複数の演算装置３，９の中から前記アプリを実行可能な演算装置を選択し、アプリ配置先演算装置候補リスト９０を作成するアプリ配置選択部２４と、複数の演算装置３，９の通信接続関係を示すトポロジ情報を保持するトポロジ情報保持部２２と、前記ネットワークの各リンクの通信性能情報を保持する通信性能情報保持部２３と、前記トポロジ情報に基づいて、アプリ配置先演算装置候補リスト９０内の各演算装置に前記アプリを配置した場合の前記アプリの通信経路を選択して通信経路候補リスト１１０を作成する通信経路選択部２５と、通信性能情報と通信要件６４とに基づいて、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを検証する性能検証部２６と、アプリ配置先演算装置候補リスト９０内の演算装置のうち、性能検証部２６によって通信要件６４が満たされることが検証された通信経路に対応する演算装置に前記アプリを配置する設定適用部２７とを備える。

また、本実施例では、アプリの実行要件５３を満たすように、ネットワーク上に存在する複数の演算装置３，９のいずれかへ前記アプリを配置するネットワーク管理方法において、前記アプリの実行要件５３および通信要件６４を保持するアプリ要件保持ステップと、複数の演算装置３，９の空きリソース情報を保持する空きリソース情報保持ステップと、実行要件５３と空きリソース情報とに基づいて、複数の演算装置３，９の中から前記アプリを実行可能な演算装置を選択し、アプリ配置先演算装置候補リスト９０を作成するアプリ配置選択ステップと、複数の演算装置３，９の通信接続関係を示すトポロジ情報を保持するトポロジ情報保持ステップと、前記ネットワークの各リンクの通信性能情報を保持する通信性能情報保持ステップと、前記トポロジ情報に基づいて、アプリ配置先演算装置候補リスト９０内の各演算装置に前記アプリを配置した場合の前記アプリの通信経路を選択して通信経路候補リスト１１０を作成する通信経路選択ステップと、通信性能情報と通信要件６４とに基づいて、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを検証する性能検証ステップと、アプリ配置先演算装置候補リスト９０内の演算装置のうち、前記性能検証ステップによって通信要件６４が満たされることが検証された通信経路に対応する演算装置に前記アプリを配置する設定適用ステップとを備える。

以上のように構成した本実施例によれば、ネットワーク上に存在する複数の演算装置３，９のいずれかへアプリを配置する際に、各演算装置３，９の演算リソースおよび演算装置間の通信リソースを考慮することにより、アプリの実行性能および通信性能を確保することができるため、アプリを安定的に動作させることが可能となる。

また、本実施例における通信要件６４および通信性能情報は、アプリの通信帯域、通信遅延、通信ジッタ、およびパケット廃棄率のいずれか１つ以上を含む。これにより、アプリの通信要件６４および通信性能情報を定義することが可能となる。

また、本実施例における性能検証部２６は、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを、通信性能情報と通信要件６４とに基づく数値計算により検証する。これにより、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを簡易的に検証することが可能となる。

また、本実施例における性能検証部２６は、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを、通信性能情報と通信要件６４とに基づくシミュレーションにより検証する。通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを高い精度で検証することが可能となる。

また、本実施例における、前記アプリを配置する際に前記アプリとともに前記ネットワークに入力されるメタデータ４３は、計算リソース、記憶リソース、およびスペックのいずれか１以上を含む実行要件５３と、通信方向、通信相手、通信周期、通信データサイズ、および通信識別情報のいずれか１以上を含む通信仕様５８と、通信帯域、通信遅延、通信ジッタ、パケット廃棄率のいずれか１以上を含む通信要件６４とを含む。これにより、アプリの実行要件５３、通信仕様５８、および通信要件６４を定義することが可能となる。

また、本実施例におけるネットワークは、車両に搭載された車載ネットワークであり、複数の演算装置３，９は、前記車両に搭載された複数の車載電子制御装置３，９である。これにより、車載ネットワークにおいて、新たに配置したアプリを安定的に動作させることが可能となる。

また、本実施例における車載装置は、前記ネットワークシステムを備える。これにより、車載装置において、新たに配置したアプリを安定的に動作させることが可能となる。

また、本実施例における通信要件６４は、前記車両に搭載されたセンサ４から出力されるセンサデータ、前記車両を制御するための制御データ、および前記センサデータから前記制御データを求める演算の途中で得られる中間データに関する項目を含む。これにより、車載装置の要求性能に応じた通信要件６４を定義することが可能となる。

第１の実施例では数値計算により通信性能を推定した。この方法は計算量が小さく簡便であるが、推定の精度は低い。そこで第２の実施例では別の方法として、ネットワークシミュレーションによる通信性能の推定を行う方法を示す。

本実施例における主な構成および動作のフローは第１の実施例と同様である。以下、第１の実施例との差分のみ説明することとする。

図２３は第２の実施例における性能検証部２６の構成図である。本実施例における性能検証部２６は大きく２つの構成が可能である。図２３（ａ）は車内でシミュレーションを実行する場合の構成図である。性能検証部２６はその内部にシミュレーション部２８を有し、これを用いてシミュレーションによる性能検証を行う。図２３（ｂ）は車外でシミュレーションを行う場合の構成図である。ここで車外とは、クラウド、Multi-access Edge Computing（ＭＥＣ）、路側機、あるいは他の車両など、自車両以外の計算リソースを意味する。性能検証部２６は無線通信等により車外に設置されたシミュレーション部２８と通信を行い、必要な設定をシミュレーション部２８へ送信後にシミュレーション部２８へシミュレーション実行を指示し、結果をシミュレーション部２８から受信する。

図２４は第２の実施例における性能検証部２６の動作のうち、図１６中ステップＳ３０５の動作を示すフローチャートである。まずステップＳ５００にてシミュレーション設定を作成する。次にステップＳ５０１にてシミュレーション部２８を動作させ、シミュレーションを実行する。最後にステップＳ５０２にてシミュレーション結果より経路候補の区間（リンク）別に性能評価結果を取得する。ここで性能評価結果には通信帯域、遅延、ジッタ、パケット廃棄率などを含む。

以上により本実施例による発明によって、より精度の高い性能評価が可能となり、収容アプリ数の増加やアプリ動作の安定性向上が可能となる。

（まとめ）
本実施例におけるネットワークシステムの性能検証部２６は、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを、通信性能情報と通信要件６４とに基づくシミュレーションにより検証する。

以上のように構成した本実施例によれば、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを高い精度で検証することが可能となる。

また、本実施例におけるネットワーク管理方法の性能検証ステップでは、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを、車両内部の計算機を用いた、通信性能情報と通信要件６４とに基づくシミュレーションにより検証する。これにより、ネットワークシステムが外部と通信できない環境下でもシミュレーションを行うことが可能となる。

また、本実施例におけるネットワーク管理方法の性能検証ステップでは、通信経路候補リスト１１０内の各通信経路にて通信要件６４が満たされるか否かを、車両外部の計算機を用いた、通信性能情報と通信要件６４とに基づくシミュレーションにより検証する。これにより、シミュレーションを行うリソースが制限されないため、シミュレーションの精度を向上させることが可能となる。

第１および第２の実施例においては車載ネットワークのトポロジを固定的なものと仮定していた。一方で車載ネットワークのトポロジは、ＣＡＮ等への新たなデバイスの追加やハードウェア異常等による通信断にて変化しうる。そこで第３の実施例では、このようなトポロジ変化に対し追従可能な車載ネットワークシステムを示す。

図２５は第３の実施例における車載ネットワークシステムの機能ブロック図である。図３と比較してトポロジ変更監視部２９が追加されている。

トポロジ変更監視部２９はＣＡＮでは「バス障害」や「エラー状態」により、またイーサネットではＬＬＤＰ（Link Level Discovery Protocol）等の方式を用いて車載ネットワークの状態を監視する。ここで車載ネットワークの状態とは、車載ネットワーク上のリンクが正常に通信可能な状態であるか否かを意味する。正常状態であれば何も動作は行わない。異常が検出された場合、当該リンクの情報をトポロジ情報保持部２２のトポロジ情報テーブル７０上で削除するか異常状態としてマークし、使用しないこととする。その後、配置済みアプリを含めてアプリの再配置を行う。つまり通信経路選択部２５、性能検証部２６、設定適用部２７を動作させ、異常状態となったリンクを避けたアプリ配置および通信経路を設定する。

（まとめ）
本実施例におけるネットワークシステムは、ネットワークのトポロジ変化を検出してトポロジ情報保持部２２に通知するトポロジ変更監視部２９をさらに備える。

以上のように構成した本実施例によれば、ネットワークのトポロジが変化した場合であっても、実行要件５３と通信要件６４とを満たすようにアプリを演算装置３，９へ配置することが可能となる。

第１および第２の実施例は複数のアプリがＯＴＡにより追加される場合、アプリ間の追加順序を考慮しない。そのため先に追加されたアプリがＥＣＵ内部のリソースやＥＣＵ間の通信リソースを消費してしまい、後から追加するアプリが追加不能となる場合がある。そのため、アプリ間で優先度が異なる場合に、高優先アプリが追加されないこととなる。

そこで第４の実施例ではアプリ間の優先度を考慮したアプリ配置を行う装置を示す。

図２６は第4の実施例におけるアプリ要件保持部２１の保持するアプリ要件テーブル５０である。実施例１から３との違いは、通信仕様５８に優先度列６９が追加される点である。図２６では０～７の８段階で優先度を設定しており、０が最低、７が最高の優先度である。なお実行要件５３および通信要件６４は第１および第３の実施例と同一であるため個別の列の記載を省略している。

図２７は第４の実施例におけるアプリ配置選択部２４の動作を表すフローチャートである。実施例１のフローチャート（図９）と同様の処理は同じ番号を付与している。実施例１から３との違いはステップＳ１０１のループ処理がステップＳ６００のように変更されている点のみである。ステップＳ６００ではアプリに関するループを本実施例におけるアプリ要件テーブル５０の優先度の降順に行う。これにより優先度の高いアプリほど先にＥＣＵ配置および通信経路が決定される。

（まとめ）
本実施例におけるアプリ要件保持部２１は、アプリごとに優先度を保持し、アプリ配置選択部２４は、優先度の高いアプリから順にアプリ配置先演算装置候補リスト９０を作成する。

以上のように構成した本実施例によれば、優先度の高いアプリから順に演算装置３，９へ配置することが可能となる。

第１から第４の実施例では通信要件の各項目を等しい優先度で扱っているが、アプリによっては通信要件間で要件を充足すべき度合いが異なる場合がある。そこで第５の実施例では、アプリ毎に特に充足すべき通信要件を指定できる構成を示す。

図２８は第５の実施例におけるアプリ要件保持部２１の保持するアプリ要件テーブル５０である。第１から第４の実施例との違いは、通信要件の各項目に対する優先度列６９ａ～６９ｄが追加されている点である。図２８では０～７の８段階で優先度を設定しており、０が最低、７が最高の優先度である。通信要件の各項目に対する優先度を用いて、アプリ毎に特に充足すべき通信要件を満たすようなアプリ配置を行うことができる。

図２９は性能検証部２６の動作を表すフローチャートである。第１の実施例１のフローチャート（図１６）と同様の処理は同じ番号を付与している。第１の実施例との違いは、ステップＳ３０６がステップＳ７００に変更された点と、ステップＳ３０７終了後にすぐステップＳ３０８にてアプリ配置失敗とするのではなく、ステップＳ７００およびＳ７０１にて最低優先度の項目を通信要件から除外した上で再度アプリ配置を試みる点である。

ステップＳ７００ではアプリ通信性能評価の結果、アプリの通信性能が優先度が０より大きい通信要件を満たせるか否かを判断する。満たせる場合（Ｙｅｓ）はアプリ配置成功としてステップＳ３１０以降を実行する。満たせない場合（Ｎｏ）はステップＳ３０７にて経路候補リストに対するループを終了する。

ステップＳ７０１ではアプリ要件テーブル５０よりアプリの通信要件毎の優先度を調べる。２つ以上の通信要件にて優先度が０より大きい値である場合、当該優先度が０より大きい通信要件のうち優先度が最も低いものを除外可能と判断する。ステップＳ７０１で除外可能と判断された場合（Ｙｅｓ）は、ステップＳ７０２ではステップＳ７００で除外可能と判断した通信要件の優先度を０にて上書きする。ステップＳ７０１で除外不可能と判断された場合（Ｎｏ）は、ステップＳ３０８へと進みアプリ配置失敗とする。

以上により通信要件のうち特に充足すべき要件を指定し、その要件を満たすアプリ配置を実現することができる。

（まとめ）
本実施例におけるアプリ要件保持部２１は、アプリの通信要件６４の項目ごとに優先度を保持し、性能検証部２６は、通信要件６４のうち満足されない項目が１つ以上あった場合に、優先度が最も低い項目を通信要件６４から除外し、通信要件６４が満たされるか否かを再度検証する。

以上のように構成した本実施例によれば、アプリの通信要件６４から優先度の低い項目を除外することにより、より多くのアプリを演算装置３，９へ配置することが可能となる。

以上、本発明の実施例について詳述したが、本発明は、上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は、本発明を分かり易く説明するために詳細に説明したものであり、本発明は必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成に他の実施例の構成の一部を加えることも可能であり、ある実施例の構成の一部を削除し、あるいは、他の実施例の一部と置き換えることも可能である。

１…車両、２…ゲートウェイ、３，３ａ～３ｄ…ドメインＥＣＵ（演算装置、車載電子制御装置）、４，４ａ～４ｄ…センサ、５，５ａ～５ｄ…アクチュエータ、６，６ａ～６ｄ…リンク、７…ＴＣＵ、８…セントラルＥＣＵ（演算装置、車載電子制御装置）、９，９ａ～９ｄ…ゾーンＥＣＵ（演算装置、車載電子制御装置）、１０…共有リンク、１１…ＣＰＵ、１２…メモリ、１３…ネットワークスイッチ、２０…空きリソース情報保持部、２１…アプリ要件保持部、２２…トポロジ情報保持部、２３…通信性能情報保持部、２４…アプリ配置選択部、２５…通信経路選択部、２６…性能検証部、２７…設定適用部、２８…シミュレーション部、２９…トポロジ変更監視部、３０…ＥＣＵ内空きリソース情報テーブル、３１…ＥＣＵ列、３２…計算リソース列、３３…記憶リソース列、３４…スペック列、４０…ＯＴＡデータ、４１…ヘッダ、４２…アプリデータ、４３…メタデータ、５０…アプリ要件テーブル、５１…アプリ列、５２…配置済みフラグ、５３…実行要件、５４…通信ＩＤ、５５…計算リソース列、５６…記憶リソース列、５７…スペック列、５８…通信仕様、５９…通信方向列、６０…通信相手列、６１…通信周期列、６２…パケットサイズ列、６３…アプリ識別情報、６４…通信要件、６５…通信帯域列、６６…通信遅延列、６７…ジッタ列、６８…廃棄率列、６９，６９ａ～６９ｄ…優先度列、７０…トポロジ情報テーブル、７１…リンク列、７２…種別列、７３…接続情報列、８０…通信性能情報テーブル、８１…リンク列、８２…通信方向、８３…総帯域列、８４…帯域列、８５…遅延時間列、８６…ジッタ列、８７…廃棄率列、８８…バッファ使用量列、９０…アプリ配置先ＥＣＵ候補リスト（アプリ配置先演算装置候補リスト）、９１…アプリ列、９２…配置先ＥＣＵ候補、１００…探索リスト、１０１…フェーズ、１０２…通信経路候補、１０３…状態、１１０…通信経路候補リスト、１１１…アプリ列、１１２…通信経路候補、１２０…通信経路リスト、１２１…アプリ列、１２２…通信経路、１３０…通信経路設定テーブル、１３１…ＥＣＵ列、１３２…アプリ識別情報、１３３…転送先ＥＣＵ。

Claims (10)

1. アプリの実行要件を満たすように、ネットワーク上に存在する複数の演算装置のいずれかへ前記アプリを配置するネットワークシステムにおいて、
   前記アプリの実行要件および通信要件を保持するアプリ要件保持部と、
   前記複数の演算装置の空きリソース情報を保持する空きリソース情報保持部と、
   前記実行要件と前記空きリソース情報とに基づいて、前記複数の演算装置の中から前記アプリを実行可能な演算装置を選択し、アプリ配置先演算装置候補リストを作成するアプリ配置選択部と、
   前記複数の演算装置の通信接続関係を示すトポロジ情報を保持するトポロジ情報保持部と、
   前記ネットワークの各リンクの通信性能情報を保持する通信性能情報保持部と、
   前記トポロジ情報に基づいて、前記アプリ配置先演算装置候補リスト内の各演算装置に前記アプリを配置した場合の前記アプリの通信経路を選択して通信経路候補リストを作成する通信経路選択部と、
   前記通信性能情報と前記通信要件とに基づいて、前記通信経路候補リスト内の各通信経路にて前記通信要件が満たされるか否かを検証する性能検証部と、
   前記アプリ配置先演算装置候補リスト内の演算装置のうち、前記性能検証部によって前記通信要件が満たされることが検証された通信経路に対応する演算装置に前記アプリを配置する設定適用部と、
   前記ネットワークのトポロジ変化を検出して前記ネットワーク上の前記リンクが正常に通信可能な状態であるか否かを監視し、前記リンクに異常が検出された場合、異常が検出された前記リンクの情報を前記トポロジ情報保持部が使用しないこととするトポロジ変更監視部と、
   を備え、
   前記リンクに異常が検出された場合、前記通信経路選択部、前記性能検証部および前記設定適用部により、異常が検出された前記リンクを避けたアプリ配置および通信経路を設定し、配置済み前記アプリを含めて前記アプリの再配置を行うことを特徴とするネットワークシステム。
2. 請求項１に記載のネットワークシステムにおいて、
   前記通信要件および前記通信性能情報は、前記アプリの通信帯域、通信遅延、通信ジッタ、およびパケット廃棄率のいずれか１つ以上を含む
   ことを特徴とするネットワークシステム。
3. 請求項１に記載のネットワークシステムにおいて、
   前記性能検証部は、前記通信経路候補リスト内の各通信経路にて前記通信要件が満たされるか否かを、前記通信性能情報と前記通信要件とに基づく数値計算により検証する
   ことを特徴とするネットワークシステム。
4. 請求項１に記載のネットワークシステムにおいて、
   前記性能検証部は、前記通信経路候補リスト内の各通信経路にて前記通信要件が満たされるか否かを、前記通信性能情報と前記通信要件とに基づくシミュレーションにより検証する
   ことを特徴とするネットワークシステム。
5. 請求項１に記載のネットワークシステムにおいて、
   前記アプリ要件保持部は、前記アプリごとに優先度を保持し、
   前記アプリ配置選択部は、優先度の高い前記アプリから順に前記アプリ配置先演算装置候補リストを作成する
   ことを特徴とするネットワークシステム。
6. 請求項１に記載のネットワークシステムにおいて、
   前記アプリ要件保持部は、前記通信要件の項目ごとの優先度を保持し、
   前記性能検証部は、前記通信要件のうち満足されない項目が１つ以上あった場合に、優先度が最も低い項目を前記通信要件から除外し、前記通信要件が満たされるか否かを再度検証する
   ことを特徴とするネットワークシステム。
7. 請求項１に記載のネットワークシステムにおいて、
   前記アプリを配置する際に前記アプリとともに前記ネットワークに入力されるメタデータは、
   計算リソース、記憶リソース、およびスペックのいずれか１以上を含む前記実行要件と、
   通信方向、通信相手、通信周期、通信データサイズ、および通信識別情報のいずれか１以上を含む通信仕様と、
   通信帯域、通信遅延、通信ジッタ、パケット廃棄率のいずれか１以上を含む前記通信要件とを含む
   ことを特徴とするネットワークシステム。
8. 請求項１に記載のネットワークシステムにおいて、
   前記ネットワークは、車両に搭載された車載ネットワークであり、
   前記複数の演算装置は、前記車両に搭載された複数の車載電子制御装置である
   ことを特徴とするネットワークシステム。
9. 請求項８に記載のネットワークシステムを備える
   ことを特徴とする車載装置。
10. 請求項８に記載のネットワークシステムにおいて、
    前記通信要件は、前記車両に搭載されたセンサから出力されるセンサデータ、前記車両を制御するための制御データ、および前記センサデータから前記制御データを求める演算の途中で得られる中間データに関する項目を含む
    ことを特徴とするネットワークシステム。