A UAV Mission Computer Operation Modes Optimization Focusing on Computational Energy Efficiency and System Responsiveness

1. Introduction

Today, unmanned aerial vehicles (UAVs) are widely used in many areas of human activity and play an essential role in scientific, industrial, search and rescue, surveillance, cinematographic and other tasks [1]. The use of UAVs made it possible to carry out dangerous missions without risking the health and life of the operators. With the beginning of Russia’s aggression in Ukraine, it became clear that the effective use of UAVs on the battlefield was almost the only possibility for the Ukrainian armed forces to oppose Russia’s massive military machine. Analyzing this confrontation, the Center of Excellence for Integrated Air and Missile Defense in the report [2] emphasizes the need to adapt NATO’s military doctrines, concepts, and tactics to the new realities of using UAVs, UGVs (unmanned ground vehicles), UWVs (unmanned water vehicles/vessels) and countermeasure systems.

The works [3,4] present an overview of UAV research and highlight the latest trends and achievements. The authors also consider UAVs’ general hardware and software architecture and describe their applications. The article [5] provides an overview and classification of UAVs. It also describes the capabilities and characteristics of UAVs weighing 2 to 11,600 kg and operating up to 40 hours.

The UAV market is actively developing. According to Fortune Business Insights [6], the CAGR of the global UAV market is 16.3% for the period 2023-2030, and the majority of the market is accounted for by UAVs of small and tactical devices (Figure 1). For such UAVs, the requirements for the on-board computer must correspond to the increased complexity of the system [7,8,9,10].

Every UAV that takes off has its mission to generate value for the operator of a UAV. To carry out its mission, a UAV shall consist of reliable, powerful, and yet power-efficient avionics (Figure 2) with the required mission capabilities. The orchestration of the mission is done by a central computer, which is called the mission computer. The typical tasks of the mission computer are to control the entire avionics, compute the UAV’s route, ensure communication to the ground station (if required), and control the onboard payload.

This article will concentrate on the mission computer alone as this is the most complex yet flexible and configurable part of modern UAV avionics.

The background of the research in this paper is the growing need for real-time mission computers that are powerful and responsive yet power-efficient and cost-efficient.

Investigating the trade-off between system reactivity and the use of energy-saving modes of the computing platform is vital in many situations, not only for UAVs but also in all real-time systems with an autonomous power supply. These are embedded systems in industrial applications, Internet of Things (IoT) devices, implanted medical devices, emergency notification systems, etc. During the operation of the computing platform, this compromise is achieved through software-implemented algorithms that allow adaptive control of computer operating modes depending on current conditions and requirements for reactivity and energy consumption of the system. To solve the question of the expediency of spending on the development of new algorithms and software, an experimental study is needed to build a mathematical model that comprehensively characterizes the reactivity and energy consumption of the computer.

The purpose of this paper is to develop a technique for experimental studies of indicators of reactivity and energy consumption of the computing platform for UAVs. All work in the paper is carried out using the authors’ mission computer ’Boryviter 0.1’.

The paper is structured as follows:

• Chapter 2 - ’Domain Overview,’ introduces the reader to the mission of computers as the object of the study, provides an overview of the real-time operation systems (RTOS) usage challenges, and describes tools and needs of energy-saving solutions for embedded mission computers;
• Chapter 3 - ’Materials And Methods’ describes the platform for conducting the study experiment, defines a system model in the look of a power state machine, and describes the exact way of measuring reactivity and power consumption of different modes of operation;
• Chapter 4 - ’Results’ provides the obtained experiment results;
• Chapter 5 - ’Discussion’ describes and presents the obtained results applied to the proposed system model;
• Chapter 6 - ’Conclusion’ concludes the article by describing the novelty of the research and its further development.

2. Domain Overview

The chapter provides an extensive overview of the technology, design, and efficiency considerations for mission computers in unmanned aerial vehicles (UAVs).

The modern approach for the avionics and mission computers development consists of the following key steps:

• Select an appropriate ready-to-use avionics platform (including a mission computer);
• Use microcontroller-specific vendor toolchain;
• Ensure that a real-time operation system is in place and can be easily adapted to the selected computation platform;
• Design and validate the required for the flight mission business logic (i.e. what exactly a UAV shall do).

All of the items above do not guarantee that the selected platform, microcontroller, operating system, and other components will allow the integrator to achieve the required results to fulfill the mission objectives. In the chapter, an in-depth review of the technologies, techniques, parts, and problems mentioned in the UAV avionics design process is reviewed.

2.1. UAV Avionics and Mission Computers

Typical UAV avionics (the on-board electronics) consist of several parts, they are (Figure 3):

• Mission computer (often called an on-board computer or flight controller board);
• Navigation and orientation system (GNSS and GPS);
• Sensors board + sensors;
• Remote control and telemetry system (Communication unit);
• Energy and propulsion system (Driving unit);
• Payload (sometimes called an off-board module).

A mission computer is a specialized computer system integrated into the avionics of a UAV or, in general, into another complex technical device that requires autonomous control and high reliability[12]. Computational power, reactivity, energy efficiency, peripheral support, and real-time performance are important considerations when choosing a mission computer. The reality of mission computer build-up and development shows that most commercial off-the-shelf (COTS) products [13] are built on a specific series of microcontrollers or microprocessors (main processors) known to the development team or the vendor. This expertise significantly advances software quality, expedites time-to-market, and enhances flight heritage.

Microcontroller units (MCUs) utilized in UAVs or nanosatellites generally exhibit substantial similarities, except when considering radiation-hardened or radiation-tolerant microcontrollers [14]. These specific microcontrollers are beyond the affordability of commercial electronics and, consequently, will not be evaluated in this article. As a result, the spectrum of available components for utilization, as well as the associated toolchain for RTOSes and development tools, is considerably broadened.

The similarity of the requirements for the construction of UAV and nanosatellites onboard systems makes it expedient to use a standard technology stack [15] to address both application areas being part of aerospace engineering. A description of the highly integrated onboard computing products used for CubeSat missions (class of nanosatellites) is given in [16]. The most energy-saving solutions are based on ARM Cortex-Mx (where x is 0 to 7), LEON3FT, and Atmel ARM 9.

Electronic component manufacturers constantly update available offers, allowing UAV developers to achieve better results (appropriate productivity with low power consumption) when solving complex tasks. Popular MCU series with brand new families that can be used in UAV onboard systems include the SAMx Series (Atmel/Microchip) [17], PIC32 (Microchip), STM32 Series (STMicroelectronics) and iMX.RT series (NXP). The characteristics of the popular series of 32-bit microcontrollers for implementing UAV mission computers are listed in Table 1. The precise selection of the components examined was determined by balancing between performance, available memory, and the availability of energy-saving modes.

