JP2018156452A - データ格納装置 - Google Patents

Abstract

【課題】ホストに相当する機能を内蔵し、自発的にデータを取得して蓄積することが可能なデータ格納装置を提供する。【解決手段】実施形態のデータ格納装置は、車載ネットワークに接続されるデータ格納装置であって、データ蓄積部と、バスインタフェースと、プロセッサと、を備える。データ蓄積部は、ＮＡＮＤインタフェースを備える。バスインタフェースは、前記データ蓄積部と同一基板上に搭載され、前記車載ネットワークのバスに接続される。プロセッサは、前記データ蓄積部および前記バスインタフェースと同一基板上に搭載され、前記バスインタフェースを介して前記車載ネットワークから自発的にデータを取得して前記データ蓄積部に蓄積するように、前記データ格納装置の動作を制御する。【選択図】図２

Description

本発明の実施形態は、車載ネットワークに接続されるデータ格納装置に関する。

従来、車両に搭載された各種の電子制御ユニット（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）が車載ネットワークで接続される構成の車載システムにおいて、ＥＣＵの動作や通信内容を記録し、ＥＣＵの診断、燃費計測、運転状況の評価などに利用することが行われている。このような用途で利用されるデータの記録には、一般に、データロガーや診断装置のように、受動的にデータが格納されるデータ格納装置が用いられる。

従来のデータ格納装置を車載ネットワークに接続して利用するには、データ格納装置とは別に、データ格納装置を制御するためのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｃｅｓｓｉｎｇ Ｕｎｉｔ）などの汎用プロセッサを備え、車載ネットワークに接続する機能を持ったホスト（外部装置）が必要となる。データ格納装置とホストが分かれていると、データ格納装置とホストのどちらかに突然の電源断が発生し、書き込み中のデータが失われた場合や、データ格納装置とホストをつなぐ通信経路上でノイズによるデータ化けが発生した場合、異常の原因がデータ格納装置にあるのかホストにあるのかを特定することが困難である。

特許第３１２９１０２号公報 特許第３３６８８８２号公報 特許第５７２８７０１号公報

本発明が解決しようとする課題は、ホストに相当する機能を内蔵し、自発的にデータを取得して蓄積することが可能なデータ格納装置を提供することである。

実施形態のデータ格納装置は、車載ネットワークに接続されるデータ格納装置であって、データ蓄積部と、バスインタフェースと、プロセッサと、を備える。データ蓄積部は、ＮＡＮＤインタフェースを備える。バスインタフェースは、前記データ蓄積部と同一基板上に搭載され、前記車載ネットワークのバスに接続される。プロセッサは、前記データ蓄積部および前記バスインタフェースと同一基板上に搭載され、前記バスインタフェースを介して前記車載ネットワークから自発的にデータを取得して前記データ蓄積部に格納するように、前記データ格納装置の動作を制御する。前記プロセッサは、メッセージ処理部と、データアクセス処理部と、を有する。メッセージ処理部は、前記バスインタフェースを介して、前記車載ネットワークに接続された電子制御ユニットまたは外部装置とメッセージを送受信する。データアクセス処理部は、前記データ蓄積部に対しデータの書き込みおよび読み出しを指示する。前記メッセージ処理部により受信されたメッセージに含まれるデータが、前記データアクセス処理部の指示に応じて前記データ蓄積部に書き込まれる。

車載ネットワークの全体構成を概略的に示す図。 データ格納装置のハードウェア構成の一例を概略的に示すブロック図。 第１実施形態に係るデータ格納装置の機能的な構成例を示すブロック図。 第１実施形態に係るデータ格納装置による処理手順の一例を示すフローチャート。 第１実施形態に係るデータ格納装置による処理手順の一例を示すフローチャート。 第１実施形態の変形例に係るデータ格納装置の機能的な構成例を示すブロック図。 第１実施形態の変形例に係るデータ格納装置による処理手順の一例を示すフローチャート。 第２実施形態に係るデータ格納装置の機能的な構成例を示すブロック図。 異常状態と特定ルールとの対応関係の一例を示す図。 第２実施形態に係るデータ格納装置による処理手順の一例を示すフローチャート。 第２実施形態の変形例に係るデータ格納装置の機能的な構成例を示すブロック図。 ルールセットとルールの対応関係および車種とルールセットの対応関係の一例を示す図。 第２実施形態の変形例に係るデータ格納装置による処理手順の一例を示すフローチャート。 第３実施形態に係るデータ格納装置の機能的な構成例を示すブロック図。 第３実施形態に係るデータ格納装置による処理手順の一例を示すフローチャート。 第３実施形態の変形例に係るデータ格納装置の機能的な構成例を示すブロック図。 第３実施形態の変形例に係るデータ格納装置による処理手順の一例を示すフローチャート。 第４実施形態に係るデータ格納装置の機能的な構成例を示すブロック図。 第４実施形態に係るデータ格納装置による処理手順の一例を示すフローチャート。 第４実施形態の変形例に係るデータ格納装置の機能的な構成例を示すブロック図。 第４実施形態の変形例に係るデータ格納装置による処理手順の一例を示すフローチャート。 第５実施形態に係るデータ格納装置の機能的な構成例を示すブロック図。 第６実施形態に係るデータ格納装置の機能的な構成例を示すブロック図。 ＬＢＡと物理アドレスの変換テーブルの一例を示す図。 第６実施形態に係るデータ格納装置による処理手順の一例を示すフローチャート。 第６実施形態の変形例１に係るデータ格納装置の機能的な構成例を示すブロック図。 ＫｅｙとＶａｌｕｅの対応テーブルの一例を示す図。 ＫｅｙとＶａｌｕｅの対応テーブルの他の例を示す図。 第６実施形態の変形例２に係るデータ格納装置の機能的な構成例を示すブロック図。

実施形態のデータ格納装置は車載ネットワークに接続され、車載ネットワーク上の電子制御ユニット（以下、ＥＣＵという）などから自発的にデータを取得して蓄積する。車載ネットワークに接続される従来のデータ格納装置は、ホストの命令に従って受動的にデータを格納する構成であるため、ＥＣＵなどが出力するデータを蓄積するには、車載ネットワークにホストを接続して使用する必要があった。これに対し、実施形態のデータ格納装置は、従来のホストに相当する機能を内蔵し、車載ネットワークに接続されると自発的に車載ネットワークからデータを取得して蓄積する新規な構成を有する。

ここで、自発的なデータの取得および蓄積とは、外部装置からの書き込み指示などによらずにデータを取得して蓄積すること意味する。自発的なデータの取得および蓄積の一例として、例えば、車載ネットワーク上のＥＣＵなどにデータ要求のリクエストメッセージを送信し、このリクエストメッセージに対するレスポンスメッセージを受信して、レスポンスメッセージに含まれるデータを取得して蓄積する例がある。また、車載ネットワークのネットワークバスを流れるメッセージの全部、あるいは予め定められた受信すべきメッセージを受信し、そのメッセージに含まれるデータを取得して蓄積することも、自発的なデータの取得および蓄積に含まれる。

以下、実施形態のデータ格納装置の詳細について、図面を参照しながら説明する。なお、以下の説明において、同様の機能を持つ構成要素については同一の符号を付して、重複した説明を適宜省略する。

＜第１実施形態＞
図１は、車載ネットワーク１の全体構成を概略的に示す図である。この車載ネットワーク１は、例えば、自動車などの車両Ｖに搭載された複数のＥＣＵ（図１では４つのＥＣＵ２ａ〜２ｄを例示している）を連携させた車両制御を実現するために用いられる。すなわち、車載ネットワーク１に接続された複数のＥＣＵ間で車両制御に必要なデータを通信することにより、複数のＥＣＵを連携させた車両制御が実現される。なお、図１では、車載ネットワーク１の構成を分かり易く図示するために、車載ネットワーク１に接続された複数のＥＣＵとして４つのＥＣＵ２ａ〜２ｄのみを図示しているが、車載ネットワーク１に接続されるＥＣＵの数は任意である。以下では、車載ネットワーク１に接続されたＥＣＵを特に区別せずに総称する場合、ＥＣＵ２と表記する。

図１に示す車載ネットワーク１は、複数のＥＣＵ２（２ａ〜２ｄ）のほか、通信装置３、無線通信Ｉ／Ｆ（インタフェース）４、および実施形態のデータ格納装置１００を備える。ＥＣＵ２、通信装置３、およびデータ格納装置１００はネットワークバス５によって接続されており、ネットワークバス５を通じてメッセージを送受信することで互いに通信できるようになっている。ネットワークバス５は、車載用に適用可能な一般的な通信プロトコルに対応したものを使用できる。例えば、ＣＡＮ、ＣＡＮ−ＦＤ、Ｅｔｈｅｒｎｅｔ（登録商標）、ＦｌｅｘＲａｙ（登録商標）、ＭＯＳＴ、ＬＩＮ、ＣＸＰＩなどに対応したものを用いることができる。

無線通信Ｉ／Ｆ４は、通信装置３に接続されている。無線通信Ｉ／Ｆ４は、外部装置（外部サーバなど）７と通信装置３をつなぐための物理インタフェースである。無線通信Ｉ／Ｆ４が利用する通信方式は３ＧＰＰ（登録商標）、ＬＴＥ（登録商標）といった携帯電話システム、またはＷｉ−Ｆｉ（登録商標）を用いることができる。

通信装置３は、無線通信Ｉ／Ｆ４を介して外部装置７と通信することができる。また、通信装置３は、ネットワークバス５を介してデータ格納装置１００やＥＣＵ２と通信することもできる。そのため、通信装置３は、外部装置７から受信したデータをデータ格納装置１００やＥＣＵ２に送信したり、データ格納装置１００やＥＣＵ２から受信したデータを外部装置７に送信したりすることができる。

ＥＣＵ２は、車載装置を制御する電子制御ユニットである。車載装置とは、車両Ｖに搭載される機械的・電子的装置のことであり、エンジンのような駆動系に分類される装置のほか、車内灯や窓のような車体系に分類される装置、ナビゲーションやフロントパネルのような情報系に分類される装置、アンチロックブレーキングシステム（ＡＢＳ）やブレーキのような走行系に分類される装置などがある。例えば、ＥＣＵ２ａは駆動系のエンジンを制御し、ＥＣＵ２ｂは車体系の車内灯を制御し、ＥＣＵ２ｃは情報系のナビゲーションを制御し、ＥＣＵ２ｄは走行系のＡＢＳを制御する。また、ＥＣＵ２ａが制御する車載装置は駆動系に限られるものではなく、車体系や情報系、走行系に分類される車載装置を制御してもよい。これはＥＣＵ２ｂ〜２ｄも同様である。また、１つのＥＣＵ２が複数の車載装置を制御してもよい。

車載装置が車両Ｖの状態に応じた制御を行うため、ＥＣＵ２は、他のＥＣＵ２とネットワークバス５を介して通信する。例えば、ＥＣＵ２が制御している車載装置を操作するための制御データや制御対象の車載装置の動作状態を他のＥＣＵ２に送信し、また、他のＥＣＵ２から同等の情報を受信する。なお、ＥＣＵ２が他のＥＣＵ２とネットワークバス５を介して通信するデータは制御データや動作状態に限らず、後述するＥＣＵ２自身の動作状態やＥＣＵ２が持つ機能の異常状態などであってもよい。

ＥＣＵ２は、メッセージを送受信して他のＥＣＵ２と通信する。通信プロトコルとしてＣＡＮを例に取ると、メッセージは、ＩＤ領域と、送信先に渡すデータ領域との少なくとも２つの領域を持つ。ＩＤ領域には、メッセージの送信元や送信先を示す情報や、メッセージを区別するためのＩＤを含んでもよい。データ領域には他のＥＣＵ２に渡すデータや、後述する診断プロトコルに基づき、ＥＣＵ２が実行した診断処理の結果を含んでもよい。ＣＡＮは、ＥＣＵ２がネットワークバス５にメッセージを送り出すと、ネットワークバス５につながるすべての機器（ＥＣＵ２ａ〜２ｄ、通信装置３、およびデータ格納装置１００）がメッセージを受信するブロードキャストベースの通信プロトコルである。メッセージを受信した機器はメッセージのＩＤを見て、どのようなデータか、自分が処理すべきデータかを判断する。

ＥＣＵ２は、制御対象の車載装置およびＥＣＵ２自身が故障した場合に備え、制御対象の車載装置およびＥＣＵ２自身を診断する機能を有する。診断機能は主に二種類に大別され、そのうちの１つは、ＥＣＵ２内部で記録されるデータをネットワークバス５上に出力する機能であり、ＥＣＵ２自身の設定情報や動作状態、または制御対象の車載装置の動作状態をメッセージとして出力する。例えば、ＥＣＵ２ａ自身の設定情報として、エンジン点火タイミングやスピードリミッタの速度設定、ファームウェアのバージョンなどがあり、ＥＣＵ２ａ自身の動作状態として、ＥＣＵ２ａに供給されているバッテリ電圧値などがある。制御対象の車載装置の動作状態としてエンジン回転数や速度、ラジエータの冷却水の温度などがある。なお、ＥＣＵ２の設定情報や動作状態は、ＥＣＵ２の設計や有する機能、ＥＣＵ２が制御する車載装置の分類によって変わる。

もう１つの診断機能は、ＥＣＵ２が持つ機能または制御対象の車載装置が持つ機能をＥＣＵ２自身がチェックし、異常が見つかれば、異常状態が発生している機能と異常状態の内容をメッセージとしてネットワークバス５上に出力するものである。例えば、ＥＣＵ２ａが持つ機能に生じる異常状態として電圧の異常、配線短絡・開放などがあり、車載装置が持つ機能に生じる異常状態として吸気温センサの入力電圧異常や排気再循環センサ入力のＧＮＤショート故障などがある。

ここで、ＥＣＵ２に対してデータ格納装置１００が診断の実行を指示するメッセージ（リクエストメッセージ）およびＥＣＵ２がネットワークバス５上に出力する診断結果のメッセージ（レスポンスメッセージ）について説明する。リクエストメッセージは、データ格納装置１００がＥＣＵ２に対して診断の実行を指示するメッセージである。ＥＣＵ２は診断対象となる機能を複数持っていてもよく、また一度に実行できる診断の数は限られていることもあるため、ＥＣＵ２が持つ診断機能のうち、どの診断機能を実行するかをデータ格納装置１００がリクエストメッセージで指示する。例えば、ＥＣＵ２ａが複数の設定情報を持つ場合、リクエストメッセージは、その中からどの設定情報を出力させるかをデータ格納装置１００がＥＣＵ２ａに指示する役割を持つ。なお、リクエストメッセージが指示する内容は診断の実行に限らず、ＥＣＵ２への各種指示に用いてもよい。例えば、異常と診断した結果を再度出力することのないようレスポンスメッセージの出力を抑制する指示をリクエストメッセージに載せてもよい。

レスポンスメッセージは、ＥＣＵ２の診断結果を示すメッセージである。ＥＣＵ２が正常に診断を実行した場合、ＥＣＵ２が出力するレスポンスメッセージには、次の（１）〜（３）に示す情報のうちいずれかが記載される。（１）ＥＣＵ２自身の設定情報や動作状態、（２）制御対象の車載装置の動作状態、（３）ＥＣＵ２が持つ機能または制御対象の車載装置が持つ機能の異常の有無や状態。一方、リクエストメッセージが指示する診断機能をＥＣＵ２が有していなかった場合、あるいは車両Ｖの状況によってＥＣＵ２が要求された診断機能を実行できなかった場合、ＥＣＵ２が出力するレスポンスメッセージには、診断を実行できなかったことを示す情報が記載される。なお、ＥＣＵ２が診断を実行し、その結果を出力するきっかけは、リクエストメッセージを受信したときだけでなく、ＥＣＵ２自身の判断でもよい。例えば、ＥＣＵ２が定期的に診断を実行し、結果を出力してもよい。

ＥＣＵ２が扱うリクエストメッセージやレスポンスメッセージは、標準規格化されたＥＣＵ向け診断プロトコルの規格を用いることを想定している。診断プロトコルの規格として、例えば、ＵＤＳ（ＩＳＯ １４２２９）のほかに、ＫＷＰ（ＩＳＯ １４３２０）、ＯＢＤ（ＩＳＯ １５０２１， ＳＡＥ Ｊ１９７９）、ＷＷＨ−ＯＢＤ（ＩＳＯ ２７１４５）、１９３９（ＳＡＥ Ｊ１９３９）を利用してもよい。

ＥＣＵ２がリクエストメッセージおよびレスポンスメッセージを用いて他のＥＣＵ２と通信する際、ネットワークバス５が対応する通信プロトコルを使用して行う。具体的には、メッセージのデータ領域にリクエストメッセージやレスポンスメッセージの情報を設定する。受信側はメッセージのデータ領域の内容を見て、診断内容を判断する。通信プロトコルとＥＣＵ向け診断プロトコルを組み合わせた規格として、例えばＵＤＳ ｏｎ ＣＡＮ、ＵＤＳ ｏｎ ＬＩＮがあり、これらの規格を利用してもよい。

次に、以上のような車載ネットワーク１に接続して使用される実施形態のデータ格納装置１００の詳細について説明する。図２は、実施形態のデータ格納装置１００のハードウェア構成の一例を概略的に示すブロック図である。このデータ格納装置１００としては、例えばＮＡＮＤフラッシュメモリを搭載する装置を想定している。

データ格納装置１００は、図２に示すように、プロセッサ１１０と、タイマ１４０と、メインメモリ１５０と、バスＩ／Ｆ１６０と、ブリッジ１７０と、データ蓄積部１８０とを備える。これら各部は同一の基板１９０上に搭載され、基板１９０上の配線などを用いた内部バス１９１，１９２を介して、図２に示すように接続されている。

バスＩ／Ｆ１６０は、ネットワークバス５によって車載ネットワーク１に接続されている。プロセッサ１１０、メインメモリ１５０、バスＩ／Ｆ１６０、およびブリッジ１７０は内部バス１９１によって接続されている。データ蓄積部１８０はブリッジ１７０と内部バス１９２によって接続されている。タイマ１４０はプロセッサ１１０に接続されている。

プロセッサ１１０は、メインメモリ１５０からロードした命令やデータを逐次的に処理し、処理した結果をメインメモリ１５０に記憶させる。例えば、プロセッサ１１０は、メインメモリ１５０を使用して所定の制御プログラム（ソフトウェアプログラム）を実行することにより、後述の機能的な構成要素を実現する。このプロセッサ１１０は、例えば、ＡＲＭ（登録商標）Ｃｏｒｔｅｘ−Ｍシリーズのような汎用プロセッサである。

タイマ１４０は、設定に従って一定周期で割込みを発生させる機能を有する。プロセッサ１１０で動作するソフトウェアは、この割込みをハンドルすることで、周期的に特定の処理を実行させることができる。

メインメモリ１５０は、汎用の主記憶装置である。例えば、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）やＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＭＲＡＭ（Ｍａｇｎｅｔｉｃ ＲＡＭ）などをメインメモリ１５０として用いることができる。

ブリッジ１７０は、内部バス１９１と内部バス１９２とを接続するブリッジコントローラである。通信プロトコルが異なる内部バス１９１と内部バス１９２の間でそれぞれのバスアクセスを変換し、内部バス１９１につながる各部（プロセッサ１１０やメインメモリ１５０、バスＩ／Ｆ１６０）と、内部バス１９２につながるデータ蓄積部１８０との間で命令やデータのやり取りを可能にする。

