An OSEK-compliant RTOS for the C16x -

An OSEK-compliant RTOS for the C16x


Dr Andrew Coombes describes the challenge in using the RealogyReal-Time Architect real-time kernel and development tools to providea fully OSEK compatible environment.

OSEK/VDX is a set of standards for operating systems (OS) andrelated services. The drive to improve system interoperability andreduce development times has led to increasing use of softwareproducts based on these standards in automotive electronicsapplications.

The Infineon C16x family of 16-bit microcontrollers is a popularchoice in the automotive industry. This makes it an obvious candidatefor OSEK development support. However, in high-volume applicationssuch as automotive, any increase in processor loading or memory usagedue to additional OS overhead will impact on target system cost, andis likely to prove unwelcome.

The challenge for LiveDevices' engineers therefore, in the designof their Realogy Real-Time Architect real-time kernel and developmenttools, was to provide a fully OSEK compatible environment, without acostly increase in the resources required by the target system. Inparticular, it was important to provide a solution that did notrequire the use of off-chip memory.

The OSEK/VDX standard

The development of the OSEK/VDX standard was primarily driven bythe high recurring costs in the automotive industry of developing andre-developing ECU (Electronic Control Unit) software, particularlythe costs of non application-specific parts of the software. A set ofcommercial off-the-shelf products to do much of this nonapplication-specific work would allow ECU manufacturers to out-sourcenon-core work and so obtain overall cost reductions.

Another motivation was the incompatibility of inter-ECUcommunications: different manufacturers of ECUs use differentprotocols for passing information around an in-vehicle bus. Thevehicle manufacturer needs the ability to integrate a number of ECUsfrom various suppliers into a single network. It is also importantthat the manufacturer has as wide a choice of supplier aspossible.

The goals of OSEK/VDX are therefore to support portability andre-usability of software components across a number of projects. Thiswill allow vendors to specialise in 'automotive IP, where a vendorcan develop a purely-software solution and run this software in anyOSEK/VDX-compliant ECU. But to reach this goal requires detailedspecifications of the interfaces to each non application-specificcomponent, and so OSEK/VDX standards include an ApplicationProgramming Interface (API) that abstracts away from the specifichardware of the underlying target platform and the configuration ofthe in-vehicle networks.

Building an OS for the C16x

In this article, we will concentrate mainly on the major factorsthat we considered in the 'minimum-footprint' implementation of aReal-time Kernel compatible with the OSEK OS specification.

The specification defines four 'conformance classes' to allow theOS to be scaled to the application's demands. The basic conformanceclasses (BCC1 and BCC2) meet the demands of deeply-embeddedautomotive ECUs, whereas the two extended conformance classes (ECC1and ECC2) are designed to support high-end demands of systems such assatellite navigation where resource use (RAM, ROM and CPU time) isnot so critical.

The nature of the conformance classes is such that the higherconformance classes are supersets of the lower ones &endash; thismeans that an RTOS that implements the requirements of ECC2 couldalso satisfy the requirements of ECC1, BCC2 and BCC1. However, thespecification of the conformance classes was done in such a way thatan RTOS implemented specifically for a lower conformance class couldbe implemented much more efficiently than one aiming to 'cover allthe bases'.

Thus the Realogy Real-Time Architect OSEK-based solution for theC16x was initially designed to comply with the BCC1 conformance classof OSEK OS 2.1. Tailoring the Realogy Real-Time Architectimplementation to this specific conformance class has enabledLiveDevices to produce a solution that is ideally matched to the typeof applications targeted by the C16x family. Subsequent developmentshave extended Realogy Real-Time Architect to support otherconformance classes in a scaleable way, thus ensuring that pure BCC1applications only require a minimum level of resources.

The initial focus on the BCC1 conformance class, however, is farfrom the whole story in the design of a memory and processorefficient OSEK solution for the C16x. Running a commercial RTOS inthe resource-constrained environment typical of single chipautomotive applications, such as the C16x is used for may beconsidered to be impractical in some cases, due to the memory andprocessor overhead demands of a conventional RTOS.

