(57)【要約】      （修正有）【課題】イベントの記録に要する記憶領域を削減することができる車載電子制御装置およびログ格納方法を提供する。【解決手段】車載電子制御装置１００は、発生したイベントのログが記録されるログ領域１２２と、正常時のイベントの発生順序である正常順序および正常順序に対応する文字列を含むパターン情報１１２Ａが格納される記憶部１１２と、正常順序に代えて文字列をログ領域に記録することでログを圧縮する圧縮部とを備える。【選択図】図２
2018109900.tif 000002
【特許請求の範囲】
【請求項１】
発生したイベントのログが記録されるログ領域と、
正常時の前記イベントの発生順序である正常順序、および前記正常順序に対応する文字列を含むパターン情報が格納される記憶部と、
前記正常順序に代えて前記文字列を前記ログ領域に記録することで前記ログを圧縮する圧縮部とを備える車載電子制御装置。
【請求項２】
請求項１に記載の車載電子制御装置において、
前記圧縮部は、前記イベントの発生順序が前記正常順序に合致しない場合は、前記ログの圧縮を行わずに前記イベントを前記ログ領域に記録する車載電子制御装置。
【請求項３】
請求項１に記載の車載電子制御装置において、
異常の発生を報知する報知部をさらに備え、
前記圧縮部は、前記イベントの発生順序が前記正常順序と完全に一致せず途中まで一致する場合は前記報知部を用いて異常の発生を報知する車載電子制御装置。
【請求項４】
請求項１に記載の車載電子制御装置において、
前記圧縮部は、前記イベントが発生するたびに発生した前記イベントの順序と前記正常順序との一致判断を行い、前記正常順序と途中まで一致すると判断すると、一致する範囲を一時的に記憶する車載電子制御装置。
【請求項５】
請求項４に記載の車載電子制御装置において、
前記正常順序はツリー構造のデータベースとして格納され、
前記圧縮部は、前記イベントが発生するたびに前記ツリー構造のデータベースをシーケンシャルに検索する車載電子制御装置。
【請求項６】
請求項１に記載の車載電子制御装置において、
前記パターン情報には、前記パターン情報に含まれる連続する２つのイベントについてあらかじめ想定された発生時刻の差である想定時刻差が含まれ、
前記圧縮部は、前記２つのイベントの現実の発生時刻の差である現実時刻差を算出し、前記現実時刻差と前記想定時刻差との差を前記ログ領域にさらに記録する車載電子制御装置。
【請求項７】
請求項１に記載の車載電子制御装置において、
異常の発生を報知する報知部をさらに備え、
前記記憶部には、特定の異常時における前記イベントの発生順序である異常順序、および前記異常順序に対応する異常文字列を含む異常パターン情報がさらに格納され、
前記圧縮部は、前記イベントの発生順序が前記異常順序に合致する場合は、前記異常順序に代えて前記異常文字列を前記ログ領域に記録するとともに、前記報知部を用いて異常の発生を報知する車載電子制御装置。
【請求項８】
発生したイベントのログが記録されるログ領域と、正常時の前記イベントの発生順序である正常順序および前記正常順序に対応する文字列を含むパターン情報が格納される記憶部と、を備える車載電子制御装置において実行されるログ格納方法であって、
前記車載電子制御装置が前記正常順序に代えて前記文字列を前記ログ領域に記録することでログを圧縮するログ格納方法。
【請求項９】
請求項８に記載のログ格納方法において、
前記イベントの発生順序が前記正常順序に合致しない場合は、前記車載電子制御装置が前記ログの圧縮を行わずに前記イベントを前記ログ領域に記録するログ格納方法。
【請求項１０】
請求項８に記載のログ格納方法において、
前記イベントの発生順序が前記正常順序と完全に一致せず途中まで一致する場合は前記車載電子制御装置が異常の発生を報知するログ格納方法。
【請求項１１】
請求項８に記載のログ格納方法において、
前記イベントが発生するたびに前記車載電子制御装置が発生した前記イベントの順序と前記正常順序との一致判断を行い、前記正常順序と途中まで一致すると判断すると、前記車載電子制御装置が一致する範囲を一時的に記憶するログ格納方法。
【請求項１２】
請求項１１に記載のログ格納方法において、
前記正常順序はツリー構造のデータベースとして格納され、
前記イベントが発生するたびに前記車載電子制御装置が前記ツリー構造のデータベースをシーケンシャルに検索するログ格納方法。
【請求項１３】
請求項８に記載のログ格納方法において、
前記パターン情報には、前記パターン情報に含まれる連続する２つのイベントについてあらかじめ想定された発生時刻の差である想定時刻差が含まれ、
前記車載電子制御装置が、前記２つのイベントの現実の発生時刻の差である現実時刻差を算出し、前記現実時刻差と前記想定時刻差との差を前記ログ領域にさらに記録するログ格納方法。
【請求項１４】
請求項８に記載のログ格納方法において、
前記記憶部には、特定の異常時における前記イベントの発生順序である異常順序、および前記異常順序に対応する異常文字列を含む異常パターン情報がさらに格納され、
前記イベントの発生順序が前記異常順序に合致する場合は、前記車載電子制御装置が、前記異常順序に代えて前記異常文字列を前記ログ領域に記録するとともに、異常の発生を報知するログ格納方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車載電子制御装置、およびログ格納方法に関する。
【背景技術】
【０００２】
近年の車両には多数の電子機器が搭載される。車両に発生する不具合の原因を究明するためには、それら電子機器の動作の記録であるログを解析することが肝要である。特許文献１には、車両運転中の操作状況及び車両状況の一方または双方を含む運転状況情報を取得する運転状況情報取得部と、車両主電源のＯＮからＯＦＦまでの期間において取得される前記運転状況情報の少なくとも一部のデータからなる車両運転ログを順次生成するログ生成部と、前記運転状況情報を用いて、前記ログ生成部で順次生成された車両運転ログが同一走行に属するものであるかどうかを判定するログ同一性判定部と、前記ログ同一性判定部による判定結果に基づいて前記車両運転ログを連結するログ加工部と、同一走行単位で仕分けられた前記車両運転ログを格納するログ格納部と、を備える車両運転ログ処理システムが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−１５２６８７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１に記載されている発明では、イベントの記録に要する記憶領域を削減することができない。
【課題を解決するための手段】
【０００５】
本発明の第１の態様による車載電子制御装置は、発生したイベントのログが記録されるログ領域と、正常時の前記イベントの発生順序である正常順序、および前記正常順序に対応する文字列を含むパターン情報が格納される記憶部と、前記正常順序に代えて前記文字列を前記ログ領域に記録することで前記ログを圧縮する圧縮部とを備える。
本発明の第２の態様によるログ格納方法は、発生したイベントのログが記録されるログ領域と、正常時の前記イベントの発生順序である正常順序および前記正常順序に対応する文字列を含むパターン情報が格納される記憶部と、を備える車載電子制御装置において実行されるログ格納方法であって、前記車載電子制御装置が前記正常順序に代えて前記文字列を前記ログ領域に記録することでログを圧縮する。
【発明の効果】
【０００６】
本発明によれば、イベントの記録に要する記憶領域を削減することができる。
【図面の簡単な説明】
【０００７】
【図１】ＥＣＵのハードウエア構成を示す図
【図２】第１の実施の形態におけるＥＣＵの機能構成を示す図
【図３】イベント情報の一例を示す図
【図４】第１の実施の形態におけるパターン情報の一例を示す図
【図５】一時バッファの一例を示す図
【図６】ログ領域の一例を示す図
【図７】第１の実施の形態におけるパターン認識部の動作例を示す図
【図８】第１の実施の形態におけるＥＣＵの動作を示すフローチャート
【図９】第１の実施の形態におけるＥＣＵの動作を示すフローチャート
【図１０】変形例１におけるパターン情報の一例を示す図
【図１１】変形例２においてツリー形式で記録される正常順序の一例を示す図
【図１２】第２の実施の形態におけるＥＣＵの機能構成を示す図
【図１３】第３の実施の形態におけるＥＣＵの機能構成を示す図
【図１４】時刻差バッファの一例を示す図
【図１５】第３の実施の形態におけるＥＣＵの動作を示すフローチャート
【図１６】第３の実施の形態におけるＥＣＵの動作を示すフローチャート
【図１７】第３の実施の形態における動作例を示す図
【発明を実施するための形態】
【０００８】
―第１の実施の形態―
以下、図１〜図９を参照して、車載電子制御装置であるＥＣＵの第１の実施の形態を説明する。本発明に係るＥＣＵは、車両に搭載される。以下では１台のＥＣＵについて説明するが、車両に搭載されるＥＣＵの数はこれに限定されない。
【０００９】
（ＥＣＵのハードウエア構成）
図１は、第１の実施の形態にかかるＥＣＵ１００のハードウエア構成を示す図である。ＥＣＵ１００は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、不揮発性メモリ１４とを備える。ＣＰＵ１１は、ＲＯＭ１２および不揮発性メモリ１４に格納されるプログラムをＲＡＭ１３に展開して実行する。ＲＯＭ１２には変更が不要なプログラム、およびプログラムが使用する定数、たとえばタイムアウトを規定する情報などが格納される。ＲＡＭ１３は揮発性メモリであり、プログラムの展開やプログラムが使用する一時的な情報の格納に使用される。不揮発性メモリ１４は電源供給が断たれても情報の記憶が継続される記憶領域であり、プログラムの動作ログや更新される可能性があるプログラム、たとえばオペレーティングシステム（ＯＳ）などが格納される。
【００１０】
（ＥＣＵの機能構成）
図２は、ＥＣＵ１００の機能構成を示す図である。ＥＣＵ１００は、時刻レジスタ１１１と、パターン認識部１１２と、イベント情報１１３と、一時バッファ１２１と、ログ領域１２２と、スナップショット領域１２３とを備える。
【００１１】
時刻レジスタ１１１は、ＣＰＵ１１に内蔵される特定のレジスタである。時刻レジスタ１１１には現在時刻を示す情報、たとえば「２０１６年１月２日３時４５分６．７８９０１２３４５６秒」が格納される。時刻レジスタ１１１に格納される値は、ＣＰＵ１１に内蔵される発振子の動作に基づき更新されており、ＣＰＵ１１が実行するプログラムは時刻レジスタ１１１を参照することで現在時刻を取得できる。
【００１２】
パターン認識部１１２は、イベントの発生の順番を認識して予め定められたパターンと一致するか否かを判断し、予め定められたパターンと一致すると判断すると該当するパターンに対応する識別子（以下、「パターン識別子」と呼ぶ）を提供する。この予め定められたパターンおよび各パターンに対応する識別子は、パターン情報１１２ＡとしてＲＯＭ１２または不揮発性メモリ１４に保存される。パターン情報１１２Ａには、パターンに含まれる各イベントについて、直前のイベント発生から当該イベントが発生するまでの想定される時間間隔も保存される。パターン情報１１２Ａの一例は後述する。本実施の形態では、パターン情報１１２Ａに保存されるイベントのパターンは全て、想定される正常なイベントの順序（以下、「正常順序」と呼ぶ）である。さらにパターン認識部１１２は、不図示の報知部を備え、異常を検出すると報知部を用いて異常の発生を報知する。この報知部は、ＥＣＵ１００に接続される他の機器と通信を行い異常を報知してもよいし、ＲＡＭ１３や不揮発性メモリ１４に異常の発生を記録することにより異常を報知してもよい。
【００１３】
イベント情報１１３には、複数のイベントについて、イベントの識別子であるイベントＩＤとそのイベントの識別情報とが関連付けて保存される。イベント情報１１３は、不揮発性メモリ１４に確保される記憶領域である。イベント情報１１３の一例は後述する。
【００１４】
一時バッファ１２１は、イベントの識別情報とイベントの発生時刻が一時的に記録される領域である。ただしイベントの識別情報に代えてイベントＩＤが記録されてもよい。一時バッファ１２１はＲＡＭ１３に確保された領域である。詳しくは後述するが、一時バッファ１２１に記録されるイベントはパターン情報１１２Ａに記載されたいずれかのパターンと一致する可能性があるイベントである。一時バッファ１２１に記録されたイベントの情報は、そのまま、または置換されてログ領域１２２に記録される。そしてイベントの情報がログ領域１２２に記録されると、一時バッファ１２１に記録されていたそのイベントの情報は消去される。一時バッファ１２１の一例は後述する。
【００１５】
ログ領域１２２は、イベントの識別情報とイベントの発生時刻が記録される領域である。ただしイベントの識別情報に代えてイベントＩＤやパターン識別子が記録されてもよい。ログ領域１２２は不揮発性メモリ１４に確保された領域である。ログ領域１２２に記録されたイベントの情報は、不図示のインタフェースを介してＥＣＵ１００の外部に読みだされる。ログ領域１２２の一例は後述する。
【００１６】
スナップショット領域１２３は、ＥＣＵ１００の異常が検知された際のＥＣＵ１００の動作状態が記録される領域である。記録されるＥＣＵ１００の動作状態には、ログ領域１２２に記録される情報が含まれる。
【００１７】
（イベント情報）
図３は、イベント情報１１３の一例を示す図である。イベント情報１１３はたとえば複数のレコードから構成され、各レコードはイベントの識別子であるイベントＩＤが格納されるフィールドとイベント識別情報が格納されるフィールドとを有する。イベント情報１１３のレコード数、すなわちイベント情報１１３に記録されるイベントの数に制限はない。イベントＩＤはたとえば１文字のアルファベットであり、本実施の形態では６つのイベントに、Ａ，Ｂ，Ｃ，Ｘ，Ｙ，Ｚを割り当てる。イベント識別情報は、イベントを識別する様々な情報である。換言すると本実施の形態における「イベント」とは、イベント情報１１３を用いて識別される事象である。
【００１８】
イベント識別情報の構成は限定されないが、たとえばイベントの種別を表すイベントプロパティとパラメータ値を表すイベントパラメータの組み合わせでもよい。イベントプロパティはたとえば、ＣＡＮフレームの受信、プログラム中の変数の特定値への一致などである。イベントパラメータはたとえば、イベントプロパティがＣＡＮフレームの受信である場合に、ＣＡＮＩＤの値とデータフィールドに格納される値の組み合わせである。なお以下の説明では、イベントＩＤがＡのイベントを、イベントＡなどとも呼ぶ。ＣＰＵ１１は、ＣＰＵ１１の内部の情報、およびＲＡＭ１３や不揮発性メモリ１４に格納された情報にアクセスできるので、イベントの発生時にイベント識別情報を取得できる。
【００１９】
（パターン情報）
図４は、パターン情報１１２Ａの一例を示す図である。パターン情報１１２Ａはたとえば複数のレコードから構成され、各レコードはあらかじめ定められたイベントの発生順番およびイベントの発生する時間間隔である置換前情報が格納されるフィールドと、イベントのパターンに対応する識別子である置換後情報が格納されるフィールドとを有する。パターン情報１１２Ａのレコード数および各レコードにおけるパターンを構成するイベント数に制限はない。
【００２０】
図４に示すように、置換前情報のフィールドには、発生する順番に第１イベント〜第４イベント、および各イベントについて想定される発生の時間間隔が含まれる。パターン情報１１２Ａでは、イベントを識別する情報としてイベント識別情報を用いてもよいが、ここではイベントＩＤを用いる。たとえば１つ目の例では、想定されるイベントの発生順番は、Ａ，Ｘ，Ｙ，Ｂであり、２つ目の例では、Ａ，Ｘ，Ｃである。そして図４では「想定間隔」のフィールドに各イベントについて想定される発生の時間間隔が記録される。このフィールドに記載される時間の単位は、たとえばナノ秒やマイクロ秒である。
【００２１】
たとえば１つ目の例において、第１イベントのＡと第２イベントのＸの間に記載された「５００」は、イベントＡが発生してからイベントＸが発生するまでの想定される時間間隔が「５００」であることを示している。同様に、イベントＸが発生してからイベントＹが発生するまでの想定される時間間隔は「２０００」であり、イベントＹが発生してからイベントＢが発生するまでの想定される時間間隔は「３００」であることが示されている。置換後情報のフィールドには、同一レコードの置換前情報に合致するイベントのパターンに合致するパターン識別子として、１つ目の例ではＰが、２つ目の例ではＱが記載される。置換処理の詳細は後述する。
【００２２】
（一時バッファ）
図５は、一時バッファ１２１一例を示す図である。一時バッファ１２１はたとえば複数のレコードから構成され、各レコードにはイベントの識別情報、およびイベントが発生した時刻を示すタイムスタンプが格納される。
【００２３】
（ログ領域）
図６は、ログ領域１２２の一例を示す図である。ログ領域１２２はたとえば複数のレコードから構成され、各レコードにはイベントの識別情報、およびイベントが発生した時刻を示すタイムスタンプが格納される。ただしイベント識別情報の代わりにイベントＩＤが格納されてもよいし、パターン情報１１２Ａに含まれるパターン識別子が格納されてもよい。
【００２４】
（パターン認識部の動作）
パターン認識部１１２の動作、および動作例を説明する。パターン認識部１１２は、一時バッファ１２１に格納されたイベントの順番が、パターン情報１１２Ａに格納されたいずれかのイベントのパターンと一致すると、以下の置換処理を行う。すなわち、それらのイベントＩＤを対応するパターン識別子に置き換えるとともに、パターンの最後のイベントが発生した時刻を、そのパターン識別子のイベントが発生した時刻とする。またパターン認識部１１２は、一時バッファ１２１に格納されたイベントの順番が、パターン情報１１２Ａに格納されたいずれのイベントのパターンとも一致しないが、いずれかのイベントのパターンと途中まで一致する場合には、置換を行わずに報知部を用いて異常の発生を報知する。さらにパターン認識部１１２は、一時バッファ１２１に格納されたイベントの順番がパターン情報１１２Ａに格納されたいずれのイベントのパターンともまったく一致しない場合、すなわち一時バッファ１２１に格納された先頭のイベントがパターン情報１１２Ａに格納されたいずれのパターンの先頭のイベントとも一致しない場合は、置換および報知のいずれも行わない。
【００２５】
図７は、ケース１〜ケース３の３つのケースにおけるパターン認識部１１２の動作例を示す図である。図７は、各ケースについて、イベント発生状況と全イベント発生後のログ領域１２２に格納される情報を示している。イベント発生状況の欄には、イベントの発生した順番でイベントＩＤが記載され、そのイベントの発生が観測された時刻も併記される。なお、いずれのケースも最初のイベントが発生する際には、一時バッファ１２１には何も記録されていないこととする。また、いずれのケースも最初のイベントが観測された時刻をゼロとする。
【００２６】
ケース１では、発生したイベントの順番をイベントＩＤで表すと、「Ａ，Ｘ，Ｙ，Ｂ，Ｃ」である。先頭から４つのイベントがパターン情報１１２Ａにおける１つ目のパターンに合致するので、これら４つのイベントの代わりにパターン識別子Ｐがログ領域１２２に記録される。そしてタイムスタンプはこのパターンの最後のイベントであるイベントＢが観測された時刻である「２６９０」が記録される。５つ目のイベントＣは、パターン情報１１２Ａのいずれのパターンとも合致しないので、イベントＩＤおよび観測時刻がそのまま記録される。
【００２７】
ケース２では、発生したイベントの順番をイベントＩＤで表すと、「Ａ，Ｘ，Ｚ」である。このイベントのパターンは、パターン情報１１２Ａのいずれのパターンとも合致しないが、１つ目のパターンと途中までは一致する。具体的には、発生した先頭の２つのイベント「Ａ，Ｘ」は、パターン情報１１２Ａの１つ目のパターンである「Ａ，Ｘ，Ｙ，Ｂ」の先頭の２つと一致する。そのため、全体が一致しないので置換は行われないが、部分的に一致するので異常が報知される。ログ領域１２２には、発生したイベントのイベントＩＤ、および観測時刻がそのまま記載される。
【００２８】
ケース３では、イベントＣのみが発生した。パターン情報１１２Ａには、イベントＣから始まるパターンが存在しないので、パターン認識部１１２は置換を行わない。そのためログ領域１２２には、発生したイベントであるイベントＣ、およびイベントＣの観測時刻がそのまま記載される。
【００２９】
（フローチャート）
図８および図９は、第１の実施の形態におけるＥＣＵ１００の動作を示すフローチャートである。ＣＰＵ１１は、ＥＣＵ１００において何らかのイベントが発生するたびに図８および図９により動作が表されるプログラムを実行する。以下に説明するフローチャートの各ステップの実行主体は、ＥＣＵ１００のＣＰＵ１１である。
ステップＳ３０２では、ＣＰＵ１１は、発生したイベントを実行する。続くステップＳ３０４では、ＣＰＵ１１は時刻レジスタ１１１から現在時刻を示す情報、すなわちタイムスタンプを取得する。なお以下では、このタイムスタンプにより表される時刻を、「イベントの発生時刻」や「イベントが観測された時刻」とも呼ぶ。続くステップＳ３０６において、ＣＰＵ１１はイベント情報１１３および発生したイベントのイベント識別情報に基づき、発生したイベントのイベントＩＤを特定する。
【００３０】
続くステップＳ３０８では、ＣＰＵ１１は、一時バッファ１２１に格納されたイベントＩＤにステップＳ３０６において特定したイベントＩＤを付加したイベントのパターンが、パターン認識部１１２のいずれかのパターンと前方一致するか否かを判断する。たとえば一時バッファ１２１に「Ａ，Ｘ」が格納され、ステップＳ３０６において特定したイベントＩＤが「Ｙ」の場合には以下のように判断される。すなわち、「Ａ，Ｘ」に「Ｙ」を付加した「Ａ，Ｘ，Ｙ」は、パターン認識部１１２の１つ目のパターンである「Ａ，Ｘ，Ｙ，Ｂ」の先頭の３つと一致するので前方一致検索を肯定判断する。ＣＰＵ１１は、肯定判断する場合はステップＳ３１０に進み、否定判断する場合はステップＳ３１４に進む。なお、一時バッファ１２１になにも記録されていない場合は、ステップＳ３０６において特定したイベントＩＤのみを用いた前方一致検索、すなわちステップＳ３０６において特定したイベントＩＤを先頭となるパターンが存在するか否かの判断を行う。
【００３１】
ステップＳ３１０では、ＣＰＵ１１はタイムアウトの有無を判断する。すなわち、直前に発生したイベントの発生時刻と今回のイベントの発生時刻との差が、所定の時間よりも長いか否かを判断する。このタイムアウトの時間は、ＲＯＭ１２に格納されていてもよいし、全てのイベントについて同一でもよいし、イベントごとに異なる値が設定されてもよい。ただし本実施の形態では、このタイムアウトの時間とパターン認識部１１２の想定間隔とは相関がないものとする。ＣＰＵ１１は、タイムアウトが発生していない、すなわち直前に発生したイベントの発生時刻と今回のイベントの発生時刻との差が所定の時間以内であったと判断する場合はステップＳ３１２に進み、タイムアウトが発生したと判断する場合はステップＳ３１４に進む。
【００３２】
ステップＳ３１２では、ＣＰＵ１１は最新のイベントＩＤとタイムスタンプ、すなわちステップＳ３０６において特定したイベントＩＤおよびステップＳ３０４において取得したタイムスタンプを一時バッファ１２１に保存して図８および図９により動作が表されるプログラムの実行を終了する。ステップＳ３０８またはステップＳ３１０において否定判定されると実行されるステップＳ３１４では、ＣＰＵ１１は一時バッファ１２１に何か記録されているか否かを判断する。ＣＰＵ１１は、なにも記録されていないと判断する場合はステップＳ３１６に進み、何らかの情報が記録されていると判断する場合は図９のステップＳ３３０に進む。ステップＳ３１６では、ＣＰＵ１１は最新のイベントＩＤとタイムスタンプ、すなわちステップＳ３０６において特定したイベントＩＤおよびステップＳ３０４において取得したタイムスタンプをログ領域１２２に保存して図８および図９により動作が表されるプログラムの実行を終了する。
【００３３】
図８のステップＳ３１４において否定判断されると、図９のステップＳ３３０が実行される。このステップＳ３３０では、ＣＰＵ１１は、一時バッファ１２１内のＩＤ列、すなわち一時バッファ１２１に格納されるイベントのパターンが、パターン情報１１２Ａに基づき置換可能か否かを判断する。置換可能と判断する場合はステップＳ３３２に進み、置換不可能と判断する場合はステップＳ３４０に進む。
【００３４】
ステップＳ３３２では、ＣＰＵ１１はステップＳ３３０において置換可能と判断された置換により得られるパターン識別子、および置換後のタイムスタンプをログ領域１２２に保存する。前述のとおり、置換後のタイムスタンプとは該当するパターンに含まれる最後のイベントが発生した時間に対応するタイムスタンプである。続くステップＳ３３４では、ＣＰＵ１１は一時バッファを一掃、すなわち一時バッファ１２１に保存された情報をすべて削除する。続くステップＳ３３５では、最新のイベントＩＤ、すなわちステップＳ３０６において特定したイベントＩＤがパターン情報１１２Ａに記載されたいずれかのパターンの先頭と一致するか否かを判断する。ＣＰＵ１１は、いずれかのパターンの先頭と一致すると判断する場合はステップＳ３３６に進み、いずれとも一致しないと判断する場合はステップＳ３３７に進む。ステップＳ３３６では、最新のイベントＩＤとタイムスタンプ、すなわちステップＳ３０６において特定したイベントＩＤおよびステップＳ３０４において取得したタイムスタンプを一時バッファ１２１に保存して図８および図９により動作が表されるプログラムの実行を終了する。ステップＳ３３７では、最新のイベントＩＤとタイムスタンプをログ領域１２２に保存して図８および図９により動作が表されるプログラムの実行を終了する。
【００３５】
ステップＳ３３０において否定判断されると実行されるステップＳ３４０では、ＣＰＵ１１は、一時バッファ１２１内の全ての情報をそのままログ領域１２２に記録し、一時バッファ１２１内の全ての情報を削除する。続くステップＳ３４２では、最新のイベントＩＤとタイムスタンプ、すなわちステップＳ３０６において特定したイベントＩＤおよびステップＳ３０４において取得したタイムスタンプをログ領域１２２に保存する。続くステップＳ３４４では、ＣＰＵ１１は不図示の報知部を用いて異常を報知する。続くステップＳ３４６では、ＣＰＵ１１は、ログ領域１２２に記録されている全ての情報をスナップショット領域１２３に記録して図８および図９により動作が表されるプログラムの実行を終了する。
【００３６】
（動作例）
図７に示した各ケースについて、図８〜図９に示したフローチャートにおいてＣＰＵ１１が行う判断を説明する。ただし以下では主にフローチャートの分岐における判断を説明し、分岐のない箇所の説明は省略する。なお前述のとおり、いずれのケースも最初のイベントが発生する際には、一時バッファ１２１には何も記録されていない。また、いずれのケースでも図８のステップＳ３１０における判断はタイムアウトの発生なし、すなわち肯定判断とする。
【００３７】
図７のケース１において、イベントＡが発生するとステップＳ３０８においてＣＰＵ１１は肯定判断を行い、ステップＳ３１２において一時バッファ１２１にイベントＡとそのタイムスタンプを記録する。イベントＸ，Ｙ，Ｂのいずれが発生した場合にも、イベントＡの場合と同様の判断がされる。なぜならば、「Ａ」、「Ａ，Ｘ」、「Ａ，Ｘ，Ｙ」および「Ａ，Ｘ，Ｙ，Ｂ」のいずれも、図４に示したパターン情報１１２Ａの１つ目のパターンである「Ａ，Ｘ，Ｙ，Ｂ」を対象とする前方一致検索で肯定判定されるからである。
【００３８】
最後にイベントＣが発生すると、ＣＰＵ１１はステップＳ３０８において、「Ａ，Ｘ，Ｙ，Ｂ，Ｃ」について「Ａ，Ｘ，Ｙ，Ｂ」を対象とする前方一致検索で否定判定する。そしてステップＳ３１４において一時バッファ１２１にイベント「Ａ，Ｘ，Ｙ，Ｂ」が記録されているので否定判定を行ってステップＳ３３０に進む。ステップＳ３３０ではＣＰＵ１１は、一時バッファ１２１に記録されたイベント「Ａ，Ｘ，Ｙ，Ｂ」が「Ｐ」で置換可能なので肯定判断を行いステップＳ３３２に進む。ステップＳ３３２ではパターン識別子ＰとイベントＢが発生した時刻を示すタイムスタンプをログ領域１２２に保存し、ステップＳ３３４において一時バッファ１２１内の情報を削除する。そしてステップＳ３３５では最新のイベントＣはパターン情報１１２Ａのいずれのパターンの先頭にも一致しないのでステップＳ３３７に進み、ステップＳ３３７においてイベントＣとそのタイムスタンプをログ領域１２２に記録する。
【００３９】
図７のケース２において、イベントＡとイベントＸが発生した際のＣＰＵ１１の動作はケース１と同様である。イベントＺが発生すると、「Ａ，Ｘ，Ｚ」はパターン認識部１１２のいずれのパターンとも一致しないのでＣＰＵ１１はステップＳ３０８において否定判断を行う。そしてステップＳ３１４では一時バッファ１２１に格納されている情報があるのでＣＰＵ１１は否定判断を行いステップＳ３３０に進む。ステップＳ３３０では一時バッファ１２１内の「Ａ，Ｘ」は置換が不可能なのでＣＰＵ１１は否定判断を行い、ステップＳ３４０以下でイベント「Ａ，Ｘ，Ｚ」およびそのタイムスタンプをログ領域１２２に記録する。
【００４０】
図７のケース３において、ＣＰＵ１１はステップＳ３０８を否定判断し、ステップＳ３１４を肯定判断し、ステップＳ３１６においてイベントＣおよびそのタイムスタンプをログ領域１２２に記録する。
【００４１】
上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）車載電子制御装置であるＥＣＵ１００は、発生したイベントのログが記録されるログ領域１２２と、正常時のイベントの発生順序である正常順序、および正常順序に対応する文字列であるパターン識別子を含むパターン情報１１２Ａが格納される不揮発性メモリ１４と、正常順序に代えてパターン識別子をログ領域１２２に記録することでログを圧縮する圧縮部、すなわちパターン認識部１１２とを備える。
【００４２】
正常順序で発生するイベントに関する情報は、障害発生の原因究明において重要度は必ずしも高くないが、正常順序で発生するイベントに関する情報が全く得られなければ原因究明が困難になる。ＥＣＵ１００は、正常順序および正常順序に対応する文字列を記憶するので正常順序を判断できる。さらにＥＣＵ１００は、正常順序そのものを記録する代わりにパターン識別子を記録することで、少ない記憶領域を用いて正常順序でイベントが発生したことを記録することができる。すなわちＥＣＵ１００は、イベントの記録に要する記憶領域を削減することができる。
【００４３】
（２）パターン認識部１１２は、イベントの発生順序が正常順序に合致しない場合は、ログの圧縮を行わずにイベントをログ領域１２２に記録する。障害発生の原因究明には、想定される正常な順序で発生するイベントに関する情報よりも、想定しない順序で発生したイベントに関する情報のほうが重要である。そのため、想定しない順序で発生したイベントは圧縮せずにパターン認識部１１２に記録し、障害の原因究明に役立てることができる。
【００４４】
（３）パターン認識部１１２は、イベントの発生順序が正常順序と完全に一致せず途中まで一致する場合は（図９のステップＳ３３０：ＮＯ）不図示の報知部を用いて異常の発生を報知する（図９のステップＳ３４４）。正常順序と完全に一致せず途中まで一致する場合とは、途中から正常順序と一致しなくなった場合なので、異常の発生が必ずしも明確でない。そのため、報知を行うことにより異常が発生したことを明確にすることができる。
【００４５】
（４）パターン認識部１１２は、イベントが発生するたびに発生したイベントの順序と正常順序との一致判断を行い、正常順序と途中まで一致すると判断すると（図８のステップＳ３０８：ＹＥＳ）、一致する範囲を一時的に記憶して（図８のステップＳ３１２）次回の一致判断の負荷を軽減する。
【００４６】
そのため、パターン認識部１１２の負荷を平準化してＥＣＵ１００のリアルタイム性を確保することができる。たとえば、一定時間の経過後や所定量のログが蓄積されたた後にパターン情報１１２Ａを参照してまとまった量の置換を行うことも考えられるが、その場合は、蓄積された所定量のログを処理するタイミングでパターン認識部１１２がＥＣＵ１００の多くのリソースを使用することになる。そのため、そのタイミングでは他のプログラムが使用可能なリソースが減少し、所定の時間内に既定の処理を完了できない恐れ、すなわちリアルタイム性を確保できない恐れがある。前述のようにＥＣＵ１００はリアルタイム性を確保できるので、処理のリアルタイム性が要求される車載用の電子制御装置に適する。
【００４７】
（変形例１）
パターン情報には、異常時におけるイベントの発生順序である異常順序、および異常順序に対応する異常文字列を含む異常パターン情報が格納されてもよい。異常パターン情報も図４に示したパターン情報１１２Ａと同様に置換前情報と置換後情報から構成される。置換前情報に示されるイベントの順序と発生したイベントの順序が一致すると、ログ領域１２２にはパターン識別子が記録されるとともに異常検知の報知も行われる。
【００４８】
図１０は、変形例１におけるパターン情報１１２Ｂの一例を示す図である。パターン情報１１２Ｂを構成するフィールドは、図４に示したパターン情報１１２Ａと比べて「正常／異常」のフィールドが追加されている。このフィールドは、そのレコードが正常時パターンと異常時パターンのいずれのパターンであるかを示している。すなわち図１０に示す例では、図４の例と同じ２つの正常パターンと、１つの異常パターンが示されている。
【００４９】
この変形例１によれば、次の作用効果が得られる。
（５）不揮発性メモリ１４には、異常時におけるイベントの発生順序である異常順序、および異常順序に対応する異常文字列を含む異常パターン情報が格納される。パターン認識部１１２は、イベントの発生順序が異常順序に合致する場合は、異常順序に代えて異常文字列をログ領域１２２に記録するとともに、不図示の報知部を用いて異常の発生を報知する。そのため、発生が想定される異常順序を予め定めておくことにより、ログの記録に要する記憶領域を削減することができる。
【００５０】
（変形例２）
上述した第１の実施の形態では、パターン情報１１２Ａに含まれるイベントの発生順番、すなわち置換前情報は、複数のフィールドから構成される表形式で記録されるとした。しかし、トレースが容易なようにツリー形式で記録してもよい。この場合は、パターン認識部１１２は現在のノード上の位置を記録し、イベントが発生するたびにツリーを１ノードずつ辿るシーケンシャルな検索を行うことで、図８のステップＳ３０８および図９のステップＳ３３０の判断を行う。
【００５１】
図１１はツリー形式で記録されるパターン情報１１２Ａの置換前情報の一例を示す図である。図１１に示されるイベントの発生順序は、図４に示すパターン情報１１２Ａの例と同一である。図１１に示すＮ１〜Ｎ５は、ツリーを構成するノードを識別するために便宜的に付与したものである。図１１に示すツリーは、Ｎ１を頂点とし図示下方向へ広がる。たとえばＮ２からはＮ３またはＮ５に遷移可能であるが、Ｎ３からはＮ４へしか遷移できない。たとえば、３つのイベントがＡ，Ｘ，Ｙの順に発生すると、パターン認識部１１２はツリー上の現在の位置がＮ３であると認識する。この次にイベントＣが発生すると、Ｎ３から遷移可能なＮ４には「Ｃ」が格納されていないので遷移不能、すなわち前方一致でないとして図８のステップＳ３０８において否定判断を行う。なお同様の判断は、図９のステップＳ３３０においても可能である。
【００５２】
この変形例２によれば、次の作用効果が得られる。
（６）正常順序はツリー構造のデータベースとして格納され、パターン認識部１１２は、イベントが発生するたびにツリー構造のデータベースをシーケンシャルに検索する。そのため正常順序における現在の位置に関わらず１回あたりの検索に要する負荷が平準化され、ＥＣＵ１００のリアルタイム性の確保に資する。この効果は正常順序が長いほど顕著である。
【００５３】
（変形例３）
上述した第１の実施の形態では、ＥＣＵ１００が異常を検知するとログ領域１２２に記録されている全ての情報をスナップショット領域１２３に記録することとしたが（図９のＳ３４６）、ＥＣＵ１００の外部にその情報を保存してもよい。またＥＣＵ１００はその情報を同一の車両内に備えられる不図示の診断装置に伝達してもよい。さらにＥＣＵ１００は、異常の検知に基づき何らかの対策、たとえば制動装置の動作を行ってもよい。
【００５４】
（変形例４）
上述した第１の実施の形態では、パターン認識部１１２は置換を行った際にログ領域１２２に最後のイベントのタイムスタンプを転記した。しかし、全てのイベントのタイムスタンプを転記してもよい。たとえば図７（ａ）に示したケース１では、イベントＰのタイムスタンプを「０，４１０，２４９０，２６９０」として記録してもよい。
【００５５】
（変形例５）
上述した第１の実施の形態では、ログ領域１２２に記録されるイベント識別情報としてイベントＩＤが用いられた。しかしイベントＩＤに代えて図４に示すイベント識別情報を用いてもよいし、イベントを識別できる情報であれば図４に記載されていない情報をログ領域１２２に記録してもよい。本変形例によれば、異常発生時の予期できないイベントをログ領域１２２に記録することができる。
【００５６】
（変形例６）
イベント情報１１３は、不揮発性メモリ１４に直接保存されず、不揮発性メモリ１４に格納されるプログラムが実行されることによりＲＡＭ１２上に作成されてもよい。たとえば不揮発性メモリ１４にオペレーティングシステム（ＯＳ）が格納され、ＣＰＵ１１がＯＳを実行するとＯＳが起動処理の一環としてイベント情報１１３をＲＡＭ１２上に作成してもよい。
【００５７】
（変形例７）
第１の実施の形態では、発生したイベントの順序が正常順序と完全に一致せず途中まで一致する場合のみ異常の発生を報知した。しかし、途中まで一致するか否かに関わらず、正常順序と一致しない場合に異常の発生を報知してもよい。すなわち、図８のステップＳ３１６の直前または直後に図９のステップＳ３３４およびＳ３４６を挿入してもよい。
【００５８】
（変形例８）
第１の実施の形態では、パターン情報１１２Ａに「想定間隔」のフィールドが含まれなくてもよい。
【００５９】
―第２の実施の形態―
図１２を参照して、車載電子制御装置であるＥＣＵの第２の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、ＣＰＵがプログラム中でイベントＩＤを特定する必要がない点で、第１の実施の形態と異なる。第２の実施の形態におけるＥＣＵのハードウエア構成は第１の実施の形態と同様なので説明を省略する。ただしＲＯＭに格納されるプログラムが第１の実施の形態と異なる。
【００６０】
（ＥＣＵの機能構成）
図１２は、第２の実施の形態におけＥＣＵ１００Ａの機能構成を示す図である。ＥＣＵ１００Ａは、第１の実施の形態における構成からイベント情報１１３が除かれている。本実施の形態では、発生するすべてのイベントにイベントＩＤが付されるのでイベント情報１１３が不要である。イベントＩＤは、たとえば不揮発性メモリ１４に格納されるＯＳにより付与される。
【００６１】
（ＥＣＵの動作）
第２の実施の形態におけるＥＣＵ１００Ａの動作は、以下の点を除き第１の実施の形態と同様である。すなわち、第２の実施の形態におけるＣＰＵ１１は、第１の実施の形態の図８におけるステップＳ３０６を実行しなくてよい。
【００６２】
上述した第２の実施の形態によれば、ＥＣＵ１００Ａはイベント情報１１３を記憶する必要がなく、イベント識別情報に基づきイベントＩＤを特定しなくてよい。
【００６３】
―第３の実施の形態―
図１３〜図１７を参照して、車載電子制御装置であるＥＣＵの第３の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、イベント情報だけでなくタイムスタンプの圧縮も行う点で、第１の実施の形態と異なる。第３の実施の形態におけるＥＣＵのハードウエア構成は第１の実施の形態と同様なので説明を省略する。ただしＲＯＭに格納されるプログラムが第１の実施の形態と異なる。
【００６４】
（ＥＣＵの機能構成）
図１３は、第３の実施の形態におけＥＣＵ１００Ｂの機能構成を示す図である。ＥＣＵ１００Ｂは、第１の実施の形態における構成からイベント情報１１３が除かれ、時刻差バッファ１２４が追加されている。時刻差バッファ１２４はＲＡＭ１３に確保される一時的な記憶領域であり、後述する２階差分を算出するために用いられる。本実施の形態では、第２の実施の形態と同様に、発生するすべてのイベントにイベントＩＤが付されるのでイベント情報１１３が不要である。イベントＩＤは、たとえば不揮発性メモリ１４に格納されるＯＳにより付与される。
【００６５】
（ＥＣＵの動作）
本実施の形態におけるＣＰＵ１１は、イベントのパターンを置換する場合には、パターンの最後のイベントが発生した時刻のタイムスタンプを記録する代わりに、以下に説明する２階差分を記録する。２階差分とは、現実時刻差と想定時刻差の差である。現実時刻差とは、ある２つのイベントが発生する時刻の差であって現実に観測された時刻の差である。想定時刻差とは、ある２つのイベントが発生する時刻の差であって、想定される時刻の差である。想定時刻差は、予め定められた値であり、ＲＯＭ１２または不揮発性メモリ１４に格納される。想定時刻差はたとえばパターン情報１１２Ａに「想定間隔」として記録される。
【００６６】
たとえば、イベントＡとイベントＢの発生時刻がそれぞれ「２０１６年１月２日３時００分０．０００００００００秒」、「２０１６年１月２日３時０１分２．３３３４４４５５５秒」と観測された場合に、現実時刻差は「１分２．３３３４４４５５５秒」である。そして、想定時刻差が「１分２．３３３４４４３３３秒」の場合には、現実時刻差と想定時刻差との差分は「０．００００００２２２秒」である。すなわち、「２．２２×１０−７秒」または「２．２２Ｅ−７」と表現できるので、２階差分では現実時刻差に比べてデータ量が少ない。なお、時間分解能が高く、想定時刻差と現実時刻差との差が少ないほど、現実時刻差と２階差分とのデータ量は相違が大きくなる。
【００６７】
（時刻差バッファ）
図１４は、時刻差バッファ１２４の一例を示す図である。時刻差バッファ１２４はたとえば複数のレコードから構成され、各レコードはどのイベント同士の間隔であるかを示すイベント間フィールドと、現実に観測される時刻の差である現実時刻差のフィールドと、想定される時刻の差である想定時刻差のフィールドと、現実時刻差フィールドの値と想定時刻差フィールドの値の差が格納される２階差分のフィールドとを有する。
【００６８】
図１４におけるイベントの発生順番、および現実時刻差は図７（ａ）に示したケース１の先頭の４つのイベントに基づくものである。すなわち、イベントが発生した順番は「Ａ，Ｘ，Ｙ，Ｂ」であり、それぞれのタイムスタンプは「０，４１０，２４９０，２６９０」である。そのため、現実時刻差が「４１０，２０８０，２００」となっている。図１３における想定時刻差は、図４に示したパターン情報１１２Ａの想定間隔である「５００，２０００，３００」である。図１４に示す２階差分は、現実時刻差の値から想定時刻差の値を減じた値としているので、順に「−９０、＋８０、−１００」となっている。
【００６９】
（フローチャート）
図１５および図１６は、第３の実施の形態におけるＥＣＵ１００Ｂの動作を示すフローチャートである。ただし第１の実施の形態と共通する動作には同一のステップ番号を付して説明を省略する。ＣＰＵ１１は、ＥＣＵ１００Ｂにおいて何らかのイベントが発生するたびに図１５および図１６により動作が表されるプログラムを実行する。以下に説明するフローチャートの各ステップの実行主体は、ＥＣＵ１００ＢのＣＰＵ１１である。
【００７０】
ＣＰＵ１１は、イベントが発生するとイベントを実行し（ステップＳ３０２）、時刻レジスタ１１１からタイムスタンプを取得する。次にステップＳ３０８を実行し、肯定判断をするとステップＳ３１０に、否定判断をするとステップＳ３１４に進む。ステップＳ３１０では肯定判断をするとステップＳ４００に進み、否定判断をするとステップＳ３１４に進む。ステップＳ４００では、ＣＰＵ１１は一時バッファ１２１に何か記録されているか否かを判断する。ＣＰＵ１１は、一時バッファ１２１に何か記録があると判断する場合はステップＳ４０２に進み、一時バッファ１２１に何も記録されていないと判断する場合はステップＳ３１２に進む。ステップＳ４０２では、一時バッファ１２１に記録されている最新のイベントとステップＳ３０２において実行したイベントとに対応する想定時刻差をＲＯＭ１２または不揮発性メモリ１４から読み込み時刻差バッファ１２４に書き込む。たとえば一時バッファ１２１に記録されている最新のイベントがＡであり、ステップＳ３０２において実行したイベントがＸの場合は、パターン情報１１２Ａが図４に示すものである場合は「５００」が想定時刻差として時刻差バッファ１２４に書き込まれる。
【００７１】
続くステップＳ４０４では、ステップＳ４０２において読みこんだ想定時刻差を用いて２階差分を算出して時刻差バッファ１２４に記録する。すなわち、まず一時バッファ１２１に記録されている最新のイベントのタイムスタンプと、ステップＳ３０４において取得したタイムスタンプとの差を算出して、時刻差バッファ１２４の現実時刻差のフィールドに記録する。次に時刻差バッファ１２４の現実時刻差と想定時刻差の差を算出し、これを２階差分として時刻差バッファ１２４に書き込む。次にステップＳ３１２に進む。
【００７２】
ステップＳ４００において肯定判断された場合、およびステップＳ４０４の次に実行されるステップＳ３１２では、最新のイベントＩＤとタイムスタンプを一時バッファ１２１に記録する。すなわちステップＳ３０２において実行したイベントのイベントＩＤとステップＳ３０４において取得したタイムスタンプを一時バッファ１２１に記録する。そして図１５および図１６により動作が表されるプログラムの実行を終了する。
【００７３】
ステップＳ３０８、またはステップＳ３１０において否定判定されると実行されるステップＳ３１４では、ＣＰＵ１１は一時バッファ１２１に何か記録されているか否かを判断する。ＣＰＵ１１は、何も記録されていないと判断する場合はステップＳ３１６に進み、何らかの情報が記録されていると判断する場合は図１６のステップＳ３３０に進む。ステップＳ３１６では、ＣＰＵ１１は最新のイベントＩＤとタイムスタンプ、すなわちステップＳ３０６において特定したイベントＩＤおよびステップＳ３０４において取得したタイムスタンプをログ領域１２２に保存して図１５および図１６により動作が表されるプログラムの実行を終了する。
【００７４】
図１６のステップＳ３３０では、ＣＰＵ１１は、一時バッファ１２１内のＩＤ列、すなわち一時バッファ１２１に格納されるイベントのパターンが、パターン情報１１２Ａに基づき置換可能か否かを判断する。置換可能と判断する場合はステップＳ４１２に進み、置換不可能と判断する場合はステップＳ３４０に進む。ステップＳ４１２では、ＣＰＵ１１はステップＳ３３０において置換可能と判断された置換により得られるパターン識別子、および時刻差バッファ１２４の２階差分の値をログ領域１２２に保存する。続くステップＳ４１４では、ＣＰＵ１１は一時バッファ１２１および時刻差バッファ１２４に保存された情報をすべて削除する。続くステップＳ３３５以下の処理は第１の実施の形態と同様であり、最新のイベントＩＤとタイムスタンプを一時バッファ１２１またはログ領域１２２に保存して図１５および図１６により動作が表されるプログラムの実行を終了する。
【００７５】
ステップＳ３３０において否定判断されると実行されるステップＳ３４０では、ＣＰＵ１１は、一時バッファ１２１内の全ての情報をそのままログ領域１２２に記録し、一時バッファ１２１内の全ての情報を削除する。続くステップＳ４１６では時刻差バッファ１２４内の全ての情報を削除してステップＳ３４２に進む。ステップＳ３４２以降の処理は第１の実施の形態と同様なので説明を省略する。
【００７６】
（動作例）
図１７は、本動作例におけるイベントの発生状況、および全てのイベントが発生した後にログ領域１２２に記録される情報を示す図である。先頭の４つのイベントがＥＣＵ１００Ｂにより観測されると、時刻差バッファ１２４には図１４に示す情報が格納される。そして、最後のイベントＣが発生すると、図１５のステップＳ３０８およびＳ３１４において否定判断され、図１６のステップＳ３３０において肯定判断されるので、ステップＳ４１２が実行される。そのためログ領域１２２にイベント識別情報としてパターン識別子Ｐが記録され、タイムスタンプとして「−９０、＋８０、−１００」が記録される。第１の実施の形態では、図７（ａ）に示すように置換されるパターンに該当する一連のイベントのうち、最後のイベントの観測時刻に対応するタイムスタンプが記録されたが、第３の実施の形態では各イベントが発生した時間の間隔が記録される。
【００７７】
上述した第３の実施の形態によれば、次の作用効果が得られる。
（７）パターン情報１１２Ａには、パターン情報に含まれる連続する２つのイベントについてあらかじめ想定された発生時刻の差である想定時刻差、すなわち想定間隔が含まれる。パターン認識部１１２は、現実の時刻の差であってパターン情報に含まれる連続するイベント同士が発生する時刻の差である現実時刻差を算出し、現実時刻差と想定時刻差との差である２階差分をログ領域にさらに記録する。
そのためＥＣＵ１００Ｂは、少ない記憶領域を使ってイベントが発生した間隔を記録できる。時刻レジスタ１１１がカウントする時間の分解能が高く、現実時刻差が想定時刻差に近いほどこの効果は顕著である。
【００７８】
（第３の実施の形態の変形例１）
ＥＣＵ１１０Ｂがイベント情報１１３を備え、ＣＰＵ１１がイベントＩＤを特定してもよい。すなわち、図１５においてステップＳ３０４の次にステップＳ３０６を実行してからステップＳ３０８に進んでもよい。
【００７９】
（第３の実施の形態の変形例２）
図１６のステップＳ４１２において、ログ領域１２２に時刻差バッファ１２４の値だけでなく、置換されるイベントのいずれかの観測時刻をあわせて記録してもよい。本変形例によれば、ログ領域１２２に記録された情報を用いて各イベントが発生した時刻も特定することができる。
【００８０】
本発明には以下のログ格納方法も含まれる。
（１）発生したイベントのログが記録されるログ領域と、正常時の前記イベントの発生順序である正常順序および前記正常順序に対応する文字列を含むパターン情報が格納される記憶部と、を備える車載電子制御装置において実行されるログ格納方法であって、前記車載電子制御装置が前記正常順序に代えて前記文字列を前記ログ領域に記録することでログを圧縮するログ格納方法。
（２）上記ログ格納方法において、前記イベントの発生順序が前記正常順序に合致しない場合は、前記車載電子制御装置が前記ログの圧縮を行わずに前記イベントを前記ログ領域に記録するログ格納方法。
（３）上記ログ格納方法において、前記イベントの発生順序が前記正常順序と完全に一致せず途中まで一致する場合は前記車載電子制御装置が異常の発生を報知するログ格納方法。
（４）上記ログ格納方法において、前記イベントが発生するたびに前記車載電子制御装置が発生した前記イベントの順序と前記正常順序との一致判断を行い、前記正常順序と途中まで一致すると判断すると、前記車載電子制御装置が一致する範囲を一時的に記憶するログ格納方法。
（５）上記ログ格納方法において、前記正常順序はツリー構造のデータベースとして格納され、前記イベントが発生するたびに前記車載電子制御装置が前記ツリー構造のデータベースをシーケンシャルに検索するログ格納方法。
（６）上記ログ格納方法において、前記パターン情報には、前記パターン情報に含まれる連続する２つのイベントについてあらかじめ想定された発生時刻の差である想定時刻差が含まれ、前記車載電子制御装置が、前記２つのイベントの現実の発生時刻の差である現実時刻差を算出し、前記現実時刻差と前記想定時刻差との差を前記ログ領域にさらに記録するログ格納方法。
（７）上記ログ格納方法において、前記記憶部には、特定の異常時における前記イベントの発生順序である異常順序、および前記異常順序に対応する異常文字列を含む異常パターン情報がさらに格納され、前記イベントの発生順序が前記異常順序に合致する場合は、前記車載電子制御装置が、前記異常順序に代えて前記異常文字列を前記ログ領域に記録するとともに、異常の発生を報知するログ格納方法。
【００８１】
ＥＣＵ１００が不図示の入出力インタフェースを備え、必要なときに入出力インタフェースとＥＣＵ１００が利用可能な媒体を介して、他の装置からプログラムが読み込まれてもよい。ここで媒体とは、例えば入出力インタフェースに着脱可能な記憶媒体、または通信媒体、すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号、を指す。また、プログラムにより実現される機能の一部または全部がハードウエア回路やＦＰＧＡにより実現されてもよい。
上述した各実施の形態および変形例は、それぞれ組み合わせてもよい。
上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。
【符号の説明】
【００８２】
１４  …  不揮発性メモリ
１１２  …  パターン認識部
１１２Ａ、１１２Ｂ  …  パターン情報
１１３  …  イベント情報
１２１  …  一時バッファ
１２２  …  ログ領域
１２３  …  スナップショット領域
１２４  …  時刻差バッファ
【図１】
2018109900.tif 000003
【図２】
2018109900.tif 000004
【図３】
2018109900.tif 000005
【図４】
2018109900.tif 000006
【図５】
2018109900.tif 000007
【図６】
2018109900.tif 000008
【図７】
2018109900.tif 000009
【図８】
2018109900.tif 000010
【図９】
2018109900.tif 000011
【図１０】
2018109900.tif 000012
【図１１】
2018109900.tif 000013
【図１２】
2018109900.tif 000014
【図１３】
2018109900.tif 000015
【図１４】
2018109900.tif 000016
【図１５】
2018109900.tif 000017
【図１６】
2018109900.tif 000018
【図１７】
2018109900.tif 000019