DFDR DATA READOUT

CHAPTER 1 Introduction
1.1 FLIGHT DATA RECORDER A required device that records pertinent parameters and technical information about a flight. At a minimum, it records those parameters required by the governing regulatory agency, but may record a much higher number of parameters. An FDR is designed to withstand the forces of a crash so that information recorded by it may be used to reconstruct the circumstances leading up to the accident. Flight Data Recorders (FDR) was first introduced in the 1950s. The purpose of an airplane FDR system is to collect and record data from a variety of airplane sensors onto a medium designed to survive an accident. Depending on the age of an airplane, the FDR system may consists of an analog or a digital flight data acquisition unit and a digital recorder. FDR may have a tape or solid-state memory. The data collected in the FDR system can help investigators determine whether an accident was caused by a pilot error, an external events (such as weather), or an airplane system (such as mechanical or electrical failures). The first generation of FDRs recorded only five parameters including acceleration, air speed, compass heading, time and altitude. This data was embossed onto steal foil, and was capable of recording for 400 hours at which time the foil must be replaced. The second generation FDRs introduced in the 1970s aimed to collect more data but they were unable to process the incoming sensor data in a timely manner. This led to the development of a separate flight data acquisition unit (FDAU). The FDAU processes sensor data, digitizes and formats it for transmission to the FDR. The second generation of digital FDR (DFDR) used (magnetic) recording tape. Most DFDRs can record and store up to 18 operational parameters for a period 25 hours. Third generation FDRs (known as SSFDR) were introduced in 1990 and used solid-state technologies for recording data. These recorders can record up to 256 operational parameter for 25 hours

JCET, LAKKIDI

DFDR DATA READOUT

1.2 HISTORY During World War II the NACA V-g recorder was introduced in transport, bomber and fighter aircraft to assess the operational loads met infrequently and structural design requirements for aircraft. This instrument records the peak accelerations and the speed at which these occur in flight. By 1950 the data from these instruments had become inadequate due to the importance of fatigue damage and the need for aircraft height to assess the structural and aerodynamic implications of gust or manoeuvre loads. Thus V-gh continuous trace recorders in the USA and counting accelerometers in the UK were introduced in the early 1950s In Australia, Dr David Warren was certain of the importance of recorded data for accident investigation purposes and he and his team at ARL pioneered the development of a combined voice and data recorder. During the 1960s, regulatory authorities around the world began to require FDRs and CVRs to be fitted to large commercial aircraft. Today the FDR and CVR are an accepted part of aviation with the debate now about the need for image recorders and extending recorder carriage requirements to smaller aircraft. 1.3 TECHNICAL EVOLUTION: Both crash-protected flight data recorders (FDRs) and optional quick access recorders (QARs) began to be installed on commercial aircraft in the 1960s. The evolution of these data collection devices is shown by using the following aircraft types as examples:

Table 1: Technical evolution

JCET, LAKKIDI

DFDR DATA READOUT

Figure 1: Access to FDR via access panel in rear fuselage

Figure 2: The canister in the tail containing the FDR Boeing 707 The Boeing 707 (B707) was typically equipped with a five parameter analogue FDR. Data was recorded by engraving traces onto a metal foil. Within the recorder were pitot/static and electrical sensors separate to the aircraft sensors used by the crew. Calibration of the FDR sensors and general reliability of a mechanical recorder were problems for investigators relying on this data.

JCET, LAKKIDI

DFDR DATA READOUT

Figure 3: Davall Wire FDR Airbus A330 The A330 is equipped with a solid-state FDR and a separate solid-state CVR. The FDR receives data from an interface unit so the FDR system is a two-box system. Additionally some airlines choose to fit a QAR that receives data from the same interface unit as the FDR and records the same parameters as the FDR. Figure 4 shows a QAR and FDR connected to the same acquisition unit. This configuration requires three boxes. A QAR can also receive data from a separate Data Management Unit (DMU). When a DMU is used, Airbus label the recorder a DAR rather than a QAR. With a DMU, the airline can program the parameters that the DAR will record so it is more flexible than a QAR which records exactly the same parameters as the FDR. Four separate avionics boxes are required for an aircraft equipped with an FDR and a DAR.

Figure 4: FDM system architecture

JCET, LAKKIDI

DFDR DATA READOUT

Embraer 170 Embraer 170 aircraft are equipped with two digital voice data recorders (DVDRs). A DVDR is a combi-recorder that records both cockpit audio and flight data in a single box. To improve the probability of both audio and flight data surviving an accident, one DVDR is located in the front of the aircraft and one in the rear of the aircraft as shown in Figure 5. There is an advantage to the operator in having only a single part number in their inventory and presumably some MEL relief would apply as well.

Figure 5: DVDR location in the Embraer 170 Airbus A380 The A380 will have networked avionics architecture but will retain the standard configuration of a solid-state FDR and a separate solid-state CVR. Rather than a separate QAR, A380 operators will be able to use the two servers that will be installed on-board running the Linux operating system. Information stored on the servers will include flight data, flight operations quality assurance data, electronic flight bag documents and other
JCET, LAKKIDI

DFDR DATA READOUT

software. The two Airbus servers will receive data through a secure communications interface from the A380s Avionics Full Duplex (AFDX) switched Ethernet avionics network. A380 operators will be able to choose to add a third server attached to the network through a secure router. The operator can then host its own applications and modify them at will as long as configuration control is maintained. Applications such as weight and balance, troubleshooting guides and wiring diagrams could be hosted. Boeing 787

Figure 6: Boeing 787 Dreamliner The B787 will have networked avionics architecture and will be fitted with two enhanced airborne flight recorders (EAFRs). Each EAFR will combine the functions of a CVR and FDR giving system redundancy. A separate flight data acquisition unit (FDAU) will not be needed as a virtual FDAU will be distributed among other software and hardware including the EAFR itself. This will reduce the total weight as a separate line replaceable unit for the FDAU will not be needed. 1.4 TYPES OF FLIGHT DATA RECORDER Metal foil and photographic film recorders Boeing 707s, DC8s and Caravelles were the first jet engine aircraft to be equipped with FDRs in the early sixties. These recorders consisted of a mechanical stylus engraving a metal foil. For metal foil FDRs, the parameters are processed internally with data coming in directly from basic aircraft sensors, such as accelerometers and pitot tubes. At about the same time, a similar technology consisted of replacing the sheet of metal
JCET, LAKKIDI

DFDR DATA READOUT

with a photographic film and the mechanical stylus with light beams. That was the photographic film FDR. Both types of FDRs could only monitor a limited number of important parameters, usually 5 or 6, such as magnetic heading and airspeed.

Figure 7: Metal foil FDR Magnetic Tape Recorders Metal foil and photographic film FDRs started to fall behind in relation to investigation needs in 1965. With the introduction of magnetic tape-based recorders, it became possible to not only record conversations but also to progressively increase the number of parameters monitored by FDRs. With the new magnetic FDRs, parameters were no longer recorded in a single stream. Instead, they were first sampled, digitalized and multiplexed inside a 1- second long frame. Then, this digital frame was recorded on a magnetic tape using simple signals to code 0s and 1s. Hence the name Digital Flight Data Recorder (DFDR).

Figure 8: Magnetic Tape recorder Acquisition unit

JCET, LAKKIDI

DFDR DATA READOUT

