3. 车载应用架构需求分析
车载应用架构的需求分析，起点不在应用本身，而在整车功能定义。整车厂在车型立项阶段会输出一份整车功能清单（Vehicle Feature List），其中每一项功能都对应一个用户可感知的能力，例如“遥控泊车”“座椅记忆联动后视镜”“低电量导航引导充电”。架构工程师的任务，是把这些以整车为粒度的功能，逐层拆解为可分配到具体应用、可被验证的软件需求。这个过程不是简单的文字转写，而是一次跨层级的语义翻译。
从整车功能到应用需求的拆解路径
以“遥控泊车”为例。整车功能描述通常是“用户可在车外通过手机控制车辆完成泊入/泊出”。要落到应用需求，需要先识别它涉及哪些域：感知（超声波雷达、环视摄像头）、决策（泊车路径规划）、控制（转向、驱动、制动）、人机交互（手机 App、车机提示）、安全（远程控制权限校验）。每个域再进一步落到具体 ECU 或应用进程。此时应用需求才逐渐清晰，例如：手机 App 需在 300ms 内建立与车端的加密通道；车机需在泊车过程中持续显示车辆周围障碍物距离；泊车控制器需在检测到障碍物距离小于 0.3m 时立即中止并回退。
这里的关键方法是“功能—场景—需求”三层映射。功能回答“能做什么”，场景回答“在什么条件下做”，需求回答“系统必须满足什么约束”。三者缺一不可，否则需求会失去上下文，导致后续架构设计无法判断优先级和边界。
驾驶场景拆解：把功能放回真实时空
驾驶场景拆解是需求分析中最容易被低估的环节。同一个功能在不同场景下，对应用的要求可能完全不同。以“导航”为例，在高速巡航场景下，用户关注的是车道级引导和前方服务区信息；在拥堵跟车场景下，用户更关注实时路况和预计到达时间；在停车场场景下，导航需要与泊车功能联动，切换到“最后一公里”步行导航。如果需求分析只写“提供导航功能”，架构上就无法决定地图数据更新频率、算力分配和网络策略。
场景拆解通常从五个维度展开：道路类型（高速/城市/乡村/停车场）、交通密度（畅通/拥堵/事故）、环境条件（白天/夜间/雨雪/隧道）、车辆状态（行驶/泊车/充电/远程控制）、用户状态（驾驶员/乘客/车外用户）。每个维度组合出一个场景切片，再针对切片提取应用需求。例如“夜间+隧道+拥堵”这个切片，会同时触发对 HUD 亮度自适应、摄像头低照度增强、导航重新规划路径的需求。
用户角色与权限：需求分析中的隐性约束
车载应用与手机应用最大的区别之一，是用户角色不是单一的“机主”。同一辆车可能被多个驾驶员使用，乘客可以操作后排娱乐，车外用户可以通过手机远程控制部分功能。需求分析必须明确每个角色的权限边界，否则架构上会出现“功能存在但无法安全开放”的尴尬。
权限模型通常分三层：功能可见性（该角色能否看到入口）、操作许可（该角色能否执行该操作）、数据访问范围（该角色能读取哪些数据）。例如，代客泊车模式下，代客人员可以看到车辆状态和泊车进度，但不能访问车主通讯录和导航历史；后排乘客可以控制空调和娱乐，但不能修改驾驶模式。这些约束会直接影响应用架构中的权限服务设计、数据隔离策略和进程间通信的鉴权机制。
非功能需求：容易被忽略但决定架构形态
非功能需求在车载场景中往往比功能需求更苛刻。功能需求决定“做什么”，非功能需求决定“能不能在车上做”。常见的非功能维度包括：
- 时延：倒车影像从挡位切换到画面显示，行业普遍要求 ≤ 2s；关键控制信号端到端 ≤ 50ms。
- 可靠性：车机在 -40°C 至 85°C 环境下需稳定运行，冷启动次数寿命 ≥ 10 万次。
- 安全：涉及车辆控制的指令必须经过安全校验，远程控制需双向认证。
- 功耗：熄火后应用需在限定时间内进入低功耗状态，避免亏电。
- 资源：车机内存和存储通常远小于手机，应用需控制常驻内存和缓存策略。
这些指标不是架构设计阶段才考虑，而是在需求分析阶段就要写成可验证的条目。例如“倒车影像显示时延 ≤ 2s”需要明确测量起点（挡位信号发出）和终点（屏幕首帧显示），否则后续无法验收。
需求到架构的映射方法
需求分析完成后，需要一套可操作的映射方法将其转化为架构决策。实践中常用四步法：
- 功能分配：将每条需求分配到具体的应用、进程或 ECU。例如“遥控泊车手机端加密通道建立 ≤ 300ms”分配到手机 App 的通信模块和车端 T-Box 的安全服务。
- 接口定义：明确需求涉及的数据流方向、信号类型和接口协议。例如泊车进度通过 CAN 信号还是 SOME/IP 服务传递，频率是多少。
- 约束校验：检查分配方案是否满足非功能约束。例如将图像处理放在座舱域控制器上，是否满足 2s 冷启动和功耗要求。
- 追溯矩阵：建立需求 ID 与架构组件的双向映射表，确保每条需求都有归属，每个组件都有需求来源。
一个可参考的需求条目模板
为了让需求可验证、可追溯，建议每条应用需求至少包含以下字段：需求 ID、需求描述、来源整车功能、触发场景、涉及角色、功能/非功能分类、验收指标、优先级、关联架构组件。例如：
需求ID: REQ-APP-0037
描述: 手机 App 发起遥控泊车时，车端应在 300ms 内完成加密通道建立并返回就绪状态
来源功能: 遥控泊车
触发场景: 车外用户 + 停车场 + 车辆静止
涉及角色: 车外用户（车主）
分类: 非功能-时延
验收指标: 从 App 发送请求到收到车端就绪响应 ≤ 300ms（P95）
优先级: 高
关联组件: 手机App通信模块 / T-Box安全服务 / 座舱域控制器这样的条目在架构设计阶段可以直接驱动接口定义和部署决策，在测试阶段可以直接转化为测试用例。需求分析的价值，正在于把整车功能的模糊描述，变成这样一条条可分配、可校验、可追溯的工程语言。