InSitu Turbulence Detection Algorithm and Report Triggering Logic Interface Control Document Gregory Meymaris 1

Transcription

1 InSitu Turbulence Detection Algorithm and Report Triggering Logic Interface Control Document Gregory Meymaris 1 Definitions Implementers the party that is implementing the C code into an on-board computer. Background NCAR is providing, to the Implementers, a C software library, the insitu turbulence library code (INSITU), that will generate wind-based maximum likelihood turbulence intensity estimates, namely eddy-dissipation rate (EDR) and optionally notify when and how many turbulence/winds/temperature/etc.(met. info) measurements to package into one report for downlink. The Implementers will incorporate these modules into a software system that samples the avionics data bus and provides the real-time data to the INSITU library. The turbulence estimation module (TURB) of the NCAR insitu turbulence library will produce turbulence intensity estimates. These estimates will be returned to the Implementers driver software. If the NCAR report triggering algorithm module (TURBPREP) is used, TURBREP will return a number indicating how many of the previous measurements to downlink. The Implementers will downlink the number of met. info measurements as indicated from the NCAR report triggering algorithm. Goal The goal of this document is to define the interfaces between the NCAR INSITU library and the Implementers software. Fundamental to this is developing an understanding of calling sequences and timing issues required by the INSITU library. Assumptions The TURB module of the INSITU library assumes the following: 1. Most adaptable parameters specific to the TURB module are be set in the C library include files and compiled into the code. These should be changed only by NCAR personnel. If necessary, these parameters will only be modified during testing and before fleetwide deployment. These parameters are specific to databus inputs, and sampling frequencies. The Implementers will only install this software on aircraft with exactly those same databus inputs and sampling frequencies. 2. A few parameters will be set by the Implementers on initialization (N1 see below) with values agreed upon by the Implementers and NCAR. The document, NCAR In situ Turbulence EDR Support Software, describes MATLAB software that can assist in the determination of these constants. These parameters are used to calibrate the algorithm to the specific aircraft type. If this software is installed on a different aircraft type, then these parameters will most likely need to be modified with consultation from NCAR (or via the EDR support software). 3. The Implementers will initialize the software (via N1 and possibly N1.1 see below) before the software is given data (via N2 see below). Generally, this is 1 NCAR/RAL, Meymaris at ucar dot edu,

2 done only at the beginning of a flight, typically soon after the wheels are off the ground. 4. During the implementation and testing phase, the run_mode parameter of the initialization interface, N1, should be set to 1, rather than the normal 0. This causes a flag to be set in the EDR output string that indicates that the EDR values are preliminary and thus should not be used operationally. When deploying, this adaptable parameter should be set to 0 to indicate that the EDR values can be used operationally. 5. The Implementers will sample the data bus at 8Hz. The N2 interface (see below) of the INSITU library will be called at 8 Hz, whether or not new data is available. Small (0-5msec) variations around seconds are tolerable. Larger variations are not acceptable. The INSITU library itself has no notion of time so it is acceptable to, say, buffer several seconds of data and then call N2 multiple times in rapid succession. It is not recommended that this be done for more than several seconds and all available data should be processed before N3 (See below) is called. 6. The Implementers will populate a C structure described in a NCAR-specified include file (see below) and pass this data to N2 of the TURB module. 7. The Implementers will provide all data in the units specified in the document NCAR In-situ Algorithm Needed Parameters, but also listed below. The Implementers will provide flags (confidence) indicating whether each input datum is good or bad for all of the 8 Hz data provided to N2. 8. The Implementers will make a separate call, N3, to generate EDR estimates. The Implementers will be responsible for downlinking the returned data. See below for information on the TURBREP module which describes the downlinking procedure and report formats. 9. N3 is to be called, to obtain the latest EDR estimates, after every 480 (60 seconds at 8 Hz) calls to N2 until the end of the flight, which should be no later than when the wheels touch the ground. The TURBREP module of the INSITU library assumes the following: 10. Parameters specific to the NCAR TURBREP module will be set in C files and compiled into the code. These should be changed only by NCAR personnel. These parameters will only be modified during testing and before fleetwide deployment. 11. The Implementers will pass data to the TURBREP library both during initialization and normal processing. This includes populating a C structure described in a specified include file (see below) or simply passing float, int, or char data types. 12. The Implementers are responsible for initializing the thresholds (via R1 see below) for the different triggering events as well as the routine reporting interval. All thresholds should be subject to type1_thresh >= type2_thresh >= type3_thresh>= 0. If this is not met, the initialization routine may return 1, indicating that initialization failed. The current recommended values are 0.18, 0.12, and 0.06, respectively. The hb_interval controls the frequency of the routine reports. The current recommended value is 15 or 20 (minutes). It is advisable that