データ蓄積部１８０は記憶装置を有し、プロセッサ１１０の命令に基づき、ネットワークバス５から受信したメッセージや内部バス１９１を流れるデータを記憶装置に格納したり、記憶装置から読み出したデータをプロセッサ１１０に出力したりする。データ蓄積部１８０が持つ記憶装置として、コントローラを含まないＮＡＮＤフラッシュメモリまたはコントローラを含むＮＡＮＤフラッシュメモリを想定している。つまり、データ蓄積部１８０は、プロセッサ１１０の命令に基づいてＮＡＮＤフラッシュメモリにデータを入出力するＮＡＮＤインタフェースを備える。コントローラを含まないＮＡＮＤフラッシュメモリは、書き込み回数の平滑化を行うウェアレベリング機能や不良ブロックの管理機能、エラー訂正機能、論理アドレスでのアクセス機能を持たない。このため、データ蓄積部１８０の記憶装置としてコントローラを含まないＮＡＮＤフラッシュメモリを使用する場合、データの書き込み時と読み出し時はプロセッサ１１０が物理アドレスを指定してデータ蓄積部１８０にアクセスする。コントローラを含むＮＡＮＤフラッシュメモリを使用する場合、アクセスする記憶領域の指定には物理アドレスではなく論理ブロックアドレス（ＬＢＡ）を用いる。コントローラを含むＮＡＮＤフラッシュメモリとして、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、ＳＤカードのようなメモリカード、ＵＳＢメモリを利用してもよい。

バスＩ／Ｆ１６０は、車載ネットワーク１のネットワークバス５にデータ格納装置１００を接続するためのインタフェースである。バスＩ／Ｆ１６０は、ネットワークバス５に流れるメッセージを取得してメッセージのＩＤを確認し、データ格納装置１００が処理すべきメッセージのＩＤであればプロセッサ１１０にメッセージ受信を通知し、内部バス１９１につながるメインメモリ１５０に取得したメッセージを書き込む。一方、データ格納装置１００が処理すべきメッセージのＩＤでなければ、プロセッサ１１０に通知せずにメッセージを破棄する。逆に、プロセッサ１１０やメインメモリ１５０からネットワークバス５にメッセージを送る際は、バスＩ／Ｆ１６０がメインメモリ１５０から読み出したメッセージをネットワークバス５に送信する。なお、バスＩ／Ｆ１６０は、ネットワークバス５にメッセージを送信する際、他の機器から同時にメッセージを送信された場合に生じる送信メッセージの衝突を検知する機能を有してもよいし、さらに衝突したメッセージを再送する機能を有してもよい。

一般的なデータ格納装置の場合、データ格納装置を制御するためのプロセッサと制御用プログラムを持つホストが必要である。ホストとデータ格納装置とが汎用ＩＦで接続され、ホストがデータ格納装置に対してデータの読み出しや書き込みを指示する。データ格納装置はホストの指示に従い、汎用ＩＦを通じて受動的にデータの読み出しや書き込みを実行するだけである。一方、実施形態のデータ格納装置１００は、従来のホストに相当する機能を実現するプロセッサ１１０を持ち、データ蓄積部１８０に対するデータの読み出しや書き込みを受動的に行うのではなく、後述するようにバスＩ／Ｆ１６０を介して自発的にメッセージの送受信を行い、車載ネットワーク１から取得したデータをデータ蓄積部１８０に蓄積したり、データ蓄積部１８０から読み出したデータを車載ネットワーク１に出力したりする。

図３は、第１実施形態に係るデータ格納装置１００の機能的な構成例を示すブロック図である。図３に示すように、データ格納装置１００は、送信メッセージ取得部１１１、メッセージ処理部１１２、データ転送部１１３、署名生成部１１４、鍵管理部１１５、およびデータアクセス処理部１１６を備える。これらの各処理部は、上述したように、プロセッサ１１０が所定の制御プログラムを実行することにより実現される。すなわち、プロセッサ１１０が上記の各処理部を有する。なお、説明を容易にするために、ハードウェアであるバスＩ／Ｆ１６０とタイマ１４０とデータ蓄積部１８０も上記の各処理部とともに図３で図示している。

送信メッセージ取得部１１１、メッセージ処理部１１２、データ転送部１１３、署名生成部１１４、鍵管理部１１５、およびデータアクセス処理部１１６は、例えば、プロセッサ１１０が所定のプログラムを実行することにより実現される。このプログラムは、例えばデータ蓄積部１８０に保存されており、データ格納装置１００が起動するとデータ蓄積部１８０からメインメモリ１５０に読み出され、プロセッサ１１０により実行される。

送信メッセージ取得部１１１は、タイマ１４０から割込み通知を受け取ると、自身が持つ送信メッセージの中から次に送信するメッセージを選択し、メッセージ処理部１１２に渡す。例えば、送信メッセージ取得部１１１は、宛先が記載されたメッセージを蓄積するメッセージキューとあらかじめメッセージの送信先のＩＤが記載されたリストを持つ。送信メッセージ取得部１１１は、メッセージキューに蓄積されたメッセージとリストと照らし合わせて、送信先のＩＤをメッセージに埋め込んで、次に送信するメッセージとして選択する。本実施形態では、上述の診断機能を持つＥＣＵ２のすべてがメッセージの送信先としてリストに登録されていることを想定する。

メッセージ処理部１１２は、送信メッセージ取得部１１１から受け取ったメッセージを、バスＩ／Ｆ１６０を介してネットワークバス５に送出する。送信メッセージ取得部１１１が持つメッセージは、ＥＣＵ２（２ａ〜２ｄ）に対して診断を要求するリクエストメッセージが挙げられる。データ格納装置１００は、リクエストメッセージを送信してＥＣＵ２に診断実行を指示し、ＥＣＵ２から送信されるレスポンスメッセージを収集して、ＥＣＵ２やＥＣＵ２が制御する車載装置の設定や異常状態を自発的にデータ蓄積部１８０に蓄積することができる。

メッセージ処理部１１２は、ネットワークバス５に接続されたＥＣＵ２や通信装置３との間でバスＩ／Ｆ１６０を介してメッセージを送受信する。メッセージ処理部１１２は、送信メッセージ取得部１１１からリクエストメッセージを受け取ると、バスＩ／Ｆ１６０を介してそのメッセージをネットワークバス５に送出する。また、リクエストメッセージを受信したＥＣＵ２からレスポンスメッセージを受け取るため、メッセージ処理部１１２はメッセージ受信待ちになる。その後、メッセージ処理部１１２は、バスＩ／Ｆ１６０を介してＥＣＵ２からレスポンスメッセージを受け取ると、レスポンスメッセージからデータ領域の内容を取得し、データ転送部１１３に渡す。このとき、ＩＤ領域の内容も一緒にデータ転送部１１３に渡してもよい。メッセージ処理部１１２が受信するメッセージは、ＥＣＵ２から送信されるレスポンスメッセージの他に、ＥＣＵ２（２ａ〜２ｄ）の間で送受信される制御メッセージなどがある。これらのメッセージに含まれるデータは、いずれもデータ蓄積部１８０に蓄積するデータである。それ以外にデータ蓄積部１８０に格納されたデータ（記録データ）の読み出しを指示するメッセージがある。このメッセージを受信した場合も、メッセージ処理部１１２は、レスポンスメッセージの場合と同様に、受信したメッセージからデータとして読み出し指示を取得して、データ転送部１１３に渡す。

データ転送部１１３は、他の処理部から受け取ったデータを署名生成部１１４またはデータアクセス処理部１１６に転送する。データ転送部１１３は、受け取ったデータによって転送先をどこにするかを決める条件を持ち、その条件に従いデータの転送先を決める。例えば、メッセージ処理部１１２からＥＣＵ２の診断処理の結果を示す診断データを受け取った場合、データ転送部１１３は、そのＥＣＵ２の診断データに署名を付与するため署名生成部１１４に診断データを転送する。このとき、診断データだけでなくＩＤ領域の内容にも署名を付与するため、診断データと一緒にＩＤ領域の内容も署名生成部１１４に転送してもよい。また、署名生成部１１４から署名が付与された診断データを受け取った場合、データ転送部１１３は、署名が付与された診断データをデータ蓄積部１８０に書き込むため、データアクセス処理部１１６に署名が付与された診断データを転送する。このとき、データアクセス処理部１１６は、署名が付与された診断データと一緒に書き込み先情報をデータ蓄積部１８０に渡し、署名が付与された診断データをどこに書き込むかを指示する。また、データ転送部１１３は、メッセージ処理部１１２からデータ蓄積部１８０に格納された記録データの読み出し指示を受け取った場合、読み出し指示をデータアクセス処理部１１６に転送する。

データ転送部１１３は、転送するデータの属性を転送先に伝えるため、転送するデータにメタデータを付与してもよい。メタデータとして、例えば、外部から受信したのか内部で生成されたのかを示すメタデータ、署名の有無を示すメタデータ、機密か公開かを示すメタデータなどがある。例えば、内部で生成されるデータとして、署名や受信したデータの性質を示すデータ（重要度、複数のデータ間の関連性など）がある。このようなデータに内部で生成されたことを示すメタデータが付与されてデータアクセス処理部１１６に転送されると、データを受け取ったデータアクセス処理部１１６はメタデータを参照することで、データの属性を知ることができる。蓄積対象のデータに付与されたメタデータはデータと一緒にデータ蓄積部１８０に格納される。また、データ蓄積部１８０から記録データを読み出すための読み出し指示は、データ格納装置１００の外部が起点になる場合と、データ格納装置１００の内部が起点になる場合の二種類がある。このため、読み出し指示の送信元を区別するためのメタデータが付与される。なお、データにメタデータを付与する処理部はデータ転送部１１３に限らず、他の処理部でメタデータを付与してもよい。

データアクセス処理部１１６は、受け取ったデータに付与されたメタデータを参照することで、データの属性を知ることができ、属性に合わせた処理を行うことができる。例えば、データアクセス処理部１１６は、内部で生成されたことを示すメタデータを持つ読み出し指示については、未署名のメタデータを持つ記録データの読み出しを許可するが、外部から受信したことを示すメタデータを持つ読み出し指示については、未署名のメタデータや機密を示すメタデータを付与された記録データを外部に読み出すのを制限する、あるいは、機密のメタデータを付与された記録データは認証された相手しか読み出せないが、公開のメタデータを付与された記録データは誰でも読み出せる、といった制限を行う。また、データ転送部１１３は、データが未署名か否かをデータに付与されたメタデータで判断し、転送先を変えてもよい。なお、メタデータを参照して処理を変える処理部は、データアクセス処理部１１６やデータ転送部１１３に限らず、どの処理部でもよい。

署名生成部１１４は、一方向ハッシュ関数と、後述する鍵管理部１１５が保持する鍵を用いた公開鍵暗号アルゴリズムから成る署名アルゴリズムによって、データ転送部１１３から受け取ったデータの署名を生成・付与する。署名生成部１１４は、一方向ハッシュ関数を用いて入力データのハッシュを計算し、求めたハッシュを公開鍵暗号アルゴリズムと秘密鍵を用いて暗号化することで署名を計算する。一方向ハッシュ関数は、ＭＤ５，ＳＨＡ−２５６，ＳＨＡ−３などのよく知られたアルゴリズムを用いればよい。公開鍵暗号アルゴリズムは、ＲＳＡや楕円曲線暗号などのよく知られたアルゴリズムを用いればよい。
なお、署名生成部１１４は、公開鍵暗号を利用する署名アルゴリズム以外に、共通鍵暗号を利用するＭＡＣ （Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）アルゴリズムやハッシュ関数を利用するＨＭＡＣを備えていてもよい。データ蓄積部１８０に格納するデータに署名およびＭＡＣを付与することで、データ蓄積部１８０から読み出したデータが改ざんされたかどうかを検知することができる。

鍵管理部１１５は、署名生成部１１４で署名を生成するための鍵を保持する。鍵管理部１１５は、公開鍵暗号アルゴリズムから計算される公開鍵と秘密鍵のペアのうち、少なくとも署名生成に必要な秘密鍵を有している。なお、署名の検証に必要な公開鍵は鍵管理部１１５が保持していてもよいし、公開鍵を管理する外部装置が保管していてもよい。鍵管理部１１５は、自前で公開鍵暗号アルゴリズムから公開鍵と秘密鍵のペアを生成してもよいし、外部で生成した秘密鍵を受け取ってもよい。自前で公開鍵と秘密鍵のペアを生成する場合、鍵管理部１１５はデータ格納装置１００の外部に公開鍵を送信する機能を有する。なお、鍵管理部１１５は、鍵をデータ蓄積部１８０に保存してもよいし、内部バス１９１に接続された他の記憶領域に保存してもよい。また、鍵を安全に管理するため、ＴＰＭ（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ）のような鍵を安全に扱うための専用のハードウェアを利用して、鍵の生成や保管を行ってもよい。

データアクセス処理部１１６は、データ蓄積部１８０へのアクセスを管理する処理部であり、データ蓄積部１８０にデータを書き込む命令を発行したり、データ蓄積部１８０からデータを読み出す命令を発行したりする。データ蓄積部１８０にデータを書き込む場合、データアクセス処理部１１６は、データ転送部１１３から書き込むデータを受け取り、自身が生成した書き込み先情報（例えば、物理アドレスとデータのサイズ）と一緒にデータ蓄積部１８０に送る。同時に、データアクセス処理部１１６は、書き込み先情報を管理し、空き領域の管理や読み出し可能かどうかのチェックを行う。なお、データアクセス処理部１１６が書き込み先情報を生成する方法は自由に設定できるものとする。例えば、アドレス順に順番に書き込む方法でもよいし、空き領域からランダムに選択してもよい。そのほかに、データアクセス処理部１１６は、データの信頼性を高めるため、書き込み箇所を一か所から複数箇所に増やしたり、誤り訂正符号を付与したりしてもよい。

データ蓄積部１８０からデータを読み出す場合、データアクセス処理部１１６は、データ転送部１１３から読み出し先を指定する情報を含む読み出し指示を受け取り、この読み出し指示をデータ蓄積部１８０からデータを読み出す命令に変換して、データ蓄積部１８０に送る。データ蓄積部１８０は、受け取った読み出し命令に基づきデータを読み出し、データアクセス処理部１１６に渡す。データアクセス処理部１１６は、受け取ったデータをデータ転送部１１３を介してメッセージ処理部１１２に渡す。これにより、データ蓄積部１８０から読み出されたデータが、バスＩ／Ｆ１６０を介してネットワークバス５に送出される。

なお、データ蓄積部１８０の読み出し先を指定する方法として、あらかじめ読み出し方法をデータアクセス処理部１１６に設定しておき、設定された読み出し方法を指定してもよい。例えば、読み出し方法として「すべての記録データの出力」を指定すると、データ格納装置１００は、データ蓄積部１８０に蓄積されたデータのうち、後述する外部読み出し禁止領域を除いた領域に格納されたすべての記録データを出力する。

データアクセス処理部１１６は、データ蓄積部１８０に対するアクセス制限を行う機能を持ち、書き込みや読み出しを制限してもよい。具体的には、データアクセス処理部１１６は、物理アドレスで示す特定の領域に対して、データの書き込みを禁止したり、あるいは、内部で生成した読み出し指示なら読み出しを許可するが、外部から受信した読み出し指示は拒否したりといった制限を行うようにしてもよい。外部から受信した読み出し命令と内部で生成した読み出し命令を区別する方法として、例えば、データ転送部１１３が付与したメタデータを参照する方法がある。データ転送部１１３は、メッセージ処理部１１２から受け取ったデータには外部を示すメタデータを付与し、署名生成部１１４などメッセージ処理部１１２以外の処理部から受け取ったデータには内部を示すメタデータを付与することができる。そのメタデータを参照することで、データアクセス処理部１１６は、受け取ったデータが外部から来たのか内部で生成されたのかを区別できる。

データアクセス処理部１１６がアクセス制限を行う機能を持つ場合、例えば、外部から受信した読み出し指示が拒否される領域（外部読み出し禁止領域）に鍵を保存することで、鍵がデータ格納装置１００の外部に不用意に出力されることを防ぐことができる。また、後述するように、未署名のままデータ蓄積部１８０に書き込まれるデータを外部読み出し禁止領域に格納することで、未署名のままデータが外部に出力されることを防ぐことができる。

図４は、本実施形態に係るデータ格納装置１００による処理手順の一例を示すフローチャートであり、データ格納装置１００が車載ネットワーク１から自発的にデータを取得してデータ蓄積部１８０に蓄積する基本的な処理動作の一例をまとめたものである。この図４のフローチャートで示す一連の処理は、プロセッサ１１０がタイマ１４０から割込み通知を受けるたびに繰り返し実行される。

プロセッサ１１０は、タイマ１４０から割込み通知を受けると（ステップＳ１０１：Ｙｅｓ）、送信メッセージ取得部１１１にタイマ割込みを伝える。

送信メッセージ取得部１１１は、タイマ割込み通知を受けて、例えば、上述のメッセージキューと送信先のリストに基づいて、送信先のＩＤを埋め込んだリクエストメッセージを選択し、メッセージ処理部１１２に渡す（ステップＳ１０２）。そして、メッセージ処理部１１２が、バスＩ／Ｆ１６０を介してＥＣＵ２に向けたリクエストメッセージをネットワークバス５に送出することで、リクエストメッセージをＥＣＵ２に送信する（ステップＳ１０３）。

その後、ＥＣＵ２からレスポンスメッセージが送信されると、メッセージ処理部１１２は、そのレスポンスメッセージをバスＩ／Ｆ１６０を介して受信し、受信したレスポンスメッセージからデータを取り出す（ステップＳ１０４）。メッセージ処理部１１２がレスポンスメッセージから取り出したデータは、データ転送部１１３を介して署名生成部１１４に渡される。

次に、署名生成部１１４が、鍵管理部１１５から署名用の鍵を読み出し（ステップＳ１０５）、その鍵を用いてデータ転送部１１３から受け取ったデータの署名を計算し（ステップＳ１０６）、データと署名をデータ転送部１１３に渡す。データ転送部１１３は、署名生成部１１４から受け取ったデータと署名と書き込み指示をデータアクセス処理部１１６に渡す。データアクセス処理部１１６は、書き込み指示に応じてデータと署名の書き込み先の物理アドレスを決め（ステップＳ１０７）、データ蓄積部１８０に対してデータと署名と書き込み先の物理アドレスを渡す。データ蓄積部１８０は、データアクセス処理部１１６から受け取ったデータと署名を、書き込み先の物理アドレスが示す領域に格納する（ステップＳ１０８）。

図５は、本実施形態に係るデータ格納装置１００による処理手順の一例を示すフローチャートであり、メッセージ受信時におけるデータ格納装置１００の処理動作の一例をまとめたものである。この図５のフローチャートで示す一連の処理は、バスＩ／Ｆ１６０がネットワークバス５に流れているメッセージを受信するたびに繰り返し実行される。

バスＩ／Ｆ１６０は、ネットワークバス５に流れているメッセージを受信すると（ステップＳ２０１：Ｙｅｓ）、受信したメッセージをメッセージ処理部１１２に渡す。メッセージ処理部１１２は、受信したメッセージが格納対象のメッセージか、あるいはデータ読み出しを指示するメッセージかをチェックする（ステップＳ２０２，Ｓ２０３）。ここで、格納対象のメッセージを受信した場合（ステップＳ２０２：Ｙｅｓ）、メッセージ処理部１１２は、メッセージに含まれるデータをデータ転送部１１３に渡し、データ転送部１１３は受け取ったデータを署名生成部１１４に渡す。

