Embed Size (px)
Citation preview
Integration, implementation and validation
of a simulation environment of a UAV
Sense and Avoid System
Ferdinand Seidel
Space Engineering, master's level (120 credits)
2016
Luleå University of Technology
Department of Computer Science, Electrical and Space Engineering
Master Thesis
Spacemaster Program – Space Science and Technology
Master 2 – Space Instrumentation and Instrumentation
„Integration, implementation and validation of a simulation
environment of a UAV Sense and Avoid System
Ferdinand Seidel, B.Sc.
Examiner Prof. Peter Von Ballmoos
Handed in 01. September 2016
Institution Université Toulouse III – Paul Sabatier
Carried out at Airbus Defense and Space GmbH, 89077 Ulm
Mission Management Systems and SW
Supervisor Dr. Martin Schmucker, Software Architect
+49(0) 731/392 3792
Address of author Franz-Josef-Roth-Str. 7, 91792 Ellingen
2
Summary
The steadily increasing amount of air transportation in the field of manned and unmanned aviation ,
as well as new requirements induced by technological innovations cause more and more complex
avionic system developments. One of the most important safety requirements in aviation is the avoid-
ance of mid-air collisions. In order to minimize such dramatic events, commercial manned aircraft
are equipped with the “Traffic Alert and Collision Avoidance System (TCAS)”to support the pilots of
both endangered aircraft by traffic advisories. In the booming field of unmanned aviation, collision
avoidance needs to be autonomous, which will achieved by complex “Sense and Avoid” systems. Com-
bining information from multiple detection sensors to minimize information uncertainties and neglect
the disadvantages of each sensor as a single system is the base for an operational S&A system for
Unmanned Aerial Vehicles (UAVs). The aircraft will use existing traffic instruments such as a tran-
sponder for the reception of automatic dependent surveillance – broadcast (ADS-B) data from other
aircraft, TCAS and additional electro-optic and radar-based sensors to compensate the lack of an on-
board pilot. All this data can be used in a logical composition to provide the UAV a better situational
awareness of the airspace and to avoid an intruding aircraft in case of emergency.
To support the development of a “Sense and Avoid” system, the company Airbus Defence and Space is
developing a dedicated simulation environment. It simulates collision scenarios between aircrafts to
integrate, verify and validate the system under development. At this point the mathematical models of
the sensors need to be integrated in the simulation environment in order to increase the degree of
realism. As a contribution for further completion of the system, this master thesis is concerned with the
integration of the existing models, implementation and improvement of missing models, visualization
of this system to the PIC and the presentation to Airbus D&S’s customer.
3
Résumé
La densité, toujours croissante, du trafic aérien d’appareils avec et sans pilote, ainsi que les
nouvelles exigences liées aux innovations technologiques, entraînent le développement de
systèmes avioniques de plus en plus complexes. L’une des exigences de sécurité les plus
importantes dans l'aviation est d'éviter les collisions en vol. Afin d’éviter ces événements
tragiques, les avions de lignes sont équipés du Système d’Alerte de Trafic et d’Évitement de
Collision (TCAS : Traffic Alert and Collision Avoidance System) pour guider les pilotes de
deux avions en danger, à l’aided’avis de circulation. Dans le domaine en plein essor de l'avia-
tion sans pilote, l'évitement des collisions doit être autonome, ce qui sera le cas grâce à des
systèmes complexes de "Sense and Avoid" (« Voir et Eviter »). La base d’un système "Sense
and Avoid" opérationnel pour véhicule aérien sans pilote, est de cumuler l’information pro-
venant de différents capteurs, pour ainsi réduire l’incertitude des données, et pouvoir négli-
ger les inconvénients de chaque capteur, pris comme système isolé.. Pour compenser
l’absence d’un pilote à bord, l’appareil utilise des instruments de navigation déjà existants,
comme le transpondeur pour recevoir des données d’autres appareils via la surveillance
dépendante automatique en mode diffusion (ADS-B), le système TCAS, ou encore d’autres
capteurs électro-optiques ou qui utilisent des radars. Toutes ces données peuvent être utili-
sées pour constituer un ensemble logique, qui fournira au véhicule aérien sans pilote une
meilleure connaissance de l’état de l'espace aérien et qui sera capable, en cas d’urgence, d'évi-
ter un appareil trop proche.
Pour encourager le développement d’un système "Sense and Avoid", la société Airbus De-
fence and Space lui a dédié un environnement de simulation. Il permet de simuler des scéna-
rios de collision entre aéronefs, afin d’intégrer, de vérifier et de valider le système en cours
d'élaboration. À ce stade, les modèles mathématiques des capteurs doivent être intégrés à
l'environnement de simulation afin de mieux se rapprocher de la réalité. En tant que contri-
bution à la réalisation de ce système, cette thèse portera sur l'intégration des modèles,
l’implémentation et l'amélioration de modèles manquants, la visualisation de ce système pour
le PIC et la présentation au client d'Airbus D & S.
4
Table of Contents
1 Introduction .................................................................... 6
1.1 Subject Matter and Structure ............................................................................. 7
2 State of the Art of a UAV S&A System ....................... 8
2.1 Scope of Sense and Avoid..................................................................................... 8
2.2 Functions of a Modern S&A System ................................................................ 8
2.3 Airborne Sensor Capabilities ............................................................................11
2.4 Concept of Collision Avoidance Decisions....................................................11
2.4.1 Tau ......................................................................................................................11
2.4.2 Protected Collision Volume................................................................................12 2.4.3 Separation Volume..............................................................................................12
3 Simulation Environment of a S&A System ............... 13
3.1 Concept of Operation for the S&A Simulation ............................................14
3.2 S&A Simulation Architecture ...........................................................................15
3.2.1 S&A Simulator Blocks ........................................................................................15
3.2.2 Software Development Toolchain......................................................................18
3.3 Sensor Models.......................................................................................................19
3.3.1 Uncooperative Sensors .......................................................................................19
3.3.2 Cooperative Sensors ...........................................................................................20
4 Personal Contribution ................................................. 21
4.1 Dynamic flight model of a UAV ......................................................................22
4.2 Mathematical Navigation model .....................................................................22
4.2.1 Sensor Theory ....................................................................................................22 4.2.2 Implementation...................................................................................................24
4.3 Visualization and Human Machine Interface ...............................................24
5 Conclusions and Perspectives..................................... 27
5
Abbreviations ADS-B.............................................................................................................. Automatic Dependent Surveillance – Broadcast
ARW ....................................................................................................................................................... Angular Random Walk
DUT................................................................................................................................................................... Device under test
FOG ...................................................................................................................................................................Fibre Optic Gyro
GNSS ...................................................................................................................................Global Navigation Satellite System
HMI .................................................................................................................................................... Human Machine Interface
ICAO........................................................................................................................International Civil Aviation Organization
IMU .................................................................................................................................................. Inertial Measurement Unit
NAV ............................................................................................................................................................................ Navigation
PIC .................................................................................................................................................................. Pilot In Command
S&A .....................................................................................................................................................................Sense and Avoid
TAF..................................................................................................................................................Traffic Awareness Function
TCAS ..................................................................................................................Traffic Alert and Collision Avoidance System
TSD......................................................................................................................................................Traffic Situation Display
UAV ..................................................................................................................................................... Unmanned Aerial Vehicle
Definitions
ATC Air Traffic Control is a service provided by ground-based control-
lers to guide air traffic and avoid collisions
Health Monitoring Information about functional state of the S&A System
Intruder Aircraft that is a potential threat by Mid-air Collision to the Own-
ship
OnBoard Data or actions which are only present within the aircraft
Ownship Manned or Unmanned Aircraft that is equipped with a Sense and
Avoid System.
Squitter Unsolicited downlink transmissions messages of ADS-B
Resolution Advisory Collision avoidance recommendation issued from TCAS to the PIC
if an A/C approaches closer than the separation threshold
Traffic Advisory Collision avoidance recommendation issued from TCAS to the PIC
if an A/C approaches closer than the collision avoidance threshold
6
1 Introduction
In comparison to 2009, the yearly worldwide amount of air passengers in 2014 rose by 30%
- from about 2.5 billion to almost 3.3 billion travellers per year [1]. Analogue to the signifi-
cantly increasing amount of worldwide air passengers and cargo in the last 5 years, the
density of aircrafts in the airspace is rising. This results in a higher possibility of mid-air
collision between aircraft, especially close to high traffic areas like airports. Furthermore,
this problem is intensified by the increased sharing of airspace between manned aircraft and
UAVs. This presents a significant problem for air safety as UAVs need to be integrated in
the conventional Safety Network of general aviation for collision avoidance where:
A pre-flight flight planning is the first base to separate air traffic
The Air Traffic Control guides aircrafts through controlled airspace
The PIC is the last instance to avoid collisions if the above services didn’t take pre-
ventive measurements
Within manned aviation, the PIC is supported in his avoidance decision by Resolution Advi-
sories and Traffic Advisories from the TCAS. The drawback of this system is that it can
only solve the collision scenario for cooperative traffic because it is based on the Intruder’s
transponder. Therefore the pilot has to constantly visually scan the aircraft’s surroundings,
especially in uncontrolled airspace where gliders, light aircrafts and balloons without tran-
sponders exist.
UAVs lack this last instance of collision avoidance because the video transmission to the
ground-based RPAS pilot can have to too much delay or could totally break up and therefor
doesn’t ensure real time reaction. In order for drones to participate in regular air traffic,
“RPAS will have to be as safe as, or safer than, present manned operations” as defined by
ICAO [2]. This means they must provide an equivalent level of safety, comparable to see-
and-avoid requirements for manned aircraft. In general, the capability of the UAV must be
effective against all air traffic with or without active transponder-based collision avoidance
systems. Even manned aviation benefits from this kind of system because it detects non-
cooperative A/C and provides this additional information to the PIC.
Currently there is no such system commercially available and for this reason, the German
government has assigned the ProSA-N program to Airbus D&S in order to develop a S&A
7
system. Consequently, the topic of this document addresses the Integration, Verification and
Validation of a simulation environment to create the base for the development of the above
S&A system.
As a personal contribution to this program various different tasks were achieved, for exam-
ple the development of the Human Machine Interface which is the future interface of the
Sense and Avoid System on-board the UAV to the ground-based pilot in command. The
simplicity and clearness of this display is vital for the operation because it needs to output
very clear and precise signals to the PIC, to minimize the reaction time of the avoid com-
mand execution and prevent false interpretation of the S&A situation from the pilot side.
The goal of this interaction is to allow operation and control of the system from the pilot,
while the aircraft simultaneously feeds back information that aids the decision making pro-
cess. The general goal of the HMI design is to create a user interface which makes the oper-
ation almost self-explanatory, efficient and user-friendly to operate the Sense and Avoid
System. Once ready, the system should be integrated in the existing TCAS II display to
minimize changes in the pilot’s familiarized UAV ground-station environment.
All subtasks were integrated and tested in the existing lab environment and are now opera-
tional in of the current state of the Sense and Avoid System environment.
1.1 Subject Matter and Structure
The course of this Master Thesis is created as followed:
The complete description of the status quo with respect to essential and important aspects
provides the base for a better understanding and further development of the Sense and
Avoid System. Part of this description includes:
A general introduction and description of the S&A System concept
A description of the currently developed simulation environment for a S&A System
Short summary of the S&A sensors to detect Intruders (Radar, EO, TCAS, ADS-B)
Personal contribution during the internship
Conclusion and Perspectives
8
2 State of the Art of a UAV S&A System
Prior to commencing work on the S&A System, some major disciplinary basics need to be
illustrated. An introduction and explanation of the features and requirements of a S&A
System results in a great overview of the future total system. This thesis focuses on provid-
ing this introduction and explanation with the goal of assisting the integration and comple-
tion of a demonstrator S&A System.
2.1 Scope of Sense and Avoid
The task of a S&A function is to act in lieu of a human pilot to detect and clear occurring
hazards to ensure a safe flight. These hazards consist of any object representing a risk of
mid-air collision, e.g. aircrafts, gilders, balloons or other UAVs, as well as terrain and obsta-
cles. [5] The system must operate in case of emergency and diversionary events but also
during regular operations. As there is no human on-board the UAV, the main goal is to
prevent collisions with manned aircrafts, with persons and collateral damage on ground.
Within classic aviation, the human pilot sees and avoids hazard. This includes regular visual
scans through the windows from his point of view in order to detect other traffic. The “see
and avoid” process becomes quite limited for poor visibility and confusing background, or
during tasks that require full concentration of the pilot.
The following chapter discusses many considerations concerning the design of a system, and
presents important trade-offs that need to be made in order to develop a fully functional
S&A system
2.2 Functions of a Modern S&A System
According to the agreements of the “Sense and Avoid Workshops” where US Federal Avia-
tion Administration and Defence Agency experts participated, the S&A function needs to
supply two services:
i. A “self-separation” service, resulting in gentle and premature manoeuvre well ahead
of the severe collision avoidance manoeuvre. This is equivalent to the visual separa-
9
tion manoeuvres of an uncontrolled, manned aircraft in order to follow the regulation
of staying “clear of other traffic”. [6]
ii. The collision avoidance service is the last defence employed to protect a UAV from
an upcoming collision, which is achieved by a late and aggressive manoeuvre. Again,
this is a corresponding strategy to the resolution advice of the TCAS that is aboard
most commercial manned aircraft.
The architecture and the functionalities of these two services are reflected in Figure 1 to
provide an impression of the whole S&A strategy.
Figure 1 – Protection volumes [2]
In the frame of providing these services, the system is divided into following sub-functions
with essential features:
(1) Detect any object or hazard (e.g. traffic, terrain, weather). This is just a premature
detection to indicate that “something” is there.
(2) Track the time-wise transition of the detected object. In order to assign consecutive
detections to the same object, a verification of the track, based on determined posi-
tion and trajectory parameters is required.
(3) Evaluate whether the object’s track may be predicted with sufficient certainty and
whether that track would indicate that a S&A manoeuvre is needed. A series of
measurements may be required to narrow the uncertainty, but would be reset to
maximum if a new or changed trajectory were detected.
(4) Prioritize the tracked objects based on the results of the evaluation. This step can
consider criteria for the declaration decision that varies with the type of hazard (e.g.
type of encounter, controlled airspace).
10
(5) Declare that the flightpaths of the Ownship and the tracked object, and the available
avoidance time 𝜏, require a manoeuvre to be initiated. These parameters need to be
defined for both self-separation and collision avoidance manoeuvres.
(6) Determine the corresponding manoeuvre by means of the geometry of the encoun-
ter, performance capabilities and preferences of the Ownship and other relevant con-
straints (e.g. Intruder manoeuvre, airspace rule, terrain, other obstacles)
(7) Command Ownship to perform the selected manoeuvre. For autonomous UAS this
only requires internal communication, while for RPAs this includes telecommand da-
ta from the ground station.
(8) Execute the chosen collision avoidance manoeuvre
The above explained states are illustrated in Figure 2 to provide a temporal feeling of the
actions in order to experience all steps of a S&A manoeuvre.
Figure 2 – Timeline of sub functions
11
2.3 Airborne Sensor Capabilities
The surveillance system that detects hazards can be implemented in various forms. These
choices have extremely different capabilities, ranging from their coverage volume to the
types of measurements made and the respective accuracies, update rates and probabilities of
false detection.
Technologies available for airborne sensing of other aircraft are best divided into two
groups, termed cooperative and non-cooperative. The following table provides an overview
of the existing range of sensors with their respective determined parameters:
Sensor Technology Coordinate System
Mode A/C Transponder Relative range, absolute altitude
ADS-B Latitude, Longitude, altitude, velocity
Electro-Optic Bearing (azimuth/elevation)
Laser/LIDAR Relative range
Onboard RADAR Relative range, bearing (azimuth/elevation)
Acoustic Bearing
Table 1 – S&A sensor range
2.4 Concept of Collision Avoidance Decisions
The ability of the S&A System to distinguish between threatening and non-threatening
traffic is key to initiate an avoidance manoeuvre only if safety is not ensured anymore.
Therefore, the threat declaration sub-function must fulfil two main requirements:
To decide whether an urgent hazard embodies a threat such that a manoeuvre is re-
quired to avoid collision.
To minimize needless warnings for detected targets that are actually non-
threatening without restricting the S&A functionality.
In order to decide whether a close aircraft could become a critical hazard there are various
different parameters that help classify intruding A/C.
2.4.1 Tau
A measurement of the range between the Ownship and an Intruder is the main criteria in
order to determine Tau, the time until collision:
𝜏 = − 𝑟
�̇�
12
Assuming the same altitude and a linear collision trajectory, if this value is positive it repre-
sents the time until impact of converging aircrafts. Conversely, it becomes negative if the
collision distance increases and the aircrafts separate again. The latter would represent a
“clear of the conflict” resulting in an aural indication to the UAV operator. Based on the
velocities of both aircrafts Tau is calculated for both horizontal and vertical convergence.
2.4.2 Protected Collision Volume
Since other aircraft may make unforeseen manoeuvres in the future, some additional margin
must be provided to protect against adverse manoeuvres. As the name already explains, the
Collision Volume is an imaginary protected area surrounding the Ownship that must not be
penetrated by other aircraft. As defined by the “critical near-midair collision” [7], the usual
collision volume is in the shape of a truncated cylinder of 200 ft in height and 500 ft in radi-
us, with the Ownship in its centre.
Because it is impossible to predict the dynamic conditions of flight, this fixed volume is a
dummy for the possible positions of an intruding A/C. Furthermore the resolution manoeu-
vre needs to take the various delays into account. These are composed of deciding, com-
municating and executing the desired manoeuvre, the performance of the airframe in accel-
erating vertically, laterally or changing velocity, the maximum climb and descent rates or
the bank angle. Considering these and more proximate hazards such as other traffic or ter-
rain, the best avoidance manoeuvre needs to be determined.
2.4.3 Separation Volume
In order to avoid dangerous states that require aggressive manoeuvres, the evaluation of
targets and a self-separation manoeuvre is initiated long before the collision avoidance.
Therefore a separation volume similar to the collision volume is defined around the a/c, but
with a notable bigger volume. Dimensions are usually orientated towards the TCAS specifi-
cation, which states a radius of 20 nautical miles and a height of ±1000 feet. [8]
The threat declare function (see 2.2.) must anticipate upcoming collision hazards and deter-
mine when a manoeuvre is required in order to stay clear from danger. The principal meth-
ods of the self-separation are almost analogue to those of collision avoidance.
A system trade-off between S&A surveillance capability and the self-separation manoeuvre
involves the sensor system accuracy described above, whether the S&A surveillance range is
sufficient to initiate track on the worst-case threat geometry, the magnitude of the self-
separation manoeuvre itself, and both the communications latency and human latency (when
decisions are not made entirely on-board the UAS).
13
3 Simulation Environment of a S&A System
Airbus Defence and Space’s TDEES14 department is currently working on the development
of a S&A System and its respective Health Monitoring. Many events in the operation of a
sense and avoid system are stochastic in nature. Therefore in the process of developing an
innovative and complex system, a simulation environment is created first, in order to test
and validate the behaviour of the developed system at low cost.
Following this idea, the department designed a simulation lab, consisting of all technical
features in order to test and validate the system. A great advantage of this investment is the
ability to provide a visual presentation of the project progress to the customer. Furthermore,
UAV pilots get to preview their future operating system and interface and in turn contribute
with early feedback within the development process.
The practical procedure to realize a project such as this is to use systems engineering ap-
proaches and model-based software and system development methods. Therefore a concept
of operation, a simulation architecture and system requirements are defined and put into
plan during different stages of the development process.
14
3.1 Concept of Operation for the S&A Simulation
The S&A Simulation shall be used in each stage of the development progress of a S&A sys-
tem. Each stage requires a dedicated concept of operation and is characterized by an individ-
ual goal and specific tools.
Figure 3 – Sense and Avoid Use Cases
To get a better understanding of the benefits from this system, the different top level use
cases for the simulation as seen in Figure 3 are elaborated below:
(1) Simulation for Algorithm Design and Verification: During the development of
algorithms and high-level concepts, the simulation helps to understand and test new
S&A approaches. It is used to make feasibility studies to understand the algorithms
15
and subsystems that are composed into the complete system in a later stage of the
development process.
(2) Simulation for Model Based System Engineering: The classical MBSE is a meth-
odology that focuses on creating models for information exchange between engi-
neers. The S&A simulation supports this model based software engineering process
and has the functionality to generate classical system engineering documents.
(3) Simulation for Safety Analysis: The system safety analysis process is based on
TCAS. In order to provide a good statistical basis for the system safety analysis, the
simulator provides the capability to run scenarios and models of the SAA system
faster than real-time. Flight-testing is used to evaluate the models for sensor perfor-
mance and pilot interactions and other modelled aspects.
(4) Simulation for Demonstration Purposes: The possibility to demonstrate interme-
diate development results and the demonstration of the final system to the project
stakeholders is very valuable feature of the simulation. Several visualizations are
available: for example an external view on the encounter scenario for manned and
unmanned host A/C.
(5) Simulation for Training Purposes: Simulation is widespread for training purposes
on complex and expensive systems. The S&A simulation provides basic capabilities
to train test flight crews and flight test engineers.
3.2 S&A Simulation Architecture
The following section describes the realization of section 3.1, where the simulation is divided
in four different environments with each stage reusing components of the previous ones (see
Figure 4).
3.2.1 S&A Simulator Blocks
Figure 4 – Simulation Architecture
16
In order to fulfil the previously described use cases, a high-level system architecture of the
S&A simulation was acquired. However this cannot be achieved with a single simulation
because definitions at early phases of the system development do not allow the development
of a complete simulation. Therefore the simulation shall be performed in four different envi-
ronments. The design of these environments shall allow the reuse of components.
To fulfil the needs of the different use cases the following simulations shall be developed:
3.2.1.1 S1 Desktop Simulation
The S1 Desktop simulation shall support the developer in the process to come from an idea
to a working algorithm or concept. Therefore one main task of this simulation is the formu-
lation of algorithms and S&A subsystems. For test and verification of these algorithms a
large number of scenarios have to be applied to analyse the behaviour and performance. The
implemented interfaces in this stage do not reflect the implementation of the complete sys-
tem but support the fluent development process.
For the generation of trajectories a scenario generation tool is developed. It calculates the
trajectories based on the guidelines stated in the European Encounter Model or any other
Air Traffic Model that is applicable for the certification of a Sense and Avoid System
3.2.1.2 S1 MBSE
To support different variants of the S&A system, the S1 MBSE simulation consists of an
executable model of the complete S&A system combined with a synthetic environment for
scenarios and models of the sensors and the platform. There shall be a model for each of the
sensors that will be used in the system under development. These sensor models get their
information about Intruder and Ownship states from a scenario engine that is compatible to
run the same scenarios that were already defined in the S1 Desktop simulation. The S1
model is designed in a way that supports the code generation for S&A subsystems e.g. "Data
fusion" or "Avoid" (see Figure 5).
It is important that the model is always consistent with the actual system design or design
variant because the interfaces that are defined in this model shall have the logical contents of
the real system.
3.2.1.3 S2 Lab
The Lab shall provide a general environment to test S&A Systems. The S2 Lab Simulation
17
consists of a part that allows code execution in a synthetic environment for the operation of
a S&A System and Models of Sensors and a Model of the S&A System itself. For demonstra-
tion purposes, the platform and intruders are simulated in a graphical flight simulation.
The lab shall support a step-by-step replacement of models with real hardware in order to
get a Hardware In The Loop simulation. With this simulation it can be shown that the
software that was generated from the MBSE model can run without errors on the target
hardware.
The building block design with data connections of the lab structure (see Figure 5) is tai-
lored to support the replacement of single components with rear sensors. Every block runs
on a different platform in the lab to ensure the modularity of the whole system.
Figure 5 – Structure and UDP traffic for S&A LAB
3.2.1.4 S3 Test Bench
The test bench consists of a hardware setup of the core S&A System and a number of real
sensors corresponding to the S&A Architecture. It shall support the hardware integration
and V&V tasks of the complete system. The test bench shall provide means to simulate the
real sensors like radar or ADS-B signals.
The main purpose of this simulation is the verification that multiple system components
work simultaneously on the real hardware.
18
3.2.2 Software Development Toolchain
In this section, the selected toolchain in order to accomplish the requirements is described.
The design of the toolchain is very special because the simulation shall support the S&A
soft- and hardware in each stage of the development process. The software development
tools are a very critical part and therefore the workflow is highly dependent on the correct
choice of tools. The choices during the different stages of the development process of this
project are arranged in Figure 6.
Figure 6 – S&A Development Toolchain
As can be seen, the tool chain is primary based in Mathworks products that have proven
their feasibility in multiple previous projects and are therefore a good choice for algorithm
design and code generation.
In the first step (S1 Desktop), Matlab code is used for algorithm formulation because it
provides a convenient and widespread programming language to define complex functions.
For dynamic systems like the sensor models, Simulink is used because it is very clear and
well suited for documentation.
In the next step (S1 MBSE), the Matlab code together with the Simulink models are then
integrated in one complete executable Simulink model of the S&A system.
For the S2 Lab, the Mathworks Embedded Coder is used to generate C/C++ code from the
MBSE model. This code shall then be compiled with QT/MinGW to generate an executable
for the use within the lab environment.
The same code shall also be used to produce A653 operating system executables with the
Windriver VxWorks Workbench. A653 is the operating system running on the actual
hardware that will be installed on the A/C. Therefore the code that is running in the simula-
tion lab is the same code that will be running on the main computer of the S&A system
equipped Ownship.
19
3.3 Sensor Models
Figure 7 – Sensor Models
3.3.1 Uncooperative Sensors
A so-called uncooperative Sensor does not communicate with an intruding aircraft and has
the ability to detect uncooperative aircrafts or hazards. It operates independently from ex-
ternal inputs and resolves position information about an intruding A/C. This is very im-
portant in order to detect hazards early enough and to overcome the disadvantages of the
absence of a pilot on-board the UAS.
3.3.1.1 Electro-Optic Sensor Model
The EO Sensor Model replaces an EO Sensor during the development process. It shall be
performant enough to track Intruders for S&A purposes.
The model input interface shall get information about:
Host State (Position, Altitude, …)
State of the Intruders (Position, Altitude, A/C Type, etc.)
Atmospheric Conditions
Environmental Conditions (Temperature, Humidity, Pressure, etc.)
20
3.3.1.2 Radar Model
The mathematical Radar Model shall model the output of a radar system for S&A purposes.
The model is influenced by following environmental and intruder state inputs:
Intruder range, azimuth, elevation.
Intruder Radar Cross-Section.
Intruder closure rate.
Atmospheric conditions.
Clutter.
The generated output of the Radar Model shall give information about:
Detection plots.
Tracks with associated plots.
Range, azimuth, and elevation rates.
Estimated accuracies of the above parameters.
The advantages of a radar sensor are:
Velocity and range information of the target.
High range.
Not influenced by weather conditions.
Can penetrate some materials (plastics, composites, etc.).
3.3.2 Cooperative Sensors
3.3.2.1 TCAS Model
The Traffic Alert and Collision Avoidance System is an aircraft collision avoidance system,
designed to minimize the mid-air collisions between aircraft. Therefor it observes the air-
space around the host aircraft for other aircraft equipped with a corresponding active tran-
sponder. It operates independent from ATC and warns the pilot of the presence of other
aircraft, which present the hazard of a mid-air collision.
The TCAS Model of the S&A system shall model a real TCAS installed in both the Ownship
and in each Intruder with its appropriate Mode C and Mode S transponder. The model shall
generate the respective SAs and RAs based on the DO-185B [9] standard, which are caused
by the Intruders, and report the results via an ARINC735 specified interface. Additionally,
TCAS air interface shall be influence by wave propagation conditions on statistical models.
21
3.3.2.2 ADS-B Model
The ADS-B Model shall model the ADS-B out function on all Intruders within the range of
a real ADS-B (approximately 180 NM) [10]. Additionally, it shall provide the ADS-B inter-
face and ADS-B receiver on the host A/C.
The model will receive following input data:
States of all Intruders.
State of Ownship.
Air interface relevant information about environment.
3.3.2.3 Mil/Civil Interrogator and Transponder Model
This device is part of every cooperative A/C and represents one of the most direct surveil-
lance methods. It emits an identifying signal in response to an interrogating signal received
by a nearby A/C or ATC. Depending on the type of interrogation, the transponder sends
back a transponder code (or "squawk code", Mode A) or altitude information (Mode C) to
help air traffic controllers to identify the aircraft and to maintain separation between air-
craft. Furthermore this information is used by the collision avoidance system in order to
detect and identify proximate aircraft and to provide all the necessary parameters visually
for the operator of the host A/C.
The Military and Civil Interrogator and Transponder Model shall cover the functionalities
of a real system. The model should output the requests and replies from all intruders in the
range of the Ownship. This data is used for the TCAS model described in section 4.3.2.1.
4 Personal Contribution
Within my internship in the TDEES14 department of Airbus D&S Ulm, I had various dif-
ferent and interesting tasks and great opportunities to contribute to the current work. The
three main tasks will be presented in this section.
22
4.1 Dynamic flight model of a UAV
Within the ProSA-N program, the task is to develop a S&A System for a UAV. Unfortu-
nately there is no platform yet defined where the system will be installed. In order to get a
realistic impression of the future operation and the according interfaces between the S&A
system and the A/C, a physical and visual model of a UAV was created. The performance
and appearance are based on the latest design of Airbus D&S’s (ex Cassidian) Talarion pro-
ject [7].
The model of the UAV was designed with the tool Planemaker, which is bundled with X-
Plane and provides a complete mathematical model of the A/C. It predicts how the plane
would fly in real conditions from the entered physical parameters (e.g. weight, wingspan,
control deflections, engine power, airfoil sections, etc.) [8].
One major constraint was the stabilization of A/C by its autopilot controller during the
development process, however the model was successfully verified and validated in X-Plane
and is now the Ownship platform for the S&A simulator.
4.2 Mathematical Navigation model
As described in Section 3.2.1.3, the simulation lab consists of multiple models that simulate
the sensors of the S&A system. The NAV model replaces the navigation device of an A/C, in
this case it simulates the output of an Inertial Measurement and Navigation System of the
type iVRU-FSSG-01-NG from the company iMAR Navigation & Control. The output pa-
rameters for both the actual device and its model are position, velocity, attitude and heading
values at a frequency from one to 1000 Hertz. This IMU consist of three high grade fiber
optic gyros, three servo-accelerometers, a powerful GNSS engine and an advanced
strapdown algorithm with data fusion [8].
4.2.1 Sensor Theory
In order to get a deeper understanding of an Inertial Measurement and Navigation device,
the key parameters that reflect the performance are described below:
4.2.1.1 Bias
Value of DUT from datasheet: 0.2 deg/hr
The bias of a rate gyro is the average output when the device is in rest position. With the
output of a gyro being integrated to find the orientation angle, constant bias errors grow
linearly with time. The constant bias error of a gyro is the average of the output over a long
23
period of time while the device is not rotating. The known bias from the data sheet can be
subtracted from subsequent measurements in order to eliminate this form of error.
4.2.1.2 Bias Stability
Value of DUT from datasheet: 0.02 deg/hr
The bias stability indicates how stable the bias of a gyro is over a certain specified period of
time. The value given in gyro datasheets is typically given in units of deg/hr or deg/s for
low-end gyros.
While the IMU is powered on, the initial bias will wander over time due to temperature
fluctuations, time and/or mechanical stress on the system. In the case of light based gyro-
scopes like Fibre Optic Gyros (FOG) the optical length increases or decreases with the
change in the physical properties of the IMU.
An INS filter constantly estimates the bias by making use of external sources of information
(GNSS, DMI, barometer). The estimated bias value is removed from the IMU measurements
before using them in the mechanization [10].
The bias stability reflects the quality of a gyro. As a consequence, the lower the bias stabil-
ity, the lower the errors will be when integrating the gyro output over time. Therefor a gyro
with lower bias stability will lead to lower errors in position estimates for the IMU.
4.2.1.3 Angular Random Walk
Value of DUT from datasheet: 0.01 deg/sqrt(t)
Gyros will exhibit very high frequency white noise that is caused by thermo-mechanical
events. This random noise is always present in the gyro output signal and has an average
magnitude equal to sigma and with a long-term average equal to zero. Mathematically this
is stated as a zero mean process with a standard deviation equal to sigma.
When a white noise error is integrated over time, its effect on the integrated result is equal
to:
𝜎𝜃(𝑡) = 𝜎 ∙ √𝛿𝑡 ∙ 𝑡
If we want to look at how this white noise will affect measurements over a certain period of
time then we typically look this value measured at 1 second.
𝐴𝑅𝑊 = 𝜎𝜃(1)
24
This parameter is called the "Angle Random Walk". It is evaluated per unit time so that we
can multiply this value by a given time (t) to get the equivalent one sigma orientation error
caused by the gyro white noise.
𝐸𝑟𝑟𝑜𝑟𝑊ℎ𝑖𝑡𝑒 𝑁𝑜𝑖𝑠𝑒 = 𝐴𝑅𝑊 ∙ √𝑡
For the example of modelling the rotation error caused by the white noise over a period of
100s, the value of ARW of 0.01 deg/sqrt(t) from the datasheet needs to be multiplied by the
square root of the time:
𝐸𝑟𝑟𝑜𝑟𝑊ℎ𝑖𝑡𝑒 𝑁𝑜𝑖𝑠𝑒 = 𝐴𝑅𝑊 ∙ √𝑡 = 0.01 𝑑𝑒𝑔
√𝑠𝑒𝑐 ∙ √100 𝑠𝑒𝑐 = 0.1 𝑑𝑒𝑔
Therefore it can be seen that in order to find the error in orientation due to gyro white noise
one needs to simply multiply the ARW by the square root of the integration time (t).
4.2.2 Implementation
The navigation output data from the Ownship is created by the X-Plane software and sent
via UDP to the mathematical model, which is running on a different system to model an
actual sensor (see Figure 5). Because the data from X-Plane is too perfect, as it is simulated
data, it is necessary to add the error that a real IMU would possess in order to increase the
grade of realism. The implementation of the mathematical model of the IMU/IMS in order
to add the specific error of the real hardware was performed in C++ code in the QT Creator
development environment. The errors in both translation and rotation were based on the
values from the datasheet of the iVRU-FSSG-01-NG [9].
For the aspect of visualization, various instruments comparable to those in a real A/C were
designed to allow the working engineers a quick impression of the aircraft’s flight condition
and verify the correctness of the navigation output data of the sensor model.
4.3 Visualization and Human Machine Interface
One very important part of the simulation is the definition of the Human Machine Interface.
In the industrial design field of human–machine interaction, this is the space where interac-
tions between humans and machines occur.
In this project it is implemented as the so-called Traffic Awareness Function, which pro-
vides the TSD to the PIC. This is a compiled picture of the traffic situation around the A/C
25
based on the provided sensor information. It is based on the well-known TCAS display for
cooperative Intruders but is extended by a custom symbolism for the uncooperative hazards.
The TAF comprises multiple sub-functions:
Traffic Situation Picture Compilation
o External Systems Management
o Traffic Situation Picture Processing
Tracks Estimation
Data Association
Data Fusion
o Traffic Situation Picture Management
o Traffic Alerts Management
Alerts Computation
Alerts Blending
Traffic Situation Picture Display
Figure 8 – TSD HMI symbolism Overview
Figure 8 shows an overview of the used symbols within the HMI. There are special symbols
for every state of the S&A system. As soon as an intruding A/C enters one of the above
states, it will be represented on the HMI by the state’s respective symbol.
These symbols, and also the whole Collision Avoidance logic, are divided into two groups:
Cooperative and non-cooperative Intruders. For cooperative Intruders the S&A system will
follow the TCAS logic and use the corresponding symbols defined by TCAS standards (see
Remarks Tab of Figure 8).
For non-cooperative Intruders, a new collision avoidance approach containing new functions
and the symbols from Figure 8 were defined. To gain a full understanding, the result is
visualized in Figure 9 and further described below.
26
Figure 9 - – S&A System Approach
Traffic: This symbol reflects a detected A/C within the range of the sensors that
does not pose a danger to the Ownship. The arrow shaped symbol reflects the true
heading of the detected A/C relative to the Ownship.
Preventive Separation Awareness Alert: This provides situational awareness in-
formation to help the PIC’s analysis of the current Traffic Situation Picture by early
identification of traffic that could violate the separation minima before any caution or
warning alert is issued. A visual advisory alert for the PIC will be issued when traf-
fic violates the Preventive Separation Awareness Alert Threshold.
Separation Awareness Alert: This function identifies the traffic that penetrates the
separation minima resulting in the loss of the well-clear separation condition of the
Ownship. The early warning about the loss of the well-clear separation condition al-
lows the PIC to manually perform an authorized manoeuvre in a very smooth and
gentle way. When an advisory alert is issued, a visual warning and an aural warning
alert the PIC.
Collision Avoidance Alert: If the separation fails, the Collision Avoidance Function
must prevent an intruder from violating the Collision Volume that indicates an im-
minent mid-air collision. This situation requires an immediate corrective action that
could be conducted either manually by the PIC or autonomously by the RPAS. The
alert will issue a visual warning, an aural warning and propose or execute a manoeu-
vre to prevent a mid-air collision.
27
For cooperative Intruders the TCAS collision avoidance approach and symbols are used.
This is an existing standard and exceeds the frame of this thesis but is described briefly in
the TCAS Intro Booklet [5]
Figure 10 – Timeline of implemented HMI states
5 Conclusions and Perspectives
During my internship the third milestone of the ProSA-n programme was successfully
accomplished and presented to the customer owing to the great effort and quality of work of
the TDEES14 department, which I was part of. The positive feedback of the customer shows
that this simulation environment is the perfect base for a great future opportunity to develop
a functional Sense and Avoid system and that it is already in an advanced and promising
state.
The necessity of a S&A system for UAVs was proven once again when the “Northrop
Grumman RQ-4” known as the “Eurohawk” was not awarded a civil aviation certification in
Germany due to its lack of anti-collision system required to protect other aircraft [13].
I implemented these symbols in an HMI
using QT creator and the C++ pro-
gramming language. The result can be
seen in Figure 10 where the above sym-
bols find themselves in a dynamic polar
plot modelling the Ownship’s surround-
ing. While the number next to the sym-
bol stands for the relative altitude in feet,
the circles reflect the range in nautical
miles of the Ownship and the Intruder to
give the PIC a complete impression of the
current collision scenario. The polar plot
rotates linearly with the Ownship’s head-
ing in order to maintain the relative
position of the detections.
28
The functional and certified S&A system that is currently under development will provide
the necessary capabilities to finally allow the integration of RPAs in German airspace and
closes the last missing step for the civil certification of UAVs.
My personal contribution to the simulation environment of the S&A system is fully in te-
grated, verified and validated in the existing lab environment and is fully operational.
As previously mentioned, the S&A system is still under current development, however once
the simulation environment is functional, the next step could be to build a RPAS ground
station in order to have the feasibility to train pilots for the operation of the new S&A sys-
tem. Therefore a ground station simulator with all the necessary components to fulfil the
training for a complete S&A reaction would require development.
Mandatory components of this ground station simulator would be:
A simulated communication with ATC because a RPAS pilot must ask for permission
if they want to leave their predefined flight path for separation manoeuvres.
An almost complete control interface of a UAV in order to pilot the Ownship and the
newly developed S&A HMI in order to be able to train the new S&A system proce-
dures and follow the recommended collision avoidance manoeuvres.
A simulation of the data link between the PIC and the UAV to train the pilot to take
the temporal delay into account or a simulation of complete link loss to show the sys-
tem’s autonomous performance.
A. List of Figures
Figure 1 – Protection volumes [2]............................................................................................9
Figure 2 – Timeline of sub functions .......................................................................................10
Figure 3 – Sense and Avoid Use Cases ....................................................................................14
Figure 4 – Simulation Architecture .........................................................................................15
Figure 5 – Structure and UDP traffic for S&A LAB ...............................................................17
Figure 6 – S&A Development Toolchain.................................................................................18
Figure 7 – Sensor Models ........................................................................................................19
Figure 8 – TSD HMI symbolism Overview ............................................................................25
Figure 9 - – S&A System Approch...........................................................................................26
Figure 10 – Timeline of implemented HMI states ..................................................................27
B. Bibliography
[1] “Luftverkehrsbericht 2014 - Daten und Kommentierungen des weltweiten
Flugverkehrs,” Deutsches Zentrum für Luft- und Raumfahrt, November 2015.
[Online]. Available:
http://www.dlr.de/fw/Portaldata/42/Resources/dokumente/aktuelles/Luftverkehrs
bericht_2014.pdf.
[2] ICAO, Manual on Remotely Piloted Aircraft Systems (RPAS), Secretary General of
International Civil Aviation Organization, 2015.
[3] P. Angelov, Sense and Avoid in UAS, John Wiley & Sons, 2012.
[4] Eisenschmidt, “Deutsche Flugsicherung,” 11 December 2014. [Online]. Available:
http://www.dfs.de/dfs_homepage/de/Flugsicherung/Luftraum/Luftraumstruktur_1
1122014.pdf. [Accessed 09 June 2016].
[5] O. o. t. S. o. Defense, “Unmanned aerial vehicles roadmap: 2000-2025,” 2001.
[6] U. F. A. Administration, “Introduction to TCAS II Version 7.1,” 2011.
[7] Federal Aviation Administration, “Introduction to TCAS II,” U.S. Department of
Transportation, no. 7.1, 28 Februar 2011.
[8] “ADS-B Technologies,” PC Avionics, [Online]. Available: http://www.ads-
b.com/faq-12.htm. [Accessed 18 Juni 2016].
[9] “Airforce Technology,” 20 Februar 2012. [Online]. Available: http://www.airforce-
technology.com/projects/talarionuav/. [Accessed 4 Juli 2016].
[10] “X-Plane,” 19 July 2016. [Online]. Available: http://developer.x-
plane.com/manuals/planemaker/index.html#introductiontoplanemaker. [Accessed 20
July 2016].
[11] iMAR Navigation GmbH, “iVRU-FSSG-01-NG Datasheet,” 06/2014.
[12] NovAtel, “IMU Errors and Their Effects,” February 21, 2014.
[13] “Atlantic Council,” 14 May 2013. [Online]. Available:
http://www.atlanticcouncil.org/blogs/natosource/germany-cancels-euro-hawk-
drone-program. [Accessed 20 July 2016].
[14] EASA, “Ihre Sicherheit ist unser Anliegen,” Köln.
C. Used Software Versions
Matlab / Simulink
MathWorks, Inc.
Version: R2015b (8.6.0.267246)
64-bit (win64)
August 20, 2015
Qt Creator
Qt Company
Program Version: 5.8 (64 Bit)
TortoiseSVN
Authors: Stefan Küng, Lübbe Onken
Version: 1.8.11, Build 26392
64-bit (win64)
X-Plane/Planemaker
Laminar Research
Original Author: Austin Meyer
Program Version: 10.35 (64 Bit)
