From Digital Services to Sustainable Ones: Novel Industry 5.0 Environments Enhanced by Observability

Abstract

The rapid evolution of Information Technologies is deeply transforming manufacturing, demanding innovative and enhanced production paradigms. Industry 5.0 further advances that transformation by fostering a more resilient, sustainable, and human-centric industrial ecosystem, built on the seamless integration of all value chains. This shift requires the timely collection and intelligent analysis of vast, heterogeneous data sources, including IoT devices, digital services, crowdsourcing platforms, and last but not least important human input, which is essential to drive innovation. With sustainability as a key priority, pervasive monitoring not only enables optimization to reduce greenhouse gas emissions but also plays a strategic role across the manufacturing economy. This work introduces Observability platform for Industry 5.0 (ObsI5), a novel observability framework specifically designed to support Industry 5.0 environments. ObsI5 extends cloud-native observability tools, originally developed for IT service monitoring, into manufacturing infrastructures, enabling the collection, analysis, and control of data across both IT and OT domains. Our solution integrates human contributions as active data sources and leverages standard observability practices to extract actionable insights from all available resources. We validate ObsI5 through a dedicated test bed, demonstrating its ability to meet the strict requirements of Industry 5.0 in terms of timeliness, security, and modularity.

1. Introduction

The growing focus on sustainability and resilience in our society is driving and stimulating growth and changes in all Information Technology (IT)-related sectors, such as Global Industries, City Management, and Agrifood. In manufacturing, we are assisting in a novel revolution usually called Industry 5.0 (I5.0), sometimes also referred to as the fifth industrial revolution, to establish closer interconnections among all value chains within any industrial sector. In fact, I5.0 promotes maximum reuse, improves production flexibility, and achieves resilience even in the case of disruptive events, putting a great emphasis on the centrality of people [1]. I5.0 creates a long-term vision that improves and completes the achievements of the previous Industry 4.0, by considering people as the core integration force to foster seamless cooperation and coordination of processes, to build circular and sustainable social value chains [2].

Big data, artificial intelligence, and sensing technology have demonstrated their effectiveness in automating, managing, and optimizing various research processes, and are now starting to expand pervasively into several other industrial domains. The current manufacturing landscape typically consists of many sets of machines and production facilities capable of both autonomous message exchanging and generating data at an ever-increasing pace. That data contains more valuable information for optimizing control and business-related goals: the exploitation of that potential can incredibly improve all manufacturing and engineering processes, supply chain management, and any life cycle management.

While results and production services become more and more digital and the importance of digital services continues increasing in usage, more and more novel services ask for pervasive access both to the shopfloor and to IT resources. We have to stress the still existing separation in manufacturing between the Information Technology (IT) and the Operational Technology (OT): most manufacturing companies still maintain, and enforce that division not only for certification satisfaction but also for professional practice and habits. We also claim that an important step forward could occur by inserting people in the production process, in the novel sense of involving people for any capacity they can offer and any information they can provide, by making them play an active role in crowdsensing the entire manufacturing environment [3], with their crucial contribution.

In this paper, we propose the necessity of defining new tools to manage systems for a more digital era, based on the capacity of observing any manufacturing system under any required perspective, searching for any potential required information, by also asking people to be involved [4]. We define the adoption of a pervasive observability so as to gather any monitoring information spanning both IT and OT layers of plants, going in the direction of enabling smarter and more holistic management of production IT and to provide potentially useful digital information toward a better entire plant management.

The ambitious goal is to grant resiliency and sustainability by exploiting any resource that you may rely on, either internally to the plant (either OT or IT related) or externally available (in the entire supply chain and extended to the entire society context). This paper presents several use cases as simple initial first steps in the direction of overcoming the IT/OT barrier, based mainly on considering people as activators of observability actions, so to integrate their professional expertise based on their roles in the industry, but also enlarging the scope to any possible people and data that can help to obtain the best goals for the whole society, according to the final I5.0 scopes.

To support the development and diffusion of Observability practices in industrial scenarios, we introduce ObsI5, a novel observability framework tailored for Industry 5.0 environments. ObsI5 leverages the principles of cloud-native observability and extends them to encompass both IT and OT domains, integrating human contributions as active data sources. By adopting and extending the OpenTelemetry standard, ObsI5 enables the collection, processing, and analysis of heterogeneous signals, metrics, logs, and traces from machines, digital services, and human actors alike. This approach fosters a holistic, real-time understanding of industrial processes, empowering organizations to enhance sustainability, resilience, and human-centricity. The proposed architecture is modular, scalable, and designed to support distributed deployments across shopfloors, edge gateways, and cloud infrastructures, enabling seamless integration and actionable insights across the entire value chain.

The remainder of this paper is organized as follows. In Section 2, we provide a comprehensive overview of the Industry 5.0 paradigm, emphasizing its human-centric, sustainable, and resilient vision, and the role of observability in enabling these goals. Section 4 introduces our proposed solution, ObsI5, a modular and distributed observability framework tailored for Industry 5.0. We detail its architecture, signal model, and implementation, including the integration of OpenTelemetry standards and the deployment of Observability Spot (OBSPOT) across IT and OT domains. In Section 5, we present an experimental assessment of ObsI5, comparing its performance with state-of-the-art observability stacks in terms of latency, scalability, and resource efficiency. Finally, Section 6 concludes the paper by summarizing our contributions and outlining future research directions, including the extension of ObsI5 to support domain-specific signals and federated observability across industrial ecosystems.

2. Industry 5.0

Industry is universally recognized as a key driver in all economic and social transitions, especially those part of the revolution of I5.0 that requires full centrality of the local territory and context to achieve better sustainability and resiliency, with enormous benefits for the whole Society 5.0 [5], intended as the societal changes seconded and favored by I5.0.

I5.0 represents a transformation in manufacturing and industry that emphasizes the integration and collaboration between people and advanced technologies. While Industry 4.0 recommended an extensive usage of automation, connectivity, and the Internet of Things (IoT) [6], Industry 5.0 seeks a balance between technology advancements and unique capabilities and creativity of human workers [4]. In fact, I5.0 recognizes that, while automation and artificial intelligence have greatly improved productivity and efficiency, technology alone can not replace the skills, intuition, and emotional intelligence possessed by real workers [7]. That paradigm recognizes the importance of human touch, empathy, and problem-solving abilities in industries, and aims at creating a symbiotic (closer and closer) relationship and coordination among humans and machines (and any equipment and data).

