Avionics Systems and Unmanned Aerial Vehicles

The first version of this course note was prepared in September 2015, drawing on the technical work and experience from my computer engineering internship at Baykar, including avionics systems, embedded software, MISRA C, static code analysis, telemetry, and UAV systems. The original scope has been preserved while the material was reviewed and expanded in September 2026 using current standards and publicly available technical information.

Avionics systems can be understood through the relationship among basic flight physics, aircraft dynamics, navigation, sensor fusion, automatic flight, data communication, ground control, and fault tolerance. In unmanned aerial vehicles, these topics do not remain separate disciplines; they operate as one system. This set of notes examines that integration together with publicly available Bayraktar TB2 information and my 2015 internship experience at Baykar.

For me this is not only a theoretical aviation subject. During my computer-engineering internship at Baykar in 2015, I began in Ikitelli with embedded networking on the TMS570 and lwIP and later worked in Kesan around real UAV systems, avionics debugging, C/C# static analysis, and ground-control telemetry. In the same year, the Bayraktar TB2 reached milestones including its second serial delivery, its first 1,000 flight hours, and its first munitions demonstration. Flight control, telemetry, sensor fusion, and fault tolerance are easy to study as separate course topics; in the field it becomes much clearer that they are parts of the same engineering system.

The static-analysis work did not begin as a quality check added near the end of the internship. I first studied and documented the ANSI and ISO context, with particular attention to MISRA C, and then treated automated checking of applicable rules as one of the first priorities in the analysis software I developed. Coding standard, analysis tooling, and project workflow were therefore connected from the beginning. I discuss that work in more detail in MISRA C and Static Code Analysis.

Only public information is used here. Current Bayraktar TB2 specifications are not projected backward onto the 2015 configuration. The platform has evolved over time, so differences among official documents published in different years are expected.

Unit 1: Flight Physics and Core Avionics Concepts

1. What is an avionics system?

The word avionics combines aviation and electronics. It covers the electronic, sensing, computing, communication, and control functions that support flight.

An aircraft avionics system is not merely a cockpit display or a flight computer. A modern avionics architecture typically brings together functions such as:

• measuring aircraft state,
• computing position and attitude,
• receiving commands from a pilot or operator,
• controlling flight surfaces and other actuators,
• managing the mission and flight plan,
• operating external-world sensors and payloads,
• providing communications,
• monitoring system health,
• detecting and, where possible, isolating faults,
• preventing the loss of critical functions after a single failure.

In a crewed aircraft, the pilot is physically present in the aircraft and remains a central decision maker. In an unmanned aircraft, removing the pilot from the airframe does not reduce avionics requirements. State estimation, communications, automatic flight, and fault management instead become even more decisive because the aircraft must continue to understand and control itself across a remote link.

An airframe and an engine are not enough to make a UAV operational. Flight must be measured, interpreted, and controlled.

2. Physical basis of flight

The shortest path to understanding a fixed-wing aircraft begins with four fundamental forces:

• lift,
• weight,
• thrust,
• drag.

In an idealized straight-and-level condition, lift balances weight and thrust balances drag. Real flight continuously departs from that balance because speed, altitude, wind, maneuvering, and control inputs change.

2.1. Dynamic pressure

A large part of aerodynamic force is associated with dynamic pressure:

q = ½ρV²

where:

• q: dynamic pressure,
• ρ: air density,
• V: airspeed relative to the surrounding air.

Because dynamic pressure varies with the square of velocity, the same control-surface deflection does not create the same effect at low and high airspeed. A flight-control system must therefore consider not only a commanded deflection but also the operating point of the aircraft.

2.2. Lift and drag

Lift can be approximated as:

L = ½ρV²SC_L

and drag as:

D = ½ρV²SC_D

Here S is wing area, C_L is the lift coefficient, and C_D is the drag coefficient.

These equations demonstrate an important engineering fact: flight cannot be explained from mechanical geometry alone. Air density, speed, angle of attack, airfoil characteristics, and aircraft configuration must be considered together.

2.3. Angle of attack

Angle of attack is the angle between an airfoil reference line and the relative airflow.

Within a normal operating range, increasing angle of attack generally increases lift coefficient. Once the flow begins to separate strongly from the wing, however, lift degrades rapidly and the wing can stall.

A stall is not simply an event that happens because an aircraft becomes “too slow.” The governing quantity is angle of attack. Airspeed, load factor, turns, and maneuvering determine how close the aircraft comes to the critical angle.

Reliable automatic flight is therefore not only a route-following problem. Keeping the aircraft inside a safe flight envelope is also part of the control problem.

3. Aircraft axes and motion

An aircraft has six degrees of freedom: three translational and three rotational.

A body-fixed coordinate frame commonly uses:

• forward axis x,
• lateral axis y,
• vertical axis z.

Rotations about these axes are commonly called:

• roll,
• pitch,
• yaw.

Angular rates are often represented as:

• p: roll rate,
• q: pitch rate,
• r: yaw rate.

