4. SDV服务生命周期总览
在软件定义汽车（SDV）中，一个车载服务（Service）并不是“写完代码、刷进车机”就结束了。它更像一个有生命周期的产品实体：从最初的需求假设，到设计、开发、测试、发布、运维，最终走向退役。服务生命周期治理的核心目标，是让每个阶段都有明确的输入、输出、责任人和质量门禁，使服务的版本演进可追溯、可回滚、可审计。
本节将SDV服务生命周期划分为七个阶段，并给出每个阶段的关键里程碑。理解这条主线，是后续版本治理、灰度发布、OTA回滚等工程实践的基础。
一、核心原理：为什么SDV服务需要生命周期治理
传统ECU软件往往是“一版定终身”，刷写后很少再变。而SDV服务运行在中央计算平台或区域控制器上，具备持续OTA能力，版本迭代频率从“年”提升到“周”甚至“天”。如果没有生命周期治理，会出现三类典型问题：
- 版本漂移：不同车型、不同批次车辆上运行的服务版本不一致，故障难以复现。
- 依赖断裂：服务A升级后，依赖它的服务B接口不兼容，导致功能失效。
- 退役遗留：旧服务已下线，但配置、证书、数据仍在后台占用资源，形成安全隐患。
生命周期治理的本质，是把“服务”当作有状态的实体来管理。每个阶段都有明确的准入条件（Entry Criteria）、交付物（Deliverables）和退出准则（Exit Criteria），并通过里程碑进行评审和冻结。
二、七阶段划分与关键里程碑
下表给出七个阶段的核心任务、交付物和里程碑，便于在项目中直接对照使用。
| 阶段 | 核心任务 | 关键交付物 | 里程碑 |
|---|---|---|---|
| ① 需求 | 收集整车功能需求，拆解为服务级需求，定义SLA | 服务需求规格、SLA草案 | M1 需求评审通过 |
| ② 设计 | 定义接口、数据模型、部署拓扑、资源配额 | 接口定义（IDL）、设计说明书 | M2 设计冻结 |
| ③ 开发 | 编码、单元测试、镜像构建、依赖锁定 | 服务镜像、SBOM、单元测试报告 | M3 代码合入主干 |
| ④ 测试 | 功能、性能、安全、兼容性、HIL/SIL测试 | 测试报告、缺陷清单、覆盖率报告 | M4 测试通过 |
| ⑤ 发布 | 版本打包、签名、灰度策略配置、OTA推送 | 发布包、灰度计划、回滚预案 | M5 发布批准 |
| ⑥ 运维 | 监控告警、日志采集、热修复、性能调优 | 运维看板、故障报告、补丁版本 | M6 稳定运行 |
| ⑦ 退役 | 服务下线、数据归档、证书吊销、资源回收 | 退役报告、归档记录 | M7 退役确认 |
三、方法流程：以版本为主线串联七阶段
在工程实践中，七阶段并不是串行瀑布，而是以“版本”为主线并行推进。每个服务版本从需求到退役，都会经历一条独立的生命周期轨迹。推荐的做法是：
- 建立服务清单：为每个服务分配唯一Service ID，记录所属域、责任人、当前阶段。
- 版本号规范：采用语义化版本
MAJOR.MINOR.PATCH，并附加构建号与车型适配标识。 - 阶段状态机：用状态机描述服务当前所处阶段，禁止跨阶段跳转。
- 门禁自动化：在CI/CD流水线中嵌入各阶段准入检查，未通过则阻断流转。
下面是一个服务版本元数据的示例配置，用于在发布系统中标识生命周期状态：
service:
id: "adas.lane-keep"
version: "2.3.1+build.20240612"
stage: "released" # draft / designed / developed / tested / released / operating / retired
target_vehicle: ["X01", "X02"]
dependencies:
- "perception.lane-detect >= 1.8.0"
- "vehicle.can-gateway >= 3.0.0"
sla:
latency_p99_ms: 50
availability: "99.95%"
rollback:
previous_version: "2.3.0"
strategy: "canary-5%-20%-100%"四、案例场景：一次车道保持服务的版本升级
某车型的车道保持服务从2.3.0升级到2.3.1，修复了弯道场景下的轻微画龙问题。按照生命周期治理流程：
- 需求阶段：收到售后反馈，形成缺陷需求，评审后确认影响范围。
- 设计阶段：确认接口不变，仅调整控制参数，设计冻结。
- 开发阶段：修改参数标定，构建新镜像，生成SBOM。
- 测试阶段：在SIL和HIL环境回放弯道场景，验证通过。
- 发布阶段：先向5%车辆灰度推送，观察48小时无异常后全量。
- 运维阶段：监控画龙指标，确认改善后关闭缺陷单。
- 退役阶段：2.3.0版本在全部车辆升级完成后标记为退役，归档其镜像与配置。
提示：灰度发布不是“可选动作”，而是发布阶段的强制门禁。没有灰度策略的版本，不应被批准进入发布阶段。
五、常见误区与复盘
误区一：把“测试通过”当作“可以发布”。测试通过只是M4，发布还需要签名、灰度策略、回滚预案和发布评审，缺一不可。
误区二：退役阶段被忽略。很多团队只关注上线，不关注下线。旧版本长期残留会导致依赖混乱、安全漏洞无法收敛。退役必须有明确的确认动作和归档记录。
误区三：版本号随意命名。没有语义化版本规范，就无法判断兼容性。MAJOR变更意味着不兼容，必须触发依赖服务的兼容性评审。
复盘建议：在每个里程碑设置“检查清单”，由责任人签字确认。将生命周期状态可视化到看板上，让每个服务的当前阶段、阻塞原因、下一里程碑一目了然。只有这样，SDV服务的版本治理才能从“救火”走向“可控”。