JP2019008687A - 演算装置、ログ記録装置、ログ記録システム - Google Patents

Abstract

【課題】イベントログ記録におけるオーバーヘッドを短縮できる演算装置を提供する。【解決手段】制御装置であるＥＣＵ（電子制御装置、Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）１００は、ＣＰＵ（演算装置）１１０、メモリ（主記憶領域）１２０、および時刻情報を管理するタイマ１３０を備える。ＥＣＵに記録対象のイベントが発生すると、ＣＰＵは、タイマに対して現在の時刻値１３１を時刻バッファ１３２に格納させるために、時刻取得トリガ１３３をアサートする。ＣＰＵは、発生したイベントの種類および、そのイベントに関する情報をイベントバッファ１２６に格納する。ＣＰＵは、イベントバッファの各レコードからイベント種類とイベント情報を取り出し、さらにそれに対応する時刻バッファのレコードから時刻を取り出し、これを一つのレコードとして統合ログ１２８の末尾に挿入する。【選択図】図１

Description

本発明は、演算装置、ログ記録装置、およびログ記録システムに関する。

近年の制御装置においては、マルチコア化をはじめとするハードウェアの高度化に伴い、ソフトウェアの複雑度も急速に高まっている。開発時あるいは運用時において制御装置の挙動を把握するためには、ソフトウェアのログの取得が欠かせない。またこのログを解析する際には、ソフトウェア内において発生したイベントとその情報とともに、イベントが発生した時刻、すなわちタイムスタンプが記録されていることが望ましい。時刻情報を伴うログの記録を行うシステムとして、たとえば特許文献１には、複数のプロセッサと、前記複数のプロセッサに共通して設けられたタイマと、前記複数のプロセッサに対応して設けられ、複数のイベントをそれぞれ格納する複数の記憶領域と、を具備し、前記タイマは、時間情報を計測する第１のカウンタと、前記複数のプロセッサが前記タイマにアクセスするごとにカウントアップする第２のカウンタとを含み、前記複数のイベントログは、前記タイマの値から得られるタイムスタンプを含み、前記タイムスタンプに基づいて、前記複数のプロセッサが行った処理の時間間隔および順序を参照できるマルチプロセッサシステムが開示されている。

特開２０１３−１９６１９５号公報

特許文献１に記載されている発明では、タイムスタンプの取得をイベントの発生のたびに行うため、タイマデバイス等の時刻情報を管理するデバイスへのアクセス時間だけＣＰＵにおいて待ちが発生し、イベントログ記録におけるオーバーヘッドが大きい。

本発明の第１の態様による演算装置は、記録指令に基づきイベントの発生時刻を第１の記憶領域に記録するタイマと、前記イベントが発生すると前記イベントの内容を第２の記憶領域に記録するとともに前記タイマに前記記録指令を出力する演算部と、前記イベントの内容と前記イベントの発生時刻との対応付けを行う対応付け部とを備える。
本発明の第２の態様によるログ記録装置は、複数のイベントの内容が発生順に記録された第１情報、および複数のイベントの発生時刻が記録された第２情報を受信する通信部と、前記通信部が受信した前記第１情報と前記第２情報との対応付けてログを生成する対応付け部と、前記対応付け部が生成した前記ログを記録する記憶部とを備える。
本発明の第３の態様によるログ記録システムは、制御装置、時刻記録装置、および上述するログ記録装置を備え、前記制御装置は、イベントが発生すると前記イベントの内容を発生順に記録するイベント記録部と、イベントが発生すると前記時刻記録装置に記録指令を出力する記録指令部と、前記イベント記録部が記録した前記イベントの内容を前記第１情報として前記ログ記録装置に送信する制御装置通信部とを備え、前記時刻記録装置は、前記記録指令を受信すると時刻情報を記録するタイマと、前記タイマが記録した前記時刻情報を前記第２情報として前記ログ記録装置に送信する時刻記録装置通信部とを備える。

本発明によれば、イベントログ記録におけるオーバーヘッドを短縮できる。

第１の実施の形態におけるＥＣＵ１００の構成を表すブロック図 イベントバッファ１２６の一例を示す図 時刻バッファ１３２の一例を示す図 統合ログ１２８の一例を示す図 第１の実施の形態におけるイベントが発生した際のＣＰＵ１１０の動作を示すフローチャート 第１の実施の形態におけるタイマ１３０の動作を示すフローチャート 第１の実施の形態における転写の終了を通知されたＣＰＵ１１０の動作を示すフローチャート 第２の実施の形態におけるタイマ１３０の動作を示すフローチャート 第２の実施の形態における転写の終了を通知されたＣＰＵ１１０の動作を示すフローチャート 第３の実施の形態におけるＥＣＵ１００の構成を表すブロック図 直接統合ログ７２３の一例を示す図 第３の実施の形態におけるイベントが発生した際のＣＰＵ１１０の動作を示すフローチャート 第３の実施の形態におけるタイマ１３０の動作を示すフローチャート 第４の実施の形態におけるＥＣＵ１００の構成を表すブロック図 第４の実施の形態におけるイベントが発生した際のＣＰＵ１１０の動作を示すフローチャート 第５の実施の形態におけるログ記録システム１の構成を表すブロック図 システムイベントバッファ１２１１の一例を示す図 システム時刻バッファ１２４１の一例を示す図 システム統合ログ１２７３の一例を示す図

―第１の実施の形態―
以下、図１〜図７を参照して、本発明にかかる演算装置であるＥＣＵの第１の実施の形態を説明する。

（構成）
図１は、制御装置であるＥＣＵ（電子制御装置、Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）の構成を表すブロック図である。ＥＣＵ１００は、演算装置であるＣＰＵ１１０、主記憶領域であるメモリ１２０、および時刻情報を管理するタイマ１３０を備える。

ＣＰＵ１１０は、汎用的な計算が可能な演算装置であり、シングルコアであってもマルチコアＣＰＵであってもよい。すなわちＣＰＵ１１０は、１つ以上の並列に動作可能なＣＰＵコアを有する。ＣＰＵ１１０は、半導体チップとして単体のものであっても、以下で述べるメモリ１２０やタイマ１３０を一つの半導体チップ上に搭載した、いわゆるＳｏＣ（Ｓｙｓｔｅｍ−ｏｎ−Ｃｈｉｐ）と呼ばれるものであってもよい。ＣＰＵ１１０は、不図示のＲＯＭに格納されたプログラムをメモリ１２０に展開して実行することにより後述する機能を実現する。ただしプログラムの展開に使用する主記憶装置はメモリ１２０の代わりに不図示のＲＡＭを用いてもよい。

メモリ１２０は、揮発性のメモリから構成される主記憶装置、たとえばＤＲＡＭ（Dynamic Random Access Memory）である。メモリ１２０は、ＥＣＵ１００でのソフトウェアで発生したイベントを記録するためのログ記録部１２１を備える。ログ記録部１２１は、イベントバッファ１２６、時刻転写バッファ１２７、および統合ログ１２８を備える。イベントバッファ１２６は、ＥＣＵ１００が実行するソフトウェアで発生した１つ以上のイベントを、それらの時系列がわかるように格納したものである。ただしイベントバッファ１２６には時刻情報は格納されない。イベントバッファ１２６のメモリ上の構造は、単純な配列であってもよいし、リングバッファのような構造を用いて最新の一定数のイベントを残すような構造であってもよい。時刻転写バッファ１２７は、後述する時刻バッファ１３２をメモリ１２０上に転写したものである。統合ログ１２８は、イベントバッファ１２６に記録されたイベントの情報と時刻転写バッファ１２７に記録されたタイムスタンプの情報を対応付けたものであり、最終的なイベントログとなる。

