1. 从一次深夜评审聊起HWA脱手驾驶到底难在哪去年冬天我参与了一个高速公路辅助HWA项目的功能安全评审。凌晨两点会议室白板上画满了转向扭矩曲线和驾驶员监控状态机争论的焦点只有一个当系统允许驾驶员脱手的那几秒钟里功能安全边界到底该划在哪里。这不是学术讨论而是直接决定项目能否按期交付、以及后续路上跑的车敢不敢放开方向盘的问题。HWA全称Highway Assist高速公路辅助是L2级驾驶辅助里最接近“脱手”体验的一类功能。它把纵向的车距保持和横向的车道居中揉在一起在封闭高速路段让驾驶员可以短暂松开方向盘。但“脱手”两个字背后藏着功能安全设计里最棘手的一堆问题系统怎么知道驾驶员还在脱手多久算安全如果驾驶员没接管车该怎么办这些问题不是靠堆传感器就能解决的它需要一套从危害分析到软件组件鉴定的完整链条。这篇文章适合谁看如果你正在做L2/L2驾驶辅助的功能安全开发或者你负责HWA、TJA这类脱手功能的系统设计再或者你只是对ISO 26262里“软件组件鉴定报告”这个热词感到好奇那接下来的内容应该能帮你少走几个月的弯路。我会从整体设计思路讲到具体实操把脱手驾驶的功能安全考量拆成能落地的步骤也会分享几个我在评审现场踩过的坑。2. HWA脱手驾驶的功能安全整体设计思路2.1 为什么HWA不能简单套用普通LKA的安全方案很多人第一反应是HWA不就是LKA加个自适应巡航吗安全设计照搬不就行了。我一开始也这么想过直到把两者的危害事件摆在一起对比才发现根本不是一回事。普通车道保持辅助LKA的前提是驾驶员手扶方向盘系统只是提供辅助扭矩驾驶员随时可以覆盖。它的安全目标相对单纯别跟驾驶员抢方向盘别在驾驶员想变道时硬拽。但HWA允许脱手意味着在脱手窗口期内驾驶员对横向控制的参与度急剧下降系统从“辅助者”变成了“实际控制者”。这时候如果系统失效驾驶员可能来不及反应。我习惯用一个类比LKA像副驾驶帮你轻轻扶一下方向盘HWA像副驾驶替你开一会儿而你双手放在膝盖上。副驾驶扶一下出错你瞬间就能纠正副驾驶替你开的时候出错你得先反应过来、再把手放回方向盘、再施加纠正这个反应链条长得多。功能安全设计要覆盖的正是这个“反应链条”里的每一环。所以HWA的安全方案必须回答三个普通LKA不需要回答的问题第一脱手状态如何被可靠地检测和确认第二脱手窗口期的时间边界怎么定第三窗口期结束前如何确保驾驶员有效接管。这三个问题贯穿了从危害分析到软件架构的整个设计过程。2.2 从HARA到安全目标的推导逻辑做功能安全第一步永远是危害分析与风险评估HARA。HWA的HARA有个特点同一个功能失效在“手扶”和“脱手”两种状态下严重度S、暴露率E、可控性C的取值完全不同。我拿“转向扭矩输出异常”这个失效模式举例。在驾驶员手扶方向盘时即使系统输出一个错误的扭矩驾驶员能立刻感知并覆盖可控性C可以评到C1或C2。但在脱手状态下驾驶员没有直接的力反馈错误扭矩可能让车辆缓慢偏离车道等驾驶员发现时已经晚了可控性直接掉到C3。可控性一变ASIL等级就可能从ASIL B跳到ASIL D。这个推导过程不能拍脑袋得有依据。我们当时的做法是把脱手窗口期按时间切片分别评估每个切片内的可控性。比如脱手后0到3秒驾驶员注意力还在可控性较好3到10秒注意力开始漂移可控性下降超过10秒可控性显著恶化。每个切片对应不同的安全目标最终取最严苛的那个作为系统级安全目标。这里有个实操心得HARA评审时一定要拉上人因工程HMI的同事。可控性评估本质上是对驾驶员反应能力的假设这个假设如果不和HMI的驾驶员监控策略对齐后面安全目标定得再漂亮也是空中楼阁。我们第一次评审就吃了这个亏安全团队按理想反应时间算HMI团队按实际监控延迟算两边对不上返工了两周。2.3 安全目标如何分解到系统与软件层级安全目标定下来之后要一层层往下分解。HWA的典型安全目标大概是这样的在脱手窗口期内系统应避免输出导致车辆偏离预期行驶路径的转向扭矩当驾驶员未能在规定时间内接管时系统应执行降级策略以降低风险。从安全目标到技术安全需求TSR再到软件安全需求SSR每一步都要可追溯。我见过不少项目在这里偷懒安全目标写得很宏观到了软件层就变成“转向模块应安全”这种需求没法验证也没法做软件组件鉴定。正确的做法是把安全目标拆成可测量、可验证的条目。比如“避免输出导致偏离的转向扭矩”可以拆成转向扭矩请求的幅值不得超过当前车速和曲率下的安全包络扭矩请求的变化率不得超过标定上限当车道线置信度低于阈值时扭矩请求应在X毫秒内归零。这些条目每一条都能对应到具体的软件组件和测试用例。软件组件鉴定报告在这里就派上用场了。ISO 26262对软件组件鉴定Software Component Qualification有明确要求尤其是当你在用非按标准开发的软件组件比如成熟度很高的旧模块、或者来自非汽车领域的算法库时鉴定报告就是证明这个组件“够格”用在安全相关功能里的关键证据。HWA项目里经常复用车距保持或车道居中的老代码这些代码当年可能没按ASIL D开发现在要提升安全等级鉴定报告就是绕不开的一环。3. 脱手检测与驾驶员监控的核心细节3.1 脱手检测的传感器方案与冗余设计脱手检测是HWA功能安全的第一道门。如果这道门失灵系统以为驾驶员还扶着方向盘实际上人已经放手后面的安全策略全部失效。主流的脱手检测方案有两类基于转向扭矩的检测和基于电容感应的检测。扭矩检测靠的是驾驶员手扶方向盘时产生的微小扭矩扰动电容感应靠的是方向盘上的电容传感器感知人手接触。两者各有短板扭矩检测在驾驶员手很轻地搭着时可能误判为脱手电容感应则容易被手套、方向盘套干扰。从功能安全角度单一传感器方案很难满足ASIL D对独立性和冗余的要求。我们当时的做法是扭矩检测和电容感应并行两个通道独立采集、独立判断只有两个通道都确认脱手系统才进入脱手状态。如果两个通道结论不一致系统按“手扶”处理同时触发传感器故障告警。这个策略的逻辑是宁可误判为手扶保守也不能误判为脱手危险。冗余设计里有个细节容易被忽略两个通道的供电和信号链路要尽量独立。如果共用一个电源芯片电源一挂两个通道同时失效冗余就形同虚设。我们在PCB布局时把扭矩信号调理和电容信号调理分到不同的电源域虽然增加了成本但这是ASIL D的硬要求。3.2 脱手窗口期的时间边界怎么定脱手窗口期定多长是HWA设计里最纠结的参数之一。定短了用户体验差频繁提示接管定长了安全风险高驾驶员注意力漂移严重。这个参数不能只从技术角度拍得结合人因研究和法规要求。当时我们参考了几个来源一是内部的人因实验数据测试驾驶员在模拟器里脱手后注意力衰减的曲线二是行业里同类功能的公开标定值三是法规对驾驶员监控的基本要求。综合下来我们把初始窗口期定在15秒左右然后根据驾驶员监控系统的置信度动态调整。动态调整的逻辑是这样的如果驾驶员监控摄像头显示驾驶员视线仍在道路前方、头部姿态正常窗口期可以适当延长如果视线偏离超过阈值窗口期立即缩短并提前触发接管提示。这个动态策略比固定窗口期复杂得多但安全收益明显。实现上它需要驾驶员监控系统和HWA控制器之间有低延迟的状态同步这个同步链路的失效模式也要纳入功能安全分析。注意窗口期参数一旦定下来不要轻易在项目后期改动。它牵涉到HARA的可控性假设、安全目标的验证用例、以及大量标定工作。后期改动等于把前面的安全分析推倒重来。3.3 驾驶员接管意图的识别与确认脱手窗口期结束前系统要确认驾驶员是否有效接管。这里的“有效”两个字很关键。驾驶员手搭上方向盘不等于接管可能只是无意识地搭着注意力还在手机上。我们把接管确认分成三个层次物理接触确认手是否在方向盘上、操作意图确认是否有转向或制动的主动输入、注意力确认视线和头部姿态是否回到驾驶任务。三个层次都满足才判定为有效接管。如果只满足物理接触系统会继续发出接管提示并准备降级策略。这个多层次确认的逻辑在软件架构上体现为状态机的多条件跳转。状态机设计时要注意避免“抖动”驾驶员手短暂搭一下又松开系统不能反复在“已接管”和“脱手”之间跳。我们加了去抖时间和滞回阈值去抖时间取200毫秒左右滞回阈值根据方向盘扭矩和电容信号的噪声水平标定。4. 功能安全机制在HWA中的落地实现4.1 转向扭矩安全包络的设计与验证转向扭矩安全包络是HWA功能安全的核心机制。它的作用是不管上游算法输出什么扭矩请求最终到执行器的扭矩都不能超出当前工况下的安全边界。安全包络的设计分两步第一步是离线计算根据车速、道路曲率、路面附着系数等参数算出理论上不会导致车辆失稳的最大扭矩第二步是在线限制实时监控扭矩请求一旦超出包络就截断或限幅。离线计算用车辆动力学模型跑仿真在线限制用查表加插值实现保证实时性。验证安全包络时我们用了故障注入的方法人为让上游算法输出一个超大的扭矩请求看包络能不能在规定的响应时间内把它压回安全范围。响应时间是关键指标我们当时的要求是10毫秒以内因为超过这个时间车辆横向位移可能已经超出可接受范围。实测下来查表加插值的方案在典型工况下能做到5毫秒左右满足要求。这里有个经验安全包络的标定不能只在干燥路面做。湿滑路面、弯道、上下坡的组合工况下安全边界会明显收窄。我们当时在冬季试验场专门跑了低附着路面的标定发现同样车速和曲率下湿滑路面的安全扭矩只有干燥路面的六成左右。如果包络不随附着系数调整湿滑路面上就会过于激进。4.2 降级策略与最小风险状态的设计当驾驶员未能在窗口期内接管系统必须执行降级策略把车辆带到最小风险状态MRC。HWA的降级策略不是简单的“退出功能”因为退出瞬间驾驶员可能还没接管车辆会突然失去横向控制。我们的降级策略分三级第一级是增强提示通过声音、震动、仪表弹窗多通道提醒驾驶员第二级是减速并保持车道系统逐步降低车速同时继续维持车道居中给驾驶员争取更多接管时间第三级是减速至停车如果驾驶员始终不接管系统在确认周围安全的前提下把车减速停到应急车道或本车道内。每一级降级都有对应的功能安全需求。比如第二级里“保持车道”的转向控制其安全等级不能低于正常HWA功能因为这时候驾驶员更可能没在关注。第三级的停车策略要考虑后车追尾风险需要结合后向雷达判断这部分又牵涉到另一个功能的安全分析。提示降级策略的触发条件要避免和驾驶员监控的误报耦合。如果驾驶员监控误判脱手系统可能在不该降级的时候降级反而制造风险。所以驾驶员监控本身的失效模式也要做FMEA关键误报路径要有冗余确认。4.3 软件组件鉴定报告在HWA项目中的实际应用软件组件鉴定报告这个词最近很热但很多人不清楚它在HWA项目里具体怎么用。我拿我们项目里的一个实例来说明。我们复用了上一代车型的车道居中控制模块这个模块当年是按ASIL B开发的现在HWA需要它达到ASIL D。直接复用不行重新开发周期又太长。这时候软件组件鉴定就派上用场了我们按照ISO 26262-8第12章的要求对这个模块做了一套鉴定活动包括详细设计审查、代码静态分析、单元测试覆盖率补测、以及针对ASIL D的额外验证。鉴定报告的核心是证明这个组件在目标应用场景下的适用性。报告里要写清楚组件的原始开发背景、鉴定活动的范围和深度、鉴定结果与ASIL D要求的差距、以及为弥补差距采取的额外措施。我们当时补了大约30%的单元测试用例重点覆盖转向扭矩计算的边界条件和故障路径最终鉴定报告通过了内部功能安全评审。实操心得软件组件鉴定不是“免死金牌”它只是证明组件够格的一种手段。鉴定报告写得好不好关键看鉴定活动的证据链是否完整。我见过有的报告只列了测试通过率没有说明测试用例怎么选的、覆盖了哪些安全需求这种报告在评审时会被直接打回。5. 实操过程从需求到验证的完整链路5.1 需求阶段的危害分析与安全目标定义需求阶段最花时间的是HARA。我们当时的流程是先由系统工程师列出HWA的所有功能失效模式然后安全工程师和HMI工程师一起对每个失效模式在“手扶”和“脱手”两种状态下分别评估S/E/C。评估可控性时我们做了一个驾驶员反应时间模型输入是脱手时长、驾驶员监控置信度、提示方式输出是驾驶员有效接管所需时间的分布。这个模型不是拍脑袋而是基于内部驾驶模拟器实验数据拟合的。模型输出用于支撑C值的评定让评估结果有数据背书。安全目标定义时要注意颗粒度。太粗没法分解太细又容易陷入实现细节。我们的经验是安全目标描述“避免什么”和“在什么条件下”不描述“怎么实现”。比如“在脱手窗口期内避免输出导致车辆偏离的转向扭矩”就是一个合适的安全目标它没有规定用包络还是用其他机制给后续设计留了空间。5.2 系统架构设计中的安全机制部署系统架构阶段要把安全目标翻译成具体的安全机制并分配到各个ECU和传感器上。HWA的安全机制主要分布在三个节点前视摄像头负责车道线和目标检测驾驶员监控摄像头负责脱手和注意力判断域控制器负责融合、决策和扭矩计算。安全机制部署时有个原则关键判断要有交叉验证。比如“驾驶员是否脱手”这个判断不能只依赖驾驶员监控摄像头还要结合方向盘扭矩信号。两个信号在域控制器里做一致性检查不一致时按保守策略处理。这个交叉验证的逻辑要写进系统安全需求并在架构图上明确标注。通信链路的安全也不能忽视。HWA的扭矩请求从域控制器发到转向执行器走的是CAN或以太网。这条链路上要有E2E保护包括CRC校验、计数器、超时监控。E2E保护的参数如CRC多项式、计数器位宽要根据链路的数据率和安全等级来选选完要做故障注入测试验证。5.3 软件实现中的安全机制编码要点软件实现阶段安全机制的编码有几个容易踩的坑。第一个是浮点运算的确定性问题。安全包络计算里如果用了浮点不同编译器优化等级下结果可能有微小差异这个差异在边界工况下可能被放大。我们的做法是关键的安全判断用定点运算浮点只用在非安全相关的舒适性计算里。第二个是看门狗和程序流监控的配置。HWA控制器的程序流监控要覆盖安全相关的任务监控超时时间要小于故障容忍时间间隔FTTI。FTTI是从故障发生到可能造成危害的最长时间这个时间在HARA里已经算过。程序流监控的超时时间一般取FTTI的三分之一到二分之一留出故障检测和反应的时间。第三个是内存保护。安全相关的变量和代码段要有MPU保护防止非安全任务越界写。我们在项目里把转向扭矩计算相关的变量单独放在一个受保护的RAM区非安全任务没有写权限。这个配置在AUTOSAR的OS模块里做配置完要用故障注入验证保护是否生效。5.4 验证阶段的故障注入与覆盖率评估验证阶段是检验功能安全设计是否真正落地的环节。故障注入测试是重头戏我们当时设计了三大类注入传感器信号注入如篡改扭矩信号、模拟摄像头丢帧、通信故障注入如丢包、延迟、CRC错误、执行器故障注入如模拟转向电机响应异常。每类注入都要有明确的通过判据。比如传感器信号注入的判据是系统应在FTTI内检测到故障进入降级状态且降级过程不产生新的危害。判据要提前定义好不能测完再补否则容易变成“结果导向”的测试失去验证意义。覆盖率评估分两部分需求覆盖率和代码覆盖率。需求覆盖率看每个安全需求是否有对应的测试用例代码覆盖率看安全相关代码的语句、分支、MC/DC覆盖情况。ASIL D对MC/DC覆盖率有明确要求我们当时在转向扭矩计算模块上补了不少用例才达标。覆盖率报告要和安全需求追溯矩阵一起提交形成完整的证据链。6. 常见问题与排查技巧实录6.1 脱手检测误报与漏报的排查思路脱手检测的误报把有手判成脱手和漏报把脱手判成有手是HWA项目里最常见的两类问题。误报会导致频繁提示接管用户体验差漏报则直接威胁安全。排查误报时先看扭矩信号的噪声水平。如果方向盘扭矩传感器噪声大微小的手扶扭矩会被淹没系统就容易误判脱手。我们的做法是加自适应滤波滤波参数根据车速和路面激励动态调整。高速平整路面上滤波可以强一些粗糙路面上要弱一些避免把真实的手扶信号滤掉。排查漏报时重点看电容感应的灵敏度。方向盘套、手套、甚至驾驶员手部干燥都会影响电容信号。我们当时在标定现场准备了不同材质的方向盘套和手套逐一测试电容信号的变化范围然后调整检测阈值。阈值不能一刀切要分档根据电容信号的基线漂移动态调整。注意脱手检测的标定数据要覆盖不同季节和气候条件。冬季干燥、夏季潮湿电容信号的基线差异明显。我们吃过一次亏夏天标定的参数到冬天就出现漏报后来加了温度补偿才解决。6.2 安全包络触发后的车辆行为异常排查安全包络触发后车辆行为异常通常表现为两种一种是扭矩截断太猛车辆出现明显的横向顿挫另一种是包络触发后系统没有及时降级车辆继续以不安全的状态行驶。第一种问题的根源往往是包络的限幅策略太激进。直接截断扭矩请求会导致横向加速度突变乘客会感到不适。我们的改进是加一个渐变限幅在几十毫秒内把扭矩平滑地压到安全边界而不是瞬间截断。渐变的时间常数要标定太短了顿挫太长了安全响应不及时。第二种问题通常是降级状态机的跳转条件有漏洞。比如包络触发后系统应该进入降级状态但如果降级状态机的入口条件写得不严谨可能被其他状态覆盖。排查时要把状态机的所有跳转路径画出来逐一检查入口和出口条件重点看有没有“优先级反转”的情况。6.3 软件组件鉴定报告被质疑时的应对软件组件鉴定报告在评审时被质疑通常集中在两个点鉴定活动的充分性和鉴定结论的可靠性。鉴定活动充分性被质疑时要回到ISO 26262-8第12章的要求逐条对照。报告里要明确列出组件的原始开发过程、鉴定活动的范围做了哪些分析、哪些测试、鉴定活动的深度测试覆盖率、分析详细程度、以及鉴定结果与目标ASIL的差距分析。如果某一条要求没做到要说明理由和补偿措施。鉴定结论可靠性被质疑时重点展示证据链。比如你说组件满足ASIL D的单元测试覆盖率要求就要附上覆盖率报告和测试用例清单说明用例是怎么从安全需求推导出来的。评审专家如果对某个用例有疑问要能当场追溯到对应的安全需求和代码实现。我个人的经验是鉴定报告不要写成“证明组件没问题”的辩护词而要写成“展示鉴定过程和结果”的技术文档。把局限性也写清楚反而更容易获得评审信任。6.4 常见问题速查表问题现象可能原因排查方向解决措施脱手误报频繁扭矩噪声大、电容阈值低查扭矩信号频谱、电容基线自适应滤波、动态阈值脱手漏报电容灵敏度不足、温度漂移查电容信号幅值、温度补偿分档阈值、温度补偿包络触发顿挫限幅策略太激进查扭矩截断速率渐变限幅、标定时间常数降级不及时状态机跳转条件漏洞查状态机所有跳转路径修正入口条件、加优先级鉴定报告被质疑证据链不完整对照ISO 26262-8第12章补鉴定活动、完善追溯E2E保护失效CRC或计数器配置错误查E2E配置参数按链路数据率重配程序流监控误触发超时时间太短查任务执行时间分布调整超时、优化任务调度7. 几个我踩过的坑和最后的建议第一个坑是低估了HARA评审的沟通成本。功能安全、HMI、系统、软件四个团队对“可控性”的理解天然有差异如果不提前对齐术语和假设评审会变成各说各话。后来我们养成了一个习惯HARA评审前先开一个预沟通会把评估模板和假设条件发给大家会上只讨论分歧点效率高了很多。第二个坑是安全包络的标定数据复用。我们一开始想直接用上一代车型的标定数据结果发现新一代车型的转向传动比和悬架特性变了同样的扭矩对应的横向加速度不一样包络必须重新标。这件事的教训是安全相关的标定数据没有“通用”一说车型一变就得重来。第三个坑是软件组件鉴定报告的时机。我们一开始把鉴定报告放在项目后期做结果发现鉴定活动需要补的测试用例太多后期时间不够差点影响交付。后来调整了策略在架构设计阶段就识别出需要鉴定的组件提前启动鉴定活动把测试用例的补充和正常开发并行做时间就宽裕多了。如果让我给正在做HWA功能安全的同行一句建议那就是把脱手窗口期当成一个动态的安全边界来设计而不是一个固定的计时器。驾驶员的状态在变道路环境在变系统的置信度也在变安全策略只有跟着变才能真正兜住底。至于软件组件鉴定报告早点启动、写清楚证据链、别怕暴露局限它就不是负担而是帮你把老代码用出新价值的工具。 HWA脱手驾驶功能安全设计：从HARA到软件组件鉴定报告
1. 从一次深夜评审聊起HWA脱手驾驶到底难在哪去年冬天我参与了一个高速公路辅助HWA项目的功能安全评审。凌晨两点会议室白板上画满了转向扭矩曲线和驾驶员监控状态机争论的焦点只有一个当系统允许驾驶员脱手的那几秒钟里功能安全边界到底该划在哪里。这不是学术讨论而是直接决定项目能否按期交付、以及后续路上跑的车敢不敢放开方向盘的问题。HWA全称Highway Assist高速公路辅助是L2级驾驶辅助里最接近“脱手”体验的一类功能。它把纵向的车距保持和横向的车道居中揉在一起在封闭高速路段让驾驶员可以短暂松开方向盘。但“脱手”两个字背后藏着功能安全设计里最棘手的一堆问题系统怎么知道驾驶员还在脱手多久算安全如果驾驶员没接管车该怎么办这些问题不是靠堆传感器就能解决的它需要一套从危害分析到软件组件鉴定的完整链条。这篇文章适合谁看如果你正在做L2/L2驾驶辅助的功能安全开发或者你负责HWA、TJA这类脱手功能的系统设计再或者你只是对ISO 26262里“软件组件鉴定报告”这个热词感到好奇那接下来的内容应该能帮你少走几个月的弯路。我会从整体设计思路讲到具体实操把脱手驾驶的功能安全考量拆成能落地的步骤也会分享几个我在评审现场踩过的坑。2. HWA脱手驾驶的功能安全整体设计思路2.1 为什么HWA不能简单套用普通LKA的安全方案很多人第一反应是HWA不就是LKA加个自适应巡航吗安全设计照搬不就行了。我一开始也这么想过直到把两者的危害事件摆在一起对比才发现根本不是一回事。普通车道保持辅助LKA的前提是驾驶员手扶方向盘系统只是提供辅助扭矩驾驶员随时可以覆盖。它的安全目标相对单纯别跟驾驶员抢方向盘别在驾驶员想变道时硬拽。但HWA允许脱手意味着在脱手窗口期内驾驶员对横向控制的参与度急剧下降系统从“辅助者”变成了“实际控制者”。这时候如果系统失效驾驶员可能来不及反应。我习惯用一个类比LKA像副驾驶帮你轻轻扶一下方向盘HWA像副驾驶替你开一会儿而你双手放在膝盖上。副驾驶扶一下出错你瞬间就能纠正副驾驶替你开的时候出错你得先反应过来、再把手放回方向盘、再施加纠正这个反应链条长得多。功能安全设计要覆盖的正是这个“反应链条”里的每一环。所以HWA的安全方案必须回答三个普通LKA不需要回答的问题第一脱手状态如何被可靠地检测和确认第二脱手窗口期的时间边界怎么定第三窗口期结束前如何确保驾驶员有效接管。这三个问题贯穿了从危害分析到软件架构的整个设计过程。2.2 从HARA到安全目标的推导逻辑做功能安全第一步永远是危害分析与风险评估HARA。HWA的HARA有个特点同一个功能失效在“手扶”和“脱手”两种状态下严重度S、暴露率E、可控性C的取值完全不同。我拿“转向扭矩输出异常”这个失效模式举例。在驾驶员手扶方向盘时即使系统输出一个错误的扭矩驾驶员能立刻感知并覆盖可控性C可以评到C1或C2。但在脱手状态下驾驶员没有直接的力反馈错误扭矩可能让车辆缓慢偏离车道等驾驶员发现时已经晚了可控性直接掉到C3。可控性一变ASIL等级就可能从ASIL B跳到ASIL D。这个推导过程不能拍脑袋得有依据。我们当时的做法是把脱手窗口期按时间切片分别评估每个切片内的可控性。比如脱手后0到3秒驾驶员注意力还在可控性较好3到10秒注意力开始漂移可控性下降超过10秒可控性显著恶化。每个切片对应不同的安全目标最终取最严苛的那个作为系统级安全目标。这里有个实操心得HARA评审时一定要拉上人因工程HMI的同事。可控性评估本质上是对驾驶员反应能力的假设这个假设如果不和HMI的驾驶员监控策略对齐后面安全目标定得再漂亮也是空中楼阁。我们第一次评审就吃了这个亏安全团队按理想反应时间算HMI团队按实际监控延迟算两边对不上返工了两周。2.3 安全目标如何分解到系统与软件层级安全目标定下来之后要一层层往下分解。HWA的典型安全目标大概是这样的在脱手窗口期内系统应避免输出导致车辆偏离预期行驶路径的转向扭矩当驾驶员未能在规定时间内接管时系统应执行降级策略以降低风险。从安全目标到技术安全需求TSR再到软件安全需求SSR每一步都要可追溯。我见过不少项目在这里偷懒安全目标写得很宏观到了软件层就变成“转向模块应安全”这种需求没法验证也没法做软件组件鉴定。正确的做法是把安全目标拆成可测量、可验证的条目。比如“避免输出导致偏离的转向扭矩”可以拆成转向扭矩请求的幅值不得超过当前车速和曲率下的安全包络扭矩请求的变化率不得超过标定上限当车道线置信度低于阈值时扭矩请求应在X毫秒内归零。这些条目每一条都能对应到具体的软件组件和测试用例。软件组件鉴定报告在这里就派上用场了。ISO 26262对软件组件鉴定Software Component Qualification有明确要求尤其是当你在用非按标准开发的软件组件比如成熟度很高的旧模块、或者来自非汽车领域的算法库时鉴定报告就是证明这个组件“够格”用在安全相关功能里的关键证据。HWA项目里经常复用车距保持或车道居中的老代码这些代码当年可能没按ASIL D开发现在要提升安全等级鉴定报告就是绕不开的一环。3. 脱手检测与驾驶员监控的核心细节3.1 脱手检测的传感器方案与冗余设计脱手检测是HWA功能安全的第一道门。如果这道门失灵系统以为驾驶员还扶着方向盘实际上人已经放手后面的安全策略全部失效。主流的脱手检测方案有两类基于转向扭矩的检测和基于电容感应的检测。扭矩检测靠的是驾驶员手扶方向盘时产生的微小扭矩扰动电容感应靠的是方向盘上的电容传感器感知人手接触。两者各有短板扭矩检测在驾驶员手很轻地搭着时可能误判为脱手电容感应则容易被手套、方向盘套干扰。从功能安全角度单一传感器方案很难满足ASIL D对独立性和冗余的要求。我们当时的做法是扭矩检测和电容感应并行两个通道独立采集、独立判断只有两个通道都确认脱手系统才进入脱手状态。如果两个通道结论不一致系统按“手扶”处理同时触发传感器故障告警。这个策略的逻辑是宁可误判为手扶保守也不能误判为脱手危险。冗余设计里有个细节容易被忽略两个通道的供电和信号链路要尽量独立。如果共用一个电源芯片电源一挂两个通道同时失效冗余就形同虚设。我们在PCB布局时把扭矩信号调理和电容信号调理分到不同的电源域虽然增加了成本但这是ASIL D的硬要求。3.2 脱手窗口期的时间边界怎么定脱手窗口期定多长是HWA设计里最纠结的参数之一。定短了用户体验差频繁提示接管定长了安全风险高驾驶员注意力漂移严重。这个参数不能只从技术角度拍得结合人因研究和法规要求。当时我们参考了几个来源一是内部的人因实验数据测试驾驶员在模拟器里脱手后注意力衰减的曲线二是行业里同类功能的公开标定值三是法规对驾驶员监控的基本要求。综合下来我们把初始窗口期定在15秒左右然后根据驾驶员监控系统的置信度动态调整。动态调整的逻辑是这样的如果驾驶员监控摄像头显示驾驶员视线仍在道路前方、头部姿态正常窗口期可以适当延长如果视线偏离超过阈值窗口期立即缩短并提前触发接管提示。这个动态策略比固定窗口期复杂得多但安全收益明显。实现上它需要驾驶员监控系统和HWA控制器之间有低延迟的状态同步这个同步链路的失效模式也要纳入功能安全分析。注意窗口期参数一旦定下来不要轻易在项目后期改动。它牵涉到HARA的可控性假设、安全目标的验证用例、以及大量标定工作。后期改动等于把前面的安全分析推倒重来。3.3 驾驶员接管意图的识别与确认脱手窗口期结束前系统要确认驾驶员是否有效接管。这里的“有效”两个字很关键。驾驶员手搭上方向盘不等于接管可能只是无意识地搭着注意力还在手机上。我们把接管确认分成三个层次物理接触确认手是否在方向盘上、操作意图确认是否有转向或制动的主动输入、注意力确认视线和头部姿态是否回到驾驶任务。三个层次都满足才判定为有效接管。如果只满足物理接触系统会继续发出接管提示并准备降级策略。这个多层次确认的逻辑在软件架构上体现为状态机的多条件跳转。状态机设计时要注意避免“抖动”驾驶员手短暂搭一下又松开系统不能反复在“已接管”和“脱手”之间跳。我们加了去抖时间和滞回阈值去抖时间取200毫秒左右滞回阈值根据方向盘扭矩和电容信号的噪声水平标定。4. 功能安全机制在HWA中的落地实现4.1 转向扭矩安全包络的设计与验证转向扭矩安全包络是HWA功能安全的核心机制。它的作用是不管上游算法输出什么扭矩请求最终到执行器的扭矩都不能超出当前工况下的安全边界。安全包络的设计分两步第一步是离线计算根据车速、道路曲率、路面附着系数等参数算出理论上不会导致车辆失稳的最大扭矩第二步是在线限制实时监控扭矩请求一旦超出包络就截断或限幅。离线计算用车辆动力学模型跑仿真在线限制用查表加插值实现保证实时性。验证安全包络时我们用了故障注入的方法人为让上游算法输出一个超大的扭矩请求看包络能不能在规定的响应时间内把它压回安全范围。响应时间是关键指标我们当时的要求是10毫秒以内因为超过这个时间车辆横向位移可能已经超出可接受范围。实测下来查表加插值的方案在典型工况下能做到5毫秒左右满足要求。这里有个经验安全包络的标定不能只在干燥路面做。湿滑路面、弯道、上下坡的组合工况下安全边界会明显收窄。我们当时在冬季试验场专门跑了低附着路面的标定发现同样车速和曲率下湿滑路面的安全扭矩只有干燥路面的六成左右。如果包络不随附着系数调整湿滑路面上就会过于激进。4.2 降级策略与最小风险状态的设计当驾驶员未能在窗口期内接管系统必须执行降级策略把车辆带到最小风险状态MRC。HWA的降级策略不是简单的“退出功能”因为退出瞬间驾驶员可能还没接管车辆会突然失去横向控制。我们的降级策略分三级第一级是增强提示通过声音、震动、仪表弹窗多通道提醒驾驶员第二级是减速并保持车道系统逐步降低车速同时继续维持车道居中给驾驶员争取更多接管时间第三级是减速至停车如果驾驶员始终不接管系统在确认周围安全的前提下把车减速停到应急车道或本车道内。每一级降级都有对应的功能安全需求。比如第二级里“保持车道”的转向控制其安全等级不能低于正常HWA功能因为这时候驾驶员更可能没在关注。第三级的停车策略要考虑后车追尾风险需要结合后向雷达判断这部分又牵涉到另一个功能的安全分析。提示降级策略的触发条件要避免和驾驶员监控的误报耦合。如果驾驶员监控误判脱手系统可能在不该降级的时候降级反而制造风险。所以驾驶员监控本身的失效模式也要做FMEA关键误报路径要有冗余确认。4.3 软件组件鉴定报告在HWA项目中的实际应用软件组件鉴定报告这个词最近很热但很多人不清楚它在HWA项目里具体怎么用。我拿我们项目里的一个实例来说明。我们复用了上一代车型的车道居中控制模块这个模块当年是按ASIL B开发的现在HWA需要它达到ASIL D。直接复用不行重新开发周期又太长。这时候软件组件鉴定就派上用场了我们按照ISO 26262-8第12章的要求对这个模块做了一套鉴定活动包括详细设计审查、代码静态分析、单元测试覆盖率补测、以及针对ASIL D的额外验证。鉴定报告的核心是证明这个组件在目标应用场景下的适用性。报告里要写清楚组件的原始开发背景、鉴定活动的范围和深度、鉴定结果与ASIL D要求的差距、以及为弥补差距采取的额外措施。我们当时补了大约30%的单元测试用例重点覆盖转向扭矩计算的边界条件和故障路径最终鉴定报告通过了内部功能安全评审。实操心得软件组件鉴定不是“免死金牌”它只是证明组件够格的一种手段。鉴定报告写得好不好关键看鉴定活动的证据链是否完整。我见过有的报告只列了测试通过率没有说明测试用例怎么选的、覆盖了哪些安全需求这种报告在评审时会被直接打回。5. 实操过程从需求到验证的完整链路5.1 需求阶段的危害分析与安全目标定义需求阶段最花时间的是HARA。我们当时的流程是先由系统工程师列出HWA的所有功能失效模式然后安全工程师和HMI工程师一起对每个失效模式在“手扶”和“脱手”两种状态下分别评估S/E/C。评估可控性时我们做了一个驾驶员反应时间模型输入是脱手时长、驾驶员监控置信度、提示方式输出是驾驶员有效接管所需时间的分布。这个模型不是拍脑袋而是基于内部驾驶模拟器实验数据拟合的。模型输出用于支撑C值的评定让评估结果有数据背书。安全目标定义时要注意颗粒度。太粗没法分解太细又容易陷入实现细节。我们的经验是安全目标描述“避免什么”和“在什么条件下”不描述“怎么实现”。比如“在脱手窗口期内避免输出导致车辆偏离的转向扭矩”就是一个合适的安全目标它没有规定用包络还是用其他机制给后续设计留了空间。5.2 系统架构设计中的安全机制部署系统架构阶段要把安全目标翻译成具体的安全机制并分配到各个ECU和传感器上。HWA的安全机制主要分布在三个节点前视摄像头负责车道线和目标检测驾驶员监控摄像头负责脱手和注意力判断域控制器负责融合、决策和扭矩计算。安全机制部署时有个原则关键判断要有交叉验证。比如“驾驶员是否脱手”这个判断不能只依赖驾驶员监控摄像头还要结合方向盘扭矩信号。两个信号在域控制器里做一致性检查不一致时按保守策略处理。这个交叉验证的逻辑要写进系统安全需求并在架构图上明确标注。通信链路的安全也不能忽视。HWA的扭矩请求从域控制器发到转向执行器走的是CAN或以太网。这条链路上要有E2E保护包括CRC校验、计数器、超时监控。E2E保护的参数如CRC多项式、计数器位宽要根据链路的数据率和安全等级来选选完要做故障注入测试验证。5.3 软件实现中的安全机制编码要点软件实现阶段安全机制的编码有几个容易踩的坑。第一个是浮点运算的确定性问题。安全包络计算里如果用了浮点不同编译器优化等级下结果可能有微小差异这个差异在边界工况下可能被放大。我们的做法是关键的安全判断用定点运算浮点只用在非安全相关的舒适性计算里。第二个是看门狗和程序流监控的配置。HWA控制器的程序流监控要覆盖安全相关的任务监控超时时间要小于故障容忍时间间隔FTTI。FTTI是从故障发生到可能造成危害的最长时间这个时间在HARA里已经算过。程序流监控的超时时间一般取FTTI的三分之一到二分之一留出故障检测和反应的时间。第三个是内存保护。安全相关的变量和代码段要有MPU保护防止非安全任务越界写。我们在项目里把转向扭矩计算相关的变量单独放在一个受保护的RAM区非安全任务没有写权限。这个配置在AUTOSAR的OS模块里做配置完要用故障注入验证保护是否生效。5.4 验证阶段的故障注入与覆盖率评估验证阶段是检验功能安全设计是否真正落地的环节。故障注入测试是重头戏我们当时设计了三大类注入传感器信号注入如篡改扭矩信号、模拟摄像头丢帧、通信故障注入如丢包、延迟、CRC错误、执行器故障注入如模拟转向电机响应异常。每类注入都要有明确的通过判据。比如传感器信号注入的判据是系统应在FTTI内检测到故障进入降级状态且降级过程不产生新的危害。判据要提前定义好不能测完再补否则容易变成“结果导向”的测试失去验证意义。覆盖率评估分两部分需求覆盖率和代码覆盖率。需求覆盖率看每个安全需求是否有对应的测试用例代码覆盖率看安全相关代码的语句、分支、MC/DC覆盖情况。ASIL D对MC/DC覆盖率有明确要求我们当时在转向扭矩计算模块上补了不少用例才达标。覆盖率报告要和安全需求追溯矩阵一起提交形成完整的证据链。6. 常见问题与排查技巧实录6.1 脱手检测误报与漏报的排查思路脱手检测的误报把有手判成脱手和漏报把脱手判成有手是HWA项目里最常见的两类问题。误报会导致频繁提示接管用户体验差漏报则直接威胁安全。排查误报时先看扭矩信号的噪声水平。如果方向盘扭矩传感器噪声大微小的手扶扭矩会被淹没系统就容易误判脱手。我们的做法是加自适应滤波滤波参数根据车速和路面激励动态调整。高速平整路面上滤波可以强一些粗糙路面上要弱一些避免把真实的手扶信号滤掉。排查漏报时重点看电容感应的灵敏度。方向盘套、手套、甚至驾驶员手部干燥都会影响电容信号。我们当时在标定现场准备了不同材质的方向盘套和手套逐一测试电容信号的变化范围然后调整检测阈值。阈值不能一刀切要分档根据电容信号的基线漂移动态调整。注意脱手检测的标定数据要覆盖不同季节和气候条件。冬季干燥、夏季潮湿电容信号的基线差异明显。我们吃过一次亏夏天标定的参数到冬天就出现漏报后来加了温度补偿才解决。6.2 安全包络触发后的车辆行为异常排查安全包络触发后车辆行为异常通常表现为两种一种是扭矩截断太猛车辆出现明显的横向顿挫另一种是包络触发后系统没有及时降级车辆继续以不安全的状态行驶。第一种问题的根源往往是包络的限幅策略太激进。直接截断扭矩请求会导致横向加速度突变乘客会感到不适。我们的改进是加一个渐变限幅在几十毫秒内把扭矩平滑地压到安全边界而不是瞬间截断。渐变的时间常数要标定太短了顿挫太长了安全响应不及时。第二种问题通常是降级状态机的跳转条件有漏洞。比如包络触发后系统应该进入降级状态但如果降级状态机的入口条件写得不严谨可能被其他状态覆盖。排查时要把状态机的所有跳转路径画出来逐一检查入口和出口条件重点看有没有“优先级反转”的情况。6.3 软件组件鉴定报告被质疑时的应对软件组件鉴定报告在评审时被质疑通常集中在两个点鉴定活动的充分性和鉴定结论的可靠性。鉴定活动充分性被质疑时要回到ISO 26262-8第12章的要求逐条对照。报告里要明确列出组件的原始开发过程、鉴定活动的范围做了哪些分析、哪些测试、鉴定活动的深度测试覆盖率、分析详细程度、以及鉴定结果与目标ASIL的差距分析。如果某一条要求没做到要说明理由和补偿措施。鉴定结论可靠性被质疑时重点展示证据链。比如你说组件满足ASIL D的单元测试覆盖率要求就要附上覆盖率报告和测试用例清单说明用例是怎么从安全需求推导出来的。评审专家如果对某个用例有疑问要能当场追溯到对应的安全需求和代码实现。我个人的经验是鉴定报告不要写成“证明组件没问题”的辩护词而要写成“展示鉴定过程和结果”的技术文档。把局限性也写清楚反而更容易获得评审信任。6.4 常见问题速查表问题现象可能原因排查方向解决措施脱手误报频繁扭矩噪声大、电容阈值低查扭矩信号频谱、电容基线自适应滤波、动态阈值脱手漏报电容灵敏度不足、温度漂移查电容信号幅值、温度补偿分档阈值、温度补偿包络触发顿挫限幅策略太激进查扭矩截断速率渐变限幅、标定时间常数降级不及时状态机跳转条件漏洞查状态机所有跳转路径修正入口条件、加优先级鉴定报告被质疑证据链不完整对照ISO 26262-8第12章补鉴定活动、完善追溯E2E保护失效CRC或计数器配置错误查E2E配置参数按链路数据率重配程序流监控误触发超时时间太短查任务执行时间分布调整超时、优化任务调度7. 几个我踩过的坑和最后的建议第一个坑是低估了HARA评审的沟通成本。功能安全、HMI、系统、软件四个团队对“可控性”的理解天然有差异如果不提前对齐术语和假设评审会变成各说各话。后来我们养成了一个习惯HARA评审前先开一个预沟通会把评估模板和假设条件发给大家会上只讨论分歧点效率高了很多。第二个坑是安全包络的标定数据复用。我们一开始想直接用上一代车型的标定数据结果发现新一代车型的转向传动比和悬架特性变了同样的扭矩对应的横向加速度不一样包络必须重新标。这件事的教训是安全相关的标定数据没有“通用”一说车型一变就得重来。第三个坑是软件组件鉴定报告的时机。我们一开始把鉴定报告放在项目后期做结果发现鉴定活动需要补的测试用例太多后期时间不够差点影响交付。后来调整了策略在架构设计阶段就识别出需要鉴定的组件提前启动鉴定活动把测试用例的补充和正常开发并行做时间就宽裕多了。如果让我给正在做HWA功能安全的同行一句建议那就是把脱手窗口期当成一个动态的安全边界来设计而不是一个固定的计时器。驾驶员的状态在变道路环境在变系统的置信度也在变安全策略只有跟着变才能真正兜住底。至于软件组件鉴定报告早点启动、写清楚证据链、别怕暴露局限它就不是负担而是帮你把老代码用出新价值的工具。