特開 2024-39283 車載設備及びログ収集システム

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

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

(11)【公開番号】P2024039283

(43)【公開日】2024-03-22

(54)【発明の名称】車載設備及びログ収集システム

(51)【国際特許分類】

   G06F 11/34 20060101AFI20240314BHJP

【ＦＩ】

G06F11/34 176

【審査請求】未請求

【請求項の数】12

【出願形態】ＯＬ

(21)【出願番号】P 2022143721

(22)【出願日】2022-09-09

(71)【出願人】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(71)【出願人】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】100092772

【弁理士】

【氏名又は名称】阪本 清孝

(74)【代理人】

【識別番号】100119688

【弁理士】

【氏名又は名称】田邉 壽二

(72)【発明者】

【氏名】樫原 俊太郎

(72)【発明者】

【氏名】大岸 智彦

(72)【発明者】

【氏名】伊藤 雅典

(72)【発明者】

【氏名】大野 允裕

(72)【発明者】

【氏名】吉田 琢也

(72)【発明者】

【氏名】本江 政司

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

5B042

【Ｆターム（参考）】

5B042GA21

5B042GB08

5B042MA08

5B042MC35

5B042MC40

(57)【要約】

【課題】ソフトウェア挙動の観点から信頼性解析につなげることのできるログを収集する車載設備を提供する。
【解決手段】OS（オペレーティングシステム）上で実行される、車載機器を制御するアプリ（アプリケーション）を実行する車載設備100であって、前記アプリが取得するアプリログ情報を含む属性情報を、前記OSが取得するOSログ情報と紐づけて収集する。前記属性情報に含まれる情報として、アプリログの取得時刻と、OSログの取得時刻と、前記車載設備を搭載している車両の識別子の情報と、前記OSを実行するコンピュータの構成情報である、プロセッサ、メモリ及びストレージの全部または一部に関する情報とを収集してもよい。
【選択図】図２

【特許請求の範囲】

【請求項1】

OS（オペレーティングシステム）上で実行される、車載機器を制御するアプリ（アプリケーション）を実行する車載設備であって、
前記アプリが取得するアプリログ情報を含む属性情報を、前記OSが取得するOSログ情報と紐づけて収集することを特徴とする車載設備。

【請求項2】

前記属性情報に含まれる情報として、前記アプリログ情報の構成要素である個別のアプリログの取得時刻を収集し、前記OSログ情報に含まれる情報として、前記OSログ情報の構成要素である個別のOSログの取得時刻を収集することを特徴とする請求項１に記載の車載設備。

【請求項3】

前記アプリログの取得時刻に対して近傍時間範囲にある前記OSログの紐づけを行って収集することを特徴とする請求項２に記載の車載設備。

【請求項4】

前記属性情報に含まれる情報として、前記車載設備を搭載している車両の識別子の情報を収集することを特徴とする請求項１に記載の車載設備。

【請求項5】

前記属性情報に含まれる情報として、前記アプリが制御する車載機器に関する情報を収集することを特徴とする請求項１に記載の車載設備。

【請求項6】

前記属性情報に含まれる情報として、前記アプリの種別を特定する情報を収集することを特徴とする請求項１に記載の車載設備。

【請求項7】

前記属性情報に含まれる情報として、前記OSの種類及び／又はバージョンに関する情報を収集することを特徴とする請求項１に記載の車載設備。

【請求項8】

前記属性情報に含まれる情報として、前記OSを実行するコンピュータの構成情報である、プロセッサ、メモリ及びストレージの全部または一部に関する情報を収集することを特徴とする請求項１に記載の車載設備。

【請求項9】

前記アプリが生成するアプリログ情報として、当該アプリにおけるソフトウェア動作状態の情報を収集することを特徴とする請求項１に記載の車載設備。

【請求項10】

前記OSログ情報を、OSのカーネルレベルでのトレーシングデータとして、CPU（中央演算装置）の処理滞留時間及び占有率、メモリのエラー発生有無、ストレージの読み書き速度、並びに、ネットワークによる通信有無及びセッション情報、の全部または一部を含めて収集することを特徴とする請求項１に記載の車載装置。

【請求項11】