In this context, modern monitoring and resource reorganization can provide novel additional roles to involved people. Surely, while workers equipped with smart wearables have provided a precious help in monitoring the health and well-being of workers [8], by playing the role of passive subjects (implicitly providing data about their well-being); other expert persons can become active subjects capable of making actions and providing opportune information, becoming new active data sources, by suggesting actions toward best optimization [9,10].

These processes and practices can achieve pervasive and more scalable monitoring and control by taking into account many different heterogeneous sources and also combining them toward a fully holistic view, the same typically already deployed in complex IT systems.

Observability, in its turn, encompasses traditional practices and tools for monitoring, being capable of offering invaluable and more complete insights of system internal state and behavior, by using precise data collection and analysis, so to offer an end-to-end detailed capacity of taking advantage of any possible information available in a manufacturing context, by defining a complete infrastructure based on Observability, capable of detecting and inspecting any useful (even hidden) information.

Due to the diffusion and recognition of standards for Observability [11] and to the development of observability best practices and tools, modern IT systems have the ability to get information of the internal behavior of any service system, as well as the interactions and dependencies among them, so as to effectively understand and troubleshoot the system as a whole, and to explore many potential optimizations. To achieve system observability involves collecting, aggregating, and analyzing data from many sources to provide meaningful insights to derive information to trigger actions.

Reinforced by the I5.0 goals, observability principles are acquiring rising importance, not only to monitor and manage the ever-rising IT services complexity but also for the industrial plant and workers. By harnessing real-time data in several cases, observability enables an organization to create safe, more efficient, and sustainable manufacturing environments, ultimately leading to the typical objective of I5.0: improved productivity, worker well-being, and overall business success. Moreover, it improves and can guarantee an easier certification of safety protocols, and also novel answers to security concerns.

The process toward observability is still delayed by the historical strong separation between Information Technology (IT) systems and Operational Technology (OT) of typical industrial plants. On the one hand, IT primarily deals with traditional enterprise technologies, including networks, servers, databases, software applications, and cybersecurity. On the other hand, OT systems focus on the management and control of physical processes, such as manufacturing, production, and industrial automation, and cyber–physical systems [12]. Despite many attempts of both research and industry to make these two layers converge, major concerns, not only in security and workplace safety, but also for the complexity of the interactions, are still preventing and discouraging a fast and smooth integration.

In I5.0 declarations, people must play a central role in production plants. We claim that the people contribution can become crucial to pave the way toward a smoother and widely accepted observability path for the new automation and industry revolution [13]. Zooming in deeper on the central role of humans in I5.0, we have to introduce a way of interpreting human-related activities so as to employ people cooperation at its best. We intend referring to crowdsensing, as the ability of people to wisely solve a problem proposed to a large crowd (such as answering questions or taking pictures to provide them) [10]. We use crowdsourcing as the possibility to propose tasks to people who can solve them, so that they can behave as mobile sensors capable of collecting data and answering data as triggers in a very holistic and intelligent way.

In the following, the main idea is to put together any possible information from any possible source that can help in the direction of the I5.0, via a holistic infrastructure based on Observability we call ObsI5. The final goals of I5.0 can be enabled and more easily supported by taking advantage of the manufacturing plant to become a living lab, in which to effectively configure and test many possible cases and to experiment with different directions of the coupling of Observability and I5.0 on the field.

In the next sub-sections, we explore four real use-case scenarios where people not only can play many crucial roles in the support of observability of the production plants but also can behave as core activators and enablers to overcome the barrier between IT and OT. We present the following cases as a starting contribution to stimulate many other possible roles of people and enriched data sources that can push that I5.0 trend even further.

2.1. Awareness of Workers Well-Being

One very important indicator for I5.0 is the wellness of workers, so they can be even more involved and closer to the company values. A first application of I5.0 toward observability is to assign workers the crucial role to collect periodical indicators about worker health within the company. That observability use case can integrate many different sensors, such as wearable devices to collect data to monitor real-time health parameters and environment conditions, to provide organizations with comprehensive insights into workforce well-being. In this case, people are passive subjects, offering their health indicators, without any initiative, apart from willingness to take part in the activity.

This observability application can work as a sentinel, on the one hand, tracking physiological indicators like heartbeat rate, body temperature, and stress levels via the advanced wearable sensors; on the other hand, environment sensors can capture ambient parameters, such as air quality, temperature, and noise levels, offering a holistic view of working conditions. Adding some AI tools, sophisticated algorithms, and machine learning techniques can analyze real-time data, detecting potential deviations or anomalies based on established scientific standards and occupational health guidelines. The ObsI5 support can provide and generate prompt notifications and alerts, enabling immediate action in addressing emerging health-related concerns.

With regard to incident prevention, this ObsI5 use case can contribute to long-term sustainability. By aggregating and analyzing data over time, we can identify patterns and trends related to worker health and safety, permitting ad-hoc target interventions, such as ergonomic improvements and personalized training programs to foster a more sustainable and enjoyable working environment. In addition, the ObsI5 observability system can enhance transparency, trust, and collaboration among all workers and with their supervisors. Workers can receive valuable feedback on their well-being and performance, by informing about their health and promoting awareness and spreading responsibility toward a safer and healthier work environment.

2.2. Workers as Smart Sensors to Enhance OT Goals

I5.0 intends to put people as the core resource of any manufacturing process, by stressing the opportunity of exploiting workers skills and experience, whenever they can intervene with valuable initiative and positive actions. Our second use case engages workers in crowdsensing actions, while moving inside the OT facilities in the plant as so to identify and harvest novel data toward better observability. The tasks requested to workers are strictly dependent on their expertise acquired over many years of experience and based on their willingness of improving internal processes and values chains. This ObsI5 case aims at involving more and more people, on a voluntary base, to gather novel and valuable insights in all production process, capitalizing on workers special abilities and any competence in new technologies.

Workers in OT, eventually equipped with any available smartphones and other close devices, can receive prompts from an ObsI5 central crowdsensing system, that proposes to them to perform crowdsensing activities aligned with their specialized knowledge. Anyone can decide whether she intends to answer, with a personal decision that may depend on the specific time schedule and tightness of her duties. These activities may involve capturing precise data during routine tasks within the industrial shopfloor or suggesting some triggering that may obviate to potential problems to come.

