导语：能跑场景，不等于完成效能评估

在仿真系统建设中，“场景能运行、过程有记录、结果能展示”通常只是评估工作的起点。

真正的效能评估还要回答一组更具体的问题：

• 这次评估要支持什么业务决策？
• 被评估的任务目标是什么？
• 系统需要具备哪些能力，才能完成这个任务？
• 用什么指标判断能力是否达到要求？
• 指标需要哪些过程数据和结果数据？
• 结论适用于什么场景，不能外推到什么范围？

如果这些问题没有先定义清楚，仿真很容易变成“运行一次、导出一张表、给出一个分数”。但平台数量、命中次数、平均时延等数值，只有放回明确的任务目标、场景约束和判定规则中，才有实际解释力。

本文讨论的不是一套脱离业务的通用评分公式，而是一种基于 AFSim 仿真系统建立评估闭环的方法：从业务场景出发，把任务目标分解为系统目标和指标，再利用 AFSim 产生的过程数据形成可追溯证据。

一、效能评估的起点不是数据，而是任务目标

很多评估工作从“系统目前能输出什么”开始：先查看日志中有哪些字段，再挑选几个容易统计的数值。这种做法实施起来很快，却容易让数据反过来决定问题。

更合理的路径是从业务目标逐层向下展开：

业务场景：在什么条件下评估
        ↓
任务目标：任务需要完成什么
        ↓
系统目标：系统需要提供什么能力
        ↓
效能指标：用什么可观察量进行判断
        ↓
仿真数据：哪些过程和结果可以作为证据

这几层不能相互替代。

业务场景 规定评估发生的条件，包括参与对象、初始状态、环境条件、约束、任务阶段和终止条件。场景变化后，同一个系统能力可能面对完全不同的评估问题。

任务目标 说明希望通过任务达到什么结果。例如，目标可能是完成指定处置、保护某类对象、维持信息通道、形成持续观测，或者在满足任务约束的同时控制资源消耗。具体表述应由业务方或项目方定义，不能由仿真平台自行推断。

系统目标 把任务目标转化为系统需要提供的能力。例如，系统可能需要在规定条件下形成观测、传递有效信息、触发决策、完成行动，或者保持自身和关键链路的可用状态。

效能指标 才是对系统目标的可观察表达。它需要规定统计对象、时间窗口、成功和失败条件、计算方式、基准或阈值，以及结果的适用边界。

因此，管理者在启动一次仿真评估时，首先应追问的不是“AFSim能导出哪些数据”，而是： 这次运行要帮助我们作出什么判断？

二、从系统目标设计指标体系

指标不是越多越好。一个指标是否有价值，取决于它能否帮助判断任务目标或系统目标。

建议每个指标至少建立以下定义：

指标名称
业务含义
计算公式或判定规则
输入数据
时间窗口
统计口径
比较基准或阈值
适用场景
结果解释边界

例如，“信息传递时延”不能只记录一个平均值，还要说明从哪个事件开始计时，到哪个事件结束；是统计成功送达的消息，还是把失败、超时和未接收消息也纳入；是观察单次过程，还是比较多个运行批次。

可以把指标分为四类：

直接回答任务目标是否达到，例如任务是否完成、约束是否满足、目标状态是否发生预期变化、方案是否达到规定的终止条件。

结果指标最接近业务决策，但也最依赖业务定义。“任务完成”不是一个脱离场景就天然成立的状态，必须绑定任务规则、终止条件和判定口径。

描述任务链路中各环节的表现，例如发现时机、识别过程、信息传递、决策触发、行动响应和效果形成的时序与成功情况。

过程指标的价值在于解释结果。任务没有完成时，可以进一步判断问题出在观测、通信、决策、行动还是其他环节；任务完成时，也可以检查是否依赖了过于理想化的条件。

描述完成任务所付出的代价，例如平台损失、弹药消耗、燃料消耗、时间占用、通信资源使用或其他项目定义的受控资源。

资源指标不能简单理解为“越少越好”。如果减少资源消耗是以任务目标未完成为代价，结论就不能单独成立。资源指标必须和任务结果、约束条件一起解释。

观察方案在不同初始条件、随机性设置、参数扰动和边界条件下是否保持相近表现。

稳健性分析 不能只依赖一次运行。单次仿真可以帮助观察一条过程，但不足以支撑具有统计意义的普遍结论。重复次数、随机种子、参数范围和统计方法应由具体评估任务确定，AFSim相关批处理和随机控制能力需要按目标版本核验【待确认】。

三、AFSim数据能力地图：仿真能提供什么证据

