Next Article in Journal
Gas Charging Characteristics and Controlling Factors in Tight Sandstone Reservoir of Xujiahe Formation, Sichuan Basin
Previous Article in Journal
Special Issue: “Petroleum Characterization and Bioprocesses: Numerical and Experimental Investigation”
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Resilient, Adaptive Industrial Self-X AI Pipeline with External AI Services: A Case Study on Electric Steelmaking

by
Petri Kannisto
1,*,
Zeinab Kargar
1,
Gorka Alvarez
2,
Bernd Kleimt
1 and
Asier Arteaga
3
1
VDEh-Betriebsforschungsinstitut (BFI), Sohnstrasse 69, 40237 Duesseldorf, Germany
2
Mondragon Sistemas de Información (MSI), 20500 Mondragon, Spain
3
Sidenor Aceros Especiales, 48970 Basauri, Spain
*
Author to whom correspondence should be addressed.
Submission received: 7 November 2024 / Revised: 7 December 2024 / Accepted: 13 December 2024 / Published: 16 December 2024
(This article belongs to the Section Advanced Digital and Other Processes)

Abstract

:
The introduction of Self-X capabilities into industrial control offers a tremendous potential in the development of resilient, adaptive production systems that enable circular economy. The Self-X capabilities, powered by Artificial Intelligence (AI), can monitor the production performance and enable timely reactions to problems or suboptimal operation. This paper presents a concept and prototype for Self-X AI in the process industry, particularly electric steelmaking with the EAF (Electric Arc Furnace). Due to complexity, EAF operation should be optimized with computational models, but these suffer from the fluctuating composition of the input materials, i.e., steel scrap. The fluctuation can be encountered with the Self-X method that monitors the performance, detecting anomalies and suggesting the re-training and re-initialization of models. These suggestions support the Human-in-the-Loop (HITL) in managing the AI models and in operating the production processes. The included Self-X capabilities are self-detection, self-evaluation, and self-repair. The prototype proves the concept, showing how the optimizing AI pipeline receives alarms from the external AI services if the performance degrades. The results of this work are encouraging and can be generalized, especially to processes that encounter drift related to the conditions, such as input materials for circular economy.

1. Introduction

1.1. Aims and Scope

Sustainability is a core development in industrial production, and this progress can be boosted with resilient Self-X systems powered by Artificial Intelligence (AI). Recently, the development of industrial systems has followed the concept of Cyber-Physical Systems (CPS), which aim to improve characteristics, such as integration, intelligence, reconfigurability, collaboration, and predictability [1]. The concept can be structured with the layered “5C” architecture, where the topmost layer, configuration, complements the whole with resilient Self-X functionality [2]. CPSs help in developing the industrial transformations in both Industry 4.0 and the subsequent Industry 5.0. The former focuses on the digitalization of production and builds primarily upon technology, whereas the latter considers the values of human-centeredness, resilience, and sustainability [3]. The concepts CPS, Industry 4.0, and Industry 5.0, each drive the technology and values of production systems towards more effortless management and control, which contribute to sustainability goals, powered by capabilities that take advantage of features that resemble human intelligence.
In addition to appropriate control, sustainability requires suitable production technologies, such as the Electric Arc Furnace (EAF) for circular economy in steelmaking. The EAF takes scrap as the input, which saves resources and, thus, protects the environment compared to virgin raw materials [4]. EAF, like other primary steelmaking processes, produces liquid steel that will be cast into the final product in the subsequent secondary metallurgy and casting processes [5] (pp. 61–62). EAF melts the scrap with the help of electrical energy and removes slag, aiming to control the concentration of unwanted substances. The scrap types vary in their chemical composition, which introduces a control element regarding the process. The scrap mix fed into the process affects the quality of the product, influencing the performance in downstream processes. Because there can be a variety of steel grades produced in a steel mill, each with different quality requirements, the operators should consider the target composition along with the composition of the scrap types, as well as their availability and price [6]. This control problem has a green aspect too, in addition to circular economy, because better quality control results in less rejection and, therefore, better efficiency. Even more, scrap will be a critical factor for steel decarbonization, and it is expected to suffer strong market pressure, so this approach is expected to help even more in those demanding conditions.
To enable resilient, AI-powered steelmaking with the EAF, this paper introduces a software system that integrates various decision support tools, such as optimization models, with a Self-X AI Pipeline, involving Human-in-the-Loop (HITL) and being supported by external Self-X AI services. Although the decision support tools have been tuned for the best performance, the outcome fluctuates. This can result from changes in the environment, such as different operating practices or the use of new scrap types. On the other hand, as more data are collected, they will cover more less-typical situations not included in the earlier data. Thus, for resilience, the system should self-detect, self-evaluate, and self-repair, recognizing when to re-train or regenerate the models for decision support. This objective is reached with a software system architecture to enable the performance monitoring of the models, supported with external AI services that notify about fluctuations. The external AI services include an Autonomic Manager, a connectivity method to the outside world familiar from Autonomic Computing [7]. Although the present work emphasizes AI, we argue that HITL provides essential human judgment for decision making. In the context of production planning, an earlier study suggests that such a judgment is important to guarantee the performance despite AI assistance [8].
The research question is,
What kind of software system design can realize a Self-X-capable AI Pipeline to offer optimization and resilience for industrial control, involving an HITL and external supporting Self-X AI services, considering the special requirements of electric steelmaking?

1.2. Related Work

In industrial production, the concept “Self-X”, building upon “cognitive” capabilities, aims for abilities where a system reflects its state and acts upon it with functionality, such as self-optimization, self-healing, and self-awareness [9]. Even though the Self-X concept was introduced decades ago, these “self” features are still being developed for industrial CPSs [10]. Along with CPSs, another key development is Digital Twins (DTs), which aim to capture the features and functionality of real-life components or systems and similarly receive advantages from cognitive features [11].
Earlier works have taken steps towards cognitive systems in the process industry. The Cognitive Automation Platform (CAP) enables cognitive sensing and control for a better perception of the situation, as exemplified for asphalt production [12]. Furthermore, CAP has been applied for DTs based on physical models in steelmaking and the related Internet of Things (IoT) [13]. Eventually, the core idea of CAP has been modeled into a reference architecture with data-driven aspects in the center of process control [14]. CAP has focused on the cognitive aspect, which is, according to [2], the fourth layer in the 5C architecture for CPS. From the viewpoint of this work, the cognitive aspect improves the perception about the process states and, thus, provides a tool for monitoring and control. However, there is no focus on resilience similar to the Self-X approach.
Additionally, a few other projects have delivered results towards cognition. COGNITWIN suggests a pipeline for DTs, adding a cognitive layer to help in interpreting process behavior [15]. Among the use cases, the approach has been applied to predictive maintenance in steel production [16]. The results of COGNITWIN cited above include a data-driven system for analytics and insights but not for resilience with Self-X. Additionally, some projects have researched cognitive aspects, but the related publications focus on methodology and prototypes, seemingly excluding architectural concepts related to cognition. These include at least COGNIPLANT [17] and HyperCOG, which suggests an architecture for communication but seems to exclude the connection with the related knowledge management based on the publications [18]. The non-existence of architectural aspects means that the works are related but lack the contribution that this work is seeking.
Subsequently, advances have arisen towards the fifth layer, “configuration”. This can occur with Self-X capabilities that involve an external, generic AI service, as proposed in a reference architecture [19]. This far, the reference architecture has been applied in aluminum production to receive external support for local AI services [20].
To conclude the related research and formulate the research gap, the existing works lack the combination of the following:
  • A Self-X optimization scheme for resilience;
  • Supportive external AI-based web services to maintain the performance of optimization models;
  • Steelmaking as the domain, even in the process industry; and
  • Software system architecture considerations.