By seamlessly integrating the collected data with existing datasets, the ObsI5 system achieves a deeper and comprehensive view of the entire production process. ObsI5 can employ advanced analytics techniques to discover in advance patterns, correlations, and anomalies, empowering stakeholders to optimize operational efficiency, to identify areas to be corrected, and to address potentially critical issues in real time.

Via timely alerts and notifications, irregularities and anomalies within the industrial shopfloor can be easily and promptly detected, both minimizing downtime and maintaining optimal production conditions. This collaborative approach spreads proactive continuous improvement, as the integration of worker expertise to provide crowdsensed information to the actions to be automated enables process optimization and enhances equipment performance and productivity. Combining worker expertise and technology advancements, the production plant reaches an enhanced level of observability, capable of achieving better-informed decision-making, defining a more effective and wise environment within the company.

2.3. Observability Inter-Plant via People Coordination

Within distributed and multi-region industrial plants, the collaboration toward the resiliency of the productive system stems from the capacity to coordinate workers over different operation lines. The use case allows for preserving the target production over the global system. In case of a crash or anomalies in one production line, we can coordinate a recovery action by taking into account other available lines to migrate production there to substitute either part or of the entire line.

In this case, the observability system can collect and analyze real-time data from various parts of the industrial plant, such as different production lines, equipment, inventory levels, and workforce performance, across multiple regions. The ObsI5 system provides a comprehensive view of the overall production, facilitating informed decision-making and coordination among different operation lines, even by forecasting some possible malfunctioning events.

When a crash is likely to occur in one region (or it has already occurred), such as a breakdown of machinery or a sudden surge in demand, the observability system promptly detects the anomaly and alerts the respective chain supervisors, so they can decide recovery actions: one simple method is to deviate the activity, or part of the load to another line available to accept. Both involved supervisors can coordinate with each other to decide the recovery actions to be taken promptly, while ObsI5 can provide all communication mechanisms to achieve the requested agreement and support its actuation.

By exploiting the suggestions and prompts provided by ObsI5, the supervisors can cooperate to identify the regions that can process additional production load or have spare capacity to support the affected region. They analyze real-time data on production capabilities, resource availability, and logistic considerations to determine the most suitable redistribution strategy. Via coordinated efforts, the responsible people can redistribute the loads to other regions with available resources. That redistribution optimizes production capacity utilization, minimizes bottlenecks, and reduces the risk of order backlogs or delays. The observability system continues monitoring and providing feedback on the progress of the redistribution, by ensuring seamless execution and mitigating any potential risk.

2.4. Supply Chain Observability by AI Query

The observability of ObsI5 that has the entire vision of IT subsystem can provide an enlarged and enhanced view of the current plant potential actions, by taking into account also the information at the large, not only by the entire scope of the available Cloud continuum, but also with the help of AI-suggested actions [14]. These actions can enlarge the scope of monitoring to other components and stakeholders at large, such as providers, production fields, and other critical elements. So, the integration of observability tools into the cloud can grant the organizations enhanced visibility and control over their present operations and can achieve improved setting. That novel holistic approach allows for the seamless collection, analysis, and visualization of data across different stages of the value chain, enabling management to make more informed decisions quickly and efficiently. The framework ability to correlate data from diverse sources ensures that any anomaly or performance issues are promptly identified and addressed.

As an example, the combined processing of observability data from both local systems and partners can enable the generation of machine learning models capable of dynamically reoptimizing production. In the event of a slowdown at one of the partner sites, these models can suggest adjustments to the local production line to improve energy efficiency across the plant while aligning with the revised production targets.

Proposing ObsI5 over a Cloud can allow for this observability framework to automatically generate queries to specialized personnel when specific alerts, bottlenecks, or analytical needs arise. That approach ensures that the right experts can be engaged to investigate and resolve issues, thereby minimizing downtime and optimizing productivity by anticipating problems. By leveraging advanced analytics and machine learning, the framework can predict potential problems before they escalate, allowing for proactive management. This not only enhances operation efficiency but also supports continuous improvement and innovation within the organization. Overall, the observability cloud framework represents a powerful tool for managing complex value chains, driving both strategic and operational excellence.

3. Current State of Observability

Observability has emerged as a foundational principle in modern software engineering, particularly within microservice-based architectures, where the complexity and distributed nature of services demand enhanced, robust monitoring and debugging capabilities [15]. Early frameworks such as Prometheus, Grafana, and Jaeger have been widely adopted to collect and visualize observability information to enable developers to understand system behavior and performance [16]. These tools have proven essential in dense microservice scenarios, where pinpointing failures and optimizing performance require granular and real-time insights across service boundaries.

Building on these foundations, observability has seen increasing adoption across a wide range of domains, both in core IT technologies, such as next-generation networks [17] and machine learning [18], and in application areas including smart cities [19], smart grids [20], and smart agriculture [21].

As an example, in smart cities, observability frameworks are more and more adopted used to monitor urban infrastructure, mobility patterns, and citizen services, supporting real-time decision-making and enhancing resilience [22,23].

Despite these advancements, the application of these principles and architecture to support observability in Industry 5.0 remains largely unexplored [24]. Existing solutions developed in other application scenarios [25,26] fall short in addressing the unique requirements of industrial environments, including the integration of human actors, security constraints, and the need for timeliness analysis across both IT and OT domains. Moreover, these solutions employ a centralized approach, consolidating all signals in a single hub to provide processing and visualization functionalities. This approach has historically found much resistance in adoption in industrial scenarios where the delocalization of information and its processing plays a fundamental role in meeting security and performance concerns.

To bridge this gap, our proposal, ObsI5, introduces a novel observability framework specifically tailored for Industry 5.0 that extends traditional monitoring concepts by considering people worker involvement as active data sources, supporting decentralized data collection and processing through modular deployments, and ensuring timely and secure analysis of heterogeneous signals. ObsI5 decentralized approach overcomes the limitations of centralized observability stacks and aligns with the core principles of Industry 5.0: human-centricity, resilience, and sustainability.

4. An Observability Framework for Industry 5.0

Our proposal, ObsI5, seeks to establish a unified framework that leverages observability best practices to integrate, store, analyze, and present data and information gathered by sensors together with workers and employees across all sectors of a whole industry plant. This integration aims to lay the foundation for creating automated processes and advanced analytics, promoting the sustainability, reliability, and security principles of Industry 5.0.

4.1. OpenTelemetry Standard for Industry 5.0

