Page 1 of 37

DEPARTMENT OF AVIONICS ENGINEERING

SUBJECT : Avionics System Design Lab

LAB NO : Lab Project Report

TITLE : Glide Slope ILS Controller

SUBMITTED TO : Sir Irfan Majid

SEMESTER : 9th
SECTION :

Marks Obtained

Group Member
Group Member 2 Group Member 3
1

Abdullah Arif
NAME Ch. Rafay Sayyam Zahid
Khan

REGISTRATION NUMBER 190701035 190701025 190701016

LAB REPORT

PERFORMANCE

TOTAL MARKS

DEADLINE FOR
26th Jan 2024
SUBMISSION:

DATE OF SUBMISSION: 26th Jan 2024

Page 2 of 37

Introduction:
In the domain of aeronautics, the execution of landing an aircraft under arduous
conditions is intricately dependent on a combination of advanced technological
systems and meticulously positioned visual aids. Foremost among these
technological marvels is the glide slope controller, an integral component of the
Instrument Landing System (ILS). This sophisticated mechanism is instrumental in
providing vertical guidance, ensuring that the aircraft maintains an optimal descent
trajectory towards the runway. The controller functions by transmitting a precisely
calibrated radio beam, which divides into two intersecting lobes. These lobes are
then intercepted by the aircraft's glide slope receiver, enabling the maintenance of an
ideal glide path, characteristically at an angle of approximately 3 degrees. This
apparatus proves indispensable, particularly under conditions of reduced visibility,
where it guides pilots with unerring accuracy to the runway.
In conjunction with this advanced system, the practice of runway marker checks is
equally crucial. This procedure involves the identification and confirmation of a
variety of visual markers strategically located on and around the runway. These
markers, encompassing runway thresholds, centerlines, and touchdown zones,
provide essential visual cues for pilots during both the takeoff and landing phases.
Pertinent to the ILS approaches are specific markers, namely the Outer, Middle, and
Inner Markers, which serve as critical distance references from the runway's
threshold. The accurate interpretation of these markers is vital for maintaining the
correct approach path towards the runway.
Please Note that this Project was conducted with a 45-degree glide slope angle to
keep the simulation time a minimum.

Problem Statement:
Design a Glide Slope Controller for an Instrument Landing System (ILS) that
maintains a steady angle of descent for an aircraft during landing. The system will
take inputs from two sensors, add them, and compare the result against a reference
signal. If the combined sensor value is greater than the reference, it indicates that
the aircraft is ascending; if it’s less, the aircraft is descending too quickly. The goal is
to keep the sensor values as close to the reference signal as possible for a steady
descent. The system will not consider horizontal sensors.
Furthermore, the system will implement three check markers on the runway. Each
marker will send a pulse to the main system every 20 seconds as an indicator that
the aircraft has passed over it. If any of the check markers is missed, the landing will
be aborted, and a warning light will be turned on.
Page 3 of 37

Formal Requirements
1. The system shall continuously apply angle error correction
1.1. The system shall take the obtained angle from excel sheet.
1.2. Control is applied Using PID
1.3. Error is sent back through feedback loop for correction

2. Landing Markers will be checked

2.1. Altitude Measurements are taken into account
2.1.1. Outer Marker Altitude is 2500m
2.1.2. Middle Marker Altitude is 1500m
2.1.3. Inner Marker Altitude is 500m
2.2. Distance Measurement is taken into account
2.2.1. Distance of outer marker is 2500m
2.2.2. Distance of middle marker is 1500m
2.2.3. Distance of inner marker is 500m
2.3. Received Pulses are Checked
2.3.1. First Pulse is received after 20s
2.3.2. Second Pulse is received after 40s
2.3.3. Third Pulse is received after 60s

3. Check if all Markers have been cleared by passing through

AND operator
3.1. First Marker clearance is given 40s delay
3.2. Second Marker Clearence is given 20s delay
3.3. Latcher to hold Value according to markers
Page 4 of 37

Interface Control Document (ICD):

An Interface Control Document (ICD) table is a document that provides detailed
information about the interface between two or more systems or subsystems. It
typically includes information such as the interface's purpose, the data that is
exchanged between the systems, the protocols that are used, and the timing and
sequence of the data exchanges.

