特開 2024-127299 情報管理システム

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

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

(11)【公開番号】P2024127299

(43)【公開日】2024-09-20

(54)【発明の名称】情報管理システム

(51)【国際特許分類】

   G06F 16/28 20190101AFI20240912BHJP

   G06Q 50/10 20120101ALI20240912BHJP

【ＦＩ】

G06F16/28

G06Q50/10

【審査請求】未請求

【請求項の数】5

【出願形態】ＯＬ

(21)【出願番号】P 2023036354

(22)【出願日】2023-03-09

(71)【出願人】

【識別番号】000006286

【氏名又は名称】三菱自動車工業株式会社

(74)【代理人】

【識別番号】100183689

【弁理士】

【氏名又は名称】諏訪 華子

(74)【代理人】

【識別番号】110003649

【氏名又は名称】弁理士法人真田特許事務所

(72)【発明者】

【氏名】石黒 稚加恵

(72)【発明者】

【氏名】松山 敬之

【テーマコード（参考）】

5B175

5L049

5L050

【Ｆターム（参考）】

5B175EA03

5B175FB04

5L049CC11

5L050CC11

(57)【要約】

【課題】情報管理システムに関し、効率よくデータの利活用を促進する。
【解決手段】開示の情報管理システム５は、車両１０に搭載される車載通信装置１１から送信される複数の車両関連情報を管理するものである。この情報管理システム５は、車両関連情報の中から複数のテーマの各々に沿った車両関連情報がテーマ毎に抽出されてなるテーブルを、テーマ毎に生成する情報処理手段６と、複数のテーブルを個別に記憶する記憶手段８とを備える。複数のテーマの各々は、テーマ毎に抽出される車両関連情報の更新頻度又は更新時機に基づいて分類される。
【選択図】図１

【特許請求の範囲】

【請求項1】

車両に搭載される車載通信装置から送信される複数の車両関連情報を管理する情報管理システムであって、
前記車両関連情報の中から複数のテーマの各々に沿った前記車両関連情報が前記テーマ毎に抽出されてなるテーブルを、前記テーマ毎に生成する情報処理手段と、
複数の前記テーブルを個別に記憶する記憶手段とを備え、
複数の前記テーマの各々が、当該テーマ毎に抽出される前記車両関連情報の更新頻度又は更新時機に基づいて分類される
ことを特徴とする、情報管理システム。

【請求項2】

複数の前記テーブルの各々が、前記更新時機の違いを表す第一属性を有し、
前記第一属性が、
前記車両を識別するための情報が格納される前記テーブルに付加される識別系と、
前記車両の状態を表す情報が格納される前記テーブルに付加される状態系と、
前記車両に対する運転操作に関する情報が格納される前記テーブルに付加される操作系とを含む
ことを特徴とする、請求項１記載の情報管理システム。

【請求項3】

複数の前記テーブルの各々が、前記更新頻度の違いを表す第二属性を有し、
前記第二属性が、
前記車両関連情報を所定期間毎に要約又は集計した情報が格納される前記テーブルに付加されるサマリー型と、
前記車両関連情報の履歴に関する情報が格納される前記テーブルに付加される履歴型と、
前記車両関連情報のうち前記車両の最新の状態を表す情報が格納される前記テーブルに付加されるトランザクション型とを含む
ことを特徴とする、請求項１記載の情報管理システム。

【請求項4】

前記更新頻度は、前記サマリー型よりも前記履歴型が高く、前記履歴型よりも前記トランザクション型が高いか同一である
ことを特徴とする、請求項３記載の情報管理システム。

【請求項5】

前記第二属性が、前記車両が製造された際に付与される情報が格納される前記テーブルに付加されるマスター型を含み、
前記更新頻度は、前記マスター型が前記サマリー型よりも低い
ことを特徴とする、請求項３記載の情報管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本件は、車両から送信される車両関連情報を管理する情報管理システムに関する。

【背景技術】

【0002】

従来、多数の車両から送信される多種多様な車両関連情報をビッグデータとして集積し、そのビッグデータの一部を様々な顧客に提供できるようにした情報管理システムが提案されている。例えば、各ユーザーの運転傾向を示す個別の集計結果情報や多数のユーザーの運転傾向を示す全体の集計結果情報等を生成し、これらの集計結果情報をメンテナンス会社や保険会社等に提供する情報管理システムが知られている（特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開2011-198334号公報

【発明の概要】

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

【0004】

近年におけるビッグデータの用途や分析目的は多岐にわたり、ますます多様化しつつある。そのため、特許文献１に記載されているような集計結果情報だけでなく、各々の顧客のニーズに合致した形で各種情報を提供できるように、ビッグデータの一部を抽出して加工しておくことが望まれる。一方、既存の情報管理システムでは、このようなビッグデータの事前加工（前処理）の重要性が十分に認識されておらず、顧客からの要求を受けた時点でその都度、ビッグデータの一部が抽出されて加工や整形が施されている。したがって、顧客が要求している各種情報を迅速かつ大量に提供することが難しく、データの利活用を促進しにくいという課題がある。

