domain: spi phys

text:
Erik H Baalbergen
email: erik.baalbergen@nlr.nl.

Jos Vankan
email: jos.vankan@nlr.nl.

Luca Boggero
email: luca.boggero@dlr.de.

Jasper H Bussemaker
email: jasper.bussemaker@dlr.de.

Thierry Lefèbvre
email: lefebvre@onera.fr.

Bastiaan Beijer
email: bastiaan.beijer@ke-works.com

Anne-Liza M R M Bruggeman

Massimo Mandorino
email: massimo.mandorino@unina.it.

M R M Bruggeman

Advancing Cross-Organizational Collaboration in Aircraft Development

Collaboration is a key enabler for the development of modern aircraft and its systems and components. Because of the highly complex and integrated nature of many aircraft systems, effective collaboration requires well-organized multi-disciplinary, multi-engineer and multiorganization development processes. These processes require data-driven and computersupported tools and methodologies. Collaboration may seem as simple as working together, thereby adopting standards and tools, and freely sharing data, information, and knowledge. However, in the development of complex systems such as aircraft, collaboration is not that straightforward. For example, aircraft engineers across disciplines and organizations commonly face challenges such as firewalls, data and tool heterogeneity, and intellectual property protection. In this paper, we review the collaboration challenges, we describe how the EU-funded research project AGILE 4.0 addresses these challenges, and we describe the application of, and experiences with, AGILE 4.0's collaboration-enabling technologies.

I. Introduction

Aircraft have grown over the past century from experimental and spectacular "flying machines" into large and complex but safe and reliable transportation vehicles. In line with this growth, the development of aircraft has evolved from a trial-and-error activity carried out by one or two persons in a work shed into a large collaborative effort that involves many engineers from multiple disciplines working at different organizations in various countries and employing digital tooling and dispersed huge data sets. This evolution is still going on, driven by the expectation that airlines will increasingly demand new aircraft to replace older, less fuel-efficient aircraft [START_REF] Airbus | Global Market Forcast 2021-2040[END_REF]. The aircraft industry and its supply chain must constantly innovate to respond to the growing demands from airlines for innovative, costefficient and high-performance aircraft in increasingly shorter time. Meanwhile, the industry has to deal with the challenges of global competition, fluctuations in the economy, evolving regulations, growing scarcity of nonrenewable energy sources and materials, and staff turnover.

Improving collaboration among original equipment manufacturers (OEMs), their suppliers, and other stakeholders is seen as an important enabler for facing some of the aforementioned challenges throughout the aircraft lifecycle. Efficient collaboration among multidisciplinary engineers, specialists and parties is a prerequisite in the design, construction, operation, and maintenance of modern and innovative aircraft [START_REF] Pardessus | Concurrent Engineering Development and Practices for Aircraft Design at Airbus[END_REF][START_REF] Moerland | Collaborative Architecture supporting the next generation of MDAO within the AGILE paradigm[END_REF]. Efficient multidisciplinary collaboration sounds trivial but is certainly not straightforward [START_REF] Bruneel | Investigating the factors that diminish the barriers to university-industry collaboration[END_REF][START_REF] Baalbergen | Integrated collaboration capabilities for competitive aircraft design[END_REF]. Collaboration is often impeded by national, organizational, human and technical barriers [START_REF] Baalbergen | Methods Supporting the Efficient Collaborative Design of Future Aircraft[END_REF]. National barriers include national laws and export regulations, such as the US-enforced International Traffic in Arms Regulations (ITAR) [START_REF]ITAR[END_REF], and may impose severe security-related restrictions on international collaborations. Organizational barriers may evolve from regulations or lack of trust among (possible) competitors and may include: mandatory working instructions, methods, and tooling for the "daily work"; physical and employment contractual measures and security constraints to protect resources and intellectual properties; and dealing with delegated responsibilities. Human barriers include diversities in culture and language, and heterogeneous ways of working. Technical barriers commonly result from national, organizational, and human barriers, and include incompatibility and heterogeneity among tooling, data, and information, and security measures such as fire walls and proxy servers.

Technical solutions that enable specialists to communicate and to exchange information exist since many decades, such as telephones, electronic mail, software for file exchanges and sharing, teleconference facilities, and distributed as well as remotely accessible central data sharing and tooling. Despite the technical solutions at hand, collaboration still faces many of the barriers mentioned above. Technical solutions addressing national laws and international regulations include labelling of data and filtering of, e.g., mail messages and data exchanges based on the labelling, but raise the additional technical challenge of how to actually use labelled data in engineering activities. Organizational barriers also cannot be avoided nor circumvented, but arrangements can be made through agreements and contracts to allow and enable engineers to collaborate across the organizational borders, thereby adopting collaboratively agreed ways of working and employing particular collaboration-enabling tools. The arrangements may indeed permit engineers to collaborate, but the engineers yet face the technical barriers resulting from protection measures taken by the organizations. Facing human and technical barriers generally involves dealing with a diversity of specialist languages and ways of working, establishing some form of interoperability among dispersed and heterogeneous tools and data, and retaining compliance with regulations, organization-specific constraints, and security rules. These challenges deserve attention in setting up cross-organizational collaborations.

The topic of collaboration across disciplines, organizations and countries has been addressed throughout the past decades in aerospace and engineering areas, e.g., [START_REF] Pardessus | Concurrent Engineering Development and Practices for Aircraft Design at Airbus[END_REF][START_REF] Durstewitz | Virtual collaboration environment for aircraft design[END_REF][START_REF] Kunz | Towards Collaboration in Engineering of Tomorrow -Building highly interactive Distributed Collaboration Platforms[END_REF][START_REF]About the Transglobal Secure Collaboration Program[END_REF]. Research and developments have resulted in several initiatives, standardization efforts, and partially also envisioned holistic solutions that support collaboration, in addition to contracts, agreements, and information technology (IT) facilities and developments. Examples are the Transglobal Secure Collaboration Program (TSCP) addressing the sharing and exchange of data in collaboration programs in aerospace and defense that span national jurisdictions [START_REF]About the Transglobal Secure Collaboration Program[END_REF], BoostAeroSpace [START_REF][END_REF] ("the Standard European Cloud providing secure collaboration services and business process integration throughout the extended value chain of the Aerospace and Defense industry") and GAIA-X [START_REF]Collaboration Platform For The International Development Of Aircraft And Space Vehicles[END_REF] ("the next generation of data infrastructure: an open, transparent and secure digital ecosystem, where data and services can be made available, collated and shared in an environment of trust"). These initiatives are much focused on juridical aspects of data exchanges or generic IT and cloud services. The study described in this paper aims to deal with collaboration aspects in several specific but representative application cases from the aeronautic supply chain.

Barriers that impede collaboration have been experienced and addressed in the context of several EU-funded aerospace research projects throughout the past decades, such as VIVACE 9 [13], CESAR 10 [14], CRESCENDO 11 [START_REF] Coleman | Innovations in collaborative modelling and simulation to deliver the Behavioural Digital Aircraft[END_REF], TOICA 12 [START_REF]TOICA Final Report -Publishable Summary[END_REF], and IDEaliSM 13 [START_REF] Berg | Application of an integrated and distributed multidisciplinary product development framework to a multi-tier aircraft design case[END_REF]. The EU-funded research project AGILE 14 (2015-2018) focused on setting up and executing collaborative, and potentially distributed, Multi-disciplinary Design Analysis and Optimization (MDAO) paradigms for aircraft design. A detailed overview of the collaboration challenges addressed in AGILE is included in [START_REF] Baalbergen | Methods Supporting the Efficient Collaborative Design of Future Aircraft[END_REF][START_REF] Baalbergen | Collaborative Engineering Technologies Enabling Multi-Partner Thermal Analysis In Early Design Stages Of Aircraft[END_REF]. The EU-funded research project AGILE 4.0 continues the research and work started in AGILE with an extended scope of the development process. AGILE focused mainly on the system design and optimization, i.e., the MDAO part of the development process. AGILE 4.0 has introduced additional upstream activities that belong to a typical Systems Engineering approach, such as stakeholders and needs identification, definition of technical requirements, and generation of system architectures. This extension in scope entails additional challenges affecting the collaborative system development. These challenges are addressed in section III.

In this paper, we give a short introduction to the AGILE 4.0 project. Next, we describe how the project responds to the collaboration challenges in terms of a collaboration framework that provides teams of potentially dispersed engineers with an integrated set of collaboration technologies. We finally describe the application of the framework and the experiences gained in several application cases. The AGILE 4.0 application cases use the implementation to establish collaboration among the involved partners from academia, research institutes, and aircraft OEMs and their suppliers.

II. Introduction to AGILE 4.0

As stated in the Introduction, the challenges of collaborative aircraft development are being addressed by the authors since several years and in the context of different projects. One of the projects, the EU-funded H2020 research project AGILE [START_REF]AGILE Aircraft 3rd Generation MDO for Innovative Collaboration of Heterogeneous Teams of Experts[END_REF] has introduced a novel paradigm and new technologies for cross-organizational collaborative MDAO processes, with the main result of accelerating the setup time of MDAO development systems and reducing them to more than 40%, with respect to conventional MDAO approaches. The scope of the AGILE project [START_REF]AGILE 4.0 Project Consortium, "AGILE 4.0 -Towards cyber-physical collaborative aircraft development[END_REF] was limited to the design and optimization of aircraft systems, for a given set of design requirements and for a given system architecture. The scope is being expanded in the follow-up EUfunded H2020 AGILE 4.0 project, where upstream Systems Engineering phases are included in the system development, in addition to the design and optimization activities. This extension in scope is represented in Fig. 1, which depicts the Systems Engineering Product Development process being set up in the AGILE 4.0 project [START_REF] Ciampa | Accelerating the Development of Complex Systems in Aeronautics via MBSE and MDAO: a Roadmap to Agility[END_REF]. The last two steps of this process represent the development activities investigated in the AGILE project and deal with the formulation and execution of MDAO processes for the design and optimization of aeronautical products. The other preceding steps of the Systems Engineering approach represent the extension in scope brought with AGILE 4.0. These steps include the definition of stakeholders, needs, and requirements [START_REF] Boggero | An MBSE Architectural Framework for the Agile Definition of System Stakeholders, Needs and Requirements[END_REF], the generation of multiple alternative system architecting to be designed and optimized [START_REF] Boggero | An MBSE Architectural Framework for the Agile Defintion of Complex System Architectures[END_REF], and the automatic verification of requirements [START_REF] Bruggeman | An MBSE-Based Requirement Verification Framework to support the MDAO Process[END_REF].

