aerospace news

Valentin Brossard, Amin Elmrabti Sogilis

Abstract : For a few years now, the number of drones has been increasing sharply and the response of regulation authorities is to add flight constraints. To use all the advantages of this technology, drones must be safer. The problem we are addressing in this paper is the lack of methods that lead to correct and reliable embedded software in UAVs (Unmanned Aerial Vehicles). Standard have been set for avionic systems for decades. Now, DO178C is the rule and has proved its value. In this paper, we propose means to develop correct and reliable embedded software for drones, taking into account the differences between the drone ecosystem and the avionics one. We propose a mix of automated verifications and DO178C adaptation depending on the drone criticality.
1. CONTEXT AND MOTIVATION
The market of UAVs has been increasing fast and has great development perspectives in domains like security, health and delivery. A market study provided by Teal Group [1] in 2013 estimates that UAV spending will more than double in the next decade.
Civil applications like entertainment, sport, supervision and others have become a topic of public debate as they create safety issues [2]. For now, regulations are all about flight constraints (weight restriction, altitudes and navigation area constraints, etc.) but they will evolve to a mix of flight constraints and safety of both hardware and software components. In fact, the European Commission, and in particular the European RPAS Steering Group, proposed in June 2013 a roadmap detailing how to evolve UAV?regulations [3]. To follow that way, EASA published, in july 2015, the ANPA201510 [4]. This document proposes a categorisation of drones from toys to military, passing through drones with specific uses likes flying over cities or crowds. These three categories will have to comply with different regulation constraints.
The need for safer drones is clear and involves both hardware and software.or heading.