We adopted OpenTelemetry as our standard for industrial observability because it is a globally recognized, structured, and open framework that enables consistent and scalable telemetry data collection across complex systems. Its widespread adoption and strong community support make it a reliable and future-proof choice for achieving deep visibility, interoperability, and performance monitoring in distributed environments.

In particular, OpenTelemetry is an open-source project that offers a suite of APIs, libraries, agents, and instrumentation to facilitate the collection of distributed traces and metrics from applications. To enhance interoperability among different instruments, the OpenTelemetry project also defines a set of semantic attributes that provide meaning to data when collecting, producing, and consuming it. Additionally, OpenTelemetry includes the OpenTelemetry Protocol, a general telemetry data delivery protocol that outlines telemetry data’s encoding, transport, and delivery mechanisms between telemetry sources, intermediate nodes such as collectors, and telemetry backends.

In particular, OpenTelemetry defines three system outputs called Signals: metrics, logs, traces that describe the underlying activity of the operating system and applications running on a platform. Adopting the OpenTelemetry standard promotes modularity and extensibility of OBSPOT and facilitates communication and data exchange among its components.

To represent the three defined ObsI5 signals, we embraced and extended the OpenTelemetry project [27], which is, at the moment of writing, a rising and widely adopted standard to define and represent observability data.

As its first contribution, ObsI5 redefines the three golden signals metrics, traces, and logs within the context of Industry 5.0. Traditionally, these signals have been used to observe the behavior and interactions of microservices in IT environments. ObsI5 extends these concepts by incorporating support for business metrics, physical assets, and Industrial Internet of Things (IIoT).

An ObsI5 metric is any measurement captured at runtime. In the Industry 5.0 scenario, metrics can capture various information regarding the status of the field and its workers, which is essential for planning production interventions, preventing outages, and guiding business decisions. Specifically, in the OT environment, metrics capture values sensed by sensors. Metrics are specialized to the specific context they represent. For example, in Industry OT, metrics can represent the operational state and performance of machinery; in Industry IT, they can indicate the availability and performance of IT services; and in business departments, they can reflect enterprise indicators such as material provisioning lead times or costs associated with field operations.

As metrics traverse the production field, they are continuously transformed and aggregated into derived metrics to present information to specialized employees and guide informed decisions. For instance, data sensed from various equipment can be presented to the field supervisor as Overall Equipment Effectiveness, measuring the efficiency of manufacturing processes by considering availability, performance, and quality [28].

ObsI5 Logs are records representing events. Logs often contain detailed debugging/diagnostic information, such as inputs to an operation, the result of the operation, and any supporting metadata for that operation. The use of Logs for management has roots in many consolidated languages, services, and tools already providing log facilities, resulting in a pervasive diffusion in both Industry IT and OT [29]. In our envisioned scenario, a ObsI5 Log captures any event concerning a modern Industry 5.0 structure, such as the output of a machine, the description of an event in the field, and an action undertaken by an operator. Logs are usually verbose information containing much contextual data about the event, what caused its triggering, and where. For this reason, a strategy for more effective management, storage, and processing of logs can result in a significant overhead in both computational and organizational means. At the same time, the high value contained in this raw source of data is essential to achieve a comprehensive view of a modern industry towards efficiency, resiliency [29], and security [30] goals.

A ObsI5 Trace is an extensive description capturing details of each interaction among two or more Industry 5.0 entities, whether human, digital, or machinery. A trace can represent product exchanges between two machines in the field, human interactions with an HMI, or packet exchanges between an IT service and the production field. For each of these interactions, the trace gathers essential information, including the timestamp, duration of the interaction, and the identification of the interacting entities. Through the collection of traces, ObsI5 can create a relationship graph that tracks the transformation of products across the field, facilitates root cause analysis, and provides a time-aware description of cyber–physical flows in modern industry. Traces give our observability system a comprehensive view of what happens within the field.

4.2. ObsI5 Observability Spot

To overcome the limitations of current state-of-the-art approaches, which rely on centralized signal processing, and to enable more effective signal gathering, storage, and analysis, ObsI5 introduces a novel decentralized architecture based on OBSPOT. Each OBSPOTs creates a tailored point of observability, primarily processing, storing, and presenting signals from the industrial sector in which it resides and acting as a waypoint for information exchange with other OBSPOTs. The exchange among OBSPOTs is facilitated through the OpenTelemetry standard and interoperable format, enabling the exchange of raw and processed data as ObsI5 signals. Indeed, OBSPOT functions as an adaptation layer among different hardware, protocols, and industrial sectors, mitigating the problem of heterogeneity in data integration processes.

OBSPOTs are configured by specialized workers who know the necessary observability data at each specific point in the field. These workers are responsible for deciding in which cases to forward data to other levels, and taking charge of the activation of particular workflows involving one or more OBSPOTs.

Focusing on the OBSPOT, the architecture outlines the core services that enable comprehensive management and processing of observability signals. In particular, the designed architecture represented in Figure 1, consists of seven layers called: Instrumentation, Ingestion, Storage, Streaming, Processing and Analytics, Query, Alerting, and Processing, and Workflow Management. Each layer, detailed in the following, plays a specific role in the data lifecycle, from collecting data to presenting insights and analysis.

Heterogeneity and vendor lock-in caused by proprietary solutions are major factors that raise integration complexity and costs [31]. The Insutrmentation layer is a set of libraries and services enabling the runtime configuration of physical devices and industrial services. It includes agents or sensors that gather data from different devices, systems, or environments. These agents can be embedded in devices, software, or infrastructure components and are designed to capture and transmit data to the next layer. They can collect various data types, such as performance metrics, user interactions, sensor readings, or log entries.

Collected datasets are received by the Ingestion Layer that performs transformations, adaptations, and buffering to prepare the data for further processing. The ingestion layer handles tasks such as data validation, enrichment, normalization, and format conversions to ensure consistency and compatibility. This layer also acts as a powerful buffer to handle temporary spikes in data volumes and smooth out any inconsistencies in data arrival rates. Finally, it prepares the data for storage and analysis.

The Storage Layer is responsible for storing, aggregating, and managing the data collected from the ingestion layer. It may employ any tools, such as databases, data lakes, or distributed storage systems, to store the data efficiently. This layer performs operations, such as data indexing, deduplication, compression, and partitioning for optimized storage and retrieval. Additionally, it supports advanced querying capabilities to enable complex analysis and insights. It can handle aggregations, correlations, and computations on the stored data, providing a foundation for data exploration and analytics.

