# A Method for SWIM-Compliant Human-in-the-Loop Simulation of Airport Air Traffic Management

Authors: Thomas Gräupl; Martin Mayr; Carl-Herbert Rokitansky
Journal: International Journal of Aerospace Engineering
 (2016)

---

## Abstract

System Wide Information Management (SWIM), as envisioned by theSingle European Sky Air Traffic Management Research (SESAR) program, is the application of service oriented architectures to the air traffic management domain. Service oriented architectures are widely deployed in business and finance but usually tied to one specific technological implementation. SWIM goes one step further by defining only the semantic layer of the application integration and leaving the implementation of the communication layer open to the implementer. The shift from legacy communication patterns to SWIM is fundamental for the expected evolution of air traffic management in the next decades. However, the air traffic management simulators currently in use do not reflect this yet. SWIM compliance is defined by semantic compatibility to theAir Traffic Management Information Reference Model (AIRM) and a SWIM service may implement one or more communication profiles, which specify a communication layer implementation. This work proposes a SWIM-compliant communication profile suitable to integrate SWIM-compliant tools into human-in-the-loop simulations for air traffic management research. We achieve this objective by implementing a SWIM communication profile using XML-based multicast messaging and extending the message format to support distributed human-in-the-loop simulations. We demonstrate our method by the evaluation of Hamburg Airport operations.


---

## Body

## 1. Introduction

The way air traffic management information is exchanged between stakeholders is changing. Legacy point-to-point connections and proprietary data formats as shown in Figure1(a) shall be replaced bySystem Wide Information Management (SWIM) as illustrated in Figure 1(b). SWIM is the technical term for service oriented architectures in the air traffic management domain. Service oriented architectures are an approach to the integration of heterogeneous systems that is widely deployed in the industry [1]. SWIM was envisioned by theSingle European Sky Air Traffic Management Research (SESAR) program. This program defines a framework for the sustainable modernization of the European air transportation system. It aims to increase capacity, improve safety, and reduce environmental footprint and costs. The improvement of air traffic management procedures by embracing SWIM [2] and automation [3] shall be one of the key enablers to achieve these objectives.Figure 1
(a) The currentAir Traffic Management (ATM) systems use legacy point-to-point connections with proprietary data formats. (b) This shall be replaced by the SWIM service oriented architecture for air traffic management.
(a)
(b)Changing the way air traffic management information is shared will also fundamentally change how air traffic management is performed. However, changes of air traffic management procedures and tools need to be evaluated carefully, often by simulation, before they are applied. Zellweger [4] identifies several stages from the early exploration of new concepts to the final evaluation of air traffic management procedures and support tools. All but the final stage involve the use of simulation for safety and cost reasons. The effects of potential changes are first assessed with fast-time simulations. Secondly, the details of the concept are explored with real-time simulations and evaluated in human-in-the-loop simulations. Only in the final stage real-world operations are considered in the form of shadow mode operations (in shadow mode operations, the new procedure is conducted in parallel to the established procedure). Human-in-the-loop simulations therefore provide an important contribution to the identification of the strengths and weaknesses of new air traffic management procedures and tools.In this vein, Kaltenhäuser [5] identified the need to support standard air traffic control interfaces as an important quality of a flexible air traffic management simulation environment. Flexible, easy to adapt interface software was thus identified as a primary task for further research. Adelantado [6] addressed the use of standard interfaces by the use of theHigh Level Architecture(HLA) to implement a distributed airport simulation environment for the French Aerospace Research Center ONERA. The simulation was implemented with HLA federates, each simulating different aspects of the airport environment, connected to a central HLA runtime infrastructure. However, HLA was not universally accepted. Prevot et al. [7] indicate that the NASA Ames Research Airspace Operation Laboratory was implemented on the basis of the “Aeronautical Data Link and Radar Simulator” communication network and Edinger and Schmitt [8] report that the German Aerospace Center DLR implemented its air traffic management simulation environment on the basis of a client-server approach employing a “Data Pool” server process as communication hub. Shifeng and Danxia [9] developed a cost-effective approach to constructing a flight control tower simulation using commercial-of-the-shelf hardware. They also introduced the use of multicast to distribute simulation state encoded in “primitive commands” proprietary to their implementation.A lot of work has thus gone into the creation of flexible and easy to adapt simulation interface software, but the support of standard air traffic control interfaces has not yet been fully realized. One major reason for this is certainly the multitude of legacy point-to-point connections and data formats used by air traffic management systems. However, we argue that with the specification of SWIM an opportunity to support a universal standard air traffic control interface becomes available. In addition, new air traffic management procedures and software will have to be SWIM-compliant and should therefore be evaluated in a SWIM-compliant environment. In our view, air traffic management simulation environments shall therefore support SWIM’sAir Traffic Management Information Reference Model (AIRM) and SWIM’s message passing based communication pattern to evaluate proposed air traffic management procedures and tools in a realistic simulation environment. SWIM compliance is achieved by supporting the AIRM semantic [10].The objective of this paper is to present a SWIM-compliant method for human-in-the-loop air traffic management simulation that (1) uses the air traffic management information reference model as semantic interface, (2) uses multicast message passing as communication interface, and (3) therefore enables the evaluation of SWIM-compliant air traffic management software in complex simulation scenarios. The SWIM AIRM is already intended for real-time information sharing and can therefore be extended to support human-in-the-loop simulation. Using message passing for communication supports the integration of existing SWIM-compliant air traffic management tools. In addition, the use of multicast is attractive because it is efficient and offers the additional opportunity to replace the client-server architectures of the current simulation environments with a decentralized approach not requiring centralized simulation infrastructure.The application of our method is demonstrated with human-in-the-loop simulation experiments evaluating airport operations at the Hamburg Airport. The experiments discussed in this paper were originally performed in the context of the SESAR Work Package E Project “Zero Failure Management at Maximum Productivity in Safety Critical Control Rooms” (ZeFMaP) by Zeh et al. [11] but were extended to produce the results presented in this paper. The objective of the extended simulation experiments was to capture the decision process of the human air traffic controllers in a rule-based model that shall provide the basis for the development of automated support tools for airport operations.


