In-Service Data Collection Implementation Plan

1. In-Service Data Collection Implementation Plan

2. Overview • Data collection motivation and constraints • Radar data recording considerations • Proposed implementation • Bill Weist apologies for not being here • Also, for not contacting Airlines, ran into snag when this was associated with FOQA process • Targeted the data recording capability • minimize the impact on the airline and pilots

3. Motivation/Constraints for Data Collection Motivation (from 2nd FAA/NASA workshop): “[Collected] data will provide a statistically-relevant data base for radar validation (nuisance, alerting times…better defined) versus case study development supplied by NASA flight campaign as well as improve business case to the airlines/vendors”. Some Constraints: • Minimize data collection costs for participating airlines • No additional equipment • Minimal affect on operation and maintenance • Minimize affect on flight crews (collection should be “transparent”) • Availability of certified data collection (recording) equipment • Proprietary data • In-situ data is proprietary to airline • Radar data is proprietary to sensor manufacture • Data collection perceptions and liabilities • Let’s make this data collection process independent from “FOQA”

4. Radar Data Recording Considerations • Raw radar data (I/Q) would overwhelm existing certified data recording systems: too much information, like drinking from a fire hose • Each radar manufacturer has “experimental” data collection equipment designed to record raw I/Q data, but this equipment is not certified per part 25 • Radar derived turbulence estimates could under whelm post flight data collection analysis: too little information, like squeezing water from a rock. • Radar derived intermediate data products, zero moments (or dBz), first moments and second central moments per radar range/azimuth bin, are a good compromise. • Can be post processed to help understand radar sensor performance limitations

5. Proposed Implementation • Utilize existing data recording systems • FDAMS (Flight Data Acquisition Management System) PN 967-0212-xxx or 967-0214-xxx • Software re-configurable • Need one “new” A429 connection from radar to FDAMS • Available on many A/C types

6. Existing FDAMS “Temporary” A429 connection Radar Data Download Source of In-situ data: Existing A/C sensors Existing connections Proposed Implementation Hardware Will need airline participation to add “temporary” A429 connection between radar and FDAMS

7. Proposed Implementation • Radar • Forward looking turbulence algorithms • including all aspects of signal processing • including turbulence “hit” threshold • Do we set the threshold a little low to get more data? • Format radar data into A429 words • Transmit A429 words to FDAMS • FDAMS Configuration • Buffer A429 radar data • Buffer in-situ data • Algorithm to compute in-situ turbulence “hit” • Radar and in-situ “hit” thresholds should agree. • Propose 5 sec moving average • Record both radar and in-situ data when either a radar or in-situ “hit” occurs

8. Proposed Implementation FDAMS Data Recording Algorithm • Continuously buffer radar and in-situ data from last two minutes • Wait for trigger event …. • A radar “hit” (encoded into one radar A429 word, location, too) - OR - • An in-situ “hit” (from FDAMS hosted in-situ algorithm) • When triggered • Record buffered data (0 - 2 minute history before “hit”) • Continuously record current radar and in-situ data while trigger active (either radar or in-situ “hit” detected). • After trigger goes away: Continue current radar and in-situ data recording for one minute (0 - 1 minute after “hit”)

9. Proposed Implementation In-Situ Data Requirements (from Roland Bowles) Minimum: • Body axis acceleration (x,y,z) at 8Hz • Angle of attack at 4Hz • Body axis inertial angles (,,) at 4Hz • True Air Speed at 4Hz • Altitude at 1Hz • Ground Speed at 1Hz • Inertial winds: Cartesian (NS/EW) or polar (speed/direction) at 1Hz • Time at 1Hz Nice to have: • A/C latitude and longitude at 1Hz • IRU vertical speed at 1Hz

10. Proposed Implementation Some TBDs • In-situ algorithm hosted by FDAMS Will need input from Larry Cornman and Roland Bowles • A429 radar “trigger” word definition Collins and Honeywell will work together to select label number (1 out of 1024 possible labels) and define radar trigger bit. • A429 radar data words definition Likely to be radar manufacturer proprietary since 1023 words will need to convey all radar data for multiple range bins and multiple turbulence scans. We should however agree on some minimum standards for radar parameter resolution and range such as: • DBz (or SNR) in 1dB steps from 0dBz to 31dBz • First moment in 0.5m/s steps from -Va to +Va (Va = radar dependent ambiguous velocity) • Square root second moment in 0.25m/s steps from 0m/s to 10m/s

11. Proposed Post Processing • Each radar manufacturer will develop proprietary software to post process FDAMS recorded radar and in-situ data. This software will be made available to • Participating airline • FAA/NASA • Participating airline will download FDAMS data • Usually on a 4-7 day cycle depending on what other parameters are being recorded. • Data will be post processed by the radar manufacture and optionally by the participating airline and the FAA/NASA.

12. Proposed Post Processing • Processed data will be sorted into three cases (the null case, no radar or in-situ “hit” is not recorded): • Radar and in-situ both indicate “hits” • Determine radar predicted and in-situ severity • Determine timeliness of radar alert • Determine atmosphere reflectivity • Radar indicates a “hit”, in-situ shows no “hit” • Determine location of radar alert (may be offset from flight path) • Determine in-situ severity (may be just below in-situ “hit” threshold) • Determine reflectivity • Radar shows no “hit”, in-situ indicates a “hit” • Determine in-situ severity why radar missed event • Radar manufacturer will prepare a proprietary report summarizing results which will be shared with the participating airline and the FAA/NASA