A Versatile Computation Platform applied to Environmental-Impact Assessments at Airport Level in Clean Sky 2

The objective of the Clean Sky 2 Technology Evaluator project GREENPORT2050 is to assess the environmental impact up to 2050 at airport level of technologies developed in Clean Sky 2 for fixed-wing aircraft. To not only facilitate computational processes and improve their efficiency, but also to ensure quality and configuration-management tasks are automatically and well taken care of, Royal NLR develops a versatile computation platform for conducting these assessments. This paper provides an overview of the platform’s implementation (adopting modern, widely-accepted and proven technologies) and its key features (especially in relation to the mechanism of defining and integrating models).


Introduction
Set up in 2014, the aim of the Clean Sky 2 Programme is to develop cleaner air transport technologies for earliest possible deployment.Cross-positioned in the programme, Clean Sky 2 established for its entire duration an independent technology evaluator: Technology Evaluator (TE).The TE's main task (cf.Article 12 in Annex I to [2]) is to monitor and assess the environmental and societal impact of the technological results arising from all Clean Sky 2 activities.In particular, TE aims to quantify the expected improvements on the overall noise, greenhouse-gas and air-pollutants emissions from the aviation sector in future scenarios in comparison to baseline scenarios.
With Clean Sky 2 technologies clustered (defining Clean Sky 2 concept aircraft), Clean Sky 2 TE conducts assessments through realistic simulations of flight or mission scenarios at three complementary levels: Aircraft (or mission) level, airport level, and air-transport system level.Carried out by Royal NLR -Netherlands Aerospace Centre, the Clean Sky 2 TE project GREENPORT2050 (Clean Sky 2 Technologies for Greener Airports by 2050; [3]) aims to quantify the environmental impact at airport level up to 2050 of technologies developed in Clean Sky 2 for fixed-wing aircraft.This impact focuses on noise on ground and on gaseous emissions and their contribution to air quality.
To facilitate GREENPORT2050's computational processes and to improve their efficiency as well as to ensure their quality and configuration-management tasks are automatically and well taken care of, GREENPORT2050 develops a versatile computation platform.This paper provides an overview of this platform, including its implementation and key features, as well as an illustration of its application in GREENPORT2050 and its potential use for a broader range of applications.

Problem domain
GREENPORT2050 provides the airport-level contribution for fixed-wing aircraft to Clean Sky 2 TE by quantifying the reduction in noise-and gaseous-emissions impact that Clean Sky 2 technologies will bring at timescales up to 2050.For each timescale, GREENPORT2050 conducts an environmentalimpact assessment for the European airports Amsterdam Airport Schiphol, Rome Fiumicino Airport, Stockholm Arlanda Airport, Hamburg Airport and Toulouse Blagnac Airport as well as for the generic airport CAEPport.Per combination of timescale and airport, GREENPORT2050 compares the environmental performance of an air traffic scenario with reference-technology aircraft with that of the same scenario in which Clean Sky 2 concept aircraft replace their reference-technology counterparts.
The quantification of the environmental performance of a scenario basically consists of three steps.The first step is a realistic simulation of the aircraft traffic in the airport's local airspace, herewith generating for each flight a complete trajectory in this airspace, which respects the airport and airspace operational procedures and rules.In the second step, these trajectories are individually processed to determine the noise and gaseous emissions they generate.In the third and final step, the output of the preceding two steps is aggregated to obtain the noise-and gaseous-emissions indicators of interest.Figure 1 illustrates the basic airport-scenario workflow; more information on GREENPORT2050's systematic assessment approach can be found in [1].Performing a multitude of diverse calculations across various domains spanning different airports and timescales, as well as accommodating all input and output data, necessitates the establishment of a computation platform (GREENPORT2050 platform).This platform should facilitate the seamless integration of models and ensure clear attribution of results to their creators, along with specifying the model versions and input data employed.Furthermore, this platform should go beyond merely enabling efficient computations; it should also put a high priority on maintaining strict quality standards encompassing typically traceability, reproducibility, data integrity, and information security.
The GREENPORT2050 platform builds and capitalises on the Java web-based framework set up in GREENPORT2050's predecessor project CLAIRPORT1 .The platform not only leverages the knowledge and expertise acquired from this project but also emphasises the utilisation of modern, widely accepted, and state-of-the-art web technologies.
In the subsequent paragraphs, first an overview is given of the GREENPORT2050 platform's architecture.Next, the core of the platform is addressed, with focus on the techniques selected for the integration of models2 and on the methods to access the platform.