## 2. Definitions

In this paper we follow Stal [12] in the view that service oriented architectures are loosely coupled “software islands” with a common semantic layer interconnected through a communication layer. The communication interface may have several different implementations.Glickman [13] defines SWIM as the application of the service oriented architecture approach to the air traffic management domain. Instead of developing and implementing specific solutions for sharing data between application pairs, SWIM specifies a semantic model, common infrastructure, and set of processes for sharing and managing data in the air traffic system.According to Wilson et al. [10] particular implementation isSWIM-compliant, if its entities and their properties can be mapped to the semantic AIRM information reference model defined by SESAR. A SWIM service need not implement the complete semantic model. It is sufficient to implement the relevant parts of the semantic model. SWIM compliance does also not depend on a specific implementation of the communication layer. Any communication layer available to the SWIM services is acceptable.


## 3. Background on SWIM

The air traffic management system is considered one of the most complex systems ever built, but many parts of it were not designed to be integrated with each other. This leads to a multitude of point-to-point connections between its subsystems using proprietary data formats.SESAR aims to bridge this interoperability gap by the introduction of service oriented architectures into the air traffic domain. The SWIM service oriented architecture shall provide the infrastructure, data formats, and protocols to share information between all air traffic management subsystems in a scalable and interoperable way. SESAR defines the semantic layer of SWIM in the AIRM information reference model as described by Wilson et al. [10]. In the communications layer it specifies the integration of air traffic management applications by message passing systems. Applications are outfitted with an interface to the message passing system and the message exchange within the system is handled by message brokers, which can scale from local software libraries to federated networks of broker servers shown in Figure 2(a). The actual implementation of the messaging protocol and message brokers may vary and is open to the implementer.Figure 2
(a) The SESAR SWIM infrastructure is implemented by aWide Area Network (WAN) of message brokers implementing several communication profiles. (b) Our method replaces the SWIM infrastructure with alocal area multicastnetwork (LAN) and the X23 communication profile.
(a)
(b)As of now, three SWIM implementation profiles have been defined by SESAR. The “yellow profile” utilizes theHypertext Transfer Protocol (HTTP) as communication protocol with XML message formats defined in theWeb Services Description Language (WSDL). The “blue profile” utilizes theData Distribution System (DDS) protocol with a binary message format. The “purple profile” utilizes theAdvanced Message Queuing Protocol (AMQP) as communication protocol with message formats defined in the web services description language.The SWIM implementation profiles developed in SESAR are intended for pan-European operational use. They are complex to implement and not intended for simulation environments. It is therefore not always possible to use them within the time and budget constraints of research projects.Our method, called X23 (in this paper we use the name “X23” interchangeably for the presented approach, communication profile, and its software implementations), is simplified implementation of SWIM suitable for research and laboratory trials. We designed a scaled-down implementation with analogous information sharing capabilities but extended for event-driven simulations. Our implementation does not provide the same WAN scalability, security, and safety mechanisms as the pan-European SWIM network but provides semantic compatibility according to [10]. It can thus be understood as a LAN-scale research-oriented SWIM profile with extensions for human-in-the-loop simulation.X23 integrates SWIM-compliant simulation and air traffic management tools through a multicast messaging protocol as illustrated in Figure2(b). Assuming wall-clock time aligned simulation-time, as is usually the case with human-in-the-loop simulations, our approach does not require the configuration of a central instance for coordination. Shared simulation state is injected into the multicast group for distribution; each simulation tool can then extract the required information from the common information pool. Using IP multicast for this purpose has the advantage that it is natively supported without configuration in local area networks as they are commonly deployed. No reconfiguration is required when moving to a different network. Within the IP multicast group a domain specific XML message format is used to represent the simulation state.


## 4. Method for SWIM-Compliant Human-in-the-Loop Simulation

