特開 2024-77372 制御装置、リソース管理方法、リソース管理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024077372

(43)【公開日】2024-06-07

(54)【発明の名称】制御装置、リソース管理方法、リソース管理プログラム

(51)【国際特許分類】

   G06F 9/50 20060101AFI20240531BHJP

   G06F 9/455 20180101ALI20240531BHJP

【ＦＩ】

G06F9/50 120A

G06F9/455 150

【審査請求】未請求

【請求項の数】22

【出願形態】ＯＬ

(21)【出願番号】P 2022189434

(22)【出願日】2022-11-28

(71)【出願人】

【識別番号】000004260

【氏名又は名称】株式会社デンソー

(74)【代理人】

【氏名又は名称】矢作 和行

(74)【代理人】

【識別番号】100121991

【弁理士】

【氏名又は名称】野々部 泰平

(74)【代理人】

【識別番号】100145595

【弁理士】

【氏名又は名称】久保 貴則

(72)【発明者】

【氏名】柴田 章博

(72)【発明者】

【氏名】林 功治

(57)【要約】

【課題】自動運転処理を実行可能な高性能なハードウェアリソースを有効活用する制御装置の提供。
【解決手段】制御装置３は、車両２の自動運転処理を実行する自動運転アプリケーション３３０を、ホストＯＳ３０上において動作させる自動運転コンテナ３３と、ユーザ指定されるユーザアプリケーション３４０を、ホストＯＳ３０上において動作させるユーザコンテナ３４と、自動運転アプリケーション３３０及びユーザアプリケーション３４０への、ハードウェアリソース１２の割り当てを管理する、コンテナ管理レイヤ３２と、を備える。コンテナ管理レイヤ３２は、自動運転アプリケーション３３０の動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２をユーザアプリケーション３４０に割り当てる。
【選択図】図２

【特許請求の範囲】

【請求項1】

複数のコンテナ（３３，３４）にハードウェアリソース（１２）及びホストＯＳ（３０）を共有させる、制御装置（３）であって、
車両の自動運転処理を実行する自動運転アプリケーション（３３０）を、前記ホストＯＳ上において動作させる自動運転コンテナ（３３）と、
ユーザ指定されるユーザアプリケーション（３４０）を、前記ホストＯＳ上において動作させるユーザコンテナ（３４）と、
前記自動運転アプリケーション及び前記ユーザアプリケーションへの、前記ハードウェアリソースの割り当てを管理する、コンテナ管理レイヤ（３２）と、を備え、
前記コンテナ管理レイヤは、前記自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、前記自動運転アプリケーションの動作継続に要する前記ハードウェアリソースに応じた残りの前記ハードウェアリソースを前記ユーザアプリケーションに割り当てる、制御装置。

【請求項2】

前記低負荷条件は、前記車両が駐車モードとなった場合に成立する、請求項１に記載の制御装置。

【請求項3】

前記低負荷条件は、前記車両のパーキングブレーキが有効となった場合に成立する、請求項２に記載の制御装置。

【請求項4】

前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両が充電中となった場合に成立する、請求項３に記載の制御装置。

【請求項5】

前記低負荷条件は、前記パーキングブレーキが有効となってから一定時間以上経過したとなった場合に成立する、請求項３に記載の制御装置。

【請求項6】

前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両の始動スイッチがオフとなった場合に成立する、請求項３に記載の制御装置。

【請求項7】

前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両のシフト位置がパーキング位置となった場合に成立する、請求項３に記載の制御装置。

【請求項8】

前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両のブレーキペダルが踏み込まれていない場合に成立する、請求項３に記載の制御装置。

【請求項9】

前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両の現在位置が駐車場内にある場合に成立する、請求項３に記載の制御装置。

【請求項10】

前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両を解錠する解錠ユニットと当該車両との距離が条件範囲外に増大した場合に成立する、請求項３に記載の制御装置。

【請求項11】

前記低負荷条件は、前記車両が手動運転モードとなった場合に成立する、請求項１に記載の制御装置。

【請求項12】

前記低負荷条件は、前記自動運転処理により実行された前記車両のオートパイロット機能が無効となった場合に成立する、請求項１１に記載の制御装置。

【請求項13】

前記低負荷条件は、前記自動運転処理により設定された運行設計領域外となった場合に成立する、請求項１１に記載の制御装置。

【請求項14】

前記低負荷条件は、前記動作負荷の前記設定範囲内への低下時間が設定時間以上継続した場合に成立する、請求項３に記載の制御装置。

【請求項15】

前記ユーザアプリケーションは、前記自動運転処理に関する機械学習モデルのパラメータを更新する機械学習アプリケーションである、請求項１に記載の制御装置。

【請求項16】

前記ユーザアプリケーションは、前記ハードウェアリソースを外部へ貸し出すレンタルアプリケーションである、請求項１に記載の制御装置。

【請求項17】

前記ユーザアプリケーションは、前記車両に関するリリース前のアプリケーションを仮想環境にてテスト動作させるアプリケーションである、請求項１に記載の制御装置。

【請求項18】

前記コンテナ管理レイヤは、前記ユーザアプリケーションによる前記自動運転コンテナへのアクセスを禁止する、請求項１に記載の制御装置。

【請求項19】

前記コンテナ管理レイヤは、前記ユーザアプリケーションによる前記ハードウェアリソース外へのアクセスを禁止する、請求項１に記載の制御装置。

【請求項20】

前記コンテナ管理レイヤは、前記低負荷条件が不成立となる場合に、前記ユーザアプリケーションへの前記ハードウェアリソースの割り当てを中止する、請求項１に記載の制御装置。

【請求項21】

複数のコンテナ（３３，３４）にハードウェアリソース（１２）及びホストＯＳ（３０）を共有させるために、プロセッサ（１１）に実行されるリソース管理方法であって、
車両（２）の自動運転処理を実行する自動運転アプリケーション（３３０）を、前記ホストＯＳ上において動作させることと、
ユーザ指定されるユーザアプリケーション（３４０）を、前記ホストＯＳ上において動作させることと、
前記自動運転アプリケーション及び前記ユーザアプリケーションへの、前記ハードウェアリソースの割り当てを管理することと、を含み、
前記ハードウェアリソースの割り当てを管理することは、前記自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、前記自動運転アプリケーションの動作継続に要する前記ハードウェアリソースに応じた残りの前記ハードウェアリソースを前記ユーザアプリケーションに割り当てることを含む、リソース管理方法。

【請求項22】

記憶媒体（１０）に記憶され、複数のコンテナ（３３，３４）にハードウェアリソース（１２）及びホストＯＳ（３０）を共有させるためにプロセッサ（１１）に実行させる命令を含むリソース管理プログラムであって、
前記命令は、
車両（２）の自動運転処理を実行する自動運転アプリケーション（３３０）を、前記ホストＯＳ上において動作させることと、
ユーザ指定されるユーザアプリケーション（３４０）を、前記ホストＯＳ上において動作させることと、
前記自動運転アプリケーション及び前記ユーザアプリケーションへの、前記ハードウェアリソースの割り当てを管理することと、を含み、
前記ハードウェアリソースの割り当てを管理することは、前記自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、前記自動運転アプリケーションの動作継続に要する前記ハードウェアリソースに応じた残りの前記ハードウェアリソースを前記ユーザアプリケーションに割り当てることを含む、リソース管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、複数のコンテナにハードウェアリソース及びホストＯＳを共有させるコンテナ型仮想化技術に、関する。

【背景技術】