Designing for efficiency

It may therefore come as a surprise to learn that an RTOS usingpreemptive multi-tasking can provide a way to improve anapplication's effective use of the CPU without incurring significantmemory overheads. In fact, with the right tool support, it ispossible for an RTOS to reduce total run-time cost while also makingapplication development and maintenance easier. There are three areaswhere using a preemptive RTOS offers benefits over a cyclicexecutive: avoiding the inefficiencies of a cyclic executive, theability to deal with sporadic events with a short latency and stillmeet deadlines, and the benefit of separating timing andarchitectural issues from the code.

Using a preemptive RTOS

The inefficiencies mentioned above occur because a cyclicexecutive works by executing all of its tasks at the same frequencyor at harmonics of some given frequency. In a real-time system, eachtask will have a frequency at which it must be executed in order tomeet the objectives of the system, and the frequency at which thecyclic executive runs will be the fastest of these frequencies (alsocalled the minor cycle). This typically results in a number of tasksbeing executed more frequently than is strictly necessary, resultingin wasted CPU time. This effect becomes even more pronounced whensporadic events with a short deadline need to be considered. If theresponse to an event is required within one minor cycle of the eventoccurring, even though the event might occur on average, once everyhundred cycles, every minor cycle needs to allow for this event tooccur. Compounded with this are the problems that are introduced whena single task needs to be split across several cycles (for example, atask that occurs once every 10 cycles, but requires 3 cycles worth ofexecution to complete).

This may result in a sequence of minor cycles, which differ insmall respects. If this is the case, these minor cycles areaggregated into a major cycle. An example of all of the above isshown in figure 1.

Figure 1: Cyclic executive with four tasks and an interrupt.Each major cycle consists of four minor cycles. Task t1 executesevery minor cycle, whereas t2 occurs every other minor cycle. Theexecution of t3 needs to be split over three minor cycles. Althoughthe interrupt (i1) can only occur once every hundred major cycles, itis necessary to assume that it could occur within any minor cycle(and therefore leaving time for it is necessary).

The preemptive design of ' Realogy Real Time Architect'sOSEK-based kernel makes it possible to address all of the aboveconcerns. Tasks can be executed at their natural frequency, ratherthan executing at some multiple of the major cycle. It isn'tnecessary to waste processing power allowing time for sporadic tasksthat won't happen most of the time. Nor is it necessary to introduceadditional structuring constraints in the system (for example,partitioning a task into three parts, so that the task fits into acycle). In fact, by exchanging a cyclic scheduler for RealogyReal-Time Architect, the user is able to save a large proportion ofCPU time that would have been wasted executing cyclic componentsineffectively. It also allows the removal of the code and data spaceoverheads of cyclic control structures.

So now we have addressed the problems of processor and schedulingefficiency. But what of memory usage? How can we minimise the impactof Realogy Real-Time Architect on precious memory space?

Single shot/single stack

The OSEK-based kernel component of Realogy Real-Time Architect hasbeen designed and implemented in such a way that it requires minimalmemory resources in order to implement a the priority basedpre-emptive multi-tasking environment described above.

The initial focus on a basic conformance class 1 (BCC1)implementation of OSEK OS permits the use of a single-shot executionmodel, which in turn enables the use of a single stack. This differsfrom the traditional RTOS model, in which the tasks need neverterminate, consequently each task needs its own permanent stackspace. The total stack required by such a system can be calculatedsimply by adding up the largest amount of stack space required byeach task and interrupt handler.

In the single shot model, stack space is only required while thetask is running and once the task terminates its stack space can bereclaimed. As a task can only ever be preempted by a task of higherpriority that must terminate before the original task can continue torun, all tasks can share a single stack. In the single shot modelrunning on a single stack, the stack requirements are proportional tothe number of unique priority levels in the system rather than thenumber of tasks.