Our X23 SWIM implementation utilizes a simple, layered, and distributed architecture based on the OSI reference model. It has been implemented as a software library in the Java and Delphi programing languages. The Java library has been used from within MATLAB by Hauf et al. [14]. A C++ implementation is under development by the authors.The implementation covers the protocol stack from the application layer down to the network layer as illustrated in Figure3. The application layer implements the interface between the simulation application and the X23 stack. This interface may be realized in different ways depending on the type of the application. The presentation layer covers the encoding of state changes in a machine-readable, platform-independent XML representation. The session layer of the stack establishes logical sessions that are robust against communication interruptions or restarted simulation processes. The transport layer encapsulates the XML information of the upper layers for end-to-end transmission between the connected processes. Finally, the network layer and the layers below take care of the actual multicast transmission over the network.Figure 3
The X23 implementation covers the protocol stack from the application layer down to the network layer. The application layer implements the interface between the application and the X23 stack. The presentation layer covers the encoding of state changes in XML messages. The session layer establishes logical sessions robust against communication interruptions. The transport layer encapsulates messages inUser Datagram Protocol (UDP) datagrams. The network layer and Ethernet take care of the actual multicast transmission.The application layer interface is specific to the application but provides access to the same distributed AIRM-compliant semantics and information for all applications. The interface uses a local object cache storing and merging the state of the distributed objects. This cache is constantly updated with the messages coming from the lower layers of the X23 stack. The actual information is condensed into objects implementing AIRM entities, for example, flight objects, airport objects, or runway objects.These objects are presented to the applications through a simple application interface or plugin realizing the message patterns specified for SWIM. Note that although SESAR specifies several message patterns, only two are actually used in the currently defined profiles: subscribe/notify and request/response. The application interface has thus only to support these two modes of operation. In many cases only one message pattern is required by a particular application.Received messages are translated into AIRM-compliant objects and stored in the local object cache. Messages concerning the same object cause the object in the cache to be updated. This applies also to messages providing partial updates. If messages from different sources are received, this results in a transparent fusion of the information. Different sources may update the same attribute. However, in this work information fusion has only been used for updates of different attributes of the same object. This allowed X23 SWIM services and simulation modules to augment objects generated by different modules with additional information.


### 4.1. Message Format

Within our X23 stack, updates to the AIRM objects are implemented by simulation events distributed over the network as XML elements of the form:<event_or_command attribute1="…"attribtute2="…"… />.Each XML element corresponds naturally to one simulation event or simulation command. The properties of the event or command are reported in the attributes of the XML element.Simulation events report property changes of AIRM entities. The XML representation of the simulation events is analogous to the life cycle of the simulated objects as shown in Figure4. Objects are created, used, and finally deallocated. A simulation module processing only selected simulation objects subscribes to these objects by accepting only messages reporting changes of these objects. This is best illustrated with an example: each simulated flight is represented in the simulation by a flight object the attributes of which can be traced back to the properties of the AIRM flight entity. A simulation module processing flight objects subscribes to the <create_flight … />, <set_flight … />, and <delete_flight … /> messages. The creation of a new simulated flight is presented by a <create_flight … /> message. This message has various attributes like the position of the flight, its departure airport, its arrival airport, and several others defined in the air traffic management information reference model. Analogous messages are defined for other AIRM entities, for example, airport entities or runway entities.Figure 4
The life cycle of X23 objects in the object cache. Object creation is triggered by create_object messages, attributes are updated according to set_object messages, and objects deletion is finally caused by delete_object messages. As optimization cached objects may also be updated by create_object messages.Simulation events conveyingController-Pilot Data Link Communication (CPDLC is used to exchange clearances for the progress of the flight between the pilot and the air traffic controller via air-ground data link) follow the request/response message pattern and are represented by <cpdlc_message … /> messages based on the FANS-1/A message definitions. FANS-1/A is an international standard (specified in ARINC 622 and EUROCAE ED-100/RTCADO-258) for CPDLC that is not part of SWIM. Each message is specified by a unique identifier and its parameters.Simulation commands are messages used for the coordination of the simulation environment. They are also not part of SWIM, but an extension introduced in our implementation. As our simulation environment is only intended for wall-clock time aligned human-in-the-loop simulations the simulation commands could be restricted to a small set of messages. Five commands are supported:start,restart,pause,resume, andstop.Start andstop are only used to initialize or shut down the simulation environment remotely.Restart causes all simulation processes to reinitialize and clear their object cache.Pause andresume allow pausing human-in-the-loop simulations without losing the current simulation state.Examples of X23 messages can be found in the Appendix of this paper.


### 4.2. SWIM-Compliance

Our method implements the relevant entities of AIRM in X23 classes. For illustrational purposes the semantic trace of two fields of the X23 Runway class to the corresponding attributes of the AIRM runway entity is displayed in Figure5.Figure 5
Semantic trace of theid andairport_id fields of the X23 Runway class to the corresponding attributes of the AIRM runway entity (top two arrows in diagram). This mapping provides evidence for the “level 2” SWIM-compliance the X23 Runway class. The semantic trace of the X23 Runway class to the AIRM runway entity would only have provided evidence for “level 1” compliance (bottom arrow in diagram).A semantic trace of the X23 classes to entities of AIRM constitutes a formal proof of “level 1” SWIM-compliance according to Wilson et al. [10]. A semantic trace of the fields of the X23 classes to the attributes of AIRM entities is a proof of “level 2” SWIM compliance.Figure5 provides thus evidence for the “level 2” SWIM compliance of two fields of the X23 Runway class. Note that the object under assessment need not implement all entities and attributes specified in the reference model and may have additional attributes, for example, for simulation purposes that may be ignored.


### 4.3. Interfacing with SWIM-Compliant Applications

The interface of an application with particular SWIM implementation is application-dependent. It follows, however, the logical approach that is central to the SWIM concept: application layer events are mapped to messages of the communication layer according to a common semantic model. The properties of the application layer event, AIRM entity state changes, are mapped to the message format of the communication profile. This is always possible as SWIM-compliant applications and communication profiles must follow the AIRM semantics. It is not necessary to change the application logic for this purpose. However, it is required to add mapping logic.In the case of X23 this means that it is required to implement a bridge between theApplication Programming Interface (API) of the SWIM application and the X23 stack mapping AIRM entities and attributes to X23 objects and fields. Requests and responses are directly mapped to messages. Entity state changes are applied to the local object cache triggering the distribution of the event by X23.


