Self-Management in a Robot Control Architecture
Jochen Maaß, Jens Steiner, Jürgen Hesselbach, Ursula Goltz
Abstract— To reach good maintainability, extendibility and
reusability of components in the design of robot control archi-
tectures is a major challenge. In this paper the authors intro-
duce an architecture for handling and assembly applications
featuring self-management techniques as an approach to tackle
these problems.
The existing architecture features a layered design, divid-
ing robot-specific components from those which are reusable
for a class of applications. Present and future concepts of
self-management applied to this architecture such as self-
configuration, self-optimization, self-healing and self-protection
are outlined. These properties are realized by the integration
of self-managers within crucial system components in a future
distributed version of the architecture.
I. INTRODUCTION
The ever-growing complexity of robot control
architectures has been identified as a major challenge.
Maintainability, extendibility and reusability become
problems besides the original realization task. Intricate
errors in large, monolithic systems often lead to huge efforts
in order to prevent the robot control from unpredicted
or disastrous behavior. Several, mostly nature inspired,
approaches have been proposed to tackle complexity
and entailed problems. In the year 2001, IBM drafted
their vision of Autonomic Computing and recommended
autonomy on different hierarchy levels in a system. They
later detailed this idea [5] and outlined how cooperating
management components for different system parts could
monitor, analyze and manipulate system behavior in their
area of responsibility and realize self-managed systems,
striving for optimization and capable to configure, heal and
protect themselves. Autonomic Computing has become a
huge research area and similar endeavors such as Organic
Computing [11] have been brought to life lately. A model
driven development (MDD) of the software parts of a
system can also help to catch some of the complexity and
can be the foundation for miscellaneous quality assurance
measures [15].
The authors introduce present and future concepts of
self-management applied to a robot control architecture
designed for sensor-guided handling and assembly tasks.
This architecture is used for the control of parallel kinematic
This work is supported by the German Research Foundation (DFG).
J. Maaß and J. Hesselbach are with the Institute of Machine Tools
and Production Engineering, Faculty of Mechanical Engineering, Tech-
nical University of Braunschweig, D-38106 Braunschweig, Germany
j.maass@tu-bs.de j.hesselbach@tu-bs.de
J. Steiner and U. Goltz are with the Institute for Programming
and Reactive Systems, Faculty of Mathematics and Computer Science,
Technical University of Braunschweig, D-38106 Braunschweig, Germany
steiner@ips.cs.tu-bs.de goltz@ips.cs.tu-bs.de
Fig. 1. Parallel Robots HEXA (l.) and TRIGLIDE (r.) for Handling and
Assembly
machines developed by the Collaboratorive Research Center
562 of the German Research Foundation (see Fig. 1 for
examples). In the following section, the architecture in
focus is described. It features the capability to perform
modern control algorithms in both, internal and external
loops. Internal loops such as the computed-torque approach
and feedback linearization [14] are required to benefit from
the robot’s dynamic performance advantage compared to a
classic approach. External loops for compliant motion with
respect to e.g. a force sensor or a vision system [12] are
crucial in light of performing error-tolerant assembly tasks
[16].
Furthermore, the architecture features a powerful task
frame formalism supporting skill primitive programming.
Introduced in 1981 by Mason [10] and taken up by
deSchutter [13], the task frame formalism is a major step
towards task orientated assembly programming [17]. The
difference compared to traditional motion description is that
the motion is defined in the task frame, which is allowed
to become placed arbitrarily in the robots’ work cell. Our
implementation of the skill primitive programming interface,
a concept which first was proposed by Hasegawa in 1992
[2], allows the robot operator to define a separate control
algorithm for each of the six d.o.f. the task frame provides,
causing hybrid moves of the robot’s end effector [7].
An inportant design principle applied to the architecture is
the separation of algorithms and communication as well as
OS issues, respectively. This allows for an easy integration
of self-management features. Most complex control systems
are designed in a collaborative environment, incorporating
experts in different fields of knowledge. Hence, the control
engineer should not be constrained by communication or
operating system restrictions. Our solution to this problem
is the application of a communication middleware. Further
improvements can be achieved by providing a complete,
platform independent programming framework [9], featuring
all required (abstract) interfaces as well as communication
and synchronization mechanisms as presented in section
II-B.
II. ARCHITECTURE DESIGN
In this section, the robot control architecture, where self-
management features are in the process of integration, is
described. A basic functional overview is given in Fig.
2. The control scheme named “RCA562” (Robot Control
Architecture of Collaboratorive Research Center 562) con-
sists of two layers. On the right, the robot specific layer is
depicted: It shows the subordinate drive controller receiving
a fully qualified (not only the desired pose xd but also its
derivatives x˙d and x¨d ) Cartesian trajectory information as
its input. This layer can be designed and put into operation
independently from the layer depicted on the left. This layer
shows the robot-independent trajectory generator, which is
the central element of this control architecture. It consists
of two types of reusable, task-specific modules: The control
core together with its coordination unit interacts with the skill
primitive programming interface and dynamically establishes
communication paths between the core and the attached
motion and sensor modules according to the motion task
specified by the current skill primitive. This is possible by
using the middleware MiRPA-X designed especially to meet
these demands. This middleware and its features are briefly
explained in subsection II-B.
Fig. 2. Functional Overview of the Control Scheme RCA562. It consists
of a robot-specific and a task-specific layer.
A. Modular Design
The previously described process of establishing dynamic
communication paths enables the control to provide the
desired control loops with respect to the currently executed
robot skill in every control cycle. In the following, an
example control cycle is described: Each time a new
skill primitive is received, a new set of desired values is
communicated to the motion modules. The current end-
effector position, velocity and acceleration is transformed
into the task frame of the current skill primitive in order to
allow these modules to calculate jerk limited trajectories.
Now the control is prepared to execute the skill primitive.
In every control cycle, the output values of the motion
modules are composed to a complete output vector,
containing the desired pose, velocities and accelerations
with reference to the task frame. This composition is
dependent on whether the motion algorithms have been
able to calculate an appropriate result. The force controller,
for example, is unable to calculate a desired trajectory
as long as the end-effector is not in contact with the
environment. An inappropriate result is replaced by the
result of a programmer-specified second level algorithm
(e.g. velocity module). In a next step, the current trajectory
information with reference to the task frame is fed back
to the motion modules in order to be incorporated during
the next control cycle. This is necessary in order to keep
temporarily displaced algorithms up to date, e.g. the force
controller. Finally, the output vector is transformed into the
robot’s base frame to generate the desired values for the
subordinated drive controller. Now the control is ready for
either the next control cycle or a new skill primitive. In the
following, focus is placed on the interfaces to the modules
of the trajectory generator.
1) Motion Modules: The important data elements of the
interface to the motion modules are discussed in the follow-
ing. The actual hand frame position, velocity and acceleration
ire passed to the motion modules. Additionally, the desired
values for the control algorithm and an array of flags, which
d.o.f. of the task frame should be controlled, are passed.
These data are followed by a list of pointers to shared
memory areas where the module can read its required sensor
data that it has previously announced to be required by its
profile. The mentioned profiles are needed for autonomous
configuration of the control system as described in section
II-C.
The motion module’s algorithm returns an array of flags
representing the d.o.f. for which a result has been calculated
successfully and the calculated output position, velocity and
acceleration. The required motion modules for the execution
of a specific skill primitive are notified by a per-module
command message. This allows the motion modules to op-
erate on distributed computing platforms in order to balance
computational load. At the end of each trajectory generator
execution cycle, the control core determines which modules’
output values are selected to be transformed into the robot’s
base frame, using the success flags. If none of the modules
has been able to calculate an appropriate result for a d.o.f., a
braking trajectory generator [4] is used by the core. All these
functionality is decoupled from the design of the trajectory
control algorithms by utilizing abstract interfaces as shown
in Fig. 3.
To maintain deterministic behavior and to become immune
against failure of motion modules and sensor modules or

