JP2020034510A - 車両用ダイアグ解析装置、車両用ダイアグデータ解析方法、及び車両用ダイアグデータ解析コンピュータプログラム - Google Patents

Abstract

【課題】車種や検査装置の機種の違い等によりダイアグデータの記録フォーマットが種々相違する場合にあっても、これを効率的に解析することができる車両用ダイアグ解析装置を提供する。【解決手段】取得したダイアグデータに使用されるバイナリコードの種類及び配列に基づいて、該ダイアグデータの記録フォーマットが、予め定められた複数の記録フォーマットのいずれであるかを判別する。また、記録フォーマットを判別済みのダイアグデータを、複数の記録フォーマットのいずれかに定められる標準記録フォーマットのダイアグデータに変換する。【選択図】図７

Description

本発明は、自動車等の車両の検査や故障診断等に用いられる車両用ダイアグ解析装置に関し、特に、車種や検査装置の機種の違い等により、それぞれ異なった記録フォーマットによって記録されたダイアグデータを取得し、これを効率的に解析できるようにした装置及び方法と、当該装置の機能をコンピュータ上にて実現するためのコンピュータプログラムに関する。

近年、自動車等の車両にも多くのコンピュータシステムが採用され、車両内のエンジン・駆動系、走行・安全系、情報系等の多数のＥＣＵ（Electronic Control Unit）として車両の各所に搭載されている。こうしたＥＣＵの搭載により、車両制御の実体は複雑化する傾向にあり、故障や検査異常発生時の原因を的確に把握することが困難になってきている。

この問題を解決するために近年、車両や検査機器には、ＣＡＮ（Controller Area Network）等の車載通信により車載機器の作動データをダイアグデータとして通信により取得し記録媒体に記録・蓄積するとともに、その記録内容を閲覧可能に出力するダイアグ記録装置が搭載されている。車両の検査員やサービスマン等は、上記ダイアグ記録装置に記録されているダイアグデータを、例えば特許文献１及び２に開示されているような解析装置により、ＩＣカード等の着脱式記憶媒体を経由して、あるいは無線ないし有線の通信により取得し、内容解析することにより、車両の検査情報、故障情報あるいはメンテナンスのための各種情報を把握することができる。

ところで、上記ダイアグ記録装置に記録されるダイアグデータの記録フォーマットは、車種や検査装置の機種の違い等により異なる場合があり、さらには同一機種であっても、ダイアグデータを記録する通信方式により異なる場合がある。そのため、取得したダイアグデータの内容を解析しようとした場合、ダイアグデータの記録フォーマットを予め把握しておく必要がある。例えば特許文献１には、車載機器の作動状況を記述した実データ情報部に対し、当該実データ情報部の記録形式やデータ配列等の記録フォーマットを記述したヘッダ部をその都度作成し、これを添付した形でダイアグデータとして記録する装置が開示されている。また、特許文献２には、車両メーカごとにフォーマットされた故障データを車両メーカ間で統一されたフォーマットに変換し、出力する機能を備えたダイアグ記録装置が開示されている。

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

しかしながら、特許文献１の装置の場合、記録フォーマットの異なるダイアグデータについて、先頭に記録フォーマットを記述したヘッダ部を付加する処理が必要であり、ダイアグ記録装置及び内容解析装置のソフトウェアの大幅な設計変更を余儀なくされる問題がある。また、特許文献２の装置は、車両メーカ間で統一された記録フォーマットとしてテキスト形式が採用されている点に大きな問題がある。すなわち、記録装置固有のバイナリコードで記述されたダイアグデータを不用意にテキスト変換すると、文字化けを起こしたり意図通りの出力内容にならなかったりするなど、解析出力内容に不具合が多発するおそれがある。

本発明者は、記録フォーマットの異なるダイアグデータの解析を行うに際して、ダイアグデータに使用されるバイナリコードの種類や配列に、個々の記録フォーマットに固有の特徴が表れる点に着目した。そして、取得するダイアグデータが、予め定められた（すなわち、既知の）複数の記録フォーマットのいずれかにより記述されていることが判明していれば、それら記録フォーマット間のバイナリコード列の特徴比較により、ダイアグデータ内に記録フォーマットの種別特定を意図した情報が含まれていなくとも、取得したダイアグデータの記録フォーマットの特定が可能となることを見出し、本発明を完成するに至ったものである。

本発明の課題は、新たなヘッダ部の組み込み等を行なわなくとも、バイナリコードで記述されたダイアグデータの記録フォーマットの判別が可能であり、ひいては車種や検査装置の機種の違い等によりダイアグデータの記録フォーマットが種々相違する場合にあっても、これを効率的に解析することができる車両用ダイアグ解析装置、車両用ダイアグデータ解析方法、及びコンピュータプログラムを提供することにある。

上記の課題を解決するために、本発明の車両用ダイアグ解析装置は、車載機器に作動事象が発生するに伴い通信により取得される作動データを、前記作動データを取得した時刻である取得時刻データと対応付けたダイアグデータとして記録するダイアグ記録装置から、予め定められた複数の記録フォーマットのいずれかにより該ダイアグ記録装置に固有のバイナリコードを用いて記述されたダイアグデータを取得するダイアグデータ取得部と、取得した前記ダイアグデータに使用される前記バイナリコードの種類及び配列に基づいて、該ダイアグデータの記録フォーマットを判別する記録フォーマット判別部と、前記記録フォーマットの判別結果に基づいて、取得した前記ダイアグデータの内容解析を行なうダイアグ解析部と、を備えたことを特徴とする。

また、本発明の車両用ダイアグデータ解析方法は、車載機器に作動事象が発生するに伴い一定長の通信フレームを単位とする形で通信により取得される作動データを、前記作動データを取得した時刻である取得時刻データと対応付けたダイアグデータとして記録するダイアグ記録装置から、予め定められた複数の記録フォーマットのいずれかにより該ダイアグ記録装置に固有のバイナリコードを用いて記述されたダイアグデータを取得するダイアグデータ取得ステップと、取得した前記ダイアグデータに使用される前記バイナリコードの種類及び配列に基づいて、該ダイアグデータの記録フォーマットを判別する記録フォーマット判別ステップと、前記記録フォーマットの判別結果に基づいて、取得した前記ダイアグデータの内容解析を行なうダイアグ解析ステップと、を備えたことを特徴とする。

さらに、本発明のコンピュータプログラムは、車載機器に作動事象が発生するに伴い一定長の通信フレームを単位とする形で通信により取得される作動データを、前記作動データを取得した時刻である取得時刻データと対応付けたダイアグデータとして記録するダイアグ記録装置から、予め定められた複数の記録フォーマットのいずれかにより該ダイアグ記録装置に固有のバイナリコードを用いて記述されたダイアグデータを取得するダイアグデータ取得ステップと、取得した前記ダイアグデータに使用される前記バイナリコードの種類及び配列に基づいて、該ダイアグデータの記録フォーマットを判別する記録フォーマット判別ステップと、前記記録フォーマットの判別結果に基づいて、取得した前記ダイアグデータの内容解析を行なうダイアグ解析ステップと、をコンピュータに実行させることを特徴とする。

本発明によると、取得したダイアグデータの記録フォーマットの種別が一旦特定されてしまえば、当該記録フォーマットに準拠した解析装置により、ダイアグデータを構成するバイナリコードは不具合なくデコードが可能となり、正確な内容把握が常に容易となる。よって、車種や検査装置の機種の違い等によりダイアグデータの記録フォーマットが種々相違する場合にあっても、これを効率的に解析することができる。

本発明の一実施形態である車両用ダイアグ解析装置を車両に接続した状態で示すブロック図。 ダイアグ記録装置を搭載した検査装置を車両に接続した状態で示すブロック図。 ダイアグ解析ソフトウェアの主処理の流れを示すフローチャート。 第一の記録フォーマットおよび第二の記録フォーマットによる各ダイアグデータの例を示す図。 記録フォーマット判別処理の流れを示すフローチャート。 記録フォーマット変換処理の流れを示すフローチャート。 記録フォーマット変換処理の各ステップの説明図。 第一の記録フォーマットに使用されるログフレームの構造を示す模式図。 フレーム分割する場合の先頭フレームの識別ステータス部を示す模式図。 記録フォーマット変換による作動データの変化を示す説明図。 記録フォーマット変換後のダイアグデータの解析処理の流れを示すフローチャート。 第一の記録フォーマットで記述され、ダイアグ通信規格の互いに異なるダイアグデータの例を示す図。 図１１の送信行解析の詳細を示すフローチャート。 通信規格判別データベースの例を示す模式図。 機器種別対応関係データベースの例を示す模式図。 有効データと機能種別特定データをなすＭｏｄｅ/ＳＩＤとの関係を示す説明図。 機能特定データベースの例を示す模式図。

以下、本発明を実施するための形態を添付の図面に基づいて説明する。
図１は、本発明の一実施形態である車両用ダイアグ解析装置５０を自動車７０（車両）に接続した状態で示すブロック図である。まず、自動車７０にはダイアグ記録装置７２が搭載されている。自動車７０には、電子機器として構成され予め定められた自動車機能を担う複数の車載機器７５が搭載され、ＥＣＵ７３によりその作動が制御される。車載機器７５は、例えばエアバッグ、ブレーキ、ランプ、ソナー、パワーウィンドウ、ブラインドスポットモニターなど多数あり、当然、これらに限られるものではない。また、ＥＣＵ７３は１個のみを描いているが、機能の異なる複数のＥＣＵ（例えば、ボデー系ＥＣＵ、エンジン系ＥＣＵ、情報系ＥＣＵなど）に分割されていてもよい。

