Use-Case-Driven Architectures for Data Platforms in Manufacturing

Abstract

Since the term “Industry 4.0” was coined in 2011, machine data retrieval, storage and processing has been one of the major drivers for process optimization and factory management. Data platforms have been introduced as a key resource to process, align and enhance data from machines, sensors and other sources. At the same time, different use cases and applications vary greatly in their technical demands towards data amounts, formats, retrieval rate, scalability, latency and many more. Thus, holistic data platforms are often a compromise between these requirements. This contribution thus looks into the requirements and needs of different use cases and applications for data usage in manufacturing—from factory management, to process control and auxiliaries monitoring. From these use cases, specific requirements will be deducted to propose architectures that reflect the needs of these distinctive applications. From a structured literature analysis with more than 100 scientific publications, archetypes for data management platforms in manufacturing will be condensed and explained in detail. Overall, eight distinctive archetypes have been identified and clustered, with the major distinguishing feature being their reliance on extensive models or digital twin. This contribution closes with application examples for some of these archetypes.

1. Introduction

During the last years, the amount of data that is created globally has risen exponentially and is currently measured in Zettabytes [1]. While most of this data is probably created by and for consumers, the area of manufacturing plays a minor yet important role: as necessary raw ingredient for optimization and control, manufacturing data can contribute greatly to company and supply chain efficiency, competitiveness or other goals such as sustainability or resilience. Ever since the term “Industry 4.0” was coined in 2011, machine data retrieval, storage and processing has thus been one of the major drivers for process optimization and factory management. Data pipelines and platforms have been introduced as key elements to process, align and enhance data from machines, sensors and other sources. Historically, most data sources such as automation equipment and sensors have been equipped with proprietary protocols, creating a wide variety of different data formats to be collected, aligned and stored. At the same time, different use cases and applications vary greatly in their technical demands towards data amounts, formats, retrieval rate, robustness, latency, security and many more. If introduced as a “one size fits all” solution, holistic data platforms often depict a compromise between these requirements. At the same time, different technologies including those used for data transmission or storage also vary greatly in their capacity and performance.

Early on, industrial and academic contributors tried to define a common high level architecture [2]. The architecture was even transferred into an international norm IEC PAS 63088 [3]. While this helped to set overarching definitions for technical terms and a common understanding, its translation into technical building blocks remained open. Ref. [4] described an architecture enabling the so-called “Internet of Production”, which was again referenced in several publications such as [5,6]. Depicting several layers of data, this model can be used to understand data aggregation and refinement, yet it remains a high level architecture with little technical details. Several authors proposed architectures for Cyber-Physical Production Systems (CPPS) such as [7,8], with the first publications going back more than 10 years (e.g., [9]). Applications ranged from scheduling [10] to retro-fitting of existing old machines (e.g., [11]). To achieve the data integration of machines and sensors, the Asset Administration Shell (AAS) was developed as a quasi-standard for data modeling and structuring [12,13], with a focus on integration of automation control systems, the so-called Programmable Logic Controls (PLCs), as in [14,15]. During the last years, the term Digital Twin has gained significant attention, bringing together live data from the shop floor with models of machine or supply chain behavior, as, for example, in [16,17].

As can be seen, an abundance of architectures for data management platforms has been developed under different names to solve a variety of distinctive use cases in manufacturing. At the same time, several architectures that were proposed in the scientific literature seem to have significant overlap or at least similarities. From the perspective of application, no clear guidance could be identified as to when apply what kind of architecture. This contribution thus provides an overview of different architecture archetypes and when to apply them. Based on a classification scheme, the best-fitted archetype for specific boundary conditions is identified. Thus, the added value of this contribution lies in a classification and identification scheme for distinctive archetypes for data management in manufacturing.

We start by researching into the requirements and needs of different use cases and applications for data usage in manufacturing—from quality management, factory organization or resource coordination to energy optimization and condition monitoring. From these use cases, specific requirements will be deducted towards architectures that reflect the needs of these distinctive applications. Based on a holistic literature survey, archetypes for data management in manufacturing are condensed and classified with respect to their boundary conditions and characteristics. To illustrate these architypes more, example cases for some of these are presented.

2. Materials and Methods

This study is based on a systematic literature review aimed at identifying the architectural characteristics required to meet the technical demands of various data-driven use cases in manufacturing. The overarching goal is to develop a decision logic that supports the context-specific selection of suitable data platform architectures. To identify the most relevant publications in a structured review, the key technical terms are introduced in Section 2.1. Afterwards, the literature reviews itself is presented in Section 2.2.