署名生成部１１４は、データ転送部１１３からデータを受け取ると、鍵管理部１１５から署名用の鍵を読み出し（ステップＳ２０４）、受け取ったデータの署名を計算して（ステップＳ２０５）、データ転送部１１３にデータと署名を渡す。データ転送部１１３は、データと署名と書き込み指示をデータアクセス処理部１１６に送る。データアクセス処理部１１６は、データ転送部１１３から書き込み指示とデータと署名をそれぞれ受け取ると、書き込み指示に応じてデータと署名の書き込み先となる物理アドレスを決め（ステップＳ２０６）、データと署名と書き込み先の物理アドレスをデータ蓄積部１８０に渡す。このとき、データアクセス処理部１１６は、書き込み先として指定した物理アドレスが指す領域にデータが書き込み済みであることを記録し、データを上書きしないよう以降データの書き込み先として指定しないようにする。データ蓄積部１８０は、データアクセス処理部１１６から受け取ったデータと署名を、書き込み先の物理アドレスが示す領域に格納する（ステップＳ２０７）。

一方、データ読み出しを指示するメッセージを受信した場合（ステップＳ２０３：Ｙｅｓ）、読み出し指示に応じてデータ蓄積部１８０からデータを読み出し、データ格納装置１００からネットワークバス５に向けて出力する処理が行われる。具体的には、メッセージ処理部１１２は、データ読み出しを指示するメッセージから読み出し指示を取得し、データ転送部１１３に渡す（ステップＳ２０８）。データ転送部１１３は、受け取った外部からの読み出し指示に外部を示すメタデータを付与してデータアクセス処理部１１６に渡す。データアクセス処理部１１６は、メタデータから読み出し指示が外部から受信したものであることを考慮して、外部に送信できない記録データを避けた読み出し命令を読み出し指示から作成し、データ蓄積部１８０に渡す。データ蓄積部１８０は読み出し命令に応じてデータを読み出し、データアクセス処理部１１６に渡す（ステップＳ２０９）。データアクセス処理部１１６は、読み出したデータをデータ転送部１１３に渡す。データ転送部１１３は、データアクセス処理部１１６から受け取ったデータをメッセージ処理部１１２に渡す。メッセージ処理部１１２は、データ転送部１１３から受け取ったデータをメッセージ形式に変換し、バスＩ／Ｆ１６０を通じてネットワークバス５に送信する（ステップＳ２１０）。

また、メッセージ処理部１１２は、受信したメッセージが格納対象のメッセージでもデータ読み出しを指示するメッセージでもない場合は（ステップＳ２０２：Ｎｏ、ステップＳ２０３：Ｎｏ）、メッセージの送信元を宛先とするエラーメッセージを生成し、バスＩ／Ｆ１６０を通じてネットワークバス５にエラーメッセージを送信する（ステップＳ２１１）。

以上説明した本実施形態の構成は、特に、車載ネットワーク１にデータ格納装置１００を搭載する際のコストを削減するのに有効である。車載ネットワーク１で使われている通信プロトコルは、低速・低コスト設計となっており、複数の相手と安定して確実に通信できることを想定している。一方、ＳＳＤやメモリカードといった従来の一般的なデータ格納装置で使われているインタフェースは、１対１で高速に通信することを目的としている。車載ネットワーク１と一般的なデータ格納装置のインタフェースは設計思想が異なるものであるため、車載ネットワーク１に一般的なデータ格納装置を接続する場合、データ格納装置を制御するＣＰＵを持ち、車載ネットワーク１に接続する機能を持ったホストが必要となる。

これに対し、本実施形態に係るデータ格納装置１００は、車載ネットワーク１用のインタフェースと通信プロトコル、標準化されたＥＣＵ診断規格にそれぞれ対応しており、車載ネットワーク１上のＥＣＵ２などから自発的にデータを取得して蓄積することを、ホストＣＰＵがなくても実行できる。また、本実施形態に係るデータ格納装置１００に用いるプロセッサ１１０は特定の処理に特化し、汎用的に持たせる機能を削減しているため、コスト削減に有効である。

さらに、本実施形態に係るデータ格納装置１００には、ネットワークバス５につながるバスＩ／Ｆ１６０とメッセージを送受信するためのホストプログラムが内蔵されている。そして、このホストプログラムはデータの収集に特化した小規模なプログラムである。このため、脆弱性を含みづらく、データ蓄積部１８０に格納されたデータを改変されるリスクを小さくするのに有効である。複数の機能を備えた外付けのホストが存在する場合、外付けホストのホストプログラムの規模が大きくなり、脆弱性を含みやすくなる虞がある。

また、本実施形態に係るデータ格納装置１００の構成は、署名に使用する鍵の管理コストを削減するのにも有効である。従来の構成のように、データを収集するホスト（ＥＣＵ）とデータ格納装置が分かれており、ホストとデータ格納装置との間が汎用インタフェースで接続されている場合、データ格納装置に鍵を保存すると、データ格納装置を取り出し、アクセス制限機能を持たない汎用インタフェースを経由して秘密鍵を含むデータを抜き出される虞がある。そのため、通常は、容易に分離可能なデータ格納装置に鍵を保存することはなく、ＴＰＭのような専用ハードウェアを使用して鍵を安全に保存する。

しかし、本実施形態のようにデータ格納装置１００が鍵管理部１１５を備える構成であれば、データ蓄積部１８０のアクセス制限をかけた領域に鍵を保存することで、データ格納装置１００を取り出し、鍵を抜き出されることを防ぐことができる。そのため、専用ハードウェアを使わずに安全に鍵を保存することができ、コストの削減に有効である。この効果は、鍵の安全な保存だけでなく、後述するように未署名のまま格納したデータが意図せず読み出されることを防ぐことにも効果がある。そのほかに、署名検証用の公開鍵もデータ格納装置１００に持つことで、データ格納装置１００に格納されたデータの検証が必要になったときに、すぐに署名検証用の公開鍵を入手できるため、署名の検証に使用する鍵の管理コストを削減する上でも有効である。

また、本実施形態では、鍵を含む署名機能をデータ格納装置１００に持つことで、データ格納装置１００を異なる車両の車載ネットワークに接続することが容易になる利点もある。データ格納装置１００が独立して署名生成できるため、接続先の環境によらず、常に同じ署名方式を用いてデータに署名を付与することができる。そのため、接続先が代わってもデータの検証は常に同じ公開鍵を用いてできるため、データの検証が容易である。従来のようにホスト（ＥＣＵ）とデータ格納装置が分かれており、署名機能をホストが有している場合、接続先の車両によってホストが持つ署名方式が異なる、もしくは署名機能を持っていない可能性がある。データ格納装置だけを他の車両に移すと、特に車両がオフライン状態の場合に、以前接続されていたホストが持つ公開鍵を探すのが困難になるなど、データによって署名の状況が異なる可能性があり、データの検証が難しくなる。

また、データの格納時に異常が発生した場合、問題発生箇所の切り分けが容易になる効果もある。メッセージの送受信をホスト（ＥＣＵ）に行わせ、メッセージに含まれるデータをホストとは別のデータ格納装置に格納する構成の場合、データの格納時に異常が発生した場合に、異常の原因がホスト側にあるのかデータ格納装置側にあるのかを特定することが必要になる。異常発生の具体的な例として、ホストあるいはデータ格納装置どちらかに突然の電源断が発生し、書き込み中のデータが失われた場合や、ホストとデータ格納装置をつなぐ通信経路上でノイズによるデータ化けが発生し、異常なデータが書き込まれる場合などが考えられる。どちらの場合も、書き込みデータが失われたり、異常なデータが書き込まれたりする原因を特定するには、ホストとデータ格納装置の両方を調査する必要がある。しかし、ホストとデータ格納装置のメーカーが異なる場合、双方の協力がないと原因の追及は難しい。同様に、通信経路上のノイズのようにホストでもデータ格納装置でもない箇所で生じた異常の場合、原因の追及はさらに難しくなる可能性がある。また、ホストのインタフェースがデータ格納装置のインタフェース規格に基づいて設計されていても、規格で明確になっていない細かい実装の違い（相性）が原因で異常が生じる可能性もある。

これに対し、本実施形態に係るデータ格納装置１００は、メッセージの送受信を行う機能とデータが格納されるデータ蓄積部１８０とが一体化されており、メーカーが共通である。そのため、データの格納時に異常が発生しても、原因はデータ格納装置１００にあり、同じメーカーで原因の特定が行えるため、異常の原因追及が容易になる。車載ネットワーク１のような高い信頼性が求められる用途では、原因の特定が容易であることが特に重要となる。

なお、本実施形態では、データ格納装置１００がＥＣＵ２から診断情報を取得して蓄積するために、ＥＣＵ２に対してリクエストメッセージを送信する例を示した。しかし、本実施形態のポイントは、データ格納装置１００が車載ネットワーク１から自発的にデータを収集して蓄積できるようにすることであり、診断情報を要求するためにＥＣＵ２に対してリクエストメッセージを送信する例に限定するものではない。例えば、バスＩ／Ｆ１６０は、データ格納装置１００が処理するＩＤでないメッセージを取得しても、そのメッセージを破棄せずにプロセッサ１１０にメッセージ受信を通知することで、データ格納装置１００に向けたレスポンスメッセージ以外のメッセージも受信する設定が可能である。データ格納装置１００が行う自発的な処理には、このような機能を利用して、ネットワークバス５に流れるメッセージを、メッセージのＩＤに関わらずすべて受信し、ＥＣＵ２の間で送受信される制御メッセージを取得してデータ蓄積部１８０に蓄積することも含まれる。

（変形例）
以上説明した第１実施形態では、ＥＣＵ２から受信したメッセージに含まれるデータに署名を付与してデータ蓄積部１８０に格納していた。しかし、ＥＣＵ２から受信したメッセージに含まれるデータを未署名のままデータ蓄積部１８０に格納しておき、プロセッサ１１０の使用率が低いときに、未署名のデータをデータ蓄積部１８０から読み出して署名を付与する構成であってもよい。

図６は、本変形例に係るデータ格納装置１００の機能的な構成例を示すブロック図である。図３に示した第１実施形態の構成との違いは、スケジューラ部１１７と未署名データ管理部１１８とが追加されている点である。

スケジューラ部１１７は、タイマ割込みを受け取った際、次に行う処理を決める処理部である。具体的には、プロセッサ１１０の使用率に応じて、リクエストメッセージを送信するか署名を計算するかの指示を行う。なお、次に行う処理を決める基準はプロセッサ１１０の使用率に限らず、あらかじめ決められたスケジュールに基づいて決めてもよい。また、次に行う処理はリクエストメッセージの送信と署名の計算の２つに限らず、その他の処理を含めてもよい。

未署名データ管理部１１８は、データ蓄積部１８０に格納された未署名データを管理する処理部である。未署名データ管理部１１８は、署名せずにデータ蓄積部１８０に格納するデータの書き込み先情報をデータアクセス処理部１１６から受け取って記録する。未署名データ管理部１１８は、スケジューラ部１１７から署名計算の指示を受けると、管理する未署名データの書き込み先情報をデータアクセス処理部１１６に渡す。同時に、未署名データに署名が付与されたと判断し、未署名データの書き込み先情報を削除する。なお、未署名データ管理部１１８は、データアクセス処理部１１６からの要求を受けて管理する未署名データの書き込み先情報を渡してもよい。また、未署名データの書き込み先情報は１つに限らず複数記録してもよい。

図７は、本変形例に係るデータ格納装置１００による処理手順の一例を示すフローチャートである。この図７のフローチャートで示す一連の処理は、プロセッサ１１０がタイマ１４０から割込み通知を受けるたびに繰り返し実行される。

プロセッサ１１０は、タイマ１４０から割込み通知を受けると（ステップＳ３０１：Ｙｅｓ）、スケジューラ部１１７にタイマ割込みを伝える。スケジューラ部１１７は、タイマ割込み通知を受けてプロセッサ１１０の使用率を確認し、プロセッサ１１０の使用率が所定の閾値以下か否かを判定する（ステップＳ３０２）。そして、プロセッサ１１０の使用率が閾値を超えていれば（ステップＳ３０２：Ｎｏ）、送信メッセージ取得部１１１に対してリクエストメッセージの選択を指示する。

送信メッセージ取得部１１１は、スケジューラ部１１７の指示に応じて、例えば、上述の送信先のリストに基づいて送信するリクエストメッセージを選択し、メッセージ処理部１１２に渡す（ステップＳ３０３）。そして、メッセージ処理部１１２が、バスＩ／Ｆ１６０を介してＥＣＵ２に向けたリクエストメッセージをネットワークバス５に送出することで、リクエストメッセージをＥＣＵ２に送信する（ステップＳ３０４）。

その後、ＥＣＵ２からレスポンスメッセージが送信されると、メッセージ処理部１１２は、そのレスポンスメッセージをバスＩ／Ｆ１６０を介して受信し、受信したレスポンスメッセージからデータを取り出す（ステップＳ３０５）。メッセージ処理部１１２がレスポンスメッセージから取り出したデータは、データ転送部１１３を介してデータアクセス処理部１１６に渡される。このとき、データ転送部１１３は、レスポンスメッセージから取り出されたデータに対して未署名を示すメタデータを付与し、データアクセス処理部１１６に渡す。

データアクセス処理部１１６は、データ転送部１１３から未署名データを受け取ると、この未署名データの書き込み先の物理アドレスを決め（ステップＳ３０６）、データ蓄積部１８０に対して未署名データと書き込み先の物理アドレスを渡すとともに、未署名データ管理部１１８に対して、未署名データの書き込み先の物理アドレスを示す書き込み先情報を送る。データ蓄積部１８０は、データアクセス処理部１１６から受け取った未署名データを、書き込み先の物理アドレスが示す領域に格納する（ステップＳ３０７）。また、未署名データ管理部１１８は、データアクセス処理部１１６から受け取った未署名データの書き込み先情報を記録する（ステップＳ３０８）。

一方、ステップＳ３０２においてプロセッサ１１０の使用率が閾値以下と判定した場合（ステップＳ３０２：Ｙｅｓ）、スケジューラ部１１７は、未署名データ管理部１１８に対して未署名データに対する署名付与を指示する。

未署名データ管理部１１８は、スケジューラ部１１７の指示に応じて、まず、自身が持つ未署名データの書き込み先情報の記録を確認し（ステップＳ３０９）、未署名データが存在する否かを判定する（ステップＳ３１０）。そして、未署名データが存在する場合（ステップＳ３１０：Ｙｅｓ）、未署名データ管理部１１８は、その未署名データの書き込み先情報を読み出し指示に変換し、読み出し指示が内部で生成されたことを示すメタデータを付与して、データアクセス処理部１１６に渡す。

データアクセス処理部１１６は、未署名データ管理部１１８から受け取った読み出し指示が内部で生成されたことをメタデータから判別し、未署名データを読み出せると判断して、この読み出し指示に基づき、未署名データをデータ蓄積部１８０から読み出してデータ転送部１１３に渡す。また、未署名データ管理部１１８は、データ蓄積部１８０から読み出された未署名データの書き込み先情報を削除する（ステップＳ３１１）。

データ転送部１１３は、データアクセス処理部１１６から受け取ったデータのメタデータを参照して、未署名データであることを認識し、そのデータを署名生成部１１４に渡す。署名生成部１１４は、データ転送部１１３から受け取ったデータの署名を計算し、データと署名をデータ転送部１１３に渡す（ステップＳ３１２）。データ転送部１１３は、署名生成部１１４から受け取ったデータと署名と書き込み指示をデータアクセス処理部１１６に渡す。データアクセス処理部１１６は、書き込み指示に応じてデータと署名の書き込み先の物理アドレスを決め、データ蓄積部１８０に対してデータと署名と書き込み先の物理アドレスを渡す。データ蓄積部１８０は、データアクセス処理部１１６から受け取ったデータと署名を、書き込み先の物理アドレスが示す領域に格納する（ステップＳ３１３）。

なお、ステップＳ３１０において、未署名データが存在しないと判定した場合（ステップＳ３１０：Ｎｏ）、未署名データ管理部１１８は、スケジューラ部１１７に対して未署名データが存在しないことを通知する。この場合、スケジューラ部１１７が送信メッセージ取得部１１１に対してリクエストメッセージの選択を指示することで、ステップＳ３０３以降の処理が行われる。

以上説明した本変形例の構成は、プロセッサ１１０の処理性能が低く、メッセージ処理部１１２が受信したメッセージに含まれるデータをデータアクセス処理部１１６に渡すごとに毎回署名を計算できるとは限らない場合に特に有効である。メッセージを受信するたびに署名を計算する構成とした場合は、プロセッサ１１０には単位時間当たりのメッセージの送受信数の最大値に合わせて署名を計算できるような高い性能が必要となり、データ格納装置１００の製造コストが高くなる。あるいは、プロセッサ１１０の性能が低いと、署名の計算に時間を取られてしまい、メッセージの受信漏れが発生する虞がある。これに対し、本変形例のように、受信したメッセージに含まれるデータを未署名のままデータ蓄積部１８０に格納し、署名の計算を行うタイミングをずらすことにより、プロセッサ１１０はメッセージの受信漏れが発生しない程度の性能を持てばよいことになる。その結果、受信したメッセージに含まれるデータに常に署名を計算するような高い性能がプロセッサ１１０に求められることがなく、データ格納装置１００の製造コストを低減することができる。

なお、上述の変形例では、受信したメッセージに含まれるデータを必ず未署名のままデータ蓄積部１８０に格納することを想定したが、受信したメッセージに含まれるデータに署名を付与してからデータ蓄積部１８０に格納する場合と、未署名のままデータ蓄積部１８０に格納して後で署名を付与する場合とを、プロセッサ１１０の使用率に応じて切り替えるようにしてもよい。すなわち、メッセージ受信時にプロセッサ１１０の使用率を確認し、署名を計算する余裕があれば、図４に示したように、メッセージに含まれるデータに署名を付与してからデータ蓄積部１８０に格納する処理を行い、署名を計算する余裕がなければ、図７に示したように、メッセージに含まれるデータを未署名のままデータ蓄積部１８０に格納し、後で署名を付与する処理を行うようにしてもよい。

このようにプロセッサ１１０の使用率に応じて署名を付与するタイミングを切り替える構成は、データ格納装置１００に必要な処理性能を低く抑えつつ、データの署名付与にかかる処理時間を短縮する効果がある。すなわち、受信したメッセージに含まれるデータを常に未署名のままデータ蓄積部１８０に格納する構成であると、未署名データの読み出しと署名の書き込みが必ず必要になるため、処理時間が長くなる。一方、プロセッサ１１０の使用率に応じて署名を付与するタイミングを切り替える構成とすれば、メッセージ受信時にプロセッサ１１０に余裕があれば、書き込みを行う前に署名付与を行うことで、未署名データの読み出しと署名の書き込みを省略できる。つまり、このようなプロセッサ１１０の使用率に応じた処理の切り替えは、常に図４に示す処理を行う場合と比較するとプロセッサ１１０に必要とされる処理性能を低くすることができ、常に図７に示す処理を行う場合と比較するとデータに署名を付与する処理にかかる時間を短くできる利点がある。

