什么ISO 26262功能安全标准?

概览

随着各行业引进一系列产品设计和测试的标准化流程,安全保障也日益规范化。ISO 26262是针对汽车零部件中的关键电气和电子(E/E)系统的功能安全标准。 ISO 26262基于IEC 61508制定,后者是电气和电子系统的通用功能安全标准。本白皮书介绍了ISO 26262的关键部分及软硬件认证。此外,本白皮书还涵盖了ISO 26262的测试过程,以及符合ISO 26262规定的认证工具。

内容

背景

随着汽车行业复杂性的日益提升,人们加大了开发安全合规系统的力度。例如,现代汽车使用了油门线控等线控系统。驾驶员踩油门时,踏板中的传感器将向电子控制单元发送信号。该控制单元会对多种因素进行分析,如发动机转速、车辆速度及踏板位置,然后向油门传递指令。要测试和验证油门线控这类系统,对汽车行业来说是个不小的挑战。ISO 26262的目标是为所有汽车E/E系统提供统一的安全标准。

ISO 26262的国际标准草案(DIS)于2009年6月发布。自草案发布以来,ISO 26262在汽车行业的影响力逐渐加深。由于公开标准草案的面世,律师们将ISO 26262视为尖端技术标准。尖端技术是指一个设备或工艺在特定时间的最高发展水平。德国法律规定,汽车生产商通常要对产品故障导致的人身伤害承担赔偿责任。尖端技术都无法检测的故障可获得免责。[德国产品责任法(§ 823 Abs.1 BGB, § 1 ProdHaftG)]。

ISO 26262提供了一个通用的标准,可用于衡量系统在使用时的安全性。同时,该标准还提供了通用的词汇表,用来指代系统的特定部分。这和其他安全关键应用领域保持一致:即提供一个通用的标准,衡量系统的安全性。

ISO 26262关键组成部分

ISO 26262采用分步系统,管理功能安全,并在系统、硬件及软件层面规范产品开发。

ISO 26262标准提供了规范及推荐做法,贯穿了产品从概念开发到报废的整个开发过程。ISO 26262详细介绍了如何为系统或组件指定可接受的风险等级,以及记录总体测试过程的方法。总体来说,ISO 26262:

  • 定义汽车安全生命周期(管理、开发、生产、运行、服务、报废),并支持在各生命周期阶段中自定义必要的活动
  • 提供基于风险的具体方法,判定汽车的风险等级(汽车安全完整性等级,简称ASIL)
  • 使用ASIL指定项目的必要安全要求,以使残余风险在可接受的范围内
  • 提供验证要求和确认方法,以确保实现有效且可接受的安全水平

汽车安全生命周期

ISO 26262共有10卷,用于系列量产车,包含针对汽车的章节。例如,ISO 26262的第7章对生产、运行、服务及报废提出了明确的安全要求。

ISO 26262汽车安全生命周期描述了整个生产生命周期,包括对安全管理员的需求、安全计划的制定以及确认方法的定义(包括安全检查、审计及评估)。开发E/E系统及元件需要遵循这些要求。

本白皮书主要介绍生命周期的开发部分。ISO 26262的开发部分涉及了系统定义、系统设计、功能安全评估以及安全验证。

汽车安全完整性等级(ASIL)

ASIL是ISO 26262标准的重要组成部分,在开发过程的开始阶段确定。它分析系统的预期功能,同时指出可能的危害。ASIL提出这样一个问题:“如果车辆发生故障,驾驶员和相关道路使用者会怎样?”

为了评估风险,ASIL需综合考虑暴露的可能性、驾驶员的控制能力以及发生重大事件时可能带来的后果的严重程度。ASIL不管系统所使用的技术,只关注驾驶员及其他道路使用者所受到的危害。

ASIL根据不同的安全要求分为A、B、C、D四个级别,其中D级拥有最安全的关键流程,测试规范最为严格。ISO 26262标准根据组件的ASIL级别,分别规定了最低测试要求,有助于确定测试时必须采取的方法。确定ASIL后,就决定了系统的安全目标,也就是确定了保证安全所需的系统行为。

