JP2022076790A - 情報処理装置、方法、プログラム、及び車両 - Google Patents

Abstract

【課題】複数の異なる機能システムの各機能間の動作に不整合がないように車両を制御することができる情報処理装置を提供する。【解決手段】車両に搭載される情報処理装置であって、車両に対する要求に応じて、車両の使われ方や動作に関する車両の振る舞いを定める複数のモードの中から１つのモードを決定する決定部と、決定部によって決定されたモードにおいて許容されるステート及びサブモードにおいて取り得る複数の状態の間で、車両の状態を遷移させる状態遷移部と、状態遷移部が遷移させた状態に基づいて車両を制御する制御部と、を備える。【選択図】図１

Description

本開示は、車両に搭載される情報処理装置などに関する。

特許文献１に、所定の車両機能を制御するための複数の入力を事前に調停した要求に基づいて、その車両機能に関わる複数の出力部の動作を最適に制御する管理部を備えた機能システムにおいて、異なる機能システムの管理部間での相互通信によって広範囲な協調制御を可能とした車両制御システムが開示されている。

特開２０２０－０３７３０９号公報

特許文献１に記載された車両制御システムは、各機能システムにおいては、自身の機能システムへ直接的に入力される要求しか協調制御の可否の判断材料がなく、自身の機能システムへ入力される要求と他の機能システムへ入力される要求との矛盾を検知することができない。また、特許文献１に記載された車両制御システムは、各機能システムから他の機能システムへ送信される要求はすでに調停された後の要求であるため、この調停後の要求と他の機能システムで調停された要求との間で不整合が生じていても要求を修正することができない。

このため、特許文献１に記載された車両制御システムでは、複数の機能システムの各機能を跨ぐ統括的な要求や時間を跨ぐ連続的な要求に対して、好適な調停がなされない場合や、３つ以上の機能システムの各機能間における調停自体が成立しない可能性がある。

本開示は、上記課題を鑑みてなされたものであり、複数の異なる機能システムの各機能間の動作に不整合がないように車両を制御することができる情報処理装置を提供することを目的とする。

上記課題を解決するために、本開示技術の一態様は、車両に搭載される情報処理装置であって、車両に対する要求に応じて、車両の使われ方や動作に関する車両の振る舞いを定める複数のモードの中から１つのモードを決定する決定部と、決定部によって決定されたモードにおいて許容されるステート及びサブモードにおいて取り得る複数の状態の間で、車両の状態を遷移させる状態遷移部と、状態遷移部が遷移させた状態に基づいて車両を制御する制御部と、を備える、情報処理装置である。

本開示の情報処理装置によれば、モードやステートを用いた状態の遷移によって車両の制御状況を一元的に管理できるため、複数の異なる機能システムの各機能間の動作に不整合がないように車両全体を好適に制御することができる。

一実施形態に係る情報処理装置を含む車両制御システムの機能ブロック図 メインモードにおける状態遷移図 走行ステートにおける状態遷移図 運動ステートにおける状態遷移図 輸送ステートにおける状態遷移図 電力インフラ協調ステートにおける状態遷移図 自動車モード時における各ステートでの遷移相関の一例 運転サブモードにおける状態遷移図 充電サブモードにおける状態遷移図 装備給電サブモードにおける状態遷移図 補機補充サブモードにおける状態遷移図 ＡＣ給電サブモードにおける状態遷移図 メインモード、ステート、及びサブモードの連動した状態遷移の事例１ メインモード、ステート、及びサブモードの連動した状態遷移の事例２ メインモード、ステート、及びサブモードの連動した状態遷移の事例３ メインモード、ステート、及びサブモードの連動した状態遷移の事例４ メインモード、ステート、及びサブモードの連動した状態遷移の事例５ メインモード、ステート、及びサブモードの連動した状態遷移の事例６ メインモード、ステート、及びサブモードの連動した状態遷移の事例７ 図１９の事例７におけるサブモード間の調停要件を示す例 メインモード、ステート、及びサブモードの連動した状態遷移の事例８ メインモード、ステート、及びサブモードの連動した状態遷移の事例９ メインモード、ステート、及びサブモードの連動した状態遷移の事例１０ メインモード、ステート、及びサブモードの連動した状態遷移の事例１１ メインモード、ステート、及びサブモードの連動した状態遷移の事例１２

本開示の情報処理装置は、車両統合ＥＣＵ（セントラルＥＣＵ）単体、又は車外クラウド単体、もしくはこれらの連携によって、車両全体の動作や振る舞いを統括する頭脳中枢として動作する制御プラットフォームの機能を提供する。この制御プラットフォームを用いることで、複数の異なる機能システムの各機能間の動作に不整合がないように車両全体を好適に制御することができる。

＜実施形態＞
［構成］
図１は、本開示の一実施形態に係る情報処理装置２０を含む車両制御システムの機能ブロック図である。図１に例示した機能ブロックは、サービスアプリケーション１０と、情報処理装置２０と、車両デバイス３０と、プラントライブラリ４０と、運転アプリケーション５０と、を備える。情報処理装置２０は、コマンドライブラリ２１、モビリティシステム制御部２２、情報共有ポータル２３、及び統合マネージャ２４を含む。この車両制御システムは、自動車などの車両に搭載され得る。

１．サービスアプリケーション１０
サービスアプリケーション１０は、車内外の情報及び車両の構成要素を活用してサービスを実現するアプリケーションが実装される機能ブロックである。このサービスには、自動車として又は製品としての車両のリアルタイムな動作の他に、例えば設定時刻に基づいたアプリケーション（自アプリ、他アプリ）の起動に関する予約、データベースの収集加工、記録媒体への記録、及び外部への無線送信などのアクティビティが含まれる。本実施形態のアプリケーションは、情報処理装置２０に対して、ＡＰＩ（Application Programming Interface）を経由してコマンドライブラリ２１に予め規定された抽象的なコマンドを要求（コール）するように作成される。抽象的な要求には、付帯情報（サービス実行想定時間、優先度、頻度など）が付されていてもよい。サービスやアクティビティを提供する事業者などは、目的に応じたＡＰＩを用いてアプリケーションをプログラミングすることによって、任意のサービスやアクティビティを提供することが可能である。事業者などに公開されるＡＰＩは、ソフトウェア開発者のレベルに応じて内容を変えてもよい。これにより、事業者の開発者などは、車両に組み込まれた電子プラットフォーム、車両が備えるデバイス（アクチュエータ、センサなど）の構成、及び車両のエネルギー（電力、熱など）体系などを意識することなく、新しい機能を実現するためのアプリケーションを簡易に開発することができる。アプリケーションとしては、コックピットＵＸ（User eXperience）、リモートサービス、ＭａａＳ（Mobility as a Service）、エネルギーマネージメントサービス、及びＯＴＡ（Over The Air）更新サービスなどに関する各種のアプリケーションを例示できる。

このサービスアプリケーション１０は、コマンドライブラリ２１に対して、各種のサービスを要求する。また、サービスアプリケーション１０は、情報共有ポータル２３が公開する共有情報を参照する。また、サービスアプリケーション１０は、モビリティシステム制御部２２から、アプリケーションの起動を指示するトリガーを入力する。さらに、サービスアプリケーション１０は、プラントライブラリ４０との間で、情報のやりとりを行うことができる。このサービスアプリケーション１０の各アプリケーションは、原則車両に実行されるが、アプリケーションの一部をクラウド化してもよい。

２．コマンドライブラリ２１
コマンドライブラリ２１は、サービスアプリケーション１０からサービスに関する抽象的な要求（サービスＡＰＩコール）がなされることで、そのサービス要求に応じた制御を実現するための抽象的なＡＰＩを揃えた機能ブロックである。換言すると、コマンドライブラリ２１は、サービスアプリケーション１０から受け付けた要求を統合マネージャ２４やモビリティシステム制御部２２に向けた要求に変換する。このコマンドライブラリ２１は、一例として、以下に示す機能を連動して実現させる種々のコマンドをライブラリとして備える。

（１）要求を実現するための車両デバイス３０（アクチュエータなど）に対する単一又は複合的な動作指令を具体化する機能。
（２）車両の振る舞い（製品としての車両の使われ方）を定める車両制御モードの遷移トリガーを出力（発信）する機能。
（３）要求の実現に必要なシステムを作動させるための電源の起動及び停止を行う機能。
（４）エントリーされたエネルギー需要に対する供給源の調停（需要マージ、需要重み付け、供給可否判断、供給源選択）を指示する機能。
（５）各種データを用いて加工及び／又は生成した共有の情報を情報共有ポータル２３へ登録する機能。
（６）必要な情報のストレージへの記憶や車内外の通信デバイスを操作する機能。
（７）指定されたアプリケーションを設定時刻に起動させるためのタイマー機能。