【0005】

本件の目的のひとつは、上記のような課題に照らして創案されたものであり、効率よくデータの利活用を促進できるようにした情報管理システムを提供することである。なお、この目的に限らず、後述する「発明を実施するための形態」に示す各構成から導き出される作用効果であって、従来の技術では得られない作用効果を奏することも、本件の他の目的として位置付けられる。

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

【0006】

開示の情報管理システムは、以下に開示する態様（適用例）として実現でき、上記の課題の少なくとも一部を解決する。態様２以降の各態様は、何れもが付加的に適宜選択されうる態様であって、何れもが省略可能な態様である。態様２以降の各態様は、何れもが本件にとって必要不可欠な態様や構成を開示するものではない。

【0007】

態様１．開示の情報管理システムは、車両に搭載される車載通信装置から送信される複数の車両関連情報を管理する情報管理システムであって、前記車両関連情報の中から複数のテーマの各々に沿った前記車両関連情報が前記テーマ毎に抽出されてなるテーブルを、前記テーマ毎に生成する情報処理手段と、複数の前記テーブルを個別に記憶する記憶手段とを備える。複数の前記テーマの各々は、当該テーマ毎に抽出される前記車両関連情報の更新頻度又は更新時機に基づいて分類される。

【0008】

態様２．上記の態様１において、複数の前記テーブルの各々が、前記更新時機の違いを表す第一属性を有することが好ましい。また、前記第一属性が、前記車両を識別するための情報が格納される前記テーブルに付加される識別系と、前記車両の状態を表す情報が格納される前記テーブルに付加される状態系と、前記車両に対する運転操作に関する情報が格納される前記テーブルに付加される操作系とを含むことが好ましい。

【0009】

態様３．上記の態様１又は２において、複数の前記テーブルの各々が、前記更新頻度の違いを表す第二属性を有することが好ましい。また、前記第二属性が、前記車両関連情報を所定期間毎に要約又は集計した情報が格納される前記テーブルに付加されるサマリー型と、前記車両関連情報の履歴に関する情報が格納される前記テーブルに付加される履歴型と、前記車両関連情報のうち前記車両の最新の状態を表す情報が格納される前記テーブルに付加されるトランザクション型とを含むことが好ましい。

【0010】

態様４．上記の態様３において、前記更新頻度は、前記サマリー型よりも前記履歴型が高く、前記履歴型よりも前記トランザクション型が高いか同一であることが好ましい。
態様５．上記の態様３又は４において、前記第二属性が、前記車両が製造された際に付与される情報が格納される前記テーブルに付加されるマスター型を含むことが好ましい。また、前記更新頻度は、前記マスター型が前記サマリー型よりも低いことが好ましい。

【発明の効果】

【0011】

開示の情報管理システムによれば、複数の車両関連情報の管理に際し、テーマ毎に異なるテーブルを用意しておくことで、車両関連情報をその利活用の目的及び用途に適した形に整理することができ、車両関連情報の利便性を向上させることができる。また、車両関連情報の更新頻度や更新時機に基づいて各テーマが分類されているため、情報を効率よく更新でき、効率よくデータの利活用を促進できる。

【図面の簡単な説明】

【0012】

【図1】実施例に係る情報管理システムが適用されるネットワークの構成を例示する模式図である。

【図2】情報管理システムに係るサーバーのハードウェア構成を例示するブロック図である。

【図3】情報管理システムで管理されるデータの構造を例示する表である。

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

【0013】

以下、本発明の実施例に係る情報管理システムを説明する。本発明が適用される情報管理システムは、車両に搭載される車載通信装置から送信される複数の車両関連情報を管理する情報管理システムである。ここでいう車両には、エンジン（内燃機関）を駆動源として走行するエンジン車両や、モータ（電動機）を駆動源として走行するモータ車両や、エンジン及びモータを駆動源として走行するハイブリッド車両（ＨＥＶ，Hybrid Electric Vehicle）が含まれる。

【0014】

なお、上記のハイブリッド車両には、外部充電又は外部給電が可能なプラグインハイブリッド車両（ＰＨＥＶ，Plug-in Hybrid Electric Vehicle）が含まれる。プラグインハイブリッド車両とは、駆動源としてのエンジン及びモータと発電装置としてのジェネレータと蓄電装置としてのバッテリーとが搭載されたハイブリッド車両において、バッテリーに対する外部充電又はバッテリーからの外部給電が可能であるものを意味する。

【0015】

