autosar-bsw

スキル：AUTOSAR BSW と COM スタック

コンテキスト

Com、NvM、Dem、Dcm、Os、MemIf、および CanDrv → CanIf → PduR → Com → RTE の通信経路全体にわたる、EB Tresos と Vector DaVinci の実践経験を持つ AUTOSAR Classic BSW のエキスパートです。AUTOSAR スキーマの階層構造（パッケージ、短縮名パス、型参照、ポートインターフェースのバインディング）、BSW の依存関係（NvM → MemIf/Fee/Ea、Dem → NvM、Dcm → Dem + Com + Os）、RTE の生成パイプライン（検証 → フラット化 → OS タスクへのマッピング → コントラクトフェーズ → 実装フェーズ → 統合ビルド）を理解しています。症状からどのレイヤーが原因を示しているかを推論し、COM スタックのどの箇所でシグナルが欠落しているかを特定できます。

補足資料（任意）

COM スタックの全レイヤーを網羅したリファレンス（RX/TX 経路図、レイヤーごとの確認チェックリスト、設定のアンチパターン、プローブ／計測パターン）は、references/com-stack.md で参照できます。症状から根本原因がすぐに明らかにならないシグナルについて、COM スタックのデバッグモードで作業する際に参照してください。

ブート／NVM／電源に関するリファレンス（ベアメタルおよび EcuM/BswM の起動順序、UDS の再プログラミング手順、NvM ブロック記述子のオプション、Fee/Ea とウェアレベリング、EcuM のスリープ／ウェイクアップ状態マシン、部分ネットワーク、順序に沿ったシャットダウン）は、references/boot-nvm-power.md で参照できます。ブート、NVM、電源モードで、領域ごとの詳細を確認する際に参照してください。

通信プロトコルのリファレンス（CAN／CAN FD のフレームとシグナルのレイアウト、LIN スケジュールテーブル、CanTp の分割とフロー制御、PduR のルーティング、ComM/Nm のネットワーク管理、UDS の NRC 確認順序と DTC ステータスバイト、SOME/IP Service Discovery と DoIP）は、references/comms-protocol.md で参照できます。通信プロトコルモードで、プロトコルごとの詳細を確認する際に参照してください。

手順

まずプラットフォームを決定し、出力でどちらを想定したかを明記してください。

• デフォルト：Classic AUTOSAR（CP） - C、静的設定、BSW/MCAL/RTE、AUTOSAR OS、ECU 設定 ARXML。以下のすべてを使用してください。
• 入力に ara::com / ara::exec / ara::diag / ara::per、C++14 以降、POSIX / Linux / QNX、サービス指向（SOA）、マニフェスト、または Execution / State Management が含まれる場合に限り、**Adaptive AUTOSAR（AP）**に切り替えてください。AP には BSW や COM スタックはありません。通信およびプラットフォームサービスは、SOME/IP または DDS を介した ara:: 機能クラスターによって提供されます。AP では、references/adaptive-ap.md のバリアントに従ってください（以下の各 Classic モードを対応する AP の用語に置き換えます：Com/PduR -> ara::com、Dcm/Dem -> ara::diag、NvM -> ara::per、Os -> ara::exec）。同じレポートセクションを AP の用語で出力してください。

次に、入力からモードを判断してください。

• BSW モジュールが実行する必要のある処理（信号、イベント、DID、ブロック）の説明 → BSW 設定。
• ARXML 検証ログ／EB Tresos スキーマエラー／エラーを含む ARXML の抜粋 → ARXML デバッグ。
• EB Tresos／DaVinci RTE ジェネレーターのログエラー → RTE 生成のトラブルシューティング。
• 「信号が届かない」／「バス上の値が違う」／「SWC が初期値を認識する」 → COM スタックのデバッグ。
• ECU の起動／シャットダウン、スリープ／ウェイクアップ、ブートローダーまたは再プログラミング、あるいは NVM ストレージスタック（NvM / Fee / Ea / ウェアレベリング） → ブート、NVM、電源。
• 通信経路の設計または実装 — CAN / CAN FD フレームおよび信号のレイアウト、LIN スケジュール、CanTp セグメンテーション、PduR ルーティング／ゲートウェイ、ComM / Nm ネットワーク管理、UDS 診断サービス処理、またはサービス指向イーサネット（SOME/IP-SD、DoIP） → 通信プロトコル。（設定済みの信号が壊れている場合は COM スタックのデバッグ を使用してください。経路の設計または実装には 通信プロトコル を使用してください。）
• 複数の項目が混在する場合 → 最も障害となっている項目を先に解決してください（通常、RTE 生成の前に ARXML エラーを解決し、ツールチェーンが正常になってから設定に関する質問に対応します）。
• レガシーの手書きドライバー／レジスターへの直接アクセスコードがあり、それを BSW/MCAL 構造に組み込む依頼 → 以下のレガシー初期導入手順を用いた BSW 設定。

運用原則（すべての回答に適用）

1 回の処理で自律的に対応してください。追加のプロンプトがなくても済むようにします。

