In-ﬂight control and communication architecture of the GLORIA imaging limb sounder on atmospheric research aircraft

. The Gimballed Limb Observer for Radiance Imaging of the Atmosphere (GLORIA), a Fourier-transform-spectrometer-based limb spectral imager, operates on high-altitude research aircraft to study the transit region between the troposphere and the stratosphere. It is one of the most sophisticated systems to be ﬂown on research aircraft in Europe, requiring constant monitoring and human intervention in addition to an automation system. To ensure proper functionality and interoperability on multiple platforms, a ﬂexible control and communication system was laid out. The architectures of the communication system as well as the protocols used are reviewed. The integration of this architecture in the automation process as well as the scientiﬁc campaign ﬂight application context are discussed.


Introduction
The Gimballed Limb Observer for Radiance Imaging of the Atmosphere (GLORIA) is an infrared limb sounder which is based on an imaging Fourier transform spectrometer.It is designed for atmospheric research in the upper-troposphere and lower-stratosphere (UTLS) region (Riese et al., 2014;Friedl-Vallon et al., 2014).The instrument can operate on various airborne platforms: to date, it has flown on the German highaltitude research aircraft HALO (High Altitude LOng range) and on the Russian stratospheric aircraft M55 Geophysica.The instrument was successfully deployed on three measurement campaigns: during the combined TACTS (Transport and Composition in the Upper Troposphere and lowermiddle Stratosphere) and ESMVal (Earth System Model Validation) campaigns in 2012 (Engel and Boenisch, 2013;Oelhaf et al., 2013) as well as during the ESSenCe (standing for ESa Sounder Campaign) campaign in 2011 (Woiwode et al., 2014, and references therein).
The instrument is mostly designed to sound the atmosphere in across-track limb geometry but can also perform measurements in nadir geometry.In addition, to properly address its different scientific objectives, the GLORIA spectrometer can operate in different modes.These modes either support atmospheric dynamics studies, with high spatial and temporal resolutions, or atmospheric chemistry studies, with high spectral resolution.Combined with a high line-of-sight pointing agility, these operation modes enable complex measurement programs which can be used, for example, to make three-dimensional (3-D) tomographic soundings of the at-E.Kretschmer et al.: Control and communication architecture of the GLORIA limb imager mosphere's structures (Ungermann et al., 2011;Kaufmann et al., 2015).Such a measurement program requires a precise along-track scanning of the line of sight, which must be synchronised with the spectrometer's measurements.Before each complete acquisition of a spectrum, lasting between 1.2 and 12 s depending on the spectrometer's operation mode, a new target point in the atmosphere must be computed and the line of sight reoriented.Regardless of whether the aircraft follows a linear flight route or a complex flight pattern such as a hexagon, such a feat can only be achieved with a high level of automation.
Although complex flight patterns can be planned in detail, in most cases the exact location and time at which they take place is unpredictable.The execution of a measurement pattern may need to be adapted to the current atmospheric conditions, as the initial planning of the patterns is based on model predictions which can be as old as 12 h.Furthermore, the execution of non-standard flight patterns is always done under the oversight of the local air traffic control authorities.Depending on the air traffic conditions or on the ease of communication with those authorities, the execution of complex flight patterns may need to be brought forward or postponed.
A measurement process leading to useable results also requires calibration measurements (Kleinert et al., 2014), which are ideally made right before and following the measurement pattern.A calibration measurement, which must be undertaken on a regular basis, is not desirable for those measurement patterns that are intended to be used in 3-D tomography.Such a calibration measurement would lead to gaps in the measurement sequence and thus to the loss of spatial information needed for accurate 3-D reconstruction (Ungermann et al., 2011).As the exact timing of flight manoeuvres is only known to the flight crew, the execution of the measurement programs may need to be done under the oversight of an on-board operator.
The observed scene varies considerably during the course of measurement flights, which may last over 10 h and cover thousands of nautical miles (Krautstrunk and Giez, 2012).During those flights, the measurement mode or geometry may also be varied.In consequence, the performance of the instrument must be continuously monitored and its operational parameters adjusted, including the integration time of the detector or the line-of-sight scanning range to avoid direct Sun viewing.It is also desirable to monitor the overall function of the instrument to ensure a swift response as issues arise; the quick restoration of the full instrument functionality and performance is advisable to minimise costly dead time in flight.Such a challenging task can hardly be undertaken by a single operator and additional operators are needed on the ground to ensure the use of the full instrument potential.Information on the status of the instrument and on its performance is provided in the form of housekeeping data.These data allows the operators both on board and on the ground to monitor GLORIA and control it accordingly.The housekeeping data also provide the information needed by a control computer for the automation of complex measurement routines.
This paper reviews the GLORIA instrument's architecture designed to allow such mission dynamics to take place.The network topology enabling multiple operators to monitor an instrument in flight is discussed as well as the different protocols used in the communication process.As none of the platforms flown to date provides a standardised payload communication and control system such as the APCS (Airborne Payload C3 System) on the NASA Global Hawk (Naftel, 2009;Forgione et al., 2012), GLORIA uses its own communication and control protocols and infrastructure.Also, an overview of the automation system for GLORIA and its integration into the communication architecture is given.Lastly, the paper will present how the communication concept can further facilitate interaction, in the context of flexible mission execution, between all actors involved.