複数の車両の各々に備わる請求項１に記載の車載設備と、
当該複数の車載設備の各々から、前記紐づけられて取得されている属性情報及びOSログ情報を収集して、データベースを構築する監視装置と、を含むことを特徴とするログ収集システム。

【請求項12】

前記監視装置は、前記データベースに対する検索要求を受け付け、検索結果を返信することを特徴とする請求項１１に記載のログ収集システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ソフトウェア挙動の観点から信頼性解析につなげることのできるログを取得する車載設備及びログ収集システムに関する。

【背景技術】

【0002】

車両、船舶、航空機といったような移動体の信頼性に関する既存技術として、例えば特許文献１（「自律型航空機の正常性システムと方法」）がある。

【0003】

特許文献１では、自律飛行する航空機の正常性を判断するため、一部遠隔サーバと連携した動作を行う。例えば、センサで取得される航空機に関する動作条件から、エンジン劣化等を判定するが、単独で動作する構成であり、複数の航空機から収集したデータや、長期にわたるデータの蓄積からの判別には対応していない。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特表2020-523596号公報

【発明の概要】

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

【0005】

近年、例えば自律運転を目指す車両において、例えば車両周辺を監視するためのカメラ等の様々な車載機器に関して、車載設備のコンピュータで実行されるOS（オペレーティングシステム）の下で稼働するソフトウェアによる制御が行われている。ここで、車両等の移動体の信頼性を確保するために、ソフトウェア挙動の観点から、十分なログを解析可能な形で確保しておくことにより、異常などが発生しうる状況の事前検出や分析等の信頼性解析につなげることが望まれるが、従来技術ではこのような枠組みでの取り組みは行われていなかった。

【0006】

例えば特許文献１は、単独の航空機の信頼性に関して、予め既知の劣化や異常に関する判定基準と照らし合わせることで判断する手法であった。特許文献１の手法では、多数の航空機から解析可能な形でログを収集することはできず、ソフトウェア挙動の観点から、発生しうる異常等の事前検出等を目指すこともできなかった。

【0007】

上記従来技術の課題に鑑み、本発明は、ソフトウェア挙動の観点から信頼性解析につなげることのできるログを収集する車載設備を提供することを目的とする。

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

【0008】

上記目的を達成するため、本発明は、OS（オペレーティングシステム）上で実行される、車載機器を制御するアプリ（アプリケーション）を実行する車載設備であって、前記アプリが取得するアプリログ情報を含む属性情報を、前記OSが取得するOSログ情報と紐づけて収集することを特徴とする。

【発明の効果】

【0009】

本発明によれば、アプリログ情報を含む属性情報をOSログ情報と紐づけて収集することにより、OSログ情報の検索キーとして属性情報が利用可能となることから、ソフトウェア挙動の観点から信頼性解析につなげることのできるログを収集することができる。

【図面の簡単な説明】

【0010】

【図1】一実施形態に係るログ収集システムの構成図である。

【図2】一実施形態に係るログ収集システムの機能ブロック図である。

【図3】車載機能部において実現されるOSと車載アプリとの階層構造と、車載アプリが制御する車載機器との関係を模式的に示す図である。

【図4】一実施形態に係るログ収集システムの動作のフローチャートである。

【図5】ログ収集部で収集する整形されたログ情報の構成図である。

【図6】OSログの取得時刻とアプリログの取得時刻との関係例を表す模式図である。

【図7】一般的なコンピュータにおけるハードウェア構成の例を示す図である。

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

【0011】

図１は、一実施形態に係るログ収集システム50の構成図であり、ログ収集システム50は、任意数のN台に渡る自動車等の車両10-1,10-2,…,10-Nと、これらの車両10-1,10-2,…,10-Nの各々からモバイルネットワーク等のネットワークNWを介してログを収集するサーバとしての監視装置20と、この監視装置20にネットワーク等を介してアクセス可能なサーバとしての分析装置30と、を備える。

【0012】

図２は、一実施形態に係るログ収集システム50の機能ブロック図である。図２にて車両10は、図１のN台の車両10-1,10-2,…,10-Nの任意の１台として、これらの共通構成を示しており、車両10はコンピュータ装置としての車載設備100を備え、車載設備100は機能ブロック構成として車載機能部11と、ログ収集部12と、車両側保存部13と、を備える。これら各部の機能の概要は以下の通りである。