As the need for more parameters grew and as new digital technology appeared, it became inadequate to have FDRs compute parameters internally based on data received from sensors. Flight data acquisition devices began to be designed to collect all parameters before being recorded. These devices include the Flight Data Acquisition Unit (FDAU), Flight Data Interface Unit (FDIU) or Flight Data Acquisition Card (FDAC). They order data and then send it to FDRs, whose function is then limited to data recording It is important to note that mainly large aircraft in the public transport category are equipped with data acquisition units. For smaller aircraft, the data acquisition function is still often performed by FDRs. Solid state recorders With the evolution of digital technologies, solid-state memory cards replaced magnetic tapes in FDRs around 1985. Recordings on these new Solid State Flight Data Recorders (SSFDR) have far better restitution reliability than on the magnetic FDRs.

Figure 9: SSFDR As memory cards got smaller, the number of recorded parameters went up to several hundred, sampling frequencies increased and recording times of some models rose to 50 hours or more. Sound recorders also benefited from this technological evolution, with not only the possibility of recording sound digitally, but also with a recording time that was extended to 2 hours as opposed to half an hour for magnetic tape-based CVRs. Non-protected recorders The introduction of data acquisition units has also benefited what is commonly called flight data monitoring. FDRs were the only devices recording data and that data was only used after an accident. Now, with data acquisition units, data is also directed to other types of recorders. These recorders are not protected. The recording media can be a
JCET, LAKKIDI

DFDR DATA READOUT

tape, an optical magnetic disc or a PCMCIA card. The recording media is designed to be removed and replaced quickly. The access to the recording media is located either in the cockpit or in the electronics bay. Quick Access Recorders (QARs) usually record exactly the same data as FDRs. On-board an aircraft, the data acquisition unit feeds both the FDR and the QAR. The most recent QARs also have input ports compatible with the standard aircraft buses (ARINC 429) and can therefore receive additional data. Direct Access Recorders (DARs) receive data from Data Management Units (DMUs) and can be programmed not only to select which parameters to record and with which sampling frequency, but also to select the recording mode: periodic recording or recording triggered by events such as a parameter passing over a pre-determined threshold. These recorders are used for maintenance, research or flight data monitoring purposes.

CHAPTER 2
JCET, LAKKIDI

DFDR DATA READOUT

10

FLIGHT DATA MONITORING

2.1 WHAT IS FDM? Flight Data Monitoring (FDM) is the systematic, pro-active and non-punitive use of digital flight data from routine operations to improve aviation safety. Flight Data Monitoring (FDM) programmes assists an operator to identify, quantify, assess and address operational risks. Since the 1970s the CAAs Safety Regulation Group (SRG) has helped develop and support such systems and used FDM information to support a range of airworthiness and operational safety tasks. Through this co-operative development work many farsighted operators have demonstrated the safety benefits of FDM such that the International Civil Aviation Organization(ICAO) have recommended their use for all Air Transport operations in aircraft of over 20 tonnes maximum weight. Further, they are making FDM a standard for all such operations of aircraft over 27 tonnes with effect 1st January 2005. The UK, in continuing its policy of applying ICAO standards, will make this a requirement under UK law and other European regulators are also expected to comply. The UK Air Navigation Order 2000 (ANO 2000) Article 34A will require the establishment and maintenance of an Accident Prevention and Flight Safety Programme (AP&FSP) and includes the requirement for FDM. The content of safety programmes, including FDM, will need to be confirmed as acceptable by the CAAs Flight Operations Inspectors. It is recognised that there is a wide range of operators covered by these requirements and that there is no one size fits all system. The size and age of aircraft may determine the parameters available for analysis. The programme effectiveness and efficiency of a small fleet or operation may be helped by pooling analysis within a group of similar operations. While retaining responsibility for risk assessment and action, some operators may wish to contract out the basic analysis due to lack of expertise or resources.

2.2 OBJECTIVES OF AN OPERATORS FDM SYSTEM 1 A FDM system allows an operator to compare their Standard Operating
JCET, LAKKIDI

Procedures (SOPs) with those actually achieved in everyday line flights. A feedback loop,

DFDR DATA READOUT

11

preferably part of a Safety Management System (SMS), will allow timely corrective action to be taken where safety may be compromised by significant deviation from SOPs. The FDM system should be constructed so as to: 2.2.1 Identify areas of operational risk and quantify current safety margins. Initially a FDM system will be used as part of an operators System Safety Assessment to identify deviations from SOPs or areas of risk and measure current safety margins. This will establish a baseline operational measure against which to detect and measure any change. Example: Current rates of rejected take-offs, hard landings, unstable approaches. 2.2.2 Identify and quantify changing operational risks by highlighting when nonstandard, unusual or unsafe circumstances occur. In addition to highlighting changes from the baseline, the system should enable the user to determine when non-standard, unusual or basically unsafe circumstances occur in operations. Example: Increases in above rates, new events, and new locations. 2.2.3 To use the FDM information on the frequency of occurrence, combined with an estimation of the level of severity, to assess the risks and to determine which may become unacceptable if the discovered trend continues. Information on the frequency of occurrence, along with estimations of the level of risk present, is then used to determine if the individual or fleet risk level is acceptable. Primarily the system should be used to deduce whether there is a trend towards unacceptable risk prior to it reaching risk levels that would indicate the SMS process has failed. Example: A new procedure has introduced high rates of descent that are approaching the threshold for triggering GPWS warnings. The SMS process should have predicted this. 2.2.4 To put in place appropriate risk mitigation techniques to provide remedial action once an unacceptable risk, either actually present or predicted by trending, has been identified.
JCET, LAKKIDI

DFDR DATA READOUT

12

Once an unacceptable risk, either actually present or predicted by trending, has been identified, then appropriate risk mitigation techniques must be used to put in place remedial actions. This should be accomplished while bearing in mind that the risk must not simply be transferred elsewhere in the system. Example: Having found high rates of descent the Standard Operating Procedures (SOPs) are changed to improve control of the optimum/maximum rates of descent being used. 2.2.5 Confirm the effectiveness of any remedial action by continued monitoring. Once a remedial action has been put in place, it is critical that its effectiveness is monitored; confirming that it has both reduced the original identified risk and not transferred the hazard elsewhere. Example: Confirm that the other measures at the airfield with high rates of descent do not change for the worse after changes in approach procedures.

Figure 10: Flight Data monitoring 2.3 DESCRIPTION OF A TYPICAL FDM SYSTEM 2.3.1 System Outline - Information Flow

JCET, LAKKIDI

DFDR DATA READOUT

13

Figure 11: FDM Data Flow 2.3.2 Aircraft Operations - Data Acquisition Data is obtained from the aircrafts digital systems by a Flight Data Acquisition Unit (FDAU) and routed to the crash protected Digital Flight Data Recorder (DFDR). In addition to this mandatory data stream, a second output is generated to a nonmandatory recorder. This output is often more comprehensive than that of the crash recorder due to the increased capacity of this recorder. Unlike the DFDR, this recorder has a removable recording medium such as a tape or optical disk cartridge. Because these are easy to gain access to replace the medium, these are known as Quick Access Recorders (QARS).

JCET, LAKKIDI

DFDR DATA READOUT

14

