2. 标定与试验业务流程解析

标定与试验不是“跑一遍数据、导出一张图”这么简单。它本质上是一条从工程需求出发、经过试验设计、台架/整车执行、数据判读，最终收敛为可交付报告与标定参数的业务链路。自动化平台要做的，不是替代工程师思考，而是把这条链路上重复、易错、可结构化的环节固化下来，让工程师把精力集中在“判断”和“决策”上。

理解这条链路，先要抓住一个关键事实：链路上游的每一个定义，都会以参数、约束或判据的形式传递到下游。需求里写“怠速转速波动不超过 ±15 r/min”，到了执行阶段就变成采样率、稳态判定窗口、滤波截止频率；到了报告阶段就变成合格/不合格的判定阈值。如果上游定义含糊，下游就只能靠人反复试，自动化也就无从谈起。

需求定义：把工程语言翻译成可执行约束

需求定义阶段的产出不是一句“把怠速标好”，而是一组可测量、可判定的条目。以某四缸汽油机怠速标定为例，需求通常包含：工况点（冷却液温度 80±2 ℃、无空调负载、挡位空挡）、目标量（目标转速 800 r/min）、允许偏差（±15 r/min）、稳定时间（进入怠速后 5 s 内达标）、以及边界条件（电瓶电压 13.5±0.3 V）。这些条目要落到一张需求条目表里，每条带唯一编号，便于后续试验用例和报告逐条追溯。

这里最容易出问题的是“目标量”和“约束量”混在一起。目标量是标定要逼近的，约束量是不能越界的。比如怠速目标转速是目标量，而排放限值、爆震边界、排温上限是约束量。自动化平台在需求阶段就应把两类量分开存储，因为后续优化算法对它们的处理方式完全不同：目标量进目标函数，约束量进可行性判断。

试验设计：把需求拆成可执行的工况矩阵

试验设计阶段的核心动作是工况点分解与用例生成。仍以怠速为例，需求只给了一个工况点，但实际标定要考虑冷却液温度从 -10 ℃ 到 105 ℃、电瓶电压从 11.5 V 到 14.5 V 的组合。工程师不会全组合遍历，而是用边界点 + 典型点的方式构造矩阵：温度取 -10、20、80、105 ℃，电压取 11.5、13.5、14.5 V，共 12 个组合，再叠加空调开/关两个状态，得到 24 个用例。

每个用例要明确：进入条件、稳定判据、采集窗口、退出条件。例如“冷却液温度达到 80 ℃ 后保持 30 s，转速波动小于 20 r/min 持续 5 s，则开始采集 10 s 数据，采样率 100 Hz”。这些字段直接决定自动化脚本怎么写。试验设计阶段的输出是一张用例矩阵表，它是连接需求与执行的桥梁。

执行：从脚本调度到数据落盘

执行阶段是自动化平台价值最直观的环节。典型流程是：平台读取用例矩阵，逐条下发工况设定值给台架或 HIL，等待稳定判据满足，触发数据采集，保存原始数据与元数据（用例编号、时间戳、环境条件、软件版本、标定版本）。这里的关键是稳定判据必须由平台自动判断，而不是靠人盯着曲线点“开始采集”。

以转速稳定判据为例，平台可以每 100 ms 计算一次最近 2 s 的转速标准差，当标准差小于设定阈值且持续 5 s，即判定稳定。这个逻辑写成伪代码大致如下：

while not stable:
    window = last_2s(speed_samples)
    if std(window) < 8 r/min:
        stable_count += 1
    else:
        stable_count = 0
    if stable_count >= 50:   # 50 × 100ms = 5s
        stable = True
    sleep(100ms)
start_acquisition(duration=10s, rate=100Hz)

执行阶段还要处理异常：工况达不到、稳定超时、数据丢帧。平台应记录异常并继续下一条，而不是整批中断。这一点在批量试验中尤其重要，因为一次跑几百个用例，人工守候不现实。

数据判读与报告输出：从原始数据到结论

数据判读不是简单画图，而是按需求条目逐条判定。平台读取原始数据，计算每个用例的统计量（均值、标准差、最大偏差、超调量、稳定时间），再与需求阈值比对，输出“通过/不通过/需人工复核”三态结论。对于不通过的用例，要保留原始曲线和判定依据，便于工程师回溯。

报告输出阶段，平台自动生成结构化报告：需求条目追溯表、用例执行汇总、关键曲线、异常清单、标定参数建议值。报告的价值在于可追溯——每一条结论都能追到具体用例、具体数据、具体判据。这也是自动化平台相比人工整理最大的优势。

把这条链路拆开看，自动化平台真正要解决的是“信息在环节之间不失真地传递”。需求条目编号传到用例矩阵，用例编号传到数据文件，数据文件传到报告结论，每一步都能反向追溯。做到这一点，批量试验才不是“跑得多、错得也多”，而是“跑得多、结论依然可信”。