タイマ１３０は、ＣＰＵ１１０から内部バスなどを介してアクセス可能な、時刻を管理するデバイスである。タイマ１３０が管理する時刻は、ＲＴＣ（Ｒｅａｌ−ｔｉｍｅ Ｃｌｏｃｋ）と呼ばれる絶対時刻であっても、デバイスが起動した時刻などのある一定のタイミングからの経過時間である相対時刻であってもよい。タイマ１３０は、時刻値１３１、時刻バッファ１３２、時刻取得トリガ１３３、およびＤＭＡエンジン１３４を備える。またタイマ１３０にはあらかじめハードウエア回路が組み込まれており、このハードウエア回路により後述する処理が実現される。ただしタイマ１３０はハードウエア回路のかわりに不図示のマイクロコンピュータを用いて同様の機能を実現してもよい。

時刻値１３１は、タイマ１３０が管理している時刻の値である。時刻バッファ１３２は、時刻取得トリガ１３３がアサートされた際の時刻値１３１を、その順序がわかるように１つ以上格納したものである。時刻バッファ１３２の構造は、単純な配列であってもよいし、リングバッファのような構造であってもよい。時刻バッファ１３２は、タイマ１３０に内蔵される小容量の記憶領域であり、メモリ１２０とは異なるハードウエアである。すなわちタイマ１３０による時刻値１３１の時刻バッファ１３２への書き込みは高速に実行される。

タイマ１３０に備えられる時刻取得トリガ１３３は、たとえば、タイマ１３０のレジスタである。時刻取得トリガ１３３は、ＣＰＵ１１０からメモリ１２０と同様にアクセスできるものである。ＣＰＵ１１０が時刻取得トリガ１３３に対して何らかの書き込みアクセスを行うと、タイマ１３０が時刻値１３１を時刻バッファ１３２の末尾に格納する。ただし時刻取得トリガ１３３は、ＣＰＵ１１０からの読み込みアクセスによってアサートされてもよいし、ＣＰＵ１１０からの特殊な命令によってアサートされてもよい。時刻取得トリガ１３３がアサートされるとは、たとえばタイマ１３０のレジスタに書き込みアクセスが行われることである。

タイマ１３０に備えられるＤＭＡエンジン１３４は、ＣＰＵ１１０を介在せずにメモリなどのある領域からある領域への転写（ＤｉｒｅｃｔＭｅｍｏｒｙＡｃｃｅｓｓ，ＤＭＡ転送）を行う。本実施の形態ではＤＭＡエンジン１３４は、時刻バッファ１３２からメモリ１２０への転写処理が可能である。なお、本実施の形態では簡単のためにＤＭＡエンジン１３４をタイマ１３０に内蔵されるとして説明するが、次の条件を満たせばＣＰＵ１１０やタイマ１３０とは独立したデバイスであってもよい。すなわちＤＭＡエンジン１３４は、ＣＰＵ１１０もしくはタイマ１３０から制御可能であり、時刻バッファ１３２およびメモリ１２０に対する転写可能なものであれば、ＣＰＵ１１０やタイマ１３０とは独立したデバイスであってもよい。

図２は、イベントバッファ１２６の一例を示す図である。図２ではイベントバッファ１２６は、上の行から下の行へ時系列順にレコードが並ぶテーブルの形式を有する。イベントバッファ１２６には、発生したイベントのそれぞれが独立したレコードとして格納される。イベントバッファ１２６の各レコードは、イベントの種類を示す「イベント」のフィールド、およびその他のイベントに関する情報が格納される「イベント情報」のフィールドを有する。イベントの種類とは、たとえば、タスクの実行や終了、割り込みの発生および割り込みハンドラの終了、通信の送信や受信などである。イベントに関する情報とは、イベント発生時のある変数の値など、そのイベント発生に付随した情報である。ただし、記録する全てのイベントで付随する情報が不要である場合は、「イベント」フィールドのみを備えればよく、「イベント情報」のフィールドは省略してもよい。

以下では、図示するレコードを上から順に第１レコード、第２レコード、・・・と呼ぶ。たとえば図２に示す例では、第１レコードには、ＥｖｅｎｔＡというイベントが発生し、そのイベントのより詳細な情報としてそのときのＰａｒａｍＸの値が１００であったことが示されている。そして第２レコードには、ＥｖｅｎｔＢの発生では、ＰａｒａｍＹが「ＨｅｌｌｏＷｏｒｌｄ」という文字列、ＰａｒａｍＺが３であり、ＥｖｅｎｔＣでは、特に詳細な情報がないことを示している。なお図２では、ＥｖｅｎｔＡ，ＥｖｅｎｔＢ，ＥｖｅｎｔＣの順番にイベントが発生したことを示しているが、それぞれが発生した時刻については格納されていない。

図３は、時刻バッファ１３２の一例を示す図である。図３では時刻バッファ１３２は、図２と同様に上の行から下の行へ時系列順にレコードが並ぶテーブルの形式を有する。時刻バッファ１３２の各レコードには、タイマ１３０によって記録された時刻値１３１が各行に格納されており、それぞれ、時刻取得トリガ１３３がアサートされた時点での時刻値１３１が記録されている。すなわち、図３に示す例でいえば、最初に時刻取得トリガ１３３がアサートされた時刻が１００、二回目が２００、三回目が２５０であったことが示されている。後述するように、時刻取得トリガ１３３はイベントが発生するたびにアサートされるため、時刻バッファ１３２の各行は、イベントの発生したタイミングに対応している。またログ記録部１２１は、イベント発生のたびにイベントバッファ１２６に一行ずつその情報を格納するため、時刻バッファ１３２の各レコードはイベントバッファ１２６の各レコードにも対応する。

図４は、統合ログ１２８の一例を示す図である。図４では、図２および図３と同様に上の行から下の行へ時系列順にレコードが並ぶテーブルの形式を有する。統合ログ１２８の各レコードは１つのログであり、「イベント」、「イベント情報」、および「時刻」のフィールドを有する。統合ログ１２８は、イベントバッファ１２６と時刻バッファ１３２の各レコードとを組み合わせて作成される。たとえば図４に示す１行目の記載から、ＥｖｅｎｔＡが発生し、その時のＰａｒａｍＸが１００であり、さらに、対応する時刻バッファ１３２の行から、その時刻が１００であったことを示している。

（動作）
イベントが発生した際のＥＣＵ１００の動作を図５〜図７を参照して説明する。記録対象のイベントが発生すると、ＣＰＵ１１０は、タイマ１３０に対して現在の時刻値１３１を時刻バッファ１３２に格納させるために、時刻取得トリガ１３３をアサートする（図５のＳ５０１）。アサートの方法は、たとえば前述したように、特定のアドレスへのメモリアクセスである。次にＣＰＵ１１０は、発生したイベントの種類および、そのイベントに関する情報をイベントバッファ１２６に格納する（Ｓ５０２）。なお、イベントバッファ１２６がリングバッファのような構造であり、イベントバッファ１２６の全てに書き込み済みである場合など、必要に応じてイベントバッファ１２６内の最古の情報を削除してもよい。

