钢铁行业生产大数据实时清洗框架设计与实现

刘伟川，倪坤仪，王刚华，李聪超，张英丽

（西门子（中国）有限公司，北京 100102）

随着钢铁行业的发展与全球工业数字化程度的提升，钢铁行业的数字化逐渐成为受瞩目的话题。早在20世纪末，钢铁行业的专家系统［1］对于生产过程的辅助已获得较多成果；如今，除已有的专家系统与知识外，大量实际生产数据的收集与应用能够为钢铁行业产业升级提供进一步帮助。实现数字化，首先需要提取工业生产中的数据，以满足后续产线监控、质量预警、大数据分析等应用。现代化钢铁企业中，数据产生的价值愈发重要,在连续的热轧产线上，往往存在产线实时监测数据无法立刻与产品对应,无法通过数据实时进行判断，数据质量差的问题。随着互联网、大数据等行业的兴起，相关技术亦愈发成熟。在消费与服务行业存在大量成功的大数据产生价值的案例，如利用实时客流进行商业评估，利用用户浏览趋势推送相关信息等［2］。

工业中的实时数据存在于生产与日常的运营当中，目前，大量企业还处在较为初级的利用粗粒度的汇总信息进行事后分析的阶段，主要的应用集中在商业智能、看板等领域，大量的产线数据并未加以有效利用，每日产生的TB级数据仅存储在数据库中，虽无人分析查看，仍需保留至几年后方可删除。此现象反映了产线数据要素价值未激活，持续增长的数据对于企业数据存储产生的压力日渐凸显两个主要问题。为此，根据典型热轧线的生产数据、数据应用场景，设计并实现了生产大数据实时清洗框架，使实时产生的数据能够以结构化、与产品（钢卷）绑定的形式进行存储，以便后续针对产品的分析；同时，大大降低了数据量，将重复与价值低的信号数据清洗，仅保留对工艺与业务有价值的数据；另外，数据的质量在清洗的过程中，通过消除空值、异常值、数据正则化等方法得到提升，大大节省了后续分析中的数据清洗与预处理工作。下面对数据清洗框架的设计与实现，以及其在实际场景中的应用与价值体现做一介绍。

1 钢铁行业生产数据特点

现代化的钢铁企业以满足客户的需求为目标，需要实现多品种、小批量、高质量、高效率等多项要求。对于带钢热连轧复杂的生产过程，为了实现上述目标，功能完备的计算机控制系统是必不可少的。目前，现代化的带钢热连轧生产配置了从基础设备控制到生产管理的多级IT系统。通常一个较为完备的热轧多级IT系统包含四个级别，即基础自动化级（L1）、过程控制级（L2）、生产控制级（L3级）和生产管理级（L4）。L1级以产线设备为主要控制对象，完成位置、速度等方面的控制。同时，对热轧质量相关的关键变量如带钢厚度、宽度、温度等进行L1级的控制。L2级主要完成L1级所需要的轧制工艺控制参数和设备控制参数目标值的计算，该计算一般通过L2级中预设的数学模型和相关的优化功能完成。L3级主要完成生产计划的调整和发布，同时包含对生产绩效的计算和处理；此外，对板坯库、钢卷库、成品库进行相关的管理，同时对成品的质量进行监控。

从订单到产品交付，四级IT系统以不同的方式产生数据，是数据分析的主要数据来源。其中，L1、L2级系统是热轧生产大数据的主要来源。基于大数据的四个特征，热轧生产大数据具有很多自身的特点：

（1）数据体量方面，热轧产线包含加热炉、粗轧、精轧、卷取等主要工艺段，每个工艺段包含不同类型的机械设备、电气设备、水电气公辅设备等。这些设备或系统在带钢生产过程中会产生大量的实时数据。同时，与设备相配套的自动化系统也会产生相应的控制数据，包含时序数据和控制闭环相关的设定值、反馈值、控制器参数等。

（2）数据类型方面，热轧产线上产生的数据包含多种不同类型的数据，如钢卷跟踪相关的事件数据、轧制相关的过程变量（如轧制力）、关键质量相关的变量数据（温度、厚度、宽度、板形等）。典型的7台精轧机构成的精轧机组通常包含70～80个控制回路，其对应的变量种类复杂且相互耦合。

（3）产生速度方面，热轧生产数据的采集频率通常很高，尤其在精轧阶段，带钢的高速轧制使得精轧区域会以十几毫秒的频率进行数据采集。