【0002】

例えば特許文献１に開示される制御装置は、膨大な計算リソースを必要とする自動運転処理を実行するために、高性能なハードウェアを備えている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】米国特許第１００９９６３０号明細書

【発明の概要】

【発明が解決しようとする課題】

【0004】

一般に制御装置において、車両の自動運転処理を実行するための高性能なハードウェアリソースは、自動運転アプリケーションの実行に静的に割り当てられている。そのため、自動運転アプリケーション非動作時等の動作負荷低下時には、ハードウェアリソースの遊休時間が発生するおそれがあった。

【0005】

本開示の課題は、自動運転処理を実行可能な高性能なハードウェアリソースを有効活用する制御装置を、提供することにある。

【課題を解決するための手段】

【0006】

本開示の第一態様による制御装置は、複数のコンテナにハードウェアリソース及びホストＯＳを共有させる、制御装置であって、
車両の自動運転処理を実行する自動運転アプリケーションを、ホストＯＳ上において動作させる自動運転コンテナと、
ユーザ指定されるユーザアプリケーションを、ホストＯＳ上において動作させるユーザコンテナと、
自動運転アプリケーション及びユーザアプリケーションへの、ハードウェアリソースの割り当てを管理する、コンテナ管理レイヤと、を備え、
コンテナ管理レイヤは、自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、自動運転アプリケーションの動作継続に要するハードウェアリソースに応じた残りのハードウェアリソースをユーザアプリケーションに割り当てる。

【0007】

本開示の第二態様によるリソース管理方法は、複数のコンテナにハードウェアリソース及びホストＯＳを共有させるために、プロセッサに実行されるリソース管理方法であって、
車両の自動運転処理を実行する自動運転アプリケーションを、ホストＯＳ上において動作させることと、
ユーザ指定されるユーザアプリケーションを、ホストＯＳ上において動作させることと、
自動運転アプリケーション及びユーザアプリケーションへの、ハードウェアリソースの割り当てを管理することと、を含み、
ハードウェアリソースの割り当てを管理することは、自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、自動運転アプリケーションの動作継続に要するハードウェアリソースに応じた残りのハードウェアリソースをユーザアプリケーションに割り当てることを含む。

【0008】

本開示の第三態様によるリソース管理プログラムは、記憶媒体に記憶され、複数のコンテナにハードウェアリソース及びホストＯＳを共有させるためにプロセッサに実行させる命令を含むリソース管理プログラムであって、
命令は、
車両の自動運転処理を実行する自動運転アプリケーションを、ホストＯＳ上において動作させることと、
ユーザ指定されるユーザアプリケーションを、ホストＯＳ上において動作させることと、
自動運転アプリケーション及びユーザアプリケーションへの、ハードウェアリソースの割り当てを管理することと、を含み、
ハードウェアリソースの割り当てを管理することは、自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、自動運転アプリケーションの動作継続に要するハードウェアリソースに応じた残りのハードウェアリソースをユーザアプリケーションに割り当てることを含む。

【0009】

このように本開示の第一～第三態様によれば、自動運転処理を実行する自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、自動運転アプリケーションの動作継続に要するハードウェアリソースに応じた残りのハードウェアリソースがユーザアプリケーションに割り当てられる。これによれば、自動運転アプリケーションの動作負荷低下に伴って解放されるハードウェアリソースを、自動運転処理とは独立したユーザ向けのユーザアプリケーションに割り当てることができる。故に、自動運転処理を実行可能な高性能なハードウェアリソースを有効活用することが、可能となる。

【図面の簡単な説明】

【0010】

【図1】本開示の第一実施形態による制御装置の搭載された車両を示す模式図である。

【図2】本開示の第一実施形態による制御装置を示す模式図である。

【図3】本開示の第一実施形態によるリソース管理フローを示すフローチャートである。

【図4】本開示の第二実施形態による制御装置を示す模式図である。

【図5】本開示の第二実施形態によるリソース管理フローを示すフローチャートである。

【図6】本開示の第三実施形態による制御装置を示す模式図である。

【図7】本開示の第三実施形態によるリソース管理フローを示すフローチャートである。

【図8】本開示の第四実施形態による制御装置を示す模式図である。

【図9】本開示の第四実施形態によるリソース管理フローを示すフローチャートである。

【図10】本開示の第五実施形態による制御装置を示す模式図である。

【図11】本開示の第五実施形態によるリソース管理フローを示すフローチャートである。

【図12】本開示の第六実施形態による制御装置を示す模式図である。

【図13】本開示の第六実施形態によるリソース管理フローを示すフローチャートである。

【図14】本開示の第七実施形態による制御装置を示す模式図である。

【図15】本開示の第七実施形態によるリソース管理フローを示すフローチャートである。

【図16】本開示の第八実施形態による制御装置を示す模式図である。

【図17】本開示の第八実施形態によるリソース管理フローを示すフローチャートである。

【図18】本開示の第九実施形態による制御装置を示す模式図である。

【図19】本開示の第九実施形態によるリソース管理フローを示すフローチャートである。

【図20】本開示の第十実施形態による制御装置を示す模式図である。

【図21】本開示の第十実施形態によるリソース管理フローを示すフローチャートである。

【図22】第二実施形態の変形例による制御装置を示す模式図である。

【図23】第二実施形態の変形例によるリソース管理フローを示すフローチャートである。

【発明を実施するための形態】

【0011】

以下、本開示の実施形態を図面に基づき複数説明する。尚、各実施形態において対応する構成要素には同一の符号を付すことで、重複する説明を省略する場合がある。また、各実施形態において構成の一部分のみを説明している場合、当該構成の他の部分については、先行して説明した他の実施形態の構成を適用することができる。さらに、各実施形態の説明において明示している構成の組み合わせばかりではなく、特に組み合わせに支障が生じなければ、明示していなくても複数の実施形態の構成同士を部分的に組み合わせることができる。

【0012】

（第一実施形態）
図１，２に示す第一実施形態の制御装置３は、複数のコンテナにハードウェアリソース１２及びホストＯＳ３０を共有させる。車両２においては、運転タスクにおける乗員の手動介入度に応じてレベル分けされる、自動運転モードが与えられる。自動運転モードは、条件付運転自動化、高度運転自動化、又は完全運転自動化といった、作動時のシステムが全ての運転タスクを実行する自律走行制御により、実現されてもよい。自動運転モードは、運転支援、又は部分運転自動化といった、乗員が一部若しくは全ての運転タスクを実行する高度運転支援制御により、実現されてもよい。自動運転モードは、それら自律走行制御と高度運転支援制御とのいずれか一方、組み合わせ、又は切り替えにより実現されてもよい。自動運転モードは、後述の自動運転処理に基づく走行制御により、達成される。

【0013】

図１に示すように車両２には、センサ系４、アプリケーション指定端末５、及び制御装置３が搭載される。センサ系４は、制御装置３により利用可能なセンサ情報を、車両２の外界及び内界の検出により取得する。そのためにセンサ系４は、外界センサ４０及び内界センサ４２を含んで構成されている。尚、図１～２１において、図示の都合上、「アプリケーション」を「アプリ」と略記している。

【0014】

