精华内容
下载资源
问答
  • 2018功能安全(ISO26262)第二版

    热门讨论 2019-01-09 08:32:17
    对应第二版功能安全文档,提供给车载嵌入式的开发者,与君共学习
  • 功能安全专题之功能安全概念阶段

    千次阅读 多人点赞 2020-06-30 16:42:53
    **“当我们展望未来新技术的挑战时,采用统一的...在诸多的标准与规范中,ISO 26262(汽车功能安全标准),继承自 IEC 61508(通用电子电气功能安全标准),定义了针对汽车工业的安全(Safety)相关组件的国际标准。

    前言

    “当我们展望未来新技术的挑战时,采用统一的开发和应用标准至关重要。” — 通用汽车副总裁 Ken Kelzer, 2018。

    在诸多的标准与规范中,ISO 26262(汽车功能安全标准),继承自 IEC 61508(通用电子电气功能安全标准),定义了针对汽车工业的安全(Safety)相关组件的国际标准。简单的说,ISO 26262通过指导与规范化的形式,对汽车电子产品,从概念阶段到最后的产品报废阶段,提出了标准化的要求。更进一步的是,ISO 26262细化了如何控制一个汽车电子产品或组件的人身伤害风险在可接受的范围,及文档化整个分析、设计、开发、测试及生产过程。
    ISO 26262的历史可以追溯到2011年,第一版的ISO 26262标准发布。第一版标准包含10个部分:

    • Part 1: 词汇(Vocabulary)
    • Part 2: 功能安全管理(Management of functional safety)
    • Part 3: 概念阶段(Concept phase)
    • Part 4: 系统级的产品开发(Product development at system level)
    • Part 5: 硬件级的产品开发(Product development at hardware level)
    • Part 6: 软件级的产品开发(Product development at software level)
    • Part 7: 生产,运营(Production and operation)
    • Part 8: 支持过程(Supporting processes)
    • Part 9: 面向ASIL及面向安全的分析(Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyes)
    • Part 10: ISO 26262指南(Guidelines on ISO 26262)

    相对于2011版的ISO 26262,发布于2018年的第二版标准修改了Part 7的名字为:

    • Part 7: 生产,运营,维护及报废(Production, operation, service and decommissioning)

    同时还增加了2个部分:

    • Part 11: 半导体厂商应用ISO 26262的指南(Guidelines on application of ISO 26262 to semiconductors)
    • Part 12: 适用于摩托车的ISO 26262(Adaptation of ISO 26262 for motorcycles)

    在ISO 26262的Part 3中,介绍在产品开发的早期阶段的活动及用于保障功能安全的开发流程。这个部分包含了相关项的定义(Item Definition),危害分析与风险评估(Hazard Analysis and Risk Assessment)的内容。本文将从基本概念出发,介绍ISO 26262 : 2018 Part 3相关的流程,分析方法及相关技术。

    1 基本概念

    ISO 26262中的概念众多(2018版185个),无法在一篇文章中一一描述,所以在本节中,只针对Part 3中涉及到的重要概念进行解释说明。其中可以涉及到到的其它名词,都符上英文名词,便于在标准中查找。

    1.1 相关项定义(Item Definition)

    Part 3的第一个活动是相关项定义(Item Definition)。相关项定义对于应用ISO 26262到产品中非常重要,参与到产品开发人员和咨询人员需要对产品有深入的了解,而相关项定义则提供了理解产品所必需的信息。相关项(Item)在标准的Part 1中定义如下:

    • 应用了ISO 26262开发标准,实现了整车级的某个功能或者某个功能的一部分的系统或者系统的组合(System or Combination of Systems)

    而相关项定义(Item Definition)是为了描述清楚:

    • 相关项(Item)的功能,依赖关系,与驾驶员、周围环境以及其它整车级相关项的交互关系
    • 提供足够的信息用于理解相关项(Item),以便于后续过程中的活动能够执行

    1.2 相关项的构成

    一个相关项(Item)可以分解为1个或多个系统(System),并向外提供1个或多个功能(Function)。系统可以由多个子系统(Sub-system)构成,也可以分解为多个组件(Component)。构成一个系统或子系统的组件至少是3个:负责输入信号的传感器(Sensor),负责信号处理及逻辑控制的控制器(Controller)及负责输出的驱动器(Actuator)。一个组件(Component)可以由1个或多个软件单元(Software Unit)或1个或多个硬件(Hardware Part)构成。下图给出了这些概念的逻辑关系:
    在这里插入图片描述

    1.3 危害分析与风险识别(Hazard Analysis & Risk Assessment)

    危害分析与风险识别(以下简称HA & RA)的主要目的在于以下2个方面:

    • 识别危害与危害事件(Hazard and Hazardous Event),相关项的异常行为会导致这些危害事件
    • 为预防与缓解识别出来的危害事件,推导出相应安全目标(Safety Goal)及其ASIL评级,来避免不合理的风险

    ISO 26262:2011中,HA & RA的输入主要是相关项定义(Item Definition)影响分析(Impact Analysis)。影响分析指出了2种可能的进入HA & RA的初始条件:

    • 从产品的Idea和期望的功能开始,把相关项视为全新开发而进行HA & RA
    • 由于产品本身的功能修改或者运行环境变化,从影响分析(Impact Analysis)开始进行HA & RA

    从2018版开始,关于影响分析的部分被划分到Part 2 功能安全管理中,因此在2018版中,只有相关项定义作为HA & RA的输入。
    相关项定义的过程中,已经考虑了产品的功能、性能及可能的失效带来的后果(如已知的失效模式),但并没有这些需求进行分类。通过HA & RA识别产品的安全目标,将这部分需求同产品自身功能区别开,纳入功能安全管理的流程(如下图所示)。因此,HA & RA对于产品的后续开发活动有重要的意义。
    在这里插入图片描述

    1.4 危害与危害事件(Hazard and Hazardous Event)

    危害(Hazard) 是指由于产品功能的失效,作为潜在的原因,会导致发生人身伤害。但这种危害只是一种可能性,把危害和危害发生的场景(Operation Situation) 结合起来,形成危害事件(Hazardous Event),才能对其进行分级(如,可接受或不可接受)。对危害事件的分级主要考虑以下3个方面:严重度(Severity)暴露度(Exposure)可控度(Controllability)。在HA & RA过程中,分别对这3个方面进行打分:严重度(0 - 3,伤害的严重程度逐渐增加),暴露度(0 - 4,暴露在危险环境中的程度逐渐增加),可控度(0 - 3,危害发生时的可控度逐渐降低)。这3个数值中,经过评估任一数值取值为0,或者相加后的数值小于7,则认为这个危害事件的风险可接受,即相关的功能开发按照QM管理即可;但如果相加的数值大于等于7,则认为风险不可接受,对这个危害事件要分配 ASIL(Automotive Safety Integrity Level) 等级。ASIL分为4个等级,分别对应相加数值的7,8,9和10。ASIL与严重度、暴露度和可控度的对应关系可以参考下表:
    ASIL

    1.5 安全目标(Safety Goal)

    对于识别出的危害事件,进行细致的分析,并制定安全目标(Safety Goal)。安全目标在功能安全产品开发中,处于最上层的需求。安全目标与危害事件之间,可以是1:N或N:1(N大于等于1)的关系。安全目标可以用自然语言的形式来描述,通常是如下的模式化形式:

    • 避免(Avoid to),如,避免近光灯非预期的熄灭
    • 阻止(Prevent to),如,阻止安全相关提示信息在2秒内关闭
    • 应该(Should),如,收到胎压不足的警告信号后,胎压不足警告灯应该亮起

    每个安全目标都有对应的ASIL评级,安全目标的ASIL等级取决于与之相关联的风险事件的最高ASIL等级。可以为每个安全目标分配故障响应时间间隔(Fault Tolerance Time Interval),用以规定检测违反安全目标的故障和安全机制响应时间的最大间隔。安全目标可以用如下的表格的形式表示:
    在这里插入图片描述

    1.6 功能安全需求(Functional Safety Requirement)

    功能安全需求(Functional Safety Requirement,FSR)派生自安全目标,一个安全目标至少派生一条功能安全需求。派生出的功能安全需求有无歧义,可理解,无矛盾,可实现及可测试等要求。派生的过程中,功能安全需求独立于系统的技术架构,还要给功能安全需求分配唯一的ID,当前状态及对应ASIL等级属性。下面是一个表格形式的功能安全需求的例子:
    在这里插入图片描述

    1.7 功能安全概念(Functional Safety Concept)

    功能安全概念(Functional Safety Concept)是Part 3的最后一个活动。虽然在产品开发尚未进入系统设计阶段(Part 4),但此时需要假设一个系统架构(System Architectural Design),因为功能安全概念需要在整车的架构上实现。功能安全概念阶段需要描述必要的功能安全需求,并分配这些安全需求到系统的功能要素(Element)上。在ISO 26262中,功能安全概念阶段要求达成以下目标:

    • 指定与相关项安全目标相符功能行为(Functional Behavior)或者降级的功能行为(Degraded Functional Behavior)。系统功能的降级是指如果由于故障不能正确的运行,需要系统工作在一个功能或性能受限的状态。一般系统降级要设计降级的策略,如近光灯系统,降级策略要求至少有一个灯可以工作。
    • 根据安全目标,指定针对合适的手段及时检测和控制相关的故障的限制条件
    • 在相关项的层面上,设计策略或者措施用来达成要求的容错能力,或者基于相关项本身、驾驶员或者外部措施以减轻相关故障造成的影响
    • 分配功能安全需求到系统架构或者外部措施上
    • 验证功能安全概念并指定功能安全确认标准,这里的验证是指对设计过程的验证(Verification),主要是检查设计过程的正确性。

    2 功能安全概念阶段相关技术

    为保障功能安全概念阶段的活动能够正确实施,对应每个活动都有一系列的实施方法。本节对涉及到的一些重要技术手段进行介绍。

    2.1 识别相关项(Identify Item)

    为了识别出相关项(Item)及针对相关项(Item)任何的功能开发之前,无论这些涉及到的功能,是否是功能安全相关的,都需要一个合适的出发点。在这里,系统工程(System Engineering)的方法论可以给出一个很有价值的方案。系统工程方法论中,为描述系统对外提供的服务,有一个针对系统上下文(System Context)建模的过程。通过模型化的系统上下文,可以表达出一个系统针对周围环境直接的影响,还可以得到系统的输入与输出信息流(包括数据流与控制流)。在这个阶段,在外部与系统交互的是系统参与者(System Actor)。
    通常系统工程中对系统建模采用SysML/UML,但系统上下文并没有作为独立概念在SysML/UML中存在,因此需要引入一种能够形象表达系统上下文的方法:SYSMOD。通过SYSMOD,我们就可以在SysML/UML中,以如下的方式定义一个车灯管理系统(Headlight Management System)的上下文:
    在这里插入图片描述

    2.2 明确相关项的边界

    一个车载系统或相关项,必然要和周边系统或驾驶员产生交互,它的边界就是一个非常重要的信息:哪些组件属于系统元素,哪些位于系统之外?这些信息要在相关项定义这个过程中识别出来(至少是一部分,因为有时项目初期产品的需求并不十分明确)。明确相关项边界的第一个任务是要明确系统交互的参与者(System Actor)。系统参与者在概念阶段应该是清晰的,否则就会陷入一个怪圈:如果系统的开发者对于系统的使用者无法识别清楚,那么该如何正确的建立系统的概念和理解呢?下面有几个方法可以快速的帮助识别系统的参与者:

    • 系统的参与者应该主要来自于需求分析
    • 系统的参与者应该是使用系统提供的服务或接口,与系统有直接交互的人员
    • 与正在开发的系统有交互的其它系统也应该被列为系统的参与者,并且进行分类,如,传感器,驱动器,外部系统,或者由于系统的运行,会受到影响的外部环境(光线、温度等),这些可以帮助我们更好的理解当前开发的系统,更容易的描述其提供的服务

    识别出系统的参与者之后,第二个任务要识别出参与者与系统之间的信息流。通过SysML/UML,我们可以建立系统参与者和相关项之间的连接(如使用Connector将2者相连),这表示系统的参与者提供信息流给系统,或者接收从系统提供来的信息流(如从传感器来的车速信号,或者输出到屏幕的视频信号)。同系统的参与者一样,我们需要在系统开发的早期识别出这些信息流,并用建模的形式把它们识别出来(可以使用SysML中的Information Item来表示,参考系统上下文图中的黑色三角)。以下几个方法可以用来识别系统中的信息流:

    • 哪些信息是系统参与者发送给相关项的,如系统上下文中的车辆信号、开关信号
    • 这些信息是否与我们正在实现的系统密切相关
    • 相关项如何集成到整车环境中,如与供电模块的连接
    • 相关项发送哪些信息到系统的参与者

    定义完系统的参与者与相应的信息流后,最后一个任务则是它们如何同相关项交互(包括输入及输出),即识别出系统的交互点(Interaction Point,系统上下文图中的带箭头的小正方形)。当我们使用Connector建立系统参与者与相关项之间的连接时,Connector与相关项的交点可以认为就是交互点。但这种识别方法不够精确,需要使用以下方法进行提炼:

    • 相关项使用哪些途径与外界交换信息
    • 已识别出的交互点是概念上的还是物理上的
    • 是否有哪些交互的路径可以合并的

    需要注意的是,在功能安全概念阶段,系统的交互点(Interaction Point)和系统接口(Interface)是不同的:系统交互点在这个阶段仍然是个抽象的概念,只用于识别相关项与外部环境之间存在交互;而接口则包含在交互点内,描述相关项对外要求或提供的服务,以及信息流的具体内容。接口的建模在系统设计过程中实施,如ASPICE流程中的SYS.2。

    2.3 需求定义技术(Techniques for Specifying Requirements)

    概念阶段的功能安全需求(Functional Safety Requirement)是后续功能安全开发活动的基础。产品开发的成功或失败依赖于功能安全需求的质量,大量的事故可以追溯到有缺陷的需求,如不完整的表述,错误的实现以及对不清晰的需求的错误理解。ISO 26262中需求可以分为4个等级(但不限于4个,可以根据需要再细分):功能安全目标,功能安全需求,技术安全需求及硬件/软件安全需求。好的需求对于产品质量、成本/时间、功能安全的实现及测试都有重要的意义,因此本节对需求的定义技术做一些基本的描述。
    需求定义通常由需求工程师进行。大多数成功的项目至少有2名资深的需求工程师,他们协同工作并相互检查对方的成果。需求开发过程中,最好也有其他的助理工程师加入,因为从组织的角度,需求开发过程中的知识积累需要传递给下游的工程活动,并且组织也需要培养更多的需求专家。需求开发要求的工程师技能要求一般包括以下几点:

    • 需求开发的经验。没有什么比经验更重要,经过多个项目的磨练后,有经验的工程师可以判断出哪些该做,哪些不该做。即使没有成功项目的经验,那么那些从失败的错误中获取的经验也十分重要。
    • 合作。需求工程师几乎和项目中的所有人员打交道,特别是在敏捷(Agile)开发团队中,还要和客户进行面对面的沟通。
    • 倾听和观察的技巧。需求工程师应该擅长从系统工程师或客户处发现细微的线索,用于挖掘缺失的需求。
    • 写作沟通能力。需求工程师的主要角色是将需求文档化,那就要求需求工程师能够清晰有组织的把需求表达出来,即使是一些复杂问题和想法。常用的手段包括图表化、数据流图、控制流图、用例图或状态图等。
    • 领域知识。对于正在开发的产品,需求工程师要具备相应的领域知识,如导航工程师就不是十分适合开发刹车或者燃油系统的需求。

    需求的表达方式除了采用MS Office系列(Word,Excel),还可以使用支持SysML的工具进行描述,除了具备直观的好处之外,还可以和后续的工程活动方便的追溯(见下节)。SysML中增加了需求图(Requirement Diagram)用于描述系统需求,如下图所示:
    在这里插入图片描述
    在工具中,每一个需求块(Block)会分配一个全局唯一的GUID,可以用于标识这个需求。但GUID通常与需求定义时分配的ID不一致且难于理解,因此针对需求块,SysML还提供了需求ID字段,用于与外部工具建立需求对应关系。另外,为方便在各个需求管理工具之间交换数据,通常会采用CSV格式的表格,通过导入/导出的形式进行数据传递。

    2.4 追溯性相关技术(Techniques for Traceability)

    作为消除系统性故障(Systematic Fault)的重要手段,可追溯性在功能安全相关设计的验证过程中是重点检查的内容。可追溯性在系统开发的不同阶段表现不同,如用例和需求之间,可以表现为实现关系(Realization);用例和用例之间,可以表现为包含、扩展(Include, Extend)等关系。可追溯性的表现形式可以有多种:

    • 基于ID的可追溯性
    • 基于SysML/UML关系图的追溯
    • 以及基于关系矩阵的追溯

    下图是一个使用SysML/UML关系图建立追溯性的例子,在图中通过手工连接的方式把用例和需求连接起来,优点是图形比较直观:
    在这里插入图片描述
    追溯图的形式能够同时表达的追溯范围有限,如果需求和用例较多,追溯图由于图中的元素太多,就不容易使用(如,查找是否有需求的遗漏),在这种情况下使用追溯矩阵(Traceability Matrix)就更合适。追溯矩阵可以在工程的全路径的任意2个连续的环节(如,需求和用例)中间建立直观的关系矩阵。如下图所示,图的横纵坐标分别表示需求与用例,箭头则表示实现(Realization)的方向,高亮的行表示需求有遗漏的情况:
    在这里插入图片描述
    建立了双向追溯之后,需求或者设计发生了变更,就可以通过追溯判定变更的影响范围。支持Baseline的SysML/UML工具,还可以基于Baseline进行差分。基于Baseline可以很容易的识别出需求和设计中发生了变更的部分,从发生了变更的部分出发,可以追溯到对应的上下游工程中,需要变更的内容,以确保一致性。

    2.5 危害识别与分析技术(Techniques for Hazard Identification and Analysis)

    常用的危害分析技术有20多种,几乎覆盖了包括了:概念,概要设计,详细设计,测试及运行在内的产品开发的各个阶段。从方法论上来说,危害分析技术可以分为2大类:内推法(Inductive)和外推法(Deductive):

    • 内推法从系统中某个组件的故障出发,自下而上的推导,在整车的级别上产生的影响是否违反功能安全目标
    • 外推法从违反功能安全目标的失效开始,自上而下的推导可能产生这个影响的组件故障

    在功能安全概念阶段,危害分析的主要目的是保障完整及正确的派生功能安全需求。在ISO 26262:2018, Part 3中提到了3种危害分析方法:FMEA (Failure Mode and Effects Analysis),HAZOP (Hazard and Operability Analysis) 和FTA (Fault Tree Analysis)。这三种分析方法的分类见下图:

    在这里插入图片描述
    以下介绍一下FMEA的基本分析技巧。FMEA用于分析系统中的关键组件的失效是否会影响功能安全目标,影响功能安全目标的失效是否设计了安全机制,相应的安全机制可以作为功能安全需求而记载到对应的文档中。FMEA的主要成果物为FMEA Worksheet,下图是来自于Ford的FMEA Handbook,图中给出了FMEA的主要的分析过程:
    在这里插入图片描述
    FMEA的输入有多种,其中比较重要的是功能块图(Functional Block Diagram)和参数图(Parameter Diagram)。功能块图简化了系统设计和支持的服务,在功能安全概念阶段可以帮助快速建立对产品的理解。功能块图展示了子系统之间的关系和接口,同时也指示了系统所必须提供的功能。下图给出了系统的功能块图的例子:
    在这里插入图片描述
    对于功能块图中的任一功能,对其进行危害分析时,需要明确该功能的输入信号,运行环境,配置信息及期望的和错误的输出。把这些信息整合,可以如下图所示的参数图(Parameter Diagram):
    在这里插入图片描述
    通过对这些参数的分析,可以得出导致某个功能出现故障的基本原因。在后续的分析过程中,针对故障原因,设计合理的检测和消除机制,可以有效的提升系统的安全性。

    3 总结

    本文从ISO 26262:2018,Part 3中的基本概念出发,介绍了该部分涉及到重要概念及开发过程中需要用到的基本技术。在ISO 26262流程中,概念阶段(包括功能安全概念和技术安全概念)是最重要的阶段,这个阶段出现的任何纰漏,都会影响后续的功能安全开发活动。由于ISO 26262采用的是V模型,概念阶段变更引起的工作量会十分巨大。本文希望通过一些重要概念的解释和实用技术的说明,理清功能安全概念的过程,帮助功能安全开发人员,实现正确的功能安全概念。

    4 参考文献

    [1]: ISO26262 International Standard, Second Edition, 2018
    [2]: AUTOSAR Specifications
    [3]: FMEA Handbook Version 4.1, Ford Motor Company

    展开全文
  • 功能安全--安全分析

    千次阅读 2019-11-14 17:49:24
    在ISO26262功能安全中,有多个地方需要进行安全分析,安全分析的质量很重要的决定了功能安全项目的成败,本文针对ISO26262中提到的各种安全分析进行汇总说明(HARA、FMEA、FTA、FMEDA、SWFMEA、DFA)。 1. HARA 在...

    在ISO26262功能安全中,有多个地方需要进行安全分析,安全分析的质量很重要的决定了功能安全项目的成败,本文针对ISO26262中提到的各种安全分析进行汇总说明(HARA、FMEA、FTA、FMEDA、SWFMEA、DFA)。

    1. HARA

    在概念阶段,功能安全要求进行HARA分析。

     HARA(危害分析与风险评估)目的是识别项目的功能故障引起的危害,对危害事件进行分类,然后定义与之对应的安全目标,以避免不可接受的风险。

    HARA分析步骤:

    SEC说明: 

    ASIL等级说明: 

    QM指的是 质量管理,表示此项功能不影响安全,通过质量管理保证即可。

     举例说明:

    HARA分析示例
    危害事件场景分析SECASIL
    EPS按照非预期的方向转向在城市道路,车辆正常匀速行驶(E4),车辆方向按照非预期转向,此时驾驶员很难控制(C3),道路两边人员较多,可能造成路人或者驾驶员的伤亡(S3)343D

    2. FMEA

    在系统阶段,功能安全要求针对各种失效模式进行分析。

    FMEA是一种自下而上的归纳分析方法,用于识别系统失效(failure),找出失效原因(Fault),以及分析失效影响(Effect)。

    分析步骤(典型七步法):

    (参考:http://www.ts16949rz.org/fmeapx/2395.html) 

     目前新版的使用AP值代替了原来的RPN方法,以下进行说明。

    SOD说明:

     

    AP说明:

    APHML
    说明高优先级,表示需有必要措施(shall),以改进预防或探测控制中优先级,应有必要的措施(should),以改进预防或探测控制低优先级,可有(could)措施进行改进预防或探测控制

     AP优先级定义:

    典型FMEA表格(新老版的):

     

    3. FTA

    在系统阶段,ISO26262还要求进行FTA(故障树分析);

    FTA是一种自上而下的演绎分析方法,用于识别失效原因及失效间的关系,目前针对FTA也只是做定性分析。

    分析步骤:

    1. 确定顶事件,一般为在整车角度描述的影响到安全目标的事件,如针对EPS,顶事件可定义为非驾驶员意图的转向,针对MCU,顶事件可定义为非预期的加速等。

    2. 分解中间事件,针对顶事件,根据系统组成或特点,进行分解,系统外界以及系统内部一般都需要考虑在内。

    3.基本事件,中间事件继续向下分析,得到无法再分解的事件,他们是组成系统顶事件失效的根本原因。

    常用的符号:

    典型FTA图: 

    4.FMEDA 

    在硬件设计阶段,ISO26262要求进行定量的安全分析。

     由于功能安全标准中已有对其进行较为详细的介绍,本文更多的是从中进行汇总摘要。

    故障类别:

    失效分析过程:

     

     失效率:

    λS P F — — —与硬件要素单点故障相关联的失效率;
    λRF — — —与硬件要素残余故障相关联的失效率;
    λMPF— — —与硬件要素多点故障相关联的失效率;
    λS — — —与硬件要素安全故障相关联的失效率。

     

     

     单点故障度量:

    潜伏故障度量:

    总体计算过程:

     5. SWFMEA

    在软件阶段,ISO26262要求对软件架构进行安全分析,此处也是定性分析。

    SWFMEA分析的目的在于找出影响到功能安全的软件失效,从而可以增加探测或诊断覆盖来提高系统的安全。

    SWFMEA,分析过程可参考系统FMEA,只是这里的分析对象略有差异,以下针对差异进行说明。

    SWFMEA,主要针对架构元素进行分析,如针对接口,分析其传入的参数的异常情况、错误调用接口情况等;针对函数,分析其传参的异常情况、调度的异常情况(没调用、调用过快、过慢等)、数据的一致性分析、资源消耗异常等情况。

    安全机制的覆盖度,可参考ISO26262标准附录。

    6.DFA

    DFA指的是相关性分析,ISO26262要求从三个层面(系统、硬件、软件)分析,找出系统中的共因以及级联失效。

    若系统进行了ASIL分解,则DFA必须分析,以此作为系统分解后的证据。

    级联失效:

    任一失效,系统都会失效;

     

    共因失效:

    失效后,冗余措施不起作用。

     系统分析角度:

            系统架构、系统边界、系统人员、系统环境、系统开发生产维护等过程。

    硬件分析角度:

          硬件架构、硬件选型、硬件人员、供电电源等。

    软件分析角度:

          CPU共享资源、软件架构、软件人员、软件工具、算法方案等。

    展开全文
  • 功能安全学习笔记002-功能安全的定义

    万次阅读 多人点赞 2018-04-07 21:52:59
    1,功能安全的定义1.1 本质安全与功能安全为了了解功能安全的概念,先得熟悉下 和“本质安全”和“功能安全”的概念。假如以铁道的路口为例,比较一下基于两种安全概念的避免路口事故的方法。这里避免路口事故就是...
    1,功能安全的定义

    1.1 本质安全与功能安全

    为了了解功能安全的概念,先得熟悉下 和“本质安全”和“功能安全”的概念。

    假如以铁道的路口为例,比较一下基于两种安全概念的避免路口事故的方法。这里避免路口事故就是安全目标,为了实现这个目标,可进行如下操作:

    首先,如果把铁道路口撤掉,直接改造成立交桥的形式,让火车和汽车都走各自的路,这样就不会发生人或者车辆横穿铁道口的事故了。像这样,根据系统的特性把危险源直接除掉的方法是「本质安全」。

                                                                               

    其次,假如我们在铁道路口设置信号灯和道口自动栏杆,当火车来临时前闪红灯,同时将栏杆放下,避免行人或者车辆通过。像这样通过栏杆的拦截功能及预警灯来抑制事故风险的技术叫做「功能安全」。在这里信号灯和自动栏杆一种安全机制(Safety Mechanism)。理想的情况是不管什么场合都采用 「本质安全」,但事实上,在很多场合里,由于系统自身的原因,不可能把危险源除掉。特别是像车载电控系统这样非常复杂的电子化系统,以上所述的本质安全很难被实现和应用。因此我们只能采用功能安全,它的目的就是在本质安全无法达到时,尽可能的通过增加安全机制去提高安全等级,实现安全目标。

    1.2 电子控制器的功能安全

    对于汽车而言,可将汽车看成一个“机器人”,驾驶员给这个“机器人”发送信号,比如踩踏板加油,汽车收到命令然后执行:电喷系统增加喷油,发动机输出扭矩增加,实现车辆加速。

    对于传统汽车而言,它的结构简单,且大多数命令都是通过机械方式来实现的,如老式汽车的机械式节气门等,其失效的可预见性大;而现在汽车,其电子电气化增强,驾驶员的指令会先转换成相关信号,然后这些信号传递给控制器的处理芯片,然后最终驱动相关的执行器来执行,其失效的可预见性大大降低。


       

    正因为现代汽车随着电子电气化的程度越来越高,其整车的安全性很大程度就取决于电子控制器的安全性,比如发动机控制器ECU,变速箱控制器TCU,车辆稳定性控制器ESP等等。而且电子控制器失效的可预见性非常低,比如芯片/电路受外界干扰等,这很难预料什么情况会出问题。  因此必须考虑电子控制器失效了会怎么办的问题。

    1.3 功能安全考虑的角度

    针对电子控制器失效了怎么办这个问题,首先得确定一个角度。比如极端高温情况下的ECU自燃,爆炸等这种系统本身带来的风险,这种风险不在功能安全的考虑范围内。

    从产品安全的角度来说,可将其安全分为传统安全以及由电子/电气功能安全,传统安全包括:与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害,除非危害是直接由电子电气安全相关系统的故障行为而引起的。传统安全不在功能安全的考虑范围之内。

      

    根据国际上知名的安全协会的定义,比如英国的MISARA(The Motor Industry Software Reliability Association 汽车工业软件可靠性协会),比如德国的德国VDA协会(VDA(Verband der Automobilindutrie)德国汽车工业协会)他们是从车辆可控性的角度对功能安全提出要求。而IEC-61508强调从人身安全(还可以考虑设备安全)角度提出需求。

    因此从车辆可控性和人身安全两个层面上考虑功能安全就有了着陆点。比如考虑是不是有非驾驶员期望的加速等,而非驾驶员期望的减速其实是降低了安全边界,但车辆扔被驾驶员控制着。这就是为什么ECU不对相关控制器的减扭做监控的原因。

    1.4 ISO26262中对功能安全的定义

    ISO 26262是专门用作提升汽车电子电气产品功能安全的国际标准,它派生于电子、电气及可编程器件功能安全基本标准IEC61508。那26262是如下定义功能安全这个概念的:

    English definition:absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems;

    没有由电子、电气系统故障行为导致的危险所引起的不合理风险。

    我们来分解下这段话:

    A.没有风险:absence of risk

    B.没有不合理风险 unreasonable

    C.没有由电子、电气系统故障行为导致的危险所引起的不合理风险

    其中的关键词是不合理风险,什么是不合理风险呢,比如车辆行驶时安全气囊蹦出来了,这是不合理风险,这是功能安全需要避免的问题。

                                                    

    总体来说,功能安全是指避免由系统功能性故障导致的不可接受的风险。它关注的是系统发生故障之后的行为,而不是系统的原有功能或性能。因此功能安全的目的就是当系统发生故障后,将系统进入安全的可控模式,避免对人身、财产造成伤害。

    2,ASIL汽车安全完整性等级

    2.1 危险事件的确定

    对电子控制器ECU来说,引起失效主要是两个方面:软件和硬件。

    软件失效:比如没有考虑分母可能为0;变量公式定义错误,导致精度丢失;

    硬件失效:如下图所示可以分为传感器失效;ECU硬件失效(比如CPU或者RAM/ROM失效);执行器失效;

            

    依据ISO 26262标准进行功能安全设计时,首先识别系统的功能,并分析其所有可能的功能故障(Malfunction)或失效,可采用的分析方法有HAZOP,FMEA、头脑风暴等。

    功能故障在特定的驾驶场景下才会造成伤亡事件,比如近光灯系统,其中一个功能故障就是灯非预期熄灭,如果在漆黑的夜晚行驶在山路上,驾驶员看不清道路状况,可能会掉入悬崖,造成车毁人亡;如果此功能故障发生在白天就不会产生任何的影响。

    所以进行功能故障分析后,要进行情景分析,识别与此故障相关的驾驶情景,比如:高速公路超车、车库停车等。分析驾驶情景建议从公路类型(国道,高速),路面情况,(湿滑、冰雪);车辆状态(转向、 超车、制动、加速等),环境条件(风雪雨尘、夜晚、隧道灯),人员情况(乘客、路人)等几个方面去考虑。功能故障和驾驶场景的组合叫做危害事件(hazard event)。

    危害事件确定后,根据三个因子——严重度(Severity)、暴露率(Exposure)和可控性(Controllability)评估危害事件的风险级别——也就是ASIL等级。

    2.2 ASIL等级

    ASIL等级的定义是为了对失效后带来的风险进行评估和量化以达到安全目标,其全称是Automotive Safety Integration Level--汽车安全完整性等级。这个概念来源于IEC61508,其通过失效概率的方式定义了安全完整性等级(SIL)。但是在汽车界只有硬件随机失效可以通过统计数字评估失效概率,软件失效却难以量化,因此26262根据汽车的特点定义了ASIL。

    如上节所述ASIL的评定,一般是在产品概念设计阶段对系统进行危害分析和风险评估,识别出系统的危害,如果系统的安全风险越大,对应的安全要求级别就越高,其具有的ASIL的等级也越高。ASIL分为QM,A、B、C、D五个等级,ASIL D是最高的汽车安全完整性等级,对功能安全的要求最高。

    2.3 危险分析和风险评定

    对于汽车系统,特定危险的风险决定于以下三个因素:

    A.危险事件所导致伤害或损失的潜在严重性 (Severity of failure, S) 

    B.指人员暴露在系统失效能够造成危害的场景中的概率OR理解为危险事件可能发生的驾驶工况的可能性 (probability of exposure, 简称E) 

    C.危险所涉及的驾驶员和其它交通人员通过及时的反应避免特定伤害或损失的能力 (controllability, 简称C)

       

    然后分别将严重性S、可能性E和可控性C分成4个等级,如下表所示,其中QM代表与安全无关:

     


    按照以上的划分并进行组合相加得到5个ASIL等级(QM,A,B,C,D),原则是:

    A. 基本可控C0的组合不考虑;

    B. 无伤害S0的组合不考虑;

    C. 其余组合相加等于7分为ASIL A,等于8分为ASIL B,等于9分为ASIL C,等于10分为最高等级ASIL D;ASIL A、B、C、D都是与功能安全相关的(Safety Relevant Function)

    D. 其余的得分安全评定为QM,代表与安全无关的功能(Non Safety Relevant Function)

       


    下面举几个例子进行说明:

    1,EPB(Electrical Park Brake)电子手刹

    以电子手刹的驻车功能为例,当驻车时,驾驶员通过按钮或者其他方式触发制动请求,EPB在汽车的后轮上施加制动力,以防止车非期望的滑行。该系统的危害有非期望的制动失效,非期望的制动启动。相同的危害在不同场景下风险也是不一样的,因此也要对不同场景进行分析。分析如下表所示:

      

    得出了EPB系统的安全目标为:防止非期望的制动,ASIL等级为D

    根据上面的分析,不难得出其它例子的ASIL 等级,比如:

     


    2.4 功能安全目标的分解

    通过上危害分析和风险评估,我们得出系统或功能的安全目标和相应的ASIL等级,当ASIL等级确定之后,就需要对每个评定的风险确定安全目标,安全目标是最高级别的安全需求。安全目标确定以后就需要在系统设计,硬件,软件等方面进行设计和实施,验证。

    从安全目标可以推导出开发阶段的安全需求,安全需求继承安全目标的ASIL等级。如果一个安全需求分解为两个冗余的安全需求,那么原来的安全需求的ASIL等级可以分解到两个冗余的安全需求上。因为只有当两个安全需求同时不满足时,才导致系统的失效,所以冗余安全需求的ASIL等级可以比原始的安全需求的ASIL等级低。ISO 26262标准的第9章给出了ASIL分解的原则。ISO 26262中提出了在满足安全目标的前提下降低ASIL等级的方法——ASIL分解,这样可以解决上述开发中的难点。

    ASIL 分解的一个最重要的要求就是独立性,如果不能满足独立性要求的话,冗余单元要按照原来的ASIL等级开发。所谓的独立性就冗余单元之间不应发生从属失效(Dependent Failure),从属失效分为共因失效(Common Cause Failure)和级联失效(Cascading Failure) 两种。共因失效是指两个单元因为共同的原因失效,比如软件复制冗余,冗余单元会因为同一个软件bug导致两者都失效,为了避免该共因失效,我们采用多种软件设计方法。级联失效是指一个单元失效导致另一个单元的失效,比如一个软件组件的功能出现故障,写入另一个软件组件RAM中,导致另一个软件组件的功能失效。

    具体降解的方法如下所示,比如应按照下列之一对一个 ASIL D 的要求进行分解: 

    1)   一个ASIL C(D)的要求和一个ASIL A(D)的要求;或 

    2)   一个ASIL B(D)的要求和一个ASIL B(D)的要求;或 

    3)  一个ASIL D(D)的要求和一个QM(D)的要求,


         

    其它ASIL等级分解可如下图所示:



          

    以上简单的介绍了下功能安全的定义,以及ASIL等级的评定和分解。所学有限,如有失误,还请指正,感激不尽。




     






















    展开全文
  • 什么是功能安全

    万次阅读 2018-07-06 09:15:33
    什么是功能安全(FS)?在现代工业控制领域中,可编程电子硬件、软件系统的大量使用,大大提升了自动化程度。但由于设备设计中的缺失,以及开发制造中风险管理意识的不足,这些存在设计缺陷的产品大量流入相关行业的...

    什么是功能安全(FS)?

    在现代工业控制领域中,可编程电子硬件、软件系统的大量使用,大大提升了自动化程度。但由于设备设计中的缺失,以及开发制造中风险管理意识的不足,这些存在设计缺陷的产品大量流入相关行业的安全控制系统中,已经造成了人身安全、财产损失和环境危害等灾难频出。为此,世界各国历来对石化过程安全控制系统、电厂安全控制系统、核电安全控制系全领域的产品安全性设计技术非常重视,并且将电子、电气及可编程电子安全控制系统相关的技术发展为一套成熟的产品安全设计技术,即“功能安全”技术。

    欧美已经颁布了成套的功能安全相关产品指令和设计标准,并深入到各个领域,如:汽车(ISO26262)轨道控制(EN 5012X)、核电(EN 61513)、工业装备及机器控制(EN 62601, EN ISO 13849-1/2)、过程控制(EN 61511)等,国际上,IEC 形成的 IEC 61508,IEC 61511 等系列标准已经逐步成为各国家、行业广泛认可的基本功能安全标准,中国也仿效并形成了的相应国家标准,其他行业性功能安全标准也在参照并将逐步形成为国家行业性标准。

    ISO26262    

    ISO26262是从电子、电气及可编程器件功能安全基本标准IEC61508派生出来的,主要定位在汽车行业中特定的电气器件、电子设备、可编程电子器件等专门用于汽车领域的部件,旨在提高汽车电子、电气产品功能安全的国际标准。

    ISO26262从2005年11月起正式开始制定,经历了大约6年左右的时间,已于2011年11月正式颁布,成为国际标准。中国也正在积极进行相应国标的制定。

    安全在将来的汽车研发中是关键要素之一,新的功能不仅用于辅助驾驶,也应用于车辆的动态控制和涉及到安全工程领域的主动安全系统。将来,这些功能的研发和集成必将加强安全系统研发过程的需求,同时,也为满足所有预期的安全目的提供证据。

    随着系统复杂性的提高,软件和机电设备的应用,来自系统失效和随机硬件失效的风险也日益增加,制定ISO 26262标准的目的是使得人们对安全相关功能有一个更好的理解,并尽可能明确地对它们进行解释,同时为避免这些风险提供了可行性的要求和流程。。

    ISO 26262为汽车安全提供了一个生命周期(管理、开发、生产、经营、服务、报废)理念,并在这些生命周期阶段中提供必要的支持。该标准涵盖功能性安全方面的整体开发过程(包括需求规划、设计、实施、集成、验证、确认和配置)。

    ISO 26262标准根据安全风险程度对系统或系统某组成部分确定划分由A到D的安全需求等级(Automotive Safety Integrity Level 汽车安全完整性等级ASIL),其中D级为最高等级,需要最苛刻的安全需求。伴随着ASIL等级的增加,针对系统硬件和软件开发流程的要求也随之增强。对系统供应商而言,除了需要满足现有的高质量要求外还必须满足这些因为安全等级增加而提出的更高的要求。


    应用     

    系统安全可以从大量的安全措施中获得,包括各种技术的应用(如:机械,液压,气动,电力,电子,可编程电子元件)。尽管ISO26262是相关于E/E系统的,但它仍然提供了基于其他相关技术的安全相关系统的框架。

    ISO26262:

    -提供了汽车生命周期(管理,研发,生产,运行,服务,拆解)和生命周期中必要的改装活动。

    -提供了决定风险等级的具体风险评估方法(汽车安全综合等级,ASILs)

    -使用ASILs方法来确定获得可接受的残余风险的必要安全要求。

    -提供了确保获得足够的和可接受的安全等级的有效性和确定性措施。

    功能安全受研发过程(包括具体要求,设计,执行,整合,验证,有效性和配置),生产过程和服务流程以及管理流程的影响。

    安全事件总是和通常的功能和质量相关的研发活动及产品伴随在一起。ISO26262强调了研发活动和产品的安全相关方面。

    ISO26262主要用于安装在最大毛重不超过3.5吨的乘用车上的一个或多个E/E系统的安全相关系统。ISO26262唯一不适用于为残疾人设计的特殊目的车辆的E/E系统。系统研发早于ISO26262出版日期的,也不在标准的要求之内。ISO26262表述了由E/E安全相关系统,包括这些系统的互相影响,故障导致的可能的危险行为,不包括电击,火灾,热,辐射,有毒物质,可燃物质,反应物质,腐蚀性物质,能量释放及类似的危险,除非这些危险是由于E/E安全相关系统故障导致的。


    行各业都会制定标准,指导未来发展并限定最低准入门槛。在汽车电子行业,这一标准就是ISO 26262,它将功能安全定义为:

    “避免因电气/电子系统故障而导致的不合理风险”。

    不同领域的标准并不完全一致,例如针对电气和电子系统的IEC 61508以及飞行器电子硬件的DO-254都有各自的定义方式。更需值得注意的是,它们都拥有专用术语,并提供了包括目标参数在内的工程研发指导。因此,开始产品研发前确定目标市场并制定合适的流程至关重要,因为中途修改研发流程必然会导致效率低下。图1展示了硅片IP的不同应用标准。实际操作中,如果需要满足多套标准,则可以求同存异,先列出专属需求,再执行质量管理等通用准则;最一开始就要做到安全第一。

    什么是功能安全?汽车功能安全的设计方案

    图1:硅片IP的功能安全标准

    实际操作中,功能安全系统必须由独立评估员认证,符合所有安全标准。实现功能安全需要具备预测能力的故障模式,实时判断系统状态是功能完整,部分功能损坏,还是系统必须关闭进行重启或重置。

    并不是所有故障都会立刻引发严重事故。比如,汽车动力转向系统故障可能会导致突发性的错误转向,但是由于电气和机械设计天然的时间延迟,故障并不会马上产生后果,这一延迟通常是几毫秒以上,ISO 26262将之定义为容错时间间隔,间隔长短取决于潜在的事故类型和系统设计。所以,不难理解,对系统安全要求越高,产生不安全事件的故障就越应该避免。

    理想情况下,功能安全不会影响系统性能;但现实生活中,现行的许多安全措施都会严重影响系统性能、功率和面积(PPA)。如何在保证功能安全的前提下减轻对系统性能的不利影响以及设计制造成本的上升,是设计师们面临的一大难题。

    为什么需要功能安全?

    芯片IP的功能安全曾是非常小众的领域,只有少数汽车、工业、航空航天和其他类似市场的芯片与系统开发商感兴趣。然而,随着过去几年各类汽车应用的兴起,情况已经发生巨大变化。除了汽车外,还有很多其他行业也能从电子器件的增加受益,当然保障功能安全是大前提。医疗电子和航空就是两个典型例子。

    自动驾驶过去几年吸引了不少人的眼球,但一直是雾里看花;如今,随着高级驾驶辅助系统(ADAS)及富媒体车载信息娱乐系统(IVI)的普及,尽管高度自动化驾驶的时代依然遥远,但自动驾驶汽车的前景已变得愈发清晰。尺寸形状各异的无人机和日益普及的物联网也是亟需功能安全的领域,ARM 的技术将成为一大助力。

    ARM功能安全技术

    与其他技术市场一样,新兴的功能安全应用也需要半导体的驱动;这并不是纸上谈兵,日新月异的产品创新已经引起了ARM合作伙伴的浓厚兴趣。多数功能安全嵌入式系统都需要具备安全防护及实时处理两大核心要素,ARM Cortex-R系列处理器为此需求量身定制,为嵌入式系统提供高性能运算解决方案,确保产品的高可靠性、高可用性、容错、以及/或强大实时自主判断能力。这些特性为实现ADAS和IVI系统的高安全完整性打下基础,不仅可以执行关键行为处理,应对安全相关的中断事件,与其他系统通讯,还可以对集成度较低的复杂功能进行监管。

    什么是故障?

    故障可能是系统性的(如规范制定和设计过程中的人为因素);也有可能与使用的工具有关。减少故障的一种方法是执行严苛的质量管控流程,必须包括详细的规划、审查和量化评估。合理的规划使用工具认证非常重要,管理与追踪需求变更的能力也同样关键。ARM的Compiler 5编译器已经通过南德集团(TÜV SÜD)认证,助力安全研发,客户无需对编译器进行额外认证。

    还有一种故障类型被称为随机硬件故障。它们可能是图2显示的永久性故障,比如短路;也有可能是由于天然辐射而造成的软性故障。这类故障可以利用集成在软硬件的方案进行处理,因此系统级的技术也同样重要。举例来说,逻辑内建自测试(BIST)可以应用于系统启动和关闭,区分软性和永久性故障。

    什么是功能安全?汽车功能安全的设计方案

    图2:故障类型

    应对措施

    故障检测和控制措施的选择和设计是流程设计师最喜欢的环节,因为他们可以同时用系统级和微架构级的技术大展手脚。建立故障模式概念和效果分析(FMEA)是个不错的开始,列举出所有可能出现的故障模式及其后果的严重程度。有了这些信息,加上设计师对复杂系统的深入理解,即可鉴别出最严重的故障模式,并设计出应对措施。

    应对潜在故障的方法较多,下面列出了一些最常用的技术:

    ·多样化检查器:使用另一条电路检查主电路是否发生故障。举个例子,检查器可以为中断控制器计数,持续记录人为及系统引起的中断总数。

    ·完整锁步复制:该技术主要用于Cortex-R5处理器,对一个IP元件(如一个处理器)进行多次实例化,利用循环产生操作延迟,生成时间和空间冗余。大容量存储通常由多个实例共享,以降低所需面积。尽管这一技术非常可靠,但也极为昂贵。

    ·选择性硬件冗余:这个方案里,只有硬件的关键部分可以复制,如仲裁器。

    ·软件冗余:硬件冗余通常非常复杂,而且会产生间接成本,是对资源的不合理使用。硬件运算的替代方法就是,在多个处理器内核上运行同一次计算,检查结果是否匹配。

    ·错误检测和校正码是另一种为人熟知的技术,通常被用于保护存储器和总线。代码类型多种多样,但目标只有一个,既通过少量附加位获得更高冗余,无需复制所有底层数据。汽车系统中,这一尖端技术可以利用足够多的冗余检测出一个存储字的2位错误;并支持错误修正。

    故障日志

    检测出故障后就必须进行记录,以帮助监管软件判断系统的健康和安全状况。安全故障(如存储器修正)和危险故障(如不能挽回的硬件故障)必须分别记录。

    故障记录通常从故障计数开始,可以由系统级架构记录有信号事件(类似于中断)的数量;或者由IP计数器记录。为了解这些事件发生的原因,最好还能将过去的事件作为参考,判断当前时间的发生原因。为支持这一需求并进行调试纠错,可以允许一些IP捕捉额外信息,如被侦查的存储地址。因为该地址通常会由软复位保存,所以可以在系统启动和系统自检过程中被读取。

    有一点需要牢记,故障也可能发生在安全架构本身。与硬件故障不同的地方是,后者通常可以在使用过程中被很快发现,但安全检查器中的故障可能是潜伏的,它已经无法侦测危险故障,但故障却已经悄悄地蔓延开了。这样的故障被称为潜伏故障,定期测试检查器是个不错的方法。

    安全完整性等级

    不同的标准体系反应安全等级的方法也各不相同,但其主要目的是直观的反映功能的关键性。比如说,控制挡风玻璃雨刮、安全气囊或制动器的ECU,完整性必须高于控制车速表或泊车传感器的ECU,因为前方视野至关重要,突然刹车或气囊充气可能造成致命后果,驾驶员也会凶多吉少;而车速表或泊车传感器对安全停车的重要性就低得多了。

    换句话说,安全完整性等级是与人避免危险情况的必要性和能力相关的;而各项标准的作用就是指导人们如何定义安全完整性等级,并提供相关参数,帮助其对系统完整性进行量化。

    IEC 61508将安全完整性等级(SIL)分成4级,第4级为最高完整性。与之相似,ISO 26262提出了汽车安全完整性等级(ASIL),最低为ASIL A,最高为ASIL D。此外,就表二所示,针对ASIL B到ASIL D,ISO 26262分别就单点故障、潜伏故障和硬件故障概率指标(PMHF,业内也称及时故障)提出了建议参数。可检测故障的比例被称为诊断覆盖率。

    什么是功能安全?汽车功能安全的设计方案

    表1. ISO 26262的推荐标准

    尽管这些指标通常被视为标准要求,但在实际应用中,它们一般只被视为建议,供应商可以自行制定目标参数。最重要的目标是打造安全的产品,而不是在产品参数表上多加几个数字。让我们再次借用前面提到过的例子——挡风玻璃雨刮、制动器和安全气囊,这些元件的安全级别可能达到ASIL D,而车速表和泊车传感器可能是ASIL B或更低,具体级别取决于整体系统安全设计。

    无论诊断覆盖率多高,打造功能安全应用的时候都必须遵循合适的流程——这也是标准体系最大的益处。此外,无论采用何种功能安全措施,严格的质量流程都可以提升任何应用的整体质量。

    功能安全IP的设计流程

    开发功能安全应用IP时,“循规蹈矩”非常重要。这个过程必须从一开始就将安全纳入考虑,而且还必须营造支持安全的文化。

    完整的开发流程必须包含以下几个重要方面:

    ·安全管理:包括团队组织架构,具体内容如:明确不同职位的定义和职责、打造安全文化、定义安全生命周期,定义功能安全支持级别。安全生命周期的设定包括制定一份成功计划,选择合适的开发工具,确保团队接受充分的培训。

    ·需求管理和故障检测及控制措施(应对措施)的可追溯性。为精确实现需求追溯,需求本身定义必须要明确,精准,且具备唯一性。追溯等级取决于完整性的要求,文件可以高等级;产品则需要从故障检测到验证等各个环节面面俱到——计划过程不得空穴来风,必须经过详细验证。

    ·质量管理是需求追溯的拓展和延伸。勘误表必须得到妥善管理和使用。ARM在这一领域拥有丰富的经验。此外,流程的记录和传达也同样重要。

    安全文件包

    IP开发是ARM支持合作伙伴的一种途径,我们的合作关系并不会止于客户收到IP的那一刻。就功能安全相关的IP开发,ARM定义了2个安全文件包等级:

    ·最高至ASIL B的标准支持

    ·最高至ASIL D的延伸支持

    每个安全文件包都包含一份安全手册,详细说明遵循的流程、故障检测及控制功能、适用场景和其他信息。我们同时提供“故障模式及效果分析报告”,并提供案例分析,阐述如何用IP实现更高的诊断覆盖率;我们也为客户的独立分析提供芯片级的更多支持。此外,文件包也就ARM和被授权方的开发接口做出了明确定义。

    独立安全单元

    安全状况报告的建立和使用需要步步递进。该报告由芯片开发商提供信息,所有厂商的信息都必须综合考虑,最后交付客户使用,层层递进。获许可最多的芯片IP被称为“独立安全单元”(SEooC),其设计师们无需了解该芯片后续的使用方式。因此,安全手册必须说明 IP开发商对芯片使用建议和说明,避免误用。同样,OEM的1级控制器供应商也可以使用SEooC模型开发安全功能。因此,IP级的安全文件包可用于整个价值链,是 IP开发的重要部分。

    功能安全将逐渐成为硬性要求

    从汽车到医疗再到工业设备,依赖电子器件的应用越来越多,功能安全正变得更加重要,并将成为常规要求。功能安全是IP厂商必须达成的要求,也是让基于该IP建造的模型顺利运行的必要条件,因此IP厂商必须将每项研究成果授予尽可能多的芯片合作伙伴,反之亦然。有了坚实的质量和可靠性,功能安全才能带来更广泛的好处,进而推动全行业的质量和可靠性提升。包括驾驶员安全、燃油经济性、舒适度和车载信息娱乐系统等,功能安全是芯片设计师解决更高级别汽车难题的基础。


    展开全文
  • BMS功能安全开发流程详解

    千次阅读 2019-08-28 14:36:36
    来源:第一电动网作者:129Lab ...最近在了解学习关于ISO26262,看了一些文章,本身从事BMS相关的工作,想做一个关于BMS功能安全开发流程的笔记,分三篇文章,第一篇是关于BMS和ISO26262的简介。 BMS & ISO26...
  • ISO26262功能安全--产品开发过程

    千次阅读 多人点赞 2019-10-18 14:37:48
    2.3 功能安全目标 2.4 安全需求与安全概念 3. 系统阶段——闭门造神车,我们开始修炼 3.1 技术安全需求(TSC) 3.2 系统架构设计 3.3 安全分析与独立性分析 3.4 软硬件接口(HSI) 4. 硬件阶段——苦其心志,...
  • 随着汽车电子软硬件复杂性提高,来自系统失效和随机硬件失效的风险日益增加,随着汽车电子行业标准ISO26262的发布,使得人们对功能安全有了深入的理解,对评估、避免这些风险提供了可靠的流程保证。电池管理BMS引入...
  • 功能安全-ISO26262标准简介

    万次阅读 2018-07-05 09:36:05
    ISO 26262基于IEC 61508-电气和电子(E/E)系统的通用功能安全标准。本白皮书介绍ISO 26262的关键组成以及软硬件认证。此外,本白皮书还包含ISO 26262的测试过程,以及ISO 26262合规的认证工具。 1 背景  随着汽车...
  • ISO26262 功能安全各个阶段测试要求

    千次阅读 多人点赞 2019-11-13 16:15:37
    2. 功能安全总体要求 2.1 各项指标 2.2 诊断覆盖度举例 针对一个信号举例说明: 3. 功能安全测试要求 3.1 测试计划 核心内容应包括, 测试对象:需要测试的对象描述,以及测试的范围描...
  • ISO26262 是 IEC61508 对 E/E 系统在道路车辆方面的功能安全要求的具体应用。 ——提供了汽车生命周期(管理,研发,生产,运行,服务,拆解)和生命周期中必要的改装活动。 ——提供了决定风险等级的具体风险评估...
  • 汽车功能安全(一)~笔记

    千次阅读 2019-09-23 10:20:31
    汽车功能安全 最近接触到汽车OBC功能安全的实现,于是开始了解关于功能安全方面的知识,初次写,若有不对之处,望提出交流、互相学习。 ...
  • 功能安全专题之端到端(E2E) 的通信保护

    万次阅读 多人点赞 2020-06-17 18:32:31
    由于软件的复杂度会影响 到功能安全的设计,所以在AUTOSAR规范中,包含了部分与功能安全相关的需求,这些新技术和概念能够帮助降低功能安全相关组件的复杂度。不过需要强调的是,AUTOSAR虽然通过提供安全措施和机制...
  • 功能安全----概念阶段详细步骤总结

    千次阅读 2019-08-14 13:36:45
    相关项:实现车辆层面功能或部分功能的系统或系统组。 相关项定义:定义并描述相关项,以及其与环境、其他相关项之间的依赖关系和交互影响,为充分理解相关项提供支持,以便执行后续阶段的活动。 2. HARA分析 ...
  • ISO PAS 21448 SOTIF(预期功能安全)笔记(一)

    千次阅读 多人点赞 2020-02-18 23:34:55
    (ISO PAS 21448中的1~3章节内容,涵盖预期功能安全的背景、介绍和重要术语) 笔记 1 Scope(范围) 1.定义: 不存在因预期功能不足或由于合理预见的人员误操作而造成的危险。 2.用途: 指导功能设计、验证和确认...
  • 谈谈功能安全种的故障,错误,失效

    万次阅读 多人点赞 2018-09-17 07:53:32
    功能安全中的有些概念比较绕,比如故障(fault),错误(error),失效(failure),今天就这三个概念进行下探讨。  一,故障  功能安全中定义的故障是指可引起要素或相关项失效的异常情况。  故障可以分为永久故障...
  • 功能安全学习笔记001-功能安全简介

    千次阅读 2018-03-13 20:08:54
    功能安全学习笔记001-功能安全简介1,历史背景功能安全的概念首先起源于20世纪60-70年代的航空领域和核技术领域。到了20世纪70-80年代时,由于当时在世界范围内,尤其是石油化工领域多次发生爆炸或污染泄露事情。...
  • 开发合格的汽车电子产品-Autosar+MBD+功能安全

    千次阅读 多人点赞 2019-10-26 16:04:02
    多多少少留下一些扎扎实实造车的企业,他们将一些国外先进的技术带入到汽车产品开发中,这些技术慢慢在汽车行业(包括乘用车和商用车)得到普及,本文主要从三个技术角度(即Autosar、MBD、功能安全)来聊聊成为标配...
  • 功能安全专题之AUTOSAR内存分区机制

    千次阅读 多人点赞 2019-12-04 09:46:12
    由于软件的复杂度会影响 到功能安全的设计,所以在AUTOSAR规范中,包含了部分与功能安全相关的需求,这些新技术和概念能够帮助降低功能安全相关组件的复杂度。不过需要强调的是,AUTOSAR虽然通过提供安全措施和机制...
  • 1. The necessary activities and processes for the ...如有兴趣,可扫下方二维码关注功能安全公纵号,也可直接入群,参与交流与讨论,管理员会定期更新功能安全相关经验、对标准的理解,等等。    
  • ISO26262如何保证功能安全

    千次阅读 2018-07-06 09:26:59
    根据ISO26262, 对于任何一项需求,其功能安全大致可以通过以下几个步骤来保证:1)进行Hazard Analysis和Risk Assessment。这个步骤是为了获得需求的E、C、S值。2)评出此需求的ASIL评级并建立Safety Goal。Safety ...
  • 随想录(功能安全和软件开发)

    千次阅读 2018-12-16 22:29:58
     要说现在汽车软件开发,最火的安全概念就是功能安全。至于标准,那就是ISO26262。当然标准只是提供了一个规范,具体怎么做,大家都是摸着石头过河。不过可以明确的就是,功能安全涉及到软件和硬件两个方面,当然...
  • 功能安全专题之AUTOSAR Timing的保护机制

    千次阅读 热门讨论 2019-10-11 15:14:48
    功能安全(Functional Safety)是一项系统特性,由于基于功能安全的设计会影响到系统设计,所以从系统开发初始阶段就要进行考虑。由于软件的复杂度会影响 到功能安全的设计,所以在AUTOSAR规范中,包含了部分与功能...
  • AUTOSAR功能安全之看门狗WDGM 介绍

    千次阅读 2020-02-28 13:01:01
    功能安全之看门狗WDGM 介绍: 1 一、AUTOSAR 看门狗软件堆栈:… 1 1)Wdg堆栈具有三个软件模块:… 1 2)WdgM通过WdgIf和Wdg控制硬件实现的看门狗,看门狗可以是一个或多个内部或外部看门狗设备。 注意:看门狗设备...
  • 硬件设计验证的手段中提到的安全分析指的是FMEDA。=> 安全分析的手段有三种:FTA, FMEA, FMEDA。其中FTA和FMEA用来支持硬件设计,FMEDA用来进行硬件设计的验证。(4) 5.8 evaluation of the hardware ...
  • 功能安全---AUTOSAR架构深度解析

    千次阅读 2018-08-22 08:50:33
    AUTOSAR的分层式设计,用于支持完整的软件和硬件模块的独立性(Independence),中间RTE(Runtime Environment)作为虚拟功能总线VFB(Virtual Functional Bus)的实现,隔离了上层的应用软件层(Application Layer)与...
  • 20180621-ISO26262功能安全基础

    千次阅读 2018-06-21 10:20:50
    2,系统本身的安全功能方面,如功能安全功能安全,指在设计过程中规定性考虑产品安全,并在整个开发过程中有序管理的一套系统。 嵌入式系统的功能安全标准为IEC61508,将安全生命周期分为16个阶段。目前汽车上用...
  • 功能安全-ISO26262硬件设计案例(ASIL等级计算)

    万次阅读 多人点赞 2018-07-06 09:57:42
    ISO26262-5中,通过某硬件电路失效率的计算展示了如何进行定量地分析功能安全。失效分为单点故障和潜在多点故障。一、硬件电路原理图电路实现的功能如下:1)MCU采集车速信号(I1、I2为车速传感器);2)当高车速时...
  •  功能F和安全机制是冗余安全需求,同时来满足安全目标,因此可以将功能F原来的ASIL等级在这两个需求上进行分解,分解为ASIL D(D)和QM(D),分解后的ASIL等级如图5所示。 图5 ASIL分解后架构示意图  原来的传感器S1...
  • ADAS/AD开发05 - 功能安全

    千次阅读 2018-09-12 18:17:36
    功能安全本是一个更宽泛的话题,但是在汽车电子领域的功能安全,几乎等同于产品开发过程中对ISO26262标准的贯彻。 一、ISO26262:Road vehicles — Functional safety 标准 该标准只针对汽车电子电器系统。会牵涉...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,806,405
精华内容 722,562
关键字:

功能安全