5分钟全面了解ISO 26262 功能安全认证

1） ISO 26262ASIL等级是什么，有哪些区别？

ASIL等级的全称为Automotive Safety Integrity Level，即汽车安全完整性等级，是利用危害分析和风险评估方法得出的一种用于指示产品安全风险等级的分级方式。

ASIL等级分为四个等级，分别是A、B、C、D。等级越高，意味着该产品失效后可能引起的安全风险越大，这时产品的研发严格程度需要越高、研发成本需要越多、研发验证周期需要越长。

2）ISO 26262适合哪些企业？

ISO 26262适合应用于道路车辆（包括汽车、摩托车、卡车、大巴等）电子、电气、软件组件安全相关的产品（可以是整个系统、硬件模块、嵌入式软件、半导体IC等产品）的企业。

3）ISO 26262能为企业带来哪些好处？

最大程度降低产品失效的风险，增加客户对产品安全的信心，保证司乘人员及相关人员的安全；提升企业在汽车行业的竞争力，最大程度的降低召回风险，避免蒙受较大的经济损失。

4）申请ISO 26262的前提是什么？

已通过质量管理体系（ISO9001或IATF16949）的认证。

5） ISO 26262体系认证和产品认证有哪些区别？

体系认证，又称为流程认证，用于证明企业已经根据ISO 26262标准相应的安全等级（ASIL等级）要求建立了开发功能安全产品的能力，包括安全文化、流程能力、工具能力、人员能力、生产制程能力或服务能力。

产品认证，用于证明企业已经根据ISO 26262标准ISO 26262标准相应的安全等级（ASIL等级）要求开发了一种功能安全产品，该产品通过检查组织的评估后，满足了相应ASIL等级的所有功能安全目标和功能安全要求。

一般情况下，企业先做流程认证，建立起功能安全开发能力后，再申请做特定的产品认证会比较合适，但并不排除企业会直接申请做产品认证。

6）ISO 26262体系认证包括哪些内容？

ISO 26262流程认证的主体内容Part2~Part9。可以根据企业的需求，进行合适的裁剪。例如只研发、生产纯硬件的企业，可以把Part6(软件开发)裁剪。

7）ISO 26262体系认证有哪些流程，周期多久？

初审，认证机构进行初步评价；一阶段审核，认证机构执行一阶段审核，针对体系建立、运行情况，得出是否满足进入二阶段审核的结论；二阶段审核，认证机构针对企业的功能安全体系、运行记录、人员能力、安全文化、制程能力等方面进行全面审查，得出是否具备ISO 26262设计和（或）制造能力的结论。包括企业建立自身流程的时间，认证的周期一般为6~8个月，最终取决于企业投入的资源。

8） ISO 26262产品认证包括哪些内容？

产品认证是对指定型号的产品按照申请的ASIL等级进行的认证。该产品可能是一个系统、硬件、芯片或软件。不同的产品适用的标准范围不同，需要根据产品类型，以及需求来界定这个范围。

9）ISO 26262产品认证有哪些流程，周期多久？

产品认证流程主要包括：认证申请、认证实施、认证结果评定、颁发认证证书。产品认证周期取决于产品的开发周期、产品的复杂度，需要实际评估。

1 ISO 26262是什么？

ISO 26262是以IEC 61508为基础，为满足道路车辆上特定电子电气系统的需求而编写的标准；ISO 26262适用于道路车辆上特定的由电子、电气和软件组件组成的安全相关系统在安全生命周期内的所有活动。ISO 26262包含了通过提供适当的要求和流程来避免风险的指导，以降低来自系统性失效和随机硬件失效的风险。

ISO26262科普

2 ISO26262的具体要求

ISO26262为车辆全生命周期（包括产品研发、生产、使用、维保和报废）中保证电子/电气系统的功能安全提供了相应的安全保证措施，如提供了如何评估/改善/验证安全性的要求、方法和管控流程，同时还提供了包括机械、液压、气压等其他技术在内的安全性保证框架。

ISO26262从整车功能安全性角度出发，通过对功能相关项的危害分析、风险评估、确定汽车安全完整性等级（ASIL），进而确定安全目标。

为达成安全目标，细分了功能相关项，组成相关项的电子/电气系统，组成系统的各组件，以及组成各组件的元器件几层，针对每个层级制定相应的功能安全概念和技术安全概念，并通过评审、验证等手段对相关项安全性是否达成和有效进行评价。

等级确认图

评审一般针对在系统开发过程中，为达成相关项安全目标所做工作而形成的工作成果而进行评审（走查/检查/认可评审），工作成果包括约86类成果文件，涵盖了从产品概念提出阶段直至报废全生命周期功能安全活动的文档资料，也包括研制方和供应商的管理文件。

对于电子组件和元器件研制和制造者，ISO26262提供相应的安全认证指南。针对ISO26262进行专门开发的电子组件或元器件，需按照ISO26262-5的开发要求安全活动进行开发和验证。

