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

Announcement - Agenda - Paper Presentations - Kickstart Sessions - Technical Keynotes - Work in Progress Reports - Tutorials - Authors

A paper copy of the workshop proceedings can be ordered from FRANK Linux Systems.

RTL Applications

• An Experimental Set-up for Robotics and Control Systems Research using Real-Time Linux and Comau SMART 3-S Robot
  Alessandro Macchelli , Claudio Melchiorri , Dietrich Pescoller
• A Linux based straithening machine control system
  Giuseppe Renoldi
• Active noise control headsets using RTAI
  Emanule Bianchi , Lorenzo Dozio
• MCA - An Expandable Modular Controller Architecture
  Kay-Ulrich Scholl , Jan-Christian Albiez , Bernd Gassmann
• The LinuxPLC - Requirements to Gain Acceptance in Industry
  Rick Jafrate
• RTLinux in CNC machine control
  Yvonne Wagner
• Prototype Flight Simulators Employing RTLinux
  Todd Gearheart
• ADITYA Tokamak control with RTLinux
  Prabhat Ranjan

RTL Contributions

• An Open Source Hands-on Course with Real-Time Linux
  Herman Bruyninckx , Pieter De Troyer , Klaas Gadeyne
• TkDAS - A Data Acquisition System Using RTLinux, COMEDI, and Tcl/TK
  Kenneth Jacker , Joshua McKinney
• Real-Time Experiment Interface System: RT-Lab
  Calin Culianu , David Christini
• Rapid-Prototyping System Based on Standard PCs with RTAI as Real-Time Operating System
  Arne Linder
• Using MATLAB-Simulink RTW to Build Real Time Control Applications in User Space with RTAI-LXRT
  Giuseppe Quaranta , Paolo Mantegazza
• Xenomai project - Implementing a RTOS emulator framework on GNU/Linux
  Philippe Gerum

Embedded RTL

• Embedded Linux - Ready for Real-Time
  Bill Weinberg , Claes Lundholm
• The Industrial Data-Aquisition System with Embedded RT-Linux and Network Server Technology
  Tomasz Motylewski
• A Tool for Customizing RT-Linux to Embedded Systems
  Josep Vidal , Pau Mendoza , Ismael Ripoll , Juan Vila
• The Embedded Data Acquisition System For Mossbauer Spectrum
  Qing Guo Zhou , Wenzhong Wu , Yue Ma
• Intelligent Sensors using Minimal Embedded RTLinux Version
  Pascual Perez , Gines Benet , Jose Simo , Franco Blanes Rafael Martinez

RTL Implementations

• Window-Constrained CPU Scheduling for Linux Systems
  Richard West , Ivan Ganev , Karsten Schwan
• Integrated Dynamic Priority Scheduler for RTLinux
  Patricia Balbastre , Ismael Ripoll
• RTLinux with Address Spaces
  Frank Mehnert , Michael Hohmuth , Sebastian Schonberg , Hermann Hartig
• RTLinux Beyond Version 3
  Victor Yodaiken
• The internal design of the Flexible Real-Time Linux kernel
  Andres Terrasa , Ignacio Paches , Ana Garcia-Fornes
• Eliminating Latencies by Using Interrupt Priorities
  Bernhard Kuhn

In this paper, the real-time control of a robot (a Comau SMART 3-S) based on RTAI-Linux is presented and discussed, along with the presentation of a flexible experimental set-up for using the robot in different tasks and with different tools (e.g. a vision system and an advanced gripper). This project is currently under development at the Laboratory of Automation and Robotics of the University of Bologna.

The most important component of the set-up is the Comau SMART 3-S robot. This is a six degrees of freedom industrial manipulator with six rotational joints. Each joint is actuated by a DC-brushless motor with angular position measured by a resolver. The robot is equipped with its own controller C3G-9000. This controller is essentially made of three parts: a user interface, a control unit and a driver unit. The control unit consists of two boards connected by a Motorola VME bus: the first board (SCC) is equipped with a DSP and carries out all the control tasks (trajectory planning, direct and inverse kinematics, etc.) The second one (RBC) is responsible for the man-machine interface and for interpreting PLD2 user's programs. On this board we can find that a shared memory area: this is a memory area which is accessible from each board connected with the VME bus.