3 the Implementers work with NCAR to determine appropriate values for the thresholds and routine reporting interval if these are not chosen. Though not recommended, if it is desired to change the thresholds during flight, the initialization routine needs to be called before further calls to the TURBREF are made. te that it is possible that all or part of a type 2 or 3 event will not be reported if initialization is performed during the event. 13. As described above the Implementers will call the N3 interface, to obtain the EDR output from the TURB module once every 60 seconds (480 calls to N2), as well as the other information required in each line in the downlink reports, namely: pressure altitude, latitude, longitude, GMT time, wind speed and direction, static air temperature, and the outputs from N3 of TURB: peak and mean EDR, conf, num bad, and the turbulence measurement encoded in a 5 char string. All of this information is to be placed in a circular buffer(s) with length at least The Implementers will provide the mean and peak EDR data to the R2 call of TURBREF exactly as passed out of TURB. The Implementers will set any bad input datum to ISTR_MISSING_DATA as described in a NCAR-specified include file (see below), if there is some problem that the Implementers detects. R2 will return an integer indicating how many (if any) of the last 6 measurements to report. 15. When reporting measurements, the Implementers will report the latest available measurements in order from oldest to newest, in the downlinked report. For example, if TURBREP R2 indicates 1 measurement to be reported, then the latest (newest) measurement is put in the report and downlinked. If 2 are to be downlinked then (in order) the second newest and newest measurements are reported. 16. The Implementers will downlink routine reports periodically. The time interval is controlled by the hb_interval parameter in the initialization step (R1). This should typically be set to 15 or 20 minutes. The triggering logic C code initiates these automatically as long as the other requirements in this document are satisfied. Though strongly discouraged, the hb_interval can be set to 0, in which case TURBREP will not indicate when to downlink routine reports. It is then the responsibility of the implementers to ensure that the routine reports are downlinked at regular intervals. Routine reports should have the same format as triggered reports except that they always contain 1 measurement line. 17. The Implementers shall trigger an end of flight routine report close to but before the aircraft lands (immediately after aircraft touchdown is acceptable and probably the most expedient). There is a corresponding beginning of flight routine report, as well but the triggering logic C code initiates that automatically as long as the other requirements in this document are satisfied. 18. The Implementers will keep track of running maximums of the conf and num_bad which are outputs of N3 of TURB. Each turbulence report will contain, in the last turbulence measurement, two encoded characters (the 2 nd and 3 rd of the 8 turbulence characters) representing these running maximums since the previous downlinked report. For the other measurements in the report, if any, these characters (2 nd and 3 rd ) should be filled with :, indicating missing values. After

4 the report is generated, the running maximums should be immediately reset. If a reset value needs be chosen, -1 is a suitable choice. 19. One potential issue is that it may be possible for a report to be generated after the running maximums have been reset but before TURB outputs new conf and num_bad. For example, suppose at 12:00:00 a turbulence report is triggered, after which the running maximums are reset. If at 12:00:01 the aircraft touches down, the running maximums would still be in a reset stage. If this should occur, i.e. the running maximums are still in a reset state at the time a report is triggered, the characters representing the running maximums in the reports (2 nd and 3 rd characters) should be represented with : s. 20. The format of the turbulence measurement, as dictated by the ARINC 620 format is a 2 character followed by an 8 character string defined below. Character Description 1 The tens of seconds of GMT time (i.e. if the GMT time is 12:34:56, this char should be a 5) 2 Encoded running maximum of conf. 2 Value ,reset value Encoded Value 0-9 A : 3 Encoded running maximum of num_bad. 2 The encoding is the same as conf 4 1 st char from EDR string output from N3 TURB 5 2 nd char from EDR string output from N3 TURB 6 3 rd char from EDR string output from N3 TURB 7 4 th char from EDR string output from N3 TURB 8 5 th char from EDR string output from N3 TURB NCAR insitu library Modules NCAR will provide 6 TURB functions to be called by the Implementers. They are: 1. N1: IST_init: An initialization (or reset) routine. This will need to be called by the Implementers once at algorithm startup, or re-initialization, i.e. after the Implementers has detected a problem like an ACMS reboot. Ideally, this should be performed immediately after takeoff. 2. N1.1: IST_alternateAOAbnds: An optional initialization routine. This routine is used to adjust the angle of attack bounds. minally, the AOA bounds are -5 to 20. AOA values outside these bounds will be flagged as bad. This routine can adjust the AOA bounds in multiples of 5. This routine, if needed, should be called immediately after every call of N1 and before any calls to any other functions. 2 Only the last measurement in the report should have values other than : for this character. See item 17 on page 2 for more details.

