特許 7571882 モビリティサービス提供システム、モビリティサービス提供サーバ、車両データ提供方法、プログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-15

(45)【発行日】2024-10-23

(54)【発明の名称】モビリティサービス提供システム、モビリティサービス提供サーバ、車両データ提供方法、プログラム

(51)【国際特許分類】

   G08G 1/00 20060101AFI20241016BHJP

   G08G 1/09 20060101ALI20241016BHJP

   G08G 1/13 20060101ALI20241016BHJP

   G06Q 50/10 20120101ALI20241016BHJP

   G16Y 10/40 20200101ALI20241016BHJP

【ＦＩ】

G08G1/00 D

G08G1/09 F

G08G1/13

G06Q50/10

G16Y10/40

【請求項の数】 14

(21)【出願番号】P 2023531991

(86)(22)【出願日】2022-06-28

(86)【国際出願番号】 JP2022025812

(87)【国際公開番号】W WO2023277032

(87)【国際公開日】2023-01-05

【審査請求日】2023-11-17

(31)【優先権主張番号】P 2021110905

(32)【優先日】2021-07-02

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000004260

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

(74)【代理人】

【識別番号】110000578

【氏名又は名称】名古屋国際弁理士法人

(72)【発明者】

【氏名】小見山 正俊

(72)【発明者】

【氏名】滝 顕匠

(72)【発明者】

【氏名】謝 凌非

(72)【発明者】

【氏名】梶岡 繁

(72)【発明者】

【氏名】田内 真紀子

【審査官】▲高▼木 真顕

(56)【参考文献】

【文献】特開２０２０－０１３５５７（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／００７８４７２（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１７／０１２４８７１（ＵＳ，Ａ１）

【文献】特表２０１９－５３０９１７（ＪＰ，Ａ）

【文献】特開２０２０－１８４３２２（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０８Ｇ １／００ － ９９／００

Ｇ０７Ｃ ５／００ － ５／１２

Ｇ０６Ｑ １０／００ － １０／３０

Ｇ０６Ｑ ３０／００ － ３０／０８

Ｇ０６Ｑ ５０／００ － ５０／２０

Ｇ０６Ｑ ５０／２６ － ９９／００

Ｇ１６Ｙ １０／００ － ４０／６０

Ｇ１６Ｚ ９９／００

(57)【特許請求の範囲】

【請求項1】

車両に搭載され前記車両から取得されるデータである車両データを収集するように構成された車載機（２）と、
前記車載機との無線通信を行うように構成されたモビリティサービス提供サーバ（３）と、
を備え、
前記車載機は、繰り返し前記車両データを前記モビリティサービス提供サーバに自発的に送信すると共に、前記モビリティサービス提供サーバからの要求に応じて前記車両データを前記モビリティサービス提供サーバに送信するように構成され、
前記モビリティサービス提供サーバは、
前記無線通信により前記車載機から取得した所定時点ごとの前記車両データを記憶するように構成された記憶部（１１３，１２５）と、
外部からの第１アクセス要求および第２アクセス要求を受け付けるように構成されたインタフェース部（１２２）と、
前記インタフェース部が前記第１アクセス要求を受け付けた場合、前記記憶部から前記車両データを取得し、前記インタフェース部を介して要求元に提供するように構成された第１制御部（１１９，１２７）と、
前記インタフェース部が前記第２アクセス要求を受け付けた場合、前記車載機にアクセスすることで該車載機から前記車両データを含むアクセス結果を取得し、前記インタフェース部を介して要求元に提供するように構成された第２制御部（１３０）と、
を備えるモビリティサービス提供システム。

【請求項2】

請求項１に記載のモビリティサービス提供システムであって、
前記第２制御部は、前記車両データを前記車載機から取得するため前記車載機に送信する取得要求と共に、前記車載機に予め割り当てられた車両認証情報を送信するように構成され、
前記車載機は、前記車両認証情報による認証に成功した場合に、前記取得要求によって要求された前記車両データを前記モビリティサービス提供サーバに送信するように構成された、
モビリティサービス提供システム。

【請求項3】

請求項１に記載のモビリティサービス提供システムであって、
前記モビリティサービス提供サーバを利用したモビリティサービスの提供元毎に、前記第２アクセス要求によるアクセス可能な範囲を規定するサービス別認可情報を記憶するように構成されたサーバ側記憶部（１４２）と、
前記第２アクセス要求を受け付けた場合、前記サービス別認可情報を参照して、前記モビリティサービスの提供元が、前記第２アクセス要求に示されたアクセス対象となる車両である対象車両へのアクセス権限を有するか否かを判定し、前記アクセス権限を有すると判定された場合に、前記対象車両に搭載された前記車載機へのアクセスを認可するように構成されたサーバ側認可部（１４４）と、
を更に備え、
前記車載機は、
前記対象車両へのアクセスを要求する可能性がある車両ユーザ毎に、前記第２アクセス要求によるアクセス可能な範囲を規定するユーザ別認可情報を記憶するように構成された車側記憶部（１４，２５）と、
前記モビリティサービス提供サーバから前記第２アクセス要求を受け付けた場合、前記ユーザ別認可情報を参照して、前記第２アクセス要求を要求した車両ユーザが、前記第２アクセス要求に示されたアクセス対象に対する前記アクセス権限を有するか否かを判定し、前記アクセス権限を有すると判定された場合に、前記アクセス対象へのアクセスを認可するように構成された車側認可部（１０７）と、
を更に備える、
モビリティサービス提供システム。

【請求項4】

請求項１に記載のモビリティサービス提供システムであって、
前記車載機は、
前記第２アクセス要求に示されたアクセス対象となる車両である対象車両へのアクセスを要求する可能性がある車両ユーザ毎に、前記第２アクセス要求によるアクセス可能な範囲を規定するユーザ別認可情報を記憶するように構成された車側記憶部（１４，２５）と、
前記モビリティサービス提供サーバから前記第２アクセス要求を受け付けた場合、前記ユーザ別認可情報を参照して、前記第２アクセス要求を要求した車両ユーザが、前記第２アクセス要求に示されたアクセス対象に対するアクセス権限を有するか否かを判定し、前記アクセス権限を有すると判定された場合に、前記アクセス対象へのアクセスを認可するように構成された車側認可部（１０７）と、
を更に備える、
モビリティサービス提供システム。

【請求項5】

請求項１から請求項４までのいずれか１項に記載のモビリティサービス提供システムであって、
前記車載機が送信する前記車両データには、前記車両から取得されるローデータを加工した加工データが含まれ、前記モビリティサービス提供サーバからの要求に応じて前記車載機が送信する前記車両データには、加工される前の前記ローデータが含まれる
モビリティサービス提供システム。

【請求項6】

車両に搭載された車載機から提供される車両データを記憶するように構成された記憶部と、
外部から第１アクセス要求および第２アクセス要求を受け付けるように構成されたインタフェース部と、
前記インタフェース部が前記第１アクセス要求を受け付けた場合、前記記憶部から前記車両データを取得し、前記インタフェース部を介して要求元に提供するように構成された第１制御部と、
前記インタフェース部が前記第２アクセス要求を受け付けた場合、前記車載機にアクセスすることで該車載機から前記車両データを含むアクセス結果を取得し、前記インタフェース部を介して要求元に提供するように構成された第２制御部と、
を備えるモビリティサービス提供サーバ。

【請求項7】

請求項６に記載のモビリティサービス提供サーバであって、
前記第１アクセス要求および前記第２アクセス要求には、当該モビリティサービス提供サーバを利用したサービスを提供するサービスユーザを識別するユーザ識別情報が含まれ、
前記インタフェース部は、
前記ユーザ識別情報を、取得可能な前記車両データの範囲を表す認可クラスに対応づけて記憶する認可情報記憶部（１４２）と、
前記第１アクセス要求および前記第２アクセス要求に示された前記ユーザ識別情報に基づいて、前記認可情報記憶部から取得される前記認可クラスに従って、前記第１アクセス要求および前記第２アクセス要求に示された取得の対象となる前記車両データが、該認可クラスによって認可された権限の範囲外である場合に、取得要求の受け付けを拒否する認可部（１４４）と、
を更に備えるモビリティサービス提供サーバ。

【請求項8】

請求項６または請求項７に記載のモビリティサービス提供サーバであって、
前記記憶部は、
前記車載機から自発的に送信され、同時刻における前記車載機を搭載した前記車両の状態を表す前記車両データの一群をシャドウとし、該シャドウが生成された時間を表す情報をシャドウバージョンとして記憶するように構成された第１データベース（１１３）と、
前記第１データベースに蓄積された前記シャドウのそれぞれに対応して生成されるインデックスを記憶するように構成された第２データベース（１２５）と、
を備え、
前記インデックスは、前記シャドウに属する前記車両データの提供元となった前記車両を提供元車両として、前記シャドウから抽出される前記提供元車両を特定する車両識別情報と、前記提供元車両の位置情報と、前記シャドウバージョンとを含み、
前記第１制御部は、前記第１アクセス要求に示された取得条件に該当する前記インデックスを、前記第２データベースから抽出し、抽出された前記インデックスから特定される前記シャドウを前記第１データベースから取得するように構成された、
モビリティサービス提供サーバ。

【請求項9】

請求項８に記載のモビリティサービス提供サーバであって、
前記第１制御部は、前記取得条件に時刻または時間範囲を指定する時間指定情報が含まれる場合、前記シャドウバージョンが前記時間指定情報に該当する前記インデックスを、前記第２データベースから抽出するように構成された
モビリティサービス提供サーバ。

【請求項10】

請求項８に記載のモビリティサービス提供サーバであって、
前記第１制御部は、前記取得条件に地理的領域を指定するエリア指定情報が含まれる場合、前記位置情報が前記エリア指定情報で指定されたエリア内を示す前記インデックスを、前記第２データベースから抽出するように構成された
モビリティサービス提供サーバ。

【請求項11】

請求項６または請求項７に記載のモビリティサービス提供サーバであって、
前記第２制御部は、
前記インタフェース部が前記第２アクセス要求を受け付けた場合、暗号情報を生成して、前記第２アクセス要求で指定された通知先に、前記暗号情報を用いて生成された暗号文の復号に用いる鍵を送信する暗号情報生成部（Ｓ２１０～Ｓ２２０）と、
前記第２アクセス要求に従って、前記車載機に要求することで取得した前記車両データを、前記暗号情報生成部にて生成された前記暗号情報を用いて暗号化して前記インタフェース部を介して要求元に提供する暗号化部（Ｓ２５０～Ｓ２６０）と、
を備える
モビリティサービス提供サーバ。

【請求項12】

車両に搭載された車載機から提供される車両データを記憶するように構成された記憶部と、外部から第１アクセス要求および第２アクセス要求を受け付けるように構成されたインタフェース部と、を備えるモビリティサービス提供サーバにおける車両データ提供方法であって、
前記インタフェース部が前記第１アクセス要求を受け付けた場合、前記記憶部から前記車両データを取得し、前記インタフェース部を介して要求元に提供し、
前記インタフェース部が前記第２アクセス要求を受け付けた場合、前記車載機にアクセスすることで該車載機から前記車両データを含むアクセス結果を取得し、前記インタフェース部を介して要求元に提供する
車両データ提供方法。

【請求項13】