前者のプラグインハイブリッド車両には、外部充電設備からの電力が送給される充電ケーブルを差し込むための充電口（インレット）や非接触受電装置等が設けられる。後者のプラグインハイブリッド車両には、外部給電用のコンセント（アウトレット）や非接触給電装置等が設けられる。一台のプラグインハイブリッド車両に、上記の充電口やコンセントを併設することも可能である。

【実施例0016】

［１．システム構成］
図１は、実施例に係る情報管理システムとしてのコネクティッドデータプラットフォーム５が適用されるネットワーク１の構成を例示する模式図である。ネットワーク１上には、デバイスプラットフォーム２とコネクティッドデータプラットフォーム５とが設けられる。

【0017】

デバイスプラットフォーム２は、車載通信装置１１が搭載される車両１０を対象としたカーテレマティクスサービスの基盤をなしている。デバイスプラットフォーム２は、ネットワーク１を介して、複数の外部コンピューターに対して接続可能とされる。ここでいう外部コンピューターの具体例としては、車載通信装置１１，車両１０のユーザーや乗員等が所持する携帯端末１２，車両１０の工場１３（工場１３の施設内に設置されたコンピューター），車両１０に搭載されている車載機器の製造元であるサプライヤー１４（サプライヤー１４が管理するコンピューター）等が挙げられる。なお、工場１３及びサプライヤー１４が保有する情報は、あらかじめ車両１０に記録されうる。したがって、工場１３及びサプライヤー１４がデバイスプラットフォーム２に接続されない場合もある。

【0018】

車載通信装置１１の具体例としては、ＩＶＣ（In Vehicle Communication，車載通信モジュール），ＴＣＵ（Telematics Control Unit，テレマティクス制御ユニット），通信機能付きＩＶＩ（In Vehicle Infotainment，車載情報モジュール）等の車両１０に搭載されているコンピューターが挙げられる。また、携帯端末１２の具体例としては、スマートフォン，ノートパソコン等の車両１０に搭載されていないコンピューターが挙げられる。

【0019】

テレマティクスサービスの対象となる車両１０から送信される大量の車両関連情報は、デバイスプラットフォーム２の上でビッグデータとして管理される。また、工場１３やサプライヤー１４から送信される情報は、デバイスプラットフォーム２の上において、各々の車両１０との対応関係が把握される形式で管理される。

【0020】

デバイスプラットフォーム２には、第一ストレージ３及び第二ストレージ４が設けられる。第一ストレージ３は、車両１０の車載通信装置１１から送信される情報が保存される記憶装置（例えば、物理ストレージやクラウドストレージ）である。第一ストレージ３に保存される情報は、例えば図示しないテレマティクスサーバーによって管理される。テレマティクスサーバーは、各種のカーテレマティクスサービスを提供する主体となる管理装置（例えば、物理サーバー装置やクラウドサーバー）であり、例えば車載通信装置１１から送信される情報を第一ストレージ３に保存する機能を持つ。

【0021】

テレマティクスサーバーは、第一ストレージ３に保存された情報を車載通信装置１１や携帯端末１２に提供する機能や、携帯端末１２からの要求に応じて車両１０や各種関連サービス事業者等に制御指令や警報を出力する機能を持つ。テレマティクスサーバーが持つ機能の具体例としては、リモートエアコン機能，リモート充電管理機能，リモート自動運転機能，自動通報機能，リモート見守り機能，リモート施錠解錠機能，車両ステータス確認機能，車両位置確認機能，走行履歴確認機能，カスタマーサポート取り次ぎ機能，オンラインアップデート機能（地図情報アップデート，システムアップデート，セキュリティアップデート）等が挙げられる。

【0022】

第二ストレージ４は、車両１０の工場１３やサプライヤー１４から送信される情報が保存される記憶装置（例えば、物理ストレージやクラウドストレージ）である。第二ストレージ４に保存される情報は、例えば図示しないＦＴＰ（File Transfer Protocol）サーバーによって管理される。ＦＴＰサーバーは、工場１３から送信される車両１０に関する情報や、サプライヤー１４から送信される車両１０の車載機器に関する情報を第二ストレージ４に保存する機能を持つ。

【0023】

コネクティッドデータプラットフォーム５は、テレマティクスサービスで取得される多種多様な車両関連情報（ビッグデータ）を整理して、モビリティサービス，保険サービス，公共交通サービス等のための各種機能を提供するためのプラットフォームである。ビッグデータの提供先（顧客）の具体例としては、カーリース会社，タクシー会社，保険会社，警察，消防，病院，データ分析会社，車両販売店，修理業者，車両メーカー等が挙げられる。車両メーカーは、顧客に限らず、自社の車両のビッグデータについてフィードバックを受ける立場であってもよい。図１中には、上記のような顧客が管理している顧客サーバー９のひとつを図示する。本実施例のコネクティッドデータプラットフォーム５は、多種多様な車両関連情報の中から顧客が要求する情報をその要求に適した形で効率よく顧客サーバー９に送信できるようにするための構成を備える。