Interface Control Document (ICD) Table

Data Min Max Unit
Name Source Destination Type Value Value s Description
Inputs for glide
Sensor 1, Glide Slope slope
Sensor Inputs Sensor 2 Controller Float -1 1 - calculation
Glide
Glide Slope Slope Glide Slope Combined
Calculation Controller Controller Float -1 1 - sensor value
Decision to
ascend or
Ascent/ Glide descend based
Descent Slope Glide Slope on sensor
Decision Controller Controller Boolean 0 1 - inputs
Pulse sent
every 20
seconds if
aircraft passes
Check Marker Check Glide Slope over a check
Pulse Marker Controller Boolean 0 1 - marker
Signal to abort
Glide Aircraft landing if any
Landing Abort Slope Control check marker is
Signal Controller System Boolean 0 1 - missed
Signal to turn
on warning light
Glide Warning if any check
Warning Light Slope Light marker is
Signal Controller System Boolean 0 1 - missed
Page 5 of 37

Functional Hazzard Assessment (FHA):

Class A system is typically used for systems with a high level of safety criticality,
where a failure could result in severe injury or death. This would include systems
such as the flight control system or the landing gear system.
Class B system is typically used for systems with a moderate level of safety
criticality, where a failure could result in injury or damage. This would include
systems such as the cockpit display system or the fuel system.
Class C system is typically used for systems with a low level of safety criticality,
where a failure would not result in injury or damage. This would include systems
such as the cabin lighting system or the in-flight entertainment system.
Entire System DAL: Class B.
Phase of Flight: Landing.
Page 6 of 37

Simulink Model:

Project Requirement Report Summary:

Page 7 of 37

Requirements Implementation Status:

Requirement Highlights:
Page 8 of 37

DO-178/DO-331 Desing Assurance Level Test:

The Failures are associated with the Design verifier as we are inputting data from
CSVs and Marcker Check Subsystem is partially Compatible because of Discrete
Impulse Blocks.

Subsystems:
1. PID Controller Subsystem:

Controller Settings:
Hit and Trial method was used and the following values were selected.
(i) P = 0.05
(ii) I = 0.9
Page 9 of 37

(iii) D = 0.01
(iv) N = 50

Angle Data:

PID Output:
Page 10 of 37

PID Subsystem Harness:

PID Controller Harness Signal Builder:

Angle Values were Directly Imported into the signal Builder and a threshold of
-0.65 to 0.65 was applied for assertion check.

PID Subsystem Compatibility Check:

Page 11 of 37

PID Controller Subsystem Dead Logic Error Check:

PID Controller Subsystem HDL Code Traceability:

Page 12 of 37

2. Altitude Check Subsystem:

For each marker to clear an altitude criteria must be cleared.

Altitude Data:
Page 13 of 37

Subsystem Output:

Altitude Check Subsystem Harness:

Page 14 of 37

Altitude Check Subsystem Harness Signal Builder:

Altitude Subsystem Compatibility:

Page 15 of 37

Altitude Subsystem Dead Logic Error Check:

Altitude Subsystem HDL Code Traceability:

Page 16 of 37

3. Distance Subsystem:

Subsystem Output:
Page 17 of 37

Distance Subsystem Harness:

Distance Subsystem Harness Signal Builder:

Page 18 of 37

Distance Subsystem Compatibility:

Distance Subsystem Dealogic Error Check:

Page 19 of 37

Distance Subsystem HDL Code Traceability:

4. Marker Clearence Subsystem:

Page 20 of 37

Marker Clearence Subsystem Output:

Marker Clearence Subsystem Harness:

Page 21 of 37

Marker Clearence Subsystem Harness Signal Builder:

For Inputs

For Assertion Check

Marker Clearence Subsystem Compatibility:

System is partially compatible because of the use of Discrete Impulse Blocks
Page 22 of 37

Marker Clearence Subsystem Dead Logic Error Check:

Page 23 of 37

Marker Clearence Subsystem C-code Traceability:

5. Marker Hold Subsystem:

Page 24 of 37

Marker Hold Subsystem Output:

Marker Hold Subsystem Harness:

Page 25 of 37

Marker Hold Subsystem Harness Signal Builder:

For Inputs

For Assertion Check

