IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社デンソーの特許一覧

特開2024-77372制御装置、リソース管理方法、リソース管理プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024077372
(43)【公開日】2024-06-07
(54)【発明の名称】制御装置、リソース管理方法、リソース管理プログラム
(51)【国際特許分類】
   G06F 9/50 20060101AFI20240531BHJP
   G06F 9/455 20180101ALI20240531BHJP
【FI】
G06F9/50 120A
G06F9/455 150
【審査請求】未請求
【請求項の数】22
【出願形態】OL
(21)【出願番号】P 2022189434
(22)【出願日】2022-11-28
(71)【出願人】
【識別番号】000004260
【氏名又は名称】株式会社デンソー
(74)【代理人】
【氏名又は名称】矢作 和行
(74)【代理人】
【識別番号】100121991
【弁理士】
【氏名又は名称】野々部 泰平
(74)【代理人】
【識別番号】100145595
【弁理士】
【氏名又は名称】久保 貴則
(72)【発明者】
【氏名】柴田 章博
(72)【発明者】
【氏名】林 功治
(57)【要約】
【課題】自動運転処理を実行可能な高性能なハードウェアリソースを有効活用する制御装置の提供。
【解決手段】制御装置3は、車両2の自動運転処理を実行する自動運転アプリケーション330を、ホストOS30上において動作させる自動運転コンテナ33と、ユーザ指定されるユーザアプリケーション340を、ホストOS30上において動作させるユーザコンテナ34と、自動運転アプリケーション330及びユーザアプリケーション340への、ハードウェアリソース12の割り当てを管理する、コンテナ管理レイヤ32と、を備える。コンテナ管理レイヤ32は、自動運転アプリケーション330の動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12をユーザアプリケーション340に割り当てる。
【選択図】図2
【特許請求の範囲】
【請求項1】
複数のコンテナ(33,34)にハードウェアリソース(12)及びホストOS(30)を共有させる、制御装置(3)であって、
車両の自動運転処理を実行する自動運転アプリケーション(330)を、前記ホストOS上において動作させる自動運転コンテナ(33)と、
ユーザ指定されるユーザアプリケーション(340)を、前記ホストOS上において動作させるユーザコンテナ(34)と、
前記自動運転アプリケーション及び前記ユーザアプリケーションへの、前記ハードウェアリソースの割り当てを管理する、コンテナ管理レイヤ(32)と、を備え、
前記コンテナ管理レイヤは、前記自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、前記自動運転アプリケーションの動作継続に要する前記ハードウェアリソースに応じた残りの前記ハードウェアリソースを前記ユーザアプリケーションに割り当てる、制御装置。
【請求項2】
前記低負荷条件は、前記車両が駐車モードとなった場合に成立する、請求項1に記載の制御装置。
【請求項3】
前記低負荷条件は、前記車両のパーキングブレーキが有効となった場合に成立する、請求項2に記載の制御装置。
【請求項4】
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両が充電中となった場合に成立する、請求項3に記載の制御装置。
【請求項5】
前記低負荷条件は、前記パーキングブレーキが有効となってから一定時間以上経過したとなった場合に成立する、請求項3に記載の制御装置。
【請求項6】
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両の始動スイッチがオフとなった場合に成立する、請求項3に記載の制御装置。
【請求項7】
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両のシフト位置がパーキング位置となった場合に成立する、請求項3に記載の制御装置。
【請求項8】
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両のブレーキペダルが踏み込まれていない場合に成立する、請求項3に記載の制御装置。
【請求項9】
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両の現在位置が駐車場内にある場合に成立する、請求項3に記載の制御装置。
【請求項10】
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両を解錠する解錠ユニットと当該車両との距離が条件範囲外に増大した場合に成立する、請求項3に記載の制御装置。
【請求項11】
前記低負荷条件は、前記車両が手動運転モードとなった場合に成立する、請求項1に記載の制御装置。
【請求項12】
前記低負荷条件は、前記自動運転処理により実行された前記車両のオートパイロット機能が無効となった場合に成立する、請求項11に記載の制御装置。
【請求項13】
前記低負荷条件は、前記自動運転処理により設定された運行設計領域外となった場合に成立する、請求項11に記載の制御装置。
【請求項14】
前記低負荷条件は、前記動作負荷の前記設定範囲内への低下時間が設定時間以上継続した場合に成立する、請求項3に記載の制御装置。
【請求項15】
前記ユーザアプリケーションは、前記自動運転処理に関する機械学習モデルのパラメータを更新する機械学習アプリケーションである、請求項1に記載の制御装置。
【請求項16】
前記ユーザアプリケーションは、前記ハードウェアリソースを外部へ貸し出すレンタルアプリケーションである、請求項1に記載の制御装置。
【請求項17】
前記ユーザアプリケーションは、前記車両に関するリリース前のアプリケーションを仮想環境にてテスト動作させるアプリケーションである、請求項1に記載の制御装置。
【請求項18】
前記コンテナ管理レイヤは、前記ユーザアプリケーションによる前記自動運転コンテナへのアクセスを禁止する、請求項1に記載の制御装置。
【請求項19】
前記コンテナ管理レイヤは、前記ユーザアプリケーションによる前記ハードウェアリソース外へのアクセスを禁止する、請求項1に記載の制御装置。
【請求項20】
前記コンテナ管理レイヤは、前記低負荷条件が不成立となる場合に、前記ユーザアプリケーションへの前記ハードウェアリソースの割り当てを中止する、請求項1に記載の制御装置。
【請求項21】
複数のコンテナ(33,34)にハードウェアリソース(12)及びホストOS(30)を共有させるために、プロセッサ(11)に実行されるリソース管理方法であって、
車両(2)の自動運転処理を実行する自動運転アプリケーション(330)を、前記ホストOS上において動作させることと、
ユーザ指定されるユーザアプリケーション(340)を、前記ホストOS上において動作させることと、
前記自動運転アプリケーション及び前記ユーザアプリケーションへの、前記ハードウェアリソースの割り当てを管理することと、を含み、
前記ハードウェアリソースの割り当てを管理することは、前記自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、前記自動運転アプリケーションの動作継続に要する前記ハードウェアリソースに応じた残りの前記ハードウェアリソースを前記ユーザアプリケーションに割り当てることを含む、リソース管理方法。
【請求項22】
記憶媒体(10)に記憶され、複数のコンテナ(33,34)にハードウェアリソース(12)及びホストOS(30)を共有させるためにプロセッサ(11)に実行させる命令を含むリソース管理プログラムであって、
前記命令は、
車両(2)の自動運転処理を実行する自動運転アプリケーション(330)を、前記ホストOS上において動作させることと、
ユーザ指定されるユーザアプリケーション(340)を、前記ホストOS上において動作させることと、
前記自動運転アプリケーション及び前記ユーザアプリケーションへの、前記ハードウェアリソースの割り当てを管理することと、を含み、
前記ハードウェアリソースの割り当てを管理することは、前記自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、前記自動運転アプリケーションの動作継続に要する前記ハードウェアリソースに応じた残りの前記ハードウェアリソースを前記ユーザアプリケーションに割り当てることを含む、リソース管理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、複数のコンテナにハードウェアリソース及びホストOSを共有させるコンテナ型仮想化技術に、関する。
【背景技術】
【0002】
例えば特許文献1に開示される制御装置は、膨大な計算リソースを必要とする自動運転処理を実行するために、高性能なハードウェアを備えている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】米国特許第10099630号明細書
【発明の概要】
【発明が解決しようとする課題】
【0004】
一般に制御装置において、車両の自動運転処理を実行するための高性能なハードウェアリソースは、自動運転アプリケーションの実行に静的に割り当てられている。そのため、自動運転アプリケーション非動作時等の動作負荷低下時には、ハードウェアリソースの遊休時間が発生するおそれがあった。
【0005】
本開示の課題は、自動運転処理を実行可能な高性能なハードウェアリソースを有効活用する制御装置を、提供することにある。
【課題を解決するための手段】
【0006】
本開示の第一態様による制御装置は、複数のコンテナにハードウェアリソース及びホストOSを共有させる、制御装置であって、
車両の自動運転処理を実行する自動運転アプリケーションを、ホストOS上において動作させる自動運転コンテナと、
ユーザ指定されるユーザアプリケーションを、ホストOS上において動作させるユーザコンテナと、
自動運転アプリケーション及びユーザアプリケーションへの、ハードウェアリソースの割り当てを管理する、コンテナ管理レイヤと、を備え、
コンテナ管理レイヤは、自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、自動運転アプリケーションの動作継続に要するハードウェアリソースに応じた残りのハードウェアリソースをユーザアプリケーションに割り当てる。
【0007】
本開示の第二態様によるリソース管理方法は、複数のコンテナにハードウェアリソース及びホストOSを共有させるために、プロセッサに実行されるリソース管理方法であって、
車両の自動運転処理を実行する自動運転アプリケーションを、ホストOS上において動作させることと、
ユーザ指定されるユーザアプリケーションを、ホストOS上において動作させることと、
自動運転アプリケーション及びユーザアプリケーションへの、ハードウェアリソースの割り当てを管理することと、を含み、
ハードウェアリソースの割り当てを管理することは、自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、自動運転アプリケーションの動作継続に要するハードウェアリソースに応じた残りのハードウェアリソースをユーザアプリケーションに割り当てることを含む。
【0008】
本開示の第三態様によるリソース管理プログラムは、記憶媒体に記憶され、複数のコンテナにハードウェアリソース及びホストOSを共有させるためにプロセッサに実行させる命令を含むリソース管理プログラムであって、
命令は、
車両の自動運転処理を実行する自動運転アプリケーションを、ホストOS上において動作させることと、
ユーザ指定されるユーザアプリケーションを、ホストOS上において動作させることと、
自動運転アプリケーション及びユーザアプリケーションへの、ハードウェアリソースの割り当てを管理することと、を含み、
ハードウェアリソースの割り当てを管理することは、自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、自動運転アプリケーションの動作継続に要するハードウェアリソースに応じた残りのハードウェアリソースをユーザアプリケーションに割り当てることを含む。
【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】
(第一実施形態)
図1,2に示す第一実施形態の制御装置3は、複数のコンテナにハードウェアリソース12及びホストOS30を共有させる。車両2においては、運転タスクにおける乗員の手動介入度に応じてレベル分けされる、自動運転モードが与えられる。自動運転モードは、条件付運転自動化、高度運転自動化、又は完全運転自動化といった、作動時のシステムが全ての運転タスクを実行する自律走行制御により、実現されてもよい。自動運転モードは、運転支援、又は部分運転自動化といった、乗員が一部若しくは全ての運転タスクを実行する高度運転支援制御により、実現されてもよい。自動運転モードは、それら自律走行制御と高度運転支援制御とのいずれか一方、組み合わせ、又は切り替えにより実現されてもよい。自動運転モードは、後述の自動運転処理に基づく走行制御により、達成される。
【0013】
図1に示すように車両2には、センサ系4、アプリケーション指定端末5、及び制御装置3が搭載される。センサ系4は、制御装置3により利用可能なセンサ情報を、車両2の外界及び内界の検出により取得する。そのためにセンサ系4は、外界センサ40及び内界センサ42を含んで構成されている。尚、図1~21において、図示の都合上、「アプリケーション」を「アプリ」と略記している。
【0014】
外界センサ40は、車両2の周辺環境となる外界の情報を、取得する。外界センサ40は、車両2の外界に存在する物標を検知することで、外界情報を取得してもよい。物標検知タイプの外界センサ40は、例えばカメラ、LiDAR(Light Detection and Ranging / Laser Imaging Detection and Ranging)、レーダ、及びソナー等のうち、少なくとも一種類である。外界センサ40は、車両2の外界に存在するGNSS(Global Navigation Satellite System)の人工衛星から測位信号を受信することで、外界情報を取得してもよい。測位タイプの外界センサ40は、例えばGNSS受信機等である。外界センサ40は、車両2の外界に存在するV2Xシステムとの間において通信信号を送受信することで、外界情報を取得してもよい。通信タイプの外界センサ40は、例えばDSRC(Dedicated Short Range Communications)通信機、セルラV2X(C-V2X)通信機、ブルートゥース(Bluetooth:登録商標)機器、Wi-Fi(登録商標)機器、及び赤外線通信機器等のうち、少なくとも一種類である。
【0015】
内界センサ42は、車両2の内部環境となる内界のセンサ情報を、取得する。内界センサ42は、車両2の内界において特定の運動物理量を検知することで、内界情報を取得してもよい。物理量検知タイプの内界センサ42は、例えば走行速度センサ、加速度センサ、及びジャイロセンサ等のうち、少なくとも一種類である。内界センサ42は、車両2の内界において乗員の特定状態を検知することで、内界情報を取得してもよい。乗員検知タイプの内界センサ42は、例えばドライバーステータスモニター(登録商標)、生体センサ、着座センサ、アクチュエータセンサ、及び車内機器センサ等のうち、少なくとも一種類である。
【0016】
ここでアクチェータセンサは、車両2の走行アクチュエータに対するドライバの指示状態として、例えばアクセルペダルの操作状態、ブレーキペダルの操作状態、パーキングブレーキの操作状態、ステアリングホイールの操舵状態、始動スイッチのオンオフ状態、及び車両2のシフト位置、車両2の充電状態等のうち、少なくとも一種類を検知する。車内機器センサは、車内機器に対するドライバ及び他乗員の指示状態として、例えばオンオフスイッチの操作状態、タッチパネルの操作状態、及び非接触認識可能なジェスチャー等のうち、少なくとも一種類を検知する。
【0017】
アプリケーション指定端末5は、ユーザによるタッチ操作等の操作を受付可能な、例えばセンターディスプレイである。アプリケーション指定端末5は、図2に示す外部のコンテナイメージサーバ6からダウンロード可能なアプリケーションを表示する。車両2の乗員であるユーザは、アプリケーション指定端末5に表示のアプリケーションを選択することで、ユーザアプリケーション340として制御装置3に実行させるアプリケーションを指定可能となっている。
【0018】
ここでコンテナイメージサーバ6は、種々のコンテナイメージを保存している、例えばドッカーハブ(Docker Hub)リポジドリ等である。各コンテナイメージには、コンテナ構成ファイルとして、アプリケーション及び当該アプリケーション実行に必要なミドルウェア及びライブラリ等が含まれている。
【0019】
図1,2に示すように制御装置3は、例えばLAN(Local Area Network)回線、ワイヤハーネス、内部バス、及び無線通信回線等のうち、少なくとも一種類を介してセンサ系4及びアプリケーション指定端末5に接続されている。制御装置3は、少なくとも一つの専用コンピュータを含んで構成されている。
【0020】
制御装置3を構成する専用コンピュータは、車両2の運転制御を統合する、統合ECU(Electronic Control Unit)であってもよい。制御装置3を構成する専用コンピュータは、車両2の運転制御における運転タスクを判断する、判断ECUであってもよい。制御装置3を構成する専用コンピュータは、車両2の運転制御を監視する、監視ECUであってもよい。制御装置3を構成する専用コンピュータは、車両2の運転制御を評価する、評価ECUであってもよい。
【0021】
制御装置3を構成する専用コンピュータは、図1に示すように制御装置3のハードウェアリソース12としてのメモリ10及びプロセッサ11を、少なくとも一つずつ有している。メモリ10は、コンピュータにより読み取り可能なプログラム及びデータ等を非一時的に記憶する、例えば半導体メモリ、磁気媒体、及び光学媒体等のうち、少なくとも一種類の非遷移的実体的記憶媒体(non-transitory tangible storage medium)である。高負荷な自動運転処理を行うためにプロセッサ11は、処理能力の高い例えばGPU(Graphics Processing Unit)をコアとして含む。さらにプロセッサ11は、例えばCPU(Central Processing Unit)、RISC(Reduced Instruction Set Computer)-CPU、DFP(Data Flow Processor)、及びGSP(Graph Streaming Processor)等のうち、少なくとも一種類をコアとしてさらに含んでもよい。
【0022】
メモリ10には、図2に示すホストOS(Operating System)30、コンテナエンジン31、及びリソース管理プログラム(図示省略)等の、プロセッサ11上で動作するソフトウェアに加えて、同図に示す自動運転コンテナ33及びユーザコンテナ34を構築するための、自動運転コンテナイメージ及びユーザコンテナイメージが保存されている。ホストOS30は、例えばリアルタイムOS、Linux(登録商標)、及びUNIX(登録商標)等のうち、少なくとも一種類であってもよい。
【0023】
プロセッサ11は、複数のコンテナにハードウェアリソース12及びホストOS30を共有させるためにメモリ10に記憶された、リソース管理プログラムに含まれる複数の命令を実行する。これにより制御装置3は、複数のコンテナにハードウェアリソース12及びホストOS30を共有させるためのコンテナ管理レイヤ32を、少なくとも一層構築する。それと共に制御装置3は、自動運転コンテナイメージ及びユーザコンテナイメージに基づき、自動運転コンテナ33及びユーザコンテナ34を構築する。
【0024】
コンテナエンジン31は、各コンテナのアプリケーションを実行するための環境をまとめる、例えばドッカー(Docker)等のソフトウェアである。コンテナエンジン31は、自動運転コンテナ33に含まれる自動運転アプリケーション330、及びユーザコンテナ34に含まれるユーザアプリケーション340を、ホストOS30上において動作させる。
【0025】
自動運転コンテナ33は、自動運転アプリケーション330、及びミドルウェア(図示省略)を含む。自動運転アプリケーション330は、センサ系4により取得のセンサ情報に基づいて、車両2の自動運転処理を実行する。自動運転アプリケーション330により実行される自動運転処理には、例えば外界の認識処理、及び走行の計画処理等といった、高負荷な処理が含まれる。
【0026】
ユーザコンテナ34は、ホストOS30及び制御装置3のハードウェアリソース12を、自動運転コンテナ33と共有する。ユーザコンテナ34は、ユーザ指定のユーザアプリエーション340、及びミドルウェア(図示省略)を含む。ここでユーザアプリケーション340は、実行に高性能なハードウェアリソース12を必要とする、高負荷アプリケーションであってもよい。
【0027】
ユーザアプリケーション340は、車両2の自動運転に関する機械学習モデルのパラメータを更新する、機械学習アプリケーションであってもよい。機械学習アプリケーションである場合のユーザアプリケーション340は、機械学習モデルのパラメータを外部センタへフィードバックするものであってもよいし、パラメータ自体を直接更新するものであってもよい。
【0028】
ユーザアプリケーション340は、制御装置3のハードウェアリソース12を外部の例えばサーバ等へ貸し出す、レンタルアプリケーションであってもよい。レンタルアプリケーションである場合のユーザアプリケーション340は、例えばIaaS(Infrastructure As A Service)又はPaaS(Platform As A Service)等としてハードウェアリソース12を貸し出すものであってもよいし、仮想通貨のマイニングにハードウェアリソース12を貸し出すものであってもよい。
【0029】
ユーザアプリケーション340は、車両2に関するリリース前のアプリケーションを仮想環境にてテスト動作させるものであってもよい。ユーザアプリケーション340は、OTA(On The Air)による外部から車両2への配信によりソフトウェアを更新する、更新アプリケーションであってもよい。ユーザアプリケーション340は、センサ系4により取得のセンサ情報の前処理と当該前処理により得られたデータを外部の例えばサーバ等へアップロードする、センシング前処理アプリケーションであってもよい。
【0030】
ユーザアプリケーション340は、例えば映画等の動画コンテンツを再生する、メディアアプリケーションであってもよい。ユーザアプリケーション340は、動画データ及び/又は音声データのエンコードを行う、エンコーダアプリケーションであってもよい。ユーザアプリケーション340は、動画データ及び/又は静止画データのアップコンバートを行う、アップコンバートアプリケーションであってもよい。ユーザアプリケーション340は、例えば数値シミュレーション、又は新薬探索シミュレーションシ等を行う、シミュレーションアプリケーションであってもよい。
【0031】
コンテナ管理レイヤ32は、センサ系4により取得のセンサ情報に基づいて、自動運転アプリケーション330とユーザアプリケーション340との各々へのハードウェアリソース12の割り当てを管理する。具体的にコンテナ管理レイヤ32は、自動運転アプリケーション330の動作負荷が設定範囲内に低下する低負荷条件が成立するか否かを、判定する。ここで設定範囲は、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12により、ユーザアプリケーション340の動作に必要なハードウェアリソース12を確保可能となる範囲に設定される。低負荷条件が成立する場合にコンテナ管理レイヤ32は、、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12を、ユーザアプリケーション340に割り当てる。一方、コンテナ管理レイヤ32は低負荷条件が成立しない場合にコンテナ管理レイヤ32は、ユーザアプリケーション340へのハードウェアリソース12の割り当てを中止することで、ユーザアプリケーション340の実行を停止する。第一及び後述の第二~第八実施形態の低負荷条件は、車両2が駐車モードとなった場合に成立する。特に第一実施形態の低負荷条件は、車両2のパーキングブレーキが有効となった場合に成立する。
【0032】
コンテナ管理レイヤ32は、アプリケーション指定端末5に対する操作によりユーザがアプリケーションを指定した場合には、ユーザ指定のアプリケーションを含むコンテナイメージがメモリ10に存在するか否かを、確認する。ユーザ指定のアプリケーションを含むコンテナイメージがメモリ10に存在しない場合にコンテナ管理レイヤ32は、当該コンテナイメージをコンテナイメージサーバ6からのダウンロードにより取得すると共に、取得したコンテナイメージに基づくユーザコンテナ34を構築する。
【0033】
コンテナ管理レイヤ32は、車両2の運転関連部分へのユーザアプリケーション340によるアクセスを、禁止する。運転関連部分へのアクセス禁止としてコンテナ管理レイヤ32は、ユーザアプリケーション340による自動運転コンテナ33へのアクセスを禁止してもよい。運転関連部分へのアクセス禁止としてコンテナ管理レイヤ32は、ユーザアプリケーション340によるハードウェアリソース12外へのアクセスを禁止してもよい。
【0034】
以上説明した制御装置3によるリソース管理方法のフローを、図3に従って以下に説明する。尚、本フローにおける各「S」は、リソース管理プログラムに含まれた複数命令によって実行される複数ステップを、それぞれ意味している。このリソース管理フローは、制御装置3の制御周期毎に開始される。
【0035】
S101においてコンテナ管理レイヤ32は、センサ系4からセンサ情報を取得する。このとき、第一実施形態によるコンテナ管理レイヤ32は、センサ情報として少なくとも、車両2におけるパーキングブレーキの操作状態を、取得する。
【0036】
S101に続くS102においてコンテナ管理レイヤ32は、S101にて取得のセンサ情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ32は、パーキングブレーキが有効であるか否かを、判定する。S102において肯定判定が下された場合にリソース管理フローは、S103へ進む。一方、S102において否定判定が下された場合にリソース管理フローは、S104へ進む。
【0037】
低負荷条件が成立している場合のS103においてコンテナ管理レイヤ32は、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12を、ユーザアプリケーション340に割り当てる。
【0038】
一方、低負荷条件が不成立となる場合のS104においてコンテナ管理レイヤ32は、ユーザアプリケーション340へのハードウェアリソース12の割り当てを中止する。
【0039】
(作用効果)
以上説明した第一実施形態の作用効果を、以下に説明する。
【0040】
第一実施形態によるコンテナ管理レイヤ32は、自動運転処理を実行する自動運転アプリケーション330の動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12をユーザアプリケーション340に割り当てる。これによれば、自動運転アプリケーション330の動作負荷低下に伴って解放されるハードウェアリソース12を、自動運転処理とは独立したユーザ向けのユーザアプリケーション340に割り当てることができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を有効活用することが、可能となる。
【0041】
第一実施形態によると、低負荷条件は、車両2が駐車モードとなった場合に成立する。これによれば、自動運転アプリケーション330の動作負荷が低下する駐車モード時に、ハードウェアリソース12をユーザアプリケーション340に割り当てることができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に伴って有効活用することが、可能となる。
【0042】
第一実施形態によると、低負荷条件は、パーキングブレーキが有効となった場合に成立する。これによれば、車両2が駐車モードとなったことをパーキングブレーキの操作状態に基づき認識するのに合わせて、ハードウェアリソース12の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に応じた適時に有効活用することが、可能となる。
【0043】
第一実施形態によると、ユーザアプリケーション340は、車両運転に関する機械学習モデルのパラメータを更新する機械学習アプリケーションであってもよい。この場合には、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に伴って有効活用して、機械学習モデルのパラメータを更新することが、可能となる。
【0044】
第一実施形態によると、ユーザアプリケーション340は、制御装置3のハードウェアリソース12を外部へ貸し出すレンタルアプリケーションであってもよい。この場合には、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に伴って有効活用して、外部サーバ等の計算負荷を軽減することが、可能となる。
【0045】
第一実施形態によると、ユーザアプリケーション340は、リリース前のアプリケーションを仮想環境にてテスト動作させるものであってもよい。この場合には、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に伴って有効活用して、正式運用前のアプリケーションの実機テストを行うことが、可能となる。
【0046】
第一実施形態によるコンテナ管理レイヤ32は、ユーザアプリケーション340による自動運転コンテナ33へのアクセスを禁止してもよい。この場合には、ユーザアプリケーション340の動作による自動運転処理への影響を、抑止することができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を有効活用する上で、車両2の安全性を高めることが可能となる。
【0047】
第一実施形態によるコンテナ管理レイヤ32は、ユーザアプリケーション340によるハードウェアリソース12外へのアクセスを禁止してもよい。この場合には、ユーザアプリケーション340の動作による車両運転操作への影響を、抑制することができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を、安全に有効活用することが可能となる。
【0048】
第一実施形態によるコンテナ管理レイヤ32は、低負荷条件が不成立となる場合に、ユーザアプリケーション340へのハードウェアリソース12の割り当てを中止する。これによれば、自動運転アプリケーション330の動作負荷が低下しない場合のハードウェアリソース12を、自動運転処理に適切に割り当てることができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を有効活用する上で、車両2の安全性を高めることが可能となる。
【0049】
(第二実施形態)
図4,5に示す第二実施形態は、車両2が充電可能な場合に採用可能な、第一実施形態の変形例である。第二実施形態では、自動運転アプリケーション330の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。
【0050】
第二実施形態の低負荷条件は、車両2のパーキングブレーキが有効、かつ、車両2が充電中となった場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ32aは、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12を、ユーザアプリケーション340に割り当てる。
【0051】
以下、第二実施形態の制御装置3によるリソース管理フローを、図5のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置3の制御周期毎に開始される。
【0052】
第二実施形態のリソース管理フローにおいてS101に代わるS201では、コンテナ管理レイヤ32aは、センサ情報として少なくとも、車両2におけるパーキングブレーキの操作状態、及び車両2における充電状態を、センサ系4から取得する。
【0053】
第二実施形態のリソース管理フローにおいてS102に代わるS202では、コンテナ管理レイヤ32aは、S201にて取得のセンサ情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ32aは、車両2のパーキングブレーキが有効、かつ、車両2が充電中となったか否かを判定する。S202において肯定判定が下された場合、リソース管理フローはS103へ進む。一方、S202において否定判定が下された場合、リソース管理フローS104へ進む。
【0054】
このように第二実施形態によると、低負荷条件は、パーキングブレーキが有効、かつ、車両2が充電中となった場合に成立する。これによれば、車両2が駐車モードとなったことをパーキングブレーキの操作状態だけでなく、車両2の充電状態にも基づき認識するのに合わせて、ハードウェアリソース12の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に応じた適時に有効活用することが、可能となる。
【0055】
(第三実施形態)
図6,7に示す第三実施形態は、第一実施形態の変形例である。第三実施形態では、自動運転アプリケーション330の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。
【0056】
第三実施形態の低負荷条件は、車両2のパーキングブレーキが有効となってから一定時間以上経過した場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ32bは、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12を、ユーザアプリケーション340に割り当てる。
【0057】
以下、第三実施形態の制御装置3によるリソース管理フローを、図7のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置3の制御周期毎に開始される。
【0058】
第三実施形態のリソース管理フローにおいてS101に続くS102に代わるS302では、コンテナ管理レイヤ32bは、S101にて取得のセンサ情報と、制御装置3の内部クロック情報とに基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ32bは、車両2のパーキングブレーキが有効となってから、一定時間以上経過したか否かを判定する。S302において肯定判定がされた場合、リソース管理フローはS103へ進む。一方、S302において否定判定が下された場合、リソース管理フローはS104へ進む。
【0059】
このように第三実施形態によると、低負荷条件は、パーキングブレーキが有効となってから一定時間以上経過した場合に成立する。これによれば、車両2が駐車モードとなったことを、パーキングブレーキが有効となってからの経過時間に基づき認識するのに合わせて、ハードウェアリソース12の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に応じた適時に有効活用することが、可能となる。
【0060】
尚、S302は、動作負荷の設定範囲内への低下時間が設定時間以上継続したか否か、と読み替えてもよい。この場合、第三実施形態の低負荷条件は、車両2のパーキングブレーキの有効状態が設定時間以上継続した場合に成立する。
【0061】
(第四実施形態)
図8,9に示す第四実施形態は、第一実施形態の変形例である。第四実施形態では、自動運転アプリケーション330の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。
【0062】
第四実施形態の低負荷条件は、車両2のパーキングブレーキが有効、かつ、車両2の始動スイッチがオフとなった場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ32cは、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12を、ユーザアプリケーション340に割り当てる。
【0063】
以下、第四実施形態の制御装置3によるリソース管理フローを、図9のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置3の制御周期毎に開始される。
【0064】
第四実施形態のリソース管理フローにおいてS101に代わるS401では、コンテナ管理レイヤ32cは、センサ情報として少なくとも、パーキングブレーキの操作状態、及び始動スイッチのオンオフ状態を、センサ系4から取得する。
【0065】
第四実施形態のリソース管理フローにおいてS102に代わるS402では、コンテナ管理レイヤ32cは、S401にて取得のセンサ情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ32cは、車両2のパーキングブレーキが有効、かつ、車両2の始動スイッチがオフとなったか否かを判定する。S402において肯定判定がされた場合、リソース管理フローはS103へ進む。一方、S402において否定判定が下された場合、リソース管理フローはS104へ進む。
【0066】
このように第四実施形態によると、低負荷条件は、パーキングブレーキが有効、かつ、車両2の始動スイッチがオフとなった場合に成立する。これによれば、車両2が駐車モードとなったことを、パーキングブレーキの操作状態だけでなく、車両2の始動スイッチ状態にも基づき認識するのに合わせて、ハードウェアリソース12の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に応じた適時に有効活用することが、可能となる。
【0067】
(第五実施形態)
図10,11に示す第五実施形態は、第一実施形態の変形例である。第五実施形態では、自動運転アプリケーション330の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。
【0068】
第五実施形態の低負荷条件は、車両2のパーキングブレーキが有効、かつ、車両2のシフト位置がパーキング位置となった場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ32dは、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12を、ユーザアプリケーション340に割り当てる。
【0069】
以下、第五実施形態の制御装置3によるリソース管理フローを、図11のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置3の制御周期毎に開始される。
【0070】
第五実施形態のリソース管理フローにおいてS101に代わるS501では、コンテナ管理レイヤ32dは、センサ情報として少なくとも、パーキングブレーキの操作状態、及びシフト位置を、センサ系4から取得する。
【0071】
第五実施形態のリソース管理フローにおいてS102に代わるS502では、コンテナ管理レイヤ32dは、S501にて取得のセンサ情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ32dは、車両2のパーキングブレーキが有効、かつ、車両2のシフト位置がパーキング位置となったか否かを判定する。S502において肯定判定がされた場合、リソース管理フローはS103へ進む。一方、S502において否定判定が下された場合、リソース管理フローはS104へ進む。
【0072】
このように第五実施形態によると、低負荷条件は、パーキングブレーキが有効、かつ、車両2のシフト位置がパーキング位置となった場合に成立する。これによれば、車両2が駐車モードとなったことをパーキングブレーキの操作状態だけでなく、車両2のシフト位置にも基づいて認識するのに合わせて、ハードウェアリソース12の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に応じた適時に有効活用することが、可能となる。
【0073】
(第六実施形態)
図12,13に示す第六実施形態は、第一実施形態の変形例である。第六実施形態では、自動運転アプリケーション330の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。
【0074】
第六実施形態の低負荷条件は、車両2のパーキングブレーキが有効、かつ、車両2のブレーキペダルが踏み込まれていない場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ32eは、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12を、ユーザアプリケーション340に割り当てる。
【0075】
以下、第六実施形態の制御装置3によるリソース管理フローを、図13のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置3の制御周期毎に開始される。
【0076】
第六実施形態のリソース管理フローにおいてS101に代わるS601では、コンテナ管理レイヤ32eは、センサ情報として少なくとも、パーキングブレーキの操作状態、及びブレーキペダルの操作状態を、センサ系4から取得する。
【0077】
第六実施形態のリソース管理フローにおいてS102に代わるS602では、コンテナ管理レイヤ32eは、S601にて取得のセンサ情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ32eは、車両2のパーキングブレーキが有効、かつ、ブレーキペダルが踏み込まれていないか否かを判定する。S602において肯定判定がされた場合、リソース管理フローはS103へ進む。一方、S602において否定判定が下された場合、リソース管理フローはS104へ進む。
【0078】
このように第六実施形態によると、低負荷条件は、パーキングブレーキが有効、かつ、ブレーキペダルが踏み込まれていない場合に成立する。これによれば、車両2が駐車モードとなったことパーキングブレーキの操作状態だけでなく、ブレーキペダルの操作状態にも基づいて認識するのに合わせて、ハードウェアリソース12の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に応じた適時に有効活用することが、可能となる。
【0079】
(第七実施形態)
図14,15に示す第七実施形態は、第一実施形態の変形例である。第七実施形態では、自動運転アプリケーション330の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。
【0080】
第七実施形態の低負荷条件は、車両2のパーキングブレーキが有効、かつ、車両2の現在位置が駐車場内にある場合に成立する。車両2の現在位置は、センサ系4から取得のGNSS情報、及びメモリ10に保存された地図情報等から認識可能である。このような低負荷条件が成立する場合にコンテナ管理レイヤ32fは、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12をユーザアプリケーション340に割り当てる。
【0081】
以下、第七実施形態の制御装置3によるリソース管理フローを、図15のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置3の制御周期毎に開始される。
【0082】
第七実施形態のリソース管理フローにおいてS101に代わるS701では、コンテナ管理レイヤ32fは、センサ情報として少なくとも、パーキングブレーキの操作状態、及びGNSS情報を、センサ系4から取得する。さらにS701では、コンテナ管理レイヤ32fは、ハードウェアリソース12のうちメモリ10から、地図情報を取得する。
【0083】
第七実施形態のリソース管理フローにおいてS102に代わるS702では、コンテナ管理レイヤ32fは、S701にて取得のセンサ情報及び地図情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ32fは、車両2のパーキングブレーキが有効、かつ、車両2の現在位置が駐車場内にあるか否かを判定する。S702において肯定判定がされた場合、リソース管理フローはS103へ進む。一方、S702において否定判定が下された場合、リソース管理フローはS104へ進む。
【0084】
尚、S701においてコンテナ管理レイヤ32fは、センサ情報としてパーキングブレーキの操作状態を取得すると共に、車両2の現在位置をロケータ(図示省略)から取得してもよい。この場合、S702においてコンテナ管理レイヤ32fは、センサ系4から取得のセンサ情報、及びロケータから取得の現在位置に基づいて、低負荷条件が成立するか否かを判定してもよい。
【0085】
S701においてコンテナ管理レイヤ32fは、センサ情報としてパーキングブレーキの操作状態を取得すると共に、車両2の現在位置を自動運転コンテナ33から自動運転処理の結果として取得してもよい。この場合、S702においてコンテナ管理レイヤ32fは、センサ系4から取得のセンサ情報、及び自動運転コンテナ33から取得の現在位置に基づいて、低負荷条件が成立するか否かを判定してもよい。
【0086】
このように第七実施形態によると、低負荷条件は、パーキングブレーキが有効、かつ、車両2の現在位置が駐車場内にある場合に成立する。これによれば、車両2が駐車モードとなったことをパーキングブレーキの操作状態だけでなく、車両2の現在位置にも基づいて認識するのに合わせて、ハードウェアリソース12の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に応じた適時に有効活用することが、可能となる。
【0087】
(第八実施形態)
図16,17に示す第八実施形態は、第一実施形態の変形例である。第八実施形態では、自動運転アプリケーション330の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。
【0088】
第八実施形態の低負荷条件は、車両2のパーキングブレーキが有効、かつ、車両2を解錠する解錠ユニットと同車両2との距離が条件範囲外に増大した場合に成立する。解錠ユニットは、車両2を解錠可能、かつ、車両2のセンサ系4と通信可能な、IC(Integrated circuit)キー、及びモバイル端末等の電子キーを含む。解錠ユニットと車両2との距離は、センサ系4のうち通信タイプの外界センサ40からのセンサ情報に基づき認識される。そこで、解錠ユニットとの距離に関する条件範囲は、例えば数メートル~数十メートル程度等であって、解錠ユニットを携帯するユーザが車両2から遠方に離れたことを判定するための距離範囲に設定される。このような解錠ユニットとの距離条件を含む低負荷条件が成立する場合にコンテナ管理レイヤ32gは、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12を、ユーザアプリケーション340に割り当てる。
【0089】
以下、第八実施形態の制御装置3によるリソース管理フローを、図17のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置3の制御周期毎に開始される。
【0090】
第八実施形態のリソース管理フローにおいてS101に代わるS801では、コンテナ管理レイヤ32gは、センサ情報として少なくとも、パーキングブレーキの操作状態、及び、解錠ユニットと車両2との距離を、センサ系4から取得する。
【0091】
第八実施形態のリソース管理フローにおいてS102に代わるS802では、コンテナ管理レイヤ32gは、S801にて取得のセンサ情報に基づいて、低負荷条件が成立するか否かを判定する。このときンテナ管理レイヤ32gは、車両2のパーキングブレーキが有効、かつ、車両2を解錠する解錠ユニットと車両2との距離が条件範囲外に増大したか否かを判定する。S802において否定判定がされた場合、リソース管理フローはS103へ進む。一方、S802において肯定判定が下された場合、リソース管理フローはS104へ進む。
【0092】
このように第八実施形態によると、低負荷条件は、パーキングブレーキが有効、かつ、車両2を解錠する解錠ユニットと車両2との距離が条件範囲外に増大した場合に成立する。これによれば、車両2が駐車モードとなったことをパーキングブレーキの操作状態だけでなく、解錠ユニットと車両2との距離情報にも基づき認識するのに合わせて、ハードウェアリソース12の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に応じた適時に有効活用することが、可能となる。
【0093】
(第九実施形態)
図18,19に示す第九実施形態は、第一実施形態の変形例である。第九実施形態では、自動運転アプリケーション330の動作負荷が設定範囲内に低下する低負荷条件が、第一実施形態の低負荷条件と異なっている。
【0094】
第九及び後述の第十実施形態の低負荷条件は、車両2が手動運転モードとなった場合に成立する。ここで手動運転モードとは、例えば米国自動車技術会の規定する自動運転レベル0~3において、少なくとも一部の運転操作をユーザが行う運転モードを意味する。特に第九実施形態の低負荷条件は、自動運転アプリケーション330の自動運転処理により実行された車両2のオートパイロット機能が無効となった場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ32hは、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12を、ユーザアプリケーション340に割り当てる。
【0095】
以下、第九実施形態の制御装置3によるリソース管理フローを、図19のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置3の制御周期毎に開始される。
【0096】
第九実施形態のリソース管理フローにおいてS101に代わるS901では、コンテナ管理レイヤ32hは、少なくともオートパイロット機能のオンオフ状態を、自動運転コンテナ33から自動運転処理の結果として取得する。
【0097】
第九実施形態のリソース管理フローにおいてS102に代わるS902では、コンテナ管理レイヤ32hは、S901にて取得のオートパイロット状態に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ32hは、自動運転処理により実行される車両2のオートパイロット機能がオフとなったか否かを判定する。S902において肯定判定がされた場合、リソース管理フローはS103へ進む。一方、S902において否定判定が下された場合、リソース管理フローはS104へ進む。
【0098】
このように第九実施形態によると、低負荷条件は、車両2が手動運転モードとなった場合に成立する。これによれば、自動運転アプリケーション330の動作負荷が低下する手動運転モード時に、ハードウェアリソース12をユーザアプリケーション340に割り当てることができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に伴って有効活用することが、可能となる。
【0099】
さらに第九実施形態によると、低負荷条件は、自動運転処理により実行された車両2のオートパイロット機能が無効となった場合に成立する。これによれば、車両2が手動運転モードとなったことを、オートパイロット機能の状態に基づき認識するのに合わせて、ハードウェアリソース12の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に応じた適時に有効活用することが、可能となる。
【0100】
(第十実施形態)
図20,21に示す第十実施形態は、第九実施形態の変形例である。第十実施形態では、自動運転アプリケーション330の動作負荷が設定範囲内に低下する低負荷条件が、第九実施形態の低負荷条件と異なっている。
【0101】
第十実施形態の低負荷条件は、自動運転アプリケーションの自動運転処理により設定された運行設計領域(ODD:Operational Design Domain)外となった場合に成立する。ここでODDとは、自動運転処理の前提となる走行環境条件が成立する走行エリアを、意味する。例えばODDは、走行中の道路が高速自動車道等の自動車専用走行エリア、運転視界の良好な走行エリア、並びに地図情報又はGNSS情報等の位置関連情報を適正に取得可能な走行エリア等に、設定される。このようなODD条件を含む低負荷条件が成立する場合にコンテナ管理レイヤ32iは、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12を、ユーザアプリケーション340に割り当てる。
【0102】
以下、第十実施形態の制御装置3によるリソース管理フローを、図21のフローチャートを参照しつつ説明する。このリソース管理フローは、制御装置3の制御周期毎に開始される。
【0103】
第十実施形態のリソース管理フローにおいてS101に代わるS1001では、コンテナ管理レイヤ32iは、車両2が自動運転処理により設定されたODD外であるか否かを示すODD情報を、自動運転コンテナ33から自動運転処理の結果として取得する。
【0104】
第十実施形態のリソース管理フローにおいてS102に代わるS1002では、コンテナ管理レイヤ32iは、S1001にて取得のODD情報に基づいて、低負荷条件が成立するか否かを判定する。このときコンテナ管理レイヤ32iは、自動運転処理により設定されたODD外となったか否かを判定する。S1002において肯定判定がされた場合、リソース管理フローはS103へ進む。一方、S1002において否定判定が下された場合、リソース管理フローはS104へ進む。
【0105】
このように第十実施形態によると、低負荷条件は、自動運転処理により設定されたODD外となった場合に成立する。これによれば、車両2が手動運転モードであることを、ODD情報に基づき認識するのに合わせて、ハードウェアリソース12の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に応じた適時に有効活用することが、可能となる。
【0106】
(他の実施形態)
以上、本開示の複数の実施形態について説明したが、本開示は、それらの実施形態に限定して解釈されるものではなく、本開示の要旨を逸脱しない範囲内において種々の実施形態及び組み合わせに適用することができる。
【0107】
変形例において制御装置3を構成する専用コンピュータは、デジタル回路及びアナログ回路のうち、少なくとも一方をプロセッサとして有していてもよい。ここでデジタル回路とは、例えばASIC(Application Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)、SOC(System on a Chip)、PGA(Programmable Gate Array)、及びCPLD(Complex Programmable Logic Device)等のうち、少なくとも一種類である。またこうしたデジタル回路は、プログラムを記憶したメモリを、有していてもよい。
【0108】
第一~第十実施形態の変形例では、コンテナ管理レイヤの機能の一部又は全体は、コンテナエンジン31の機能として実装してもよい。
【0109】
第一~第十実施形態の変形例では、ユーザアプリケーション340によるアクセス禁止範囲を、ユーザアプリケーション340の種類により可変としてもよい。
【0110】
第一~第十実施形態の変形例では、アプリケーション指定端末5は、車両2に搭載されている端末以外の端末であってもよい。例えばアプリケーション指定端末5は、車両の制御装置3と通信可能なスマートフォンやタブレット等、ユーザが携帯可能な端末であってもよい。
【0111】
第二、第四~第十実施形態の変形例による低負荷条件は、自動運転アプリケーション330の動作負荷の設定範囲内への低下時間が設定時間以上継続した場合に成立するとしてもよい。以下、第二実施形態の変形例について、図22,23を参照しつつ具体的に説明する。
【0112】
第二実施形態において自動運転アプリケーション330の動作負荷が設定範囲内へ低下したと判定される条件は、車両2のパーキングブレーキが有効、かつ、車両2が充電中となったことである。したがって、第二実施形態の変形例による低負荷条件は、車両2のパーキングブレーキが有効、かつ、車両2が充電中の状態が、設定時間以上継続した場合に成立する。このような低負荷条件が成立する場合にコンテナ管理レイヤ32jは、自動運転アプリケーション330の動作継続に要するハードウェアリソース12に応じた残りのハードウェアリソース12を、ユーザアプリケーション340に割り当てる。
【0113】
図23に示す変形例のリソース管理フローにおいてS202に代わるS1102では、コンテナ管理レイヤ32jは、S201にて取得のセンサ情報と、制御装置3の内部クロック情報とに基づいて、低負荷条件が成立するか否かを判定する。S1102において肯定判定が下された場合、リソース管理フローはS103へ進む。一方、S1102において否定判定が下された場合、リソース管理フローS104へ進む。
【0114】
このような変形例によると、低負荷条件は、動作負荷の設定範囲内への低下時間が設定時間以上継続した場合に成立する。これによれば、ハードウェアリソース12の遊休状態を、自動運転アプリケーション330の低負荷状態の継続時間に基づいて認識するのに合わせて、ハードウェアリソース12の割り当てを行うことができる。故に、自動運転処理を実行可能な高性能なハードウェアリソース12を自動運転アプリケーション330の動作負荷低下に応じた適時に有効活用することが、可能となる。
【0115】
(技術的思想の開示)
この明細書は、以下に列挙する複数の項に記載された複数の技術的思想を開示している。いくつかの項は、後続の項において先行する項を択一的に引用する多項従属形式(a multiple dependent form)により記載されている場合がある。さらに、いくつかの項は、他の多項従属形式の項を引用する多項従属形式(a multiple dependent form referring to another multiple dependent form)により記載されている場合がある。これらの多項従属形式で記載された項は、複数の技術的思想を定義している。
【0116】
(技術的思想1)
複数のコンテナ(33,34)にハードウェアリソース(12)及びホストOS(30)を共有させる、制御装置(3)であって、
車両の自動運転処理を実行する自動運転アプリケーション(330)を、前記ホストOS上において動作させる自動運転コンテナ(33)と、
ユーザ指定されるユーザアプリケーション(340)を、前記ホストOS上において動作させるユーザコンテナ(34)と、
前記自動運転アプリケーション及び前記ユーザアプリケーションへの、前記ハードウェアリソースの割り当てを管理する、コンテナ管理レイヤ(32)と、を備え、
前記コンテナ管理レイヤは、前記自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、前記自動運転アプリケーションの動作継続に要する前記ハードウェアリソースに応じた残りの前記ハードウェアリソースを前記ユーザアプリケーションに割り当てる、制御装置。
【0117】
(技術的思想2)
前記低負荷条件は、前記車両が駐車モードとなった場合に成立する、技術的思想1に記載の制御装置。
【0118】
(技術的思想3)
前記低負荷条件は、前記車両のパーキングブレーキが有効となった場合に成立する、技術的思想2に記載の制御装置。
【0119】
(技術的思想4)
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両が充電中となった場合に成立する、技術的思想3に記載の制御装置。
【0120】
(技術的思想5)
前記低負荷条件は、前記パーキングブレーキが有効となってから一定時間以上経過したとなった場合に成立する、技術的思想3に記載の制御装置。
【0121】
(技術的思想6)
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両の始動スイッチがオフとなった場合に成立する、技術的思想3に記載の制御装置。
【0122】
(技術的思想7)
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両のシフト位置がパーキング位置となった場合に成立する、技術的思想3に記載の制御装置。
【0123】
(技術的思想8)
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両のブレーキペダルが踏み込まれていない場合に成立する、技術的思想3に記載の制御装置。
【0124】
(技術的思想9)
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両の現在位置が駐車場内にある場合に成立する、技術的思想3に記載の制御装置。
【0125】
(技術的思想10)
前記低負荷条件は、前記パーキングブレーキが有効、かつ、前記車両を解錠する解錠ユニットと当該車両との距離が条件範囲外に増大した場合に成立する、技術的思想3に記載の制御装置。
【0126】
(技術的思想11)
前記低負荷条件は、前記車両が手動運転モードとなった場合に成立する、技術的思想1に記載の制御装置。
【0127】
(技術的思想12)
前記低負荷条件は、前記自動運転処理により実行された前記車両のオートパイロット機能が無効となった場合に成立する、技術的思想11に記載の制御装置。
【0128】
(技術的思想13)
前記低負荷条件は、前記自動運転処理により設定された運行設計領域外となった場合に成立する、技術的思想11に記載の制御装置。
【0129】
(技術的思想14)
前記低負荷条件は、前記動作負荷の前記設定範囲内への低下時間が設定時間以上継続した場合に成立する、技術的思想3に記載の制御装置。
【0130】
(技術的思想15)
前記ユーザアプリケーションは、前記自動運転処理に関する機械学習モデルのパラメータを更新する機械学習アプリケーションである、技術的思想1ないし14のいずれか一項に記載の制御装置。
【0131】
(技術的思想16)
前記ユーザアプリケーションは、前記ハードウェアリソースを外部へ貸し出すレンタルアプリケーションである、技術的思想1ないし14のいずれか一項に記載の制御装置。
【0132】
(技術的思想17)
前記ユーザアプリケーションは、前記車両に関するリリース前のアプリケーションを仮想環境にてテスト動作させるアプリケーションである、技術的思想1ないし14のいずれか一項に記載の制御装置。
【0133】
(技術的思想18)
前記コンテナ管理レイヤは、前記ユーザアプリケーションによる前記自動運転コンテナへのアクセスを禁止する、技術的思想1ないし17のいずれか一項に記載の制御装置。
【0134】
(技術的思想19)
前記コンテナ管理レイヤは、前記ユーザアプリケーションによる前記ハードウェアリソース外へのアクセスを禁止する、技術的思想1ないし17のいずれか一項に記載の制御装置。
【0135】
(技術的思想20)
前記コンテナ管理レイヤは、前記低負荷条件が不成立となる場合に、前記ユーザアプリケーションへの前記ハードウェアリソースの割り当てを中止する、技術的思想1ないし19のいずれか一項に記載の制御装置。
【0136】
(技術的思想21)
複数のコンテナ(33,34)にハードウェアリソース(12)及びホストOS(30)を共有させるために、プロセッサ(11)に実行されるリソース管理方法であって、
車両(2)の自動運転処理を実行する自動運転アプリケーション(330)を、前記ホストOS上において動作させることと、
ユーザ指定されるユーザアプリケーション(340)を、前記ホストOS上において動作させることと、
前記自動運転アプリケーション及び前記ユーザアプリケーションへの、前記ハードウェアリソースの割り当てを管理することと、を含み、
前記ハードウェアリソースの割り当てを管理することは、前記自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、前記自動運転アプリケーションの動作継続に要する前記ハードウェアリソースに応じた残りの前記ハードウェアリソースを前記ユーザアプリケーションに割り当てることを含む、リソース管理方法。
【0137】
(技術的思想22)
記憶媒体(10)に記憶され、複数のコンテナ(33,34)にハードウェアリソース(12)及びホストOS(30)を共有させるためにプロセッサ(11)に実行させる命令を含むリソース管理プログラムであって、
前記命令は、
車両(2)の自動運転処理を実行する自動運転アプリケーション(330)を、前記ホストOS上において動作させることと、
ユーザ指定されるユーザアプリケーション(340)を、前記ホストOS上において動作させることと、
前記自動運転アプリケーション及び前記ユーザアプリケーションへの、前記ハードウェアリソースの割り当てを管理することと、を含み、
前記ハードウェアリソースの割り当てを管理することは、前記自動運転アプリケーションの動作負荷が設定範囲内に低下する低負荷条件が成立する場合に、前記自動運転アプリケーションの動作継続に要する前記ハードウェアリソースに応じた残りの前記ハードウェアリソースを前記ユーザアプリケーションに割り当てることを含む、リソース管理プログラム。
【符号の説明】
【0138】
2:車両、3:制御装置、10:記憶媒体、11:プロセッサ、12:ハードウェアリソース、30:ホストOS、32:コンテナ管理レイヤ、33:自動運転コンテナ、34:ユーザコンテナ、330:自動運転アプリケーション、340:ユーザアプリケーション
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23