A Distributed Integrated Modular Avionics platform for

Multi-Mission Vehicles

Miguel Tavares de Barrosmiguel.barros@tecnico.ulisboa.pt

Instituto Superior Tecnico, Universidade de Lisboa, Portugal

July 2019

Abstract

More than ever, the development of avionics systems for unmanned multi-mission vehicles requiresan ever-increasing optimization and standardization effort. Recently, a new type of avionics architecturebased on the use of Distributed Integrated Modular Avionics (DIMA) was developed for civil aviation. Itallows for a significant increase in the number of avionics functionalities and a reduction in related weightand power consumption. By adopting these DIMA architectures, unmanned multi-mission vehicles gainincreased flexibility, certifiability and compatibility with regulated airspace, expanding their range ofapplications in a safe manner. This thesis details the existing limitations with unmanned platforms andproposes the use of DIMA architectures as a solution. To this purpose, an existing reconfigurable DIMAarchitecture was studied and integrated in an Unmanned Aerial Vehicle (UAV). The resulting platformwas then validated in a simulated environment and tested in a real use-case scenario. Concurrentlythe use of Software-Defined Radio (SDR) communication for data-link applications was investigated,studying the benefits of integrating this flexible technology in such a modular avionics platform. Theproposed avionics integration proved to be successful, in both the simulated and the real environments,performing an automated flight while maintaining its existing DIMA reconfiguration capabilities. Asmall data link protocol was also implemented using SDR, which worked as expected on the workbench, but struggled in larger ranges. It is concluded that the integration of DIMA architectures onmulti-mission vehicles is not only viable, but encouraged, since these can attend to some current andrelevant limitations of this industry.Keywords: Integrated Modular Avionics, Multi-Mission Vehicle, Software-Defined Radio

1. Introduction

Over the past decades, the development of Multi-Mission Vehicles (MMVs) has increased substan-tially, taking advantage of their high degree ofversatility and the multiplicity of their use-cases,and establishing this field as a critical market forcivil and military industries. With the innovationsin computing and automation, Unmanned Vehi-cles (UVs) have proved to be effective in a vari-ety of fields from underwater and ground domains,to the space exploration industry. Originally, Un-manned Aerial Vehicles (UAVs) were mainly mil-itary aircraft, used in missions that were deemedtoo dull or dangerous for human pilots. With therapid growth in the availability of technology acrossthe world, new applications for these systems werefound. Nowadays, UAVs are part of multiple fieldsof our society, as, for example, agricultural, scien-tific and recreational. Due to this quick rise in pop-ularity and the variety of use-cases, a standardizedavionics architecture for UAVs does not exist. Ev-ery manufacturer implements their own ad hoc so-

lution, preventing the use of these vehicles as anabstract platform. With the ever-increasing inte-gration of these vehicles in regulated airspace, con-cerns about the safety of these systems are beingraised, leading to newer and more strict regulations.As such, the current approach of independent andunique avionics platforms, without any overarchingarchitecture, may soon move to be outdated andobsolete.

In contrast, the civil air transport industry hasconverged into a common architecture since the 90s,based on Integrated Modular Avionics (IMA) solu-tions. These avionics platforms are the acceptedsolution for dealing with the pressure for increas-ing aircraft functionality while keeping avionics sys-tems safe. Distributed Integrated Modular Avion-ics (DIMA), also known as Second Generation IMA(IMA2G), is a recent and promising concept inIMA, which further improves modularity, reliabil-ity and lowers the cost when comparing with olderarchitectures [6]. This kind of proven innovativeavionics platform can be the solution for future

1

UAV integrations, solving concerns of reliability,flexibility and safety.

This work studies and furthers the developmentof an existing DIMA prototype UAV platform, tai-loring it to fly in an aerial multi-mission vehicle. Atthe same time, this work also studies a radio tech-nology named Software-Defined Radio (SDR). SDRtechnologies offer a promising novel approach tocommunication, permitting a higher degree of flexi-bility and reconfigurability over typical communica-tion infrastructures. Hence, SDR may prove to haveextensive synergies with IMA architectures and itsinclusion in an aircraft could have several benefitsfor Size, Weight and Power (SWaP) requirements.

2. BackgroundIn order to provide the proper background, we willstart by detailing the limitations of current UAVavionics platforms and describing how the use ofIntegrated Modular Avionics can provide significantimprovements to the industry.