（4）价值密度方面，产线不同工艺段的数据随时间不断产生，其中真正轧制时的数据仅占一部分。

综上所述，在钢铁行业的数字化项目中，如何有效地应对生产大数据的特点是数字化项目高质量交付的前提，也是需要解决的核心问题。

2 典型热轧线数字化项目难点

2.1 项目概述

热轧线数字化项目通常是在其高自动化水平的基础上提出的，旨在提升数据集成和深度挖掘能力。一般来说，项目以贯通L1、L2级数据为主，同时兼顾L3级相关数据的集成，通过实时数据清洗实现产线的数据资产建立，并以数据资产支撑上层的热轧智慧应用。典型热轧线数字化项目整体架构如图1所示。

图1 典型热轧线数字化项目整体架构Fig.1 Overall Framework for Typical Digital Project on Hot Rolling Line

数据清洗功能架构在平台的IaaS基础设施之上，对接已有系统中的实时数据并完成数据清洗。清洗后的结果既可以直接提供给实时性较高的应用，也可以直接完成数据持久化，供后续数据分析和其他应用使用。可以看出，数据清洗作为整个建构的中间层，是整个上层智慧应用的数据底座，是上层智慧应用有效运行的必要前提条件。同时，为了使清洗后数据更具有业务价值，建立了从业务视角出发的钢卷数字化画像，结合数据清洗将钢卷相关的数据进行实时关联。

2.2 实时数据清洗难点

热轧产线的实时数据清洗是支撑热轧智慧应用的关键。从数据的角度面临几个难点：

（1）热轧产线通常包含多种数据源接入，包括L1级和L2级相关的数据采集系统、水电煤气系统、质量判定系统等。系统之间相对独立，需要进行同步接入。

（2）L1、L2级具有极高的数据采集频率，需要完成实时的数据接入与清洗，并将清洗结果进行持久化，对于清洗系统的数据承压能力提出了较高的要求。

（3）典型热轧线数字化项目具有多样的清洗需求，包含钢卷ID与生产数据实时绑定、粗轧正逆轧制映射、钢卷时空变换、数据特征提取等。如何在极高频率下完成数据的清洗工作，对于清洗算法的设计和实现都是很大的挑战。

（4）如何构建有效的钢卷数字画像，将生产、质量等不同维度的数据进行关联，进而支持上层智慧应用的需求，也是数据清洗所面临的难点之一。

3 实时清洗框架

针对实时数据清洗的难点和钢铁行业的特点，实时清洗框架的功能需要涵盖对多种应用场景的弹性支持、对清洗过程中的异常进行容错处理、具有高吞吐量和低延迟的特性、特殊应用场景的支持［3］。

3.1 实时清洗架构

整个数据流向的架构分为5层，自下而上由接入层、计算层、存储层、服务层、应用层构成。涵盖了数据从L1到L4流转的各个步骤。其中，接入层采用Kafka消息中间件作为数据接入方式。计算层基于Flink［4］实时数据处理框架，对具体的场景需求进行算法定制。存储层提供关系型数据库PostgreSQL和实时数据库ClickHouse作为数据存储组件。服务层对外提供统一的数据接口，对上层应用屏蔽下层的数据复杂性，利于最上层应用的开发与实施。实时清洗架构图如图2所示。

图2 实时清洗架构图Fig.2 Architecture Diagram for Real-time Cleaning

3.2 功能特点

3.2.1 引入主数据表

由于钢铁行业的特殊性，在整个流式处理中，原始数据并没有和生产数据实时绑定，对后续的分析应用造成了技术负担。在此场景中，系统引入主数据表概念以处理各种业务需求，其中定义了数据源系统中的测点和分析系统中的对应关系、各个工序对应的配置、钢卷ID对应的source通道等一系列辅助数据清理的信息来支持弹性分析。用户同样可以通过编辑主数据表来输入专家知识并帮助数据清理逻辑以更好地满足业务需要。

3.2.2 数据热存储