Page 26 of 37

Marker Hold Subsystem compatibility:

Marker Hold Subsystem Dead Logic Error Check:

Page 27 of 37

Marker Hold Subsystem HDL Code Traceability:

System Coverage Report:

Page 28 of 37

Coverage Summary:

Simulink Test Manager Executed Tests:

Page 29 of 37

Visualization of Results:

Verification and Validation Table:

Time Distance (m) Altitude(m) Output Status Data type

20 Seconds 2500 2500 1 LED 1 ON Boolean

40 Seconds 1500 1500 1 LED 2 ON Boolean

60 Seconds 500 500 1 LED 3 ON Boolean

Page 30 of 37
Hardware Implementation:
Code Comparison:
Arduino Code
LEDs, Buzzer, LCD Setup:
Defines LED pins (6, 7, 8), buzzer pin (9),
and LCD pins.
Uses Liquid Crystal library for LCD.
Initialization in setup() function.
Main Loop:
Utilizes Millis() for timing.
Implements conditional logic based on time
intervals to control LEDs, buzzer, and LCD
messages.
No explicit handling of altitude and distance
variables in the provided code snippet.
Direct manipulation of hardware (LEDs,
buzzer, LCD) based on conditional checks.
Programming Style:
Procedural style with direct control of
hardware components.
Manual timing control using millis() and
delay().
Simulink model code
Subsystem and Signal Handling:
Uses a model-based design approach.
Manages signals and states through
specific structures (DW_Subsystem3_T,
ExtU_Subsystem3_T,
ExtY_Subsystem3_T).
Main Function (Subsystem3_step):
Controlled execution of the subsystem.
Uses Boolean signals and delay blocks for
logic implementation.
Utilizes discrete impulse generators.
No direct hardware manipulation; abstracts
the control logic.
Programming Style:
Model-based design, focusing on system
behavior rather than direct hardware
control.
Generated code is part of a larger system
model, likely to be integrated with other
subsystems.
Assumes interaction with external inputs
and outputs, which are probably mapped to
hardware in a higher-level system
configuration.
hardware interaction, while Arduino code
includes direct hardware manipulation.
Page 31 of 37

Key Differences:
Control Approach:
Arduino code directly manipulates hardware, while Simulink code abstracts the
control logic and focuses on system behaviour.
Timing Mechanisms:
Arduino uses manual timing with millis () and delay (), whereas Simulink utilizes
signal-based timing and discrete impulses.
Complexity and Scalability:
Simulink’s model-based approach is generally more scalable and adaptable to
complex systems. In contrast, the Arduino code is more straightforward but might
become cumbersome for large-scale systems.
Hardware Abstraction:
Simulink code separates logic from hardware, implying a different layer handles the
actual

Integration:
Simulink code is designed to be part of an integrated system, whereas Arduino code
is self-contained for the specific application.
Page 32 of 37

Flow Chart of System:

1. Vertical Glideslope Controller: This is your system for controlling the

aircraft's vertical position during an ILS approach.
2. 3-Marker Check Unit: This unit is responsible for monitoring the 3-marker
beacon signals, which are part of the ILS system.
3. Avionics Data Buses (e.g., ARINC 429): Common data buses used in
avionics systems. ARINC 429 is just an example; the actual bus used may
depend on the aircraft's avionics architecture.
4. Interface Units: These units facilitate communication between your
Glideslope Controller, 3-Marker Check Unit, and the Avionics Data Buses. The
interface units convert and format data as needed for compatibility with the
avionics data bus.
5. Avionics System Integration: The integrated avionics system incorporates
the data from the Glideslope Controller and 3-Marker Check Unit into the
broader avionics network. This could involve the Flight Control Computer and
other relevant avionic systems.
Page 33 of 37

Integrated Modular Avionics (IMA):