Software components are present in several places inside a UAV, including the autopilot. It is a hardware/software system used to handle the trajectory of the vehicle using sensors like GPS, accelerometer and gyrometer. These sensors have software drivers. But there are also others components containing software like cameras, gimbals or delivery modules. An example of software interaction in an UAV is shown in Figure 1.
For now, no standard explains what is correct and reliable software for drones, and how to produce it. If we look at the avionic domain, some solutions have been found and have proved their effectiveness.
Thanks to DO178C [5], there has never been a life loss due to a software failure in any commercial flight.
However, the drone ecosystem is not familiar with avionic methods. We need to find simpler ways to develop software to have safe drones otherwise drone manufacturers will not be able to adapt.
This paper presents how to meet the need for safer UAV autopilots without putting too many constraints on drone manufacturers. We present methods and tools that could be used to check the presence and the behaviour of mandatory features but also architectural choices that could lead to lower certification costs and maintain software development liberty for drone manufacturers.
The paper is organized as follows. Section 2 reviews some related work on existing cost focused and safety focused autopilots. Cost focused autopilots are providing a great solution for hobbyists but do not provide enough safety to be used in more critical cases. Safety focused autopilot might be safe, but they cannot prove it to regulation authorities. Section 3 introduces tools and methods aiming at bringing safety at an accessible cost. We propose a test bench that could automatically verify the presence and the behaviour of mandatory features and architectural choices that could bring safety and regulation compliance to drones at a lower cost. Section 4 gives more information on how we are implementing our proposals and to finish, section 5 concludes the paper and gives perspectives on how these proposals could be an answer to drone regulations.
2. RELATED WORK
There are several kinds of autopilots, with different focuses, providing generally the same features.
In the following, we consider two categories : a cost focused one, aiming at providing a free solution for hobbyist, and a safety focused one, using different types of tools, to provide a bug free solution.
2.1. COST FOCUSED AUTOPILOTS
Most autopilots used today in drones have been developed by modelmakers. They are mostly open source autopilots. In this category, we can find for example ArduPilot [6], Paparazzi [7] or EZINAV [8].
The most famous and used autopilot in this category is ArduPilot. The development of this autopilot started in 2007. It is an open source autopilot developed by the DIY drones community. The goal of this autopilot is to provide a free alternative to expensive and proprietary ones. Now, it supports almost any kind of vehicles, from quadcopter to rover and has around 170 contributors. It is the leading autopilot for hobbyists.
This autopilot has a lot of features and can be parameterized. But, when it comes to riskier uses, we find that this autopilot has neither requirement nor test. At the beginning of the Hexo+[9] development, we started to use this autopilot but faced several bugs that lead our drone to crash. In order to increase the reliability and the flight safety of ArduPilot, we have added several tests and proposed them to the community. They seem not to be ready to add them because they rejected our proposal as “maintaining the test suites would be quite a bit of additional work” [10].
This autopilot is well suited for hobbyists, because it proposes a lot of features and is free. It is not a problem to use it in large open areas, but it has not been developed using safety approaches and technologies and therefore is not designed to achieve a high security level or to obtain safety certifications.
That is why it cannot be used for the kind of uses we are aiming at.
2.2. SAFETY FOCUSED AUTOPILOTS
Some other autopilots have more concerns on safety. In this category, there is specially TauLabs [11] and SMACCMPilot [12].
The one with the greatest focus on safety is SMACCMPilot, it is a project led by Galois, Inc [13].
This project is developed under DARPA’s HACMS [14] program and its philosophy is to develop languages and tools to “improve programmer productivity but also to ensure correctness properties by construction”.
In particular, they developed Ivory [15] and Tower [16], two embedded domain specific languages. The first, Ivory, aims at safer system programming, it gives strong guarantees of type and memory safety. Ivory is compiled into C code containing no risky patterns. Tower is for composing Ivory programs into realtime systems. It allows to specify communication channels and tasks for Ivory. Once the code is generated from Ivory, they use several static analysis tools like cppcheck [17] or Coverty [18] to find bugs that have not been detected by compilers.
Beside development tools, portion of the autopilot is tested using an implementation of the QuickCheck [19] harness for Ivory. It allows to easily test functions with hundreds of random values. Galois Inc’s engineers also have built a runtime verification framework that automatically instruments C code to capture global state values whenever a variable changes.
So the focus on quality is clear and they may have good results, but they choose to develop this autopilot without linking it to regulation issues. So it is very likely that this autopilot will require some additional work to make it compliant with future regulations.
We are not aiming at providing an other autopilot for hobbyists, we want to produce a correct and reliable autopilot and prove its correctness to regulation authorities. We focus on how regulation compliant software for drones could be built at a lower cost than for avionic systems, a topic that has never been discussed to our knowledge.
3. DEVELOPMENT METHODS : AUTOMATED TESTS AND ARCHITECTURAL CHOICES
The need to have guidelines to build correct and reliable embedded software for drones is clear, but it does not make any sense to do that without taking into account the whole system. We will first have look at the existing methods for avionic systems then we will discuss on how they can be applied for drones.
3.1 AVIONIC AND UAV REGULATORY CONTEXT
For civil avionic systems, ARP4761 [20] (Guidelines And Methods For Conducting The Safety Assessment Process On Civil Airborne Systems And Equipment) describes how to perform the system analysis. This document goes through several methods like Functional Hazard Assessment (FHA), Preliminary System Safety Assessment (PSSA), System Safety Assessment (SSA) or Fault Tree Analysis (FTA). All these methods aim at dividing the whole system into functions and to identify the criticality of failure of each function. Once this is done, a DAL (Development Assurance Level) is set for every functions, depending on the criticality and probability of failure, from E (no impact on safety, aircraft operation or crew workload) to A (Failure may cause multiple fatalities usually with loss of the airplane).
Regarding software, DO178C proposes ways to comply with these levels of criticality. For DAL E to A, it describes what must be done in order to mitigate the risk. By fulfilling DO178C, you can say that the software you developed “performs its intended function with a level of confidence in safety that complies with airworthiness requirement”. To reach that, several objectives have to be met concerning planning, development, verification, configuration management etc. At several steps in the development, regulation authorities check that everything is performed as planned and act, at the end, that the software is compliant to DO178C and can fly.
Concerning drones, the EASA has provided a document, the ANPA 201510.
This document describes the three following categories of drones : ‘Open’, ‘Specific’ and ‘Certified’. In our work, we focus on ‘Open’ and ‘Specific’.
The ‘Open’ category is for low risk, and simple drone operations. In this case, the risk will be mitigated through operational limitations. There will not be any certification, approval or licence for this category. By the way, two features will be mandatory. In the proposal 6 of the ANPA 201510, EASA talks about geofencing and identification features. The geofencing feature is meant to be sure that drones will not fly in predefined ‘No Fly Zones’ and could be used for both safety and privacy issues. The identification feature requests the drone to answer to a defined message with specific information.
The ‘Specific’ category contains drones fulfilling operations that are riskier for overflown people or for drones sharing the airspace with manned aviation. In this category we can find drones flying above cities or crowds, heavy drones, autonomous drones and others. As the risk generated by these drones is more important and can cause fatalities, EASA proposes that they shall perform a system risk assessment to identify the risks that are specific to the operation, as the ARP4761 describes for avionic systems.
3.2 AUTOMATED TEST BENCH
Identification and Geofencing are not very complex features, but the presence and correct implementation of these features will have to be proven to regulation authorities otherwise the drone will not be allowed to fly. One possibility is to run through a DO178C process. Manufacturers will have to provide a lot of documents, to develop tests and to go through a traditional certification process. Regulation authorities would have to check the correct development of these features. There are several hundreds of drones and autopilot versions, this solution would generate a massive amount of work for both manufacturers and regulation authorities and would considerably limit the market of ‘Open’ drones.
There is a more efficient way to know if these features are correctly implemented. DO178C demands specifications, but in that case the specification will be the same for all drones, so it could be made once for all. On the other side, as the specification is known, it is possible to develop the associated tests. A test bench that could automatically check the presence and correct implementation of the
features can be built. It could stress the drone with a defined set of test cases and automatically provide positive or negative results (see Figure 2). Of course, this tool will have to be qualified by regulation authorities but the cost will be quickly compensated as the conformity could be checked with only a very few human intervention.
3.3 ARCHITECTURAL CHOICES
For drones that need safety risk assessment, NASA issued a paper (Preliminary Considerations for Classifying Hazards of Unmanned Aircraft Systems) [21] that performs FHA for a typical drone. It describes the different features of a drone and what are the critical parts. Even if this work need to be continued through PSSA, SSA and FTA, it is clear that some functions, as they involve the overall drone safety, will have to meet the highest level of criticality. DO178C provides a good way to develop correct and reliable software meeting safety requirements. It has been shown as successful for the aeronautics industry. So if we want the same correctness and reliability for drone software, DO178C is an answer. Once the system analysis is performed, DAL (Design Assurance Level) are defined for different software functions and the autopilot can be developed.
But once again, it represents a huge amount of work for both drone manufacturers and regulation authorities. If we have a closer look at the drone industry, we can see that there are a lot of different missions that can be performed by drones. In domains like health, cinema, delivery or even supervision, drones could be used very efficiently. All these uses have their specificities but all of them share a basic set of features related to the flight, all of them need to take off, navigate and land. Their specific functions related to their use are not related with safety and most of them will be assessed at the lower level of criticality, with no constraints around development process and method.
We propose a software architecture solution that allows drone manufacturers to develop domain related features without dealing with certification process. As described in Figure 3, software in a drone could be divided into two parts with different criticality levels. We propose to have a specific and constrained board dedicated to the critical part of the software. It would contain all the navigation features that are shared with almost any kind of drones, whatever their mission. Beside this board a second one would contain the nonsafety critical software, specific to each drone and free to be modified. These two boards could communicate through an API (Application Programming Interface) and together, fulfill drone’s mission.
By using the test bench to verify compliance of ‘Open’ drone with regulation we can bring basic safety features to small drones without increasing the development cost of the autopilot as drone manufacturers will not have to meet DO178C.
For bigger and riskier drones, we can minimize the cost of certification by dividing the software in two parts, with different criticality levels that could be developed on two different boards, with two different processes.
4. CURRENT ACTIVITIES
In this part, we describe what we are doing for both the automated test bench and the navigation software development.
4.1 AUTOMATED TEST BENCH
For the ‘Open’ category, we have started the development of a test bench that could automatically check the presence and behaviour of Identification and Geofencing features. All these tests are performed at the system level.
4.1.1 IDENTIFICATION
In the 3.1 part, we have presented a way to easily check the presence and the behaviour of Identification and Geofencing features. We have started with the definition of the identification protocol (Figure 4), using a well known protocol in drone ecosystem, the MavLink [22] protocol.
With messages #8 and #9 defined as described in Figure 5 (category_type, brand_type, operation_type and operation_purpose_type are MavLink types).
We generated the associated code using scripts provided in the MavLink repository [23]. Now, we are working on test cases and test procedures to check the correct implementation of the identification feature.
4.1.2 GEOFENCING
Geofencing is a bit more complicated as we need to simulate a GPS constellation to be able to run test cases and test procedures. There are already existing simulators like GSS9000 [24], or LabSat [25].
With these simulators, it is possible to simulate that the drone is going towards a ‘NoFlyZone’ and to see what happens.
Today, we are writing test cases and test procedures to check the Geofencing feature and are planning to buy a GPS simulator.
4.2 INTERFACING NAVIGATION BOARD WITH MISSION BOARD
We have started the development of the navigation software following DO178C. We are currently writing plans and standards, the first activity of a DO178C compliant development. There are five plans, PSAC (Plan for Software Aspect of Certification), SDP (Software Development Plan), SVP (Software Verification Plan), SCMP (Software Configuration Management Plan) and SQAP (Software Quality Assurance Plan) and three standards (Software Requirement Standard, Software Design Standard, Software Code Standard). Plans describe how the software will be developed, which tools will be used and standards describe rules for the development of requirements, design and code.
We have chosen an iterative and incremental process to develop our software. Every two weeks, we have a few features to specify, develop, test and review. The main advantage of that process is that it allows to have quick feedback on what works and what can be improved and to reach very quickly an efficient process.
The architecture we chose is the one described in section 3.2. We are developing the navigation software on a dedicated and certified board that will communicate with the mission dedicated Non Certified board.
The architecture is described in Figure 6.
The communication between the two board is done through an API that provide the needed information like position (Figure 7), battery level (Figure 8)
When messages arrive to the drone, those concerning Navigation will be sent to the certified board and those concerning the mission will be sent to the noncertified board. After the processing, output from both mission and navigation board will be sent together on the output channel. ‘Dispatch’ and ‘Gather’ function might be located on the certified board but are separated on the figure for better understanding.
So the DO178C plans are describing the development process for ‘Dispatch’, ‘Navigation’ and ‘Gather’ functions. The ‘Mission’ part has no constraint and can be developed freely by drone manufacturers.
To sum up, Table 1 describes which method or tool we propose in front of the different categories of drone.