このコマンドライブラリ２１は、モビリティシステム制御部２２に対して、車両制御モードの遷移を指示するトリガーの出力、運行計画の伝達、及び予約の通知などを行う。また、コマンドライブラリ２１は、統合マネージャ２４に対して、制御要求又はサービス要求を出力する。また、コマンドライブラリ２１は、サービスアプリケーション１０から、各種サービスの要求を受け付ける。また、コマンドライブラリ２１は、アプリケーションの加工情報を、公開のために情報共有ポータル２３に提供することができる。また、コマンドライブラリ２１は、情報共有ポータル２３が公開する共有情報を参照する。さらに、コマンドライブラリ２１は、プラントライブラリ４０との間で、情報のやりとりを行うことができる。

３．モビリティシステム制御部２２
モビリティシステム制御部２２は、車両の振る舞い（使われ方、動作など）に関わる制御状況の一元管理、運行計画に基づいた一連のタスクの進行管理、及びスケジュールの管理などを行う機能ブロック（決定部、状態遷移部）である。このモビリティシステム制御部２２は、一例として、以下に示す管理機能を有する。

（１）車両制御モード管理
下記の構成要素（複数のモード及びステート）によって車両全体の制御を管理し、車両デバイス３０の各構成及びシステムの振る舞いを統制し、車両が置かれた場面（ＴＰＯ）に応じたＵＸ要求を調停する機能。
・メインモード：場面に応じた車両トータルでの大括りの使われ方を決定
＜自動車モード／電化モード／発電モード／休止モード＞
・ステート：シーケンシャルな制御局面に応じた車両状態の遷移を管理
＜走行ステート／運動ステート／輸送ステート／電力インフラ協調ステート＞
・サブモード：単独もしくは複数のモード配下において制御目的及び手段を限定
＜運転サブモード／充電サブモード／装備給電サブモード／補機補充サブモード／ＡＣ給電サブモードなど＞
（２）スケジュール管理（スケジューラ）
指定されたアクティビティやアプリケーションの開始時刻／終了時刻の予約を実行する機能。タイマー充電やプレ空調を例示できる。
（３）運行管理
ＭａａＳの利用において、運行計画表に基づいた車両の移動、輸送サービス（人流／物流）、滞在サービス、及び付随タスク（車掌機能など）の進捗を管理する機能。
（４）ＦＯＰ管理
個人所有車両（ＰｏＶ：Personally Owned Vehicle）のみならず、ＭａａＳにおいてもフェールセーフ及びフェールオペレーション（ＦＯＰ）を一元管理する機能。なお、必要に応じて、主要なサブシステムの信頼性情報の生成や、システムダイアグノーシスなどの搭載がなされる。

このモビリティシステム制御部２２は、統合マネージャ２４に対して、調停に必要な指標や制御許可／禁止の指示を出力する。また、モビリティシステム制御部２２は、サービスアプリケーション１０に対して、アプリケーションの起動を指示するトリガーを出力する。また、モビリティシステム制御部２２は、コマンドライブラリ２１から、車両制御モードの遷移を指示するトリガー、運行計画、及び予約などを取得する。また、モビリティシステム制御部２２は、モビリティシステム情報（制御モード、運行状況、ＵＸ調停結果など）を、公開のために情報共有ポータル２３に提供することができる。また、モビリティシステム制御部２２は、情報共有ポータル２３が公開する共有情報を参照する。さらに、モビリティシステム制御部２２は、運転アプリケーション５０に対してモビリティシステム情報（運転モード、目的地など）を提供したり、運転アプリケーション５０の情報を参照したりすることができる。

４．情報共有ポータル２３
情報共有ポータル２３は、サービスアプリケーション１０、コマンドライブラリ２１、モビリティシステム制御部２２、及び統合マネージャ２４など、各機能ブロックが参照するためのグローバルに公開される情報（共有情報）を集約する機能ブロックである。この共有情報は、車両統合ＥＣＵ（セントラルＥＣＵ）から通信によって繋がる各制御ドメインや車外のクラウドからも参照可能である。共有情報としては、車両の状態及び車両周辺の状況、車内外のシーン情報、ユーザーニーズの検知結果、及びセンサの入力値などの情報を例示できる。この情報共有ポータル２３は、各機能ブロックが、共有情報の生成（提供）元を意識させないでその共有情報を参照することができる構造となっている。また、情報共有ポータル２３には、車両の走行シーン（時刻、天候、気温など）、車両利用者の認証結果、ストレージの容量などの情報を加工できるコーディネータが含まれていてもよい。

この情報共有ポータル２３は、サービスアプリケーション１０、コマンドライブラリ２１、モビリティシステム制御部２２、統合マネージャ２４、車両デバイス３０、及び運転アプリケーション５０に共有情報を公開する。また、情報共有ポータル２３は、コマンドライブラリ２１から、公開可能なアプリケーションの加工情報を取得することができる。また、情報共有ポータル２３は、モビリティシステム制御部２２から、公開可能なモビリティシステム情報（制御モード、運行状況、ＵＸ調停結果など）を取得することができる。また、情報共有ポータル２３は、統合マネージャ２４から、公開可能な調停結果を取得することができる。また、情報共有ポータル２３は、車両デバイス３０から、公開可能な一般情報（センサ、通信、アナログ信号など）を取得することができる。情報共有ポータル２３は、車両デバイス３０から取得する一般情報をそのままサービスアプリケーション１０に出力するゲートウェイとして機能してもよい。また、情報共有ポータル２３は、運転アプリケーション５０から、公開可能な運転状況（停留判定結果など）を取得することができる。この情報共有ポータル２３で公開される情報は、原則車両に登録（記憶）されるが、情報の一部をクラウドに登録（記憶）してもよい。

５．統合マネージャ２４
統合マネージャ２４は、モビリティシステム制御部２２による制御状況及び情報共有ポータル２３から参照可能な各種の共有情報に基づいて、サービスアプリケーション１０からの要求（サービスＡＰＩコール）の受付可否及び物理量制限などの調停を実施し、要求を実現するための車両デバイス３０への最終指令を決定する機能ブロック（制御部）である。この統合マネージャ２４は、一例として、以下に示す機能についてマネジメントを行うマネージャを含む。本実施形態では、統合マネージャ２４が車両の装備バリエーション（ハードウェアの差異）を吸収するように構成される。

（１）システム起動／停止マネージャ（電源マネージャ）
要求されるサービスニーズより、車両の配下にある必要なシステムの起動及び停止を制御し、指令（電源オン／オフ、ＮＭトリガー、通信要求）を出力する機能。
（２）電力マネージャ
車両における充放電や電圧変換といった電力の消費と供給を効率的に制御する機能。本実施形態では、車両にてエントリーされた（予約も含む）全てのエネルギー需要（電力、電力量）に対する公平な供給の調停を実施し、サービス許可の判断、電力収支の上限／下限の決定、及び電力供給源（高圧電池、充電器など）の選択を行う。
（３）熱マネージャ
車両の排熱や暖房といった熱の需要と供給を効率的に制御する機能。本実施形態では、サービスアプリケーション１０からの発熱要求（空調、部品温調）に対する調停を実施し、燃費／エミッションの要件を満足する範囲においてエンジンの始動又は燃料電池（ＦＣ）の起動の指令を出力する。
（４）運動マネージャ
車両の「走る」「曲がる」「止まる」といった運動に関わる機能を制御する運動系システムへ要求を調停する機能。本実施形態では、モビリティシステム制御部２２における要件（走行ステート、運動ステート、輸送運行管理）、及びＭａａＳサービスなどによる新規要求の反映（発進禁止、車両の固定要求／解除禁止など）を行う。

この統合マネージャ２４は、モビリティシステム制御部２２から調停に必要な指標や制御許可／禁止の指示を入力する。また、統合マネージャ２４は、コマンドライブラリ２１から、制御要求（又はサービス要求）を入力する。統合マネージャ２４は、コマンドライブラリ２１から入力する制御要求をそのまま車両デバイス３０に出力するゲートウェイとして機能してもよい。また、統合マネージャ２４は、車両デバイス３０に対して、調停後の指令（ＡＣＴＲ、通信、ドライバ出力など）を出力する。また、統合マネージャ２４は、各マネージャの調停結果を、公開のために情報共有ポータル２３に提供することができる。また、統合マネージャ２４は、情報共有ポータル２３が公開する共有情報を調停のために参照する。また、統合マネージャ２４は、運転アプリケーション５０に対して運動マネージャのアンサーバックや調停結果を提供したり、運転アプリケーション５０から要求される車両運動に関する情報（加速度、舵角など）を参照したりすることができる。

なお、統合マネージャ２４は、上述したマネージャ以外にも、例えば、車両のナビゲーション画面やメーターなどへの好適な表示や車両の操作を好適に提供する電装制御（ユーザビリティ）に関わる機能を制御するＨＭＩ（Human Machine Interface）マネージャを含んでもよい。

