Flight Heritage for Risk Assessment

Télécharger le fichier original (Mémoire de fin d’études)

Integration of Drones into Airspace

Commercial advantages oﬀered by drones are already targeted by big companies worldwide. The airspace regulatory authorities seem to be caught between the com-panies (that demand rapid access to airspace), and the concerns of the public about potential privacy breaches, safety and liability issues [29, 41]. Even with today’s strictly regulated airspace, reported occurrences show that there are a number of hurdles to overcome before the further integration of UAS into the airspace.
With the Riga Conference1 in 2015, Europe has started on a path towards a unified regulatory framework design in order to allocate airspace with the growing number of drones. Its diversity, innovation and international structure is oﬀering huge potential for new jobs. EASA (European Aviation Safety Agency) has been assigned by the European Commission to develop two main aspects:
• EU Regulatory Framework for drone operations;
• proposals for the regulation of low-risk drone operations, key elements of the future Implementation Rules (IRs).
With a starting point of the Riga Declaration [73], and building on Regulation (EC) No 216/2008 (Basic Regulation) [76], the A-NPA (Advance Notice of Proposed Amendment) [36] introduces three main categories of operations and asks for public consultation. In the report, drones are grouped under two main categories; remotely piloted and autonomous. An autonomous drone is defined by the ICAO (International Civil Aviation Organization) [52] as: A drone that does not allow pilot intervention in the management of the flight. Aside from sounding like science fiction, one of the key reasons that EASA has switched to using the term ‘drone’ and categorizing as remotely piloted or autonomous — rather than using UAS or RPAS — is to ensure the fast growing development of autonomous drones.
While mentioning the eﬀorts by diﬀerent organizations to accommodate drones in airspace, we examine the present regulatory context from European and international perspectives. The ICAO is a United Nations Organization working with 191 Member States of the Chicago Convention (Convention on International Civil Aviation) and global aviation organizations. At the present time, the international circulation of drones is not allowed by Article 8 of the Chicago Convention [51]. Starting in 2003, the ICAO began a study on the Standards and Recommended Practices (SARPs) for drones, to which member states refer when developing their legally enforceable national civil aviation regulations. 2018 is the proposed year for draft SARPs with a focus on international drone operations. Until then, the work of the ICAO can be traced by studies of the UAS Study Group (set up by ICAO in 2007), which devel-oped the Circular 328 AN/190 on Unmanned Aircraft Systems [48], an amendment to Annex 2 (Rules of the Air) [49] and Annex 7 (Aircraft Nationality and Regis-tration Marks) [50]. From a European perspective, Basic Regulation (Regulation EC No.216/2008) [76] is that which holds at present. Article 2 and Annex II limit the regulation to apply only to drones with a maximum take oﬀ mass above 150 kg and/or except operations on military, customs, police, firefighting, search and rescue, and experimental work. Those that are not covered by Basic Regulation are handled by national aviation legislation, which are not yet harmonized and mostly designed with an assumption that small drones are operating locally. EASA is working on diﬀerent aspects of drone integration into the airspace. Last year, EASA published the ‘Prototype’ Commission Regulation on Unmanned Aircraft Operations [33], after public consultancy with A-NPA 2015-10 (Advance Notice of Proposed Amendment) [36], and its resulting Opinion [32] with an Explanatory Note of Opinion. Another work from EASA aims to authorize general principles for the type certification for fixed wing and helicopter drones separately, using a policy adopted by the agency in 2009 (E.Y013-01) [31].
In the proposed regulation by EASA, an operation and risk centric categorization has been followed. Open, specific, and certified are the three categories proposed, corresponding to the diﬀerent risk levels that they entail.
• Open Category encompasses low-risk operations, such as most leisure flights and some professional activities. Operations falling in this category do not require explicit authorization from civil aviation authorities. However, they are subject to strict operational limitations (e.g., no proximity to people, traﬃc, infrastructures; no dangerous items; one pilot per UAS; no item dropping). These operational limitations are suﬃcient to mitigate the low risk. Though some professional activities fit into this category, the main goal is to regulate leisure types of operation [63].
• Specific Category regroups medium-risk operations, such as operation be-yond visual line of sight (i.e., no visual contact between pilot and UAV during flight). To facilitate the regulation process, several scenarios with specific oper-ational limitations are designed. To operate within a scenario, the UAS needs to comply with a list of requirements. For operations outside the scope of those scenarios, a risk analysis must be carried out to show that the existing risks are properly mitigated. To facilitate this risk analysis process, JARUS has de-veloped a framework called the Specific Operations Risk Assessment (SORA). SORA considers threats — which contribute to the risk — and barriers — which mitigate the risk — in order to evaluate the actual risk of an operation, and decide if the resulting mitigated risk is low enough to allow the operation, as illustrated in Fig. 2-2. The risk analysis needs to be validated by the authorities in order to authorize an operation not included in the standard scenarios [63].
• Certified Category Operations with risk that cannot be mitigated in Spe-cific Category are evaluated in Certified Category. These represent high-risk operations, such as a large cargo delivery in urban area. These are likely to be operations with a risk close to current manned aviation. As such, the air-craft, avionics, pilot/crew and operator will need to be certified in order to fly these operations. The fact that a certification process is involved increases the complexity of the introduction of UAS in these types of operations. Indeed, before being able to certify a piece of equipment, a standard must be developed for this equipment. Standardization can be best understood as the process of defining details and minimum requirements for safe and uniform operations across a diverse range of implementations. However, at present, not all of the parts required to fly a UAS have the corresponding standards, e.g., Detect And Avoid (DAA) systems, C2 links, pilot training. Thus, enabling this category of operation requires extra eﬀort and time for the industry so as to agree on standards. For Certified Category, harmonization at the ICAO is planned to allow international operations [63].
Latest eﬀorts for the integration of drones into airspace have welcomed a relatively new concept, called the ‘U-Space’. This approach has been adopted for immediate plans at the European level, to accommodate drones in urban areas. While EASA continues to search for solutions for the integration of drones in a variety of presumed airspaces, Commissioner Violeta Bulc has mentioned other pillars at a high level conference2 in Warsaw. She oﬀers that in parallel to the eﬀorts of EASA, there are two other pillars that need to be tackled; UTM (UAS Traﬃc Management) and the U-Space. U-Space covers the usage of drones especially in ‘U-rban’ areas with an equal share of airspace, in which case ‘U ’ stands for ‘you’. To illustrate its availability to everyone, the services will be available through a mobile phone, as shown in Fig. 2-3. The goals are highly challenging [20]:
• “Safe: safety at low altitude levels will be just as good as that for traditional manned aviation. The concept is to develop a system similar to that of Air Traﬃc Management for manned aviation.”
• “Automated: the system will provide information for highly automated or au-tonomous drones to fly safely and avoid obstacles or collisions.”
• “Up and running by 2019: for the basic services like registration, e-identification and geo-fencing. However, further U-Space services and their corresponding standards will need to be developed in the future.”
EASA regulations already cover the airspace issued in U-Space, either under specific or certified categories (depending on the risk of the operation). Using U-Space, a faster integration is expected in urban areas. We do not appear to be far from the images of flying vehicles populating the sky, as in science fiction — but even more advanced — without drivers, and more automated.
In the US, in order to tackle the safety challenges and help the development of regulation, NASA is currently carrying out a four-year research program (up to 2019) to enable unmanned aircraft traﬃc management solutions which are structured and flexible when needed. To ensure safety, this integration needs to be achieved through airspace management and UAS reliability. In addition, preliminary airspace designs, such as that proposed by Amazon shown in Fig. 2-4, identify diﬀerent zones depending on the UAS capabilities, population density and altitude.
United Arab Emirates (UAE) has accelerated the safe integration of drones into urban airspace, by settling an agreement for UAS Traﬃc Management (UTM) with Nokia, as part of its ‘Next generation network for mission-critical and smart city services’ [71]. Aiming at tracking and managing all drones in the airspace, Nokia is oﬀering solutions for automated flight permissions, no-fly zone regulation, beyond visual line of sight (BVLOS) safety operations utilizing LTE protocols for low latency, reliable and resilient communication. For compatibility with this system, drones will be equipped with LTE dongles and access modules for telemetry data access.

