I

A PROJECT REPORT ON

FLIGHT RECORDER APPLICATIONS

Submitted in partial fulfillment of the requirements for the

award of the degree of

MASTER OF TECHNOLOGY
In
SOFTWARE ENGINEERING
By
RESHMA M

Under the Esteemed Guidance of

Mr. Manoj Kumar Mr. G. Santhosh Kumar

Tech Lead Lecturer
Honeywell Technology Solutions Dept. of Computer Science
Lab Pvt Ltd CUSAT
Bangalore

DEPARTMENT OF COMPUTER SCIENCE

COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY
KOCHI – 682022
MAY 2008
III

DEPARTMENT OF COMPUTER SCIENCE

COCHIN UNIVERSITY OF SCIENCE &TECHNOLOGY
KOCHI-682022

CE R TIFICA TE

Certified that project work entitled “Flight Recorder

Applications” is a bonafide work carried out by Reshma M. at
Honeywell Technology Solutions Lab Pvt. Ltd, Bangalore in
partial fulfillment for the award of master of technology in
Software Engineering from Cochin University of Science &
Technology during the academic year 2007-2008

Dr. K. Poulose Jacob Mr. G. Santhosh Kumar

Professor & Internal Project Guide
Head of the Department Lecturer
Dept.of Computer Science Dept.of Computer Science
CUSAT CUSAT
V

ACKNOWLEDGEMENT

I am greatly indebted to Mr Manoj Kumar, Tech Lead, Honeywell

Technology Solution Lab for his technical support, constant encouragement,
consistent guidance and inspiration throughout the course of this investigation.

I feel immense pleasure in thanking my guide Mr. G. Santhosh Kumar,

Lecturer, Department of Computer Science for his valuable suggestions and
support during the course of the project work.

I express my sincere thanks to our H.O.D, Dr. Poulose Jacob for being a
great pillar to all our achievements.

I would like to express my gratitude to my mentor Mohammed Siddique,

Engineer for his motivation and encouragement

I am extremely happy to thank Dr.Sumam Mary Idicula and Mr David

Peter S, Professors, Department of Computer Science for their excellent guidance
and invaluable help rendered throughout this project in a versatile manner
VII

ABSTRACT
In every aircraft that is being made, there is always a chance, like any
other vehicle moving on our planet, to undergo an accident. Although the figures are thin
but cannot be neglected, as the loss associated with the lives and property is enormous.
The reason for the crash can be human negligence or, technical failures. There were times
when crashes could not be avoided, but then there are others which could be prevented.
The reason for the crash can be investigated and for this purpose, a flight recorder is been
installed in every aircraft.

Flight recorders (also known as ‘black boxes’) are crash survivable units that designed to
withstand the impact of aircraft crash and considered to be indestructible. It is defined as
an instrument that records the performance and condition of an aircraft in flight. The data
that was being stored before the crash could be used later on, to investigate the reason for
crash. The applications specified in this report facilitates data retrieval from flight
recorders and another one is used for testing ensuring the proper working of the
recorders.

The applications that we are working on already existed when we got the
project, but the applications needed modifications and addition of new features as
required by latest technologies implemented in newer generations of flight recorders.
These technologies have provided an altogether new dimension to aircraft safety.

Significance: The data retrieved from a flight data recorder can be used
to generate a computer-animated video reconstruction of the flight of an aircraft, making
possible the investigation and analysis of aircraft accidents or other unusual occurrenc
 Flight Recorder Applications IX

Table of Contents
ABSTRACT....................................................................................................... VII
TABLE OF CONTENTS ................................................................................... IX
LIST OF FIGURES ............................................................................................ XI
LIST OF ACRONYMS .................................................................................... XII
1. ORGANISATION PROFILE .......................................................................... 3
3. INTRODUCTION............................................................................................ 7
3.1. EVOLUTION OF FLIGHT RECORDERS.............................................................. 7
3.2. FLIGHT DATA RECORDER............................................................................ 10
3.3. COCKPIT VOICE RECORDER ........................................................................ 12
3.4 RECORDING AND STORAGE .......................................................................... 14
4. FLIGHT RECORDER APPLICATIONS.................................................... 19
4.1. FLIGHT DATA PLAYING SOFTWARE .............................................................. 19
4.2. FLIGHT RECORDER TESTING SOFTWARE ..................................................... 23
5. SOFTWARE REQUIREMENTS AND SPECIFICATIONS ................. 29
5.1. FLIGHT DATA PLAYING SOFTWARE ............................................................. 30
5.1.1. Design Constraints.............................................................................. 30
5.1.2. User interface requirements ............................................................... 30
5.1.3. Functional requirements..................................................................... 32
5.1.4. User Profile......................................................................................... 34
5.1.5. Usage Scenario ................................................................................... 34
5.2. FLIGHT RECORDER TESTING SOFTWARE ..................................................... 35
5.2.1. Design Constraints.............................................................................. 35
5.2.2. User interface requirements ............................................................... 35
5.2.3. Functional requirements..................................................................... 36
5.2.4. User Profile/ Usage Scenarios............................................................ 40
6. DESIGN PHASE......................................................................................... 45
6.1. SYSTEM DESCRIPTION ................................................................................. 45
6.1.1. Interfacing the recorder with the system .......................................... 46
X

6.1.2. RPGSE Laptop/Desktop.................................................................... 49

6.1.3. PCI interfacing card ......................................................................... 49
6.1.4. Cable ................................................................................................. 49
6.1.5. Driver wrapper ................................................................................. 50
6.1.6. Flight Recorder Applications............................................................ 50
6.2. DESIGN CONSTRAINTS ........................................................................... 50
7. TESTING PHASE ...................................................................................... 53
7.1. TESTS CARRIED OUT ON FLIGHT DATA PLAYING SOFTWARE ................. 55
7.2. TESTS CARRIED OUT ON FLIGHT RECORDER TESTING SOFTWARE .......... 57
8. TOOL SURVEY.......................................................................................... 61
8.1. THE DEVELOPMENT ENVIRONMENT MICROSOFT VISUAL C++ .............. 61
8.2. DIRECTX................................................................................................ 63
8.3. COM DLL............................................................................................. 65
9. OBSERVATIONS AND CONCLUSIONS............................................... 75
10. REFERENCES............................................................................................ 81
 Flight Recorder Applications XI

List of Figures
Figure 1: Flight recorder ------------------------------------------------------------------ 9
Figure 2: Basic components and operation of an aviation recording system -----15
Figure 3:Flight Data Playing Software -------------------------------------------------22
Figure 4: Basic diagram to show the working of flight data playing software----45
Figure 5: Connecting a recorder to the system ----------------------------------------47
Figure 6: Interfacing of Flight recorder applications with Recorders -------------48
Figure 7: Main window of Flight Data playing software ----------------------------69
Figure 8: Main window of Flight Recorder Testing software -----------------------70
Figure 9: Main window of Audio Calibration Utility ---------------------------------71
XII