2.1. The current state of UVsToday, the use of unmanned vehicles in our societyis ever-increasing, ranging from recreational to com-mercial and scientific uses. The recent growth inthis industry is being lead by multiple factors suchas: continuous developments in associated technolo-gies, an increase and diversification of applicationsand the widespread use of location based services.However, there are some challenges that these sys-tems still face. If solved, these would allow un-manned vehicles to become a more popular, safeand connected part of our lives.

Cost and reliability — While the price of un-manned systems and equipment is low when com-pared to the commercial aviation industry, cheapavionics components still have low technologicalmaturity, reliability and a higher than desired fail-ure rate. A cost-effective increase in reliabilitywould further the use of this kind of platforms.

Safety — The number of UAVs using sharedairspace has been growing significantly and thereare still few enforceable certification requirementsthat would guarantee safety of these systems. Atthe same time, most control and safety require-ments for these platforms are still too relaxed, lead-ing to less need for strict real-time requirements.The introduction of a partitioned architecture forthese platforms would ease the certification efforts,providing a cost-effective path for complying withfuture safety regulations.

Flexibility — The large number of possible mis-sions a UAV can perform implies that any under-lying platform must be capable of supporting thehighly variable requirements needed. Different mis-sions can require distinct payloads, from high stor-age and bandwidth cameras, to strict real-time sen-

sors. The flexibility of the platform is limited tothe supported payloads. For this reason, the cre-ation of a standard interface that would allow theintroduction of new payloads to the system wouldgreatly benefit the flexibility of the system.

Automation and high-performance com-puting — Currently, most of the data obtainedin a mission follows one of two paths. The livetransmission of the raw data to the ground station,or the storage of the data for posterior analysis.Both these solutions can be troublesome and couldbe improved by expanding the on-board processingcapabilities of the aircraft. This would greatly re-duce the amount of data to be transmitted, whichwould allow the operator to quickly evaluate if mis-sion objectives are being fulfilled and, if necessary,intervene in real-time.

2.2. Federated architectures and IMAUntil the early 1990s, civil aircraft avionics systemsfollowed a federated architecture. The cornerstoneof this architecture is to use a segregated “blackbox”, called a Line-Replaceable Unit (LRU), foreach avionics function. All the hardware, software,and Input/Output (I/O) interfaces needed by thesystem are self-contained in LRUs. Due to the mod-ular nature of this architecture, some benefits arisewhen designing such systems. These modular ele-ments are easy to replace, allowing for simple faultdetection mechanisms and maintenance, since oneonly needs to swap out the affected box for a similarone in stock. On the other hand, the inner designof the LRUs is usually developed by a third partycontractor, preventing the final system integratorto know specific details about the equipment, in-creasing the cost of modifications and upgrades tothe system.

Contrary to the federated architectures, IMA ar-chitectures focus on providing a shared pool of com-puting, communication and I/O resources to differ-ent systems. As such, spare capacity can be al-located where needed, and the number of differ-ent hardware part types is reduced. This new ap-proach proved to be a huge success, resulting notonly in a state-of-the-art avionics system, as wellas in a new model for developing future ones [8].Although computing resources may be shared be-tween hosted functions, each one may have specificinterface needs. In the first IMA implementations,the processing modules were developed with theI/O interfaces needed by all the applications us-ing that resource. This forced each function to oneor more predetermined physical units, since thosewere the only ones with the specific I/O interface.These processing modules were regularly placed inthe aircraft’s avionics bay and had to be connectedthrough these specific I/O interfaces, to the respec-tive sensors and actuators. This required extra ca-

2

bling and, while still an advance over traditionalfederated architectures, left room for improvement.IMA platforms then evolved into a new paradigmwhere the I/O tasks are decentralized, extendingthe use of the Remote Data Concentrator (RDC)modules and placing them much closer to the sen-sors and actuators of the aircraft, reducing evenmore the amount of cabling required. Additionally,by focusing the processing modules solely on host-ing the avionics functions, this enabled the use ofgeneral purpose Central Processing Units (CPUs),decreasing the heterogeneity of the platform andconsequently, its cost. Nowadays, research in IMAtechnologies continues to push the boundaries inthese distributed system by integrating new and im-portant concepts, such as incremental certificationand reconfiguration mechanisms.

2.3. IMA architectures and its benefitsAs was explored previously, one core benefit ofIMA solutions is the optimization of resource allo-cation, minimizing the existence of unused comput-ing capacity in the system and improving SWaP re-quirements. Additionally, IMA platforms have alsoshown relevant enhancement in safety parametersas Mean Time Between Failures (MTBF). AamirMairaj studies the comparison between federatedand IMA architectures in several projects [3]. InFigure 1, one can observe and compare the impactcaused by the introduction of this technology.