在典型热轧数字化项目中，由于测点众多，业务逻辑相对复杂，主数据表的体量随着业务的推进迅速增加。为此，系统提出以预加载主数据表和热存储关联的方式解决大数据实时清理中的主数据加载、分发、对上下游的压力问题。随着数据表容量的变化，系统以切换主数据表的加载方式来更好地服务清洗需求。预加载主数据的方式是将主数据预先加载到内存中，各处理单元在流式处理时到内存中完成相应的关联和查询操作，实现简单，但是占用内存，不适合主数据大的场景，且主数据更新不及时。热存储关联的方式是将主数据加入热存储中，通过异步IO的操作、去IO的方式完成查询。在吞吐量高的场景下，为了防止与热存储的交互造成瓶颈，系统引入缓存机制以减轻对热存储交互的压力。同时，系统采用事件差异检查的机制来避免无效的数据加载操作和主数据及时更新的问题。在主数据表更新时，系统将对已加载主数据和主数据表进行差异分析。如果有差异，将差异更新至缓存。实时清洗框架热存储功能如图3所示。

图3 实时清洗框架热存储功能Fig.3 Thermal Storage Function of Real-time Cleaning Framework

3.2.3 数据缓存

在工业场景中，数据的准确性非常重要。在分布式系统中，组成系统的各个计算机是相互独立的。系统易受各种意外因素的影响而发生故障（磁盘、网络等）。如果发生了故障，在很多大数据清理框架中会有不同的侧重点。流处理引擎为数据处理定义的语义包含at-most-once、at-least-once以及exactly-once。在此项目的技术选型中，系统采用了对钢铁行业最适合的exactly-once模式来保证数据的准确性和避免数据重复。在数据清理框架中系统将配置和启用检查点机制，框架定期触发检查点并触发快照的生成。快照中包含了能从故障中恢复的相关信息。在开始流式处理时会生成一个快照，在之后的各个计算因子作用下此快照版本会被更新，并传递检查点信息至下一个计算因子，在整个流式过程结束之后提交整个快照以归档整个流程。整套机制不依赖于外部系统，各环节的状态信息将维护在清理框架中，由框架统一管理。如果发生故障，就从最近的一次快照中恢复运行。数据在最终计算和归档化的过程中只会被计算和统计一次。实时清洗框架状态缓存功能如图4所示。

图4 实时清洗框架状态缓存功能Fig.4 Status Cache Function of Real-time Cleaning Framework

3.2.4 数据源接入

在数据源部分，为了保证系统的高吞吐量和低延迟，相关业务会被拆解成多个信息通道并行传输，在保证高效信息传输的同时也解决了高速消息队列在某些设置下很难保证对消息顺序性的问题。在常见的流式处理框架中，系统为了保证数据的快速投递，会将数据拆分成多个通道传输，但是在随后的多个通道合并处理过程中，很难在保证效率的情况下保证数据能够被顺序消费和处理。在工业场景中，由此引发的问题常常是不能被接受的。为此，需在系统中、全局顺序和局部顺序的平衡中保证清洗任务的高效运行。在具体的实现中，依赖钢铁行业知识和热轧线的工艺特点，将各工艺段拆分成多个通道，以保证各个通道中的消息数据。在各工艺段的数据联合处理中，结合专家知识调整各通道在高吞吐量下可能引发的时间戳到达时间不一致情况，以达到全局顺序的要求。实时清洗框架数据源接入如图5所示。

图5 实时清洗框架数据源接入Fig.5 Data Source Access to Real-time Cleaning Framework

4 典型热轧产线应用

4.1 实现功能

面对复杂的清洗需求，利用算子（Operator）在上述实时数据清洗框架中主要实现钢卷ID与生产数据实时绑定、粗轧正逆轧制映射、钢卷时空变换、数据特征提取四个功能。

4.1.1 钢卷ID与生产数据实时绑定

由于在产线数据中，钢卷ID的下发信号通道是由六个通道的ASCII码组成，其下发时间不与生产时间相关，且存在重复下发情况；钢卷ID如何与产线上得到的数据进行绑定是项目首先需要解决的问题。传统方法一般对钢卷ID下发后产生的所有相应数据进行存储，产线级数据采集量大，因此转变为对流入算子的生产数据进行标注 （即标注钢卷ID），以极大减少实时清洗平台的计算与存储量，提升钢卷ID绑定的效率，同时为后续其他功能腾挪计算空间。

4.1.2 粗轧正逆轧制映射

由于在物理层面，粗轧工序的正逆轧制存在往复行动，因此所有具有方向性的数据点、需要定位轧制位置（与后续时空变换更加相关）的数据点，均需要进行正逆轧制映射，以判断出轧制方向和出轧制的位置，即钢卷头/尾位置坐标。由于正逆轧制具有咬钢、轧制力、速度等多种指示信号，结合以上三者状态，即可判断正逆轧制与位置信息。

4.1.3 钢卷时空变换