車両に搭載され前記車両から取得されるデータである車両データを収集するように構成された車載機と、前記車載機との無線通信を行うように構成されたモビリティサービス提供サーバと、を備えたモビリティサービス提供システムにおける車両データ提供方法であって、
前記車載機は、繰り返し前記車両データを前記モビリティサービス提供サーバに自発的に送信すると共に、前記モビリティサービス提供サーバからの要求に応じて前記車両データを前記モビリティサービス提供サーバに送信し、
前記モビリティサービス提供サーバは、
前記無線通信により前記車載機から取得した所定時点ごとの前記車両データを記憶部に記憶し、
外部からの第１アクセス要求および第２アクセス要求を受け付けるように構成されたインタフェース部が、前記第１アクセス要求を受け付けた場合、前記記憶部から前記車両データを取得し、前記インタフェース部を介して要求元に提供し、
前記インタフェース部が前記第２アクセス要求を受け付けた場合、前記車載機にアクセスすることで該車載機から前記車両データを含むアクセス結果を取得し、前記インタフェース部を介して要求元に提供する
車両データ提供方法。

【請求項14】

車両に搭載された車載機から提供される車両データを記憶するように構成された記憶部、および外部から第１アクセス要求および第２アクセス要求を受け付けるように構成されたインタフェース部と共にモビリティサービス提供サーバを構成するコンピュータを、
前記インタフェース部が前記第１アクセス要求を受け付けた場合、前記記憶部から前記車両データを取得し、前記インタフェース部を介して要求元に提供する第１制御部、
前記インタフェース部が前記第２アクセス要求を受け付けた場合、前記車載機にアクセスすることで該車載機から前記車両データを含むアクセス結果を取得し、前記インタフェース部を介して要求元に提供する第２制御部
として機能させるためのプログラム。

【発明の詳細な説明】

【関連出願の相互参照】

【0001】

本国際出願は、２０２１年７月２日に日本国特許庁に出願された日本国特許出願第２０２１－１１０９０５号に基づく優先権を主張するものであり、日本国特許出願第２０２１－１１０９０５号の全内容を本国際出願に参照により援用する。

【技術分野】

【0002】

本開示は、モビリティサービスを提供する技術に関する。

【背景技術】

【0003】

特許文献１には、車両から車両データを収集することによって現実世界の車両の状態を仮想空間で再現するデジタルツインシミュレーションが記載されている。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１９－１５３２９１号公報

【発明の概要】

【0005】

モビリティサービスの広がりを受け、例えば、ＧＰＳ情報等の車両データを、管理対象車両から定期的に収集して管理対象車両の位置をブラウザの地図画面上に表示させることで、サービス管理者が管理対象車両を一元管理するフリートサービスが提供されている。

【0006】

車両データを取得する際に、実車両から直接データを取得する方法とデジタルツインなどの仮想環境を用いてクラウド上のシャドウからデータを取得することで、クラウド内で完結させる場合と大きく二通りある。

【0007】

実車両から直接取得する場合、車両のローデータを扱うことができる一方、電源オフ等の車両状態によっては、取得できなかったり、扱いやすい形式に正規化されていなかったりするため、扱いが困難である。

【0008】

クラウド内で完結させる場合、車両状態の影響を受けないが、正規化された車両データしか扱えない。

【0009】

本開示は、モビリティサービス提供システムにおいて、用途に応じたデータ提供を実現する技術を提供する。

【0010】

本開示の一態様は、モビリティサービス提供システムであって、車載機と、モビリティサービス提供サーバと、を備える。車載機は、車両に搭載され車両から取得されるデータである車両データを収集するように構成される。モビリティサービス提供サーバは、車載機との無線通信を行うように構成される。車載機は、繰り返し車両データをモビリティサービス提供サーバに自発的に送信すると共に、モビリティサービス提供サーバからの要求に応じて車両データをモビリティサービス提供サーバに送信するように構成される。

【0011】

モビリティサービス提供サーバは、記憶部と、インタフェース部と、第１制御部と、第２制御部と、を備える。記憶部は、無線通信により車載機から取得した所定時点ごとの車両データを記憶するように構成される。インタフェース部は、外部からの第１アクセス要求および第２アクセス要求を受け付けるように構成される。第１制御部は、インタフェース部が第１アクセス要求を受け付けた場合、記憶部から車両データを取得し、インタフェース部を介して要求元に提供するように構成される。第２制御部は、インタフェース部が第２アクセス要求を受け付けた場合、車載機にアクセスすることで車載機から車両データを含むアクセス結果を取得し、インタフェース部を介して要求元に提供するように構成される。

【0012】

このような構成によれば、モビリティサービス提供サーバのインタフェース部を利用することで、車載機を搭載した車両から取得され、モビリティサービス提供サーバの記憶部に記憶された車両データ、および車載機を搭載した車両が有する車両データをいずれも取得することができる。

【0013】

本開示の一態様は、モビリティサービス提供サーバであって、記憶部と、インタフェース部と、第１制御部と、第２制御部と、を備える。記憶部は、車両に搭載された車載機から提供される車両データを記憶するように構成される。インタフェース部は、外部から第１アクセス要求および第２アクセス要求を受け付けるように構成される。第１制御部は、インタフェース部が第１アクセス要求を受け付けた場合、記憶部から車両データを取得し、インタフェース部を介して要求元に提供するように構成される。第２制御部は、インタフェース部が第２アクセス要求を受け付けた場合、車載機にアクセスすることで車載機から車両データを含むアクセス結果を取得し、インタフェース部を介して要求元に提供するように構成される。

【0014】

このような構成によれば、上記効果を有するモビリティサービス提供システムを構築できる。

【0015】

本開示の一態様は、車両データ提供方法である。車両データ提供方法が適用されるモビリティサービス提供サーバは、記憶部と、インタフェース部と、を備える。

【0016】

車両データ提供方法では、インタフェース部が第１アクセス要求を受け付けた場合、記憶部から車両データを取得し、インタフェース部を介して要求元に提供する。また、インタフェース部が第２アクセス要求を受け付けた場合、車載機にアクセスすることで車載機から車両データを含むアクセス結果を取得し、インタフェース部を介して要求元に提供する。

【0017】

本開示の一態様は、プログラムである。プログラムを実行するコンピュータは、記憶部、インタフェース部と共にモビリティサービス提供サーバを構成する。

【0018】

プログラムは、コンピュータを、第１制御部、第２制御部として機能させる。第１制御部は、インタフェース部が第１アクセス要求を受け付けた場合、記憶部から車両データを取得し、インタフェース部を介して要求元に提供する。第２制御部は、インタフェース部が第２アクセス要求を受け付けた場合、車載機にアクセスすることで車載機から車両データを含むアクセス結果を取得し、インタフェース部を介して要求元に提供する。

【図面の簡単な説明】

【0019】

【図1】モビリティＩｏＴシステムの構成を示すブロック図である。

【図2】エッジ装置の構成を示すブロック図である。

【図3】エッジ装置の機能的な構成を示す機能ブロック図である。

【図4】フレームの構成を示す図である。

【図5】車両データ変換テーブルの構成を示す図である。

【図6】標準化車両データの第１階層と、データフォーマットとを示す図である。

【図7】標準化車両データの構成を示す図である。

【図8】標準化車両データの作成手順を示すシーケンス図である。

【図9】データ送信タイミングを示すタイミングチャートである。

【図10】管理センターの構成を示すブロック図である。

【図11】管理センターの機能的な構成を示す機能ブロック図である。

【図12】モビリティＧＷおよびデータ管理部の機能的な構成を示す機能ブロック図である。

【図13】シャドウの構成を示す図である。

【図14】最新インデックスの構成を示す図である。

【図15】インデックスの構成を示す図である。

【図16】認可情報記憶部が有する認可オブジェクトデータベースの構成を示す図である。

【図17】認可情報記憶部が有する認可クラスデータベースの構成を示す図である。

【図18】ＡＰＩ提供部の動作を示すシーケンス図である。

【図19】第１データ取得要求の指定情報およびシャドウアクセス要求の構成を示す図である。

【図20】エリア指定の指定方法の説明図である。

【図21】インデックス取得部が実行するシャドウリスト生成処理のフローチャートである。

【図22】オープンＡＰＩである第１データ取得ＡＰＩを利用したデータ取得の手順を示すシーケンス図である。

【図23】第２データ取得要求の指定情報の構成を示す図である。

【図24】車両制御部が実行する車両データ取得処理のフローチャートである。

【図25】クローズＡＰＩである第２データ取得ＡＰＩを利用したデータ取得の手順を示すシーケンス図である。

【図26】車両に搭載されるＥＣＵの接続状態を示すブロック図である。

【図27】第２実施形態において管理センターが有するサーバ側認可データベースの構成を示す図である。

【図28】第２実施形態におけるエッジ装置の機能的な構成を示すブロック図である。

【図29】第２実施形態においてエッジ装置が有する車側認可データベースの構成を示す図である。

【図30】管理センターおよびエッジ装置の双方で認可処理を実行する２段階認可の手順を示すシーケンス図である。

【図31】エッジ装置側でのみ認可処理を実行する車側単独認可の手順を示すシーケンス図である。

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

【0020】

以下に本開示の実施形態を図面とともに説明する。

【0021】

［１．第１実施形態］
［１－１．システム概要］
本実施形態のモビリティＩｏＴシステム１は、図１に示すように、複数のエッジ装置２と、管理センター３と、サービス提供サーバ４とを備える。ＩｏＴは、Internet of Thingsの略である。

【0022】

エッジ装置２は、車両に搭載され、広域無線通信網ＮＷを介して、管理センター３とデータ通信を行う機能を有する。

【0023】

管理センター３は、モビリティＩｏＴシステム１を管理する装置である。管理センター３は、広域無線通信網ＮＷを介して、複数のエッジ装置２およびサービス提供サーバ４との間でデータ通信を行う機能を有する。

【0024】

サービス提供サーバ４は、例えば、車両の運行を管理するサービスを提供するために設置されたサーバである。なお、モビリティＩｏＴシステム１は、サービス内容が互いに異なる複数のサービス提供サーバ４を備えてもよい。サービス提供サーバ４は、オンプレミスで構成されてもよいし、クラウドで構成されてもよい。また、サービス提供サーバ４は、管理センター３と物理的に同じサーバとして構成されていてもよい。

【0025】

［１－２．エッジ装置］
［１－２－１．装置構成］
エッジ装置２は、図２に示すように、マイクロコンピュータ１１と、車両インタフェース（以下、車両Ｉ／Ｆ）１２と、通信部１３と、記憶部１４とを備える。

【0026】

マイクロコンピュータ１１は、第１コア２１と、第２コア２２と、ＲＯＭ２３と、ＲＡＭ２４と、フラッシュメモリ２５と、入出力部２６と、バス２７とを備える。

【0027】

マイクロコンピュータ１１の各種機能は、第１コア２１および第２コア２２が非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、ＲＯＭ２３が、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。

【0028】

なお、第１コア２１および第２コア２２が実行する機能の一部または全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。

【0029】

フラッシュメモリ２５は、データ書き換え可能な不揮発性メモリである。フラッシュメモリ２５は、後述する標準化車両データを格納する標準化車両データ格納部２５ａを備える。

【0030】

入出力部２６は、マイクロコンピュータ１１の外部と第１コア２１および第２コア２２との間でデータの入出力を行わせるための回路である。

【0031】

バス２７は、第１コア２１、第２コア２２、ＲＯＭ２３、ＲＡＭ２４、フラッシュメモリ２５および入出力部２６を、互いにデータ入出力可能に接続する。

【0032】

車両Ｉ／Ｆ１２は、車両に搭載された電子制御装置およびセンサ等との間で信号の入出力を行わせるための入出力回路である。