Because inertial sensors are physically mounted to the airframe, the body frame is also natural from the avionics perspective. Sensors first measure quantities in body coordinates; navigation and control software then transforms those measurements into the reference frames required by the application.

This is one of the points where software enters directly into physics. A sign error in a coordinate transformation, an incorrect unit, a missing timestamp, or a wrong axis convention can turn a small software defect into an incorrect estimate of aircraft state.

4. Stability, control, and feedback

A stable system tends to return toward an equilibrium after a small disturbance. In an unstable system, small deviations can grow with time.

Aerodynamic stability must be considered together with performance. Some aircraft configurations deliberately reduce natural stability to improve drag or maneuvering characteristics. The cost is a stronger dependence on active control.

Flight control therefore becomes a classical feedback problem:

e(t) = r(t) - y(t)

where:

• r(t): desired state,
• y(t): measured or estimated state,
• e(t): control error.

A controller uses this error to generate actuator commands.

To achieve a desired bank angle, for example, a controller does not merely move an aileron to one fixed deflection. It observes measured bank angle and angular rate, evaluates the dynamic response of the aircraft, and continuously corrects the command in a closed loop.

An autopilot is therefore not software that simply replays a list of predefined motions. It is a real-time system in which sensing, state estimation, control laws, actuators, and feedback operate together.

5. Fly-by-wire and digital flight control

In a fly-by-wire system, control commands are processed electrically and digitally rather than being transmitted solely through direct mechanical linkages.

A simplified loop is:

command → flight computer → control law → actuator → aircraft → sensor → feedback

This architecture is natural for a UAV because the remote operator has no physical mechanical linkage to the aircraft. Flight computers, sensors, and actuators are intrinsic parts of the control path.

Digital flight control provides capabilities such as:

• gain scheduling across operating points,
• complex control laws,
• processing multiple sensor sources,
• comparing redundant channels,
• fault detection,
• built-in testing,
• flight-data recording,
• functional updates through software.

The trade-off is that software faults become part of the flight-safety problem. “It runs” is not a sufficient engineering statement for flight-critical software. Timing, data validity, failure behavior, memory behavior, input bounds, and fault propagation are also part of the design.

Unit 2: Sensors, Navigation, and Flight Control

6. Air-data systems

An aircraft needs to know not only where it is but also how it is moving through the atmosphere.

An air-data system may provide or contribute to values such as:

• static pressure,
• total pressure,
• pressure altitude,
• calibrated airspeed,
• true airspeed,
• Mach number,
• air temperature,
• vertical speed,
• angle of attack.

Pressure altitude and airspeed are fundamental control states. Because a given control-surface deflection produces different aerodynamic moments at different speeds, flight-control gains may be scheduled according to air-data conditions.

For a UAV, air data is especially important for three groups of functions:

1. Flight envelope: protecting against stall and overspeed conditions.
2. Autopilot: running altitude, speed, climb, and descent modes.
3. Navigation: combining airspeed and barometric altitude with other sensors.

A sensor value is never the whole physical truth. Calibration, installation effects, pressure error, temperature, sampling time, and data validity are part of the measurement as well.

7. IMU, gyroscopes, and accelerometers

One of the central building blocks of modern avionics is the inertial measurement unit.

A typical IMU measures three-axis:

• angular rate with gyroscopes,
• specific force with accelerometers.

In a strap-down architecture the sensors are fixed to the airframe, and attitude, velocity, and position are computed numerically rather than by mechanically stabilized platforms.

In an idealized system, integrating acceleration gives velocity and integrating velocity gives position. Real sensors, however, contain:

• bias,
• scale-factor error,
• axis misalignment,
• temperature sensitivity,
• noise,
• drift.

Integration causes many of these errors to accumulate. That is one of the fundamental limitations of inertial navigation.

The engineering conclusion is that robust navigation is not simply a matter of choosing a “good GPS” or a “good IMU.” Sensors with different error characteristics must be combined correctly.

8. Attitude and state estimation

One of the flight computer’s fundamental questions is:

Where is the aircraft, how is it oriented, and how is it moving now?

A state vector depends on the application, but an example can be represented as:

x = [position, velocity, attitude, angular rate, sensor biases]

Attitude can be expressed through Euler angles, while computation often uses quaternions or other representations to avoid singularities and improve numerical behavior.

State estimation combines multiple sensors inside a common physical model. Instead of trusting one measurement source blindly, the estimator can reason about consistency among measurements and model predictions.

That is why sensor fusion is central to UAV reliability.

9. GPS/GNSS, INS, and sensor fusion

Satellite navigation provides long-term absolute position information. Inertial navigation provides high-rate, smooth short-term motion information.

Their error characteristics complement each other:

• GNSS provides absolute position but can suffer latency, outages, degradation, or interference.
• INS can continue without external radio navigation but its errors grow over time.

Combining GNSS and INS is therefore a natural solution.

9.1. Kalman filtering

At a high level, a Kalman filter alternates between two operations:

1. predict the state using a system model,
2. correct the prediction when a new measurement arrives.

A simplified prediction can be written as x̂⁻ₖ = F x̂ₖ₋₁.

