4. 变更请求的接收与分类
在量产交付阶段，变更请求（Change Request, CR）不会只从单一渠道出现。客户在整车路试中反馈某个诊断服务响应超时，内部测试团队在回归测试中发现某个DTC状态位跳变异常，供应商在芯片或协议栈升级后通知某个驱动接口行为变化——这三类来源的变更请求，其描述方式、紧急程度、证据完整度和影响范围往往差异很大。如果接收环节没有统一入口和分类标准，后续的评估、排期和验证就会陷入“谁先喊谁先做”的混乱。本节要解决的核心问题是：如何把来自客户、内部测试、供应商的变更请求，统一收敛到DaVinci工程上下文中，完成影响范围初判和优先级分类。
一、三类来源的接收差异与统一入口
客户来源的变更请求通常以“现象+期望”的形式出现，例如“车辆在售后诊断仪执行0x27安全访问时，连续三次错误密钥后未进入延迟锁定状态，期望符合ISO 14229-1的延迟时间要求”。这类请求的强项是业务场景明确，弱项是往往缺少工程定位信息，需要接收人主动追问ECU变体、软件版本、诊断会话类型和复现条件。
内部测试来源的变更请求通常带有测试用例编号、失败日志和期望结果，例如“TC-DIAG-0421在扩展会话下执行0x2E写入DID 0xF190失败，返回NRC 0x31，期望返回0x22条件不满足”。这类请求的强项是证据链完整，弱项是可能只覆盖单一测试路径，需要判断是否属于测试用例本身的问题还是软件缺陷。
供应商来源的变更请求通常以“变更通知+影响说明”的形式出现，例如“AUTOSAR基础软件版本从4.4.0升级到4.4.1，Dcm模块的会话状态机在默认会话到编程会话切换时增加了一个内部状态”。这类请求的强项是技术描述准确，弱项是供应商往往只说明自身模块变化，不评估对整车项目配置的连锁影响。
统一入口的做法是：无论来源如何，都先登记到变更请求台账，字段至少包括CR编号、来源类型、提交人、提交日期、关联ECU变体、关联软件版本、现象描述、期望结果、证据附件、初步分类和初判影响范围。台账不是形式主义，而是后续在DaVinci工程中做影响分析时的索引。
二、用DaVinci工程上下文做影响范围初判
DaVinci工程上下文的核心价值在于：它把ECU的配置、生成代码、诊断数据库、通信矩阵和标定参数组织在一个可追溯的工程结构中。接收变更请求后，不要急于打开代码，而是先在工程上下文中定位“这个变更会碰到哪些配置对象”。
以客户反馈的0x27安全访问延迟锁定问题为例，影响范围初判可以按以下路径展开：
- 在DaVinci Configurator中打开对应ECU工程，定位Dcm模块的DcmDspSecurity配置容器，确认当前安全等级、密钥算法、延迟锁定时间和错误计数阈值。
- 检查DcmDspSecurityDelayTime和DcmDspSecurityNumAttDelay参数是否与客户期望一致。若参数本身配置正确，则问题可能出在状态机实现或集成代码。
- 沿工程引用关系查看Dcm与Dem、ComM、BswM的接口连接，判断延迟锁定状态是否被其他模块覆盖或复位。
- 检查生成的Dcm_Cfg.c和Dcm_Lcfg.c中安全访问相关的配置结构体，确认生成结果与配置意图一致。
- 若涉及诊断数据库，检查ODX/CDD文件中0x27服务的状态机描述是否与DaVinci配置同步。
对于内部测试来源的0x2E写入失败问题，影响范围初判的重点不同：先确认DID 0xF190在DaVinci中的DcmDspDid配置是否存在、是否绑定了正确的DcmDspDidDataElement、写权限条件是否配置为扩展会话。若配置正确，再检查RTE端口连接和SWC中的写入回调是否被正确生成。这类问题的初判结论通常是“配置缺失”或“集成错误”，而不是“算法错误”。
对于供应商来源的BSW升级问题，影响范围初判要更谨慎：先在DaVinci工程中查看当前使用的BSW版本和模块依赖关系，再对照供应商变更说明，逐项检查Dcm、Dem、Com、PduR等模块的配置是否受到接口行为变化的影响。特别要注意那些“默认行为变化”的条目，因为它们不会在编译时报错，但会在运行时改变诊断响应。
三、优先级分类的判断维度
优先级分类不能只看“客户催得急不急”。在量产交付阶段，建议从四个维度综合判断：
| 维度 | 判断问题 | 示例 |
|---|---|---|
| 安全与法规 | 是否影响功能安全、排放法规或诊断法规符合性？ | 0x27延迟锁定失效可能影响防盗合规 |
| 交付节点 | 是否阻塞当前SOP节点或客户装车节点？ | 客户下周装车，诊断写入失败必须本周修复 |
| 影响范围 | 影响单一变体还是全平台？影响诊断、通信还是应用层？ | BSW升级影响所有使用该基础软件的ECU变体 |
| 修复成本与风险 | 修改是否涉及生成代码重新集成、是否需要重新标定或重新认证？ | 仅改Dcm参数可快速回归；改状态机需完整诊断测试 |
基于这四个维度，可以把变更请求分为三类：紧急变更（影响安全法规或阻塞SOP，需立即评估并给出临时措施）、常规变更（影响功能但可通过计划版本修复，纳入下一个迭代）、观察项（影响轻微或证据不足，先记录并持续跟踪）。分类结果要写回变更请求台账，并同步给客户、测试和供应商三方，避免信息不对称。
四、从接收到分类的完整判断路径
下面这张图把三类来源的变更请求、DaVinci工程上下文中的影响定位对象，以及优先级分类的判断路径放在同一张关系图中。图中左侧是来源入口，中间是工程上下文中的关键配置容器和文件，右侧是分类结果。读者可以沿着箭头方向理解：一个变更请求从进入台账到完成初判，需要经过哪些工程对象，以及最终如何落到优先级分类。
在实际操作中，影响范围初判和优先级分类往往需要迭代。第一轮初判可能只定位到Dcm配置，第二轮在检查生成代码时发现RTE连接也有影响，第三轮在对照供应商变更说明时又发现BSW版本升级引入了新的状态。因此，变更请求台账中的“初判影响范围”和“优先级”字段应允许更新，并记录每次更新的依据和时间。这样，当变更进入实施阶段时，团队能够清楚地知道当初为什么把它定为紧急或常规，避免在资源冲突时反复争论。
最后需要强调的是：接收与分类的目标不是“快速关闭变更请求”，而是“让正确的变更在正确的时间被正确处理”。客户、内部测试和供应商三类来源各有盲区，DaVinci工程上下文提供了统一的定位语言，优先级分类则提供了资源分配的判断依据。把这三者串起来，变更管理才真正具备量产交付所需的可追溯性和可控性。