【0033】

車両Ｉ／Ｆ１２は、電源電圧入力ポート、汎用入出力ポート、ＣＡＮ通信ポートおよびイーサネット通信ポートなどを備える。ＣＡＮ通信ポートは、ＣＡＮ通信プロトコルに従ってデータの送受信を行うためのポートである。イーサネット通信ポートは、イーサネット通信プロトコルに基づいてデータの送受信を行うためのポートである。ＣＡＮは、Controller Area Networkの略である。ＣＡＮは登録商標である。イーサネットは登録商標である。

【0034】

ＣＡＮ通信ポートおよびイーサネット通信ポートには、車両に搭載された他の電子制御装置が接続される。エッジ装置２は、他の電子制御装置との間で通信フレームの送受信を行うことができる。

【0035】

通信部１３は、広域無線通信網ＮＷを介して、管理センター３とデータ通信を行う。

【0036】

記憶部１４は、各種データを記憶するための記憶装置である。

【0037】

図２６に示すように、車両には、一つのＥＣＵ２１０と、複数のＥＣＵ２２０と、複数のＥＣＵ２３０と、車外通信装置２４０と、車内通信網２５０とが搭載される。ＥＣＵは、Electronic Control Unitの略である。

【0038】

ＥＣＵ２１０は、複数のＥＣＵ２２０を統括することにより、車両全体として連携がとれた制御を実現する。

【0039】

ＥＣＵ２２０は、車両における機能によって区分けしたドメイン毎に設けられ、主として、そのドメイン内に存在する複数のＥＣＵ２３０の制御を実行する。各ＥＣＵ２２０は、それぞれ個別に設けられた下層ネットワーク（例えば、ＣＡＮ）を介して配下のＥＣＵ２３０と接続される。ＥＣＵ２２０は、配下のＥＣＵ２３０に対するアクセス権限などを一元的に管理し利用者の認証等を行う機能を有する。ドメインは、例えば、パワートレーン、ボデー、シャシおよびコックピット等である。

【0040】

パワートレーンのドメインに属するＥＣＵ２２０に接続されるＥＣＵ２３０は、例えば、エンジンを制御するＥＣＵ２３０、モータを制御するＥＣＵ２３０、および、バッテリを制御するＥＣＵ２３０等を含む。

【0041】

ボデーのドメインに属するＥＣＵ２２０に接続されるＥＣＵ２３０は、例えば、エアコンを制御するＥＣＵ２３０、および、ドアを制御するＥＣＵ２３０等を含む。

【0042】

シャシドメインに属するＥＣＵ２２０に接続されるＥＣＵ２３０は、例えば、ブレーキを制御するＥＣＵ２３０、および、ステアリングを制御するＥＣＵ２３０等を含む。

【0043】

コックピットのドメインに属するＥＣＵ２２０に接続されるＥＣＵ２３０は、例えば、メータおよびナビゲーションの表示を制御するＥＣＵ２３０、および、車両の乗員によって操作される入力装置を制御するＥＣＵ２３０等を含む。

【0044】

車外通信装置２４０は、広域無線通信網ＮＷを介して、車両外の通信装置（例えば、クラウドサーバ）との間でデータ通信を行う。

【0045】

車内通信網２５０は、ＣＡＮ ＦＤとイーサネットとを備える。ＣＡＮ ＦＤは、CAN with Flexible Data Rateの略である。ＣＡＮ ＦＤは、ＥＣＵ２１０と各ＥＣＵ２２０および車外通信装置２４０とをバス接続する。イーサネットは、ＥＣＵ２１０と各ＥＣＵ２２０および車外通信装置２４０との間を個別に接続する。

【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】

「ポジション」は、データフィールド内におけるＣＡＮデータの位置を示す情報である。「ＤＬＣ」は、データ長を示す情報である。ＤＬＣは、Data Length Codeの略である。

【0077】

「ユニークラベル」は、制御ラベルを示す情報である。例えば、「ＥＴＨＡ」は吸気温を示し、「ＮＥ１」はエンジン回転数を示す。「解像度」は、１ビット当たりの数値を示す情報である。

【0078】

したがって、「ＣＡＮＩＤ」、「ＥＣＵ」、「ポジション」、「ＤＬＣ」および「ユニークラベル」によって、標準フォーマットデータから、「ユニークラベル」に対応するデータが抽出される。さらに抽出データは、「解像度」および「オフセット」により、「単位」で表される値に換算された、車両データに変換される。

【0079】

また、車両データ変換テーブル２３ａの意味化情報は、例えば、図５に示すように、制御ラベルが「ＳＳＡ」である「操舵移動角度」から、制御ラベルが「ＳＳＡＺ」である「操舵ゼロ点」を減算することにより「操舵角」に変換する変換式を含む。この変換式により、「操舵移動角度」を表す車両データと、「操舵ゼロ点」を表す車両データとから、「基準位置からの操舵量」という意味を有する「操舵角」を表す車両データに変換される。

【0080】

第２コア２２は、変換された車両データを階層化してフラッシュメモリ２５に記憶する。具体的には、第２コア２２は、変換された車両データを、フラッシュメモリ２５に設けられた標準化車両データ格納部２５ａの対応領域に格納する。

【0081】

標準化車両データ格納部２５ａは、車両データを階層化して構成される標準化車両データを格納する。

【0082】

標準化車両データは、車両毎（すなわち、エッジ装置２毎）に作成され、複数の階層構造を有している。標準化車両データでは、複数の階層のそれぞれに対して、１または複数の項目が設定されている。例えば、図６に示すように、標準化車両データは、最上位の第１階層に設定される項目として、「属性情報」、「パワトレ」、「エネルギー」、「ＡＤＡＳ／ＡＤ」、「ボデー」、「マルチメディア」および「その他」を備える。ＡＤＡＳは、Advanced Driver Assistance Systemの略である。ＡＤは、Autonomous Drivingの略である。「属性情報」、「パワトレ」および「エネルギー」等はカテゴリに相当する。

【0083】

また各車両データは、項目として、「ユニークラベル」、「ＥＣＵ」、「データ型」、「データサイズ」、「データ値」および「データ単位」を備える。「ユニークラベル」および「ＥＣＵ」は、前述の通りである。「データ型」、「データサイズ」および「データ単位」は、「データ値」で示される数値に関する型、サイズ、単位を示す。

【0084】

図７に示すように、標準化車両データは、第１階層に加えて、少なくとも第２階層および第３階層を備える。第２階層は第１階層の直下の階層であり、第３階層は第２階層の直下の階層である。標準化車両データは、前述した正規化および意味化の処理において設定された項目である。標準化車両データは、階層化されたデータ構造を有する。

【0085】

例えば、第１階層の項目である「属性情報」は、第２階層の項目として、「車両識別情報」、「車両属性」、「トランスミッション構成」および「ファームウェアバージョン」等を備える。「車両識別情報」は、車両を一意に識別できる情報を示すカテゴリ名である。「車両属性」は、車両の種類を示すカテゴリ名である。「トランスミッション構成」は、トランスミッションに関する情報を示すカテゴリ名である。「ファームウェアバージョン」は、車両のファームウェアに関する情報を示すカテゴリ名である。

【0086】

また、第１階層の項目である「パワトレ」は、パワートレーンに関する情報を示すカテゴリ名である。「パワトレ」は、第２階層の項目として、「アクセルペダル」、「エンジン」および「エンジンオイル」等を備える。「アクセルペダル」には、アクセルペダルの状態、開度など１以上の車両データが含まれる。「エンジン」には、エンジンの状態、回転数など１以上の個々の車両データが含まれる。第２階層の項目もカテゴリに相当する。他の第１階層の項目についても同様である。

【0087】

また、第１階層の項目である「エネルギー」は、エネルギーに関する情報を示すカテゴリ名である。「エネルギー」は、第２階層の項目として、「バッテリ状態」、「バッテリ構成」および「燃料」等を備える。

【0088】

また、第２階層の項目である「車両識別情報」は、第３階層の項目として、「車両識別番号」、「車体番号」および「ナンバープレート」を備える。第３階層の項目は、１以上の個々の車両データであり、アイテムとも言う。つまり、標準化車両データの階層構造において、最下層の項目をアイテム、最下層以外の項目（すなわち、下位階層を有する項目）をカテゴリという。

【0089】

また、第２階層の項目である「車両属性」は、第３階層の項目として、「ブランド名」、「モデル」および「製造年」等を備える。

【0090】

また、第２階層の項目である「トランスミッション構成」は、第３階層の項目として、「トランスミッション種別」を備える。

【0091】

例えば、第２コア２２は、変換された車両データの制御ラベルが「車両識別情報」である場合には、標準化車両データ格納部２５ａにおいて第１階層が「属性情報」であり且つ第２階層が「車両識別情報」であり且つ第３階層が「車両識別番号」である格納領域に、変換された車両データを格納する。

【0092】

「その他」には、例えば、車両に搭載されたＧＰＳ装置から車両Ｉ／Ｆ１２を介して取得される位置情報、すなわち、緯度、経度、高度が含まれてもよい。

【0093】

次に、図８に示すシーケンス図を用いて、エッジ装置２が標準化車両データを作成する手順を説明する。

【0094】

矢印Ｌ１１で示すように、車両Ｉ／Ｆ１２が車両から車両データを取得すると、車両Ｉ／Ｆ１２は、矢印Ｌ１２で示すように、通信プロトコル判定を行う。さらに車両Ｉ／Ｆ１２は、矢印Ｌ１３で示すように不要な車両データをフィルタリングし、矢印Ｌ１４で示すように、必要な車両データを第１ユニット１０１へ出力する。

【0095】

第１ユニット１０１は、車両Ｉ／Ｆ１２から車両データを取得すると、矢印Ｌ１５で示すように、車両データを標準フォーマットに変換し、矢印Ｌ１６で示すように、標準フォーマットに変換された車両データをフラッシュメモリ２５に記憶する。

【0096】

第２ユニット１０２は、矢印Ｌ１７で示すように、標準フォーマットに変換された車両データをフラッシュメモリ２５から取得すると、矢印Ｌ１８で示すように、取得した車両データを変換する。さらに第２ユニット１０２は、矢印Ｌ１９で示すように、変換したデータを構造化して標準化車両データを作成する。

【0097】

次に、エッジ装置２が実行するデータ送信処理の手順を説明する。

【0098】

標準化車両データに属する各車両データには、管理センター３にデータを送信するタイミングを表すタイミング情報が、それぞれ設定される。タイミング情報は、データが変化する度合いやデータの重要度等に応じて、頻繁に変化するデータほど、重要度が高いデータほど周期が短くなるように設定される。タイミング情報は、例えば、５００ｍｓ周期、２ｓ周期、４ｓ周期、３０ｓ周期、３００ｓ周期、１２時間周期等である。

【0099】

第２コア２２は、送信単位時間（例えば２５０ｍｓ）周期で送信処理を実行する。

【0100】

図９に示すように、５００ｍｓ周期で送信する車両データである第１頻度データを、２グループに分けて、送信タイミング毎に交互に送信する。同様に、１ｓ周期で送信する車両データである第２頻度データを、２グループまたは４グループに分けて各グループのデータを異なる送信タイミング送信する。つまり、各車両データを、あらかじめ設定された送信スケジュールに従って送信することにより、同じ送信タイミングに多くの車両データの送信が集中することを抑制する。また、各車両データを、その特性に応じた頻度で送信することにより、効率の良い送信を実現する。

【0101】