Figure 12: Flight Data Recording system The QAR tapes/disks are replaced at the end of each day or sometimes after a period of several days have elapsed, dependent on media capacity and data recovery strategy, and sent to a central point for replay and analysis. This normally takes place at the operators major hub airport for convenience. As an alternative to the QAR, some operators routinely download information contained on the crash recorder. While this is not practicable with the older, tape based devices, the modern solid-state recorder is reliable and fast. The technology also exists to download straight from an on-board storage device to an operators file server via wireless links. This reduces the logistical problems associated with the movement of media or physical downloading tasks. Chapter 5 paragraph 6 technical specification gives an outline of some of the current technologies applicable to FDM.

2.3.3 Ground-Based Data Replay and Analysis Programs The tapes/disks are logged in and replayed through a suite of computer programs starting with one that converts the raw binary data into engineering units. Aircraft, recorder and tape/disk data quality and other checks are made and recorded for trending purposes. Verification and validation procedures are critical at this stage to increase the reliability of output. Traditionally the data has been processed through analysis programs, retained for a set period of time for air safety report follow-up and then destroyed. However, the retention of the data, or at least a selection of the parameters, for
JCET, LAKKIDI

DFDR DATA READOUT

15

amalgamation into longer term historical views of operations is now considered to be essential. This may be held in either raw or processed form. 2.3.4 The Information A) Exceedence Detection Exceedence or event detection is the traditional approach to FDM that looks for deviations from flight manual limits, standard operating procedures and good airmanship. There is normally a set of core events that cover the main areas of interest that are fairly standard across operators. Example: High take-off rotation rate, stall warning, GPWS warning, flap limit speed exceedence, fast approach, high/low on glideslope, heavy landing. B) Routine Data Measurements Increasingly, data is retained from all flights and not just the significant ones producing events. The reason for this is to monitor the more subtle trends and tendencies before the trigger levels are reached. A selection of measures is retained that are sufficient to characterise each flight and allow comparative analysis of a wide range of aspects of operational variability. Examples of parameters: take-off weight; flap setting; temperature; rotation and take-off speeds vs scheduled speeds; maximum pitch rate and attitude during rotation; gear and retraction speeds, heights and times. Examples of analysis: Pitch rates from high vs low take-off weights; pilot technique during good vs bad weather approaches; touchdowns on short vs long runways. C) Incident Investigation Data FDR data should be used as part of the routine follow-up of mandatory occurrences and other technical reports. FDR data has been found to be very useful in adding to the picture painted by the flight crew report, quantifying the impressions gathered from the recollections after the heat of the moment. System status and performance can add further clues to cause and effect. FDR data obtained for use in this way falls under the mandatory requirements of JAR-OPS and hence de-identification of
JCET, LAKKIDI

DFDR DATA READOUT

16

the data, required to maintain FDM confidentiality, does not usually apply. As the crew have already filed reports then this is reasonable in an open, pro-active safety culture that provides constructive feedback. Examples of Incidents where FDR data could be useful: vortex wake encounters; all flight control problems; system failures that affect operations; emergencies such as high speed abandoned take-offs; TCAS or GPWS triggered manoeuvres. D) Continued Airworthiness Investigation Data Both routine and event data can be utilised to assist the continued airworthiness function. Engine monitoring programs use measures of engine operation to monitor efficiency and predict future performance. These programs are normally supplied by the engine manufacturer and feed their own databases. Operators should consider the potential benefits of including the wider use of this data within their continued airworthiness programmes. Examples of continued airworthiness uses: Engine thrust levels; airframe drag measurement; avionic and other system performance monitoring; flying control performance; brake and landing gear usage. E) The Information Database All the information gathered should be kept either in a central database or in linked databases that allow cross-referencing of the various types of data. These links should include air safety and technical fault reporting systems to provide a complete view of the operation. Where there is an obvious tie up between the systems then this should be highlighted by the system. Example of links: A heavy landing should produce a crew report, a FDR event and also an airworthiness report. The crew report will provide the context, the FDR event the qualitative description and the airworthiness report the result. F) Operators Departments - Assessment and Follow-up This is the critical part of the process. Given the systems are put in place to detect, validate and distribute the information; it finally reaches the areas where the safety and continued airworthiness benefits may be realised. The data must be assessed using firstJCET, LAKKIDI

DFDR DATA READOUT

17

hand knowledge of the operational or airworthiness context in which it is set. Final validation done at this informed level may still weed out some erroneous data. Example of follow-up: During a routine analysis of go-arounds it was found that one had a delay of over 20 seconds between flap selection and raising the gear. G) Remedial Action Once a hazard or potential hazard has been identified, then the first action has to be to decide if the level of risk is acceptable. If not, then appropriate action to mitigate the effect should be investigated along with an assessment of the fuller effects of any proposed changes. This should ensure the risk is not moved elsewhere. The responsibility for ensuring action is taken must be clearly defined and those identified must be fully empowered. Example of Remedial Action: In the go-around case described above, the operator included go-arounds in the next simulator check sessions. These highlighted how easy it was to miss the gear action if the positive climb call was missed by the non-handling pilot. It stressed the importance of a team effort during go-arounds. H) Continued Monitoring Once any action is taken, then an active monitor should be placed on the original problem and a careful assessment made of other hazards in the area of change. Part of the assessment of the fuller effects of changes should be an attempt to identify potential relocation of risks. This, plus a general monitor on all surrounding measures is required before signing off the change as successful. This confirmation, or otherwise, would be expected to feed into a high level management group to ensure remedial action takes place. 2.4 INTERPRETATION AND USE OF FDM INFORMATION

2.4.1 Interpretation of Results - The Raw FDR Data Interpretation and verification of the basic FDR data is a critical, if somewhat laborious, operation. The well-known adage of rubbish in - rubbish out very much applies here.
JCET, LAKKIDI

DFDR DATA READOUT

18

A) Validation Checking Strategy Most parameters required for the FDM programme are seen on every flight and these should be checked both by the program and visually. However, a number of parameters are rarely used except in more detailed analysis of incidents and these should be validated whenever the opportunity arises. There are also a number of rarely triggered warnings, operating modes etc. that can only be tested by complex procedures in the maintenance workshop. Reference to the validation and certification of the mandatory crash recorder may assist in this process. A strategy outlining the frequency of checks and documenting opportunity checks during analysis should be laid down as part of the basic system maintenance procedures. Examples of common use parameters: airspeed, altitude, air/ground switches, accelerations, flight controls, main auto-flight modes. Examples of infrequently used parameters: alternate flap, less common auto-flight modes, GPWS and other warnings. Examples of difficult to check parameters: hydraulic pressure warning; fire warnings, N1 over speed. B) Watch for Bad Data, Datum Errors etc. There are a range of basic data faults which can be either established demanding changes in equipment or software, or transient such as a faulty transducer or processing unit. Example of a Transducer Error: accelerometers occasionally stick and have an offset datum, say of 1.3g rather than 1.0g when at rest, or lose damping so they are over sensitive and hence reading too high. Examples of Data Acquisition faults: One pitch angle sample each second does not follow the trend of the rest of the data. This can be caused by the system picking a sample from the previous seconds data stream. Normal acceleration data can be filtered by passing through a system unit that removed high frequency data. Hence no heavy landing g peaks!

JCET, LAKKIDI

DFDR DATA READOUT

19