When a measurement becomes available, the correction can be represented as x̂ₖ = x̂⁻ₖ + K(zₖ - Hx̂⁻ₖ).

The innovation term zₖ - Hx̂⁻ₖ is the difference between the actual measurement and the measurement expected from the predicted state.

The same framework can estimate quantities such as gyroscope bias and accelerometer bias, not only position.

For a UAV, sensor fusion is effectively part of the control system’s perception. No control law can compensate for consistently incorrect state information.

9.2. Coordinate frames and time alignment

Combining sensor values is not enough. The values must represent the same physical quantity in compatible coordinate frames and on a compatible time basis. GNSS position normally arrives in a geodetic reference system, whereas IMU measurements originate in body axes. The navigation solution must transform data among earth, local-navigation, and body frames as required by the system.

WGS 84 is a widely used global geodetic reference. Flight-control algorithms often work in local navigation frames such as north-east-down together with body coordinates. A sign error, axis-order mistake, or unit mismatch in these transformations can convert correct sensor data into an incorrect physical interpretation.

Time alignment is equally important. A 100 Hz IMU and a slower GNSS receiver cannot be fused correctly merely according to packet arrival order. The estimator must know when each measurement was taken, the transport and processing latency, and how to propagate the state to a common estimation instant. Sensor fusion is therefore a problem of coordinate consistency and temporal consistency as well as statistical estimation.

10. Autopilot and flight management

Autopilot and flight management are not the same function.

An autopilot closes control loops around specific targets such as:

• bank-angle hold,
• heading hold,
• altitude hold,
• speed hold,
• climb or descent,
• route tracking.

Flight management operates at a higher level and may deal with:

• flight plans,
• waypoint sequences,
• mission routes,
• speed and altitude profiles,
• mission phases,
• route changes,
• performance prediction.

The distinction becomes especially clear in unmanned aircraft.

A ground operator normally does not command “move the aileron three degrees to the right.” A higher-level intent is given instead:

fly to this waypoint

To execute that intent, the system must:

1. determine current position,
2. compute the required path,
3. derive heading and bank targets,
4. run lower-level flight-control loops,
5. compensate for wind and disturbances.

As autonomy increases, operator commands move to a higher level of abstraction. The lower-level feedback loops do not disappear; more responsibility is delegated to them.

Unit 3: UAV Architecture, Ground Control, Telemetry, and Real-Time Communications

11. UAV system architecture

A UAV should not be viewed only as a flying platform. An operational system generally contains:

• the aircraft,
• flight-control system,
• mission computer,
• sensors,
• payloads,
• data link,
• ground control station,
• operator interface,
• mission-planning and recording infrastructure,
• maintenance and test equipment.

This system view is important when I look back at the 2015 internship. The system visible in Kesan was not simply an aircraft in the sky. There was a continuous path between the air vehicle and the software on the ground: data transfer, monitoring, debugging, recording, and operator interaction. From a computer-engineering perspective, a large part of the UAV becomes visible precisely through these interfaces.

12. Ground control stations

In a crewed aircraft, many flight and system indications are presented directly in the cockpit. In a UAV, much of that information moves to the ground control station.

A ground-control interface may display:

• position,
• altitude,
• airspeed and groundspeed,
• heading,
• pitch and roll,
• route and waypoints,
• engine and power-system status,
• flight mode,
• data-link status,
• sensor and payload status,
• video or electro-optical imagery,
• warnings and faults.

The user interface is not cosmetic in this setting.

If the operator selects the wrong flight mode, treats stale telemetry as current, or misses a critical alarm, the problem becomes a system-level failure. Information density, prioritization, mode awareness, and error visibility must therefore be handled as engineering requirements rather than decoration.

13. Telemetry: from numbers to system state

Telemetry is more than displaying values received from the aircraft.

For every telemetry value, questions such as these matter:

• What is the source of the value?
• When was it measured?
• What unit does it use?
• When was it last updated?
• Is it valid?
• Is it inside an expected range?
• At what sampling rate is it produced?
• Were packets lost?
• Were sequence numbers skipped?
• Is the value a raw sensor measurement, an estimate, or a command?
• Can an old value remain on screen and appear current?

In a ground station, altitude = 5000 is not a complete data model.

A more useful representation is closer to:

value + unit + source + measurement time + validity + quality + sequence

Working on ground-control telemetry in 2015 made the difference between theoretical networking and a live real-time system very tangible. Latency, link interruption, or malformed data were no longer laboratory examples; they directly affected whether the system state was understood correctly.

14. Embedded networking and data flow

UAV communication can be considered at two different scales:

1. communication inside the aircraft among avionics components,
2. the data link between the aircraft and the ground system.

Internal buses allow sensors, computers, and actuators to exchange information. The air-ground link may carry commands, telemetry, mission data, and payload data.

Bandwidth is only one engineering constraint. Other relevant properties include:

• latency,
• latency variation,
• packet loss,
• ordering,
• data integrity,
• error detection,
• time alignment,
• prioritization,
• behavior after link loss.

