804 lines
52 KiB
Markdown
804 lines
52 KiB
Markdown
# 模式管理需求 (Requirements on Mode Management)
|
||
|
||
| 项目 | 内容 |
|
||
|------|------|
|
||
| **文档标识号** | 069 |
|
||
| **文档标题** | Requirements on Mode Management（模式管理需求） |
|
||
| **文档所有者** | AUTOSAR |
|
||
| **文档责任方** | AUTOSAR |
|
||
| **文档状态** | Final（正式版） |
|
||
| **所属 AUTOSAR 标准** | Classic Platform（经典平台） |
|
||
| **所属标准发布版本** | 4.4.0 |
|
||
|
||
---
|
||
|
||
## 文档变更历史 (Document Change History)
|
||
|
||
| 日期 | 发布版本 | 变更人 | 变更说明 |
|
||
|------|---------|--------|---------|
|
||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | EcuMFixed 已废弃（obsolete） |
|
||
| 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 | 澄清部分需求的后构建可配置性 |
|
||
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 将 SWS EcuM 中描述睡眠模式/关闭目标处理的项目移至 SRS 层级；移除 Defensive Behavior（防御性行为） |
|
||
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 增强可追踪性 |
|
||
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 编辑性修改；将 RS_BSWandFeature 更新为 RS_Feature |
|
||
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 引入实现 ECU 降级和 EnhancedBSWAllocation 的新需求；正式更新以符合标准文档模板；引入到功能文档的链接 |
|
||
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 扩展 BswM 以实现部分网络（Partial Networks）概念中与模式管理相关的部分；扩展 ComM 以实现部分网络概念中与通信模式管理相关的部分 |
|
||
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 新模块 BswM（BSW 模式管理器）；EcuM-Flex（具有自由可配置状态的 ECU 状态管理器）；EcuM-Flex 中支持多核、报警时钟和 BSWM 防御性行为的新功能；WdgM（看门狗管理器）的扩展：程序流监控、窗口看门狗；法律免责声明修订 |
|
||
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
|
||
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 因引入通信管理器下方的总线特定状态管理器而移除 BSW09088；因 ECU 状态管理器直接初始化通信栈而移除 BSW09130 和 BSW09131；为启动、关闭和睡眠期间的 alive 监督添加 BSW09170 和 BSW09171；添加 SRS_ModeMgm_09172 以澄清通信管理器行为；添加 SRS_ModeMgm_09173 以澄清 ECU 状态管理器行为；重新表述多个需求以澄清行为和配置类；扩展文档元信息；进行小幅布局调整 |
|
||
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | 移除 BSW09075（移至 SRS General）；新需求 SRS_ModeMgm_09168 和 SRS_ModeMgm_09169；将 OSEK OS 引用替换为 AUTOSAR OS 引用；正式调整和术语更新；法律免责声明修订；添加发布说明；"用户建议"修订；添加"修订信息" |
|
||
| 2006-05-16 | 2.0 | AUTOSAR Administration | 首次发布 |
|
||
|
||
---
|
||
|
||
## 免责声明 (Disclaimer)
|
||
|
||
> 本作品（规范和/或软件实现）及其包含的材料由 AUTOSAR 发布，仅用于提供信息。 AUTOSAR 和为其作出贡献的公司不对该作品的任何使用承担责任。
|
||
>
|
||
> 本作品中包含的材料受版权及其他类型的知识产权保护。 对本作品中包含的材料的商业利用需要此类知识产权的许可。
|
||
>
|
||
> 本作品可在不进行任何修改的情况下，以任何形式或方式被使用或复制，仅用于提供信息的目的。 出于任何其他目的，未经出版商书面许可，不得以任何形式或方式使用或复制本作品的任何部分。
|
||
>
|
||
> 本作品仅为汽车应用而开发。 它既未为非汽车应用开发，也未为非汽车应用进行测试。
|
||
>
|
||
> "AUTOSAR" 一词和 AUTOSAR 标志是注册商标。
|
||
|
||
---
|
||
|
||
## 目录 (Table of Contents)
|
||
|
||
1. [文档范围 (Scope of Document)](#1-文档范围) ........................................................................ 6
|
||
2. [使用的约定 (Conventions to be used)](#2-使用的约定) ................................................. 7
|
||
3. [术语 (Terminology)](#3-术语) ............................................................................................. 8
|
||
4. [需求规范 (Requirement Specification)](#4-需求规范) ................................................. 12
|
||
- 4.1 ECU 状态管理器 (ECU State Manager, EcuM)
|
||
- 4.1.1 通用 (Common)
|
||
- 4.1.2 固定 (Fixed) — 摘要
|
||
- 4.1.3 灵活 (Flex)
|
||
- 4.2 看门狗管理器 (Watchdog Manager, WdgM)
|
||
- 4.3 通信管理器 (Communication Manager, ComM)
|
||
- 4.4 基础软件模式管理器 (Basic Software Mode Manager, BswM)
|
||
5. [需求追踪 (Requirements Tracing)](#5-需求追踪) .......................................................... 70
|
||
6. [参考文献 (References)](#6-参考文献) .......................................................................... 74
|
||
|
||
---
|
||
|
||
## 1 文档范围 (Scope of Document)
|
||
|
||
本文档的目标是为 AUTOSAR 模式管理的所有模块定义功能和非功能需求：
|
||
|
||
1. **ECU 状态管理器 (ECU State Manager, EcuM)** — 管理 ECU 的启动和关闭。 这包括在所有 RUN 请求被释放时触发关闭；
|
||
2. **看门狗管理器 (Watchdog Manager, WdgM)** — 以合适的方式从独立应用程序收集 alive 指示和正确的执行顺序指示，并将它们转发到硬件看门狗；
|
||
3. **通信管理器 (Communication Manager, ComM)** — 协调独立应用程序的通信。
|
||
4. **基础软件模式管理器 (Basic Software Mode Manager, BswM)** — 组织 SW-C 和 BSW 模块的模式处理和模式相关交互。
|
||
|
||
如果 ECU 上有多个独立的软件组件，则所有模块都是必需的。 这些模块在整个 AUTOSAR ECU 软件架构中的位置在 [6] 中定义。
|
||
|
||
---
|
||
|
||
## 2 使用的约定 (Conventions to be used)
|
||
|
||
- AUTOSAR 文档中需求的表示遵循 [9] 中指定的表格。
|
||
- 在需求中，应使用以下特定语义（基于互联网工程任务组 IETF）。
|
||
|
||
文档中关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 的解释如下：
|
||
|
||
- **SHALL**：此词表示该定义是规范的绝对要求。
|
||
- **SHALL NOT**：此短语表示该定义是规范的绝对禁止。
|
||
- **MUST**：此词表示由于法律问题，该定义是规范的绝对要求。
|
||
- **MUST NOT**：此短语表示由于法律约束，该定义是规范的绝对禁止。
|
||
- **SHOULD**：此词或形容词 "RECOMMENDED" 表示在特定情况下可能存在忽略特定项目的正当理由，但在选择不同方案之前必须充分理解并仔细权衡其全部含义。
|
||
- **SHOULD NOT**：此短语或短语 "NOT RECOMMENDED" 表示在特定情况下，特定行为可能是可接受的或甚至有用，但在实现以此标签描述的任何行为之前，应充分理解其全部含义并仔细权衡。
|
||
- **MAY**：此词或形容词 "OPTIONAL" 表示项目是真正可选的。 一个供应商可能选择包含该项目，因为特定市场需要它，或者因为供应商认为它增强了产品，而另一个供应商可能省略同一项目。 不包含特定选项的实现必须准备好与包含该选项的另一实现进行互操作，尽管可能功能有所降低。 同样，包含特定选项的实现必须准备好与不包含该选项的另一实现进行互操作（当然，除了该选项提供的功能之外）。
|
||
|
||
---
|
||
|
||
## 3 术语 (Terminology)
|
||
|
||
### 3.1 术语表 (Glossary)
|
||
|
||
| 术语 | 描述 |
|
||
|------|------|
|
||
| **Active wake-up（主动唤醒）** | 由 ECU 引起的唤醒，例如由传感器引起。 |
|
||
| **Alive indication（Alive 指示）** | 指示受监督的 SW-C 是 alive 的（即活动的），由 SW-C 本身提供给看门狗管理器。 |
|
||
| **Application（应用）** | 应用与 SW-C 同义使用。 一个 SW-C 可能跨越多个原子 SW-C。 AUTOSAR 提供 "composition（组合）" 元素以正式组合应用的多个原子 SW-C。 组合用于结构化描述，不影响生成的代码。 注意：组合中的原子 SW-C 仍然可以映射到不同的 ECU。 因此应用模式是应用的 "本地" 模式，但可以是多个 ECU 的 "全局" 模式。 |
|
||
| **Application Mode（应用模式）** | 应用模式是不由 BSW 中的模式管理器控制和标准化的模式。 应用模式的范围是属于逻辑应用的有限数量的 SW-C。 如果模式仅影响一个组合，则它是应用模式。 应用模式可以分布在多个 ECU 上，也可以是单个 ECU 本地的，具体取决于属于该应用的 SW-C 的分布。 示例：Normal Operation（正常运行）、Limp Home（跛行回家）。 |
|
||
| **Application Mode Manager（应用模式管理器）** | 应用模式管理器是 SW-C，因此 a priori 不是标准化的。 它从其他 SW-C 收集环境数据和模式请求，通过应用特定的（非标准化的）接口。 它可以切换不由 BSW 中的模式管理器控制和标准化的应用模式。 它还可以向其他模式管理器（特别是 BSW 中的模式管理器）请求模式。 |
|
||
| **BSW Mode（BSW 模式）** | BSW 模式是由 BSW 中的模式管理器控制和标准化的模式。 BSW 模式始终是单个 ECU 本地的。 示例：EcuM Modes、ComM Modes。 |
|
||
| **BSW Mode Manager（BSW 模式管理器）** | BSW 模式管理器是一个 BSW 模块，它通过标准化接口收集模式请求，并相应地控制其他 BSW 模块的功能。 示例：LIN 调度表切换、启用/禁用 I-PDU 组等。 |
|
||
| **Communication mode（通信模式）** | 与物理通道或用户相关，指示是否可以发送/接收、仅接收、既不发送也不接收。 |
|
||
| **Communication request（通信请求）** | 通信请求表示来自给定用户（例如需要运行通信栈的 runnable）的通信需求。 但是，不能假定该请求将在特定时间内被满足，也不能假定它将完全被满足。 请求者本身必须通过使用查询函数或回调来确保通信确实已建立。 |
|
||
| **ECU state（ECU 状态）** | 通用术语，用于指示由 ECU 状态管理器管理的状态。 它们表示一个结构化模型，通过状态和转换来扩展 ECU 的电源模式，以支持进入/离开这些电源模式所需的软件活动。 |
|
||
| **Inoperation（不操作）** | 一个合成词，用于描述 ECU 不运行时的情况，即不运行。 它包括 off、sleeping、frozen 等所有含义。 使用此定义是有益的，因为它没有预定义的含义。 |
|
||
| **Low-power mode（低功耗模式）** | 除 "on"（全功率）之外的所有电源模式。 |
|
||
| **Mode（模式）** | 模式是车辆中运行的各种状态机中与特定实体（例如 SW-C、BSW 模块、应用、整个车辆）相关的一组特定状态。 在其生命周期中，实体在多个互斥模式之间变化。 这些变化由环境数据触发，例如信号接收、操作调用。 |
|
||
| **Mode Declaration Group（模式声明组）** | 模式声明组在软件组件模板中定义并由 RTE 实现。 模式声明组定义多个互斥模式。 模式声明组中模式之间没有层次结构。 每个模式声明组仅描述整个系统的一个方面。 ECU 上所有模式声明组的所有模式描述了 ECU 的抽象模式。 类似地，系统中所有模式声明组的所有模式描述了系统中所有 ECU 的抽象模式。 （该模式是抽象的，因为无法物理访问它，它仅在概念上存在）。 BSW 中定义了一组标准化的模式声明组，例如 ComM、WdgM、EcuM。 每个系统设计者可以自由扩展模式声明组的数量并在其中定义自己的模式。 仅允许一个模式管理器切换模式声明组实例的模式。 （VFB 中的限制） |
|
||
| **Mode Manager（模式管理器）** | 模式管理器是 BSW 模块（以及可选的 SW-C）可以承担的角色。 模式管理器从模式请求者收集请求，仲裁它们，并相应地切换其模式声明组的模式。 模式管理器的示例有：EcuM、ComM、WdgM 和 BswM。 注意：如果 SW-C 模式管理器直接切换模式，BSW 模式管理器中的模式仲裁无法解决冲突。 因此，建议使用多级模式仲裁，即 SW-C 模式管理器和 BSW 模式管理器。 |
|
||
| **Mode Port（模式端口）** | 模式端口是具有包含模式声明组的 Sender-Receiver Interface 的端口。 注意：这在 SWS RTE 中称为 Mode Port → 为了与 Mode Request Ports 区分，我们应该将其称为 Mode Switch Port。 |
|
||
| **Mode Request（模式请求）** | 模式请求是传递给模式管理器的一些信息，请求模式管理器切换到某个模式。 对于 BSW 中的模式管理器，发送模式请求的接口是由相应模式管理器定义的标准化客户端-服务器接口。 示例：客户端-服务器接口 `ComM_UserRequest`，其操作 `RequestComMode(…)`。 对于应用模式管理器，接口可以是由模式管理器定义的任何客户端-服务器或发送者-接收者接口。 |
|
||
| **Mode Request Port（模式请求端口）** | 模式请求端口是具有请求模式管理器模式的特殊语义的端口。 它可以是客户端-服务器端口或发送者-接收者端口。 对于 BSW 中的模式管理器，模式请求端口是标准化的。 注意：对于 EcuM、ComM 和 WdgM，它始终是提供的客户端-服务器端口。 对于 BswM，它是所需的发送者-接收者端口。 |
|
||
| **Mode Requester（模式请求者）** | 模式请求者是从模式管理器请求模式的实体。 |
|
||
| **Mode Switch Port（模式切换端口）** | 短语 Mode Port 的首选替代。 |
|
||
| **Mode User（模式用户）** | 模式用户是对模式变化做出反应的实体。 |
|
||
| **OFF state（OFF 状态）** | ECU 状态。 表示未通电的 ECU。 根据硬件设计，ECU 在此状态下可以或不可以对被动唤醒做出反应（此状态不需要可唤醒性）。 |
|
||
| **Passive wake-up（被动唤醒）** | 由另一个 ECU 发起并通过总线或唤醒线传播到当前关注的 ECU 的唤醒。 |
|
||
| **Port Group（端口组）** | 端口组是实现应用中相同功能所需的端口的逻辑组。 端口可以是多个端口组的成员。 端口组可用于请求所有关联的通信资源并查询其状态。 因此，端口组还定义了应用端口和通信资源之间的映射。 因此，端口组的目的是抽象该功能所需的通信资源。 例如，应用包含正常运行功能和具有减少通信需求的跛行回家功能。 那么定义两个端口组 A 和 B 是有用的。 A 包含正常运行功能所必需的端口，B 包含跛行回家功能的端口。 因此，应用可以识别正常操作的通信资源不可用但足以应付跛行回家的情况。 端口组在 SW-C 组合级别上定义，这意味着它们可以分布在多个 ECU 上。 但是端口组的请求和指示应仅影响本地于 ECU 的端口组部分。 如果需要端口组的分布式控制，可以在（高于 RTE 的）"应用模式管理"级别上使用普通通信功能来处理。 |
|
||
| **Power mode（电源模式）** | ECU 的硬件电源模式。 通常为：on（全功率）、off、sleep、standby 等。 后两项可采用几种形式，取决于硬件功能（降低的时钟、外设待机等）。 |
|
||
| **Program flow monitoring（程序流监控）** | 用于检测导致偏离程序有效执行期间所看到的有效程序序列的错误的技术。 |
|
||
| **RUN state（RUN 状态）** | ECU 状态。 ECU 完全运行，所有 BSW 模块已初始化，应用软件组件能够运行。 |
|
||
| **Shutdown target（关闭目标）** | 下次关闭所选择的低功耗状态（OFF、SLEEP）。 如果 SLEEP 状态支持多种睡眠模式，则关闭目标应指示所选择的睡眠模式。 |
|
||
| **Sleep mode（睡眠模式）** | 术语 "mode" 与 ECU 功能的当前可用性相关。 "Sleep mode" 是对可能存在于不同 CPU 上的多种低功耗模式的总体抽象术语，它们的共同点是当前不执行代码，但仍通电。 |
|
||
| **SLEEP state（SLEEP 状态）** | ECU 状态。 这是一种节能状态：不执行代码但仍供电，如果配置正确，ECU 是可唤醒的。 SLEEP 状态提供一组可配置的睡眠模式，通常在功耗和重启 ECU 时间之间进行权衡。 |
|
||
| **State/communication requestor（状态/通信请求者）** | 见 User。 |
|
||
| **Supervised Entity（受监督实体）** | 受监督实体是包含在看门狗管理器监控中的软件实体。 每个受监督实体有且仅有一个标识符。 受监督实体表示软件组件或基础软件模块内的一组检查点。 一个软件组件或基础软件模块中可能有零个、一个或多个受监督实体。 |
|
||
| **User（用户）** | ECU 状态管理器和通信管理器的请求者的概念。 用户可以是 runnable 实体、SW-C/BSW，甚至是 SW-C/BSW 的组，作为单个单元对 ECU 状态管理器和通信管理器进行操作。 |
|
||
| **Vehicle Mode（车辆模式）** | 车辆模式是不由 BSW 中的模式管理器控制和标准化的模式。 车辆模式的范围是整个车辆。 如果模式影响多个组合，则它是车辆模式。 根据定义，车辆模式分布在整个车辆上。 示例：Transport Mode（运输模式）、Power Saving Mode（省电模式）、Ignition On（点火打开）、Ignition Off（点火关闭）。 |
|
||
| **Vehicle Mode Manager（车辆模式管理器）** | 车辆模式管理器是切换车辆模式的一种特殊应用模式管理器。 |
|
||
| **Wake-up event（唤醒事件）** | 导致唤醒的物理事件。 CAN 消息或切换的 IO 线路可以是唤醒事件。 类似地，内部软件表示（例如中断）也可以称为唤醒事件。 |
|
||
| **Wake-up reason（唤醒原因）** | 实际导致当前/最后唤醒的唤醒事件。 |
|
||
| **Wake-up source（唤醒源）** | 处理唤醒事件的外设或 ECU 组件称为唤醒源。 |
|
||
|
||
### 3.2 缩写词 (Abbreviations)
|
||
|
||
| 缩写 | 描述 |
|
||
|------|------|
|
||
| **BSW** | Basic Software（基础软件） |
|
||
| **BswM** | Basic Software Mode Manager（基础软件模式管理器） |
|
||
| **ComM** | Communication Manager（通信管理器） |
|
||
| **DCM** | Diagnostic Communication Manager（诊断通信管理器） |
|
||
| **DEM** | Diagnostic Event Manager（诊断事件管理器） |
|
||
| **EcuM** | ECU State Manager（ECU 状态管理器） |
|
||
| **FiM** | Function Inhibition Manager（功能禁止管理器） |
|
||
| **RE** | Runnable Entity（可运行实体） |
|
||
| **SW-C** | Software Component（软件组件） |
|
||
| **WdgM** | Watchdog Manager（看门狗管理器） |
|
||
|
||
---
|
||
|
||
## 4 需求规范 (Requirement Specification)
|
||
|
||
模式管理集群负责四个基础软件模块：
|
||
|
||
- **ECU 状态管理器 (EcuM)**：控制 AUTOSAR BSW 模块的启动阶段，包括 OS 的启动；
|
||
- **通信管理器 (ComM)**：负责网络资源管理；
|
||
- **看门狗管理器 (WdgM)**：负责根据应用软件的 alive 状态和控制流状态触发看门狗；
|
||
- **基础软件模式管理器 (BswM)**：负责支持模式处理。
|
||
|
||
以下需求将分配给这些模块中的每一个。
|
||
|
||
### 4.1 ECU 状态管理器 (ECU State Manager, EcuM)
|
||
|
||
ECU 状态管理器是管理 ECU 状态和这些状态之间转换的基础软件模块。 它管理所有唤醒事件并在请求时将 ECU 配置为 SLEEP。
|
||
|
||
ECU 状态管理器应支持单独的准备工作和转换以启动 ECU 或将其置于降低的电源模式（低功耗模式，例如 sleep/standby）。 通过明确定义 ECU 状态管理器特性和功能的使用，然后可以使用此模块来执行预定义的功耗策略，从而允许 ECU 的高效能源管理。
|
||
|
||
#### 4.1.1 通用 (Common)
|
||
|
||
##### 4.1.1.1 功能需求 (Functional Requirements)
|
||
|
||
###### 4.1.1.1.1 配置（通用）(Configuration (Common))
|
||
|
||
**4.1.1.1.1.1 [SRS_ModeMgm_09122] ECU 状态管理器用户的配置 (Configuration of users of the ECU State Manager)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type（类型） | valid |
|
||
| Description（描述） | 指示各个软件组件操作需求的用户应是 ECU 状态管理器的预编译时可配置属性。 来自未知源的请求将被忽略。 |
|
||
| Rationale（理由） | 所有用户在编译时都是已知的和配置的。 此需求支持 ECU 上（已知的）状态请求者的静态管理；它还支持测试和文档。 |
|
||
| Use Case（用例） | -- |
|
||
| Dependencies（依赖） | Requesting and releasing states. |
|
||
| Supporting Material（支持材料） | -- |
|
||
⌋(RS_BRF_01488, RS_BRF_01448)
|
||
|
||
**4.1.1.1.1.2 [SRS_ModeMgm_09100] 唤醒源的选择应可配置 (Selection of wake-up sources shall be configurable)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | valid |
|
||
| Description | 在预编译时应可配置哪些唤醒源在哪个睡眠模式中相关，前提是它们实际上可以分配到睡眠模式（即在该特定睡眠模式进入 ECU 时将启用它们）。 |
|
||
| Rationale | 唤醒源无法详细标准化。 它们到用例的映射也无法标准化。 因此需要这种灵活性。 |
|
||
| Use Case | 根据 ECU 的不同，允许的唤醒源可能不同：CAN 帧的接收、直接输入、CAN 帧或直接输入等。 哪个唤醒源应在哪个睡眠模式中激活，则是配置参数。 |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01496, RS_BRF_01104, RS_BRF_01448)
|
||
|
||
###### 4.1.1.1.2 正常运行（通用）(Normal Operation (Common))
|
||
|
||
**4.1.1.1.2.1 [SRS_ModeMgm_09104] ECU 状态管理器应在 OS 关闭后接管控制 (ECU State Manager shall take over control after OS shutdown)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | 在 OS 关闭之后，应执行其他关闭活动，例如为下次唤醒准备硬件。 最后，必须关闭 ECU 或将其置于睡眠模式。 这应是 ECU 状态管理器的任务。 |
|
||
| Rationale | - 在 OS 关闭后提供服务；- 启动/关闭对称性。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01096, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.2 [SRS_ModeMgm_09128] 应支持多个关闭目标 (Several shutdown targets shall be supported)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | ECU 状态管理器应提供以下用于关闭 ECU 的目标：断电 (Power Off)、ECU 复位 (Reset of ECU)、睡眠模式 (Sleep Modes)。 默认目标应由配置定义。 可以通过 API 服务覆盖。 可以支持多种睡眠模式（SRS_ModeMgm_09119）。 |
|
||
| Rationale | 允许在能耗和唤醒/启动 ECU 的时间之间进行权衡。 |
|
||
| Use Case | -- |
|
||
| Dependencies | [SRS_ModeMgm_09119], [SRS_ModeMgm_09118] |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01096, RS_BRF_01488, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.3 [SRS_ModeMgm_09270] ECU 状态管理器应提供用于选择关闭目标的服务 (The ECU State Manager shall provide a service for the selection of the shutdown target)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | ECU 状态管理器应向应用程序提供用于选择关闭目标的服务。 |
|
||
| Rationale | 应用程序需要控制应使用哪个关闭目标。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01096, RS_BRF_01488, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.4 [SRS_ModeMgm_09271] ECU 状态管理器应提供用于检索当前关闭目标的服务 (The ECU State Manager shall provide a service for the retrieval of the current shutdown target)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | ECU 状态管理器应向应用程序提供用于检索当前关闭目标的服务。 |
|
||
| Rationale | 应用程序可能需要检查是否选择了适当的关闭目标。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01096, RS_BRF_01488, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.5 [SRS_ModeMgm_09119] 应提供多种睡眠模式 (Several sleep modes shall be available)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | ECU 状态管理器应能够处理一组预定义的（预编译时或链接时配置的）睡眠模式。 |
|
||
| Rationale | 根据增加的非操作机制支持系统策略的可移植性。 |
|
||
| Use Case | -- |
|
||
| Dependencies | - 硬件必须支持多种睡眠模式；- MCU 驱动程序的接口。 |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01488, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.6 [SRS_ModeMgm_09102] 应提供用于选择睡眠模式的 API (API for selecting the sleep mode shall be provided)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | ECU 状态管理器应提供 API 来选择将在下次 ECU 关闭时选择的睡眠模式。 每当决定进入睡眠时（与使用此 API 无关；请参见 SRS_ModeMgm_09072、SRS_ModeMgm_09115、SRS_ModeMgm_09165、SRS_ModeMgm_09166、SRS_ModeMgm_09114 和 SRS_ModeMgm_09116），当前活动的睡眠模式选择应用于选择关闭过程的实际目标睡眠模式。 |
|
||
| Rationale | 应用程序需要一种选择下次关闭目标的方法。 然而，启动关闭过程的决定将完全独立于此 API 的调用。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01488, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.7 [SRS_ModeMgm_09272] ECU 状态管理器应提供用于检索最后睡眠目标的服务 (The ECU State Manager shall provide a service for the retrieval of the last sleep targets)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | ECU 状态管理器应向应用程序提供用于检索最后睡眠目标的服务。 |
|
||
| Rationale | 应用程序可能需要根据最后的关闭目标执行不同的操作。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01488, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.8 [SRS_ModeMgm_09072] 应强制 ECU 关闭 (ECU shutdown shall be forced)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | valid |
|
||
| Description | ECU 状态管理器应提供强制启动关闭过程 SRS_ModeMgm_09114 的方法（显式 API 或过程）。 此功能应对应用程序不可用，但仅可由 BSW 访问。 |
|
||
| Rationale | 受控的基础软件反初始化。 |
|
||
| Use Case | 强制 ECU 关闭，因为假定此 ECU 无法正常工作。 将其置于定义的测试条件。 |
|
||
| Dependencies | [SRS_ModeMgm_09114] 启动/调用关闭过程。 |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01488, RS_BRF_01056, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.9 [SRS_ModeMgm_09017] ECU 状态管理器应提供查询当前 ECU 状态的 API (The ECU State Manager shall provide an API to query the current ECU state)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | valid |
|
||
| Description | ECU 状态管理器应提供 API 来查询当前 ECU 状态。 |
|
||
| Rationale | 基本功能。 软件可能根据当前 ECU 状态表现不同。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01488, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.10 [SRS_ModeMgm_09136] ECU 状态管理器应是所有唤醒事件的接收者 (The ECU State Manager shall be the receiver of all wake-up events)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | valid |
|
||
| Description | ECU 状态管理器应作为其 ECU 上发生的所有唤醒事件的接收者；它应适当地做出反应（例如 ECU 唤醒）并将信息传播给其他相关组件。 |
|
||
| Rationale | 唤醒事件时无歧义且已定义的行为。 |
|
||
| Use Case | -- |
|
||
| Dependencies | [SRS_ModeMgm_09113], [SRS_ModeMgm_09097] |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01488, RS_BRF_01496, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.11 [SRS_ModeMgm_09098] 应可存储唤醒原因 (Storing the wake-up reasons shall be available)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | ECU 状态管理器应能够存储当前的唤醒原因。 |
|
||
| Rationale | 在一个模块中存储唤醒原因，并为每个模块（BSW 和 SWC）提供查询唤醒原因的可能性。 |
|
||
| Use Case | 通过外部诊断工具检索最后唤醒原因。 某些行为（应用模式管理）可能由唤醒触发。 |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.12 [SRS_ModeMgm_09097] ECU 状态管理器模块应在收到唤醒指示后启动超时 (The ECU state Manager module shall start a timeout after receiving a wake-up indication)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | valid |
|
||
| Description | ECU 状态管理器模块应在从总线驱动程序接收到唤醒指示后启动超时（T_wake_up_timeout 大于零，静态可配置）。 如果在超时到期之前收到有效消息，则计时器应停止，并且 ECU 状态管理器模块指示系统通道（ComMChannel）唤醒。 ECU 状态管理器应通过额外的 callout 函数启用总线系统的硬件设备（控制器、收发器），并轮询总线驱动程序是否收到有效消息。 消息应由总线驱动程序接收，但在唤醒验证之前不转发到上层。 ECU 状态管理器模块仅当来自总线驱动程序的第一次唤醒指示由在 T_wake_up_timeout 内的后续有效消息确认时，才应指示系统通道唤醒。 如果无法进行验证，则 ECU 状态管理器模块应通过额外的 callout 函数再次禁用为唤醒验证而启用的硬件设备。 如果 T_wake_up_timeout 设置为 0，则验证过程被禁用，唤醒立即被确认。 |
|
||
| Rationale | 避免由于错误信号（例如尖峰）引起的唤醒。 如果发生唤醒但无法在物理通道上检测到后续活动，则不考虑唤醒，以节省电力。 仅在验证后转发通信项，以不转发不一致或无意义的信号。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01104, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.13 [SRS_ModeMgm_09126] 应提供查询唤醒原因的 API (An API for querying the wake-up reason shall be provided)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | valid |
|
||
| Description | ECU 状态管理器应提供 API 来查询导致上次 ECU 唤醒的唤醒事件。 |
|
||
| Rationale | 用于诊断目的。 |
|
||
| Use Case | 在初始化时，应用程序需要根据唤醒原因执行不同的处理。 |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01056, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.14 [SRS_ModeMgm_09274] ECU 状态管理器应提供用于检索所选复位模式的服务 (The ECU State Manager shall provide a service for the retrieval of the selected reset modality)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | ECU 状态管理器应向应用程序提供用于检索所选复位模式的服务。 |
|
||
| Rationale | 应用程序可能需要检查是否选择了适当的关闭目标。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01056, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.15 [SRS_ModeMgm_09101] 应提供查询复位原因的 API (An API to query the reset reason shall be provided)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | ECU 状态管理器应提供 API 来查询上次复位的原因。 |
|
||
| Rationale | 此功能需要根据复位是有意还是无意的来设置不同的启动场景。 |
|
||
| Use Case | 复位循环检测。 |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01056, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.16 [SRS_ModeMgm_09276] ECU 状态管理器应提供允许选择启动目标的服务 (The ECU State Manager shall provide a service allowing the selection of the boot target)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | ECU 状态管理器应向应用程序提供服务，允许选择启动目标。 |
|
||
| Rationale | 应用程序可能需要发起复位并使系统分支到引导加载程序。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01056, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.17 [SRS_ModeMgm_09275] ECU 状态管理器应提供用于查询先前复位时间的服务 (The ECU State Manager shall provide a service for querying the time of previous resets)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | ECU 状态管理器应向应用程序提供用于查询先前复位时间的服务。 |
|
||
| Rationale | 应用程序可能需要跟踪复位时间以进行诊断。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01056, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.18 [SRS_ModeMgm_09127] ECU 状态管理器应在关闭过程中适当地反初始化基础软件模块 (The ECU State Manager shall de-initialize Basic Software modules where appropriate during the shutdown process)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | valid |
|
||
| Description | ECU 状态管理器应在关闭过程中适当地反初始化基础软件模块。 |
|
||
| Rationale | 协调的 ECU 关闭。 |
|
||
| Use Case | -- |
|
||
| Dependencies | [SRS_ModeMgm_09147] |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01096, RS_BRF_01448)
|
||
|
||
**4.1.1.1.2.19 [SRS_ModeMgm_09116] 应提供 RUN 状态的请求和释放 (Requesting and releasing the RUN state shall be provided)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | valid |
|
||
| Description | ECU 状态管理器应提供服务以请求和释放 RUN 状态。 |
|
||
| Rationale | 保持 ECU 处于 RUN 状态的决策始终与应用上下文相关，无法标准化。 因此 ECU 状态管理器需要从应用角度获取 "user-requests" 以了解当前情况。 建议具有独立 RUN 状态需求的独立应用（SWC）应通过使用 ECU 状态管理器提供的接口来控制其 "user request"。 |
|
||
| Use Case | 在 ECU 上发生与催化排气系统的预热功能相关的唤醒事件（例如门接触），该 ECU 通过软件覆盖和控制此功能。 通过此唤醒事件，应在 ECU 状态管理器上建立进入此 ECU 的 RUN 状态的请求。 一旦预热完成，预热功能应释放其保持 RUN 状态的需求。 如果此 ECU 上没有其他应用软件组件请求保持 RUN 状态，则 ECU 状态管理器将继续进行关闭过程。 |
|
||
| Dependencies | [SRS_ModeMgm_09115] 评估保持 RUN 状态的条件。 |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01096, RS_BRF_01488, RS_BRF_01448)
|
||
|
||
#### 4.1.2 固定 (Fixed) — 摘要
|
||
|
||
> **翻译说明**：
|
||
> 请注意，具有固定状态机的 ECU 状态管理器规范不再是本发布版本的一部分。 EcuM Fixed 是 EcuM 的一个变体，具有一组固定的状态：OFF、RUN、SLEEP 和瞬态：STARTUP、WAKEUP、SHUTDOWN。
|
||
>
|
||
> 详细需求（SRS_ModeMgm_09120、09147、09146、09001、09173、09114、09113、09009、09118、09115、09164、09165、09166、09145 等）的完整列表请参见原始 PDF 文档。 这些需求涵盖了 EcuM Fixed 的配置、初始化/反初始化顺序、状态转换、POST_RUN 状态、唤醒/睡眠操作等方面。
|
||
|
||
#### 4.1.3 灵活 (Flex)
|
||
|
||
**EcuM Flex** 是 EcuM 的一个变体，可以非常灵活的方式控制 ECU 状态（BSW 和应用的部分运行）。 这为实现项目特定的节能策略提供了基础。 为此，它利用了 BswM（基础软件模式管理器）。
|
||
|
||
##### 4.1.3.1 功能需求 (Functional Requirements)
|
||
|
||
###### 4.1.3.1.1 正常运行 (EcuM Flexible) (Normal Operation (EcuM Flexible))
|
||
|
||
**4.1.3.1.1.1 [SRS_ModeMgm_09234] EcuM 应处理基础软件模块的初始化 (The EcuM shall handle the initialization of Basic Software modules)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | valid |
|
||
| Description | EcuM 处理初始化，直到 BswM 的模式管理启动。 |
|
||
| Rationale | 组织 BSW 的初始化过程。 |
|
||
| Use Case | 基础软件架构的已定义初始化过程。 |
|
||
| Dependencies | [SRS_ModeMgm_09120] |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01096, RS_BRF_01448)
|
||
|
||
**4.1.3.1.1.2 [SRS_ModeMgm_09235] ECU 状态管理器应提供两个用于关闭 ECU 的目标 (The ECU State Manager shall offer two targets for shutting down the ECU)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | valid |
|
||
| Description | ECU 状态管理器应至少提供以下用于关闭 ECU 的目标：断电 (Power Off)、ECU 复位 (ECU Reset)。 默认目标应由配置定义。 应有一个接口来更改目标。 |
|
||
| Rationale | 允许在能耗和唤醒/启动 ECU 的时间之间进行权衡。 |
|
||
| Use Case | 错误后的有效关闭；用于刷写的有效关闭。 |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_1096, RS_BRF_01488, RS_BRF_01448)
|
||
|
||
###### 4.1.3.1.2 报警时钟 (Alarm Clock)
|
||
|
||
**4.1.3.1.2.1 [SRS_ModeMgm_09185] 应提供本地 SW-C 使用的持久报警时钟 (A persistent Alarm Clock used by local SW-Cs shall be provided)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | ECU 状态管理器应提供一个持久的报警时钟，该时钟跟踪时间并在睡眠期间保持 "活动" 状态，并允许根据未来时间请求唤醒服务，以保证 ECU 在本地 SW-C 请求时处于 RUN 状态。 |
|
||
| Rationale | 允许基于时间的内部唤醒请求离开睡眠状态，而不仅仅是基于外部 I/O 事件。 |
|
||
| Use Case | -- |
|
||
| Dependencies | SRS_ModeMgm_09186 |
|
||
| Supporting Material | 持久性并不意味着在断电阶段非易失性，但它应在 ECU 处于任何睡眠模式并仍连接到电源时保持持久。 涵盖的功能请求：RS_BRF_00196（报警时钟） |
|
||
⌋(RS_BRF_01448)
|
||
|
||
**4.1.3.1.2.2 [SRS_ModeMgm_09186] 报警时钟应在 ECU 通电时处于活动状态 (Alarm Clock shall be active while the ECU is powered)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | 所使用的时间基准应在 ECU 通电时计时。 每次（重新）连接到电源应将内部时间重置为零，取消所有以前活动的报警，并立即重新开始计时。 |
|
||
| Rationale | 在 ECU 未通电时无法估计经过的时间，也无法在这种情况下启动任何操作。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | 在断电阶段不需要在内存中保持 armed 报警。 |
|
||
⌋(RS_BRF_01448)
|
||
|
||
**4.1.3.1.2.3 [SRS_ModeMgm_09187] 在唤醒情况下，所有报警时钟应被取消 (In Case of wakeup, all the alarm clock shall be canceled)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | 当 ECU 唤醒时，报警时钟的所有报警应被取消。 |
|
||
| Rationale | 这避免了唤醒 ECU 的意外事件导致的不期望的行为。 SW-C 负责在执行时启动报警时钟。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01448)
|
||
|
||
**4.1.3.1.2.4 [SRS_ModeMgm_09188] 在启动情况下，所有报警时钟应被取消 (In Case of startup, all the alarm clock shall be canceled)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | 当 ECU 进行上电复位时，报警时钟的所有报警应被取消。 |
|
||
| Rationale | 这避免了唤醒 ECU 的意外事件导致的不期望的行为。 SW-C 负责在执行时启动报警时钟。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01448)
|
||
|
||
**4.1.3.1.2.5 [SRS_ModeMgm_09189] 连续请求应仅遵守最早到期的报警 (Consecutive requests shall honor the earliest expiring alarm only)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | 连续请求应仅遵守最早到期的报警。 |
|
||
| Rationale | 这避免了唤醒 ECU 的意外事件导致的不期望的行为。 SW-C 负责在执行时启动报警时钟。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01448)
|
||
|
||
**4.1.3.1.2.6 [SRS_ModeMgm_09190] 报警时钟服务应允许以秒为单位的时间分辨率设置相对于当前时间的报警 (The alarm clock service shall allow setting an alarm relative to the current time using a time resolution of seconds)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | 报警时钟服务应允许以秒为单位的时间分辨率设置相对于当前时间的报警。 除了仅在 ECU 离开 RUN 模式（POSTRUN）时允许使用此接口之外，没有访问限制。 |
|
||
| Rationale | SW-C 应能够设置报警。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01448)
|
||
|
||
**4.1.3.1.2.7 [SRS_ModeMgm_09199] 报警时钟服务应允许通过使用秒级分辨率的绝对时间设置绝对报警 (The alarm clock service shall allow setting an alarm absolute by using an absolute time with a resolution of seconds)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | 报警时钟服务应允许通过使用绝对时间（但相对于计时器的开始）以秒级分辨率设置绝对报警。 除了仅在 ECU 离开 RUN 模式（POSTRUN）时允许使用此接口之外，没有访问限制。 |
|
||
| Rationale | SW-C 应能够设置报警。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01448)
|
||
|
||
**4.1.3.1.2.8 [SRS_ModeMgm_09194] 报警时钟服务应允许设置时钟 (The alarm clock service shall allow setting the clock)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | 报警时钟服务应允许设置时钟。 没有访问限制。 这可用于将报警时钟与任何其他时钟同步（例如由 GPS 接收器接收的时钟）。 |
|
||
| Rationale | SW-C 应能够将报警时钟与其他时间源同步。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01448)
|
||
|
||
**4.1.3.1.2.9 [SRS_ModeMgm_09277] ECU 状态管理器应提供报警时钟服务，该服务应允许检索时钟值 (The ECU State Manager shall provide an alarm clock service which shall allow the retrieval of clock values)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | ECU 状态管理器应向应用程序提供报警时钟服务，该服务应允许检索时钟值。 |
|
||
| Rationale | 应用程序可能需要读取当前时钟值。 |
|
||
| Use Case | -- |
|
||
| Dependencies | -- |
|
||
| Supporting Material | -- |
|
||
⌋(RS_BRF_01448)
|
||
|
||
###### 4.1.3.1.3 多核 (Multi Core)
|
||
|
||
**4.1.3.1.3.1 [SRS_ModeMgm_09236] 应有一个区分不同核的 EcuM_Init 函数实例 (There shall be one instance of the function EcuM_Init that distinguishes between the different cores)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | valid |
|
||
| Description | 应有一个 EcuM_Init 函数实例，通过 OS 服务 "GetCoreID" 区分不同的核。 |
|
||
| Rationale | "InitSequence 1" 可以是核特定的。 多核架构的理念是拥有一个二进制文件，因此 "EcuM_Init" 仅存在一次。 |
|
||
| Use Case | • 核特定的硬件初始化；• 一个核启动其他核，而其他核不启动进一步的核。 |
|
||
| Dependencies | -- |
|
||
| Supporting Material | AUTOSAR 多核 OS 架构规范 |
|
||
⌋(RS_BRF_01160, RS_BRF_00206, RS_BRF_01448)
|
||
|
||
**4.1.3.1.3.2 [SRS_ModeMgm_09237] RTE_Start 应该在每个核上调用 (RTE_Start shall be called on each core)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | RTE_Start 应通过 BswM 在主核上通过专用的可用动作触发的任务在每个核上本地调用。 |
|
||
| Rationale | 有必要协调核上的 RTE 启动，因为从核上的 RTE 可能请求使用主核上可能尚未初始化的模块。 同样，有必要避免 RTE 的跨核传播，否则会增加其复杂性并使其远超 "宏层"。 |
|
||
| Use Case | 如果没有协调，从核上 RTE 的启动可能比主核早得多，主核上运行着更多的模块，每个模块都需要初始化时间。 |
|
||
| Dependencies | -- |
|
||
| Supporting Material | AUTOSAR 多核 OS 架构规范 |
|
||
⌋(RS_BRF_01160, RS_BRF_00206, RS_BRF_01448)
|
||
|
||
**4.1.3.1.3.3 [SRS_ModeMgm_09238] 状态变化应为 ECU 全局的 (State changes shall be ECU global)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | 状态变化应为 ECU 全局的（所有核都切换到有效状态）。 整个 ECU 仅可切换到 "off"、"fully functional" 或 "sleeping"（已停止或设置为轮询）。 |
|
||
| Rationale | 应减少/避免多并行存在状态所引入的复杂性和问题。 （至少对于 R 4.0） |
|
||
| Use Case | 每次状态变化。 |
|
||
| Dependencies | -- |
|
||
| Supporting Material | AUTOSAR 多核 OS 架构规范 |
|
||
⌋(RS_BRF_01160, RS_BRF_00206, RS_BRF_01448)
|
||
|
||
**4.1.3.1.3.4 [SRS_ModeMgm_09239] 为了关闭，ShutdownAllCores 应在同步所有核后在主核上调用 (To shutdown, ShutdownAllCores shall be called on the master core after synchronizing all cores)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | 为了停止运行（关闭 ECU），ShutdownAllCores 应在同步所有核后在主核上调用。 |
|
||
| Rationale | 应用程序开发人员/系统集成商有责任确保在调用 "ShutdownAllCores" 之前完成在应用程序和基础软件级别上为关闭所做的任何准备工作。 AUTOSAR R4.0 不支持核单独的关闭。 |
|
||
| Use Case | 整个 ECU 的同步关闭。 |
|
||
| Dependencies | -- |
|
||
| Supporting Material | AUTOSAR 多核 OS 架构规范 |
|
||
⌋(RS_BRF_01160, RS_BRF_00206, RS_BRF_01448)
|
||
|
||
**4.1.3.1.3.5 [SRS_ModeMgm_09254] 唤醒事件的验证和处理应在本地完成 (Validation and handling of a wakeup event shall be done locally)**
|
||
|
||
⌈
|
||
| 字段 | 内容 |
|
||
|------|------|
|
||
| Type | Valid |
|
||
| Description | 唤醒事件的验证和处理应在配置中分配唤醒的核上本地完成。 |
|
||
| Rationale | 每个唤醒事件在特定核的 EcuM 实例中精确配置。 唤醒处理（包括其验证）应在该核上本地完成。 |
|
||
| Use Case | 在多核架构中唤醒核并验证唤醒事件。 |
|
||
| Dependencies | -- |
|
||
| Supporting Material | 概念 EnhancedBSWAllocation |
|
||
⌋(RS_BRF_01104, RS_BRF_01448)
|
||
|
||
### 4.2 看门狗管理器 (Watchdog Manager, WdgM) — 摘要
|
||
|
||
> **翻译说明**：看门狗管理器（WdgM）负责基于应用软件的时间约束（时间程序流监控）和正确执行顺序（逻辑程序流监控）来监督应用执行的可靠性。 它监督多个独立的应用程序，监督安全相关任务和周期函数的执行，提供故障反应机制，并支持通过看门狗驱动程序触发内部或外部、标准或窗口看门狗。 看门狗模式（Off Mode、Slow Mode、Fast Mode）的选择取决于 ECU 状态和硬件功能。
|
||
>
|
||
> 详细需求（包括 SRS_ModeMgm_09107 初始化、SRS_ModeMgm_09108 模式切换、SRS_ModeMgm_09109 监督、SRS_ModeMgm_09110 alive 指示、SRS_ModeMgm_09111 触发、SRS_ModeMgm_09112 故障处理 等）的完整列表请参见原始 PDF 文档。
|
||
>
|
||
> 主要需求类别：
|
||
> - 4.2.2.1 初始化 (Initialization)
|
||
> - 4.2.2.2 正常操作 (Normal Operation)
|
||
> - 4.2.2.3 关闭和唤醒 (Shutdown and Wakeup)
|
||
> - 4.2.2.4 监督 (Supervision)
|
||
> - 4.2.2.5 Alive 监督 (Alive Supervision)
|
||
> - 4.2.2.6 程序流监控 (Program Flow Monitoring)
|
||
> - 4.2.2.7 错误处理 (Error Handling)
|
||
> - 4.2.3 错误操作 (Fault Operation)
|
||
|
||
### 4.3 通信管理器 (Communication Manager, ComM) — 摘要
|
||
|
||
> **翻译说明**：通信管理器（ComM）负责协调 ECU 上的通信。 它管理用户的通信请求，限制通信模式（例如 NONE_COM、SilentCommunication、FullCommunication），并与总线状态管理器（CanSM、FrSM、EthSM、LinSM）协调以响应网络状态变化。 ComM 还支持部分网络（Partial Network Cluster），并提供资源管理。
|
||
>
|
||
> 详细需求（包括通信模式、用户、通道、PNC、请求/释放、限制模式、唤醒、ECU 群组、错误处理等）的完整列表请参见原始 PDF 文档。
|
||
|
||
### 4.4 基础软件模式管理器 (Basic Software Mode Manager, BswM)
|
||
|
||
> **翻译说明**：BswM 通过标准化接口收集模式请求并相应地控制其他 BSW 模块的功能。 它支持模式处理和模式相关交互。 BswM 仲裁模式请求并根据仲裁结果执行预定义的动作。 详细需求请参见原始 PDF 文档和 SWS BswM 规范。
|
||
>
|
||
> 详细需求（包括 SRS_BswM_xxxxx 各项）的完整列表请参见原始 PDF 文档。
|
||
|
||
---
|
||
|
||
## 5 需求追踪 (Requirements Tracing)
|
||
|
||
> 完整的需求追踪表（包括每个 SRS_ModeMgm_xxxxx 需求到 RS_BRF_xxxxx 特征的映射）请参见原始 PDF 文档的 5 章。 下表提供了简要概览。
|
||
|
||
| 需求 ID | 模块 | 主题 | 链接的特征 |
|
||
|--------|------|------|-----------|
|
||
| SRS_ModeMgm_09122 | EcuM Common | 用户配置 | RS_BRF_01488, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09100 | EcuM Common | 唤醒源配置 | RS_BRF_01496, RS_BRF_01104, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09104 | EcuM Common | OS 关闭后接管控制 | RS_BRF_01096, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09128 | EcuM Common | 多关闭目标 | RS_BRF_01096, RS_BRF_01488, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09270 | EcuM Common | 关闭目标选择服务 | RS_BRF_01096, RS_BRF_01488, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09271 | EcuM Common | 关闭目标检索服务 | RS_BRF_01096, RS_BRF_01488, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09119 | EcuM Common | 多睡眠模式 | RS_BRF_01488, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09102 | EcuM Common | 睡眠模式选择 API | RS_BRF_01488, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09272 | EcuM Common | 最后睡眠目标检索 | RS_BRF_01488, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09072 | EcuM Common | 强制 ECU 关闭 | RS_BRF_01488, RS_BRF_01056, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09017 | EcuM Common | 查询当前 ECU 状态 | RS_BRF_01488, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09136 | EcuM Common | 唤醒事件接收 | RS_BRF_01488, RS_BRF_01496, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09098 | EcuM Common | 唤醒原因存储 | RS_BRF_01448 |
|
||
| SRS_ModeMgm_09097 | EcuM Common | 唤醒超时 | RS_BRF_01104, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09126 | EcuM Common | 唤醒原因查询 API | RS_BRF_01056, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09274 | EcuM Common | 复位模式检索 | RS_BRF_01056, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09101 | EcuM Common | 复位原因查询 | RS_BRF_01056, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09276 | EcuM Common | 启动目标选择 | RS_BRF_01056, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09275 | EcuM Common | 复位时间查询 | RS_BRF_01056, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09127 | EcuM Common | BSW 反初始化 | RS_BRF_01096, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09116 | EcuM Common | RUN 请求/释放 | RS_BRF_01096, RS_BRF_01488, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09234 | EcuM Flex | BSW 模块初始化 | RS_BRF_01096, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09235 | EcuM Flex | 关闭目标 | RS_BRF_1096, RS_BRF_01488, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09185 | EcuM Flex | 持久报警时钟 | RS_BRF_01448 |
|
||
| SRS_ModeMgm_09186 | EcuM Flex | 报警时钟通电 | RS_BRF_01448 |
|
||
| SRS_ModeMgm_09187 | EcuM Flex | 唤醒时取消报警 | RS_BRF_01448 |
|
||
| SRS_ModeMgm_09188 | EcuM Flex | 启动时取消报警 | RS_BRF_01448 |
|
||
| SRS_ModeMgm_09189 | EcuM Flex | 连续请求最早报警 | RS_BRF_01448 |
|
||
| SRS_ModeMgm_09190 | EcuM Flex | 相对时间报警 | RS_BRF_01448 |
|
||
| SRS_ModeMgm_09199 | EcuM Flex | 绝对时间报警 | RS_BRF_01448 |
|
||
| SRS_ModeMgm_09194 | EcuM Flex | 设置时钟 | RS_BRF_01448 |
|
||
| SRS_ModeMgm_09277 | EcuM Flex | 时钟值检索 | RS_BRF_01448 |
|
||
| SRS_ModeMgm_09236 | EcuM Flex | EcuM_Init 多核 | RS_BRF_01160, RS_BRF_00206, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09237 | EcuM Flex | RTE_Start 每核 | RS_BRF_01160, RS_BRF_00206, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09238 | EcuM Flex | 状态变化 ECU 全局 | RS_BRF_01160, RS_BRF_00206, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09239 | EcuM Flex | ShutdownAllCores | RS_BRF_01160, RS_BRF_00206, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09254 | EcuM Flex | 本地唤醒处理 | RS_BRF_01104, RS_BRF_01448 |
|
||
| SRS_ModeMgm_09107 .. 09112 | WdgM | 初始化、监督等 | RS_BRF_xxxxx |
|
||
| SRS_ComM_xxxxx | ComM | 通信管理 | RS_BRF_xxxxx |
|
||
| SRS_BswM_xxxxx | BswM | 模式管理 | RS_BRF_xxxxx |
|
||
|
||
> 完整的需求追踪表见原始 PDF 文档的 5 章。
|
||
|
||
---
|
||
|
||
## 6 参考文献 (References)
|
||
|
||
[1] AUTOSAR Layered Software Architecture
|
||
[2] AUTOSAR Basic Software Module Description Template
|
||
[3] AUTOSAR Specification of Watchdog Manager
|
||
[4] AUTOSAR Specification of Communication Manager
|
||
[5] AUTOSAR Specification of ECU State Manager
|
||
[6] AUTOSAR Main Requirements
|
||
[7] AUTOSAR Requirements on Architecture
|
||
[8] AUTOSAR Specification of BSW Mode Manager
|
||
[9] AUTOSAR Requirements Specification Template
|
||
|
||
---
|
||
|
||
## 翻译说明
|
||
|
||
本文档为 AUTOSAR CP Release 4.4.0《模式管理需求》的中文翻译。 主要翻译内容包括：
|
||
|
||
1. **完整翻译**：
|
||
- 文档标识、变更历史
|
||
- 目录
|
||
- 第 1 章 文档范围
|
||
- 第 2 章 使用的约定（关键字解释）
|
||
- 第 3 章 术语（完整术语表、缩写表）
|
||
- 第 4.1.1 节 EcuM 通用需求（约 20 个核心需求完整翻译）
|
||
- 第 4.1.3 节 EcuM Flex 需求（包含报警时钟、多核等 16 个核心需求完整翻译）
|
||
2. **摘要标记**：
|
||
- 第 4.1.2 节 EcuM Fixed（注明不再属于本发布版本）
|
||
- 第 4.2 节 WdgM
|
||
- 第 4.3 节 ComM
|
||
- 第 4.4 节 BswM
|
||
3. **保留内容**：
|
||
- 所有 API 标识符
|
||
- 模块缩写（EcuM、ComM、WdgM、BswM、SW-C、SWC、SW、BSW、RTE 等）
|
||
- 状态名称（RUN、SHUTDOWN、SLEEP、POST_RUN、OFF 等）
|
||
- AUTOSAR 方框符 `⌈⌋`
|
||
- 需求 ID（SRS_ModeMgm_xxxxx）
|
||
- 文档间交叉引用
|