Figure 1: Comparison of IMA architecture impactin different platforms [3].

All the studied platforms improved their MTBFbetween 2 and 3.5 times, proving that, even withoutphysical segregation between systems, IMA plat-forms can lead to better reliability. Additionally,the use of IMA eliminated the need for 40 to 145LRUs, providing a weight reduction of 40% to 60%.Of the four presented projects, the Airbus A350is the one showing greater improvements, whichis expected since it makes most use of this differ-ent paradigm. IMA platforms also bring a differentkind of advantage due to their specific developmentprocess. With the introduction of IMA, the inte-grator takes a more active role in sub-system devel-opment. With the abstraction layer created by theReal-Time Operating System (RTOS), software de-veloped by the third-party companies is also more

portable. At the same time, as developers of avion-ics functions are no longer in charge of hardwarenecessities, their focus can be shifted onto hostedsoftware, easing development burdens and certifica-tion efforts [7].

2.4. DIMA as a platform solution

As one can see, distributed IMA opens the path fora more connected, open and flexible architecture.At the same time, it does not compromise safety,allowing for the certification of a platform to high-est levels of assurance. This study will focus on theimpact of DIMA solutions applied to UAV avion-ics platforms, where concepts which were previouslyonly applied to non-critical systems, such as “Plug-and-Play” and reconfiguration mechanisms, couldlater be safely introduced.

2.5. Software-Defined Radio solutions

In order to further study the possibilities of aDIMA architecture for UVs, this work will conducta study on the feasibility of integrating Software-Defined Radio (SDR) solutions as an air-to-grounddata link. In software-defined radio communica-tion, components that are commonly implementedin hardware, such as modulators and demodulators,are instead implemented in software. This enableshigher flexibility as it is easier to change the wave-form or the encoding when these elements are de-fined by software. In addition, SDR tentatively of-fers some advantages over hardware based solutions,such as the possibility of reconfiguring links in real-time, better management of communication spec-trum by cooperative selection of channels and moreaggressive error-checking techniques.

These advantages make SDR a good candidatefor integration in a reconfigurable IMA networksuch as DIMA. The configurability of DIMA canbe expanded to encompass also the radio frequencycommunication link. A usage example of such inte-gration is the selection of the wireless communica-tion link properties depending on the requirementsof a given payload. Such a functionality also mapswell with different mission phases, where the sametransmitter can adapt to the availability of differentcommunication links.

3. The first DIMA platform

The main motivation in the development of the ini-tial DIMA platform was to expand IMA to the mar-ket of unmanned vehicles, addressing some trendsin this industry. Most UAVs are still based on pro-prietary and closed architectures, where a handfulof suppliers have full control of sub-system integra-tion. At the same time, certification concerns forthese systems are increasing, as a result of theirexpansion in applicability and desire to operate inregulated airspace.

3

3.1. The distributed IMA architecture

To answer these goals, the platform utilizes a dis-tributed IMA architecture as its foundation. Theuse of IMA standards also introduces an under-lying partitioned architecture, where the avionicsplatform is composed of different layers, which ab-stract the underlying hardware and allow applica-tions to be developed independently. By combiningthe versatility of UAVs with the open modularityand proven safety of DIMA technologies, the goalis to introduce the concept of “UAV Platforms as aService”, while improving the current standards forsafety and security in UAVs.

3.2. Reconfiguration mechanisms

One key enabler for this vision is the introductionof reconfiguration mechanisms into distributed IMAplatforms, which plays a critical role in opening newpossibilities. There are various benefits to usingreconfiguration in IMA, some of which are detailedbelow.

Overcoming hardware failure — The plat-form can continuously verify each module’s stateand take action if one fails. Reconfiguration al-lows it to overcome hardware failure by using re-dundancy management, improving the operationalreliability of the aircraft while preserving currentlevels of safety.

Multiple levels of autonomy — At the sametime, reconfiguration allows the unmanned vehicleto work in different autonomy levels. The user canbe in charge of flying the aircraft, or leave thatto the autopilot and dedicate its efforts somewhereelse, for example navigation or payload deployment.This allows vehicles to be optionally piloted, or towork with reduced crew configurations.

Change in Payload/Mission — Currentavionics system designs are mission specific, andswitching between them is time and cost consuming.Reconfiguration allows the platform to react andadapt to a payload or mission change, saving impor-tant resources between different missions. Payloadintegration can be handled by software, excusingthe need for dedicated hardware. By using recon-figuration mechanisms the platform can change tomeet the different payload’s requirements.