【0013】

車載機能部11は、CPU等のプロセッサが所定のプログラムを実行することによって実現されるものであり、本実施形態では所定のOS（オペレーティングシステム）が実行されることによる機能と、当該OSの管理下でさらに実行される車載アプリ（ソフトウェア）の機能と、をこの車載機能部11が担う。車載アプリは車載機器Dの制御処理を担う。ログ収集部12は車載機能部11からログを収集して、所定形式で整形したログを、記憶媒体である車両側保存部13に保存する。

【0014】

サーバ側保存部21及び検索部22を備える監視装置20では、N台の車両10-1,10-2,…,10-Nの各々の車両側保存部13に保存されているログを収集して、記憶媒体であるサーバ側保存部21に保存し、データベースを構築する。受付部31及び表示部32を備える分析装置30では、ログ分析を行うユーザからのログ検索の入力を受付部31において受け付け、ログ検索の要求を監視装置20へと送信し、検索部22がデータベースであるサーバ側保存部21から、当該要求されたログ検索条件に従った検索を行って検索結果を得て分析装置30へと返信し、表示部32においてこの返信された検索結果を表示する。

【0015】

図３に、車載機能部11において実現されるOSと車載アプリとの階層構造と、車載アプリが制御する車載機器との関係を模式的に示す。CPUがOSに対応するプログラムを実行することで、OSの機能が実現され、この機能には当該OSレベルでのログ生成機能が含まれる。当該OSの管理下で、CPUが所定プログラムを実行することでn個の車載アプリAPk(k=1,2,…n)の機能が実現され、各車載アプリAPkの機能には、当該アプリレベルでのログ生成機能が含まれる。各車載アプリAPkは、対応する所定の車載機器Dk(k=1,2,…,n)を制御する機能を担うものである。

【0016】

車載機器Dkの各々は、車両10における運転関連の機能を担う任意の機器であってよく、例えば、運転に関連ないし付随した車両10の周辺環境のセンシングを担う機器として、LiDAR（光検出と測距、レーザー画像検出と測距）センサあるいは通常のRGB画像の撮影を行うカメラ等であってもよいし、車両10の外部あるいは内部を点灯するライトであってもよいし、車両10の乗員に各種のコンテンツその他の情報提供を行うディスプレイやスピーカーであってもよい。なお、図３の例では、１つの車載アプリAPkが１つのみの対応する車載機器Dkを制御する場合が例として示されているが、１つの車載アプリが２つ以上の車載機器を制御するように構成されていてもよい。（なお、車載機器Dk及び車載アプリAPkは、車両10をインテリジェント化やコネクテッド化する等により付加価値を提供することに関連したものであればよい。一方で、本発明の車載機器Dk及び車載アプリAPkは、安全性に直接関わるものは扱わない。例えば、手動運転の際の衝突事故等についての事象を解析するのに用いられるEDR（イベント・データ・レコーダ）等ではエンジン回転数、ブレーキペダル操作状況、アクセルペダル操作状況等のような安全性に直接関わるものを記録しているが、本発明の車載機器Dk及び車載アプリAPkはこうした安全性に直接関わるものを扱わない。）

【0017】

また、変形例として、車載機器Dkを制御する車載アプリAPkの全部または一部が、メインOSとは別途のサブOS上において、メインOSが実行されるプロセッサとは別のプロセッサで実行されるものであってもよい。この場合、サブOSはサブOSのログ生成機能を担い、車載アプリAPkは自身のログ生成機能を担い、これらのサブOSのログと車載アプリAPkのログとを収集すればよく、図３括弧内に示されるように、メインOS上で実行されるログ収集アプリAP'kにおいてこれらを収集するようにしてもよい。メインOSはドメインECU（電子制御ユニット）によって実行されるものであってよく、サブOSはこのドメインECUが束ねる複数の小型ECUの各々において実行されるものであってもよい。（なお、図３括弧内に示されるように１つのサブOS(k)上では１つのみのアプリAPkが実行されるように構成することができる。）