図５のＳ５０１によって時刻取得トリガ１３３がアサートされると、タイマ１３０は図６に示すフローチャートにより動作が表されるプログラムを開始する。すなわちタイマ１３０は、まず現在の時刻値１３１を時刻バッファ１３２の末尾に格納する（図６のＳ５１１）。次にタイマ１３０は、時刻バッファ１３２にこれ以上の時刻値を格納可能であるか否かを判断する（Ｓ５１２）。タイマ１３０はまだ格納可能な領域が時刻バッファ１３２に存在すると判断する場合は（Ｓ５１２：ＮＯ）、図６に示す処理を終了する。タイマ１３０は、時刻バッファ１３２が一杯であり、これ以上の時刻値を格納することができないと判断する場合は（Ｓ５１２：ＹＥＳ）次の処理を行う。すなわちタイマ１３０は、ＤＭＡエンジン１３４を用いて時刻バッファ１３２に格納された情報をメモリ１２０上の時刻転写バッファ１２７に転写する（Ｓ５１３）。

そしてタイマ１３０は、Ｓ５１３の転写が完了するとＣＰＵ１１０に対して通知を行う（Ｓ５１４）。この通知は、たとえば、ＣＰＵ１１０に対して割り込みを発生させるものであってもよいし、特定のメモリ領域あるいは特定のＣＰＵ命令によって、ＣＰＵ１１０が知ることのできるものであってもよい。後者の場合は、ＣＰＵ１１０は、たとえばアイドル時にその領域へのアクセスあるいは命令を発行することによって、完了の通知があるかどうかを調べ、完了通知がある場合に次に述べる処理を実行する。なおＳ５１４の通知は、タイマ１３０が主体となりＤＭＡエンジン１３４の転写完了をトリガーとしてＣＰＵ１１０に通知してもよいし、ＤＭＡエンジン１３４がＣＰＵ１１０に対して完了を通知してもよい。最後にタイマ１３０は、時刻バッファ１３２が以降で発生したイベントの時刻を記録可能になるように、時刻バッファ１３２の内容をクリアし（Ｓ５１５）、図６に示す処理を終了する。

図７を参照して、Ｓ５１４の処理により転写の終了を通知されたＣＰＵ１１０の処理を説明する。ＣＰＵ１１０は、まず時刻転写バッファ１２７と時刻バッファ１３２の各レコードを比較し、一方の各レコードが他方のどのレコードに対応するかを判断する（Ｓ５２１）。上述したように、イベント発生時にはイベントバッファ１２６と時刻バッファ１３２にレコードごとに同じ順番で格納されていくので、これらの対応関係は明らかである。すなわち統合ログ１２８の説明で述べたように、それぞれの最古のレコード同士が対応し、それ以後も各レコードが順番に他方と対応する。ＣＰＵ１１０は、この対応付けに従って統合ログ１２８を完成させる（Ｓ５２２）。すなわちＣＰＵ１１０は、イベントバッファ１２６の各レコードからイベント種類とイベント情報を取り出し、さらにそれに対応する時刻バッファ１３２のレコードから時刻を取り出し、これを一つのレコードとして統合ログ１２８の末尾に挿入する。ＣＰＵ１１０は統合ログ１２８がリングバッファのような構造であれば、統合ログ１２８に対してもイベントバッファ１２６に対する処理と同様に、古いものを削除してもよい。最後にＣＰＵ１１０は、イベントバッファ１２６および時刻転写バッファ１２７をクリアすることで、新しいイベントの記録を行えるようにする（Ｓ５２３）。ＣＰＵ１１０は、以上で図７に示す処理を終了する。

上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）ＥＣＵ１００は、記録指令、すなわち時刻取得トリガ１３３へのアサートに基づきイベントの発生時刻を時刻転写バッファ１２７に記録するタイマと、イベントが発生するとイベントの内容をイベントバッファ１２６に記録するとともにタイマ１３０の時刻取得トリガ１３３をアサートするＣＰＵ１１０（図５のＳ５０１、Ｓ５０２）と、イベントの内容とイベントの発生時刻との対応付けを行うＣＰＵ１１０（図７のＳ５２１）とを備える。

このような構成を有するので、ＥＣＵ１００はイベントの発生時刻であるタイムスタンプの記録のために、イベントの発生のたびにＣＰＵがタイマからタイムスタンプを読み出すという処理を行う必要がない。これは、イベント発生時のＣＰＵ１１０の処理としては、Ｓ５０１によるトリガ処理と、イベント情報に関するメモリ１２０へのアクセスのみであり、タイムスタンプはタイマ１３０自身が記録するためである。このことにより、イベント発生時の記録処理によって発生するＣＰＵ１１０のオーバーヘッドを削減することができる。なぜならば、ＣＰＵ１１０のタイマからのタイムスタンプの読出しは、読出し（ロード）命令であり、一般に、ロード命令は、実際に読み出した内容がＣＰＵ１１０に到達するまでＣＰＵ１１０を待ち状態とする必要があるが、他方、トリガ処理に用いられる処理が、前述したように書き込み（ストア）命令であれば、ストア命令は一般に、書き込みの完了をＣＰＵ１１０が待つ必要はないため、ロード命令を発行する場合に対してストア命令を発行したほうがＣＰＵ１１０が待ち状態となる時間を削減することができるためである。

さらに、時間削減の効果は、ＣＰＵ１１０の機能として、メモリやＩ／ＯのアクセスをＣＰＵ１１０の実行モードに応じて制限する機能が有効である場合にも大きくなる。ＣＰＵ１１０がタイマ１３０の時刻値１３１への直接のアクセスが許されないモードで動作している場合に、記録対象のイベントが発生したときには、タイムスタンプの取得、すなわち時刻値１３１の読出しのために、アクセスが許されるモードへ遷移する必要がある。この処理は、一般にシステムコールなどと呼ばれる仕組みを用いて行われるが、そのアクセスの正当性の検査などを精査する処理が必要となり、少なからずオーバーヘッドがかかる。しかしながら、ＥＣＵ１００は上述した構成を有するので、時刻取得トリガ１３３へのアクセスを許すことによって、ロード命令がストア命令に置き換えられることによる効果に加えて、モード遷移によるオーバーヘッドも含めて削減することができる。

なおＥＣＵ１００はイベント情報と時刻情報との記録を分離するので、図７においてＳ５２１〜Ｓ５２２として示した対応付け処理が必要になる。しかし、これらの処理は図５や図６に示したログの記録とは独立して実行可能であり、たとえばＣＰＵ１１０がアイドル状態である際にまとめて行うことができる利点がある。すなわち、イベント発生時にログ記録によって発生するオーバーヘッドとしては観測されず、アイドル状態でＣＰＵ１１０が使用されていない状態を有効に活用することができる。

さらにＥＣＵ１００におけるイベント発生時のログ記録によるオーバーヘッドを削減する効果は、非常に強い実時間性を要求される制御装置で特に有益である。たとえば、自動車のＥＣＵがその一例である。記録対象のイベントとして、割り込みの発生を例として挙げると、割り込みの発生時には、その割り込みハンドラの実行を行う前に発生したことをログとして記録する必要がある。このため、ログ記録によるオーバーヘッドが大きいと、割り込みハンドラの実行がそれだけ遅延されることになる。他方、実時間性の一つの要素として、割り込みへの応答時間がある。応答時間とは、割り込みが発生してから、実際に割り込みハンドラによってその対応する処理が実行されるまでの時間である。つまり、本実施例で説明したように、ログ記録におけるオーバーヘッドを短縮することができ、応答性を向上させることが可能になる。