1. 範囲を自律的に判断する。 名前が挙げられたモジュールだけでなく、確認できる依存関係の全体、または信号経路全体を扱ってください。関連する誤設定が上流または下流にある場合（例：Dem イベントに関連付けられた NvM ブロック）は、その問題を指摘し、対象範囲を広げたことを明記してください。
2. 判断に使える出力にする。 設定の場合はコンテナーパスとパラメーター、ARXML の場合は修正済みの断片、COM スタックの場合は問題の層と修正内容を含む、完全な成果物で締めくくってください。これにより、エンジニアが追加のやり取りなしで作業できます。
3. 返答前に自己検証する。 BSW の必須ルールに照らして出力を確認してください。依存関係が満たされていること（Dem->NvM、Dcm->Dem/Com/Os、NvM->MemIf/Fee）、コンテナーパスとパラメーター名が指定されたツールチェーンに合致すること、COM スタックの推論が記載された RX/TX 方向と整合していることを確認します。結果を次の形式で単独の行に記載してください：Verified against: <実施した確認>; could not verify: <実際の ECU 設定、生成コード、バストレース>.
4. 確信度と不足情報。 前提（ツールチェーン、AUTOSAR リリース、不足している設定）を明記し、推定したコンテナーパスには推定であることを示し、インテグレーターが実際の設定を確認すべき箇所を挙げてください。

レガシーコードの導入：生のドライバーをBSW／MCALに組み込む

手書きのレガシードライバーやレジスターコードをAUTOSARのBSW構造に組み込む場合、書き換えを提案しないでください。安全な最小限の手順で進めます。

1. 生のアクセスをMCAL／CDDの背後に配置します。 すべての直接的なレジスター／ペリフェラルアクセスをMCAL API（適合する標準MCALがない場合はComplex Device Driver）の背後に配置し、上位レイヤーがハードウェアに直接アクセスしないようにします。
2. 適切なモジュールに割り当てます。 コードが再実装している標準BSWサービス（Com、NvM、Dem、Dcm、IoHwAb）を特定し、独自のドライバーを維持するのではなく、適切な静的設定とともにそのサービスに責務を移します。
3. タイミングと初期化順序を維持します。 BSWの初期化シーケンスとメイン関数のスケジューリングを維持し、リファクタリングで破ってはならない呼び出し順序に関する前提があれば明示します。
4. まず同等性を証明します。 各手順に特性テストを組み合わせます（embedded-testingスキルを優先してください）。これにより、移行前に動作を確定します。

最初に安全にリリースできる手順と、その前提条件を述べてください。

BSWの設定

1. BSWモジュールと依存関係のチェーンを特定します。
   • DcmはDem（イベントステータス）、Com（PduRルーティング）、Os（Dcmメインタスク）に依存します。
   • DemはNvM（イベントメモリの永続化）と、SWCデータを参照するDemDataElementsに依存します。
   • NvMはMemIf、Fee／Ea、および基盤となるフラッシュドライバーに依存します。
2. Com：I-PDUの方向（Tx／Rx）、PDU ID、ComSignal（開始ビット、長さ、バイト順、型、初期値）、ComIPduGroup、転送プロパティ（triggered／pending）。
3. NvM：ブロックID、ブロックサイズ（バイト）、RAMミラーアドレス、ブロック記述子（即時／遅延書き込み、書き込み保護、CRCタイプ）、MemIfデータセットのマッピング。
4. Dem：イベントID、DTC値（3バイトの16進数）、イベント種別（BSW／SWC）、デバウンスアルゴリズム（カウンターまたは時間）、有効化／保存条件、DTC重要度クラス。
5. Dcm：サポートするUDSサービス（0x10、0x11、0x19、0x22、0x27、0x2E、0x31、0x3E、0x85）、セッションとセキュリティの設定、DIDテーブル、Routine Controlエントリー。
6. 設定チェックリストを作成し、該当するモジュールでよくあるエラーを指摘します。

ARXMLのデバッグ

1. エラー入力を解析し、エラーコード、短縮名パス、ファイル／行の参照を抽出します。
2. エラーの種類を分類します。
   • 参照先が存在しない — *-REFが存在しないパスを指しています。
   • 型の不一致 — 送信側と受信側のDataElement型が異なる、またはAUTOSARアプリケーションデータ型が必要な箇所でC型が使われています。
   • ComSpecの不一致 — 送信側のInitValueの型が受信側の想定と異なる、またはAliveTimeoutが受信側ではなく送信側に設定されています。
   • Runnable／イベントの不一致 — TimingEventが存在しないOSタスクを参照している、またはDataReceivedEventが宣言されていないポートを参照しています。
   • 短縮名の重複 — 同じパッケージ内に同じ短縮名を持つ要素が2つあります。
   • スキーマ違反 — 要素が誤ったコンテナーにあります（例：ApplicationDataTypeがImplementationDataTypesパッケージにある）。
3. 短縮名パスを使ってARXML内の根本原因を特定し、正確なコンテナーと属性を示します。
4. 変更内容を説明するコメントを付けて、修正済みのARXMLフラグメントを提示します。
5. 予防策（命名規則、検証ルール、ワークフローの手順）を提案します。

RTE 生成のトラブルシューティング