［１－３．管理センター］
［１－３―１．装置構成］
管理センター３は、図１０に示すように、制御部３１と、通信部３２と、記憶部３３とを備える。

【0102】

制御部３１は、ＣＰＵ４１、ＲＯＭ４２およびＲＡＭ４３等を備えたマイクロコンピュータを中心に構成された電子制御装置である。マイクロコンピュータの各種機能は、ＣＰＵ４１が非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、ＲＯＭ４２が、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。なお、ＣＰＵ４１が実行する機能の一部または全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。また、制御部３１を構成するマイクロコンピュータの数は１つでも複数でもよい。

【0103】

通信部３２は、広域無線通信網ＮＷを介して、複数のエッジ装置２およびサービス提供サーバ４との間でデータ通信を行う。なお、エッジ装置２との通信には、パブリッシュ／サブスクライブ型のシンプルで軽量なプロトコルであるＭＱＴＴが用いられる。ＭＱＴＴは、Message Queue Telemetry Transportの略である。

【0104】

記憶部３３は、各種データを記憶するための記憶装置である。

【0105】

［１－３－２．機能構成］
管理センター３は、ＲＯＭ４２に格納されたプログラムをＣＰＵ４１が実行することにより実現される機能ブロックとして、図１１に示すように、車両側ユニット１１０と、サービス側ユニット１２０とを備える。車両へのアクセスに近い側の機能ブロックが車両側ユニット１１０であり、サービス提供サーバ４からのアクセスに近い側の機能ブロックがサービス側ユニット１２０である。これら２つの機能ブロックは、疎結合に構成される。

【0106】

管理センター３を構成するこれらの要素を実現する手法はソフトウェアに限るものではなく、その一部または全部の要素について、一つあるいは複数のハードウェアを用いて実現してもよい。例えば、上記機能がハードウェアである電子回路によって実現される場合、その電子回路は多数の論理回路を含むデジタル回路、またはアナログ回路、あるいはこれらの組合せによって実現してもよい。

【0107】

車両側ユニット１１０は、車両へのアクセスおよび車両から受信したデータを管理する機能を有する。車両側ユニット１１０は、モビリティゲートウェイ（以下、モビリティＧＷ）１１１を備える。モビリティＧＷ１１１は、車両へのアクセス要求を車両へ中継する機能の他、車両から受信したデータを管理する機能を有する。

【0108】

そしてモビリティＧＷ１１１は、シャドウ管理部１１２と、車両制御部１３０とを備える。シャドウ管理部１１２は、エッジ装置２を搭載する車両毎に設けられた車両データを収容するシャドウ１１４を管理する機能を備える。シャドウ１１４は、ある車両の車両データ群を示す。シャドウ１１４は、エッジ装置２から送信される標準化車両データに基づいて生成される。車両制御部１３０は、サービス提供サーバ４からの指示に従って、エッジ装置２を介して、該エッジ装置２を搭載している車両を制御する機能を備える。

【0109】

サービス側ユニット１２０は、サービス提供サーバ４からの要求を受け付けるとともに、車両データの提供を行う。サービス側ユニット１２０は、データ管理部１２１と、ＡＰＩ提供部１２２とを備える。ＡＰＩは、Application Programming Interfaceの略である。

【0110】

データ管理部１２１は、車両の接続状態の変化に依存しない車両アクセスを提供するための仮想空間であるデジタルツイン１２３を管理する機能を備える。データ管理部１２１は、車両側ユニット１１０で管理する車両データへのアクセスに必要なデータを管理する。

【0111】

ＡＰＩ提供部１２２は、サービス提供サーバ４がモビリティＧＷ１１１およびデータ管理部１２１へアクセスするための標準インタフェースである。ＡＰＩ提供部１２２は、サービス提供サーバ４に対し、車両へのアクセスや車両データを取得するためのＡＰＩを提供する。

【0112】

［１－３－２－１．データ蓄積機能］
図１２に示すように、シャドウ管理部１１２は、エッジ装置２から取得した車両データを蓄積する機能を実現する構成として、シャドウ作成部１１５と、シャドウ記憶部１１３と、最新インデックス作成部１１６と、最新インデックス記憶部１１７とを備える。

【0113】

シャドウ作成部１１５は、エッジ装置２から構造化された標準化車両データを受信する。シャドウ作成部１１５は、エッジ装置２から車両データが送信される毎に、送信された車両データを、構造化された標準化車両データの該当領域に上書きすることにより、標準化車両データを更新する。シャドウ作成部１１５は、構造化された標準化車両データの一部を受信してもよい。シャドウ作成部１１５は、更新された標準化車両データを用いて、新たなシャドウ１１４を作成する。シャドウ作成部１１５は、作成したシャドウ１１４をシャドウ記憶部１１３に蓄積する。シャドウ作成部１１５は、更新された標準化車両データを用いて新たなシャドウ１１４を作成する際、通し番号など任意の情報を付与してシャドウ記憶部１１３に記憶してもよい。シャドウ記憶部１１３には、車両毎に、時系列的に作成された複数のシャドウ１１４が記憶される。つまり、シャドウ１１４は、エッジ装置２を搭載した車両のある時刻における状態をコピーしたものとみなすことができる。

【0114】

一つのシャドウ１１４は、ある車両の所定時刻の車両データ群であり、図１３に示す標準化されたデータ構造で表される車両データ群を含む。なお、通信部３２を介してシャドウ作成部１１５が構造化された標準化車両データを受信するタイミングは、車両によって異なる。新たなシャドウ１１４の作成は、全ての車両に対して同じタイミングで行ってもよい。シャドウ作成部１１５は、新たなシャドウ１１４の作成を、全ての車両に対して一定周期で行ってもよい。シャドウ記憶部１１３には、車両毎に、過去のシャドウ１１４が蓄積されている。一定期間経過したシャドウ１１４は順次削除されてもよい。

【0115】

図１３に示すように、シャドウ１１４は、車両データ格納部１１４ａと、デバイスデータ格納部１１４ｂとを備える。

【0116】

車両データ格納部１１４ａは、エッジ装置２を搭載している車両に関するデータとして、「ｏｂｊｅｃｔ－ｉｄ」、「Ｓｈａｄｏｗ＿ｖｅｒｓｉｏｎ」および「ｍｏｂｉｌｉｔｙ－ｄａｔａ」を格納する。

【0117】

「ｏｂｊｅｃｔ－ｉｄ」は、エッジ装置２を搭載している車両を識別する文字列であり、パーティションキーとして機能する。

【0118】

「Ｓｈａｄｏｗ＿ｖｅｒｓｉｏｎ」は、シャドウ１１４のバージョンを示す数値であり、シャドウ１１４が作成される毎に、作成された時刻を示すタイムスタンプが設定される。

【0119】

「ｍｏｂｉｌｉｔｙ－ｄａｔａ」は、上記の標準化車両データである。

【0120】

デバイスデータ格納部１１４ｂは、エッジ装置２に搭載されているハードウェア、ソフトウェア、および状態に関するデータとして、「ｏｂｊｅｃｔ－ｉｄ」、「ｕｐｄａｔｅ＿ｔｉｍｅ」、「ｖｅｒｓｉｏｎ」、「ｐｏｗｅｒ＿ｓｔａｔｕｓ」、「ｐｏｗｅｒ＿ｓｔａｔｕｓ＿ｔｉｍｅｓｔａｍｐ」、「ｎｏｔｉｆｙ＿ｒｅａｓｏｎ」を格納する。「ｖｅｒｓｉｏｎ」、「ｐｏｗｅｒ＿ｓｔａｔｕｓ」等のデータは、値に変化が生じた際に、上記標準化車両データとは別で、エッジ装置２から送信される。

【0121】

「ｏｂｊｅｃｔ－ｉｄ」は、車両データ格納部１１４ａにて説明したものと同じである。

【0122】

「ｕｐｄａｔｅ＿ｔｉｍｅ」は、更新時刻を示す数値である。

【0123】

「ｖｅｒｓｉｏｎ」は、エッジ装置２のハードウェアおよびソフトウェアのバージョンを示す文字列である。

【0124】

「ｐｏｗｅｒ＿ｓｔａｔｕｓ」は、エッジ装置２のシステム状態を示す文字列である。具体的には、全ての機能を利用可能なウェイクアップ状態、一部の機能を停止した低消費電力のスリープ状態がある。

【0125】

「ｐｏｗｅｒ＿ｓｔａｔｕｓ＿ｔｉｍｅｓｔａｍｐ」は、システム状態の通知時刻を示す数値である。

【0126】

「ｎｏｔｉｆｙ＿ｒｅａｓｏｎ」は、通知理由を示す文字列である。

【0127】

このようにシャドウ１１４は、車両データ群に加え、エッジ装置２の情報を含む。なお、デバイスデータ格納部１１４ｂは、エッジ装置２の情報をシャドウ１１４に含めず別でＲＯＭ４２等に記憶してもよい。デバイスデータ格納部１１４ｂは、エッジ装置２の情報を、タイムスタンプ毎に過去のデータを蓄積するのではなく、最新のデータのみをＲＯＭ４２等に記憶してもよい。

【0128】

上記デバイスデータ格納部１１４ｂに格納される「ｖｅｒｓｉｏｎ」「ｐｏｗｅｒ＿ｓｔａｔｕｓ」「ｎｏｔｉｆｙ＿ｒｅａｓｏｎ」等は、上記の標準化車両データとは別で、変化が生じたときにエッジ装置２から通知される。

【0129】

最新インデックス作成部１１６は、シャドウ記憶部１１３から車両毎に最新のシャドウ１１４を取得し、取得したシャドウ１１４を用いて最新インデックス１１８を作成する。そして最新インデックス作成部１１６は、作成した最新インデックス１１８を最新インデックス記憶部１１７に記憶する。最新インデックス記憶部１１７には、車両毎（すなわち、ｏｂｊｅｃｔ－ｉｄ毎）に１つの最新インデックス１１８が記憶される。

【0130】

図１４に示すように、最新インデックス１１８は、「ｇａｔｅｗａｙ－ｉｄ」、「ｏｂｊｅｃｔ－ｉｄ」、「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」、「ｖｉｎ」、「ｌｏｃａｔｉｏｎ－ｌｏｎ」、「ｌｏｃａｔｉｏｎ－ｌａｔ」および「ｌｏｃａｔｉｏｎ－ａｌｔ」を格納する。

【0131】

「ｏｂｊｅｃｔ－ｉｄ」、「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」は、シャドウ１１４にて説明したものと同様である。

【0132】

「ｇａｔｅｗａｙ－ｉｄ」は、モビリティＧＷ１１１を識別する情報である。管理センター３が、例えば、国別に設けられる等して複数存在する場合に、これらを識別する情報である。

【0133】

「ｖｉｎ」は、エッジ装置２を搭載している車両固有の登録番号である。

【0134】

「ｌｏｃａｔｉｏｎ－ｌｏｎ」は、エッジ装置２を搭載している車両が存在する緯度を示す情報である。

【0135】

「ｌｏｃａｔｉｏｎ－ｌａｔ」は、エッジ装置２を搭載している車両が存在する経度を示す情報である。

【0136】

「ｌｏｃａｔｉｏｎ－ａｌｔ」は、エッジ装置２を搭載している車両が存在する高度を示す情報である。

【0137】

図１２に示すように、データ管理部１２１は、シャドウ管理部１１２から取得された最新インデックス１１８をインデックス１２６として蓄積する機能を実現する構成として、インデックス作成部１２４と、インデックス記憶部１２５とを備える。

