基于功能安全的示例AUTOSAR软件系统

功能安全是一个在项目开始阶段就要引入的话题，它对于整个系统的设计都会有影响，如今AUTOSAR已经运用到了绝大多数汽车ECU当中，AUTOSAR的标准规范里同样有功能安全相关的说明。

AUTOSAR本身并不提供完整的安全解决方案，项目本身仍需要遵从ISO26262的规定来达到期望的安全等级设计，但AUTOSAR提供功能安全措施与机制，来支持实现系统所必要的功能安全。

01.简介

AUTOSAR提供一个Use Case文档，以示例的方式来帮助开发人员了解如何运用AUTOSAR实现相关的功能安全功能。

本示例将包含以下话题：

功能安全概念

系统层面的技术要点

ECU层面的技术要点

AUTOSAR基础软件层面的功能安全

02.系统架构

大体架构

03.功能介绍

近光功能，主要是在夜间照亮车前部分路面，也可以告诉参与路面交通的其他人有车靠近，近光功能的开启/关闭条件如下：

车钥匙激活CL15的情况下，打开车灯开关，车灯近光灯被打开

主要功能如下：

检测近光灯请求

车前灯管理模块应当判断点火钥匙位置

车前灯管理模块应当读取车灯开关位置状态

判断近光请求

车前灯管理模块应当判断车灯开关位置状态

只有当车灯开关位置从OFF置为ON时，车前灯管理模块才应当创建一个事件（ON）

当车灯开关位置从ON置为OFF时，车前灯管理模块应当创建一个事件（OFF）

控制近光灯

车前灯管理模块应当在点火开关位置为ON时，检测到车灯开关事件ON的情况下，点亮近光灯

车前灯管理模块应当在点火开关位置为OFF，或者检测到车灯开关事件OFF时，关闭近光灯

监控近光灯功能

车前灯管理模块应当监管近光灯

车前灯管理模块应当能够在电流错误或者灯泡失效等的情况下提示近光灯发生错误

点亮日间行车灯

车前灯管理模块应当在近光灯发生错误时，点亮日间行车灯

04.初步架构

为此，我们有了一个初步的架构方案：

中间的uc即为车前灯管理模块，为了方便，后文将用缩写进行说明：

车前灯管理模块—FLM

车灯开关（位置）—LS

点火开关（位置）—CL15

它们和FLM ECU的交互接口如下：

如果以通信的角度看，整体架构如下：

示例功能安全需求分析的假设以及限制

作为出发点，我们假定系统：

1. FLM的实现都在一个ECU上

2. 车灯开关提供一个数字I/O输出（实际的车辆中会更复杂，这里作简化）

3. 应急灯功能由硬件提供，这里不做考虑

4. 所有内存，无论是否非易失性，都有ECC提供保护机制

5. 硬件提供内存分区功能（例如MPU）

6. FLM软件集成在没有ASIL等级的基础软件上

7. ECU失效模式的分析已完成，安全衡量方式也已被定义并实现，分析基于供应商的数据，例如功能安全手册和ISO2626需求

为了集中在AUTOSAR软件功能安全部分，我们还需要做以下约束：

假定ECU按照要求工作：

ECU处在唤醒状态，也可以正确执行并进入睡眠状态。模式管理，状态管理等均不在本示例讨论范围内。

络通信可用，并且正确启动并运行。通信管理也不再本示例讨论范围之内。

必要的BSW模块也根据需求正确执行/触发

线束，电池或供电系统的鼓掌均不考虑。我们假定整车级的解决方案会考虑这些故障失效。

近光灯供电系统故障不被考虑。

车灯开关功能正常，且已按照功能安全需求开发并实现。

整车级功能安全

我们假定，在做完危害和风险评估之后，得到了以下结果：

危害H1: 近光灯完全不工作（ASIL B）

此危害可能会导致驾驶员失去对车辆的控制，偏离道路并发生碰撞。

H1的例外和边界条件：

只有在能见度低的条件下（例如夜间，大雾等），近光灯工作才被视作为风险

在弯曲，无路灯的乡村道路上发生近光灯不工作时，视作为最危险的情况

