干货实录 | 软件可靠性与功能安全：看似相似，实则不同

本文整理自SASETECH社区技术分享直播《软件可靠性与功能安全》主讲人是九号公司的功能安全专家Jeff.zhao(赵老师)——具有十余年的车辆控制器开发经验在系统安全设计、软件安全及可靠性、硬件安全设计、基于RISC-V的MCU功能安全设计方面有丰富经验。本文涵盖软件可靠性的基本概念与核心指标、与功能安全的本质差异、可靠性设计原则、基于操作剖面的测试方法以及精选的现场问答。功能安全在汽车行业已经讨论了很多但软件可靠性相比之下谈得比较少。很多人听过这个概念却不一定清楚它和功能安全到底是什么关系——是包含是重叠还是两码事这次分享从两者的本质差异切入把软件可靠性里那些真正对功能安全有借鉴价值的东西——尤其是操作剖面测试和可靠性设计原则——做了清晰的拆解。一、软件可靠性是什么可靠性的定义很简单产品在规定的条件下、规定的时间内完成规定的功能的能力。软件可靠性就是把主语换成了软件产品。但深入看规定的条件对软件来说指的不是工况或场景而是软件运行所依赖的硬件配置、基础软件、操作系统和网络环境。规定的时间指的是软件要在分配的时间片内完成执行。规定的功能就是每个软件模块承担的特定需求——比如BMS完成电池状态监控电机控制器完成电机控制。可靠性的内涵可以拆成五个维度可用性、容错性、健壮性、成熟性、可恢复性。一软件可靠性的指标软件可靠性的指标体系包含失效率λ、累计失效率、可靠度、平均无故障时间MTTF/MTBF等。这里有一个关键差异值得注意功能安全从不对软件提失效率。功能安全的做法是通过流程、测试、设计等最佳实践来保证软件开发质量是定性的。但可靠性会把这些指标作为目标来定和实现是定量的。二指标的分配拿到一个可靠性目标后怎么分配到各个软件模块有四种分配方法等值分配把目标失效率平均分到每个模块最简单基于关键度分配越关键的模块失效率越低基于复杂度分配越复杂的模块失效率越高基于任务剖面分配执行频率越高的模块失效率越低二、软件可靠性 vs 功能安全核心差异在哪功能安全和可靠性都属于质量的大范畴有交集但核心目标不同软件质量满足用户对功能、性能等综合要求软件可靠性在规定的条件下、规定的时间内完成规定的功能功能安全防止由于系统故障导致人员伤亡关键差异在于站在功能安全的角度功能可以不实现可以降级但不能造成人员伤亡。这是两者的分水岭。1、流程上的差异软件可靠性有开发流程框架每个阶段有对应活动但没有功能安全那么细。功能安全标准ISO 26262详细规定了每阶段要做什么、从哪里输入、输出什么。相比之下可靠性的落地指导偏弱这也是在汽车行业做得相对较少的原因。2、测试上的差异一般性软件测试的目标是发现bug、保证质量。软件可靠性测试的目标是评估当前的可靠性水平——它不关心有没有bug它关心的是现在的可靠度够不够。三、软件可靠性的两个设计原则1、避错设计七个原则的核心目标就是一个字简。具体看就是从四个维度衡量模块化程度、耦合度扇入扇出数、模块规模代码行数、输入参数数、复杂度圈复杂度、嵌套层数。线性原理要求函数按顺序执行避免深层嵌套。易证原理要求模块可验证——越简单、越确定越容易验证。2、容错设计软件失效有时无法完全避免比如硬件引起内存比特翻转、CPU执行错误关键在于如何把错误容忍下来不让它传播成系统级失效。容错设计主要涉及三个方面软件冗余——设计两个独立的软件通道实现相同功能一个失效另一个顶上避免单点失效直接导致系统失效。故障诊断与容忍——通过看门狗等机制检测异常。举例来说看门狗检测到任务超时后主动复位该任务在错误扩散之前切断传播链这是最常见的容错手段。故障影响缓解——当失效已经不可避免时降低其危害程度。比如功率降级策略确保系统不会因为局部失效而完全失控。四、操作剖面软件可靠性测试的精髓1、什么是操作剖面操作剖面就是软件的真实运行场景画像。核心思想是测试要基于真实使用场景而不是随机场景。举一个ATM机的例子插入卡→输入密码正确概率99%错误1%→后续操作可能是取现、转账、缴费、修改密码每一步都有对应的概率。把这个流程画出来就知道每一个task的执行频率后续测试用例就按这个频率来设计——执行最多的功能测试用例就要最多。2、去哪里找这些概率有两个途径一是统计数据——比如银行后台可以统计ATM每一步操作的频率二是调研和分析——没有客观数据时需要做全面的场景调研和领域判断。3、增长测试 vs 验证测试软件可靠性测试包含两种可靠性增长测试SRGT发现一个缺陷、修改一个缺陷再测再改。在这个过程中可靠性不断增长直到达到目标值比如MTTF从最初的10小时增长到1000小时。可靠性验证测试摸底测试不改缺陷只评估当前可靠性水平。五、功能安全能从可靠性借鉴什么三个具体方向1. 避错和容错设计原则——尤其是简单原则的四个衡量维度对功能安全开发中的软件架构评审很有实操价值2. 任务操作剖面——能识别出哪些软件模块执行最多、最关键从而更精准地分配测试资源和安全分析的深度3. 基于场景的测试思路——功能安全测试通常基于需求而可靠性测试基于真实使用频率两者互补能让测试覆盖更有说服力六、精选问答Q1软件可靠性测试用例怎么写答重点在于构建任务操作剖面。剖面构造出来之后完全可以通过AI来生成测试用例。所以关键在前端的剖面构建不是后端的用例编写。场景越充分任务剖面越完善测试就越有针对性。Q2可靠性顶层目标怎么定答跟功能安全目标确定过程类似——分析失效后的影响影响恶劣就把失效率目标定低些、可靠度目标定高些。具体数值一方面看行业对标另一方面看标准要求。比如航空标准会规定一定周期内不能出现什么样的事故分配到软件就有了顶层目标。Q3ASIL D下的软件开发测试核心动作是什么答把功能安全简化就是三件事找失效→处理失效→验证失效。用什么方式找失效FMEA等、针对失效的诊断和处理措施是什么、验证失效的措施有没有起效——把握住这条线就抓住了核心。Q4有没有软件可靠性的标准可以参考答软件可靠性相关的标准有ISO 25010、25000、25055。可靠性增长测试和验证测试可以参考国军标GJB/Z 171。另外也可以搜一下Reliasoft网站上面有大量软件可靠性的知识点。软件可靠性和功能安全各有各的目标体系和方法论。可靠性里面最值得功能安全工程师关注的两样东西一是操作剖面测试——它让测试更贴近真实使用场景弥补了纯基于需求的测试盲区二是避错与容错设计原则——尤其是简单原则的四个衡量维度是评审软件架构时非常实用的检查清单。本次直播的PPT精华已整理成PDF填写表单邮箱发送