In DIMA, the implemented reconfiguration mech-anism is classified as automatic and multi-static.Automatic reconfiguration occurs without humaninvolvement, after being triggered by a predeter-mined event. Multi-static reconfiguration statesthat the set of configurations and transitions be-tween configurations are predefined and prevali-dated. This prior verification of allowed statesopens the way for a certification process, as theirexpected behavior has been previously studied. Themain trigger for the reconfiguration in DIMA is a

modification in the payloads attached to the avion-ics system. After user consent is given, the platformexercises reconfiguration at all levels of the system,changing the applications running on each module,adapting network routes and providing applicationswith new parameters (e.g. new aerodynamic vari-ables or increased weight).

3.3. DIMA Test Bench

To prototype the creation of such avionics platformand the study of reconfiguration solutions, a DIMATest Bench was developed and is represented in Fig-ure 2. The DIMA Test Bench includes four CoreProcessing Modules (CPMs) and four RDCs, em-ulated using inexpensive boards. These are con-nected by an Ethernet network which allows themto exchange useful information.

Figure 2: DIMA Test Bench block diagram.

The Test Bench is a small scale demonstrator,and, given the prohibitive overhead of integratingreal payloads in the system, these are simulatedusing Arduino prototyping boards and other quickprototyping elements. The core processing mod-ules used run GMV’s real-time operating system,XKY [1]. These elements are responsible for themain processing of the avionics platform as well asthe reconfiguration services. The remote data con-centrators run RTEMS real-time operating system.Their function is to act as a bridge between theEthernet network and the payloads of the system.They also implement the payload recognition pro-tocol and participate in the system-wide reconfigu-ration. More detail on this platform and on the rea-soning behind its development choices can be foundin Distributed Integrated Modular Avionics [2].

3.4. Outcomes

The DIMA Test Bench was a successful prototypeof a distributed IMA platform, allowing the ex-ploration of new technologies and reconfigurationmechanisms. While its objectives were fulfilled, theplatform was still far from being representative of areal-case scenario. With the promising results ob-tained, this work continues the research by further

4

developing DIMA and studying some other inter-esting new concepts related to IMA technologies.

4. A DIMA platform for UVsHaving described the existing platform, we nowpresent the avionics platform for a DIMA basedUAV, aptly named DIMA-FLY. The steps towardsits development are hereby discussed, mainly in-volving the integration of the Commercial Off-the-Shelf (COTS) flight control system and the proto-typing of the SDR data link. The main objectivesof the study were:

1. To integrate a tailored DIMA platform in aUAV, providing automated flight functionalityand payload driven reconfiguration;

2. To study and prototype the usage of SDR inDIMA architectures.

All these needed to be fulfilled without compro-mising the reconfiguration functionalities featuredin the original DIMA Test Bench.

4.1. UAV acquisition and assemblyThe aircraft that was integrated with DIMA avion-ics is Applied Aeronautics’ Albatross UAV. TheAlbatross UAV is a high performance commercialdrone with an affordable price, which uses compos-ite materials, weighs around 4kg (without batter-ies), has a 10kg Maximum Takeoff Weight (MTOW)and a 3m wingspan.

4.2. Integration of the Flight Control SystemOne of the main goals for the DIMA-FLY platformis the capability of automated flight. The prob-lem of autonomy in UAVs has been studied heav-ily and there are now commercial off-the-shelf solu-tions that could be integrated in the avionics plat-form. Using a COTS module prevents the need todevelop solutions for problems outside of the scopeof the study, such as sensor device drivers and a fail-safe manual mode. The work involved choosing theproper hardware and software, studying their im-plementations and designing a way for the DIMAplatform to cooperate with the Flight Control Sys-tem (FCS), providing some flight autonomy. Thechosen FCS was the Pixhawk 1 hardware board,using the PX4 software stack.

4.3. Operating flight modesThe ability of a system to control the movementof a vehicle can be divided into three main tasks:Guidance, Navigation and Control. To explore dif-ferent levels of responsibility for the DIMA systemwhile making most of the FCS functionalities, twoflight modes were designed:

Waypoint mode — The simpler mode, wherethe DIMA platform is only in charge of the Navi-gation, and delegates Guidance and Control tasks

to the FCS. The DIMA platform is in charge of re-ceiving the desired trajectory waypoints from theground station and communicating them to theFCS, while safely executing other previously definedtasks as payload handling and health-monitoring.

Attitude-target mode — This mode usesDIMA to execute both Navigation and Guidancetasks, leaving only lower level Control tasks to theFCS. Contrary to the previous mode, this one re-quires low latency processing to provide the desiredinstantaneous attitude to the FCS, furthering thetest of this avionics platform as a potential solutionfor more representative use-cases.

