精华内容
下载资源
问答
  • 基于ISO26262的整车电源模式管理系统功能安全概念设计
  • 本PDF包括整车电子电气发展趋势,AUTOSAR的控制开发流程,后面对应了开发的实际案例,希望对想了解基于功能安全标准和AUTOSAR开发的人有用。
  • ISO26262功能安全要求和AUTOSAR标准的整车控制架构研
  • 背景介绍 为了保证汽车电子电气的可靠性设计,在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



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



    喜欢此篇文章的话欢迎一键三联支持小编吧~!
    展开全文
  • 题主正在做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分析的话,在功能冻结上的分析结果就变成了永远在超车(很无语的结果)。发现不能分析了后就把这个功能拆成了变道,加速,变道三个功能,然后分析了一遍,豁然开朗。
    
    展开全文
  • 从SAE J3061到ISO 21434,威胁分析与风险评估(TARA)均被作为核心的网络安全分析方法,并已成为智能汽车网络安全功能开发实施与测试的前提和基础。如何评估智能汽车网络安全威胁与风险?如何定义智能汽车网络安全需求...

    随着智能网联汽车的不断普及与演进,网络安全问题日益突显,其所存在的安全威胁与风险亟需通过科学、全面的分析,建立有效的安全应对措施。从SAE J3061ISO 21434,威胁分析与风险评估(TARA)均被作为核心的网络安全分析方法,并已成为智能汽车网络安全功能开发实施与测试的前提和基础。如何评估智能汽车网络安全威胁与风险?如何定义智能汽车网络安全需求?

    本期谈思实验室特邀广东为辰信息科技有限公司 副总经理 罗建超博士为大家介绍在多个主机厂成功实施的TARA方法及案例,为整车、零部件、车联网业务等的TARA分析及网络安全功能实施提供指引。

    罗建超博士,为辰信安副总经理,电子科技大学博士,具有十余年汽车电子项目实施经验,专注于汽车电子网络安全领域的产品研发与产业化,主持多款汽车电子网络安全产品研发并量产上市,主持实施面向主机厂的多个整车级网络安全咨询项目。主导编写了具有国际影响力的《车联网网络安全防护指南细则》、国内智能汽车网络安全第一份白皮书《车联网网络安全白皮书》,参与编写汽车电子网络安全第一个国家标准《信息安全技术 汽车电子系统网络安全要求》。

    演讲时间79本周日晚 19:30-20:30

    演讲主题整车网络安全威胁分析与风险评估(TARA)方法与实践

    关键话题

    国际主流TARA方法介绍

    面向智能汽车的TARA方法

    整车TARA分析过程与案例

    TARA在开发/运维阶段的运用:安全审计、安全测试、安全运维

    展开全文
  • 为了避免信息安全对功能安全的不利影响,本文介绍了功能安全和信息安全在整车开发流程中可能存在交互关系,功能安全和信息安全都有助于提升E/E系统的安全性。本文仅从功能安全的角度出发,所以并没有介绍实现信息...

    功能安全和信息安全的交互

    前言

    为了避免信息安全对功能安全的不利影响,本文介绍了功能安全和信息安全在整车开发流程中可能存在交互关系,功能安全和信息安全都有助于提升E/E系统的安全性。本文仅从功能安全的角度出发,所以并没有介绍实现信息安全的相关方法。在整个开发流程中,由于项目的范围和不同研发团队的差异性,可能会导致功能安全和信息安全的交互关系存在一定的差异。因此本文没有提供具体的实现方法或技术,相关企业可以根据自身条件和环境选定适合的方法。

    概述

    功能安全主要解决的是由系统错误和随机错误导致的E/E系统的故障,而信息安全主要是为了解决外部对E/E系统的恶意入侵威胁。为了更好的实现功能安全,可以从信息安全中了解可能会对功能安全产生负面影响或可以帮助提升功能安全的相关信息。

    更多信息安全相关的信息可以参考 SAE J3061,ISO/IEC 27001, ISO/IEC 15408。

    功能安全管理阶段

    功能安全管理与信息安全管理的交互主要包括以下方面:

    • 信息安全的计划和里程碑主要考虑的是可能对信息安全进度造成影响的依赖项,如:开发软件和工具的选择、编程语言和标准规范等。
    • 两者个协作部分主要在监控相关的活动里,包括事件的报告、跟踪和处理。如信息安全可以将相关的异常问题传递功能安全,从而功能安全做出更有效的防护。

    概念阶段

    概念阶段的交互主要包含以下内容:

    • 为了保证HARA和安全目标的完整性,信息安全相关的威胁应被功能安全作为危害事件进行分析;
    • 功能安全可以够给信息安全提供危害事件和相对应的危害等信息,帮助信息安全更好的识别潜在的威胁;
    • 信息安全在检测到攻击的情况下在E/E系统中的相关措施和行为应被功能安全考虑,确保该措施不会对安全目标或安全概念造成潜在影响。

    开发阶段

    开发阶段的交互主要有以下内容:

    • 在E/E系统中用于实现信息安全策略的相关技术信息应当考虑是否对功能安全的技术安全概念和系统设计造成影响。
    • 信息安全软件和硬件设计应注意是否对功能安全软件和硬件安全要求以及设计约束(例如独立性)的存在潜在影响。
    • 功能安全应提供安全措施的设计和执行方式,用于确定功能安全和信息安全在安全措施相关开发的边界和交互。
    • 应协调功能安全和信息安全分析活动,以便发现信息安全对功能安全的潜在影响。 功能安全分析也应考虑对信息安全措施的影响。
    • 信息安全应注意识别信息安全措施开发过程中产生的系统故障,以免对功能安全造成影响,例如:功能安全措施的开发所要求的相关方法和标准应分享给信息安全。

    生产和运行

    生产和运行阶段的交互内容如下:

    • 信息安全因考虑在生产运行阶段中相关措施或策略的改变和更新对功能安全的潜在影响。
    展开全文
  • 本文依据ISO 26262从功能安全测试的角度出发,以ESCL为测试对应,阐述符合功能安全标准的测试实现过程,基于Vector VT System的HiL系统开发相关测试脚本实现测试。 ISO 26262简介 ISO 26262系列标准是对IEC 61508...
  • VCU整车控制器的功能安全设计架构,从软件和硬件层面来说明整车控制器的功能安全的整体设计思路,非常适合功能安全的设计师
  • ISO26262 功能安全各个阶段测试要求

    千次阅读 2019-11-13 16:15:37
    2. 功能安全总体要求 2.1 各项指标 2.2 诊断覆盖度举例 针对一个信号举例说明: 3. 功能安全测试要求 3.1 测试计划 核心内容应包括, 测试对象:需要测试的对象描述,以及测试的范围描...
  • 本文首先介绍建立符合ISO 26262要求的开发和管理过程体系方面的经验;然后介绍整车厂、汽车电子产品供应商和二级供应商如何协作实施符合 ISO 26262要求的汽车电子功能安全解决方案。
  • 当前新能源汽车产品蓬勃发展,为了能够帮助客户快速的建立满足Autosar和功能安全需求的整车控制器,缩短客户开发时间,上海工业控制安全创新科技有限公司联合旗下工作室企业上海革路电子科技有限公司,开发了VCU的...
  • 来源 | 网络新能源汽车作为一种绿色的运输工具在环保、节能以及驾驶性能等...为了满足整车动力性、经济性、安全性和舒适性的目标,一方面必须具有智能化的人车交互接口,另一方面,各系统还必须彼此协作,优化匹配,...
  • 本次课程是从整车角度统筹车辆发动机、空调、电池、电机等相关部件及子系统相关匹配、优化与控制,有效解决整车热相关问题,使得各工功能模块处于最佳温度工况区间,提高整车经济性和动力性,保证车辆安全行驶。...
  • 随着燃油经济性、环境保护和道路安全要求的逐步加强,汽车电子电气架构设计中必须要考虑系统整体优化,并需要提高开发效率、缩短开发时间,此时基于模型的方法就变得非常重要。采用这种方法必须要借助工具才能实现,...
  • 在汽车电子的ECU领域,面临程序经常升级的困扰,为了减小程序升级的成本,整车开发一般需要支持OTA。下面我们从ECU的角度分析下Bootloader方案。 你是否面临过升级失败拆机的困扰,是否面临过客户需要变更Bootload...
  • 满足自动驾驶远程遥控的...判断各个子控制单元和整车系统的状态,做出合理、安全的指令,从而让各个子控制单元协调、安全的工作,实现自动驾驶电动车系统的功能。 通常整车控制器将需要采集整车档位信号,油门踏板...
  • 自动驾驶、V2X、OTA等技术的更迭发展,整车拓扑上势必会增加大量ECU模块,同时数据加密等的技术引入,都将导致现有的车辆电子架构将越来越无法满足功能需求。 针对未来的整车电子架构设计,Domain Controller的引入...
  • • MCU要求: −CPU: >80MHz, FLASH >512K, RAM>64K,FPU • 通讯接口: −CAN:1~3路 − 以太网 −LIN:1~3 • AUTOSAR • 功能安全: −ASIL-C或ASIL-D
  • 如果线束失效,就会造成信号传递失效,功能设备失去作用;或接触电阻过大发热失火;或短路失火;或绝缘层失效漏电。因而,为了保证汽车线束的品质、安全性和可靠性,汽车线束生产线上或用户使用前检测十分重要。那么...
  • 根据整车安全目标分解的功能安全需求并对应到相关零部件,可知电机控制系统相关的功能安全需求至少要满足ASIL C的安全等级,才能符合整车功能安全目标。然而传统电机控制器是由单个电机控制芯片做处理器,往往很难...
  • 随着汽车技术的不断进步及用户体验的升级,搭载更多的需求功能、多变的使用环境,直接考验整车安全及运行可靠性。汽车的可靠性试验,保障了人类生命财产安全,推动着汽车行业进入新的、密集的、 内部可操作的多...
  • 根据整车安全目标分解的功能安全需求并对应到相关零部件,可知电机控制系统相关的功能安全需求至少要满足ASIL C的安全等级,才能符合整车功能安全目标。然而传统电机控制器是由单个电机控制芯片做处理器,往往很难...
  • 随着汽车工业的发展和进步,人们对汽车的动力性、经济性、安全性及排放等方面提出了更高的要求,传统的机械式控制系统已经远远不能满足这些需要。电子化控制系统以其高精度、高速度、控制灵活、稳定可靠等特点逐渐...
  • 其中《GB 18384-2020 电动汽车安全要求》主要规定了电动汽车的电气安全和功能安全要求,增加了电池系统热事件报警信号要求,能够第一时间给驾乘人员安全提醒;强化了整车防水、绝缘电阻及监控要求,以降低车辆在正常...
  • 本部分规定了营运货车中载货汽车的术语和定义,以及整车、制动系统、安全防护装置、载荷布置与系固点、报警与提示功能、其他等安全技术要求。 本部分适用于N1类、N2类、N3类的营运货车,不适用于牵引货车、半挂牵引...
  • 机动车整车/底盘出厂合格证 打印接口v3.0设计说明 ................... 10 第一章 升级内容 ................................................... 11 1.1 打印接口升级声明 ................................. 11 ...
  • 其中《GB 18384-2020 电动汽车安全要求》主要规定了电动汽车的电气安全和功能安全要求,增加了电池系统热事件报警信号要求,能够第一时间给驾乘人员安全提醒;强化了整车防水、绝缘电阻及监控要求,以降低车辆在正常...
  • 2017年个大整车厂商,Tier 1以及行业联盟纷纷推出了V2X 产品,技术和行业标准,包括:奇瑞在安徽建成首条智能网联 V2X 示范道路;上汽荣威新车计划2019年商业化体验V2X网联功能;Qualcomm发布突破性C-V2X车联网解决...

空空如也

空空如也

1 2 3 4 5 ... 7
收藏数 134
精华内容 53
关键字:

整车功能安全