cleopatre: open-source operating system facilities for - hal

HAL Id: hal-00542199https://hal.archives-ouvertes.fr/hal-00542199

Submitted on 1 Dec 2010

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

CLEOPATRE: Open-source Operating System Facilitiesfor Real-time Embedded Applications

Maryline Chetto, Thibault Garcia, Audrey Marchand

To cite this version:Maryline Chetto, Thibault Garcia, Audrey Marchand. CLEOPATRE: Open-source Operating SystemFacilities for Real-time Embedded Applications. Journal of Computing and Information Technology,University Computing Centre Zagreb, 2007, pp.131-142. <10.2498 /cit.1000806>. <hal-00542199>

https://hal.archives-ouvertes.fr/hal-00542199

https://hal.archives-ouvertes.fr

Journal of Computing and Information Technology - CIT 15, 2007, 2, 131–142doi:10.2498/cit.1000806

131

CLEOPATRE:Open-source Operating System Facilitiesfor Real-time Embedded Applications

Maryline Silly-Chetto, Thibault Garcia-Fernandez and Audrey MarchandIRCCyN, UMR CNRS 6597 / University of Nantes, France

In this paper, we present the facilities offered byCLEOPATRE, a new framework devoted to respond toreal-time application developers needs, more particularlyfor open-source environments. The optional componentsof the operating system library cover a large range ofneeds in terms of scheduling, synchronization, fault-tolerance and aperiodic task servicing. And we describesome results of a performance evaluation study focusingon overhead and footprint.

Keywords: real-time, operating system, open-source,scheduling, Linux, fault-tolerance

1. Introduction

In any intelligent control system, there are threehierarchical levels. The servo level involvesreading data from sensors, analyzing the dataand controlling electromechanical devices. Thetiming is critical and often involves periodictasks ranging from 1 Hz to 1000 Hz. At a higherlevel, orders like move mobile robot to positionA are issued but are not as critical as for the servolevel. Finally, at the highest level, tasks estab-lish a plan for a pre-defined time horizon. Atevery level of control, the problem of schedul-ing operations has to be considered. Gener-ally, scheduling will consist in the allocationof available resources (files, CPU, machines,vehicles. . . ) to operations or parts over timewith respect to specified constraints includingtiming constraints. At the servo-level, real-timeconstraints imposed on the tasks are specifiedby strict deadlines by which they need to be ful-filled. Real-time means getting the task doneon time and every time. This means that theprimary concern is not average response time,but worst-case response time.

So, the major goal in designing a real-time con-trol system is to ensure adherence to all thetiming constraints during the whole lifetime ofthe application in order to avoid a system fail-ure. To meet these timing requirements, coor-dination, scheduling, resource management andcontrol are functions that must be adequatelyimplemented with a multi-tasking and flexiblereal-time operating system (RTOS). Computercontrol systems are embedded in a large andgrowing group of products such as automotivevehicles, aircrafts, and industrial robots. A rea-son for designing an easy usable and completereal-time operating system is that the applica-tions are becoming increasingly more complexdue to the inclusion of more functionality.

This paper focuses on the description of a real-time library aiming to support the reactive layerfor control applications. We present CLEOPA-TRE, a highly configurable system providingthe means for the application designer to choosethe needed functionality in a library of open-source software components that provides real-time facilities. CLEOPATRE claims not to berestricted to any application area [1].

The library hides to the designer some of thecomplexity by providing a simplified interface.Furthermore, the library allows on-line modifi-cation of real-time parameters. This feature canbe used to adapt the computational requirementsof the real-time system at run time.

The software framework was developed as partof the French national R&D project CLEOPA-TRE. It is an offshoot of a larger project to

132 CLEOPATRE: Open-source Operating System Facilities. . .

develop open-source software dedicated to re-configurable robots. Section 2 deals with weak-ness of Linux as an open-source operating sys-tem for real-time applications and gives somebackground materials about RTAI, a real-timevariant of Linux. In Section 3, we discuss therequirements of an RTOS to be compliant with alarge panel of embedded applications which areproposed by the CLEOPATRE library. Thesereal-time facilities are described in Section 4.Section 5 reports evaluation results in termsof overheads and footprints, and Section 6 de-scribes a simple development example. Wesummarize the paper in Section 7.

2. Linux and Real-time

2.1. Real-time Concepts

The use of state-of-the-art real-time techniquesin planning and control applications is still rare.The lack of competence in real-time theoryamong engineers and the lack of commerciallyavailable tools are the major reasons for this.

Real-time systems can be classified into twomajor categories: hard and soft real-time sys-tems, depending on the consequences of a dead-linemiss. The deadline is derived from the latestpoint in time when a response to an event mustbe generated. Hard real-time systems are com-puter systems in which all task deadlines mustbe met. On the other hand, in soft real-timesystems, a number of deadlines can be missedwithout serious consequences. Real-time sys-tems must be able to handle not only periodictasks, but also aperiodic tasks. Periodic tasksare used to implement off-line pre-planned re-quests. While periodic tasks have hard dead-lines, aperiodic tasks may have soft, hard or nodeadlines at all.