List of Acronyms

CVR Cockpit Voice Recorder

FDR Flight Data Recorder
CSMU Crash Survivable Memory Unit
SSCVR Solid State Cockpit Voice Recorder
SSFDR Solid State Flight Data Recorder
GBE Ground Based Equipment
PCI Peripheral Component Interconnect
RPGSE Recorders Portable Ground Support Equipment
Flight Recorder Applications 1
Flight Recorder Applications 1

INTRODUCTION
2 Organization Profile
 Flight Recorder Applications 3

1. ORGANISATION PROFILE
Honeywell Technology Solutions Lab (HTSL) is a USD 33
billion diversified technology and manufacturing leader, serving customers worldwide
with aerospace products and services; control technologies for buildings, homes and
industry, automotive products, turbochargers, and specialty materials. Based in Morris
Township, N.J., Honeywell’s shares are traded on the New York, London, Chicago and
Pacific Stock Exchanges.

Honeywell can trace its roots back to 1885, when an inventor named Albert Butz
patented the furnace regulator and alarm. He formed the Butz Thermo-Electric Regulator
Co., Minneapolis, on April 23, 1886, and a few weeks later invented a simple, yet
ingenious device that he called the "damper flapper."

Four Business Groups are

1. Aerospace:
Headquartered in Phoenix, Arizona, Honeywell Aerospace is a leading global
provider of integrated avionics, engines, systems and service solutions for aircraft
manufacturers, airlines, business and general aviation, military, space and airport
operations. Honeywell Aerospace continues to work to improve the capabilities of
military forces, developing systems that power unmanned vehicles, avionics for jet
fighters, weapon sensors for precision targeting, and upgrades that extend the lives of
proven aircraft and vehicles. Honeywell Aerospace has sales of over $11 billion and
employs 40,000 people in 97 worldwide manufacturing and service sites.
 4 Organization Profile

2. Automation and Control Solutions:

Honeywell makes homes, buildings, industrial sites, and airport facilities more
efficient, safe and comfortable. Honeywell products, solutions, and services are
prominent in growth areas such as sensors, wireless technology, and real-time data
management.

3. Specialty Materials:
Honeywell produces high-performance specialty materials such fluorocarbons,
specialty films, advanced fibers, customized research chemicals and intermediates for
applications as diverse as telecommunications, ballistic protection, pharmaceutical
packaging, and counterfeiting avoidance.

4. Transportation Systems:
As a leading automotive supplier, Honeywell enhances vehicle performance,
efficiency, and appearance through state-of-the-art technologies, world-class brands, and
global solutions to the customers’ needs.

Honeywell’s quality products, integrated system solutions, and services make life
safer, more comfortable, more secure, and more productive in every corner of the world.
Honeywell products touch the lives of most people everyday, whether you're flying on a
plane, driving a car, heating or cooling a home, furnishing an apartment, taking
medication or playing a sport.
Flight Recorder Applications 5
 Flight Recorder Applications 7

3. INTRODUCTION
3.1. Evolution of Flight Recorders
In the earliest days of air transportation, plane crashes yielded few clues for
safety investigators. Investigators would struggle to figure out what happened
immediately preceding the accident but often fail to come to any definite conclusions
regarding the cause of the crash. In June 1960, a Fokker F27 plane crashed while landing
in Queensland, Australia, killing 29 people. Despite intensive investigations, the
underlying cause for the accident was never determined.

The mystery prompted the Australia board of inquiry to recommend that

all airplanes be fitted with a flight recorder that would detail the flight crew's
conversation. This is just one of the instances that made the aviation boards realize the
importance of Flight Recorders to be installed in aircrafts. The idea, however, faced one
enormous technological challenge. Design specifications required that the unit survive
the forces of an aircraft crash, as well as any resulting fire exposure.

Since it was first being used in the aircrafts it has become an inseparable
part of air safety systems. Each crash gives some information about some of the
loopholes in aircraft safety measures. This helps us to enhance the safety measures taken
in future aircrafts. The recorders have evolved over the time. The changes occurred due
to invention of newer, faster, more durable memory devices. Other reason was
requirement of more sturdy and rugged shells to pack the memory unit as aircrafts got
faster and bigger year after year. Also the data to be stored in the recorders kept on
increasing through the time.
 8 Introduction

Flight recorders are also called as “Black Boxes” which is a misnomer

because these are painted bright red or orange with reflective surfaces to facilitate its
location out of debris, after the crash. Flight recorders are designed to survive enormous
conditions of pressure and high temperature. The storage part of the recorder is
indestructible and is called CSMU (Crash survivable memory unit). Magnetic tape
versions of flight data and cockpit voice recorders can withstand a force of impact
equivalent to 1,000 Gs (1000 times the force with which earth pulls a body). Newer solid-
state versions can handle up to 3,400 Gs. These can survive even in a temperature as high
as 1000°C or higher reached by combustion of jet fuel for one hour and more. The
recorders are designed to be maintenance free.
 Flight Recorder Applications 9

Figure 1: Flight recorder

All are lettered "FLIGHT RECORDER DO NOT OPEN" on one side in English and
“ENREGISTREUR DE VOL NE PAS OUVRIR” in French on the other side.

There are two types of recorders:

• Flight Data recorder (FDR)

• Cockpit Voice Recorder (CVR)

 10 Introduction

3.2. Flight Data Recorder

An aircraft flight recorder records many different operating conditions of

a flight and provides information that may be difficult or impossible to obtain by any
other means. By regulation in most countries in the world, newly manufactured aircraft
must monitor at least twenty-eight important parameters. These include time, altitude,
airspeed, heading, vertical acceleration, and aircraft pitch. Some recorders can record the
status of more than three hundred additional in-flight characteristics that can aid in an
accident investigation. Some of these include flap position, autopilot mode, and even
smoke alarms.
To ensure that a large amount of information is recorded, a flight
recorder is able to record for at least twenty-five hours. Computer programs have been
written to take flight recorder data and reconstruct animated videos of aircraft flight. The
animation allows the investigation team to view the last moments of a flight prior to an
accident. In the event of an accident, investigators can visualize the instrument readings,
power settings, airplane’s attitude, and other important characteristics of a given flight.
By regulation, flight recorders for newly manufactured aircraft must accurately
monitor at least 28 critical factors, such as:
• Time
• Pressure (Internal and external)
• Altitude
• Airspeed
• Vertical acceleration
• Magnetic heading
• Control-column position
 Flight Recorder Applications 11