＜第２実施形態＞
次に、第２実施形態について説明する。上述の第１実施形態では、データ格納装置１００が自発的にＥＣＵ２に向けてリクエストメッセージを送信し、ＥＣＵ２の設定情報や動作状態、診断結果などを取得して蓄積する構成を示した。ここで、上述の第１実施形態では、データ格納装置１００が送信するリクエストメッセージは、車両Ｖの状態に関わらず固定されたセットの中で順番に選択されていた。この手法は、決められたデータを定期的に収集する用途（例えば、ＥＣＵ２の状態の監視など）を想定していた。

これに対し第２実施形態では、状況に応じてデータ格納装置１００が送信するリクエストメッセージを切り替える機能を備えた構成を示す。例えば、データ格納装置１００を搭載する車両Ｖに適したリクエストメッセージを選択したり、ＥＣＵ２の異常状態に応じて、異常状態の原因を特定するために必要なデータを選択して収集したりする。具体的には、診断結果を含むレスポンスメッセージからは異常の発生個所や異常の状況は分かるが、異常の原因は分からない。そこで、異常が発生した際に、異常が発生したことを示すデータを取得して蓄積するだけでなく、異常の原因を究明するための情報を取得して蓄積できれば、故障原因の早期発見や車両Ｖの修理に有用である。

異常状態の発生原因を特定するには、異常発生元の機能やＥＣＵ２だけでなく、他の機能の状態や周辺のＥＣＵ２の状態も収集し、総合的に判断する必要がある。例えば、車両Ｖに搭載されている発電機（オルターネータ）を制御するＥＣＵ２がない場合、発電機が故障したことを直接検出する方法はない。しかし、バッテリが充電されないことにより、ＥＣＵ２のバッテリ電圧の低下が異常状態として発生する。このとき、もし、ＥＣＵ２のバッテリ電圧低下が１つのＥＣＵ２だけでなく、共通のバッテリに接続された他のＥＣＵ２にもバッテリ電圧低下が発生していれば、ＥＣＵ２の故障ではなく、バッテリや発電機に異常の原因がある可能性が高いことが分かる。そのため、ＥＣＵ２のバッテリ電圧低下という異常が発生したとき、他のＥＣＵ２のバッテリ電圧を収集し記録することで、異常状態の発生原因を特定する精度を高めることができる。これは、ＥＣＵ２のバッテリ電圧異常の原因特定だけでなく、ＥＣＵ２の診断機能により取得可能な異常状態の原因特定に適用可能な手法である。

上記手法を実現する１つの方法は、すべてのＥＣＵ２からすべての機能の診断結果を収集することである。しかし、大量のリクエストメッセージやレスポンスメッセージが車載ネットワーク１に流れることに加え、記憶容量が膨大になり、データの蓄積に要する処理量も大きくなるため、コスト高になる。そこで、第２実施形態では、発生した異常状態の故障原因を特定する診断情報だけを収集するため、送信するリクエストメッセージを状況に応じて変更することで、収集するデータを減らす機能を追加する。送信するリクエストメッセージのセットが固定であると、あらゆるデータを取得しなくてはいけなくなるのに対し、発生した異常状態に応じて動的に異常状態の原因を特定するセットに変更すれば必要なデータだけを収集できるため、不要なリクエストメッセージおよびレスポンスメッセージの送受信を削減することができる。

ここで、リクエストメッセージおよびレスポンスメッセージのフォーマットについて説明する。診断プロトコルとしてＵＤＳを例に取ると、リクエストメッセージおよびレスポンスメッセージは、少なくとも、サービスＩＤ領域とサービスデータ領域との２つの領域を持つ。サービスＩＤ領域は、どの診断機能を実行するかを示す値が設定される。サービスデータ領域は、リクエストメッセージかレスポンスメッセージかを区別する情報と、レスポンスメッセージの場合、診断結果が記録される。前述したように、リクエストメッセージおよびレスポンスメッセージをＥＣＵ２間の通信プロトコルを利用して送受信する場合、リクエストメッセージおよびレスポンスメッセージの送信先はメッセージのＩＤ領域に設定され、サービスＩＤ領域とサービスデータ領域は、メッセージのデータ領域に設定される。

なお、通信プロトコルとＥＣＵ向け診断プロトコルを組み合わせた規格を利用した場合、ＥＣＵ向け診断プロトコルは、メッセージのＩＤ領域にメッセージの送信先以外の情報を含めることができる。具体的には、メッセージのＩＤ領域を分割し、分割されたＩＤ領域の一方にリクエストメッセージおよびレスポンスメッセージの送信先を設定し、もう一方に送信元を設定してもよい。この場合、通信プロトコルはメッセージのＩＤ領域の送信先が設定された部分だけを参照することで、メッセージの送信先を区別する。

以下では、データ格納装置１００が送信するリクエストメッセージのセットのことをルールと呼ぶ。ルールは１以上のリクエストメッセージから構成されている。ルールを構成するリクエストメッセージは、ルールに設定された目的を達成する情報をＥＣＵ２に要求する。例えば、ＥＣＵ２のバッテリ電圧を収集するルールは、ＥＣＵ２ａ〜２ｄにバッテリ電圧を要求するリクエストメッセージから構成される。また、ＥＣＵ２の機能や車載装置の構成は車両Ｖの車種によって異なるため、車種によってルールの構成やルールを構成するリクエストメッセージの内容は異なる。

第２実施形態では、送信メッセージ取得部１１１は、ＥＣＵ２に異常が発生しているかを確認するため、ＥＣＵ２に対して送信すべきリクエストメッセージが記載されたルール（監視ルール）を持つ。データ格納装置１００は、監視ルールに基づき、ＥＣＵ２に異常が発生しているかを確認するためにリクエストメッセージをＥＣＵ２に送信する。データ格納装置１００は、ＥＣＵ２から受信したレスポンスメッセージを解析し、異常状態を検出したら、異常状態の原因を特定する情報を収集するルール（特定ルール）に切り替える。以降、データ格納装置１００は、切り替え後のルールに基づき送信するリクエストメッセージを選択するようになる。以後、実現方法の詳細について説明する。

図８は、第２実施形態に係るデータ格納装置１００の機能的な構成例を示すブロック図である。図３に示した第１実施形態の構成との違いは、データ監視部１１９とルール管理部１２０とが追加されている点である。

データ監視部１１９は、メッセージ処理部１１２からＥＣＵ２が送信したレスポンスメッセージを受け取り、ＥＣＵ２および車載装置に異常が発生していないかをチェックする。具体的には、レスポンスメッセージのサービスＩＤとデータを解析する。もし異常が発生していれば、発生した異常の内容をルール管理部１２０に渡す。異常が発生していなければ、データ監視部１１９はルール管理部１２０に何も渡さず、次のレスポンスメッセージを解析する。

ここで、データ監視部１１９は、異常を解析する際、１つのメッセージを解析するほかに、あるＥＣＵ２から受信した複数のメッセージを解析してもよいし、複数のＥＣＵ２から受信したそれぞれのメッセージを解析してもよい。また、データ監視部１１９は、レスポンスメッセージを解析することで、異常状態の有無だけでなく、車両Ｖの状態を検出してもよい。例えば、診断が実行できないことを示すレスポンスメッセージから、ＥＣＵ２がリクエストメッセージを処理できない状態にあることを検出してもよいし、レスポンスメッセージを受信するまでの時間がかかりすぎる、あるいはタイムアウトしたことで、ＥＣＵ２がリクエストメッセージを受信できない状態にあることを検出してもよい。この場合、このような情報をルール管理部１２０に伝え、後述するようにルール管理部１２０が送信メッセージ取得部１１１のルールを切り替えるきっかけにしてもよい。

ルール管理部１２０は、データ監視部１１９が異常状態を検出した際、送信メッセージ取得部１１１に設定されているルールを異常状態の原因を特定するために必要な情報を収集するルール（特定ルール）に切り替える。ルール管理部１２０は、発生した異常状態と特定ルールとの対応関係を有している。ルール管理部１２０が保持する異常状態と特定ルールとの対応関係の一例を図９に示す。ルール管理部１２０は、データ監視部１１９が伝える異常状態の内容を受け取ると、例えば図９に示す対応関係を参照し、異常状態の原因を特定するために必要な情報を収集する特定ルールを選択して、送信メッセージ取得部１１１に渡す。送信メッセージ取得部１１１は、ルール管理部１２０から特定ルールを受け取ると、現在設定されているルールを、ルール管理部１２０から受け取った特定ルールに切り替える。

なお、ルール管理部１２０がルールを切り替えるタイミングは、異常発生時だけでなく、特定ルールが持つリクエストメッセージをすべて送信し終えた後でもよい。例えば、送信メッセージ取得部１１１は、現在設定されている特定ルールが持つリクエストメッセージをすべて送信すると、異常状態が発生していないかをチェックする監視ルールに切り替えたり、車両Ｖの状況に応じて監視ルールに切り替えたりしてもよい。また、車両Ｖのエンジンが始動した直後や停止中、低速走行中、高速走行中などでＥＣＵ２が受け付け可能なリクエストメッセージが変化したり、監視すべきＥＣＵ２やＥＣＵ２が持つ機能、車載装置が異なったりすることが考えられる。その場合、データ格納装置１００は車両Ｖの状態に合わせて複数の監視ルールを持ち、制御メッセージやレスポンスメッセージから車両Ｖの状態を取得し、それに合わせた監視ルールに切り替えてもよい。これによりＥＣＵ２が受け付けできないリクエストメッセージの送信をあらかじめ削減することができる。

ルール管理部１２０が管理するルールは、ルール管理部１２０自身が保持していてもよいし、データ蓄積部１８０に保管していてもよい。データ蓄積部１８０にルールを保管している場合、データアクセス処理部１１６を経由してデータ蓄積部１８０からルールを読み出す必要がある。

図１０は、本実施形態に係るデータ格納装置１００による処理手順の一例を示すフローチャートであり、異常状態の発生を検出した際、異常状態の原因を特定するために必要なデータを収集するルールに切り替える処理動作の一例をまとめたものである。この図１０のフローチャートで示す処理は、図４のフローチャートで示す処理に対し、メッセージ処理部１１２が受信したレスポンスメッセージから異常発生の有無をチェックし、ルール切り替えを行う処理を追加したものである。この追加の処理は、図４のステップＳ１０４の後に、図４のステップＳ１０５からステップＳ１０８の処理（レスポンスメッセージのデータをデータ転送部１１３に渡した後の処理）と並行して行われ、両者に前後関係はない。以下では追加の処理についてのみ説明する。

本実施形態におけるメッセージ処理部１１２は、レスポンスメッセージのデータをデータ転送部１１３に渡すことに加えて、レスポンスメッセージをデータ監視部１１９に渡す。データ監視部１１９は、メッセージ処理部１１２からレスポンスメッセージを受け取ると、現在設定されているルールが監視ルールか否かを確認し（ステップＳ４０１）、監視ルールであれば（ステップＳ４０１：Ｙｅｓ）、メッセージ処理部１１２から受け取ったレスポンスメッセージを解析して、異常状態が発生しているかをチェックする（ステップＳ４０２）。ここで、異常状態が発生していなければ（ステップＳ４０２：Ｎｏ）、送信したリクエストメッセージが最後のリクエストメッセージかどうかを確認し（ステップＳ４０３）、最後のリクエストメッセージであれば（ステップＳ４０３：Ｙｅｓ）、次に送信するリクエストメッセージを監視ルールの最初のメッセージに戻して（ステップＳ４０４）、図４のステップＳ１０１に戻る。一方、送信したリクエストメッセージが最後のリクエストメッセージでなければ（ステップＳ４０３：Ｎｏ）、何もせず図４のステップＳ１０１に戻る。

また、ステップＳ４０２において異常状態が発生していると判定した場合（ステップＳ４０２：Ｙｅｓ）、データ監視部１１９は、レスポンスメッセージから異常状態の内容を解析し、ルール管理部１２０に渡す。ルール管理部１２０は、受け取った異常状態の内容に対応する特定ルール、すなわち、発生した異常状態の原因を特定するために必要なルールを選択し、送信メッセージ取得部１１１に渡す。送信メッセージ取得部１１１は、現在設定されている監視ルールを、ルール管理部１２０から受け取った特定ルールに切り替えて（ステップＳ４０５）、図４のステップＳ１０１に戻る。

また、現在設定されているルールが監視ルールでない場合、つまり特定ルールが設定されている場合（ステップＳ４０１：Ｎｏ）、データ監視部１１９は、送信したリクエストメッセージが特定ルールの最後のリクエストメッセージかどうかを確認し（ステップＳ４０６）、最後のリクエストメッセージであれば（ステップＳ４０６：Ｙｅｓ）、送信メッセージ取得部１１１に現在設定されている特定ルールを監視ルールに切り替える（ステップＳ４０７）。そして、検出した異常状態を再度出力させないよう、メッセージ処理部１１２からバスＩ／Ｆ１６０を介して、異常状態を出力したＥＣＵ２に対して指示メッセージを送信し（ステップＳ４０８）、図４のステップＳ１０１に戻る。一方、送信したリクエストメッセージが特定ルールの最後のリクエストメッセージでなければ（ステップＳ４０６：Ｎｏ）、何もせず図４のステップＳ１０１に戻る。なお、原因を特定した異常状態を再度検出しない方法として、該当する異常状態をチェックするリクエストメッセージを送信しないように監視ルールから削除してもよい。

なお、ルール管理部１２０が管理するルールをデータ蓄積部１８０に保管している場合、ルールを切り替える手順は次のようになる。ルール管理部１２０は、データ蓄積部１８０からルールを読み出す指示を、データ転送部１１３を経由して、データアクセス処理部１１６に渡す。データアクセス処理部１１６は、データ蓄積部１８０に読み出し指示を渡す。データ蓄積部１８０は、読み出し指示に応じてルールを読み出し、データアクセス処理部１１６に渡す。データアクセス処理部１１６は、データ蓄積部１８０から読み出されたルールを、データ転送部１１３を介してルール管理部１２０に渡す。ルール管理部１２０は、送信メッセージ取得部１１１にルールを渡し、送信メッセージ取得部１１１は、現在設定されているルールを、ルール管理部１２０から受け取ったルールに切り替える。

本実施形態のように、データ監視部１１９によるＥＣＵ２の状態把握と、ルール管理部１２０によるＥＣＵ２の異常状態に応じたルールの設定を行う構成は、特にデータ格納装置１００に必要な記憶容量の削減、およびＥＣＵ２が送受信する不要なリクエストメッセージ・レスポンスメッセージの削減、および車載ネットワーク１に流れる不要なメッセージの削減による負荷軽減に特に有用である。すなわち、異常発生に備えて常に異常状態に関係するデータを取得するために、あらゆるリクエストメッセージを送信し、あらゆるレスポンスメッセージを受信すれば、異常状態の原因の特定に必要なデータを収集できる。しかし、この場合は、発生した異常の原因特定と関係のないデータを多く含むことになる。そのため、データ格納装置１００やＥＣＵ２、車載ネットワーク１には無駄なリクエストメッセージを送信したり、無駄なレスポンスメッセージを受信したりする負荷が余計にかかる。さらにデータ格納装置１００には無駄なレスポンスメッセージを記録するための余計なデータを記録することになる。これに対し、本実施形態のように、ＥＣＵ２の状態に合わせたデータだけを収集する構成とすることで、データ格納装置１００やＥＣＵ２、車載ネットワーク１が送受信する不要なリクエストメッセージやレスポンスメッセージを削減し、データ格納装置１００の記憶容量を削減することができる。

（変形例）
以上説明した第２実施形態では、異常状態の発生が検出されたときにルールの切り替えを行っていた。しかし、データ格納装置１００の接続先の変更時にもルールの切り替えを行う構成としてもよい。つまり、本変形例は、データ格納装置１００の接続先の変更時に、接続先の車種に合わせたリクエストメッセージが送信されるように、自動的にルールを切り替える。

図１１は、本変形例に係るデータ格納装置１００の機能的な構成例を示すブロック図である。図８に示した第２実施形態の構成との違いは、物理Ｉ／Ｆ挿抜検出部１２１と車種特定部１２２とが追加されている点である。

本変形例のデータ格納装置１００は、データ格納装置１００の接続先の変更時に、ルール管理部１２０が管理するルールセットを接続先車種に対応したルールセットに変更する。ここで、ルールセットとは監視ルールと特定ルール一式のことを指しており、車種ごとに異なるルールセットが定められている。ルールセットとルールの対応関係および車種とルールセットの対応関係の一例を図１２に示す。図１２（ａ）がルールセットとルールの対応関係、図１２（ｂ）が車種とルールセットとの対応関係をそれぞれ示している。

物理Ｉ／Ｆ挿抜検出部１２１は、物理インタフェースが挿抜されたことを検出する処理部である。物理Ｉ／Ｆ挿抜検出部１２１は、物理インタフェースの挿抜を検出すると、車種特定部１２２に対して物理インタフェースが挿抜されたことを示す信号を通知する。物理インタフェースの挿抜を検出する方法として、例えば、物理Ｉ／Ｆ挿抜検出部１２１が、データ格納装置１００が接続されている物理インタフェースから供給される電源電圧を常に監視し、その電源電圧の変化によって物理インタフェースの挿抜を検出してもよい。また、それ以外の挿抜検出方法を使用してもよい。

車種特定部１２２は、データ格納装置１００が接続されている車種を特定する情報を取得する処理部である。車種特定部１２２は、物理Ｉ／Ｆ挿抜検出部１２１から物理インタフェースが挿抜されたことを示す信号を受け取ると、車種を特定する情報を取得するため、データ格納装置１００の接続先となる車種情報を要求するメッセージを、メッセージ処理部１１２を経由してバスＩ／Ｆ１６０からネットワークバス５に送出する。車種特定部１２２が接続先の車種に関する情報を取得すると、その情報をルール管理部１２０に渡す。なお、車種情報を取得する方法として、例えば、ＥＣＵ２もしくはデータ格納装置１００とバスを介して通信可能な外部記憶装置が持つ車種情報を取得する方法でもよいし、車種に固有のＥＣＵ２およびＥＣＵ２が制御する車両を構成する装置からレスポンスメッセージを受け取ることで判断する方法でもよいし、外部装置からデータ格納装置１００に向けて車種情報を送信してもよい。また、車種によってＥＣＵ２の構成やバスの構成が異なることを利用して、接続先の車種を特定してもよい。

図１３は、本変形例に係るデータ格納装置１００による処理手順の一例を示すフローチャートであり、物理インタフェースの挿抜を検出した際、接続先の車種を特定し、車種に対応するルールに切り替える処理動作の一例をまとめたものである。

まず、物理Ｉ／Ｆ挿抜検出部１２１が物理インタフェースの挿抜を検出すると（ステップＳ５０１：Ｙｅｓ）、物理インタフェースが挿抜されたことを車種特定部１２２に通知する。車種特定部１２２は、この通知を受けて、上述の方法によりデータ格納装置１００が接続されている車種を特定する情報を取得して、その情報をルール管理部１２０に渡す（ステップＳ５０２）。