【0018】

図４は、一実施形態に係るログ収集システム50の動作のフローチャートである。ステップS1では、N台の車両10-1,10-2,…,10-Nの各々において、その車載設備100でOSログとアプリログとを常時、取得し、これらログを紐づけて保存しておき、定期的に、当該紐づけて保存したログ情報を監視装置20へと送信する。ステップS2では、ステップS1において定期的にN台の車両10-1,10-2,…,10-Nの各々から送信されたログを保存することでデータベースを更新して管理している監視装置20に対して、ユーザが分析装置30よりログ検索の要求を行うことで、分析装置30に対してログ検索の結果を返信する。

【0019】

なお、図４のステップS1におけるログ収集は、各々の車両10の車載設備100が稼働している状態において常時、実行するようにしてよく、収集したログの監視装置20への送信は、例えば１日１回夜間帯にアップロードする等により、定期的に実行することができる。このステップS1での常時ログ収集と定期的なログ送信とを前提として、ステップS2の検索処理は、分析装置30を利用するユーザが所望する任意のタイミングで実行することができる。

【0020】

以下、ステップS1におけるログ収集の詳細（ログ収集部12の詳細）を説明する。

【0021】

ログ収集部12では、OSカーネルレベルの情報（CPU、メモリ、ストレージ、通信）をトレースしたOSログ情報に、車載設備のパーツ構成や、動作中のソフトウェアの種別や状態などを属性情報として付加することで、整形されたログ情報を取得し、車両側保存部13に保存する。

【0022】

図５は、ログ収集部12で収集する整形されたログ情報の構成図であり、図５に示されるように、OSカーネルレベルのトレーシングデータであるOSログ情報に対して、属性情報として、車両識別子と、取得時刻と、車載設備のパーツ構成等に関する構成情報と、アプリの状態が記述されるアプリログ情報とを紐づけることにより、整形されたログ情報を得ることができる。

【0023】

車両識別子については、OSに記録されている所定の車両識別子を用いればよく、OS識別子（車載設備100のMAC（Media Access Control）アドレス等）で代用するようにしてもよい。

【0024】

なお、以下にも説明する通り、OSログ情報とアプリログ情報とに関しては、共に、所定のイベントが発生した場合に不定期に、あるいは、何らかの情報を定期的に記録しておくものとして、取得されるものである。用語として、「OSログ情報」とは、個別要素としての「OSログ」の集合を意味し、「アプリログ情報」とは、個別要素としての「アプリログ」の集合を意味するものとする。すなわち、様々な取得時刻において様々な種類の情報が取得される個別の「OSログ」を集めた全体が「OSログ情報」を構成し、同様に、様々な取得時刻において様々な種類の情報が取得される個別の「アプリログ」を集めた全体が「アプリログ情報」を構成するものとする。

【0025】

取得時刻（タイムスタンプ）については、OSログの取得時刻と、アプリログの取得時刻とを含めるようにすればよい。図６は、OSログの取得時刻とアプリログの取得時刻との関係例を示す模式図であり、図６に示されるように、OSログはCPU、メモリ、ストレージ、通信等の使用量に対して一般に、OSの処理タイミングの各時刻t=1,2,3,…において定期的に取得することができ、一方でOSログのうち一部分として例えばネットワークのセッション情報（通信元と通信先のペア情報）やメモリのエラー情報は不定期に取得されるのに対して、アプリログは一般に、OS処理タイミングの各時刻t=1,2,3,…上において、ログ生成条件が満たされた際に、不定期に、離散的な時刻（例えばt=100,301,905,…などのように離散的に）に取得される挙動を示す。（なお、アプリログについても例えば１時間ごとに生成するといったように、定期的に取得されるものがあってもよい。なお、不定期なアプリログのうちの１つに、不定期なOSログ（例えばメモリのエラー情報）と結果的に連動して取得される挙動を示すものがあってもよい。）

【0026】

