# AUTOSAR SPAL 通用需求规范
> **General Requirements on SPAL**
> AUTOSAR CP Release 4.4.0
## 元信息
- **文档类别**：SRS（Software Requirements Specification，软件需求规范）
- **模块名称**：SPAL（Standard Peripheral Abstraction Layer,标准外设抽象层)
- **关联层级**：MCAL / ECU Abstraction Layer
- **AUTOSAR 版本**：Classic Platform 4.4.0
- **文档标识号**：009
## 文档标识
| 项 | 值 |
| --- | --- |
| Document Title | General Requirements on SPAL |
| Document Owner | AUTOSAR |
| Document Responsibility | AUTOSAR |
| Document Identification No | 009 |
| Document Status | Final |
| Part of AUTOSAR Standard | Classic Platform |
| Part of Standard Release | 4.4.0 |
## 文档变更历史
| 日期 | 版本 | 变更方 | 变更说明 |
| --- | --- | --- | --- |
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性修订 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | SRS 需求引用 BMW 规范;删除对 HIS 的引用;轻微修订、澄清与编辑性变更，详情请参阅 ChangeDocumentation |
| 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 | 将需求与 BSW Feature 文档相关联;按照 TPS_StandardizationTemplate 更新需求格式 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 在 SRS_SPAL_12461 中变更:从描述中删除"所有其他寄存器应由启动代码初始化" |
| 2010-02-02 | 3.1.4 | 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 | 更新 SRS_SPAL_12092 中的用例;删除 SRS_SPAL_12077 中的支持材料,因其引用已被拒绝的需求 BSW12161;修订法律免责声明;修订"用户须知";新增"修订信息" |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 文档拆分,每个 SPAL 驱动现在拥有独立的需求文档;变更唤醒需求;新增 3 项需求;修改 9 项需求;拒绝 5 项需求 |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 首次发布 |
## 免责声明
> 本节为版权与法律声明,以英文形式发布,翻译时予以保留原文。详情请参考英文原版。
---
## 目录
1. [文档范围](#1-文档范围)
2. [需求指南](#2-需求指南)
- 2.1 [使用的约定](#21-使用的约定)
- 2.2 [需求质量](#22-需求质量)
- 2.3 [需求标识](#23-需求标识)
- 2.4 [需求结构](#24-需求结构)
3. [缩略语与缩写](#3-缩略语与缩写)
4. [概念性问题](#4-概念性问题)
- 4.1 [通用规则](#41-通用规则)
- 4.2 [不受时钟频率影响的驱动列表](#42-不受时钟频率影响的驱动列表)
- 4.3 [MCAL 相关的 ECU 电源模式](#43-mcal-相关的-ecu-电源模式)
- 4.4 [唤醒场景](#44-唤醒场景)
- 4.5 [驱动的调度与集成](#45-驱动的调度与集成)
5. [需求追溯](#5-需求追溯)
6. [需求规范](#6-需求规范)
- 6.1 [功能性需求](#61-功能性需求)
- 6.1.1 [通用需求](#611-通用需求)
- 6.2 [非功能性需求](#62-非功能性需求)
- 6.2.1 [时序需求](#621-时序需求)
- 6.2.2 [软件设计需求](#622-软件设计需求)
- 6.2.3 [流程需求](#623-流程需求)
7. [参考文献](#7-参考文献)
---
## 1 文档范围
本文档规定了以下软件层中基础软件模块的通用需求:
- Microcontroller Abstraction Layer(微控制器抽象层)
- ECU Abstraction Layer(ECU 抽象层)
上述模块包括下列类型:
- µC 内部和外部外设的驱动 Drivers
- 处理程序 Handlers
- 接口 Interfaces
模块的选择源于 WP Architecture BSW Module List 和 Layered Architecture。涵盖的模块包括:
- 内存驱动与接口(内部/外部 EEPROM、Flash、Flash EEPROM Emulation)
- I/O 驱动(PORT、ADC、DIO、PWM、ICU、OCU)
- I/O 硬件抽象
- ECU 板载通信驱动与处理程序(SPI)
- 系统驱动(内部/外部 Watchdog、MCU、GPT、RAM test)
### 约束
基础软件模块需求规范的首要范围是不涉及安全相关的系统。因此,安全需求被赋予中等优先级。
---
## 2 需求指南
应引用现有规范(以单个需求的形式)。与这些规范的差异应作为附加需求另行规定。
### 2.1 使用的约定
- AUTOSAR 文档中需求的表示形式遵循文献[5]中规定的表格。
- 在需求中,以下特定语义被使用(摘自 IETF 的 Request for Comment 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"表示某项确实是可选的。一个供应商可以选择包含该项,因为特定市场需求或供应商认为它能够提升产品,而另一供应商可以省略相同的项。不包含特定可选项的实现 MUST 准备好与包含该选项的实现互操作(可能功能有所缩减)。同理,包含特定选项的实现 MUST 准备好与不包含该选项的实现互操作(当然,除了该选项所提供的特性之外)。
### 2.2 需求质量
所有需求应具备以下属性:
- **无冗余 Redundancy**:需求不应在同一需求中或在其他需求中重复。
- **清晰性 Clearness**:所有需求只允许一种解释方式。只能使用术语表中的技术术语。
- **原子性 Atomicity**:每个需求只应包含一项需求。如果需求不能被进一步拆分,则它是原子的。
- **可测试性 Testability**:需求应可通过分析、评审或测试进行验证。
- **可追溯性 Traceability**:需求的来源和状态应始终可见。
### 2.3 需求标识
每个需求都有以前缀 "BSW"(代表"Basic Software")开头的唯一标识符。任何评审注释、备注或问题请引用此唯一 ID,而非章节或页码!
### 2.4 需求结构
每章应按以下方式组织:
**功能性需求**:
- 配置(模块中哪些元素需要可配置)
- 初始化
- 正常操作
- 关机操作
- 故障操作
- ...
**非功能性需求**:
- 时序需求
- 资源使用
- 易用性
- 给其他工作包的输出(例如描述模板、工具链等)
- ...
---
## 3 缩略语与缩写
具有局部范围的缩略语和缩写不包含在 AUTOSAR 术语表中。它们必须出现在本地术语表中。
| 缩写 | 描述 |
| --- | --- |
| CS | Chip Select(片选) |
| DIO | Digital Input Output(数字输入输出) |
| ECU | Electric Control Unit(电子控制单元) |
| ICU | Interrupt Capture Unit(中断捕获单元) |
| MAL | 微控制器抽象层的旧称(已被 MCAL 取代,因为 'MAL' 在法语中意为'坏的') |
| MCAL | Microcontroller Abstraction Layer(微控制器抽象层) |
| MCU | Microcontroller Unit(微控制器单元) |
| MMU | Memory Management Unit(内存管理单元) |
| Master | 控制其他设备(从设备,见下文)的设备 |
| Slave | 完全由主设备控制的设备 |
| NMI | Non Maskable Interrupt(不可屏蔽中断) |
| OS | Operating System(操作系统) |
| OCU | Output Compare Unit(输出比较单元) |
| PLL | Phase Locked Loop(锁相环) |
| PWM | Pulse Width Modulation(脉冲宽度调制) |
| RX | Reception(总线通信场景下的接收) |
| SPAL | Standard Peripheral Abstraction Layer(本工作组名称) |
| SFR | Special Function Register(专用功能寄存器) |
| RTE | Runtime Environment(运行时环境) |
| WP | Work Package(工作包) |
| STD | Standard(标准) |
| REQ | Requirement(需求) |
| UNINIT | Uninitialized(未初始化) |
由于本文档是面向专业人员的专业文档,其余术语默认读者已知。
---
## 4 概念性问题
### 4.1 通用规则
1. 不要在我们的回调函数内做任何超出 50 µs 运行时间的事情,这将对系统性能产生过多影响。
2. 每个驱动规范的设计应使驱动本身负责维护其内部数据的原子性和数据完整性。
3. 应用层缓冲区应作为指针从用户传递给驱动。
### 4.2 不受时钟频率影响的驱动列表
时钟频率是对 WP "Specification / Standardization of BSW" 中大多数驱动有很大影响的参数。下面列出不直接依赖时钟频率的软件模块:
- PORT
- DIO
- RAM test
**结论**:大多数驱动对时钟频率有强依赖,因此在配置每个软件组件时仔细考虑其在整个系统中的影响非常重要。
### 4.3 MCAL 相关的 ECU 电源模式
WP "Specification / Standardization of BSW" 中所包含的驱动应支持 Specification of ECU State Manager 中定义的 ECU 电源模式。
必须支持不同的时钟模式。所有驱动应支持以不同配置参数重新初始化。详情请参阅"ECU State Manager"文档。
### 4.4 唤醒场景
由于不同的时序需求(例如某些 ECU 周期性唤醒,仅检查一些输入后尽快回到睡眠状态),需要采用不同的初始化流程。例如:
- 唤醒后初始化
- 上电复位 Power On Reset 后初始化
**结论**:不可能采用标准化的唤醒序列。该序列取决于微控制器硬件和系统需求。当前规定的概念允许以标准化的方式处理唤醒信号,同时提供自定义实际唤醒序列的可能。
### 4.5 驱动的调度与集成
目前,已知 ECU 的 90% 功能采用协作式调度。原因包括:
- 技术原因:相对抢占式系统,具有更低的开销(任务切换时间和任务栈消耗)
- 技术原因:更易于创建确定性行为
- 技术原因:相对全抢占式系统,采用协作式系统更易达到稳定的 95% 系统负载
- 历史原因:许多 ECU 在使用协作式调度概念
因此,所有驱动应允许被用于协作式调度的系统中。它们不应实现阻塞代码并期望被操作系统抢占。实现提示:使用状态机代替线性代码。
---
## 5 需求追溯
| 上层需求 | 描述 | 由以下需求满足 |
| --- | --- | --- |
| RS_BRF_01064 | AUTOSAR BSW 应提供回调函数以访问上层模块 | SRS_SPAL_00157, SRS_SPAL_12056 |
| RS_BRF_01096 | AUTOSAR 应支持 ECU 启动与关机 | SRS_SPAL_12057, SRS_SPAL_12068, SRS_SPAL_12125, SRS_SPAL_12163, SRS_SPAL_12461, SRS_SPAL_12463 |
| RS_BRF_01104 | AUTOSAR 应支持 ECU 与总线的睡眠与唤醒 | SRS_SPAL_12067, SRS_SPAL_12069, SRS_SPAL_12267 |
| RS_BRF_01152 | AUTOSAR 应支持有限的动态重配置 | SRS_SPAL_12265 |
| RS_BRF_01440 | AUTOSAR 服务应支持系统诊断功能 | SRS_SPAL_12064 |
| RS_BRF_01496 | AUTOSAR 应规范化处理使 ECU 离开 SLEEP 模式的事件 | SRS_SPAL_12267 |
| RS_BRF_02168 | AUTOSAR 诊断应提供异常运行状况的集中分类与处理 | SRS_SPAL_00157, SRS_SPAL_12064 |
| RS_BRF_02232 | AUTOSAR 应支持带运行时断言检查的开发 | SRS_SPAL_00157, SRS_SPAL_12448 |
---
## 6 需求规范
### 6.1 功能性需求
#### 6.1.1 通用需求
本章包含适用于 Microcontroller Abstraction Layer 与 ECU Abstraction Layer 所有模块,但不一定适用于其他层基础软件模块的通用需求。
##### 6.1.1.1 配置
###### 6.1.1.1.1 [SRS_SPAL_12263] 所有驱动模块的实现应允许在链接时配置特定模块参数类型
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动模块的实现应允许在链接时配置下列模块参数类型:
- 写入硬件寄存器的值
- 在驱动模块中使用的值(例如时序)
- 回调函数
这些参数应置于一个模块外部的初始化数据结构中。 |
| Rationale | 以目标代码形式交付驱动模块 |
| Use Case | SVDO 与 Hella 内部开发模型 |
| Dependencies | [SRS_SPAL_12264] 配置项规范 |
| Supporting Material | 需要采用复杂的软件设计技术,以达到与源代码类似的可扩展性和资源效率。 |
⌋()
###### 6.1.1.1.2 [SRS_SPAL_12056] 所有驱动模块应允许通知机制的静态配置
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动模块应允许通知机制的静态配置。回调函数的指针不得通过 API 传递。 |
| Rationale | 灵活性与可扩展性 |
| Use Case | 提供在受保护操作系统中运行驱动的可能性。通过 API 传递且"指向任意位置"的回调不可在受保护 OS 中使用。MISRA 建议避免使用指向函数的动态指针。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01064)
###### 6.1.1.1.3 [SRS_SPAL_12267] 唤醒源应由 MCAL 驱动和/或 MCU 驱动初始化
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 唤醒源应由 MCAL 驱动和/或 MCU 驱动初始化。可能的唤醒源包括 reset、watchdog、NMI、interrupt 等。 |
| Rationale | 允许配置 MCU 唤醒。 |
| Use Case | GPT 中断由 GPT 驱动使能,应能将 MCU 从 Idle/Sleep/Stop 模式中唤醒。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01104, RS_BRF_01496)
##### 6.1.1.2 初始化
###### 6.1.1.2.1 [SRS_SPAL_12057] 所有驱动模块应实现初始化接口
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动模块应实现一个用于初始化的接口。该服务应初始化所有模块的全局变量以及由该模块使用的所有 SFR。 |
| Rationale | 基本功能。 |
| Use Case | -- |
| Dependencies | [SRS_SPAL_12125] 硬件资源的初始化 |
| Supporting Material | -- |
⌋(RS_BRF_01096)
###### 6.1.1.2.2 [SRS_SPAL_12125] 所有驱动模块应仅初始化已配置的资源
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动模块应仅初始化已配置的资源。配置文件中未配置的资源不应被触及。 |
| Rationale | 允许与复杂驱动 Complex Drivers 集成且无资源冲突。 |
| Use Case | 通道 0..3 被 GPT 驱动使用,通道 4..6 被复杂驱动使用。 |
| Dependencies | [SRS_SPAL_12057] 驱动模块初始化 |
| Supporting Material | -- |
⌋(RS_BRF_01096)
###### 6.1.1.2.3 [SRS_SPAL_12163] 所有驱动模块应实现去初始化接口
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动模块应实现一个用于去初始化的接口。该服务应将该模块使用的所有模块全局变量及所有 SFR 复位到其默认复位值。不可写寄存器的值除外。 |
| Rationale | 关闭模块。重新创建与初始化前相同的状态。清空队列。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01096)
###### 6.1.1.2.4 [SRS_SPAL_12461] 关于控制器寄存器初始化的特定规则应适用于所有驱动实现
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 关于控制器寄存器初始化的下列规则应适用于所有驱动实现:
1. 如果硬件只允许该寄存器的一次使用,实现该功能的驱动模块负责初始化该寄存器
2. 如果该寄存器可影响多个硬件模块且为 I/O 寄存器,应由 PORT 驱动初始化
3. 如果该寄存器可影响多个硬件模块且非 I/O 寄存器,应由 MCU 驱动初始化
4. 在复位后需要立即初始化的一次性可写寄存器,应由启动代码初始化 |
| Rationale | 控制器寄存器的明确初始化,无需为不同配置更改驱动实现。 |
| Use Case | 1) 所有与 flash 模块相关的寄存器应由 flash 驱动初始化
2) 可用于 CAN、ADC 或 DIO 的 I/O 寄存器应由 PORT 驱动初始化
3) 影响不同硬件模块时钟设置的寄存器应由 MCU 驱动初始化
4) 影响寄存器集、RAM 或 EEPROM 映射的寄存器应在启动代码中初始化 |
| Dependencies | -- |
| Supporting Material | I/O register:任何可影响端口引脚功能的内容。 |
⌋(RS_BRF_01096)
###### 6.1.1.2.5 [SRS_SPAL_12462] 寄存器初始化设置应当发布
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 各驱动模块的实现者必须在驱动模块文档中发布所有寄存器初始化设置。 |
| Rationale | 配置者(负责配置软件的人员或工具)需要获取那些不直接由驱动初始化的寄存器设置。 |
| Use Case | -- |
| Dependencies | SRS_SPAL_12461 |
| Supporting Material | -- |
⌋()
###### 6.1.1.2.6 [SRS_SPAL_12463] 寄存器初始化设置应合并并转发
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 配置者应合并所有来自不同驱动的初始化设置,并对其进行一致性检查(依赖性与冲突)。检查通过后应将合并的设置转发给负责初始化硬件的模块。如有不一致,配置者应抛出错误,系统构建过程必须重新启动。 |
| Rationale | 确保所有控制器寄存器以一致方式使用,且所有驱动对寄存器初始化设置的需求均得到满足。 |
| Use Case | -- |
| Dependencies | [SRS_SPAL_12461], [SRS_SPAL_12462] |
| Supporting Material | -- |
⌋(RS_BRF_01096)
###### 6.1.1.2.7 [SRS_SPAL_12068] MCAL 各模块应按定义顺序初始化
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | MCAL 各模块应按如下顺序初始化:
1. 禁用全局中断
2. 初始化全局寄存器(MCAL 系统模块)
3. 初始化所有驱动
4. 可使能全局中断 |
| Rationale | 无副作用的明确初始化序列。 |
| Use Case | Power On Reset |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01096)
###### 6.1.1.2.8 [SRS_SPAL_12069] SPAL 中从唤醒中断恢复的所有驱动应报告唤醒原因
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | SPAL 中从唤醒中断恢复的所有驱动应通过 IO 硬件抽象层向 ECU State Manager 报告唤醒原因。
来自 SPAL 驱动的通知应在 IO 硬件抽象模块中处理,然后再将唤醒原因发送至 ECU 状态管理器。
实现提示:通常,该通知由唤醒中断的 ISR 完成。 |
| Rationale | ECU State Manager 需要唤醒原因。它可以保证低功耗。例如,对于 ICU,可以避免报告无效的唤醒原因(尖峰)。 |
| Use Case | 相关唤醒中断的 ISR 在唤醒发生时调用 ECU State Manager 的唤醒报告函数。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01104)
##### 6.1.1.3 正常操作
###### 6.1.1.3.1 [SRS_SPAL_00157] AUTOSAR 基础软件的所有驱动与处理程序应实现驱动和处理程序的通知机制
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | AUTOSAR 基础软件的所有驱动与处理程序应实现下列通知机制(每个模块可配置)以供基础软件内使用:
- 轮询(通过读取状态信息)
- 回调函数
- 默认错误跟踪器 DET 的错误报告函数
- 诊断事件管理器 DEM 的事件报告函数 |
| Rationale | 灵活集成;避免强耦合与依赖。 |
| Use Case | EEPROM 写命令的完成可通过回调函数或设置状态信息(可通过模块接口访问)进行信号传递。
EEPROM 写入过程中发生故障(单元损坏)可上报至诊断事件管理器 DEM。 |
| Dependencies | Mr. Schumpelt/Bosch 的评审注释 #35 |
| Supporting Material | -- |
⌋(RS_BRF_01064, RS_BRF_02232, RS_BRF_02168)
###### 6.1.1.3.2 [SRS_SPAL_12169] 提供不同操作模式的所有驱动模块应提供模式选择服务
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 提供不同操作模式的所有驱动模块应提供模式选择服务。该服务允许在无需去初始化与重新初始化的情况下,从一种操作模式切换到另一种操作模式。 |
| Rationale | 允许在不希望出现的副作用情况下进行操作模式切换。 |
| Use Case | 将 EEPROM 驱动从普通模式切换到突发模式 |
| Dependencies | [SRS_SPAL_12064] 运行操作期间的操作模式变更 |
| Supporting Material | -- |
⌋()
###### 6.1.1.3.3 [SRS_SPAL_12063] 所有驱动模块应仅支持原始值模式
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动模块应仅支持原始值模式。在该模式下,通过 API 服务传递的值将被直接使用,不进行进一步缩放。 |
| Rationale | 缩放和到物理值的转换是 ECU Abstraction Layer 的任务。原始值模式提供最高的性能。 |
| Use Case | I/O Hardware Abstraction 将原始 ADC 值转换为缩放后的值(例如电压),反之亦然。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
###### 6.1.1.3.4 [SRS_SPAL_12075] 具有随机流式能力的所有驱动应使用应用层缓冲区
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 具有随机流式能力的所有驱动(memory drivers)应使用应用层缓冲区。在驱动作业处理期间,调用者不得改变数据。 |
| Rationale | 最少的 RAM 消耗,运行时效率。 |
| Use Case | EEPROM 写服务获取一个指向源数据的指针。EEPROM 写操作期间,驱动从应用层缓冲区读取数据。EEPROM 驱动不提供自己的数据缓冲区。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
###### 6.1.1.3.5 [SRS_SPAL_12129] ISR 应负责复位中断标志并调用相应的通知函数
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | ISR 应负责复位中断标志并调用相应的通知函数。 |
| Rationale | 通知函数可以由用户定义,因此不允许直接访问硬件。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
##### 6.1.1.4 故障操作
###### 6.1.1.4.1 [SRS_SPAL_12064] 若操作模式变更导致正在运行的操作降级,所有驱动模块应报告错误
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 若操作模式的变更导致正在运行的操作降级,所有驱动模块应报告错误。正在运行的操作应被保留。
附加说明:此错误条件在正确的系统设计中不应发生。 |
| Rationale | -- |
| Use Case | SPI EEPROM 操作模式在正在运行的 SPI 通信序列中有效。 |
| Dependencies | [SRS_SPAL_12169] 操作模式控制 |
| Supporting Material | -- |
⌋(RS_BRF_02168, RS_BRF_01440)
###### 6.1.1.4.2 [SRS_SPAL_12448] 所有驱动模块在检测到开发错误后应具有特定行为
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 在检测到开发错误时,所有驱动模块应:
- 将错误报告至默认错误跟踪器 DET
- 跳过所要求的功能(在不执行任何动作的情况下离开服务)
- 标准返回值的情况下返回 E_NOT_OK
- 在返回任意值的情况下(例如 Dio_ReadPort)返回 0 |
| Rationale | 所有 SPAL 模块行为统一。避免处理错误的 API 参数,从而避免硬件损坏或危险的系统行为。 |
| Use Case | 已为驱动启用开发错误检测。驱动服务被调用且输入参数值有误。该服务不应处理该命令(否则可能导致严重故障)。 |
| Dependencies | [SRS_SPAL_00157] 驱动与处理程序的通知机制 |
| Supporting Material | -- |
⌋(RS_BRF_02232)
##### 6.1.1.5 关机操作
###### 6.1.1.5.1 [SRS_SPAL_12067] 所有驱动模块应根据所选操作模式设置其唤醒条件
⌈
| 项 | 值 |
| --- | --- |
| Type | valid |
| Description | 所有驱动模块应根据所选操作模式设置其唤醒条件。 |
| Rationale | 允许使能模块特定的唤醒中断。 |
| Use Case | 例子:
ECU 状态管理器将 ECU 电源模式切换为 'ECU_POWERMODE_SLEEP'。
模块 'GPT' 和 'ICU' 根据其相对于 'ECU_POWERMODE_SLEEP' 的配置使能特定唤醒中断。 |
| Dependencies | [SRS_SPAL_12169] 操作模式控制 |
| Supporting Material | -- |
⌋(RS_BRF_01104)
### 6.2 非功能性需求
#### 6.2.1 时序需求
##### 6.2.1.1 [SRS_SPAL_12077] 所有驱动应提供非阻塞实现
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 所有驱动应提供非阻塞实现。
注:本需求中的"阻塞实现"是指"无感、不协作地占用处理器时间",例如长时间循环。 |
| Rationale | 避免未确定的等待时间。允许在协作式调度系统中使用所有驱动。 |
| Use Case | 用于"ADC 转换就绪标志"的等待循环应具有附加的超时条件。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
##### 6.2.1.2 [SRS_SPAL_12078] 驱动应以内存和运行时资源最有效的方式编码
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 驱动应以内存和运行时资源最有效的方式编码。 |
| Rationale | 避免资源浪费。 |
| Use Case | 在嵌入式汽车系统中使用驱动。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
#### 6.2.2 软件设计需求
##### 6.2.2.1 [SRS_SPAL_12092] 驱动的 API 应由其处理程序或管理器访问
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 如果一个驱动由处理程序或管理器控制,则不允许绕过该处理程序/管理器直接访问驱动的 API。如果驱动上方没有处理程序/管理器,则可直接访问。 |
| Rationale | 一致的访问。Handlers 和 Managers 不应被绕过。 |
| Use Case | EEPROM 驱动通过 EEPROM Abstraction 模块和 Memory Abstraction Interface 由 NVRAM Manager 独占控制。不允许其他形式访问 EEPROM 驱动的 API。 |
| Dependencies | -- |
| Supporting Material | -- |
⌋()
##### 6.2.2.2 [SRS_SPAL_12265] 配置数据应保持常量
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | 通过初始化函数传递给模块的初始化结构体的内容,应在运行时保持常量并可用。
说明:通常,这个初始化数据结构位于 ROM 中。 |
| Rationale | 模块可以随时访问该结构。 |
| Use Case | -- |
| Dependencies | -- |
| Supporting Material | -- |
⌋(RS_BRF_01152)
#### 6.2.3 流程需求
##### 6.2.3.1 [SRS_SPAL_12264] 应提供配置项规范
⌈
| 项 | 值 |
| --- | --- |
| Type | Valid |
| Description | SWS(软件规范)应针对每个配置元素指定:
- 它是在编译前还是编译后可配置
- 该配置项位于何处(初始化数据结构,配置头文件 *_Cfg.h) |
| Rationale | 启用允许目标代码交付的配置参数的正确实现。 |
| Use Case | -- |
| Dependencies | [SRS_SPAL_12263] 编译后配置 |
| Supporting Material | -- |
⌋()
---
## 7 参考文献
### 7.1 AUTOSAR 交付物
[1] Glossary
AUTOSAR_TR_Glossary.pdf
[2] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of ECU State Manager
AUTOSAR_SWS_ECUStateManager.pdf
[5] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf
### 7.2 相关标准与规范
无。
---
## 翻译说明
- 本文档由 AUTOSAR CP 4.4.0 英文原文翻译。
- 模块缩写(MCAL、SPAL、ECU、DIO、PORT、ADC、PWM、ICU、OCU、SPI、MCU、GPT 等)保留原文。
- API 标识符、需求 ID(SRS_SPAL_xxxxx、RS_BRF_xxxxx)保留原文。
- AUTOSAR 方括号符 `⌈ ⌋` 保留原貌,以保持需求结构的可追溯性。
- 版权声明保持英文原文。
- 跨文档引用以英文文件名形式保留。