AFSim 的价值之一，是把多个平台、组件、时间和交互过程放到同一个仿真环境中运行，并为后续分析提供过程和结果依据。

但“数据支撑”需要分层理解。对于任何一个数据项，都应先判断它属于哪一种：

直接可观察或记录的数据
        ↓
由多个原始事件计算出的派生指标
        ↓
由业务定义、扩展逻辑或自定义采集补充的数据

下面按评估中常见的数据类别展开。表中“可能的来源形态”用于描述分析方向，不等于目标版本固定的日志字段或文件格式。

这张地图可以帮助团队建立数据需求，但不能替代目标版本的工程核对。实际工作中应为每类数据建立数据字典，至少记录：

• 数据名称和业务含义；
• 生产者和消费者；
• 来源对象、事件或输出机制；
• 单位、坐标系和时间基准；
• 采样时机、有效期和时间戳；
• 缺失、重复、延迟和失败的语义；
• 是原生数据、派生数据，还是自定义采集数据；
• 对应的模型、参数、场景和软件版本。

四、三层数据边界：直接输出、事件计算和业务定义

效能评估中最容易产生误解的地方，是把“AFSim能观察到某个过程”写成“AFSim直接提供某个最终指标”。这两者经常不是一回事。

这类数据通常对应仿真对象、平台状态、组件状态、消息、事件、时间和运行结果。它们可以作为原始证据保存下来。

例如，平台状态变化、某个消息的发送或接收事件、某个处理器被触发、某个交战过程发生，可能属于这一层。但具体是否能够直接输出、以什么名称输出、由哪种机制记录，需要以目标版本资料和工程配置核验为准。

很多有业务价值的指标，并不是仿真对象自动生成的一个字段，而是由多个事件组合计算得到。

例如：

发现时延 = 形成有效观测的时间 - 目标进入评估条件的时间
信息送达时延 = 接收时间 - 发送或产生时间
决策响应时延 = 行为触发时间 - 决策输入到达时间
任务阶段耗时 = 阶段结束时间 - 阶段开始时间
资源消耗 = 初始资源状态 - 终止时资源状态

这些表达式只是方法示意。每个事件的起点、终点、成功定义和异常情况，都需要项目方确认。若起止事件选择不同，指标结果也会不同。

任务完成、有效处置、保护目标、协同质量、方案优选等概念，往往需要业务规则、评估脚本、处理器逻辑或扩展机制来定义和记录。它们不能仅凭平台状态或日志名称自动推断。

因此，评估数据链应当同时保留：原始事件、派生指标、计算规则和最终判定。只有这样，别人才能追问一个结论是如何从仿真过程得到的。

五、用一条抽象任务链连接目标、指标和数据

为了说明方法，可以使用不含真实装备、客户和敏感参数的抽象任务链：

 发现 -> 识别 -> 决策 -> 行动 -> 效果评估

假设业务目标是：在规定场景条件下形成有效处置，同时满足时间和资源约束。这个目标不能直接交给仿真平台，而要继续拆分。

第一步，定义系统目标。

系统需要完成观测、信息传递、状态判断和行动响应。每个环节都要明确输入、输出和成功条件。

第二步，定义过程指标。

可以考虑观察发现时延、有效信息形成时间、信息送达时延、决策响应时延和行动响应结果。这些只是指标候选，不是统一适用于所有项目的正式指标。

第三步，映射AFSim数据。

发现时延
  <- 探测事件、观测或航迹建立时间、场景起始条件
信息送达时延
  <- 消息产生/发送事件、接收事件、链路状态和消息时间
决策响应时延
  <- 输入消息或事件、处理器处理记录、状态转换和指令输出
行动结果
  <- 行动请求、交互过程、目标状态变化和任务终止条件
资源约束
  <- 平台状态、弹药/燃料/通信资源状态和消耗事件

第四步，设置对照关系。

建立基准方案和对照方案，只改变明确的变量，例如某项系统能力、部署条件或通信约束。其他场景、模型、参数和判定规则尽量保持一致，并为每次运行记录版本和配置。

第五步，形成有边界的结论。

结论应回答“在本组场景、模型、参数和统计口径下，对照方案相对于基准方案出现了什么差异”。不能把一次运行中的差异直接扩大为所有场景下的现实系统效能，也不能把仿真结果写成实际作战结果。

六、从仿真运行到评估报告，需要一条证据链

一份可审查的评估结果，至少应能沿着下面的链路回溯：

评估结论
  <- 指标结果与比较方法
      <- 原始事件和状态记录
          <- AFSim模型、配置和运行参数
              <- 场景、任务目标和系统目标