外界センサ４０は、車両２の周辺環境となる外界の情報を、取得する。外界センサ４０は、車両２の外界に存在する物標を検知することで、外界情報を取得してもよい。物標検知タイプの外界センサ４０は、例えばカメラ、ＬｉＤＡＲ（Light Detection and Ranging / Laser Imaging Detection and Ranging）、レーダ、及びソナー等のうち、少なくとも一種類である。外界センサ４０は、車両２の外界に存在するＧＮＳＳ（Global Navigation Satellite System）の人工衛星から測位信号を受信することで、外界情報を取得してもよい。測位タイプの外界センサ４０は、例えばＧＮＳＳ受信機等である。外界センサ４０は、車両２の外界に存在するＶ２Ｘシステムとの間において通信信号を送受信することで、外界情報を取得してもよい。通信タイプの外界センサ４０は、例えばＤＳＲＣ（Dedicated Short Range Communications）通信機、セルラＶ２Ｘ（C-V2X）通信機、ブルートゥース（Bluetooth：登録商標）機器、Ｗｉ－Ｆｉ（登録商標）機器、及び赤外線通信機器等のうち、少なくとも一種類である。

【0015】

内界センサ４２は、車両２の内部環境となる内界のセンサ情報を、取得する。内界センサ４２は、車両２の内界において特定の運動物理量を検知することで、内界情報を取得してもよい。物理量検知タイプの内界センサ４２は、例えば走行速度センサ、加速度センサ、及びジャイロセンサ等のうち、少なくとも一種類である。内界センサ４２は、車両２の内界において乗員の特定状態を検知することで、内界情報を取得してもよい。乗員検知タイプの内界センサ４２は、例えばドライバーステータスモニター（登録商標）、生体センサ、着座センサ、アクチュエータセンサ、及び車内機器センサ等のうち、少なくとも一種類である。

【0016】

ここでアクチェータセンサは、車両２の走行アクチュエータに対するドライバの指示状態として、例えばアクセルペダルの操作状態、ブレーキペダルの操作状態、パーキングブレーキの操作状態、ステアリングホイールの操舵状態、始動スイッチのオンオフ状態、及び車両２のシフト位置、車両２の充電状態等のうち、少なくとも一種類を検知する。車内機器センサは、車内機器に対するドライバ及び他乗員の指示状態として、例えばオンオフスイッチの操作状態、タッチパネルの操作状態、及び非接触認識可能なジェスチャー等のうち、少なくとも一種類を検知する。

【0017】

アプリケーション指定端末５は、ユーザによるタッチ操作等の操作を受付可能な、例えばセンターディスプレイである。アプリケーション指定端末５は、図２に示す外部のコンテナイメージサーバ６からダウンロード可能なアプリケーションを表示する。車両２の乗員であるユーザは、アプリケーション指定端末５に表示のアプリケーションを選択することで、ユーザアプリケーション３４０として制御装置３に実行させるアプリケーションを指定可能となっている。

【0018】

ここでコンテナイメージサーバ６は、種々のコンテナイメージを保存している、例えばドッカーハブ（Ｄｏｃｋｅｒ Ｈｕｂ）リポジドリ等である。各コンテナイメージには、コンテナ構成ファイルとして、アプリケーション及び当該アプリケーション実行に必要なミドルウェア及びライブラリ等が含まれている。

【0019】

図１，２に示すように制御装置３は、例えばＬＡＮ（Local Area Network）回線、ワイヤハーネス、内部バス、及び無線通信回線等のうち、少なくとも一種類を介してセンサ系４及びアプリケーション指定端末５に接続されている。制御装置３は、少なくとも一つの専用コンピュータを含んで構成されている。

【0020】

制御装置３を構成する専用コンピュータは、車両２の運転制御を統合する、統合ＥＣＵ（Electronic Control Unit）であってもよい。制御装置３を構成する専用コンピュータは、車両２の運転制御における運転タスクを判断する、判断ＥＣＵであってもよい。制御装置３を構成する専用コンピュータは、車両２の運転制御を監視する、監視ＥＣＵであってもよい。制御装置３を構成する専用コンピュータは、車両２の運転制御を評価する、評価ＥＣＵであってもよい。

【0021】

制御装置３を構成する専用コンピュータは、図１に示すように制御装置３のハードウェアリソース１２としてのメモリ１０及びプロセッサ１１を、少なくとも一つずつ有している。メモリ１０は、コンピュータにより読み取り可能なプログラム及びデータ等を非一時的に記憶する、例えば半導体メモリ、磁気媒体、及び光学媒体等のうち、少なくとも一種類の非遷移的実体的記憶媒体（non-transitory tangible storage medium）である。高負荷な自動運転処理を行うためにプロセッサ１１は、処理能力の高い例えばＧＰＵ（Graphics Processing Unit）をコアとして含む。さらにプロセッサ１１は、例えばＣＰＵ（Central Processing Unit）、ＲＩＳＣ（Reduced Instruction Set Computer）－ＣＰＵ、ＤＦＰ（Data Flow Processor）、及びＧＳＰ（Graph Streaming Processor）等のうち、少なくとも一種類をコアとしてさらに含んでもよい。

【0022】

メモリ１０には、図２に示すホストＯＳ（Operating System）３０、コンテナエンジン３１、及びリソース管理プログラム（図示省略）等の、プロセッサ１１上で動作するソフトウェアに加えて、同図に示す自動運転コンテナ３３及びユーザコンテナ３４を構築するための、自動運転コンテナイメージ及びユーザコンテナイメージが保存されている。ホストＯＳ３０は、例えばリアルタイムＯＳ、Ｌｉｎｕｘ（登録商標）、及びＵＮＩＸ（登録商標）等のうち、少なくとも一種類であってもよい。

【0023】

プロセッサ１１は、複数のコンテナにハードウェアリソース１２及びホストＯＳ３０を共有させるためにメモリ１０に記憶された、リソース管理プログラムに含まれる複数の命令を実行する。これにより制御装置３は、複数のコンテナにハードウェアリソース１２及びホストＯＳ３０を共有させるためのコンテナ管理レイヤ３２を、少なくとも一層構築する。それと共に制御装置３は、自動運転コンテナイメージ及びユーザコンテナイメージに基づき、自動運転コンテナ３３及びユーザコンテナ３４を構築する。

【0024】

コンテナエンジン３１は、各コンテナのアプリケーションを実行するための環境をまとめる、例えばドッカー（Ｄｏｃｋｅｒ）等のソフトウェアである。コンテナエンジン３１は、自動運転コンテナ３３に含まれる自動運転アプリケーション３３０、及びユーザコンテナ３４に含まれるユーザアプリケーション３４０を、ホストＯＳ３０上において動作させる。

【0025】

自動運転コンテナ３３は、自動運転アプリケーション３３０、及びミドルウェア（図示省略）を含む。自動運転アプリケーション３３０は、センサ系４により取得のセンサ情報に基づいて、車両２の自動運転処理を実行する。自動運転アプリケーション３３０により実行される自動運転処理には、例えば外界の認識処理、及び走行の計画処理等といった、高負荷な処理が含まれる。

【0026】

ユーザコンテナ３４は、ホストＯＳ３０及び制御装置３のハードウェアリソース１２を、自動運転コンテナ３３と共有する。ユーザコンテナ３４は、ユーザ指定のユーザアプリエーション３４０、及びミドルウェア（図示省略）を含む。ここでユーザアプリケーション３４０は、実行に高性能なハードウェアリソース１２を必要とする、高負荷アプリケーションであってもよい。

【0027】

ユーザアプリケーション３４０は、車両２の自動運転に関する機械学習モデルのパラメータを更新する、機械学習アプリケーションであってもよい。機械学習アプリケーションである場合のユーザアプリケーション３４０は、機械学習モデルのパラメータを外部センタへフィードバックするものであってもよいし、パラメータ自体を直接更新するものであってもよい。

