Impact Monitor Framework: Development and Implementation of a Collaborative Framework for Aviation Impact Assessment ^†

Abstract

The development and implementation of a collaborative framework for aviation impact assessment studies is presented. The focus is on which technologies can be used to enable the collaborative aspect, including the use of a common data model, the secure transfer of data between domain experts in different locations, and the automated execution of impact assessment workflows. It is demonstrated how the selected technologies can be extended to meet the requirements of air transport systems assessment and how they can be integrated into a common framework. The results of the developments are discussed in terms of their technical capabilities and the lessons learned from their practical use. The proposed framework shows that collaborative impact assessment studies can be conducted efficiently and securely. This forms the basis for three application studies in the same research project.

1. Introduction

It is well known that the aviation sector must find ways to significantly reduce its impact on anthropogenic climate change [1]. Any mitigation effort must take into account the complex interplay between the different systems and stakeholders in this sector. For example, an aircraft as a complex system cannot be considered in isolation, but has to be seen in the context of the air transport system as a whole. This includes the fleet composition in which it is operated, how the required energy (fuel) is produced and provided, how it is operated (e.g., operating heights, efficient approach procedures, etc.), how it interacts with others systems like airports and air traffic control, and much more. This holistic view is referred to as the Air Transport System (ATS) [2]. In addition, there are important interactions at the interface between the ATS and other transport systems, e.g., sea and land transport [3], as well as with policy and society.

Scientific studies must take these complex interactions into account if they want to develop meaningful and valid scenarios for reducing the climate impact of global aviation. The challenge here, however, is that no single discipline can adequately cover all aspects; instead, various experts from different disciplines must collaborate. This research work analyzes and develops digital methods to enable and support the formulation and execution of collaborative aviation impact assessment studies. It proposes a digital framework for the seamless integration of the involved experts and tools and for managing the complexity of the data and information exchange involved. Based on the acquisition of requirements in Section 2, a set of suitable technologies is identified in Section 3, and these technologies are then adopted, extended, and implemented in a collaborative framework, as described in Section 4.

2. Requirements

As a first step, a joint requirements workshop was set up. Although no assumptions about the actual framework architecture were made at this point, a division into three categories was already introduced: (1) the data model category addresses questions about interfaces between tools that exchange information based on this data model, as well as requirements about the provenance of the data; (2) the framework category addresses the topics of implementing a central data repository and executing workflows; and (3) the dashboard category includes a graphical interaction by potential users of the framework, addressing questions about data exchange with the actual framework as well as different solutions for data exploration and visualization. This categorization is visualized in Figure 1.

Experts and project members from the Impact Monitor research project were asked to outline so-called “user stories” for each of these areas. Such a user story follows a predefined template structure: “As <who am I>, I would like to <what to do> in order to <why>?” The participants were asked to also cover perspectives of other stakeholders, like aviation research in general, the aviation industry, policymakers, environmental organizations, society, and others. From these user stories, requirements were derived and prioritized according to the MoSCoW method [4]: Must have, Should have, Could have, Won’t have. The five most relevant requirements for each category are listed in

Table 1. Requirements for the Impact Assessment framework (selection of the five most important).

Prio.	Requirement
	(a) Data model requirements
M	Data must be accessible via a suitable API.
M	Workflows must be easy to generate.
M	FAIR principle must be followed.
M	The execution network must meet security issues.
M	Secure user data handling is required.
	(b) Framework requirements
M	The user shall be able to access the dashboard app through a web browser.
M	User access should be through secure login credentials to ensure data privacy and security.
M	The system shall be able to import use case results data represented in tabular form.
M	The system shall be able to create various types of interconnected plots for loaded data.
M	The system should enable the users to interactively filter data locally and globally.
	(c) Dashboard requirements
M	The user shall be able to access the dashboard app through a web browser.
M	User access should be through secure login credentials to ensure data privacy and security.
M	The system shall be able to import use case results data represented in tabular form.
M	The system shall be able to create various types of interconnected plots for loaded data.
M	The system should enable the users to interactively filter data locally and globally.

.

3. State of the Art Review and Technology Selection