In our experimental set-up, the C3G-9000 controller is open, that is the VME bus is connected with an ISA-PC bus via a couple of Bit3 boards, one inside the controller and the other inside the PC that will implement the control algorithms. This is RTAI-Linux system. The two boards are connected with an high-speed cable. A data exchange between the PC and the controller is possible via the shared memory area on the RBC board inside the controller and synchronization can be achieved by an interrupt signal generated by the controller itself. In this configuration, position and velocity loops managed by the C3G-9000 are opened, and all securities are disabled: the controller is only used as an interface between resolvers and drives on the robot and the PC.

On the robot wrist a vision system and the A.S.I. Gripper are mounted. The vision system is used to provide visual information about the environment and, in particular, about objects inside it. These informations are needed when we decide to follow a moving object in the work space with the wrist of the robot or to move the robot in a position so that the taking of an object could be possible using the gripper. The vision system is connected to a frame-grabber board inside another PC and the information exchange with the robot control system occurs on the Internet via TCP/IP. The vision software runs under a non real-time Linux system, so it will not be discussed in detail in the full paper.

The A.S.I. Gripper has three degrees of freedom, and is particularly suited for no-gravity manipulation tasks in space applications, since it can interact with free-oating and irregular objects. Its control algorithms run over a custom board based on the TMS320C32 DSP hosted in a third PC. A loader and a DSP-monitor had been developed under Linux, along with some drivers for the DSP board. By now, we are still developing the information exchange mechanisms between robot/vision system and gripper: the idea is to use the visual information and all the data that the sensory equipment on the gripper provides to move the robot in such a way to achieve a better taking of an object. At the moment, we can only use the visual information to place the gripper in a position of the robot's working space so that the object framed by the vision system can be grasped.

In the final version of the paper, details on the Hw/Sw architecture will be given, as well as some remarks on the experimental activity developed os far.

The application consists of the realization of the control system for a straightening machine for shaft, profiles and rings. The machine is composed by 3 brushless motors axis controlled to make point to point movements (not interpolating) and by a multichannel LVDT position sensors acquisition system that must be precisely syncronized with the rotation of the workpiece. The control architecture is composed by an industrial PC (Pentium 233MMX) based on Linux + its Real Time Application Interface (RTAI) by Dipartimento di Ingegneria Aerospaziale del Politecnico di Milano (DIAPM) which control the axis, the analog acquisition system and some digital I/O. This computer is connected (by a serial line driven by rt_com) to a Panel PC for the MMI and to a PLC which interface the external loading/unloading system. The application is a mix of some kernel modules (axis control, acquisition and serial communication) and a huge application in user space using the much part of the real time symmetrically usable APIs provided by LXRT. RTAI has been chosen specifically for its symmetric services usability in kernel and user space.

The most demanding real time part is realized in kernel space after having developed, and tested it, wholly in user space. Thank to the services symmetry, the following port to kernel space has been totally trouble free. In such a way, a faster and less risky development has been possible. The only thing lacking was the possibility of using rt_com directly from user space and the author had to extend LXRT to make it possible an easy expansion of the related services. The result is the module rt_com_lxrt which is now embedded in RTAI distribution. The use of the above cited OS-extension-APIs has proved very reliable and effective and has allowed a single developer to carry out the whole task from system conception to the working machine in a relatively short time.

In this paper an adaptive digital control system has been developed for low-frequency noise reduction in headsets. Each headset channel incorporates a sensor/actuator pair (microphone and loudspeaker), which is used in a FIR filters and LMS algorithm based feedback loop.

The RTAI software involves two real time tasks, one for each channel, that are resumed at 5 KHz by the external A/D board timer. Fifos and shared memory provide the data exchange with a Qt based graphical user interface.

The most impressive results have been obtained for single-harmonic disturbances, with attenuation of more than 60 dB. The controller has been successfully tested even in presence of multi-tone and random noises.

For the effective development and realization of different robot prototypes the use of transferable software components is a very important aspect. Reusable components with standardized interfaces lead to extendable architectures. MCA is a modular software framework that is developed to satisfy these topics.

The effort at software implementation should be restricted to the excitation of new components and control methods that are not implemented so far. If parts of a whole controller system are organized in small standardized modules, these modules can be reused in other projects. Communication between and synchronization of the different parts of the software have to be done by the controller system, i.e. the project developers can focus their work on the methods that are necessary for controlling the robot.