ダイアグ記録装置７２は、車載通信（本実施形態では、例えばＣＡＮとする）のシリアル通信バス６２を介して各車載機器７５の作動情報を取得する。この通信機能のプラットフォームは通信ファームウェア７２ａにより構築される。そして、取得した作動データは取得時刻データと対応付けてダイアグデータとされ、ダイアグデータ記憶部７２ｃに時系列順に記憶される。このダイアグデータの記録機能（ダイアグ記録機能）はダイアグ記録システムソフトウェア７２ｂの実行により実現されるものである。

一方、図２に示すように、ダイアグ記録装置７２は検査装置７４に搭載することもできる。検査装置７４は装置側コネクタ６３’を有し、自動車側コネクタ７１に接続して使用される。検査装置７４は検査項目別に定められた通信スケジュールに従い、検査対象となる車載機器を検査モードで作動させるための作動要求をＥＣＵに送信する。ＥＣＵはこれを受信し、検査対象となる車載機器を作動要求データの内容に従い作動させるとともに作動データを作成して検査装置７４に返す。検査装置７４は、作動要求の送信ログと自動車７０からの作動データの受信ログとをセットにし、それぞれログ取得時刻と対応付けたダイアグデータとしてダイアグ記録装置７２に記録させる。

ダイアグデータは、ダイアグ記録装置７２の機種に固有のバイナリコードを用いて記述されるものであり、各機種に固有の記録フォーマットを有している。このダイアグデータのバイナリデータをデコードせず物理層レベルで出力すると、ダイアグログを構成する各フィールド（格納領域）の切れ目すらも判然としない１６進コードの羅列が得られるのみであり、装置の利用者はその内容を直接把握するのが困難である。当然、当該ダイアグデータがどのような記録フォーマットで記述されているのかも把握することができない。車両用ダイアグ解析装置５０は、記録フォーマットが判明していない。そのようなダイアグデータに使用されるバイナリコードの種類及び配列を解析することにより、該ダイアグデータの記録フォーマットを判別・特定し、その特定された記録フォーマットに従いダイアグデータをデコードすることにより、装置利用者が容易に把握できる形態に変換し出力する機能を担う。

図１に示すように、車両用ダイアグ解析装置５０はダイアグ記録装置７２に接続して使用される。車両用ダイアグ解析装置５０は装置側コネクタ６３を備え、これを自動車側コネクタ７１に接続することにより、該自動車７０に搭載されたダイアグ記録装置７２内のダイアグデータの解析が可能となる。一方、図２の検査装置７４を用いる場合は、検査用のダイアグデータの記録が終了すれば装置側コネクタ６３’を自動車側コネクタ７１から取り外し、車両用ダイアグ解析装置５０の装置側コネクタ６３につなぎ代えることで検査装置７４に搭載されたダイアグ記録装置７２内のダイアグデータの解析が可能となる。なお、図２においても車両用ダイアグ解析装置５０はダイアグ記録装置７２に接続される。

ダイアグ記録装置７２に搭載されるダイアグ記録システムソフトウェア７２ｂは、自動車７０や検査装置７４の形式によりバージョンが相違し、ダイアグデータの記録フォーマットも異なるものとなる。そして、この記録フォーマットの種類は、車種や検査装置の種別に応じ、予め定められた複数のフォーマットのいずれかであることが判明しているものとする。

以下、車両用ダイアグ解析装置５０の構成及び作動の説明に入る前に、本実施形態に関係するダイアグデータの記録フォーマットについて詳細に説明しておく。まず、ＥＣＵからの作動データ取得に使用される車載通信のプロトコル規格は、標準的な車載通信に使用されるシリアル通信プロトコル規格において、通信フレーム長が一定に定められている。ＣＡＮ通信では通信フレーム内のデータフィールドの長さは８バイトに固定されている。その結果、作動データの送受信は上記８バイトのデータフィールド長を単位とする形でやりとりされることとなる。

これを反映して、ダイアグ記録装置７２が採用するダイアグデータの記録フォーマットには、次の２つのいずれかが採用されているものとする。いずれも、取得時刻データと作動データとが一対一に対応付けられたダイアグログ行を時系列順に配列したものとして記述される。
（１）第一の記録フォーマット（本実施形態では、「ＦＯＲＭＡＴ１」と称する）
この記録フォーマットでは、１つの作動事象を記述するダイアグデータが上記の通信フレーム単位で記録される。そして、１つの作動事象、例えば１つの検査イベントで自動車側から取得される作動データのサイズが、１つの通信フレームにて送信許容される規定データ長を超える場合に、ダイアグデータをフレーム単位で分割した形で記録する方式である。この記録フォーマットは、通信フレームを送受信するごとに、当該通信フレームの内容をログフレームとして順次記録してゆけばよいので、ダイアグデータ記録の処理負荷が低い利点があり、特に多くの車両や検査装置に採用されているものである。ただし、１つの作動事象において発生する作動データのサイズが大きい場合は、同じ作動事象の作動データであるにも関わらず分割して記録されることとなり、作動データ抽出や集約といった解析処理の負荷が増大する欠点がある。

（２）第二の記録フォーマット（本実施形態では、「ＦＯＲＭＡＴ２」と称する）
この記録フォーマットでは、１つの作動事象に対応する作動データ、例えば１つの検査イベントで自動車側から取得される作動データを、通信フレームの規定データ長（具体的には８バイト）と無関係に１行に集約して記録するものである。この記録フォーマットは、作動データのサイズが大きい場合は、複数フレームに分散した作動データを各フレームから抽出して集約する処理が必要であり、ダイアグデータ記録の処理負荷は上記の第一の記録フォーマットを採用する場合より大きい。しかし、１つの作動事象の作動データは、サイズと無関係に１行に集約して記録されるため、解析処理負荷は大幅に減じられる。その解析の利便性から、近年、検査効率の向上を図るため（１）に準じて普及が進みつつある。

図４の符号１００は、第一の記録フォーマットであるＦＯＲＭＡＴ１のダイアグデータの一例を示すものである。該ダイアグデータは表計算ソフトウェア等でのデータの取り扱いが容易となるように、ＣＳＶ（Community Service Volunteer）ファイル形式にて記述されている。送受信のダイアグログ行１０１は、ＣＳＶの先頭列から順に、行番号（Ｎｏ．）、送受信時刻あるいはダイアグログの取得時刻（ｈｈ：ｍｍ：ｓｓ）、送受信種別（送受信）、エラーコード（エラー）、通信フレーム種別（種類）、ＣＡＮ＿ＩＤ（ＩＤ）、データ長（Ｌｅｎ）、作動データ（データ）、相対時間［作動事象開始を時間原点とする時刻情報］（相対時間）の各構成データ要素のフィールドからなる。また、１行目はフィールド名を注釈するコメント行１０２とされている（上記（）内がコメント行内での要素名を示す）。なお、このコメント行は、ＦＯＲＭＡＴ１（第一の記録フォーマット）のダイアグデータをＦＯＲＭＡＴ２（第二の記録フォーマット）のダイアグデータに変換する際は余剰データ部分となり、削除の対象とされる。

このうち、行番号、時刻情報及び相対時間はダイアグ記録装置側で追加されるものであるが、それ以外の構成データ要素は、ＣＡＮ通信の通信フレーム内のフィールド構造を引き継いだものとなっている。具体的には以下の通りである。
・送受信フィールド：ＣＡＮ通信では、データを必要とするノードからリモートフレームが送信され、そのデータを持ったノードからデータフレームを返すことで通信を行なう。なお、リモートフレームのデータフィールドには、例えば検査時において、ＣＡＮ＿ＩＤが指定する車載機器に特定の作動を指定する作動要求データが格納されるが、本明細書ではこの作動要求データも広義に「作動データ」に属するものとみなす。ＣＡＮ通信フレームは、これに含まれるＲＴＲ（Remote Transmission Request）フィールドのビット情報が「０（ドミナント）」のときデータフレーム、同じく「１（レセシブ）」のときリモートフレームとなる。スレーブノードであるダイアグ記録装置からみた場合、作動データの「要求」をマスターノードであるＥＣＵに送信するときにリモートフレームが使用され、その作動データをマスターノードからの「応答」として受信するときはデータフレームが使用されることが、ＣＡＮプロトコルから自明に定まる。よって、ダイアグログ行の送受信フィールドの内容は、ＣＡＮ通信フレームのＲＴＴフィールドの値が「１」のとき「要求（送信）」に設定され、「０」のとき「応答（受信）」が設定される。

・エラーフィールド：データフレームの受信ないしリモートフレームの送信時に何らかの異常によりエラーが発生した場合、ＣＡＮ通信では、それらデータフレームないしリモートフレームに続いてエラーフレームがＣＡＮコントローラから送信される。そして、ダイアグ記録装置が「要求」ないし「応答」の際にエラーフレームを受信したとき、ダイアグログ行のエラーフィールドの内容はエラーの発生を示す値（例えば「１」）が設定される。

・通信フレーム種別フィールド：作動データのサイズが規定データ長を超え、単一のフレームではオーバーフローする場合に、ダイアグ記録装置は複数のデータフレームに分割して受信する。これに関連して、作動データを含んだデータフレームの受信と、当該データフレームの送信要求に関し、通信フレームは図８に示す４種類のフレームが使い分けられるのであるが、その種別を特定するためのフレーム種別特定データが格納される。ＣＡＮ通信のデータフィールドでは、その先頭の１バイトが通信フレーム種別の特定に使用されるので、その値を引き継いだ内容が該通信フレーム種別フィールドに格納される。なお、該通信フレーム種別フィールドは、ＦＯＲＭＡＴ１からＦＯＲＭＡＴ２に変換する際に余剰データ部分となり、削除の対象とされる。各フレームの詳細は以下の通りである。