６．車両デバイス３０
車両デバイス３０は、制御情報や動作要求、データ、信号などの最終入出力先であるセンサやアクチュエータなどのデバイスを備える機能ブロックである。車両デバイス３０として、車両の周囲の状況を表す情報や車両の状態を表す情報を取得するセンサや、ドライバーによる車両運転に関する操作（アクセル、ブレーキ、ステアリング、シフトなど）の情報を取得するセンサなど、を例示できる。また、車両デバイス３０として、空調システムの起動のために用いられるデバイス（ＩＧＰ）、車両運動系システムの起動のために用いられるデバイス（ＩＧＲ）、エンジンの起動を制御するスターター（ＳＴ）などのアクチュエータを例示できる。

この車両デバイス３０は、統合マネージャ２４から、調停後の指令（ＡＣＴＲ、通信、ドライバ出力など）を入力する。また、車両デバイス３０は、一般情報（センサ、通信、アナログ信号など）を、公開のために情報共有ポータル２３に提供することができる。

７．プラントライブラリ４０
プラントライブラリ４０は、サービスアプリケーション１０における制御性向上のために活用できる各種のシミュレーション（残充電所要時間推定、マップ変換など）が可能なシミュレータ、車内外から閲覧可能なデータベース、及び人工知能（ＡＩ）や機械学習アルゴリズムなどの環境を提供する機能ブロックである。これらの環境の一部又は全部は、車両に実装されてもよいし、クラウドに配置されてもよい。

このプラントライブラリ４０は、所定のＡＰＩを経由して、サービスアプリケーション１０、コマンドライブラリ２１、及び運転アプリケーション５０に対して必要な情報を要求したり、所定の処理（シミュレーションなど）を行った結果である情報をサービスアプリケーション１０、コマンドライブラリ２１、及び運転アプリケーション５０に取得させたり、することができる。このプラントライブラリ４０の機能は、原則車両に搭載されるが、機能の一部をクラウド化してもよい。

８．運転アプリケーション５０
運転アプリケーション５０は、車両に実装されるアプリケーションのうち、サービスアプリケーション１０に実装されるアプリケーション以外であって車両の運転及びその支援に特化したアプリケーションである。この運転アプリケーション５０としては、自動駐車などの遠隔運転、自動運転（ＡＤ：Autonomous Driving）、ＭａａＳによる自動運転（Autono-MaaS）、先進運転支援システム（ＡＤＡＳ：Advanced Driver Assistance System）を例示できる。

この運転アプリケーション５０は、所定の車両運転ＡＰＩを経由して、モビリティシステム制御部２２が公開する情報（運転モード、目的地など）を参照したり、モビリティシステム制御部２２に情報を参照させたり、情報共有ポータル２３に運転状況（停留判定結果など）を提供したり、情報共有ポータル２３に公開されている共有情報（各種データ）を取り込んだり、統合マネージャ２４に対して車両運動（加速度、舵角など）を要求したり、統合マネージャ２４からのアンサーバック（調停結果など）を受けたりすることができる。また、運転アプリケーション５０は、プラントライブラリ４０との間で、情報のやりとりを行うことができる。この運転アプリケーション５０の各アプリケーションは、原則車両に実行されるが、アプリケーションの一部をクラウド化してもよい。

本実施形態の車両制御システムは、上述した各機能ブロックを備えることによって、制御プラットフォームの構造、規定されるコマンド、車両のシステム構成、及び車両で扱われるエネルギー体系などを意識せずに開発したアプリケーションをインストールするのみで、様々なサービスを実現することが可能となる。

［制御］
図２乃至図１２を参照して、本開示の車両制御システムにおいて各種のサービスを実現するために、モビリティシステム制御部２２が実行する制御の１つである車両の振る舞い（使われ方、動作など）に関わる制御である車両制御モード管理について、具体的に説明する。

モビリティシステム制御部２２は、車両制御モード管理において、以下の制御モード及び制御ステートを用いて車両の振る舞い（使われ方、動作など）を制御する。
（１）メインモード（車両制御モード）
１－１：自動車モード
１－２：電化モード（定点電化モード）
１－３：発電モード（非常用発電モード）
１－４：休止モード
（２）ステート
２－１：走行ステート（待機、始動、走行、終了）
２－２：運動ステート（固定、停止、発進可判断、駆動、停止要判断）
２－３：輸送ステート（待機、停留、出発、移動）
２－４：電力インフラ協調ステート（待機、準備、充電、給電）
（３）サブモード
３－１：運転サブモード（マニュアル、セミオート、フルオート）
３－２：充電サブモード（休止、ＡＣ充電、ＤＣ充電、接触、非接触、ソーラー高圧）
３－３：装備給電サブモード（休止、電化サービス、移動準備、乗降車、ＯＴＡ）
３－４：補機補充サブモード（休止、高圧汲み出し、ソーラー低圧）
３－５：ＡＣ給電サブモード（休止、室内ＡＣＣ、室内Ｖ２Ｌ、外部Ｖ２Ｇ、外部Ｖ２Ｌ）

（１）メインモード
メインモードは、場面に応じた車両トータルでの大括りの使われ方を決定する。このメインモードでは、自動車モード、電化モード、発電モード、及び休止モードのいずれかが選択される。「自動車モード」は、車両を本来の自動車としての移動や輸送のニーズに対応させるモードである。この自動車モードでは、車両の走る、曲がる、止まるといった運動に関わる機能及びその周辺の機能を作動させることができる。「電化モード（又は定点電化モード）」は、駐車中の車両を自動車としてではなく蓄電池を持つ電気装備（電化製品）としてのニーズに対応させるモードである。この電化モードでは、車載機器の活用の他、統合マネージャ２４の電力マネージャと連携して電力の需要供給バランスに応じた高圧汲み出しや充電器作動を含めた蓄電池の充電などが行われる。「発電モード（又は非常用発電モード）」は、駐車中の車両を自動車としてではなく非常時又は生活用の発電機としてのニーズに対応させるモードである。この発電モードでは、車外で電気を利用するために必要な発電を実行する。「休止モード」は、車両を自動車、電化製品、及び発電機としていずれも動作させていないときのデフォルトのモードである。

図２は、メインモードにおける、休止モード（ＩＤ＝０）、自動車モード（ＩＤ＝１）、電化モード（ＩＤ＝２）、及び発電モード（ＩＤ＝３）の状態遷移図である。各モード間の遷移は、以下に説明する条件に基づいて実行される。

・休止モード→自動車モード
休止モードにおいて移動ニーズ［Ａ］が発生すると、自動車モードに遷移する。移動ニーズ［Ａ］の発生は、車両のドライバーから直接又は間接的な操作があった場合、ＭａａＳ（ＡＰＩ）からの要求を検知した場合、及び車両の固定状態が解除された（シフトがパーキング（Ｐ）の位置以外）場合など、によって判断することができる。
・休止モード→電化モード
休止モードにおいて駐車中サービスニーズ［Ｃ］が発生すると、電化モードに遷移する。駐車中サービスニーズ［Ｃ］の発生は、蓄電池の充放電の状態や外部給電などの各種サービスを検知した場合など、によって判断することができる。なお、この休止モードから電化モードへの遷移は、後述する電力インフラ協調ステート、充電サブモード、装備給電サブモード、及び補機補充サブモードの状態に従って実施される。
・休止モード→発電モード
休止モードにおいて発電ニーズ［Ｅ］が発生すると、発電モードに遷移する。発電ニーズ［Ｅ］の発生は、車内又は車外で非常用発電の要求を検知した場合などによって判断することができる。なお、この休止モードから発電モードへの遷移は、後述するＡＣ給電サブモードの状態に従って実施される。

・自動車モード→休止モード
自動車モードにおいて移動完了［Ｂ］を判断すると、休止モードに遷移する。移動完了［Ｂ］は、移動ニーズ［Ａ］が終了しかつ車両の駐車が完了した場合などによって判断することができる。
・自動車モード→電化モード
自動車モードにおいて駐車中サービスニーズ［Ｃ’］が発生すると、電化モードに遷移する。駐車中サービスニーズ［Ｃ’］は、駐車中サービスニーズ［Ｃ］と同様である。なお、この自動車モードから電化モードへの遷移は、後述する電力インフラ協調ステート、充電サブモード、装備給電サブモード、及び補機補充サブモードの状態に従って実施される。

・電化モード→自動車モード
電化モードにおいて移動ニーズ［Ａ’］が発生すると、自動車モードに遷移する。移動ニーズ［Ａ’］は、移動ニーズ［Ａ］と同様である。
・電化モード→休止モード
電化モードにおいて駐車中サービス完了［Ｄ］を判断すると、休止モードに遷移する。駐車中サービス完了［Ｄ］は、駐車中サービスニーズ［Ｃ］が全て終了した場合などによって判断することができる。
・電化モード→発電モード
電化モードにおいて発電ニーズ［Ｅ’］が発生すると、発電モードに遷移する。発電ニーズ［Ｅ’］は、発電ニーズ［Ｅ］と同様である。なお、この電化モードから発電モードへの遷移は、後述するＡＣ給電サブモードの状態に従って実施される。

