校验¶
修改 ROM 之后 ECU 仍会接受它，但可能通不过安全或排放测试。校验做两件事：证明 你写入的数据在正确的位置，并重新计算 checksum 区域。
checksum 是什么？¶
许多 ECU 会在代码与数据区块内或末尾保存一个完整性校验值。若该值没有变化， ECU 会认为"没有被改动"。写入会使它失效；若不修正，ECU 就会自行决定（通常 进入应急模式）。
校验与修正¶
项目 ▸ 校验 checksum 检查所选算法的全部区块，项目 ▸ 修正 checksum
重新计算失败的区块。
流程：
- 选择 ECU 类型。
- 运行校验，列表会显示失败的区块。
- 先完成标定图修改，最后执行 checksum 修正 —— 否则 checksum 会 再次失效。
- 修正后再次校验。
Checksum 对话框¶
项目 ▸ 校验/修正 checksum 会打开 WinOLS 风格的表格窗口：
| 列 | 含义 |
|---|---|
# |
行号 |
Algorithm |
算法名称 |
From / To |
覆盖的地址范围 |
Manually |
手动添加的条目 |
AutoCorr. |
是否启用自动修正 |
按钮：Search（在该 ROM 上重新检测）、Add…（从已安装列表手动添加 算法）、Properties…（查看选中条目详情）、Delete（删除手动添加项）、 Apply（在内存中重新计算 checksum）与 Installed plugins…（已安装的 checksum 模块）。Apply 只产生一步撤销；如对话框底部提示，checksum 会在导出时自动重新计算。
Checksums 面板与状态栏¶
项目 ▸ Checksums（或 视图 ▸ Checksums）会在右侧打开一个常驻停靠面板
（默认关闭）。面板自动检测当前 ROM，并为每个 checksum 引擎显示一行（先原生
Spec，后 DLL 算法）：
| 列 | 含义 |
|---|---|
# |
行号 |
Algorithm / Engine |
算法或引擎名称 |
Family |
匹配的 ECU 家族 |
From / To |
覆盖的地址范围 |
Status |
ok / mismatch / unknown |
Correctable |
该行能否被安全修正 |
- Verify 只进行计算，绝不改动 ROM。
- Correct & Apply 只重写
correctable的行，并把全部改动作为单步撤销 提交。 - Refresh 重新运行检测；工程变化或 ROM 被编辑时，面板会（去抖后）自动刷新。
状态栏右侧有 WinOLS 风格的实时指示，编辑后会自行更新：
All CS ok — Checksum block N: okay—— 全部区块有效，CS mismatch — N issue(s)—— 存在不匹配，No checksum module—— 该家族没有可用引擎，CS: unknown (no definition)—— 有引擎但该家族没有定义。
导出时自动修正¶
启用 项目 ▸ Correct checksums on export（可勾选）后，导出 ROM 时会自动修正
检测到的全部 checksum 区块——仅作用于导出的副本，工程中的 ROM 不会被
修改。关闭时，应用会在写入前询问是否修正。
每次导出 ROM 前都会先弹出预览对话框，显示文件名、大小以及当前的 checksum
状态——有效、无效——将在导出时修正、无效——将提示你修正 或 无法验证。
若未检测到算法，则跳过修正并在状态栏给出提示；导出不会被阻止。
家族定义与"无法验证"状态¶
导出前的最后一次检查还会参考可选的 ECU 家族 checksum 目录
（data/ecukb/checksum_families.json），它把 ECU 家族映射到可读的算法提示。
程序会区分两种情况：
- 算法已知但未检测到 —— 目录中有该家族的提示；导出继续进行，并建议使用
修正 checksum…。 - 没有家族定义 —— 目录中没有匹配项；checksum 会被标记为
无法验证，ROM 在未修改的情况下导出。此时刷写前必须自行验证 checksum。
若目录缺失，则无法进行上述区分，该功能会静默关闭；导出同样不会被阻止。
内置（原生）checksum 引擎¶
应用自带一个配置驱动的原生 checksum 引擎，无需 DLL。家族→算法的映射从
data/ecukb/native_checksums.json 读取（由
tools/dataset/build_native_checksums.py 生成）。该引擎支持累加
（Sum8/16/32）、XOR 与 CRC（CCITT/IBM/IEEE 及自定义参数）类型。
- 原生优先、DLL 兜底： 若家族有原生定义，先尝试原生引擎；没有定义时才使用 Windows 模块库。
- 安全修正： 原生引擎只对标记为
correctable且区块落在 ROM 范围内的 Spec 写入；未知家族时校验返回known=false，不修改任何字节。
Bosch MED17/EDC17 的校验与修正也已内置，无需任何 DLL。其他系列使用 Windows 模块库。
Checksum 覆盖范围¶
家族→算法知识经 WinOLS checksum 模块、Ecus.txt/Modelle.txt、FTAG 与网络
调研扩充。当前覆盖：152 个家族（checksum_families.json）、113 个
WinOLS 家族（winols_checksum_families.json）与 13 个原生算法
（native_checksums.json）。覆盖数据是可选的；缺失时指示会显示"无定义"
（安装见 DATASET_SETUP.md）。
148 模块的 Windows 库¶
ChecksumDLL/ 包含 148 个 32 位模块。它们在 32 位 Windows 上运行，由 64 位
应用通过 checksumhelper.exe 辅助进程调用。
必需运行库
模块依赖 Microsoft Visual C++ 2005 SP1 (x86) 运行库。未安装时模块 无法加载，应用会明确提示。
模块仅在 Windows 上可用；Linux 与 macOS 只有内置的 MED17/EDC17 路径。
为什么要单独的进程？¶
checksumhelper.exe 是 32 位辅助进程。ROM 数据通过临时文件在两个进程之间
传递，这样 64 位应用无需把 32 位 DLL 加载进自己的地址空间即可运行它。
Version Overview（版本对比矩阵）¶
视图 ▸ Version Overview… 打开一个矩阵：行为标定图，列为版本，每个单元格
显示该标定图在该版本中相对原始 ROM 变化了多少字节。顶部的版本选择器 +
注释行可编辑每个版本的注释。项目 ▸ 保存版本快照 时注释会自动生成 ——
以 "N map(s), M byte(s) changed" 的形式概括变化的标定图数与字节数，
之后可随意修改。
Accept changes（从另一工程转移操作）¶
项目 ▸ Accept Changes from Project… 把另一个 .mtrp 工程中的修改转移到
当前工程。匹配依据是数值模式而非地址，因此即使源工程的标定图位于不同
地址，操作也能按位置无关的方式应用。
Watermark（数字签名）¶
项目 ▸ Sign ROM (Watermark)… 在 ROM 最大的空白（0x00/0xFF）区嵌入不可见
的所有权签名；不影响正常读取与驾驶行为。项目 ▸ Verify Watermark 可查找并
验证该签名，日后可证明某文件出自你的工作台。
处理器识别¶
其他 ▸ Detect processor… 扫描 ROM 中的已知签名，给出 CPU 系列估计与置信度
百分比。在选择 checksum 算法之前，可用它快速确认 ECU 系列。
一定要与外部工具交叉验证¶
把应用的结果看作多方意见之一：
- ECU 厂商自带的工具集，
- 厂商的 checksum/校验软件，
- 台架与排放测试结果。
即使应用报告成功，若地址匹配错误，整条验证链依然无意义。验证中最薄弱的一环 不是 checksum，而是地址匹配。
A2L 基地址验证¶
A2L 中的地址是相对基地址给出的。基地址错误会让标定图打开在错误位置，而 checksum 校验无法发现。首次使用时：
- 用你已知的地址与 A2L 中的值对照。
- 确认 ROM 在该地址处确实是有意义的数据。
- 必要时手动修正基地址列表。
保存并重新打开测试¶
最简单的完整性测试：
- 保存改动。
- 关闭工程。
- 重新打开文件。
- 运行校验并检查你编辑过的标定图数值。