Instrument overview
The 48 kg spectrometer is mounted in a gimballed frame assuring both line-of-sight orientation and stabilisation as well as compensation of platform movements.This construction ensures a sufficient pointing accuracy and stability during measurement to achieve the required instrument performances (Friedl-Vallon et al., 2014).This system, being installed outside of the aircraft pressurised cabin in a belly pod or partially exposed instrument bay, must operate at temperatures ranging from 200 to 320 K and pressures ranging from sea level pressure to 70 hPa; this adds to the instrument's inherent complexity and leads to a need for constant monitoring (Piesch et al., 2015).
Along the science data delivered by the spectrometer, more than a thousand housekeeping parameters of the instrument and its subsystems are acquired during operation.This information is used in real time for monitoring the instrument to ensure that it functions properly.The data are also stored for detailed post-flight analysis.The analysis and results of some of these housekeeping data are described by Piesch et al. (2015).The housekeeping data are also used to support the processing of the science data as they also include geolocation and pointing information.Additional data are provided by environmental sensors, such as temperature and vibration sensors; diagnostic information, such as the voltages and currents that are provided to the different systems, is also supplied.
The full housekeeping data rate is typically around 110 kB s −1 , depending on which subunits are active and sending data.This data rate is significantly smaller than the science data rate produced by the spectrometer, which typically reaches 74 MB s −1 (or 260 GB h −1 ).The science data are transferred to an on-board storage via a dedicated optical link using the Camera Link protocol.This link is completely independent of the control and communication architecture presented in this paper.Since the science data are too large to be processed, transmitted to the ground and reviewed in real time, the housekeeping data also include diagnostic information on the science data and on their overall quality.
To support a large number of environmental and attitude sensors placed on different levels of the gimbal frame, a modular approach has been chosen.The data acquisition and control tasks have been separated into different interdependent units.Each unit sends its housekeeping data flow to, and receives commands from, a central control computer.The unit intercommunication and communication with the central control computer is based on a Gigabit Ethernet (GbE) local area network (LAN).Address assignment is done via the Dynamic Host Configuration Protocol (DHCP) by the central control computer and any number of units may be integrated into the data handling concept.
The central control computer receives and stores all housekeeping data as well as the science data from the spectrometer and provides a gateway to external networks for control and monitoring.Notably, it relays to the electronic units the commands issued from the operators, who are either on board or at various ground stations.Furthermore, the central control computer plays a key role in automation of the system by running the automatic control software.
The modularity of the communication infrastructure, notably the physical separation between the central control computer and the instrument, is an important element in its portability between platforms with different requirements and facilities.On the HALO aircraft, the instrument itself is mounted in the belly pod of the aircraft, while the central control computer is mounted in an instrument rack in the aircraft cabin (Friedl-Vallon et al., 2014;Giez, 2010).An operator can be present on board.On the M55 Geophysica, which has no pressurised cabin, the whole instrument including the central control computer is mounted in an instrument bay in the nose (Friedl-Vallon et al., 2014).No operator can fly with the instrument on this single-seat aircraft.
Despite the instrument complexity, both in its design and operation, GLORIA can be fully remotely operated by a member of the ground crew, reducing the need for an operator on board the aircraft and enabling operation on aircraft such as the M55 or the future deployment on balloonborne platforms or unmanned aircraft systems.An operator is nevertheless required to accompany the instrument if the data link with the aircraft does not meet the stability and throughput requirements for remote operation, control and monitoring.An on-board operator may also be required for campaign-specific needs, as later discussed in Sect.7.

