Integrated collaboration capabilities for competitive aircraft design

Airlines need to continuously extend and modernise their fleets, to keep up with the challenges of air-travel growth, competition, green, safe and secure operations, and growing passenger demands. As a result, the aircraft industry and its supply chain have to manage the growing needs for cost-efficient and complex aircraft in increasingly shorter time. Meanwhile they face their own challenges, such as certification and global competition. Quick evaluation of promising new technologies and concepts facilitates a short time to market. However, the required innovations are costly and risky, and require involvement of many experts from different disciplines and partners. Increasing the level of collaboration within the aircraft industry and its supply chain will be an essential step forward to deal with the challenges. Developing modern aircraft in an increasingly cost and time efficient manner in a collaborative set-up however requires step changes. The EU-funded Horizon2020 project AGILE has developed methods and tools for efficient and cross-organisation collaborative aircraft design, facilitating the rapid evaluation of new technologies and concepts at the early stages of aircraft development. This paper describes the capabilities and illustrates the successful integrated application of the capabilities by means of a collaborative aircraft rudder design evaluation.


Introduction
Global air travel is doubling every fifteen years [1]. Besides accommodating this growth, airlines also have to deal with increasing passenger demands for fast, cheap, and comfortable travelling. Moreover, green, safe and secure air travel operations must be ensured. To keep up with these challenges, airlines continuously extend and modernise their fleets. As a result, the aircraft industry and its supply chain must constantly innovate. They have to manage the growing needs for cost-efficient and complex aircraft in increasingly shorter time.
For airframers, the quick evaluation of promising new aircraft technologies and concepts facilitates a short time to market [2]. The required innovations in the aircraft design and development process are however costly and risky and involve a multitude of disciplinary experts that may be distributed among many partners. At the same time, the aircraft industry faces issues such as certification, global competition, economic fluctuations, scarcity of non-renewable energy sources, staff turnover and aging employees. Increasing the level of collaboration within the aircraft industry and its supply chain is considered as an essential step forward in order to deal with all these challenges. Developing modern aircraft in an increasingly cost and time efficient manner in a collaborative set-up however requires step changes.
The EU-funded Horizon2020 project AGILE targets the significant reduction of aircraft development costs by enabling a more competitive supply chain to reduce the time to market of innovative aircraft products. AGILE focuses on the reduction of the aircraft development effort and time at the early stages of the design process, pronouncing the synergies among the overall product architect and the heterogeneous disciplinary experts, thereby exploiting the knowledge and expertise available in the supply chain. In AGILE, multidisciplinary aircraft design analyses and optimisations are performed in a collaborative way by engineers from multiple organisations located in several countries. With reduction of the aircraft development lead-time and increase in quality of the design and optimisation process as major goals, AGILE has developed and enhanced a set of capabilities for efficient and cross-organisation collaborative aircraft design [2]. The capabilities enable multidisciplinary experts from different organisations to collaboratively and rapidly evaluate new technologies and concepts at the early stages of aircraft product development.
This paper describes the capabilities and illustrates the successful integrated application of the capabilities by means of a collaborative aircraft rudder design evaluation. Section 2 analyses the main challenges in collaborative aircraft design, and lists requirements for collaboration capabilities. Section 3 describes the capabilities that were developed, enhanced and integrated in the AGILE project to address the challenges and requirements. Section 4 describes the integrated demonstration of the capabilities by means of a collaborative and integrated aircraft rudder design evaluation. Section 5 summarises and concludes.

Collaboration challenges and requirements
Although collaboration may seem straightforward in the aircraft industry and its supply chain, it is certainly not trivial [3]. Many organisational, human and technical barriers that impede collaboration -let alone efficient collaboration -have been encountered and dealt with by the authors in former research project throughout the past decades (e.g. the EU projects CRESCENDO [4] and TOICA [5], and the DLR-lead project FrEACs [6]). These barriers have raised several interesting challenges in the area of collaborative aircraft design and multi-disciplinary analysis studies [2,7]. In particular, "upgrading" from a singleengineer workflow running on a single computer to a multi-site collaborative workflow that spans multiple engineers working on different computers in different organisations, potentially in different countries, raises many challenges.
The challenges are largely caused by the heterogeneity among organisations, people and their ways of working, and by the security constraints that serve to protect assets and intellectual property (IP). As a result, collaborating engineers from different organisations generally have to deal with barriers such as compliance with information and knowledge sharing rules, the obligation to exchange data securely, technical security measures (incl. firewalls, proxy servers), and heterogeneity among working procedures, tools and data formats. These clear and explicit barriers exist in addition to more implicit barriers and issues such as export control regulations, cultural differences, personal and organisational interests and lack of an overarching organisational management. A more detailed overview of the collaboration challenges on the human, organisational and technical level, and a description of the general collaborative design architecture that was developed and applied in AGILE are presented in [7]. One of the project results is the 'AGILE Development Framework' (ADF) for use in several collaborative design studies of innovative aircraft concepts.
The ADF supports distributed teams of multidisciplinary engineers in efficiently conducting collaborative aircraft design and analysis studies, and -more specificallydefining and executing cross-organisation multi-disciplinary design analysis (MDA) and optimisation (MDO) studies and workflows. Based on the challenges described before, the following collaborative design requirements have been addressed through the ADF: 1. Use knowledge about the analysis competences available among the team to enable the selection of competences, to perform sanity checks, to facilitate the definition of multi-partner collaborative MDA/MDO studies and the composition of executable workflows that support the studies. 2. Facilitate the use of the disciplinary analysis tools the specialists are used to work with (i.e., do not enforce the use of standard analysis tools). 3. Facilitate the shared use and coupling of competences across organisations, both with respect to data and integrated use of tools in process integration and design optimisation systems in a non-intrusive way: comply with local systems and architectures. 4. Deal with the technical barriers resulting from assets and IP protection, while complying with the prevailing policies, procedures and security constraints of the collaborative study and the participating organisations.