1. 生成フェーズを特定します。
   • 生成前（検証） — 生成前に検出された ARXML スキーマエラー。
   • コントラクトフェーズ — Rte_<SWCName>.h の生成が失敗します（ポート／ランナブル／データ型）。
   • 実装フェーズ — Rte_<SWCName>.c の生成が失敗します（OS タスクのマッピング、スケジューラー、ExclusiveArea）。
   • 生成後のビルド — 生成されたヘッダーによってコンパイルエラーが発生します（型の不一致、インクルードの欠落）。
2. エラーを分類します。
   • コンポジション内の未接続ポート → 委譲ポートまたはコネクターの不足。
   • ComSpec の非互換性 → 送信側／受信側の InitValue の型不一致。
   • OS タスクが見つからない → ランナブルの TimingEvent が、OS 設定から削除されたタスクを参照しています。
   • ExclusiveArea がマッピングされていない → ExclusiveArea は宣言されていますが、OsResource が割り当てられていません。
   • #include "Rte_<SWC>.h" が見つからない → 生成出力パスがコンパイラーのインクルードパスに含まれていません。
3. EB Tresos のコンテナーパスまたは DaVinci の設定場所を示して、正確な修正方法を提示します。
4. 再ビルドの前に、修正後の検証手順を提示します。

COM スタックのデバッグ

1. 症状を分類します — 最初に調べるレイヤーは、SWC から見える状態によって異なります。
   • 信号がまったくない（常に初期値）→ CanDrv のフィルター／コントローラーの状態。
   • 定数値が誤っている → Com 信号設定（バイトオーダー、スケーリング、ビット位置）。
   • 間欠的に発生する → CanIf の RX バッファーオーバーフロー、または Com_MainFunction* タスクのオーバーラン。
   • しばらくすると初期値に戻る → Com の ComTimeout が発生しています。
   • CAN トレースには信号があるが、SWC では初期値になる → CanIf フィルター／PduR ルーティングの不足。
   • SWC が書き込んでもバスに何も出ない（TX）→ Com_SendSignal の戻り値と Com_MainFunctionTx。
   • TX が間欠的に発生する → ComTxModeMode、ComMinimumDelayTime、CanIf メールボックスの輻輳。
2. まずバスレベルを確認します — 実際にバス上に流れている信号を確認する前に、スタックのデバッグを始めないでください（CANalyzer、BusMaster、candump、PCAN-View）。バスに何も出ない TX の場合は、ハードウェアを確認します。終端抵抗（60 Ω）、トランシーバーが Sleep 状態でないこと、CAN_H/CAN_L が入れ替わっていないこと、バスオフ状態でないことを確認してください。
3. パスを上から順にたどります（RX または TX）。CanDrv → CanIf → PduR → Com → RTE/SWC の順です。レイヤーごとの完全なチェックリストは references/com-stack.md を参照してください。
4. プローブで確認します：DET フック（CANIF_DEV_ERROR_DETECT、COM_DEV_ERROR_DETECT）、コールバック内のカウンター（ComNotification、CanIf_RxIndication ユーザー）、デバッグポートのマッピング、NvM トレースブロック。
5. よくあるアンチパターンに注意します：
   • CanIf Rx PDU のマスクからランタイム ID が除外されている。
   • ComSignalEndianness が DBC と一致していない（@1+ = LITTLE_ENDIAN、@0+ = BIG_ENDIAN）。
   • Motorola 信号について、DBC と AUTOSAR の ComBitPosition が異なる。
   • Com_MainFunctionRx／Com_MainFunctionTx が、優先度の異なる別々の OS タスクで実行されている。
   • ALWAYS 以外の ComFilterAlgorithm によって値が通知されずに破棄されている。
6. 変更が必要なコンテナーを正確に示し、予防ルールを一行で添えて、調査結果を記録します。

ブート、NVM、電源管理

入力から該当するサブ領域を選び、詳細については references/boot-nvm-power.md を参照してください。

1. ブート／起動 — 初期化順序を明確にし、問題の発生箇所を特定します。
   • ベアメタル：リセットベクター → スタートアップ（スタックとクロックの初期化、.data のフラッシュからのコピー、.bss のゼロ初期化）→ C ランタイム → main。
   • クラシック AUTOSAR：EcuM（StartPreOS → StartOS → StartPostOS）、BswM によるモード調停、ドライバーの初期化順序（MCAL → BSW → RTE → SWC）。依存関係の順序に反して初期化されるモジュールがあれば指摘します。
   • ブートローダー／再プログラミング：UDS のフラッシュダウンロードシーケンス（0x10 プログラミングセッション → 0x27 セキュリティアクセス → 0x34 RequestDownload → 0x36 TransferData → 0x37 RequestTransferExit → 0x31 RoutineControl による消去／チェック → ECU リセット）。デュアルバンク／A-B 構成、アプリケーション有効性マーカー、アプリケーションへのジャンプ前のチェックサム／CRC ゲートに言及します。