Losing a packet in a video stream and losing a flight-mode command do not belong to the same consequence class. Critical-system traffic must be classified by semantics and risk, not just by byte rate.

That is also the avionics significance of the TMS570 and lwIP work I performed. A network stack is not merely a TCP/IP programming subject. It is part of the boundary among processor behavior, timing, fault handling, and the physical system.

14.1. Avionics data buses: different requirements, different designs

Not every avionics data path needs to be Ethernet- or IP-based. Different aircraft generations and system architectures use buses selected for their reliability, wiring, bandwidth, determinism, and environmental constraints.

ARINC 429 is a long-established civil-avionics data-transfer standard with a deliberately simple and predictable model. MIL-STD-1553 defines a different command/response architecture in which a bus controller manages communication on the multiplex data bus. Mentioning these standards here does not imply that the Bayraktar TB2 uses either interface. Platform-internal interfaces should not be inferred without a public source that supports the claim.

The broader engineering lesson is that a data bus should not be selected by bit rate alone. Fault model, topology, bounded latency, timing predictability, electromagnetic environment, maintainability, and interface lifecycle all matter.

15. Real-time behavior and latency

A real-time system is not simply a system that runs very fast.

The essential requirement is:

Producing the result at the correct time is part of producing the correct result.

If a control-loop value must arrive within 10 ms and instead arrives after 500 ms, numerical correctness alone is insufficient.

Avionics software therefore treats concepts such as these as part of functional correctness:

• worst-case execution time (WCET),
• sampling period,
• deadline,
• jitter,
• queueing delay,
• timeout,
• stale data.

The human operator works on a much slower time scale than an inner flight-control loop. Even so, telemetry latency and freshness must remain visible. The operator must be able to distinguish “current state” from “state several seconds ago.”

15.1. Data age and time synchronization

Packet reception time and measurement time are not the same thing. A telemetry packet may have arrived just now while carrying a sensor value sampled significantly earlier. For critical data, it is not enough to attach an arbitrary timestamp; the meaning of that timestamp must be explicit.

In multisensor systems, clock drift, timestamp resolution, buffering, queue delay, and different sampling rates can all affect state estimation. The same numerical value can imply a different physical state when associated with the wrong instant. Data age and time synchronization are therefore part of functional correctness rather than secondary performance metrics.

16. Link loss is a design state, not an exception

A data link in an unmanned system cannot be assumed to be permanently perfect.

Link loss should therefore not be treated as an unexpected exception.

It must be represented explicitly in system design.

Questions that need predefined answers include:

• Under what conditions is the link considered lost?
• Does the aircraft continue the current task?
• Does it navigate toward a predefined point?
• Is there a safe loiter behavior?
• How does the operator see the loss of link?
• How is state reconciled after communication is restored?

The point is not to describe a specific platform’s operational logic. The engineering principle is that failure behavior belongs inside the normal system state model, not outside it.

16.1. Modeling link loss with a state machine

A robust design usually benefits from an explicit state model rather than one if statement for communication loss. A generic design may distinguish normal operation, degraded communication, lost link, safe behavior, reconnection, and state reconciliation. The transitions can depend on timeout, data quality, mission phase, and other context.

This does not claim to represent the real operational state machine of any particular UAV. It demonstrates why a critical communication failure should not be delegated to an exception handler. An explicit state model also provides a clearer basis for testing, fault injection, and review.

Unit 4: Reliability, Fault Tolerance, Static Analysis, and System Integration

17. Redundancy and fault tolerance

In flight-critical systems, the failure of a single component should not necessarily lead to complete loss of the system.

Redundancy can be applied at several levels:

• sensors,
• processors,
• power sources,
• data buses,
• actuators,
• communications,
• software or algorithms.

However, installing three sensors is not by itself fault tolerance.

A redundant system also needs mechanisms such as:

• cross-channel comparison,
• identification of an inconsistent channel,
• voting,
• fault isolation,
• reconfiguration,
• degraded modes,
• common-cause failure analysis.

If three channels depend on the same incorrect assumption, numerical redundancy does not remove the common-cause failure.

This is why critical avionics considers not only redundant hardware but also independence, diversity where appropriate, and containment of fault propagation.

18. FMEA and fault-oriented thinking

Failure Modes and Effects Analysis (FMEA) provides a structured way to ask how a component can fail and what the system consequences will be.

The basic question is:

What happens if this component behaves incorrectly?

That leads to more specific questions:

• Can the failure be detected?
• Does the component produce incorrect data or stop producing data?
• Can the fault propagate to other channels?
• Can the system continue operating?
• Can it move to a safe mode?
• Can the operator understand what happened?

In critical-system engineering, a fault is not only a software event handled by a catch block. Sensors, power, networking, processors, timing, and human interaction have to be considered together.

18.1. Built-in test and health monitoring

Fault tolerance is not only switching to a spare channel after a failure. The system must also be able to observe the health of its components, detect abnormal behavior as early as practical, and isolate the faulty source from healthy ones. Built-In Test (BIT) is one way avionics systems implement this idea.

