Concepts such as the Digital Thread and the Digital Twin pursue the goal of maintaining continuous and traceable data throughout the entire product life cycle. This paper applies the fundamental principles of these concepts to automotive series production. This sector in particular, requires information systems (IS) that link product information documented at the development stage with process data derived from the shop floor. <\/p>\n\n\n\n
Changes from development departments must be seamlessly transferred to production systems (downstream)\u2014for example, adjustments to welding parameters based on new strength requirements\u2014while, conversely, changes arising in production must be systematically fed back to the relevant departments (upstream). This bidirectional integration is particularly relevant in the context of AI-based applications, whose effectiveness depends directly on the availability and quality of the underlying data [2]. Welding parameters for example, can already be optimized using AI. However, implementing these optimized parameters in production largely remains a manual process [3]. <\/p>\n\n\n\n
This article addresses this gap by establishing the conceptual foundation for a generic information system (IS) that enables AI-modified process parameters to be transferred deterministically to production equipment following human approval. The IS serves as an enabling platform that existing AI applications can build upon, allowing their results to be transferred directly to the operational level of production. <\/p>\n\n\n\n
At the same time, such an IS can help preserve expertise long term by permanently archiving automatically transferred parameters, whereas documentation has traditionally depended on the diligence and consistency of individual personnel. The automotive body-in-white production department serves as application context for the design of such an IS in this study. <\/p>\n\n\n\n
The objective of this paper is to derive fundamental principles of an IS for the bidirectional transfer of structured parameters\u2014both downstream and upstream\u2014within the cycle-time-driven production processes of the automotive industry. This paper is part of an ongoing research series in this field and follows the Design Science Research (DSR) paradigm. It represents the first building block of an nascent design theory and draws on established solution patterns from the Industrial Internet of Things (IIoT) to develop architectural approaches for the transfer described above (exaptation according to [4]).<\/p>\n\n\n\n
For the purposes of this paper, it is important to distinguish between different types of data. A distinction is made between three types of parameters:<\/p>\n\n\n\n
- \n
- Runtime variables that are read or modified during operation (e.g., the pressure in a vessel),<\/li>\n<\/ul>\n\n\n\n
- \n
- structured setpoint parameter sets in the form of programs or recipes that define the process logic (e.g., a welding program with specified setpoints\/targets for current, voltage, and time), and<\/li>\n<\/ul>\n\n\n\n
- \n
- configuration data with long-term relevance (e.g., the network configuration of a production machine).<\/li>\n<\/ul>\n\n\n\n
This article focuses on structured parameter sets, as they directly specify and determine the execution of production processes.<\/p>\n\n\n\n
Current state of research<\/h2>\n\n\n\n
The bidirectional integration of industrial systems has been the subject of numerous research studies in the context of the Industrial Internet of Things (IIoT). Opa\u010din et al. [5] and Ungurean and Gaitan [6], for example, demonstrate that industrial controllers can be connected bidirectionally to higher-level systems using Message Queuing Telemetry Transport (MQTT)- and fog-based architectures, respectively. <\/p>\n\n\n\n
However, these approaches focus primarily on runtime variables, with IoT capabilities largely limited to the sensor and actuator levels. Web-based Human\u2013Machine Interface (HMI) approaches, such as those presented by Jeng and Chieng [7], primarily expand operator interaction and visualization capabilities without addressing the structured and process-safe transfer of setpoint parameter sets to the operational production environment.<\/p>\n\n\n\n
In contrast, cloud- and platform-centric architectural approaches within the automotive industry demonstrate a high degree of maturity in the upstream integration of machine data, as shown in [3] and [8]. Both studies highlight the potential of centralized platforms for aggregating and analyzing production data. However, these studies do not address the automated downstream transfer of structured setpoint parameters into production.<\/p>\n\n\n\n
The closest match to the topic addressed in this paper is the Digital Process Chain proposed by Schramm et al. [9]. Their approach describes a bidirectional IIoT architecture in which production-relevant parameters are managed through a central IS and transmitted to machine controllers in a standardized manner via middleware. This demonstrates the fundamental feasibility of transferring setpoint parameters within a production environment.<\/p>\n\n\n\n
At the same time, the authors themselves point to open questions regarding the scalability of the approach to high-volume series production systems. The present paper, together with subsequent studies in this research series, builds on the work presented in [9] as a conceptual foundation and aims to address these open issues.<\/p>\n\n\n\n
Based on criteria relevant to this research, all reviewed studies are compared in Figure 1<\/strong>.<\/p>\n\n\n\n
![\"Figure](\"https:\/\/industry-science.com\/wp-content\/uploads\/2026\/09\/Richter-1.jpg\")
Figure 1: Distinction between related studies based on criteria defining the subject of investigation (\u2713 met, (\u2713) partially met, \u2717 not met; \u2020 automotive context without implementation in series production).<\/em><\/figcaption><\/figure>\n\n\n\n The comparison presented in Figure 1 reveals a clear asymmetry: while the upstream of state and process data has already reached a high level of maturity, the downstream transfer of structured setpoint parameter setswithin cycle-time-driven execution has so far been addressed only to a limited extent and has not been comprehensively solved for high-volume series production in any of the reviewed studies. Recent literature reviews confirm that Digital Manufacturing architectures largely remain at the prototype level, while bidirectional approaches are still rare [10, 11].<\/p>\n\n\n\n
The resulting research gap therefore lies in the development of a concept that consistently transfers structured setpoint parameter setsto the operational execution level in a technology-independent manner while meeting the requirements for robustness, availability, and process safety in high-volume body-in-white series production.<\/p>\n\n\n\n
Methodology and meta requirements<\/h2>\n\n\n\n
This paper adopts the DSR paradigm [12] and structures the research according to the DSR phases outlined by Peffers et al. [13]. Hevner et al. [12] describe DSR as a problem-solving-oriented paradigm that generates knowledge by creating and evaluating innovative artifacts to solve relevant problems.<\/p>\n\n\n\n
As a problem-centered study following [13], this article covers the first two activities of the Peffers model: problem identification and the derivation of solution objectives. The development, demonstration, and evaluation of the overall artifact will be addressed in subsequent papers within this research series. <\/p>\n\n\n\n
The problem is identified through the introduction and state-of-the-art review and is further specified below using so-called Meta-Requirements (MRs) [13], while the solution objectives are formulated as architectural design principles. According to the \u201cKnowledge Contribution Framework\u201d of Gregor and Hevner [4], this work represents a Level 2 knowledge contribution, namely a nascent design theory in the form of an exaptation that transfers established solution patterns from the IIoT to the previously described problem context.<\/p>\n\n\n\n
For the bidirectional target architecture, the meta-requirements (MR) are derived from the problem context. Building on these, architectural design principles for the body in white domain are developed.<\/p>\n\n\n\n
The first MR concerns robustness. In body-in-white production, any equipment downtime directly affects the entire line and results in significant opportunity costs. An IS whose failure interrupts production would therefore not be suitable for practical use. This leads to MR-1: Ongoing production must be able to continue without disruption in the event of an IS failure or a loss of connectivity to the IS (non-production-critical).<\/p>\n\n\n\n
The second MR concerns the timing of parameter adoption. Uncontrolled adoption of parameters during an ongoing production step can lead to inconsistencies: a weld spot whose current is changed during the process is neither reproducible nor quality-assured. In extreme cases, this can result in product defects or equipment failure. This leads to MR-2: Structured setpoint parameter sets must be adopted deterministically and in a process-compatible manner during ongoing production.<\/p>\n\n\n\n
The automotive body-in-white production process typically involves several thousand IIoT assets capable of communication. In this environment, an IS must thus be designed to scale effectively even with a high amount of assets. This leads to MR-3: The IS must be designed to be cost-effective and communicatively scalable when handling a vast number of assets, with minimal additional effort per asset.<\/p>\n\n\n\n
The control landscape in the body in white production is heterogeneous across manufacturers. Production equipment is gradually renewed over long lifecycles. Therefore, the architecture must be able to uniformly integrate equipment from different manufacturers and generations. Hence, MR-4: Data access and parameter descriptions must be standardized and semantically unambiguous across heterogeneous equipment.<\/p>\n\n\n\n
An unauthorized change of setpoint parameters can destroy both the product and the manufacturing system. Consequently, controlled Operational Technology (OT)\/Information Technology (IT) interfaces and means of authorized parameterization are required. This leads to MR-5: Changes to setpoint parameter setsin the downstream process must be authorized and protected against unauthorized access.<\/p>\n\n\n\n
Architectural principles of the target architecture<\/h2>\n\n\n\n
Principle 1<\/strong> (fulfills MR-3, MR-2, MR-1): Target parameters are distributed centrally and event-driven in the downstream. They are activated by the controller based on its system state.<\/p>\n\n\n\n
This distinction builds on the overarching communication logic (pull vs. push). In a pull-based approach, the production equipment actively retrieves the setpoint parameters from a central instance (Fig. 2), enabling state-dependent and therefore deterministic parameter adoption (see [9]). However, in body-in-white production, a pull-based approach presents significant scalability challenges: to detect changes in a timely manner, each of the N assets within a given technology must periodically retrieve its complete set of x setpoint parameter sets, regardless of whether any parameter has changed. <\/p>\n\n\n\n
Thus, each polling cycle generates a load of N \u00b7 x requests per technology, resulting in a total of Q = N \u00b7 k \u00b7 x requests across k technologies. For example, in spot welding, a controller can execute multiple weld spots p per cycle (e.g., p = 5), which might be programmed differently for different vehicle variants (e.g., v = 20 variants). The number of programs that must be maintained would be x = v \u00b7 p = 100 per asset. With N = 1,000 assets, spot welding alone would generate 10\u2075 requests per cycle; across multiple technologies, Q can quickly reach the millions. Because target parameters are changed relatively infrequently compared to the amount of polls during steady-state series production, this data traffic is almost entirely redundant.<\/p>\n\n\n\n
The problem is further highlighted by the fact that requests are not uniformly distributed over time. Since many stations operate with similar cycle times, requests can become concentrated in certain time windows, requiring the central IS to be dimensioned for load peaks that provide no additional information. The pull approach therefore scales poorly with the number of production assets and fails to satisfy MR-3.<\/p>\n\n\n\n
![\"Figure](\"https:\/\/industry-science.com\/wp-content\/uploads\/2026\/09\/Richter_Figures2-4_page-0001-e1788455831744.jpg\")
Figure 2: Schematic comparison of pull- and push-based communication in the downstream process.<\/em><\/figcaption><\/figure>\n\n\n\n In contrast, a push-based IS distributes the target parameters as needed and only when actual changes occur. The load (on the order of N \u00b7 fp with a change rate of fp per asset) is several orders of magnitude lower and is not cycle-correlated. <\/p>\n\n\n\n
To comply with MR-2, the IS must be supplemented with a buffer and a transfer mechanism within the asset. The setpoint parameter sets are pushed to the buffer and transferred to the production programs by the controller only when the relevant state conditions are met, ensuring that the ongoing production process is not affected in an uncontrolled manner. Since the most recently distributed parameter set is available locally, this also decouples the controller from the platform\u2019s availability (MR-1).<\/p>\n\n\n\n
Principle 2<\/strong> (meets MR-3): IIoT communication capabilities should be ensured device-natively wherever possible; dedicated hardware should be avoided.<\/p>\n\n\n\n
Today, production systems are often connected to central data platforms via dedicated hardware in the form of edge or IIoT gateways [14] (Fig. 3<\/strong>), which convert fieldbus-based communication into standardized IIoT protocols.<\/p>\n\n\n\n
![\"Figure](\"https:\/\/industry-science.com\/wp-content\/uploads\/2026\/09\/Richter_Figures2-4_page-0002-e1788455891137.jpg\")
Figure 3: Schematic illustration of the use of edge devices to connect production equipment to centralized data platforms.<\/em><\/figcaption><\/figure>\n\n\n\n Given the several hundred to thousand assets N typical in the body-in-white domain, this approach does not scale economically or operationally (MR-3). Each gateway entails acquisition costs CHW and, in most cases, an annual, device-specific management license CLic. Over n years, the total cost C(N) = N(CHW + n \u00b7 CLic) grows linearly with N.For N = 1,000 and n = 10, the licensing costs alone quickly reach several million euros. Operationally, each gateway also introduces an additional node with its own deployment and lifecycle management effort, creating a second prerequisite for commissioning that must be fulfilled for each asset.<\/p>\n\n\n\n
Modern assets, by contrast, increasingly incorporate native IIoT interfaces [15, 16], thereby becoming IIoT participants themselves. Additional procurement, licensing, and maintenance costs are largely eliminated, as connectivity and updates occur within the assets\u2019 lifecycle. A prerequisite for this approach is a standardized interface and data model (MR-4). The adoption of device-native connectivity should therefore be pursued as a long-term objective, while edge gateways should remain reserved for legacy assets without native IIoT capabilities.<\/p>\n\n\n\n
Principle 3<\/strong> (fulfills MR-3, MR-5, MR-1): Security and coordination functions should be consolidated in decentralized on-premises fog nodes.<\/p>\n\n\n\n
A fog node refers to a decentralized computing unit within the IIoT architecture that is positioned between shop-floor-based systems and central cloud services and acts as an intermediary. In the context of automotive body-in-white manufacturing, the fog node can assume coordination and security functions for defined areas, such as production lines or sites. <\/p>\n\n\n\n
Figure 4<\/strong> schematically illustrates how fog nodes can be integrated into an IIoT architecture. Instead of N direct shop-floor-to-cloud connections, each fog node maintains local connections with the assets, with only one outward cloud-connection per area (MR-3). For downstream communication, incoming setpoints parameter sets can be pre-validated, e.g., regarding semantic correctness and version consistency. At the same time, the fog node can act as a security enforcement point, providing a clear separation between OT networks and wide-area networks (MR-5).<\/p>\n\n\n\n
![\"Figure](\"https:\/\/industry-science.com\/wp-content\/uploads\/2026\/09\/Richter_Figures2-4_page-0003-e1788455961327.jpg\")
Figure 4: Schematic illustration of the use of fog nodes to connect IIoT-enabled production assets to centralized data platforms.<\/em><\/figcaption><\/figure>\n\n\n\n Principle 4<\/strong> (fulfills MR-3, MR-4): Parameter distribution is performed using a widely adopted IIoT communication standard (preferably MQTT) and is based on a standardized information model.<\/p>\n\n\n\n
Two communication standards dominate the IIoT landscape: Open Platform Communications Unified Architecture (OPC UA) and MQTT. OPC UA provides structured information through an object-oriented information model implemented on the machine side [3, 9], thereby ensuring unambiguous semantic representation of setpoint parameters (MR-4). However, large parameter sets entail considerable modeling effort, while the fine-grained read\/write communication of OPCUA results in a large number of individual accesses: A set of P parameters may require up to P individual accesses (contradicting MR-3).<\/p>\n\n\n\n
In contrast, MQTT takes a lightweight, broker-based publish\/subscribe approach using topics, thereby enabling efficient, scalable distribution to many subscribers (meets MR-3), but does not specify any message semantics. For downstream communication, the semantics of the messages must therefore be standardized outside the protocol, for example through Asset Administration Shells [17], to ensure correct machine-side processing (MR-4). Due to its better scalability, MQTT should preferably be used in body-in-white manufacturing.<\/p>\n\n\n\n
Evaluation of the principles<\/h2>\n\n\n\n
The evaluation of the derived principles is conducted ex ante in an artificial-formative manner, in accordance with [18]. The principles formulated above are evaluated analytically against the meta-requirements and validated using a representative scenario.<\/p>\n\n\n\n
Completeness:<\/strong> Each of the five meta-requirements is addressed by at least one principle (MR-1: P1, P3), (MR-2: P1), (MR-3: P1\u2013P4), (MR-4: P4), (MR-5: P3). Conversely, each principle can be traced back to at least one meta-requirement. Thus, neither an unaddressed requirement nor an unsubstantiated principle without a corresponding requirement remains.<\/p>\n\n\n\n
Consistency: <\/strong>The principles are mutually consistent and interrelated: Push-based, event-driven distribution (P1) is compatible with device-based connectivity (P2) and asynchronous, broker-based transport (P4). Buffering the parameters on the asset (P1) resolves the apparent contradiction between the asynchronous broker and the cycle time-driven production by shifting determinism to the asset (MR-2).<\/p>\n\n\n\n
Scenario walkthrough: <\/strong>A set of welding parameters\u2014approved by the development team and optimized by AI\u2014is distributed in an event-driven, broker-based manner along with a supplementary information model (P1, P4). Along the path to the asset, communication is secured and pre-validated by a fog node (P3). The welding parameter set is buffered in within the production assets (P2) until the controller activates it in a defined state outside an active production cycle. The path complies with all principles without contradiction and culminates in a deterministic, cycle-accurate implementation.<\/p>\n\n\n\n
A naturalistic, summative validation through quantitative studies requires a system instantiated in the field and will therefore be addressed in subsequent contributions of this research series.<\/p>\n\n\n\n
Implications for architecture development<\/h2>\n\n\n\n
This article demonstrates that the bidirectional connection of production systems in body-in-white manufacturing is not merely an integration problem but raises fundamental questions regarding architectural design. While existing IIoT approaches largely address the upstream of machine state data, significant deficits remain in the downstream of setpoint parameter setssinto cycle-bound processes in a deterministic and state-dependent manner. <\/p>\n\n\n\n
These deficits become increasingly relevant with the adoption of AI-based applications. To address them, four key architectural principles were derived. Further research is should focus on developing and validating a corresponding architecture under real-world production conditions: While the fundamental feasibility of bidirectional communication is established, the central challenge lies in its process-reliable, scalable, and standardized implementation.<\/p>\n\n\n\n
In this paper, the generative AI tool ChatGPT (provider: OpenAI, version: GPT-4\/5, period: February\u2013June 2026) was used for the linguistic revision of text passages. All substantive statements, assessments, and scientific arguments were formulated independently.<\/em><\/p>\n
Bibliography <\/h2>[1] \tRiaz, A.; Ullah, A.; Muhammad, B.: The Impact of Global Supply Chain Pressure on the Stock Market: A Sectoral View\u201c. In: Humanities and Social Sciences Communications 12 (2025) 1, pp. 284. DOI: https:\/\/doi.org\/10.1057\/s41599-025-04634-0\r
[2] \tMueller, C.; Mezhuyev, V.: AI Models and Methods in Automotive Manufacturing: A Systematic Literature Review. In: Al-Emran, M.; Shaalan, K.: Recent Innovations in Artificial Intelligence and Smart Applications 1061. Cham 2022, pp. 1\u201325. DOI: https:\/\/doi.org\/10.1007\/978-3-031-14748-7_1\r
[3] \tParant, A.; Chen, Y.: Industrial Metaverse Architecture in the Automotive Sector. In: Barata, J.; Madani, K.; Panetto, H.: Innovative Intelligent Industrial Production and Logistics. Cham 2026, pp. 246\u2013261. DOI: https:\/\/doi.org\/10.1007\/978-3-032-15576-4_16\r
[4] \tGregor, S.; Hevner, A. R.: Positioning and Presenting Design Science Research for Maximum Impact1\u201c. In: MIS Quarterly 37 (2013) 2, pp. 337\u2013 355. DOI: https:\/\/doi.org\/10.25300\/MISQ\/2013\/37.2.01\r
[5] \tOpa\u010din, S.; Rizvanovi\u0107, L. et al.: Developing and Evaluating MQTT Connectivity for an Industrial Controller. In: 2023 12th Mediterranean Conference on Embedded Computing (MECO). Budva, Montenegro: IEEE, June 2023, pp. 1\u20135. DOI: https:\/\/doi.org\/10.1109\/MECO58584.2023.10154921\r
[6] \tUngurean, I.; Gaitan, N. C.: Software Architecture of a Fog Computing Node for Industrial Internet of Things. In: Sensors 21 (2021) 11, DOI: https:\/\/doi.org\/10.3390\/s21113715 \r
[7] \tJeng, S.-L.; Chieng, W.-H.: Web-Based HMI of Industrial Controllers for General Purpose\u201c. In: 2020 3rd IEEE International Conference on Knowledge Innovation and Invention (ICKII). August 2020, pp. 212\u2013215. DOI: https:\/\/doi.org\/10.1109\/ICKII50300.2020.9318905 \r
[8] \tSanz, E.; Blesa, J.; Puig, V.: BiDrac Industry 4.0 Framework: Application to an Automotive Paint Shop Process. In: Control Engineering Practice 109 (2021), pp. 104757. DOI: https:\/\/doi.org\/10.1016\/j.conengprac.2021.104757 \r
[9] \tSchramm, N.; Richter, T. et al.: Realization of a Digital Process Chain Architecture: Rapid Reconfiguration of Production Machines for Product Changes. In: Procedia Computer Science. 7th International Conference on Industry of the Future and Smart Manufacturing (Former International Conference on Industry 4.0 and Smart Manufacturing) 277 (2026), pp. 342\u2013355. DOI: https:\/\/doi.org\/10.1016\/j.procs.2026.02.076\r
[10] \tKaiser, J.; McFarlane, D. et al.: A review of reference architectures for digital manufacturing: Classification, applicability and open issues\u201c. In: Computers in Industry 149 (2023), pp. 103923. DOI: https:\/\/doi.org\/10.1016\/j.compind.2023.103923\r
[11] \tPermana, A. K.; Muhammad Naim, K. M.; Khalif, Ku et al.: Bidirectional Synchronization between AR\/MR Interfaces and Digital Twins in Industrial Manufacturing: A Systematic Literature Review\u201c. In: The International Journal of Advanced Manufacturing Technology. DOI: https:\/\/doi.org\/10.1007\/s00170-026-17614-8\r
[12] \tHevner, A. R.; March, S. T. et al.: Design Science in Information Systems Research1\u201c. In: MIS Quarterly 28 (2004) 1, pp. 75\u2013106. DOI: https:\/\/doi.org\/10.2307\/25148625\r
[13] \tPeffers, K.; Tuunanen, T. et al.: A Design Science Research Methodology for Information Systems Research\u201c. In: Journal of Management Information Systems 24 (2007), pp. 45\u201377.\r
[14] \tSiemens AG: Industrial Edge. URL: https:\/\/www.siemens.com\/de-de\/products\/industrialedge\/devices\/, accessed 30.03.2026.\r
[15] \tBossard \u00d6sterreich. URL: https:\/\/www.bossard.com\/at-de\/wissen\/ressourcen\/download-center\/produkte-und-loesungen\/produktinformationen\/, accessed 23.03.2026.\r
[16] \tSKS: LSQ COMPACT IoT. URL: https:\/\/www.sks-welding.com\/produk te\/schweissmaschinen\/compact-systeme\/lsq-compact-iot, accessed 20.03.2026.\r
[17] \tIndustrial Digital Twin Association e.V.: IDTA \u2013 Der Standard f\u00fcr den Digitalen Zwilling. URL: https:\/\/industrialdigitaltwin.org\/, accessed 01.04.2026.\r
[18]\tVenable, J.; Pries-Heje, J.; Baskerville, R.: FEDS: A Framework for Evaluation in Design Science Research\u201c. In: European Journal of Information Systems 25 (2916) 1, pp. 77\u201389. DOI: https:\/\/doi.org\/10.1057\/ejis.2014.36 \r
<\/div>Your downloads<\/h2>
- configuration data with long-term relevance (e.g., the network configuration of a production machine).<\/li>\n<\/ul>\n\n\n\n
- structured setpoint parameter sets in the form of programs or recipes that define the process logic (e.g., a welding program with specified setpoints\/targets for current, voltage, and time), and<\/li>\n<\/ul>\n\n\n\n