2.1. Key Terms and Concepts

Latency: The ability of a digital system to respond to certain inputs in a pre-defined time span with a high certainty is often described as “real time”. This definition can be found in the ISO/IEC 2382 [18] and simply acknowledges the fact that latency requirements depend on the application. In the context of automatized systems such as CNC mills or robots, strong latency requirements might thus translate into few milliseconds. In the case of IT systems for business processes, weak (or relaxed) latency requirements often translate into the need to respond within several seconds [19].

Data volume: Low-volume applications in manufacturing often comprise readings from single sensors (Bytes) or text-protocols from controls (few Kilobytes). Applications with medium data volume might comprise pictures or program code (Megabytes), high volume applications sometimes range into Gigabytes [19]. At the same time, large amounts of low data producers might add up to medium data volume streams, as in the case of large scale sensor networks (e.g., [20]). Sometimes, data reduction techniques such as aggregation will come into play here.

Data consistency: Factories typically feature heterogenous data sources ranging from codified sensor data to vendor-specific automation protocols, pictures and even process management data, thus ensuring data consistency becomes a very important topic. At the same time, this might interfere with data reduction techniques to reduce volume.

Data integrity: While data consistency looks more at the availability of correct data for model building or control, integrity focuses more on data that has not be manipulated. This becomes very important when sharing sensitive quality data with customers and suppliers or managing orders across a value chain.

Security: Manufacturing companies often employ data security systems in accordance with international norms such as the ISO 27001 to prevent data breaches or unwanted intrusions [21]. In some cases, they might even be forced to consider tighter regulations as in the case of the EU Cyber Resilience Act [22]. At the same time, manufacturing-specific standards such as the IEC 62443 have not yet been introduced in large number [23].

Scalability: Scalability describes the ability of a system to scale, meaning to grow considerably in size. In the case of manufacturing systems, this depicts the ability to integrate new data producers such as sensors as well as resources, machines and employees seamlessly, without the need to manually change parts of the architecture.

2.2. Systematic Literature Review

The methodology follows the general principles of systematic literature reviews but does not explicitly apply formal frameworks such as PRISMA (short for ‘Preferred Reporting Items for Systematic Reviews and Meta-Analyses’) and SPAR-4-SLR (short for ‘Scientific Procedures and Rationales for Systematic Literature Reviews’). Our approach mirrors central elements of these frameworks—such as transparent filtering, clear inclusion criteria, and replicability—but deviates from them in specific areas. Since we used only the Scopus database, where a large number of relevant publications were already available, duplicate screening was not necessary. Moreover, to focus on identifying architectural requirements that are often mentioned only implicitly, we conducted a full-text analysis without an abstract-based screening in advance. This made it possible to extract nuanced technical details from a manageable number of papers, which justified the methodological divergence.

The search strategy was developed to systematically narrow down the literature corpus toward practically relevant publications at the intersection of industrial data usage and architectural design. A stepwise filtering approach was applied in the Scopus database, covering English-language publications from 2015 to 2025, including journal articles, review papers, and conference proceedings. The query was executed on 8 April 2025.

Figure 1 provides an overview of this four-step filtering process and illustrates the reduction in results across each stage.

In the first step (S1), the query combined general architectural terms with industrial manufacturing contexts: (“Data Architecture” OR “System Architecture” OR “Information Architecture”) AND (“Manufacturing” OR “Production Systems” OR “Industry 4.0” OR “Smart Manufacturing”). This resulted in 1213 initial publications.

In the second step (S2), the query was extended by integrating well-established architectural paradigms: S1 AND (“Edge Computing” OR “Cloud Computing” OR “Hybrid Architecture” OR “Data Mesh” OR “Monolithic Architecture” OR “On-Premise” OR “Digital Twin” OR “Centralized Architecture” OR “Distributed Architecture”). The inclusion of broader terms such as “Data Mesh” was intentional, as these papers often also cover concrete technical architectures that support such socio-technical concepts. This narrowed the results to 195 publications.

In the third step (S3), additional decision-relevant architectural factors were incorporated: S2 AND (“Requirements” OR “Design Criteria” OR “Influencing Factors” OR “Architecture Selection” OR “Real-time” OR “Latency” OR “Scalability” OR “Security” OR “Data Quality” OR “Complexity” OR “AI Readiness” OR “Data Privacy”). This final query yielded 123 publications, all of which were subjected to full-text review.

These 123 papers were analyzed using a table-based content analysis along pre-defined technical dimensions, including boundary conditions, databases, physical transmission technologies, communication protocols, cloud and edge components, and programming frameworks. The analysis was conducted collaboratively by three researchers and cross-validated through regular consensus sessions to ensure objectivity and consistency.