Paparazzi Autopilot System

An open-source autopilot, Paparazzi [14], has been adapted to generate faulty control inputs during the flight. In this section, an introduction to Paparazzi open-source autopilot system is given. Next, we discuss the properties of open-source systems that would best serve the integration of drones into the airspace. To highlight the advantages of Paparazzi, the best practices that are oﬀered by EASA in its A-NPA [36] are referred to, and the properties of Paparazzi to achieve this are discussed.

Open-source Autopilots for UAS

With the new era of First Person View (FPV) flights [40], especially for multi-rotor UAVs, there has been an exponential increase in the hardware and software of the open-source autopilots. A brief comparison of the popular current open-source and commercial autopilots is available in Table 2.1. Usually, the trend is to make the hard-ware as inexpensive as possible for recreational consumers. This reality is damaging to the reputation of open-source autopilots as they are considered as not reliable or robust, because they are being used without experience. Indeed, there exists a diﬀer-ence in the quality of sensors used in the open-source autopilot systems compared to commercial autopilots, and this is confirmed by the price of the units. This in turn makes a diﬀerence to the flight quality of the vehicles, however, with new on-board processing power, more complex estimation algorithms and filters are being used in order to overcome this problem [9].

Introduction to Paparazzi Autopilot System

The Paparazzi Autopilot System provides a software and hardware solution for low-cost mini and micro unmanned air vehicles. A fleet of Paparazzi equipped drones can be seen in Fig. 2-5.
This began as a personal project in 2003 by Pascal Brisset and Antoine Drouin, and afterwards gained the support of ENAC in 2005. Being one of the first (if not the first) open-source autopilot system in the world, Paparazzi has attracted much atten-tion, and has led others to start new branches and systems. The software is originally packaged for Debian/Ubuntu but can be manually installed on any GNU/Linux oper-ating system, even including MacOS-X. However, it is not compatible with Windows which automatically eliminates 90 % of the possible user community, and therefore it is not as popular as other existing autopilot systems currently on the user market.
Being one of the first open-source autopilot systems in the world, Paparazzi covers all three segments: ground, airborne, and the communication link between them, as shown in Fig. 2-6. The ground software of Paparazzi is mainly written in Ocaml, with some additional parts in Python and C. Thanks to its middle-ware communication bridge called Ivy-Bus, external software can be directly connected with the publish and subscribe method to the ground segment, without needing to modify on code. Airborne software is written in C, however there is an on-going eﬀort to support C++ [9]. One of the distinguishing features of Paparazzi is to support multi-UAV flights (Figure 2-7). Several projects have been using Paparazzi Autopilot System because of this additional feature. The communication with each vehicle is established by the ground control station, however air-to-air communication between flying vehicles and the internal relay of information to the ground control station is being implemented (for a future version).
There are over 130 modules written for Paparazzi by several developers and re-searchers, including meteorology, imagery, surveillance, advance navigation, forma-tion flight, and collision avoidance, etc. A photo taken during a Paparazzi mission in a campaign for meteorological studies by MeteoFrance is provided in Fig. 2-8. Mete-oFrance is French national meteorological service, and uses drones as tools to conduct research for meteorological studies.
Paparazzi has its own complete flight plan language, where the user can define any possible trajectory using existing commands, such as circle, line, hippodrome, figure-eight, survey, etc. Additionally, any function written in C language can be called from the flight plan and executed. This opens up a lot of application possibilities, such as triggering a navigation procedure via a sensor output.
A real-time operating system based on ChibiOS has been used since 2015. The first implementation was mainly for adding a separate thread in order to make on-board logging at a high frequency. On going work is to divide all autopilot tasks into individual threads and manage everything according to priorities which will increase the safety and reliability.
There exists over 20 diﬀerent autopilot boards capable of running Paparazzi. Ad-ditionally, several mission-based custom sensor boards have been designed under the Paparazzi project, such as Meteo-Stick 3. In this thesis, flights have been realized with an Apogee4 which is shown in Fig. 2-9.
For the faulty flight data gathering necessary for this thesis, some modifications to the Paparazzi autopilot were necessary: first, injecting the real-time faults from GCS; and second, editing the controller on board so that the sent faulty input values configure the servos when changed from the GCS.
The rest of this section highlights the capacity of Paparazzi capacity to tackle issues encountered during the integration of Unmanned Aircraft System (UAS)s into the airspace. These issues have been grouped into three categories: modularity, congestion management and reliability. For each category, Paparazzi oﬀers a unique set of features to deal with these issues.

