功能安全的学习笔记（二）

mqh0386

前言

最近我家宝宝生病，忙碌了两周多，心力交瘁，终于有空更新文章了。

对于功能安全（FUSA），我一直停留在只知方法不知方法论的层级，说来惭愧，一直在吃联电积累下来的FUSA老本，当然也和自己没有系统的做过FUSA有关。最近为了研究FUSA，狠下心读了几百页文档，本文仅仅是一些读后感。如有错误，请指正。

故障分类原则

我们常说单点失效，多点失效，潜伏失效。那么怎么去识别一个失效属于哪种情况。如何去计算失效率和诊断覆盖率？

故障分类，按故障层级分类如下：

Safe Fault层级: Safe Fault


Single Point Fault层级：Single Point Fault和Residual Fault

Multiple Point Fault层级：Detected Multiple Point Fault,Perceived Multiple Point Fault,Latent Multiple Point Fault

按照故障分类准则，各类故障分类如下：

Non-Safety Related: Safety Fault

违反Safety Goal且无Safety Mechanism:Single Point Fault

违反Safety Goal且有Safety Mechanism但不能被阻止的:Residual Fault

其余属于Multiple Point Fault

能被检测的Multiple Point Fault：Detected Multiple Point Fault

不能被检测但是能被察觉的Multiple Point Fault: Perceived Multiple Point Fault

其余的Multiple Point Fault情况：Latent Fault（多点故障）

失效率计算如下：

失效率 = 单点故障率+残余故障率+多点故障率+safe fault故障率

单点失效的诊断覆盖率计算如下：

单点失效的诊断覆盖率 = 1 -  （单点失效率+残余失效率）/（失效率 – safe fault失效率）

潜伏多点诊断覆盖率计算如下：

潜伏多点诊断覆盖率 =  1 – 多点潜伏失效率 / （失效率 – safe fault 失效率 – 单点故障失效率 –  残余故障失效率）

软件FEMA方法论

软件结构图

Class diagram类图：类、接口以及静态结构关系。

Object diagram对象图：一组实例及其之间的关系。

Package diagram包图：类、接口等模型元素的组织结构和层级关系。

Composite Structure diagram复合结构图：结构的内部组成以及组成之间的关系。

Component diagram组件图：描述组件和组件之间的关系。

Deployment diagram部署图：硬件的物理架构以及软件在硬件上的部署方式。

Profile diagram概型图：定义和展示UML的扩展机制

软件行为图

Use Case diagram用例图:描述系统、参与者以及他们之间的交互，注重系统的功能需求。

Activity diagram活动图:展示工作流程和动作流。类似于流程图。

State Machine diagram状态机图:不同生命周期状态下的事件或行为。

Interaction diagram交互图有如下三类：

Sequence diagram序列图:按照时间顺序展示对象之间的消息传递。

Communication diagram通信图:类似于序列图，非严格时间顺序。

Timing diagram时序图:对象之间的时间交互关系。

Interaction Overview diagram交互概览图:概括系统的主要交互流程。

软件失效定义

功能丢失

功能降级

功能随机启停

部分功能存在（性能丢失）

非预期的功能（错误时间点执行、非预期的方向、不相等的性能）

功能超限

功能延迟

软件安全机制

软件架构错误检测考虑因素

输入输出数据的范围检查


合理性检查

数据错误检测（内存保护）

外部设施监控

控制流监控（心跳包、程序流监控、Deadline检查）

软件差异化设计

软件部署

架构层级错误处理机制

静态恢复机制

适度降级

独立并行冗余

数据纠正码

软件FEMA失效分析

软件FEMA只对Severity和Detection做检测，不对Occurrence做分析。需要对ECU层级-组件层级-模块层级进行FEMA分析，最终形成FTA（故障树分析）。

故障树分析最主要的操作就是：处理好顶层事件、中间事件、底事件三者之间的关联。找到导致顶层事件发生的最小底层事件的集合。

在整个软件FEMA分析过程中，明确需求，明确造成的影响。在架构设计阶段，应做好架构级别的安全分析。在单元级别的设计阶段，应做好单元层级的安全分析。

在软件FEMA分析过程中，需要考虑对象的静态特性和动态特性，颗粒度和架构中的最小元保持一致，分析架构元素和需求、架构元素功能、接口、数据流。失效因素需要考虑硬件平台影响（硬件环境因素）、架构影响（内部环境影响）、无动态对象、变量影响（初始化、多用、限制指针的使用、隐性数据类型转换）、人为错误、没有无条件跳转、无递归等等，主要考虑系统性失效（分析单元设计内部设计、内部逻辑、判定条件、变量类型赋值、输入输出接口等）。

