本文主要是介绍汽车安全困境:如何破局?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
在近年智能制造的大环境下,智能汽车、无人驾驶等话题逐渐成为了焦点。随着汽车软件的数量增幅加剧,汽车所涉及的代码量也出现了惊人的增长:现今的每辆车约有1亿行代码——超过了喷气式飞机的代码量,且其复杂度远超Linux系统内核。汽车软件工程师需要处理的问题范围变得越来越广泛,而与之对应的车辆安全也面临着巨大的挑战。
本文将从汽车软件的类型入手,结合当下汽车安全面临威胁的现状,通过分析汽车的各项安全标准及等级,探索针对车辆安全问题的解决方案。
01.汽车软件的类型:
汽车软件包含许多种类,不同种类的软件分别对应实现不同的功能。
根据其对车辆的自动控制程度,可以将汽车电子软件分为以下三类:
- 控制、车载信息娱乐软件:*控制软件:驾驶员可以通过使用此类软件,达到控制车辆的目的。此类软件通常位于车辆指挥、控制和信息系统中,能够提供引擎管理、制动、外部照明等功能;*车载信息娱乐软件:可用于实现汽车的可用性、舒适性,如车窗控制、车内照明。
- 高级驾驶员辅助软件:Advanced Driving Assistance Software,简称ADAS,包括自适应巡航控制、自动泊车、盲点监测和防撞系统等。
- 自动驾驶软件:分为环境感知、行为决策、路径规划和运动控制四大部分,使用广泛的传感器阵列来感知环境,以达到完全自动控制车辆的目的。
根据下图可见,软件对车辆的自动控制程度越高,安全系数、风险也就越高。
02.安全标准
2.1 ISO 26262《道路车辆功能安全》
ISO 26262国际标准是一项功能安全标准,面向总重不超过3.5吨八座乘用车,根据安全相关电子电气系统的特点所制定,基于IEC 61508《安全相关电气/电子/可编程电子系统功能安全》,正式发布于2011年11月15日。
ISO 26262是IEC61508对E/E 系统在道路车辆方面的功能安全要求的具体应用,为汽车安全提供了完整生命周期(管理、开发、生产、经营、服务、报废)及该周期内必要的改装活动的理念,提供了决定风险等级的具体风险评估方法(汽车安全完整性等级,ASIL),为避免这些风险提供了可行性的要求和流程。
ISO 26262第6部分专门用于汽车软件级别的产品开发,包含以下开发要求:
- 初始化产品开发
- 软件安全要求规范
- 软件架构设计
- 单元设计与实施
- 单元测试
- 软件集成和测试
- 验证软件安全要求
2.2 汽车编码标准
MISRA C是一套C语言开发标准,最早由MISRA(The Motor Industry Software Reliability Association,汽车工业软件可靠性协会)提出,其目的是增进嵌入式系统的安全性及可移植性,但良好的编码风格指南只是整体解决方案的一小部分,并不能取代正式设计系统的需求。除汽车领域外,其他产业也逐渐开始使用MISRA C:航天、电信、国防、医疗设备、铁路等领域中都已有使用该标准的厂商。
03.ASIL——汽车安全完整性等级
ISO 26262定义了汽车安全完整性等级(Automotive Safety Integrity Level,ASIL),通过对潜在危险进行风险分析,确定危害事件,并判断危害事件的严重性、暴露性和可控性,将安全等级由低到高划分为QM/A/B/C/D。
3.1危害事件(hazard event):
划分ASIL等级,首先需要确认危害事件。汽车领域的危害事件,通常指功能故障(Malfunction)与驾驶场景的组合。
3.1.1 功能故障
众所周知,汽车实现其功能通常通过三个步骤来进行:传感器、ECU、执行器。传感器将外部数据传递给ECU,ECU将决策结果传递给执行器,执行器通过执行决策结果来实现驾驶员需要的功能。功能故障,即指该三者中任意硬件或软件发生失效的情况。
3.1.2 驾驶场景
某些功能故障只有发生在特定的驾驶场景下,才会成为危害事件。
以发生车辆照明系统的“灯非预期熄灭”功能故障为例:在崎岖的山路行驶时,若为能见度较低、视距较短的夜晚,则可能掉下山崖,造成车毁人亡的后果;若为明丽的白天,则不会产生任何影响。
公路类型(国道、高速等)、路面情况(湿滑、冰雪等)、环境条件(转向、超车、制动灯)、人员情况(驾驶员、乘客、路人情况)等,都是判断驾驶场景需要考虑的因素。
3.2 ASIL等级
ASIL将能够对汽车造成特定危险的风险,按以下三种特定类型进行划分:
- 严重性等级:Severity of failure,简称S,按照事件所致伤害或损失的潜在严重性划分为S1/S2/S3。以驾驶员可能受到的伤害为例:S1指轻伤或中等伤害;S2指可以生还的重伤或致命伤;S3指不确定是否能生还的致命伤。
- 暴露性等级:probability of Exposure,简称E,按照驾驶员暴露在危害事件中可能受到伤害的可能性,由低到高E1/E2/E3/E4。E1指,E4指驾驶员将不可避免地受到伤害。
- 可控性等级:Controllability, 简称C,按照驾驶员自身及事件涉及的其他人员通过及时的反应避免特定伤害或损失的能力,由高到低划分为C1/C2/C3。C3指人员无法通过即时反应避免特定伤害的情况。
▲ASIL等级划分表
分析并组合三种性质的风险后,ASIL将与安全无关的功能评定为QM,将能造成最高危害(S3+E4+C3)的功能评定为D。
安全气囊、防抱死制动系统和动力转向系统必须达到安全保障的最严苛等级,即ASIL D级——其失效带来的风险最高。
EPS(Electric Power Steering)电动助力转向系统
电动助力转向系统,指依靠汽车电子控制单元(Electronic Control Unit,ECU)提供扭矩的动力转向系统。ECU是现代汽车的核心电子元件之一,被称为“行车电脑”;扭矩指使物体发生转动的力矩。EPS使ECU根据转向传感装置和车速传感装置传输的信号,确定旋转方向、角度及助力电流的大小,轻松实现车速不同、助力不同的效果,使驾驶兼顾轻便灵活与稳定可靠,降低能耗的同时提高驾控智能水平,且更容易与其它高级安全系统集成。
该系统失效导致的危害有电机产生自主扭矩、死锁扭矩、突发扭矩及不提供助力等,下面以自主扭矩为例,分析EPS的ASIL等级:
经评估,EPS系统的安全目标为:不产生非预期的转向,ASIL等级为D。
04.车辆安全解决方案
系统的ASIL等级越高,其安全性方面的要求就越高,而与之对应的设计开发复杂程度、开发周期、开发成本呈指数级增长,意味着汽车安全需要付出更高的代价,包括更高等级的覆盖率测试要求、更严格的开发流程管理及更先进的技术要求
4.1 虚拟ECU
构建汽车虚拟ECU,实现测试“左移”,成为了实现汽车安全的必然产物。
迪捷软件作为汽车等安全关键领域产品与解决方案提供商,通过涵盖基于模型的系统工程(Model Based System Engineering,MBSE)的整个生命周期的全系列产品,为汽车电子开发提供完整的解决方案,支持虚拟ECU和从系统到软件的车辆虚拟样机设计。
其中,SkyEye(天目全数字实时仿真软件),是基于可视化建模的硬件行为级仿真平台,指通过应用软件仿真技术,逼真地模拟出被测软件运行的物理环境,并通过动态执行被测软件来进行的软件确认与验证活动。SkyEye可以作为虚拟ECU开发平台,将开发过程从台架转移到个人计算机(PC)上,实现ECU软件的快速高效迭代开发。
4.2 持续集成
在代码量激增的当下,越来越多的汽车研发团队开始使用持续集成来保证软件层面的车辆安全。
持续集成(Continuous Integration,CI)以使产品在快速迭代的同时保持高质量为目的,指开发人员定期将代码变更合并到一个中央存储库中,系统自动运行构建和测试的过程。此前,开发人员通常需要基于最新的代码进行手动编译打包测试,费时费力;且往往要在进行集成测试时才能发现bug,而定位错误又将消耗大量时间。
SkyEye不仅可以作为虚拟ECU的开发平台,还可以帮助汽车软件工程师实现测试目的,有着可靠性、安全性等多重保障。
▲SkyEye界面图
SkyEye可以模拟整个嵌入式系统,测试所需代码,开发人员只需将代码提交至仓库,通过WebHook(一种Web接口机制)触发持续集成的条件,SkyEye就会自动完成编译测试并输出报告。
SkyEye还可以使软件工程师通过可视化图形的硬件建模方式,快速搭建汽车硬件模型,在模型上运行和调试与真实硬件相同的二进制文件,并支持自动化测试。同时,SkyEye也可查看和修改处理器寄存器或设备寄存器的数据、查看反汇编、内存值、进行故障注入等。
更多车辆安全相关的最新创新、方法和经验,欢迎访问www.digiproto.com进行了解!
参考文献
[1]《了解ISO 26262 ASIL》CNKI:SUN:DZSQ.0.2013-12-006
这篇关于汽车安全困境:如何破局?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!