Table des matières

1 Introduction
1.1 Motivation
1.2 Contribution
1.3 Thesis Outline
2 State of theArt
2.1 Integration of Drones into Airspace
2.2 Paparazzi Autopilot System
2.2.1 Open-source Autopilots for UAS
2.2.2 Introduction to Paparazzi Autopilot System
2.2.3 Open-Source Systems in Relation to the New Regulatory Context
2.2.4 Modularity
2.2.5 Congestion Management
2.2.6 Reliability
2.2.7 Flight Heritage for Risk Assessment
2.2.8 Future Evolutions
2.3 Fault Tolerant Control Systems
2.3.1 Loss of Control in Aviation
2.3.2 FTCS Terminology
2.3.3 Conventions for a Safe Flight
2.3.4 Methods for Fault Tolerant Control Systems
2.3.5 Fault Detection and Diagnosis
2.4 Machines on the Rise
2.5 Conclusion
3 Non linear Air craft Model
3.1 Attitude motion modeling
3.1.1 Attitude representations
3.1.2 Attitude kinematics
3.1.3 Attitude dynamics
3.2 Translation modeling
3.2.1 Translational kinematics
3.2.2 Translational dynamics
3.3 Drone model
3.3.1 Modeling of aerodynamic moments
3.3.2 Modeling of aerodynamic forces
3.3.3 Shortcut to modeling
3.3.4 Sensor Models
3.3.5 Fault Models
3.4 Conclusion
4 Methodology
4.1 Machine Learning
4.1.1 Introduction
4.1.2 Terminology
4.1.3 Steps towards the learning machine
4.2 Support Vector Machines
4.2.1 Introduction
4.2.2 Application
4.3 Conclusion
5 Simulation Results
5.1 Fault detection from simulated flight data
5.2 Fault detection from real flight data
5.2.1 Injecting faults in flight from Paparazzi GCS
5.2.2 Modifications to Paparazzi autopilot controls to inject faults during flight
5.2.3 Reading and labeling flight data
5.2.4 Control surface stuck fault
5.2.5 Control surface loss of efficiency fault
5.2.6 Use of spinors as attributes
5.3 Conclusion
6 Conclusion
6.1 Future Work
A Codes for FD from simulated data
A.1 Read Me file for the aircraft simulation codes in Matlab
A.2 configDrone.m
A.3 modelDrone.m
A.4 quat_to_euler.m
A.5 rungeKutta4.m
A.6 simDrone.m
B Codes for FD from flight data
B.1 dataRead.m
B.2 selectDataToInvest.m
B.3 arrangeDataSet.m
B.4 svmFD.m
B.5 svmFDtuningViaHeuristic.m
B.6 svmFDtuningViaOptim.m
B.7 calcF1score.m
B.8 addFeaturesBefore.m