（２）タイマ１３０は、時刻情報を時刻転写バッファ１２７に発生した順番に格納する。ＣＰＵ１１０は、イベントの内容をイベントバッファ１２６に発生した順番に格納する。ＣＰＵ１１０は、格納された順番に基づき時刻転写バッファ１２７に記録された時刻情報とイベントバッファ１２６に記録されたイベントの内容を対応付ける。そのためＥＣＵ１００は、時刻情報とイベント情報とを容易に対応付けることができる。

（３）タイマ１３０は、時刻取得トリガ１３３がアサートされた時刻がイベントの発生時刻として記録される時刻バッファ１３２と、時刻バッファ１３２に記録されたイベントの発生時刻を時刻転写バッファ１２７に転記するＤＭＡエンジン１３４とを備える。ＤＭＡエンジン１３４は、時刻バッファ１３２の空き容量が所定の容量以下になると転記を行い、時刻バッファ１３２からイベントの発生時刻を消去する（図６のＳ５１２〜Ｓ５１５）。そのため適切なタイミングで時刻バッファ１３２の内容をメモリ１２０にＤＭＡ転送し、時刻バッファ１３２をクリアすることで動作の継続を可能とする。

（４）ＣＰＵ１１０は、ＤＭＡエンジン１３４による転記が行われると対応付けを行い（図７のＳ５２１）、時刻転写バッファ１２７に記録されたイベントの発生時刻およびイベントバッファ１２６に記録されたイベントの内容を消去する（図７のＳ５２３）。そのため迅速に対応付けを行い、ログを生成することができる。

（変形例１）
ＣＰＵ１１０は、図５に示すＳ５０２の処理を遅延させて、複数回分のイベントの情報をまとめて記録してもよい。割り込みの発生と割り込みハンドラ処理の完了を例にあげれば、割り込みハンドラ処理の完了時において、その前に割り込みが発生したことは明らである。すなわち割り込みの発生時には、ＣＰＵ１１０は図５に示すＳ５０１の処理のみを実行し、割り込みハンドラ処理の完了時に、発生したイベントと完了時のイベントの二つのログをイベントバッファ１２６に追記する。この変形例１によれば、前述した割り込み発生時の応答性をさらに向上させることができる。

（変形例２）
図６に示すＳ５１２において、時刻バッファ１３２がいっぱいであるか否かを判断する代わりに、時刻バッファ１３２の空きが予め定めた量、またはあらかじめ定めた割合以下であることを条件としてもよい。この変形例２によれば、イベントの発生が短期間で連続した場合に、時刻バッファ１３２の転送が完了する前に、新たな時刻値１３１の格納が必要となった場合でも、時刻バッファ１３２の空き領域に格納することができ、時刻値１３１の記録を取りこぼすことを防ぐことができる。

（変形例３）
図６に示すＳ５１５において、転写完了時に時刻バッファ１３２をクリアすることで空き領域を確保するとした。しかし、時刻バッファ１３２が複数面のバッファを有する場合は、Ｓ５１５においてこれを切り替えることでクリアの代替処理としてもよい。この変形例３によれば、空き容量を即座に確保することができ、変形例２と同様の効果を得ることができる。

（変形例４）
ＣＰＵ１１０は、図７に示した処理をＣＰＵ１１０の処理負荷が低い場合に実行してもよい。換言するとＣＰＵ１１０は、ＤＭＡエンジン１３４による時刻転写バッファ１２７へのイベント発生時刻の転写が完了しても、即座に図７に示す処理を実行しなくてもよい。本変形例によれば、ＣＰＵ１１０の処理負荷を平準化することができる。

―第２の実施の形態―
図８〜図９を参照して、本発明にかかる演算装置であるＥＣＵの第２の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、タイマ１３０がＤＭＡエンジンを備えない点で、第１の実施の形態と異なる。すなわち本実施の形態では、ＥＣＵ１００はＣＰＵ１１０によるデータ転送を行う。

（構成）
第２の実施の形態におけるＥＣＵ１００の構成は、第１の実施の形態からＤＭＡエンジン１３４が省略された構成である。それ以外の構成は第１の実施の形態と同様である。ただしＥＣＵ１００の不図示のＲＯＭに格納されるプログラムの動作およびタイマ１３０に実装されたハードウエア回路の動作が第１の実施の形態と異なる。

（動作）
第１の実施の形態との動作フローの相違点を図８〜図９を参照して説明する。なお時刻バッファ１３２は、ＣＰＵ１１０からロード命令もしくは特定の命令によってアクセス可能である。図８〜図９は、イベント発生時のＣＰＵ１１０およびタイマ１３０の動作フローの一例を示したものであり、第１の実施の形態における図６〜図７に対応する。すなわち図７に示したイベントが発生した際のＣＰＵ１１０の動作は第１の実施の形態と同様であり、ここでは説明を省略する。

ＣＰＵ１１０から時刻取得トリガ１３３がアサートされると、タイマ１３０は第１の実施の形態と同様にＳ５１１およびＳ５１２を実行する。タイマ１３０はＳ５１２を肯定判断すると、ＣＰＵ１１０にバッファ空き容量の不足を通知し（Ｓ６１３）、図８に示す処理を終了する。ＣＰＵ１１０は、図８のＳ６１３における通知をタイマ１３０から受信すると、図９に示す処理を開始する。すなわちＣＰＵ１１０は、時刻バッファ１３２から時刻転写バッファ１２７に転写を行う（Ｓ６２１）。次にＣＰＵ１１０は、Ｓ５２１およびＳ５２２の処理を行う。最後にＣＰＵ１１０は、時刻バッファ１３２、イベントバッファ１２６および時刻転写バッファ１２７をクリアし（Ｓ６２４）、図９に示す処理を終了する。

上述した第２の実施の形態によれば、ＤＭＡエンジンを保持しない制御装置においても、第１の実施の形態と同様の効果を得ることができる。

（第２の実施の形態の変形例）
本実施の形態では、Ｓ６２１およびＳ５２２において、時刻バッファ１３２から時刻転写バッファ１２７への転写および時刻転写バッファ１２７から統合ログ１２８への転写をＣＰＵ１１０が行うと説明した。しかし、Ｓ５２１における対応付けが明らかな形であるならば、すなわち、たとえば時刻バッファ１３２の各行とイベントバッファ１２６の各行が先頭から順に対応するのであれば、時刻バッファ１３２から統合ログ１２８の「時刻」列への転写を、時刻転写バッファ１２７を介さずに直接行ってもよい。本変形例によれば、転写回数を減らし、対応付けに必要なＣＰＵ１１０の処理および必要なメモリ１２０の量をさらに削減する効果が得られる。

―第３の実施の形態―
図１０〜図１３を参照して、本発明にかかる演算装置であるＥＣＵの第３の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、イベントバッファおよび時刻転写バッファが後述する直接統合ログの領域内に設定される点で、第１の実施の形態と異なる。

（構成）
図１０は、第３の実施の形態におけるＥＣＵ１００の構成を示すブロック図である。メモリ１２０に備えられるログ記録部１２１は、直接統合ログ７２３を備える。またＤＭＡエンジン１３４は、ＣＰＵ１１０もしくはタイマ１３０から設定可能な転送先アドレス７３５の情報を有する。転送先アドレス７３５は、ＤＭＡエンジン１３４が転写するメモリ領域の宛先のメモリアドレスを指定するものである。ＤＭＡエンジン１３４は、タイマ１３０からの動作指示により、時刻バッファ１３２の内容を転送先アドレス７３５に対して転写する。