In a fourth step, each identified use case was additionally evaluated for its applicability and architectural relevance. A scoring system from 0 to 100% was applied, and only studies with a fit score of 60% or higher were retained for in-depth analysis, resulting in a final set of 61 studies. The rationale behind the 60% cutoff was based on an internal evaluation scale in 10% steps, where 50% marked the boundary between weak and adequate fit. Only papers with a use-case fit above this threshold—starting at 60%—were retained, ensuring that the final sample consisted of clearly relevant studies with sufficient architectural detail.

The evaluation focused on the practical and technically grounded description of each use case, particularly regarding data flow, system integration, and architectural components. For example, use cases without an active connection between data acquisition and processing were excluded, as such scenarios typically do not require a data platform and were therefore considered out of scope for this study.

Based on the results, thematic use-case clusters were derived inductively according to their application. In parallel, standardized architecture archetypes were extracted purely inductively from the technological configurations presented in the studies. These archetypes will be discussed in detail in a subsequent section.

The aim of this methodological approach was to identify architecture-specific requirements for various use case types and derive context-sensitive recommendations for data architecture design in manufacturing environments.

A list of all analyzed publications, including their assessed fit and detailed evaluations across relevant technical dimensions, is available via the link provided under ‘Supplementary Materials’.

3. Archetypes for Data Management Platforms in Manufacturing

The following section identifies the most relevant technical requirements and boundary conditions for data-driven use cases in manufacturing, based on the analysis of the 61 selected research papers. These include factors such as latency, data volume, and scalability. Building on this foundation, different use cases for data-driven optimization, monitoring, and control are subsequently discussed in relation to these requirements and constraints. These technical requirements and use cases are then used to cluster and organize different data management archetypes in manufacturing. Afterwards, each archetype is presented and discussed in detail.

3.1. Requirements of Archetypes

In the course of the systematic literature research, a number of highly relevant requirements and boundary conditions were identified: latency, data volume, scalability, application environment, data integrity, and the use of model-driven approaches. The characteristics and definitions of these requirements are not always formulated clearly and with integrity, which can lead to confusion and misinterpretation. For this reason, definitions are formulated below that largely align with the majority of the literature reviewed.

3.1.1. Latency

Latency, real-time-capabilities and high frequency of data transmission are mentioned as very important by nearly every analyzed paper, but unfortunately, these terms are interpreted extremely inconsistently as there is no exact scientific definition. While most of the 61 analyzed papers refer to low latency or real-time capabilities, only a few specify the required latency in absolute terms. In fact, the numbers quoted also vary widely: some papers, such as [24,25], describe systems that require reaction times of a few seconds or minutes; others, such as [26,27], write about milliseconds and even less. For a clear definition, this paper uses the term ‘low latency’ and ‘strong latency requirement’ to refer to time-critical controls or data transmissions of a few milliseconds and less.

3.1.2. Data Volume (and Heterogeneity)

In most of the analyzed papers, a large amount of data was mentioned as a boundary condition. However, none of them provided specific quantitative metrics regarding the volume of data. While some papers did not really address this issue, others used data preprocessing at the edge (e.g., [28,29]) or different database technologies (e.g., [25,30]) as a solution. Along with the volume of data, the challenge of data heterogeneity or the handling of data from different sources and formats is often mentioned, as [31,32] show.

3.1.3. Scalability

Scalability is the next term that seems to be relevant for some use cases or data platforms, and it is important to consider how it can be understood in these contexts. Articles such as [33,34] focus on gateways or Internet of Things (IoT) devices that enable scalable data collection and recording, referring to computational scalability. A more common description of ‘scalability’ is aligned to data throughput, emphasizing the possibilities of transmitting and storing data using data streaming (e.g., Apache Kafka [35]) or standardized transmission protocols and centralized databases; suitable examples include [24,36]. This latter understanding of scalability is used throughout the rest of this paper.

3.1.4. Application Environment

Looking at the different applications analyzed in the literature review, it is notable that some focus on fixed systems and machines, while others focus on movable entities and mobile robots. In [30,37], for example, applications are focused on digital twins of machines or production lines and are fixed in nature. Such systems work closely with PLCs and therefore use wired transmission technologies such as bus systems (e.g., Profibus [38]) or Ethernet. Typically, in correlation with logistics optimization, the data transmission of mobile entities is essential for creating digital twins, as can be found in [26,39,40]. These applications work with Automated Guided Vehicles (AGVs), requiring fast processing and transmission via 5G and tracking and tracing technologies such as Radio-Frequency Identification (RFID) and Ultra-Wideband (UWB).

