1. 脱手驾驶与功能安全的碰撞点在哪第一次接触HWAHighway Assist高速公路辅助这个功能的时候我脑子里冒出来的第一个问题不是这功能怎么实现而是这玩意儿出了事算谁的。后来做功能安全Functional Safety相关的开发才慢慢明白这个问题的答案不在法律条文里而在ISO 26262的框架里。HWA本质上是一个L2级别的驾驶辅助功能它允许驾驶员在特定条件下脱手但眼睛还得看着路随时准备接管。这个脱手但不脱眼的定位就是功能安全设计里最拧巴的地方。为什么这么说因为传统L2功能比如自适应巡航ACC加车道保持LKA默认驾驶员手是搭在方向盘上的系统只需要在驾驶员走神的时候给个提醒就行。但HWA明确允许你把手拿开这就意味着系统必须自己判断现在这个场景我能不能扛得住扛不住的时候还得提前足够长时间告诉驾驶员你该接手了。这个判断逻辑的失效就是功能安全要解决的核心问题。这篇文章适合谁看如果你正在做ADAS域的功能安全开发尤其是涉及L2脱手功能的HARA分析、安全概念设计或者软件组件鉴定那咱们聊的东西应该能对上。如果你刚入行对ISO 26262还停留在听说过的阶段也没关系我会尽量用实际项目里的例子把逻辑讲清楚。整篇内容会围绕HWA这个具体功能把功能安全设计里那些容易踩坑的地方一个个拆开说。2. HWA功能安全设计的整体思路拆解2.1 为什么HWA的功能安全等级通常定在ASIL D做功能安全的人都知道ASIL等级不是拍脑袋定的它来自HARA危害分析与风险评估的三个维度严重度S、暴露率E和可控性C。HWA这个功能有意思的地方在于它的三个维度都容易往高了走。严重度方面HWA工作在高速公路场景车速通常在60km/h以上一旦系统误动作导致车辆偏离车道或者突然减速后果基本就是S3致命或危及生命的伤害。暴露率方面高速公路辅助的使用场景就是高速巡航这个场景在国内虽然不算最高频但E4高概率是跑不掉的。可控性是最关键的也是HWA和普通LKA最大的区别——普通LKA默认驾驶员手在方向盘上可控性可以做到C2甚至C1但HWA允许脱手驾驶员的手不在方向盘上反应时间天然就长了一截可控性直接掉到C3难以控制。S3E4C3查表就是ASIL D。这个结论在行业里基本是共识我参与过的几个HWA项目功能安全等级都是按ASIL D来做的。但这里有个坑不是所有子功能都需要ASIL D。比如HWA的脱手允许条件判断这个子功能如果判断错了导致在不该脱手的时候允许脱手那是ASIL D但脱手提醒的UI显示这个子功能即使显示错了驾驶员也不会因为UI错误而失去对车辆的控制所以可以降到ASIL A甚至QM。这种功能分解的思路是HWA功能安全设计里省成本的关键。2.2 安全目标怎么定才不会被挑战安全目标Safety Goal是功能安全设计的顶层输入它直接决定了后续所有安全机制的设计方向。HWA的安全目标通常围绕避免非预期的横向或纵向运动来定但具体怎么写里面有很多讲究。我见过一些项目把安全目标写成避免HWA功能导致车辆偏离驾驶员预期的行驶轨迹这个写法太模糊了。驾驶员预期这个东西没法量化评审的时候很容易被挑战。更稳妥的写法是拆成两条第一条避免HWA在驾驶员未接管的情况下产生非预期的横向加速度超过X m/s²第二条避免HWA在系统能力边界外仍保持激活状态而不发出接管请求。第一条管的是系统误动作第二条管的是系统该退出的时候不退出。这两条安全目标对应的安全状态也不一样。第一条的安全状态是限制横向加速度输出第二条的安全状态是降级或退出HWA并发出接管请求。把安全目标和安全状态一一对应起来后续做技术安全需求TSR的时候才不会乱。2.3 功能安全与预期功能安全SOTIF的边界怎么划HWA这个功能特别容易把功能安全和预期功能安全SOTIFISO 21448搅在一起。简单说功能安全管的是系统失效导致的不合理风险比如传感器坏了、芯片跑飞了、软件有bugSOTIF管的是系统没坏但性能不够导致的不合理风险比如摄像头在强光下识别不到车道线、雷达把相邻车道的车误判为本车道的前车。做HWA的时候这两者的边界必须划清楚否则HARA做出来的结果会重复或者遗漏。我的经验是凡是能通过检测到失效并进入安全状态来解决的归功能安全凡是系统正常工作但就是做不到的归SOTIF。举个例子摄像头镜头被泥巴糊住了如果系统能检测到镜头遮挡这个失效状态并退出HWA那这是功能安全的范畴但如果系统检测不到遮挡继续用模糊的图像做车道保持那就是SOTIF的问题。实际项目里这两个活动通常是并行的但交付物要分开。功能安全交付的是安全概念、TSR、安全机制SOTIF交付的是场景库、已知不安全场景的缓解措施、验证策略。把这两套东西混在一起写文档评审的时候会被问得很难受。3. 核心细节解析与实操要点3.1 HARA分析中那些容易吵起来的点HARA分析是功能安全的起点也是团队里最容易吵架的环节。HWA的HARA分析里有几个点几乎每个项目都会争论。第一个是暴露率的取值。高速公路辅助的使用场景到底算E3还是E4如果按车辆在高速公路上行驶的时间占比来算国内大部分城市通勤场景可能连E2都不到但如果按HWA功能被激活的时间占比来算那只要功能开着暴露率就是E4。我的做法是看功能的设计运行域ODD如果ODD限定在高速公路且车速大于60km/h那暴露率取E3比较稳妥如果ODD放宽到城市快速路那E4没跑。这个取值直接影响ASIL等级E3和E4在S3C3的情况下一个可能是ASIL C一个就是ASIL D差一个等级开发成本差很多。第二个是可控性的评估。HWA允许脱手可控性天然就差但差到什么程度需要有理有据。我通常会参考几个因素驾驶员接管请求发出后到必须接管的时间窗口通常要求至少10秒、驾驶员在脱手状态下的注意力水平脱手不等于走神但确实比手扶方向盘更容易分心、以及系统降级后的车辆状态是直接退出还是先降级到LKA。把这些因素量化成C2/C3的判定依据评审的时候才站得住脚。第三个是危害事件的粒度。有些团队把HWA非预期横向运动当成一个危害事件这太粗了。横向运动可以拆成非预期左偏和非预期右偏右偏在高速公路上可能直接撞护栏左偏可能撞中央隔离带严重度虽然都是S3但后续的安全机制设计会不一样。粒度拆得越细后续的TSR越有针对性。3.2 技术安全需求TSR怎么写才可落地TSR是安全目标往下分解的第一层它要回答的是系统需要做什么来避免违反安全目标。HWA的TSR通常包括这几类传感器融合的冗余校验、横向控制输出的限幅、驾驶员接管请求的触发条件、系统降级的策略。写TSR的时候最容易犯的错是写得太抽象。比如系统应检测传感器失效这个写法没法验证。好的TSR应该是系统应在摄像头和雷达的横向位置输出差异超过0.5米且持续超过100毫秒时判定为传感器融合失效并在200毫秒内退出HWA功能。有检测条件、有阈值、有时间要求、有安全状态这样的TSR才能直接指导开发和测试。另一个坑是TSR的分配。HWA的TSR要分配到具体的架构元素上比如摄像头、雷达、域控制器、执行器。分配的时候要考虑每个元素的ASIL能力如果某个元素只能做到ASIL B那就要么加冗余要么把TSR分解成ASIL B的部分和ASIL D的部分分别分配。这个分解过程在ISO 26262里叫ASIL分解常用的方案是D分解成B(D)B(D)或者C(D)A(D)。分解不是随便分的需要满足独立性要求两个分解后的元素不能有共因失效。3.3 软件组件鉴定报告到底要写什么最近热词里提到的ISO 26262中功能安全开发的软件组件鉴定报告是很多团队容易忽略的一块。软件组件鉴定Software Component Qualification针对的是那些非按照ISO 26262开发的软件组件比如从供应商买的AUTOSAR基础软件、开源的算法库、或者复用的旧项目代码。HWA项目里最常需要做鉴定的软件组件包括操作系统比如AUTOSAR OS、通信协议栈、诊断模块、以及一些通用的数学库。这些组件通常不是按ASIL D开发的但要用在ASIL D的系统里就需要做鉴定。鉴定报告的核心内容是证明这个组件在特定使用场景下足够可靠。具体要写什么我的经验是包含这几块组件的功能描述和边界、组件的开发过程证据如果供应商能提供、组件的失效模式分析、组件在目标系统里的使用假设、以及验证测试的结果。其中使用假设是最关键的比如一个通信协议栈如果它的使用假设是只传输非安全相关数据那用在HWA的安全通信里就不行如果使用假设是支持E2E保护那还要验证E2E保护的覆盖率。鉴定报告不是写一次就完事的每次组件的版本升级、或者使用场景变化都要重新评估。我见过一个项目供应商升级了AUTOSAR OS的版本但没有重新做鉴定结果在功能安全审核的时候被开了一个不符合项。4. 实操过程与核心环节实现4.1 从HARA到安全概念的完整流程HWA的功能安全开发从HARA到安全概念中间要经过好几个步骤。我把实际项目里的流程梳理一下你可以直接参考。第一步是定义功能的功能边界。HWA的功能边界包括激活条件车速、车道线质量、驾驶员手部状态、退出条件驾驶员接管、系统能力不足、故障、以及功能输出横向控制、纵向控制、人机交互。这个边界定义清楚了HARA才有分析的对象。第二步是识别危害事件。从功能边界出发逐个分析如果这个功能失效了会发生什么。HWA的典型危害事件包括非预期横向运动、非预期纵向减速、该退出时不退出、该提醒时不提醒。每个危害事件都要记录触发条件和车辆状态。第三步是评估S/E/C。这一步需要跨团队协作系统工程师、测试工程师、人机交互工程师都要参与。评估的结果要记录在HARA表格里每个危害事件的S/E/C取值都要有依据。第四步是确定ASIL等级和安全目标。根据S/E/C查表得到ASIL然后为每个ASIL D的危害事件定义安全目标。安全目标要覆盖所有ASIL D的危害事件不能有遗漏。第五步是功能安全概念FSC。FSC描述的是用什么功能安全机制来满足安全目标比如通过传感器冗余来检测融合失效、通过输出限幅来避免非预期横向加速度过大。FSC不涉及具体的技术实现是功能层面的描述。第六步是技术安全概念TSC。TSC把FSC往下分解到具体的架构元素定义每个元素的TSR和安全机制。TSC要跟系统架构设计同步进行确保TSR能分配到具体的硬件和软件上。4.2 横向控制的安全机制怎么设计横向控制是HWA最核心的输出也是功能安全设计的重点。我以非预期横向运动这个危害事件为例说说安全机制怎么设计。第一层防护是输入信号的冗余校验。HWA的横向控制依赖摄像头识别的车道线和雷达识别的周边车辆这两个传感器的输出要互相校验。如果摄像头说车道线在左边0.3米雷达说左边0.8米有车那系统就要判断是不是摄像头识别错了。校验的逻辑通常是如果两个传感器的横向位置差异超过阈值比如0.5米且持续超过一定时间比如100毫秒就判定为融合失效退出HWA。第二层防护是控制输出的限幅。即使输入信号没问题控制算法也可能因为各种原因输出过大的横向加速度。所以要在控制输出后面加一个限幅器把横向加速度限制在合理范围内比如不超过3 m/s²。限幅器的阈值要根据车辆动力学和驾驶员舒适度来定太低了功能没法用太高了安全风险大。第三层防护是驾驶员接管请求的触发。当系统检测到能力边界比如车道线丢失、前方有施工区或者内部故障时要提前发出接管请求。接管请求的触发时间很关键太早了驾驶员觉得烦太晚了来不及接管。行业里通常要求至少提前10秒发出请求但这个时间要根据车速和场景动态调整。高速上可以短一点因为驾驶员注意力相对集中城市快速路上要长一点因为场景更复杂。第四层防护是系统降级策略。如果驾驶员没有在规定时间内接管系统不能直接退出让车辆失控而是要降级到一个安全状态。HWA的降级策略通常是先降级到LKA车道保持如果驾驶员还没接管再降级到ACC自适应巡航最后如果还没接管就触发紧急制动或者靠边停车。这个降级链条要设计得平滑不能有跳变。4.3 软件组件鉴定的实操记录我拿一个实际项目里的软件组件鉴定过程来说。那个项目用的是某供应商的AUTOSAR通信协议栈供应商只提供了QM级别的开发证据但HWA的安全通信需要ASIL D。我们做了以下几件事。第一确认组件的使用假设。供应商的协议栈假设上层应用会做E2E保护所以我们必须在应用层实现E2E保护并且验证E2E保护的覆盖率。E2E保护的机制包括CRC校验、计数器、超时监控这些都要在应用层实现。第二分析组件的失效模式。我们用了FMEA的方法把协议栈的每个模块CAN驱动、CAN接口、PDU路由器、COM模块的失效模式列出来分析每种失效对安全通信的影响。比如CAN驱动的发送缓冲区溢出可能导致安全报文丢失这个失效模式的影响是安全报文未送达严重度是S3。第三做故障注入测试。我们在协议栈的各个模块里注入故障比如位翻转、缓冲区溢出、超时观察E2E保护能不能检测到并触发安全反应。测试的结果要记录在鉴定报告里作为组件在目标使用场景下足够可靠的证据。第四写鉴定报告。报告的结构是组件描述、使用假设、失效模式分析、故障注入测试结果、结论。结论要明确说该组件在满足使用假设的前提下可以用于ASIL D的安全通信。报告要附上测试用例和测试结果方便审核的时候追溯。这个鉴定过程花了大概两个月主要是故障注入测试比较耗时。但做完之后后续的项目复用这个组件就省事了只要使用假设不变鉴定报告可以直接复用。5. 常见问题与排查技巧实录5.1 HARA分析中暴露率和可控性的取值争议这个问题我几乎每个项目都会遇到。暴露率取E3还是E4可控性取C2还是C3不同的人有不同的看法。我的经验是不要试图说服所有人而是用数据说话。暴露率方面可以统计功能在实际使用中的激活时间占比。如果拿不到实际数据就参考类似功能的数据。比如ACC的激活时间占比行业里有公开的研究报告可以引用。可控性方面可以做驾驶员模拟器实验测量驾驶员从脱手状态到接管方向盘的反应时间。这个实验的数据比拍脑袋靠谱得多。如果实在拿不到数据就取保守值。E4和C3虽然会导致ASIL D但开发成本增加有限而且评审的时候不会被挑战。取E3和C2虽然省成本但一旦被挑战重新做HARA的代价更大。5.2 安全机制误触发导致功能不可用HWA的安全机制设计得太敏感会导致功能频繁退出用户体验很差。我见过一个项目摄像头稍微有点脏就退出HWA用户抱怨这功能根本没法用。解决这个问题的关键是平衡安全性和可用性。安全机制的触发阈值不能一刀切要根据场景动态调整。比如摄像头遮挡检测如果只是轻微遮挡比如灰尘可以降级到LKA而不是直接退出HWA如果是严重遮挡比如泥巴才退出HWA。这个分级策略要在TSR里定义清楚。另一个技巧是加去抖动逻辑。安全机制的触发条件不能一满足就立即动作要持续一段时间才动作。比如传感器融合失效的判定要求差异超过阈值持续100毫秒而不是一帧数据异常就退出。去抖动时间的长短要根据信号的噪声特性来定太短了容易误触发太长了响应不及时。5.3 软件组件鉴定报告被审核挑战软件组件鉴定报告最容易被挑战的点是使用假设和证据充分性。审核员会问你怎么证明这个组件在ASIL D的场景下足够可靠如果你的证据只是供应商提供的一份QM证书那肯定不够。我的做法是不管供应商提供了什么证据自己都要做一轮独立的验证。验证的内容包括功能测试、故障注入测试、边界测试。测试的覆盖率要足够高最好能覆盖组件的所有安全相关功能。测试的结果要记录在报告里作为独立验证的证据。另一个容易被挑战的点是组件的版本管理。如果组件的版本升级了但鉴定报告没有更新审核员会认为你的鉴定失效了。所以每次组件升级都要重新评估鉴定报告的有效性必要时重新做测试。5.4 常见问题速查表问题现象可能原因排查思路解决措施HWA频繁退出安全机制阈值过敏感查看退出时的触发条件日志调整阈值或加去抖动逻辑接管请求发出太晚触发条件设计不合理分析接管请求发出时的剩余时间提前触发条件或动态调整时间传感器融合误判校验阈值不合理对比两个传感器的原始数据调整校验阈值或加时间窗口软件组件鉴定被拒证据不充分检查使用假设和测试覆盖率补充独立验证测试ASIL分解不通过独立性不满足分析两个分解元素的共因失效加冗余或调整分解方案6. 功能安全与SOTIF的协同验证怎么做HWA的功能安全验证和SOTIF验证通常是分开做的但实际项目里这两者的验证活动有很多重叠。如果完全分开做会浪费很多资源如果混在一起做又容易遗漏。我的做法是在验证计划阶段就把两者的验证活动对齐共享测试场景和测试数据但验证目标和通过准则分开定义。功能安全的验证目标是证明安全机制在故障注入下能正确触发所以测试用例主要是故障注入测试。SOTIF的验证目标是证明系统在已知不安全场景下能正确响应所以测试用例主要是场景测试。两者的测试场景可以共享比如车道线突然消失这个场景功能安全关注的是系统能不能检测到摄像头失效并退出SOTIF关注的是系统能不能在车道线消失前发出接管请求。验证的通过准则也不一样。功能安全的通过准则是安全机制在规定的故障注入下能在规定时间内进入安全状态SOTIF的通过准则是在已知不安全场景下系统不会产生不合理风险。这两个准则要分别定义分别评估。实际执行的时候我通常会把功能安全的故障注入测试和SOTIF的场景测试放在同一个测试周期里做用同一套测试设备但测试用例和评估标准分开。这样既能节省资源又能保证两者的验证充分性。7. 个人实操体会与建议做HWA的功能安全最大的体会是不要为了做功能安全而做功能安全。ISO 26262的流程和交付物是手段不是目的。目的是让HWA这个功能在脱手场景下足够安全。如果某个交付物对安全没有实际帮助那就要思考是不是可以简化。另一个体会是早介入、早对齐。功能安全不能等到系统设计完了再补那样成本很高。最好在功能定义阶段就让功能安全工程师参与把安全目标和安全概念提前定下来。HWA的很多安全问题如果在功能定义阶段就考虑到了后续的开发会顺畅很多。最后分享一个小技巧做HARA的时候把驾驶员在环这个因素考虑进去。HWA允许脱手但驾驶员还是在环的只是手不在方向盘上。所以可控性的评估不能完全按驾驶员无介入来算要考虑驾驶员看到接管请求后的反应时间。这个反应时间可以通过模拟器实验来测量比拍脑袋靠谱。