The ambition of AGILE 4.0 is to bring significant reductions in aircraft development costs and time-to-market through the implementation of an integrated cyber-physical aeronautical supply chain, from integrators and high-tier suppliers to SMEs, leading to innovative and more sustainable aircraft products. In particular, AGILE 4.0 targets the digital transformation of the main pillars of the aeronautical supply-chain, including design, production, certification, and maintenance. In order to achieve this target, fifteen partners from industry, research organizations and academia located in Europe, Canada, and Brazil are collaborating in the project. More information about the AGILE 4.0 project can be found in reference [START_REF] Ciampa | MBSE-MDAO agility in Aircraft Development: Achievements and Open Challenges from the AGILE4.0 Project[END_REF]. AGILE 4.0 builds upon the MDAO technologies developed in the AGILE project, but introduces new methodologies and implementations that leverage a Model-Based Systems Engineering (MBSE) approach. The MBSE approach supports the main activities of a Systems Engineering Product Development process through modelling. Therefore, it entails the modelling of development scenarios, stakeholders involved, needs, and requirements; the modelling of the aircraft architecture; the modelling of the requirement verification methods; and the modelling of the decision making and validation processes. The MBSE and MDAO technologies developed in AGILE 4.0 are implemented in an Operational Collaborative Environment (OCE). The OCE enables the collaborative development of complex aeronautical products through the support of modeling and a Systems Engineering approach along all phases. A schema of some of the MBSE and MDAO technologies as part of the OCE and used during all the steps of a Systems Engineering Product Development process is depicted in Fig. 2. The extensions in scope brought with AGILE 4.0 and the inclusion of Systems Engineering upstream activities has entailed new technical challenges affecting the collaboration between multiple partners. The main collaboration challenges in MBSE and MDAO encountered in AGILE 4.0 are presented in section III. The solutions provided through the new MBSE and MDAO technologies developed in the project are described in section IV. Integrated application of the solutions through the OCE in some example application cases in AGILE 4.0 are described in section V.

III. Collaboration Challenges in AGILE 4.0

This section describes the collaboration challenges in AGILE 4.0 emerging from four main functionalities addressed in the AGILE 4.0 project: integrated access to the OCE, collaborative systems engineering, tool integration in cross-organization collaborative workflows, and surrogate modelling.

A. Integrated Access to the OCE

An important challenge in AGILE 4.0 concerns the collaborative access to the OCE, thereby organizing and giving integrated access to expert knowledge, competences, technologies, data, and information that is dispersed across engineers and organizations. The main challenge is providing collaboration engineers with access to the OCE throughout the Systems Engineering development process while following an MBSE approach with the aim of performing (cross-organization) MDAO. This challenge includes giving access to different data standards for modelling information and mastering different expert knowledge and tools. Within the team of engineers, each engineer must have a dashboard through which he or she can fulfill his or her role within the development process. A graphical user interface must help each expert in giving access to the relevant competences, technologies, data, and information whilst hiding complexity traditionally involved with using each element separately. For example, data interfaces should be automated and the user should have an intuitive graphical user interface to steer the process in favor of programming.

B. Collaborative Systems Engineering

As stated in section II, one of the AGILE 4.0 project's ambitions is to extend the process for the development of complex systems, by including typical upstream Systems Engineering activities such as requirements definition and system architecting before deploying and operating collaborative MDAO processes. This extension entails the generation of new information collaboratively by different people who have different roles within the development team, e.g., systems engineers, requirement engineers and system architects. The elements of the design information are strongly interrelated. For example, system requirements are elicited according to stakeholder expectations, but requirements drive the architecting and design of the system [START_REF] Boggero | An MBSE Architectural Framework for the Agile Definition of System Stakeholders, Needs and Requirements[END_REF]. Therefore, the whole design information should be made available to the entire development team and should always be up-to-date, without inconsistencies and duplicates. Put in other words, one of the collaboration challenges being tackled in AGILE 4.0 is about the collection and sharing of design information through a Single Source of Truth (SSOT). In addition, an MBSE approach would enhance the collaboration among the experts of the development team. In fact, when the SSOT is in the form of models instead of documents, the design information can be more effectively shared among multiple people having different tasks in the development process. Therefore, a second significant ambition of the AGILE 4.0 project is the transitioning from a document-based to a model-based approach supporting the previously mentioned activities of a Systems Engineering process. However, this entails another challenge faced in the project, regarding the development of technologies that enable and facilitate the concurrent modelling of design information.

A relevant phase of the Systems Engineering development process is that of system architecting. This phase builds on use cases (i.e. how the system is going to be used by actors) and the accompanying functional architecture (i.e. system functions and their relations) defined in the online collaborative environment. System architectures are created by first modelling an architecture design space based on the Architecture Design Space Graph (ADSG) [START_REF] Bussemaker | System Architecture Design Space Exploration: An Approach to Modeling and Optimization[END_REF], and next using this model to generate architectures in an optimization context. The ADSG represents architectural elements (such as functions, components, decompositions, ports) and their connections, and is created and manipulated using a Graphical User Interface (GUI). Furthermore, to enable analysis and design of generated architectures using collaborative workflows, the elements in the ADSG should be linked to the MDAO workflow. The collaborative challenge lies in how to store and synchronize model data being worked on in a collaborative engineering project, how to make the GUI available to all project users with as little extra steps as possible, and how to connect the elements in the ADSG to other upstream (i.e., systems engineering) and downstream (i.e., MDAO) model artifacts.

C. Tool Integration in Cross-Organization Collaborative Workflows

As described, the central AGILE 4.0 collaborative environment facilitates the definition of collaborative MDAO studies in the form of collaborative workflows that involve the use of competences and resources of the collaborating but possibly organizationally and geographically dispersed teams of engineers. The next main challenge is to actually perform the collaborative MDAO studies by running the collaborative workflows. Experiences in past collaboration projects revealed that bringing all scattered competences, tools, resources, data and other information required for running such workflows at a central hub and having all engineers working at and operating their specialist tools at the central hub is generally not a practical option. Instead, the partners wishor are even forcedto perform their share of the collaborative study at their own premises, enabling them to protect, and control the usage of, their own resources, intellectual properties, and proprietary tools and data.

The specific and commonly IP-protected resources required for running a partner's share of the collaborative workflow are commonly available on the partner's premises and ICT infrastructure only. As a result, a collaborative MDAO workflow usually spans the ICT networks of the collaborating engineers, and hence crosses the borders of their organizations. This distributed set-up, however, raises several practical collaboration challenges, including connecting the variety of tools at data level; orchestrating the distributed tools according to the collaborative workflow thereby keeping the tool and resource owners in control and letting the data flow in a secure way among the tools despite their locations; and supporting successful execution of the collaborative workflow despite absent partners, failing networks, and overloaded services due to concurrent use of web-based services.

D. Surrogate Modelling

One drawback of collaborative and distributed MDAO workflows is their natural tendency to increase the time needed to achieve studies compared to fully integrated workflows. Within the AGILE project, several bottlenecks were identified. First, some partners -mainly industrial ones -may experience difficulty in sharing their competence because of IP and network accessibility issues. Integrating these competences in an optimization workflow was therefore not achievable. Secondly, as more accuracy is requested about the system performance, more costly competences should be integrated in the workflow but they would lead to intractable increase of running time in an optimization perspective. To overcome these challenges, surrogate modelling technology was applied and further developed in order to enable efficient parametric and optimization studies while protecting IP. This approach relied on a central broker for registration, storage, deployment, sharing, and usage of surrogate models (SMs).

In AGILE 4.0, with the complexification of the workflows that include more than a single design domain, the need of surrogate models and their efficient integration is getting even more crucial. Developments should facilitate the creation of surrogate models, their registration for use in the workflows, and their access to collaborative engineers. In addition, the technology should allow surrogate modelling competences to be provided by different partners. Eventually, increasing the robustness and flexibility of the processes would be an important step towards higher TRL levels and application in industry.

IV. Collaboration Solutions in AGILE 4.0

The AGILE 4.0 OCE provides an integrated suite of technologies that support the collaborative Systems Engineering and MDAO activities as described in section II. We present in this section the main technologies that support the collaboration aspects and respond to the challenges presented in section III, organized according to the main functionalities covered in the previous section.

A. Integrated Access to the OCE