Beside the reusability of controlling mechanisms for other prototypes the short training period of new students as well as the uniformly software appearance on all levels has played an important role during the development of MCA. Therefore C++ as programming language has been chosen. To fulfill eventual real-time requirements Real Time Linux has been used. RT-Linux combines real-time functionality with the advantages of a stable Unix system. In RT-Linux a simple real-time executive runs a non-real-time kernel as its lowest priority task.

This paper gives an overview about the inside workings of MCA, the used tools and the realised projects.

A proposal to deploy a small LinuxPLC application was recently presented to Kaiser Aluminum in Spokane WA. The proposal was initially met with enthusiasm but was eventually was rejected for a number of reasons; some valid some perhaps not.

Since the reaction and concerns of Kaiser are likely to be not much different than many industrial consumers of automation it would be worthwhile for the LinuxPLC developers in particular, and for Real-time Linux developers in general, to examine this proposal and rejection in greater detail. Knowing what customers are probably going to expect, what objections they will have, etc. would be a great help to developers and promoters of real-time Linux.

This paper proposes to quantify the advantages and disadvantages of the LinuxPLC, as perceived by Kaiser. It will closely examine the reasons for the rejection. The paper will attempt to enumerate the items that are

In this article the project of porting an axis controller for turning and milling machines running under the real time operating system IA-SPOX to RTLinux is described. EMCO implements PC based control systems for training machines with different user interfaces simulating control systems like Siemens or Fanuc. The current real time system IA-SPOX is running under Windows on the same computer as the application, exchanging set und actual values via ISA card with the machine. As the old RTOS is not supported any more under Windows 2000, a new solution had to be found. The reason, why it is now possible to use RTLinux, lies in the flexibility of the whole new control system where the graphical user interfaces and the axis controller are separated. Our GUIs will continue to run under Windows, but communicate with the real time tasks via Ethernet. Thus, the platform for Real Time can be freely chosen without paying attention to the current operating system our clients use. The target will be a motherboard booted from flash disk with RTLinux as its operating system, more precisely miniRTL for our embedded system. The data exchange to the axis will be realized by addressing a PCI card every control cycle.

The points, where porting the axis controller tasks on RTLinux required some redesign, are explained, and also some other problems encountered during this on-going project.

The flight simulators presented in this paper have hydraulic motion system, hydraulic control loading, and 3D visual systems. Full compliment of Aircraft flight instrumentation, dual avionics and radios, GPS, flight director, and autopilot. They also feature enhancements such as: TCAS, GPWS, FMS, Color Radar with real-world wx simulation, and functional EVP (environmental voice processor) with integrated ATIS and random communication chatter. Simulation software contains complete flight, engine, navigation, systems, and avionics simulations. All featured simulators are in the US FAA Level B/C/D class. The I/O subsystem on these simulators contain as many as 64 12 bit analog inputs, 256 12 bit analog outputs, 900 discrete inputs and 672 discrete outputs. On the OS and control side, the periodic scheduler in RTLinux 3.0 (installed in kernel 2.4.5) sets up two real-time threads: A low priority real-time thread services the I/O and calls the simulator modular executive. The modular executive manages and schedules over 100 simulation modules at different rates based upon required task granularity. A second high priority real-time thread monitors the lower priority thread to insure that it completes execution before it's period expires. Mbuff 0.7.2 is used for the shared commons areas. Real-time I/O is accomplished through a user mode I/O daemon which uses RT fifos for communication.

ADITYA Tokamak produces high temperature plasma with a maximum time of 300 ms.

Main Power Supply and its control system : Uses power directly from grid (without storing) and can consume upto 60-70 MW of power for about 1 second or so. It has to supply power to three magnet coils. The current in the coil follows the references issued in real time with an update rate of about 1 ms using analog controls.

This power supply was earlier being controlled using a PDP-11 computer. Since this computer started to give problem, we have currently shifted to a PC-based system with Real Time Linux v2.0. Around August 1999, we had made a partial shift to PC using RTLinux v1.0. This system with PDP-11 was working till about March 2001, when PDP-11 failed to work, So quickly we have now shifted full functionality of the control to a PC running RTLinux v2,0; Following is the hardware:

• PC410B card from Datel Corp. with 16 AI, 4 AO, 8 DI and 8 DO. It also has timer/counter. RTLinux driver was available for v1.0, which we have ported to RTLinux v2.0
• Dynalog (India) PCL-840 Timer/Counter Card having 10 timer channel, 16 DI/ 16 DO channels. Timer is based on Am9533A chip and DI/DO is based on Motorola 6821 chip. We have ported the driver of a National Instrument Timer Card to this.
• CAN Bus syetem from Advantech corporation using PC-Can interface card PCL-841 (ISA based) and Advantech 5000 series 4 AO, 96 DI modules.

