本文介绍战斗管理系统决策链的可追溯性。
之前做机器学习项目，从边缘侧数据采集开始，到云端接收加密数据，到数据转换和数据存储，再到机器学习算法，再到部署在容器编排云服务上的后台应用微服务，最后到Web用户界面和BI报表，整个数据链路很长。
测试过程和用户使用时如果出了问题，没人知道到底问题出在哪里。只能连到各个边缘侧和云端的组件自己一行行看日志，根据时间人肉关联数据和消息。整个分析过程极其麻烦，更不要提还有客户的压力。
同样地，在战斗管理系统中，也会存在类似的问题。
空间域感知（SDA）中的空间战斗管理（SBM）系统，需要持续接收传感器输入、历史数据和相关的太空域感知信息，对太空驻留物体（RSO）进行敌意评估，并向太空军的操作员提供响应建议。
然而，战斗管理系统内部多个子系统之间进行着复杂的数据交互，对操作员来说是一个黑箱。操作员只能看到系统最终生成的决策建议，却看不到生成决策建议的端到端的决策追溯链。
空间战斗管理系统完整的算法处理过程
如果某个中间过程出现错误导致错误的决策建议，既无法审计，也无法回溯，更无法精确定位错误源头。
在人工智能日益主导军事决策的时代，黑箱的算法处理过程带来的不信任感，成为战斗管理系统建立人机信任的最大障碍：
操作员：不愿意将决策权交给无法理解的机器；
指挥官：无法向政治领导人解释为何系统建议采取某种行动；
审计员：无法在事后调查中重建决策的过程。
在太空这个新兴作战域，态势感知的速度和质量决定胜负。而可追溯性确保了这种感知不仅是快速的，更是可理解、可验证、可改进的。
当太空作战军官评估一个太空威胁时，作为轨道分析专家，他们不能盲目信任算法处理过程；他们需要追溯数据处理的整个过程，审查计算逻辑的整个链条，做出知情的判断和决策。
为此，美国太空军开发的空间战斗管理决策链的可追溯性框架（详见本文参考资料[1]），将供应链的可追溯性框架应用到太空作战领域，通过消息总线捕获完整的消息血缘，通过图数据库和可视化界面呈现端到端的决策链条，从而将黑箱决策转化为透明的、可追溯的决策。
这种可追溯性不仅是技术特性，更是战斗管理系统战斗力的力量倍增器：
增强了操作员对战斗管理系统的信任，使他们更愿意在关键时刻依赖系统给出的决策建议；
加速了故障诊断过程，减少了虚警导致的资源浪费；
支持持续学习，使战斗管理系统能够从每次决策中持续进化；
建立了问责机制，确保在出现错误时能够定位责任、吸取教训。
这项战斗管理系统决策链的可追溯性研究，虽然是针对空间战斗管理的，但是由于任何战斗管理系统都需要靠追溯性，所以其设计理念，同样适用于其他作战领域甚至联合全域的复杂决策系统：
空战场战斗管理系统决策链的可追溯性
联合全域指控决策链的可追溯性
F2T2EA杀伤链/杀伤网的可追溯性
反无人机cUAS杀伤链的可追溯性
ABMS 指控过程可追溯性
晶格（Lattice）指控系统通用数据空间数据处理过程的可追溯性
Agentic AI 调用链的可追溯性
网络杀伤链的可追溯性
数字工程从数据/模型到决策的可追溯性
MBSE和MDAO的可追溯性
人工智能赋能系统的调用流程的可追溯性
无人自主系统多智能体微服务调用的可追溯性
多元信息融合的可追溯性
情报分析过程的可追溯性
后勤规划过程的可追溯性
后勤保障数字孪生的可追溯性
......
与本文研究相关的阅读建议：
上述参考资料，如果有需要的，可以扫描下面的二维码加入圈子后下载。
一、战斗管理系统的决策链追溯
1.1 供应链追溯
为了解决太空军的空间战斗管理系统决策链的可追溯性问题，这项研究引入了一个看似不相关领域的解决方案：供应链追溯（详见本文附录A和附录B）。
在制造业中，如果一家关键基础设施采购商发现某个芯片存在缺陷，他们需要能迅速追踪这颗芯片的完整旅程——从最终组装厂回溯到晶圆制造商。
即通过记录商品在供应链中的流动（正向）和追溯（反向），实现了对产品血缘、谱系和透明度的全面掌控。
供应链的可追溯性的原理
1.2 战斗管理系统决策链追溯
战斗管理系统中的数据流，与制造业供应链惊人地相似。
在战斗管理系统中，数据如同零部件，算法处理过程如同装配工序，最终生成的决策建议如同成品。如果制造商能够追踪一个物理产品的完整旅程，太空作战系统也同样可以追踪一个威胁判定决策的端到端过程。
也就是说，我们可以用类似供应链追溯的方法，实现数据与决策的可追溯性。
这种可追溯性指的是对数据生命周期的全面、可审计的文档记录，涵盖数据的起源、转换、移动和使用，以及使用这些数据做出决策的逻辑和影响因素。
1.3 战斗管理系统决策链追溯的价值
这种方法创建了一条可验证的证据链，支持重建数据来源并证明战斗管理系统内各个算法处理过程是否正确。
在涉及多方利益相关者和自动化决策流程的复杂的战斗管理系统中，可追溯性建立起问责机制，确保数据完整性，支持调试和优化，并满足监管合规要求。
这种可追溯性为持续改进战斗管理系统奠定了基础——通过识别数据处理中的潜在偏见、低效环节和决策流程中的改进空间。
具体来说，战斗管理系统决策链可追溯性框架的三大价值：
错误诊断：如果发现了一个可疑或错误的新的空间物体，操作员可以迅速追溯问题发生的节点。也许是使用了错误的数据源，设许是某个算法模型产生了可疑的输出，也许是参数配置出现了偏差。可追溯性将故障定位时间从数小时缩短到数分钟。
持续改进：通过分析可追溯数据，算法工程师和数据工程师能够理解哪些数据质量和模型精度问题影响了最终决策。这种洞察驱动模型和数据的持续优化，最终产生更可靠的作战决策结果。
审计能力：系统工程师和审计人员可以逆向审计决策路径，验证系统是否做出了正确决策。他们可以检查输入数据、审查各个算法模型的贡献，确认没有遗漏关键信息。
二、战斗管理系统可追溯系统
2.1 战斗管理系统架构
下图为太空军的空间域感知（SDA）的空间战斗管理（SBM）系统的六大核心子系统及其数据流关系。
空间域感知（SDA）战斗管理系统架构
战斗管理系统接收到观测数据后，六个功能模块分工协作，最终生成响应决策建议：
子系统1（目标建模）：维护卫星主数据库，聚合已知卫星的尺寸、重量、射频特征等先验信息，为后续分析提供基准数据。
子系统2（状态估计）：模块执行精密定轨，通过初始轨道确定（IOD）、未关联轨迹处理（UCT）和校准，计算太空资产的位置、速度与轨道参数。
子系统3（指挥控制）：负责任务规划，调度望远镜执行搜索、重新捕获等观测任务。
子系统4（CCDM评估）：监测异常行为，分析卫星机动模式、轨道退化趋势，并检测解体事件。
子系统5（敌意评估）：进行威胁研判，综合评估目标的能力、意图与作战环境，判定敌我属性。
子系统6（响应建议）：生成行动方案，向操作员推荐规避、缓解或归因等应对措施。
2.2 战斗管理系统决策链可追溯性系统架构
下图为支撑数据与决策可追溯性的模块化的技术架构。
消息总线：作为数据入口，实时捕获BMS各算法间的交互消息与元数据；
适配器：将流式数据转换并持久化至图数据库；
图数据库：消息的存储和查询引擎，利用图结构高效存储复杂的父子关系与血缘链条；
可追溯性算法：执行图遍历与路径分析，从原始元数据中重建决策逻辑，回答用户界面发起的查询；
决策追溯链用户界面：通过前端可视化界面呈现决策追溯链条，支持操作员交互式分析。
数据流程：消息总线→适配器→图数据库→算法分析→用户界面。这种分层解耦设计确保新的算法处理过程仅需接入消息总线即可自动获得追溯能力，同时支持事后审计、实时调试等多场景需求，将分布式计算黑箱转化为可查询、可验证的知识图谱。
三、战斗管理系统可追溯系统的关键技术
3.1 消息总线
传统架构中，不同算法之间通过直接的API调用进行端到端通信。这种点对点连接如同电话线——A直接打给B，B直接打给C，但旁观的D无从得知通话内容。
当系统规模扩大到数十个算法、数百个数据流时，这种架构不仅导致意大利面条式的依赖关系，更致命的是彻底丧失了全局可见性。
解决方案就是消息总线。
消息总线充当系统的中央通信框架。不同算法不再直接对话，而是将消息发布到总线上。每个消息遵循严格定义的消息schema（模式），捕获关于数据、其来源以及生成数据的处理过程的关键信息。
下图为简化的数据与算法处理过程的交互流程，说明消息总线如何充当中央通信枢纽。
图中以颜色区分三类要素：绿色数据方框代表轨迹、观测等数据元素；红色过程方框代表轨道确定、解体筛查等算法；蓝色目标方框代表"发现新物体"等决策结果。
整个流程始于外部星历、状态向量和跟踪轨迹数据输入，经解体筛查、轨道确定与任务选择生成传感器任务请求。传感器返回观测数据后，经航迹生成器处理生成候选轨迹，再分流至轨道确定方法与UCT处理器。数据经传播器、评分服务、去重服务等多级处理，最终与已知物体数据库比对，输出发现新物体的结论。
上图中的所有数据交换、算法处理过程调用和状态变更，均通过消息总线完成，而不是点对点的直连。这种架构使每次交互都被捕获为带血缘元数据的消息，从而支持从最终结论逆向追溯至原始传感器请求，构建完整的决策追溯链。
3.2 消息头 Schema
要实现可追溯性，需要设计支持可追溯性的消息头。
系统内的每个组件之间通过消息收发数据时，都必须按照这个消息头的schema格式记录输入、输出和元数据信息。这样一来，随着系统运行，持续收集所有消息的消息头信息，就可以形成所有数据转换和决策的时序日志。
消息头通过schema标准化带来了互操作性。来自不同供应商、使用不同编程语言实现的算法，只要遵循这个消息schema格式，就能无缝集成到可追溯性框架中。
比如，一个用Python编写的轨道确定算法生成的消息，可以被用C++编写的威胁评估算法消费，而图数据库能够无缝追踪这个跨语言的因果关系链。
下面为校准消息的消息头的例子，它包含如下关键字段：
消息ID：唯一标识符（UUID格式），确保全局唯一性
消息时间：ISO 8601格式的时间戳，精确到微秒
消息版本：消息schema版本，支持向后兼容
子系统：标识消息来源子系统（如ss0代表传感器子系统）
数据提供者：生成数据的组织
数据类型：数据类型层次结构（如ss0.data.eoobserv.calibrated表示子系统0的地球观测数据的校准版本）
数据版本：数据格式的特定版本
数据载荷：实际载荷内容，包含观测坐标、时间、参考数据等
消息哈希值：消息的加密哈希，确保完整性
可追溯性：血缘关系部分，分内部和外部血缘。内部血缘指通过消息总线在战斗管理系统内流动的数据；外部血缘则代表系统边界外的数据。
3.3 消息血缘
有了消息头，基于下面两个简单的规则，就可以构建消息之间的血缘关系。
一：捕获输入输出。对于系统中的每次算法处理过程，系统会通过消息总线捕获其输入和输出。
二：关联父子过程。不同算法处理过程之间，基于输出-输入连接关系相互关联。当一个子过程消费另一个父过程的输出时，系统记录下这种父子血缘关系。
构建消息血缘的两条规则
当需要追溯时，任何决策输出都能追踪到其直接父节点，而父节点又能追溯到它们的父节点，如此构建起完整的可追溯性链条。
基于这两条简单规则——记录每个过程的输入输出、建立算法处理过程间的调用关系——使系统能够建模包含数百个算法和复杂数据交换的庞大系统。
下图展示了UCT（未关联轨迹）处理算法过程的实际数据流示例（蓝框部分）。
UTC算法消费观测数据和轨迹数据，生成四个不同的输出。通过底层的消息总线上捕获的消息头schema，系统可收集关于未关联轨迹处理（UCT）算法处理过程的每个输入和输出的元数据。
3.4 消息存储
捕获和关联消息只是第一步，还需要存储、查询消息。
传统关系型数据库擅长处理表格数据，但不适合表示"消息A衍生出消息B，消息B又被算法C消费生成消息D"这种复杂网络关系。
图数据库天然适合表示节点（数据、算法）和边（衍生、消费关系），能够高效地执行深度遍历查询——例如"找出所有直接或间接影响这个威胁评估的原始传感器数据"。
因此，这项研究选择图数据库作为所有消息的存储和查询引擎。
3.5 决策追溯链可视化用户界面
基于图数据库中存储的所有消息，就可以开发可视化界面，让操作员可以分析整个决策追溯链。
下图为数据到决策的完整的追溯链的用户界面，将复杂的数据和算法处理流程转化为直观的可视化决策链。
用户界面采用有向图形式，不同颜色节点代表不同子系统（黑色为子系统0，深蓝色为子系统1，橙色为最终生成的建议），连线表示数据流。当用户选择某个节点时，右侧面板展示详细的消息内容，包括消息ID、时间戳、数据类型、数据提供方及完整的可追溯性元数据（内部与外部父资源）。界面支持从特定警报（如潜在威胁）出发，逐步回溯揭示评估过程中涉及的数据、决策和算法流程。
这个可视化界面，可以让操作员交互式地探索整个端到端的决策链——操作员可以像浏览族谱的家族树一样，点击任意决策节点，即可查看其祖先（输入数据和上游过程）和后代（输出数据和后续过程）。从而将原本黑箱的数据转换过程转化为可审查、可验证的透明链条，最终增强对系统建议的信任并支持快速故障诊断。
当系统标记一个潜在威胁时，这个可视化界面能够为操作员完整展示整个评估过程：从传感器检测到卫星发射，到轨道确定，到威胁评分，最终触发警报。每个步骤都附带置信度分数、使用的算法版本、参考的外部数据源等元数据。
这种透明性和可解释性，不仅增强了操作员的信任，还赋予了他们分析问题的能力。当系统建议规避某个目标时，操作员可以迅速验证：这个建议是基于最新的轨道数据吗？使用的轨道传播模型考虑了大西洋上空的太阳活动吗？有没有可能将友好的商业卫星误判为敌对目标？
四、案例介绍：追踪卫星解体事件
下面介绍一个典型场景：卫星解体事件后的新目标发现。
当一颗卫星发生爆炸或碰撞解体时，会产生数百乃至数千个碎片。空间域感知系统的战斗管理系统需要迅速识别这些新物体，评估威胁，并建议操作员是否采取规避措施。
在这个过程中，数据经历了复杂的处理链条：从原始传感器观测，到轨迹形成，到轨道确定（OD），到解体目标的筛查过滤，再到最终的新物体发现声明。
在没有可追溯性的战斗管理系统中，当操作员看到发现新物体的警报时，他无法回答关键问题：这个新物体来自哪次解体事件？哪些原始观测数据支持这个结论？哪些算法参与了识别？有没有可能是虚警？
而有了可追溯性，就可以可视化完整的数据与算法流程。外部数据（星历、状态向量、轨迹）流入系统，经过解体目标筛查、轨道确定、任务选择等环节，触发传感器任务请求。传感器返回观测数据，经过轨迹形成器、UCT处理器、评分服务、去重服务，最终输出发现新物体的结论。
下图展示了可追溯性框架如何逆向追踪这个结论，将新发现的太空物体回溯至原始的解体事件。从新发现物体节点出发（红色箭头指向的圆圈），系统回溯经过多个子系统组件（橙色、黄色、蓝色圆圈），穿过一系列消息（绿色圆圈），最终追溯到原始的任务请求——正是这个请求触发了解体调查。
本图自上而下分为四层：顶层灰色圆圈代表外部资源（如太空军UDL统一数据湖中的已知太空物体数据库）；第二层绿色圆圈代表系统生成的消息，每个消息包含唯一ID和血缘元数据；第三层橙色圆圈代表子系统2的组件（状态估计，如轨道确定、UTC、校准）；底层黄色和蓝色圆圈分别代表子系统1（目标建模）和子系统3（指控）。红色箭头指示追溯路径：从新发现物体节点出发，最终回溯到解体筛查算法和原始任务分派请求。这个可视化的链路说明，通过捕获消息间的父子关系，系统能够重建完整的决策谱系，操作员就可以确认新发现的物体确实源于特定解体事件，而不是传感器虚警或算法误判。
五、未来发展
当前，这个研究正推进三个关键方向的扩展工作。
各种算法全面接入消息总线
将所有算法接入到消息总线。随着每个算法的集成，自动数据捕获立即生效。
这不仅支持事后行为分析，还为未来系统优化提供宝贵洞察。
图数据库优化
优化图数据库，存储海量消息节点和它们之间的关系，并支持更复杂的查询模式，如"找出过去24小时内，所有因特定传感器校准错误导致的误判威胁"。
用户界面优化
除了现有的节点链接图，计划增加时间轴视图（按时间顺序展示决策过程）、对比视图（并排比较两次决策的数据差异）和预测视图（基于历史数据预测潜在的错误传播路径）。
附录A：供应链可追溯性框架的数据架构
A1. 可追溯性记录的通用结构
首先需要定义可追溯性记录的通用结构。每个记录包含固定数据元素和可变数据块。固定元素确保跨系统的一致性，而可变块可以支持行业特定扩展。
每个可追溯性记录必须包含以下核心元素：
记录标识符：全局唯一标识符（UUID），确保每个事件条目在生态系统内可唯一识别。
事件时间戳：事件发生的时间戳和记录，被正式写入受信任仓库的时间戳。这两个时间戳的区分，对于事后分析和责任认定至关重要。
组织标识符：生成事件的组织唯一标识符。重要的是，这些标识符应代表公开可识别的商业实体，不应包含个人身份信息（PII）。
被追踪实体标识符：分配给产品实例的唯一标识符（如产品ID、组件ID），形成网络-物理链接的基础。
追溯链接：指向先前相关记录的引用，建立供应链事件的谱系关系。
A2. 五大事件类型：从原材料到部署
定义五种核心的追溯记录的事件类型：
制造记录：捕获创建新产品或组件的事件。这通常适用于从原材料（无先前追溯记录）生产产品的场景。记录中包含产品ID、制造类型ID，以及可能关联的机器ID、材料批次号、环境参数（如温度、压力）等关键值对数据。
组装记录：表示将多个先前追踪的组件组合成新产品的过程。与制造记录不同，组装记录必须引用输入组件的先前事件（制造、组装或接收记录）。这确保了组装体的连续性，能够追溯到每个零部件的来源。
运输记录：记录产品或组件在不同责任方之间的转移。它链接到制造或组装记录，显示"运了什么"，并包含承运商名称、追踪号码、运输方式（如冷链卡车、空运）等信息。
接收记录：捕获接收货物的事件，与对应的运输记录形成配对。接收事件发生在产品的消费地——即产品将进入运营环境或进一步制造的地方。记录中可能包含检验结果（接受/拒绝）、温度日志、交付条件等数据。
部署记录：记录产品在运营环境中的安装或激活。这标志着产品从供应链进入使用阶段。部署记录通常链接到接收记录，并包含部署位置、配置ID、安全合规检查结果等信息。
这五种事件类型形成了一个完整的闭环：制造和组装创造产品，运输和接收移动产品，部署则标志着产品进入服务状态。
A3. 链接机制：构建不可篡改的链条
每个记录通过加密验证的引用连接到其前身，形成可追溯性链。
链接包含三个关键数据：
资源链接：指向生态系统服务的URI/URL，用于检索数据。
参数块：包含记录ID和访问哈希的结构化参数集。访问哈希基于记录创建时的字段（如时间戳）生成，用于验证访问权限而不暴露敏感信息。
资源哈希：完整记录的密码学哈希值（如SHA3-256），用于验证返回数据的完整性。
这种设计确保了数据完整性。当利益相关者检索记录时，可以重新计算哈希值并与存储的哈希值比较。任何篡改都会导致哈希不匹配，从而立即暴露。
附录B：供应链可追溯性框架的技术实现
B1. 物体的唯一数字身份证
每个被追踪的物品，都必须分配一个持久且唯一的标识符。
这个标识符可以是多种形式：序列号、数字孪生ID、批次标识符或行业标准追踪号。关键要求是唯一性——至少在适用生态系统内唯一。
例如，一个芯片上的激光刻印序列号（物理部分）与数据库中的产品ID（数字部分）关联。当制造商创建制造记录时，他们同时建立了这个链接。后续所有事件（运输、组装、部署）都通过这个ID引用该物理物品。
B2. 补充链接：扩展追溯的维度
除了核心的追溯链接，还可以加上补充链接。
这些非强制性的引用链接指向外部数据源，如合规报告、测试结果、质量检验报告、操作日志或工程模型。
补充链接遵循与追溯链接类似的结构，但指向存储在受信任仓库之外的数据。这可以让企业关联大量支持文档，而不必将所有数据都存储在核心的追溯链中。
然而，追溯记录本身必须包含支持谱系和来源验证所需的所有基本数据，独立于任何补充链接。这确保了即使外部数据不可用，核心的追溯目标仍然可以实现。
B3. 序列化与确定性哈希
为了确保密码学验证的可靠性，还需要依赖于确定性序列化——将结构化数据一致地编码为规范形式的过程。这意味着相同的输入，必须始终产生相同的字节级输出。
这个供应链可追溯性框架并不强制特定的序列化技术，但鼓励采用支持确定性序列化的格式，如JSON、XML（规范模式）或CBOR（简明二进制对象表示法）。
关键在于，如果检索到的记录编码与计算哈希时使用的版本不同，验证将失败。
上述参考资料，如果有需要的，可以扫描下面的二维码加入圈子后下载。