比如,以雨刷系统为例。安全分析将确定丧失雨刷功能会对驾驶员的视线造成何种影响。ASIL给出指导,选择适当的方法来使产品达到一定程度的完整性,旨在补充现有的安全做法。目前,汽车制造采用高安全标准,而ISO 26262旨在规范行业内的特定做法。

硬件认证

硬件认证有两个主要目的:明确部件对整体系统的适应性,以及评估故障模式。基础硬件组件可通过标准认证进行评估,但更复杂的部件要求通过ASIL分解及测试进行评估。硬件组件的认证通常是在一系列环境和操作条件下进行测试。接着,使用多种定量方法分析测试结果,写入认证报告,同时随附测试程序、假设及输入标准。

软件认证

认证软件组件包括:确定功能要求、资源使用以及预测在故障和重载情况下的软件行为。在实际应用的开发阶段使用认证的软件可大幅简化该过程。通过认证的软件组件通常是十分优秀的产品,可在项目中复用,包含库、操作系统、数据库及驱动软件。

为了认证软件组件,标准需要在正常操作条件下进行测试,并在系统中插入故障,以判定其如何应对非正常输入。设计阶段将分析并处理软件错误,如运行时和数据错误。

“在实践证明”论据

硬件及软件组件可通过“在实践中证明”的论据,证明其符合ISO 26262要求。若组件已在其他实际应用中无故障运行,则可适用该条款。ISO 26262也适用于在实践中得到证明的早期系统。很多情况下,若某种系统已经在几百万辆汽车上得到验证,则没有必要重新检验其是否符合标准。例如,目前制造的汽车中,很多系统是按照ISO 26262发布前的高级别安全标准制造的。在实际应用过程中,这些安全关键组件运行良好、可靠。  在早期汽车中就已使用且一直未变的可靠系统仍可获得ISO 26262认证。类似实际应用和得到广泛部署的早期实际应用中的认证组件结合,极大地降低了总体系统复杂度。

应用现有流程

执行类似于ISO 26262这样的新标准,主要挑战之一是将其应用于现有流程。对于新标准,需要使用试验项目展示标准的实现,及其对现有流程的影响。目前的结果表明,ISO 26262符合业内现有的安全理念。各公司已经看到了在开发阶段早期评估风险并进行危害分析的优势,并开始将测试投入各流程中。

计划执行ISO 26262的公司需要理解,我们的目的是在开发过程的早期阶段分析风险、确立适当的安全要求,并通过开发中的测试最终满足这些要求。

测试工具认证

测试是ISO 26262开发过程中的重要组成部分。安全关键系统必须合理应对测试场景,并在面对各种人为及环境输入时维持在指定的安全范围内。使用高质量测试系统可提高产品性能、提升质量及可靠性,同时降低返修率。据估计,与实际应用中相比,在生产中发现错误所产生的故障成本将降低10倍;若能在设计环节发现错误,故障成本又比在生产中发现降低10倍。测试通过发现缺陷并收集数据,可改进设计或流程,为您的组织创造价值。通过技术创新和妥善实践方法推动流程创新,可大幅提升效率,降低花费。人们容易忽略工具,只考虑系统的设计。但实际上,工具对终端用户的安全十分重要。

ISO 26262发现,使用广泛应用的软件工具可简化或自动化开发电子、电气及软件元件(提供安全相关功能)所需的步骤及任务。介绍工具认证过程的细节前,需要定义工具认证的一个重要部分:工具置信度。

工具置信度

通过工具的输入和输出,可开发典型(或参考)用例。分析用例便可确定工具置信度,简称TCL。TCL和ASIL决定了软件工具要求的认证水平。要确定置信度,需要评估以下两种因素:

  • 软件工具出故障的可能性,以及错误输出对安全相关项目或开发中的元件会造成何种危害
  • 在输出中预防或检测该错误的可能性