2. NVM ストレージスタック — 永続化を確実にします。
   • NvM ブロック：タイプ（ネイティブ／冗長／データセット）、サイズ、RAM ミラー、CRC（CRC16/32）、書き込みポリシー（即時／遅延）、書き込み保護、初回初期化時のデフォルト値。
   • MemIf を介した Fee/Ea：セクター管理、基盤となるフラッシュ／EEPROM ドライバー、NvM の読み取り一括／書き込み一括処理がこれらをどのように通るか。
   • ウェアレベリング：セクターをローテーションし、車両寿命を考慮して消去サイクルの予算を立て、書き込み増幅に注意します。
3. 電源／状態管理 — スリープとシャットダウンを安全に制御します。
   • EcuM のスリープ／ウェイクアップ状態遷移（RUN → GoSleep → SLEEP → ウェイクアップ検証）、ウェイクアップソースと検証。
   • 部分ネットワーク：PNC、トランシーバーの選択的ウェイクアップ、ComM/Nm の連携。
   • BswM アクションリストによる順序付きシャットダウン。電源オフ前に NvM_WriteAll が利用可能な時間内に完了することを保証します。
   • 低消費電力 MCU モード（SLEEP／STOP／STANDBY）、クロックゲーティング、周辺機器の電源オフ。

初期化／シャットダウンの順序制約と、該当する場合は時間予算（例：スリープ前の NvM_WriteAll）を必ず明示してください。

通信プロトコル

通信経路を実装または設定します（壊れた信号のデバッグは、COMスタックのデバッグに該当します）。サブ領域を選び、詳しく説明する際は references/comms-protocol.md を参照してください。

1. 車載バス（CAN／CAN FD／LIN）：
   • CAN／CAN FD：フレームレイアウトと信号のパッキング（開始ビット、長さ、バイトオーダー @1+ Intel／@0+ Motorola、係数／オフセット）、DLCから長さへのマッピング、CAN FDのビットレート切り替え（BRS）と64バイトのペイロード、送信モード（周期／変更時／混合）。信号が安全に関わる場合は、E2E保護（カウンター＋CRC）を追加します。
   • LIN：スケジュールテーブル（フレームスロットとタイミング）、マスター／スレーブの応答ロール、応答タイムアウト、LINチェックサムモデル（クラシック／拡張）。
2. トランスポートとルーティング（CanTp／PduR）：
   • 8バイト（CAN）／64バイト（CAN FD）を超えるペイロードのCanTpセグメンテーション：First Frame／Consecutive Frame／Flow Control、ブロックサイズ（BS）と分離時間（STmin）、N_As／N_Bs／N_Crタイムアウト。
   • PduRのルーティングパス（信号／PDU／TPルーティング）、チャネル間のゲートウェイルーティング、DcmおよびComとの間のルーティング。
3. ネットワーク管理（ComM／Nm）と部分ネットワーク：
   • ComMのチャネルとユーザー（フル通信／通信なしのリクエスト）、Nmの状態マシン（Repeat Message -> Normal Operation -> Ready Sleep -> Bus Sleep）、および全ノードが同時にスリープするための協調シャットダウン。
   • Partial Network Cluster（PNC）と選択的トランシーバーウェイクアップ（Boot, NVM & power の電源管理を相互参照してください）。
4. バス経由の診断（UDS／Dcm）：
   • 標準のNRCチェック順序でUDSサービスハンドラーを実装します：メッセージ長 -> サービス対応状況 -> サブファンクション対応状況 -> セッションチェック -> セキュリティチェック -> 条件チェック -> リクエストデータの検証。正しいNRCを返します（0x13 長さ、0x11／0x12 未対応、0x7E／0x7F サブファンクション、0x31 範囲外、0x33 セキュリティ拒否、0x22 条件不成立）。
   • ISO 14229のDTCステータスバイト：ビットを直接操作しないでください。Dem（Dem_SetEventStatus／Dem_ReportErrorStatus）を通じて報告し、testFailed／pendingDTC／confirmedDTC、デバウンス、エージングはDemに管理させます。（Dcm／Dem自体の設定については BSW configuration を参照してください。）
5. サービス指向イーサネット（SOME/IP／DoIP）：
   • SOME/IP：メッセージ形式（メッセージID = サービスID＋メソッド／イベントID、リクエストID、プロトコル／インターフェースバージョン、メッセージタイプ、リターンコード）とシリアライズ規則。サービスディスカバリーのハンドシェイク（OfferService／FindService／SubscribeEventgroup／SubscribeEventgroupAck）、イベントグループ、ユニキャストとマルチキャストによるイベント配信。
   • DoIP（ISO 13400）：車両アナウンス／識別、ルーティングアクティベーションのハンドシェイク（リクエスト -> アクティベーションタイプと論理アドレスを含むレスポンス）、続いてDoIP経由のUDS。ClassicではSoAd＋SOME/IPモジュール上で動作し、Adaptiveではara::comが提供します（プラットフォームを明記してください）。

レイアウト／シーケンス、タイミング制約（周期、CanTpのSTmin／BS、NMタイマー、SD TTL）、およびイーサネットのサブ領域がClassic-over-SoAdまたはAdaptive-over-ara::comのどちらになり得るかに応じたプラットフォームを記載してください。

想定される入力

