Approach for Implementing Object-Oriented Real-Time Models

on Top of Embedded Targets

L. B. Becker*, M. Gergeleit & E. Nett
Institute for Distributed Systems (IVS)
Otto-von-Guericke Universitt Magdeburg, Germany
{lebecker, gergeleit, nett}@ivs.cs.uni-magdeburg.de

* on leave from the Computer Science Institute, Federal University of Rio Grande do Sul, Brazil

Abstract: Over the last years, object-orientation has been recognized as a suitable technique for the
modeling and design of real-time systems. Although modeling strategies archived a high-level of
maturity, current run-time infrastructures have not reached the Nirvana. The so called middleware,
which provide adequate abstractions for programming object-oriented real-time applications, still
demands lots of computational efforts. When considering an embedded system, where processing
power and memory footprints are very tight, these nice environments are often out of consideration,
and programming is done using low-level languages, missing the basic object-oriented principles.
This paper describes possible alternative implementations for an object-oriented model of a mobile
robotic application. It gives some insights in the problems (and their possible solutions) that occur in
the development of object-oriented real-time systems on top of embedded architectures.

Keywords: embedded real-time systems ; object-oriented; modeling and design.

1. Introduction
The object-oriented paradigm archived a great level of popularity within the real-time community over
the last recent years. Concepts like modularity, inheritance, polymorphism, and encapsulation contributes for
better structuring the application, facilitating its understanding, testing and debugging [4, 13]. Also, objects are
suitable units for expressing concurrency. These aspects make the object-oriented paradigm suitable for the
modeling and design of real-time systems [6, 12, 16].
Although modeling techniques archived a high-level of maturity, in special after the definition of
OMGs Unified Modeling Language (UML) [5], there is no consensus on how to represent the modeled aspects
in the implementation. As a general rule, the use of object-oriented programming languages is suggested (but not
forced). Moreover, the use of object-oriented real-time middleware has been encouraged [7, 9, 15], since it
increases the programming abstraction level with the use of APIs. The main problem regarding these
middleware, is that there are no commercial of the shelf (COTS) versions available, and existent preliminary
versions are still very resource consuming (the typical peak memory requirement for the RT-CORBA TAO [14]
could be well over 256 Mb).
Considering embedded systems design, it leads to extra constraints that do not appear in non-embedded
ones. Since embedded systems typically run on top of microcontrollers, most applications must deal with limited
resources and poor programming and execution environment support (only a few family of microcontrollers
provide compilers for object-oriented programming languages and operating system support). Together, these
facts do not actually motivate designers to start the transition from the error-prone, low-level Assembly or C
programming towards the object-oriented paradigm. However, also in the world of embedded systems there is an
increasing need for open systems and as a result of that also for modularity, understandability, and reusability.
So the problem remains, how to make the benefits of object-oriented programming available to small embedded
systems?
In this paper we describe, as a case-study, the object-oriented redesign of an existing embedded
microcontroller application. In this description we focus on the real-world problems that arise when trying to
convert poorly structured, but working real-time code into a clean design. We also discuss how an integrated
object-oriented development environment can be applied to ease this transition.
The remaining of this paper is divided as follows. In the next section, the adopted case-study is
presented in detail. Then, in section 3, possible implementation alternatives for the developed model are
described. Finally, section 4 summarizes the main aspects of the developed case-study and section 5 gives the
conclusions.

2. Case-study Presentation
The application used as case-study is part of the distributed onboard-control architecture of a mobile
autonomous robot. It executes on a 16-bit Infineon C167 microcontroller and it includes safety-critical code to
shut down the drives in case of emergency, tight time-critical control loops, and field-bus communication with
the other onboard-controllers. The robot is equipped with a set of sensors, including encoders (to determine
speed and movement), infrared sensors (to determine distance from obstacles), and bumpers (to detect
collis ions). In addition, it includes two motors, allowing speed and direction control. Fig. 1 shows the hardware
of the robot. The following subsections present the OO model of the system, the functionalities that must be
accomplished and a possible implementation strategy.


















Fig. 1: The Kurt2 mobile robot.

