An Intelligent Human–Machine Interface Architecture for Long-Term Remote Robot Handling in Fusion Reactor Environments

Abstract

This paper addresses the intricate challenge posed by remote handling (RH) operations in facilities with operational lifespans surpassing 30 years. The extended RH task horizon necessitates a forward-looking strategy to accommodate the continuous evolution of RH equipment. Confronted with diverse and evolving hardware interfaces, a critical requirement emerges for a flexible and adaptive software architecture based on changing situations and past experiences. The paper explores the inherent challenges associated with sustaining and upgrading RH equipment within an extended operational context. In response to this challenge, a groundbreaking, flexible, and maintainable human–machine interface (HMI) architecture named MAMIC is designed, guaranteeing seamless integration with a diverse range of RH equipment developed over the years. Embracing a modular and extensible design, the MAMIC architecture facilitates the effortless incorporation of new equipment without compromising system integrity. Moreover, by adopting this approach, nuclear facilities can proactively steer the evolution of RH equipment, guaranteeing sustained performance and compliance throughout the extended operational lifecycle. The proposed adaptive architecture provides a scalable and future-proof solution, addressing the dynamic landscape of remote handling technology for decades.

1. Introduction

Nowadays, the field of remote handling (RH) integrates many technical fields (electronics, communications, control, computer vision, artificial intelligence, augmented reality, etc.), and all of them, in general, work synergistically. Currently, there are outstanding new fields that add intelligence to RH robots; this is something very interesting because it simplifies the traffic and criticality of the information exchanged from/towards the operator, letting the robot act on its own [1]. Moreover, if we were able to model how the best operator carries out a series of complex tasks, we could reduce task times and human error risks introduced due to fatigue, boredom, or lack of experience.

These technological advances and others that RH is currently working on have made it possible to achieve great innovations in the nuclear fusion sector. Since 1930, scientists and increasingly also engineers have been continuously searching to discover how to recreate and harness nuclear fusion to provide virtually limitless clean, safe, and affordable energy to meet the world’s energy demand. Fusion can generate four times more energy per kilogram of fuel than fission, which is used in nuclear power plants, and nearly four million times more energy than burning oil or coal.

More than 50 countries have carried out multiple nuclear fusion and plasma physics research, and fusion reactions have been successfully produced in many experiments. Different designs and magnet-based machines have been developed to initiate fusion, like stellarators and tokamaks (this design is under study in this thesis), as well as approaches that rely on lasers, linear devices, and advanced fuels.

One of these countries is France, where the world’s largest international fusion facility, named ITER, is being designed and manufactured across the world [2]. ITER endeavors to demonstrate the scientific and technological viability of producing fusion energy and validate technology and concepts for future fusion power plants that will generate electricity, referred to as DEMO. ITER will initiate its initial experiments in the latter half of the 2020s, and full-power tests should begin in the latter half of the 2030s [3]. The timeline for DEMO varies among different countries, but experts agree that an electricity-generating fusion power plant could be constructed and operational by 2050.

All these facilities have the same problem: the RH control systems will need to be operated from a dedicated remote control room that consists of many modules and technologies that must be operational over the lifetime of the fusion project (estimated at more than 30 years, including initial assembly and final decommissioning in the case of the ITER project). Therefore, the operation and supervision of these RH systems in environments requiring long-term flexibility and safety have increasingly necessitated the adoption of efficient graphical interfaces, prompting the need for a new innovative architecture proposal: Multiple Agent Managerial Intelligent Control (MAMIC). The MAMIC model allows the interaction of these systems with the operator in a unique, fast, and simple manner in response to varying situations and past experiences. Moreover, the repeatability required for industrialization underscores the significant importance of having reference models rather than each implementation being custom-built.

Section 2 reviews the evolution of software architecture in recent decades due to the increasing complexity of computing systems and the need to adapt to rapid technological changes and concludes that combining different approaches can lead to more robust architectures, such as those that RH facilities require. Section 3 presents the preliminary stages of the study (requirements and software lifecycle) aimed at developing a proposal for an architecture model that integrates multiple methodologies. Section 4 explores a completely new architecture model that addresses the anticipated needs in the technical specification phase while considering its lifetime, cost reduction, and risk mitigation over time. Last, the model application in the ITER case is summarized for convenience in Section 5 and Section 6, including the model validation into the requirement phase, while Section 7 provides a short conclusion and future work. Following a list of acronyms, the article concludes with one appendix. Appendix A provides a detailed description of the remote robot handling intelligent human–machine interface architecture requirements.

2. Software Architecture Models Evolution Study

