3. HUD功能需求分析（SysReq）

好，咱们进入第三讲。这一讲，我打算聊聊HUD的功能需求分析。说白了，就是搞清楚HUD到底要显示什么，以及怎么把这些需求写得让开发、测试都能看懂。

我个人习惯，做需求分析前，先问自己三个问题：

• 用户是谁？——驾驶员
• 他要看什么？——关键信息
• 信息怎么来？——从车上各个ECU

嗯，想清楚这三点，后面的工作就顺了。

3.1 基于ISO 26262和ASPICE的需求工程方法

先说说方法论。ISO 26262和ASPICE，这两个标准在汽车电子圈里是绕不开的。

ISO 26262 管的是功能安全。它告诉你，HUD显示的信息如果错了，会有什么后果。比如车速显示错了10km/h，可能只是超速罚单；但ADAS告警没显示，那可能就是追尾事故。所以，安全等级（ASIL）得定清楚。

ASPICE 管的是过程质量。它要求你的需求是可追溯的、可验证的。说白了，就是每个需求都要有来源，也要能测。

我在项目中遇到过，有些团队把需求写得像散文，什么“系统应具有良好的用户体验”。这种需求，测试根本没法写用例。所以，我建议用结构化需求的方法：

• 功能需求：系统必须做什么（如：显示当前车速）
• 非功能需求：系统做得怎么样（如：刷新率≥30fps）
• 约束条件：系统必须在什么条件下做（如：工作温度-40℃~85℃）

3.2 HUD功能清单

好了，理论讲完，咱们看看HUD到底要显示什么。我列一个典型的功能清单，你想想看，这些信息是不是你开车时最想看到的？

功能模块	显示内容	数据来源	典型场景
车速显示	当前车速、限速标识	ESP/VCU	日常行驶
导航信息	转向箭头、距离、路名	IVI/手机	导航中
ADAS告警	FCW、LDW、AEB预警	ADAS域控	碰撞风险、车道偏离
来电显示	来电号码、联系人	蓝牙模块	来电时
多媒体信息	歌曲名、播放状态	IVI	听音乐时
车辆状态	电量/油量、故障灯	VCU/BMS	低电量、故障时

这里要注意，不是所有信息都要同时显示。我曾经见过一个项目，HUD上堆了十几个图标，驾驶员根本看不过来。所以，我建议做优先级分层：

• 一级（强制显示）：车速、ADAS告警
• 二级（按需显示）：导航、来电
• 三级（可选显示）：多媒体、车辆状态

3.3 需求属性定义

好，功能清单有了，接下来就是给每个需求贴上“标签”。这些标签就是需求属性。我常用的属性有这几个：

3.3.1 需求ID

每个需求都要有唯一ID。我习惯用这种格式：

HUD_SYS_REQ_001
HUD_SYS_REQ_002
...

这样，在测试用例、设计文档里引用起来特别方便。你想想看，如果没有ID，沟通时你说“那个车速显示的需求”，对方可能理解成另一个需求。

3.3.2 优先级

优先级决定了开发顺序。我一般分三级：

• P1（必须实现）：车速、ADAS告警。没有这些，HUD就是废的。
• P2（应该实现）：导航、来电。这些是提升体验的。
• P3（可以延迟）：多媒体、车辆状态。锦上添花。

3.3.3 安全等级（ASIL）

这是ISO 26262的核心。HUD显示的信息，安全等级怎么定？我举个例子：

功能	失效模式	危害	ASIL等级
车速显示	显示值比实际高20km/h	驾驶员可能超速	ASIL A
ADAS告警	FCW告警未显示	追尾风险	ASIL B
导航信息	转向箭头错误	走错路	QM
来电显示	不显示	错过电话	QM

嗯，这里要注意，ASIL等级不是拍脑袋定的。它需要做危害分析和风险评估（HARA）。我建议在需求阶段就引入功能安全工程师，一起把ASIL定下来。否则，后期改需求，代价很大。

3.4 需求示例

最后，我写一个完整的需求示例，你看看结构：

需求ID: HUD_SYS_REQ_001
标题: 显示当前车速
描述: 系统应从CAN总线上获取当前车速信号，并在HUD主显示区域以数字形式显示。
显示格式: 白色字体，字号不小于20pt，单位“km/h”显示在数字右侧。
刷新率: ≥30fps
精度: ±1km/h
优先级: P1
安全等级: ASIL A
数据来源: ESP模块，CAN ID 0x123，信号位0-7
验证方法: 通过CAN模拟器发送车速信号，目视检查HUD显示是否一致。

你看，这样的需求，开发拿到手就知道怎么做，测试也知道怎么测。说白了，需求写得越清楚，后面返工就越少。

好，这一讲就到这里。下一讲，咱们聊聊HUD的系统架构设计，看看这些功能怎么在硬件和软件上落地。