ルール管理部１２０は、車種特定部１２２からデータ格納装置１００の接続先の車種を特定する情報を取得すると、自身が管理するルールセットをその接続先車種に対応するルールセットに変更する（ステップＳ５０３）。そして、ルール管理部１２０は、そのルールセットに含まれるルールを取得する処理を行う。例えば、ルールがデータ蓄積部１８０に保存されている場合、ルール管理部１２０は、データアクセス処理部１１６を経由してデータ蓄積部１８０からルールを読み出すよう指示する。接続先車種に対応するルールセットに含まれるルールを読み出す方法として、データ蓄積部１８０に車種情報のメタデータを付与したルールセットを保存しておき、車種を指定してルールを読み出す方法がある。なお、接続先車種に対応するルールセットが存在しない場合もある。

車種に対応するルールセットが存在する場合（ステップ５０４：Ｙｅｓ）、そのルールセットに含まれるルールがデータ蓄積部１８０から読み出され、データアクセス処理部１１６からデータ転送部１１３を介してルール管理部１２０に渡される。ルール管理部１２０は、車種に対応するルールを受け取ると、そのルールを送信メッセージ取得部１１１に渡す。送信メッセージ取得部１１１は、ルール管理部１２０からルールを受け取ると、現在設定されているルールを、ルール管理部１２０から受け取ったルールに切り替える（ステップＳ５０５）。以降、図４および図１０のフローチャートで示した処理が行われる。

一方、車種に対応するルールセットが存在しない場合（ステップＳ５０４：Ｎｏ）、ルール管理部１２０は、送信メッセージ取得部１１１のルールを空欄にし、接続先車種に対応していないリクエストメッセージを送信しないよう、リクエストメッセージの送信を停止させる（ステップＳ５０７）。以降、図５のフローチャートに従って、データの読み出しやメッセージの受信のみ行う。このとき、データ格納装置１００は車種に対応するルールを持っていないことをメッセージに載せてネットワークバス５に送出し、他の機器に通知してもよい。

以上説明した本変形例の構成は、特にデータ格納装置１００に手を加えることなく、データ格納装置１００を搭載する車種を容易に変更できる点で特に有用である。すなわち、車種によってＥＣＵ２の構成が異なると、送信するリクエストメッセージや受信するレスポンスメッセージの内容も異なるが、物理インタフェースの抜き差しに合わせてデータ格納装置１００を搭載した車種に対応したルールに自動に変更することで、データ格納装置１００を任意の車種の車両Ｖに搭載された車載ネットワーク１に接続することが容易になる。また、データ格納装置１００の接続先車種に対応しないリクエストメッセージを誤って送信することも防ぐことができるため、接続先の車載ネットワーク１に余計なメッセージを送信するのを防いだり、ＥＣＵ２が誤動作することを防いだりできる。

＜第３実施形態＞
次に、第３実施形態について説明する。上述の第２実施形態では、データ格納装置１００がＥＣＵ２に異常がないかをチェックし、もし異常状態が検出されれば、異常状態の原因を特定するために必要なデータだけを選択して収集する構成を示した。この構成では、ＥＣＵ２に現在の状態や異常の有無を示すデータを要求するリクエストメッセージは、ルールという形でデータ格納装置１００内に保存されている。また、ルールはデータ格納装置１００を車両Ｖに搭載する前に、製造段階でデータ蓄積部１８０に格納しておくことを想定していた。

これに対し第３実施形態では、データ格納装置１００がルールを更新するためのメッセージを外部から受け取り、データ蓄積部１８０に保存されたルールを更新する機能を備えた構成を示す。

図１４は、第３実施形態に係るデータ格納装置１００の機能的な構成例を示すブロック図である。図８に示した第２実施形態の構成との違いは、更新データ処理部１２３が追加されている点である。

更新データ処理部１２３は、ネットワークバス５を介して受信したルールの更新データを取得し、更新データの内容をチェックして、ルールを更新すべきかどうかを判断し、問題がなければ、データ蓄積部１８０に格納されたルールを更新する。

更新データは、例えば、診断プロトコルのフォーマットでデータ格納装置１００に送付される。更新データは、サービスＩＤ領域に更新データを示すＩＤが設定され、データ領域に更新対象の情報と更新データの本体がそれぞれ設定される。更新データを示すＩＤは、メッセージが、診断を要求するリクエストメッセージではなく、ルールを更新するデータを含むメッセージであることをデータ格納装置１００に伝える。更新対象の情報には、ルールのバージョンと更新するルールについて記載されている。更新するルールについて、例えば、データ格納装置１００が持つ特定のルールに対する更新なのか、ルール全体に対する更新なのか、新たなルールセットの追加なのかといった内容が記載されている。データ格納装置１００は、更新対象の情報をもとに更新するルールを認識し、更新元のルールが格納されている場所を特定する。なお、更新データの構成は、診断プロトコルに従ったフォーマットに限らない。例えば、独自のフォーマットでもよい。

更新データ処理部１２３は、受け取った更新データの内容をチェックし、更新対象のルールを更新すべきか否かを判断する。例えば、更新データ処理部１２３は、更新データのバージョンや更新対象のルールが存在するか、更新データのバージョンが更新対象のルールよりも新しいかといったことをチェックする。まず、更新データ処理部１２３は、更新データから更新対象のルールを特定する。更新対象のルールが存在すれば、更新データ処理部１２３は、更新対象のルールの情報をルール管理部１２０から取得し、更新ルールのバージョンと更新対象のルールのバージョンと比較する。更新ルールのバージョンの方が新しければ、更新データ処理部１２３は、データ蓄積部１８０に格納されたルールを更新する。

具体的には、更新データ処理部１２３は、更新データの内容に合わせて、データ蓄積部１８０に格納されたルールを更新する指示をデータアクセス処理部１１６に渡す。ルールを更新する指示（更新指示）は、更新対象のルールが格納された場所を示す物理アドレスと、更新データを更新対象のルールの格納場所に上書きするようデータアクセス処理部１１６に指示する内容となっている。ルール管理部１２０が持つルールを更新する場合、ルール管理部１２０に更新データを渡し、ルール管理部１２０がルールを更新するか、ルール管理部１２０にデータ蓄積部１８０から更新データを読み込ませればよい。

更新データ処理部１２３によるルールの更新は、データ蓄積部１８０に格納されている既存のルールを置き換える方法のほかに、新たなルールを追加してもよい。新たなルールを追加する場合、更新データ処理部１２３は、追加されたルールについてルール管理部１２０に通知し、ルール管理情報を更新する。以降、ルール管理部１２０は新たに追加されたルールを参照するようにする。

図１５は、本実施形態に係るデータ格納装置１００による処理手順の一例を示すフローチャートであり、更新メッセージを受信し、データ蓄積部１８０に格納されたルールを更新する処理動作の一例をまとめたものである。この図１５のフローチャートで示す一連の処理は、バスＩ／Ｆ１６０がネットワークバス５を介して更新データを含むメッセージを受信するたびに繰り返し実行される。

バスＩ／Ｆ１６０から受信メッセージを受け取ったメッセージ処理部１１２は、そのメッセージに含まれるデータ部分を取り出し、データ転送部１１３に渡す。データ転送部１１３は、受け取ったデータのサービスＩＤを参照して更新データであることを認識し（ステップＳ６０１：Ｙｅｓ）、その更新データを更新データ処理部１２３に渡す。

更新データ処理部１２３は、データ転送部１１３から受け取った更新データのデータ領域に設定された更新対象の情報を参照し、更新データのバージョンや更新対象のルールが存在するかをチェックすることにより、ルールの更新かどうかを判定する（ステップＳ６０２）。ここで、更新対象のルールが存在する場合、つまりルールの更新であると判断した場合（ステップＳ６０２：Ｙｅｓ）、更新データ処理部１２３は、次に、更新データのバージョンが更新対象のルールよりも新しいかどうかを判定する（ステップＳ６０３）。

ここで、更新データの方が新しければ（ステップＳ６０３：Ｙｅｓ）、更新データ処理部１２３は、更新対象の情報から更新指示を生成し（ステップＳ６０４）、更新データの本体と更新指示をデータアクセス処理部１１６に渡す（ステップＳ６０５）。そして、データアクセス処理部１１６は、更新指示と更新データ本体から書き込み先情報（物理アドレスとサイズなど）を生成し、更新データ本体と合わせてデータ蓄積部１８０に渡す。データ蓄積部１８０は、データアクセス処理部１１６から受け取った書き込み先情報に基づき、更新対象のデータの格納場所に更新データの本体を上書きすることにより、更新対象のルールを更新する（ステップＳ６０６）。その後、更新データ処理部１２３は、ルール管理部１２０が持つ更新対象のルールを更新する（ステップＳ６０７）。

一方、更新データのバージョンが更新対象のルールのバージョンよりも古い場合（ステップＳ６０３：Ｎｏ）、更新データ処理部１２３は、更新データを破棄し（ステップＳ６０８）、ルールの更新を行わない。また、更新データのデータ領域に設定された更新対象の情報に更新対象のルールが存在しない場合、つまりルールの更新ではなくルールの新規追加である場合は（ステップＳ６０２：Ｎｏ）、更新データ処理部１２３は、更新データの本体と書き込み指示をデータアクセス処理部１１６に渡し、データ蓄積部１８０に更新データを新規に格納させることにより、ルールを追加させる（ステップＳ６０９）。そして、更新データ処理部１２３は、追加のルールについてルール管理部１２０に通知し、ルール管理情報を更新する（ステップＳ６１０）。

なお、ここではルール単位の更新を例に説明したが、ルールの更新単位はルール単位だけでなく、ルールセット単位でもよいし、あるルールセット全体を更新単位してもよい。あるいは、新たな車種に対応するルールおよびルールセットを追加してもよい。

また、更新対象はルールだけでなく、データ格納装置１００を制御するソフトウェアプログラムでもよい。ソフトウェアプログラムを更新する目的として、例えば、第１実施形態の変形例で説明したスケジューラ部１１７のメッセージ送信タイミングを更新する、データ監視部１１９の動作状態メッセージからＥＣＵ２が異常状態かどうかを判断するアルゴリズムを更新する、ソフトウェアプログラムに見つかった脆弱性を修正する、データ格納装置１００に機能を追加するなどが挙げられる。

ソフトウェアプログラムの更新を実行する場合、ルールの更新と次のような違いがある。まず、更新データ処理部１２３は、データ蓄積部１８０に格納されているソフトウェアプログラムの格納場所を特定可能な情報を保持しているものとする。ソフトウェアプログラムの更新データの構成は、ルールの更新データの構成と同じである。サービスＩＤ領域には更新データを示すＩＤが設定され、更新対象の情報にソフトウェアプログラムの更新データのバージョンとソフトウェアプログラムが更新対象ということが記載されている。

データ格納装置１００は、図１５のルール更新処理と同等の手順で、ソフトウェアプログラムの更新データを取得し、データ蓄積部１８０に格納されている既存のソフトウェアプログラムの格納場所に更新データを上書きする。これにより、データ格納装置１００が再起動するタイミングで更新後のソフトウェアプログラムが起動することになる。具体的には、データ格納装置１００の電源がＯＮ／ＯＦＦされて、データ格納装置１００が再起動すると、データ格納装置１００は更新後のソフトウェアプログラムを読み出し、実行する。また、データ格納装置１００の電源のＯＮ／ＯＦＦに限らず、車両Ｖの停車中など、データ格納装置１００が一時的にデータの取得や蓄積を中断しても影響が軽微なタイミングでデータ格納装置１００を再起動し、ソフトウェアプログラムを更新してもよい。また、データ格納装置１００上で実行中のソフトウェアプログラムに対し、直接メインメモリ１５０上のデータをオンザフライで書き換えることで、データ格納装置１００を再起動することなくソフトウェアプログラムを更新してもよい。

更新メッセージの送信元となる機器は、データ格納装置１００にメッセージを送信できる機器であればよく、外部サーバや外部記憶装置などの外部装置７であってもよい。この場合、通信装置３が無線通信Ｉ／Ｆ４を介して外部装置７から送信される更新メッセージを受信し、ネットワークバス５を介してこの更新メッセージをデータ格納装置１００に送信する。

ルールの更新やデータ格納装置１００を制御するソフトウェアプログラムの更新は、更新データを含むメッセージを受信した時点で、データ格納装置１００によって自動的に行われてもよいし、更新処理の実行を許可する機能をデータ格納装置１００に持たせ、車両Ｖの運転手や整備士といったユーザの操作による更新処理の実行許可をデータ格納装置１００が受け取った時に、更新処理が実行されるようにしてもよい。

以上説明した本実施形態の構成によって、データ格納装置１００の機能を改善する、新たな機能を追加する、ソフトウェアのバグを修正するといったことが可能になり、データ格納装置１００のライフサイクルを伸ばすことができる。データ格納装置１００が搭載される自動車などの車両Ｖは１０年以上使用されることもあり、それに合わせてデータ格納装置１００の製品寿命を設計する必要がある。その場合、ソフトウェアの更新機能によりデータ格納装置１００の機能が危殆化・陳腐化せず使用し続けられることは重要である。

さらに、この構成によって、市場出荷後の車両Ｖに搭載されたデータ格納装置１００のルールおよびソフトウェアプログラムを更新するコストを削減するのにも有効である。なぜなら、車両Ｖに搭載されている無線通信Ｉ／Ｆ４を利用して外部装置７から更新メッセージを受信できるため、車両Ｖの所有者がディーラーに出向いて整備担当者の手を借りて更新作業をしたり、車両Ｖの所有者に整備担当者を派遣して更新作業をさせたりする必要がなくなるからである。データ格納装置１００を搭載する車両Ｖの販売台数が多くなるほど、このコスト削減の効果は大きくなる。

（変形例）
以上説明した第３実施形態では、データ格納装置１００のルールやソフトウェアを更新するためのメッセージに含まれる更新データが、正当なルールやソフトウェアプログラムであることを前提としていた。しかし、上述の更新機能が悪用され、更新データが改ざんされると、不正なルールやソフトウェアプログラムがデータ格納装置１００に設定される懸念がある。そこで、更新データの改ざんを検知する機能をデータ格納装置１００にさらに持たせるようにしてもよい。

図１６は、本変形例に係るデータ格納装置１００の機能的な構成例を示すブロック図である。図１４に示した第３実施形態の構成との違いは、署名検証部１２４が追加されている点である。

署名検証部１２４は、データ格納装置１００が受け取ったデータに署名が付与されている場合、データの改ざんを検知するため、署名を検証する処理部である。署名検証部１２４が検証可能な署名アルゴリズムは、一方向ハッシュ関数と、鍵管理部１１５が保持する鍵を用いた公開鍵暗号アルゴリズムからなる署名アルゴリズムである。前提として、データ格納装置１００は、署名検証用の公開鍵もしくはＭＡＣ検証用の共通鍵を鍵管理部１１５に保持しているものとする。この検証用の鍵は、データ格納装置１００の製造時に鍵管理部１１５に書き込んでもよいし、車両Ｖの運転手や整備士など人間の操作でネットワークバス５につながる機器経由で取得してもよい。

署名検証の方法は次の通りである。署名検証部１２４は、一方向ハッシュ関数を用いて受け取ったデータのハッシュを計算する。次に、受け取ったデータに付与された署名を、鍵管理部１１５が保持する署名元の公開鍵を利用して復号し、ハッシュを取得する。計算したハッシュと復号したハッシュを比較し、一致していれば検証に成功したとする。

一方向ハッシュ関数は、ＭＤ５，ＳＨＡ−２５６，ＳＨＡ−３などのよく知られたアルゴリズムを利用できる。公開鍵暗号アルゴリズムは、ＲＳＡや楕円曲線暗号などのよく知られたアルゴリズムを利用できる。なお、署名検証部１２４は、公開鍵暗号を利用する署名アルゴリズム以外に、共通鍵暗号を利用するＭＡＣアルゴリズムやハッシュ関数を利用するＨＭＡＣを検証できる構成であってもよい。

図１７は、本変形例に係るデータ格納装置１００による処理手順の一例を示すフローチャートであり、更新データが改ざんされていないかを確認するため、更新データに付与された署名を検証する処理動作の一例をまとめたものである。この図１７のフローチャートで示す処理は、図１５のステップＳ６０２の前に追加されて実施される。

データ転送部１１３は、受信メッセージに含まれるデータをメッセージ処理部１１２から受け取ると、受け取ったデータのサービスＩＤを参照して署名付きの更新データであることを認識し（ステップＳ７０１：Ｙｅｓ）、その署名付きの更新データを署名検証部１２４に渡す。署名検証部１２４は、データ転送部１１３から署名付きの更新データを受け取ると、鍵管理部１１５から署名に対応する公開鍵を取得して、この公開鍵で署名を検証する（ステップＳ７０２）。

ここで、署名の検証に成功した場合（ステップＳ７０３：Ｙｅｓ）、署名検証部１２４は、データ転送部１１３に検証成功を通知する。データ転送部１１３は、検証成功の通知を受けて更新データを更新データ処理部１２３に渡し、図１５のステップＳ６０２以降の処理が行われる。一方、署名の検証に失敗した場合は（ステップＳ７０３：Ｎｏ）、更新データが改ざんされた可能性があるため、署名検証部１２４は検証失敗をデータ転送部１１３に通知し、更新データを破棄する（ステップＳ７０４）。なお、更新データには署名の代わりにＭＡＣを付与し、署名ではなくメッセージ認証を利用して改ざんの有無をチェックしてもよい。

以上説明した本変形例の構成は、ルールの更新機能を悪用され、不正なルールやソフトウェアプログラムがデータ格納装置１００に設定されることを防ぐ際に特に有効である。外部装置７が無線通信Ｉ／Ｆ４を経由して更新メッセージを送信する場合、利便性が高い半面、悪意のある更新メッセージにより、不正なルールやソフトウェアプログラムがデータ格納装置１００に設定される虞がある。本変形例では、更新メッセージの署名の検証を行うことで、更新メッセージの改ざんを検出することができる。それによって、更新データが改ざんされていないことを保証し、データ格納装置１００が攻撃を受けて意図しない動作をする可能性を減らすことができる。さらに、署名を使用すれば、更新メッセージの作成者を確認することができることから、より更新データの信頼性を高めることができる。

＜第４実施形態＞
次に、第４実施形態について説明する。上述の第１実施形態では、ＥＣＵ２から受信したリクエストメッセージや制御データをデータ蓄積部１８０に格納する際、データアクセス処理部１１６が書き込み先情報（例えば、物理アドレスとデータのサイズ）を指定することで、データ蓄積部１８０への書き込みを制御している。第１実施形態において、データアクセス処理部１１６は、受け取ったデータをそのまま書き込むという方法であった。この手法は、データ蓄積部１８０に使われているＮＡＮＤフラッシュメモリの品質が高く、読み出し時に発生する誤り率が低いことを想定していた。

これに対し、第４実施形態では、後述のデータ監視部が、データ転送部１１３から受け取ったデータをデータアクセス処理部１１６に渡す前に、データの重要度を判定する。データ格納装置１００は、受け取ったデータが重要なデータならばよりロバストになるように信頼性を高める情報を付与してデータ蓄積部１８０に格納し、それ以外のデータならばデータの格納に必要な領域の増加を抑えることを優先し、データ格納装置１００の用途に適した必要最小限の情報を付与してデータ蓄積部１８０に格納する。この方法は、データの重要度に応じて信頼性を高める情報を変えることで、データをロバストに格納しながら、信頼性を高める情報を計算する処理負荷を小さくし、かつ、信頼性を高める情報を付加することによる情報量の増加も小さく抑えることを可能にする。