【0024】

コネクティッドデータプラットフォーム５には、サーバー６（情報処理手段）とデータレイク７とデータウェアハウス８（記憶手段）とが設けられる。サーバー６は、コネクティッドデータプラットフォーム５における演算処理を司る管理装置（例えば、物理サーバー装置やクラウドサーバー）である。また、データレイク７及びデータウェアハウス８は、サーバー６によって管理される記憶装置（例えば、物理ストレージやクラウドストレージ）である。データレイク７及びデータウェアハウス８に保存される各種情報は、顧客の要求に応じて顧客サーバー９に送信可能となっている。

【0025】

データレイク７は、第一ストレージ３及び第二ストレージ４に保存されるものと同じ車両関連情報をまとめて保存する記憶装置である。データレイク７には、テレマティクスサーバーから送信された車両関連情報のローデータ（Raw Data，生データ）がそのままの形で保存される。一方、データウェアハウス８には、処理済みデータが保存される。ここでいう処理済みデータには、ローデータの一部を抽出したもの，加工したもの，整形したもの等が含まれる。

【0026】

つまり、データレイク７がビッグデータそのものを保存する役割を持つのに対し、データウェアハウス８はビッグデータに事前加工（前処理）を施したものを保存する役割を持つ。このように、加工後のデータは、加工前の車両関連情報とは別個に保存される。なお、データレイク７及びデータウェアハウス８は、一台の物理ストレージ内において互いに独立に設けられるものであってもよいし、別体の物理ストレージの各々に設けられるものであってもよい。

【0027】

図２は、コネクティッドデータプラットフォーム５に設けられるサーバー６のハードウェア構成を例示するブロック図である。サーバー６には、プロセッサー２１及びメモリー２２を有する処理装置２０と通信装置２３と記憶装置２４とが設けられる。処理装置２０は、サーバー６で実行される演算処理の主体となる装置であり、通信装置２３は、ネットワーク１を介して他のコンピューターと情報の授受を行うための装置である。記憶装置２４は、サーバー６で実行される演算処理の内容を処理プログラムとして記憶する装置である。処理プログラムの内容は、プロセッサー２１及びメモリー２２に適宜読み込まれて実行される。なお、記憶装置２４はサーバー６と別体に設けてもよい。また、サーバー６はひとつの物理サーバーに含まれる複数の仮想サーバーのうちのひとつであってもよいし、複数の物理サーバーをひとつの仮想サーバーとして機能させたものであってもよい。

【0028】

サーバー６は、第一ストレージ３に保存される情報と第二ストレージ４に保存される情報とを図示しないテレマティクスサーバーから受け取り、受け取った情報をデータレイク７及びデータウェアハウス８に保存する機能を持つ。サーバー６による情報の保存機能は、二種類の機能に大別される。第一の機能は、受け取った全ての車両関連情報をローデータとしてデータレイク７に保存する機能である。第二の機能は、受け取った車両関連情報のうちの一部分を抽出して加工し、処理済みデータとしてデータウェアハウス８に保存する機能である。以下、データウェアハウス８に保存される処理済みデータについて詳述する。

【0029】

データウェアハウス８の処理済みデータは、複数の情報の要素がひとつの行（Row）をなすように格納されるとともに、複数の行が列（Column）をなすように格納されるテーブルの形式で保存される。また、データウェアハウス８には、このようなテーブルが複数保存される。サーバー６は、車両関連情報の中から複数のテーマの各々に沿った車両関連情報がテーマ毎に抽出されてなるテーブルを、テーマ毎に生成する。また、データウェアハウス８は、サーバー６で生成された複数のテーブルを個別に記憶する。

【0030】

各々のテーブルに保存される情報の要素の種類や数は、テーブル毎に相違する。また、各々のテーブルの更新頻度（時間あたりの更新回数）や更新時機（更新タイミング）についても、テーブル毎に相違する。一方、テーブル毎に相違する更新頻度や更新時機の情報は、デバイスプラットフォーム２から送信される情報に含まれている訳ではなく、各テーブルの利活用の目的や用途に応じて決定されるべき情報である。そこで、本実施例のサーバー６は、更新頻度や更新時機を表す属性情報を各テーブルに付加した上で、各テーブルをデータウェアハウス８に保存する。つまり、サーバー６で生成される複数のテーブルの各々は、固有のテーマに沿って集積された車両関連情報の集合となっており、複数のテーマの各々は、当該テーマ毎に抽出される車両関連情報の更新頻度又は更新時機に基づいて分類される。

【0031】

［２．テーブル］
図３は、データウェアハウス８に保存されるテーブルの具体例と各テーブルの構造とを例示する表である。表中の一行がデータウェアハウス８に保存されるひとつのテーブルを表し、合計で２７個のテーブルが例示されている。ひとつのテーブルには、テーブル毎に異なる複数の情報の要素が行列状に保存される。また、各テーブルには、そのテーブルの更新時機の違いを表す「第一属性」の情報と、そのテーブルの更新頻度の違いを表す「第二属性」の情報とが付加される。

