# AUTOSAR CAN 需求分析文件

## 修訂記錄

| 日期 | 版本 | 變更內容 | 作者 | 批准人 |
|------|------|----------|------|--------|
| 2024/10/04 | V0.1.0 | 初始版本 | Assistant | - |

## 1. 目的

本文檔旨在詳細定義和描述基於AUTOSAR標準的CAN通信系統的軟體需求。這些需求將指導CAN通信模塊的開發,確保其符合AUTOSAR標準,並滿足可重用性、可移植性、可維護性和可追朔性的要求。

## 2. 適用範圍

本文檔涵蓋了AUTOSAR架構下CAN通信系統的軟體需求,包括但不限於:
- CAN驅動層(MCAL)
- CAN硬體抽象層(HAL)
- CAN介面(BSW)
- CAN相關的應用層功能(SWC)

## 3. 縮寫和定義

### 3.1 名詞和定義

| 名詞 | 定義 |
|------|------|
| AUTOSAR | AUTomotive Open System ARchitecture,汽車開放系統架構 |
| CAN | Controller Area Network,控制器局域網絡 |

### 3.2 縮寫

| 縮寫 | 描述 |
|------|------|
| SWC | Software Component |
| BSW | Basic Software |
| MCAL | Microcontroller Abstraction Layer |
| HAL | Hardware Abstraction Layer |

## 4. 概述

### 4.1 軟體概述

AUTOSAR CAN通信系統主要分為四個層次:

1. SWC (軟體組件層): 包含使用CAN通信的應用功能。
2. BSW (基礎軟體層): 提供CAN通信服務和協議。
3. MCAL (微控制器抽象層): 提供CAN控制器驅動。
4. Hardware (硬體層): CAN控制器和收發器。

### 4.1 軟體概述

AUTOSAR CAN通信系統主要分為四個層次，從上到下依次為SWC、BSW、MCAL和Hardware。每一層都有其特定的功能和職責，共同構成了完整的CAN通信系統。以下是對每一層的詳細描述：

#### 1. SWC (軟體組件層)

SWC層是最上層，直接面向應用開發的層次。

- **主要功能**：包含使用CAN通信的應用功能。
- **組件示例**：
- 車身控制應用
- 發動機管理系統
- 安全系統（如防抱死制動系統ABS）
- **特點**：
- 高度抽象，不直接處理硬體細節
- 可移植性強，可以在不同的ECU上重用
- 通過RTE（Runtime Environment）與下層通信
- **開發重點**：
- 實現具體的業務邏輯
- 定義清晰的軟體組件接口

#### 2. BSW (基礎軟體層)

BSW層提供了標準化的服務和通信協議實現。

- **主要功能**：提供CAN通信服務和協議。
- **組件示例**：
- CAN通信棧（CAN Stack）
- 診斷協議模塊
- 網絡管理（NM）模塊
- **特點**：
- 實現標準化的AUTOSAR服務
- 管理CAN消息的發送和接收
- 處理通信協議細節（如消息包裝、解包等）
- **開發重點**：
- 確保與AUTOSAR標準的兼容性
- 優化性能和資源使用
- 實現可靠的錯誤處理機制

#### 3. MCAL (微控制器抽象層)

MCAL層直接與硬體交互，為上層提供標準化的接口。

- **主要功能**：提供CAN控制器驅動。
- **組件示例**：
- CAN控制器驅動
- 中斷處理程序
- 時鐘配置模塊
- **特點**：
- 屏蔽硬體差異，提供統一的API
- 通常由微控制器供應商提供
- 需要符合功能安全標準（如ISO 26262）
- **開發重點**：
- 優化驅動性能
- 確保對不同CAN控制器的兼容性
- 實現精確的時序控制

#### 4. Hardware (硬體層)

硬體層是整個系統的基礎，包括實際的物理設備。

- **主要組件**：
- CAN控制器：負責CAN協議的底層實現
- CAN收發器：負責CAN信號的物理層轉換
- **特點**：
- 直接與物理CAN總線連接
- 決定了系統的基本性能參數（如最大傳輸速率）
- **選擇重點**：
- 根據應用需求選擇適當的CAN控制器和收發器
- 考慮電磁兼容性（EMC）要求
- 評估功耗和成本因素