While the Storage Layer is responsible for collecting and memorizing data at rest, namely logs, metrics, and traces that the system can exploit in specific spots—the Streaming layer provides support for moving that data. This layer is in charge of transferring data both inside and between OBSPOT, enabling stream processing and data movement across the industrial plant.

In the first case, it addresses the growing need for timely processing of critical observability signals that carry high time-sensitive value. Here, the Streaming layer acts as a queue, efficiently transporting observability signals from the Ingestion to the Processing Layer within a single OBSPOT. In the second case, the Streaming layer provides a reliable transport mechanism between different OBSPOT, allowing raw and processed data to move across one or multiple industrial sites. This functionality enables OBSPOT instances to share and access a broader range of data and to relocate the execution of observability signal processing and storage where it is most useful.

The Processing and Analytics layer provides the support to execute different types of processing over analytics data. Depending on the performance of the available computational resources, network, and data closeness, the Processing and Analytics layer can implement different solutions, and strategies, and support different type of analytics from simple aggregation operations to more advanced analysis like map-reduce or machine learning processing.

The Query, Alerting, and Visualization Layer provides information, analysis, and insights in a convenient and user-friendly manner by offering multiple mechanisms to consume and interact with the data. This layer includes various components such as visualization tools, dashboards, reports, and interfaces tailored for different user groups. It leverages any visual interface techniques, including charts, graphs, maps, and visual indicators, to convey information effectively, depending on user preferences. It also facilitates additional features like real-time updates, custom alerts, automated processes, and integration with external systems or devices (e.g., mobile apps or IoT devices) to extend accessibility and usability.

To streamline workflow management and ensure the resilience of each OBSPOT, ObsI5 is supported by the Workflow Management layer (Figure 1). This layer provides specialized workers with an endpoint for each OBSPOT to receive definitions of observability workflows. These configurations are first checked to verify the access rights of the worker to selected resources and services, and then to verify that the new submitted workflow does not conflict with existing configurations. After this verification process, the Workflow Management layer configures individual components to activate the workflow, including ingress and egress points to a single OBSPOT, ensuring the performance and reliability of each involved component.

Once a workflow is activated, the Workflow Management layer continuously monitors the performance and activity of each component involved in the workflow processing to ensure high availability and performance of the pipeline through remediation strategies such as component scaling, offloading, and dynamic reconfigurations.

Overall, the OBSPOT architecture enables all the end-to-end data lifecycle functions, starting from data collection through agents, transforming and buffering in the ingestion layer, storing and aggregating in the aggregation layer, and finally presenting insights and analysis through visualizations in the visualization layer. This component provides a structured and scalable approach to handling data at each stage and facilitates efficient data processing, analysis, and decision-making.

4.3. OBSPOT Architecture for Shop Floor Observability

Starting from the shopfloor, here ObsI5 integrates and expands the capabilities of existing control systems such as Programmable Logic Controller (PLC), Virtual Programmable Logic Controller (VPLC), and Human–Machine Interface (HMI) at different levels, suiting productive field needs as depicted in Figure 2.

In production, OBSPOTs are deployed inside Industrial PCs to gather information from specific machinery, equipped sensors, and sensor-equipped workers to augment the capabilities of traditional HMI supports. Here, machinery supervisors and field workers can access advanced analytics and alert mechanisms to improve production efficiency and safeguard worker well-being.

Data gathered from the field, raw and aggregated by OBSPOT, are conveyed to higher-level OBSPOT, where a more elastic computational capacity can be made available to process and store data. Here, specialized workers, such as Field Supervisors, are supported by a more comprehensive view of the field by exploiting advanced analytics, such as anomaly detection or root cause analysis.

Field observability is linked and offered to business and organizational sectors of the company through the Industrial Edge Gateway OBSPOT. This OBSPOT represents the frontier between IT and OT, and between productive fields and the external world. This layer plays fundamental roles in modern industries, such as protecting the productive field from external malicious attacks [32], anonymizing information to preserve industrial secrets, and aggregating data to protect IT services from overloads caused by the huge amount of data generated in the field.

Finally, the OBSPOT deployed in the IT, capitalizing on the higher availability of computational resources of Elastic Runtime Environments, acts as a collector and bridge between the different industry departments and presents personalized views to each worker.

4.4. OBSPOT Implementation

Focusing on the implementation of the OBSPOT seven layers (Instrumentation, Ingestion, Storage, Streaming, Processing and Analytics, Query, Alerting, and Workflow Management), we integrate state-of-the-art instruments supporting the OpenTelemetry protocol and complement them with ad hoc solutions when components are missing or do not suit the specific needs of the Industry 5.0 use case.

As first components of the Instrumentation and Ingestion layer (Figure 3), the Instrumentation Agent and the Collector services work at the frontier of OBSPOT, enabling data capture and interaction with Industry assets.

The Instrumentation Agent is a hardware-specific service that enables control and configuration of machinery using high-level API fields. For example, the Instrumentation Agent embeds hardware-specific logic to configure a PLC’s frequency of metrics forwarding or the targeted endpoint. This layer of abstraction allows OBSPOT to control manufacturing assets more effectively.

The Collector acts as the primary endpoint to receive and pull information from field assets, bridging industrial protocols (e.g., Profinet, Ethercat, Modbus) and data formats. This is where the transformation from industry-specific information or events to a ObsI5 signal occurs.

ObsI5 Collector is developed extending the OpenTelemetry Collector, inheriting support for OTLP protocol, information representation, and flexible distribution. In particular, the ObsI5 Collector supports two types of execution: as an agent co-located with the sources of signals and acting as an adapter to the OpenTelemetry format, and as a gateway collector serving as an intermediary waypoint for multiple sources [11].

Information acquired by the Collector is then forwarded to the Ingestor, part of the Ingestion Layer, which performs preliminary data manipulation and aggregation before routing to the Storage and Streaming Layer. The Ingestor process is developed as a data processing pipeline on top of the OpenTelemetry collector framework, enabling definition of a series of processing tasks that are executed accordingly to a pipeline definition. This approach enables Industry workers to dynamically create and define new specialized ingestor processes by composing existing processing tasks in different ways to suit particular needs in observability data processing. Moreover, the Ingestor process can behave as a buffer to mitigate spikes or surges in signal production, which can stress Storage services.

