kaixinmeimei的博客

原创 ISO 26262-11 半导体（芯片）功能安全学习笔记（一）

如果一个半导体组件时基于ISO 26262系列标准开发的，那么它要满足最高层安全目标项目的硬件安全需求，并通过TSC来实现。需要满足故障的诊断覆盖率，满足PMHF或EEC。满足分配的SPFM，LFM，PMHF目标值，需要进行ISO 26262-5：2018 7.4.3和ISO 26262-9“2018第八章的安全分析。半导体器件可以按照SEooc开发，这样开发可以评估满足假设的工作环境，验证需要基于更高层的集成环境，并考虑更从安全目标中导出的安全需求。4.1 怎样考虑一个半导体组件。

原创 ISO 26262-6 软件设计

原创 ISO 26262-6 软件开发前准备

原创 ISO 26262-6

注：只有其行为依赖于配置数据的那部分嵌入式软件要针对配置数据集进行验证。条的规定进行验证，以确定用于所考虑项目开发的配置数据集。证明配置数据满足软件架构设计和按照软件单元设计规范。等级应等于应用于该数据的可配置软件的最高。配置数据不同要素之间的相互依赖。配置数据要保证能被正确使用。配置数据的目的和用法；使用的值在规定的范围内。与其它配置数据的兼容性。

原创 ISO 26262-6 软件功能安全

原创 ISO 26262-5 硬件功能安全 通过安全分析评估PMHF

功能2 有两个输入（通过传感器I1 和I2 生成脉冲来测量轮速）和一个输出（通过I61 控制阀1），其功能是当车速高于90km/h 时打开阀1。如果没有电流经过I61，阀1 打开。相关联的安全目标2 是“当速度超过100km/h 时关闭阀1 的时间不得长于200 ms”。安全目标被分配为ASIL C 等级。安全状态为：阀1 打开。微控制器读取I1 和I2 的脉冲值。通过这些传感器给出的平均值计算轮速。安全机制2 （表中的安全机制SM2）比较两个输入。SM2 对每个输入的失效探测达到99%的诊断覆盖率。

原创 ISO 26262-5 硬件失效计算例子

硬件架构度量示例计算：“单点故障度量”和“潜伏故障度量”

原创 ISO 26262-5 硬件失效计算公式

原创 ISO 26262-5 区分失效模式

多点故障，两点以上的故障就是多点故障，如我们可以在一个位置同时布置两个温度传感器去采集温度，则一个温度传感器损害就是多点故障。单点故障时失效率直接影响安全目标的故障，距离，如我们安全目标是要判断过温，则温度传感器的故障就是单点故障。如果多点故障发生可以被检测到就是可探测的多点故障，如BIST一般用来检测多点故障。如多点故障发生可被驾驶员感知，则是可感知的多点故障，如故障发生会导致故障灯点亮。多点故障又分成可探测的多点故障，可感知的多点故障。安全相关的故障有单点故障，多点故障，残余故障。

原创 ISO 26262-5 评估硬件随机失效率

在硬件随机失效率评估中，针对ASIL(B)、C和D的安全目标，有两种主要方法：随机硬件失效概率度量（PMHF）和对违背安全目标的每个原因进行评估（EEC）。PMHF是一种定量分析方法，用于评估硬件要素的随机失效是否违背安全目标，通常使用表6、相似设计的现场数据或定量分析技术（如FMEDA和FTA）来计算。目前，FMEDA被广泛用于计算PMHF，而FTA则主要用于硬件架构的定性分析，以提高效率。EEC则要求对每个硬件元器件及其在单点失效、残余失效和双点失效方面的影响进行独立评估。

原创 ISO 26262-5 评估硬件架构度量值

如果能够提供的硬件元器件失效率证据不足，应提出替代方案（ 例如， 增加安全机制来探测和控制此故障）。上面两个值的评估方法是FMEDA，可以是excel表格形式，也可以是某种工具里带的表格的形式，如MA。应结合残余故障和相关的潜伏故障来预估安全机制所实现的安全相关硬件要素的诊断覆盖率。两种硬件架构的度量， 用于评估相关项架构应对随机硬件失效的有效性。单点故障度量和潜伏故障度量的诊断覆盖率来评估。） 的定量目标值应基于下列参考目标值来源之一。） ” 的定量目标值应满足下列表格。