通過這種分層設計，AUTOSAR CAN通信系統實現了高度的模塊化和標準化，有利於軟體的重用、維護和升級。每一層都有明確的職責，通過定義良好的接口相互協作，共同實現複雜的CAN通信功能。

### 4.2 約束

- 軟體抽象和隔離：

- 本項目主要實現了軟體層（SWC和BSW）的抽象和隔離。
純軟體層的代碼設計應盡可能獨立於特定的硬體平台。

- 硬體相關限制：

- MCAL層並非完全符合AUTOSAR標準，不能直接套用於不同的CAN收發器。
- 對於不同的MCU和CAN收發器，MCAL層的代碼需要重新編寫或大幅調整。

- 可移植性限制：

- 只有SWC和BSW層具有較高的可移植性。
- MCAL層的可移植性有限，需要根據具體的硬體平台進行適配。

- 標準兼容性：

- 雖然整體設計參考了AUTOSAR的思想，但並不完全符合AUTOSAR標準。
重點在於實現軟體架構的模塊化和層次化，而非嚴格遵循AUTOSAR標準。

- 開發靈活性：

- 允許在必要時對架構進行適當調整，以適應項目特定需求。
在保持整體架構思想的同時，可以根據實際情況做出妥協。

- 測試和驗證：

- 由於硬體相關性，完整的系統測試需要在目標硬體平台上進行。
純軟體層可以進行獨立的單元測試和模擬測試。

這些約束反映了項目的實際情況，強調了軟體層的抽象和隔離，同時明確了在硬體相關層面的限制。這有助於開發團隊更好地理解項目的範圍，並在開發過程中做出適當的決策。

### 4.3 假設和相依

1. CAN收發器硬體:
- 假設使用NXP公司的TJA1153 CAN收發器。
- TJA1153支持CAN FD (Flexible Data-rate),可兼容傳統CAN和高速CAN FD通信。

2. TJA1153主要特性:
- 支持的協議: ISO 11898-2:2016, ISO 11898-1:2015
- 數據傳輸速率:
- 傳統CAN模式下最高1 Mbit/s
- CAN FD模式下最高5 Mbit/s
- 工作電壓範圍: 4.5V to 5.5V
- 工作溫度範圍: -40°C to +125°C
- 低功耗模式支持,適合電池供電的應用

3. MCU接口要求:
- 使用NXP S32K344微控制器,具有以下與CAN通信相關的特性:
a. CAN控制器:
- 包含4個增强型CAN FD控制器(CAN_FD)
- 支持ISO 11898-1:2015標準
- 支持傳統CAN和CAN FD協議
- 最高位速率可達8 Mbit/s (CAN FD模式)

b. GPIO接口:
- 提供足夠的可配置GPIO接口用於控制TJA1153
- 可用於實現STB (Standby)、EN (Enable)等控制信號

c. 中斷支持:
- 支持CAN控制器相關的中斷
- 可配置ERR (Error)和WAKE (Wakeup)信號為中斷源

d. 時鐘管理:
- 提供靈活的時鐘配置,以滿足CAN通信的時序要求
- 支持精確的位時序配置

e. DMA支持:
- 具備DMA控制器,可用於優化CAN數據傳輸

f. 低功耗模式:
- 提供多種低功耗模式,可與TJA1153的低功耗特性配合使用

g. 診斷和安全特性:
- 支持CAN總線故障診斷
- 具備硬件安全模塊(HSM),增強系統安全性

- 接口配置要求:
a. CAN_TX和CAN_RX信號需正確連接到S32K344的相應CAN控制器引腳
b. TJA1153的STB和EN引腳需連接到S32K344的可控GPIO
c. TJA1153的ERR和WAKE信號應連接到S32K344的中斷capable引腳
d. 必須遵循S32K344數據手冊中關於CAN接口的佈線和阻抗匹配建議

- 軟件配置考慮:
a. MCAL層需要正確配置S32K344的CAN控制器,包括位時序、濾波器等
b. 需要實現S32K344 CAN控制器的中斷服務程序(ISR)
c. 利用S32K344的DMA功能優化CAN數據傳輸
d. 實現電源管理策略,協調S32K344和TJA1153的低功耗模式
e. 利用S32K344的診斷功能增強系統可靠性

