FAAM Facility for Airborne Atmospheric Measurements FAAM Data

FAAM Facility for Airborne Atmospheric Measurements FAAM Data Recording and Display System 1. Quick Introduction to FAAM 2. DRS History 3. Project Criteria 4. Features and Hardware Alan Woolley, Instrumentation Manager 11/12/12

FAAM Facility for Airborne Atmospheric Measurements The FAAM Aircraft An aircraft measurement platform for use by all the UK atmospheric research community on campaigns throughout the world. Core data ~70 parameters sampled and recorded at up to 32 Hz, both displayed in flight and post-processed, with at least as many non-core data outputs depending on the aircraft fit.

FAAM Facility for Airborne Atmospheric Measurements History of the Existing System Aircraft ‘core’ data are acquired and displayed centrally using a data system (‘HORACE’) designed in the 1990 s by the Met Office, as part of the predecessor C 130 aircraft. Based around a COMPAQ 64 -bit DEC Alpha system running Open. VMS with Fortran routines handling most of the control/acquisition. Peripheral Data Logging Units (A/D conversion) updated for BAe 146 conversion, as was an Aircraft time generator based on GPS satellite data. These were bespoke, and were designed and built in collaboration with external contractors. SPF

FAAM Facility for Airborne Atmospheric Measurements User can select from a range of different measured or derived physical quantities to plot in some simple ways during a flight. Data are used to inform the science mission – example below Carbon Monoxide measurements overlaid on Google earth Above broadband radiometer data as a time series

FAAM Facility for Airborne Atmospheric Measurements Imperatives for Change Existing system is obsolete (end-of-life was intended to be 2007!), technology and standards have moved on since the system was designed. • Limited spares, even more limited staff expertise for bespoke hardware originally designed in-house and built under contract. • Non-standard approach, where standards were adhered to these are often now obsolete. • Many single-point failures, though robust. • Impossible to adapt to new instrument outputs and contemporary systems. Only FAAM core data is typically available to display in flight • Hardware isn’t as robust as modern equivalents • Failures are starting to happen. SPF

FAAM Facility for Airborne Atmospheric Measurements Data System Considerations Cost of flights effectively mandate perfect reliability Realtime availability of data used for missioncritical decisions Changing environmental conditions Harsh environment for scientists – automate tasks where possible, error-check Operational constraints, startup/shutdown, data transfer and postflight Space/fit constraints Remote operations mean that system must be as autonomous/fault tolerant as possible as staff may not be available to remedy failures Flexible aircraft science fits and renewal of instruments

FAAM Facility for Airborne Atmospheric Measurements x 2

FAAM Facility for Airborne Atmospheric Measurements Accurate Time Widget PC UDP 1 hz ASCII Instruments Distributed Computer TCP/IP full rate Binary Postgre. SQL Database Python Scaling Storage Served to Java Clients Postflight

FAAM Facility for Airborne Atmospheric Measurements Data Acquisition Hardware SPF Off-the-shelf data acquisition hardware from National Instruments (compact RIO). - c. RIO designed with distributed data acquisition in mind, and tested for use -20 to +70°C with extensive shock and vibration specification. Tested to over 15 km equivalent pressure altitude by third parties. Modular, rugged, ethernet compatible. Labview and c. RIO are both used very widely, and modules already exist for the majority of the inputs required. - Happens to fit in the existing enclosures! - DLU still a single point failure, hold a spare for every module and card, maintain separate images of each different DLU code.

FAAM Facility for Airborne Atmospheric Measurements Timing SPF DLU = Distributed Logging Unit Previously each DLU would take a synchronisation pulse from the Master Time generator to coordinate its action. Also, AMTG only sync with GPS at boot Now each new DLU maintains its own internal clock. Labview Realtime allows for actions such as data acquisition triggering to happen relative to ‘Absolute time’. FPGA acquisition is triggered by Real. Time code. In 2010, NI ran a beta test for their support for the IEEE 1588: 2008 Precision Time Protocol (PTP). PTP: - Higher accuracies possible on LAN than with NTP No requirement for GPS receiver at each node Master-slave relationship This permits the compact. Rio-based DLUs to automatically synchronise to a networked PTP source, in turn synchronised to GPS time.

FAAM Facility for Airborne Atmospheric Measurements Timing 2 DLU = Distributed Logging Unit Well-understood timing is a fundamental requirement for our measurements. Use 2 identical commercial PTP timeservers to provide reliable output. • GPS-linked • Internal crystal oscillators capable of maintaining time to within ± 22µs/day if GPS-link lost • ‘Intelligent’ DLU slaves which determine the best time to use **What time is it? PTP uses the same epoch as UNIX time (which is linked to UTC clock) However, UTC and UNIX are both subject to leap seconds PTP time is linked to TAI, Temps Atomique International, which has monotonically increased since 1/1/1970, and is 35 s in advance of UTC

FAAM Facility for Airborne Atmospheric Measurements Server Replacement Fanless 2. 4 GHz dual-core computers rated for vibration to MIL-STD-810 F 514. 5 C, operating conditions -20 to +70°C. Two machines carry out identical tasks. Linux Ubuntu 10. 04 LTS (Lucid Lynx) server support to April 2015 Post. Gre. SQL relational database: • Reliable, Flexible • Conforms with ANSI-SQL: 2008 standard • Runs stored procedures in more than a dozen languages, including python - Existing fortran in-flight processing has been rewritten in python rather than wrapping it as C code, done for simplicity. • Labview SQL tools are compatible • Post. GIS adds support for geographic objects in Postgre. SQL – possible future development? Server machines are used as the main repository for all DLU data, as a convenient staging post for the post-processing.

FAAM Facility for Airborne Atmospheric Measurements User Interface allows user to monitor and interact with data system from a standard windows platform, while the system itself runs stably in a real-time operating system. Intelligent fault diagnosis is being built in, enabling an unfamiliar user to address problems as quickly as possible. Full system trialled on the FAAM BAe 146 Nov/Dec 2012…

FAAM Facility for Airborne Atmospheric Measurements Backup Systems Critical parts of the aircraft data system have been duplicated. Failures of the timeservers, database machines, support systems and so on will have minimal impact on a mission, enabling FAAM to carry out maintenance when the aircraft returns from deployment. Display Any Data UDP data inputs are designed to a common format, and described using simple csv files. -New data sources simple to integrate because of system structure -Key component of the database is the ability to handle ANY data, meaning that non-core data from guest systems can be easily and flexibly integrated and displayed alongside FAAM core data.

FAAM Facility for Airborne Atmospheric Measurements DECADES – Summary DECADES is more robust and autonomous. It is faster to start (60 s vs 15 minutes). Hardware is off-the-shelf, with FAAM easily able to maintain and carry spares on worldwide deployment. The aircraft network is fully exploited, this simplifies and decentralises the system whilst making it straightforward for users to incorporate non-core data into the existing display and visualisation. This project has relied on important contributions from outside FAAM. As such, a vital part of DECADES has been the facility to work on the system remotely, helping external contributors to develop this vital FAAM facility from the safety of their own desks. Main Project Participants: Alan Woolley, Matt Gascoyne (FAAM), Dan Walker (NCAS, Leeds), Dave Tiddeman (Met Office, Exeter) Acknowledgements for their help to Matt Hobby and Mark Bart (Leeds University), Phil Goy (ARSF)