2. 量产项目启动与交付基线
量产项目启动阶段的核心任务，不是立刻开始配置BSW，而是把“交付什么、依据什么、用什么版本、按什么节奏”这四件事固定下来。一旦基线未锁定就进入开发，后期任何一次工具升级、客户输入变更或BSW配置调整，都会引发连锁返工。因此本章的重点是建立一份可追溯、可评审、可冻结的交付基线。
一、启动阶段必须确认的四类基线
ETAS量产项目通常围绕四条基线展开，它们相互约束，缺一不可：
- 交付物基线：明确最终交付给客户或整车厂的软件包、文档、测试报告、标定文件、诊断数据库等清单，并标注每项的交付形式（源码/二进制/加密包）与验收标准。
- 客户输入基线：包括系统需求规格、通信矩阵（DBC/ARXML）、诊断规范（CDD/ODX）、网络管理需求、功能安全需求（如ASIL等级）、硬件接口定义等。每份输入需记录版本号、发布日期与责任人。
- 工具链基线：ETAS工具版本必须与客户项目要求匹配，常见组合如ISOLAR-AB、RTA-CAR、EB tresos、INCA等。工具版本不一致会导致ARXML导入失败或生成代码行为差异。
- BSW配置基线：基于AUTOSAR标准模块（EcuM、ComM、Dcm、Dem、NvM、CanIf、CanTp等）的配置参数集合，需明确哪些模块启用、哪些参数由客户指定、哪些由ETAS默认模板提供。
这四类基线在启动评审会上应形成一份项目基线清单，由项目经理、系统工程师、BSW配置工程师和测试负责人共同签字确认。基线一旦冻结，后续变更必须走变更控制流程。
二、客户输入的接收与校验
客户输入往往以多种格式到达：Excel通信矩阵、Vector DBC、ARXML系统描述、PDF诊断规范、甚至邮件中的口头约定。启动阶段必须完成一次输入完整性校验，重点检查：
- 通信矩阵中的报文ID、周期、信号长度是否与DBC一致；
- 诊断服务列表是否覆盖客户要求的UDS服务（如0x10、0x27、0x22、0x2E、0x31、0x3E等）；
- 网络管理类型（OSEK NM或AUTOSAR NM）及休眠唤醒策略是否明确；
- 功能安全需求是否已分配到具体软件组件，ASIL等级是否标注。
若发现缺失项，应在启动阶段以输入澄清清单形式反馈客户，避免在集成阶段才发现诊断服务未定义或信号映射冲突。
三、ETAS工具版本与BSW配置基线的匹配
ETAS工具链版本与BSW配置基线必须成对锁定。例如，某量产项目采用RTA-CAR 7.0.3配合ISOLAR-AB 9.2，则BSW配置应基于该版本自带的AUTOSAR 4.2.2模板。若客户要求AUTOSAR 4.4，则需确认工具是否支持，否则应提前升级或申请补丁。
BSW配置基线的建立通常从ECU提取文件（ECU Extract）开始，导入系统描述后生成初始配置。启动阶段应完成以下动作：
- 导入客户ARXML，检查ECU实例与软件组件映射；
- 启用项目所需BSW模块，关闭未使用模块以减少代码体积；
- 配置基础参数：时钟、看门狗、通信控制器、诊断通道；
- 生成第一版配置报告，记录模块版本、参数差异与待确认项。
此时不要求配置完整，但必须形成配置基线快照，作为后续迭代的起点。
四、交付计划模板的关键字段
交付计划不是简单的甘特图，而应包含可验证的里程碑与交付物对应关系。一个实用的交付计划模板至少包含以下字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 里程碑 | 关键评审或交付节点 | BSW配置冻结 |
| 交付物 | 该节点产出的具体文件 | BSW配置包、生成代码 |
| 依据基线 | 对应的客户输入或工具版本 | 通信矩阵V2.1、RTA-CAR 7.0.3 |
| 责任人 | 负责交付的工程师 | BSW配置工程师 |
| 验收标准 | 如何判断交付合格 | 编译通过、诊断服务响应正确 |
| 计划日期 | 预计完成时间 | 2025-06-15 |
该模板可直接用于项目周会跟踪，每个里程碑完成后更新实际日期与偏差原因。
五、启动阶段基线关系图
下图展示了四类基线之间的约束关系与交付流向，帮助理解启动阶段各要素如何相互锁定。
六、启动评审会与基线冻结
启动评审会是基线冻结的正式场合。会议输出应包括：
- 基线清单：四类基线的版本号、责任人、冻结日期；
- 待澄清项清单：客户输入缺失或矛盾之处，明确关闭时间；
- 交付计划：按里程碑排列的交付物与验收标准；
- 风险登记：工具版本不匹配、诊断服务未定义、功能安全需求未分配等。
完成上述工作后，项目才具备进入详细配置与集成阶段的条件。启动阶段的质量直接决定后续返工量，基线越清晰，量产交付越可控。