In the past decades, the software architecture landscape has witnessed significant evolution driven by the escalating complexity of computing systems and the imperative to adapt to a rapidly changing technological environment. During this period, diverse architectural frameworks and methodologies have emerged and evolved to address the unique challenges faced by software developers and architects. Among these architectures and methodologies, the most influential in the aforementioned environments are the following:

• Anthropomorphic approach: Rooted in human-centered design principles, the anthropomorphic approach places a strong emphasis on understanding and accommodating human needs and behaviors in system design [4]. While it enhances the user experience and adaptability, it may introduce complexity in implementation and require extensive user research.
• Predictive modeling: Leveraging data analytics and machine learning techniques, predictive modeling enables systems to anticipate future events and trends based on historical data. This fosters informed decision-making and resource optimization, but may be limited by data quality and the dynamic nature of real-world scenarios [5,6].
• Cognitive architecture: Inspired by human cognition, cognitive architecture seeks to replicate cognitive processes within software systems, enabling them to perceive, reason, and adapt like humans. While it enhances system intelligence and user interaction, it may entail significant computational overhead and require complex modeling [7].
• Hexagonal architecture: Offering a modular and adaptable design approach, hexagonal architecture decouples core system logic from external dependencies, promoting scalability and maintainability. However, it may introduce additional architectural complexity and require careful planning to ensure seamless integration [8].
• Design thinking: Design thinking fosters innovation by empathizing with user needs, ideating creative solutions, and iterating through prototyping and feedback cycles [9]. Its user-centric approach enhances solution relevance and usability, yet may lead to ambiguity in requirements and feasibility.
• Lean startup: Rooted in rapid experimentation and customer feedback, lean startup accelerates product development and validation. While it fosters agility and market responsiveness, it may prioritize speed over quality and overlook long-term scalability [10].
• Domain-driven design (DDD): DDD focuses on modeling complex business domains to align software architecture with business requirements [11]. By promoting a shared understanding of domain concepts, it enhances system flexibility and maintainability. However, it may require extensive domain expertise and introduce overhead in domain modeling.
• Agile development: Agile methodologies emphasize iterative development, collaboration, and adaptability to changing requirements [12]. They enhance transparency and stakeholder engagement but may pose challenges in managing scope and ensuring comprehensive documentation.
• Service-oriented architecture (SOA): SOA organizes systems as interoperable services, facilitating flexibility and reusability [13]. It promotes modular design and interoperability, yet may introduce complexity in service orchestration and governance.

While these architectures and methodologies offer a range of advantages, they also present unique challenges and limitations that must be carefully addressed. When evaluating and selecting an architecture or methodology for a specific project, it is crucial to consider the business needs and objectives, as well as the project’s context and technical requirements. In the realm of complex system design, as mentioned before, the adoption of a singular methodology or approach may not suffice to address all dimensions and challenges that arise. It is within this context that the notion of combining different approaches and methodologies to create more robust and adaptable architectures emerges.

In this regard, the integration of approaches such as the anthropomorphic approach, predictive modeling, and cognitive architecture, along with the hexagonal architecture, can provide a more comprehensive and holistic vision in the design and development of advanced systems.

The advantages of this integration are manifold and significant. Whereas the anthropomorphic approach emphasizes the importance of understanding human needs and expectations in system design, leading to an enhanced user experience and greater acceptance of proposed solutions, predictive modeling offers the ability to forecast future events based on historical data, facilitating informed decision-making and resource optimization across various contexts.

Furthermore, the inclusion of cognitive architecture provides a framework for modeling human cognitive processes, enabling the design of systems that are more intuitive and adaptable to human interaction. Finally, the hexagonal architecture offers a flexible and modular structure for software development, promoting the separation of concerns and facilitating adaptation to technological and business changes.

By combining these approaches, an architecture can be achieved that is not only technically sound but also sensitive to human needs and behaviors, capable of anticipating future events, and easily adaptable to changes in the environment. This integration offers a holistic approach to complex system design, allowing developers to effectively and efficiently tackle a wide range of challenges.