従って、定期的なOSログについては各時刻t=1,2,3,…の全てについて保存しておく実施形態以外にも、不定期なアプリログや不定期なOSログが発生した時刻の近傍範囲の時刻についてのみ、保存しておくようにしてもよい。図６の例ではある時刻t=T1でアプリログAL1が発生した際に、これに紐づけて保存するOSログとして、この近傍範囲R1={t|T1-W1≦t≦T1+W1}(W1>0は定数)のみを保存するようにしてよく、同様に、ある時刻t=T2でアプリログAL2が発生した際に、これに紐づけて保存するOSログとして、この近傍範囲R2={t|T2-W2≦t≦T2+W2}(W2>0は定数)のみを保存するようにしてよい。また、近傍範囲のみを保存することで近傍範囲外は削除することに代えて、不定期なアプリログとその発生時刻に対して、近傍範囲のOSログを紐づけて保存する（近傍範囲外のOSログについても保存されるが、このアプリログ及びその発生時刻との紐づけは行われていない状態で保存する）ようにしてもよい。また、近傍範囲の紐づけを行わない場合であっても、アプリログの取得時刻tと同一時刻tのトレーシングデータ（OSログ情報）を紐づけることで、分析装置30を利用するユーザが属性情報で検索した際に、アプリログの取得時刻tと同一時刻tのトレーシングデータを参照可能となり、当該ユーザは必要に応じて、この時刻tの近傍範囲でのトレーシングデータの挙動を自ら確認するといった分析作業が可能となる。

【0027】

アプリログに対応付けて保存しておくOSログの時間範囲は、アプリログの種別に応じた範囲としてよい。例えば、正常挙動を示すアプリログについては、比較的短い時間範囲でのOSログを紐づけて保存し、異常挙動を示すアプリログについては、比較的長い時間範囲でのOSログを紐づけて保存するようにしてもよい。さらに、このようにアプリログに紐づけて保存するOSログの時間範囲は、図３の模式例で示したような、アプリAPk(k=1,2,…,n)の種別kに応じた所定範囲としてもよい。

【0028】

車載設備のパーツ構成等に関する構成情報については、図３の模式例で示したように、アプリAPk(k=1,2,…,n)の種別kに応じて、このアプリAPkが制御処理を担当する車載機器Dk（例えばカメラ等）の構成情報を用いるようにしてよく、この情報はアプリAPkに対する事前設定の情報として取得することができる。

【0029】

また、この構成情報にはさらに、当該アプリログを生成したアプリAPk(k=1,2,…,n)の種別kの情報と、アプリAPkを動作させているOSの種類及び／又はバージョンに関する情報や、車載設備100を構成するコンピュータ構成情報として、CPU、メモリ、ストレージの性能や種別を含めるようにしてもよい。

【0030】

アプリログの情報は、ログとして出力される直接のテキスト情報を含めてもよいし、所定のエラーコード等の形式で、アプリのソフトウェアの動作状態（正常稼働状態も含む）を予め分類したコード形式で与えるようにしてもよい。

【0031】

OSログ情報としてのトレーシングデータは、OSが提供するカーネルレベルでのトレーシングデータ取得機能により取得すればよい。例えば、車載設備100が、OSとしてLinux（登録商標）が動作するコンピュータで構成されているのであれば、eBPF（extended Berkeley Packet Filter）技術を用いることでOSカーネルレベルのトレースログデータを取得できる。車載設備100がその他の組み込みOS等で実現されている場合も、所定のトレーシングデータ取得機能を用いるようにすればよい。

【0032】

カーネルレベルでのトレーシングデータの内容としては、CPU（処理滞留時間、占有率）、メモリ（エラー発生有無）、ストレージ（読み書き速度）、ネットワーク（通信有無、セッション情報）などの各時刻tにおける情報（これらの情報はeBPF技術により取得可能である）を含めて、トレースログデータを取得すればよい。

【0033】

なお、アプリAPkの種別kに依らずに取得可能な全ての種類のトレーシングデータを取得するようにしてもよいし、以下の２つの例のように、アプリAPkの種別kに応じた所定種類のトレーシングデータを取得するようにしてもよい。
（１） ログを記録するアプリの場合、記録用ストレージの読み書き速度のトレーシングデータ
（２） リアルタイム処理の重要なアプリの場合、CPU処理の滞留時間のトレーシングデータ

【0034】

