実施形態のデータ格納装置は車載ネットワークに接続され、車載ネットワーク上の電子制御ユニット(以下、ECUという)などから自発的にデータを取得して蓄積する。車載ネットワークに接続される従来のデータ格納装置は、ホストの命令に従って受動的にデータを格納する構成であるため、ECUなどが出力するデータを蓄積するには、車載ネットワークにホストを接続して使用する必要があった。これに対し、実施形態のデータ格納装置は、従来のホストに相当する機能を内蔵し、車載ネットワークに接続されると自発的に車載ネットワークからデータを取得して蓄積する新規な構成を有する。
ここで、自発的なデータの取得および蓄積とは、外部装置からの書き込み指示などによらずにデータを取得して蓄積すること意味する。自発的なデータの取得および蓄積の一例として、例えば、車載ネットワーク上のECUなどにデータ要求のリクエストメッセージを送信し、このリクエストメッセージに対するレスポンスメッセージを受信して、レスポンスメッセージに含まれるデータを取得して蓄積する例がある。また、車載ネットワークのネットワークバスを流れるメッセージの全部、あるいは予め定められた受信すべきメッセージを受信し、そのメッセージに含まれるデータを取得して蓄積することも、自発的なデータの取得および蓄積に含まれる。
以下、実施形態のデータ格納装置の詳細について、図面を参照しながら説明する。なお、以下の説明において、同様の機能を持つ構成要素については同一の符号を付して、重複した説明を適宜省略する。
<第1実施形態>
図1は、車載ネットワーク1の全体構成を概略的に示す図である。この車載ネットワーク1は、例えば、自動車などの車両Vに搭載された複数のECU(図1では4つのECU2a〜2dを例示している)を連携させた車両制御を実現するために用いられる。すなわち、車載ネットワーク1に接続された複数のECU間で車両制御に必要なデータを通信することにより、複数のECUを連携させた車両制御が実現される。なお、図1では、車載ネットワーク1の構成を分かり易く図示するために、車載ネットワーク1に接続された複数のECUとして4つのECU2a〜2dのみを図示しているが、車載ネットワーク1に接続されるECUの数は任意である。以下では、車載ネットワーク1に接続されたECUを特に区別せずに総称する場合、ECU2と表記する。
図1に示す車載ネットワーク1は、複数のECU2(2a〜2d)のほか、通信装置3、無線通信I/F(インタフェース)4、および実施形態のデータ格納装置100を備える。ECU2、通信装置3、およびデータ格納装置100はネットワークバス5によって接続されており、ネットワークバス5を通じてメッセージを送受信することで互いに通信できるようになっている。ネットワークバス5は、車載用に適用可能な一般的な通信プロトコルに対応したものを使用できる。例えば、CAN、CAN−FD、Ethernet(登録商標)、FlexRay(登録商標)、MOST、LIN、CXPIなどに対応したものを用いることができる。
無線通信I/F4は、通信装置3に接続されている。無線通信I/F4は、外部装置(外部サーバなど)7と通信装置3をつなぐための物理インタフェースである。無線通信I/F4が利用する通信方式は3GPP(登録商標)、LTE(登録商標)といった携帯電話システム、またはWi−Fi(登録商標)を用いることができる。
通信装置3は、無線通信I/F4を介して外部装置7と通信することができる。また、通信装置3は、ネットワークバス5を介してデータ格納装置100やECU2と通信することもできる。そのため、通信装置3は、外部装置7から受信したデータをデータ格納装置100やECU2に送信したり、データ格納装置100やECU2から受信したデータを外部装置7に送信したりすることができる。
ECU2は、車載装置を制御する電子制御ユニットである。車載装置とは、車両Vに搭載される機械的・電子的装置のことであり、エンジンのような駆動系に分類される装置のほか、車内灯や窓のような車体系に分類される装置、ナビゲーションやフロントパネルのような情報系に分類される装置、アンチロックブレーキングシステム(ABS)やブレーキのような走行系に分類される装置などがある。例えば、ECU2aは駆動系のエンジンを制御し、ECU2bは車体系の車内灯を制御し、ECU2cは情報系のナビゲーションを制御し、ECU2dは走行系のABSを制御する。また、ECU2aが制御する車載装置は駆動系に限られるものではなく、車体系や情報系、走行系に分類される車載装置を制御してもよい。これはECU2b〜2dも同様である。また、1つのECU2が複数の車載装置を制御してもよい。
車載装置が車両Vの状態に応じた制御を行うため、ECU2は、他のECU2とネットワークバス5を介して通信する。例えば、ECU2が制御している車載装置を操作するための制御データや制御対象の車載装置の動作状態を他のECU2に送信し、また、他のECU2から同等の情報を受信する。なお、ECU2が他のECU2とネットワークバス5を介して通信するデータは制御データや動作状態に限らず、後述するECU2自身の動作状態やECU2が持つ機能の異常状態などであってもよい。
ECU2は、メッセージを送受信して他のECU2と通信する。通信プロトコルとしてCANを例に取ると、メッセージは、ID領域と、送信先に渡すデータ領域との少なくとも2つの領域を持つ。ID領域には、メッセージの送信元や送信先を示す情報や、メッセージを区別するためのIDを含んでもよい。データ領域には他のECU2に渡すデータや、後述する診断プロトコルに基づき、ECU2が実行した診断処理の結果を含んでもよい。CANは、ECU2がネットワークバス5にメッセージを送り出すと、ネットワークバス5につながるすべての機器(ECU2a〜2d、通信装置3、およびデータ格納装置100)がメッセージを受信するブロードキャストベースの通信プロトコルである。メッセージを受信した機器はメッセージのIDを見て、どのようなデータか、自分が処理すべきデータかを判断する。
ECU2は、制御対象の車載装置およびECU2自身が故障した場合に備え、制御対象の車載装置およびECU2自身を診断する機能を有する。診断機能は主に二種類に大別され、そのうちの1つは、ECU2内部で記録されるデータをネットワークバス5上に出力する機能であり、ECU2自身の設定情報や動作状態、または制御対象の車載装置の動作状態をメッセージとして出力する。例えば、ECU2a自身の設定情報として、エンジン点火タイミングやスピードリミッタの速度設定、ファームウェアのバージョンなどがあり、ECU2a自身の動作状態として、ECU2aに供給されているバッテリ電圧値などがある。制御対象の車載装置の動作状態としてエンジン回転数や速度、ラジエータの冷却水の温度などがある。なお、ECU2の設定情報や動作状態は、ECU2の設計や有する機能、ECU2が制御する車載装置の分類によって変わる。
もう1つの診断機能は、ECU2が持つ機能または制御対象の車載装置が持つ機能をECU2自身がチェックし、異常が見つかれば、異常状態が発生している機能と異常状態の内容をメッセージとしてネットワークバス5上に出力するものである。例えば、ECU2aが持つ機能に生じる異常状態として電圧の異常、配線短絡・開放などがあり、車載装置が持つ機能に生じる異常状態として吸気温センサの入力電圧異常や排気再循環センサ入力のGNDショート故障などがある。
ここで、ECU2に対してデータ格納装置100が診断の実行を指示するメッセージ(リクエストメッセージ)およびECU2がネットワークバス5上に出力する診断結果のメッセージ(レスポンスメッセージ)について説明する。リクエストメッセージは、データ格納装置100がECU2に対して診断の実行を指示するメッセージである。ECU2は診断対象となる機能を複数持っていてもよく、また一度に実行できる診断の数は限られていることもあるため、ECU2が持つ診断機能のうち、どの診断機能を実行するかをデータ格納装置100がリクエストメッセージで指示する。例えば、ECU2aが複数の設定情報を持つ場合、リクエストメッセージは、その中からどの設定情報を出力させるかをデータ格納装置100がECU2aに指示する役割を持つ。なお、リクエストメッセージが指示する内容は診断の実行に限らず、ECU2への各種指示に用いてもよい。例えば、異常と診断した結果を再度出力することのないようレスポンスメッセージの出力を抑制する指示をリクエストメッセージに載せてもよい。
レスポンスメッセージは、ECU2の診断結果を示すメッセージである。ECU2が正常に診断を実行した場合、ECU2が出力するレスポンスメッセージには、次の(1)〜(3)に示す情報のうちいずれかが記載される。(1)ECU2自身の設定情報や動作状態、(2)制御対象の車載装置の動作状態、(3)ECU2が持つ機能または制御対象の車載装置が持つ機能の異常の有無や状態。一方、リクエストメッセージが指示する診断機能をECU2が有していなかった場合、あるいは車両Vの状況によってECU2が要求された診断機能を実行できなかった場合、ECU2が出力するレスポンスメッセージには、診断を実行できなかったことを示す情報が記載される。なお、ECU2が診断を実行し、その結果を出力するきっかけは、リクエストメッセージを受信したときだけでなく、ECU2自身の判断でもよい。例えば、ECU2が定期的に診断を実行し、結果を出力してもよい。
ECU2が扱うリクエストメッセージやレスポンスメッセージは、標準規格化されたECU向け診断プロトコルの規格を用いることを想定している。診断プロトコルの規格として、例えば、UDS(ISO 14229)のほかに、KWP(ISO 14320)、OBD(ISO 15021, SAE J1979)、WWH−OBD(ISO 27145)、1939(SAE J1939)を利用してもよい。
ECU2がリクエストメッセージおよびレスポンスメッセージを用いて他のECU2と通信する際、ネットワークバス5が対応する通信プロトコルを使用して行う。具体的には、メッセージのデータ領域にリクエストメッセージやレスポンスメッセージの情報を設定する。受信側はメッセージのデータ領域の内容を見て、診断内容を判断する。通信プロトコルとECU向け診断プロトコルを組み合わせた規格として、例えばUDS on CAN、UDS on LINがあり、これらの規格を利用してもよい。
次に、以上のような車載ネットワーク1に接続して使用される実施形態のデータ格納装置100の詳細について説明する。図2は、実施形態のデータ格納装置100のハードウェア構成の一例を概略的に示すブロック図である。このデータ格納装置100としては、例えばNANDフラッシュメモリを搭載する装置を想定している。
データ格納装置100は、図2に示すように、プロセッサ110と、タイマ140と、メインメモリ150と、バスI/F160と、ブリッジ170と、データ蓄積部180とを備える。これら各部は同一の基板190上に搭載され、基板190上の配線などを用いた内部バス191,192を介して、図2に示すように接続されている。
バスI/F160は、ネットワークバス5によって車載ネットワーク1に接続されている。プロセッサ110、メインメモリ150、バスI/F160、およびブリッジ170は内部バス191によって接続されている。データ蓄積部180はブリッジ170と内部バス192によって接続されている。タイマ140はプロセッサ110に接続されている。
プロセッサ110は、メインメモリ150からロードした命令やデータを逐次的に処理し、処理した結果をメインメモリ150に記憶させる。例えば、プロセッサ110は、メインメモリ150を使用して所定の制御プログラム(ソフトウェアプログラム)を実行することにより、後述の機能的な構成要素を実現する。このプロセッサ110は、例えば、ARM(登録商標)Cortex−Mシリーズのような汎用プロセッサである。
タイマ140は、設定に従って一定周期で割込みを発生させる機能を有する。プロセッサ110で動作するソフトウェアは、この割込みをハンドルすることで、周期的に特定の処理を実行させることができる。
メインメモリ150は、汎用の主記憶装置である。例えば、DRAM(Dynamic Random Access Memory)やSRAM(Static Random Access Memory)、MRAM(Magnetic RAM)などをメインメモリ150として用いることができる。
ブリッジ170は、内部バス191と内部バス192とを接続するブリッジコントローラである。通信プロトコルが異なる内部バス191と内部バス192の間でそれぞれのバスアクセスを変換し、内部バス191につながる各部(プロセッサ110やメインメモリ150、バスI/F160)と、内部バス192につながるデータ蓄積部180との間で命令やデータのやり取りを可能にする。
データ蓄積部180は記憶装置を有し、プロセッサ110の命令に基づき、ネットワークバス5から受信したメッセージや内部バス191を流れるデータを記憶装置に格納したり、記憶装置から読み出したデータをプロセッサ110に出力したりする。データ蓄積部180が持つ記憶装置として、コントローラを含まないNANDフラッシュメモリまたはコントローラを含むNANDフラッシュメモリを想定している。つまり、データ蓄積部180は、プロセッサ110の命令に基づいてNANDフラッシュメモリにデータを入出力するNANDインタフェースを備える。コントローラを含まないNANDフラッシュメモリは、書き込み回数の平滑化を行うウェアレベリング機能や不良ブロックの管理機能、エラー訂正機能、論理アドレスでのアクセス機能を持たない。このため、データ蓄積部180の記憶装置としてコントローラを含まないNANDフラッシュメモリを使用する場合、データの書き込み時と読み出し時はプロセッサ110が物理アドレスを指定してデータ蓄積部180にアクセスする。コントローラを含むNANDフラッシュメモリを使用する場合、アクセスする記憶領域の指定には物理アドレスではなく論理ブロックアドレス(LBA)を用いる。コントローラを含むNANDフラッシュメモリとして、SSD(Solid State Drive)、SDカードのようなメモリカード、USBメモリを利用してもよい。
バスI/F160は、車載ネットワーク1のネットワークバス5にデータ格納装置100を接続するためのインタフェースである。バスI/F160は、ネットワークバス5に流れるメッセージを取得してメッセージのIDを確認し、データ格納装置100が処理すべきメッセージのIDであればプロセッサ110にメッセージ受信を通知し、内部バス191につながるメインメモリ150に取得したメッセージを書き込む。一方、データ格納装置100が処理すべきメッセージのIDでなければ、プロセッサ110に通知せずにメッセージを破棄する。逆に、プロセッサ110やメインメモリ150からネットワークバス5にメッセージを送る際は、バスI/F160がメインメモリ150から読み出したメッセージをネットワークバス5に送信する。なお、バスI/F160は、ネットワークバス5にメッセージを送信する際、他の機器から同時にメッセージを送信された場合に生じる送信メッセージの衝突を検知する機能を有してもよいし、さらに衝突したメッセージを再送する機能を有してもよい。
一般的なデータ格納装置の場合、データ格納装置を制御するためのプロセッサと制御用プログラムを持つホストが必要である。ホストとデータ格納装置とが汎用IFで接続され、ホストがデータ格納装置に対してデータの読み出しや書き込みを指示する。データ格納装置はホストの指示に従い、汎用IFを通じて受動的にデータの読み出しや書き込みを実行するだけである。一方、実施形態のデータ格納装置100は、従来のホストに相当する機能を実現するプロセッサ110を持ち、データ蓄積部180に対するデータの読み出しや書き込みを受動的に行うのではなく、後述するようにバスI/F160を介して自発的にメッセージの送受信を行い、車載ネットワーク1から取得したデータをデータ蓄積部180に蓄積したり、データ蓄積部180から読み出したデータを車載ネットワーク1に出力したりする。
図3は、第1実施形態に係るデータ格納装置100の機能的な構成例を示すブロック図である。図3に示すように、データ格納装置100は、送信メッセージ取得部111、メッセージ処理部112、データ転送部113、署名生成部114、鍵管理部115、およびデータアクセス処理部116を備える。これらの各処理部は、上述したように、プロセッサ110が所定の制御プログラムを実行することにより実現される。すなわち、プロセッサ110が上記の各処理部を有する。なお、説明を容易にするために、ハードウェアであるバスI/F160とタイマ140とデータ蓄積部180も上記の各処理部とともに図3で図示している。
送信メッセージ取得部111、メッセージ処理部112、データ転送部113、署名生成部114、鍵管理部115、およびデータアクセス処理部116は、例えば、プロセッサ110が所定のプログラムを実行することにより実現される。このプログラムは、例えばデータ蓄積部180に保存されており、データ格納装置100が起動するとデータ蓄積部180からメインメモリ150に読み出され、プロセッサ110により実行される。
送信メッセージ取得部111は、タイマ140から割込み通知を受け取ると、自身が持つ送信メッセージの中から次に送信するメッセージを選択し、メッセージ処理部112に渡す。例えば、送信メッセージ取得部111は、宛先が記載されたメッセージを蓄積するメッセージキューとあらかじめメッセージの送信先のIDが記載されたリストを持つ。送信メッセージ取得部111は、メッセージキューに蓄積されたメッセージとリストと照らし合わせて、送信先のIDをメッセージに埋め込んで、次に送信するメッセージとして選択する。本実施形態では、上述の診断機能を持つECU2のすべてがメッセージの送信先としてリストに登録されていることを想定する。
メッセージ処理部112は、送信メッセージ取得部111から受け取ったメッセージを、バスI/F160を介してネットワークバス5に送出する。送信メッセージ取得部111が持つメッセージは、ECU2(2a〜2d)に対して診断を要求するリクエストメッセージが挙げられる。データ格納装置100は、リクエストメッセージを送信してECU2に診断実行を指示し、ECU2から送信されるレスポンスメッセージを収集して、ECU2やECU2が制御する車載装置の設定や異常状態を自発的にデータ蓄積部180に蓄積することができる。
メッセージ処理部112は、ネットワークバス5に接続されたECU2や通信装置3との間でバスI/F160を介してメッセージを送受信する。メッセージ処理部112は、送信メッセージ取得部111からリクエストメッセージを受け取ると、バスI/F160を介してそのメッセージをネットワークバス5に送出する。また、リクエストメッセージを受信したECU2からレスポンスメッセージを受け取るため、メッセージ処理部112はメッセージ受信待ちになる。その後、メッセージ処理部112は、バスI/F160を介してECU2からレスポンスメッセージを受け取ると、レスポンスメッセージからデータ領域の内容を取得し、データ転送部113に渡す。このとき、ID領域の内容も一緒にデータ転送部113に渡してもよい。メッセージ処理部112が受信するメッセージは、ECU2から送信されるレスポンスメッセージの他に、ECU2(2a〜2d)の間で送受信される制御メッセージなどがある。これらのメッセージに含まれるデータは、いずれもデータ蓄積部180に蓄積するデータである。それ以外にデータ蓄積部180に格納されたデータ(記録データ)の読み出しを指示するメッセージがある。このメッセージを受信した場合も、メッセージ処理部112は、レスポンスメッセージの場合と同様に、受信したメッセージからデータとして読み出し指示を取得して、データ転送部113に渡す。
データ転送部113は、他の処理部から受け取ったデータを署名生成部114またはデータアクセス処理部116に転送する。データ転送部113は、受け取ったデータによって転送先をどこにするかを決める条件を持ち、その条件に従いデータの転送先を決める。例えば、メッセージ処理部112からECU2の診断処理の結果を示す診断データを受け取った場合、データ転送部113は、そのECU2の診断データに署名を付与するため署名生成部114に診断データを転送する。このとき、診断データだけでなくID領域の内容にも署名を付与するため、診断データと一緒にID領域の内容も署名生成部114に転送してもよい。また、署名生成部114から署名が付与された診断データを受け取った場合、データ転送部113は、署名が付与された診断データをデータ蓄積部180に書き込むため、データアクセス処理部116に署名が付与された診断データを転送する。このとき、データアクセス処理部116は、署名が付与された診断データと一緒に書き込み先情報をデータ蓄積部180に渡し、署名が付与された診断データをどこに書き込むかを指示する。また、データ転送部113は、メッセージ処理部112からデータ蓄積部180に格納された記録データの読み出し指示を受け取った場合、読み出し指示をデータアクセス処理部116に転送する。
データ転送部113は、転送するデータの属性を転送先に伝えるため、転送するデータにメタデータを付与してもよい。メタデータとして、例えば、外部から受信したのか内部で生成されたのかを示すメタデータ、署名の有無を示すメタデータ、機密か公開かを示すメタデータなどがある。例えば、内部で生成されるデータとして、署名や受信したデータの性質を示すデータ(重要度、複数のデータ間の関連性など)がある。このようなデータに内部で生成されたことを示すメタデータが付与されてデータアクセス処理部116に転送されると、データを受け取ったデータアクセス処理部116はメタデータを参照することで、データの属性を知ることができる。蓄積対象のデータに付与されたメタデータはデータと一緒にデータ蓄積部180に格納される。また、データ蓄積部180から記録データを読み出すための読み出し指示は、データ格納装置100の外部が起点になる場合と、データ格納装置100の内部が起点になる場合の二種類がある。このため、読み出し指示の送信元を区別するためのメタデータが付与される。なお、データにメタデータを付与する処理部はデータ転送部113に限らず、他の処理部でメタデータを付与してもよい。
データアクセス処理部116は、受け取ったデータに付与されたメタデータを参照することで、データの属性を知ることができ、属性に合わせた処理を行うことができる。例えば、データアクセス処理部116は、内部で生成されたことを示すメタデータを持つ読み出し指示については、未署名のメタデータを持つ記録データの読み出しを許可するが、外部から受信したことを示すメタデータを持つ読み出し指示については、未署名のメタデータや機密を示すメタデータを付与された記録データを外部に読み出すのを制限する、あるいは、機密のメタデータを付与された記録データは認証された相手しか読み出せないが、公開のメタデータを付与された記録データは誰でも読み出せる、といった制限を行う。また、データ転送部113は、データが未署名か否かをデータに付与されたメタデータで判断し、転送先を変えてもよい。なお、メタデータを参照して処理を変える処理部は、データアクセス処理部116やデータ転送部113に限らず、どの処理部でもよい。
署名生成部114は、一方向ハッシュ関数と、後述する鍵管理部115が保持する鍵を用いた公開鍵暗号アルゴリズムから成る署名アルゴリズムによって、データ転送部113から受け取ったデータの署名を生成・付与する。署名生成部114は、一方向ハッシュ関数を用いて入力データのハッシュを計算し、求めたハッシュを公開鍵暗号アルゴリズムと秘密鍵を用いて暗号化することで署名を計算する。一方向ハッシュ関数は、MD5,SHA−256,SHA−3などのよく知られたアルゴリズムを用いればよい。公開鍵暗号アルゴリズムは、RSAや楕円曲線暗号などのよく知られたアルゴリズムを用いればよい。
なお、署名生成部114は、公開鍵暗号を利用する署名アルゴリズム以外に、共通鍵暗号を利用するMAC (Message Authentication Code)アルゴリズムやハッシュ関数を利用するHMACを備えていてもよい。データ蓄積部180に格納するデータに署名およびMACを付与することで、データ蓄積部180から読み出したデータが改ざんされたかどうかを検知することができる。
鍵管理部115は、署名生成部114で署名を生成するための鍵を保持する。鍵管理部115は、公開鍵暗号アルゴリズムから計算される公開鍵と秘密鍵のペアのうち、少なくとも署名生成に必要な秘密鍵を有している。なお、署名の検証に必要な公開鍵は鍵管理部115が保持していてもよいし、公開鍵を管理する外部装置が保管していてもよい。鍵管理部115は、自前で公開鍵暗号アルゴリズムから公開鍵と秘密鍵のペアを生成してもよいし、外部で生成した秘密鍵を受け取ってもよい。自前で公開鍵と秘密鍵のペアを生成する場合、鍵管理部115はデータ格納装置100の外部に公開鍵を送信する機能を有する。なお、鍵管理部115は、鍵をデータ蓄積部180に保存してもよいし、内部バス191に接続された他の記憶領域に保存してもよい。また、鍵を安全に管理するため、TPM(Trusted Platform Module)のような鍵を安全に扱うための専用のハードウェアを利用して、鍵の生成や保管を行ってもよい。
データアクセス処理部116は、データ蓄積部180へのアクセスを管理する処理部であり、データ蓄積部180にデータを書き込む命令を発行したり、データ蓄積部180からデータを読み出す命令を発行したりする。データ蓄積部180にデータを書き込む場合、データアクセス処理部116は、データ転送部113から書き込むデータを受け取り、自身が生成した書き込み先情報(例えば、物理アドレスとデータのサイズ)と一緒にデータ蓄積部180に送る。同時に、データアクセス処理部116は、書き込み先情報を管理し、空き領域の管理や読み出し可能かどうかのチェックを行う。なお、データアクセス処理部116が書き込み先情報を生成する方法は自由に設定できるものとする。例えば、アドレス順に順番に書き込む方法でもよいし、空き領域からランダムに選択してもよい。そのほかに、データアクセス処理部116は、データの信頼性を高めるため、書き込み箇所を一か所から複数箇所に増やしたり、誤り訂正符号を付与したりしてもよい。
データ蓄積部180からデータを読み出す場合、データアクセス処理部116は、データ転送部113から読み出し先を指定する情報を含む読み出し指示を受け取り、この読み出し指示をデータ蓄積部180からデータを読み出す命令に変換して、データ蓄積部180に送る。データ蓄積部180は、受け取った読み出し命令に基づきデータを読み出し、データアクセス処理部116に渡す。データアクセス処理部116は、受け取ったデータをデータ転送部113を介してメッセージ処理部112に渡す。これにより、データ蓄積部180から読み出されたデータが、バスI/F160を介してネットワークバス5に送出される。
なお、データ蓄積部180の読み出し先を指定する方法として、あらかじめ読み出し方法をデータアクセス処理部116に設定しておき、設定された読み出し方法を指定してもよい。例えば、読み出し方法として「すべての記録データの出力」を指定すると、データ格納装置100は、データ蓄積部180に蓄積されたデータのうち、後述する外部読み出し禁止領域を除いた領域に格納されたすべての記録データを出力する。
データアクセス処理部116は、データ蓄積部180に対するアクセス制限を行う機能を持ち、書き込みや読み出しを制限してもよい。具体的には、データアクセス処理部116は、物理アドレスで示す特定の領域に対して、データの書き込みを禁止したり、あるいは、内部で生成した読み出し指示なら読み出しを許可するが、外部から受信した読み出し指示は拒否したりといった制限を行うようにしてもよい。外部から受信した読み出し命令と内部で生成した読み出し命令を区別する方法として、例えば、データ転送部113が付与したメタデータを参照する方法がある。データ転送部113は、メッセージ処理部112から受け取ったデータには外部を示すメタデータを付与し、署名生成部114などメッセージ処理部112以外の処理部から受け取ったデータには内部を示すメタデータを付与することができる。そのメタデータを参照することで、データアクセス処理部116は、受け取ったデータが外部から来たのか内部で生成されたのかを区別できる。
データアクセス処理部116がアクセス制限を行う機能を持つ場合、例えば、外部から受信した読み出し指示が拒否される領域(外部読み出し禁止領域)に鍵を保存することで、鍵がデータ格納装置100の外部に不用意に出力されることを防ぐことができる。また、後述するように、未署名のままデータ蓄積部180に書き込まれるデータを外部読み出し禁止領域に格納することで、未署名のままデータが外部に出力されることを防ぐことができる。
図4は、本実施形態に係るデータ格納装置100による処理手順の一例を示すフローチャートであり、データ格納装置100が車載ネットワーク1から自発的にデータを取得してデータ蓄積部180に蓄積する基本的な処理動作の一例をまとめたものである。この図4のフローチャートで示す一連の処理は、プロセッサ110がタイマ140から割込み通知を受けるたびに繰り返し実行される。
プロセッサ110は、タイマ140から割込み通知を受けると(ステップS101:Yes)、送信メッセージ取得部111にタイマ割込みを伝える。
送信メッセージ取得部111は、タイマ割込み通知を受けて、例えば、上述のメッセージキューと送信先のリストに基づいて、送信先のIDを埋め込んだリクエストメッセージを選択し、メッセージ処理部112に渡す(ステップS102)。そして、メッセージ処理部112が、バスI/F160を介してECU2に向けたリクエストメッセージをネットワークバス5に送出することで、リクエストメッセージをECU2に送信する(ステップS103)。
その後、ECU2からレスポンスメッセージが送信されると、メッセージ処理部112は、そのレスポンスメッセージをバスI/F160を介して受信し、受信したレスポンスメッセージからデータを取り出す(ステップS104)。メッセージ処理部112がレスポンスメッセージから取り出したデータは、データ転送部113を介して署名生成部114に渡される。
次に、署名生成部114が、鍵管理部115から署名用の鍵を読み出し(ステップS105)、その鍵を用いてデータ転送部113から受け取ったデータの署名を計算し(ステップS106)、データと署名をデータ転送部113に渡す。データ転送部113は、署名生成部114から受け取ったデータと署名と書き込み指示をデータアクセス処理部116に渡す。データアクセス処理部116は、書き込み指示に応じてデータと署名の書き込み先の物理アドレスを決め(ステップS107)、データ蓄積部180に対してデータと署名と書き込み先の物理アドレスを渡す。データ蓄積部180は、データアクセス処理部116から受け取ったデータと署名を、書き込み先の物理アドレスが示す領域に格納する(ステップS108)。
図5は、本実施形態に係るデータ格納装置100による処理手順の一例を示すフローチャートであり、メッセージ受信時におけるデータ格納装置100の処理動作の一例をまとめたものである。この図5のフローチャートで示す一連の処理は、バスI/F160がネットワークバス5に流れているメッセージを受信するたびに繰り返し実行される。
バスI/F160は、ネットワークバス5に流れているメッセージを受信すると(ステップS201:Yes)、受信したメッセージをメッセージ処理部112に渡す。メッセージ処理部112は、受信したメッセージが格納対象のメッセージか、あるいはデータ読み出しを指示するメッセージかをチェックする(ステップS202,S203)。ここで、格納対象のメッセージを受信した場合(ステップS202:Yes)、メッセージ処理部112は、メッセージに含まれるデータをデータ転送部113に渡し、データ転送部113は受け取ったデータを署名生成部114に渡す。
署名生成部114は、データ転送部113からデータを受け取ると、鍵管理部115から署名用の鍵を読み出し(ステップS204)、受け取ったデータの署名を計算して(ステップS205)、データ転送部113にデータと署名を渡す。データ転送部113は、データと署名と書き込み指示をデータアクセス処理部116に送る。データアクセス処理部116は、データ転送部113から書き込み指示とデータと署名をそれぞれ受け取ると、書き込み指示に応じてデータと署名の書き込み先となる物理アドレスを決め(ステップS206)、データと署名と書き込み先の物理アドレスをデータ蓄積部180に渡す。このとき、データアクセス処理部116は、書き込み先として指定した物理アドレスが指す領域にデータが書き込み済みであることを記録し、データを上書きしないよう以降データの書き込み先として指定しないようにする。データ蓄積部180は、データアクセス処理部116から受け取ったデータと署名を、書き込み先の物理アドレスが示す領域に格納する(ステップS207)。
一方、データ読み出しを指示するメッセージを受信した場合(ステップS203:Yes)、読み出し指示に応じてデータ蓄積部180からデータを読み出し、データ格納装置100からネットワークバス5に向けて出力する処理が行われる。具体的には、メッセージ処理部112は、データ読み出しを指示するメッセージから読み出し指示を取得し、データ転送部113に渡す(ステップS208)。データ転送部113は、受け取った外部からの読み出し指示に外部を示すメタデータを付与してデータアクセス処理部116に渡す。データアクセス処理部116は、メタデータから読み出し指示が外部から受信したものであることを考慮して、外部に送信できない記録データを避けた読み出し命令を読み出し指示から作成し、データ蓄積部180に渡す。データ蓄積部180は読み出し命令に応じてデータを読み出し、データアクセス処理部116に渡す(ステップS209)。データアクセス処理部116は、読み出したデータをデータ転送部113に渡す。データ転送部113は、データアクセス処理部116から受け取ったデータをメッセージ処理部112に渡す。メッセージ処理部112は、データ転送部113から受け取ったデータをメッセージ形式に変換し、バスI/F160を通じてネットワークバス5に送信する(ステップS210)。
また、メッセージ処理部112は、受信したメッセージが格納対象のメッセージでもデータ読み出しを指示するメッセージでもない場合は(ステップS202:No、ステップS203:No)、メッセージの送信元を宛先とするエラーメッセージを生成し、バスI/F160を通じてネットワークバス5にエラーメッセージを送信する(ステップS211)。
以上説明した本実施形態の構成は、特に、車載ネットワーク1にデータ格納装置100を搭載する際のコストを削減するのに有効である。車載ネットワーク1で使われている通信プロトコルは、低速・低コスト設計となっており、複数の相手と安定して確実に通信できることを想定している。一方、SSDやメモリカードといった従来の一般的なデータ格納装置で使われているインタフェースは、1対1で高速に通信することを目的としている。車載ネットワーク1と一般的なデータ格納装置のインタフェースは設計思想が異なるものであるため、車載ネットワーク1に一般的なデータ格納装置を接続する場合、データ格納装置を制御するCPUを持ち、車載ネットワーク1に接続する機能を持ったホストが必要となる。
これに対し、本実施形態に係るデータ格納装置100は、車載ネットワーク1用のインタフェースと通信プロトコル、標準化されたECU診断規格にそれぞれ対応しており、車載ネットワーク1上のECU2などから自発的にデータを取得して蓄積することを、ホストCPUがなくても実行できる。また、本実施形態に係るデータ格納装置100に用いるプロセッサ110は特定の処理に特化し、汎用的に持たせる機能を削減しているため、コスト削減に有効である。
さらに、本実施形態に係るデータ格納装置100には、ネットワークバス5につながるバスI/F160とメッセージを送受信するためのホストプログラムが内蔵されている。そして、このホストプログラムはデータの収集に特化した小規模なプログラムである。このため、脆弱性を含みづらく、データ蓄積部180に格納されたデータを改変されるリスクを小さくするのに有効である。複数の機能を備えた外付けのホストが存在する場合、外付けホストのホストプログラムの規模が大きくなり、脆弱性を含みやすくなる虞がある。
また、本実施形態に係るデータ格納装置100の構成は、署名に使用する鍵の管理コストを削減するのにも有効である。従来の構成のように、データを収集するホスト(ECU)とデータ格納装置が分かれており、ホストとデータ格納装置との間が汎用インタフェースで接続されている場合、データ格納装置に鍵を保存すると、データ格納装置を取り出し、アクセス制限機能を持たない汎用インタフェースを経由して秘密鍵を含むデータを抜き出される虞がある。そのため、通常は、容易に分離可能なデータ格納装置に鍵を保存することはなく、TPMのような専用ハードウェアを使用して鍵を安全に保存する。
しかし、本実施形態のようにデータ格納装置100が鍵管理部115を備える構成であれば、データ蓄積部180のアクセス制限をかけた領域に鍵を保存することで、データ格納装置100を取り出し、鍵を抜き出されることを防ぐことができる。そのため、専用ハードウェアを使わずに安全に鍵を保存することができ、コストの削減に有効である。この効果は、鍵の安全な保存だけでなく、後述するように未署名のまま格納したデータが意図せず読み出されることを防ぐことにも効果がある。そのほかに、署名検証用の公開鍵もデータ格納装置100に持つことで、データ格納装置100に格納されたデータの検証が必要になったときに、すぐに署名検証用の公開鍵を入手できるため、署名の検証に使用する鍵の管理コストを削減する上でも有効である。
また、本実施形態では、鍵を含む署名機能をデータ格納装置100に持つことで、データ格納装置100を異なる車両の車載ネットワークに接続することが容易になる利点もある。データ格納装置100が独立して署名生成できるため、接続先の環境によらず、常に同じ署名方式を用いてデータに署名を付与することができる。そのため、接続先が代わってもデータの検証は常に同じ公開鍵を用いてできるため、データの検証が容易である。従来のようにホスト(ECU)とデータ格納装置が分かれており、署名機能をホストが有している場合、接続先の車両によってホストが持つ署名方式が異なる、もしくは署名機能を持っていない可能性がある。データ格納装置だけを他の車両に移すと、特に車両がオフライン状態の場合に、以前接続されていたホストが持つ公開鍵を探すのが困難になるなど、データによって署名の状況が異なる可能性があり、データの検証が難しくなる。
また、データの格納時に異常が発生した場合、問題発生箇所の切り分けが容易になる効果もある。メッセージの送受信をホスト(ECU)に行わせ、メッセージに含まれるデータをホストとは別のデータ格納装置に格納する構成の場合、データの格納時に異常が発生した場合に、異常の原因がホスト側にあるのかデータ格納装置側にあるのかを特定することが必要になる。異常発生の具体的な例として、ホストあるいはデータ格納装置どちらかに突然の電源断が発生し、書き込み中のデータが失われた場合や、ホストとデータ格納装置をつなぐ通信経路上でノイズによるデータ化けが発生し、異常なデータが書き込まれる場合などが考えられる。どちらの場合も、書き込みデータが失われたり、異常なデータが書き込まれたりする原因を特定するには、ホストとデータ格納装置の両方を調査する必要がある。しかし、ホストとデータ格納装置のメーカーが異なる場合、双方の協力がないと原因の追及は難しい。同様に、通信経路上のノイズのようにホストでもデータ格納装置でもない箇所で生じた異常の場合、原因の追及はさらに難しくなる可能性がある。また、ホストのインタフェースがデータ格納装置のインタフェース規格に基づいて設計されていても、規格で明確になっていない細かい実装の違い(相性)が原因で異常が生じる可能性もある。
これに対し、本実施形態に係るデータ格納装置100は、メッセージの送受信を行う機能とデータが格納されるデータ蓄積部180とが一体化されており、メーカーが共通である。そのため、データの格納時に異常が発生しても、原因はデータ格納装置100にあり、同じメーカーで原因の特定が行えるため、異常の原因追及が容易になる。車載ネットワーク1のような高い信頼性が求められる用途では、原因の特定が容易であることが特に重要となる。
なお、本実施形態では、データ格納装置100がECU2から診断情報を取得して蓄積するために、ECU2に対してリクエストメッセージを送信する例を示した。しかし、本実施形態のポイントは、データ格納装置100が車載ネットワーク1から自発的にデータを収集して蓄積できるようにすることであり、診断情報を要求するためにECU2に対してリクエストメッセージを送信する例に限定するものではない。例えば、バスI/F160は、データ格納装置100が処理するIDでないメッセージを取得しても、そのメッセージを破棄せずにプロセッサ110にメッセージ受信を通知することで、データ格納装置100に向けたレスポンスメッセージ以外のメッセージも受信する設定が可能である。データ格納装置100が行う自発的な処理には、このような機能を利用して、ネットワークバス5に流れるメッセージを、メッセージのIDに関わらずすべて受信し、ECU2の間で送受信される制御メッセージを取得してデータ蓄積部180に蓄積することも含まれる。
(変形例)
以上説明した第1実施形態では、ECU2から受信したメッセージに含まれるデータに署名を付与してデータ蓄積部180に格納していた。しかし、ECU2から受信したメッセージに含まれるデータを未署名のままデータ蓄積部180に格納しておき、プロセッサ110の使用率が低いときに、未署名のデータをデータ蓄積部180から読み出して署名を付与する構成であってもよい。
図6は、本変形例に係るデータ格納装置100の機能的な構成例を示すブロック図である。図3に示した第1実施形態の構成との違いは、スケジューラ部117と未署名データ管理部118とが追加されている点である。
スケジューラ部117は、タイマ割込みを受け取った際、次に行う処理を決める処理部である。具体的には、プロセッサ110の使用率に応じて、リクエストメッセージを送信するか署名を計算するかの指示を行う。なお、次に行う処理を決める基準はプロセッサ110の使用率に限らず、あらかじめ決められたスケジュールに基づいて決めてもよい。また、次に行う処理はリクエストメッセージの送信と署名の計算の2つに限らず、その他の処理を含めてもよい。
未署名データ管理部118は、データ蓄積部180に格納された未署名データを管理する処理部である。未署名データ管理部118は、署名せずにデータ蓄積部180に格納するデータの書き込み先情報をデータアクセス処理部116から受け取って記録する。未署名データ管理部118は、スケジューラ部117から署名計算の指示を受けると、管理する未署名データの書き込み先情報をデータアクセス処理部116に渡す。同時に、未署名データに署名が付与されたと判断し、未署名データの書き込み先情報を削除する。なお、未署名データ管理部118は、データアクセス処理部116からの要求を受けて管理する未署名データの書き込み先情報を渡してもよい。また、未署名データの書き込み先情報は1つに限らず複数記録してもよい。
図7は、本変形例に係るデータ格納装置100による処理手順の一例を示すフローチャートである。この図7のフローチャートで示す一連の処理は、プロセッサ110がタイマ140から割込み通知を受けるたびに繰り返し実行される。
プロセッサ110は、タイマ140から割込み通知を受けると(ステップS301:Yes)、スケジューラ部117にタイマ割込みを伝える。スケジューラ部117は、タイマ割込み通知を受けてプロセッサ110の使用率を確認し、プロセッサ110の使用率が所定の閾値以下か否かを判定する(ステップS302)。そして、プロセッサ110の使用率が閾値を超えていれば(ステップS302:No)、送信メッセージ取得部111に対してリクエストメッセージの選択を指示する。
送信メッセージ取得部111は、スケジューラ部117の指示に応じて、例えば、上述の送信先のリストに基づいて送信するリクエストメッセージを選択し、メッセージ処理部112に渡す(ステップS303)。そして、メッセージ処理部112が、バスI/F160を介してECU2に向けたリクエストメッセージをネットワークバス5に送出することで、リクエストメッセージをECU2に送信する(ステップS304)。
その後、ECU2からレスポンスメッセージが送信されると、メッセージ処理部112は、そのレスポンスメッセージをバスI/F160を介して受信し、受信したレスポンスメッセージからデータを取り出す(ステップS305)。メッセージ処理部112がレスポンスメッセージから取り出したデータは、データ転送部113を介してデータアクセス処理部116に渡される。このとき、データ転送部113は、レスポンスメッセージから取り出されたデータに対して未署名を示すメタデータを付与し、データアクセス処理部116に渡す。
データアクセス処理部116は、データ転送部113から未署名データを受け取ると、この未署名データの書き込み先の物理アドレスを決め(ステップS306)、データ蓄積部180に対して未署名データと書き込み先の物理アドレスを渡すとともに、未署名データ管理部118に対して、未署名データの書き込み先の物理アドレスを示す書き込み先情報を送る。データ蓄積部180は、データアクセス処理部116から受け取った未署名データを、書き込み先の物理アドレスが示す領域に格納する(ステップS307)。また、未署名データ管理部118は、データアクセス処理部116から受け取った未署名データの書き込み先情報を記録する(ステップS308)。
一方、ステップS302においてプロセッサ110の使用率が閾値以下と判定した場合(ステップS302:Yes)、スケジューラ部117は、未署名データ管理部118に対して未署名データに対する署名付与を指示する。
未署名データ管理部118は、スケジューラ部117の指示に応じて、まず、自身が持つ未署名データの書き込み先情報の記録を確認し(ステップS309)、未署名データが存在する否かを判定する(ステップS310)。そして、未署名データが存在する場合(ステップS310:Yes)、未署名データ管理部118は、その未署名データの書き込み先情報を読み出し指示に変換し、読み出し指示が内部で生成されたことを示すメタデータを付与して、データアクセス処理部116に渡す。
データアクセス処理部116は、未署名データ管理部118から受け取った読み出し指示が内部で生成されたことをメタデータから判別し、未署名データを読み出せると判断して、この読み出し指示に基づき、未署名データをデータ蓄積部180から読み出してデータ転送部113に渡す。また、未署名データ管理部118は、データ蓄積部180から読み出された未署名データの書き込み先情報を削除する(ステップS311)。
データ転送部113は、データアクセス処理部116から受け取ったデータのメタデータを参照して、未署名データであることを認識し、そのデータを署名生成部114に渡す。署名生成部114は、データ転送部113から受け取ったデータの署名を計算し、データと署名をデータ転送部113に渡す(ステップS312)。データ転送部113は、署名生成部114から受け取ったデータと署名と書き込み指示をデータアクセス処理部116に渡す。データアクセス処理部116は、書き込み指示に応じてデータと署名の書き込み先の物理アドレスを決め、データ蓄積部180に対してデータと署名と書き込み先の物理アドレスを渡す。データ蓄積部180は、データアクセス処理部116から受け取ったデータと署名を、書き込み先の物理アドレスが示す領域に格納する(ステップS313)。
なお、ステップS310において、未署名データが存在しないと判定した場合(ステップS310:No)、未署名データ管理部118は、スケジューラ部117に対して未署名データが存在しないことを通知する。この場合、スケジューラ部117が送信メッセージ取得部111に対してリクエストメッセージの選択を指示することで、ステップS303以降の処理が行われる。
以上説明した本変形例の構成は、プロセッサ110の処理性能が低く、メッセージ処理部112が受信したメッセージに含まれるデータをデータアクセス処理部116に渡すごとに毎回署名を計算できるとは限らない場合に特に有効である。メッセージを受信するたびに署名を計算する構成とした場合は、プロセッサ110には単位時間当たりのメッセージの送受信数の最大値に合わせて署名を計算できるような高い性能が必要となり、データ格納装置100の製造コストが高くなる。あるいは、プロセッサ110の性能が低いと、署名の計算に時間を取られてしまい、メッセージの受信漏れが発生する虞がある。これに対し、本変形例のように、受信したメッセージに含まれるデータを未署名のままデータ蓄積部180に格納し、署名の計算を行うタイミングをずらすことにより、プロセッサ110はメッセージの受信漏れが発生しない程度の性能を持てばよいことになる。その結果、受信したメッセージに含まれるデータに常に署名を計算するような高い性能がプロセッサ110に求められることがなく、データ格納装置100の製造コストを低減することができる。
なお、上述の変形例では、受信したメッセージに含まれるデータを必ず未署名のままデータ蓄積部180に格納することを想定したが、受信したメッセージに含まれるデータに署名を付与してからデータ蓄積部180に格納する場合と、未署名のままデータ蓄積部180に格納して後で署名を付与する場合とを、プロセッサ110の使用率に応じて切り替えるようにしてもよい。すなわち、メッセージ受信時にプロセッサ110の使用率を確認し、署名を計算する余裕があれば、図4に示したように、メッセージに含まれるデータに署名を付与してからデータ蓄積部180に格納する処理を行い、署名を計算する余裕がなければ、図7に示したように、メッセージに含まれるデータを未署名のままデータ蓄積部180に格納し、後で署名を付与する処理を行うようにしてもよい。
このようにプロセッサ110の使用率に応じて署名を付与するタイミングを切り替える構成は、データ格納装置100に必要な処理性能を低く抑えつつ、データの署名付与にかかる処理時間を短縮する効果がある。すなわち、受信したメッセージに含まれるデータを常に未署名のままデータ蓄積部180に格納する構成であると、未署名データの読み出しと署名の書き込みが必ず必要になるため、処理時間が長くなる。一方、プロセッサ110の使用率に応じて署名を付与するタイミングを切り替える構成とすれば、メッセージ受信時にプロセッサ110に余裕があれば、書き込みを行う前に署名付与を行うことで、未署名データの読み出しと署名の書き込みを省略できる。つまり、このようなプロセッサ110の使用率に応じた処理の切り替えは、常に図4に示す処理を行う場合と比較するとプロセッサ110に必要とされる処理性能を低くすることができ、常に図7に示す処理を行う場合と比較するとデータに署名を付与する処理にかかる時間を短くできる利点がある。
<第2実施形態>
次に、第2実施形態について説明する。上述の第1実施形態では、データ格納装置100が自発的にECU2に向けてリクエストメッセージを送信し、ECU2の設定情報や動作状態、診断結果などを取得して蓄積する構成を示した。ここで、上述の第1実施形態では、データ格納装置100が送信するリクエストメッセージは、車両Vの状態に関わらず固定されたセットの中で順番に選択されていた。この手法は、決められたデータを定期的に収集する用途(例えば、ECU2の状態の監視など)を想定していた。
これに対し第2実施形態では、状況に応じてデータ格納装置100が送信するリクエストメッセージを切り替える機能を備えた構成を示す。例えば、データ格納装置100を搭載する車両Vに適したリクエストメッセージを選択したり、ECU2の異常状態に応じて、異常状態の原因を特定するために必要なデータを選択して収集したりする。具体的には、診断結果を含むレスポンスメッセージからは異常の発生個所や異常の状況は分かるが、異常の原因は分からない。そこで、異常が発生した際に、異常が発生したことを示すデータを取得して蓄積するだけでなく、異常の原因を究明するための情報を取得して蓄積できれば、故障原因の早期発見や車両Vの修理に有用である。
異常状態の発生原因を特定するには、異常発生元の機能やECU2だけでなく、他の機能の状態や周辺のECU2の状態も収集し、総合的に判断する必要がある。例えば、車両Vに搭載されている発電機(オルターネータ)を制御するECU2がない場合、発電機が故障したことを直接検出する方法はない。しかし、バッテリが充電されないことにより、ECU2のバッテリ電圧の低下が異常状態として発生する。このとき、もし、ECU2のバッテリ電圧低下が1つのECU2だけでなく、共通のバッテリに接続された他のECU2にもバッテリ電圧低下が発生していれば、ECU2の故障ではなく、バッテリや発電機に異常の原因がある可能性が高いことが分かる。そのため、ECU2のバッテリ電圧低下という異常が発生したとき、他のECU2のバッテリ電圧を収集し記録することで、異常状態の発生原因を特定する精度を高めることができる。これは、ECU2のバッテリ電圧異常の原因特定だけでなく、ECU2の診断機能により取得可能な異常状態の原因特定に適用可能な手法である。
上記手法を実現する1つの方法は、すべてのECU2からすべての機能の診断結果を収集することである。しかし、大量のリクエストメッセージやレスポンスメッセージが車載ネットワーク1に流れることに加え、記憶容量が膨大になり、データの蓄積に要する処理量も大きくなるため、コスト高になる。そこで、第2実施形態では、発生した異常状態の故障原因を特定する診断情報だけを収集するため、送信するリクエストメッセージを状況に応じて変更することで、収集するデータを減らす機能を追加する。送信するリクエストメッセージのセットが固定であると、あらゆるデータを取得しなくてはいけなくなるのに対し、発生した異常状態に応じて動的に異常状態の原因を特定するセットに変更すれば必要なデータだけを収集できるため、不要なリクエストメッセージおよびレスポンスメッセージの送受信を削減することができる。
ここで、リクエストメッセージおよびレスポンスメッセージのフォーマットについて説明する。診断プロトコルとしてUDSを例に取ると、リクエストメッセージおよびレスポンスメッセージは、少なくとも、サービスID領域とサービスデータ領域との2つの領域を持つ。サービスID領域は、どの診断機能を実行するかを示す値が設定される。サービスデータ領域は、リクエストメッセージかレスポンスメッセージかを区別する情報と、レスポンスメッセージの場合、診断結果が記録される。前述したように、リクエストメッセージおよびレスポンスメッセージをECU2間の通信プロトコルを利用して送受信する場合、リクエストメッセージおよびレスポンスメッセージの送信先はメッセージのID領域に設定され、サービスID領域とサービスデータ領域は、メッセージのデータ領域に設定される。
なお、通信プロトコルとECU向け診断プロトコルを組み合わせた規格を利用した場合、ECU向け診断プロトコルは、メッセージのID領域にメッセージの送信先以外の情報を含めることができる。具体的には、メッセージのID領域を分割し、分割されたID領域の一方にリクエストメッセージおよびレスポンスメッセージの送信先を設定し、もう一方に送信元を設定してもよい。この場合、通信プロトコルはメッセージのID領域の送信先が設定された部分だけを参照することで、メッセージの送信先を区別する。
以下では、データ格納装置100が送信するリクエストメッセージのセットのことをルールと呼ぶ。ルールは1以上のリクエストメッセージから構成されている。ルールを構成するリクエストメッセージは、ルールに設定された目的を達成する情報をECU2に要求する。例えば、ECU2のバッテリ電圧を収集するルールは、ECU2a〜2dにバッテリ電圧を要求するリクエストメッセージから構成される。また、ECU2の機能や車載装置の構成は車両Vの車種によって異なるため、車種によってルールの構成やルールを構成するリクエストメッセージの内容は異なる。
第2実施形態では、送信メッセージ取得部111は、ECU2に異常が発生しているかを確認するため、ECU2に対して送信すべきリクエストメッセージが記載されたルール(監視ルール)を持つ。データ格納装置100は、監視ルールに基づき、ECU2に異常が発生しているかを確認するためにリクエストメッセージをECU2に送信する。データ格納装置100は、ECU2から受信したレスポンスメッセージを解析し、異常状態を検出したら、異常状態の原因を特定する情報を収集するルール(特定ルール)に切り替える。以降、データ格納装置100は、切り替え後のルールに基づき送信するリクエストメッセージを選択するようになる。以後、実現方法の詳細について説明する。
図8は、第2実施形態に係るデータ格納装置100の機能的な構成例を示すブロック図である。図3に示した第1実施形態の構成との違いは、データ監視部119とルール管理部120とが追加されている点である。
データ監視部119は、メッセージ処理部112からECU2が送信したレスポンスメッセージを受け取り、ECU2および車載装置に異常が発生していないかをチェックする。具体的には、レスポンスメッセージのサービスIDとデータを解析する。もし異常が発生していれば、発生した異常の内容をルール管理部120に渡す。異常が発生していなければ、データ監視部119はルール管理部120に何も渡さず、次のレスポンスメッセージを解析する。
ここで、データ監視部119は、異常を解析する際、1つのメッセージを解析するほかに、あるECU2から受信した複数のメッセージを解析してもよいし、複数のECU2から受信したそれぞれのメッセージを解析してもよい。また、データ監視部119は、レスポンスメッセージを解析することで、異常状態の有無だけでなく、車両Vの状態を検出してもよい。例えば、診断が実行できないことを示すレスポンスメッセージから、ECU2がリクエストメッセージを処理できない状態にあることを検出してもよいし、レスポンスメッセージを受信するまでの時間がかかりすぎる、あるいはタイムアウトしたことで、ECU2がリクエストメッセージを受信できない状態にあることを検出してもよい。この場合、このような情報をルール管理部120に伝え、後述するようにルール管理部120が送信メッセージ取得部111のルールを切り替えるきっかけにしてもよい。
ルール管理部120は、データ監視部119が異常状態を検出した際、送信メッセージ取得部111に設定されているルールを異常状態の原因を特定するために必要な情報を収集するルール(特定ルール)に切り替える。ルール管理部120は、発生した異常状態と特定ルールとの対応関係を有している。ルール管理部120が保持する異常状態と特定ルールとの対応関係の一例を図9に示す。ルール管理部120は、データ監視部119が伝える異常状態の内容を受け取ると、例えば図9に示す対応関係を参照し、異常状態の原因を特定するために必要な情報を収集する特定ルールを選択して、送信メッセージ取得部111に渡す。送信メッセージ取得部111は、ルール管理部120から特定ルールを受け取ると、現在設定されているルールを、ルール管理部120から受け取った特定ルールに切り替える。
なお、ルール管理部120がルールを切り替えるタイミングは、異常発生時だけでなく、特定ルールが持つリクエストメッセージをすべて送信し終えた後でもよい。例えば、送信メッセージ取得部111は、現在設定されている特定ルールが持つリクエストメッセージをすべて送信すると、異常状態が発生していないかをチェックする監視ルールに切り替えたり、車両Vの状況に応じて監視ルールに切り替えたりしてもよい。また、車両Vのエンジンが始動した直後や停止中、低速走行中、高速走行中などでECU2が受け付け可能なリクエストメッセージが変化したり、監視すべきECU2やECU2が持つ機能、車載装置が異なったりすることが考えられる。その場合、データ格納装置100は車両Vの状態に合わせて複数の監視ルールを持ち、制御メッセージやレスポンスメッセージから車両Vの状態を取得し、それに合わせた監視ルールに切り替えてもよい。これによりECU2が受け付けできないリクエストメッセージの送信をあらかじめ削減することができる。
ルール管理部120が管理するルールは、ルール管理部120自身が保持していてもよいし、データ蓄積部180に保管していてもよい。データ蓄積部180にルールを保管している場合、データアクセス処理部116を経由してデータ蓄積部180からルールを読み出す必要がある。
図10は、本実施形態に係るデータ格納装置100による処理手順の一例を示すフローチャートであり、異常状態の発生を検出した際、異常状態の原因を特定するために必要なデータを収集するルールに切り替える処理動作の一例をまとめたものである。この図10のフローチャートで示す処理は、図4のフローチャートで示す処理に対し、メッセージ処理部112が受信したレスポンスメッセージから異常発生の有無をチェックし、ルール切り替えを行う処理を追加したものである。この追加の処理は、図4のステップS104の後に、図4のステップS105からステップS108の処理(レスポンスメッセージのデータをデータ転送部113に渡した後の処理)と並行して行われ、両者に前後関係はない。以下では追加の処理についてのみ説明する。
本実施形態におけるメッセージ処理部112は、レスポンスメッセージのデータをデータ転送部113に渡すことに加えて、レスポンスメッセージをデータ監視部119に渡す。データ監視部119は、メッセージ処理部112からレスポンスメッセージを受け取ると、現在設定されているルールが監視ルールか否かを確認し(ステップS401)、監視ルールであれば(ステップS401:Yes)、メッセージ処理部112から受け取ったレスポンスメッセージを解析して、異常状態が発生しているかをチェックする(ステップS402)。ここで、異常状態が発生していなければ(ステップS402:No)、送信したリクエストメッセージが最後のリクエストメッセージかどうかを確認し(ステップS403)、最後のリクエストメッセージであれば(ステップS403:Yes)、次に送信するリクエストメッセージを監視ルールの最初のメッセージに戻して(ステップS404)、図4のステップS101に戻る。一方、送信したリクエストメッセージが最後のリクエストメッセージでなければ(ステップS403:No)、何もせず図4のステップS101に戻る。
また、ステップS402において異常状態が発生していると判定した場合(ステップS402:Yes)、データ監視部119は、レスポンスメッセージから異常状態の内容を解析し、ルール管理部120に渡す。ルール管理部120は、受け取った異常状態の内容に対応する特定ルール、すなわち、発生した異常状態の原因を特定するために必要なルールを選択し、送信メッセージ取得部111に渡す。送信メッセージ取得部111は、現在設定されている監視ルールを、ルール管理部120から受け取った特定ルールに切り替えて(ステップS405)、図4のステップS101に戻る。
また、現在設定されているルールが監視ルールでない場合、つまり特定ルールが設定されている場合(ステップS401:No)、データ監視部119は、送信したリクエストメッセージが特定ルールの最後のリクエストメッセージかどうかを確認し(ステップS406)、最後のリクエストメッセージであれば(ステップS406:Yes)、送信メッセージ取得部111に現在設定されている特定ルールを監視ルールに切り替える(ステップS407)。そして、検出した異常状態を再度出力させないよう、メッセージ処理部112からバスI/F160を介して、異常状態を出力したECU2に対して指示メッセージを送信し(ステップS408)、図4のステップS101に戻る。一方、送信したリクエストメッセージが特定ルールの最後のリクエストメッセージでなければ(ステップS406:No)、何もせず図4のステップS101に戻る。なお、原因を特定した異常状態を再度検出しない方法として、該当する異常状態をチェックするリクエストメッセージを送信しないように監視ルールから削除してもよい。
なお、ルール管理部120が管理するルールをデータ蓄積部180に保管している場合、ルールを切り替える手順は次のようになる。ルール管理部120は、データ蓄積部180からルールを読み出す指示を、データ転送部113を経由して、データアクセス処理部116に渡す。データアクセス処理部116は、データ蓄積部180に読み出し指示を渡す。データ蓄積部180は、読み出し指示に応じてルールを読み出し、データアクセス処理部116に渡す。データアクセス処理部116は、データ蓄積部180から読み出されたルールを、データ転送部113を介してルール管理部120に渡す。ルール管理部120は、送信メッセージ取得部111にルールを渡し、送信メッセージ取得部111は、現在設定されているルールを、ルール管理部120から受け取ったルールに切り替える。
本実施形態のように、データ監視部119によるECU2の状態把握と、ルール管理部120によるECU2の異常状態に応じたルールの設定を行う構成は、特にデータ格納装置100に必要な記憶容量の削減、およびECU2が送受信する不要なリクエストメッセージ・レスポンスメッセージの削減、および車載ネットワーク1に流れる不要なメッセージの削減による負荷軽減に特に有用である。すなわち、異常発生に備えて常に異常状態に関係するデータを取得するために、あらゆるリクエストメッセージを送信し、あらゆるレスポンスメッセージを受信すれば、異常状態の原因の特定に必要なデータを収集できる。しかし、この場合は、発生した異常の原因特定と関係のないデータを多く含むことになる。そのため、データ格納装置100やECU2、車載ネットワーク1には無駄なリクエストメッセージを送信したり、無駄なレスポンスメッセージを受信したりする負荷が余計にかかる。さらにデータ格納装置100には無駄なレスポンスメッセージを記録するための余計なデータを記録することになる。これに対し、本実施形態のように、ECU2の状態に合わせたデータだけを収集する構成とすることで、データ格納装置100やECU2、車載ネットワーク1が送受信する不要なリクエストメッセージやレスポンスメッセージを削減し、データ格納装置100の記憶容量を削減することができる。
(変形例)
以上説明した第2実施形態では、異常状態の発生が検出されたときにルールの切り替えを行っていた。しかし、データ格納装置100の接続先の変更時にもルールの切り替えを行う構成としてもよい。つまり、本変形例は、データ格納装置100の接続先の変更時に、接続先の車種に合わせたリクエストメッセージが送信されるように、自動的にルールを切り替える。
図11は、本変形例に係るデータ格納装置100の機能的な構成例を示すブロック図である。図8に示した第2実施形態の構成との違いは、物理I/F挿抜検出部121と車種特定部122とが追加されている点である。
本変形例のデータ格納装置100は、データ格納装置100の接続先の変更時に、ルール管理部120が管理するルールセットを接続先車種に対応したルールセットに変更する。ここで、ルールセットとは監視ルールと特定ルール一式のことを指しており、車種ごとに異なるルールセットが定められている。ルールセットとルールの対応関係および車種とルールセットの対応関係の一例を図12に示す。図12(a)がルールセットとルールの対応関係、図12(b)が車種とルールセットとの対応関係をそれぞれ示している。
物理I/F挿抜検出部121は、物理インタフェースが挿抜されたことを検出する処理部である。物理I/F挿抜検出部121は、物理インタフェースの挿抜を検出すると、車種特定部122に対して物理インタフェースが挿抜されたことを示す信号を通知する。物理インタフェースの挿抜を検出する方法として、例えば、物理I/F挿抜検出部121が、データ格納装置100が接続されている物理インタフェースから供給される電源電圧を常に監視し、その電源電圧の変化によって物理インタフェースの挿抜を検出してもよい。また、それ以外の挿抜検出方法を使用してもよい。
車種特定部122は、データ格納装置100が接続されている車種を特定する情報を取得する処理部である。車種特定部122は、物理I/F挿抜検出部121から物理インタフェースが挿抜されたことを示す信号を受け取ると、車種を特定する情報を取得するため、データ格納装置100の接続先となる車種情報を要求するメッセージを、メッセージ処理部112を経由してバスI/F160からネットワークバス5に送出する。車種特定部122が接続先の車種に関する情報を取得すると、その情報をルール管理部120に渡す。なお、車種情報を取得する方法として、例えば、ECU2もしくはデータ格納装置100とバスを介して通信可能な外部記憶装置が持つ車種情報を取得する方法でもよいし、車種に固有のECU2およびECU2が制御する車両を構成する装置からレスポンスメッセージを受け取ることで判断する方法でもよいし、外部装置からデータ格納装置100に向けて車種情報を送信してもよい。また、車種によってECU2の構成やバスの構成が異なることを利用して、接続先の車種を特定してもよい。
図13は、本変形例に係るデータ格納装置100による処理手順の一例を示すフローチャートであり、物理インタフェースの挿抜を検出した際、接続先の車種を特定し、車種に対応するルールに切り替える処理動作の一例をまとめたものである。
まず、物理I/F挿抜検出部121が物理インタフェースの挿抜を検出すると(ステップS501:Yes)、物理インタフェースが挿抜されたことを車種特定部122に通知する。車種特定部122は、この通知を受けて、上述の方法によりデータ格納装置100が接続されている車種を特定する情報を取得して、その情報をルール管理部120に渡す(ステップS502)。
ルール管理部120は、車種特定部122からデータ格納装置100の接続先の車種を特定する情報を取得すると、自身が管理するルールセットをその接続先車種に対応するルールセットに変更する(ステップS503)。そして、ルール管理部120は、そのルールセットに含まれるルールを取得する処理を行う。例えば、ルールがデータ蓄積部180に保存されている場合、ルール管理部120は、データアクセス処理部116を経由してデータ蓄積部180からルールを読み出すよう指示する。接続先車種に対応するルールセットに含まれるルールを読み出す方法として、データ蓄積部180に車種情報のメタデータを付与したルールセットを保存しておき、車種を指定してルールを読み出す方法がある。なお、接続先車種に対応するルールセットが存在しない場合もある。
車種に対応するルールセットが存在する場合(ステップ504:Yes)、そのルールセットに含まれるルールがデータ蓄積部180から読み出され、データアクセス処理部116からデータ転送部113を介してルール管理部120に渡される。ルール管理部120は、車種に対応するルールを受け取ると、そのルールを送信メッセージ取得部111に渡す。送信メッセージ取得部111は、ルール管理部120からルールを受け取ると、現在設定されているルールを、ルール管理部120から受け取ったルールに切り替える(ステップS505)。以降、図4および図10のフローチャートで示した処理が行われる。
一方、車種に対応するルールセットが存在しない場合(ステップS504:No)、ルール管理部120は、送信メッセージ取得部111のルールを空欄にし、接続先車種に対応していないリクエストメッセージを送信しないよう、リクエストメッセージの送信を停止させる(ステップS507)。以降、図5のフローチャートに従って、データの読み出しやメッセージの受信のみ行う。このとき、データ格納装置100は車種に対応するルールを持っていないことをメッセージに載せてネットワークバス5に送出し、他の機器に通知してもよい。
以上説明した本変形例の構成は、特にデータ格納装置100に手を加えることなく、データ格納装置100を搭載する車種を容易に変更できる点で特に有用である。すなわち、車種によってECU2の構成が異なると、送信するリクエストメッセージや受信するレスポンスメッセージの内容も異なるが、物理インタフェースの抜き差しに合わせてデータ格納装置100を搭載した車種に対応したルールに自動に変更することで、データ格納装置100を任意の車種の車両Vに搭載された車載ネットワーク1に接続することが容易になる。また、データ格納装置100の接続先車種に対応しないリクエストメッセージを誤って送信することも防ぐことができるため、接続先の車載ネットワーク1に余計なメッセージを送信するのを防いだり、ECU2が誤動作することを防いだりできる。
<第3実施形態>
次に、第3実施形態について説明する。上述の第2実施形態では、データ格納装置100がECU2に異常がないかをチェックし、もし異常状態が検出されれば、異常状態の原因を特定するために必要なデータだけを選択して収集する構成を示した。この構成では、ECU2に現在の状態や異常の有無を示すデータを要求するリクエストメッセージは、ルールという形でデータ格納装置100内に保存されている。また、ルールはデータ格納装置100を車両Vに搭載する前に、製造段階でデータ蓄積部180に格納しておくことを想定していた。
これに対し第3実施形態では、データ格納装置100がルールを更新するためのメッセージを外部から受け取り、データ蓄積部180に保存されたルールを更新する機能を備えた構成を示す。
図14は、第3実施形態に係るデータ格納装置100の機能的な構成例を示すブロック図である。図8に示した第2実施形態の構成との違いは、更新データ処理部123が追加されている点である。
更新データ処理部123は、ネットワークバス5を介して受信したルールの更新データを取得し、更新データの内容をチェックして、ルールを更新すべきかどうかを判断し、問題がなければ、データ蓄積部180に格納されたルールを更新する。
更新データは、例えば、診断プロトコルのフォーマットでデータ格納装置100に送付される。更新データは、サービスID領域に更新データを示すIDが設定され、データ領域に更新対象の情報と更新データの本体がそれぞれ設定される。更新データを示すIDは、メッセージが、診断を要求するリクエストメッセージではなく、ルールを更新するデータを含むメッセージであることをデータ格納装置100に伝える。更新対象の情報には、ルールのバージョンと更新するルールについて記載されている。更新するルールについて、例えば、データ格納装置100が持つ特定のルールに対する更新なのか、ルール全体に対する更新なのか、新たなルールセットの追加なのかといった内容が記載されている。データ格納装置100は、更新対象の情報をもとに更新するルールを認識し、更新元のルールが格納されている場所を特定する。なお、更新データの構成は、診断プロトコルに従ったフォーマットに限らない。例えば、独自のフォーマットでもよい。
更新データ処理部123は、受け取った更新データの内容をチェックし、更新対象のルールを更新すべきか否かを判断する。例えば、更新データ処理部123は、更新データのバージョンや更新対象のルールが存在するか、更新データのバージョンが更新対象のルールよりも新しいかといったことをチェックする。まず、更新データ処理部123は、更新データから更新対象のルールを特定する。更新対象のルールが存在すれば、更新データ処理部123は、更新対象のルールの情報をルール管理部120から取得し、更新ルールのバージョンと更新対象のルールのバージョンと比較する。更新ルールのバージョンの方が新しければ、更新データ処理部123は、データ蓄積部180に格納されたルールを更新する。
具体的には、更新データ処理部123は、更新データの内容に合わせて、データ蓄積部180に格納されたルールを更新する指示をデータアクセス処理部116に渡す。ルールを更新する指示(更新指示)は、更新対象のルールが格納された場所を示す物理アドレスと、更新データを更新対象のルールの格納場所に上書きするようデータアクセス処理部116に指示する内容となっている。ルール管理部120が持つルールを更新する場合、ルール管理部120に更新データを渡し、ルール管理部120がルールを更新するか、ルール管理部120にデータ蓄積部180から更新データを読み込ませればよい。
更新データ処理部123によるルールの更新は、データ蓄積部180に格納されている既存のルールを置き換える方法のほかに、新たなルールを追加してもよい。新たなルールを追加する場合、更新データ処理部123は、追加されたルールについてルール管理部120に通知し、ルール管理情報を更新する。以降、ルール管理部120は新たに追加されたルールを参照するようにする。
図15は、本実施形態に係るデータ格納装置100による処理手順の一例を示すフローチャートであり、更新メッセージを受信し、データ蓄積部180に格納されたルールを更新する処理動作の一例をまとめたものである。この図15のフローチャートで示す一連の処理は、バスI/F160がネットワークバス5を介して更新データを含むメッセージを受信するたびに繰り返し実行される。
バスI/F160から受信メッセージを受け取ったメッセージ処理部112は、そのメッセージに含まれるデータ部分を取り出し、データ転送部113に渡す。データ転送部113は、受け取ったデータのサービスIDを参照して更新データであることを認識し(ステップS601:Yes)、その更新データを更新データ処理部123に渡す。
更新データ処理部123は、データ転送部113から受け取った更新データのデータ領域に設定された更新対象の情報を参照し、更新データのバージョンや更新対象のルールが存在するかをチェックすることにより、ルールの更新かどうかを判定する(ステップS602)。ここで、更新対象のルールが存在する場合、つまりルールの更新であると判断した場合(ステップS602:Yes)、更新データ処理部123は、次に、更新データのバージョンが更新対象のルールよりも新しいかどうかを判定する(ステップS603)。
ここで、更新データの方が新しければ(ステップS603:Yes)、更新データ処理部123は、更新対象の情報から更新指示を生成し(ステップS604)、更新データの本体と更新指示をデータアクセス処理部116に渡す(ステップS605)。そして、データアクセス処理部116は、更新指示と更新データ本体から書き込み先情報(物理アドレスとサイズなど)を生成し、更新データ本体と合わせてデータ蓄積部180に渡す。データ蓄積部180は、データアクセス処理部116から受け取った書き込み先情報に基づき、更新対象のデータの格納場所に更新データの本体を上書きすることにより、更新対象のルールを更新する(ステップS606)。その後、更新データ処理部123は、ルール管理部120が持つ更新対象のルールを更新する(ステップS607)。
一方、更新データのバージョンが更新対象のルールのバージョンよりも古い場合(ステップS603:No)、更新データ処理部123は、更新データを破棄し(ステップS608)、ルールの更新を行わない。また、更新データのデータ領域に設定された更新対象の情報に更新対象のルールが存在しない場合、つまりルールの更新ではなくルールの新規追加である場合は(ステップS602:No)、更新データ処理部123は、更新データの本体と書き込み指示をデータアクセス処理部116に渡し、データ蓄積部180に更新データを新規に格納させることにより、ルールを追加させる(ステップS609)。そして、更新データ処理部123は、追加のルールについてルール管理部120に通知し、ルール管理情報を更新する(ステップS610)。
なお、ここではルール単位の更新を例に説明したが、ルールの更新単位はルール単位だけでなく、ルールセット単位でもよいし、あるルールセット全体を更新単位してもよい。あるいは、新たな車種に対応するルールおよびルールセットを追加してもよい。
また、更新対象はルールだけでなく、データ格納装置100を制御するソフトウェアプログラムでもよい。ソフトウェアプログラムを更新する目的として、例えば、第1実施形態の変形例で説明したスケジューラ部117のメッセージ送信タイミングを更新する、データ監視部119の動作状態メッセージからECU2が異常状態かどうかを判断するアルゴリズムを更新する、ソフトウェアプログラムに見つかった脆弱性を修正する、データ格納装置100に機能を追加するなどが挙げられる。
ソフトウェアプログラムの更新を実行する場合、ルールの更新と次のような違いがある。まず、更新データ処理部123は、データ蓄積部180に格納されているソフトウェアプログラムの格納場所を特定可能な情報を保持しているものとする。ソフトウェアプログラムの更新データの構成は、ルールの更新データの構成と同じである。サービスID領域には更新データを示すIDが設定され、更新対象の情報にソフトウェアプログラムの更新データのバージョンとソフトウェアプログラムが更新対象ということが記載されている。
データ格納装置100は、図15のルール更新処理と同等の手順で、ソフトウェアプログラムの更新データを取得し、データ蓄積部180に格納されている既存のソフトウェアプログラムの格納場所に更新データを上書きする。これにより、データ格納装置100が再起動するタイミングで更新後のソフトウェアプログラムが起動することになる。具体的には、データ格納装置100の電源がON/OFFされて、データ格納装置100が再起動すると、データ格納装置100は更新後のソフトウェアプログラムを読み出し、実行する。また、データ格納装置100の電源のON/OFFに限らず、車両Vの停車中など、データ格納装置100が一時的にデータの取得や蓄積を中断しても影響が軽微なタイミングでデータ格納装置100を再起動し、ソフトウェアプログラムを更新してもよい。また、データ格納装置100上で実行中のソフトウェアプログラムに対し、直接メインメモリ150上のデータをオンザフライで書き換えることで、データ格納装置100を再起動することなくソフトウェアプログラムを更新してもよい。
更新メッセージの送信元となる機器は、データ格納装置100にメッセージを送信できる機器であればよく、外部サーバや外部記憶装置などの外部装置7であってもよい。この場合、通信装置3が無線通信I/F4を介して外部装置7から送信される更新メッセージを受信し、ネットワークバス5を介してこの更新メッセージをデータ格納装置100に送信する。
ルールの更新やデータ格納装置100を制御するソフトウェアプログラムの更新は、更新データを含むメッセージを受信した時点で、データ格納装置100によって自動的に行われてもよいし、更新処理の実行を許可する機能をデータ格納装置100に持たせ、車両Vの運転手や整備士といったユーザの操作による更新処理の実行許可をデータ格納装置100が受け取った時に、更新処理が実行されるようにしてもよい。
以上説明した本実施形態の構成によって、データ格納装置100の機能を改善する、新たな機能を追加する、ソフトウェアのバグを修正するといったことが可能になり、データ格納装置100のライフサイクルを伸ばすことができる。データ格納装置100が搭載される自動車などの車両Vは10年以上使用されることもあり、それに合わせてデータ格納装置100の製品寿命を設計する必要がある。その場合、ソフトウェアの更新機能によりデータ格納装置100の機能が危殆化・陳腐化せず使用し続けられることは重要である。
さらに、この構成によって、市場出荷後の車両Vに搭載されたデータ格納装置100のルールおよびソフトウェアプログラムを更新するコストを削減するのにも有効である。なぜなら、車両Vに搭載されている無線通信I/F4を利用して外部装置7から更新メッセージを受信できるため、車両Vの所有者がディーラーに出向いて整備担当者の手を借りて更新作業をしたり、車両Vの所有者に整備担当者を派遣して更新作業をさせたりする必要がなくなるからである。データ格納装置100を搭載する車両Vの販売台数が多くなるほど、このコスト削減の効果は大きくなる。
(変形例)
以上説明した第3実施形態では、データ格納装置100のルールやソフトウェアを更新するためのメッセージに含まれる更新データが、正当なルールやソフトウェアプログラムであることを前提としていた。しかし、上述の更新機能が悪用され、更新データが改ざんされると、不正なルールやソフトウェアプログラムがデータ格納装置100に設定される懸念がある。そこで、更新データの改ざんを検知する機能をデータ格納装置100にさらに持たせるようにしてもよい。
図16は、本変形例に係るデータ格納装置100の機能的な構成例を示すブロック図である。図14に示した第3実施形態の構成との違いは、署名検証部124が追加されている点である。
署名検証部124は、データ格納装置100が受け取ったデータに署名が付与されている場合、データの改ざんを検知するため、署名を検証する処理部である。署名検証部124が検証可能な署名アルゴリズムは、一方向ハッシュ関数と、鍵管理部115が保持する鍵を用いた公開鍵暗号アルゴリズムからなる署名アルゴリズムである。前提として、データ格納装置100は、署名検証用の公開鍵もしくはMAC検証用の共通鍵を鍵管理部115に保持しているものとする。この検証用の鍵は、データ格納装置100の製造時に鍵管理部115に書き込んでもよいし、車両Vの運転手や整備士など人間の操作でネットワークバス5につながる機器経由で取得してもよい。
署名検証の方法は次の通りである。署名検証部124は、一方向ハッシュ関数を用いて受け取ったデータのハッシュを計算する。次に、受け取ったデータに付与された署名を、鍵管理部115が保持する署名元の公開鍵を利用して復号し、ハッシュを取得する。計算したハッシュと復号したハッシュを比較し、一致していれば検証に成功したとする。
一方向ハッシュ関数は、MD5,SHA−256,SHA−3などのよく知られたアルゴリズムを利用できる。公開鍵暗号アルゴリズムは、RSAや楕円曲線暗号などのよく知られたアルゴリズムを利用できる。なお、署名検証部124は、公開鍵暗号を利用する署名アルゴリズム以外に、共通鍵暗号を利用するMACアルゴリズムやハッシュ関数を利用するHMACを検証できる構成であってもよい。
図17は、本変形例に係るデータ格納装置100による処理手順の一例を示すフローチャートであり、更新データが改ざんされていないかを確認するため、更新データに付与された署名を検証する処理動作の一例をまとめたものである。この図17のフローチャートで示す処理は、図15のステップS602の前に追加されて実施される。
データ転送部113は、受信メッセージに含まれるデータをメッセージ処理部112から受け取ると、受け取ったデータのサービスIDを参照して署名付きの更新データであることを認識し(ステップS701:Yes)、その署名付きの更新データを署名検証部124に渡す。署名検証部124は、データ転送部113から署名付きの更新データを受け取ると、鍵管理部115から署名に対応する公開鍵を取得して、この公開鍵で署名を検証する(ステップS702)。
ここで、署名の検証に成功した場合(ステップS703:Yes)、署名検証部124は、データ転送部113に検証成功を通知する。データ転送部113は、検証成功の通知を受けて更新データを更新データ処理部123に渡し、図15のステップS602以降の処理が行われる。一方、署名の検証に失敗した場合は(ステップS703:No)、更新データが改ざんされた可能性があるため、署名検証部124は検証失敗をデータ転送部113に通知し、更新データを破棄する(ステップS704)。なお、更新データには署名の代わりにMACを付与し、署名ではなくメッセージ認証を利用して改ざんの有無をチェックしてもよい。
以上説明した本変形例の構成は、ルールの更新機能を悪用され、不正なルールやソフトウェアプログラムがデータ格納装置100に設定されることを防ぐ際に特に有効である。外部装置7が無線通信I/F4を経由して更新メッセージを送信する場合、利便性が高い半面、悪意のある更新メッセージにより、不正なルールやソフトウェアプログラムがデータ格納装置100に設定される虞がある。本変形例では、更新メッセージの署名の検証を行うことで、更新メッセージの改ざんを検出することができる。それによって、更新データが改ざんされていないことを保証し、データ格納装置100が攻撃を受けて意図しない動作をする可能性を減らすことができる。さらに、署名を使用すれば、更新メッセージの作成者を確認することができることから、より更新データの信頼性を高めることができる。
<第4実施形態>
次に、第4実施形態について説明する。上述の第1実施形態では、ECU2から受信したリクエストメッセージや制御データをデータ蓄積部180に格納する際、データアクセス処理部116が書き込み先情報(例えば、物理アドレスとデータのサイズ)を指定することで、データ蓄積部180への書き込みを制御している。第1実施形態において、データアクセス処理部116は、受け取ったデータをそのまま書き込むという方法であった。この手法は、データ蓄積部180に使われているNANDフラッシュメモリの品質が高く、読み出し時に発生する誤り率が低いことを想定していた。
これに対し、第4実施形態では、後述のデータ監視部が、データ転送部113から受け取ったデータをデータアクセス処理部116に渡す前に、データの重要度を判定する。データ格納装置100は、受け取ったデータが重要なデータならばよりロバストになるように信頼性を高める情報を付与してデータ蓄積部180に格納し、それ以外のデータならばデータの格納に必要な領域の増加を抑えることを優先し、データ格納装置100の用途に適した必要最小限の情報を付与してデータ蓄積部180に格納する。この方法は、データの重要度に応じて信頼性を高める情報を変えることで、データをロバストに格納しながら、信頼性を高める情報を計算する処理負荷を小さくし、かつ、信頼性を高める情報を付加することによる情報量の増加も小さく抑えることを可能にする。
一般に、記憶装置としてNANDフラッシュメモリを持つSSDやSDカードは、NANDフラッシュメモリの品質を長期にわたって保ち、寿命を延ばすための仕組みを持つ。例えば、NANDフラッシュメモリの局所的な劣化を防止するため書き込み回数の平滑化を行うウェアレベリング機能や、ブロックの書き換え回数を管理し劣化したブロックへの書き込みを回避する不良ブロック管理機能、読み出し誤りが発生した場合に備え書き込みデータに誤り訂正信号を付与する機能、複数のブロックに同じデータを書き込み1つのブロックが読み出し不能になっても他のブロックから読み出す多重書き込み機能などがある。以下では、これらを総称して信頼性担保処理という。信頼性担保処理は、SSDやSDカードの内部コントローラが処理する。また、書き込みデータに付与される誤り訂正信号や多重書き込みされたデータのような情報は、NANDフラッシュメモリの容量を消費する。加えて、書き込み寿命に達したブロックの代用などのために、通常、SSDやSDカードは、公称の記憶容量よりも大きなNANDフラッシュメモリを余分に持つことがある。
SSDやSDカードは汎用的な用途を想定しており、信頼性担保処理は書き込まれるデータの内容や性質に関わらず実行される。そのため、用途によっては非効率な方法になる可能性がある。例えば、データ格納装置100のようにネットワークバス5に流れるメッセージを取得してメッセージに含まれるデータを格納する場合、データ蓄積部180に書き込むデータは、主に、定期的に受信するメッセージや異常状態の原因を特定するレスポンスメッセージに含まれるデータである。このとき、記憶容量が十分にあれば、頻繁なデータの消去や書き換えは起こらず、データを時系列に格納していく。また、データを蓄積することが主であり、データの読み出しの回数は書き込む回数よりも相対的に少ない。このような用途の場合、NANDフラッシュメモリの書き込み回数に起因した品質の劣化は生じづらい。そのため、汎用的な用途を想定したウェアレベリング機能や誤り訂正信号付与機能などをデータ格納装置100に適用すると、過剰な品質保証になる可能性がある。過剰な品質保証により、余計な信頼性担保処理を計算するコストが生じ、不要な信頼性を高める情報で記憶領域が消費されてしまう。
ネットワークバス5に流れるメッセージを取得して格納する際の特徴として、頻繁な書き換えが生じず、長期運用時のNANDフラッシュメモリのブロック劣化が汎用的な用途の場合よりも小さいことがある。この特徴を活かして、信頼性担保処理を軽量化することができる。信頼性担保処理の軽量化とは、汎用的な用途を想定した場合と同じ寿命を維持しながら、汎用的な用途を想定した場合よりも、ウェアレベリング機能の実行頻度を減らしたり、書き込みデータに付与する誤り訂正信号を小さくしたり、多重書き込みの多重化数を減らしたり、もしくは多重書き込みをやめたりして、処理を軽くすることである。信頼性担保処理を軽量化することで、プロセッサ110の処理負荷を抑えたり、信頼性を高める情報の格納に必要な領域を減らしたりできる。しかし、書き込みデータすべてに対して一様に信頼性担保処理を軽量化すると、用途によっては寿命が保証できない可能性がある。
そこで、第4実施形態では、受信したメッセージに含まれるデータにその内容に応じた重要度を付与し、重要度によって信頼性担保処理の内容を変える構成とする。具体的には、二種類の信頼性担保処理を定める。1つは汎用的な用途を想定した信頼性担保処理、もう1つは軽量化した信頼性担保処理とする。重要なデータには汎用的な用途を想定した信頼性担保処理を適用し、それ以外のデータには軽量化した信頼性担保処理を適用する。重要度が高いデータは、データ格納装置100に頻繁なデータの消去や書き換えがあっても、確実に読み出せるよう保証する。それ以外は、頻繁な書き換えが発生しないデータを蓄積する用途に限って読み出しを保証し、信頼性担保処理に必要なプロセッサ110の処理能力やデータ蓄積部180の記憶領域を小さく抑える。
図18は、第4実施形態に係るデータ格納装置100の機能的な構成例を示すブロック図である。図3に示した第1実施形態の構成との違いは、データ監視部125とデータ格納処理部126とが追加されている点である。
データ監視部125は、データ転送部113からデータ蓄積部180に書き込むデータを受け取り、データの内容に基づいてそのデータの重要度を判定して、データ蓄積部180に書き込むデータとその重要度をデータ格納処理部126に渡す。データに付与する重要度は、重要であることを示すメタデータとする。なお、説明を簡略化するために、重要度は重要かそうでないかの2通りとし、重要なデータを重要データ、それ以外のデータを非重要データとする。なお、データに付与する重要度に3通り以上の段階を設定し、より綿密な重要度に基づく信頼性担保処理の切り替えを行うようにしてもよい。
データ監視部125がデータ転送部113から受け取るデータとしては、例えば、ECU2からレスポンスメッセージとして送信された診断情報やECU2間でやり取りされる制御データ、制御対象のシステム(エンジンやトランスミッション、エアバッグなど)の動作状態を示すデータなどがある。重要データの例として、異常状態を示す診断情報や安全性に影響のあるエンジンやエアバッグの動作状態を示すデータなどが挙げられる。非重要データとして、安全性には影響のないエアコン操作のデータや、ウィンドウの開け閉め指示などが挙げられる。なお、データ監視部125がどのようなデータに重要度を設定するのかは、データ格納装置100の出荷時に決めてもよいし、製品出荷後に設定してもよい。
データ格納処理部126は、データ監視部125からデータとその重要度を受け取り、重要度に応じてデータに対する信頼性担保処理を行う。ここでは、重要度に応じて切り替える信頼性担保処理として、(a)誤り訂正符号の付与、(b)書き込み回数が少ないブロックへの書き込み、(c)同一データの複数ブロックへの書き込み、の3つを想定する。データ格納処理部126は、重要度に応じた信頼性担保処理を行い、その結果をデータに付与した上で、実際にデータをデータ蓄積部180に書き込む処理を行うデータアクセス処理部116へ渡す。付与するデータは、信頼性を高める情報とデータアクセス処理部116への指示である。具体的には、誤り訂正信号のほかに、データアクセス処理部116に対する書き込み回数が少ないブロックへの書き込み指示や、同じデータを複数のブロックに書き込む指示である。
ここで、上記(a)の誤り訂正符号の付与について説明する。誤り訂正符号をデータに付与してデータ蓄積部180に書き込むと、仮にデータを書き込んだブロックからデータを読み出した際に誤りが生じた場合、誤りの検出および訂正を行うことができる。誤り検出および訂正可能な誤りのサイズは付与する誤り訂正符号の符号長により決まり、符号長が長いほど誤り検出および訂正可能な誤りのサイズが大きくなる。そこで、データ格納処理部126は、重要データに長い誤り訂正符号を付与し、非重要データには短い誤り訂正符号を付与する。このとき、誤り訂正符号の方式として、ハミング符号、巡回ハミング符号、ゴレイ符号、BCH符号、差集合巡回符号、ファイア符号、ターボ符号、LDPC、畳み込み符号などを使用してもよい。
次に、上記(b)の書き込み回数が少ないブロックへの書き込みについて説明する。NANDフラッシュメモリはデータの書き込みを繰り返すことでブロックが次第に劣化していき、最終的に書き込みおよび読出しができなくなる。したがって、書き込み回数の少ないブロックに書き込まれたデータは書き込み回数の多いブロックに書き込まれたデータよりも信頼性が高い。そこで、データ格納処理部126は、重要データには書き込み回数が少ないブロックに優先的に書き込む指示を出し、非重要データには書き込み回数が少ないブロックを除外して残ったブロックに書き込む指示を出す。
次に、上記(c)の同一データの複数ブロックへの書き込み(多重書き込み)について説明する。これは、同じデータを複数のブロックに書き込むことで一か所のブロックから読み出しができなくなっても、同じデータを書き込んだ別のブロックからデータを読み出すことで、データの信頼性を高める方法である。データ格納処理部126は、重要データには複数のブロックに同じデータを書き込む指示を付与し、非重要データには同じデータを書き込むブロック数を減らした指示を付与するか、この指示を付与せず、多重書き込みを行わない。
データ格納処理部126は、上記(a)〜(c)の信頼性担保処理について、次に示す(1)〜(3)の基準に従って、重要データに対する信頼性担保処理と非重要データに対する信頼性担保処理とを切り替える。(1)重要データに付与する誤り訂正符号は、非重要データに付与する誤り訂正符号よりも長い。(2)重要データの書き込み先ブロックの書き込み回数は、非重要データに対する書き込み先ブロックの書き込み回数よりも少ない。(3)重要データを多重書き込みする多重化の数は、非重要データを多重書き込みする多重化の数よりも大きい。
なお、データ格納処理部126は、信頼性担保処理として上記(a)〜(c)のいずれかを適用してもよいし、上記(a)〜(c)を組み合わせて適用してもよい。また、信頼性担保処理は上記(a)〜(c)の3つに限定するものではなく、他の処理を使用してもよい。
図19は、本実施形態に係るデータ格納装置100による処理手順の一例を示すフローチャートであり、レスポンスメッセージに含まれるデータに対して、データの内容に応じた重要度を付与し、重要度に応じた信頼性担保処理を行う処理動作の一例をまとめたものである。この図19のフローチャートで示す処理は、図4のステップS107およびステップS108の処理に代えて実施される。
図4のステップS106で計算された署名とデータが署名生成部114から渡されると、データ転送部113は、署名生成部114から受け取ったデータと署名をデータ監視部125に渡す。データ監視部125は、データ転送部113から受け取ったデータの内容に基づいて、データの重要度を判定し(ステップS801)、データと署名とデータの重要度をデータ格納処理部126に渡す。データ格納処理部126は、データ監視部125から受け取ったデータと署名に対し、データの重要度に応じた信頼性担保処理を行う。すなわち、データ監視部125から受け取ったデータが重要データであれば(ステップS802:Yes)、データ格納処理部126は、重要データに基づく信頼性担保処理を実行する(ステップS803)。一方、データ監視部125から受け取ったデータが非重要データであれば(ステップS802:No)、データ格納処理部126は、非重要データに基づく信頼性担保処理を実行する(ステップS804)。そして、データ格納処理部126は、データと署名に加えて、信頼性担保処理の結果得られた誤り訂正符号とデータアクセス処理部116に対する指示をデータアクセス処理部116に渡す。
データアクセス処理部116は、データ格納処理部126からの指示に従って、データと署名と誤り訂正信号の書き込み先を決め(ステップS805)、データ蓄積部180に対してデータと署名と誤り訂正符号と書き込み先の物理アドレスを渡す。データ蓄積部180は、データアクセス処理部116から受け取ったデータと署名と誤り訂正符号を、書き込み先の物理アドレスが示す領域に格納する(ステップS806)。
以上説明した本実施形態の構成は、特にデータ蓄積部180に格納するデータの信頼性とデータ蓄積部180の記憶領域の容量を節約できる点で有用である。車載ネットワーク1を流れるメッセージは、重要なデータもあればそうでもないデータもある。重要なデータは高信頼性を確保し、データ格納装置100が長期利用されていても確実に読み出せるようにする一方で、重要度が低いデータは信頼性よりも容量を優先することで、データ格納装置100のコストを下げることができる。
記憶装置としてNANDフラッシュメモリを持つSSDやSDカードなどでは、物理アドレスによる書き込みや信頼性情報の付与を内部コントローラが行い、信頼性情報の管理や信頼性を向上させるための方式はSSDやSDカードに固有の方式が用いられるため、汎用I/Fを介して外部から書き込むデータに対し、信頼性情報を付与することはできない。本実施形態では、データ格納装置100にコントローラを含まないNANDフラッシュメモリを使用し、物理アドレスで書き込みを行うことにより、データの重要度に基づき、信頼性を優先するか容量を優先するかを細かく制御することが可能となる。この機能により、コストを下げながらデータ格納装置100の寿命を延ばすことが可能になる。
なお、本実施形態では、信頼性担保処理をデータの重要度に応じて行うが、データの保存期間に応じて行ってもよい。長期保存する必要のあるデータは高信頼性を確保し、ロバストにし、短期間で不要になるデータは信頼性よりも容量を優先してもよい。
(変形例)
以上説明した第4実施形態では、データに対する署名生成や信頼性担保処理、書き込み処理などを個々のデータに対し独立に行っていた。しかし、受信した複数のデータを解析し、共通の性質を持つデータ同士をまとめて1つのデータとして扱い、署名生成や信頼性担保処理や書き込み処理をまとめて行う構成としてもよい。
図20は、本変形例に係るデータ格納装置100の機能的な構成例を示すブロック図である。図18に示した第4実施形態の構成との違いは、データ相関判定部127が追加されている点である。本実施形態では、データ相関判定部127を利用して複数のデータをまとめて1つのデータとし、まとめたデータに対して重要度を判定して、重要度に応じた信頼性担保処理を行うことを想定する。これにより、まとめたデータ全体を同じ信頼性で統一することができる。さらに、個々のデータに対して信頼性担保処理を行うよりも、処理効率が向上し記憶領域を節約できる。
データ相関判定部127は、データ転送部113から受け取った複数のデータの内容を解析し、複数のデータに共通する性質(相関関係)を求め、相関関係のある複数のデータを1つにまとめる処理部である。
ここで、データ相関判定部127が複数のデータ間に相関関係があると判定する具体例について説明する。例えば、同じ特定ルールに属するリクエストメッセージによってECU2から取得したレスポンスメッセージは、相関関係があると判定する。理由としては、異常原因を特定するには同じ特定ルールに属するレスポンスメッセージをすべて解析する必要があり、どれか1つでも欠けてしまうと正しい解析ができなくなり、異常原因を特定できない可能性があるためである。同じ特定ルールに属する複数のレスポンスメッセージを扱う際、データ蓄積部180に格納するデータ間の信頼性に差があると、その中で信頼性が最も低いデータによって全体の信頼性が決まってしまう。つまり、データ蓄積部180に格納するデータの中で信頼性が最も低いデータよりも信頼性を高めたメッセージがあっても、効果がないことになる。そのような不整合をなくすため、データ相関判定部127は、同じ特定ルールに属する複数のレスポンスメッセージから得たデータに相関関係があると判定する。
なお、受け取った複数のデータ間に相関関係があるかどうかの判定は、複数のレスポンスメッセージが同一の特定ルールに属するか否かを基準とするほかに、同一の診断ルールに属するか否かを基準としてもよいし、そのほかの要因を基準としてもよい。
データ相関判定部127が、同一ルールに属するレスポンスメッセージ間に相関関係があると判定する処理の一例を説明する。まず、データ相関判定部127は、データ転送部113から受け取ったデータが属するルールを判別する。具体的には、データ相関判定部127は、受け取ったデータの診断内容を示すサービスIDを取得し、そのサービスIDが送信メッセージ取得部111に現在設定されているルールに含まれるかを確認する。もし、受け取ったデータのサービスIDが現在設定されているルールに含まれていれば、データ相関判定部127は、相関関係があると判断し、自身の記憶領域にデータをためる。もし、ルールに含まれていなければ、データ相関判定部127は、相関関係がないと判断し、受け取ったデータをデータ監視部125に送る。データ相関判定部127は、相関関係があるデータを一定数ためると、ためたデータを1つのデータにまとめ、データ監視部125に送る。
このとき、データ相関判定部127は、相関関係があると判定したデータを一定数蓄積してから1つにまとめてもよいし、送信メッセージ取得部111に現在設定されているルールが切り替わった時点で1つにまとめてもよい。現在設定されているルールが切り替わった時点でデータを1つにまとめる理由として、ルールが切り替わると、切り替わる前のルールに属するレスポンスメッセージの受信がなくなるため、切り替わる前の相関関係があるデータを一定数ためることができなくなる可能性があるからである。この場合、相関関係があると判定したデータを一定数ためてから1つにまとめる方法だけでは、データをまとめる機会がなくなってしまう。
図21は、本変形例に係るデータ格納装置100による処理手順の一例を示すフローチャートであり、データ格納装置100が受信したリクエストメッセージを解析し、相関関係を持つ複数のデータ同士をまとめて1つのデータとして扱い、署名の付与や重要度の判定、信頼性担保処理、書き込み処理をまとめて行う処理動作の一例をまとめたものである。この図21のフローチャートで示す処理は、図4のステップS105からステップS108までの処理に代えて実施される。
本実施形態では、図4のステップS104でメッセージ処理部112がレスポンスメッセージから取り出したデータは、データ転送部113からデータ相関判定部127に渡される。データ相関判定部127は、送信メッセージ取得部111に現在設定されているルールを取得し(ステップS901)、例えば、データ転送部113から受け取ったデータの診断内容を示すサービスIDが現在設定されているルールに含まれるかをチェックすることにより、データ転送部113から受け取ったデータが現在設定されているルールに基づいて取得されたデータか否かをチェックする(ステップS902)。
ここで、データ転送部113から受け取ったデータが現在設定されているルールに基づいて取得されたデータではない場合(ステップS902:No)、データ相関判定部127は、データ転送部113から受け取ったデータを相関関係がないデータと判定し(ステップS903)、そのデータを自身の記憶領域に蓄積することなくデータ転送部113に渡す。
一方、データ転送部113から受け取ったデータが現在設定されているルールに基づいて取得されたデータである場合(ステップS902:Yes)、データ相関判定部127は、データ転送部113から受け取ったデータを相関関係があるデータと判定し、自身の記憶領域にそのデータを蓄積する(ステップS904)。そして、データ相関判定部127は、自身の記憶領域に一定数のデータが蓄積されたか否かを確認し(ステップS905)、一定数のデータが蓄積されていなければ(ステップS905:No)、図4のステップS101に戻って以降の処理を繰り返す。一方、一定数のデータが蓄積されると(ステップS905:Yes)、データ相関判定部127は、自身の記憶領域に蓄積されたデータを1つのデータにまとめ(ステップS906)、1つにまとめたデータをデータ転送部113に渡す。
データ転送部113は、データ相関判定部127から受け取ったデータを署名生成部114に渡す。署名生成部114は、鍵管理部115から署名用の鍵を読み出し(ステップS907)、その鍵を用いてデータ転送部113から受け取ったデータの署名を計算し(ステップS908)、データと署名をデータ転送部113に渡す。データ転送部113は、署名生成部114から受け取ったデータと署名をデータ監視部125に渡す。以降、図19のステップS801に進んで、図19のフローチャートで示した一連の処理が行われる。なお、データ相関判定部127が蓄積したデータを1つのデータにまとめる処理は、送信メッセージ取得部111に現在設定されているルールが切り替わった時点でもよい。
以上説明した本変形例の構成は、特に署名生成や信頼性担保処理の計算負荷の軽減という点で有用である。受信したレスポンスメッセージのデータ1つ1つに対して署名生成や信頼性担保処理を行わず、相関関係のある複数のデータを1つにまとめて、まとめたデータに対して署名生成や信頼性担保処理を行うことで、データ蓄積部180に格納するデータをロバストにしながら、同時に、署名生成や信頼性担保処理に必要な計算負荷を軽減し、記憶領域を節約することできる。
<第5実施形態>
次に、第5実施形態について説明する。上述の各実施形態では、データ格納装置100がECU2に向けて自発的にリクエストメッセージを送信し、ECU2の設定情報や動作状態、診断結果などを取得してデータ蓄積部180に蓄積する構成を示した。リクエストメッセージの送信やECU2から情報を取得する動作を実現するのは、データ格納装置100上で動作するソフトウェアプログラムである。ソフトウェアプログラムにバグや脆弱性がなく、問題なく動作することを前提にすれば、そのソフトウェアプログラムによって取得したデータはデータ格納装置100内で改ざんされる虞はない。
上述の各実施形態では、データ格納装置100上で動作するソフトウェアプログラムに問題がないことを前提としているため、データ格納装置100で動作するソフトウェアプログラムの動作は記録していなかった。これに対し、第5実施形態では、ソフトウェアプログラムにバグや脆弱性が存在する場合があることも想定し、データ格納装置100がECU2の情報を取得してデータ蓄積部180に蓄積することと併せて、データ格納装置100自身の状態も記録するものである。具体的には、データ格納装置100がECU2の情報を取得してデータ蓄積部180に蓄積する間、メインメモリ150の内容をダンプし、データ格納装置100上で動作するソフトウェアプログラムの動作を記録する。
データ格納装置100が取得してデータ蓄積部180に蓄積したECU2の設定情報、動作状態および診断結果などを事故原因の特定のような第三者による分析に利用することを想定した場合、データが改ざんされていないかどうかの確認に加え、それらのデータを収集した機器が正常に動作していたかどうかの確認が必要になる。データ格納装置100から読み出したデータが改ざんされていないかどうかの確認は、上述の第1実施形態で述べたように、データに付与された署名を検証することで行う。データ格納装置100が正常に動作していたかどうかの確認は、本実施形態で述べるように、データ格納装置100上で動作するソフトウェアプログラムの動作を記録したメモリダンプを分析することで行う。データ格納装置100が蓄積したデータの改ざんをチェックすることに加え、データ格納装置100自身の動作に問題がなかったことを確認することで、分析に利用するデータだけでなく、そのデータを収集したデータ格納装置100そのものの信頼性も高めることができる。
図22は、第5実施形態に係るデータ格納装置100の機能的な構成例を示すブロック図である。図3に示した第1実施形態の構成との違いは、動作情報収集部128が追加されている点である。なお、説明を容易にするために、ハードウェアであるメインメモリ150も図示している。
動作情報収集部128は、メインメモリ150の内容をダンプし、データ転送部113に渡す。動作情報収集部128がダンプしたメインメモリ150の内容をメモリダンプと呼ぶ。メモリダンプは、データ転送部113を経由してデータアクセス処理部116に渡り、データ蓄積部180に格納される。
動作情報収集部128は、タイマ140の割込み通知を受けた時点や、動作情報収集部128が実行された時点でメモリダンプを取得する。ここではメモリダンプを取得するタイミングをタイマ140の割込み通知を受けた時点と想定して、動作情報収集部128の動作を説明する。タイマ140の割込み通知は、発生間隔が一定時間として周期的に発生してもよいし、不定期に発生してもよい。タイマ140の割込み通知が不定期な時間間隔で発生することで、動作情報収集部128がメモリダンプを取得するタイミングが、特定の処理の前後ではなく、不特定となる。こうすることで、データ格納装置100が行う処理の決まった箇所の動作について確認するのではなく、様々な箇所の動作について確認することができ、処理全体の動作を確認できる。
ここで、動作情報収集部128がメモリダンプを取得する処理動作の一例について説明する。動作情報収集部128は、タイマ140からの割込み通知を受け取ると、メインメモリ150からメモリダンプを取得する。つぎに、動作情報収集部128は、取得したメモリダンプをデータ転送部113に渡す。データ転送部113は受け取ったメモリダンプと書き込み指示をデータアクセス処理部116に渡す。データアクセス処理部116は、受け取ったメモリダンプと自身で生成した書き込み先情報をデータ蓄積部180に渡す。データ蓄積部180は書き込み先情報により指定された書き込み先に、メモリダンプを格納する。
以上説明した本実施形態の構成は、データを取得して蓄積している最中のデータ格納装置100の動作を検証することで、特にデータ格納装置100が蓄積するデータの信頼性を高める効果がある。データ格納装置100は記録データに署名を付与することで、記録データの改ざんの有無を確認することができる。しかし、データ格納装置100のソフトウェアプログラムにバグがあり正しくデータを蓄積できない場合や、データ格納装置100のソフトウェアに脆弱性があり、不正なプログラムに乗っ取られ、データ格納装置100内部でデータの改ざんが発生する場合など、データ格納装置100自体の動作に問題がある場合、署名を付与する前の記録データがそもそも信頼できない可能性が生じる。このような事態が起こることを想定し、データ蓄積部180に格納されたメモリダンプを分析することで、データ格納装置100で動作するソフトウェアがどのような動作をしていたかを知ることができる。仮に、署名を付与する前に記録データの改ざんが判明すれば、そのデータを信頼できないことが分かる。また、不正なプログラムが動作情報収集部128を止めてしまう可能性が考えられるが、データ蓄積部180にメモリダンプが格納されていないことで、ソフトウェアプログラムの動作異常を知ることができる。
なお、動作情報収集部128が取得したメモリダンプの改ざんを防止するため、メモリダンプに署名を付与してもよい。例えば、動作情報収集部128からメモリダンプを受け取ったデータ転送部113は、データアクセス処理部116ではなく署名生成部114にメモリダンプを渡す。署名生成部114は、メモリダンプの署名を計算し、メモリダンプと署名をデータ転送部113に渡す。その後、データ転送部113は、署名生成部114から受け取ったメモリダンプと署名をデータアクセス処理部116に渡し、データ蓄積部180にそれらを格納させる。
<第6実施形態>
次に、第6実施形態について説明する。上述の各実施形態では、データ蓄積部180へのアクセスはデータアクセス処理部116を介して物理アドレスで行っていた。具体的には、データ蓄積部180に格納された記録データを読み出す場合、データ格納装置100は、外部から受け取った読み出し先を指定する情報をデータアクセス処理部116で物理アドレスに変換し、データ蓄積部180から指定された記録データを読み出す。ここで、上述の各実施形態では、ネットワークバス5を介して読み出した記録データを送信することを想定していた。外部に記録データを送信する場合、データ格納装置100は、ネットワークバス5を介して記録データの読み出し指示を受信し、読み出し指示から実際にデータ蓄積部180に書き込まれたデータを指定する物理アドレスを計算し、読み出したデータをネットワークバス5に送信していた。
これに対し第6実施形態では、データ蓄積部180へのアクセスにLBA(論理ブロックアドレス)を使用し、一般的なデータ格納装置(ストレージ製品)に使われる汎用インタフェースから記録データを読み出すことができるようにしたものである。データ蓄積部180へのアクセスにLBAを使用することで、一般的なストレージ製品に使われているSASやSATAといった汎用インタフェースを経由して、データ格納装置100から記録データを読み出すことが可能になる。ネットワークバス5で想定されているCANなどの車載ネットワークの通信速度より、SASやSATAといった汎用インタフェースの読み出し速度の方が速いため、記録データを読み出す時間を短縮できる。さらに、汎用インタフェースは一般的なPC(パーソナルコンピュータ)が備えているため、専用の通信インタフェースがなくても、データ格納装置100とPCを接続し、データを読み出すことが可能になる。
図23は、第6実施形態に係るデータ格納装置100の機能的な構成例を示すブロック図である。図3に示した第1実施形態の構成との違いは、ハードウェアとしてストレージI/F200が追加されているとともに、LBA対応部131とファイルシステム生成部132とファイルシステム管理部133とが追加されている点である。
ストレージI/F200は、データ格納装置100と外部装置7を接続するためのインタフェースであり、図2に示した基板190上に搭載されている。外部装置7はストレージI/F200を介して、データアクセス処理部116に指示を送り、データ蓄積部180にアクセスする。このとき、外部装置7はアクセスする場所の指定に、LBAを使用する。なお、ストレージI/F200が接続するバスの規格は一般的なストレージ向け汎用インタフェース規格、例えばSAS,SATAなどを想定している。そのためSAS,SATAといったインタフェースを持つPCにデータ格納装置100を接続し、PCからデータ蓄積部180に格納された記録データにアクセスすることができる。なお、データアクセス処理部116は、ストレージI/F200からデータ蓄積部180へのデータの書き込みを禁止し、読み出しを許可してもよい。
LBA対応部131は、データアクセス処理部116で管理するデータを用い、LBAと物理アドレスの対応付けを行う処理部である。LBA対応部131は、例えば図24に示すようなLBAと物理アドレスの変換テーブルを管理し、物理アドレスとLBAの対応を取っている。なお、図24に例示する変換テーブルは、LBAのブロックサイズと物理アドレスのブロックサイズが同じ場合を示しているが、異なっていてもよい。
例えば、データアクセス処理部116でウェアレベリングを実行し、データ蓄積部180のブロックの書き込み回数が平滑化された場合、記録データの保存先を示す物理アドレスが変わる可能性がある。また、あるデータを記録するブロックが壊れかけていれば、壊れかけのブロックを無効化し、別のブロックにコピーを作成するというブロックの置換を行った場合や、同じデータを複数のブロックに記録していて、参照先に設定していた一方のブロックを無効化し、同じデータを記録した別のブロックを新たな参照先として変更するブロックの交換を行った場合も、記録データの保存先を示す物理アドレスが変わる。このとき、LBA対応部131は、あるデータの物理アドレスが変更された場合、データアクセス処理部116で管理する物理アドレスを用い、LBAと物理アドレスの変換テーブルを更新する。このように、LBA対応部131がLBAと物理アドレスの変換テーブルを更新することで、物理アドレスで書き込まれたデータをLBAで参照しても、常に同じデータであることが保証される。データアクセス処理部116がデータ蓄積部180にアクセスする場合、LBAと物理アドレスとの対応関係をLBA対応部131が管理する変換テーブルから取得する。
ファイルシステム生成部132は、データ蓄積部180のフォーマットを行い、データ蓄積部180にLBAでアクセスできるようにデータアクセス処理部116の管理データを作成する処理部である。ファイルシステム生成部132は、例えば、バスI/F160が初めて車両Vに接続されたことを検出したときや、データ格納装置100に初めて電源が投入されたことを検出したときなどに、データ蓄積部180のフォーマットを実行する。
これ以外にも、外部からフォーマットの指示を受信し、ファイルシステム生成部132がこの指示に従ってデータ蓄積部180のフォーマットを実行するようにしてもよい。この場合、フォーマットはデータ蓄積部180の記録内容を消去してしまうため、ファイルシステム生成部132は、フォーマットを一度実行した後、二度目を実行しないように制限する方法や、二度目のフォーマットを実行する場合には、特定の機器からしか指示できないようにするなどの制限機能を有してもよい。なお、ファイルシステム生成部132は必須の構成要素ではなく、データ格納装置100がフォーマット済みの状態で工場出荷されてもよい。
ファイルシステム管理部133は、データ蓄積部180に書き込まれるデータをファイルとして管理するため、ファイルシステムの管理情報を作成・保持する処理部である。
ファイルシステム管理部133の機能を説明するために、まず、ファイルシステムの一例について説明する。ここで、ファイルシステム管理部133が扱うファイル形式は、ファイルとディレクトリの2種類を想定する。データ蓄積部180には、ファイルを管理するための管理データ領域が設定されている。この管理データ領域は、データ蓄積部180をフォーマットする際に確保される。
管理データ領域は、(α)管理領域の保存場所を示す領域、(β)ファイル管理領域、(γ)ディレクトリデータ管理領域、(δ)ユーザデータ領域、の4種類の領域を含む。
上記(α)の管理領域の保存場所を示す領域には、ファイル管理領域とディレクトリデータ領域の場所が記録されている。このデータは、ファイルシステムが管理するデータにアクセスするための起点となるデータである。管理領域の保存場所を示す領域は、LBAの先頭アドレスによって示される。外部装置7がファイルシステムにアクセスする際、まずLBAの先頭アドレスにアクセスし、管理領域の保存場所を参照して、ファイル管理領域とディレクトリデータ領域の場所を取得する。
上記(β)のファイル管理領域は、ファイルの性質を記した管理データ(ファイル管理データ)を記録する領域である。ファイルの本体は後述するユーザデータ領域に保存されるが、そのファイルの性質を示すデータはファイル管理領域に保存される。ファイルの性質として、ファイルタイプ、ファイルサイズ、データの保存場所の3つを記録する。ファイルタイプは、通常のファイルかディレクトリかを示すフラグである。データの保存場所は、ファイルの本体がユーザデータ領域のどこに保存されているかを示す。外部装置7がファイルにアクセスする場合、ファイル管理データを参照し、ファイル本体の保存場所を取得し、該当する場所にアクセスする。ファイル管理データはファイル毎に作られ、区別するために固有の番号が割り当てられる。なお、ファイルの性質は上記3つに限定されるものではなく、ファイル参照時刻やファイル更新時刻などその他の情報が含まれる場合もある。
上記(γ)のディレクトリデータ管理領域は、ディレクトリ内に存在するファイル名をすべて記録するディレクトデータを記録する領域である。ディレクトリデータは、ファイル名から対象ファイルのファイル管理データにアクセスできるように、ファイル名とファイル管理データの番号の表を記録する。例えば、外部装置7がファイルAにアクセスする場合、ファイルAが存在するディレクトリを参照し、そこに記録された表からファイルAに対応づけられたファイル管理データの番号を取得する。そして、取得した番号に対応するファイル管理データを参照し、ファイル本体の保存場所を取得し、ファイルにアクセスする。
上記(δ)のユーザデータ領域は、ファイル本体を記録するデータ領域である。ユーザデータ領域のどこにファイル本体が記録されているかはファイル管理データに記されている。
なお、管理データ領域は上記(α)〜(δ)の4種類に限定されるものではなく、その他に空きデータ管理領域などがあってもよい。空きデータ管理領域は、データ蓄積部180の空き領域を管理する。この空きデータ管理領域を参照することで、外部装置7がデータ蓄積部180の使用率を知ることができる。
ファイルシステム管理部133は、外部装置7が上記ファイルシステムに基づく手順でデータ蓄積部180に格納されたデータにアクセスできるように、ファイル管理情報を生成し、データに対応づけて、ファイルシステムの管理情報を更新する。ファイルシステム管理部133がファイルシステムの管理情報を更新する手順は、次のようになる。
データアクセス処理部116は、格納対象のデータを受け取ると、ファイルシステム管理部133を通じてファイルシステム経由で、格納対象のデータをデータ蓄積部180に書き込む。その際、ファイルシステム管理部133は、書き込むデータをファイルとして扱うため、ファイル管理データを生成して管理データ領域に書き込む。このファイル管理データに対し、ファイルシステム管理部133は、ファイルタイプを通常のファイルと設定し、固有の番号を割り当てる。さらに、ファイルシステム管理部133は、ファイル管理データに対応するファイル名を生成する。このとき、ファイルシステム管理部133は、異なるファイルに同じ名称が使われないように、付与するファイル名に通し番号を設定したり、ランダムな文字などを設定したりしてもよい。
ファイルシステム管理部133は、生成したファイル名とファイル管理データの番号を、記録先のディレクトリデータの表に追加し、ディレクトリデータを更新する。更新元のディレクトリデータは、ファイルシステム管理部133がデータ蓄積部180のディレクトリデータ管理領域から読み出す。なお、ファイルシステム管理部133がデータ蓄積部180に記録されている内容と同じディレクトリデータをキャッシュしていてもよい。ファイルシステム管理部133は、生成したファイル管理データと更新したディレクトリデータを、データアクセス処理部116を介してデータ蓄積部180の管理データ領域に書き込む。
ファイル本体およびファイル管理データ、ディレクトリデータを書き込む処理は、具体的に次のような手順となる。データアクセス処理部116は、ファイル本体やファイル管理データ、ディレクトリデータを含むデータの書き込み先アドレス(LBA)をLBA対応部131で物理アドレスに変換し、信頼性を高める情報などを付与して、データ蓄積部180に書き込む。
ファイルシステム管理部133がファイルシステムの管理情報を更新する別の手段として、データアクセス処理部116が物理アドレスでデータを書き込んだ後に、物理アドレスで書き込まれたデータにファイル管理データを対応づけてもよい。データアクセス処理部116は、LBA対応部131が管理するLBAと物理アドレスの変換テーブルを参照し、格納対象のデータの書き込み先情報(例えば、先頭物理アドレスとデータのサイズ)から物理アドレスに対応するLBAを取得する。ファイルシステム管理部133は、データアクセス処理部116が取得したLBAとデータのサイズを元にファイル管理データを作成する。
なお、ファイルシステム管理部133は、ファイル管理を分かりやすくするため、複数のディレクトリを作成し、ファイルを分類して記録してもよい。例えば、メッセージのID領域の値を名前にしたディレクトリを作成し、ディレクトリ名と一致するIDを持つメッセージのデータを該当するディレクトリの中に記録することで、外部装置7が記録データを参照した際に内容が分かりやすくなる。
以上のように、ファイルシステム管理部133が、ファイルシステムに基づいて格納対象のデータに管理データを付与することで、外部装置7は、データ蓄積部180に格納されたデータを、ファイルシステムに基づく手順で読み出すことができる。なお、ファイルシステム管理部133が使用するファイルシステムは、PC向けに広く使用されているFAT、FAT32、NTFS、EXT3、EXT4、XFS、HFS、HFSXなどでもよいし、独自のファイルシステムでもよい。独自のファイルシステムを使用する場合は、外部装置7が独自のファイルシステムに対応しているものとする。
図25は、本実施形態に係るデータ格納装置100による処理手順の一例を示すフローチャートであり、ストレージI/F200経由で外部装置7から読み出し指示を受け取り、データ蓄積部180からデータを読み出す処理動作の一例をまとめたものである。
データ格納装置100は、ストレージI/F200が接続するバスを介して、外部装置7からコマンドを受信する(ステップS1001)。ストレージI/F200は、受信したコマンドをデータアクセス処理部116に送る。データアクセス処理部116は、ストレージI/F200から受け取ったコマンドが読み出し指示かそれ以外かをチェックする(ステップS1002)。ここで、受け取ったコマンドが読み出し指示ではない場合(ステップS1002:No)、データアクセス処理部116は、そのコマンドを無視するようにストレージI/F200にアクセス制御を設定してもよい。一方、受け取ったコマンドが読み出し指示の場合(ステップS1002:Yes)、データアクセス処理部116は、読み出し指示から読み出し範囲としてLBAを取得し(ステップS1003)、LBA対応部131に渡す。
LBA対応部131は、変換テーブルを参照し、データアクセス処理部116から受け取ったLBAに対応する物理アドレスを取得し(ステップS1004)、データ蓄積部180に対してデータを要求する。データ蓄積部180は、読み出し命令に従いデータを読み出し(ステップS1005)、データアクセス処理部116に渡す。データアクセス処理部116は、データ蓄積部180から読み出したデータをストレージI/F200に渡す。ストレージI/F200は、データ蓄積部180から読み出したデータを外部装置7に送信する(ステップS1006)。
以上説明した本実施形態の構成は、特にデータ蓄積部180に格納されたデータを扱いやすくする上で有用である。車載ネットワーク1に使われている通信プロトコルは低コストである反面、低速であるため、記録データを読み出そうとすると、そのサイズによっては膨大な時間がかかってしまう虞がある。また、車載ネットワーク1の通信インタフェースは、一般のPCで使用するには専用の変換器や専用ソフトウェアが必要となり、扱いやすいとはいえない。ストレージ製品に一般に使われている汎用インタフェースならば、記録データを短時間で読み出すことができる。例えば、CANの伝送速度は最大1Mbpsであるが、ストレージ製品向け汎用IFのSATAは最大6Gbpsであり、6000倍の速度差がある。また、汎用インタフェースは一般的なPCに接続することができ、LBAでアクセスできることから、専用ソフトウェアを使うことなくデータを読み出すことができる。データ格納装置100に蓄積されたデータの解析に専用の装置を使わず一般のPCを利用することで、記録データの解析にかかるコストを削減することができる。
(変形例1)
以上説明した第6実施形態では、データ蓄積部180に格納されたデータを、ファイルシステムを経由してファイルとして読み出す構成としたが、オブジェクトデータを指定することでデータを読み出す構成としてもよい。オブジェクトデータ方式は、データ格納装置100にデータを格納する際、データの格納場所を特定する情報(Value)に一意な識別子(Key)を付与する。データ格納装置100に格納されたデータを読み出す際、Keyを指定することで対応するValueからデータを読み出す。
図26は、本変形例に係るデータ格納装置100の機能的な構成例を示すブロック図である。図23に示した第6実施形態の構成との違いは、オブジェクトデータ対応部134が追加されている点である。
オブジェクトデータ対応部134は、格納対象のデータに固有のKeyを割り当て、そのデータの格納場所を特定する情報(Value)とKeyの対応関係を管理する処理部である。オブジェクトデータ対応部134は、格納対象のデータを特定する情報(例えば、ファイル名など)をデータアクセス処理部116内で共有している。オブジェクトデータ対応部134は、データの格納場所を特定する情報の一例としてファイル名をValueとし、固有のKeyを生成して、Valueに割り当てる。オブジェクトデータ対応部134は、KeyとValueとの対応関係を記録したテーブルを管理する。具体的には、例えば図27に示すようなKeyとValueの対応テーブルを持つ。
オブジェクトデータ対応部134は、KeyがValueに固有の値になるように、Keyに通し番号を割り当てる。なお、同じ値のない乱数をKeyに割り当ててもよい。Valueには、記録データに対応するファイル名が記録されている。オブジェクトデータ対応部134は、データをデータ蓄積部180に書き込むたびにKeyとValueの対応関係を対応テーブルに追加していく。
オブジェクトデータ対応部134は、KeyとValueとの対応関係を記録した対応テーブルを外部装置7からの要求に応じて渡すことができる。この場合、外部装置7は、データ蓄積部180からデータを読み出す際に、オブジェクトデータ対応部134から受け取ったテーブルに基づきKeyを指定するだけで、該当するデータを読み出すことができる。
なお、KeyとValueの対応関係を記録する対応テーブルは、例えば図28に示すように、通し番号や重複のない乱数にデータの分類を示す数値を付与することで、KeyからValueの属性が分かるように記録する構成としてもよい。例えば、通し番号や重複のない乱数にメッセージIDとメッセージ種別を設定する。ここで、メッセージ種別とは、メッセージが制御データかレスポンスメッセージか、異常状態の情報を含むレスポンスメッセージかといったメッセージの内容の分類のことを示す。
この場合、オブジェクトデータ対応部134は、メッセージIDとメッセージの種別をデータ転送部113から受け取り、通し番号や重複のない乱数に追加してKeyとして設定する。外部装置7は、付与する情報をあらかじめ共有しておくことで、オブジェクトデータ対応部134から受け取った対応テーブルを参照して、Valueの属性を知ることができる。なお、Keyに付与するValueの属性はいくつでもよく、2つに限定しない。また、KeyにはメッセージIDとメッセージ種別以外の属性を設定してもよく、例えば、時刻情報やタイムスタンプといったメッセージの記録タイミングなどをKeyに付与してもよい。
本変形例では、外部装置7がデータを読み出す場合に、読み出し指示にKeyを指定する。外部装置7がKeyを指定してデータ格納装置100からデータを読み出す手順の一例を示す。まず、外部装置7が、読み出したいデータのKeyを読み出し指示に指定し、この読み出し指示を、ストレージI/F200を介してデータ格納装置100に送信する。読み出し指示を受け取ったデータ格納装置100のデータアクセス処理部116は、読み出し指示からKeyを取得し、オブジェクトデータ対応部134が持つ管理テーブルを参照し、取得したKeyに対応するValue(ファイル名)を取得する。そして、データアクセス処理部116は、取得したファイル名のファイル管理データを参照し、ファイルの書き込み先情報を取得する。そして、データアクセス処理部116は、この書き込み先情報を読み出し命令に変換して、データ蓄積部180に渡す。データ蓄積部180は、データアクセス処理部116からの読み出し命令に従ってデータを読み出し、データアクセス処理部116に渡す。データアクセス処理部116は、データ蓄積部180から読み出されたデータをストレージI/F200に渡し、外部装置7に送信する。
以上説明した本変形例の構成は、外部装置7がデータ蓄積部180に構築されたファイルシステムにアクセスすることなく、Keyをデータ格納装置100に送信するという単純な処理だけで、データ蓄積部180に格納されたデータを読み出すことができるという点で有用である。例えば、ファイルシステムを経由してデータを読み出す場合、外部装置7はファイル名を送信してデータ蓄積部180に記録されたファイル管理データを読み出し、ファイル管理データからファイルが記録されている場所を受け取り、その場所を指定してファイル本体を読み出すといった手順が必要である。一方、記録データをオブジェクトデータとして扱うことで、読み出し指示にKeyを指定するだけで、記録データを出力するまでデータ格納装置100が処理してくれる。外部装置7がストレージI/F200を経由してデータ蓄積部180にアクセスする場合に限らず、例えば、外部ネットワーク経由でデータ蓄積部180にアクセスする場合も、Keyを送信するだけでデータ格納装置100は読み出すデータを一意に特定することができる。そのため、外部装置7がデータ蓄積部180からデータを読み出す処理を単純にできる。
(変形例2)
以上説明した第6実施形態では、データ蓄積部180に格納されたデータを読み出す外部装置7を特に限定していなかったが、データを読み出す外部装置7を限定するため、認証を通過した外部装置7のみ、データ蓄積部180に格納されたデータを読み出せるようにしてもよい。
図29は、本変形例に係るデータ格納装置100の機能的な構成例を示すブロック図である。図23に示した第6実施形態の構成との違いは、外部装置認証部135が追加されている点である。
外部装置認証部135は、データ蓄積部180からデータを読み出す外部装置7を限定するため、データを読み出す権限を持つ外部装置7かどうかを確認する。データを読み出す権限を持つ外部装置7かどうかを確認する方法として、例えば、権限を持つ外部装置7しか知りえない情報を確認する方法を用いる。具体的には、パスワード認証でもよいし、MACや署名を使用した認証をしてもよい。認証にMACや署名を使用する場合、鍵管理部115で管理している鍵を使用してもよい。
データアクセス処理部116は、外部装置認証部135による認証に成功した外部装置7、つまり、データを読み出す権限を持つことが確認された外部装置7からのデータ読み出し指示のみを受け付ける。すなわち、外部装置認証部135による認証に成功した外部装置7のみが、読み出しコマンドを送信し、データ蓄積部180からデータを読み出すことができる。
以上説明した本変形例の構成は、特にデータ蓄積部180に蓄積されたデータからプライバシ情報やノウハウ情報が盗み出されることを防ぐ場合に有効である。データ格納装置100は、車両Vの走行中に車載ネットワーク1を流れるデータを大量に取得してデータ蓄積部180に格納するため、データ蓄積部180に蓄積されたデータを詳細に解析すれば、車両Vの運転手のプライバシ情報を取得することができてしまう可能性がある。そこで、上述した本変形例の構成により、データ蓄積部180にアクセス可能な外部装置7を制限することで、意図しない情報流出を防止することができる。
以上述べた少なくとも1つの実施形態によれば、従来のホストに相当する機能を内蔵し、自発的にデータを取得して蓄積することが可能なデータ格納装置を提供することができる。
以上、本発明の実施形態を説明したが、この実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。