Architecture overview
For sharing information on the web, it is common practice to use the well-known web-application architecture.This architecture is adopted in the GREENPORT2050 platform (see figure 2) using a multitier architecture that consists of: • User-client front-end The front-end component (thin-client) offers web access to the platform.The thin client and its functionality run entirely inside the web browser and is known as a web application where the web server delivers the contents using a REST interface.

• Middle-tier application server
This component contains the models and handles data pre-processing, including input preparation and output extraction/formatting/aggregation.• Back-end datastore (database) The back-end component contains the data storage.The data storage contains all input data and parameters as well as the calculations results.
The platform employs controllers to manage user-related functionalities, models, and more.These controllers expose their functionalities via a RESTful API (application interface), following principles of loose coupling and modularity.Each REST controller supports CRUD operations encompassing Create, Read, Update and Delete operations.For example, a service handling calculation tools (models) provides functions like creation, initiation, activation, result retrieval, and deletion of a tool.

The GREENPORT2050 platform applies the following design patterns: • Program to an interface and not the implementation
Designing the code to interact with interfaces rather than specific implementations is a practice to facilitate future changes or enhancements without affecting the overall platform.

• Data Access Object pattern
This design pattern is used to abstract and encapsulate the details of data source access, such as databases or APIs, and allows data access changes without affecting the rest of the application.

• API-first approach
Adopting an API-first approach means designing and defining the APIs before delving into the implementation details.By outlining the APIs upfront, clear boundaries and communication channels between different components of the platform are established.
All these practices contribute to the overall quality, maintainability, and scalability of the platform's software.By focusing on interfaces, abstracting data access, and designing APIs before diving into implementation, a solid foundation for a flexible, modular, and well-structured platform is created.

Computation core
To support the architecture of the GREENPORT2050 platform, various technical decisions are taken.The platform is built using a modern state-of-the-art framework: Spring Boot (cf.[6]).This open-source Java framework is widely accepted and well documented, and has a large developer community.Spring Boot offers a lot of functionality to develop and deploy web applications, such as REST controllers and the persistency layer (Hibernate).
As a consequence, the application server business logic of the GREENPORT2050 platform is written with the help of the Spring Boot technology where Java serves as the primary programming language for the back-end.For the front-end development and to implement the Graphical User Interface, the React library (cf.[5]) is chosen.Also React has a large developer community, and many web applications have been realised with it.Hence, the platform is implemented with modern, noncommercial, widely-accepted and proven technologies.
The GREENPORT2050 platform is basically an environment where various types of models can be integrated.Models can be single applications (tools) or composite applications (e.g.first run model A and then model B).Composite applications can be regarded as simple workflows.
The following paragraphs address the core design elements used to create a versatile platform dealing with different levels of integration and interaction.It describes how models are integrated and how the platform can be accessed.