By reducing the number of different priority levels in the system,the overall stack requirements can be reduced significantly. Byoptimising priority levels and exploiting the fact the single shotmodel enables a single stack it is possible to reduce RAMrequirements much closer to those of cyclic systems. This enables thebenefits of preemption to be enjoyed in systems where it was notpreviously possible without exceeding the on-chip XRAM provided bythe 16x family.

To illustrate the possible savings, consider a system with fourtasks: t1, t2, t3 and t4, where the priorities of the tasks rangefrom 1 (the lowest) for t1 to 4 for t4. If all tasks are fullypreemptive, the stack usage of the system is the sum of the stackusage for each of the tasks t1 to t4. However, if tasks t1 and t2 areboth defined as non-preemptive, t1 can never appear on the stack atthe same time as any other task, likewise t2 can never appear on thestack with any other task. Thus the stack usage of the system thenbecomes the maximum stack usage of t1 or of t2, or of the sum of t3and t4.

Fig 2

Improving memory usage with internal resources

In addition to the standard OSEK OS resource locking mechanism,Realogy Real-Time Architect offers support for the internal resourcesfeature from the forthcoming OSEK OS v2.2 standard. This allowsautomatic locking and unlocking of resources without any explicit APIcalls.

If a task is declared as using an 'internal resource' RealogyReal-Time Architect will automatically lock the specified resource(s)immediately before starting the task, and unlock the resource(s)directly after the task has exited. This means that during taskexecution all specified internal resources remain locked until thetask exits, thus preventing any other tasks that share the sameinternal resources from pre-empting the currently running task.

Internal resources offer the developer a mechanism to control taskpreemption that is more detailed than simply declaring tasks asnon-preemptive.

When declaring a non-pre-emptable task no other tasks are everallowed to pre-empt this task. This can introduce long blocking timesparticularly if the task was assigned a very low priority. Usinginternal resources instead allows the possibility of specifyingexactly the tasks that must never pre-empt each other, and thus avoidany unnecessary blocking. Any higher priority tasks that do not sharethe same internal resource are still allowed to pre-empt. Therefore,using internal resources defines logical groups of tasks that are notable to pre-empt each other.

Internal resources can be used in an application to reduce thenumber of preemption levels, thus reducing the amount of stack memoryrequired. If it is known that a system remains schedulable whencertain tasks do not pre-empt other tasks, you can use internalresources to achieve non-preemptive task execution. This isillustrated in the below diagram, which shows that even a largenumber of tasks can be fitted onto a small amount of stack space.

Fig 3

Improving memory usage with 16x interrupt grouping

Because there is flexibility in the interrupt priority level foreach vector, 16x applications can be tuned relatively late in theirlife-cycle to optimise the trade-off between response times and stackusage. The 16x prioritised interrupt handling provides, for interrupthandlers, the equivalent functionality of Realogy Real-Time Architectinternal resources for tasks. By grouping several interrupt handlersat the same priority, it is possible to make sure that their overallstack requirement is only the maximum of their stack usages and notthe sum total. The programmable arbitration order ('group level')among those interrupts provides fine control when several are pendingat one time. Within the same application, any interrupt handler thatmust pre-empt in order to meet its response time constraints can beawarded a distinct, high priority.

Real-Time Architect provides support for calculating the exactstack requirements of entire applications from the stack requirementsof individual tasks and interrupt handlers in the presence ofpreemption, internal resources and interrupt grouping.

The practical benefits obtained by using Realogy RTA can beillustrated by considering the processor and memory overheads for atypical benchmark application on the C167, as well as interruptlatency figures.

The data in the tables were obtained using an I+ME Evaboard C167v2.0. The clock frequency was 20MHz. Test code and data were locatedin off-chip RAM configured for zero wait states.