工具置信度分为TCL1、TCL2、TCL3和TCL4,其中TCL4为最高置信度,TCL1为最低置信度。

工具认证过程

要根据ISO 26262对工具进行认证,需要满足多项要求。例如,ASIL必须已经确定。工具必须包含用户手册、独特的标识及版本号、功能描述、安装过程以及环境(仅举几例)。ISO 26262要求提供以下工具认证材料:

  • 软件工具认证计划
  • 软件工具文档
  • 软件工具分类分析
  • 软件工具认证报告

软件工具认证计划

软件工具认证计划(STQP)是在安全相关项目开发生命周期的早期创建的。它主要关注两个方面:计划软件工具的认证,以及能证明该工具符合所需置信度的用例。

STQP必须包含的项目有:软件工具独特的标识及版本号、用例、环境、描述、用户手册以及预先确定好的ASIL。

软件工具分类分析

软件工具分类分析(STCA)的主要目的是确定工具置信度。确定TCL有两个主要因素。第一个因素是工具影响(TI)。第二个因素是工具错误检测(TD)。根据这两个因素,选择合适的TCL。

工具影响分为TI1和TI2两类。当确定发生故障的软件工具绝对不会违反安全要求时,选择TI1。对于所有其他情况,选择TI2。

例如,假设某工具在执行特定软件功能时,会在文档中产生错误字符。这仅仅是一个小错误,并不违反测试时的安全要求。该错误造成的是TI1类别的工具影响。若工具造成的错误以任何形式改变了系统行为,则选择TI2。

工具错误检测分为TD1至TD3几类。TD1代表对工具检测错误的能力有高度的置信,而TD3则代表很低的置信度,即只能随机检测出错误。

例如,假设某工具用于检测设计模型的错误。该工具对模型执行静态分析。当静态分析良好时,该工具不能检测模型中的所有可能违规行为。还有一点值得注意的是,这并不一定意味着该模型不正确,仅表明需要进行额外测试。这种情况属于中等程度的置信度,即TD2。

 

 

工具错误检测

TD1

TD2

TD3

工具影响

TI1

TCL1

TCL1

TCL1

TI2

TCL1

TCL2

TCL3

根据所需置信度,一旦确定了工具影响(TI)和工具错误检测(TD),就确定了TCL的级别。有时,多个用例可能产生不同的TCL。出现这种情况时,请使用最高级别的TCL。对每个软件工具,用户需进行工具分类。 

软件工具文档

为确保正确使用软件工具,必须提供多种信息。

  • 功能描述
  • 安装过程描述
  • 用户手册
  • 运行环境
  • 异常状态下的预期行为

软件工具认证报告

软件工具认证报告包含结论以及完成认证且满足要求的证据。任何验证期间产生的故障或错误输出都需在此进行分析和记录。

实践提升置信

从实践中提升置信是工具认证的一个重要方面。若能证明某工具已经符合认证要求,就无需进一步的认证。这将大幅降低开发过程中的花费及时间成本。然而,在用于项目开发前,每个安全相关项目或元件都必须证明已达到认证要求。为证明这一点,该工具必须证明:

  • 曾经为了相同的目的,在类似的用例中使用过
  • 该工具的规范没有改变
  • 未在曾经开发的安全相关项目中违反安全要求。

例如,假设工具A用于验证汽车X的ECU(引擎控制单元)。若测试工具A未违反任何安全要求且没有改变,那么它就可用于验证汽车Y的ECU,只要汽车Y的ECU用途与汽车X的ECU使用方法类似即可。

继续学习

欲知NI测试工具如何用于测试安全相关项目,请参考NI测试安全兼容系统妥善做法。该白皮书包含诸如模型在环测试和硬件在环测试等技术,贯穿整个开发过程。此外,该白皮书还讨论了组件重用的优势及效率提升。

更多资源