数字孪生系统的工程实践

在实践调研中发现，目前的自动控制系统中，1，2，3类型具有以下特点：

（1）系统具有极高的重复运行稳定性。实践中，除刀具磨损造成的尺寸偏差外，几乎没有包括逻辑误差在内的其他误差；

（2）内置软件为预先编制好的软件，在编制过程中，已经完成了运行时间、装卡时间等与生产线运行节拍相关的运行参数分析，而且没有需要借助外界端口进行逻辑判断和运算的过程，完全独立运行；

（3）在实践中，此类型设备的反馈信息仅需要知道物料流转和报警、运行、待机信息。而对于具体加工过程，因为在设备上线前期已经掌握其工作节拍，且正式运行后并不会改变，因此用户普遍对设备的详细运行过程不予关注。

因此，在数字孪生系统中，对于 1，2，3 类型的设备按照客户的实际需求，作为黑盒模块处理，只关注其输入/输出信号，忽略设备内部的详细动作过程，达到简化数字孪生系统的目的。

对于类型4，基于计算机（PC）的控制系统，较多的应用是在自动检测/测试系统，而且绝大部分属于订制开发产品。对于此类控制系统，可以采用与实体控制系统并行运行的方式，直接实现数字孪生。笔者在自行开发此类控制系统时，通过专门配合开发的信号输入模拟软件即可实现相应信号的输入以及模拟运行后数据的输出。在实际工作中作为一个调试工具，此信号模拟输入软件模块是此类控制系统开发过程的副产品之一。

另外的两个副产品就是基于网络的控制系统状态、信号、数据的输出端口模块，以及多种端口形式的系统远程控制模块。为了解决设备在现场调试时的远程检测、远程调试的问题，上述的模块通常都是作为开发调试工具进行开发的。在有明确需求的时候，经过完善即可导入数字孪生系统。

作为可订制开发的软硬件结合产品，在项目定义初期就应定义好相关功能模块，后期在实现数字孪生过程中，就可以轻松地实现数据接入和输出。对于模拟运行分析等操作，配合上述几个模块，可以简单地通过独立计算机在线模拟运行等方式实现。

对于类型5，基于工业计算机的数控机床设备，目前很多设备在出厂时已经具有通过网络通信交互传输数据的能力。而其他没有开放对外输出数据功能的设备，基本都使用基于微软Windows操作系统的软件平台，而且市场主流设备都会把相关生产过程数据以 LOG 记录文件的方式按照一定规则存放在特定文件目录里。因此，可以在连接设备网络端口自行组网后，自行依靠设备软件平台的系统设置功能，采用设置网络共享目录等方式远程联网获取所需数据。此处有一点需要注意，由于系统安全和设备维护的原因，几乎所有设备生产厂家都不愿意采用在设备配置的计算机中安装第三方软件的方法，实现本机数据主动发送到远程数据服务器的功能。因此，只能从服务器端去抓取设备运行的数据文件，再以相关数据作为输入，结合设备节拍、设备参数配置等设备内预先设置好的参数，或者是工艺技术人员编制完成的生产程序，完成在数字孪生系统中对设备的运行过程进行实时监控、模拟和分析。

对于类型6 ，基于可编程控制器（PLC）实现的控制系统，在实践中发现以下几个特点：

（1）此类设备出现在生产现场的频率远远高于其他几类设备的，用量大；

（2）既有专用设备，也有通用设备；

（3）很多生产过程中的多种功能模块集成运行的连接方式，都是采用此类控制系统实现的，此类设备的集成运行过程中涉及很多逻辑性的判断和运算操作，其中很多运行过程很难作为黑盒处理，需要对过程进行模拟或实施完整监控；

（4）虽然可以采用通信端口通过 PLC 控制器的软件编程，使 PLC 控制器可以按照类型 4 基于计算机（PC）的控制系统的设备一样的方法与外界进行交互，但是，因为占用 PLC 控制器包括存储空间，运行扫描周期的软硬件资源等问题，降低了设备的运行可靠性和运行稳定性，因此，在实施过程中存在一定风险，而且无法实现模拟运行。

根据上述调研结果，作为一个运用广泛，有模拟运行需求的控制系统，如何在较低的后期开发工作量的前提下，能够快速地部署到数字孪生系统中，就显得很重要了。

调查中还发现，国内市场上的 PLC 控制器应用，存在以下几个特点：

（1）虽然市场上 PLC 控制器的品牌有二三十个，但是常见的PLC控制器的品牌相对集中；

