两份文件看起来有关联却仍可能是错误的对比
将原始文件与修改后文件进行对比听起来很简单：打开双方，找出差异并检查被改动的标图（maps）。当两份文件并非基于相同的软件基础时，问题就出现了。
OEM 更新可能会移动数据、替换代码区段、改变校准结构或引入新的标图变体。虚拟读取（virtual read）可能来自匹配的数据库文件，而不是 ECU 中先前存储的精确字节。客户提供的文件则可能已经包含未记录的改动。
WinOLS 可以显示差异、连接项目并支持变更传输，但软件无法替代文件识别与技术判断。在导入任何内容之前，调校师必须确认每个文件的性质以及比较是否有效。
在比较前先定义文件
在项目中使用清晰的术语：
- ORI： 针对该具体 ECU 软件经验证的原始或可用的最佳基线。
- MOD： 从已记录基线派生的修改版本。
- OEM update： 制造商发布的后续或不同的软件版本。
不要仅因为文件名包含“original”就将文件标记为ORI。文件名只是注记，而非证据。
建立文件识别记录表
在打开对比视图之前，记录每个文件可用的识别信息。
| 识别字段 | 文件 A | 文件 B |
|---|---|---|
| ECU 系列 | 记录的精确类型 | 记录的精确类型 |
| 硬件编号 | 来自工具或标签的数值 | 来自工具或来源的数值 |
| 软件编号 | 精确数值 | 精确数值 |
| 标定号或更新号 | 如可用则显示 | 如可用则显示 |
文件大小一致有参考价值，但并不能证明两个文件共享相同的软件结构。
三种不同的比较场景
大多数 WinOLS 比较工作属于以下三种情况之一。每种情况都需要不同程度的谨慎。
1. 同一基线的 ORI 与 MOD
这是最干净的比较。MOD 是直接从 ORI 创建的，两个文件结构相同。差异应对应已记录的标定修改以及任何预期的校验和相关变化。
2. 不同 OEM 软件版本之间的比较
这并非典型的调校比较。由于制造商可能更改了代码、诊断、标定结构或数据对齐，大片区域可能存在差异。此类差异不应被误解为调校改动。
3. 已修改的旧版本 与 更新后的较新 OEM 版本 的对比
这是风险最高的迁移场景。旧地址可能不再指向相同的映射表。应当根据新软件结构重新生成并验证改动，而不是盲目复制。
从宏观差异审查开始
在打开单个映射表之前，先观察整体差异模式。
需要问：
- 改动是否集中在一个小的标定区域？
- 差异是否分布在文件的大部分？
- 是否有大块数据出现位移？
- 代码区和标定区是否都发生了变化？
- 是否存在重复的差异模式？
一小组紧凑的标图更改可能与正常的标定编辑一致。大范围且分散的差异通常在得出标图层面的结论前需要先进行软件版本分析。
差异模式是线索，而非证据
| 差异模式 | 可能的解释 | 需要检查项 |
|---|---|---|
| 已知标图内部的小簇变化 | 有记录的标定更改 | 确认轴、单位和预期功能 |
| 大范围连续区域差异 | OEM 软件更新或不同文件基底 | 核实软件编号和代码结构 |
| 重复的孤立字节 | 校验和、计数器、元数据或工具处理导致 | 检查协议和校验和 |
任何模式都不应被视为绝对保证。将其作为需进一步检查项的判定依据。
比较的是标图而不仅仅是地址
地址只在其所属的软件结构内有效。当文件来自不同软件版本时，同一功能可能存放在另一个地址或以不同方式表示。
对每个要比较的标图，请确认：
- 标图维度；
- 坐标轴数值；
- 坐标轴顺序；
- 数据类型；
- 字节序；
- 缩放因子和偏移量；
- 工程单位；
- 周边数据结构；
- 与相关目标图和限幅图的关系。
形状相同的表格并不一定代表功能相同。坐标轴和周边逻辑也必须合理。
谨慎使用参考版本
在审查同一项目基线或进行受控更新比较时，参考版本很有用。它让技师能够在不频繁切换文件的情况下检查数值和差异。
一个清晰的工作流程是：
- 保持已验证的原始版本不被更改。
- 将比较文件作为单独版本或关联项目创建或导入。
- 在连接文件之前确认项目标识。
- 先审查整体差异。
- 打开已知的映射并比较其结构与数值。
- 记录哪些更改已被确认、存疑或被拒绝。
不要仅因为 WinOLS 能识别相似区域就自动转移更改。
何时适合自动导入
当文件基于相同的软件基础且原始与修改之间的对应关系已被记录时，导入更改最为可靠。
在以下情况下，应慎重对待自动或半自动转移：
- 软件编号不同；
- 其中一个文件是 OEM 更新；
- 一个文件是虚拟读取而另一个是物理读取；
- 映射地址已经移动；
- 源 MOD 包含未记录的补丁；
- 文件大小或内存布局不同；
- 源项目使用未经验证的定义。
在这些情况下，请逐表重建所需的标定变更，并在目标软件上验证其逻辑。
创建变更传递工作表
| 映射或功能 | 来源状态 | 目标匹配 | 操作建议 |
|---|---|---|---|
| 驾驶员请求 | 在来源中已确认 | 坐标轴与单位已匹配 | 重建并复核 |
| 扭矩限制器 | 已确认 | 在目标中找到多个变体 | 编辑前先调查清楚 |
| 压力目标 | 在来源中已更改 | 缩放比例未确认 | 请不要直接修改，先确认标度与单元 |
此工作表可防止未记录的源端更改悄然进入新项目。
不要盲目按百分比转移更改
一个常见的捷径是计算旧 MOD 中某值的变化百分比，然后将相同百分比应用到新软件中看起来相似的映射上。这种做法可能具有误导性，因为厂商可能已经更改了基准值、单位、限制器关系或控制策略。
相反，应当询问：
- 最初的编辑目的是为了达到什么结果？
- 新软件中是否已包含修订后的目标？
- 哪些相关映射控制相同的功能？
- 坐标轴和工作区域是否等效？
- 是否可以通过日志验证预期的结果？
传递的是标定目标，而不仅仅是旧数值。
将标定改动与补丁和元数据区分开
并非每处差异都是地图编辑。文件差异也可能由以下原因造成：
- 校验和修正；
- 工具特有的处理；
- 编程计数器；
- 软件补丁；
- 版本元数据；
- 诊断配置；
- 未知的先前修改。
在批准文件之前，应对文档化标定区域以外的不明改动进行调查。
转移后验证目标项目
在重建或导入更改后，进行完整的项目复查：
- 核对每个被编辑的标图及其坐标轴；
- 检查相关的目标值与限幅器；
- 确认单位与缩放比例；
- 检查插值和边界单元；
- 确认没有非预期的区域被修改；
- 确认校验和（checksum）责任归属；
- 保存与目标 ORI 的差异报告；
- 清晰标注最终文件版本；
- 准备正确的恢复文件；
- 规划一次受控的诊断与数据记录测试。
一次成功的导出并不能证明标定逻辑就是正确的。
相关的 WinOLS 资源
有关定义匹配、map-pack 验证和量程检查，请参阅 WinOLS A2L/DAMOS 与 Map Packs。在写入完成的文件之前，请查看 WinOLS 校验和。
有关 ECU 软件版本讨论和真实文件案例，请参考 CarTechnology 或 MHHAuto。将论坛信息作为调研依据，并在实际目标项目中确认每一处更改。
文件比对检查清单
- 将每个文件归类为 ORI、MOD、OEM 更新、虚拟原始文件或未知。
- 记录 ECU 硬件和软件识别信息。
- 确认读取方法和文件大小。
- 检查文件是否基于相同的软件基础。
- 在打开标定表之前先审查整体差异模式。
- 按结构、坐标轴、单位和功能匹配标定表。
常见问题
我可以把较旧 OEM 软件版本的标定表复制到较新的版本吗？
不能仅凭地址安全复制。必须在较新软件中确认该标定表的功能、尺寸、轴向、缩放和周边策略，然后重新构建预期改动。
文件大小相同是否意味着文件兼容？
不。文件即便大小相同，也可能包含不同的代码、标定布局或软件版本。
什么是最安全的 ORI 与 MOD 比对？
最安全的比对应使用经过验证的原始文件，以及直接从同一原始基底创建并有文档记录的已修改版本。
为什么我编辑之外的区域会有差异？
这些差异可能来自校验和变更、元数据、工具处理、计数器或未记录的作业。批准文件前需先识别这些差异。
对于 OEM 更新，是否应使用自动导入？
只有在经过谨慎验证的情况下才可使用。软件基底发生变化时，标图可能会移动或改变结构，人工复核和受控重建通常更安全。
WinOLS 比较不仅仅是查找不同的字节。它是一个证明文件身份、理解软件关系并仅转移在目标版本中仍然有效的标定决策的过程。
