《动力电池及充电技术》+课件+第14章_功能安全讲解.pptx

第14章功能安全;汇报提纲;随着汽车与电力电子技术的深度融合发展，汽车逐渐从“强机械属性产品”变换为“强电气属性产品”，在电动汽车上，电气零部件的价值更是已经超过机械零部件，汽车已经不再是传统的“机械汽车”，而是“电气汽车”，随着汽车电气系统复杂性的进一步提高，软件和硬件更广泛的应用，来自系统硬件或软件随机失效的风险也日益增加，道路车辆功能安全标准ISO26262为避免这些风险提供了可行性的要求和流程。;14.1功能安全概述;2020/8/29;目前许多汽车企业和零部件企业在控制器开发过程中采用ISO26262这个标准，ISO26262包括了汽车电子电气开发中与安全相关的所有应用，制定了汽车整个生命周期中与安全相关的所有活动，ISO26262从需求开始，当中包括概念设计、软硬件设计，直至最后的生产、操作，都提出了相应的功能安全要求，其覆盖了汽车整个生命周期，从而保证安全相关的电子产品的功能性失效不会造成危险的发生。;2020/8/29;14.2相关术语定义;概念阶段的功能安全需求（FunctionSafetyRequirements）应当能够满足整车层面的安全目标（SafetyGoal），电子电气层面开发出来的技术安全要求（TechnicalSafetyRequirements）同时也应该满足概念阶段的功能安全需求，最后一步是确定零部件级别的软件和硬件的功能安全需求。图1.2是ISO26262开发途径。;2020/8/29;故障（Fault）定义：可引起要素或相关项失效的异常情况。

错误（Errors）：计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异。失效（Failure）：要素按要求执行功能的能力的终止。基于上面的定义，他们之间存在一定的因果关系，故障会产生错误，而错误会引起功能或者系统的失效，如图1.3所示。;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;2020/8/29;硬件安全需求规范应包括与安全相关的每一条硬件要求;2020/8/29;2020/8/29;ISO26262推荐用两个可选的方法以评估违背安全目标的残余风险是否足够低。两个方法都评估由单点故障、残余故障和可能的双点故障导致的违背安全目标的残余风险。如果显示为与安全概念相关，也可考虑多点故障。在分析中，对残余和双点故障，将考虑安全机制的覆盖率，并且，对双点故障也将考虑暴露持续时间。;ISO26262标准中引入了失效率等级。硬件元器件失效率的失效率等级评级应按如下确定：;功能安全要求FSR;技术安全要求TSR;14.7软件功能安全;14.7软件功能安全;软件架构包含静态和动态方面的，静态方面的主要是和不同软件单元之间的接口：;在软件架构设计中，需要重点考虑软件的可维护性及可测试性。在汽车行业，软件在整个产品周期内都应当考虑维护性，同时还要考虑软件架构的设计测试的容易性，在ISO26262标准中，测试是非常重要的一方面，任何设计都应该同时考虑到测试的方便性。;在软件架构层面，可以检测不同软件单元之间的错误。ASIL等级越高，要求的安全机制越多。下面是ISO26262中提到的一些安全机制，有些安全机制之间可能有重复。;一旦软件错误被检测到，应该有相应的错误处理机制在软件架构级别ISO26262详列的错误处理安全机制如下：;一旦软件架构设计结束后，就需要对软件架构的需求进行测试。ISO26262详列了一些方法：;软件单元测试;关于软件单元实施，ISO26262中提到的许多设计原则。有些可能不适用，取决于开发过程。有些也可能被使用的编码指南所涵盖:;2020/8/29;在软件单元设计和实现的时候，需要验证硬件软件接口和软件安全要求是否满足安全需求。此外，应确保软件代码符合编码准则，软件单元设计与预期硬件兼容。ISO推荐了的方法基本和软件架构的一样。;谢谢！