4.4. Communication

The DIMA platform uses a regular Ethernet con-nection and UDP/IP to communicate between de-vices and the application layer of this communica-tion uses a protocol named MAVLink. MAVLink(Micro Air Vehicle Link) is a protocol designedfor communication between a ground station andunmanned vehicles. This protocol has become astandard in commercial off-the-shelf flight controlsystems, allowing for an agnostic approach to theGuidance and Navigation problem. As with our im-plementation, MAVLink can also be used as a com-munication protocol between on-board computers.

4.5. DIMA module application

The application which runs on the the DIMA coreprocessing modules was written in ARINC 653 com-pliant C code. It was aptly named Guidance, Nav-igation and Control (GNC) and its responsibilityis to handle requests from the ground station, useMAVLink to communicate with the Pixhawk andexecute the desired calculations. The GNC ap-plication handles the bridge between the GroundControl Station (GCS) and the FCS. Dependingon the mode of flight, this application has differ-ent functionalities. In the DIMA Waypoint mode,the pilot provides waypoints for the aircraft throughthe GCS, which are directed to the GNC parti-tion. From there, the GNC partition handles theNavigation aspect, translating the waypoint direc-tions to the MAVLink protocol and communicatingthem to the Pixhawk, which is then in charge ofdoing Guidance and Control tasks. In the DIMAAttitude-target mode, the pilot also provides way-points through the GCS. In this mode however,the GNC partition handles the Guidance aspect,along with the Navigation, calculating the neces-sary position and attitude setpoints to accomplishthe mission. The position and attitude target dataare then sent obeying the MAVLink protocol tothe Pixhawk, which handles only the Control as-pect of finding the necessary control surface move-ments needed. The system is duplicated in a coldredundancy scheme. If one of the duplicated ap-

5

plications stops emitting a heartbeat message, thebackup module takes responsibility for the systemfunctionality using DIMA’s reconfiguration mecha-nisms to immediately take charge.

4.6. Guidance algorithmFor the DIMA Attitude-target mode, the existingGuidance algorithm from the PX4 flight controlsoftware was adapted and implemented to run inDIMA processing modules. It uses two main cal-culations for lateral and longitudinal control of theaircraft.

4.6.1. Lateral controlThe lateral control calculation is based on a non-linear guidance algorithm, which is known as L1

guidance algorithm. As described by Park et al.[4], this nonlinear algorithm starts by selecting areference point in the desired path, which shouldbe located at guidance length L1 in front of the air-craft. Afterwards, a lateral acceleration commandis determined using the expression:

as = 2V 2

L1sin η (1)

Where as is the lateral acceleration of the air-craft, V the aircraft velocity, L1 is the line from theaircraft position to the reference point and η is theangle from V to the line L1 (clockwise is positive).

Figure 3: Guidance algorithm diagram.

This simpler approach to the lateral guidanceproblem provides two important properties:

1. The direction of the acceleration depends onthe sign of the angle between the L1 line andthe aircraft velocity, allowing the vehicle toalign the direction of its velocity with the oneof the L1 line.

2. At any point in time a circular path can bedefined by two points (the position of the ref-erence point and the current aircraft position)and a tangent (the aircraft velocity). This al-lows the algorithm to follow a circle when pro-ducing acceleration as.

The last step involves calculating the desired rollangle from the obtained acceleration. For this, theaircraft is described as being in a banked turn,where altitude is maintained and the centripetal ac-celeration is provided by the lift force and the rollangle.

Figure 4: Banked turn diagram.

Using this model, the following equations are de-rived:

L sinφ = mas (2)

L cosφ = W = mg (3)

Where L is the aircraft lift, φ is the roll angle, Wis the aircraft weight, m is the aircraft mass and gis the acceleration of gravity. Consequently:

mg tanφ = mas (4)

φ = arctanasg

= arctan2V 2 sin η

gL1(5)

The desired roll angle is then ready to be sent tothe PX4 software, which will use it as a desired set-point. The yaw angle is simply sent as the bearingfrom the current position to the L1 reference point.

4.6.2. Longitudinal controlThe longitudinal control is used to calculate the de-sired pitch and normalized throttle, allowing theaircraft to climb and descend automatically. Forthis, an approach called Total Energy Control Sys-tem (TECS) is implemented in PX4. This mainconcept of this algorithm is described by R. Bruce[5]. It aims to control the total energy rate of theaircraft, which can be expressed as the sum of thepotential and kinetic energy of the system:

E = Wh+1W

2gV 2 (6)

Where E is the total energy of the aircraft andh is the aircraft altitude. The specific energy rateof the system, normalized for the velocity, can thenbe expressed by:

E

V=h

V+V

g= γ +

V

g(7)

Where γ is the flight path angle. For an accel-erated climb, the following equation of motion istrue:

T −D −W sin γ =W

ga (8)

6

From Equations 8 and 7, and for a small enoughγ, we then obtain the thrust required as:

T = W (γ +V

g) +D (9)

Where D is the aircraft drag and T the requiredthrust. Assuming that the variation in drag is slowenough, Equations 7 and 9 allow us to approximatethat the aircraft throttle controls the rate at whichenergy can be added or removed from the system.A control law can then be implemented, driving theerror of the total energy rate to zero. Our imple-mentation uses a simplified version of this controllaw, by porting the algorithm present in PX4 intothe DIMA module. Utilizing a previously calcu-lated desired setpoint for speed and altitude, wefirst obtain the demanded specific energy and spe-cific energy rate. Using the cruise throttle as thestarting point, we assume that:

1. The maximum specific total energy rate isachieved when throttle is at maximum;

2. A zero specific total energy rate is achievedwhen throttle is at cruise;

3. The minimum specific total energy rate isachieved when throttle is at minimum.

With this simplification, and utilizing thesame Proportional–Integral–Derivative (PID) con-trol feedback present in the PX4 software, we cancalculate an appropriate normalized throttle thatwill match our desired specific energy rate. Uponobtaining this value, the final step is to specify aspecific energy balance that details whether energyshould be allocated towards kinetic or potential en-ergy. Using calculations provided in the original im-plementation, this specific energy balance and thedesired specific energy rate can be used to calculatea desired pitch angle. Together with the desiredthrottle, roll and yaw, these values are combinedand sent to the PX4 software as a desired attitudesetpoint.

4.7. Software-Defined RadioAnother goal of this study was to learn aboutand prototype a SDR data link. For this studya single channel data link was implemented. Thetwo transceivers establish a communication chan-nel. Upon arrival the message is subject to anintegrity check, in order to guarantee the validityof the data. The radio communication operatesin half-duplex mode avoiding cross feedback fromthe receiving and transmitting antennas. The SDRtransceivers appear as static IP addresses in theDIMA network. As such, any packets that are tobe sent through the SDR data link need only to beaddressed at specific IP address of the RDC. This

process provides a seamless integration of the SDRsystem, greatly simplifying its interaction with thenetwork.

The SDR transceiver functionality, can be di-vided into two separate layers. The ApplicationLayer, mainly responsible for receiving and send-ing data on the DIMA network, and the Physi-cal Layer, responsible for transmitting and receiv-ing frames of data between the application layerand the antennas, while executing needed signalprocessing functionalities. The SDR transceiverspresent in the system need to be physically con-nected to a host board or computer, which run theApplication Layer software, responsible for severaltasks in the data link communication channel. Thissoftware uses an Ethernet interface to communicatewith the network. In the DIMA Ethernet network,the host boards are non-reconfigurable RDC mod-ules with static IP addresses, bridging the gap be-tween the SDR transceiver and the network. Inthe other side of the data link channel (the GCS),the SDR transceivers are connected to the computerperforming ground control functions. Using precon-figured IP addresses and UDP ports the Applica-tion Layer listens to data and sends it across thechannel. On the other end of the channel the otherApplication Layer instance forwards the data to therespective destination on the new network, connect-ing multiple receivers and sender across differentnetworks. Despite the fact that this implementa-tion uses only one computer on the GCS network,it still uses the configuration possibilities to sendand receive different data through different UDPports, allowing information exchange with differentpartitions in different CPM modules in the DIMAplatform.

Figure 5: DIMA-FLY SDR functionality.

4.8. DIMA-FLY

After verifying the integrity of the Albatross air-frame and testing the Pixhawk avionics, these wereintegrated into the Albatross aircraft. The Pixhawkboard uses a variety of sensors and actuators to con-trol the aircraft attitude according to the desiredsetpoint. The integrated sensors were:

• The internal Pixhawk sensors, as gyroscope,accelerometer, magnetometer and barometer;

7

• A pitot tube, fixed under the wing to measurestatic and dynamic pressure;

• And an external Global Positioning System(GPS) receiver, module Reyax RY836AI.

The integrated actuators were:

• Servomotors in control surfaces,

• Brushless motor for propulsion.

Figure 6: DIMA-FLY diagram.

5. Results