原创 ISO 26262-5 生产维护和报废

在生产、运行、服务和报废过程中，若安全分析显示存在与安全相关的特殊特性，需明确这些特性并制定相应的措施和接受准则。这包括编制《特殊特性清单》、《维修手册》和《用户手册》。为确保功能安全，必须向负责这些阶段的人员提供避免错误组装、拆卸和报废的信息。此外，安全相关硬件要素应具备可追溯性，以支持有效的现场监测和召回或更换管理。硬件设计过程中产生的相关要求也需传达给负责人员，确保在整个生命周期内维护安全标准。

原创 ISO 26262- 5 评估硬件度量值

硬件架构度量评估是确保系统应对随机硬件失效有效性的关键步骤。主要使用FMEDA方法，针对ASIL B、C和D安全目标进行评估，重点包括诊断覆盖率、单点故障度量和潜伏故障度量。对于ASIL C，诊断覆盖率需≥97%，而结合残余和潜伏故障的诊断覆盖率则需≥80%。硬件元器件的预估失效率应依据SN29500、IEC61709等标准确定。若失效率证据不足，需提出替代方案，如增加安全机制。每个安全目标的单点故障度量和潜伏故障度量需满足特定定量目标值。FMEDA作为硬件功能安全的核心，其复杂性体现在对多个安全要素的细致

原创 ISO 26262-5 硬件验证

硬件需求验证需确保满足安全需求、HSI及功能安全特殊特性要求。验证方案依据ISO2626-5表3实施，按功能安全等级选择方法，如ASILC等级需进行硬件设计检查、安全分析，并推荐仿真和原型机开发验证。若硬件安全要求实施不可行，应遵循变更管理流程提出变更。同时，需验证集成到硬件中的SEooC（独立于环境的安全要素）假设的有效性，确保符合硬件安全要求和设计规范。

原创 ISO 26262-5 安全分析

应具备证据以证明安全机制在可接受的多点故障探测时间间隔内完成潜伏故障的失效探测和实现或保持安全状态及警示驾驶员的能力，以确定哪些故障保持潜伏，哪些故障可被探测到；a）证明安全机制具有实现和保持安全状态的能力（特别是在容错时间间隔和最大故障处理时间间隔内适当的失效减轻能力）对于每个安全相关的硬件组件或元器件，针对所考虑的安全目标， 安全分析应识别以下内容（适用于等级为。应具备实施的安全机制对防止潜伏故障的有效性的证据（潜伏故障的处理）。的故障或减少残余故障的有效性的证据。应具备实施的安全机制对防止导致。

原创 ISO 26262-5 硬件详细设计

硬件详细设计是确保硬件系统可靠性和安全性的关键步骤。设计过程中需进行理论计算和分析，避免常见缺陷，并应用经验总结。设计时应考虑温度、振动、水、灰尘、电磁干扰等非功能性因素对硬件元器件失效的影响。同时，需评估硬件元器件的任务剖面和运行条件，确保其在规格范围内运行，防止预期使用导致的失效。鲁棒性设计原则应贯穿始终，通过保守规范应对环境和运行应力。选择功能安全芯片时，必须确保其提供基础效率和失效模式，以及必要的安全手册、FMEDA和证书，以满足组件鉴定要求。最终，设计应输出原理图，为硬件实现提供指导。

原创 ISO 26262-5 硬件设计

硬件设计（HWD）分为硬件架构设计和硬件详细设计两个主要部分。硬件架构设计涉及硬件组件及其相互关系的定义，而硬件详细设计则关注电子电气原理图级别的元器件连接。在设计过程中，需同时考虑安全和非安全性要求，确保硬件架构实现硬件安全需求，并将这些需求分配到相应的硬件要素，按照最高ASIL等级进行开发。安全分解原则需在硬件架构设计中得到应用，且硬件要素的ASIL等级应不低于其子要素的等级。硬件架构设计应具备模块化、适当粒度水平和简单性，以避免系统性故障，并考虑温度、振动等非功能性因素对安全相关硬件组件的影响。ASI