（直接統合ログ７２３）
図１１は、直接統合ログ７２３の一例を示す図である。直接統合ログ７２３の各レコードが有するフィールド、および各フィールドに格納される情報は、統合ログ１２８と同様である。ただし統合ログ１２８および直接統合ログ７２３は、情報が書き込まれるタイミングおよび情報を書き込む主体が異なる。すなわち直接統合ログ７２３はイベントのログ記録時にもＣＰＵ１１０により書き込みが行われる。また直接統合ログ７２３は、第１の実施の形態におけるイベントバッファ１２６および時刻転写バッファ１２７を包含するものである。すなわち、直接統合ログ７２３のイベントおよびイベント情報のフィールドが第１の実施の形態におけるイベントバッファ１２６に相当する。また直接統合ログ７２３の時刻のフィールドが第１の実施の形態における時刻転写バッファ１２７に相当する。前述のとおり、転送先アドレス７３５はＤＭＡエンジン１３４が転写するメモリ領域の宛先のメモリアドレスを指定するので、転送先アドレス７３５はＤＭＡエンジン１３４が時刻情報を転記する時刻転写バッファ１２７の詳細な位置を示すものとも言える。

また図１１において空欄で表現されているように、「時刻」のフィールドが埋められていないレコードも存在しうる。以降の説明のために、第１〜第３のレコードにおける「時刻」フィールドをそれぞれ、時刻７２３ａ、時刻７２３ｂ、時刻７２３ｃと呼ぶ。たとえば図１１に示す例において、第１のレコードに記載されたイベントの種類がＥｖｅｎｔＡであり、その情報はＰａｒａｍＸが１００であり、その発生時刻は１００である。第３のレコードに記載されたイベントの種類はＥｖｅｎｔＣであり、その情報はなく、またその発生時刻は未だ格納されていないことを表している。

図１２〜図１３は、イベント発生時のログ記録の動作フローの一例を示したものであり、第１の実施の形態における図５〜図７に相当する。ＣＰＵ１１０は、転送先アドレス７３５を直接統合ログ７２３の次に記録すべきレコードの「時刻」フィールドのアドレスに設定する（Ｓ９０１）。次にＣＰＵ１１０は、Ｓ５０１と同様に時刻取得トリガ１３３をアサートし、タイマに対して時刻取得を指示する（Ｓ９０２）。そしてＣＰＵ１１０は、発生したイベントの種類およびそのイベントに関する情報を、直接統合ログ７２３の次に記録すべきレコードの「イベント」および「イベント情報」のフィールドにそれぞれ格納する（Ｓ９０３）。ＣＰＵ１１０は、以上で図１２に示す処理を終了する。

図１２のＳ９０２によって時刻取得トリガ１３３がアサートされると、タイマ１３０は図１３に示すフローチャートにより動作が表されるプログラムを開始する。すなわちタイマ１３０は、まずＳ５１１と同様に時刻値１３１を時刻バッファ１３２に転写する（Ｓ９１１）。次にタイマ１３０は、ＤＭＡエンジン１３４を用いて時刻バッファ１３２の内容を転送先アドレス７３５、すなわち、直接統合ログ７２３の次のレコードの「時刻」のフィールドを示すアドレスへ転写を行う（Ｓ９１２）。これにより、イベント発生時のタイムスタンプを直接統合ログ７２３の最終レコードの「時刻」のフィールドにコピーすることができる。以上でタイマ１３０は図１３に示す処理を終了する。

（動作例）
ＥＣＵ１００の動作を図１１を参照して説明する。ＣＰＵ１１０は、最初のイベントが発生すると、転送先アドレス７３５を時刻７２３ａに設定する（Ｓ９０１）。そしてＣＰＵ１１０は、タイマ１３０の時刻取得トリガ１３３をアサートする（Ｓ９０２）。次にＣＰＵ１１０は、第１レコードの「イベント」フィールドにＥｖｅｎｔＡ、「イベント情報」フィールドにＰａｒａｍＸ：１００を格納する（Ｓ９０３）。タイマ１３０は、時刻取得トリガ１３３がアサートされたときの時刻値１３１の値１００を時刻バッファ１３２に格納する（Ｓ９１１）。さらにタイマ１３０は、ＤＭＡエンジン１３４を用いて、時刻バッファ１３２の値１００を直接統合ログ７２３の第１レコードの「時刻」フィールドに転写する。これによって、第１レコードが完成する。次のイベント（ＥｖｅｎｔＢ）が発生すると、ＣＰＵ１１０は転送先アドレス７３５を時刻７２３ｂに設定し、同様の処理を行う。図１１に示す状態では、第３のイベント（ＥｖｅｎｔＣ）が発生し、ＣＰＵ１１０はイベントおよびイベント情報の格納（Ｓ９０３）までを終えており、タイマ１３０はＳ９１１まで完了しＳ９１２を実行する前の状態を表している。

上述した第３の実施の形態によれば、第１の実施の形態の作用効果に加えて、次の作用効果が得られる。
（１）時刻転写バッファ１２７とイベントバッファ１２６は同一の物理メモリ内に確保される。タイマ１３０は、時刻取得トリガ１３３がアサートされた時刻がイベントの発生時刻として記録される時刻バッファ１３２と、時刻バッファ１３２に記録されたイベントの発生時刻を時刻転写バッファ１２７に転記するＤＭＡエンジン１３４とを備える。ＣＰＵ１１０は、ＤＭＡエンジン１３４が時刻情報を書き込む時刻転写バッファ１２７の詳細な位置を転送先アドレス７３５としてＤＭＡエンジン１３４に指定することで対応付けを行う。

本実施の形態によれば、図１２のＳ９０１によってＤＭＡエンジン１３４の転写先のアドレスをあらかじめ指定しているので、ＤＭＡエンジン１３４による転写が完了した時点で対応付けが完了する。これによって、図７で示した二回目のＣＰＵ１１０による対応付け処理を省略することができる。すなわち、ＣＰＵ１１０による処理の削減、および、イベントバッファ１２６、時刻転写バッファ１２７といったメモリ使用量の削減という効果を得ることができる。

（第３の実施の形態の変形例１）
ＤＭＡエンジン１３４の転写元として時刻値１３１を指定することができる場合は、図１３に示した処理を以下のように変更してもよい。すなわち、図１３のＳ９１１を省略し、図１３のＳ９１２を時刻値１３１から転送先アドレスに転写するように変更する。この変形例によれば、時刻バッファ１３２に対する転写を省略することができ、さらなる時間短縮の効果が得られる。

（第３の実施の形態の変形例２）
ＣＰＵ１１０はさらに直接統合ログ７２３のレコードごとに完成したことを判断してもよい。すなわちＣＰＵ１１０は、直接統合ログ７２３のそれぞれのレコードについて、全てのフィールドに書き込みがされるとそのレコードが完成したと判断する。なお、ＣＰＵ１１０の動作とタイマ１３０およびＤＭＡエンジン１３４の動作は並行しているため、「時刻」フィールドのみが埋まり、「イベント」と「イベント情報」のフィールドが空欄である場合もありうる。