Centralized and integrated access to the OCE is realized using KE-chain [START_REF] Ke-Works | Smart collaboration based on quality assurance based on your own project data[END_REF]. KE-chain features a web-based portal providing heterogeneous teams of experts a user-friendly collaborative platform for organizing and accessing design study data and technologies across the various steps defined in the Systems Engineering Product Development process and among the collaborating partners. KE-chain is the central hub for initiating collaborative MDAO studies and for defining MDAO workflows. KE-chain provides user-authenticated access to design study data, gives access to descriptions of available competences and resources provided by the collaborating partners, and enables integration of engineering services. KE-chain guides engineers through the various steps of the Systems Engineering development process through a dedicated and user-friendly GUI. KE-chain serves as broker for the other OCE technologies and data, thereby hiding as much implementation details as possible from the engineers so that they can focus on their engineering activities. A schematic overview of KE-chain as front end for the OCE is depicted in Fig. 3. KE-chain gives access to different data standards for the modeling information across the development process (such as SysML, CPACS, CMDOWS), manages expert knowledge and tools such as ADORE, MDAx, KADMOS, and supports the collaborative application of the MBSE methodology with the aim to perform MDAO. These tools are either embedded directly in the KE-chain front end or interact with the KE-chain data model through the Python library Pykechain [START_REF] Ke-Works | KE-chain Python SDK[END_REF]. OCE tools are integrated as engineering services which can be executed directly on the KE-chain server using Docker containers with dedicated Python environments. The collaborative definition and modelling of systems, stakeholders, needs, scenarios and requirements is performed mainly through the GUI of KE-chain. Different people having different roles in the development process (e.g. customers, requirement engineers) can collaboratively author and inspect the data regarding the first two steps of the AGILE 4.0 Systems Engineering process depicted in Fig. 1 using KE-chain. In addition, model validation scripts are integrated in the KE-chain back end in order to automatically identify possible errors, missing details and inconsistencies in the information produced by different members of the team.

The intermediate part of the AGILE 4.0 Systems Engineering Product Development process focuses on the generation of multiple alternatives of system architectures fulfilling all the functions demanded by the stakeholders through their needs. System architectures are therefore created by multiple people through the modelling of an architecture design space based on the ADSG. The GUI for editing the ADSG is implemented in a tool called ADORE [START_REF] Bussemaker | From System Architecting to System Design and Optimization: A Link Between MBSE and MDAO[END_REF]. Its graphical user interface is implemented using web technologies to ensure that the back end, i.e., the Python code implementing the ADSG, and the front end, i.e., the browser-based interactive GUI code for manipulating the ADSG, do not have to reside on the same computer. This enables the use of the tool and method without any need for local installation. Besides user convenience, this also serves the purposes of protecting IP rights and enables quicker release cycles.

ADORE has been deployed at a central webserver. Connection to the OCE implemented in KE-chain is established using the aforementioned Pykechain Python library. Independently from the main code of ADORE, a KEchain/ADORE adapter code base is created that implements functionality related to authentication and project-data management using the KE-chain platform. This enables users to authenticate themselves using the same credentials they use for accessing the OCE, and to store and load ADORE projects stored in some design study project in the OCE. This concept is depicted in Fig. 4. Additionally, this adapter code enables adding upstream systems engineering elements (e.g. functional requirements, boundary functions) to ADORE projects. Linking upstream elements to elements in the architecture design space model represents the main forward traceability link between upstream system engineering phases and the architecting phase.

Fig. 4 Notional implementation of KE-chain adapter code for enabling authentication and project-file management through KE-chain for a web-based GUI hosted on a central server: the GUI API uses an

Authenticator for managing logins and a Database for managing project files; the KE-chain adapter then specializes these two classes to communicate with the KE-chain server using pykechain.

In the last part of the AGILE 4.0 collaborative Systems Engineering approach, the generated system architectures are designed and optimized. Connecting architecture models created using ADORE to MDAO workflows that enable quantitative analysis of generated architectures is done by associating architecture elements (e.g. components and Quantities of Interest) to nodes in the central data schema (see next subsection). Establishing these links is done using the MultiLinQ tool [START_REF] Bussemaker | From System Architecting to System Design and Optimization: A Link Between MBSE and MDAO[END_REF]. Similar to ADORE, MultiLinQ is also implemented as a Python back end and a web-based front end. Its connection to the KE-chain collaborative environment is implemented in a similar fashion as well. This enables the user to seamlessly switch between the architecture design space model and associating architecture elements to the collaborative MDAO workflow. To do this, the KE-chain adapter for MultiLinQ implements functionality for retrieving ADORE models and for importing MDAO tool input/output definitions from either the project's tool repository or from already established collaborative workflows.

The MDAO workflow modeler MDAx [START_REF] Risueño | MDAx: Agile Generation of Collaborative MDAO Workflows for Complex Systems[END_REF] has been integrated in the OCE as an alternative solution to KADMOS, which is an open-source Python package that supports graph-based formulation of large collaborative MDAO studies [START_REF] Van Gent | Formulation and integration of MDAO systems for collaborative design: A graphbased methodological approach[END_REF]. MDAx offers a web-based GUI for creating and exploring collaborative MDAO workflows, which can then be exported to a variety of formats including CMDOWS (Common MDO Workflow Schema, an open-source, XML-based neutral language for workflow schemas [START_REF] Van Gent | CMDOWS: A proposed new standard to store and exchange MDO systems[END_REF]) and RCE workflows for execution. Similar to ADORE, its Python back end is connected to KE-chain using the KE-chain adapter principle. In addition to storing workflows and related CMDOWS files in the OCE, it also exposes available tool definitions from the tool repository in the OCE in the MDAx user interface: users can directly use the OCE tool repository to start creating workflows. Additionally, a restricted version of MDAx used for creating and editing tool definitions is deployed and connected to the OCE. This restricted version is called MDAx I/O and can still be used together with KADMOS, as it only relates to the tool repository and not to collaborative workflows.

The Requirements Verification Framework (RVF) has been implemented in KE-Chain to further support the collaborative systems engineering process [START_REF] Bruggeman | An MBSE-Based Requirement Verification Framework to support the MDAO Process[END_REF]. The RVF connects model-based requirements to the different engineering tools in the MDAO workflows and enables the automatic verification of requirements based on the MDAO results. Due to the model-based nature of the RVF and its integration in KE-chain, a clear trace from requirements to the MDAO workflow is generated. This allows the collaborating partners to inspect this trace and to better understand the development process. For example, stakeholders can inspect how their needs and requirements have been taken into account in the design process and how requirement compliance has been achieved. Furthermore, disciplinary experts can determine which requirements their engineering tools need to verify. The RVF is implemented as a Python-package. KE-chain servers as the GUI for the RVF and interacts directly with the Python code.

C. Tool Integration in Cross-Organization Collaborative Workflows

The AGILE 4.0 OCE provides and integrates several technologies that support the execution of cross-organization collaborative MDAO workflows generated as described in sections IV-A and IV-B, thereby facing the practical collaboration challenges identified in section III-C.

In support of connecting the variety of tools at data level, the AGILE 4.0 OCE is built around a common format for accomplishing data compatibility among engineering tools, the Common Parametric Aircraft Configuration Schema (CPACS) [START_REF] Nagel | Communication in aircraft design: Can we establish a common language?[END_REF]. CPACS is an open-source, XML-based common language for the exchange of product data. It allows storage of parametric definitions of aircraft geometries as well as analysis results of the individual design disciplines in a hierarchical structure that allows the consistent exchange of product data on multiple fidelity levels. CPACS is collaboratively developed by and used within the aircraft design community. A legacy engineering tool in AGILE 4.0 context is equipped with a wrapper that enables the tool to act on product data and produce analysis results in CPACS format. This "CPACS-ification" of engineering tools also facilitates specification (or "declaration") of tools in terms of their semantics at MDAO level. This specification enables the OCE technologies KADMOS and MDAx to select and automatically integrate partner-provided tools into collaborative workflows that support fulfilling the specified MDAO targets, as described in section IV-B above.

The AGILE 4.0 OCE provides several technologies to support orchestration of the tools distributed across the organizations involved and according to the collaborative workflow, while enabling the owners of the tools and resources to remain in control and letting the data flow in a secure way among the tools despite their locations. Tool orchestration at a single location is basically facilitated through the Remote Component Environment (RCE) [START_REF] Boden | RCE: an integration environment for engineering and science[END_REF].

RCE is an open-source environment for the integration of stand-alone tools into automated executable workflows. In the context of the AGILE project, RCE has been equipped with a facility to import workflow definitions in CMDOWS format, allowing automatic creation of local workflows, comprising the local CPACS-ified tools.

Local RCE workflows in AGILE 4.0 may be equipped with Brics building blocks that facilitate the composition and execution of workflows across organizational borders in a service-oriented architecture style, while complying with the applicable security constraints and dealing with the security measures of the collaborating partners [START_REF] Baalbergen | Streamlining cross-organisation product design in aeronautics[END_REF]. Brics comprises protocols and middleware that can easily be used stand-alone as well as integrated in any workflow management tool, such as RCE. The middleware orchestrates the executions and the data exchanges among the potentially dispersed workflows and services that constitute the collaborative workflow, thereby complying with the ICT security measures of the organizations involved and enabling the respective specialists to remain in full control of their own tools, data and other resources being accessed. To facilitate the secure exchange of data among organizations, the OCE provides a central SharePoint server in a neutral domain that is trusted by the partners.