When aperiodic tasks have hard deadlines, thegoal of the operating system is to allow the ex-ecution of aperiodic tasks without jeopardiz-ing the schedulability of hard periodic tasks. Itclearly comes that the scheduler is the centralelement of the operating system and must beflexible enough to cope with all task modelsand constraints.

2.2. Linux Features

Linux presence is rapidly increasing in advancedcontrol applications, replacing proprietary real-time operating systems. In fact, Linux is nowthe dominant operating system within the em-bedded market. The embedded 32-bit processormarket has over twenty timesmore deploymentsthan desktop computers, and scales awide rangeof applications from MP3 players to telecom-munication systems.

Linux initially attracts designers because it isfree to download, comes with full source code,and is compatible with a wide range of proces-sors. A detailed examination reveals a modulararchitecture, a user-friendly licensing, a world-wide support community, a reputation for reli-ability, a standard programming interface, freetools, and a mature, well-tested code base. Al-though these features are ideal for a large seg-ment of the embedded-system world, the lackof precise timing in response to external eventshas been the biggest weakness for real-time ap-plications.

The standard Linux kernel has been suitable forproviding the best average response time. AsLinux is loaded down, it gracefully degrades theperformance of all tasks. This is not acceptablefor real-time computing. For example, when aprocess calls a kernel service, such as the sched-uler or a device driver, this call disables inter-rupts and makes it impossible to preempt Linuxuntil the service completes execution. Like-wise, the stock Linux scheduler uses a fairnessalgorithm that guarantees even the lowest pri-ority process some CPU time, even though ahigher priority process may be waiting.

To deal with these problems andmake the kernelmore responsive, the Linux support communityhas devised patches and workarounds that de-liver deterministic performance. One approachhas been to add preemption points within thekernel to reduce process latency and still pro-tect critical code sections.

A second approach is to add a small real-timekernel to handle the high-priority tasks whileLinux runs as the lowest priority to schedulethe remaining, non-real-time tasks. This ap-proach delivers the best real-time performancebecause it doesn’t allow Linux to disable inter-rupts. RTLinux and RTAI (Real Time Appli-cation Interface) are two open-source projects

CLEOPATRE: Open-source Operating System Facilities. . . 133

that their developers based on the dual-kernelapproach [2] [3]. The response to this is to writea minimal RTOS, then run Linux as a back-ground task under the minimal RTOS.

3. CLEOPATRE Framework

3.1. Background Material on RTAI

The RTAI project began at the Dipartimento diIngegneria Aerospaziale del Politecnico di Mi-lano (DIAPM) about ten years ago. RTAI is aplug-in which permits Linux to fulfil some real-time constraints (few milliseconds deadline, noevent loss). It is based on a Hardware Abstrac-tionLayer (HAL). This concept is also known inWindowsNT. The HAL defines a clear interfacewhich exports some Linux data and functionsclose related to hardware (see Figure 1). RTAImodifies them to get control over the hardwareplatform. RTAI is basically an interrupt dis-patcher which mainly traps the peripherals in-terrupts and if necessary re-routes them to Linux(e.g. disk interrupts).

That allows RTAI real-time tasks to run concur-rently with Linux processes. It leads to simpleadaptation in Linux Kernel and easy RTAI portfrom version to version of Linux.

RTAI offers some services related to hardwaremanagement layer dealing with peripherals,scheduling and communication means amongtasks and Linux processes.

R T A I L i n u x

H a r d w a r e

R T A ITasks

L i n u xprocesses

Interrupts

Hardware Abstraction Layer

Figure 1. Basic principles of RTAI.

The scheduler of RTAI is in charge of distribut-ing the CPU to different tasks present in the sys-tem (including Linux). The scheduler makes it

elected the first highest priority task in a readystate. RTAI considers the priority 0 as the high-est priority and 0x3fffFfff the lowest, given toLinux.

With RTAI, the Linux Trace Toolkit [4] and theGNU debugger as helper development tools canbe used.

Nevertheless, it presents drawbacks which re-strict the fields of integration:1) the preemptive scheduler works with static

priorities,2) both aperiodic and periodic tasks can be used

but the priority of a periodic task bears norelation to its period,

3) deadlines are not used,4) resource access protocols and fault-tolerance

mechanisms are not present.

3.2. Motivations

Consequently, our approach in the CLEOPA-TRE project was first to add real-time capabil-ities to Linux, yet keeping all its existing ca-pabilities and second, to design an adaptive, re-configurable and extensible operating system infree open-source code. One of the most impor-tant reasons for us to choose Linux as the foun-dation of our project is due to the open sourcepolicy behind it that allows it to grow constantly.One of the key technological innovations inCLEOPATRE is the configuration system. Es-sentially, this enables CLEOPATRE developersto create their own application-specific operat-ing system and makes CLEOPATRE suitablefor a wide range of embedded uses. Configura-tion also ensures that the resource footprint ofCLEOPATRE is minimized as all unnecessaryfunctionalities and features are removed. Theconfiguration system also presents CLEOPA-TRE as components architecture. This providesa standardized mechanism for component sup-pliers to extend the functionality of CLEOPA-TRE.

