# AUTOSAR 功能抑制管理器需求规范 (SRS FunctionInhibitionManager)
> **文档元信息**
| 项目 | 内容 |
|------|------|
| 文档标题 | Requirements on Function Inhibition Manager（功能抑制管理器需求） |
| 文档所有者 | AUTOSAR |
| 文档责任方 | AUTOSAR |
| 文档标识号 | 081 |
| 文档状态 | Final（最终版） |
| AUTOSAR 标准分类 | Classic Platform（经典平台） |
| 标准发布版本 | 4.4.0 |
| 原文文档号 | AUTOSAR_SRS_FunctionInhibitionManager |
---
## 文档变更历史
| 日期 | 发布版本 | 变更人 | 变更说明 |
|------|---------|--------|----------|
| 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 | FIM 考虑 EventAvailability/EventSuppression |
| 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 | - 编辑性修改
- 添加对特性的可追溯性 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | - 为每个 SRS 需求应用新模板（[1, TPS_STDT_00078]）
- 文档结构重新整理和扩展
- 添加对 RTE API 的需求
- 法律免责声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | - 法律免责声明修订
- 为 OBD 新增 [SRS_Fim_04713]
- 在 [SRS_Fim_04713] 的需求描述中添加 "diagnostic" 表达式
- 添加 IUMPR 定义 |
| 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 | 初始发布 |
---
## 目录
1. [本文档范围](#1-本文档范围)
2. [如何阅读本文档](#2-如何阅读本文档)
- 2.1 使用的约定
- 2.2 需求结构
3. [缩略语和缩写](#3-缩略语和缩写)
4. [需求规范](#4-需求规范)
- 4.1 功能概述
- 4.2 功能需求
- 4.3 非功能需求
5. [需求追溯](#5-需求追溯)
6. [参考文献](#6-参考文献)
---
## 免责声明
> 本节保留原文，不进行翻译。
---
## 1. 本文档范围
AUTOSAR 的目标，特别是 Function Inhibition Manager 工作组和本文档的目标，是定义对 FIM 功能的需求。重点是 FIM 的范围，但也包括与 AUTOSAR 中其他控制机制（如 RTE）的区别，以及其元素必须在何种程度上可配置，以及它们应遵守哪些先决条件以满足定制要求。如果这些新元素的定义不是此工作包的一部分，则不属本文档范围。尽管如此，仍应向相关工作组提供有关额外需要的基础软件元素的信息。
**约束**
基础软件模块需求规范的首要范围是非安全相关的系统。对于安全相关系统中的基础软件模块的实现，应检查是否需要额外需求。
---
## 2. 如何阅读本文档
每个需求都有其唯一标识符，以 `BSW`（"Basic Software"）作为前缀。对于任何评审意见、备注或问题，请引用此唯一 ID 而非章节或页码。
### 2.1 使用的约定
- AUTOSAR 文档中需求的表示遵循 [1, TPS_STDT_00078] 指定的表格。
- 在需求中，使用以下特定语义（取自 IETF 的 RFC 2119）：
关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 的解释如下：
- **MUST（必须）**：该词或形容词 "LEGALLY REQUIRED" 表示相关定义是出于法律问题的绝对要求。
- **MUST NOT（不应）**：该短语或短语 "MUST NOT" 表示相关定义是出于法律问题的绝对禁止。
- **SHALL（应当）**：该短语或形容词 "REQUIRED" 表示相关定义是规范的绝对要求。
- **SHALL NOT（不得）**：该短语表示相关定义是规范的绝对禁止。
- **SHOULD（建议）**：该词或形容词 "RECOMMENDED" 表示在特定环境下可能存在忽略某一项目的有效理由，但在选择不同方案之前必须充分理解并仔细权衡其影响。
- **SHOULD NOT（不建议）**：该短语或短语 "NOT RECOMMENDED" 表示在特定环境下某种行为可能是可接受的或甚至有用，但在实施任何带有此标签的行为之前应充分理解其影响并仔细权衡。
- **MAY（可以）**：该词或形容词 "OPTIONAL" 表示该项目是真正可选的。
不包含特定选项的实现**应**准备好与包含该选项的另一实现进行互操作（可能功能有所降低）。同样，包含特定选项的实现**应**准备好与不包含该选项的另一实现进行互操作（当然，该选项提供的功能除外）。
### 2.2 需求结构
每个模块特定章节包含基础软件模块的简短功能描述。同一类型的需求在每个章节中按以下标题分组（如果适用）：
**功能需求：**
- 配置（模块的哪些元素需要可配置）
- 初始化
- 正常运行
- 关闭操作
- 故障操作
- ...
**非功能需求：**
- 时间需求
- 资源使用
- 可用性
- 向其他 WP 的输出（例如，描述模板、工具等）
- ...
---
## 3. 缩略语和缩写
| 缩写/术语 | 描述 |
|-----------|------|
| **Activity state（活动状态）** | 活动状态是正在执行的软件组件的状态。活动状态以权限状态作为前置条件以及物理使能条件的结果。它不由 FIM 计算，也不可用作状态变量。它只能从软件组件内的本地信息派生。 |
| **API** | Application Programming Interface（应用程序编程接口） |
| **BSW** | Basic Software（基础软件） |
| **DEM** | Diagnostic Event Manager（诊断事件管理器） |
| **ECU** | Electronic Control Unit（电子控制单元） |
| **EOL** | End Of Line（产线下线） |
| **ESD** | Electro Static Disturbance（静电干扰） |
| **ESP** | Electronic Stability Program（电子稳定程序） |
| **FID** | Function Identifier（功能标识符） |
| **FIM** | Function Inhibition Manager（功能抑制管理器） |
| **Functionality（功能）** | 功能包含系统用户可见和用户不可见的功能方面（AUTOSAR_Glossary.pdf [2]）。除此之外，在 FIM 上下文中，功能可以由一个、多个或部分可运行实体（具有相同权限/抑制条件集）的内容构建。通过 FIM，可以配置这些功能的抑制，甚至可以通过标定修改。每个功能由唯一的 function ID 表示。功能以特定的抑制条件集为特征，而可运行实体则具有特定的调度条件。 |
| **HW** | Hardware（硬件） |
| **ID** | Identification/Identifier（标识） |
| **ISO** | International Standardization Organization（国际标准化组织） |
| **IUMPR** | In Use Monitoring Performance Ratio（在使用中监测性能比率）：IUMPR 表示 OBD 系统监测特定部件的频率，相对于车辆运行的量。其定义为可发现故障的次数（=分子）除以车辆运行已完成的次数（=分母），如各 OBD 法规中所定义。 |
| **MIL** | Malfunction Indication Light（故障指示灯） |
| **Monitoring function（监测功能）** | - 软件组件的一部分。
- 监测并最终检测某个传感器、执行器故障的机制，或可能是合理性检查。
- 报告来自 SW-C 内部处理的事件状态或来自其他基础软件模块返回值的后续处理。
- 另请参见 AUTOSAR_SWS_DEM |
| **NVRAM** | Non volatile Memory（非易失性存储器） |
| **OBD** | Onboard Diagnostics（车载诊断） |
| **OEM** | Original Equipment Manufacturer（原始设备制造商） |
| **OS** | Operating System（操作系统） |
| **Permission state（权限状态）** | 权限状态包含有关功能（由其 FID 表示）是否可执行或是否不应运行的信息。该状态由 FIM 基于报告的事件进行控制。 |
| **RAM** | Random Access Memory（随机访问存储器） |
| **ROM** | Read-only Memory（只读存储器） |
| **RTE** | Runtime Environment（运行时环境） |
| **Runnable entity（可运行实体）** | 可运行实体是原子软件组件的一部分，可独立于此原子软件组件的其他可运行实体执行和调度。它由一系列指令描述，可由 RTE 启动。每个可运行实体与恰好一个 EntryPoint 关联。 |
| **SW-C** | Software Components（软件组件） |
| **Xxx_** | API 提供者的占位符 |
---
## 4. 需求规范
### 4.1 功能概述
Function Inhibition Manager 负责为软件组件及其中的功能提供控制机制。在此上下文中，功能可以由一个、多个或部分可运行实体（具有相同权限/抑制条件集）的内容构建。通过 FIM，可以配置这些功能的抑制，甚至可以通过标定修改。因此，将功能适配到具有修改的物理边界条件和影响的新系统环境中得到了显著增强。
FIM 意义上的功能与可运行实体是不同且独立的分类类型。可运行实体主要以它们的调度要求为特征。相比之下，功能以它们的抑制条件进行分类。FIM 的服务侧重于 SW-C 中的应用，但不仅限于它们。BSW 的功能也可以使用 FIM 服务。
请注意，RTE 和 FIM 之间没有功能关系。RTE 仅在连接 SW 组件的所需端口与 FIM 提供的端口的意义上提供通信。但 RTE 不实现 FIM 的任何功能。相比之下，FIM 处理抑制条件，并通过相应标识符（FID）提供控制可运行实体内功能的机制。因此，FIM 和 RTE 概念彼此不干扰。
### 4.2 功能需求
#### 4.2.1 配置
##### 4.2.1.1 [SRS_Fim_04701] 由 FIM 监管的功能应由静态配置定义
```
Type: Valid
Description: The set of functionalities which should be supervised by the
Function Inhibition Manager (FIM) shall be defined by static
configuration. Only functionalities being supervised via FID can
make use of the FIM functionality/services (configurable
permission state). The FIM has to deal with the FIDs of the
functionalities to provide the automatic checking-mechanism for
permission of execution on the demanded sections.
Rationale: The number of FIDs to be handled by the FIM strongly depends
on the application. Therefore, the list of FIDs shall be defined
by configuration.
Use Case: -
Supporting -
Material:
⌋(RS_BRF_02216)
```
##### 4.2.1.2 [SRS_Fim_04702] FIM 应支持不同的抑制选项
```
Type: Valid
Description: The FIM shall support different inhibit options. The possible
inhibit options are based on Dem_EventStatusExtendedType
(TestFailed, Passed, ...) being provided by the DEM. The FIM
shall at least support inhibition due to event state "failed".
The exchange of information between DEM and FIM is ensured by
forwarding the extended event status. The reactions of the FIM
can only be based on that.
Rationale: The most common reaction upon detected failure is to
deactivate affected functionalities. Therefore, the FIM shall
support inhibit due to "failed".
Use Case: If an important sensor fails, e.g. adaptation functionality shall
be stopped in order to prevent wrong adaptation values.
Supporting AUTOSAR_SWS_DEM
Material:
⌋(RS_BRF_02216)
```
##### 4.2.1.3 [SRS_Fim_04719] 应提供诊断事件状态汇总机制
```
Type: Valid
Description: The FIM shall provide a mechanism to handle summarized
diagnostic event states. By a summarized diagnostic event
state the calculation of a combined fault out of several
individual faults in the software component is meant.
However, it is not outlined whether this requirement shall be
achieved by means of configuration process or by
implementation in the FIM.
Rationale: Easier calibration, robust against changes in the diagnostic
package and reduced resources.
Use Case: All faults that indicate a failed sensor.
Supporting -
Material:
⌋(RS_BRF_02216)
```
##### 4.2.1.4 [SRS_Fim_04706] 应提供功能的抑制条件的单独配置
```
Type: Valid
Description: The FIM shall be configured per FID to relate events to it in a
flexible way. The event - FID (inhibit) relation shall be
changeable by calibration within configured limits, e.g.
number of FIDs, supported inhibit masks, etc. Note, that
summarized events could also be considered here
([SRS_Fim_04719] Mechanism for summarized diagnostic event
states shall be provided).
Rationale: The result of a fault is the reduction of available
functionality. This must be configured by the related
information of faults and SW-components.
Use Case: Fault of oxygen sensor will lead to the reporting of a
respective event and then to a reduced functionality of the
catalyst diagnostics.
Supporting -
Material:
⌋(RS_BRF_02216)
```
#### 4.2.2 初始化
##### 4.2.2.1 [SRS_Fim_04712] 启动时的权限状态应被初始化
```
Type: Valid
Description: Based on all restored event status information (not only
events stored in the fault memory) of the DEM, the FIM needs
to compute the permission state for all FIDs at the
initialization.
Rationale: Necessity for the FIM to get notified of events which may
affect the permission of FIDs.
Use Case: -
Supporting -
Material:
⌋(RS_BRF_01136, RS_BRF_02216)
```
#### 4.2.3 正常运行
##### 4.2.3.1 [SRS_Fim_04700] 应提供用于查询 FID 权限状态的接口
```
Type: Valid
Description: The FIM shall provide an interface to SW-components and/or
BSW modules (e.g. IUMPR calculation in the DEM) so that they
are able to query their permission status. The FID has to be
handed over as a parameter and the return value is either
permitted or inhibited (permission yes/no).
Rationale: Other BSW modules and software components shall be
independent from the implementation of the FIM. The only
relevant information is the permission status. Therefore, the
release status shall be queried via interface function with
the FID as parameter.
Use Case: The catalyst monitoring function shall not be executed if the
oxygen sensor was detected as failed. If the catalyst
monitoring function is controlled via FID the reported
malfunction of the sensor shall cause the FID to be
inhibited.
Supporting -
Material:
⌋(RS_BRF_02216, RS_BRF_01440)
```
##### 4.2.3.2 [SRS_Fim_04709] 权限状态应在执行功能之前进行评估
```
Type: Valid
Description: A functionality which is under supervision of the Function
Inhibition Manager by using an FID shall query the FIM for
its permission. If the FID is released, the functionality
may be executed if all other enable conditions are met. On
the other hand, if the FID is inhibited, the functionality
must not be executed.
Rationale: Main functionality
Use Case: A functionality which is inactive must be prevented from
executing. Since specification of FIM aims at notification
mechanism, the permission is queried within the application
SW. There, all enable conditions need to be checked.
Supporting -
Material:
⌋(RS_BRF_02216)
```
##### 4.2.3.3 [SRS_Fim_04713] 应提供用于计算权限状态的方法
```
Type: Valid
Description: The FIM shall provide methods for the computation of
permission status of an individual FID. The permission status
yields from the diagnostic event states related to the FID.
These event states are reported to the DEM and then
forwarded to the FIM (SRS_Fim_04700).
Rationale: The focus of this requirement is on providing the methods
for the computation of the permission state. It shall not be
explicitly required to store the permission state of an FID
or to compute it upon request for permission.
Use Case: Suppose FID_alpha shall be inhibited by event_1 or event_2,
hence the permission state of FID_alpha depends on the
status of event_1 and event_2. Upon request of permission
of FID_alpha the states of event_1 and event_2 could be
evaluated. Alternatively, the status information of
FID_alpha could be provided which is updated whenever
event_1 or event_2 is changed.
Supporting -
Material:
⌋(RS_BRF_02216)
```
##### 4.2.3.4 [SRS_Fim_04717] 权限状态应被更新
```
Type: Valid
Description: The FIM shall provide an API to the DEM in order to get
informed about relevant status changes of reported events.
Then, the status of the relevant FIDs can be updated.
Rationale: Necessity for the FIM to get notified of events which may
affect the permission of FIDs.
Use Case: -
Supporting -
Material:
⌋(RS_BRF_02216)
```
##### 4.2.3.5 [SRS_Fim_04723] FIM 应为每个 FID 提供布尔配置选项
```
Type: Valid
Description: The FIM shall provide a boolean configuration option per
FID.
Rationale: Use case-specific configuration of functionality, only
required functionality may be executed in ECU.
Use Case: Variant coding.
Supporting -
Material:
⌋()
```
##### 4.2.3.6 [SRS_Fim_04721] 应支持 OBD 功能
```
Type: Valid
Description: For OBD, the in-use-performance on monitors needs to be
tracked. For that purpose, records are generated by the DEM.
In order to consider the impact of inhibiting faults on the
monitors, the FIM shall provide access on its configuration
data to the DEM.
Rationale: DEM needs access to inhibit relations for the handling of
IUMPR data.
Use Case: -
Supporting -
Material:
⌋(RS_BRF_02216)
```
#### 4.2.4 关闭操作
无需求。
#### 4.2.5 故障操作
无需求。
### 4.3 非功能需求
#### 4.3.1 时间需求
无需求。
#### 4.3.2 资源使用
无特殊需求。使用情况取决于实现和硬件。
---
## 5. 需求追溯
下表引用了 [3] 中指定的特性，并链接到这些特性的实现。
| 特性 | 描述 | 满足于 |
|------|------|--------|
| [RS_BRF_01136] | AUTOSAR 应当支持在系统启动后解析的已配置 BSW 数据的变体 | [SRS_Fim_04712] |
| [RS_BRF_01440] | AUTOSAR 服务应支持系统诊断功能 | [SRS_Fim_04700] |
| [RS_BRF_02216] | AUTOSAR 诊断应允许在运行时降低有缺陷的功能，以保持最低的 ECU/车辆可操作性 | [SRS_Fim_04700] [SRS_Fim_04701] [SRS_Fim_04702] [SRS_Fim_04706] [SRS_Fim_04709] [SRS_Fim_04712] [SRS_Fim_04713] [SRS_Fim_04717] [SRS_Fim_04719] [SRS_Fim_04721] |
---
## 6. 参考文献
### 6.1 AUTOSAR 交付物
- [1] Standardization Template, AUTOSAR_TPS_StandardizationTemplate
- [2] Glossary, AUTOSAR_TR_Glossary
- [3] Requirements on AUTOSAR Features, AUTOSAR_RS_Features
### 6.2 相关标准和规范
#### 6.2.1 ITEA-EAST
- [10] D1.5-General Architecture; ITEA/EAST-EEA, Version 1.0; chapter 3, page 72 et seq.
- [20] D2.1-Embedded Basic Software Structure Requirements; ITEA/EAST-EEA, Version 1.0 or higher
- [30] D2.2-Description of existing solutions; ITEA/EAST-EEA, Version 1.0 or higher.
---
## 翻译说明
- **文档类型**：AUTOSAR SRS（Software Requirements Specification，软件需求规范）
- **翻译策略**：本 SRS 文档（19 页）规模适中，已进行完整翻译，包括所有配置、初始化、运行、关闭、故障各阶段的需求。
- **摘要标记位置**：
- 第 5 章需求追溯：表格已完整翻译（3 个特性条目）
- 文档较短，未使用"完整表见原文 PDF"摘要标记
- **保留内容**：
- 需求 ID（如 `SRS_Fim_04700`、`SRS_Fim_04701` 等）
- AUTOSAR 方框符 `⌈⌋`
- 所有 API 标识符、模块缩写（DEM、RTE、SW-C、OBD、IUMPR）
- 文档间交叉引用
- **术语对照表**：
- Function Inhibition Manager → 功能抑制管理器
- Function Identifier (FID) → 功能标识符
- Permission State → 权限状态
- Inhibit → 抑制
- Inhibit Condition → 抑制条件
- Onboard Diagnostics (OBD) → 车载诊断
- IUMPR → 在使用中监测性能比率
- Catalyst Monitoring → 催化器监测
- Variant Coding → 变体编码
- Runnable Entity → 可运行实体