功能安全实例：LKA，ACC

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

车功能安全主要关注的是通过实施保护措施，以消除或减轻由车辆级系统的故障或意外行为引起的危险。ISO 26262标准为汽车制造商及其供应商提供了最佳实践，以帮助确保在产品设计的每一步都实现功能安全。评估风险是汽车功能安全计划的第一步，通过危害分析和风险评估（HARA）来识别和评估潜在危险。在HARA期间，OEM为每个已识别的潜在危险分配汽车安全完整性等级（ASIL）等级，表示提高对功能以安全方式运行的信心所需的风险降低量。功能安全的目的不是彻底消除风险，而是把风险降低到一个可接受的范围，这个范围一般由当前的技术发展水平以及社会道德共识来决定。

针对自动驾驶的功能安全分为两个方面内容解决：

1、 道路车辆功能安全解决“电子电器失效”对人造成的危害；

2、 预期功能安全解决“非系统故障原因”对人造成的伤害；

ASIL按照严重性（Severity ）、可能性（Exposure ）和可控性（Controllability: ）评估危害事件的风险级别等级，共分为QM、A、B、C、D五个等级，ASIL D是最高的汽车安全完整性等级，对功能安全的要求也最高。

按照以上的划分并进行组合相加得到的5个ASIL等级,原则是：

（1）基本可控的C0组合和无伤害S0的组合不考虑；

（2）其余组合相加等于7分为ASIL A，等于8分为ASIL B，等于9分为 ASIL C，等于10分为 ASIL D；

（3）其余得分安全评定为QM，只要遵循标准的质量管理流程(IATF16949)，与功能安全无关。

针对汽车功能安全，讲太多概念性的东西不利于理解，我们先上实例，心里有了锚定后再继续拓展。

以下以具体的ADAS系统子功能实例（LKA、ACC）讲解功能安全如何进行分析定义确定相应的ASIL等级，如何根据ASIL等级进行需求分解，以保证最终ADAS系统功能安全满足要求。

1.1 对象定义

1.1.1 对象相关项定义

• 定义LKA整车级功能性的需求；

功能描述：根据引导线将车辆保持在车道中央；

车道保持系统LKA(LaneKeepAssist)通过前视摄像头系统实现。该系统由摄像头、图像处理模块、MCU控制模块、网络适配模块和图像输出模块(可选配)几个部分组成。

LKA功能在车道偏离预警系统LDW的基础上通过车载安全保障感知系统提供的方向盘转角感知及安全响应系统自动调节方向盘角度，当驾驶员无意识情况下(没有提供偏出方向的转向灯等证明驾驶员转向意图的信息)偏出当前行驶车道时帮助驾驶员将车辆保持在当前行驶车道中。

• 定义LKA环境要求

工况描述：具有清晰车道线的行车道；

限制条件：

1、转向力矩过小；

2、速度超过上下限制；

3、脱手时间对整个系统激活有影响；

抑制条件：转向灯, 转向力矩, 制动灯/制动力, EPS状态, 加速踏板状态, 脱手状态

• 定义LKA系统要素

输入信号：车辆速度，横摆角速度，转向角

• 定义LKA与其他关联对象的要求

实现方式：通过发送转向力矩给转向系统EPS进行横向控制，将车辆纠偏至车道中央；

1.1.2 对向回路

在对向回路中，设计LKA相应的对象有如下；

1.2 危险分析和风险评估

1.2.1 危害识别

针对LKA对象回路可能出现的危害识别如下：

• 感知端：无法正确识别车道线，LKA系统无法对实际环境做出正确的响应；

• 决策：LKA功能逻辑仲裁机制、算法不合理，导致输出错误的转向角或转向扭矩；

• 执行：EPS执行机构错误的执行LKA输出的转向角，难以完美控制；

以上描述中重点体现在整车执行错误的转向角及转向扭矩后，车辆偏离原始路径进入别的车道，甚至驶出正常行车道。