3.1.5. Data Integrity

Besides the common challenge of cybersecurity—which will not be discussed in detail here—it is notable that some highlighted the importance of data integrity. This refers not only to the challenge of ensuring that data is correct, complete and consistent over time and in different formats, but also to protecting it against unauthorized modification. While blockchain technologies are one approach used to support tamper-proof and verifiable data records [41,42], data integrity is also addressed through other mechanisms, such as secure gateway solutions at the edge of the network [43].

3.1.6. Model-Driven Approach

The analysis of data archetypes in this literature review revealed a clear distinction: they can be broadly grouped into two categories—model-driven and non-model-driven approaches.

Model-driven approaches refer to data archetypes that are linked with advanced data analytics models or robotic control systems. These approaches are designed to enable highly analytical and autonomous systems directly on the shop floor. The data archetypes in this category are, therefore, tightly integrated with the operational logic and control mechanisms of these systems, facilitating real-time decision-making and automated actions. Their primary objective is to leverage data to drive sophisticated models that directly influence physical processes or automated functions, for example, refs. [44,45].

Conversely, non-model-driven approaches primarily focus on applications related to monitoring, data provision, and data sharing. These examples tend to operate at the management or business level, rather than directly controlling shop floor operations. While they are crucial for providing insights, supporting strategic decisions, and enabling information flow across an organization, they do not necessarily involve complex analytical models or direct robotic control. Instead, their emphasis is on ensuring data availability, consistency, and accessibility for broader oversight and collaborative purposes. Examples can be found in [46,47].

3.2. Use Cases

In recent years, the use of data management platforms in manufacturing has grown significantly. However, the objectives that companies aim to achieve with these platforms vary widely. As a result, the associated requirements and boundary conditions differ substantially across use cases. Through the literature study, several use cases and applications scenarios with distinctive boundary conditions were identified. In the following sub-chapters, these will be presented together with their technical characteristics regarding data volume, data variety, real time constraints and other.

3.2.1. Factory Management and Coordination

Factory management typically means the coordination of people, resources and assets on the scale of complete supply chains or at least several machines and processes. Typically, these stretch across a medium to large physical space. Due to different vendors and purchasing periods of equipment, data formats and technologies may vary. At the same time, data volume can be considered medium to high, depending on the amount of data provided by single resources. Real time constraints are typically relaxed (several seconds to even minutes), as people are in the loop to make management decisions.

3.2.2. Process Management and Monitoring

Monitoring and assessing single machines or processes is relevant in areas such as quality or operations management as well as planning and scheduling. The amount of data can be medium to high, for example, when data is taken from several sensors and PLCs to give a holistic assessment of the current situation of an asset. At the same time, extensive process models are sometimes used for predictions. Real time constraints for process management and monitoring are typically more relaxed, as human operators still make decisions and thus are part of a feedback cycle.

3.2.3. Process Control of Robots and Machines

As opposed to process monitoring or management, process control of robots and machines requires an active response to control a technical process to handle deviations and disturbances. With a focus on a small amount of processes (or even just one), the data amount typically is lower than in other use cases. At the same time, real time requirements are usually stronger due to short reaction times. However, depending on the process, these vary greatly. Motion control, as in robots, requires responses in the magnitude of milliseconds, while batch processes, as in plastic molding, might require an update only every batch or cycle, thus leaving several seconds for a response. Process control typically goes hand in hand with extensive process models on which to make predictions and draw conclusions.

3.2.4. Management of Auxiliaries

During the last years, the consumption of auxiliaries such as water, electrical energy or pressurized air have gained in importance due to rising prices as well as a change in political and regulatory focus. Thus, monitoring and managing these became a task for manufacturing companies. Typically, monitoring the consumption is a first step to later improvements. Typical meters will provide small amount of data (several bytes for one measurement) spread over relatively long periods of time. For example, in energy management, the billing interval of fifteen minutes used by electricity providers lead to measurement intervals of one minute or more. Thus, real-time constraints are very relaxed. Sections may be divided by subheadings. They should provide a concise and precise description of the experimental results, their interpretation, as well as the experimental conclusions that can be drawn.

3.3. Clustering of Archetypes

Based on the requirements derived in Section 3.1 and the use cases identified in Section 3.2, the research team has defined and clustered eight generic archetypes. A significant differentiation has been established between non-model-driven and model-driven approaches to guide the subsequent clustering based on these criteria comprehensively. A detailed description of these archetypes will follow in Section 3.4.