• Rudder-pedal position
• Control-wheel position
• Horizontal stabilizer
• Fuel flow
• Rotor Speed
• GMT Timestamp
Modern day FDRs are typically plugged into the aircraft's fly-by-wire
main data bus. They record significant flight parameters, including the control and
actuator positions, engine information and time of day. There are 88 parameters required
as a minimum under current U.S. federal regulations (only 29 were required until 2002),
but some systems monitor many more variables. Generally each parameter is recorded a
few times per second, though some units store "bursts" of data at a much faster frequency
if the data begins to change quickly. Most FDRs record 25 hours worth of data in a
continuous loop.
This has also given rise to flight data monitoring programs, whereby
flights are analyzed for optimum fuel consumption and dangerous flight crew habits. The
data from the FDR is transferred, in situ, to a solid state recording device and then
periodically analyzed with some of the same technology used for accident investigations
FDRs are usually located in the rear of the aircraft, typically in the tail. In this position,
the entire front of the aircraft acts as a "crush zone" to reduce the shock that reaches the
recorder. Also, modern FDRs are typically double wrapped, in strong corrosion-resistant
stainless steel or titanium, with high-temperature insulation inside.
 12 Introduction

3.3. Cockpit Voice Recorder

A cockpit voice recorder records the flight crew’s voices, as well as other
sounds within the cockpit. Communications with air traffic control, automated radio
weather briefings, and conversation between the pilots and ground or cabin crew are
recorded. Sounds of interest to an investigation board, including engine noise, stall
warnings, landing gear extension and retraction, and any clicking or popping noises, are
typically recorded. Based on these sounds, important flight parameters, such as speed,
system failures, and the timing of certain events can often be determined. In the event of
an accident, an investigation committee creates a written transcript of the cockpit
recorder tape. Local standard times associated with the accident sequence are determined
for every event on the transcript. This transcript contains all the pertinent portions of the
cockpit recording. Due to the highly sensitive nature of the verbal communications inside
the cockpit, a high degree of security is provided for the cockpit recorder tape and its
transcript. The timing of release and the content of the written transcript are strictly
regulated.
A Cockpit Voice Recorder (CVR) is a flight recorder used to record the
audio environment in the flight deck of an aircraft for the purpose of investigation of
accidents and incidents. This is typically achieved by recording the signals of the
microphones and earphones of the pilot’s headsets and of an area microphone in the roof
of the cockpit. The current applicable FAA TSO is C123b titled Cockpit Voice Recorder
Equipment.

Where an aircraft is required to carry a CVR and utilizes digital

communications the CVR is required to record such communications with air traffic
control unless this is recorded elsewhere. It is at present (2005) a requirement that the
 Flight Recorder Applications 13

recording duration is a minimum of thirty minutes, but it is recommended that it should

be two hours.

This recorder gets digitized sound input from various microphones

located at various points in the cockpit like in front of pilot, co-pilot, navigator, and high
bandwidth wide band which records the common sound in the cockpit. There may be
other microphones situated in other parts depending on the requirement.

Here are the positions of the four microphones:

• Pilot's headset
• Co-pilot's headset
• Headset of a third crew member (if there is a third crew member)
• Near the center of the cockpit, where it can pick up audio alerts and other
sounds
The recorders are available in different memory capacities to store data
that varies from 30 minutes to 25 hours. The latest voice data from the cockpit is
collected and stored in data recorder along with few other parameters like GMT
timestamp. Once the recorder is full it starts replacing previously recorded data. In case
of a crash this data can be analyzed to find out the possible cause of accident and a lot of
information can be derived out of crew members’ conversations.
 14 Introduction

3.4 Recording and Storage

Recording and storage can be done using magnetic tapes or solid state memory
board. Magnetic tape works like any tape recorder
Solid-state Technology
Solid-state recorders are considered much more reliable than their magnetic-tape
counterparts, according to Ron Crotty, a spokesperson for Honeywell, a black-box
manufacturer. Solid state uses stacked arrays of memory chips, so they don't have
moving parts. With no moving parts, there are fewer maintenance issues and a decreased
chance of something breaking during a crash.

Data from both the CVR and FDR is stored on stacked memory boards inside the crash-
survivable memory unit (CSMU). In recorders made by L-3 Communications, the
CSMU is a cylindrical compartment on the recorder. The stacked memory boards are
about 1.75 inches (4.45 cm) in diameter and 1 inch (2.54 cm) tall.

The memory boards have enough digital storage space to accommodate two hours of
audio data for CVRs and 25 hours of flight data for FDRs.

Airplanes are equipped with sensors that gather data. There are sensors that detect
acceleration, airspeed, altitude, flap settings, outside temperature, cabin temperature and
pressure, engine performance and more. Magnetic-tape recorders can track about 100
parameters, while solid-state recorders can track more than 700 in larger aircraft.

All of the data collected by the airplane's sensors is sent to the flight-data acquisition
unit (FDAU) at the front of the aircraft. This device often is found in the electronic
equipment bay under the cockpit. The flight-data acquisition unit is the middle manager
of the entire data-recording process. It takes the information from the sensors and sends it
on to the black boxes
Flight Recorder Applications 15

Figure 2: Basic components and operation of an aviation recording system

16 Introduction
Flight Recorder Applications 17

FLIGHT RECORDER
APPLICATIONS
18 Flight Data Playing Software
 Flight Recorder Applications 19

.
4 FLIGHT RECORDER APPLICATIONS
There are two types of application that we are using along with flight
recorders. They are Flight data Playing software and Flight Recorder testing
software. Flight data playing software is used to download data (Audio as well as
digital) from the flight recorder.

4.1. Flight data playing software

Once the flight recorder is restored from the wreck, it is brought to a

ground station and is connected to the Ground based equipment (GBE) installed
computer or to a Ruggedized laptop computer, which is equipped with additional
hardware to interface with the Recorder through an intermediate cable. When the
recorder is connected to the GBE this software is used to retrieve data from the
recorder. The data that is fetched from the recorder is in compressed form and does not
make much sense. The data file is then decompressed and separated from other data
files that may be analyzed using other ground-based software.

It also consists of audio data (depending upon whether the recorder is cockpit
voice recorder or not). We get an option to select whatever out of the raw data, we want
to decompress to more understandable form. For audio data, being large in size, an
option is provided to segregate and decompress it in one of the two offered wave
formats. One is to separate and decompress into PCM (pulse code modulation) wave
files and other is to simply segregate to ADPCM (Adaptive differential pulse code
modulation) to reduce the size it takes on the hard disc.
 20 Flight Data Playing Software

The operation of decompression to PCM is time consuming and takes more time to
decompress then ADPCM because the audio data is already stored in ADPCM format.
The application uses appropriate codec for this purpose. Once the data is segregated
and separated in different files, it can be viewed using this application. The audio data
consists of various audio channels recorded from microphones that are located at
different positions in cockpit. The application provides support to play the audio data
(both PCM and ADPCM) on stereo speakers and 5.1 multichannel speakers or a
combination of both. It also provides option to select which sound file should play on
which audio channel. By providing the functionality to play PCM files this application
may save a lot of disk space and computation time that would have taken otherwise to
decompress the file to PCM format. On the other hand, if the audio files are to be
played again and again and there is no limitation of disk space, decompressing the file
is recommended because playing an ADPCM files takes more CPU resources.

The application supports playback of sound on Stereo as well as multichannel audio