【0138】

インデックス作成部１２４は、最新インデックス記憶部１１７から予め設定された取得スケジュールに従って最新インデックス１１８を取得し、取得した最新インデックス１１８を用いてデジタルツイン１２３用のインデックス１２６を作成する。そしてインデックス作成部１２４は、作成したインデックス１２６をインデックス記憶部１２５に順次記憶する。インデックス記憶部１２５には、車両毎に、時系列的に作成された複数のインデックス１２６が記憶される。つまり、インデックス記憶部１２５に記憶されたインデックス１２６のそれぞれが、仮想的な時空間であるデジタルツイン１２３上に存在する車両を表す。

【0139】

図１５に示すように、インデックス１２６は、「ｔｉｍｅｓｔａｍｐ」、「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」、「ｇａｔｅｗａｙ－ｉｄ」、「ｏｂｊｅｃｔ－ｉｄ」、「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」、「ｖｉｎ」、「ｌｏｃａｔｉｏｎ」および「ａｌｔ」を格納する。

【0140】

「ｔｉｍｅｓｔａｍｐ」は、インデックス１２６が作成された時刻をミリ秒単位で示すタイムスタンプである。

【0141】

「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」は、データ作成元のスケジューラが定期であるかイベントであるかを示す。定期である場合には「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」は「Ｒｅｐｅａｔ」に設定され、イベントである場合には「ｓｃｈｅｄｕｌｅ－ｔｙｐｅ」は「Ｅｖｅｎｔ」に設定される。

【0142】

「ｇａｔｅｗａｙ－ｉｄ」、「ｏｂｊｅｃｔ－ｉｄ」「ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ」、「ｖｉｎ」は、最新インデックス１１８から引き継いだ情報である。

【0143】

「ｌｏｃａｔｉｏｎ」は、最新インデックス１１８の「ｌｏｃａｔｉｏｎ－ｌｏｎ」、「ｌｏｃａｔｉｏｎ－ｌａｔ」から引き継いだ情報であり、「ａｌｔ」は、最新インデックス１１８の「ｌｏｃａｔｉｏｎ－ａｌｔ」から引き継いだ情報である。

【0144】

ここで、シャドウ管理部１１２は、最新インデックス作成部１１６および最新インデックス記憶部１１７を省略した構成としてもよい。この場合、インデックス作成部１２４は、シャドウ記憶部１１３に記憶されているシャドウ１１４を取得してインデックス１２６を生成してもよい。望ましくは、インデックス作成部１２４は、最新インデックス記憶部１１７から取得した最新インデックス１１８を用いてインデックス１２６を生成する。これは、モビリティＧＷ１１１とデータ管理部１２１とを疎結合とする構成の一つである。

【0145】

さらに、データ管理部１２１は、インデックス作成部１２４およびインデックス記憶部１２５を省略した構成としてもよい。この場合、例えば、インデックス取得部１２７は、ＡＰＩ提供部１２２を介して指定されたｏｂｊｅｃｔ－ｉｄとタイムスタンプ（すなわち、ｓｈａｄｏｗ－ｖｅｒｓｉｏｎ）を用いて、データ取得部１１９に指定された車両データの取得を要求してもよい。

【0146】

［１－３－２－２．サービス提供機能］
図５および図１２に示すように、サービス側ユニット１２０は、ＡＰＩ提供部１２２を備える。ＡＰＩ提供部１２２は、管理センター３が有する機能を、サービス提供サーバ４等の外部のサービス提供者に利用させるために用意されたインタフェースである。以下では、ＡＰＩ提供部１２２等を利用するモビリティＩｏＴシステム１のユーザをサービスユーザという。サービスユーザは、例えば車両トランクへの宅配を行うサービス事業者である。

【0147】

ＡＰＩ提供部１２２は、図１２に示すように、認証情報記憶部１４１と、認可情報記憶部１４２と、車両識別情報記憶部１４３と、認証処理部１４４とを備える。また、サービスユーザに提供するＡＰＩの種類として、ログインＡＰＩ１４５と、第１データ取得ＡＰＩ１４６と、第２データ取得ＡＰＩ１４７と、車両制御ＡＰＩ１４８とを備える。

【0148】

ログインＡＰＩ１４５は、サービスユーザの認証を行うために提供されるＡＰＩである。第１データ取得ＡＰＩ１４６および第２データ取得ＡＰＩ１４７は、いずれも、サービスユーザがデータを取得するために提供されるＡＰＩである。車両制御ＡＰＩ１４８は、サービスユーザが車両に対する制御を行うために提供されるＡＰＩである。

【0149】

認証情報記憶部１４１は、「サービスユーザＩＤ」に対応づけて「認証情報」を記憶する。「サービスユーザＩＤ」は、サービスユーザを一意に識別する識別情報である。「認証情報」は、サービスユーザ本人であることを認証するための情報であり、例えば、あらかじめ設定されたパスワードである。

【0150】

認可情報記憶部１４２は、認可オブジェクトデータベース（以下、認可オブジェクトＤＢ）と、認可クラスＤＢとを備える。

【0151】

図１６に示すように、認可オブジェクトＤＢは、「サービスユーザＩＤ」に対応づけて、「認可クラス」「認可オブジェクト」「有効期限」を記憶する。「認可クラス」は、サービスユーザに対して認可された権限の範囲を表す情報である。「認可オブジェクト」は、サービスユーザによるアクセスが許可された車両の「ｏｂｊｅｃｔ－ｉｄ」のリストである。「有効期限」は、登録内容が有効な期間の開始年月日および終了年月日である。つまり、認可オブジェクトＤＢは、モビリティＩｏＴシステム１に対する各サービスユーザの権限についての登録内容を示すデータベースである。認可オブジェクトＤＢには、「認可オブジェクト」が異なっているか、または、「有効期限」が重複していなければ、１のサービスユーザについて複数の登録がされてもよい。

【0152】

図１７に示すように、認可クラスＤＢは、「認可クラス」に対応づけて「ＡＰＩ情報」「取得権限」「有効期限」を記憶する。認可クラスＤＢは、「認可クラス」の具体的な内容を表すデータベースである。

【0153】

「認可クラス」は、認可を与えるデータ範囲を表す複数のクラスを識別する情報であり、例えば、認可クラスの低い順に「ｏｐｅｎ」「Ｃｌａｓｓ０」「ｃｌａｓｓ１」「ｃｌａｓｓ２」「ｃｌａｓｓ３」「Ｆｕｌｌ」の６クラスが存在してもよい。「認可クラス」は、データに対し読み出しや書き込みができるデータ範囲のクラス分けに限定されず、動作を制御できる動作制御範囲のクラス分け等であってもよい。

【0154】

「ＡＰＩ情報」は、対応する「認可クラス」のサービスユーザに提供するＡＰＩのｕｒｌである。ｕｒｌは、Uniform Resource Locatorの略である。

【0155】

「取得権限」は、対応する「認可クラス」のサービスユーザに対して許可された取得可能なデータのリストである。認可クラスが「ｏｐｅｎ」である場合、「取得権限」に含まれるデータは、誰もが自由にアクセスできる情報に限られ、例えば、車両の位置情報、高度情報が含まれてもよい。認可クラスが「Ｆｕｌｌ」である場合、「取得権限」に含まれるデータは、管理センター３が管理する全ての情報、およびエッジ装置２を搭載する車両から取得可能な全ての情報が含まれる。認可クラスが「Ｃｌａｓｓ０」～「Ｃｌａｓｓ３」の場合、クラスが０～３に上がるに従って、アクセス可能なデータの数が増加するように設定されてもよいし、クラス毎に、アクセス可能なデータの種類が異なるように設定されてもよい。

【0156】

ここでは取得権限として、取得可能なデータが列挙されているが、取得可能なデータの代わりに、または、取得可能なデータに加えて、利用可能な機能、例えば、エッジ装置２を搭載した車両に対する制御の種類等が列挙されてもよい。取得可能なデータとしては、例えば図７に示すデータ項目の中から列挙される。

【0157】

「有効期限」が重複していなければ、１の「認可クラス」に複数の設定が存在してもよい。

【0158】

車両識別情報記憶部１４３は、エッジ装置２が搭載された車両に一意に割り当てられた「ｏｂｊｅｃｔ－ｉｄ」と、その車両の「ｖｉｎ」とを対応づけたテーブル情報を記憶する。

【0159】

認証処理部１４４は、ログインＡＰＩ１４５を介して認証要求が行われた場合に、認証処理を実行し、第１データ取得ＡＰＩ１４６、第２データ取得ＡＰＩ１４７、車両制御ＡＰＩ１４８を介してアクセス要求が行われた場合に、認可処理を実行する。認証処理および認可処理いついては後述する。

【0160】

ＡＰＩ提供部１２２を介したアクセス要求に関わる手順を、図１８を用いて説明する。

【0161】

ログインＡＰＩ１４５は、サービスユーザがモビリティＩｏＴシステム１にログインする際に用いられる。

【0162】

矢印Ｌ２１で示すように、ログインＡＰＩ１４５がサービスユーザからの認証要求を受け付けると、認証処理部１４４が認証処理を実行する。認証処理では、ログインＡＰＩ１４５により入力された「サービスユーザＩＤ」「認証情報」を、認証情報記憶部１４１の登録内容と照合する。照合の結果、情報が一致した場合、すなわち、認証に成功した場合は、矢印Ｌ２２で示すように、認証結果として、モビリティＩｏＴシステム１へのアクセスを許可する証明書となるデータであるトークンを返す。

【0163】

第１データ取得ＡＰＩ１４６は、機密性の低い情報等へのアクセスに用いるオープンＡＰＩの一つである。第２データ取得ＡＰＩ１４７は、機密性の高い情報等へのアクセス際に用いるクローズＡＰＩの一つである。車両制御ＡＰＩ１４８は、エッジ装置２が搭載された車両を制御する際に用いるクローズＡＰＩの一つである。

【0164】

クラウドからのデータの取得に関し、機密性が高いデータの取得をクローズＡＰＩで提供し、機密性が低いデータの取得をオープンＡＰＩで提供してもよい。車両からのデータ取得に関し、機密性が高いデータの取得をクローズＡＰＩで提供し、機密性が低いデータの取得をオープンＡＰＩで提供してもよい。車両制御に関し、車両の走行に関わる制御をクローズＡＰＩで提供し、車両の走行に関わらない制御をオープンＡＰＩで提供してもよい。

【0165】

ここでは、図１１中の矢印Ｌ１に示すように、管理センター３に蓄積された車両データ（すなわち、インデックス１２６およびシャドウ１１４）へのアクセスには、オープンＡＰＩである第１データ取得ＡＰＩ１４６が用いられる。また、図１１中の矢印Ｌ２に示すように、エッジ装置２が搭載された車両へのアクセスには、クローズＡＰＩである第２データ取得ＡＰＩ１４７および車両制御ＡＰＩ１４８が用いられる。但し、管理センター３に蓄積された車両データの一部（すなわち、機密性の高い情報等）に対してクローズＡＰＩを用いてもよい。

【0166】

以下では、第１データ取得ＡＰＩ１４６、および第２データ取得ＡＰＩ１４７、車両制御ＡＰＩ１４８を、総称してアクセスＡＰＩという。図１８中の矢印Ｌ２３で示すように、アクセスＡＰＩは、サービスユーザからのアクセス要求を受け付けると、認証処理部１４４が認可処理を実行する。

【0167】