The first two cards are in one computer, which runs a control loop of 992 microsecond. We poll 7 digital IN lines every loop to detect any problem and start shutdown sequence. During each loop we acquire data from 16 AI channels and do some processing. AO channels are then updated, which are tracked by the power supply. The CAN bus card is in a separate PC and is doing slower control.

The full system is running without any problem reliably for last two months. Of course the part of the system had been operational for nearly two years without any problem.

This paper describes our hands-on course on real-time systems, as we present it to the fourth-year mechatronics engineering students. This hands-on course is one part of a cluster of three, the others being more theoretical courses on real-time software, and on processors and interfacing for real-time systems.

The hands-on course is using Real-Time Linux, and its examples focus on mechatronic systems for mechanical engineers, i.e., mostly motion control applications. The course was first given in Dutch, but its documentation and code examples are now reworked and extended for this year's course into an English version, which will be available under an Open Contents license. The aim is to serve as an initial basis for international cooperation in the field of educational material for real-time courses for beginning engineering students. The paper explains:

• the goals of the course (introducing engineering students to real-time programming, including the relevant Software Patterns and common design examples);
• the division in about eight sessions adapted for guided self-study;
• the different concepts introduced in the accompanying theoretical courses that we want to demonstrate (loadable modules; (POSIX) threads and their scheduling and attributes; mutexes, semaphores, condition variables, signals; IPC; interrupts and their ISR/DSR routines; monitor objects; ...);
• the hardware case studies (basically a set of motion control systems);
• the code examples.

We also report on our experiences when preparing and giving the course, as well as on the students' reactions and results.

After a brief introduction to data acquisition, the paper presents an overview of RTLinux and COMEDI. Then, our free TkDAS application is described including its datasets, modes, visualizations, and a step-by-step usage scenario. Following a detailed look at TkDAS's implementation, suggestions are made for the creation of user extensions (e.g., adding other data reduction methods). The paper concludes with a discussion of future work.

The need for real-time interface systems is ubiquitous in scientific research (e.g., cardiac arrhythmia control, torque measurement, fluid dynamics analysis). However, current options have significant drawbacks: common multi-tasking operating systems are inherently non-real-time and therefore require special hardware for real-time functionality, DOS functionality is outdated, and proprietary real-time operating systems are expensive. Furthermore, each of these options is vulnerable to the ever-looming possibility of obsolescence in the event that the proprietary, closed-source operating system were to be discontinued.

To overcome these limitations, we are developing a general-purpose, open-source, real-time experiment interface system based on Real-Time Linux, Comedi, and Qt. This system is being developed with flexibility and adaptability in mind, so that experimentalists with limited programming experience can modify it to meet the specific demands of their application. With this freely available system, we hope to ease the burden of experiment interfacing for a wide range of scientists and engineers.

Standard rapid-prototyping systems for real-time applications are usually equipped with x86-based PCs for software development and additional DSP processors to do the real-time work. Using a DSP always requires tools and compilers which in most cases must be purchased and are licensed by the vendor of the DSP, increasing the cost of the system. This paper presents a rapid-prototyping system based on a PC without using any DSPs. It consists of a standard PC with Pentium processor and a 19"-rack connected to the PC via an interface board. The different slots of the 19"-rack contain several plug-in cards (e. g. A/D- or D/A-converters) to connect the PC-system to any controlled system. All real- time tasks are processed by the main processor of the PC, which implies a real-time operating system. Using RTAI the performance of the system is sufficient for most applications of electrical machines and drive control. Experimental results obtained by the proposed system for a field-oriented control of an induction machine will be presented.

The RTAI (Real Time Application Interface) project was born at the Dipartimento di Ingegneria Aerospaziale, Politecnico di Milano (DIAMP) as a tool to develop PC based real-time control systems. Everything started from the need to have at hand a OSS to develop complex control systems, or to perform real-time data acquisition and simulations with hardware in the loop, at the lowest possible cost. At the present the project has already reached its maturity, and has been successfully used in numerous applications. Anyway, until now, the development of the executable code implementing a control system required good C-programming skills, and sometimes a deep knowledge of numerical methods.