【0032】

第一属性には、識別系と状態系と操作系とが含まれる。
識別系とは、車両１０を識別するための情報が格納されるテーブルに付加される属性である。車両１０を識別するための情報は、基本的には変化しない情報であって、その車両１０に固有の情報である。したがって、識別系のテーブルは、車両１０の製造時やメンテナンスにより主要な車載機器（例えば、車載通信装置１１）が交換された時にのみ更新される。

【0033】

状態系とは、車両１０の状態を表す情報が格納されるテーブルに付加される属性である。車両１０の状態を表す情報の変化は、着目する対象に応じて相違し、短時間で大きく変化するものもあれば、長い時間をかけて緩慢に変化するものもある。そこで、状態系のテーブルは、テーブル毎に定められた所定のインターバル（例えば、時間間隔や走行距離間隔等）をあけて定期的に更新される。

【0034】

操作系とは、車両１０に対する運転操作に関する情報が格納されるテーブルに付加される属性である。運転操作に関する情報の変化も、着目する対象に応じて相違し、車両１０の走行中に時々刻々と変化するものもあれば、車両１０の始動時や駐車時にしか変化しないものもある。そこで、操作系のテーブルは、テーブル毎に定められた所定の操作がなされた時に随時更新される。

【0035】

第二属性には、マスター型とサマリー型と履歴型とトランザクション型とが含まれる。
マスター型とは、車両１０及び車載通信装置１１が製造された際に付与される情報が格納されるテーブルに付加される属性である。したがって、マスター型のテーブルは、車両１０の製造時やメンテナンスにより主要な車載機器（例えば、車載通信装置１１）が交換された時にのみ更新される。なお、本実施例では識別系及びマスター型が等価であり、第一属性が識別系であるテーブルのみが第二属性にマスター型を有し、第二属性がマスター型であるテーブルのみが第一属性に識別系を有する。

【0036】

サマリー型とは、車両関連情報を所定期間毎に要約した情報や集計した情報が格納されるテーブルに付加される属性である。以下、このような情報のことを要約集計情報と呼ぶ。要約集計情報には、例えば所定期間の終了時における数値の情報や、所定期間の総計の情報や、所定期間の平均の情報等が含まれる。サマリー型のテーブルは、基本的には第一属性が状態系のテーブル群に含まれる。第一属性が状態系のテーブル群のうち、車両関連情報の要約集計情報に価値があるとみなされる情報を含むものに、サマリー型という第二属性が付与される。サマリー型のテーブルは、テーブル毎に定められる所定期間毎に更新される。ここでいう所定期間の具体例としては、例えば１トリップ（メインスイッチやイグニッションスイッチが投入されてから切断されるまでの期間を一単位とした運行状態），一日，一週間，一月といった比較的長いインターバルが挙げられる。

【0037】

履歴型とは、車両関連情報の履歴に関する情報が格納されるテーブルに付加される属性である。履歴型のテーブルには、状態系に含まれるものと操作系に含まれるものとがある。前者は車両１０の過去の状態を表す情報が格納されるテーブルであり、後者は車両１０に対する過去の運転操作に関する情報が格納されるテーブルである。図３に示すように、履歴型のテーブルの各々には、そのテーブルに対応するトランザクション型のテーブルが存在する。履歴型のテーブルの更新頻度は、少なくともそのテーブルに対応するトランザクション型のテーブルの更新頻度以下になるように設定される。例えば、あるトランザクション型のテーブルが数回更新される毎に、そのテーブルに対応する履歴型のテーブルが更新されるようになっている。

【0038】

トランザクション型とは、車両関連情報のうち車両１０の最新の状態を表す情報が格納されるテーブルに付加される属性である。履歴型のテーブルと同様に、トランザクション型のテーブルには、状態系に含まれるものと操作系に含まれるものとがある。前者は車両１０の最新の状態を表す情報が格納されるテーブルであり、後者は車両１０に対する最新の運転操作に関する情報が格納されるテーブルである。トランザクション型のテーブルの更新頻度は、テーブル毎に定められる所定時間毎に更新される。ただし、ここでいう所定時間は、サマリー型のテーブルが更新される所定期間よりも短い時間（例えば、数秒～数分といった比較的短いインターバル）である。

【0039】

表１は、テーブルの第二属性と更新頻度及び演算負荷（システムリソース）との関係を示すものである。テーブルの更新頻度は、サマリー型よりも履歴型が高く設定される。また、トランザクション型の更新頻度は、履歴型よりも高いか履歴型と同一に設定される。つまり、演算負荷が比較的低い履歴型やトランザクション型の更新頻度が高めに設定されるのに対し、演算負荷が比較的高いサマリー型の更新頻度は低めに設定される。なお、マスター型の演算負荷は低く、更新頻度はサマリー型よりも低い。