### 4.4. Multicast Communication Protocol

The X23 network layer uses IP multicast over Ethernet. The rationale for using multicast is threefold: first, multicast is the most efficient way to exchange information between multiple nodes without a central node in a local area network. Secondly, using multicast enables self-configuring deployment. All simulation modules join the same local IP multicast group and listen on the same port for messages. This is the only required configuration and can be performed automatically and independently from the actual configuration of the simulation network. If stateless autoconfigured IP addresses are provided by the operating system, a deployment network is not required and the simulation hosts can be connected directly. This is of advantage if simulation experiments need to be performed with partner institutions that cannot allow external parties access to their internal networks. Thirdly, using multicast offers additional flexibility in setting up the simulation environment as simulation nodes may join and leave the network during runtime without the need to reconfigure other nodes.At the transport layer UDP is used. At reception the XML messages are extracted from the received multicast UDP datagram and checked against a regular expression for syntactic integrity. If the message is invalid, the message is discarded with logging. Each XML message is tagged with a unique sequence number and source identifier. XML messages may be reordered or duplicated if applications are deployed on multihomed hosts (in practice this typically happens when simulation modules are deployed in virtual machines, which create additional (virtual) network interfaces on the host). Thus, the X23 transport layer protocol on top of UDP provides the deduplication of XML elements and filtering according to the application’s subscription.The X23 transport protocol header is transparently added as additional XML attributes. It comprises four fields:<event_or_command source="…"sequence_number ="…"sender_uid="…"/>. The event_or_command field specifies the type of the object conveyed in the message. It may indicate either a state change of a simulation object or a simulation command. The source field indicates the logical source (e.g., HMI and air traffic simulation) of the message to allow filtering without knowing the identity of the sending process. The sequence_number and sender_uid fields uniquely identify the message in the network. The sequence_number is incremented for each message that is not a retransmission. The sender_uid is a hash value uniquely identifying the process generating the message as several processes may implement the same logical source, for example, multiple HMI instances.Messages following the request/response pattern are sent using acknowledgements, because single messages can get lost or be corrupted from time to time. A request/response is transmitted by the X23 transport layer until it is acknowledged by the desired receiver identified in the source field, or the maximum number of retransmissions is reached. A message is considered acknowledged if at least one acknowledgement message is received. Note that this protocol does not support acknowledgements from multiple receivers for now. The acknowledgement message is implemented as an X23 message, because UDP does not support transport layer acknowledgements. The acknowledgment message is a XML message with thesequence_number and sender_uid of the original message and the source of the receiver. This allows the sender of the request/response to identify the acknowledgement unambiguously and other receivers to discard it silently. The acknowledgment message is not forwarded to the upper layers of the stack and not identical to the response to a request that is often called “logical acknowledgement,” which is a higher layer message.Messages available through the subscribe/notify message pattern are sent unacknowledged and are never retransmitted as the session layer redistributes them in regular intervals as described in the next paragraph.The session layer uses a soft-state pattern allowing restarted simulation applications to recover lost simulation state. This is realized by redistributing the essential parts of the simulation state needed for recovery in regular intervals. In the case of flight objects this is implemented by the retransmission of the complete state vector of all flight objects currently in the simulation through newly generated<create_flight … />  messages every thirty seconds. Retransmissions for individual flights are randomly offset to avoid message bursts. Airport and runway information is retransmitted in an analogous way. This applies to all information available through the subscribe/notify message pattern. Request/response messages may be retransmitted several times to recover from lost packets but have to be reinitialized if the session breaks.The presentation layer takes care of the creation and updating of X23 objects according to the received messages. The objects are stored in a local object cache accessible by the application layer.The application layer notifies SWIM services and simulation modules of received requests, responses, or state changes according to the application-specific SWIM-compliant interface.The processing of received X23 messages is illustrated in Figure6. The processing of transmitted X23 messages is performed analogously and in reverse order.Figure 6
Processing of received messages in the X23 stack.


## 4.1. Message Format

