1 Introduction

Our modern societies are currently undergoing a fundamental transformation from analog to digital processes effecting of all parts of our lives [1]. The Space Sector [2], obviously, is affected too and about to leap into a new eraFootnote 1 [3]. In fact, new companies have entered the space market and gained success using methods and products of a digitized world [4]. This, however, also affects high-tech products from robust hardware, their manufacture, and supply chains [5]. Consequently, the objective of the present paper is the discourse of this digital transformation while approaching the collaborative production of high-performance space components under the specific boundary conditions in European space sector. This includes typical space research funding, the resulting transnational collaboration based on geography return (Chapter 2), as well as the awakening awareness for the digital transformation in the space sector in terms of the digital agenda of the European Space Agency (ESA) (Chapter 3). On the other hand, there is the European Gaia-X initiative, which strives for domain-specific data spaces for Europe which obviously has interesting synergy potentials for space sector. Moreover, Gaia-X aims to interconnect existing data infrastructure based on federated services that ensure identity and trust based on European laws, enable compliance and sovereign data exchange to create a data economy based on European values. The latter in terms of so-called Advanced Smart Services (ASS) that create added value based on data (Chapter 4). A future service addressed in this paper concerns the digital fusion of engineering and manufacturing, which traditionally take place one after the other (Chapter 5). The focus is on a data integration scenario (DIZ) based on the boundary conditions presented in the first part. The DIZ includes, on the one hand, typical stakeholders from the space sector, while the cooperative merging, on the other hand, creates added value through early property identification and higher component security. In concrete terms, this is achieved by replacing nominal (material) properties with actual properties, while the design, manufacture, and testing of the hardware take place in iterations and each iteration affects the next. The intervention, in turn, is based on a plan-do-check-act/adjust principle as basis for data-based decision-making in, e.g., technical reviews. Either way, the current state of the prevailing “first-design-then-produce” method can, of course, be implemented unchanged (zero iteration), with the data being used for, e.g., verification purposes.

2 European space research

2.1 European space agency

The European Space Agency (ESA), formally established in 1975,Footnote 2 was founded to enable space collaborations reaching a critical size that clearly exceeds the possibilities of the individual members [6]. In 2021, ESA's budget was €6.49 billion [7], which is about 27.9% of NASA's budget [8]. The ESA budget is divided in domains (Table 1) [7].

Table 1 ESA budget by domain for 2021

In 2021, ESA initiated 123 activities in the technology support domain, while 52 activities could be completed [7]. The work plan budget for 2021/2022, in turn, includes 209 activities of which 94 put special emphasis on commercial off-the-shelf (COTS) and Digital Engineering [7]. To ensure the success of the commissioned development projects, ESA has significantly strengthened its competencies in the areas of digital engineering, artificial intelligence, and cyber security, while these areas being declared as emerging technology fields [7]. This is in line with ESA´s Automation and Artificial Intelligence Roadmap [9] that shall foster European growth in applied AI in alignment with ESA Technology Strategy to, e.g., increase efficiency and reduce cost for space programs. The roadmap [9] is part of ESA’s Agenda 2025 that strives to boost commercialisation for a green and digital Europe among the top actions for safe and secure data and communication infrastructure “in space, and from space” [10].

2.2 Geo-return

The European-wide approach is not only a goal, and in turn, it is a fundamental pillar in the financing of ESA called geographic return (geo-return) [2]. The geo-return policy targets that all member states receive a significant share of their Agency contributions (Table 2) in the form of industrial contracts [11].

Table 2 ESA budget returns in 2021 by funding source

An example application from the area of technology support in which geo-return is applied is set out in Table 3. The objective of this activity is to improve the advanced manufacturing processes [12] in terms of cost, quality, technological advancement, manufacturing time, and/or reducing the time to market [13]. This shall be achieved through the utilization of a digital twin (DT) concept that allows process data, acquired during advanced manufacturing of space hardware, to be analyzed [14].

Table 3 ESA example project from the field of digitization with applied geo-return

ESA’s DT concept relates to the development of data models for physical systems to accurately reproduce physical and performance characteristics of processes and products [14]. Hänel et al. provide a clear example of what this means in specific terms and how this can be implemented [15].

2.3 Cross-cutting initiatives