Network architecture
Primarily for practical reasons, but also for performance and security reasons, the network topology used for the GLORIA subsystems is divided in two distinct physical networks: the GLORIA-LAN (Glo-LAN) interconnects all the control and housekeeping units of the instrument with the central control computer, while the Laboratory-LAN (Lab-LAN) interconnects all control and monitoring stations on the ground.This topology is illustrated in Fig. 1.
The data transfers between the Glo-LAN and the Lab-LAN are done via a single entry point, the bridge computer, using a third dedicated interfacing network.Except for the bridge, no other ground-based control or monitoring computer has a direct connection to the on-board central control computer.
Depending on the aircraft and the available infrastructure, the third network may be routed via a narrowband one-channel Iridium satellite link, via a broadband multichannel OpenPort Aero Iridium link or via a broadband Inmarsat link.Furthermore, during on-ground operations, the third network may be routed via wireless LAN (WLAN).The M55 aircraft has no communication facilities for the payload and thus the iridium OpenPort Aero satellite communication system has been installed as part of the GLORIA experiment.The HALO aircraft offers a broadband Inmarsat system, and the addition of an Iridium system similar to the one flown on the M55 is under investigation.The combination of Inmarsat and Iridium is already available on the HI-APER (High-performance Instrumented Airborne Platform for Environmental Research), a similar platform operated by NSF/NCAR (Laursen et al., 2006).The nature of the bridging network and its exact topology can be changed at any time.These changes remain transparent to the users.
Table 1 details the available bandwidth in the different bridging networks.
For measurement campaigns which require one or more remote operation bases, for example for overnight stay and refuelling, a fourth network is deployed at the remote site.
Table 1.Available networks for the connection between the central control computer on the aircraft and the Laboratory-LAN.No nominal bandwidth is given for the Inmarsat system as it has not been used to date.The nominal bandwidth is the bandwidth typically used for issuing commands and for the housekeeping feed.Extraordinary activities such as running a remote desktop connection between the ground and the central control computer are not included in this nominal bandwidth.This network allows connecting the operators at the remote site with the Lab-LAN.The connection is established securely through a virtual private network (VPN) via the locally available Internet infrastructure (e.g.public WLAN or GSM/UMTS).The central control computer of GLORIA can also connect to this remote-site network via WLAN for faster data transfer and to limit the costs of operating satellite links while on the ground.

Bridging network
The VPN used for the remote sites is based on the Open-VPN protocol and allows any computer on the Internet with the proper certificates to securely join the control and monitoring network of GLORIA, the Lab-LAN.This allows technical operators to monitor the instrument and issue commands without having to be on site.In addition, a second VPN is established between the bridge computer and the central control computer.This allows secure and transparent bidirectional communication through the infrastructure and firewalls of the satellite communication service providers, which otherwise block up-going communications.The use of VPN is illustrated in Fig. 2.
Additional networks dedicated to specific tasks are available within the aircraft cabin on HALO.A service port at the central control computer allows the connection of the onboard operator directly into the instrument Glo-LAN, thus allowing the operator to communicate directly with the control and housekeeping units of GLORIA for low-level access.A transfer network dedicated to the transfer of the science data from the central control computer to a storage unit during the on-ground maintenance is also available.A third dedicated cabin network connects the central control computer to the public cabin network of HALO, giving access to avionic data and condition data provided by standard HALO sensors (Giez, 2010;Krautstrunk and Giez, 2012).The public cabin network also gives access to a GPS-based time server.The multiple networks are managed through virtual LAN (VLAN) following the IEEE 802.1Q standard (IEEE, 2011) with the help of a managed switch mounted in the instrument rack alongside the central control computer.