Within our X23 stack, updates to the AIRM objects are implemented by simulation events distributed over the network as XML elements of the form:<event_or_command attribute1="…"attribtute2="…"… />.Each XML element corresponds naturally to one simulation event or simulation command. The properties of the event or command are reported in the attributes of the XML element.Simulation events report property changes of AIRM entities. The XML representation of the simulation events is analogous to the life cycle of the simulated objects as shown in Figure4. Objects are created, used, and finally deallocated. A simulation module processing only selected simulation objects subscribes to these objects by accepting only messages reporting changes of these objects. This is best illustrated with an example: each simulated flight is represented in the simulation by a flight object the attributes of which can be traced back to the properties of the AIRM flight entity. A simulation module processing flight objects subscribes to the <create_flight … />, <set_flight … />, and <delete_flight … /> messages. The creation of a new simulated flight is presented by a <create_flight … /> message. This message has various attributes like the position of the flight, its departure airport, its arrival airport, and several others defined in the air traffic management information reference model. Analogous messages are defined for other AIRM entities, for example, airport entities or runway entities.Figure 4
The life cycle of X23 objects in the object cache. Object creation is triggered by create_object messages, attributes are updated according to set_object messages, and objects deletion is finally caused by delete_object messages. As optimization cached objects may also be updated by create_object messages.Simulation events conveyingController-Pilot Data Link Communication (CPDLC is used to exchange clearances for the progress of the flight between the pilot and the air traffic controller via air-ground data link) follow the request/response message pattern and are represented by <cpdlc_message … /> messages based on the FANS-1/A message definitions. FANS-1/A is an international standard (specified in ARINC 622 and EUROCAE ED-100/RTCADO-258) for CPDLC that is not part of SWIM. Each message is specified by a unique identifier and its parameters.Simulation commands are messages used for the coordination of the simulation environment. They are also not part of SWIM, but an extension introduced in our implementation. As our simulation environment is only intended for wall-clock time aligned human-in-the-loop simulations the simulation commands could be restricted to a small set of messages. Five commands are supported:start,restart,pause,resume, andstop.Start andstop are only used to initialize or shut down the simulation environment remotely.Restart causes all simulation processes to reinitialize and clear their object cache.Pause andresume allow pausing human-in-the-loop simulations without losing the current simulation state.Examples of X23 messages can be found in the Appendix of this paper.


## 4.2. SWIM-Compliance

Our method implements the relevant entities of AIRM in X23 classes. For illustrational purposes the semantic trace of two fields of the X23 Runway class to the corresponding attributes of the AIRM runway entity is displayed in Figure5.Figure 5
Semantic trace of theid andairport_id fields of the X23 Runway class to the corresponding attributes of the AIRM runway entity (top two arrows in diagram). This mapping provides evidence for the “level 2” SWIM-compliance the X23 Runway class. The semantic trace of the X23 Runway class to the AIRM runway entity would only have provided evidence for “level 1” compliance (bottom arrow in diagram).A semantic trace of the X23 classes to entities of AIRM constitutes a formal proof of “level 1” SWIM-compliance according to Wilson et al. [10]. A semantic trace of the fields of the X23 classes to the attributes of AIRM entities is a proof of “level 2” SWIM compliance.Figure5 provides thus evidence for the “level 2” SWIM compliance of two fields of the X23 Runway class. Note that the object under assessment need not implement all entities and attributes specified in the reference model and may have additional attributes, for example, for simulation purposes that may be ignored.


## 4.3. Interfacing with SWIM-Compliant Applications

The interface of an application with particular SWIM implementation is application-dependent. It follows, however, the logical approach that is central to the SWIM concept: application layer events are mapped to messages of the communication layer according to a common semantic model. The properties of the application layer event, AIRM entity state changes, are mapped to the message format of the communication profile. This is always possible as SWIM-compliant applications and communication profiles must follow the AIRM semantics. It is not necessary to change the application logic for this purpose. However, it is required to add mapping logic.In the case of X23 this means that it is required to implement a bridge between theApplication Programming Interface (API) of the SWIM application and the X23 stack mapping AIRM entities and attributes to X23 objects and fields. Requests and responses are directly mapped to messages. Entity state changes are applied to the local object cache triggering the distribution of the event by X23.


## 4.4. Multicast Communication Protocol

The X23 network layer uses IP multicast over Ethernet. The rationale for using multicast is threefold: first, multicast is the most efficient way to exchange information between multiple nodes without a central node in a local area network. Secondly, using multicast enables self-configuring deployment. All simulation modules join the same local IP multicast group and listen on the same port for messages. This is the only required configuration and can be performed automatically and independently from the actual configuration of the simulation network. If stateless autoconfigured IP addresses are provided by the operating system, a deployment network is not required and the simulation hosts can be connected directly. This is of advantage if simulation experiments need to be performed with partner institutions that cannot allow external parties access to their internal networks. Thirdly, using multicast offers additional flexibility in setting up the simulation environment as simulation nodes may join and leave the network during runtime without the need to reconfigure other nodes.At the transport layer UDP is used. At reception the XML messages are extracted from the received multicast UDP datagram and checked against a regular expression for syntactic integrity. If the message is invalid, the message is discarded with logging. Each XML message is tagged with a unique sequence number and source identifier. XML messages may be reordered or duplicated if applications are deployed on multihomed hosts (in practice this typically happens when simulation modules are deployed in virtual machines, which create additional (virtual) network interfaces on the host). Thus, the X23 transport layer protocol on top of UDP provides the deduplication of XML elements and filtering according to the application’s subscription.The X23 transport protocol header is transparently added as additional XML attributes. It comprises four fields:<event_or_command source="…"sequence_number ="…"sender_uid="…"/>. The event_or_command field specifies the type of the object conveyed in the message. It may indicate either a state change of a simulation object or a simulation command. The source field indicates the logical source (e.g., HMI and air traffic simulation) of the message to allow filtering without knowing the identity of the sending process. The sequence_number and sender_uid fields uniquely identify the message in the network. The sequence_number is incremented for each message that is not a retransmission. The sender_uid is a hash value uniquely identifying the process generating the message as several processes may implement the same logical source, for example, multiple HMI instances.Messages following the request/response pattern are sent using acknowledgements, because single messages can get lost or be corrupted from time to time. A request/response is transmitted by the X23 transport layer until it is acknowledged by the desired receiver identified in the source field, or the maximum number of retransmissions is reached. A message is considered acknowledged if at least one acknowledgement message is received. Note that this protocol does not support acknowledgements from multiple receivers for now. The acknowledgement message is implemented as an X23 message, because UDP does not support transport layer acknowledgements. The acknowledgment message is a XML message with thesequence_number and sender_uid of the original message and the source of the receiver. This allows the sender of the request/response to identify the acknowledgement unambiguously and other receivers to discard it silently. The acknowledgment message is not forwarded to the upper layers of the stack and not identical to the response to a request that is often called “logical acknowledgement,” which is a higher layer message.Messages available through the subscribe/notify message pattern are sent unacknowledged and are never retransmitted as the session layer redistributes them in regular intervals as described in the next paragraph.The session layer uses a soft-state pattern allowing restarted simulation applications to recover lost simulation state. This is realized by redistributing the essential parts of the simulation state needed for recovery in regular intervals. In the case of flight objects this is implemented by the retransmission of the complete state vector of all flight objects currently in the simulation through newly generated<create_flight … />  messages every thirty seconds. Retransmissions for individual flights are randomly offset to avoid message bursts. Airport and runway information is retransmitted in an analogous way. This applies to all information available through the subscribe/notify message pattern. Request/response messages may be retransmitted several times to recover from lost packets but have to be reinitialized if the session breaks.The presentation layer takes care of the creation and updating of X23 objects according to the received messages. The objects are stored in a local object cache accessible by the application layer.The application layer notifies SWIM services and simulation modules of received requests, responses, or state changes according to the application-specific SWIM-compliant interface.The processing of received X23 messages is illustrated in Figure6. The processing of transmitted X23 messages is performed analogously and in reverse order.Figure 6
Processing of received messages in the X23 stack.