The example application is defined asfollows: There are 7 periodic and 3 sporadic tasks. Theperiodic tasks have periods of 10,10,20,20,40,80 and 80msrespectively. The sporadic tasks have a minimuminter-arrival time of 20ms. A single ISR is used to activatethe periodic tasks using the ActivateTask call. Where atarget supports more than one ISR, they are at the samepriority level if possible. There are 4 non pre-emptionlevels, implemented by autoresources.

Data Memory Usage


Code Memory Usage




StartOS (and any functions itcalls)






Stack usage (OS overheads)




Stack usage (total)




OS internals




Worst case CPU overheads in any 80msperiod) 1.422ms = 1.78%

Interval CPU times



ISR entry latency


Time from interrupt raised to executionof first instruction of ISR

ISR exit resume latency


Time to return from last instruction ofISR to the interrupted task

Task entry latency


Worst case time for task entry

Task exit latency


Worst case time for task exit

Counter tick


Time to call CounterTickXXX() per alarm from inside ISR

Activate call


Time to call ActivateTask() from inside ISR

OS lock time


Longest time interrupts are locked outdue to OS execution

The example application is defined as follows: There are 7periodic and 3 sporadic tasks. The periodic tasks have periods of10,10,20,20,40,80 and 80ms respectively. The sporadic tasks have aminimum inter-arrival time of 20ms. A single ISR is used to activatethe periodic tasks using the ActivateTask call. Where a targetsupports more than one ISR, they are at the same priority level ifpossible. There are 4 non pre-emption levels, implemented byautoresources.

This single stack/single shot execution model is the key to thehigh processor and memory efficiency of Realogy Real-Time Architect.However, to take full advantage of the savings offered by the singlestack approach, it is important to determine the overall stackrequirements for the entire application in advance. Fortunately, thetiming analysis tools provided as part of the Realogy Real-TimeArchitect development environment provides support for this.

This is a unique feature for Realogy Real-Time Architect, whichuses schedulability analysis, which is based upon an extended form ofDMA (deadline monotonic analysis). The most obvious feature of thesetools is to allow the developer to guarantee that all deadlines willbe met under all circumstances. This is clearly a powerful andextremely useful feature.

However, the analysis of Realogy Real-Time Architect is notlimited solely to showing this. The analysis also shows the amount ofslack in the system as a whole, or in individual tasks, allowing forprocessors to be run at different speeds and still meeting deadlines,or adding functionality to specific tasks.

One of the most interesting features is the ability toautomatically determine which tasks can be placed into non-preemptiongroups, thus reducing overall stack usage. Studies performed byLiveDevices over a wide range of systems show that, irrespective ofthe number of tasks in a system, systems rarely require more than 5preemption levels.

The timing analysis can be applied through the developmentprocess, from design verification based on a system model andestimates of processing time through verification of implementationto investigating scope for change (headroom) and practicality ofproposed enhancements or modifications.

The single-shot kernel technology offered by Realogy Real-TimeArchitect complements the 'maximum performance for minimum silicon'philosophy of the C16x microcontroller family, by extending theconcept to total system cost &endash; both hardware and software. Thesmall code footprint and cycle-optimising scheduler of RealogyReal-Time Architect provide the ideal development environment forautomotive applications using the resource-efficient C167architecture. Furthermore, being able to define the configuration ofthe application ahead of deployment allows further optimisation ofmemory usage.

Dr Andrew Coombes CEng, Product Development Manager, LiveDevices, aprivate UK-based company with sales and distribution offices in theUSA and Europe. Founded in 1997 as a spin-off from leading edgereal-time software development work with the Volvo Car Corporationfor the S80 saloon car project. LiveDevices has financial backingfrom venture capital firms and recently raised £9.2M indevelopment capital.

It has three product lines:

  • Realogy Real-Time Architect (OSEK OS based real-time kerneland scheduling analysis tools);
  • Embedinet (small footprint, fully-featured TCP/IP stack);
  • Embediserve (infrastructure services for embedded TCP/IPdevices).

Published in Embedded Systems (Europe) February2002

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.