（2）所有PLC控制器的程序运行过程都是在各自的编程软件上完成编程后，经编译后下载到 PLC 控制器中，再由 PLC 控制器执行；

（3）PLC 控制器的编程语言种类虽然有五六种，但是已经成为标准化的编程语言，其指令结构和功能、运行模式等都是基本一致的，因此，不同品牌之间的程序可以进行移植。当然，各厂家的某些指令格式存在着差异，但是功能和动作逻辑是一致的；

（4）因为已经基本实现标准化的原因，市场上比较常见的两个编程语言风格，以西门子、三菱/欧姆龙为代表，其他各厂商的编程语句与上述两家的编程语句相似度非常高。

基于PLC控制器程序的生成和运行过程，笔者认为既然都是编译后执行，则可以忽略编译后的机器代码内容，只需要保证原始程序能够准确通过编译即可。只要开发者能够虚拟运行一家的PLC控制器，则其他家的PLC控制器的运行过程完全可以全部编译成选定厂家的 PLC 控制器的机器语言并在虚拟机内运行。为了更加真实地模拟各家PLC控制器厂商的产品，只需要根据各家PLC控制器产品的差异，调整系统扫描时间等设备运行参数即可。

另外，实践中更换PLC控制器的厂家和型号也是设备开发中的常见操作，只是因为各厂家 PLC 控制器的差异，需要调整程序和输入输出参数设置。在数字孪生系统中，也可以通过修改虚拟机PLC控制器参数，便于更改PLC的厂家和型号。

当然，各厂商的 PLC 控制器参数有很多，不同厂商的参数及同一厂商的PLC控制器使用不同的扩展模块、连接不同外接设备时，相关的参数也存在差异。但是由于数字孪生系统的虚拟机只需要模拟运行其逻辑运算过程，因此很多诸如通信设置、脉冲设置、伺服设置等参数都可以忽略，仅仅关注PLC控制器虚拟机的输入输出信号和逻辑运算过程。

PLC控制器程序在实体端和数字端的运行过程如图1和图2所示。

   

在确定了此开发思路后，如何在运行于计算机上的数字端虚拟机上直接运行 PLC 控制器的程序就成为了下一个阶段的核心任务。

   

基于以上对技术和市场分析结果，笔者选取了 2个不同体系的PLC着手进行验证，这两个体系分别是三菱和西门子。作为国内应用量大、底层资料公布多的两款PLC，国内大约在 2010 年前后就以开源 DIY-PLC 项目的形式，开始了针对上述两款PLC控制器基于51单片机和基于STM32的ARM系统软硬件平台的解析和仿制工作。基于此开源项目的背景，笔者选取了数字孪生系统虚拟机相关的部分模块，即输入解析模块，输出解析模块，编码解析模块作为开发工作的重点。

（1）输入解析模块 首先需要根据输入接口列表，将从实体设备远程采集到的各种信号转换为虚拟机的数据参数。简单地说，就是用外界实体数据对输入解析模块进行赋值。此处输入解析模块甚至仅仅需要对输入的数据进行变量类型、数据格式的转换等基本操作，然后将得到的数据赋值给代表各个接口的指定变量就可以实现由实体信号输入虚拟机运算模块的过程。输入解析模块的工作过程如图3所示。

   

（2）输出解析模块 与输入模块的输入数据处理过程相似，通过对虚拟机的运算结果赋值到输出端口映射的数据变量、数据地址或文件，就可以完全实现输出执行结果的工作。而虚拟机的端口，实际上只是一些存储数据的变量或数据地址。数字孪生系统再通过对虚拟机存储的上述数据变量以及数据地址或文件内存储的数据，进行分析处理，完成对实体端的模拟运行和分析。输出解析模块的工作过程如图4所示。

   

（3）编码解析模块 在 PLC 控制器的官方编程软件中，程序编译后成为的机器编码形式，在实体端，程序先被存入 PLC控制器，再由PLC控制器的MCU及固件进行调用、解析和执行。而在数字孪生系统的数字端，则是由虚拟机对机器编码执行上述的调用、解析和执行工作。再通过虚拟机及输入和输出解析模块完成在计算机系统上的虚拟运行，此模块的工作也是 PLC控制器虚拟机的核心工作。对于计算机系统来说，其工作过程就如同一个开发者自定义的计算机高级语言解释器。

对于此项核心工作，开源DIY-PLC项目中提供了很详细的代码和文档，文中不再赘述。