3.3. Interfacing CLEOPATRE to RTAI

Our purpose was to enrich the real-time facili-ties of a Linux-based operating system, but wedid not want to reinvent the wheels. So we haveexploited the idea used by the operating system


community for structuring effective hierarchicaloperating systems consisting of different layersof operating systems. Such approach providesa flexible environment for sharing hardware re-sources among multiple operating systems.

In the CLEOPATRE framework, multiple pri-oritised domains co-exist simultaneously on thesame hardware where Linux is the lowest pri-ority domain and CLEOPATRE is the highestpriority domain which always processes inter-rupts before the RTAI domain (see Figure 2).Let us note that RTAI could be replaced by RT-Linux by adapting a single interfacing compo-nent. Several projects have pursued the samegoal such as the European IST project, OCERA(Open Components for Embedded Real-timeApplications), also initiated in 2002,which usesa similar approach and relies on RT-Linux ( seehttp://www.ocera.org/).

R T A IL i n u x

H a r d w a r e

R T A ITasks

L i n u xprocesses

Interrupts

Hardware Abstraction Layer

Cléopatre

CléopatreTasks

OS Abstraction Layer : TCL

Figure 2. Basic principles of CLEOPATRE.

To interface CLEOPATRE withRTAI, a specificLinux module has been created, namely TCL(Task Control Layer) which is an enhancementof the native RTAI scheduler. TCL providesan internal interface for the CLEOPATRE ser-vices. It is responsible for low-level mecha-nisms and data structures including generationof periodic events and lists of task descriptors.For example, TCLCreateType is a structure thatgathers all the parameters required to createtasks for any RTOS.

The CLEOPATRE library contains this specificmodule which is necessarily loaded to run aCLEOPATRE application. This module consti-tutes an OS abstraction layer which makes thelibrary of generic services since it is possible touse them with Linux through different versionsof RTAI or other kernel such RTLinux by only

adapting this software layer. Consequently, thisabstraction model makes it possible to integratenew real-time facilities and development tools,in a clear and efficient way.

Moreover, native RTAI applications still run un-der the CLEOPATRE environment, with a viewto keeping compatibility. RTAI is no longerneeded after the introduction of Cleopatre tasks.But it was decided to keep RTAI as a back-ground task which makes available a minimalset of functionalities for users. Cleopatre tasksand RTAI tasks may coexist whereas never in-terfering except for interrupts handlers whichnecessarily will require attention. Nevertheless,it is also possible and easy to manually convertRTAI C code to Cleopatre code.

4. Real-time Facilities of CLEOPATRE

4.1. Library of Components

Advanced sensor-based control systems are dy-namically reconfigurable. As a result, they re-quire many special features, including highlyadaptive schedulers which are currently notfound in classical real-time operating systems.Several features the authors have developed andimplemented as part of CLEOPATRE are pre-sented here. They are dispatched in multipleshelves of the library and provide selectablecomponents (see Figure 3).

Scheduling SynchronizationFault

ToleranceAperiodic task

servicing

OS Abstraction Layer : TCL

OverloadManagement

Cléopatre library

A p p l i c a t i o n

Figure 3. The CLEOPATRE framework.

We define a component as a piece of softwarethat brings some new functionality or feature atdifferent levels in some of the following fields:scheduling, fault tolerance, aperiodic task ser-vicing and overload management. A compo-nent is dynamically loadable, and runs in kernelspace. It is installed or uninstalled via the well-known insmod and rmmod Linux commands re-spectively.


4.1.1. Scheduling

One of the key aspects in real time systemsis concerning to the task scheduling policies.A strong work has been done during the lastyears in static and dynamic scheduling theory.Whereas static scheduling has been incorpo-rated in commercial operating systems due toits simplicity, dynamic scheduling has been rel-egated to a research framework. However, newadvances in scheduling theory and new applica-tions working with dynamic environments em-phasize its advantages.

It is well known that with dynamic priorityscheduling policies it is possible to achievehigher utilization levels of the system resourcesthan with fixed priority policies. In addition,there are many systems for which their dynamicnature makes it necessary to have very flexiblescheduling mechanisms, such as robotics sys-tems, complex control systems and multimediasystems, in which different quality of servicemeasures need to be traded against one another.

CLEOPATRE supports both static and dynamicpreemptive scheduling of real-time tasks in-cluding Deadline Monotonic (DM) and Earli-est Deadline First (EDF) [5] [6]. With DM,tasks with shorter deadlines are given higherpriorities, at design time. The DM priority as-signment is optimal meaning that if any staticpriority scheduling algorithm can meet all thedeadlines, then the DM algorithm can too. Aproblem with DM is that is does not supportdynamically changing periods.

With EDF, the task with the earliest deadlineis always executed first. When scheduling pe-riodic tasks that have deadlines equal to theirperiods, EDF has a utilization bound of 100%.That is, EDF can guarantee that all deadlinesare met provided that the total CPU utilizationis not more than 100%. So, compared to fixedpriority scheduling techniques likeDMschedul-ing, EDF can guarantee all the deadlines in thesystem at higher loading. Tasks may be pe-riodic or not and characterized by a deadlineless than or equal to the period. Programmersmay change from one scheduler to another inloading the corresponding component withoutinvolving recompilation.

4.1.2. Synchronization

Synchronization refers here to resource accesspolicy that is a set of rules that govern whenand under what conditions each request for re-source is granted and how tasks requiring re-sources are scheduled. Exclusive access to ashared resource is typically achieved with theuse of a semaphore.

Problems with semaphore designs are wellknown: priority inversion and deadlocks. Inpriority inversion, a high priority task waits be-cause a low priority task has a semaphore. Ina deadlock, two tasks lock two semaphores, butin the opposite order. Research has yielded so-lutions respectively based on non-preemption,priority inheritance and priority ceiling. Theclassical policies in CLEOPATRE use P and Voperations on a semaphore with an associatedqueue of waiting tasks for the resource and or-dered according to some selectable rule suchas FIFO or task priority. But to prevent frompriority inversion and deadlocks, the followingpolicies have been implemented and made com-patible with any fixed or dynamic schedulingstrategy:• The simplest way is to disable all interrupts

during critical sections which correspond toexecute the task holding a resource at thehighest priority. We call this protocol theSuper-Priority Protocol (SPP). This schemeis simplistic, but requires clever program-ming to keep the critical sections very brief.

• ThePriority InheritanceProtocol (PIP)man-dates that a lower-priority task inherits thepriority of any higher-priority task pendingon a resource they share [7]. This prior-ity change takes place as soon as the high-priority task is pended; it ends when the re-source is released. However, deadlocks maystill occur.

• The Priority Ceiling Protocol (PCP) is anextension of PIP to prevent both deadlocksand priority inversions [8]. The schedulingalgorithm will increase the priority of a taskto the maximum priority of any task waitingfor any resource the task has a resource lockon. Once a task finishes with the resource,its priority returns to normal.

CLEOPATRE users may opt for, either proto-cols that avoid synchronization anomalies and


guarantee predictability with high overheads in-cluding PCP, or less complex protocols that maylead to a non-deterministic behaviour, for ex-ample using the conventional semaphore-basedprimitives. Note that PCP and SPP are theonly synchronization protocols for which maxi-mum blocking times can be precisely evaluatedand inserted in an off-line test to verify feasi-bility of the application. That means that thechoice for a synchronization mechanism mustbe tuned in accordance with the application pro-file and requires attention especially for basicprotocols that involves unpredictable blockingtimes. However, as mentioned in Subsection4.2, Cleopatre provides a timeout mechanismwhich enables to properly cancel every runningtask when its execution time exceeds a giventime interval.

For the moment, only semaphore-based syn-chronization mechanisms are supported underCLEOPATRE, but doubtless, the shelf shall beenriched.

4.1.3. Fault-tolerance

The interactions between the computer controlsystem and the instrumentation are more andmore complex and the number of functions del-egated by the human operator to the computertool imposes to verify its functioning on the ex-actness of the results which it produces and onthe respect for the temporal constraints attachedto each of them.

Even when carefully designed a real-time sys-tem can be subject to disturbances which arethe effects of subtile errors in software coding,malfunctions in input channel. Moreover, esti-mating the execution time of tasks is often diffi-cult and under-estimating worst-case executiontimes can lead to deadline failure.

Consequently, it is necessary to provide anyreal-time operating system with techniqueswhich are able to make the results available ona timely basis even if this one leads to a func-tioning in degraded mode. This is a quality pre-required by the embedded real-time systems.

Fault-tolerance (FT) is achieved via time and/orspatial redundancy and hence its design metho-dologies are characterized by the trade-offbetween these two types of redundancy. Inreal-time environments, a fault-tolerance policy

should be selected and implemented to recoverfrom errors within a certain time limit.

In CLEOPATRE, we consider software redun-dancy and time redundancy strategies. Softwareredundancy means that the system will be pro-vided with different software versions of tasks,so that when a version of a task fails under cer-tain inputs, another version can be used. Withtime redundancy, the task schedule has someslack in it, so that some tasks can be rerun, pos-sibly with less precision, and still meet criticaldeadlines.

With the so-called Deadline Mechanism, eachfault-tolerant task is implemented as two dis-tinct tasks (primary and backup copy) [9]. Theprimary version produces good quality results,but its execution is prone to a timing failurebecause of its high level of complexity and re-source usage. The backup version, on the otherhand, only contains theminimum required func-tions and produces less precise, but acceptableresults in a time bounded interval. Since it issimpler and requires less resources, we assumethat its reliability has been fully tested a prioriand its WCET (Worst Case Execution Time)can be known. That is why a feasibility testbased on WCETs of backup tasks can be per-formed off-line in order to certify that, in themost degraded mode, all back-up tasks can befeasibly scheduled and the system is never over-loaded, even transiently.

Hence, whenever a primary copy tries to executefor an interval of time longer than its reservedexecution time, it is aborted and the scheduleris able to guarantee the execution of the backupcopy while meeting its timing constraint. Thebackup-copy provides a degraded performancesolution but never executes unnecessarily whenthe associated primary copy successfully com-pletes, and this by applying the so-called Lastchance strategy.

T1

T2

0 4 8

processor time reserved for backups

Time available forprimaries

Idletime

Figure 4. Static EDL schedule for backup copies.

In our implementation, the processor time re-served for the execution of the backup copy is


realized with EDL (Earliest Deadline as Lateas possible) algorithm and is reclaimed as soonas the primary task executes successfully (seeFigures 4 and 5). EDL is a dynamic slack steal-ing algorithm which consists of making spareprocessing time available for the primary tasksas soon as possible by stealing slack from thebackup tasks.

T1

T2 backup

primary

failure

success

failure

Figure 5. FT schedule with the Deadline Mechanism.

This technique, above all, is proving an efficientone for failure recovery in particular when ex-ecution times are under-estimated or when pro-gramming errors produce unbounded computa-tion times like infinite loops, leading to deadlinemissing.

4.1.4. Overload Management

Often, in a so-called dynamic or reconfigurablesystem, neither the number of tasks to be ex-ecuted on the processor nor the characteristicsof these tasks are known a priori, possibly lead-ing to transient overload. The method of Im-precise Computation (IC), introduced by Lin,Liu and Natarajan, is a flexible technique forthe design of such real-time systems [10]. Thetechnique is motivated by the fact that one canoften trade off precision for timeliness. It pre-vents missed deadlines and provides gracefuldegradation during a transient overload.

A task based on this model consists of two ormore logical parts: a mandatory part and atleast one optional part. The mandatory partshould include all the operations necessary toproduce a logically correct result. The optionalpart, on the other hand, refines the output of themandatory part within the limits of the availablecomputing capacity. Since the mandatory partshave hard deadlines, provisions should be takenagainst faults which may occur during execu-tion. That is why Imprecise Computation maybe used in conjunction with Fault-tolerance inCLEOPATRE.

4.1.5. Aperiodic Task Servicing

An aperiodic task server aims to schedule softand hard aperiodic tasks together with periodictasks. Whenever a hard aperiodic task occurs,an acceptance test is performed in order to verifythe feasibility of the resulting schedule. If theaperiodic task is rejected, a message is printed,and the application is informed via error codesso that it can react if necessary. Whenever asoft aperiodic task occurs, it is scheduled so asto minimize its response time. Soft aperiodictasks are served on a FCFS (First Come FirstServe) basis.

Three servers are available in the library: BG(Background server), EDL (Earliest Deadlineas Late as possible server) and TBS (TotalBandwidth Server) [11] [12]. EDL is based onthe dynamic Slack Stealing approachwhile TBSis based on the dynamic computation of a virtualdeadline for the aperiodic task. Both EDL andTBS have been proved optimal in the sense thatthey minimize the mean response time for thesoft aperiodic tasks and they maximize the ac-ceptance ratio for the hard aperiodic tasks whileguaranteeing that periodic tasks still meet theirtiming requirements.

An additional shelf of components called “Qual-ity of Service” is under development. It aimsat providing scheduling solutions for firm real-time applications [13] where missing deadlinesunder someprecise conditions is tolerated. Moreprecisely, it will enrich theCLEOPATRE librarywith enhanced scheduling components based onthe Skip-Over model [14].

4.2. CLEOPATRE Tool Set

The strength of CLEOPATRE lies also in a setof tools which are highly desirable for devel-oping real-time applications, but are not avail-able with the other RTOS. Following is a list ofthe advanced features implemented as optionalcomponents in the CLEOPATRE library:• A software automatic stop mechanism to

safely terminate applications even in emer-gency situations. This mechanism avoidsthat programming faults lead to a computercrash and keeps the integrity of the system.

• A watchdog mechanism to protect from infi-nite loops. At initialization time, the user can


specify a maximal duration during which atask can be executed. If the execution time ofa task exceeds this parameter, the real-timeapplication is automatically ended.

• A communication mechanism, namely KLI(Kernel Linux Interface) for data exchangesbetween user space and kernel space in orderto notably use the standard Linux interface.

• A simulation tool set able to generate in-terrupts. This tool can be used to simulateexecutions of periodic tasks as well as occur-rences of aperiodic events. It can be viewedas a debugging tool for CLEOPATRE com-ponents developers.

• And aspect-oriented programming interfacesto help tracing and debugging, with minimalintrusion.

4.3. Properties of the Library

The CLEOPATRE library is organized into sixshelves that contain the real-time services. TheCLEOPATREOff-the-Shelf components are op-tional except the OS abstraction layer (TCL)and the scheduler.

At most one component per shelf can be se-lected. Since all components of a given shelfhave the same programming interface, they areinterchangeable. Any component is inter-opera-ble with any other one. The only exception isthe Dynamic Priority Ceiling Protocol whichnecessarily is loaded with the Earliest Deadlinescheduler. For example, the user may select theEarliest Deadline scheduler and theBackgroundaperiodic task server to run with the overloadmanagement and fault-tolerance mechanisms.

Components are totally independent from thekernel and the hardware. Reusability of thecomponents with another hardware and OS ismade possible by just adapting the OS abstrac-tion layer in the TCL component. This compo-nent hides the specific features of each platform,so that the run-time components can be imple-mented in a portable fashion and adapt to thetarget’s processor architecture and board.

CLEOPATRE framework started from two ker-nels:• Linux kernel 2.2.14 with the addition of a

set of patches to improve the real-time be-haviour

• RTAI 1.3

Initial developments of CLEOPATRE relied ontheReal-TimeHardwareAbstractionLayer (RTHAL).Note that this conceptwas subject to theRTLinuxpatent, thus reassessing the open-source fea-tures of both RTAI and CLEOPATRE.

Nowadays however, CLEOPATRE frameworkis running underLinux/RTAI3.0 andLinux ker-nel 2.4.22, and is based on the ADEOS (Adap-tive Domain Environment Operating System)interrupt low-level mechanisms [15]. The com-ponents compliance was tested on the last freeRTLinux version too. Results showed the adapt-ability of the CLEOPATRE components in an-other environment. Experiments were confinedto the validation of the functional aspect of eachcomponent under RTLinux.

5. Implementation

5.1. License

CLEOPATRE is royalty and buyout free sincedistributed under the LGPL license which per-mits proprietary application code to be linkedwith CLEOPATRE without being forced to bereleased under the GPL license.

CLEOPATRE offers a lot of useful documenta-tion (User’s Guide, Programmer’s guide, andseveral articles) which are being continuallyupdated as the system develops. Everythingneeded to use and develop CLEOPATRE can bedownloaded from the web site of the CLEOPA-TRE project:http://cleopatre.rts-software.org/.

5.2. Accessibility

Success of real-time systems comes from bothease of use and performances. Writing code torun with CLEOPATRE is as simple as writing aC language program to run under Linux.

The name of every CLEOPATRE primitive iscomposed of two words separated by “.”. Thefirst word identifies the component which theprimitive belongs to and the second one iden-tifies the primitive. For example, TCL.beginrefers to the primitive, named begin in the TCLcomponent.


Our aim was to define an API which is com-patible with the largest possible set of compo-nents on a given shelf. This API is partly com-pliant to the POSIX standard. While POSIXis a very recognized standard API, it does notpermit to implement all scheduling and fault-tolerant strategies. So, partial compliance withPOSIX and its real-time extensions is the priceto pay for permitting both total interoperabil-ity between components and extensibility of thelibrary.

5.3. Overheads and Footprints

5.3.1. Performance Evaluation

To get an idea of the performance of CLEOPA-TRE, several critical operating system featureswere timed. The timings shown hereafter wereperformed on a 1,7 GHz Pentium 4 with theTime Stamp Counter (TSC), available with ev-ery modern Intel processor. The performancehas not been yet evaluated on other targets.

A task can be created in 1.7μs, and destroyedin 0.36μs. These operations are generally doneduring initialization and termination, and notduring time critical code. As a result, perfor-mance of these routines is sometimes sacrifised,in favour of performing any computations be-forehand, so that the performance of run-timeoperations, such as context switching, can beimproved.

One of the important performance criteria of amultitasking kernel is the reschedule and con-text switch time. Upon the expiration of a timequantum, a timer interrupts is generated, forc-ing a time-driven reschedule. If the currentlyrunning task has the highest priority, it remainsrunning, and the timer interrupt results in notask swapping. The scheduling time in this caseis 96 ns, resulting in a peak CPU utilizationof 99.84 percent with a one millisecond timequantum.

At the other extreme, a full context switch isneeded, which executes in 120 ns (note thatthis measurement does not include the storingand restoring of FP registers), thus providingminimum CPU utilization of 98.8 percent. Thescheduling time includes updating dynamic pri-orities, and selecting a new task if the highest

priority task changes. A full context switch in-volves suspending the current task by saving itsentire context, and resuming the new task byrestoring its entire context.

5.3.2. Footprints

CLEOPATRE kernel is effective and consumesa minimal memory footprint because allowingto load dynamically only the required compo-nents.

Table 1 shows that a CLEOPATRE component,when loaded in memory (by the insmod com-mand) has a size approximately 33% lower thanthat on the hard disk. This phenomenon ismainly due to the information which is con-tained on the disk and used by Linux to dynam-ically assemble the interfaces of the componentsat the loading stage.

Mechanism ComponentHard disksize (KB)

Memorysize (KB)

Minimal RTAI RTAI 27,2 23Interfacing TCL 34,8 27,1

Centralscheduling

DDMDEDF

3,13,1

2,12,1

Aperiodic taskservicing

BGSEDLTBS

4,219,73,4

2,915,22,6

Synchronization

FIFOPRIOSPPPCP

DPCP

1,81,81,53,64,3

0,81,00,62,32,9

Fault tolerance FT 4,9 20Overload

management IC 2,5 1,3

Table 1. Footprints of CLEOPATRE components.

We also show that the minimal footprint of theCLEOPATRE system is 30 KB in memory (38KB in hard disk), excluding RTAI and necessar-ily including the interface and the central sched-uler. CLEOPATRE can then be easily stored ona floppy disk or a compact flash memory.

6. Integration

The following example brings to light some ofthe features of CLEOPATRE and shows the dif-ferent steps in developing under the CLEOPA-TRE environment. The application, which is


only an academic one for simplicity, aims tocount the number of interruptions which aregenerated by the mouse.

T1

T2

V V+1

V=324 V=326

Mouse interrupts

V V+1

Figure 6. General view of the example.

In this example, an interrupt handler is tied tothe mouse signal and releases aperiodic task T2.T2 keeps up to date variable V that contains thenumber of interrupt occurrences. Periodic taskT1 reads V and displays it every second. Ac-cess to V is protected by a mutual exclusionsemaphore.

6.1. Source Code

To compile the application, a programmer needsto include headers of all required components.

/* —– Components interfaces —– */

#include <TCL.h> /* Task Control Layer */#include <Dsch.h> /* Scheduler */#include <sem.h> /* Semaphore */#include <irq.h> /* Interrupt management */

Parameters are declared with #define directives.

/* —– Parameters —– */

#define TIMERTICKS 1e6 /* Timer period: 1ms */#define irq twelve 12 /* Mouse interrupt */#define HEAP 0 /* Heap size */#define STACK 2000 /* Stack size */#define NO FPU 1 /* 0 to use FPU */

Descriptors for tasks, semaphores and interruptsare declared as global static variables.

/* —– Descriptors —– */

static DSchTaskType t mouse; /* Tasks */static DSchTaskType t report;static irqType irq mouse; /* Interrupt */static SemType sem; /* Semaphore */

/* —– variables —– */

static unsigned v; /* number of mouse interrupts */static unsigned i=0; /* number of printings */

Infinite loop and explicitwait next period primi-tive are not required to implement a periodictask in the CLEOPATRE environment, in con-trast of most RTOSes, which results in moreconciseness.

/* —– Periodic report task —– */

void report() {sem.P(&sem); /* semaphore locking */print("report %4i: %u\n",++i,v);sem.V(&sem); /* semaphore unlocking */}

Similarly, a semaphore is not required to releasean aperiodic task.

/* —– Aperiodic count task —– */

void mouse() {sem.P(&sem);v++;sem.V(&sem);}

CLEOPATRE real-time handlers begin with themacro-command IRQ begin and terminate withIRQ end. These macro-commands protect han-dlers from multiple interrupts during their ex-ecution and give hand to Linux handlers ifneeded.

The following handler just releases the aperi-odic task.

/* —– Interrupt Handler —– */

void handler() {IRQ begin(&irq mouse);Dsch.wakeup(&t mouse,TCL.time);IRQ end(&irq mouse);}

Linux runs the init module() function that ini-tializes tasks, semaphores, interrupt handlersand starts running in real-time mode.

/* —– Application initialization —– */

int init module(void) {/* O.S. Abstraction Layer parameters */TCLCreateType creat= {HEAP,STACK,NO FPU,0};/* Initializations: Tasks, semaphore, interrupt */Dsch.create(&t report,report,1000,1000,creat);Dsch.create(&t mouse, mouse, 0, 0,creat);sem.create(&sem,1);IRQ.create(&irq mouse, irq twelve,handler);

/* periodic task start */Dsch.wakeup(&t report,1000);

/* Real time mode */TCL.begin(TIMERTICKS,20);

return 0;}

Cleanup module() function is executed whenunloading. TCL.end() function safely deletesevery object initially declared by init module().


/* —– Application deletion —– */

void cleanup module(void) {TCL.end();}

6.2. Results

This application enables us to state that, on av-erage the mouse generates 300 interrupts persecond. But, this result is not as important asthe way to get it. The main objective of thisbasic example was to give an overview aboutprogramming under CLEOPATRE.

7. Conclusion

The word “real-time” is defined as follows:the ability of the operating system to providea required level of service in a bounded re-sponse time. The real-time functions includenot only guarantee of worst case but also beinglightweight, small footprint, high speed and soon.

CLEOPATRE is a portable, open-source, freeto download and royalty free RTOS that canbe used in commercial applications through theLPGL license. It can be viewed as an “a la carte”kernel that provides system software compo-nents, allowing for a wide variety of services.Developers can reduce their time to market byusing CLEOPATRE as a debugging tool duringdevelopment as well as using its services in thefinal product deployment. CLEOPATRE ap-plications are highly portable to any new CPUarchitecture thanks to its OS abstraction layerwhich makes the library of services generic.

We have proved the applicability and interop-erability of the components, first by simulationtests and then by integration. CLEOPATRE hasbeen used with several different systems, both atNantes University in a mobile robotic applica-tion and elsewhere, including at the LRV Labo-ratory (Laboratoire de Robotique de Versailles)to realize a real-time vision system and to con-trol a redundant manipulator with 7 degrees offreedom [16].

Current works aim at completing the function-alities of the library with scheduling facilitiesthat consider Quality of Service requirements.

8. Acknowledgment

The CLEOPATRE project was supported by theFrench Research Office, grant number 01 K0742. We would like to thank all partners ofthis project.

References

[1] T. GARCIA, A. MARCHAND, M. SILLY-CHETTO,CLEOPATRE: A R&D project for providing newreal-time functionalities to RTAI Linux. 5th RealTime Linux Workshop (2003), Valence, Spain.

[2] V. YODAIKEN, The RTLinux Approach to Real-Time. FSMLabs Inc., (August 2004).

[3] P. MANTEGAZZA, DIAPM RTAI for Linux: Why’s,what’s and how’s. Real Time Linux Workshop,(1999), University de Technology of Vienna.

[4] B. B. RAMYA, V. PAVITHRA, B. THANGARAJU, Pro-cess Tracing with the Linux Trace Toolkit. SysAdmin magazine, (2004).

[5] N. C. AUDSLEY, Deadline monotonic scheduling.Report YCS.146, (1990), Dept. of Computer Sci-ence, University of York.

[6] C. LIU, J. W. LAYLAND, Scheduling algorithms formultiprogramming in a hard real-time environment.Journal of ACM, (1973), 20(1) pp. 46–61.

[7] L. SHA, R. RAJKUMAR, J. P. LEHOCZKY, Priorityinheritance protocol: An approach to real-timesynchronization. IEEE Transactions on Computers,(1990), 39(9), pp. 1175–1185.

[8] M. I. CHEN, K. J. LIN, Dynamic priority ceilings:a concurrency control protocol for real-time sys-tems. Real-time systems journal, (1990), 2(4), pp.325–346.

[9] H. CHETTO, M. SILLY-CHETTO, An adaptivescheduling algorithm for a fault-tolerant real timesystem. Software Engineering Journal, (May 1991),6(3), pp. 93–100.

[10] J. W. S. LIU, J. K. LIN, S. NATARAJAN, Schedulingalgorithms for multiprogramming in a hard real-time environment. Proceeding of the 8th real-timesystem symposium, (December 1987), pp. 252–260,San Francisco, CA.

[11] M. SILLY-CHETTO, The EDL server for schedulingperiodic and soft aperiodic tasks resource con-straints. The journal of real-time systems, Kluweracademic publishers, 17 (1999), pp. 1–25.

[12] G. C. BUTTAZZO, F. SENSINI, Optimal Deadline As-signment for Scheduling Soft Aperiodic Tasks inHard Real-Time Environments. IEEE Transactionson Computers, (1999), 48(10), pp. 1035–1052,ISSN:0018-9340.


[13] A. MARCHAND, M. SILLY-CHETTO, RLP: EnhancedQoS Support for Real-Time Applications. In Pro-ceedings of the 11th IEEE International Conferenceon Embedded and Real-Time Computing Systemsand Applications (August 2005), Hong-Kong.

[14] G. KOREN, D. SHASHA, Skip-Over algorithms andcomplexity for overloaded systems that allow skips.In Proc. of the 16th IEEE RTSS’95, (1995) Pisa,Italy.

[15] K. YAGHMOUR, Adaptive Domain Environment forOperating Systems. Opersys Inc., (2001).

[16] A. DE CABROL ET AL. , Video rate color regionsegmentation for mobile robotic applications. Proc.of SPIE, Applications of Digital Image ProcessingXXVIII, (2005), Vol. 5909.

Received: February, 2006Revised: June, 2006

Accepted: July, 2006

Contact addresses:

Maryline Silly-ChettoIRCCyN, UMR CNRS 6597

Research Group on Real-time systems1, Rue de la Noe – Nantes, France

e-mail: [email protected]

Thibault Garcia-FernandezIRCCyN, UMR CNRS 6597

Research Group on Real-time systems1, Rue de la Noe – Nantes, France


Audrey MarchandIRCCyN, UMR CNRS 6597

Research Group on Real time systems1, Rue de la Noe – Nantes, France


MARYLINE SILLY-CHETTO is a Professor at the University of Nantes,France. Her research is conducted in the Group of Real-time systems ofthe Research Institute of Communications and Cybernetics (IRRCyN).Her area of interest includes scheduling and fault-tolerance in real-timesystems. She has published more than 60 journal articles and confer-ence papers in the area of real-time operating systems. She has beenthe leader of a French national R&D project, namely CLEOPATRE,supported by the French government, which aims to provide free opensource real-time solutions.

THIBAULT GARCIA-FERNANDEZ is an Assistant Professor at the Univer-sity of Nantes, France. His research field is real-time operating systems.In 2005, he received the PhD degree in Computer Sciences from theUniversity of Nantes.

AUDREY MARCHAND graduated in Computer Engineering from theEcole polytechnique of the University of Nantes (France), in 2002.She is currently a PhD student at the University of Nantes. Her researchinterests include scheduling theory and quality of service for real-timesystems, and Linux-based real-time operating systems.

cleopatre: open-source operating system facilities for - hal

Documents