認可処理が実行されると、認証処理部１４４は、アクセス要求に付加された「トークン」から「サービスユーザＩＤ」を特定する。次に、認証処理部１４４は、認可情報記憶部１４２の認可オブジェクトＤＢを検索することで、特定された「サービスユーザＩＤ」の「認可クラス」「認可オブジェクト」を特定する。更に、認証処理部１４４は、アクセス要求に示されたアクセス対象の車両が、「認可オブジェクト」に示されているか否か、すなわち、サービスユーザが指定した車両へのアクセスが許可されているか否かを判定する。また、認証処理部１４４は、認可クラスＤＢを参照して、アクセス要求に用いられたアクセスＡＰＩが、指定された「認可クラス」の「ＡＰＩ情報」に含まれるか否か、すなわち、サービスユーザが指定したＡＰＩの利用が許可されているか否かを判定する。また、認証処理部１４４は、認可クラスＤＢを参照して、アクセス要求に示された指示内容が、特定された「認可クラス」の「取得権限」の範囲内であるか否か、すなわち、サービスユーザが要求する指示内容に対しアクセスが許可されているか否かを判定する。そして、アクセス対象の車両が「認可オブジェクト」に示されない場合、アクセスＡＰＩが「ＡＰＩ情報」に含まれない場合、または指示内容が「取得権限」の範囲外である場合、認証処理部１４４は不認可と判定する。不認可と判定した場合、認証処理部１４４は、矢印Ｌ２４で示すように、アクセスＡＰＩを介して、サービスユーザにアクセス拒否を通知する。アクセス対象の車両が「認可オブジェクト」に示され、かつ、アクセスＡＰＩが「ＡＰＩ情報」に含まれ、かつ、指示内容が「取得権限」の範囲内にある場合、認証処理部１４４は認可と判定する。認可と判定した場合、認証処理部１４４は、矢印Ｌ２５で示すように、アクセス要求を、アクセス対象へ転送する。具体的には、アクセスＡＰＩが、第１データ取得ＡＰＩ１４６のようなオープンＡＰＩの場合、アクセス要求を、アクセス対象であるシャドウ１１４へ転送する。アクセスＡＰＩが、第２データ取得ＡＰＩ１４７および車両制御ＡＰＩ１４８のようなクローズＡＰＩの場合、アクセス要求を、アクセス対象である実車両へ転送する。その後、矢印Ｌ２６で示すように、アクセス対象から返送されるアクセス結果は、アクセスＡＰＩを介して、サービスユーザに提供される。

【0168】

なお、アクセスＡＰＩでは、車両を特定する情報として、「ｏｂｊｅｃｔ－ｉｄ」および「ｖｉｎ」のいずれを用いてもよく、「ｖｉｎ」が用いられている場合は、車両識別情報記憶部１４３を参照し、「ｖｉｎ」を「ｏｂｊｅｃｔ－ｉｄ」に変換してもよい。

【0169】

図１２に示すように、管理センター３は、アクセスＡＰＩを介したアクセス要求を実現するための構成として、インデックス取得部１２７と、データ取得部１１９と、車両制御部１３０とを備える。インデックス取得部１２７は、インデックス記憶部１２５に蓄積されたインデックス１２６からデータを取得する機能を実現する。データ取得部１１９は、シャドウ記憶部１１３に蓄積されたシャドウ１１４からデータを取得する機能を実現する。車両制御部１３０は、エッジ装置２との通信機能を利用して、エッジ装置２を搭載する車両にアクセスする機能を実現する。

【0170】

つまり、オープンＡＰＩである第１データ取得ＡＰＩ１４６を介して入力されるアクセス要求（以下、第１データ取得要求）は、インデックス取得部１２７にて処理される。また、クローズＡＰＩである第２データ取得ＡＰＩ１４７を介して入力されるアクセス要求（以下、第２データ取得要求）、および車両制御ＡＰＩ１４８を介して入力されるアクセス要求（以下、車両制御要求）は、車両制御部１３０にて処理される。

【0171】

［１－３－３．第１データ取得処理］
第１データ取得ＡＰＩ１４６が第１データ取得要求を受け付けた場合に実行される一連の処理である第１データ取得処理について説明する。具体的には、図１８において認証処理および認可処理が行われた後、アクセスＡＰＩからアクセス対象へアクセス要求が送信されたときの第１データ取得処理である。第１データ取得処理は、第１データ取得ＡＰＩ１４６を用いて、管理センター３内で管理されるシャドウ１１４から指定したデータを取得する処理である。

【0172】

まず、第１データ取得要求に含まれる指定情報について説明する。指定情報は、サービスユーザによって設定される。

【0173】

図１９に示すように、指定情報は、車両指定情報と、時間指定情報と、データ指定情報とを含む。

【0174】

車両指定情報は、データ取得の対象となる車両（以下、対象車両）を指定するための情報である。車両指定情報は、対象車両の車両ＩＤ（すなわち、ｏｂｊｅｃｔ－ｉｄまたはｖｉｎ）をリスト形式で列挙する方法と、対象車両が存在する地理的領域を指定（以下、エリア指定）する方法とがある。他にも、車種や型式等により、対象車両を指定してもよい。

【0175】

エリア指定する方法は、図２０に示すように、矩形指定、および多角形指定、近傍指定の３種類が存在する。矩形指定は、矩形の地理的領域を、左上隅座標、右下隅座標によって指定する方法である。座標は、緯度、経度を用いて表される。多角形指定は、多角形の地理的領域を、多角形が有するｎ個の頂点の各座標によって指定する方法である。近傍指定は、円形の地理的領域を、中心座標と中心座標からの距離によって指定する方法である。

【0176】

図１９に戻り、時間指定情報は、データが生成されたタイミングを指定する情報である。時間指定情報は、起点となる時刻、およびレンジによって表される。レンジは、例えば、最新インデックス１１８の生成周期を単位時間として、時間幅を１以上の整数で表した値である。

【0177】

データ指定情報は、取得するデータを指定する情報である。データ指定情報は、標準化車両データに示されたデータのアイテム名をリスト形式で表してもよいし、標準化車両データに示されたカテゴリ名を指定することで表してもよい。カテゴリ名を指定した場合、そのカテゴリに属するすべてのアイテムが指定されたことになる。また、アイテム名およびカテゴリ名がいずれも指定されていない場合は、全アイテムが指定されたことになる。また、アイテム名によって指定可能なデータには、標準化車両データには含まれないローデータが含まれてもよい。例えば、データ指定情報には、ローデータに対応づけられたＣＡＮフレームのＣＡＮＩＤが含まれてもよい。

【0178】

なお、ここで示した車両指定情報、時間指定情報、データ指定情報の設定の仕方は一例であり、上記方法に限定されるものではない。

【0179】

次に、第１データ取得ＡＰＩ１４６が第１データ取得要求を受け付けた場合に、インデックス取得部１２７が実行するシャドウリスト生成処理を、図２１のフローチャートを用いて説明する。

【0180】

Ｓ１１０では、インデックス取得部１２７は、第１データ取得要求に示された車両指定情報を参照し、指定情報が車両ＩＤリストであれば、処理をＳ１２０に移行し、指定情報がエリア指定であれば、処理をＳ１３０に移行する。

【0181】

Ｓ１２０では、インデックス取得部１２７は、インデックス記憶部１２５を参照して、車両ＩＤリストに示された「ｏｂｊｅｃｔ－ｉｄ」を有し、かつ、時間指定情報に示された時間範囲内の「ｔｉｍｅｓｔａｍｐ」を有する全てのインデックス１２６を抽出して、処理をＳ１５０に進める。

【0182】

Ｓ１３０では、インデックス取得部１２７は、指定情報に示されたエリア指定に従って、対象車両を探索する探索エリアを設定する。

【0183】

続くＳ１４０では、インデックス取得部１２７は、インデックス記憶部１２５を参照して、Ｓ１３０で設定された探索エリア内の「ｌｏｃａｔｉｏｎ」を有し、且つ、時間指定情報に示された時間範囲内の「ｔｉｍｅｓｔａｍｐ」を有する全てのインデックス１２６を抽出して、処理をＳ１５０に進める。

【0184】

Ｓ１５０では、インデックス取得部１２７は、Ｓ１２０またはＳ１４０で抽出されたインデックス１２６のそれぞれについて、インデックス１２６に示された「ｏｂｊｅｃｔ－ｉｄ」と「ｓｈａｄｏｗ＿ｅｒｓｉｏｎ」とを組み合わせたシャドウ特定情報を生成する。生成されたシャドウ特定情報は、シャドウ特定情報を列挙したシャドウ特定情報リスト（以下、シャドウリスト）の構成要素となる。

【0185】

続くＳ１６０では、インデックス取得部１２７は、Ｓ１５０にて生成されたシャドウリストに、第１データ取得要求に示されたデータ指定情報を付加したシャドウアクセス要求を、シャドウ管理部１１２のデータ取得部１１９に出力して、処理を終了する。

【0186】

図２２に示すように、インデックス取得部１２７は、矢印Ｌ３１で示すように、第１データ取得ＡＰＩ１４６から第１データ取得要求を受け取ると、シャドウリストを生成する。シャドウリストは、第１データ取得要求に示された車両指定情報および時間指定情報を取得条件とし、この取得条件に従って生成される。また、インデックス取得部１２７は、矢印Ｌ３２で示すように、生成したシャドウリストとデータ指定情報とを組み合わせたシャドウアクセス要求をデータ取得部１１９に出力する。

【0187】

データ取得部１１９は、インデックス取得部１２７からのシャドウアクセス要求が入力されると、シャドウ記憶部１１３を参照して、シャドウアクセス要求のシャドウリストに示された各シャドウ特定情報に対応するシャドウ１１４を抽出する。さらに、データ取得部１１９は、抽出されたシャドウ１１４のそれぞれから、シャドウアクセス要求のデータ指定情報に示されたデータである指定データを抽出する。データ取得部１１９は、矢印Ｌ３３で示すように、抽出した指定データをアクセス結果として、要求元となった第１データ取得ＡＰＩ１４６に返送する。

【0188】

［１－３－４．第２データ取得処理］
第２データ取得ＡＰＩ１４７がデータ取得要求（以下、第２データ取得要求）を受け付けた場合に実行される一連の処理である第２データ取得処理について説明する。具体的には、図１８において認証処理および認可処理が行われた後、アクセスＡＰＩからアクセス対象へアクセス要求が送信されたときの第２データ取得処理である。第２データ取得処理は、車両を指定して、その指定した車両から指定したデータを取得する処理である。

【0189】

まず、第２データ取得要求に含まれる指定情報について説明する。

【0190】

図２３に示すように、指定情報は、車両指定情報と、車両認証情報と、通知先情報と、データ指定情報とを含む。

【0191】

車両指定情報には、一つの車両ＩＤが示される。

【0192】

車両認証情報は、エッジ装置２を搭載する車両を認証するための情報であり、車両所有者に割り当てられたオーナＩＤと車両パスワードとで構成される。車両認証情報は、車両が保持すると共に、その車両へのアクセスが許可されたサービスユーザも保持する。

【0193】

通知先情報は、暗号化されたアクセス結果（すなわち、暗号文）の復号に用いる暗号情報の通知先を示すアドレス情報（例えばｕｒｌ）である。

【0194】

データ指定情報は、第１データ取得要求に含まれる指定情報にて説明したものと同様である。但し、アイテム名によって指定可能なデータには、標準化車両データには含まれないローデータが含まれてもよい。例えば、データ指定情報には、ローデータに対応づけられたＣＡＮフレームのＣＡＮＩＤが含まれてもよい。