As in the previous section, the three categories shown in Figure 1—(1) data model, (2) framework, and (3) dashboard—are used to guide technology selection based on the state of the art of techniques for collaborative impact assessment studies.

3.1. Data Modeling

In terms of data modeling, it is important to link the inputs and outputs of the disciplines involved to ensure a smooth and robustly interpretable exchange of information. There are two state-of-the-art approaches in the engineering design literature: On the one hand, inputs and outputs can be viewed as domain-specific knowledge that is flexibly linked via semantic graphs [5]. An alternative approach is that all domains link to a central language model. Both approaches have their advantages and disadvantages. While the tool inputs and outputs remain essentially unchanged when using semantic graphs, an additional discipline is required to link the languages. The use of a central language model requires a larger initial effort for the tool developers who have to adapt their inputs and outputs to this language model. However, the motivation is to reuse these interfaces in follow-up studies if the central data model is an established standard which does not change too often. In the present research work, the second approach is chosen, using the “Common Parametric Aircraft Configuration Schema” (CPACS). This data exchange model has been developed at the DLR for two decades so that a certain wealth of experience can be built upon. Implemented using the “Extensible Markup Language” (XML), CPACS datasets can be read with simple text editors, the XML Schema Definition (XSD) allows for easy validation and extension of the data model, and it is available as open source. In addition to existing software libraries, e.g., Python lxml.etree [6], DLR provides the CPACS parser TiXI [7] and the geometry library TiGL [8] as open-source extension to different programming languages (e.g., C, C++, Python, Matlab, Fortran, etc.).

Another advantage of using a central data model is that the coupling between the individual disciplines can be modeled in the form of an eXtended Design Structure Matrix (XDSM). Technologies supporting the creaton of workflows via automatic input- and output matching are WhatsOpt [9], Gemseo [10], or MDAx [11]. In this study, MDAx was chosen because its development at DLR allows for flexible adaptations and extensions of the web-based software based on the needs of the Impact Monitor framework.

3.2. Framework

Once the modeling of the data interfaces and the overall assessment workflow are complete, it must be able to run on a network of interconnected computer platforms. This process is often constrained in several ways. Partners can typically share their results, but not all of their tools. Furthermore, IT security restrictions apply and may be subject to other constraints such as human-in-the-loop regulations (e.g., no automated tool execution).

There are various software solutions in the research landscape that address these conditions to varying degrees. One example is GEMSEO [10], which is used as a base technology of the WITNESS framework [12], an open-source platform for collaborative system-of-systems analysis. Other distributed engineering frameworks are TENT [13] or ModelCenter [14]. For this study, the Open-Source integration environment RCE [15] (Remote Component Environment) was chosen because of its strong focus on IT security aspects and long in-house experience from DLR partners. Originally developed for maritime research, the DLR has since coordinated the further development of RCE and established it as a standard for today’s distributed design and analysis processes in aerospace research [15].

Finally, the data generated need to be stored and managed centrally. A suitable technology had to be found that would enable secure and easy data transfer. The open source software NextCloud was chosen from a wide range of cloud-based solutions, as it has proven to be a powerful technology not only for aerospace applications [16,17]. This solution has attracted a large user community over the past few years, so there is a solid documentation base, potential security vulnerabilities should be identified and addressed wherever possible, the solution can be self-hosted or hosted by professional providers on various platforms, and long-term support is available. NextCloud can be accesed via multiple means, for example, by a graphical browser interfae, a WebDAV application programming interface (API), or platform-specific tools to synchronize local folders with a given NextCloud account. An integrated user management allows for flexible authentication and the assignment of individual access rights. For the Impact Monitor project, a NextCloud instance hosted by DESY (Deutsches Elektronen-Synchrotron) as part of the Helmholtz Association was chosen.

3.3. Dashboard

Finally, the visualization of the results will be done via a collaborative web-based platform. While there are no existing solutions that are directly applicable to this project, there are some development frameworks that can be built upon. For the implementation of the backend methodology, the Flask framework [18] is a suitable solution, which can be developed in Python and provides a simple means to develop and deploy the necessary server architecture (e.g., via a REST API and documentation via Swagger).