The only exception to this research gap is [20], which, however, focuses on aluminum production instead of steelmaking. On the other hand, the article lacks a structured presentation with the reference architecture (presented in [19]).

1.3. Outline

Next, Section 2 elaborates the research method. Then, Section 3 describes the results: the requirements (Section 3.1), the optimization scheme (Section 3.2), the architecture to implement the scheme (Section 3.3), and a prototype system (Section 3.4). Finally, Section 4 discusses the results, followed by a conclusion in Section 5.

2. Research Method

The research method follows Design Science Research (DSR), where the approach is to design artifacts, such as software, to solve real-world problems. This can be seen to include three cycles: the relevance cycle associates the research to a real-life problem, the rigor cycle both applies existing scientific knowledge and contributes to this, and the design cycle forms the actual design work with the help of the two other cycles [21]. These are applied as follows (see Figure 1):
  • Relevance cycle includes, on a general level, all process industries with fluctuations in the production environment or raw materials. More specifically, the relevance includes the steel industry, focusing on the EAF. This is described in Section 1 and is further discussed in Section 4;
  • Rigor cycle has two viewpoints: the application of knowledge realizes from the development of AI-based methods to improve the resilience of the steelmaking process, whereas the contribution comes from the novelty of the approaches within this particular scope, including the novelty of the concept in general. These applications of knowledge for novel contributions occur in Section 3; however, the contributions are elaborated more thoroughly in Section 4;
  • Design cycle includes the development of the results, that is, the design of the Self-X AI Pipeline. It receives both support and restrictions from the other two cycles, as no research is valuable without relevance and rigor. The workflow from requirements to design and prototype is described in Section 3.
The development of the decision support models occurs in two stages. First, the models are created with offline data. Second, they are commissioned to the online system and then adapted and tuned as necessary.

3. Self-X AI Data Pipeline

This section describes the results for the design and rigor cycle of the research method. For rigor, technologies and methods are applied for novel results. For design, this section describes the essential artefacts, i.e., the design concept and the prototypes.
The design cycle includes the following components. Although these are numbered, any iterations occur as appropriate.
  • Recognize the detailed requirements (see Section 3.1);
  • Deliver a software system design (i.e., artefact) to conform to the requirements (see Section 3.2 for the concept and Section 3.3 for the component-level design);
  • Instantiate the design with prototypes and evaluate (or prove) the designed concept with experiments (see Section 3.4).

3.1. Requirements: Difficulty in Scrap Mixing

Scrap characterization aims to detect the chemical composition of the scrap types, enabling efficient scrap usage while ensuring the quality of the end products. This method is favored over laboratory measurements for a chemical analysis due to the high costs and small samples. The advantages are obvious considering the variety of scrap types and suppliers as well as the related fluctuation. Depending on the scrap origin, such as buildings and infrastructure or vehicles, or even the supplier, the chemical composition varies. Each scrap supplier can specialize in certain scrap types. Moreover, local conditions affect the task. Not only does the availability vary, but also the external conditions, such as the weather affecting the amount of water (e.g., rain or even snow).
In the use case plant, the scrap is sourced from three primary origins. Post-consumer scrap includes old materials recovered from the demolition of industrial buildings, machinery, and used cars. Pre-consumer scrap is generated as a by-product in industries that use steel as a raw material for their manufacturing processes. Additionally, internal recoveries consist of scrap produced within the steelmaking process itself, including operations in melt shops, rolling mills, and other processes within the premises [6].
The sorting and identification of incoming scrap are critical for maintaining process efficiency and ensuring product quality. Manual sorting and visual inspection are common methods where operators examine the scrap for contaminants such as rust, paint, or other undesirable materials. Different types of scrap, such as shredded, bundled, or heavy melting scrap, are identified based on their visual appearance. Magnetic sorting is another essential method, where magnets are used to separate ferrous (iron-based) materials from non-ferrous metals.
In the use case plant, each type of scrap is stored in designated, clearly labeled areas, such as “Scrap A” or “Scrap B”, to facilitate identification and retrieval. This organizational system ensures that the operators can quickly locate the required scrap type. However, challenges arise from the variability in the quality of incoming scrap, even from the same supplier. Additionally, the accidental mixing of scrap types in the yard can further complicate the sorting process. The final chemical composition of the scrap is determined during the scrap characterization phase with the dedicated mathematical model presented in this work. This critical step accounts for variations in scrap quality and ensures that the composition meets the specific requirements for steel production.
Further problems occur from the limitations in applying the results. Because the scrap composition can vary over time, even within one supplier, repeated re-generation is necessary. On the other hand, due to the variety and fluctuation, the results have practically no reusability between steel plants.
Scrap mix optimization is a subsequent step from scrap characterization. Once scrap characterization has resolved the chemical composition of the scrap types, scrap mix optimization is necessary to optimize scrap usage during operation. The availability and price of each scrap type varies. Typically, the cleaner the scrap type, the more expensive it is, but a cheap, non-clean scrap type can require more extensive processing to remove impurities. On the other hand, the energy required for melting is another characteristic. Furthermore, from the circular economy viewpoint, all available scrap types should be re-used. The combination of the dynamic scrap characterization and scrap mix optimization is especially relevant, as the historical weakness of scrap mix optimization has been the uncertainty in the input data.

3.2. Self-X Optimization Scheme

For resilient, efficient scrap mixing for the EAF, this work introduces a Self-X Data AI Pipeline concept (see Figure 2). The two main tools for optimization include scrap characterization and scrap mix optimization. The entire production chain should be supported by external AI services for external knowledge, including alarms to help the HITL recognize potential problems early, related to either the processes or the optimization models. An HITL is necessary to make the final decisions because the production system includes too much complexity and variability for full automation. The external services operate with production- and model-related metadata. These data come from a Metadata Generator that aggregates performance information. On the other hand, the logic to reason for alarms is based on rules and conditions determined by the production plant.
To enable adaptation and resilience, the Self-X abilities include self-detection, self-evaluation, and self-repair. Self-detection refers to the identification of deviations (or anomalies) in measurements, such as the chemical composition, temperature, and oxygen levels of the steel. Self-evaluation occurs after a deviation has been detected by involving the HITL to decide whether the deviation is actually an anomaly. Self-repair, finally, occurs if the HITL has acknowledged the anomaly. This will result in the retraining of the decision support and optimization models.
For external support in resilience, the scheme includes an Autonomic Manager to recognize unusual situations with the help of a rule engine. One of the critical alarms in a steel plant comes from non-conformities in the scrap types. The rule works as follows: if the deviation between the predicted and measured chemical analysis of the steel in the furnace exceeds a certain threshold and this deviation occurs over several consecutive heats, an alarm is triggered. While the Autonomic Manager is a core part of the concept, the component itself is out of scope in this work. Regarding terminology, the name “Autonomic Manager” comes from autonomic computing [7].
The Autonomic Manager needs performance-related metadata to operate, which is the reason for the Metadata Generator to exist. The Metadata Generator calculates various key figures, aggregating the data about production and performance. These key figures reveal how the production processes and optimization models perform, enabling the detection of deviations and, thus, potential issues. A degraded performance can hint that the models should be retrained or the operation should otherwise be revised.
The optimization models for scrap characterization and scrap mix optimization could potentially be developed with multiple methods. In this work, scrap characterization builds upon statistical multi-linear regression, whereas scrap mix optimization is modelled as a linear optimization problem. The internals of these models are out of scope in this work, which focuses on the AI pipeline concept.

3.3. AI Pipeline Architecture

3.3.1. Reference Architecture