（第３の実施の形態の変形例３）
短期間に多数のイベントが発生すると、Ｓ９１２の処理が完了する前に、新たなイベントが発生してしまう場合が考えられる。このような場合は、次の２つのいずれかの対策を行ってもよい。第１の対策は、ＤＭＡエンジン１３４の転写完了までＣＰＵ１１０が待機し、転送が完了するとＣＰＵ１１０が次のＳ９０１の処理を開始するものである。第２の対策は、ＤＭＡチェーンを利用するものである。すなわち転送先アドレス７３５に直接統合ログ７２３のさらに次のレコードの「時刻」フィールドのアドレスもあわせて格納し、ＤＭＡエンジン１３４に複数の転送を次々に実行させる。第１の対策では、短期間の多数のイベント発生に対応可能ではあるが、ＤＭＡエンジン１３４の転写が完了するまでＣＰＵ１１０が待ち状態となり、応答性を悪化させる恐れがある。第２の対策では、ＣＰＵ１１０はＤＭＡエンジン１３４の転写を待つことなく次の処理へ進むことができるため、イベントが短期間で多く発生するような場合でも、応答性を損なわない効果が得られる。

（第３の実施の形態の変形例４）
直接統合ログ７２３が格納されるメモリのアドレスが規則性を有する場合は、転送先アドレス７３５の設定をＤＭＡエンジン１３４自身が行ってもよい。この場合はＣＰＵ１１０は、初期化処理などにおいて直接統合ログ７２３の第１レコードの「時刻」フィールドのアドレス、および上述した規則性に基づきレコードごとのオフセット値を設定する。そしてＤＭＡエンジン１３４は、転写を実行するたびに転送先アドレス７３５を設定されたオフセット値だけ増価させる。本変形例によれば、イベント発生のたびにＣＰＵ１１０が転送先アドレス７３５を設定する必要がない。すなわち、ＣＰＵ１１０のイベント発生時のログ記録の処理を短縮し、応答性を向上させる効果が得られる。

―第４の実施の形態―
図１４〜図１５を参照して、本発明にかかる演算装置であるＥＣＵの第４の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、タイマ１３０に時刻情報を記録するタイミングを通知する方法が第１の実施の形態と異なる。

（構成）
図１４は、第４の実施の形態におけるＥＣＵ１００の構成を示す図である。ＥＣＵ１００は、第１の実施の形態における構成に加えて、出力信号ポート１０４０を備える。出力信号ポート１０４０は、ＣＰＵ１１０から制御が可能であり、ＥＣＵ１００の外部へ信号を出力するポートである。出力信号ポート１０４０から信号を出力するための制御は、時刻取得トリガ１３３と同様に、たとえば特定のメモリアドレスへのストア命令や、特定のＣＰＵ１１０の命令である。また後述するように、不図示のＲＯＭに格納されるプログラムの動作が第１の実施の形態と異なる。

タイマ１３０は、第１の実施の形態における構成に加えて、トリガ信号ポート１０３４を備える。トリガ信号ポート１０３４は図１における時刻取得トリガ１３３と同様の機能を有する。すなわちトリガ信号ポート１０３４には、ＥＣＵ１００の外部から時刻値１３１を時刻バッファ１３２へ転写させるためのトリガーとなる信号が入力される。さらに、この出力信号ポート１０４０とトリガ信号ポート１０３４を配線Ｋにより結線している。配線Ｋは物理的な配線であってもよいし、ＥＣＵ１００内部の論理的な配線であってもよい。物理的な配線である場合は、これらの信号ポートの電圧や電流、極性などの特性に応じて、これらを調節する電子回路を経由していてもよい。以降の説明では、出力信号ポート１０４０の出力信号の電圧レベルをＬｏｗからＨｉｇｈに切り替えた立ち上がりのタイミングで、トリガ信号ポート１０３４を経由して時刻値１３１から時刻バッファ１３２への転写が発生するものとする。

（動作）
図１５は、イベント発生時のＣＰＵ１１０の動作を示すフローチャートである。図１５は、第１の実施の形態における図５に相当する。ＣＰＵ１１０は、イベントが発生すると出力信号ポート１０４０からＨｉｇｈ信号を出力し（Ｓ１１０１）、次に第１の実施の形態と同様にＳ５０２を実行する。そしてＣＰＵ１１０は、出力信号ポート１０４０からＬｏｗ信号を出力して図１５に示す処理を終了する。なお、第１の実施の形態における図６および図７に相当する動作に変更はない。

上述した第４の実施の形態によれば、次の作用効果が得られる。
（１）タイマ１３０は記録指令を受け付けるトリガ信号ポート１０３４を備える。ＥＣＵ１００は、トリガ信号ポート１０３４へ記録指令を出力する出力信号ポート１０４０を備える。ＣＰＵ１１０は、出力信号ポート１０４０を介してタイマ１３０に記録指令を出力する。そのため、タイマ１３０の時刻値１３１から時刻バッファ１３２への転写のトリガが外部ポートとしてのみ存在し、ＣＰＵ１１０から直接アサートすることができないＥＣＵ１００であっても、第１の実施の形態と同様の効果を得ることができる。

（第４の実施の形態の変形例）
上述した第４の実施の形態では、トリガ信号ポート１０３４に対する信号が確実に伝わるように、Ｓ５０２を挟んでＳ１１０１の処理とＳ１１０３の処理とを実行した。これは、信号レベルをＨｉｇｈからＬｏｗに戻すのに一定の時間を要すること一般に必要だからである。しかし、実際の物理特性に応じ、ＨｉｇｈとＬｏｗ信号出力の間隔が短くてよい場合には、Ｓ１１０３をＳ５０２の前に実行してもよいし、Ｓ５０２の実行よりも長い間隔が必要であれば、Ｓ１１０３の前に適切な時間の待ちを挿入してもよい。

―第５の実施の形態―
以下、図１６〜図１９を参照して、本発明にかかるログ記録装置およびログ記録システム１の第５の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、ネットワークを介して接続された装置を構成に含む点で、第１の実施の形態と異なる。

（構成）
図１６は、ログ記録システム１の構成を表すブロック図である。ログ記録システム１は、ＥＣＵ１２００と、時刻記録装置１２３０と、ログ記録装置１２６０とを備える。ＥＣＵ１２００、時刻記録装置１２３０、ログ記録装置１２６０は、通信ネットワークバス１２８０によって接続されており相互に通信可能である。ただし図１６にはＥＣＵは１台しか記載されていないが、２台以上のＥＣＵが通信ネットワークバス１２８０に接続されてもよい。

ＥＣＵ１２００は、ＣＰＵ１２０５、メモリ１２１０、および第１インタフェース（以下、第１ＩＦ）１２２０を備える。ＣＰＵ１２０５は、第１の実施の形態で説明したＣＰＵ１１０と同様のものである。メモリ１２１０は、システムイベントバッファ１２１１を持ち、それぞれ第１の実施の形態で説明したメモリ１２０およびイベントバッファ１２６と同様のものである。第１ＩＦ１２２０は、Ｅｔｈｅｒｎｅｔ（登録商標）やＣＡＮ（ＣａｒＡｒｅａＮｅｔｗｏｒｋ、登録商標）やＦｌｅｘＲａｙ（登録商標）などの通信用のネットワークバスを介して、データの送受信を行うためのインタフェースであり、ＣＰＵ１２０５から任意のデータの送受信が可能である。

時刻記録装置１２３０は、時刻記録を目的とした装置であり、ＣＰＵ１２３５、メモリ１２４０、タイマ１２５０、および第２ＩＦ１２５５を備える。ＣＰＵ１２３５は、ＣＰＵ１２０５と同様のものである。メモリ１２４０は、システム時刻バッファ１２４１を有し、それぞれ第１の実施の形態で説明したメモリ１２０および時刻バッファ１３２と同様のものである。タイマ１２５０は、時刻値１２５１を有し、第１の実施の形態で説明したタイマ１３０および時刻値１３１と同様のものである。ただし本実施の形態では装置間を跨いだ通信も行われるため、第１の実施の形態におけるタイマ１３０の機能は、本実施の形態ではタイマ１２５０、ＣＰＵ１２３５、および第２ＩＦ１２５５により実現される。第２ＩＦ１２５５は、第１ＩＦ１２２０と同様のインタフェースであり、ＣＰＵ１２３５から任意のデータの送受信が可能である。