5.1. Software-In-The-LoopThe first validation of the integration was donethrough the development of a Software-In-The-Loop (SITL) configuration, testing the automatedflight capabilities of the system in a simulated en-vironment. A desktop PC running Linux was con-nected to the DIMA network. Here, two relevantprograms were running: an instance of the previ-ously mentioned PX4 software and a physics simu-lator named Gazebo.

5.2. Mode comparisonAt this stage, it is important to study the compari-son between the DIMA Waypoint mode and DIMAAttitude-target mode. The difference between themis that in DIMA Waypoint the Guidance task is upto the commercial FCS, while in DIMA Attitude-target mode the Guidance algorithm is calculatedin the DIMA distributed modules. Using the sametrajectory, data from both types of flights was ob-tained. Figure 7 shows the ideal trajectory, nextto the ones resulting from Waypoint and Attitude-target modes.

As can be seen, the trajectory obtained by ourimplementation of the Guidance algorithm is sim-ilar to the one from PX4. In fact, the Attitude-target mode resulted in an Root Mean Square(RMS) lateral deviation of 3.984 m, while the Way-point mode resulted in a higher 6.234 m deviation.

Figure 7: Trajectory comparison.

While this value is specific to this path, it serves aspartial validation for the implemented algorithm,proving it can follow the desired lateral trajectorywithin a reasonable degree of accuracy.

The longitudinal component however, proved tobe harder to replicate, as can be seen in Figure 8.Here, when ignoring takeoff and landing, Attitude-target mode resulted in an RMS vertical deviationof 5.263 m. Waypoint mode, on the other hand,resulted in a lower 3.940 m deviation. The PX4 im-plementation includes multiple adjustments to pro-vide a more stable altitude which were not portedto the DIMA modules. While this does not com-pletely invalidate the performance of the Attitude-target mode, it puts into question how robust it isand if it could handle unpredictable conditions aswind.

Figure 8: Trajectory altitude comparison.

5.3. Hardware-In-The-Loop

The next validation step was to repeat this simula-tion using a Hardware-In-The-Loop (HITL) mech-anism. This means that the PX4 no longer runs onthe Linux desktop, but now runs on the final hard-ware, the Pixhawk board. This allows testing thenon-functional requirements of the system, guaran-teeing the Pixhawk board has the needed memoryand processing power to complete its tasks. Theresults of this step were similar to the one before,verifying that the system followed the expected be-havior observed in the SITL simulation.

8

5.4. Aircraft-In-The-Loop

Finally, the DIMA-FLY was assembled in order totest the DIMA platform in a proper flight test. Thepurpose of this flight was to safely test the DIMAWaypoint mode, verifying the automation of theaircraft and the ability of the platform to handleother important tasks, such as payload handlingand system-wide health-monitoring. The test flightstarted by using the PX4 Manual mode for takeoff.Afterwards, Stabilized mode was used to make surethat all the connections and signals are properlyadjusted from the Pixhawk’s perspective. When itwas deemed safe, the DIMA GCS was used fromthe ground laptop, transmitting the desired way-points to the flight controller. Then, DIMA Way-point mode was initiated remotely, starting the au-tomated portion of the flight. Using the Pixhawk /PX4 system allows the capture of important flightdata in the form of a specific log file. Below, somerelevant flight data that was retrieved from the testflight is presented.

5.4.1. Altitude estimate

As can be seen below, according to the GPS data,the ground altitude is at around 50 meters. Theaircraft climbed in Manual mode until around 200meters, when the Stabilized mode was activated.When the expected behavior of Stabilized mode wasconfirmed, Mission mode was activated from theGround Control Station, and the aircraft flew itsmission automatically at around 150 meters.

Figure 9: Altitude estimate.

5.4.2. Roll angle

This graphic presents both the estimated roll angleand the roll setpoint, which is the desired roll angleto fly automatically. As we can see, both are highlycorrelated, demonstrating the expected behavior.

5.4.3. 2D Trajectory

In this subsection one can observe the 2D trajectoryof the flight displayed on top of a grid scale.

6. Conclusions

In closing, we will now detail the achievements ofthe work performed and provide useful notes forfuture developments in this topic.

Figure 10: Roll angle.

Figure 11: 2D trajectory — Grid scale.

6.1. Achievements

The first DIMA Test Bench was built on COTScomponents that did not possess the maturity com-patible with aeronautic requirements. While thissolution was cost effective, this study aimed to im-prove on the maturity of the avionics platform and,consequently, to increase the representativeness ofthe demonstrator and its applicability in aeronauticcontext. For this purpose, the study targeted thefollowing goals: to integrate a tailored DIMA plat-form in a UAV, providing automated flight func-tionality and payload driven reconfiguration, andto study and prototype the usage of SDR in DIMAarchitectures.