這些MCU接口要求為基於S32K344和TJA1153的CAN通信系統開發提供了具體的硬件接口上下文。開發團隊需要在軟件設計和實現過程中充分考慮這些硬件特性和要求。

4. 軟體設計相依:
- MCAL層需要根據TJA1153的具體特性進行開發,包括初始化配置、模式切換等。
- BSW層的CAN驅動需要支持TJA1153提供的所有功能,如CAN FD支持、低功耗模式等。

5. 電源管理:
- 系統設計需考慮TJA1153的電源需求,確保在所有工作模式下提供穩定的電源。
- 軟體需要實現TJA1153的低功耗模式管理,以優化系統的整體功耗。

6. 電磁兼容性(EMC):
- 系統設計需符合TJA1153的EMC特性,確保在車載環境中的可靠運行。
- PCB設計需遵循TJA1153數據手冊中的佈線建議,以確保信號完整性。

7. 診斷功能:
- 軟體需要利用TJA1153提供的診斷功能,如過熱保護、短路檢測等。
- 需要實現對TJA1153狀態的實時監控和錯誤處理機制。

8. 開發工具和環境:
- 假設使用支持TJA1153配置和調試的開發工具。
- 測試環境需要能夠模擬TJA1153在各種工作條件下的行為。

9. 標準符合性:
- 雖然整體架構參考AUTOSAR,但TJA1153相關的底層實現需要嚴格遵循NXP提供的技術規範。
- 系統設計需同時滿足汽車電子系統的相關標準要求。

這些假設和相依條件為基於TJA1153 CAN收發器的CAN通信系統開發提供了具體的硬體上下文。它們影響了從底層驅動到上層應用的整個軟體堆棧,開發團隊需要在整個開發過程中持續關注這些因素。

## 5. 軟體需求

### 5.1 操作模式

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-001 |
| 類別 | 系統操作 |
| 描述 | CAN通信系統應支持以下操作模式:<br>1. 初始化模式<br>2. 正常模式<br>3. 睡眠模式<br>4. 靜默模式 |
| 來源ID | SYSRA-xxx |

# AUTOSAR CAN 需求分析文件

## 5. 軟體需求

### 5.1 軟體功能需求

#### 5.1.1 CAN通信功能

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-001 |
| 類別 | 功能 |
| 描述 | 系統應能夠發送和接收CAN消息，支持以下功能：<br>1. 支持標準格式(11位ID)和擴展格式(29位ID)的CAN幀<br>2. 支持CAN FD (Flexible Data-rate)通信<br>3. 實現CAN消息的優先級管理和調度 |
| 來源ID | SYSRA-xxx |

#### 5.1.2 CAN總線配置

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-002 |
| 類別 | 功能 |
| 描述 | 系統應提供以下CAN總線配置功能：<br>1. 配置CAN總線的位時序和採樣點<br>2. 支持靈活的波特率設置，包括仲裁階段和數據階段<br>3. 實現CAN控制器的濾波器配置，以減少CPU負載 |
| 來源ID | SYSRA-xxx |

#### 5.1.3 錯誤處理和診斷

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-003 |
| 類別 | 功能 |
| 描述 | 系統應實現以下錯誤處理和診斷功能：<br>1. 檢測和處理CAN通信錯誤，包括位錯誤、填充錯誤、CRC錯誤等<br>2. 實現TJA1153提供的診斷功能，如過熱保護、短路檢測<br>3. 提供CAN總線狀態監控和錯誤統計功能<br>4. 實現錯誤恢復機制，包括自動重試和錯誤報告 |
| 來源ID | SYSRA-xxx |

#### 5.1.4 電源管理

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-004 |
| 類別 | 功能 |
| 描述 | 系統應實現以下電源管理功能：<br>1. 支持TJA1153的低功耗模式管理<br>2. 實現S32K344 MCU的低功耗模式控制<br>3. 根據系統狀態自動切換CAN節點的工作模式<br>4. 提供喚醒機制，響應CAN總線喚醒信號 |
| 來源ID | SYSRA-xxx |

### 5.2 介面需求

