3. 仿真模型全生命周期中的可信度活动

可信度不是仿真交付前临时补做的一次性检查，而是贯穿模型从需求到退役的持续活动。若把可信度评估全部压到“测试阶段”，往往会出现两类问题：一是需求阶段没有定义可验证的精度指标，测试时无从判定；二是概念模型与详细模型之间缺少可追溯的假设记录，后期发现偏差时无法定位是建模假设错误还是代码实现错误。因此，本节按生命周期阶段梳理各阶段的可信度任务、关键输入与交付物，并给出可操作的示例。

需求分析阶段：把“可信”翻译成可验证指标

需求分析阶段的可信度任务不是证明模型可信，而是把使用方的任务需求转化为可验证的可信度需求。核心动作包括：明确模型用途（训练、论证、预测、辅助决策）、使用边界（工况范围、时间尺度、空间范围）、精度要求（关键输出量的允许误差）、以及验证与确认（V&V）的约束条件（可用的试验数据、经费、周期）。

例如某型无人机航程仿真，使用方要求“在巡航高度 3000～5000 m、风速不超过 15 m/s 条件下，航程预测误差不超过 8%”。这条需求可直接转化为验证指标：以 6 组飞行试验数据为基准，计算航程相对误差，要求 6 组中至少 5 组误差 ≤8%，且最大误差 ≤12%。若需求只写“航程预测要准确”，则无法设计验证方案，也无法判定模型是否可信。

本阶段交付物通常包括：可信度需求规格说明（含用途、边界、精度指标、验证数据来源）、V&V 计划草案（验证方法、判据、资源需求）。这些文件是后续各阶段可信度活动的“合同”，任何指标变更都应在此追溯。

概念模型阶段：显式化假设与简化

概念模型是真实世界到数学/逻辑模型的第一次映射，也是可信度风险最高的环节。本阶段的可信度任务是：识别并记录建模假设、简化与忽略项，评估其对关键输出的影响，并建立概念模型与需求之间的可追溯关系。

实际操作中，可采用“假设—影响”表：列出每条假设（如“忽略发动机推力随马赫数的瞬态变化”），标注影响的关键输出（航程、爬升率），给出影响量级估计（示例：在巡航段影响 <1.5%），并说明验证方式（与试验数据对比或高保真模型交叉验证）。若某条假设影响量级接近或超过精度指标，则必须重新审视简化是否可接受。

本阶段交付物包括：概念模型文档（含假设清单、简化依据、影响评估）、概念模型验证记录（与需求的一致性检查、与领域专家评审结论）。

详细模型与代码实现阶段：把假设变成可执行、可追溯的代码

详细模型阶段将概念模型转化为方程、算法与数据结构；代码实现阶段将其转化为可运行程序。可信度任务在此阶段体现为“可追溯性”与“可验证性”：每个关键方程、参数、分支都应有来源（需求、假设、试验数据或文献），代码中的变量命名、单位、坐标系应与模型文档一致。

例如在航程仿真中，若概念模型假设“燃油消耗率仅与推力有关”，则详细模型应明确燃油消耗率函数 sfc = f(T) 的拟合数据来源与适用范围；代码中应保留单位转换（如 N 与 kgf、m/s 与 km/h）的显式检查，避免因单位不一致导致 3.6 倍量级错误。建议在代码中嵌入“可信度断言”：当输入超出使用边界（如风速 >15 m/s）时，程序应给出警告或拒绝运行，而不是静默外推。

本阶段交付物包括：详细模型文档（方程、参数表、单位与坐标系定义）、代码与版本记录（含配置管理、变更日志）、可追溯性矩阵（需求—假设—方程—代码—测试用例的对应关系）。

测试阶段：用证据判定可信度

测试阶段的可信度任务是执行 V&V 计划，收集证据并给出判定。验证（Verification）回答“模型建得对不对”，确认（Validation）回答“模型建得准不准”。验证包括代码审查、单元测试、数值收敛性检查；确认包括与试验数据、高保真模型或专家判断的对比。

以航程仿真为例，验证可检查：相同输入下两次运行结果一致（确定性）、时间步长减半后航程变化 <0.5%（收敛性）、燃油消耗总量与推力积分闭合（守恒性）。确认则用 6 组飞行试验数据计算相对误差，按需求判据判定。若某组误差达 14%，需分析是工况超出边界、试验数据不确定度大，还是模型缺少某物理效应，并记录偏差处理结论。

本阶段交付物包括：测试计划与用例、测试报告（含原始数据、误差计算、判据对比、偏差分析）、可信度评估结论（在何种边界内、以何种置信水平可信）。

运行与维护阶段：可信度是持续状态

模型交付后，使用条件、数据源、硬件平台都可能变化。运行阶段的可信度任务是监控模型输入是否仍在已验证边界内、记录实际使用中的异常与偏差、定期用新试验数据复确认。维护阶段则包括缺陷修复、模型升级、重新验证与版本再确认。

例如当使用方将巡航高度扩展到 6000 m 时，原确认结论不再自动适用，必须补充该高度下的试验数据或高保真模型对比，重新评估误差是否满足 8% 指标。若仅修改代码而未更新文档与追溯矩阵，可信度证据链即断裂。

本阶段交付物包括：运行监控记录、变更申请与影响分析、再确认报告、可信度状态卡（当前版本、适用边界、剩余风险、下次复确认时间）。

阶段间的追溯与反馈

上述六个阶段并非单向流水线。测试阶段发现的偏差可能追溯到概念模型的某条假设，触发假设修正与重新验证；运行阶段的新数据可能要求扩展使用边界，触发再确认。可信度活动的核心不是“每阶段交一份文件”，而是保持一条完整的证据链：需求指标 → 假设记录 → 方程与代码 → 测试数据 → 判定结论 → 运行边界。任一环节缺失或变更未同步，可信度结论即失效。

综上，需求分析定义“可信到什么程度”，概念模型记录“为什么可以这样简化”，详细模型与代码实现保证“假设被正确执行”，测试提供“证据与判定”，运行维护维持“可信状态不退化”。各阶段交付物共同构成可审计、可追溯、可复现的可信度证据体系，而不是彼此孤立的文档集合。