To handle the potentially huge volumes of data ingested by IT, we integrate Apache Kafka as the primary streaming service. Apache Kafka is a highly scalable, open source streaming platform that realizes the Pub/Sub protocols. We opted for Apache Kafka, among many open source Message Oriented Middleware (MOM) present on the market, mainly for its capabilities of scaling to handle a massive number of concurrent messages with multiple configurable qualities proven also in the Industry context [33]. Observability workflow can exploit the capability of Kafka to handle the diffusion and movement of signal among multiple OBSPOT.

Given the different properties of the three signals: Metrics, Logs, and Traces, our initial ObsI5 prototype implements the Storage Layer as a composition of three different backend solutions, namely Prometheus, OpenSearch, and Jaeger (Figure 3).

In particular, to store ObsI5 metrics, we integrated in OBSPOT Prometheus metric server. Prometheus is an open-source systems monitoring and alerting toolkit maintained by the Cloud Native Computing Foundation (CNCF) that collects metrics from configured targets, such as the OpenTelemetry collectors, at given intervals [34]. The metrics collected are associated with rule expressions analyzing the behavior and providing enhanced information for visualization and alerting. OpenSearch is the second endpoint addressed to store and analyze logs [35]. OpenSearch is a scalable analytics engine supporting different types of analytics and queries over stored records. In OpenSearch, logs are stored in the form of documents that are replicated and distributed over multiple nodes of the OpenSearch cluster through the sharding techniques. Finally, to manage ObsI5 traces and so enable correlation among multiple events, we integrated Jaeger. Jaeger is an open-source distributed tracing platform that maps the flow of requests and data as they traverse a distributed system, exploiting context propagation provided by OpenTelemetry traces [36]. Jaeger connects disparate sources of signals of the plant, helping to identify performance bottlenecks, troubleshoot errors, and improve overall plant reliability.

All these three storage solutions offer advanced signal specific processing capabilities such as aggregation, correlation, and full-text seearch, behaving also as essential components of the Processing layer.

Processing capabilities are also complemented with Processor components (Figure 3), ad-hoc processes realized on top of OpenTelemetry agents [27], providing plug-and-play and modular vertical Big Data processing pipelines to handle specific use cases, such as data transformation and metric/trace correlation. These agents are also extremely customizable, enabling specialized workers to easily create new Processor components.

As an example, to locate the most capable expert in the proximity of a specific machinery or field location, we implemented a Processor that, upon receiving information from the field, first filters workers to select only those with specific competencies or access level grants and then computes the K nearest to the point of interest. This processor enables Observability pipelines to select specific workers for informed crowd-sourcing tasks or as destinations for important alerts.

Finally, as an endpoint for data visualization and alerting service, we integrate in OBSPOT the Grafana service. Grafana is an open source solution, which is an already adopted and consolidated solution in the Industry field [37], used for visualizing time-series data. It allows users to create and share dynamic dashboards, providing insights into various metrics and logs from different data sources. Grafana supports a wide range of plugins and integrations, making it highly customizable and adaptable to different use cases. Thanks to Grafana dashboard customization and permissioned sharing, each worker can access dynamic views providing the needed information tailored to competence level, job, and language of each subject.

It is noteworthy that each OBSPOT can be configured to host any arbitrary configuration of aforementioned components to suit the business and technological constraints of each installation, as shown in Figure 4. As an example, an OBSPOT deployment in IT, thanks to the high availability of computational resources, can integrate all the components explained, with the exception of the Collector and Instrumentation agent, as this spot does not have direct access to machinery. In an opposite case, a OBSPOT deployed very near to machines can host only the needed process to communicate and interact with machinery to preserve limited computational resources, and in some cases, tailored Grafana Dashboards to be accessed by in-the-field workers. To support the distribution and management process of OBSPOT, all the components are developed to run inside Linux containers to facilitate their distribution and lifecycle management through an edge-oriented container orchestrating platform, such as K3S, a lightweight distribution of Kubernetes.

Each component is automatically scaled and kept active thanks to the Kubernetes orchestrating platform and specific controllers called operators [38], made available by different technology providers. For custom components created on top of the OpenTelemetry framework to complement the functionality of Kubernetes in Workflow Management, we implemented specialized controllers following the operator pattern [38]. Indeed, the management of the ObsI5 Collector, Ingestor, and Processors life cycle is complex, as it is subject to updates and varying load conditions, and it resides in different factory locations of the plants. For this reason, our proposal integrates the Crossplane Controller, a control loop process that continuously observes the status of the different processes and undertakes actions to ensure their stability. This controller also extends Kubernetes object APIs by enabling the definition of custom objects. In this way, in the process of managing OBSPOT deployments and observability workflows, workers can exploit Kubernetes object definitions and abstractions and leverage Kubernetes automation to handle it.

5. Preliminary Results and Assessment

To assess the validity of our proposal, we set up a testbed based on already consolidated experience with manufacturing [39]. In the envisioned scenario, represented in Figure 3, machinery continuously produces logs and metrics sampled and transmitted to OBSPOTs. OBSPOT interacting with OT assets are specialized, enabling sampling and anonymization of signals passed to the observability system. Each of the OT nodes considered is augmented with a static or dynamic position in the plants, whether considering a static asset or a moving node, such as autonomous vehicles and human-operated vehicles. In this environment, we simulated the presence of workers moving in the plants and periodically signaling their positions through their wearable devices to OBSPOT.

All the experiments have been conducted in a distributed infrastructure deployed across two separate sites, mimicking an IT/OT environment of a real Industry 5.0 deployment. In the OT layer, we deployed two limited resource nodes, 2 VCPUs and 8GB of RAM each, addressable by simulated end devices and workers. A third node is installed as an industrial edge gateway, bridging the two zones, and is equipped with a Core i7-9700TE CPU, 32 GB of RAM, and a 512 GB NVME disk. In the IT layer, we installed a K3S Kubernetes cluster with three nodes, each equipped with 16 VCPUs, 16 GB of RAM, and a 512 GB Solid State Disk.