而对货架电子组件或元器件，开发阶段并没有引入ISO26262的安全概念，需根据ISO26262-8对硬件要素的评估要求进行安全功能评估和背离安全目标风险评估。对于此类货架电子组件和元件器在评估时，根据产品的特性、评估难度的差异以及要素在安全概念中的作用进行分类（Class Ⅰ-Class Ⅲ）。

3 Class Ⅰ-Class Ⅲ

3.1 Class Ⅰ

Class Ⅰ类组件或元器件属于最简单的认证要素（电子组件/元器件的统称），被动元件和分立器件属于此类要素，共性特点工作模式较少，工作参数能够全面评价且内部没有故障诊断和控制机制。

在ISO26262-11-2011版本中，此类被评估要素只需经过ISO16750或AEC-Q相应的标准认证即可，而在2018版本中，此类要素不需要进行单独评估，而是在更高的集成层面进行评估即可。

3.2 Class Ⅱ

Class Ⅱ类要素的特点是工作模式多样，但内部同样不具备安全诊断和控制机制，如传感器，没有集成IP内核的集成电路属于此类要素。此类要素的评估需按照ISO26262-8采用分析（对数据、文件、模型、记录的分析）和测试（针对功能，使用环境的安全性进行试验验证）进行评估，被评估的要素对外界应力的鲁棒性测试按照ISO26262-5进行评估。

评估的目的是分析和验证要素的功能性能是否能够符合其规范，以及满足其预期用途。这些性能要求应充分考虑被评估要素在正常环境下以及造成故障发生环境下的性能要求。

3.3 Class Ⅲ

Class Ⅲ类要素的特点是工作模式多样，而且必须要在考虑实际工作情况下才能对其功能性能进行评估，内部嵌入安全诊断和控制机制，如MCU、DSP、集成IP内核的集成电路属于此类要素。对Class Ⅲ类要素评估最为复杂和苛刻，此要素除了要满足如Class Ⅱ类要素安全评估各项要求外，还要采用额外的评估措施，以能够说明背离安全目标和安全要求的风险足够低。额外的评估措施包括但不限于：

a) 需要根据具体的使用功能和使用环境完成安全相关功能的验证。

b）最好具备类似使用场景的使用历程，以作为硬件安全评估的支撑依据。

c）硬件内部要具备独立多样化的执行诊断功能的内核，能够进行芯片安全性的监控。

d）硬件的开发过程执行了某些安全标准，且安全标准与ISO26262的ASIL等级相当。正因如此ISO26262中对非按照ISO26262开发的Class Ⅲ类要素的评估是不建议采纳的，希望此类要素能够在未来的升级时充分按照ISO26262-5硬件层开发要求进行升级。

ISO26262-2018版本相比于2011版本增加了ISO26262-11《应用于半导体开发指南》，专门针对半导体组件及元器件的开发过程提供了方法和用例。

4 ISO 26262认证模式

认证模式一

认证模式二

认证模式三

5 ISO 26262认证范围问题

认证范围

6 ISO26262关于验证的要求

6.1 验证的基本形式

验证是ISO26262中关于成果认可最重要的环节。

ISO26262对验证（Verification）的定义是检查对象是否满足特定的要求，验证的形式包括了验证评审（verification review）、走查（walk-through），检查（inspection）、验证测试（verification testing）、模拟仿真（simulation）、原型机验证（prototyping）和分析（analysis包括安全分析、控制流程分析、数据流分析等等）。

从验证本身的系统性和正式程度从小到大排序，验证的各个形式可以排为检查、走查、模拟仿真、原型机验证、分析、验证评审。

验证在功能安全活动不同阶段的对象也有差异，比如在产品概念提出阶段，验证的对象主要为：依据危害风险评估导出的安全目标以及根据安全目标定义的功能安全概念，如场景危害识别是否适用、相关性定义是否正确、是否与其他相关项定义的危害和风险评估一致、危害事件是否覆盖实际应用等。如，在产品开发阶段，验证主要是针对硬件设计的架构，验证其需求规范、架构设计、模型或代码是否符合安全要求。

6.2 验证的基本程序

验证以建立验证计划作为开始，如上述的产品各个开发阶段的验证都是从验证计划开始的。

6.3 验证计划要包括

1）所需验证的对象：组成待验证的成果清单，要考虑成果的复杂性，进行适当的拆分；

2）针对每个待验证的成果，确定相应的验证目的，确定验证目的时要充分借鉴前期的验证经验，如维修的历史数据、已经使用的经历等，这可以指导验证目的和制定的验证方法的剪裁；

3）对工作成果采用什么样的验证方法，评审/检查/走查/测试/仿真/分析，验证方法最终要细化为“验证规范”作为验证支持依据，同时要保证验证方法是充分的，必要时要进行几种验证形式的组合；

4）如果采用的是测试或者模拟作为验证方法，则要明确验证的环境和验证所需的设备，要充分考虑验证技术的成熟度，不能采用最新的未经过经验证明有效性的方法和设备进行验证；

5）分配验证资源；

6）验证过程中出现异常时，明确应该采取或建议采取的闭环活动；

7）对于哪些已经经过验证后，进行了变更的成果，制定回归策略，即对验证计划的剪裁（是部分重复验证，还是全部重复验证）。