【0040】

【表1】

【0041】

図３に示す表の内容について詳述する。表中の第一列はテーブル名（テーブルの名称であって、そのテーブルのテーマ）を表す。また、第二列は第一属性を表し、第三列は第二属性を表す。以下、便宜的にテーブル名に括弧を付して表記する。

【0042】

「車両基本」は、車両１０の基本情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，型式等が挙げられる。第一属性は識別系であり、第二属性はマスター型である。
「車両登録」は、テレマティクスサービスが提供される車両１０のユーザーを特定するための情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，ユーザーＩＤ等が挙げられる。第一属性は識別系であり、第二属性はマスター型である。

【0043】

「ＴＣＵ」は、車両１０に搭載されるＴＣＵの情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，ＴＣＵのシリアル番号等が挙げられる。第一属性は識別系であり、第二属性はマスター型である。
「ヘッドユニット」は、車両１０に搭載されるヘッドユニットの情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，ヘッドユニットのシリアル番号等が挙げられる。第一属性は識別系であり、第二属性はマスター型である。

【0044】

「日別親」は、以下に説明する３つのデイリーサマリーテーブルの親テーブルである。デイリーサマリーテーブルとは、一日毎の車両関連情報をまとめた要約集計情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，履歴を更新した日付等が挙げられる。
「日別車両」は、デイリーサマリーテーブルのひとつであり、走行状態に関する要約集計情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，総走行距離（日報）等が挙げられる。第一属性は状態系であり、第二属性はサマリー型である。

【0045】

「日別タイヤ」は、デイリーサマリーテーブルのひとつであり、タイヤに関する要約集計情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，タイヤ圧（日報）等が挙げられる。第一属性は状態系であり、第二属性はサマリー型である。
「日別警告」は、デイリーサマリーテーブルのひとつであり、車載機器が発報した各種警告に関する情報（ダイアグノーシス情報）が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，警告種別の日報等が挙げられる。第一属性は状態系であり、第二属性はサマリー型である。

【0046】

「車両位置履歴」は、車両１０の位置に関する履歴情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，緯度・経度（履歴），車速（履歴）等が挙げられる。第一属性は状態系であり、第二属性は履歴型である。
「車両状態履歴」は、走行状態に関する履歴情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，総走行距離（履歴）等が挙げられる。第一属性は状態系であり、第二属性は履歴型である。

【0047】

「車両タイヤ履歴」は、タイヤに関する履歴情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，タイヤ圧（履歴）等が挙げられる。第一属性は状態系であり、第二属性は履歴型である。
「車両警告履歴」は、車両識別番号と、車載機器が発報した各種警告に関する履歴情報とが格納されるテーブルである。第一属性は状態系であり、第二属性は履歴型である。

【0048】

「ＥＶデータ履歴」は、電動車両（電気自動車，ハイブリッド自動車）を対象としてＥＶ（Electric Vehicle）走行に関する履歴情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，駆動用バッテリーの残充電量（履歴）等が挙げられる。第一属性は状態系であり、第二属性は履歴型である。

【0049】

「ドア状態履歴」は、ドアの状態に関する履歴情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，ドアの開閉状態（履歴）等が挙げられる。第一属性は操作系であり、第二属性は履歴型である。
「ライト状態履歴」は、ライトの状態に関する履歴情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，ライトの点等状態（履歴）等が挙げられる。第一属性は操作系であり、第二属性は履歴型である。

【0050】

「シートベルト状態履歴」は、シートベルトの状態に関する履歴情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，シートベルトが装着されているか否かの装着情報（最新）等が挙げられる。第一属性は操作系であり、第二属性は履歴型である。
「トリップ履歴」は、車両１０のトリップに関する履歴情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，トリップ開始から終了までの走行距離（履歴）等が挙げられる。第一属性は操作系であり、第二属性は履歴型である。

【0051】

「車両位置」は、車両１０の位置に関する最新情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，緯度・経度（最新），車速（最新）等が挙げられる。第一属性は状態系であり、第二属性はトランザクション型である。
「車両状態」は、走行状態に関する最新情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，総走行距離（最新）等が挙げられる。第一属性は状態系であり、第二属性はトランザクション型である。

【0052】

「車両タイヤ」は、タイヤに関する最新情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，タイヤ圧（最新）等が挙げられる。第一属性は状態系であり、第二属性はトランザクション型である。
「車両警告」は、車両識別番号と、車載機器が発報した各種警告に関する最新情報とが格納されるテーブルである。第一属性は状態系であり、第二属性はトランザクション型である。

【0053】