Housekeeping data handling
The housekeeping data transmission is based on a protocol which evolved from one previously used with the GLORIA predecessor instruments MIPAS-B2 (Michelson Interferometer for Passive Atmospheric Sounding -Balloon-borne) (Friedl-Vallon et al., 2004) and MIPAS-STR (Michelson Interferometer for Passive Atmospheric Sounding -Stratospheric aircraft-borne) (Piesch et al., 1996).The use of the same data structure, which was perfectly adapted for links with limited bandwidth, allowed us, to a large extent, to reuse the existing logical architecture and implementation and ensured backward compatibility.The former serial link frame protocol, including the sync word and header, was simply encapsulated in Transfer Control Protocol (TCP) frames.
Each unit of GLORIA opens a TCP connection on a dedicated port with a server application called Spider running on the central control computer.Following the connection establishment, each housekeeping data packet is transmitted with one or, when the frame is bigger than the maximum transmission unit (MTU), with multiple TCP frames.Each packet is then written as received by the Spider application to a logging file on disc.The sync word inherited from the serial protocol found in the data packet header facilitates the interpretation of the raw packet log, where packets may have different lengths and formats.
The structure of a housekeeping data packet, illustrated in Fig. 3, consists of a data block preceded by a header, starting with the constant sync word.The header also includes the unique identifiers of the sending device (DEV) and of the data packet type (TAG), the packet type serial counter, the packet send time, the packet length, and a cyclic redundancy check (CRC) value for error detection.
A device may send only a single type of data packet or different types of data packets, each identified with a TAG.The data structure of each type of data packet for each unit is predefined in a definition library used by the different programs to interpret the data.The library specifies the name of each data entry, the data type, size, physical units, and, if applicable, offset and scaling factors.Using this definition library, any program can interpret the raw data packet for any use, such as the processing of the data or visualisation.
The data packets may be sent by units at a constant rate or sporadically, triggered by events.Each packet type, even those coming from the same unit, may be sent at different rates to accommodate the needs related to the housekeep-ing values they convey.For housekeeping parameters produced at a high frequency, for example vibration and acoustic data, the defined data structure may repeat itself multiple times within a single data packet up to the length given in the packet header.These cyclic data packets allow the transmission of a large multiple of measured parameters within a single block, reducing the number of required packets, thus reducing the communication overhead on high-rate data.
The implementation of the communication protocols in embedded controllers of electronic units is standardised through a universal C library.This library has been effectively used on multiple platforms, including Windows, Linux and QNX.Furthermore, the communication protocols have been readily implemented in Java and Groovy programs and are available as modules for Labview programs.The broad support of different platforms provides great flexibility in the design of the different subunits of GLORIA, as well as a lot of freedom during the prototyping and testing of these units.

Centralised data collection and distribution
Every unit, or device, sends its data packets to the Spider server application located on the central control computer.The Spider application does not only log the data received, it can also redistribute them, or parts of them, to other computers for visualisation or further retransmission.Due to the nature of the data link between the ground station and the aircraft, it is neither convenient nor desirable for single ground operators to receive housekeeping data destined for visualisation directly from the central control computer.
For this task, a second Spider server application runs on the bridge computer.This second Spider builds a connection with the Spider on the aircraft and receives, logs and eventually retransmits every data packet sent by the in-flight server to the users requesting them.The connection can either be built through a TCP channel when all the data packets are to be retransmitted or through a User Datagram Protocol (UDP) channel when only part of the data is to be transmitted through an unreliable link, such as a satellite connection.The TCP channel, with full retransmission of the data packet, is only used via the WLAN infrastructure during ground operations.
Via the UDP channel, only data packets specifically requested by the operators are transmitted.Any data packet can be transmitted as needed by the central control computer.Either every or only a reduced number of the data packets of a type coming from a unit can be transmitted as they arrive at the central control computer.If only a reduced number of packets is desired, the user can choose to send a data packet only once or with a given minimum time interval between packet transmission.This flexible communication protocol allows ground operators to dynamically adapt the data packet flow over the limited bandwidth to the current situation.
The selection of the data packets to be retransmitted via the UDP-based feed is independent of the requests made by the users in the Lab-LAN through the visualisation tools discussed in Sect.4.2.The Spider application on the central control computer is instructed to relay specific data packet types at a chosen rate using the standard protocol of GLORIA for issuing commands, detailed in Sect. 5.
In addition to the capability of retransmitting selected data packets, the Spider application can also construct new data packets with data extracted from the incoming packets from the units.This allows further data reduction and a higherfrequency update of important parameters distributed over a large number of different data packets sent to the central control computer.
The Spider application cascading is not limited to a single level and the data received at the bridge computer can be sent to further Spider applications through TCP or UPD links, for example at remote operation sites where other operators may need to review the data.Furthermore, multiple Spider applications can connect at once to another Spider application.Each Spider connected to the first one thus receives the same data flow, multiplexing the data stream for various needs.