3.3.1. Archetypes Without Model-Driven Approaches

Drawing on the previously defined requirements, four generic archetypes have been identified that primarily support monitoring, data provision, and sharing within data management platforms. While it is important to acknowledge that model-driven approaches are possible in these contexts and are sometimes partially utilized, they do not primarily focus on complex analytical models or direct robotic control. Clustering these archetypes without models was the initial step. One archetype—blockchain—stood clearly apart from the others as in the publications addressing this, data integrity was the driver. Several distinguishing characteristics were tried to separate the remaining architectures, from the amount of data handled to latency requirements, safety, scalability and many more. Between the authors, it has been found to be most effective when considering three key characteristics: data volume, scalability and data integrity—each divided into low and high abilities. As shown in Figure 2, this three-dimensional classification provides a clear framework for understanding the varying technical demands and operational priorities of these diverse applications.

3.3.2. Archetypes with Model-Driven Approaches

Using the identified use cases and derived requirements as a basis, the research outlines four separate model-driven archetypes for data management platforms in manufacturing. What stands out is that the systematic classification based on latency requirements (ranging from weak to strong) and the application environment (fixed vs. mobile) proves to be particularly useful. This two-dimensional classification matrix provides a clear and effective categorization of diverse operational characteristics, offering a robust framework for understanding the unique demands of each archetype, as illustrated in Figure 3.

In relation to these four archetypes, digital twins are often employed. If there are strong latency requirements, one thing in particular should be emphasized: edge–cloud dualism. The advantage is that time-critical controls and data analysis model execution can be carried out directly on the machines at shop floor level, which usually have a direct connection to the PLC. Edge devices are used for this purpose and also enable data pre-processing. A central cloud or server operates as a service coordinator and supervisor where among various other functions, data analysis models can be created, trained and optimized. An overview of the edge–cloud-dualized architecture is provided in Figure 4, alongside descriptions of it in articles like [27,28].

3.4. Archetypes in Detail

Based on a total of 61 relevant publications identified in the literature review, the following sub-sections explore each architecture type in depth, drawing on the technological characteristics identified during the literature analysis. While the number of sources per archetype and per feature is often limited, these patterns still allow for meaningful classification, as the extracted characteristics are both consistent across cases and representative of core design decisions. This reflects the high diversity of use cases, but also the methodological decision to include only clearly assignable and explicitly described technological features per archetype.

3.4.1. Gateway

Gateway-based architectures represent a lightweight and modular approach to industrial data acquisition, particularly suited for decentralized environments with heterogeneous device landscapes and moderate real-time demands. A total of 13 publications implement a gateway pattern, characterized by intermediary nodes that mediate between field-level devices and higher-level systems. These nodes—typically implemented via Raspberry Pi [34,48] and comparable microcontrollers—facilitate protocol translation, local preprocessing, and secure transmission, often via Message Queueing Telemetry Transport (MQTT) and Open Platform Communications Unified Architecture (OPC UA) [33,49]. The gateway architecture is illustrated in Figure 5.

Common use cases include sensor integration for condition monitoring [34] and visualization dashboards [50]. Several implementations rely on edge-level inference using lightweight machine learning models [43], while others focus on reliable logging and visualization without local analytics. The architectural role is often passive or semi-active, with limited capacity for model-based control or autonomous decision-making.

Overall, gateway systems are primarily deployed in small to mid-sized setups, where low integration effort, cost-efficiency, and compatibility with legacy devices are critical. Architecturally, they are not very scalable due to the technical limitations of the edge devices used, but they are suitable for large volumes of data. This archetype is defined by its intermediary role between field and platform layers, using lightweight hardware, open communication protocols, and limited edge intelligence for basic preprocessing and integration tasks.

3.4.2. Low Energy, Wide Range

The low-energy, wide-range archetype comprises architectures that emphasize energy-efficient, long-range communication protocols such as Long Range Wide Area Network (LoRaWAN) and Zigbee. These systems typically target non-critical, large-area deployments in industrial settings where real-time constraints are relaxed. Five studies implement such architectures [25,36,46,47,51].

A typical application scenario is environmental or infrastructure monitoring as described in [46]. Such setups frequently combine time-series databases (such as InfluxDB [52]) with lightweight protocols like MQTT and Representational State Transfer Application Programming Interfaces (REST APIs), as seen in [36]. Due to the reliance on low-bandwidth communication, data is often transmitted at regular intervals rather than continuously, making these architectures suboptimal for high-frequency analytics or safety-critical control.