For a structured approach, this work builds upon the reference architecture for Self-X AI systems introduced in [19]. This architecture is based on the state-of-the-art evolution of industrial system architectures: “the automation pyramid” from ANSI/ISA-95 [22] as well as the newer Reference Architecture Model Industrie 4.0 (RAMI 4.0 [23]), which includes the levels of the pyramid.
Furthermore, the reference architecture aims to fulfil the vision of autonomic computing with the MAPE-K loop. The MAPE-K includes four stages: monitor (M), analyze (A), plan (P), and execute (E), and all these are associated with related knowledge (K) [7]. In the vision, each autonomic component executes the MAPE-K on a “managed element” and communicates with other components and humans via their dedicated Autonomic Managers.
This work considers a high-level subset of the reference architecture, including the following main layers from bottom to top:
  • Data ingestion and transformation are the tasks necessary to retrieve and refine data for exploitation in other components, such as optimization and metadata generation;
  • Data brokering and persistence includes the components to either deliver or store the data;
  • Data processing comprises the activities where added value is generated from the data;
  • Meta layer includes the metadata to be communicated between the plant and the Autonomic Manager;
  • Autonomic Manager offers external AI services to the plant to support the Self-X scheme and connect to the external world;
  • Applications include any applications or Graphical User Interfaces (GUIs) for the end users.

3.3.2. Components

To design a self-X system following the requirements, appropriate components were designed and positioned into the reference architecture; see Figure 3. The following paragraphs explain the tasks of each component.
Raw data sources refer to the sources of production-related data. These can be, for instance, databases, other data servers, IoT sensors, or any other data sources.
Data refinements tools ensure that the production-related data has a sufficient quality for the components to exploit. The refinement can include methods, such as outlier detection and interpolation in the case of missing values.
Data storage is within the center of the plant-wide data-driven scheme. It enables data sharing between the various components. These data include not only data refined from production-related systems but also the results calculated by the components, such as optimization models.
Workflow management tools ensure functional interoperability between the various components. Even if the semantics of data contents were commonly supported in all components, the functional aspect is necessary to ensure that the workflows and activities are completed fully in the correct sequence and that no important events are missed. For example, a detected anomaly will trigger corrective actions, and the finishing of a process heat can start a data analysis based on measured data. In distributed industrial systems, such service orchestration and choreographing is among the main problems [24].
Data processing layer includes any models and algorithms for decision support or process optimization for HITL. Conceptually, these models can include any functionality for any process or production-related aspect, not limited to EAF in steelmaking. The name data processing layer highlights that the models have a data-driven nature.
Metadata Generator calculates various key figures, aggregating the production data. These key figures reveal how the production process performs generally, enabling the detection of deviations and, thus, potential issues in the performance of the optimization models.
Client for external AI services integrates the plant infrastructure with the external AI service. It will share the results from the Metadata Generator and, in return, receive information about deviations.
External AI services refer especially to the Autonomic Manager that provides a service to notify about deviations in the performance of production and the related optimization. The AI service can execute a range of AI methods to reveal deviations in the metadata. In MAPE-K, the Autonomic Manager is the interface of the autonomic component (i.e., the production plant in this context) with the outside world [7]. The Application Programming Interfaces (APIs) provide a means to both feed the data into the Autonomic Manager and receive results (that is, detected deviations) generated from the data.
HITL GUIs enable the operators and data scientists to interact with the system locally within the plant. Because the processes within the plant are too complex and stochastic for a full automation, the HITL enables a human element in decision-making, and the optimization models and anomaly detection are merely supportive tools that help in maintaining and sharing production-related knowledge.

3.3.3. Interaction with External AI Services

Figure 4 illustrates the workflow with external AI services. The AI Data Pipeline (orchestrated by workflow management tools) shares its metadata for the external AI services to observe. These generate one or more alarms, and the AI Data Pipeline delivers these to the GUI of the data scientist (i.e., HITL). Based on the results and performance data, the data scientist decides to either confirm or reject the alarm. This decision is saved and made available to the AI Data Pipeline. Then, the pipeline will refresh the related optimization model.
The workflow is general within the system and even across use cases and domains. That is, the related external AI service can be either an Autonomic Manager or the associated AI methods, and the model can be a Metadata Generator or scrap characterization. However, depending on the involvement of HITL, the degree of automation can vary. For example, although AI Data Pipeline refreshes the models, the data scientist can make the decision as well, depending on how the system has been designed. Finally, the whole can be tailored based on the case-specific needs, but the main steps of generating alarms externally, based on metadata, and then reacting to the alarms will remain the same.
It is notable that, although the external AI services provide support to the HITL, AI Data Pipeline can still operate independently. From the viewpoint of maintaining the local models, this means that the HITL can decide to refresh the models, regardless of if there are related alarms or not.

3.4. Prototype and Experiments

3.4.1. Architecture Implemented

Table 1 shows the implementation technology of each component of the prototype, and Figure 5 shows the relationship and connection of the components. Each technology is referred to in the following paragraphs. The whole is orchestrated with two main technologies: Node-RED to connect the components and ensure the workflows required for functional interoperability (as referred to in data brokering and persistence layer) and Docker for the platform, providing Infrastructure-as-Code to manage the components and services more easily.
Applications. This layer contains the HITL GUIs. These all have been installed into a web application platform. For scrap characterization and scrap mix optimization, both their GUIs are pure Hypertext Markup Language (HTML) and JavaScript, and any diagrams are constructed with ChartJS (“JS” referring to JavaScript). For the display of measurement value trends (process data view) and alarms (alarms view), the GUIs build upon Grafana and Angular.
Autonomic Manager. The internals of this layer are out of scope now that this work focuses on the AI Data Pipeline within the context of one process plant. From this viewpoint, the Autonomic Manager and AI methods are “black boxes”. However, the Autonomic Manager has been implemented as a rule engine based on Apache Airflow and AI methods on D2Lab. The analysis behind modeling the rules has been described in [37] (p. 17).
Meta. This layer includes the client that is necessary to communicate with the APIs of the Autonomic Manager. For the API in, the client communicates by sending FIWARE content with a connector within the Node-RED environment. For the API out, which supplies messages via Apache Kafka, another Node-RED connector is applied.
Data processing. In this layer, scrap characterization and scrap mix optimization have been developed in Python. These provide an API implemented in Flask, based on Hypertext Transfer Protocol (HTTP) and JavaScript Object Notation (JSON). The Metadata Generator has been implemented as a pure Python application that connects with the rest of the system via a MySQL database (“SQL” referring to Structured Query Language).
Data brokering and persistence. In this layer, the data brokering occurs via Node-RED, which orchestrates the interaction of the various components within the AI Data Pipeline. On the other hand, any data, either generated or consumed by the components, is stored in either a MySQL database or InfluxDB timeseries database.
Data ingestion and transformation. In this work, data ingestion involves the retrieval of process data from a database operated within the process plant, which is MySQL in this case. On the other hand, the raw data are unusable as such due to outliers that must be filtered. Without filtering, the models would be corrupted by clear numeric errors that sometimes appear in any sensor-collected data. Any preprocessing occurs in Node-RED.
Hardware, infrastructure, and networking. While not a part of the architecture design, software requires hardware and computational capacity to operate. This work focuses on the actual optimization with models and algorithms instead of Internet of Things (IoT) or similar hardware-related constraints. Thus, the software operates in a conventional server system, and the components are deployed as containers. Although the models and algorithms necessitate non-trivial computational operations and data processing, this happens in the background, and the dynamics of the productions batches is slow. Process operation does not require sub-second or normally even second-scale response times. On the other hand, no restrictions have been encountered in network capacity due to the slow pace of operation, which means that the message traffic is far from exceeding the capacity of the state-of-the-art wired internet.
Technology choices. The technologies have been chosen based on earlier experiences. This means that, for instance, as there are many relational databases but MySQL works and the developers know it, there is no reason to change. MongoDB [38] is considered a non-suitable alternative due to its license, which adds difficulty in applications with closed-source components (such as proprietary optimization algorithms). On the other hand, Node-RED provides a large ecosystem of tools to orchestrate the components. FIWARE was chosen by the project consortium, which exceeds this steelmaking use case. The other tools, such as Flask and ChartJS, had been applied earlier, and there was no reason to re-implement the software with another tool.