Fig. 3. Using Abstract Interfaces in Order to Decouple the Design of
Architecture and Algorithms
even process termination on distributed computing platforms,
the control core needs to get the CPU privileged to the
other modules at crucial points of time in the control cycle.
This is achieved by making use of the priority inheritance
concept of the real-time operating system.
2) Sensor Modules: The interface to the sensor modules
is simpler. A sensor module provides one or more data
structures in a shared memory area maintained by the
communication middleware. This structure contains a flag,
indicating if the sensor module is requested to provide a
sensor value and the returned sensor value itself. They
are activated by a broadcast message in the beginning of
a trajectory generator cycle. Woken up on the message
reception, they could calculate signal processing algorithms
if necessary or just copy sensor information from a hardware
interface into the above mentioned shared memory area.
Here, it does not matter if the measurement comes from a
real sensor or just an internal state of the drive controller,
e.g. in order to perform adaptive control using the tracking
error as a performance criterion. In the latter case these
sensors are called virtual sensors and are driven by the
controller itself. Before becoming blocked again, the sensor
modules decrease a counter previously set up by the control
core with the number of requested sensor values needed
by the motion modules and the robot program. When
the counter becomes zero, the control core subsequently
activates the motion modules.
B. Real-time Middleware MiRPA-X
In order to facilitate the development of a control frame-
work as it is described in the preceding subsections, the
usage of a flexible and highly efficient communication and
synchronization infrastructure is necessary. As it is the
key functionality of all commercial middleware approaches
(CORBA, DCOM, etc.), MiRPA-X can be used simply as a
communication object server to handle data and procedure
requests in robot control systems transparently [1]. In order
to meet hard real-time requirements derived from the ap-
plication within complex parallel robot systems, it provides
additional mechanisms for hard-real-time data processing,
such as shared memory communication as well as process
scheduling and synchronization.
Fig. 4 shows a schematic overview of the communication
system used to interconnect the control system components.
Besides, the control modules (motion and sensor modules)
mentioned in section II-A, exemplary further modules
are situated on the application level. In order to facilitate
real-time data exchange between the central control unit and
external robot components (drives, sensors and actuators), a
high-speed communication bus (currently based on the IEEE
1394 standard) is used together with a specially tailored
communication protocol (Industrial Automation Protocol,
IAP). A detailed description of the overall communication
system is given in [6].
1) Message-Based Data Transfer: MiRPA-X uses QNX
message passing internally as the basic mechanism for
putting synchronous and asynchronous communication ser-
vices into reality. According to this, MiRPA-X can be ported
to any real-time operation system that supports this mecha-
nism. Application processes providing control level services
are regarded as servers, while service requesters are regarded
as clients. According to these roles, servers block on the
reception of specific queries and instructions. As soon as
they unblock by message reception, data interpretation and
calculation is performed and in general concluded with an
acknowledging reply to the requesting client. All message-
based communication is performed and controlled by the
key component of MiRPA-X, the object server. It is an
independent process within the system that evaluates in-
quiries issued by clients and forwards them to the respective
servers without data interpretation. The forwarding strategy
is based on a name service specifying application services
(e.g. MotionModule CalcAlgo). Servers are thus identified
using a representation for the service name based on a
hash mechanism. This kind of name service facilitates a
transparent and flexible way of implementing modular and
even redundant application services without reference to the
Fig. 4. Example Middleware-based Communication System
actual server and server location providing the service. a change of the cycle frequency and the resulting necessary
2) Shared Memory and Synchronization: Alongside rearrangement of our hard real-time processes a deeper un-
the message-based communication, MiRPA-X provides derstanding of module inter-dependencies, expert knowledge
a communication mechanism based on shared memory about the communication system and extensive testing to see
usage. As for messages, the shared memory mechanism if the constraints still hold after the change are required.
uses the MiRPA-X name service. The usage of shared
memory facilitates a high-speed, non-blocking data transfer <<device>>
Vision PC
<<device>>
Analysis PC <<device>> <<device>>
<<device>> <<device>>
between application processes, without the object server {OS=Windows} {OS=Windows} Sensor DSP n
<<device>>
Sensor DSP n
Actuator DSP 1
<<device>>
Actuator DSP 1
Sensor DSP
IAP 1 Actuator DSP
IAP 1
being involved in the actual communication task. After GUI SymTA/S
IAP ...IAP
registration, application processes directly read and write IAP IAP
TCP TCP
fast inter-process data using memory pointers provided Client Client