#### 5.2.1 硬體抽象層(HAL)介面

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-005 |
| 類別 | 介面 |
| 描述 | 系統應提供以下HAL層介面：<br>1. CAN控制器初始化和配置介面<br>2. CAN消息發送和接收介面<br>3. CAN中斷處理介面<br>4. TJA1153控制介面（如模式切換、狀態讀取）<br>5. 提供標準化的錯誤碼和狀態報告機制 |
| 來源ID | SYSRA-xxx |

#### 5.2.2 應用程序介面(API)

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-006 |
| 類別 | 介面 |
| 描述 | 系統應提供以下應用層API：<br>1. CAN消息發送和接收函數<br>2. CAN總線狀態查詢函數<br>3. 錯誤處理和診斷信息獲取函數<br>4. 電源管理控制函數<br>5. 符合AUTOSAR標準的COM栈介面（如適用） |
| 來源ID | SYSRA-xxx |

### 5.3 硬體需求

#### 5.3.1 微控制器(MCU)要求

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-007 |
| 類別 | 硬體 |
| 描述 | 系統使用NXP S32K344微控制器，需滿足以下要求：<br>1. 利用S32K344的4個增強型CAN FD控制器<br>2. 使用適當的GPIO接口控制TJA1153<br>3. 配置CAN相關的中斷<br>4. 利用DMA控制器優化CAN數據傳輸<br>5. 正確配置時鐘以滿足CAN通信需求<br>6. 使用硬體安全模塊(HSM)增強系統安全性 |
| 來源ID | SYSRA-xxx |

#### 5.3.2 CAN收發器要求

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-008 |
| 類別 | 硬體 |
| 描述 | 系統使用NXP TJA1153 CAN收發器，需滿足以下要求：<br>1. 支持CAN FD通信，最高速率5 Mbit/s<br>2. 利用TJA1153的低功耗模式<br>3. 使用TJA1153的診斷功能<br>4. 確保TJA1153的EMC特性滿足汽車電子要求<br>5. 按照數據手冊建議進行PCB設計和布線 |
| 來源ID | SYSRA-xxx |

### 5.4 性能需求

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-009 |
| 類別 | 性能 |
| 描述 | CAN通信系統應滿足以下性能要求：<br>1. 在CAN FD模式下支持最高5 Mbit/s的數據傳輸率<br>2. CAN消息處理延遲不超過100μs<br>3. 系統能夠處理每秒至少1000條CAN消息<br>4. 在低功耗模式下，功耗不超過10mW<br>5. 系統從睡眠模式恢復到正常工作狀態的時間不超過5ms |
| 來源ID | SYSRA-xxx |

### 5.5 安全需求

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-010 |
| 類別 | 安全 |
| 描述 | CAN通信系統應滿足以下安全要求：<br>1. 實現CAN通信的訊息認證機制<br>2. 利用S32K344的硬體安全模塊(HSM)進行關鍵數據的加密存儲<br>3. 實現防篡改機制，檢測非法修改的嘗試<br>4. 符合ISO 26262功能安全標準的ASIL B級別要求<br>5. 實現安全啟動（Secure Boot）機制 |
| 來源ID | SYSRA-xxx |

## 5.6 功能安全需求

| 项目 | 描述 |
|------|------|
| ID | SWRA-CAN-011 |
| 类别 | 功能安全 |
| 描述 | 系统应实现以下功能安全特性：<br>1. 符合ISO 26262功能安全标准的ASIL B级别要求<br>2. 实现CAN通信的冗余机制，确保关键信息的可靠传输<br>3. 实现看门狗机制，监控系统运行状态并在异常时进行复位<br>4. 实现CAN总线Off现象的检测和自动恢复机制<br>5. 实现CAN控制器和TJA1153收发器的定期自检功能<br>6. 提供故障注入测试接口，用于验证系统的故障响应能力 |
| 来源ID | SYSRA-xxx |

| 项目 | 描述 |
|------|------|
| ID | SWRA-CAN-012 |
| 类别 | 功能安全 |
| 描述 | 系统应实现以下安全监控和报告机制：<br>1. 实时监控CAN总线负载，并在超过预设阈值时触发警告<br>2. 记录并报告所有CAN通信相关的错误事件，包括错误类型、发生时间和频率<br>3. 实现CAN消息的完整性检查，检测并报告任何数据损坏<br>4. 提供可配置的安全等级，允许在不同的操作模式下启用或禁用特定的安全特性<br>5. 实现安全日志机制，记录所有安全相关事件，并支持离线分析 |
| 来源ID | SYSRA-xxx |