In the subsequent analysis (

Table 1. Analysis of the different architecture evolutions, focusing on the anthropomorphic approach, predictive modeling, cognitive architecture, and hexagonal architecture.

Architecture	Origin	Evolution	Current Application
Anthropomorphic Approach	This approach has deep roots in human–computer interaction and cognitive psychology. The aim is to create systems that better understand and adapt to human needs and preferences [4].	Over the decades, this approach has evolved with advances in understanding human psychology, ergonomics, and user-centered design [14].	This approach is used in the design of user interfaces, virtual assistants, artificial intelligence systems, and robotics [15].
Predictive Modeling: ARCH	It has existed in various forms throughout history but has undergone rapid development with the advent of computing and access to large amounts of data [5,6].	With the advancement of statistical and machine learning techniques, predictive modeling has become a powerful tool for forecasting future events in a variety of domains [16].	It is used in a wide range of applications, from weather prediction to product recommendations on e-commerce platforms. It is also fundamental in areas such as personalized medicine and financial risk management [17].
Cognitive Architecture: RCS	Developed in the fields of artificial intelligence and cognitive psychology to understand and replicate human cognitive processes [7,18,19,20,21]. An RCS is similar to other cognitive architectures by representing procedural knowledge through production rules and hldeclarative knowledge (abstract data structures: frames, classes, and semantic nets [22]). RCSs originated as a real-time intelligent control system designed to operate real machines interacting with actual objects in the tangible world.	Over the decades, researchers have developed a variety of cognitive architecture models to simulate human mental functions, such as perception, attention, memory, and reasoning. Throughout its developmental stages, all symbols within the RCS world model have been firmly linked to objects and states in the tangible world. The latest iteration, 4D/RCS, incorporates elements of Dickmanns’ 4D approach to machine vision [23,24] within the RCS control architecture.	Applied in decision support system training and simulation systems. Initially, it served as a sensory-interactive, goal-directed controller for a laboratory robot [25]. Over time, RCSs have evolved into an intelligent controller applicable to industrial robots, machine tools, intelligent manufacturing systems, automated mail facilities, stamp distribution systems, mining equipment, unmanned underwater vehicles, and unmanned ground vehicles [26,27].
Hexagonal Architecture	Proposed by Alistair Cockburn (early 2000s) to improve the design of complex software systems. The key distinction from others is the business logic separation from technical implementation details, making business logic easier to test, evolve, and change independently of the underlying technology [8].	Since its initial proposal, hexagonal architecture has gained popularity as an effective approach for creating scalable, flexible, maintainable, and easily testable software systems [13].	Currently, hexagonal architecture is widely used in software development across a variety of domains, from web applications to embedded systems. It is especially popular in environments where high flexibility and adaptability to technological and business changes are required [13].

), how each of these approaches can complement and reinforce one another in the creation of advanced system architectures to transition from a flexible model to an intelligent open model is explored in detail.

Combining all the mentioned approaches can be an interesting and potentially beneficial challenge, as each brings unique perspectives and can address different aspects of a complex system:

• Multidisciplinary analysis: Conduct a multidisciplinary analysis of the problem you are addressing, considering both the technical and cognitive/human aspects involved. This will help you better understand the context and the system’s needs.
• User-centered design: Utilize the anthropomorphic approach to design systems that better adapt to users’ needs, expectations, and behaviors. This may include designing intuitive interfaces and considering emotional and cultural factors in human–computer interaction.
• Cognitive modeling: Integrate cognitive models, inspired by cognitive architecture, to understand how users interact with and process information within the system. This can help identify behavioral patterns and optimize system usability.
• Prediction and optimization: Employ predictive modeling techniques to forecast future events and optimize system performance. For example, you can apply predictive analytics techniques to anticipate resource demand and optimize resource planning and allocation accordingly.
• Modular and decoupled architecture: Implement hexagonal architecture to organize the system design into clearly defined and decoupled layers. This will facilitate system modification and maintenance over time while providing flexibility to adapt to technological or requirement changes.
• Validation and feedback: Incorporate continuous feedback loops and validation with real users to iterate and constantly improve the system design. This can help ensure that the system meets users’ expectations and needs, as well as identify improvement opportunities.

3. Software Lifecycle in the Remote Handling Environment

Defining a software lifecycle plays a fundamental role in designing an architecture that blends all the aforementioned approaches. Moreover, reliability, availability, maintainability, and safety (RAMS) are eminent requirements of RH systems. The primary software lifecycle phases extracted from ISO-12207 [28] are as follows:

• Software Requirement Analysis Process.
• Software Architectural Design Process.
• Software Detailed Design Process.
• Software Construction Process.

  -

  Coding.

  -

  Module testing.

• Software Integration Process.

  -

  Integration.

  -

  Integration testing.

• Software Qualification Testing Process.

The development and operation of a system of this complexity require rigorous adherence to safety engineering, quality assurance, validation and verification, requirement management, and requirement traceability processes to ensure reliability and fail-safe operation.