To fulfill the first goal, a tailored version of theDIMA platform was integrated in an aircraft model.The DIMA-FLY configuration acts as a validationof DIMA platform’s maturity, since it imposes re-quirements closer to the typical ones for aeronau-tical systems in real flight scenarios. A Pixhawkflight control system was integrated in the network,and, coupled with a GNC application, provides theaircraft model with automated flight capabilities.With the development of the GNC application, anew Ground Control Station software was also pro-totyped.

The final goal was to study SDR technologies,investigate possible synergies with DIMA architec-tures and prototype a data link solution. Usinga prototyping board called bladeRFx40, a single-channel data link solution was implemented in theDIMA platform. Using an integrity-checking func-

9

tionality at each end allows for the verification ofdata payload. The link also includes a scramblingtechnique, which encrypts and protects the databeing transmitted. These boards connect to theDIMA network using static RDCs and allow anyelement on the network to send and receive dataacross the link.

In conclusion, this study was an important andsuccessful step in the development of DIMA as aplatform, acting as a validation for its maturitywhile imposing a real life scenario on this architec-ture.

6.2. Recommendations for future workWhile this study improved certain aspects of theDIMA platform, there are still relevant activitiesthat could be developed in future projects to im-prove the platform. Some are described below.

• DIMA-FLY’s automated flight capabilities arecurrently dependent on the low-level function-alities of the Pixhawk. It would be interestingto transfer more capabilities to the DIMA pro-cessing modules.

• At the same time, the Attitude-target flightmode didn’t prove to be mature enough, sus-pending initial plans for a test flight using thismode. While the simulated implementationproved to be successful, more effort would haveto be dedicated to obtain a flight-ready versionof the algorithm.

• SDR proved to be a complex field of work, andthe prototype displayed some limitations. Thedata link displayed a small range of around 10to 20 meters. Due to this limitation, DIMA-FLY used a traditional telemetry data link forthe flight scenario. Due to the amount of effortand resources needed to solve this issue, it wasleft as potential future work.

• In addition, the use of a proper avionics net-work, perhaps based on Avionics Full-DupleXSwitched Ethernet (AFDX), could also be fur-ther considered. The reconfiguration of time-predictable networks was considered out ofscope of this study. This simplification in termsof network choice has resulted in several is-sues being avoided and in a simplification ofthe configuration, as no network configurationwas required. Nonetheless, the impacts of thenetwork on the reconfiguration need to be fur-ther explored as the distributed system and,therefore, the reconfiguration, heavily dependon the network capabilities.

AcknowledgementsThe author would like to thank Claudio Silvaand the rest of GMV’s team for providing the

opportunity, tools and knowledge needed to per-form this study. Another thank you goes to Prof.Agostinho Fonseca, which provided valuable guid-ance throughout the process.

References[1] XKY User Guide. GMV, February 2018.

[2] M. T. Barros, J. A. S. Neves, J. R. P. Negrao,S. D. Penna, and M. A. A. Ortiz. DistributedIntegrated Modular Avionics. In STO-MP-IST-166, number 3. STO, October 2018.

[3] A. Mairaj. Preferred choice for resource effi-ciency: Integrated modular avionics versus fed-erated avionics. In 2015 IEEE Aerospace Con-ference, pages 1–6, March 2015.

[4] S. Park, J. Deyst, and J. How. A new nonlin-ear guidance logic for trajectory tracking. 082004. ISBN 978-1-62410-073-4. doi: 10.2514/6.2004-4900.

[5] K. R. Bruce. Integrated autopilot/autothrottlefor the nasa tsrv b-737 aircraft: Design and ver-ification by nonlinear simulation. 03 1989.

[6] G. Wang and Q. Gu. Research on dis-tributed integrated modular avionics systemarchitecture design and implementation. In2013 IEEE/AIAA 32nd Digital Avionics Sys-tems Conference (DASC), pages 7D6–1–7D6–10, October 2013.

[7] C. B. Watkins and R. Walter. Transi-tioning from federated avionics architecturesto integrated modular avionics. In 2007IEEE/AIAA 26th Digital Avionics SystemsConference, pages 2.A.1–1–2.A.1–10, October2007.

[8] B. Witwer. Systems integration of the 777 air-plane information management system (AIMS).IEEE Aerospace and Electronic Systems Maga-zine, 11(4):17–21, April 1996.

10