3.4.2. Experimental Evaluation

To validate the operation of the AI Pipeline and the related interplay with the external services, experiments have been committed. This section summarizes how the external AI services, i.e., AI methods and Autonomic Manager, generate alarms for AI Data Pipeline based on performance-related metadata. Then, the data scientist (HITL) will react to these alarms. If an alarm is confirmed, the related optimization-related model will be retrained, which closes the Self-X sequence illustrated in Figure 4. That is, the following workflow occurs (each figure explained more thoroughly afterwards):
  • The data scientist can view the alarms of the external AI service, either originating from the AI methods behind the Autonomic Manager (Figure 6 and Figure 7) or from Autonomic Manager itself (Figure 8 and Figure 9);
  • As an alarm occurs, the data scientist runs scrap characterization to check if the new characterization results seem to provide a better performance in the future (Figure 10);
  • Based on scrap characterization results, the data scientist runs another scrap mix optimization to assist in operating the EAF (Figure 11).
Alarms from AI methods. The external AI methods apply AI-driven monitoring methods to track certain parameter values and generate alarms to notify about deviations. The values are related to the liquid steel composition in the furnace. Once the threshold for a deviation is exceeded, the AI method generates an alarm to signal potential problems.
The alarms cover two aspects: the pipeline stages and alarm categories (Figure 6). First, the stage-based separation is possible thanks to the metadata that cover the various stages of the AI Data Pipeline, from data input and transformation to exploration and model training. Second, considering categories, the AI methods generate two distinct types of alarms: the Peak Alarm and the Stability Alarm. Figure 7 illustrates these alarms within the transformation stage, specifically in relation to the cumulative amount of secondary oxygen blown into the furnace. The Peak Alarm is triggered by a sudden, significant spike in the data. That is, the data surpass a predefined threshold, indicating an unusual fluctuation that may require attention. However, not all peaks in the graph trigger a Peak Alarm. This is because the alarm rules are specifically designed to avoid false positives by applying only to peaks that exceed both a magnitude threshold and a duration threshold. Additionally, time periods with no production will not generate an alarm either. In contrast, the Stability Alarm is activated when there are shifts in the data trend, signaling changes in overall data stability. Upon examining the raw data, these alarms are validated as accurate indicators of these fluctuations.
Alarms from Autonomic Manager. To detect deviations in the metadata, the Autonomic Manager generates alarms based on predefined rules that are applied to metadata at the various stages of the AI Data Pipeline. For instance, a rule can generate an alarm when a commonly used scrap type is not used at all or if the data include unexpected missing values (concretely, “not a number”). The alarms are further categorized into types, illustrated in Figure 8. Additionally, the GUI shows the alarms in a tabular view for more details for the HITL (see Figure 9). Together, the high-level categorization and the details provide the HITL with solid tools for decision support.
As an example for the rules inside the Autonomic Manager, if an alarm is triggered by model accuracy degradation, this indicates a systematic anomaly rather than a punctual one. For such cases, there is a rule for the threshold of the Mean Absolute Error (MAE) between the predicted and measured chemical analysis of the liquid steel in the furnace over multiple heats. Such cases suggest a potential issue related to scrap-type properties, prompting further investigation via scrap characterization; see Figure 10.
In these situations, HITL feedback enables a comparison between the old and new chemical compositions of the scrap types. If the HITL accepts the new results (by pressing the “Save results” button in Figure 10), the alarm is validated and the results are saved. Consequently, the AI models within the pipeline are retrained to maintain an alignment between the models and the updated scrap characterization.
Following this step, the scrap mix optimizer updates the scrap information with the latest results and recommends the optimal steel recipe (see Figure 11). This recommendation considers the target steel grade, scrap availability, and cost, aiming to provide the most efficient scrap mix to load into the furnace. Although an up-to-date scrap optimization model should outperform human capabilities in most cases, the HITL will use their judgment to decide to which degree they follow the recommendation.
As shown in this subsection, the Self-X AI Data Pipeline concept is operational. It orchestrates the various components, sharing production-related metadata with the external supporting AI services. Then, the external services generate alarms to support the HITL in maintaining the models and making decisions.
Outlook: HITL Significance. HITL’s intervention helps reducing the number of false alarms and unnecessary interruptions, ensuring that only valid alarms lead to corrective actions. For example, if an alarm is triggered due to elevated copper levels in a heat intended for stainless steel—a grade that can tolerate a higher copper content—the operator can recognize this alarm as false and decline it. If certain scrap materials are used exclusively for certain heats, the operator can use their knowledge of the context to avoid unnecessary alarms. In addition, the scrap mix recommendations generated by the system must be validated by HITL operators to match scrap availability in real time. Inconsistencies between the system data and the actual state of the scrap yard could lead to suggestions for unavailable materials, resulting in inefficient scrap management and potential production issues. Without human oversight, the system could trigger unwarranted alarms, wasting resources and production time investigating non-critical issues.
Thus, HITL is clearly needed in the operation, regardless of the supportive AI tools. The AI and HITL support each other, which aligns well with the human-centric aspect of Industry 5.0.

4. Discussion

This section considers the rigor part of Design Science Research. That is, the text elaborates what the results mean and how they contribute to the state of art. Additionally, this section further elaborates the relevance aspect from the viewpoint of the application domain.

4.1. Assessment of Results

Novelty. This study brings novelty regarding the application of AI technologies in industrial production and, especially, the process industry through Autonomic Computing [7]. As far as is known, the earlier studies lack a respective design and prototype with both plant-wide and cross-value-chain AI solutions with external AI services. In steelmaking, no such advances are have been seen before.
Originality. Originality comes in the form of new understanding for the design of AI systems. This applies to the process industry in general but, especially, to steel industry. On the other hand, the viewpoint of this study is green transformation, a conventionally developing area in heavy industries [39].
Significance. The significance of the work stems from the Self-X AI Pipeline that applies novel methods to exploit knowledge for green industrial production. The methods include AI methods not only executed within a single plant but also in a cross-value-chain scope within the Autonomic Manager, the external AI service. The results contribute to the goals of both Industry 4.0 with AI (novel information technology and digitalization [40]) as well as Industry 5.0 (sustainability from circular economy and reduced resource consumption, human factors with HITL, and resilience [41]). On the other hand, the developed system is an advance towards the highest level of cyber-physical developments in 5C architecture, that is, from cognition to configuration through the Self-X capabilities [2]. In the global scope, the work contributes to advances towards green steelmaking by reusing existing scrap and supporting the operators towards decisions with a lower environmental load. This is important, especially considering the heavy, energy-intensive nature of steel industry. Furthermore, it can be argued that the proposed system helps the HITL in learning new tools and methods (which are inevitable in the ongoing digitalization of the steel industry [42]) by providing vital decision support. The advantages of the suggested approach apply most likely to steel-related production processes and problems in general, such as model-based EAF state monitoring or the optimization of Continuous Casting.

4.2. Limitations