完成上述数字端实时仿真运行系统上运行的软件模块的开发后，就可以将实体设备中相关的程序经过预处理后，直接生成数字系统需要的代码；结合输入解析模块输入，就可以供数字端在虚拟机中进行实时的仿真运行。

生产实践中，因为产品型号更换，设备参数、工艺调整等原因，数字端也需要与实体端同步实现变更。如何方便快捷根据实体端的实际运行需要实现数字端工艺流程的变更，此需求决定了数字孪生系统是否能够长期有效的运行。其核心要求是：

变更的方法要适应一线技术人员的学习，容易掌握；开发的方式，要贴合现行工艺和设备的工艺卡片、工艺流程等技术文件的编制习惯。

实践中，笔者开发了一种基于工艺卡片式文本形式的脚本化编程语言。其中包含了工艺流程中常见的编程指令模块，例如：数据的逻辑运算，数据的数学运算，流程流转控制，还有设备参数相关的设备选择，设备的通信端口选择，数据存储地址设置等，以及用于运行流程跟踪的运行结果反馈，显示信息等。考虑系统运行的实际情况，还增加了跳步，数据记录 LOG 文件生成等指令。

开发工艺列表式的脚本化编程语言的主要目的是，在修改实体端的工艺流程文件后，工艺技术人员可以在数字端便于根据工艺流程文件和生产现场的设备等实际状况，通过修改调用各设备的相关逻辑和技术条件等参数，方便地修改设备工艺的排布顺序及每个设备的调用参数，从而实现工艺技术人员在修改实体端的产品生产工艺流程时，根据工艺流程文件直接实现对数字端的工艺流程同步进行修改，而再不需要专业人员对数字端系统进行软件方面的升级维护。

编程语言的实现，是基于数字端的所有设备均采用模块化构建的方式，其输入输出的数据均采用参数化设计。

编程语言的格式相同，但是针对系统层和设备层，在各字段的选择和字段内容上有差别。主要差别点在于设备的信息选择和数据通信端口的选择。也就是系统层的编程核心是在设定情况下应该调用什么设备，设备层的编程核心是根据上一行语句收到的信息判断下面应该执行什么操作。

为了便于对程序执行的过程进行控制，列表式编程语言使用行号作为各命令行的标记。

基本的通用编程语言字段参如表1所示。

   

因为列表式编程语言的开发针对于工艺过程管理，因此，很多存在于高级语言中的数据类型及语句、命令、函数等，均得以省略或简化。

列表式编程语言的运行逻辑按照从首行至末行扫描顺序执行，除非遇到跳转、跳过等命令，程序将连续执行到末行。然后再次从首行开始执行。

编程语言采用解释语言的方式执行，不需要编译，便于维护和修改。

列表式编程语言，以表格方式编制，以文本方式存储。表格式结构的编程界面里可以方便地通过选择菜单直接选择相关命令和表格的内容，此种设计也为后续实现人工智能化编程预留了发展空间。

经实践验证，列表式编程语言可实现工艺人员在经过简单培训后，即可通过按照工艺卡片及其逻辑关系填写该表格，从而可完成相应程序的编制。生成实际编制程序如表 2 所示。

   

在数字端运行开发的列表式编程语言，需要在数字端开始整体运行之前，根据实体端整体的工艺流程，选择调用相应的脚本程序文件，而各设备也需要选择和调用相应的脚本程序。

当然，实际操作中，此略显繁琐的调用过程是在预先编制的配置包中自动加载。其加载文件主要调用部分格式如下：

[ProductSet]

ProductID=CT0008A

ProductModel=800SPRO

ProcessPlan=CT008A-800SPRO

Verifiaction=CT0008AVerifiaction2A.txt

Barcode=14

[FilePath]

ProcessPlan=\processplan

[LogFile]

LogFileName=log22Q4BCT008A-800SPRO

LogTitle1=The Product:

[ModelSetting]

800SPRO=800SPROSet**V1.txt

[ModelList]

ModelList=800SPRO

配置加载文件也可以在数字端模拟运行过程中随时人工加载或更换其他配置文件。

实践证明通过编程语言+配置包的形式，可以方便快捷地实现数字端的产品生产过程的无缝切换。

完成了模拟执行功能后，会发现系统实体端和数字端的运行时间并不同步，数字端的运行速度总是会比实体端快。针对此问题的解决方法有两种，简单的设备可以在脚本程序中通过填写延时数据进行人工修改，经过反复修改和验证，最终实现数字端与实体端的运行时序一致；另外一个方法就是利用机器学习方式，由软件自动适配出合适的时序。机器学习过程的概要逻辑图如图5所示。

   

