3. 显示安全基础
HUD（抬头显示）把车速、导航、报警、ADAS状态等关键信息投射到驾驶员前方视野，一旦显示错误、延迟、缺失或被篡改，驾驶员可能做出错误判断。因此HUD安全不能只谈“硬件可靠”，而要同时覆盖功能安全（Functional Safety, FuSa）、预期功能安全（SOTIF）和信息安全（Cybersecurity）三条主线。三者关注点不同，却在HUD系统中相互交织。
一、三条安全主线的基本概念
功能安全关注的是“系统故障导致的危害”。它假设系统存在随机硬件失效和系统性失效，通过危害分析、安全目标、ASIL等级、安全机制、诊断覆盖率等手段，把风险降到可接受水平。典型标准是ISO 26262。对HUD而言，功能安全要回答：如果PGU（图像生成单元）死机、背光失控、CAN信号丢失、电源跌落，显示会不会出现误导性画面？系统能否在故障时进入安全状态？
预期功能安全关注的是“没有故障，但性能不足或场景理解偏差导致的危害”。它假设系统按设计运行，却因传感器局限、算法边界、驾驶员误用、环境干扰而引发风险。典型标准是ISO 21448。对HUD而言，SOTIF要回答：强光下对比度不足、雨雾中虚像模糊、驾驶员把AR导航箭头误读为真实车道、报警图标优先级不清晰，这些都不是“坏了”，却可能造成危险。
信息安全关注的是“人为恶意攻击导致的危害”。它关注资产、威胁、漏洞、攻击面、身份认证、完整性、机密性、可用性。典型标准是ISO/SAE 21434。对HUD而言，信息安全要回答：攻击者能否通过IVI或OTA通道篡改显示内容？能否伪造车速或报警信号？能否让HUD在关键时刻黑屏或弹出误导信息？
一句话区分：功能安全防“坏”，预期功能安全防“弱”，信息安全防“恶”。HUD的安全设计必须同时回答这三类问题。
二、HUD中的安全映射关系
把三条主线映射到HUD的具体对象上，可以形成清晰的工程抓手。HUD的典型信号链包括：车辆信号输入（车速、挡位、ADAS目标）、SOC/GPU渲染、PGU成像、光学投影、驾驶员视觉感知。每个环节都可能成为三类安全的落点。
三、方法流程：从危害到安全需求
HUD安全开发通常遵循“危害分析→安全目标→安全需求→安全机制→验证确认”的闭环。功能安全侧使用HARA（危害分析与风险评估）确定ASIL；SOTIF侧使用场景分析和已知/未知危害区域划分；信息安全侧使用TARA（威胁分析与风险评估）确定攻击路径和缓解措施。
- 识别资产与危害：列出HUD显示的关键信息，如车速、报警、ADAS状态，分析错误显示、丢失、延迟、篡改的后果。
- 确定安全目标：例如“HUD不得显示与真实车速偏差超过±2km/h的错误车速”“关键报警丢失时应在100ms内降级提示”。
- 分配安全需求：把目标分解到信号输入、渲染、PGU、光学、通信各层，形成可测试的需求条目。
- 设计安全机制：包括信号校验、看门狗、冗余渲染、亮度闭环、安全启动、消息认证、显示内容签名等。
- 验证与确认：通过故障注入、场景测试、渗透测试、实车路试验证安全目标达成。
四、案例与场景：三类风险在HUD中的典型表现
功能安全案例：某车型HUD在低温启动时PGU初始化失败，屏幕保持黑屏，但仪表仍正常。驾驶员误以为HUD已开启，未察觉车速信息缺失。改进措施是增加PGU心跳检测和启动自检，失败时通过仪表弹出“HUD不可用”提示，并记录DTC。
SOTIF案例：AR-HUD在隧道出口强光下，虚像对比度骤降，导航箭头几乎不可见。系统没有故障，但显示性能不满足场景需求。改进措施包括环境光传感器联动亮度、HUD亮度动态补偿、在极端光照下切换为高对比度简化模式。
信息安全案例：攻击者通过IVI的调试接口注入伪造车速报文，HUD显示“车速0km/h”，而实际车辆正在行驶。改进措施包括CAN报文认证、IVI与HUD之间的安全通道、显示内容完整性校验、调试接口访问控制。
常见误区：把SOTIF问题当成功能安全故障处理，或把信息安全攻击当成随机失效。三者根因不同，安全机制也不同。例如，强光下看不清不是“坏了”，加看门狗没用；而报文被篡改也不是“性能不足”，只做场景测试无法发现。
五、对比清单：三类安全在HUD中的关注点
| 维度 | 功能安全 FuSa | 预期功能安全 SOTIF | 信息安全 Cybersec |
|---|---|---|---|
| 触发条件 | 随机硬件失效、系统性失效 | 性能局限、场景边界、误用 | 恶意攻击、漏洞利用 |
| HUD典型对象 | PGU、电源、CAN、看门狗 | 光学、亮度、人因、AR算法 | IVI、OTA、调试口、通信总线 |
| 核心标准 | ISO 26262 | ISO 21448 | ISO/SAE 21434 |
| 典型措施 | 冗余、诊断、安全状态 | 场景覆盖、边界限制、提示 | 认证、加密、访问控制、监控 |
| 验证手段 | 故障注入、FMEDA | 场景测试、实车路试 | 渗透测试、漏洞扫描 |
六、工程落地建议
在HUD项目中，建议建立统一的安全需求库，把FuSa、SOTIF、Cybersec需求分别打标签，避免遗漏。安全机制设计要遵循“独立、可验证、可降级”原则：独立意味着不依赖同一失效源；可验证意味着能被测试和诊断覆盖；可降级意味着故障时仍能保留最低限度的安全信息显示。
HUD安全需求示例（伪代码）：
REQ-FUSA-001: 当PGU心跳丢失超过50ms，HUD应在100ms内关闭投影并点亮故障指示灯。
REQ-SOTIF-002: 当环境光超过80000lux，HUD应自动提升亮度至最大并切换高对比度模式。
REQ-CYBER-003: HUD接收的显示内容必须经过MAC校验，校验失败时丢弃并记录安全事件。
REQ-FUSA-004: 车速信号应采用双通道冗余，偏差超过2km/h时进入降级显示。
REQ-SOTIF-005: AR导航箭头在车道线识别置信度低于0.7时，应切换为2D简化箭头。
总之，HUD显示安全不是单一标准能覆盖的问题。功能安全解决“故障不害人”，预期功能安全解决“能力不足不害人”，信息安全解决“被攻击不害人”。只有把三者映射到HUD的具体信号链、部件和场景中，才能形成可落地、可验证、可降级的安全设计。