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

Description

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

特許文献１に、複雑な大規模システム開発を行う際にも開発期間の短縮化が図れる車両用ネットワークシステムが開示されている。この車両用ネットワークシステムでは、複数の電子制御装置（ＥＣＵ：Electronic Control Unit）に跨がるネットワークに対し、複数の階層に分けた分散制御プラットフォーム構造を構築して各階層で個別の役割を担うことで、協調制御を実現している。

特開２００６－１４２９９４号公報

特許文献１に記載されたシステムは、車両としての予め想定された機能の範囲において、車両の制御システム体系を前提として予め設定された要求のみを適用対象とした制御構造を採用している。そのため、制御システムにおいて予め設定されたものとは異なる車両操作や、車両デバイスを用いた本来とは異なる車両の新たな使い方などには、特許文献１に記載のシステムは適していない。

このため、例えば、サービス事業者などが後から車両に対して新規又は追加のサービスを提供しようとした場合、サービス事業者などのアプリケーション開発者は、その新規又は追加のサービスを実現するために必要な車両の内部構造（電子プラットフォーム、システム構成、及びエネルギー体系など）を具体的に把握した上でサービス用のアプリケーションを開発しなければならず、開発が複雑で期間が長くなる、作業コストが高くなる、などの課題がある。

本開示は、上記課題を鑑みてなされたものであり、アプリケーション開発者が簡易に機能開発をすることができる情報処理装置を提供することを目的とする。

上記課題を解決するために、本開示技術の一態様は、車両に搭載される情報処理装置であって、アプリケーションからの要求としてＡＰＩを介した第１入力を受け付ける第１処理部と、第１処理部が受け付けた第１入力を、少なくとも要求を実現するための車両デバイスの制御を管理する第１マネージャに向けた第２入力に変換する第２処理部と、第２処理部による変換後の第２入力を、少なくとも第１マネージャに出力する第３処理部と、を備える、情報処理装置である。

本開示の情報処理装置によれば、第２処理部が入力を変換するため、アプリケーション開発者が車両の電子プラットフォーム、システム構成、及びエネルギー体系などを意識せずに、簡易に機能開発をすることができる。

一実施形態に係る情報処理装置を含む車両制御システムの機能ブロック図 リモート空調（具体例１）を行う場合の各機能ブロック間の詳細な処理フロー例 図２の処理フローを大まかな流れで表したイメージ例 リモート空調をタイマーで設定した時刻に実施する場合の各機能ブロック間の詳細な処理フロー例 リモート空調を中止／終了する場合の各機能ブロック間の詳細な処理フロー例 リモート空調を実施中にドライブアウェイを行う場合の各機能ブロック間の詳細な処理フロー例 図６の処理フローを大まかな流れで表したイメージ例 リモート空調及びドライブアウェイ（具体例１）を実施する場合の主要構成の機能イメージ図 駐車中見守り撮影（具体例２）を実施する場合の主要構成の機能イメージ図 具体例２において、サービスＡＰＩとコマンドに対応した各機能ブロックへの処理との関連を説明する図

本開示の情報処理装置は、車両統合ＥＣＵ（セントラルＥＣＵ）単体、又は車外クラウド単体、もしくはこれらの連携によって、車両全体の動作や振る舞いを統括する頭脳中枢として動作する制御プラットフォームの機能を提供する。この制御プラットフォームにおいては、アプリケーション開発者は、制御プラットフォームの構造、規定されるコマンド、車両のシステム構成、及び車両で扱われるエネルギー体系などを意識することなく、簡易に新規又は追加のサービス開発が可能となる。

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

１．サービスアプリケーション１０
サービスアプリケーション１０は、車内外の情報及び車両の構成要素を活用してサービスを実現するアプリケーションが実装される機能ブロックである。このサービスには、自動車として又は製品としての車両のリアルタイムな動作の他に、例えば設定時刻に基づいたアプリケーション（自アプリ、他アプリ）の起動に関する予約、データベースの収集加工、記録媒体への記録、及び外部への無線送信などのアクティビティが含まれる。本実施形態のアプリケーションは、情報処理装置２０に対して、ＡＰＩ（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