## 5. Application to Human-in-the-Loop Simulation of EDDH Airport Air Traffic Management

The simulation experiments illustrating the application of our method were originally performed within SESAR Work Package E. The project was called “Zero Failure Management at Maximum Productivity in Safety Critical Control Rooms” (ZeFMaP). It investigated effects of theFailure Mode and Effects Analysis (FMECA) productivity improvement processes on the performance of air traffic management as reported by Zeh et al. [11].The objective of the simulations was to provide the test-subjects of the study, trained air traffic controllers, with a realistic environment to assess the improvement process under evaluation. This was accomplished by the detailed simulation of the Hamburg (EDDH) Airport, the interactive simulation of realistic air traffic, and the integration of commercial air traffic control tools into an authentic control room environment and workflow. The simulation scenario and control room environment are described in detail in the Appendix of this paper.The previous work was extended to produce the results presented in this paper. The objective was to increase knowledge on how the air traffic management performance of the human controllers can be understood and modeled with the intention to develop automatic decision support tools in the future. To this end, the same scenarios were executed with a rule-based simulated controller replacing the human controllers.The study was conducted using commercial-of-the-shelf air traffic management software. Controllers managed aircraft by entering messages into the air traffic management tool, and the interactive air traffic simulation responded in the same manner. All simulation modules and tools were connected through our X23 SWIM implementation.


### 5.1. Integration of COTS and Custom Air Traffic Management Software

The simulation experiments used a combination of academic simulation tools and commercially available air traffic management software deployed on commercial-of-the-shelf hardware. The NAVSIM research air traffic simulator (developed by “Mobile Communications R&D GmbH, Salzburg” in cooperation with University of Salzburg) was used for the interactive simulation of realistic air traffic. The controllers taking part in the experiment used the commercially available smartStrips electronic flight strips tool (developed by Frequentis AG) as human machine interface to interact with the simulated air traffic. smartStrips was augmented by a simulated radar display (NAVSIM ATC, developed by “Mobile Communications R&D GmbH, Salzburg,” in cooperation with University of Salzburg) and a generic arrival/departure manager (developed by the University of Salzburg) shown on auxiliary screens. The human controllers were also provided with a virtual tower view based on the graphics engine of the X-Plane simulation software (developed by Laminar Research). This virtual tower view was projected onto a 270° cylindrical screen.The interface to X23 was implemented differently for each application. The NAVSIM simulator was extended with an X23 interface by the addition of mapping logic mediating between its internal representation of AIRM entities and X23 objects. The interface between smartStrips and X23 was implemented in a bridge class extending the smartStrips application with similar mapping logic. Frequentis AG provided guidance and compiled Java classes for this purpose. The generic arrival/departure manager was built directly on top of the X23 object cache. No mapping was therefore required in this case. The X-Plane software supports plugins that can be loaded at runtime. The X23 bridge was thus implemented by compiling the X23 stack and the required mapping logic into an X-Plane plugin. In all three cases the implementation of the mapping logic was straightforward as it concerned only the mediation between objects implementing the same semantic model.The information flow between the simulation components is illustrated in Figure7. NAVSIM ATC, smartStrips, and the arrival/departure manager are actually present five times in the experiment setup, once for each human controller. The virtual tower application is present four times, once for each projector to achieve a 270° field of view. Note that the update messages of the simulation events and commands were not only distributed over the network, but also stored in log files for further analysis. All computers in the network were synchronized via NTP to have consistent time-stamps in the log files.Figure 7
Logical information flow in the simulation’s X23 SWIM network for the EDDH scenario. Flight and airport objects are distributed in the subscribe/notify message pattern. Commands follow the request/response message pattern. The shaded HMI was later replaced with a simulated controller.