以上のように、本実施形態による車載設備100のログ収集部12では、OSログとアプリログとを紐づける形でログを保存しておき、多数の車両10において保存されているログを監視装置20で集約してデータベースを構築するので、分析装置30からログ検索を行う場合に、属性情報で絞り込むことで特定車両や特定OSバージョンのみなどの条件に合わせたログ情報を抽出し、信頼性の用途での分析に供することが可能となる。

【0035】

すなわち、車載設備100の構成（CPU、メモリ、ストレージの性能や種別）や、利用しているソフトウェアの動作状態を属性情報として、OSカーネルレベルの挙動のログと紐づける形で記録し、遠隔サーバ（監視装置20）に保管することで、長期間かつ複数の車両から取得したデータ分析を行う際に、属性情報をキーとすることで、条件に合わせた分析用のデータ抽出を行うことができる。車載設備100が正常に稼働していることをOSカーネルレベルでトレースしたログ情報から分析するにあたっては、長期間および複数の車両10から取得したデータ蓄積が前提として必要になると考えられるところ、本実施形態による属性情報の付与により、同一条件で取得したログのみを抽出することが可能となり、特定の構成の車載設備や、特定のアプリケーションのみに関連する分析を行うことができるようになり、ソフトウェア観点での信頼性向上に資することができる。

【0036】

なお、ソフトウェア観点での信頼性向上に関連する分析対象となる状況として例えば、車載機器がLiDARやカメラ等である場合に、想定より多数の特徴点が抽出されることで処理負荷が増え、特徴点抽出後の物体検出処理等の動作安定性が減る状況等がある。本実施形態によればこのような事例についての分析が可能となる。

【0037】

図７は、一般的なコンピュータにおけるハードウェア構成の例を示す図である。ログ収集システム50を構成する車載設備100、監視装置20及び分析装置30の各々は、このような構成を有する１台以上のコンピュータ装置70として実現可能である。なお、２台以上のコンピュータ装置70でログ収集システム50の部分構成を実現する場合、ネットワーク経由で処理に必要な情報の送受を行うようにしてよい。コンピュータ装置70は、所定命令を実行するCPU（中央演算装置）71、CPU71の実行命令の一部又は全部をCPU71に代わって又はCPU71と連携して実行する専用プロセッサとしてのGPU（グラフィックス演算装置）72、CPU71（及びGPU72）にワークエリアを提供する主記憶装置（メモリ）としてのRAM73、補助記憶装置（ストレージ）としてのROM74、通信インタフェース75、ディスプレイ76、マウス、キーボード、タッチパネル等によりユーザ入力を受け付ける入力インタフェース77、車載機器D、とこれらの間でデータを授受するためのバスBSと、を備える。（なお、車載機器Dは車両10に搭載される車載設備100に備わるものであり、監視装置20及び分析装置30では省略される構成であってよい。また、一般的なデスクトップコンピュータで用いるための構成としてのディスプレイ76及び入力インタフェース77は、車載設備100では省略され、１つ以上の車載機器Dにおいて表示機能や入力機能を担うものが実現されていてもよい。）

【0038】

ログ収集システム50の各機能部は、各部の機能に対応する所定のプログラムをROM74から読み込んで実行するCPU71及び／又はGPU72によって実現することができる。なお、CPU71及びGPU72は共に、演算装置（プロセッサ）の一種である。ここで、表示関連の処理が行われる場合にはさらに、ディスプレイ76が連動して動作し、データ送受信に関する通信関連の処理が行われる場合にはさらに通信インタフェース75が連動して動作する。

【0039】

本実施形態のログ収集システム50によれば、車両に情報システムを組み込んでスマート化することに寄与することができるので、国連が主導する持続可能な開発目標（ＳＤＧｓ）の目標９「レジリエントなインフラを整備し、持続可能な産業化を推進するとともに、イノベーションの拡大を図る」に貢献することが可能となる。

【符号の説明】

【0040】

50…ログ収集システム、10…車両、100…車載設備、20…監視装置、30…分析装置、11…車載機能部、D…車載機器、12…ログ収集部、13…車両側保存部、21…サーバ側保存部、22…検索部、31…受付部、32…表示部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】