In short, an architecture that integrates multiple approaches must be designed, paying special attention to requirement gathering and the software lifecycle (

Table 2. Requirement gathering and software lifecycle definition from the perspective of the various architecture approaches under study.

Architecture	Requirements	Software lifecycle
Anthropomorphic Approach	In this approach, the needs, expectations, and behaviors of end-users are crucial. Also, it emphasizes the importance of comprehending human characteristics to design systems that adapt to them. During requirement gathering, cognitive and emotional aspects influencing human–computer interaction must be identified.	In defining the software lifecycle, specific stages for user-centered design should be included, where usability testing is conducted and user feedback is gathered for iterative design.
Predictive Modeling: ARCH	This approach starts by analyzing historical data, trends, and behavioral patterns influencing system requirements over time, which are the main actions during requirement identification. Due to this phase, predictive modeling to anticipate future user needs is leveraged.	In this model, the software lifecycle plans and optimizes the development phase. This includes estimating necessary resources, predicting delivery times, and identifying potential obstacles or risks.
Cognitive Architecture: RCS	This approach searches for requirements associated with human cognitive processes: understanding how users interact with the system, which mental processes are involved, and how systems can be designed to better fit these processes.	The software lifecycle includes stages of modeling and validating human cognitive processes. This involves simulating user–system interactions to evaluate the effectiveness of the cognitive architecture in practice.
Hexagonal Architecture	This architecture prioritizes modularity and flexibility as its essential requirements. Identifying functional and non-functional requirements that determine the modular structure of the system is crucial for designing a scalable and adaptable architecture.	Defining the software lifecycle incorporates agile development practices that leverage the modularity and flexibility of the hexagonal architecture. This includes frequent iterations, unit testing, and continuous refactoring to maintain code quality and consistency.

). Both processes must be adapted to leverage the strengths of each approach and ensure that the resulting system meets the business needs and end-user’s expectations.

4. MAMIC System: A New Model Generation

A reference model architecture delineates the functionalities, entities, events, relationships, and information flow occurring within and across functional modules. It furnishes a framework for delineating functional requirements, designing software to fulfill those requirements, and testing components and systems. By combining the anthropomorphic approach, predictive modeling, and cognitive architecture with the hexagonal architecture, more comprehensive and effective systems can be created that address both technical and cognitive/human aspects holistically.

It is important to note that the application of each approach should be tailored to the project’s specific context and requirements, and the appropriate blend will depend on the domain characteristics and user needs.

Through the combination of these architecture approaches, a novel model emerges named the Multiple Agent Managerial Intelligent Control (MAMIC) system. The MAMIC system requires careful consideration of each component’s functionality and interactions. In

Table 3. Component’s functionalities of anthropomorphic approach, predictive modeling, and cognitive architecture used to combine them into the hexagonal architecture.

Architecture	Special Consideration
Anthropomorphic Approach	Design user interfaces and interactions that are intuitive and adaptive to human behavior. Gather user feedback through surveys, interviews, or usability testing to understand user preferences and needs. Implement features such as personalized recommendations or natural language processing to enhance user experience.
Predictive Modeling: ARCH	Collect and analyze historical data on user behavior, system performance, and external factors. Develop predictive models to anticipate future user actions or system events. Integrate predictive analytics into the system to dynamically adjust behavior or resources based on anticipated events.
Cognitive Architecture: RCS	Model cognitive processes such as perception, learning, and decision-making within the system. Implement algorithms inspired by cognitive science to simulate human-like behavior or reasoning. Design interfaces and interactions that align with human cognitive abilities and limitations.

, some special aspects are detailed to understand how the anthropomorphic approach, predictive modeling, and cognitive architecture could be integrated into the hexagonal architecture.

Integrating these approaches within a hexagonal architecture involves structuring the system into layers with a clear separation of concerns:

• Domain layer: The domain is the innermost layer. It encompasses all core business logic and functionality of the system and remains agnostic of the other layers. It should only vary based on the needs of the business, uninfluenced by external factors. In this layer, the data model is located or “Read model is housed”, and it is crucial to consider modeling it based on the requirements rather than the database model. Furthermore, within this layer, business validations are located in “Value Objects” and “Entities”, as well as the ports of the MAMIC system (adapter interfaces and domain services).
• Application layer: The application layer contains the use cases needed for each “Bounded context” or unit of the MAMIC system. The role of application classes is to orchestrate the necessary classes to execute an action requested by the external systems. Additionally, it handles the translation of primitive data received into objects managed by the domain. The application layer should never be aware of infrastructure details.
• Infrastructure layer: The infrastructure layer is responsible for communication between the MAMIC system and external factors, and vice versa. Its classes are tightly coupled to specific technologies such as frameworks, database engines, specific queuing systems, external libraries, and other infrastructure components. Within this layer, some modules translate information received/sent by other components and entry points to the MAMIC system, among other functionalities.