・発電モード→休止モード
発電モードにおいて発電完了［Ｆ］を判断すると、休止モードに遷移する。発電完了［Ｆ］は、発電ニーズ［Ｅ］が全て終了した場合などによって判断することができる。

（２）ステート
ステートは、メインモードの特定モードの配下において、シーケンシャルな制御局面に応じた車両状態の遷移を実施する。このステートには、自動車モードで選択される走行ステート、運動ステート、及び輸送ステート、電化モードで選択される電力インフラ協調ステートがある。各ステートでは、制御局面に応じて次のように車両状態が遷移する。

２－１：走行ステート
走行ステートは、自動車モードの配下で状態を遷移させる。この走行ステートにおいて取り得る車両の状態には、待機、始動、走行、及び終了の各状態がある。「待機」は、車両制御システムの初期状態を示し、所定のイベントの指示があれば車両の走行（トリップ）の準備を開始し、指示がなければスリープ状態に移行する。「始動」は、車両が移動を開始するためにパワートレインシステム（パワトレ）の始動を実行する状態を示し、始動要求（クランキング要求）を発信する。「走行」は、パワートレインシステムの始動が完了し、駆動力を発生することが可能である状態を示す。「終了」は、車両の走行中や停止中にかかわらず、駆動力を発生することが不可能である状態を示す。

図３は、走行ステートにおける、待機（ＩＤ＝０）、始動（ＩＤ＝１）、走行（ＩＤ＝２）、及び終了（ＩＤ＝３）の状態遷移図である。各状態間の遷移は、以下に説明する条件に基づいて実行される。

・待機→始動
待機状態においてトリップ開始［Ａ］を判断すると、始動状態に遷移する。トリップ開始［Ａ］は、車両のドライバーから直接又は間接的な操作があった場合、及びＭａａＳ（ＡＰＩ）からの要求を検知した場合など、によって判断することができる。
・始動→走行
始動状態においてパワトレ起動［Ｂ］を判断すると、走行状態に遷移する。パワトレ起動［Ｂ］は、車両がハイブリッド自動車（ＨＶ）、電気自動車（ＥＶ）、及びプラグインハイブリッド自動車（ＰＨＶ）である場合には、動作状態がＲｅａｄｙ－ＯＮになったことで、車両が内燃機関をエンジンとする自動車（コンベ）である場合には、エンジンが完全爆発（完爆）したことで、判断することができる。
・走行→終了
走行状態においてパワトレ停止［Ｃ］を判断すると、終了状態に遷移する。パワトレ停止［Ｃ］は、車両のドライバーやＭａａＳ（ＡＰＩ）からの要求が取り下げられた場合や、車両の動作状態がＲｅａｄｙ－ＯＦＦになったことで、判断することができる。
・終了→待機
終了状態においてトリップ終了［Ｄ］を判断すると、待機状態に遷移する。トリップ終了［Ｄ］は、車両が停止されてかつ固定された（シフトがパーキング（Ｐ）の位置）とで、判断することができる。
・終了→始動
終了状態においてパワトレ再始動［Ａ’］を判断すると、始動状態に遷移する。パワトレ再始動［Ａ’］は、車両のドライバーから直接又は間接的な操作が再びあった場合や、ＭａａＳ（ＡＰＩ）からの要求を再び検知した場合など、によって判断することができる。
・始動→終了
始動状態においてパワトレ始動失敗［Ｃ’］を判断すると、終了状態に遷移する。パワトレ始動失敗［Ｃ’］は、例えば所定の時間が経過してもパワトレ起動［Ｂ］を検出できないことなどで判断することができる。

２－２：運動ステート
運動ステートは、自動車モードの配下で状態を遷移させる。この運動ステートにおいて取り得る車両の状態には、固定、停止、発進可判断、駆動、及び停止要判断の各状態がある。「固定」は、車両制御システムの初期状態を示し、車両が動かない前提でのサービス及びアクティビティを許可し、その間は必要に応じて車両の固定状態の解除を禁止する。「停止」は、主に道路状況以外の外的要因によって車両を発進できない状態を示す。この停止状態では、ブレーキの保持によって車両が停止している。「発進可判断」は、道路状況などに基づいた運転主権者（ドライバーなど）の意思で、ブレーキの保持によって車両を一時的に停止させている状態を示す。「駆動」は、運転主権者（ドライバーなど）の意思で、駆動力を適宜発生させながら車両運動（走行など）を実施させている状態を示す。「停止要判断」は、主に道路状況以外の外的要因によって車両を停止させる必要があり、パワートレインシステムによる駆動力の発生を許可できない状態を示す。

図４は、運動ステートにおける、固定（ＩＤ＝０）、停止（ＩＤ＝１）、発進可判断（ＩＤ＝２）、駆動（ＩＤ＝３）、及び停止要判断（ＩＤ＝４）の状態遷移図である。発進可判断は、駆動力発生の許可中に選択される状態である。停止要判断は、車両の運動中に選択される状態である。駆動は、駆動力発生の許可中かつ車両の運動中に選択される状態である。各状態間の遷移は、以下に説明する条件に基づいて実行される。

・固定→停止
固定状態において固定解除［Ａ］を判断すると、停止状態に遷移する。固定解除［Ａ］は、シフトがパーキング（Ｐ）の位置以外になり（Ｐロック抜き）、かつパーキングブレーキが解除された場合など、によって判断することができる。
・停止→発進可判断
停止状態において駆動可能［Ｂ］を判断すると、発進可判断状態に遷移する。駆動可能［Ｂ］は、車両の動作状態がＲｅａｄｙ－ＯＮになり、かつ車両運動系システムの信頼性がある場合など、によって判断することができる。
・発進可判断→駆動
発進可判断状態において駆動意思あり［Ｃ］を判断すると、駆動状態に遷移する。駆動意思あり［Ｃ］は、シフトがドライブ（Ｄ）又はリバース（Ｒ）の位置以外になり、かつブレーキがＯＦＦされた（ブレーキペダルの踏み込みがない）場合など、によって判断することができる。
・駆動→停止要判断
駆動状態において駆動不可［Ｄ］を判断すると、停止要判断状態に遷移する。駆動不可［Ｄ］は、車両の動作状態がＲｅａｄｙ－ＯＦＦになる場合、車両運動系システムの信頼性がなくなる（システム失陥）場合、又は車掌機能などによって即時停止の判定がされる場合などのいずれか、によって判断することができる。車掌機能とは、動ける状態にある車両の動作を制限（ロック）できる機能である。
・停止要判断→停止
停止要判断状態において車両停止［Ａ’］を判断すると、停止状態に遷移する。車両停止［Ａ’］は、車両の速度（車速）がゼロ又は停止に相当するほぼゼロになった（車速≒０）場合など、によって判断することができる。
・発進可判断→停止
発進可判断状態において発車待機［Ａ”］を判断すると、停止状態に遷移する。発車待機［Ａ”］は、車掌機能などによって発車準備が完了しない場合、又は誤操作に応じてエラープルーフが作動する場合など、によって判断することができる。
・駆動→発進可判断
駆動状態において停止意思あり［Ｂ’］を判断すると、発進可判断状態に遷移する。停止意思あり［Ｂ’］は、ブレーキがＯＮされて（ブレーキペダルが踏み込まれた）、かつ車速がゼロ又は停止に相当するほぼゼロになった場合（車速≒０）など、によって判断することができる。
・停止要判断→駆動
停止要判断状態において駆動可能［Ｃ’］を判断すると、駆動状態に遷移する。駆動可能［Ｃ’］は、駆動可能［Ｂ］と同様に、車両の動作状態がＲｅａｄｙ－ＯＮになり、かつ車両運動系システムの信頼性がある場合など、によって判断することができる。
・停止→停止要判断
停止状態において車両転がり［Ｄ’］を判断すると、停止要判断状態に遷移する。車両転がり［Ｄ’］は、停止している車両が前進又は後退し始めた（｜車速｜＞０）場合など、によって判断することができる。
・停止、発進可判断、駆動、停止要判断→固定
停止、発進可判断、駆動、及び停止要判断のいずれかの状態において車両固定［Ｅ］を判断すると、固定状態に遷移する。車両固定［Ｅ］は、シフトがパーキング（Ｐ）の位置になった場合、又はパーキングブレーキが作動した場合など、によって判断することができる。

２－３：輸送ステート
輸送ステートは、自動車モードの配下で状態を遷移させる。この輸送ステートにおいて取り得る車両の状態には、待機、停留、出発、及び移動の各状態がある。「待機」は、車両制御システムの初期状態を示す。車両をモビリティニーズがない個人所有車両（ＰｏＶ）として使用する場合には、この待機状態が選択される。「停留」は、立ち寄る目的地における人員の乗り降りや荷物の積み下ろしなどのための駐車、及び駐車に付随するタスクを実現する状態を示す。「出発」は、次の目的地に向かう際の発車直前の準備や点検を実施する状態を示し、準備や点検が完了するまで状態を維持する。「移動」は、輸送中の計画進捗状況（他の情報を参照）や目的に応じたタスクシーケンスを実現する状態を示す。