【0028】

ユーザアプリケーション３４０は、制御装置３のハードウェアリソース１２を外部の例えばサーバ等へ貸し出す、レンタルアプリケーションであってもよい。レンタルアプリケーションである場合のユーザアプリケーション３４０は、例えばＩａａＳ（Infrastructure As A Service）又はＰａａＳ（Platform As A Service）等としてハードウェアリソース１２を貸し出すものであってもよいし、仮想通貨のマイニングにハードウェアリソース１２を貸し出すものであってもよい。

【0029】

ユーザアプリケーション３４０は、車両２に関するリリース前のアプリケーションを仮想環境にてテスト動作させるものであってもよい。ユーザアプリケーション３４０は、ＯＴＡ（On The Air）による外部から車両２への配信によりソフトウェアを更新する、更新アプリケーションであってもよい。ユーザアプリケーション３４０は、センサ系４により取得のセンサ情報の前処理と当該前処理により得られたデータを外部の例えばサーバ等へアップロードする、センシング前処理アプリケーションであってもよい。

【0030】

ユーザアプリケーション３４０は、例えば映画等の動画コンテンツを再生する、メディアアプリケーションであってもよい。ユーザアプリケーション３４０は、動画データ及び／又は音声データのエンコードを行う、エンコーダアプリケーションであってもよい。ユーザアプリケーション３４０は、動画データ及び／又は静止画データのアップコンバートを行う、アップコンバートアプリケーションであってもよい。ユーザアプリケーション３４０は、例えば数値シミュレーション、又は新薬探索シミュレーションシ等を行う、シミュレーションアプリケーションであってもよい。

【0031】

コンテナ管理レイヤ３２は、センサ系４により取得のセンサ情報に基づいて、自動運転アプリケーション３３０とユーザアプリケーション３４０との各々へのハードウェアリソース１２の割り当てを管理する。具体的にコンテナ管理レイヤ３２は、自動運転アプリケーション３３０の動作負荷が設定範囲内に低下する低負荷条件が成立するか否かを、判定する。ここで設定範囲は、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２により、ユーザアプリケーション３４０の動作に必要なハードウェアリソース１２を確保可能となる範囲に設定される。低負荷条件が成立する場合にコンテナ管理レイヤ３２は、、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２を、ユーザアプリケーション３４０に割り当てる。一方、コンテナ管理レイヤ３２は低負荷条件が成立しない場合にコンテナ管理レイヤ３２は、ユーザアプリケーション３４０へのハードウェアリソース１２の割り当てを中止することで、ユーザアプリケーション３４０の実行を停止する。第一及び後述の第二～第八実施形態の低負荷条件は、車両２が駐車モードとなった場合に成立する。特に第一実施形態の低負荷条件は、車両２のパーキングブレーキが有効となった場合に成立する。

【0032】

コンテナ管理レイヤ３２は、アプリケーション指定端末５に対する操作によりユーザがアプリケーションを指定した場合には、ユーザ指定のアプリケーションを含むコンテナイメージがメモリ１０に存在するか否かを、確認する。ユーザ指定のアプリケーションを含むコンテナイメージがメモリ１０に存在しない場合にコンテナ管理レイヤ３２は、当該コンテナイメージをコンテナイメージサーバ６からのダウンロードにより取得すると共に、取得したコンテナイメージに基づくユーザコンテナ３４を構築する。

【0033】

コンテナ管理レイヤ３２は、車両２の運転関連部分へのユーザアプリケーション３４０によるアクセスを、禁止する。運転関連部分へのアクセス禁止としてコンテナ管理レイヤ３２は、ユーザアプリケーション３４０による自動運転コンテナ３３へのアクセスを禁止してもよい。運転関連部分へのアクセス禁止としてコンテナ管理レイヤ３２は、ユーザアプリケーション３４０によるハードウェアリソース１２外へのアクセスを禁止してもよい。

【0034】

以上説明した制御装置３によるリソース管理方法のフローを、図３に従って以下に説明する。尚、本フローにおける各「Ｓ」は、リソース管理プログラムに含まれた複数命令によって実行される複数ステップを、それぞれ意味している。このリソース管理フローは、制御装置３の制御周期毎に開始される。

【0035】

Ｓ１０１においてコンテナ管理レイヤ３２は、センサ系４からセンサ情報を取得する。このとき、第一実施形態によるコンテナ管理レイヤ３２は、センサ情報として少なくとも、車両２におけるパーキングブレーキの操作状態を、取得する。

【0036】

Ｓ１０１に続くＳ１０２においてコンテナ管理レイヤ３２は、Ｓ１０１にて取得のセンサ情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ３２は、パーキングブレーキが有効であるか否かを、判定する。Ｓ１０２において肯定判定が下された場合にリソース管理フローは、Ｓ１０３へ進む。一方、Ｓ１０２において否定判定が下された場合にリソース管理フローは、Ｓ１０４へ進む。

【0037】

低負荷条件が成立している場合のＳ１０３においてコンテナ管理レイヤ３２は、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２を、ユーザアプリケーション３４０に割り当てる。

【0038】

一方、低負荷条件が不成立となる場合のＳ１０４においてコンテナ管理レイヤ３２は、ユーザアプリケーション３４０へのハードウェアリソース１２の割り当てを中止する。

【0039】

（作用効果）
以上説明した第一実施形態の作用効果を、以下に説明する。

【0040】

第一実施形態によるコンテナ管理レイヤ３２は、自動運転処理を実行する自動運転アプリケーション３３０の動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２をユーザアプリケーション３４０に割り当てる。これによれば、自動運転アプリケーション３３０の動作負荷低下に伴って解放されるハードウェアリソース１２を、自動運転処理とは独立したユーザ向けのユーザアプリケーション３４０に割り当てることができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を有効活用することが、可能となる。

【0041】

第一実施形態によると、低負荷条件は、車両２が駐車モードとなった場合に成立する。これによれば、自動運転アプリケーション３３０の動作負荷が低下する駐車モード時に、ハードウェアリソース１２をユーザアプリケーション３４０に割り当てることができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に伴って有効活用することが、可能となる。

【0042】

第一実施形態によると、低負荷条件は、パーキングブレーキが有効となった場合に成立する。これによれば、車両２が駐車モードとなったことをパーキングブレーキの操作状態に基づき認識するのに合わせて、ハードウェアリソース１２の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に応じた適時に有効活用することが、可能となる。

【0043】

第一実施形態によると、ユーザアプリケーション３４０は、車両運転に関する機械学習モデルのパラメータを更新する機械学習アプリケーションであってもよい。この場合には、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に伴って有効活用して、機械学習モデルのパラメータを更新することが、可能となる。

【0044】

第一実施形態によると、ユーザアプリケーション３４０は、制御装置３のハードウェアリソース１２を外部へ貸し出すレンタルアプリケーションであってもよい。この場合には、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に伴って有効活用して、外部サーバ等の計算負荷を軽減することが、可能となる。

【0045】

第一実施形態によると、ユーザアプリケーション３４０は、リリース前のアプリケーションを仮想環境にてテスト動作させるものであってもよい。この場合には、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に伴って有効活用して、正式運用前のアプリケーションの実機テストを行うことが、可能となる。

【0046】

第一実施形態によるコンテナ管理レイヤ３２は、ユーザアプリケーション３４０による自動運転コンテナ３３へのアクセスを禁止してもよい。この場合には、ユーザアプリケーション３４０の動作による自動運転処理への影響を、抑止することができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を有効活用する上で、車両２の安全性を高めることが可能となる。