The MAMIC model, Figure 1, facilitates the integration of these approaches by providing a modular and flexible structure. Each model can be encapsulated within its respective layer, allowing for independent development, testing, and evolution. Additionally, the architecture promotes the separation of concerns, making it easier to maintain and extend the system over time:

• Anthropomorphic approach: Implemented primarily in the application layer, where user interfaces and interaction components reside. User-centric design principles guide the development of interfaces and interactions.
• Predictive modeling: Integrated into both the domain and application layers. Predictive models are part of the business logic in the domain layer, while data processing and analysis components reside in the application layer.
• Cognitive architecture: Implemented within the domain layer, where cognitive processes are modeled and simulated. Algorithms inspired by cognitive science are embedded into the business logic to enable human-like behavior.

In summary, while the MAMIC model proposal offers valuable insights and capabilities, it presents specific challenges related to complexity, resource utilization, technological constraints, and ethical implications.

• Initial complexity: Deploying this methodology could necessitate increased design and configuration efforts owing to its intricate structural nature.
• Resource overhead: The modular nature of this architecture may result in elevated layers and abstractions, which could pose maintenance challenges and overhead.
• Technological limitations: The MAMIC model could be limited by existing technological capabilities, impacting its ability to faithfully replicate human behavior or achieve precise predictive outcomes.
• Computational cost: Sophisticated predictive models may require substantial computational resources, impacting scalability and practical deployment capabilities.
• Ethical considerations: Applying MAMIC principles raises ethical considerations concerning human perception and technology-related expectations.

5. Application to a Specific Case Study: ITER Divertor Remote Handling System

5.1. ITER Environment

The ITER remote handling (RH) [29] system will be operated from a dedicated control room, approx. 1km away from the reactor and designed for full remote operation. The intention is to manage all the necessary equipment for specific RH tasks from a single operations bench known as the RH standard work cell. Given that numerous RH operations will be executed concurrently, the plan is to incorporate multiple work cells within the RH control room.

The ITER RH control system comprises various modules and technologies, necessitating sustained operational functionality throughout the ITER project’s estimated 30-year lifespan, encompassing assembly and decommissioning.

To streamline initial integration and ongoing maintenance, a modular approach is advocated. ITER mandates a fixed modular architecture for all systems, emphasizing a straightforward principle to foster interoperability and maintainability: each control system element should meet its requirements without imposing specific solutions on other elements. For the implementation of the RH standard work cell, this modular approach was realized. Figure 2 illustrates the different modules that configure a work cell.

The ITER remote maintenance system (IRMS) [31] is required to provide full remote handling capability (including rescue) inside the in-vessel area. The IRMS remote handling equipment is the divertor remote handling system (RHS) (DTP2), which is illustrated in Figure 3:

The divertor RHS (toroidal system) is required to perform the following key functions:

• Insertion/extraction of divertor cassettes and their transportation to/from a transfer cask docked at divertor-level RH ports.
• Insertion/extraction of divertor-level diagnostic assemblies and their transportation to/from a transfer cask docked at divertor-level RH ports.
• Removal/replacement of the divertor-level RH port primary closure plate (PCP).
• Dust removal within and around the divertor region during the cassette-removal process.

A work cell to control the divertor RHS will be established based on the latest ITER specifications for the control room and work cell design, incorporating the remote handling and control room software developed for F4E/ITER:

• General-purpose controller (GENROBOT): GENROBOT is a software controller application built to command particular RH systems used across the ITER remote handling environment and is integrated to command RH systems via the RH-IHMI application.
• Remote robot handling intelligent human–machine interface (RH-IHMI): The RH-IHMI software is a single application that provides the operator interface to control and command the different ITER remote handling systems (RHSs) via a customizable graphical user interface. The RH-IHMI software application also allows one to receive information about all the steps present in the presently active method and any step containing an SL instruction designed for RH-IHMI application.
• Virtual reality (VR): The VR software GUIs at ITER RH possess the capability to receive external commands via an interface port. Certain commands trigger script files, referred to as VR internal commands, which enable adjustments to the VR configuration and display. These script files are pre-programmed within the VR models and are also stored within them.
• Input devices: Comprising a joystick and haptic arms. The area where the haptic arms are usually located will be used for exoskeleton/VR and new technologies.
• Operation management systems (OMSs): The OMS software tools are a component of the RH software suite within the high-level control system (HLCS). It establishes communication with various other components of the HLCS, primarily situated within or near the remote handling control room (RHCR). The primary goal of the OMS involves the planning and execution of task procedures. These procedures involve the entire sequence of manual actions necessary to carry out tasks; in the end, the OMS tool essentially drives the remote handling process.
• The RH database (RHDB): This constitutes an integral component of the OMS, along with the OMS task builder and the OMS task executor. It encompasses a comprehensive range of RH task information, covering the following:
  • Super-tasks, sub-tasks, methods, and steps.
  • Instances of RH tools and RH equipment (cross-referenced within super-tasks, sub-tasks, methods, and steps).
  • Associations with external multimedia files (referenced within super-tasks, sub-tasks, methods, and steps).
  • Records of task logs (inclusive of annotations and links generated during task execution).
  • Profiles of RH users and OMS login credentials, with varying permission tiers.
