发布作品

    汽车功能安全标准“ISO 26262”导入实践(上)

    01

    前言


    近年来,在汽车领域,随着自动驾驶技术的持续创新并迅速发展,越来越需要有助于在紧急情况下防患于未然的功能(功能安全)、以及将功能安全标准化的 ISO 26262 等标准。特别是在技术创新卓著的中国,ISO 26262(功能安全)已被确立为以“GB/T”开头的推荐性国家标准,ISO 26262 的第一版中文译本“GB/T 34590”已于2017 年 10 月发布,并且已于 2018 年 5 月起开始施行。


    在这种背景下,不仅汽车制造商(OEM),越来越多的汽车电子产品制造商(Tier1)也纷纷加速了功能安全支持,从全球范围来看,实现功能安全已经是必经之路。


    本文将从半导体制造商的角度,在对功能安全和 ISO 26262 的关注度日益增加,并需要采取行动积极应对的背景下,介绍功能安全和ISO 26262是什么,以及它们如何影响最新的汽车领域。


    02

    什么是功能安全?


    首先,让我们重新思考一下什么是“功能安全”。


    2-1. “安全”的定义


    当突然被问及“请您解释一下安全是怎样的状态”时,可能很多人都难以立即作答。顺便提一下,在安全问题相关的基础导则--国际基本安全标准第一版 ISO/IEC Guide 51 中,对安全的定义是“安全 = 免于不可接受的风险”。这是一句双重否定句,可能在中文里很难立即理解,但是在英文中被描述为“Freedom from risk which is not tolerable”,可能更容易理解。但是,无论如何也很难用一句话来解释清楚“安全”到底是什么,因此我们先来解释一下安全的定义。


    “安全”的反义词是“危险”。那么,“危险”是怎样的状态呢?有时会将“危险”状态称为“有风险”。通常,“风险”有大有小。因此,通过针对“危险”(即高风险)采取措施并使风险降低到能够接受范围,“危险”状态就会变为“安全”状态。换句话说,“安全”状态也可以称之为“没有不可接受的高风险的状态”。现在能够理解开头的“安全 = 免于不可接受的风险”这句话了吧。


    2-2. “本质安全”与“功能安全”的比较


    那么,“功能安全”是什么意思?在介绍“功能安全”时,经常引用的术语是“本质安全”。在此我们想通过与“本质安全”的比较来介绍“功能安全”。“本质安全”是一种通过消除危险原因来确保安全的方法。而“功能安全”是通过功能方面的努力将风险降低到可接受水平来确保安全的方法。


    例如,以道路和铁路交叉口为例,让我们来思考一下应该采取什么措施来避免汽车和火车之间发生碰撞(图 1)。


    为了消除道路和铁路交叉的危险原因,将道路和铁路分开,建立交桥来避免碰撞的做法就是基于“本质安全”的思路。按照“本质安全”的思路,采用立交桥的做法,可以从物理上消除汽车与火车之间的碰撞。而“功能安全”的方法则可能是通过设置铁路道口来避免碰撞。在道路与铁路的交叉处设置警报器和栏杆,在铁路上安装传感器,当传感器检测到火车接近时,警报器响起,并降下栏杆。当另外的传感器检测到火车已经通过时,警报器停止,并升起栏木机。虽然道路与铁路在物理上仍然交叉,但可通过设置铁路道口的方法将把汽车和火车相撞的风险降低到可接受的水平。这就是“功能安全”的思路。


    图 1. 本质安全与功能安全的思路


    如前面的案例所示,“本质安全”可以确保绝对的安全性,但是通常会很昂贵。相比之下“功能安全”很多时候只要相对较低的成本就可实现,但在设计时必须考虑到当附加的功能发生故障时应如何确保安全。在上述“功能安全”的案例中,如果传感器损坏,那么即使火车接近时,警报器和栏杆也不会工作。这样,就会立即变为“危险”状态,因此就需要一种即使传感器损坏也不会引发危险状态的设计。例如,对传感器增加自我诊断电路,设计为如诊断出自身有问题就会降下栏杆。这样即使发生故障也会导向安全的方向,这就是“故障安全(Fail Safe)”的思路。或者需要进行“冗余设计”,比如设置双重传感器,即使一个传感器损坏,另一个传感器也会工作,在此期间可以对损坏的传感器进行修复。顺便提一下,作为双重保险的案例,还有铁路道口警报器的红灯、汽车的前灯/尾灯等。这些不仅是出于外观设计的考虑,而且还有双重保险的考虑,即使一个灯灭了也能确保最低限度的安全。


    2-3 如何实现功能安全


    为了避免严重事故的发生,需要基于“人会犯错”、“东西会损坏”的考虑来进行制造,因而有了“功能安全”。要想实现功能安全,需要防止人受到设计对象的动作或行为的危害,而要想实现这一目标,就需要同时考虑到“系统性故障”和“随机性故障”这两方面。


    “系统性故障”是指在设计时就隐含的潜在故障,通常称为“Bug(漏洞,缺陷)”。要想防止系统性故障,就需要构建一个不会引起设计漏洞的设计流程。具体而言,需要从根据要求制定规格开始,明确每一个流程(如设计、验证、试制、评估等),并在各阶段进行评审。而且还需要管理各阶段制作的表单类文件,确保可以随时取用。而“随机性故障”则是指制造后发生的故障。由于不能完全预防随机性故障,因此有必要设立一种安全机制,以确保即使发生这种故障也不会对人造成危害。


    2-4 半导体的功能安全


    随着以车载和工业设备为中心的技术创新,电子产品变得越来越高难度,越来越复杂,半导体的作用也越来越大,对半导体采取功能安全措施的要求也越来越高。


    通常,半导体产品是在硅电路板上形成电路、并被称为“模塑”的黑色树脂固封,因此内部是看不见的。然而,在这种小黑块中却包含着成千上万的晶体管和电阻等元件,因此,电路和模块结构等也很复杂。为了应对这些半导体产品的故障,需要从开始设计之前的规格制定阶段就纳入适当的功能安全概念。因此,半导体本身也需要同时考虑到对应系统性故障和随机性故障的“功能安全”支持。



    03

    与 ISO 26262 相关的标准


    我们已经对“功能安全”的概念有所了解,下面来概述介绍本文的主题--功能安全标准“ISO 26262”。另外,请记住功能安全标准不仅仅局限于汽车领域,在其他领域也有各种功能安全标准。


    3-1 主要的标准


    在详细介绍“ISO 26262”标准之前,先来介绍一下主要标准。首先,“ISO”是指 International Organization for Standardization(国际标准化组织),是总部位于瑞士日内瓦的非政府机构,旨在制定并推广国际标准(IS:International Standard)。其中 ISO 9001(质量管理体系)和 ISO 14001(环境管理体系)是非常有名的标准,估计很多人可能都听说过。


    其次是“IATF 16949”,汽车行业的国际质量管理体系标准。顺便提一下,IATF 标准是由国际汽车工业特别工作组制定的。“IATF 16949”是在“ISO 9001:2015”的基础上添加了汽车工业相关的必要事项,因此必须与 ISO 9001 一起使用。“ISO 26262”是以已经存在“IATF 16949”这样的质量管理体系为前提制定的。


    3-2 ISO 26262 的由来及其他功能安全标准


    前面提到的 ISO 26262 是汽车电气/电子系统相关的“功能安全”标准,是基于 IEC 61508(也被称为功能安全的母标准)制定的。


    IEC 61508 是由 IEC(International Electrotechnical Commission:国际电工委员会)制定的电气、电子、可编程电子系统的功能安全国际标准,对象为工厂、发电厂、机械、铁路、医疗设备、家用电器等。ISO 26262 是遵循 IEC 61508 的基本思路和框架,并根据汽车的电气/电子系统进行修改而成的。


    顺便提一下,在其他行业中也有很多基于 IEC 61508 的功能安全标准。具有代表性的标准有:流程工业(IEC 61511)、工业机械(IEC 62061)、机械类的控制系统(IEC13849)、可调速电力驱动系统(IEC61800-5-2)、家用电器(IEC 60335-1)、核能(IEC 61513)、铁路(IEC 62278)、机器人设备(ISO13482)、医疗设备(IEC 60601)、电梯(EN81)、炉用电气设备(EN50156-1)等。


    应该指出的是,虽然 ISO 26262 旨在实现功能安全,但它并不是法律。因此,不遵守 ISO 26262 标准并不违法。但是,汽车制造商不会购买不符合标准的产品。汽车制造商通过根据 ISO 26262 设计电气/电子系统来证明能够确保汽车的安全。而且,设计应确保即使发生了电气/电子系统故障,也不会造成人身(不仅包括驾驶员和乘客,还包括行人等)伤害。


    3-3 如何满足 ISO 26262 标准?


    要想满足 ISO 26262 标准,就需要从“流程支持”和“产品支持”这两方面来对应。这种标准中所说的“流程”是指包括输入、处理、输出在内的整个流程,“流程支持”是指在包括开发步骤在内的整个开发流程中进行对应。要求通过完善公司内部规定和开发标准等,来建立开发时所需的文件和评审等开发流程。


    “产品支持”是指在产品功能方面的对应,在设计的产品中设置一种安全机制,能够在产品的哪里发生了故障时检测出该故障,并进行某种处理,从而避免危险。接下来再稍微具体一些思考一下流程支持和产品支持。


    前面介绍过,从“人会犯错”的角度看,设计时隐含的潜在故障(=即 Bug,缺陷,漏洞)是系统性故障,作为避免这种系统性故障的对策,就需要流程支持。要想在设计时不存在潜在缺陷,应规定开发时所需的文件和评审等,并将其作为文档保留以用作证据。所有的软件故障都是系统性故障。


    另外,前面也介绍过,从“东西会损坏”的角度看,将市场(或工厂)发生的故障归为随机性故障(或随机性硬件故障),作为应对这种随机性故障的对策,就需要产品支持。在设计时需要考虑到各种余量以避免产品损坏。从功能安全的角度出发,要求即使发生故障也不会造成人身伤害。


    因此,需要设立一种安全机制,以确保能够检测出故障并针对不同的故障做出适当的处理。在设计初期的规格探讨阶段,需要研究并探讨每种功能可能会发生的故障,以及针对该故障应该设立什么样的安全机制。产品支持是指为了对应随机性故障从而增加安全机制。


    3-4 设计者的产品责任


    产品责任(Product Liability)相对小众,一起来了解一下什么是产品责任。产品责任是指由于产品的缺陷,造成了人身伤害或财产损失,甚至危及人的生命安全时,应该由产品的生产者承担赔偿责任。设计者需要证明自己设计的产品不存在设计缺陷(即 Bug),因此设计者需要保留设计依据和设计时的假设等各种证据,因此应对产品责任也可以被视为流程支持的一部分。

    次阅读
    2评论
    6赞同
    收藏
    分享
    2评论
    6赞同
    收藏
    分享

    评论·0

    头像头像
    提交评论
      加载中…

      热门资讯