【0047】

第一実施形態によるコンテナ管理レイヤ３２は、ユーザアプリケーション３４０によるハードウェアリソース１２外へのアクセスを禁止してもよい。この場合には、ユーザアプリケーション３４０の動作による車両運転操作への影響を、抑制することができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を、安全に有効活用することが可能となる。

【0048】

第一実施形態によるコンテナ管理レイヤ３２は、低負荷条件が不成立となる場合に、ユーザアプリケーション３４０へのハードウェアリソース１２の割り当てを中止する。これによれば、自動運転アプリケーション３３０の動作負荷が低下しない場合のハードウェアリソース１２を、自動運転処理に適切に割り当てることができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を有効活用する上で、車両２の安全性を高めることが可能となる。

【0049】

（第二実施形態）
図４，５に示す第二実施形態は、車両２が充電可能な場合に採用可能な、第一実施形態の変形例である。第二実施形態では、自動運転アプリケーション３３０の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。

【0050】

第二実施形態の低負荷条件は、車両２のパーキングブレーキが有効、かつ、車両２が充電中となった場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ３２ａは、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２を、ユーザアプリケーション３４０に割り当てる。

【0051】

以下、第二実施形態の制御装置３によるリソース管理フローを、図５のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置３の制御周期毎に開始される。

【0052】

第二実施形態のリソース管理フローにおいてＳ１０１に代わるＳ２０１では、コンテナ管理レイヤ３２ａは、センサ情報として少なくとも、車両２におけるパーキングブレーキの操作状態、及び車両２における充電状態を、センサ系４から取得する。

【0053】

第二実施形態のリソース管理フローにおいてＳ１０２に代わるＳ２０２では、コンテナ管理レイヤ３２ａは、Ｓ２０１にて取得のセンサ情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ３２ａは、車両２のパーキングブレーキが有効、かつ、車両２が充電中となったか否かを判定する。Ｓ２０２において肯定判定が下された場合、リソース管理フローはＳ１０３へ進む。一方、Ｓ２０２において否定判定が下された場合、リソース管理フローＳ１０４へ進む。

【0054】

このように第二実施形態によると、低負荷条件は、パーキングブレーキが有効、かつ、車両２が充電中となった場合に成立する。これによれば、車両２が駐車モードとなったことをパーキングブレーキの操作状態だけでなく、車両２の充電状態にも基づき認識するのに合わせて、ハードウェアリソース１２の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に応じた適時に有効活用することが、可能となる。

【0055】

（第三実施形態）
図６，７に示す第三実施形態は、第一実施形態の変形例である。第三実施形態では、自動運転アプリケーション３３０の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。

【0056】

第三実施形態の低負荷条件は、車両２のパーキングブレーキが有効となってから一定時間以上経過した場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ３２ｂは、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２を、ユーザアプリケーション３４０に割り当てる。

【0057】

以下、第三実施形態の制御装置３によるリソース管理フローを、図７のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置３の制御周期毎に開始される。

【0058】

第三実施形態のリソース管理フローにおいてＳ１０１に続くＳ１０２に代わるＳ３０２では、コンテナ管理レイヤ３２ｂは、Ｓ１０１にて取得のセンサ情報と、制御装置３の内部クロック情報とに基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ３２ｂは、車両２のパーキングブレーキが有効となってから、一定時間以上経過したか否かを判定する。Ｓ３０２において肯定判定がされた場合、リソース管理フローはＳ１０３へ進む。一方、Ｓ３０２において否定判定が下された場合、リソース管理フローはＳ１０４へ進む。

【0059】

このように第三実施形態によると、低負荷条件は、パーキングブレーキが有効となってから一定時間以上経過した場合に成立する。これによれば、車両２が駐車モードとなったことを、パーキングブレーキが有効となってからの経過時間に基づき認識するのに合わせて、ハードウェアリソース１２の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に応じた適時に有効活用することが、可能となる。

【0060】

尚、Ｓ３０２は、動作負荷の設定範囲内への低下時間が設定時間以上継続したか否か、と読み替えてもよい。この場合、第三実施形態の低負荷条件は、車両２のパーキングブレーキの有効状態が設定時間以上継続した場合に成立する。

【0061】

（第四実施形態）
図８，９に示す第四実施形態は、第一実施形態の変形例である。第四実施形態では、自動運転アプリケーション３３０の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。

【0062】

第四実施形態の低負荷条件は、車両２のパーキングブレーキが有効、かつ、車両２の始動スイッチがオフとなった場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ３２ｃは、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２を、ユーザアプリケーション３４０に割り当てる。

【0063】

以下、第四実施形態の制御装置３によるリソース管理フローを、図９のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置３の制御周期毎に開始される。

【0064】

第四実施形態のリソース管理フローにおいてＳ１０１に代わるＳ４０１では、コンテナ管理レイヤ３２ｃは、センサ情報として少なくとも、パーキングブレーキの操作状態、及び始動スイッチのオンオフ状態を、センサ系４から取得する。

【0065】

第四実施形態のリソース管理フローにおいてＳ１０２に代わるＳ４０２では、コンテナ管理レイヤ３２ｃは、Ｓ４０１にて取得のセンサ情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ３２ｃは、車両２のパーキングブレーキが有効、かつ、車両２の始動スイッチがオフとなったか否かを判定する。Ｓ４０２において肯定判定がされた場合、リソース管理フローはＳ１０３へ進む。一方、Ｓ４０２において否定判定が下された場合、リソース管理フローはＳ１０４へ進む。

【0066】

このように第四実施形態によると、低負荷条件は、パーキングブレーキが有効、かつ、車両２の始動スイッチがオフとなった場合に成立する。これによれば、車両２が駐車モードとなったことを、パーキングブレーキの操作状態だけでなく、車両２の始動スイッチ状態にも基づき認識するのに合わせて、ハードウェアリソース１２の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に応じた適時に有効活用することが、可能となる。

【0067】

（第五実施形態）
図１０，１１に示す第五実施形態は、第一実施形態の変形例である。第五実施形態では、自動運転アプリケーション３３０の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。

【0068】

第五実施形態の低負荷条件は、車両２のパーキングブレーキが有効、かつ、車両２のシフト位置がパーキング位置となった場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ３２ｄは、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２を、ユーザアプリケーション３４０に割り当てる。

【0069】

以下、第五実施形態の制御装置３によるリソース管理フローを、図１１のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置３の制御周期毎に開始される。

【0070】

第五実施形態のリソース管理フローにおいてＳ１０１に代わるＳ５０１では、コンテナ管理レイヤ３２ｄは、センサ情報として少なくとも、パーキングブレーキの操作状態、及びシフト位置を、センサ系４から取得する。

【0071】

第五実施形態のリソース管理フローにおいてＳ１０２に代わるＳ５０２では、コンテナ管理レイヤ３２ｄは、Ｓ５０１にて取得のセンサ情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ３２ｄは、車両２のパーキングブレーキが有効、かつ、車両２のシフト位置がパーキング位置となったか否かを判定する。Ｓ５０２において肯定判定がされた場合、リソース管理フローはＳ１０３へ進む。一方、Ｓ５０２において否定判定が下された場合、リソース管理フローはＳ１０４へ進む。

【0072】