• Mixed reality: Designs an interactive experience in which the sensor readings are combined with HMI-generated content. The content can span multiple sensory modalities, including visual, auditory, haptic, somatosensory, and olfactory. Moreover, other techniques, such as augmented reality, are designed as a system that incorporates three basic features: a combination of real and virtual worlds, real-time interaction, and accurate 3D registration of virtual and real objects.
• Data analysis with artificial intelligence: Incorporating user perception and operator fatigue into the application model operation involves integrating computer vision techniques to effectively direct the operator’s attention to the ongoing tasks. Additionally, to enhance configurability and usability for the operator, artificial intelligence (AI) is integrated into the general application. This requires further investigation into determining optimal operator inputs to train the AI model, including factors such as work hours, RH device activity, task development duration, and more. All these functionalities will be performed under the operator’s supervision, allowing manual intervention at any time to restore the system to a safe state.

5.2. ITER Requirements

The essential requirements of ITER organization [32] for the RH-IHMI software in a critical environment are outlined in Appendix A.

In this table, it is remarkable that providing a user-friendly interface supporting real-time communications with RH systems is necessary. Additionally, the interface must be efficient in monitoring and visualizing large datasets and incorporate robust security measures to prevent unauthorized access. It should also be adaptable to various screen sizes and resolutions and comply with industry standards for reliability and safety. Furthermore, comprehensive logging and auditing features, along with multi-language localization support, are essential. Customizable dashboards and reporting tools, modular architecture for easy maintenance, built-in error handling, and support for integration with other systems complete the list of requirements for this critical software system.

Ultimately, the architecture design process will be guided by hazard and risk assessments, with a recommendation to adopt the ISO-10218 [33] standard for industrial robots to comply with the European Machinery Directive. Furthermore, the ITER nuclear safety control tier is utilized for I&C related to nuclear safety.

ISO-10218-1:2011 §5.4.2 [33]: Safety-related parts of control systems shall be designed so that they comply with PL=d with structure category 3, as described in ISO-13849-1:2006 [34], or so that they comply with SIL 2 with a hardware fault tolerance of 1 with a proof test interval of not less than 20 years, as described in IEC 62061:2005 [35].

5.3. ITER Software Lifecycle Definition

Due to the complexity of the proposed requirements (Annex 1), interaction with numerous external agents, modular integration across different environments, and maintainability over long periods, an iterative software development cycle was chosen. It offers numerous benefits, including increased flexibility, risk mitigation, and stakeholder satisfaction, making it a preferred approach for many software development projects. Integrating an iterative software development cycle within a MAMIC architecture involves structuring the development process to align with the principles of iterative development while leveraging the modular and flexible nature of the MAMIC architecture.

Several steps are necessary to be carried out for the culmination of an iterative software cycle, as has been followed in the case of ITER:

• Incremental development: Breaks down the software development process into smaller increments or iterations, each focused on delivering specific functionality or features. This aligns with the iterative approach, allowing for continuous feedback and improvement.
• Feedback loops: Establishes feedback loops at the end of each iteration to gather input from stakeholders, users, and team members. This feedback informs the next iteration, guiding adjustments and refinements to the system.
• Modular design: Utilizes the modularity of the MAMIC architecture to encapsulate different components and functionalities within distinct modules. Each module represents a self-contained unit with well-defined interfaces, facilitating incremental development and testing.
• Separation of concerns: Maintains a clear separation of concerns within the MAMIC architecture, with distinct layers for domain logic, application logic, and infrastructure. This separation ensures that changes and updates can be made to specific components without affecting the entire system.
• Continuous integration and verification and deployment: Implements automated testing and continuous integration and verification practices to ensure that changes introduced during each iteration are seamlessly integrated into the codebase. This allows for rapid feedback and the early identification of potential issues.
• Adaptability and flexibility: Embraces the flexibility of the MAMIC architecture to accommodate changes and updates throughout the development process. The modular design and separation of concerns enable developers to respond quickly to evolving requirements and priorities.
• Iterative refinement: It continuously refines and improves the system with each iteration based on feedback and lessons learned. This iterative refinement process ensures that the software evolves incrementally, gradually meeting the desired objectives and quality standards.

