功能安全是一个在项目开始阶段就要引入的话题，它对于整个系统的设计都会有影响，如今AUTOSAR已经运用到了绝大多数汽车ECU当中，AUTOSAR的标准规范里同样有功能安全相关的说明。AUTOSAR本身并不提供完整的安全解决方案，项目本身仍需要遵从ISO26262的规定来达到期望的安全等级设计，但AUTOSAR提供功能安全措施与机制，来支持实现系统所必要的功能安全。本文福利：分享报告《新能源换电研究框架报告》，公众号对话框回复【汽车ECU开发007】下载。01.
简介
AUTOSAR提供一个Use Case文档，以示例的方式来帮助开发人员了解如何运用AUTOSAR实现相关的功能安全功能。本示例基于车辆前大灯管理的功能，集中介绍在ISO26262定义的框架内，和AUTOSAR部分相关的功能安全内容，本文可以作为AUTOSAR方法论中安全相关分析的基本指导，但仍有很多诸如软件安全需求或安全分析测量的示例等细节无法覆盖到，需要开发人员在后续设计开发步骤中完成。02.
系统架构
整体架构如上图，我们的功能核心是车前灯管理，ECU还会和车灯开关，点火钥匙，HMI，车灯等仪器或执行机进行交互，在车前灯管理ECU当中，我们选取近光功能来进行讲解。其他诸如雾灯，示宽灯等等功能都不在本文讨论范围之内。由于和功能安全相关，作为降级（后备）功能的日间行车灯也会被加入到本文当中，当然，日间行车灯的具体控制功能本文不会进行涉及。03.
功能介绍
近光功能，主要是在夜间照亮车前部分路面，也可以告诉参与路面交通的其他人有车靠近，近光功能的开启/关闭条件如下：
车钥匙激活CL15的情况下，打开车灯开关，车灯近光灯被打开- 只有当车灯开关位置从OFF置为ON时，车前灯管理模块才应当创建一个事件（ON）
- 当车灯开关位置从ON置为OFF时，车前灯管理模块应当创建一个事件（OFF）
- 车前灯管理模块应当在点火开关位置为ON时，检测到车灯开关事件ON的情况下，点亮近光灯
- 车前灯管理模块应当在点火开关位置为OFF，或者检测到车灯开关事件OFF时，关闭近光灯
- 车前灯管理模块应当能够在电流错误或者灯泡失效等的情况下提示近光灯发生错误
- 车前灯管理模块应当在近光灯发生错误时，点亮日间行车灯
04.
初步架构
中间的uc即为车前灯管理模块，为了方便，后文将用缩写进行说明：- 车灯开关提供一个数字I/O输出（实际的车辆中会更复杂，这里作简化）
- 所有内存，无论是否非易失性，都有ECC提供保护机制
- ECU失效模式的分析已完成，安全衡量方式也已被定义并实现，分析基于供应商的数据，例如功能安全手册和ISO2626需求
为了集中在AUTOSAR软件功能安全部分，我们还需要做以下约束：- ECU处在唤醒状态，也可以正确执行并进入睡眠状态。模式管理，状态管理等均不在本示例讨论范围内。
- 网络通信可用，并且正确启动并运行。通信管理也不再本示例讨论范围之内。
线束，电池或供电系统的鼓掌均不考虑。我们假定整车级的解决方案会考虑这些故障失效。车灯开关功能正常，且已按照功能安全需求开发并实现。整车级功能安全
我们假定，在做完危害和风险评估之后，得到了以下结果：此危害可能会导致驾驶员失去对车辆的控制，偏离道路并发生碰撞。- 只有在能见度低的条件下（例如夜间，大雾等），近光灯工作才被视作为风险
- 在弯曲，无路灯的乡村道路上发生近光灯不工作时，视作为最危险的情况
- 仅一侧近光灯不工作不会被视为能直接导致危险的情况，然而，它仍被当作潜在故障，包含在概念建议当中
ASIL：基于危害分析和风险评估中识别出的严重等级，发生概率和可控性，认定位ASIL B等级Safety Goal SG01: 防止近光灯完全失效故障容忍时间(Fault Tolerance Time): 500ms当然，还可以识别出很多其他的危害，但为了示例的简洁明了，本文不涉及其他情况。相关的故障模式
05.
功能安全概念
功能介绍，功能安全目标，以及功能安全需求的分析结构，即功能安全架构，会映射到一个具体的车辆架构上。FunSafReq01-01: FLM应当能正确检测任何合法的近光灯开启条件。（如果有一个合法的打开车灯请求，但没有开启近光，则对应MF01）
FunSafReq01-02: FLM应当验证任何收到的近光开启请求的有效性，并相应地开启或关闭车灯。（如果没有收到合法的关闭近光的请求，但是关闭了灯光，则对应MF02）FunSafReq01-03: FLM应当检测近光是否故障并以指示灯反馈给驾驶员。（如果灯光失效/故障，则对应MF03）车辆级安全需求
作为车辆级安全分析的一部分，根据系统架构，还定义了警告和降级概念。对于本文关注的近光功能，我们定义了如下两步降级概念：降级模式Step 1 —— 一侧近光失效：另一侧近光仍然正常工作；应当给驾驶员以提示，告诉驾驶员虽然有开启灯光请求，但一侧并未成功降级模式Step 2 —— 双侧近光失效：开启灯光但并不成功时，应当开启日间行车灯；应当给驾驶员以提示，告诉驾驶员虽然有开启灯光请求，但双侧都未成功，且已打开日间行车灯（整车级）技术安全需求
基于上述介绍过的FunSafReq，我们可以得到下列技术安全需求：- SysSafReq01: 车身控制ECU使用CAN总线将点火钥匙CL15状态通过CAN消息CL15_01发送（CAN消息：CL15_01，CAN信号：CL15ON，布尔值，1代表CL15为ON状态）（ASIL B）
- 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级的假设和限制
- 周期读取硬件信号，可以通过C/S方式从IO硬件抽象模块的RAM中读取
- ECU正确地唤醒，运行和睡眠（本文不考虑模式管理或状态管理）
- RTE作为中间层进行数据和消息的传输，但不做任何Transformation
- 日间行车灯和车前灯有同样的连接方式，只是使用的SPI通道不同
Safety Goal
相关的系统安全需求
06.
ECU级概念概述
如上图，“车前灯”功能（ASIL B）被拆分为两个独立的头灯（2 x ASILA(B)），提供冗余。
之前的假设是，set_pwm的丢失并不会直接导致近光灯失效，因此控制车灯的普通SPI总线是QM等级。Set_pwm用来生成矩形波，调制宽度用来通过Smart high side driver控制车前灯。- 回读通道read_current_R和read_current_L 提供反馈，灯光请求是否成功传递
- 如果回读通道指示和请求不同，需要执行相应的安全动作，独立于set_pwm命令。（例如，车灯开关ON时，应当打开日间行车灯）
- 再者，车灯激活通道控制车灯的开启与关闭，反馈通道（ASIL B）会在任何危险（夜间）情况前通知成功状态。单一set_pwm鼓掌只会影响一侧车前灯。
ECU级的需求
下方列表展示了ECU级别的安全需求。基于软件需求，BSW模块的需求也被推演出来。这里只做示例，方便理解，实际项目需要按照指定需求的最高ASIL等级进行开发。
ECU功能
- 相关软件模块：DIO Driver/Handler, RTE, SwitchEvent(Sensor-SWC)
- 相关软件模块: CAN, CanIf, PduR, COM, RTE, Light Request(Application SWC)
- 物理输出: : PWM_headlight left, PWM_headlight right (QM)
- 相关软件模块: 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, CanIf, PduR, COM, RTE, FLM(Application SWC)
控制车灯的逻辑部分全部由软件包含，逻辑出入量在上面的功能中已经提及。- 相关软件模块: Switch-Event(Sensor-SWC)，LightRequest(Application SWC)，FLM(Application-SWC), Headlight(Actuator-SWC)，RTE
软件架构和软件安全需求
首先，我们会分析此软件系统的大体架构，包括相关的软件模块和BSW模块。在分析过程当中，我们会介绍接口和数据流这样的静态信息，以及处理流程，时间行为等的动态信息。其次，我们还会一起来分析并识别出ECU级别总结的安全需求所相关的潜在故障模式，如何使用功能安全方法检测出这些潜在故障，同时也会提供AUTOSAR中的实现方式。
软件架构
FLM集成在了一个现有的AUTOSAR工程当中，主要包含四个SWC：
- Application SWC(LightRequest)
SwitchEvent在收到LightRequest请求时被触发调用，读取车灯开关状态。
LightRequest会检查车灯开关状态，也会读取CL15_01 CAN信号（点火钥匙位置信息），在需要时将车灯请求发送给FLM。FLM会监控灯泡状态（包或是否可用状态），周期获取车灯请求数据，如果车灯故障时发送信号给HMI，当需要开启/关闭车灯时发送请求给Headlight模块。如果近光灯失效时发送日间行车灯请求给HeadLight。DEM功能也在FLM中处理。HeadLight提供当前车灯状态，收到请求时提供车灯是否可用的状态。它是直接控制车前灯的模块。当FLM已经请求车灯的情况下周期读取回读通道的数据。同时，它还要保证电压，PWM等以使车灯正常工作。- DIO and Port Driver /Handler
BSW的功能这里不再详细说明，如有需要请参考其他文章或者规范原文，以了解AUTOSAR各底层模块能够提供的功能。失效模式
- 随机硬件故障，在整个生命周期当中可能以不同概率随机出现
- 系统故障，会以特定的原因导致特定故障，需要在生产过程，操作流程，文档或其他方式，亦或是更改设计的方式消除故障
硬件故障模式不属于软件安全分析的一部分，这里不再提及。软件故障模式，主要分为“数据完整性，初始化和配置数据”，“数据交换”，“时间和控制流”和“数据处理”。数据完整性
数据完整性代表所有和内存损坏或初始化和配置数据有关的故障模式。内存数据损坏，也即某一特定内存地址上的软件数据发生损坏，包括寄存器，全局或静态变量，程序代码等。初始化和配置数据，也即对应的配置数据并不适用于或错误适配于当前的项目中（的外设等）。数据交换
数据交换包括所有收发双方进行数据传输时发生的故障模式。时间和控制流
时间和控制流代表所有和执行时间以及执行顺序有关的故障模式。数据处理
数据处理代表所有和逻辑软件错误（例如算法的错误实现，数据过滤等）的故障模式。软件以及潜在故障模式
到此为止，我们可以基于上述信息进行故障模式以及功能需求进行匹配，在项目当中可以列出这样的表格：
由于原文示例有非常详细（也就是很多文字）说明了这个列表，这里只将这个作为例子，图中的故障模式为：COM， RTE以及很多其他模块都有权限过滤，转换，修改某些数据，这会很容易导致内存故障。为此，我们主要从三个方面考虑可能的安全方案：ECC，MPU/MMU，E2E。防止硬件随机错误，防止非预期的修改，以及保证数据传输过程的正确性/完整性。07.
后记
日常的工作当中也经常会收到很多安全功能相关的问题，主要是关于AUTOSAR中和功能安全相关模块的功能，以及对应的配置，还有怎么实现/达到功能安全等级，由于笔者工作主要是AUTOSAR基础软件相关，所以还是想强调的是，系统的功能安全，一定要从一开始就加入到项目的考量中去，进行功能分解，设计等等。AUTOSAR最多只能作为一个必要条件，以提供功能安全相关模块，辅以功能安全手册的方式帮助项目达到设计要求，但它不是一个充分条件，不可能是因为用了AUTOSAR，所以你的产品/项目就是功能安全的。
就V字模型来说，可以很明显的看出来，OEM和Tier1确实需要花很多功夫去做功能安全分析以及功能分解等待，最后在过安全认证的时候也要掉很多头发（手动狗头）。
就目前情况来说，考虑到上述的故障模式，做项目的时候，在AUTOSAR基础软件这一块儿，主要从E2E，SafetyOS（应用分区，内存保护等）,Safety Watchdog，SafetyRTE的方面，来实现项目的整体功能安全。当然，SWC的开发同样需要遵守ISO26262以提供Safety API。
阅读原文，关注作者知乎
关于对汽车ECU软件测试的理解
特斯拉最新中央计算模块(CCM)解析
2021款特斯拉Model Y ECU接口梳理
详解CANoe之CAPL编程
关于CAN时间同步的理解
dbc文件的格式以及创建详解
大众ID.4 X网络架构详解
基于UDS的Bootloder详解
关于整车上下电流程的理解
一文详解CAN总线错误帧|附下载
DoIP协议介绍，资料分享！
详解车载网络 OTA系统的开发|文末附下载
一文了解汽车嵌入式AUTOSAR架构|附下载
特斯拉Autopilot系统安全研究|附dbc下载