Brics facilitates the use of "stub tools" in local workflows for calling remote tools and workflows; cf. Fig. 5. A stub tool is a small tool that provides the local workflow with the same interface of the remote tool or workflow in terms of accepting the same inputs and producing the same outputs. Internally, however, the stub tool calls a remote tool or workflow, thereby taking care of the triggering, the synchronization, and the data transfers involved. Brics also facilitates the creation of services and local workflows that may play the role of remote tool or workflow for a stub tool. As such, Brics provides the building blocks for accomplishing a service-oriented set-up for distributed workflows. A local workflow executing a tool stub temporarily becomes the client ("request a service"). The remote tool or workflow then becomes its server ("provide a service"). In the context of the AGILE project, RCE provides Brics plug-ins that enable stub tools to be included in workflows and that enable local workflows to be defined as servers. The basic role of Brics in the service-oriented set-up is depicted in Fig. 5. In this figure, the RCE Brics plug-in that represent the stub tool at the client site is labelled with 'C'. Label 'S' at the server site identifies the RCE Brics plug-in that handles calls from the stub tool and calls the rest of the server workflow. When the stub tool is activated, it employs the Brics protocol to accomplish the remote tool execution as if the remote tool was part of the local workflows. The numbered arrows in Fig. 5 represent the steps taken to accomplish the remote execution. First, the input files for the remote service are uploaded to the central data server in a neutral domain [START_REF] Airbus | Global Market Forcast 2021-2040[END_REF]. Next, the remote specialist gets notified (2), who in response starts the remote service (3). The service retrieves the input files from the data server (4), runs the engineering service [START_REF] Baalbergen | Integrated collaboration capabilities for competitive aircraft design[END_REF], and uploads the output files to the data server [START_REF] Baalbergen | Methods Supporting the Efficient Collaborative Design of Future Aircraft[END_REF]. Finally, the output files are downloaded to the client's side [START_REF]ITAR[END_REF], and the client workflow continues execution.

Fig. 5 depicts the simplest possible application of Brics in establishing a distributed workflow: calling a single remote tool, which has been embedded in a dedicated RCE workflow, from within a linear local workflow, with a single input file. Brics however facilitates the construction of more complex situations and has provision to avoid repeated notifications of remote specialists in case of repetitive requests for the same remote service, such as in distributed parameter studies and optimization studies. Brics also provides means for creating automated services in trusted settings, thereby eliminating the need for explicit triggering of remote specialists.

To enable successful execution of the collaborative workflow despite unresponsive partners, failing networks, and overloaded services, the AGILE 4.0 OCE provides the Brics Adapter Service (BAS), a generic server that may relay remote calls. The BAS enables collaborative workflows to be more dynamic in the sense that the identification of a remote service, which usually is hard-coded through the RCE Brics plug-ins in an RCE workflow, can be determined at run-time, based on the input data. From an RCE workflow's perspective, the BAS can be addressed as a remote service via the available RCE Brics plug-ins, but acts as an intermediary agent (a "sub server") for one or more other remote services. The latter services are referred to as actual remote service(s). The BAS handles requests automatically, without mail notifications nor human intervention. The BAS propagates the remote service request to an actual remote service determined from the input, thereby forwarding the provided input. The BAS can do the propagation either following the Brics protocol or some other protocol. The results of the actual remote service execution are propagated back to the caller of the BAS, as if the BAS has executed the remote service.

As an example, a specific instance of BAS has been used as one of the key links in the chain of executing WhatsOpt surrogate models from within RCE workflows, as described in section IV-D below. WhatsOpt does not fully support neither the CPACS interface nor the default AGILE execution method provided by RCE. As such, WhatsOpt models cannot be integrated into RCE workflows out-of-the-box, without modifying either RCE or the WhatsOpt service. With the BAS in the loop, however, calls to WhatsOpt surrogate models initiated from within RCE workflows and addressing 'bas' as remote service, are propagated to the WhatsOpt service at ONERA, and results are passed back.

D. Surrogate Modelling

The surrogate model technologies developed to tackle collaborative challenges identified in section III.D comprise a surrogate model generator, a surrogate model repository and surrogate modelling competences. The Surrogate Model Generator (SMG) is a broker that facilitates the creation of surrogate models, the coordination and registration of this process and related data, and the connection of the actors involved in collaborative MDAO studies. The Surrogate Model Repository (SMR) eases the sharing and usage of surrogate models within collaborative MDAO studies [START_REF] Baalbergen | Methods Supporting the Efficient Collaborative Design of Future Aircraft[END_REF]. The surrogate modelling competences allow collaborating engineers to efficiently replace design competences or subparts of the MDAO workflows.

A key enhancement of AGILE 4.0 is the ability to smoothly connect SMR to different providers of surrogate modelling competences in a transparent way from the end-user perspective. As an example, ONERA's surrogate modelling competences relies on the SMT Toolbox [START_REF] Bouhlel | A Python surrogate modeling framework with derivatives[END_REF] and are made accessible "as a service" to SMR through WhatsOpt [START_REF] Lafage | WhatsOpt: a web application for multidisciplinary design analysis and optimization[END_REF], a web application supporting MDAO collaborative activities.

In order to achieve this new capability, SMR has been extended to facilitate the registration of WhatsOpt surrogate models so they can be executed directly via the SMR user interface as well as indirectly from within RCE workflows utilizing SMR model. The registration of the WhatsOpt surrogate model at SMR is possible from WhatsOpt, making a surrogate model created using WhatsOpt to be available via the SMR as well. The metadata of the surrogate model is provided using a JavaScript Object Notation (JSON) format file including the inputs and outputs information as well as the associated WhatsOpt identifier. A WhatsOpt surrogate model registered with SMR can be selected via SMR (and hence KE-chain) as a competence for use in a study and includes wrappers to facilitate CPACS compliancy. The information is stored in a CMDOWS file and can be imported in KE-chain, thus considered as any design competence in the workflow creation.

When the resulting workflow is imported in the RCE execution platform, the process to execute the WhatsOpt surrogate model requires a remote call by the RCE workflow via the available/regular RCE Brics plug-in for accomplishing remote calls. The remote call is achieved through the BAS, which is described in section IV-C. A specific BAS instance provides WhatsOpt surrogate model calculations "as a service" and runs as a separate service next to SMR. It will recognize the identified WhatsOpt model and propagates execution to SMR. Based on the metadata registered with the WhatsOpt surrogate model, SMR translates the CPACS input file into JSON format used by the WhatsOpt server, calls the WhatsOpt API to delegate the actual execution of the model to the WhatsOpt server, translates the received JSON-formatted output into a CPACS output file, which is subsequently relayed by the BAS instance to the RCE workflow as result from the remote call. As shown on Fig. 6, the WhatsOpt RSM can be accessed through different components on the OCE. This smooth connection of SMR to different surrogate modelling competences provider facilitates the registration of surrogate models from different sources to be used in the workflows.

V. Application of Collaboration Solutions in AGILE 4.0

The AGILE 4.0 project addresses seven application cases (ACs) as depicted in Fig. 7. The application cases are validated by the industrial partners of the project consortium, and focus on different stages of the aircraft life-cycle, including production, certification and upgrade, thereby using the AGILE 4.0 OCE. A brief description of the seven application cases is provided below.

Fig. 7 AGILE 4.0 Application Cases developed through the collaboration solutions addressed in the paper.

A 90-passenger regional aircraft is taken as reference for two application cases focusing on the Production phase of the development life-cycle. One case (AC1) addresses the optimization of trailing edge flaps while taking manufacturing aspects into account. The other case (AC2) models and analyzes the production of horizontal tail planes by different industrial supply chains.

Three application cases focus on Certification. The main objective of these cases is to address certification aspects during the design process. Conventional and innovative architectures of propulsion and on-board systems are investigated. In particular, one case (AC3) aims at identifying and evaluating multiple system architectures driven by safety constraints. Another case (AC4) focuses on the continuous airworthiness, which mainly defines the maintenance process and aircraft maintainability. Both these cases are based on a 19-passenger regional aircraft. The third case (AC5) addresses part of the certification process of systems and airframe (e.g. electromagnetic compatibility) of Unmanned Aerial Vehicles (UAVs)

The last two application cases address Upgrade aspects. The first case (AC6) deals with retrofitting an existing 90-passenger regional jet aircraft, by re-designing and re-integrating novel and improved versions of engines and onboard system architectures. The second case (AC7) tackles the development of a business-jet family composed by three 8-passenger aircraft with different cabin length and design range.

The subsequent subsections describe three application cases in more detail, including the collaboration challenges addressed, the applied AGILE 4.0 collaboration solutions, the experiences gained on how AGILE 4.0 solves the specific collaboration challenges, and any remaining collaboration challenges and issues.

A. Example Application Case: Collaborative Flap Design Optimization for Minimal Weight and Manufacturing Cost

The application Case 'collaborative flap design optimization for minimal weight and manufacturing cost' (AC1) focuses on the design and optimization of the inboard flap of a regional aircraft. Two flap configurations, as shown in Fig. 8, are compared: the advanced kinematics flap and the dropped hinge flap. The trade-off focuses on the flap weight versus manufacturing cost. The advanced kinematics flap is characterized by a decoupled rotation and translation. Therefore, the expectation is that this flap is more efficient and therefore smaller than the dropped hinge flap. However, the advanced kinematics flap is more complex and therefore, the manufacturing costs are expected to be higher than for the dropped hinge flap. Four AGILE 4.0 partners are collaborating in this AC, as shown in Fig. 9. Each partner provides different analysis tools necessary to enable the specified trade-off. GKN Fokker provides two analysis tools: the Multidisciplinary Modeler (MDM) [START_REF] Van Den Berg | A multidisciplinary modeling system for structural design applied to aircraft moveables[END_REF] and the Cost Analysis Tool for Manufacturing of Aircraft Components (CATMAC) [START_REF] Van Der Laan | An open source part cost estimation tool for MDO purposes[END_REF]. MDM is a Knowledge Based Engineering (KBE) tool that generates the geometric model of the flap. The MDM has a module called CAD2FEM that generates the FEM model of the flap. CATMAC calculates the manufacturing and assembly costs of the flap. TU Delft provides two analysis tools: Proteus [ADD SOURCE], which uses the FEM model from the MDM to size the composite skin of the flap, and the Landing Performance Tool, which calculates the landing distance of the aircraft. NLR provides the AMLoad [START_REF] Rajpal | Including Aeroelastic Tailoring in the Conceptual Design Process of a Composite Strut-Braced Wing[END_REF] tool, which calculates the loads on the flap for different load cases. CFS Engineering from Lausanne, Switzerland, provides one analysis tool, the Navier-Stokes Multi Block (NSMB) CFD solver [START_REF] Hoarau | Recent Developments of the Navier Stokes Multi Block (NSMB) CFD Solver[END_REF], which calculates the aerodynamic performance of the flap. Several collaboration challenges have been identified within AC1. The biggest challenges are related to the tool integration as described in Section III-C. As explained in Section IV-C, all tools within the AGILE 4.0 workflows need to be "CPACS-ified", meaning that they use CPACS files as input and output. Within the workflow of AC1, the tool Proteus needs a detailed FEM model, which is generated by the tool MDM. However, it is not possible to add this FEM model to a CPACS file. Therefore, multiple files need to be transferred between the MDM and Proteus (both the CPACS file as well as the FEM model files). This challenge has been overcome by extending the Brics functionalities in RCE. Several functionalities have been developed that enable the transfer of multiple files between different servers, allowing high-fidelity tool data -for which CPACS was not sufficient -to be communicated between Proteus and the MDM.

