feifei.xu/autosar_standard_spec_v4.4
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
784f11ab73dc710f0245ffa15e5176652632d9ca
autosar_standard_spec_v4.4/Communication/AUTOSAR_SRS_CAN.md
T

2148 lines
115 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# CAN 需求规范
## 元信息
| 项目 | 内容 |
|------|------|
| 文档标题 | CAN 需求规范 |
| 文档所有者 | AUTOSAR |
| 文档责任方 | AUTOSAR |
| 文档标识号 | 001 |
| 文档状态 | Final（最终） |
| 所属 AUTOSAR 标准 | Classic Platform（经典平台） |
| 所属标准发布版本 | 4.4.0 |
| 对应原文 PDF | `AUTOSAR_SRS_CAN.pdf` |
| 翻译状态 | 已完成 |
| 翻译日期 | 2026-06-12 |
## 文档标识
| 字段 | 值 |
|------|----|
| Document Title（文档标题） | Requirements on CAN |
| Document Owner（文档所有者） | AUTOSAR |
| Document Responsibility（文档责任方） | AUTOSAR |
| Document Identification No（文档标识号） | 001 |
| Document Status（文档状态） | Final |
| Part of AUTOSAR Standard（所属 AUTOSAR 标准） | Classic Platform |
| Part of Standard Release（所属标准发布版本） | 4.4.0 |
## 文档变更历史
| 日期 | 发布版本 | 变更人 | 变更说明 |
|------|----------|--------|----------|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | - 为 BusMirroring 添加需求<br>- 从 CanTp 中移除半双工模式 |
| 2016-12-08 | 4.3.1 | AUTOSAR Release Management | - 编辑性修改 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | - 添加获取 CAN 错误 active/passive 状态的方法 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | - 添加 CAN FD 支持的需求<br>- 移除发送取消的需求 |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | - 根据 padding 配置修订 DLC 检查 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | - 修正需求：\"BusOff 之后第一条总线消息不发送 WUF\"<br>- 编辑性修改 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | - 支持 29bit 混合寻址<br>- 总线唤醒回调应同步或异步，取决于硬件<br>- 高级发送缓冲区处理 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | - 添加部分网络化的高层需求<br>- 添加发送缓冲区处理改进<br>- 添加全双工支持 |
| 2011-04-15 | 4.0.2 | AUTOSAR Administration | - 移除 CAN 轮询/中断模式的 BSW01017 需求 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | - 为 CAN 传输层添加额外需求<br>- 添加远程帧支持需求<br>- 修订法律免责声明 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | - 修订法律免责声明 |
| 2007-07-24 | 2.1.16 | AUTOSAR Administration | - 修订\"用户建议\"<br>- 添加\"修订信息\" |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | - PDF 文件修正 |
| 2006-11-28 | 2.1 | AUTOSAR Administration | - 架构设计变更：CAN 收发器驱动现在分层在 CAN 接口之下<br>- CAN 接口中扩展 11/29 位标识符支持<br>- 在 SRS_Can_01069 和 SRS_Can_01074 中添加 N_SA<br>- 修订法律免责声明 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | - CAN 驱动、CAN 接口：优化传输时序行为（多路传输、基于优先级的传输、传输取消）<br>- 在一个网络上支持标准和扩展 CAN 标识符<br>- CAN 传输层：多连接机制、支持 ISO-15765-4、支持连接特定的超时值、并行支持不同的寻址模式<br>- CAN 收发器驱动：添加 CAN 收发器驱动的需求 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | - 初始发布 |
## 目录
1. [Scope of document（文档范围）](#1-scope-of-document)
2. [How to read this document（如何阅读本文档）](#2-how-to-read-this-document)
- 2.1 [Conventions used（使用的约定）](#21-conventions-used)
- 2.2 [Requirements structure（需求结构）](#22-requirements-structure)
3. [Acronyms and abbrevations（缩略语和缩写）](#3-acronyms-and-abbrevations)
4. [Functional Overview（功能概述）](#4-functional-overview)
5. [Requirements Tracing（需求追踪）](#5-requirements-tracing)
6. [Requirements Specification（需求规范）](#6-requirements-specification)
- 6.1 [Remarks to the CAN Bus Transceiver Driver（CAN 总线收发器驱动备注）](#61-remarks-to-the-can-bus-transceiver-driver)
- 6.2 [Functional Requirements（功能需求）](#62-functional-requirements)
- 6.2.1 [CAN Driver（CAN 驱动）](#621-can-driver)
- 6.2.2 [CAN Interface (Hardware Abstraction)（CAN 接口（硬件抽象））](#622-can-interface-hardware-abstraction)
- 6.2.3 [CAN State Manager（CAN 状态管理器）](#623-can-state-manager)
- 6.2.4 [Transport Layer CAN（CAN 传输层）](#624-transport-layer-can)
- 6.2.5 [CAN Bus Transceiver Driver（CAN 总线收发器驱动）](#625-can-bus-transceiver-driver)
- 6.3 [Non functional requirements（非功能需求）](#63-non-functional-requirements)
7. [References（参考资料）](#7-references)
## 1 Scope of document
本文档规定了以下基础软件模块的需求（模块名称在括号中）：
- CAN Driver (Can) — CAN 驱动
- CAN Interface (CanIf) — CAN 接口
- CAN State Manager (CanSM) — CAN 状态管理器
- CAN Transport Layer (CanTp) — CAN 传输层
- CAN Bus Transceiver Driver (CanTrcv) — CAN 总线收发器驱动
## 2 How to read this document
每个需求都有其唯一的标识符，以前缀"BSW"开头（"Basic Software"，即基础软件）。对于任何评审注释、备注或问题，请参考此唯一 ID 而不是章节或页码！
### 2.1 Conventions used
- AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中指定的表格。
- 在需求中，使用以下特定语义：
本文档中关键字 "MUST"（必须）、"MUST NOT"（不得）、"REQUIRED"（必需）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（建议）、"SHOULD NOT"（不建议）、"RECOMMENDED"（推荐）、"MAY"（可以）和 "OPTIONAL"（可选）应按照 RFC 2119 进行解释。请注意，使用这些词的文档的需求级别会修改这些词的强制力。
- **MUST**：此词，或术语 "REQUIRED" 或 "SHALL"，表示该定义是规范的绝对要求。
- **MUST NOT**：此短语，或短语 "SHALL NOT"，表示该定义是规范的绝对禁止。
- **SHOULD**：此词，或形容词 "RECOMMENDED"，表示在特定情况下可能存在忽略某项的有效理由，但在选择不同方案之前必须充分理解并仔细权衡其影响。
- **SHOULD NOT**：此短语，或短语 "NOT RECOMMENDED"，表示在特定情况下某特定行为可能是可接受甚至有用的，但在实现任何以此标签描述的行为之前，应充分理解其影响并仔细权衡该情况。
- **MAY**：此词，或形容词 "OPTIONAL"，表示某项是真正可选的。一个供应商可能选择包含该项，因为特定市场需要它，或者因为供应商认为它能增强产品；而另一个供应商可能省略相同的项。不包含特定选项的实现必须准备好与包含该选项的另一个实现进行互操作，尽管功能可能有所降低。同样，包含特定选项的实现必须准备好与不包含该选项的另一个实现进行互操作（当然，该选项提供的功能除外）。
### 2.2 Requirements structure
每个模块特定章节包含基础软件模块的简要功能描述。同一类型的需求在每个章节中按以下标题分组（如果适用）：
**功能需求：**
- Configuration（配置）— 模块中需要可配置的哪些元素
- Initialization（初始化）
- Normal Operation（正常运行）
- Shutdown Operation（关闭操作）
- Fault Operation（故障操作）
**非功能需求：**
- Timing Requirements（时序需求）
- Resource Usage（资源使用）
- Usability（可用性）
- Output for other WPs（例如描述模板、工具）
## 3 Acronyms and abbrevations
| 缩略语 | 描述 |
|--------|------|
| CAN Communication Matrix（CAN 通信矩阵） | 描述完整的 CAN 网络：<br>• 参与的节点<br>• 所有 CAN PDU 的定义（标识符、DLC）<br>• PDU 的源和宿<br>格式在其他 AUTOSAR 工作包中定义 |
| Physical Channel（物理通道） | 物理通道表示到 CAN 网络的接口。CAN 硬件单元的不同物理通道可以访问不同的网络 |
| L-PDU | CAN（数据链路层）协议数据单元。由标识符、DLC 和数据（L-SDU）组成 |
| L-SDU | CAN（数据链路层）服务数据单元。在 L-PDU 内传输的数据 |
| Hardware Object（硬件对象） | 硬件对象定义为 CAN 硬件单元的 CAN RAM 内部的消息缓冲区。也常称为消息对象 |
| Hardware Object Handle（硬件对象句柄） | 硬件对象句柄（HOH）由 CAN 驱动定义并提供。通常每个 HOH 表示一个硬件对象。HOH 由 CAN 接口层用作对 CAN 驱动进行发送和读取请求的参数 |
| L-PDU Handle（L-PDU 句柄） | L-PDU 句柄在 CAN 接口层内部定义并放置。通常每个句柄表示一个 L-PDU 或一个 L-PDU 范围，是包含用于 Tx/Rx 处理信息的常量结构 |
| CAN Controller（CAN 控制器） | CAN 控制器精确地服务一个物理通道。参见 CAN 接口 SWS 中的"典型 CAN 硬件单元"图 |
| CAN Hardware Unit（CAN 硬件单元） | CAN 硬件单元可以由一个或多个相同类型的 CAN 控制器以及一个或多个 CAN RAM 区域组成。CAN 硬件单元可以是片上设备或外部设备。CAN 硬件单元由一个 CAN 驱动表示 |
| Multiplexed Transmission（多路传输） | 使用三个 TX HW 对象，它们对上层表示为一个发送实体（硬件对象句柄）。用于避免外部优先级反转 |
| Inner Priority Inversion（内部优先级反转） | 同一物理通道中存在挂起的低优先级 L-PDU 时，会阻止高优先级 L-PDU 的传输 |
| Outer Priority Inversion（外部优先级反转） | 发生在两个连续的 TX L-PDU 传输之间存在时间间隔。在这种情况下，来自另一节点的较低优先级 L-PDU 可能会阻止发送下一个 L-PDU，因为较高优先级的 L-PDU 到达太晚而无法参与正在进行的总线仲裁 |
| Bus（总线） | 总线表示 CAN 或 LIN 网络。总线具有给定的物理行为（例如 CAN 低速或高速）。总线可以支持通过总线唤醒或"始终开启" |
| N-PDU | CAN 传输层的网络协议数据单元 |
| N-SDU | CAN 传输层的服务数据单元。在 N-PDU 内传输的数据 |
| static configuration（静态配置） | 在运行时不可更改的配置。这意味着配置通常在 ECU 的启动阶段完成一次。此关注点与将配置参数引入 ECU 本身的可能性无关：预编译时、链接时或后构建时 |
| STmin | Separation Time min（最小间隔时间） |
| BS | Block Size（块大小） |
| HTH | CAN hardware transmit handle（CAN 硬件发送句柄） |
## 4 Functional Overview
CAN 总线收发器驱动负责根据总线特定 NM 的预期状态和整个 ECU 的当前状态，处理 ECU 上的 CAN 收发器。
收发器是一种硬件设备，主要将 µC 端口的逻辑开/关信号值转换为符合总线的电平、电流和时序。在汽车环境中主要使用三种不同的 CAN 物理层。这些物理层是高速 CAN（高达 1Mbd）的 ISO11898 和低速 CAN（高达 125kBd）的 ISO11519。两者都在 AUTOSAR 中考虑，而单线 CAN 的 SAE J2411 不在考虑范围内。CAN FD 使用与高速 CAN 相同的 CAN 物理层，但提供更快的传输速率。
此外，收发器通常能够检测电气故障，例如布线问题、地偏移或过长显性信号的传输。根据接口的不同，它们可以通过单个端口引脚汇总或通过 SPI 详细地标记检测到的错误。
某些收发器还支持电源控制和通过总线唤醒。市场上有很多不同的唤醒/睡眠和电源概念，专注于为给定任务提供最佳成本优化解决方案。最新发展是所谓的系统基础芯片（SBC），其中不仅 CAN 和/或 LIN 收发器，还有电源控制和高级看门狗都集成在一个封装内，并通过一个接口（通常是 SPI）控制。
典型的 CAN 收发器是用于低速 CAN 总线的 TJA1054。相同的状态转换模型也用于 TJA1041（支持通过 CAN 唤醒的高速 CAN），并且可以转移到市场上的许多其他产品。
**Transceiver Wakeup Reason（收发器唤醒原因）**
收发器驱动能够存储对谁请求了唤醒的本地视图：总线或软件。
- **Bus（总线）**：总线导致了唤醒。
- **Internally（内部）**：唤醒是由对驱动的软件请求引起的。
- **Sleep（睡眠）**：收发器处于运行模式睡眠，且未发生唤醒。
## 5 Requirements Tracing
下表列出了本文档中的需求以及它们所满足的 AUTOSAR RS（需求规范）需求。
| 需求 | 描述 | 由以下需求满足 |
|------|------|----------------|
| RS_BRF_01000 | AUTOSAR 架构应将 BSW 组织为硬件独立层和硬件相关层 | SRS_Can_01001, SRS_Can_01121 |
| RS_BRF_01008 | AUTOSAR 应将硬件相关层组织为微控制器独立层和微控制器相关层 | SRS_Can_01121 |
| RS_BRF_01016 | AUTOSAR 应在软件层内提供模块化设计 | SRS_Can_01121 |
| RS_BRF_01056 | AUTOSAR BSW 模块应提供标准化接口 | SRS_Can_01142 |
| RS_BRF_01064 | AUTOSAR BSW 应提供回调函数以访问上层模块 | SRS_Can_01014, SRS_Can_01045, SRS_Can_01106, SRS_Can_01138 |
| RS_BRF_01088 | AUTOSAR 应提供允许表达高层应用通信需求的接口 | SRS_Can_01154 |
| RS_BRF_01096 | AUTOSAR 应支持 ECU 的启动和关闭 | SRS_Can_01108 |
| RS_BRF_01104 | AUTOSAR 应支持 ECU 和总线的睡眠和唤醒 | SRS_Can_01151, SRS_Can_01156 |
| RS_BRF_01136 | AUTOSAR 应支持在系统启动后解析的已配置 BSW 数据的变体 | SRS_Can_01021, SRS_Can_01022, SRS_Can_01023, SRS_Can_01041, SRS_Can_01090, SRS_Can_01139, SRS_Can_01155 |
| RS_BRF_01152 | AUTOSAR 应支持有限的动态重新配置 | SRS_Can_01042 |
| RS_BRF_01184 | AUTOSAR 应支持不同的降级方法 | SRS_Can_01154 |
| RS_BRF_01408 | AUTOSAR 应提供可从每个基础软件层访问的服务层 | SRS_Can_01055 |
| RS_BRF_01544 | AUTOSAR 通信应定义通信数据的发送和接收 | SRS_Can_01003, SRS_Can_01007, SRS_Can_01008, SRS_Can_01009, SRS_Can_01011, SRS_Can_01045, SRS_Can_01049, SRS_Can_01051, SRS_Can_01109, SRS_Can_01129, SRS_Can_01131 |
| RS_BRF_01552 | AUTOSAR 通信应将独立于总线的功能与依赖于总线的功能分离 | SRS_Can_01001, SRS_Can_01034 |
| RS_BRF_01600 | AUTOSAR 通信应支持超时处理 | SRS_Can_01081, SRS_Can_01082, SRS_Can_01143, SRS_Can_01144, SRS_Can_01146 |
| RS_BRF_01608 | AUTOSAR 通信应支持信号过滤 | SRS_Can_01004 |
| RS_BRF_01632 | AUTOSAR 通信应支持信号组的数据一致性 | SRS_Can_01059, SRS_Can_01114 |
| RS_BRF_01664 | AUTOSAR 通信应支持总线的状态管理 | SRS_Can_01027, SRS_Can_01028, SRS_Can_01029, SRS_Can_01032, SRS_Can_01054, SRS_Can_01055, SRS_Can_01060, SRS_Can_01107, SRS_Can_01115, SRS_Can_01122, SRS_Can_01136, SRS_Can_01143, SRS_Can_01144, SRS_Can_01146, SRS_Can_01156, SRS_Can_01157 |
| RS_BRF_01680 | AUTOSAR 通信应支持保持总线唤醒和被总线保持唤醒的机制 | SRS_Can_01006, SRS_Can_01013, SRS_Can_01032, SRS_Can_01106, SRS_Can_01107, SRS_Can_01115, SRS_Can_01136, SRS_Can_01138, SRS_Can_01151, SRS_Can_01153, SRS_Can_01156, SRS_Can_01157 |
| RS_BRF_01704 | AUTOSAR 通信应支持 CAN 通信总线 | SRS_Can_01002, SRS_Can_01003, SRS_Can_01004, SRS_Can_01005, SRS_Can_01006, SRS_Can_01007, SRS_Can_01008, SRS_Can_01009, SRS_Can_01011, SRS_Can_01013, SRS_Can_01015, SRS_Can_01016, SRS_Can_01018, SRS_Can_01020, SRS_Can_01021, SRS_Can_01022, SRS_Can_01023, SRS_Can_01027, SRS_Can_01028, SRS_Can_01029, SRS_Can_01032, SRS_Can_01033, SRS_Can_01034, SRS_Can_01035, SRS_Can_01036, SRS_Can_01037, SRS_Can_01038, SRS_Can_01039, SRS_Can_01041, SRS_Can_01042, SRS_Can_01043, SRS_Can_01045, SRS_Can_01049, SRS_Can_01051, SRS_Can_01053, SRS_Can_01054, SRS_Can_01055, SRS_Can_01058, SRS_Can_01059, SRS_Can_01060, SRS_Can_01061, SRS_Can_01062, SRS_Can_01066, SRS_Can_01068, SRS_Can_01069, SRS_Can_01071, SRS_Can_01073, SRS_Can_01074, SRS_Can_01075, SRS_Can_01076, SRS_Can_01078, SRS_Can_01079, SRS_Can_01081, SRS_Can_01082, SRS_Can_01090, SRS_Can_01091, SRS_Can_01092, SRS_Can_01095, SRS_Can_01096, SRS_Can_01097, SRS_Can_01098, SRS_Can_01099, SRS_Can_01100, SRS_Can_01101, SRS_Can_01103, SRS_Can_01106, SRS_Can_01107, SRS_Can_01108, SRS_Can_01109, SRS_Can_01110, SRS_Can_01114, SRS_Can_01115, SRS_Can_01122, SRS_Can_01125, SRS_Can_01126, SRS_Can_01129, SRS_Can_01130, SRS_Can_01131, SRS_Can_01132, SRS_Can_01134, SRS_Can_01135, SRS_Can_01136, SRS_Can_01138, SRS_Can_01139, SRS_Can_01140, SRS_Can_01141, SRS_Can_01143, SRS_Can_01144, SRS_Can_01145, SRS_Can_01146, SRS_Can_01147, SRS_Can_01149, SRS_Can_01151, SRS_Can_01153, SRS_Can_01154, SRS_Can_01155, SRS_Can_01156, SRS_Can_01157, SRS_Can_01158, SRS_Can_01159 |
| RS_BRF_01712 | AUTOSAR 通信应支持 CAN FD 提供的高速适应性 | SRS_Can_01073, SRS_Can_01160, SRS_Can_01161, SRS_Can_01162, SRS_Can_01163 |
| RS_BRF_01720 | AUTOSAR 通信应支持 CAN 上的标准化诊断传输协议 | SRS_Can_01065, SRS_Can_01066, SRS_Can_01068, SRS_Can_01069, SRS_Can_01071, SRS_Can_01073, SRS_Can_01074, SRS_Can_01075, SRS_Can_01076, SRS_Can_01078, SRS_Can_01079, SRS_Can_01081, SRS_Can_01082, SRS_Can_01086, SRS_Can_01111, SRS_Can_01112, SRS_Can_01116, SRS_Can_01148, SRS_Can_01149 |
| RS_BRF_01728 | AUTOSAR 通信应支持 J1939 传输协议 | SRS_Can_01159 |
| RS_BRF_01736 | AUTOSAR 通信应支持按 J1939 网络管理要求动态分配地址 | SRS_Can_01159 |
| RS_BRF_02168 | AUTOSAR 诊断应提供异常运行条件的集中分类和处理 | SRS_Can_01082 |
## 6 Requirements Specification
### 6.1 Remarks to the CAN Bus Transceiver Driver
CAN 总线收发器在行为和支持的功能方面差异很大。范围从非常简单的"始终开启"的 CAN 收发器开始，包括支持高级跛行回家处理和错误检测的收发器，并以所谓的系统基础芯片（SBC）结束，其中内部包含多个 CAN 总线收发器、看门狗、电压调节器等等。
收发器数据手册的规模从几页到 80 多页不等，设备的额外应用说明几乎数不胜数。
本文档的目标是规定适用于市场上几乎所有用例的当前和未来 CAN 总线收发器的接口和行为。如果能实现至少使总线收发器功能的使用者（通常是 AUTOSAR NM 和 AUTOSAR 通信管理器）独立于总线并因此可重用，那就太好了。
在一个 AUTOSAR 实现中涵盖所有可能的总线收发器与所有可想象的电源概念的组合是不可能的。
#### 6.1.1 Explicitly uncovered CAN Bus Transceiver functionality
某些 CAN 总线收发器提供附加功能以改善例如 ECU 自检或增强诊断错误检测能力。
ECU 自检和增强错误检测未在 AUTOSAR 中定义，并且通常需要这样的功能会将当前使用（且便宜）的收发器设备排除在外。因此，本文需求不支持"地偏移检测"、"选择性唤醒"、"斜率控制"等功能。由于可移植性和可重用性，AUTOSAR 中不接受通用和"开放"的 API，如 IOControl()。
#### 6.1.2 System Basis Chip and CAN Bus Transceiver Driver
系统基础芯片（SBC）除了 CAN 总线收发器外，还包含与电源控制和安全相关的附加硬件（例如多个电压调节器和看门狗）以及更多功能（例如持久性存储器）。
在 AUTOSAR 概念中，每个已识别的硬件设备都由一个单独的 manager/driver/handler（在 AUTOSAR 中称为：Interface）负责。因此，除了总线收发器驱动外，额外的 manager/driver/handler 覆盖了 SBC 内部的功能（例如 Watchdog Manager、非易失性存储器管理器、电源控制驱动等）。由于共享的通信访问以及该通信中（与安全相关的）限制，将无法独立处理每个 SBC 子功能。
这将导致以下情况：要么 SBC 不能在 AUTOSAR 兼容的 ECU 中使用，要么（更好的解决方案）必须使用具有每个单一域的所有 API 的 SBC 功能的专用 manager/driver/handler。
### 6.2 Functional Requirements
#### 6.2.1 CAN Driver
CAN 驱动为该层的上层用户（CAN 接口）提供统一的接口。CAN 驱动尽可能合理地隐藏相关 CAN 控制器的硬件特定属性。
有关详细的功能描述和接口定义，请参见 CAN 驱动规范 [Can]。
##### 6.2.1.1 Configuration（配置）
###### 6.2.1.1.1 [SRS_Can_01036] CAN 驱动应支持标准标识符和扩展标识符
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | valid |
| Description（描述） | 如果 CAN 硬件支持，CAN 驱动应能在一个 CAN 控制器上同时使用标准和扩展 CAN 标识符进行操作。如果 CAN 硬件支持，每个硬件对象应可静态且单独配置为两种标识符类型之一。通过该 CAN 控制器发送和接收的所有 L-PDU 应符合此配置。CAN 驱动应支持接收和发送具有标准和扩展 ID 的 L-PDU，包括在同一硬件对象上同时存在两种类型。配置参数应允许为预编译时、链接时或后构建时类型。 |
| Rationale（原理） | CAN 标准覆盖范围 |
| Use Case（用例） | CAN 标准允许标准和扩展标识符。不同的项目可能需要使用扩展 CAN ID 以及标准 CAN ID，因为剩余的标准 CAN ID 不足。 |
| Dependencies（依赖） | [SRS_Can_01016] |
| Supporting Material（支持材料） | -- |
⌋(RS_BRF_01704)
###### 6.2.1.1.2 [SRS_Can_01037] CAN 驱动应允许静态配置硬件接收过滤器
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | valid |
| Description（描述） | 硬件支持的接收 L-PDU 过滤应可配置。配置应在初始化阶段完成。在正常运行期间的重新配置仅应在 STOPPED 模式下可能。配置参数应允许为预编译、链接时或后构建类型。 |
| Rationale（原理） | 硬件能力覆盖 |
| Use Case（用例） | CAN 控制器允许在硬件内部过滤消息。这减少了与 ECU 无关的消息所导致的软件负载。 |
| Dependencies（依赖） | [SRS_Can_01018] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.1.1.3 [SRS_Can_01038] 每个 CAN 控制器的位时序应可配置
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | valid |
| Description（描述） | 由 CAN 驱动服务的每个 CAN 控制器的位时序以及波特率应可配置。以下列表描述了典型属性：<br>• 传播延迟（Propagation delay）<br>• Tseg1<br>• Tseg2<br>• 每位采样数（Samples/bit）<br>• SJW（同步跳转宽度）<br>配置参数应允许为预编译时、链接时或后构建时类型。 |
| Rationale（原理） | CAN 标准覆盖范围，硬件能力覆盖 |
| Use Case（用例） | CAN 标准不指定一个波特率 -> 波特率是项目特定的。时序参数的可能配置取决于硬件。 |
| Dependencies（依赖） | [SRS_Can_01139] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.1.1.4 [SRS_Can_01039] 应在静态配置文件中为 CAN 接口提供硬件对象句柄
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 所有可用的硬件对象句柄应在 ECU 配置描述中定义。公共部分的语法应标准化，因为这是到 CAN 接口的配置接口。配置参数应允许为预编译时、链接时或后构建时类型。 |
| Rationale（原理） | 硬件能力覆盖，到 CAN 接口的配置接口 |
| Use Case（用例） | 为了软件和硬件过滤的最佳协作以及底层硬件的最佳使用，CAN 接口需要知道可用的硬件资源及其配置。 |
| Dependencies（依赖） | SRS_Can_01016 |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.1.1.5 [SRS_Can_01058] 应可配置是否使用多路传输
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | valid |
| Description（描述） | 多路传输功能应可预编译时配置。仅当底层 CAN 控制器支持多路传输时，才应支持此功能。 |
| Rationale（原理） | -- |
| Use Case（用例） | 可以避免外部优先级反转 |
| Dependencies（依赖） | [SRS_Can_01134] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.1.1.6 [SRS_Can_01062] 每个 CAN 控制器的每个事件应可配置为通过轮询或中断检测
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | valid |
| Description（描述） | 每个 CAN 控制器的每个可能事件应可预编译时配置为以下两种模式之一：<br>**轮询（Polling）：** CAN 驱动表示至少一个周期性调用的任务。它轮询 CAN 控制器。根据发生的事件调用相应的通知。CAN 驱动可选择支持多个轮询周期。该模式下，相应事件的 CAN 中断被禁用。<br>**中断驱动（Interrupt driven）：** CAN 控制器通过中断通知 CAN 驱动检测到的硬件事件。<br>CAN 硬件单元实现可能不同，因为某些事件只能通过中断报告或只能轮询 -> 轮询或中断的配置应在驱动内部完成。 |
| Rationale（原理） | 硬件能力覆盖 |
| Use Case（用例） | 当需要确定性时序行为（响应时间）时需要轮询模式。例如用于电机管理系统。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.1.1.7 [SRS_Can_01135] 应可配置一个或多个 TX 硬件对象
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | valid |
| Description（描述） | 应可配置一个或多个 TX 硬件对象，其中每个硬件对象由其自己的硬件对象句柄表示。（不要与多路传输混淆。）<br>TX 硬件对象的选择由发送请求服务的调用者通过一个标识硬件对象句柄的参数完成。<br>这要求硬件允许配置多个 TX 硬件对象。配置应允许为预编译、链接时或后构建类型。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 支持典型 CAN 控制器能力：配置多个 Full-CAN 发送对象和多个 Basic-CAN 发送对象，以及一个 Basic-CAN 发送对象和多个 Full-CAN 发送对象等。 |
| Dependencies（依赖） | [SRS_Can_01058], [SRS_Can_01049] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
##### 6.2.1.2 Initialization（初始化）
###### 6.2.1.2.1 [SRS_Can_01041] CAN 驱动应实现初始化接口
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动应实现一个用于初始化的接口。此服务应初始化所有模块全局变量和 CAN 硬件单元及其控制器的所有寄存器。此函数在启动期间只应被调用一次。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | CAN 硬件单元具有必须根据静态配置进行设置的寄存器。某些寄存器值属于单个 CAN 控制器，某些影响整个单元。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01136)
###### 6.2.1.2.2 [SRS_Can_01042] CAN 驱动应支持动态选择配置集
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动应支持从配置集列表中动态选择一个静态配置集。这应通过通过初始化接口传递的参数来完成。有关参数的详细视图，请参阅 CAN 驱动 SWS。仅当 CAN 驱动的状态机处于 STOPPED 模式时，才能切换到另一个配置集。<br>提示：适当配置集的选择本身以及将配置集集成到 ECU 中的方式（后构建、预编译）不受此需求影响。 |
| Rationale（原理） | 支持运行时的不同配置 |
| Use Case（用例） | 根据 ECU 的不同安装位置，使用具有不同 CAN ID 等的不同配置集。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704,RS_BRF_01152)
##### 6.2.1.3 Normal Operation（正常运行）
###### 6.2.1.3.1 [SRS_Can_01043] CAN 驱动应提供启用/禁用 CAN 控制器中断的服务
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动应提供用于启用和禁用由 CAN 控制器生成的所有中断的服务。<br>• 禁用意味着：禁用相关 CAN 控制器的所有中断<br>• 启用意味着：重新启用之前禁用的所有中断 |
| Rationale（原理） | 基本功能，确保数据一致性 |
| Use Case（用例） | 用于禁用 CAN 驱动事件的异步中断。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋(RS_BRF_01704)
###### 6.2.1.3.2 [SRS_Can_01059] CAN 驱动应保证接收 L-PDU 的数据一致性
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动应保证在复制过程中硬件对象内的数据不会被覆盖。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 新到达的消息可能在从 CAN 控制器读取数据期间覆盖 CAN 硬件缓冲区。这可能导致数据不一致。因此，驱动应确保不复制不一致的数据。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01632)
###### 6.2.1.3.3 [SRS_Can_01045] CAN 驱动应提供接收指示服务
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动应向 CAN 接口通知成功接收。通知通过调用 CAN 接口内实现的静态回调函数完成。通知包括以下信息：<br>• CAN 标识符<br>• DLC<br>• CAN 硬件对象<br>• 指向 SDU 数据的指针 |
| Rationale（原理） | 基本功能，CAN 标准覆盖 |
| Use Case（用例） | 根据 CAN 服务原语，接收到的 CAN 帧的接收应被指示给下一个上层。此服务由 CAN 接口使用（在指示时，它通知下一个上层并复制接收到的数据）。 |
| Dependencies（依赖） | [SRS_Can_01003] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01064,RS_BRF_01544)
###### 6.2.1.3.4 [SRS_Can_01049] CAN 驱动应提供动态发送请求服务
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动 API 应提供动态发送请求服务（由 CAN 接口调用）。L-PDU 的 DLC 和 ID 作为参数给出。<br>CAN 接口提供以下参数：<br>• CAN 硬件对象句柄（隐含 CAN 控制器）<br>• L-PDU：<br>&nbsp;&nbsp;o 指向 L-SDU 源的指针<br>&nbsp;&nbsp;o CAN 标识符<br>&nbsp;&nbsp;o DLC |
| Rationale（原理） | 基本功能，CAN 标准覆盖 |
| Use Case（用例） | Basic-CAN 发送硬件对象 |
| Dependencies（依赖） | [SRS_Can_01008] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01544)
###### 6.2.1.3.5 [SRS_Can_01051] CAN 驱动应提供发送确认服务
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动应向 CAN 接口通知成功发送。在这种情况下，成功发送意味着至少一个接收器确认了 CAN 帧并且它没有被错误打断。通知通过调用 CAN 接口内实现的静态回调函数完成。 |
| Rationale（原理） | 基本功能，CAN 标准覆盖 |
| Use Case（用例） | 根据 CAN 服务原语，应确认 CAN 帧的发送。 |
| Dependencies（依赖） | [SRS_Can_01009] |
| Supporting Material（支持材料） | ISO11898 第 6.3.3 节 "Recovery management" |
⌋( RS_BRF_01704, RS_BRF_01544)
###### 6.2.1.3.6 [SRS_Can_01053] CAN 驱动应提供更改 CAN 控制器模式的服务
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动应提供更改指定 CAN 控制器模式的服务。应为以下状态提供支持：<br>• UNINIT（未初始化）— CAN 控制器未配置，通常寄存器处于复位状态<br>• STOPPED（已停止）— CAN 控制器已配置但不参与 CAN 通信<br>• STARTED（已启动）— CAN 控制器已启动并正在运行<br>• SLEEP（睡眠）— CAN 控制器处于睡眠模式<br>相应的 CAN 驱动 SWS 详细描述了可能的状态转换。<br>相应模式转换所需的所有硬件初始化都在此服务内完成。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 在睡眠模式下，CAN 控制器可以针对低功耗进行初始化。这是通过此服务完成的，用于 SLEEP 转换。在总线关闭的情况下，控制器可以设置为 UNINIT 状态（通常复位控制器）然后稍后设置为运行。 |
| Dependencies（依赖） | [SRS_Can_01027] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.1.3.7 [SRS_Can_01054] CAN 驱动应为控制器唤醒事件提供通知
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动模块应在 CAN 控制器的唤醒中断的情况下通知服务层。通知通过调用由 ECU StateManager 指定的静态回调函数完成，但由 Complex Driver 或所谓的"集成代码"实现。<br>仅当 CAN 硬件单元支持睡眠模式并且具有特定的唤醒中断时，才应实现此功能。即使 CAN 硬件支持，此功能也应可预编译时配置。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 任何唤醒源都被通知给 ECU StateManager。ECU StateManager 将此通知转发给负责的模块（通常是 CAN 接口），后者检查唤醒源。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01664)
###### 6.2.1.3.8 [SRS_Can_01122] CAN 驱动应支持在到 standby/sleep 的转换进行的同时通过总线发生唤醒的情况
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 总线唤醒始终与到睡眠的内部转换异步。在最坏的情况下，唤醒发生在到睡眠的转换期间。这种情况必须由软件设计覆盖并针对每个 ECU 显式测试。<br>假设这种最坏情况，驱动应在进入 standby/sleep 模式的 API 完成后立即引发唤醒通知。<br>提示：如果 ECU 硬件具有从不同硬件组件（例如收发器和控制器）通知一个唤醒原因的能力，则由系统配置选择信号源。 |
| Rationale（原理） | 安全的唤醒和睡眠处理 |
| Use Case（用例） | 影响所有具有总线唤醒的总线。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01664)
###### 6.2.1.3.9 [SRS_Can_01132] CAN 驱动应能通过 CAN 中断和轮询按消息对象检测通知事件
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 根据配置，任何接收、发送或错误事件的检测应通过释放 CAN 中断和通过 CAN 驱动轮询完成。两种机制应可对每个消息对象配置（如果 CAN 硬件支持）。 |
| Rationale（原理） | 全局轮询 CAN 硬件会导致以下问题：轮询速率属于具有最短周期时间的 CAN 消息，这可能导致非常高的运行时。中断通知提供了实时反应的能力。这对于具有非常短周期时间的消息特别有用。 |
| Use Case（用例） | 网关/CCP/网络层 <=> 系统间通信。时间触发的复杂驱动程序，对保证固定反应时间和确保可预测行为有严格限制。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.1.3.10 [SRS_Can_01134] CAN 驱动应支持多路传输
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 如果底层 CAN 控制器支持，CAN 驱动应支持多路传输。<br>"多路传输"的定义：三个 TX 硬件对象对上层表示为一个发送实体（硬件对象句柄）。这避免了连续发送 L-PDU 之间的间隔。<br>仅当 CAN 硬件满足以下要求时，才应实现此功能选项：<br>[三个硬件对象表示为单个寄存器集 或者 硬件提供标识空闲缓冲区的寄存器]<br>且<br>[L-PDU 按其优先级顺序发送] |
| Rationale（原理） | 可以避免外部优先级反转 |
| Use Case（用例） | Basic-CAN 发送硬件对象 |
| Dependencies（依赖） | [SRS_Can_01058] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.1.3.11 [SRS_Can_01147] CAN 驱动不应支持远程帧
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动不应发送由远程发送请求触发的消息。CAN 驱动应初始化 CAN 硬件以忽略任何远程发送请求。 |
| Rationale（原理） | 远程发送请求不在汽车领域使用。 |
| Use Case（用例） | 参见原理 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.1.3.12 [SRS_Can_01161] CAN 驱动应支持经典 CAN 和 CAN FD
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | New |
| Description（描述） | 如果 CAN 硬件支持，CAN 驱动应能在一个 CAN 控制器上同时使用经典 CAN 和 CAN FD 帧进行操作。 |
| Rationale（原理） | CAN (FD) 标准覆盖 |
| Use Case（用例） | CAN FD 帧在更高的波特率下支持每帧最多 64 字节，某些项目可能需要。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | ISO 11898-1 |
⌋( RS_BRF_01712)
###### 6.2.1.3.13 [SRS_Can_01167] CAN 驱动应提供返回当前 CAN 控制器错误状态的函数
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 该函数应返回当前驱动状态 ACTIVE（主动）、PASSIVE（被动）和 BUSOFF（总线关闭）。 |
| Rationale（原理） | 在进入 CAN passive 或 bus-off 状态时设置 DTC。 |
| Use Case（用例） | CAN 驱动的用户在 CAN passive 或 bus-off 状态时需要设置 DTC。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋()
###### 6.2.1.3.14 [SRS_Can_01170] CAN 驱动应提供返回当前 CAN 控制器 Rx 和 Tx 错误计数器的函数
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动应通过专用函数报告当前的 Rx 和 Tx 错误计数器。 |
| Rationale（原理） | 错误计数器在大多数 CAN 控制器中可用，AUTOSAR 应提供对此信息的标准化访问。 |
| Use Case（用例） | 提供有关 CAN 总线当前状态的信息以用于诊断目的。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | Concept 634 "Bus Mirroring" |
⌋()
#### 6.2.2 CAN Interface (Hardware Abstraction)
CAN 接口提供标准化接口，以提供与 ECU 的 CAN 总线系统的通信。API 独立于特定的 CAN 控制器和收发器以及它们通过负责的驱动层进行的访问。CAN 接口能够通过一个统一接口访问一个或多个 CAN 驱动和 CAN 收发器驱动。
有关详细的功能描述和接口定义，请参见 CAN 接口规范 [CanIf]。
##### 6.2.2.1 Configuration（配置）
###### 6.2.2.1.1 [SRS_Can_01015] CAN 接口配置应能够从 CAN 通信矩阵导入信息
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口的静态配置应基于 CAN 通信矩阵中的信息。应从 CAN 通信矩阵中提取以下信息：<br>• 每个 CAN 控制器的单独 RX L-PDU — 由 CAN ID 标识<br>• 每个 CAN 控制器的 RX L-PDU 范围<br>• 每个 CAN 控制器的所有 TX L-PDU — 由 CAN ID 标识<br>• 每个 CAN 控制器的 TX L-PDU 范围<br>• 每个 L-PDU（-范围）的上层客户端<br>• 每个 L-PDU（-范围）的 DLC<br>配置参数应允许为预编译、链接时或后构建类型。 |
| Rationale（原理） | CAN 网络的公共数据库 |
| Use Case（用例） | 通信矩阵用于描述网络中的所有消息及其发送者和接收者。此信息可用于配置软件过滤算法、DLC 检查和 CAN 接口的通知。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.2.1.2 [SRS_Can_01016] CAN 接口应具有到 CAN 驱动静态配置信息的接口
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口及其代码配置器/生成器应能够读取 ECU 配置描述中的 CAN 驱动配置。 |
| Rationale（原理） | 灵活性和可扩展性 |
| Use Case（用例） | 根据配置的硬件过滤器优化软件过滤 |
| Dependencies（依赖） | [SRS_Can_01036], [SRS_Can_01039] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.2.1.3 [SRS_Can_01018] CAN 接口应允许在预编译时以及链接时和后构建时配置其软件接收过滤器
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 所有未由硬件过滤器过滤且在网络数据库中未定义为接收 L-PDU 的 L-PDU 需要由软件中实现的过滤器拒绝。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 不应由 ECU 接收但无法由硬件过滤器过滤的消息应由 CAN 接口中的软件过滤。 |
| Dependencies（依赖） | [SRS_Can_01037], [SRS_Can_01004], [SRS_Can_01039] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.2.1.4 [SRS_Can_01019] 应可预编译时配置是否执行 DLC 检查
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 应可预编译时配置是否执行 DLC 检查 — 对每个 CAN 控制器全局执行。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 关闭 DLC 检查可提高旧 ECU 的可交换性，其中 ID 保持不变但 SDU 长度不同。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.2.1.5 [SRS_Can_01020] TX 缓冲区应可静态配置
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 应可在预编译时配置每个 L-PDU 是有一个缓冲区还是没有缓冲区。 |
| Rationale（原理） | -- |
| Use Case（用例） | 实现 ECU 的不同变体需要不同的属性。 |
| Dependencies（依赖） | [SRS_Can_01011] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
##### 6.2.2.2 Initialization（初始化）
###### 6.2.2.2.1 [SRS_Can_01021] CAN 接口应实现初始化接口
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口应实现一个用于初始化的接口。此服务应初始化所有模块全局变量。 |
| Rationale（原理） | 基本功能。 |
| Use Case（用例） | CAN 接口具有需要初始化的静态变量，然后才能使用 CAN 接口。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01136)
###### 6.2.2.2.2 [SRS_Can_01022] CAN 接口应支持配置集的选择
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口应支持从不同静态配置集列表中选择一个配置集。这应通过通过初始化接口传递的参数来完成。这通常在启动期间完成一次。 |
| Rationale（原理） | 支持运行时的不同配置 |
| Use Case（用例） | 另一个模块（独立于 CanIf）检查启动条件，例如根据车内的安装位置，选择适当的配置集。然后将其传递给 CanIf。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01136)
###### 6.2.2.2.3 [SRS_Can_01023] CAN 接口应以定义的方式初始化
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口应按以下顺序初始化：<br>1. 初始化全局变量<br>2. 复位标志<br>此顺序必须按此顺序执行，因为 CAN 接口必须在 CAN 驱动（从而通信启动）之前可操作。 |
| Rationale（原理） | 定义的初始化序列，无副作用。 |
| Use Case（用例） | 上电复位 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01136)
##### 6.2.2.3 Normal Operation（正常运行）
###### 6.2.2.3.1 [SRS_Can_01002] CAN 接口应负责接收 PDU 的分派
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口知道哪个上层是成功接收的 L-PDU 的接收方，并决定它属于哪一层。这就是为什么 CAN 接口可以将顺序 L-PDU 重定向到其目的地。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 通过不同的上层提供对接收到的 CAN 数据的访问 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.2.3.2 [SRS_Can_01003] 适当的高层通信栈应由 CAN 接口通知已发生的接收
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动将指示每个成功接收的 L-PDU。适当的高层通信栈应由 CAN 接口通知已发生的接收。此指示事件的路由此任务是 CAN 接口的任务。指示只是一个通知，不传输数据。有关已接收的 L-PDU 的信息应是指示的一部分。 |
| Rationale（原理） | 基本功能，CAN 标准覆盖 |
| Use Case（用例） | 根据 CAN 服务原语，接收到的 CAN 帧的接收应被指示给下一个上层。 |
| Dependencies（依赖） | [SRS_Can_01045] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01544)
###### 6.2.2.3.3 [SRS_Can_01114] 应保证要发送的 L-PDU 的数据一致性
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 在发送数据复制期间，必须防止相应的内存区域被上层覆盖。 |
| Rationale（原理） | 数据一致性 |
| Use Case（用例） | 上层写入同时为 CAN 发送读出的数据区域。这将导致数据不一致，因此必须防止。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01632)
###### 6.2.2.3.4 [SRS_Can_01004] 软件过滤应由 CAN 接口实现
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 基于 CAN 标识符的 L-PDU 过滤应由 CAN 接口实现。如果接收到的 L-PDU 未通过软件过滤器，则不会进一步处理。不会通知上层。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 不应由 ECU 接收但无法由硬件过滤器过滤的消息应由 CAN 接口中的软件过滤。 |
| Dependencies（依赖） | [SRS_Can_01015], [SRS_Can_01018], [SRS_Can_01037], [SRS_Can_01039] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01608)
###### 6.2.2.3.5 [SRS_Can_01005] CAN 接口应对接收到的 PDU 执行正确的 DLC 检查
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口应检查通过 SW 过滤器的接收 L-PDU 的 DLC。DLC 应大于或等于配置的 L-PDU 长度。如果接收到的 L-PDU 未通过 DLC 检查，则不应进一步处理。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 避免因不完整的 L-SDU 导致的数据不一致 |
| Dependencies（依赖） | [SRS_Can_01015] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.2.3.6 [SRS_Can_01006] CAN 接口应提供按 CAN 控制器启用/禁用 L-PDU 接收的服务
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口的 API 应提供一个服务来启用/禁用属于一个 CAN 控制器的所有传入 L-PDU 的接收，这些 L-PDU 通常会导致接收指示（和数据复制）。<br>如果接收到的 L-PDU 被禁用，则不会进一步处理。不会通知上层。此服务直接通过隧道传送到相应的 CAN 驱动。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | COM Manager 必须能够抑制相应 CAN 网络的所有接收事件。它是打开/关闭发送路径的补充功能。 |
| Dependencies（依赖） | [SRS_Can_01013] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704,RS_BRF_01680)
###### 6.2.2.3.7 [SRS_Can_01007] CAN 接口应将上层模块的发送请求分派到所需的 CAN 控制器
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 如果 CAN 硬件单元由多个 CAN 控制器组成，则 CAN 接口应将上层模块的发送请求分派到所需的 CAN 控制器。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 一个 ECU 上有多个片上 CAN 控制器。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01544)
###### 6.2.2.3.8 [SRS_Can_01008] CAN 接口应提供发送请求服务
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口 API 应提供发送请求服务。L-PDU 要么转发到 CAN 驱动，要么存储在 TX 缓冲区中。 |
| Rationale（原理） | 基本功能，CAN 标准覆盖 |
| Use Case（用例） | 根据 CAN 服务原语，应提供发送服务。 |
| Dependencies（依赖） | [SRS_Can_01011], [SRS_Can_01020] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01544)
###### 6.2.2.3.9 [SRS_Can_01009] CAN 接口应提供发送确认分派器
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口必须将成功的发送通知适当的上层模块。因此，CAN 接口必须在 CAN 驱动确认后分派发送确认。应可对每个 PDU 静态配置是否将确认转发到上层。 |
| Rationale（原理） | 基本功能，CAN 标准覆盖 |
| Use Case（用例） | 根据 CAN 服务原语，应确认 CAN 帧的发送。 |
| Dependencies（依赖） | [SRS_Can_01051] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01544)
###### 6.2.2.3.10 [SRS_Can_01011] CAN 接口应提供发送缓冲区
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口应仅在以下情况下缓冲挂起的发送请求：<br>• 如果 CAN 驱动因硬件资源不可用而拒绝了先前的发送请求<br>• 如果在 CAN 驱动中取消了挂起的发送请求<br>发送缓冲区应提供以下功能：<br>• 每个发送 L-PDU 应具有对一个缓冲区容器的精确引用<br>• 缓冲区容器的大小定义可缓冲的 L-PDU 数量<br>• 如果缓冲区大小为 0，表示不会进行 CanIf 缓冲<br>• 每个缓冲区容器应具有 1...n 个对逻辑硬件发送对象（HTH）的引用（将用于发送）<br>• 一个 HTH 恰好有一个对缓冲区的引用<br>• 缓冲区应仅在达到"Tx Offline"状态时刷新<br>• 缓冲区应具有优先级顺序，不应存储 L-PDU 的多个实例<br>• 在缓冲区溢出的情况下，发送服务应返回"Not OK"<br>• 在 Tx 确认期间，最高优先级的 L-PDU 应转发到 CAN 驱动。优先级由属于发送 L-PDU 的 CAN 标识符定义。只有 L-PDU 的最新实例应存储在其自己的缓冲区中，旧的应被覆盖<br>• 应有一个配置选项来定义缓冲区固定为 8 字节<br>应可预编译时配置 CanIf 是否提供发送缓冲区。 |
| Rationale（原理） | 基本功能，Tx 缓冲区的有限资源 |
| Use Case（用例） | 由于具有更高优先级的消息处于挂起状态，消息可能不会立即发送。需要为每个 PDU 缓冲一个实例，以确保每个 L-PDU 的最小延迟时间。 |
| Dependencies（依赖） | [SRS_Can_01020], [SRS_Can_01008] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01544)
###### 6.2.2.3.11 [SRS_Can_01013] CAN 接口应提供每个 CAN 控制器的 Tx-L-PDU 启用/禁用服务
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | NM 需要一个额外的软件服务来锁定和解锁属于一个 CAN 控制器的传出 L-PDU 的发送。此功能必须放在 CAN 接口中。由 WP Architecture 决定。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | -- |
| Dependencies（依赖） | [SRS_Can_01006] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704,RS_BRF_01680)
###### 6.2.2.3.12 [SRS_Can_01027] CAN 接口应提供更改 CAN 控制器模式的服务
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口应提供更改指定 CAN 控制器模式的服务。此服务通常由 NM 根据物理通道的视图调用。限制：物理通道仅由一个 CAN 控制器表示。<br>应支持以下模式：<br>• UNINIT<br>• STARTED<br>• STOPPED<br>• BUSOFF（软件无法达到）<br>• SLEEP<br>相应模式转换所需的所有初始化都在 CAN 驱动内完成。可能的状态转换在相应的 CAN 驱动 SWS 中描述。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 此服务表示 CAN 驱动模式选择服务的接口。 |
| Dependencies（依赖） | [SRS_Can_01053] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01664)
###### 6.2.2.3.13 [SRS_Can_01028] CAN 接口应提供查询 CAN 控制器状态的服务
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口应提供一个查询 CAN 控制器状态的服务。有关可能状态的详细信息，请参阅 CAN 接口 SWS 文档。<br>提示：通过此服务轮询 CAN 接口的内部状态。在某些情况下，实际硬件状态可能在一定时间内有所不同。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 如果 CAN 控制器不提供中断服务，则可以使用。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01664)
###### 6.2.2.3.14 [SRS_Can_01151] CAN 接口应提供检查 CAN 唤醒事件的服务
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口模块应提供一个服务来检查 CAN 唤醒事件发生时的 CAN 唤醒源。此服务通过驱动模块查询 CAN 控制器和 CAN 收发器以查找唤醒源。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | ECU 可以通过不同方式识别 CAN 唤醒：轮询、CAN 控制器中断、CAN 收发器中断。在每种情况下，ECU StateManager 都需要此服务来检查 CAN 接口是否有导致唤醒的唤醒源。有关用例的更多详细信息，请参阅 ECU StateManager 文档中的图 33-35。 |
| Dependencies（依赖） | [SRS_Can_01032] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01104,RS_BRF_01680)
###### 6.2.2.3.15 [SRS_Can_01032] CAN 接口应向 ECU StateManager 报告唤醒通知
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 在 CAN 接口模块检查 CAN 控制器和 CAN 收发器的唤醒事件后，它应将导致唤醒的事件和源通知给 ECU StateManager。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | ECU 可以通过不同方式识别 CAN 唤醒。在每种情况下，ECU StateManager 都需要此通知以激活正确的 CAN 控制器进行唤醒验证。有关用例的更多详细信息，请参阅 ECU StateManager 文档中的图 33-35。 |
| Dependencies（依赖） | |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01664,RS_BRF_01680)
###### 6.2.2.3.16 [SRS_Can_01061] CAN 接口应提供动态 TX 句柄
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口应提供可由上层分配的动态 TX 句柄。上层应可以更改动态 TX 句柄的 ID 和 DLC。应预编译时配置是否使用此功能。 |
| Rationale（原理） | 与空白或无效的 L-PDU ID 表通信或上层直接控制 CAN 标识符。 |
| Use Case（用例） | 动态计算的 TX ID。仅允许在网络中已知的 ID 范围。通常由 TP 使用，其中目标地址在 CAN 标识符内编码。目标地址不能静态定义。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.2.3.17 [SRS_Can_01159] CAN 接口应提供动态 RX 句柄
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口应提供可由上层分配的动态 RX 句柄。动态 RX 句柄的 ID 和 DLC 将提供给上层。应预编译时配置是否使用此功能。 |
| Rationale（原理） | 上层访问 CAN 标识符。 |
| Use Case（用例） | 动态评估的 RX ID。通常由 TP 或 J1939 使用，其中目标和/或源地址在 CAN 标识符内编码。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704,RS_BRF_01728,RS_BRF_01736)
###### 6.2.2.3.18 [SRS_Can_01130] CAN 接口的接收状态接口
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口还应提供一个接口，上层可以通过该接口轮询消息的通知状态。 |
| Rationale（原理） | 灵活集成<br>避免强耦合和依赖<br>时间触发行为的上层确定性行为 |
| Use Case（用例） | CAN 发送请求命令的完成不仅可以通过回调函数发出信号，现在还可以通过可通过模块接口访问的状态信息发出信号。CAN 发送请求期间发生的故障（总线被阻塞、CAN 控制器有缺陷）可以通过错误钩子发出信号。 |
| Dependencies（依赖） | |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.2.3.19 [SRS_Can_01131] CAN 接口模块应提供并行使用轮询和回调通知机制的可能性
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 在回调通知机制同时，"Read Message Data" 和 "Read Message Status" API 应能同时使用。<br>应允许上层根据其需要调整对接收到的 CAN 消息的新数据和状态的访问，并且它们不依赖于网络流量。<br>不同的 CAN 接口客户端对延迟有不同的需求（通知机制提供小的延迟时间，轮询机制提供大的延迟时间）。因此，应可能区分要接收的不同 CAN 消息的读数据和通知机制。 |
| Use Case（用例） | 网关/CCP/网络层 <=> 系统间通信。时间触发的复杂驱动程序，对保证固定反应时间和确保可预测行为有严格限制。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01544)
###### 6.2.2.3.20 [SRS_Can_01136] CAN 接口模块应提供检查 CAN 唤醒事件验证的服务
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口模块应提供检查 CAN 唤醒事件验证的服务（参见 SRS_Can_01032）。仅当在检测到唤醒事件的 CAN 总线上正确接收到消息时，它才通知 ECU StateManager 已验证的唤醒事件。 |
| Rationale（原理） | 降低功耗 |
| Use Case（用例） | 唤醒验证服务应由 ECU Statemanager 在相应的 CAN 收发器设置为正常模式且 CAN 控制器启动后调用。在验证期间，传入的消息不得由 CAN 接口转发到上层，因为相应的 L-PDU 通道组仍应被禁用（脱机）。 |
| Dependencies（依赖） | [SRS_Can_01032] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704,RS_BRF_01680,RS_BRF_01664)
###### 6.2.2.3.21 [SRS_Can_01129] CAN 接口模块应提供一个过程接口，用于上层读取单个 CAN 消息的数据（轮询机制）
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 在获取有关新接收数据的信息后（通过调用 get 状态接口 SRS_SPAL_00157），上层必须能够读出数据。因此 CAN 接口应提供相应的 API（'ReadMessageData()'）以读出接收到的 CAN 消息的数据。所描述的函数应可预编译时选择。 |
| Rationale（原理） | 灵活性（上层应有可能决定何时以及是否应传输数据（数据流由上层控制）<br>避免强耦合和依赖（参见 BSW 157 的原理）<br>在确定性行为的时间触发软件系统中有应用。确定性行为只能在这些应用程序不被总线事件中断的情况下确保。 |
| Use Case（用例） | CAN 消息接收事件完成的通知可用于在上层需要时读出数据。使用该 API，数据从 CAN 硬件缓冲区或 CAN 驱动的影子缓冲区访问。例如 'GetMessageData()' API 的数据规范化所需的此中间缓冲区应可为每个 CAN Rx 标识符配置。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01544)
###### 6.2.2.3.22 [SRS_Can_01140] CAN 接口应支持标准（11 位）和扩展（29 位）标识符
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口应支持标准和扩展标识符。应可为每个网络配置是支持标准还是扩展标识符。 |
| Rationale（原理） | 标准 CAN 2.0b 功能 |
| Use Case（用例） | |
| Dependencies（依赖） | [SRS_Can_01141] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.2.3.23 [SRS_Can_01141] CAN 接口应支持在一个网络上同时使用标准（11 位）和扩展（29 位）标识符
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 此需求描述了 SRS_Can_01140 之外的一种实现变体：<br>CAN 接口应能在一个网络上同时支持标准和扩展标识符（=混合模式支持）。<br>由于对代码效率和复杂性有重大影响，此功能应为可选。<br>如果不购买此功能，SRS_Can_01140 仍然有效。 |
| Rationale（原理） | -- |
| Use Case（用例） | 在具有两种标识符类型的 CAN 网络中使用便宜的 Basic CAN 控制器 |
| Dependencies（依赖） | [SRS_Can_01036] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.2.3.24 [SRS_Can_01153] 在部分网络化的情况下，Tx 过滤器应确保总线上发送的第一条消息是唤醒帧（WUF）
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 如果 L-PDU 被激活用于发送，则 Tx 过滤器应切换到阻塞模式。<br>如果 Tx 过滤器处于阻塞模式，则除了唤醒帧（WUF）之外，所有 L-PDU 都应被丢弃。<br>如果 L-PDU 处于阻塞模式并且唤醒帧（WUF）已发送，则应将其转发到下层。<br>如果 CAN 接口接收到 WUF 的发送通知，则 Tx 过滤器应切换到通过模式。<br>如果 Tx 过滤器处于通过模式，则所有 L-PDU 都应转发到下层。<br>Tx 过滤器在总线关闭模式下不应激活。 |
| Rationale（原理） | 如果使用部分网络化，ECU 必须确保总线上的第一条消息是唤醒帧（WUF）。 |
| Use Case（用例） | 从 BusSleep 模式、PrepareBusSleep 模式、BusOff 开始通信 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01680)
###### 6.2.2.3.25 [SRS_Can_01158] CAN 栈应为 ECU 被动模式提供 TX 脱机主动模式
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 栈应提供 tx 脱机主动模式以允许 ECU 被动模式。 |
| Rationale（原理） | ECU 被动模式用于通过对应用程序"模拟"成功的发送请求来禁用所有 Tx 请求。 |
| Use Case（用例） | 诊断、临时关闭所有发送 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋(RS_BRF_01704)
###### 6.2.2.3.26 [SRS_Can_01160] 由于离散 CAN FD DLC 导致字节填充
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | New |
| Description（描述） | 由 CAN FD 帧的离散 DLC（> 8 字节）引起的未使用字节应被填充。 |
| Rationale（原理） | CAN FD 帧通过仅使用 4 位 DLC 来指示有效负载长度，支持每帧最多 64 字节。但是，> 8 字节的帧的长度可配置为 12、16、20、24、32、48 和 64 字节。如果 PDU 与这些可配置大小不完全匹配，则未使用的字节应被填充。 |
| Use Case（用例） | PDU 声明的大小与 CAN FD 的离散 DLC 不同。大小最多到下一个离散 DLC 必须被填充，以避免在接收时误解。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | ISO 11898-1 |
⌋(RS_BRF_01712)
###### 6.2.2.3.27 [SRS_Can_01162] CAN 接口应支持经典 CAN 和 CAN FD 帧
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | New |
| Description（描述） | CAN 接口应支持经典 CAN 和 CAN FD L-PDU。应可为每个 L-PDU 配置是分配经典 CAN 还是 CAN FD 帧。 |
| Rationale（原理） | CAN (FD) 标准功能 |
| Use Case（用例） | CanIf 必须区分 CAN 和 CAN FD L-PDU，以允许在上层（例如 CanTp）中进行适当的处理。 |
| Dependencies（依赖） | [SRS_Can_01061] |
| Supporting Material（支持材料） | ISO 11898-1 |
⌋(RS_BRF_01712)
###### 6.2.2.3.28 [SRS_Can_01169] CAN 接口应提供返回当前 CAN 控制器错误状态的函数
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 该函数应返回当前驱动状态 ACTIVE、PASSIVE 和 BUSOFF。 |
| Rationale（原理） | 在进入 CAN passive 或 bus-off 状态时设置 DTC。 |
| Use Case（用例） | CAN 驱动的用户在 CAN passive 或 bus-off 状态时需要设置 DTC。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋()
###### 6.2.2.3.29 [SRS_Can_01171] CAN 接口应提供返回当前 CAN 控制器 Rx 和 Tx 错误计数器的函数
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口应通过专用函数报告当前的 Rx 和 Tx 错误计数器。 |
| Rationale（原理） | 错误计数器在大多数 CAN 控制器中可用，AUTOSAR 应提供对此信息的标准化访问。 |
| Use Case（用例） | 提供有关 CAN 总线当前状态的信息以用于诊断目的。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | Concept 634 "Bus Mirroring" |
⌋()
###### 6.2.2.3.30 [SRS_Can_01172] CAN 接口应提供将接收和发送的帧提供给 Bus Mirroring 的函数
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 如果启用，CAN 接口应将一个 CAN 控制器接收和发送的所有帧报告给 Bus Mirroring。 |
| Rationale（原理） | 此功能应驻留在 CAN 接口中，因为 CAN 接口从不同的 CAN 驱动模块抽象出来，并且仍然可以访问 CAN 驱动处理的所有 CAN 帧。 |
| Use Case（用例） | 出于诊断目的镜像 CAN 总线流量。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | Concept 634 "Bus Mirroring" |
⌋()
##### 6.2.2.4 Shutdown Operation（关闭操作）
###### 6.2.2.4.1 [SRS_Can_01168] CAN 接口应实现去初始化接口
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口应实现一个用于去初始化的接口。此服务应将模块置于接受后续初始化调用的状态。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 应能使用新的配置集重新配置 CAN 栈，而无需 ECU 复位。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋()
##### 6.2.2.5 Fault Operation（故障操作）
###### 6.2.2.5.1 [SRS_Can_01029] CAN 接口应将设备的总线关闭状态报告给上层
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 当 CAN 接口通过 CAN 驱动状态变化通知检测到总线关闭状态时，应调用在 CAN State Manager 中实现的回调函数。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 任何状态转换都通过 CAN 接口通知。总线关闭通知通常由 CAN State Manager 处理。 |
| Dependencies（依赖） | [SRS_Can_01055] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01664)
#### 6.2.3 CAN State Manager
##### 6.2.3.1 Configuration（配置）
###### 6.2.3.1.1 [SRS_Can_01143] CAN State Manager 应支持可配置的 BusOff 恢复时间
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN State Manager 应控制 BusOff 恢复算法。从 CAN 控制器检测到 BusOff 事件到通信重新启动之间的时间应可配置。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 在检测到 BusOff 后延迟通信以克服临时总线干扰。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01664, RS_BRF_01600)
##### 6.2.3.2 Initialization（初始化）
###### 6.2.3.2.1 [SRS_Can_01144] CAN State Manager 应提供上电初始化通信模式的接口
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN State Manager 应提供一个接口，用于在上电时初始化通信模式。初始化的通信模式应可配置。应能以全通信模式、静默通信模式或无通信模式启动。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | ECU 在上电后具有不同种类的通信行为（仅在应用程序需要全通信能力之前进行侦听，或立即具有全通信能力）。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01664, RS_BRF_01600)
##### 6.2.3.3 Normal Operation（正常运行）
###### 6.2.3.3.1 [SRS_Can_01145] CAN State Manager 应控制分配的 CAN 设备
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN State Manager 应启动和停止 CAN 设备并使它们准备好进入睡眠。 |
| Rationale（原理） | 降低了 CAN 接口的复杂性 |
| Use Case（用例） | 数据流和控制流的分离 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
##### 6.2.3.4 Shutdown Operation（关闭操作）
[SRS_Can_01164]⌈ CAN State Manager 应实现去初始化接口。⌋ ()
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN State Manager 应实现一个用于去初始化的接口。此服务应将模块置于接受后续初始化调用的状态。 |
| Rationale（原理） | 基本功能 |
| Use Case（用例） | 应能使用新的配置集重新配置 CAN 栈，而无需 ECU 复位。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
##### 6.2.3.5 Fault Operation（故障操作）
###### 6.2.3.5.1 [SRS_Can_01146] CAN State Manager 应为每个使用的 CAN 控制器包含 CAN BusOff 恢复算法
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN State Manager 应通过算法控制 CAN BusOff 恢复。它应向 Diagnostic Event Manager 报告生产错误"CAN BusOff"。如果在可配置的时间内无法恢复，则应针对每个配置的 CAN 网络报告特定的"CAN BusOff"生产错误。 |
| Rationale（原理） | 网络控制器特定的错误和总线状态管理 |
| Use Case（用例） | 参见原理 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01664, RS_BRF_01600)
#### 6.2.4 Transport Layer CAN
本章节描述了 CAN 传输层 [CanTp] 的需求。
AUTOSAR CAN 传输层通常基于 ISO 15765-2 和 ISO 15765-4 规范。
##### 6.2.4.1 Configuration（配置）
###### 6.2.4.1.1 [SRS_Can_01066] AUTOSAR CAN 传输层应可静态配置为以优化方式支持单个或多个连接
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | AUTOSAR CAN 传输层应可静态配置为以优化方式支持单个或多个连接。此配置在预编译时完成。 |
| Rationale（原理） | 当 ECU 启用网关能力时，它必须同时处理跨不同子网络的不同消息传输。因此 AUTOSAR 传输层允许并发连接。但是，大多数 ECU 只需要用于诊断的单个连接，必须以优化的方式实现。 |
| Use Case（用例） | 用例是以优化的方式提供单个和多个连接，以节省运行时和代码大小。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01720)
###### 6.2.4.1.2 [SRS_Can_01068] CAN 传输层应使用唯一标识符标识每个 N-SDU
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 传输层使用唯一标识符标识每个 N-SDU。因此上层可以在不考虑 CAN-TP 寻址模式配置的情况下寻址 N-SDU。此外，可以为每个 N-SDU 标识符值分配符号名称以简化 API 的使用。 |
| Rationale（原理） | 上层独立于 CAN-TP 配置。 |
| Use Case（用例） | PDU-Router 可以操作所有 N-SDU（FlexRay、CAN 和 LIN），无论其底层协议的寻址模式特殊性如何。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01720)
###### 6.2.4.1.3 [SRS_Can_01069] CAN 地址信息和 N-SDU 标识符映射
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | N-SDU 表示由一组地址信息（N_AI，由 MType、N_TAtype、N_TA、N_SA 和 N_AE 组成）定义的特定连接，或表示到或来自上层的专用通信路径的通用连接，用于地址信息的可能组合（不包括始终为连接定义的 MType 和 N_TAtype）。<br>因此，对于特定连接，N-SDU ID 和地址信息之间存在 1:1 关系，而通用连接仅限制为某些寻址格式和功能/物理请求，并可能限制为某个本地地址。 |
| Rationale（原理） | N-SDU 标识符用于仅发送或接收一种应用消息。N-SDU 要么仅与一个 CAN 地址信息（特定连接）相关联，要么与一组地址信息（通用连接）相关联。另一方面，CAN 地址信息要么链接到恰好一个特定连接，要么链接到多个相同的通用连接。 |
| Use Case（用例） | • 为了发送或接收应用消息，CAN 传输层仅需要数据和 N-SDU 标识符。<br>• 为了从不同的测试仪接收和发送诊断消息，CAN 传输层应使用 CAN 接口的动态 TX 和 RX 句柄直接处理 CAN ID。<br>• 在多个 ECU 之间划分功能，因此一个 ECU 可以属于不同的功能组。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01720)
###### 6.2.4.1.4 [SRS_Can_01071] CAN 传输层应使用唯一标识符标识每个 N-PDU（也称为 L-SDU）
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 传输层使用唯一标识符标识每个 N-PDU。因为 CAN-TP 使用 CAN 接口来发送和接收 N-PDU，这些句柄在两层中应是唯一的。所以需要进行一些公共配置检查。此外，可以为每个标识符值分配符号名称以简化实现。 |
| Rationale（原理） | 每个 CAN 标识符仅对应 CAN 传输层的一个 N-PDU 标识符。因此 N-PDU 可以完全由标识符标识。 |
| Use Case（用例） | 出于优化原因，CAN N-PDU 标识符可能不同于 CAN 标识符。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01720)
###### 6.2.4.1.5 [SRS_Can_01073] CAN 传输层应可静态配置为填充 PDU 的未使用字节
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 传输层应可对每个连接静态配置是否填充未使用字节。这会影响最后一个连续帧（CF）、单帧（SF）和流控制（FC）。在 CAN FD 填充对于大于八的 DLC 值是强制性的情况下，当要传输的数据长度不等于 ISO 11898-1:2014 DLC 表中定义的离散长度值之一时，将添加填充字节。在填充的情况下，经典 CAN 的 DLC 始终为 8（字节），或 CAN FD 的 8、12、16、20、24、32、48 或 64（字节）。DLC 检查应在已用字节上运行。如果配置或强制填充，则 DLC 检查应在所有字节上运行（DLC = 8、12、16、20、24、32、48 或 64）。 |
| Rationale（原理） | 满足法规 OBD 通信（ISO 15765-4）的要求，并将此功能作为 OEM 增强诊断和应用通信的可选项。 |
| Use Case（用例） | 为了与旧 ECU 完全兼容。 |
| Dependencies（依赖） | [SRS_Can_01005] [SRS_Can_01086] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01720, RS_BRF_01712)
###### 6.2.4.1.6 [SRS_Can_01074] 传输连接属性应可静态配置
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 传输连接配置应静态分配每个 N-SDU 的属性：<br>- 其唯一标识符<br>- 通信方向：发送方或接收方<br>- N-SDU 的最小长度<br>- 关联的 N-PDU 标识符<br>- 物理（1 对 1 通信）或功能（1 对 n 通信）寻址<br>- 寻址模式：请参阅 [SRS_Can_01078]<br>- 在扩展寻址模式连接的情况下：N_TA 和 N_SA 值 |
| Rationale（原理） | 在运行时，CAN TP 模块必须具有管理传输连接所需的所有信息。 |
| Use Case（用例） | 此信息可在生成时用于从 TP 角度检查网络配置。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01720)
###### 6.2.4.1.7 [SRS_Can_01149] CAN 传输层应支持 TP 通道的全双工通信
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 传输层应支持 TP 通道的全双工通信。这意味着 CAN 传输层应能同时在同一通道上管理接收和发送。 |
| Rationale（原理） | 节省 CAN 标识符。 |
| Use Case（用例） | OEM 特定的非诊断应用需要 CAN 传输协议的全双工实现。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01720)
##### 6.2.4.2 Initialization（初始化）
###### 6.2.4.2.1 [SRS_Can_01075] CAN 传输层应实现初始化接口
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 传输层实现一个用于初始化的接口。此服务应初始化模块的所有全局变量并将所有传输协议连接设置为默认状态（Idle）。 |
| Rationale（原理） | 基本功能。 |
| Use Case（用例） | 将传输层软件设置为定义状态 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01720)
###### 6.2.4.2.2 [SRS_Can_01076] CAN 传输层服务在初始化模块之前不应可操作
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 在使用 CAN 传输层的发送能力之前，应初始化它。如果不是这种情况，服务必须返回错误并报告开发错误。 |
| Rationale（原理） | 基本功能。 |
| Use Case（用例） | 为了避免在没有完全初始化的情况下使用模块，这可能导致损坏帧的传输。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01720)
##### 6.2.4.3 Normal Operation（正常运行）
###### 6.2.4.3.1 [SRS_Can_01078] AUTOSAR CAN 传输层应支持 ISO 15765-2 寻址格式
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | AUTOSAR CAN 传输层应支持 ISO 15765-2 的正常、扩展、混合 11 位、混合 29 位和正常固定寻址格式。 |
| Rationale（原理） | 基本功能。 |
| Use Case（用例） | 除了正常和扩展寻址格式外，汽车领域的远程诊断还需要混合寻址模式。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01720)
###### 6.2.4.3.2 [SRS_Can_01079] CAN 传输层应符合 CAN 接口模块通知
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 传输层应仅实现有关 TP 消息的 CAN 接口通知服务：<br>- 接收通知<br>- Tx 确认<br>提示：BusOff 管理由 CAN State Manager 处理。 |
| Rationale（原理） | 在 AUTOSAR 架构中，CAN 传输层位于 PDU Router 和 CAN 接口之间。 |
| Use Case（用例） | CAN 传输层必须支持由 CAN 接口调用的通知服务。 |
| Dependencies（依赖） | [SRS_Can_01003], [SRS_Can_01009] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704,RS_BRF_01720)
###### 6.2.4.3.3 [SRS_Can_01081] CAN 传输协议超时的值应对每个连接可静态配置
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | ISO 15765-2 规范中定义的所有超时都对每个连接可静态配置。配置参数应允许为预编译时、链接时或后构建时类型。 |
| Rationale（原理） | 调整超时值以适应 ECU 应用领域。 |
| Use Case（用例） | 诊断连接和应用连接（例如显示数据）之间的通信约束可能完全不同。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | ISO 15765-2 规范 |
⌋( RS_BRF_01704, RS_BRF_01600,RS_BRF_01720)
###### 6.2.4.3.4 [SRS_Can_01082] 错误处理
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 如果 CAN 传输层接收到意外的 N-PDU，它应遵守 ISO-15765-2 规范中"网络协议数据单元的意外到达"章节中定义的行为。对于其他错误，CAN-TP 只会中止分段会话。 |
| Rationale（原理） | 定义错误时的层行为。 |
| Use Case（用例） | 当接收到第三个 CF 帧而不是第二个时会发生什么？ |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | ISO 15765-2 规范 |
⌋( RS_BRF_01704, RS_BRF_02168, RS_BRF_01600,RS_BRF_01720)
###### 6.2.4.3.5 [SRS_Can_01086] 未使用字节的数据填充值
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 当 CAN 传输层配置为具有固定数据长度（DLC = 8）时，PDU 在不初始化未使用字节的情况下发送。 |
| Rationale（原理） | 将最后一帧中的未使用数据设置为特定值将导致 µC 内运行时和资源需求的增加。 |
| Use Case（用例） | ISO 15765-4 对 OBD 通信的建议明确指出，每个诊断 CAN 帧中包含的 CAN DLC 应始终设置为 8，并且 CAN 帧的未使用数据字节是未定义的。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | ISO 15765-4 §7 |
⌋(RS_BRF_01720)
###### 6.2.4.3.6 [SRS_Can_01116] AUTOSAR CAN 传输层应能并行管理正常和扩展模式
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 当 CAN 传输层配置为支持多个连接时，它还应可配置为必须并行处理正常和扩展寻址模式，还是仅处理正常或扩展寻址模式之一。 |
| Rationale（原理） | 当允许并发连接时，不限制通信能力。但将其作为 OEM 特定的决策。 |
| Use Case（用例） | CAN 子网络可以混合使用具有正常或扩展寻址模式的连接，例如并行使用 OBD（正常寻址）和 UDS（扩展寻址）。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋(RS_BRF_01720)
###### 6.2.4.3.7 [SRS_Can_01148] AUTOSAR CAN 传输层应提供动态设置协议参数的服务
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | AUTOSAR CAN 传输层应提供在运行时更改 BS 和 STmin 参数的服务。此服务支持根据 ISO 15765-2 规范动态设置协议参数。 |
| Rationale（原理） | 动态减慢通信。 |
| Use Case（用例） | 在高性能 ECU 连接到性能较低的网关的网络时减慢闪存重新编程过程。在 CAN 栈不可后构建配置的情况下修改参数。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | ISO 15765-2 规范 |
⌋(RS_BRF_01720)
###### 6.2.4.3.8 [SRS_Can_01163] AUTOSAR CAN 传输层应支持 ISO 15765-2 规定的经典 CAN 和 CAN FD 通信
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | New |
| Description（描述） | CAN 传输层应支持经典 CAN 和 CAN FD 通信。这包括支持长达 64 字节的 N-PDU、最大传输长度扩展到 4GBytes，以及区分经典 CAN 和 CAN FD 通信。 |
| Rationale（原理） | CAN FD 兼容的传输协议 |
| Use Case（用例） | 利用 CAN FD 的扩展有效负载和提高的波特率可提高通信性能。 |
| Dependencies（依赖） | [SRS_CAN_01161] [SRS_CAN_01162] |
| Supporting Material（支持材料） | ISO 15765-2 规范 |
⌋(RS_BRF_01712)
#### 6.2.5 CAN Bus Transceiver Driver
##### 6.2.5.1 Configuration（配置）
###### 6.2.5.1.1 [SRS_Can_01090] 总线收发器驱动包应提供为给定总线和支持的通知配置驱动所需的配置参数
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 典型参数为：<br>- 每条总线的最大支持波特率，以启用配置错误的检测<br>- 通过总线唤醒<br>- 通过 SPI 或端口引脚控制收发器<br>- 通知函数的调用上下文（ISR、轮询），以启用配置时必要的数据一致性机制的检测<br>有关更详细的视图，请参阅相应的软件规范。 |
| Rationale（原理） | 收发器配置的基本功能。 |
| Use Case（用例） | -- |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01136)
###### 6.2.5.1.2 [SRS_Can_01091] CAN 总线收发器驱动应支持多于一条总线的配置
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 驱动应能支持 ECU 上的多个 CAN 总线。必须能为每个总线独立配置使用的收发器类型。这也包括使用不同总线物理的混合系统（例如两个使用不同总线物理的 CAN）。只应可能进行预编译时配置。<br>收发器处理在很大程度上取决于所使用的设备。因此每个收发器可能需要在驱动内有它自己的实现，并且只能选择已知和受支持的设备。对于所有用例的收发器驱动的通用解决方案可能是不可能的。<br>默认情况下，每个 CAN 控制器都连接到自己的总线，因此需要自己的总线收发器。<br>在某些情况下，多个 CAN 控制器连接到同一总线以增加邮箱的数量。出现两种替代方案：<br>a) 这些 CAN 控制器共享相同的总线收发器<br>b) 每个 CAN 控制器都有自己的总线收发器<br>情况 a) 在此规范中涵盖，应由此 AUTOSAR 驱动支持。<br>情况 b) 是很少使用的设置，因此不在此驱动中涵盖。 |
| Rationale（原理） | 收发器配置的基本功能 |
| Use Case（用例） | 多总线系统，例如 CAN-CAN 网关 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.5.1.3 [SRS_Can_01092] 总线收发器驱动应支持为每个支持的总线独立配置总线操作模式
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 由于多 CAN 总线 ECU 的不同启动要求，CAN 收发器驱动应支持在驱动初始化期间设置每个收发器的总线操作模式的独立预选择。 |
| Rationale（原理） | 收发器配置的基本功能 |
| Use Case（用例） | 多总线系统 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋(RS_BRF_01704)
###### 6.2.5.1.4 [SRS_Can_01095] 总线收发器驱动应支持对"通过总线唤醒"事件更改通知向上层的编译时配置
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 应支持一个"通过总线唤醒"事件通知到更高的层。上层应在编译时可配置。<br>如果收发器不支持"通过总线唤醒"，则对于此总线永远不会调用此通知。 |
| Rationale（原理） | 总线收发器驱动和上层之间的有效耦合。 |
| Use Case（用例） | 参见 SRS_Can_01106 |
| Dependencies（依赖） | [SRS_Can_01106] |
| Supporting Material（支持材料） | -- |
⌋(RS_BRF_01704)
###### 6.2.5.1.5 [SRS_Can_01154] 总线收发器驱动包应提供配置驱动部分网络化所需的配置参数
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 典型参数为：<br>- 部分网络化支持<br>- 远程唤醒帧（RWUF）的 CAN ID<br>- SPI 超时参数 |
| Rationale（原理） | 支持部分网络化收发器。 |
| Use Case（用例） | 影响部分网络配置。 |
| Dependencies（依赖） | |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01184, RS_BRF_01088,RS_BRF_01704)
##### 6.2.5.2 Initialization（初始化）
###### 6.2.5.2.1 [SRS_Can_01096] 总线收发器驱动应提供 API 以在内部初始化驱动，然后将所有连接的收发器设置为其预选的操作模式
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 必须在 ECU 的上电/复位序列期间初始化驱动。<br>根据用于控制收发器的驱动（例如 DIO、SPI），它们必须在收发器驱动初始化时已经可用并正常工作。<br>唤醒原因也必须在驱动初始化执行期间被检测和存储。 |
| Rationale（原理） | 将总线收发器和驱动设置为预定义和已知状态 |
| Use Case（用例） | 收发器控制的基本功能。 |
| Dependencies（依赖） | [SRS_Can_01103]<br>总线收发器驱动设置信息必须提供必要的配置数据，以使生成工具能够选择适当的控制机制（例如 SPI、I/O 端口）并保证正确分配必要的通信资源和初始化序列。 |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.5.2.2 [SRS_Can_01155] 总线收发器驱动应支持配置集的选择
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口应支持从不同静态配置集列表中选择一个配置集。这应通过通过初始化接口传递的参数来完成。这通常在启动期间完成一次。 |
| Rationale（原理） | 支持运行时的不同配置 |
| Use Case（用例） | 此请求的原理是，在 ECU 启动时，一些外部条件可以确定 ECU 配置，而不需要通过测试仪或 EOL 过程进行编码（例如编码连接插头，它通过数字代码发出 ECU 在给定车辆中的连接信号，从而确定必要的配置）。 |
| Dependencies（依赖） | [SRS_Can_01096] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01136)
##### 6.2.5.3 Normal Operation（正常运行）
###### 6.2.5.3.1 [SRS_Can_01097] CAN 总线收发器驱动 API 应是同步的
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 总线收发器驱动 API 应立即执行所请求的操作，并应立即将结果状态传递给调用者。这将简化 AUTOSAR BSW 栈内唤醒和睡眠概念的实现。<br>某些 API 可能由于硬件限制（SPI）而需要异步行为。 |
| Rationale（原理） | 在复杂的 AUTOSAR BSW 环境中更好地使用收发器功能。 |
| Use Case（用例） | 原子转换到其他操作模式；对 ECU 状态管理器或 ComManager 等上层的更简单更好的抽象。与异步处理相比，可测试性得到改善。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.5.3.2 [SRS_Can_01098] 总线收发器驱动应支持将寻址的收发器发送到其 Standby 模式的 API
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 许多收发器仅通过转换到 Standby 模式来支持到 Sleep 模式的转换。此外，某些电源概念需要将收发器仅设置为 Standby 而不是 Sleep 模式。<br>并非所有收发器都支持这种状态。如果给定的设备支持此功能，驱动应确认状态转换成功。 |
| Rationale（原理） | 通过总线和内部唤醒实现 ECU 低功耗模式。 |
| Use Case（用例） | 上层服务层与其他节点商定将总线设置为睡眠模式。现在，收发器应切换到支持通过总线唤醒且功耗尽可能低的状态以适应 ECU 的当前状态。 |
| Dependencies（依赖） | [SRS_Can_01099] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.5.3.3 [SRS_Can_01099] 总线收发器驱动应支持将寻址的收发器发送到其 Sleep 模式的 API
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 将使用此 API 请求到睡眠模式的转换。<br>并非所有收发器都支持这种状态。如果给定的设备支持此功能，驱动应确认状态转换成功。 |
| Rationale（原理） | 通过总线和内部唤醒实现 ECU 低功耗模式。 |
| Use Case（用例） | 上层服务层与其他节点商定将总线设置为睡眠模式。收发器已处于 StandBy，应切换到功耗最低的 Sleep。请注意，收发器的睡眠状态通常与 ECU 的"未通电"状态类似。 |
| Dependencies（依赖） | [SRS_Can_01098] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.5.3.4 [SRS_Can_01100] 总线收发器驱动应支持将寻址的收发器发送到其 Normal 模式的 API
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 所有收发器都支持此状态，因为它是"工作状态"。 |
| Rationale（原理） | 通信！ |
| Use Case（用例） | 必须启用所有通信才能进行通信。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.5.3.5 [SRS_Can_01101] 总线收发器驱动应支持 API 以读出 ECU 内指定总线的收发器的当前操作模式
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 收发器的当前操作模式将是上层（例如诊断）所必需的。API 应始终返回收发器驱动看到的当前状态（这也可以是本地存储的状态）。 |
| Rationale（原理） | 对收发器驱动的状态访问 |
| Use Case（用例） | 在开发期间和通过诊断命令检查当前操作模式。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.5.3.6 [SRS_Can_01103] 总线收发器驱动应支持 API 以读出 ECU 内指定总线的最后唤醒原因
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 收发器驱动应能存储本地视图"谁请求了唤醒：总线还是内部"。<br>- Bus：总线导致了唤醒。<br>- Internally：唤醒是由软件引起的<br>- Sleep：收发器处于运行模式睡眠，且未发生唤醒。<br>- Partial network wake-up：如果收发器硬件支持部分网络唤醒<br>- Wake pin：收发器唤醒引脚上的边沿（如果存在）引起了唤醒。<br>当操作模式不是 Normal 且未发生唤醒时，唤醒原因应为"sleep"。<br>当发生唤醒时，API 应始终返回首先检测到的唤醒原因（例如，如果通过总线发生唤醒，然后几乎同时发生内部唤醒，则唤醒原因为"bus"）。<br>离开 Normal 操作模式后，唤醒原因应再次设置为"sleep"。 |
| Rationale（原理） | 在开发期间和通过诊断命令检测唤醒原因。也可以由 NM 或 ECU 状态管理器使用。 |
| Use Case（用例） | -- |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
###### 6.2.5.3.7 [SRS_Can_01106] 总线收发器驱动应在检测到"通过总线唤醒"事件时调用 EcuM 的适当回调函数
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 总线收发器驱动通过下层通知或通过轮询下层获得"通过总线唤醒"事件。在这些情况下，总线收发器驱动将调用 EcuM 的适当 API 来传递事件。<br>应可能支持 ECU 内多于一个总线的此通知。<br>此需求仅适用于具有适当唤醒能力的收发器。 |
| Rationale（原理） | 总线收发器驱动和上层之间的有效耦合。 |
| Use Case（用例） | 总线收发器在总线上检测到唤醒条件，并通过例如端口引脚向 µC 显示这一点。<br>进一步处理取决于当前 ECU 状态。假设 ECU 已停止，端口上的变化可能会终止 HALT 语句并让处理器继续工作。分配的端口中断将被执行并调用此处理程序。现在，收发器驱动将存储唤醒原因并通过此通知将调用传递给例如 NM，以让 NM 决定如何处理该事件。<br>有关更多详细信息，请参见 ⌋(RS_BRF_01704) 以及 [SRS_Can_01095]。 |
| Dependencies（依赖） | 上层，即（特定总线的）NM 或 ECU 状态管理器之一。<br>[SRS_Can_01095], [SRS_Can_01138] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01064, RS_BRF_01680)
###### 6.2.5.3.8 [SRS_Can_01138] CAN 总线收发器驱动应为下层 ICU 驱动提供一个回调函数以处理"通过总线唤醒"事件
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | ICU 驱动应在"通过总线唤醒"事件的情况下调用此 API。此函数的一个参数应引用引起"通过总线唤醒"事件的 CAN 总线。<br>此 API 应可编译时配置，并且仅在相应的总线收发器具有唤醒能力时可用。<br>如果禁用"通过总线唤醒"的支持或对"通过总线唤醒"事件进行轮询，则应删除此函数。<br>此 API 应是同步或异步的，具体取决于收发器通信。 |
| Rationale（原理） | 下层和总线收发器驱动之间的有效耦合。 |
| Use Case（用例） | 通过下层通知"通过总线唤醒"事件。 |
| Dependencies（依赖） | [SRS_Can_01106] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01064, RS_BRF_01680)
###### 6.2.5.3.9 [SRS_Can_01156] 如果收发器硬件支持部分网络化，则总线收发器驱动应支持通过远程唤醒模式（RWUP）或远程唤醒帧（RWUF）唤醒事件
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 如果总线收发器硬件支持部分网络化，则总线收发器驱动应支持唤醒模式（RWUP）或远程唤醒帧（RWUF）的唤醒原因。 |
| Rationale（原理） | 部分网络化收发器的附加唤醒原因 |
| Use Case（用例） | 影响部分网络配置。 |
| Dependencies（依赖） | [SRS_Can_01106] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01104,RS_BRF_01680,RS_BRF_01664)
###### 6.2.5.3.10 [SRS_Can_01107] CAN 收发器驱动应支持在到 standby/sleep 的转换进行的同时发生"通过总线唤醒"的情况
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | "通过总线唤醒"始终与到睡眠的内部转换异步。在最坏的情况下，唤醒发生在到睡眠的转换期间。这种情况必须由软件设计覆盖并针对每个 ECU 显式测试。<br>驱动应在进入 standby/sleep 模式的 API 完成后立即产生"通过总线唤醒"通知。<br>调用/控制组件（NM 或 ECU 状态管理器）必须能够在请求 standby/sleep 后立即处理唤醒。 |
| Rationale（原理） | 安全的唤醒和睡眠处理。 |
| Use Case（用例） | 影响所有具有"通过总线唤醒"的总线。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01680,RS_BRF_01664)
###### 6.2.5.3.11 [SRS_Can_01115] 总线收发器驱动应支持 API 以分别启用和禁用每个总线的唤醒通知
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 为了使上层能够将总线收发器安全地命令进入其 standby 和/或 sleep 状态，需要一个额外的 API 来禁用和启用唤醒通知。<br>如果通知被禁用，驱动不应执行通知但应在内部存储事件，直到通知再次启用。通知应立即处理。<br>应可能清除挂起的唤醒事件。如果不再发生进一步的唤醒事件，则在再次启用通知后不应执行任何通知。如果发生进一步的唤醒事件，则应通知。 |
| Rationale（原理） | 安全的唤醒和睡眠处理。 |
| Use Case（用例） | 影响所有具有"通过总线唤醒"的总线。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01680,RS_BRF_01664)
##### 6.2.5.4 Shutdown Operation（关闭操作）
###### 6.2.5.4.1 [SRS_Can_01108] 总线收发器驱动应以允许安全系统启动和关闭的方式支持 AUTOSAR ECU 状态管理器
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 通常，对于启动，在电源可用且稳定之前，不应启用总线收发器以防止总线上出错。此外，在收发器配置为其正常操作模式之前，不应启用通信硬件和驱动。<br>对于关闭，必须根据 AUTOSAR NM 算法停止通信，必须停止 CAN/LIN 驱动，然后收发器也可以设置为 standby/sleep。正确的顺序取决于所使用的总线和 AUTOSAR 的唤醒睡眠概念。 |
| Rationale（原理） | 安全的系统启动和关闭 |
| Use Case（用例） | 支持"通过总线唤醒"的系统。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | 参见 2005-01-11/12 的 WP CAN/LIN 和 WP Mode Management 联合工作组会议结果。 |
⌋( RS_BRF_01704, RS_BRF_01096)
###### 6.2.5.4.2 [SRS_Can_01157] 总线收发器驱动应提供 API 以清除收发器硬件中的 WUF 位
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 此 API 是 CAN 通信通道关闭流程的一部分。该 API 清除收发器硬件中的 WUF 标志，以便能够发出后续的唤醒帧信号。对于支持部分网络化的 CAN 收发器，在收发器正常模式下也可以检测唤醒帧。这确保了在清除 WUF 标志后，ECU 转换到 standby 模式期间不会丢失唤醒帧。 |
| Rationale（原理） | 安全的系统启动和关闭 |
| Use Case（用例） | 支持部分网络化的系统。 |
| Dependencies（依赖） | |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01680,RS_BRF_01664)
##### 6.2.5.5 Fault Operation（故障操作）
###### 6.2.5.5.1 [SRS_Can_01109] 总线收发器驱动应检查到收发器的控制通信和收发器的反应的正确性
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 根据支持的收发器设备，驱动应检查所执行的控制通信的正确性以及收发器所处的操作模式。<br>应根据 [SRS_BSW_00337] 进行错误的分类。 |
| Rationale（原理） | 诊断和故障排除 |
| Use Case（用例） | 1) 检测有缺陷或行为异常的收发器硬件<br>2) 检测损坏的 SPI 通信<br>检查应仅应用于收发器或收发器控制通信（端口或 SPI）内的错误，即由 µC、SW 或有缺陷的收发器设备故障引起的错误。"外部世界"（例如总线线路干扰或地偏移）引起的"错误"不在此 API 的范围内。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01544)
### 6.3 Non functional requirements（非功能需求）
#### 6.3.1 CAN Driver
##### 6.3.1.1 [SRS_Can_01033] CAN 驱动应满足 AUTOSAR_SRS_SPAL 中规定的基础软件模块的一般需求
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 基于文档 AUTOSAR_SRS_SPAL 版本 2.0.0 中的需求 |
| Rationale（原理） | 重用对所有驱动有效的需求 |
| Use Case（用例） | CAN 驱动与其他驱动（SCI、SPI）位于同一层。因此，CAN 驱动也应满足一般的 SPAL 需求。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
##### 6.3.1.2 [SRS_Can_01034] CAN 驱动应提供独立于硬件的接口
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动和 CAN 接口之间的接口应独立于底层硬件。<br>CAN 驱动的实现是硬件相关的并且可静态配置。 |
| Rationale（原理） | 可移植性 |
| Use Case（用例） | 相同的 CAN 接口实现可用于不同的 µC。 |
| Dependencies（依赖） | [SRS_Can_01001] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704, RS_BRF_01552)
##### 6.3.1.3 [SRS_Can_01035] CAN 驱动应支持同一 CAN 硬件单元的多个 CAN 控制器
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 驱动应支持一个 CAN 硬件单元内的多个 CAN 控制器。<br>应可能在预编译时取消选择未使用的 CAN 控制器。 |
| Rationale（原理） | 硬件能力覆盖 |
| Use Case（用例） | 市场上存在在一个设备中包含多个 CAN 控制器的设备。 |
| Dependencies（依赖） | [SRS_Can_01053] |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01704)
#### 6.3.2 CAN Interface (Hardware Abstraction)
##### 6.3.2.1 [SRS_Can_01121] CAN 接口应是底层 CAN 驱动和 CAN 收发器驱动与上层之间的接口层
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 接口是所有上层用于 CAN 操作的单一接口。<br>CAN 接口是 CAN 驱动和 CAN 收发器驱动的唯一用户。 |
| Rationale（原理） | 接口和交互 |
| Use Case（用例） | 不同的上层（如 AUTOSAR_WP Architecture_SoftwareArchitecture 中所述）可以访问同一 CAN 硬件单元。一个 ECU 中也可能存在多个 CAN 硬件单元及其相应的驱动（内部和外部）。<br>CAN 接口的用户可以是 PDU Router、CAN 传输层、网络管理和 CAN State Manager。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | AUTOSAR_WP Architecture_SoftwareArchitecture |
⌋( RS_BRF_01000, RS_BRF_01008, RS_BRF_01016)
##### 6.3.2.2 [SRS_Can_01001] CAN 接口的实现和接口应独立于底层 CAN 控制器和 CAN 收发器
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 实现可能依赖于底层硬件的可用资源量（即 CAN 控制器数量、硬件对象句柄、是否允许 HW 取消），但硬件抽象层封装了不同的硬件访问机制。 |
| Rationale（原理） | 可移植性和可重用性。 |
| Use Case（用例） | 将特定 CAN 控制器的实现细节封装在更高的软件层之外。 |
| Dependencies（依赖） | [SRS_Can_01034] |
| Supporting Material（支持材料） | -- |
⌋(RS_BRF_01000,RS_BRF_01552)
#### 6.3.3 CAN State Manager
##### 6.3.3.1 [SRS_Can_01142] CAN State Manager 应向上层提供网络抽象 API
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN State Manager 到上层（ComM）的接口应是网络抽象的接口。<br>CAN State Manager 应处理分配给网络的外围设备的状态。它应执行以下操作以控制外围设备（CAN 控制器和 CAN 收发器）的状态：<br>• Init（初始化）<br>• Start（启动）<br>• Stop（停止）<br>• WakeUp（唤醒）<br>• Sleep（睡眠）<br>• BusOff Recovery（总线关闭恢复） |
| Rationale（原理） | Com Manager 和网络之间的抽象 |
| Use Case（用例） | 总线状态管理器控制每个网络的网络特定外围设备的状态。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01056)
##### 6.3.3.2 [SRS_Can_01014] CAN State Manager 应为上层提供独立于网络配置的接口
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN State Manager 到上层的接口应独立于网络配置。 |
| Rationale（原理） | 分层概念。信息隐藏。 |
| Use Case（用例） | 将硬件依赖封装在 CAN 驱动和接口内。访问 CAN State Manager 的模块不需要是硬件特定的。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01064)
#### 6.3.4 Transport Layer CAN
##### 6.3.4.1 [SRS_Can_01065] AUTOSAR CAN 传输层应基于 ISO 15765-2 和 15765-4 规范
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 如果没有明确添加或排除任何需求，AUTOSAR CAN 传输层的实现应遵循 ISO 15765-2 规范（用于 OEM 增强的诊断或应用通信）和 ISO 15765-4（用于车载诊断（OBD）通信）。 |
| Rationale（原理） | 重用现有标准作为 AUTOSAR BSW。ISO 15765-2 和 15765-4 规范是汽车领域最常用的 CAN 传输层。 |
| Use Case（用例） | CAN 上的传输协议符合 ISO 15765-2：<br>- 发送方向的数据分段<br>- 接收方向的数据收集<br>- 数据流控制<br>- 错误检测（消息丢失/重复/序列）<br>ISO 15765-4 规范中描述的网络层符合 ISO 15765-2，但有一些限制/添加。<br>请参阅相应版本的 AUTOSAR CAN 传输协议软件规范。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | ISO 15765-2 和 ISO 15765-4 规范 |
⌋( RS_BRF_01720)
##### 6.3.4.2 [SRS_Can_01111] CAN 传输层应是 PDU Router 和 CAN 接口之间需要传输协议功能的 CAN 消息的接口层
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 传输层由 PDU Router 用于发送和接收来自 Diagnostic Communication Manager 的 CAN 消息。<br>因为 PDU Router 通过 CAN 传输和 CAN 接口进行通信，它们的两个接口应是一致的（即，如果它们提供类似的原语，例如 Transmit，则这些原语的参数必须尽可能相似）。<br>为了处理发送，CAN 传输模块使用 CAN 接口的服务。 |
| Rationale（原理） | 接口和交互 |
| Use Case（用例） | 通过使用一致的 API（服务参数的同质性等），源代码的可读性和可维护性得到改善。 |
| Dependencies（依赖） | BSW01118-- |
| Supporting Material（支持材料） | AUTOSAR_WP Architecture_SoftwareArchitecture |
⌋(RS_BRF_01720)
##### 6.3.4.3 [SRS_Can_01112] CAN 传输层接口应独立于其内部通信配置
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 传输层应为 PDU Router 提供一个完全独立于其内部通信配置（N_TA 值、扩展或正常寻址模式、功能或物理寻址等）和实现的接口。<br>接口应仅处理 PDU 标识符和数据单元（N-SDU）属性。 |
| Rationale（原理） | 分层软件架构。信息隐藏。所有应用程序的公共接口 |
| Use Case（用例） | -- |
| Dependencies（依赖） | [SRS_Can_01014] |
| Supporting Material（支持材料） | -- |
⌋(RS_BRF_01720)
#### 6.3.5 CAN Bus Transceiver Driver
##### 6.3.5.1 Timing Requirements（时序需求）
###### 6.3.5.1.1 [SRS_Can_01110] CAN 总线收发器驱动应在内部处理收发器特定的时序需求
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | µC 和收发器之间的通信通过端口或 SPI 或两者执行。如果使用端口，则以预定义的顺序和给定的时序将值应用于端口，以进行通信并更改硬件操作模式。这些序列和时序必须在总线收发器驱动内处理。<br>像 TJA1054"进入睡眠命令的反应时间"的 50µs 这样的小时间可以在驱动内作为等待循环实现。<br>缺点是该时间对其他软件而言是浪费的，并且等待时间取决于所使用的 µC 和例如系统时钟。<br>较大的等待时间（例如 >200µs）可能需要总线收发器驱动的异步 API。缺点是对于这样的硬件设备，完整的 API 和使用将有所不同。 |
| Rationale（原理） | 正确处理使用的收发器 |
| Use Case（用例） | 例如，切换端口引脚执行 TJA1054 从 StandBy 到 Sleep 的转换。端口值必须保持至少 50µs 以保证收发器已在硬件中检测并处理了请求。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋(RS_BRF_01704)
#### 6.3.6 CAN Driver and Interface together
本章节描述了 CAN 驱动和 CAN 接口共同应满足的需求。
##### 6.3.6.1 [SRS_Can_01125] CAN 栈应确保在接收方向不丢失消息
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 栈应确保在总线负载为 100%（有效负载为 1 字节）的时间帧内读出 HW 接收缓冲区，以使消息不丢失。 |
| Rationale（原理） | 应能处理消息突发而不丢失数据。此需求故意使用 1 字节有效负载的 CAN 帧。它们比较长的帧产生更多的开销来处理。0 字节消息很少使用。<br>提示：这当然并不意味着禁止一般使用 0 字节消息。 |
| Use Case（用例） | 参见原理 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋(RS_BRF_01704)
##### 6.3.6.2 [SRS_Can_01126] CAN 栈应能产生 100% 总线负载
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | CAN 栈应能产生 100% 总线负载（除了不使用多路 HW 发送缓冲区导致的间隙）。此需求故意使用 1 字节有效负载的 CAN 帧。它们比较长的帧产生更多的开销来处理。0 字节消息很少使用。<br>提示：这当然并不意味着禁止一般使用 0 字节消息。 |
| Rationale（原理） | 服务于所用 CAN 总线的最大速度。 |
| Use Case（用例） | 参见原理 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |
⌋(RS_BRF_01704)
##### 6.3.6.3 [SRS_Can_01139] CAN 接口和驱动应提供 CAN 控制器特定的初始化接口
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 此服务应初始化 CAN 控制器特定的配置，例如关于波特率（SRS_Can_01038）的参数。<br>此服务通常用于例如 BusOff 之后的重新初始化，但不显式限制为该情况。<br>此函数调用应仅在 CAN 驱动的状态机处于 STOPPED 模式时无错误返回。应支持通过 API 传递参数来选择多个配置集中的一个。 |
| Rationale（原理） | 基本功能。 |
| Use Case（用例） | -- |
| Dependencies（依赖） | 参见描述 |
| Supporting Material（支持材料） | -- |
⌋( RS_BRF_01136,RS_BRF_01704)
## 7 References
### 7.1 Deliverables of AUTOSAR
[Can] Specification of CAN Driver
AUTOSAR_SWS_CANDriver.pdf
[CanIf] Specification of CAN Interface
AUTOSAR_SWS_CANInterface.pdf
[CanSM] Specification of CAN State Manager
AUTOSAR_SWS_CANStateManager.pdf
[CanTp] Specification of CAN Transport Layer
AUTOSAR_SWS_CANTransportLayer.pdf
[CanTrcv] Specification of CAN Transceiver Driver
AUTOSAR_SWS_CANTransceiverDriver.pdf
[SrsSpal] General Requirements on SPAL
AUTOSAR_SRS_SPALGeneral.pdf
[SrsGeneral] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[TPS_STDT_0078] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf
### 7.2 Related standard and norms
#### 7.2.1 ISO
ISO 15765-2(2004-10-12), Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part2: Network layer services
ISO 15765-3(2004-10-06), Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part3: Implementation of diagnostic services
ISO 15765-4(2005-01-04), Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part4: Requirements for emissions-related systems
### 7.3 Related Example Transceiver Data Sheets
参见例如 ST L9669、Freescale MC33389、Philips TJA1054（CAN LowSpeed）、TJA1041（CAN HighSpeed）的当前数据手册。
## 翻译说明
本文档为 AUTOSAR Classic Platform Release 4.4.0 中关于 CAN 模块的软件需求规范（SRS），对应英文文档 `AUTOSAR_SRS_CAN.pdf`。
翻译过程中遵循以下原则：
1. 保留了所有 API 标识符、模块缩写、协议名（如 CAN、BSW、PDU、CanTp、CanIf 等）
2. 保留了所有需求 ID（如 `SRS_Can_010xx`、`RS_BRF_xxxxx`）
3. 保留了 AUTOSAR 方框符 `⌈⌋`
4. 保留了所有 ISO 标准引用和文档间交叉引用
5. 表格内容、章节描述、需求说明均已翻译为中文
翻译时使用的需求格式参考了 AUTOSAR 标准的 [TPS_STDT_00078] 软件标准化模板，包括 Type、Description、Rationale、Use Case、Dependencies、Supporting Material 等字段。
Reference in New Issue View Git Blame Copy Permalink