図５は、輸送ステートにおける、待機（ＩＤ＝０）、停留（ＩＤ＝１）、出発（ＩＤ＝２）、及び移動（ＩＤ＝３）の状態遷移図である。各状態間の遷移は、以下に説明する条件に基づいて実行される。

・待機→停留
待機状態において運行開始［Ａ］を判断すると、停留状態に遷移する。運行開始［Ａ］は、移動サービスの開始を受け付けた場合など、によって判断することができる。この停留に付随する主なタスクとしては、他ステートの遷移条件の切り替えなどを例示できる。
・停留→出発
停留状態において発車準備［Ｂ］を判断すると、出発状態に遷移する。発車準備［Ｂ］は、出発予定時刻に到達したことを示す情報を検知した場合など、によって判断することができる。この出発に付随する主なタスクとしては、人流サービスにおける自動ドアの閉扉や、閉動作途中の車両固定解除の禁止などを例示できる。
・出発→移動
出発状態において発車［Ｃ］を判断すると、移動状態に遷移する。発車［Ｃ］は、上述した走行ステートが駆動状態に遷移した場合など、によって判断することができる。この出発に付随する主なタスクとしては、人流に関する各種のアナウンスなどを例示できる。
・移動→停留
移動状態において移動完了［Ｄ］を判断すると、停留状態に遷移する。移動完了［Ｄ］は、目的地に到着したことを示す情報を検知した場合など、によって判断することができる。この停留に付随する主なタスクとしては、車両固定の指令を発信することや、人流サービスにおける自動ドアの開扉などを例示できる。
・停留→待機
停留状態において運行終了［Ｅ］を判断すると、待機状態に遷移する。運行終了［Ｅ］は、移動サービスが完了した場合や、移動サービスの中止を受け付けた場合など、によって判断することができる。この待機に付随する主なタスクとしては、遷移条件のリセットなどを例示できる。

２－４：電力インフラ協調ステート
電力インフラ協調ステートは、電化モードの配下で状態を遷移させる。この電力インフラ協調ステートにおいて取り得る車両の状態には、待機、準備、充電、及び給電の各状態がある。「待機」は、インフラ協調の要求がない初期状態を示す。「準備」は、インフラ協調の要求を認識した後の、充電又は放電（給電）の工程の指定を待っている状態又はこれらの工程を切り替える途中の状態を示す。「充電」は、インフラから車両（の蓄電池）へ充電を実施する充電工程である状態を示す。「給電」は、車両（の蓄電池）からインフラへエネルギーを供給する供給工程である状態を示す。

図６は、電力インフラ協調ステートにおける、待機（ＩＤ＝０）、準備（ＩＤ＝１）、充電（ＩＤ＝２）、及び供給（ＩＤ＝３）の状態遷移図である。各状態間の遷移は、以下に説明する条件に基づいて実行される。

・待機→準備
待機状態において協調開始指示［Ａ］を判断すると、準備状態に遷移する。協調開始指示［Ａ］は、インフラ協調の要求を検知した場合などによって判断することができる。
・準備→待機
準備状態において協調終了指示［Ｂ］を判断すると、待機状態に遷移する。協調終了指示［Ｂ］は、インフラ協調の要求を検知しなくなった場合などによって判断することができる。
・準備→充電
準備状態において充電開始指示［Ｃ］を判断すると、充電状態に遷移する。充電開始指示［Ｃ］は、インフラ側から車両に対して充電が指示された場合などによって判断することができる。
・充電→準備
充電状態において充電終了［Ｄ］を判断すると、準備状態に遷移する。充電終了［Ｄ］は、インフラ側から車両に対して充電終了の指示又は給電開始の指示がされた場合などによって判断することができる。充電から給電への工程切り替えも、充電状態から一旦準備状態に戻した後で給電状態に遷移する。
・準備→給電
準備状態において給電開始指示［Ｅ］を判断すると、給電状態に遷移する。給電開始指示［Ｅ］は、インフラ側から車両に対して給電が指示された場合などによって判断することができる。
・給電→準備
給電状態において給電終了［Ｆ］を判断すると、準備状態に遷移する。給電終了［Ｆ］は、インフラ側から車両に対して給電終了の指示又は充電開始の指示がされた場合などによって判断することができる。給電から充電への工程切り替えも、給電状態から一旦準備状態に戻した後で充電状態に遷移する。

図７に、自動車モード時における各ステート（走行、運動、輸送）での遷移相関の一例を示す。図７に示すように、本実施形態の車両制御モード管理では、メインモード及び各ステートの単独の状態又は複数の状態の組み合わせにより、他の状態への遷移を禁止させることで各種要求の干渉を回避させたり、他の状態への強制的に遷移させることで制御停滞などを回避させたりする。

＜ａ１＞トリップ開始要求が発生してメインモードが休止から自動車に遷移すると、走行ステートが待機から始動に遷移する。＜ａ２＞ＭａａＳの移動サービスの場合には、さらに上位の移動サービス要求と連動する。
＜ｂ１＞Ｒｅａｄｙ－ＯＮ後に走行ステートが走行に遷移すると、運動ステートが発進可判断に遷移する。＜ｂ２＞ＭａａＳの移動サービスの場合には、出発準備が完了する（輸送ステートにおいて出発に遷移）まで、運動ステートの停止状態が保持される。
＜ｃ＞ＭａａＳの移動サービスの場合、停留の要求があるときには、運動ステートにおいて発進可判断への遷移を禁止する。
＜ｄ＞走行中にＲｅａｄｙ－ＯＦＦを判断した場合には、運動ステートを停止要判断へ遷移させ、駆動力を出さずにその場で車両を停止させる。
＜ｅ１＞車両の走行が終了したとき、運動ステートを固定状態に遷移させてトリップを完了させた後、＜ｅ２＞メインモードを自動車から休止に遷移させて、車両の仕様を完了させる。＜ｅ０＞ＭａａＳの移動サービスの場合は、輸送ステートが停留から待機に遷移したことに応じて、走行ステートが終了から待機に遷移する。

（３）サブモード
サブモードは、単独もしくは複数のモード配下において制御目的及び手段を限定する。このサブモードには、運転サブモード、充電サブモード、装備給電サブモード、補機補充サブモード、及びＡＣ給電サブモードがある。各サブモードでは、制御目的や手段に応じて次のように車両状態が遷移する。

３－１：運転サブモード
運転サブモードは、自動車モードの配下で状態を遷移させる。この運転サブモードにおいて取り得る車両の状態には、マニュアル、セミオート、及びフルオートの各状態がある。「マニュアル」は、車両制御システムの初期状態を示し、ドライバー主権による運転状態である（手動かつ有人）。アダプティブクルーズコントロール（ＡＣＣ）やレーントレーシングアシスト（ＬＴＡ）などの運転支援機能の作動もマニュアル状態で実行される。「セミオート」は、自動運転システム主権による運転状態ではあるが、有事の際にはドライバーへ運転主権を移譲することを前提とした状態を示す（自動かつ有人）。このセミオートは、自動車技術会（ＳＡＥ）が定義する自動運転のレベル４以下を想定している。「フルオート」は、自動運転システム主権による運転状態において、ドライバーが不在でも運転が成立することを前提とした状態を示す（自動かつ無人）。このフルオートは、自動車技術会（ＳＡＥ）が定義する自動運転のレベル５以上を想定している。リモート駐車機能の作動は、フルオート状態で実行可能である。

図８は、運転サブモードにおける、マニュアル（ＩＤ＝０）、セミオート（ＩＤ＝１）、及びフルオート（ＩＤ＝２）の状態遷移図である。各状態間の遷移は、以下に説明する条件に基づいて実行される。

