NCAR Insitu Turbulence EDR Software Requirements

Transcription

1 NCAR Insitu Turbulence EDR Software Requirements December 31, 2014 Authors: Affiliation: Dr. Gregory Meymaris, Gary Blackburn, Julia Pearson University Corporation for Atmospheric Research (UCAR) UCAR RAL; All Rights Reserved

2 What is in this document The NCAR in situ turbulence EDR software was developed under FAA sponsorship to create automated atmospheric turbulence reports as encountered by an aircraft. The algorithm complexity, including quality control and diagnostic functionality, necessitated providing an implementation. The EDR software is a C library that needs to be integrated into an on-board system, such as the aircraft condition monitoring system (ACMS). To assist with the integration of the C library into an on-board system (e.g. ACMS), the EDR software package includes documentation and supporting software. This document lists the minimum requirements for integrating the EDR software into an on-board system. In other words, this document can be viewed as containing a check list of requirements that must be satisfied before attempting to integrate the EDR software. If a requirement is not satisfied, there may be times when there is a possible work around (though this may necessitate NCAR assistance) or else it may mean that the EDR software simply cannot be integrated UCAR RAL; All Rights Reserved Page 1

3 Contents What is in this document... 1 Background... 3 Requirements... 4 On-board system... 4 Offline support software UCAR RAL; All Rights Reserved Page 2

4 Background The NCAR in situ Turbulence EDR software package includes: on-board C library for computing EDR (EDR software; version 3), including EDR computation, triggering logic, quality control, and diagnostic information. offline software written, primarily in MATLAB 1, for assisting in input data quality checking, tuning, testing, etc. The on-board C library takes as input several high-rate (e.g. 8 Hz) aircraft data parameters (fields) and, as requested, outputs a mean and peak EDR measurement. There are a small number of interface functions: a few initialization routines, the high-rate data input routine, an output routine for retrieving the mean and peak EDR (along with some quality control metrics), and optionally, an event triggering routine along with a few diagnostic routines. The input types include floats, ints, and arrays of structures. Output types include floats, ints, and character arrays. The general function calling pattern is to call the initialization routine(s), with specific initialization parameters (typically specific to an aircraft-type) immediately after the wheels are off the ground. Thereafter, the high-rate data is input at the data frequency (e.g. 8 Hz). Every minute (i.e. after every 480 samples), the output routine is called. If the supplied event triggering logic is used (generally recommended), the output data, along with other data that is used in the downlink report (lat, lon, alt, time, winds, temp, etc.) is put into a buffer, and the output data (mean and peak EDR) is also put into the triggering routine, which outputs the number of measurements to report (i.e. number of elements in the buffer). The offline software was developed to assist in implementation of the on-board C library. In particular, before integration is performed, the input data should be checked to verify that it is of sufficient quality and the tuning parameters need to be determined for the deployment aircraft type and data fields. Additionally, before the deployment is begun, the end-to-end system, from data input to downlink, should be tested. The offline software is to assist the implementers with these tasks. 1 MATLAB is a registered trademark of The MathWorks, Inc UCAR RAL; All Rights Reserved Page 3

5 Requirements On-board system 1. The target on-board system needs to be capable of integrating a 3 rd party C library including passing parameters, in the form of structures, ints, floats, and character arrays. 2. The compiler/on-board system need to have floating point support. Ideally, the hardware itself would support floating point operations, but it is possible to run the software without hardware floating point operation support, providing the compiler can handle it. However, there will be a significant cpu performance hit. 3. The on-board system needs to have enough resources (cpu time and memory) to be able to run the EDR software, though it may be hard to ascertain this beforehand. The EDR software was designed to run efficiently. Even on an older platform that did not have hardware floating point operation support (roughly equivalent to i386), the software was able to run, though it did consume about 30% of the cpu resources. On more current systems, the cpu usage is not anticipated to be a limiting factor. 4. The C compiler should support standard C, including, but not limited to, static and constant variable support, direct struct copy (e.g. if A and B are both struct of the same kind, then A=B; should work), variable setting in the declaration statement (e.g. int x = 2;), [[OTHERS?]]. Note that the software does not use dynamic memory. 5. The EDR software C library must be kept resident in memory for the entire flight since the EDR software stores data in static variables. 6. The on-board system needs to be able to access all of the required data fields at, currently, 8 Hz or higher. The required fields are inertial vertical velocity, true airspeed, pitch, roll, pitch rate, and indicated angle of attack. For data precision, please refer to section 1.1 of the file: NCAR Insitu Algorithm Needed Parameters. Note that the data fields should NOT be up-sampled to 8 Hz. Additionally, the input data must be of sufficient data quality (which is to be determined using the offline MATLAB software on sufficient quantities of recorded high-rate data (see 7 below). 7. The on-board system needs to be capable of recording entire flights worth of all of the high-rate input data as well as the EDR software output. The recorded data should be exactly the same as the input data to the algorithm including data source, update frequency, and precision. Additionally, depending on the amount of experience with deploying the EDR software on that aircraft type/on-board system configuration, it will be necessary to record anywhere from about 50 flights (if no experience) to as few as 20 flights (if significant experience). There should be at least several hours of turbulence. 8. The on-board system needs to be able to communicate with a downlink system like ACARS. Additionally, the output data needs to be able to be included into a downlink report. If set up as recommended, there will be reports that include anywhere from 1 to 6 EDR measurements. 9. The on-board system needs the capability to buffer as many as 6 output EDR measurements (both mean and peak), along with other data (lat, lon, alt, time, etc.) for inclusion in the downlink report. If used as recommended, the on-board system should also be able to keeping a resettable running maximum for an output quantity (int) UCAR RAL; All Rights Reserved Page 4

6 10. If used as recommended, the on-board system needs to be configurable enough to create sufficient logic to determine when to initialize, run, and terminate the EDR software. Offline support software 1. Most of the offline support software is written in MATLAB, and thus MATLAB (any version at or after 2010b) is required. It is possible that GNU Octave can be used instead, but this option is not guaranteed. MATLAB can be installed on any standard OS, though all of the testing, to date, has been on a Linux system. 2. In order to process the recorded high-rate input data for data quality checking, tuning, etc., the high-rate data will need to be able to be reformatted into a particular CSV format (to be specified in the offline documentation. See the document: NCAR In-Situ EDR Support Software for more information UCAR RAL; All Rights Reserved Page 5