基于数字孪生的工业软件持续交付
2022-10-03徐长盛杨土荣
徐长盛 杨土荣 李 伟
(上海宝信软件股份有限公司湛江分公司 广东 湛江:524000)
0 引言
国内外关于工业软件的定义不尽相同,一般认为工业软件指专用于或主要用于工业领域,以提高工业企业研发、制造、管理水平和工业装备性能的软件[1]。工业软件对实时性、可靠性和安全性有极高要求。钢铁业作为典型的流程制造业,其工业软件的应用具有先进性和典型性,宝钢对工业软件按功能层次进行划分[2]:L4企业资源计划(ERP)、L3制造执行系统(MES)、L2过程控制系统(PCS)、L1基础自动化系统(BAS)等。
工业软件一般都属于定制化开发软件,交付前必须进行反复测试。传统的工业软件测试一般分离线测试(不带设备)与现场联调测试(与生产工艺和设备全部打通)。离线测试往往只能做单体功能测试和部分集成测试,虽可模拟一些外部生产设备信号,但由于不能完整模拟真实生产情况,测试不全面。软件发布运行后不能正常工作、发生错误的情况较多。
生产线正常投运后还面临持续的参数和流程优化、加入新功能等情况;随着工业4.0[3]、智能制造[4]的大力推进,对工业软件交付更是提出了新的要求[5]:实时性要求更高、功能更加复杂,这样出错的机会和成本也大大提升。
自动化测试、敏捷开发、持续交付(Continuous delivery,CD)和开发运维一体化(DevOps)[6-7]等软件工程新技术在商业软件开发、测试、发布中取得较好效果,但在工业软件领域应用较为困难,很少有相关研究成果,主要难点在于无法模拟、再现真实生产情况。
如何让工业软件在实际投用前尽可能地进行与真实生产情况一致的充分测试?近年来兴起的数字孪生技术(Digital Twin,DW)提供了可能[8]。对于什么是数字孪生有不同的认识[9],本文认为在冶金制造业,数字孪生可将物理实体和系统的关键特征和行为映射到虚拟世界,这样真实的物理工厂的生产过程将以数字化的方式在数字空间中展示出来,成为虚拟工厂[10]。这就为离线测试提供了好的基础,在虚拟工厂中经过充分测试的工业软件将可稳定地投入到物理工厂中在线运行。
本文基于数字孪生技术提出一种新的工业软件持续交付方法,利用生产现场所产生的海量数据,经抽取数据构建典型场景的数字孪生平台,同时结合对部分关键设备的仿真,可获得接近真实生产情况下的运行环境,自动运行更多典型或者代表性场景的测试用例,既可以覆盖更多的情况,又可以加速测试过程,便于及时发现问题,降低故障、提升效率。下文所述工业软件除非特别说明,都指冶金制造业对实时性要求较高的L2软件或类似软件。
1 总体方案
单元测试、集成测试与软件开发同步进行,而软件交付前需要做详细的系统测试(包括功能测试、性能测试、用户体验等)、验收测试(交付测试),除了工业软件第一次正式部署运行前需要分别作比较正式的系统测试和验收测试,后续的功能升级或者优化测试一般较简单。对工业软件来讲,要求测试环境能基本重现真实的物理场景,测试数据(包括数据之间的关系)与真实情况一致。
建立与物理场景完全一致的数字孪生环境成本非常高,考虑到主要目的是建立与物理场景一致的测试环境,侧重在获取典型价值的数据,因此可以简化数字孪生系统的建立。基于DW技术构建软件持续发布的测试环境的总体框架如图1所示。
图1 DW环境的建立
图1左侧是真实的物理运行环境,右侧则是基于DW的测试环境(数据量远小于虚拟工厂数据量)。
考虑到生产的相对稳定性,一段时间内有大量实时数据是基本重复的,只有在更换新物料、生产新产品、采用新工艺,或者设备状态不稳定时,设备数据才会有明显差异,因此需要构建建模程序,抽取具备典型特征(开始、变化、结束等)的实时数据并保存到数据库DB_B中,作为测试环境的测试基准库。在测试环境中也部署与真实环境类似的工业软件,当有新软件待交付时,则开始模拟运行,模拟运行产生测试结果库DB_T,分析程序对比基准库(DB_B)中的实际运行(实绩)数据和测试结果库(DB_T)中的模拟运行数据,最终给出新软件是否通过测试的结论。通过测试的工业软件将择机在物理环境中发布。持续的软件发布只需要反复执行上述过程即可。
2 系统构建
2.1 数据采集
数字孪生通过数字化的手段构建一个数字世界中一模一样的实体(虚拟工厂),离不开海量的实时数据支持,数据越多越能真实的反映物理世界。这些数据包括:生产计划、工艺参数(含工业模型)、设备运行状态、物理环境等[11]。对设备运行状态的数据采集涉及较多专用网络和仪器仪表,随着更多智能传感器、5G在工业中的大规模应用,越来越多的设备数据被采集[12],如大电机的温度、电压、电流、震动等。
从流程角度来讲,可将每一个业务流程抽象为:输入数据、处理过程、输出数据。输入数据I和输出数据O都包括多个数据项x0x1,x2,……,xk和y0,y1,y2,……,yn,本级输出数据会成为下一级系统或者设备的输入数据,认为处理过程是一种映射M,可定义:
M:I→O
(1)
I:x0,x1,x2……xk
O:y0,y1,y2……yn
如果不探究M的具体方法和意义,则根据大量的输入、输出数据,通过一定方法如深度学习[13]等可以建立一定的学习、预测模型,根据新的输入预测出新的输出[14-15],即使用数据就可以模拟工业生产全过程。工业软件的工作过程可以认为是多层、多个M的组合:
M0(M10(M20(…I…)),M11(M21(…I…)),
……M1k(M2n(…I…)))→O0
(2)
原始的输入数据I0是生产计划(包括了原料信息、合同成品要求等)、初始设备状态等,而最终的输出O0应该是成品实绩(实际成品的参数信息,满足合同成品参数要求)、设备状态等。
建立采集程序,将生产过程中的输入、输出数据采集到实时数据库DB_R中。考虑对现有工业软件系统的影响和经济成本,采集程序的采集范围、采集策略(频率等)等需要认真设计。以某一个冷轧生产线为例,如果有50000个数据采集点,每5ms采集一次,每次10个字节,则每秒的数据量就是100M,如果某个钢卷需要在产线上处理10分钟,则一个钢卷的采集数据就达到60G,这还不包括很多图像数据、音频数据等,无论是网络还是存储都是难以承受的。
2.2 数据建模
将生产过程中的数据全部采集下来用于测试环境的建立既无必要,也不可行,因此需要有建模程序对DB_R中的实时数据做过滤、筛选,建立产品模型数据或者典型测试场景数据,这些数据模型或者场景数据将作为测试环境下的参照基准。
建模程序如何建立?这就涉及到具体生产过程的分析,以钢铁企业里冷轧处理线生产过程为例,一个原料钢卷大约4000m,当钢卷在入口被输送到机组上,则由激光焊机与上一钢卷进行焊接,然后生产线各设备按照工艺要求进行工作,约15min后本钢卷处理完毕,机组出口剪切形成成品钢卷,机组开始新的一卷生产(实际中由于机组距离较长,机组入口上料时间和出口出料时间并不一致)。分析上述过程就知道除了本次的典型数据需要保留,生产过程中长期稳定的数据则可以进行压缩;考虑到是连续生产的上一输入、下一次输入的关键信息也必须保存。
经过本步骤,将形成以下的场景模型数据Pk:
Pk{Ik0,Ik1…Ikm,…,Ok}
(3)
Ik0:Pk的初始输入数据,多个数据项组成Ikm:Pk的某个中间数据,由上一级Ikm-1经映射Mkm-1得到Okm-1,合并其他数据成为新的输入数据Ikm
Ok:Pk的最终输出数据,多个数据项组成
需要按照一定的关键字(如产品规格、时间等)建立模型数据,关键字的选择应该能体现生产的独特性,其作用代表了一个独立的测试场景。以湛江钢铁某冷轧厂镀锌机组为例,经调查三个月内的生产数据发现,钢种、宽度、厚度、锌层厚度是决定因素,只需要针对上述关键字筛选有代表性的生产数据,就无必要采集全部数据,可以降低数据存储80%以上。
数据采集程序和建模程序可以合并在一起,但考虑到建模程序的复杂性,还是分开建立较好。
2.3 虚拟设备建立
测试环境中需要建立虚拟设备,其目的在于能够仿真真实的物理设备工作:接收待测试工业软件的输出,经模拟处理后输出到工业软件。如何构建逼真的虚拟设备是难点,特别是当生产线上有大量设备或者工作机理非常复杂的设备,这种工作几乎是无法完成的。
按照公式(1)原理可以构建虚拟设备,即将输入数据与现有模型数据进行对比,按照一定规则产生模拟输出数据,规则有物理公式(有固定逻辑)、查表法(存在历史相同规格数据)和插值方法(无历史相同规格数据但有接近的数据)。对于复杂设备如冷轧退火炉的虚拟设备构建则比较复杂,也可以使用深度学习算法,本文不作详细讨论。
以某钢铁厂冷轧某镀锌机组为例,入口有钢卷小车、开卷机、矫直机、剪刀、焊机、月牙剪、入口活套等设备;中央段有清洗槽、加热炉、锌锅、镀后冷却塔等设备;平整段有中央活套、平整机、拉矫机、辊涂机、后处理塔等设备;出口段有出口活套、月牙剪、圆盘剪、测宽仪、测厚仪、涂油机、飞剪、卷取机、钢卷小车等设备。当然全生产线还有较多张紧辊和转向辊等设备。容易出故障的设备有焊机、平整机、锌锅、辊涂机等。
在以上设备中机理相对简单、便于构建虚拟设备的有:钢卷小车、剪刀、开卷机、活套、月牙剪、圆盘剪、测宽仪、测厚仪、涂油机、飞剪、卷取机、钢卷小车等,根据输入值使用物理公式或者查找基准库(DB_B)就可以构建输出值,使用编程语言如C#做成控件就可以直接使用,在做控件时需要将物理设备的参数允许范围也记录下来,便于及时校验输入值是否合理。
对于加热炉、平整机、拉矫机等设备,机理复杂,要提升虚拟设备与物理设备的符合度,需要较多努力,考虑到当前主要目的是测试,并不要求精确模拟生产,因此采用简单的方法即查表和线性插值法来构建输出数据,若发现本级输出与正常值有较大差异则强制清除偏差。同样用编程语言做成控件方便使用。
为了让虚拟设备工作,以及不修改原有软件(通信接口部分),还需做一个接口转换程序,如图2所示。
图2 虚拟设备的建立
L2系统一般通过TCP/IP通信或者OPC[16]方式从L1获得数据或者下发数据给L1,接口转换程序的作用可以起到这部分功能。
如果新程序的发布不涉及原计算规则变化,则理论上输出应不发生变化、不需要经过虚拟设备而直接与原输出进行比较,但是从测试的真实性角度考虑,还是应进行完整的生产作业流程测试。
2.4 软件新版本测试及发布
如果只针对新增加或修改的功能进行测试,往往会导致测试不充分,理想情况应是将原正常工作的测试用例全部运行一次。每次测试用例的执行都会涉及测试数据的准备和测试结果的对比分析,测试输入数据主要基于DB_B中的计划数据。当有新工业软件待交付前,则在测试环境中开始模拟运行,模拟运行产生数据库DB_T,新软件是否正确需要有分析程序对比DB_B的实绩数据(与计划数据对应的输出结果)和DB_T,最终给出新软件是否通过测试的结论。
测试用例的建立应具有广泛的覆盖性,包括各种情况,值得注意的是从真实环境中获取的计划数据往往都是符合要求的正常数据(一般生产过程中的异常数据会被清理掉),缺乏异常数据如边缘数据和错误数据,从提升工业软件鲁棒性角度来讲,需要增加异常数据集做相关的测试。软件新版本的测试与接受流程如图3所示。
图3 软件新版本的测试与接受
考虑到软件的持续发布,为提升效率,测试用例的运行应基于自动化原则,尽可能的减少人工干预,在运行每个测试用例之前,还需要做一定的清理工作。
2.5 软件发布及持续交付
软件通过测试,经评估认为满足正式发布条件的软件可选择合适的时机进行发布,对连续生产的机组一般需要选择停机时间如定修时间进行。发布之前应做好相关环境和程序的备份,用于紧急情况下的恢复。如果考虑软件的持续发布,可以反复进行上述过程,为进一步提升效率则需要构建自动发布机制。
3 实例验证分析
本实验数据来源于某钢铁企业的厚板生产厂的L2系统的现场交付与冷轧厂的无人化全自动行车系统中的库区管理与控制软件(Warehouse Manage System,WMS)的现场交付。
3.1 厚板L2的持续交付
厚板生产线主要包括加热炉、轧线、层冷、精整及热处理等部分,工艺比较复杂,其L2系统如图4所示。
图4 厚板L2系统
因为厚板L2系统的复杂,直接在现场测试、发布很容易出现问题,某厚板厂2019年下半年工业软件发布问题见表1。
表1 厚板L2系统2019年下半年更新发布情况
随着厚板市场形势转好,产能逐年提高,以及新品种、新工艺的应用,对L2系统的功能变更越来越频繁。2019年下半年开始采取了基于数字孪生建设测试环境并测试、交付的方法(见表2)。
表2 2020上半年厚板L2发布情况
厚板L2是五个独立部分,采用一台物理服务器模拟五套虚拟系统的方式,实时采集L2有关数据并抽取、建模到测试环境中。
对表1和表2数据进行对比可以发现,基于DW的测试环境的建立提升了软件测试的有效性,有助于工业软件的持续发布,当然也存在由于新品种的出现导致测试环境下场景数据不足、测试不充分的情况。
3.2 冷轧厂WMS的持续交付
无人化全自动行车系统(Unmanned Automatic Crane System,UACS)采用三维定位、自动驾驶等技术代替人工驾驶仓库里的行车(梁式轨道起重机),实现仓库的自动化管理(见图5),其核心是WMS[17]。
图5 UACS系统
WMS程序常需要在现场及时更新,但是多台行车运行的各种场景组合太多,单纯人工测试能够覆盖到的场景不足30%,测试不足极易造成行车运行故障,严重的造成安全事故,统计2019年上半年某冷轧厂成品库10台无人化行车(2018年已经正常交付运行)WMS更新发布情况见表3。
表3 2019年上半年冷轧WMS更新发布情况
在2019年下半年采用了上述方案后,在虚拟环境下进行测试,提升了测试用例数量,大幅降低了测试时间(包括了测试发现问题重新修复、测试的情况)、现场发布时间和投运后的故障,具体见表4。
表4 2019年下半年WMS更新发布情况
4 结语
当前工业软件的持续交付还处在较低层次,存在较多问题;随着云计算、大数据、5G等技术的发展,传统制造逐步向智能制造转变,对工业软件的交付也提出了新的要求,同时也提供了新的可能。本文提出基于数字孪生的工业软件持续交付方法,提取、建模出物理工厂下的典型生产场景数据作为测试基准与模拟运行结果进行比较以判断是否可以交付新的工业软件。本方法在实际生产中进行了应用,验证了该方法的有效性,该方案使工业软件在交付之前能够快速在多种典型场景下进行验证,大幅降低了正式发布后软件出故障的机会,同时提升了软件测试效率。
当前研究存在的主要问题在于更多的是基于历史正常数据所作出的测试,对新品种测试存在一定偏差,另外在压力测试、异常数据与图像音频等采集方面考虑不多。未来研究将聚焦于上述不足,进一步提升虚拟环境下测试的全面性和有效性。