仅一侧近光灯不工作不会被视为能直接导致危险的情况，然而，它仍被当作潜在故障，包含在概念建议当中

ASIL：基于危害分析和风险评估中识别出的严重等级，发生概率和可控性，认定位ASIL B等级

Safety Goal SG01: 防止近光灯完全失效

Safe State: 近光灯工作

故障容忍时间(Fault Tolerance Time): 500ms

相关的故障模式

以下错误行为都可能违反SG01的要求：

MF01: 无法检测灯光开启/关闭的条件

MF02: 无法评估和实现用来开启车灯的请求

MF03: 已点亮车灯的故障

05.功能安全概念

功能介绍，功能安全目标，以及功能安全需求的分析结构，即功能安全架构，会映射到一个具体的车辆架构上。

FunSafReq01-01: FLM应当能正确检测任何合法的近光灯开启条件。（如果有一个合法的打开车灯请求，但没有开启近光，则对应MF01）

FunSafReq01-02: FLM应当验证任何收到的近光开启请求的有效性，并相应地开启或关闭车灯。（如果没有收到合法的关闭近光的请求，但是关闭了灯光，则对应MF02）

FunSafReq01-03: FLM应当检测近光是否故障并以指示灯反馈给驾驶员。（如果灯光失效/故障，则对应MF03）

车辆级安全需求

作为车辆级安全分析的一部分，根据系统架构，还定义了警告和降级概念。

普通模式：参考上文已描述的相关功能

降级模式Step 1—— 一侧近光失效：另一侧近光仍然正常工作；应当给驾驶员以提示，告诉驾驶员虽然有开启灯光请求，但一侧并未成功

降级模式Step 2—— 双侧近光失效：开启灯光但并不成功时，应当开启日间行车灯；应当给驾驶员以提示，告诉驾驶员虽然有开启灯光请求，但双侧都未成功，且已打开日间行车灯

（整车级）技术安全需求

基于上述介绍过的FunSafReq，我们可以得到下列技术安全需求：

SysSafReq02: 车灯开关利用数字硬件总线HW_LB_OFF发送开关状态信 （0=0V代表开启请求，1=5V代表关闭请求）（ASIL B）

SysSafReq03: 车灯开关故障时，HW_LB_OFF为0（ASIL B）

SysSafReq04: FLM ECU检测到点亮灯泡的条件满足时，应当保证电压或PWM等达到稳定条件并点亮近光灯灯泡（ASIL B）

SysSafReq05: 当CL15ON==1时，FLM ECU只有在HW_LB_OFF==1并保持20ms的情况下才会关闭车灯（ASIL B）

SysSafReq06: FLM ECU应当检测电路故障（灯泡，保险丝，线束等），并使用CAN信 （CAN消息: LightStatus_01, CAN信 : LBFailure (2 bit, 01 代表左近光失效, 10 代表右近光失效, 11 代表双侧失效)）（ASIL B）

SysSafReq07: FLM ECU应当在双侧近光失效状态超过200ms的情况下打开双侧日间行车灯（ASIL B）

SysSafReq08: FLM ECU应当使用独立电路来点亮双侧灯泡，以免单一故障就使得双侧失效（ASIL B）

SysSafReq09: HMI应当根据LBFailure信 显示灯泡故障信息（ASIL A）

SysSafReq10: CAN信 CL15ON传输需要得到保证（ASIL B）

SysSafReq11: CAN信 LBFailure传输需要得到保证（ASIL B）

SysSafReq12: FLM ECU应当在CL15_01消息通信故障连续发生200ms时点亮近光灯

SysSafReq13: FLM ECU应当在LightStatus_01消息通信故障连续发生200ms时打开双侧日间行车灯；还要为驾驶员提供例如“车灯系统故障”的文本信息

分配（功能）系统安全需求

下一步，我们需要将所有系统安全需求分配到架构中的系统元素当中。

映射关系如下：

FLM ECU级的技术安全概念

本节内容主要介绍ECU级别的安全分析，一般由供应商总结。

ECU级的假设和限制

FLM ECU级的安全概念基于下列假设：

根据AUTOSAR方法论，BSW周期执行

周期读取硬件信 ，可以通过C/S方式从IO硬件抽象模块的RAM中读取