5 3. N2: IST_getDataBusInputs: A routine to be called for each 8 Hz data sample. This routine computes quality-controlled vertical winds. Processing of the data ideally begins immediately after N1 and continues until the aircraft touches down. Data should not be passed to the algorithm while the aircraft is on the ground. 4. N3: IST_reportEdrEstimate: Once every minute (after every 480 calls of N2) the Implementers will call N3, which generates a turbulence (EDR) sample. This sample is returned as a 5 character string and contains an encoded summary of the turbulence since the last summary, as well as additional information for use in downlinking (see the document titled InSitu Turbulence Detection Algorithm Interface Control Document for Report Triggering Logic for more information). 5. D1: IST_checkInitVars: An optional diagnostic routine to query the state of the parameters used for initialization. This routine may be called anytime after N1 is called. If N1.1 is used then normally D1 would be called afterwards. 6. D2: IST_checkForErrsWarns: An optional diagnostic routine to query the state of the errors and warnings counters. This routine may be called anytime after N1. NCAR will provide 3 TURBREP functions to be called by the Implementers, if the TURBPREP module is used. They are: 7. R1: ISTR_init: An initialization (or reset) routine. This will need to be called by The Implementers once at startup (i.e. at the same time TURB is initialized) and if re-initialization is necessary, i.e. after the Implementers have detected a problem or wants to change the thresholds for the reports. 8. R2: ISTR_determine_report: A routine to be called every 60 seconds (after 480 calls to N2) for each EDR data sample generated from N3 of TURB (i.e. immediately after TURB N3 routine is called). This routine determines the number of measurements that should be reported, if any, into a single turbulence report and downlinked. The following diagrams try to capture how NCAR envisions the Implementers driver will call these interface functions.

6 Implementers Detect Takeoff N1 Touch down? Implementers sample data bus Yes Implementers enter report triggering logic END N2 Summary Time? N3 Yes Implementers enter report triggering logic Figure 1: Minimal implementation

7 Implementers Detect Takeoff N1 N1.1 Touch down? Implementers sample data bus Yes Implementers enter report triggering logic END N2 Summary Time? N3 Yes Implementers enter report triggering logic Figure 2: Implementation including N1.1

8 Implementers Detect Takeoff N1 N1.1 D1 * Touch down? Implementers sample data bus Yes Implementers enter report triggering logic END N2 Summary Time? N3 D2 * Yes Implementers enter report triggering logic Figure 3: One possible implementation including D1 and D2. te that the timing of the calling of D1 and D2 is quite flexible. * To be useful, the results from D1 and D2 should be saved somehow, for example in a separate downlinked report, for later review.

9 Implementers Initialization R1 Impl. gets new EDR data from TURB (after N3) Impl. puts relevant data into circular buffers R1 YES Did Threshold s change? R2 Did R2 return value > 0 YES Reset running maximums Impl. Reports the number of measurements indicated by R2 Figure 4: Flow diagram for downlinking.