C) Establish Characteristics of "Normal" Data The essence of good interpretation is an ability to detect what is different or unusual. To do this the analyst must have knowledge of what normal data looks like and the variations that fall within a reasonable range. Example of Parameter Characteristics: normal acceleration has a higher frequency content on the ground than on the air, has no stunted peaks, a 30 degree co-ordinated level turn should produce 1.15g and 45 degrees 1.4g. D) Cross-check Significant and Related Parameters Where possible establish the technique of cross-checking between related parameters. For example, at rotation confirm pitch up is accompanied by an increase in normal acceleration, an elevator up control movement and is followed by the air/ ground switch moving to AIR. Other Examples of Related Parameters: EPRs on engines normally are similar; heading changes with bank angle; opposing aileron deflections at turn initiation but the same sign during load relief or drooping with flap selection; positive longitudinal acceleration as ground speed increases. E) Relate Data to SOPs Data and events should always be placed in the context of the operators Standard Operating Procedures. It would be useful to annotate a typical flight with the SOP action points. Examples of SOP Points Relevant to an Exceedence Program: the following speeds are used for configuration changes after take-off - at positive climb retract gear; above 5 ft AGL - autopilot on, speed not less than V2+10 or max pitch 18 degrees; at 1000 ft GL select flaps up and set climb thrust. 2.4.2 INTERPRETATION OF RESULTS - THE OPERATIONAL ASSESSMENT During this part of the process the validated FDR data is assessed using knowledge of the operating environment and standards. It is here where the safety lessons will emerge and action decided upon.
JCET, LAKKIDI

DFDR DATA READOUT

20

A) Further Validity Checks While most basic data errors should have been eliminated by this stage, more subtle data problems may still exist. In addition, where incidents seem inexplicable then errors in the data or in the program have been found to be present. Examples of subtle errors: aircraft weight, parameter offsets, radio altimeter faults, airbrake lever arm position. Examples of program errors: incorrect source of weight data taken, schedule speed reference table error, wrong event limits/specification. B) Set Events in Context Take-off and Approach events should be taken in the context of the physical and procedural characteristics of the particular airfield. During periods of bad weather, this also has to be taken into account. Examples of airfield related context: location/local geography, altitude, runways, procedures including noise abatement, approach aids, ATC standards. C) Correlation with Relevant Air Safety Reports By this stage all events should have been correlated with relevant Air Safety Reports to give the best possible picture of these, normally more significant incidents. This will also prevent two separate investigations taking place into the same incident, each using only partial data. Normally, an interpreted summary of the FDR data should be added to the ASR investigation file and the follow-up controlled by the normal flight safety process within the operators safety management system. Examples of events normally covered by ASRs: GPWS, stick shakes, loss of control, heavy landings etc. See CAA CAP 382 for details of the requirements laid down in the Air Navigation (General) Regulations 1993 Article 17. D) The Need for Crew Debrief for Background Information At an early stage in the assessment, a decision should be made if more information on the circumstances of the event should be obtained. In this case the confidential crew contact procedures should be initiated and the sooner they are contacted after the event the better their recollection will be. The timely correlation with any
JCET, LAKKIDI

DFDR DATA READOUT

21

relevant ASRs will prevent wasted effort and duplication. The information gathering objectives of such a debrief include learning of: ATC involvement, Weather, Technical problems, Procedural difficulties, Operational lapses, other traffic. The training objectives may include: re-enforcement of SOPs, reminders of ASR requirements, congratulations for well-handled emergencies such as a well flown windshear recovery. Examples of cases benefiting from a confidential crew debrief: hurried approaches at busy airports, take-off rotation technique, unreported heavy landing, inappropriate autopilot mode use, SID technique, altitude busts E) Degree of Direct or Indirect Hazard It is best if the degree of hazard is estimated to enable resources to be targeted at the most beneficial reduction in hazard. This may be to prevent a large number of relatively low risk events or to eliminate a low number of high risk events. In assessing the level of risk, the analyst must take into account both the direct risks and those that may be a consequence of those circumstances. Example of a direct risk: a hard GPWS warning while an indirect one would be a plethora of false warnings - of little risk in themselves but if reducing the effectiveness of standard recovery from a real warning these could be catastrophic if not addressed. F) Assess Potential Accident Factors It is useful if a list of precursors of and causal factors in previous accidents is drawn up to further highlight potential hazards. These again may be relatively low risk events in their own right but good indications of the probability of further, more significant incidents. Examples of accident precursors: positional errors, auto vs manual flight conflict, landing technique, directional control during take-off and landing runs. G) Assess Frequency - Single Event or Systematic Problem The events should be assessed in the context of previous experience. One of a series showing a trend or a one-off incident in exceptional circumstances. Clusters of events may occur at a particular airfield, on one aircraft or during a period of bad weather.
JCET, LAKKIDI

DFDR DATA READOUT

22

By placing all events on a database will enable the analyst to decide an informed course of action. H) Taking Action - The Decision Process As with any safety report, the responsible analyst must decide if it is appropriate to take action to prevent repetition. Action could be required due to safety severity (through individual risk or high frequency), financial or operational implications. Actions and the underlying reasons and data used should be recorded to provide an audit path. I) Continuous Monitoring of Result of Actions After taking action, anticipated knock-on effects should be carefully monitored to ensure no risks are transferred elsewhere.

CHAPTER 3
JCET, LAKKIDI

DFDR DATA READOUT

23

LEGISLATION AND REQUIREMENTS RELATED TO FDM

3.1 OBJECTIVE Decoding and analysis of the DFDR/ QAR/ PMR data is one of the major tools to identify the hazards and system deficiencies in aircraft operations before they may result in an accident. All scheduled operators & major non-scheduled operators are therefore required to monitor DFDR/ QAR/ PMR data to determine deficiencies/ shortcomings in the operation of aircraft. This CAR lays down the requirements and procedure in this regard. It is issued under the provisions of Rule-133A of the Aircraft Rules, 1937.

3.2 REQUIREMENTS FOR DATA MONITORING All operators engaged in scheduled air transport services and major nonscheduled operators having aircraft equipped with DFDR, shall develop procedures, establish facilities and monitor DFDR/ QAR/ PMR data of all flights to determine exceedences in flight parameters from the stipulated limits. The operators shall lay down in their flight safety manuals detailed programme in this regard which shall be followed meticulously. The programme should be periodically reviewed to maintain it effective.

3.3 INSTALLATION OF QUICK ACCESS RECORDERS (QAR)/ PERFOMANCE MONITOR RECOREDERS (PMR) All the aircraft installed with DFDR should be fitted with QAR/ PMR units for easy retrieval of the recorded data.. Till this is achieved, manual downloading of the data from DFDR units shall be carried out regularly without loss of any flight data to ensure that the data of all the flights is analysed. 3.4 ESTABLISHMENT OF MONITORING FACILITIES

JCET, LAKKIDI

DFDR DATA READOUT

24

3.4.1

Dedicated monitoring cells with adequate number of trained personnel shall be established by the operators to ensure that data monitoring is carried out on continuous basis without any breakdown.

3.4.2

Suitable arrangements/ network shall be established for inflow & outflow of the QAR/ PMR / Downloaded data between various stations and the monitoring cell.

3.4.3

Adequate and suitable hardware and software shall be provided so that failure of any single unit does not lead to breakdown of the system.

3.4.4

Suitable software package shall be developed / procured which can give output in the form of digital data, graphical presentation & 3-D presentation of the recorded data.

3.4.5

Exceedence limits of various parameters shall be established by the operators for each type of aircraft within the limits given in Annexure-A. These shall be stipulated in their Flight Safety Manuals.