ログ記録装置１２６０は、ログ記録を目的とした装置であり、ＣＰＵ１２６５、メモリ１２７０、第３ＩＦ１２７５を備える。ＣＰＵ１２６５は、ＣＰＵ１２０５と同様のものである。メモリ１２７０は、イベント転写バッファ１２７１、時刻転写バッファ１２７２、およびシステム統合ログ１２７３を有する。イベント転写バッファ１２７１は、ネットワーク転送されたシステムイベントバッファ１２１１の内容を保持する。時刻転写バッファ１２７２は、ネットワーク転送されたシステム時刻バッファ１２４１の内容を保持する。システム統合ログ１２７３は、これらイベント転写バッファ１２７１および時刻転写バッファ１２７２の内容を対応付け、１つの完成したログとして統合したものである。第３ＩＦ１２７５は、第１ＩＦ１２２０と同様のインタフェースであり、ＣＰＵ１２６５から任意のデータの送受信が可能である。

図１７は、システムイベントバッファ１２１１の一例を示す図である。システムイベントバッファ１２１１には複数のレコードが格納され、その各レコードは識別子、イベント、およびイベント情報のフィールドを有する。識別子のフィールドには、イベントを特定する情報が格納される。識別子のフィールドの値は、時刻値１３１の対応関係を明らかにするために用いられる。イベントおよびイベント情報のフィールドは、第１の実施の形態において図２を参照して説明したイベントバッファ１２６のイベントおよびイベント情報のフィールドと同様である。

図１８は、システム時刻バッファ１２４１の一例を示す図である。システム時刻バッファ１２４１には複数のレコードが格納され、その各レコードは識別子、および時刻のフィールドを有する。識別子のフィールドには、システムイベントバッファ１２１１と同様にイベントが発生したＥＣＵを特定する情報が格納される。時刻のフィールドは、第１の実施の形態において図３を参照して説明した時刻バッファ１３２と同様である。

図１９は、システム統合ログ１２７３の一例を示す図である。システム統合ログ１２７３には複数のレコードが格納され、その各レコードは識別子、イベント、イベント情報、および時刻のフィールドを有する。識別子のフィールドには、システムイベントバッファ１２１１と同様にイベントが発生したＥＣＵを特定する情報が格納される。その他のフィールドは、第１の実施の形態において図４を参照して説明した統合ログ１２８と同様である。

（動作）
ログ記録対象のイベントがＥＣＵ１２００において発生した場合のログ記録システム１の動作を説明する。まず、ＥＣＵ１２００のＣＰＵ１２０５は、イベントが発生した際に、ＣＰＵ１２０５およびそのイベントを識別するための識別子を生成する。この識別子は、たとえば予め決めてあった一意となるＥＣＵ１２００の識別子とそのＥＣＵ１２００内でのイベントに対する通番を組み合わせたものである。次にＣＰＵ１２０５は、第１ＩＦ１２２０を介して、時刻記録装置１２３０に対して時刻記録の指示を表すデータを、生成した識別子とともに送信する。そして、発生したイベントの種類、イベントの情報および識別子をシステムイベントバッファ１２１１の末尾に格納する。すなわちシステムイベントバッファ１２１１には、イベントの内容がその発生順に記録される。

ＥＣＵ１２００から時刻記録指示を受信した時刻記録装置１２３０は、ＣＰＵ１２３５が時刻値１２５１を読出し、受け取った時刻記録指示に含まれる識別子とともに、システム時刻バッファ１２４１に格納する。

ＥＣＵ１２００は、システムイベントバッファ１２１１が一杯になると、その内容をログ記録装置１２６０に送信する。これを受信したログ記録装置１２６０のＣＰＵ１２６５は、これをイベント転写バッファ１２７１に格納する。時刻記録装置１２３０は、システム時刻バッファ１２４１がいっぱいになると、その内容をログ記録装置１２６０に送信する。これを受信したログ記録装置１２６０のＣＰＵ１２６５は、これを時刻転写バッファ１２７２に格納する。ログ記録装置１２６０のＣＰＵ１２６５は、イベント転写バッファ１２７１および時刻転写バッファ１２７２から同一の識別子を持つデータを抽出し、対応付けを行い、システム統合ログ１２７３に格納する。これにより、時刻情報とイベント情報が両方含まれる最終的なログが完成する。

上述した第５の実施の形態によれば、次の作用効果が得られる。
（１）ログ記録装置１２６０は、複数のイベントの内容が発生順に記録されたシステムイベントバッファ１２１１の記録情報、および複数のイベントの発生時刻が記録されたシステム時刻バッファ１２４１の記録情報を受信する第３ＩＦ１２７５と、第３ＩＦ１２７５が受信したシステムイベントバッファ１２１１の記録情報とシステム時刻バッファ１２４１の記録情報とを対応付けてログを生成するＣＰＵ１２６５と、ＣＰＵ１２６５が生成したシステム統合ログ１２７３を記録するメモリ１２７０とを備える。そのためログ記録装置１２６０は、受信したイベント情報と時刻情報を統合して記録することができる。

（２）ログ記録装置１２６０は、システムイベントバッファ１２１１の記録情報およびシステム時刻バッファ１２４１の記録情報には、イベントが発生した装置を示す識別子が含まれる。ＣＰＵ１２６５は、識別子に基づいて装置ごとに対応付けを行う。そのためログ記録装置１２６０は、複数のＥＣＵで発生したイベントのログを時刻情報と対応付けて記録することができる。

（３）ログ記録システム１は、ログ記録装置１２６０、ＥＣＵ１２００、および時刻記録装置１２３０を備える。ＥＣＵ１２００は、イベントが発生するとシステムイベントバッファ１２１１にイベントの内容を発生順に記録するＣＰＵ１２０５と、イベントが発生すると時刻記録装置１２３０に記録指令を出力するＣＰＵ１２０５と、ＣＰＵ１２０５が記録したイベントの内容をログ記録装置１２６０に送信する第１ＩＦ１２２０とを備える。時刻記録装置１２３０は、記録指令を受信すると時刻情報をシステム時刻バッファ１２４１に記録するＣＰＵ１２３５と、ＣＰＵ１２３５が記録した時刻情報をログ記録装置１２６０に送信する第２ＩＦ１２５５とを備える。そのため、タイムスタンプを取得可能なタイマのようなデバイスを持たないＥＣＵ１２００を含むシステムにおいても、タイムスタンプを含むＥＣＵ１２００で発生したイベントログを生成することができる。すなわち、タイマデバイスを備える装置を時刻記録装置１２３０の一つに集約することができる。また、時刻情報の取得等は、ＥＣＵ１２００ではなく時刻記録装置１２３０で行うため、応答性の要求されるＥＣＵ１２００の応答性を損なうことなく、ログにタイムスタンプを付加する効果が得られる。

（第５の実施の形態の変形例１）
通信ネットワークバス１２８０にＥＣＵが１台しか接続されない場合、または１台のＥＣＵのログしか記録しない場合は、ＥＣＵ１２００は識別子を生成しなくてもよい。この場合は、図１７〜図１９に示したシステムイベントバッファ１２１１、システム時刻バッファ１２４１、およびシステム統合ログ１２７３から識別子のフィールドを削除する。本変形例によれば、それぞれのメモリの消費量およびネットワークを介した通信量を削減することができる。

