• 131查看
  • 0回复

[功能安全] 功能安全的学习笔记(二)

[复制链接]

该用户从未签到

发表于 3-6-2024 19:31:48 | 显示全部楼层 |阅读模式

汽车零部件采购、销售通信录       填写你的培训需求,我们帮你找      招募汽车专业培训老师


前言

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

对于功能安全(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侧用软件实现它,当然软件实现有它的局限性,但是总比没有好。

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

快速发帖

您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|手机版|小黑屋|Archiver|汽车工程师之家 ( 渝ICP备18012993号-1 )

GMT+8, 22-6-2024 11:13 , Processed in 0.316360 second(s), 27 queries .

Powered by Discuz! X3.5

© 2001-2013 Comsenz Inc.