A Methodology for Customization of a Real-Time

2021 IEEE XXVIII International Conference on Electronics, Electrical Engineering and Computing (INTERCON) | 978-1-6654-1221-6/21/$31.00 ©2021 IEEE | DOI: 10.1109/INTERCON52678.2021.9532670

Operating System for Embedded Systems

Luiz Rubens Lencioni Denis S. Loubach Osamu Saotome
Department of Computer Systems Department of Computer Systems Electronics Engineering Division
Aeronautics Institute of Technology, ITA Aeronautics Institute of Technology, ITA Aeronautics Institute of Technology, ITA
São José dos Campos, SP, Brazil São José dos Campos, SP, Brazil São José dos Campos, SP, Brazil
[email protected] [email protected] [email protected]

Abstract—There is a considerable availability of real-time available, there are boundaries in these parameters usage that
operating systems (RTOS) for embedded systems in the market, prevent their full employment by the applications previously
from commercial to free and open source types of software mentioned, and then a customization effort might be needed.
licenses. Nevertheless, not all of them accomplish application-
specific requirements as they are provided. In that case, a Given this scenario, we propose a methodology to guide
customization effort is often required. In this paper, we propose application-specific RTOS customization. At first, project re-
a generic methodology to guide embedded systems designers to quirements are regarded, and a candidate RTOS from a list is
customize a chosen RTOS to meet design constraints, such as selected. Next, predefined steps must be followed and the cus-
reduced memory footprint layout and static memory allocation tomization feasibility is assessed. At the end of the proposed
of kernel objects. An illustrative reduced example is provided,
applying different candidate RTOS through the methodology, and workflow, the customized RTOS is presented together with a
the results are analyzed. set of configuration options and source code files. Our cus-
Index Terms—Real-Time Operaring Systems (RTOS), Embed- tomization methodology does not require special techniques
ded Systems, Application-Specific RTOS. nor modeling languages throughout the entire process.
I. I NTRODUCTION II. R ELATED W ORK
Real-time operating systems (RTOS) design has evolved There have been several studies to implement application-
since the ’70s. In recent years, state-of-the-art architectures specific RTOS over the past decades. In [7], a highly config-
have been developed to explore advances in memory inno- urable RTOS based on aspect-oriented programming (AOP) is
vations, energy efficiency, and multicore processing of em- presented. An approach using RTOS modeling is introduced
bedded systems [1]. Besides providing resources for both in [8] using a finite state machine (FSM) for an OSEK/VDX-
time and space task scheduling, they also offer a variety of based RTOS. A newer model-based approach is proposed in
optional services, such as a communications protocol stack [9]. In recent years the automotive industry has leading RTOS
and file management systems. Nowadays, there are dozens of customizations studies, due to the AUTOSAR-OS require-
RTOS available, prepared to be ported onto different hardware ments [10]. A similar proposal to our work can be found in
platforms. They range from commercial solutions, qualifiable [11], however, only open source RTOS were analyzed.
towards safety-critical standards, as DO-178 (e.g. VxWorks,
QNX Neutrino, and Integrity), to no-fees, open source pack- III. P ROPOSED METHODOLOGY
ages (e.g. FreeRTOS, Linux with real-time patches [2]). A. Overview
At the same time, trends in computer architecture such An overview of the proposed methodology is illustrated in
as domain-specific architectures (DSA) [3] have brought new Fig. 1. The main steps are illustrated inside the dashed line.
challenges like heterogeneous computing nodes dedicated to
particular functions. In the automotive industry, the automotive
software architecture (AUTOSAR) standard [4] requires a
statically configured RTOS. There, tasks configuration should
be performed during compile time and remain unchanged
during runtime, for predictability and safety reasons [5].
Moreover, in competitive sectors as consumer electronics
and internet of things (IoT), the need to fulfill stringent
embedded systems constraints, as cost and energy savings, can
lead to a design solution employing a microcontroller with
a limited memory footprint and a single-core processor [6].
Although in well-established RTOS configuration options are Fig. 1. Proposed methodology overview.

978-1-6654-1221-6/21/$31.00 ©2021 IEEE

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on September 23,2021 at 00:36:13 UTC from IEEE Xplore. Restrictions apply.
 Application requirements or hardware resource constraints