Built-in test can operate at startup, continuously during operation, or on demand during maintenance. The goal is not merely to output “pass” or “fail.” Health management may also need to determine which capability has been lost, what residual capability remains, and whether the system should enter a degraded mode.

This layer is directly connected to FMEA. FMEA identifies failure modes and consequences; built-in test and health monitoring provide mechanisms by which those failure modes may be observed during operation.

19. Static analysis in avionics software

The avionics meaning of the C and C# static-analysis work I performed during the 2015 internship became clearer to me over time.

This was not a tool experiment that appeared late in the internship. I began the project by studying and documenting programming standards, especially MISRA C. I then made automation of the applicable rules one of the first priorities in the analysis software I developed. I initially wrote C-based checks that scanned source code with explicit lexical state, and later built a C# desktop application that combined my own checks with findings from tools such as Cppcheck and Splint in a common result model.

The durable value was not one particular analyzer. It was the chain from a documented rule, through repeatable automated checking where possible, to source-file and line-level traceability, together with the recognition that different analyzers provide different kinds of assurance for the same source code.

Static analysis can help expose classes of problems such as:

• unreachable code,
• null-pointer and pointer misuse,
• undefined behavior,
• out-of-bounds access,
• unsafe type conversions,
• resource leaks,
• unused states and values,
• overly complex control flow,
• some concurrency defects.

Static analysis does not replace testing or system-level verification.

A more realistic assurance chain is:

sound architecture + explicit requirements + static analysis + testing + integration verification + field evidence

No single tool produces reliability. Different methods are needed because they detect different defect classes and rely on different assumptions.

19.1. MISRA C: separating the rule set from the analyzer

MISRA C is not itself a static-analysis engine. It is a family of guidelines intended to make the use of C in critical systems more predictable and reviewable. A tool may automatically enforce some guidelines, while others can require code review, design evidence, or a controlled deviation process.

For the work I performed in 2015, MISRA C:2012 is the historically correct reference. Later editions do not change what was available and used at that time. MISRA C:2025 is a newer current reference, but the internship documentation and implementation should still be described in its actual MISRA C:2012 context. A compliance claim also cannot be reduced to “the analyzer reports zero warnings.” Applicable guidelines, deviations, and verification evidence need project-level control and traceability.

The subject is developed in greater depth in MISRA C and Static Code Analysis.

19.2. Airworthiness and software assurance

Airworthiness is not equivalent to compiling without errors or passing a software test suite. Evidence about the aircraft and its systems must be considered across system design, hardware, software, maintenance, configuration, and operational context.

For civil airborne software, RTCA DO-178C is one of the central reference documents for development and verification assurance. The FAA’s active AC 20-115D recognizes DO-178C together with DO-330 for software-tool qualification, DO-331 for model-based development and verification, DO-332 for object-oriented technology and related techniques, and DO-333 for formal methods. Discussing these documents here does not claim that the Bayraktar TB2 uses a particular civil certification basis. Such a conclusion would require public evidence.

The broader engineering principle is an auditable evidence chain among requirements, design, code, verification results, configuration, and problem reports. That is the avionics counterpart of the traceability and verification concepts developed in Software Engineering and Software Test Engineering.

19.3. Requirements-based verification and structural coverage

Structural coverage is evidence about which portions of the implementation were exercised. It does not by itself prove that the requirements were correct, complete, or properly verified. In critical systems, criteria such as statement coverage, decision coverage, and modified condition/decision coverage (MC/DC) become meaningful according to the applicable assurance objectives and risk.

The sound objective is not simply to maximize a coverage percentage. Verification scenarios are first derived from requirements; structural coverage analysis can then expose code that was not exercised, behavior without a clear requirements basis, or places where additional tests are needed. Coverage becomes a way to find verification gaps rather than a score to optimize in isolation.

20. Relationship between sensor fusion and fault tolerance

Sensor fusion is often introduced as an accuracy problem. It can also be a reliability problem.

Consider three independent attitude sources.

Simply averaging them is not sufficient. If one source begins to diverge, the system may need to determine:

• which sensor is inconsistent,
• how long the inconsistency has persisted,
• whether the behavior is transient or persistent,
• how much confidence should remain in the resulting state estimate.

Sensor fusion therefore sits at the intersection of state estimation and health management.

A UAV must not only know its estimated state; it should also have an engineering basis for how much confidence can be placed in that estimate.

21. System integration

An avionics architecture is not the sum of individually good components.

Integration includes decisions such as:

• which function runs on which computer,
• where sensors connect,
• which path carries each data item,
• latency budgets,
• power distribution,
• redundancy,
• software partitioning,
• maintenance and built-in test,
• reconfiguration after failures.

This is why the word interface is so important in system integration.

Two subsystems may each be correct in isolation and still behave incorrectly together.

Examples include:

• different coordinate systems,
• different endianness,
• different time references,
• different units,
• different sign conventions,
• different update rates.

Any one of these can produce an integration failure.

Avionics debugging therefore does not stop inside source code. The engineer may need to trace data end to end, from cable and protocol to sensor processing and the operator display.