cards depending on whichever is installed in the installation machine. Also it can use
both type of cards simultaneously, or in any other combination if more than one card
are installed on the machine. Any sound file can be assigned to play in any of the sound
channels available.

The playback of audio data includes the optional Rotor Speed and GMT/FSK time
indication on the player’s screen which shows this data as the playback progresses.

The application also has a tool to see the flight data. That tool can be used to view the
flight data in binary format. We can also store that data in the disk in a Microsoft Excel
sheet.
 Flight Recorder Applications 21

There are other options provided like volume control which opens sndvol32.exe and
allows the user to directly jump to volume control by just a click of button.
Some other functionalities like password protecting the application to prevent
unauthorized access to the application. Main functions of Flight data playing software
are
Download:
Data from the flight recorder is downloaded using the application. We can
choose. There is an option to select whichever data the user wants to download.
Downloaded data can be narrow band data, Wide band data, data link data etc.
Decompression:
Downloaded data is then decompressed in to audio as well as digital data. User
is given an option to select which data he wants to decompress. Decompressed data
contains audio data, Data link data, CMU data, EEPROM data etc.
Channel Selection:

Select a channel to play the decompressed signal

Data link:

Data link displays the data in ASCII format. It also displays the GMT

and OMS messages

 22 Flight Data Playing Software

Download module

Decompression Module

Flight Data Playing Software

Channel Selection

Data link module

Figure 3:Flight Data Playing Software

 Flight Recorder Applications 23

4.2. Flight Recorder Testing Software

The purpose of installing the flight recorder in an aircraft should

be clear by now and to use it, in case of a crash, we have software. As mentioned
earlier flight recorders are designed to be maintenance free. Each unit that comes
out of manufacturing plant needs to be tested thoroughly. Then the units are
installed in aircrafts. To ensure its proper working during its lifetime, it needs
routine checkup to be made periodically. They also need testing after they are
serviced, repaired or upgraded. For this purpose there is an application that is
used to test the proper functioning of Flight recorders.
This software provides different set of tests for testing the
recorder in all of the cases which includes specialized test suites for specific
purpose and manual tests to allow testing any part or aspect of working of the
recorder. User gets option to select from simpler tests to full duration thorough
checkups. The tests available to execute on a recorder depends on the recorder
connected and is different for different configurations and versions of recorders.
The application also supports a different mode of operation
which just simulates what would have happened if a particular type of recorder
would have been tested. This mode doesn’t actually run any tests, but shows the
expected result of tests executed. It can also be used to see which all tests are
supported by a particular recorder, though it doesn’t show some of the tests
which are there in the test execution mode. It also shows how the application
should behave if the recorder connected is in proper working condition and
doesn’t give any error.
There are mainly
• Acceptance test
 24 Flight Recorder Testing Software

• Qualification Test
• Return to Service test
• Safe to turn on Test

Tests performed by the application ensure whether the recorder is in

proper working condition. The application checks the power supply connected to
the recorder, whether audio data is stored in the recorder in a proper way,
Audio Calibration Utility:

As we have already said, Flight Recorder Testing Software is used to test the
performance of a flight recorder. Flight recorder is used to store digital as well as audio
data inside the aircraft. So we have to test the recorder for both digital and audio data.
Before performing tests for audio data we have to consider the presence of noise or
distortion in that signal, because presence of noise will degrade the recorder performance

Sometimes the test may fail and the reason for failure may be low performance of
sound card or corrupted recorder memory. To find out the actual reason for failure we
have to first test the sound card for its performance. Sound cards which are in general use
produces high noise or distortion. For the same reason we can’t use it for testing the
Recorders. So we have to find sound cards that are very good in performance. I.e. The
distortion is within the tolerance limit. In order to ensure the performance of sound card
before testing the recorder, we are using Audio calibration utility.

The application has the capability to detect all the audio devices connected to the
system. End user can choose any of the devices among them to calibrate. The
performance of a sound card is mainly determined by calculating its signal to noise ratio
(SNR). It is defined as the ratio of a signal power to the noise power corrupting the
 Flight Recorder Applications 25

signal. The higher the ratio, the less obtrusive the background noise is. The application
also takes care of mapping the voltage at speaker-out to that of Recorder specific line-in.
This mapping is done based on the level of voltage output from the specific audio device.

Application also has the ability to conform if the calibration expired, which is
specified by end users. Upon detection of expiry of calibration, the application has an
interactive method to call for recalibration.
26 Flight Recorder Testing Software
Flight Recorder Applications 27

SOFTWARE REQUIREMENTS
AND
SPECIFICATIONS
Flight Recorder Applications 29

5. SOFTWARE REQUIREMENTS AND

SPECIFICATIONS
Both software shall comply with the following recorders:

• Solid State Cockpit Voice Recorder (SSCVR)

• AR-Series Cockpit Voice Recorder (AR-CVR)

• HFR5 Solid State Cockpit Voice Recorder (HFR5 CVR).

• Digital Voice and Data Recorder (DVDR).

• Solid State Flight Data Recorder (SSFDR).

• AR-Series Flight Data Recorder (AR-FDR).

• HFR5 Solid State Flight Data Recorder (HFR5 FDR).

• AR-Series Combination Flight Data and Cockpit Voice Recorder (AR-COMBI).

• HFR5 Cockpit Voice and Flight Data Recorder (HFR5 CVFDR).

 30 Software Requirements & Specifications

5.1. Flight data Playing Software

The Software requirements for the Flight data playing software are as follows:

5.1.1. Design Constraints

The flight data playing software shall be designed to operate within the RPGSE
system and shall run on the Microsoft Windows 2000 or later compatible operating
system.

5.1.2. User interface requirements

• The application should have an easy to use and simple user interface which
facilitates the use of different functionalities provided.

• Technical jargons should be kept to the minimum to make the software easy to
use for end users.

• The options provided by the application shall be easily accessible to the user and
the look if the interface shall not be very much packed or overstuffed.

• All of the options provided to the user should be included in the menu bar.
Toolbars for the options to be used frequently should be added to the interface
along with the menu.

• The application shall ensure that sufficient disk space exists to complete a
download prior to transferring any flight data from a recorder to disk. If there is
not sufficient disk space, the application shall notify the user and prompt him to
check for sufficient disk space and proceed or halt as per the user’s decision.
Flight Recorder Applications 31

• For download functionality, there should be a progress bar showing the amount
of data downloaded out of whole data available in the recorder.

• For decompression functionality there should be two progress bars one showing
the progress of sound file band wise i.e. on band at a time and starts again on
startup of decompression of new audio band. The other bar should denote the
complete progress of decompression.

• For playback functionality the interface should display the total time, time
elapsed (progress) for the playback.

• For the playback of recorder sounds the interface should also provides the
capability to the user to jump to and point in the sound file by directly mouse
clicking on the timeline or simply dragging the progress pointer. The respective
timestamp should also be updated.

• The status bar should show the GMT timestamp and rotor speed parameters.