A clear limitation is that the research method is inductive, generalizing results related to a single steel plant. Therefore, it can be argued that the differences between plants could limit applicability. Still, all EAFs in the world follow the same operational principles. Therefore, plants can be expected to face fluctuation in the input materials, and the performance of each furnace likely changes, even between maintenance breaks.
Another inductive assumption is that the Self-X method can be generalized within the process industry. The same methods might not work in all industries. In general, however, many process industries face fluctuation in raw materials and, therefore, necessitate adaptation to maintain performance. This should include not only metallurgy but any production process with natural or organic ingredients, such as food, pulp and paper, or minerals. On the other hand, the overall Self-X AI concept has been developed in a collaborative research project between aluminum [20], pharmaceutical, and asphalt industries, which hints that the approach is generic.

4.3. Implications of Open Source

This work builds upon multiple open-source products that can either help in forming a software ecosystem or readily offer such, helping in the ongoing digitalization of production systems. The exploited open-source products include, for example, Python [33], Node-RED [32], Grafana [25], Apache Kafka [31], and Apache Airflow [28]. The categories of open-source products for IoT systems are numerous, including, but not limited to, databases, communication frameworks, system integration and orchestration tools, IoT platforms, and visualization tools [43]. Open-source tools can be the basis for a full smart factory architecture [44]. Still, open IoT tools are not replacing conventional software systems but rather complementing these, facilitating the transition towards Industry 4.0 [45].
Regarding licensing, the open-source approach can affect how the system can deliver commercial benefits. The so-called copyleft licenses, such as GNU’s Not Unix General Public License 3 (GNU GPL 3 [46]) and its variants, require that any derivatives are open source too if distributed. In some commercial schemes, this is not desired. However, some open-source licenses, such as MIT (Massachusetts Institute of Technology [47]) and Berkeley Software Distribution 3 (BSD-3 [48]) and its variants, permit closed-source distributions. One must consider for each product whether open source is desired. On the one hand, the development of the software can benefit from the open community, and openness can increase the trust of the users. On the other hand, companies often seek exclusive benefit from their proprietary special expertise, such as optimization algorithms.
This work does not consider long-term aspects regarding the operation of the software system, especially as the system includes open-source components. The future topics could include this now that software maintenance is, inevitably, an essential factor in lifecycle costs.

4.4. Further Research

Various items remain for future research within the steel domain. The Self-X AI Data Pipeline design could be applied for more use cases in steelmaking, such as models that estimate the EAF state [6]. On the other hand, the approach is undoubtedly applicable for more processes, including, but not limited to, the Blast Furnace, the methods for secondary metallurgy, and Continuous Casting.
Considering steel industry, it can be argued that the results help to face current challenges and needs. These include, at least, increasing circularity, decarbonization, the support for improving employee skills, and adaptation to the continuously changing business environment [49].
From the organizational viewpoint, the optimization scheme of this work is a cross-organizational distributed system, which stresses the need for interoperability in its various levels and aspects. Each of these aspects could be studied further to ensure the connectivity of the tools. There are many eveled interoperability models, for instance, the domain-agnostic European Interoperability Framework (EIF) [50]. Earlier, EIF has already been mapped with the process industry, indicating development needs, especially in semantic and organizational interoperability [51]. Semantic interoperability is often reached with common information models; however, this reduces the room for flexibility. In addition to common information models, semantic interoperability can be contributed to with ontologies that facilitate the mapping of heterogeneous models [52]. The next level is functional interoperability, a subset of organizational interoperability. This is concerned with sequences and workflows and can be facilitated with choreography modeling to enable common agreements [53]. Choreographing is especially important in microservice environments, which often lack a centralized orchestrator [54]. To ensure interoperability in organizational aspects, it is possible to use independent mediators within the ecosystem [55]. Finally, despite our focus on process industry, the interoperability efforts could emphasize cross-domain schemes. Such schemes facilitate innovation by crossing the conventional borders [56]. This would facilitate undertaking the goals of Industry 5.0, which aim at societal and social values rather than mere technology.
Regarding technology, multiple potential research topics exist. In the prototype implementation, the plant-wide part could build upon a standard API (such as Open Platform Communications Unified Architecture or OPC UA [57] and Next-Generation Service Interfaces Linked Data or NGSI-LD [58]) for an easier integration to external systems. On the other hand, the system could build upon event-driven, message-broker-based integration for more flexibility and scalability over the levels of the automation pyramid (similar to [59]). Finally, the concept of International Dataspaces (IDSs [60]) and Gaia-X [61] could be applied to ensure that the data owner preserves the rights for its data, i.e., to preserve data autonomy and sovereignty, as the data are shared from the production plant to external services.

5. Conclusions

This article introduces a software system architecture to include a Self-X-capable AI Pipeline into industrial processes and, especially, electric steelmaking with the EAF. Following the Design Science Research method, the work begins with an explanation of the context, both generally and within the application domain (Section 1), elaborating case-specific requirements (Section 3.1), creating an architecture concept (Section 3.2 and Section 3.3), instantiating the architecture with a prototype (Section 3.4), and, finally, discussing the results to indicate the rigor and relevance of the results (Section 4).
The AI Pipeline enables resilience and self-adaptation (self-detect, self-evaluate, and self-repair) and connects with external AI services that support the maintenance of these Self-X capabilities and the related models. To prove the concept, optimization models were connected with the AI Pipeline along with online data from an EAF. The results suggest that the concept can help in maintaining optimization models, providing decision support to human employees. This was indicated with the system of local and external software components. The local system generates performance-related metadata, which are then shared with the supportive external AI services. These services will, then, notify the local system about deviations, suggesting model re-generation as relevant. However, the HITL always makes the final decision.
The concept contributes to the goals of Industry 5.0: resilience through improved feedback for maintenance, environmental values by reducing resource consumption and applying circularity, and human factors by supporting the expertise and operation of the HITL with an AI-based support system. On the other hand, the pipeline is an advance from cognitive systems to self-configuration, which is the topmost level and, thus, the most intelligent aspect of CPSs.

Author Contributions

Conceptualization, P.K., B.K. and Z.K.; methodology, P.K., B.K. and Z.K.; software, Z.K., G.A. and P.K.; validation, Z.K. and A.A.; formal analysis, Z.K.; investigation, Z.K.; resources, B.K. and A.A.; data curation, Z.K. and G.A.; writing—original draft preparation, P.K. and Z.K.; writing—review and editing, P.K., Z.K., B.K., A.A. and G.A.; visualization, Z.K., P.K. and G.A.; supervision, B.K. and A.A.; project administration, Z.K. and B.K.; funding acquisition, B.K. and A.A. All authors have read and agreed to the published version of the manuscript.

Funding

This work has been supported by the project “self-X Artificial Intelligence for European Process Industry digital transformation” (s-X-AIPI), which has received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement No. 101058715. Views and opinions expressed are, however, those of the authors only and do not necessarily reflect those of the European Union. Neither the European Union nor the granting authority can be held responsible for them.

Data Availability Statement

The datasets presented in this article are not readily available due to the business-sensitive nature.

Acknowledgments

The authors want to thank the colleagues, especially Waldemar Krieger, Vera Peiss, Akhilesh Chandgude, and Norbert Holzknecht, at VDEh-Betriebsforschungsinstitut, and Peter Craamer and Joseba Egia, at Mondragon Sistemas de Información, for their contributions, insights, and help. Additional special thanks go to the operator Sidenor Aceros Especiales (especially to Diana Mier Vasallo) for providing the use case, the related data, and additional funding; Engineering Ingegneria Informatica for developing the Autonomic Manager; Nissatech Innovation Centre for authoring the associated AI method; and Cartif for coordinating the project. Naturally, the authors are grateful to all partners involved in the s-X-AIPI project.