Architecturally, the edge is often minimal, with most processing tasks shifted to centralized platforms or clouds [36]. This communication and architecture pattern is illustrated in Figure 6, which shows temperature and infrastructure sensors connected via LoRaWAN. The systems primarily collect and forward data for visualization, condition monitoring, or usage analysis. As such, data volume is moderate to low, while data integrity mechanisms are usually absent or basic compared to other non-model-driven archetypes such as blockchain, which emphasize strong integrity guarantees as discussed in Section 3.4.3. This archetype is clearly characterized by low-frequency data capture, minimal edge capabilities, and the exclusive use of long-range, low-power protocols such as LoRaWAN or Zigbee.

3.4.3. Blockchain

Blockchain architectures are designed to provide tamper-proof, transparent, and decentralized data management, making them particularly attractive in collaborative manufacturing networks where data provenance and auditability are essential. Four studies implemented blockchain-based solutions in industrial settings [41,42,53,54].

These architectures typically rely on distributed ledger technologies such as Hyperledger Fabric, paired with WORM (short for ‘Write Once Read Many’) storage [53], and are often integrated with edge or fog computing layers to compensate for blockchain’s latency and throughput limitations [41,42]. While peer-to-peer communication protocols and consensus mechanisms ensure data integrity and non-repudiation, they impose performance trade-offs that restrict the applicability of blockchain to low-data-volume, high-integrity use cases, such as traceability documentation.

Architectural implementations are often hybrid: edge devices such as Raspberry Pi [55] and Jetson boards [56] act as blockchain clients [41], while cloud or fog nodes assume ledger synchronization and consensus roles. The systems evaluated are less performant in their real-time capability than other standard architectures but show strong guarantees in data authenticity and immutability, as illustrated by [53] in scenarios requiring long-term traceability across supply chains. Blockchain-based architectures stand out by combining distributed consensus mechanisms with immutable data storage, ensuring tamper-proof documentation and verifiable data exchange across multiple stakeholders, as exemplified in Figure 7.

3.4.4. Streaming

Streaming architectures enable continuous, near real-time ingestion and processing of high-frequency data streams in industrial contexts. Despite being supported by only two sources [31,57], this archetype represents a distinct and theoretically coherent architectural pattern. Its empirical limitations are acknowledged, but its inclusion is justified by the clarity and consistency of its defining technological characteristics.

Typically, these systems are employed where process data must be acquired and analyzed in parallel—for example, for scientific workflow orchestration [31]. The architectural backbone often includes distributed data flow engines like Spark [58], HDFS storage systems such as Hadoop [59] or actor-based workflow environments such as Kepler [60]. Communication is facilitated via standard protocols (e.g., OPC UA, MTConnect, Hypertext Transfer Protocol Secure (HTTPS)), and data is either directly streamed to cloud-based platforms or routed through intermediate orchestration layers, as also reflected in the producer-consumer setup shown in Figure 8.

The streaming paradigm supports high-volume, high-velocity applications with tight temporal coupling between data capture and analysis, meaning minimal delay between data capture and analysis. However, latency constraints vary depending on the process. From an architectural classification perspective, streaming systems offer the processing of large volumes of data coupled with high scalability. Yet this benefit comes at the cost of lower data integrity. Streaming architectures are uniquely defined by their continuous data ingestion pipelines, distributed processing layers, and high-throughput capabilities, tailored for time-critical and data-intensive applications.

3.4.5. Management and Monitoring

The archetype for digital twins in factory management and monitoring mostly focuses on fixed systems with lower latency requirements. These architectures are primarily used for tasks such as planning, scheduling, quality management and operations management, thus referring to the use case outlined in Section 3.2.2. Five studies clearly belong to this category: [61,62,63,64,65].

The technical implementation often involves edge devices, such as Raspberry Pi’s [55] (as indicated in [61,62,63]), for localized data capture and preprocessing. For broader storage, analytics, and the deployment of machine learning models, cloud platforms (e.g., [62,63]) are commonly employed. Data persistence is managed through various database technologies, including both traditional SQL databases (as widely seen in [65]) and Not only Structured Query Language (NoSQL) solutions (e.g., [62]). Communication between these components typically leverages lightweight protocols like MQTT or REST APIs [61,62], with OPC UA also being a common standard for industrial interoperability [63]. This integration of data sources to factory management models is schematically outlined in Figure 9.

These architectures are characterized by their support for fixed, low-latency systems using hybrid storage, moderate edge processing, and industrial-standard protocols for factory-wide transparency and coordination.

3.4.6. Resource Orchestration

