Combined Approach of OSGi and RTLinux Framework for Supporting
Software Architecture of Internet Embedded Real-Time System
Won Eui Hong
Bon Jin Ku
Myung Jin Lee
Hong Bae Park
Soon Ju Kang
Kyungpook
National University
Kyungpook
National University
Kyungpook
National University
Kyungpook
National University
Kyungpook
National University
wehong
@palgong.knu.ac.kr
kbj7838
@palgong.knu.ac.kr
explr
@palgong.knu.ac.kr
hbpark@ee.knu.ac.kr
sjkang@ee.knu.ac.kr
Abstract
In this paper, we propose new software architecture
for Internet embedded real-time system. In order to
support the local real-time behavior, dynamic
reconfiguration behavior and Web-based Internet
connectivity simultaneously, we have designed a
domain-specific software architecture by combining
OSGi framework and dual kernel based OS, RTLinux.
The proposed architecture can effectively merge both
real-time tasks and non-real-time tasks without any
loss of real-time constraint. Using this architecture, we
also have implemented a prototype of Internet
embedded real-time appliance as a case study and
evaluated the suitability.
1. Introduction
Internet embedded real-time systems means devices
or appliances satisfying the needs of both Internet
connectivity and embedded real-time characteristics.
Web camera, local weather forecasting system, Webcontrollable telescope for the universe, and unmanned
aerial vehicle are well-known cases of Internet
embedded real-time systems. Because the Internet
embedded real-time systems require similar constraints,
domain-specific software architectures are essential to
meet these requirements optimally.
The current software architecture of the system can
not support some characteristics like Internet support
without disturbing the internal real-time constraint. To
solve these problems, we specially suggest a domainspecific software architecture using OSGi framework
and RTLinux based on dual kernel technique in this
paper. A prototype, called Internet Vending Machine
based on this architecture was built and has been
evaluated.
2. Requirements
2.1. Dynamic reconfiguration
Some systems such as vending machines or ATMs,
should work persistently and, at the same time, their
logic of functions, policy of service, information which
is provided and the charge frequently needs to be
changed. If you have these kinds of things to do,
shutdown of the entire system and replacement of some
modules is a general procedure in most of current
systems.
But the dynamic configuration facility can help the
manager of the system to update these things easily.
Without stopping the system, he might upload new
parts or information to the system and apply them.
Moreover, it is possible to make one form of system
hardware to be utilized in different way just by
replacing the logic modules. All of these processes may
be taken via the Internet.
2.2. Guarantee of real-time constraints
Internet embedded systems may have time-critical
tasks. Because the Internet and non time-critical
services of the system do not have real-time
requirements, most of the systems are defined to
contain two problem domains – real-time and non-realtime.
In this case, real-time tasks should not be disturbed
by non-real-time tasks. For example, Internet
acceptance procedure must not prevent safety check
routines in the factory control system.
If the system is managed to be divided into two
sections of real-time and non-real time and made to
give higher priority to the real-time task, you can assure
that the real-time tasks do not miss the deadline. The
fundamental operations with real-time constraints can
be treated in the real-time section, whereas Internet
management and other applications can be in the nonreal-time section.
2.3. Support for Internet Connectivity
Internet embedded system works must be managed and
operated through the Internet at any time by the system
operator. So, the system has to serve the persistent
Internet connection service
Internet is a best-effort service. That is to say, it does
not guarantee the timeliness at all. To compensate for
this and to handle the real-time tasks through the
Internet, particular software architectures are needed.
3. Basic concept and related work
3.1. OSGi framework
OSGi(Open Services Gateway Initiative) is a
specification of an open service platform for the
delivery and management of multiple applications and
services to all types of networked devices in home,
vehicle, mobile and other environments [4][5].
One of the most graceful features of OSGi
framework is its dynamic configurability. Every service
module running on the OSGi framework is made as a
form of component named bundles and it can be
installed, started, stopped and uninstalled without
changing the status of the system even from the remote
area via Internet.
Although the OSGi framework is developed
especially for the home network gateway, this
characteristic can be utilized in general embedded
systems. If the main function of an embedded system is
implemented in the OSGi bundles, reconfiguration of
the system becomes easier and comfortable for the
manager to do. You can change the system logic just by
updating the bundles of the main function. You can
also insert a new function to do an additional job or
replace it by a quite different one which makes the
system perform another job with the same system
resources. No power-off or system reset is necessary in
these processes, and the manager of the system can do
these processes over the network.
In addition, the abstract logic of a system can be
easily implemented because the OSGi bundle is made
up of familiar Java programming language and JNI can
be used to communicate with lower layer tasks.
3.2. Separated management of real-time and
non-real-time tasks using RTLinux
In the situation that real-time tasks and non-real-time
tasks coexist in the system, the policy of task
scheduling is an important issue. It must be assured that
the real-time tasks precede non-real-time tasks.
RTLinux is a variation of Linux kernel for hard realtime control [7]. It adopts dual kernel architecture to
meet both general Linux and real-time operating system
requirements. RTLinux kernel treats the Linux kernel
as a real-time task of lowest priority. A real-time task
of higher priority preempts the Linux kernel. So,
RTLinux does priority-based task scheduling.
For its dual kernel architecture, we can reuse most of
the Linux applications without any modification. HTTP
server in Linux and the libraries might be reused in
Internet embedded system. The Java virtual machine is
also available to execute the OSGi framework.
4. Design of conceptual framework
4.1. Structuring of Tasks
Despite the enhancement of protocol and routing
algorithm, Internet does not guarantee the timeliness
due to its best-effort property. You cannot order the
system to do a time-critical work unit by unit through
the Internet. The interval of each transferred command
is not deterministic. If you write the application code or
system logic
in non-real-time programming
environment such as Java or C in user-level, you also
cannot assure the timeliness of the system.
To make these fashions available in the time-critical
system, the process of hierarchical task structuring is
needed in the system design time.
non real time
Internet
Connection
Application
Middleware /
API
real time
Real Time
Figure 1. Task structure in Internet embedded
real-time system
As shown in the figure 1, general task structure of
Internet embedded system is hierarchically spread out
as follow:
 Internet Connection Layer
 Application Layer
 Middleware / API Layer
 Real time layer