The frontend architecture can be implemented using a variety of competing frameworks, including Angular [19], Vue [20], React [21], and others. The React framework was chosen for this study due to its extensive portfolio of available modules and libraries for building modern-looking web interfaces.

4. Implementation

The technologies selected in the Section 3 are finally combined within an overall framework for the collaborative impact assessment of the ATS. The necessary extensions and adaptations of the respective technologies in the three categories (1) data model, (2) framework, and (3) dashboard are explained in more detail below.

4.1. Data Model: Using MDAx to Extend CPACS Towards ATS

CPACS is currently undergoing a major revision at the ATS level to enable holistic studies of the entire air traffic system. In order to identify the necessary extensions, the data exchange between the disciplines involved in the Impact Monitor project was modeled as an interactive XDSM diagram using MDAx. MDAx allows the CPACS schema to be imported in the form of an empty XML structure. On this basis, domain experts can map their tool inputs and outputs. Missing information is then used to discuss extensions to the CPACS data model. These can then be implemented in the CPACS schema using XSD according to the CPACS development standards.

The result of the CPACS extensions is shown in Figure 2. Individual aircraft can be modeled at a high level of detail. However, it is equally important to map existing aircraft into the current or near future fleet structure. This is where the advantages of the top-down approach in CPACS come into play. In principle, it is sufficient to specify an aircraft model via an ICAO or IATA code or via referencing a BADA model. The propulsion architecture can also be specified, for example, via the ICAO identifier of existing engines or choosing the energy carrier and propulsion train from a list of keywords (i.e., via restricted strings). In this context, it is also noted that a CPACS dataset can contain several aircraft models. This means that new types of aircraft from current research projects can be combined with existing fleet structures.

A rudimentary airport description is already available in the public CPACS v3.5 release. However, this is currently being expanded to enable detailed approach and departure procedures, for example, for noise or continuous descent operation analyses. The focus here is on the long-term scalability of the data model, with the Netherlands Aerospace Center (NLR) contributing its expertise in airport operations by proposing to structure the airport element into into airport layout and operations as well as airspace layout and operations.

Once the vehicles and airports have been defined, they can be used to define flights. A flight describes a connection between a pair of airports, whereby this connection can be served with a certain frequency, for example to avoid redundant flight definitions on different days of the week. A flight can refer to a mission in the vehicle-independent performanceCases defined at the vehicles level, which was extended to map flight plans.

Finally, different flights can be combined into schedules and assigned to a specific time period. In this way, the current air traffic can be defined in comparison to a future scenario. The schedules element is an extension to the current CPACS v3.5 release and is currently being evaluated and tested in generic application cases, before including it in a public release process in near future.

As usual, in CPACS for most of the major entities, analyses elements are available at different levels to store level-specific results. This approach was adopted at the ATS level. To remain backwards compatible with previous CPACS releases, the studies element was retained at the highest level in CPACS (and not renamed analyses), but expanded by additional study elements (e.g., lifeCycleAssessment).

4.2. Framework: Uplink and Brics for Secure Remote Execution of Workflows

While RCE version 10.5 is available as a robust integration framework that does not require major adjustments to its core, Uplink is an extension to RCE that is currently in prototype development. Uplink allows different RCE clients to connect via SSH, while two levels of security apply: first, users are individually assigned a password-protected account to access an Uplink server provided by DLR in Cologne. Second, different authorization groups can be set up for publishing tools. In this way, the user group for a specific tool provided by a project partner can be restricted to selected applications, thus preventing potential misuse.

Uplink is complemented by an NLR development called BRICS. Similar to Uplink, BRICS has a strong focus on safety-critical aspects for the remote exchange of data between different disciplines [22]. In addition, users are asked before their tools are executed in order to prevent unintentional automatic execution. This man-in-the-loop principle is strictly required in some company policies, for example, at NLR. BRICS can be combined with Uplink. For this purpose, the Uplink tools are tightly integrated into the RCE tool palette, while BRICS tools are connected via a combination of a master and slave workflow, which exchanges data via a central data repository.