「ＥＶデータ」は、電動車両を対象としてＥＶ走行に関する最新情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，駆動用バッテリーの残充電量（最新）等が挙げられる。第一属性は状態系であり、第二属性はトランザクション型である。
「充電イベントリスト」は、電動車両を対象として、車両識別番号と、バッテリーの充電状態に関する最新情報とが格納されるテーブルである。第一属性は状態系であり、第二属性はトランザクション型である。

【0054】

「ドア状態」は、ドアの状態に関する最新情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，ドアの開閉状態（最新）等が挙げられる。第一属性は操作系であり、第二属性はトランザクション型である。
「ライト状態」は、ライトの状態に関する最新情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，ライトの点等状態（最新）等が挙げられる。第一属性は操作系であり、第二属性はトランザクション型である。

【0055】

「シートベルト状態」は、シートベルトの状態に関する最新情報が格納されるテーブルである。このテーブルに格納される情報例としては、シートベルトが装着されているか否かの装着情報（最新）等が挙げられる。第一属性は操作系であり、第二属性はトランザクション型である。
「トリップイベントリスト」は、車両１０のトリップに関する最新情報が格納されるテーブルである。このテーブルに格納される情報例としては、車両識別番号，トリップ開始から終了までの走行距離（最新）等が挙げられる。第一属性は操作系であり、第二属性はトランザクション型である。

【0056】

テーブルの属性同士の関係について、識別系のテーブルはマスター型であり、マスター型のテーブルは識別系である。また、状態系のテーブルには、サマリー型と履歴型とトランザクション型とが含まれる。一方、操作系のテーブルには、履歴型とトランザクション型とが含まれる。本実施例では操作系のテーブルにトランザクション型のテーブルが含まれていないが、このようなテーブルを設けてもよい。

【0057】

［３．効果］
（１）上記のコネクティッドデータプラットフォーム５は、少なくとも車載通信装置１１から送信される複数の車両関連情報を管理する情報管理システムであって、サーバー６（情報処理手段）とデータウェアハウス８（記憶手段）とを備える。サーバー６は、車両関連情報の中から複数のテーマの各々に沿った車両関連情報がテーマ毎に抽出されてなるテーブルを、テーマ毎に生成する。データウェアハウス８は、複数のテーブルを個別に記憶する。複数のテーマの各々は、そのテーマ毎に抽出される車両関連情報の更新頻度又は更新時機に基づいて分類される。

【0058】

上記の通り、複数の車両関連情報（自動車のビッグデータ）の管理に際し、テーマ毎に異なる複数のテーブルを生成することで、車両関連情報をその利活用の目的及び用途に適した形に整理することができ、車両関連情報の利便性を向上させることができる。したがって、効率よくデータの利活用を促進できる。また、各テーマは、個々の車両関連情報の更新頻度又は更新時機に基づいて分類されているため、更新された車両関連情報を含むテーブルのみを変更すればよく、更新されていない車両関連情報のみを含むテーブルを変更する必要がない。これにより、各テーブルを効率よく更新することができ、サーバー６の演算処理負荷を軽減できる。

【0059】

（２）データウェアハウス８が記憶する複数のテーブルの各々は、更新時機の違いを表す第一属性を有する。図３に示すように、第一属性は、識別系と状態系と操作系とを含む。識別系とは、車両１０を識別するための情報が格納されるテーブルに付加される属性である。状態系とは、車両１０の状態を表す情報が格納されるテーブルに付加される属性である。操作系とは、車両１０に対する運転操作に関する情報が格納されるテーブルに付加される属性である。

【0060】

第一属性に基づくテーブルの分類により、各テーブルを更新するタイミングが明確になる。例えば、識別系のテーブルは、車両１０が製造された時点でその車両１０の車両関連情報を登録しておけば、その後に主要な車載機器（例えば、車載通信装置１１）が交換されない限り、再登録の必要がない。また、操作系のテーブルは、運転操作がなされていない車両１０については更新が不要である。状態系のテーブルは、所定のインターバルで更新すればよく、前回の更新時刻から所定のインターバルが経過していなければ更新が不要である。したがって、各テーブルを効率よく更新することができ、サーバー６の演算処理負荷を軽減できる。

【0061】

また、第一属性に基づくテーブルの分類により、車両関連情報をその利活用の目的及び用途に応じて素早く取り出すことが可能となる。例えば、フリートサービス，アフターセールス，スマートシティへの活用，開発や商品企画へのフィードバックなど、利用目的に応じて適切な車両関連情報を容易に抽出することができる。したがって、データの利活用をさらに促進できる。

【0062】

（３）データウェアハウス８が記憶する複数のテーブルの各々は、更新頻度の違いを表す第二属性を有する。図３に示すように、第二属性は、サマリー型と履歴型とトランザクション型とを含む。サマリー型とは、車両関連情報を所定期間毎に要約又は集計した情報が格納されるテーブルに付加される属性である。履歴型とは、車両関連情報の履歴に関する情報が格納されるテーブルに付加される属性である。トランザクション型とは、車両関連情報のうち車両１０の最新の状態を表す情報が格納されるテーブルに付加される属性である。