A second challenge experienced within AC1 is related to the consistency of the CPACS input and output files of the different engineering tools. To enable the automatic MDAO workflow formulation, all tools need to have the correct input and output elements as defined in CPACS, such that the correct data is transferred between the different engineering tools. The structure (meaning the type and number of elements) of these files cannot change during MDAO workflow execution. This means that each time the CPACS files changes (e.g. a flap rib is added or removed) all files need to be updated and the workflow needs to be reformulated. This challenge, already identified during the previous AGILE project [START_REF] Van Gent | A Critical Look at Design Automation Solutions for Collaborative MDO in the AGILE Paradigm[END_REF], has partially been solved within AGILE 4.0 using the MDAx I/O editor as explained in Section IV-B. The GUI of the MDAx I/O editor makes it easier to update the CPACS files and keep all CPACS I/O files consistent. This saves a lot of time compared to the manual manipulation of CPACS files that was required before.

Finally, a third collaboration challenge experienced within AC1 related to the NSMB tool. This tool requires some manual steps to run and has a relative long execution time compared to the other AC1 engineering tools. Therefore, it is difficult to integrate the tool in a collaborative workflow as already indicated in Section III-D. This challenge will be solved by generating a surrogate model of the tool. The surrogate model is currently under development using the AGILE 4.0 tools as described in Section IV-D. Integrating the surrogate model in the MDAO workflow will significantly reduce the execution time of the workflow and will make the workflow fully automated and therefore easier to run.

Overall, the collaboration solutions as described in the previous section have made the collaboration within AC1 easier. Due to KE-chain, all partners could access and update the relevant data, while the data is stored in one place. Furthermore, KE-chain, ADORE and the RVF together enabled the inspection of the relations between the different systems engineering elements. Starting from the stakeholders, needs and requirements, through the system architecting and MDAO workflow formulation, to the automatic verification of the requirements. This increased the common understanding of the application case between the partners involved.

Even though several collaboration challenges have been solved, there are still some challenges left within AC1. One of the challenges involves the resilient execution of the workflow. In the case that one of the partners servers fails or gets disconnected, for example when it is accidently restarted, the engineering tool on that server cannot simply be restarted as it has lost track of the number of iterations. In this case, the entire workflow needs to be restarted which can be very inconvenient. This inconvenience is being solved in AGILE 4.0 by improving the Brics functionalities, enabling a remote service to continue a previously interrupted series of iterations.

Another collaboration challenge that arises within AC1 is the installation of the extra tools, such as Brics and RCE, at the partner's servers to enable the execution of the cross-organizational collaborative workflows. This may pose challenges especially for industrial partners who have very strict rules on software installation and security, and usually requires convincing IT departments.

B. Example Application Case: Collaborative Airframe Upgrade Design

The application case 'collaborative airframe upgrade design' (AC6) is focused on a regional-jet 90-passenger aircraft with a design range of 1890 nm. The analysis concerns two retrofitting solutions which can be applied to the reference system. The retrofitting packages considered are: (i) Engine upgrade: High Bypass Ratio (BPR) geared turbofan engines will replace the conventional ones, resulting in fuel consumption, maintenance, noise and air emission improvement. The engine to be installed are designed within the AGILE 4.0 project, their architecture is like Pratt & Whitney PW1000G series engines and is characterized by a BPR between 9 and 15. (ii) On-Board System (OBS) architecture electrification: three different progressive systems electrifications are considered, obtained through hydraulic and pneumatic system removal. More electric aircraft (MEA) and all electric aircraft (AEA) configuration can bring to weight, fuel consumption and maintenance upgrades. Fig. 10 represents the whole system and highlights the two components targeted by the retrofitting activities. Designing an aircraft upgrade is not a simple activity. The replacement of a single component involves different phenomena and actors. For instance, it is fundamental to analyze the impact on both performance and cost of such an operation. Performance depends on aerodynamic, structural, and propulsive characteristics of the new solution. Costs are affected by engine, system or aircraft manufacturers, certification authorities, governments, passengers, and airliners. As a result, a wide range of disciplines and stakeholders must be considered to obtain a coherent and realistic solution. This leads to several challenges that must be faced by designer. The most significant ones are: (i) The huge number of disciplines involved can raise difficulties related to management and schematization of the MDAO workflow required for the analysis. (ii) Each discipline must be executed sequentially with a different tool. The connection of input and output of all the competences could be challenging. (iii) The high number of tools involved during the analysis requires the support of different specialists. Each of them will provide his own competences which can be limited by intellectual property restrictions. (iv) The huge number of stakeholders and scenarios considered requires an appropriate methodology to account for all actors' needs during the design; in addition, once the final solution has been defined, a methodology to verify if the requirements are satisfied is needed. (v) High fidelity computations are essential to reach accurate and realistic solutions for each discipline considered, unfortunately their exploitation will result in a significant increase in computational time. (vi) Different retrofitting solutions can be achieved; the best solution will not necessarily be unique. Trade-off analyses should be performed to understand which solution is more suitable to the scenario and stakeholders needs considered. These challenges make a collaborationenabling technology essential to perform such a complex design activity. The remainder of this subsection explains how the OCE has contributed to facing the challenges, showing the benefits of the collaboration solutions illustrated in section IV.

KE-chain, KADMOS, ADORE. KE-chain offers the possibility to schematize and manage all the Systems Engineering and MDAO activities. Thanks to this service, it has been possible to have a clear overview of all the stakeholders involved in the scenario and the needs arising from their inclusion in the design process. Fig. 11 shows an excerpt of this schematization. From an analogous schema, each need can then be converted to a problem role, such as an objective, a design variable, or a constraint using the RVF. In addition, each problem role will be linked to a specific discipline. It is easy to imagine how the management of the connection between all these items require an adequate system engineering platform. Considering the different retrofitting solutions, which can be carry out separately or in combination with each other, a schematization of the achievable platform solutions helped the designer to understand which components and disciplines are required to analyze each solution. For instance, an electrification of the aircraft OBS will lead to the removal of pneumatic and hydraulic systems and to the installation of a bleedless engine. This means that some components and some sources of fuel consumption have not to be included in the analysis. This purpose is satisfied by ADORE, which makes it possible to generate several systems architectures, thereby defining the main differences among them. Subsequently, KADMOS has been exploited to define all the available competences in the form of tools. Once the required input and the output of each discipline are indicated, an XDSM of the MDAO workflow is automatically generated by using the problem roles previously defined. The AC6 schema which illustrates all the disciplines involved in the design is showed in Fig. 12. SMR. High fidelity results are reached through the execution of this workflow. The definition of two surrogate models allowed to reduce from hours to seconds the execution time of these tools. A response surface model from CFD computations has been obtained to estimate the aircraft drag in cruise condition, also accounting for the new installed engine geometry. The second surrogate model is exploited to size the wing structure according to the aircraft masses and loads. Both these surrogate models allow to better estimate the performance and costs related to the retrofitted aircraft, which are the main objectives of the analysis.

C. Example Application Case: Collaborative Family Concept Design

The application case 'collaborative family concept design' (AC7) deals with the design of a business jet family that consists of three 8-passenger business jets with various design ranges and cabin lengths [START_REF] Bussemaker | Collaborative Design of a Business Jet Family Using the AGILE 4.0 MBSE Environment[END_REF]. The three business jets are designed using an Overall Aircraft Design (OAD) tool in combination with several higher-fidelity analysis tools. Then, family-level non-recurring and operating costs are calculated, which form the basis of the trade-off: increasing the number of shared components may reduce non-recurring costs (i.e. save money for the manufacturer), but however may also increase operating costs due to the design of a less efficient aircraft. The optimizer has the choice to share wings, engines, empennage (vertical and horizontal tailplanes), landing gear, and/or on-board system. In addition, for each aircraft, three wing design variables are available: wing sweep, wing thickness-to-chord ratio (t/c), and the rear-spar location as percentage of chord. These design variables together with categorical design variables for selecting which components to share between aircraft make up a hierarchical design problem [START_REF] Bussemaker | System Architecture Design Space Exploration: An Approach to Modeling and Optimization[END_REF]: for some values of the sharing-variables, some of the wing design variables might be inactive.