このように第五実施形態によると、低負荷条件は、パーキングブレーキが有効、かつ、車両２のシフト位置がパーキング位置となった場合に成立する。これによれば、車両２が駐車モードとなったことをパーキングブレーキの操作状態だけでなく、車両２のシフト位置にも基づいて認識するのに合わせて、ハードウェアリソース１２の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に応じた適時に有効活用することが、可能となる。

【0073】

（第六実施形態）
図１２，１３に示す第六実施形態は、第一実施形態の変形例である。第六実施形態では、自動運転アプリケーション３３０の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。

【0074】

第六実施形態の低負荷条件は、車両２のパーキングブレーキが有効、かつ、車両２のブレーキペダルが踏み込まれていない場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ３２ｅは、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２を、ユーザアプリケーション３４０に割り当てる。

【0075】

以下、第六実施形態の制御装置３によるリソース管理フローを、図１３のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置３の制御周期毎に開始される。

【0076】

第六実施形態のリソース管理フローにおいてＳ１０１に代わるＳ６０１では、コンテナ管理レイヤ３２ｅは、センサ情報として少なくとも、パーキングブレーキの操作状態、及びブレーキペダルの操作状態を、センサ系４から取得する。

【0077】

第六実施形態のリソース管理フローにおいてＳ１０２に代わるＳ６０２では、コンテナ管理レイヤ３２ｅは、Ｓ６０１にて取得のセンサ情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ３２ｅは、車両２のパーキングブレーキが有効、かつ、ブレーキペダルが踏み込まれていないか否かを判定する。Ｓ６０２において肯定判定がされた場合、リソース管理フローはＳ１０３へ進む。一方、Ｓ６０２において否定判定が下された場合、リソース管理フローはＳ１０４へ進む。

【0078】

このように第六実施形態によると、低負荷条件は、パーキングブレーキが有効、かつ、ブレーキペダルが踏み込まれていない場合に成立する。これによれば、車両２が駐車モードとなったことパーキングブレーキの操作状態だけでなく、ブレーキペダルの操作状態にも基づいて認識するのに合わせて、ハードウェアリソース１２の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に応じた適時に有効活用することが、可能となる。

【0079】

（第七実施形態）
図１４，１５に示す第七実施形態は、第一実施形態の変形例である。第七実施形態では、自動運転アプリケーション３３０の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。

【0080】

第七実施形態の低負荷条件は、車両２のパーキングブレーキが有効、かつ、車両２の現在位置が駐車場内にある場合に成立する。車両２の現在位置は、センサ系４から取得のＧＮＳＳ情報、及びメモリ１０に保存された地図情報等から認識可能である。このような低負荷条件が成立する場合にコンテナ管理レイヤ３２ｆは、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２をユーザアプリケーション３４０に割り当てる。

【0081】

以下、第七実施形態の制御装置３によるリソース管理フローを、図１５のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置３の制御周期毎に開始される。

【0082】

第七実施形態のリソース管理フローにおいてＳ１０１に代わるＳ７０１では、コンテナ管理レイヤ３２ｆは、センサ情報として少なくとも、パーキングブレーキの操作状態、及びＧＮＳＳ情報を、センサ系４から取得する。さらにＳ７０１では、コンテナ管理レイヤ３２ｆは、ハードウェアリソース１２のうちメモリ１０から、地図情報を取得する。

【0083】

第七実施形態のリソース管理フローにおいてＳ１０２に代わるＳ７０２では、コンテナ管理レイヤ３２ｆは、Ｓ７０１にて取得のセンサ情報及び地図情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ３２ｆは、車両２のパーキングブレーキが有効、かつ、車両２の現在位置が駐車場内にあるか否かを判定する。Ｓ７０２において肯定判定がされた場合、リソース管理フローはＳ１０３へ進む。一方、Ｓ７０２において否定判定が下された場合、リソース管理フローはＳ１０４へ進む。

【0084】

尚、Ｓ７０１においてコンテナ管理レイヤ３２ｆは、センサ情報としてパーキングブレーキの操作状態を取得すると共に、車両２の現在位置をロケータ（図示省略）から取得してもよい。この場合、Ｓ７０２においてコンテナ管理レイヤ３２ｆは、センサ系４から取得のセンサ情報、及びロケータから取得の現在位置に基づいて、低負荷条件が成立するか否かを判定してもよい。

【0085】

Ｓ７０１においてコンテナ管理レイヤ３２ｆは、センサ情報としてパーキングブレーキの操作状態を取得すると共に、車両２の現在位置を自動運転コンテナ３３から自動運転処理の結果として取得してもよい。この場合、Ｓ７０２においてコンテナ管理レイヤ３２ｆは、センサ系４から取得のセンサ情報、及び自動運転コンテナ３３から取得の現在位置に基づいて、低負荷条件が成立するか否かを判定してもよい。

【0086】

このように第七実施形態によると、低負荷条件は、パーキングブレーキが有効、かつ、車両２の現在位置が駐車場内にある場合に成立する。これによれば、車両２が駐車モードとなったことをパーキングブレーキの操作状態だけでなく、車両２の現在位置にも基づいて認識するのに合わせて、ハードウェアリソース１２の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に応じた適時に有効活用することが、可能となる。

【0087】

（第八実施形態）
図１６，１７に示す第八実施形態は、第一実施形態の変形例である。第八実施形態では、自動運転アプリケーション３３０の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。

【0088】

第八実施形態の低負荷条件は、車両２のパーキングブレーキが有効、かつ、車両２を解錠する解錠ユニットと同車両２との距離が条件範囲外に増大した場合に成立する。解錠ユニットは、車両２を解錠可能、かつ、車両２のセンサ系４と通信可能な、ＩＣ（Integrated circuit）キー、及びモバイル端末等の電子キーを含む。解錠ユニットと車両２との距離は、センサ系４のうち通信タイプの外界センサ４０からのセンサ情報に基づき認識される。そこで、解錠ユニットとの距離に関する条件範囲は、例えば数メートル～数十メートル程度等であって、解錠ユニットを携帯するユーザが車両２から遠方に離れたことを判定するための距離範囲に設定される。このような解錠ユニットとの距離条件を含む低負荷条件が成立する場合にコンテナ管理レイヤ３２ｇは、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２を、ユーザアプリケーション３４０に割り当てる。

【0089】

以下、第八実施形態の制御装置３によるリソース管理フローを、図１７のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置３の制御周期毎に開始される。

【0090】

第八実施形態のリソース管理フローにおいてＳ１０１に代わるＳ８０１では、コンテナ管理レイヤ３２ｇは、センサ情報として少なくとも、パーキングブレーキの操作状態、及び、解錠ユニットと車両２との距離を、センサ系４から取得する。

【0091】

第八実施形態のリソース管理フローにおいてＳ１０２に代わるＳ８０２では、コンテナ管理レイヤ３２ｇは、Ｓ８０１にて取得のセンサ情報に基づいて、低負荷条件が成立するか否かを判定する。このときンテナ管理レイヤ３２ｇは、車両２のパーキングブレーキが有効、かつ、車両２を解錠する解錠ユニットと車両２との距離が条件範囲外に増大したか否かを判定する。Ｓ８０２において否定判定がされた場合、リソース管理フローはＳ１０３へ進む。一方、Ｓ８０２において肯定判定が下された場合、リソース管理フローはＳ１０４へ進む。

【0092】

このように第八実施形態によると、低負荷条件は、パーキングブレーキが有効、かつ、車両２を解錠する解錠ユニットと車両２との距離が条件範囲外に増大した場合に成立する。これによれば、車両２が駐車モードとなったことをパーキングブレーキの操作状態だけでなく、解錠ユニットと車両２との距離情報にも基づき認識するのに合わせて、ハードウェアリソース１２の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に応じた適時に有効活用することが、可能となる。