### 5.2. Simulated Controller

In the extended experiment the human controllers were replaced by a rule-based simulated controller. Note that the only necessary change to the simulation setup was to replace the smartStrips tool by the simulated controller. Due to the SWIM-based simulation network, no changes to the other parts of the simulation were required.The rules for the simulated controller were derived from the controller training material of Hamburg Airport which take specific aspects of the airport into account. The selection of the appropriate departure runway holding point was based on taxi time duration, aircraft type, and available runway takeoff length. The issuing of engine start-up clearances was based on taxi time duration and calculated takeoff time taking the current airport situation into account; that is, the rules were formulated to issue “just in-time” start-up clearances to avoid unnecessary fuel consumption, reduce CO2 emissions, and avoid congestion at runway holding points. Runway line-up sequencing was then performed on the basis of the calculated takeoff time. The takeoff clearance was issued according to the wake classes of previously departing, arriving, or landing aircraft. If reassignments of the gates and parking positions were necessary, they were calculated during the approach phase on the basis of the currently available gates and the wingspan of the aircraft. Landing clearances were issued taking currently departing and arriving aircraft into account. The taxi routes of arriving aircraft were calculated to minimize the taxi time duration in the current airport situation. This included runway crossing clearances giving way to landing and departing aircraft.The key performance indicators of the taxiing performance of the human and simulated controllers for one selected simulation scenario are displayed in Table1.Table 1
Controller performance for EDDH “high traffic” scenario, 60 A/C per hour, 1 h duration.
Human controllers
Simulated controller
Avg.
Stdev.
Avg.
Stdev.
Delay (departures)
−64.78
446.06
10.55
145.66
s
Taxi time (arrivals)
253.24
61.95
295.37
20.44
s
Taxi time (departures)
141.69
38.38
135.77
39.27
s
Taxi distance (arrivals)
2372.48
393.47
2547.56
225.55
m
Taxi distance (departures)
1887.56
324.5
1795.91
324.10
m


## 5.1. Integration of COTS and Custom Air Traffic Management Software

The simulation experiments used a combination of academic simulation tools and commercially available air traffic management software deployed on commercial-of-the-shelf hardware. The NAVSIM research air traffic simulator (developed by “Mobile Communications R&D GmbH, Salzburg” in cooperation with University of Salzburg) was used for the interactive simulation of realistic air traffic. The controllers taking part in the experiment used the commercially available smartStrips electronic flight strips tool (developed by Frequentis AG) as human machine interface to interact with the simulated air traffic. smartStrips was augmented by a simulated radar display (NAVSIM ATC, developed by “Mobile Communications R&D GmbH, Salzburg,” in cooperation with University of Salzburg) and a generic arrival/departure manager (developed by the University of Salzburg) shown on auxiliary screens. The human controllers were also provided with a virtual tower view based on the graphics engine of the X-Plane simulation software (developed by Laminar Research). This virtual tower view was projected onto a 270° cylindrical screen.The interface to X23 was implemented differently for each application. The NAVSIM simulator was extended with an X23 interface by the addition of mapping logic mediating between its internal representation of AIRM entities and X23 objects. The interface between smartStrips and X23 was implemented in a bridge class extending the smartStrips application with similar mapping logic. Frequentis AG provided guidance and compiled Java classes for this purpose. The generic arrival/departure manager was built directly on top of the X23 object cache. No mapping was therefore required in this case. The X-Plane software supports plugins that can be loaded at runtime. The X23 bridge was thus implemented by compiling the X23 stack and the required mapping logic into an X-Plane plugin. In all three cases the implementation of the mapping logic was straightforward as it concerned only the mediation between objects implementing the same semantic model.The information flow between the simulation components is illustrated in Figure7. NAVSIM ATC, smartStrips, and the arrival/departure manager are actually present five times in the experiment setup, once for each human controller. The virtual tower application is present four times, once for each projector to achieve a 270° field of view. Note that the update messages of the simulation events and commands were not only distributed over the network, but also stored in log files for further analysis. All computers in the network were synchronized via NTP to have consistent time-stamps in the log files.Figure 7
Logical information flow in the simulation’s X23 SWIM network for the EDDH scenario. Flight and airport objects are distributed in the subscribe/notify message pattern. Commands follow the request/response message pattern. The shaded HMI was later replaced with a simulated controller.


## 5.2. Simulated Controller