Tools integration and interaction
In the GREENPORT2050 platform's design, a clear distinction is made between the definition of a tool (tool template) and the actual instance of the tool (tool instance).For every tool embedded in the platform, there is a corresponding tool template.This template can be regarded as a description of the tool with typical attributes such as: domain classifier (e.g.noise and gaseous emissions), version, reference to version-control system, owner, parameters, platform identifier (Windows/UNIX), name (unique identifier for tool template), class (for Java this is the Main Class; for third-party executables and scripts this is a so-called SystemBatchTool), and path to the jar file/executable.
Based on the provided tool template, uniquely identified by its template name, it is possible to create a specific instance of the tool.This tool instance represents a personalised real instantiation of the tool and is identified by a unique tool instance name.During the process of creating the tool instance, all the required tool input data must be assigned to it.These input data encompass all the parameters and data/files necessary for the tool to run effectively.Once the tool instance creation is finalised, it can be accessed and referred to using its unique tool instance name.
Every tool instance functions as a container, facilitating interaction with the tool's implementation.This container enables users to initiate the tool's execution, monitor its progress, and, once completed, examine the output.Upon completion of a run (with possible statuses like 'error' or 'finished'), users can download and review the results.All output (log, results, errors) and input data are linked to the tool instance and are made persistent within the platform.The platform employs a datastore (e.g.MySQL database) to store all tool input parameters, as well as input and output files associated with the instances.This approach ensures that data remain accessible and organised, providing a robust and reliable storage solution.This is highly beneficial for quality control as it enables to compare results of new versions of a tool against previous versions, ensuring accuracy and consistency.
It is noted that running a tool immediately after its instance creation is not mandatory.Alternatively, one can prepare tool instances first and execute them at a later time.
All tool instances inside the platform are under control of a so-called tools controller.This controller manages all the currently active (or scheduled) tool instances within the platform, handles tool requests for start, stop and progress, and maintains priority of tool runs.Figure 3 illustrates the tools integration.
To support different levels of integration and interaction with tools, the GREENPORT2050 platform and its tools controller currently have two categories of tool templates 3 : • Third-party tool integration via SystemBatchTool template The third-party tool (script, executable) is used "as is" with only limited control of the tool.• Java tool integration at source code level This is the highest level of integration where the original tool jar-file is untouched and extended with a plugin that must implement the platform's "runner" interface.This interface is used by the tools controller to service methods for run, progress, cancel and status.When the plugin implements these methods, the tools controller has full control over the tool instance.

Tools definition with GOAP
As already mentioned in Subsection 4.1, every tool in the GREENPORT2050 platform must be defined via its tool template.Tool templates can be defined using a simple XML file, but the platform extends this capability to define also relationships between composite tools, utilising the concept of Goal-Oriented Action Planning (GOAP).GOAP originated in the field of artificial intelligence and is widely used in robotics and game development [4].It provides a framework for creating intelligent agents that can autonomously take decisions and actions to achieve specific goals.In GOAP, the system is designed around a set of goals that the agent aims to accomplish.Each goal is defined with a set of conditions that must be satisfied for it to be considered achieved.To accomplish these goals, the agent is equipped with a set of actions or behaviours that it can perform.These actions are defined through preconditions (i.e.conditions that need to be met before the action is executed) and effects (changes the action brings to the platform environment).By evaluating the current state of the platform environment, the available actions and the desired goals, the agent takes the best sequence of actions.GOAP is integrated into the GREENPORT2050 platform and is implemented within the tools controller.Figure 4 shows a GOAP XML definition for a composite tool of ToolA and ToolB.The preconditions (<pre> tag) and the actions (tool named in the ref= attribute) and effects (<effects> tag) must be defined for each tool.
3 Integration of tools at the source code level for non-Java code (i.e.third level of integration) is currently not established  ToolA is activated when pre-conditions ToolA-Par1 and ToolA-File1 are met, producing ToolA-Result.Subsequently, ToolB is automatically initiated upon the creation of ToolA-Result, utilising ToolB-Parameters to generate ToolB-Result.
Within the context of GOAP, there is a notable concept known as the costs metric (<costs> tag).This metric functions as a weight that represents the effort or resources required for performing an action.It helps the tools controller determine the most efficient or the optimal path to reach its desired objectives.The path planner has been implemented according the so-called A*-Star pathfinding algorithm.

Access to platform
User-specific access permissions determine which platform features a logged-in user can access.The GREENPORT2050 platform employs a comprehensive access-rights system, organising users into hierarchical groups for fine-grained control.For instance, a user group can be established for users who only require read-access to specific tool results.Authentication options include LDAP (Lightweight Directory Access Protocol) integration for existing credentials and local storage for independent user management.This combination ensures secure access and meets organisational and demonstration needs.
Access to the GREENPORT2050 platform is provided through three main methods: • Web REST API; • Java Helper API; • Front-end user-friendly web user interface.