建议将一次评估批次绑定以下信息：

• 场景版本和想定摘要；
• 模型版本、参数集和代码或构建标识；
• 仿真配置、运行时间和随机性设置；
• 基准方案与对照方案的变量差异；
• 原始数据和事件记录；
• 指标公式、脚本或判定规则版本；
• 统计汇总、异常运行和剔除规则；
• 结论、适用范围和未建模因素。

这里的重点不是增加文档数量，而是避免出现“报告中有一个结果，但没人知道它由哪一次运行、哪组参数和哪条规则产生”的情况。

管理者可以把评估交付物分为四组：

场景与模型基线
原始运行证据
指标与统计结果
结论与适用边界

如果只有最后一张结果表，没有原始事件和版本信息，评估就很难复现，也很难判断差异究竟来自系统能力、模型参数、场景条件还是数据处理方式。

七、几种常见的评估误区

大量日志不等于指标体系完整。如果没有任务目标和判定规则，更多数据只会增加筛选成本。

应先确定哪些数据能够证明关键环节，再决定采集粒度和保存方式。

字段通常描述一个状态或事件，指标还需要业务含义、统计口径和解释边界。一个命中事件可以支撑交互过程分析，但不一定单独支撑任务完成结论。

一次运行适合观察过程和发现问题，但不能自动代表不同初始条件下的稳定表现。需要根据问题设计重复运行、对照试验或参数敏感性分析，具体方法应由评估任务确定。

仿真时间可以用于分析事件顺序和模型内部的时间关系，但它不自动等于现实系统的响应能力。现实时间还涉及计算资源、接口链路、部署方式、人员操作和其他未建模因素。

场景是否运行到终止条件，是仿真控制问题；系统是否完成任务，是业务判定问题。两者应分别记录，不能混为同一个“成功”状态。

八、管理者应关注的四个评估问题

从管理角度看，一套效能评估体系是否成熟，可以重点检查四件事。

第一，是否从决策问题出发。

评估是否明确要比较什么方案、支持什么选择，还是只是在积累一批仿真数据。

第二，是否能够解释结果。

结果指标是否有过程指标支撑，能否追踪到发现、通信、决策、行动等关键环节。

第三，是否能够复现和审查。

场景、模型、参数、代码、随机设置、原始事件和计算规则是否绑定在一起。

第四，是否声明了结论边界。

报告是否说明适用场景、模型假设、未建模因素和不能由本次仿真回答的问题。

这四个问题决定了仿真结果是一次性的演示材料，还是可以持续支撑系统工程和方案决策的证据资产。

结语：AFSim提供数据证据，业务定义系统效能

基于 AFSim 搭建仿真系统开展效能评估，关键不在于把所有可见数据都记录下来，而在于建立一条从任务目标到数据证据的闭环：

业务场景
  -> 任务目标
  -> 系统目标
  -> 指标与判定规则
  -> 想定与对照试验
  -> AFSim过程和结果数据
  -> 统计分析与证据追溯
  -> 有边界的决策结论

AFSim可以为平台状态、运动过程、传感器探测、航迹和观测、通信消息、处理器行为、交战过程、时间事件、资源消耗和任务状态提供仿真数据支撑。部分数据可能可以直接观察或记录，部分指标需要从多个事件二次计算，另一些任务结果和评价规则则必须由业务方定义并通过自定义机制补充。

因此，效能评估的责任边界应当保持清楚： AFSim负责提供仿真过程和结果证据，业务目标负责定义评估问题，评估规则负责解释数据，模型验证和统计分析共同限定结论能够成立的范围。

只有把这几层关系连接起来，仿真系统才不只是“能运行的场景集合”，而能够成为支持方案比较、系统改进和工程决策的分析基础。

来源与验证

项目已有内容

• 2026-09-001 《AFSIM 模型体系是怎么样的？》：平台、场景、组件和业务链路的基础背景。
• 2026-09-004 《AFSIM 模型集成：架构体系与组件集成方式》：类型、组件、场景和仿真组织方式的背景。
• 2026-09-005 至 2026-09-009 ：运动、传感器、通信、处理器和武器模型的职责与交互背景。
• 2026-09-010 《仿真的基石是模型：从 AFSIM 看模型精度如何影响仿真结论》：模型适用性、接口语义和验证边界背景。
• 2026-09-011 《通用装备数字模型开发标准：从接口契约到 AFSIM 集成》：模型状态、输入输出、生命周期和验证追溯背景。
• 2026-09-012 《AFSIM 的模型能单独剥离吗？从源码看仿真引擎与模型的耦合边界》：AFSIM运行时和模型上下文关系背景。