5. CONCLUSION AND PERSPECTIVES
Drones have to be safer and regulation authorities will provide regulations. But these regulations will have to deal with two problems. The workload of certification for the EASA and the cost of certification for drones manufacturers.
By performing an automatic check of required features and using an architectural choice that allows drone manufacturers to keep developing their software, it is possible to make safer drones at a lower cost. With the automated test bench, ‘Open’ drones would be able to meet regulation needs easily, without a particular knowledge of DO178C.
For the ‘Specific’ category, the navigation board could be the same on drones with different uses but the mission board could be freely developed by drone manufacturers.
We are currently using these two strategies in the development of the Pulsar Flight System, our certified navigation board. There are still challenges but nothing that cannot be done. These solutions might be an answer for drone regulation.
6. REFERENCES
[1] : Teal Group Aviation Consulting Group https://tealgroup.com/index.php/abouttealgroupcorporation/pressreleases/942013uavpressrelease
[2] : Tech Republic 12 drone disasters that show why the FAA hates drones https://www.techrepublic.com/artic/12dronedisastersthatshowwhythefaahatesdrones/
[3] : European RPAS Steering Group Roadmap for the integration of civil RemotelyPiloted Aircraft Systems into the European Aviation System https://ec.europa.eu/DocsRoom/documents/10484/attachments/1/translations/en/renditions/native
[4] : EASA ANPA201510 Introduction of a regulatory framework for the operation of drones https://easa.europa.eu/documentlibrary/noticesofproposedamendment/npa201510
[5] : DO178C Software Considerations in Airborne Systems and Equipment Certification https://www.rtca.org/store_product.asp?prodid=803
[6] : ArduPilot https://ardupilot.com/
[7] : Paparazzi https://wiki.paparazziuav.org/wiki/Main_Page
[8] : EZINAV https://www.auav.net/EZINAV.html
[9] : Hexo+ https://hexoplus.com/
[10] : GitHub Issue#1095 MAV_CMD_DO_CHANGE_SPEED https://github.com/diydrones/ardupilot/pull/1110#issuecomment48558719
[11] : TauLabs https://taulabs.org/
[12] : SMACCMPilot https://smaccmpilot.org/
[13] : Galois, Inc https://galois.com/
[14] : DARPA HighAssurance Cyber Military Systems https://www.darpa.mil/program/highassurancecybermilitarysystems
[15] : Ivory Language https://ivorylang.org/ivoryintroduction.html
[16] : Tower Language https://ivorylang.org/toweroverview.html
[17] : CppCheck https://cppcheck.sourceforge.net/
[18] : Coverty https://scan.coverity.com/
[19] : QuickCheck https://www.cse.chalmers.se/~rjmh/QuickCheck/manual.html
[20] : ARP4761 Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment https://standards.sae.org/arp4761/
[21] : NASA Preliminary Considerations for Classifying Hazards of Unmanned Aircraft Systems https://shemesh.larc.nasa.gov/people/jmm/NASA2007tm214539.pdf
[22] : MavLink Protocol https://pixhawk.ethz.ch/mavlink/
[23] : MavLink Repository https://github.com/mavlink/mavlink
[24] : GSS9000 https://www.spirent.com/Products/GSS9000GPSSimulator
[25] : LabSat https://www.labsat.co.uk/index.php/en/products/l

Source: SOGILIS

Useful link: https://dronesgator.com/how-to-build-a-drone/