收到CAN消息时会产生中断

通信 络可用，以正确方式启动并运行

BSW根据需求被触发

RTE作为中间层进行数据和消息的传输，但不做任何Transformation

日间行车灯和车前灯有同样的连接方式，只是使用的SPI通道不同

Safety Goal

前文已说明

相关的系统安全需求

上一章已说明

06.ECU级概念概述

如上图，“车前灯”功能（ASIL B）被拆分为两个独立的头灯（2 x ASILA(B)），提供冗余。

之前的假设是，set_pwm的丢失并不会直接导致近光灯失效，因此控制车灯的普通SPI总线是QM等级。

Set_pwm用来生成矩形波，调制宽度用来通过Smart high side driver控制车前灯。

理由：

1. 启动时自我诊断会检测SPI连接鼓掌并反馈给驱动

2. 回读通道read_current_R和read_current_L 提供反馈，灯光请求是否成功传递

3. 如果回读通道指示和请求不同，需要执行相应的安全动作，独立于set_pwm命令。（例如，车灯开关ON时，应当打开日间行车灯）

4. 所以，SPI通道可以以QM等级实现

5. 再者，车灯激活通道控制车灯的开启与关闭，反馈通道（ASIL B）会在任何危险（夜间）情况前通知成功状态。单一set_pwm鼓掌只会影响一侧车前灯。

ECU级的需求

下方列表展示了ECU级别的安全需求。基于软件需求，BSW模块的需求也被推演出来。这里只做示例，方便理解，实际项目需要按照指定需求的最高ASIL等级进行开发。

ECU功能

读取车灯开关状态

物理输入：HW_LB_OFF

逻辑输入：LB_OFF

相关软件模块：DIO Driver/Handler, RTE, SwitchEvent(Sensor-SWC)

读取点火钥匙状态（通过车身控制器）

物理输入: CAN BUS CAN_CL15

逻辑输入: CL15_01 (ASIL B)

相关软件模块: CAN, CanIf, PduR, COM, RTE, Light Request(Application SWC)

点亮车灯（物理）

近光灯

物理输出: : PWM_headlight left, PWM_headlight right (QM)

逻辑输出: Set_pwm

相关软件模块: HeadLight(Actuator-SWC控制通道), RTE, SPI Driver/Handler

日间行车灯

物理输出: 日间行车灯

逻辑输出: （不在本示例讨论范围之内）

相关软件模块: （不在本示例讨论范围之内）

监控灯

物理输入: HW_current left, HW_current right (ASIL A(B))

逻辑输入: Read_current_L, read_current_R

相关软件模块: HeadLight (Actuator-SWC 回读通道), RTE, ADC Driver/Handler

驾驶员提示信息

物理输出: CAN总线(ASIL A)

逻辑输出: LBFailure

相关软件模块: CAN, CanIf, PduR, COM, RTE, FLM(Application SWC)

控制车灯（逻辑）

控制车灯的逻辑部分全部由软件包含，逻辑出入量在上面的功能中已经提及。

物理输入: 无

物理输出: 无

相关软件模块: Switch-Event(Sensor-SWC)，LightRequest(Application SWC)，FLM(Application-SWC), Headlight(Actuator-SWC)，RTE

软件架构和软件安全需求

本节将主要介绍两部分内容：

首先，我们会分析此软件系统的大体架构，包括相关的软件模块和BSW模块。在分析过程当中，我们会介绍接口和数据流这样的静态信息，以及处理流程，时间行为等的动态信息。

其次，我们还会一起来分析并识别出ECU级别总结的安全需求所相关的潜在故障模式，如何使用功能安全方法检测出这些潜在故障，同时也会提供AUTOSAR中的实现方式。

软件架构级的框图

软件架构

SWC与AUTOSAR BSW模块

FLM集成在了一个现有的AUTOSAR工程当中，主要包含四个SWC：

Sensor SWC(SwitchEvent)

Application SWC(LightRequest)

Application SWC(FLM)

Actuator SWC(Headlight)

数据通信图

SwitchEvent在收到LightRequest请求时被触发调用，读取车灯开关状态。