3.4.6

There should be provision in the software package to change the threshold values of exceedences, as required.

3.4.7

Operators shall revise the threshold values of the exceedences from time to time & introduce new parameters based on the experience to make the monitoring system more stricter.

3.4.8

The exceedence values used for monitoring shall be submitted to the Air Safety Directorate of DGCA (Hqrs)

3.5 ANALYSIS OF DATA & PREPARATION OF REPORTS 3.5.1 Entire data of each flight shall be analysed to determine if any flight parameter had exceeded the laid down limit. If any exceedance is detected appropriate report for the same shall be generated in the format given in the Annexure 'B', giving the actual value of the parameter, the specified
JCET, LAKKIDI

DFDR DATA READOUT

25

limit for the same, the time of the event and the other relevant flight details. Hard copy of the report shall be printed for futher analysis and review. 3.5.2 For the flights in which the exceedances are detected, a detailed analysis of flight shall be carried out to check whether or not the flight was handled as per the Standard Operating Procedures. As there are more accidents during approach and landing phases, detailed analysis of the approach and landing phases of all flights shall be carried out, to detect any deviations from the normal approch profile and whether the approch was stabilised or not. 3.5.3 At the airfields where special take off procedure have been laid down, the data analysis should cover whether the take-off profile of the flight was as per the special procedure or not. 3.5.4 Daily reports for the exceedences of parameters shall be generated for all the types of aircraft and put up for review and flight analysis by the dedicated senior officials. 3.5.5 Suitable corrective action to overcome the deficiencies / shortcomings observed during analysis of the data shall be taken. 3.5.6 Counselling of the crew members on the deficiencies observed shall be carried out by the operator 3.5.7 A quarterly statistical report giving summary of general findings and suggested corrective measures shall be prepared covering all type of aircraft and circulated to its operational personnel. 3.5.8 During the refresher courses, the results and findings of the analysis will be discussed for the benefit of the crew members. 3.5.9 Proper records shall be maintained of all the findings and corrective measures taken.
JCET, LAKKIDI

DFDR DATA READOUT

26

3.5.10 The Flight Safety Division of the operator shall ensure effective functioning of the programme in coordination with the operations, training and other concerned Divisions. 3.6 GENERAL While the Air Safety Directorate of DGCA Headquarters shall monitor the overall implementation of the programme, the Regional Air Safety and Airworthiness Offices, Flight Inspection Directorate, Audit Teams, accident/incident investigators and other officers authorised by DGCA, shall also check implementation of the provisions of this CAR during the course of their checks. The programme should be reviewed to assess its effectiveness and amended, if necessary, in the light of the experience gained and the developments in the civil aviation sector. 3.7 7 ICAO Annex 6 Part 1 - CHAPTER 3. GENERAL 3.6 Accident prevention and safety programme 3.6.1 An operator shall establish and maintain an accident prevention and flight safety programme. 3.6.2 Recommendation. From 1 January 2002, an operator of an aeroplane of a certificated take-off mass in excess of 20,000kg should establish and maintain a flight data analysis programme as part of its accident prevention and flight safety programme. 3.6.3 From 1 January 2005, an operator of an aeroplane of a certificated take-off mass in excess of 27,000kg shall establish and maintain a flight data analysis programme as part of its accident prevention and flight safety programme. Note. - An operator may contract the operation of a flight data analysis programme to another party while retaining the overall responsibility for the maintenance of such a programme. 3.6.4 A flight data analysis programme shall be non-punitive and contain safeguards to protect the source(s) of the data.

JCET, LAKKIDI

DFDR DATA READOUT

27

CHAPTER 4 FLIGHT OPERATIONAL QUALITY ASSURANCE

4.1 FOQUA Flight Operational Quality Assurance (FOQA). A voluntary program for the routine collection and analysis of flight operational data to provide more information about, and greater insight into, the total flight operations environment. A FOQA program combines these data with other sources and operational experience to develop objective information to enhance safety, training effectiveness, operational procedures, maintenance and engineering procedures, and air traffic control (ATC) procedures. Flight Operational Quality Assurance (FOQA) is defined as a program to improve flight safety by providing more information about, and greater insight into, the total flight operations environment through selective automated recording and analysis of data generated during flight operations. Analysis of FOQA data can reveal situations that require improved operating, training, and maintenance procedures, practices, equipment, and infrastructure.

4.2 FOQA PROGRAM COMPONENTS The principal components that will compose the FOQA program at [Airline Name] are described below and are illustrated in Figure 13. 4.2.1 Aircraft Fleet The [Aircraft Model/Type] aircraft will be the launch aircraft for the [Airline Name] FOQA program. Twenty of these aircraft will be used to initiate the FOQA program. These aircraft will be equipped with the [Product Name] Flight Data Acquisition Management System on a schedule established by [Airline Name] Maintenance and Engineering. Additional aircraft will be added to the FOQA program pending approval from the FOQA Monitoring Team (FMT) as sufficient experience is gained on data acquisition and analysis.
JCET, LAKKIDI

DFDR DATA READOUT

28

4.2.2 Airborne Data Acquisition System [Airline Name] will be utilizing the [Product Name] Quick Access Recorder. This recorder collects continuous flight data parameters and stores this information on the [Specify Storage Media, e.g., PCMCIA card]. 4.2.3 Data Download and Airborne System Maintenance and Support The Flight Data Acquisition Management System and Quick Access Recorder will be maintained per the FAA-approved [Airline Name] aircraft maintenance program. Avionics Engineering will be responsible for managing this process. The [Storage Media] will be downloaded [specify frequency] by means of [Specify Downloading Methodology, e.g., removal and replacement of PCMCIA cards]. The FOQA Manager will be responsible for coordinating maintenance issues with [Airline Name] Avionics Engineering regarding data download and any Flight Data Acquisition Management System
problems discovered during data analysis.

4.2.4 Ground Data Replay and Analysis System (GDRAS) The GDRAS is designed to process and analyze data from all FOQA-equipped aircraft in the [Airline Name] fleet. It will apply protective mechanisms, including removal of identifying information in accordance with the provisions described in the previous sections. The GDRAS will also include trend analysis capabilities to explore historical data and analyze similar event data from past flights to determine if any patterns exist or if further study is warranted.

4.2.5 Other Equipment [Airline Name] will be investigating several other components to incorporate into the FOQA program as the technology becomes available and requirements are identified and refined. The addition of these components is subject to approval by the FMT.

JCET, LAKKIDI

DFDR DATA READOUT

29

Figure 13: FOQA system architecture

JCET, LAKKIDI

DFDR DATA READOUT

30

4.3 FOQA Analysis Process. The FOQA analysis process must be developed based on the objective and scope of the intended program. At a minimum, the process will be determined depending on whether information will be used to evaluate or effect change in any or all of the following areas: Operational Safety Aircraft Performance Aircraft System Performance Crew Performance Company Procedures Training Programs Training Effectiveness Aircraft Design ATC System Operation Airport Operational Issues Meteorological Issues