An interesting way to avoid such a hurdle, is offered by the MATLAB/Simulink Real-Time Workshop (RTW) suite. RTW is an automatic C language code generator for Simulink. Under Simulink it is possible to create, simulate and analyze dynamic systems, by simply connecting functional blocks, that can be chosen from various pre-configured libraries. By using this tool the user can concentrate on the modeling and control issues as opposed to programming issues; RTW controls the translation of the blocks in C code than can be compiled to obtain an executable file. Applying a few simple compatibilities wrappers to the RTW interface that is used to get a C-code for the VxWorks environment, it can be used unchanged to run control codes in hard real-time (i.e. providing a deterministic response) under the supervision of the RTAI-LXRT.

LXRT is an easier, less risky and faster environment to develop applications in user space, allowing the user to develop and test applications without going into kernel. In this way has been possible to use TCP/IP communications from Simulink to the running code and vice versa, to perform on-line parameters tuning during real-time executions, and to observe the behavior of any signal while the simulation is running. The paper presents a few simple applications of this system that show the good performance that can be achieved in terms of sampling rate, and the easiness of use of this new tool.

Xenomai is a Linux-based framework which aims at being a foundation for a set of RTOS API emulators running on top of hard real-time extensions of Linux.

Generally speaking, this project aims at helping application designers relying on proprietary RTOSes to move as smoothly as possible to a Linux-based execution environment, without having to rewrite their applications entirely.

The technical benefits expected from having a common framework that underlies multiple RTOS emulations on top of real-time Linux are:

• reduced complexity of designing new API emulations using a common code base of generic services ;
• improved stability and reliability of the emulators by code sharing and mutualization ;
• RTOS-awareness and efficient debugging support implemented once and consistently at the generic level, thus available to all the emulation layers running on top of it.

This project relies on the similarities found between many proprietary RTOSes, especially from the thread scheduling and synchronization standpoint. These similarities are exploited by Xenomai to provide a nanokernel exporting a set of generic services. These services grouped in a high-level interface are used in turn to implement emulation modules of real-time application programming interfaces, which mimic the corresponding real-time kernel APIs.