2.1 Robot Model
As the first step in the redesign process, the robot control application was modeled using the object-
oriented paradigm. This model, developed with the use of SIMOO-RT integrated environment [1, 2], is
presented in fig. 2 (the left part represents the class diagram and the right one the instance diagram). It includes
all the embedded devices mentioned in the beginning of the section, and also the relevant elements within the
application semantics. The dependencies among these entities, or objects, are depicted through means of classes
associations. The reader not familiar with SIMOO-RT notation must not worry with the graphical symbols inside
the classes (mainly used to depicted the simulation paradigm associated with the class). Also, the dashed square
of MovPlanner class means that it is viewed as an external element to the designed model.


Fig. 2: OO Model of the Kurt2 mobile robot.

The robot functionality is constituted by four tasks: move planning, sensors interfacing, motor control,
and odometry. The SIMOO-RT modeling environment suggests designers to express systems functionalities with
UML message sequence diagrams (MSD). In the current implementation of the MSD editor, it is possible to
describe the timing constraints of the object interactions, as showed in fig. 3 for the motor control task.
Elucidating the constraints in the figure, the one associated with Control() means that this message is cyclic, with
period value of 3ms. Moreover, the other constraints within the mctr1 object represent the deadline for the
methods invocations, and its counterpart on the other side of the invocation describes the maximum execution
time for the method. Following the MotorCtr execution line, the constraints of the method invocations represent
the deadlines for receiving the return. Basically, each one of the four tasks previously listed will derivate into a
MSD. Analyzing the application dynamics, others periodic activities can be pointed out: encoder sampling
(2ms), odometry loop (100ms), and event handler polling (120ms).
The event handler (EH) polling activity emerges from the adopted communication strategy. The reason
is that the MovPlanner object is located on another execution node, interconnect by a CAN-bus network. In
order to allow asynchronous communication over the CAN-bus, an approach similar to [8] was used. The objects
interested in sending or receiving messages through the CAN-bus need to interact with the EH. Since this
element is part of the implementation only to support the communication mechanism, it is not presented in the
model of fig. 2. A more detailed discussion about object models and communication abstractions can be found in
[11]. Next section discusses how the model described could be implemented using SIMOO-RT automatic code
generation.


Fig. 3: Objects interaction within the motor control.

2.2 Implementation Strategy
One important feature of the SIMOO-RT environment is the capacity to make automatic code
generation in AO/C++ language [10]. This language adopts special constructors for the specification of
concurrent active objects, supporting also the association of timing constraints within these objects. Actually,
AO/C++ has a similar Interface Definition Language (IDL), as adopted by others objects technologies, like
CORBA, DCOM and Java-RMI. After pre-processed, a scheme to map method invocations to remote methods
invocations (in this case, remote means in a different OS task) is automatically generated. This scheme is
consisted by stub and skeletons, which are responsible, respectively, for parameters marshal and demarshal.
Although the runtime environment for the AO/C++ language was not available on the target platform
(currently, it runs on QNX and Linux), it was used as base for the implementations described in the following
sections. According to this idea, the elements from the instance diagram presented in fig. 2 are implemented as
instances of active classes, which are executed by independent threads of control. The periodical activities found
in the specification are associated to cyclic object methods within the active objects. Object communications
inside the microcontroller are mapped to remote methods invocations (RMI), since they do not necessarily
execute in the same address space. At least RMI requires synchronization on shared objects. Communications
through the CAN-bus is handled by the EH. In the final picture, the application will be constituted by a set of
active objects, running concurrently, and activated both by time (e.g. in cyclic operations) and by events (e.g.
remote methods invocations). Fig. 4 shows an example of AO/C++ code for the MotorCtr class.


Fig. 4: Example of AO/C++ code.

3. Embedded Solutions
As mentioned before, the application generated by SIMOO-RT was not supported directly on the
embedded target used by the robots. In despite of that, this section argues about the possibilities for making the
mapping between SIMOO-RT object-oriented model and the C167 microcontroller. The goal is to present and
discuss alternatives that can be used as guidelines for designers faced with similar problems. These alternatives
were defined using the idea of a "graceful degradation", i.e. the design alternatives are discussed starting from
using the completed functionalities of an embedded operating system and a C++ compiler down to no operating
system and no object-oriented compiler. However, the object-oriented design principles were kept in all the used
alternatives. Fig. 5 summarizes this concept, exhibiting the configurations used to implement the mentioned idea.
The remaining of this section describes the configurations applied and the involved drawbacks.










Fig. 5: Configurations of the embedded solutions.