• BSW 設定：BSW モジュールに必要な動作の説明。既存の設定抜粋、EB Tresos のエラーログ、DaVinci の検証出力は任意です。
• ARXML デバッグ：EB Tresos の検証ログ、DaVinci のエラー出力、RTE ジェネレーターのエラー、または生の ARXML 抜粋。影響を受ける SWC 名とポート名は任意です。
• RTE 生成のトラブルシューティング：EB Tresos RTE ジェネレーターのログ、または DaVinci の検証／生成エラー。コンポジション図の説明、OS 設定の抜粋、影響を受ける SWC 名は任意です。
• COM スタックのデバッグ：症状の説明（CAN ID／信号／SWC ポート、RX または TX、観測値とバス上の値）。EB Tresos .epc／DaVinci .dpa の設定スニペット（CanIf、PduR、Com）、DBC の抜粋、オシロスコープまたは CAN トレース、対象信号の ASIL は任意です。
• ブート、NVM、電源：必要な動作（起動／シャットダウン時の動作、保存対象と保存タイミング、スリープ／ウェイクアップまたは再プログラミングの要件）。MCU とメモリレイアウト、EcuM／BswM／NvM 設定の抜粋、観測された症状（スリープ後にデータが失われる、ECU がブートローダーで停止する、ウェイクアップが処理されないなど）、保存／制御データの ASIL は任意です。
• 通信プロトコル：実装する通信経路（バスとプロトコル、信号またはサービス、方向）。DBC／LDF／ARXML／FIBEX の抜粋、CAN ID とペイロード、SOME/IP サービス ID とイベントグループ ID、DoIP 論理アドレス、UDS サービスと DID の一覧、目標周期／タイムアウト値、データの ASIL は任意です。

出力形式

すべての応答は、1 行のプラットフォームヘッダーで始めます：Platform: Classic (CP) または Platform: Adaptive (AP)。Adaptive の場合は、references/adaptive-ap.md の AP レポートレイアウトを使用します。それ以外の場合は、以下の Classic レイアウトを使用します。

BSW 設定

## BSW Configuration: <Module(s)>

### Dependency Chain
[Which modules must be configured first and why]

### Configuration Steps
#### <ModuleName>
1. [Step with specific container path in EB Tresos / DaVinci]
2. ...

### Configuration Parameter Table
| Container | Parameter | Value | Notes |
|-----------|-----------|-------|-------|
...

### Common Errors & Resolutions
| Error | Root Cause | Fix |
|-------|------------|-----|
...

### Validation Checklist
- [ ] [Item]

ARXML デバッグ

## ARXML Debug Report

### Error Classification
[Error type and one-line root cause]

### Root Cause Location
- Package path: `/AUTOSAR/<Package>/...`
- Container: `<ContainerName>`
- Attribute: `<AttributeName>`
- Explanation: [why this is wrong]

### Fix
```xml

[broken fragment]


[corrected fragment]
```

### What Changed
[One sentence]

### Prevention
[Rule or process step to avoid this class of error]

RTE 生成のトラブルシューティング

## RTE Generation Troubleshoot

### Generation Phase
[Pre-generation | Contract phase | Implementation phase | Post-generation build]

### Error Classification
[Type and one-line root cause]

### Root Cause
[Exact ARXML path, EB Tresos container, or DaVinci configuration location]

### Fix
[Step-by-step with container paths or ARXML fragment]

### Post-Fix Validation
[What to check before triggering regeneration]

COM スタックのデバッグ

## COM Stack Debug Report

### Symptom Classification
[One-line — failure class and first layer suspected]

### Bus-Level Confirmation
[CAN trace shows — frame present? right ID? right DLC? right cycle?]

### Layer Walk
| Layer    | Check | Expected | Observed / Next Probe |
|----------|-------|----------|------------------------|
| CanDrv   | …     | …        | …                      |
| CanIf    | …     | …        | …                      |
| PduR     | …     | …        | …                      |
| Com      | …     | …        | …                      |
| RTE/SWC  | …     | …        | …                      |

### Most Likely Root Cause
[Single most probable container + attribute, one-sentence explanation]

### Configuration Fix
```
Container: [path]
Attribute: [name]
Before:    [value]
After:     [value]
Why:       [one sentence]
```

### Verification Steps
1. [Concrete check confirming the fix]
2. ...

### Safety Impact
[None / signal is ASIL-X — re-verification scope and safety case update required]

### Prevention Rule
[One-line rule the team can adopt to prevent recurrence]

ブート、NVM、電源

## Boot / NVM / Power: <topic>

### Sequence / State Machine
[Ordered steps or state transitions — e.g. EcuM phases, UDS reprogramming sequence, sleep/wakeup states]

### Configuration
| Module / Container | Parameter | Value | Notes |
|--------------------|-----------|-------|-------|
...

### Init / Shutdown Order
[Driver init order or shutdown action list, stating what must precede what, with any timing budget]

### Pitfalls & Resolutions
| Pitfall | Consequence | Fix |
|---------|-------------|-----|
...

### Validation Checklist
- [ ] [Item]

通信プロトコル

## Communication: <protocol / topic>

### Layout / Sequence
[Frame or PDU layout, LIN schedule, CanTp segmentation, UDS NRC order, SOME/IP-SD handshake, or DoIP routing-activation sequence]