In the extended experiment the human controllers were replaced by a rule-based simulated controller. Note that the only necessary change to the simulation setup was to replace the smartStrips tool by the simulated controller. Due to the SWIM-based simulation network, no changes to the other parts of the simulation were required.The rules for the simulated controller were derived from the controller training material of Hamburg Airport which take specific aspects of the airport into account. The selection of the appropriate departure runway holding point was based on taxi time duration, aircraft type, and available runway takeoff length. The issuing of engine start-up clearances was based on taxi time duration and calculated takeoff time taking the current airport situation into account; that is, the rules were formulated to issue “just in-time” start-up clearances to avoid unnecessary fuel consumption, reduce CO2 emissions, and avoid congestion at runway holding points. Runway line-up sequencing was then performed on the basis of the calculated takeoff time. The takeoff clearance was issued according to the wake classes of previously departing, arriving, or landing aircraft. If reassignments of the gates and parking positions were necessary, they were calculated during the approach phase on the basis of the currently available gates and the wingspan of the aircraft. Landing clearances were issued taking currently departing and arriving aircraft into account. The taxi routes of arriving aircraft were calculated to minimize the taxi time duration in the current airport situation. This included runway crossing clearances giving way to landing and departing aircraft.The key performance indicators of the taxiing performance of the human and simulated controllers for one selected simulation scenario are displayed in Table1.Table 1
Controller performance for EDDH “high traffic” scenario, 60 A/C per hour, 1 h duration.
Human controllers
Simulated controller
Avg.
Stdev.
Avg.
Stdev.
Delay (departures)
−64.78
446.06
10.55
145.66
s
Taxi time (arrivals)
253.24
61.95
295.37
20.44
s
Taxi time (departures)
141.69
38.38
135.77
39.27
s
Taxi distance (arrivals)
2372.48
393.47
2547.56
225.55
m
Taxi distance (departures)
1887.56
324.5
1795.91
324.10
m


## 6. Discussion

Air traffic management tools and procedures will increasingly interface using SWIM. It is therefore important to evaluate them in a realistic SWIM-compliant simulation environment to ascertain the validity of the results. Our work shows that extending the SWIM air traffic information reference model to include simulation specific information is straightforward and does not conflict with SWIM-compliance. The benefits of using SWIM as simulation interface were demonstrated with the integration of commercial air traffic management software into our research simulation.Our method and X23 SWIM implementation were applied to human-in-the-loop simulation experiments investigating the application of productivity improvement processes to air traffic management and evaluating a rule-based controller model against the performance of human air traffic controllers.The comparison of key performance indicators of the air traffic management performance indicates a good agreement of the rule-based model with the human controller performance. It is, however, noteworthy that the rule-based model accrued significantly later off-block times than the human controllers. The controllers would typically plan ahead and let aircraft leave the gate shortly before their planned departure times. This was not reflected in the simulated controller rules as they were formulated with the intent to meet the calculated takeoff times as precisely as possible.The flexibility of our multicast communication approach proved of great practical value. Joining and removing simulation nodes at runtime were helpful in the debugging of the simulation software. Not relying on a configured deployment network allowed the live demonstration of the simulation environment at several external occasions.We were surprised by the quality of the scenery and navigation databases used in the different commercial modules of the simulation. The air traffic management simulation and the virtual tower used independent databases for the geographic layout of the airport. The navigation data for the air traffic management simulation was provided by the European air traffic authorities through SESAR. The origin of the X-Plane 10 scenery database, which is used by the virtual tower, is unclear. Nevertheless the scenery and navigation databases matched extremely well down to the level of individual taxi lanes.The simulation method presented in this paper provides the features required for the SWIM-compliant distribution of simulation state and simulation events in loosely real-time synchronized human-in-the-loop simulations running in a single local area network. It does not provide nor intend to provide the scalability or security features required for large-scale pan-European SWIM networks. It is intended for quick deployment and rapid prototyping in research laboratory settings.It does also not provide or intend to provide the rich distributed simulation capabilities of frameworks like HLA. As of now, our approach is limited to wall-clock time aligned human-in-the-loop simulations because no sophisticated simulation time management was implemented. In theory, this could be added; however, it is questionable whether the coupling of commercial-of-the-shelf air traffic management software would still be possible with similarly low effort in this case. Commercial-off-the-shelf air traffic management software is obviously designed to operate in wall-clock time and has no concept of simulation time.Our method is functionally equivalent to the human-in-the-loop simulation environments presented by Prevot et al. [7] and Edinger and Schmitt [8]. The major difference is the use of the semantic model the air traffic management domain is currently converging to. It contributes therefore to the realization of the need to support standard air traffic management interfaces identified by Kaltenhäuser [5].With regard to the implementation our method builds on the work of Shifeng and Danxia [9] to use multicast to distribute the simulation state. However, we go one step further by using multicast to build a completely decentralized simulation communication architecture.The method presented in this paper is currently limited to the aeronautical domain because of the use of AIRM. This model is not applicable to other application domains. However, application domains where similar semantic models are specified can also be covered by our approach with appropriate adaptations.The limitations of the evaluation of the controller model lie in the limited number of experiments that could be performed with human controllers to collect the data. In total, four measured experiments of approximately one-hour duration each have been performed. Within this paper only the “high air traffic” scenario was presented.


## 7. Conclusion

In this work we presented a SWIM-compliant method for human-in-the-loop air traffic management simulation that uses the air traffic management information reference model AIRM as semantic interface and multicast message passing as communication interface. By this, it enables the evaluation of SWIM-compliant air traffic management software in research laboratory settings without the need for specialized infrastructure.Air traffic management tools and procedures will increasingly interface using SWIM as standard interface. It is therefore of high interest to evaluate them in a SWIM-compliant simulation environment to ascertain the validity of the evaluation.It has been shown that our implementation enables the use of commercial-of-the-shelf air traffic management software in simulation experiments improving the applicability of the results. Our use of multicast allows distributed simulation environments without a dedicated SWIM communication infrastructure. This makes deployment more rapid and more robust.Our method was applied to human-in-the-loop simulations experiments evaluating the performance of a rule-based controller model against human controllers in Hamburg Airport operations. Future work will investigate enhancing the controller model towards an automated optimization and decision support tool.



---

*Source: 6806198-2016-07-27.xml*