• For any error that occurs an appropriate error dialog should be displayed which
should suggest how to possibly correct and rectify the error (e.g. An Error has
occurred while attempting to read the recorder. Please check all the connections
and try again).
 32 Software Requirements & Specifications

5.1.3. Functional requirements

The various functional requirements that are expected to be incorporated in the

application are as follows:
• The application should contain all the necessary code and libraries to interact
with the Honeywell recorders of all the generations and types available till now.

• The application should detect whether the hardware card is properly installed or
not. In the latter case it should show an error dialog and disable the download
functionality.

• The application shall have an option to password protect the application to

protect any unauthorized access to the software. The password stored shall be
stored in an encrypted form.

• The application should be able to detect if the recorder is not being powered on.

• The application should be able to recognize the cable that is specific to recorder
type, and attached to hardware card.

• It should ask confirmation from the user about the type of recorder connected in
case of any confusion on its part.

• It should be able to extract the data from the recorder and store it in compressed
form under one file in disc.

• During the download, the application shall display the total download size (in
bytes) of the data to be received. In addition, the software shall continually
update a status indicator showing the number of bytes left to transfer (or a
Flight Recorder Applications 33

percent of data left to transfer) as well as the estimated time for download
completion. The number of download packet retries attempted shall also be
displayed.

• This downloaded file should be named automatically as “recorder name followed

by the current timestamp”.

• It should be able to decompress that data file into different files depending on
what all data is available stored in the recorder.

• User should be given a choice to select out of all the data available, what all data
he wants to be decompressed.

• All the files that are decompressed should be place in a folder with the same
name as that of the compressed file and is created in the same directory the
compressed file was put into.

• User should be given a choice whether the audio file id to be decompressed in

PCM or ADPCM format.

• The user should be able to play sound files in both formats, depending on the
sound data is being decompressed in which formats.

• Codec to decompress the files into PCM and playing of encoded ADPCM sound
files should be included into the package.

• Before playing the audio files, an option should be provided to assign individual
sound file to any audio channel that is available on the system (depends on which
sound device is installed on the ground based machine).
 34 Software Requirements & Specifications

• The user should be able to adjust the progress of playback like in a media player
and should be able to adjust the playback using mouse pointer.

• There should be a tool to view the flight data recorded in the recorder. The same
tool should provide the option to save the file in an MS Excel format.

• All the data displayed should be arranged in a tabular format.

• The tool must be able to save that data in an Excel sheet.

5.1.4. User Profile

The various distinct classes of users who will use the Playback software are:
• Regulatory Authorities such as NTSB.
• Test and Engineering Section of DMR group.
• Airlines (End Customers).

5.1.5. Usage Scenario

The typical usage scenarios for the Playback software:

• Crash/ accident investigation.

• Periodic download, decompression and analysis of recorded audio data.

• Periodic downloads of recorded ARINC 717 flight data.

• Troubleshooting aide during various stages of recorder development and testing.

 Flight Recorder Applications 35

5.2. Flight Recorder Testing Software

The Software requirements for the Flight Recorder Testing Software are as follows:

5.2.1. Design Constraints

The Flight Recorder Testing Software shall be designed to operate within the RPGSE
system and shall run on the Microsoft Windows 2000 or later compatible operating
system.

5.2.2. User interface requirements

• The application should have an easy to use and simple user interface which
facilitates the use of different functionalities provided.

• Technical jargons should be kept to the minimum to make the software easy to
use for end users.

• The options provided by the application shall be easily accessible to the user and
the look if the interface shall not be very much packed or overstuffed.

• All of the options provided to the user should be included in the menu bar.
Toolbars for the options to be used frequently should be added to the interface
along with the menu.
 36 Software Requirements & Specifications

• The whole window should be divided into frames to accommodate smaller

windows.

• One of the windows is used to select whether the user wants to select some
predefined set of tests or can also manually select tests that he/she desires to run
out that particular window.

• Another window shall be used as “Status window” to show which all tests are
selected and what is their status (running, pass, fail or aborted).

• One more window is used to show the summary report. The window shall be
named as “test summary window”.

• For any error that occurs an appropriate error dialog should be displayed which
should suggest how to possibly correct and rectify the error (e.g. An Error has
occurred while attempting to read the recorder. Please check all the connections
and try again).

5.2.3. Functional requirements

• The application should contain all the necessary code and libraries to interact
with the recorders of all the generations and types available till now.

• The application shall have a database providing all the information like which all
tests apply to a particular recorder and configurations associated with each
recorder.
Flight Recorder Applications 37

• At the time when the application is launched, the application shall ask the user
for the part number of the recorder connected. User shall be able to change the
part number later at any time.

• The application supports two modes of operations. The first mode is called Test
execution mode which works with recorder connected. The second mode is called
as Simulation mode which shan’t actually interacts with the recorders, rather it
just simulates the tests executed and can work even if the recorder or hardware
card is not present.

• Test execution mode shall be enabled automatically at the time of startup if the
application is able to interact with the recorder at that time.

• If the application fails to interact with the recorder, it should display an

appropriate error dialog and switch to simulation mode. It should also disable the
test execution mode selection button.

• If the recorder is connected and the application can interact with it, user should
be able to switch between these two modes whenever he wants to.

• The software should provide support for at least two types of set of tests:

o The test which has to be run to check the functioning of a brand new
recorder which has just been manufactured and is ready to be shipped to
airliner or fitted in an aircraft.

o The test to be executed on a recorder which has been repaired or

upgraded or just underwent a routine checkup to see whether it is ready
to be installed again.
 38 Software Requirements & Specifications

o In a third mode a user should be given an option to select any

combination of tests he wants to run for a recorder, this can be used to
test selected functionality or operation.

• There is a continuous mode to repeat the same tests selected any number of times
till the execution is aborted eventually.

• The database should also have information about which all tests will be
supported by a particular recorder and none of the tests for a recorder should be
missing.

• One special test is to be conducted to check any electrical fault in the recorder
which can damage the equipment. This test should be kept as optional but should
be recommended by showing a dialog.

• The test once executed should be provided with the option to abort in between of
the execution.

• The test when aborted should decide if the currently running test is going to take
more time for completion than a predefined threshold value, then the test is
aborted then and there without completion, otherwise it is allowed to complete
that particular test.

• The status window shows the status of tests that are executing and contents
should be continuously refreshed. It should also show time duration the test took
to complete.

• Summary window displays the summary report of steps took place during the
test.
Flight Recorder Applications 39

• There should be three levels of details for summary report that user may select
out from, to filter the contents of the report to the level required. This option to
change the level shall be provided in menu bar.

• User shall be able to save both the status report and summary report. He shall
also be able to print the reports and also see the print preview using the same
application.

• The application shall provide the operator an option to printout the Test report.

• The Test Report shall provide the following details:

o Operator Name

o Test Date and Time

o Recorder Model Number

o Recorder Serial Number

o Voltage Source

o Comments

o Itemized Test performed with a Pass/Fail/Abort/Error indicator.