Analysis Techniques. Two types of analysis techniques can be applied to FOQA data. They are parameter exceedence analysis and statistical analysis. (a) Exceedence Analysis. This involves setting a specific limit for the GDRAS to detect for a particular parameter. For example, the GDRAS can be programmed to detect each time the aircraft roll angle exceeds 45 degrees. This data can be trended over multiple flights to determine the number of exceedence occurring per flight segment. In addition, the data can be trended to determine which phase of flight, airport, or runway, if appropriate, depending on the event type. Levels of exceedence can be programmed for particular events based on the operators risk assessment to assist in focusing resources on implementing corrective action on the highest perceived operational risk area. A higher level of risk may be associated with an occurrence where the bank angle reached or exceeded 60 degrees. The FMT, through the gatekeeper, may choose to contact the crew or conduct a more detailed investigation of the event for this type
JCET, LAKKIDI

DFDR DATA READOUT

31

of exceedence in addition to just maintaining and monitoring the trends where bank angle exceedences reach 45 degrees or greater. Exceedence levels will have to be developed through assessment of a carriers operations manuals, training programs, and risk assessment process as part of the overall safety program. (b) Statistical Analysis This is used to create profiles of flight, maintenance, or engineering operational procedures. The profiles can use several measurements to build distributions of various criteria. A distribution of data will show all flights and enable a carrier to determine risk based on mean and standard deviations from the mean. One procedure a carrier may look at is approach tracks. A profile would be designed to measure the different criteria of an approach, like airspeed, rate of descent, configuration, or power setting. For example, the GDRAS will capture the maximum airspeed of every flight on final approach. A series of distributions will show a picture of how all flights are performing. The carrier can then determine when an approach track may lead to an unstable approach or landing. Similar to exceedence analysis, statistical analysis can use distributions to drill down into the data to look at phase of flight, airports, or aircraft type, if appropriate. Each individual airline working with its FOQA team could establish or modify airline policy and training programs based on the performance of all its flights. Once a baseline is established, the data could be monitored to track the trend of what is occurring. The value of using statistical analysis is that data from all flights is used to determine risk for an airline without focusing on specific event exceedences. The use of data distributions can develop a risk assessment process by establishing a baseline for trending data and determining critical safety concerns. Statistical analysis is a tool to look at the total performance of an airlines operation.

JCET, LAKKIDI

DFDR DATA READOUT

32

(c) Validated Trend Information

This is reviewed to determine the nature of any required action. Such actions might include the immediate notification of maintenance personnel if limits were exceeded that require inspection of the aircraft, reviews of the event to identify possible corrective measures, or a determination that further information is needed through crew feedback. Depending on the particular event, the flightcrew may be contacted to gather more information about the circumstances and causes of the event. Corrective measures can range from modifications of flightcrew training to revisions of the operating procedures to equipment redesign. Information on valid events is also stored in databases for use in trend analysis.

JCET, LAKKIDI

DFDR DATA READOUT

33

CHAPTER 5 DATA FRAME

5.1 Introduction to Data Frames A Flight Data Acquisition Unit (FDAU) takes the aircraft inputs and condenses the data into a multiplexed digital data stream for recording onto the Digital Flight Data Recorder (DFDR). When the data is extracted, the process has to be reversed and the raw binary data has to be converted back into engineering units. This decoding process has two phases. The first is to know which data bits correspond to which variable parameters as defined by the dataframe layout and the second is to know the scaling factor that will convert the binary value for a given parameter back to the original engineering value. The dataframe definition defines the bit map and scaling laws that allow conversion between raw binary and engineering units. The number of bits that a parameter occupies determines the number of states that a given parameter can have. Thus, a parameter stored in 12 bits can have 4,096 possible states (range of 0 to 4,095 counts, see Table 2). The resolution is the range of the parameter, divided by the number of possible states and is hence the bit weighting of the least significant bit used. Note that the recorded range is always larger than the range encountered in service in order to accommodate the actual and out of range inputs. Some ranges will be signed, such as roll angle or outside air temperature. Some ranges will be positive only, such as airspeed or magnetic heading. A parameters sample rate is the number of recordings made by the DFDR within a given period of time, usually per second. Some parameters, such as vertical acceleration, are recorded several times a second, while others, such as date, are recorded at a very slow rate, e.g. once per 16 seconds. Each parameters minimum sample rate in the DFDR is determined by the regulations, and should be distinguished from the rate at which the parameter is refreshed on the DFDAU input bus. Thus, whilst the gross weight may be refreshed every 20 milliseconds at the DFDAU 429 input port, it will only be recorded every 64 seconds on the DFDR. It is important that the Databus refresh rate is consistent with the required data capture rate.

JCET, LAKKIDI

DFDR DATA READOUT

34

5.2 What is a Data Frame? The previous section introduced the notion of a data frame that contains bit mapping and scaling information. The FDR system dataframe will normally comprise of multiples of 64D words recorded every second, e.g. 64, 128, 256, 512 or 1,024 words per second. This number is used due to the original encoding of the word number counter using three bit octal counters and 64D being equivalent to the maximum available using the two least significant bits of this counter = 77O. For the purposes of this section, a data rate of 64 wps is used, and at 12 bits/word, this corresponds to a bit rate of 768 bits/sec. 5.3 Data Frame Structure An FDR dataframe occupies a 4 second interval, within which are four 1 second subframes, called subframes 1, 2, 3 and 4. These subframes appear in sequential order, over and over again in the data as the subframe pattern repeats for each new data frame. The ARINC Characteristic 573 (Mark 2 Aircraft Integrated Data System) data frame concept developed at the point when tape damage due to crash loads was a concern. ARINC defined a set of synchronisation words (sync words), one for each subframe, that would be located into the first word of each subframe. This sync pattern was clarified in ARINC Characteristic 717 (Digital Flight Data Acquisition Unit), removing the ambiguity in ARINC 573 concerning the direction that the bit pattern should be read. In good flight data, once the sync word for subframe 1 has been found, moving 64 words further into the data will find the sync word for subframe 2, and so on until subframe 1 is reached in the next frame. A block of data that has all the right sync words in all the right places is synchronised. Any unsynchronised data should be treated with caution. Once the sync word pattern has been restored, the data integrity in terms of data location should also have been restored. Most data frames contain a frame counter to help track possible gaps in the data. This frame counter is usually a full word (12 bits), and can have 4,096 possible states (0 to 4095) which the data frame steps through, until the frame counter gets to 4,095 and the process begins again. This counter is generated by the DFDAU. However, the readout software may put a frame number on each sequential group of four subframes. Thus, if there are 20,000 frames in a block of data, the frame number will run from 1 to 20,000, in order. This frame number applied to the data by the readout software is not contained within the data itself, and does not repeat as part of a
JCET, LAKKIDI

DFDR DATA READOUT

35