Conflicts of Interest

Authors Petri Kannisto, Zeinab Kargar, and Bernd Kleimt were employed by the company VDEh-Betriebsforschungsinstitut (BFI). Author Gorka Alvarez was employed by the company Mondragon Sistemas de Información (MSI). Author Asier Arteaga was employed by the company Sidenor Aceros Especiales. All the authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest. The authors declare that this study received funding from European Union. The funder was not involved in the study design; the collection, analysis, or interpretation of data; the writing of this article; or the decision to submit it for publication.

Abbreviations

The following abbreviations are used in this manuscript:
5C5C architecture for Cyber-Physical Systems
AIArtificial Intelligence
APIApplication Programming Interface
BSDBerkeley Software Distribution
CAPCognitive Automation Platform
CPSCyber-Physical System
DSRDesign Science Research
DTDigital Twin
EAFElectric Arc Furnace
EIFEuropean Interoperability Framework
GNU GPLGNU’s Not Unix General Public License
GUIGraphical User Interface
HITLHuman in the Loop
HTMLHypertext Markup Language
HTTPHypertext Transfer Protocol
IDSInternational Data Spaces
IoTInternet of Things
JSJavaScript
JSONJavaScript Object Notation
MAEMean Absolute Error
MAPE-KMonitor, Analyze, Plan, and Execute; Knowledge
MITMassachusetts Institute of Technology
NGSI-LDNext-Generation Service Interfaces Linked Data
OPC UAOpen Platform Communications Unified Architecture
SQLStructured Query Language