This archetype, focusing on resource orchestration, also exhibits lower real-time requirements, like the “Management and Monitoring” archetype. However, its distinctive feature lies in its emphasis on large-scale systems involving mobile entities and the efficient management of dynamic resources. Relevant literature supporting this archetype includes sources [40,66,67,68].

These systems are typically used for logistics planning, scheduling, and dynamic coordination tasks, including the simulation of production and supply chains (e.g., [66,67]). A representative overview of how spatially distributed assets are coordinated is provided in Figure 10.

Technologically, the utilization of SQL databases is a common characteristic. Crucially, these systems leverage various spatial positioning technologies, such as RFID, Bluetooth Low Energy (BLE), UWB, Barcodes, and Global Positioning System (GPS), to track and manage mobile assets. The data generated by these entities is typically transmitted wirelessly via Wireless Fidelity (WiFi) and 4G networks (supported by [40,67,68]). Resource orchestration architectures combine flexible connectivity and localization technologies to manage dynamic, mobile elements across large-scale industrial environments with moderate latency demands. Orchestrating and managing resources often also entails the necessity to deal with data veracity, meaning to create decisions based on contradictory information or demand from these resources.

3.4.7. Process Control

The archetype for process control demands strong latency requirements despite primarily operating with fixed machines and robots. It directly refers to the process control use case formulated in Section 3.2.3, focusing on active responses to handle deviations and disturbances. These systems are frequently employed in autonomous robotic control systems, where immediate reactions are paramount. Therefore, such architectures typically leverage the advantages of the edge–cloud dualism, as explained in Section 3.3.2. A total of 12 papers were identified in the literature review that fit very well into this category: [27,28,30,44,69,70,71,72,73,74,75,76].

Structured data is usually stored in SQL databases (e.g., [27,71,75]), complemented by NoSQL databases such as MongoDB [77] (e.g., [30,71]) and graph databases like Neo4j [78] for semantic knowledge representation (e.g., [27]). The edge layer predominantly uses wired Ethernet connections (e.g., [44,69,71]) to robot controllers to achieve low latency. Communication protocols typically include REST APIs (e.g., [28,69]) and OPC UA for PLC access (e.g., [73]), while 5G wireless connectivity is occasionally used (e.g., [70,73]). Data is transferred to the cloud via MQTT [27].

These architectures are defined by high-frequency edge processing, direct PLC integration, and deterministic low-latency communication between industrial resources and control systems to enable sub-second control, as exemplified in Figure 11, which illustrates a manufacturing resource connected to an edge computing device using fieldbus protocols such as EtherCAT.

3.4.8. Large-Scale, Time-Critical Control

This archetype represents highly demanding scenarios requiring both very low latency for real-time transmission and the ability to manage mobile entities throughout the factory. Applications include logistics and safety-critical systems involving human–machine interaction, such as AGV control [26], collision detection [20], worker-aware systems [32], and mobile robotic platforms [79].

Edge–cloud dual architectures, as also seen in the “Process Control” archetype, are typical in this context. Additionally, high-performance wireless communication—especially 5G as noted by [26]—is essential to meet latency requirements. As with “Resource Orchestration”, positioning technologies like RFID or UWB are frequently used for precise localization [32]. OPC UA is commonly used for control system connectivity, while MQTT supports data exchange [20,32]. These architectures often employ a combination of various database types. For example, Ref. [32] utilizes a Neo4j graph database for instance data and local storage, alongside MySQL for shipment data.

These architectures uniquely combine real-time edge analytics, mobile coordination, and ultra-low latency communication to ensure responsive, safe operations in highly dynamic production environments, as visualized in Figure 12.

4. Example Cases

In the following chapter, some examples are provided for some of the archetypes described above. These example cases will provide a better insight into the different architectures, their respective applications and boundary conditions. All example cases have been taken from the InnovationHub Bergisches Rheinland in Gummersbach and were developed under the research grant mentioned at the end of this contribution.

4.1. Gateway for Computerized Numerical Control Data

Computerized Numerical Control (CNC) mills are widely used in manufacturing, especially for metal cutting. In Germany and other European countries, controls provided by Siemens are prevalent, but other manufacturer such as Rockwell, Heidenhain and Mitsubishi feature a relevant market share. In the case of our model factory, we use a DMG Mori 3-axis CNC mill [80] with a Siemens control system [81] that is able to act as an OPC UA server. To extract data from the CNC, pre-process, accumulate and push this information to a database, a Raspberry Pi 4 (8GB) [82] running node-RED [83] is used.