1.2.2  功能安全ASIL等级分析

MD遭受了一起严重的黑客入侵事件，黑客Intelbroker 大规模泄漏了AMD的数据。AMD当即发起了调查，在一份声明中表示：“我们正在与执法官员和第三方托管合作伙伴密切合作，调查该指控和数据的意义。”

ASIL（LKA）= S3+E4+C3 =10，所以LKA的ASIL等级为D级

1.3 功能安全目标分解

功能安全标准：最大允许的非期望的车道偏离，即当在一定时间内即将偏离车道行驶后，驾驶员需要接管对车辆的控制，若驾驶员未接管车辆控制，则LKA需自动调节控制恢复整车控制；

每一种扭矩波动都存在相同的风险，其风险分析应包含所有的工况，不同的使用工况其抗风险能力不同，ASIL等级也不相同，LKA系统功能要求执行器在判断超过响应限值情况下，可以具备一定的抗风险能力；

LKA系统总体执行目标是ASIL D，可以分解为控制端和执行端分别产生不同的功能安全要求等级，如下图，最终实现功能安全等级为ASIL D=QM（ADAS）+ASIL D（EPS）；

2.1 对象定义

2.1.1 对象相关项定义

• 定义ACC整车级功能性的需求；

功能描述：ACC采用前雷达或融合前视摄像头探测本车前方车辆，通过发动机管理系统EMS/IMCU或制动系统ESP/IBS来控制本车的速度，并保持与前车合适的跟车距离。

ACC系统工作原理

ACC 系统的状态及其转换

• 定义ACC环境要求

工况描述：一般情况的道路均可正常使用ACC，在隧道或反射面过多的场景下功能可能受影响；

限制条件：

1、加速力矩超过限值；

2、速度超过上下限制；

3、减速度响应超过限值；

抑制条件：制动力/电子手刹, ESP功能状态，加速踏板, 安全带/车门/, ESC/EMS/TCU状态, 驾驶员状态；

• 定义ACC与其他关联对象的要求

实现方式：通过发送正向扭矩给动力系统EMS进行加速控制，将车辆加速至期望的速度值；通过发送减速度给制动系统ESP进行减速控制，将车辆减速至期望的速度值；

2.2 危险分析和风险评估

2.2.1 危害识别

针对ACC 对象回路可能出现的危害识别如下：

• 感知端：无法正确探测到前方目标，ACC系统无法对实际环境做出正确的响应；

• 决策：ACC功能逻辑仲裁机制、算法不合理，导致输出错误的制动力或驱动扭矩；

• 执行：EMS错误的执行ACC输出的扭矩请求，ESP错误的执行ACC输出的制动请求；

以上描述中重点体现在整车执行错误的扭矩请求及制动请求后，车辆加速异常或减速异常。

2.2.2  功能安全ASIL等级分析

针对不同的功能安全目标输出进行不同的风险分析，最终得出每一项功能安全目标对应的ASIL等级：

2.3 功能安全目标分解

功能安全标准：最大允许的非期望的自车加速或制动，即当在一定时间内自车产生非期望的加速或制动后，驾驶员需要接管对车辆的控制，若驾驶员未接管车辆控制，则ACC需自动调节恢复整车控制；

2.3.1 功能安全分解

• 危害性分析（HazardAnalysis）：避免执行太高或非期望的制动力；

• 功能安全目标：ASIL C

• 危害性分析（HazardAnalysis）：避免执行太低的制动力；

• 功能安全目标：ASIL D

• 危害性分析（HazardAnalysis）：避免太高或非期望驱动扭矩；

• 危害性分析（HazardAnalysis）：避免太低的驱动扭矩；

• 功能安全目标：ASIL A；

• 功能安全目标：ASIL C；