From a collaborative engineering viewpoint, this application case is challenging as it involves coupling many disciplinary tools, multiple aircraft being designed at the same time, and hierarchical design variables. The collaborative MDAO workflow consists of two levels: a family-level and an aircraft-level workflow. The aircraftlevel workflow sizes one aircraft at a time, optionally with shared components, whereas the family-level workflow connects the aircraft-level workflows and calculates family-level cost metrics. The family-level workflow starts by initializing the three business jets using the empirical OAD tool. Next, the aircraft design MDAO is executed until convergence, after which the aircraft-level costs are calculated. Finally, family-level metrics are calculated. The aircraft-level workflow starts by initializing the respective aircraft from its previous design and with components shared according to the sharing design variables. Next, the aircraft-level MDAO is executed where first several highfidelity tools are executed in parallel, whose results are then merged together before resizing the aircraft using the OAD tool to ensure that the aircraft design stays consistent. The family-level and aircraft-level workflow models are shown in Fig. 13 and Fig. 14, respectively. The coupled high-fidelity disciplines include on-board systems design using the ASTRID tool for aircraft on-board systems sizing and trade-off analysis in initial design, a tool for tailplane sizing and maximum lift estimation, the Proteus tool for wing-mass estimation, and the AMC tool for mission simulation. The tools are provided by different partners. Wing-mass estimation involves optimizing the composite wing structure, taking aeroelastic stability, strength, and buckling constraints into account. One such wing optimization takes about an hour. Therefore, it was not feasible to directly include this tool in the workflow. A surrogate modelling approach is used instead. A DOE was generated varying several wing parameters, the fuselage length and the aircraft MTOW. Together with results from the OAD tool, a multi-fidelity Kriging model was trained and included in the workflow. The workflow uses Brics for remote execution of the ASTRID and the tailplane sizing and maximum lift estimation tools. The remote cost estimation tool is executed using Brics as well. To prepare the AC7 workflow for optimization, however, the execution time of one family design had to be reduced. To keep the execution time under one hour, it was decided to replace the ASTRID and tailplane sizing and maximum lift estimation tools by surrogate models as well. For the latter tools an approach similar to the one applied to wing mass estimation has been applied. For the ASTRID tool, however, IP rights constraints are applicable, and therefore it is not possible to create a surrogate model locally. Instead, the SMR service is used to call a surrogate model residing at the partner's computer.

Both the family-level and the aircraft-level workflows are modelled using MDAx and implemented in RCE. The RCE workflows are created directly from MDAx export, but require some modifications before they are actually executable: disciplines need to be replaced either with the appropriate script(s) and tool(s) or by a Brics call; scripts must be added to convert between family-level and aircraft-level CPACS files; and converger, output writer, and Brics settings must be checked and corrected. Treating the family-level and aircraft-level CPACS files differently enables using one RCE workflow to design each of the three aircraft. This approach, however, also introduces several additional challenges: the CPACS file needs to be correctly filtered before being sent to the aircraft-level workflow, and defining tool I/O and creating MDAx and RCE workflows from it is not straightforward.

As far as hierarchical design variables are concerned: this is a common situation in architecture optimization problems [START_REF] Bussemaker | Effectiveness of Surrogate-Based Optimization Algorithms for System Architecture Optimization[END_REF] and is therefore solved by using ADORE to execute the optimization problem. The architecture design space model is constructed such that wing design variables are associated to the wing component. The decision to use a common wing or not then automatically leads to the deactivation of the wing design variables if a common wing is chosen. Once the DOE or optimization algorithm starts to generate design vectors to be analyzed, ADORE takes care of converting the design vectors to a physical architecture model that can be evaluated. As architectures are evaluated using the MDAO workflow in RCE, a bridge needs to be established; this is done using MultiLinQ which maps an architecture to a CPACS file and back, using rules defined using its GUI. Communication between MultiLinQ and the workflow in RCE is established using Brics; a Brics Python adapter sends the file to the workflow and waits for it to send back a response. Fig. 15 shows this in a sequence diagram. Experience gained from the AC7 workflow shows that Brics works well to work in the context of IP-rights constraints and in general for remote or cross-environment (Python to RCE) data communication. Compared to the total execution time of the workflow, Brics adds a reasonable amount of time: an estimated 1 minute per hour. The Brics technology is flexible and can be used with more integration environments and neutral data servers than what is used in AGILE 4.0. Applying Brics in RCE workflows using the RCE Brics plug-ins is fairly simple. Using the Brics technology for the construction of collaborative workflows with more complicated connections among the participating partners is possible but requires extra effort to call Brics from custom scripts, to configure Brics properly, and to test the setup. For example, to start the aircraft-level workflow only once, and to enable it to be called three times from the family-level workflow at the same time, is not possible using the RCE Brics plug-ins but requires custom scripts.

Creating surrogate models is challenging as there are many decisions to be taken that influence the quality of the model, such as, for example, choosing the type of model, hyperparameters, and selecting the DOE points. In these aspects the collaborative engineering environment cannot assist. The SMR turned out to be a useful tool for managing remotely available surrogate model thereby meeting IP-rights.

The family design aspect of AC7 also made for a good test of the CPACS data standard. In most projects and application cases within AGILE 4.0, only one aircraft is designed at a time. Therefore, in the past whenever a CPACS interface was added to a tool, it would only be able to handle a CPACS file with one aircraft in it. Therefore, the aircraft-level workflow, where the actual empirical and physics-based aircraft design and analysis takes place, the CPACS file containing the family is filtered to only contain the one aircraft currently being designed. For this reason, several tool-specific trees were created with their own respective identifiers for filtering, something which is not part of the CPACS standard. On the family-level, MDAx is well-suited to create RCE workflows that implement such filtering. However, to achieve this several custom scripts were needed to automatically modify tool I/O definitions for the three aircraft. Adding such modelling features to the MDAx GUI would be a valuable addition.

Using ADORE together with MultiLinQ to drive the optimization loop works well, especially when applying newly developed optimization algorithms implemented in Python. Using MultiLinQ to define the logic for mapping a physical architecture to a CPACS file, however, takes quite a lot of debugging and it remains to be seen whether this approach is flexible enough to cover all application cases. Additionally, it is not possible to start an ADORE optimization without having to install ADORE and MultiLinQ locally. In the AGILE 4.0 project this will be solved by letting the tool developers execute the tools and connecting through Brics. In the future, however, it should be possible to start an optimization without any such interaction, preferably controlled through a web GUI. Finally, it is not yet possible to give RCE control over the optimization loop and integrate ADORE and MultiLinQ directly in the RCE workflow.

VI. Conclusions

In this paper, we address the collaboration challenges faced by aerospace engineers across disciplines and organizations in the collaborative development of the next-generation aircraft and its systems and components in the context of the EU-funded AGILE 4.0 research project. We describe several collaboration technologies made available through the integrated framework (OCE), which enables the collaborating engineers to face these challenges. We finally describe the application of the technologies as well as the experiences gained in several application case studies. The collaboration technologies are already actively applied in other R&D projects that are operating in the same field of collaborative aeronautic design on complementary application cases, as for example in the EU H2020 project IMOTHEP [START_REF] Novelli | IMOTHEP: towards hybrid propulsion for commercial aviation: Project Overview[END_REF].

Several collaborative systems engineering technologies are implemented in the AGILE 4.0 project. Requirements management is implemented directly in the KE-chain platform using the RVF. Architecture modelling is implemented in the ADORE tool. Logic for linking generated architectures to MDAO (i.e. CPACS) can be defined using MultiLinQ. Finally, collaborative MDAO workflows can be modelled using MDAx and KADMOS. Integrated access to and usage of these tools is facilitated by KE-chain, which acts as central hub for initiating collaborative MDAO studies and definition of MDAO workflows. Execution of collaborative MDAO workflow, which potentially span the ICT networks of the collaborating organizations, is facilitated through CPACS-ified engineering tools, the RCE workflow management tool, and the Brics technology for connecting local workflows across organizational borders. The use of surrogate modelling, which is an essential technology in collaborative design studies and optimizations, is supported using the SMR, WhatsOpt, and BAS tools. The integrated application of the collaborative systems engineering technologies has been made possible through the AGILE 4.0 integrated framework OCE, and has been demonstrated in the context of several application case studies in the AGILE 4.0 project.

The Collaborative Flap Design Optimization application case experiences several collaboration challenges. Thanks to the newly developed technologies, most of these challenges have successfully been overcome. New Brics functionalities enable the automatic transfer of high-fidelity models between different disciplines. The MDAx I/O generator greatly reduce the effort to keep CPACS files between disciplines consistent. The surrogate modelling tools will resolve the challenges encountered with computational expensive tools. And finally, KE-chain, ADORE, and the RVF together enable the inspection of the relations between the systems engineering elements, increasing the traceability of the design study and increasing the common understanding of the application case between the partners involved.

The Airframe Upgrade Design application case successfully faces a large number of collaboration challenges, thanks to the AGILE 4.0 OCE technologies. During the preliminary design phase, OCE allows considering all stakeholders' needs involved in the process accounting for different scenarios. In addition, such a collaborative environment makes it possible to include all the effects coming from the huge number of disciplines required to obtain a coherent and realistic solution. High-fidelity results can be obtained through few hours of computations thanks to the integration of surrogate models provided via the SMR in the design workflow. Therefore, trade-off analysis to evaluate the best retrofit solution according to the stakeholders' needs are made possible.

The Family Concept Design application case introduces several challenges to the collaborative environment. For example, the Brics technology is successfully being applied in the setup and application of a large and complex collaborative workflow, using custom scripts rather than the ready-to-use RCE Brics Plug-ins. Several disciplines are integrated in the workflow using surrogate models to reduce the workflow runtime. The application case also demonstrates successful application of several collaborative systems engineering tools, such as MDAx for workflow modelling, ADORE for manipulating ADSGs, and MultiLinQ for linking architecture models created using ADORE to MDAO workflows.

The AGILE 4.0 project demonstrates that the collaboration technologies, available through the integrated framework OCE, support dispersed teams of experts to successfully jointly apply engineering competences and MBSE and MDAO technologies in the collaborative development of complex aeronautical products, and to face the challenges of collaborative aircraft development, despite the hurdles that impede collaboration.