（１）シングルフレーム（ＳＦ）：作動データをＥＣＵから受信する際に該作動データのサイズが規定データ長範囲内となる場合のデータフレーム、及び作動データをＥＣＵに要求する際のリモートフレームに使用される。作動データの受信に使用する場合、データフィールド長は８バイトであるが、先頭の1バイトはフレーム識別ステータス(Ｎ＿ＰＣＩ: Protocol Control Interface）に割り振られるので、作動データの格納に使用できるのは最大で７バイトとなる。よって、１回の受信で取得可能な作動データの規定データ長は７バイトとなる。また、作動データのサイズが規定データ長よりも少なく、データフィールドの終端側に余剰バイトが生ずる場合はヌルコードが格納されるが、該ヌルコードは、ＦＯＲＭＡＴ１からＦＯＲＭＡＴ２に変換する際に余剰データ部分となり、削除の対象とされる。

（２）ファーストフレーム（ＦＦ）：作動データのサイズが規定データ長以上のとき、これを分割受信するときのデータフレーム群のうち、その最初（先頭）に送信されるものに使用される。また、作動データの全サイズが８フレーム分割での許容データサイズを超えるときは、８フレームごとに送信を区切る目的でも随時挿入して使用される。ＦＦでは、先頭の２バイトがＮ＿ＰＣＩに割り振られるので、作動データの格納に使用できるのは最大で６バイトとなる。

（３）コンセクティブトフレーム（ＣＦ）：作動データのサイズが規定データ長以上のとき、これを分割送信するためのデータフレーム群のうち、ファーストフレームに続いて送信されるものに使用される。ＣＦのデータフィールドは、先頭の２バイトがＮ＿ＰＣＩに割り振られるので、作動データの格納に使用できるのは最大で７バイトとなる。また、１つの作動事象の作動データ送信の最後に送信されるＣＦ（又はＦＦ）のデータフィールドの終端側に余剰バイトが生ずる場合はヌルコードが格納されるが、このヌルコードもＦＯＲＭＡＴ１からＦＯＲＭＡＴ２に変換する際に余剰データ部分となり、削除の対象とされる。

（４）フローコントロール（ＦＣ）：これは、スレーブノード（ダイアグ記録装置）側でデータフレーム等を受信し、その格納処理等のために後続のデータフレームの受信が不能となっている場合、マスターノードに次のデータフレームの送信を待たせるために送られるリモートフレームである。ＣＦのデータフィールドは、先頭の３バイトがＮ＿ＰＣＩに割り振られ、後続の５バイトにはヌルコードが設定される。ＦＣは、その全体がＦＯＲＭＡＴ１からＦＯＲＭＡＴ２に変換する際の余剰データ部分となり、削除の対象とされる。

図９は、フレーム識別ステータス(Ｎ＿ＰＣＩ）の構造をファーストフレーム（ＦＦ）の場合を例にとって示すものである。フレーム識別ステータスの先頭の４ビットがフレーム種別の特定に使用される。本実施形態では、ＳＦが「００００」、ＦＦが「０００１」、ＣＦが「００１０」及びＦＣが「００１１」として定められている。Ｎ＿ＰＣＩは、ＦＯＲＭＡＴ１からＦＯＲＭＡＴ２に変換する際に余剰データ部分となり、削除の対象とされる。

以下、ＦＯＲＭＡＴ１の構成データ要素の説明に戻る。
・ＣＡＮ＿ＩＤフィールド：ＣＡＮ通信フレームのＩＤフィールドの記述内容を引き継いでいる部分であり、取得する作動データの機器種別特定データの主要部分をなす。ＣＡＮ通信フレームのＩＤフィールドは、ＳＯＦ（Start Of Frame）ビットに続く最初のフィールドとして定められており、データ内容や送信ノードの識別、通信調停の優先順位などを決定する部分として記述される。

・データ長フィールド：ＣＡＮ通信フレームのコントロールフィールドにおいて、データレングスコード（DLC）の内容を引き継いでいる部分であり、ＦＯＲＭＡＴ１においては８ビットに内容が固定されている。該データ長フィールドは、ＦＯＲＭＡＴ１からＦＯＲＭＡＴ２に変換する際に余剰データ部分となり、削除の対象とされる。

・データフィールド：ＣＡＮ通信フレームのデータフィールドの内容を引き継いだ部分である。フレーム種別に応じて先頭の１〜３バイトがフレーム識別ステータス（Ｎ＿ＰＣＩ）に使用されるほか、機器種別によっては、これをより的確に分類するために、ＣＡＮ＿ＩＤにさらに分類補助バイナリコード（後述のＮ＿ＴＡ：Network Target Adress）を付加したものが機器種別特定データとして使用される場合がある（すなわち、機器種別に応じてバイナリコード割当数が複数種類に設定される）。この分類補助バイナリコードが付与される場合は、データフィールドの先頭側にてＮ＿ＰＣＩに続く１バイトが該分類補助バイナリコードに割り振られる。この場合、作動データを実質的に格納可能な領域は、データフィールドからフレーム識別ステータス及び分類補助バイナリコードを除いた残余の領域のみとなる。

ＦＯＲＭＡＴ１における上記の各フィールドは、ＣＡＮ通信フレームのデータフィールドの内容を引き継いでいる関係上、データフィールドも含め、ＣＳＶ形式において全て決められたデータ長に設定されており、コメント行の対応フィールドも同じ列幅に定められるとともに、含まれる文字列（固有文字列）の種類も常に一定である。ＦＯＲＭＡＴ１（第一の記録フォーマット）において、このコメント行は必ず先頭に配置される、という点が重要である。

次に、図４の符号２００は、第二の記録フォーマットであるＦＯＲＭＡＴ２のダイアグデータの一例を示すものである。この記録フォーマットにおいてもダイアグデータはＣＳＶファイル形式にて記述されている。ＦＯＲＭＡＴ２はＦＯＲＭＡＴ１と異なり、コメント行を有さない。その理由は、作動データが行分割されずに１行に集約してダイアログ行に組み込まれるため作動データ長が一定でないこと、ＦＯＲＭＡＴ１に含まれるフィールドのうち、ダイアグログ解析に特に不要と考えられるもの（具体的には、行番号、フレーム種別、データ長の各フィールド）が省略され、ダイアグログ行のフィールド数（構成データ要素）が大幅に削減されているため、特にコメント行がなくても解析内容を把握しやすいことに起因する。すなわち、ＣＡＮ通信のフレーム構造は（特に、作動データ部分には）引き継がれていないといえる。

その結果、ＦＯＲＭＡＴ２の送受信のダイアグログ行２０１は、ＣＳＶの先頭列から順に、送受信時刻（ダイアグログの取得時開始ないし完了時刻）、相対時間、送受信種別、エラーコード（エラー）、ダイアグ通信規格種別（ダイアグ記録装置の機種に依存する）、ＣＡＮ＿ＩＤ＋Ｎ＿ＴＡ（機器種別特定データ）、作動データの各構成データ要素のフィールドからなる。

ＦＯＲＭＡＴ２のダイアグデータは、ＦＯＲＭＡＴ１のダイアグデータと比較したとき、フィールドの数が削減され順序も異なっている点以外に、次のように特徴的な差異がある。
（１）１つの作動事象に対応する作動データ、例えば１つの検査イベントで自動車側から取得される作動データを、通信フレームの規定データ長（具体的には８バイト）と無関係に１行に集約して記録されている。また、ＣＡＮ通信フォーマットのデータフィールドの内容を単純に引き継ぐのではなく、前述したＮ＿ＰＣＩやヌルコードを全て削除するとともに、機器種別特定データに属するデータバイト（特に、補助分類コードをなすＮ＿ＴＡ）も分離し、実質的な作動データに属するバイナリコードのみを抽出して集約されている。
（２）機器種別特定データは、ＣＡＮ＿ＩＤ以外に、（１）で分離された補助分類コード（Ｎ＿ＴＡ）を補った形で作動データの前に置かれる。

（３）ダイアグ通信規格種別フィールドが追加されている。ダイアグデータは、作成元であるダイアグ記録装置が採用するダイアグ通信規格が複数存在する（本実施形態では、「Ｓｙｓｔｅｍ１」及び「Ｓｙｓｔｅｍ２」の名称を有する２種類のいずれかであるとする）。よって、車載機器が個別に備える種々の機能を特定する、機能種別特定データと機能種別内容との対応関係も規格により相違したものとなる。具体的には、特有の番号等で表示される機能種別特定データと実際の機能名称との対応関係が、ダイアグ通信規格に依存して相違する。よって、このフィールドを参照することにより、ダイアグ通信規格の種別を特定でき、これに適合した機能特定データベース（図１７：符号５５ｈ４及び５５ｈ５）を参照することで、適切な解析が可能となる。本実施形態においては、後述のごとく、ダイアグデータの内容に基づいて、当該ダイアグデータが準拠するダイアグ通信規格の種別を判別し、その判別結果に応じてダイアグ通信規格フィールドの内容を定めるようにしている。

（４）エラーフィールド（図示せず）は、エラーフレームに含まれるエラーフラグの値をビット数の固定された形で表示する。
（５）ダイアグログ行に取り込まれる作動データは、作動事象の内容に応じてサイズが全く異なるので、行の末尾を占めるように配置される。一方、これより先頭側に配置される他のフィールドはフィールド長が固定されていることから、フォーマットの一定したヘッダ部分を構成している。よって、先頭側からこれを順次読み出したとき、何番目のコードがどのフィールドに属するかを一義的に決定できる。特に、先頭のフィールドは形式が特に一定でかつ特徴的な送受信時刻フィールドとなる。これは、ダイアグ記録装置から取得したダイアグデータが本ＦＯＲＭＡＴ２の記録フォーマットによるものであるか否かを判別する上でも重要な手がかりを与えるものである。

図１に戻り、車両用ダイアグ解析装置５０の構成について説明する。
ダイアグ解析装置５０はコンピュータハードウェアを主体に構成されるものであり、処理主体をなすＣＰＵ５１、そのワークエリアとなるＲＡＭ５２、及びＢＩＯＳ等の基本プログラムを格納したＲＯＭ５３、ダイアグ解析装置５０の基本機能を実現するためのソフトウェア（プログラム）を格納したハードディスクドライブ５５（フラッシュメモリなど、記憶内容が電気的に書換え可能であって、外部からのリセット信号を受けても当該記憶内容を保持する不揮発性メモリ構成してもよい）、入出力部５４、それらを相互に接続するバス（データバス＋アドレスバス）５６、ＣＡＮ通信規格に準拠したシリアル通信インターフェース５７、及び通信データを一時的に記憶する通信バッファメモリ５８を備える。シリアル通信インターフェース５７はＣＡＮ通信バス（ツイストペア線等で構成される通信ケーブルを含む）６２に接続され、装置側コネクタ６３及び自動車側コネクタ７１を介してダイアグ記録装置７２と接続される。

ハードディスクドライブ（ＨＤＤ）５５には、通信ファームウェア５５ａが格納されており、ＣＰＵ５１が実行することにより、シリアル通信インターフェース５７と共同してダイアグ記録装置７２からダイアグデータを通信取得する、ダイアグデータ取得部の基本機能を担う。また、取得したダイアグデータはダイアグデータ記憶部５５ｂに記憶される。なお、ダイアグ記録装置７２からのダイアグデータの取得は通信に限られるものではなく、図示はしていないが、例えば着脱式記憶デバイスを経由して取得するようにしてもよい。

一方、ＨＤＤ５５には、ダイアグ解析ソフトウェア５５ｄが格納されている。ＣＰＵ５１が実行することにより、ダイアグ解析装置５０の以下の機能が実現される。
・記録フォーマット判別部：取得したダイアグデータに使用されるバイナリコードの種類及び配列に基づいて、該ダイアグデータの記録フォーマットを判別する。本実施形態では、上述のごとく、記録フォーマットがＦＯＲＭＡＴ１（第一の記録フォーマット）とＦＯＲＭＡＴ２（第二の記録フォーマット）のいずれであるかの判別を行なう。
・フォーマット変換部：記録フォーマットを判別済みのダイアグデータを、複数の記録フォーマットのいずれかに定められる標準記録フォーマットのダイアグデータに変換する。本実施形態では、取得したダイアグデータがＦＯＲＭＡＴ１（第一の記録フォーマット）であった場合、これを標準記録フォーマットであるＦＯＲＭＡＴ２（第二の記録フォーマット）に変換する機能を担う。
・ダイアグ解析部：記録フォーマットの判別結果に基づいて、取得したダイアグデータの内容解析を行なう。
・ダイアグ通信規格判別部：ＦＯＲＭＡＴ２（第二の記録フォーマット）に変換されたダイアグデータの内容に基づいて、当該ダイアグデータが準拠するダイアグ通信規格の種別（本実施形態では、Ｓｙｓｔｅｍ１及びＳｙｓｔｅｍ２）を判別する。具体的には、ＨＤＤ５５に格納されている通信規格判別データベース５５ｆを参照して判別を行なう。
・解析実行部：機器種別対応関係データベース５５ｇ及び機能特定データベース５５ｈ（これも、ＨＤＤ５５に格納されている）を参照してダイアグデータの内容解析を実行する。なお、本実施形態においては、機能特定データベース５５ｈはダイアグ通信規格の種別に応じて互いに内容の異なるものが用意されている（図１７参照）。

また、フォーマット変換部の基本機能を担うのは、ダイアグ解析ソフトウェア５５ｄに組み込まれた記録フォーマット判別・変換ソフトウェア５５ｅである。記録フォーマット判別・変換ソフトウェア５５ｅをＣＰＵ５１が実行することにより、さらに以下の機能が実現される。
・フレーム種別判別部：ＦＯＲＭＡＴ１（第一の記録フォーマット）のログフレームに含まれるフレーム種別特定データ（前述のＳＦ、ＦＦ、ＣＦ及びＦＣ）に基づき、ログフレームが、作動データを分割する分割フレーム（すなわち、ＦＦ又はＣＦ）に該当するか否かを判別する。
・作動データ部分合成部：分割フレーム（ＦＦ又はＣＦ）と判別された複数のログフレームからフレーム種別特定データを削除しつつ作動データ部分をそれぞれ抽出し、それら作動データ部分を時系列順に直列に合成してＦＯＲＭＡＴ２（第二の記録フォーマット）の作動データとする。
・機器種別／作動データ分離抽出部：ＦＯＲＭＡＴ１（第一の記録フォーマット）のログフレーム内の機器種別特定データと作動データとを分離しつつ抽出する。

以下、ダイアグ解析装置５０の動作についてフローチャート及び図７の説明図を用いて説明する。図３は、ダイアグ解析装置５０の主処理の流れを示す。Ｓ１においては、取得したダイアグデータがすでにコンピュータ上で開かれたオープンファイルになっていないかどうかを確認する。オープンファイルの場合はＳ９に進み、エラー表示を行なって終了する。

一方、オープンファイルでなかった場合はＳ２に進み、取得したダイアグデータの読み込みを行なう。そして、Ｓ３でダイアグデータの記録フォーマットの判別を行なう（記録フォーマット判別部）。Ｓ４においては、取得したダイアグデータがＦＯＲＭＡＴ１とＦＯＲＭＡＴ２のいずれにも該当しなかった場合はエラーとなり処理を終了する。続いて、Ｓ５では、判別された記録フォーマットがＦＯＲＭＡＴ２（第二の記録フォーマット、標準記録フォーマット）であるか否かを判定する。ＦＯＲＭＡＴ２であった場合はフォーマット変換が不要であり、Ｓ７の自動解析処理（解析実行部）に進む。他方、Ｓ５において記録フォーマットがＦＯＲＭＡＴ１（第一の記録フォーマット）であった場合はＳ６に進み、記録フォーマット変換処理を実行する（フォーマット変換部）。変換が終了すればＳ７の自動解析処理（解析実行部）に進む。

Ｓ７の自動解析処理では、ＦＯＲＭＡＴ２に変換後のダイアグデータのダイアグログ行が逐次解析される。Ｓ８で最終行まで解析が完了すれば、その解析結果を図１のＨＤＤ５５内に形成された解析結果記憶部５５ｉに記憶する。記憶された解析結果は、例えばモニタ５９あるいはプリンタ６１から随時出力することで閲覧が可能となる。

図５は、記録フォーマット判別処理の詳細を示すものである。
Ｓ３１では、取得したダイアグデータの先頭行（ヘッダ行）を読み込む。ダイアグデータが、図４のＦＯＲＭＡＴ１（第一の記録フォーマット）のダイアグデータ１００であった場合、ヘッダ行はコメント行１０２となっている。コメント行は、行内の所定の文字列格納位置（具体的には決められた列位置）に各フィールド（構成データ要素）の要素名を示す、「Ｎｏ」、「ｈｈ：ｍｍ：ｓｓ」、「送受信」、「エラー」、「種類」、「ＩＤ」、「Ｌｅｎ」、「データ」あるいは「相対時間」といった固定文字列を含む。そこで、Ｓ３２では、取得されたダイアグデータの先頭行内の、上記の文字列格納位置に対応するバイナリコードを読み込み、これを文字列と仮定して、例えばＪＩＳ文字コード表等を参照してデコード（解読）する。そのデコード結果に表れる文字列の一部または全てが、上記の固定文字列と一致していれば、該先頭行をコメント行と認定し、Ｓ３４に進んで、記録フォーマットの種別はＦＯＲＭＡＴ１（第一の記録フォーマット）であると判別する。

一方、Ｓ３２において上記ヘッダ行がコメント行ではないと判断されたときはＳ３３に進む。もし該ヘッダ行が、図４におけるＦＯＲＭＡＴ２のダイアグデータのダイアグログ行２０１であった場合は、先頭の決められた数のバイナリコードは取得時刻データとなっているはずであるから、Ｓ３３でこれをデコードし、時刻データを示す文字列となるか否かを確認する。時刻データを示す文字列であればＳ３５に進み、記録フォーマットの種別はＦＯＲＭＡＴ２（第二の記録フォーマット）であると判定する。他方、Ｓ３３において時刻データを示す文字列でなかった場合はＳ３６のエラー判定を行い、図３の主処理ルーチンにリターンする。

以下、記録フォーマット変換処理の詳細を図６のフローチャートと図７を用いて説明する。まず、取得したダイアグデータは、この時点でＦＯＲＭＡＴ１のものであることが判明しているので、先頭のコメント行の削除を行ない、続いて図７(1)のデータ区分整理処理を行なう。該処理は、具体的には、ダイアグログ行から行番号フィールドを削除し、さらに８バイトのデータフィールドを構成するバイナリコード列を１バイト単位に区切る処理を行なう。次に、図６のＳ６１では、ダイアグログ行からＣＡＮ＿ＩＤフィールド内のバイナリコードを取得し、デコードして内容を確認する。続いて、図１５の機器種別対応関係データベース５５ｇを参照し、該ＣＡＮ＿ＩＤが、末尾に分類補助バイナリコードであるＮ＿ＴＡ（Network Target Adress）が付与されているか否かを確認する。例えば、ＣＡＮ＿ＩＤが図１５において７５０、７５８などのときは、Ｎ＿ＴＡとして「４１」が付与されていることがわかる。

上記のＮ＿ＴＡはＣＡＮ＿ＩＤフィールドではなくデータフィールドに食い込むように格納されている（例えば、図７の２行目及び４行目以下参照）。そこで、該当するＣＡＮ＿ＩＤがＮ＿ＴＡを伴う番号であった場合は、Ｓ６２においてデータフィールドの先頭バイナリコードをＮ＿ＴＡとして取得し、Ｓ６３でＣＡＮ＿ＩＤとＮ＿ＴＡとを合成し、５桁の機器種別特定データとしてＦＯＲＭＡＴ２の対応するフィールドに格納する。

次に、各ダイアグログ行の作動データの抽出処理に入る。この処理は、送信（要求）及び受信（応答）のイベントに分けて実行され、各ダイアグログ行のフレームの種別を、フレーム種別フィールドの内容（ＳＦ，ＦＦ，ＣＦ，ＦＣ）から判別する。これにより、ログフレーム先頭のＮ＿ＰＣＩのバイト数が判明する。

また、フレームがＳＦであった場合は、データフィールドの末尾のヌルコードを識別し、これを余剰コードとして除外する。他方、フレームがＦＦないしＣＦであった場合は、１つの作動事象（受信イベント）に対応する作動データが複数フレーム分割されていることを意味するので、ＳＦを介さずに連続しているＦＦ及びＣＦ（途中にＦＣが挟まっていてもよい：また、ＣＦを除いて８行ごとに挿入されるＦＦダイアグログ行も同じ作動事象に属するとみなす）の受信ダイアグログ行を識別しつつ、各行のデータフィールドからのＮ＿ＰＣＩ及びＮ＿ＴＡの識別・除外と、その最後に位置するダイアグログ行（ＣＦ又はＦＦ）のデータフィールドの終端側のヌルコードの識別・除外を各々行なう。

すなわち、各データフィールドのバイナリコードのうち、実質的に作動データ部分をなす部分（以下、有効データという）のみが抽出され、ダイアグログ行ごとにそのバイト数が計数され、図６のＳ６４でこれが有効データ長として取得される。また、Ｓ６５では該有効データ長を１０進数に変換する。続いて、Ｓ６６では、１つの作動事象に対応する受信イベントとして連続取得された一群のＦＦダイアグログ行とＣＦダイアログ行の各有効データ数を合計し、合成後の有効データのサイズ、つまり作動データの全体のサイズを演算する（以上、フレーム種別判別部の機能が実現している）。この値は、作動データ全体を格納するための記憶領域サイズの設定に使用されるほか、１０進数値により作動データサイズの情報として出力すれば、使用者が解析結果を閲覧しようとする際の参考情報となる。

次に、Ｓ６７では、１つの作動事象に対応する受信イベントとして連続取得された一群のＦＦダイアグログ行及びＣＦダイアログ行から、有効データ長算出のために除外されているＮ＿ＰＣＩ、Ｎ＿ＴＡ及びヌルコードをデータフィールドから削除して、有効データのみを抽出する（また、ＦＣダイアグログ行はその都度全体を削除する）。そして、Ｓ６８では、抽出された有効データを時系列順に合成して１行化する（作動データ部分合成部）。図１０は、変換前のＦＯＲＭＡＴ１の送信（Ｓ）及び受信（Ｒ）のデータフィールドの例と、変換後のＦＯＲＭＡＴ２の送信（Ｓ）及び受信（Ｒ）のデータフィールドの例とを比較して示すものである。ヌルコードはデータフィールドの終端側のもののみが削除されている。また、先頭の１バイトないし２バイトはＮ＿ＰＣＩ及びＮ＿ＴＡとして削除ないし分離・除外されている。さらに、変換前の２つ目の送信ログ行はＣＦであり、全体が削除されている。

その後、送受信時刻、相対時間、送受信種別、エラーコード、ダイアグ通信規格種別（ただし、この段階ではブランク）、機器種別データの各フィールドをこの順に配列し、さらに上記合成された作動データ（有効データ）を配置すればＦＯＲＭＡＴ２の記録フォーマットへの変換処理は完了する。

図１１は自動解析処理の詳細を示すものである。この処理では、ＦＯＲＭＡＴ２に変換されたダイアグデータの送信ダイアグログ行（以下、単に送信行ともいう）、及び受信ダイアグログ行（以下、単に受信行ともいう）を個別に解析する処理を行なっている。まず、Ｓ７０１では、読み込んだダイアグデータに送信行があるか否かを判断する。送信行が全くない場合は、例えば通信ケーブルの断線などが原因していることが考えられ、Ｓ７０２に進んで「応答なし」のエラー処理を行なう（表示など）。

一方、送信行が含まれていればＳ７０３に進み、送信行解析処理を行なう。図１３はその詳細を示すものであり、Ｓ７０１１では、ダイアグ通信規格種別が前述のＳｙｓｔｅｍ１とＳｙｓｔｅｍ２のいずれであるかを判別する処理を行なう。これは、図１４の通信規格判別データベース５５ｆを参照して実施される。図１２は、記録フォーマットがＦＯＲＭＡＴ１の場合の、Ｓｙｓｔｅｍ１のダイアグデータ１００Ａと、同じくＳｙｓｔｅｍ２のダイアグデータ１００Ｂとを示すものである。データ構造は全く同じであるが、データフィールドのエンコード方式が異なり、対応するダイアグ通信規格に適合しないデコードを実行すると、まったく意味の分からない解析結果が出力されてしまうことになる。その主要な相違点は、車載機器の機器種別の下位に定められる個々の機器の機能種別の分類構造、すなわち、機能種別特定データと機能種別内容との対応関係が相違していることにある。図１５は、機器種別特定データであるＣＡＮ＿ＩＤと車載機器種別との対応関係を示す機器種別対応関係データベース５５ｇを示すものであり、これはＳｙｓｔｅｍ１とＳｙｓｔｅｍ２のダイアグ通信規格において共通に用いられる。一方、図１７の上に示すのは、Ｓｙｓｔｅｍ１の機能特定データベース５５ｈ４を、同じく下はＳｙｓｔｅｍ１の機能特定データベース５５ｈ５を示すものである。機能特定データは、前者においては「ｍｏｄｅ」と称され、後者においては「ＳＩＤ」と称される。いずも、同一の機能特定データ列に対応する機能種別内容を抜き出して表示しているが、具体的な機能種別内容と「ｍｏｄｅ」ないし「ＳＩＤ」との対応関係は２つのダイアグ通信規格で全く異なっていることがわかる。

この機能特定データは、作動データの先頭の１バイトとして組みこまれているものである。しかし、ＦＯＲＭＡＴ１の記録フォーマットでは、データフィールドにＮ＿ＰＣＩやＮ＿ＴＡが挿入されつつ、作動データが複数行に分散して記録されているので、手掛かりとなる「ｍｏｄｅ」ないし「ＳＩＤ」（機能特定データ）の特定は非常に面倒になる。

しかし、余剰データが削除され送受信ごとに作動データが１行化されているＦＯＲＭＡＴ２の記録フォーマットであれば、図１６に示すように、その先頭のバイナリコードにより「ｍｏｄｅ」ないし「ＳＩＤ」（機能特定データ）を容易に把握することができる。図１４の通信規格判別データベース５５ｆには、２つ（複数）のダイアグ通信規格（Ｓｙｓｔｅｍ１とＳｙｓｔｅｍ２）の機能特定データ（「ｍｏｄｅ」ないし「ＳＩＤ」）の種類ごとに、それがどの通信規格で採用されているか否か、共通に使用されている場合は、その場合の複数の判別条件を示す情報などが網羅されている。例えば、機能特定データの内容が「２１〜３３」についてはＳｙｓｔｅｍ１の「ｍｏｄｅ」としてのみ使用されており、「４１〜４６」についてはＳｙｓｔｅｍ２の「ＳＩＤ」としてのみ使用されていることがわかる。よって、これらは固有特定データとして把握することができ、ダイアグデータから抽出された機能特定データにこれら固有特定データが含まれる場合は、通信規格判別データベース５５ｆを参照することにより、当該ダイアグデータがＳｙｓｔｅｍ１のものであるかＳｙｓｔｅｍ２のものであるかを直ちに把握することができる。

一方、通信規格判別データベース５５ｆの残余の機能特定データはＳｙｓｔｅｍ１とＳｙｓｔｅｍ２とに共通に使用される共通特定データである。この場合は機能特定データの内容のみでは、ダイアグ通信規格がいずれであるかを把握することができない。例えば、機能特定データが「０４、０９、０Ａ」となっている場合については、それらの機能特定データがダイアグデータに使用される時のＣＡＮ＿ＩＤ（機器特定データ）の内容が、上記２つのダイアグ通信規格において排他的である点が、規格種別の判別に有効に利用できる。具体的には、上記３つの機能特定データは、Ｓｙｓｔｅｍ１においてはＣＡＮ＿ＩＤが７ＤＦとなっている場合にのみ出現し、他方Ｓｙｓｔｅｍ２ではＣＡＮ＿ＩＤが７ＤＦ以外のものになっている場合にのみ出現する。よって、ＣＡＮ＿ＩＤの値を参照し、その値が７ＤＦであればＳｙｓｔｅｍ１、それ以外の値であればＳｙｓｔｅｍ２として判定が可能である。つまり、共通特定データが使用される車載機器の種別によってダイアグ通信規格の種別が判定されている。

一方、機能特定データが「１０」または「１４」の場合は、その送信行に対する受信行（応答）の内容が正常応答となっていることを前提として、応答行に含まれる作動データのサイズ（バイト数）がＳｙｓｔｅｍ１とＳｙｓｔｅｍ２との間で排他的となっていることで判別可能となることを示している。同様に、機能特定データが「３Ｅ」の場合は、
・送信行による要求内容が「３Ｅ０１」の時の応答内容の否定／肯定が排他的であること、または、
・その要求内容に対する応答内容が正常応答となっていることを前提として、応答に含まれる作動データのサイズ（バイト数）がＳｙｓｔｅｍ１とＳｙｓｔｅｍ２との間で排他的となっていること、
のいずれかの条件により判別可能となることを示している。いずれも、取得される作動データのサイズないし車載機器側からの応答内容に基づくダイアグ通信規格の種別判別がなされることとなる。

図１３に戻り、上記の判定条件によりダイアグ通信規格の種別が把握できれば、変換後のＦＯＲＭＡＴ２のダイアグデータの対応するダイアグログ行の、ブランクとなっている通信規格種別フィールドを上記判別結果により補充する。そして、Ｓ７０１２に進み、機器特定データから作動対象となる車載機器を把握し、Ｓ７０１３で機能特定データ（Ｓｙｓｔｅｍ１の場合は「ｍｏｄｅ」、Ｓｙｓｔｅｍ２の場合は「ＳＩＤ」）を特定するとともに、図１７に示す機能特定データベース５５ｈ４及び５５ｈ５のうち、把握されたダイアグ通信規格に対応するものを参照して、特定された機能特定データに対応する機器機能を把握するとともに、応答行の作動データの内容をデコードして内容を解析する。

図１１に戻り、Ｓ７０４では解析した送信行の内容が送信エラーを示していた場合はＳ７０５に進み、応答エラー処理を行なう（表示など）。一方、送信エラーを示していなかった場合はＳ７０６に進み、その送信行への応答としての受信行の解析に移る。Ｓ７０６で対応する受信行がなかった場合はＳ７０７へ進み、無応答となることが最初から前提となっている送信行であるか否か、本実施形態では該送信行が機能アドレス向けであったかどうかが判別される。ここで、機能アドレスとは、全てのＣＡＮ＿ＩＤ（すなわち車載機器）に対して一括処理（例えば電源異常など）を指定する際に有となるノードアドレスのことである。該機能アドレスに一括処理のコマンド（作動要求データ）を送信した際、全てのＣＡＮ＿ＩＤの車載機器からそれぞれ応答が返されると膨大な数となる。よって、該機能アドレス向けの送信行に対しては「応答がない」ことが正常となる。よって、Ｓ７０７で送信行が機能アドレス向けであった場合は無応答を正常と判断してＳ７０９へ進む。一方、機能アドレス向けでなかった場合はＳ７０８へ進み、無応答エラー処理を行なう（表示など）。

一方、Ｓ７０６で受信行があった場合はＳ７０９に進み、その受信行による応答内容が否定応答であったかどうかを確認する。否定応答でなかった場合はＳ７１０に進み、正常応答処理となる。また、否定応答であった場合はＳ７１１に進み、否定応答処理を行なう。以上の解析結果は、図１の解析結果記憶部５５ｉに格納され、必要に応じてモニタ５９ないしプリンタ６１より出力し、閲覧に供される。

以上、本発明の実施の形態について説明したが、あくまで例示であって、本発明はこれに限定されるものではない。例えば、取得したダイアグデータは記録フォーマットを判別したのち、あえて標準記録フォーマットへ変換せず、各々判別された記録フォーマットに対応するダイアグ解析ソフトウェアにより個別に解析するようにしてもよい。

本発明の作用及び効果の詳細は次のとおりまとめられる。すなわち、本発明においては、取得したダイアグデータに使用されるバイナリコードの種類及び配列に基づいて、該ダイアグデータの記録フォーマットが、予め定められた複数の記録フォーマットのいずれであるかを判別する。よって、ダイアグデータに新たなヘッダ部の組み込み等を行なわなくとも、その記録フォーマットの判別が可能となる。また、取得したダイアグデータのバイナリコーディング状態が失われないので、従来技術におけるテキスト形式に変換を行なう場合と比較して、文字化けを起こしたり意図通りの出力内容にならなかったりするなどの不具合が大幅に生じにくくなる。すなわち、本発明によると、取得したダイアグデータの記録フォーマットの種別が一旦特定されてしまえば、当該記録フォーマットに準拠した解析装置により、ダイアグデータを構成するバイナリコードは不具合なくデコードが可能となり、正確な内容把握が常に容易となる。よって、車種や検査装置の機種の違い等によりダイアグデータの記録フォーマットが種々相違する場合にあっても、これを効率的に解析することができる。

本発明の車両用ダイアグ解析装置には、記録フォーマットを判別済みのダイアグデータを、複数の記録フォーマットのいずれかに定められる標準記録フォーマットのダイアグデータに変換するフォーマット変換部を設けることができる。ダイアグ解析部は、標準記録フォーマットに変換後のダイアグデータの内容解析を行なうものとして構成できる。

上記の構成によると、記録フォーマットが異なるダイアグデータを取得した場合、その記録フォーマットの種別を判別した上で、複数の記録フォーマットのいずれかに定められる共通の記録フォーマット、すなわち標準記録フォーマットに変換し、内容解析に供される。よって、ダイアグ解析部は、標準記録フォーマットのみに対応したダイアグデータ解析機能（例えば、バイナリコードのデコード機能）を具備していればよく、多数の記録フォーマットに対応した解析機能を搭載する必要がなくなり、ソフトウェアの簡略化及び軽量化に大いに貢献する。

作動データの取得に使用される車載通信のプロトコル規格は、例えばＣＡＮ（Controller Area Network）あるいはＬＩＮ（Local Interconnect Network）など、周知のシリアル通信規格が採用可能である。これらの通信規格はいずれも、通信フレーム長が一定に定められており、これを採用する場合、作動データは、車載機器に作動事象が発生するに伴い一定長の通信フレームを単位とする形で通信取得されることとなる。

これを反映して、現行のダイアグ記録装置では、ダイアグデータの記録フォーマットとして、１つの作動事象を記述するダイアグデータを通信フレーム単位で記録するとともに作動データのサイズが１つの通信フレームにて送信許容される規定データ長を超える場合にダイアグデータをフレーム単位で分割した形で記録する方式（以下、第一の記録フォーマットという）が多く採用されている。この記録フォーマットでは、通信フレームを送受信するごとに、当該通信フレームの内容を順次記録してゆけばよいので、ダイアグデータ記録の処理負荷が低い利点がある。しかしながら、１つの作動事象において発生する作動データのサイズが大きい場合は、同じ作動事象の作動データであるにも関わらず分割して記録されることとなり、作動データの抽出や集約といった解析前処理の負荷が増大する欠点がある。

一方、別のダイアグデータの記録フォーマットとして、１つの作動事象に対応する作動データを、通信フレームの規定データ長と無関係に１行に集約して記録する方式も存在する（以下、第二の記録フォーマットという）。この記録フォーマットは、１つの作動事象において発生する作動データのサイズが大きい場合は、複数フレームに分散した作動データを各フレームから抽出して集約する処理が必要である。そのため、ダイアグデータ記録の処理負荷は上記の第一の記録フォーマットを採用する場合より大きいが、１つの作動事象において発生する作動データのサイズが大きくても、ダイアグデータとして１行に集約して記録されるため、作動データの解析処理負荷は大幅に減じられる。

そして、現行のダイアグ記録装置の大半においてダイアグデータの記録フォーマットは、これら第一の記録フォーマットと第二の記録フォーマットのいずれか採用されており、このうち記録装置低廉化が望まれる背景から、第一の記録フォーマットのほうがより多く普及しているといえる。

そこで、本発明においては、前述の第二の記録フォーマットを標準記録フォーマットとして定め、フォーマット変換部は、取得したダイアグデータが第一の記録フォーマットにより記録されたものであった場合に、該ダイアグデータを第二の記録フォーマットのデータに変換するように構成しておくとよい。第二の記録フォーマットは解析処理負荷低減の観点から、第一の記録フォーマットよりもはるかに好都合であり、かつ、普及が進んでいる第一の記録フォーマットによるダイアグ記憶装置を、あえて高価な第二の記録フォーマットによるダイアグ記憶装置に更新せずとも、取得されたダイアグデータを第二の記録フォーマットにより低負荷にて解析に供することができる利点が生ずる。

上記第一及び第二の記録フォーマットにおいてダイアグデータは、取得時刻データと作動データとが一対一に対応付けられたダイアグログ行を時系列順に配列したものとして作成できる。この場合、第一の記録フォーマットにおいてダイアグデータは、ダイアグログ行内の構成データ要素を注釈するコメント行を先頭に配置することができる。また、第二の記録フォーマットにおいてダイアグデータは、コメント行が省略されるとともに先頭行からダイアグログ行を配列したものとして構成できる。そして、記録フォーマット判別部は、取得したダイアグデータの先頭におけるコメント行の有無に基づいて記録フォーマットの種別を判別するものとすることができる。

第一の記録フォーマットでは、一定長の通信フレーム構造がダイアグログ行の構造にも引き継がれ、ダイアグログ行（以下、本明細書では、第一の記録フォーマットに限りダイアグログ行のことを、通信フレームに対応する用語として「ログフレーム」と称する場合がある）内の各構成データ要素の格納領域を固定的に定めやすい。そのため、コメント行に含まれる構成データ要素注釈用の文字列を、ダイアグログ行（ログフレーム）内のバイナリコード列と位置的に対応させた形で表示するのが容易であり、コメント行の挿入・表示に適したフォーマットであるといえる。他方、第二の記録フォーマットでは、ダイアログ行に組み込まれる作動データ長が一定でなく、通信フレーム構造は引き継がれない。また、ダイアグ記録に際して作動データの分割がなされないため、フレーム種別や分割制御のためのコードが含まれず、ダイアグログ行（ログフレーム）の構成要素が第一の記録フォーマットよりも必然的に少なくなるので、コメント行がなくてもダイアグログ行（ログフレーム）の内容把握が容易である。そして、コメント行が第一の記録フォーマットにのみ組み込まれ、第二の記録フォーマットでは排除されている構成となっていることで、当該コメント行の有無は第一の記録フォーマットと第二の記録フォーマットの非常に有力な判別要素として活用でき、これら２つの記録フォーマットを確実に判別するのに貢献する。

この場合、第一の記録フォーマットにおいてコメント行は、行内の所定の文字列格納位置に構成データ要素の要素名を示す固定文字列を含むものとすることができる。記録フォーマット判別部は、取得されたダイアグデータの先頭行内にて文字列格納位置に対応するバイナリコードを読み込み、これを文字列と仮定して解読するとともに、その解読結果がコメント行に含まれる固定文字列を示すものであった場合に、記録フォーマットの種別が第一の記録フォーマットであると判別するものとして構成できる。そして、フォーマット変換部は、第一の記録フォーマットのダイアグデータを第二の記録フォーマットのダイアグデータへ変換するのに際して、（第二の記録フォーマットでは不要となる）コメント行を削除する処理を行なうものとされる。コメント行は含まれるバイナリコードが上記注釈のための固有文字列を含むので、取得したダイアグデータの先頭行に内容が一定の固有文字列が存在すると仮定して、バイナリコードの解読（デコード）行なうことで、当該固有文字列に変換されれば当該ダイアグデータが第一の記録フォーマットのものであると容易に判別することができる。

第一の記録フォーマットのダイアグデータには、作動データの分割処理がなされることに起因する、第二の記録フォーマットに含まれないバイナリコードが余剰コードとして組み込まれていてもよい。そして、フォーマット変換部は、第一の記録フォーマットのダイアグデータを第二の記録フォーマットのダイアグデータへ変換するに際して、余剰コードを削除するものとして構成できる。ダイアグデータを第一の記録フォーマットから第二の記録フォーマットに変換するに際して、上記余剰コード（上記のコメント行も余剰コードに該当するものである）を的確に削除し、その後、作動データ部分のデータ結合を行なって第二の記録フォーマットへ変換することで、作動データの内容解析の精度を大幅に向上することができる。以下の構成は、その詳細例を個別に示すものである。

（１）ダイアグログ行をなすログフレームについて、第一の記録フォーマットにおいては、作動データの分割の有無に応じてフレーム種別が定められ、さらにそのフレーム種別を特定するためのフレーム種別特定データが組み込まれる。一方、第二の記録フォーマットにおいては、作動データが分割記録されないのでフレーム種別特定データは省略される。その結果、フォーマット変換部は、第一の記録フォーマットのダイアグデータを第二の記録フォーマットのダイアグデータへ変換するに際して、フレーム種別特定データを削除する処理を行なうものとされる。

（２）第一の記録フォーマットにおいて、分割されない作動データのログフレームは、フレーム種別が単一フレームとして定められるともに、作動データのサイズを特定するサイズ特定データが組み込まれる。フォーマット変換部は、第一の記録フォーマットのダイアグデータを第二の記録フォーマットのダイアグデータへ変換するに際して、サイズ特定データが示す作動データのサイズが、単一フレームにおいて作動データ用に確保されている作動データ格納領域のサイズよりも小さい場合に、該作動データ格納領域の余剰部分に生ずるヌルコードを削除する。

（３）また、フォーマット変換部は、第一の記録フォーマットのログフレームに含まれるフレーム種別特定データに基づき、ログフレームが、作動データを分割する分割フレームに該当するか否かを判別するフレーム種別判別部と、分割フレームと判別された複数のログフレームからフレーム種別特定データを削除しつつ作動データ部分をそれぞれ抽出し、それら作動データ部分を時系列順に直列に合成して第二の記録フォーマットの作動データとする作動データ部分合成部とを備えるものとして構成できる。

（４）分割フレーム群は、分割対象となる作動データのダイアグデータ記録部への記録に際して、時系列上の最初に記録される先頭フレーム、及び当該先頭フレームに続いて記録される１ないし複数の中間フレームをフレーム種別として含み、分割された作動データの全体サイズを特定するサイズ特定データが先頭フレームに組み込まれる。
フレーム種別判別部は、ダイアグデータに記録された複数のログフレーム群において先頭フレーム及び中間フレームを相互に判別するものとされる。
作動データ部分合成部は、サイズ特定データに基づき、中間フレームのうち時系列上の最後に記録されるものにおいて、作動データ用に確保されている作動データ格納領域の余剰部分に生ずるヌルコードを特定し、これを削除する。

次に、第一の記録フォーマットと第二の記録フォーマットの双方において、ログフレーム内の予め定められた機器種別格納領域に、作動事象に対応付けられる車載機器の機器種別を特定する機器種別特定データを格納することができ、当該機器種別格納領域とは別に設定される作動データ格納領域に作動データを格納することができる。フォーマット変換部は、第一の記録フォーマットのログフレーム内の機器種別特定データと作動データとを分離しつつ抽出する機器種別／作動データ分離抽出部を有するものとし、それら分離された機器種別特定データと作動データとを、第二の記録フォーマットのダイアグデータに組み込むように構成できる。第一の記録フォーマットのダイアグデータ内の機器種別特定データと作動データとを分離することで、第二の記録フォーマットのダイアグデータに変換した際に、ダイアグ記録された作動事象にかかる機器種別とその作動内容をより適正に把握することが可能となる。

しかしながら、車載機器の種別は多岐にわたり、作動事象にかかる機器種別は分類が細分化され、総数も極めて多くなりがちである。そして、機器種別特定データは、対応する機器種別を的確に分類するために、機器種別に応じてバイナリコード割当数が複数種類に設定される場合もあり得る。ダイアグデータのファイルは、バイナリコードが先頭から逐次的に読み取られるシーケンシャルファイルとして作成されることが多く、ログフレーム内の作動データ格納領域は、機器種別特定データに後続する形で機器種別特定データのバイナリコード割当数に応じて異なる位置に設定されることとなる。この場合、機器種別／作動データ分離抽出部は、ログフレームから逐次読み出されるバイナリコード群において、作動データとして把握するべきバイナリコードを、機器種別特定データのバイナリコード割当数を参照して特定するように構成できる。これにより、機器種別特定データのバイナリコード割当数が変動する場合においても、作動データとの分離抽出を的確に実施することが可能となる。

ダイアグデータは、機器種別毎に定められる機能種別特定データと機能種別内容との対応関係が相違する複数のダイアグ通信規格のいずれかに準拠して作成されたものとすることができる。ここで、機能種別とは、個々の車載機器が固有に備える作動機能を意味する。取得するダイアグデータは、作成元であるダイアグ記録装置が採用するダイアグ通信規格の相違により、機能種別特定データと機能種別内容との対応関係も相違したものとなることが多い。その結果、記録フォーマットが同一のダイアグデータであっても、ダイアグ通信規格の種別把握に失敗すると、解析に際して参照される機能種別特定データと機能種別内容との対応関係が適正なものではなくなり、誤った解析結果が得られてしまう不具合につながる。

このような場合、ダイアグ解析部に、第二の記録フォーマットに変換されたダイアグデータの内容に基づいて、当該ダイアグデータが準拠するダイアグ通信規格の種別を判別するダイアグ通信規格判別部と、ダイアグ通信規格の種別ごとに用意された、機能種別特定データと機能種別内容との対応関係を示す機能特定データベースと、機能特定データベースのうち、判別されたダイアグ通信規格の種別に対応するものを参照してダイアグデータの内容解析を実行する解析実行部とを設けておくことで、上記の不具合を効果的に解消することができる。

例えば、機能種別特定データの予め定められた種類のものが、複数のダイアグ通信規格のいずれかに固有に使用される固有特定データである場合、ダイアグ通信規格判別部は当該固有特定データがダイアグデータ内に含まれているか否かに基づいてダイアグ通信規格の種別を容易に判別することができる。しかし、機能種別特定データの予め定められた種類のものが、複数のダイアグ通信規格の少なくとも２以上のものに共通して使用される場合は上記の方式によるダイアグ通信規格の判別は不可能である。この場合、ダイアグ通信規格判別部は、共通特定データが使用される車載機器の種別、取得される作動データのサイズ、車載機器側からの応答の種別の少なくともいずれかに基づいてダイアグ通信規格の種別を判別するように構成することができる。これにより、ダイアグデータに機能種別特定データとして固有特定データが含まれず、共通特定データのみが含まれる場合にあっても、ダイアグ通信規格の種別を的確に判別することができる。例えば、機能種別特定データは、１つの作動事象に対応する作動データの先頭に一定数のバイナリコードとして組み込まれている場合があり、この場合のダイアグ通信規格判別部は、前記第二の記録フォーマットのダイアグデータにおける前記作動データの先頭のバイナリコードから前記機能種別特定データを取得するように構成できる。

５０ 車両用ダイアグ解析装置
５１ ＣＰＵ
５２ ＲＡＭ
５３ ＲＯＭ
５４ 入出力部
５５ ハードディスクドライブ
５５ａ 通信ファームウェア（ダイアグデータ取得部）
５５ｂ ダイアグデータ記憶部
５５ｃ 変換結果記憶部
５５ｄ ダイアグ解析ソフトウェア（ダイアグ解析部）
Ｓ７０１１ ダイアグ通信規格判別部
５５ｅ 記録フォーマット判別・変換ソフトウェア
Ｓ３ 記録フォーマット判別部
Ｓ６ フォーマット変換部
Ｓ７ 解析実行部
Ｓ６６ フレーム種別判別部
Ｓ６８ 作動データ部分合成部
Ｓ６１，Ｓ６２，Ｓ６３，Ｓ６７ 機器種別／作動データ分離抽出部
５５ｆ 通信規格判別データベース
５５ｇ 機器種別対応関係データベース
５５ｈ，５５ｈ４，５５ｈ５ 機能特定データベース
５５ｉ 解析結果記憶部
５６ バス
５７ シリアル通信インターフェース（ダイアグデータ取得部）
５８ 通信バッファ
５９ モニタ
６０ 入力部
６１ プリンタ
７０ 車両
７１ 車両側コネクタ
７２ ダイアグ記録装置
７２ａ 通信ファームウェア
７２ｂ ダイアグ記録システムソフトウェア
７２ｃ ダイアグデータ記憶部
７３ ＥＣＵ
７４ 検査装置
７５ 車載機器
１００，１００Ａ，１００Ｂ 第一の記録フォーマットのダイアグデータ
１０１ ダイアグログ行（ログフレーム）
２００ 第二の記録フォーマットのダイアグデータ
２０１ ダイアグログ行

Claims (14)

1. 車載機器に作動事象が発生するに伴い通信により取得される作動データを、前記作動データを取得した時刻である取得時刻データと対応付けたダイアグデータとして記録するダイアグ記録装置から、予め定められた複数の記録フォーマットのいずれかにより該ダイアグ記録装置に固有のバイナリコードを用いて記述されたダイアグデータを取得するダイアグデータ取得部と、
   取得した前記ダイアグデータに使用される前記バイナリコードの種類及び配列に基づいて、該ダイアグデータの記録フォーマットを判別する記録フォーマット判別部と、
   前記記録フォーマットの判別結果に基づいて、取得した前記ダイアグデータの内容解析を行なうダイアグ解析部と、
   を備えたことを特徴とする車両用ダイアグ解析装置。
2. 前記記録フォーマットを判別済みの前記ダイアグデータを、前記複数の記録フォーマットのいずれかに定められる標準記録フォーマットのダイアグデータに変換するフォーマット変換部を備え、前記ダイアグ解析部は、前記標準記録フォーマットに変換後の前記ダイアグデータの内容解析を行なうものである請求項１記載の車両用ダイアグ解析装置。
3. 前記作動データは、車載機器に作動事象が発生するに伴い一定長の通信フレームを単位とする形で通信取得されるものであり、
   前記記録フォーマットは、１つの作動事象を記述する前記ダイアグデータを前記通信フレーム単位で記録するとともに前記作動データのサイズが１つの前記通信フレームにて送信許容される規定データ長を超える場合に前記ダイアグデータをフレーム単位で分割した形で記録する第一の記録フォーマットと、１つの作動事象に対応する前記作動データを、前記通信フレームの前記規定データ長と無関係に１行に集約して記録する第二の記録フォーマットとのいずれかであり、該第二の記録フォーマットが前記標準記録フォーマットとして定められ、
   前記フォーマット変換部は、取得した前記ダイアグデータが前記第一の記録フォーマットにより記録されたものであった場合に、該ダイアグデータを前記第二の記録フォーマットのデータに変換するものである請求項２記載の車両用ダイアグ解析装置。
4. 前記ダイアグデータは、前記取得時刻データと前記作動データとが一対一に対応付けられたダイアグログ行を時系列順に配列した形で記録されるものであり、
   該ダイアグデータは、前記第一の記録フォーマットにおいては、前記ダイアグログ行内の構成データ要素を注釈するコメント行が先頭に配置され、該コメント行に続く形で前記ダイアグログ行がログフレームとして時系列順に配列されたものであり、前記第二の記録フォーマットにおいては、前記コメント行が省略されるとともに先頭行から前記ダイアグログ行を配列したものであり、
   前記記録フォーマット判別部は、取得した前記ダイアグデータの先頭における前記コメント行の有無に基づいて前記記録フォーマットの種別を判別するものである請求項３記載の車両用ダイアグ解析装置。
5. 前記第一の記録フォーマットにおいて前記コメント行は、行内の所定の文字列格納位置に前記構成データ要素の要素名を示す固定文字列を含むものであり、
   前記記録フォーマット判別部は、取得された前記ダイアグデータの先頭行内にて前記文字列格納位置に対応するバイナリコードを読み込み、これを文字列と仮定して解読するとともに、その解読結果が前記コメント行に含まれる前記固定文字列を示すものであった場合に、前記記録フォーマットの種別が前記第一の記録フォーマットであると判別するものであり、
   前記フォーマット変換部は、前記第一の記録フォーマットのダイアグデータを前記第二の記録フォーマットのダイアグデータへ変換するのに際して、前記コメント行を削除する処理を行なうものである請求項４記載の車両用ダイアグ解析装置。
6. 前記第一の記録フォーマットのダイアグデータには、前記作動データの分割処理がなされることに起因する、前記第二の記録フォーマットに含まれないバイナリコードが余剰コードとして組み込まれ、
   前記フォーマット変換部は、前記第一の記録フォーマットのダイアグデータを前記第二の記録フォーマットのダイアグデータへ変換するに際して、前記余剰コードを削除するものである請求項３ないし請求項５のいずれか１項に記載の車両用ダイアグ解析装置。
7. 前記第一の記録フォーマットと前記第二の記録フォーマットの双方において、ログフレーム内の予め定められた機器種別格納領域に、前記作動事象に対応付けられる前記車載機器の機器種別を特定する機器種別特定データが格納され、当該機器種別格納領域とは別に設定される作動データ格納領域に前記作動データが格納されるとともに、
   前記フォーマット変換部は、前記第一の記録フォーマットの前記ログフレーム内の前記機器種別特定データと前記作動データとを分離しつつ抽出する機器種別／作動データ分離抽出部を有し、それら分離された前記機器種別特定データと前記作動データとを、前記第二の記録フォーマットの前記ダイアグデータに組み込むものである請求項５又は請求項６に記載の車両用ダイアグ解析装置。
8. 前記機器種別特定データは前記機器種別に応じてバイナリコード割当数が複数種類に設定されるとともに、前記ダイアグデータのファイルは、バイナリコードが先頭から逐次的に読み取られるシーケンシャルファイルであり、前記ログフレーム内の前記作動データ格納領域は、前記機器種別特定データに後続する形で前記機器種別特定データの前記バイナリコード割当数に応じて異なる位置に設定され、
   前記機器種別／作動データ分離抽出部は、前記ログフレームから逐次読み出される前記バイナリコード群において、前記作動データとして把握するべきバイナリコードを、前記機器種別特定データの前記バイナリコード割当数を参照して特定するものである請求項７記載の車両用ダイアグ解析装置。
9. 前記ダイアグデータは、前記機器種別毎に定められる機能種別特定データと機能種別内容との対応関係が相違する複数のダイアグ通信規格のいずれかに準拠して作成されたものであり、
   前記ダイアグ解析部は、前記第二の記録フォーマットに変換された前記ダイアグデータの内容に基づいて、当該ダイアグデータが準拠する前記ダイアグ通信規格の種別を判別するダイアグ通信規格判別部と、
   前記ダイアグ通信規格の種別ごとに用意された、前記機能種別特定データと前記機能種別内容との対応関係を示す機能特定データベースと、
   前記機能特定データベースのうち、判別された前記ダイアグ通信規格の種別に対応するものを参照して前記ダイアグデータの内容解析を実行する解析実行部とを備える請求項７又は請求項８に記載の車両用ダイアグ解析装置。
10. 前記機能種別特定データの予め定められた種類のものが、前記複数のダイアグ通信規格のいずれかに固有に使用される固有特定データである場合、前記ダイアグ通信規格判別部は当該固有特定データが前記ダイアグデータ内に含まれているか否かに基づいて前記ダイアグ通信規格の種別を判別するものである請求項９記載の車両用ダイアグ解析装置。
11. 前記機能種別特定データの予め定められた種類のものが、前記複数のダイアグ通信規格の少なくとも２以上のものに共通して使用されるとともに対応する前記機能種別内容が相違する共通特定データとされ、
    前記ダイアグ通信規格判別部は、前記共通特定データが使用される前記車載機器の種別、取得される前記作動データのサイズ、車載機器側からの応答の種別の少なくともいずれかに基づいて前記ダイアグ通信規格の種別を判別するものである請求項９又は請求項１０に記載の車両用ダイアグ解析装置。
12. 前記機能種別特定データが、１つの作動事象に対応する前記作動データの先頭に一定数のバイナリコードとして組み込まれてなり、
    前記ダイアグ通信規格判別部は、前記第二の記録フォーマットのダイアグデータにおける前記作動データの先頭のバイナリコードから前記機能種別特定データを取得するものである請求項９ないし請求項１１のいずれか１項に記載の車両用ダイアグ解析装置。
13. 車載機器に作動事象が発生するに伴い一定長の通信フレームを単位とする形で通信により取得される作動データを、前記作動データを取得した時刻である取得時刻データと対応付けたダイアグデータとして記録するダイアグ記録装置から、予め定められた複数の記録フォーマットのいずれかにより該ダイアグ記録装置に固有のバイナリコードを用いて記述されたダイアグデータを取得するダイアグデータ取得ステップと、
    取得した前記ダイアグデータに使用される前記バイナリコードの種類及び配列に基づいて、該ダイアグデータの記録フォーマットを判別する記録フォーマット判別ステップと、
    前記記録フォーマットの判別結果に基づいて、取得した前記ダイアグデータの内容解析を行なうダイアグ解析ステップと、
    を備えたことを特徴とする車両用ダイアグデータ解析方法。
14. 車載機器に作動事象が発生するに伴い一定長の通信フレームを単位とする形で通信により取得される作動データを、前記作動データを取得した時刻である取得時刻データと対応付けたダイアグデータとして記録するダイアグ記録装置から、予め定められた複数の記録フォーマットのいずれかにより該ダイアグ記録装置に固有のバイナリコードを用いて記述されたダイアグデータを取得するダイアグデータ取得ステップと、
    取得した前記ダイアグデータに使用される前記バイナリコードの種類及び配列に基づいて、該ダイアグデータの記録フォーマットを判別する記録フォーマット判別ステップと、
    前記記録フォーマットの判別結果に基づいて、取得した前記ダイアグデータの内容解析を行なうダイアグ解析ステップと、
    をコンピュータに実行させることを特徴とする車両用ダイアグデータ解析コンピュータプログラム。

Images