In addition to the clear assignment to the respective domains (Table 1), there have also been overarching funding initiatives at ESA established since 2012. These are called “cross-cutting initiatives (CCI)”, while each initiative is focused on a particular theme of interest for the future of the space industry [16]. The implementation bridges different programs, technical disciplines, and technology levels, encouraging external partnerships where appropriate [16]. This is to strengthen interdisciplinary approaches, exchange and coordination of R&D between all programs, broaden interactions and links between upstream and downstream, and move toward a leaner, highly responsive, diverse and proactive Space 4.0 organization [16]. This shall be achieved through the following objectives [16]:

  • adequately address the increasingly more frequent partnerships between the public and the private sectors,

  • to maximize programmatic synergies and use of assets—resources and competences—available,

  • to foster and drive cross-fertilization, including best use of lessons learned.

However, each CCI is focused on a particular theme of interest for the future of the space industry (Table 4) while reflecting ESA´s Agenda 2025 set out by Aschbacher [10].

Table 4 ESA’s current cross-cutting initiatives

3 ESA digital manufacturing

3.1 What is needed

ESA's drive toward digitization is already evident from the names of the initiatives (Table 4). Looking into, e.g., the Design-to-Produce CCI, it becomes clear that future space systems shall be fully integrated into modern economies, to serve new customers and integrate with diverse ground networks and smart devices [18]. This requires a transformation from a lengthy document centric traditional design, build and then test process toward a model centric analyze and build process more suitable to the new space environment [18]. Moreover, models and high-fidelity virtual environments shall be used to prototype, experiment and test options and concepts, means integrating new technologies with a faster pace.

3.2 Seamless data cycle

This should not be achieved independently; on the contrary, ESA aims to apply novel techniques from terrestrial design and manufacturing processes—including digitalisation, process automation, interoperability, and harnessing smart embedded sensors—to cut the schedule and cost of space missions [18]. This means to implement the digital transformation and Industry 4.0 [20] which is changing the manufacturing process in various ways. According to ESA does this include a single, seamless digital data cycle (SDC) (Fig. 1) to link key disciplines from design to production, automated inspections, augmented reality to guide integration and testing and embedded sensors giving an authoritative, ongoing overview of product status [21].

Fig. 1
figure 1

ESA’s seamless data cycle [21]

The SDC is covered by adopting a digital model and digital engineering for end-to-end development across the entire supply chain. The digital transformation of the entire supply chain shall enable continuous improvement of the design and product based on analysis of data from embedded sensors, covering on-ground and aboard, plus streamlined assembly, integration, and testing [18]. Moreover, this shall include the latest generation techniques for the shop floor application of such techniques, including augmented reality and automation and methods supporting execution of assembly, integration, and testing, to prevent anomalies and failures and reduce inefficiencies [18].

4 The Gaia-X initiative

4.1 Purpose of Gaia-X

The framework conditions set out in the previous chapters require a “common data space” as a foundation for the implementation of a future “space data economy” which is in line with the European strategy for data [22]. According to Franklin et al. [23], they require data spaces in a data integration concept that follows linked data design principles. Otto [24] notes in this context that data spaces do not require physical data integration, and on the contrary, they leave the data at the source and only make it accessible when needed. Gaia-X aims to achieve the desired data interoperability and collaboration of actors (Fig. 1) across the boundaries of individual data spaces [24], countries (Table 3), and/or companies [e.g., between large system integrators (LSI) [25] and small- and medium-sized enterprises (SMEs)] as illustrated in Fig. 2.

Fig. 2
figure 2

Schematic representation of an advanced manufacturing data space with reference to Table 3 under the assumption of controlled external data access (e.g., digital troubleshooting) or data re-use (e.g., machine learning) by a third party within the framework of the ESA general terms and conditions (GTCs) adapted from [24]

Gaia-X, initiated by France and Germany, seeks to create a proposal for the next generation of data infrastructure for Europe, while many ESA member states contributing to this initiative (Table 5Footnote 3).

Table 5 List of Gaia-X Hubs as contact points for interested parties with ESA member states high-lighted in bold

