Process Industry faces limits related to artificial intelligence (AI) adoption because of intrinsic dynamics in processes and feedstock. While proposing solutions, current studies neglect to consider the human role, which is deemed critical in Industry 5.0 perspective. This work aims to develop a procedure to evaluate the dynamic interactions between humans and adaptive AI controllers in real settings, addressing the need for robust systems that can integrate human expertise.
A novel framework is proposed, integrating Autonomic Computing principles with a classification of humachine interaction types. A three-step analytical procedure is then proposed and applied via an explanatory multiple case study of four industrial applications.
The analysis reveals a divergence between theoretical and current practice, where AI applications usually follow a human-as-a-master configuration, suggesting socio-technical barriers that prevent the adoption of higher automation levels.
This work offers a first attempt at a systematic procedure to evaluate humachine dynamics in Autonomic Computing applications in Process Industry. For practitioners, it constitutes a design tool for more effective socio-technical systems by aligning AI autonomy with operational challenges and the role of human supervision and control.
Quick value overview
Interesting because: this work addresses the gap between human-centric manufacturing goals and the practical design of AI-enabled control systems. While this gap is covered by discrete manufacturing studies or high-level organisational models, this article dives into specific Process Industry control loops, where process variability exposes AI to typical shortcomings. In doing so, it proposes a three-step procedure to analyse and classify human–AI interaction dynamics (“humachine dynamics”) at shopfloor level.
Theoretical value: the theoretical contribution is a novel analytical framework created by cross-fertilising Autonomic Computing, humachine dynamics, and the RAMI4.0 architecture. Applying this to four Process Industry case studies, the article provides empirical evidence challenging deterministic views of AI adoption: a key finding is the divergence between theoretically “desirable” human–AI collaboration types and the current reality, which is dominated by a human-led systems. This suggests that socio-technical barriers, such as the need for operator trust and explainability, are primary obstacles to achieving effective human–AI partnership.
Practical value: the article offers managers a diagnostic tool that helps align the planned type of humachine interaction with the desirable one. After identifying the AI application context and the intended interaction target, managers can compare the two and detect potential mismatches that may lead to AI underusage or overconfidence, shifting attention toward the collaborative interface rather than solely on model accuracy.
1. Introduction
Process Industry (PI) is considered a “mature” sector because it relies on established processes difficult to replace without compromising production volumes or performance (Panwar et al., 2015). Nevertheless, PI continues exploring innovative technologies aimed at efficiency, reducing operational costs and environmental impact, and enhancing workplace safety (Dwivedi et al., 2023): for this reason, several domains of PI embraced innovation actions based on digital transformation like the well-known “Industry 4.0” (Fantini et al., 2018), which exploits production data for applications like maintenance, production scheduling and supply chain optimisation (Pinzone et al., 2024). The consequent growth of industrial data enhanced the adoption of artificial intelligence (AI) solutions, particularly machine learning (ML) models, which can process large datasets to deliver scalable and efficient outcomes in industrial production systems (Khan and Ammar Taqvi, 2023; Pavlović et al., 2020).
However, PI presents unique challenges – as feedstock variability – that can affect the performance and reliability of ML models (Qin, 2014). Although several studies addressed these limitations, most of the proposed solutions focus on technical and incremental approaches, refining AI models to mitigate technical shortcomings. Given PI’s traditionally low level of human involvement (Borghesan et al., 2022), mitigation strategies have emphasised technological improvements – as the adoption of explainable AI models (Karun et al., 2021) – rather than organisational or structural adaptations. Yet, the critical role of human–automation relationship has long been recognised, starting with the seminal work of Rasmussen (1976), and continuing as a core theme in the expanding field of human–autonomy interaction types (Wesche et al., 2022). This gap becomes relevant amid the current shift toward human-centric industry approach, known as “Industry 5.0”, which emphasises collaboration, adaptability and resilience through integrating human expertise and intelligent systems (Raisch and Krakowski, 2021; Rosemeyer et al., 2024). Recent advancements have included Maturity Models (Latino, 2025), but these tools are tailored to the needs of manufacturing SMEs (Gökalp and Martinez, 2021) limiting their reliability for PI, where large enterprises dominate the market; furthermore, they adopt a holistic view of companies, considering humans within the lens of organisational culture, but seldom addressing supervised processes (Pinzone et al., 2021). Consequently, a significant gap persists between strategic goals and the practical design of AI-enabled control systems, particularly regarding tools analysing interplay between human agents and these systems.
To address this gap, this study proposes a systematic procedure for analysing the integration of AI tools into PI automation systems, specifically in scenarios involving human agents in process control loops. After analysing AI-specific shortcomings in PI, the article argues that overcoming AI’s limitations in PI environments does not require only more sophisticated algorithms, but a holistic approach that considers both people and technology to achieve higher performances. Therefore, after having identified Autonomic Computing (Kephart and Chess, 2003) as a promising solution, this work adopts the humachine concept (Sanders and Wood, 2019; Wesche and Sonderegger, 2019) to examine the dynamic interaction between humans and AI systems. The proposed procedure is then applied to four case studies across different PI domains, providing insights into different levels of human involvement in AI-based industrial process control. This contributes to the debate on effectively integrating humans into control contexts to manage PI’s inherent variability and uncertainty. Moreover, applying the proposed procedure to four PI case studies provides empirical evidence of its versatility across different sub-domains.
This article is organised as follows: Section 2 reviews literature on AI and ML shortcomings in PI. Section 3 details the study’s research design. Section 4 introduces foundational concepts of Autonomic Computing and humachine, while Section 5 presents the procedure for their analysis. Section 6 applies this procedure to case studies. Finally, Section 7 discusses findings, limitations and outlines future work.
2. State of the art on shortcomings of AI and ML in process industry
Industry 4.0, focusing on production digitisation and enterprises’ digital transformation, has led manufacturing companies to adopt models based on software hierarchies introduced by ISA 95, later refined through IEC 61512 and 62,264. These standards were integrated into the Reference Architecture Model for Industrie 4.0 (RAMI4.0) (Fantini et al., 2018) which structures industrial companies by defining automation layers aligned with distinct control platforms.
Layer 0 (L0): physical assets, sensors and actuators responsible for data generation and actuation.
Layer 1 (L1): fixed-cycle-time controllers, usually implemented via PLCs.
Layer 2 (L2): process-domain-specialised controllers, synchronised with the process and usually hosted on server-based platforms, often corresponding to SCADA systems or Process Control Systems (PCS).
Layer 3 (L3): process-synchronised systems responsible for manufacturing execution (i.e. MES).
Layer 4 (L4): asynchronous systems such as ERP and Advanced Planning Systems (APS) (Ivanov et al., 2018), which implement demand forecasting to provide reference inputs to L3.
An emerging industrial requirement is therefore the integration of AI features across all the control levels. AI applications have indeed proven capable of increasing process efficiency, enhancing decision-making and delivering additional benefits in activities as resource management and maintenance (Peres et al., 2020). However, adopting AI and ML in PI also raises concerns about potential drawbacks in this domain (Karwowski et al., 2025).
To evaluate these issues and to gauge awareness within scientific and industrial communities, a systematic literature review was conducted following PRISMA 2020 guidelines. Accordingly, the review followed a structured process with three main phases.
In the identification phase, Scopus database was queried using the following search string applied to titles, abstracts, and keywords: ((“Artificial Intelligence” OR “Machine Learning” OR AI OR ML) AND (shortcomin* OR issue* OR drawbac*) AND “process industr*”), returning 87 results. Inclusion criteria were then applied to ensure quality and relevance, reducing the set to 65 papers for title and abstract screening. Inclusion criteria considered: publications written in English, published from 2011 (marking the introduction of RAMI 4.0), and peer-reviewed articles from journals or conferences.
During the screening phase, titles and abstracts were reviewed conservatively to avoid excluding potentially relevant studies. Exclusion criteria neglected papers that focused only on AI/ML as a solution without addressing limitations, those that were primarily technical comparisons of AI/ML models, and those falling outside the scope of PI. After applying these criteria, 31 articles remained for full-text analysis.
In the final phase, the 31 full texts were examined in detail, applying the same exclusion criteria to ensure consistency and maintain relevance. As a result, 14 articles were included in the qualitative synthesis, as shown in Table 1.
Systematic literature search
| Article . | Shortcoming . | Solution . | |||||
|---|---|---|---|---|---|---|---|
| Data . | Performance . | Human . | Addressed . | Provided . | |||
| Changing condition . | Imbalance . | Scarcity . | |||||
| Bunian et al. (2024) | ✔ | ✔ | |||||
| Mietkiewicz and Madsen (2023) | ✔ | ✔ | |||||
| Wang et al. (2024) | ✔ | ✔ | |||||
| Shi et al. (2024) | ✔ | ✔ | |||||
| Lin et al. (2023) | ✔ | ✔ | |||||
| Li et al. (2023) | ✔ | ✔ | |||||
| Nölle et al. (2022) | ✔ | ✔ | |||||
| Karun et al. (2021) | ✔ | ✔ | |||||
| Ragab et al. (2021) | ✔ | ✔ | |||||
| Nian et al. (2020) | ✔ | ✔ | |||||
| He et al. (2020) | ✔ | ✔ | |||||
| Pilario et al. (2019) | ✔ | ✔ | |||||
| Shao et al. (2019) | ✔ | ✔ | ✔ | ||||
| Qin and Chiang (2019) | ✔ | ✔ | |||||
| Article . | Shortcoming . | Solution . | |||||
|---|---|---|---|---|---|---|---|
| Data . | Performance . | Human . | Addressed . | Provided . | |||
| Changing condition . | Imbalance . | Scarcity . | |||||
| Bunian et al. (2024) | ✔ | ✔ | |||||
| Mietkiewicz and Madsen (2023) | ✔ | ✔ | |||||
| Wang et al. (2024) | ✔ | ✔ | |||||
| Shi et al. (2024) | ✔ | ✔ | |||||
| Lin et al. (2023) | ✔ | ✔ | |||||
| Li et al. (2023) | ✔ | ✔ | |||||
| Nölle et al. (2022) | ✔ | ✔ | |||||
| Karun et al. (2021) | ✔ | ✔ | |||||
| Ragab et al. (2021) | ✔ | ✔ | |||||
| Nian et al. (2020) | ✔ | ✔ | |||||
| He et al. (2020) | ✔ | ✔ | |||||
| Pilario et al. (2019) | ✔ | ✔ | |||||
| Shao et al. (2019) | ✔ | ✔ | ✔ | ||||
| Qin and Chiang (2019) | ✔ | ✔ | |||||
Analysis of these works reveals three main clusters of issues in AI/ML applications within PI: (1) data, where issues concern the input of the AI/ML models, (2) computational performance, where they sit in the computational effort of such algorithms and (3) human, where they are related to the interface of the human agent with the controller within which the algorithm is framed.
The most studied data-related issue involves changing processes’ conditions, a common drawback in PI, where slow dynamics (e.g. equipment aging or feedstock variability) degrade AI/ML performance, inducing biases and drifts over time. Scholars propose different approaches: Shao et al. (2019) statistically enriched training dataset; Nölle et al. (2022) used Digital Twins to simulate conditions’ change; Karun et al. (2021) highlighted the need for human-understandable models, to involve operators in the decisional loop and correct biased output. Other approaches stem from AI techniques: Pilario et al. (2019) suggested kernel methods for better dynamics identification during feature extraction; Shi et al. (2024) employed self-attention in Gated Recurrent Layer to dynamically select memory (Chung et al., 2014); Lin et al. (2023) proposed to mitigate context changes through Transfer Learning (Li et al., 2022); Bunian et al. (2024) proposes self-optimising AI modules for condition variability; Li et al. (2023) addressed dataset imbalance, common in anomaly detection, where normal behaviour data samples dominate, using a weighting mechanism (Ye et al., 2022). Data scarcity (whether due to small datasets or costly labelling) was debated by He et al. (2020), Shao et al. (2019) and Wang et al. (2024), with the first two adopting statistical augmentation of training dataset, and the latter using Generative Adversarial Network (Goodfellow et al., 2020) to expand labelled dataset.
Computational performance-related issues were debated in Nian et al. (2020), Ragab et al. (2021). The former cited the growing computational complexity of Artificial Neural Networks as dataset size increases, while the latter suggested using a Reinforcement Learning reward mechanism to reduce dataset dimension and, consequently, computational requirements for complex or long-term analyses. These issues are intrinsic to AI/ML and apply across several industrial domains; therefore, they will not be further addressed in this work.
Human-related issues focus on the interface with human agents and the need for better integration in detection and decision-making phases. Qin and Chiang (2019) reported digital illiteracy among shopfloor operators, hindering smooth human-machine integration Ragab et al. (2021) highlighted the need for human’s expertise in the decision-making. This was also addressed by Karun et al. (2021), who proposed human-interpretable models, and by Mietkiewicz and Madsen (2023), who developed decision support systems based on Dynamic Influence Diagrams.
In summary, the main shortcomings related to AI integration in PI fall into the three areas: data quality and availability, computational limitations and challenges in integrating human agents into AI-enabled decision processes. Notwithstanding the research interest in these topics, most approaches remain incremental and fail to systematically address control implications and human–AI interactions dynamics.
3. Research design
To address this gap, this study introduces a framework designed to achieve the following objectives:
address scalability, reliability and adaptability limits of AI-enabled controls in RAMI4.0 layers. AI in PI faces data-related phenomena such as slow-dynamics deviations (gradual domain shifts pushing processes outside optimised operating regions) or abrupt deviations (unforeseen events that remain undetected or cannot be compensated by the automation system (Millara et al., 2019))
explicitly consider the human role inside complex and critical control systems. As noted by Rasmussen (1976), human-machine interaction in socio-technical system requires strategic evaluation to define optimal function allocation and maximise human-machine complementarity.
To meet O1, the framework should go beyond static AI implementations. Slow-dynamics and abrupt deviations impose functional requirements on any control architecture. For slow-dynamics, the system should continuously monitor its performance and detect early degradation over time. For abrupt deviations, it must diagnose unforeseen events and reconfigure itself adapting for the new dynamics. Consequently, upon detecting either deviation, the system should plan and execute corrective actions, ranging from recalibrating model parameters to retraining or reverting to a safer operational mode. These requirements align with Autonomic Computing (AC) (Kephart and Chess, 2003) principles, identified therefore as the technological foundation for the framework and discussed in the next chapter. For instance, García et al. (2023) applied AC in the food industry to address feedstock seasonality and optimise cattle fodder composition. Kannisto et al. (2024) exploited AC to improve scrap mix preparation in secondary steel production. These examples highlight AC’s potential to manage input data fluctuations, positioning it as a means to face O1.
While AC provides the technological foundation for O1, understanding the resulting human–AI interaction (O2) requires a methodology able to explore complex socio-technical phenomena. O2 indeed targets dynamics between human operators and adaptive AI controllers that cannot be adequately addressed through quantitative methods alone. Therefore, this study adopts a multiple case study methodology, suitable for investigating phenomena within their context, especially when boundaries with the context are unclear (Yin, 2009). This method enables qualitative exploration of interactions, organisational factors and contextual variables shaping the humachine relationship. Following established classifications of real-world research (Robson, 2002), the purpose of this research is primarily explanatory. While it includes descriptive elements, its focus is on explaining how and why certain humachine dynamics emerge in practice. Specifically, the study first proposes a theoretical framework and normative propositions for desirable human–AI interaction. It then applies the multiple-case design to test this framework and, critically, to build an explanation for the observed divergence between theoretical concepts and real-world implementations, producing insights to guide researchers and practitioners in designing future socio-technical systems.
To ground the study on relevant and advanced industrial practice, it leverages the opportunity to analyse four distinct PI cases from the European Commission-funded research “self-X Artificial Intelligence for European Process Industry digital transformation”. This provides a methodological advantage by ensuring extensive data access and a consistent technological baseline, as all participants were engaged in embodying AC solutions into their production environments. This selection ensures diversity and enhances external validity as cases span multiple PI sub-domains – asphalt, steel, pharmaceuticals (from now on referred to as “pharma”) and aluminium production – each presenting peculiar challenges related to feedstock variability, process complexity and safety criticality. This heterogeneity enables comparative analysis and supports testing the proposed framework’s consistency across different industrial contexts.
The primary unit of analysis is each specific AI application. Since a single case may involve multiple AI-driven tasks, each one constitutes an independent case for evaluating humachine dynamics. Data were collected through qualitative reviews of technical documentation, system design specifications and project reports, cross-referenced to ensure consistency. To ensure adherence with the actual implementation design, verification interviews with companies’ representatives (R&D and production managers) were also conducted. This approach provided detailed insights into both the AI controllers’ technical architecture and their intended interaction with human operators. To ensure systematic and replicable analysis across the heterogeneous cases, a three-step analytical procedure – detailed in Section 5 – was developed and applied. The first step contextualises the AI application within RAMI4.0. In the four cases, AI applications typically fall into one of three primary contexts: Planning (L3/L4), Process setup optimisation (L2/L3) or Process real-time (r/t) control (L1).
The second step identifies the primary control target of the humachine system. These targets come from objective O1 and are so classified:
Process Deviation Correction Efficiency (PDCE): focuses on corrective interventions for both slow-dynamic and abrupt deviations.
Decision Making Efficiency (DME): seeks synergy between machine analysis and human reasoning, especially in unconventional situations.
Automation of Repetitive Tasks (ART): targets tasks where automation can improve consistency and safety by mimicking human actions.
The final step targets O2 by classifying the observed humachine dynamic against a desirable state. Based on literature (Wesche et al., 2022), three interaction types are defined:
Type 1 (Human Master): the human drives the process, with AI as a supporting tool.
Type 2 (AI Master): AI has full control, while the human acts as an observer/supervisor.
Type 3 (Collaborative): Human and AI continuously interact in a partnership.
4. Autonomic Computing and self-X capabilities
Introduced by IBM in 2003 to manage network complexity through self-diagnosis and automated intervention, AC embeds self-management properties within software infrastructures (Kephart and Chess, 2003). These properties enable systems to dynamically adjust control policies in response to contextual changes. Its resumption has been further supported by the rise of cloud computing, where context-awareness in multi-agent nodes has become critical (S-Julián et al., 2023). Defined by Kephart and Chess (2003) as “self-X capabilities’”, its properties can be inflected in industrial application by complementing the conventional controller of Figure 1a with the self-X controller of Figure 1b, representing an outer control loop around the first one.
The image shows two labeled diagrams, “a” on the left and “b” on the right. Diagram “a” includes a circular summing node on the left that receives a rightward arrow labeled “Target”. A plus sign is present above the circular summing node. A rightward arrow labeled “Error” emerges from the summing node and points to a rectangular box labeled “Controller”. A rightward arrow labeled “Input” emerges from the controller and points to a rectangular box labeled “System”. A downward arrow labeled “Disturbance” emerges from above and points to the “System”. A rightward arrow labeled “Output” emerges from the “System” and extends outward. A downward arrow emerges from this rightward output arrow and points to a rectangular text box labeled “Sensor”, which is positioned slightly below and between the “Controller” and the “System”. An upward arrow emerges from the “Sensor” and points back to the circular summing node, connecting at the point marked with a negative sign. Diagram “b” includes a circular summing node on the left that receives a rightward arrow labeled “Target”. A plus sign is present below the rightward arrow “Target”. A rightward arrow labeled “Error” emerges from the summing node and points to a rectangular box labeled “Controller”. A rightward arrow labeled “Input” emerges from the controller and points to a rectangular box labeled “System”. An upward arrow labeled “Disturbance” emerges from above and points to the “System”. A rightward arrow labeled “Output” emerges from the “System” and points to an icon of a bar graph with a trend line on the far right. A downward arrow emerges from this rightward output arrow and points to a rectangular text box labeled “Sensor”, which is positioned slightly below and between the “Controller” and the “System”. An upward arrow emerges from the “Sensor” and points back to the circular summing node, connecting at the point marked with a negative sign. A downward arrow emerges from the bar graph icon and points to a rectangular text box labeled “s–X Controller”, which is positioned below “Sensor”. An upward arrow emerges from the “s–X Controller” and points back to the rightward arrow labeled “Target” on the left.Conventional (a) and self-X enhanced (b) control loops representation. Source(s): Authors’ own work
The image shows two labeled diagrams, “a” on the left and “b” on the right. Diagram “a” includes a circular summing node on the left that receives a rightward arrow labeled “Target”. A plus sign is present above the circular summing node. A rightward arrow labeled “Error” emerges from the summing node and points to a rectangular box labeled “Controller”. A rightward arrow labeled “Input” emerges from the controller and points to a rectangular box labeled “System”. A downward arrow labeled “Disturbance” emerges from above and points to the “System”. A rightward arrow labeled “Output” emerges from the “System” and extends outward. A downward arrow emerges from this rightward output arrow and points to a rectangular text box labeled “Sensor”, which is positioned slightly below and between the “Controller” and the “System”. An upward arrow emerges from the “Sensor” and points back to the circular summing node, connecting at the point marked with a negative sign. Diagram “b” includes a circular summing node on the left that receives a rightward arrow labeled “Target”. A plus sign is present below the rightward arrow “Target”. A rightward arrow labeled “Error” emerges from the summing node and points to a rectangular box labeled “Controller”. A rightward arrow labeled “Input” emerges from the controller and points to a rectangular box labeled “System”. An upward arrow labeled “Disturbance” emerges from above and points to the “System”. A rightward arrow labeled “Output” emerges from the “System” and points to an icon of a bar graph with a trend line on the far right. A downward arrow emerges from this rightward output arrow and points to a rectangular text box labeled “Sensor”, which is positioned slightly below and between the “Controller” and the “System”. An upward arrow emerges from the “Sensor” and points back to the circular summing node, connecting at the point marked with a negative sign. A downward arrow emerges from the bar graph icon and points to a rectangular text box labeled “s–X Controller”, which is positioned below “Sensor”. An upward arrow emerges from the “s–X Controller” and points back to the rightward arrow labeled “Target” on the left.Conventional (a) and self-X enhanced (b) control loops representation. Source(s): Authors’ own work
Considering RAMI4.0, the conventional control loop depicted in Figure 1a can be implemented at any layer, serving purposes from industrial real-time control to managerial operations (Samad et al., 2022). In Figure 1a, the controller addresses routine tasks that humans cannot usually manage alone. Advanced control solutions already used in the process industry fall into this category (Craig et al., 2011). For example, advanced process control techniques, like Model Predictive Controls (Bemporad and Morari, 1999), have evolved from laboratory applications to become standard in many PI contexts.
Conversely, a control platform with self-X abilities embodies the following properties (Kephart and Chess, 2003; Quadrini et al., 2024):
Self-Configuration: ability to reconfigure itself, in response to evolving requirements or environmental changes by deploying alternative control components.
Self-Healing: ability to maximise the availability through fault diagnosing and repair of control functionality.
Self-Optimisation: ability to improve performances both reactively and proactively.
Self-Protection: ability to anticipate and detect external factors that could cause damage.
Several self-X properties can be implemented through control technologies. For example, self-Healing and self-Configuration can be achieved via fault detection mechanisms followed by automatic reconfiguration (Marquez et al., 2021). Similarly, self-Optimisation can be realised through technologies that classify all possible conditions during normal process execution (Cuzzola and Aurora, 2017; Liu, 2017) or through control strategies adaptable to varying operating points, such as gain-scheduling approaches (Bett and Chen, 2005). Current technology maturity does not yet enable systematic implementation of all self-X properties across every control layer and process industry (Mo et al., 2023). However, it represents a vision that aims at self-X properties implementation (also referred to as self-Adaptation (De Lemos et al., 2013)) recognising them as an approach to manage process uncertainties to achieve an effective continuous-improvement loop.
Introducing self-X properties redefines the role of human operators, as shown in Figure 1b. The outer control loops – “self-X Controller” –activate after process measurements, expanding control scope and elevating human involvement. self-X Controllers can be modelled as an MAPE-K loop, a widely used approach built on a Knowledge-base (Arcaini et al., 2015) that distinguishes four computational phases (Monitor, Analyse, Plan, and Execute):
Monitoring corresponds to capturing the status of performance indicators.
Analysis uses the Knowledge-base to compare current conditions with the historical information, including verification about the efficiency of past control actions against previously detected corrective needs.
Planning applies decision-making technologies to identify future self-X control actions that optimise performance or correct anomalies.
Execution defines new references for lower-level controllers.
Fault-detection and reconfiguration, gain scheduling and other control technologies developed in the field of automatic control can also be modelled as MAPE-K loops.
Given the PI’s dynamic conditions and the evolving human responsibilities, self-X Controllers act as tools that enhance human expertise through automated learning mechanisms (Ghobakhloo et al., 2024). This perspective aligns with the humachine concept (Sanders and Wood, 2019; Wesche and Sonderegger, 2019), which highlights human–AI collaboration as a driver of human-centric and resilient industrial environments. It also represents an evolution of earlier socio-technical frameworks embedding cognition in manufacturing organisations (Nobre, 2011; Nobre et al., 2008), while humachine focus mainly on interaction (Mourtzis et al., 2023).
5. A procedure for exploring humachine dynamics in process industry use-cases
Given these premises, this study is devoted to understanding interactions between human actors and self-X AI controllers in PI. To analyse humachine interactions, a three-step procedure is here proposed:
5.1 “AI application context” definition
AI applications are mapped onto corresponding RAMI4.0 layers to assess technological burdens and enable comparison with similar implementations across sectors.
In PI, AI technologies based on ML data-pipelines can operate at different RAMI4.0 layers (Craig et al., 2011), mainly:
Planning: handles optimal scheduling of production processes and belongs to L4 and L3 (for area-production scheduling). It usually relies on predictive methods and, given resilience requirements, on real-time knowledge.
Process setup optimisation: typically implemented at intermediate layers (L2 or L3), where predictive models ensure maximum product quality. Without predictive automation, process optimisation depends on supervisors with specialised process expertise, though experts can still oversee setups via user interfaces.
Process real-time (r/t) control: usually implemented at L1, using control techniques based on prior process knowledge, or on trial-and-error calibration. Human supervision is supported through interfaces displaying process status.
5.2 Humachine target definition
From Step 1, the control target is defined and classified into predefined categories, clustering AI applications based on human, technological, performance and resilience requirements. This classification simplifies comparison of heterogeneous case studies in terms of humachine expectations. Specifically, this step identifies control targets the humachine system aims to achieve, derived from the two primary requirements established in the research design: ensuring AI robustness against process modifications (O1) and effectively blending machine and human activities (O2). Using the MAPE-K model, these targets can be classified according to the functional purpose of self-X Controllers. Key targets for humachine systems in process industries are defined as follows, and may require robustness through a MAPE-K layer to address previously identified deviations:
Process Deviation Correction Efficiency (PDCE): prompting automatic corrective intervention is critical for slow-dynamics deviations, where process changes must be analysed, and for abrupt deviations, where prompt actions are needed even when humans detect the modification (e.g. applying a trim to a control variable or re-configuring the control logic).
Decision Making Efficiency (DME): in decision making, human and machine activity should complement each other. Indeed, machines execute ML algorithms without bias when situations match prior observations, while human reasoning ability excels in unconventional situations requiring intuition. DME typically concerns a decision to be applied independently from the current process status (e.g. production scheduling as a decision-making process whose efficiency is to be checked against optimality).
Automation of Repetitive Tasks (ART): for tasks requiring strict safety conditions (i.e. when distraction can cause mistakes or damages) humachine ensures process continuity and safety.
5.3 Humachine dynamics type definition
As proposed in Wesche et al. (2022), three alternative humachine dynamic interaction types depicted in Figure 2:
The image shows three labeled diagrams, “1”, “2”, and “3”, arranged vertically. Diagram “1” includes a circular summing node on the left that receives a rightward arrow labeled “Target”. A rightward arrow emerges from the summing node and points to a rectangular box labeled “Human Sensing”. A rightward arrow connects “Human Sensing” to a rectangular box labeled “Human Thinking”, and another rightward arrow connects “Human Thinking” to a rectangular box labeled “Actuation”. A rightward arrow connects “Actuation” to a rectangular box labeled “Process and basic Controller”, which leads to an output icon of a bar graph with a trend line on the far right. Below “Human Sensing” and “Human Thinking”, a rectangular box labeled “s–X Sensing: Monitor, Analyse (M A–K)” connects rightward to a rectangular box labeled “s–X Controller: Plan, Execute (P E)”, and an upward arrow from the box “s–X Sensing: Monitor, Analyse (M A–K)” points to “Human sensing” and an upward arrow from the box “s–X Controller: Plan, Execute (P E)” points to “Human Thinking”. A downward arrow emerges from the rightward arrow that connects the summing node to “Human Sensing” and points to the text box labeled “s–X Sensing: Monitor, Analyse (M A–K)”. A downward leftward arrow emerges from the rightward arrow connecting “Actuation” and “Process and basic Controller” and points to the text box labeled “s–X Sensing: Monitor, Analyse (M A–K)”. A cornered leftward upward arrow emerges from the rightward arrow connecting “Process and basic Controller” to the output icon, bends leftward and then upward, and points back to the summing node at the start. A double-headed horizontal arrow from “s–X Sensing: Monitor, Analyse (M A–K)” points to a cylindrical text box on the left labeled “Knowledge base”. Diagram “2” includes a circular summing node on the left that receives a rightward arrow labeled “Target”. A rightward arrow emerges from the summing node and points to a rectangular box labeled “s–X Sensing: Monitor, Analyse (M A–K)”. A rightward arrow connects “s–X Sensing: Monitor, Analyse (M A–K)” to a rectangular box labeled “s–X Controller: Plan, Execute (P E)”. A rightward arrow connects “s–X Controller: Plan, Execute (P E)” to a rectangular box labeled “Actuation”, and another rightward arrow connects “Actuation” to a rectangular box labeled “Process and basic Controller”, which leads to an output icon of a bar graph with a trend line on the far right. Below the “s–X Sensing: Monitor, Analyse (M A–K)”, two rectangular boxes labeled “Human Sensing” and “Human Thinking” are positioned sequentially, with a rightward arrow connecting “Human Sensing” to “Human Thinking”. An upward arrow emerges from “Human Thinking” and points to the “s–X Controller: Plan, Execute (P E)”. A downward arrow emerges from the rightward arrow connecting “Actuation” and “Process and basic Controller” and points to “s–X Sensing: Monitor, Analyse (M A–K)”. A downward arrow also emerges from the rightward arrow that connects the summing node and “s–X Sensing: Monitor, Analyse (M A–K)” and points to the “Human Sensing”. A rectangular cylinder labeled “Knowledge base” is present above the summing node, and a double-headed arrow emerges from the “Knowledge base” and points to “s–X Sensing: Monitor, Analyse (M A–K)”. A cornered leftward upward arrow emerges from the rightward arrow connecting “Process and basic Controller” to the output icon, bends leftward and then upward, and points back to the summing node at the start. Diagram “3” includes a circular summation node on the left that receives a rightward arrow labeled “Target”. A rightward arrow emerges from the summation node and points to a rectangular box labeled “s–X Sensing: Monitor, Analyse (M A–K)”. A rightward arrow emerges from “s–X Sensing: Monitor, Analyse (M A–K)” and points to the rectangular box on the right labeled “s–X Controller: Plan, Execute (P E)”. To the far right of “s–X Controller: Plan, Execute (P E)”, a rectangular text box labeled “Process and basic Controller” is present. A rightward arrow emerges from “Process and basic Controller” and points to the output icon with the bar graph and a trend line on the far right. A cornered downward, leftward, and upward arrow emerges from the arrow connecting “Process and basic Controller” and the output icon and points back to the summation node at the start. Four rectangular text boxes are horizontally arranged and positioned slightly below the box labeled “s–X Sensing: Monitor, Analyse (M A–K)”. The first text box is labeled “Human Sensing”. A downward arrow emerges from the rightward arrow connecting the summation node and “s–X Sensing: Monitor, Analyse (M A–K)” and points to “Human Sensing”. A rightward arrow connects “Human Sensing” to the next rectangular text box labeled “Human Thinking”. A rightward arrow connects “Human Thinking” to the next rectangular text box labeled “Human–A I collaborative layer”. A rightward arrow emerges from “Human–A I collaborative layer” and points to the rectangular box on the right labeled “Actuation”. An upward arrow emerges from the box labeled “Actuation” and points to “Process and basic Controller”. Two upward arrows emerge from “Human Thinking” and “Actuation” respectively. The first upward arrow from “Human Thinking” points to “s–X Controller: Plan, Execute (P E)”, and the second upward arrow from “Actuation” points to “Process and basic Controller”. A leftward arrow emerges from the arrow connecting “Actuation” and “Process and basic Controller” and points to the arrow on the left labeled “s–X Sensing: Monitor, Analyse (M A–K)”. A double-headed arrow connects “s–X Sensing: Monitor, Analyse (M A–K)” and the cylindrical text box labeled “Knowledge base” positioned above the summation node.Humachine dynamics types (Mourtzis et al., 2023). Source(s): Author’s adaptation from (Mourtzis et al., 2023), licensed under CC BY 4.0
The image shows three labeled diagrams, “1”, “2”, and “3”, arranged vertically. Diagram “1” includes a circular summing node on the left that receives a rightward arrow labeled “Target”. A rightward arrow emerges from the summing node and points to a rectangular box labeled “Human Sensing”. A rightward arrow connects “Human Sensing” to a rectangular box labeled “Human Thinking”, and another rightward arrow connects “Human Thinking” to a rectangular box labeled “Actuation”. A rightward arrow connects “Actuation” to a rectangular box labeled “Process and basic Controller”, which leads to an output icon of a bar graph with a trend line on the far right. Below “Human Sensing” and “Human Thinking”, a rectangular box labeled “s–X Sensing: Monitor, Analyse (M A–K)” connects rightward to a rectangular box labeled “s–X Controller: Plan, Execute (P E)”, and an upward arrow from the box “s–X Sensing: Monitor, Analyse (M A–K)” points to “Human sensing” and an upward arrow from the box “s–X Controller: Plan, Execute (P E)” points to “Human Thinking”. A downward arrow emerges from the rightward arrow that connects the summing node to “Human Sensing” and points to the text box labeled “s–X Sensing: Monitor, Analyse (M A–K)”. A downward leftward arrow emerges from the rightward arrow connecting “Actuation” and “Process and basic Controller” and points to the text box labeled “s–X Sensing: Monitor, Analyse (M A–K)”. A cornered leftward upward arrow emerges from the rightward arrow connecting “Process and basic Controller” to the output icon, bends leftward and then upward, and points back to the summing node at the start. A double-headed horizontal arrow from “s–X Sensing: Monitor, Analyse (M A–K)” points to a cylindrical text box on the left labeled “Knowledge base”. Diagram “2” includes a circular summing node on the left that receives a rightward arrow labeled “Target”. A rightward arrow emerges from the summing node and points to a rectangular box labeled “s–X Sensing: Monitor, Analyse (M A–K)”. A rightward arrow connects “s–X Sensing: Monitor, Analyse (M A–K)” to a rectangular box labeled “s–X Controller: Plan, Execute (P E)”. A rightward arrow connects “s–X Controller: Plan, Execute (P E)” to a rectangular box labeled “Actuation”, and another rightward arrow connects “Actuation” to a rectangular box labeled “Process and basic Controller”, which leads to an output icon of a bar graph with a trend line on the far right. Below the “s–X Sensing: Monitor, Analyse (M A–K)”, two rectangular boxes labeled “Human Sensing” and “Human Thinking” are positioned sequentially, with a rightward arrow connecting “Human Sensing” to “Human Thinking”. An upward arrow emerges from “Human Thinking” and points to the “s–X Controller: Plan, Execute (P E)”. A downward arrow emerges from the rightward arrow connecting “Actuation” and “Process and basic Controller” and points to “s–X Sensing: Monitor, Analyse (M A–K)”. A downward arrow also emerges from the rightward arrow that connects the summing node and “s–X Sensing: Monitor, Analyse (M A–K)” and points to the “Human Sensing”. A rectangular cylinder labeled “Knowledge base” is present above the summing node, and a double-headed arrow emerges from the “Knowledge base” and points to “s–X Sensing: Monitor, Analyse (M A–K)”. A cornered leftward upward arrow emerges from the rightward arrow connecting “Process and basic Controller” to the output icon, bends leftward and then upward, and points back to the summing node at the start. Diagram “3” includes a circular summation node on the left that receives a rightward arrow labeled “Target”. A rightward arrow emerges from the summation node and points to a rectangular box labeled “s–X Sensing: Monitor, Analyse (M A–K)”. A rightward arrow emerges from “s–X Sensing: Monitor, Analyse (M A–K)” and points to the rectangular box on the right labeled “s–X Controller: Plan, Execute (P E)”. To the far right of “s–X Controller: Plan, Execute (P E)”, a rectangular text box labeled “Process and basic Controller” is present. A rightward arrow emerges from “Process and basic Controller” and points to the output icon with the bar graph and a trend line on the far right. A cornered downward, leftward, and upward arrow emerges from the arrow connecting “Process and basic Controller” and the output icon and points back to the summation node at the start. Four rectangular text boxes are horizontally arranged and positioned slightly below the box labeled “s–X Sensing: Monitor, Analyse (M A–K)”. The first text box is labeled “Human Sensing”. A downward arrow emerges from the rightward arrow connecting the summation node and “s–X Sensing: Monitor, Analyse (M A–K)” and points to “Human Sensing”. A rightward arrow connects “Human Sensing” to the next rectangular text box labeled “Human Thinking”. A rightward arrow connects “Human Thinking” to the next rectangular text box labeled “Human–A I collaborative layer”. A rightward arrow emerges from “Human–A I collaborative layer” and points to the rectangular box on the right labeled “Actuation”. An upward arrow emerges from the box labeled “Actuation” and points to “Process and basic Controller”. Two upward arrows emerge from “Human Thinking” and “Actuation” respectively. The first upward arrow from “Human Thinking” points to “s–X Controller: Plan, Execute (P E)”, and the second upward arrow from “Actuation” points to “Process and basic Controller”. A leftward arrow emerges from the arrow connecting “Actuation” and “Process and basic Controller” and points to the arrow on the left labeled “s–X Sensing: Monitor, Analyse (M A–K)”. A double-headed arrow connects “s–X Sensing: Monitor, Analyse (M A–K)” and the cylindrical text box labeled “Knowledge base” positioned above the summation node.Humachine dynamics types (Mourtzis et al., 2023). Source(s): Author’s adaptation from (Mourtzis et al., 2023), licensed under CC BY 4.0
Human is the “master” of the activity, and AI application is the “slave”. AI MAPE-K can supervise the process and human activities, but human thinking and execution drive the process.
The AI MAPE-K application is the “master”, and the human can only influence it by providing observations or modifying the machine’s decision-making strategy.
The third possibility is the case with human and AI MAPE-K application continuously interacting, realising a fully collaborative human–AI application. Here, a collaborative layer should implement the logics needed to reconcile the decision-making process.
Humachine dynamics include a “sensing” component in charge of M and A and a controller component where P and E reside. In all configurations, humachine dynamics might concern either the MA or the PE phases of MAPE-K application:
Humachine dynamics involve M and A when machine aids humans in sensing processes (e.g. slow-dynamics deviations difficult to perceive) or in analysing data from the Knowledge-base (K). Here, the performance information is compared to historical information to evaluate the efficiency of the last control action with respect to the previous ones. Hence, the interaction with K component is needed both for storing new data and for retrieving historical ones.
Humachine dynamics concern PE part when repetitive actions are required or when the process time-constant exceeds human capabilities.
To define desirable humachine dynamics for each target, a principled function allocation was adopted. This approach reflects classic frameworks analysing the complementary strengths of humans and machines (Fitts et al., 1951) and modern models that break tasks into stages of information processing and action (Parasuraman et al., 2000), mapped onto the MAPE-K phases of the self-X Controller to determine optimal automation levels:
PDCE’s desirable dynamics varies by deviation type. PDCE involves indeed responding to off-nominal conditions, where the allocation of functions depends on the nature of the deviation:
For abrupt deviations corresponding to novel and unstructured situations, human strengths in improvisation and inductive reasoning are still unachieved by AI, whose role is therefore relegated to information acquisition, supporting the human who leads analysis, planning and execution. This corresponds to a Type 1 dynamic.
For slow-dynamics deviations, the problem is perception, as changes are often too subtle for humans to detect. Here, AI’s ability to sense and analyse gradual trends is crucial. Type 3 dynamic is preferable, with AI detecting and diagnosing drift (MA) and proposing a corrective plan (P), which the human validates before execution (E).
DME tasks require computational analysis and contextual judgment. Following Parasuraman’s model, AI is best suited for the initial stages: information acquisition and analysis (MA), where it can process large datasets without bias. However, the final decision (P) often requires human intuition, especially in novel situations. Therefore, Type 3 dynamic, where the AI proposes optimised plans and the human validates or refines them, represents the most effective synergy.
ART targets indeed highly structured and frequent tasks. Based on function allocation principles (Fitts et al., 1951), machines excel at repetitive, high-precision actions prone to human fatigue-errors. Here, AI should handle every stage of the task (MA and PE). This corresponds to a higher level of automation, making Type 2 (AI Master) the most suitable dynamic.
6. Results
6.1 Overall description of the cases
The four cases proposing self-X implementation are described and classified by humachine characteristics as follows.
Asphalt case is a distributed PI including a production site where aggregates are mixed with bitumen, a laboratory quality system tests the properties of the material, and a network of mixer trucks take care of logistics and paving:
Controller “a” designs product mix recipes by prediction of the theoretical properties of produced material.
Controller “b” diagnoses faults in real-time in the production plant.
Controller “c” sets the material temperature when it is loaded on the trucks at the production plant, based on an estimation of temperature on the paving zone to save heating costs.
While controller “a” requires self-X properties to handle domain shifts caused by variability in feedstock, controller “b” is also affected, as material changes influence vibrations and burner efficiency. Meanwhile, controller “c” requires self-X properties to address environmental effects, which may be seasonal or not.
Steel case is a company producing secondary steel through an Electric Arc Furnace (EAF) melting metal scrap to produce recycled steel. The case is focused on the EAF, in terms of process-control and in terms of process control, recipe design, and stockpile management. Indeed:
Controller “a” supervises the EAF parameters to match the predicted chemical composition of a production, considering quality and quantity of input scrap materials.
Controller “b” optimises in a moving-horizon perspective the scrap usage, basing on the availability and the chemical estimation of the scrap stocks.
Controller “c” solves the operative research problem of designing (and re-designing) production recipes for different alloys based on the available metal scrap.
All the controllers are strongly interconnected and need self-X attributes to face the issue of domain shift, given the variability of chemical composition of the input scrap material.
Pharma case is a pilot-size installation allowing the conversion of cortisone to adrenosterone via an electro-chemical reaction (Petrović et al., 2023). The installation aims at testing different production setups to experimentally verify the most favourable ones, allowing a reduction of the operative costs related to electrical consumption and usage of consumable (i.e. electrodes subject to corrosion). In particular:
Controller “a” maximises the chemical reaction rate against power consumption and electrodes lifespan.
Controller “b” regulates the reaction rate optimising settling-time and closed-loop stability. Reaction rate is measured through Fourier-Transform Infrared spectroscopy (FTIR).
Controller “c” detects ineffective positioning of the sensor (Optical Coherence Tomography, OCT) monitoring electrodes wear.
In this case, the need for self-X attributes is implied by the wearing process of electrodes, which change the parameters of the system to be controlled, and by the deviations of OCT positioning.
Aluminium case is similar to the steel one, given the similarities in scrapyard and melting processes. The main difference lies in the operative conditions (i.e. input scrap material is systematically tested before being accordingly stored in separated silos) but also in terms of challenges, since it is limited to “a” and “c” tasks presented in the steel case study, whereas moving-horizon planning is not considered part of the case study due to lower production volumes.
6.2 Application of the proposed framework and procedure
6.2.1 Step 1 – AI application context
The classification in Table 2 reflects targets pursued by each case, where several AI application contexts may be addressed through parallel tasks:
AI application contexts’ definition
| AI application context . | Planning . | Process setup optimisation . | Process r/t control . |
|---|---|---|---|
| Asphalt | ✔ | ✔ | |
| Steel | ✔ | ✔ | ✔ |
| Pharma | ✔ | ✔ | |
| Aluminium | ✔ |
| AI application context . | Planning . | Process setup optimisation . | Process r/t control . |
|---|---|---|---|
| Asphalt | ✔ | ✔ | |
| Steel | ✔ | ✔ | ✔ |
| Pharma | ✔ | ✔ | |
| Aluminium | ✔ |
Asphalt
1a (recipe design) and 1c (set of loaded material temperature) fall under Process setup optimisation, while 1b (fault detection) involves lower time-dynamics and belongs to the Process r/t control one.
Steel
2a (EAF parameters definition) is classified as belonging to the Process setup optimisation category, with process monitoring features also placing it in process r/t control, 2b (scrap usage optimisation) is a planning process, belonging to the corresponding category; 2c (recipe design) belongs to Process setup optimisation.
Pharma
3a (chemical reaction rate maximisation) falls under Process setup optimisation, while 3b (reaction rate regulation) and 3c (electrodes misplacing detection) operate in closed-loop control, belonging to Process r/t control category.
Aluminium
Similar to Steel, but without a task equivalent to 2b, and with 4a disconnected from real-time monitoring, its controls belong to Process setup optimisation only.
6.2.2 Step 2 – humachine target
Since every case implements one or many AI applications and every AI application can pursue several humachine targets, it is significant that the most common target concerns the need for making more efficient some decision-making processes (DME). Table 3, correlates the AI application contexts with their humachine targets.
Industrial cases
| Case . | Requirement . | PDCE . | DME . | ART . |
|---|---|---|---|---|
| Asphalt | Planning | - | - | - |
| Process setup optimisation | 1a aims at improving efficiency for existing products | 1a assists at implementing new products | 1c intervenes at every production lot dispatch at paving site | |
| Process r/t control | - | 1b is expected to recognise anomalous conditions | - | |
| Steel | Planning | - | Cost optimisation for feedstock usage via moving horizon approach (2b) | - |
| Process setup optimisation | Setup parameters are optimised to guarantee material final chemistry, furnace temperature, metallurgical quality (2c when re-designing) | Setup parameters are optimised to guarantee material final chemistry, furnace temperature, metallurgical quality (2c when designing) | Simulation tool for EAF recipe (2a) is integrated into the automation system to support technological debugging | |
| Process r/t control | - | - | - | |
| Pharma | Planning | - | - | - |
| Process setup optimisation | 3a optimises production settings | - | - | |
| Process r/t control | OCT misplacing is to be detected and avoided before production starts (3c) | - | Controller (3b) regulates the reaction rate after FTIR measurement | |
| Aluminium | Planning | - | - | - |
| Process setup optimisation | Setup parameters are optimised to guarantee material final chemistry, furnace temperature, metallurgical quality (4c) | Setup parameters are optimised to guarantee material final chemistry, furnace temperature, metallurgical quality (4c) | Setup parameters optimisation is a repetitive task to be automatised (4a) | |
| Process r/t control | - | - | - |
| Case . | Requirement . | PDCE . | DME . | ART . |
|---|---|---|---|---|
| Asphalt | Planning | - | - | - |
| Process setup optimisation | 1a aims at improving efficiency for existing products | 1a assists at implementing new products | 1c intervenes at every production lot dispatch at paving site | |
| Process r/t control | - | 1b is expected to recognise anomalous conditions | - | |
| Steel | Planning | - | Cost optimisation for feedstock usage via moving horizon approach (2b) | - |
| Process setup optimisation | Setup parameters are optimised to guarantee material final chemistry, furnace temperature, metallurgical quality (2c when re-designing) | Setup parameters are optimised to guarantee material final chemistry, furnace temperature, metallurgical quality (2c when designing) | Simulation tool for EAF recipe (2a) is integrated into the automation system to support technological debugging | |
| Process r/t control | - | - | - | |
| Pharma | Planning | - | - | - |
| Process setup optimisation | 3a optimises production settings | - | - | |
| Process r/t control | OCT misplacing is to be detected and avoided before production starts (3c) | - | Controller (3b) regulates the reaction rate after FTIR measurement | |
| Aluminium | Planning | - | - | - |
| Process setup optimisation | Setup parameters are optimised to guarantee material final chemistry, furnace temperature, metallurgical quality (4c) | Setup parameters are optimised to guarantee material final chemistry, furnace temperature, metallurgical quality (4c) | Setup parameters optimisation is a repetitive task to be automatised (4a) | |
| Process r/t control | - | - | - |
6.2.3 Step 3 – case studies’ humachine dynamics types
Cases can hence be classified by humachine dynamics, as depicted by Table 4.
Humachine dynamics for the four cases’ applications
| Case . | Requirement . | Humachine dynamics classification . |
|---|---|---|
| Asphalt | Process setup optimisation | 1a is PDCE when it refers to an existing product for which the current mix recipe is not satisfactory and it is of a DME when about a new product |
| Type implemented: Type 1 (in both cases) | ||
| Analysis: in the current implementation of the mix recipe optimisation several prediction tools are applied but no direct actuation of the automatic decision is ever foreseen, therefore the implemented humachine is always Type 1, while for DME target (new product design) a Type 3 is the desirable option, and for PDCE target (existing product optimisation) the implemented humachine is in line with the desirable option (Type 1) | ||
| 1c is ART since it is deterministically executed every time material is dispatched for defining the target loading temperature | ||
| Type implemented: Type 1 | ||
| Analysis: Type 1 mismatches the desirable option (Type 2) because of the incapability to precisely predict temperature at paving site | ||
| Process r/t control | 1b is DME since technology aims at making diagnoses | |
| Type implemented: Type 1 | ||
| Analysis: Type 1 mismatches the desirable option for a DME target (Type 3) for the automatic reconfiguration. Indeed, ML technologies provide suggestions only, while human validates anomalies and determines mitigation actions | ||
| Steel | Planning | Planning is activated by a human operator (2b) to ensure optimal scrap usage. It is a DME task, since planning tool proposes a solution, and human intervention occurs only if the proposed solution is deemed suboptimal. Moreover, scenario exploration is a typical feature of planning tools, as simulations allowing exploration of alternative scenarios. However, the application of the final plan might be the result of human-MAPE-K cooperation even if systematically human supervised |
| Type implemented: Type 3 | ||
| Analysis: in this case, the implemented type is in line with the DME desirable option | ||
| Process setup optimisation | A simulation tool for the EAF recipe (2a) is integrated into the automation system to identify root causes of production non-conformities. Aligning with the need for automated diagnosis, it is an ART-type application | |
| Type implemented: Type 1 | ||
| Analysis: Type 1 does not match the desired configuration for ART target, which would require Type 2 | ||
| 2c is a PDCE when it refers to re-designing recipes, and a DME when it refers to a new design | ||
| Type implemented: Type 1 (in both cases) | ||
| Analysis: in the current implementation of the design/re-design of a recipe making several prediction tools are applied, but no direct actuation of the automatic decision is foreseen; therefore, the humachine type for the DME target is not the desired one (Type 3), whereas it corresponds to the desirable option and for a PDCE target (Type 1) | ||
| Pharma | Process setup optimisation | The process settling optimisation (3a) can be classified as a PDCE task since the process might be standardised once enough data is collected in all possible working points |
| Type implemented: Type 1 | ||
| Analysis: the implemented type is coherent with the desired one for a PDCE target. | ||
| Process r/t control | An MPC acts continuously on the basis of an incapsulated predictive ML model to regulate a chemical reaction (3b, target classification ART). The controller freezes if the control trim exceeds a tolerance level and, in this case, human intervention is required for correction. In the nominal conditions, the reference generated by the MPC controller is actuated in an unsupervised way. ML model is also applied to automatically define the controller initial settings | |
| Type implemented: Type 2 | ||
| Analysis: the implemented type is coherent with the desired one for an ART target. | ||
| The ML model is also used to diagnose possible OCT misplacements (3c, target classification PDCE). In case of anomaly detection, the OCT positioning remains human actuated | ||
| Type implemented: Type 1 | ||
| Analysis: the implemented type is coherent with the desired one for a PDCE target. | ||
| Aluminium | Process setup optimisation | A simulation tool for the recipe (4a) is integrated into the automation system to identify the root cause of production non-conformities. Aligning with the need for automated diagnosis, it is an ART-type application |
| Type implemented: Type 1 | ||
| Analysis: Type 1 does not match the desired configuration for ART target, which would require Type 2 | ||
| 4c is a PDCE when it refers to re-designing recipes, and a DME when it refers to a new design. Collaboration with the human is realised by generating three different recipes, allowing the human to select the most reliable one. In this case, generative AI is applied | ||
| Type implemented: Type 3 (in both cases) | ||
| Analysis: in this case, the implemented type is in line with the DME desirable option | ||
| Case . | Requirement . | Humachine dynamics classification . |
|---|---|---|
| Asphalt | Process setup optimisation | 1a is PDCE when it refers to an existing product for which the current mix recipe is not satisfactory and it is of a DME when about a new product |
| Type implemented: Type 1 (in both cases) | ||
| Analysis: in the current implementation of the mix recipe optimisation several prediction tools are applied but no direct actuation of the automatic decision is ever foreseen, therefore the implemented humachine is always Type 1, while for DME target (new product design) a Type 3 is the desirable option, and for PDCE target (existing product optimisation) the implemented humachine is in line with the desirable option (Type 1) | ||
| 1c is ART since it is deterministically executed every time material is dispatched for defining the target loading temperature | ||
| Type implemented: Type 1 | ||
| Analysis: Type 1 mismatches the desirable option (Type 2) because of the incapability to precisely predict temperature at paving site | ||
| Process r/t control | 1b is DME since technology aims at making diagnoses | |
| Type implemented: Type 1 | ||
| Analysis: Type 1 mismatches the desirable option for a DME target (Type 3) for the automatic reconfiguration. Indeed, ML technologies provide suggestions only, while human validates anomalies and determines mitigation actions | ||
| Steel | Planning | Planning is activated by a human operator (2b) to ensure optimal scrap usage. It is a DME task, since planning tool proposes a solution, and human intervention occurs only if the proposed solution is deemed suboptimal. Moreover, scenario exploration is a typical feature of planning tools, as simulations allowing exploration of alternative scenarios. However, the application of the final plan might be the result of human-MAPE-K cooperation even if systematically human supervised |
| Type implemented: Type 3 | ||
| Analysis: in this case, the implemented type is in line with the DME desirable option | ||
| Process setup optimisation | A simulation tool for the EAF recipe (2a) is integrated into the automation system to identify root causes of production non-conformities. Aligning with the need for automated diagnosis, it is an ART-type application | |
| Type implemented: Type 1 | ||
| Analysis: Type 1 does not match the desired configuration for ART target, which would require Type 2 | ||
| 2c is a PDCE when it refers to re-designing recipes, and a DME when it refers to a new design | ||
| Type implemented: Type 1 (in both cases) | ||
| Analysis: in the current implementation of the design/re-design of a recipe making several prediction tools are applied, but no direct actuation of the automatic decision is foreseen; therefore, the humachine type for the DME target is not the desired one (Type 3), whereas it corresponds to the desirable option and for a PDCE target (Type 1) | ||
| Pharma | Process setup optimisation | The process settling optimisation (3a) can be classified as a PDCE task since the process might be standardised once enough data is collected in all possible working points |
| Type implemented: Type 1 | ||
| Analysis: the implemented type is coherent with the desired one for a PDCE target. | ||
| Process r/t control | An MPC acts continuously on the basis of an incapsulated predictive ML model to regulate a chemical reaction (3b, target classification ART). The controller freezes if the control trim exceeds a tolerance level and, in this case, human intervention is required for correction. In the nominal conditions, the reference generated by the MPC controller is actuated in an unsupervised way. ML model is also applied to automatically define the controller initial settings | |
| Type implemented: Type 2 | ||
| Analysis: the implemented type is coherent with the desired one for an ART target. | ||
| The ML model is also used to diagnose possible OCT misplacements (3c, target classification PDCE). In case of anomaly detection, the OCT positioning remains human actuated | ||
| Type implemented: Type 1 | ||
| Analysis: the implemented type is coherent with the desired one for a PDCE target. | ||
| Aluminium | Process setup optimisation | A simulation tool for the recipe (4a) is integrated into the automation system to identify the root cause of production non-conformities. Aligning with the need for automated diagnosis, it is an ART-type application |
| Type implemented: Type 1 | ||
| Analysis: Type 1 does not match the desired configuration for ART target, which would require Type 2 | ||
| 4c is a PDCE when it refers to re-designing recipes, and a DME when it refers to a new design. Collaboration with the human is realised by generating three different recipes, allowing the human to select the most reliable one. In this case, generative AI is applied | ||
| Type implemented: Type 3 (in both cases) | ||
| Analysis: in this case, the implemented type is in line with the DME desirable option | ||
As summarised in Table 5, Type 2 applications (purely driven by AI) are currently considered impractical by industry. Among the cases, only Pharma shows significant adoption, where AI is part of the MPC system controlling the chemical reaction. This level of autonomy is justified by the inherent limitations of human sensing in such process.
Implemented vs desirable humachine dynamics types
| . | Human is master (Type 1) . | MAPE-K is master (Type 2) . | Collaborative humachine (Type 3) . |
|---|---|---|---|
| Implemented humachine dynamics type | 10 | 1 | 3 |
| Desirable humachine dynamics type | 4 | 4 | 6 |
| . | Human is master (Type 1) . | MAPE-K is master (Type 2) . | Collaborative humachine (Type 3) . |
|---|---|---|---|
| Implemented humachine dynamics type | 10 | 1 | 3 |
| Desirable humachine dynamics type | 4 | 4 | 6 |
Conversely, Type 3 implementations are also rare, with human–AI collaboration limited to the early stages of production: Planning in the steel case and Process setup optimisation in the aluminium one.
Finally, Type 1 systems are the most common across the explored cases, due to the influence of environmental variables that are not directly measurable by sensors and therefore difficult to manage through fully automated control systems.
7. Discussion
AC can be viewed as a discipline addressing AI/ML limitations in PI’s application. This study integrates self-X properties into the RAMI4.0 paradigm, clarifying their feasibility in industrial settings. It then introduces a procedure to classify self-X solutions by application contexts, targets and humachine interaction type.
The analysis of four case studies revealed a significant divergence between observed humachine dynamics and the expectations set by the human-centric paradigms. While literature predicts sophisticated human–AI collaboration (O’Neill et al., 2022), findings show persistent dominance of Type 1 systems. In most implementations, the human holds the master role, positioning PI as a sector granting employees high autonomy and responsibility. This suggests industry’s AI adoption is more cautious and human-centric than often portrayed (Harms and Han, 2019), with AI tools frequently relegated to supporting roles.
The struggle to deploy Type 2 systems stems from PI unpredictability. The analysis shows how feasibility appears only in highly controlled scenarios where human perception is limited (e.g. chemical reaction control in Pharma case). Conversely, sectors like asphalt and steel face feedstock variability that current AI controllers struggle to manage autonomously. Frequent need for human improvisation makes giving full control to an AI a high-risk choice, limiting Type 2 to highly specialised tasks.
Similarly, Type 3 adoption is confined to less time-critical, higher-level tasks like planning and setup optimisation: here, the barriers may arise from socio-technical phenomena: in the observed cases, collaboration occurs through AI-generated alternatives, later chosen, validated or modified by humans. Thus, while AI handles analysis (MA), decision-making authority (PE) remains human. Therefore, achieving actual human–AI partnership requires more than accurate algorithms and needs investment in transparent, explainable AI to build operator trust and effectively integrate human expertise into control loops, confirming initial literature findings.
In this light, the theoretical contribution of this work first relates to the systematic literature review in Section 2, which noted how AI shortcomings are mainly addressed incrementally, while this study proposes a structured approach. Then, the main contribution lies in the cross-fertilisation of three different paradigms: it resumes concepts from AC to address the dynamic nature of PI environments, involving the humachine concept from socio-technical studies to model human–AI collaboration, while leveraging on RAMI4.0 architecture to ground the analysis in a well-known industrial standard, framing it in a holistic perspective and distinguishing from the available literature, which often treats them as three separated concepts. The framework also responds to an emerging need from the literature for new approaches to human-automation integration: seminal works highlighted the need for evaluation of function allocation in socio-technical systems and more recent studies underscored the need for deeper understanding of collaborative dynamics (Pinzone et al., 2020), but practical tools at process control level have been lacking (Melo et al., 2023); the procedure here described offers a scalable method to move from high-level goals of human centricity to the granular analysis of control loops. Finally, the present study contributes to shed light on PI, a domain that despite its economical relevance, is often less discussed than discrete manufacturing in the human-automation literature (Doran et al., 2025).
Practically, the three-step procedure offers managers and designers a diagnostic and design tool which completes strategic frameworks like Maturity Models through a shopfloor-level method to translate high-level goals into practice, allowing organisations to identify mismatches between planned AI’s autonomy and task’s complexity, set implementation expectations, focus development on critical bottlenecks, such as building trust and improving collaborative interfaces rather than just model accuracy, everything framed in a well-known RAMI4.0. For instance, a company planning AI adoption can exploit the procedure as an analysis tool by classifying the intended application (e.g. Process setup optimisation at L2), identifying the target (e.g. DME), and comparing the planned humachine dynamic type with the desiderata one (e.g. Type 3 for DME), identifying potential mismatches, which could lead to underusage of AI functionalities and expensive post-implementation actions.
8. Conclusions
This study is, however, limited by the number of cases; therefore, the humachine analysis procedure will require further validation in other PI sectors, and future efforts should use quantitative metrics assessing the effectiveness of humachine dynamics types. Nevertheless, the identified patterns provide an initial foundation and suggest the framework’s generalisability. Therefore, future research could test these findings in other domains, such as discrete manufacturing, where AC is being employed to address resource allocation in flexible scenarios (Müller et al., 2022).
Looking ahead, challenges in deploying Type 2 and Type 3 highlight the need for robust AI that handles uncertainty and human-centric interfaces that foster trust. Emerging technologies like generative AI may offer new synergies (Lin et al., 2023). By potentially enhancing the “Planning” phase of the MAPE-K loop through more intuitive and natural interactions, such technologies could ground true Type 3 collaboration, bridging the gap between human expertise and machine intelligence in industrial control.
This research provides empirical evidence that, against technological determinism, the adoption of AI in PI remains deeply human-centric. Observed gaps between desirable and actual levels of automation highlight that socio-technical challenges are significant barriers to deploying more advanced human–AI partnerships. Addressing these challenges is a critical requirement for exploiting AI, suggesting that future research must prioritise the co-design of intelligent systems where human expertise and machine capabilities are not just co-located, but truly integrated.