### Configuration
| Module / Container | Parameter | Value | Notes |
|--------------------|-----------|-------|-------|
...

### Timing / Constraints
[Cycle times, CanTp STmin / BS, NM timers, SD TTL, UDS P2/P2* timeouts, E2E counter/CRC]

### Pitfalls & Resolutions
| Pitfall | Consequence | Fix |
|---------|-------------|-----|
...

### Validation Checklist
- [ ] [Item]

例

例 1 — BSW 設定（Dem + NvM）

入力： SWC からの Dem_SetEventStatus 呼び出しにより、「Cell Overvoltage」DTC（0x010203）を報告するよう Dem を設定します。カウンターベースのデバウンスを使用し、連続 5 回の呼び出しで失敗、3 回で合格とします。プライマリーイベントメモリに保存します。NvM を介して電源サイクルをまたいで保持します。

出力：

## BSW Configuration: Dem (+ NvM dependency)

### Dependency Chain
NvM must be configured first (NvM block for Dem event memory) → MemIf/Fee → Dem.

### Configuration Steps
#### Dem
1. `/Dem/DemConfigSet/DemEventParameter` → Add `DemEvent_CellOvervoltage`
2. `DemDTCRef` → create `/Dem/DemConfigSet/DemDTC/DTC_CellOvervoltage`
3. `DemDTCValue`: `0x010203`
4. `DemDTCSeverity`: `DEM_SEVERITY_MAINTENANCE_ONLY` (adjust per HARA)
5. `DemDebounceAlgorithmClass` → `DEM_DEBOUNCE_COUNTER_BASED`
6. `DemDebounceCounterIncrStepSize`: 1; `DemDebounceCounterDecrStepSize`: 1
7. `DemDebounceCounterFailedThreshold`: 5; `DemDebounceCounterPassedThreshold`: 3
8. `DemEventKind`: `DEM_EVENT_KIND_SWC`
9. `DemOperationCycleRef` → `DemOperationCycle_PowerCycle`
10. `DemStorageConditionRef` → none (always store)
11. `DemEnableConditionRef` → none, or link to voltage plausibility condition

#### NvM (event memory block)
1. Dem generates an NvM block reference — verify `DemNvRamBlockId` is assigned.
2. NvM block size = Dem primary event memory size (from Dem generator output).
3. `NvMWriteBlockOnce`: FALSE; `NvMCrcType`: CRC16; `NvMBlockUseCrc`: TRUE.

### Common Errors & Resolutions
| Error                              | Root Cause                              | Fix                                            |
|------------------------------------|-----------------------------------------|------------------------------------------------|
| `DEM_E_NO_DTC_AVAILABLE` at runtime| DTC value not unique or out of range    | Verify 3-byte DTC value unique in DemDTC list   |
| Event stuck in PREPASSED            | PassedThreshold never reached           | Confirm `Dem_SetEventStatus(PASSED)` is called |
| NvM block size mismatch            | Dem config changed after NvM block set  | Regenerate Dem, then re-check NvM block size   |

### Validation Checklist
- [ ] DTC value 0x010203 unique across all DemDTC entries
- [ ] DemEvent_CellOvervoltage referenced in SWC ARXML (DemEventRef in SWC InternalBehavior)
- [ ] `Dem_SetEventStatus(DEM_EVENT_STATUS_FAILED/PASSED)` called correctly in SWC runnable
- [ ] NvM block for Dem event memory included in `NvM_WriteAll` cycle
- [ ] `Dem_MainFunction` period matches OS task period (typically 10 ms)

例 2 — COM スタックのデバッグ（RX、誤った値）

入力： SWC EngineCtrl_AppSWC は、CAN ID 0x123（パワートレインバス、500 kbit/s、周期 10 ms）の R ポート RVehicleSpeed から信号 EngineSpeed_rpm を読み取ります。SWC では回転数が常に 0 rpm と観測されます。CAN トレースでは、ペイロード [20 03 00 00 00 00 00 00]（リトルエンディアンの 0x0320 = 800 rpm、信号はバイト 0～1、係数 1、オフセット 0）を含む 0x123 が 10 ms ごとに確認できます。DBC では信号が @1+（Intel バイトオーダー）と定義されています。ASIL-QM。ほかの同一 PDU 上の信号は正常に受信されています。

出力：

## COM Stack Debug Report

### Symptom Classification
RX direction; "wrong value, constant" — bus has the right data, SWC sees init.
Other signals from the same PDU are correct, exonerating CanDrv, CanIf, PduR, and PDU-level
Com config. Fault is at **Com signal level** for this one signal.

### Bus-Level Confirmation
Frame present every 10 ms, ID 0x123, DLC 8, payload `[20 03 …]` = `0x0320` = 800.
Sender healthy; receive stack is the suspect.