by MiRPA-X. For each shared memory region they act <<TCP/IP>>

<<IEEE 1394a>>

as publishers and subscribers, respectively. In the case of <<device>>

<<IEEE 1394a>> <<IEEE 1394a>>
<<device>> <<device>>
multiple application processes accessing the same shared Control PC 1 Control PC 2 Control PC n
{OS=QNX} {OS=QNX} {OS=QNX}
memory region, especially for complex control systems, TCP Robo- RCA
RCA 562 RCA 562
data integrity has to be ensured at any time. As shared Server Pret 562

memory access is neither blocking nor synchronized by MiRPA-XD

itself, MiRPA-X provides mutex and condition variable
mechanisms using the same name service as for messages
and shared memory.
C. Self-Management at the Present State of Development
At startup, the control core broadcasts a profile request
command to all motion modules and they deliver their
names and specific capabilities back into a prepared
synchronized shared memory area. The most important
properties of the motion modules are whether they are
able to operate in a hybrid control context and if they are
suitable to be used in the task frame formalism. Using this
information, the control core is able to decide whether the
requested module combination specified by the current skill
primitive is executable or not during runtime and which
transformations have to be performed during execution. This
ensures perfect scalability of the presented architecture: The
programmer simply starts up the processes of the motion
and sensor modules he wants to use within his program, no
further effort is required. Furthermore, the maximum and
minimum execution frequency of the modules is read from
the modules’ profile. So, if at the desired cycle frequency
the computational load has been too high in the current
control cycle, motion modules can be rescheduled to a
lower task execution frequency during runtime in order to
prevent the system from algorithm overload.
III. ADVANCED SELF-MANAGEMENT
Even though our software architecture is very generic
and modular [9], the self-management problem is gaining
new degrees of freedom with the next expansion stage of
our architecture, which is depicted in Fig. 5. Here several
networked control PCs are used to distribute the algorithmic
load in order to implement advanced capabilities such as
integrating vision sensors. The figure also shows the next
evolution step of the middleware MiRPA-X, where we have
added a “D” to take account for its distributed operation.
Since we have very rigid real-time constraints, for instance
MiRPA-
... MiRPA-
XD XD
IAP IAP IAP
Fig. 5. Next expansion state of our software architecture PROSA-X. The
algorithmic load is distributed between several control PCs.
Here, rearranging can mean distribution to remote proces-
sors and topology changes in terms of added or removed
control PCs. Therefore, instead of manually optimizing
the system effectiveness according to different criteria as
e.g. performance or robustness, we want to integrate self-
managers capable of performing this task. Those managers
will capsule expert knowledge in evaluation functions and
manipulation patterns and will be capable of judging and
influencing the behavior of components. In addition to self-
optimization, those management components will provide
other so called self-* properties [18] like self-protection
and self-healing. They follow the design suggestions of [5]
and incorporate different threads for monitoring, analysis,
complex planning and execution tasks, all using a common
knowledge base (see Fig. 6).
By embedding the self-manager threads in different real-
time layers we ensure that no real-time constraints are hurt by
the integration. The only part of the management component
working in the hard real-time context is the monitor. Even
though fuzzy inference and case based reasoning techniques
can be applied in deterministic time amounts, we are only
integrating self-management in the soft and no real-time
layers at the moment.
In the following, we describe the first realization of a
self-manager for our system as depicted in Fig. 6. Its area
of responsibility is the control core in the new distributed
version of our architecture (see Fig. 5) in which control
components can be spread over several control PCs. By
splitting the algorithmic load capsuled in motion and sensor
modules higher cycle frequencies and better algorithms be-
come possible. The information which control part is running
on which PC is stored in so called distribution patterns. The
self-manager is able to seamlessly adapt the control system to
topology changes, can find and verify beneficial distribution
 Self-Manager evaluation function, an optimization could be more perfor-