4.3.1.
Web REST API.This API is an integral part of the GREENPORT2050 platform, and defines the endpoints that clients can use to send requests and receive responses.This API is implemented as a RESTful API and enables users/developers to interact with the platform programmatically over the web.Users can utilise a variety of standard HTTP methods (such as GET, POST, PUT, and DELETE) to access the different features and services offered by the platform, all in accordance with the principles of REST architecture, which include concepts like statelessness, resources, HTTP methods, and representations.Each RESTful endpoint within the platform is decorated with annotations to support the OpenAPI Specification (OAS), successor of the Swagger specification.OAS is an open standard that provides a structured format for describing RESTful APIs.By using OAS, developers can easily document, design, and visualise the APIs, to support better understanding and interaction with the platform's functionalities.
The platform's web REST API serves multiple purposes and can be utilised for: • Gaining a comprehensive overview of its capabilities through OAS; • Interacting with the web application (React front-end); • Developing custom applications using various languages, such as scripts, Python or MATLAB; • Facilitating integration with the Java Helper API, providing seamless access to the platform for Java applications.

Java Helper API.
The Java Helper API is designed to support Java developers in effortlessly accessing the platform.It offers a set of predefined methods for the following functionalities: • Connecting to the platform; • Obtaining an overview of existing tool templates and tool instances; • Creating a new tool instance and uploading parameters and input files; • Interacting with a tool instance, including starting the tool, retrieving progress information, obtaining status updates, and downloading results.

Conclusions and future work
GREENPORT2050 quantifies the environmental impact at airport level of technologies developed in Clean Sky 2 for fixed-wing aircraft.In order to facilitate an efficient and effective assessment process that consistently produces robust and dependable results, GREENPORT2050 created a versatile computation platform.This platform includes a comprehensive access rights management system and incorporates a structure of model versions with interconnected input and output data, thereby enhancing the quality of the outcomes.This GREENPORT2050 platform is implemented with modern, non-commercial, widely-accepted and proven technologies.It seamlessly integrates environmental-impact models as single tools or composite tools (i.e.workflows).The platform offers three interfaces for accessing models and data: a robust RESTful web API, a Java helper API to support Java developers and a user-friendly web-based interface.The API facilitates model and data integration with external systems and enables sharing with external stakeholders.GREENPORT2050 fruitfully applied the platform for the calculations in its environmental-impact assessments.
The platform already showed its potential for applications beyond its initial domain.Hence, Royal NLR intends to further enhance the platform after the closure of the project; for instance to: • Extend the capabilities of the tools controller using the GOAP concept, with a particular focus on optimising the sequence of tools (GOAP activities) by considering the costs metric; • Implement improved data storage organisation for enhanced data structuring to facilitate users to easily locate specific data of a wide variety of models and their specific input and output data; • Broaden the application of the platform beyond environmental-impact assessments of new aircraft technologies at airport level.In summary, the GREENPORT2050 platform has shown to be an important asset to the GREENPORT2050 project, for it ensures efficient and effective execution of calculations within environmental impact assessments while also automating and proficiently managing quality and configuration-management tasks.Moreover, this platform is already exploited to a broader range of applications in other projects at Royal NLR, even beyond airport-level assessments.Also, it will be reused within the Horizon Europe project "Impact Monitor"4 .
4.3.3.Web user interface.The platform includes an intuitive, easy-to-use web-based interface that allows non-technical users to interact with the embedded tools and data without the need to write code or use APIs directly.The web user interface (React) provides convenient access to tools embedded in the platform.Certain tool specific parts of this interface are dynamically generated, leveraging information from the application server.Figure5gives an impression of a typical overview of the user tool instances within the front-end client.Upon completion, the tool provides reports, logfiles, and results.If the tool status indicates "Finished" without any errors, users can proceed to download the generated results.