Data visualisation
The data visualisation tool receives the data packets exactly as sent by the source unit.It is only at the end of the whole data collection chain that the data packets are interpreted.The interpretation is done using the parameters specified in the definition library for each data packet type.The definition library is laid down as a simple text format file and is interpreted at runtime by the visualisation tools.No update of the software tools is required as the data packet structure evolves or as the format of the values therein are changed.
Within the visualisation tool, the operator selects the housekeeping parameters he desires to monitor.The tool then requests the relevant data packet from the bridge Spider application via a TCP connection with a special filter request data packet.Following the request, the Spider retransmits the requested data packets to the visualisation tool via the existing TCP link.This process is illustrated in Fig. 4.
Figure 5 shows a typical housekeeping visualisation window.In addition to raw values, selected parameters can also be displayed as graphs.The visualisation tool shows the name of the data values, the values themselves after proper scaling and offset correction, and the physical units.A green indicator shows whether the values are actively updated or whether the values displayed are old.Warning flags on the far right indicate whether a value is within its nominal range, which is also defined within the definition library.2.
As deferred review and visualisation of the housekeeping data may be convenient, the housekeeping feed arriving at the bridge is also sorted into a database.This database contains the housekeeping parameters in their interpreted form based on the structure defined in the definition library file.The values within the database can be reviewed and visualised with time delay, making the database a great asset when, for example, reviewing the events that led to problems during a flight.
In addition to the technical housekeeping visualisation tool, general information about the missions is published live on a website.The web application requests the desired housekeeping data from the bridge computer and publishes them on the Internet, presenting information about the instrument status as well as the aircraft altitude and location.This simple visualisation tool allows the large scientific community working with GLORIA, but also with other instruments on board the research aircraft, and, moreover, the broader scientific community interested in specific HALO missions to follow actively the progress of the missions.

Control interface
Similar to the housekeeping protocol, the basis for the control protocol also dates back to the communication used for the predecessor instruments of GLORIA, MIPAS-STR and MIPAS-B2.As with the housekeeping data packet, the control data packets used to issue instructions to a specific unit have been encapsulated in TCP/IP frames for the transmission via the modern infrastructure of GLORIA.
A control data packet -or telecommand packet (TC)consists of 10 bytes, starting with a synchronisation byte.The packet, detailed in Fig. 6, includes the identifier (ID) of the unit to be given commands, ID of the given command plus four optional-value bytes, the type of the optional values, a parity check value and the ID of the command originator.The type flag indicates to the receiving unit command interpreter how the four value bytes should be interpreted.presents how the different optional-value bytes may be used according to the type parameter.
A shell interface interpreting human readable commands is available to the operators.Each time a command is entered, the shell opens a new TCP connection with the Spider server application and sends the interpreted commands as a 10-bytes payload.The on-board Spider determines the proper destination device address using the information contained in the payload and redirects the command to that specific unit in the GLORIA-LAN.Upon successful retransmission, the payload is sent back as acknowledgement (ACK) to the originator in reverse byte order by the Spider application via the same link.This validation process is illustrated in Fig. 7.
In the event of unsuccessful retransmission by the onboard Spider, the returned ACK payload is zeroed, leading to an error message in the command shell.Upon successful reception of a control data packet, the unit will send a second confirmation in the form of a housekeeping data packet containing the received command payload.This confirmation data packet may be reviewed by the operators to ensure proper command reception, in which case it needs to be requested in the same way as with any other housekeeping data packets.The command feeds are cascaded from one Spider server to another all the way to the central control computer, following the same route as the housekeeping feed, but in reverse direction.Fig. 7 reviews this process as well.
This control protocol can be used to issue commands to specific units initiating specific actions, such as throwing a relay or updating the device clock from a time server.It can also be used to set parameters, such as targeting parameters for the pointing system or maximum optical path difference in the spectrometer.The commands can also be grouped together in batches, facilitating manual operation of the instrument.A batch is simply a plain text file with a list of commands sequentially interpreted by the command shell.  .Telecommand (TC) and housekeeping (HK) relaying between the operators and the GLORIA housekeeping and control units.The relaying takes place over the cascaded Spider application running on the central control computer and on the bridge computer.The TC acknowledge (ACK) is sent back from the Spider on the central control computer to the originating operator's shell upon delivery of the TC packet to the unit, which also sends an echo confirmation in the form of an HK data packet.Just as with any other HK data packet, the TC echo packet must be requested by the operator and sent via the HK feed from the central control computer in order to be reviewed.