21.1. Partitioning and ARINC 653

Integrated Modular Avionics allows multiple functions to share common computing resources, which in turn creates a requirement to prevent faults and timing interference from spreading across applications. ARINC 653 addresses this area by defining the APEX interface between application software and the avionics operating-system environment together with a partitioning model.

Spatial partitioning aims to contain memory and resource interference between partitions. Temporal partitioning aims to allocate processor time in predictable windows so that one application cannot arbitrarily consume another application's execution budget. This note keeps the topic at architecture level; the details are covered separately in ARINC 653 Temporal and Spatial Partitioning.

ARINC 653 Part 1 Supplement 6 was published at the end of 2024. Keeping standards references current matters: a supplement number copied from an older engineering note should not be assumed to remain the current revision indefinitely.

22. COTS components and critical-system use

Commercial off-the-shelf components can reduce development time and cost. Their use is especially natural in ground systems and supporting infrastructure.

The same convenience cannot automatically be assumed for a flight-critical function.

Evaluation may need to consider:

• product lifecycle,
• documentation,
• backward compatibility,
• deterministic behavior,
• environmental robustness,
• verifiability,
• supply continuity,
• software integrity.

“Widely used in the market” is not safety evidence.

It is also insufficient to evaluate only the feature list. The exact version, compiler or toolchain, configuration, known defects, update policy, and vendor lifecycle behavior may need to remain traceable. Two releases with the same product name can have different fault characteristics. In a critical system, reproducible configuration and known component provenance matter as much as technical capability.

Unit 5: Bayraktar TB2 and My 2015 Baykar Experience

23. Reading the Bayraktar TB2 as a system

Looking at the Bayraktar TB2 only through its airframe, engine, and camera leaves much of its engineering architecture unexplained.

Baykar's current public product information describes characteristics including:

• fully automatic flight control,
• a triple-redundant autopilot system,
• fault-tolerant triple-redundant sensor fusion,
• fully automatic taxi, takeoff, cruise, and landing,
• navigation using internal sensor fusion without dependency on GNSS,
• a cross-redundant ground-control-station architecture,
• redundant servo-actuator units,
• redundant power units,
• line-of-sight and beyond-line-of-sight communication options.

Read together, these points show an integrated avionics architecture in which state estimation, automatic flight, redundancy, ground control, and communications are designed as one system rather than as an aircraft that is simply “remote controlled.”

Public Baykar documents published in different years contain differences in values such as mass, altitude, and endurance because configurations and product generations evolve. Current numerical specifications should therefore not be treated as if they described the exact 2015 aircraft configuration.

24. The stage of the TB2 program in 2015

According to Baykar's public history:

• the Bayraktar TB2 completed its first fully autonomous flight test in 2014,
• the first serial delivery occurred in 2014,
• a second serial delivery occurred in 2015,
• the Turkish National Police placed an order in 2015,
• the platform completed its first 1,000 operational flight hours in 2015,
• the first munitions firing demonstration took place in 2015.

My internship at Baykar took place in that same period.

This timing is important. Once a system has progressed beyond prototype flight into serial delivery and accumulating operational hours, the software-engineering problem changes. Laboratory correctness remains necessary, but additional concerns become much more visible:

• repeatability,
• maintainability,
• logging quality,
• debugging,
• stability under field conditions,
• operator experience,
• version control,
• compatibility among subsystems.

The embedded-networking, avionics-debugging, static-analysis, and telemetry work I encountered during the internship fits naturally into that stage of system maturation.

25. Technical meaning of my 2015 Baykar experience

My first work in Ikitelli was on embedded networking with the TMS570 and lwIP. The TMS570 family belongs to the class of safety-oriented embedded controllers, while lwIP is a lightweight TCP/IP stack widely used in resource-constrained systems.

That work taught me to think in three layers at the same time:

hardware → embedded software → network

In Kesan, the same chain could be observed at system scale:

air vehicle → avionics data → communications → ground-control software → operator

Every value visible on a telemetry screen had a sensor, processor, protocol, and timing chain behind it.

In avionics debugging, it is often insufficient to classify a problem as only a “GUI problem,” “network problem,” or “sensor problem.” The real cause may cross layers.

A value that appears frozen on screen, for example, could result from:

• a sensor no longer updating,
• embedded software no longer producing a packet,
• network loss,
• packet parsing failure,
• timeout logic,
• a user-interface update problem.

That view has remained valid in the real-time, high-traffic, and critical software systems I have worked on since: end-to-end behavior is more important than correctness of one isolated module.

The static-analysis project was another side of the same end-to-end thinking. I began by studying and documenting MISRA C rules rather than treating the coding standard as paperwork detached from implementation. I then made realization of applicable checks one of the first priorities in the software I was developing. As the tool evolved, findings from multiple analysis engines could be viewed through a common interface. The objective was to turn repeatable engineering rules into repeatable checks before the codebase grew around inconsistent habits.

26. Why ground-control software is critical

