2. AUTOSAR需求工程基础

AUTOSAR方法论（AUTOSAR Methodology）并不是一套孤立的建模规范，它首先是一套“从需求到可交付软件”的工程链路。在这条链路里，需求工程决定了后续所有配置、生成与集成工作的正确性。如果需求类型划分不清、层级归属混乱、属性缺失或生命周期状态失控，那么即使BSW配置再规范、RTE生成再顺利，最终交付物也无法证明“满足原始诉求”。本节围绕四个核心问题展开：需求有哪些类型、需求分几层、每条需求要带哪些属性、需求在项目中如何流转与冻结。

一、需求类型：功能、非功能与约束

在AUTOSAR项目中，需求通常按“性质”分为三类。第一类是功能需求，描述系统或软件必须实现的行为，例如“当车速大于20 km/h且驾驶员未系安全带时，仪表应在500 ms内点亮安全带警告灯”。这类需求最终会映射到SWC的Runnable、端口与数据元素上。第二类是非功能需求，描述行为之外的品质约束，例如时序、资源、安全与诊断能力，典型如“该Runnable的最坏执行时间不超过2 ms”“ECU上电到CAN报文可发送的时间不超过100 ms”。第三类是约束与合规需求，来自法规、平台或组织规范，例如“必须符合AUTOSAR 4.4.0”“必须支持UDS 0x22服务读取软件版本”。

三类需求在追溯链上的落点不同：功能需求主要追溯到SWC与RTE，非功能需求主要追溯到OS任务、BSW调度与内存配置，约束需求则更多体现在模板选择、生成器版本与交付清单中。混淆类型会导致验证方法错配，例如把时序需求当作功能需求，只做功能测试而不做时间测量，就无法闭环。

二、需求层级：从整车到代码的纵向分解

AUTOSAR方法论中的需求层级通常表现为一条自上而下的分解链：整车级需求 → 系统级需求 → ECU级需求 → 软件组件级需求 → 单元/配置级需求。每一层都应对上一层负责，并通过追溯关系（Traceability）保持双向可查。整车级需求回答“车要做什么”，系统级需求回答“哪些子系统协同完成”，ECU级需求回答“本控制器承担什么”，SWC级需求回答“哪个组件、哪个端口、哪个Runnable实现”，配置级需求则回答“用哪些参数、哪些生成选项落地”。

层级分解的关键不是“拆得细”，而是“拆得可验证”。一条ECU级需求如果无法落到具体的SWC端口或BSW模块参数上，就说明分解不完整；反过来，一个配置参数如果无法向上追溯到任何一条需求，就属于“无源配置”，在变更时极易被遗漏。

三、需求属性：让需求可管理、可验证

一条需求如果只有一句自然语言描述，在AUTOSAR项目中几乎无法管理。需求属性是需求对象的“元数据”，决定了它能否被检索、分配、验证和变更控制。常见的必备属性包括：

• 唯一标识（ID）：如 REQ_BCM_LIGHT_001，全项目唯一，禁止复用。
• 需求类型：功能、非功能、约束，决定验证方法。
• 层级归属：整车/系统/ECU/SWC/配置，决定分配对象。
• 来源与依据：来自哪份法规、哪条整车需求或哪个客户输入。
• 优先级：如Must/Should/Could，影响变更与裁剪决策。
• 验收准则：可测量的通过条件，如“响应时间≤500 ms”。
• 状态：草稿、评审中、已批准、已实现、已验证、已废弃。
• 版本与变更记录：每次修改的原因、影响范围与批准人。

其中“验收准则”最容易被写空。以“安全带警告灯应在500 ms内点亮”为例，验收准则必须明确测量点：从安全带扣开关信号变化到警告灯驱动输出变化，在ECU引脚处测量，使用示波器或总线记录仪，采样周期不大于10 ms。没有测量点和测量方法的验收准则，在验证阶段无法判定通过与否。

四、需求生命周期：从提出到废弃的状态流转

需求生命周期描述一条需求从产生到退出项目的状态变化。典型状态包括：草稿（Draft）→ 评审中（In Review）→ 已批准（Approved）→ 已分配（Allocated）→ 已实现（Implemented）→ 已验证（Verified）→ 已冻结（Frozen）→ 已废弃（Obsolete）。状态流转必须伴随准入条件，例如“草稿→评审中”要求属性完整，“已实现→已验证”要求提供测试报告与追溯链接，“已批准→已分配”要求至少关联一个SWC或BSW配置对象。

在AUTOSAR项目中，需求冻结与基线管理紧密相关。当一条需求进入“已冻结”状态后，任何修改都必须走变更请求（Change Request），并评估对SWC、RTE、BSW配置和生成代码的影响。如果需求状态与配置状态脱节，就会出现“需求已改、代码未动”或“代码已改、需求未记”的追溯断链。

五、需求与AUTOSAR交付物的映射示例

为了把上述概念落到实际交付，下面给出一个简化的映射示例。假设有一条ECU级需求：“BCM应在收到车门状态报文后100 ms内更新车门锁状态”。在AUTOSAR方法论中，它会被分解为：SWC级需求“DoorLock SWC的Runnable RE_DoorLock_Update周期为10 ms，读取DoorStatus端口并写入LockCmd端口”；配置级需求“RTE事件到Runnable的映射使用TimingEvent，周期10 ms”；验证需求“在HIL台架上注入车门状态变化，测量LockCmd输出变化时间≤100 ms”。

这张映射表的价值在于：它把“需求—配置—代码—测试”串成一条可检查的链。任何一环缺失，都会在追溯审查中暴露。对于AUTOSAR项目而言，需求工程不是文档工作，而是配置生成和代码交付的输入约束。只有需求类型清晰、层级完整、属性可验证、生命周期受控，后续的SWC集成、RTE生成和BSW配置才有可靠依据。