2. 汽车电子系统需求工程
在汽车电子MBSE（基于模型的系统工程）实践中，需求工程是贯穿整个V模型的生命线。它决定了后续架构设计、软件实现、测试验证的输入质量。本节围绕需求来源与分类、功能需求与非功能需求、需求属性与追溯、需求管理工具，以及以ADAS域控制器为例的需求条目编写，展开可落地的讲解。
一、需求从哪里来：来源与分类
汽车电子需求并非凭空产生，它来自多个上游输入。常见来源包括：整车级功能定义（如“车辆应具备自动紧急制动能力”）、法规与标准（如UN-R152 AEB法规、ISO 26262功能安全、ISO 21448预期功能安全）、客户与市场诉求（如用户对泊车辅助的体验期望）、平台与复用策略（如沿用已有域控制器硬件平台）、以及内部工程约束（如功耗、成本、开发周期）。
按抽象层级，需求可分为整车级需求、系统级需求、子系统/组件级需求。按性质，则分为功能需求与非功能需求。按来源归属，又可分为法规需求、客户需求、内部需求。分类的目的不是贴标签，而是让每条需求找到正确的责任边界和验证层级。
二、功能需求与非功能需求
功能需求描述系统“做什么”，即输入到输出的行为映射。例如：“当车速大于30 km/h且前方目标TTC小于1.5 s时，AEB功能应在300 ms内发出制动请求。”它包含触发条件、输入信号、处理逻辑和输出动作。
非功能需求描述系统“做得怎么样”，包括性能、安全、可靠性、可维护性、功耗、成本等。例如：“AEB制动请求的端到端延迟不超过150 ms”“域控制器满足ASIL-D安全等级”“工作温度范围-40℃～+85℃”。非功能需求往往决定架构选型和验证方法，容易被忽视却影响巨大。
三、需求属性与追溯
一条合格的需求条目通常具备以下属性：唯一ID、需求描述、类型（功能/非功能）、优先级、来源、理由、验证方法（测试/分析/检查/演示）、状态、版本、负责人。这些属性使需求可管理、可追踪、可变更。
追溯是需求工程的核心机制。正向追溯从需求到设计、代码、测试用例；反向追溯从测试结果回到需求，确认覆盖完整。双向追溯矩阵能回答三个关键问题：每条需求是否被实现？每个设计元素是否源于需求？每个测试是否验证了需求？在功能安全项目中，追溯还是ISO 26262审核的必备证据。
四、需求管理工具
手工表格难以应对汽车电子动辄数千条需求及频繁变更。主流工具包括IBM DOORS / DOORS Next、Polarion、Jama Connect、Codebeamer等。它们提供需求条目化存储、属性管理、链接追溯、基线管理、变更影响分析和评审工作流。
在MBSE语境下，工具还需与SysML建模工具（如Rhapsody、MagicDraw/Cameo、Enterprise Architect）集成，实现需求与模型元素的链接。例如，在Cameo中将需求图与块定义图关联，当需求变更时自动标记受影响的架构元素。选择工具时重点考察：追溯能力、与建模工具集成度、变更管理、报表输出、以及是否支持ASPICE和ISO 26262的审核要求。
五、以ADAS域控制器为例的需求条目编写
下面以ADAS域控制器的AEB功能为例，展示需求条目的实际写法。假设整车级需求为“车辆应具备自动紧急制动功能，在碰撞风险时自动减速”。
| 需求ID | 需求描述 | 类型 | 验证方法 | 追溯来源 |
|---|---|---|---|---|
| REQ-AEB-001 | 当车速在30～80 km/h且前方目标TTC小于1.5 s时，域控制器应在300 ms内输出制动请求，减速度不低于4 m/s² | 功能 | 测试 | 整车级AEB需求 |
| REQ-AEB-002 | 从目标识别到制动请求输出的端到端延迟不超过150 ms | 非功能（性能） | 测试/分析 | REQ-AEB-001 |
| REQ-AEB-003 | AEB功能应满足ASIL-D安全等级，单点故障不得导致制动请求丢失 | 非功能（安全） | 分析/测试 | ISO 26262 |
| REQ-AEB-004 | 域控制器应通过CAN FD向制动执行器发送制动请求，报文周期10 ms | 功能（接口） | 测试 | 架构设计 |
| REQ-AEB-005 | 域控制器工作温度范围-40℃～+85℃，防护等级IP5X | 非功能（环境） | 检查/测试 | 平台规范 |
编写时注意几点：第一，每条需求只表达一个意图，避免“且/或”堆叠导致验证困难；第二，量化指标必须可测，如“300 ms”“4 m/s²”“10 ms”；第三，明确验证方法，测试、分析、检查、演示四选一；第四，建立追溯链接，REQ-AEB-002和REQ-AEB-003都追溯到REQ-AEB-001，形成父子关系；第五，接口需求要写清信号、报文、周期和物理层。
在MBSE流程中，这些需求条目会进一步与SysML需求图、用例图、活动图关联，形成从需求到模型再到测试的完整闭环。需求工程的质量，直接决定ADAS域控制器能否在安全、性能与成本之间取得平衡，也决定后续V模型右半边的验证是否有的放矢。