The architecture of Gaia-X is based on the principle of decentralization [26] taken into account typical forms of cooperation in space business (Fig. 2), although the illustration represents explicitly only a section of the ecosystem of relevant stakeholders. This shall be achieved via a multitude of individual platforms that all follow a common standard—the Gaia-X standard [24]. The Gaia-X standard supports the goals of interoperability of services, data portability, and data sovereignty [27] as articulated in the European data strategy [17], and addresses a requirement gap in the existing infrastructure models [24]. All in all, the present constellation combines a common political basis of the central actors (c.f. Table 2 and Table 5), support from the European Union [22], the current digitization efforts of the ESA (Chapter 3), and the opportunity on the basis of the ESA GTCs (which must be accepted to submit a fully compliant offer) that could declare data to an deliverable, which, in turn, creates an excellent starting point for data-driven use cases and digital business models of the future. The latter shall be discussed further based on an architectural consideration of Gaia-X and a central component of ESA´s Advanced Telescope for High-ENergy Astrophysics (ATHENA).

4.2 Layered architecture of GAIA-X

Essentially, the decentralized approach of Gaia-X is open to other market participants [e.g., from other digital engineering projects (c.f. chapter 2.1)] and their systems without forced data pooling. Hybrid cloud scenarios and distributed implementation (vertical and horizontal) enable this across data providers (interoperable) Fig. 3. A key aspect of Gaia-X is the use of sovereign identity procedures (Self Sovereign ID & Trust) [28] that shall clearly identify the data providers (Fig. 3, infrastructure ecosystem in red at the bottom) and data users (Fig. 3, data ecosystem in blue at the top) as trusted participants [29].

Fig. 3
figure 3

Gaia-X architecture and federated services [27]

The basis for assessing the compliance [30] of a participant is the Minimum Viable Set (MVS) of Policy Rules developed by the Gaia-X Policy Rules Committee and approved by the Board of Directors of the Gaia-X AISBL [31]. The approval process is currently being developed, but is going to be based on recognized standards and established conformity assessment tools [32]. Either way, upon successful completion of the validation process, verifiable credentials (vCs) representing the security levels of the service offering are issued and registered in the Gaia-X Federated Catalogue (Fig. 3) [31]. These vCs can be used to automatically indicate the level of compliance in, e.g., different federations [32]. Another key element of federated services concerns the sovereign exchange of data (Fig. 3). In fact, a controllable, sovereign, and traceable exchange of data across boundaries (Fig. 2) is essential for the establishment and success of a digital ecosystem. In practice, this means to be able to send data from an existing device (e.g., cyber-physical manufacturing system via an EDGE device [33]) or database (sector specific cloud; c.f. Fig. 2) to a trusted recipient in a certified data space (data ecosystem). This, however, includes that the data provider, which is a shareholder of the data space [34], retains control over data and conditions of its use [35]. The IDS trusted connector [36] (c.f. IDS reference architecture model 4.0 [37, 38]) offers the possibility for technical implementation enabling that data are stored in virtual containers that are only used according to the terms agreed by the parties involved. Moreover, there are the federated services (Fig. 3), a catalog [39] system for digital services addressing further assistance for sovereign data exchange [40] and compliance [30] considerations. However, the reference implementations for the federal services (Fig. 3) can be found and downloaded in the associated Gitlab (Fig. 4).Footnote 4

Fig. 4
figure 4

Gitlab Gaia-X Federation Services

These services include transparent and verifiable descriptions, e.g., in relation to data protection, data security, and compliance with technical standards and legal requirements, while being checked for compliance (e.g., GDPR, EU requirements, Cyber Security Act, and geolocation) and certified and accredited in terms of trustworthiness [37]. In addition, the Gaia-X Association has recently published a compliance and labeling framework. In fact, three basic compliance levels have been defined (Table 6)Footnote 5 which can be obtained by services (Figs. 3, 4, data ecosystem in blue at the top) based on different standards and expectations for data protection, transparency, security, portability, flexibility, and European control [41]. This framework ensures a minimum level of compliance for any service, helping to achieve the desired level of trust between entities and services in the marketplace [42]. In addition, governments, trade associations, industry associations, and agencies alike will be allowed to ultimately create their labels and establish specific rulebooks for each specific domain needs [41].

Table 6 Gaia-X compliance and labelling framework [41]

