1. 前言为什么测控软件每换一个型号就要重写一遍前阵子参与某型运载火箭的地面测发控系统论证会议室里聊到测试软件架构时话题又绕回那个老问题为什么每次换型号测控软件都要推倒重来也是在那次论证里我系统性评估了基于ATMLAutomatic Test Markup Language自动测试标记语言标准的建设思路。简单说ATML用一套统一的XML数据模型把测试需求、被测对象、仪器能力、测试配置全部标准化让测试软件从为某个型号定制变成按数据契约解释执行。这篇文章把我认为最有参考价值的方案设计、建模步骤和踩坑经验整理出来给正在被测控软件复用问题困扰的系统设计师、测试工程师以及想了解ATML到底怎么落地到航天测控场景的同行做个参考。1.1 点对点开发模式的老账传统测控软件的开发基本都是点对点模式测试需求直接变成代码逻辑被测对象信息散落在各种表格和文档里仪器控制逻辑和测试业务逻辑揉在同一个模块里测试结果各存各的格式。单看某一个子系统似乎没什么问题但放到全箭测试的维度看问题就很明显了。需求变更的传导链路极长。总装测试流程里加一个伺服机构频率特性检查从流程文档、需求表、代码逻辑、数据判读程序到报表模板全链路都要跟着动一次变更动辄以月计。测试资源无法跨工位共享每个测试间都是一套研制软件加一柜子专用设备的绑定关系设备挪到别的工位软件就不认了。数据互操作基本靠人肉转换某个分系统输出的测试记录另一个团队接手时得先花两周搞清楚字段语义。我真正意识到问题严重是有一次射前功能检查中两个分系统对同一个压力传感器的输出格式理解不一致数据对接时才发现双方文档里量纲换算公式是两套写法。这种问题靠开会解决不了得靠标准约束。1.2 ATML解决的问题恰好就是这些ATML是IEEE 1671标准族定义的一套基于XML的测试信息描述规范核心思路是把测试信息从测试执行中剥离出来测试需求、被测对象、仪器能力、适配关系、测试配置全部用统一的XML Schema描述由解释引擎在运行时去执行。这个思路在航空机载设备的自动测试领域已经验证了二十年从一开始就是为了解决测试程序不可移植、测试资源不可复用这两个老大难。把同样的思路引入运载火箭测控领域价值是明确的。第一型号之间的测试资产可以真正复用换型号相当于换一组被测对象模型和测试描述执行引擎和仪器资源层不用重写。第二测试程序与具体仪器解耦测试描述关心的是给这个传感器加多少伏激励、期望返回什么量纲的响应而不是调用哪家板卡驱动仪器更换只需改配置描述。第三全链条数据口径统一从测试需求、测试程序到测试结果全部基于同一套数据字典信号定义不一致这类问题在建模阶段就会被发现并消灭。1.3 这篇文章写给谁这篇方案面向两类读者。一类是参与测控系统总体设计、正被型号复用问题困扰的系统工程师和软件架构师这篇文章能提供一套可以直接参考的分层架构和落地路径另一类是刚接触ATML、想搞清楚这套标准到底值不值得投入的测试工程师我会尽量把标准术语翻译成工程语言同时保留能落到实处的细节。下面的内容先从标准族本身的拆解开始。2. ATML标准族拆解一份XML描述如何贯通测控全链路2.1 IEEE 1671主干与分支ATML不是一个孤立的XML文件而是一族配套的Schema官方定位是测试信息集成框架。套用到运载火箭测控场景最常用的几个分支可以整理成下面这张表标准/分支描述内容在测控场景中的对应物IEEE 1671 主框架公共约束、命名空间、扩展机制组织统一的元数据框架IEEE 1671.1 测试描述测试需求、测试步骤、判定条件各分系统测试流程、射前功能检查项目IEEE 1671.2 仪器描述仪器能力、量程、精度、触发特性数据采集器、信号源、总线通讯卡、电源IEEE 1671.3 UUT描述被测对象端口、信号特性箭上单机、传感器、变换器、箭上计算机IEEE 1671.4 测试配置一次具体测试的资源绑定关系工位、适配器、测试工序的组合IEEE 1671.5 适配器描述适配器内的通路与转换关系电缆网、转接盒、信号分配盒IEEE 1671.6 测试台描述测试台的仪器清单与物理结构测控间机柜、车载测控站、发控台理解这套标准族最好的方式是把它想成设备清单加装配关系UUT描述是被测设备长什么样仪器描述是测试设备能干什么适配器描述是两者怎么连测试配置是这一场测试实际用了哪些东西测试描述则是这场测试按什么顺序干、每步怎么判读。2.2 IEEE 1641信号定义最值钱的部分如果说IEEE 1671解决的是格式统一那么IEEE 1641解决的则是语义统一。1641标准定义了一套与具体仪器无关的信号描述语言包含基本信号组件BSC、测试信号框架TSF和标准信号库。简单讲它把给设备加一个5V直流激励产生一个脉宽2ms的下降沿脉冲这类动作定义成了独立的、可组合的信号组件。为什么信号级抽象这么关键因为测控系统里大量的测试动作本质上就是施加某种信号、测量某种信号。用1641描述信号至少有四个好处同一信号描述可以映射到不同厂家的仪器描述里不含通道号、量程代码这些私有信息信号组合可以封装复用比如采集热电阻并换算成温度可以封装成一个TSF多个分系统共用测试需求能做版本评审XML是文本配置管理工具直接能对比差异从需求到结果全程可追溯信号定义贯穿测试描述与结果数据。对运载火箭这种高压、大电流、高频振动、总线协议复杂的场景1641的标准信号库肯定有覆盖不全的地方但标准本身预留了TSF扩展机制这个问题完全可以解决具体怎么做放到第五部分再讲。2.3 各描述模型在一次射前功能检查中如何流转拿一次典型的射前功能检查举例。检查项目是伺服机构零位与极性检查大致流程是给伺服控制器施加模拟指令信号采集反馈电位器输出确认极性正确、零位在允许范围。按照ATML体系这项检查会这样组织数据UUT描述里定义伺服控制器和电位器的端口类型、电气接口特性测试描述里用1641信号组件定义直流模拟指令和电压测量并写明上下限判定条件仪器描述里登记现场机柜里信号源板卡和采集板卡的能力范围测试配置里把UUT端口、适配器通路、仪器通道绑定到同一张逻辑图上。执行引擎拿到这组XML后只做一件事把测试描述中的信号需求解析成对具体仪器通道的操作序列。测试工程师写的是这是什么测试、合格标准是什么而不是调用哪个库函数、设置哪个寄存器。这个差别看起来只是形式变化实际上决定了整个系统的可维护性。3. 运载火箭测控系统的ATML分层架构设计3.1 总体分层从被测对象到执行引擎参考ATML标准的分层逻辑和国内测控系统的工程现状我建议新研系统放弃传统的硬件-驱动-应用三层结构改成五层数据与模型层、解析与映射层、执行控制层、服务接口层、应用展示层。数据与模型层就是ATML的XML模型库包含UUT库、仪器库、适配器库、测试流程库和配置库。解析与映射层负责XML Schema绑定解析以及信号到资源的映射也就是把1641信号翻译成具体的仪器操作序列。执行控制层管测试序列调度、并发控制、异常处理和中断响应。服务接口层向上提供结果查询、状态订阅、命令下发接口。应用展示层则是测试监控界面、判读曲线、报表生成这些面向操作人员的功能。这么分层的关键理由是前两层属于描述世界后三层属于执行世界。测试工程师改的是前两层的XML模型软件工程师维护的是后三层的引擎两边靠稳定的Schema契约协作互不干扰。传统模式下改一个需求要动一堆代码的问题在这里被结构性地消解了。3.2 面向发射流程的测试需求建模运载火箭测试流程本身是分层的ATML模型也必须跟着分层建不能试图用一个庞大的测试描述从头写到尾。按照实际研制流程我建议分成四个层次来建模测试层级覆盖范围ATML建模方式单元级单机设备传感器、变换器、阀门、驱动器每个单机一份UUT描述加对应测试描述分系统级动力、电气、控制、测量等分系统多UUT实例加适配器连接关系加综合测试描述总装级全箭匹配测试、干扰检查全箭UUT模型加跨分系统测试流程射前级加注后检查、射前功能检查、发射程序精细化测试描述带严格时序约束这里有一个建模粒度问题值得单独说。总装级和射前级的测试描述不宜直接复制单元级的所有步骤应该采用引用加覆盖的机制射前级引用单元级定义好的信号步骤但覆盖判定界限、精简测试时间、增加环境约束。XML的层次化结构天然支持这种引用与重定义前提是工具链要跟得上依赖配置管理来约束不能靠测试人员手动拷贝否则版本一致性迟早出问题。3.3 仪器与适配层的资源抽象测控现场的设备种类非常杂多功能数据采集器、任意波形发生器、直流电源、串口卡、1553B总线卡、CAN总线卡、继电器分配盒。ATML的仪器描述层要求把每类设备抽象成能力集合而不是产品型号集合。举个例子。某型号用的是A厂的数据采集器另一个型号用B厂的产品两者量程、采样率、通道数各不相同。在仪器描述里A和B都写成支持0到正负10V模拟输入、采样率不低于100kS/s、通道数不少于32这样的能力描述。测试描述层只认这个能力描述执行映射时引擎再根据测试台配置把能力需求分配到具体通道。B厂设备到场后只需新增一份仪器描述和对应的IO驱动所有引用该能力的测试描述都不用改。这个抽象的代价是前期建模工作量不小尤其是要把各家设备的异构能力统一到同一套能力词汇上需要逐项校准。但收益会在后续每一个型号上持续放大属于典型的先慢后快。4. 构建方案落地路径从信号字典到可执行程序4.1 第一步先立信号字典再谈建模我见过不止一个项目一上来就设计XML Schema结果做到一半发现同一个量纲在不同分系统有不同叫法压力信号有时指电桥输出毫伏值有时指换算后的兆帕值。所以落地第一步不是写Schema而是建一份全系统的信号字典。做法是把全箭各分系统的测量量、激励量、总线报文、开关量全部梳理出来每个信号定义一个四元组信号名全局唯一比如某增压压力的编码、物理含义与量纲、电气表达形式例如电桥输出0到20mV对应0到10MPa、标准信号类型映射对应IEEE 1641的哪个信号组件。这份字典是后续所有ATML模型的地基。我的建议是在立项初期就组织各分系统设计师和测试人员开集中梳理会宁可多花几周也要把口径统一掉。字典建好后必须入配置管理库任何修改走变更审查流程不能谁想改就改。4.2 第二步按先UUT、后测试描述的顺序建模建完信号字典先做UUT描述再做测试描述顺序不能反因为测试描述要引用UUT上的端口和信号UUT模型不牢测试描述必然返工。UUT建模重点定义三部分内容端口列表供电、激励、测量、总线、旁路、端口电气特性电平、阻抗、速率、可测信号列表关联到信号字典条目。箭上单机的UUT模型建议按设备类型做模板比如压力传感器模板、伺服机构模板、温度传感器模板同类型设备复制模板改参数即可工作量会明显下降。测试描述建模从流程切入先列工序树再为每个工序配测试步骤和判据。射前功能检查的工序树可能有几百个节点每个节点的判据要落到具体信号和界限值。这个阶段最容易犯的错是过度细化把底层操作比如切换第三路继电器设置板卡量程档位也写进测试描述这会彻底毁掉描述的可移植性。正确的做法是底层操作交给适配器描述和测试台配置去表达测试描述只表达测什么、怎么判。4.3 第三步测试台配置与执行引擎开发模型库建好后开发量集中在执行引擎。引擎的核心模块包括XML绑定解析器、信号到资源映射器、序列执行器、判读与异常处理器。信号到资源映射器的逻辑是读取测试描述中的1641信号需求遍历当前测试台配置中的仪器能力描述找到满足能力且通道空闲的资源生成具体仪器操作序列。这个模块是描述世界和执行世界的接缝最容易出bug。我的建议是加一个能力匹配预检报告功能每次测试前先跑一遍预检把匹配不上的信号需求全部列出来按严重程度分级提示。这个功能帮我们避免了无数次程序跑到一半才发现仪器能力不足的事故。执行控制层要处理两个航天场景特有的问题。第一是时间同步分布式测试间之间必须统一时基建议直接引入PTP或IRIG-B码同步XML模型里给每个测试步增加时间戳来源属性。第二是紧急中断射前流程一旦出现参数越界或异响要在毫秒级中止当前序列并切换到预案步骤引擎的异常处理必须设计成事件驱动不能靠顺序轮询。4.4 第四步结果数据闭环测试结果要回到标准化格式里形成闭环。ATML配套的结果数据格式可以参照IEEE 1636.1来设计但航天场景需要做必要的裁剪。结果数据必须携带信号字典编码和UUT实例ID这是后续数据挖掘的基础没有这个标识所有结果都是死数据。原始波形与特征值分开存特征值进关系型数据库便于判读原始波形按批次归档到对象存储。判读结论要留证据链哪条界限、哪个算法、哪个版本的判读程序得出的结论全部记录在案。我见过一些系统的结果数据只存一个合格/不合格结论出了质量问题根本追溯不到原始数据这是很要命的ATML体系下不应该再出现这种情况。5. 实际推进中踩过的坑5.1 标准版本漂移与Schema锁定第一个坑来自标准本身。IEEE 1671和1641都有修订版本不同版本的XSD结构不兼容有的供应商实现还停留在老版本。我们遇到过分包团队按早期草案开发了一批测试描述与我们主系统按新版生成的Schema绑定解析直接崩溃。最后我们统一做了三件事主框架锁定Schema版本并做基线所有对外接口强制校验版本号在组织规范里写明只准用标准扩展点扩展、不许改标准Schema拆出一个合规检查工具模型入库前自动扫描不兼容元素。这个坑要尽早处理越拖到后面改造成本越高。5.2 动态信号建模与解析性能问题第二个坑在性能。射前要做振动与冲击信号检查这类动态信号用1641标准库里的基本组件很难完整表达我们通过标准预留的扩展机制新增了几个TSF组件比如带窗函数的功率谱密度测量信号、时域冲击响应峰值提取信号。扩展本身不复杂复杂的是性能和解析器适配。实测遇到两个问题。一个是大规模测试描述的XML解析内存占用过高两千多个测试步的文件解析后接近1GB内存另一个是自定义TSF在映射器里的匹配计算太慢一次预检要跑十几秒。解决办法是解析器改为延迟绑定加缓存只加载当前测试段映射器对每个TSF生成预编译的能力匹配规则避免运行时暴力遍历。优化后预检时间降到了两秒以内。5.3 老系统数据迁移与语义映射第三个坑是兼容存量系统。现役工位有大量历史测试数据存在私有格式里这些数据价值很高不能扔。我们的做法是写了一套迁移工具链把旧数据按信号字典映射到标准结果结构。工作比想象中磨人难点不在解析二进制而在语义映射老数据的通道编号和信号名对应关系散落在多个版本的文档里必须靠人工确认。给后来者的建议是迁移前先做一份信号名、通道号、量纲、换算公式对照清单让熟悉老系统的资深工程师逐项确认宁可前期多花两周不要边迁边猜否则迁移完的数据可信度就是个问号。5.4 标准治理最大的坑其实是组织级的最后这个坑也是最大的坑不在技术而在组织。ATML的标准化收益有个前提全系统必须共享一套数据字典和建模规范。但实际研制体系里各分系统团队长期各自为战让他们统一命名规范、统一建模粒度阻力非常大。我们的应对是成立一个跨团队的专项建模组而不是等总体单位下发文件。这个组的职责包括制定信号字典与建模规范、评审各分系统的UUT和测试描述、维护Schema版本与扩展包、组织季度一致性检查。从结果看真正落地互操作靠的正是这个组织机制没有它标准文档再厚也只是纸面工作。6. 从单型号到通用测试平台后续能怎么扩展6.1 多型号复用与模型库资产化模型库建起来之后最大的红利是新一代型号可以站在上一代基础上起步。按我们的估算沿用同一套模型库时新型号的测试描述建模工作量能减少四成以上箭上单机类型相似的部分直接引用模板只有新设备和新流程才需要新增模型。支撑这一点有个前提模型库必须做资产管理。每个模型要有负责人、版本号、评审记录、被引用列表否则用着用着改了一个公用模板影响范围说不清楚反而变成风险点。6.2 与半实物仿真和数字孪生结合测试描述的价值不止用于真实测试。因为它是信号级的同一份测试描述完全可以发给半实物仿真环境执行用仿真信号替代真实激励实现同一套流程先仿后实。我们在一个新研型号上试过这个模式测试描述先在仿真环境完整跑了一遍发现三处流程顺序问题这些问题如果等到真品上才发现代价会大得多。更进一步如果数字孪生模型能够消费标准格式的结果数据就可以做趋势分析和故障预测比如某类伺服机构零位漂移的历史曲线可以跨型号积累这正是ATML数据标准化之后的自然衍生价值。6.3 测试数据的标准化挖掘最后说数据。所有测试结果以标准格式入库后能做的分析工作就多起来了同类设备多个批次的参数分布分析、不同工位之间的系统误差比对、加注前后同一参数的系统性偏移监测。这些分析在各存各的格式时期几乎没法做因为数据口径不统一在ATML体系里它们只是几条查询语句的事。我实际用下来最顺手的一个场景是把三个工位同类传感器的线性度测试结果汇到一张表里直接发现某一批次传感器的线性度分布明显偏离历史区间后来查出来是生产批次工艺波动。放在以前这种异常可能要到故障暴露之后才会被注意到。这套方案在我参与的项目里已经完整跑过从建模到执行再到结果归档的流程。说实话过程不是没有折腾前期建模阶段各分系统为了信号命名的事没少开会执行引擎的映射器也重写过一次。但走到今天型号复用的收益已经实实在在体现出来。如果让我给正准备做类似系统的人一句忠告那就是ATML不是一套买了就能用的软件而是一份需要整个研制体系共同遵守的数据契约。能不能拿到回报取决于你愿不愿意先在信号字典和建模规范上花够工夫。这个地基打牢了后面每一步都顺打不牢后面全是补丁活。