3. 一致性验证的度量与标准

在 MBD 开发流程中,模型与生成代码之间的一致性不能只靠“看起来一样”来判断。工程上必须把一致性拆解为可度量、可判定的维度,并对照功能安全标准给出的验证要求,确定每个维度需要达到的证据强度。本节围绕五个核心维度展开:结构一致性、行为一致性、时序一致性、数据一致性,以及 ISO 26262 与 DO-178C 对验证活动的约束。

结构一致性:模型元素与代码实体的可追溯映射

结构一致性关注的是模型中的层次、子系统、模块、信号、参数与生成代码中的文件、函数、变量、常量之间是否存在稳定且可追溯的对应关系。典型度量包括:模型模块与代码函数的一对一映射率、未映射元素数量、命名偏差率、接口端口与函数参数的一致性比例。例如,一个 Simulink 子系统 ThrottleCtrl 生成代码后应能定位到对应的 ThrottleCtrl_step() 函数,其输入端口 PedalPos 应映射为函数参数或结构体成员,而不是被优化掉或改名后无法追溯。

结构一致性通常通过代码生成报告、模型-代码追溯矩阵、静态扫描工具来检查。若模型模块在代码中找不到对应实体,或代码中出现模型未定义的全局变量,就应判定为结构不一致。该维度的判定标准一般是“映射覆盖率 100%,未映射项为 0”,但允许在明确记录优化策略的前提下存在受控偏差。

行为一致性:输入输出关系与状态迁移的等价性

行为一致性要求模型在给定输入序列下产生的输出、状态迁移、条件分支与生成代码执行结果等价。度量方式包括:相同测试向量下模型输出与代码输出的最大绝对误差、状态变量偏差、分支覆盖率差异、条件判定结果不一致次数。例如,对 PI 控制器模型输入阶跃信号,模型输出与代码输出在 1000 个采样点上的最大误差应小于 1e-6(浮点)或完全一致(定点)。

行为一致性验证通常采用 SIL(Software-in-the-Loop)与 MIL(Model-in-the-Loop)对比。若模型使用浮点,代码使用定点,则必须明确量化误差边界,并判断该误差是否影响功能。行为不一致往往来自舍入模式、饱和处理、查表插值方式或条件执行顺序的差异。

时序一致性:采样周期、执行顺序与延迟

时序一致性关注模型仿真步长、任务周期、函数调用顺序、状态更新时刻与代码实际执行时序是否一致。度量包括:采样周期偏差、任务抖动、执行顺序一致性、单位延迟与状态更新时刻偏差。例如,模型中以 0.01 s 周期运行的控制器,生成代码后若被调度到 0.02 s 任务中,即使行为逻辑正确,也会因时序不一致导致闭环性能下降甚至失稳。

时序一致性检查需要结合调度配置、任务映射表、代码执行时间测量。对于多速率模型,还要检查速率转换模块是否在代码中正确实现。判定标准通常是“采样周期与模型配置一致,任务执行顺序与模型排序一致,关键路径延迟不超过允许阈值”。

数据一致性:类型、精度、范围与初始化

数据一致性覆盖数据类型、字长、定点标度、数值范围、初始值、参数存储类别。度量包括:类型匹配率、定点标度偏差、溢出次数、初始化值偏差、参数可标定性与模型配置的一致性。例如,模型中将 Kp 定义为 single 类型、初值 1.2,代码中却生成为 double 或初值被清零,就属于数据不一致。

数据不一致常出现在定点化、数据类型继承、参数对象配置错误等场景。验证时应逐项比对模型数据字典与代码中的变量声明、初始化段和标定接口。对于安全相关信号,还应检查是否存在未初始化使用、隐式类型转换或精度损失。

一致性验证五维度与安全标准约束关系 模型侧 子系统 / 模块 状态机 / 逻辑 采样周期 / 任务 数据字典 / 参数 功能需求 / 安全目标 一致性维度与度量 结构一致性 映射覆盖率、未映射元素数、命名偏差率 行为一致性 输出最大误差、状态偏差、分支覆盖差异 时序一致性 采样周期偏差、任务抖动、执行顺序一致性 数据一致性 类型匹配率、定点标度偏差、溢出次数 功能安全标准约束 ISO 26262 ASIL / DO-178C DAL 证据要求 代码侧 函数 / 文件 条件分支 / 状态 调度任务 / 中断 变量 / 常量 / 标定 安全机制 / 诊断 判定:各维度度量满足阈值 → 一致性通过

功能安全标准对验证的要求

ISO 26262 与 DO-178C 并不直接规定“模型与代码必须逐位一致”,而是要求开发过程具备可追溯性、验证独立性和足够的证据强度。ISO 26262 按 ASIL A 至 D 分级,ASIL 越高,对模型-代码一致性的验证方法要求越严格。例如,ASIL D 通常要求使用形式化验证或结构化覆盖率分析,并保留双向追溯记录;ASIL A/B 可接受基于需求的测试与评审。DO-178C 则按 DAL A 至 E 分级,DAL A 要求目标代码与模型之间的验证证据达到最高完整性,包括鲁棒性测试、最坏执行时间分析和独立验证。

两个标准共同强调:一致性验证不是一次性活动,而应贯穿模型设计、代码生成、集成测试和变更管理。任何模型修改都必须触发对应代码的重新生成与一致性复核,并保留变更影响分析记录。

实践提示:在项目早期就应建立“一致性度量矩阵”,把每个维度对应的度量项、阈值、验证方法、责任人、证据存放位置固定下来。例如,结构一致性用追溯矩阵,行为一致性用 MIL/SIL 对比报告,时序一致性用调度分析表,数据一致性用数据字典比对表。这样在安全审核时可以直接按矩阵提交证据,而不是临时拼凑。

度量阈值与判定示例

以下给出一个示例性的度量表,用于说明如何把五个维度转化为可判定的条目。表中数值为教学示例,实际项目应根据 ASIL/DAL 等级、模型复杂度和工具链能力确定。

维度 度量项 示例阈值 验证方法
结构一致性 模型-代码映射覆盖率 100%,未映射项 0 追溯矩阵 + 静态扫描
行为一致性 相同测试向量下输出最大绝对误差 ≤ 1e-6(浮点) MIL/SIL 对比
时序一致性 采样周期偏差 0(与模型配置一致) 调度分析 + 执行时间测量
数据一致性 类型与标度匹配率 100% 数据字典比对
安全标准 双向追溯完整性 需求-模型-代码-测试全链路可追溯 评审 + 工具报告

需要强调的是,一致性验证的最终目的不是追求“零差异”这一形式指标,而是证明生成代码在目标运行环境中能够安全、正确地实现模型所定义的功能。当差异不可避免时,必须评估差异是否影响安全目标,并给出明确的接受理由和补偿措施。只有把度量、标准与工程判断结合起来,一致性验证才真正具备安全价值。