The International Data Spaces Association (IDSA) has defined a reference architecture and a global standard for creating and operating virtual data spaces [43] (Fig. 3). The IDS Architecture is based on commonly recognized data governance models [44] facilitating secure exchange and easy linkage of data within business ecosystems. The latter overcomes the, e.g., trilateral nature of cooperation toward a multi-stakeholder collaboration (Figs. 1, 2). This means, e.g., linking and use of data from production environments (Fig. 1) by value-added services to achieve a breakthrough for the broad implementation. These “Advanced Smart Services (ASS)”, being provided cloud based, are the heart of the arising future data economy (Fig. 3, data ecosystem in blue at the top) while addressing themes like artificial intelligence (AI), data analytics and automation (Table 4). This means, at this point, if implemented correctly, there will be future domain-specific data ecosystems (in analogy to, e.g., the app stores of mobile phone manufacturers) in which trustworthy actors offer data services (apps) which can be used, e.g., by data providers (Fig. 3). Such a scenario is further considered in a real use case.

5 Space domain implementation

5.1 Introduction

The COOPERANTSFootnote 6 (COllabOrative Processes and sERvices for AeroNauTics and Space) lighthouse project, funded by the Federal Ministry for Economic Affairs and Climate Action (BMWK), will accelerate the digitization of processes in the aeronautics and space industry. The goal of the German consortium is to develop more efficient, decentralized forms for future working methods and processes across the entire lifecycle of space or air vehicles. This will serve to increase the competitiveness of the aeronautics and space industry within Germany and the European Union. The project is embedded in the initiative of the German Federal Ministry of Economic Affairs and Climate Action (BMWK) to develop innovative and practical applications as well as data spaces in the Gaia-X digital ecosystem and addresses the application domains Industry 4.0 with particular emphasis on the needs of SME to enable data-driven business models. The architectural approach of COOPERANTS (Fig. 5) concretizes the abstract Gaia-X representation (Fig. 3) while approaching the vertical and/or horizontal data exchange based on specific use cases such as the ATHENA Space Flight Mission [45, 46]. In the case of the latter, collaborative engineering with a focus on the linkage of engineering and manufacture is examined in detail. This is to enable improved verification and simulation (c.f. Fig. 5, Smart Service Layer).

Fig. 5
figure 5

Cooperants layered architectural approach with illustration of the ATHENA Space Pilot adapted from https://dasclab.eu/de/

5.2 Athena space flight mission

5.2.1 Mission context and optical bench

The Advanced Telescope for High-Energy Astrophysics (ATHENA), illustrated in Fig. 6, will be an X-ray telescope designed to address the cosmic vision science theme of the hot and energetic universe [59]. In 2014, Athena was selected as the second large (L-class) mission [60] in ESA’s Cosmic Vision program [61]. One of the main components of the telescope is a metallic optical bench [46, 62] which is part of the mirror assembly module (MAM), as shown in Fig. 6. The advanced manufacture (c.f. chapter 1) of ATHENA’s metallic OB, in turn, is further approached from the perspective of ESA’s seamless data cycle (Fig. 1) using the layered architecture of Gaia-X (Figs. 3, 5).

Fig. 6
figure 6

Schematic illustration of the ATHENA telescope and the metallic optical bench part of the mirror assembly model (MAM)

5.2.2 Athenas OB as neutral business object

In the following, the optical bench (OB) of the ATHENA Telescope is considered as a piece of hardware that is created with the participation of several stakeholders (c.f. Fig. 2). Moreover, the development and manufacturing process of the OB is representatively abstracted and generally described to show the broad applicability of the targeted future data service (reference). Consequently, the ATHENA OB is further regarded as a neutral business object (Fig. 7). The latter, however, is initially a bilateral relationship between the agency (ESA) and the LSI (here Airbus DS). The technical basis of this relationship is set out on the customer side by, e.g., the Statement of Work (SoW) defining the requirements based on related system engineering. The LSI, on the other hand, uses this input to define the system requirements by creating a system requirement specification (SRS). The SRS is a refinement of the customer requirements, forming the basis for the definition of the initial system architecture after iteration and/or release.

Fig. 7
figure 7

Customer LSI business object flow

The system architecture is the basis for the system design definition, which depends on the equipment requirement specification, which, in turn, is derived from the system requirement specification. The detail design definition is done based on system design definition while depending on the Interface Control Documents (ICD) from the supplier equipment including electrical, mechanical, and functional ICD. Expert analysis is performed in parallel based on the system requirement specification, by bidirectional iteration with the system architecture and by examination of the system design according to its definition. The result, however, is an “as designed” object, which is further iterated covering the “design for manufacturing”.

