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
martin.schmucker@airbus.com, +49(0) 731/392 3792
Address of author Franz-Josef-Roth-Str. 7, 91792 Ellingen ferdinand.seidel@gmail.com
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.
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.
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
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
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
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 th e 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
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-
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).
(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
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:
𝜏 = − 𝑟 𝑟̇
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).
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.
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
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
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
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.
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.
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.)
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.
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.
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
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)
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
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.
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.
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.
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)