【0063】

第二属性に基づくテーブルの分類により、車両関連情報をその利活用の目的及び用途に応じて素早く取り出すことが可能となる。例えば、車両１０の大局的な操作状況や運転傾向等を把握したい場合には、サマリー型のテーブルのみを参照すればよい。一方、操作状況や運転傾向等を詳細に分析したい場合には、履歴型のテーブルを参照すればよく、更に分析精度を高めたい場合には、トランザクション型のテーブルも考慮すればよい。このように、利活用の目的及び用途に応じて適切な車両関連情報を容易に抽出することができる。したがって、データの利活用をさらに促進できる。

【0064】

（４）第二属性に係るテーブルの更新頻度は、サマリー型よりも履歴型が高く設定される。また、トランザクション型のテーブルの更新頻度は、履歴型のテーブルの更新頻度以上になるように設定される。言い換えれば、サマリー型のテーブルの更新頻度は、履歴型やトランザクション型のテーブルの更新頻度よりも低く設定される。このように、演算負荷が比較的高いサマリー型のテーブルの更新頻度を低くすることで、サーバー６の演算処理負荷を軽減できる。また、履歴型やトランザクション型のテーブルは演算負荷が比較的低いため、更新頻度を高めたとしてもサーバー６の負荷に大きな影響を与えにくい。したがって、サーバー６の総合的な演算処理負荷を軽減しつつ、テーブルの総合的な更新頻度を高めることができる。

【0065】

（５）図３に示すように、第二属性は、車両１０が製造された際に付与される情報が格納されるテーブルに付加されるマスター型を含む。マスター型のテーブルの更新頻度は、サマリー型のテーブルよりも低く設定される。このように、基本的には変化しない情報をまとめてマスター型のテーブルに格納することで情報の更新回数を削減でき、サーバー６の演算処理負荷を軽減できる。

【0066】

［４．その他］
上記の実施例はあくまでも例示に過ぎず、本実施例で明示しない種々の変形や技術の適用を排除する意図はない。本実施例の各構成は、それらの趣旨を逸脱しない範囲で種々変形して実施できる。また、本実施例の各構成は必要に応じて取捨選択でき、あるいは、適宜組み合わせることができる。

【0067】

例えば、上記の実施例では、サーバー６とデータレイク７とデータウェアハウス８とが設けられたコネクティッドデータプラットフォーム５を例示したが、データレイク７は必須の要素ではなく適宜省略可能である。また、サーバー６は、コネクティッドデータプラットフォーム５上に設けられたものであってもよいし、そうでなくてもよい。サーバー６は、少なくともデータウェアハウス８にアクセス可能な状態で、ネットワーク１上に物理的又は仮想的に存在するものであればよい。

【0068】

また、上記の実施例では、データウェアハウス８に保存されるテーブルが第一属性及び第二属性を有する場合について詳述したが、第一属性及び第二属性を持たないテーブルをデータウェアハウス８に保存してもよい。データウェアハウス８に保存されるテーブルは、少なくとも複数のテーマの各々に沿った車両関連情報がテーマ毎に抽出されてなるテーブルであればよく、かつ、複数のテーマの各々が、テーマ毎に抽出される車両関連情報の更新頻度又は更新時機に基づいて分類されるものであればよい。

【0069】

なお、データウェアハウス８に保存されるテーブルは、第一属性のみを有するものであってもよいし、第二属性のみを有するものであってもよい。また、第一属性は、識別系と状態系と操作系との何れか一つ以上を有するものであってもよい。同様に、第二属性は、マスター型とサマリー型と履歴型とトランザクション型との何れか一つ以上を有するものであってもよい。

【産業上の利用可能性】

【0070】

本件は、車両に搭載される車載通信装置から送信される複数の車両関連情報を管理する情報管理システムの製造業や情報管理システムによるサービス業に広く適用可能である。また、本件は車両運行管理システム，自動運転システム，カーナビゲーションシステム，自動充電管理システム，交通管理システム，運転技術評価システム等とも融合可能であり、多種多様な車両用システムに係る産業上の利用可能性を持つ。

【符号の説明】

【0071】

１ ネットワーク
２ デバイスプラットフォーム
３ 第一ストレージ
４ 第二ストレージ
５ コネクティッドデータプラットフォーム（情報管理システム）
６ サーバー（情報処理手段）
７ データレイク
８ データウェアハウス（記憶手段）
９ 顧客サーバー
１０ 車両
１１ 車載通信装置
１２ 携帯端末
１３ 工場
１４ サプライヤー
２０ 処理装置
２１ プロセッサー
２２ メモリー
２３ 通信装置
２４ 記憶装置

【図1】

【図2】

【図3】