Based on the “as-designed geometry”, a structural analysis is enabled by updated stress results, which can be compared with the results of the strength analysis. Either way, all calculations are based on the geometrical design and nominal mechanical properties of the selected material. The standard Q-ST-70-36C [60], in turn, requires, e.g., the consideration of the directional variation of an alloy as well as the residual stress distribution and the grain orientation. In that, it is [60] stated further that machining does not only alter the stress distribution, but it can also result in the exposure of a short transverse region on the surface of the finished part which is subjected to tension in service. Hence, the need is derived to integrate the determination of the actual geometry and the material properties into the business object workflow (Fig. 9) while expanding the correlation of strength analysis significantly. A central enabler for that is the cyber-physical production system (CPPS) [61] which is used to manipulate the raw material toward the “as designed geometry” while providing process data as “Production Parameter Log Data” during the manipulation with manufacturing processes. In addition, the actual geometry is determined via 3D scan “as measured” and, in combination with “production parameter log data”, a target/actual comparison is performed to create an "as manufactured" geometry, with the deviations determined by the target/actual comparison being quantified and taken further for a root cause analysis. The intermediate work piece in the “as manufactured” geometry is also linked to non-destructive testing to determine residual stresses using neutron radiation. It should be noted that this cycle also includes the NDT of the raw material to cover the determination of the influence of machining on the residual stress state in ref to. However, there is the focus on the feedback loop, which updates the strength results “as designed” through the “as manufactured” to verdict to continue manipulation or perform thermo-mechanical tailoring in near-net-shape condition. The feedback loop shall be considered in the following chapter (Chapter 6).

5.3 Advanced manufacturing of Athena’s OB

5.3.1 Digital workflow

The “as designed” is a result of the LSI business object flow (Fig. 8). The CAD service uses Catia as a 3D construction software while providing an “as designed” Step file as an exchange format. The “as designed” Step file is handed over to the CAM Service using TEBIS as path planning software to generate the NC Code in CLDATA format. The NC code describes the manipulation of the hardware with the CPPS which is operated by SINUMERIK 840D sl machine control. The process data, in turn, are generated and processed at the machine control level being classified as sampled high-frequency data. Examples are the change of axis positions and drive currents, acquired or measured with sampling rates less than 2 ms and provided as JSON filetype. The procedure from the machine to the JSON file is described in detail in [33, 63]. The TwinProCut service uses the TwinProCut software to, e.g., calculate the “as manufactured” geometry based on process data using validated models. In addition, the “as manufactured” geometry is additionally measured via 3D Scan providing a digital geometrical representation "as measured" STL file too. TwinProCut is an application-oriented implementation of model-based digital twin, which, e.g., describes the geometric condition of the hardware while allowing the calculation and visualization of the deviations between “as manufactured” and “as measured” geometry, e.g., induced by residual stresses. Moreover, in the present case of subtractive processing, TwinProCut further enables the characterization of the removed material in parallel to the manipulation. In fact, if looking at the potential directional variation of an alloy in ref. Q-ST-70-36C [64], the spatially discrete mapping of, e.g., the cutting force [15], is applied as a destructive material testing method providing volumetric information while machining. Either way, the information model of the software is set out in [65], while the model-based analytics-ready approach is described in detail in [15]. The digital workflow includes the location-discrete determination of residual stresses based on the non-destructive measurement of strain using neutron radiation [66]. Via a CAQ tool service, the non-destructively measured values, associated location coordinates, and derived information are provided in tabular form as CSV file while altogether being incorporated in the digital representation of the work piece using TwinProCut. The combination of mechanical characterization results, description of the achieved geometric precision, or the local quantification of the deviations, respectively, as well as the result of the residual stress determination serving as input for the execution of the “strength analysis result service”. This is done using the “as manufactured”/”as measured” geometry for the correlation of stress analysis results, while the results of the residual stress determination represent an, e.g., additional load case. Here, Nastran is used as FEM software for both the correlation of the stress analysis results as well as to evaluate the strength results. A central advantage of the presented data workflow is that the outlined information can be obtained by gradually manipulating the raw material toward the final geometry. Hence, thermo-mechanical tailoring can be performed while having an equidistant geometric offset to the target contour, which compensates for distortion and surface layer effects. The, e.g., heat treatment is described as a time–temperature curve and integrated into the digital representation as a CSV file where it is stored as the reason for the change between two material and geometrical states. The geometrical evaluation, again, is recorded as “as measured” and transferred to the CAM service as geometry deviation while geometrically enveloping the “as designed” geometry.