2.2. Problems and Researches in the Field of Mission Computers

Ensuring the ability to fly autonomously requires efficient sensor operation, appropriate flight control, and mission software. There is a lot of research on using AI for these tasks, such as computer vision for object recognition and tracking [18,19,20], reinforcement learning for mission control [21], sensor fusion, and others. The success of missions in general and, in particular, the effectiveness of the application of machine learning (ML) models critically depends on the reactivity of the onboard system to ensure the prompt acquisition of data and the speed of execution of the relevant program blocks.

Another area of research is the energy efficiency [15,22] of the onboard systems, which directly affects the maximum duration of the UAV flight with the maximum reduction of the weight of the powertrain and its energy source. Any calculations, from the business logic that performs the business tasks (payload) and overall mission control (such as engine control) to system ones, such as diagnosing the state of the computer and connected sensors and actuators, require software running on the central processor or microcontrollers. The availability of microcontrollers does not play the last role in the selection of electronic components for mission computers. Research is being conducted on the experimental comparison of the solution’s effectiveness based on various technology stacks, which involve using budget solutions and open-source software. Thus, the paper [23] describes the creation and experimental research of a hexacopter and a quadcopter built on different flight controllers and software using budget components and free, open-source products. The authors of the paper [15] provided the results of a stack layer comparison, including the use of open real-time operating systems (RTOS), such as FreeRTOS, ROS, and Linux with real-time extensions, with open middleware such as cFS (core Flight System) by NASA or F’ Prime by JPL/NASA [24], and image sharing firmware.

Assessment of electrical power consumption in microcontrollers requires the use of mathematical models to delineate the relationship between energy consumption and the operational parameters of the target computing platform. Typically, these models are expressed as mathematical functions that correlate energy consumption with characteristics that are measured or estimated at a specific level of abstraction in conjunction with the fundamental hardware architecture. The power consumption model can be used as input data during development and for adaptive control of mission computer operating modes during application. Depending on the specific target application, the power model must meet different multi-domain and multi-criteria requirements and be designed accordingly. Power analysis during design uses the power model offline to limit the design parameter space of the target computing platform, allowing evaluation of their energy, power, performance, and other quality indicators at an early stage of development. Conversely, monitoring consumed electrical power during operation allows adaptive control of operating modes in real-time by comparing actual energy consumption estimates and a pre-designed energy consumption model.

It is important to mention that complex mission computers contain many peripheral in-circuit devices like external RAM, ROM, peripheral interface drivers, ADCs, DACs, IMUs, etc. Proper peripheral control of these extra devices via correct microcontroller power modes ensures overall mission-computer energy efficiency. The rule of thumb is that the microcontroller and the rest of the digital peripherals consume equal energy.

Looking into modern development approaches to embedded software development, it is pretty easy to see that bare metal programming is becoming less and less used, whereas RTOS-based programming is dominating. Using RTOS ensures interoperability and reuse of software components and allows the use of modern system architecture approaches such as microservices, containerization [25], and, for larger microcontrollers, virtualization. This article focuses on optimizing the power consumption of microcontrollers governed by RTOS without assessing the remaining peripherals of the mission controller.

2.3. Real-Time Systems and Typical Scheduling Algorithms

Real-time systems must guarantee task execution within specified deadlines and time constraints while ensuring energy-efficient computations. For mission computers, such tasks could lie in the domains of motor control, ground station communication, sensor fusion tasks, orientation, aircraft and operator safety handling, and navigation. All these typical tasks are to be handled by the mission computer and with a different demand from real-time criticality.

All possible tasks performed by a microcontroller can be classified as follows, determined by the nature of event occurrence:

• by execution reason: periodic and sporadic tasks;
• by constraint nature: tasks with hard or soft deadlines.

The execution schedule of a real-time system is correct if all time constraints are met.

For periodic tasks, the schedule will be a table that indicates at which point in time which task should be executed. A minimum possible event occurrence period is determined for sporadic tasks, allowing them to be artificially classified as periodic. This schedule must be compiled for a time interval equal to all tasks’ hyperperiods (the least common multiple of periods) to guarantee their execution without violating time constraints.

The classic work by Liu and Layland [26] proposed two main scheduling concepts for priority-based real-time systems:

• static priority assignment in reverse order of known task periods - Rate-monotonic scheduling (RMS);
• dynamic priority scheduling, where the highest priority is assigned to the task with the nearest execution deadline – Earliest Deadline First (EDF).

RMS-based schedulers work on timer interrupts, with tasks simply being called at the right moments from the interrupt handler. The advantage of this class of algorithms is the exceptional simplicity and predictability that is confirmed by a large number of test results and experiments. The disadvantages are:

• inflexibility, as the scheduler does not actually react to external world events and works exclusively on timer interrupts;
• difficulty in scheduling sporadic tasks based on the minimum possible period of external events;
• very large size of the schedule table with appropriate ratios between task periods.

EDF-based schedulers define the task with the earliest absolute execution deadline as the highest priority. However, in practical real-time systems, the relative deadline for task execution is not always equal to its period, so the above assumption greatly limits the usefulness of available scheduling test results based on EDF usage. Analysis of the exact scheduling possibility for EDF scheduling with arbitrary relative terms requires calculating processor requirements for a task set at each absolute term to check if there is an overflow at a given time interval. This interval is limited by a certain value, which guarantees that we can find a failure point if the task set is not schedulable. Significant efforts to perform schedulability checking according to EDF in real systems limit the possibilities of applying EDF in real-time systems. As a result, the EDF algorithm is not widely used as a fixed priority algorithm in commercial real-time systems [27]. Weakly Hard Real-Time Systems or Firm Hard Real-Time Systems were started in 2001 [28] to better characterize real-time task constraints. The concept is based on task differentiation, assuming that not all task-time constraints must be satisfied. In general, it is proposed to use a model (m, k) based on the assumption that out of any k consecutive instances (jobs) of a task, at least m instances must meet time constraints. In other words, a one-time or multiple violation of time constraints by one task is not always a failure if the number of these violations does not exceed a predetermined number. This is explained by the existing redundancy of systems and is applied to soft real-time tasks and hard or firm real-time tasks. The concept of weakened systems has been further developed in many works, for example, in articles [29,30]. It is based on the following task model in the form of a tuple:

$${\tau }_i=\langle C_i,D_i,T_i,m_i,K_i\rangle ,$$

