精华内容
下载资源
问答
  • 基于功能安全的电动汽车整车控制器开发与实现,包括功能安全的发展历程等
  • 整车控制器功能安全的设计和研究的期刊论文,简明扼要。
  • 基于ISO26262的整车电源模式管理系统功能安全概念设计
  • 基于纯电动汽车整车控制器的功能安全分析与设计.pdf
  • 行业资料-交通装置-一种基于功能安全整车控制器.exe
  • 本PDF包括整车电子电气发展趋势,AUTOSAR的控制开发流程,后面对应了开发的实际案例,希望对想了解基于功能安全标准和AUTOSAR开发的人有用。
  • ISO26262功能安全要求和AUTOSAR标准的整车控制架构研
  • 行业资料-交通装置-一种基于安全功能整车控制器.zip
  • 背景介绍 为了保证汽车电子电气的可靠性设计,在2011年发布了ISO 26262(道路...由Pi Innovo设计和制造的OpenECU M560整车控制器ECU是针对特定的功能安全目标集而开发的,可以满足ISO 26262 ASIL D功能安全,适用于通用

    背景介绍

    为了保证汽车电子电气的可靠性设计,在2011年发布了ISO 26262(道路车辆功能安全标准),ISO 26262标准横向视角来看,解决的问题是:减少汽车电子电气系统发生系统性失效的可能性,采用的方式是全生命周期全系统的安全管理方式,从而保证安全相关的电子产品的功能性失效不会造成安全事故。标准还提供了审核方法,使安全体系形成闭环。

    由Pi Innovo设计和制造的OpenECU M560整车控制器ECU是针对特定的功能安全目标集而开发的,可以满足ISO 26262 ASIL D功能安全,适用于通用快速原型平台或小批量生产。

    本文将介绍M560系列OpenECU硬件模块和软件平台的功能安全体系架构和设计特性,验证其是否可以达到ISO 26262 ASIL D安全等级。

    北汇信息作为Pi Innovo的合作伙伴,将为您的ISO 26262功能安全需求提供相关产品和技术服务。我们期待与您密切合作,了解和完善您的功能安全要求(FSR),选择适当的硬件,以满足您的项目需求。


    在这里插入图片描述


    M560功能安全概要

    之前的文章已介绍过快速原型M560系列OpenECU的硬件资源和应用范围,(点此回顾→符合ASIL-D的纯电动/混动整车控制器M560正式发布)提到了通过可选的硬件冗余以及在副处理器(ST Micro SPC560P34L1CEFAR)上校验软件的实施,M560可以满足ISO26262 ASIL D功能安全需求。

    作为符合ASIL-D安全目标的ISO 26262:2011项目的一个要素,其功能安全通过以下提供的架构实现:

    •	具有非对称硬件冗余和多样化软件冗余的双处理器架构
    •	两个处理器器判断来激活输出
    •	输入路由到两个处理器进行交互计算
    •	副处理器能够独立的激活/关闭CAN总线
    

    M560功能安全最大ASIL等级取决于具体的应用程序使用和应用程序软件实现的实际安全机制。表1总结了如果使用所有可用的内部安全机制下M560的ASIL最大等级;图1以图形方式描述了这些场景。


    在这里插入图片描述

    Table 1 - Maximum ASIL

    在这里插入图片描述

    Figure 1 - ASIL scenarios



    浅析M560功能安全实现架构

    M560主要是为纯电动/混动汽车设计的动力总成监控控制器,它包含一个主处理器,安全功能目的的副处理器,两个传感器电源,4个高速CAN总线,以及丰富的输入和输出IO,包括SAE J1772接口(电动车及插电式混合动力车传导式充电接口)。


    系统操作环境要求

    M560仅在技术规范中规定的操作环境中使用时,才能实现指定的ASIL等级,并进一步局限于以下表2准则。


    在这里插入图片描述

    Table 2 - M560 qualified operating environment

    功能安全实现示例

    M560提供下表3所示安全功能:
    在这里插入图片描述

    Table 3 - M560 safety functions



    M560对系统集成要求

    (ISO 26262 10-9.2.2 step 1b)在系统中使用M560必须符合表4中指定的要求:


    在这里插入图片描述

    Table 4 - M560 system integration requirements



    实现安全功能需求

    M560满足表5中规定的安全功能需求:


    在这里插入图片描述

    Table 5 - M560 safety requirements



    OpenECU软件开发

    M560平台软件是依据ISO 26262流程 ASIL B(D)等级以及结合具有ASIL B(D)等级的软件来开发的,其平台软件包含:

    固件(Firmware)

    •	Bootloader
    •	Reprogramming mode
    

    操作系统(Operating System)

    •	Primary microcontroller: Priority ceiling preemptive task scheduler with rate-monotonic application task prioritization, tasks as fast as 1ms period on primary
    •	Secondary microcontroller: non-preemptive, strict rate monotonic task scheduler
    •	Platform library and application initialization
    •	Stack monitoring
    •	Device driver hardware interface (hardware abstraction layer
    

    平台库(Platform library)

    •	APIs to access the device drivers
    •	Utility functions
    

    软件开发工具链程序(Software development toolchain utilities)

    •	Binary image preparation (OpenECU executable format)
    •	ASAP2 file generation
    

    OpenECU M560平台软件通过多种方式在两个处理器之间提供软件的多样化冗余:

    •	每个处理器的源代码是独立的
    •	每个处理器的二进制文件由不同的编译器和链接器工具链生成
    

    对于具体M560中两个微控制器的软件环境、可用的安全机制以及每种机制支持的诊断覆盖率在表6中列出了部分供参考。


    在这里插入图片描述

    Table6 - Software environment




    另外软件开发配置和工具需要按以下特定的要求来配置:

    工具要求
    要满足本文的假设,需要以下工具,且是下述指定需求的确切版本。这些工具的新版本目前还不具备资格,因此不宜用于正式的开发。

    •	Mathworks
        Primary microcontroller: Matlab, Simulink, Stateflow, Sateflow Coder, Matlab Coder: R2015b (32-or 64-bit)
        
    •	Diab
        Primary microcontroller: WindRiver compiler: version 5.9.4.8 with patch TCDIAB-14743
        
    •	CodeWarrior
        Secondary microcontroller: CodeWarrior Development Studio for MPC55xx/MPC56xx Version 2.10
    

    主副处理通信
    M560在主处理器和副处理器之间提供专用的UART通信总线,该总线特征如下:

    •	242k波特率
    •	延迟:从传输请求到总线的出现的第一个位延迟小于1ms,加上传输时间(字节/波特)为请求/响应通信设计的轮询机制
    •	应用软件负责检测通信超时
    •	OpenECU平台软件只在消息校验和与消息数据匹配时将接收到的消息传递给应用程序,校验和值本身没有传递给应用程序
    

    潜在故障管理

    应用软件负责启动检查和协调潜在故障检查,包括:

    •	应用程序软件必须实现一个检查功能,即两个处理器可以彼此互相重置。
    •	副处理器应尝试启用/禁用每个CAN总线,并通过使用主处理器软件监视通信来验证总线状态的变化。
    •	对于副处理器使能的每个输出,副处理器可以关闭输出,而主处理器使用监视器确认输出失效以验证关闭命令即可尝试激活输出。
    

    应用程序开发流程指导

    M560提供了ECU硬件和平台软件,共同辅助开发符合复杂的功能安全要求的应用程序。Pi Innovo对M560基于ISO 26262流程的安全相关条目应用程序开发提供了许多设想,这部分内容客户可以针对自己的具体应用和设想在基于M560硬件和平台软件的基础上进行相关的学习,如有需要可以联系北汇信息做进一步交流。


    总结

    ISO 26262功能安全要求ECU硬件、应用程序软件和平台软件均满足整体功能安全目标,Pi Innovo是基于经过验证的V模型来开发硬件和软件平台的,主处理器和副处理器上的应用程序软件由最终用户负责。任何一种软件都不能单独实现功能安全。因此,应用程序软件和平台软件必须依据ISO 26262 流程的相同ASIL等级开发,才可以确保功能安全可实现。总而言之,安全是一个系统级工程,小到需要每个IO、ECU、软件,大到整车厂、供应商、汽车电子电气解决方案的通力协作才可能实现系统功能安全目标。


    在这里插入图片描述

    关于Pi Innovo

    Pi Innovo 公司(成立于1990年)总部位于美国密歇根州,在发动机控制、新能源整车控制、底盘控制等领域具有多年的成功应用经验。其开发的快速原型系列产品OpenECU,基于Matlab/Simulink的开发环境、高效的自动代码生成、支持通用的标定工具,针对发动机、后处理、车辆稳定系统和新能源车辆控制系统开发提供有效的解决方案,适用于生产、试生产及大批量生产。

    北汇信息作为Pi Innovo 在中国的合作伙伴,将为客户提供全方位的支持和高效的控制策略解决方案。



    参考文献

    [1] M560 Technical Specification (01T-070018TK-xx)
    [2] ISO 26262 First edition 2011-11-15
    [3] 29T-070064-01_M560 Family Functional Safety Manual
    [4] SAE Webinar Pi Innovo M560-26262_Lessons_Learned_Webinar_06-FINAL 180524



    ----------------------------------------------------------------------------------------------------------------------



    喜欢此篇文章的话欢迎一键三联支持小编吧~!
    展开全文
  • 2016满足ISO26262功能安全要求和AUTOSAR标准的整车控制架构研发与测试评价.zip
  • 整车电子电器功能开发模式探索
  • 整车电子电器功能开发
  • 整车配置表和功能表在电气功能开发中的应用研究
  • 功能安全专题之功能安全概念阶段

    千次阅读 多人点赞 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

    展开全文
  • 用来进行HARA分析的整车功能有哪些

    千次阅读 2019-03-01 16:00:22
    题主正在做L3级别的自动驾驶的功能安全,在参考了传统车的分析方法后,感觉在某些方面没有搞清楚一些事情,导致了这场耗时较长的讨论。(感觉以后会经常有这种时耗的讨论出来的话,不知道老板会不会因此拍我们)。 ...

    题主正在做L3级别的自动驾驶的功能安全,在参考了传统车的分析方法后,感觉在某些方面没有搞清楚一些事情,导致了这场耗时较长的讨论。(感觉以后会经常有这种时耗的讨论出来的话,不知道老板会不会因此拍我们)。
    文章的主题是整车上的哪些功能可以用来分析HARA(Hazard Analysis and Risk Assessment).
    为什么讨论这个话题是因为大家都没有对整车的功能有一个清晰的定义。比如横向控制,纵向控制算是整车的功能,还是像LKA(PCC,Predictable Cruise Control,可预测巡航控制)算是一个整车功能。大家感觉来感觉去,觉得好像两类都是整车的功能,只是后面一种是多个整车功能的合集。于是就引发了这个话题。
    !在这里插入图片描述
    这个话题的焦点集中在,既然我在分析PCC功能的时候也要将该功能打散到横向控制和纵向控制,为何不能就简单的就横向控制,纵向控制等整车的基础功能进行HARA的分析呢?
    最终促成我们终结该话题的原因如下:
    1.各个功能的使用工况不一样。比如横向控制在车辆的大多数运行工况中都可能出现,但是PCC功能只可能出现在GPS信号和以太网能正常工作的工况下,比如隧道里面,PCC功能可能就直接降级成ACC或者CC功能了。因为工况的不一样,在进行ASIL评分的时候,所评出来的S,E,C就会有很大的不同,直接造成安全目标的ASIL等级的不同。
    2.各个功能的系统框图不一样(也可以说针对功能级别的Item definition不一样),包括感知,决策和执行机构。比如从感知上来讲,PCC需要用到GPS,高精地图等信号,但是整车的横向移动可能需要用到整车上大多数感知信号,总不能根据横向移动评估出来的ASIL等级对所有的感知器件提同样的ASIL等级需求,在大多数情况下,这会过于苛刻。
    以上,作为记录先存着。

    补记1:
    所以最终,在进行HARA分析的时候,要先将功能的Item definition画出来,然后才能讨论HARA。ISO26262中也有类似的记载,只是没有说明是要将整车的Item definition画出来还是将功能的Item definition画出来。题主的认识是,如果将整车的Item definition画出来,在针对各个功能进行HARA分析的时候会因为Item definition中的东西太多了而导致混乱。
    补记2:
    发现关于超车这个大功能不能用HAZOP(6个方面分析,功能丢失,功能过多,功能过少,相反的功能,不可预期的功能,功能冻结)的方法进行分析,因为超车的定义是,超过前面的车辆并回到原来的车道上。按照这个定义来进行HAZOP分析的话,在功能冻结上的分析结果就变成了永远在超车(很无语的结果)。发现不能分析了后就把这个功能拆成了变道,加速,变道三个功能,然后分析了一遍,豁然开朗。
    
    展开全文
  • 功能安全学习笔记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等级的评定和分解。所学有限,如有失误,还请指正,感激不尽。




     






















    展开全文
  • VCU整车控制器的功能安全设计架构,从软件和硬件层面来说明整车控制器的功能安全的整体设计思路,非常适合功能安全的设计师
  • 混合动力客车多功能整车控制系统开发
  • 浅谈功能尺寸在整车中的应用
  • 功能安全--安全分析

    千次阅读 2019-11-14 17:49:24
    在ISO26262功能安全中,有多个地方需要进行安全分析,安全分析的质量很重要的决定了功能安全项目的成败,本文针对ISO26262中提到的各种安全分析进行汇总说明(HARA、FMEA、FTA、FMEDA、SWFMEA、DFA)。 1. HARA 在...
  • 本文依据ISO 26262从功能安全测试的角度出发,以ESCL为测试对应,阐述符合功能安全标准的测试实现过程,基于Vector VT System的HiL系统开发相关测试脚本实现测试。 ISO 26262简介 ISO 26262系列标准是对IEC 61508...
  • 从SAE J3061到ISO 21434,威胁分析与风险评估(TARA)均被作为核心的网络安全分析方法,并已成为智能汽车网络安全功能开发实施与测试的前提和基础。如何评估智能汽车网络安全威胁与风险?如何定义智能汽车网络安全需求...
  • 电动汽车整车控制器BootLoader功能开发
  • 中国第一汽车集团有限公司智能网联开发院的汽车OTA方案,为满足智能网联汽车快速迭代的需求, 提出一种安全、方便、可靠的整车 OTA 解决方案。 通过建立云服务器端 和车辆客户 端之间的数据通路, 使用差分算法、...
  • 为了避免信息安全对功能安全的不利影响,本文介绍了功能安全和信息安全在整车开发流程中可能存在交互关系,功能安全和信息安全都有助于提升E/E系统的安全性。本文仅从功能安全的角度出发,所以并没有介绍实现信息...
  • 功能安全 - 安全自动驾驶是团队工作 Christoph Maier DEKRA Digital GmbH 摘要 自动驾驶技术是未来最大的挑战之一。需要对数十个传感器进行每秒数百次的评估,以创建一个有效的环 境模型,并在此基础上,推导出驱动...
  • 车辆信息安全策略及整车电子架构防火墙 转载于“解读:整车电子架构防火墙需求定义” 车辆与外部实现远近场通信的两种主要连接方式:如包括蓝牙、毫米波传感器、RFID及未来DoIP(Diagnostic Over Internet ...
  • 目录 ...ISO 26262《道路车辆功能安全》国际标准是针对总重不超过3.5吨八座乘用车,以安全相关电子电气系统的特点所制定的功能安全标准,基于IEC 61508《安全相关电气/电子/可编程电子系统功能安..
  • 本期将汽车以太网架构、ADAS功能模块以太网架构、两个以太网协议、以太网功能硬件架构、以太网硬件方案、传感器以太网通信方案、控制器以太网方案、以太网软件架构、软件开发流程、EB Tresos 开发实例、Davinci 开发...
  • 汽车功能架构设计-功能安全方案设计

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,224
精华内容 1,289
关键字:

整车功能安全