・マニュアル→セミオート
マニュアル状態において自動運転開始［Ａ］を判断すると、セミオート状態に遷移する。自動運転開始［Ａ］は、車両のドライバーから自動運転（レベル１～レベル４）の要求があった場合などによって判断することができる。
・セミオート→マニュアル
セミオート状態において自動運転終了［Ｂ］を判断すると、マニュアル状態に遷移する。自動運転終了［Ｂ］は、車両のドライバーから自動運転（レベル１～レベル４）の要求の取り下げがあった場合、自動運転の対象エリアを抜けた（トリップ完了）場合、自動運転システムの失陥後に主権がドライバーに移譲（ハンドオーバーが完了）された場合など、によって判断することができる。
・セミオート→フルオート
セミオート状態においてレベルアップ［Ｃ］を判断すると、フルオート状態に遷移する。レベルアップ［Ｃ］は、車両のドライバーやＭａａＳの移動サービスから自動運転（レベル５以上）の要求があった場合、リモート駐車（入庫／出庫）の受け付けがあった場合、ドライバーの失神（デッドマン判定）を検知した場合など、によって判断することができる。
・フルオート→セミオート
フルオート状態においてレベルダウン［Ｄ］を判断すると、セミオート状態に遷移する。レベルダウン［Ｄ］は、車両のドライバーを認識し、かつ自動運転（レベル１～レベル４）の要求があった場合などによって判断することができる。
・マニュアル→フルオート
マニュアル状態において自動運転開始［Ｅ］を判断すると、フルオート状態に遷移する。自動運転開始［Ｅ］は、車両のドライバーやＭａａＳの移動サービスから自動運転（レベル５以上）の要求があった場合、リモート駐車（入庫／出庫）の受け付けがあった場合、などによって判断することができる。
・フルオート→マニュアル
フルオート状態において自動運転終了［Ｆ］を判断すると、セミオート状態に遷移する。自動運転終了［Ｆ］は、車両のドライバーから自動運転（レベル５以上）の要求の取り下げがあった場合、自動運転の対象エリアを抜けた（トリップ完了）場合、バレー駐車による出庫が完了した場合など、によって判断することができる。

３－２：充電サブモード
充電サブモードは、電化モードの配下で状態を遷移させる。この充電サブモードにおいて取り得る車両の状態には、休止、ＡＣ充電、ＤＣ充電、非接触、接触、及びソーラー高圧の各状態がある。「休止」は、車両の充電を実施していないときのデフォルトの状態を示す。「ＡＣ充電」、「ＤＣ充電」、「非接触」、「接触」、及び「ソーラー高圧」は、それぞれ以下に示す車両の充電を実施している状態を示す。

ＡＣ充電は、交流電源による車両の蓄電池への充電を選択している状態を示す。このＡＣ充電は、ユーザーによるＡＣ電源設備へのプラグ挿入による充電（タイマー起動による開始を含む）、車両のインフラ協調（Ｖ２Ｇ）の過程におけるＡＣ電力の受電、駐車中サービス時のＡＣ充電器による車両装備への直接電力供給（プレ空調、マイルーム使用など）など、が行われたときに選択される。ＡＣ充電状態へ遷移するためのトリガーとしては、ユーザーから入力されるプラグ接続操作、プレ空調要求、及びマイルーム要求や、システムから要求されるタイマー設定時刻到達、及びＶ２ｘ／ＶＰＰなど、を例示できる。

ＤＣ充電は、直流電源による車両の蓄電池への充電又は蓄電池からの放電を選択している状態を示す。このＤＣ充電は、ユーザーによるＤＣ電源設備へのプラグ挿入による充電、車両のインフラ協調（Ｖ２Ｇ）の過程におけるＤＣ電力の受電又は給電、駐車中サービス時との並列での電力供給など、が行われたときに選択される。ＤＣ充電状態へ遷移するためのトリガーとしては、ユーザーから入力されるプラグ接続操作、プレ空調要求、及びマイルーム要求や、システムで判断されるタイマー設定時刻到達、及びＶ２ｘ／ＶＰＰなど、を例示できる。

非接触は、充電設備と接触しない車両の蓄電池への充電を選択している状態を示す。この非接触は、充電スタンドに設置された車両に対してユーザーのスイッチ（ＳＷ）操作によるマニュアル充電などが行われたときに選択される。非接触状態へ遷移するためのトリガーとしては、車両の充電スタンド設置後にユーザーから入力されるＳＷ操作などを例示できる。

接触は、充電設備と接触した車両の蓄電池への充電を選択している状態を示す。この接触は、位置決め及びペアリングされた充電スタンドに設置された車両に対して、充電スタンドと車両との結合による充電などが行われたときに選択される。接触状態へ遷移するためのトリガーとしては、車両の位置決め及びペアリングがされた後、充電スタンドへの車両の設置が完了したことなどを例示できる。

ソーラー高圧は、ソーラー発電システムで発生した電力を一時的に貯めるためのバッファ用バッテリーから高圧の蓄電池への充電を選択している状態を示す。このソーラー高圧は、バッファ用バッテリーの蓄電量（ＳＯＣ）が所定の閾値に到達した場合などに選択される。ソーラー高圧へ遷移するためのトリガーとしては、システムで判断されるバッファ用バッテリーの蓄電量の閾値への到達などを例示できる。

図９は、充電サブモードにおける、休止（ＩＤ＝０）、ＡＣ充電（ＩＤ＝１）、ＤＣ充電（ＩＤ＝２）、非接触（ＩＤ＝３）、接触（ＩＤ＝４）、及びソーラー高圧（ＩＤ＝５）の状態遷移図である。休止状態において、ＡＣ充電、ＤＣ充電、非接触、接触、及びソーラー高圧の少なくとも１つの要求が発生すると、要求された充電の状態に遷移する。いずれの充電の要求がなくなれば、休止状態に遷移する。複数の要求が重複した場合などの各状態の優先順位は、ＡＣ充電及びＤＣ充電が最も高く、ソーラー高圧が最も低い。ＡＣ充電とＤＣ充電とは、先に充電要求が発生した方式の状態が選択される（先勝ち）が、同時に要求が発生した場合にはＤＣ充電が選択される。また、非接触と接触とは排他的関係にあり、同時には成立しない。

３－３：装備給電サブモード
装備給電サブモードは、自動車モード、電化モード、及び発電モードの配下で状態を遷移させる。この装備給電サブモードにおいて取り得る車両の状態には、休止、電化サービス、移動準備、乗降車、及びＯＴＡの各状態がある。「休止」は、装備給電に関するサービスを実施していないときのデフォルトの状態を示す。「電化サービス」、「移動準備」、「乗降車」及び「ＯＴＡ」は、それぞれ以下に示す装備給電に関するサービスを実施している状態を示す。

電化サービスは、車両を直接的な走行以外で使用した固有のサービスの提供を選択している状態を示す。この電化サービスは、自動車モード、電化モード、及び発電モードの全てにおいて選択可能な状態である。電化サービスが選択される固有のサービスとしては、見守り機能やコネクティッド活用機能などのサービスを例示できる。

移動準備は、車両の走行前の準備に特化した固有のサービスの提供を選択している状態を示す。この移動準備は、電化モードのみ（又は電化サービスから乗降車に継続して遷移する場合の自動車モード）で選択可能な状態である。移動準備が選択される固有のサービスとしては、プレ空調機能などのサービスを例示できる。

乗降車は、車両の走行におけるドア開閉の前後に特化した固有のサービスの提供を選択している状態を示す。この乗降車は、自動車モード、電化モード、及び発電モードの全てにおいて選択可能な状態である。乗降車が選択される固有のサービスとしては、電子ミラーやおもてなし機能などのサービスを例示できる。

ＯＴＡは、無線通信によるリプログラミング（リプロ）の提供を選択している状態を示す。このＯＴＡは、電化モードのみで選択可能な状態である。ＯＴＡは、他のサービスを全て停止させることを前提として選択される状態である。

図１０は、装備給電サブモードにおける、休止（ＩＤ＝０）、電化サービス（ＩＤ＝１）、移動準備（ＩＤ＝２）、乗降車（ＩＤ＝３）、及びＯＴＡ（ＩＤ＝４）の状態遷移図である。休止状態において、電化サービス、移動準備、乗降車、及びＯＴＡの少なくとも１つの要求が発生すると、要求されたサービスを提供できる状態に遷移する。いずれのサービス提供の要求がなくなれば、休止状態に遷移する。複数の要求が重複した場合などの各状態の優先順位は、ＯＴＡが最も高く、他の状態は上位が下位を包括する条件で乗降車、移動準備、及び電化サービスの順に優先度が高くなる。

３－４：補機補充サブモード
補機補充サブモードは、自動車モード、電化モード、及び発電モードの配下で状態を遷移させる。この補機補充サブモードにおいて取り得る車両の状態には、休止、高圧汲み出し、及びソーラー低圧の各状態がある。「休止」は、車両の充電を実施していないときのデフォルトの状態を示す。「高圧汲み出し」及び「ソーラー低圧」は、それぞれ以下に示す車両の充電を実施している状態を示す。

高圧汲み出しは、長期にわたる車両の駐車時など、補機電池の容量が低下して高圧電池から補機電池への電力を移動させる電力汲み出し処理を選択している状態を示す。この高圧汲み出しは、電化モードのみで選択可能な状態である。高圧電池による電力汲み出し機能は、ユーザーの指示などによらずシステムが自律的に起動することを前提としている。

ソーラー低圧は、車両の駐車中などに、ソーラー発電システムで発生した電力を一時的に貯めるためのバッファ用バッテリーから高圧の蓄電池への充電を選択している状態を示す。このソーラー低圧は、自動車モード、電化モード、及び発電モードの全てにおいて選択可能な状態である。バッファ用バッテリーから高圧の蓄電池への充電機能は、バッファ用バッテリーの蓄電量（ＳＯＣ）が所定の閾値に到達したことを検知したシステムが自律的に起動することを前提としている。