【0093】

（第九実施形態）
図１８，１９に示す第九実施形態は、第一実施形態の変形例である。第九実施形態では、自動運転アプリケーション３３０の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。

【0094】

第九及び後述の第十実施形態の低負荷条件は、車両２が手動運転モードとなった場合に成立する。ここで手動運転モードとは、例えば米国自動車技術会の規定する自動運転レベル０～３において、少なくとも一部の運転操作をユーザが行う運転モードを意味する。特に第九実施形態の低負荷条件は、自動運転アプリケーション３３０の自動運転処理により実行された車両２のオートパイロット機能が無効となった場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ３２ｈは、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２を、ユーザアプリケーション３４０に割り当てる。

【0095】

以下、第九実施形態の制御装置３によるリソース管理フローを、図１９のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置３の制御周期毎に開始される。

【0096】

第九実施形態のリソース管理フローにおいてＳ１０１に代わるＳ９０１では、コンテナ管理レイヤ３２ｈは、少なくともオートパイロット機能のオンオフ状態を、自動運転コンテナ３３から自動運転処理の結果として取得する。

【0097】

第九実施形態のリソース管理フローにおいてＳ１０２に代わるＳ９０２では、コンテナ管理レイヤ３２ｈは、Ｓ９０１にて取得のオートパイロット状態に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ３２ｈは、自動運転処理により実行される車両２のオートパイロット機能がオフとなったか否かを判定する。Ｓ９０２において肯定判定がされた場合、リソース管理フローはＳ１０３へ進む。一方、Ｓ９０２において否定判定が下された場合、リソース管理フローはＳ１０４へ進む。

【0098】

このように第九実施形態によると、低負荷条件は、車両２が手動運転モードとなった場合に成立する。これによれば、自動運転アプリケーション３３０の動作負荷が低下する手動運転モード時に、ハードウェアリソース１２をユーザアプリケーション３４０に割り当てることができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に伴って有効活用することが、可能となる。

【0099】

さらに第九実施形態によると、低負荷条件は、自動運転処理により実行された車両２のオートパイロット機能が無効となった場合に成立する。これによれば、車両２が手動運転モードとなったことを、オートパイロット機能の状態に基づき認識するのに合わせて、ハードウェアリソース１２の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に応じた適時に有効活用することが、可能となる。

【0100】

（第十実施形態）
図２０，２１に示す第十実施形態は、第九実施形態の変形例である。第十実施形態では、自動運転アプリケーション３３０の動作負荷が設定範囲内に低下する低負荷条件が、第九実施形態の低負荷条件と異なっている。

【0101】

第十実施形態の低負荷条件は、自動運転アプリケーションの自動運転処理により設定された運行設計領域（ＯＤＤ：Operational Design Domain）外となった場合に成立する。ここでＯＤＤとは、自動運転処理の前提となる走行環境条件が成立する走行エリアを、意味する。例えばＯＤＤは、走行中の道路が高速自動車道等の自動車専用走行エリア、運転視界の良好な走行エリア、並びに地図情報又はＧＮＳＳ情報等の位置関連情報を適正に取得可能な走行エリア等に、設定される。このようなＯＤＤ条件を含む低負荷条件が成立する場合にコンテナ管理レイヤ３２ｉは、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２を、ユーザアプリケーション３４０に割り当てる。

【0102】

以下、第十実施形態の制御装置３によるリソース管理フローを、図２１のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置３の制御周期毎に開始される。

【0103】

第十実施形態のリソース管理フローにおいてＳ１０１に代わるＳ１００１では、コンテナ管理レイヤ３２ｉは、車両２が自動運転処理により設定されたＯＤＤ外であるか否かを示すＯＤＤ情報を、自動運転コンテナ３３から自動運転処理の結果として取得する。

【0104】

第十実施形態のリソース管理フローにおいてＳ１０２に代わるＳ１００２では、コンテナ管理レイヤ３２ｉは、Ｓ１００１にて取得のＯＤＤ情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ３２ｉは、自動運転処理により設定されたＯＤＤ外となったか否かを判定する。Ｓ１００２において肯定判定がされた場合、リソース管理フローはＳ１０３へ進む。一方、Ｓ１００２において否定判定が下された場合、リソース管理フローはＳ１０４へ進む。

【0105】

このように第十実施形態によると、低負荷条件は、自動運転処理により設定されたＯＤＤ外となった場合に成立する。これによれば、車両２が手動運転モードであることを、ＯＤＤ情報に基づき認識するのに合わせて、ハードウェアリソース１２の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に応じた適時に有効活用することが、可能となる。

【0106】

（他の実施形態）
以上、本開示の複数の実施形態について説明したが、本開示は、それらの実施形態に限定して解釈されるものではなく、本開示の要旨を逸脱しない範囲内において種々の実施形態及び組み合わせに適用することができる。

【0107】

変形例において制御装置３を構成する専用コンピュータは、デジタル回路及びアナログ回路のうち、少なくとも一方をプロセッサとして有していてもよい。ここでデジタル回路とは、例えばＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＳＯＣ（System on a Chip）、ＰＧＡ（Programmable Gate Array）、及びＣＰＬＤ（Complex Programmable Logic Device）等のうち、少なくとも一種類である。またこうしたデジタル回路は、プログラムを記憶したメモリを、有していてもよい。

【0108】

第一～第十実施形態の変形例では、コンテナ管理レイヤの機能の一部又は全体は、コンテナエンジン３１の機能として実装してもよい。

【0109】

第一～第十実施形態の変形例では、ユーザアプリケーション３４０によるアクセス禁止範囲を、ユーザアプリケーション３４０の種類により可変としてもよい。

【0110】

第一～第十実施形態の変形例では、アプリケーション指定端末５は、車両２に搭載されている端末以外の端末であってもよい。例えばアプリケーション指定端末５は、車両の制御装置３と通信可能なスマートフォンやタブレット等、ユーザが携帯可能な端末であってもよい。

【0111】

第二、第四～第十実施形態の変形例による低負荷条件は、自動運転アプリケーション３３０の動作負荷の設定範囲内への低下時間が設定時間以上継続した場合に成立するとしてもよい。以下、第二実施形態の変形例について、図２２，２３を参照しつつ具体的に説明する。

【0112】

第二実施形態において自動運転アプリケーション３３０の動作負荷が設定範囲内へ低下したと判定される条件は、車両２のパーキングブレーキが有効、かつ、車両２が充電中となったことである。したがって、第二実施形態の変形例による低負荷条件は、車両２のパーキングブレーキが有効、かつ、車両２が充電中の状態が、設定時間以上継続した場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ３２ｊは、自動運転アプリケーション３３０の動作継続に要するハードウェアリソース１２に応じた残りのハードウェアリソース１２を、ユーザアプリケーション３４０に割り当てる。

【0113】

図２３に示す変形例のリソース管理フローにおいてＳ２０２に代わるＳ１１０２では、コンテナ管理レイヤ３２ｊは、Ｓ２０１にて取得のセンサ情報と、制御装置３の内部クロック情報とに基づいて、低負荷条件が成立するか否かを判定する。Ｓ１１０２において肯定判定が下された場合、リソース管理フローはＳ１０３へ進む。一方、Ｓ１１０２において否定判定が下された場合、リソース管理フローＳ１０４へ進む。

【0114】

