You are here: Home / RTLWS 1999-2017 / RTLWS Submitted Papers / 
2023-12-10 - 17:46

Dates and Events:

OSADL Articles:

2023-11-12 12:00

Open Source License Obligations Checklists even better now

Import the checklists to other tools, create context diffs and merged lists

2023-03-01 12:00

Embedded Linux distributions

Results of the online "wish list"

2022-01-13 12:00

Phase #3 of OSADL project on OPC UA PubSub over TSN successfully completed

Another important milestone on the way to interoperable Open Source real-time Ethernet has been reached

2021-02-09 12:00

Open Source OPC UA PubSub over TSN project phase #3 launched

Letter of Intent with call for participation is now available

Real Time Linux Workshops

1999 - 2000 - 2001 - 2002 - 2003 - 2004 - 2005 - 2006 - 2007 - 2008 - 2009 - 2010 - 2011 - 2012 - 2013 - 2014 - 2015

Eleventh Real-Time Linux Workshop on September 28 to 30, in Dresden, Germany

Announcement - Hotels - Agenda - Paper Abstracts - Presentations - Registration - Abstract Submission - Xenomai User Meeting - Sponsors


Real-Time Linux for Real-Time Simulation

Andreas Thuy, University of Paderborn / C-LAB
Gilles Bertrand Gnokam Defo, University of Paderborn / C-LAB

To support the development of embedded software for a certain hardware platform, the application code (C code) written/produced for that platform shall be executed on a PC running a real-time operating system (RTAI). The real-time operating system is extended to a simulation environment where timing accurate triggering of the application code is possible. In contrast to a pure logical simulation, it is possible to perform first tests regarding the timing behavior. However, in such a simulation the view on the embedded hardware is simplified because the hardware itself is not simulated but only its behavior as needed by the application software (e.g. interrupts). Therefore the question arises how to emulate the signals from the embedded hardware platform and the operating system running on that platform. The idea is to encapsulate the application software in a RTAI task. Because of the assumptions regarding the embedded hardware behavior within this simulation, some changes/adaptations have to be applied to the application software.

Embedded software produced for a specific board either runs directly on the hardware handling interrupts itself or the embedded software is assembled with an embedded operating system to form a package of both application code and operating system. In the latter case, the embedded operating system is in charge of handling interrupts. These might occur because hardware timers signal the proceeding of time or communication peripherals signal the arrival of some data. In this study, timer interrupts were emulated by periodic RTAI tasks which trigger the embedded software accordingly. The interface to bus/network devices in the RTAI system is a device driver where the signals have to be forwarded to the embedded software accordingly. This adaptation of putting the software in a RTAI task and forwarding signals (timer and communication signals) within this study is done by hand.

While it is clear that hard real-time performance can only be reached through the usage of real-time drivers that use the API of the real-time operating system, many device drivers are shipped with standard Linux drivers only. In this study, we carried out a few experiments with a communication bus hardware that offer both standard Linux and RTAI drivers. Results concerning the drivers' fitness for the described real-time simulation comparing the use and the structure of both types of drivers are presented.

Because the PC is expected to be equipped with much more processing power than the target hardware would be, the next step is to run several RTAI tasks as described above concurrently thus allowing to simulate the distributed nature of the final scenario. This raises the question of scheduling problems like how long one of the simulation tasks is allowed to occupy the processor without being interrupted by another task. As all of the simulation tasks are assumed to have the same priority, some other guidelines for task switching (besides time slicing which does only offer a very generic mechanism) must be developed, which is future work.