3. 车身与底盘控制器需求分析

在AURIX车身与底盘控制器开发中，需求分析不是把客户SOR（Statement of Requirements）翻译成中文，而是把整车层面的功能意图、法规约束、安全目标和量产交付要求，逐步分解为可设计、可实现、可验证、可追溯的工程条目。车身域控制器（BCM/BDC）与底盘域控制器（如ESC、EPS、悬架控制器）在需求结构上有明显差异：车身控制器强调多路IO、LIN/CAN通信、低功耗与诊断；底盘控制器强调高实时性、高功能安全等级和闭环控制精度。本节围绕功能需求、非功能需求、安全目标与交付物定义四个维度展开，并给出可执行的分解方法。

一、功能需求：从整车行为到控制器条目

功能需求描述“控制器必须做什么”。以车身控制器为例，典型功能包括：遥控解闭锁、迎宾灯、雨量感应雨刮、车窗防夹、座椅加热、后备箱控制、LIN执行器驱动、CAN网关路由、UDS诊断、网络管理（NM）等。每条功能需求应包含触发条件、输入信号、处理逻辑、输出动作、异常处理和验收判据。

以“车速自动闭锁”为例，需求条目可写为：当车速信号（来自ESC的CAN报文，信号名VehSpd，分辨率0.05625 km/h，周期20 ms）连续超过15 km/h且持续200 ms，且点火状态为ON、四门状态均为关闭时，BCM应在100 ms内驱动门锁执行器上锁，并通过CAN发送DoorLockSts=Locked。若任一车门在闭锁过程中被打开，应中止闭锁并记录DTC。这样的条目才具备可测试性。

底盘控制器功能需求则更强调闭环与实时性。例如EPS的助力需求：方向盘扭矩信号（TAS，周期1 ms）经助力曲线查表得到目标电流，电流环控制周期100 μs，助力电机响应延迟不超过5 ms。功能需求分解时，建议采用“场景—触发—响应—判据”四元组，避免“支持”“兼容”等不可验证的动词。

二、非功能需求：约束条件决定架构选型

非功能需求描述“在什么约束下实现功能”，往往直接决定AURIX型号、外设配置和软件架构。车身与底盘控制器常见的非功能需求包括：

• 实时性：CAN报文接收中断延迟、控制周期抖动、任务最坏执行时间（WCET）。例如底盘控制任务周期1 ms，抖动要求≤50 μs。
• 资源：Flash/RAM占用、CPU负载率（目标≤70%）、堆栈余量。
• 通信：CAN FD通道数、LIN主从节点数、以太网DoIP、SENT/PSI5传感器接口。
• 电气与环境：工作电压6~18 V、抛负载、EMC等级、工作温度-40~+125 ℃。
• 功耗：休眠电流≤100 μA，支持局部网络唤醒。
• 诊断与刷写：UDS服务集、Bootloader刷写时间、DTC存储与老化策略。
• 功能安全：ASIL等级、安全机制覆盖率、故障响应时间（FTTI）。

这些约束需要量化并写入需求基线。例如“CPU负载率≤70%”应明确测量工况（如全负载CAN流量+诊断并发），否则无法验证。

三、安全目标：从HARA到技术安全需求

安全目标来源于整车HARA（危害分析与风险评估）。以车窗防夹为例，危害为“车窗上升夹伤乘员”，严重度S2、暴露率E4、可控性C2，得出ASIL B。安全目标为：在防夹区域内检测到障碍物时，车窗应在规定时间内反转或停止，避免持续夹持力超过限值。

安全目标需进一步分解为功能安全需求（FSR）和技术安全需求（TSR）。例如FSR：防夹功能应在车窗上升过程中持续有效；TSR：采用双通道电流采样与霍尔位置信号交叉校验，当两路信号偏差超过阈值时进入安全状态（反转下降）。AURIX的锁步核、SMU、ECC、看门狗等安全机制需在TSR中明确配置与响应路径。

底盘控制器的安全目标通常更高。例如ESC的ASIL D安全目标要求：在单点故障下不得输出错误制动请求。对应TSR包括：扭矩/压力传感器冗余校验、执行器驱动使能互锁、安全状态为关闭阀驱动并点亮警告灯。

四、交付物定义：需求基线、追溯与验证证据

需求分析的输出不是一份文档，而是一组可追溯、可验证、可变更控制的交付物。典型交付物包括：

• 需求规格说明书（SRS）：功能需求、非功能需求、安全需求分章编号，每条含ID、描述、来源、ASIL、验证方法。
• 需求追溯矩阵（RTM）：从整车需求→系统需求→软件/硬件需求→测试用例的双向追溯。
• 接口定义（ICD）：CAN/LIN报文、信号、DLC、周期、超时、初值、SNA。
• 安全分析报告：HARA、FMEA、DFA、安全案例。
• 验证计划：单元测试、集成测试、HIL测试、实车标定用例。
• 配置与变更记录：需求基线版本、变更请求、影响分析。

以下SVG给出需求分析从整车输入到交付物的数据流与追溯关系，帮助理解各环节的输入输出和验证闭环。

五、需求分析的实际操作要点

在AURIX项目中，需求分析通常与AUTOSAR方法论并行。功能需求映射到SWC（软件组件）和Runnable；非功能需求映射到OS任务周期、BSW配置和MCU外设；安全需求映射到安全机制和监控。建议在需求阶段就建立需求ID命名规则，例如BCM-FUNC-001、BCM-NF-012、BCM-SAF-003，便于追溯。

对于底盘控制器，还需特别关注安全目标与FTTI的分解。例如FTTI为100 ms，则从故障检测到进入安全状态的总时间必须小于100 ms，需分配传感器诊断时间、CPU处理时间、执行器响应时间。若某环节超时，应通过安全机制降级或冗余路径满足。

最后，交付物定义应明确版本、责任人、评审状态和变更流程。需求基线一旦冻结，任何变更都需经过影响分析，评估对软件、硬件、测试和安全案例的影响。只有形成“需求—设计—实现—测试—安全”的闭环追溯，才能支撑后续AURIX控制器的开发与工程交付。