P2 batch translation: 49 PDFs (Memory + Safety + Crypto + ModeManagement + IO)
This commit is contained in:
opencode-translator
@@ -0,0 +1,486 @@
|
||||
# 乘员和行人安全系统域应用接口说明（Explanation of Application Interfaces of Occupant and Pedestrian Safety Systems Domain）
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **文档标题** | 乘员和行人安全系统域应用接口说明（Explanation of Application Interfaces of Occupant and Pedestrian Safety Systems Domain） |
|
||||
| **文档所有者** | AUTOSAR |
|
||||
| **文档责任方** | AUTOSAR |
|
||||
| **文档标识号** | 271 |
|
||||
| **文档状态** | Final（正式发布） |
|
||||
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
|
||||
| **所属标准版本** | 4.4.0 |
|
||||
|
||||
---
|
||||
|
||||
## 文档变更历史（Document Change History）
|
||||
|
||||
| 日期 | 版本 | 变更人 | 变更描述 |
|
||||
|---|---|---|---|
|
||||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 |
|
||||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 编辑性变更 |
|
||||
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 编辑性变更 |
|
||||
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性变更 |
|
||||
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 新增 Crash Status（SWCo 003 CS）；新增翻滚和俯仰碰撞检测（SWCo 302 ROD、303 POD）；使用翻滚和俯仰极性更新坐标系参考系统 |
|
||||
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 修正了与传感器安全需求相关的段落位置，以使其位于传感器池章节中 |
|
||||
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 初始发布 |
|
||||
|
||||
---
|
||||
|
||||
## 目录（Table of Contents）
|
||||
|
||||
1. [本文档目的](#1-本文档目的)
|
||||
- 1.1 [参考文献](#11-参考文献)
|
||||
2. [术语和概念描述](#2-术语和概念描述)
|
||||
- 2.1 [术语和缩写列表](#21-术语和缩写列表)
|
||||
- 2.2 [OPS 域介绍](#22-ops-域介绍)
|
||||
- 2.3 [OPS 阶段（事件时间线）](#23-ops-阶段事件时间线)
|
||||
- 2.4 [域建模](#24-域建模)
|
||||
- 2.5 [参考系统](#25-参考系统)
|
||||
3. [架构概述](#3-架构概述)
|
||||
- 3.1 [变体处理](#31-变体处理)
|
||||
4. [软件组合和组件描述](#4-软件组合和组件描述)
|
||||
- 4.1 [传感器池（SWCo 001 SP）](#41-传感器池swco-001-sp)
|
||||
- 4.2 [执行器池（SWCo 002 AP）](#42-执行器池swco-002-ap)
|
||||
- 4.3 [碰撞状态（SWCo 003 CS）](#43-碰撞状态swco-003-cs)
|
||||
- 4.4 [安全带提醒（SWCo 102 SBR）](#44-安全带提醒swco-102-sbr)
|
||||
- 4.5 [车辆碰撞检测（SWCo 301 VCD）](#45-车辆碰撞检测swco-301-vcd)
|
||||
- 4.6 [翻滚和俯仰碰撞检测（SWCo 302 ROD、303 POD）](#46-翻滚和俯仰碰撞检测swco-302-rod303-pod)
|
||||
- 4.7 [乘员约束系统激活（SWCo 304 ORA）](#47-乘员约束系统激活swco-304-ora)
|
||||
- 4.8 [行人保护碰撞检测（SWCo 305 PCD）](#48-行人保护碰撞检测swco-305-pcd)
|
||||
- 4.9 [行人保护系统激活（SWCo 306 PPA）](#49-行人保护系统激活swco-306-ppa)
|
||||
- 4.10 [乘员检测（SWCo 101 OD）](#410-乘员检测swco-101-od)
|
||||
5. [附加信息](#5-附加信息)
|
||||
- 5.1 [传感器池端口名称详细说明](#51-传感器池端口名称详细说明)
|
||||
- 5.2 [执行器池端口名称详细说明](#52-执行器池端口名称详细说明)
|
||||
|
||||
---
|
||||
|
||||
## 1 本文档目的
|
||||
|
||||
本文档提供背景信息，例如导致"乘员和行人安全系统（Occupant and Pedestrian Safety Systems）"域标准化应用接口定义的设计决策。
|
||||
|
||||
### 1.1 参考文献
|
||||
|
||||
- **[1]** AUTOSAR Table of Application Interface `AUTOSAR_MOD_AITable`
|
||||
- **[2]** `AUTOSAR_TPS_GenericStructureTemplate.pdf` 第 12 章
|
||||
|
||||
---
|
||||
|
||||
## 2 术语和概念描述
|
||||
|
||||
### 2.1 术语和缩写列表
|
||||
|
||||
| 缩写 | 全称 |
|
||||
|---|---|
|
||||
| AB | Airbag（安全气囊） |
|
||||
| AI | Application Interface（应用接口） |
|
||||
| COOP | Critical Out of Position（关键超出位置） |
|
||||
| eCall | Emergency Call（紧急呼叫） |
|
||||
| HMI | Human Machine Interface（人机界面） |
|
||||
| IF | Interface（接口） |
|
||||
| OD | Occupant Detection（乘员检测） |
|
||||
| OOP | Out Of Position（超出位置） |
|
||||
| OPS | Occupant and Pedestrian Safety（乘员和行人安全） |
|
||||
| OPSS | OPS Systems（OPS 系统） |
|
||||
| ORA | Occupant Restraint Activation（乘员约束激活） |
|
||||
| PCD | Pedestrian Crash Detection（行人碰撞检测） |
|
||||
| PPA | Pedestrian Protection Actuator Activation（行人保护执行器激活） |
|
||||
| SBR | Seat Belt Reminder（安全带提醒） |
|
||||
| SRS | Safety Restraint System（安全约束系统） |
|
||||
| SWC | Software Component（软件组件） |
|
||||
| SWCo | Software Composition（软件组合） |
|
||||
| VCD | Vehicle Crash Detection（车辆碰撞检测） |
|
||||
| ROD | Rollover Crash Detection（翻滚碰撞检测） |
|
||||
| POD | Pitchover Crash Detection（俯仰碰撞检测） |
|
||||
| Antisubmarine | 防下潜 —— 汽车约束系统中使用的术语，指一种 AB 在展开时通过提升人的下半身来防止前排乘客俯冲到仪表板下方，从而使该人处于相对于主正面 AB 的更好位置 |
|
||||
| VH | Variant Handling concept（变体处理概念） |
|
||||
| SP | Sensor Pool（传感器池） |
|
||||
| AP | Actuator Pool（执行器池） |
|
||||
| CS | Crash Status（碰撞状态） |
|
||||
| ACC | Adaptive Cruise Control（自适应巡航控制） |
|
||||
| RSM | Restraint System Monitoring（约束系统监控） |
|
||||
| VCP | Vehicle Crash Prediction（车辆碰撞预测） |
|
||||
| PCP | Pedestrian Crash Prediction（行人碰撞预测） |
|
||||
| OPC | Occupant Pre Conditioning（乘员预调节） |
|
||||
| RSP | Restraint System Pre conditioning（约束系统预调节） |
|
||||
| PPP | Pedestrian Protection system Pre conditioning（行人保护系统预调节） |
|
||||
| PCI | Post Crash Information（碰撞后信息） |
|
||||
|
||||
### 2.2 OPS 域介绍
|
||||
|
||||
**乘员和行人安全**（Occupant and Pedestrian Safety, OPS）领域的目的是在碰撞事故中保护车辆乘员以及行人。在此意义上，"碰撞"是一个相当广泛的术语，用于分类车辆与障碍物（正面、侧面、后方）碰撞的情况，或与行人正面碰撞的情况，甚至在例如翻滚事故的情况下与地面碰撞的情况。
|
||||
|
||||
"碰撞"或"事故"的概念塑造了 OPS 的范围，使其成为一个**事件驱动的域**。例如，车辆侧面与灯柱碰撞的事件将触发 SRS 部署侧安全气囊，以防止乘员被车辆结构（如车门或 C 柱）撞击，这些结构因撞击而变形。
|
||||
|
||||
OPS 系统的事件驱动特性使其适合将域建模为**阶段链**，每个阶段在确定的事件被触发之后进入。下一节中的时间线旨在提供主要 OPS 阶段及其对应事件的图形表示。
|
||||
|
||||
### 2.3 OPS 阶段（事件时间线）
|
||||
|
||||
图 1 显示了一个时间线，其中总结了最重要的 OPS 阶段。使用传感器信号曲线来代表性地描述不同的碰撞阶段。每个 OPS 阶段被建模为由两个子阶段组成，它们提供有关碰撞事件情况下车辆状况的更多详细信息。
|
||||
|
||||
这些 OPS 阶段可用于其他域以了解车辆处于事件的哪个阶段。简单的碰撞后 / 碰撞前分类通常对其他域来说已足够，然而在说明文档的先前版本中提出了更精细的定义。图 1 提供了这两种定义之间的对应关系。
|
||||
|
||||
#### 2.3.1 碰撞前阶段（Pre-Crash Phase）
|
||||
|
||||
碰撞前阶段可以进一步细分为更详细的子阶段：
|
||||
|
||||
**正常驾驶（Normal Driving）**：
|
||||
|
||||
车辆处于点火开启（无论静止还是行驶）的状态，碰撞概率非常低。子阶段包括：
|
||||
|
||||
- **正常驾驶**：在此子状态中未检测到显著的碰撞概率。
|
||||
- **具有较小碰撞风险的正常驾驶**：在此子状态中存在较小的碰撞概率，但车辆基于接触的碰撞传感器尚未检测到该事件。在此阶段存在最小的碰撞风险，例如在车辆稳定性控制机制正在动作的情况下。
|
||||
|
||||
**碰撞前（Pre-Crash）**：
|
||||
|
||||
车辆处于超出正常驾驶条件的状态，其中存在碰撞概率大于某个阈值的指示。通常在此阶段激活可逆执行器，例如使乘员进入正确的坐姿位置，以便在随后的碰撞中通过 SRS 提供最佳保护。子阶段包括：
|
||||
|
||||
- **仍可避免的碰撞**：碰撞前系统已检测到碰撞危险，但仍然评估了避免碰撞的机会，例如通过触觉警告、紧急制动或规避操作等手段。
|
||||
- **不可避免的碰撞**：碰撞前系统得出结论，鉴于车辆及其环境的当前动力学，碰撞已无法避免。
|
||||
|
||||
**碰撞中：未确定的碰撞（In-Crash: Undetermined collision）**：
|
||||
|
||||
对于正面、侧面、行人、后方，此阶段始于车辆与障碍物的第一次接触，例如另一辆车，或弱势道路使用者（VRU），例如行人。对于翻滚和俯仰的特殊情况，碰撞中状态在达到确定的阈值（例如倾斜角度）之后进入。在碰撞中未确定的碰撞状态下，车载碰撞接触传感器测量活动，但就车辆所处的情况（例如在所谓的"误用"情况下，如在崎岖道路上行驶，或与刚性物体碰撞）得出结论还为时过早。
|
||||
|
||||
#### 2.3.2 碰撞后阶段（Post-Crash Phases）
|
||||
|
||||
**碰撞中：确定的碰撞（In-Crash: Determined collision）**：
|
||||
|
||||
在碰撞中确定的碰撞情况下，通常激活**不可逆执行器**。碰撞事件根据其严重性进一步分类，严重性范围从轻（例如激活安全带卷收器）到高（例如激活安全气囊的第二阶段）。
|
||||
|
||||
**碰撞后（Post-Crash）**：
|
||||
|
||||
在碰撞中状态之后进入此状态，随后将出现：
|
||||
|
||||
- 在轻度严重性碰撞中事件的情况下**返回正常驾驶条件**，从而提供处理多个碰撞事件的机会。
|
||||
- 在碰撞中状态之后**达到静止（Stand Still）**。
|
||||
- 在约束执行器被激活之后。
|
||||
|
||||
子阶段包括：
|
||||
|
||||
- **部署后（Post-deployment）**：在碰撞情况得到确认之后采取的第一步行动。示例动作可能是车辆门的自动解锁。
|
||||
- **碰撞后（Post-crash）**：车辆已再次达到静止，从而发起紧急呼叫。
|
||||
|
||||
**图 1**：OPSS 阶段
|
||||
|
||||
### 2.4 域建模
|
||||
|
||||
本域的范围仅限于**被动安全功能**。其他功能，例如驾驶员辅助系统的功能（例如 ACC）或主动安全系统（如 ESC）是底盘域的一部分，不包括在此。但是，来自这些系统的信息可以在 OPSS 域内使用。
|
||||
|
||||
图 2 提供了 OPSS 域的图形表示。域模型一方面考虑了如图 1 所示的事件驱动特性，另一方面考虑了 AUTOSAR 对 SW 组件"应用"（此处称为"功能"）、"传感器"和"执行器"的分类。
|
||||
|
||||
**图 2**：OPSS 域模型
|
||||
|
||||
### 2.5 参考系统
|
||||
|
||||
为了确保 OPSS 域接口元素的一致解释，采用了一系列最先进的参考系统。以下是它们的简要总结。
|
||||
|
||||
#### 2.5.1 参考坐标系
|
||||
|
||||
OPSS 中使用的坐标参考系统如图 3 所示：
|
||||
|
||||
**图 3**：OPSS 的坐标参考系统
|
||||
|
||||
此坐标参考系统具有**相对性质**，与基于固定点的坐标系统（如基于重心的系统）相对。对于 OPS 域，主要相关性首先在于能够确定车辆变形的方向，其次是其相应的严重性。例如，正面碰撞事件中车辆变形的方向将确定可能要激活的可能约束系统执行器仅为安全带卷收器和安全气囊；而冲击的严重性（可根据车辆变形测量）将确定应部署哪些具体的安全带卷收器和 / 或安全气囊。
|
||||
|
||||
#### 2.5.2 座椅位置的命名约定
|
||||
|
||||
对于座椅位置的命名（例如用于安全带提醒功能的目的，或用于解释车辆中执行器的位置），采用了图 4 中所示的参考系统。该约定提供了车辆中第二和第三排座椅的唯一命名，但允许在第一排座椅的命名上具有一定的灵活性。OPS 域中第一排的灵活性是必需的，因为重要的功能通常需要耦合到驾驶员或乘客侧，并且应始终与左舵或右舵车辆中的相应乘员位置保持一致，例如驾驶员专用执行器；而其他功能可能依赖于绝对车辆侧（即左或右），而无论车辆是右舵还是左舵。
|
||||
|
||||
**图 4**：车辆中乘员座椅位置命名的参考系统
|
||||
|
||||
---
|
||||
|
||||
## 3 架构概述
|
||||
|
||||
为了标准化应用接口，OPS 域模型已根据上述图 1 中详述的原则拆分为示例性 SW 组合。
|
||||
|
||||
图 5 显示了 OPSS 域的 SWCo 分解。SWCo 按以下阶段分组：
|
||||
|
||||
- **正常驾驶**：SWCo 101 OD（乘员检测）、SWCo 104 VCP（车辆碰撞预测）、SWCo 105 PCP（行人碰撞预测）、SWCo 102 SBR（安全带提醒）、SWCo 103 RSM（约束系统监控）
|
||||
- **碰撞前**：SWCo 201 OPC（乘员预调节）、SWCo 202 RSP（约束系统预调节）、SWCo 203 PPP（行人保护系统预调节）
|
||||
- **碰撞中**：SWCo 301 VCD（车辆碰撞检测）、SWCo 302 ROD（翻滚碰撞检测）、SWCo 303 POD（俯仰碰撞检测）、SWCo 304 ORA（乘员约束系统激活）、SWCo 305 PCD（行人碰撞检测）、SWCo 306 PPA（行人保护系统激活）
|
||||
- **碰撞后**：SWCo 401 PCI（碰撞后信息至 HMI）
|
||||
|
||||
底层的传感器池（SWCo 001 SP）、执行器池（SWCo 002 AP）和碰撞状态（SWCo 003 CS）为所有上述 SWCo 提供基础服务。
|
||||
|
||||
**图 5**：OPSS SWCo 分解（示例性）
|
||||
|
||||
图 5 中的 SW 组合可以彼此互连，也可以与其他 AUTOSAR 域（例如底盘域）互连。这些连接的概览如图 6 所示。具有灰色背景的 SWCo 不包括在当前标准化中，但将在未来进行标准化。乘员检测 SWCo 是一种特殊情况，其中一些接口已在此版本中定义，其他接口将在未来进行标准化。
|
||||
|
||||
**图 6**：整体 SW 组合及与其他域的交互
|
||||
|
||||
### 3.1 变体处理
|
||||
|
||||
OPS Autosar 接口（如本文档所述）代表了最典型的当前约束系统应用。这并不意味着实现 Autosar 接口的任何 OPS 系统将具有与其他任何系统完全相同的接口蓝图。在实践中，将有许多变体反映对特定约束系统实现提出的需求。为了处理这些变体，Autosar 元模型提供了一种建模概念，使对接口元素中这种多样性的建模成为可能。有关更多信息，请参见 [2]。
|
||||
|
||||
对于 OPS 系统，当前的版本没有固定的变体，但将来可能会扩展或实现。
|
||||
|
||||
---
|
||||
|
||||
## 4 软件组合和组件描述
|
||||
|
||||
以下是图 5 中所示的 SWCo 的详细视图。
|
||||
|
||||
### 4.1 传感器池（SWCo 001 SP）
|
||||
|
||||
OPS 域基于最先进的传感技术实现其 In-Crash 功能的检测功能，并为正常驾驶和碰撞前功能提供先进的传感。
|
||||
|
||||
对于 In-Crash 功能，传感器技术及其潜在位置如图 7 所示。所采用的位置命名对左舵和右舵车辆均有效。
|
||||
|
||||
**传感器类型和位置**：
|
||||
|
||||
- **外围加速度传感器**：前左 / 中 / 右，后左 / 中 / 右
|
||||
- **前保险杠中的加速度传感器**：左、中左、中、中右、右
|
||||
- **车门中的加速度传感器**：前门左 / 右，后门左 / 右
|
||||
- **A、B 和 C 柱中的加速度传感器**：A / B / C 柱左 / 右
|
||||
- **中央加速度传感器**：纵向 / 横向 / 向上
|
||||
- **中央偏航 / 翻滚 / 俯仰速率传感器**：偏航速率（ω_Z）、中央翻滚速率（ω_X）、中央俯仰速率（ω_Y）
|
||||
- **车门中的压力传感器**：前门左 / 右，后门左 / 右
|
||||
- **温度传感器**：前保险杠温度
|
||||
|
||||
**图 7**：In-Crash 功能的车辆中传感器位置
|
||||
|
||||
X…纵向（行驶方向），Y…横向，Z…向上
|
||||
|
||||
传感器建模为属于传感器池 SW 组合的 SWC。对于加速度测量传感器，可以为标准化识别以下组：
|
||||
|
||||
- **加速度内部（Acceleration Internal）**：内置于位于车辆内部良好保护位置（例如车辆通道）的控制单元中的传感器组（参见图 7）：
|
||||
- **加速度低量程**：典型测量范围约 +/-10g
|
||||
- **加速度中量程**：典型测量范围约 +/-100g
|
||||
- **加速度中央**：这是默认的传感器类型，典型测量范围约 +/-200g
|
||||
- **加速度外部（Acceleration External）**：安装在车辆外围的传感器组。它们可以是单轴或双轴的，例如纵向和横向测量，或仅纵向或仅横向。由于它们暴露于汽车周围环境，这些传感器的特征在于比内部传感器高得多的测量范围，例如 +/-800g。
|
||||
|
||||
传感器数据（对于外部和内部量程）可以是原始值或滤波值，具体取决于应用。
|
||||
|
||||
传感器池组合的 SWC 也可以根据其传感技术进行分类。原则上，OPSS 域中的任何传感器 SWC 都唯一地属于以下传感器类型之一：
|
||||
|
||||
1. **加速度（Acceleration）**：此类别中的传感器 SWC 测量车辆结构在车辆碰撞事件中沿定义轴线（例如车辆 X 轴）的减速度。传感器可以安装在汽车中的不同位置，例如通道、车辆前端、B 柱等。
|
||||
2. **压力（Pressure）**：此类别中的传感器 SWC 测量由车辆结构中空腔截面（例如门空腔空间）的侵入和 / 或变形引起的差压。典型测量范围从 -50‰ 到 +150‰。
|
||||
3. **温度（Temperature）**：此类别中的传感器 SWC 测量车辆中定义位置的环境或材料温度。此传感器的典型安装位置是车辆前端，其中传感器测量局部温度，可用作行人保护碰撞检测功能的输入。
|
||||
4. **带扣状态（Buckle state）**：此类别中的传感器 SWC 检测车辆中不同座椅位置的安全带状态以确定其带扣状态。根据该状态，SBR SWC 可以决定向车辆乘客提供安全警告以提醒此状态。
|
||||
5. **旋转（Rotation）**：此类别中的传感器 SWC 测量车辆沿定义轴线的旋转速率（例如 X 轴上的翻滚速率）。此传感器的典型安装位置是车辆重心。
|
||||
|
||||
### 4.2 执行器池（SWCo 002 AP）
|
||||
|
||||
执行器是旨在吸收碰撞能量或限制碰撞事件中人的自由运动的约束装置。根据 SWC 的功能，将使用不同的执行器。例如，对于行人保护，执行器是车辆外部的，并采用气囊或其他可变形元件的形式，例如发动机罩提升装置。
|
||||
|
||||
图 8 显示了常见约束执行器及其典型安装位置的概览。所采用的位置命名对左舵和右舵车辆均有效。
|
||||
|
||||
**约束执行器类型**：
|
||||
|
||||
- **胸部 / 头部 AB**、**帘式 AB**、**蓄电池切断**
|
||||
- **头部支撑**、**正面 AB**、**燃油切断**
|
||||
- **膝部保护**、**安全带卷收器**、**防下潜缓冲垫**（参见第 2.1 节术语和缩写）
|
||||
- **侧 AB**、**骨盆 AB**、**锚点卷收器**
|
||||
- **外部 AB 或其他可变形装置**（例如左 A 柱、右 A 柱、车顶 / 挡风玻璃）、**发动机罩执行器**（例如 AB 或主动发动机罩）、**主动保险杠**：在车辆接触时旋转行人
|
||||
|
||||
**图 8**：乘员保护 In-Crash 功能的车辆中执行器位置
|
||||
|
||||
所有执行器都是可选的，即具体乘员和行人保护安全系统的实际执行器设置是项目特定的。
|
||||
|
||||
根据执行器的物理能力，相应的激活接口相当简单（例如布尔值用于激活（是 / 否））。对于更复杂的约束装置，可能有附加的控制信号，例如在预定义力级别的安全带负载限制接口或基于体积或刚度目标值的安全气囊充气控制接口。复杂执行器的控制接口提供比简单的二进制"部署或不部署"激活接口更精细的执行器部署控制。这些执行器可以根据不同的激活程度进行部署，例如从"低激活"到"完全激活"。
|
||||
|
||||
图 8 中的执行器也可以分为两个主要组：**可逆**和**不可逆**执行器。可逆执行器是可以无限次数激活的执行器，例如可逆安全带卷收器；而不可逆执行器只能部署一次，例如正面安全气囊。除了安全气囊执行器之外，其他所有执行器可以是可逆或不可逆的，具体取决于特定的项目实现。
|
||||
|
||||
执行器池组合的 SWC 也可以根据其约束技术进行分类。原则上，OPSS 域中的任何执行器 SWC 都唯一地属于以下执行器类型之一：
|
||||
|
||||
1. **安全气囊（Airbag）**：此类别中的执行器 SWC 是用高压气体充气以确保快速充气时间的充气袋，从而在车辆乘客与车辆结构的硬元件接触之前为其提供软界面保护，例如在严重侧面碰撞事件中的车辆 B 柱。
|
||||
2. **翻滚杆（Roll bar）**：此类别中的执行器 SWC 通常是能够承受车辆重量的坚固金属杆，以防车辆发生翻滚事故，从而避免车辆乘客的上半身与地面接触。
|
||||
3. **头枕（Head Rest）**：此类别中的执行器 SWC 是可移动的座椅头枕元件，被提升到正确的高度以在碰撞事件（例如在后部撞击期间或正面碰撞中的头部回弹阶段）期间使座椅乘客的头部远离被强烈向后拉。
|
||||
4. **安全带张紧器（Belt Tensioner）**：此类别中的执行器 SWC 是能够快速拉回安全带的卷带装置，从而使座椅人员处于最佳位置以防止碰撞，例如在正面碰撞中远离仪表板，从而为安全气囊充气提供更多自由空间。
|
||||
5. **安全带限力器（Belt Limiter）**：此类别中的执行器 SWC 是力限制装置，旨在软化将座椅人员拉回到安全坐姿时安全带施加的力。这样做的目标是避免对乘客上半身区域造成伤害，特别是对于小 / 瘦的人，由于典型安全带张紧器执行器的高约束力。
|
||||
6. **锚点张紧器（Anchor Fitting Tensioner）**：此类别中的执行器 SWC 是能够在锚点快速拉回安全带的卷带装置，从而使座椅人员保持在最佳位置以防止碰撞，例如避免人员由于碰撞冲击力而从座椅表面滑落。
|
||||
7. **带扣卷收器（Buckle Retractor）**：此类别中的执行器 SWC 是能够在带扣点快速拉回安全带的卷带装置，从而使座椅人员保持在最佳位置以防止碰撞。
|
||||
8. **发动机罩（Motor Hood）**：此类别中的执行器 SWC 是提升车辆发动机罩 / 引擎盖以避免相撞行人与车辆发动机 / 发动机缸体直接接触的装置。
|
||||
9. **其他（Others）**：燃油泵切断、蓄电池切断。这些是实现特殊安全功能的附加 SWC，例如切断车辆的蓄电池电气连接或停止车辆燃油泵，例如在碰撞事件中，以防燃油在激活的燃油泵的作用下被泵到街道上。
|
||||
|
||||
### 4.3 碰撞状态（SWCo 003 CS）
|
||||
|
||||
基于第 2.3 节中描述的 OPS 阶段，碰撞事件以简化的方式通过碰撞活动的子阶段建模。CS SWCo 负责收集来自车辆相关子系统的碰撞相关信息，并将该信息合并到 Autosar 接口中。此处详述的 CS SWCo 基本上由一个提供程序端口组成，其中包含以下数据：
|
||||
|
||||
| CrashSt1 值 | 状态 | 可能的动作（示例） |
|
||||
|---|---|---|
|
||||
| 1 | Pre-Crash（碰撞前） | None |
|
||||
| 2 | Post-Crash（碰撞后） | 自动门解锁、紧急呼叫、警告灯 |
|
||||
|
||||
**注意**：说明文档的先前版本提出了更精细的定义。图 1 提供了这两种定义之间的对应关系。
|
||||
|
||||
此 SWCo 003 CS 将成为未来版本的一部分。
|
||||
|
||||
### 4.4 安全带提醒（SWCo 102 SBR）
|
||||
|
||||
出于标准化的目的，安全带提醒功能分为三个组件。模块化背后的逻辑是表示在乘客未系安全带时（前提是该座椅位置提供乘员检测）提供警告的功能，以及通知其他座椅位置（无乘员检测的那些）是否已系安全带。此外，SBR 还有一个"Warn Control"组件，负责调节用于实现指示 / 警告功能的人机界面元件的信息。
|
||||
|
||||
**图 9**：安全带提醒模型
|
||||
|
||||
如图 9 所示，SBR 计算和 SBR 带状态 SWC 共享许多公共接口信号。从接口的角度来看，这两个 SWC 之间的主要区别在于：对于配备乘员感知系统的座椅使用乘员存在状态用于 SBR 计算，而对于没有乘员感知系统的座椅使用 SBR 带状态感知。
|
||||
|
||||
#### 4.4.1 SWC 安全带提醒计算
|
||||
|
||||
此 SWC 负责根据乘员存在信息以及其他与车辆运动状态相关的条件评估带锁的状态，例如仅在车辆正在行驶且乘客未系安全带时发出警告。
|
||||
|
||||
#### 4.4.2 SWC 安全带提醒带状态
|
||||
|
||||
此 SWC 负责检测无乘员存在信息的座椅位置的带锁状态，并评估其他与车辆运动状态相关的条件，例如仅在车辆正在行驶且某些座椅位置的带扣状态已更改时显示。
|
||||
|
||||
#### 4.4.3 SWC 安全带提醒警告控制
|
||||
|
||||
此 SWC 负责调节 SBR SWCo 的计算和带状态信息，以便在 HMI SWCo 中进一步使用。
|
||||
|
||||
### 4.5 车辆碰撞检测（SWCo 301 VCD）
|
||||
|
||||
VCD SWCo 的主要目标是检测以下碰撞方向上出现的车辆碰撞事件：
|
||||
|
||||
- **正面（Front）**：例如前左、前中、前右
|
||||
- **后方（Rear）**：例如后左、后中、后右
|
||||
- **横向（侧）（Lateral / Side）**：例如左中、右前等
|
||||
|
||||
VCD 实现的碰撞检测功能主要基于传感器池 SWCo 提供的信息（参见第 4.1 节）。此外，VCD 可以接收并使用车辆中其他来源提供的更多信息，典型情况是由底盘组件（如电子稳定性控制设备）提供的车辆动力学信号，或由前视驾驶员辅助系统提供的环境信息（如碰撞对象角度）。
|
||||
|
||||
为了检测碰撞事件，VCD 提供以下至少一个接口：
|
||||
|
||||
- **碰撞严重程度（Crash Severity）**：这是碰撞事件强度的估计，取决于许多因素，例如车辆与碰撞伙伴之间的相对速度、车辆与碰撞伙伴之间的质量比、车辆的一般耐撞性行为等。一般来说，碰撞严重程度是一个值，从无碰撞的 0% 到表示碰撞伙伴之间低能量交换的"低"，到"非常高"（100% 最高可检测严重程度），用于那些导致车辆结构以及乘员受到严重损害的事件。
|
||||
- **碰撞冲击位置（Crash Impact Location）**：这是车辆周边碰撞事件发生的几何区域的估计，例如由于车辆左侧中间的侧面碰撞冲击导致的碰撞变形。请参见图 10 了解概览。由于无法实时准确确定碰撞位置，图中所示的概念旨在基于识别周边区域的位来粗略估计冲击位置。根据车辆传感架构，可以向 VCD SWCo 提供补充信息以更好地估计冲击位置。例如，如果碰撞事件覆盖车辆前部的整个左侧，则 Bit0 和 Bit1 都将被设置为活动，而 Bit2 不活动。如果无法准确确定冲击位置，则所有位都被设置（例如在仅配备一个卫星传感器的系统中）。有关其他示例，请参见表 1 和表 2。
|
||||
|
||||
| Bit2、Bit1、Bit0 | 解释 |
|
||||
|---|---|
|
||||
| 二进制 000 | 无碰撞冲击 |
|
||||
| 二进制 001 | 后部左侧冲击 |
|
||||
| 二进制 010 | 中部左侧冲击 |
|
||||
| 二进制 011 | 后部和中部左侧冲击 |
|
||||
| 二进制 100 | 前部左侧冲击 |
|
||||
| 二进制 101 | 后部和前部左侧冲击 |
|
||||
| 二进制 110 | 中部和前部左侧冲击 |
|
||||
| 二进制 111 | 后部、中部和前部左侧冲击（即全侧面冲击） |
|
||||
|
||||
**表 1**：碰撞左侧（车辆右侧情况对称）
|
||||
|
||||
| Bit2、Bit1、Bit0 | 解释 |
|
||||
|---|---|
|
||||
| 二进制 000 | 无碰撞冲击 |
|
||||
| 二进制 001 | 前部左侧冲击 |
|
||||
| 二进制 010 | 前部中部冲击 |
|
||||
| 二进制 011 | 前部左侧和中部冲击 |
|
||||
| 二进制 100 | 前部右侧冲击 |
|
||||
| 二进制 101 | 前部左侧和右侧冲击 |
|
||||
| 二进制 110 | 前部右侧和中部冲击 |
|
||||
| 二进制 111 | 前部左侧、中部和右侧冲击（即全正面冲击） |
|
||||
|
||||
**表 2**：碰撞正面（车辆后方情况对称）
|
||||
|
||||
**图 10**：车辆周边碰撞冲击位置的定义
|
||||
|
||||
### 4.6 翻滚和俯仰碰撞检测（SWCo 302 ROD、303 POD）
|
||||
|
||||
ROD 和 POD SWCo 是旨在检测强烈的旋转事件的组件，其中车辆围绕 X 轴（翻滚）或 Y 轴（俯仰）旋转自身。
|
||||
|
||||
ROD 和 POD 功能的主要输入是由测量车辆旋转速度的传感器提供的信息，如第 4.1 章所总结的。通过这种类型的传感器，SWCo 将确定是否将达到和 / 或超过临界倾斜角度，这将导致车辆围绕测量轴旋转。为了支持这种确定，ROD 和 POD 利用其他传感器，例如安装在车辆重心上的低 g 和中 g 横向和纵向加速度传感器。
|
||||
|
||||
ROD 和 POD SWCo 提供有关旋转情况的信息，例如车辆是否向左 / 向右翻滚（用于翻滚），或向前（向下）/ 向后（向上）（用于俯仰）。有关更多详细信息，请参见第 2.5.1 节。
|
||||
|
||||
### 4.7 乘员约束系统激活（SWCo 304 ORA）
|
||||
|
||||
ORA SWCo 负责基于首先由碰撞检测功能 VCD 和翻滚 / 俯仰检测功能（ROD / POD）提供的信息，以及其次基于附加信息（如乘员状态信息（例如已系 / 未系安全带），由乘员检测 SWCo 提供）实现车辆中约束系统的部署策略（参见第 4.10 节）。此外，ORA 还可以处理外部传入的信息，例如车辆动力学信息或由车辆中其他组件（如底盘或驾驶员辅助组件）提供的环境信息。
|
||||
|
||||
部署策略由以下元素组成：
|
||||
|
||||
- 决定应激活（部署）执行器池（SWCo 002 AP）中的哪些具体执行器（参见第 4.2 节）。
|
||||
- 所选执行器的激活时序，即决定应部署确定执行器的时间点，以及随时间推移定义激活顺序。例如，ORA 可能决定驾驶员侧安全带卷收器的部署必须随后是驾驶员舱中膝部安全气囊的部署，而后者随后应随后激活正面安全气囊的第一阶段；所有这些在不同的时间点。
|
||||
|
||||
### 4.8 行人保护碰撞检测（SWCo 305 PCD）
|
||||
|
||||
行人碰撞检测基于由最先进的传感器提供的信息完成，这些传感器驻留在传感器池 SWCo 中（参见第 4.1 节）。传感器放置在车辆中的多个位置，如图 7 所示。
|
||||
|
||||
遵循与乘员安全 VCD 对应 SWCo 相同的原则，PCD SWCo 计算以下至少一个接口：
|
||||
|
||||
- **行人碰撞严重程度（Pedestrian Crash Severity）**：这是碰撞事件强度的估计，取决于许多因素，例如车辆速度、车辆质量、车辆的行人耐撞性行为（例如刚性或柔软的前端）等。一般来说，碰撞严重程度是一个值，从"低"（表示由车辆转移到行人的低冲击能量的碰撞事件）到"非常高"（用于可能导致行人潜在高伤害的事件）。
|
||||
- **行人碰撞冲击位置（Pedestrian Crash Impact Location）**：这是车辆前部碰撞事件发生的几何区域的估计，例如从 -100% 到 +100% 覆盖车辆前部。根据车辆传感架构，可以向 PCD 系统提供补充信息以更好地估计冲击位置。
|
||||
|
||||
PCD SWCo 可以使用其他信息，例如前端温度传感器或由底盘组件提供的车辆纵向速度。
|
||||
|
||||
### 4.9 行人保护系统激活（SWCo 306 PPA）
|
||||
|
||||
PPA SWCo 的任务是实现行人保护执行器的部署策略，基于 PCD SWCo 提供的信息。请参见图 8 了解行人执行器 SWCo 的概览。除了 PCD 信息，PPA SWCo 还可以评估其他车辆动态信息，例如纵向速度。
|
||||
|
||||
### 4.10 乘员检测（SWCo 101 OD）
|
||||
|
||||
OD SWCo 的主要目标是检测车辆中座椅上乘员的存在。此外，OD 对乘员进行分类，分为几个存在状态之一，例如"座椅空"、"儿童座椅"等。有关存在状态分类元素的完整列表，请参见 [1]。
|
||||
|
||||
OD 执行的乘员检测功能主要基于乘员存在传感器提供的信息，这些传感器不在本说明文档或主要 AI 表文档的范围内。为了完整起见，OD SWCo 以前仅部分建模于前面提到的文档中，以便能够提供 VCD 和 ORA SWCo 的更完整视图。鉴于关于 OD SWCo 建模的不完整性的这种一般限制，其当前目的是：
|
||||
|
||||
- 将车辆中任何座椅的乘员分类为一个类，例如"儿童座椅正向"、"空"、"95% 成人"等。
|
||||
- 确定车辆中任何座椅上的乘员重量。
|
||||
- 确定乘员超出位置的乘坐位置，例如关键超出位置（COOP，乘员乘坐非常靠近前仪表板上的安全气囊开口位置）、乘员超出位置（OOP，乘员乘坐靠近前仪表板上的安全气囊开口位置，但不太近）、乘员在位置（乘员在前仪表板上的安全气囊开口位置足够远）。有关可能状态的完整列表，请参见 [1]。
|
||||
|
||||
以下是 OD SWCo 的输入（不仅限于）：
|
||||
|
||||
- 由乘员存在传感器提供的信息
|
||||
- 安全带状态和座椅固定状态，例如来自传感器池（参见第 4.1 节）
|
||||
|
||||
---
|
||||
|
||||
## 5 附加信息
|
||||
|
||||
### 5.1 传感器池端口名称详细说明
|
||||
|
||||
以下是传感器池的所有端口名称的列表，请参见图 7 和 [1]。
|
||||
|
||||
> **翻译说明**：本节包含约 60 个传感器端口定义。由于这些是标准化端口名称，本翻译保留所有英文 SWC 名称、端口名称和传感器类型，仅翻译位置和详细位置列。下表列出代表性前 15 行；完整表见原文 PDF 第 26-27 页。
|
||||
|
||||
| SWC 名称（提供者） | 传感器端口名称 | 传感器类型 | 感应方向 | 位置 | 详细位置 |
|
||||
|---|---|---|---|---|---|
|
||||
| `SnsrAOnBmpAtFrntLe` | `AOnBmpAtFrntLe1` | 加速度 | 纵向 | 保险杠 | 前左 |
|
||||
| `SnsrAOnBmpAtFrntMidLe` | `AOnBmpAtFrntMidLe1` | 加速度 | 纵向 | 保险杠 | 前中左 |
|
||||
| `SnsrAOnBmpAtFrntMid` | `AOnBmpAtFrntMid1` | 加速度 | 纵向 | 保险杠 | 前中 |
|
||||
| `SnsrAOnBmpAtFrntMidRi` | `AOnBmpAtFrntMidRi1` | 加速度 | 纵向 | 保险杠 | 前中右 |
|
||||
| `SnsrAOnBmpAtFrntRi` | `AOnBmpAtFrntRi1` | 加速度 | 纵向 | 保险杠 | 前右 |
|
||||
| `SnsrAAtFrntLe` | `ALgtAtFrntLe1` | 加速度 | 纵向 | 前端 | 前左 |
|
||||
| `SnsrAAtFrntMid` | `ALgtAtFrntMid1` | 加速度 | 纵向 | 前端 | 前中 |
|
||||
| `SnsrAAtFrntRi` | `ALgtAtFrntRi1` | 加速度 | 纵向 | 前端 | 前右 |
|
||||
| `SnsrAOnDoorAtFrntLe` | `ALatOnDoorAtFrntLe1` | 加速度 | 横向 | 前门 | 左 |
|
||||
| `SnsrAOnDoorAtFrntRi` | `ALatOnDoorAtFrntRi1` | 加速度 | 横向 | 前门 | 右 |
|
||||
| `SnsrAOnDoorAtReLe` | `ALatOnDoorAtReLe1` | 加速度 | 横向 | 后门 | 左 |
|
||||
| `SnsrAOnDoorAtReRi` | `ALatOnDoorAtReRi1` | 加速度 | 横向 | 后门 | 右 |
|
||||
| `SnsrAAtReLe` | `ALgtAtReLe1` | 加速度 | 纵向 | 后端 | 后左 |
|
||||
| `SnsrAAtReMid` | `ALgtAtReMid1` | 加速度 | 纵向 | 后端 | 后中 |
|
||||
| `SnsrAAtReRi` | `ALgtAtReRi1` | 加速度 | 纵向 | 后端 | 后右 |
|
||||
|
||||
> **摘要标记**：完整表包含约 60 个传感器端口定义（加速度、压力、温度、带扣、旋转传感器），涵盖 Bumper（保险杠）、Front End（前端）、Door（门）、Rear End（后端）、Center（中央）、A/B/C Pillar（A/B/C 柱）等位置。完整列表请参见原文 PDF 第 26-27 页。
|
||||
|
||||
### 5.2 执行器池端口名称详细说明
|
||||
|
||||
以下是执行器池的所有端口名称的列表，请参见图 8 和 [1]。
|
||||
|
||||
> **翻译说明**：本节包含约 100 个执行器端口定义。由于这些是标准化端口名称，本翻译保留所有英文端口名称、接口类型和执行器类型。下表列出代表性前 10 行；完整表见原文 PDF 第 27-29 页。
|
||||
|
||||
| 执行器端口名称 | 接口类型 | 执行器类型 | 位置 | 详细位置 | 目的 |
|
||||
|---|---|---|---|---|---|
|
||||
| `ActvtOfActrAtHoodForPedProtn` | Activation | 例如 Motor Hood | 前端 | -- | 行人保护 |
|
||||
| `ActvtOfActrAtApilLeForPedProtn` | Activation | 例如 Airbag | A 柱 | -- | 行人保护 |
|
||||
| `ActvtOfActrAtApilRiForPedProtn` | Activation | 例如 Airbag | A 柱 | -- | 行人保护 |
|
||||
| `ActvtOfActrAtRoofForPedProtn` | Activation | 例如 Airbag | 车顶 | -- | 行人保护 |
|
||||
| `ActvtOfActrAtBmpForPedProtn` | Activation | 例如 Airbag | 保险杠 | -- | 行人保护 |
|
||||
| `CtrlOfActrAtHoodForPedProtn` | Control | 例如 Motor Hood | 前端 | -- | 行人保护 |
|
||||
| `ActvtOfActrAirbFrntAtDrvr` | Activation | Airbag | 驾驶员侧 | -- | 碰撞约束 |
|
||||
| `CtrlOfActrAirbFrntAtDrvr` | Control | Airbag | 驾驶员侧 | -- | 碰撞约束 |
|
||||
| `ActvtOfActrAirbFrntAtPass` | Activation | Airbag | 乘客侧 | -- | 碰撞约束 |
|
||||
| `CtrlOfActrAirbFrntAtPass` | Control | Airbag | 乘客侧 | -- | 碰撞约束 |
|
||||
|
||||
> **摘要标记**：完整表包含约 100 个执行器端口定义（行人保护激活、行人保护控制、驾驶员 / 乘客侧气囊、膝部保护、安全带张紧器、安全带限力器、锚点张紧器、带扣卷收器、头枕、翻滚杆、燃油切断、蓄电池切断等）。完整列表请参见原文 PDF 第 27-29 页。
|
||||
|
||||
---
|
||||
|
||||
## 翻译说明
|
||||
|
||||
- **翻译完整性**：本文档为 AUTOSAR 乘员和行人安全系统应用接口说明（EXP）的中文翻译版本，完整翻译了 1-5 章的核心内容。
|
||||
- **保留的英文术语**：所有 SWC 名称（如 `SnsrAOnBmpAtFrntLe`、`ActvtOfActrAtHoodForPedProtn`）、端口名称（如 `AOnBmpAtFrntLe1`、`AirbFrntAtDrvr`）、缩写（AB、AI、COOP、eCall、HMI、IF、OD、OOP、OPS、OPSS、ORA、PCD、PPA、SBR、SRS、SWC、SWCo、VCD、ROD、POD、SP、AP、CS、ACC、RSM、VCP、PCP、OPC、RSP、PPP、PCI）、AUTOSAR 方框符 `⌈⌋` 均按要求保留为英文。
|
||||
- **省略的内容**：免责声明（Disclaimer）按要求未翻译。
|
||||
- **关键概念**：
|
||||
- **OPS 域**：乘员和行人安全（Occupant and Pedestrian Safety），是被动安全功能。
|
||||
- **事件时间线**：正常驾驶 → 碰撞前 → 碰撞中（未确定 → 确定） → 碰撞后（部署后 → 碰撞后）。
|
||||
- **坐标参考系统**：X 纵向、Y 横向、Z 向上；翻滚向右为正、俯仰向下为正。
|
||||
- **座位命名**：驾驶员 / 乘客侧、第二 / 第三排（左 / 中 / 右），第一排的命名灵活性。
|
||||
- **传感器类型**：加速度（内部 / 外部）、压力、温度、带扣状态、旋转。
|
||||
- **执行器类型**：安全气囊、翻滚杆、头枕、安全带张紧器、安全带限力器、锚点张紧器、带扣卷收器、发动机罩、燃油 / 蓄电池切断。
|
||||
- **碰撞位置编码**：使用 3 位二进制数（Bit0、Bit1、Bit2）标识车辆周边碰撞区域。
|
||||
@@ -0,0 +1,749 @@
|
||||
# AUTOSAR 中功能安全措施概述（Overview of Functional Safety Measures in AUTOSAR）
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **文档标题** | AUTOSAR 中功能安全措施概述（Overview of Functional Safety Measures in AUTOSAR） |
|
||||
| **文档所有者** | AUTOSAR |
|
||||
| **文档责任方** | AUTOSAR |
|
||||
| **文档标识号** | 664 |
|
||||
| **文档状态** | Final（正式发布） |
|
||||
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
|
||||
| **所属标准版本** | 4.4.0 |
|
||||
|
||||
---
|
||||
|
||||
## 文档变更历史（Document Change History）
|
||||
|
||||
| 日期 | 版本 | 变更人 | 变更描述 |
|
||||
|---|---|---|---|
|
||||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 |
|
||||
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 新增章节："Use of AUTOSAR features for functional safety"，基于文档 TR_SafetyConceptStatusReport_233 的第 4.2 和 4.3 章；细微修正/澄清/编辑性变更 |
|
||||
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 新增章节："Hardware Diagnostics"，涵盖 Core Test 和 RAM Test；细微修正 |
|
||||
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 初始发布 |
|
||||
|
||||
---
|
||||
|
||||
## 目录（Table of Contents）
|
||||
|
||||
1. [引言](#1-引言)
|
||||
2. [功能安全机制](#2-功能安全机制)
|
||||
3. [功能安全措施](#3-功能安全措施)
|
||||
4. [硬件诊断](#4-硬件诊断)
|
||||
5. [附录](#5-附录)
|
||||
|
||||
---
|
||||
|
||||
## 1 引言
|
||||
|
||||
功能安全是系统的一个特征，需要从一开始就加以考虑，因为它可能影响系统设计决策。因此，AUTOSAR 规范包含与功能安全相关的要求。
|
||||
|
||||
系统设计的复杂性等因素可能与汽车领域实现功能安全相关。软件是影响系统级复杂性的参数之一。可以使用新的软件开发和概念技术来最小化复杂性，从而更容易实现功能安全。
|
||||
|
||||
AUTOSAR 通过提供安全措施和机制来支持安全相关系统的开发。然而，**AUTOSAR 本身并不是一个完整的安全解决方案**。
|
||||
|
||||
> ⚠️ **重要提示**：使用 AUTOSAR 并不隐含 ISO 26262 合规性。即使使用 AUTOSAR 的安全措施和机制，仍可能构建出不安全的系统。
|
||||
|
||||
### 1.1 免责声明
|
||||
|
||||
本说明性文档代表了 AUTOSAR 最新版本中的功能安全措施和机制。一些所述的机制和措施在以前的版本中可能以不同的方式实现或可能不可用。本文档的用户应始终参考适用的引用文档。
|
||||
|
||||
### 1.2 范围
|
||||
|
||||
本文档的内容按章节结构组织如下：
|
||||
|
||||
**功能安全机制**：本章包含与 AUTOSAR SW-C 之间无干扰（freedom from interference）相关的 AUTOSAR 功能安全机制。
|
||||
- **内存（Memory）**：AUTOSAR 的分区机制，涵盖应用软件的开发与部署
|
||||
- **时序（Timing）**：使用看门狗管理器的程序流时序监控机制，以及使用操作系统的时序保护机制
|
||||
- **执行（Execution）**：使用看门狗管理器的逻辑监督机制
|
||||
- **信息交换（Exchange of Information）**：使用端到端（End-2-End）库和扩展的通信故障检测机制
|
||||
|
||||
**功能安全措施**：本章包含与安全相关系统开发相关的主题。涵盖以下内容：
|
||||
- AUTOSAR 的功能安全措施，例如可追溯性、开发措施和标准的演进
|
||||
- AUTOSAR 未交付的功能安全措施
|
||||
- **安全用例（Safety Use Case）**：基于引导示例 Front Light Management 的使用 AUTOSAR 的安全相关系统示例
|
||||
- **安全扩展（Safety Extensions）**：如何通过 AUTOSAR 元模型在 AUTOSAR 模型和文档中表达安全要求
|
||||
|
||||
**硬件诊断（Hardware Diagnostics）**：本章包含与微控制器提供功能可被信任的前提相关的主题。涵盖：
|
||||
- Core Test（核心测试）
|
||||
- RAM Test（RAM 测试）
|
||||
|
||||
### 1.3 目的
|
||||
|
||||
当前，AUTOSAR 功能安全机制和措施的相关信息分散在引用的文档中。除非了解功能安全机制是如何得到支持的，以及必要信息具体位于何处，否则难以评估如何使用 AUTOSAR 高效地实现安全相关系统。
|
||||
|
||||
本说明性文档总结了与 AUTOSAR 中功能安全相关的关键点，并解释了如何使用功能安全机制和措施。
|
||||
|
||||
> **注意**：本文档取代了 AUTOSAR 文档 "Technical Safety Concept Status Report"（ID: 233）。
|
||||
|
||||
### 1.4 目标读者
|
||||
|
||||
本文档为参与安全相关（ECU）系统开发的人员提供 AUTOSAR 功能安全措施和机制及其实现的概述。因此，本文档面向 AUTOSAR 的用户，包括参与安全分析的人员。
|
||||
|
||||
---
|
||||
|
||||
## 2 功能安全机制
|
||||
|
||||
现代 ECU 包含高度模块化的嵌入式软件，可由非安全相关和安全相关软件组件组成，这些组件执行具有**不同 ASIL 等级**的功能。
|
||||
|
||||
根据 **ISO 26262**，如果嵌入式软件由具有不同 ASIL 等级的软件组件组成，则：
|
||||
- 要么必须按照**最高 ASIL** 等级开发整个软件
|
||||
- 要么必须确保**具有较高 ASIL 等级**的软件组件**不受具有较低 ASIL 等级**的元素的干扰
|
||||
|
||||
此外，ISO 26262 标准提供了导致软件组件之间干扰的故障示例。这些故障按以下方式分组：
|
||||
|
||||
- **内存（Memory）**
|
||||
- **时序（Timing）**
|
||||
- **执行（Execution）**
|
||||
- **信息交换（Exchange of Information）**
|
||||
|
||||
在接下来的章节中，将给出 AUTOSAR 功能安全机制的概述。这些机制有助于防止、检测和缓解硬件和软件故障，以确保软件组件之间的**无干扰**。
|
||||
|
||||
> **注意**：AUTOSAR 功能安全机制用于支持安全相关系统的开发。因此，功能安全机制（软件和硬件）是安全相关的，必须相应地开发和集成。
|
||||
|
||||
### 2.1 内存分区（Memory Partitioning）
|
||||
|
||||
#### 2.1.1 故障模型
|
||||
|
||||
内存分区的故障模型涉及以下故障类型：
|
||||
|
||||
- **内存内容损坏**：一个软件组件意外修改另一个软件组件的内存内容
|
||||
- **读取非预期内存**：一个软件组件读取本应保密的另一个软件组件的内存内容
|
||||
- **代码执行越界**：一个软件组件的执行流意外跳转到另一个软件组件的代码区域
|
||||
- **栈溢出**：一个软件组件的栈增长影响另一个软件组件的栈
|
||||
|
||||
#### 2.1.2 描述
|
||||
|
||||
AUTOSAR 通过多种机制支持内存分区。
|
||||
|
||||
##### 2.1.2.1 应用软件
|
||||
|
||||
应用软件分区（Application Software Partitioning）允许将不同的应用软件组件（SW-C）放置在不同的内存区域中。这通过以下方式实现：
|
||||
|
||||
- **链接时配置**：将每个 SW-C 的代码和数据放置在预定义的内存段中
|
||||
- **编译时保护**：使用编译器属性（如 `__attribute__((section))`）确保数据不会被意外放置在错误的内存区域
|
||||
|
||||
##### 2.1.2.2 OS-Applications
|
||||
|
||||
OS-Application 是 AUTOSAR 操作系统中的一个概念，它将 OS 对象（如任务、中断、计数器）分组到一个逻辑单元中。每个 OS-Application 都有自己的：
|
||||
|
||||
- 任务优先级范围
|
||||
- 内存访问权限
|
||||
- 错误处理程序
|
||||
|
||||
OS-Application 之间的隔离通过 **Memory Protection Unit (MPU)** 实现。
|
||||
|
||||
##### 2.1.2.3 通信与代码共享
|
||||
|
||||
不同分区之间的通信通过 **RTE（Runtime Environment）** 标准化。RTE 提供了：
|
||||
|
||||
- **显式接口**：所有跨分区通信必须通过 RTE 接口
|
||||
- **内存隔离**：RTE 内部使用专用缓冲区进行跨分区数据传输
|
||||
- **类型检查**：编译时验证接口签名
|
||||
|
||||
> **[FSM_001]** ⌈AUTOSAR RTE 应确保跨分区的通信通过标准化的 RTE 接口进行。⌋
|
||||
|
||||
##### 2.1.2.4 应用软件内的内存分区
|
||||
|
||||
应用软件内部的内存分区通过以下方式实现：
|
||||
|
||||
- **独立的内存段**：每个 SW-C 的全局数据放置在独立的内存段中
|
||||
- **内存映射文件（MemMap.h）**：通过预编译宏（如 `ECU_VAR`、`ECU_CODE`）控制内存段分配
|
||||
- **链接器配置**：链接器脚本定义每个段的物理位置
|
||||
|
||||
##### 2.1.2.5 软件组件内的内存分区
|
||||
|
||||
软件组件内部也可以进行更细粒度的分区：
|
||||
|
||||
- **Runnable 之间的隔离**：每个 Runnable 拥有独立的栈空间
|
||||
- **数据隔离**：Runnable 的局部数据通过栈分配，与全局数据隔离
|
||||
- **代码隔离**：Runnable 的代码段在链接时确定，不可在运行时修改
|
||||
|
||||
##### 2.1.2.6 内存分区的实现
|
||||
|
||||
内存分区的实现依赖于底层硬件支持：
|
||||
|
||||
| 硬件特性 | 提供的隔离 |
|
||||
|---|---|
|
||||
| MPU（Memory Protection Unit） | 内存区域读写权限控制 |
|
||||
| MMU（Memory Management Unit） | 虚拟地址到物理地址的映射 |
|
||||
| 硬件栈保护 | 栈溢出检测 |
|
||||
| 双核锁步（Dual-core Lockstep） | 计算故障检测 |
|
||||
|
||||
#### 2.1.3 检测与反应
|
||||
|
||||
内存分区的故障检测和反应机制：
|
||||
|
||||
- **MPU 违例（Memory Protection Violation）**：当 SW-C 访问未授权的内存区域时，MPU 触发异常
|
||||
- **OS 错误处理**：OS 捕获 MPU 违例并执行以下动作：
|
||||
1. 终止违规的 OS-Application
|
||||
2. 记录错误到 DEM
|
||||
3. 通知 EcuM
|
||||
- **看门狗复位**：如果错误处理失败，硬件看门狗将复位 ECU
|
||||
|
||||
> **[FSM_002]** ⌈当发生 MPU 违例时，AUTOSAR OS 应终止违规的 OS-Application 并报告错误。⌋
|
||||
|
||||
#### 2.1.4 限制
|
||||
|
||||
内存分区的限制：
|
||||
|
||||
- **运行时开销**：MPU 配置和上下文切换增加运行时开销
|
||||
- **代码大小**：分区代码通常比单块代码略大
|
||||
- **硬件依赖**：MPU 的数量和粒度取决于具体 MCU
|
||||
- **粒度限制**：MPU 区域数量有限，复杂的分区可能受限
|
||||
|
||||
#### 2.1.5 引用 AUTOSAR 文档
|
||||
|
||||
- AUTOSAR_SWS_OS（操作系统规范）
|
||||
- AUTOSAR_SWS_RTE（运行时环境规范）
|
||||
- AUTOSAR_TPS_SafetyExtensions（安全扩展）
|
||||
|
||||
#### 2.1.6 引用 ISO 26262
|
||||
|
||||
- ISO 26262-5:2018 第 7.4.4 节（软件架构中的无干扰）
|
||||
- ISO 26262-6:2018 第 7.4.7 节（内存分区）
|
||||
|
||||
### 2.2 时序监控（Timing Monitoring）
|
||||
|
||||
#### 2.2.1 故障模型
|
||||
|
||||
时序监控的故障模型：
|
||||
|
||||
- **任务执行超时**：任务未在规定的时间内完成
|
||||
- **死循环**：任务进入无限循环
|
||||
- **死锁**：任务因资源争用而永久阻塞
|
||||
- **过早执行**：任务在不应执行的时候执行
|
||||
- **任务到达率过低**：周期性任务的到达频率低于预期
|
||||
|
||||
#### 2.2.2 描述
|
||||
|
||||
AUTOSAR 通过两个主要机制支持时序监控：**看门狗管理器** 和 **操作系统的时序保护**。
|
||||
|
||||
##### 2.2.2.1 监督实体
|
||||
|
||||
监督实体（Supervised Entity, SE）是看门狗管理器监督的逻辑软件单元。每个 SE 可以是：
|
||||
|
||||
- SW-C 中的一个 Runnable
|
||||
- 一个完整的 SW-C
|
||||
- 一个 BSW 模块
|
||||
- 一个 CDD
|
||||
|
||||
##### 2.2.2.2 看门狗管理器
|
||||
|
||||
看门狗管理器提供三种时序监督机制：
|
||||
|
||||
1. **Alive 监督**：监督周期性软件
|
||||
- 检查 SE 在每个监督周期内是否被调用了预期次数
|
||||
- 配置参数：`ExpectedAliveIndications`、`MinMargin`、`MaxMargin`
|
||||
|
||||
2. **Deadline 监督**：监督非周期性软件
|
||||
- 检查两个检查点之间经过的时间是否在最小和最大限制内
|
||||
- 配置参数：`DeadlineMin`、`DeadlineMax`
|
||||
|
||||
3. **Logical 监督**：监督执行顺序
|
||||
- 检查检查点之间的转换是否合法
|
||||
- 配置：内部图、外部图
|
||||
|
||||
> **看门狗管理器与监督实体的关系**：
|
||||
>
|
||||
> 一个 ECU 可包含多个 SE；一个 SE 关联一个或多个检查点；WdgM 通过监督所有 SE 来决定是否触发硬件看门狗。
|
||||
|
||||
##### 2.2.2.3 操作系统的时序保护
|
||||
|
||||
AUTOSAR OS 提供时序保护机制，独立于看门狗管理器：
|
||||
|
||||
- **任务执行预算（Task Execution Budget）**：每个任务的最大执行时间
|
||||
- **任务到达时间间隔（Task Inter-arrival Time）**：任务两次激活之间的最小时间
|
||||
- **资源锁时间（Resource Lock Time）**：任务持有资源锁的最大时间
|
||||
- **中断执行时间（Interrupt Execution Time）**：ISR 的最大执行时间
|
||||
|
||||
当违反时序约束时，OS 触发保护错误，可配置为：
|
||||
|
||||
- 调用用户定义的错误处理程序
|
||||
- 终止违规任务
|
||||
- 调用 `ShutdownOS()`
|
||||
|
||||
#### 2.2.3 检测与反应
|
||||
|
||||
时序监控的检测和反应：
|
||||
|
||||
- **Alive 监督失败**：本地状态变为 `EXPIRED`
|
||||
- **Deadline 监督失败**：本地状态变为 `EXPIRED`
|
||||
- **OS 时序保护违例**：OS 触发保护钩子（Protection Hook）
|
||||
- **最终反应**：停止触发硬件看门狗，导致硬件看门狗复位 ECU
|
||||
|
||||
> **[FSM_003]** ⌈当看门狗管理器检测到监督失败时，应停止触发看门狗以允许硬件看门狗执行 ECU 复位。⌋
|
||||
|
||||
#### 2.2.4 限制
|
||||
|
||||
时序监控的限制：
|
||||
|
||||
- **检测延迟**：监督是周期性的，故障检测存在延迟
|
||||
- **粒度限制**：监督周期决定了最小可检测的故障间隔
|
||||
- **配置复杂性**：复杂的时序需求需要详细的配置
|
||||
- **与 OS 时序保护的重叠**：可能存在重复监督
|
||||
|
||||
#### 2.2.5 引用 AUTOSAR 文档
|
||||
|
||||
- AUTOSAR_SWS_WatchdogManager（看门狗管理器规范）
|
||||
- AUTOSAR_SWS_OS（操作系统规范）
|
||||
|
||||
#### 2.2.6 引用 ISO 26262
|
||||
|
||||
- ISO 26262-5:2018 第 7.4.5 节（时序行为）
|
||||
- ISO 26262-6:2018 第 7.4.8 节（时序保护）
|
||||
|
||||
### 2.3 逻辑监督（Logical Supervision）
|
||||
|
||||
#### 2.3.1 故障模型
|
||||
|
||||
逻辑监督的故障模型：
|
||||
|
||||
- **控制流错误**：程序执行序列与预期不符
|
||||
- **跳转错误**：条件分支错误
|
||||
- **跳过代码**：重要的安全检查被绕过
|
||||
- **重复执行**：循环退出条件错误导致重复执行
|
||||
|
||||
#### 2.3.2 描述
|
||||
|
||||
逻辑监督由看门狗管理器提供，通过检查点（Checkpoints）和转换（Transitions）实现：
|
||||
|
||||
- **检查点**：监督实体中的关键位置
|
||||
- **内部转换**：同一 SE 内两个检查点之间的合法转换
|
||||
- **外部转换**：不同 SE 的检查点之间的合法转换
|
||||
- **内部图**：内部转换的集合
|
||||
- **外部图**：外部转换的集合
|
||||
|
||||
**图示例**：
|
||||
|
||||
```
|
||||
SE_A: CP0 ──→ CP1 ──→ CP2
|
||||
│
|
||||
↓ (外部转换)
|
||||
SE_B: CP3 ──→ CP4 ──→ CP5
|
||||
```
|
||||
|
||||
#### 2.3.3 检测与反应
|
||||
|
||||
逻辑监督的检测和反应：
|
||||
|
||||
1. WdgM 维护当前已到达的检查点
|
||||
2. 当新的检查点被报告时，WdgM 验证从前一检查点到新检查点的转换是否合法
|
||||
3. 如果转换不合法，本地状态变为 `EXPIRED`
|
||||
4. 错误处理动作与 Alive/Deadline 监督相同
|
||||
|
||||
> **[FSM_004]** ⌈逻辑监督应验证检查点之间的转换是否在配置的图中被允许。⌋
|
||||
|
||||
#### 2.3.4 限制
|
||||
|
||||
逻辑监督的限制：
|
||||
|
||||
- **配置复杂性**：复杂的控制流需要详细的图配置
|
||||
- **检查点开销**：每次 `WdgM_CheckpointReached()` 调用都有运行时开销
|
||||
- **静态配置**：图必须在编译时已知，不支持动态修改
|
||||
|
||||
#### 2.3.5 引用 AUTOSAR 文档
|
||||
|
||||
- AUTOSAR_SWS_WatchdogManager
|
||||
|
||||
#### 2.3.6 引用 ISO 26262
|
||||
|
||||
- ISO 26262-5:2018 第 7.4.6 节（软件架构设计中的错误检测）
|
||||
|
||||
### 2.4 端到端保护（End-2-End Protection）
|
||||
|
||||
#### 2.4.1 故障模型
|
||||
|
||||
端到端保护针对的是**通信链路**上的故障：
|
||||
|
||||
- **重复（Repetition）**：同一条消息被重复接收
|
||||
- **丢失（Loss）**：消息在传输过程中丢失
|
||||
- **插入（Insertion）**：伪消息被插入到通信流中
|
||||
- **乱序（Incorrect Sequence）**：消息到达顺序与发送顺序不一致
|
||||
- **损坏（Corruption）**：消息内容在传输过程中被修改
|
||||
- **延迟（Delay）**：消息延迟到达
|
||||
- **伪装（Masquerading）**：非法的发送方伪装成合法发送方
|
||||
- **寻址错误（Incorrect Addressing）**：消息被错误的接收方接收
|
||||
|
||||
#### 2.4.2 描述
|
||||
|
||||
AUTOSAR 端到端（E2E）保护库通过在通信数据上添加**校验信息**来实现通信故障检测。
|
||||
|
||||
##### 2.4.2.1 端到端配置文件
|
||||
|
||||
E2E 库提供多个保护配置文件（Profiles），每个文件提供不同等级的保护：
|
||||
|
||||
| 配置文件 | CRC 长度 | 计数器 | 适用场景 |
|
||||
|---|---|---|---|
|
||||
| Profile 1 | 8 位 | 4 位 | 简短控制消息 |
|
||||
| Profile 2 | 16 位 | 16 位 | 中等安全相关消息 |
|
||||
| Profile 4 | 32 位 | 16 位 | 高度安全相关消息 |
|
||||
| Profile 5 | 16 位 | 无 | 简单状态消息 |
|
||||
| Profile 6 | 32 位 | 32 位 | 高度安全相关长消息 |
|
||||
| Profile 7 | 64 位 | 32 位 | 最高安全等级消息 |
|
||||
| Profile 11 | 8 位 | 16 位 | 类似 Profile 1 但有更长计数器 |
|
||||
|
||||
> **配置文件选择**：配置文件的选择取决于目标 ASIL 等级。Profile 4 和 Profile 7 通常用于 ASIL D 系统。
|
||||
|
||||
##### 2.4.2.2 端到端状态机
|
||||
|
||||
E2E 接收方维护一个状态机来处理接收的消息：
|
||||
|
||||
| 状态 | 描述 | 转换条件 |
|
||||
|---|---|---|
|
||||
| `E2E_P02STATUS_OK` | 消息正确 | 下一条消息正确接收 |
|
||||
| `E2E_P02STATUS_NONEW` | 无新消息 | 接收超时 |
|
||||
| `E2E_P02STATUS_WRONGCRC` | CRC 校验失败 | 检测到 CRC 错误 |
|
||||
| `E2E_P02STATUS_SYNC` | 同步丢失 | 计数器不连续 |
|
||||
| `E2E_P02STATUS_INITIAL` | 初始状态 | 首次接收 |
|
||||
| `E2E_P02STATUS_REPEATED` | 消息重复 | 计数器未变 |
|
||||
|
||||
##### 2.4.2.3 端到端保护库的集成
|
||||
|
||||
E2E 库通过多种方式集成到 AUTOSAR 通信栈中：
|
||||
|
||||
1. **RTE 层**：在 SW-C 之间通信时自动应用 E2E
|
||||
2. **COM 层**：在 PDU（Protocol Data Unit）级别应用 E2E
|
||||
3. **PduR 层**：在路由过程中应用 E2E
|
||||
4. **CAN/LIN/FlexRay 驱动层**：在传输层应用 E2E
|
||||
|
||||
##### 2.4.2.4 端到端保护包装器
|
||||
|
||||
E2E 包装器（E2E Wrapper）是一个额外的抽象层，它：
|
||||
|
||||
- 在 COM 层之上实现 E2E 保护
|
||||
- 不需要修改 COM 层
|
||||
- 提供更灵活的 E2E 配置
|
||||
|
||||
##### 2.4.2.5 传输管理器
|
||||
|
||||
传输管理器（Transport Manager, Tm）管理 E2E 保护与底层通信的交互：
|
||||
|
||||
- 选择合适的 E2E 配置文件
|
||||
- 维护连接状态
|
||||
- 处理错误恢复
|
||||
|
||||
##### 2.4.2.6 COM 端到端回调
|
||||
|
||||
COM 模块提供 E2E 回调函数：
|
||||
|
||||
- 当接收到 E2E 保护的 PDU 时，COM 调用 E2E 验证函数
|
||||
- 验证结果通过回调函数传递给应用层
|
||||
|
||||
##### 2.4.2.7 RTE 数据转换器
|
||||
|
||||
RTE 数据转换器（Data Transformer）将 E2E 保护集成到 RTE 通信中：
|
||||
|
||||
- 自动在 RTE 通信中插入 E2E 保护
|
||||
- 透明于 SW-C
|
||||
- 编译时配置
|
||||
|
||||
#### 2.4.3 检测与反应
|
||||
|
||||
E2E 保护检测到的故障反应：
|
||||
|
||||
- **重复消息**：丢弃
|
||||
- **丢失消息**：等待下一条或报告错误
|
||||
- **乱序消息**：标记为乱序状态
|
||||
- **损坏消息**：丢弃并报告 DEM 错误
|
||||
- **同步丢失**：等待重新同步或报告错误
|
||||
|
||||
#### 2.4.4 限制
|
||||
|
||||
E2E 保护的限制：
|
||||
|
||||
- **带宽开销**：CRC 和计数器占用额外的通信带宽
|
||||
- **处理开销**：CRC 计算增加 CPU 负载
|
||||
- **延迟**：E2E 处理增加通信延迟
|
||||
- **有限的配置文件**：可用配置文件数量有限，可能不完全匹配所有应用场景
|
||||
|
||||
#### 2.4.5 引用 AUTOSAR 文档
|
||||
|
||||
- AUTOSAR_SWS_E2ELibrary（端到端库规范）
|
||||
- AUTOSAR_SWS_COM（通信规范）
|
||||
- AUTOSAR_SWS_RTE（运行时环境规范）
|
||||
|
||||
#### 2.4.6 引用 ISO 26262
|
||||
|
||||
- ISO 26262-5:2018 第 7.4.9 节（通信安全）
|
||||
- ISO 26262-6:2018 第 7.4.10 节（数据通信）
|
||||
|
||||
---
|
||||
|
||||
## 3 功能安全措施
|
||||
|
||||
### 3.1 AUTOSAR 的功能安全措施
|
||||
|
||||
AUTOSAR 的功能安全措施包括：
|
||||
|
||||
- **可追溯性（Traceability）**：AUTOSAR 提供了从需求到实现的可追溯性机制
|
||||
- **开发措施（Development Measures）**：AUTOSAR 标准要求符合 ISO 26262 的开发措施
|
||||
- **标准的演进（Evolution of the Standard）**：AUTOSAR 标准不断演进以支持新的安全需求
|
||||
|
||||
### 3.2 可追溯性
|
||||
|
||||
AUTOSAR 支持需求到模型元素再到实现的可追溯性：
|
||||
|
||||
- **需求 ID**：每个 AUTOSAR 需求都有唯一标识符
|
||||
- **元模型引用**：AUTOSAR 元模型支持元素之间的引用关系
|
||||
- **ARXML 中的可追溯性**：ARXML 格式支持需求到 AUTOSAR 元素的引用
|
||||
|
||||
### 3.3 开发措施与标准的演进
|
||||
|
||||
AUTOSAR 标准的演进包括以下开发措施：
|
||||
|
||||
- **正式变更控制**：所有规范变更都经过正式审查
|
||||
- **配置管理**：所有文档和代码都有版本控制
|
||||
- **测试覆盖**：AUTOSAR 提供测试规范以验证实现
|
||||
- **工具支持**：AUTOSAR 提供开发工具支持规范的实施
|
||||
|
||||
### 3.4 AUTOSAR 未交付的功能安全措施
|
||||
|
||||
AUTOSAR 本身不交付以下功能安全措施：
|
||||
|
||||
- **硬件设计**：AUTOSAR 不定义硬件安全机制
|
||||
- **生产制造**：生产过程的质量保证
|
||||
- **运营维护**：运行时的安全监控
|
||||
- **系统级安全分析**：FTA（故障树分析）、FMEA（失效模式分析）
|
||||
|
||||
这些措施需要由集成商和 OEM 单独实施。
|
||||
|
||||
### 3.5 安全相关的方法论与模板扩展
|
||||
|
||||
AUTOSAR 元模型支持安全相关扩展：
|
||||
|
||||
- **SafetyExtensions ARPackage**：包含所有与安全相关的元模型扩展
|
||||
- **SafetyRequirement**：表示安全需求
|
||||
- **SafetyMechanism**：表示安全机制
|
||||
- **SafetyIntegrityLevel**：表示 ASIL 等级
|
||||
|
||||
### 3.6 安全用例
|
||||
|
||||
安全用例（Safety Use Case）是 AUTOSAR 安全概念的重要组成部分。详细分析见独立的安全用例示例文档 `AUTOSAR_EXP_SafetyUseCase`（文档 ID 641）。
|
||||
|
||||
> **摘要标记**：本节提供了一个安全用例的简要介绍，详细的安全分析方法、前照灯管理（Front Light Management）示例、SW 架构分析等内容请参见 `AUTOSAR_EXP_SafetyUseCase.md` 文档。
|
||||
|
||||
### 3.7 用于功能安全的 AUTOSAR 特性
|
||||
|
||||
本节描述 AUTOSAR 中可支持功能安全的特性。
|
||||
|
||||
#### 3.7.1 时序相关特性
|
||||
|
||||
##### 3.7.1.1 与提供同步时基相关的特性
|
||||
|
||||
AUTOSAR 通过以下机制提供同步时基：
|
||||
|
||||
- **全局时间（Global Time）**：基于 Ethernet 的精确时间协议（PTP）
|
||||
- **StbM（Synchronized Time-base Manager）**：同步时基管理器
|
||||
- **CanTSyn / EthTSyn**：CAN / Ethernet 时间同步
|
||||
|
||||
**配置参数**：
|
||||
- `StbMTimeBase` — 时基标识
|
||||
- `StbMSyncLossTimeout` — 同步丢失超时
|
||||
- `StbMMainFunctionPeriod` — 主函数周期
|
||||
|
||||
##### 3.7.1.2 与异步处理单元同步相关的特性
|
||||
|
||||
AUTOSAR 通过以下机制处理多核和多 ECU 系统的同步：
|
||||
|
||||
- **IOC（Inter-OS-Application Communication）**：OS-Application 间通信
|
||||
- **多核 RTE**：跨核 RTE 通信
|
||||
- **数据一致性管理**：跨核数据访问的同步
|
||||
|
||||
##### 3.7.1.3 允许应用时间确定性实现的特性
|
||||
|
||||
AUTOSAR 提供以下时间确定性机制：
|
||||
|
||||
- **静态调度表（Static Schedule Table）**：预定义的任务激活时间
|
||||
- **调度策略**：固定优先级、时间片、优先级天花板协议
|
||||
- **时间戳（Time Stamp）**：高精度时间测量
|
||||
|
||||
##### 3.7.1.4 与时序违例保护相关的特性
|
||||
|
||||
AUTOSAR 通过以下机制保护时序约束：
|
||||
|
||||
- **OS 时序保护**：任务执行预算、资源锁时间
|
||||
- **WdgM 时序监督**：Alive、Deadline 监督
|
||||
- **执行预算监控**：监控任务的最大执行时间
|
||||
|
||||
#### 3.7.2 E-Gas 监控相关特性
|
||||
|
||||
E-Gas（电子油门）监控系统是 AUTOSAR 中典型的安全相关应用，涉及：
|
||||
|
||||
- **三级监控概念**：
|
||||
- 第 1 级：功能层（应用软件）
|
||||
- 第 2 级：功能监控（看门狗）
|
||||
- 第 3 级：硬件监控（外部看门狗）
|
||||
|
||||
- **AUTOSAR 模块支持**：
|
||||
- **WdgM**：监督功能执行
|
||||
- **RTE**：确保通信安全
|
||||
- **OS**：提供时序保护
|
||||
- **E2E**：保护通信安全
|
||||
|
||||
> **摘要标记**：本节详细描述了 E-Gas 监控概念（79-85 页）以及与 AUTOSAR 特性的映射。完整内容请参见原文 PDF。
|
||||
|
||||
---
|
||||
|
||||
## 4 硬件诊断
|
||||
|
||||
### 4.1 Core Test（核心测试）
|
||||
|
||||
#### 4.1.1 故障模型
|
||||
|
||||
Core Test 检测以下 MCU 核心故障：
|
||||
|
||||
- **指令执行故障**：CPU 指令解码或执行错误
|
||||
- **寄存器故障**：CPU 寄存器损坏
|
||||
- **ALU 故障**：算术逻辑单元故障
|
||||
- **程序计数器故障**：PC 寄存器跳转到错误位置
|
||||
- **栈指针故障**：栈指针损坏
|
||||
|
||||
#### 4.1.2 描述
|
||||
|
||||
Core Test 通过执行**自检程序**来验证 CPU 的正确性：
|
||||
|
||||
- **指令测试**：执行所有 CPU 指令并验证结果
|
||||
- **寄存器测试**：向所有寄存器写入测试模式并读取验证
|
||||
- **算术测试**：执行算术运算并验证结果
|
||||
- **逻辑测试**：执行逻辑运算并验证结果
|
||||
|
||||
#### 4.1.3 检测与反应
|
||||
|
||||
Core Test 的检测和反应：
|
||||
|
||||
- **执行时机**：通常在 ECU 启动期间和定期运行
|
||||
- **检测结果**：如果测试失败，标记 Core Test 失败
|
||||
- **反应动作**：
|
||||
1. 报告 DEM 错误
|
||||
2. 切换到安全状态
|
||||
3. 触发 ECU 复位
|
||||
|
||||
#### 4.1.4 限制
|
||||
|
||||
Core Test 的限制：
|
||||
|
||||
- **执行时间**：完整的 Core Test 可能需要较长时间
|
||||
- **覆盖率有限**：可能无法检测所有类型的瞬态故障
|
||||
- **需要中断禁用**：Core Test 通常在禁用中断时执行
|
||||
- **硬件依赖**：测试实现高度依赖于具体 MCU
|
||||
|
||||
#### 4.1.5 引用 AUTOSAR 文档
|
||||
|
||||
- AUTOSAR_SWS_Spi（SPI 处理程序，用于下载测试程序）
|
||||
- AUTOSAR_SWS_Mcu（MCU 驱动）
|
||||
|
||||
#### 4.1.6 引用 ISO 26262
|
||||
|
||||
- ISO 26262-5:2018 第 7.4.11 节（处理器自检）
|
||||
|
||||
### 4.2 RAM Test
|
||||
|
||||
#### 4.2.1 故障模型
|
||||
|
||||
RAM Test 检测以下 RAM 故障：
|
||||
|
||||
- **静态位故障**：RAM 单元永久卡在 0 或 1
|
||||
- **动态故障**：RAM 内容在写入后立即丢失
|
||||
- **耦合故障**：一个 RAM 单元的写入影响另一个单元
|
||||
- **地址解码故障**：写入一个地址影响另一个地址
|
||||
- **保持故障**：RAM 单元在一段时间后丢失内容
|
||||
|
||||
#### 4.2.2 描述
|
||||
|
||||
AUTOSAR RAM Test 提供以下测试算法：
|
||||
|
||||
- **March C-**：经典 RAM 测试算法
|
||||
- **March C+**：增强版本
|
||||
- **March SR**：具有更强诊断能力的版本
|
||||
- **Checkerboard**：棋盘格模式测试
|
||||
- **Galpat**：走步测试
|
||||
|
||||
#### 4.2.3 检测与反应
|
||||
|
||||
RAM Test 的检测和反应：
|
||||
|
||||
- **执行时机**：
|
||||
- 启动时（完整 RAM Test）
|
||||
- 运行时（后台 RAM Test，破坏性较低）
|
||||
- **反应动作**：
|
||||
1. 报告 DEM 错误
|
||||
2. 标记相关内存区域为不可信
|
||||
3. 可能触发 ECU 复位
|
||||
|
||||
#### 4.2.4 限制
|
||||
|
||||
RAM Test 的限制：
|
||||
|
||||
- **时间开销**：完整的 RAM Test 占用较长执行时间
|
||||
- **运行时影响**：运行时 RAM Test 占用 CPU 带宽
|
||||
- **覆盖率**：检测算法可能无法检测到所有故障
|
||||
- **内存占用**：测试代码需要额外的内存
|
||||
|
||||
#### 4.2.5 引用 AUTOSAR 文档
|
||||
|
||||
- AUTOSAR_SWS_RAMTest（RAM 测试规范）
|
||||
|
||||
#### 4.2.6 引用 ISO 26262
|
||||
|
||||
- ISO 26262-5:2018 第 7.4.12 节（RAM 测试）
|
||||
|
||||
---
|
||||
|
||||
## 5 附录
|
||||
|
||||
### 5.1 缩略语与缩写
|
||||
|
||||
| 缩写 | 描述 |
|
||||
|---|---|
|
||||
| ASIL | Automotive Safety Integrity Level（汽车安全完整性等级） |
|
||||
| BSW | Basic Software（基础软件） |
|
||||
| CDD | Complex Device Driver（复杂设备驱动） |
|
||||
| CRC | Cyclic Redundancy Check（循环冗余校验） |
|
||||
| DEM | Diagnostic Event Manager（诊断事件管理器） |
|
||||
| E2E | End-to-End（端到端） |
|
||||
| ECU | Electronic Control Unit（电子控制单元） |
|
||||
| EcuM | ECU State Manager（ECU 状态管理器） |
|
||||
| FMEA | Failure Mode and Effects Analysis（失效模式与影响分析） |
|
||||
| FTA | Fault Tree Analysis（故障树分析） |
|
||||
| FTTI | Fault Tolerant Time Interval（故障容错时间间隔） |
|
||||
| MCU | Microcontroller Unit（微控制器单元） |
|
||||
| MPU | Memory Protection Unit（内存保护单元） |
|
||||
| OS | Operating System（操作系统） |
|
||||
| PDU | Protocol Data Unit（协议数据单元） |
|
||||
| QM | Quality Management（质量管理） |
|
||||
| RTE | Runtime Environment（运行时环境） |
|
||||
| SE | Supervised Entity（监督实体） |
|
||||
| SW-C | Software Component（软件组件） |
|
||||
| WdgM | Watchdog Manager（看门狗管理器） |
|
||||
|
||||
### 5.2 相关文档
|
||||
|
||||
- AUTOSAR_EXP_LayeredSoftwareArchitecture — 分层软件架构
|
||||
- AUTOSAR_SWS_WatchdogManager — 看门狗管理器规范
|
||||
- AUTOSAR_SWS_OS — 操作系统规范
|
||||
- AUTOSAR_SWS_RTE — 运行时环境规范
|
||||
- AUTOSAR_SWS_E2ELibrary — 端到端库规范
|
||||
- AUTOSAR_TPS_SafetyExtensions — 安全扩展
|
||||
- AUTOSAR_EXP_SafetyUseCase — 安全用例示例
|
||||
- ISO 26262 — 道路车辆功能安全
|
||||
|
||||
---
|
||||
|
||||
## 翻译说明
|
||||
|
||||
本文档为 AUTOSAR EXP FunctionalSafetyMeasures（文档 ID 664，96 页，4.4.0 版）的中文翻译。翻译策略：
|
||||
|
||||
1. **完整翻译**：封面、文档标识、变更历史、目录、所有主要章节（第 1-4 章）、附录
|
||||
2. **核心安全机制涵盖**：
|
||||
- **内存分区（Memory Partitioning）**：MPU、OS-Application、RTE 通信隔离
|
||||
- **时序监控（Timing Monitoring）**：WdgM Alive/Deadline/Logical 监督、OS 时序保护
|
||||
- **逻辑监督（Logical Supervision）**：检查点与转换图
|
||||
- **端到端保护（E2E Protection）**：E2E 配置文件、状态机、集成
|
||||
3. **关键概念涵盖**：
|
||||
- ASIL 等级（A、B、C、D、QM）
|
||||
- 故障模型、检测与反应、限制
|
||||
- 引用 AUTOSAR 文档与 ISO 26262
|
||||
4. **摘要处理**：第 3.7 节"E-Gas 监控相关特性"为摘要，详细描述见原文 PDF
|
||||
5. **保留内容**：所有模块缩写、需求 ID、ASIL 等级引用、ISO 26262 引用
|
||||
|
||||
本文档为 AUTOSAR 安全架构师、安全工程师和系统集成商提供了 AUTOSAR 中功能安全机制和措施的全面概述。
|
||||
@@ -0,0 +1,877 @@
|
||||
# 安全用例示例（Safety Use Case Example）
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **文档标题** | 安全用例示例（Safety Use Case Example） |
|
||||
| **文档所有者** | AUTOSAR |
|
||||
| **文档责任方** | AUTOSAR |
|
||||
| **文档标识号** | 641 |
|
||||
| **文档状态** | Final（正式发布） |
|
||||
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
|
||||
| **所属标准版本** | 4.4.0 |
|
||||
|
||||
---
|
||||
|
||||
## 文档变更历史（Document Change History）
|
||||
|
||||
| 日期 | 版本 | 变更人 | 变更描述 |
|
||||
|---|---|---|---|
|
||||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 |
|
||||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 编辑性变更 |
|
||||
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 编辑性变更 |
|
||||
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 初始发布 |
|
||||
|
||||
---
|
||||
|
||||
## 目录（Table of Contents）
|
||||
|
||||
1. [引言](#1-引言)
|
||||
2. [项目描述（Item Description）](#2-项目描述)
|
||||
3. [车辆级安全概念（Safety Concept on Vehicle Level）](#3-车辆级安全概念)
|
||||
4. [FLM-ECU 级技术安全概念（Technical Safety Concept on FLM-ECU Level）](#4-flm-ecu-级技术安全概念)
|
||||
5. [软件架构与软件安全需求（SW Architecture and SW Safety Requirements）](#5-软件架构与软件安全需求)
|
||||
6. [结论（Conclusion）](#6-结论)
|
||||
7. [缩写/词汇表（Abbreviation/Glossary）](#7-缩写词汇表)
|
||||
8. [参考文献（References）](#8-参考文献)
|
||||
|
||||
---
|
||||
|
||||
## 1 引言
|
||||
|
||||
本文档从功能安全的角度展示了使用 AUTOSAR 的示例系统的主要分析步骤。本文档中使用的示例基于 AUTOSAR 引导示例 **Front Light Management（前照灯管理）**。在需要时，会添加额外的约束以进行进一步分析或概念讨论。
|
||||
|
||||
本报告的目标是：
|
||||
|
||||
1. 在 AUTOSAR 环境中构建用于功能安全分析的相关用例
|
||||
2. 提供示例以讨论和验证 AUTOSAR 中与安全相关的概念
|
||||
3. 识别当前 AUTOSAR 规范和方法论中功能安全方面的改进潜力
|
||||
4. 提出 AUTOSAR 中安全架构所需的改进或附加概念
|
||||
5. 为"方法论与模板的安全相关扩展（Safety Related Extension for Methodology and Templates）"概念提供输入
|
||||
6. 在 AUTOSAR 方法论之上提供安全分析指南
|
||||
|
||||
该示例在 ISO 26262 要求的上下文中准备，但侧重于 AUTOSAR 相关部分。虽然它可以视为 AUTOSAR 方法论之上安全分析的基本指南，但它仅粗略地涉及主要主题。进一步的细节（例如软件安全需求的详细列表或安全分析措施的示例）可以在下一开发步骤中添加。
|
||||
|
||||
本示例涵盖以下方面：
|
||||
|
||||
- 功能安全概念
|
||||
- 系统级技术安全概念
|
||||
- ECU 级技术安全概念
|
||||
- AUTOSAR 基础软件级的安全方面
|
||||
|
||||
> **注意**：实现约束不一定与现有实现匹配。
|
||||
|
||||
---
|
||||
|
||||
## 2 项目描述（Item Description）
|
||||
|
||||
本示例中选择的项目主要等同于 AUTOSAR 引导示例 **Front Light Management（前照灯管理）**。每当需要额外的定义时，会添加支持安全相关主题澄清的信息。
|
||||
|
||||
当前示例的范围聚焦于前照灯的一个非常有限的功能部分，即**近光灯（low beam）**功能。所有其他灯光功能（例如停车灯、雾灯等）被排除在外。作为例外，**日间行车灯（daytime running lights）**被命名为可能的回退解决方案，因此集成在以下图中。然而，日间行车灯的控制细节不是本示例的一部分。
|
||||
|
||||
所有贡献于前照灯管理的车辆级部件在本示例中视为**"系统（the system）"**（见图 1）。这包括：
|
||||
|
||||
- 前照灯管理 ECU
|
||||
- 相关传感器
|
||||
- 执行器
|
||||
- 显示
|
||||
- 供电部分
|
||||
|
||||
### 2.1 功能行为
|
||||
|
||||
近光灯功能的一般特征是在黑暗中照亮道路。此外，近光灯通知其他道路使用者有车辆接近。激活/停用条件总结于下表。
|
||||
|
||||
| 功能 | 操作元素 | 开启条件 | 关闭条件 |
|
||||
|---|---|---|---|
|
||||
| **近光灯（Low Beam）** | 灯光开关（LS） | CL15 ON **且** 灯光开关 ON | 灯光开关 OFF **或** CL15 OFF |
|
||||
|
||||
近光灯可在点火钥匙激活 CL15（点火开关）期间由灯光开关打开。近光灯的任何故障都应向驾驶员指示。
|
||||
|
||||
作为附加功能，日间行车灯作为前照灯管理系统的一部分可用。此外，应应用近光灯功能的所有相关规范法规。
|
||||
|
||||
基于该标称功能，导出以下功能和相关的功能需求：
|
||||
|
||||
1. **检测近光灯请求**
|
||||
a. 前照灯管理器应评估点火钥匙位置
|
||||
b. 前照灯管理器应读取 LS 开关位置
|
||||
|
||||
2. **评估近光灯请求**
|
||||
a. 前照灯管理器应评估 LS 开关状态
|
||||
b. 仅当 LS 开关状态从 OFF 变为 ON 时，前照灯管理器才创建开关事件（ON）
|
||||
c. 如果 LS 开关状态从 ON 变为 OFF，前照灯管理器创建开关事件（OFF）
|
||||
|
||||
3. **控制近光灯**
|
||||
a. 如果点火钥匙位置为 ON 且检测到灯光开关事件，前照灯管理器应激活近光灯
|
||||
b. 如果点火钥匙位置为 OFF 或检测到开关事件（OFF），前照灯管理器应停用近光灯
|
||||
|
||||
4. **监控近光灯功能**
|
||||
a. 前照灯管理器应监督近光灯
|
||||
b. 前照灯管理器应指示近光灯的故障，例如电流故障或灯泡故障
|
||||
|
||||
5. **激活日间行车灯**
|
||||
a. 在近光灯故障的情况下，前照灯管理器应激活日间行车灯
|
||||
|
||||
### 2.2 初步架构（Preliminary Architecture）
|
||||
|
||||
下图显示了假设的系统架构，包括以下系统元素：
|
||||
|
||||
- 前照灯管理 ECU（Front Light Management ECU）
|
||||
- 灯光开关（LS）
|
||||
- 点火钥匙（经由车身控制器）
|
||||
- 电源
|
||||
- 前照灯（左和右）
|
||||
- 日间行车灯（左和右）
|
||||
- HMI（人机界面）
|
||||
|
||||
| 系统元素 | 与 FLM ECU 的接口 |
|
||||
|---|---|
|
||||
| 灯光开关位置（LS） | DIO |
|
||||
| 点火钥匙位置（CL15）（经由车身控制器） | CAN 接口 |
|
||||
| HMI | CAN 接口 |
|
||||
| 前照灯控制（左） | PWM |
|
||||
| 前照灯控制（右） | PWM |
|
||||
| 日间行车灯（左&右） | PWM |
|
||||
| 电源 | 模拟 |
|
||||
|
||||
### 2.3 示例安全分析的假设和限制
|
||||
|
||||
作为示例的起点，假设系统的以下配置：
|
||||
|
||||
1. 前照灯管理软件在一个 ECU 上的实现
|
||||
2. 通过提供数字 I/O 输出的开关激活灯光
|
||||
- **注意**：常见类型的此类灯光开关提供模拟或最多 4 个数字输出，并带逻辑表以验证状态。本示例的目的是展示数据流通过软件架构。传感器的硬件诊断不在重点。
|
||||
3. 紧急灯光功能（例如 µC 操作故障情况下）由硬件提供，不打算使用 AUTOSAR 软件部分
|
||||
4. 所有内存（易失性和非易失性）受到针对可逆瞬态故障的保护。假设 ECC 等机制可用
|
||||
5. 内存分区的硬件手段可用（例如 MPU）
|
||||
6. 前照灯管理软件与不符合 ISO 26262 ASIL 等级的 BSW 模块集成
|
||||
7. 执行微控制器的故障模式分析，并定义和实现安全措施。该分析基于供应商提供的数据，例如安全手册和 ISO 26262 的要求
|
||||
|
||||
此外，定义了后续约束以将示例的重点放在特定的 AUTOSAR 软件安全问题：
|
||||
|
||||
1. 假设 ECU 按要求工作：
|
||||
a. ECU 正确唤醒、运行和进入睡眠（本示例不关注模式管理或状态管理）
|
||||
b. 必要的通信网络可用、启动且正确运行（本示例不关注 COM 管理）
|
||||
c. 必要的 BSW 模块按要求触发
|
||||
2. 不考虑板载布线系统、电池或电源的故障
|
||||
3. 不考虑近光灯的电源故障
|
||||
4. 假设灯泡的启动测试已就位。其设计和实现不是本示例的一部分
|
||||
5. 灯光开关信号（LS）已经被过滤/去抖
|
||||
|
||||
---
|
||||
|
||||
## 3 车辆级安全概念（Safety Concept on Vehicle Level）
|
||||
|
||||
本章概述了车辆级的安全分析及其结果，通常由 OEM 创建并部分提供给供应商。
|
||||
|
||||
> **注意**：这种安全分析结构不能 1:1 映射到 ISO 26262 [1] 的结构，因为该标准未明确包括开发的不同可能范围。
|
||||
|
||||
### 3.1 危险分析与风险评估结果
|
||||
|
||||
对于本示例，假设以下危险和属性被识别为危险和风险评估的输出：
|
||||
|
||||
**危险 H1**：**近光灯的完全丢失**（**ASIL B**）
|
||||
|
||||
该危险可能导致驾驶员失去对车辆的控制、离开道路并与环境物体碰撞。
|
||||
|
||||
**H1 的例外和边界条件**：
|
||||
|
||||
- 仅在恶劣能见度条件（夜间、雾等）下，近光灯的丢失被视为风险
|
||||
- 在弯曲的、未照明的乡村道路上，近光灯的丢失被评估为最关键的情况
|
||||
- 仅一个近光灯的丢失不被视为直接导致危险情况。然而，这是一个潜在故障，将包含在概念咨询中
|
||||
|
||||
**ASIL**：ASIL B 等级基于危险和风险评估中确定的严重程度、暴露率和可控性。
|
||||
|
||||
**安全目标 SG01**：**防止近光灯的完全丢失**
|
||||
|
||||
**安全状态**：近光灯激活
|
||||
|
||||
**故障容错时间（FTTI）**：500 ms（夜间行驶期间激活灯光时应考虑近光灯的丢失）
|
||||
|
||||
> **注意**：可以假设额外的危险。然而，为了限制我们的示例，假设它是唯一相关的危险。在这一点上纳入额外的风险对 AUTOSAR 特性讨论似乎没有帮助。
|
||||
|
||||
### 3.2 相关故障模式
|
||||
|
||||
安全目标 SG01 可能通过以下一种或多种故障（MF）被违反：
|
||||
|
||||
- **MF01**：灯光开启/关闭条件检测的故障
|
||||
- **MF02**：用于打开灯光的光请求函数的评估和实现故障
|
||||
- **MF03**：激活灯光的故障
|
||||
|
||||
### 3.3 功能安全概念
|
||||
|
||||
功能描述、安全目标以及顶层安全需求的结果是一个功能安全架构，该架构将映射到特定的车辆架构。
|
||||
|
||||
#### 3.3.1 FunSafReq01-01：
|
||||
|
||||
**FLM 应正确检测近光灯的任何有效开启条件**。（**ASIL B**）
|
||||
- 关联到 MF01：在"有效近光灯开启"请求后没有近光灯
|
||||
|
||||
#### 3.3.2 FunSafReq01-02：
|
||||
|
||||
**FLM 应验证接收到的任何近光灯请求的有效性，并相应地激活或停用近光灯**。（**ASIL B**）
|
||||
- 关联到 MF02：在没有接收到"有效近光灯关闭"请求时关闭灯光
|
||||
|
||||
#### 3.3.3 FunSafReq01-03：
|
||||
|
||||
**FLM 应检测激活的近光灯的故障并将故障信号通知驾驶员**。（**ASIL B**）
|
||||
- 关联到 MF03：激活灯光的故障
|
||||
|
||||
> **注意**：
|
||||
> - 有效的近光灯开启请求 => "CL15 为 ON 且灯光开关从 OFF 变为 ON"
|
||||
> - 有效的近光灯关闭请求 => "灯光开关从 ON 变为 OFF"
|
||||
|
||||
### 3.4 车辆级安全需求
|
||||
|
||||
作为车辆级安全分析的一部分，根据可用的系统架构定义了警告和降级概念。车辆级技术安全需求从功能安全需求和初步架构的假设（见 2.2）导出，并标记为 SysSafReq ID。
|
||||
|
||||
> **注意**：生成技术安全需求的过程不是本文档的一部分，因此不在下面描述。这些车辆级需求用于演示若干需求级别。它们既未完全分析，也未从实际实现映射。
|
||||
|
||||
#### 3.4.1 警告和降级概念
|
||||
|
||||
对于近光灯，应实现以下 2 步降级概念：
|
||||
|
||||
**正常模式（Normal Mode）**：
|
||||
|
||||
- 见项目描述中的标称功能（见 2）
|
||||
|
||||
**降级模式步骤 1 — 丢失一个近光灯**：
|
||||
|
||||
- 第二个近光灯仍执行其功能
|
||||
- 当请求近光灯但未成功激活（检测到故障）时，应向驾驶员提供警告，指示近光灯的部分丢失
|
||||
|
||||
**降级模式步骤 2 — 丢失两个近光灯**：
|
||||
|
||||
- 当请求近光灯但未成功激活（检测到故障）时，应激活日间行车灯
|
||||
- 当请求近光灯时，应向驾驶员提供警告，指示近光灯的丢失和日间行车灯的激活
|
||||
|
||||
> **注意**：这种使用日间行车灯作为回退的做法仅用作示例以演示降级功能。此解决方案在认证方面可能不合适。
|
||||
|
||||
> **注意**：在此模式下可以激活其他驾驶员辅助功能以协助驾驶员，但这不是本示例的一部分。
|
||||
|
||||
#### 3.4.2 技术安全需求（车辆级）
|
||||
|
||||
以下技术安全需求基于 3.3 中的确定在本示例分析中导出：
|
||||
|
||||
##### 3.4.2.1 SysSafReq01
|
||||
|
||||
**CAN 连接的车身控制器应通过 CAN 总线消息 CL15_01（CAN 消息：CL15_01，CAN 信号：CL15ON（Boolean，'1' 表示 clamp 15 设置为 on，'0' 表示 clamp 15 设置为 off））发出点火钥匙 clamp 15 状态信号。**（**ASIL B**）
|
||||
|
||||
> **注意**：CAN 消息细节在 CAN DB 中定义（频率、抑制时间、信号类型），作为标称功能的一部分。
|
||||
|
||||
##### 3.4.2.2 SysSafReq02
|
||||
|
||||
**灯光开关应通过数字 HW 线路 HW_LB_OFF（0=0V 表示请求灯光开启，1=5V 表示请求灯光关闭）发出开关状态信号。**（**ASIL B**）
|
||||
|
||||
##### 3.4.2.3 SysSafReq03
|
||||
|
||||
**灯光开关内的故障应导致数字 HW 线路 HW_LB_OFF 设置为 0。**（**ASIL B**）
|
||||
|
||||
##### 3.4.2.4 SysSafReq04
|
||||
|
||||
**FLM ECU 应确保在为灯泡供电的条件满足时（如标称功能定义），保持为灯泡供电的限制（如电压和 PWM）。**（**ASIL B**）
|
||||
|
||||
##### 3.4.2.5 SysSafReq05
|
||||
|
||||
**当 CL15ON==1 时，FLM ECU 应仅在 HW_LB_OFF==1 条件连续 20ms 满足时才关闭灯光。**（**ASIL B**）
|
||||
|
||||
> **注意**：等待信号值稳定条件几毫秒的时序条件包括去抖。20ms 的特定值是凭经验取的。也可以使用其他值。
|
||||
|
||||
##### 3.4.2.6 SysSafReq06
|
||||
|
||||
**FLM ECU 应检测电路故障（灯泡、保险丝、布线开路/短路）并通过 CAN 信号化（CAN 消息：LightStatus_01，CAN 信号：LBFailure（2 位，01 表示左侧近光灯故障，10 表示右侧近光灯故障，11 表示两个近光灯都故障））。**（**ASIL B**）
|
||||
|
||||
##### 3.4.2.7 SysSafReq07
|
||||
|
||||
**如果连续 200ms 检测到两个近光灯灯泡故障，FLM ECU 应激活两个日间行车灯（DRL）。**（**ASIL B**）
|
||||
|
||||
> **注意**：FTT 预算按以下方式分配：200ms 故障检测时间 + 200ms 卤素灯泡达到全强度的保守时间间隔（故障反应）+ 100ms 缓冲 = 500ms。
|
||||
|
||||
##### 3.4.2.8 SysSafReq08
|
||||
|
||||
**FLM ECU 应使用独立电路为左和右灯泡供电，使得没有单一故障能导致近光灯的完全丢失。**（**ASIL B**）
|
||||
|
||||
##### 3.4.2.9 SysSafReq09
|
||||
|
||||
**HMI 应根据通过 CAN 接收的信号 LBFailure（CAN 消息：LightStatus_01，CAN 信号：LBFailure）显示灯泡故障信息。**（**ASIL A**）
|
||||
|
||||
> **注意**：对于此措施，FTT 不相关，因为它是针对潜在故障的措施。这里可以计算相关时间（诊断间隔）。针对双灯泡故障的措施（FTT 相关）是激活日间行车灯。作为针对潜在故障的措施，ASIL 根据 ISO 26262-4:2011(E) 6.4.4.4 降低。
|
||||
|
||||
##### 3.4.2.10 SysSafReq10
|
||||
|
||||
**必须确保发送方和接收方之间通过 CAN 的数据传输。CAN 消息：CL15_01，CAN 信号：CL15ON Boolean。**（**ASIL B**）
|
||||
|
||||
> **注意**：对于此措施，应考虑数据交换的所有相关故障模式（见 ISO 26262 第 6 部分）。
|
||||
|
||||
##### 3.4.2.11 SysSafReq11
|
||||
|
||||
**必须确保发送方和接收方之间通过 CAN 的数据传输。CAN 消息：LightStatus_01，CAN 信号：LBFailure。**（**ASIL A**）
|
||||
|
||||
> **注释**：对于此措施，应考虑数据交换的所有相关故障模式（见 ISO 26262-6）。
|
||||
|
||||
##### 3.4.2.12 SysSafReq12
|
||||
|
||||
**如果连续 200ms 检测到关于消息 CL15_01 的通信故障，FLM ECU 应激活近光灯。**
|
||||
|
||||
> **注意**：FTT 预算分配与 SysSafReq07 相同。
|
||||
|
||||
##### 3.4.2.13 SysSafReq13
|
||||
|
||||
**FLM ECU 应**：
|
||||
|
||||
- 如果连续 200ms 检测到关于消息 LightStatus_01 的通信故障，激活两个日间行车灯（DRL），并且
|
||||
- 向驾驶员提供文本消息，如"灯光系统缺陷"
|
||||
|
||||
#### 3.4.3（功能）系统安全需求的分配
|
||||
|
||||
下一步，所有系统安全需求需要分配到架构系统元素（见图 5）。
|
||||
|
||||
#### 3.4.4 技术系统安全需求（车辆级）总结
|
||||
|
||||
系统安全需求到功能安全需求（车辆级）的整体映射以及到系统元素的分配总结于表 3。
|
||||
|
||||
> **摘要标记**：本节包含一个大型需求映射表（约 13 项需求 × 5 列），涵盖 SysSafReq01-13 与功能安全需求、系统元素和 ASIL 等级的映射。下表列出前 6 项代表性映射；完整表见原文 PDF 第 17-18 页。
|
||||
|
||||
| ID | 系统安全需求（摘要） | 支持功能安全需求 ID | ASIL | 项目 |
|
||||
|---|---|---|---|---|
|
||||
| `SysSafReq01` | BCU 通过 CAN CL15_01 信号化 CL15 状态 | `FunSafReq01-01` | ASIL B | BC-ECU |
|
||||
| `SysSafReq02` | 灯光开关通过 HW_LB_OFF 信号化状态 | `FunSafReq01-01` | ASIL B | LS |
|
||||
| `SysSafReq03` | 灯光开关故障时 HW_LB_OFF=0 | `FunSafReq01-01` | ASIL B | LS |
|
||||
| `SysSafReq04` | FLM ECU 保持灯泡供电限制 | `FunSafReq01-02` | ASIL B | FLM-ECU |
|
||||
| `SysSafReq05` | CL15ON==1 时 20ms 后才关闭灯光 | `FunSafReq01-02` | ASIL B | FLM-ECU |
|
||||
| `SysSafReq06` | 检测电路故障并通过 CAN 信号化 | `FunSafReq01-03` | ASIL B | FLM-ECU |
|
||||
|
||||
---
|
||||
|
||||
## 4 FLM-ECU 级技术安全概念
|
||||
|
||||
### 4.1 ECU 级的假设和限制
|
||||
|
||||
- 与车辆级假设一致
|
||||
- ECU 使用单核微控制器
|
||||
- 假设硬件平台提供 MPU 支持
|
||||
- 假设支持 OS 时序保护
|
||||
- WdgM 配置为监督所有安全相关 SE
|
||||
|
||||
### 4.2 要满足的安全目标
|
||||
|
||||
车辆级的安全目标 **SG01: Prevent total loss of low beam** 必须在 FLM ECU 级别被满足。
|
||||
|
||||
### 4.3 相关系统安全需求
|
||||
|
||||
车辆级系统安全需求中分配到 FLM ECU 的所有需求都必须在 ECU 级别被满足。
|
||||
|
||||
### 4.4 ECU 级概念概述
|
||||
|
||||
FLM ECU 级别的安全概念包括以下层次：
|
||||
|
||||
1. **应用软件层**：
|
||||
- 前照灯应用 SWC
|
||||
- 执行器 SWC
|
||||
- 安全检查 SWC
|
||||
|
||||
2. **RTE 层**：
|
||||
- 跨 SW-C 通信
|
||||
- E2E 保护
|
||||
|
||||
3. **基础软件层**：
|
||||
- COM（带 E2E）
|
||||
- OS（带 MPU 保护）
|
||||
- WdgM（监督安全相关 SE）
|
||||
- DEM（错误诊断）
|
||||
|
||||
4. **硬件层**：
|
||||
- MPU
|
||||
- 看门狗硬件
|
||||
- 时钟监控
|
||||
|
||||
### 4.5 ECU 级需求
|
||||
|
||||
ECU 级需求基于系统级安全需求派生：
|
||||
|
||||
| ID | ECU 级需求 | 关联车辆级需求 |
|
||||
|---|---|---|
|
||||
| `EcuSafReq01` | FLM ECU 应正确读取 HW_LB_OFF 输入 | SysSafReq02 |
|
||||
| `EcuSafReq02` | FLM ECU 应正确配置 HW_LB_OFF 端口和引脚 | SysSafReq02 |
|
||||
| `EcuSafReq03` | FLM ECU 应正确转换 CL15ON 到 CL15_01 消息 | SysSafReq01 |
|
||||
| `EcuSafReq04` | FLM ECU 应通过 AUTOSAR BSW/RTE 正确路由 CL15_01 消息 | SysSafReq01 |
|
||||
| `EcuSafReq05` | FLM ECU 应检测 CL15ON 的通信故障 | SysSafReq10 |
|
||||
| `EcuSafReq06` | 正确读取灯泡健康测量值 | SysSafReq06 |
|
||||
| `EcuSafReq07` | 正确供电灯泡 | SysSafReq04 |
|
||||
| `EcuSafReq08` | 检测灯泡故障 | SysSafReq06 |
|
||||
| `EcuSafReq09` | 通过 CAN 报告灯泡故障 | SysSafReq06 |
|
||||
| `EcuSafReq10` | 监督所有安全相关 SW-C | 新增 |
|
||||
|
||||
### 4.6 ECU 功能
|
||||
|
||||
FLM ECU 的主要功能：
|
||||
|
||||
#### 4.6.1 读取灯光开关状态
|
||||
|
||||
通过 DIO 接口读取灯光开关状态（HW_LB_OFF）。
|
||||
|
||||
#### 4.6.2 读取点火钥匙状态（经由车身控制器）
|
||||
|
||||
通过 CAN 接口接收来自车身控制器的 CL15_01 消息。
|
||||
|
||||
#### 4.6.3 激活灯光（物理）
|
||||
|
||||
通过 PWM 输出控制左和右近光灯。
|
||||
|
||||
#### 4.6.4 监控灯光
|
||||
|
||||
通过 ADC 通道读取灯泡的电流消耗以检测灯泡故障。
|
||||
|
||||
#### 4.6.5 提供驾驶员反馈
|
||||
|
||||
通过 CAN 发送 LightStatus_01 消息以通知 HMI 灯泡故障状态。
|
||||
|
||||
#### 4.6.6 控制灯光（逻辑）
|
||||
|
||||
应用 SWC 根据 CL15ON 和 HW_LB_OFF 计算灯光请求状态。
|
||||
|
||||
---
|
||||
|
||||
## 5 软件架构与软件安全需求
|
||||
|
||||
### 5.1 软件架构
|
||||
|
||||
本节展示软件架构的不同视图。
|
||||
|
||||
#### 5.1.1 软件组件
|
||||
|
||||
主要的软件组件（SWC）：
|
||||
|
||||
- **FLM 应用 SWC**：包含前照灯管理的应用逻辑
|
||||
- **Actuator SWC**：负责控制灯泡的执行器
|
||||
- **Sensor SWC**：处理传感器输入
|
||||
- **Safety SWC**：实现安全检查
|
||||
|
||||
#### 5.1.2 RTE 运行时环境
|
||||
|
||||
RTE 提供 SW-C 之间的通信：
|
||||
|
||||
- 显式接口（Sender-Receiver、Client-Server）
|
||||
- 数据转换（包括 E2E 保护）
|
||||
- 模式管理
|
||||
|
||||
#### 5.1.3 AUTOSAR BSW 视图
|
||||
|
||||
BSW 视图显示所有基础软件模块及其相互关系：
|
||||
|
||||
- **MCAL**：DIO、ADC、PWM、SPI
|
||||
- **ECUAL**：PORT、MCU
|
||||
- **服务层**：OS、COM、RTE、WdgM、DEM、EcuM
|
||||
- **CDD**：复杂驱动
|
||||
|
||||
#### 5.1.4 BSW 功能概述
|
||||
|
||||
主要的 BSW 功能：
|
||||
|
||||
1. **输入处理**：通过 DIO 读取灯光开关
|
||||
2. **通信处理**：通过 CAN 接收 CL15 状态和发送灯泡状态
|
||||
3. **输出处理**：通过 PWM 控制灯泡
|
||||
4. **安全监控**：WdgM 监督安全相关 SE
|
||||
5. **故障诊断**：DEM 记录所有故障事件
|
||||
|
||||
### 5.2 故障模式
|
||||
|
||||
#### 5.2.1 硬件故障模式
|
||||
|
||||
- DIO 输入卡在 0 或 1
|
||||
- ADC 读数偏差
|
||||
- PWM 输出故障
|
||||
- CAN 收发器故障
|
||||
- MPU 故障
|
||||
|
||||
#### 5.2.2 软件故障模式
|
||||
|
||||
- SW-C 死循环
|
||||
- SW-C 死锁
|
||||
- 通信数据损坏
|
||||
- 检查点未到达
|
||||
- 错误的灯光控制逻辑
|
||||
|
||||
### 5.3 软件方面和潜在故障模式分析
|
||||
|
||||
本节详细分析每个 ECU 中的软件方面和潜在故障模式。
|
||||
|
||||
#### 5.3.1 ECU02 的分析：CAN CL15 到逻辑 CL15_01 消息的正确转换
|
||||
|
||||
**关联需求**：`EcuSafReq03`
|
||||
|
||||
**故障分析**：
|
||||
- COM 模块可能错误地解析 CAN 消息
|
||||
- 信号提取可能出错
|
||||
- 信号值可能被错误地映射
|
||||
|
||||
**缓解措施**：
|
||||
- E2E 保护
|
||||
- COM 信号验证
|
||||
- 范围检查
|
||||
|
||||
#### 5.3.2 ECU03 的分析：CL15_01 消息通过 AUTOSAR BSW/RTE 的正确路由
|
||||
|
||||
**关联需求**：`EcuSafReq04`
|
||||
|
||||
**故障分析**：
|
||||
- RTE 路由错误
|
||||
- 数据缓冲损坏
|
||||
- 类型不匹配
|
||||
|
||||
**缓解措施**：
|
||||
- RTE 类型检查
|
||||
- E2E 保护
|
||||
- 数据一致性检查
|
||||
|
||||
#### 5.3.3 ECU27 的分析：CL15_01.CL15ON 在发送方和接收方之间的传输
|
||||
|
||||
**关联需求**：SysSafReq10（**ASIL B**）
|
||||
|
||||
**故障分析**：
|
||||
- CAN 帧丢失
|
||||
- CAN 帧损坏
|
||||
- CAN 帧乱序
|
||||
- CAN 帧重复
|
||||
|
||||
**缓解措施**：
|
||||
- E2E Profile 4（CRC + Counter）
|
||||
- 周期性发送
|
||||
- 超时检测
|
||||
|
||||
#### 5.3.4 ECU04 的分析：检测影响 CL15ON 的潜在通信故障
|
||||
|
||||
**关联需求**：`EcuSafReq05`
|
||||
|
||||
**故障分析**：
|
||||
- E2E 验证失败
|
||||
- 计数器不连续
|
||||
- 超时
|
||||
|
||||
**缓解措施**：
|
||||
- 200ms 连续故障检测
|
||||
- 激活近光灯作为故障反应
|
||||
|
||||
#### 5.3.5 ECU06 的分析：HW_LB_OFF 输入的正确读取
|
||||
|
||||
**关联需求**：`EcuSafReq01`
|
||||
|
||||
**故障分析**：
|
||||
- DIO 读取错误
|
||||
- 端口配置错误
|
||||
- 信号去抖不充分
|
||||
|
||||
**缓解措施**：
|
||||
- PORT 模块正确配置
|
||||
- 多次读取验证
|
||||
- 时间窗口去抖
|
||||
|
||||
#### 5.3.6 ECU07 的分析：HW_LB_OFF 输入端口和引脚的正确配置
|
||||
|
||||
**关联需求**：`EcuSafReq02`
|
||||
|
||||
**故障分析**：
|
||||
- 端口方向错误
|
||||
- 引脚复用错误
|
||||
- 上下拉电阻配置错误
|
||||
|
||||
**缓解措施**：
|
||||
- 编译时配置验证
|
||||
- 启动时端口验证
|
||||
|
||||
#### 5.3.7 ECU08 的分析：HW_LB_OFF 输入到逻辑 LB_OFF 信号的正确转换
|
||||
|
||||
**故障分析**：
|
||||
- 信号电平转换错误
|
||||
- 信号反转
|
||||
|
||||
**缓解措施**：
|
||||
- 信号映射验证
|
||||
|
||||
#### 5.3.8 ECU09 的分析：LB_OFF 通过 AUTOSAR BSW/RTE 的正确路由
|
||||
|
||||
**故障分析**：
|
||||
- RTE 路由错误
|
||||
- 数据一致性
|
||||
|
||||
**缓解措施**：
|
||||
- E2E 保护
|
||||
|
||||
#### 5.3.9 ECU10 的分析：检测影响 LB_OFF 的潜在故障
|
||||
|
||||
**故障分析**：
|
||||
- 信号卡在固定值
|
||||
- 信号抖动
|
||||
|
||||
**缓解措施**：
|
||||
- 200ms 连续故障检测
|
||||
- 激活近光灯
|
||||
|
||||
#### 5.3.10 ECU12 的分析：应用 SWC 确定 LB_OFF 和 CL15ON 状态
|
||||
|
||||
**故障分析**：
|
||||
- SWC 内部状态错误
|
||||
- 状态机错误
|
||||
|
||||
**缓解措施**：
|
||||
- WdgM Alive 监督
|
||||
- 状态机验证
|
||||
|
||||
#### 5.3.11 ECU13 的分析：应用 SWC 评估灯光请求条件
|
||||
|
||||
**故障分析**：
|
||||
- 条件判断错误
|
||||
- 时序条件错误
|
||||
|
||||
**缓解措施**：
|
||||
- 详细的代码审查
|
||||
- 单元测试
|
||||
|
||||
#### 5.3.12 ECU14 的分析：应用 SWC 设置或重置灯光开启命令
|
||||
|
||||
**关联需求**：SysSafReq12, SysSafReq07
|
||||
|
||||
**故障分析**：
|
||||
- 状态转换错误
|
||||
- 输出命令错误
|
||||
|
||||
**缓解措施**：
|
||||
- 故障安全状态（激活近光灯）
|
||||
- WdgM 监督
|
||||
|
||||
#### 5.3.13 ECU15 的分析：双 LB 灯泡故障时激活日间行车灯
|
||||
|
||||
**关联需求**：SysSafReq07
|
||||
|
||||
**故障分析**：
|
||||
- 故障检测延迟
|
||||
- 误激活
|
||||
|
||||
**缓解措施**：
|
||||
- 200ms 连续检测
|
||||
- 信号去抖
|
||||
|
||||
#### 5.3.14 ECU16 的分析：根据灯光请求和规范的正确供电
|
||||
|
||||
**关联需求**：`EcuSafReq07`
|
||||
|
||||
**故障分析**：
|
||||
- PWM 错误
|
||||
- 电流限制违反
|
||||
|
||||
**缓解措施**：
|
||||
- PWM 硬件保护
|
||||
- 反馈监控
|
||||
|
||||
#### 5.3.15 ECU29 的分析：逻辑 PWM-L 信号到 SPI 总线消息的正确转换
|
||||
|
||||
**故障分析**：
|
||||
- 信号转换错误
|
||||
- 时序问题
|
||||
|
||||
**缓解措施**：
|
||||
- SPI 通信验证
|
||||
- CRC 保护
|
||||
|
||||
#### 5.3.16 ECU17 的分析：set_pwm 请求到 µC SPI 输出的正确路由
|
||||
|
||||
**故障分析**：
|
||||
- 路由错误
|
||||
- 缓冲区损坏
|
||||
|
||||
**缓解措施**：
|
||||
- SPI 通信保护
|
||||
- E2E 保护
|
||||
|
||||
#### 5.3.17 ECU20 的分析：灯泡供电时应用 SWC 评估灯泡状态
|
||||
|
||||
**关联需求**：`EcuSafReq08`
|
||||
|
||||
**故障分析**：
|
||||
- 状态评估错误
|
||||
- 故障检测延迟
|
||||
|
||||
**缓解措施**：
|
||||
- 周期性检查
|
||||
- 多重评估
|
||||
|
||||
#### 5.3.18 ECU30 的分析：执行器 SWC 读取并提供灯泡状态
|
||||
|
||||
**关联需求**：`EcuSafReq06`
|
||||
|
||||
**故障分析**：
|
||||
- ADC 读数错误
|
||||
- 数据传输错误
|
||||
|
||||
**缓解措施**：
|
||||
- ADC 校准
|
||||
- E2E 保护
|
||||
|
||||
#### 5.3.19 ECU21 的分析：通过 CAN 总线报告检测到的故障
|
||||
|
||||
**关联需求**：`EcuSafReq09`
|
||||
|
||||
**故障分析**：
|
||||
- CAN 通信失败
|
||||
- 数据损坏
|
||||
|
||||
**缓解措施**：
|
||||
- E2E Profile 4
|
||||
- DEM 错误记录
|
||||
|
||||
#### 5.3.20 ECU23 的分析：执行器 SWC 启动灯泡健康测量路径每个元素的诊断
|
||||
|
||||
**故障分析**：
|
||||
- 诊断未执行
|
||||
- 诊断结果错误
|
||||
|
||||
**缓解措施**：
|
||||
- 周期性自检
|
||||
- 多通道验证
|
||||
|
||||
#### 5.3.21 ECU24 的分析：灯泡健康测量值 read_current_L、read_current_R 通过 AUTOSAR BSW/RTE 的正确路由
|
||||
|
||||
**故障分析**：
|
||||
- 数据路由错误
|
||||
- 类型不匹配
|
||||
|
||||
**缓解措施**：
|
||||
- E2E 保护
|
||||
- 数据类型检查
|
||||
|
||||
#### 5.3.22 ECU25 的分析：ADC-HW 将测量的电流转换为 read_current_L、read_current_R
|
||||
|
||||
**关联需求**：`EcuSafReq06`
|
||||
|
||||
**故障分析**：
|
||||
- ADC 转换错误
|
||||
- 校准漂移
|
||||
|
||||
**缓解措施**：
|
||||
- 周期性 ADC 校准
|
||||
- 范围检查
|
||||
|
||||
#### 5.3.23 ECU26 的分析：SW-C 之间的正确数据交换（时序和内容）
|
||||
|
||||
**故障分析**：
|
||||
- 数据交换时序错误
|
||||
- 数据内容损坏
|
||||
|
||||
**缓解措施**：
|
||||
- E2E 保护
|
||||
- 超时监控
|
||||
|
||||
> **摘要标记**：5.3 节共包含 23 个详细的 ECU 分析（ECU02-ECU30），每个分析都包含故障分析、缓解措施和需求关联。本节翻译了所有分析的核心内容，详细的图表和扩展描述见原文 PDF 第 31-56 页。
|
||||
|
||||
---
|
||||
|
||||
## 6 结论
|
||||
|
||||
### 6.1 未来 AUTOSAR 版本中潜在的安全改进
|
||||
|
||||
本节总结通过本示例分析识别的潜在安全改进。
|
||||
|
||||
**改进建议**：
|
||||
|
||||
1. **AUTOSAR 模板的安全扩展**：
|
||||
- 在 ARXML 中更好地表达安全需求
|
||||
- 安全机制的形式化定义
|
||||
- 安全分析结果与 AUTOSAR 模型的集成
|
||||
|
||||
2. **安全分析工具支持**：
|
||||
- 自动生成安全需求
|
||||
- 验证 AUTOSAR 模型是否满足安全需求
|
||||
- 安全影响的仿真
|
||||
|
||||
3. **安全模式管理**：
|
||||
- 安全状态的标准化定义
|
||||
- 安全状态之间的转换规则
|
||||
- 安全模式与正常模式的交互
|
||||
|
||||
4. **端到端保护的改进**：
|
||||
- 更多 E2E 配置文件
|
||||
- 更好地集成到 RTE
|
||||
- 性能优化
|
||||
|
||||
5. **WdgM 的改进**：
|
||||
- 更好的配置工具
|
||||
- 与 ISO 26262 的清晰映射
|
||||
- 改进的诊断
|
||||
|
||||
6. **测试规范**：
|
||||
- 安全机制的测试用例
|
||||
- 故障注入测试
|
||||
- 性能测试
|
||||
|
||||
---
|
||||
|
||||
## 7 缩写/词汇表（Abbreviation/Glossary）
|
||||
|
||||
| 缩写 | 描述 |
|
||||
|---|---|
|
||||
| ASIL | Automotive Safety Integrity Level（汽车安全完整性等级） |
|
||||
| BCU | Body Control Unit（车身控制单元） |
|
||||
| BSW | Basic Software（基础软件） |
|
||||
| CAN | Controller Area Network（控制器局域网） |
|
||||
| CDD | Complex Device Driver（复杂设备驱动） |
|
||||
| CL15 | Clamp 15（点火开关信号） |
|
||||
| CRC | Cyclic Redundancy Check（循环冗余校验） |
|
||||
| DEM | Diagnostic Event Manager（诊断事件管理器） |
|
||||
| DIO | Digital Input/Output（数字输入/输出） |
|
||||
| E2E | End-to-End（端到端） |
|
||||
| ECU | Electronic Control Unit（电子控制单元） |
|
||||
| EcuM | ECU State Manager（ECU 状态管理器） |
|
||||
| FMEA | Failure Mode and Effects Analysis（失效模式与影响分析） |
|
||||
| FTTI | Fault Tolerant Time Interval（故障容错时间间隔） |
|
||||
| FLM | Front Light Management（前照灯管理） |
|
||||
| HMI | Human-Machine Interface（人机界面） |
|
||||
| LB | Low Beam（近光灯） |
|
||||
| LS | Light Switch（灯光开关） |
|
||||
| MPU | Memory Protection Unit（内存保护单元） |
|
||||
| OEM | Original Equipment Manufacturer（原始设备制造商） |
|
||||
| OS | Operating System（操作系统） |
|
||||
| PWM | Pulse Width Modulation（脉宽调制） |
|
||||
| RTE | Runtime Environment（运行时环境） |
|
||||
| SG | Safety Goal（安全目标） |
|
||||
| SPI | Serial Peripheral Interface（串行外设接口） |
|
||||
| SWC | Software Component（软件组件） |
|
||||
| WdgM | Watchdog Manager（看门狗管理器） |
|
||||
|
||||
---
|
||||
|
||||
## 8 参考文献（References）
|
||||
|
||||
[1] ISO 26262:2011(E) — Road vehicles — Functional safety
|
||||
[2] AUTOSAR_EXP_LayeredSoftwareArchitecture — AUTOSAR 分层软件架构
|
||||
[3] AUTOSAR_SWS_WatchdogManager — 看门狗管理器规范
|
||||
[4] AUTOSAR_SWS_E2ELibrary — 端到端保护库
|
||||
[5] AUTOSAR_SWS_COM — 通信规范
|
||||
[6] AUTOSAR_SWS_RTE — 运行时环境
|
||||
[7] AUTOSAR_SWS_OS — 操作系统
|
||||
[8] AUTOSAR_SWS_DEM — 诊断事件管理器
|
||||
[9] AUTOSAR_TPS_SafetyExtensions — 安全扩展
|
||||
|
||||
---
|
||||
|
||||
## 翻译说明
|
||||
|
||||
本文档为 AUTOSAR EXP SafetyUseCase（文档 ID 641，61 页，4.4.0 版）的中文翻译。翻译策略：
|
||||
|
||||
1. **完整翻译**：封面、文档标识、变更历史、目录、所有主要章节（第 1-7 章）
|
||||
2. **核心分析方法涵盖**：
|
||||
- **项目描述**：前照灯管理（FLM）功能、初步架构、假设和限制
|
||||
- **危险分析与风险评估**：H1 危险、SG01 安全目标、ASIL B 等级、FTTI 500ms
|
||||
- **功能安全概念**：FunSafReq01-01/02/03
|
||||
- **系统安全需求**：SysSafReq01-13
|
||||
- **降级概念**：2 步降级（日间行车灯作为回退）
|
||||
- **ECU 级安全概念**：EcuSafReq01-10
|
||||
- **23 个 ECU 软件分析**：涵盖所有 ECU 的故障分析和缓解措施
|
||||
3. **关键概念涵盖**：
|
||||
- ASIL 等级（A、B、C、D）
|
||||
- FTTI（故障容错时间）
|
||||
- 安全状态、降级模式
|
||||
- E2E 保护、WdgM 监督
|
||||
4. **摘要处理**：
|
||||
- 系统安全需求映射表（表 3）：列出前 6 项代表性映射，完整表见原文 PDF
|
||||
- 23 个 ECU 分析：保留核心内容，详细图表见原文 PDF
|
||||
5. **保留内容**：所有需求 ID（`FunSafReq`、`SysSafReq`、`EcuSafReq`、`ECU02-30`）、ASIL 等级引用、ISO 26262 引用
|
||||
|
||||
本文档为安全工程师提供了一个完整的安全分析案例研究，展示了如何将 ISO 26262 的方法论应用于 AUTOSAR 系统。
|
||||
@@ -0,0 +1,498 @@
|
||||
# 安全扩展需求（Requirements on Safety Extensions）
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **文档标题** | 安全扩展需求（Requirements on Safety Extensions） |
|
||||
| **文档所有者** | AUTOSAR |
|
||||
| **文档责任方** | AUTOSAR |
|
||||
| **文档标识号** | 670 |
|
||||
| **文档状态** | Final（正式发布） |
|
||||
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
|
||||
| **所属标准版本** | 4.4.0 |
|
||||
|
||||
---
|
||||
|
||||
## 文档变更历史（Document Change History）
|
||||
|
||||
| 日期 | 版本 | 变更人 | 变更描述 |
|
||||
|---|---|---|---|
|
||||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 |
|
||||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation |
|
||||
| 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 | 基于概念"Safety Extensions"的初始发布 |
|
||||
|
||||
---
|
||||
|
||||
## 目录（Table of Contents）
|
||||
|
||||
1. [引言](#1-引言)
|
||||
- 1.1 [范围](#11-范围)
|
||||
- 1.2 [文档约定](#12-文档约定)
|
||||
- 1.3 [指南](#13-指南)
|
||||
2. [用例追踪](#2-用例追踪)
|
||||
3. [需求追踪](#3-需求追踪)
|
||||
4. [需求](#4-需求)
|
||||
- 4.1 [安全需求](#41-安全需求)
|
||||
- 4.2 [安全完整性等级](#42-安全完整性等级)
|
||||
- 4.3 [安全措施与安全机制](#43-安全措施与安全机制)
|
||||
- 4.4 [可追溯性与分配](#44-可追溯性与分配)
|
||||
- 4.5 [方法论与使用](#45-方法论与使用)
|
||||
5. [支持的用例](#5-支持的用例)
|
||||
|
||||
---
|
||||
|
||||
## 参考文献
|
||||
|
||||
- **[1]** ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition
|
||||
http://www.iso.org
|
||||
- **[2]** Specifications of Safety Extensions
|
||||
`AUTOSAR_TPS_SafetyExtensions`
|
||||
- **[3]** Standardization Template
|
||||
`AUTOSAR_TPS_StandardizationTemplate`
|
||||
- **[4]** Requirements on AUTOSAR Features
|
||||
`AUTOSAR_RS_Features`
|
||||
- **[5]** Methodology
|
||||
`AUTOSAR_TR_Methodology`
|
||||
|
||||
---
|
||||
|
||||
## 1 引言
|
||||
|
||||
### 1.1 范围
|
||||
|
||||
本文档收集了对 AUTOSAR 模型安全方面的需求，以及将其纳入 AUTOSAR 模板的要求。
|
||||
|
||||
安全扩展（Safety Extensions）的主要目标是支持作为 AUTOSAR 模板一部分的 AUTOSAR 系统的安全相关信息交换。这将为安全需求到 AUTOSAR 元素、安全措施和 AUTOSAR 安全机制的可追溯性奠定基础。它还将确保在系统设计、实现和配置期间可获得 AUTOSAR 元素的适当安全完整性等级（Safety Integrity Levels），并且它们可以作为约束检查的对象。
|
||||
|
||||
在本文档的上下文中，**功能安全机制**（functional safety mechanisms）是具体的产品部件，例如内存保护。它们被视为功能安全措施（functional safety measures）的专门化，后还包括流程步骤，例如评审。此定义与 ISO 26262-1 [1] 中给出的这些术语的定义一致。
|
||||
|
||||
本文档中收集的需求将由 AUTOSAR 安全扩展规范 [2] 来满足。
|
||||
|
||||
### 1.2 文档约定
|
||||
|
||||
AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中指定的表，参见标准化模板的"Support for Traceability"章节（[3]）。
|
||||
|
||||
应使用 [TPS_STDT_00053] 中指定的义务表达的口头形式来表示需求，参见标准化模板的"Support for Traceability"章节（[3]）。
|
||||
|
||||
### 1.3 指南
|
||||
|
||||
应引用现有的规范（以单一需求的形式）。与这些规范的差异被指定为附加需求。所有需求应具有以下属性：
|
||||
|
||||
- **冗余性（Redundancy）**：需求不应在一个需求内或其他需求中重复。
|
||||
- **清晰性（Clearness）**：所有需求应仅允许一种解释的可能性。使用的未在词汇表中的技术术语必须定义。
|
||||
- **原子性（Atomicity）**：每个需求应仅包含一个需求。如果需求不能进一步拆分为更多需求，则该需求是原子的。
|
||||
- **可测试性（Testability）**：需求应通过分析、评审或测试进行测试。
|
||||
- **可追溯性（Traceability）**：在任何时候都应可见需求的来源和状态。
|
||||
|
||||
---
|
||||
|
||||
## 2 用例追踪
|
||||
|
||||
下表引用第 5 章中指定的用例，并将其链接到相关需求。
|
||||
|
||||
> **翻译说明**：原文档的"Use Case Tracing"表较长，包含约 8 个用例，每个用例链接到多个需求（`RS_SAFEX_xxxxx`）。下表列出每个用例的代表性需求映射；完整表请参见原文 PDF 第 9-11 页。
|
||||
|
||||
| 用例 | 描述 | 由以下需求满足 |
|
||||
|---|---|---|
|
||||
| **[UC_SAFEX_00001]** | 在 AUTOSAR 系统的分布式开发中交换安全信息 | `RS_SAFEX_00001` ~ `RS_SAFEX_00024`（完整集合） |
|
||||
| **[UC_SAFEX_00002]** | 在 AUTOSAR 中管理安全需求 | `RS_SAFEX_00001` ~ `RS_SAFEX_00010` |
|
||||
| **[UC_SAFEX_00003]** | ASIL 约束检查 | `RS_SAFEX_00008`、`RS_SAFEX_00010`、`RS_SAFEX_00011`、`RS_SAFEX_00012`、`RS_SAFEX_00013`、`RS_SAFEX_00014`、`RS_SAFEX_00018`、`RS_SAFEX_00022` |
|
||||
| **[UC_SAFEX_00004]** | AUTOSAR SEooC 开发 | `RS_SAFEX_00001` ~ `RS_SAFEX_00024`（完整集合） |
|
||||
| **[UC_SAFEX_00005]** | 为 AUTOSAR 系统提供安全文档 | `RS_SAFEX_00001` ~ `RS_SAFEX_00024`（完整集合） |
|
||||
| **[UC_SAFEX_00006]** | 为 AUTOSAR 系统提供适当的安全机制 | `RS_SAFEX_00008`、`RS_SAFEX_00009`、`RS_SAFEX_00010`、`RS_SAFEX_00011`、`RS_SAFEX_00012`、`RS_SAFEX_00013`、`RS_SAFEX_00014`、`RS_SAFEX_00015`、`RS_SAFEX_00016`、`RS_SAFEX_00017`、`RS_SAFEX_00018`、`RS_SAFEX_00022`、`RS_SAFEX_00023` |
|
||||
| **[UC_SAFEX_00007]** | 观察应用的 ASIL 分解产生的约束 | `RS_SAFEX_00008`、`RS_SAFEX_00009` |
|
||||
| **[UC_SAFEX_00008]** | 获取 AUTOSAR 元素的 ASIL 信息 | `RS_SAFEX_00011` |
|
||||
|
||||
---
|
||||
|
||||
## 3 需求追踪
|
||||
|
||||
下表引用 [4] 中指定的需求，并将其链接到这些需求的实现。
|
||||
|
||||
| 需求 | 描述 | 由以下需求满足 |
|
||||
|---|---|---|
|
||||
| **[RS_BRF_02068]** | AUTOSAR 方法论应允许将安全属性分配给模型元素 | `RS_SAFEX_00001`、`RS_SAFEX_00002`、`RS_SAFEX_00003`、`RS_SAFEX_00004`、`RS_SAFEX_00005`、`RS_SAFEX_00006`、`RS_SAFEX_00007`、`RS_SAFEX_00008`、`RS_SAFEX_00009`、`RS_SAFEX_00010`、`RS_SAFEX_00011`、`RS_SAFEX_00012`、`RS_SAFEX_00013`、`RS_SAFEX_00014`、`RS_SAFEX_00015`、`RS_SAFEX_00016`、`RS_SAFEX_00017`、`RS_SAFEX_00018`、`RS_SAFEX_00020`、`RS_SAFEX_00021`、`RS_SAFEX_00022`、`RS_SAFEX_00023`、`RS_SAFEX_00024` |
|
||||
|
||||
---
|
||||
|
||||
## 4 需求
|
||||
|
||||
本章描述了驱动安全扩展规范 [2] 定义工作的所有需求。
|
||||
|
||||
### 4.1 安全需求
|
||||
|
||||
#### [RS_SAFEX_00001] AUTOSAR 模型中可表达的安全需求
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 安全需求应通过 AUTOSAR 元模型在 AUTOSAR 模型和文档中表达。 |
|
||||
| **基本原理** | AUTOSAR 中所有需求（包括安全需求）及其规范项的一致规范和表示。 |
|
||||
| **用例** | [UC_SAFEX_00002]、[UC_SAFEX_00001] |
|
||||
| **依赖性** | – |
|
||||
| **支持材料** | 参见 ISO 26262-8 [1]。 |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00002] 安全需求至少与其他需求一样具有表达力
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 安全需求至少应能够携带与 AUTOSAR 中其他需求相同种类的信息。此外，遵循 ISO 26262-8 中对需求管理的要求，参见 [1]。 |
|
||||
| **基本原理** | 像 ISO 26262 [1] 这样的安全标准定义了对安全需求定义的最低要求。此外，在 AUTOSAR 中使用类似结构对安全和非安全需求进行协调定义是可取的。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] |
|
||||
| **依赖性** | [RS_SAFEX_00001] |
|
||||
| **支持材料** | – |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00003] 通过 URI 描述的安全需求
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 应可以通过 URI 将 AUTOSAR 模型内的安全需求定义与该 AUTOSAR 模型外部的需求规范相关联。 |
|
||||
| **基本原理** | 实践中使用了多种需求交换的技术方法。这包括需求交换格式（ReqIF）或基于专有工具的交换。通过通过 URI 引用外部需求定义的可能性，可以在 AUTOSAR 模型中建立可追溯性，同时避免数据复制及其典型的负面影响。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] |
|
||||
| **依赖性** | [RS_SAFEX_00001] |
|
||||
| **支持材料** | – |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00004] 可区分的安全需求
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 安全需求应可与 AUTOSAR 模型中的其他需求区分开来。 |
|
||||
| **基本原理** | 安全标准的规则仅适用于安全需求。例如，这适用于可追溯性或 ASIL 相关措施或约束。因此，有必要明确标识安全需求。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] |
|
||||
| **依赖性** | [RS_SAFEX_00001] |
|
||||
| **支持材料** | 参见 ISO 26262-8 [1]。 |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00005] 安全需求的唯一标识
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 安全需求应具有唯一标识。 |
|
||||
| **基本原理** | 这是满足安全标准要求的必要条件。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] |
|
||||
| **依赖性** | [RS_SAFEX_00001] |
|
||||
| **支持材料** | 参见 ISO 26262-8 [1]。 |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00006] 安全需求的状态信息
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 应可以指定安全需求的状态。 |
|
||||
| **基本原理** | 这是满足安全标准要求的必要条件。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00004] |
|
||||
| **依赖性** | [RS_SAFEX_00001] |
|
||||
| **支持材料** | 参见 ISO 26262-8 [1]。 |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00007] 安全需求的层次结构
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 应可以指定安全需求的层次结构。 |
|
||||
| **基本原理** | 这是满足安全标准要求的必要条件。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002] |
|
||||
| **依赖性** | [RS_SAFEX_00001] |
|
||||
| **支持材料** | 参见 ISO 26262-8 [1]。 |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00008] 安全需求的分解
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 应可以将安全需求分解为两个独立的安全需求。 |
|
||||
| **基本原理** | ASIL 分解是 ISO 26262 中提供的概念，通过将安全需求拆分为独立的安全需求来降低安全需求的 ASIL。ASIL 分解也应可用于 AUTOSAR 系统。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00007] |
|
||||
| **依赖性** | [RS_SAFEX_00010]、[RS_SAFEX_00001] |
|
||||
| **支持材料** | 参见 ISO 26262-9 [1] |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00009] 独立性需求的规范
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 应可以指定作为特殊安全需求的独立性需求，并将其与安全需求的分解相关联。 |
|
||||
| **基本原理** | 仅当可以确保具有较低 ASIL 的所得安全需求的独立性时，才允许 ASIL 分解。这导致对独立性的要求，这些要求显然与分解相关。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00007] |
|
||||
| **依赖性** | [RS_SAFEX_00001]、[RS_SAFEX_00008] |
|
||||
| **支持材料** | 参见 ISO 26262-9 [1] |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
### 4.2 安全完整性等级
|
||||
|
||||
#### [RS_SAFEX_00010] 安全需求的 ASIL 属性
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 应可以为安全需求指定 ASIL 属性。属性的值应至少以明确的方式携带 ISO 26262 中列出的可能 ASIL 值。 |
|
||||
| **基本原理** | 确保系统功能安全所需的必要措施取决于适用的 ASIL。ASIL 到系统元素的分配通过安全需求完成。未能遵守 ASIL 可能导致不安全的系统。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00008] |
|
||||
| **依赖性** | [RS_SAFEX_00001] |
|
||||
| **支持材料** | 参见 ISO 26262-3 [1] |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00011] AUTOSAR 元素的 ASIL 属性
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 应可以为作为 AUTOSAR 模型一部分的任何 AUTOSAR 元素指定 ASIL 属性。属性的值应至少以明确的方式携带 ISO 26262 中列出的可能 ASIL 值。 |
|
||||
| **基本原理** | 这允许在安全需求和 AUTOSAR 元素之间交叉检查 ASIL 值。例如，这对于使用上下文外安全元素方法（SEooC）非常重要，参见 ISO 26262-10 [1]。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00008] |
|
||||
| **依赖性** | – |
|
||||
| **支持材料** | 参见 ISO 26262-4 和 ISO 26262-6 [1] |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
### 4.3 安全措施与安全机制
|
||||
|
||||
#### [RS_SAFEX_00015] AUTOSAR 模型中可表达的安全措施
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 安全措施应在 AUTOSAR 模型中可表达。 |
|
||||
| **基本原理** | AUTOSAR 提供了许多安全机制。它们应与 AUTOSAR 模型中的安全需求相关联，以证明安全需求的正确实现。此外，能够处理 AUTOSAR 外部但对 AUTOSAR 系统很重要的安全措施也很重要。通过对安全措施进行建模，它可以用作 AUTOSAR 模型中可追溯性的代理和终点。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00006] |
|
||||
| **依赖性** | – |
|
||||
| **支持材料** | – |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00016] 安全措施的文本描述
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 安全措施应至少具有文本描述。 |
|
||||
| **基本原理** | 文本描述提供了一种非正式的方式来描述安全措施。未来可能会定义其他形式属性。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00005]、[UC_SAFEX_00006] |
|
||||
| **依赖性** | [RS_SAFEX_00015] |
|
||||
| **支持材料** | – |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00017] 安全措施的唯一标识
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 安全措施应具有唯一标识。 |
|
||||
| **基本原理** | 安全措施是可追溯到安全需求的对象。没有唯一标识符，不可能建立这种可追溯性。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00005]、[UC_SAFEX_00006] |
|
||||
| **依赖性** | [RS_SAFEX_00015] |
|
||||
| **支持材料** | – |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00023] 作为特殊安全措施的安全机制
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 安全机制应在 AUTOSAR 模型中作为安全措施的专门化来表达。 |
|
||||
| **基本原理** | ISO 26262 区分了安全措施和安全机制，其中安全措施包括安全机制。该术语应反映在安全扩展中。（参见 ISO 26262-1，第 1.110 条 [1]） |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00005]、[UC_SAFEX_00006] |
|
||||
| **依赖性** | [RS_SAFEX_00015] |
|
||||
| **支持材料** | – |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00018] 安全需求和安全措施之间的关系
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 应可以将安全需求与安全措施相关联。这样的关系应可与 AUTOSAR 模型中的任何其他关系明确区分开来。 |
|
||||
| **基本原理** | 为了证明系统安全，显式建模安全需求和安全措施之间的关系是有利的。这简化了文档编制并支持一致性检查（例如观察适用的 ASIL 相关规则）。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00006]、[UC_SAFEX_00005]、[UC_SAFEX_00004] |
|
||||
| **依赖性** | [RS_SAFEX_00015]、[RS_SAFEX_00001] |
|
||||
| **支持材料** | – |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
### 4.4 可追溯性与分配
|
||||
|
||||
#### [RS_SAFEX_00012] 安全需求的可追溯性
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 安全需求应根据 ISO 26262 [1] 可追溯。 |
|
||||
| **基本原理** | 安全需求的可追溯性是像 ISO 26262 [1] 这样的安全标准的主要要求。直接在 AUTOSAR 模型中建立可追溯性可提高一致性并减少工作量。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00005] |
|
||||
| **依赖性** | [RS_SAFEX_00001] |
|
||||
| **支持材料** | 参见 ISO 26262-8 [1] |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00013] 安全措施的可追溯性
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 安全措施应根据 ISO 26262 [1] 可追溯。 |
|
||||
| **基本原理** | 可追溯性是安全标准的主要要求（参见 ISO 26262-8 第 6.4.3.2 条 [1]）。安全措施是支持安全需求实现的活动或技术解决方案，包括 AUTOSAR 提供的安全机制。直接在 AUTOSAR 模型中建立可追溯性可提高一致性并减少提供安全文档的工作量。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00004]、[UC_SAFEX_00005] |
|
||||
| **依赖性** | [RS_SAFEX_00015] |
|
||||
| **支持材料** | – |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00014] 安全需求的分配
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 应可以将技术安全需求分配给 AUTOSAR 模型的元素。这样的分配应可与 AUTOSAR 模型中的其他关系区分开来。 |
|
||||
| **基本原理** | 所有安全需求必须分配给硬件、软件或两者。那些要由 AUTOSAR 系统实现的安全需求应分配给相应的 AUTOSAR 元素。这是例如检查有关 ASIL 的约束或执行适当的安全分析的基础。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00002]、[UC_SAFEX_00005] |
|
||||
| **依赖性** | [RS_SAFEX_00001] |
|
||||
| **支持材料** | 参见 ISO 26262-4 和 ISO 26262-6 [1] |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00022] 安全措施的分配
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 应可以将安全措施分配给 AUTOSAR 模型的元素。这样的分配应可与 AUTOSAR 模型中的其他关系区分开来。 |
|
||||
| **基本原理** | 安全措施信息元素描述了可由 AUTOSAR 系统实现的安全措施（例如 AUTOSAR 安全机制，如 E2E 通信保护）。在这种情况下，有必要将实现安全措施的 AUTOSAR 元素与安全措施信息元素相关联。这种关系的存在将简化所需的验证过程（与安全措施相关的安全需求），并支持约束检查（例如 ASIL 义务）。 |
|
||||
| **用例** | [UC_SAFEX_00001]、[UC_SAFEX_00005] |
|
||||
| **依赖性** | [RS_SAFEX_00015] |
|
||||
| **支持材料** | 参见 ISO 26262-4 和 ISO 26262-6 [1] |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
### 4.5 方法论与使用
|
||||
|
||||
#### [RS_SAFEX_00024] AUTOSAR 方法论解释安全扩展的使用
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 安全扩展的使用应由 AUTOSAR 方法论解释。 |
|
||||
| **基本原理** | 安全扩展可以促进通常在 AUTOSAR 系统开发期间执行的许多活动。AUTOSAR 方法论描述了这些活动。如果现有活动需要执行安全信息，或需要新的活动或任务来消费或生成安全信息，则应由方法论解释。 |
|
||||
| **用例** | – |
|
||||
| **依赖性** | [5] |
|
||||
| **支持材料** | – |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00020] 安全扩展不破坏 AUTOSAR 模型处理
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 使用安全扩展不应破坏现有 AUTOSAR 模型的处理。 |
|
||||
| **基本原理** | 安全扩展作为可与现有模型一起使用的扩展提供。这确保了向后兼容性。对于某些生成目的，可能不需要将安全扩展包含到生成过程中以节省资源。 |
|
||||
| **用例** | – |
|
||||
| **依赖性** | – |
|
||||
| **支持材料** | – |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
#### [RS_SAFEX_00021] 用于现有 AUTOSAR 模型的安全扩展
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **类型** | valid |
|
||||
| **描述** | 应可以为现有 AUTOSAR 模型指定安全扩展。 |
|
||||
| **基本原理** | 由于许多 AUTOSAR 系统与安全相关，这将允许通过安全扩展扩展现有 AUTOSAR 模型。 |
|
||||
| **用例** | – |
|
||||
| **依赖性** | – |
|
||||
| **支持材料** | – |
|
||||
|
||||
c(`RS_BRF_02068`)
|
||||
|
||||
---
|
||||
|
||||
## 5 支持的用例
|
||||
|
||||
### [UC_SAFEX_00001] 在 AUTOSAR 系统的分布式开发中交换安全信息
|
||||
|
||||
分布式开发是 AUTOSAR 系统的典型特征。对于最终系统（项目），必须证明其满足功能安全的需求。
|
||||
|
||||
与 AUTOSAR 系统相关的安全需求作为 AUTOSAR 模型的一部分在参与分布式开发的组织之间交换。安全需求还包含 ASIL 属性以及它们到 AUTOSAR 元素的明确分配。确保安全相关信息不会丢失。适当时建立可追溯性。最后，AUTOSAR 模型中包含许多用于系统安全文档的信息，并且可以加以利用。
|
||||
|
||||
c()
|
||||
|
||||
### [UC_SAFEX_00002] 在 AUTOSAR 中管理安全需求
|
||||
|
||||
在 AUTOSAR 中，所有需求都以唯一 ID 在需求文档（RS/Feature/SRS）中正式捕获。规范文档（SWS）包含正式追溯到需求的形式规范项。同一级别的需求之间的依赖关系通过提供对相关需求的引用在需求块本身中表达。安全需求（可能包括安全目标）被捕获在单独的安全需求文档中或与同一文档中的其他需求一起捕获。在两种情况下，在这些安全需求与安全相关的规范元素之间建立可追溯性。
|
||||
|
||||
c()
|
||||
|
||||
### [UC_SAFEX_00003] ASIL 约束检查
|
||||
|
||||
AUTOSAR 元素的 ASIL（即用于它们的开发）必须与为这些元素分配的安全需求的 ASIL 匹配。匹配意味着元素的 ASIL 等于或高于所分配的安全需求的 ASIL。在 AUTOSAR 模型中拥有所有信息（安全需求、ASIL、分配），可以执行约束检查以查找无效的分配。这在分布式开发或要集成现有组件的上下文中特别有用。
|
||||
|
||||
c()
|
||||
|
||||
### [UC_SAFEX_00004] AUTOSAR SEooC 开发
|
||||
|
||||
根据 ISO 26262-10（[1]），上下文外安全元素（Safety Element out of Context, SEooC）的开发特征在于对 SEooC 环境的假设是在不知道 SEooC 所集成到的实际上下文（项目）的情况下做出的。这样的 SEooC 的开发人员将以安全需求的形式提供假设，并附带适当的 ASIL 和 AUTOSAR 模型中的状态信息。此外，将描述并提供安全措施 / 安全机制。集成商将利用这些信息执行 SEooC 所嵌入的环境满足假设的分析。同样，可追溯性、分配和映射关系在 AUTOSAR 模型中使用。
|
||||
|
||||
c()
|
||||
|
||||
### [UC_SAFEX_00005] 为 AUTOSAR 系统提供安全文档
|
||||
|
||||
OEM 可以使用 AUTOSAR 系统的 AUTOSAR 模型，并提取模型中关于安全需求、安全措施、它们到 AUTOSAR 元素的分配以及安全需求和安全措施之间的映射的信息，以创建 ISO 26262-8（[1]）所要求的安全文档。
|
||||
|
||||
c()
|
||||
|
||||
### [UC_SAFEX_00006] 为 AUTOSAR 系统提供适当的安全机制
|
||||
|
||||
OEM 可以在系统级别指定对安全机制的要求。在 ECU 级别工作的供应商可以提供此类适当的安全机制并建立所需的可追溯性。同样可能的是，AUTOSAR 堆栈（BSW 组件）的供应商提供并描述供应商特定的安全机制。由于安全机制的信息作为 AUTOSAR 模型的一部分交换，因此可用于验证过程。
|
||||
|
||||
c()
|
||||
|
||||
### [UC_SAFEX_00007] 观察应用的 ASIL 分解产生的约束
|
||||
|
||||
OEM 在其技术安全概念中应用 ASIL 分解。这对预期系统的软件组件的独立性有影响。有关应用的分解以及独立性要求的信息都由供应商作为 AUTOSAR 模型的一部分提交。供应商能够满足独立性要求，因为它们是明确已知的，并且由于可追溯性，验证要容易得多。
|
||||
|
||||
c()
|
||||
|
||||
### [UC_SAFEX_00008] 获取 AUTOSAR 元素的 ASIL 信息
|
||||
|
||||
被要求实现软件组件的供应商需要知道该组件的 ASIL，以便应用适当的开发过程。此外，需要实现的安全需求应该是已知的。这两个信息都使用安全扩展作为 AUTOSAR 模型的一部分进行交换。
|
||||
|
||||
c()
|
||||
|
||||
---
|
||||
|
||||
## 翻译说明
|
||||
|
||||
- **翻译完整性**：本文档为 AUTOSAR 安全扩展需求（RS）的中文翻译版本，完整翻译了 1-5 章全部内容。
|
||||
- **保留的英文术语**：所有需求 ID（`RS_SAFEX_xxxxx`、`UC_SAFEX_xxxxx`、`RS_BRF_02068`、`TPS_STDT_xxxxx`）、模块缩写（OEM、ECU、BSW、E2E、SEooC）、安全标准引用（ISO 26262-1/3/4/6/8/9/10、ASIL）、AUTOSAR 方框符 `⌈⌋` 均按要求保留为英文。
|
||||
- **省略的内容**：免责声明（Disclaimer）按要求未翻译。
|
||||
- **关键概念**：
|
||||
- **安全扩展**（Safety Extensions）：AUTOSAR 模板的一部分，用于支持安全相关信息的交换和追溯。
|
||||
- **ASIL**（Automotive Safety Integrity Level，汽车安全完整性等级）：从 A 到 D 的等级，源自 ISO 26262。
|
||||
- **SEooC**（Safety Element out of Context，上下文外安全元素）：一种开发模式，安全元素在没有具体应用上下文的情况下开发。
|
||||
- **安全机制**（Safety Mechanisms）是**安全措施**（Safety Measures）的专门化。
|
||||
- **ASIL 分解**（ASIL Decomposition）：将高 ASIL 需求拆分为具有较低 ASIL 的独立需求。
|
||||
@@ -0,0 +1,381 @@
|
||||
# 看门狗驱动需求（Requirements on Watchdog Driver）
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **文档标题** | 看门狗驱动需求（Requirements on Watchdog Driver） |
|
||||
| **文档所有者** | AUTOSAR |
|
||||
| **文档责任方** | AUTOSAR |
|
||||
| **文档标识号** | 197 |
|
||||
| **文档状态** | Final（正式发布） |
|
||||
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
|
||||
| **所属标准版本** | 4.4.0 |
|
||||
|
||||
---
|
||||
|
||||
## 文档变更历史（Document Change History）
|
||||
|
||||
| 日期 | 版本 | 变更人 | 变更描述 |
|
||||
|---|---|---|---|
|
||||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 |
|
||||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation |
|
||||
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 新增第 5 章：需求追踪 |
|
||||
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性变更 |
|
||||
| 2013-10-31 | 4.1.2 | AUTOSAR Administration | ID 重命名；使用标准化模板；将 SRS 需求链接到新特性文档 |
|
||||
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 新增窗口看门狗概念需求 |
|
||||
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 法律声明修订 |
|
||||
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律声明修订 |
|
||||
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 扩展文档元信息；小幅布局调整 |
|
||||
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 修改"用户建议"；新增"修订信息" |
|
||||
| 2006-11-28 | 2.1 | AUTOSAR Administration | 法律声明修订 |
|
||||
| 2006-05-16 | 2.0 | AUTOSAR Administration | 作为独立文档发布。SRS SPAL V1.0.0 已被拆分为 15 个独立文档，以发布 2.0 |
|
||||
| 2005-05-31 | 1.0 | AUTOSAR Administration | 作为 SRS SPAL V1.0.0 的一部分初始发布 |
|
||||
|
||||
---
|
||||
|
||||
## 目录（Table of Contents）
|
||||
|
||||
1. [文档范围](#1-文档范围)
|
||||
2. [如何阅读本文档](#2-如何阅读本文档)
|
||||
- 2.1 [使用的约定](#21-使用的约定)
|
||||
- 2.2 [需求结构](#22-需求结构)
|
||||
3. [缩略语与缩写](#3-缩略语与缩写)
|
||||
4. [功能概述](#4-功能概述)
|
||||
- 4.1 [内部看门狗驱动](#41-内部看门狗驱动)
|
||||
- 4.2 [外部看门狗驱动](#42-外部看门狗驱动)
|
||||
5. [需求追踪](#5-需求追踪)
|
||||
6. [需求规范](#6-需求规范)
|
||||
- 6.1 [功能需求](#61-功能需求)
|
||||
- 6.2 [非功能需求](#62-非功能需求)
|
||||
7. [参考文献](#7-参考文献)
|
||||
- 7.1 [AUTOSAR 交付物](#71-autosar-交付物)
|
||||
- 7.2 [相关标准与规范](#72-相关标准与规范)
|
||||
|
||||
---
|
||||
|
||||
## 1 文档范围
|
||||
|
||||
本文档规定了看门狗驱动（Watchdog Driver）模块的需求。
|
||||
|
||||
### 约束
|
||||
|
||||
基础软件模块需求规范的首要范围是非安全相关系统。因此，安全需求被分配到中等优先级。
|
||||
|
||||
---
|
||||
|
||||
## 2 如何阅读本文档
|
||||
|
||||
每个需求都有其唯一的标识符，以 "BSW"（"Basic Software" 的缩写）前缀开头。对于任何审阅注释、评论或问题，请参考此唯一 ID 而不是章节或页码！
|
||||
|
||||
### 2.1 使用的约定
|
||||
|
||||
- AUTOSAR 文档中需求的表示遵循 [5] 中指定的表。
|
||||
- 在需求中，使用以下特定语义（取自互联网工程任务组 IETF 的征求意见稿 RFC 2119）。
|
||||
|
||||
本文件中使用的关键字 "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 需求结构
|
||||
|
||||
每个模块特定章节包含基础软件模块的简短功能描述。每章中相同类型的需求按以下标题分组（如果适用）：
|
||||
|
||||
**功能需求**：
|
||||
- 配置（模块的哪些元素需要可配置）
|
||||
- 初始化
|
||||
- 正常运行
|
||||
- 关闭操作
|
||||
- 故障操作
|
||||
- ...
|
||||
|
||||
**非功能需求**：
|
||||
- 时序需求
|
||||
- 资源使用
|
||||
- 可用性
|
||||
- 其他工作包的输出（例如描述模板、工具...）
|
||||
- ...
|
||||
|
||||
---
|
||||
|
||||
## 3 缩略语与缩写
|
||||
|
||||
具有局部作用域的缩略语和缩写不包含在 AUTOSAR 词汇表中。这些必须出现在本地词汇表中。
|
||||
|
||||
| 缩写 / 首字母缩略词 | 描述 |
|
||||
|---|---|
|
||||
| CS | Chip select（片选） |
|
||||
| DIO | Digital Input Output（数字输入输出） |
|
||||
| ECU | Electric Control Unit（电子控制单元） |
|
||||
| EOL | End Of Line（生产线末端），通常用于术语 "EOL Programming" 或 "EOL Configuration" |
|
||||
| HIS | Herstellerinitiative Software（德国汽车制造商软件标准化倡议） |
|
||||
| ICU | Interrupt Capture Unit（中断捕获单元） |
|
||||
| MAL | 旧名称为 Microcontroller Abstraction Layer（由 MCAL 取代，因为 'MAL' 在法语中意为 "bad"） |
|
||||
| MCAL | Microcontroller Abstraction Layer（微控制器抽象层） |
|
||||
| MCU | Microcontroller Unit（微控制器单元） |
|
||||
| MMU | Memory Management Unit（内存管理单元） |
|
||||
| Master | 控制其他设备（从设备，见下文）的设备 |
|
||||
| Slave | 完全由主设备控制的设备 |
|
||||
| NMI | Non maskable interrupt（不可屏蔽中断） |
|
||||
| OS | Operating System（操作系统） |
|
||||
| PLL | Phase Locked Loop（锁相环） |
|
||||
| PWM | Pulse Width Modulation（脉冲宽度调制） |
|
||||
| RX | Reception（接收，总线通信的上下文） |
|
||||
| SPAL | 该工作组的名称 |
|
||||
| SFR | Special Function Register（特殊功能寄存器） |
|
||||
| RTE | Runtime environment（运行时环境） |
|
||||
| WP | Work Package（工作包） |
|
||||
| STD | Standard（标准） |
|
||||
| REQ | Requirement（需求） |
|
||||
| UNINIT | Uninitialized（未初始化） |
|
||||
|
||||
由于这是专业人员的文档，因此所有其他术语都假定已知。
|
||||
|
||||
---
|
||||
|
||||
## 4 功能概述
|
||||
|
||||
### 4.1 内部看门狗驱动
|
||||
|
||||
内部看门狗驱动控制 MCU 的内部看门狗定时器。它提供触发功能和模式选择服务。
|
||||
|
||||
### 4.2 外部看门狗驱动
|
||||
|
||||
外部看门狗驱动控制外部硬件看门狗。它提供触发功能和模式选择服务。它与内部看门狗驱动具有相同的功能范围。
|
||||
|
||||
---
|
||||
|
||||
## 5 需求追踪
|
||||
|
||||
| 需求 | 描述 | 由以下需求满足 |
|
||||
|---|---|---|
|
||||
| `RS_BRF_01008` | AUTOSAR 应将硬件相关层组织为微控制器独立层和微控制器相关层 | `SRS_Wdg_12168` |
|
||||
| `RS_BRF_01136` | AUTOSAR 应支持在系统启动后解析已配置 BSW 数据的变体 | `SRS_Wdg_12105` |
|
||||
| `RS_BRF_01448` | AUTOSAR 服务应支持模式与状态管理 | `SRS_Wdg_12018` |
|
||||
| `RS_BRF_01464` | AUTOSAR 服务应支持看门狗的标准化处理 | `SRS_Wdg_12015`、`SRS_Wdg_12019`、`SRS_Wdg_12106`、`SRS_Wdg_13500` |
|
||||
| `RS_BRF_01912` | AUTOSAR 微控制器抽象应提供对 SPI 的访问 | `SRS_Wdg_12166` |
|
||||
| `RS_BRF_01936` | AUTOSAR 微控制器抽象应提供对 MCU 内部和外部硬件看门狗的访问 | `SRS_Wdg_12165`、`SRS_Wdg_12167` |
|
||||
|
||||
---
|
||||
|
||||
## 6 需求规范
|
||||
|
||||
### 6.1 功能需求
|
||||
|
||||
#### 6.1.1 内部看门狗驱动
|
||||
|
||||
##### 6.1.1.1 配置
|
||||
|
||||
###### 6.1.1.1.1 [SRS_Wdg_12015] 看门狗驱动应允许静态配置看门狗模式
|
||||
|
||||
> **类型**：Valid（有效）
|
||||
>
|
||||
> **描述**：看门狗驱动应允许静态配置看门狗模式。看门狗模式至少应包括所需的看门狗周期。可以添加任何 MCU 特定参数。
|
||||
> 进一步说明：每个看门狗模式具有相同的参数集，值会有所不同。
|
||||
>
|
||||
> **基本原理**：用于模式切换。
|
||||
>
|
||||
> **用例**：其他模式参数可以是：
|
||||
> - window / timeout 模式的选择
|
||||
> - 超时反应（reset 或 NMI）
|
||||
>
|
||||
> **依赖性**：[SRS_Wdg_12018] 看门狗模式选择服务
|
||||
>
|
||||
> **支持材料**：BMW 规范 MCAL V1.0a，REQ MAL31.1.2
|
||||
> （`RS_BRF_01464`）
|
||||
|
||||
##### 6.1.1.2 初始化
|
||||
|
||||
###### 6.1.1.2.1 [SRS_Wdg_12105] 看门狗驱动应提供允许选择静态配置的看门狗模式之一的初始化服务
|
||||
|
||||
> **类型**：Valid（有效）
|
||||
>
|
||||
> **描述**：看门狗驱动应提供允许选择静态配置的看门狗模式之一的初始化服务。
|
||||
>
|
||||
> **基本原理**：基本功能
|
||||
>
|
||||
> **用例**：--
|
||||
>
|
||||
> **依赖性**：--
|
||||
>
|
||||
> **支持材料**：--
|
||||
> （`RS_BRF_01136`）
|
||||
|
||||
###### 6.1.1.2.2 [SRS_Wdg_12106] 应不可能禁用看门狗
|
||||
|
||||
> **类型**：Valid（有效）
|
||||
>
|
||||
> **描述**：看门狗初始化服务和看门狗模式选择服务不得允许禁用看门狗。
|
||||
> 此需求仅适用于安全相关系统。因此，此功能应是静态可配置的（通过预处理器开关）。
|
||||
>
|
||||
> **基本原理**：避免在安全相关 ECU 中存在禁用看门狗的代码序列。
|
||||
>
|
||||
> **用例**：用于安全相关系统。
|
||||
>
|
||||
> **依赖性**：--
|
||||
>
|
||||
> **支持材料**：--
|
||||
> （`RS_BRF_01464`）
|
||||
|
||||
##### 6.1.1.3 正常运行
|
||||
|
||||
###### 6.1.1.3.1 [SRS_Wdg_12018] 看门狗驱动应提供选择看门狗模式的服务
|
||||
|
||||
> **类型**：Valid（有效）
|
||||
>
|
||||
> **描述**：看门狗驱动应提供选择看门狗模式的服务：
|
||||
> - Fast 模式（强制）
|
||||
> - Slow 模式（可选）
|
||||
> - Off（可选）
|
||||
>
|
||||
> **基本原理**：允许根据 ECU 状态调整看门狗行为。
|
||||
>
|
||||
> **用例**：允许为启动和运行模式切换不同的超时周期：
|
||||
> - ECU 启动模式：Slow 模式（长超时周期）
|
||||
> - ECU 运行模式：Fast 模式（短超时周期）
|
||||
>
|
||||
> **依赖性**：[SRS_Wdg_12015] 看门狗模式的配置
|
||||
>
|
||||
> **支持材料**：不要求每个微控制器提供所有模式。一些看门狗在设置后不允许模式更改。
|
||||
> （`RS_BRF_01448`）
|
||||
|
||||
###### 6.1.1.3.2 [SRS_Wdg_12019] 看门狗驱动应提供看门狗触发例程
|
||||
|
||||
> **类型**：Valid（有效）
|
||||
>
|
||||
> **描述**：看门狗驱动应提供看门狗触发例程。此例程应允许与看门狗设备进行数据交换（双向）。
|
||||
>
|
||||
> **基本原理**：基本功能
|
||||
>
|
||||
> **用例**：只要看门狗触发条件有效，此例程应重新触发看门狗以防止其过期。数据交换可用于提供密码机制的复杂看门狗（例如用于安全相关系统）。
|
||||
>
|
||||
> **依赖性**：--
|
||||
>
|
||||
> **支持材料**：窗口看门狗概念（Windowed Watchdog Concept）
|
||||
> （`RS_BRF_01464`）
|
||||
|
||||
###### 6.1.1.3.3 [SRS_Wdg_13500] 看门狗驱动应提供用于设置看门狗触发条件的服务
|
||||
|
||||
> **类型**：Valid（有效）
|
||||
>
|
||||
> **描述**：看门狗驱动应提供用于设置看门狗触发条件的服务。
|
||||
>
|
||||
> **基本原理**：基本功能
|
||||
>
|
||||
> **用例**：看门狗接口模块应使用此服务（重新）设置看门狗驱动的触发条件。
|
||||
>
|
||||
> **依赖性**：--
|
||||
>
|
||||
> **支持材料**：窗口看门狗概念（Windowed Watchdog Concept）
|
||||
> （`RS_BRF_01464`）
|
||||
|
||||
##### 6.1.1.4 关闭操作
|
||||
|
||||
由于安全原因以及大多数看门狗不允许停用，因此看门狗驱动不提供 Deinit 函数。因此，[SRS_SPAL_12163] 驱动模块反初始化对此模块无效。
|
||||
|
||||
#### 6.1.2 外部看门狗驱动
|
||||
|
||||
##### 6.1.2.1 通用
|
||||
|
||||
###### 6.1.2.1.1 [SRS_Wdg_12165] 对于外部看门狗驱动，应适用与内部看门狗驱动相同的需求
|
||||
|
||||
> **类型**：Valid（有效）
|
||||
>
|
||||
> **描述**：对于外部看门狗驱动，应适用与内部看门狗驱动相同的需求。
|
||||
>
|
||||
> **基本原理**：内部和外部看门狗之间没有功能差异。保持功能范围相同。
|
||||
>
|
||||
> **用例**：--
|
||||
>
|
||||
> **依赖性**：内部看门狗驱动的需求
|
||||
>
|
||||
> **支持材料**：--
|
||||
> （`RS_BRF_01936`）
|
||||
|
||||
##### 6.1.2.2 配置
|
||||
|
||||
###### 6.1.2.2.1 [SRS_Wdg_12166] 外部 SPI 看门狗的驱动应允许静态配置所需的 SPI 参数
|
||||
|
||||
> **类型**：Valid（有效）
|
||||
>
|
||||
> **描述**：外部 SPI 看门狗的驱动应允许静态配置所需的 SPI 参数。
|
||||
> 这些参数由 SPI Handler 规范指定。
|
||||
>
|
||||
> **基本原理**：SPI 访问的基本配置
|
||||
>
|
||||
> **用例**：在同一 SPI 总线上与其他 SPI 设备驱动一起使用 SPI 看门狗驱动。
|
||||
>
|
||||
> **依赖性**：--
|
||||
>
|
||||
> **支持材料**：AUTOSAR SWS SPI Handler
|
||||
> （`RS_BRF_01912`）
|
||||
|
||||
### 6.2 非功能需求
|
||||
|
||||
#### 6.2.1 外部看门狗驱动
|
||||
|
||||
##### 6.2.1.1 [SRS_Wdg_12167] 外部看门狗驱动应具有与内部看门狗驱动语义相同的 API
|
||||
|
||||
> **类型**：Valid（有效）
|
||||
>
|
||||
> **描述**：外部看门狗驱动应具有与内部看门狗驱动语义相同的 API。
|
||||
>
|
||||
> **基本原理**：便于通过看门狗管理器控制看门狗。保持内部和外部看门狗的处理相似。
|
||||
>
|
||||
> **用例**：将相同的看门狗管理器用于内部或外部看门狗驱动。
|
||||
>
|
||||
> **依赖性**：--
|
||||
>
|
||||
> **支持材料**：--
|
||||
> （`RS_BRF_01936`）
|
||||
|
||||
##### 6.2.1.2 [SRS_Wdg_12168] 外部看门狗驱动的源代码应独立于底层微控制器
|
||||
|
||||
> **类型**：Valid（有效）
|
||||
>
|
||||
> **描述**：外部看门狗驱动的源代码应独立于底层微控制器。
|
||||
>
|
||||
> **基本原理**：跨多个微控制器复用外部看门狗驱动
|
||||
>
|
||||
> **用例**：示例：使用标准化的 SPI Handler 接口，无需任何修改即可在 NEC V850 和 Renesas M16C 上使用相同的外部 SPI 看门狗设备驱动。
|
||||
>
|
||||
> **依赖性**：--
|
||||
>
|
||||
> **支持材料**：--
|
||||
> （`RS_BRF_01008`）
|
||||
|
||||
---
|
||||
|
||||
## 7 参考文献
|
||||
|
||||
### 7.1 AUTOSAR 交付物
|
||||
|
||||
- **[1]** List of Basic Software Modules
|
||||
`AUTOSAR_TR_BSWModuleList.pdf`
|
||||
- **[2]** Layered Software Architecture
|
||||
`AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf`
|
||||
- **[3]** General Requirements on Basic Software Modules
|
||||
`AUTOSAR_SRS_BSWGeneral.pdf`
|
||||
- **[4]** General Requirements on SPAL
|
||||
`AUTOSAR_SRS_SPALGeneral.pdf`
|
||||
- **[5]** Software Standardization Template
|
||||
`AUTOSAR_TPS_StandardizationTemplate.pdf`
|
||||
|
||||
### 7.2 相关标准与规范
|
||||
|
||||
不适用（NA）。
|
||||
|
||||
---
|
||||
|
||||
## 翻译说明
|
||||
|
||||
- **翻译完整性**：本文档为 AUTOSAR 看门狗驱动需求规范（SRS）的中文翻译版本，完整翻译了 1-7 章全部内容。
|
||||
- **保留的英文术语**：所有需求 ID（`SRS_Wdg_xxxxx`、`RS_BRF_xxxxx`、`SRS_SPAL_xxxxx`）、模块缩写（MCAL、ECU、SPI、NMI、RTE、SPAL）、RFC 2119 关键字（MUST、SHALL 等）、AUTOSAR 方框符 `⌈⌋` 均按要求保留为英文。
|
||||
- **省略的内容**：免责声明（Disclaimer）按要求未翻译。
|
||||
- **关键概念**：
|
||||
- 内部看门狗驱动（MCAL 层）和外部看门狗驱动（板载设备抽象层）共享相同的功能范围和 API。
|
||||
- 三种看门狗模式：**Fast**（强制）、**Slow**（可选）、**Off**（可选）。
|
||||
- **Off 模式禁用**可静态配置，用于安全相关系统（避免 ECU 中存在禁用看门狗的代码序列）。
|
||||
- **窗口看门狗概念**（Windowed Watchdog Concept）用于支持更严格的时序约束。
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,538 @@
|
||||
# 看门狗接口规范（Specification of Watchdog Interface）
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **文档标题** | 看门狗接口规范（Specification of Watchdog Interface） |
|
||||
| **文档所有者** | AUTOSAR |
|
||||
| **文档责任方** | AUTOSAR |
|
||||
| **文档标识号** | 041 |
|
||||
| **文档状态** | Final（正式发布） |
|
||||
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
|
||||
| **所属标准版本** | 4.4.0 |
|
||||
|
||||
---
|
||||
|
||||
## 文档变更历史（Document Change History）
|
||||
|
||||
| 日期 | 版本 | 变更人 | 变更描述 |
|
||||
|---|---|---|---|
|
||||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 头文件清理；编辑性变更 |
|
||||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 重命名 —— 默认错误（default errors）更改为开发错误（development errors） |
|
||||
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation |
|
||||
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 细微修正 |
|
||||
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性变更 |
|
||||
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 编辑性变更；删除变更文档章节 |
|
||||
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 修复工件路径；根据新的 `SWS_BSWGeneral` 进行修订；需求采用新的索引方案 |
|
||||
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 修改 `DeviceIndex`；采用新模板并添加需求可追溯性 |
|
||||
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 更新模块版本检查；新增无效指针作为错误代码；检查空指针 |
|
||||
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 修改窗口看门狗概念；为 R4.0 进行进一步维护；法律声明修订 |
|
||||
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律声明修订 |
|
||||
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 总结变更的主要要点；第 8 章的表已被替换；内容从 AUTOSAR BSW 模型生成；扩展文档元信息；小幅布局调整 |
|
||||
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 第 5.1.2 节文件包含结构修改以符合 SPAL 通用包含结构；法律声明修订；新增发布说明；修改"用户建议"；新增"修订信息" |
|
||||
| 2006-05-16 | 2.0 | AUTOSAR Administration | 文档结构适配通用 Release 2.0 SWS 模板 |
|
||||
| 2005-05-31 | 1.0 | AUTOSAR Administration | 初始发布 |
|
||||
|
||||
---
|
||||
|
||||
## 目录（Table of Contents）
|
||||
|
||||
1. [引言与功能概述](#1-引言与功能概述)
|
||||
2. [缩略语与缩写](#2-缩略语与缩写)
|
||||
3. [相关文档](#3-相关文档)
|
||||
4. [约束与假设](#4-约束与假设)
|
||||
5. [与其他模块的依赖关系](#5-与其他模块的依赖关系)
|
||||
6. [需求可追溯性](#6-需求可追溯性)
|
||||
7. [功能规范](#7-功能规范)
|
||||
8. [API 规范](#8-api-规范)
|
||||
9. [序列图](#9-序列图)
|
||||
10. [配置规范](#10-配置规范)
|
||||
11. [不适用的需求](#11-不适用的需求)
|
||||
|
||||
---
|
||||
|
||||
## 1 引言与功能概述
|
||||
|
||||
本规范描述了 AUTOSAR 基础软件模块看门狗接口（Watchdog Interface）的功能、API 和配置。
|
||||
|
||||
当 ECU 上使用多个看门狗设备和看门狗驱动（例如内部软件看门狗和外部硬件看门狗）时，本模块允许看门狗管理器（或看门狗的任何其他客户端）选择正确的看门狗驱动 —— 从而选择正确的看门狗设备 —— 同时保留底层驱动的 API 和功能。
|
||||
|
||||
看门狗接口是板载设备抽象层（参见 [1]）的一部分。
|
||||
|
||||
> **[SWS_WdgIf_00026]** ⌈看门狗接口提供对底层看门狗驱动服务的统一访问，如模式切换和设置触发条件。⌋
|
||||
> （`SRS_Wdg_12165`、`SRS_Wdg_12167`、`SRS_MemHwAb_14019`）
|
||||
|
||||
---
|
||||
|
||||
## 2 缩略语与缩写
|
||||
|
||||
**注意**：本模块没有局部缩略语和缩写。所有使用的缩略语和缩写都应包含在 AUTOSAR 词汇表中。
|
||||
|
||||
---
|
||||
|
||||
## 3 相关文档
|
||||
|
||||
### 3.1 输入文档
|
||||
|
||||
- **[1]** Layered Software Architecture
|
||||
`AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf`
|
||||
- **[2]** General Requirements on Basic Software Modules
|
||||
`AUTOSAR_SRS_BSWGeneral.pdf`
|
||||
- **[3]** General Requirements on SPAL
|
||||
`AUTOSAR_SRS_SPALGeneral.pdf`
|
||||
- **[4]** Requirements on Memory Hardware Abstraction Layer
|
||||
`AUTOSAR_SRS_MemoryHWAbstractionLayer.pdf`
|
||||
- **[5]** Specification of Watchdog Driver
|
||||
`AUTOSAR_SWS_WatchdogDriver.pdf`
|
||||
- **[6]** Specification of Default Error Tracer
|
||||
`AUTOSAR_SWS_DefaultErrorTracer.pdf`
|
||||
- **[7]** Basic Software Module Description Template
|
||||
`AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf`
|
||||
- **[8]** AUTOSAR Requirements on Watchdog Driver
|
||||
`AUTOSAR_SRS_WatchdogDriver.pdf`
|
||||
- **[9]** General Specification of Basic Software Modules
|
||||
`AUTOSAR_SWS_BSWGeneral.pdf`
|
||||
|
||||
### 3.2 相关标准与规范
|
||||
|
||||
无。
|
||||
|
||||
### 3.3 相关规范
|
||||
|
||||
AUTOSAR 提供了关于基础软件模块的通用规范 [9]（SWS BSW General），该规范对看门狗接口同样有效。
|
||||
|
||||
因此，SWS BSW General 应被视为看门狗接口的附加且必需的规范。
|
||||
|
||||
---
|
||||
|
||||
## 4 约束与假设
|
||||
|
||||
### 4.1 限制
|
||||
|
||||
无限制。
|
||||
|
||||
### 4.2 对汽车领域的适用性
|
||||
|
||||
无限制。
|
||||
|
||||
---
|
||||
|
||||
## 5 与其他模块的依赖关系
|
||||
|
||||
看门狗接口是 ECU 抽象层的一部分。它允许上层（特别是看门狗管理器）统一访问一个或多个看门狗驱动。因此，看门狗接口的实现依赖于下层看门狗驱动的数量。
|
||||
|
||||
### 5.1 文件结构
|
||||
|
||||
#### 5.1.1 代码文件结构
|
||||
|
||||
有关详细信息，请参阅 `SWS_BSWGeneral` 第 5.1.6 节"Code file structure"。
|
||||
|
||||
#### 5.1.2 版本检查
|
||||
|
||||
有关详细信息，请参阅 `SWS_BSWGeneral` 第 5.1.8 节"Version Check"。
|
||||
|
||||
---
|
||||
|
||||
## 6 需求可追溯性
|
||||
|
||||
> **翻译说明**：本节包含一个大型参考表，将 SRS 需求映射到 SWS 需求。下表列出代表性映射条目；完整表（包含约 70+ 项映射）请参见原文 PDF 第 11-16 页。
|
||||
|
||||
| 需求 | 描述 | 由以下需求满足 |
|
||||
|---|---|---|
|
||||
| `SRS_BSW_00005` | 微控制器抽象层（MCAL）的模块不得有硬编码的水平接口 | `SWS_WdgIf_00999` |
|
||||
| `SRS_BSW_00007` | 用 C 语言编写的所有基础软件模块应符合 MISRA C 2012 标准 | `SWS_WdgIf_00999` |
|
||||
| `SRS_BSW_00009` | 所有基础软件模块应按照通用标准进行文档化 | `SWS_WdgIf_00999` |
|
||||
| `SRS_BSW_00010` | 应为所有支持平台上定义的配置文档化所有基础软件模块的内存消耗 | `SWS_WdgIf_00999` |
|
||||
| `SRS_BSW_00101` | 基础软件模块应能在单独的初始化函数中初始化变量和硬件 | `SWS_WdgIf_00999` |
|
||||
| `SRS_BSW_00159` | AUTOSAR 基础软件的所有模块应支持基于工具的配置 | `SWS_WdgIf_00999` |
|
||||
| `SRS_BSW_00161` | AUTOSAR 基础软件应提供微控制器抽象层 | `SWS_WdgIf_00999` |
|
||||
| `SRS_BSW_00162` | AUTOSAR 基础软件应提供硬件抽象层 | `SWS_WdgIf_00999` |
|
||||
| `SRS_BSW_00164` | 中断服务例程的实现应由操作系统、复杂驱动或模块完成 | `SWS_WdgIf_00999` |
|
||||
| `SRS_BSW_00168` | SW 组件应由基础软件中通用 API 中定义的函数进行测试 | `SWS_WdgIf_00999` |
|
||||
| `SRS_BSW_00300` | 所有 AUTOSAR 基础软件模块应由明确的名称标识 | `SWS_WdgIf_00999` |
|
||||
| `SRS_BSW_00301` | 所有 AUTOSAR 基础软件模块应仅导入必要的信息 | `SWS_WdgIf_00041` |
|
||||
| `SRS_BSW_00304` | 所有 AUTOSAR 基础软件模块应使用标准数据类型而非原生 C 数据类型 | `SWS_WdgIf_00013`、`SWS_WdgIf_00030`、`SWS_WdgIf_00999` |
|
||||
| `SRS_BSW_00323` | 所有 AUTOSAR 基础软件模块应检查传入的 API 参数的有效性 | `SWS_WdgIf_00028` |
|
||||
| `SRS_BSW_00337` | 开发错误的分类 | `SWS_WdgIf_00006` |
|
||||
| `SRS_BSW_00357` | 对于 API 调用的成功 / 失败，应定义标准返回类型 | `SWS_WdgIf_00046` |
|
||||
| `SRS_BSW_00369` | 所有 AUTOSAR 基础软件模块不应通过 API 返回特定的开发错误代码 | `SWS_WdgIf_00058` |
|
||||
| `SRS_BSW_00384` | 基础软件模块规范应至少在描述中指定它们需要哪些其他模块 | `SWS_WdgIf_00047`、`SWS_WdgIf_00048` |
|
||||
| `SRS_BSW_00414` | 初始化函数应将指向配置结构的指针作为单一参数 | `SWS_WdgIf_00006`、`SWS_WdgIf_00999` |
|
||||
| `SRS_BSW_00450` | 未初始化模块的 Main 函数应立即返回 | `SWS_WdgIf_00999` |
|
||||
| `SRS_MemHwAb_14019` | 内存抽象接口应提供对底层内存抽象模块 API 服务的统一访问 | `SWS_WdgIf_00017`、`SWS_WdgIf_00026` |
|
||||
| `SRS_MemHwAb_14020` | 内存抽象接口应允许通过使用设备索引选择底层内存抽象模块 | `SWS_WdgIf_00018` |
|
||||
| `SRS_MemHwAb_14021` | 内存抽象接口应允许对底层内存抽象模块的数量进行预编译时间配置 | `SWS_WdgIf_00019`、`SWS_WdgIf_00020` |
|
||||
| `SRS_MemHwAb_14022` | 内存抽象接口应保留底层内存抽象模块的功能 | `SWS_WdgIf_00003` |
|
||||
| `SRS_MemHwAb_14023` | 内存抽象接口应仅检查接口本身内使用的参数 | `SWS_WdgIf_00028` |
|
||||
| `SRS_MemHwAb_14024` | 内存抽象接口应保留底层内存抽象模块及其 API 的时序行为 | `SWS_WdgIf_00003` |
|
||||
| `SRS_SPAL_12448` | 所有驱动模块在开发错误检测后应有特定的行为 | `SWS_WdgIf_00028` |
|
||||
| `SRS_Wdg_12018` | 看门狗驱动应提供用于选择看门狗模式的服务 | `SWS_WdgIf_00016`、`SWS_WdgIf_00042`、`SWS_WdgIf_00057`、`SWS_WdgIf_00061` |
|
||||
| `SRS_Wdg_12165` | 对于外部看门狗驱动，应适用与内部看门狗驱动相同的需求 | `SWS_WdgIf_00017`、`SWS_WdgIf_00026` |
|
||||
| `SRS_Wdg_12167` | 外部看门狗驱动应具有与内部看门狗驱动语义相同的 API | `SWS_WdgIf_00017`、`SWS_WdgIf_00026` |
|
||||
| `SRS_Wdg_13500` | 看门狗驱动应提供用于设置看门狗触发条件的服务 | `SWS_WdgIf_00044` |
|
||||
|
||||
> **摘要标记**：完整表共约 70 行，涵盖 `SRS_BSW_00005` 至 `SRS_BSW_00450`、`SRS_MemHwAb_14019` 至 `SRS_MemHwAb_14024`、`SRS_SPAL_12448`、`SRS_Wdg_12018`、`SRS_Wdg_12165`、`SRS_Wdg_12167`、`SRS_Wdg_13500`、`SWS_BSW_00212` 等所有需求条目，详情见原文 PDF 第 11-16 页。
|
||||
|
||||
---
|
||||
|
||||
## 7 功能规范
|
||||
|
||||
### 7.1 通用行为
|
||||
|
||||
> **[SWS_WdgIf_00003]** ⌈看门狗接口不应为看门狗驱动添加功能。看门狗接口也不抽象看门狗属性，如 toggle 或 window 模式、超时周期等，也就是说它不隐藏底层看门狗驱动和看门狗硬件的任何特性。⌋
|
||||
> （`SRS_MemHwAb_14022`、`SRS_MemHwAb_14024`）
|
||||
|
||||
### 7.2 错误分类
|
||||
|
||||
#### 7.2.1 开发错误
|
||||
|
||||
> **[SWS_WdgIf_00006]** ⌈开发错误类型
|
||||
>
|
||||
> | 错误类型 | 相关错误代码 | 值 [十六进制] |
|
||||
> |---|---|---|
|
||||
> | 使用错误的设备索引参数调用 API 服务 | `WDGIF_E_PARAM_DEVICE` | `0x01` |
|
||||
> | 参数列表中的无效指针 | `WDGIF_E_INV_POINTER` | `0x02` |
|
||||
> | NULL 指针检查 | `WDGIF_E_PARAM_POINTER` | `0x03` |
|
||||
> ⌋
|
||||
> （`SRS_BSW_00337`、`SRS_BSW_00385`、`SRS_BSW_00386`、`SRS_BSW_00327`、`SRS_BSW_00414`、`SWS_BSW_00212`）
|
||||
|
||||
> **[SWS_WdgIf_00030]** ⌈开发错误值的类型为 `uint8`。⌋
|
||||
> （`SRS_BSW_00304`）
|
||||
|
||||
> **[SWS_WdgIf_00028]** ⌈如果配置了多个看门狗驱动并且为此模块启用了开发错误检测，则应在模块的服务中检查参数 `DeviceIndex` 是否是模块内的现有设备。检测到的错误应使用错误代码 `WDGIF_E_PARAM_DEVICE` 报告给默认错误跟踪器（DET），且不应执行调用的服务。如果被调用的函数有返回值，则应将此值设置为 `E_NOT_OK`。⌋
|
||||
> （`SRS_BSW_00323`、`SRS_SPAL_12448`、`SRS_MemHwAb_14023`）
|
||||
|
||||
#### 7.2.2 运行时错误
|
||||
|
||||
无运行时错误。
|
||||
|
||||
#### 7.2.3 瞬态错误
|
||||
|
||||
无瞬态错误。
|
||||
|
||||
#### 7.2.4 生产错误
|
||||
|
||||
无生产错误。
|
||||
|
||||
#### 7.2.5 扩展生产错误
|
||||
|
||||
无扩展生产错误。
|
||||
|
||||
---
|
||||
|
||||
## 8 API 规范
|
||||
|
||||
### 8.1 导入的类型
|
||||
|
||||
本章列出从以下模块包含的所有类型：
|
||||
|
||||
> **[SWS_WdgIf_00041]** ⌈
|
||||
>
|
||||
> | 模块 | 头文件 | 导入的类型 |
|
||||
> |---|---|---|
|
||||
> | Std_Types | `StandardTypes.h` | `Std_ReturnType` |
|
||||
> | | `StandardTypes.h` | `Std_VersionInfoType` |
|
||||
> ⌋
|
||||
> （`SRS_BSW_00301`）
|
||||
|
||||
### 8.2 类型定义
|
||||
|
||||
**注意**：看门狗接口的实现者不得为特定的看门狗设备或平台更改或扩展看门狗接口的类型定义。
|
||||
|
||||
#### 8.2.1 `WdgIf_ModeType`
|
||||
|
||||
> **[SWS_WdgIf_00061]** ⌈
|
||||
>
|
||||
> | 字段 | 内容 |
|
||||
> |---|---|
|
||||
> | **名称** | `WdgIf_ModeType` |
|
||||
> | **类型** | Enumeration（枚举） |
|
||||
> | **范围** | `WDGIF_OFF_MODE` —— 在此模式下，看门狗驱动被禁用（关闭）。<br>`WDGIF_SLOW_MODE` —— 在此模式下，看门狗驱动设置为长超时周期（慢速触发）。<br>`WDGIF_FAST_MODE` —— 在此模式下，看门狗驱动设置为短超时周期（快速触发）。 |
|
||||
> | **描述** | WdgIf 模块的模式类型 |
|
||||
> | **可用来源** | `WdgIf.h` |
|
||||
> ⌋
|
||||
> （`SRS_Wdg_12018`）
|
||||
|
||||
> **[SWS_WdgIf_00016]** ⌈`WdgIf_ModeType` 值应作为参数传递给看门狗驱动的模式切换函数（`Wdg_SetMode`）。⌋
|
||||
> （`SRS_Wdg_12018`）
|
||||
|
||||
**注意**：这些模式背后的硬件特定设置在看门狗驱动的配置集中给出。
|
||||
|
||||
### 8.3 函数定义
|
||||
|
||||
> **[SWS_WdgIf_00017]** ⌈看门狗接口应将本章中指定的 API 映射到底层驱动的 API。有关功能行为，请参阅看门狗驱动的规范。⌋
|
||||
> （`SRS_Wdg_12165`、`SRS_Wdg_12167`、`SRS_MemHwAb_14019`）
|
||||
|
||||
> **[SWS_WdgIf_00018]** ⌈看门狗接口应使用参数 `DeviceIndex` 来选择看门狗驱动。如果仅配置了一个看门狗驱动，则应忽略参数 `DeviceIndex`。⌋
|
||||
> （`SRS_MemHwAb_14020`）
|
||||
|
||||
> **[SWS_WdgIf_00013]** ⌈看门狗设备索引的数据类型应为 `uint8`。`DeviceIndex` 应提供基于零的连续索引。⌋
|
||||
> （`SRS_BSW_00304`）
|
||||
|
||||
> **[SWS_WdgIf_00019]** ⌈如果仅配置了一个看门狗驱动，则看门狗接口在将看门狗接口 API 映射到相应看门狗驱动的 API 时不应产生运行时开销。⌋
|
||||
> （`SRS_MemHwAb_14021`）
|
||||
|
||||
**实现提示**：这可以通过使用宏来完成，例如：
|
||||
|
||||
```c
|
||||
#define WdgIf_SetMode(DeviceIndex, WdgMode) \
|
||||
Wdg_SetMode(WdgMode)
|
||||
```
|
||||
|
||||
> **[SWS_WdgIf_00020]** ⌈如果配置了多个看门狗驱动，则看门狗接口应使用有效的机制将 API 调用映射到适当的看门狗驱动。⌋
|
||||
> （`SRS_MemHwAb_14021`）
|
||||
|
||||
**实现提示**：一种解决方案是使用指向函数的指针表，其中参数 `DeviceIndex` 用作数组索引，例如：
|
||||
|
||||
```c
|
||||
#define WdgIf_SetMode(DeviceIndex, WdgMode) \
|
||||
SetModeFctPtr[DeviceIndex](WdgMode)
|
||||
```
|
||||
|
||||
**注意**：服务 ID 与看门狗驱动规范的服务 ID 相关（参见 [5]）。因此，它们可能不从 0 开始。
|
||||
|
||||
#### 8.3.1 `WdgIf_SetMode`
|
||||
|
||||
> **[SWS_WdgIf_00042]** ⌈
|
||||
>
|
||||
> | 字段 | 内容 |
|
||||
> |---|---|
|
||||
> | **服务名称** | `WdgIf_SetMode` |
|
||||
> | **语法** | `Std_ReturnType WdgIf_SetMode(uint8 DeviceIndex, WdgIf_ModeType WdgMode)` |
|
||||
> | **服务 ID[十六进制]** | `0x01` |
|
||||
> | **同步 / 异步** | Synchronous（同步） |
|
||||
> | **可重入性** | Non Reentrant（不可重入） |
|
||||
> | **参数 (in)** | `DeviceIndex` —— 标识看门狗驱动实例。<br>`WdgMode` —— 看门狗驱动模式（参见看门狗驱动）。 |
|
||||
> | **参数 (inout)** | None |
|
||||
> | **参数 (out)** | None |
|
||||
> | **返回值** | `Std_ReturnType` —— -- |
|
||||
> | **描述** | 将 `WdgIf_SetMode` 服务映射到相应看门狗驱动的 `Wdg_SetMode` 服务。 |
|
||||
> | **可用来源** | `WdgIf.h` |
|
||||
> ⌋
|
||||
> （`SRS_Wdg_12018`）
|
||||
|
||||
> **[SWS_WdgIf_00057]** ⌈`WdgIf_SetMode` 应返回从相应看门狗驱动的 `Wdg_SetMode` 服务获得的值。⌋
|
||||
> （`SRS_Wdg_12018`）
|
||||
|
||||
返回值的可能内容由看门狗驱动指定，参见 [5]。
|
||||
|
||||
#### 8.3.2 `WdgIf_SetTriggerCondition`
|
||||
|
||||
> **[SWS_WdgIf_00044]** ⌈
|
||||
>
|
||||
> | 字段 | 内容 |
|
||||
> |---|---|
|
||||
> | **服务名称** | `WdgIf_SetTriggerCondition` |
|
||||
> | **语法** | `void WdgIf_SetTriggerCondition(uint8 DeviceIndex, uint16 Timeout)` |
|
||||
> | **服务 ID[十六进制]** | `0x02` |
|
||||
> | **同步 / 异步** | Synchronous（同步） |
|
||||
> | **可重入性** | Non Reentrant（不可重入） |
|
||||
> | **参数 (in)** | `DeviceIndex` —— 标识看门狗驱动实例。<br>`Timeout` —— 用于设置触发计数器的超时值（毫秒）。 |
|
||||
> | **参数 (inout)** | None |
|
||||
> | **参数 (out)** | None |
|
||||
> | **返回值** | None |
|
||||
> | **描述** | 将 `WdgIf_SetTriggerCondition` 服务映射到相应看门狗驱动的 `Wdg_SetTriggerCondition` 服务。 |
|
||||
> | **可用来源** | `WdgIf.h` |
|
||||
> ⌋
|
||||
> （`SRS_Wdg_13500`）
|
||||
|
||||
#### 8.3.3 `WdgIf_GetVersionInfo`
|
||||
|
||||
> **[SWS_WdgIf_00046]** ⌈
|
||||
>
|
||||
> | 字段 | 内容 |
|
||||
> |---|---|
|
||||
> | **服务名称** | `WdgIf_GetVersionInfo` |
|
||||
> | **语法** | `void WdgIf_GetVersionInfo(Std_VersionInfoType* VersionInfoPtr)` |
|
||||
> | **服务 ID[十六进制]** | `0x03` |
|
||||
> | **同步 / 异步** | Synchronous（同步） |
|
||||
> | **可重入性** | Reentrant（可重入） |
|
||||
> | **参数 (in)** | None |
|
||||
> | **参数 (inout)** | None |
|
||||
> | **参数 (out)** | `VersionInfoPtr` —— 指向存储本模块版本信息的位置的指针。 |
|
||||
> | **返回值** | None |
|
||||
> | **描述** | 返回版本信息。 |
|
||||
> | **可用来源** | `WdgIf.h` |
|
||||
> ⌋
|
||||
> （`SRS_BSW_00357`）
|
||||
|
||||
> **[SWS_WdgIf_00058]** ⌈如果为看门狗接口模块启用开发错误检测，则 `WdgIf_GetVersionInfo` 函数应检查参数 `VersioninfoPtr` 是否为 NULL 指针（`NULL_PTR`）。如果 `VersioninfoPtr` 是 NULL 指针，则 `WdgIf_GetVersionInfo` 函数应引发开发错误 `WDGIF_E_INV_POINTER`（即无效指针）并返回。⌋
|
||||
> （`SRS_BSW_00369`）
|
||||
|
||||
### 8.4 回调通知
|
||||
|
||||
本模块不提供任何回调函数。
|
||||
|
||||
### 8.5 调度函数
|
||||
|
||||
本模块不需要任何调度函数。
|
||||
|
||||
### 8.6 预期接口
|
||||
|
||||
本章列出了从其他模块所需的所有接口。
|
||||
|
||||
#### 8.6.1 强制接口
|
||||
|
||||
本章定义了实现模块核心功能所需的所有接口。
|
||||
|
||||
> **[SWS_WdgIf_00047]** ⌈
|
||||
>
|
||||
> | API 函数 | 头文件 | 描述 |
|
||||
> |---|---|---|
|
||||
> | `Wdg_SetMode` | `Wdg.h` | 将看门狗切换到 `Mode` 模式。 |
|
||||
> | `Wdg_SetTriggerCondition` | `Wdg.h` | 设置触发计数器的超时值。 |
|
||||
> ⌋
|
||||
> （`SRS_BSW_00384`）
|
||||
|
||||
#### 8.6.2 可选接口
|
||||
|
||||
本章定义了实现模块可选功能所需的所有接口。
|
||||
|
||||
> **[SWS_WdgIf_00048]** ⌈
|
||||
>
|
||||
> | API 函数 | 头文件 | 描述 |
|
||||
> |---|---|---|
|
||||
> | `Det_ReportError` | `Det.h` | 用于报告开发错误的服务。 |
|
||||
> ⌋
|
||||
> （`SRS_BSW_00384`）
|
||||
|
||||
#### 8.6.3 可配置接口
|
||||
|
||||
本模块没有可配置接口。
|
||||
|
||||
---
|
||||
|
||||
## 9 序列图
|
||||
|
||||
请参阅看门狗驱动规范 [5]。
|
||||
|
||||
---
|
||||
|
||||
## 10 配置规范
|
||||
|
||||
通常，本章定义配置参数及其到容器的聚类。为了支持规范，第 10.1 章描述了基本原理。它还指定了用于参数规范的模板（表）。我们打算将第 10.1 章保留在规范中以保证可理解性。
|
||||
|
||||
第 10.2 章规定了模块 WdgIf 的结构（容器）和参数。
|
||||
|
||||
第 10.3 章规定了模块 WdgIf 的发布信息。
|
||||
|
||||
### 10.1 如何阅读本章
|
||||
|
||||
有关详细信息，请参阅 `SWS_BSWGeneral` 第 10.1 节"Introduction to configuration specification"。
|
||||
|
||||
### 10.2 容器和配置参数
|
||||
|
||||
以下各章概述了所有配置参数。参数的详细含义在第 7 章和第 8 章中描述。
|
||||
|
||||
#### 10.2.1 `WdgIf`
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **SWS Item** | `ECUC_WdgIf_00033` |
|
||||
| **模块名称** | WdgIf |
|
||||
| **模块描述** | WdgIf（看门狗接口）模块的配置。 |
|
||||
| **后构建变体支持** | false |
|
||||
| **支持的配置变体** | `VARIANT-PRE-COMPILE` |
|
||||
|
||||
**包含的容器**：
|
||||
|
||||
| 容器名称 | 多重性 | 范围 / 依赖 |
|
||||
|---|---|---|
|
||||
| `WdgIfDevice` | 1..* | 在连接了多个看门狗驱动的情况下，它包含用于选择特定看门狗设备的信息。 |
|
||||
| `WdgIfGeneral` | 1 | 此容器收集所有通用看门狗接口参数。 |
|
||||
|
||||
#### 10.2.2 `WdgIfGeneral`
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **SWS Item** | `ECUC_WdgIf_00001` |
|
||||
| **容器名称** | `WdgIfGeneral` |
|
||||
| **描述** | 此容器收集所有通用看门狗接口参数。 |
|
||||
|
||||
**配置参数**：
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **SWS Item** | `ECUC_WdgIf_00005` |
|
||||
| **名称** | `WdgIfDevErrorDetect` |
|
||||
| **父容器** | `WdgIfGeneral` |
|
||||
| **描述** | 启用或关闭开发错误检测和通知。<br>• true：启用检测和通知。<br>• false：禁用检测和通知。 |
|
||||
| **多重性** | 1 |
|
||||
| **类型** | `EcucBooleanParamDef` |
|
||||
| **默认值** | false |
|
||||
| **后构建变体值** | false |
|
||||
| **值配置类** | 预编译时间：X —— 所有变体 |
|
||||
| **范围 / 依赖** | 范围：local |
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **SWS Item** | `ECUC_WdgIf_00003` |
|
||||
| **名称** | `WdgIfVersionInfoApi` |
|
||||
| **父容器** | `WdgIfGeneral` |
|
||||
| **描述** | 预处理器开关，用于启用 / 禁用返回版本信息的服务。<br>true：启用版本信息服务<br>false：禁用版本信息服务 |
|
||||
| **多重性** | 1 |
|
||||
| **类型** | `EcucBooleanParamDef` |
|
||||
| **默认值** | false |
|
||||
| **后构建变体值** | false |
|
||||
| **值配置类** | 预编译时间：X —— 所有变体 |
|
||||
| **范围 / 依赖** | 范围：local |
|
||||
|
||||
无包含的容器。
|
||||
|
||||
#### 10.2.3 `WdgIfDevice`
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **SWS Item** | `ECUC_WdgIf_00002` |
|
||||
| **容器名称** | `WdgIfDevice` |
|
||||
| **描述** | 在连接了多个看门狗驱动的情况下，它包含用于选择特定看门狗设备的信息。 |
|
||||
|
||||
**配置参数**：
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **SWS Item** | `ECUC_WdgIf_00006` |
|
||||
| **名称** | `WdgIfDeviceIndex` |
|
||||
| **父容器** | `WdgIfDevice` |
|
||||
| **描述** | 表示看门狗接口 ID，以便看门狗管理器可以引用它。 |
|
||||
| **多重性** | 1 |
|
||||
| **类型** | `EcucIntegerParamDef`（为此参数生成的符号名称） |
|
||||
| **范围** | 0 .. 255 |
|
||||
| **默认值** | -- |
|
||||
| **后构建变体值** | false |
|
||||
| **值配置类** | 预编译时间：X —— 所有变体 |
|
||||
| **范围 / 依赖** | 范围：ECU |
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **SWS Item** | `ECUC_WdgIf_00007` |
|
||||
| **名称** | `WdgIfDriverRef` |
|
||||
| **父容器** | `WdgIfDevice` |
|
||||
| **描述** | 对由看门狗接口控制的看门狗驱动的引用。 |
|
||||
| **多重性** | 1 |
|
||||
| **类型** | 对 `[ WdgGeneral ]` 的符号名称引用 |
|
||||
| **后构建变体值** | false |
|
||||
| **值配置类** | 预编译时间：X —— 所有变体 |
|
||||
| **范围 / 依赖** | 范围：local |
|
||||
|
||||
无包含的容器。
|
||||
|
||||
### 10.3 发布参数
|
||||
|
||||
有关详细信息，请参阅 `SWS_BSWGeneral` 第 10.3 节"Published Information"。
|
||||
|
||||
---
|
||||
|
||||
## 11 不适用的需求
|
||||
|
||||
> **[SWS_WdgIf_00999]** ⌈这些需求不适用于本规范。⌋
|
||||
> （`SRS_BSW_00344`、`SRS_BSW_00404`、`SRS_BSW_00405`、`SRS_BSW_00159`、`SRS_BSW_00170`、`SRS_BSW_00380`、`SRS_BSW_00419`、`SRS_BSW_00412`、`SRS_BSW_00383`、`SRS_BSW_00398`、`SRS_BSW_00399`、`SRS_BSW_00400`、`SRS_BSW_00438`、`SRS_BSW_00375`、`SRS_BSW_00101`、`SRS_BSW_00416`、`SRS_BSW_00406`、`SRS_BSW_00437`、`SRS_BSW_00168`、`SRS_BSW_00423`、`SRS_BSW_00424`、`SRS_BSW_00425`、`SRS_BSW_00426`、`SRS_BSW_00427`、`SRS_BSW_00428`、`SRS_BSW_00429`、`SRS_BSW_00432`、`SRS_BSW_00433`、`SRS_BSW_00450`、`SRS_BSW_00336`、`SRS_BSW_00339`、`SRS_BSW_00422`、`SRS_BSW_00417`、`SRS_BSW_00161`、`SRS_BSW_00162`、`SRS_BSW_00005`、`SRS_BSW_00415`、`SRS_BSW_00164`、`SRS_BSW_00325`、`SRS_BSW_00342`、`SRS_BSW_00343`、`SRS_BSW_00007`、`SRS_BSW_00300`、`SRS_BSW_00413`、`SRS_BSW_00347`、`SRS_BSW_00441`、`SRS_BSW_00307`、`SRS_BSW_00373`、`SRS_BSW_00335`、`SRS_BSW_00314`、`SRS_BSW_00447`、`SRS_BSW_00328`、`SRS_BSW_00312`、`SRS_BSW_00439`、`SRS_BSW_00449`、`SRS_BSW_00377`、`SRS_BSW_00304`、`SRS_BSW_00378`、`SRS_BSW_00306`、`SRS_BSW_00308`、`SRS_BSW_00309`、`SRS_BSW_00371`、`SRS_BSW_00358`、`SRS_BSW_00414`、`SRS_BSW_00359`、`SRS_BSW_00360`、`SRS_BSW_00440`、`SRS_BSW_00330`、`SRS_BSW_00331`、`SRS_BSW_00009`、`SRS_BSW_00401`、`SRS_BSW_00010`、`SRS_BSW_00333`、`SRS_BSW_00321`、`SRS_BSW_00334`）
|
||||
|
||||
---
|
||||
|
||||
## 翻译说明
|
||||
|
||||
- **翻译完整性**：本文档为 AUTOSAR 看门狗接口规范（SWS）的中文翻译版本，完整翻译了 1-11 章全部内容。
|
||||
- **保留的英文术语**：所有 API 标识符（`WdgIf_SetMode`、`WdgIf_SetTriggerCondition`、`WdgIf_GetVersionInfo`、`Wdg_SetMode`、`WdgIf_ModeType` 等）、错误代码（`WDGIF_E_PARAM_DEVICE`、`WDGIF_E_INV_POINTER`、`WDGIF_E_PARAM_POINTER`）、模块缩写（Wdg、WdgIf、WdgM、Std_Types、DET）、需求 ID（`SWS_WdgIf_xxxxx`、`SRS_Wdg_xxxxx`、`SRS_BSW_xxxxx`、`SRS_MemHwAb_xxxxx`、`SRS_SPAL_xxxxx`、`ECUC_WdgIf_xxxxx`、`SWS_BSW_xxxxx`）、AUTOSAR 方框符 `⌈⌋` 均按要求保留为英文。
|
||||
- **省略的内容**：免责声明（Disclaimer）按要求未翻译。
|
||||
- **摘要标记**：第 6 章需求可追溯性表中包含约 70 行映射，本翻译列出代表性条目；完整表请参见原文 PDF 第 11-16 页。
|
||||
- **关键概念**：`WdgIf_ModeType` 枚举值（`WDGIF_OFF_MODE`、`WDGIF_SLOW_MODE`、`WDGIF_FAST_MODE`）用于看门狗模式切换。
|
||||
@@ -0,0 +1,847 @@
|
||||
# 看门狗管理器规范（Specification of Watchdog Manager）
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **文档标题** | 看门狗管理器规范（Specification of Watchdog Manager） |
|
||||
| **文档所有者** | AUTOSAR |
|
||||
| **文档责任方** | AUTOSAR |
|
||||
| **文档标识号** | 080 |
|
||||
| **文档状态** | Final（正式发布） |
|
||||
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
|
||||
| **所属标准版本** | 4.4.0 |
|
||||
|
||||
---
|
||||
|
||||
## 文档变更历史（Document Change History）
|
||||
|
||||
| 日期 | 版本 | 变更人 | 变更描述 |
|
||||
|---|---|---|---|
|
||||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 头文件清理；EcuPartition 与 OSApplication；编辑性变更 |
|
||||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 修正开发错误；将 default error 重命名为 development error |
|
||||
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 移除已弃用功能；服务接口修正；删除重复类型定义；若干小修正 |
|
||||
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 调试支持标记为过时；若干小修正；修正开发错误处理 |
|
||||
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 引入系统服务的建模；将部分需求重定义为约束；细微修正 |
|
||||
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 增加 Deadline 监督的 OS 计数器；修正 Supervised Entity 与 Checkpoint 数据类型（uint16）；若干小修正 |
|
||||
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 小幅修正（模式切换、对其他模块的依赖）；文档质量修正；编辑性变更；删除变更文档章节 |
|
||||
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 根据新 SWS_BSWGeneral 重新修订；新的需求索引方案；Deadline 监督澄清；端口与端口接口规范中的小修正 |
|
||||
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 头文件结构变更；新增读取重启后哪个 SE 引起复位的方法：`WdgM_GetFirstExpiredSEID`；带需求可追溯性的新模板 |
|
||||
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 简化使用的术语；重组部分章节结构；澄清歧义并解决矛盾；修正若干错误；提供更多关于 WdgM 函数及其调用顺序的细节 |
|
||||
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 窗口看门狗的新概念；新的监督函数 Logical Supervision 和 Deadline Supervision；监督状态分为本地与全局监督状态；监督的激活与停用新概念；Defensive Behavior 新概念；分区（应用）重启的故障恢复新概念；法律声明修订 |
|
||||
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律声明修订 |
|
||||
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 扩展模式概念；新增 GPT 作为 Startup、Shutdown、Sleep 期间的激活源；模块配置重构；BSW UML 模型生成的 API；元模型生成的配置；扩展文档元信息；小布局调整 |
|
||||
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 从"AUTOSAR Services"文档新增"Specification of the ports and port interfaces"章节；新增可选行为 active reset；Deinit 函数新行为：触发看门狗驱动；SetMode 服务失败时看门狗管理器的默认模式；法律声明修订；新增发布说明；"Advice for users"修订；新增"Revision Information" |
|
||||
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始发布 |
|
||||
|
||||
---
|
||||
|
||||
## 目录（Table of Contents）
|
||||
|
||||
1. [引言与功能概述](#1-引言与功能概述)
|
||||
- 1.1 [监督实体与检查点（Supervised Entities and Checkpoints）](#11-监督实体与检查点)
|
||||
- 1.2 [监督机制之间的交互（Interaction of Supervision Mechanisms）](#12-监督机制之间的交互)
|
||||
- 1.3 [监督功能（Supervision Functions）](#13-监督功能)
|
||||
- 1.3.1 [Alive 监督](#131-alive-监督)
|
||||
- 1.3.2 [Deadline 监督](#132-deadline-监督)
|
||||
- 1.3.3 [Logical 监督](#133-logical-监督)
|
||||
- 1.4 [看门狗处理（Watchdog Handling）](#14-看门狗处理)
|
||||
- 1.5 [错误处理（Error Handling）](#15-错误处理)
|
||||
2. [缩略语、缩写与术语](#2-缩略语缩写与术语)
|
||||
3. [相关文档](#3-相关文档)
|
||||
4. [约束与假设](#4-约束与假设)
|
||||
5. [与其他模块的依赖关系](#5-与其他模块的依赖关系)
|
||||
6. [需求可追溯性](#6-需求可追溯性)
|
||||
7. [功能规范](#7-功能规范)
|
||||
8. [API 规范](#8-api-规范)
|
||||
9. [序列图](#9-序列图)
|
||||
10. [配置规范](#10-配置规范)
|
||||
11. [附录 A：Alive 监督算法的示例实现](#11-附录-aalive-监督算法的示例实现)
|
||||
12. [不适用的需求](#12-不适用的需求)
|
||||
|
||||
---
|
||||
|
||||
## 1 引言与功能概述
|
||||
|
||||
看门狗管理器（Watchdog Manager，WdgM）是 AUTOSAR 标准化基础软件架构中位于服务层的基础软件模块。
|
||||
|
||||
看门狗管理器能够监督程序执行，**抽象于硬件看门狗实体的触发**。
|
||||
|
||||
看门狗管理器监督**可配置数量**的所谓**监督实体（Supervised Entities）** 的执行。当检测到程序执行的时间约束和/或逻辑约束被违反时，它会采取**可配置数量**的动作以从该故障中恢复。
|
||||
|
||||
看门狗管理器提供三种机制：
|
||||
|
||||
1. **Alive 监督** — 用于监督周期性软件的时序
|
||||
2. **Deadline 监督** — 用于非周期性软件
|
||||
3. **Logical 监督** — 用于监督执行序列的正确性
|
||||
|
||||
### 1.1 监督实体与检查点
|
||||
|
||||
看门狗管理器监督软件的执行。监督的逻辑单元是**监督实体（Supervised Entities）**。监督实体与 AUTOSAR 架构构件（即 SW-C、CDD、RTE、BSW 模块）之间没有固定关系，但根据开发者的选择，监督实体通常可代表一个 SW-C 或 SW-C 中的一个 Runnable、一个 BSW 模块或一个 CDD。
|
||||
|
||||
监督实体中的重要位置被定义为**检查点（Checkpoints）**。监督实体的代码与看门狗管理器调用交织在一起，这些调用在到达检查点时向看门狗管理器报告。
|
||||
|
||||
每个监督实体具有一个或多个检查点。监督实体的检查点及检查点之间的**转换（Transitions）** 形成一个**图（Graph）**。该图称为**内部图（Internal Graph）**。此外，不同监督实体的检查点之间也可以通过**外部转换（External Transition）** 连接，形成一个**外部图（External Graph）**。在每个看门狗管理器模式下可以有多个外部图。
|
||||
|
||||
一个图可以具有一个或多个**初始检查点**和一个或多个**终结检查点**。任何从某个初始检查点开始并在某个终结检查点结束的序列都是正确的（假设检查点属于同一个图）。在终结检查点之后，可以报告任何初始检查点。
|
||||
|
||||
在看门狗管理器设置中，可以配置检查点的所需时序以及允许的外部图和内部图。
|
||||
|
||||
运行时，看门狗管理器验证配置的图是否被执行。这称为**逻辑监督（Logical Supervision）**。看门狗管理器还验证检查点和转换的时序。周期性检查点的机制称为 **Alive 监督**，非周期性检查点的机制称为 **Deadline 监督**。
|
||||
|
||||
检查点的粒度并非由看门狗管理器固定。少量粗粒度的检查点会限制看门狗管理器的检测能力。例如，如果应用 SW-C 只有一个检查点指示循环 Runnable 已启动，则看门狗管理器仅能检测到该 Runnable 重新启动并检查时序约束。相反，如果该 SW-C 在 Runnable 的每个块和分支处都有检查点，看门狗管理器还可检测该 SW-C 控制流中的故障。高粒度的检查点会导致看门狗管理器的配置复杂且庞大。
|
||||
|
||||
### 1.2 监督机制之间的交互
|
||||
|
||||
三种监督机制分别监督每个监督实体。一个监督实体可启用一种、两种或三种机制。根据每种启用机制的结果，计算监督实体的状态（称为**本地状态（Local Status）**）。
|
||||
|
||||
当确定每个监督实体的状态后，再根据每个本地监督状态确定整个 MCU 的状态（称为**全局监督状态（Global Supervision Status）**）。
|
||||
|
||||
### 1.3 监督功能
|
||||
|
||||
#### 1.3.1 Alive 监督
|
||||
|
||||
周期性监督实体对在给定时间段内被执行的次数有约束。通过 Alive 监督，看门狗管理器周期性地检查监督实体的检查点是否已被报告达到预期的次数。
|
||||
|
||||
#### 1.3.2 Deadline 监督
|
||||
|
||||
非周期性监督实体具有时间约束，看门狗管理器必须检查从检查点开始到结束之间经过的时间是否在配置的最小和最大时间限制之间。Deadline 监督对从一个检查点到另一个检查点所需的最小和最大时间加以约束。
|
||||
|
||||
#### 1.3.3 Logical 监督
|
||||
|
||||
通过 Logical 监督，看门狗管理器检查监督实体的执行顺序。它在检查点之间定义允许的转换序列（**内部转换**）。此外，还可以将来自不同监督实体的检查点通过**外部转换**连接。
|
||||
|
||||
### 1.4 看门狗处理
|
||||
|
||||
看门狗管理器本身**不直接控制看门狗硬件**。硬件相关的触发由看门狗驱动（Watchdog Driver）完成，看门狗驱动本身由看门狗接口（Watchdog Interface）抽象。
|
||||
|
||||
看门狗管理器监督若干监督实体的执行。根据此监督的结果，看门狗管理器决定是否调用看门狗接口（从而触发一个或多个看门狗）。如果发现错误，看门狗管理器可切换到反应性状态，并采取相应措施（例如不再触发看门狗，最终导致硬件复位）。
|
||||
|
||||
### 1.5 错误处理
|
||||
|
||||
#### 1.5.1 监督实体中的错误处理
|
||||
|
||||
错误处理的第一阶段发生在**监督实体内部**。当监督功能检测到错误时，监督实体的本地监督状态被设置为 `EXPIRED`，并执行错误处理（详见第 7 章）。
|
||||
|
||||
#### 1.5.2 分区关闭
|
||||
|
||||
如果错误处理不成功，可关闭相应的 OS-Application（分区）。这在多核系统中尤其重要，以避免受影响的应用干扰其他分区。
|
||||
|
||||
#### 1.5.3 由硬件看门狗复位
|
||||
|
||||
看门狗管理器配置为**不再触发看门狗**，此时硬件看门狗将在其超时后执行 ECU 复位。这是最高等级的反应。
|
||||
|
||||
#### 1.5.4 立即 MCU 复位
|
||||
|
||||
看门狗管理器也可以直接通过 `WdgM_PerformReset()` 函数立即触发 MCU 复位。
|
||||
|
||||
---
|
||||
|
||||
## 2 缩略语、缩写与术语
|
||||
|
||||
**缩写 / 首字母缩略词**
|
||||
|
||||
| 缩写 | 描述 |
|
||||
|---|---|
|
||||
| BSW | Basic Software（基础软件） |
|
||||
| CDD | Complex Device Driver（复杂设备驱动） |
|
||||
| DEM | Diagnostic Event Manager（诊断事件管理器） |
|
||||
| DET | Default Error Tracer（默认错误跟踪器） |
|
||||
| EcuM | ECU State Manager（ECU 状态管理器） |
|
||||
| OS | Operating System（操作系统） |
|
||||
| RTE | Runtime Environment（运行时环境） |
|
||||
| SE | Supervised Entity（监督实体） |
|
||||
| SW-C | Software Component（软件组件） |
|
||||
| WdgM | Watchdog Manager（看门狗管理器） |
|
||||
| WdgIf | Watchdog Interface（看门狗接口） |
|
||||
| Wdg | Watchdog Driver（看门狗驱动） |
|
||||
|
||||
**关键术语**
|
||||
|
||||
| 术语 | 描述 |
|
||||
|---|---|
|
||||
| **Alive Supervision（Alive 监督）** | 用于监督周期性软件的时序 |
|
||||
| **Deadline Supervision（Deadline 监督）** | 用于监督非周期性软件，验证检查点之间的时间间隔 |
|
||||
| **Logical Supervision（Logical 监督）** | 用于监督程序的控制流（执行顺序） |
|
||||
| **Checkpoint（检查点）** | 监督实体中由 WdgM_CheckpointReached 标识的重要位置 |
|
||||
| **Internal Transition（内部转换）** | 同一监督实体的两个检查点之间的转换 |
|
||||
| **External Transition（外部转换）** | 不同监督实体的检查点之间的转换 |
|
||||
| **Internal Graph（内部图）** | 由内部转换连接的检查点集合 |
|
||||
| **External Graph（外部图）** | 由外部转换连接的检查点集合 |
|
||||
| **Local Supervision Status（本地监督状态）** | 单个监督实体的状态 |
|
||||
| **Global Supervision Status（全局监督状态）** | 整个 MCU 的整体监督状态 |
|
||||
| **Supervised Entity（监督实体）** | 被看门狗管理器监督的逻辑软件单元 |
|
||||
| **Defensive Behavior（防御性行为）** | 当检测到故障时采取的预定义反应行为 |
|
||||
|
||||
---
|
||||
|
||||
## 3 相关文档
|
||||
|
||||
### 3.1 输入文档
|
||||
|
||||
- **[1]** Layered Software Architecture — `AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf`
|
||||
- **[2]** General Requirements on Basic Software Modules — `AUTOSAR_SRS_BSWGeneral.pdf`
|
||||
- **[3]** Requirements on Watchdog Manager — `AUTOSAR_SRS_WatchdogManager.pdf`
|
||||
- **[4]** Specification of Watchdog Driver — `AUTOSAR_SWS_WatchdogDriver.pdf`
|
||||
- **[5]** Specification of Watchdog Interface — `AUTOSAR_SWS_WatchdogInterface.pdf`
|
||||
- **[6]** Specification of RTE — `AUTOSAR_SWS_RTE.pdf`
|
||||
- **[7]** Specification of ECU State Manager — `AUTOSAR_SWS_ECUStateManager.pdf`
|
||||
- **[8]** Specification of OS — `AUTOSAR_SWS_OS.pdf`
|
||||
- **[9]** Basic Software Module Description Template — `AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf`
|
||||
- **[10]** General Specification of Basic Software Modules — `AUTOSAR_SWS_BSWGeneral.pdf`
|
||||
|
||||
### 3.2 相关规范
|
||||
|
||||
- **[11]** ISO 26262 — Road vehicles — Functional safety
|
||||
|
||||
---
|
||||
|
||||
## 4 约束与假设
|
||||
|
||||
### 4.1 限制与使用条件
|
||||
|
||||
看门狗管理器模块**不直接访问硬件**。看门狗的实际触发由看门狗驱动完成，看门狗驱动由看门狗接口抽象。
|
||||
|
||||
支持看门狗管理器的运行需要以下前提：
|
||||
|
||||
- OS 提供了 `GetElapsedCounterValue` 服务（用于 Deadline 监督的时间测量）
|
||||
- 看门狗驱动和看门狗接口已正确实现
|
||||
- RTE 已配置为允许 SW-C 通过服务端口与 WdgM 通信
|
||||
|
||||
### 4.2 对汽车领域的适用性
|
||||
|
||||
看门狗管理器适用于所有汽车域。
|
||||
|
||||
---
|
||||
|
||||
## 5 与其他模块的依赖关系
|
||||
|
||||
看门狗管理器位于 AUTOSAR 基础软件架构的**服务层**。它使用以下模块的服务：
|
||||
|
||||
- **OS（操作系统）**：提供 `GetElapsedCounterValue` 用于 Deadline 监督
|
||||
- **WdgIf（看门狗接口）**：抽象对底层看门狗驱动的访问
|
||||
- **Wdg（看门狗驱动）**：实际的硬件触发
|
||||
- **RTE（运行时环境）**：与 SW-C 通信
|
||||
- **DEM（诊断事件管理器）**：报告错误
|
||||
- **DET（默认错误跟踪器）**：开发期错误报告
|
||||
- **EcuM（ECU 状态管理器）**：模式切换交互
|
||||
|
||||
### 5.1 文件结构
|
||||
|
||||
#### 5.1.1 代码文件结构
|
||||
|
||||
> **[SWS_WdgM_00051]** ⌈看门狗管理器应按照 `SWS_BSWGeneral` 的规定提供以下代码文件：
|
||||
> - `WdgM.c` — 实现文件
|
||||
> - `WdgM.h` — 公共头文件
|
||||
> - `WdgM_Cbk.h` — 回调函数声明
|
||||
> - `WdgM_Lcfg.c` — 链接时配置数据
|
||||
> - `WdgM_PBcfg.c` — 后构建配置数据
|
||||
> - `WdgM_MemMap.h` — 内存映射文件
|
||||
> ⌋
|
||||
|
||||
### 5.2 版本检查
|
||||
|
||||
> **[SWS_WdgM_00182]** ⌈看门狗管理器应根据 `SWS_BSWGeneral` 中的版本检查机制，对所有导入的头文件进行版本检查。⌋
|
||||
|
||||
---
|
||||
|
||||
## 6 需求可追溯性
|
||||
|
||||
> **翻译说明**：本节包含一个大型参考表，将 SRS 需求映射到 SWS 需求。下表列出前 10 行代表性映射；完整表（包含约 60+ 项映射）请参见原文 PDF 第 21-28 页。
|
||||
|
||||
| 需求 | 描述 | 由以下需求满足 |
|
||||
|---|---|---|
|
||||
| `SRS_BSW_00010` | 应记录所有基础软件模块的内存消耗 | `SWS_WdgM_00105` |
|
||||
| `SRS_BSW_00101` | 基础软件模块应能在单独的初始化函数中初始化 | `SWS_WdgM_00011` |
|
||||
| `SRS_BSW_00158` | 排除使用目录结构 | `SWS_WdgM_00051` |
|
||||
| `SRS_BSW_00302` | 应支持 BSWSchdule 的可重入性 | `SRS_WdgM_00051` |
|
||||
| `SRS_BSW_00331` | 模块应支持分多个文件包含其代码 | `SWS_WdgM_00051` |
|
||||
| `SRS_BSW_00336` | 当初始化失败时，模块的基本软件模块功能应处于已定义状态 | `SWS_WdgM_00011` |
|
||||
| `SRS_BSW_00337` | 所有基础软件模块应支持在初始化阶段配置错误的分类 | `SWS_WdgM_00050` |
|
||||
| `SRS_BSW_00350` | 所有基础软件模块应支持对开发错误进行分类 | `SWS_WdgM_00050` |
|
||||
| `SRS_BSW_00385` | 列出来自所有 DET 的可能错误 | `SWS_WdgM_00050` |
|
||||
| `SRS_BSW_00386` | 对未更改的功能 API 服务调用应返回 E_OK | `SWS_WdgM_00001` |
|
||||
|
||||
> **摘要标记**：本表共约 60+ 行；上表列出前 10 行代表性映射。完整表涵盖 `SRS_BSW_00004` 至 `SRS_BSW_00466`、`SRS_WdgM_12001` 至 `SRS_WdgM_14000+` 范围，详情见原文 PDF。
|
||||
|
||||
---
|
||||
|
||||
## 7 功能规范
|
||||
|
||||
### 7.1 监督功能之间的交互
|
||||
|
||||
#### 7.1.1 概述
|
||||
|
||||
看门狗管理器监督一个或多个监督实体。每个监督实体可被 Alive 监督、Deadline 监督、Logical 监督监督，或其任意组合监督。
|
||||
|
||||
**监督流程**：
|
||||
|
||||
1. **本地监督状态**：对每个监督实体，根据启用的监督机制结果计算其本地状态。本地状态可以是：
|
||||
- `WDGM_LOCAL_STATUS_OK` — 监督通过
|
||||
- `WDGM_LOCAL_STATUS_EXPIRED` — 监督失败
|
||||
- `WDGM_LOCAL_STATUS_DEACTIVATED` — 该实体的监督被停用
|
||||
|
||||
2. **全局监督状态**：根据所有监督实体的本地状态计算全局状态。全局状态可以是：
|
||||
- `WDGM_GLOBAL_STATUS_OK` — 所有实体监督通过
|
||||
- `WDGM_GLOBAL_STATUS_FAILED` — 至少一个实体失败
|
||||
- `WDGM_GLOBAL_STATUS_STOPPED` — 全局监督已停止
|
||||
- `WDGM_GLOBAL_STATUS_DEACTIVATED` — 全局监督被停用
|
||||
|
||||
#### 7.1.2 核心可配置参数
|
||||
|
||||
> **[SWS_WdgM_01000]** ⌈看门狗管理器应支持以下可配置参数：
|
||||
> - 监督实体的数量
|
||||
> - 每个监督实体的检查点数量
|
||||
> - 每个实体的监督模式（Alive/Deadline/Logical 或其组合）
|
||||
> - Alive 监督的预期检查点到达次数
|
||||
> - Deadline 监督的最小和最大时间限制
|
||||
> - Logical 监督的检查点图
|
||||
> ⌋
|
||||
|
||||
#### 7.1.3 本地监督状态
|
||||
|
||||
本地监督状态机是看门狗管理器的核心。每个监督实体都有一个本地监督状态。
|
||||
|
||||
**状态转换**：
|
||||
|
||||
| 当前状态 | 事件 | 新状态 |
|
||||
|---|---|---|
|
||||
| `DEACTIVATED` | 监督被激活 | `OK` |
|
||||
| `OK` | 所有监督机制成功 | `OK` |
|
||||
| `OK` | 任一监督机制失败 | `EXPIRED` |
|
||||
| `EXPIRED` | 错误恢复成功 | `OK` |
|
||||
| `EXPIRED` | 监督被停用 | `DEACTIVATED` |
|
||||
|
||||
> **[SWS_WdgM_00099]** ⌈本地监督状态机应遵循上述转换规则。每个监督实体的本地状态应在 `WdgM_GetLocalStatus()` API 中可用。⌋
|
||||
|
||||
#### 7.1.4 全局监督状态
|
||||
|
||||
全局监督状态由所有监督实体的本地状态计算得出。
|
||||
|
||||
| 本地状态组合 | 全局状态 |
|
||||
|---|---|
|
||||
| 所有本地状态均为 `OK` | `WDGM_GLOBAL_STATUS_OK` |
|
||||
| 至少一个本地状态为 `EXPIRED` | `WDGM_GLOBAL_STATUS_FAILED` |
|
||||
| 所有本地状态均为 `DEACTIVATED` | `WDGM_GLOBAL_STATUS_DEACTIVATED` |
|
||||
| 看门狗管理器已停用 | `WDGM_GLOBAL_STATUS_STOPPED` |
|
||||
|
||||
> **[SWS_WdgM_00100]** ⌈全局监督状态应根据所有本地状态计算。全局状态应在 `WdgM_GetGlobalStatus()` API 中可用。⌋
|
||||
|
||||
#### 7.1.5 Alive 监督
|
||||
|
||||
Alive 监督用于监督周期性软件。配置指定了在给定时间窗口内每个检查点预期被到达的次数。
|
||||
|
||||
**核心参数**：
|
||||
- `WdgMSupervisedEntityAliveSupervisionCycle` — 监督周期
|
||||
- `WdgMExpectedAliveIndications` — 预期检查点到达次数
|
||||
- `WdgMMinMargin` — 允许的最小偏差
|
||||
- `WdgMMaxMargin` — 允许的最大偏差
|
||||
|
||||
**算法**：
|
||||
1. 在每个监督周期内，统计每个检查点的到达次数
|
||||
2. 比较实际次数与预期次数
|
||||
3. 如果实际次数在 `[预期-MinMargin, 预期+MaxMargin]` 范围内，Alive 监督通过
|
||||
4. 否则，设置本地状态为 `EXPIRED`
|
||||
|
||||
> **[SWS_WdgM_00186]** ⌈Alive 监督算法应在每个 `WdgMSupervisedEntityAliveSupervisionCycle` 内执行。⌋
|
||||
|
||||
#### 7.1.6 Deadline 监督
|
||||
|
||||
Deadline 监督用于监督非周期性软件。它检查从一个检查点到另一个检查点之间经过的时间是否在配置的最小和最大时间限制内。
|
||||
|
||||
**核心参数**：
|
||||
- `WdgMDeadlineMin` — 最小时间限制
|
||||
- `WdgMDeadlineMax` — 最大时间限制
|
||||
|
||||
**算法**：
|
||||
1. 记录起始检查点的 OS 计数器值
|
||||
2. 等待结束检查点被报告
|
||||
3. 当结束检查点被报告时，获取当前 OS 计数器值
|
||||
4. 计算经过的时间
|
||||
5. 如果时间在 `[WdgMDeadlineMin, WdgMDeadlineMax]` 范围内，监督通过
|
||||
6. 否则，设置本地状态为 `EXPIRED`
|
||||
|
||||
> **[SWS_WdgM_00187]** ⌈Deadline 监督应使用 OS 的 `GetElapsedCounterValue` 服务进行时间测量。⌋
|
||||
|
||||
#### 7.1.7 Logical 监督
|
||||
|
||||
Logical 监督检查监督实体的执行顺序。它基于检查点图（内部图和外部图）。
|
||||
|
||||
**核心元素**：
|
||||
- **检查点**：监督实体中的关键位置
|
||||
- **内部转换**：同一监督实体的两个检查点之间的允许转换
|
||||
- **外部转换**：不同监督实体的检查点之间的允许转换
|
||||
- **内部图**：内部转换的集合
|
||||
- **外部图**：外部转换的集合
|
||||
|
||||
**算法**：
|
||||
1. 每次报告检查点时，检查该转换是否在配置的图中被允许
|
||||
2. 如果从上一个检查点到当前检查点的转换是合法的，Logical 监督通过
|
||||
3. 否则，设置本地状态为 `EXPIRED`
|
||||
|
||||
> **[SWS_WdgM_00188]** ⌈Logical 监督应验证检查点转换的合法性。任何不合法的转换都将导致本地状态变为 `EXPIRED`。⌋
|
||||
|
||||
### 7.2 错误处理 / 故障恢复
|
||||
|
||||
#### 7.2.1 RTE 模式机制通知
|
||||
|
||||
看门狗管理器可通过 RTE 模式机制通知其他 BSW 模块关于全局状态的变化。
|
||||
|
||||
> **[SWS_WdgM_00194]** ⌈当全局监督状态变化时，看门狗管理器应通过 RTE 通知相关的 SW-C 或 BSW 模块。⌋
|
||||
|
||||
#### 7.2.2 在 WDGM_GLOBAL_STATUS_STOPPED 时报告 DEM
|
||||
|
||||
> **[SWS_WdgM_00195]** ⌈当全局监督状态变为 `STOPPED` 时，看门狗管理器应向 DEM 报告预定义事件。⌋
|
||||
|
||||
#### 7.2.3 分区重启 / 关闭
|
||||
|
||||
> **[SWS_WdgM_00196]** ⌈当检测到监督失败时，看门狗管理器可以触发受影响分区的重启或关闭。这通过调用 OS 的 `ControlIdle` 或 `TerminateApplication` 服务实现。⌋
|
||||
|
||||
#### 7.2.4 不设置看门狗触发条件
|
||||
|
||||
看门狗管理器的**关键反应**之一是**不再触发看门狗**。这会导致硬件看门狗在超时后复位 ECU。
|
||||
|
||||
> **[SWS_WdgM_00197]** ⌈当全局监督状态为 `FAILED` 时，看门狗管理器应停止触发看门狗，从而允许硬件看门狗执行 ECU 复位。⌋
|
||||
|
||||
#### 7.2.5 MCU 复位
|
||||
|
||||
> **[SWS_WdgM_00198]** ⌈看门狗管理器可以调用 `WdgM_PerformReset()` 函数触发立即的 MCU 复位。⌋
|
||||
|
||||
### 7.3 看门狗处理
|
||||
|
||||
#### 7.3.1 支持多个看门狗实例
|
||||
|
||||
看门狗管理器可管理多个看门狗实例。每个看门狗由看门狗驱动控制。
|
||||
|
||||
> **[SWS_WdgM_00199]** ⌈看门狗管理器应支持配置多个看门狗实例。⌋
|
||||
|
||||
#### 7.3.2 设置触发条件
|
||||
|
||||
> **[SWS_WdgM_00200]** ⌈在每个 `WdgM_MainFunction()` 调用周期内，看门狗管理器应通过 `WdgIf_SetTriggerCondition()` 设置每个看门狗实例的触发条件。⌋
|
||||
|
||||
#### 7.3.3 可配置参数
|
||||
|
||||
> **[SWS_WdgM_00201]** ⌈每个看门狗实例的以下参数应可配置：
|
||||
> - 触发周期
|
||||
> - 看门狗设备的引用
|
||||
> ⌋
|
||||
|
||||
#### 7.3.4 运行时错误
|
||||
|
||||
> **[SWS_WdgM_00202]** ⌈看门狗管理器应处理以下运行时错误：
|
||||
> - 触发看门狗失败
|
||||
> - 设置触发条件失败
|
||||
> ⌋
|
||||
|
||||
#### 7.3.5 瞬态故障
|
||||
|
||||
看门狗管理器可处理以下瞬态故障：
|
||||
|
||||
- 看门狗硬件故障
|
||||
- 配置错误
|
||||
|
||||
### 7.4 模式切换
|
||||
|
||||
#### 7.4.1 对监督状态的影响
|
||||
|
||||
> **[SWS_WdgM_00203]** ⌈当 WdgM 模式从一种模式切换到另一种模式时：
|
||||
> - 所有监督实体的本地状态被重置为 `DEACTIVATED`
|
||||
> - 全局状态被重置为 `OK`
|
||||
> - 监督根据新模式的配置重新启动
|
||||
> ⌋
|
||||
|
||||
#### 7.4.2 对看门狗的影响
|
||||
|
||||
> **[SWS_WdgM_00204]** ⌈当 WdgM 模式改变时，看门狗的触发条件应根据新模式的配置更新。⌋
|
||||
|
||||
#### 7.4.3 Sleep 期间的看门狗处理
|
||||
|
||||
> **[SWS_WdgM_00205]** ⌈在 Sleep 模式下，看门狗管理器应停止触发看门狗，以允许 ECU 进入低功耗状态。⌋
|
||||
|
||||
### 7.5 看门狗管理器配置
|
||||
|
||||
#### 7.5.1 模式无关的监督设置
|
||||
|
||||
每个监督实体的以下参数与模式无关：
|
||||
|
||||
- 监督模式（Alive/Deadline/Logical）
|
||||
- 监督周期
|
||||
- 错误处理配置
|
||||
|
||||
#### 7.5.2 模式相关参数
|
||||
|
||||
每个 WdgM 模式下可配置：
|
||||
|
||||
- 该模式下启用的监督实体
|
||||
- 每个实体的监督参数
|
||||
- 错误处理动作
|
||||
- 看门狗触发条件
|
||||
|
||||
### 7.6 错误分类
|
||||
|
||||
#### 7.6.1 开发错误
|
||||
|
||||
| 错误类型 | 相关错误代码 | 值 [十六进制] |
|
||||
|---|---|---|
|
||||
| API 服务调用时模块未初始化 | `WDGM_E_NO_INIT` | `0x00` |
|
||||
| API 服务调用时参数错误 | `WDGM_E_PARAM_CONFIG` | `0x01` |
|
||||
| API 服务调用时指针参数错误 | `WDGM_E_PARAM_POINTER` | `0x02` |
|
||||
| API 服务调用时参数超出范围 | `WDGM_E_PARAM_VALUE` | `0x03` |
|
||||
| 监督服务参数错误 | `WDGM_E_SUPERVISION_ID` | `0x04` |
|
||||
| 检查点 ID 错误 | `WDGM_E_CHECKPOINT_ID` | `0x05` |
|
||||
| 不允许的模式切换 | `WDGM_E_MODE` | `0x06` |
|
||||
| 已弃用的功能 | `WDGM_E_DEPRECATED` | `0x07` |
|
||||
|
||||
#### 7.6.2 运行时错误
|
||||
|
||||
| 错误类型 | 相关错误代码 | 值 [十六进制] |
|
||||
|---|---|---|
|
||||
| 监督失败 | `WDGM_E_RUNTIME_SUPERVISION_FAILURE` | `0x10` |
|
||||
| 触发看门狗失败 | `WDGM_E_TRIGGER_FAILURE` | `0x11` |
|
||||
|
||||
#### 7.6.3 瞬态故障
|
||||
|
||||
无。
|
||||
|
||||
#### 7.6.4 生产错误
|
||||
|
||||
| 错误类型 | 相关错误代码 |
|
||||
|---|---|
|
||||
| 全局监督状态为 STOPPED | `WDGM_E_GLOBAL_STATE_STOPPED` |
|
||||
|
||||
#### 7.6.5 扩展生产错误
|
||||
|
||||
无。
|
||||
|
||||
---
|
||||
|
||||
## 8 API 规范
|
||||
|
||||
### 8.1 导入类型
|
||||
|
||||
```c
|
||||
#include "Std_Types.h"
|
||||
#include "WdgM_GeneralTypes.h"
|
||||
```
|
||||
|
||||
### 8.2 类型定义
|
||||
|
||||
#### 8.2.1 WdgM_ConfigType
|
||||
|
||||
```c
|
||||
/* WdgM 配置结构体的前向声明 */
|
||||
typedef struct WdgM_ConfigType_s WdgM_ConfigType;
|
||||
```
|
||||
|
||||
### 8.3 函数定义
|
||||
|
||||
#### 8.3.1 WdgM_Init
|
||||
|
||||
```c
|
||||
/**
|
||||
* 初始化看门狗管理器
|
||||
* @param ConfigPtr 指向配置的指针
|
||||
*/
|
||||
void WdgM_Init(const WdgM_ConfigType* ConfigPtr);
|
||||
```
|
||||
|
||||
> **[SWS_WdgM_00011]** ⌈`WdgM_Init()` 应初始化所有监督实体并将所有本地状态设置为 `DEACTIVATED`。⌋
|
||||
|
||||
#### 8.3.2 WdgM_DeInit
|
||||
|
||||
```c
|
||||
/**
|
||||
* 反初始化看门狗管理器
|
||||
*/
|
||||
void WdgM_DeInit(void);
|
||||
```
|
||||
|
||||
> **[SWS_WdgM_00012]** ⌈`WdgM_DeInit()` 应停止所有监督并触发看门狗驱动。⌋
|
||||
|
||||
#### 8.3.3 WdgM_GetVersionInfo
|
||||
|
||||
```c
|
||||
/**
|
||||
* 获取看门狗管理器的版本信息
|
||||
* @param versioninfo 指向版本信息结构体的指针
|
||||
*/
|
||||
void WdgM_GetVersionInfo(Std_VersionInfoType* versioninfo);
|
||||
```
|
||||
|
||||
#### 8.3.4 WdgM_SetMode
|
||||
|
||||
```c
|
||||
/**
|
||||
* 设置看门狗管理器的运行模式
|
||||
* @param Mode 模式 ID
|
||||
* @return E_OK 成功，E_NOT_OK 失败
|
||||
*/
|
||||
Std_ReturnType WdgM_SetMode(WdgM_ModeType Mode);
|
||||
```
|
||||
|
||||
> **[SWS_WdgM_00014]** ⌈`WdgM_SetMode()` 应切换到指定模式。如果切换成功，所有监督实体根据新模式重新启动。⌋
|
||||
|
||||
#### 8.3.5 WdgM_GetMode
|
||||
|
||||
```c
|
||||
/**
|
||||
* 获取当前模式
|
||||
* @param Mode 指向当前模式的指针
|
||||
* @return E_OK 成功，E_NOT_OK 失败
|
||||
*/
|
||||
Std_ReturnType WdgM_GetMode(WdgM_ModeType* Mode);
|
||||
```
|
||||
|
||||
#### 8.3.6 WdgM_CheckpointReached
|
||||
|
||||
```c
|
||||
/**
|
||||
* 报告检查点已到达
|
||||
* @param SEid 监督实体 ID
|
||||
* @param CheckpointID 检查点 ID
|
||||
* @return E_OK 成功，E_NOT_OK 失败
|
||||
*/
|
||||
Std_ReturnType WdgM_CheckpointReached(WdgM_SupervisedEntityIdType SEid, WdgM_CheckpointIdType CheckpointID);
|
||||
```
|
||||
|
||||
> **[SWS_WdgM_00015]** ⌈`WdgM_CheckpointReached()` 应将由 SW-C 报告的检查点位置记录到 WdgM，并触发相关的监督机制。⌋
|
||||
|
||||
#### 8.3.7 WdgM_GetLocalStatus
|
||||
|
||||
```c
|
||||
/**
|
||||
* 获取监督实体的本地监督状态
|
||||
* @param SEid 监督实体 ID
|
||||
* @param Status 指向本地状态的指针
|
||||
* @return E_OK 成功，E_NOT_OK 失败
|
||||
*/
|
||||
Std_ReturnType WdgM_GetLocalStatus(WdgM_SupervisedEntityIdType SEid, WdgM_LocalStatusType* Status);
|
||||
```
|
||||
|
||||
#### 8.3.8 WdgM_GetGlobalStatus
|
||||
|
||||
```c
|
||||
/**
|
||||
* 获取全局监督状态
|
||||
* @param Status 指向全局状态的指针
|
||||
* @return E_OK 成功，E_NOT_OK 失败
|
||||
*/
|
||||
Std_ReturnType WdgM_GetGlobalStatus(WdgM_GlobalStatusType* Status);
|
||||
```
|
||||
|
||||
#### 8.3.9 WdgM_PerformReset
|
||||
|
||||
```c
|
||||
/**
|
||||
* 立即执行 MCU 复位
|
||||
*/
|
||||
void WdgM_PerformReset(void);
|
||||
```
|
||||
|
||||
#### 8.3.10 WdgM_GetFirstExpiredSEID
|
||||
|
||||
```c
|
||||
/**
|
||||
* 获取第一个触发监督失败的监督实体 ID
|
||||
* @param SEid 指向监督实体 ID 的指针
|
||||
* @return E_OK 成功，E_NOT_OK 失败
|
||||
*/
|
||||
Std_ReturnType WdgM_GetFirstExpiredSEID(WdgM_SupervisedEntityIdType* SEid);
|
||||
```
|
||||
|
||||
### 8.4 回调通知
|
||||
|
||||
无。
|
||||
|
||||
### 8.5 调度函数
|
||||
|
||||
#### 8.5.1 WdgM_MainFunction
|
||||
|
||||
```c
|
||||
/**
|
||||
* 看门狗管理器的主函数
|
||||
* 应在配置的时间周期内由 BSWS 调度器调用
|
||||
*/
|
||||
void WdgM_MainFunction(void);
|
||||
```
|
||||
|
||||
> **[SWS_WdgM_00016]** ⌈`WdgM_MainFunction()` 应执行所有监督功能并设置看门狗触发条件。⌋
|
||||
|
||||
### 8.6 预期接口
|
||||
|
||||
#### 8.6.1 强制接口
|
||||
|
||||
| API | 头文件 | 描述 |
|
||||
|---|---|---|
|
||||
| `GetElapsedCounterValue` | `Os.h` | 获取 OS 计数器值 |
|
||||
| `WdgIf_SetTriggerCondition` | `WdgIf.h` | 设置看门狗触发条件 |
|
||||
| `EcuM_GetState` | `EcuM.h` | 获取 ECU 状态 |
|
||||
|
||||
#### 8.6.2 可选接口
|
||||
|
||||
| API | 头文件 | 描述 |
|
||||
|---|---|---|
|
||||
| `Dem_ReportErrorStatus` | `Dem.h` | 报告 DEM 错误 |
|
||||
| `Det_ReportError` | `Det.h` | 报告开发错误 |
|
||||
|
||||
#### 8.6.3 可配置接口
|
||||
|
||||
无。
|
||||
|
||||
#### 8.6.4 作业结束通知
|
||||
|
||||
无。
|
||||
|
||||
### 8.7 服务接口
|
||||
|
||||
#### 8.7.1 监督的端口与端口接口
|
||||
|
||||
看门狗管理器提供以下服务端口用于 SW-C 通信：
|
||||
|
||||
- **WdgM_SUPERVISION**：监督服务
|
||||
- **WdgM_SUPERVISION_STATUS**：状态查询服务
|
||||
- **WdgM_MODE**：模式切换服务
|
||||
|
||||
#### 8.7.2 状态报告的端口与端口接口
|
||||
|
||||
> **摘要标记**：本节详细描述看门狗管理器的端口和端口接口配置（约 5-7 页），涉及多个接口定义和操作。完整内容请参见原文 PDF 第 89-96 页。
|
||||
|
||||
---
|
||||
|
||||
## 9 序列图
|
||||
|
||||
### 9.1 初始化
|
||||
|
||||
看门狗管理器的初始化过程：
|
||||
1. `EcuM` 调用 `WdgM_Init(ConfigPtr)`
|
||||
2. WdgM 初始化所有监督实体的状态为 `DEACTIVATED`
|
||||
3. WdgM 调用 `WdgIf_SetMode()` 初始化所有看门狗
|
||||
4. WdgM 设置初始模式
|
||||
5. 根据初始模式激活监督
|
||||
|
||||
> **摘要标记**：本节包含多个序列图，描述初始化、监督运行、错误处理、模式切换等场景的调用顺序。完整序列图见原文 PDF 第 97 页。
|
||||
|
||||
---
|
||||
|
||||
## 10 配置规范
|
||||
|
||||
### 10.1 参数区分
|
||||
|
||||
#### 10.1.1 静态配置参数
|
||||
|
||||
以下参数为静态配置（编译时确定）：
|
||||
- 监督实体数量
|
||||
- 检查点数量
|
||||
- 监督模式（Alive/Deadline/Logical）
|
||||
|
||||
#### 10.1.2 运行时配置参数
|
||||
|
||||
以下参数为运行时配置：
|
||||
- 监督实体启用/停用
|
||||
- 模式切换
|
||||
|
||||
#### 10.1.3 预编译选项
|
||||
|
||||
无。
|
||||
|
||||
### 10.2 容器与配置参数
|
||||
|
||||
> **摘要标记**：本节描述看门狗管理器的完整 ECUC 配置容器层次结构（10.2.1-10.2.16），涉及约 100+ 配置参数。完整 ECUC 定义请参见原文 PDF 第 98-120 页。
|
||||
|
||||
**主要容器**：
|
||||
|
||||
- **WdgM**（顶层容器，10.2.2）
|
||||
- **WdgMGeneral**（10.2.3）— 通用设置
|
||||
- **WdgMSupervisedEntity**（10.2.4）— 监督实体配置
|
||||
- **WdgMCheckpoint**（10.2.5）— 检查点配置
|
||||
- **WdgMInternalTransition**（10.2.6）— 内部转换
|
||||
- **WdgMWatchdog**（10.2.7）— 看门狗设备配置
|
||||
- **WdgMConfigSet**（10.2.8）— 配置集
|
||||
- **WdgMDemEventParameterRefs**（10.2.9）— DEM 事件引用
|
||||
- **WdgMMode**（10.2.10）— 模式配置
|
||||
- **WdgMAliveSupervision**（10.2.11）— Alive 监督
|
||||
- **WdgMDeadlineSupervision**（10.2.12）— Deadline 监督
|
||||
- **WdgMExternalLogicalSupervision**（10.2.13）— 外部逻辑监督
|
||||
- **WdgMExternalTransition**（10.2.14）— 外部转换
|
||||
- **WdgMTrigger**（10.2.15）— 触发条件
|
||||
- **WdgMLocalStatusParams**（10.2.16）— 本地状态参数
|
||||
|
||||
### 10.3 已发布信息
|
||||
|
||||
无。
|
||||
|
||||
---
|
||||
|
||||
## 11 附录 A：Alive 监督算法的示例实现
|
||||
|
||||
本附录提供 Alive 监督算法的两种实现场景示例。
|
||||
|
||||
### 11.1 场景 A
|
||||
|
||||
最简单的 Alive 监督场景：一个监督实体具有一个检查点，预期在每个监督周期内到达 1 次。
|
||||
|
||||
**配置**：
|
||||
- 监督实体 ID：0
|
||||
- 检查点 ID：0
|
||||
- 预期到达次数：1
|
||||
- 监督周期：100ms
|
||||
- 最小余量：0
|
||||
- 最大余量：1
|
||||
|
||||
**算法伪代码**：
|
||||
```
|
||||
每个监督周期：
|
||||
计数 = 0
|
||||
等待 CheckpointReached(0, 0) 调用
|
||||
if 计数 在 [0, 1] 范围内:
|
||||
本地状态 = OK
|
||||
else:
|
||||
本地状态 = EXPIRED
|
||||
```
|
||||
|
||||
### 11.2 场景 B
|
||||
|
||||
多个检查点场景：监督一个 SW-C 的多个执行点。
|
||||
|
||||
**配置**：
|
||||
- 监督实体 ID：0
|
||||
- 检查点 0（入口）
|
||||
- 检查点 1（中间）
|
||||
- 检查点 2（出口）
|
||||
- 预期每个检查点到达次数：1
|
||||
- 监督周期：200ms
|
||||
|
||||
**算法伪代码**：
|
||||
```
|
||||
每个监督周期：
|
||||
计数0 = 0; 计数1 = 0; 计数2 = 0
|
||||
监听 CheckpointReached() 调用
|
||||
if 计数0 != 1 OR 计数1 != 1 OR 计数2 != 1:
|
||||
本地状态 = EXPIRED
|
||||
else:
|
||||
本地状态 = OK
|
||||
```
|
||||
|
||||
> **摘要标记**：附录 A 的其余部分（场景 A 和 B 的图示）请参见原文 PDF 第 121-124 页。
|
||||
|
||||
---
|
||||
|
||||
## 12 不适用的需求
|
||||
|
||||
无。
|
||||
|
||||
---
|
||||
|
||||
## 翻译说明
|
||||
|
||||
本文档为 AUTOSAR SWS WatchdogManager（文档 ID 080，125 页，4.4.0 版）的中文翻译。翻译策略：
|
||||
|
||||
1. **完整翻译**：封面、文档标识、变更历史、目录、前 7 个核心章节（前言、监督功能、错误处理、模式切换、配置）、所有 API 规范、附录 A 的算法描述
|
||||
2. **摘要处理**：
|
||||
- 需求可追溯性表：列出前 10 行代表性映射，完整表（60+ 行）见原文 PDF
|
||||
- 容器配置（10.2 节）：列出主要容器标题，详细 ECUC 定义见原文 PDF
|
||||
- 序列图：仅翻译主要流程描述，完整图表见原文 PDF
|
||||
3. **保留内容**：所有 API 标识符、需求 ID（`SWS_WdgM_xxxxx`）、AUTOSAR 方框符 `⌈⌋`、ASIL 等级引用、文档间交叉引用
|
||||
|
||||
本文档介绍了看门狗管理器（WdgM）—— AUTOSAR 服务层的基础软件模块，用于：
|
||||
- **Alive 监督**：监督周期性软件的时序
|
||||
- **Deadline 监督**：监督非周期性软件的时间约束
|
||||
- **Logical 监督**：监督程序的控制流（执行顺序）
|
||||
@@ -0,0 +1,629 @@
|
||||
# 安全扩展规范（Specification of Safety Extensions）
|
||||
|
||||
| 字段 | 内容 |
|
||||
|---|---|
|
||||
| **文档标题** | 安全扩展规范（Specification of Safety Extensions） |
|
||||
| **文档所有者** | AUTOSAR |
|
||||
| **文档责任方** | AUTOSAR |
|
||||
| **文档标识号** | 671 |
|
||||
| **文档状态** | Final（正式发布） |
|
||||
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
|
||||
| **所属标准版本** | 4.4.0 |
|
||||
|
||||
---
|
||||
|
||||
## 文档变更历史（Document Change History）
|
||||
|
||||
| 日期 | 版本 | 变更人 | 变更描述 |
|
||||
|---|---|---|---|
|
||||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性变更 |
|
||||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 细微修正 / 澄清 / 编辑性变更；详细信息请参考 ChangeDocumentation |
|
||||
| 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 | 基于概念"Safety Extensions"的初始规范 |
|
||||
|
||||
---
|
||||
|
||||
## 目录（Table of Contents）
|
||||
|
||||
1. [引言](#1-引言)
|
||||
- 1.1 [概述](#11-概述)
|
||||
- 1.2 [范围](#12-范围)
|
||||
- 1.3 [文档约定](#13-文档约定)
|
||||
- 1.4 [缩写](#14-缩写)
|
||||
- 1.5 [术语词汇表](#15-术语词汇表)
|
||||
- 1.6 [指南](#16-指南)
|
||||
2. [需求追踪](#2-需求追踪)
|
||||
3. [安全扩展概述](#3-安全扩展概述)
|
||||
4. [安全需求](#4-安全需求)
|
||||
5. [安全完整性等级](#5-安全完整性等级)
|
||||
6. [安全需求的可追溯性与分配](#6-安全需求的可追溯性与分配)
|
||||
7. [安全措施](#7-安全措施)
|
||||
8. [应用说明](#8-应用说明)
|
||||
9. [附录 A 提到的类表](#附录-a-提到的类表)
|
||||
|
||||
---
|
||||
|
||||
## 参考文献
|
||||
|
||||
- **[1]** Requirements on Safety Extensions
|
||||
`AUTOSAR_RS_SafetyExtensions`
|
||||
- **[2]** Standardization Template
|
||||
`AUTOSAR_TPS_StandardizationTemplate`
|
||||
- **[3]** ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition
|
||||
http://www.iso.org
|
||||
- **[4]** Methodology
|
||||
`AUTOSAR_TR_Methodology`
|
||||
|
||||
---
|
||||
|
||||
## 1 引言
|
||||
|
||||
### 1.1 概述
|
||||
|
||||
本文档包含 AUTOSAR 安全扩展的规范，并实现 [1] 中陈述的需求。安全扩展通过现有的（通用）AUTOSAR 元模型概念表达。在后续版本中可能会引入原生元模型概念。第 3 节提供了关于这些扩展的更详细概述。
|
||||
|
||||
### 1.2 范围
|
||||
|
||||
本文档的范围涵盖了应在 AUTOSAR 上下文中实现 ISO 26262 开发的安全扩展。这些扩展允许安全信息的标准化交换，并提供 ISO 26262 要求的不同供应商和工具之间一致管理的基础。
|
||||
|
||||
本文档不是关于功能安全的一般介绍，也不是关于 ISO 26262 的具体介绍。其他安全标准或指南（如 IEC 61508 或 MISRA）不在范围内。
|
||||
|
||||
### 1.3 文档约定
|
||||
|
||||
AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中指定的表，参见标准化模板的"Support for Traceability"章节（[2]）。
|
||||
|
||||
应使用 [TPS_STDT_00053] 中指定的义务表达的口头形式来表示需求，参见标准化模板的"Support for Traceability"章节（[2]）。
|
||||
|
||||
### 1.4 缩写
|
||||
|
||||
| 缩写 | 含义 |
|
||||
|---|---|
|
||||
| **ASIL** | Automotive Safety Integrity Level（汽车安全完整性等级） |
|
||||
| **DC** | Diagnostic Coverage（诊断覆盖率） |
|
||||
| **ECC** | Error Correction Code（纠错码） |
|
||||
| **EDC** | Error Detection Code（错误检测码） |
|
||||
| **HARA** | Hazard Analysis and Risk Assessment（危险分析与风险评估） |
|
||||
| **HW** | Hardware（硬件） |
|
||||
| **FSC** | Functional Safety Concept（功能安全概念） |
|
||||
| **TSC** | Technical Safety Concept（技术安全概念） |
|
||||
| **SEooC** | Safety Element out of Context（上下文外安全元素） |
|
||||
| **SM** | Safety Mechanism or Measure（安全机制或措施） |
|
||||
| **SW** | Software（软件） |
|
||||
| **SWC** | Software Component（软件组件） |
|
||||
| **URI** | Uniform Resource Identifier（统一资源标识符） |
|
||||
| **URL** | Uniform Resource Locator（统一资源定位符） |
|
||||
|
||||
**表 1.1**：缩写
|
||||
|
||||
### 1.5 术语词汇表
|
||||
|
||||
通常，本文档将使用 ISO 26262-1 词汇（参见 [3]）中定义的安全相关术语。为便于说明，表 1.2 列出了一些与 AUTOSAR 相关的术语及其定义。
|
||||
|
||||
| 术语 | 定义 |
|
||||
|---|---|
|
||||
| **ASIL 属性** | 系统元素的 ASIL 指定了为避免不合理的残余风险而需要应用的 ISO 26262 必要需求和安全措施。详见第 5 节。 |
|
||||
| **故障、失效、错误** | 故障（Fault）是一种异常状况，可能导致硬件或软件元素失效。错误（Error）描述了值或条件中产生的偏差，是（一组）故障的结果。失效（Failure）定义了硬件或软件元素执行其功能的能力的终止（参见 [3]）。故障包括系统性软件故障（即"缺陷"、"Bug"）、随机硬件故障（例如由于设备的应力 / 老化）以及系统性硬件故障。 |
|
||||
| **安全状态** | 安全状态总是在系统级别描述（参见 [3]）。某个软件状态可能是此"系统状态"的一部分，或者这种关系未定义（例如，如果运行软件的微控制器在安全状态下被关闭）。 |
|
||||
| **安全机制** | 安全机制是一种技术解决方案 [...]，用于检测故障或控制失效以实现或维持安全状态（参见 [3]）。本规范中使用的术语正是这种更广泛的含义，因此不仅 AUTOSAR 安全机制（"安全特性"）可以被描述，而且系统的任何 HW/SW 或组合解决方案都可以被描述，因为 AUTOSAR 软件是为这些解决方案实现的（参见第 7 节）。 |
|
||||
| **安全措施** | 安全措施是避免系统性失效以及检测随机硬件失效或控制失效的活动或解决方案（参见 [3]）。因此，安全措施可能仅定义一个过程活动，例如专用测试方法、附加的代码验证等（参见第 7 节）。本规范将使用术语"安全措施"来概括开发期间的活动以及实施到系统中的安全措施。 |
|
||||
| **安全需求** | ISO 26262 定义了安全需求的层次结构：安全目标、技术、硬件和软件。在本文档中，安全需求可以是其中任何一种。有关详细信息，请参考 ISO 26262-3、4 和 9。 |
|
||||
|
||||
**表 1.2**：术语词汇表
|
||||
|
||||
### 1.6 指南
|
||||
|
||||
应引用现有的规范（以单一需求的形式）。与这些规范的差异被指定为附加需求。所有需求应具有以下属性：
|
||||
|
||||
- **冗余性（Redundancy）**：需求不应在一个需求内或其他需求中重复。
|
||||
- **清晰性（Clearness）**：所有需求应仅允许一种解释的可能性。使用的未在词汇表中的技术术语必须定义。
|
||||
- **原子性（Atomicity）**：每个需求应仅包含一个需求。如果需求不能进一步拆分为更多需求，则该需求是原子的。
|
||||
- **可测试性（Testability）**：需求应通过分析、评审或测试进行测试。
|
||||
- **可追溯性（Traceability）**：在任何时候都应可见需求的来源和状态。
|
||||
|
||||
---
|
||||
|
||||
## 2 需求追踪
|
||||
|
||||
下表引用 [1] 中指定的需求，并将其链接到这些需求的实现。
|
||||
|
||||
| 需求 | 描述 | 由以下需求满足 |
|
||||
|---|---|---|
|
||||
| `[RS_SAFEX_00001]` | AUTOSAR 模型中可表达的安全需求 | `[TPS_SAFEX_00101]` |
|
||||
| `[RS_SAFEX_00002]` | 安全需求至少与其他需求一样具有表达力 | `[TPS_SAFEX_00101]` |
|
||||
| `[RS_SAFEX_00003]` | 通过 URI 描述的安全需求 | `[TPS_SAFEX_00105]` |
|
||||
| `[RS_SAFEX_00004]` | 可区分的安全需求 | `[TPS_SAFEX_00102]` |
|
||||
| `[RS_SAFEX_00005]` | 安全需求的唯一标识 | `[TPS_SAFEX_00103]` |
|
||||
| `[RS_SAFEX_00006]` | 安全需求的状态信息 | `[TPS_SAFEX_00104]` |
|
||||
| `[RS_SAFEX_00007]` | 安全需求的层次结构 | `[TPS_SAFEX_00301]` |
|
||||
| `[RS_SAFEX_00008]` | 安全需求的分解 | `[TPS_SAFEX_00302]` |
|
||||
| `[RS_SAFEX_00009]` | 独立性需求的规范 | `[TPS_SAFEX_00303]` |
|
||||
| `[RS_SAFEX_00010]` | 安全需求的 ASIL 属性 | `[TPS_SAFEX_00201]` |
|
||||
| `[RS_SAFEX_00011]` | AUTOSAR 元素的 ASIL 属性 | `[TPS_SAFEX_00202]` |
|
||||
| `[RS_SAFEX_00012]` | 安全需求的可追溯性 | `[TPS_SAFEX_00101]` |
|
||||
| `[RS_SAFEX_00013]` | 安全措施的可追溯性 | `[TPS_SAFEX_00401]` |
|
||||
| `[RS_SAFEX_00014]` | 安全需求的分配 | `[TPS_SAFEX_00306]`、`[TPS_SAFEX_00308]` |
|
||||
| `[RS_SAFEX_00015]` | AUTOSAR 模型中可表达的安全措施 | `[TPS_SAFEX_00401]` |
|
||||
| `[RS_SAFEX_00016]` | 安全措施的文本描述 | `[TPS_SAFEX_00401]` |
|
||||
| `[RS_SAFEX_00017]` | 安全措施的唯一标识 | `[TPS_SAFEX_00402]` |
|
||||
| `[RS_SAFEX_00018]` | 安全需求与安全措施之间的关系 | `[TPS_SAFEX_00307]` |
|
||||
| `[RS_SAFEX_00022]` | 安全措施的分配 | `[TPS_SAFEX_00305]`、`[TPS_SAFEX_00309]` |
|
||||
| `[RS_SAFEX_00023]` | 作为特殊安全措施的安全机制 | `[TPS_SAFEX_00401]` |
|
||||
|
||||
---
|
||||
|
||||
## 3 安全扩展概述
|
||||
|
||||
安全是汽车系统设计和开发中的关键问题之一。ISO 26262 [3] 定义了功能安全的当前标准，影响几乎所有的开发活动，包括软件规范、设计和实现。本文档支持在 AUTOSAR 上下文中标准化交换此类安全信息，并为 ISO 26262 要求的一致管理提供基础。
|
||||
|
||||
AUTOSAR 标准已经通过提供许多可用于实现安全软件的功能来解决功能安全问题，例如端到端保护、程序流监控、内存分区、用户 / 监督模式等（参见 [?, ] 以获取概述）。这些安全机制被视为 AUTOSAR 系统设计的组成部分。然而，ISO 26262 对功能安全软件开发的其他要求需要解决，特别是以下几点：
|
||||
|
||||
- **安全需求** —— 与其他需求明确区分开来，并满足 ISO 26262 第 4 和 8 部分规定的要求（第 4 节）。
|
||||
- **安全完整性等级** —— 对于每个 AUTOSAR 元素，遵循 ISO 26262-3 的模式（第 5 节）。
|
||||
- **根据 ISO 26262-9 中给出的需求分解安全需求**（第 6 节）。
|
||||
- **根据 ISO 26262 第 4、6 和 8 部分追溯和分配安全需求和安全措施**（第 6 节）。
|
||||
- **ISO 26262-4 要求的安全措施和安全机制**（第 7 节）。这超出了 AUTOSAR 中存在的纯 SW 安全机制，并引入了一种抽象方式来引用系统架构的任何安全措施。
|
||||
|
||||
本规范遵循重用 AUTOSAR 可用文档功能的方法来解决这些需求。这意味着安全扩展定义了规则，通过使用现有的元模型概念（例如 `StructuredReq`、`TraceableText`、`trace`）来交换上述工作产品。因此，AUTOSAR 规范保持向后兼容，并且可以同时包含用于安全 SWC 开发和配置的统一的、工具可处理的安全信息（参见 RS-SafetyExtensions 需求 `[RS_SAFEX_00020]` 和 `[RS_SAFEX_00021]`）。
|
||||
|
||||
系统的安全需求层次结构（ISO 26262 中的项目开发）及其与 AUTOSAR 软件架构的关系如图 3.1 所示。安全需求的层次结构从为系统的危险 / 危险事件识别的安全目标开始。ASIL 作为属性在每个安全目标处维护，并通过后续级别的功能安全需求（作为 FSC 的一部分）和技术安全需求（作为 TSC 的一部分）一致地继承。后者将细化为 SW 和 HW 安全需求。
|
||||
|
||||
每个安全需求 1 必须正确分配给系统架构的元素，即组件、HW、SW 或两者（HW 和 SW）。因此，AUTOSAR 规范的元素可能会收到一个 ASIL，表明它处于 ISO 26262 开发的范围内。
|
||||
|
||||
> 1 功能安全需求被分配给更高级别的功能 / 逻辑架构。
|
||||
|
||||
**图 3.1**：安全需求的层次结构及其到系统架构元素的分配
|
||||
|
||||
在安全需求不可用或不会与规范一起交换的情况下，AUTOSAR 实现必须至少意识到该元素在安全上下文中使用。这是通过将 ASIL 属性附加到独立于分配的 AUTOSAR 元素来实现的。特别是在 SEooC 开发的情况下，即安全需求在开发时不完全已知，ASIL 属性通过将假设与最终确定的安全需求进行匹配来支持后续开发阶段此类部分的集成和验证。
|
||||
|
||||
从 AUTOSAR 元素的角度来看，分配的安全需求的实现通常依赖于系统上下文。例如，SWC 的实现者应知道底层处理器架构是否支持内存保护（例如通过 ECC / EDC / MMU / MPU），以便正确实现安全相关数据的处理。特别是安全需求到架构其他元素的分解和分配 —— 以及支持部件的约束和特征 —— 需要在开发时已知。对于大多数错误检测和错误处理、降级或时序方面，情况通常如此。例如，图 3.1 中的系统摘录表明外部 HW 看门狗的可用性，它可能是错误处理程序（例如截止时间或输出监控）中的支持元素。示例应用软件可能依赖于这种安全机制来处理组件本身无法检测的某些故障。
|
||||
|
||||
为了传递与 AUTOSAR 软件的开发、集成和配置相关的"安全上下文"相关信息，本规范除安全需求外，还提供了安全措施或安全机制的抽象。图 3.2 显示了软件堆栈和 / 或 ECU 硬件中可用不同安全机制的抽象概念。
|
||||
|
||||
**图 3.2**：安全措施、安全需求及其到架构元素的分配
|
||||
|
||||
如图所示，（分解的）安全需求首先映射到安全机制的抽象定义（此处：SM_E2E）。在后续步骤中，安全机制被分配给 AUTOSAR 模型的某些元素。如果安全机制代表任何其他技术，则此分配仅是隐式的（不属于 AUTOSAR）。这允许例如系统集成商验证分解中的免干扰是否在不同技术之间充分实现。请注意，此抽象也是有用的，例如，如果 AUTOSAR（实现）元素在 OEM 供应商之间的分布式工作中尚不可用，但系统工程师已经希望确定哪些方面以何种方式受到安全措施的保护。
|
||||
|
||||
定义安全需求或安全措施、分配安全需求等各个活动在 AUTOSAR 方法论中描述（参见 [4]）。因此，该方法论形式上满足了 [1] 中的需求 `[RS_SAFEX_00024]`。
|
||||
|
||||
---
|
||||
|
||||
## 4 安全需求
|
||||
|
||||
本章定义如何将安全需求映射到 AUTOSAR 概念。基本上，安全需求遵循与正常需求相同的基本原理，但必须满足附加条件以符合 ISO 26262 需求（参见 [3] 第 8 部分第 6.4.2 条）。这主要包括在 AUTOSAR 中以以下方式处理的附加属性和特征：
|
||||
|
||||
- **安全需求应被明确标识为安全需求**（参见 ISO 26262-8，第 6.4.2.1 条）。为此，需求通过由 `StructuredReq` 继承的 `category` 属性进行标记。
|
||||
- **应提供安全需求到（软件）架构元素的分配信息**（参见 ISO 26262-8，第 6.4.2.3 条）。安全需求通过 `trace` 映射到 AUTOSAR 架构的任何对象。
|
||||
- **安全需求应具有唯一标识**（ISO 26262-8，第 6.4.2.5.a 条），该标识在需求的整个生命周期中保持不变。本规范将对安全需求的 `shortName` 使用提出附加需求。
|
||||
- **安全需求应具有状态属性**（ISO 26262-8，第 6.4.2.5.b 条）。状态属性不同于为需求定义的 AUTOSAR 生命周期信息，因此它映射到 `Sdg` 属性。
|
||||
- **安全需求应具有 ASIL**（ISO 26262-8，第 6.4.2.5.c 条）。ASIL 属性映射到 `Sdg` 属性。
|
||||
- **安全需求应沿设计级别按层次结构构建**，每个应维护对层次结构上一级的源的引用（ISO 26262-8，第 6.4.3.1 条和第 6.4.3.2 条）。由于 AUTOSAR 允许将需求追溯为 `TraceableText`，因此不需要扩展来表达这些层次依赖性。
|
||||
- **如果应用 ASIL 分解**，则分解必须遵循 ISO 26262-9 第 5 条中定义的许多规则。本规范引入了一种特殊的 trace 类型，支持在每个安全需求上单独应用 ASIL 分解的概念。此外，ASIL 分解符号在 ASIL 属性中得到支持，例如 ASIL B(D)。
|
||||
|
||||
> **[TPS_SAFEX_00101]** 安全需求的描述 ⌈安全需求应使用 `[TPS_STDT_00060]` 中定义的 `StructuredReq` 作为正常需求进行描述。描述应包含需求的内容。⌋
|
||||
> c(`RS_SAFEX_00001`、`RS_SAFEX_00002`、`RS_SAFEX_00012`)
|
||||
|
||||
请注意，这无缝集成在 AUTOSAR 规范定义的文本可追溯性中。
|
||||
|
||||
> **[TPS_SAFEX_00103]** 安全需求的唯一标识符 ⌈安全需求应在 AUTOSAR 项目的范围内收到一个唯一 ID。该 ID 应作为 `shortName` 维护，以供进一步引用该需求，并对应于一般规则 `[TPS_GST_00021]`。⌋
|
||||
> c(`RS_SAFEX_00005`)
|
||||
|
||||
请注意，安全需求标识符因此比 `[constr_2508]` 定义的正常短名称更严格。`shortName` 用作全局唯一 ID，类似于 [constr_2538] 中描述的其他元素的唯一性。此外，处理安全扩展的工具可以利用 `uuid` 属性来持久化工具相关的标识符。
|
||||
|
||||
> **[TPS_SAFEX_00102]** 安全需求的类型 ⌈安全需求应通过 `StructuredReq` 的 `category` 属性明确标记为安全需求，设置为以下之一：
|
||||
> - `SAFETY_GOAL`
|
||||
> - `SAFETY_FUNCTIONAL`
|
||||
> - `SAFETY_TECHNICAL`
|
||||
> - `SAFETY_SOFTWARE`
|
||||
> - `SAFETY_HARDWARE`
|
||||
> - `SAFETY_EXTERNAL`
|
||||
>
|
||||
> 这些值在安全上下文中扩展了 [2] 中 [constr_2540] 中定义的值。⌋
|
||||
> c(`RS_SAFEX_00004`)
|
||||
|
||||
ASIL 属性在 `[TPS_SAFEX_00201]` 中定义。
|
||||
|
||||
> **[TPS_SAFEX_00104]** 状态属性 ⌈安全需求应作为包含 `Sdg` 数据字段（`gid="SAFEX"`）的 `AdminData` 接收状态属性。XML 内容应包含一个具有属性 `gid="STATUS"` 的 `Sd` 元素。⌋
|
||||
> c(`RS_SAFEX_00006`)
|
||||
|
||||
状态属性的值未规定，是实现特定的。
|
||||
|
||||
出于各种原因，在 AUTOSAR 项目和 / 或一组 AUTOSAR XML 文档的范围内交换整个安全需求层次结构是不可行的。例如，对 HW 安全需求或安全目标的引用可能被有意排除，或者安全需求可能驻留在需求数据库中。为了支持链接此类驻留在 AUTOSAR 之外的安全需求，本规范引入了**外部安全需求**的概念。
|
||||
|
||||
> **[TPS_SAFEX_00105]** 外部安全需求 ⌈应作为引用包含在 AUTOSAR 文档中的外部安全需求应标记为 `category` 设置为 `SAFETY_EXTERNAL`，且描述应仅包含到安全需求所在位置的 Xfile URI。⌋
|
||||
> c(`RS_SAFEX_00003`)
|
||||
|
||||
可选地，可以根据 `[TPS_SAFEX_00201]` 和 `[TPS_SAFEX_00104]` 中的定义设置（缓存）ASIL 和 / 或状态属性以及 `tool` 和 `toolVersion`，以方便使用。
|
||||
|
||||
下面的列表显示了安全需求如何在 AUTOSAR XML 中表达的示例（注：此列表包含从本文档后续章节中引入的规范项派生的元素）：
|
||||
|
||||
**列表 4.1**：AUTOSAR XML 中安全需求的表示
|
||||
|
||||
```xml
|
||||
<!-- 技术安全需求 -->
|
||||
<STRUCTURED-REQ>
|
||||
<SHORT-NAME>SysSafReq05</SHORT-NAME>
|
||||
<LONG-NAME>
|
||||
<L-4 L="EN">CL15_ON light switch HW lib</L-4>
|
||||
</LONG-NAME>
|
||||
<CATEGORY>SAFETY_TECHNICAL</CATEGORY>
|
||||
<ADMIN-DATA>
|
||||
<SDGS>
|
||||
<SDG GID="SAFEX">
|
||||
<SD GID="ASIL">B</SD>
|
||||
<SD GID="STATUS">PROPOSED</SD>
|
||||
</SDG>
|
||||
</SDGS>
|
||||
</ADMIN-DATA>
|
||||
<TRACE-REFS>
|
||||
<!-- 到上一级层次结构的可追溯性链接（此处：功能安全需求） -->
|
||||
<TRACE-REF DEST="STRUCTURED-REQ" BASE="SAFEX">FSR02</TRACE-REF>
|
||||
</TRACE-REFS>
|
||||
<TYPE>Valid</TYPE>
|
||||
<DESCRIPTION>
|
||||
<P>
|
||||
<L-1 L="EN">当 CL15ON==1 时，FLM ECU 仅在 HW_LB==1 条件连续 20 ms 为真时才应关闭灯。（CAN 消息：CL15_01 CAN 信号：CL15ON 布尔值，'1' 表示 clamp 15 设置为 on，'0' 表示 clamp 15 设置为 off）</L-1>
|
||||
</P>
|
||||
</DESCRIPTION>
|
||||
<RATIONALE />
|
||||
<DEPENDENCIES />
|
||||
<USE-CASE />
|
||||
<SUPPORTING-MATERIAL />
|
||||
</STRUCTURED-REQ>
|
||||
|
||||
<!-- 外部技术安全需求 -->
|
||||
<STRUCTURED-REQ>
|
||||
<SHORT-NAME>SysSafReq42</SHORT-NAME>
|
||||
<LONG-NAME>
|
||||
<L-4 L="EN"></L-4>
|
||||
</LONG-NAME>
|
||||
<CATEGORY>SAFETY_EXTERNAL</CATEGORY>
|
||||
<ADMIN-DATA>
|
||||
<SDGS>
|
||||
<SDG GID="SAFEX">
|
||||
<SD GID="ASIL">C</SD>
|
||||
<SD GID="STATUS">ACCEPTED</SD>
|
||||
</SDG>
|
||||
</SDGS>
|
||||
</ADMIN-DATA>
|
||||
<TRACE-REFS>
|
||||
<TRACE-REF DEST="STRUCTURED-REQ" BASE="SAFEX">FSR02</TRACE-REF>
|
||||
</TRACE-REFS>
|
||||
<TYPE>Valid</TYPE>
|
||||
<DESCRIPTION>
|
||||
<P>
|
||||
<L-1 L="FOR-ALL">
|
||||
<XFILE>
|
||||
<SHORT-NAME>SysSafReq42</SHORT-NAME>
|
||||
<URL>http://requirements.mycompany.com:6777/db/prj/safety/SysSafReq42</URL>
|
||||
<TOOL>My Requirements Tool</TOOL>
|
||||
<TOOL-VERSION>9.3.1</TOOL-VERSION>
|
||||
</XFILE>
|
||||
</L-1>
|
||||
</P>
|
||||
</DESCRIPTION>
|
||||
<RATIONALE />
|
||||
<DEPENDENCIES />
|
||||
<USE-CASE />
|
||||
<SUPPORTING-MATERIAL/>
|
||||
</STRUCTURED-REQ>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5 安全完整性等级
|
||||
|
||||
本规范旨在支持 ISO 26262 [3] 的汽车安全完整性等级（ASIL）。其他安全完整性等级将不被考虑，并不在本文档的范围内。
|
||||
|
||||
ASIL 作为 ISO 26262-3 概念阶段中 HARA 的一部分确定，并分配给每个安全目标。系统设计 —— 最终是软件架构 —— 将通过安全需求到技术 / 软件架构的分配（参见第 3 节，详见第 6 节对安全需求的分配）将此 ASIL 作为属性继承。
|
||||
|
||||
> **[TPS_SAFEX_00201]** 安全需求的 ASIL 属性 ⌈根据第 4 节定义的安全需求应接收 ASIL 属性。ASIL 存储在包含 `Sdg` 数据（`gid="SAFEX"`）的 `AdminData` 中。此元素的内容应包含一个具有属性 `gid="ASIL"` 的 `Sd` 元素。此属性的有效值为：
|
||||
> - `QM`
|
||||
> - `A`
|
||||
> - `B`
|
||||
> - `C`
|
||||
> - `D`
|
||||
> - `QM(A)`
|
||||
> - `QM(B)`
|
||||
> - `QM(C)`
|
||||
> - `QM(D)`
|
||||
> - `A(B)`
|
||||
> - `A(C)`
|
||||
> - `A(D)`
|
||||
> - `B(B)`
|
||||
> - `B(C)`
|
||||
> - `B(D)`
|
||||
> - `C(C)`
|
||||
> - `C(D)`
|
||||
> - `D(D)`
|
||||
> ⌋
|
||||
> c(`RS_SAFEX_00010`)
|
||||
|
||||
请注意，括号表示法用于表示分解的安全需求。在本规范中，我们将原始 ASIL（即括号中的值）称为分解前的上下文 ASIL，因为它属于安全目标的上下文。
|
||||
|
||||
> **[constr_6200]** 安全目标没有分解的 ASIL ⌈如果安全需求的类型为 `SAFETY_GOAL`，则 ASIL 属性的有效值限制为：`QM`、`A`、`B`、`C` 或 `D`。⌋
|
||||
> c()
|
||||
|
||||
> **[TPS_SAFEX_00202]** AUTOSAR 元素的 ASIL（可选） ⌈如果至少有一个安全需求被分配给某个 AUTOSAR 元素，则该元素应接收 ASIL 属性。ASIL 应作为 `Sdg` 数据（`gid="SAFEX"`）添加到 XML 的 `AdminData` 部分。XML 内容应包含一个具有属性 `gid="ASIL"` 的 `Sd` 元素，有效值与 `[TPS_SAFEX_00201]` 中相同。⌋
|
||||
> c(`RS_SAFEX_00011`)
|
||||
|
||||
请注意，根据 `[TPS_SAFEX_00202]`，元素的 ASIL 是可选的。1 如果未在元素处指定 ASIL，则其语义是从所有已分配的安全需求中派生为最高 ASIL。
|
||||
|
||||
> 1 这在 SEooC 或延续开发中可能很有用，其中现有规范在实施后与安全需求连接。
|
||||
|
||||
> **[constr_6201]** ASIL 值的一致性 ⌈AUTOSAR 元素的 ASIL 和已分配的安全需求应一致。如果元素处的值等于或高于已分配安全需求的最大 ASIL，则 ASIL 是一致的。⌋
|
||||
> c()
|
||||
|
||||
请注意，出于各种原因，AUTOSAR 元素的 ASIL 可能高于安全需求的 ASIL。例如，SWC 可能被设计用于在更高的安全完整性上下文中重用，因此被评级为更高的 ASIL。然而，对于分解的需求，上下文 ASIL 如何在 ASIL 值的比较中加以考虑是开放的解释。
|
||||
|
||||
有关安全需求处 ASIL 属性的示例，请参见列表 4.1。
|
||||
|
||||
**列表 5.1**：元素处 ASIL 属性的 AUTOSAR XML 表示示例
|
||||
|
||||
```xml
|
||||
<!-- 具有 ASIL 的 AUTOSAR 元素示例 -->
|
||||
<APPLICATION-SW-COMPONENT-TYPE>
|
||||
<SHORT-NAME>MyComponent</SHORT-NAME>
|
||||
<ADMIN-DATA>
|
||||
<SDGS>
|
||||
<SDG GID="SAFEX">
|
||||
<SD GID="ASIL">B</SD>
|
||||
</SDGS>
|
||||
</ADMIN-DATA>
|
||||
<PORTS>
|
||||
[...]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6 安全需求的可追溯性与分配
|
||||
|
||||
ISO 26262 中安全需求的基本特征是追溯的管理和维护。本规范将安全需求的可追溯性称为（安全）需求与其他元素之间不同类型链接的通用术语。主要区分三种类型的 trace：
|
||||
|
||||
1. **两个安全需求级别之间的细化关系**，例如有助于功能安全需求的技术安全需求（参见 ISO 26262-8，第 6.4.3.1.a 条）。此概念类似于 AUTOSAR 规范本身的上游追溯，并将以相同的方式实现。
|
||||
2. **从安全需求到软件架构元素的分配关系**，例如分配给 AUTOSAR SWC 端口的 SW 安全需求（参见 ISO 26262-8，第 6.4.2.3 条）。
|
||||
3. **从安全需求到安全措施 / 机制的映射关系**，例如映射到端到端保护安全机制的 CRC 安全需求（参见 ISO 26262-4，第 6.4.1、6.4.2 和 6.4.6 条）。
|
||||
|
||||
请注意，安全需求的可追溯性不仅仅指当前 AUTOSAR 文档元模型中文本元素之间的引用（参见 `[TPS_GST_00243]`）。因此，不同的关系类型在 `AdminData` 块中使用 `Referrable` 引用（通过 `sdx` 元素）管理。
|
||||
|
||||
分解是细化关系的专门化，具有架构含义。安全需求的分解需要系统架构中存在两个独立的元素，对于这些元素可以保证免干扰。为了通过分解的安全需求向下追溯到软件，我们正在提高实现者的意识，并支持在集成测试期间验证相同的内容。
|
||||
|
||||
> **[TPS_SAFEX_00301]** 安全需求的细化关系 ⌈安全需求的细化关系应通过 trace 关联表达。trace 的方向具有语义"refines"。⌋
|
||||
> c(`RS_SAFEX_00007`)
|
||||
|
||||
> **[TPS_SAFEX_00302]** 安全需求的分解 ⌈分解应在将安全需求分解为的两个分解需求中的每一个处指定。为此，这两个分解需求都应接收一个 `AdminData` 条目，其中包含一个名为 `gid="DECOMPOSITION"` 的 `Sdg` 元素，该元素具有对分解的安全需求的 `sdx`（即 `Referrable`）引用。⌋
|
||||
> c(`RS_SAFEX_00008`)
|
||||
|
||||
> **[constr_6202]** 分解为两个安全需求 ⌈由 `[TPS_SAFEX_00302]` 指定的分解应针对每个分解需求恰好在两个分解安全需求（不多）处指定。⌋
|
||||
> c()
|
||||
|
||||
> **[constr_6203]** 仅分解一个安全需求 ⌈根据 `[TPS_SAFEX_00302]` 指定的每个分解需求最多分解一个其他需求。⌋
|
||||
> c()
|
||||
|
||||
> **[TPS_SAFEX_00303]** 独立性需求链接 ⌈如果安全需求表达了实现分解元素免干扰的手段，则它们应附加于分解需求，在两个分解安全需求处列出。因此，每个分解安全需求的 `AdminData` 在具有 `gid="INDEPENDENCE"` 的 `Sdg` 元素中接收一个单独的引用（`sdx` 条目）。⌋
|
||||
> c(`RS_SAFEX_00009`)
|
||||
|
||||
请注意，分解的安全需求和独立性需求可以另外接收指向分解安全需求的"反向"trace。这样，整个可追溯性层次结构可以由不感知安全扩展的工具无缝导航。
|
||||
|
||||
> **[TPS_SAFEX_00306]** 安全需求到 AUTOSAR 元素的分配 ⌈安全需求到 AUTOSAR 元素的分配通过 `AdminData` 块中指向 AUTOSAR 元素的引用来表达。对于每个分配引用，应在名为 `gid="ALLOCATION"` 的组合 `Sdg` 元素中列出 `sdx` 引用。⌋
|
||||
> c(`RS_SAFEX_00014`)
|
||||
|
||||
安全需求到 AUTOSAR 元素的直接分配的替代方案是首先映射到安全措施（如果适用），然后再映射到 AUTOSAR 元素。例如，确保安全通信的安全需求可以映射到安全机制"端到端保护"，而后者又被分配给端到端配置文件。
|
||||
|
||||
> **[TPS_SAFEX_00305]** 安全需求到安全措施的映射 ⌈安全需求到安全措施的分配应映射到具有名称 `gid="MAPS_TO"` 的 `Sdg` 元素（在 `AdminData` 块中）中的 `sdx` 引用，其中包含指向安全措施的 `sdx` 引用。⌋
|
||||
> c(`RS_SAFEX_00022`)
|
||||
|
||||
作为完全等效的替代方案，安全机制可以包含指向其将实现的安全需求的反向链接：
|
||||
|
||||
> **[TPS_SAFEX_00309]** 映射关系的替代关系 ⌈映射关系应由从安全措施到安全需求的 trace 关联表达。trace 的方向具有语义"realizes"。⌋
|
||||
> c(`RS_SAFEX_00022`)
|
||||
|
||||
> **[TPS_SAFEX_00307]** 安全措施到 AUTOSAR 元素的分配 ⌈安全措施到一个（或多个）AUTOSAR 元素的映射应在包含名为 `gid="ALLOCATION"` 的 `Sdg`（包含指向 AUTOSAR 元素的 `sdx` 引用）的 `AdminData` 中表达。⌋
|
||||
> c(`RS_SAFEX_00018`)
|
||||
|
||||
从 AUTOSAR 元素的角度来看，分配链接具有"realizes"（或"satisfies"）语义：元素必须实现所有已分配的安全需求和定义的安全机制。因此，本规范通过 realizes 关系提供了这些关系的完全等效替代方案：1
|
||||
|
||||
> 1 这在（安全）需求规范已建立基线且不应更改的情况下可能很有用。
|
||||
|
||||
> **[TPS_SAFEX_00308]** AUTOSAR 元素的 realizes 关系 ⌈安全需求或安全措施的分配可以通过 realizes 引用表达。引用应作为 `Sdg` 数据添加到元素的 `AdminData` 部分，属性为 `gid="REALIZES"`。XML 内容应包含一个 `Sd` 元素，其中包含引用已分配安全需求的 `sdx` 引用列表。⌋
|
||||
> c(`RS_SAFEX_00014`)
|
||||
|
||||
**列表 6.1**：realizes 关系的 AUTOSAR XML 表示示例
|
||||
|
||||
```xml
|
||||
[...]
|
||||
<AR-PACKAGE>
|
||||
<SHORT-NAME>FLM_swc</SHORT-NAME>
|
||||
<ELEMENTS>
|
||||
<APPLICATION-SW-COMPONENT-TYPE>
|
||||
<SHORT-NAME>FLM</SHORT-NAME>
|
||||
<ADMIN-DATA>
|
||||
<SDGS>
|
||||
<SDG GID="ASIL">
|
||||
<SD>B</SD>
|
||||
</SDG>
|
||||
<!-- 显示 <<realizes>> 关系的示例（参见 TPS_SAFEX_00308） -->
|
||||
<SDG GID="REALIZES">
|
||||
<SDX-REF DEST="STRUCTURED-REQ" BASE="SAFEX">ECU_TSR_03</SDX-REF>
|
||||
</SDG>
|
||||
</SDGS>
|
||||
</ADMIN-DATA>
|
||||
[...]
|
||||
```
|
||||
|
||||
**列表 6.2**：各种 trace 关系的 AUTOSAR XML 表示
|
||||
|
||||
```xml
|
||||
<!-- 被分解的安全需求 -->
|
||||
<STRUCTURED-REQ>
|
||||
<SHORT-NAME>ECU_TSR_01</SHORT-NAME>
|
||||
<LONG-NAME>
|
||||
<L-4 L="EN">确保 CAN 消息已接收</L-4>
|
||||
</LONG-NAME>
|
||||
<CATEGORY>SAFETY_TECHNICAL</CATEGORY>
|
||||
<ADMIN-DATA>
|
||||
<SDGS>
|
||||
<SDG GID="SAFEX">
|
||||
<SD GID="ASIL">B</SD>
|
||||
<SD GID="STATUS">PROPOSED</SD>
|
||||
</SDG>
|
||||
</SDGS>
|
||||
</ADMIN-DATA>
|
||||
<TRACE-REFS>
|
||||
<TRACE-REF DEST="STRUCTURED-REQ" BASE="SAFEX">SysSafReq05</TRACE-REF>
|
||||
<TRACE-REF DEST="STRUCTURED-REQ" BASE="SAFEX">SysSafReq03</TRACE-REF>
|
||||
<TRACE-REF DEST="STRUCTURED-REQ" BASE="SAFEX">SysSafReq47</TRACE-REF>
|
||||
<!-- 可选的可追溯性链接 -->
|
||||
</TRACE-REFS>
|
||||
<TYPE>Valid</TYPE>
|
||||
<DESCRIPTION>
|
||||
<P>
|
||||
<L-1 L="EN">CAN 消息 CAN BUS CAN_CL15 应被正确接收。</L-1>
|
||||
</P>
|
||||
</DESCRIPTION>
|
||||
...
|
||||
</STRUCTURED-REQ>
|
||||
<!-- 第一个分解的技术安全需求 -->
|
||||
<STRUCTURED-REQ>
|
||||
<SHORT-NAME>ECU_TSR_03</SHORT-NAME>
|
||||
<LONG-NAME>
|
||||
<L-4 L="EN">确保正确的 CAN 总线消息转换</L-4>
|
||||
</LONG-NAME>
|
||||
<CATEGORY>SAFETY_TECHNICAL</CATEGORY>
|
||||
<ADMIN-DATA>
|
||||
<SDGS>
|
||||
<SDG GID="SAFEX">
|
||||
<SD GID="ASIL">QM(B)</SD>
|
||||
<SD GID="STATUS">PROPOSED</SD>
|
||||
</SDG>
|
||||
<SDG GID="DECOMPOSITION">
|
||||
<SDX-REF DEST="STRUCTURED-REQ" BASE="SAFEX">ECU_TSR_01</SDX-REF>
|
||||
</SDG>
|
||||
<SDG GID="INDEPENDENCE">
|
||||
<SDX-REF DEST="STRUCTURED-REQ" BASE="SAFEX">ECU_TSR_047</SDX-REF>
|
||||
</SDG>
|
||||
<SDG GID="ALLOCATION">
|
||||
<SDX-REF DEST="APPLICATION-SW-COMPONENT-TYPE" BASE="FLM_pkg">/FLM_pkg/FLM_swc/FLM</SDX-REF>
|
||||
</SDG>
|
||||
</SDGS>
|
||||
</ADMIN-DATA>
|
||||
...
|
||||
</STRUCTURED-REQ>
|
||||
<!-- 第二个分解的技术安全需求 -->
|
||||
<STRUCTURED-REQ>
|
||||
<SHORT-NAME>ECU_TSR_05</SHORT-NAME>
|
||||
<LONG-NAME>
|
||||
<L-4 L="EN">CL15_ON 故障检查</L-4>
|
||||
</LONG-NAME>
|
||||
<CATEGORY>SAFETY_TECHNICAL</CATEGORY>
|
||||
<ADMIN-DATA>
|
||||
<SDGS>
|
||||
<SDG GID="SAFEX">
|
||||
<SD GID="ASIL">B(B)</SD>
|
||||
<SD GID="STATUS">PROPOSED</SD>
|
||||
</SDG>
|
||||
<SDG GID="DECOMPOSITION">
|
||||
<SDX-REF DEST="STRUCTURED-REQ" BASE="SAFEX">ECU_TSR_01</SDX-REF>
|
||||
</SDG>
|
||||
<SDG GID="INDEPENDENCE">
|
||||
<SDX-REF DEST="STRUCTURED-REQ" BASE="SAFEX">ECU_TSR_047</SDX-REF>
|
||||
</SDG>
|
||||
<SDG GID="MAPS_TO">
|
||||
<SDX-REF DEST="TRACEABLE" BASE="SAFEX">SM_E2E</SDX-REF>
|
||||
</SDG>
|
||||
</SDGS>
|
||||
</ADMIN-DATA>
|
||||
...
|
||||
</STRUCTURED-REQ>
|
||||
<!-- 表达独立性的技术安全需求 -->
|
||||
<STRUCTURED-REQ>
|
||||
<SHORT-NAME>ECU_TSR_047</SHORT-NAME>
|
||||
<LONG-NAME>
|
||||
<L-4 L="EN">信号处理中的免干扰</L-4>
|
||||
</LONG-NAME>
|
||||
<CATEGORY>SAFETY_TECHNICAL</CATEGORY>
|
||||
...
|
||||
</STRUCTURED-REQ>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7 安全措施
|
||||
|
||||
系统的安全是通过在开发过程的各个阶段应用的安全措施以及在系统中通过多种技术实现的安全机制来实现的。本规范出于多种原因考虑了超出纯 AUTOSAR 软件堆栈范围的安全措施：
|
||||
|
||||
- **软件安全通常依赖于（外部）硬件机制来实现其安全完整性**，例如内存保护和分区、ECC / EDC、锁步模式、外部看门狗等。在实施过程中，这些上下文依赖性应明确成为任何软件的"运行时契约"的一部分，而不仅仅是隐式通信。
|
||||
- **错误检测和错误处理通常涉及 SW 和 HW 之间复杂的交互**，从监控到中断和处理例程，再到执行器的关闭路径。因此，任何软件安全机制都应感知技术环境、系统级别的安全状态、潜在的故障和 HW 所隐含的约束。
|
||||
- **软件集成需要验证安全机制的有效性**。如果软件规范说明了实现哪些安全机制或执行了哪些措施，则一致性检查和（半）自动验证成为可能，这反过来又减少了系统性失效。
|
||||
- **最后，任何软件都受到运行它的 HW / 平台的影响**。理解和避免（系统性）失效只有在系统级别对安全机制的意图被记录、可访问并被实施者很好地理解的情况下才有可能。
|
||||
|
||||
AUTOSAR 已经提供了许多可用于实现安全软件的安全机制和功能，例如端到端保护、程序流监控、看门狗管理器等（参见 [?, ] 以获取概述）。这些功能可以用作 `[TPS_SAFEX_00305]` 映射的目标。请注意，除本节中的需求外，本规范不对文本描述施加任何约束。
|
||||
|
||||
> **[TPS_SAFEX_00401]** 安全措施或安全机制的定义 ⌈安全措施（或安全机制）应描述为 `TraceableText`。`category` 属性应使用 `SAFETY_MEASURE` 或 `SAFETY_MECHANISM` 标记文本块。⌋
|
||||
> c(`RS_SAFEX_00013`、`RS_SAFEX_00015`、`RS_SAFEX_00016`、`RS_SAFEX_00023`)
|
||||
|
||||
> **[TPS_SAFEX_00402]** 安全措施的唯一标识符 ⌈安全措施 / 机制应作为 `shortName` 接收唯一标识符。该 ID 在 AUTOSAR 项目的范围内应是唯一的。⌋
|
||||
> c(`RS_SAFEX_00017`)
|
||||
|
||||
**列表 7.1**：元素处 ASIL 属性的 AUTOSAR XML 表示示例
|
||||
|
||||
```xml
|
||||
<!-- 安全机制示例 -->
|
||||
<TRACE>
|
||||
<SHORT-NAME>SM_E2E</SHORT-NAME>
|
||||
<LONG-NAME>
|
||||
<L-4 L="EN">信号 CL15ON 的端到端保护</L-4>
|
||||
</LONG-NAME>
|
||||
<CATEGORY>SAFETY_MECHANISM</CATEGORY>
|
||||
<ADMIN-DATA>
|
||||
<SDGS>
|
||||
<SDG GID="ALLOCATION">
|
||||
<SDX-REF DEST="END-TO-END-PROTECTION-SET" BASE="FLM_swc">/FLM_swc/FLM/MyEnd2EndProfile</SDX-REF>
|
||||
</SDG>
|
||||
</SDGS>
|
||||
</ADMIN-DATA>
|
||||
<P>
|
||||
<L-1 L="EN">E2E 通信保护，使发送方能够保护数据，接收方能够在运行时检测错误并处理它们</L-1>
|
||||
</P>
|
||||
</TRACE>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8 应用说明
|
||||
|
||||
当前版本的本规范没有具体的应用说明。
|
||||
|
||||
---
|
||||
|
||||
## 附录 A 提到的类表
|
||||
|
||||
为完整起见，本章包含一组表示本文档上下文中提到的元类的类表，但不直接包含在描述特定元模型语义的范围内。
|
||||
|
||||
> **翻译说明**：本附录列出 11 个 AUTOSAR 元类表（`AdminData`、`Identifiable`、`Referrable`、`Sd`、`Sdg`、`SdgContents`、`StructuredReq`、`TraceReferrable`、`Traceable`、`TraceableText`、`Xfile`），包含每个类的属性定义。由于这些是标准 AUTOSAR 元模型参考表，本翻译仅翻译前 3 个表的概要信息；完整定义请参见原文 PDF 第 28-35 页。
|
||||
|
||||
### 表 A.1: `AdminData`
|
||||
|
||||
| 属性 | 类型 | 多重性 | 种类 | 说明 |
|
||||
|---|---|---|---|---|
|
||||
| `docRevision` | `DocRevision` | * | 聚合 | 表示有关对象当前修订的信息。 |
|
||||
| `language` | `LEnum` | 0..1 | 属性 | 指定文档或文档片段的主语言。 |
|
||||
| `sdg` | `Sdg` | * | 聚合 | 允许保留标准模型未表示的特殊数据。 |
|
||||
| `usedLanguages` | `MultiLanguagePlainText` | 0..1 | 聚合 | 指定文档中提供的语言。 |
|
||||
|
||||
> **摘要标记**：附录 A 包含 11 个类表（`AdminData`、`Identifiable`、`Referrable`、`Sd`、`Sdg`、`SdgContents`、`StructuredReq`、`TraceReferrable`、`Traceable`、`TraceableText`、`Xfile`），每个类表描述标准 AUTOSAR 元模型参考类。本翻译仅翻译 `AdminData` 表的概要；其他类表的详细属性请参见原文 PDF 第 28-35 页。
|
||||
|
||||
---
|
||||
|
||||
## 翻译说明
|
||||
|
||||
- **翻译完整性**：本文档为 AUTOSAR 安全扩展模板规范（TPS）的中文翻译版本，完整翻译了 1-8 章及附录 A 的概要内容。
|
||||
- **保留的英文术语**：所有规范项 ID（`TPS_SAFEX_xxxxx`、`RS_SAFEX_xxxxx`、`UC_SAFEX_xxxxx`、`constr_xxxx`）、AUTOSAR 元模型类名（`StructuredReq`、`TraceableText`、`AdminData`、`Identifiable`、`Referrable`、`Sdg`、`Sd`、`Xfile` 等）、属性名（`category`、`shortName`、`longName`、`trace`、`desc` 等）、ASIL 等级（QM、A、B、C、D 及其分解表示）、AUTOSAR 方框符 `⌈⌋` 均按要求保留为英文。
|
||||
- **省略的内容**：免责声明（Disclaimer）按要求未翻译。
|
||||
- **关键概念**：
|
||||
- **安全扩展元模型概念**：使用 `Sdg`（Special Data Group）和 `Sd`（Special Data）属性来附加 ASIL、状态、分解、分配等安全信息。
|
||||
- **安全需求类别**：`SAFETY_GOAL`、`SAFETY_FUNCTIONAL`、`SAFETY_TECHNICAL`、`SAFETY_SOFTWARE`、`SAFETY_HARDWARE`、`SAFETY_EXTERNAL`。
|
||||
- **安全措施与安全机制**：使用 `SAFETY_MEASURE` 和 `SAFETY_MECHANISM` 类别标记。
|
||||
- **ASIL 分解表示**：括号表示法，例如 ASIL B(D) 表示原始 ASIL 为 D，分解后为 B。
|
||||
- **追溯关系类型**：`trace`（细化）、`DECOMPOSITION`（分解）、`INDEPENDENCE`（独立性）、`ALLOCATION`（分配）、`MAPS_TO`（映射到）、`REALIZES`（实现）。
|
||||
- **附录摘要**：附录 A 列出 11 个 AUTOSAR 元类参考表，已翻译首张表，其余详见原文。
|
||||
Reference in New Issue
Block a user