References

  1. Napoleone, A.; Macchi, M.; Pozzetti, A. A review on the characteristics of cyber-physical systems for the future smart factories. J. Manuf. Syst. 2020, 54, 305–335. [Google Scholar] [CrossRef]
  2. Lee, J.; Bagheri, B.; Kao, H.A. A Cyber-Physical Systems architecture for Industry 4.0-based manufacturing systems. Manuf. Lett. 2015, 3, 18–23. [Google Scholar] [CrossRef]
  3. Xu, X.; Lu, Y.; Vogel-Heuser, B.; Wang, L. Industry 4.0 and Industry 5.0—Inception, conception and perception. J. Manuf. Syst. 2021, 61, 530–535. [Google Scholar] [CrossRef]
  4. Metal Recycling Factsheet. 2020. Available online: https://circulareconomy.europa.eu/platform/sites/default/files/euric_metal_recycling_factsheet.pdf (accessed on 23 October 2024).
  5. Bartos, R.; Brockmann, S.; Fandrich, R.; Endemann, G.; Heinzel, S.; Keul, C. Steel Manual; Stahlinstitut VDEh: Dusseldorf, Germany, 2015. [Google Scholar]
  6. Kleimt, B.; Krieger, W.; Mier Vasallo, D.; Arteaga Ayarza, A.; Unamuno Iriondo, I. Model-Based Decision Support System for Electric Arc Furnace (EAF) Online Monitoring and Control. Metals 2023, 13, 1332. [Google Scholar] [CrossRef]
  7. Kephart, J.; Chess, D. The vision of autonomic computing. Computer 2003, 36, 41–50. [Google Scholar] [CrossRef]
  8. Roblek, M.; Kern, T.; Andrašec, E.K.; Brezavšček, A. Comparative Analysis of Human and Artificial Intelligence Planning in Production Processes. Processes 2024, 12, 2300. [Google Scholar] [CrossRef]
  9. Sanz, R.; López, I.; Bermejo, J.; Chinchilla, R.; Conde, R. Self-X: The Control Within. IFAC Proc. Vol. 2005, 38, 179–184. [Google Scholar] [CrossRef]
  10. Barari, A.; de Sales Guerra Tsuzuki, M.; Cohen, Y.; Macchi, M. Editorial: Intelligent manufacturing systems towards industry 4.0 era. J. Intell. Manuf. 2021, 32, 1793–1796. [Google Scholar] [CrossRef]
  11. Al Haj Ali, J.; Gaffinet, B.; Panetto, H.; Naudet, Y. Cognitive systems and interoperability in the enterprise: A systematic literature review. Annu. Rev. Control 2024, 57, 100954. [Google Scholar] [CrossRef]
  12. Vega, C.; Gómez, D.; Reñones, A. Cognitive Solutions in Process Industry: H2020 CAPRI Project. In Proceedings of the 3rd International Conference on Innovative Intelligent Industrial Production and Logistics—ETCIIM, Valletta, Malta, 24–26 October 2022; pp. 267–278. [Google Scholar] [CrossRef]
  13. Nölle, C.; Arteaga, A.; Egia, J.; Salis, A.; De Luca, G.; Holzknecht, N. Digital Twin-enabled Application Architecture for the Process Industry. In Proceedings of the 3rd International Conference on Innovative Intelligent Industrial Production and Logistics—ETCIIM, Valletta, Malta, 24–26 October 2022; pp. 255–266. [Google Scholar] [CrossRef]
  14. Salis, A.; Marguglio, A.; De Luca, G.; Razzetti, S.; Quadrini, W.; Gusmeroli, S. An Edge-Cloud based Reference Architecture to support cognitive solutions in Process Industry. Procedia Comput. Sci. 2023, 217, 20–30. [Google Scholar] [CrossRef]
  15. Johansen, S.T.; Unal, P.; Albayrak, Ö.; Ikonen, E.; Linnestad, K.J.; Jawahery, S.; Srivastava, A.K.; Løvfall, B.T. Hybrid and cognitive digital twins for the process industry. Open Eng. 2023, 13, 20220418. [Google Scholar] [CrossRef]
  16. Unal, P.; Albayrak, Ö.; Jomâa, M.; Berre, A.J. Data-Driven Artificial Intelligence and Predictive Analytics for the Maintenance of Industrial Machinery with Hybrid and Cognitive Digital Twins. In Technologies and Applications for Big Data Value; Curry, E., Auer, S., Berre, A.J., Metzger, A., Perez, M.S., Zillner, S., Eds.; Springer International Publishing: Cham, Switzerland, 2022; pp. 299–319. [Google Scholar] [CrossRef]
  17. Luftensteiner, S.; Mayr, M.; Chasparis, G.; Pichler, M. AVUBDI: A Versatile Usable Big Data Infrastructure and Its Monitoring Approaches for Process Industry. Front. Chem. Eng. 2021, 3, 665545. [Google Scholar] [CrossRef]
  18. Huertos, F.J.; Masenlle, M.; Chicote, B.; Ayuso, M. Hyperconnected Architecture for High Cognitive Production Plants. Procedia CIRP 2021, 104, 1692–1697. [Google Scholar] [CrossRef]
  19. Quadrini, W.; Cuzzola, F.A.; Fumagalli, L.; Taisch, M.; De Luca, G.; Calderaro, M.; Marzano, M.G.; Marguglio, A. A reference architecture to implement Self-X capability in an industrial software architecture. Procedia Comput. Sci. 2024, 232, 446–455. [Google Scholar] [CrossRef]
  20. Angosto Artigues, R.; Gregores Coto, A.; Torrez Herrera, J.; Lou Tomás, F.; Verardi, S.; Marzano, M.; Fernandez Martinez, A. An AI-Driven User-Centric Framework reinforced by Autonomic Computing: A case study in the Aluminium sector. In Human Interaction and Emerging Technologies (IHIET 2024); AHFE International: Orlando, FL, USA, 2024; pp. 196–206. [Google Scholar] [CrossRef]
  21. Hevner, A.R. A three cycle view of design science research. Scand. J. Inf. Syst. 2007, 19, 87–92. [Google Scholar]
  22. International Society of Automation. ANSI/ISA-95.00.01 Enterprise-Control System Integration: Part 1: Models and Terminology; International Society of Automation: Research Triangle Park, NC, USA, 2010. [Google Scholar]
  23. Adolphs, P.; Bedenbender, H.; Dirzus, D.; Ehlich, M.; Epple, U.; Hankel, M.; Heidel, R.; Hoffmeister, M.; Huhle, H.; Kärcher, B.; et al. Reference Architecture Model Industrie 4.0 (RAMI4.0). VDI Verein Deutscher Ingenieure e.V./ZVEI—German Electrical and Electronic Manufacturers’ Association. 2015. Available online: https://www.zvei.org/fileadmin/user_upload/Presse_und_Medien/Publikationen/2016/januar/GMA_Status_Report__Reference_Archtitecture_Model_Industrie_4.0__RAMI_4.0_/GMA-Status-Report-RAMI-40-July-2015.pdf (accessed on 14 August 2024).
  24. Wiesmayr, B.; Zoitl, A.; Hästbacka, D. Modeling Service Choreographies and Collaborative Tasks for Autonomous Mixed-Fleet Systems. In Proceedings of the ACM/IEEE 27th International Conference on Model Driven Engineering Languages and Systems, MODELS Companion ’24, Linz, Austria, 22–27 September 2024; pp. 234–244. [Google Scholar] [CrossRef]
  25. Grafana. 2024. Available online: https://grafana.com/ (accessed on 3 December 2024).
  26. Angular. 2024. Available online: https://angular.dev/ (accessed on 3 December 2024).
  27. Chart.js. 2024. Available online: https://www.chartjs.org/ (accessed on 3 December 2024).
  28. Apache Airflow. 2024. Available online: https://airflow.apache.org/ (accessed on 3 December 2024).
  29. D2Lab. 2024. Available online: https://d2lab.nissatech.com/ (accessed on 3 December 2024).
  30. Orion Context Broker. 2024. Available online: https://fiware-orion.readthedocs.io/en/master/ (accessed on 3 December 2024).
  31. Apache Kafka. 2024. Available online: https://kafka.apache.org/ (accessed on 3 December 2024).
  32. Node-RED. 2024. Available online: https://nodered.org/ (accessed on 3 December 2024).
  33. Python. 2024. Available online: https://python.org/ (accessed on 3 December 2024).
  34. Flask Documentation. 2024. Available online: https://flask.palletsprojects.com/ (accessed on 3 December 2024).
  35. MySQL. 2024. Available online: https://www.mysql.com/ (accessed on 3 December 2024).
  36. InfluxDB Time Series Data Platform. 2024. Available online: https://www.influxdata.com/ (accessed on 3 December 2024).
  37. Calderaro, M.; De Luca, G.; Marzano, M.; Fernandez Martinez, A.; Fink, E.; Gomez, D.; Galende, M.; Mier, D.; Kargar, Z.; Egia, J.; et al. D4.1 Autonomic Managers for Data in Motion and Humans Support in AI Solutions—Initial Version. 2023. Available online: https://s-x-aipi-project.eu/s/D41-Autonomic-Managers-for-Data-in-Motion.pdf (accessed on 23 October 2024).
  38. MongoDB. 2024. Available online: https://www.mongodb.com/ (accessed on 5 December 2024).
  39. Johnson, O.W.; Mete, G.; Sanchez, F.; Shawoo, Z.; Talebian, S. Toward Climate-Neutral Heavy Industry: An Analysis of Industry Transition Roadmaps. Appl. Sci. 2021, 11, 5375. [Google Scholar] [CrossRef]
  40. Peres, R.S.; Jia, X.; Lee, J.; Sun, K.; Colombo, A.W.; Barata, J. Industrial Artificial Intelligence in Industry 4.0—Systematic Review, Challenges and Outlook. IEEE Access 2020, 8, 220121–220139. [Google Scholar] [CrossRef]
  41. Maddikunta, P.K.R.; Pham, Q.V.; B, P.; Deepa, N.; Dev, K.; Gadekallu, T.R.; Ruby, R.; Liyanage, M. Industry 5.0: A survey on enabling technologies and potential applications. J. Ind. Inf. Integr. 2022, 26, 100257. [Google Scholar] [CrossRef]
  42. Akyazi, T.; Goti, A.; Alberdi, E.; Behrend, C.; Schröder, A.J.; Colla, V.; Stroud, D.; Antonazzo, L.; Weinel, M. Conclusion: Recasting the Future of the European Steel Industry. In Industry 4.0 and the Road to Sustainable Steelmaking in Europe: Recasting the Future; Stroud, D., Schröder, A.J., Antonazzo, L., Behrend, C., Colla, V., Goti, A., Weinel, M., Eds.; Springer International Publishing: Cham, Switzerland, 2024; pp. 219–227. [Google Scholar] [CrossRef]
  43. Domínguez-Bolaño, T.; Campos, O.; Barral, V.; Escudero, C.J.; García-Naya, J.A. An overview of IoT architectures, technologies, and existing open-source projects. Internet Things 2022, 20, 100626. [Google Scholar] [CrossRef]
  44. Fortoul-Diaz, J.A.; Carrillo-Martinez, L.A.; Centeno-Tellez, A.; Cortes-Santacruz, F.; Olmos-Pineda, I.; Flores-Quintero, R.R. A Smart Factory Architecture Based on Industry 4.0 Technologies: Open-Source Software Implementation. IEEE Access 2023, 11, 101727–101749. [Google Scholar] [CrossRef]
  45. Folgado, F.J.; Calderón, D.; González, I.; Calderón, A.J. Review of Industry 4.0 from the Perspective of Automation and Supervision Systems: Definitions, Architectures and Recent Trends. Electronics 2024, 13, 782. [Google Scholar] [CrossRef]
  46. GNU General Public License Version 3. 2024. Available online: https://opensource.org/license/gpl-3-0 (accessed on 6 December 2024).
  47. The MIT License. 2024. Available online: https://opensource.org/license/mit (accessed on 6 December 2024).
  48. The 3-Clause BSD License. 2024. Available online: https://opensource.org/license/bsd-3-clause (accessed on 6 December 2024).
  49. Stroud, D.; Antonazzo, L.; Weinel, M. The Technological and Social Transformation of the European Steel Industry: Towards Decarbonisation and Digitalisation. In Industry 4.0 and the Road to Sustainable Steelmaking in Europe: Recasting the Future; Stroud, D., Schröder, A.J., Antonazzo, L., Behrend, C., Colla, V., Goti, A., Weinel, M., Eds.; Springer International Publishing: Cham, Switzerland, 2024; pp. 17–34. [Google Scholar] [CrossRef]
  50. Kouroubali, A.; Katehakis, D.G. The new European interoperability framework as a facilitator of digital transformation for citizen empowerment. J. Biomed. Inform. 2019, 94, 103166. [Google Scholar] [CrossRef]
  51. Kannisto, P.; Hästbacka, D. Digitalized Cross-organizational Interoperability in Industrial Business Ecosystems: Implications and Models for Process Industry. In Proceedings of the 3rd International Conference on Innovative Intelligent Industrial Production and Logistics—Volume 1: EI2N (IN4PL/EI2N), Valletta, Malta, 24–26 October 2022; pp. 233–241. [Google Scholar] [CrossRef]
  52. Ameri, F.; Sormaz, D.; Psarommatis, F.; Kiritsis, D. Industrial ontologies for interoperability in agile and resilient manufacturing. Int. J. Prod. Res. 2022, 60, 420–441. [Google Scholar] [CrossRef]
  53. Kannisto, P.; Gümrükcü, E.; Ponci, F.; Monti, A.; Repo, S.; Hästbacka, D. Distributed Service Choreography Framework for Interoperability Among Prosumers and Electric Power System. IEEE Access 2023, 11, 137969–137989. [Google Scholar] [CrossRef]
  54. Baškarada, S.; Nguyen, V.; Koronios, A. Architecting Microservices: Practical Opportunities and Challenges. J. Comput. Inf. Syst. 2020, 60, 428–436. [Google Scholar] [CrossRef]
  55. Kannisto, P.; Hästbacka, D.; Marttinen, A. Information Exchange Architecture for Collaborative Industrial Ecosystem. Inf. Syst. Front. 2020, 22, 655–670. [Google Scholar] [CrossRef]
  56. Magas, M.; Kiritsis, D. Industry Commons: An ecosystem approach to horizontal enablers for sustainable cross-domain industrial innovation (a positioning paper). Int. J. Prod. Res. 2022, 60, 479–492. [Google Scholar] [CrossRef]
  57. OPC 10000-1; OPC Unified Architecture Part 1: Overview and Concepts, Release 1.05.02. OPC Foundation: Scottsdale, AZ, USA, 2022.
  58. ETSI GS CIM 009 NGSI-LD API V1.8.1. 2024. Available online: https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.08.01_60/gs_CIM009v010801p.pdf (accessed on 15 August 2024).
  59. Kannisto, P.; Hästbacka, D.; Gutiérrez, T.; Suominen, O.; Vilkko, M.; Craamer, P. Plant-wide interoperability and decoupled, data-driven process control with message bus communication. J. Ind. Inf. Integr. 2022, 26, 100253. [Google Scholar] [CrossRef]
  60. Pettenpohl, H.; Spiekermann, M.; Both, J.R. International Data Spaces in a Nutshell. In Designing Data Spaces: The Ecosystem Approach to Competitive Advantage; Otto, B., ten Hompel, M., Wrobel, S., Eds.; Springer International Publishing: Cham, Switzerland, 2022; pp. 29–40. [Google Scholar] [CrossRef]
  61. Tardieu, H. Role of Gaia-X in the European Data Space Ecosystem. In Designing Data Spaces: The Ecosystem Approach to Competitive Advantage; Otto, B., ten Hompel, M., Wrobel, S., Eds.; Springer International Publishing: Cham, Switzerland, 2022; pp. 41–59. [Google Scholar] [CrossRef]