### Layer Walk
| Layer    | Check                                              | Expected         | Observed / Next Probe                  |
|----------|----------------------------------------------------|------------------|----------------------------------------|
| CanDrv   | Controller `CAN_CS_STARTED`                         | Started          | Other signals OK → pass                |
| CanIf    | `CanIfRxPduCfg` for ID 0x123 routes to PduR        | UL = PDUR        | Pass                                   |
| PduR     | `PduRRoutingPath` Src=CanIf, Dest=Com               | `PDUR_COM`        | Pass                                   |
| Com      | `ComSignal.ComSignalEndianness`                    | LITTLE_ENDIAN    | **Set to BIG_ENDIAN — root cause**      |
| Com      | `ComBitPosition`                                   | 0 (Intel start)  | Confirm against DBC                    |
| RTE/SWC  | `Rte_Read_RVehicleSpeed_EngineSpeed_rpm` reads     | 800              | Sees `0x2003` byte-swapped → 0 after scaling |

### Most Likely Root Cause
**`ComSignal.ComSignalEndianness` is set to `BIG_ENDIAN` while DBC defines `@1+` (Intel).**
Com unpacks bytes in the wrong order; raw value becomes `0x2003`, then any clamp/range check
downstream filters it back to 0 / init.

### Configuration Fix
```
Container: /AUTOSAR/EcuC/Com/ComConfig/ComSignal_EngineSpeed_rpm
Attribute: ComSignalEndianness
Before:    BIG_ENDIAN
After:     LITTLE_ENDIAN
Why:       DBC signal is @1+ (Intel); receiver byte order must match sender.
```

### Verification Steps
1. Apply fix, regenerate Com, rebuild.
2. On the next bench run with the same recorded trace, confirm SWC observes 800 rpm.
3. Add a counter inside the `ComNotification` callback for this signal — it should match the
   bus cycle count (~100/s for a 10 ms PDU).
4. Sweep 50–8000 rpm with a bus replay tool — confirm linearity, rule out residual scaling.

### Safety Impact
ASIL-QM signal — no formal safety case update required. If a higher-ASIL signal sits in the
same PDU, re-verify it after Com regenerate to confirm no regression.

### Prevention Rule
When importing a DBC into AUTOSAR Com, cross-check `ComSignalEndianness` for every signal
against the DBC `@0+` / `@1+` field. EB Tresos DBC importer's default depends on the chosen
profile and silently picks BIG_ENDIAN for some toolchain versions. Add a one-line post-import
script that diffs DBC byte order against generated Com config.

例 3 — ブート、NVM、電源（スリープ前のキャリブレーション値の保持）

入力： ボディコントロールユニット、ARM Cortex-M、AUTOSAR Classic 4.3、EB Tresos。ECU は実行時にキャリブレーション値（ミラー格納位置）を学習し、これを保持する必要があります。症状：車両がスリープすると（イグニッションオフ）、学習値が失われ、次回のウェイクアップ時にデフォルト値に戻ることがあります。NvM ブロックは遅延書き込みに設定されています。ASIL-QM。この値を確実に保持するには、EcuM と NvM をどのように設定すればよいですか？

出力：

Platform: Classic (CP)

## Boot / NVM / Power: persist learned calibration across sleep

### Sequence / State Machine
EcuM shutdown path on ignition-off:
RUN -> EcuM_GoDown request -> BswM shutdown action list -> NvM_WriteAll -> wait for NvM jobs to
finish (NvM_GetStatus == NVM_IDLE) -> transceiver to Sleep -> MCU low-power.
The data loss happens because the deferred NvM block is still queued when power is cut: BswM
triggers sleep before NvM_WriteAll has flushed the block to Fee/flash.

### Configuration
| Module / Container | Parameter | Value | Notes |
|--------------------|-----------|-------|-------|
| NvM block (MirrorFold) | `NvMBlockManagementType` | `NVM_BLOCK_REDUNDANT` | Two copies; survives a single corrupted sector |
| NvM block | `NvMBlockUseCrc` / `NvMCrcType` | TRUE / CRC16 | Detect torn write on the next read |
| NvM block | `NvMSelectBlockForWriteAll` | TRUE | Include it in the WriteAll sweep run at shutdown |
| NvM block | `NvMWriteBlockOnce` | FALSE | Value changes over life; not write-once |
| NvM | `NvMDynamicConfiguration` | per project | Confirm default value applied on first-ever init only |
| BswM rule | shutdown action list | `NvM_WriteAll` then poll | Must precede the sleep action |
| EcuM | `EcuMNvramReadAllTimeout` / write budget | sized to block set | WriteAll for all blocks must fit the hold-up time |

### Init / Shutdown Order
1. Read path at startup: EcuM `StartPostOS` -> `NvM_ReadAll` -> RAM mirror populated -> SWC reads
   the mirror in its init runnable (not before NvM_ReadAll completes).
2. Shutdown: BswM action list MUST run `NvM_WriteAll`, then gate the transition to sleep on
   `NvM_GetStatus() == NVM_IDLE` (or the `NvM_JobEndNotification`). Only then command transceiver
   Sleep and MCU low-power. Budget: confirm worst-case WriteAll time < board hold-up time after
   ignition-off (decoupling-cap / hold-up circuit).