We have configured two deployment strategies featuring a different workflow distribution among OBSPOT and infrastructure resources, one concentrated in IT and the other over both IT and OT. The first strategy, ObsI5 IT, concentrates all the components in a single OBSPOT hosted in the IT layer as showed in Figure 3. This approach simulates state-of-the-art deployments and Observability solutions where all the services needed to manage observability workflows are concentrated in a single physical deployment unit. The second is the ObsI5 IT/OT strategy, which otherwise exploits the distribution capabilities of ObsI5 to spread workload processing among multiple OBSPOT. In particular, the distribution of components represented in Figure 4 follows an organization more driven by the requirements and constraints of a modern Industry 5.0 manufacturing [40], as already described in Section 4.3. In the ObsI5 IT/OT deployment, the OBSPOTs located in the OT are specialized to gather signals from machinery and workers, minimizing processing and storage duties to simple but effective visualization tailored for specialized workers. The OBSPOT installed on the Edge Gateway, serving as a bridge between OT and IT, mainly acts as a collector for data gathered. Finally, the OBSPOT located in the IT layer, thanks to the higher availability of resources, finalizes data processing thanks to different processors and stores them in different data storage to be visualized and queried later in time. The infrastructure is configured to host two main workflows: the first detects gathered values that exceed predetermined thresholds set by experts, and the second gathers real-time worker and moving asset positions to evaluate, for each piece of machinery, the nearest workers to which the system can assign a monitoring and operational task.

Typically, observability of Industry 5.0 scenarios is characterized by an enforced separation between IT and OT and a greater importance in the timeliness of observability data elaboration. To assess the advantages of the distributed model, we proposed with respect to state-of-the-art industrial observability solutions, we have installed and configured two of the most widespread open-source Observability solutions, the Elasticsearch and the Prometheus-Grafana stacks [16]. These two solutions have been widely adopted in many cloud solutions and have recently been proposed for monitoring industry applications [41,42]. These two stacks have been deployed and configured on the three nodes representing the IT infrastructure. We then configured the same workflows described above on both Elasticsearch and Grafana solutions and monitored their behavior and performance under different workload conditions.

The remainder of this section is organized into three experiments, each targeting a specific aspect of the proposed architecture. The first experiment evaluates the resource consumption and network usage of ObsI5 compared to state-of-the-art to demonstrate its applicability even in resource-constrained industrial scenarios. The second experiment focuses on the responsiveness of the system, measuring the time required to detect and alert on anomalous values under different workload conditions. Finally, the third experiment assesses the ability of the ObsI5 infrastructure to support advanced processing tasks at the edge, by evaluating the performance of a KNN-based processor designed to identify the nearest qualified workers in dynamic industrial environments.

In particular, in the first experiment, we collected data about the memory, usage, and overall network usage of the three solutions over a timespan of 3 days, when a constant number of 1000 observability metrics were generated and gathered.

The results illustrated in Figure 5 show the comparison of average CPU and memory performance. From this result, none of the evaluated stacks demonstrates a clear advantage. Specifically with regard to memory usage, all stacks consistently consumed around 2 GB of memory per cluster node. That stresses the inherently memory-intensive nature of observability stacks, that require substantial memory resources to load, store, index, and process collected signals.

It is also worth underlining that, despite a sustained load of 1000 signals being processed and stored, the CPU usage for all three frameworks stays consistently below 7.5%. This is a favorable outcome, considering that observability systems are intended to support core business services by delivering continuous and accurate operational insights while minimizing their own resource footprint.

When analyzing the total volume of data transmitted over the network throughout the experiment, the results of the right Figure 5 reveal a marked disparity between the data sent and received by the various deployed components. This discrepancy can be attributed to the nature of observability workflows, that are designed to extract and synthesize insights from large volumes of raw data.

Among the four deployed stacks, ObsI5 IT/OT stands out with a substantial reduction in both incoming and outgoing data volumes. This significant advantage stems from the distributed architecture of ObsI5 IT/OT, which allows data processing to occur closer to the source. By extracting information locally, the system minimizes the need to transmit raw data across components, thereby reducing network overhead.

It is particularly noteworthy that ObsI5 OT achieves this efficiency while maintaining resource consumption levels comparable to those of the other, more centralized stacks.

Decomposing the Overall Resident RAM value retrieved into singular contributions of each component installed in ObsI5 OBSPOT, we can observe in

Table 1. Minimum memory requirements to deploy the different Components of an OBSPOT.

	OTEL-Collector	Prometheus	Grafana	Kafka	Jaeger	OpenSearch
Memory Requirements	130.4	80.06	82.79	472.2	358.6	888.9

that, taken in its essential form, the overall stack memory occupation does not exceed 2 GB. In particular, the OpenTelemetry collectors, hosted in both edge and cloud nodes, impact the memory with 100 MB for each instance. This value is mainly due to the memory reservation mechanism that the service exploits to store incoming data and process it in batches. In the evaluation of this metric, however, we have to consider that the size of this buffer can be customized through service configuration and can then vary depending on customer-specific needs. On the other side, Prometheus and Grafana, thanks to their extensive use of permanent memory storage, steadily remain under the 100 MB of memory occupied. Jaeger and OpenSearch services exhibit elevated memory consumption as a result of in-memory structures required to manage indexes and data graphs. These data are particularly relevant in the case of OpenSearch if we consider that the scalability of this component forces an odd number of active master replicas with a minimum number of three replicas to obtain High Availability and fault tolerance of the service. This result highlights the importance of a decentralized approach, such as the one proposed by ObsI5, enabling the tailoring of observability solutions to better suit the specific needs and computational characteristics of each deployment point. Indeed, installing a complete observability framework in constrained computational sites, such as edge nodes, can limit the memory available for storing and processing incoming signals, thereby reducing the effectiveness and applicability of the solution. On the contrary, ObsI5 enables the installation of only the components specifically required for the observability workflow at each deployment site, leveraging cross-OBSPOT communication to ensure completeness and support more complex observability workflows.

In the second experiment, we evaluated the performance of the four frameworks in detecting anomalous values and reporting them through an alert. We generated a constantly increasing number of events, starting from 0 up to 30,000 events/s, and logged the time of generation and the time of the corresponding alert.

The results of Figure 6 demonstrate that ObsI5 workflows achieve performance levels an order of magnitude superior to those of the ElasticSearch and Grafana stacks. This improvement can be primarily attributed to the flexible architecture of ObsI5, which supports parallel in-stream processing of signals. In contrast, both Grafana and ElasticSearch require signals to be stored before evaluation can begin. Moreover, the evaluation of metrics to generate alerts is performed through periodic batches of stored data, which further increases the time needed to emit alerts.