Taking into account a classic software lifecycle and the considerations carried out in the MAMIC architecture, the following iterative development methodology (IDM) is presented in Figure 4.

5.4. ITER MAMIC Model Definition

By integrating an iterative software development cycle within a MAMIC architecture, teams can effectively manage complexity, respond to change, and deliver high-quality software that meets the evolving needs of stakeholders and users. Focusing on the ITER environment, the MAMIC architecture presents an approach for building software systems with a centralized core that is separate from its interactions with external interfaces. This is realized through the utilization of ports and adapters, as depicted in Figure 5.

The driving agents (primary) are those that initiate the interaction: the external input controller transfers data to the application through a port, the RH task operations in structure language process it in an automatic or semi-automatic way, and third-party frameworks send the data through the adapter to carry out some actions. The driven agents (secondary) are those that respond to the application’s request: a database adapter is called upon by the application to retrieve the data, an RH controller device is commanded by the application layer and also publishes status information through the port, and mixed reality is presented to visualize the in-vessel critical environment.

The domain layer is divided into several bounded contexts. These are a self-contained and delimited space where a specific set of business problems can be solved in isolation from the rest and without affecting anything beyond this context. Each context has its own set of concepts, terms, and specific domain models and may have its own technical implementation. The different bounded contexts depicted in the figure, which comprise the domain layer, are as follows:

• Configuration domain: The MAMIC architecture provides a flexible configuration mechanism that allows customization of the design and the internal logic behavior of the RH-IHMI. This customization is achieved through configuration parameters that are stored in the configuration files and loaded during start-up time.
• Error handling domain: The error management process defines the software behavior when an error occurs during its execution. The basic steps in an error management process are detection, identification, handling, mitigation, and resolution or recovery. Moreover, this domain is in charge of gathering controller event messages from RH devices and VR, AR, RHDB, and OMS actions.
• Task prediction domain/application: This domain is based on predictive modeling, in which artificial intelligence can be included in the RH-IHMI to be more configurable, considering its usability by the operator. Therefore, it is necessary to incorporate the best operator inputs to train the artificial intelligence model, such as work hours, when the RH device is working, how much time has been spent on the development of the task, and so on. This domain allows the driving of processes in an automatic or semi-automatic way. This domain operates under continuous operator supervision, enabling manual intervention to return the system to a safe state at any time.
• World interaction domain: An interactive experience in which the sensor readings are combined with HMI-generated content. The content can span multiple sensory modalities, including visual, auditory, haptic, somatosensory, and olfactory. Moreover, other techniques, such as augmented reality, are designed as a system that incorporates three basic features: a combination of real and virtual worlds, real-time interaction, and accurate 3D registration of virtual and real objects.
• Assistant operation domain: In this domain, a cognitive architecture is applied, dividing the bounded context in different node behavior generation; world modeling, which interacts with the world interaction domain; sensory processing, adding user perception and operator fatigue state; and a value judgment process together with a knowledge database. In each node, there exists both a deliberative and a reactive component. At the lower level, each node completes a reactive control loop driven by feedback from sensors. At the higher level, each node formulates and executes plans intended to fulfill task objectives, priorities, and limitations communicated by commands from above. Within each node, deliberative plans are integrated with reactive behaviors.
• Communication domain: Different communication protocols need to be configured to establish efficient data handling with the RH devices, RH database, augmented reality, virtual reality, I/O input devices, third-party frameworks, CODAC workstations, and OMS applications.

The ITER MAMIC model proposal aims to overcome the deficiencies or constraints of prior architectural models (anthropomorphic, predictive, cognitive, and hexagonal) by implementing the following strategies:

• Adopting a clear, well-defined separation of concerns (bounded context) so the initial complexity can be managed more effectively.
• Minimizing dependencies between modules and optimizing resource allocation, which can mitigate the risk of increased layers and abstractions.
• Designing elements to gracefully degrade or adapt based on available capabilities, allowing for progressive enhancement as technology evolves.
• Employing a scalable MAMIC model that can dynamically allocate resources based on workload can enhance scalability and reduce costs.
• Implementing mechanisms for facilitating user understanding and control over technology interactions.