o Overall Pass/Fail indication

• The software should embed a tool to view the memory contents of the recorder in
an understandable format. It shows the contents in hexadecimal as well as in
binary format.
 40 Software Requirements & Specifications

• That tool should be able to save that content in the disc with a specified name.

• There should be an admin mode which is activated by entering a password, the

whole thing is activated only if the application is registered by giving a particular
key provided with the package.

• The admin mode enables us to access some of the functionalities that are disabled
otherwise like in memory viewing tool to switch to Hex mode. Other
Functionalities are to get the software version of the recorder and initialize the
UUT.

5.2.4. User Profile/ Usage Scenarios

The various distinct classes of users who will use the Flight recorder testing software
application are:

• Maintenance Engineering of Airlines (End Customers).

• Recorder Engineering (DMR) group

• Customer Support Engineering

The typical usage scenarios for the Flight recorder testing software application:

• Go/ No-Go Acceptance Tests of recorders

• End-Item tests during recorder assembly.

Flight Recorder Applications 41

• Troubleshooting aide to perform tests on a specific interface under consideration,

during various stages of recorder development and testing.
42 Software Requirements & Specifications
Flight Recorder Applications 43

DESIGN PHASE
44 Design Phase
 Flight Recorder Applications 45

6. DESIGN PHASE
6.1. System Description
This system is designed to connect and interact with the flight recorder
connected and extract the data out to analyze it further or store it in archives to keep the
records of it.

Figure 4: Basic diagram to show the working of flight data playing software
 46 Design Phase

The PCI card installed in the system is a dedicated hardware that takes machine level
instructions from the system and with the help of drivers converts them to system
commands that are understandable to the recorder. The system thus fetches data from
the recorder and stores it for future use. This data can, anytime, be used to extract
desirable data of his choice out of any amount of data that is present in the
uncompressed data. Once the data is decompressed, separate files are created for all
the data that was asked to decompress. Now the data can be seen using the tool
provided in the application. The sound data can be played by using sound card and its
drivers and individual sound file can be assigned to any channel of that card. The
audio signal is then forwarded to amplifiers and sound is generated from individual
speakers according to the channel assigned.

6.1.1. Interfacing the recorder with the system

The recorders are designed to have one to two connectors to connect them to external
systems, be it the Aircraft or the Ground based system.
 Flight Recorder Applications 47

Figure 5: Connecting a recorder to the system

There are two connectors, front and main connector. The main connector is a high speed
connector which supports all the data that supports high data rate.It is used to connect the
recorder to aircraft and can also be used to connect it to Ground station. The front
connector is used by ground station to connect and download the flight data even when
recorder is already connected to aircraft i.e. main connector is occupied and it is not
required to be disconnected. Front connector doesn’t support audio data. Front connector
 48 Design Phase

is not found in some of the cockpit voice recorder’s older versions. The front connector
also provides Ethernet support for latest recorders. The recorders support two power
options, 28V DC and 115V AC. Any one of the options can be selected depending on the
power source available.

Figure 6: Interfacing of Flight recorder applications with Recorders

 Flight Recorder Applications 49

6.1.2. RPGSE Laptop/Desktop

This host system is fitted with a PCI Interface card. The appropriate Device Drivers need
to be installed to ensure the functioning of the PCI Card.

6.1.3. PCI interfacing card

The 100-pin PCI card is the Ground Support Equipment (GSE) hardware interface to the
recorder. It supports RS-422, ARINC 717 and ARINC 429 protocols. The Flight recorder
testing application will establish communication with the UUT (unit under test) in
accordance with the ICD command definitions over the RS-422 interface. The RS-422
interface permits the execution of command on the UUT and data transfer with the UUT.

6.1.4. Cable

The Cable interfaces the RPGSE system to the recorder. (It connects the 100-pin PCI
Card on one end and main and front connector(s) on the other end). The cable directly
interfaces the audio, ARINC – 717, 429 and most of the discrete signals on the GBE Card
with corresponding signals on the UUT.
The cable supports the following control functions:
• Control of Power Supply to the UUT: 28V DC / 115 V AC (individually)

• 422 selection function to multiplex the RS-422 Download and Main Connector
of the UUT

• Activate CVR Stop Recording and FDR Inhibit function

• Ability to monitor the Channel-4

 50 Design Phase

• Control attenuation levels on Channel 4 (supported for AR-CVR and AR-

COMBI)

• Ability to provide external ARINC 717 signals to the UUT

The cable type is identified based on the status of certain Cable-detect discrete input pins.

6.1.5. Driver wrapper

The Driver wrapper interacts with the PCI card using the software device drivers. The
purpose of this layer is to provide the necessary platform abstraction. If the PCI Card
hardware/Device Driver is modified, this layer should be suitably modified.

6.1.6. Flight Recorder Applications

These applications should interact with the PCI card via the Driver wrapper

6.2. Design Constraints

The Flight recorder applications have to work on RPGSE platform. So the hardware and
software available on RPGSE platform define the operating and timing constraints, which
may be due to:
• Recorder Response Time
• Inherent timing delays in the GBE Card
In case a RS-422 response timeout occurs, the recorder testing application should attempt
to re-transmit the last command.
Flight Recorder Applications 51

TESTING PHASE
52 Testing Phase
 Flight Recorder Applications 53

7. TESTING PHASE

Once the development phase for a version is over, we go ahead with testing the product
for finding any possible bugs and report it to development team about the bug caught.
This process is repeated till the code reaches a satisfactory level of reliability that can be
safely delivered to the customer.

In a typical lifecycle model the testing phase consists of the following sub phases:

• Unit testing (procedure used to validate that individual units of source code are
working properly).

• Integration testing (phase of software testing in which individual software

modules are combined and tested as a group).