Notably, in the initial phase of the experiment, ObsI5 IT/OT exhibits superior performance, maintaining a time-to-alert consistently below 200 ms (with an average of 191 ms). This is possible because of its decentralized processing model, which allows alerts to be generated closer to the signal source. In comparison, the centralized version of ObsI5 averages 2 s, while ElasticSearch and Grafana lag significantly behind, with average alert times of 67.87 s and 23.81 s, respectively.

However, this behavior shifts dramatically once the system overcomes the throughput of 10,000 signals per second. At that point, resource exhaustion at the edge leads to a rapid decline in ObsI5 IT/OT performance, resulting in signal queuing and a sharp increase in alert latency. Conversely, ObsI5, Grafana, and ElasticSearch, benefitting from the greater resource availability of centralized IT infrastructures, can sustain higher signal frequencies, up to 20,000 events per second. Beyond that threshold, even IT-based resources become saturated, leading to further queuing and eventual signal loss as the frameworks struggle to keep up with the incoming data stream.

Overall, the OBSPOT distribution implemented in the ObsI5 IT/OT architecture demonstrates superior performance in terms of alerting latency. Timely detection of anomalies, errors, or failures is a critical requirement for observability systems in the context of Industry 5.0, where responsiveness and system resilience are of paramount importance. The experimental results clearly indicate that achieving low time-to-alert values stems from the appropriate allocation and exploitation of both edge and cloud resources. That also highlights the importance of a carefully designed infrastructure that aligns resource provisioning with the expected data throughput and system criticality.

In the third experiment, we evaluate the performance of the OpenTelemetry collector to augment system information by estimating the K nearest workers able to gather information about an IT machine. In the envisioned scenario, the plants integrate human-operated and autonomous mobile nodes that move within the plants, dynamically changing the number of observed nodes and workers over time. We did a simulation of worker movement within the area facility, resulting in a variable amount of data for the Collector to process. The primary goal of this experiment is to verify the adaptability of the OpenTelemetry collector, designed to enhance and carry out intricate operations on data originating from the OT layer. That aims at ensuring that our solution can align more closely with the security and organizational requirements of Industry 5.0 facilities.

During the whole experiment, the Collector, configured to execute batch processing every 500 ms, showed a great variability in overall computation time spanning from 180 ms to 675 ms with an average of 274 ms (Figure 7 left). The computation time is a critical factor in batch processing, as if it exceeds the time elapsed between executing successive batch scheduling, it can cause a phenomenon of enqueuing of tasks, eventually leading to degraded performance and buffer saturation. The overall computation time, a part of the time taken to process the KNN analysis, is significantly impacted by the serialization and deserialization of data that are formatted in output in the OpenTelemetry standard (Figure 7 right). In this scenario, a crucial role is played by the Crossplane Controller, which manages the lifecycle of collectors, and can trigger changes in their configuration, e.g., batch interval time and the scale of a service.

In summary, the experimental results confirm the superiority of ObsI5 compared to the state-of-the-art solutions considered, particularly in light of the growing involvement of humans in future Industry 5.0 scenarios. Our solution demonstrates greater flexibility in deployment, enabling the configuration of tailored OBSPOTs to meet the specific needs of individual industrial sectors. This approach supports workers with customized metrics while ensuring secure and regulated information propagation across different domains. Furthermore, it allows organizations to exploit the heterogeneous computational characteristics of modern industrial environments, from resource-constrained edge nodes to powerful IT infrastructures. The decentralized nature of our workflows also introduces an additional layer of flexibility by dynamically selecting the most suitable worker for a given observability task, based on expertise, proximity, and availability. Nevertheless, the principal limitation of our solution lies in the human factor in case of workers not appropriately trained and specialized, which, while being the cornerstone of next-generation industrial plants, also represents a potential weakness. Indeed, the absence of specialized workers able to create needed workflows and interact with ObsI5 to both provide and receive information can limit the potential of our solution. This limitation could have significant economic implications if industries fail to invest in continuous workforce training, both in vertical specialization and cross-sectoral competencies, to fully leverage the benefits of human-in-the-loop observability.

6. Conclusions and Future Works

In conclusion, Industry 5.0 demands a strong shift towards centrality to people, to give them a central role in offering their effective contribution, knowledge, and professional capacity. In that direction, we have shown that the inclusion of human operators as active participants in data gathering and monitoring could offer new solutions to overcome the still very well spread separation between IT/OT by taking advantage of people capacities.

This work introduces a novel observability architecture, ObsI5, designed to meet the evolving demands of Industry 5.0 by placing human contribution at the center of industrial innovation. By leveraging the OpenTelemetry standard and extending it through a modular, distributed architecture of OBSPOTs, ObsI5 enables seamless integration of data from both IT and OT domains, while enabling worker-tailored point of observation, providing needed information on the state of the Industrial processes.

The proposed architecture demonstrates how observability, traditionally confined to IT systems, can be effectively adapted and expanded to support the complex, heterogeneous environments of modern manufacturing. ObsI5 not only bridges the long-standing IT/OT divide but also empowers workers to act as intelligent sensors and decision-makers, enhancing system resilience, sustainability, and responsiveness.

Experimental results validate the architecture efficiency, particularly for distributed deployments, where local processing at the edge significantly reduces latency and network overhead, and additional required resources can be found in IT. The integration of open-source technologies like Prometheus, Jaeger, OpenSearch, and Grafana within ObsI5 further reinforces its adaptability and ease of adoption in real-world industrial settings.

Looking ahead, companies will increasingly need to identify and harness every potential way for improvement, not only within the broad scope of the manufacturing plant but also by expanding their perspective to include external sources of information and innovation. The trend is capable of exploiting any opportunities, being prepared to recognize and respond to emerging opportunities and competitive dynamics, wherever they may arise, both inside and beyond organizational boundaries.

In the future, we plan to extend the ObsI5 by defining new domain-specific signals tailored to industrial contexts, such as ergonomic stress indicators, collaborative task metrics, and predictive maintenance triggers, to further enrich the observability landscape. Moreover, we plan to further extend the ObsI5 orchestration capabilities in order to assist specialized workers in observability workflows placement and distribution.

Finally, as cross-company collaboration becomes increasingly vital, we also envision evolving ObsI5 into a federated solution capable of operating across multiple private installations. That would push forward observability and coordination while upholding strict security and privacy requirements.

Our final claim is that only by fully exploiting any possible integration of people in a digital I5.0 context to collect data, to ask for their willing contributions in any situation, and to appeal to their capacities and personal resources can the final goal of achieving the ambitious I5.0 goals of sustainability and resiliency be made possible.