cycle. Other than the sync words and a possible frame counter, all other words in the data frame can be filled with any combination of numeric parameters and discretes. Each subframe is defined separately, so that different subframes can record quite different data, if so desired. Each four second 64 wps data frame can generate 252 12 bit words (256 available, minus the 4 sync words), or 3,024 bits that are available to record data. The number of parameters that can be stored depends on the range and resolution of each parameter (number of bits) and the sample rate (how often a parameter is recorded) required. For DFDR data frames, range, resolution and sample rates are set by the regulations for all mandatory parameters. Resolution is the smallest change in a parameter value that can be recorded. This depends on the number of bits allocated to that parameter, and the value range that the DFDR can accommodate. For example, oil temperature may vary from 0C to 300C. To be sure to cover the operational range, the recorded range is 0 to 400 C. If oil temperature is stored in a 12 bit word with 4,096 possible states, then the resolution is: Resolution = range/range of recorded digital word 400C range/4,095 bits = 0.09768C/bit In some cases, the regulations may require a resolution that a single 12 bit word cannot provide. In this case, it will probably be necessary to store such a parameter in two data frame words, with a fine and coarse component. Examples of parameters that may require more than 12 bits to meet the range and resolution requirements are altitude, latitude and longitude. The sample rate needed for a given parameter can vary widely. For example, "month" changes rarely during a flight, and can be recorded with a long interval. Vertical acceleration (Nz) is typically recorded at eight times per second to capture the parameter with sufficient precision. A parameter stored in the same word in each subframe has a sample rate of once per second. Nz requires eight words per data frame, and these must be spread evenly through the 64 available words, for a sample rate of once every 0.125 seconds and a total of 32 total words in the four second data frame. As data frames developed, designers found that they had more parameters to record than there were words to store them. To increase the possibilities available the superframe was defined. In this concept, the same word in the frame has a 16 count cycle where different parameters may be stored. When the 16th step is reached, the next word goes back to the first step and starts over again. If superframes are used, a superframe counter also has to
JCET, LAKKIDI

DFDR DATA READOUT

36

be stored. The superframe counter determines the recording position within the 16 step sequence. Starting with the assumption that a data frame has been defined with a superframe word only in subframe 1, the following would be true: If a parameter is recorded in only one of the 16 slots, the refresh rate will be (subframe 1 every 4 seconds) x (16 states per superframe cycle) = a 64 second sample rate. If the same superframe word is placed in all four subframes, the refresh rate becomes 16 seconds. Obviously, a superframe is only used for those parameters which change slowly. Typical superframe parameters may include gross weight, day/ month/year, and flight number. Some parameters, such as airspeed, are numeric. That is, they have a numeric value, such as 325 knots. Other parameters, called discretes, are a coded way to describe the aircraft configuration or system configuration. A discrete is a parameter that can have only two defined states. A discrete will have a value of one or zero, such as gear up/down or master caution ON/OFF. However, a number of discretes may be used together to represent a combination of values and require tables to define the recorded bit patterns. In this way, n discretes can provide 2n combinations. For example, four discretes could be combined to represent sixteen autopilot modes. 5.4 Data Conversions The range and resolution with which the data word can store numeric values depends on the number of bits that the data frame assigns to that parameter. If a parameter occupies all 12 bits, there can be 4,096 different values covering the range of the engineering parameter. Table 2 shows the number of states possible for different numbers of bits. The resolution of the storage process is one bit divided by the total 25 March 2011 CAP 731 Approval, Operational Serviceability and Readout of Flight Data Recorder Systems and Cockpit Voice Recorders Appendix B Page 4 number of possible states. Thus, a 12 bit word has a resolution of 1/4,095 of the full range of the engineering parameter being represented. Shown below, the data word has a maximum range of 8,190 with a resolution of 2.

Number of

12

11

10

3 2 1
JCET, LAKKIDI

DFDR DATA READOUT

37

Bit Bit weighting

MSB

LSB

4096 2048 1024 512 256 128 64 32 16 8 4 2

Table 2: Powers of 2 (Bit Resolution) NOTE: MSB=Most Significant Bit LSB=Least Significant Bit There are two basic kinds of data to be stored; data from an analogue source (synchro, AC or DC voltage ratio, variable resistance, and potentiometer, High Level DC, Low Level DC or Very Low Level DC) or a digital source such as an ARINC 429 bus. The conversion to and from the 12 bit word value is different for the two kinds of data. To describe the process of converting digital data into the FDR system data format, let us assume an altitude value is being sent to the FDR system 12 bit word on an ARINC 429 bus input. Let the altitude range between 0 and 65,535 ft, where 65,536 is the number of possible states for an input that occupies 16 bits. Thus, the parameter range is from 0 to 65,535 with a resolution of 1 ft. To be recorded within one FDR system data word, this needs to be mapped into a 12 bit parameter with 4,096 different states. Therefore, for an altitude value of 10,000 ft: Digital counts, 12 bits = 4,095 * (10,000 ft data/65,536 full range) = 625 counts (decimal), or 1,161 counts (octal) Resolution, 12 bits = 65,536 ft full range/4095 counts full range in 12 bits) =16 ft =The equivalent of 4 bits resolution when 16 bits map into 12 =16 ft/count x 4,096 counts possible = 65,536 (0 to 65,535 ft) Once the resolution is established, this can be used to recalculate the actual count value using the actual range achievable with the 12 recorded bits, i.e. maximum range is not 65,536 but is 65,520 due to the 16 foot recorded resolution. Therefore: Digital counts, 12 bits = 4,095 * (10,000 ft data/65,520 full range) = 625 counts (decimal), or 1,161 counts (octal). For the next example, assume a signed altitude (plus and minus values possible) is being stored. Thus, in the 16 bit word, one bit is the sign, which leaves 15 bits (32,768
JCET, LAKKIDI

DFDR DATA READOUT

38

possible states) plus the sign bit to give an overall range of 65,536 states split evenly over the +/- 32,767 ft range. In order to accommodate the +/- range in the recorded data word, the input value is converted into an offset binary value such that a zero input equates to half range recorded counts. This offset is then subtracted during the data re-conversion process, using a "c" in a y = mx+c format.To calculate the digital counts for a one foot accuracy (+/- 32,767 ft): Digital counts, 12 bits = 4,095 * (10,000 ft - (-32,768 ft at 0 counts))/65,536 ft = 4,095 * 42,768/65,536 = 2,672 decimal or 5,160 octal counts where 2,048 counts decimal is approximately zero altitude. Resolution = (+32,736 to - 32,736 range)/4,096 states in 12 bits = 16 ft Once the resolution is established, this can be used to recalculate the actual count value using the actual range achievable with the 12 recorded bits, i.e. maximum range is not 65,536 but is 65,520 due to the 16 ft recorded resolution. Therefore: Digital counts, 12 bits = 4,095 * (10,000 ft - (-32,752 ft at 0 counts))/65,520 ft = 4,095 * 42,752/65,520 = 2,672 decimal or 5,160 octal counts. Analogue data works somewhat differently, with one exception. Synchro inputs can be treated like digital data, where the full range of 0 to 360 (inclusive) can be encoded directly into the full range of a data word such that a full range count of 4,095 = 359.9mand 4,096 counts = 360 = 0 counts = 0, because it is possible to cross over zero degrees and continue, like a compass reading. In order to convert into engineering units, it is then necessary to apply the signal source LRUs data conversion factor as a part of, or after, this conversion process. Other analogue source data will use a count to input range specified for each input, normally in accordance with ARINC 573. For example, a Low Level DC (LLDC) input will be accepted with an input range of 0 to 5Vdc with 0V being recorded as 0 counts and 5V as 4,095 counts (assuming a 12 bit word). Thus any conversion from the recorded data will identify the input voltage that then must be reconverted to raw source (engineering unit) data using the signal source LRUs data.
JCET, LAKKIDI

DFDR DATA READOUT

39

For example: Normal Acceleration (Nz) is recorded as a 12 bit word with 4,096 states. The total range of the input is 3.375g to +6.0g, giving an input range of 9.375g. As this is a bipolar input (+ and ranges), the data is handled as an offset bipolar word with a -3.375g offset. Therefore, for a Nz of 2.0g; Digital counts, 12 bits = 4,095 x (2g + 3.375g)/9.375g = 2,348 decimal or 4,454 octal counts Resolution, 12 bits = total input range (gravities)/total range (counts) = 9.375g/4,096 (0 to 4,095 counts used) = 0.002289 g/bit.