## 5.7 非功能需求

### 5.7.1 可维护性需求

| 项目 | 描述 |
|------|------|
| ID | SWRA-CAN-013 |
| 类别 | 非功能 - 可维护性 |
| 描述 | 系统应满足以下可维护性要求：<br>1. 采用模块化设计，确保CAN驱动程序、协议栈和应用层可独立更新<br>2. 提供清晰的文档，包括详细的API说明和使用示例<br>3. 实现日志记录机制，支持不同级别的日志输出，便于问题诊断<br>4. 提供配置工具，允许在不重新编译代码的情况下修改CAN参数<br>5. 代码应遵循MISRA C:2012编码标准，提高代码的可读性和可维护性 |
| 来源ID | SYSRA-xxx |

### 5.7.2 可测试性需求

| 项目 | 描述 |
|------|------|
| ID | SWRA-CAN-014 |
| 类别 | 非功能 - 可测试性 |
| 描述 | 系统应满足以下可测试性要求：<br>1. 提供单元测试框架，覆盖所有关键功能模块<br>2. 实现软件仿真模式，允许在无硬件的环境下进行功能测试<br>3. 提供CAN总线监控接口，支持外部测试设备的连接<br>4. 实现可配置的测试模式，支持各种边界条件和异常情况的模拟<br>5. 提供自动化测试脚本，支持回归测试和性能测试 |
| 来源ID | SYSRA-xxx |

### 5.7.3 可移植性需求

| 项目 | 描述 |
|------|------|
| ID | SWRA-CAN-015 |
| 类别 | 非功能 - 可移植性 |
| 描述 | 系统应满足以下可移植性要求：<br>1. 使用AUTOSAR标准的RTE (Runtime Environment)，提高软件的可移植性<br>2. 将硬件相关代码严格限制在MCAL层，便于适配不同的MCU平台<br>3. 提供明确的硬件抽象层(HAL)接口，简化不同CAN控制器的适配过程<br>4. 使用条件编译和配置文件管理平台相关的差异，提高代码的可移植性<br>5. 文档中应明确指出任何与特定硬件平台相关的限制或依赖 |
| 来源ID | SYSRA-xxx |

### 5.7.4 性能和资源需求

| 项目 | 描述 |
|------|------|
| ID | SWRA-CAN-016 |
| 类别 | 非功能 - 性能和资源 |
| 描述 | 系统应满足以下性能和资源需求：<br>1. CAN驱动程序的CPU使用率在正常工作条件下不应超过5%<br>2. 系统的静态内存使用不应超过可用RAM的20%<br>3. CAN消息处理的平均延迟应小于100微秒<br>4. 系统应能同时处理至少16个活跃的CAN标识符<br>5. 在低功耗模式下，系统的功耗应小于5mW<br>6. 系统从睡眠模式到完全运行状态的转换时间应小于10ms |
| 来源ID | SYSRA-xxx |

## 5.8 製造需求

### 5.8.1 生產測試需求

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-017 |
| 類別 | 製造 - 生產測試 |
| 描述 | 系統應滿足以下生產測試需求：<br>1. 提供生產測試模式，允許快速驗證CAN通信功能<br>2. 實現自動化測試程序，覆蓋所有關鍵硬件接口和軟件功能<br>3. 支持批量測試，能夠同時測試多個單元<br>4. 提供明確的通過/失敗標準，便於生產線上的快速判斷<br>5. 測試過程中應記錄詳細的測試日誌，支持後續分析和追溯 |
| 來源ID | SYSRA-xxx |

### 5.8.2 校準和配置需求

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-018 |
| 類別 | 製造 - 校準和配置 |
| 描述 | 系統應滿足以下校準和配置需求：<br>1. 提供製造階段的參數配置接口，允許根據具體車型調整CAN參數<br>2. 支持批量配置工具，提高生產效率<br>3. 實現配置數據的加密存儲，防止未經授權的修改<br>4. 提供配置驗證機制，確保所有參數在有效範圍內<br>5. 支持配置數據的備份和恢復功能 |
| 來源ID | SYSRA-xxx |