The ground control station is not itself the aircraft flight computer, but it is the principal human-machine interface between the operator and the unmanned aircraft.

Several properties therefore become safety- and mission-relevant.

26.1. One unambiguous representation of state

The same system fact should not appear with conflicting meanings in different places.

Flight mode, link state, and the health of a critical sensor need one consistent semantic definition across the interface.

26.2. Distinguishing old data from new data

After a link interruption, the last known value may remain on screen. If that value still looks “live,” the operator can form an incorrect mental model of the aircraft.

26.3. Alarm priority

If every notification is red, none of them is meaningfully red.

The system needs a distinction among informational messages, warnings, and truly critical alarms.

26.4. Command acknowledgement and completion

An operator action being:

• received,
• validated,
• executed

are not the same event.

The command interface should make those differences visible where the operational context requires it.

26.5. Recording and traceability

After a critical event, the system should make it possible to answer questions such as:

• Which data arrived and when?
• Which command was sent and when?
• What mode was the aircraft in?
• Which warning was generated?
• What was the communication state?

Telemetry recording is not only a convenience for later analysis. It is a feedback mechanism for system engineering, maintenance, verification, and fault investigation.

Unit 6: Human Factors, Autonomy, Reliable Software, and End-to-End Architecture

27. Human factors in a UAV system

The pilot is not physically inside the aircraft, but human factors do not disappear.

The operator may have to:

• work with delayed video,
• monitor many system states at once,
• understand automatic-flight modes,
• manage communication outages,
• understand what the automation is doing and why.

As automation increases, a new class of problem becomes important: automation surprise.

The system may have made a technically correct transition, yet the operator's situation awareness can still degrade if the transition and its reason are not understandable.

A good interface should not merely display state. It should make system behavior interpretable.

28. Autonomy versus remote control

In a remotely controlled vehicle, the human continuously produces low-level commands.

In an autonomous system, the human gives a higher-level objective and the vehicle produces lower-level control decisions internally.

The distinction can be summarized as:

remote control: human → control surface

autonomous flight: human → mission objective → flight management → autopilot → control surface

Bayraktar TB2 public descriptions emphasize capabilities such as automatic taxi, takeoff, cruise, route following, and landing. These are examples of the distinction between low-level continuous manual control and higher-level supervisory interaction.

Autonomy does not mean “a system without humans.”

A more precise statement is:

Autonomy raises the level of abstraction between the human and the inner control loop.

29. What makes UAV software different?

UAV software differs from ordinary desktop or web software in several fundamental ways.

It is directly coupled to the physical world

An incorrect output may affect a physical system rather than only render an incorrect screen.

Time matters

A correct answer delivered too late can be functionally wrong.

Hardware is imperfect

Sensor noise, packet loss, component drift, and power disturbances are part of the real environment.

Failure conditions are normal design cases

Loss of communication, sensor disagreement, or failover to a redundant channel should be modeled before deployment.

Observability is necessary

Without logs, telemetry, and state records, reproducing a field problem becomes much harder.

System boundaries are wide

The root cause of one visible error may lie anywhere from an embedded processor to the ground-control display.

These properties make it necessary to study UAV software together with systems engineering rather than as isolated application code.

The control side of this subject intersects directly with Automatic Control, measurement and sampling with Signals and Systems, processor and interrupt behavior with Microprocessors, scheduling and process behavior with Operating Systems, and data transport with Computer Networks. Ground-control human-machine interaction is complemented by UI/UX Engineering, while the verification chain connects naturally to Software Test Engineering.

30. Fundamental software principles for reliability

Several principles apply broadly to avionics and similar real-time critical systems.

Avoid ambiguous state

If data is invalid, “last known value” and “valid current value” should not be presented as the same state.

Avoid silent failure

Silently producing an incorrect answer can be more dangerous than explicitly reporting a failure.

Prefer deterministic behavior

Predictable timing and explicit state transitions are valuable when failure analysis and verification matter.

Limit fault propagation

A failure in one subsystem should not unnecessarily disable otherwise independent functions.

Bound resource use

Memory, CPU, queue growth, and other finite resources should have defined limits and failure behavior.

Preserve observability

The system should retain enough state and event information to explain what happened after a problem.

These principles are not unique to aviation. The same reasoning appears in critical financial systems, public-safety systems, telecommunications, and industrial control.

31. The connection between flight physics and software

One of the most instructive aspects of avionics engineering is that the boundary between software and physics becomes very thin.

A software variable named:

airspeed

is not merely a floating-point number.

Behind it may be:

• pitot/static sensing,
• calibration,
• an atmosphere model,
• filtering,
• sampling time,
• a data bus,
• flight-control gain scheduling,
• an operator display.

Likewise:

roll

is not merely an angle shown on the screen.

It can be the combined result of IMU measurements, coordinate transformation, state estimation, and control logic.

For this reason, avionics software must preserve a strong and explicit relationship between a program variable and the physical quantity it represents.

32. End-to-end data path from sensor to display

Consider one telemetry quantity:

altitude

It may originate through a path such as:

pressure sensor → ADC → air-data computation → flight computer → packetization → data link → ground station → parsing → UI

or:

GNSS → navigation solution → flight computer → data link → ground station

or:

INS + barometric data → fusion → estimated altitude → telemetry

An “altitude looks wrong” problem therefore cannot be assigned to one layer without evidence.

A good debugging process traces the value end to end:

1. Is the source measurement correct?
2. Is the conversion correct?
3. Is the packet correct?
4. Is the timestamp correct?
5. Did the data reach the destination?
6. Was it parsed correctly?
7. Is the UI presenting the correct unit and scale?

This is one of the most durable engineering methods I learned while working around avionics debugging in 2015, and I have continued to use the same end-to-end reasoning in other critical systems.

33. Reading architecture through public Bayraktar TB2 characteristics

The public characteristics of the TB2 can be mapped to the engineering concepts in this note without claiming access to non-public implementation details.

Triple-redundant autopilot

This indicates an architectural objective of avoiding dependence on one flight-control channel. The real engineering problem is not simply running three channels, but comparing them and reaching a safe decision when they disagree.

Triple-redundant sensor fusion

This connects state estimation directly to fault tolerance rather than treating sensor processing as an isolated accuracy function.

Autonomous takeoff and landing

These dynamic flight phases require several functions to operate together:

• state estimation,
• path and line tracking,
• speed and altitude control,
• actuator control.

Navigation without GNSS dependency

The public description emphasizes internal sensor fusion. Without inferring a non-public implementation, the design principle is clear: satellite navigation is not treated as the only source from which all navigation capability depends.

Cross-redundant ground-control architecture

Mission continuity is not only an air-vehicle problem. Ground-system availability is part of the overall architecture.

Redundant servo and power units

A correct command from the control computer is not enough. The command must reach a physical actuator, and the system must remain powered. Reliability has to extend through the actuation and energy chain.

Unit 7: Field Experience and Engineering Conclusions

34. Difference between theory and field engineering

Textbooks divide the system into disciplines:

• aerodynamics,
• control,
• navigation,
• communications,
• software,
• human-machine interaction.

A real failure does not respect those boundaries.

A route-tracking error, for example, can originate from:

• wind-model error,
• GNSS error,
• IMU bias,
• time-synchronization problems,
• controller gains,
• servo response,
• telemetry presentation.

That was the most important value of the 2015 Baykar internship for me. Concepts that university courses naturally separated into embedded systems, networking, C/C++, control, sensors, and user interfaces appeared in the field as parts of one end-to-end aircraft system.

35. Engineering conclusions

Several general lessons emerge from avionics and UAV systems.

Lesson one: physics is part of the software requirement

If software controls a physical system, the relevant physics belongs inside the software requirement and verification model.

Lesson two: measurement and reality are not the same thing

Every sensor value should be interpreted together with an error model, validity, and time context.

Lesson three: network failures are business logic

Link loss and latency can change system behavior. They are not merely concerns of a communications library.

Lesson four: redundancy is an architecture problem

Adding multiple copies of a component is not sufficient if comparison, isolation, independence, and recovery are not designed.

Lesson five: the interface can be a critical component

If the human sees an incorrect or ambiguous system state, correct lower-level computation may still lead to a mission-level failure.

Lesson six: logging and telemetry are not afterthoughts

A system that must operate in the field also needs to be diagnosable, reviewable, and explainable after unexpected behavior.

Lesson seven: autonomy is not merely more software

As the human moves farther from the inner control loop, responsibility shifts toward state estimation, fault handling, bounded behavior, and reliable automated control.

36. Conclusion

A UAV begins with aerodynamics, but reliable operation depends on avionics components working together.

The wing produces lift.

Sensors measure the aircraft state.

State estimation transforms those measurements into a coherent model.

Navigation determines where the aircraft is going.

The autopilot closes the control loops around the desired flight state.

Actuators convert digital commands into physical motion.

The data link carries information between air and ground.

The ground control station makes system state visible to the operator.

Redundancy and fault management attempt to prevent one defect from causing complete loss of the mission.

The Bayraktar TB2 provides a concrete public example in Türkiye through which many of these subjects can be examined together. The topic also has a personal dimension for me because I was at Baykar as an intern in 2015 during a period of serial delivery and operational maturation. The path from TMS570/lwIP embedded networking to avionics debugging in Kesan, from C/C# static analysis to ground-control telemetry, became an early foundation for the way I later approached real-time and critical systems.

One principle from that period has remained unchanged:

A critical system is not simply the sum of individually correct components.

The real engineering task is to make those components operate reliably inside the same physical reality, the same timeline, and the same fault model.

References

R. P. G. Collinson, Introduction to Avionics Systems, Third Edition, Springer, 2011.

Baykar, Bayraktar TB2 product page

Baykar, history

Baykar, public product and technical information

FAA AC 20-115D, Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( )

SAE, ARINC 653 Part 1 Supplement 6

SAE, ARINC 429 Part 1 Supplement 19

U.S. DoD ASSIST, MIL-STD-1553

MISRA C:2025 Addendum 6