10 NCAR Module Interface Argument Lists N1: int IST_init(float sensormomentarmlength, float AoaCorrCoeff_0, float AoaCorrCoeff_1, float FreqLimitLowerHz, float FreqLimitUpperHz, float EdrScaleFact, int use_bodyangofattack, int output_char_set_option, int run_mode); Inputs: Outputs: Returns: Settings: N1.1: Distance from center of gravity to AOA sensor (ft) AOA calibration coefficient 0 AOA calibration coefficient 1 Lower frequency bounds for EDR calculation Upper frequency bounds for EDR calculation EDR model scale factor Option to use body AOA from input data (1) or to calculate it (0) Option to specify output character set for EDR encoded message. Option to specify the run mode of the software. If 1, which should always be used during development, this will set a flag in the EDR output indicating the EDR values are preliminary. If 2, the software is put in a special mode where N2 will ignore the input data and instead use static data, producing constant EDR. This is useful for testing that the software is working properly. Set this to 0 on final deployment after all testing is complete. ne 0 if initialization succeeded 1 if initialization failed further processing possible. The appropriate settings for these inputs are to be provided in a separate document. int IST_alternateAOAbnds(int option); Inputs: Outputs: Returns: Settings: Option to adjust AOA bounds for the quality control algorithm. The AOA bounds used in the software are (-5 +5 *option) to (20 +5 *option). If N1.1 is not called, the default value used for option is 0 (and thus the bounds are -5 to 20 ). option can be any integer between -3 and 3 (inclusive). ne 0 if initialization succeeded 1 if initialization failed further processing possible. The correct value of option should be determined by examination of the range of values of the input angle of attack during flight, including during turbulence encounters. N2: void IST_getDataBusInputs(QcDataBusInputs anewinputs);

11 Inputs: Outputs: Latest Avionics Data ne N3: void IST_reportEdrEstimate(char *coded_report, float *avg_edr, float *peak_edr, int *conf, int *num_bad); Inputs: Outputs: ne Encoded 5-character characterization of turbulence severity Average EDR over last minute Peak EDR over last minute Encoded confidence associated with the Average and Peak EDR Encoded number of bad points experienced by the algorithm. D1: int IST_checkInitVars(char *out_str, int str_size); Inputs: Outputs: Returns: D2: int Inputs: Outputs: Returns: (str_size) The maximum allowed size of the string.the created message will not exceed this length. It is recommended that the string be at least 64 characters long. (out_str) The message containing the current initialization parameters (the string is right-padded with spaces). This character array should be allocated before being passed to this routine. Length of the message filled by the routine. IST_checkForErrsWarns(char *out_str, int str_size); (str_size) The maximum allowed size of the string. The created message will not exceed this length. It is recommended that the string be quite long, say 500 characters long. (out_str) The message containing the errors and warning counts (the string is right-padded with spaces). This character array should be allocated before being passed to this routine. The total number of errors encountered so far.

12 Relevant sections of include files describing interface structures From InSituTurbAlg.h (sometimes T_ALG.H) for TURB: typedef enum { INP_ALTMSL = 0, /* altitude MSL (ft) */ INP_CALAIRSPEED, /* calibrated air speed (meters/sec) */ INP_ANGOFATTK0, /* 1 angle-of-attack (deg) */ INP_ANGOFATTK1, /* 2 angle-of-attack (deg) */ INP_FLAPANG, /* flap angle (deg) */ INP_PITCHRATE, /* pitch rate (deg/sec) */ INP_PITCHANG, /* pitch angle (deg) */ INP_ROLLANG, /* roll angle (deg) */ INP_IVV, /* inertial vertical velocity (meters/sec) */ INP_CGA, /* center-of-gravity vertical accel. (G)*/ INP_CURRWTLBS, /* current a/c weight (lbs). */ INP_TRUEAIRSPEED, /* true air speed (meters/sec) */ INP_BODYANGOFATTK,/* body angle of attack (deg), used only when use_bodyangofattack on */ INP_NINPUTS } DataBusInputEnum; static char *DataBusInputNames[] = { "AltMsl", /* not used. Can fill with 0 s */ "CalAirSpeed", /* not used. Can fill with 0 s */ "AngleOfAttack", "FlapAngle", /* not used. Can fill with 0 s */ "PitchRate", "PitchAngle", "RollAngle", "InertVertVel", "CtrGravAccel", /* not used. Can fill with 0 s */ "CurrWtLbs", /* not used. Can fill with 0 s */ "TrueAirSpeed" }; typedef struct { float value; float conf; } ValueConfPair; typedef ValueConfPair QcDataBusInputs[ INP_NINPUTS ]; From ISTR_trg.g for TURBPREP: typedef struct { float type1_thresh; float type2_thresh; float type3_thresh; int hb_interval; } EdrInitStruct; #define ISTR_MISSING_DATA tes: The Implementers should set the confidence value, conf, for each input data field. These should be set to zero for bad data and one for good data.

13 Currently, altitude, flap angle, calibrated airspeed, center of gravity vertical acceleration, and current a/c weight are not used and consequently can be set to have a missing value and 0 confidence.