### 5.8.3 可追溯性需求

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-019 |
| 類別 | 製造 - 可追溯性 |
| 描述 | 系統應滿足以下可追溯性需求：<br>1. 每個生產的單元應有唯一的序列號，可通過軟件讀取<br>2. 記錄生產日期、軟件版本、硬件版本等關鍵信息<br>3. 提供機制記錄重要的製造過程數據，如測試結果、校準參數等<br>4. 支持通過CAN總線讀取單元的製造信息<br>5. 實現安全的數據存儲機制，防止製造信息被篡改 |
| 來源ID | SYSRA-xxx |

## 5.9 法規和標準需求

### 5.9.1 汽車行業標準

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-020 |
| 類別 | 法規和標準 |
| 描述 | 系統應符合以下汽車行業標準：<br>1. ISO 11898-1:2015 - 道路車輛 — 控制器局域網絡（CAN）<br>2. ISO 26262:2018 - 道路車輛 — 功能安全<br>3. AUTOSAR（AUTomotive Open System ARchitecture）標準，版本R20-11<br>4. SAE J1939 - 商用車輛通信協議（如適用）<br>5. ISO 16750 - 道路車輛 — 電氣及電子設備的環境條件和試驗 |
| 來源ID | SYSRA-xxx |

### 5.9.2 電磁兼容性（EMC）要求

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-021 |
| 類別 | 法規和標準 - EMC |
| 描述 | 系統應滿足以下EMC要求：<br>1. 符合CISPR 25 - 車輛、船舶和內燃機 - 無線電干擾特性<br>2. 滿足ISO 11452 系列標準 - 道路車輛 — 電氣干擾的測試方法<br>3. 符合IEC 62132 - 集成電路 - 電磁干擾測量<br>4. 通過EN 55024 - 信息技術設備 - 抗擾度特性<br>5. 滿足車廠特定的EMC要求（需具體指明） |
| 來源ID | SYSRA-xxx |

### 5.9.3 環境和可靠性要求

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-022 |
| 類別 | 法規和標準 - 環境和可靠性 |
| 描述 | 系統應滿足以下環境和可靠性要求：<br>1. 符合AEC-Q100 - 集成電路的壓力測試規範<br>2. 滿足ISO 16750-4 - 道路車輛 - 電氣及電子設備的環境條件和試驗 - 第4部分：氣候負荷<br>3. 通過IPC-A-610 Class 3 - 電子組件可接受性標準<br>4. 符合 ZVEI Robustness Validation 標準<br>5. 滿足車廠特定的耐久性和可靠性要求（需具體指明） |
| 來源ID | SYSRA-xxx |

### 5.9.4 網絡安全要求

| 項目 | 描述 |
|------|------|
| ID | SWRA-CAN-023 |
| 類別 | 法規和標準 - 網絡安全 |
| 描述 | 系統應滿足以下網絡安全要求：<br>1. 符合ISO/SAE 21434 - 道路車輛 — 網絡安全工程<br>2. 實現 UNECE WP.29 網絡安全管理系統（CSMS）的相關要求<br>3. 滿足 ENISA Good Practices for Security of Smart Cars 的建議<br>4. 符合 AutoISAC（Automotive Information Sharing and Analysis Center）的最佳實踐指南<br>5. 遵循 NHTSA（美國國家公路交通安全管理局）的網絡安全指南 |
| 來源ID | SYSRA-xxx |

## 6. 參考文件

| 編號 | 文件 | 版本 | 位置 |
|------|------|------|------|
| 1 | AUTOSAR Specification of CAN Driver | 4.4.0 | AUTOSAR官方網站 |
| 2 | ISO 11898-1:2015 Road vehicles -- Controller area network (CAN) | 2015 | ISO官方網站 |

## 7. 工具

| 工具 | 版本 | 參考指南 | 許可證詳情 |
|------|------|----------|------------|
| AUTOSAR Builder | 4.4.0 | AUTOSAR Builder User Guide | 商業許可 |
| CANoe | 12.0 | CANoe User Manual | 商業許可 |

## 8. 附錄

（根據需要添加其他相關信息）