K —预设的学习次数；N —学习次数；Te —信号结束时间；

Ts —信号触发时间；Tr —运行时间；Ti —初始运行时间；

Dr [ m ] —用于存储运行时间；Da —运行时间均值1；

Db —运行时间均值2；Dc— Db - Da的绝对值均值；Θ —阈值

其原理如下：

首先对需要计算的时序对应于数字端设定初始运行时间值Ti。设定软件计时器分别对应实体端的时序起始触发 Ts 和结束触发Te。

数值Tr用于从起始触发Ts到结束触发Te计算出的运行时间。一维数组变量 Dr [ m ]用于存储运行时间，此数组的大小，可以根据实际需求设置为50或更多。

变量Da，Db用于运行时间均值存储。

变量Dc用于存放运算得出的Db - Da的绝对值均值。

运行数字端的模拟运行软件，同时检测实体端的数据输入。数字端软件分别记录实体端发送过来的起始触发 Ts和结束触发时间 Te。计算获得实际的运行时间 Tr，Tr存入对应的实体端测量数据记录值数组 Dr [ m ]。采集数据 Tr 的数量达到预设数量后，对该组数值进行平均计算后得到 Da。第一次测算时，以Da修正数字端的初始运行时间Ti。然后继续运行下一个检测周期。检测周期结束后，先将上一个周期的计算数值Da写入辅助记录值Db，再将本检测周期的Dr的平均数值写入辅助记录值 Da。同时比较 Da 和 Db 两个记录数值，并将此次比较的结果写入辅助记录值数组Dc。一段时间后，如果辅助记录值Dc始终低于预先设定的一个阈值 Θ，则认为此时序的失真率极低，可以代表真实的实体设备数值。此时就可以把 Da作为实际的运行时间Ti正式填写入虚拟机时序。

上述运行过程写成一个函数，人工填入学习次数 n值和作为运行时间偏差的阈值后，由虚拟机软件在各个节点自行调用。采用上述自学习机制后，可以在很短的时间内做到数字端虚拟与实体端的运行时间达成一致。

该方法的缺点是占用计算机的资源较多，在后期关闭此功能后，虽然运行时序仍然会有少许偏差，但是由于目前的计算机运算能力普遍较强，因此微秒级别的时间时序偏差普遍可以接受。

以一套锂材料生产用的手套箱控制系统为例说明此算法的实际效果。该设备的基本技术要求是内部充满惰性气体，恒压、恒湿度、恒温度。其中的温度、湿度、气压通过若干组传感器获取，根据不同产品及设备实时状态驱动相应的泵、电机、阀体进行调整。因为泵、阀、电机设备从启动到参数达到设定目标，需要一段时间且根据产品不同，存在差异，在系统设计中还要考虑设备运行成本，电机、泵等设备的运行寿命。因此，客户需要对此设备的运行参数需要仿真优化和状态跟踪。

设备的实体端，由一个可编程控制器（PLC）及一个显示屏实现控制。实体端的操作信息、传感器反馈信息，以及各泵阀的运行状况，通过网络传送至数字端。

在进行产品型号更换时，产品型号数据同步传送至数字端，数字端自动加载相关配置文件。在获取传送过来的设备实体端运行数据的同时，启动模拟运行并将运行数据进行比较。在跟踪一段时间实体端运行无异常后，模拟运行停止，仅运行监视功能。

以设备中的各个泵为例，对比启动后稳定运行时间如表 3所示，监测方式采用对各泵的工作电流进行监测。

   

在数字端的工作中，数字孪生技术初期最重要的是如何及时准确地获取实体端的信号和数据，以及如何尽量精确地模拟实体端的运行。随后，就要解决如何让数字孪生系统的数字端具有高度的柔性化和生产适应性、维护便捷性、易于使用的问题。后者在很大程度上决定了一个数字孪生系统的生命周期长度。为了实现方便快捷的同步系统实体端和数字端的运行时间同步，有大量的长期的工作需要做。

文中所述的几个技术方面中，工艺脚本化编程语言的前 3个版本已经在基层生产技术人员的维护下实际运行多年，并且随着设备信息接口的扩展在不断升级，包括PLC可编程控制器虚拟机在内的其他技术点正在实际运行中进一步验证和强化，以提高其准确性、适应性和便捷性。

数字孪生技术的发展需要大量的多学科技术相结合，在适应生产实际需要和技术快速发展的同时进行长期艰苦的研究和实践。