软件FEMA分析的内容标题

软件模块的功能逻辑（功能描述、功能条件、数据范围、运行周期等等No/Lost、More/Less、Delay/Before、Unintended、Other than、Part of）


软件模块的数据接口（接口变量、数据类型、取值范围、初始值、失效模式）

软件模块的时序及执行（周期、执行时间、执行时序、优先级、失效模式（阻塞、死锁、活锁、时间分配错误、同步失效、执行顺序错误））

软件对应的内存属性（内容失效（读取或者写入数据损坏）、访问权限（非法的读写、内存资源使用）、空间不足（分配空间不足、内存不释放、内存溢出）、地址错误（读取或者写入地址错误）、数据不一致（读取数据不一致））

软件部署（CPU核依赖（负载高低）、存储依赖（堆栈使用和访问）、底层/OS依赖（任务调度和优先级）、通信总线依赖、外设资源依赖（外设输入和配置未及时更新或者获取）、模块与模块之间的依赖）

CRC在FUSA中的应用原理

CRC校验全称循环冗余校验，一般有CRC8,CRC16,CRC32三种模式，多项式就更多了。主要用于检测或校验数据传输或者保存后可能存在出现的错误。

CRC校验的速度快、误码率低，所以常用，但是CRC校验不纠错。如果要纠错就得使用Hamming码、BCH码、Reed-Solomon码。PS：不确定的信息：IFX芯片的ECC功能就是可以检测2个Bit错误，纠正1个Bit错误，采用的好像就是硬件实现的Hamming码。

我们重新回顾一下IFX  TCxxxMCU芯片的Memory Protect Unit（MPU保护）机制，芯片会提供相应的权限保护，防止非功能安全程序访问带有安全等级的变量，一般策略是防止意外的篡改，并不防止意外的读。

那么，在MCU芯片没有MPU保护之前，内存保护怎么做呢？其实很多国际大厂就是用CRC校验做的，访问这些变量需要利用特殊的接口，不能直接访问其符号表。我之前碰到的这种变量，称之为“安全变量”，如果你在ABCD这种公司，接触到老项目，可以看看代码中还有没有这种老的机制存在。这种机制之前应用在ASIL-C等级的环境中，就ADAS而言，一般要求ASIL-B，在MPU侧开发这种功能安全机制，完全满足功能安全需求。那么使用CRC校验能满足功能安全要求的安全机制是什么呢，防止哪些错误呢？

在通信或者内存读写的过程中，一般有如下故障信息：

常见故障	安全机制
信息重复	计数器+时间戳
信息丢失/删除	计数器
信息延迟	时间戳+超时机制
通信通道阻止访问	计数器+超时机制
信息次序错误	计数器+时间戳
信息只被部分接收者收到（节点丢失）	计数器+超时机制
信息数据损坏	CRC
发送给多个接收者的信息不对称	CRC
信息插入	计数器、反馈信息、源ID、ID处理
错误寻址	DataID
伪装源发送	反馈信息、ID处理+CRC

一般情况下，如上表所示，基于上述故障和安全机制的分析，通信相关的功能采用E2E保护机制，E2E保护机制本身就带有CRC校验。

内存相关的相关故障分析如下：

常见故障	安全机制
分配空间不足	预先静态分配内存、内存监控
内存空间不释放	内存监控、定制化的内存库
写入地址错误	逻辑检测、地址信息校验
写入数据损坏	CRC校验、纠正码
写入空间溢出	CRC校验或者标志码
读取地址错误	逻辑检测、地址信息校验
读取数据损坏	CRC校验、纠正码
读取数据不一致	CRC校验、确定性调度
非法的读或写	内存访问权限隔离、共享内存划分
内存资源使用冲突	任务调度排布、时序分析

CRC校验在内存资源的错误检测中也有着很有效的作用。当然在内存保护中，一般CRC校验和特殊的Pattern联合使用，特殊Pattern的原理就是和栈区的溢出检测原理一致。
总结

FUSA在MCU中有很多硬件机制，但是在SoC侧很多机制需要软件实现。需要理解MCU侧硬件提供的功能安全机制的原理，在SoC侧用软件实现它，当然软件实现有它的局限性，但是总比没有好。

另外一方面，功能安全对编码有很多要求，总的来说，就是要求用最旧最保稳的技术开发功能安全软件，不要使用新特性，不要用动态对象。