原创 ISO 26262-5 硬件需求

硬件安全需求规范（HSR）是从技术安全要求（TSC）中导出的，专门针对硬件部分的需求。HSR应包含所有与功能安全相关的硬件需求，包括控制内部和外部失效的安全机制、符合其他要素安全要求的特性、探测和发送失效信息的机制等。此外，HSR还需定义硬件架构和随机失效的度量值，适用于ASIL等级为B、C和D的安全目标。满足功能安全需求的通用要求包括无歧义、可理解、可验证等。对于ASIL C以上的安全目标，需使用半形式化语言进行设计验证，并明确环境条件和组件需求。硬件要素的评估和测试是验证HSR的重要手段，确保单点和多点

原创 ISO 26262-4 safety validation

安全验证（车厂实施）安全验证的主要目标包括：a) 提供证据证明在将项目集成到相应车辆时，安全目标已实现；b) 证明功能安全概念和技术安全概念适合实现项目的功能安全。验证的输入包括危险分析和风险评估报告、功能安全概念以及安全验证环境。安全目标需在车辆级别的代表性环境中进行验证，考虑车辆类型和配置的差异，并涵盖影响技术特性的操作变化。安全验证的规范包括校准数据、验证程序、测试案例、驾驶操作、验收标准、设备及所需环境条件。验证执行需严格按照规范进行，并对结果进行评估，以证明实施的安全目标实现了功能安全。最终的工

原创 ISO 26262-4 系统集成和测试

•••and••••••（整车集成和测试）

原创 ISO 26262-4 系统设计

4-6的输入是3-7的功能安全概念，输出是part 5，6的硬件及软件设计。系统设计包括系统的功能模块和接口，并需要把TSR的需求分配到系统功能中。对应是4-7的系统集成和测试。TSR包括安全目标，安全需求。TSC=TSR+系统设计。

原创 ISO 26262-3 功能安全概念

功能安全概念学习的核心在于确保系统在发生故障时仍能保持安全运行。其主要目的包括：定义系统在安全目标下的功能行为或降级行为；制定探测和控制故障的约束条件；通过系统自身、驾驶员或外部措施实现故障容错或减轻故障影响；将功能安全要求分配给系统架构或外部措施；并验证功能安全概念。以BMS（电池管理系统）为例，整车层面需定义BMS的功能安全要求，如接收VCU的高压启动信号后，BMS需在100ms内监控继电器是否粘连。若继电器正常，则按序吸合高压继电器；若粘连，则反馈无法吸合的信号并报警，确保系统安全。

原创 ISO 26262-3 危害分析

ISO 26262-3 危害分析，听过危害分析导出安全目标和安全等级

原创 ISO 26262-3 概念阶段-Item 定义

ISO 26262-3 item 定义

原创 ISO 26262-4，5，6主要开发过程

ISO 26262-4，5，6主要成果物

原创 转向系统的功能安全目标有哪些？

转向功能安全目标

原创 BMS的功能安全目标有哪些？

功能安全，安全目标，BMS，安全等级

原创 重放攻击及侧信道攻击

ISO 21434 侧信道攻击 重放攻击

原创 什么是级联失效cascading failure

什么是级联失效cascading failure

原创 设计中的共因失效

功能模块甲和乙都由电源a供电，而电源a又受到EMC的干扰，导致供电电源异常，而影响了功能模块甲和乙的功能正常运行，则甲和乙的失效原因就是共同原因（共因EMC）导致的失效。2.通过隔离或者多样化的设计使各个通道最大程度的独立化，可以通过物理隔离，将功能模块甲和乙隔离开，或中间加磁阻，电容等方式对干扰进行隔离。如温度环境导致两个功能模块不能正常工作，同样 湿度环境，粉尘，EMC等外部应力导致的硬件失效中的湿度，粉尘，EMC都是共因；共因失效：共因故障导致的失效。举例说明硬件设计中的共因失效。

原创 ISO 26262-2 功能安全管理

汽车功能安全管理

原创 ISO 26262-1 词汇

ISO 26262-1 词汇

原创 功能安全标准整理

功能安全标准整理，汽车功能安全标准