(1)

where $C_i$ is the maximum time required for the task; $T_i$ is the minimum time interval for the arrival of the task. If it is a periodic task, then $T_i$ is its period; If sporadic, it is the minimum period of interruption occurrence; $D_i$ is the time constraint for task execution ($D_i\le T_i$);

$$\langle m_i,K_i\rangle ,m_i<K_i,$$

(2)

are weakened constraints of real-time tasks: In a sequence of $K_i$ jobs for this task, it can violate deadlines no more than $m_i$ mi times. If this task belongs to the hard real-time class, then:

$$m_i=0,K_i=1.$$

(3)

The scheduler algorithm in a weak real-time hard system includes the following steps:

• If all scheduled time constraints of all jobs for all tasks can be met using EDF, use EDF and finish. If not, then go to Step 2.
• Sort the jobs of all tasks according to the criterion of the number of time constraints of jobs that are still allowed to be violated for the planning time interval. Class "0" will include all tasks that do not allow any misses. Class "1" will include those that can violate the time constraint once. Example: if ($m_i;K_i$) for a task is equal to (2, 4), then it is allowed to violate the time constraint of 2 jobs out of 4 consecutive jobs, so the task can fall into classes 0, 1, 2 depending on the number of jobs already missed.
• Use EDF first for class 0, then for class 1, etc.

Many modern publications are devoted to technologies for evaluating microcontroller performance indicators and measuring the time costs of typical algorithms on both widely used mass-produced platforms and original developments.

In work [31], a comparison of performance indicators of the Raspberry Pi4, BeagleBone AI, and TWR-K70F120M platforms, as well as the execution time of algorithms on these platforms under the condition of multithreaded implementation of a specific set of executable tasks, was performed. The important leading indicators for real-time systems are task execution time, worst-case execution time, waiting time, and response delays. To achieve the goal, a multithreaded test program was developed with special computationally intensive sorting operations, matrix operations, and the lightweight crypto library wolfCrypt, written in ANSI C and designed for embedded systems, real-time systems, and resource-constrained environments.

The article [25] provides results that compare the computational performance of the open STEM-like hardware project Pi Pico from Raspberry on the RP2040 processor [32] and the author’s solution of the "Falco SBC/CDHM" computing platform based on the ATSAMV71 microcontroller (Microchip) [17] with improved performance. The possibility of using microservice architecture and the effectiveness of the proposed new platform were experimentally verified by measuring the processor time required to execute three typical algorithms of different algorithmic complexity and different dimensions of initial data.

A common drawback of the considered works is the lack of evaluation of the energy efficiency of computing platforms. An integral feature of real-time systems is redundancy, including time resources, to guarantee the fulfillment of time constraints under any conditions. In real projects, such redundancy exists at both the hardware and the software-algorithmic levels. It is important to answer the question of how energy-efficiently the platform behaves in the time interval when all current tasks have already been completed, and there is no need to do anything until a new interrupt comes, either external from connected devices or internal from the system timer. The ideal situation would be where the platform consumes nothing at all during this time, but this is impossible. The reverse side of this problem is to determine the indicators of deterioration in the reactivity of the computing system because before starting to do something useful after an external event, the processor and other components of the computing platform must first fully restore the normal operating mode.

2.4. Methods of Energy Consumption Management

The survey [33] provides the following classification of methods for ensuring the energy efficiency of microcontrollers in embedded systems:

• Methods of dynamic voltage and frequency scaling (DVFS) and power-aware scheduling;
• Use of low power consumption modes, called Power Mode Management (PMM) or Dynamic Power Management (DPM);
• Microarchitectural techniques for energy conservation in individual components, such as memory where the computational context is stored in memory during total or partial processor shutdown;
• Use of non-traditional computers, such as DSP or GPU FPGA. This method is suitable for computationally intensive tasks where traditional general-purpose processors perform worse (mW/MIPS).

The article [34] explores the possibility of energy savings in wireless sensor networks through DVFS in low-energy microcontrollers. The quantitative metric for evaluating energy efficiency is normalized power, which is the ratio of electrical power consumed to performance (mW / MIPS). Normalized power allows for a more accurate characterization of the microcontroller’s energy efficiency, as it considers the consumed electrical power and the performance expressed in MIPS (Million Instructions Per Second). The lower the value of normalized power, the less energy the microcontroller will consume.

Overall, the article provides a good basis for further research on DVFS in wireless sensor networks, but some aspects require more thorough elaboration. The drawbacks of the article include the difficulty in generalizing the results obtained to other platforms and architectures, the lack of evaluating overhead costs for transitions between DVFS modes, and a limited number of measurements for different voltage/frequency combinations.

The publication [35] comprehensively investigates the relationships between three components:

• real-time constraints;
• constraints on the energy consumption of the computer;
• software methods for ensuring fault tolerance.

It discusses the interdependencies of the probability of permanent failures on frequency and supply voltage, the probability of temporary failures on task execution time, and the dependence of consumed electrical power on the computer’s chosen fault tolerance policies and operating parameters. The article proposes a joint model for analyzing scheduling and failures to highlight formal interactions between fault tolerance mechanisms and temporal properties. The article suggests several vital directions for future research in the field of fault-tolerant real-time systems:

• development of scheduling algorithms that take into account the probability of failures to minimize the active time of tasks and their total probability of failures while maintaining schedulability;
• analysis of the impact of various fault tolerance strategies (re-execution, checkpoints, N-modular redundancy (NMR)) on scheduling. In particular, the integration of different approaches and their optimization to improve schedulability and compliance with requirements for failure probability;
• application of the mixed-criticality concept to make systems compatible with industry standards and quantify the probability of transition to high criticality mode;
• analysis of trade-offs between energy consumption management (DVFS), thermal effects, resistance to various types of failures, and real-time requirements;
• improvement of system software reliability, such as scheduler and failure detection mechanisms;
• use of probabilistic information about execution time to calculate a more accurate estimate of failure probability;
• consideration of other failure models, such as (k, n), approximate computations, and malicious failures.

The article [36] analyzes the reliability of embedded real-time satellite systems operating in harsh space environments. Two types of errors characteristic of systems operating in harsh temperature and/or radiation conditions are considered:

• "Soft-error" or "soft fault" - a single-event upset (SEU), temporary distortion of a bit value in memory or processor register caused by external factors that do not lead to permanent hardware damage;
• "Hard-error" or "hard fault" - permanent damage to a hardware component caused by wear or degradation of materials due to prolonged operation or, for example, radiation exposure in space use. Such errors are classified as single-event latchups (SEL).