Fig. 8
figure 8

Large system integrator business object flow (BOF)

The digital flowchart is summarized in Table 6, where for each object, the software group, software, file type, and outputs are listed.

5.3.2 Deployment architecture

From an information technology perspective, the targeted scenario presents a challenge for data management. The data are highly heterogeneous with regard to its provenance, format, and scale. A deployment architecture for integration must address all dimensions. First, diverse provenance introduces requirements concerned with protection of intellectual property and data sovereignty. The multi-layered character of aeronautical supply chains requires partners to integrate their enterprise data sources into a network. To manage the access to a given data service, interested parties are supported by tools such as the Eclipse Dataspace Connector (EDC),Footnote 7 an open-source implementation of the IDS specification. A standard vocabulary for access rights, such as the Open Digital Rights Language [67], ensures interoperable exchange of data policies and can be parsed by connectors to restrict the access for unauthorized requests. Using these building blocks, an equipment supplier can participate in sovereign data exchange with a customer (Fig. 10) by iterating requests or passing operational data directly from manufacturing to the smart service layer to perform specific analysis of the manufacturing process (Fig. 5). However, there are no restrictions on a company’s internal architecture, since connectors can be used as backend adapters for enterprise systems to securely communicate outside the intranet. Using them as central gateways to a network (Fig. 11) yields the same access to a data space and provides a useful migration path for newcomers.

Given the presence of centrally deployed Gaia-X Federation Services (introduced in chapter 4.2), participants can also exchange data safely with previously unknown parties. Catalogs play a critical role in the discovery of and interaction with a third party’s data services. This deployment architecture is suitable to address the challenge of incoherent provenance of data in a distributed network. Second, the challenge of heterogeneous data formats in data spaces can be met by enhancing data with semantic context [68]. The described use case (Fig. 10) integrates data from edge-devices, digital solutions along the CAD-CAM-CAQ-chain, measurement data form the manufacturing process, and calculations data (Table 7) in different software systems and file types. Annotating the documents and the data they contain with an appropriate set of meta-data elements allows systems consuming data from the network to parse and act upon it without the need for human intervention. Given intersecting domains in a complex interaction scenario like this, semantic description must place focus on flexibility as well as interoperability. Requiring all industry- and lifecycle-specific ontologies to reference a top-level ontology as a common framework is a proven way to reliably integrate ontologies [69] while still remaining open to integrate new domains and partners. Strict application of semantic standards is suitable to address incoherent data formats. The third challenge of the use case (Fig. 10) is the heterogeneous scale of data and the necessary computing resources to handle them. All objects/information systems described in Table 7 (TwinProCut, CAD/CAM,…) require different processing systems. While some data flows may only occur sporadically, others stream large datasets continuously. The deployment architecture must consider this and seamlessly integrate resources on the edge or in a local data platform and with cloud services—of course while preserving sovereignty guaranteed by dataspace connectors. The EDC has taken this requirement into account by separating the contract negotiation mechanisms from those facilitating the data exchange once an agreement is reached [70]. The use-case architecture reflects all three challenges while implementing a hybrid (Fig. 11), with a dataspace that adheres to the principles of Gaia-X while remaining true to the principles of modern IT enterprise architectures. Either way, the design and realization of space programs is joint effort between various organizations on different level (c.f. Figure 7, 9). Hence, the resulting data are widely fragmented, technically but also contractually. Consequently, providing a legally secure and reliable contractual framework is a key enabling element for data ecosystems. The cooperants project underlying here focuses on the technical aspects the utilization of the mechanisms of new collaboration services to build additional and new services on top. However, in parallel to this technical work, the discussion of the needed evolution of the contractual framework is currently in progress. In fact, the legal aspects (from the governance perspective c.f. Fig. 5) of the advanced smart manufacturing service (Chapter 6) are considered further and in isolation based on this publication.

Table 7 Tabular summary of the digital flow chart with software group, software, file type, and outputs of each object