（第５の実施の形態の変形例２）
上述した実施の形態では、ＥＣＵ１２００からログ記録装置１２６０へのシステムイベントバッファ１２１１の転送、および時刻記録装置１２３０からログ記録装置１２６０へのシステム時刻バッファ１２４１の転送の契機をそれぞれのバッファがいっぱいになったタイミングとした。しかし、それぞれのＣＰＵがアイドル状態である時、また、ネットワークの通信が少ない時などに上述した転送を行ってもよい。本変形例によれば、転送処理が演算リソースやネットワークリソースを占有することによる他の処理への悪影響、具体的にはリソースを奪い合い実行の遅延を生じさせる弊害を防止できる。

（第５の実施の形態の変形例３）
ＥＣＵ１２００から時刻記録装置１２３０への時刻記録の指示と、システムイベントバッファ１２１１およびシステム時刻バッファ１２４１の転送とを異なるネットワークにより実現してもよい。たとえば、時刻記録装置１２３０からログ記録装置１２６０に対する通信において、ＲＤＭＡと呼ばれる機能を備えたネットワークインタフェースを用いることで、ログ記録装置１２６０の時刻転写バッファ１２７２あるいはシステム統合ログ１２７３に対して直接転送を行う。そしてＥＣＵ１２００から時刻記録装置１２３０への時刻記録の指示には異なるネットワークインタフェースを用いる。これにより、ネットワークの特性を生かした構成とすることができる。

（第５の実施の形態の変形例４）
ＥＣＵ１２００、時刻記録装置１２３０、ログ記録装置１２６０を独立した装置として記述したが、これらのうち２つが実際には同一の装置であってもよい。これにより、特にログの量が比較的少ない場合に、システムのコストを削減できる効果が得られる。

（第５の実施の形態の変形例５）
識別子はイベントが発生したＥＣＵのみを特定するものでもよい。換言すると、同一のＥＣＵにおいて発生したイベントは識別子により識別できなくてもよい。イベントは発生した順番に記録され、ＥＣＵごとに発生したイベントの順番でシステム時刻バッファ１２４１とシステムイベントバッファ１２１１とを対応付けることができるからである。本変形例によれば、それぞれのＥＣＵにおいて識別子が固定値となるので識別子を随時生成する必要がなくなり、処理を高速化することができる。

プログラムは不図示のＲＯＭに格納されるとしたが、プログラムはメモリ１２０に格納されていてもよい。また、ＥＣＵ１００が不図示の入出力インタフェースを備え、必要なときに入出力インタフェースとＥＣＵ１００が利用可能な媒体を介して、他の装置からプログラムが読み込まれてもよい。ここで媒体とは、たとえば入出力インタフェースに着脱可能な記憶媒体、または通信媒体、すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号、を指す。また、プログラムにより実現される機能の一部または全部がハードウエア回路やＦＰＧＡにより実現されてもよい。

上述した各実施の形態および変形例は、それぞれ組み合わせてもよい。上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

１…ログ記録システム
１２１…ログ記録部
１２６…イベントバッファ
１２７…時刻転写バッファ
１２８…統合ログ
１３０、１２５０…タイマ
１３２…時刻バッファ
１３３…時刻取得トリガ
１３４…ＤＭＡエンジン
７２３…直接統合ログ
７３５…転送先アドレス
１０３４…トリガ信号ポート
１０４０…出力信号ポート
１２１１…システムイベントバッファ
１２３０…時刻記録装置
１２４１…システム時刻バッファ
１２６０…ログ記録装置
１２７１…イベント転写バッファ
１２７２…時刻転写バッファ
１２７３…システム統合ログ
１２８０…通信ネットワークバス

Claims (9)

1. 記録指令に基づきイベントの発生時刻を第１の記憶領域に記録するタイマと、
   前記イベントが発生すると前記イベントの内容を第２の記憶領域に記録するとともに前記タイマに前記記録指令を出力する演算部と、
   前記イベントの内容と前記イベントの発生時刻との対応付けを行う対応付け部とを備える演算装置。
2. 請求項１に記載の演算装置において、
   前記タイマは、前記イベントの発生時刻を前記第１の記憶領域に発生した順番に記録し、
   前記演算部は、前記イベントの内容を前記第２の記憶領域に発生した順番に記録し、
   前記対応付け部は、記録された順番に基づき前記イベントの発生時刻と前記イベントの内容とを対応付ける演算装置。
3. 請求項１に記載の演算装置において、
   前記タイマは、
   前記記録指令を受けた時間が前記イベントの発生時刻として記録されるローカル記憶部と、
   前記ローカル記憶部に記録された前記イベントの発生時刻を前記第１の記憶領域に転記する転記部とを備え、
   前記転記部は、前記ローカル記憶部の空き容量が所定の容量以下になると前記転記を行い、前記ローカル記憶部から前記イベントの発生時刻を消去する演算装置。
4. 請求項３に記載の演算装置において、
   前記対応付け部は、前記転記部による前記転記が行われると前記対応付けを行い、前記第１の記憶領域に記録された前記イベントの発生時刻および前記第２の記憶領域に記録された前記イベントの内容を消去する演算装置。
5. 請求項１に記載の演算装置において、
   前記第１の記憶領域と前記第２の記憶領域は同一の物理メモリ内に確保され、
   前記タイマは、
   前記記録指令を受けた時間が前記イベントの発生時刻として記録されるローカル記憶部と、
   前記ローカル記憶部に記録された前記イベントの発生時刻を前記第１の記憶領域に転記する転記部とを備え、
   前記対応付け部は、前記転記部が前記イベントの発生時刻を書き込む前記第１の記憶領域内の詳細な位置を前記転記部に指定することで前記対応付けを行う演算装置。
6. 請求項１に記載の演算装置において、
   前記タイマは前記記録指令を受け付けるトリガ入力部を備え、
   前記演算装置は、前記トリガ入力部へ前記記録指令を出力する指令出力部をさらに備え、
   前記演算部は、前記指令出力部を介して前記タイマに前記記録指令を出力する演算装置。
7. 複数のイベントの内容が発生順に記録された第１情報、および複数のイベントの発生時刻が記録された第２情報を受信する通信部と、
   前記通信部が受信した前記第１情報と前記第２情報とを対応付けてログを生成する対応付け部と、
   前記対応付け部が生成した前記ログを記録する記憶部とを備えるログ記録装置。
8. 請求項７に記載のログ記録装置において、
   前記第１情報および前記第２情報には、イベントが発生した装置を示す識別子が含まれ、
   前記対応付け部は、前記識別子に基づいて装置ごとに前記対応付けを行うログ記録装置。
9. 制御装置、時刻記録装置、および請求項７に記載のログ記録装置を備えるログ記録システムであって、
   前記制御装置は、
   イベントが発生すると前記イベントの内容を発生順に記録するイベント記録部と、
   イベントが発生すると前記時刻記録装置に記録指令を出力する記録指令部と、
   前記イベント記録部が記録した前記イベントの内容を前記第１情報として前記ログ記録装置に送信する制御装置通信部とを備え、
   前記時刻記録装置は、
   前記記録指令を受信すると時刻情報を記録するタイマと、
   前記タイマが記録した前記時刻情報を前記第２情報として前記ログ記録装置に送信する時刻記録装置通信部とを備えるログ記録システム。
   

Images