Integrated Modular Avionics (IMA) is a real-time computer network airborne system.
This network consists of a number of computing modules capable of supporting
numerous applications of differing criticality levels. Here are some key features of
IMA architecture:
1. Integrated Architecture: Unlike traditional federated architectures, the IMA
concept proposes an integrated architecture with application software portable
across an assembly of common hardware modules¹.
2. Modularity: IMA modularity simplifies the development process of avionics
software. As the structure of the modules network is unified, it is mandatory to use a
common API to access the hardware and network resources, thus simplifying the
hardware and software integration.
3. Software Updates and Upgrades: IMA allows for the updating and upgrading of
the software that controls the system, ensuring the compatibility and interoperability
of the software with the hardware and other systems.
4. Obsolescence Management: IMA identifies the components and systems that
may become obsolete over time and develops a plan for managing and replacing
them.
5. Partitioning: Partitioning is generally used in order to help segregate mixed
criticality applications and thus ease the verification process.

Our Architecture:
Our Architecture will contain the following
1. Localizer: This provides lateral course guidance during an approach to
landing. It’s a critical component of the IMA architecture.
2. Glide Path: This provides vertical guidance. It’s another crucial component
that ensures the aircraft maintains the correct altitude during landing.
3. Marker Beacons: These provide supplementary range information. They help
the pilot determine the aircraft’s distance from the runway.
4. Receivers: These are responsible for receiving signals from the localizer,
glide path, and marker beacons. They play a key role in processing the
guidance information.
5. Instrumentation: This displays the guidance information to the pilot. It’s
essential for the pilot to make informed decisions during the landing phase.
6. Software Updates and Upgrades: The IMA architecture allows for the
updating and upgrading of the software that controls the system. This ensures
the compatibility and interoperability of the software with the hardware and
other systems.
7. Obsolescence Management: This involves identifying the components and
systems that may become obsolete over time and developing a plan for
managing and replacing them. It’s a proactive approach to ensure the
longevity of the system.
Page 34 of 37

Certifications Required:
Developing a Glide Slope Instrument Landing System (ILS) with marker beacons
necessitates strict adherence to certification standards and testing protocols,
particularly due to the system's critical role in aviation safety. While providing a
general overview, it's crucial to note that specific requirements may vary based on
jurisdiction (e.g., FAA in the United States or EASA in Europe) and the type of aircraft
involved.
1. Technical Standard Orders (TSOs) / European Technical Standard
Orders (ETSOs):
 In the U.S., the FAA issues TSOs, outlining minimum performance
standards for materials, parts, processes, and appliances on civil
aircraft. Similarly, EASA issues comparable standards in Europe.
 Relevant TSOs for ILS systems encompass navigation equipment
standards.
2. Environmental Testing (RTCA DO-160 / EUROCAE ED-14):
 Encompassing environmental conditions and test procedures for
airborne equipment, this standard includes tests like temperature and
altitude, humidity, shocks, vibrations, and more.
3. Electromagnetic Compatibility (EMC) and Interference Testing:
 Ensures the system emits no harmful electromagnetic interference and
is resilient against interference from external sources.
 Standards such as RTCA DO-160G cover EMC testing aspects.
4. Software Certification (RTCA DO-178C / EUROCAE ED-12C):
 If the system includes software, compliance with these standards is
crucial. They focus on ensuring software reliability and safety in
airborne systems, with testing rigor varying based on software levels.
5. System Safety Assessment (RTCA DO-254 / EUROCAE ED-80):
 For hardware components like FPGA and ASIC, ensuring they meet
required safety and reliability levels.
6. Flight Tests:
 Actual in-flight testing to verify system functionality under real
operational conditions.
7. Operational Tests:
 Testing to ensure the system meets operational requirements across
various scenarios.
8. Human Factors Consideration (RTCA DO-178):
Page 35 of 37

 Ensuring the system's design is intuitive and does not induce operator
errors.
9. Maintenance and Reliability Testing:
 Ensuring the system is reliable and can be maintained according to
industry standards.
10. Certification for Specific Aircraft Type:
 The system must undergo testing and certification for each aircraft
type, involving integration tests to ensure compatibility with specific
aircraft systems.
11. Cyber security Assessment (RTCA DO-326A / EUROCAE ED-202A):
 If the system connects to networks, cyber security assessments are
essential to safeguard against potential cyber threats.

Standards and Testing for Hardware Certification:

1. Environmental Testing: We ensure that our hardware can withstand flight
conditions such as temperature, humidity, vibration, and altitude. We
commonly use standards such as RTCA/DO-160 for these tests.
2. Emissions and Immunity Testing: Our tests ensure that the hardware does
not emit any harmful electromagnetic interference (EMI) and that it is immune
to any EMI it may be exposed to in the aircraft. We commonly use standards
such as RTCA/DO-160 for these tests.
3. Safety Testing: We conduct tests such as flammability, toxicity, and smoke
density to ensure that the hardware does not pose any safety hazards in the
event of a fire or other emergency. We commonly use standards such as
RTCA/DO-160 for these tests.
4. Stress and Fatigue Testing: Our tests ensure that the hardware can
withstand the stresses of flight, such as vibration and fatigue, without failing.
We commonly use standards such as RTCA/DO-160 and ASTM E467 for
these tests.
5. Software and Firmware Testing: This includes functional testing, integration
testing, and certification testing to ensure that the software and firmware are
working properly and are compliant with relevant standards. We commonly
use standards such as RTCA/DO-178C, RTCA/DO-254, and DO-178B for
these tests.
6. Certification Testing: We conduct various types of testing such as type
certification, production certification, and airworthiness certification, which are
required to ensure that the hardware meets all safety and performance
standards set by the relevant regulatory agencies before it can be installed on
an aircraft. We commonly use standards such as Federal Aviation Regulation
(FAR) Part 23, 25, 27, 29 for these tests.
7. Fuel System Testing: We test the hardware’s compatibility with different
types of fuels and ensure that it can function properly in the fuel system. We
commonly use standards such as RTCA/DO-160 and ASTM D3241 for these
tests.
Page 36 of 37

8. Hydraulic and Pneumatic Testing: We test the hardware’s compatibility with

the aircraft’s hydraulic and pneumatic systems and ensure that it can function
properly in these systems. We commonly use standards such as RTCA/DO-
160 and SAE AS4059 for these tests.
9. Electrical System Testing: We test the hardware’s compatibility with the
aircraft’s electrical systems and ensure that it can function properly in these
systems. We commonly use standards such as RTCA/DO-160 and SAE
ARP5412A for these tests.
10. Fire Protection Testing: We test the hardware’s ability to withstand exposure
to fire and ensure that it does not contribute to the spread of fire in the aircraft.
We commonly use standards such as RTCA/DO-160 for these tests.
11. Crashworthiness Testing: We test the hardware’s ability to protect the
aircraft’s occupants in the event of a crash. We commonly use standards such
as RTCA/DO-160 for these tests.
12. Human Factors Testing: We test the hardware’s compatibility with the
human operators and ensure that it is easy to use and understand. We
commonly use standards such as RTCA/DO-160 and SAE ARP4761 for these
tests.
13. Corrosion Testing: We test the hardware’s resistance to corrosion and
ensure that it can withstand the harsh environments of flight. We commonly
use standards such as RTCA/DO-160 for these tests.
14. Ground Handling Testing: We test the hardware’s compatibility with the
equipment used for ground handling and maintenance of the aircraft. We
commonly use standards such as RTCA/DO-160 and SAE ARP4754A for
these tests.
10-year Life Cycle Support:
1. Maintenance and Support Plan
Identify components, tasks, and procedures. Define performance indicators, quality
standards, and reliability requirements.

2. Support Team
Identify and train personnel. Establish a communication and collaboration system.

3. Logistics Plan
Identify necessary parts, tools, and equipment. Establish a system for acquisition,
storage, and distribution. Estimate costs and risks. Plan for 10 Arduinos and 4
Simulink licenses over 10 years.

4. Testing and Inspection Plan

Identify test equipment and procedures. Define acceptance criteria, test cases, and
results.

5. Tracking and Reporting System

Establish a system for tracking tasks and reporting issues. Create a feedback and
improvement mechanism.
Page 37 of 37

6. Repair and Overhaul Plan

Identify procedures and resources for repair or overhaul. Develop a contingency and
backup plan.

7. Software Updates and Upgrades

Identify procedures and resources for software updates and upgrades. Ensure
software compatibility and interoperability.

8. Obsolescence Management
Identify potential obsolete components and develop a replacement plan. Monitor
market trends and technological developments.

9. Training and Technical Support

Provide training and technical support. Create a user manual and troubleshooting
guide.

10. Review and Update the Plan

Regularly review and update the plan. Conduct periodic audits and evaluations.

___________________________________________________________________