一般に、記憶装置としてＮＡＮＤフラッシュメモリを持つＳＳＤやＳＤカードは、ＮＡＮＤフラッシュメモリの品質を長期にわたって保ち、寿命を延ばすための仕組みを持つ。例えば、ＮＡＮＤフラッシュメモリの局所的な劣化を防止するため書き込み回数の平滑化を行うウェアレベリング機能や、ブロックの書き換え回数を管理し劣化したブロックへの書き込みを回避する不良ブロック管理機能、読み出し誤りが発生した場合に備え書き込みデータに誤り訂正信号を付与する機能、複数のブロックに同じデータを書き込み１つのブロックが読み出し不能になっても他のブロックから読み出す多重書き込み機能などがある。以下では、これらを総称して信頼性担保処理という。信頼性担保処理は、ＳＳＤやＳＤカードの内部コントローラが処理する。また、書き込みデータに付与される誤り訂正信号や多重書き込みされたデータのような情報は、ＮＡＮＤフラッシュメモリの容量を消費する。加えて、書き込み寿命に達したブロックの代用などのために、通常、ＳＳＤやＳＤカードは、公称の記憶容量よりも大きなＮＡＮＤフラッシュメモリを余分に持つことがある。

ＳＳＤやＳＤカードは汎用的な用途を想定しており、信頼性担保処理は書き込まれるデータの内容や性質に関わらず実行される。そのため、用途によっては非効率な方法になる可能性がある。例えば、データ格納装置１００のようにネットワークバス５に流れるメッセージを取得してメッセージに含まれるデータを格納する場合、データ蓄積部１８０に書き込むデータは、主に、定期的に受信するメッセージや異常状態の原因を特定するレスポンスメッセージに含まれるデータである。このとき、記憶容量が十分にあれば、頻繁なデータの消去や書き換えは起こらず、データを時系列に格納していく。また、データを蓄積することが主であり、データの読み出しの回数は書き込む回数よりも相対的に少ない。このような用途の場合、ＮＡＮＤフラッシュメモリの書き込み回数に起因した品質の劣化は生じづらい。そのため、汎用的な用途を想定したウェアレベリング機能や誤り訂正信号付与機能などをデータ格納装置１００に適用すると、過剰な品質保証になる可能性がある。過剰な品質保証により、余計な信頼性担保処理を計算するコストが生じ、不要な信頼性を高める情報で記憶領域が消費されてしまう。

ネットワークバス５に流れるメッセージを取得して格納する際の特徴として、頻繁な書き換えが生じず、長期運用時のＮＡＮＤフラッシュメモリのブロック劣化が汎用的な用途の場合よりも小さいことがある。この特徴を活かして、信頼性担保処理を軽量化することができる。信頼性担保処理の軽量化とは、汎用的な用途を想定した場合と同じ寿命を維持しながら、汎用的な用途を想定した場合よりも、ウェアレベリング機能の実行頻度を減らしたり、書き込みデータに付与する誤り訂正信号を小さくしたり、多重書き込みの多重化数を減らしたり、もしくは多重書き込みをやめたりして、処理を軽くすることである。信頼性担保処理を軽量化することで、プロセッサ１１０の処理負荷を抑えたり、信頼性を高める情報の格納に必要な領域を減らしたりできる。しかし、書き込みデータすべてに対して一様に信頼性担保処理を軽量化すると、用途によっては寿命が保証できない可能性がある。

そこで、第４実施形態では、受信したメッセージに含まれるデータにその内容に応じた重要度を付与し、重要度によって信頼性担保処理の内容を変える構成とする。具体的には、二種類の信頼性担保処理を定める。１つは汎用的な用途を想定した信頼性担保処理、もう１つは軽量化した信頼性担保処理とする。重要なデータには汎用的な用途を想定した信頼性担保処理を適用し、それ以外のデータには軽量化した信頼性担保処理を適用する。重要度が高いデータは、データ格納装置１００に頻繁なデータの消去や書き換えがあっても、確実に読み出せるよう保証する。それ以外は、頻繁な書き換えが発生しないデータを蓄積する用途に限って読み出しを保証し、信頼性担保処理に必要なプロセッサ１１０の処理能力やデータ蓄積部１８０の記憶領域を小さく抑える。

図１８は、第４実施形態に係るデータ格納装置１００の機能的な構成例を示すブロック図である。図３に示した第１実施形態の構成との違いは、データ監視部１２５とデータ格納処理部１２６とが追加されている点である。

データ監視部１２５は、データ転送部１１３からデータ蓄積部１８０に書き込むデータを受け取り、データの内容に基づいてそのデータの重要度を判定して、データ蓄積部１８０に書き込むデータとその重要度をデータ格納処理部１２６に渡す。データに付与する重要度は、重要であることを示すメタデータとする。なお、説明を簡略化するために、重要度は重要かそうでないかの２通りとし、重要なデータを重要データ、それ以外のデータを非重要データとする。なお、データに付与する重要度に３通り以上の段階を設定し、より綿密な重要度に基づく信頼性担保処理の切り替えを行うようにしてもよい。

データ監視部１２５がデータ転送部１１３から受け取るデータとしては、例えば、ＥＣＵ２からレスポンスメッセージとして送信された診断情報やＥＣＵ２間でやり取りされる制御データ、制御対象のシステム（エンジンやトランスミッション、エアバッグなど）の動作状態を示すデータなどがある。重要データの例として、異常状態を示す診断情報や安全性に影響のあるエンジンやエアバッグの動作状態を示すデータなどが挙げられる。非重要データとして、安全性には影響のないエアコン操作のデータや、ウィンドウの開け閉め指示などが挙げられる。なお、データ監視部１２５がどのようなデータに重要度を設定するのかは、データ格納装置１００の出荷時に決めてもよいし、製品出荷後に設定してもよい。

データ格納処理部１２６は、データ監視部１２５からデータとその重要度を受け取り、重要度に応じてデータに対する信頼性担保処理を行う。ここでは、重要度に応じて切り替える信頼性担保処理として、（ａ）誤り訂正符号の付与、（ｂ）書き込み回数が少ないブロックへの書き込み、（ｃ）同一データの複数ブロックへの書き込み、の３つを想定する。データ格納処理部１２６は、重要度に応じた信頼性担保処理を行い、その結果をデータに付与した上で、実際にデータをデータ蓄積部１８０に書き込む処理を行うデータアクセス処理部１１６へ渡す。付与するデータは、信頼性を高める情報とデータアクセス処理部１１６への指示である。具体的には、誤り訂正信号のほかに、データアクセス処理部１１６に対する書き込み回数が少ないブロックへの書き込み指示や、同じデータを複数のブロックに書き込む指示である。

ここで、上記（ａ）の誤り訂正符号の付与について説明する。誤り訂正符号をデータに付与してデータ蓄積部１８０に書き込むと、仮にデータを書き込んだブロックからデータを読み出した際に誤りが生じた場合、誤りの検出および訂正を行うことができる。誤り検出および訂正可能な誤りのサイズは付与する誤り訂正符号の符号長により決まり、符号長が長いほど誤り検出および訂正可能な誤りのサイズが大きくなる。そこで、データ格納処理部１２６は、重要データに長い誤り訂正符号を付与し、非重要データには短い誤り訂正符号を付与する。このとき、誤り訂正符号の方式として、ハミング符号、巡回ハミング符号、ゴレイ符号、ＢＣＨ符号、差集合巡回符号、ファイア符号、ターボ符号、ＬＤＰＣ、畳み込み符号などを使用してもよい。

次に、上記（ｂ）の書き込み回数が少ないブロックへの書き込みについて説明する。ＮＡＮＤフラッシュメモリはデータの書き込みを繰り返すことでブロックが次第に劣化していき、最終的に書き込みおよび読出しができなくなる。したがって、書き込み回数の少ないブロックに書き込まれたデータは書き込み回数の多いブロックに書き込まれたデータよりも信頼性が高い。そこで、データ格納処理部１２６は、重要データには書き込み回数が少ないブロックに優先的に書き込む指示を出し、非重要データには書き込み回数が少ないブロックを除外して残ったブロックに書き込む指示を出す。

次に、上記（ｃ）の同一データの複数ブロックへの書き込み（多重書き込み）について説明する。これは、同じデータを複数のブロックに書き込むことで一か所のブロックから読み出しができなくなっても、同じデータを書き込んだ別のブロックからデータを読み出すことで、データの信頼性を高める方法である。データ格納処理部１２６は、重要データには複数のブロックに同じデータを書き込む指示を付与し、非重要データには同じデータを書き込むブロック数を減らした指示を付与するか、この指示を付与せず、多重書き込みを行わない。

データ格納処理部１２６は、上記（ａ）〜（ｃ）の信頼性担保処理について、次に示す（１）〜（３）の基準に従って、重要データに対する信頼性担保処理と非重要データに対する信頼性担保処理とを切り替える。（１）重要データに付与する誤り訂正符号は、非重要データに付与する誤り訂正符号よりも長い。（２）重要データの書き込み先ブロックの書き込み回数は、非重要データに対する書き込み先ブロックの書き込み回数よりも少ない。（３）重要データを多重書き込みする多重化の数は、非重要データを多重書き込みする多重化の数よりも大きい。

なお、データ格納処理部１２６は、信頼性担保処理として上記（ａ）〜（ｃ）のいずれかを適用してもよいし、上記（ａ）〜（ｃ）を組み合わせて適用してもよい。また、信頼性担保処理は上記（ａ）〜（ｃ）の３つに限定するものではなく、他の処理を使用してもよい。

図１９は、本実施形態に係るデータ格納装置１００による処理手順の一例を示すフローチャートであり、レスポンスメッセージに含まれるデータに対して、データの内容に応じた重要度を付与し、重要度に応じた信頼性担保処理を行う処理動作の一例をまとめたものである。この図１９のフローチャートで示す処理は、図４のステップＳ１０７およびステップＳ１０８の処理に代えて実施される。

図４のステップＳ１０６で計算された署名とデータが署名生成部１１４から渡されると、データ転送部１１３は、署名生成部１１４から受け取ったデータと署名をデータ監視部１２５に渡す。データ監視部１２５は、データ転送部１１３から受け取ったデータの内容に基づいて、データの重要度を判定し（ステップＳ８０１）、データと署名とデータの重要度をデータ格納処理部１２６に渡す。データ格納処理部１２６は、データ監視部１２５から受け取ったデータと署名に対し、データの重要度に応じた信頼性担保処理を行う。すなわち、データ監視部１２５から受け取ったデータが重要データであれば（ステップＳ８０２：Ｙｅｓ）、データ格納処理部１２６は、重要データに基づく信頼性担保処理を実行する（ステップＳ８０３）。一方、データ監視部１２５から受け取ったデータが非重要データであれば（ステップＳ８０２：Ｎｏ）、データ格納処理部１２６は、非重要データに基づく信頼性担保処理を実行する（ステップＳ８０４）。そして、データ格納処理部１２６は、データと署名に加えて、信頼性担保処理の結果得られた誤り訂正符号とデータアクセス処理部１１６に対する指示をデータアクセス処理部１１６に渡す。

データアクセス処理部１１６は、データ格納処理部１２６からの指示に従って、データと署名と誤り訂正信号の書き込み先を決め（ステップＳ８０５）、データ蓄積部１８０に対してデータと署名と誤り訂正符号と書き込み先の物理アドレスを渡す。データ蓄積部１８０は、データアクセス処理部１１６から受け取ったデータと署名と誤り訂正符号を、書き込み先の物理アドレスが示す領域に格納する（ステップＳ８０６）。

以上説明した本実施形態の構成は、特にデータ蓄積部１８０に格納するデータの信頼性とデータ蓄積部１８０の記憶領域の容量を節約できる点で有用である。車載ネットワーク１を流れるメッセージは、重要なデータもあればそうでもないデータもある。重要なデータは高信頼性を確保し、データ格納装置１００が長期利用されていても確実に読み出せるようにする一方で、重要度が低いデータは信頼性よりも容量を優先することで、データ格納装置１００のコストを下げることができる。

記憶装置としてＮＡＮＤフラッシュメモリを持つＳＳＤやＳＤカードなどでは、物理アドレスによる書き込みや信頼性情報の付与を内部コントローラが行い、信頼性情報の管理や信頼性を向上させるための方式はＳＳＤやＳＤカードに固有の方式が用いられるため、汎用Ｉ／Ｆを介して外部から書き込むデータに対し、信頼性情報を付与することはできない。本実施形態では、データ格納装置１００にコントローラを含まないＮＡＮＤフラッシュメモリを使用し、物理アドレスで書き込みを行うことにより、データの重要度に基づき、信頼性を優先するか容量を優先するかを細かく制御することが可能となる。この機能により、コストを下げながらデータ格納装置１００の寿命を延ばすことが可能になる。

なお、本実施形態では、信頼性担保処理をデータの重要度に応じて行うが、データの保存期間に応じて行ってもよい。長期保存する必要のあるデータは高信頼性を確保し、ロバストにし、短期間で不要になるデータは信頼性よりも容量を優先してもよい。

（変形例）
以上説明した第４実施形態では、データに対する署名生成や信頼性担保処理、書き込み処理などを個々のデータに対し独立に行っていた。しかし、受信した複数のデータを解析し、共通の性質を持つデータ同士をまとめて１つのデータとして扱い、署名生成や信頼性担保処理や書き込み処理をまとめて行う構成としてもよい。

図２０は、本変形例に係るデータ格納装置１００の機能的な構成例を示すブロック図である。図１８に示した第４実施形態の構成との違いは、データ相関判定部１２７が追加されている点である。本実施形態では、データ相関判定部１２７を利用して複数のデータをまとめて１つのデータとし、まとめたデータに対して重要度を判定して、重要度に応じた信頼性担保処理を行うことを想定する。これにより、まとめたデータ全体を同じ信頼性で統一することができる。さらに、個々のデータに対して信頼性担保処理を行うよりも、処理効率が向上し記憶領域を節約できる。

データ相関判定部１２７は、データ転送部１１３から受け取った複数のデータの内容を解析し、複数のデータに共通する性質（相関関係）を求め、相関関係のある複数のデータを１つにまとめる処理部である。

ここで、データ相関判定部１２７が複数のデータ間に相関関係があると判定する具体例について説明する。例えば、同じ特定ルールに属するリクエストメッセージによってＥＣＵ２から取得したレスポンスメッセージは、相関関係があると判定する。理由としては、異常原因を特定するには同じ特定ルールに属するレスポンスメッセージをすべて解析する必要があり、どれか１つでも欠けてしまうと正しい解析ができなくなり、異常原因を特定できない可能性があるためである。同じ特定ルールに属する複数のレスポンスメッセージを扱う際、データ蓄積部１８０に格納するデータ間の信頼性に差があると、その中で信頼性が最も低いデータによって全体の信頼性が決まってしまう。つまり、データ蓄積部１８０に格納するデータの中で信頼性が最も低いデータよりも信頼性を高めたメッセージがあっても、効果がないことになる。そのような不整合をなくすため、データ相関判定部１２７は、同じ特定ルールに属する複数のレスポンスメッセージから得たデータに相関関係があると判定する。

なお、受け取った複数のデータ間に相関関係があるかどうかの判定は、複数のレスポンスメッセージが同一の特定ルールに属するか否かを基準とするほかに、同一の診断ルールに属するか否かを基準としてもよいし、そのほかの要因を基準としてもよい。

データ相関判定部１２７が、同一ルールに属するレスポンスメッセージ間に相関関係があると判定する処理の一例を説明する。まず、データ相関判定部１２７は、データ転送部１１３から受け取ったデータが属するルールを判別する。具体的には、データ相関判定部１２７は、受け取ったデータの診断内容を示すサービスＩＤを取得し、そのサービスＩＤが送信メッセージ取得部１１１に現在設定されているルールに含まれるかを確認する。もし、受け取ったデータのサービスＩＤが現在設定されているルールに含まれていれば、データ相関判定部１２７は、相関関係があると判断し、自身の記憶領域にデータをためる。もし、ルールに含まれていなければ、データ相関判定部１２７は、相関関係がないと判断し、受け取ったデータをデータ監視部１２５に送る。データ相関判定部１２７は、相関関係があるデータを一定数ためると、ためたデータを１つのデータにまとめ、データ監視部１２５に送る。

このとき、データ相関判定部１２７は、相関関係があると判定したデータを一定数蓄積してから１つにまとめてもよいし、送信メッセージ取得部１１１に現在設定されているルールが切り替わった時点で１つにまとめてもよい。現在設定されているルールが切り替わった時点でデータを１つにまとめる理由として、ルールが切り替わると、切り替わる前のルールに属するレスポンスメッセージの受信がなくなるため、切り替わる前の相関関係があるデータを一定数ためることができなくなる可能性があるからである。この場合、相関関係があると判定したデータを一定数ためてから１つにまとめる方法だけでは、データをまとめる機会がなくなってしまう。

図２１は、本変形例に係るデータ格納装置１００による処理手順の一例を示すフローチャートであり、データ格納装置１００が受信したリクエストメッセージを解析し、相関関係を持つ複数のデータ同士をまとめて１つのデータとして扱い、署名の付与や重要度の判定、信頼性担保処理、書き込み処理をまとめて行う処理動作の一例をまとめたものである。この図２１のフローチャートで示す処理は、図４のステップＳ１０５からステップＳ１０８までの処理に代えて実施される。

本実施形態では、図４のステップＳ１０４でメッセージ処理部１１２がレスポンスメッセージから取り出したデータは、データ転送部１１３からデータ相関判定部１２７に渡される。データ相関判定部１２７は、送信メッセージ取得部１１１に現在設定されているルールを取得し（ステップＳ９０１）、例えば、データ転送部１１３から受け取ったデータの診断内容を示すサービスＩＤが現在設定されているルールに含まれるかをチェックすることにより、データ転送部１１３から受け取ったデータが現在設定されているルールに基づいて取得されたデータか否かをチェックする（ステップＳ９０２）。

ここで、データ転送部１１３から受け取ったデータが現在設定されているルールに基づいて取得されたデータではない場合（ステップＳ９０２：Ｎｏ）、データ相関判定部１２７は、データ転送部１１３から受け取ったデータを相関関係がないデータと判定し（ステップＳ９０３）、そのデータを自身の記憶領域に蓄積することなくデータ転送部１１３に渡す。

一方、データ転送部１１３から受け取ったデータが現在設定されているルールに基づいて取得されたデータである場合（ステップＳ９０２：Ｙｅｓ）、データ相関判定部１２７は、データ転送部１１３から受け取ったデータを相関関係があるデータと判定し、自身の記憶領域にそのデータを蓄積する（ステップＳ９０４）。そして、データ相関判定部１２７は、自身の記憶領域に一定数のデータが蓄積されたか否かを確認し（ステップＳ９０５）、一定数のデータが蓄積されていなければ（ステップＳ９０５：Ｎｏ）、図４のステップＳ１０１に戻って以降の処理を繰り返す。一方、一定数のデータが蓄積されると（ステップＳ９０５：Ｙｅｓ）、データ相関判定部１２７は、自身の記憶領域に蓄積されたデータを１つのデータにまとめ（ステップＳ９０６）、１つにまとめたデータをデータ転送部１１３に渡す。