Fig. 1

 1 Fig. 1 Systems Engineering Product Development process set up in AGILE 4.0 for the collaborative development of complex aeronautical systems [20].

Fig. 2

 2 Fig. 2 Collaborative MBSE and MDAO technologies developed in AGILE 4.0 to address all the steps of a Systems Engineering Product Development process (adapted from [20]).

Fig. 3

 3 Fig. 3 Schematic overview of the KE-chain front end which embeds and provides access to OCE technology as engineering services. B. Collaborative Systems Engineering Several technologies have been developed in AGILE 4.0 to support, improve and accelerate the development activities performed by multiple experts during the different steps of the collaborative Systems Engineering Product Development process introduced in Section II.The collaborative definition and modelling of systems, stakeholders, needs, scenarios and requirements is performed mainly through the GUI of KE-chain. Different people having different roles in the development process (e.g. customers, requirement engineers) can collaboratively author and inspect the data regarding the first two steps of the AGILE 4.0 Systems Engineering process depicted in Fig.1using KE-chain. In addition, model validation scripts are integrated in the KE-chain back end in order to automatically identify possible errors, missing details and inconsistencies in the information produced by different members of the team.The intermediate part of the AGILE 4.0 Systems Engineering Product Development process focuses on the generation of multiple alternatives of system architectures fulfilling all the functions demanded by the stakeholders through their needs. System architectures are therefore created by multiple people through the modelling of an architecture design space based on the ADSG. The GUI for editing the ADSG is implemented in a tool called ADORE[START_REF] Bussemaker | From System Architecting to System Design and Optimization: A Link Between MBSE and MDAO[END_REF]. Its graphical user interface is implemented using web technologies to ensure that the back end, i.e., the Python code implementing the ADSG, and the front end, i.e., the browser-based interactive GUI code for manipulating the ADSG, do not have to reside on the same computer. This enables the use of the tool and method without any need for local installation. Besides user convenience, this also serves the purposes of protecting IP rights and enables quicker release cycles.ADORE has been deployed at a central webserver. Connection to the OCE implemented in KE-chain is established using the aforementioned Pykechain Python library. Independently from the main code of ADORE, a KEchain/ADORE adapter code base is created that implements functionality related to authentication and project-data management using the KE-chain platform. This enables users to authenticate themselves using the same credentials they use for accessing the OCE, and to store and load ADORE projects stored in some design study project in the OCE. This concept is depicted in Fig.4. Additionally, this adapter code enables adding upstream systems engineering elements (e.g. functional requirements, boundary functions) to ADORE projects. Linking upstream elements to elements in the architecture design space model represents the main forward traceability link between upstream system engineering phases and the architecting phase.

Fig. 5

 5 Fig. 5 Schematic representation of the Brics protocol in the context of a client and a server workflow in RCE. The numbered arrows indicate the steps taken to accomplish the remote execution, as described in the text above.

Fig. 6

 6 Fig. 6 Representation of the same WhatsOpt surrogate model in three different OCE components: a) WhatsOpt , b) SMR and C) RCE.

Fig. 8

 8 Fig. 8 Two different flap configurations are considered in AC1: the advanced kinematics flap (left) with a decoupled rotation and translation, and the dropped hinge flap (right) [38].

Fig. 9

 9 Fig. 9 Overview of the analysis tools used within AC1, including their geographical location.

Fig. 10

 10 Fig. 10 AGILE 4.0 AC 6 Aircraft with Engines and OBS highlighted.

Fig. 11

 11 Fig. 11 Excerpt of AGILE 4.0 AC6 stakeholders and needs.

Fig. 12

 12 Fig. 12 AGILE 4.0 AC6 MDAO XDSM of the MDAO workflow.RCE, Brics.A CMDOWS file has been generated and imported in RCE, allowing to automatically generate an executable collaborative converged design-of-experiments (DOE) workflow. Thanks to Brics technology, each specialist executes his or her own tool remotely, only providing to the main working station the outcome of the computations. The CPACS format allows to store the preliminary and the evaluated pieces of information concerning the analyzed platform in a single output file.SMR. High fidelity results are reached through the execution of this workflow. The definition of two surrogate models allowed to reduce from hours to seconds the execution time of these tools. A response surface model from CFD computations has been obtained to estimate the aircraft drag in cruise condition, also accounting for the new installed engine geometry. The second surrogate model is exploited to size the wing structure according to the aircraft masses and loads. Both these surrogate models allow to better estimate the performance and costs related to the retrofitted aircraft, which are the main objectives of the analysis.

Fig. 13 AC7Fig. 14 AC7

 1314 Fig. 13 AC7 XDSM visualizations of the family-level workflow.

Fig. 15

 15 Fig. 15 Sequence diagram showing how one design vector is analyzed: ADORE is used to generate an architecture, MultiLinQ to map the architecture to and from the CPACS file, Brics to send the file to the MDAO workflow in RCE.

Acknowledgments

The research presented in this paper has been performed in the framework of the AGILE 4.0 project (Towards cyberphysical collaborative aircraft development) and has received funding from the European Union Horizon 2020 Programme under grant agreement n• 815122.


Laura Paggi

Alice Fabas

Hasnaa El Ouazzani

Jean-Paul Hugonin

Nathalie Bardou

Christophe Dupuis

Jean-Jacques Greffet

Patrick Bouchon

Over-coupled Helmholtz-like optical resonator for broadband surface enhanced infrared absorption (SEIRA) spectroscopy

Keywords: nanoresonator, surface enhanced infrared absorption, spectroscopy, detection