3.1 Embedded OS/Multi-task Application
This alternative constitutes in porting the AO/C++ language to an embedded OS available for the C167
microcontroller, e.g. the Hightech PXROS. To implement this configuration, the same successful strategy as for
porting AO/C++ for Linux can be used: the original calls to QNX were kept, and a library for mapping these
calls to PXROS has to be added to the application project. This porting allows the full implementation of the
model presented in the previous section. However, the application size increased substantially compared to the
original solution. This is because of the necessary stubs and skeletons required to encapsulate the RMI
communication model. Another problem is the amount of threads switching during runtime. Once the granularity
of the tasks that the system must handle is very fine, the code becomes over-weighted.

3.2 Embedded OS/Minimal-task Application
One alternative for reducing the penalty of the threads switching is to group operations with similar
cycles into the one task. Checking the application semantics and the periods of the existing objects, it is possible
to argue that the encoder sampling and the motor control can be grouped in a single 3ms loop, that executes the
encoder sampling before the control algorithm. Additionally, it can be seen that also the odometry loop and the
event handler loop can be grouped into a single schedulable entity. The system still suffers from some context
switching overhead (especially caused by the 3ms loop), but task grouping reduces it by half. Another benefit is
that the RMI is substituted by normal method invocations within the grouped objects. As a consequence, the
number of stubs and skeletons is substantially reduced, what improves the application performance. Especially
within these tasks there is no need for synchronization code any more as the invocations are serialized now. A
// header file MotorCtr.ph
active class MotorCtr {
private:
// reference to other active
objects
Encoder REF rEnc0, rEnc1;
Drive REF rDrive0, rDrive1;

...// other attributes
unsigned int speed;
public:
void ControlLoop(cycle_t);
void SetSpeed(dead_l);
} // end of motorctr class
// implementation file MotorCtr.pC
include MotorCtr.h

void ControlLoop(cycle_t){
begin_cycle
//Cycle definitions....
end_cycle
}

void SetSpeed(dead_l){
begin_operation
//Normal operation....
end_ operation
begin_exception
//Exception operation....
end_ exception
}

Emb. OS/multi-task app
Emb. OS/minimal-task app
No-OS/C++ compiler
No-OS/C compiler
System Resources
major drawback of this is the fact that control flows in different active objects are now dependent on each other.
As a consequence, in this coroutine-like approach the code must be structured to avoid any blocking operations,
as blocking would prevent other periodic tasks from meeting their deadlines.

3.3 No-OS/C++ Objects
Since a typical situation on embedded systems design is the absence of OS support, the previous
configuration was adapted for dealing with this restriction. The active objects from AO/C++ were substituted by
normal C++ objects. Moreover, a different scheme for dividing the application control flow between the two
remaining tasks was established. The task with the less frequent loop (the odometry loop, 100ms) was kept in the
main control flow of the application. The control loop (3ms) was mapped to an IRQ handler, resulting in a kind
on minimal Rate Monotonic schedule. When using the IRQ as replacement for a task, a clear advantage is that
the overhead for handling an IRQ is considerably lowers then a normal context switch. Also, considering that the
absence of OS forces objects to run in the same task, there is no need for inter-process communication (IPC)
mechanisms (other than simple interrupt-synchronization), eliminating the stubs and skeletons and reducing the
application size. The clear trade-off in this approach is the lost flexibility: the ability to express tasks with
different periods is very limited now. The usual work-around in such a single loop controller is the use of
counting variables, that enable (parts of) the execution of tasks with larger periods every n
th
period. Also the
approach of moving tasks with short periods in the interrupt handler has some drawbacks. The number of
possible nested interrupt levels is usually very limited. Also, by blocking interrupts for synchronization purposes
the overall interrupt latency becomes critical. As a result, this way of implementing active objects relies heavily
on application-specific knowledge. Without the support of a design tool that controls the mapping and checks
compliance with the given timing requirements, this approach will soon end up in the same messy structure as
the initial ad-hoc implementation.

3.4 No-OS/C Objects
Going depth in the restrictions of embedded systems, it can be seen that a large set of microcontrollers
does not have object-oriented (e.g. C++) compilers. Typically, only an ANSI C compiler is offered. To tackle
this situation and keep the use of an object-oriented structuring, the strategy proposed by Sickle in [17] has been
adopted. The idea is to combine macros, pointers, and standard C structures to define classes and create objects.
This way, the same functionalities and structure of the previous real object-oriented program were kept. The
disadvantage from this method is that it consumes big implementations efforts, increasing the complexity and the
size of the code, although it is compensated by a well structured application. Fig. 6 shows the example code for
the MotorCtr class using this strategy.