CHAPTER 6 FDR READOUT

JCET, LAKKIDI

DFDR DATA READOUT

40

6.1 FLISAFE FliSAFE is a powerful FOQA tool that increases the effectiveness of any Flight Safety Monitoring Program. It identifies exceedances and adverse trends developed during each flight, thus enabling the user to take remedial action. FliSAFE is designed to meet the requirements in departments of safety, operations and engineering of any airline operator or aircraft owner. FliSAFE is a highly secure system with declassification of data and user rights definition, thus ensuring the need to know basis principle. 6.1.1 Key features of FliSAFE Supports even the latest commercial aircrafts and tracks the history of FDR/QAR/FDAU and parameter changes of any aircraft. FliSAFE can be configured for identifying and reporting details of any parameters that have crossed their threshold limit. Completely Automated FOQA Process: FliSAFE has taken FOQA process to the next level where-in user interference is reduced to the minimum. FliSAFE is designed to automatically import multiple number of flight data, process it and store the exceedances/warnings detected, all in the shortest possible duration. The imported files can be archived and restored using the archive-restore feature. Detailed exceedance configuration feature helps in classifying and configuring the most intricate exceedance. Advanced analysis module detects exceedances, warnings and extreme parameter values and stores the key information in database for future reference. The powerful trend analysis module of FliSAFE gathers FOQA events from the database and generates periodic reports in tabular and graphical formats helping users to understand exceedances/ warning trend. Highly configurable modules help in configuring various parameters for readout and analysis of flight data. Quality Management Reports to help audit the effectiveness of FOQA operation based on flight cycle count information. Flight Details Reports provides complete details of flights within a period based on takeoff airport/aircraft registration etc.
JCET, LAKKIDI

DFDR DATA READOUT

41

Detailed exceedance, warning and extreme value reports can be generated in both numerical and graphical reports. Advanced reporting option with width counter and colour coding features An optional 3D visualization module helps in simulating the flight data using FlightViz, the leading simulation tool by SimAuthor Inc. 6.1.2 FliSAFE Performance Monitoring Tools FliSAFE is designed to make use of the vast repository of data available from the DFDR to monitor various performance and fuel efficiency aspects of the airline. Some of the performance plug-in modules that are available for FliSAFE, made according to customer specific requirements are Aircraft Performance Monitoring Module Engine Condition Monitoring Module Reduced Thrust Monitoring Module Time Monitoring Module Fuel Monitoring Module 6.2 DFDR Data Downloading Units A) RSU Ruggedized Service Unit (RSU) The RSU is the worlds premier Flight Data Recorder Data Download and Diagnostic Tool. Proven Since 1997, the RSU has gained a growing worldwide following at airlines, militaries, airframe and engine OEMs, repair stations, research groups, regulatory agencies, accident investigation boards, and educational institutions. Unlike other handheld readout devices, the RSU is capable of displaying data in real time engineering units, octal, decimal, and binary formats. And, unlike OEM devices, it can download and display real time data from a wide variety of recorder makes and models, including solid - state and legacy tape units. In fact, it is the ONLY download choice in current production for a number of legacy units! And all this can be done on the aircraft, without removing the unit, avoiding re-certification costs. Engineering units provide a more convenient, understandable means of diagnosing DFDR system problems than octal codes or blinking lights. An aircraft with diagnosed DFDR
JCET, LAKKIDI

DFDR DATA READOUT

42

System failures may be quickly returned to service after replacing suspect components and performing requisite operational checks using an RSU.

Figure 14: RSU

B) RSU II The RSU-II is the successor to RSU I. Like its predecessor, the platform for the RSU-II was chosen carefully to best respond to todays, as well as tomorrows, ground support requirements. It is a powerful and rugged, weather-resistant pen-tablet platform with an 8.5color LCD display, equipped with USB 2.0 and Ethernet ports. Ergonomically, its just the right size, weight, and shapes to balance performance and convenience. Youll wear out before the battery does (an external battery pack doubles battery life), and the power supply powers either the dock or the unit directly to minimize your accessory count and maximize your options. The RSU-II downloads (or monitors) practically every Flight Data Recorder in the western world (see below). Many Flight Data Acquisition units can also be monitored, TCAS systems diagnosed, and ARINC-429 busses monitored. To protect your investment, weve ensured the RSU-II interfaces with most all your original RSU Portable Test Interface (PTI) cables. With Secure LINK wireless on your aircraft, you can even monitor your real-time miniQAR data wirelessly! But thats not all Our new menuing software enables users to configure their own custom prompts and workflow. From one-touch operation to comprehensive data entry, the choice is yours. And, with a Windows XP Tablet operating system, you
JCET, LAKKIDI

DFDR DATA READOUT

43

can be sure these applications are only the beginning of a whole new family of tools to share this platform, from wireless planeside electronic documents, to data loading and more. Like the original, the RSU-II is capable of displaying data in real-time engineering units, octal, decimal, and binary formats. Engineering units provide a more convenient, understandable means of diagnosing DFDR system problems than octal codes or blinking lights. In addition, the RSU-II displays graphical traces of the data, and enables YOU to choose which parameters to view with drag-and-drop simplicity. Using these handy features, an aircraft with diagnosed DFDR System failures may be quickly returned to service after replacing suspect components and performing requisite operational checks.

B) Portable Interface Unit The L-3 Portable Interface is a hand-held portable device for data retrieval from Recorders. The user interface, a seven-key keypad and an eight-line display allows standalone operation to perform the following functions: FDR, CVR, and CVDR monitor, copy, and playback.

Figure 15: Hand-held PI device for data retrieval C) Portable Interface 2 The PI/2 is a multi-functional hand-held downloader. This new generation PI/2 incorporates all of the features of the original PI with many enhancements. The PI/2 downloads/ monitors i) Flight Data Recorder Models F1000, FA2100, FA2200 ii) Cockpit voice recorder models FA2100 iii) Combination voice and data recorder models FA2100 and FA2300
JCET, LAKKIDI

DFDR DATA READOUT

44

Figure 16: Portable Interface 2 D) Rose Analysis Unit The RAU is a portable line tester with ROSE Software included. The RAU supports on-aircraft real time evaluation of parameters or retrieval of flight recorder data. For the FA2100 FDR and F1000 SSFDR. Features: i) Monitors Live Data and Downloads Stored Data ii) Data Decompression iii) Data Archive and Export iv) Database Import and Export v) Tabular/Raw Data/Graphic Display of Flight Data vi) Database Control

Figure 17: RAU

JCET, LAKKIDI

DFDR DATA READOUT

45

E) Hand Held Multi Purpose Interface (HHMPI) The HHMPI is a hand-held download unit which connects to multiple types of flight recorders (Data& voice). The download unit supports multiple memory devices such as SD card, CF card, USB memory and a PCMCIA II card option to store flight data or cockpit audio files. The HHMPI offers significant cost advantages by eliminating the need to acquire different download units to interface with each flight recorder type. The HHMPI is powered by the flight recorder or optional battery version.

Figure 18: HHMPI

JCET, LAKKIDI

[Type text]

JCET, LAKKIDI