Automatic control
The automatic control system of GLORIA enables the automation of processes which would require constant attention from an operator as well as processes where short reaction times are required, such as targeting.The automatic control also allows the execution of complex measurement sequences with little to no human intervention.The number of operators actively and constantly monitoring and controlling the instrument can thus be reduced.
Two operation modes are provided for the GLORIA instrument: one where no on-board operator is or can be present and one with an on-board operator.The latter is required for operation with a low-bandwidth data link, such as with the single-channel Iridium link.While the on-board operator has access to the full instrument data stream in real time, the ground operators can support him with a limited set of housekeeping data.
Operation without an on-board operator mandates sufficient bandwidth to ensure the proper monitoring of the housekeeping data on the ground.Doing this does not require a full housekeeping data set, but a set of all parameters deemed mission-critical is the minimum requirement.The update of these parameters on the ground must also be frequent enough.In both operation modes, the full operations of GLORIA, from power on to measurement, calibration, error recovery and power down may be fully or in part undertaken by the automatic control systems.
Integrated within the Spider application, the automatic control system also runs on the central control computer.Benefiting from this integration, the automatic control has full access to all housekeeping data provided by the instrument.The Spider, a Java-based application, includes a Groovy interpreter module for the automation purpose.Groovy is an interpreted script language derived from Java, with a code base in large part interchangeable with that of strict Java (Codehaus Groovy Community, 2014).The scripts are interpreted during runtime and may even be modified during operations.An interface is provided by the Spider application to the Groovy interpreter module to read and interpret any housekeeping parameter received at the central control computer.
Furthermore, this interface allows scripts that are run in the Groovy module to send control packets to the units exactly as an operator would do using the command shell.To facilitate the implementation of the scripts, exactly the same nomenclature as in the command shell or in the visualisation tool is used.As with the manual command shell, the Groovy interpreter may use predefined command sequences (or batches).Most scripts of the automatic control system mimic the manual operations of the instrument by monitoring the same housekeeping, and they form an expert system fully capable of operating the instrument.
The automatic control system is a multi-thread system, where every subscript can be run in a separate thread.During the power-up of the instrument, most of the threads are run at once, starting the different subsystems and units (navigation, pointing, spectrometer, calibration blackbodies, etc.) in parallel.Once all systems are ready, a main thread becomes active, monitoring the state of the instrument and activating or changing measurement modes as desired by the program.Other threads, such as watchdogs ensuring the proper functioning of a unit, may be run in parallel.
The states of the instrument are regulated through logical rules defined before each flight.The main thread interprets those rules and verifies which are true.Following these rules, the main thread puts the instrument in the correct operational state.A typical rule could, for example, be "when altitude greater than 10 000 m", and each rule may be assigned a degree of priority, giving some rules precedence over others.This flexible system allows the scripting of complex operation patterns.
A condition, i.e. a measurement mode or program, is assigned to each rule.According to the verity of the rules and their priority, the automatic control software chooses the operation condition for the instrument.Once this condition changes, for example from one measurement mode to another, the program being executed will be aborted and the new program will be started automatically.Calibration sequences with different calibration scenes are preprogrammed and handled exactly as measurement programs.Finally, special conditions are used to secure the instrument for landing or to power it down after landing.
At any time during the flight, the rule system upon which the automatic control system is based may be bypassed by the operators.Measurement mode and conditions of the instrument may be set manually, allowing manual control during flights where a more flexible approach is required or in case of unforeseen circumstances.During the manual operations, most systems and functions of GLORIA remain automated; only the condition selection is managed manually.The rules may also be updated at any time during the flight, allowing for uncertain flight planning or operational mission changes.This task can also be done by a ground-based operator.Some conditions may not be overruled by the operators.These include the special conditions set by the automatic control system in order to protect the instrument, such as disabling the line-of-sight stabilisation when the aircraft attitude exceeds an operational envelope.

