UDS サービスの基本パート 31

UDS サービスの基本 - 31 のサービス

序文

前回の記事「UDSの基礎 2Fサービス」でも触れましたが、2Fサービスは今回取り上げる31サービスとの類似点があるため、31サービス自体についてさらに詳細な分析を行う必要があります。 T は、誰もが考えられるように、のような次

• 31サービスって知っていますか？
• 31 サービスの依頼・診断形式は何ですか？
• 31 サービス利用時の注意点は何ですか？

この記事では、これらの質問を一緒に調べて答えてみましょう。誰でも理解しやすいように、この記事のトピックの概要を以下に示します。

---

文章

サービス機能

機能説明

ISO14119-1標準によれば、診断サービス 31 サービスは主に、異常な動作条件下でのプログラム動作や特定の種類のテスト シナリオでのその他のメモリ消去などの一連の連続操作ステップを実装するために使用されます。

場合によっては、2F サービスの基本機能も 31 個のサービスで実現できます。2F で実現されるすべての機能は 31 個のサービスで実現できることがわかります。より複雑な入出力制御シナリオに使用されますが、2F サービスは比較的単純で一般的な入出力制御シナリオに使用できます。

以下のテキストで使用されるクライアントは、上位コンピュータであるテスターとして直接理解でき、サーバーは、テスターの診断要求を受け入れる ECU として直接理解できます。

アプリケーションシナリオ

一般に、31 の診断サービスの主なアプリケーション シナリオは次のとおりです。

• たとえば、カメラやレーダーの内部パラメータ校正プロセスなど、センサーの特定の動作条件下での一連の操作に使用されます。
• 車両製造プロセス全体では、特定のセンサーの外部パラメータ校正ステーションがより一般的です。このステーションでは、校正ルーチンを開始するために 31 サービスを使用する必要があります。校正プロセスが完了した後、31 サービスは次のパラメータを取得することもできます; キャリブレーション ルーチンの最終結果。
• たとえば、レーダー使用中の異常な動作条件下での送信波形の設定調整は、31 のサービスを通じて実現できます。
• UDS フラッシュのプロセスでは、31 のサービスを通じてメモリ消去操作をトリガーできます。

上記のアプリケーション シナリオは比較的一般的なものであるため、ここでは列挙しません。

31 サービスについては、使用されるアプリケーション シナリオに加えて、次の注意事項を提起する必要があります。

• 31 同じ制御シナリオのサービスは、一般に開始、停止、結果取得の 3 つのプロセスに分けることができますが、これら 3 つのプロセスは同時に存在することはなく、同時に存在する必要があるかどうかはお客様が完全にカスタマイズできます;
• 31 のサービスは、各制御シナリオのルーチン ID によって一意に区別できるため、異なる制御シナリオは一意のルーチン ID によって区別される必要があります。
• AUTOSAR ツール チェーンを通じて構成された 31 のルーチン コールバック関数に名前を付ける場合、その基本的な機能の説明に加えて、関数名には対応するルーチン ID も関数名に反映する必要があります。これは検索やトラブルシューティングに便利であり、優れた機能です。コードの練習。
• 31 のサービスに関与するコールバック関数については、主にコードの保守性の観点から、RTE を使用することは推奨されません。RTE の方がより簡潔で明確で、実装効率が高くなります。RTE インターフェイスを使用すると、追加の作業負荷が必要になります。不必要でエラーが発生しやすくなります。

31 サービス制御の基本原則:

以下の図 1 に示すように、31 のサービスの通信制御プロセスは、以下の AUTOSAR BSW モジュールによって処理され、最終的なルーチン制御が完了します。具体的な手順は次のとおりです。

• クライアントは診断命令をサーバーに送信し、サーバーは命令を受信した後にルーチン タイプを確認することで、さまざまなコールバック関数を呼び出すことを決定します。
• 各コールバック関数では、顧客定義の制御シナリオを実現できますが、特定のシナリオは顧客のニーズに応じてカスタマイズする必要があります。

図1 31 サービス制御フローチャート

サービスのお申し込み

サービス要求は、クライアントからサーバーに送信される診断サービス命令です。

リクエストフォーマット

ISO14229-1 規格によると、31 サービス診断リクエストのフォーマットは以下の図 2 に示されています。これは、上記の 31 サービス制御原則における診断サービスリクエストのフォーマットです。

図2 31 診断サービスリクエストフォーマット

上記のパラメータLukeControlOptionRecordはオプションであり、関連する制御パラメータを渡すなど、プロジェクト内でカスタマイズできます。さらに、SID、SubFunction、およびルーチン IDの 3 つのパラメータは必須であり、以下の図 3 のパラメータについては次のように説明されます。

図 3 31 診断サービス要求フォーマットの説明

リクエストインスタンス

オープンルーチン(01)

ルーチンを開く例を考えます。ルーチン ID が0201で、ルーチンは短期入出力制御に使用され、ルーチン インスタンスを開くための 31 サービス診断リクエストが次の図 4 に示されています。

