2、汽车软件系统基础：电子电气架构（EEA）、ECU、传感器、执行器、车载网络（CAN/LIN/FlexRay/Ethernet）等核心概念
汽车软件需求分析的首要前提，是理解软件所运行的物理与逻辑载体。现代汽车已从分布式电子控制单元（ECU）各自为政的“孤岛模式”，演进为以域控制器和中央计算平台为核心的“集中式电子电气架构（EEA）”。软件需求分析师若不能清晰区分信号流向、控制层级与网络拓扑，便无法准确界定功能边界、时序约束与故障处理策略。本章将系统梳理EEA的演进脉络、ECU的软硬件边界、传感器与执行器的信号特征，以及CAN/LIN/FlexRay/Ethernet四大车载网络的选型逻辑，为后续需求建模与架构设计奠定基础。
2.1 电子电气架构（EEA）的演进与需求影响
核心原理：电子电气架构定义了整车所有电子器件、网络拓扑、电源分配、信号路由与软件部署方式的总体框架。传统分布式EEA中，每个功能由独立ECU实现，如一个车身控制器只负责车窗升降，另一个只负责门锁。这种架构的软件需求边界清晰，但线束重量大、算力无法共享、OTA升级困难。现代集中式EEA将功能按域（动力、底盘、座舱、智驾、车身）聚合到域控制器，甚至进一步跨域融合为中央计算平台+区域控制器（Zone Controller）的架构。需求分析师必须理解：EEA决定了软件部署位置、通信延迟预算、故障隔离策略和升级范围。
| 架构代际 | 拓扑特征 | 软件部署 | 典型带宽 | 需求分析关注点 |
|---|---|---|---|---|
| 分布式（2000s） | 30-80个ECU，点对点连接 | 每个ECU独立固件 | CAN 500kbps | 功能边界清晰，但跨ECU时序难保证 |
| 域集中式（2015s） | 5-8个域控制器 | 域内软件集中，SOA起步 | CAN FD + 以太网 | 域间通信延迟、服务接口定义 |
| 中央+区域（2020s） | 1-2个中央计算单元 + Zone | 虚拟化、容器化部署 | 以太网为主 | 算力分配、确定性调度、功能安全 |
判断方法：在需求分析初期，首先确认目标EEA版本。查看架构文档中的网络拓扑图，识别功能涉及的ECU或域控位置，标注信号路径上的每个中间节点。若功能跨越多个域控（如自动紧急制动AEB需要摄像头感知、决策规划、制动执行三个域协同），则需求中必须包含跨域通信的时序约束和降级策略。
2.2 ECU：软件运行的物理载体
核心原理：ECU（Electronic Control Unit）是嵌入式计算单元，包含MCU（微控制器）、电源管理、通信收发器、输入/输出接口和存储器。从软件视角看，ECU提供：①计算资源（CPU主频、RAM、Flash）；②通信接口（CAN、LIN、以太网等）；③I/O能力（ADC采样、PWM输出、数字IO）。需求分析师需要明确目标ECU的资源余量，因为软件功能复杂度必须与硬件能力匹配。例如，一个基于Infineon AURIX TC397的域控，拥有6核300MHz TriCore，若需求要求同时运行感知算法、融合算法和决策规划，则必须评估CPU负载率是否超过70%的安全阈值。
操作流程：在需求分析阶段，对每个涉及ECU的功能执行以下检查：
- 确认ECU型号与硬件版本，获取数据手册中的资源参数。
- 估算功能所需的CPU负载、RAM占用、Flash存储和通信带宽。
- 检查ECU的通信接口是否满足需求（如是否需要额外CAN通道）。
- 确认ECU的AUTOSAR版本和软件组件（SWC）部署方式。
- 评估功能安全等级（ASIL）对ECU硬件隔离的要求。
2.3 传感器与执行器：信号特征与接口类型
核心原理：传感器将物理量（距离、温度、图像、加速度）转换为电信号，执行器将电信号转换为机械动作。软件需求必须描述传感器数据的精度、分辨率、采样率、噪声特性和故障模式。例如，超声波传感器的探测范围为20-450cm，分辨率1cm，但受温度影响较大；毫米波雷达在雨雾天气性能稳定，但近距离盲区较大。执行器需求则需关注响应时间、控制精度、占空比范围和失效安全位置。
| 传感器/执行器类型 | 典型接口 | 数据特征 | 需求分析要点 |
|---|---|---|---|
| 摄像头（CMOS） | GMSL2 / LVDS | 1280x720@30fps，YUV422 | 帧率、曝光时间、HDR范围、坏点策略 |
| 毫米波雷达 | CAN FD | 目标列表，每帧最多64个目标 | 目标ID稳定性、速度分辨率、角度精度 |
| 超声波传感器 | LIN / 数字IO | 距离值，10Hz更新 | 盲区、串扰抑制、温度补偿 |
| 制动执行器（ESC） | CAN FD | 主缸压力请求，0-200bar | 压力闭环控制周期、失效安全（保持/释放） |
| 转向执行器（EPS） | CAN FD | 扭矩请求，±8Nm | 扭矩梯度限制、方向盘反冲、故障降级 |
常见误区：需求分析师常忽略传感器的数据质量属性。例如，仅写“摄像头检测到行人”，未定义“检测置信度≥0.9”或“在逆光场景下的检出率”。这会导致开发团队无法验证算法性能。正确做法是在需求中明确传感器的操作条件（光照范围、温度范围、车速范围）和性能边界（检出率、误报率、响应延迟）。
2.4 车载网络：CAN/LIN/FlexRay/Ethernet的选型逻辑
核心原理：车载网络是软件组件间通信的“神经系统”。不同网络在带宽、实时性、确定性、成本和物理层特性上差异显著。CAN（Controller Area Network）是应用最广的车辆总线，采用CSMA/CA仲裁机制，标准CAN带宽500kbps，CAN FD最高5Mbps，支持优先级仲裁，适合传输控制指令和状态信息。LIN（Local Interconnect Network）是低成本单主多从总线，带宽20kbps，用于车窗、后视镜等低速车身功能。FlexRay提供时间触发和事件触发混合调度，带宽10Mbps，具备确定性时隙，适合线控转向等安全关键应用，但成本较高。车载以太网（100BASE-T1/1000BASE-T1）提供高带宽，支持SOA通信和OTA升级，但实时性需通过AVB/TSN机制保障。
判断方法：选择网络类型时，按以下维度评估：
- 带宽需求：若单帧数据超过8字节或周期消息超过100条/s，优先考虑CAN FD或以太网。
- 实时性要求：端到端延迟<10ms且需要确定性，考虑FlexRay或以太网+TSN。
- 成本敏感：车身舒适功能（车窗、门锁）用LIN即可，无需CAN。
- 诊断与OTA：需要大文件传输时，以太网是唯一选择。
- 物理层约束：双绞线非屏蔽（CAN/LIN）vs 屏蔽双绞线（FlexRay/以太网）的线束成本差异。
2.5 案例闭环：AEB自动紧急制动系统的网络与信号需求分析
背景与约束：某车型开发AEB功能，目标满足Euro NCAP 2023五星评级。系统涉及前视摄像头（安装于挡风玻璃）、毫米波雷达（前保险杠）、智驾域控（ADCU）、底盘域控（含ESC制动执行器）和仪表显示。约束条件：整车成本增加≤3000元，AEB激活车速范围10-80km/h，系统必须在-40°C至85°C环境温度下可靠工作。
初始现象与目标：初始需求仅描述“实现AEB功能，避免碰撞”。需求分析师介入后，发现以下关键问题：①摄像头与雷达的数据融合在ADCU中完成，但两者数据帧率不同（摄像头30fps，雷达20Hz），需要时间同步机制；②制动请求从ADCU到ESC的通信路径经过CAN FD网关，存在转发延迟；③若ESC故障，需要降级为仪表报警+驾驶员提醒，但原需求未定义降级条件。
关键输入数据：摄像头输出：1280x720@30fps，YUV422格式，单帧数据量约1.8MB，通过GMSL2传输至ADCU，传输延迟≤5ms。雷达输出：CAN FD报文，每帧包含最多64个目标，周期50ms。ADCU到ESC的CAN FD通信周期10ms，网关转发延迟实测3-8ms（受总线负载影响）。
分析判断过程：需求分析师通过时序分析发现，从摄像头采集到制动执行的总延迟预算为：摄像头曝光+读取（20ms）+ GMSL2传输（5ms）+ 视觉算法（30ms）+ 融合算法（10ms）+ 决策规划（10ms）+ CAN FD发送（2ms）+ 网关转发（8ms）+ ESC响应（10ms）= 95ms。而Euro NCAP要求AEB在相对速度50km/h时，碰撞前1.2s发出制动请求。95ms的延迟在可接受范围内，但若网关负载升高导致转发延迟超过15ms，则总延迟将突破100ms，可能影响极端场景下的性能。
实际操作步骤：①在需求中明确“摄像头与雷达时间同步误差≤5ms”，要求ADCU提供同步机制；②定义“CAN FD总线负载率≤50%”作为网关延迟的约束条件；③增加“ESC故障时，AEB功能降级为FCW报警，并在仪表显示故障灯”的降级需求；④在测试规范中增加“网关高负载场景下的AEB功能测试”用例。
结果对比：优化后的需求文档中，AEB功能的可测试性显著提升。测试团队能够根据明确的时序指标设计验证方案，最终在实车测试中，AEB在80km/h跟车场景下成功避免碰撞，端到端延迟实测88ms，满足设计目标。
风险与代价：为满足时序要求，ADCU选用了更高性能的处理器（成本增加约500元），同时增加了CAN FD网关的优先级配置工作。但相比后期发现时序问题导致的召回风险，这些代价是值得的。
复盘经验：①需求分析必须从物理架构出发，不能只写功能逻辑；②跨域功能的时序预算必须逐段分解并验证；③降级策略是安全关键功能需求中不可缺失的部分；④网络负载率是影响通信延迟的隐性因素，应在需求中给出明确约束。