Flight operations
The flight operations of GLORIA may vary significantly from one carrier to the other.The communication and control systems of GLORIA are flexible enough to cope with a wide range of operational scenarios.In some cases, operational decisions such as the exact moment of a dive flight pattern or special measurement flight pattern for GLORIA may have to be taken on board the aircraft based on the atmospheric conditions as well as on the interactions between the flight crew and air traffic control.The on-board operator of GLORIA may interact with the flight crew and the mission prime investigator (mission PI) and adjust the measurement plan as needed.
To facilitate coordination with the ground crew and with the scientific advisors for the proper selection of the measurement program, different communication systems are established between the on-board operator and the ground stations.The HALO aircraft has an Iridium satellite telephone, which can be used as a communication channel between the cabin and the ground crew.Furthermore, the GLORIA instrument has its own Iridium satellite telephone, which may also be used for this purpose.Satellite telephones are neither practical nor affordable for constant communication between the ground crew and the on-board operator.This constant communication is nonetheless necessary for the technical operation of GLORIA and helpful for flexible mission execution.
For this purpose, a text communication is established between the aircraft and the ground using the IRC protocol (Oikarinen and Reed, 1993) with a dedicated IRC (internet relay chat) server and network.The text communication allows asynchronous communication as well as the transfer of critical parameters in text form.In order to cope with the unstable nature of satellite communication links and with frequent reconnection, the on-board operator connects to the GLORIA IRC network through an IRC proxy, also referred to as a bouncer or as BNC.The bouncer ensures reliable re-ception of the sent text message by either party, even in the event of satellite link downtime.The IRC-based link uses very little bandwidth and operates on the same data link used by GLORIA for the housekeeping and commanding links.
During the TACTS and ESMVal, this communication infrastructure was used to its full potential.On the flight on 13 September 2012, during which GLORIA was taken to the edge of the Antarctic continent and polar vortex on HALO, the communication infrastructure enabled the execution of a 3-D tomography hexagonal flight pattern around an area featuring high dynamic structures (Kaufmann et al., 2015).The pattern, which was to be flown near the end of the flight, could only be executed contingent upon sufficient fuel reserves, a decision to be taken on board by the flight crew.Once the decision to execute the hexagonal pattern was taken -at that point 7 h into the flight -the decision was communicated via text channel to the operators and scientists located on the ground in Germany and in South Africa, where a second operation basis was deployed.Using more recent model data, the location of the atmospheric structure along the flight track of the aircraft was communicated back to the on-board operator through the same text channel.This location was then used by the on-board operator and the flight crew to plan the hexagonal pattern and accordingly file flight plan amendments with local air traffic authorities.

