2. 区域控制器需求分析与功能定义

区域控制器（Zonal Controller，ZC）的需求不是从零“发明”出来的，而是从整车功能清单中“分解—聚类—裁剪—约束”出来的。本节的任务是把整车级功能需求，逐步收敛为一份可评审、可追溯、可分配给软硬件模块的区域控制器需求规格草案。整个过程围绕四条主线展开：功能清单分解、功能聚类、通信矩阵与信号清单梳理、功能安全与信息安全需求初判。

一、整车功能清单分解：从“整车能力”到“可分配功能项”

整车功能清单通常以用户可见能力或系统级能力描述，例如“无钥匙进入与启动”“电动尾门防夹”“座椅记忆”“外部灯光迎宾”“远程诊断”等。这类描述粒度太粗，无法直接映射到控制器。分解的目标是把它拆成可独立分配、可独立验证的功能项，每个功能项应至少包含：功能名称、触发条件、输入信号、输出执行、约束条件、失效表现。

以“无钥匙进入与启动（PEPS）”为例，可分解为：低频寻卡、钥匙认证、门把手触发检测、解锁执行、一键启动使能、防盗认证失败处理等。分解时建议采用“功能—子功能—信号级行为”三层结构，避免直接跳到信号级而丢失功能语义。分解完成后，每个功能项应标注其实时性等级（硬实时/软实时/非实时）、安全等级初判（QM/ASIL A~D）和通信需求（CAN/CAN FD/LIN/以太网/私有总线）。

二、区域控制器承载的功能聚类方法

功能聚类决定“哪些功能放到区域控制器、哪些留在中央计算或专用ECU”。聚类不是简单按位置分组，而应综合以下维度：

• 物理位置：传感器/执行器是否集中在同一区域（前舱、左后、右后、舱内）。
• 实时性：硬实时功能（如防夹、碰撞信号）应靠近执行器，避免跨域转发延迟。
• 安全等级：ASIL B及以上功能优先放在具备锁步核与安全监控的ZC中。
• 通信带宽：摄像头、雷达等大带宽数据不宜经ZC中转，应直连中央计算。
• 供电与驱动能力：大电流负载（座椅电机、尾门电机）需ZC具备相应驱动或预驱接口。
• 功能耦合度：频繁交互的功能应聚在同一ZC，减少跨控制器信号往返。

实践中常用“区域+功能域”二维聚类：先按物理区域划分ZC，再在每个ZC内按功能域（车身、灯光、门锁、座椅、热管理）组织软件模块。例如前舱ZC承载前灯、雨刮、前门锁、前座椅加热；左后ZC承载左后门、左后灯、左后座椅、充电口盖。聚类结果应形成一张功能—区域分配矩阵，作为后续通信矩阵和需求规格的输入。

三、通信矩阵与信号清单梳理

功能聚类完成后，需要把每个功能项的输入输出落到具体信号上，形成通信矩阵。通信矩阵的核心字段包括：信号名、所属报文/帧、发送节点、接收节点、周期、长度、字节序、初值、超时行为、安全属性（E2E/CRC/计数器）。

以“左前门把手触发→左后ZC→中央计算→解锁”为例，信号链可能为：门把手开关硬线输入到左后ZC，ZC通过CAN FD发送DoorHandle_Status，中央计算校验后下发Lock_Cmd，ZC驱动门锁电机。此时需明确：门把手信号周期（如10ms）、超时判定（如50ms无更新则置为无效）、E2E保护（若涉及防盗则需CRC+计数器）。

信号清单梳理时建议同步建立信号—功能追溯表，确保每个功能项至少有一个输入信号和一个输出信号，且无孤立信号。对于跨ZC信号，应标注路由路径和延迟预算，例如“左后ZC→中央计算→右后ZC”的端到端延迟应小于功能允许的最大值。

四、功能安全与信息安全需求初判

功能安全初判依据ISO 26262的HARA思路：对每个功能项识别危害事件，评估严重度（S）、暴露率（E）、可控性（C），得到ASIL等级。例如“电动尾门防夹”若失效可能导致夹伤，S2/E3/C2，初判ASIL B；“座椅记忆”失效通常不直接危及生命，可初判QM或ASIL A。初判结果决定ZC是否需要锁步核、安全监控、独立看门狗、安全输出关断路径等。

信息安全初判依据ISO/SAE 21434思路：识别资产（钥匙认证数据、诊断服务、OTA包、门锁控制指令）、威胁（重放、篡改、未授权访问）、攻击面（CAN、以太网、蓝牙、诊断口）。例如无钥匙进入的射频认证数据若被重放，可能导致车辆被盗，需引入挑战—响应机制和新鲜度计数器；诊断服务需支持安全访问（Seed/Key）和诊断事件日志。初判结果应形成安全需求清单，标注每条需求对应的功能项、安全等级和验证方法。

五、需求规格草案的交付形态

完成上述四步后，应形成一份结构化的需求规格草案。草案建议包含以下部分：

以左后ZC为例，草案中可写：功能项FUNC_RL_DOOR_LOCK，触发条件为“左后门把手触发且钥匙认证通过”，输入信号DoorHandle_RL（硬线，10ms去抖），输出信号LockMotor_RL_Cmd（PWM，500ms脉冲），安全等级ASIL A，安全机制为“输出回读+超时关断”，验证方法为“台架模拟把手触发+故障注入”。

最后需要强调：区域控制器的需求定义是一个迭代过程。随着整车功能清单更新、通信矩阵细化、安全分析深入，草案会持续演进。建议使用需求管理工具维护版本和追溯关系，确保每条需求都能追溯到整车功能，每个功能都能追溯到验证用例。这样，后续的S32平台集成、软件架构设计和测试验证才有稳定的输入基线。