Real-time system constraints are taken into account using a periodic task model to assess the system load during redundant backup execution of tasks to detect soft errors and their subsequent elimination by the requirements of functional safety standards such as DO-178B, IEC-61508 [37], and ISO-26262 [38]. Increasing resistance to single soft errors and permanent hard errors is achieved by solving an optimization problem.

The article [39] is devoted to analyzing and developing methods to reduce energy consumption in ultra-low-power embedded systems using dynamic voltage and frequency scaling (DVFS). The authors analyzed energy consumption while performing computationally intensive operations such as the Fast Fourier Transform (FFT), Cyclic Redundancy Check (CRC32), and the calculation of MD5 and SHA256 hash functions. According to the results of experimental testing on the ARM Cortex-M0+ microcontroller, it is confirmed that the application of DVFS can save from 27.74% to 47.74% of electrical energy. The disadvantages include the lack of comparison with other energy-saving methods and a limited set of test operations (FFT, CRC, hash functions), which may not be representative of other types of load. The problems of transient processes during dynamic voltage changes and related time delays have remained unexplored.

The evaluation of the effectiveness of system planning and energy savings in embedded real-time systems with low computational resources is a problem considered in the article [40]. In real-time operating systems (RTOS), the characteristics of the implemented scheduling policy play an important role in both scheduling and energy consumption. Ideally, the scheduling policy should guarantee adherence to task schedules and low energy costs during execution, allowing better use of the available free time to save energy. The scheduling policy proposed in the article is based on fixed priority scheduling (RMS), which provides low overhead and simplicity of implementation. According to this scheme, a simple priority vector indicates that the current task is ready for execution. However, the scheduling results are usually lower than those that can be achieved by dynamic priority scheduling, according to which task priorities are assigned during execution.

A microcontroller with the FreeRTOS operating system manages a limited energy budget using hardware and software tools [41]. When a task is waiting for an interrupt or the end of a time interval, it is blocked. FreeRTOS will execute the idle task with the lowest priority when all other tasks transition to a blocked state (waiting for an event, resource, or just the next timer-driven run). Therefore, the idle task can be put into energy-saving mode when the processor is idle. This mechanism is helpful in some scenarios, but if the clock frequency is too high, the processor will waste energy and time entering and exiting the standby mode. Thus, saving energy using this mechanism will not be beneficial. Therefore, to improve the corresponding energy-saving mechanism, a tickless idle technique was introduced [42]. The technique uses a time-tracking mechanism to turn off the source of periodic ticks for a certain period to put the processor into deep sleep mode until an external interrupt or a higher-priority core interrupt occurs.

In work [43], a solution is proposed to optimize the energy efficiency of the operating system scheduler of a microcontroller based on LM3S3748. It is proposed to use an "idle" system flow, which, after completing its own work, puts the microcontroller into Sleep or Deep Sleep modes. The article provides quantitative experimental results of measurements of the energy consumed by the microcontroller and estimates of the reduction in system reactivity due to additional time costs for suspending and resuming the microcontroller’s operation. The disadvantage of the article is the lack of generalization of results in the form of a general technology for optimizing the energy efficiency of the microcontroller’s operation.

Article [44] provides an overview of the main energy-saving algorithms. DVFS (Dynamic Voltage and Frequency Scaling) - dynamic change of processor voltage and frequency, and DPM (Dynamic Power Management) - dynamic power management, which is based on switching the processor to low power consumption modes. This review highlights the main problems associated with the reactivity of real-time systems when applying energy-saving methods. It emphasizes the complexity of balancing energy efficiency and maintaining the required level of reactivity in real-time systems.

The reactivity-time indicators given in the article can be divided into two classes. The first class includes delays that are determined mainly by the hardware component:

• Wake-up delays characterize the time required for full recovery of the processor from sleep mode. They can be measured by determining the time interval from the moment of the interrupt request to the first useful command in the interrupt handler;
• break-even time is an integral characteristic. The processor must spend the minimum amount of time in low-power consumption mode to compensate for the energy and time costs of transitioning to this mode and back. Break-even time is the sum of wake-up and transition delays, which characterize the time costs necessary for the processor to transition from active state to sleep mode.

The second class includes delays that are determined only by software algorithms:

• procrastination delays, when some algorithms deliberately postpone the execution of tasks to increase the duration of the idle period and more efficiently use low power consumption modes. These delays are carefully calculated so as not to violate the time constraints of tasks;
• scheduling delays - the time required to make decisions about changing the power consumption mode and rescheduling tasks;
• delays associated with calculating optimal moments for transitioning to sleep mode and waking up. Some algorithms perform complex calculations to determine these moments, which can introduce additional delays;
• early completion delays, which create additional space for energy saving but require dynamic rescheduling.

Considering the delays of the first class is critical for the practical application of energy-saving modes in real-time systems, as they directly affect the system’s ability to adhere to time constraints while simultaneously reducing energy consumption. Therefore, only these delays are the subject of further consideration.

2.5. Overview of Existing Methods for Evaluating Performance and Energy Efficiency of Embedded Systems

Any task of optimizing system indicators begins with measuring and analyzing the system parameters. While there are many tools for measuring and evaluating performance and energy efficiency for modern household PCs, the number of such tools for embedded computing is limited and very little known to embedded system developers.

The authors of the work [45] investigate the computational performance and energy efficiency of various microprocessors used as mission computers in nanosatellites in typical tasks of determining and controlling the orientation of nanosatellites. The primary motivation of the authors for developing a new specialized benchmark (software for measurement and comparison) instead of using known benchmarks is the shortcomings of the latter.

In short, the following benchmarks were analyzed:

• Benchmarks like EEMBC [46], ParMiBench [47], BEEBS [48], or EmsBench [49] do not contain a sufficient number of operations with matrices, quaternions, and calculations typical for satellite orientation control algorithms;
• Most existing benchmarks are focused on performance evaluation, while energy efficiency of calculations is critically important for satellite systems due to strict power constraints;
• Requirements for large memory volumes or use of external files. Some benchmarks require access to the file system, which can be problematic for embedded systems with limited memory resources;
• Lack of open source code or requirement of paid subscription. For example, EEMBC benchmarks require a paid subscription to access test loads.

The authors tested their developed benchmark on three different platforms often used in nanosatellites: Arduino Uno, Texas Instruments MSP430, and STM32 Nucleo. The electrical energy consumed was used as a key metric to compare different platforms. As a test set of tasks, the authors used typical operations and algorithms for determining orientation and controlling nanosatellites, such as operations with matrices of arbitrary dimensions and quaternion calculations.