図１１は、補機補充サブモードにおける、休止（ＩＤ＝０）、高圧汲み出し（ＩＤ＝１）、及びソーラー低圧（ＩＤ＝２）の状態遷移図である。休止状態において、高圧汲み出し及びソーラー低圧の少なくとも１つの要求が発生すると、要求された充電を提供できる状態に遷移する。いずれの充電の要求がなくなれば、休止状態に遷移する。複数の要求が重複した場合には、高圧汲み出しの状態がソーラー低圧の状態よりも優先される。

３－５：ＡＣ給電サブモード
ＡＣ給電サブモードは、自動車モード、電化モード、及び発電モードの配下で状態を遷移させる。このＡＣ給電サブモードにおいて取り得る車両の状態には、休止、室内ＡＣＣ、室内Ｖ２Ｌ、外部Ｖ２Ｇ、及び外部Ｖ２Ｌの各状態がある。「休止」は、車両の充電を実施していないときのデフォルトの状態を示す。「室内ＡＣＣ」、「室内Ｖ２Ｌ」、「外部Ｖ２Ｇ」、及び「外部Ｖ２Ｌ」は、それぞれ以下に示す車両の充電を実施している状態を示す。

室内ＡＣＣは、ユーザーによる専用のスイッチ（ＳＷ）操作によるアクセサリー機器の利用を選択している状態を示す。この室内ＡＣＣは、自動車モード及び電化モードにおいて選択可能な状態であり、固有の駐車中サービスとセットで選択され得る。

室内Ｖ２Ｌは、固有のコマンド操作による非常用発電を選択している状態を示す。この室内Ｖ２Ｌは、発電モードのみで選択可能な状態である。非常用発電を行うために、エンジンの始動やＦＣ（燃料電池）の利用の許可がなされる。

外部Ｖ２Ｇは、専用の治具を車両に挿入した後、外部からの指令に基づいて家屋やシステム系統と協調したＡＣ充放電を選択している状態を示す。この外部Ｖ２Ｇは、電化モードのみで選択可能な状態である。

外部Ｖ２Ｌは、専用の治具を車両に挿入した後、固有のコマンド操作による非常用発電を選択している状態を示す。この外部Ｖ２Ｌは、発電モードのみで選択可能な状態である。非常用発電を行うために、エンジンの始動やＦＣ（燃料電池）の利用の許可がなされる。

図１２は、ＡＣ給電サブモードにおける、休止（ＩＤ＝０）、室内ＡＣＣ（ＩＤ＝１）、室内Ｖ２Ｌ（ＩＤ＝２）、外部Ｖ２Ｇ（ＩＤ＝３）、及び外部Ｖ２Ｌ（ＩＤ＝４）の状態遷移図である。休止状態において、室内ＡＣＣ、室内Ｖ２Ｌ、外部Ｖ２Ｇ、及び外部Ｖ２Ｌの少なくとも１つの要求が発生すると、要求された充電の状態に遷移する。いずれの充電の要求がなくなれば、休止状態に遷移する。

［具体例］
図１３乃至図２５をさらに参照して、上述したメインモードの各モード（自動車、電化、発電、休止）、各ステート（走行、運動、輸送、電力インフラ協調）、及び各サブモード（運転、充電、装備給電、補機補充、及びＡＣ給電）の連動した状態遷移の具体的な事例について説明する。以下の説明では、メインモード、ステート、及びサブモードの状態を「モビシス状態」という。

（事例１）
図１３に、電力インフラ協調ステート状態と連動した充電サブモード及びＡＣ給電サブモードの遷移の例（事例１）をまとめた図を示す。インフラ協調の指示がない場合は、状態が「待機ステート」に固定される。インフラ協調の指示により、「準備」、「充電」、及び「給電」の各状態に遷移する。協調中の充電と給電との切り替え時は、一旦「準備」を介して状態を切り替える。車両の都合によりインフラ協調の指示に従えない場合も同様である。

（事例２）
図１４に、運転サブモード状態による走行ステートの「始動」状態への遷移許可条件の切り替えの例（事例２）をまとめた図を示す。図１４では、マニュアル、セミオート、及びフルオートの各状態において、走行ステートの待機から始動への状態遷移を許可する判定条件を示している。

（事例３）
図１５に、自動車モード中のステート状態による直接的運動系への要求の例（事例３）をまとめた図を示す。図１５に示すように、主要機能を制御する管理部に対して、モビシス状態をインプットすることで、複数の機能に跨がる車両全体の振る舞いを一括で統制することが可能となる。また、モビシス状態によって、直接的な指令を決定することができる。

（事例４）
図１６に、自動車モード中の上位要求のモビシス状態によるゲート調停の例（事例４）をまとめた図を示す。図１６に示すように、主要機能を制御する管理部に対して、モビシスの状態をインプットすることで、複数の機能に跨がる車両全体の振る舞いを一括で統制することが可能となる。また、上位からの動作要求に対して、モビシス状態又は任意のシーン情報との組み合わせにより、出力の禁止や制限を実施することができる。

（事例５）
図１７に、輸送サービス中のアクティビティに対する調停の例（事例５）をまとめた図を示す。輸送サービスにおける基本的な流れは、車両が停留所に到着したとき、乗員の乗り降りがあれば車両を固定した後に自動ドアを開き、出発前は発車待機の状態で自動ドアの全閉を実施する。図１７に示すように、主要機能を制御する管理部に対して、モビシス状態をインプットすることで、複数の機能に跨がる車両全体の振る舞いを一括で統制することが可能となる。また、モビシス状態によって、直接的な指令を決定することができる。

（事例６）
図１８に、モビシス状態とシーン情報とによる自動車モード中の電源調停の例（事例６）をまとめた図を示す。図１８に示すように、主要機能を制御する管理部に対して、モビシス状態をインプットすることで、複数の機能に跨がる車両全体の振る舞いを一括で統制することが可能となる。また、モビシス状態によって、直接的な指令を決定することができる。また、上位からの動作要求に対して、モビシス状態又は任意のシーン情報との組み合わせにより、出力の禁止や制限を実施することができる。

（事例７）
図１９に、充放電要求調停によるサブモード遷移状態の組み合わせ例をまとめた図（事例７）を示す。図１９は、充電サブモードの各状態を列に、装備給電サブモード及び補機補充サブモードの各状態を行に記載し、各組み合わせにおける充電のみ実行可、放電のみ実行可、充電と放電とが共存可を示している。

装備給電サブモードがＯＴＡかつ充電サブモードがＡＣ充電又はＤＣ充電の場合（＊１）、プラグ接続を伴う充電中は走行前提の装備駆動は適用外とされる。ただし、プラグアウト後は遷移を許可する。装備給電サブモードが休止以外かつ充電サブモードがソーラー高圧の場合（＊２）、充電電力よりも汲み出し中の損失の方が大きくなる公算が高いため、ソーラー充電は適用しない。充電サブモードがソーラー高圧の場合（＊３）、ソーラーシステムにおいては高圧充電と低圧補充は排他関係にあるため、高圧側を優先する。補機補充サブモードが高圧汲み出しかつ充電サブモードがＡＣ充電、ＤＣ充電、非接触、又は接触の場合（＊４）、該当充電システムがリプロ対象であれば汲み出しのみ実行する。なお、停電によるリプロ失敗を回避するため、いずれの場合も予め必要なエネルギーを蓄積した後にリプロの実行を行う。補機補充サブモードがソーラー低圧かつ充電サブモードがＡＣ充電、ＤＣ充電、非接触、又は接触の場合（＊５）、通常充電中においても補機電池の容量低下時のメインＤＤＣ（ＤＣＤＣコンバーター）による促進補給を想定する。充電サブモードがＡＣ充電、ＤＣ充電、非接触、又は接触の場合（＊６）、走行中と同様に既存のＤＤＣとソーラー汲み出し用ＤＤＣの同時駆動の許容を前提とする。補機補充サブモードが移動準備かつ充電サブモードが非接触又は接触の場合（＊７）、一部ユーザーの乗車を伴うサービス（マイルーム充電など）については、リジェクトが必要となる可能性がある。補機補充サブモードがＯＴＡかつ充電サブモードが非接触又は接触の場合（＊８）、走行前提のドライバー乗降前後は、非接触充電の一時中断を必要とする可能性がある。

図２０に、装備給電サブモードと補機補充サブモードとの間の調停要件を示す。装備給電サブモードがＯＴＡの場合は給電が優先となり、装備給電サブモードがＯＴＡ以外の場合は共存可能である。各給電及び高圧汲み出しにおける都度の各々の採否は、最終的には優先度ランクによる需要供給調停に依存する。給電とソーラー低圧との共存は、かつ走行移行後のシームレスな継続も可能である。モビシスを共存可能にしておけば、バッファ用バッテリーを廃止した際にもエネルギーの有効活用を期待できる。

