feifei.xu/autosar_standard_spec_v4.4
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

P1 batch translation: 94 PDFs (Communication + Diagnostics + SystemServices + MCAL)

Browse Source
This commit is contained in:
opencode-translator
2026-06-13 00:29:54 +08:00
parent 0d470d1f17
commit 6f293acbf7
95 changed files with 70811 additions and 83 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Communication/AUTOSAR_SRS_SecureOnboardCommunication.md
+492
View File
@@ -0,0 +1,492 @@
# 安全车载通信需求规范
## 元信息
| 项目 | 内容 |
|------|------|
| 文档标题（中文） | 安全车载通信需求规范 |
| 文档标题（英文） | Requirements on Secure Onboard Communication |
| 文档所有者 | AUTOSAR |
| 文档责任方 | AUTOSAR |
| 文档标识号 | 653 |
| 文档状态 | Final（最终） |
| 所属 AUTOSAR 标准 | Classic Platform（经典平台） |
| 所属标准发布版本 | 4.4.0 |
| 对应原文 PDF | `AUTOSAR_SRS_SecureOnboardCommunication.pdf` |
| 翻译状态 | 已完成 |
| 翻译日期 | 2026-06-12 |
## 文档标识
| 字段 | 值 |
|------|----|
| Document Title（文档标题） | Requirements on Secure Onboard Communication |
| Document Owner（文档所有者） | AUTOSAR |
| Document Responsibility（文档责任方） | AUTOSAR |
| Document Identification No（文档标识号） | 653 |
| 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 | - 添加发送错误认证信息的需求<br>- 添加处理动态长度 PDU 的需求<br>- 次要更正/澄清/编辑性修改；有关详细信息，请参阅 Change Documentation |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | - 次要更正/澄清/编辑性修改；有关详细信息，请参阅 Change Documentation |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | - 次要更正/澄清/编辑性修改；有关详细信息，请参阅 ChangeDocumentation |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | - 次要更正/澄清/编辑性修改；有关详细信息，请参阅 ChangeDocumentation |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | - 初始发布 |
## 目录
1. [Scope of Document（文档范围）](#1-scope-of-document)
2. [Conventions to be used（使用的约定）](#2-conventions-to-be-used)
3. [Acronyms and abbreviations（缩略语和缩写）](#3-acronyms-and-abbreviations)
4. [Requirements Tracing（需求追踪）](#4-requirements-tracing)
5. [Template for Requirements Specific（需求规范模板）](#5-template-for-requirements-specific)
- 5.1 [Template for Requirements Specification（需求规范模板）](#51-template-for-requirements-specification)
- 5.2 [Functional Overview（功能概述）](#52-functional-overview)
6. [Requirement Specification（需求规范）](#6-requirement-specification)
- 6.1 [Functional Requirements（功能需求）](#61-functional-requirements)
- 6.1.1 [Configuration（配置）](#611-configuration)
- 6.1.2 [Initialisation（初始化）](#612-initialisation)
- 6.1.3 [Normal operations（正常运行）](#613-normal-operations)
- 6.1.4 [Support for end-to-end and point-to-point protection（支持端到端和点对点保护）](#614-support-for-end-to-end-and-point-to-point-protection)
- 6.1.5 [Shutdown Operation（关闭操作）](#615-shutdown-operation)
- 6.1.6 [Fault Operation（故障操作）](#616-fault-operation)
- 6.2 [Non-Functional Requirements (Qualities)（非功能需求（质量））](#62-non-functional-requirements-qualities)
- 6.2.1 [Timing Requirements（时序需求）](#621-timing-requirements)
7. [References（参考资料）](#7-references)
## 1 Scope of Document
本文档列出了适用于 AUTOSAR SecOC 模块设计的需求。
## 2 Conventions to be used
- AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中指定的表格。
- 在需求中，应使用以下特定语义（基于互联网工程任务组 IETF）。
本文档中关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应解释为：
- **SHALL**：此词表示该定义是规范的绝对要求。
- **SHALL NOT**：此短语表示该定义是规范的绝对禁止。
- **MUST**：此词表示由于法律问题，该定义是规范的绝对要求。
- **MUST NOT**：此短语表示由于法律约束，该定义是规范的绝对禁止。
- **SHOULD**：此词或形容词 "RECOMMENDED" 表示在特定情况下可能存在忽略某项的有效理由，但在选择不同方案之前必须充分理解并仔细权衡其影响。
- **SHOULD NOT**：此短语或短语 "NOT RECOMMENDED" 表示在特定情况下某特定行为可能是可接受甚至有用的，但在实现任何以此标签描述的行为之前，应充分理解其影响并仔细权衡该情况。
- **MAY**：此词或形容词 "OPTIONAL" 表示某项是真正可选的。
## 3 Acronyms and abbreviations
具有局部范围的缩略语和缩写不包含在 AUTOSAR 词汇表中。
| 缩写 | 描述 |
|------|------|
| MAC | Message Authentication Code（消息认证码） |
| SecOC | Secure Onboard Communication（安全车载通信） |
| 缩写 | 描述 |
|------|------|
| NVM | Non volatile memory（非易失性存储器） |
| Authentic I-PDU | 真正的 I-PDU 是通过 Secured I-PDU 在网络传输过程中完全保护的任意 AUTOSAR I-PDU。 |
| Secured I-PDU | 受保护的 I-PDU 是包含真实 I-PDU 的有效负载并补充了额外认证信息的 AUTOSAR I-PDU。 |
## 4 Requirements Tracing
| 需求 | 描述 | 由以下需求满足 |
|------|------|----------------|
| RS_BRF_01600 | AUTOSAR 通信应支持超时处理 | SRS_SecOC_00021 |
| RS_BRF_01704 | AUTOSAR 通信应支持 CAN 通信总线 | SRS_SecOC_00012 |
| RS_BRF_01712 | AUTOSAR 应支持 CAN FD 提供的高速适应性 | SRS_SecOC_00012 |
| RS_BRF_01720 | AUTOSAR 通信应支持 CAN 上的标准化诊断传输协议 | SRS_SecOC_00010 |
| RS_BRF_01728 | AUTOSAR 通信应支持 J1939 传输协议 | SRS_SecOC_00010 |
| RS_BRF_01736 | AUTOSAR 通信应支持按 J1939 网络管理要求动态分配地址 | SRS_SecOC_00010 |
| RS_BRF_01744 | AUTOSAR 通信应支持 TTCAN | SRS_SecOC_00010 |
| RS_BRF_01752 | AUTOSAR 通信应支持 FlexRay | SRS_SecOC_00012 |
| RS_BRF_01760 | AUTOSAR 通信应支持 FlexRay 上标准化的诊断传输协议 | SRS_SecOC_00012 |
| RS_BRF_01768 | AUTOSAR 通信应支持 LIN | SRS_SecOC_00012 |
| RS_BRF_01776 | AUTOSAR 通信应支持 Ethernet | SRS_SecOC_00012 |
| RS_BRF_01784 | AUTOSAR 通信应支持 IP 协议栈 | SRS_SecOC_00010 |
| RS_BRF_02035 | AUTOSAR 应支持消息数据认证 | SRS_SecOC_00001, SRS_SecOC_00002, SRS_SecOC_00003, SRS_SecOC_00005, SRS_SecOC_00006, SRS_SecOC_00007, SRS_SecOC_00010, SRS_SecOC_00013, SRS_SecOC_00017, SRS_SecOC_00020, SRS_SecOC_00021, SRS_SecOC_00022, SRS_SecOC_00025, SRS_SecOC_00026, SRS_SecOC_00028, SRS_SecOC_00030 |
| RS_BRF_02036 | AUTOSAR 应支持消息数据新鲜度验证 | SRS_SecOC_00001, SRS_SecOC_00002, SRS_SecOC_00003, SRS_SecOC_00005, SRS_SecOC_00006, SRS_SecOC_00007, SRS_SecOC_00013, SRS_SecOC_00017, SRS_SecOC_00020, SRS_SecOC_00021, SRS_SecOC_00022, SRS_SecOC_00025, SRS_SecOC_00026, SRS_SecOC_00028, SRS_SecOC_00029, SRS_SecOC_00030 |
| RS_BRF_02037 | AUTOSAR 应支持消息数据完整性验证 | SRS_SecOC_00001, SRS_SecOC_00002, SRS_SecOC_00003, SRS_SecOC_00005, SRS_SecOC_00006, SRS_SecOC_00007, SRS_SecOC_00013, SRS_SecOC_00017, SRS_SecOC_00020, SRS_SecOC_00021, SRS_SecOC_00022, SRS_SecOC_00025, SRS_SecOC_00026, SRS_SecOC_00028, SRS_SecOC_00030 |
| RS_BRF_02200 | AUTOSAR 诊断应提供对内部配置和标定数据的外部访问 | SRS_SecOC_00001, SRS_SecOC_00002, SRS_SecOC_00003, SRS_SecOC_00005, SRS_SecOC_00006 |
## 5 Template for Requirements Specific
### 5.1 Template for Requirements Specification
需求结构在 TPS_StdT_00077 中定义。
### 5.2 Functional Overview
安全车载通信（SecOC）模块的目的是提供一个 AUTOSAR BSW 模块，以在通过汽车嵌入式网络交换信息的两个或多个对等方之间传输受保护的数据。
**图 1：消息认证和新鲜度验证**
## 6 Requirement Specification
### 6.1 Functional Requirements
#### 6.1.1 Configuration
##### 6.1.1.1 [SRS_SecOC_00001] 选择真正的 I-PDU
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 应可配置哪些真正的 I-PDU 应受保护。 |
| Rationale（原理） | 有必要能够选择和配置需要受保护的真正 I-PDU。 |
| Use Case（用例） | SecOC 配置器选择引用应受保护的 I-PDU 的 PDU ID。他/她添加安全相关的配置数据以实现特定级别的安全性。 |
| Dependencies（依赖） | [SRS_SecOC_00003] |
| Supporting Material（支持材料） | |
⌋(RS_BRF_02035,RS_BRF_02036,RS_BRF_02037,RS_BRF_02200)
##### 6.1.1.2 [SRS_SecOC_00002] 接收方验证重试范围
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 使用自行更新的新鲜度信息的验证重试范围应可配置。 |
| Rationale（原理） | 当允许接收方对给定消息使用自行更新的新鲜度信息执行验证重试时，有必要能够配置可接受的重试次数以匹配 SecOC 模块所需的鲁棒性。 |
| Use Case（用例） | 安全专家和系统设计人员配置从安全角度可接受的验证重试次数。 |
| Dependencies（依赖） | [SRS_SecOC_00007] |
| Supporting Material（支持材料） | |
⌋(RS_BRF_02035,RS_BRF_02036,RS_BRF_02037,RS_BRF_02200)
##### 6.1.1.3 [SRS_SecOC_00003] 不同安全属性/需求的配置
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 不同的安全属性应可配置。 |
| Rationale（原理） | 评估可能在多个参数及其安全需求上有所不同。因此，保护级别应可配置，以通过一组适当的参数适应这些需求。 |
| Use Case（用例） | 安全专家定义不同的安全属性。对于每个具有安全保护需求的消息，可以选择适当的属性。 |
| Dependencies（依赖） | |
| Supporting Material（支持材料） | |
⌋(RS_BRF_02035,RS_BRF_02036,RS_BRF_02037,RS_BRF_02200)
#### 6.1.2 Initialisation
##### 6.1.2.1 [SRS_SecOC_00005] 安全信息初始化
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | SecOC 模块的安全配置应在模块启动时被初始化。 |
| Rationale（原理） | SecOC 模块需要安全配置信息（Key-ID、新鲜度值）来执行其操作。因此，此信息应在开始其处理操作之前被恢复和配置。 |
| Use Case（用例） | SecOC 加载 PDU 的 ID、授权的认证重试计数器以及用于处理其来自上层和下层传入通信的属性。 |
| Dependencies（依赖） | [SRS_SecOC_00001], [SRS_SecOC_00002], [SRS_SecOC_00003] |
| Supporting Material（支持材料） | |
⌋(RS_BRF_02035,RS_BRF_02036,RS_BRF_02037,RS_BRF_02200)
#### 6.1.3 Normal operations
##### [SRS_SecOC_00026] 分别传输数据和认证信息的能力
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | SecOC 应支持在单独的消息中传输真正的 I-PDU 及其认证信息。 |
| Rationale（原理） | 由于多种原因，可能无法通过附加额外数据来保护消息，需要单独发送。 |
| Use Case（用例） | • 要认证的数据在传输消息中占用的空间太大，无法添加可接受长度的认证器<br>• 现有消息需要为某些接收方保护，但不为其他接收方<br>• 现有消息需要保护，但并非所有接收方都可以更新以支持修改后的消息内容 |
| Dependencies（依赖） | - |
| Supporting Material（支持材料） | - |
⌋ (RS_BRF_02035,RS_BRF_02036,RS_BRF_02037)
##### [SRS_SecOC_00028] 验证时正确匹配数据和认证信息
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | SecOC 应确保在单独消息中传输时，使用正确的认证信息验证真正的 I-PDU。 |
| Rationale（原理） | 当真正的 I-PDU 及其认证信息在单独的消息中传输时，任何消息都可能在传输过程中丢失。在这种情况下，SecOC 可能匹配两个不对应的消息，并尝试使用不匹配的认证信息验证真正的 I-PDU。此验证必然失败，SecOC 可能会向上层发送验证错误。应用层可能将其归类为攻击，即使消息只是真正丢失。 |
| Use Case（用例） | 如果上层负责根据 SecOC 的信息检测安全攻击，则 SecOC 需要提供准确的信息。消息丢失应根据原因（例如硬件故障或拒绝服务）独立报告。 |
| Dependencies（依赖） | SRS_SecOC_00026 |
| Supporting Material（支持材料） | - |
⌋ (RS_BRF_02035,RS_BRF_02036,RS_BRF_02037)
##### 6.1.3.1 [SRS_SecOC_00006] 从真正的 I-PDU 创建受保护的 I-PDU
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 安全信息（MAC 和新鲜度计数器）应与真正的 I-PDU 一起传输，并产生一个受保护的 I-PDU，该 I-PDU 可根据协议能力在 L-PDU 或 N-PDU 中传输。 |
| Rationale（原理） | 为了使接收方验证消息来自可信发送方且未被故意修改，发送方的 SecOC 模块必须能够将其必须保护的信息与验证信息一起传输。<br>发送方和接收方的 SecOC 模块应能够处理消息及其附加安全信息（MAC 和新鲜度计数器），以在向其他软件层提供受保护的 PDU 之前执行验证过程。 |
| Use Case（用例） | 真正的 I-PDU 由 SecOC 配置开发人员配置为受保护。当它由 SecOC 模块处理时，将添加安全信息以创建受保护的 I-PDU。 |
| Dependencies（依赖） | [SRS_SecOC_00001] |
| Supporting Material（支持材料） | |
⌋(RS_BRF_02035,RS_BRF_02036,RS_BRF_02037,RS_BRF_02200)
##### 6.1.3.2 [SRS_SecOC_00007] 接收方验证重试
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 在接收方验证失败时，SecOC 模块应提供一种方法，使用自计算的新鲜度信息重试验证处理，直到在可配置范围内验证成功。 |
| Rationale（原理） | 发送方和接收方之间同步的丢失在验证尝试保持在可配置可接受范围内时不应导致验证失败。因此，有必要允许受保护消息的接收方使用自行更新的新鲜度信息重新尝试验证，直到达到配置的最大重新尝试次数。 |
| Use Case（用例） | 当接收到的受保护 I-PDU 的验证失败时，相同的数据可由接收方使用不同的自计算新鲜度信息重新处理。 |
| Dependencies（依赖） | [SRS_SecOC_00002] |
| Supporting Material（支持材料） | |
⌋(RS_BRF_02035,RS_BRF_02036,RS_BRF_02037)
##### 6.1.3.3 [SRS_SecOC_00010] AUTOSAR 的所有通信范例都提供通信安全
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 该概念应提供从一个源 ECU 到一个或多个 ECU 的安全通信机制。 |
| Rationale（原理） | 某些信号可能仅由一个 ECU 使用，而其他信号包含不同分配功能所需的值。 |
| Use Case（用例） | 1:1 示例：车身控制 ECU 应向驻车制动单元发送指示释放制动请求的消息；<br>1:n 示例：速度值由车辆中可能分配给不同 ECU 的不同功能所需，例如速度表、巡航控制或导航系统。<br>在两个示例中，宿 ECU 应能验证信号是由具有足够权限的源 ECU 发送的且未修改。数据验证应由每个 ECU 独立于其他可能的接收方执行。没有安全需求的接收方应能接收和使用信号数据而无需执行任何额外计算。 |
| Dependencies（依赖） | |
| Supporting Material（支持材料） | |
⌋(RS_BRF_02035,RS_BRF_01720,RS_BRF_01728,RS_BRF_01736,RS_BRF_01744,RS_BRF_01784)
##### 6.1.3.4 [SRS_SecOC_00029] 灵活的新鲜度构造
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 真正的 PDU 的新鲜度生成应由外部组件生成和维护。这可以由软件组件（SW-C）或复杂设备驱动（CD）完成。 |
| Rationale（原理） | OEM 有不同的方法来生成新鲜度。这不能在 AUTOSAR 规范中描述，也不能在 AUTOSAR 模块中实现和维护。为了提供更高的灵活性，新鲜度的构造应位于单独的软件模块中。 |
| Use Case（用例） | 为受保护 PDU 提供灵活的方式生成新鲜度。 |
| Dependencies（依赖） | [SRS_SECOC_00002], [SRS_SECOC_00003], [SRS_SECOC_00005], [SRS_SECOC_00005] |
| Supporting Material（支持材料） | |
⌋ (RS_BRF_02036)
##### 6.1.3.5 [SRS_SecOC_00012] 支持汽车总线系统
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | SecOC 模块应适用于 AUTOSAR 支持且对汽车环境典型的不同种类的总线系统。 |
| Rationale（原理） | Autosar 支持的所有总线协议都应受益于 SecOC 设计。 |
| Use Case（用例） | 应支持像 CAN 这样的低带宽总线以及像以太网这样的用于大数据链路的技术。 |
| Dependencies（依赖） | |
| Supporting Material（支持材料） | |
⌋(RS_BRF_01704,RS_BRF_01712,RS_BRF_01752,RS_BRF_01760,RS_BRF_01768,RS_BRF_01776)
##### 6.1.3.6 [SRS_SecOC_00030] 支持无需认证提取真正 I-PDU 的能力
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | SecOC 模块应能够从受保护 I-PDU 提取真正的 I-PDU，无需认证。 |
| Rationale（原理） | SecOC 可用作从受保护 I-PDU 提取真正 I-PDU 的提取器，以当下游通信集群的部分不需要 PDU 认证时启用低延迟 GW 行为。 |
| Use Case（用例） | 网关 |
| Dependencies（依赖） | [SRS_SecOC_00025] |
| Supporting Material（支持材料） | |
⌋ (RS_BRF_02035,RS_BRF_02036, RS_BRF_02037)
##### 6.1.3.7 [SRS_SecOC_00031] 支持下层模块的填充和动态长度的真正 I-PDU
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | SecOC 模块应适用于在下层模块使用填充和动态长度的真正 I-PDU 的用例。 |
| Rationale（原理） | 在接收方，接收到的包含动态长度真正 I-PDU 的受保护 I-PDU 也可能包含填充字节（由发送方的下层模块添加，以适应特定总线的 L-PDU 长度约束，例如 CAN FD 和 FlexRay）。在这种情况下，接收方无法识别所接收有效负载的字节数/字节位置。 |
| Use Case（用例） | CAN FD 和 FlexRay 上的动态长度 PDU |
| Dependencies（依赖） | [SRS_SecOC_00012] |
| Supporting Material（支持材料） | |
⌋ ([RS_BRF_01568] [RS_BRF_01649] [RS_BRF_01712] [RS_BRF_01716] [RS_BRF_01752] [RS_BRF_02035] [RS_BRF_02036] [RS_BRF_02037])
#### 6.1.4 Support for end-to-end and point-to-point protection
如果数据不是直接通过直接连接或总线系统传输，而是通过多个跳数或通过网关传输，则有两种保护模式，SecOC 模块都应支持：端到端和点对点保护。通信的端点由 ECU 定义，而不是由 SWC 定义。
- **点对点保护通信的定义**：在点对点方案中，通信在网络的每个单个对等方之间受到保护，因此在多次跳数的情况下，认证执行多次（即在传输路径的每个发送方上），验证执行多次（即在传输路径的每个接收方上）。
- **端到端保护通信的定义**：在端到端方案中，通信在发送方和接收方之间受到保护，无论中间跳数如何。认证在发送方执行一次，验证在接收方执行一次。
##### 6.1.4.1 [SRS_SecOC_00013] 支持端到端和点对点保护
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 支持端到端和点对点保护。 |
| Rationale（原理） | 虽然一些信号只是被转发，并且对通道或中间的中继实体没有进一步的要求，但其他信号可能通过中继实体，这些实体可以对数据包内容进行更改，因此需要受信于接收实体。 |
| Use Case（用例） | 一个 ECU 通信通过几个具有不同安全属性的逻辑网络传输的数据。重新认证网关将数据从一个逻辑网络桥接到另一个，并处理验证和重新认证。 |
| Dependencies（依赖） | |
| Supporting Material（支持材料） | |
⌋(RS_BRF_02035,RS_BRF_02036,RS_BRF_02037)
##### 6.1.4.2 [SRS_SecOC_00017] PDU 安全信息覆盖
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 应可能覆盖 PDU 的验证结果以强制验证失败，从而使 SecOC 模块拒绝消息。 |
| Rationale（原理） | 当检测到攻击或系统不可信时，验证结果应被覆盖为失败，以强制拒绝它们，无论接收到的安全信息如何，只要通信通道不安全。 |
| Use Case（用例） | 当接收方检测到攻击或假设其未正确同步时，只要它不信任通信通道，它可以决定拒绝消息。 |
| Dependencies（依赖） | |
| Supporting Material（支持材料） | |
⌋(RS_BRF_02035,RS_BRF_02036,RS_BRF_02037)
#### 6.1.5 Shutdown Operation
##### 6.1.5.1 [SRS_SecOC_00020] 安全操作信息持久性
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | SecOC 模块应在 NVM 中提供安全信息的受保护持久性机制，该机制在关闭操作完成之前用于其正常运行。 |
| Rationale（原理） | 像新鲜度计数器这样的安全信息可以在 SecOC 模块关闭时重用，以避免每次重启时 SecOC 模块的重新同步。 |
| Use Case（用例） | 模块重启后重用关闭前的安全信息。 |
| Dependencies（依赖） | |
| Supporting Material（支持材料） | |
⌋(RS_BRF_02035,RS_BRF_02036,RS_BRF_02037)
#### 6.1.6 Fault Operation
##### 6.1.6.1 [SRS_SecOC_00021] 发送 PDU 认证失败处理
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 在真正 I-PDU 的认证失败时，不应发送未受保护的 PDU，或者应使用默认认证信息发送。 |
| Rationale（原理） | 应由系统设计者负责决定与给定 PDU 的发送失败相关联的相同功能反应性是否应保持适用于其受保护时的发送失败。当构建认证器失败时，应可能决定不发送 PDU 或发送未受保护的 PDU。 |
| Use Case（用例） | 应可能决定认证失败是否导致通信错误。 |
| Dependencies（依赖） | |
| Supporting Material（支持材料） | |
⌋(RS_BRF_02035,RS_BRF_02036,RS_BRF_02037,RS_BRF_01600)
##### 6.1.6.2 [SRS_SecOC_00022] 接收 PDU 验证失败处理
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 在接收到的受保护 PDU 验证失败时，真正 PDU 不应传播到任何其他模块，并应提供通知。 |
| Rationale（原理） | 包含在导致验证失败的受保护 PDU 中的信号数据不应用于进一步处理，因为信号数据被视为已被篡改。 |
| Use Case（用例） | 当 SWC 被通知其应该接收的信息无法被信任时，它会触发某种失效安全模式。 |
| Dependencies（依赖） | |
| Supporting Material（支持材料） | |
⌋(RS_BRF_02035,RS_BRF_02036,RS_BRF_02037)
### 6.2 Non-Functional Requirements (Qualities)
#### 6.2.1 Timing Requirements
##### 6.2.1.1 [SRS_SecOC_00025] 认证和验证处理时间
⌈
| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 认证和验证处理应以及时的方式执行，使实时关键信号不受影响。 |
| Rationale（原理） | 两个或多个对等方的运行应用程序之间的时间关键信号的发送和接收不应因其底层通信软件层的额外处理而受到惩罚，最终导致信号被拒绝。<br>有必要的是，当通过受保护 I-PDU 发送和接收时间关键信号时，SecOC 模块所需的额外处理保持在一个可预测且与相关信号的时间约束兼容的值。 |
| Use Case（用例） | 合法的认证消息在预期时间范围内被验证并传递给接收 SWC，不会遇到信号监控错误。 |
| Dependencies（依赖） | [SRS_SecOC_00014] |
| Supporting Material（支持材料） | |
⌋(RS_BRF_02035,RS_BRF_02036,RS_BRF_02037)
## 7 References
### 7.1 Deliverables of AUTOSAR
[DOC_LayeredSoftwareArchitecture] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[DOC_COM_TYPES] Specification of Communication Stack Types
AUTOSAR_SWS_CommunicationStackTypes.pdf
[DOC_VFB] Specification of the Virtual Functional Bus
AUTOSAR_EXP_VFB.pdf
[DOC_ECUC] Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration.pdf
[DOC_SWS_COM] Specification of Communication
AUTOSAR_SWS_COM.pdf
[DOC_SWS_LDCOM] Specification of Large Data COM
AUTOSAR_SWS_LargeDataCOM.pdf
[DOC_TR_Glossary] Glossary
AUTOSAR_TR_Glossary.pdf
[DOC_RS_Features] Requirements on AUTOSAR Features
AUTOSAR_RS_Features.pdf
[DOC_SWS_CryptoServiceManager] Specification of Crypto Service Manager
AUTOSAR_SWS_CryptoServiceManager
[DOC_TPS_STDT] Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf
### 7.2 Related standards and norms
[DOC_IEC7498-1] The Basic Model, IEC Norm, 1994
[DOC_FIPS-180-4] National Institute of Standards and Technology (NIST): FIPS-180-4, Secure Hash Standard (SHS), March 2012
http://csrc.nist.gov/publications/fips/fips180-4
[DOC_FIPS-197] Advanced Encryption Standard (AES), U.S. Department of Commerce, Information Technology Laboratory (ITL), National Institute of Standards and Technology (NIST), Gaithersburg, MD, USA, Federal Information Processing Standards Publication, 2001
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
## 翻译说明
本文档为 AUTOSAR Classic Platform Release 4.4.0 中关于 Secure Onboard Communication（安全车载通信，SecOC）模块的软件需求规范（SRS），对应英文文档 `AUTOSAR_SRS_SecureOnboardCommunication.pdf`。
翻译过程中遵循以下原则：
1. 保留了所有 API 标识符、模块缩写、协议名（如 SecOC、MAC、NVM、I-PDU、AES、CAN FD、FlexRay、SWC、CD 等）
2. 保留了所有需求 ID（如 `SRS_SecOC_00xxx`）
3. 保留了 AUTOSAR 方框符 `⌈⌋`
4. 保留了所有 ISO/NIST 标准引用和文档间交叉引用
5. 表格内容、章节描述、需求说明均已翻译为中文