are used as inputs, such as the target processor, maximum
code memory size, specific set of inter-process communi-
cation (IPC), and compatibility to legacy software versions.
There can be two different outputs, depending on whether
the RTOS customization can or cannot meet the input ap-
plication requirements. In case of positive confirmation, the
resulting application-specific RTOS can be cross-compiled and
implemented into the target hardware. Otherwise, a negative
response from the workflow means that no candidate RTOS
(from the list of candidates) was able to pass through the RTOS
selection phase, or could not be customized. In that case, a
review of the input requirements might be necessary, or an
alternative in-house RTOS solution should be designed [12].
B. List of Candidate RTOS
An internal list of candidate RTOS needs to be created,
maintained, and constantly updated. It should be organized in
an orderly fashion. For instance, this order can be based on
RTOS availability or popularity in different industry sectors,
e.g. avionics, medical, automotive. There are specialized em- Fig. 2. RTOS selection sub-steps.
bedded systems publications that can be used as a source of
information, as they conduct market surveys and report RTOS
currently in use by several applications [13]. 4) Software License Evaluation: The software license type
must be analyzed in detail, as often the same RTOS offers
C. RTOS Selection Step different levels of licensing arrangements. For the sake of
This initial step in the methodology has the objective to simplicity, this work classifies RTOS licenses into only two
select the most adequate RTOS candidate. This evaluation is different groups: commercial and open source.
made under guidance criteria given by a set of application a) Commercial: It refers to proprietary and non-free
requirements, such as: software license types, where no rights are granted for source
• Budget availability: if cost is a critical constraint, a no- code customization (i.e. even if the source code is provided
fees RTOS should be chosen; by the software vendor, it cannot be redistributed).
• Target processor: it can narrow candidate RTOS , as some b) Open source: It relates to open source and free soft-
have limited board support package (BSP) options; ware license types [14], where the source code is entirely avail-
• Backwards compatibility: legacy code developed in pre- able, can be modified, and further redistributed. Some licenses
vious RTOS, by the development team, can be taken into in this group are known as permissive BSD-style, allowing
account; for customizations and relicensing with minimum restrictions
• Memory footprint: also due to cost, memory layout (e.g. copyright and permission notice to be included in the
boundaries can be an important factor to consider; code or documentation). Others, as the GNU General Public
• Kernel objects allocation: for predictability reasons, some License (GPL), also known as copyleft, forbids proprietization,
safety-related standards can require kernel components to allow customizations, but imposes requirements for developers
be statically allocated (instead of dynamically allocated to provide their application source code, as the original GPL
during runtime); and license.
• Technical support: not only from the original developer Examples of candidate RTOS classified into different license
that released the RTOS, but also from the open source groups, based on their main license types, are shown in Table I.
knowledge shared through community forums.
The sub-steps related to RTOS selection are illustrated in 5) Study RTOS Configuration Options: This is an important
Fig. 2, and detailed as follows. sub-step especially for the commercial license group, as the
1) Customizable Requirements Verification: For each input
requirement, there will be a Boolean classification of whether TABLE I
it can be customizable according to this methodology. E XAMPLES OF CANDIDATE RTOS AND THEIR LICENCES TYPES .
2) Select Next Candidate RTOS: It picks up the next
candidate in the already ordered list of candidates. RTOS name License type License group
3) Decision on All Candidates Analyzed: This decision 1 QNX Neutrino Copyrighted Commercial
point avoids an infinite loop, in the case none candidate in 2 FreeRTOS MIT Open Source
3 µC/OS-III Apache 2.0 Open Source
the list passes through the selection.

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on September 23,2021 at 00:36:13 UTC from IEEE Xplore. Restrictions apply.
source code is mostly not available. Software vendors offer Rate Monotonic Analysis (RMA), taking into account blocking
vast documentation for tailoring RTOS for a specific use. time due to shared resources [16], can be verified as in (1).
6) Prepare RTOS Requirements Compliance Matrix: Based m
on the output of the previous sub-steps, a compliance matrix
X Cj Bm 1
+ ≤ U (m) = m(2 m − 1) , 1 ≤ m ≤ n (1)
for each selected RTOS should be prepared. It must state if j=1
Tj Tm
each requirement can or cannot be met.
where Cj is the worst-case execution time associated with
7) RTOS Complies With All Non-Customized Requirements
periodic task j; Tj is the period associated with task j; Tm is
Decision: The next sub-step can be triggered only if there
the period associated with task m; Bm is the longest duration
are requirements able to be customized. Otherwise, the next
of blocking that can be experienced by task m; and n refers
RTOS in the list of candidates should be evaluated.
to the number of tasks.
8) Customization Information: The requirements compli-
3) Source Code Modification: Should any requirement not
ance matrix and the configuration options for the chosen RTOS
be achieved and satisfied by simply applying a change in the
must be gathered to be used in the next step.
available configuration options, source code modification must
D. Customization Workflow Step be addressed.
The customization workflow step is illustrated in Fig. 3. 4) Meet Requirements: A final cross-check between the
Each sub-step is detailed next. customized RTOS and the application requirements must be
1) Identification of Modules and Objects: Each RTOS is done. If all requirements are met, the modified source code
based upon elementary building blocks [15]. The core module with the suitable configuration options can be cross-compiled
is known as the kernel, responsible for scheduling, shared and able to be debugged into the target hardware. Otherwise,
resources management and task communication, for instance. an alternative should be tried, such as developing an in-house
Some common elements in the kernel are the scheduler, tasks, RTOS.
semaphores, message queues, mailboxes, event handlers, and IV. I LLUSTRATIVE E XAMPLE
the task control block (TCB). Accordingly, these kernel objects
need a memory space to be stored and an application program- An illustrative example showing the applicability of our
ming interface (API) that provides access to operations to be methodology for customization of a real-time operating system
performed (e.g. task creation and messaging passing). Support is presented as a proof-of-concept. As a starting point, a set
modules to high-level functionalities can be ready to use, such of application-specific requirements for an optimum RTOS are
as a file system, device drivers, and networking protocols. shown in Table II. Also, we assume the list of candidate RTOS
To be scalable, generally, these non-essential modules can is already provided, as in Table I.
be switched off during compile time, especially in a RTOS Following the first sub-step in the RTOS selection step
based on microkernel architectures. A list of these modules showed in Fig. 2, customization feasibility for each require-
and objects must be built, based on manuals or even looking ment is performed. Since [Req.1] and [Req.2] deal with
directly at the source code. intrinsic costs and license grants, they cannot be customizable
2) High-Level Modeling: A mathematical model of the by this methodology. Next, QNX Neutrino is selected as it
scheduling algorithm to be employed is necessary to perform remains at the top of the list of candidates. Then, its license
an offline schedulability analysis. For instance, the extended terms are evaluated, suitable configuration options are studied,
and a requirements compliance matrix is prepared. Whereas
QNX Neutrino does not comply with all non-customizable
requirements (e.g. it has proprietary license policies), it must
not be forwarded to the next step within the methodology.
Thus, the evaluation process restarts and FreeRTOS is the
next candidate on the list. The requirements [Req.1] and
[Req.2] can be satisfied since FreeRTOS adopts a free of