Fig. 6: Example of a class implementation in C.

4. Results
The implementation strategies presented in the previous section highlights the use of object-oriented
modeling principles in the design of a real-time embedded application. These implementations reflect different
project requirements and available systems resources. E.g. if the embedded target supports a RT-OS, the
designer can choose between more or less task switching overhead, the amount of synchronization primitives
and IPC mechanisms. Without an OS, active objects with the highest priorities can be mapped to IRQ handlers,
while the others can be grouped into a cyclic executive. Here, the results obtained in the case-study are addressed
and discussed.
// header file MotorCtr.ph
#include defines.h
#define MOTORCTR \
BASE this; \
Encoder * theEnc1; \
Encoder * theEnc2; \
Drive * theDrive; \
unsigned int speed; \
void (*control) (BASE); \
void (* PI) (BASE);

typedef struct mctr{
MOTORCTR
} MotorCtr; // end of motorctr class

MotorCtr *motorctr_(void);
void motorctr__(Count *);
// header file MotorCtr.ph
static void control(BASE *this){
// Method code
}

MotorCtr *motorctr_(void) {
MotorCtr *Temp;
if((Temp=(MotorCtr *) malloc(
sizeof(MotorCtr)))==NULL)
error_handler();
Temp->control = control;
Temp->PI = PI;
Temp->this = Temp;
return Temp;
}

void motorct__(MotorCtr *this){
free(this);
}
Four aspects were used to perform a comparison among the developed implementations (the respective
results are summarized in table 1). The first aspect regards to the number of lines of code in the programs,
highlighting implementation efforts and code complexity. According to this aspect, the C++ program without OS
outperforms the others. This results from the code reusability provided by the OO paradigm. Next in this
discipline are, respectively, the programs with OS minimal and multi-tasking, that are a little bit bigger (resulting
from the instructions to make the operating system initialization; the second mu st also include synchronization
primitives). In the classification the program with the "C objects" with its extra macros and definitions to
implement the classes structures still better than the original one developed in C without the use of objects.
Another aspect in the comparison provided is the application code size, that relates to resource consumption
and system performance. To make a fair comparison among the different strategies, the measurements were
made using the size of the downloadable program. As expected, the applications without OS require less
memory resources than those that use an OS. Also, considering the applications without OS, an interesting result
is the smaller size of the application with C++ objects in comparison to the other two C programs.
The next aspect compared, called structure, depicts an evaluation of the code modularity, understandability,
and maintainability. The authors understand that using multi-task OS is the best conceptual solution, as it allows
designers to distinguish clearly the different control flows in the application. Not only the distinction of
activation periods is important, but also the ability to express the importance of an operation (often also reflected
by its priority) and fault-tolerance aspects have to be considered. The more an implementation differs from this
ideal concept, the worse it is rated.
The last aspect analyzed is the performance estimation of the applications. Since the applications have the
same functionality, the main point of difference is the overhead introduced by the OS. The main problem of
using an OS in the present application, as previously discussed, is the tight control loop for the motor controller.
For this reason, the frequent invocation of the OS scheduler causes a high overhead in the system, implying
performance degradation. One alternative that does not eliminate, but minimizes the problem, is to apply the
minimum-task approach. This keeps the main advantages of an operating system, like the provision of a robust
system-platform that encapsulates details of the underlying hardware with defined interfaces. It also preserves
extensibility as it allows adding other (active) objects without the need to touch the optimizations applied to
some of the high-period tasks.

Configurations Code lines Code size Structure
*
Performance
estimation
*

Original C program 1210 59.416 - ++
Emb. OS/Multi-task 890
+
97.000
+
++ -
Emb. OS/Minim.-task 850
+
95.147 + +/-
No-OS/C++ objects 800 54.876 +/- ++
No-OS/C objects 920
+
57.000
+
+/- ++
(*)
Legend: ++: very good; +: good; +/-: reasonable; - not acceptable.
(+)
Estimated value.

Tab. 1: Statistics from the robot code.