6 Advanced smart manufacturing service

The SDC (Fig. 1) presented by ESA was exemplified as BOF from the requirement and design phase until production using the Optical Bench of the ATHENA Telescope (Chapter 5). The latter started from the bilateral concept between the Agency and LSI (Fig. 7), about the detailing of the design process (Fig. 8) to the detailed presentation of the production (Fig. 9) including the realization of the desired digital model (c.f. Figs. 1, 8). Moreover, the BOF (Fig. 9) was described via a digital work flow (Fig. 10) whose objects (Table 7) contribute to the digital model (cf. Figs. 1, 10; Table 7). Additionally, a deployment architecture (c.f. Figs. 5, 11) based on the Gaia-X principles (Chapter 4) was presented. The result, however, is data made available by trusted data providers (Table 6; Fig. 11) in the domain-specific data space (Figs. 2, 5). The result, in turn, is an advanced smart manufacturing service (ASMS) that links engineering and production via a data analytics layer (Fig. 12). The data analytics layer, based on the digital flowchart (Fig. 10), enables plan-do-check-act/adjust cycles used for verification (digital twin as designed corresponds to as manufactured) offers the possibility to react to “as manufactured” analysis results by making an “as designed” adjustment. An example of an act/adjust scenario is the selection of a mechanical property adjustment by a tailor-made heat treatment versus a design adjustment (wall thickness increase), considering the cost and schedule implications (c.f. Fig. 12). It is essential that these decisions are made possible, while the component is being manufactured (in parallel), which differs significantly from serial practice [33]. Moreover, the ASMS is not limited to the usage in the space sector and can be used in the other domains based on the Gaia-X principles. In addition, the ASMS can be linked to other digital services that enable component-specific or cross-component analyses (c.f. Fig. 2). ASMS is contributing an essential in the overall effort of E2E digitalization. Quite advanced is at the moment is the digitalization for service (an example for this is the SkywiseFootnote 8 for Airbus commercial Aircraft). Efforts for digital engineering are ongoing at full swing in the different organization. ASMS is improving the connection with engineering and service with manufacturing information, for sure with a focus on manufacturing, but also improving product quality (with the loop into engineering), but also provide more data for service.

Fig. 9
figure 9

BOF along the I/F LSI for ATHENA digital model

Fig. 10
figure 10

Digital flowchart derived from the business object

Fig. 11
figure 11

Illustration of the ATHENA space flight mission Gaia-X deployment architecture

Fig. 12
figure 12

Illustration of the Gaia-X deployment architecture-based ASMS offering a plan-do-check-act/adjust procedure as used for the manufacture of the ATHENA OB

7 Conclusions

There is a broad consensus that developments in the space sector must be implemented more quickly and cheaply in the future. On the other hand, space applications are in most cases high technology whose development is accompanied by high safety requirements. Consequently, the quality of the development works is secured by standardized procedures, tests, and reviews, which must also be guaranteed with increasing pressure in terms of cost and time. As a result, ways must be found to make the existing processes more efficient instead of, e.g., costly qualifying new ones. Regarding the manufacture of space hardware, this can be achieved by parallelizing testing and production, especially if the production system describes the manufacture and testing automatically and in a machine-readable manner. This paper describes a possible approach how this can be achieved. It shows:

  • the future importance of digital production based on representative partner constellations in the space sector while linking ESA´s seamless data cycle approach to the Gaia-X principles and showing the overlap,

  • the transfer of the generic layered architecture approach of Gaia-X into a representative space pilot application transferring an on-premises scenario in a cloud-based application with online services,

  • the representation of the business object flow between the stakeholders using a main component of the ATHENA mission deriving the digital workflow in which the TwinProCut Service will be implemented as a hybrid architecture-based advanced smart service in the Gaia-X ecosystem,

  • the selection of a hybrid scenario as deployment architecture, while the data exchange is implemented via the Eclipse Dataspace Connector,

  • an application scenario, in which the digital production twin is used for verification, with digital requirements being used as a basis for comparison,

  • the digital production twin as a precise description of the as-built component that is used further for assembly, integration and testing,

  • a Gaia-X deployment architecture-based Advanced Smart Manufacturing Service offering a plan-do-check-act/adjust procedure for the manufacture of hardware developed based on the needs of the space sector that can easily be transferred to other domains.