TABLE II
E XAMPLE OF APPLICATION - SPECIFIC REQUIREMENTS .

ID Requirement description
[Req.1] The RTOS must not have license nor royalties costs.
[Req.2] The RTOS license must not hinder software proprietization.
[Req.3] The RTOS must employ a fixed-priority preemptive scheduler.
[Req.4] The RTOS must statically allocate task objects.
[Req.5] The RTOS must deny task creation after the scheduler is first
started.
[Req.6] The RTOS must have a BSP compatible with ARM Cortex-M0
Fig. 3. Customization workflow step. cores.

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on September 23,2021 at 00:36:13 UTC from IEEE Xplore. Restrictions apply.
 TABLE III In this example, FreeRTOS release 202012.00 was em-
R EQUIREMENTS COMPLIANCE MATRIX EXAMPLE FOR F REE RTOS. ployed. Although not explicitly mentioned, a subsequent phase
of debugging can take place. Ongoing maintenance is also an
ID Customizable? FreeRTOS
important point to consider, mainly to keep up with releases
[Req.1] No Compliant containing patches to kernel bug fixes.
[Req.2] No Compliant
[Req.3] Yes Compliant V. C ONCLUSION
[Req.4] Yes Compliant
[Req.5] Yes Not compliant In this paper, a new guideline to select and customize field-
[Req.6] Yes Compliant proven RTOS for embedded systems is proposed, requiring
no special techniques nor modeling languages. As future work,
the proposed methodology could be tested towards harsher ap-
charge and permissive MIT license option. Also, [Req.3] and plication requirements, such as adherence to POSIX standards
[Req.6] are met, as a fixed-priority scheduler is employed, and modifications in real-time scheduling algorithms.
and there are BSPs for ARM Cortex-M0 cores from different
R EFERENCES
IC companies. Furthermore, with the configuration option
configSUPPORT_STATIC_ALLOCATION enabled [17], static [1] T. Kuo, J. Chen, Y. Chang, and P. Hsiu, “Real-time computing and
the evolution of embedded system designs,” in 2018 IEEE Real-Time
allocation of kernel objects are allowed through a different Systems Symposium (RTSS), Dec. 2018, pp. 1–12.
set of API functions, and consequently, [Req.4] can be met. [2] F. Reghenzani, G. Massari, and W. Fornaciari, “The real-time linux
However, FreeRTOS allows the creation of tasks after the kernel: A survey on PREEMPT RT,” ACM Computing Surveys, Feb.
2019.
scheduler is running, and then it cannot comply with [Req.5] [3] D. Loubach, J. Marques, and A. Cunha, “Considerations on domain-
provided ”as is”. The resulting requirements compliance ma- specific architectures applicability in future avionics systems,” in 10th
trix for FreeRTOS is presented in Table III. Aerospace Technology Congress, Oct. 2019, pp. 156–161.
[4] AUTOSAR, Requirements on Operating System, 2018. [Online].
Although FreeRTOS cannot fulfill all the stated application Available: https://www.autosar.org/fileadmin/Releases TEMP/Classic
requirements, it does comply with all non-customizable ones, Platform 4.4.0/SystemServices.zip
and then can go on to the customization workflow step. As [5] K. T. G. Tigori, J.-L. Béchennec, S. Faucou, and O. H. Roux, “Formal
model-based synthesis of application-specific static RTOS,” ACM Trans.
detailed in Fig. 3, an identification of modules, files, and Embed. Comput. Syst., May 2017.
objects is conducted. The high-level model for schedulability [6] A. Levy, B. Campbell, B. Ghena, D. B. Giffin, S. Leonard, P. Pannuto,
analysis presented in (1) is also valid for this case. As it is P. Dutta, and P. Levis, “The tock embedded operating system,” in
Proceedings of the 15th ACM Conference on Embedded Network Sensor
classified as an open source RTOS according to Section III-C4, Systems. Association for Computing Machinery, 2017.
the next sub-step in the workflow is to modify its source code [7] D. Lohmann, W. Hofer, W. Schröder-Preikschat, J. Streicher, and
to comply with [Req.5]. The static task creation function and O. Spinczyk, “Ciao: An aspect-oriented operating-system family for
resource-constrained embedded systems,” in Proceedings of the 2009
information about the running state of the scheduler (an inter- Conference on USENIX Annual Technical Conference, 2009.
nal variable named xSchedulerRunning) are all contained [8] C. Dietrich, M. Hoffmann, and D. Lohmann, “Back to the roots:
in a single C-language file named tasks.c. A possibility to implementing the RTOS as a specialized state machine,” in 11th annual
workshop on Operating Systems Platforms for Embedded Real-Time
implement this modification is presented in Listing 1. If an applications (OSPERT15), 2015, pp. 7–12.
application function tries to create a task while the scheduler [9] R. M. Gomes and M. Baunach, “A model-based concept for RTOS porta-
is already running, a NULL pointer is returned, and the task is bility,” in 2018 IEEE/ACS 15th International Conference on Computer
Systems and Applications (AICCSA), Oct. 2018, pp. 1–6.
not created, as mandated by [Req.5]. Finally, the requirement [10] T. Toussaint, J.-L. Béchennec, S. Faucou, and O. Roux, “Using formal
compliance matrix for the customized FreeRTOS is reviewed. methods for the development of safe application-specific RTOS for
As it now meets all requirements the workflow is complete. automotive systems,” CARS 2015 - Critical Automotive applications:
Robustness & Safety, 2015.
Then, the output of the methodology consists of the modified [11] P. S. Berntsson, L. Strandén, and F. Warg, “Evaluation of open source
source code and needed configuration options able to get cross- operating systems for safety-critical applications,” Software Engineering
compiled to the target hardware. for Resilient Systems. SERENE 2017., pp. 117–132, 2017.
[12] T. D. Juhász, S. Pletl, and L. Molnar, “A method for designing and
Listing 1 implementing a real-time operating system for industrial devices,” in
C USTOMIZED CODE SNIPPET OF F REE RTOS T A S K S . C FILE 2019 IEEE 13th International Symposium on Applied Computational
Intelligence and Informatics (SACI), 2019, pp. 149–154.
TaskHandle_t xTaskCreateStatic( ... ) [13] AspenCore. 2019 embedded markets study. [Online].
{ Available: https://www.embedded.com/wp-content/uploads/2019/11/
TaskHandle_t xReturn; EETimes Embedded 2019 Embedded Markets Study.pdf
/* Code added to comply with [Req.5] */ [14] M. Manteghi, “Understanding open source and free software licensing
if(xSchedulerRunning == pdTRUE) mechanism: A close review of the alternative approach to traditional
{ notions of software licensing,” Social Science Research Network
xReturn = NULL; (SSRN), 2017. [Online]. Available: https://ssrn.com/abstract=3082313
} [15] Q. Li and C. Yao, Real-Time Concepts for Embedded Systems, 1st ed.
else USA: CRC Press, Inc., 2003.
{ [16] L. Sha, R. Rajkumar, and J. P. Lehoczky, “Priority inheritance proto-
/* Legacy code */ cols: an approach to real-time synchronization,” IEEE Transactions on
} Computers, vol. 39, no. 9, pp. 1175–1185, 1990.
return(xReturn); [17] FreeRTOS Reference Manual - API functions and configuration options,
} Amazon Web Services, 2017, version 10.0.0 issue 1.

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on September 23,2021 at 00:36:13 UTC from IEEE Xplore. Restrictions apply.