このような変形例によると、低負荷条件は、動作負荷の設定範囲内への低下時間が設定時間以上継続した場合に成立する。これによれば、ハードウェアリソース１２の遊休状態を、自動運転アプリケーション３３０の低負荷状態の継続時間に基づいて認識するのに合わせて、ハードウェアリソース１２の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース１２を自動運転アプリケーション３３０の動作負荷低下に応じた適時に有効活用することが、可能となる。

【0115】

（技術的思想の開示）
この明細書は、以下に列挙する複数の項に記載された複数の技術的思想を開示している。いくつかの項は、後続の項において先行する項を択一的に引用する多項従属形式（a multiple dependent form）により記載されている場合がある。さらに、いくつかの項は、他の多項従属形式の項を引用する多項従属形式（a multiple dependent form referring to another multiple dependent form）により記載されている場合がある。これらの多項従属形式で記載された項は、複数の技術的思想を定義している。

【0116】

（技術的思想１）
複数のコンテナ（３３，３４）にハードウェアリソース（１２）及びホストＯＳ（３０）を共有させる、制御装置（３）であって、
車両の自動運転処理を実行する自動運転アプリケーション（３３０）を、前記ホストＯＳ上において動作させる自動運転コンテナ（３３）と、
ユーザ指定されるユーザアプリケーション（３４０）を、前記ホストＯＳ上において動作させるユーザコンテナ（３４）と、
前記自動運転アプリケーション及び前記ユーザアプリケーションへの、前記ハードウェアリソースの割り当てを管理する、コンテナ管理レイヤ（３２）と、を備え、
前記コンテナ管理レイヤは、前記自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、前記自動運転アプリケーションの動作継続に要する前記ハードウェアリソースに応じた残りの前記ハードウェアリソースを前記ユーザアプリケーションに割り当てる、制御装置。

【0117】

（技術的思想２）
前記低負荷条件は、前記車両が駐車モードとなった場合に成立する、技術的思想１に記載の制御装置。

【0118】

（技術的思想３）
前記低負荷条件は、前記車両のパーキングブレーキが有効となった場合に成立する、技術的思想２に記載の制御装置。

【0119】

（技術的思想４）
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両が充電中となった場合に成立する、技術的思想３に記載の制御装置。

【0120】

（技術的思想５）
前記低負荷条件は、前記パーキングブレーキが有効となってから一定時間以上経過したとなった場合に成立する、技術的思想３に記載の制御装置。

【0121】

（技術的思想６）
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両の始動スイッチがオフとなった場合に成立する、技術的思想３に記載の制御装置。

【0122】

（技術的思想７）
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両のシフト位置がパーキング位置となった場合に成立する、技術的思想３に記載の制御装置。

【0123】

（技術的思想８）
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両のブレーキペダルが踏み込まれていない場合に成立する、技術的思想３に記載の制御装置。

【0124】

（技術的思想９）
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両の現在位置が駐車場内にある場合に成立する、技術的思想３に記載の制御装置。

【0125】

（技術的思想１０）
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両を解錠する解錠ユニットと当該車両との距離が条件範囲外に増大した場合に成立する、技術的思想３に記載の制御装置。

【0126】

（技術的思想１１）
前記低負荷条件は、前記車両が手動運転モードとなった場合に成立する、技術的思想１に記載の制御装置。

【0127】

（技術的思想１２）
前記低負荷条件は、前記自動運転処理により実行された前記車両のオートパイロット機能が無効となった場合に成立する、技術的思想１１に記載の制御装置。

【0128】

（技術的思想１３）
前記低負荷条件は、前記自動運転処理により設定された運行設計領域外となった場合に成立する、技術的思想１１に記載の制御装置。

【0129】

（技術的思想１４）
前記低負荷条件は、前記動作負荷の前記設定範囲内への低下時間が設定時間以上継続した場合に成立する、技術的思想３に記載の制御装置。

【0130】

（技術的思想１５）
前記ユーザアプリケーションは、前記自動運転処理に関する機械学習モデルのパラメータを更新する機械学習アプリケーションである、技術的思想１ないし１４のいずれか一項に記載の制御装置。

【0131】

（技術的思想１６）
前記ユーザアプリケーションは、前記ハードウェアリソースを外部へ貸し出すレンタルアプリケーションである、技術的思想１ないし１４のいずれか一項に記載の制御装置。

【0132】

（技術的思想１７）
前記ユーザアプリケーションは、前記車両に関するリリース前のアプリケーションを仮想環境にてテスト動作させるアプリケーションである、技術的思想１ないし１４のいずれか一項に記載の制御装置。

【0133】

（技術的思想１８）
前記コンテナ管理レイヤは、前記ユーザアプリケーションによる前記自動運転コンテナへのアクセスを禁止する、技術的思想１ないし１７のいずれか一項に記載の制御装置。

【0134】

（技術的思想１９）
前記コンテナ管理レイヤは、前記ユーザアプリケーションによる前記ハードウェアリソース外へのアクセスを禁止する、技術的思想１ないし１７のいずれか一項に記載の制御装置。

【0135】

（技術的思想２０）
前記コンテナ管理レイヤは、前記低負荷条件が不成立となる場合に、前記ユーザアプリケーションへの前記ハードウェアリソースの割り当てを中止する、技術的思想１ないし１９のいずれか一項に記載の制御装置。

【0136】

（技術的思想２１）
複数のコンテナ（３３，３４）にハードウェアリソース（１２）及びホストＯＳ（３０）を共有させるために、プロセッサ（１１）に実行されるリソース管理方法であって、
車両（２）の自動運転処理を実行する自動運転アプリケーション（３３０）を、前記ホストＯＳ上において動作させることと、
ユーザ指定されるユーザアプリケーション（３４０）を、前記ホストＯＳ上において動作させることと、
前記自動運転アプリケーション及び前記ユーザアプリケーションへの、前記ハードウェアリソースの割り当てを管理することと、を含み、
前記ハードウェアリソースの割り当てを管理することは、前記自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、前記自動運転アプリケーションの動作継続に要する前記ハードウェアリソースに応じた残りの前記ハードウェアリソースを前記ユーザアプリケーションに割り当てることを含む、リソース管理方法。

【0137】

（技術的思想２２）
記憶媒体（１０）に記憶され、複数のコンテナ（３３，３４）にハードウェアリソース（１２）及びホストＯＳ（３０）を共有させるためにプロセッサ（１１）に実行させる命令を含むリソース管理プログラムであって、
前記命令は、
車両（２）の自動運転処理を実行する自動運転アプリケーション（３３０）を、前記ホストＯＳ上において動作させることと、
ユーザ指定されるユーザアプリケーション（３４０）を、前記ホストＯＳ上において動作させることと、
前記自動運転アプリケーション及び前記ユーザアプリケーションへの、前記ハードウェアリソースの割り当てを管理することと、を含み、
前記ハードウェアリソースの割り当てを管理することは、前記自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、前記自動運転アプリケーションの動作継続に要する前記ハードウェアリソースに応じた残りの前記ハードウェアリソースを前記ユーザアプリケーションに割り当てることを含む、リソース管理プログラム。

【符号の説明】

【0138】

２：車両、３：制御装置、１０：記憶媒体、１１：プロセッサ、１２：ハードウェアリソース、３０：ホストＯＳ、３２：コンテナ管理レイヤ、３３：自動運転コンテナ、３４：ユーザコンテナ、３３０：自動運転アプリケーション、３４０：ユーザアプリケーション

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】