由于以上分解方式，LKA端的功能安全为QM，ACC端功能安全也为QM，也即无功能安全要求，具体到每种工况下相应系统的功能安全将由相关执行器EPS/ESP/EMS来实现。根据ISO26262推荐查表，可以从减少EPS硬件单点失效率，潜在失效率，随机硬件失效率来实现。比如针对LKA要求EPS功能安全为ASIL D，则对EPS硬件失效的要求可表示如下。

• Signal-point fault metric > 99%

• Latent fault metric > 90%

• Random hardware failure rate < 10-8/h

3.1 软件安全需求策略

ADAS软件开发层面需要重点关注由于发送或执行端失效即将违反功能安全目标时，如何通过软件控制整车不失控并维持在一个安全状态。

如下举例针对部分软件控制对功能安全的策略：

• LKA通过从执行器EPS软件层面上可通过限制执行的最大扭矩，当ADAS发送端扭矩过大超过执行端限制扭矩值时，执行端只执行到其功能安全允许的最大扭矩值。

• ACC通过发送保压请求给ESP进行保压，当驾驶工况进入的是坡道或其他极端工况时，车辆溜车，则ADAS系统可以通过ESP进行二次加压，或直接拉起电子手刹保持车辆不溜车，维持安全目标。

目前大致了解了功能安全如何进行分析，对于工程师来说，开发的进阶性远不止如此，比如针对市场对ADAS系统的其中一个抱怨点就是ACC跟停时间太短（目前行业标准是3s），但是针对功能安全分析我们不难发现，该时间受限于驾驶员是否在车内这一因素，因为系统需要确保重新起步过程中，整车具有足够的横向受控力。

如上图描述了相应的提升方案，从系统层面上需要达到功能安全B级，ADAS端只能满足QM，那么剩余的要求是对系统需要保证驾驶员在车内的要求，那么就可以通过要求另外的关联系统如车门、安全带等输入信号告诉系统驾驶员在车内，并且这些信号满足ASIL B即可。

ASIL D级SoC芯片的现实意义

ASIL等级决定了对系统安全性的要求，ASIL等级越高，对系统的安全性要求越高，为实现安全付出的代价越高，意味着硬件的诊断覆盖率越高，开发流程越严格，相应的开发成本增加、开发周期延长、技术要求更严格。下表是ASIL等级评估对照表，可以看出，如果安全等级到达D级，则意味着整个系统范围内单点故障率不超过1%。

如果你的汽车整体符合ISO 26262 ASIL-D级标准，那意味着在面对某些临界安全问题时，汽车已经可以代替您做出决策了。而对于整车ASIL-B级标准的汽车来说，汽车只会提醒驾驶员危险来临，具体动作仍需要驾驶员执行。

就目前来说，实际落地的ADAS系统仍需要驾驶员随时准备介入控制。那么，为什么业界对ASIL-D级芯片产生了如此迫切的需求呢？ASIL-D级的SoC真的有现实意义么？

问题的答案在汽车OEM厂商身上，因为OEM厂商需要在产品稳定性与开发速度之间做取舍，而可靠性不足极其容易导致诉讼缠身。

一方面，整个业界正在快马加鞭地部署高性能计算系统，为自动驾驶决策提供算力；另一方面，在自动驾驶汽车上，品类繁多的汽车控制子系统必须保证提供多种智能化功能的同时，保持高级别的安全性。

基于此，业界在拥抱自动驾驶的同时，OEM厂商也在寻找工程上可行的解决方案。这种方案必须在满足苛刻安全标准的同时，提供快速的产品迭代能力，并提供足够的算力。而符合安全标准的SoC芯片正是解决这个棘手问题的最优解。

汽车领域独立数据调研机构IHS Markit则从另一个角度得出了相似的结论。他们认为，OEM厂商尚未对ASIL-D提出明确的要求，因为从需求层面上目前还不紧迫。但是，如果ASIL-D级别的芯片与普通芯片价格相同，所有OEM厂商都将很乐意使用并推广，因为这种方案显然能够节省他们的研发成本，而且还让OEM厂商避免因器件稳定性不足导致的诉讼。

来源：无人驾驶俱乐部