Many sub-wavelength structures have been used to enhance the infrared fingerprint of molecules in order to develop sensitive and versatile infrared spectroscopy molecular detection tools. Helmholtz-like optical resonators have the ability to strongly enhance electric fields in relatively large volumes and show good angular stability while their fabrication process is well mastered, what makes them interesting for an application to surface enhanced infrared absorption (SEIRA) spectroscopy. The overcoupled configuration shows new advantages compared to other coupling regimes: it can enhance the signature of vibrational modes of poly(methyl methacrylate (PMMA) up to 70% over 5 µm wide wavelength range with a unique resonator. This study presents the behaviour of this promising structure compared to the original Helmholtz optical resonator and the application of different coupling regimes to SEIRA spectroscopy of PMMA, underlining the advantages of the overcoupling regime previously demonstrated.

INTRODUCTION

Sub-wavelength metallic structures have kept on demonstrating potential for applications to Surface-Enhanced Infrared Absorption (SEIRA) spectroscopy. [START_REF] Osawa | Near-Field Optics and Surface Plasmon Polaritons[END_REF] These structures, able to strongly enhance electric fields can increase the absorption of chemical compounds places in their vicinity. A majority of publications focus on developing optical resonators operating in reflection that are critically coupled to free space (i.e. reflectivity R is equal to zero at resonance) or undercoupled, with the highest enhancement of the field achievable. [START_REF] Neubrech | Resonant Plasmonic and Vibrational Coupling in a Tailored Nanoantenna for Infrared Detection[END_REF][START_REF] Cubukcu | Split ring resonator sensors for infrared detection of single molecular monolayers[END_REF][START_REF] Cataldo | Hole-Mask Colloidal Nanolithography for Large-Area Low-Cost Metamaterials and Antenna-Assisted Surface-Enhanced Infrared Absorption Substrates[END_REF][START_REF] Brown | Surface-Enhanced Infrared Absorption Using Individual Cross Antennas Tailored to Chemical Moieties[END_REF][START_REF] D'andrea | Optical Nanoantennas for Multiband Surface-Enhanced Infrared and Raman Spectroscopy[END_REF][START_REF] Brown | Fan-Shaped Gold Nanoantennas above Reflective Substrates for Surface-Enhanced Infrared Absorption (SEIRA)[END_REF][START_REF] Huck | Plasmonic Enhancement of Infrared Vibrational Signals: Nanoslits versus Nanorods[END_REF][START_REF] Chen | Nanogap-Enhanced Infrared Spectroscopy with Template-Stripped Wafer-Scale Arrays of Buried Plasmonic Cavities[END_REF][START_REF] Huck | Chemical Identification of Single Ultrafine Particles Using Surface-Enhanced Infrared Absorption[END_REF][START_REF] Fabas | Dispersion-based intertwined SEIRA and SPR effect detection of 2,4-dinitrotoluene using a plasmonic metasurface[END_REF][START_REF] Tittl | Metasurface-Based Molecular Biosensing Aided by Artificial Intelligence[END_REF][START_REF] Altug | Advances and applications of nanophotonic biosensors[END_REF] Detection of very low quantity of material has been achieved. [START_REF] Dong | Nanogapped Au Antennas for Ultrasensitive Surface-Enhanced Infrared Absorption Spectroscopy[END_REF][START_REF] John-Herpin | Quantifying the limits of detection of surface-enhanced infrared spectroscopy with grating order-coupled nanogap antennas[END_REF] A challenge remains in creating versatile and broadband enhancing devices. Strategies have been proposed like using multi-resonant structures, [START_REF] Aouani | Ultrasensitive Broadband Probing of Molecular Vibrational Modes with Multifrequency Optical Antennas[END_REF][START_REF] Chen | Dual-Band Perfect Absorber for Multispectral Plasmon-Enhanced Infrared Spectroscopy[END_REF][START_REF] Cetin | Multi-resonant compact nanoaperture with accessible large nearfields[END_REF][START_REF] Rodrigo | Resolving molecule-specific information in dynamic lipid membrane processes with multi-resonant infrared metasurfaces[END_REF][START_REF] Rodrigo | Self-Similar Multiresonant Nanoantenna Arrays for Sensing from Near-to Mid-Infrared[END_REF][START_REF] Li | Multifunctional Chemical Sensing Platform Based on Dual-Resonant Infrared Plasmonic Perfect Absorber for On-Chip Detection of Poly(ethyl cyanoacrylate)[END_REF] epsilon near zero material, [START_REF] Smaali | Reshaping plasmonic resonances using epsilonnear-zero materials for enhanced infrared vibrational spectroscopy[END_REF] but they stay limited or lack experimental demonstration. The inclusion of machine learning in data analysis and multiplexed antennas is a very promising approach, but it implies combining many resonators and probing different molecules. ? Helmholtz-type optical resonators have the advantage of strongly enhancing the electric field homogeneously in a relatively large volume. [START_REF] Fabas | Dispersion-based intertwined SEIRA and SPR effect detection of 2,4-dinitrotoluene using a plasmonic metasurface[END_REF][START_REF] Chevalier | Optical Helmholtz resonators[END_REF][START_REF] Abadie | Helmholtz resonator applied to nanocrystal-based infrared sensing[END_REF] The overcoupled regime offer in this case many advantages: better enhancement, up to 70% and with only one resonator, it is possible to enhance all the vibration modes of the molecules over very large wavelength range. [START_REF] Paggi | Over-coupled resonator for broadband surface enhanced infrared absorption (seira)[END_REF] In this work, we propose a parametric study of such a Helmholtz-type structure and explore the evolution of its spectral response according to geometry, as well as different coupling configurations and their enhancement of poly(methyl methacrylate (PMMA) infrared signature. A combination of few of these structures could enable to pave the fingerprint region to recover the specific signature of any molecule and create a versatile infrared spectroscopy detection platform.

HELMHOLTZ-LIKE RESONATOR

The optical Helmholtz resonator is a structure inspired from acoustics. [START_REF] Chevalier | Optical Helmholtz resonators[END_REF] The Helmholtz-like resonator is likely constituted of a dielectric layer, on a gold substrate and surmounted by a gold layer nanostructured to form an array of ribbons. Compared to original Helmholtz optical resonator, the cavity walls have been suppressed in order to simplify the structure and its fabrication process. The valuable properties of the structure are nonetheless maintained: in between the ribbons, the field is concentrated at resonance. The resonance wavelength is tuned thanks to the geometrical parameters as the thickness of the dielectric layer h d , the thickness of the ribbons h Au , the width of the slits between the ribbons w and the period d. In this case the width of the box and the period are identical. Calculations are obtained using a B-Splines Modal Method. [START_REF] Bouchon | Fast modal method for subwavelength gratings based on B-spline formulation[END_REF] For the following figures, we chose the following geometrical parameters: h d = 50nm, h Au = 45nm, w = 50nm an d = 765nm. For the closed cavity, the period is 2 µm. The dielectric layer is modeled with a model corresponding to zinc sulfide (ZnS) [START_REF] Klein | Room-temperature dispersion equations for cubic zinc sulfide[END_REF] and gold layers by a Drude model. Fig. 1 shows the Helmholtz-type structures with both continuous and closed cavity along with a spectrum and normalized electric field distribution maps. At resonance, the field is highly confined inside the slit. The simplified structure keeps a strong angular tolerance, which is advantageous for device integration, in addition to the simpler fabrication process. The evolution of the resonance wavelength λ R with the different geometrical parameters h d , h Au , w and d for both continuous and closed cavity are presented in Fig. 1. The geometrical parameters influence the coupling of the system to free space by changing the system's ratio of radiative loss over non radiative loss γ r /γ nr . [START_REF] Adato | Engineered Absorption Enhancement and Induced Transparency in Coupled Molecular and Plasmonic Resonator Systems[END_REF] The critical parameter is the thickness of the dielectric layer. One can demonstrate the SEIRA potential of the structure by adding an analyte in the slits, here chosen as a 45 nm PMMA layer described in the calculations by a dielectric permittivity given by a Drude-Lorentz model. [START_REF] Paggi | Over-coupled resonator for broadband surface enhanced infrared absorption (seira)[END_REF][START_REF] Tsuda | Spectral and angular shaping of infrared radiation in a polymer resonator with molecular vibrational modes[END_REF] The layer is placed on top of the ribbons and filling the slits. For all geometries, the slits dimensions are identical and the period has been adapted to tune the resonator with the strong vibration mode of PMMA at 5.8 µm. If the thickness of the ZnS layer is decreased to 20 nm, the ratio of losses is inferior to 1 and the overall system shifts towards undercoupling. A typical SEIRA effect (peak of reflectivity) appears at 5.8 µm testifying of the coupling between the Helmholtz resonance and PMMA mode. This phenomenon has been previously described in literature using Temporal Coupled Mode Theory. [START_REF] Adato | Engineered Absorption Enhancement and Induced Transparency in Coupled Molecular and Plasmonic Resonator Systems[END_REF] In the contrast is limited theoretically, as it start from a lower absorption. The field enhancement is also low, as shown on Fig. 2 From both previous examples, as for many structures proposed in the literature, the reflectivity contrast is hard to recover, as the spectrum is shifted due to the effect of the change of refractive index. Post-processing strategies are usually required to obtain the information.

APPLICATION TO SEIRA

By increasing the thickness of the ZnS layer to 280 nm, one can obtain an overcoupled system: the resonator cannot absorb all the incident light, it saturates, and the resonance appears wide and has a weak amplitude. In this case, the field intensity is lower (Fig. 2.c.), which is not always the case (Fig. 2.g. [START_REF] Paggi | Over-coupled resonator for broadband surface enhanced infrared absorption (seira)[END_REF] ). With the addition of a PMMA layer as previously described, the overall system shifts towards critical coupling (maximum absorption) and the PMMA modes are enhanced as proven by dips in reflectivity due to exalted absorption.

In this case, the overcoupled regime shows a clear advantage over the previous configurations. The low quality factor of the resonance enables to use reflectivity difference values without and with the PMMA layer ∆R = R without -R with . The reflectivity difference is thus 75% for the 5.8 µm PMMA mode. The resonance shifts due to refractive index change has less influence, which makes the tuning less critical the information about the analyte easier to recover. Other absorption peaks of the molecule are visible at higher wavelengths. By taking a resonator with a higher resonance wavelength, it is possible to obtain higher enhancement of all modes between 5 and 10 µm as the field enhancement is maintained along the wide resonance. [START_REF] Paggi | Over-coupled resonator for broadband surface enhanced infrared absorption (seira)[END_REF] The simple stacked structure of the Helmholtz-type resonator has the advantage to be fabricated using wellknown processes. A 280 nm thick ZnS layer is deposited on a gold substrate and the gold ribbons are then created with electron-beam lithography. The PMMA layer used as analyte is deposited by spin-coating in order to obtain a thin layer of about 50 nm filling the slit. Measurements are performed with Fourier Transform Infrared (FTIR) spectrometer. The reflectivity difference obtained is inferior to the theoretical value due to a slight detuning induced by the presence of traces of PMMA under the ribbons left after the lift-off process. Presence of traces of PMMA in the slits is also confirmed on the spectrum of the bare array (Fig. 3.a.) by the little reflectivity dip at 5.8 µm.

Experimental results

CONCLUSION

We presented the behavior of the Helmholtz-type optical resonator with different geometries as well as different coupling regimes. The simplified geometry enables to maintain the properties of the Helmholtz resonator that are attractive for device integration like homogeneous enhancement of the field in large volumes and strong angular tolerance while simplifying the system and fabrication process. The results show clear advantages of the overcoupled configuration, as previously described. [START_REF] Paggi | Over-coupled resonator for broadband surface enhanced infrared absorption (seira)[END_REF] The structure gives larger reflectivity difference, is more robust to geometry fluctuations as the resonance is broad and less affected by the shift of the plasmon resonance, which make analysis of spectra easier. A combination of such structures could give access to the entire fingerprint of molecules and pave the way to the creation of versatile SEIRA sensors.

Further

  author information: (Send correspondence to P.B.) P.B.: patrick.bouchon@onera.fr, Telephone: +33 (0)1 80 38 63 67

Figure 1 .

 1 Figure 1. Structure of a. the Helmholtz optical resonator, b. the Helmholtz-like resonator, c. Calculated spectra and d. normalized electric field maps of the original Helmholtz resonator (orange dashed line) and the simplified version (continuous blue line), e. angular dependence of the Helmholtz-like resonator, f. to i. evolution of the resonance wavelength λR with the geometrical parameters d, w , hAu and h d .

Figure 2 .

 2 Figure 2. Normalized electric field maps and calculated spectra of Helmholtz-like resonators a,d. in undercoupling regime (hb = 20nm), b,e. in critical coupling regime (hb = 50nm) and c,f. in overcoupling regime (hb = 280nm). For all geometries the slit is 45 nm high and 50 nm wide. Periods are adapted to match the 5.8 µm mode of PMMA. g. Evolution of the field intensity as a function of the loss ratio, h. Evolution of the quality factor with the loss ratio.

  .a. In Fig 2.b. is showed the result starting from a resonator close to the critically coupled configuration (h d = 50nm), The reflectivity change is around 20 % and the field is better enhanced. Nevertheless, other vibrational modes are not significantly enhanced.

Figure 3 .

 3 Figure 3. Measured spectra of a. the bare array and b. the array covered with a 45 nm PMMA layer, for TM (orange continuous line) and TE polarization (green dashed line). Grey areas cover the absorption of CO2. Dimensions hAu= 45 nm, h d =280 nm, w = 50 nm and d = 400 nm.

ACKNOWLEDGMENTS

This work was funded by the Agence Nationale de la Recherche grant Dartagnan (ANR-20-CE39-0003).