6. Architecture Model Validation

In today’s rapidly evolving technological landscape, ensuring the quality and reliability of any software system is crucial. One crucial aspect of this process is requirement validation, which represents the concluding phase of requirement engineering. The objective of this stage is to review the final draft of a requirement document to confirm that it accurately represents an acceptable description of the system to be implemented. Inputs to the validation process include the requirement specification, organizational standards, and implicit organizational knowledge. Outputs consist of a list of identified requirement issues and agreed-upon actions to resolve these issues. Applying this rigorous validation methodology, future developments can mitigate risks, enhance user satisfaction, and deliver iterative versions that meet or exceed expectations.

In this section, the validation process of the MAMIC architecture is conducted against a requirement matrix provided in Appendix A and consists of tracing the requirements established by ITER to address the scenarios defined in the RHS divertor against the software lifecycle and various layers that make up the reference model architecture, shown in

Table 4. Validation traceability used to link ITER requirements to the MAMIC architecture components.

Requirement Level	Validation Result
Applicable policies, processes, and requirements	The IDM ensures that the software planning activities produce the software plans and standards that direct MAMIC architecture development processes and others, such as configuration management and quality. The IDM is developed following supplier QA processes to have good reliability and avoid delays in RH operations. Risk management is performed systematically during the development to allow the reduction and control of the identified risks.
General requirements: application initialization and file management	The MAMIC architecture provides a flexible configuration mechanism that allows customization of the design and the internal logic behavior of the RH-IHMI. The error management bounded context in the domain layer defines the software behavior when an error occurs during its execution. The GUI adapter serves as an intermediary component responsible for facilitating communication between the core application logic and the CODAC workstation dependencies.
HMI design requirements	The application layer ensures that any action requested by the external systems is processed correctly and any primitive data received are translated into specific objects managed by the domain layer. The error management context specifies the software’s response and behavior in the event of an error occurring during its execution. The GUI adapter functions as an intermediary module tasked with facilitating communication between the core application logic and the dependencies of the CODAC workstation.
Interfaces	Assistant operation domain ensures the execution of plans intended to fulfill task objectives, priorities, and limitations. Communication domain establishes efficient data handling with the different external applications using specific protocols, such as HLC and RAPI. Task prediction context allows the RH-IHMI to be more configurable, considering its usability by the operator.

. A detailed model validation analysis is included in the last column of this matrix.

This systematic approach verifies that each requirement is sufficiently addressed and implemented within the software solution, adhering to metrics outlined in ISO-9001 and CODAC SWIL-2 standards [36].

In conclusion, the MAMIC model covers all the requirements established, with the advantage that it is flexible enough to introduce changes to its structure within short timeframes and with moderate effort.

7. Conclusions and Future Works

The MAMIC model proposal, in which the hexagonal architecture is integrated with an anthropomorphic approach, predictive modeling, and cognitive architecture, provides a robust strategy for developing flexible, maintainable, and testable software. Through the implementation of ports and adapters, a clear separation of concerns is achieved, enhancing the resilience of the RH-IHMI to technological shifts and enabling adaptation to evolving business needs. With the MAMIC architecture, the RH-IHMI is engineered to endure the passage of time, safeguarding the core business logic at its core and demonstrating resilience against future changes in technology and delivery mechanisms.

Moreover, using the MAMIC model, agents can operate autonomously until human supervision is required or a problem is detected by the supervisor. The MAMIC design strategy aims to create a versatile system applicable to different RH device controllers. We leverage the benefits of autonomous systems while allowing human control through a human–machine interface. The MAMIC architecture equips the supervisor with tools to interact with all processing levels of the RH device controllers. These interactions can rectify unexpected moves or address decisions that might lead an autonomous system into an unstable state. One of the MAMIC goals is to specify task assignments, teleoperate agents, display sensory data, override process conclusions, and reconfigure the system in response to various sensory and agent failures.

Additionally, having a model architecture greatly aids industrialization by providing a common model and language for remote handling (RH) across the industry. This facilitates the integration of multiple systems and subsystems.

Due to the model generation having been validated with the ITER requirements, the MAMIC architecture is perfectly valid to cover the current and future needs of ITER facilities. Furthermore, considering the remote handling needs of future fusion facilities, such as IMIF-DONES [37,38,39] and DEMO [40,41,42], an update of the model could be made by including new bounded contexts in the domain layer and new ports and adapters in the application and infrastructure layers.