データ転送部１１３は、データ相関判定部１２７から受け取ったデータを署名生成部１１４に渡す。署名生成部１１４は、鍵管理部１１５から署名用の鍵を読み出し（ステップＳ９０７）、その鍵を用いてデータ転送部１１３から受け取ったデータの署名を計算し（ステップＳ９０８）、データと署名をデータ転送部１１３に渡す。データ転送部１１３は、署名生成部１１４から受け取ったデータと署名をデータ監視部１２５に渡す。以降、図１９のステップＳ８０１に進んで、図１９のフローチャートで示した一連の処理が行われる。なお、データ相関判定部１２７が蓄積したデータを１つのデータにまとめる処理は、送信メッセージ取得部１１１に現在設定されているルールが切り替わった時点でもよい。

以上説明した本変形例の構成は、特に署名生成や信頼性担保処理の計算負荷の軽減という点で有用である。受信したレスポンスメッセージのデータ１つ１つに対して署名生成や信頼性担保処理を行わず、相関関係のある複数のデータを１つにまとめて、まとめたデータに対して署名生成や信頼性担保処理を行うことで、データ蓄積部１８０に格納するデータをロバストにしながら、同時に、署名生成や信頼性担保処理に必要な計算負荷を軽減し、記憶領域を節約することできる。

＜第５実施形態＞
次に、第５実施形態について説明する。上述の各実施形態では、データ格納装置１００がＥＣＵ２に向けて自発的にリクエストメッセージを送信し、ＥＣＵ２の設定情報や動作状態、診断結果などを取得してデータ蓄積部１８０に蓄積する構成を示した。リクエストメッセージの送信やＥＣＵ２から情報を取得する動作を実現するのは、データ格納装置１００上で動作するソフトウェアプログラムである。ソフトウェアプログラムにバグや脆弱性がなく、問題なく動作することを前提にすれば、そのソフトウェアプログラムによって取得したデータはデータ格納装置１００内で改ざんされる虞はない。

上述の各実施形態では、データ格納装置１００上で動作するソフトウェアプログラムに問題がないことを前提としているため、データ格納装置１００で動作するソフトウェアプログラムの動作は記録していなかった。これに対し、第５実施形態では、ソフトウェアプログラムにバグや脆弱性が存在する場合があることも想定し、データ格納装置１００がＥＣＵ２の情報を取得してデータ蓄積部１８０に蓄積することと併せて、データ格納装置１００自身の状態も記録するものである。具体的には、データ格納装置１００がＥＣＵ２の情報を取得してデータ蓄積部１８０に蓄積する間、メインメモリ１５０の内容をダンプし、データ格納装置１００上で動作するソフトウェアプログラムの動作を記録する。

データ格納装置１００が取得してデータ蓄積部１８０に蓄積したＥＣＵ２の設定情報、動作状態および診断結果などを事故原因の特定のような第三者による分析に利用することを想定した場合、データが改ざんされていないかどうかの確認に加え、それらのデータを収集した機器が正常に動作していたかどうかの確認が必要になる。データ格納装置１００から読み出したデータが改ざんされていないかどうかの確認は、上述の第１実施形態で述べたように、データに付与された署名を検証することで行う。データ格納装置１００が正常に動作していたかどうかの確認は、本実施形態で述べるように、データ格納装置１００上で動作するソフトウェアプログラムの動作を記録したメモリダンプを分析することで行う。データ格納装置１００が蓄積したデータの改ざんをチェックすることに加え、データ格納装置１００自身の動作に問題がなかったことを確認することで、分析に利用するデータだけでなく、そのデータを収集したデータ格納装置１００そのものの信頼性も高めることができる。

図２２は、第５実施形態に係るデータ格納装置１００の機能的な構成例を示すブロック図である。図３に示した第１実施形態の構成との違いは、動作情報収集部１２８が追加されている点である。なお、説明を容易にするために、ハードウェアであるメインメモリ１５０も図示している。

動作情報収集部１２８は、メインメモリ１５０の内容をダンプし、データ転送部１１３に渡す。動作情報収集部１２８がダンプしたメインメモリ１５０の内容をメモリダンプと呼ぶ。メモリダンプは、データ転送部１１３を経由してデータアクセス処理部１１６に渡り、データ蓄積部１８０に格納される。

動作情報収集部１２８は、タイマ１４０の割込み通知を受けた時点や、動作情報収集部１２８が実行された時点でメモリダンプを取得する。ここではメモリダンプを取得するタイミングをタイマ１４０の割込み通知を受けた時点と想定して、動作情報収集部１２８の動作を説明する。タイマ１４０の割込み通知は、発生間隔が一定時間として周期的に発生してもよいし、不定期に発生してもよい。タイマ１４０の割込み通知が不定期な時間間隔で発生することで、動作情報収集部１２８がメモリダンプを取得するタイミングが、特定の処理の前後ではなく、不特定となる。こうすることで、データ格納装置１００が行う処理の決まった箇所の動作について確認するのではなく、様々な箇所の動作について確認することができ、処理全体の動作を確認できる。

ここで、動作情報収集部１２８がメモリダンプを取得する処理動作の一例について説明する。動作情報収集部１２８は、タイマ１４０からの割込み通知を受け取ると、メインメモリ１５０からメモリダンプを取得する。つぎに、動作情報収集部１２８は、取得したメモリダンプをデータ転送部１１３に渡す。データ転送部１１３は受け取ったメモリダンプと書き込み指示をデータアクセス処理部１１６に渡す。データアクセス処理部１１６は、受け取ったメモリダンプと自身で生成した書き込み先情報をデータ蓄積部１８０に渡す。データ蓄積部１８０は書き込み先情報により指定された書き込み先に、メモリダンプを格納する。

以上説明した本実施形態の構成は、データを取得して蓄積している最中のデータ格納装置１００の動作を検証することで、特にデータ格納装置１００が蓄積するデータの信頼性を高める効果がある。データ格納装置１００は記録データに署名を付与することで、記録データの改ざんの有無を確認することができる。しかし、データ格納装置１００のソフトウェアプログラムにバグがあり正しくデータを蓄積できない場合や、データ格納装置１００のソフトウェアに脆弱性があり、不正なプログラムに乗っ取られ、データ格納装置１００内部でデータの改ざんが発生する場合など、データ格納装置１００自体の動作に問題がある場合、署名を付与する前の記録データがそもそも信頼できない可能性が生じる。このような事態が起こることを想定し、データ蓄積部１８０に格納されたメモリダンプを分析することで、データ格納装置１００で動作するソフトウェアがどのような動作をしていたかを知ることができる。仮に、署名を付与する前に記録データの改ざんが判明すれば、そのデータを信頼できないことが分かる。また、不正なプログラムが動作情報収集部１２８を止めてしまう可能性が考えられるが、データ蓄積部１８０にメモリダンプが格納されていないことで、ソフトウェアプログラムの動作異常を知ることができる。

なお、動作情報収集部１２８が取得したメモリダンプの改ざんを防止するため、メモリダンプに署名を付与してもよい。例えば、動作情報収集部１２８からメモリダンプを受け取ったデータ転送部１１３は、データアクセス処理部１１６ではなく署名生成部１１４にメモリダンプを渡す。署名生成部１１４は、メモリダンプの署名を計算し、メモリダンプと署名をデータ転送部１１３に渡す。その後、データ転送部１１３は、署名生成部１１４から受け取ったメモリダンプと署名をデータアクセス処理部１１６に渡し、データ蓄積部１８０にそれらを格納させる。

＜第６実施形態＞
次に、第６実施形態について説明する。上述の各実施形態では、データ蓄積部１８０へのアクセスはデータアクセス処理部１１６を介して物理アドレスで行っていた。具体的には、データ蓄積部１８０に格納された記録データを読み出す場合、データ格納装置１００は、外部から受け取った読み出し先を指定する情報をデータアクセス処理部１１６で物理アドレスに変換し、データ蓄積部１８０から指定された記録データを読み出す。ここで、上述の各実施形態では、ネットワークバス５を介して読み出した記録データを送信することを想定していた。外部に記録データを送信する場合、データ格納装置１００は、ネットワークバス５を介して記録データの読み出し指示を受信し、読み出し指示から実際にデータ蓄積部１８０に書き込まれたデータを指定する物理アドレスを計算し、読み出したデータをネットワークバス５に送信していた。

これに対し第６実施形態では、データ蓄積部１８０へのアクセスにＬＢＡ（論理ブロックアドレス）を使用し、一般的なデータ格納装置（ストレージ製品）に使われる汎用インタフェースから記録データを読み出すことができるようにしたものである。データ蓄積部１８０へのアクセスにＬＢＡを使用することで、一般的なストレージ製品に使われているＳＡＳやＳＡＴＡといった汎用インタフェースを経由して、データ格納装置１００から記録データを読み出すことが可能になる。ネットワークバス５で想定されているＣＡＮなどの車載ネットワークの通信速度より、ＳＡＳやＳＡＴＡといった汎用インタフェースの読み出し速度の方が速いため、記録データを読み出す時間を短縮できる。さらに、汎用インタフェースは一般的なＰＣ（パーソナルコンピュータ）が備えているため、専用の通信インタフェースがなくても、データ格納装置１００とＰＣを接続し、データを読み出すことが可能になる。

図２３は、第６実施形態に係るデータ格納装置１００の機能的な構成例を示すブロック図である。図３に示した第１実施形態の構成との違いは、ハードウェアとしてストレージＩ／Ｆ２００が追加されているとともに、ＬＢＡ対応部１３１とファイルシステム生成部１３２とファイルシステム管理部１３３とが追加されている点である。

ストレージＩ／Ｆ２００は、データ格納装置１００と外部装置７を接続するためのインタフェースであり、図２に示した基板１９０上に搭載されている。外部装置７はストレージＩ／Ｆ２００を介して、データアクセス処理部１１６に指示を送り、データ蓄積部１８０にアクセスする。このとき、外部装置７はアクセスする場所の指定に、ＬＢＡを使用する。なお、ストレージＩ／Ｆ２００が接続するバスの規格は一般的なストレージ向け汎用インタフェース規格、例えばＳＡＳ，ＳＡＴＡなどを想定している。そのためＳＡＳ，ＳＡＴＡといったインタフェースを持つＰＣにデータ格納装置１００を接続し、ＰＣからデータ蓄積部１８０に格納された記録データにアクセスすることができる。なお、データアクセス処理部１１６は、ストレージＩ／Ｆ２００からデータ蓄積部１８０へのデータの書き込みを禁止し、読み出しを許可してもよい。

ＬＢＡ対応部１３１は、データアクセス処理部１１６で管理するデータを用い、ＬＢＡと物理アドレスの対応付けを行う処理部である。ＬＢＡ対応部１３１は、例えば図２４に示すようなＬＢＡと物理アドレスの変換テーブルを管理し、物理アドレスとＬＢＡの対応を取っている。なお、図２４に例示する変換テーブルは、ＬＢＡのブロックサイズと物理アドレスのブロックサイズが同じ場合を示しているが、異なっていてもよい。

例えば、データアクセス処理部１１６でウェアレベリングを実行し、データ蓄積部１８０のブロックの書き込み回数が平滑化された場合、記録データの保存先を示す物理アドレスが変わる可能性がある。また、あるデータを記録するブロックが壊れかけていれば、壊れかけのブロックを無効化し、別のブロックにコピーを作成するというブロックの置換を行った場合や、同じデータを複数のブロックに記録していて、参照先に設定していた一方のブロックを無効化し、同じデータを記録した別のブロックを新たな参照先として変更するブロックの交換を行った場合も、記録データの保存先を示す物理アドレスが変わる。このとき、ＬＢＡ対応部１３１は、あるデータの物理アドレスが変更された場合、データアクセス処理部１１６で管理する物理アドレスを用い、ＬＢＡと物理アドレスの変換テーブルを更新する。このように、ＬＢＡ対応部１３１がＬＢＡと物理アドレスの変換テーブルを更新することで、物理アドレスで書き込まれたデータをＬＢＡで参照しても、常に同じデータであることが保証される。データアクセス処理部１１６がデータ蓄積部１８０にアクセスする場合、ＬＢＡと物理アドレスとの対応関係をＬＢＡ対応部１３１が管理する変換テーブルから取得する。

ファイルシステム生成部１３２は、データ蓄積部１８０のフォーマットを行い、データ蓄積部１８０にＬＢＡでアクセスできるようにデータアクセス処理部１１６の管理データを作成する処理部である。ファイルシステム生成部１３２は、例えば、バスＩ／Ｆ１６０が初めて車両Ｖに接続されたことを検出したときや、データ格納装置１００に初めて電源が投入されたことを検出したときなどに、データ蓄積部１８０のフォーマットを実行する。

これ以外にも、外部からフォーマットの指示を受信し、ファイルシステム生成部１３２がこの指示に従ってデータ蓄積部１８０のフォーマットを実行するようにしてもよい。この場合、フォーマットはデータ蓄積部１８０の記録内容を消去してしまうため、ファイルシステム生成部１３２は、フォーマットを一度実行した後、二度目を実行しないように制限する方法や、二度目のフォーマットを実行する場合には、特定の機器からしか指示できないようにするなどの制限機能を有してもよい。なお、ファイルシステム生成部１３２は必須の構成要素ではなく、データ格納装置１００がフォーマット済みの状態で工場出荷されてもよい。

ファイルシステム管理部１３３は、データ蓄積部１８０に書き込まれるデータをファイルとして管理するため、ファイルシステムの管理情報を作成・保持する処理部である。

ファイルシステム管理部１３３の機能を説明するために、まず、ファイルシステムの一例について説明する。ここで、ファイルシステム管理部１３３が扱うファイル形式は、ファイルとディレクトリの２種類を想定する。データ蓄積部１８０には、ファイルを管理するための管理データ領域が設定されている。この管理データ領域は、データ蓄積部１８０をフォーマットする際に確保される。

管理データ領域は、（α）管理領域の保存場所を示す領域、（β）ファイル管理領域、（γ）ディレクトリデータ管理領域、（δ）ユーザデータ領域、の４種類の領域を含む。

上記（α）の管理領域の保存場所を示す領域には、ファイル管理領域とディレクトリデータ領域の場所が記録されている。このデータは、ファイルシステムが管理するデータにアクセスするための起点となるデータである。管理領域の保存場所を示す領域は、ＬＢＡの先頭アドレスによって示される。外部装置７がファイルシステムにアクセスする際、まずＬＢＡの先頭アドレスにアクセスし、管理領域の保存場所を参照して、ファイル管理領域とディレクトリデータ領域の場所を取得する。

上記（β）のファイル管理領域は、ファイルの性質を記した管理データ（ファイル管理データ）を記録する領域である。ファイルの本体は後述するユーザデータ領域に保存されるが、そのファイルの性質を示すデータはファイル管理領域に保存される。ファイルの性質として、ファイルタイプ、ファイルサイズ、データの保存場所の３つを記録する。ファイルタイプは、通常のファイルかディレクトリかを示すフラグである。データの保存場所は、ファイルの本体がユーザデータ領域のどこに保存されているかを示す。外部装置７がファイルにアクセスする場合、ファイル管理データを参照し、ファイル本体の保存場所を取得し、該当する場所にアクセスする。ファイル管理データはファイル毎に作られ、区別するために固有の番号が割り当てられる。なお、ファイルの性質は上記３つに限定されるものではなく、ファイル参照時刻やファイル更新時刻などその他の情報が含まれる場合もある。

上記（γ）のディレクトリデータ管理領域は、ディレクトリ内に存在するファイル名をすべて記録するディレクトデータを記録する領域である。ディレクトリデータは、ファイル名から対象ファイルのファイル管理データにアクセスできるように、ファイル名とファイル管理データの番号の表を記録する。例えば、外部装置７がファイルＡにアクセスする場合、ファイルＡが存在するディレクトリを参照し、そこに記録された表からファイルＡに対応づけられたファイル管理データの番号を取得する。そして、取得した番号に対応するファイル管理データを参照し、ファイル本体の保存場所を取得し、ファイルにアクセスする。

上記（δ）のユーザデータ領域は、ファイル本体を記録するデータ領域である。ユーザデータ領域のどこにファイル本体が記録されているかはファイル管理データに記されている。

なお、管理データ領域は上記（α）〜（δ）の４種類に限定されるものではなく、その他に空きデータ管理領域などがあってもよい。空きデータ管理領域は、データ蓄積部１８０の空き領域を管理する。この空きデータ管理領域を参照することで、外部装置７がデータ蓄積部１８０の使用率を知ることができる。

ファイルシステム管理部１３３は、外部装置７が上記ファイルシステムに基づく手順でデータ蓄積部１８０に格納されたデータにアクセスできるように、ファイル管理情報を生成し、データに対応づけて、ファイルシステムの管理情報を更新する。ファイルシステム管理部１３３がファイルシステムの管理情報を更新する手順は、次のようになる。

データアクセス処理部１１６は、格納対象のデータを受け取ると、ファイルシステム管理部１３３を通じてファイルシステム経由で、格納対象のデータをデータ蓄積部１８０に書き込む。その際、ファイルシステム管理部１３３は、書き込むデータをファイルとして扱うため、ファイル管理データを生成して管理データ領域に書き込む。このファイル管理データに対し、ファイルシステム管理部１３３は、ファイルタイプを通常のファイルと設定し、固有の番号を割り当てる。さらに、ファイルシステム管理部１３３は、ファイル管理データに対応するファイル名を生成する。このとき、ファイルシステム管理部１３３は、異なるファイルに同じ名称が使われないように、付与するファイル名に通し番号を設定したり、ランダムな文字などを設定したりしてもよい。

ファイルシステム管理部１３３は、生成したファイル名とファイル管理データの番号を、記録先のディレクトリデータの表に追加し、ディレクトリデータを更新する。更新元のディレクトリデータは、ファイルシステム管理部１３３がデータ蓄積部１８０のディレクトリデータ管理領域から読み出す。なお、ファイルシステム管理部１３３がデータ蓄積部１８０に記録されている内容と同じディレクトリデータをキャッシュしていてもよい。ファイルシステム管理部１３３は、生成したファイル管理データと更新したディレクトリデータを、データアクセス処理部１１６を介してデータ蓄積部１８０の管理データ領域に書き込む。

ファイル本体およびファイル管理データ、ディレクトリデータを書き込む処理は、具体的に次のような手順となる。データアクセス処理部１１６は、ファイル本体やファイル管理データ、ディレクトリデータを含むデータの書き込み先アドレス（ＬＢＡ）をＬＢＡ対応部１３１で物理アドレスに変換し、信頼性を高める情報などを付与して、データ蓄積部１８０に書き込む。

ファイルシステム管理部１３３がファイルシステムの管理情報を更新する別の手段として、データアクセス処理部１１６が物理アドレスでデータを書き込んだ後に、物理アドレスで書き込まれたデータにファイル管理データを対応づけてもよい。データアクセス処理部１１６は、ＬＢＡ対応部１３１が管理するＬＢＡと物理アドレスの変換テーブルを参照し、格納対象のデータの書き込み先情報（例えば、先頭物理アドレスとデータのサイズ）から物理アドレスに対応するＬＢＡを取得する。ファイルシステム管理部１３３は、データアクセス処理部１１６が取得したＬＢＡとデータのサイズを元にファイル管理データを作成する。

なお、ファイルシステム管理部１３３は、ファイル管理を分かりやすくするため、複数のディレクトリを作成し、ファイルを分類して記録してもよい。例えば、メッセージのＩＤ領域の値を名前にしたディレクトリを作成し、ディレクトリ名と一致するＩＤを持つメッセージのデータを該当するディレクトリの中に記録することで、外部装置７が記録データを参照した際に内容が分かりやすくなる。