无论粗轧或精轧，后续钢卷生产过程参数与质量的相关性分析均需要与钢卷位置进行关联，因此钢卷长度的时空变换是至关重要的功能。由于在生产过程中，钢坯产生形变，轧制完成的钢卷表面缺陷在形变前的加工参数溯源是主要难点。为此，首先以钢坯形变均匀为重要假设，根据拉速对钢坯行进长度进行累计，并在每个数据点明确已轧制长度，以便后续分析使用。

4.1.4 数据特征提取

大量数据中，数据的基本特征如平均值、最大值、最小值、标准差等均是常规的必需参数，但每一钢卷的上千条数据分别聚合计算的工作量与计算量过于巨大。因此，项目应用时在实时数据清洗平台上部署了数据特征提取算子，对常用数据特征进行滚动计算，即仅储存数个参数，在钢卷轧制完成后即可得出其特征值。由于标准差是一项必须获得全量数据方可精确计算的参数，基于实时计算的情况，采用迭代算法进行滚动计算，以近似实际标准差。

4.2 钢卷数字画像构建

钢卷在生产过程中相关联的数据不仅包含其ID、生产工艺参数、订单等信息，产线上的控制参数、实时测量的温度，甚至于能源表计系统测量的流量都是钢卷数字画像的一部分。在后续对钢卷的分析过程中，针对不同的主题，提取钢卷的相关数据是热轧生产及其相关应用的数据获取最优方式。为达到此目标，根据应用维度，从“人、机、料、法、环、测”六方面为钢卷建立了数字画像。除此六维度以外，钢卷数字画像的参数分为控制参数与实际参数两类；在针对钢卷的质量分析中，需要对比L2的模型计算下设值（即控制参数）与实际参数的区别。由于数据量较多且逻辑复杂，利用知识图谱技术进行钢卷数字画像构建，每个画像从加热炉至卷取结束，包括轧制力、弯辊力、轧辊速度、前滑后滑、温度、厚度、平直度、冷却水流量、窜辊位置的下设值及其实际值等，共约700个测点。

在数据通过Kafka接入后，4.1中的四个工艺段的生产数据实时绑定算子根据各测点位置将测点值与钢卷ID进行绑定，并存入存储层的时序数据库中。同时，由于各测点逻辑关系固定，在服务层根据其业务逻辑建立本体框架，使不断产生的数据可以根据本体库的结构与逻辑关系进行关联，进而生成知识图谱。对于上层应用层，在进行高级应用构建与分析时，根据知识图谱查询相关数据即可。本体库与知识图谱示意图如图6所示。

图6 本体库与知识图谱示意图Fig.6 Schematic Diagram for Ontology Base and Knowledge Mapping

4.3 实时数据应用

实时数据清洗框架的一大应用即将数据以10 ms左右的时间清洗后，进行产品在线初步分析。由于生产性质限制，当发生超出阈值或不符标准情况时，无法停线中断不合格产品的生产，但可在产线上对产品标注；同时，利用钢卷时空变换功能，对粗轧、精轧前6架的问题钢卷段进行标注。

4.4 应用效果

应用方案在项目中进行了实施和验证，效果如下：

（1）实时清洗框架成功承受住了热轧线上最小10 ms的数据采样频率，能在高速数据流的情况下完成数据清洗并保持系统稳定。

（2）钢卷ID与生产数据实时绑定能够有效去除非生产时的数据，同时结合时序数据库的压缩能力，大幅度减小数据存储量（某典型热轧项目中可以达到60 G原始数据到600 MB～1 G的减量效果），从而有效节约生产系统的存储空间，提高后续数据查询的效率。

（3）项目中对典型钢卷进行了数据准确性验证，所提出的实时清洗框架能够做到数据不丢失并与原始生产数据对应。

（4）在钢卷ID绑定后的数据上进行了业务相关的实时计算，为轧制稳定性分析、过程预警的应用场景提供了高质量的数据支持。

5 总结与展望

从热轧产线的数据特点出发，分析了热轧的数据特点，以及在数据清洗时所面临的难点。在此基础上，提出了一种新的实时大数据清洗框架，说明了框架的特点以及相应技术组件，并对热轧生产中的数据清洗需求进行了分析。同时，基于清洗后的产线数据，设计了一种热轧生产线的知识图谱建立方法，该方法综合考虑了产品、产线设备、质量分析等各个方面因素，以产品为中心打通并连接了多种数据，为数据应用提供了有效的数据基础。