Figure 1. The cycles of the research methodology illustrated.
Figure 1. The cycles of the research methodology illustrated.
Processes 12 02877 g001
Figure 2. The Self-X optimization scheme, including HITL and the external, supportive AI services.
Figure 2. The Self-X optimization scheme, including HITL and the external, supportive AI services.
Processes 12 02877 g002
Figure 3. The architecture of the Self-X AI Pipeline; each component is positioned within the reference architecture.
Figure 3. The architecture of the Self-X AI Pipeline; each component is positioned within the reference architecture.
Processes 12 02877 g003
Figure 4. An alarm is delivered from External AI services to the data scientist. If the data scientist confirms the alarm, AI Data Pipeline will refresh the optimization models.
Figure 4. An alarm is delivered from External AI services to the data scientist. If the data scientist confirms the alarm, AI Data Pipeline will refresh the optimization models.
Processes 12 02877 g004
Figure 5. The components of the prototype.
Figure 5. The components of the prototype.
Processes 12 02877 g005
Figure 6. The alarms generated by the AI methods for the different stages of the AI pipeline are displayed in the dashboard (left). These alerts are categorized into different types (right).
Figure 6. The alarms generated by the AI methods for the different stages of the AI pipeline are displayed in the dashboard (left). These alerts are categorized into different types (right).
Processes 12 02877 g006
Figure 7. The alarms generated by the AI methods for the cumulative amount of secondary oxygen in the transformation stage are shown in the upper plot. The raw data for the cumulative amount of secondary oxygen are shown in the lower graph, with the alarm-triggering periods indicated by red rectangles.
Figure 7. The alarms generated by the AI methods for the cumulative amount of secondary oxygen in the transformation stage are shown in the upper plot. The raw data for the cumulative amount of secondary oxygen are shown in the lower graph, with the alarm-triggering periods indicated by red rectangles.
Processes 12 02877 g007
Figure 8. Autonomic Manager generates alarms based on predefined rules applied to metadata at the various stages of the AI pipeline, categorizing the alarms into different types.
Figure 8. Autonomic Manager generates alarms based on predefined rules applied to metadata at the various stages of the AI pipeline, categorizing the alarms into different types.
Processes 12 02877 g008
Figure 9. Alarms generated by the Autonomic Manager for model degradation.
Figure 9. Alarms generated by the Autonomic Manager for model degradation.
Processes 12 02877 g009
Figure 10. Scrap characterization calculates a chemical analysis for different scrap types.
Figure 10. Scrap characterization calculates a chemical analysis for different scrap types.
Processes 12 02877 g010
Figure 11. Scrap mix optimization recommends the optimal scrap mix for the furnace, taking into account the target steel grade, scrap availability, and cost.
Figure 11. Scrap mix optimization recommends the optimal scrap mix for the furnace, taking into account the target steel grade, scrap availability, and cost.
Processes 12 02877 g011
Table 1. The technologies that implement the AI Data Pipeline presented in Figure 3.
Table 1. The technologies that implement the AI Data Pipeline presented in Figure 3.
LayerComponentTechnology
ApplicationsHITL GUIsHTML, JavaScript and related tools, e.g., Grafana [25], Angular [26], and ChartJS [27]
Autonomic ManagerAutonomic ManagerApache Airflow [28]
AI methodsData Diagnostic Laboratory (D2Lab) [29]
API inFIWARE Orion context broker [30]
MetaAPI outApache Kafka [31]
Client for external servicesFIWARE and Kafka clients in Node-RED environment [32]
Scrap characterizationPython [33] and Flask [34]
Data processingScrap mix optimizationPython [33] and Flask [34]
Metadata GeneratorPython [33]
Data brokering and persistenceWorkflow managementNode-RED [32]
Data storageMySQL relational database [35], InFluxDB timeseries database [36]
Data ingestion and transformationData refinementNode-RED [32]
Raw data sourcesMySQL relational database [35]
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Kannisto, P.; Kargar, Z.; Alvarez, G.; Kleimt, B.; Arteaga, A. Resilient, Adaptive Industrial Self-X AI Pipeline with External AI Services: A Case Study on Electric Steelmaking. Processes 2024, 12, 2877. https://doi.org/10.3390/pr12122877

AMA Style

Kannisto P, Kargar Z, Alvarez G, Kleimt B, Arteaga A. Resilient, Adaptive Industrial Self-X AI Pipeline with External AI Services: A Case Study on Electric Steelmaking. Processes. 2024; 12(12):2877. https://doi.org/10.3390/pr12122877

Chicago/Turabian Style

Kannisto, Petri, Zeinab Kargar, Gorka Alvarez, Bernd Kleimt, and Asier Arteaga. 2024. "Resilient, Adaptive Industrial Self-X AI Pipeline with External AI Services: A Case Study on Electric Steelmaking" Processes 12, no. 12: 2877. https://doi.org/10.3390/pr12122877

APA Style

Kannisto, P., Kargar, Z., Alvarez, G., Kleimt, B., & Arteaga, A. (2024). Resilient, Adaptive Industrial Self-X AI Pipeline with External AI Services: A Case Study on Electric Steelmaking. Processes, 12(12), 2877. https://doi.org/10.3390/pr12122877

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop