UDS19サービス
記事ディレクトリ
0x19 サービス リクエストのサブサービスの概要:
以下に示すように:
0x19 サービス 01 サブサービス:
以下に示すように:
返信するには 19 01 FF を送信してください:
状態マスクを使用して、それに一致するフォルトの数を見つけます。
サービス診断機器は、ECU の DTC 状態が DTC 状態マスクと一致する障害コードの数を要求できます。DTC の実際のステータス ビットが「1」で、DTC ステータス マスク内の対応するビットも「1」の場合、DTC のステータスは DTC ステータス マスクと一致するとみなされます（つまり、DTC ステータスのマスク バイトが一致する場合）。と DTC の実際のステータス バイトが論理的に「ビット AND 演算」され、結果がゼロ以外の値になると、2 つが一致します); このとき、フォールトの数は +1 になります。クライアントが ECU がサポートしていないビットを含むステータス マスクを定義した場合、ECU はサポートしているビットのみを使用して障害情報を処理します。リクエストの形式は次のとおりです。
リクエストを受信した後の ECU 応答の形式は次のとおりです。
DTC ステータス マスク パラメータには 8 つの DTC ステータス ビットが含まれており、そのビットは次のように定義されています。
0x19 サービス 02 サブサービス:
以下に示すように:
19 02 FF 返信を送信:
定義されたステータス マスクの形式で一致するフォルトを検索し、一致した DTC 識別子 (3 バイト) と DTC ステータス (1 バイト) 情報を返します。01 サブサービスはステータス マスクに一致する DTC の数のみをカウントし、02 サブサービスは一致する DTC 情報を返します。リクエストの形式は次のとおりです。
リクエストを受信した後の ECU の応答メッセージの形式は次のとおりです。
0x19 サービス 04 サブサービス:
以下に示すように:
故障の原因を便利に見つけるために、対応する故障が発生した場合、ECUは故障時のスナップショット情報を記録する必要があり、04サービスを使用して指定された故障コード(DTC)のスナップショット情報を要求します。これらのデータを障害発生時に検索することで、障害の原因を解析します。リクエストの形式は次のとおりです。
このうち、ＤＴＣＳｎａｐｓｈｏｔＲｅｃｏｒｄＮｕｍｂｅｒは、ＤＴＣスナップショットレコードコードを表し、１バイトを占め、特定のＤＴＣスナップショットデータレコード番号を表す。たとえば、特定の DTC の最初の発生 (1 で表されるものとします) と最新のスナップショット データ (2 で表されるものとします) を記録する必要がある場合、DTCSnapshotRecordNumber が 1 の場合、それは、 DTC スナップショット情報の最初の出現。
ECU が複数の DTC スナップショット データ レコードをサポートしている場合、レコード コードは 0x01 ～ 0xFE の範囲の値を使用する必要があります。このパラメータの値が FF (16 進数) の場合、ECU は保存されているすべての DTC スナップショット データ レコードを一度にレポートする必要があります。
リクエストを受信した後の ECU の応答メッセージの形式は次のとおりです。
上記と同様に、応答メッセージの DTCSnapshotRecordNumber は、どの DTC のスナップショット レコードが返されるかを示し、DTCSnapshotRecordNumberOfIdentifiers は、スナップショット情報に定義されているメンバーの数を示し、定義されたスナップショット データに 4 つの情報がある場合、値は 4 になります。
0x19 サービス 06 サブサービス:
以下に示すように:
拡張情報。障害の発生回数、エージング回数、エージング時間など、障害に関するその他の情報を記録するために使用されます。06 サービスは、指定された障害コード (DTC) の拡張情報を要求するために使用されます。リクエストの形式は次のとおりです。
| DTCExtDataRecordNumber 値 (16 進数) | 説明する |
|---|---|
| 0 | 利用不可（予約済み） |
| 01～8F | 自動車メーカーの指定に従って保存されている DTCExtendedData (DTC 拡張データ) レコードを報告するようにサーバーに要求します。 |
| 90~EF | 法定 OBD によって保存されている DTCExtendedData (DTC 拡張データ) レコードを報告するようにサーバーに要求します。 |
| F0~FD | 予約する |
| FE | すべての法定 OBD ストアの DTCExtendedData (DTC 拡張データ) レコードを単一の応答メッセージで報告するようにサーバーに要求します。 |
| FF | 保存されているすべての DTCExtendedData (DTC 拡張データ) レコードを 1 つの応答メッセージで報告するようサーバーに要求します。 |
リクエストを受信した後の ECU の応答メッセージの形式は次のとおりです。
0x19 サービス 0A サブサービス:
以下に示すように:
19 0A 応答を送信します。
このサービスは、サポートされているすべての DTC 情報 (3 バイトの DTC 識別子と 1 バイトの DTC ステータス ビット) を要求するために使用され、その応答メッセージは 02 サービスと一致しますが、このサービスがすべての DTC を返すことは区別する必要があります。 02サービスはリクエスト時のステートマスクとは異なる「0」以外のDTC情報を返すことになります。リクエストの形式は次のとおりです。
リクエストを受信した後の ECU の応答メッセージの形式は次のとおりです。
UDSパケットの解釈例
0x19 サービス 06 サブサービスを例として、CAN バス上の実際の UDS メッセージを解釈します。
クライアントはサーバーに次のリクエストを行います。
06 19 06 XX XX XX FF 00
| 06 | 最初の 4 桁「0」はフレーム データが単一フレーム データであることを示し、最後の 4 桁「6」はフレーム内に有効なバイトが 6 つあることを示します (「19 06 XX XX XX FF」) |
|---|---|
| 19 06 | 0x19 サービス 06 サブサービスを示します |
| XX XX XX | DTCコードを表します |
| FF | DTCExtDataRecordNumber=0xFF; DTC のすべての拡張データをサーバーから取得することを意味します |
| 00 | 無効なバイト |
サーバーはクライアントに次のように応答します。
10 11 59 06 × × × × × 10
| 1 | 最初のバイトの最初の 4 ビットは、そのフレームが最初のフレームであることを示します。これは、サーバーが残りのデータの送信を続けるために、クライアントがフロー制御フレームに応答するのを待つことを意味します。 |
|---|---|
| 0 11 | 最初のバイトの最後の 4 ビットと 2 番目のバイトの 8 ビットで構成される 12 ビット コードは、現在のデータ ストリームの合計バイト数です。つまり、現在のデータ ストリームには 17 の有効なバイトがあることになります。 |
| 59 06 | 0x19 サービス 06 サブサービスの応答を示します |
| XX XX XX | DTC コードは、クライアントが要求した DTC コードと一致しています。 |
| 10 | 現在の DTC のステータス ビット |
クライアントは、フロー制御フレームを受信した後、これで応答します。
30 00 00 00 00 00 00 00
| 3 | 現在フロー制御フレームであることを示します |
|---|---|
| 0 | サーバーにデータの送信を続けるように要求する |
| 00 | このバイトは、サーバーが次回送信できる連続フレーム数を示します。「0」の場合、すべてのデータが送信されます。 |
| 00 | サーバーが連続フレームを送信するときの最小時間間隔を指定します。現在は「0ms」です。 |
| 00 00 00 00 00 | 無効なデータ |
それを受信した後、サーバーは 2 つのデータ フレームで応答しました。
21 10 00 00 00 00 20 00
22 00 30 01 00 00 00 00
| 21と22 | これは 2 つのデータ フレームのフレーム ヘッダーで、最初の 4 桁は現在のフレームが連続していることを示し、最後の 4 桁は現在のフロー制御フレームを受信した後のフレームのシリアル番号を示します。 |
|---|---|
| 10 00 00 00 00 20 00 00 30 01 00 | 拡張情報データ「10」、「20」、「30」の 3 組が DTCExtDataRecordNumber (custom) であり、それぞれの DTCExtDataRecordNumber の長さもカスタマイズされています |
| 00 00 00 | 無効なデータ |