The data from the CNC is pushed to a time-series database, in our case an InfluxDB [52] with a cloud installation hosted by the provider. Data is requested and processed once per second and used to gain insights into classical operations KPI such as process time and Overall Equipment Effectiveness (OEE). Dashboards for machine surveillance were developed in Grafana [84] and are currently displayed in physical proximity to the CNC. Theoretically, the dashboards could be displayed anywhere as the data is stored in a cloud environment and latency requirements are in the area of several seconds. This classical gateway architecture is typical for such use cases, moderately easy to install and relatively cheap. All software components are open source, the hardware needed costs less than 100 €.

4.2. Low Energy, Wide Range for Building Resource Monitoring

The model factory in Gummersbach has been equipped with a system for monitoring the energy and resource consumption of the building. In our specific case, a network of LoRaWAN based sensor has been installed. The overall energy consumption is monitored, as well as the status of several windows and doors (open/close), humidity and temperature of the main hall. All sensors transmit their data package through an MQTT protocol to a central antenna, wide proven range of up to 100 m. As data is collected and handled only once per minute and the overall energy consumption of the physical transmission is low, all sensors are battery operated and last several years.

From the antenna, all data is pushed to a cloud-deployed back-end employing a time-series database as well as dashboards based on Grafana [84]. As was the case with the other architecture presented before, this dashboard is available globally.

5. Discussion

This paper aimed to identify use-case-driven requirements for industrial data architectures and derive context-specific archetypes based on a systematic literature analysis. The motivation was rooted in the observation that manufacturing use cases—ranging from factory management to predictive maintenance and real-time control—entail vastly different demands regarding latency, data volume, data integrity, scalability, and architectural complexity. By analyzing 61 publications and clustering technical configurations into eight archetypes, the study offers a structured framework for understanding and evaluating architectural choices in industrial contexts.

The archetypes developed in this study are not just descriptive patterns—they highlight recurring technological trade-offs and reflect functional priorities across industrial scenarios. Model-driven archetypes emphasize edge–cloud dualism and latency-critical capabilities, making them essential for control-related use cases. Non-model-driven archetypes, in contrast, prioritize scalability, broad data accessibility, or integrity over real-time responsiveness, and are typically used in applications where reactive control is not required. This conceptual distinction allows practitioners to navigate the complexity of platform design by aligning requirements with feasible architectural models.

A key insight is that no universal architecture satisfies all boundary conditions. This becomes particularly evident when considering non-model-driven archetypes, which inherently reflect necessary compromises between data volume, latency, integrity, and implementation effort. For example, the blockchain archetype ensures tamper-proof logging but is limited in throughput, while streaming architectures offer high scalability at the cost of data integrity. These archetypes are each optimized for specific objectives—such as trust, volume, or reach—but cannot meet all requirements simultaneously. As a result, future data platforms in manufacturing will likely require hybrid or layered combinations of these non-model-driven archetypes to achieve broader applicability and technical balance.

Beyond the technical classification, this study supports strategic decision-making in manufacturing IT. The archetypes provide orientation for both greenfield implementations and incremental modernization strategies, where legacy constraints or application-specific priorities shape the technical solution space.

Future work should expand on several fronts. First, the integration of hybrid architectures that combine the strengths of different archetypes appears promising. Secondly, the development of a standardized architecture archetype that balances high scalability, large data volume handling, and strong data integrity in non-model-driven contexts should be explored. This would address the critical trade-offs highlighted in Figure 2 and support broader applicability of data platforms in manufacturing. Third, future work could explore how modular and reconfigurable architectures can be designed to allow for incremental expansion or adaptation as manufacturing requirements evolve—without necessitating a complete system overhaul.

In addition, a longitudinal evaluation of archetype implementations across industrial sectors could help verify the generalizability and refine the classification logic over time.

6. Conclusions

This paper systematically classified eight archetypes for data platform architectures in manufacturing, based on a review of 61 peer-reviewed publications. The classification differentiates between model-driven and non-model-driven architectures, each aligned with specific use-case characteristics and technical requirements.

Key results include:

• A clear distinction between latency-critical architectures (e.g., process control) and data-sharing-oriented architectures (e.g., blockchain, gateway);
• A three- and two-dimensional framework for organizing archetypes according to requirements such as data integrity, scalability, latency, and mobility;
• The identification of trade-offs between architectural properties, illustrating that hybrid or modular solutions may be necessary in real-world settings.

This typology offers both researchers and practitioners a structured reference for aligning technical choices with industrial needs. Future work should focus on hybrid archetype combinations and empirically validating implementation outcomes.