3. Materials and Methods

3.1. Planning the Experiment

The hardware platform discussed in the following chapters falls within the first class and partially in the second, specifically designed for unmanned aerial vehicles with a take-off weight range of 20 to 150 kg according to the NATO standard 4671 "Unmanned Aerial Vehicles Systems Airworthiness Requirements" (USAR)[50]. According to the standard, the authors consider MTOW of Class II - "UAVs with MTOW between 150 and 600 kg". Experimental research is carried out on the author’s computer platform named ’Boryviter 0.1’ (Figure 4), which is described in detail in the work [25] and on the presentation page [51]. The platform is built based on a 32-bit Atmel ATSAMV71 microcontroller (Figure 4), which belongs to the ARM Cortex M7 microcontroller family [17] and operates under the control of the FreeRTOS Open Source Real-Time Operating System (RTOS).

The chosen ATSAMV71 microcontroller has three low power-saving modes: Sleep, Wait, and Backup.

In the ’Sleep’ mode, the processor core stops, and all other functions, that is, DMA and peripheral digital automates, can work. The sleep mode best balances the power consumption of external events and the response time.

All clocks and functions are stopped in the ’Wait’ mode, but some peripherals can be configured to wake up the system according to predefined conditions. This feature, called “SleepWalking”, performs a partial asynchronous wake-up, allowing the processor to exit sleep mode only when needed. A 32-bit low-power real-time timer (RTT), real-time clock (RTC), and wake-up logic work in ’Backup’ mode. In addition, in this mode, the device can meet the most stringent key-off requirements when the system or device is powered off. However, the microprocessor continues to operate with some activity level, storing 1 Kbyte of SRAM. The system clock has been designed to support different clock frequencies for selected peripherals to optimize power consumption. In addition, CPU and bus clocks can be changed without affecting the operation of USB, U(S)ART, AFE, and timer counter.

Figure 4. The authors’ mission computer ’Boryviter 0.1’ (eng. Falco), developed by Falco.Engineering [51]

Figure 4. The authors’ mission computer ’Boryviter 0.1’ (eng. Falco), developed by Falco.Engineering [51]

Figure 5. A ’Boryviter 0.1" microcontroller ATSAMV71Q21

Figure 5. A ’Boryviter 0.1" microcontroller ATSAMV71Q21

The ’Backup’ mode achieves the lowest possible power consumption. This mode is quite good for applications where recurring and periodic tasks are to be executed, and the microcontroller sleeps the rest of the time. This is a good instrument for low-reliability or slow control systems and does not fit very well with the real-time tasks of the mission control computer. It is important to mention that the core state after return from backup mode is ’reset,’ which means that the specific software design patterns are to be used to construct an appropriate use of this mode.

In our work, we used some effective measurement techniques from [52] to measure time costs for such service operations as interrupt handling and thread-switching delays for virtual machines, which in our article was adapted for a microcontroller and RTOS setup. Given that FreeRTOS operates with the concept of Tasks and the interrupt handling exists within a context of parallel computation, which is largely independent of the scheduler operation, we adopted the mentioned architectural approach to our experiment needs.

3.2. Limitations and Assumptions

The following limitations and assumptions shall apply:

• The supply voltage of the microcontroller is nominal and equal to 3.3 Volts. It is the most reliable supply voltage for the electronics components on the mission computer and allows the best resistance to one-time failures and electromagnetic interference (EMI). There is a power consumption dependence over the supply voltage, but this is not the subject of this research;
• The priorities of the performed tasks are assigned according to the classical theory of Lew and Leyland, called RMS (rate-monotonic scheduling). In this case, each task ${\tau }_i$ periodic and characterized by two numbers:

  $${\tau }_i=\langle C_i,T_i\rangle ,$$

  (4)

  where $C_i$ - is the maximum time required for the task execution and $T_i$ is the repetition period of the task.
• A set of N tasks to be performed:

  $$T=\left\{{\cup }_{i=1}^N{\tau }_i\right\},$$

  (5)

  is always formed in such a way that they meet the sufficient condition of scheduling tasks of hard real-time systems formulated by Liu and Leyland [26]:

  $$\sum _{i=1}^N{\displaystyle \frac{T_i}{C_i}}\le N(2^{{\displaystyle \frac{1}{N}}}-1),$$

  (6)
• The limit on the size of the system tick, which determines the frequency of interruptions from the system timer, is obtained from the FreeRTOS documentation, taking into account the limitations of the MPLAB X IDE development environment for the Atmel ATSAMV71 microcontroller:

  $$T\in \{1ms,4ms\},$$

  (7)
• The limits on the microcontroller clock frequency are determined based on the technical documentation for the ATSAMV71 microcontroller, hardware clock configuration of the ’Boryviter 0.1’ mission computer and form the following set:

  $$f\in \{30MHz,100MHz,300MHz\}.$$

  (8)

3.3. Experiment Plan

Let’s define the ATSAMV71 microcontroller as a power-state machine with several operating modes: an active mode enabling software to make its main calculations and low-power modes turning off CPU peripherals and components (Figure 6). Dependencies on the clock frequency over the electrical power consumed by the microcontroller in possible power states and the time spent on transitions between them must be obtained based on the results of experiments. Such experiments are conducted in more detail in this article.

Let us divide all the necessary experimental dependencies and structure them into three classes:

• The dependence of energy consumption on frequency. Dependencies of the consumed electric power on the processor clock frequency N(f) must be determined for each operating mode m. The set of possible modes includes the active mode and power saving modes:

  $$m\in \{Active,Sleep,Wait,Backup\}.$$

  (9)