• System Testing (testing conducted on a complete, integrated system to evaluate

the system's compliance with its specified requirements).

System testing falls within the scope of black box testing, and as such, should require no
knowledge of the inner design of the code or logic.

When classified according to the aspect of the product that is tested we did test the
following test plans also:

• Installation testing (the setup is tested by installing the package on a fresh

machine and test whether all the files i.e. dlls, executables, drivers, decoders and
other files, are getting copied at their expected locations. Check whether the
 54 Testing Phase

proper versions are getting copied and for their registration. The windows
registries are also tested for appropriate entries which are associated with the
application.

• User Interface testing (the user interface is tested for all the requirements that
were planned and implemented to be available on the windows interface. All the
objects in the interface connect to the corresponding function that is expected to
execute while we use this object).

• Testing different functionalities separately.

• Combine different functionalities and test them together to see the effect one
casts on another and how they work as a unit. This is a concept similar to
Integration testing.

• Test the system as a whole and check for proper functionality and behavior
should be as expected and stated in requirement document.

• Testing the applications for as many configurations of recorders as possible. The

application may behave unexpectedly under different circumstances and
configurations.

• As the product requires playing of audio data which is stored in more that one
format, with more than one codecs required and played on different hardware
cards, it was also tested for quality of sound that is heard from different
permutations of these on individual speakers.

• Testing for any previously reported bug that was fixed in the last or earlier cycle
and report whether the bug has been fixed properly or not.
 Flight Recorder Applications 55

7.1. Tests carried out on Flight Data Playing Software

The flight data playing software is basically an application designed for data
extracting and rendering it in a more human understandable form by decompressing it
and split in different files depending on the data present in the raw data file. The
functionality it provides to users is to present to them flight data in a simpler forma and
cockpit voice data in audio form. Some tests that are specific to this application and do
not apply to recorder testing application are:

• The application is detecting the cable to tell the right kind of recorder. This test
for a whole lot of recorders.

• The flight data that is provided by the utility provided in the software should
render the data in a well arranged format laid out in well defined rows and
columns.

• The option to play the PCM files is playing PCM files only and not the ADPCM
files by mistake.

• The option to play the ADPCM files is playing ADPCM files only and not the
PCM wave files by mistake.

• The dialog box to assign the audio files to audio channels available is showing
only two channels as drop down lists if this stereo card is selected as the default
device in ‘sound and audio device’ properties in control panel of windows.

• The options in drop down list lists the audio files available for playback
associated to the data downloaded from a particular recorder.
 56 Testing Phase

• On activating the playback control, the sound must come from the same stereo
card that is selected as default.

• The dialog box to assign the audio files to audio channels available is showing
four channels as drop down lists if this multichannel card is selected as the
default device in ‘sound and audio device’ properties in control panel of
windows.

• On activating the playback control, the sound must come from the same
multichannel card that is selected as default.

• If one stereo and one multichannel cards are installed in a machine or both stereo
cards are installed and one of the stereo cards is selected as default, then they
play as primary speakers, which are denoted by first two speakers. As the
application can support maximum or four channels at a time the rest two speakers
can also be utilized.

• Within the same audio card, the audio file assigned to a particular channel is
getting played at the same speaker.

• All the audio channels that are assigned with a sound file are playing.

• All the channels are tested, with different permutations of files available assigned
to different channels, for sound quality produced by the speakers.

• The sound quality is compared by playing the same files with some standard
media players like Windows Media Player and Winamp.
 Flight Recorder Applications 57

7.2. Tests carried out on Flight Recorder Testing Software

The Flight Recorder Testing Software is support software to ensure the quality of
recorders that comes out of the manufacturing plant and ensure the smooth and proper
functioning of it during its lifetime. The tests that are specific to this application are
given below:

• On the launch of application it detects for the PCI interfacing card.

• If it fails to detect the card, it switches to simulation mode else it jumps to test
execution mode.

• It asks for the recorder type connected to it through the cable.

• In the help menu check for versions of the application and supporting files
installed in the system.

• The application is getting registered provided the correct key entered.

• It does not get registered if wrong key is provided.

• The options previously disabled get enabled by entering password to go into the
admin mode.

• The memory contents are shown in proper format and data is consistent for both
views i.e. Hex and Binary modes.

• Both the predefined group of tests, on selection shows the tests that are expected
for the recorder selected.
 58 Testing Phase

• The tests to be selected from in manual mode should all apply to the recorder
selected.

• If a test fails once it is failing repeatedly.

• If all tests pass once, they pass repeatedly.

• The results of all the tests should be conducted in continuous mode should match
whatever number of times it repeats.

• If the selected tests are not in continuous mode, then they are not executing more
than once.

• The continuously running tests are stopping its execution only when it is aborted.

• A running test is aborted; it should stop execution showing the status aborted, or
pass or fail (it should complete) if the time of execution left is lesser than a
threshold while execution was aborted.

• The test is not jumping to the next test in queue after the abort button is activated
in any case.
Flight Recorder Applications 59

TOOL SURVEY
60 Tool Survey
 Flight Recorder Applications 61

8. TOOL SURVEY
8.1. The Development Environment Microsoft Visual C++
Visual C++ is an Integrated Development Environment product for the C and
C++ programming languages engineered by Microsoft. It has tools for developing and
debugging C++ code, especially that written for the Microsoft Windows API, the DirectX
API, and the Microsoft .NET Framework.

Visual C++ includes advanced features such as syntax highlighting, IntelliSense (a

coding auto completion feature) and advanced debugging functionality. For example, it
allows for remote debugging using a separate computer and allows debugging by
stepping through code a line at a time. The "edit and continue" functionality allows
changing the source code and rebuilding the program during program debugging, without
restarting the debugged program. It also includes Visual Workbench, an integrated
Windows-based development environment and the Microsoft Foundation Class Library
(MFC), the latter providing a basic framework of object-oriented code to build an
application upon.

MICROSOFT FOUNDATION CLASS (MFC)

The Microsoft Foundation Class (MFC) library is a set of data types, functions, classes,
and constants used to create applications for the Microsoft Widows family of operating
systems. It is an "application framework" for programming in Microsoft Windows.
Written in C++, MFC provides much of the code necessary for managing windows,
menus, and dialog boxes; performing basic input/output; storing collections of data
 62 Tool Survey

objects; and so on. MFC was introduced in 1992 with Microsoft's C/C++ 7.0 compiler
for use with 16-bit versions of Windows.

The MFC framework is a powerful approach that allows the user to build upon the work
of expert programmers for Windows. MFC shortens development time; makes code more
portable; provides tremendous support without reducing programming freedom and
flexibility; and gives easy access to "hard to program" user-interface elements and
technologies, like Active technology, OLE, and Internet programming. Furthermore,
MFC simplifies database programming through Data Access Objects (DAO) and Open
Database Connectivity (ODBC), and network programming through Windows Sockets.
MFC makes it easy to program features like property sheets ("tab dialogs"), print
preview, and floating, customizable toolbars.

When MFC was introduced, Microsoft extended the C++ syntax with a series of macros
for management of windows messages, exceptions, and dynamic class instantiation. The
syntactic changes for windows messages were intended to reduce memory required by
avoiding gratuitous viable use and provide a more concrete structure for various Visual
C++-supplied tools to edit and manipulate code without parsing the full language. The
message-handing macros replaced virtual function mechanism provided by C++. Because
some versions of the macros defeated the type checking done by the compiler, their use
has been a fruitful source of bugs for users of MFC. The macros which implemented
serialization, exception support, and dynamic runtime types were less problematic, and
predated availability of standards-based language extensions by a number of years. 32-bit
versions of MFC, for Windows NT 3.1 and later Windows operating systems, retained
these features in the interest of compatibility.
 Flight Recorder Applications 63

The chief advantage of MFC is that it provides an object-oriented programming model to

the Windows APIs. Another advantage of MFC are C++ wrapper types for many
common Windows resource-related data types that provide automatic closure of handles
when the objects creating them go out of scope. Additionally, MFC provides a
Document/View framework for creating Model-View-Controller-based architectures.

8.2. DirectX
Microsoft DirectX is a collection of application programming interfaces (APIs)
for handling tasks related to multimedia, especially game programming and video, on
Microsoft platforms. Originally, the names of these APIs all began with Direct, such as
Direct3D, DirectDraw, DirectMusic, DirectPlay, DirectSound, and so forth. DirectX,
then, was the generic term for all of these Direct-something APIs, and that term became
the name of the collection. Over the intervening years, some of these APIs have been
deprecated and replaced, so that this naming convention is no longer absolute. In fact, the
X has caught on to the point that it has replaced Direct as the common part in the names
of new DirectX technologies, including XAct, XInput, and so forth. Additionally, when
Microsoft decided to develop game consoles based on DirectX, the X stuck, leading to
the name Xbox (and later Xbox 360).

Direct3D (the 3D graphics API within DirectX) is widely used in the

development of computer games for Microsoft Windows, Microsoft Xbox, and Microsoft
Xbox 360. Direct3D is also used by other software applications for visualization and
graphics tasks, most notably among the engineering sector for CAD/CAM, because of its
ability to quickly render high-quality 3D graphics using DirectX-compatible graphics
hardware. As Direct3D is the most widely recognized API in DirectX, it is common to
see the name DirectX used in place of Direct3D.
 64 Tool Survey

The interfaces that comprise DirectX include components for use by a running
application (runtime components) as well as components for use by software developers
at design time (the software development kit). The runtimes were originally redistributed
by computer game developers along with their games, but are now included as built-in
parts of Microsoft Windows. The SDK is available as a free download. While the
runtimes are proprietary, closed-source software, source code is provided for most of the
SDK samples.

The latest versions of Direct3D, namely, Direct3D 10 and Direct3D 9Ex, are
exclusive to Windows Vista. This is because there were extensive changes in the
Windows graphics architecture, and in particular the introduction of the Windows
Display Driver Model. This redesign of the graphics infrastructure for Windows Vista
supports virtualizing graphics hardware to multiple applications and services such as the
Desktop Window Manager, in contrast to the exclusive access afforded to DirectX
applications on Windows XP. Both Direct3D 9Ex and Direct3D 10 rely on the WDDM
infrastructure and WDDM drivers.
 Flight Recorder Applications 65

8.3. COM DLL

COM is an outgrowth of the OO technology. It is a specification that is based on

a binary standard for reuse through interfaces. That is, components, which are pre-
compiled blocks of code, written for COM can be reused without any dependencies on
the language in which they are coded. The programming language may be Visual Basic,
C++ etc.

COM uses system-level code that is implemented in the form of dynamic

link libraries, which are collectively called COM library. The COM library consists of
several application programming interface (API) functions that are necessary for COM
components to do various tasks. COM library is responsible for locating and activating
server applications. With client applications, COM APIs contains the necessary functions
for instantiating objects that the client wants to use. Also the COM library provides
locator services using the System Control Manager (SCM), which also provides
transparent remote procedure calls when an object is executing out-of-process in a local
or remote server.

COM components may be out-of-process or in-process. An out-of-

process component can effectively be a separate program containing objects. This type
runs in its own process space and will thus be largely independent from any client
programs. These components are often large applications themselves, and provide access
to their objects to make it easy for other programs to create macros or otherwise make use
of existing functionality. This can be very beneficial, because the component developer
can choose his own threading models. The drawback here is that the developer has to
write the code for threading. This work can be handled by automatically COM+ , the
latest one from the COM family.
 66 Tool Survey

An in-process component is one where the objects run inside the client's
process. Each client gets its own private copy of the component and hence a copy of all
the objects in that component. An in-process component is often called COM DLLs or
ActiveX DLLs. In-process component does not have a process of its own and it always
runs within the context of another process. Often this other process is the client
application itself but may be run within the context of a different process entirely. In this
case, we can get performance boost as the component is loaded in the client application
itself. There is almost no overhead when client interacts with an object that is running in
the same process. The major advantages of having in-process components are stability
and increased manageability
Flight Recorder Applications 67

RESULTS AND SNAPSHOTS

Flight Recorder Applications 69

Figure 7: Main window of Flight Data playing software

70 Results & Snapshots

Figure 8: Main window of Flight Recorder Testing software

Flight Recorder Applications 71

Figure 9: Main window of Audio Calibration Utility

Flight Recorder Applications 73

OBSERVATIONS
AND
CONCLUSIONS
 Flight Recorder Applications 75

9. OBSERVATIONS AND CONCLUSIONS

Flight Recorder applications developed can be used to test the
performance of flight recorders. The application Flight Data playing software can be used
to retrieve data stored in the flight recorder for investigation purposes
Future Work:
The Flight Recorder Applications have a lot of scope for future enhancements.
These applications are supporting softwares for Honeywell recorders which need to be
modified for any enhancement in recorder technologies. They also need to be modified
when the requirement to store more number of parameters arises or is standardized, then
the applications need to be modified to support new recorders.

Modifications are already been carried out for the application and the project is going to
continue for quite some more time.
 76 Observation & Conclusion

CONCLUSION

The flight recorders were invented to investigate the cause of accidents. These

investigations gave out reasons why the earlier flights failed. These reasons were used

to develop safety measures for the aircrafts which advance, by the way, over the time,

as new details and information gets in regarding the faults and errors that can happen.

This information inspires the advancement in technology as well and development of

new systems. This information is critical in finding the malicious hand behind (if any).

The information has always made the air journey safer over the time. The flight

recorder software played a very important role in achieving this level of flight safety

that we enjoy nowadays, and they have helped in bringing down the number of

accidents and thus minimizing the loss of lives and property. This trend will continue

and the teams here at HONEYWELL will keep on developing new systems for flight

safety and wishing us a safer and more comfortable journey always.

Flight Recorder Applications 77
Flight Recorder Applications 79

REFERENCES
80 References
 Flight Recorder Applications 81

10. REFERENCES
1) The flight recorder: an architectural aid for system monitoring, Proceedings of
the 1991 ACM/ONR workshop on Parallel and distributed debugging,
portal.acm.org/citation.cfm?id=122775&coll=portal&dl=ACM
2) The remote aircraft flight recorder and advisory telemetrysystem-RAFT
(patent pending) and its application to unifying the totaldigital avionics
system by Levine, S.

3) How it Works: Science and Technology By Wendy Horobin

4) Understanding Flight by David Anderson, Scott Eberhardt

5) www.howstuffworks.com

6) www.honeywell.com

7) Product manuals; requirement and test spec documents (Flight data playing

software)

8) Product manuals; requirement and test spec documents (Flight recorders testing

software)

9) http://www.fftw.org/

10) The FFT ,Fundamentals and Concepts by Robert W. Ramirez

11) DirectX 9 User Interfaces: Design and Implementation by Alan Thorn

12) Introduction to the DirectX® 9 High Level Shading Language

ati.amd.com/developer/ShaderX2_IntroductionToHLSL.pdf
82 References

ati.amd.com/developer/ShaderX2_IntroductionToHLSL.pdf