図 4 31 サービスがルーチン リクエスト インスタンスを開く

ストップルーチン(02)

停止ルーチンを例として、31 サービス診断停止ルーチン要求の例を以下の図 5 に示します。

図5 31サービス停止ルーチンリクエストインスタンス

ルーチン結果の取得 (03)

ルーチン結果取得を例として、31 サービス診断取得ルーチン結果リクエストの例を以下の図 5 に示します。

図 6 31 サービスがルーチン結果要求インスタンスを取得する

サービス応答

サービス応答は、サーバー診断要求に対するクライアントの応答です。

肯定的な応答の形式

以下の図 7 に示すように、これは 31 診断サービスの肯定応答形式です。

図 7 31 診断サービスの肯定応答フォーマット

上の図からわかるように、31 診断サービスの肯定的な応答は次の 2 つの部分で構成されます。

• 応答 ID: このパラメータは SID+0x40 = 0x71 に固定されています。
• SubFunction: このパラメータは、上記の診断要求フォーマットのルーチン タイプと一致します。
• ルーチン識別子: このパラメータは、診断サービス リクエストのルーチン識別子と一致します。
• ルーチン情報: 一般に、オプションとしての顧客のカスタマイズとして理解できます。
• ルーチンステータスレコード: 上記と同じ。

陽性反応例

オープンルーチン(01)

以下の図 8 に示すように、これは上記の31 01 02 01リクエストの例に対応する肯定的な応答です。

図 8 31 01 肯定応答の例

このうち、0x01 は診断リクエストの 31 01 の RoutineType と一致し、routineStatusRecord は顧客のニーズに応じたカスタム応答です。

ストップルーチン(02)

以下の図 9 に示すように、これは上記の31 02 02 01リクエストの例に対応する肯定的な応答です。

図 9 31 02 肯定応答の例

このうち、0x02 は診断リクエストの 31 02 の RoutineType と一致し、routineStatusRecord は顧客のニーズに応じたカスタム応答です。

ルーチン結果の取得 (03)

以下の図 10 に示すように、これは上記の31 03 02 01リクエストの例に対応する肯定的な応答です。

図 10 31 03 の肯定的な応答の例

このうち、0x03 は診断要求の 31 03 の RoutineType と一致し、routineStatusRecord は顧客のニーズに応じたカスタム応答です。

否定応答 NRC サポート

ほとんどの場合、サーバーはクライアントの要求に対して肯定的な応答を返します。たとえば、再始動する前に、エンジンが停止し、車速が超過できないなど、車両全体が安全な状態であることを確認する必要があります。 3km/h など、または診断リクエストの形式に従わないことを防ぐため、リクエストを実行すると、サーバーは、肯定的な応答が得られるまで問題を調査するために、何らかの方法で実行に失敗した理由をクライアントに伝える必要があります。 。

したがって、ISO14229-1 は、すべての診断サービスに対して統一された診断否定応答診断形式、7F +SID + NRCを提供します。

NRC の正式名は Negetive Responce Code であり、各 NRC には現在の診断要求エラーの原因を表す固有の意味があります。もちろん、各診断サービスがサポートする NRC は同じではありません。サポートされる特定の NRC については、ISO14229-1 標準文書を参照する必要があります。31 のサービスでサポートされる NRC は次のとおりです。

図 11 31 サービス NRC サポート

• 診断リクエストのサブ機能がサーバーによってサポートされる範囲内にない場合、サーバーは「7F 31 12」と応答します。
• 送信されたメッセージの長さまたは形式が正しくない場合、サーバーは「7F 31 13」と応答します。
• たとえば、リセットしようとして現在の車両速度条件が満たされていない場合、クライアントが診断フィンガー要求を送信すると、サーバーは「7F 31 22」と応答して、プログラミング セッションに入る現在の条件が満たされていないことを要求者に伝えます。満たした場合は、プログラミング セッション条件を入力するために再度確認してください。
• ルーチンが結果を要求するか、開始前にルーチンを終了すると、サーバーは **"7F 31 24"** と応答します。
• ルーチン識別子またはオプションのルーチン制御オプションレコードの両方が指定された範囲を超えると、サーバーは ** "7F 31 31" ** と応答します。
• ルーチン識別子にセキュリティ アクセス レベルが設定されている場合、ロックを解除せずに 31 サービスを実行すると、サーバーは **"7F 31 33"** と応答します。
• 31 サービスを使用して NVM を消去する場合、プロセス中に障害が発生すると、サーバーは **「7F 31 72」** と応答します。

上記の NRC には対応する優先順位もあるため、Little T には、以下の図 12 に示すように、対応する 31 のサービス NRC 優先順位が表示されます。

図 12 31 サービス NRC の優先順位

AUTOSAR のさらにエキサイティングな基本的かつ実践的な内容については、公式アカウント「ADAS と ECU に関する私の意見」にご注目ください。
Little T の基本的な内容と組み合わせて、Little T の実戦シリーズを深く学び、AUTOSAR を簡単にマスターできる:
AUTOSAR 実践ガイド