• Time spent by the operating system to perform functions related to rescheduling and dispatching tasks. These events could originate from forced software requests for rescheduling, system timer interrupts due to the next system tick, or external unplanned interrupt triggering OS synchronization facility – Mutexes, Semaphores, Event Groups, and Queues. Here are the definitions of the events identified for the experiment:

  (a)

  Forced software re-scheduling. The FreeRTOS taskYIELD() function is the basic function of cooperative dispatching. It immediately causes rescheduling, forcing the scheduler to check if another task is ready for execution. If such a task exists and has a higher or equal priority than the current one, a context switch to this task will be performed. Unlike external or system tick interrupts, taskYIELD() does not rely on hardware interrupts. Instead, it is a software mechanism in which the running task voluntarily yields execution, allowing other tasks to run. As a result, the taskYIELD() function represents a cooperative approach to multitasking, where tasks manage their own execution time, while external interrupts and system tick interrupts are part of a preemptive system where the OS can forcefully manage task execution based on real-time events and regular scheduling needs. The time required to perform the function is denoted by: $La{t}_Y\left(f\right)$;

  (b)

  System timer interrupt. The processor time spent processing interruptions from the system timer $IR{Q}_{Timer}$ depends on the clock frequency of the computing platform. It characterizes the operating system’s overhead for working in the preemptive multitasking mode. System tick interrupts occur regularly, triggering the OS to perform tasks such as updating the system time, managing the scheduling process, and potentially preempting the current task if necessary. The time required to perform the function is denoted by: $La{t}_T\left(f\right)$;

  (c)

  External or peripheral interrupt. The time of the system and call of the interrupt service routine (ISR) is the time from the moment of the occurrence of the external or peripheral interrupt to the time of execution of the first command of the interrupt handler. The time required to perform the function is indicated by $La{t}_{ext}\left(f\right)$. When an external interrupt occurs, the Interrupt Service Routine (ISR) handler or the first-level interrupt handler (FLIH) is triggered immediately. This mechanism forces the OS to temporarily stop the current process, handle the interrupt, and then return to the interrupted task or switch to a different task based on priority. It is important to mention that freeRTOS is a very low-footprint RTOS, and in reality, the context of the ISR handler and the rest of the RTOS context are not very closely coupled. In other words, the IRQ handling is like a regular blocking function with an asynchronous call and a primitive calculation context preservation that heavily leans on ARM Cortex M core capabilities.

• The time spent entering and leaving the low power mode (LPM): The time required to enter and leave a low-power mode will define how much energy can be saved and how bad system reactivity will be decreased. According to the power state-machine definition, two transitions shall be assessed:

  (a)

  Entering. As entering a LPM requires a specific amount of instructions - its time shall be properly measured. Only specific processor peripherals shall be shut off depending on the exact LPM. No memory preservation actions are required.

  (b)

  Leaving. The exit from an LPM requires more sophisticated actions. As some of the LPM modes shut off the internal frequency generator or switch it to the low-power one, a specific stabilization time is required before any processor instruction can be executed.

Thus, the independent factors of the experiment are the clock frequency and the operating mode, and the data that shall be obtained via the experiment are energy consumption, processor time spent on interrupt processing from the system timer, and the delay in the execution of the first instruction of the interrupt processing procedure. A complete factor experiment is planned, in which the factors take the following values:

$$f\in \{30MHz,100MHz,300MHz\},m\in \{Active,Sleep,Wait,Backup\}.$$

(10)

3.4. Measurement Technique

Typically, all power-saving measurements in modern microcontrollers require quite a comprehensive setup, as they require precise energy measurement, synchronized time-slice measurements, and an external disturbance generator.

For our experiments, the research bench (Figure 7, Figure 8, Figure 9 and Figure 10) was built with the following equipment:

• the square wave generator - GW Instek GFG-8219A that generates external interrupt signals with a given period;
• the high-precision power supply unit and power meter - Keithley 2281S-20-6 that measures the electric energy consumed. It guarantees the accuracy of the measurements (the measurement error of the time interval is no worse than 15 ms, and the error of the electric power measurement does not exceed 0.0001 W;
• the multi-channel storage oscilloscope - LeCroy WavePro 7200A provides the measurement of the time interval between two events: an externally generated interrupt signal from a square wave generator and the first command of the interrupt handler, which is a change of the state of a predefined port - Port 1, to the opposite. Since the command to change the port is atomic, that is, it is executed in one computing cycle in the RISC architecture, the time to change the state of the port can be considered insignificant;
• A hand-modified ’Boryviter 0.1’ mission computer where the oscilloscope is connected to the two GPIO outputs (via flying wires) and to the signal generator.

We had to design a more complicated measurement connection diagram for the second part of the measurements, entering the low-power modes. The key idea was to use the already soldered on a mission computer shunt resistor and operational amplifier to ensure that the proper scale and linearity of the current consumption are captured on the oscilloscope. So the connection diagram for the second test bench includes:

• The high-precision power supply unit and power meter - Keithley 2281S-20-6 was used to measure the electric power consumed;
• A multi-channel oscilloscope – Siglent SDS1204X-E measures the trigger event between the processor command “go to the low-power mode” and the current consumption response of the microcontroller;
• A modified ’Boryviter 0.1’ mission computer where the oscilloscope is connected to the output of the power-monitor operational amplifier, to ensure proper signal linearity and low noise.

The following connection diagrams were designed:

For the three classes of the dependencies defined above, the following measurement technique was used:

• To obtain dependencies of energy consumption on the frequency in the available modes of operation of the microcontroller in the stationary mode of operation, it is enough to set one of the four operating modes (Active, Sleep, Wait, and Backup) and record the electric power consumption by the Keithley 2281S-20-6 power measurement unit;
• Time spent by the operating system to perform functions related to the rescheduling and dispatching tasks is measured as follows:
  To estimate the pre-emptive dispatching time, we measured the execution time of the simple pre-defined calculation algorithm with the known execution time for each CPU frequency. For reliable results, a set of 1000 measurements were executed. It is expected that due to the overhead required for handling external interrupts and interrupts from the system timer, some iterations of the known algorithm will take longer. Suppose that the frequency of the external interrupt differs by one and a half to two times from the frequency of the system timer, and the execution time of one iteration is 20-30 percent of the value of the system tick. In that case, we will get the following dependence of the execution time on the iteration number (Figure 11). If the frequencies of interruptions (external and from the system timer) differ by 1.5-2 times, then it is very easy to distinguish their influence on the general graph: it is enough to count the number of measurements that got on the corresponding shelves.
  The results of measurements of the actual execution time of each iteration are distributed on four shelves, depending on whether the cycle was interrupted for processing interruptions. These shelves correspond to the following situations:
  • there are no interruptions;
  • an interrupt from the system timer occurred;
  • an external interrupt occurred;
  • the iteration was interrupted twice by the system timer and externally.
  The following algorithm was performed for each CPU frequency to estimate the cooperative dispatch time.
  The program first accumulates an array of data about the execution time of the mutex ’take’ operation. The FreeRTOS is configured to have only one single task, which blocks and releases the mutex, and then records the time required to perform these two operations in the array.
  In the second stage, several tasks are created, which block the mutex in a loop, record the time and task number in the logEntries shared array, release the mutex, and then call system function taskYIELD() to transfer control to other tasks. These tasks work in parallel, creating conditions for estimating the overhead of switching between tasks. A hardware timer measures the time of operations with a resolution equal to 66,66 ns. The logEntries array stores the execution time of the operations and the task number, which enables the analysis of the results after the program is executed.
  Conditional Transition between Stages: The second stage begins after completing the first one, ensuring the correctness of the accumulated data.
• The time spent entering and leaving low-power modes (LPM). According to the processor datasheet, the ’Wait’, ’Sleep’, and ’Backup’ modes require a specific microcontroller shutdown technique that, in return, requires a waiting loop to ensure that all peripherals are safely turned off. However, the ’Backup’ mode, as the most ’deep’ power saving mode, can be exited only if a processor resets. To measure it, it is necessary to apply external devices because when the processor is turned off, and the peripheral shut-off process has been initiated, it is impossible to get information on when exactly the core has stopped working. The time for the transitions [1], [3], [5] in Figure 6 can only be determined using an external oscilloscope since the program is not executed in energy-saving modes. In this case, the actual time of entering the low-power modes can be assessed by the drop in the supply current consumption and, thus, registered with the oscilloscope:
  • Step 1. The test software toggles the output GPIO port state. This allows to trigger the connected oscilloscope;
  • Step 2. Based on the triggered event of entering the LPM, the second channel of the connected oscilloscope, which is connected to the operational amplifier, registers the current consumption drop;
  • Step 3. By calculating the time difference between the triggered event in Step 1 and the current drop event in Step 2, the time required to enter an LPM is obtained.
  The exit time measurement technique for the transitions [2], [4], [6] in Figure 6 is also rather hard to do. Still, with the essence of having an external interrupt wake the processor up, it is pretty straightforward to measure the time difference between the external interrupt signal from the signal generator and the output pin toggle of the microcontroller.
  However, as the most ’deep’ power saving mode, the’ Backup’ mode can be exited only during a processor reset. For this specific case, the test software was modified so that the specific pin toggle was the first operation from the start of the software. The exit from the LPM heavily depends on the particular LPM and how it implements the microcontroller peripheral shutdowns. If the Sleep and Wait modes are relatively straightforward to measure, as both allow them to return to the ’before the LPM’ computation context, the Backup mode is more nontrivial. The exit from the Backup mode requires a RESET vector entrance, which means that the microcontroller software starts from scratch. This behavior requires a more complex software architecture for implementation and typically requires an external NVRAM that could be used as context memory.
  So, we used two different test software scenarios to measure exit from LPM modes. For both scenarios, the external interrupt from the signal generator was used. That signal triggers the connected oscilloscope to capture the GPIO pin toggle as the first operation after the microcontroller is ready to execute the next command on the program counter (PC).
  • Scenario 1 – Sleep and Wait modes:

    -

    Step 1. The wakeup source is configured to react on the external interrupt from the GPIO pin connected to the signal generator;

    -

    Step 2. The external signal generator is set to generate 10 Hz square pulses;

    -

    Step 3. The interrupt handler is done in a way that the first thing it does is the appointed GPIO pin toggle;

    -

    Step 4. The time difference between the rising edge of the square pulse from the signal generator and the rising edge at the output GPIO pin could be considered the wakeup time.

  • Scenario 2 - Backup mode:

    -

    Step 1. The wakeup source is configured to react on the external interrupt from the GPIO pin connected to the signal generator;

    -

    Step 2. The external signal generator is set to generate 10 Hz square pulses;

    -

    Step 3. As the microcontroller shall undergo a reset vector, the GPIO pin toggle was done as the very first operation in the main() function, right after the GPIO configuration. As the test software didn’t contain any major variables, the time for initialization of the “.bss” section can be neglected;

    -

    Step 4. The time difference between the rising edge of the square pulse from the signal generator and the rising edge at the output GPIO pin could be considered the wakeup time.

4. Results

4.1. The Dependence of Energy Consumption on the Operating Frequency

The platform’s power consumption depends linearly on the frequency at a fixed supply voltage (Figure 12). The constant, independent of the frequency of the processor energy consumption, is approximately 130 mW. The slope coefficients of the linear dependencies of the energy consumption on the frequency are shown in the figure. Using the low-power modes of the processor saves up to 60% of energy. This advantage is most noticeable when the processor is running at maximum frequency.

4.2. Time Spent by the Operating System to Perform Functions Related to the Rescheduling and Dispatching Tasks

The measurement technique is described in detail in Section 3.3, ’Time spent by the operating system to perform functions related to rescheduling and dispatching tasks.’ The summary Table 2 characterizes the main reactivity indicators of the operating system on the ’Boryviter 0.1’ platform. In addition to reactivity indicators, the table contains the results of measuring operations with a nonblocking mutex (’take’, ’give’).

Due to the specifics of the ARM Cortex-M computing architecture, which has two independent instruction counters: a full Program Counter (PC) and an "emulated" Link Register (LR), the computer demonstrates sufficiently high reactivity indicators. FreeRTOS effectively supports the ARM Cortex-M architecture, as it does not distinguish between interrupt handling and normal functions. It has been experimentally confirmed that with cooperative dispatching, the execution time of the function taskYield() does not depend on the number of tasks in the system, since the FreeRTOS OS implements the round-robin dispatching mechanism of queued tasks.

4.3. The Time Spent Entering and Leaving the Low Power Modes (LPM)

A typical oscillogram of the decrease in power consumption over time after execution of the command to enter the LPM is shown in Figure 13.

The following Figure 14 illustrates the measurement view of the delay in execution of the first command of the interrupt handler after receiving an external interrupt when the processor was in LPM mode.

Table 3 summarizes the results of the measurements of the integral indicators that characterize the practicality of using LPM modes for energy savings.

There are two main characteristics: wake-up delays characterize the time required for the processor to exit sleep mode fully, and the break-even time is the sum of the wake-up and transition to LPM delays, last characterizes the time required for the processor to transition from the active state to the sleep mode.

5. Discussion

The data presented above confirm the possibility of experimentally determining the following quantitative indicators characterizing the operation of the computing platform under the conditions of time and energy constraints that exist in the on-board avionics of the UAV:

• dependence of power consumption on clock frequency for active mode and low-power modes;
• overhead costs of the operating system to support multitasking, namely delays in the execution of operations of the scheduler and dispatcher of the operating system for the implementation of cooperative and preemptive dispatching;
• break-even and wake-up times when using low-power modes.

Practical application We will discuss the possibility of practical application of the results obtained. We consider the scenario when at the stage of designing both hardware and software of a mission computer of the UAV, there is the following need:

• to ensure that it is functioning energy-efficiently, i.e., spending only a minimum of electrical energy on its operation;
• to guarantee that the required amount of computational work will be completed within the established time frame;
• to ensure that the reaction time to external events will not exceed the established and required by the end-application (mission) limits.

Then, in the list of possible design solutions, one or both of the following must be selected:

• set the clock frequency of the processor, which will be sufficient to guarantee the specified limits;
• apply a software solution to enable one of the existing low-power modes.

Of course, the use of software algorithms to manage power-saving modes has undoubted advantages in terms of flexibility. Still, the possibility of determining the processor’s clock frequency is sufficient for practical use and should not be neglected.

We will not consider the ’Backup’ mode, as it requires a complete processor restart and is characterized by sufficiently large payback time requirements and a completely different software architecture to be applied.

Algorithms to design The results obtained make it possible to design algorithms and energy-saving mechanisms for the mission computer as a solution to the optimization problem. The optimization criterion is the minimum power consumption of the mission computer in various power-saving modes:

$$P\left(\eta \right)=min(P_{LF}\left(\eta \right),P_{Sleep}\left(\eta \right),P_{Wait}\left(\eta \right)),$$

(11)

where $\eta ={\sum }_{i=1}^N{\displaystyle \frac{T_i}{D_i}}$ is the relative cost of processor time sufficient to ensure real-time constraints;

$P_{LF}\left(\eta \right),P_{Sleep}\left(\eta \right),P_{Wait}\left(\eta \right)$ - energy consumption for the operation of the mission computer when applying the following approaches to energy saving: low-frequency mode (LF), software-defined transitions to ’Sleep’ and ’Wait’ modes with a return to active mode upon external/internal interruption.

Then, when using each of the low-power modes, the average power consumption will not be greater than during the continuous operation of the processor at the maximum frequency. The relative part of the energy savings $\left(\mu \right)$ for the three modes of energy savings depends on the processor load factor - $\eta$ and, in the case of an ideal mission computer, is calculated as $\mu =1-\eta$.

The linear dependencies of the consumed electric power for the real computer modes on the frequency can be summarized in the form of an equation:

$$N_m\left(f\right)=N_0+a_{m}f,$$

(12)

where the m modes take the following values: $m\in \{Active,Sleep,Wait\}$, and result as the following:

$N_0=120mWt,a_{Active}=1.07{\displaystyle \frac{mWt}{MHz}},a_{Sleep}=0.46{\displaystyle \frac{mWt}{MHz}},a_{Wait}=0.20{\displaystyle \frac{mWt}{MHz}}$ from the subsection 4.1 (see Figure 11).

So how much energy can we save? The relative part of the energy saved can be calculated for a real computer using the following equations.

$${\mu }_{LF}\left(\eta \right)={\displaystyle \frac{a_{Active}{f}_{max}(1-\eta )}{N_0+a_{Active}{f}_{max}}},$$

(13)

$${\mu }_{Sleep}\left(\eta \right)={\displaystyle \frac{f_{max}(1-\eta )(a_{Active}-a_{Sleep})}{N_0+a_{Active}{f}_{max}}},$$

(14)

$${\mu }_{Wait}\left(\eta \right)={\displaystyle \frac{f_{max}(1-\eta )(a_{Active}-a_{Wait})}{N_0+a_{Active}{f}_{max}}},$$

(15)

Figure 15 illustrates the results of calculating energy savings using energy-saving modes. Limiting the processor’s clock frequency at the design stage is the most beneficial if the system has excessive computing power. Flexible software-controlled methods for switching between ’Sleep’ and ’Wait’ modes do not provide such benefits. However, they have the key advantage of adapting to a specific situation onboard. Estimates of the reactivity of the system in different modes of operation and operating system overheads for multitasking support obtained in the article make it possible to consider overheads for operating system operations.

6. Conclusions

The main goal of this work is to develop and test the technique of experimental search for a compromise between the required reactivity of the real-time system of the mission computer of the UAV and the electrical energy consumption of it.

The technique was approved using the author’s computing platform ’Boryviter 0.1’, which is implemented on the ATSAMV71 microprocessor and operates under the control of the open operating system FreeRTOS. The platform is intended to be used in a dual-purpose UAV and nanosatellites of the CubeSat class. This technique is based on the system model. The system model is a power-state machine that comprehensively characterizes the relationship between energy consumption and reactivity. Next, we define three types of models that are needed to fill this system model. This depends on the clock frequency:

• consumed electrical energy in the active mode and power-saving modes of the on-board computer;
• time spent by the operating system to perform functions related to rescheduling and dispatching tasks. We have considered all three possible cases when the OS performs rescheduling and dispatching: cooperative dispatching, crowding out dispatching after an interrupt from the system timer, and external interrupts;
• time spent on entering the energy-saving mode and returning to the active mode after an external event (interruption) that requires the system to wake up.

Then we determined the measurement techniques to obtain the dependencies mentioned above.

As the work results, a generalization of the experimental results is presented, and quantitative estimates of the measured characteristics for the author’s computing platform ’Boryviter 0.1’ are provided.

We consider the following to be the scientific novelty of the work:

• The task of finding compromises between reactivity and power consumption of the on-board computer is formulated through a representation in the form of a system model - power state machine;
• The developed technique for measuring the time spent pushing dispatching after an interruption from the system timer and processing an external interruption allows you to quickly and accurately determine these costs;
• The proposed time measurement technique for cooperative dispatching is also fast and accurate; besides, it is well-scalable, as it allows us to figure out the system’s behavior with an arbitrary number of tasks.

As a practical result, the article substantiates the conclusion that using a real-time operating system (FreeRTOS) in the author’s computing platform, ’Boryviter 0.1’, fully meets the task of quickly adapting the computing context to changing external factors (like interrupt-driven UAV avionics signals) and the required volume of calculations.

A limitation of our work is a certain idealization of measurement modes when the influence of external factors was considered separately. For practical application, it is necessary to check the adequacy of the obtained mathematical dependencies in the case of a more realistic picture of the existence of many practical tasks inherent in a typical set of calculations when using UAVs. Such practical and real-time deviations could be connected both with the avionics faults, external signals arrival frequency, etc.

In addition to checking the adequacy of the mathematical models obtained, we plan to investigate the reactivity and energy consumption of our computing platform if the component-oriented framework F´ (F Prime) from NASA is used for the development of onboard software. We plan to use it to allow us to quickly develop and deploy the UAV and satellite mission computer software. Potentially, it can also be used for the software of other parts of the avionics. This framework has a relatively high entry threshold. However, it provides mechanisms for component-oriented development available in open access for reuse, facilitating the solution of common tasks.