A similar approach was used for the CarbonKernel project (i.e. http://savannah.gnu.org/projects/carbonkernel/), in which simulated RTOS kernels are built on top of a generic virtual RTOS based on event-driven simulation techniques.

To obtain the needed hard real-time capabilities, the nanokernel itself relies on a real-time Linux extension such as RTAI (http://www.rtai.org/) or RTLinux (http://www.rtlinux.org/) for hardware control and architecture-dependent system software.

The nanokernel is aimed at running on top of RTAI/x86 first, replacing the standard rtai_sched module by the end of Q3/2001. The first emulation module mimicking pSOS+ (*) which will be built on top of the emulation framework is scheduled for the beginning of Q4/2001.

Xenomai is a free software project hosted at http://savannah.gnu.org/projects/xenodaptor/, and published under the terms of the General Public License V2.

(*) VxWorks is a registered trademark of WindRiver Systems, Inc.

Linux is increasingly finding application in embedded systems with requirements for real-time responsiveness. The standard Linux kernel, however, having been designed for throughput-intensive enterprise duty, and bearing the UNIX legacy of timesharing and system administration needs, is not well suited to meet such real-time challenges. In particular, the kernel is non-preemptible and the scheduling/prioritization schema is fairness-based. At present, two main approaches exist for meeting real-time response requirements in a Linux system: brute-force (real-fast) application of processor power, and the insertion of secondary kernels that virtualize the CPU interrupt chain and manage real-time events and processing, leaving Linux to run (or not) as a lower-priority task under the second kernel.

Unfortunately, these kernel insertion methods present barriers to their general application: divergent APIs, non-standard programming models, and a tendency to starve ""real"" Linux. In short, today's so-called ""real-time Linux"" may offer real-time, but is definitely NOT LINUX. This presentation presents a third path to real-time Linux : the use of native Linux real-time capability (i.e., no kernel insertion), by leveraging the inherent preemptibility of the standard Linux SMP (Symmetric Multi-Processing) kernel. Such a native approach utilizes standard Linux code, APIs, and programming models, and has as its end to make Linux better, rather than subverting it. The presentation will cover this native approach, covering architecture, build methodology, and performance considerations in the context of versions 2.4 and future 2.5 kernels.

An industrial test control and data acquisition system MD 2 which is developed by BFAD GmbH and Wolf+Woelfel GmbH will be presented. The interface cards communicate through 16 MHz data bus with the controller card which is based on a DIMM-PC module running RT-Linux. The kernel driver consists of low level Multidata bus driver (communication layer), middle layer of hardware and task specific modules and the Linux layer which provides character device driver interface to the middle modules which are written in OS-neutral way. Maximum flexibility is achieved by allowing direct access to the communication layer and by passing unknown ioctls to the middle layer transparently. Several application modules using RT-Linux have been developed.

The driver may be accessed remotely via custom TCP/IP and UDP multithreaded server. PERL/Tk and C clients will be shown. The ways to optimize parameters of the system (network latency, etc.) will be discussed.

Real Time LEAST Tool, is a cross system development to design Linux based embedded systems. It allows to automatically tailor a great variety of embedded devices: since biscuits PC to single RAM & processors systems. In the last few years, Linux has proved to be a competitive operating system for a wide range of systems. One of the newest fields where it is becoming more appealing is embedded systems. Some of the main reasons why Linux is being preferred against proprietary based solutions is easiness of tailoring, portability and recently, with the introduction of RT-Linux, the possibility of meeting real-time requirements. However, customizing Linux to small hardware platforms is not straightforward. Although there have been several efforts to minimize Linux, two key issues have not been properly addressed: the first one is flexibility for configuring the boot and root file system devices, while the second one is flexibility for configuring a minimum file system and extending it in a modular way according to the application needs. One of the features of an embedded system is that there are many different possibilities for specifying a boot device and a root file system storage device. The combinations of all of them offers a great range of possible configurations. In addition, many of these devices are rather specific to embedded system: flash memories, EPROM memories, RAM disks.

The LEAST tool provides support for all these combinations. A target system where Linux has not been already installed is typically initialised using the network (bootp protocol) or a temporary connection to a floppy disk (if the network is not available) as boot devices. The root file system with a previously customized version of Linux or RT-Linux with is installed, by default, on RAM disk, because this is the minimal support that can be assumed to exist on every target system.

Once Linux can run with this minimal configuration, some other combination of boot and root file system devices can be used. For example, if a flash memory exists, it can be configured to be the boot device, the root device or both. Usually it is specified only as boot device, rather than root file system device because of two reasons: the first one is that the backup device can keep the image of the root file system in a compressed form, thus doubling its capacity; the second one is that using RAM memory as root device is faster and cheaper than using flash memory. However, this is an example and any other configuration can be used.

Regarding how to extend a minimum file system in a flexible way, the notion of a file system "profile" has been developed. The idea of profile allows to develop a file system in a modular and flexible way. A profile is basically a package containing a set of libraries, application programs, kernel modules, configuration files,..., for extending the minimum file system to allow a given programming environment. An example of profile is RT-Linux.

Some other profiles are the Java profile, the Ada95 profile, the administration profile, etc. Profiles can be combined incrementally. The application for the target system is itself developed as another profile. The whole process of developing a customized Linux version for a target system is done on a host running Linux and the Real Time LEAST (Linux Embedded & Autonomous System Tailoring Tool). This tool allows and makes easy the process of configuring a kernel, configuring a file system, configuring the boot and root devices, producing a file with the image of kernel and file system for the target, and initialising the target using the bootp protocol or a floppy disk.

With the great developmnet of the embedded and real-time operating system, it becomes practical the hardware based on PC architecture in high-end embedded applications. Especially the research on embedded Linux is the hotspot in this area. In this thesis, we had built a remote data acquisition and monitor system for mossbauer spectrum based on the miniRTL. This system could be accessed by the Internet browser or the Java application program which is designed specially. Extensive consideration was given in the design of the system to achieve the most advantageous balance between hardware and software, i.e. to maintain the ease of handling and full capability of hardware system without employing sophisticated hardware. The concept of the design may be applied to other experiments requiring real-time data collection and online data processing facilities.

In the last years, with the massive introduction of Systems-on-a-Chip (SoC) and other highly integrated platforms, the development of intelligent sensors with high processing capability have been increased. The sensors and actuators of a robot prototype called YAIR have been developed using this technology. This local computing power allows an intelligent sensor to process the information locally and distribute the results by means of a CAN network.

The systems-on-a-chip require an operating system and there are several possibilities to be used: bare machine with embedded applications, VxWorks, Real-Time DOS extensions, RTLinux and so on. RTlinux is a good election because it allows easy tailoring to target platform. The boot process and the development of specific drivers is possible and easy, using the available source code. Moreover, the structure of RTLinux allows to develop a two-level architecture with a part of hard real-time and soft real-time in a RT control process level, and an upper level (Linux level) to provide multiple resources as distributed file-systems or storage capabilities, IP networks and sockets to allow the SoC platform to access knowledge databases on Internet and so on.

The control of each sensor and actuator in YAIR robot uses an embedded platform based on the 386EX SoC. It has only 3Mb of memory (1.5MB of RAM, 1MB of flash memory and 0.5MB of ROM and I/O digital lines), A/D and D/A with several channels. To increase its communication capabilities an intelligent communication system has been developed. This communication system is based on Philips 80c592 processor with a double port RAM. The main advantage of the used platform is the core of the SoC included. This is an Intel IA32 processor with extended management circuitry. For using the RTLinux OS, a platform PC compatible is needed, but the embedded platform used is not completely PC compatible. The main incompatibility are the absence of compatible BIOS and secondary storage devices.

These drawbacks are been overcome by developing a small BIOS capable of remote load and patching the boot process executed by RTLinux kernel. The patch are similar to a bootp patch, allowing system load and subsequent execution of the kernel and init process. In general, the PC-based SoCs have only a clock. This characteristic requires programming prescalers and the memory map to obtain a 100% compatible PC platform. These operations are made by the BIOS.

On the other hand a new driver has been developed to control specific hardware of the embedded platform: a flash memory and the ROM file system. Also, a driver for accessing remote file systems via CAN network has been developed. As these drivers are used as secondary storage devices, and to reduce its complexity, they are centralized, using a virtual hard disk partition table. The driver schedules the requests using this table. For accessing A/D & D/A converters, several API s have been developed.

The file system of the embedded platform have been split into two devices: one local, which has the local real-time tasks and tools for managing it, and a shell for remote access via a communication channel. The other part of local file system is a remote file system mounted via network using a CANFS driver. This remote file system is based on virtual block device drivers using a two level hard and soft Real Time CAN driver over the RT level.

This paper describes our experience using Dynamic Window-Constrained Scheduling (DWCS) to schedule processes (and threads) on available CPUs in a Linux system. We describe the implementation of a kernel-loadable module that replaces the default Linux scheduler. Each process scheduled using DWCS has a request period of T time units and a window-constraint, x/y. The end of one request period and the start of the next denotes a deadline by which time a process must be serviced for one quantum, of K time units. Under these constraints, DWCS attempts to guarantee that each process receives at least (y-x)K units of CPU time every window of yT time units. That is, DWCS tries to guarantee that each process misses no more than x deadlines every window of y requests for service, and each time a process is serviced it receives K units of CPU time.

DWCS is theoretically capable of meeting the window-constraints of n processes. This means that DWCS can produce a feasible schedule, guaranteeing no process misses more than x out of y deadlines as long as the least upper bound on resource utilization does not exceed 100% and each process is serviced in fixed size time slots. In this sense, DWCS is optimal.

We show that DWCS successfully schedules CPU- and I/O-bound processes in Linux more than 99% of the time, when a feasible schedule is theoretically possible, assuming system overheads are negligible. However, interrupt handling, context-switching, scheduling latency and unpredictable management of other resources besides the CPU affect the predictable scheduling of processes. We discuss several approaches that we are considering, to account for system overheads and provide predictable real-time scheduling to processes in Linux.

In a hard real-time system, a scheduler decides whether a task has to be executed or not according to its priority. Moreover, hard real-time computer systems are subject to absolute timing requirements, which are often expressed in terms of deadlines. RTLinux is a good choice to implement a real-time system. However, the only scheduling policy implemented in RTLinux is the Rate Monotonic Algorithm (RMA), in which every task is assigned a fixed priority, according to its period. A scheduler related issue is the control of the concurrency. RTLinux (Pthreads), provides Mutex objects to protect critical sections. But the use of mutex in a real-time environment lead to the problem of priority inversion. Pthread API provides two solutions to priority inversion: Priority Inheritance Protocol (PIP) and the Ceiling Semaphore Pro-tocol (CSP) called by Pthread PTHREAD PRIO INHERIT and PTHREAD PRIO PROTECT respectively. RTLinux only implements the PRIO PROTECT, which is better than PRIO INHERIT since it reduces context switches and also avoids deadlocks.

Dynamic priority scheduling theory is mature enough to be used in real-time systems. This paper describes the modifications done to the current RTLinux code to provide both fixed and dynamic priority scheduling. Since the CSP protocol can only be used in fixed priority schedulers, a new type of mutex has been implemented: PTHREAD PRIO SRP, which implements the Stack Resource Protocol (SRP).

The Stack Resource Policy is a general resource access protocol, which can be used with both fixed and dynamic scheduling algorithms. The main characteristics are that: run-time overhead of the SRP is the same than that of the CSP; SRP produces less context switches than CSP; The worst case blocking time is the same than that of the CSP; under some situations SRP can increase the response time of processes over CSP. In conclusion, CSP can be replaced by SRP in most situations. Special care has been taken to implement the new scheduler according to the current RTLinux API and POSIX API recommendations. The new scheduler and mutex code is fully compatible with current API.

Additional informations.

In this paper, we determine the cost of a separate-space system relative to that of a shared-space system. We compare these particular two types of systems because we feel that separate-space systems lend themselves for the largest num-ber applications, and we expect the largest performance over-head relative to shared-space systems.

For our evaluation, we used RTLinux from the shared-space systems category, and L4RTL, a reimplementation of the RTLinux API as a separate-space system based on a real-time microkernel and a user-level Linux server.

We observed RTLinux's worst-case response time to be much higher than about 15 us on a generic x86 PC claimed by the systems authors. In our experiments, RTLinux worst-case interrupt latency was 68 us. The worst case for L4RTL was 85 us.

We found that the cost induced by address-space switches to real-time applications does not significantly distort the predictability of the system. In general, most of the worst-case overhead we observed must be attributed to implementation artifacts of the microkernel we used, not to the use of address spaces.

This talk will cover recent developments in RTLinux, including work for SMP embedded systems, systems on chip, the BSD port, and adjustments to efficiently satisfy POSIX standards requirements. In addition, we will discuss a new real-time networking layer.

SMP: RTLinux now runs on quad embedded PowerPC boards. In order to make the system run efficiently, we performed an extensive analysis of locking behavior and made use of new data structures to minimize contention. We'll discuss some technology and performance.

System on chip: RTLinux now runs on several highly integrated processors. We'll discuss performance implications.

POSIX: Over the last year we have continued to add POSIX functions and to work with system design to make sure these can be used efficiently. We have also been working on low contention synchronization methods that fit within POSIX.

The BSD Port: RTLinux now runs with NetBSD as a host system. We'll discuss design issues.

Networking: FSM has developed a new real-time networking layer to address requirements in factory automation and communication systems. This layer is designed to allow zero copy stacking of protocols and to co-exist with the existing Linux network layer.

Flexible Real-Time Linux (FRTL) is a Real-Time-Linux-based kernel which has been specially designed for supporting flexible hard real-time systems. Such systems need both hard real-time constraints and the ability to dynamically adapt their responses to changes in the environment. One of the major design goals of FRTL is to be provided along with a complete schedulability test, which specifically includes the kernel overhead. This test has been adapted to the special task model which FRTL supports, as well as to the kernel's internal design. Because of this requirement, FRTL has been designed in such a way that its timing characterization becomes straightforward and its overhead can be easily measured. This paper presents the internal design of the FRTL kernel, with special emphasis on its layered structure and its homogeneous way of structuring all its system calls and interrupt service routines.

Current implementation of RTAI and RT-Linux make use of the "deferred interrupt mechanism". Although this is a simple way to add hard real time extensions to a standard linux kernel with minimum modifications, real time tasks can still be delayed by linux interrupts, causing latencies.

When using a fast processor, this situation is a minor problem, because non real time interrupts are only marked as "deferred" and real time processing is resumed immediatly: the latencies caused by caches, TLB-invalidation and PCI-operations are usualy higher than those caused by the interrupt deferring handler.

But with slower processors - targeted for mass volume production - the situation is somewhat different: here, the latencies caused by the deferred interrupts mechanism are much higher,rendering the hard real time extension useless in worst case.

This talk will show how to get around of the problem mentioned above by simply disabling interrupts of lower priority. This scheme invents priority levels for interrupts and will be discussed and demonstrated using the recent port of RTAI to M68K, where this mechanism was implemented, first. The talk will end with a presentation about porting RTAI to other architectures.