4.3. Framework: Development of a RCE-to-NextCloud Interface

In Section 3.2, NextCloud was presented as the chosen data repository solution. Specifically for the Impact Monitor project, an RCE plugin was developed to store the study results in NextCloud for long-term storage and to download them for further processing. Based on the Python programming language, the plugin can be made available to project partners via an Uplink server, as described in Section 4.2. The user credentials are encrypted as a compressed JSON file using the Advanced Encryption Standard AES. On the server side, a corresponding decryption key is available to open the data and provide access to the corresponding NextCloud instance via a WebDAV protocol. By specifying a target location, which by default includes the workflow name and metadata of the uploading user, individual CPACS datasets or entire data folders are stored in the central data repository. Alternatively, by specifying the file paths to be downloaded, information can be automatically retrieved and downloaded via WebDAV, e.g., to make it available for visualization in the dashboard.

4.4. Dashboard Application

The dashboard is a completely new development developed at Cranfield University, as no suitable visualization solution was available for the current research questions. The solution, in the following referred to as Impact Monitor Dashboard Application, is based on the assumption that the datasets from the previous analysis process are provided in the form of CPACS data. Since the CPACS data model is standardized, the results can be automatically processed and visualized. The backend of the Impact Monitor Dashboard Application, implemented with Flask, provides specific functionality such as microservices or interpolation algorithms. The frontend, developed using the REACT framework, enables interactive design space exploration and what-if scenario evaluation at different scales (from aircraft component level to ATS). What-if scenario analysis is particularly relevant for the present research project in order to robustly evaluate the impact of ATS on climate and society and to derive decisions from these results. For this purpose, different types of graphs are available where data can be linked to each other. For example, data can be selected from scatter plots while the selected data are highlighted in other plots, such as scatter plots (see Figure 3a). Other plots allow, for example, the visualization of flight paths in two or three spatial dimensions (see Figure 3b).

5. Application Cases and Lessons Learned

The framework was currently applied for three demonstration studies: (1) a classical aircraft design process with the design of the propulsion architecture [23], (2) an analysis of the potential of continuous descent procedures at a generic airport [24], and (3) a socio-economic impact study at the ATS level [25]. The referenced literature provides a deeper insight into these use cases. In order to apply the framework correctly and efficiently, the researchers involved were introduced to the technologies through a novel training procedure. On the one hand, simplified Python tools were provided to establish the technical basis for reading and writing CPACS data and to make the tools available to other project partners via RCE. At the same time, MDAx was used to define and discuss the connections between the disciplines via CPACS, on the basis of which the data model could be adapted and extended to meet the new requirements (see Section 4.1).

Important lessons were learned from this process: (1) Connecting to CPACS requires some initial development effort from tool owners, which is often underestimated. It should be emphasized that the return on investment comes with future studies where the developed interfaces can be reused, as CPACS is a standardized data exchange model. Furthermore, (2) the teaching material needs to be precisely described. Finally, (3) CPACS should only be used for data exchange and not as a container for all available data.

6. Conclusions and Next Steps

This study developed a framework for assessing the climate and societal impacts of the ATS. Requirements were gathered, and potential technologies were identified, which were then extended and implemented into a holistic framework. In this context, a new teaching process simplified the connection of disciplinary tools to CPACS and its integration into RCE, while at the same time MDAx was successfully applied in a large and heterogeneous project team to define and discuss the disciplinary interfaces in a very efficient way. As the CPACS data model has historically had a strong focus on the aircraft and its component level, major extensions to the ATS level will pave the way for future impact assessment studies. The prototypical implementation of RCE–Uplink has proven to be robust and useful within the research project.

Some work needs to be invested to finalize the details of the CPACS extensions, complete the workflow implementation and execution, and enhance the dashboard with user feedback. In this context, the CPACS extensions will be incorporated into the public release so that the research community can build on the work. The authors of this paper and the researchers involved in the Impact Monitor project will employ the framework in follow-up studies to elaborate the use cases and generate more holistic results. This will not only test the scalability of the impact assessment framework, but also contribute to making aviation more economically and environmentally sustainable through reliable and transparent results.