AGILE collaboration capabilities
The ADF has been implemented as an integrated set of collaboration capabilities (i.e., standards, services and tools), which were developed and/or enhanced in the AGILE project to support collaborative MDA/MDO studies and integrated application of the available competences. The collaboration capabilities are listed below, together with an indication of the requirement(s) addressed.  KE-Chain [8]: cloud-based business workflow manager, used in AGILE context for set-up, management and execution of MDA/MDO studies and for integrated application of the available competences and collaborative capabilities. The AGILEspecific business workflow guides the MDA/MDO study architect through the process of competence specification and selection, and workflow composition, execution, and results inspection. (Requirement 1)  CMDOWS (Common Multidisciplinary Design Optimization Workflow Schema) [9]: XML-based data format for specification of knowledge about competences and for workflow-tool independent specification of workflows. (Requirement 1)  SMR (Surrogate Model Repository) [7]: central broker for registration, storage, deployment, sharing, and usage of surrogate models (SMs), enabling sharing and reuse of said models among collaborating partners in a knowledge-based way. The SMR serves to facilitate sharing of the SMs developed and applied in AGILE, to enable partners to provide simplified versions of their models to support efficient optimisation while protecting the IP of the detailed models.

Integrated demonstration of the collaboration capabilities
In order to assess the collaboration capabilities of the ADF presented in section 3 against the collaborative design requirements presented in section 2, an integrated demonstrator comprising the involved capabilities has been set up. The demonstrator features an integrated aircraft MDA, applying NLR's aero-elastic load analysis tool AMLoad [13] in combination with SMs of other design competences. The SMs were made available through the SMR. The collaborative design of an aircraft rudder was selected as a use case (see also [13]). Only the MDA step was performed, excluding the optimiser from the loop. For a given aircraft configuration and rudder planform the rudder loads are calculated by AMLoad. A SM based on several local rudder optimisations performed by GKN Fokker calculates the optimised rudder mass for the specified rudder load and planform. Another SM based on an Overall Aircraft Design (OAD) analysis performed by DLR calculates the corresponding mission fuel mass. Fig. 1 depicts the demonstration setup of the integrated rudder MDA using the ADF, with all the collaboration capabilities as described in section 3. The demonstration was performed in an integrated as well as distributed set-up: KE-Chain, Kadmos and VISTOMS run at KE-Works, SMR on an NLR web server, RCE on a NLR-internal PC, and the analysis tools AMLoad and the SMs on separate NLR-internal PCs. Brics plays a key role in facilitating the distributed simulation workflow. The Teamsite data server (hosted by DLR) plays the role of the central shared data repository.
The left part of Fig. 1 illustrates the five steps towards MDA/MDO study set-up, execution and analysis as supported by the ADF. Below these steps are described in more detail. Each step is initiated from within KE-Chain. The ADF process involves a number Actors: the Architect formulates the requirements of the study and reviews the results, the Integrator selects, specifies and connects the involved MDA competences, the Discipline specialists make available and run their MDA competence and the Collaboration engineer facilitates the multi-partner and multi-site aspects of the collaborative MDA workflow. Step 1: Define the study. During this step, the Architect defines an MDA/MDO study in terms of requirements, design parameters and objectives, and involved engineering competences. First, the requirements for the study are defined. In this case the study involves the evaluation of one aircraft rudder MDA step while applying all the tools in the ADF in a distributed and integrated way. Second, the involved design parameters and objectives are defined: the aircraft wing span and the rudder root chord are supplied as design parameters, while the aircraft fuel mass is specified as the objective (output) of the analysis. Third, the involved competences are selected: in our case AMLoad is applied as analysis competence, in combination with a geometry-retrieval tool (getGEOM), and with SMs of the local rudder design optimisation (rudderSur) and the OAD analysis (oadSur). As the SMs were made available through the SMR a direct link is provided from KE-Chain to the SMR. Within the SMR the SMs are stored together with their meta-information [7], e.g. allowed ranges of the input parameters and prediction accuracy. This meta-information is relevant for formulation of the MDA in KE-Chain, and as such can be exchanged between the SMR and KE-Chain using the CMDOWS SM description as the intermediary format. As the result of this exchange, the SMs deployed on SMR are made available in the KE-Chain environment as MDA competences as well.
Step 2: Specify the competences. During this step, the Integrator specifies -in collaboration with the Architect and the Discipline specialists -the competences in terms of detailed inputs and outputs, for further automated generation of an analysis or optimisation workflow. First the reference aircraft is selected by importing the applicable CPACS file. The data model of the selected aircraft can be browsed through KE-Chain and the aircraft geometry can be visualised and inspected using a 3D model generated by VISTOMS. Next, the inputs and the outputs of the competences are non-ambiguously mapped to sections of CPACS file (e.g. "length of the rudder root chord" parameter will be mapped to "rudder/rootChord/length" section). The interplay between the competences can then be visualised by the means of a repository connectivity graph (RCG; e.g. Fig. 2), which describes the correspondence between inputs and outputs of various models. Step 3: Formulate the problem. In this step the Integrator derives an eXtended Design Structure Matrix (XDSM) using the RCG generated in the previous step. This analysis is automated by Kadmos, which, based on the specification of workflow inputs and outputs, constructs optimal workflow execution order. The execution order is then visualised by VISTOMS (see Fig. 2). Although this demonstration focussed on a simple rudder MDA, Kadmos can handle more complex cases as well (such as ones involving optimisation). Step 4: Prepare the PIDO systems. During the previous step intermediate representations of the MDA workflow were generated. During step 4 the Integrator generates the final representation of the MDA workflow in CMDOWS format. The final representation includes the information required for remote execution of the involved competences, such as contact information of remote tool specialists and the web address of the shared data repository -DLR's Teamsite in the current demonstration -that need to be provided to the Brics encapsulations of the competences. Next the Collaboration Engineer configures the PIDO tool -RCE in the current demonstration -by specifying installation paths and other settings of locally available software tools called from workflow. Subsequently, the MDA workflow in CMDOWS format is imported into the PIDO tool. Fig. 3 presents the resulting distributed RCE workflow, with a brief explanation of each execution step and with the remote counter parts included. Finally, after the PIDO tool is provided with the downloaded CPACS input file and user credentials required for using the remote services, the workflow is ready to be executed.
Step 5: Run the workflow and inspect the results. The workflow (see Fig. 3) is run in a semi-automatic way. The Collaboration Engineer starts the workflow. The getGEOM tool runs automatically on the local PC with the RCE installation. Next a Brics notification is sent automatically to the AMLoad Discipline specialist, triggering him/her to calculate the rudder force on local PC. The AMLoad Discipline specialist starts this task by downloading the input from the Teamsite, and completes it by uploading the calculation results back there. Subsequently another Brics notification is sent to the rudder Discipline specialist, who performs that task in a similar fashion and calculates the optimised rudder mass (the rudder Discipline specialist could start his/her detailed rudder analysis process, but within the scope of this demonstration, for efficiency purposes, the rudder SM is used instead). Subsequently, the oadSur tool is run automatically, calculating the aircraft fuel mass (for a standard mission, applying the current design configuration). In the context of this demonstration the steps getGEOM and oadSur were performed by the Collaboration Engineer on local PC, but this could be performed by separate Discipline specialists as well, on their remote PCs using Brics.
Finally, the resulting CPACS file that contains the results of the MDA study is uploaded into KE-Chain by the Collaboration Engineer for review and inspection by the Architect. In the demonstration, the Architect inspects the study results by looking at the value of the calculated fuel mass, i.e. the MDA result.

Summary, conclusions and future directives
In this paper we have described the need for efficient multi-partner collaboration in aircraft design, listed the challenges that come with this collaboration, derived specific collaborative design requirements and introduced the capabilities fulfilling these requirements, which were developed and enhanced in the AGILE project. As such these capabilities facilitate efficient collaboration, and in particular the definition and execution of MDA/MDO studies and workflows across organisational borders.
Being able to set-up and conduct collaborative studies and run optimisation studies and automated workflows across multidisciplinary engineers at different organisations is one of the cornerstones and success factors of AGILE. The study described in section 4 has been the first live demonstration of the integrated set of all collaboration capabilities available in the project. Although a simplified MDA study was used as example it illustrates well both the potentials of and the challenges towards collaborative design and demonstrates the integrated approach.
Application of the AGILE Development Framework and being able to smoothly run cross-organisation collaborative workflows raised new challenges and triggered ideas that deserve additional research. For example, making cross-organisation collaborative workflows more robust and flexible is an important challenge towards higher TRL levels and application in industry. Present workflows may suffer from non-responsive services, engineers being unavailable in time, or tools producing erroneous results. The new challenges will be used as input for research activities in the near future.