Analyser Planner mance (e.g. a higher cycle frequency) or more robustness
- evaluation function - distribution advantageous? (e.g. redundant execution, freeing execution time in the
- comparison with last - which components?
execution - where to?
cycle). It also could be triggered by a topology change where,
- positive effect due to - bandwidth for distributed for instance, additional control PCs got connected. The self-
prior distribution operation available
manager searches its knowledge base for an appropriate
Monitor
- component state
Executor distribution pattern and if there is none, one to be evaluated is
- acquire ressources
- system parameters - initiate distribution
transferred to the SymTA/S instance running on the analysis
- execution times
- topology changes
- cause monitoring of impact PC. After verifying if real-time constraints still hold after a
within Analyser
rearrangement of tasks or not, the distribution pattern gets
Knowledge transferred back to the self-manager and becomes part of its
- aim specification
- topology
knowledge base. Its executor component then can acquire
- execution times necessary resources, reconfigure the communication system
- available ressources (bandwidth, ...)
and trigger the migration or remote startup of tasks via
MiRPA-XD.

Control Core
Fig. 6. Self-Manager for the control core. This management component
provides different self-* properties and is capable to adapt the control system
to topology changes.
patterns, and trigger the migration of control components to
remote processors. Its integration realizes self-* properties
for this system part that are detailed in the following.
A. Self-Optimization
After system start, the knowledge base of the self-manager
already contains a few distribution patterns. Those patterns
are known to result in a working system and include, of
course, the starting pattern. There are also patterns in the
knowledge base that already got verified in prior runs, failed
to pass the verification, or caused errors before. We are
working on a pattern verification realized with the schedu-
lability analysis tool SymTA/S [3] that is running on a
separate analysis PC. Resources such as busses or processors,
tasks assigned to them, task dependencies, priorities and
deadlines are used for a formal verification of the real-time
constraints. The verification is realized with different algo-
rithms delivering worst case response times for isochronous
and asynchronous IEEE1394-based communication. Those
algorithms are an extension of a priority based principle by
Lehoczky [8].
The verification process can also be executed during
the runtime of the system. The TCP communication with
the analysis PC is demand driven and has a small time
consumption. A SymTA/S model on the main control PC
constantly gets refined with measured execution times, topol-
ogy information or changing task dependencies. When the
self-manager searches for ways to optimize the behavior of
the control core he also evaluates if the component could
perform better after a rearrangement of its different tasks.
This consideration is triggered by its constant striving
for self-optimization. According to its aim specification and
B. Self-Protection
The monitoring thread of the self-manager constantly
records all kinds of information relevant for the evaluation
of the control core’s behavior. By keeping track of execution
and response times, the analyzer thread is capable to recog-
nize when the system is approaching a critical system state.
Several critical settings are thinkable.
The motion and sensor modules of RCA562, bearing most
of the algorithmic load, reside within the soft real-time layer
of the architecture. Violations of real-time requirements,
meaning late responses of a module in most occurences can
be tackled with fallback solutions. Nevertheless, this gen-
erally signalizes a bad system performance. By measuring
the unused cycle time at the end of the outer control cycle
which serves as a buffer catching jitter caused by fluctuating
calculation or transfer times, the self-manager’s analyzer
can recognize that the system is approaching a performance
problem and search for a solution within its planner before
it occurs.
Another parameter capable to cause problems is the bus
load and the response times of remote modules that depend
on this load. Such bad response times can be caused by a
prior migration of a calculation module that resulted in an
heavily increased bus load because of strong dependencies
between the migrated and a local module. An appropriate
reaction of the self-manager after noticing a critical bus load
would be to reverse the previous migration or generally a
concentration of modules on less PCs.
Self-protection within our system does not mean protect-
ing the system against malicious external influences but to
anticipate error-prone system states and to initiate counter-
measures before an error actually occurs.
C. Self-Healing
Even with self-protection capabilities in place, errors can
occur that could not be foreseen and have a critical impact
on the system. In the hard real-time layer a violation of real-
time requirements inevitably leads to an error where the robot
is stopped in a controlled way and a global error state is
entered. This also can happen when a real-time constraint in
the soft real-time layer is hurt and no fallback solution exists
that can compensate the missing response of a module.
From within the error state the self-manager can analyze
the situation and try to return to normal operation by a
rearrangement of modules within the distributed architecture
and an corresponding reconfiguration of the communication
system. Therefore, it can use already verified distribution
patterns from within its knowledge base or trigger a new
verification if no patterns are available corresponding to the
actual or planned situation. Since the system is in a safe
and stable state after an error occurred, time consumption
of the formal analysis does not constrain this approach.
By the integration of self-* properties via self-managers, a
very flexible control core is realized that is able to seamlessly
adapt to environmental changes, to anticipate and prevent er-
rors, and to reconfigure itself after errors to return to normal
operation. The integration of a formal analysis verifies the ad-
herence to real-time requirements before a rearrangement of
components within the distributed architecture is conducted.
Another self-management capability already inherent in our
system is the self-configuration that takes place in different
parts of the system after startup as previously described in
section II-C.
IV. CONCLUSION AND FUTURE WORK
In this paper design principles for building a modular and
self-managing control architecture for handling and assembly
tasks have been presented. An example architecture consist-
ing of a significant portion of reusable components already
taking benefits from these principles could be successfully
applied to two different parallel kinematic robots.
In the near future, distributed execution of sensor and
motion modules will become available by developing a
distributed middleware called MIRPA-XD based on the IEEE
1394 standard as well as on Ethernet transceivers for PC
interconnection. This allows for the implementation of more
demanding motion and sensor modules in terms of compu-
tation time. Furthermore, it is planned to extend the existing
self-management capabilities and realize self-optimization
mechanisms during runtime. A distributed architecture will
be able to plan and optimize the scheduling with respect
to the modules’ profile information and the measurement of
their real behavior during execution autonomously.
The next challenge is to find the relevant process infor-
mation for robot control components, required for the self-
manager’s knowledge base and to capsule it in analysis and
planning algorithms.
The main aim for the future is to enable the control
designer to put less effort in architecture and component
design, allowing him to concentrate on the control algorithms
and assembly strategies themselves.
V. ACKNOWLEDGEMENTS
The authors are thankful for the given and still granted
support on Collaborative Research Center 562 by the German
Research Foundation (DFG). Acknowledgements are given
to QNX Software Systems Inc. for providing free software
licenses.
R EFERENCES
[1] K. Diethers, N. Kohn, M. Kolbus, T. Reisinger, J. Steiner, and
U. Thomas, “PROSA - A Generic Control Architecture for Parallel
Robots,” in Proceedings of MECHROB, 2004, pp. 3932–3928.
[2] T. Hasegawa, T. Suehiro, and K. Takase, “A Model-Based Manipu-
lation System with Skill-Based Execution,” Transactions on Robotics
and Automation, vol. 8, no. 5, pp. 535–544, 1992.
[3] R. Henia, A. Hamann, M. Jersak, R. Racu, K. Richter, and R. Ernst,
“System level performance analysis - the SymTA/S approach,” IEEE
Proceedings Computers and Digital Techniques, vol. 152(2), pp. 148–
166, 2005.
[4] J. Hesselbach, J. Maaß, and C. Bier, “Singularity prediction for parallel
robots for improvement of sensor integrated assembly,” Annals of the
CIRP, pp. 349–352, 2005.
[5] IBM Corporation, “Autonomic Computing: IBM’s Perspective on the
Stand of Information Technology,” January 2003. [Online]. Available:
http://www.research.ibm.com/autonomic/research/papers/
AC Vision Computer Jan 2003.pdf
[6] N. Kohn, J. Steiner, J.-U. Varchmin, and U. Goltz, “Universal Commu-
nication Architecture for High-Dynamic Robot Systems using QNX,”
in Proceedings of ICARCV, 2004.
[7] T. Kröger, B. Finkemeyer, and F. M. Wahl, “A Task Frame Formalism
for Practical Implementations ,” in IEEE International Conference on
Robotics and Automation, 2004, pp. 5218–5223.
[8] J. Lehoczky, “Fixed priority scheduling of periodic task sets with
arbitrary deadlines,” in Proceedings of the IEEE Real-Time Systems
Symposium, 1990, pp. 201–209.
[9] J. Maaß, N. Kohn, and J. Hesselbach, “Open modular robot control
architecture for assembly using the task frame formalism,” Interna-
tional Journal of Advanced Robotic Systems, vol. 3, no. 1, pp. 1–10,
2006.
[10] M. T. Mason, “Compliance and force control for computer controlled
manipulators,” IEEE Transactions on Systems, Man, and Cybernetics,
vol. 11, pp. 418–432, June 1981.
[11] C. Muller-Schloer, “Organic computing - on the feasibility of con-
trolled emergence,” in CODES+ISSS ’04: Proceedings of the Interna-
tional Conference on Hardware/Software Codesign and System Syn-
thesis (CODES+ISSS’04). Washington, DC, USA: IEEE Computer
Society, 2004, pp. 2–5.
[12] J. D. Schutter and H. V. Brussel, “Compliant Robot Motion II. A Con-
trol Approach Based on External Control Loops,” The International
Journal of Robotics Research, vol. 7, no. 4, pp. 18–33, Aug. 1988.
[13] J. D. Schutter and J. V. Brussel, “Compliant Robot Motion I. A
Formalism for Specifying Compliant Motion Tasks,” The International
Journal of Robotics Research, vol. 7, no. 4, pp. 3–17, Aug. 1988.
[14] L. Sciavicco and B. Siciliano, Modelling and control of robot manip-
ulators. McGraw Hill, London, 1996.
[15] J. Steiner, M. Huhn, and T. Muecke, “Model based quality assur-
ance and self-management within a software architecture for parallel
kinematic machines,” in Proceedings of the IEEE 3rd International
Conference on Mechatronics (ICM2006). Budapest, Hungary: IEEE
Computer Society, July 2006, pp. 55–60, iSBN: 0-7803-9713-4.
[16] U. Thomas, B. Finkemeyer, T. Kröger, and F. M. Wahl, “Error-tolerant
execution of complex robot tasks based on skill primitives ,” in
IEEE International Conference on Robotics and Automation, 2003,
pp. 3069–3075.
[17] U. Thomas, J. Maaß, F. Wahl, and J. Hesselbach, “Towards a new
concept of robot programming in high speed assembly applications,” in
IEEE International Conference on Intellegent Robotic Systems, 2005,
pp. 3932–3928.
[18] T. D. Wolf and T. Holvoet, Autonomic Computing: Concepts, Infras-
tructure, and Applications. Taylor & Francis, CRC Press, December
2006, ch. A Taxonomy for Self-* Properties in Decentralised Auto-
nomic Computing, ISBN 1420009354.