Conclusions
The GLORIA airborne imaging limb sounder is designed to carry out complex measurement sequences with a high level of flexibility.In order to provide data of high scientific value, GLORIA requires both a substantial level of automation to cover its routine tasks and human intervention to optimise its performances and carry out measurements difficult to plan.An efficient communication system was designed for the GLORIA airborne experiment drawing on the experience gained from the use of its predecessors, the MIPAS-B2 and MIPAS-STR instruments.This communication system played a key role in the success of the ESSenCe campaign in 2011 and of the TACTS and ESMVal campaigns in 2012.The flexibility of the communication systems allows operation on different platforms with a varying physical infrastructure.Also, the embedded Ethernet technology used for the instrument internal network has proved to be a wise and flexible choice.Units can be changed, upgraded or added with little or no modification to the wiring concept.Changes in the infrastructure, even during operation, are transparent to the instrument operators.
Visualisation tools for the technical housekeeping data allow operators both on board and on the ground to monitor the operation of the instrument.A flexible low-bandwidth protocol was established to cope with any type of available data links between the airborne platform and the ground stations.The transmitted data may be changed ad hoc and according to the available bandwidth.A general visualisation of selected data through a web interface is also available for the wider community.
The infrastructure supports decentralised operation centres, all communicating with the instrument through a single point of entry.Remote operators connected to the Internet can join the control and monitoring network via secure VPN connections.This possibility simplifies the personal resource management and reduces the burden on specialised technical staff for long-duration and decentralised campaigns.
Both the infrastructure and protocols deployed for the GLORIA experiment are flexible and scalable such that they could be deployed with little modifications for any experiment.It is even possible for multiple experiments to share a common infrastructure.Issuing commands to instruments and devices via a serial link is also feasible through the use of ethernet-serial bridges.This would be facilitated by the form of the payload frame used, which is inherently compatible with serial data links.
Complex instruments like GLORIA significantly rely on automation systems, which were successfully implemented.The scripting-based automation system uses the standard communication infrastructure to gain information on the instrument status and to control it.Many operations typically executed on various scientific payloads by on-board operators during the flight could be handled by proper scripting, mitigating the need for operators and thus optimising scientific payload capacity.
The operational requirements of GLORIA required a persistent communication link between the on-board and the ground crews.This was successfully implemented through a text-based communication protocol and was shown to be an important asset not only for the instrument but for the whole mission during the TACTS and ESMVal campaigns.

Figure 1 .
Figure1.Overview of the network topology.On the left side, the ground infrastructure communicates with the on-board infrastructure, shown on the right side, through satellite up-and downlink or through WLAN.
−1 M55, HALO * Under consideration and investigation for future implementation at time of publishing.

Figure 2 .
Figure 2. Global network topology diagram showing how the data transmission is carried out through VPN connection (shown in green) while transiting through the physical networks (shown in black).Here the logical (VPN) and physical networks are illustrated in parallel to highlight how they are perceived by the users.The operators at remote sites are fully integrated into the Lab-LAN through the VPN connection.

Figure 4 .
Figure 4. Schematic illustration of the housekeeping (HK) data packet cascading from source to end point.Different units produce different types of HK data packets (identified with the letters A to N), all received and stored at the central control computer.A feed of selected HK data packets is sent down to the bridge computer.Operators request specific packet types (here, type A) from the bridge computer through the visualisation tool.Only the requested HK data packet is sent from the bridge computer Spider to the visualisation tool of the operator.

Figure 5 .
Figure 5.Typical housekeeping visualisation showing parameters transmitted via different data packets.The disposition of the values as well as the displayed information such as units or out of range indicators can be chosen as desired by the operator.

Figure 6 .
Figure6.Structure of a GLORIA telecommand data packet encapsulated in a TCP/IP frame.The synchronisation byte is followed by four optional-value bytes and by the command byte, indicating which action to take.In addition, the target device as well as the source device are included in the packet.The type byte indicates how the four value bytes should be interpreted as shown in Table2.

Figure 7
Figure7.Telecommand (TC) and housekeeping (HK) relaying between the operators and the GLORIA housekeeping and control units.The relaying takes place over the cascaded Spider application running on the central control computer and on the bridge computer.The TC acknowledge (ACK) is sent back from the Spider on the central control computer to the originating operator's shell upon delivery of the TC packet to the unit, which also sends an echo confirmation in the form of an HK data packet.Just as with any other HK data packet, the TC echo packet must be requested by the operator and sent via the HK feed from the central control computer in order to be reviewed.

Table 2 .
Usage of the control data packet optional values according to the specified type.If relevant, the most significant byte (MSB) and the least significant byte (LSB) are indicated.The little-endian convention is followed.