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 . The instrument can operate on various airborne platforms: to date, it has flown on the German high-altitude 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 lower-middle Stratosphere) and ESMVal (Earth System Model Validation) campaigns in 2012 as well as during the ESSenCe (standing for ESa Sounder Campaign) campaign in 2011 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 atmosphere's structures . 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 , 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 . 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 . 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 , 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.

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 . 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 .

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 . 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 kBs-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 MBs-1 (or 260 GBh-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 . 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 . 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 balloon-borne 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. .

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. .

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 HIAPER (High-performance Instrumented Airborne Platform for Environmental Research), a similar platform operated by NSF/NCAR . The nature of the bridging network and its exact topology can be changed at any time. These changes remain transparent to the users.

Table  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. 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.

The VPN used for the remote sites is based on the OpenVPN 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. .

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 on-board 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 . 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 with the help of a managed switch mounted in the instrument rack alongside the central control computer.

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) and MIPAS-STR (Michelson Interferometer for Passive Atmospheric Sounding – Stratospheric aircraft-borne) . 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. , 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 housekeeping 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.

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. , 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. Table  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. .

In the event of unsuccessful retransmission by the on-board 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.  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.

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 . 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 pre-programmed 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.

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 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 reception 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 . 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.

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.