【0195】

次に、第２データ取得ＡＰＩ１４７が第２データ取得要求を受け付けた場合に、車両制御部１３０が実行する車両データ取得処理を、図２４のフローチャートを用いて説明する。

【0196】

Ｓ２１０では、車両制御部１３０は、データの暗号化および暗号化されたデータの復号に用いる暗号情報を生成する。暗号情報は、暗号化と復号とで同じ鍵（すなわち、共通鍵）を用いてもよいし、異なる鍵（すなわち、暗号鍵と復号鍵）を用いてもよい。

【0197】

続くＳ２２０では、車両制御部１３０は、第２データ取得要求の通知先情報に示された通知先（例えば、第２データ取得要求の発信元であるサービスユーザが指定するｕｒｌ）に、Ｓ２１０で生成された暗号情報、特に復号に用いる鍵（すなわち、共通鍵または復号鍵）を送信する。

【0198】

続くＳ２３０では、車両制御部１３０は、第２データ取得要求の指定情報から通知先情報を除いた車両アクセス要求を生成し、車両指定情報に示された車両ＩＤを有する車両である対象車両に対して、通信部３２を介して車両アクセス要求を送信する。

【0199】

続くＳ２４０では、車両制御部１３０は、通信部３２を介して対象車両から車両アクセス要求に対する応答があったか否かを判定し、応答がなければ、同ステップを繰り返すことで待機し、応答があれば、処理をＳ２５０に移行する。ここでの車両アクセス要求は、車両からのデータ取得要求であり、車両においてエッジ装置２にて処理される。エッジ装置２は、認証処理を行った後、自身または車両Ｉ／Ｆ１２を介して接続されたＥＣＵ２１０，２２０，２３０等から、データ指定情報に該当する車両データを取得する。エッジ装置２は、取得した車両データを、通信部１３を介して管理センター３へ送信する。なお、ＥＣＵ２１０，２２０，２３０等から車両データを取得できなかった場合、エラーを管理センター３へ送信する。車両制御部１３０は、これらを車両からの応答として受信する。

【0200】

Ｓ２５０では、車両制御部１３０は、車両からの応答内容を、Ｓ２１０で生成された暗号に用いる鍵（すなわち、共通鍵または暗号鍵）によって暗号化し、暗号化された応答内容を、要求元となった第２データ取得ＡＰＩ１４７に返信して処理を終了する。なお、車両からの応答内容には、例えば、データ指定情報にて指定されたデータ、および車両での認証に失敗した旨の通知などが含まれてもよい。

【0201】

図２５に示すように、車両制御部１３０は、矢印Ｌ４１で示すように、第２データ取得ＡＰＩ１４７から第２データ取得要求が入力されると、暗号情報を生成する。そして、車両制御部１３０は、矢印Ｌ４２で示すように、第２データ取得要求に示された通知先に、生成した復号用の鍵を送信する。これと共に、車両制御部１３０は、矢印Ｌ４３で示すように、第２データ取得要求の指定情報から通知先情報を除いた車両アクセス要求を、車両に向けて送信する。すなわち、車両制御部１３０は、車両アクセス要求を車両に向けて送信する段階で、復号用の鍵を通知先に送信しておく。

【0202】

車両指定情報に示された車両ＩＤを有する車両に搭載されたエッジ装置２が、車両アクセス要求を受信すると、車両アクセス要求に示された車両認証情報と、自車両が有する車両認証情報とを照合して認証を行う。

【0203】

認証に失敗した場合、エッジ装置２は、その旨を表す通知を含んだ応答を管理センター３に送信する。

【0204】

認証に成功した場合、エッジ装置２は、矢印Ｌ４４で示すように、データ指定情報に示された指定データを車両から取得して、取得した指定データを含んだ応答を管理センター３に送信する。指定データは、エッジ装置２が有するデータの場合もあれば、車両Ｉ／Ｆ１２を介して他の電子制御装置から取得するデータの場合もある。なお、エッジ装置２は、指定データを取得できなかった場合、取得失敗を表す通知を含んだ応答を管理センター３に送信する。

【0205】

応答を受信した車両制御部１３０は、矢印Ｌ４５で示すように、応答内容を暗号化して第２データ取得ＡＰＩ１４７に返送する。

【0206】

第２データ取得要求を行ったサービスユーザは、第２データ取得ＡＰＩ１４７を介して取得する暗号化された応答内容を、通知先に送られた復号用の鍵を用いて復号することで、応答内容を知ることができる。ここで、復号用の鍵を送付する通知先は、第２データ取得ＡＰＩ１４７自身であってもよい。また、車両制御部１３０は、通知先に対して暗号化した応答内容を送信するようにしてもよい。

【0207】

車両制御ＡＰＩ１４８では、データ指定情報の代わりに制御指定情報を用いることで、第２データ取得ＡＰＩ１４７による一連の処理と同様の処理で、エッジ装置２を介して車両を制御できる。制御指定情報は、車両のアクチュエータ等を制御するための情報で、どのアクチュエータをどのように制御するかが指定される。例えば、エッジ装置の車両Ｉ／Ｆを介してドアロックを制御する電子制御装置に指示を送信することで、ドアをロックまたはアンロックすることができる。エッジ装置２は、通信部１３を介して車両アクセス要求を受信すると、認証処理を行う。その後、エッジ装置２は、車両Ｉ／Ｆ１２を介して接続されたＥＣＵ２１０，２２０，２３０等から、実行完了または実行失敗を通知されると、それらを表す通知を含んだ応答を管理センター３に送信する。

【0208】

［１－４．用語の対応］
以上説明した実施形態において、モビリティＩｏＴシステム１はモビリティサービス提供システムに相当し、管理センター３はモビリティサービス提供サーバに相当し、エッジ装置２は車載機に相当する。シャドウ記憶部１１３は第１データベースに相当し、インデックス記憶部１２５は第２データベースに相当する。ＡＰＩ提供部１２２はインタフェース部に相当する。サービスユーザＩＤおよびトークンはユーザ識別情報に相当する。認証処理部１４４において認可処理を実施する機能が認可部に相当する。Ｓ２１０～Ｓ２２０の処理は暗号情報生成部に相当し、Ｓ２５０～Ｓ２６０の処理は暗号化部に相当する。第１データ取得要求が第１アクセス要求に相当し、第２データ取得要求および車両制御要求が第２アクセス要求に相当する。

【0209】

［１－５．効果］
以上詳述した実施形態によれば、以下の効果を奏する。

【0210】

（１ａ）モビリティＩｏＴシステム１によれば、サービスユーザは、オープンＡＰＩである第１データ取得ＡＰＩ１４６を利用して、データ取得の対象となる対象車両の車両データを、対象車両のシャドウ１１４から取得できる。つまり、対象車両の状態に関わらず、標準化車両データに属する任意の車両データを取得できる。また、サービスユーザは、クローズＡＰＩである第２データ取得ＡＰＩ１４７を利用して、対象車両から直接、対象車両が有する車両データを取得できる。この場合、標準化車両データに属する車両データだけでなく、標準化車両データに含まれないローデータも取得できる。また、シャドウ１１４が記憶する過去のデータではなく、リアルタイムなデータを取得できる。従って、サービスユーザの要求に応じた柔軟な情報提供を実現できる。

【0211】

（１ｂ）クローズＡＰＩ１４７，１４８では、アクセス先からの応答が暗号化してサービスユーザに提供されると共に、復号用の鍵が、サービスユーザによって指定された送信先に送信される。従って、クローズＡＰＩ１４７，１４８を利用することで、機密性の高い情報を安全に取得すること、および対象車両の制御を安全に実行することができる。

【0212】

（１ｃ）アクセスＡＰＩ１４６～１４８では、サービスユーザのアクセス権限（すなわち、認可クラス，認可オブジェクト）を確認し、権限外のアクセスを拒否する。従って、サービスユーザに応じた、柔軟なサービスの提供を実現できる。

【0213】

（１ｄ）第１データ取得ＡＰＩ１４６を用いてシャドウ１１４からデータを取得する際に、車両指定情報と時間指定情報を用いてデジタルツイン１２３を検索することで抽出されたインデックス１２６から、シャドウ特定情報を生成する。従って、特定車両の現在から過去に渡る任意の車両データや、指定時刻に指定エリアに存在した車両の車両データ等を、簡易に取得できる。その結果、第１データ取得ＡＰＩ１４６によって取得される車両データは、例えば、交通量の解析や予測を行うサービス等に用いることができる。

【0214】

［２．第２実施形態］
［２－１．第１実施形態との相違点］
第２実施形態は、基本的な構成は第１実施形態と同様であるため、相違点について以下に説明する。なお、第１実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。

【0215】

前述した第１実施形態では、ＡＰＩを用いたアクセス要求に対する認可を、管理センター３側で処理する仕組みを説明した。これに対し、第２実施形態では、ＡＰＩを用いた車両へのアクセス要求（すなわち、第２データ取得要求および車両制御要求）に対する認可を、管理センター３およびエッジ装置２のうち少なくとも一方で処理する仕組みについて説明する。

【0216】

［２－２．管理センター］
管理センター３は、認可オブジェクトＤＢおよび認可クラスＤＢの代わりにサーバ側認可ＤＢを備える。サーバ側認可ＤＢは、例えば、図１２に示した認可情報記憶部１４２に設けられる。

【0217】

図２７に示すように、サーバ側認可ＤＢは、「サービスユーザＩＤ」に対応づけて、「認可オブジェクト」「アクセス権限」を記憶する。「サービスユーザＩＤ」および「認可オブジェクト」は、認可オブジェクトＤＢでの説明と同様である。「アクセス権限」は、「認可オブジェクト」で特定される車両について、「サービスユーザＩＤ」で特定されるサービスユーザに対してアクセスが許可されたアクセス対象のリストである。「アクセス権限」には、例えば、「Ｄｏｏｒ」「Ｔｒｕｎｋ」「ＡＬＬ」等が含まれる。「Ｄｏｏｒ」は、ドアの解錠、施錠についてアクセス権限があることを示す。「Ｔｒｕｎｋ」は、トランクの開閉についてアクセス権限があることを示す。「ＡＬＬ」は、車両が提供可能なすべてのアクセス対象についてアクセス権限があることを示す。

【0218】

サーバ側認可ＤＢでは、モビリティサービスの提供元となるサービスユーザ毎に、車両アクセス要求についてサービスユーザが有するアクセス権限、すなわち、車両アクセス要求によってアクセス可能な範囲を規定する情報が設定される。

【0219】

［２－３．エッジ装置］
図２８に示すように、第２実施形態では、エッジ装置２の第２ユニット１０２が、ＧＰＯＳ１０５および第２アプリケーション１０６に加えて、車両アクセスＡＰＩ１０７を備える。

【0220】

車両アクセスＡＰＩ１０７は、管理センター３からの車両アクセス要求を受け付けて、車両側での認可処理（以下、車側認可処理）を実行する。また、エッジ装置２は、車側認可処理に用いる車側認可ＤＢを備える。車側認可ＤＢは、例えば、図２に示した記憶部１４またはフラッシュメモリ２５に設けられる。

【0221】

図２９に示すように、車側認可ＤＢは、「サービスユーザＩＤ」に対応づけて、「認可ユーザ」「アクセス権限」を記憶する。「認可ユーザ」には、実際に車両を利用する可能性のある車両ユーザのＩＤ（以下、車両ユーザＩＤ）が列挙される。つまり、ひとつの「サービスユーザＩＤ」に対して複数の「認可ユーザ」が対応づけられてもよい。「アクセス権限」は、サーバ側認可ＤＢでの説明と同様である。「アクセス権限」は、「認可ユーザ」毎に設定される。