The most upper layer task, the Internet connection,
which is close to the non-real-time characteristic,
processes abstract commands to the system. These
abstract commands represent one goal of the system
and should be short enough to be transferred instantly
through the Internet. They are like “Keep the house at
30°C until the next morning“, “Make my coffee black”.
5. Case study: Internet Vending Machine
To estimate our proposal, we have made an Internet
vending machine. It serves customers a wireless
Internet connection and provides the information of the
local area in which the machine is located including
advertisements. This machine also serves coffee with
detailed choice of taste, by specifying the quantity of
each coffee, sugar, cream, and water. So the customers
have opportunities of choosing their own favorites.
5.1. Software Architecture
We choose RTLinux as the operating system of the
vending machine to perform real-time control of
hardware and, at the same time, to use Java virtual
machine for applications. We use RTLinux 3.1 and
Linux kernel 2.4.4.
The APIs for hardware control, communicating with
real-time threads through the RT-FIFOs, are located on
top of the general Linux section as a form of Linux
shared library. The API library exchanges data or
signals with the real-time threads, and responds to the
call of bundles of the OSGi framework.
Ivmlib
main
ivmhttp
Other
Services
OSGi Framework ( JES 2.0 )
JNI
To achieve the goal, the task of this layer makes use of
the lower layer tasks.
The application layer, less abstract than the upper
layer, makes the commands a little more concrete. It
forms system logics with the upper layer commands.
To “keep the house at 30°C until the next morning,”
the tasks of this layer set processes of temperature
monitor, heater, and timer in lower layer with specific
values and call them. So, there is no need to write a
program of this layer with real-time system
programming language.
The middleware / API layer is the basis of upper
layer and the channel between the upper non-real-time
and the lower real-time layer. The tasks of application
layer communicate with the real-time task layer by
means of the APIs provided in the system or interfaces
presented by middleware.
The real time layer treats hard real-time problems.
In this layer, concrete operations are implemented.
These operations are usually related with hardware
control such as the port read/write. These operations
can be implemented as real time threads or tasks, and
must not be blocked by the upper layer tasks.
Every task on the same layer works in parallel but
follows the priority. A tree of the tasks represents a unit
of core work. Upper layer tasks can make use of more
than one tasks of lower layer. Some tasks may not call
any lower layer task.
This structure makes it possible that the system
logic modules are implemented in non-real-time
approach. If the system logic and services can be
written in a familiar program language such as Java, it
becomes easy to modify
Real Time Tasks
Sensor
Thread
1
Actuator
Thread
2
Thread
N
RT-FIFO
...
Digital I/O
module
Vending Machine
Hardware
Java Virtual Machine
API Library
General Linux Kerenl
RT-Linux Real-Time Kernel
Single Board Computer
Figure 2. Software architecture of Internet
Vending Machine
The Java virtual machine is base environment of
OSGi framework. The OSGi framework which we
choose in the system is Sun Microsystems’s Java
Embedded Server 2.0. On the JES, services and the
default bundles such as HTTP, log services are
executed. The hardware control service bundle, ivmlib,
uses several APIs in API library through JNI. HTTP
interface service, ivmhttp, takes an order of coffee.
Main service, main, manages all these services. It takes
the information of ordering from ivmhttp service, and
passes that to the ivmlib to make coffee.
On the real-time section, real-time tasks are
implemented as POSIX threads. Threads have its own
duties and the system logic is realized with a
composition of these threads. We made real-time
threads to take care of each sensors and actuators.
The abstract system logic in the non-real-time
section fires several units of real-time threads. If we
order this machine to “make my coffee sweet,” the
system logic module calculates the setup value of each
sensors and motors, and then calls the API with the
parameters of that value. In that case, the value to the
sugar motor is higher than normal situations. APIs,
which are made up of native system call, convey the
values via RT-FIFO. The real-time threads get awaked
as soon as the values arrive and perform real-time
controls.
Because the real-time tasks have higher scheduling
priority than the non-real-time ones, the real-time
constraint of the system is met, and we can say that the
sensor data collected in the non-real-time tasks has the
real-time quality.
5.2. Task Structure
Our tree of tasks is shown in figure 3. The command
of ordering coffee, ”make my coffee sweet,” is
accepted with the HTML forms in the Internet
connection layer. It is transformed to specific status
values of the coffee, sugar, and water motors. And then
it invokes APIs of the coffee actuator and sugar
actuator to trigger the real-time tasks. Those API
functions transfer the status values to RT-FIFO and
awake the real-time threads that turn on the motors.
Simultaneously, others services such as information
of the local area and system failure check, are provided.
All of real-time tasks are executed parallel in the policy
of scheduling.
Internet
Connection
Layer
make my
coffee sweet
show me the
map of this
area
Application
Layer
set the
actuator with
coffee = 2
sugar = 4
query DB and
display the
map
Middleware /
API
Layer
Real Time
Layer
water pump
check
with interval = 2
thread to call:
coffee actuator
duration = 2
turn on
coffee
valve
for 2 ms
thread to call:
sugar actuator
duration = 4
turn on
sugar
valve
for 4 ms
thread to call:
temp check
interval = 1
thread to call:
pump check
interval = 2
check the
temperature
of water
every second
check water
pump every
2 seconds
5.3. System Reconfiguration
To test all of sensors and actuators in the system, we
made a simple OSGi bundle which makes use of the
same lower level APIs and real-time tasks. The job is
turning on all of actuators and displaying the sensor
values. Without the shutdown of the system, we could
simply replace the modules on a web browser.
check
the system
actuator test
value = 3
coffee = 2
sugar = 4
thread to call:
coffee actuator
duration = 2
turn on
coffee
valve
for 2 ms
thread to call:
sugar actuator
duration = 4
turn on
sugar
valve
for 4 ms
thread to call:
temp check
interval = 1
check the
temperature
of water
every second
thread to call:
coffee actuator
duration = 3
turn on
coffee
valve
for 3 ms
turn on
sugar
valve
for 3 ms
non real time
layer
Local
HTTP
Coffee
Information
Service
Service
Service
HTTP
Service
Local
Information
Service
preemption
occur
H/W
Check
real time
layer
HTTP
Service
Coffee
Service
H/W
Check
regular task
ordinary service waiting time
regular task
RT
RT RT
Task Task Task
1
2
1
RT
Task
3
irregular tasks
extended service waiting time
due to the real time tasks
full service time related
with real time tasks
Figure 5. Scheduling of Internet Vending
Machine
When a real task occurs, service waiting time gets
extended. Although this is essential to meet the realtime constraints, it ruins the response time. In worst
situation, HTTP connection may be time-outed. To
avoid such a disaster, we make the real-time tasks
simple and estimate the maximum delay of service at
design time.
In this paper, we suggested a domain-specific
software architecture for Internet embedded real-time
systems. From the experimental implementation, we
could confirm the superiority not only of the
performance but also of the suitability in the system
integration. This architecture has not been fully tested
in hard real-time applications, but the current
performance is sufficient for soft real-time applications.
In order to make this architecture more flexible, we
should add intelligent reasoning layer to perform more
abstract and autonomous actions.
8. Acknowledgements
sensor test
value = 1
thread to call:
sugar actuator
duration = 3
coffee
ordering
perceived
6. Conclusion and future work
Figure 3. Task tree of Internet Vending
Machine
make my
coffee sweet
it is necessary to limit the number or duration time of
regular real-time tasks.
thread to call:
temp check
interval = 1
report the
temperature
sensor value
every second
This work was supported by grant No. R01-2003000-10252-0 from the Basic Re-search Program of the
Korea Science & Engineering Foundation.
Figure 4. Reconfiguration of upper layer
9. References
5.4. Schedulability Analysis
[1] Gamma, E. Helm, R. Johnson, R. and Vlissides, J. 1995.
Design Patterns: Elements of Reuable Object-Oriented
Software. Addison-Wesley.
[2] Liu, C. and Layland, J. 1973. Scheduling Algorithms for
Multiprogramming in a Hard Real-Time Environment.
Journal of the ACM, 20(1): 46-61.
[3] Moon, J. and Kang, S. 1997. Design of Robot
Teleoperation System Based on Distributed Object
Technology. Proc. KICS Summer Conf. 97. pp. 1051-1054.
[4] Antinav, http://www.atinav.com/osgi
[5] OSGi Alliance, http://www.osgi.org
[6] Java Technology Forum, http://forum.java.sun.com
[7] FSMLabs, http://www.fsmlabs.com.
The scheduling diagram of the Internet Vending
Machine is depicted in figure 5. Scheduling takes place
in both the real-time and the non-real-time layer.
Because the real-time tasks have higher priority, the
real-time tasks block the non-real-time ones when they
are in execution.
Service waiting time directly affects the system
response time. To make system users feel comfortable,
this interval time needs to be in a reasonable range. So