（事例８）
図２１に、ＡＣ給電サブモードと他の充放電のサブモードとの組み合わせにおける調停要件例（事例８）をまとめた図を示す。図２１は、ＡＣ給電サブモードの各状態を列に、充電サブモード、装備給電サブモード、及び補機補充サブモードの各状態を行に記載し、各組み合わせにおける、○：充電と放電とが共存可、△：充放電のみ可、▽：ＡＣ給電のみ可、×：排他（先勝ち）、□：ＡＣ中発電途中の放電側遷移は可（逆は不可）、●：排他（適宜切り替え）、▲：特定の「電化サービス」中のみ共存可（他は充放電のみ可）、及び▼：「移動準備」未実施時のみＡＣのみに遷移可（他は排他先勝ち）を示している。なお、－は、その組み合わせが無いことを示す。カッコ付きの共存可は、モビシスでの遷移は許容し、最終的には統合マネージャの電力マネによるアクティビティ間での優先順位調停やアクティビティ側でのシーン情報などによる要求可否判断などにより決定する。

（事例９）
図２２に、ＡＣ充電の制御フローの例（事例９）を示す。
＜ａ＞充電プラグ接続操作のエッジ検知又は接続中のスケジュール管理からの時刻設定通知でモードを開始する。これにより、ＩＧＢ信号を出力し、パワトレ充電系システムを起動する。デフォルトの充電タイマーが有効かつ時刻未到達時も、所要時間算出のためエッジ検知後はＡＣリレー接続まで実施する。
＜ｂ＞タイマー要求を受け、インフラ、電池状態、及び目標充電量から所要時間を算出して起動を予約する。なお、接続直後に時間が不足しているときには、即時開始する。
＜ｃ＞充電方式の選択結果の伝達及び実行要求を受け、パワトレにて充電実行を管理する（停電、プラグ抜きなどによる中断遷移を含む）。そして、充電完了又は中止確定後は、モビシスに結果を伝達し制御モードが終了する。

（事例１０）
図２３に、高圧補機バッテリー補充制御フローの例（事例１０）を示す。
＜ａ＞インフラからのＶＰＰ実施要求を受信後、切り替えステートを「準備」、メインモードを「電化」に遷移させる。
＜ｂ＞接続されたインフラからの情報によって、充放電方式がＡＣであることを認識する。
＜ｃ＞インフラ要求を受け、充電サブモードを「ＡＣ充電」に遷移させて充電を実行する。
＜ｄ＞充電終了後、切り替えステートを「準備」に戻す。インフラ可の中断し例示も同様である。
＜ｅ＞インフラからの給電要求時は、ＡＣ給電サブモードを「外部Ｖ２Ｇ」に遷移させて実行する。
＜ｆ＞充電同様、切り替えステートを「準備」に戻して終了する。タイムガードなどによって適宜「待機」でモードを完了する。このように、充放電切り替えステートの設定により、充電と給電との排他調停を実施し、制御干渉を回避することができる。

（事例１１）
図２４に、駐車中サービス、高圧汲み出し、及びＡＣ充電による複合制御フローの例（事例１１）を示す。
＜ａ＞サービスニーズ発生時に、装備給電サブモードを「電化サービス」に遷移させ電化モードを開始する。さらに、要求サービスに応じた電源を投入する。
＜ｂ＞統合マネ／電力マネにおける調停にて高圧利用が許可された場合、汲み出しを指令して、ＩＧＢを起動させる。
＜ｃ＞さらに、ＡＣ充電が可能なときに、統合マネ／電力マネにおける調停にてＡＣによる電力供給が許可された場合、充電サブモードを「ＡＣ充電」に遷移させて、充電指令の出力によって並列で実行する。

（事例１２）
図２５に、非常用発電制御フローの例（事例１２）を示す。
＜ａ＞ユーザー操作による発電要求を受けて、ＡＣ給電サブモードを「外部Ｖ２Ｌ」及び「室内Ｖ２Ｌ」のいずれかに遷移させる。そして、メインモードを「休止」から「（非常用）発電」に遷移させる。
＜ｂ＞出力処理部において、ＩＧＰ信号を出力し、パワトレシステムを起動させる。同時に、ＡＣ給電指令を出力する。なお、外部給電の場合は、充電システムを起動させるためのＩＧＢ信号、リレー切り替えのための外部出力指令も出力する。
＜ｃ＞上位からの給電及び出力指令を受けて、パワトレドメインにおいて要求を実現させる。
＜ｄ＞ユーザー操作での要求取り下げがない場合でも、供給限界に到達したらサービスを終了させる。

［効果など］
以上のように、本開示の一実施形態に係る情報処理装置は、アクティビティ実現を可能にする制御アーキテクチャにおいて、予め定められた抽象的コマンドをコールするのみで、複合的なアクチュエータ動作調停、必要なシステムを起動するための電源起動、エネルギー需要に対する供給調停（可否判断、供給源選択）、車両全体の振る舞いを決めるモード遷移を自動的に決定できる種々コマンドをライブラリとして予め備える。

これにより、アプリケーション開発者は、車両の電子プラットフォーム構成、規定コマンド、システム構成（ハードバリエーション）、及びエネルギー体系などを意識することなく、目的に対して直感的なアルゴリズム設計による新規又は追加のアプリケーション（サービス）を容易に開発することが可能となる。

また、本実施形態に係る情報処理装置は、共有ポータル情報の参照及びコマンドライブラリの活用のみで、関連するアプリケーションの修正が必要なく、新規又は追加するアプリケーションを単体でインストールだけで機能追加を行うことが可能となる。

また、車両のシステム側（Ｉｎ－Ｃａｒ－ＯＳ側）において車両の安心安全を担保できるため、アプリケーション開発者は、車両の安心安全などに関わる制限を気にすることなく新規又は追加のアプリケーションを容易に開発することが可能となる。

また、本実施形態に係る情報処理装置は、階層構造化における各入出力インターフェイス（Ｉ／Ｆ）の範疇での振る舞いによって車両の安心安全を担保するため、車両の想定外の挙動による不具合の発生や制御干渉確認などの検査工数の肥大化を回避することができる。

さらに、本実施形態に係る情報処理装置は、モードやステートを用いた状態の遷移によって車両の制御状況を一元的に管理できるため、複数の異なる機能システムの各機能間の動作に不整合がないように車両全体を好適に制御することができる。

以上、本開示技術の一実施形態を説明したが、本開示は、情報処理装置だけでなく、プロセッサとメモリを備えた情報処理装置が実行する方法、その方法のプログラム、そのプログラムを記憶したコンピューター読み取り可能な非一時的な記録媒体、あるいは情報処理装置を搭載した車両などとして捉えることが可能である。

本開示は、車両などに搭載される情報処理装置に有用である。

１０ サービスアプリケーション
２０ 情報処理装置
２１ コマンドライブラリ
２２ モビリティシステム制御部
２３ 情報共有ポータル
２４ 統合マネージャ
３０ 車両デバイス
４０ プラントライブラリ
５０ 運転アプリケーション

Claims (5)

1. 車両に搭載される情報処理装置であって、
   車両に対する要求に応じて、車両の使われ方や動作に関する車両の振る舞いを定める複数のモードの中から１つのモードを決定する決定部と、
   前記決定部によって決定された前記モードにおいて許容されるステート及びサブモードにおいて取り得る複数の状態の間で、車両の状態を遷移させる状態遷移部と、
   前記状態遷移部が遷移させた状態に基づいて車両を制御する制御部と、を備える、
   情報処理装置。
2. 前記状態遷移部が車両の状態を遷移させるための条件は、前記決定部によって決定された前記モードに依存する、
   請求項１に記載の情報処理装置。
3. 車両に搭載される情報処理装置のコンピューターが実行する方法であって、
   車両に対する要求に応じて、車両の使われ方や動作に関する車両の振る舞いを定める複数のモードの中から１つのモードを決定するステップと、
   前記決定された前記モードにおいて許容されるステート及びサブモードにおいて取り得る複数の状態の間で、車両の状態を遷移させるステップと、
   前記遷移させた状態に基づいて車両を制御するステップと、を含む、
   方法。
4. 車両に搭載される情報処理装置のコンピューターに実行させるプログラムであって、
   車両に対する要求に応じて、車両の使われ方や動作に関する車両の振る舞いを定める複数のモードの中から１つのモードを決定するステップと、
   前記決定された前記モードにおいて許容されるステート及びサブモードにおいて取り得る複数の状態の間で、車両の状態を遷移させるステップと、
   前記遷移させた状態に基づいて車両を制御するステップと、を含む、
   プログラム。
5. 請求項１又は２に記載の情報処理装置を搭載した、車両。

Images