【0222】

車側認可ＤＢでは、サービスユーザが提供する対象サービスにおいて、対象サービスのユーザとして登録された車両ユーザ毎に、車両アクセス要求について車両ユーザが有するアクセス権限、すなわち、車両アクセス要求によってアクセス可能な範囲を規定する情報が設定される。

【0223】

［２－４．２段階認可］
管理センター３による認可処理（以下、サーバ側認可処理）およびエッジ装置２による認可処理（すなわち、車側認可処理）をいずれも実行する２段階認可の手順を、図３０のシーケンス図を用いて説明する。

【0224】

ここでは、要求者が、サービス提供サーバ４が提供するサービスを利用して、車両へのアクセス要求を行った場合を例にして説明する。要求者は、例えば、車両を使用する車両ユーザである。車両ユーザは、車両のオーナでもよいし、車両のレンタルを受けるユーザでもよい。要求者は車両ユーザＩＤによって識別される。サービス提供サーバ４が提供するサービスは、サービスユーザＩＤによって識別される。

【0225】

サービス提供サーバ４は、要求者からの車両アクセス要求を受け付けると、管理センター３のＡＰＩ提供部１２２が提供するログインＡＰＩ１４５にアクセスして認証処理を実行する。認証処理の手順は、矢印Ｌ２１，Ｌ２２で示すように、第１実施形態の場合と同様である。

【0226】

サービス提供サーバ４は、認証処理に成功すると、矢印Ｌ５１で示すように、ＡＰＩ提供部１２２が提供するアクセスＡＰＩを用いて、要求者からの要求に応じた車両アクセス要求（すなわち、第２データ取得要求または車両制御要求）を、管理センター３に対して出力する。車両アクセス要求には、認証処理によって付与されるトークンと、車両ユーザＩＤと、車両指定情報と、データ指定情報または制御指定情報とが含まれる。車両指定情報は、アクセスの対象となる車両（以下、指定車両）を指定するための情報である。データ指定情報または制御指定情報は、具体的な、アクセス対象を特定するための情報である。アクセス対象には、車両データおよび種々の車載機器が含まれる。

【0227】

管理センター３は、サービス提供サーバ４からの車両アクセス要求を受け付けると、認証処理部１４４が認可処理を実行する。

【0228】

認可処理が実行されると、認証処理部１４４は、車両アクセス要求に付加された「トークン」から「サービスユーザＩＤ」を特定する。次に、認証処理部１４４は、認可情報記憶部１４２のサーバ側認可ＤＢを検索することで、特定された「サービスユーザＩＤ」に対応づけられた「認可オブジェクト」「アクセス権限」を抽出する。更に、認証処理部１４４は、抽出された「認可オブジェクト」に、車両アクセス要求に示された指定車両が含まれるか否か、すなわち、サービスユーザが提供するサービスにおいて、指定車両へのアクセスが許可されているか否かを判定する。また、認証処理部１４４は、抽出された「アクセス権限」に、車両アクセス要求に示されたアクセス対象が含まれるか否か、すなわち、サービスユーザが提供するサービスにおいて、アクセス対象へのアクセスが許可されているか否かを判定する。

【0229】

指定車両が「認可オブジェクト」に含まれない場合、または、アクセス対象が「アクセス権限」に含まれない場合、認証処理部１４４は不認可と判定する。不認可と判定した場合、認証処理部１４４は、矢印Ｌ５２で示すように、アクセスＡＰＩおよびサービス提供サーバ４を介して要求者に、サービスユーザの権限外を理由とするアクセス拒否を通知する。

【0230】

指定車両が「認可オブジェクト」に含まれ、かつ、アクセス対象が「アクセス権限」に含まれる場合は、認可と判定し、矢印Ｌ５３で示すように、車両アクセス要求を、車両制御部１３０を介して指定車両に送信する。

【0231】

指定車両に搭載されたエッジ装置２の車両アクセスＡＰＩ１０７は、管理センター３からの車両アクセス要求を受け付けると、車側認可処理を実行する。

【0232】

車側認可処理が実行されると、第２ユニット１０２は、車側認可ＤＢを参照して、車両アクセス要求に示された「サービスユーザＩＤ」に対応づけられる「認可ユーザ」「アクセス権限」を抽出する。次に、第２ユニット１０２は、抽出された「認可ユーザ」に、アクセス要求に示された要求者の車両ユーザＩＤが含まれるか否か、すなわち、要求者による指定車両へのアクセスが許可されているか否かを判定する。また、第２ユニット１０２は、抽出された「アクセス権限」に、アクセス要求に示されたアクセス対象が含まれるか否か、すなわち、要求者によるアクセス対象へのアクセスが許可されているか否かを判定する。

【0233】

要求者の車両ユーザＩＤが「認可ユーザ」に含まれない場合、または、アクセス対象が「アクセス権限」に含まれない場合、第２ユニット１０２は、不認可と判定する。不認可と判定した場合、第２ユニット１０２は、矢印Ｌ５４で示すように、車両アクセスＡＰＩ１０７を介して管理センター３に、要求者の権限外を理由とするアクセス拒否を送信する。アクセス拒否を受信した管理センター３は、矢印Ｌ５５で示すように、アクセスＡＰＩおよびサービス提供サーバ４を介して要求者に、アクセス拒否を通知する。

【0234】

要求者の車両ユーザＩＤが「認可ユーザ」に含まれ、かつ、アクセス対象が「アクセス権限」に含まれる場合、第２ユニット１０２は、認可と判定する。認可と判定した場合、第２ユニット１０２は、矢印Ｌ５６で示すように、アクセス対象に対して制御指示を送信し、矢印Ｌ５７で示すように、アクセス対象からアクセス結果を受信する。更に、第２ユニット１０２は、矢印Ｌ５８で示すように、車両アクセスＡＰＩ１０７を介して管理センター３にアクセス結果を送信する。アクセス結果を受信した管理センター３は、矢印Ｌ５９で示すように、アクセスＡＰＩおよびサービス提供サーバ４を介して要求者にアクセス結果を通知する。アクセス結果の通知は、第１実施形態での説明と同様に、暗号化してもよい。

【0235】

［２－５．車側単独認可］
認可処理をエッジ装置２でのみ実行する車側単独認可の手順を、図３１のシーケンス図を用いて説明する。

【0236】

ここでは、２段階認可の場合と同様に、要求者が、サービス提供サーバ４が提供するサービスを利用して、車両へのアクセス要求を行った場合を例にして説明する。

【0237】

サービス提供サーバ４は、要求者からの車両アクセス要求を受け付けると、管理センター３のＡＰＩ提供部１２２が提供するログインＡＰＩ１４５にアクセスして認証処理を実行する。認証処理の手順は、矢印Ｌ２１，Ｌ２２で示すように、第１実施形態の場合と同様である。

【0238】

サービス提供サーバ４は、認証処理に成功すると、矢印Ｌ５１で示すように、ＡＰＩ提供部１２２が提供するアクセスＡＰＩを用いて、要求者からの要求に応じた車両アクセス要求を、管理センター３に対して出力する。

【0239】

管理センター３は、サービス提供サーバ４からのアクセス要求を受け付けると、センター側認可処理を実行することなく、矢印Ｌ５３で示すように、車両制御部１３０を介して車両アクセス要求を指定車両に送信する。

【0240】

指定車両に搭載されたエッジ装置２の車両アクセスＡＰＩ１０７は、管理センター３からのアクセス要求を受け付けると、車側認可処理を実行する。車側認可処理の結果を管理センター３に送信する以降の手順は、矢印Ｌ５４～Ｌ５９で示すように、前述の２段階認可で説明した手順と同様である。

【0241】

［２－６．センター側単独認可］
認可処理をエッジ装置２でのみ実行するセンター側単独認可の手順について説明する。

【0242】

センター側単独認可では、センター側単独認可では、指定車両に搭載されたエッジ装置２の車両アクセスＡＰＩ１０７が、管理センター３から車両アクセス要求を受け付けた場合、車側認可処理が省略される点以外は、２段階認可の手順と同様である。つまり、センター側単独認可では、図３０に示したシーケンスにおいて、車側認可処理が省略されると共に、車側認可処理で不認可と判定される場合の一連のシーケンスが省略される。

【0243】

［２－７．用語の対応］
以上説明した実施形態において、サーバ側認可ＤＢが設けられる認可情報記憶部１４２がサーバ側記憶部に相当し、サーバ側認可処理を実行する認証処理部１４４がサーバ側認可部に相当する。車側認可ＤＢが設けられる記憶部１４又はフラッシュメモリ２５が車側記憶部に相当し、車側認可処理を実行する車両ＡＰＩ１０７が車側認可部に相当する。サーバ側認可ＤＢの内容がサービス別認可情報に相当し、車側認可ＤＢの内容がユーザ別認可情報に相当する。

【0244】

［２－８．効果］
以上詳述した第２実施形態によれば、前述した第１実施形態の効果（１ａ）を奏し、さらに、以下の効果を奏する。

【0245】

（２ａ）第２実施形態では、車両アクセス要求に対して、管理センター３では、サービスユーザ単位で認可処理（すなわち、サーバ側認可処理）を行い、エッジ装置２では、車両ユーザ単位で認可処理（すなわち、車側認可処理）を行う。そして、サーバ側認可処理および車側認可処理をいずれも行う２段階認可を適用した場合、車側認可処理でアクセス拒否されること、ひいては、管理センター３とエッジ装置２との通信量を抑制できる。車側単独認可を適用した場合、管理センター３の処理負荷を軽減できる。センター側単独認可を適用した場合、エッジ装置２の処理負荷を軽減できる。

【0246】

［３．他の実施形態］
以上、本開示の一実施形態について説明したが、本開示は上記実施形態に限定されるものではなく、種々変形して実施することができる。

【0247】

（３ａ）第２実施形態では、２段階認可、車側単独認可、センター側単独認可の３つの手順について説明したが、サーバ側認可ＤＢの設定によって、センター側単独認可、および車側単独認可のいずれかを選択できるように構成されてもよい。具体的には、図２７に示すサーバ側認可ＤＢの「アクセス権限」の欄を利用し、「アクセス権限」に「ＡＬＬ」および「ＡＮＹ」のいずれかを設定する。そして「ＡＬＬ」の場合は、すべてのアクセス対象に対してアクセス権限を有するため、管理センター３だけで認可処理を行い、「ＡＮＹ」の場合は、管理センター３での認可処理を省略し、エッジ装置２での認可処理のみを行う。この場合、サービスユーザは、自身が提供するサービスに適した認可方法を柔軟に選択できる。

【0248】

（３ｂ）本実施形態に記載の制御部３１およびその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサおよびメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本実施形態に記載の制御部３１およびその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本実施形態に記載の制御部３１およびその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサおよびメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されてもよい。制御部３１に含まれる各部の機能を実現する手法には、必ずしもソフトウェアが含まれている必要はなく、その全部の機能が、一つあるいは複数のハードウェアを用いて実現されてもよい。

【0249】

（３ｃ）上記実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加または置換してもよい。

【0250】

（３ｄ）上述した管理センター３の他、当該管理センター３を構成要素とするシステム、当該管理センター３としてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実体的記録媒体、車両データ提供方法など、種々の形態で本開示を実現することもできる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】