以上のように、ファイルシステム管理部１３３が、ファイルシステムに基づいて格納対象のデータに管理データを付与することで、外部装置７は、データ蓄積部１８０に格納されたデータを、ファイルシステムに基づく手順で読み出すことができる。なお、ファイルシステム管理部１３３が使用するファイルシステムは、ＰＣ向けに広く使用されているＦＡＴ、ＦＡＴ３２、ＮＴＦＳ、ＥＸＴ３、ＥＸＴ４、ＸＦＳ、ＨＦＳ、ＨＦＳＸなどでもよいし、独自のファイルシステムでもよい。独自のファイルシステムを使用する場合は、外部装置７が独自のファイルシステムに対応しているものとする。

図２５は、本実施形態に係るデータ格納装置１００による処理手順の一例を示すフローチャートであり、ストレージＩ／Ｆ２００経由で外部装置７から読み出し指示を受け取り、データ蓄積部１８０からデータを読み出す処理動作の一例をまとめたものである。

データ格納装置１００は、ストレージＩ／Ｆ２００が接続するバスを介して、外部装置７からコマンドを受信する（ステップＳ１００１）。ストレージＩ／Ｆ２００は、受信したコマンドをデータアクセス処理部１１６に送る。データアクセス処理部１１６は、ストレージＩ／Ｆ２００から受け取ったコマンドが読み出し指示かそれ以外かをチェックする（ステップＳ１００２）。ここで、受け取ったコマンドが読み出し指示ではない場合（ステップＳ１００２：Ｎｏ）、データアクセス処理部１１６は、そのコマンドを無視するようにストレージＩ／Ｆ２００にアクセス制御を設定してもよい。一方、受け取ったコマンドが読み出し指示の場合（ステップＳ１００２：Ｙｅｓ）、データアクセス処理部１１６は、読み出し指示から読み出し範囲としてＬＢＡを取得し（ステップＳ１００３）、ＬＢＡ対応部１３１に渡す。

ＬＢＡ対応部１３１は、変換テーブルを参照し、データアクセス処理部１１６から受け取ったＬＢＡに対応する物理アドレスを取得し（ステップＳ１００４）、データ蓄積部１８０に対してデータを要求する。データ蓄積部１８０は、読み出し命令に従いデータを読み出し（ステップＳ１００５）、データアクセス処理部１１６に渡す。データアクセス処理部１１６は、データ蓄積部１８０から読み出したデータをストレージＩ／Ｆ２００に渡す。ストレージＩ／Ｆ２００は、データ蓄積部１８０から読み出したデータを外部装置７に送信する（ステップＳ１００６）。

以上説明した本実施形態の構成は、特にデータ蓄積部１８０に格納されたデータを扱いやすくする上で有用である。車載ネットワーク１に使われている通信プロトコルは低コストである反面、低速であるため、記録データを読み出そうとすると、そのサイズによっては膨大な時間がかかってしまう虞がある。また、車載ネットワーク１の通信インタフェースは、一般のＰＣで使用するには専用の変換器や専用ソフトウェアが必要となり、扱いやすいとはいえない。ストレージ製品に一般に使われている汎用インタフェースならば、記録データを短時間で読み出すことができる。例えば、ＣＡＮの伝送速度は最大１Ｍｂｐｓであるが、ストレージ製品向け汎用ＩＦのＳＡＴＡは最大６Ｇｂｐｓであり、６０００倍の速度差がある。また、汎用インタフェースは一般的なＰＣに接続することができ、ＬＢＡでアクセスできることから、専用ソフトウェアを使うことなくデータを読み出すことができる。データ格納装置１００に蓄積されたデータの解析に専用の装置を使わず一般のＰＣを利用することで、記録データの解析にかかるコストを削減することができる。

（変形例１）
以上説明した第６実施形態では、データ蓄積部１８０に格納されたデータを、ファイルシステムを経由してファイルとして読み出す構成としたが、オブジェクトデータを指定することでデータを読み出す構成としてもよい。オブジェクトデータ方式は、データ格納装置１００にデータを格納する際、データの格納場所を特定する情報（Ｖａｌｕｅ）に一意な識別子（Ｋｅｙ）を付与する。データ格納装置１００に格納されたデータを読み出す際、Ｋｅｙを指定することで対応するＶａｌｕｅからデータを読み出す。

図２６は、本変形例に係るデータ格納装置１００の機能的な構成例を示すブロック図である。図２３に示した第６実施形態の構成との違いは、オブジェクトデータ対応部１３４が追加されている点である。

オブジェクトデータ対応部１３４は、格納対象のデータに固有のＫｅｙを割り当て、そのデータの格納場所を特定する情報（Ｖａｌｕｅ）とＫｅｙの対応関係を管理する処理部である。オブジェクトデータ対応部１３４は、格納対象のデータを特定する情報（例えば、ファイル名など）をデータアクセス処理部１１６内で共有している。オブジェクトデータ対応部１３４は、データの格納場所を特定する情報の一例としてファイル名をＶａｌｕｅとし、固有のＫｅｙを生成して、Ｖａｌｕｅに割り当てる。オブジェクトデータ対応部１３４は、ＫｅｙとＶａｌｕｅとの対応関係を記録したテーブルを管理する。具体的には、例えば図２７に示すようなＫｅｙとＶａｌｕｅの対応テーブルを持つ。

オブジェクトデータ対応部１３４は、ＫｅｙがＶａｌｕｅに固有の値になるように、Ｋｅｙに通し番号を割り当てる。なお、同じ値のない乱数をＫｅｙに割り当ててもよい。Ｖａｌｕｅには、記録データに対応するファイル名が記録されている。オブジェクトデータ対応部１３４は、データをデータ蓄積部１８０に書き込むたびにＫｅｙとＶａｌｕｅの対応関係を対応テーブルに追加していく。

オブジェクトデータ対応部１３４は、ＫｅｙとＶａｌｕｅとの対応関係を記録した対応テーブルを外部装置７からの要求に応じて渡すことができる。この場合、外部装置７は、データ蓄積部１８０からデータを読み出す際に、オブジェクトデータ対応部１３４から受け取ったテーブルに基づきＫｅｙを指定するだけで、該当するデータを読み出すことができる。

なお、ＫｅｙとＶａｌｕｅの対応関係を記録する対応テーブルは、例えば図２８に示すように、通し番号や重複のない乱数にデータの分類を示す数値を付与することで、ＫｅｙからＶａｌｕｅの属性が分かるように記録する構成としてもよい。例えば、通し番号や重複のない乱数にメッセージＩＤとメッセージ種別を設定する。ここで、メッセージ種別とは、メッセージが制御データかレスポンスメッセージか、異常状態の情報を含むレスポンスメッセージかといったメッセージの内容の分類のことを示す。

この場合、オブジェクトデータ対応部１３４は、メッセージＩＤとメッセージの種別をデータ転送部１１３から受け取り、通し番号や重複のない乱数に追加してＫｅｙとして設定する。外部装置７は、付与する情報をあらかじめ共有しておくことで、オブジェクトデータ対応部１３４から受け取った対応テーブルを参照して、Ｖａｌｕｅの属性を知ることができる。なお、Ｋｅｙに付与するＶａｌｕｅの属性はいくつでもよく、２つに限定しない。また、ＫｅｙにはメッセージＩＤとメッセージ種別以外の属性を設定してもよく、例えば、時刻情報やタイムスタンプといったメッセージの記録タイミングなどをＫｅｙに付与してもよい。

本変形例では、外部装置７がデータを読み出す場合に、読み出し指示にＫｅｙを指定する。外部装置７がＫｅｙを指定してデータ格納装置１００からデータを読み出す手順の一例を示す。まず、外部装置７が、読み出したいデータのＫｅｙを読み出し指示に指定し、この読み出し指示を、ストレージＩ／Ｆ２００を介してデータ格納装置１００に送信する。読み出し指示を受け取ったデータ格納装置１００のデータアクセス処理部１１６は、読み出し指示からＫｅｙを取得し、オブジェクトデータ対応部１３４が持つ管理テーブルを参照し、取得したＫｅｙに対応するＶａｌｕｅ（ファイル名）を取得する。そして、データアクセス処理部１１６は、取得したファイル名のファイル管理データを参照し、ファイルの書き込み先情報を取得する。そして、データアクセス処理部１１６は、この書き込み先情報を読み出し命令に変換して、データ蓄積部１８０に渡す。データ蓄積部１８０は、データアクセス処理部１１６からの読み出し命令に従ってデータを読み出し、データアクセス処理部１１６に渡す。データアクセス処理部１１６は、データ蓄積部１８０から読み出されたデータをストレージＩ／Ｆ２００に渡し、外部装置７に送信する。

以上説明した本変形例の構成は、外部装置７がデータ蓄積部１８０に構築されたファイルシステムにアクセスすることなく、Ｋｅｙをデータ格納装置１００に送信するという単純な処理だけで、データ蓄積部１８０に格納されたデータを読み出すことができるという点で有用である。例えば、ファイルシステムを経由してデータを読み出す場合、外部装置７はファイル名を送信してデータ蓄積部１８０に記録されたファイル管理データを読み出し、ファイル管理データからファイルが記録されている場所を受け取り、その場所を指定してファイル本体を読み出すといった手順が必要である。一方、記録データをオブジェクトデータとして扱うことで、読み出し指示にＫｅｙを指定するだけで、記録データを出力するまでデータ格納装置１００が処理してくれる。外部装置７がストレージＩ／Ｆ２００を経由してデータ蓄積部１８０にアクセスする場合に限らず、例えば、外部ネットワーク経由でデータ蓄積部１８０にアクセスする場合も、Ｋｅｙを送信するだけでデータ格納装置１００は読み出すデータを一意に特定することができる。そのため、外部装置７がデータ蓄積部１８０からデータを読み出す処理を単純にできる。

（変形例２）
以上説明した第６実施形態では、データ蓄積部１８０に格納されたデータを読み出す外部装置７を特に限定していなかったが、データを読み出す外部装置７を限定するため、認証を通過した外部装置７のみ、データ蓄積部１８０に格納されたデータを読み出せるようにしてもよい。

図２９は、本変形例に係るデータ格納装置１００の機能的な構成例を示すブロック図である。図２３に示した第６実施形態の構成との違いは、外部装置認証部１３５が追加されている点である。

外部装置認証部１３５は、データ蓄積部１８０からデータを読み出す外部装置７を限定するため、データを読み出す権限を持つ外部装置７かどうかを確認する。データを読み出す権限を持つ外部装置７かどうかを確認する方法として、例えば、権限を持つ外部装置７しか知りえない情報を確認する方法を用いる。具体的には、パスワード認証でもよいし、ＭＡＣや署名を使用した認証をしてもよい。認証にＭＡＣや署名を使用する場合、鍵管理部１１５で管理している鍵を使用してもよい。

データアクセス処理部１１６は、外部装置認証部１３５による認証に成功した外部装置７、つまり、データを読み出す権限を持つことが確認された外部装置７からのデータ読み出し指示のみを受け付ける。すなわち、外部装置認証部１３５による認証に成功した外部装置７のみが、読み出しコマンドを送信し、データ蓄積部１８０からデータを読み出すことができる。

以上説明した本変形例の構成は、特にデータ蓄積部１８０に蓄積されたデータからプライバシ情報やノウハウ情報が盗み出されることを防ぐ場合に有効である。データ格納装置１００は、車両Ｖの走行中に車載ネットワーク１を流れるデータを大量に取得してデータ蓄積部１８０に格納するため、データ蓄積部１８０に蓄積されたデータを詳細に解析すれば、車両Ｖの運転手のプライバシ情報を取得することができてしまう可能性がある。そこで、上述した本変形例の構成により、データ蓄積部１８０にアクセス可能な外部装置７を制限することで、意図しない情報流出を防止することができる。

以上述べた少なくとも１つの実施形態によれば、従来のホストに相当する機能を内蔵し、自発的にデータを取得して蓄積することが可能なデータ格納装置を提供することができる。

以上、本発明の実施形態を説明したが、この実施形態は例として提示したものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１ 車載ネットワーク
５ ネットワークバス
１００ データ格納装置
１１０ プロセッサ
１１２ メッセージ処理部
１１４ 署名生成部
１１６ データアクセス処理部
１１８ 未署名データ管理部
１１９ データ監視部
１２０ ルール管理部
１２１ 物理Ｉ／Ｆ挿抜検出部
１２２ 車種特定部
１２３ 更新データ処理部
１２４ 署名検証部
１２５ データ監視部
１２６ データ格納処理部
１２７ データ相関判定部
１２８ 動作情報収集部
１３１ ＬＢＡ対応部
１３４ オブジェクトデータ対応部
１３５ 外部装置認証部
１６０ バスＩ／Ｆ
１８０ データ蓄積部
１９０ 基板
２００ ストレージＩ／Ｆ

Claims (15)

1. 車載ネットワークに接続されるデータ格納装置であって、
   ＮＡＮＤインタフェースを備えたデータ蓄積部と、
   前記データ蓄積部と同一基板上に搭載され、前記車載ネットワークのバスに接続されるバスインタフェースと、
   前記データ蓄積部および前記バスインタフェースと同一基板上に搭載され、前記バスインタフェースを介して前記車載ネットワークから自発的にデータを取得して前記データ蓄積部に格納するように、前記データ格納装置の動作を制御するプロセッサと、を備え、
   前記プロセッサは、
   前記バスインタフェースを介して、前記車載ネットワークに接続された電子制御ユニットまたは外部装置とメッセージを送受信するメッセージ処理部と、
   前記データ蓄積部に対しデータの書き込みおよび読み出しを指示するデータアクセス処理部と、を有し、
   前記メッセージ処理部により受信されたメッセージに含まれるデータが、前記データアクセス処理部の指示に応じて前記データ蓄積部に書き込まれる
   データ格納装置。
2. 前記プロセッサは、
   前記データ蓄積部に書き込むデータまたは前記データ蓄積部から読み出したデータに付与する署名を生成する署名生成部を有する
   請求項１に記載のデータ格納装置。
3. 前記プロセッサは、
   前記データ蓄積部に書き込まれた未署名データを管理する未署名データ管理部をさらに有し、
   前記署名生成部は、前記プロセッサの使用率が閾値以下のときに、前記未署名データに付与する署名を生成する
   請求項２に記載のデータ格納装置。
4. 前記データ蓄積部、前記バスインタフェースおよび前記プロセッサと同一基板上に搭載され、前記バスインタフェースよりも高速通信が可能で、論理ブロックアドレスを用いて前記データ蓄積部にアクセス可能なストレージインタフェースをさらに備え、
   前記プロセッサは、
   論理ブロックアドレスと物理アドレスの対応付けを行うＬＢＡ対応部をさらに有し、
   前記データアクセス処理部は、前記ストレージインタフェースを介して外部装置から論理ブロックアドレスを指定した読み出し指示があった場合に、指定された論理ブロックアドレスに対応する物理アドレスを指定して、前記データ蓄積部に対してデータの読み出しを指示する
   請求項１乃至３のいずれか一項に記載のデータ格納装置。
5. 前記プロセッサは、
   前記データ蓄積部のフォーマットを行い、前記データ蓄積部に論理ブロックアドレスでアクセスできるように前記データアクセス処理部の管理データを作成するファイルシステム生成部と、
   前記データ蓄積部に書き込まれるデータをファイルとして管理するためのファイル管理情報を作成し保持するファイルシステム管理部と、をさらに有する
   請求項４に記載のデータ格納装置。
6. 前記データアクセス処理部は、前記ストレージインタフェースから前記データ蓄積部へのデータ書き込みを禁止し、読み出しを許可する
   請求項４または５に記載のデータ格納装置。
7. 前記データ蓄積部、前記バスインタフェースおよび前記プロセッサと同一基板上に搭載され、前記バスインタフェースよりも高速通信が可能なストレージインタフェースをさらに備え、
   前記プロセッサは、
   前記データ蓄積部に格納されたデータをオブジェクト単位で管理してＫｅｙとＶａｌｕｅの対応関係を保持するオブジェクトデータ対応部をさらに有し、
   前記データアクセス処理部は、前記ストレージインタフェースを介して外部装置からＫｅｙを指定した読み出し指示があった場合に、Ｋｅｙに対応するＶａｌｕｅに対応するデータの読み出しを前記データ蓄積部に対して指示する
   請求項１乃至３のいずれか一項に記載のデータ格納装置。
8. 前記プロセッサは、
   前記外部装置を認証する外部装置認証部をさらに有し、
   前記データアクセス処理部は、前記外部装置の認証に成功した場合に、前記外部装置からの読み出し指示を受け付ける
   請求項４乃至７のいずれか一項に記載のデータ格納装置。
9. 前記プロセッサは、
   ソフトウェア実行中のメモリの内容をダンプする動作情報収集部を有し、
   前記データ蓄積部は、前記動作情報収集部によるメモリダンプをさらに蓄積する
   請求項１乃至８のいずれか一項に記載のデータ格納装置。
10. 前記プロセッサは、
    前記データ蓄積部に格納するデータの重要度を判定する第１データ監視部と、
    前記データ蓄積部に格納するデータの重要度に応じて、誤り訂正符号の付与、書き込み回数が少ないブロックへの書き込み、および同一データの複数ブロックへの書き込みの少なくとも１つを制御するデータ格納処理部と、を有する
    請求項１乃至９のいずれか一項に記載のデータ格納装置。
11. 前記プロセッサは、
    前記データ蓄積部に格納する複数のデータに相関がある場合に、これら複数のデータを１つにまとめるデータ相関判定部をさらに有し、
    前記第１データ監視部は、前記データ相関判定部により１つにまとめられたデータの重要度を判定し、
    前記データ格納処理部は、前記データ相関判定部により１つにまとめられたデータの重要度に応じて、誤り訂正符号の付与、書き込み回数が少ないブロックへの書き込み、および同一データの複数ブロックへの書き込みの少なくとも１つを制御する
    請求項１０に記載のデータ格納装置。
12. 前記メッセージ処理部は、前記車載ネットワークに接続された電子制御ユニットに対しデータを要求するリクエストメッセージを送信して、該リクエストメッセージにより要求したデータを含むレスポンスメッセージを受信し、
    前記データアクセス処理部は、前記メッセージ処理部が受信したレスポンスメッセージに含まれるデータを前記データ蓄積部に書き込むように指示する
    請求項１乃至１１のいずれか一項に記載のデータ格納装置。
13. 前記プロセッサは、
    前記車載ネットワークから取得したデータを解析し、異常の有無を検査する第２データ監視部と、
    発生した異常状態と、異常状態の原因を特定するために必要なデータを取得するためのルールとの対応関係を保持し、前記第２データ監視部が異常を検出した場合に、検出された異常に対応する前記ルールを設定するルール管理部と、をさらに有し、
    設定された前記ルールに従って前記車載ネットワークからデータを取得する
    請求項１乃至１２のいずれか一項に記載のデータ格納装置。
14. 前記プロセッサは、
    外部から前記ルールの更新データを取得し、前記ルールを更新する更新データ処理部をさらに有する
    請求項１３に記載のデータ格納装置。
15. 前記プロセッサは、
    署名が付与された前記更新データの署名を検証する署名検証部をさらに有し、
    前記更新データ処理部は、署名の検証に成功した場合に前記ルールを更新する
    請求項１４に記載のデータ格納装置。

Images