LightRequest会检查车灯开关状态，也会读取CL15_01 CAN信 （点火钥匙位置信息），在需要时将车灯请求发送给FLM。

FLM会监控灯泡状态（包或是否可用状态），周期获取车灯请求数据，如果车灯故障时发送信 给HMI，当需要开启/关闭车灯时发送请求给Headlight模块。如果近光灯失效时发送日间行车灯请求给HeadLight。DEM功能也在FLM中处理。

HeadLight提供当前车灯状态，收到请求时提供车灯是否可用的状态。它是直接控制车前灯的模块。当FLM已经请求车灯的情况下周期读取回读通道的数据。同时，它还要保证电压，PWM等以使车灯正常工作。

对于RTE，也即生成SWC和BSW之间的接口。

使用到的BSW模块如下图所示：

COM Manager

AUTOSAR COM

CAN State Manager

PDU Router

CAN Interface

CAN Driver

CAN Transceiver Driver

SPI Driver /Handler

DIO and Port Driver /Handler

ADC-Driver /Handler

ECU State Manager

BSW Manager

AUTOSAR OS

BSW的功能这里不再详细说明，如有需要请参考其他文章或者规范原文，以了解AUTOSAR各底层模块能够提供的功能。

失效模式

ISO26262区分两种不同的故障原因：

1. 随机硬件故障，在整个生命周期当中可能以不同概率随机出现

2. 系统故障，会以特定的原因导致特定故障，需要在生产过程，操作流程，文档或其他方式，亦或是更改设计的方式消除故障

硬件故障模式不属于软件安全分析的一部分，这里不再提及。

软件故障模式，主要分为“ 数据完整性，初始化和配置数据”，“ 数据交换”，“ 时间和控制流”和“ 数据处理”。

数据完整性

数据完整性代表所有和内存损坏或初始化和配置数据有关的故障模式。

内存数据损坏，也即某一特定内存地址上的软件数据发生损坏，包括寄存器，全局或静态变量，程序代码等。

初始化和配置数据，也即对应的配置数据并不适用于或错误适配于当前的项目中（的外设等）。

数据交换

数据交换包括所有收发双方进行数据传输时发生的故障模式。

时间和控制流

时间和控制流代表所有和执行时间以及执行顺序有关的故障模式。

数据处理

数据处理代表所有和逻辑软件错误（例如算法的错误实现，数据过滤等）的故障模式。

软件以及潜在故障模式

到此为止，我们可以基于上述信息进行故障模式以及功能需求进行匹配，在项目当中可以列出这样的表格：

由于原文示例有非常详细（也就是很多文字）说明了这个列表，这里只将这个作为例子，图中的故障模式为：COM， RTE以及很多其他模块都有权限过滤，转换，修改某些数据，这会很容易导致内存故障。

为此，我们主要从三个方面考虑可能的安全方案：ECC，MPU/MMU，E2E。防止硬件随机错误，防止非预期的修改，以及保证数据传输过程的正确性/完整性。

07.后记

日常的工作当中也经常会收到很多安全功能相关的问题，主要是关于AUTOSAR中和功能安全相关模块的功能，以及对应的配置，还有怎么实现/达到功能安全等级，由于笔者工作主要是AUTOSAR基础软件相关，所以还是想强调的是，系统的功能安全，一定要从一开始就加入到项目的考量中去，进行功能分解，设计等等。AUTOSAR最多只能作为一个必要条件，以提供功能安全相关模块，辅以功能安全手册的方式帮助项目达到设计要求，但它不是一个充分条件，不可能是因为用了AUTOSAR，所以你的产品/项目就是功能安全的。

借用一张EB产品介绍中的一页PPT

就V字模型来说，可以很明显的看出来，OEM和Tier1确实需要花很多功夫去做功能安全分析以及功能分解等待，最后在过安全认证的时候也要掉很多头发（手动狗头）。

就目前情况来说，考虑到上述的故障模式，做项目的时候，在AUTOSAR基础软件这一块儿，主要从E2E，SafetyOS（应用分区，内存保护等）,Safety Watchdog，SafetyRTE的方面，来实现项目的整体功能安全。 当然，SWC的开发同样需要遵守ISO26262以提供Safety API。