5. Conclusions
The results presented in the previous section emphasize clearly the advantages of structuring an application
using the OO paradigm over a function oriented approach. However, some of the results presented are influenced
by very application-specific requirements (like the large overhead from using OS, due to the very fine
granularity of the case-study control loops). This way, it is recommended to designers to check carefully their
application needs before selecting the implementation approach to be adopted.
In order to help designers to produce object-oriented embedded applications, the SIMOO-RT environment is
currently being prepared to provide an automatic code generator that can be dynamically adapted to the designer
requirements. The idea is to provide configuration options, reflecting in the implementation strategies presented,
which the designer can choose to configure the generated code. Basically, these options concerns to the grouping
of the active objects in the target platform. The insights obtained in the case-study can help designers to decide
about grouping active objects into one or more tasks, or even to map it to interrupt handlers.
The next step of the present project will be to use software metrics at design time, allowing evaluating the
implications of the adopted strategy before the actual implementation is run. The experience obtained with some
previous work regarding software evaluation (see [3]), can facilitate the implementation of this approach. In this
sense, the previous developed tools can be adapted for the new set of requirements.

6. Acknowledgments
Thanks are expressed to Prof. Carlos Eduardo Pereira, from UFRGS/Brazil, which collaborated for the
definition of the modeling concepts used in this work. Thanks are also expressed to Spiro Trikaliotis and Thomas
Ihme, colleges at OvG University of Magdeburg/Germany, which enriched the authors with their insights about
the previous implementation of the Kurt2 software.

7. References
[1] L.B. Becker, and C.E. Pereira. From Design to Implementation: Tool Support for the Development of
Object-Oriented Distributed Real-Time Systems. In Proc. of 12
th
Euromicro Conference on Real-Time
Systems. Stokholm, Sweeden, June 2000. pp. 108-115.
[2] L.B. Becker, C.E. Pereira, E. Nett and M. Gergeleit. "An integrated environment for the complete
development cycle of an object-oriented distributed real-time system". To appear in Computer Systems
Science Engineering, Leics, UK.
[3] O. P. Dias, L.B. Becker, I. Teixeira, J.P. Teixeira and C.E. Pereira. On identifying and evaluating object
architectures for real-time applications. Control Engineering Practice, v.9, n.4, p.403-409, 2001.
[4] G. Booch. Object-Oriented Development. Benjamin/Cummings Publishing Company, Redwood City,
1991.
[5] G. Booch, I. Jacobson, and J. Rumbaugh. The Unified Modeling Language User Guide. Addison-Wesley,
Reading, Massachusetts, 1999.
[6] B. Douglas. Real-Time UML: Design Efficient Objects for Embedded Systems. Addison Wesley, 1998.
[7] Java Expert Group. The Real-Time Java for Java Experts Group. Addison-Weley, 2000.
[8] J. Kaiser and M. Mock. Implementing the Real-Time Publisher/Subscriber Model on the Controller Area
Network (CAN), Proceedings of the 2nd Int. Symp. on Object-oriented Real-time distributed Computing
(ISORC99), Saint-Malo, France, May 1999.
[9] K. Kim. APIs for real-time distributed object programming. IEEE Computer (special issue on OO RT
distributed Computing), pages 72-80, June 2000.
[10] C. E. Pereira. "Real Time Active Objects in C++/Real-Time UNIX". In Proc. Of ACM SIGPLAN
Workshop on Languages, Compiler, and Tool Support for Real-Time Systems. Orlando, EUA. 1994.
[11] C. E. Pereira, L. B. Becker, C. Villela, C. Mitidieri and J. Kaiser. On Evaluating Interaction and
Communication Schemes for Automation Applications based on Real-Time Distributed Objects. To
appear in proceedings of the 4th Int. Symp. on Object-oriented Real-time distributed Computing
(ISORC01), Magdeburg, Germany, May, 2001.
[12] E. Shokri and P. Sheu. Real-time distributed object computing: An emerging field. IEEE Computer, pages
45--46, Juni 2000. Guest Editors' Introduction.
[13] J. Rumbaugh. Object Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, NJ, 1991.
[14] D. Schmidt, D. Levine, and S. Mungee. The design of the tao real-time object request broker. Computer
Communications, 21(4), April 1998.
[15] D. Schmidt and F. Kuhns. An overview of the real-time corba specifcation. IEEE Computer (special issue
on OO RT distributed Computing), June 2000, pp. 56-63.
[16] B. Selic. "Turning clockwise: Using UML in the real-time domain". Association for Computing
Machinery. Communications of the ACM. ISSN: 00010782. vol. 42. New York, Oct 1999. pp. 46-54.
[17] T. V. Sickle. Reusable software components - object oriented embedded systems programming in C. New
Jersey: PTR Prentice Hall, 1997.