Joscho.de

Towards portable embedded
automotive applications
by Dr. Jochen Schoof, 3SOFT
Combining OSEK/VDX
and a hardware
abstraction layer has
finally taken the devel-
opers where OSEK/VDX
alone promised to take
them but did not
succeed. Using this
package will be the nor-
mal approach in future.
termined and the system adapted to these.
highest priority task that is ready to run.
forming operating system and a widely accept-ed a hardware abstraction layer (HAL) makes it The most important resources of OSEK-OS are possible to write hardware-independent soft- tasks, events and alarms. For working with these OSEK/VDX. All other services primarily help to ware. Hardware-independent software has a an API is provided specially designed for small facilitate working with pre-emptable, concur- number of benefits. It decreases the costs of size. An API conforming with the current ver- rent tasks. The application is formed by sever- switching between architectures during devel- sion 2.2 of the standard has to provide about 40 al tasks which in some way need to coordinate opment. It facilitates the re-use of applications user functions. The API’s small size enables the their activities. They can be synchronized by or parts of them. And finally it makes it possi- developer to learn and use it easily.
means of events or resources. Tasks can wait for ble to easily run software in a simulated envi- events as well as cause them. Preconditions can Tasks can be compared to ordinary C functions.
thus be signaled to other tasks. This requires the under Windows are still available. Adding a The only difference is that tasks can be pre- participation of an extended task, because HAL to simulate all required peripherals on the only these are able to wait for events. Basic tasks PC makes it possible to run and test the appli- that a pre-empted task will later be resumed at cannot do this, but they can cause events.
cation at the developer’s workplace. Combining the very point of pre-emption. From inside the OSEK/VDX and a HAL has finally taken the de- task the pre-emption is invisible. The idea be- Resources in OSEK/VDX terminology refer to velopers where OSEK/VDX alone promised to hind pre-emption of tasks is to provide means data structures similar to semaphores, which take them but did not succeed. Using this pack- to reach more dynamic applications. They no can be used to guarantee exclusive access to age will be the normal approach in future, just longer have a linear, continuously repeating global data. This makes it possible to use them flow of operation but instead can react to a for deadlock prevention. OSEK/VDX uses the given situation more quickly. This approach is priority ceiling protocol for this purpose. It as- OSEK/VDX characteristics
signs a special priority to each resource and setsa task priority to this value while it uses the The OSEK/VDX-OS standard defines a static, Two kinds of tasks are provided in OSEK-OS: matching resource. This is a safe means of syn- scalable, multi-tasking real-time operating sys- basic and extended. Basic tasks only release the chronization, because tasks using resources can tem. Static means the exact number of required processor by terminating themselves and can- neither wait for events nor be terminated. Ad- resources has to be determined before generat- not wait for any event. Therefore they typical- ditionally, the priority ceiling protocol is math- ing a specific kernel. Dynamic changes at run- ly perform jobs, which have to be completed ematically proven to be deadlock-free.
time are not supported. By setting up these re- entirely after activation. Extended tasks however strictive demands the chances of better code op- can wait for events, so they usually only need to timization are increased significantly, making it be started once and are controlled by appro- tasks. Their behavior is defined in OSEK/VDX- possible to use even simple processors. Thus it priate events. Each task is given a fixed priori- COM, which also describes messages between is not necessary to estimate the resources re- ty that must not be changed at run-time. This ECUs. The main purpose of messages is to send quired in the worst case, instead the actual re- priority is used to determine which task will be quirements of the static system can be easily de- performed. The scheduler simply selects the some interesting additional services. By sending November 2002
a message it is possible to automatically per- someone familiar with it than it is for proprietary form another activity. This can be activating a solutions. Second, functions that belong togeth- task, setting an event, executing a call-back er can be put into one task to form a ready-to-use function or setting a flag. So it is possible to ac- tested module. Typical change requests should tivate the receiver of the message by just send- now only influence a few tasks and so the ing the message. This makes sure there always changes only need to be performed locally. This can of course also be achieved without usingOSEK/VDX. But the standard provides easy–to- use means which facilitate this approach.
ters and alarms. The unit of time is a tick offixed length. An alarm is an activity to be per- However, the standard does not define every- ProOSEK features an integrated graphical formed when a counter reaches a given value. It thing that is needed to develop hardware inde- results in activating a task, causing an event or pendent software. OSEK/VDX-OS takes a few executing a call-back routine. Alarms can be routines. These need to be written by the pro- steps in this direction but leaves a few blank both activated and deactivated dynamically. It grammer, but are executed by the operating sys- spots. It is possible to encapsulate all direct ac- is possible to specify whether an alarm is to be tem in certain situations. The StartupHook for cesses to hardware into tasks. These tasks still performed once or cyclically. Although de- example is performed on start-up of the appli- require changes when programming for dif- signed to measure time, counters can also be cation and can be used to initialize on-chip pe- ferent hardware, but the changes only need to used to control different things. An example ripherals. The second interesting hook is the Er- be applied locally. This approach has been used might be to have a counter count errors de- tected in an application. Every three errors an begun to call for a better solution that makes alarm operates and activates a task that stores value indicating some internal error. The Er- applications portable without any changes.
the error codes in some given location.
rorHook is similar to a small exception handler.
The key to reaching this goal is the definition ofa standard driver interface. With the publication Finally interrupt service routines (ISRs) are still Benefits and challenges
of this interface anybody would be able to write available as expected by the programmer.
drivers for all kinds of peripherals. The driver They are divided into two categories. Catego- OSEK/VDX defines all the services a real-time functions could be used via a standardized in- ry 1 ISRs execute without any interference with multi-tasking kernel needs. It facilitates the de- terface that makes switching between different the operating system. They behave exactly the sign and implementation of software that can drivers easy. The software written on top of same as usual on the particular architecture be ported to different architectures more easi- these drivers does not require any changes. The used. As a drawback these routines cannot use ly. An application can for example be split into peripherals to be accessed can easily be deter- any operating system services. Coordination various functional parts. Each of these is im- mined via a special configuration tool quite with tasks has to be done using global variables plemented as one or more tasks. Different de- similar to the configurators provided with or similar. In category 2 ISRs, on the other velopers can work on different tasks and can hand, the majority of operating system func- even test them independently. This is possible tions can be used. To achieve this a few in- because a task gets no information about the The solution: a hardware
structions need to be inserted at the beginning origin of activations or events sent to it. Thus to and end of the ISR. These ISRs can now acti- test a single task the programmer can write one abstraction layer
vate tasks to let them perform the less time- more task that generates all the events and ac- critical parts of the work. On architectures tivations the first task needs to react to.
(HAL) is simple: it offers one interface to the without interrupt priorities or levels this helps application and another one to the hardware to receive the next interrupt request faster.
Also, the maintainability of applications is im- driver. The HAL has responsibility for mapping proved. First, with a standardized software un- requests from the application to the corre- The services provided are completed by hook derlying the application it is much easier to find sponding driver and vice versa. The mapping OSEK/VDX is a standard for…
■ …modular and static real-time operating systems, initiated by leading automotive manufacturers and suppliers, research institutes and soft-ware developers. OSEK stands for the German words meaning open systems and the corresponding interfaces for automotive electronics”. VDXmeans “vehicle distributed executive“ and originally formed a separate initiative, which later joined the OSEK group. Both titles make the in-tention of OSEK/VDX clear: standardized interfaces for automotive electronics. The standard formulated is completely platform-independ-ent and makes only relatively small demands on target systems. This allows use of rather simple processors in control tasks instead of more ex-pensive solutions without added functionality. However, there is practically no upper bound for possible target platforms, because it is reasonableto use even more complex CPUs.
The standard defines several independent components: the actual operating system (OS), a communication subsystem (COM), a network man-agement system (NM), the OSEK implementation language (OIL) and the OSEK run-time interface (ORTI). Two new standards have been addedin recent years. They aim specially at the future market for x-by-wire systems providing time-triggered services. They are OSEK/VDX time-triggered operating system (OSEKtime) and fault-tolerant communication system (FTCOM). Currently the OSEK/VDX standards are beingprepared for acceptance as ISO 17536. Today the operating system standard in particular is a mature document reflecting years of practical ex-perience with conforming implementations. The first ECUs with OSEK-based software have been on the roads since 2000. The first car usingOSEK in all its ECUs can already be bought. More and more automotive OEMs demand that software for their cars should use OSEK. ■ November 2002
can be defined in a simple configuration lan- The hardest job when defining a HAL is to find guage similar to OIL. Of course configuration supporters for the particular solution. A HAL will tools can be provided to make writing these con- only help software developers if it is widely ac- in early 1997. Today, ProOSEK is the base of figuration files easier. All this is well known from cepted. Unfortunately the chances of establishing BMW’s standard core used in the majority of another OSEK/VDX standard were quite bad. So ECUs in the new 7-series. 3SOFT also partici- pated in the definition of both the OSEK/VDX- The application now no longer has to access any hardware directly. Instead it calls functions formed an interest group called HIS (Hersteller- Initiative Software i.e. manufacturer’s software ini- The I/O-Library is available as a stand-alone mentation or by the HAL. The HAL itself is tiative), aiming to agree on standard approaches product and as part of the new ProOSEK 4.0.
again a hardware-independent piece of soft- wherever possible. One of the first results was the Drivers for a number of peripherals are already ware using hardware specific drivers. So in- definition of a HAL called I/O-Library.
available. As mentioned before these need not stead of porting an application, only the op- be bought, but can easily be developed if need- erating system – if not already available for the This solution has been defined and imple- ed. A tool for configuring the drivers is also part architecture anyway – and the drivers need to mented in a joint effort between Daimler- of the I/O-Library. This tool can be used not be ported. In contrast to porting the operating Chrysler and 3SOFT, the latter being well only for commercial drivers but also for self- system, writing a driver is quite simple. The known as the developer of the ProOSEK oper- HAL driver interface is published so everyone ating system. 3SOFT has been active in the ProOSEK, the HAL configurator is integrated 3SOFT – 15 years of software competence
3SOFT went on to write an im-pressive story of success. The com- even in these economically difficult times.
“Assisto” central domestic control system was resonance and ultra-sonics are focused.
created in the development laboratories of know-how that is second to none. About 150 In the early 90s 3SOFT broadened its activities permanent employees at the company locations into industrial automation. Siemens Automa- Specialist for standard software
in Erlangen, Braunschweig, and Stuttgart advise tion and Drives (A & D) and Heidelberger and develop software for a circle of customers platforms
including the leaders of the current market sec- tomers. Today 3SOFT has a partnership with Transfering technologiecal know-how, profes- tors. Agfa, Audi, BMW, Bosch (Blaupunkt), Siemens A & D for training and support in all sional engineering services and innovative Conti Temic, DaimlerChrysler, Fresenius Med- matters concerning Windows CE on Mobic®, products make 3SOFT GmbH a reliable part- and supports Siemens’ customers in the Open ner. Customers of 3SOFT obtain everything Siemens A&D/Med /VDO, Techem, Visteon, from a single source, from the management of VW, ZF Lenksysteme represent only an excerpt adaptation of software for operator panels.
complex projects to training for the introduc- tion of new concepts, through to the imple- In the middle of the 90s the European auto- mentation and maintenance of applications.
Company history
motive industry has specified the OSEK/VDX The assurance of software quality receives operating system standard for electronic con- Embedded software for medical devices was the trol units in automobiles—. Based on the col- first business area addressed by the company.
lective experience with different real-time Today, 3SOFT is the expert for standard soft- Since then 3SOFT has developed control and operating systems, the strategic choice fell on ware platforms. The cen-tral concern is to assist service software for Siemens Med meeting the 3SOFT to implement this standard. The result customers to achieve cost advantages and rapid high quality standards of the TÜV and FDA is the ProOSEK real-time operating system, time-to-market. A current development in this (Food and Drug Administration). Components direction is the company’s entry as development for large medical equipment as used in an- November 2002

Source: http://www.joscho.de/PUB/ECENov02.pdf