仿真控制系统

Weiser2026/8/23大约 6 分钟约 1743 字

公开说明

本文是经过脱敏处理的项目介绍，仅说明通用业务问题、技术思路和个人工作，不涉及具体应用单位、使用场景、系统规模、设备信息、网络参数、协议字段或部署环境。

项目背景

复杂仿真试验通常由多个独立研发的模拟器、数字样机和配套软件共同完成。不同节点的操作系统、启动方式、参数文件、通信接口和工作时序并不完全一致，但在一轮试验中又必须按照统一顺序协同运行。

项目建设前，试验人员需要分别登录各个节点，逐项完成参数准备、软件启动、运行控制、停止和复位。节点增多后，人工操作容易出现顺序不一致、遗漏或误操作；多轮试验还需要持续值守，发生异常时也很难快速判断问题所在的节点和阶段。

因此，项目建设了一套统一的仿真控制系统，把分散操作收敛为可配置、可编排、可追踪的标准流程，并支持人工分阶段控制和多轮任务自动执行。

系统采用“控制端 + 节点代理 + 仿真软件”的分层结构：

任务配置与流程编排
        ↓
统一控制端
        ↓
各节点代理与设备适配层
        ↓
仿真软件、数字样机和配套设备

控制端负责全局任务、阶段编排、命令下发和状态汇总；节点代理负责文件放置、进程启停、协议适配和本机状态反馈。控制端只关注“节点、命令、阶段和状态”，具体平台与设备差异封装在代理和适配层中。

系统同时形成两条相互独立的闭环：

参与设计阶段化流程，将原本的人工操作抽象为可编排步骤，统一管理任务、轮次、节点状态和阶段结果。在此基础上实现人工推进、自动流转、异常终止和多轮任务调度。

基于 Java 和 Netty 开发网络通信及消息处理模块。针对无连接通信可能出现的丢失、乱序和重复问题，在应用层加入请求标识、执行反馈、超时处理、有限重试、重复消息识别和状态确认机制。

发送成功不等于业务完成。系统会等待节点返回明确结果，并结合持续状态上报判断真实进度；只有必要节点全部达到目标状态，控制端才允许流程进入下一阶段。

节点按照请求标识保存处理状态。重复收到正在执行或已经完成的请求时，只返回现有状态或历史结果，不重复执行具有副作用的操作。控制端维护全局状态表，节点代理维护本机状态，两级状态共同保证流程可检测、可重试、可恢复判断。

实现参数文件生成、下发、校验和结果反馈，并统一封装不同操作系统下的软件启动、关闭、复位和状态采集。路径、工作目录和启动方式由配置管理，减少平台差异侵入流程编排逻辑。

参与运行数据采集和分层存储设计。实时控制链路与数据写入链路相互隔离，避免存储短时波动阻塞命令处理；根据实时展示、历史回放和长期分析的不同要求，对数据采用不同处理方式。

参与多节点部署和端到端联调，按照“控制端发送、节点接收、本机执行、结果回传、状态汇总”的完整链路组织验证。对偶发通信、进程启动时序和跨平台控制问题进行日志分析、复现与修复。

项目没有要求所有既有软件重写，也没有把每个节点的差异堆积在控制端，而是通过节点代理和设备适配层隔离差异。新增同类节点以配置为主；新增行为不同的设备则增加适配实现，尽量不修改通用流程。

仿真流程不是数据库事务，无法保证所有外部系统回滚到同一历史状态。系统采用可控失败策略：终止当前轮次、保存失败节点和阶段、执行停止与复位，环境恢复后重新开始完整流程，不虚构不存在的全局事务能力。

网络 I/O 线程只负责快速解码和任务投递，控制处理、数据解析和持久化使用相互隔离的业务队列。队列设置容量、重试和告警，避免数据积压影响关键命令与状态反馈。

项目让我积累了分布式流程控制、网络通信、状态机、幂等处理、跨平台进程控制、异步数据链路以及复杂现场问题排查等工程经验。