对于验证方法的细化就形成了验证规范，验证规范最需要细化的是测试用例。

6.4 测试用例应具有

1）测试用例的唯一识别性，即该测试应用到哪项成果，什么目的验证；

2）测试用例针对的是哪个版本的工作成果；

3）对验证目标采用何种预处理或配置，比如将MCU应用在什么场景下，配置什么功能或系统，如果对于通用型的要素，其会在很多场合应用，则需将要素置于一种通用的（覆盖多种应用场景的）条件下进行验证；

4）环境条件，就是与测试过程或模拟过程相关的物理条件，比如温度。

5）验证过程中要监测的行为，比如输出数据，可接受的范围，时间或容差的特性，测试时需要考核前后数据的变化趋势，就需要对初始值进行明确的定义；有可能存在不同的测试用例下，会存在多种预处理、配置或环境条件和规范，这时候可以采用一种明确能覆盖多种测试用例的验证配置进行验证。

6）测试通过和不通过的判据。

测试用例可以根据测试设备和测试环境、逻辑和时序关系、所利用的资源进行分组，比如对于可以分为回归测试用例或者完整的测试用例。

验证要求第二/三方验证，即不能用工作成果的完成人进行验证。验证完成后要对验证的结果进行评估。

6.5 验证结果评估需包括

1）评估验证的成果是不是唯一的；

2）评估验证计划和验证规范的完整性和适用性；

3）评估验证过程中所用到的环境配置、验证工具及标定数据是否符合要求；

4）评估验证结果与预期结果的一致性；

5）综合给出验证通过或不通过，并对于不通过的给出具体的理由以及整改建议；

6）如果存在验证过程未按照验证计划或规范执行，需要给出理由。

单一层级的验证，比如只针对开发的硬件进行功能、性能等安全性的评估，并不能提供硬件满足安全要求的充分证据，比如：硬件与其他接口兼容性、硬件与其他已有硬件的匹配性、硬件对整车安全的贡献性、硬件开发的种种假设证明的有效性等等，这些都无法单独在硬件验证的层面进行评估。

因此，为充分评估开发硬件的功能安全，往往要通过将硬件与软件、其他要素、系统甚至整车集成起来，按照“验证原型机测试”的标准去考核。

7 ISO26262给出集成测试的相关规定

7.1 集成与验证的相关规定

关于集成测试，某一开发的硬件要通过三个阶段集成至整车系统，完成安全目标的确认。

集成测试是以软硬件集成为起点，而整车级的验证对安全目标是否达成是最具权威的。但是从集成的难度和所需要的资源的考虑，集集成阶段越高，集成验证的难度越高，占用资源越多，因此尽可能选择低阶段的集成策略。

7.2 如何选择集成验证的策略

1）明确需要验证测试的目标，比如要验证安全机制对传感器的诊断，EDC对数据错误的诊断和控制等；

2）定义这些承载这些测试目标的相关项和测试的要求（预期的行为，集成的等级），比如验证开发的硬件与接口的兼容性，就必须考虑硬件与系统的集成；

3）确定了测试的目标和承载这些目标的相关项和测试要求，要进行梳理，确保每一条测试的目标都能够进行至少一次地验证，比如某项测试目标无法在软硬件集成阶段进行验证，则需要到系统集成阶段进行验证；

4）要考虑硬件开发概念阶段是否采用了假设，如SEooC的开发，是基于应用假设为前提的，对这种假设需要在系统，甚至是整车的层面进行集成验证；

5）如果系统集成时，存在多个可能的集成变体，即所谓的多配置，那么我们就要充分评估，在未来整车量产时，可能采用哪些系统配置，尽可能地包络这些系统配置（或形成系统的集合）完成系统级的验证。

确定目标和相应的集成策略后，根据需要选择相对应的方法，ISO26262 part4 第7.4.2-7.4.4给出了三个集成阶段的测试方法，总体上包括：

A 鉴定式的测试

1）功能和非功能的测试：对集成硬件的功能和性能对照规格书要求的测试；

2）内外接口测试：包括模拟，数字输入输出测试、边界测试和等价类测试，评估接口功能兼容性、时序容错性。

B 仿真与试验相结合测试

1）故障注入测试：采用特殊方法向运行中的测试对象注入故障，如骚扰、错误数据、延迟时序等；

2）背靠背测试：在具有仿真模型和结果的情况下，采用实际试验对仿真模型和结果的差异进行评估和分析。

C 基于经验性测试

1）错误猜测法测试：类似故障注入法，基于专家知识和经验数据预测被测对象可能错在的错误，然后设计评估方法去检查这些错误；

2）来自现场经验的测试：直接从使用现场采集的数据，如试车时的运行数据；

3）长期测试：类似来自现场经验的测试，只是将普通用户作为测试者，收集实际使用条件下的数据。

D 鲁棒性测试

1）资源使用测试：对集成系统所能容纳的最大负载，代码，功率等能力进行测试；

2）压力测试：测试对象在高负载和恶劣环境下是否能够长期稳定运行的能力进行测试。