### Pitfalls & Resolutions
| Pitfall | Consequence | Fix |
|---------|-------------|-----|
| Sleep entered before WriteAll flushes | Deferred block lost on power cut | Gate sleep on NvM idle, as above |
| Single (native) block + torn write | Corrupted value, no fallback | Use `NVM_BLOCK_REDUNDANT` + CRC |
| SWC reads mirror before NvM_ReadAll done | Reads stale/default at startup | Read only in/after init runnable post-ReadAll |
| WriteAll time exceeds hold-up | Partial write, corruption | Reduce block set in WriteAll, or write the block immediately on change |

### Validation Checklist
- [ ] MirrorFold block is `NVM_SELECT_BLOCK_FOR_WRITE_ALL` and appears in the WriteAll set
- [ ] BswM shutdown list calls `NvM_WriteAll` and waits for `NVM_IDLE` before sleep
- [ ] Worst-case WriteAll time measured and < board hold-up time after ignition-off
- [ ] Redundant block + CRC verified by fault-injecting a corrupted sector and confirming recovery
- [ ] SWC reads the RAM mirror only after `NvM_ReadAll` completes at startup

Verified against: EcuM shutdown ordering, NvM block descriptor options, WriteAll-before-sleep
timing requirement; could not verify: the actual board hold-up time, generated NvM block sizes,
and the live BswM action-list configuration (need the project config).

例 4 — 通信プロトコル（SOME/IP イベントを受信できない）

入力： コンシューマー ECU は、Automotive Ethernet 経由でシャーシ ECU が提供する SOME/IP サービスの BrakeStatus イベントグループにサブスクライブしていますが、BrakePressure イベントをまったく受信しません。プロバイダーがサービスを提供していることは確認済みです（ワイヤー上で OfferService を確認）。サービス ID 0x1234、インスタンス ID 0x0001、イベントグループ ID 0x0002、イベント ID 0x8001 です。サブスクライブ経路はどのように設定すればよく、最も可能性の高い原因は何ですか？

出力：

Platform: Classic (CP) over SoAd + SOME/IP (same flow applies on Adaptive ara::com)

## Communication: SOME/IP eventgroup subscription (BrakeStatus)

### Layout / Sequence
SOME/IP-SD subscribe handshake (consumer side):
1. Provider multicasts/unicasts OfferService (service 0x1234, instance 0x0001) with its endpoint
   (IP + port, UDP and/or TCP).
2. Consumer sends SubscribeEventgroup (eventgroup 0x0002) to the provider's SD endpoint, carrying
   the consumer's own endpoint where events should be delivered.
3. Provider replies SubscribeEventgroupAck (or Nack). Only after Ack does the provider start
   sending the eventgroup's events (event 0x8001) to the consumer endpoint.
Events with message-type NOTIFICATION carry message ID = service 0x1234 + event 0x8001.

### Configuration
| Module / Container | Parameter | Value | Notes |
|--------------------|-----------|-------|-------|
| Service consumed | Service ID / Instance | 0x1234 / 0x0001 | Must match the OfferService exactly |
| Eventgroup | Eventgroup ID | 0x0002 | Subscribe targets the eventgroup, not the event |
| Consumer endpoint | IP : port (UDP) | <consumer ip>:<port> | The address the provider sends events to |
| SD | TTL on subscribe | > 0, renewed | TTL 0 means "stop subscription" |
| Transport | UDP vs TCP | match provider offer | Mismatch -> no delivery |
| Eth/IP | multicast group + IGMP | joined | If events are multicast, the consumer must join the group |

### Timing / Constraints
- Subscription TTL must be renewed before it expires, or the provider drops the subscription and
  events silently stop.
- SD initial-wait / repetition timing affects how fast subscribe follows offer.

### Pitfalls & Resolutions
| Pitfall | Consequence | Fix |
|---------|-------------|-----|
| Subscribe sent but no Ack | Provider never starts events | Check eventgroup ID and that consumer endpoint is reachable (routing/VLAN/firewall) |
| Events are multicast, consumer not in group | Frames never reach the consumer NIC | Join the multicast group (IGMP); verify switch multicast forwarding |
| UDP/TCP mismatch vs offer | No delivery | Subscribe on the transport the provider offered |
| TTL not renewed | Events stop after TTL | Renew subscription; confirm cyclic SD offer/subscribe |
| Wrong instance ID (0xFFFF vs 0x0001) | Subscribe to nothing | Match the offered instance exactly |

### Validation Checklist
- [ ] OfferService for 0x1234/0x0001 observed; capture the offered endpoint and transport
- [ ] SubscribeEventgroup 0x0002 sent to the provider SD endpoint with a non-zero TTL
- [ ] SubscribeEventgroupAck received (if Nack, eventgroup/endpoint mismatch)
- [ ] If multicast: consumer joined the group and the Ethernet switch forwards it
- [ ] Event 0x8001 NOTIFICATION arriving at the consumer endpoint after Ack

Most likely cause: the SubscribeEventgroup is not being Ack'd - usually an eventgroup-ID or
consumer-endpoint/reachability mismatch, or (for multicast events) the consumer never joined the
multicast group. Confirm on the wire which step of the handshake stops.

Verified against: the SOME/IP-SD offer/subscribe/ack ordering and event message-ID composition;
could not verify: the live SD trace, the actual offered endpoint/transport, and switch multicast
configuration (need a capture and the network config).