IMPLEMENTING ORGANIC COMPUTING SYSTEMS WITH

AGENTSERVICE

∗

Florian Nafz, Frank Ortmeier, Hella Seebach, Jan-Philipp Stegh¨ofer and Wolfgang Reif

Lehrstuhl f¨ur Softwaretechnik und Programmiersprachen, Universit¨at Augsburg, D-86135 Augsburg, Germany

Keywords:

Organic computing, software engineering, design methods, multi-agent systems.

Abstract:

Designing and implementing Organic Computing systems is typically a difﬁcult task. To facilitate the con-

struction a design pattern for Organic Computing systems has been developed. This organic design pattern

(ODP) helps in modeling and designing a broad class of Organic Computing systems.

This paper focuses on the implementation of Organic Computing systems with the help of this pattern. The

core idea is to provide a generic implementation by mapping ODP artifacts to artifacts of a multi-agent frame-

work. The used framework – AgentService – is one of the few C# multi-agent frameworks. In this paper a

possible implementation as well as beneﬁts and limitations are described.

1 INTRODUCTION

A new trend in computer science is to make systems

organic (M¨uller-Schloer et al., 2004; Branke et al.,

2006). Organic here means, that the systems are capa-

ble of autonomouslyreacting to changes in their envi-

ronment. Such capabilities are called self-organizing,

self-healing, self-conﬁguring, self-adapting or simply

self-x (G¨udemann et al., 2006a). The basis for self-x

capability is often to give the systems some degrees

of freedom, which allow them to react to component

failures and/or changing environments. In (Seebach

et al., 2007) an organic design pattern for modeling

Organic Computing systems has been introduced. It

helps a lot for modeling and design, but unfortunately

artifacts of the pattern can not be directly mapped into

code. This is because ODP artifacts are deﬁned on

a very abstract level. Interaction on ODP level typi-

cally comprises – on the code level – sending a mes-

sage, relaying it, receiving it, interpreting it and acting

according to it. To facilitate construction of Organic

Computing systems it is useful to provide generic ref-

erence implementations of ODP models in a standard

programming language. In this paper C# has been

chosen as programming language and the multi-agent

framework AgentService (Boccalatte et al., 2006) is

∗

This research is partly sponsored by the priority pro-

gram “Organic Computing” (SPP OC 1183) of the German

research foundation (DFG)

used as communication infrastructure. Possibilities,

risks and experiences of this generic implementation

will be discussed in the following sections. They are

illustrated on a real-world case study from the domain

of production automation.

In Sect. 2 a brief introduction to the organic de-

sign pattern is given and Sect. 3 provides a similar

introduction to the multi-agent framework AgentSer-

vice. A generic mapping of ODP artifacts into

AgentService artifacts is shown in Sect. 4. The prac-

ticability and lessons learned are illustrated on a case

study from production automation (Sect. 5). Sect. 6

concludes the paper.

2 DESIGNING OC SYSTEMS

Design and construction of Organic Computing sys-

tems is often challenging. To facilitate the model-

ing of these systems, an organic design pattern (ODP)

has been developed. This pattern is suitable for char-

acterization and design of Organic Computing appli-

cations. It gives explicit descriptions (constructs and

rules) of how domain-speciﬁc models generally look

like and how they should be built. Speciﬁc applica-

tions are then instances of the ODP. The pattern in-

structs both the structure of the whole system and the

communication channels of system components.

Fig. 1 shows the ODP. The main components of

Nafz F., Ortmeier F., Seebach H., Steghöfer J. and Reif W. (2008).

IMPLEMENTING ORGANIC COMPUTING SYSTEMS WITH AGENTSERVICE.

In Proceedings of the Third International Conference on Evaluation of Novel Approaches to Software Engineering, pages 64-71

DOI: 10.5220/0001762700640071

 SciTePress

Figure 1: Organic design pattern (ODP).

Organic Computing systems are Agents. They pro-

cess Resources according to given Tasks. Every Agent

knows a set of Agents from which it can receive Re-

sources (Input), a set of Agents to whom it can give

Resources (Output) and a set of Capabilities which it

can provide. Which Capabilities an Agent performs

and from resp. to which Agent Resources are taken

resp. given is captured in its Role.

To ensure consistency Roles may be restricted by

OCL-constraints (Object Management Group, 2003)

which assert for example (constraint 1) that the role

assigned to an agent only includes capabilities the par-

ticular agent can perform.

Agents, Capabilities, Resources and Tasks are all

part of the functional aspects of the system and the

self-x infrastructure. They describe what has to be

done and what can be done. But the whole system

can only process Resources according to their Tasks

if Roles are distributed correctly among Agents. Al-

location of Roles to Agents is the core of the organic

part of the system. For ﬁnding a correct allocation

it is necessary to take Capabilities, Tasks and agent

topology (i.e. the connection between agents through

their inputs and outputs) into account. All organic in-

telligence may be speciﬁed in one entity: the virtual

centralized Observer/Control. This entity can then ei-

ther contain a (distributed) algorithm, which calcu-

lates role allocations or just a speciﬁcation of such an

algorithm.

This pattern allows ﬁrstly for splitting construc-

tion of functional and organic parts of the system in

two. Secondly, it allows for a generic speciﬁcation of

role allocation algorithms as logical problems. The

basic idea here is to describe valid (i.e. working) role

allocations with a logical formula, which has the de-

grees of freedom as free variables. Finding a valid

role allocation is then equivalent to ﬁnding a satis-

fying valuation of free variables of a formula. See

(Seebach et al., 2007) for more details. An example

system which is modeled as an instance of the ODP is

described in Sect. 5.

In the context of this paper it is now more impor-

tant to note, that ODP provides a generic modeling

formalism for Organic Computing systems. It con-

sists of a certain set of high-level artifacts, some inter-

action between them and some consistency rules. The

goal – in this paper – is to provide a generic transfor-

mation of an ODP model into executable code.

IMPLEMENTING ORGANIC COMPUTING SYSTEMS WITH AGENTSERVICE

Figure 2: Basic AgentService concepts.

3 AN INTRODUCTION TO

AGENTSERVICE

In this section, a short summary of the basic con-

cepts of AgentService is given. For a more detailed

overview see (Boccalatte et al., 2004). The AgentSer-

vice framework has been developed at the Univer-

sity of Genua and is one of the few C# agent plat-

forms. It incorporates all the basic concepts of a

FIPA-compatible

application, i.e. an Agent Man-

agement System as well as FIPA-compliant messag-

ing services and directory services. Furthermore, a

comprehensive code basis for agent development is

available in the form of the AgentService API. Ad-

ditional capabilities include persistence of agent state

and a plug-in system, which allows for the develop-

ment of enhancements to the platform itself. A sim-

pliﬁed overview of the most important parts of an

AgentService system is shown in Fig. 2.

The central components of AgentService are

Agents. An Agent comprises several instances of two

different classes: Behaviors and Knowledges. Behav-

iors encapsulate all actions an agent is able to per-

form, including communication with other agents and

manipulation of the environment and its knowledge

base. Knowledges contain everything the agent knows

about itself and its environment. In general, several

behaviors per agent may be active concurrently. If –

for example – an agent provides translation between

ﬁle formats, then this will be encapuslated in a behav-

ior. Several instances of this behavior may be created,

such that the agent can accept multiple translation re-

quests at the same time. These behaviors will then

The Foundation for Intelligent Physical Agents (FIPA)

deﬁned the industry standard for interoperable agents. With

the completion of the standard in 2001 a common basis for

communicating, mobile agent systems has been set to which

almost all modern agent platforms comply. The standard

includes deﬁnitions for protocols, message formats as well

as architectural foundations for agents systems. Details can

be found on the FIPA website (FIPA Website, 1996).

run concurrently and terminate as soon as they ﬁn-

ished their individual translation job. Note that all

behaviors access a common knowledge base (in this

example maybe a dictionary), which consists of all

knowledges known to the agent.

Before agents can exchange messages, a conver-

sation between the two peers has to be established. A

conversation provides a context for the message ex-

change and enables agents to subsume different mes-

sages to one instance of the protocol sequence. In-

coming conversations are accepted by the agent and

then forwarded to one of its behaviors which in turn

handles the protocol. Messages can be transferred

within these conversations by means of a proprietary

message format based on C#’s serialization facilities

or as standardized FIPA-ACL (FIPA ACL, 2002) mes-

sage codes.

Every time a behavior wants to access a knowl-

edge it has to lock the object ﬁrst. This enables dif-

ferent behaviors of an agent to concurrently manip-

ulate the shared understanding of their environment.

Knowledges may contain arbitrary classes and are ac-

cessed with methods provided by the agent frame-

work. Knowledge objects can automatically be per-

sisted by the framework to provide recovery in case

of a system crash. Conﬁguration of the platform and

the agents is contained in XML-ﬁles. These ﬁles de-

scribe the basic parameters of the framework as well

as the correct instantiation of knowledges and behav-

iors.

4 IMPLEMENTING OC SYSTEMS

WITH AGENTSERVICE

This section details a generic transformation of ODP

models into code using the AgentService framework.

Therefor, abstract ODP artifacts must be mapped in a

generic way to artifacts of AgentService framework.

An example of a concrete mapping (as an instance of

the generic mapping) will be presented in Sect. 5.3.

Table 1 gives an overview of the mapping:

There is a direct relationship between ODP’s no-

tion of an Agent and the agent artifact in AgentSer-

vice. Both entities are used for message dispatching

and as containers for the core functionality. An im-

portant difference to ODP is that AgentService does

not explicitly state which other agents are inputs or

outputs for resources. These associations are implic-

itly contained in the conﬁguration of the instance.

ODP allows constraints on possible work-ﬂows by

limiting the associated agents. In the implementation,

each agent is allowed to exchange resources with each

other hypothetically.

ENASE 2008 - International Conference on Evaluation of Novel Approaches to Software Engineering

Table 1: Relation between ODP and AgentService artifacts.

ODP Artifact AgentService Artifact

Agent Agent

VirtualCentralizedO/C Agent

Capability One generic behavior, which contains all

possible capabilities

Role Knowledge, which parameterizes the generic behavior

Role Allocation Set of knowledge

Task Need not be mapped explicitly, for self-healing and

self-conﬁguring.

Resource Knowledge

The Capabilities of the agent are contained in one

generic behavior: the DO behavior. It contains all

the logic for processing resources. It is generic in the

sense, that it contains all theoretically possible capa-

bilities this type of agent may have. The DO behavior

is typically restricted with a “has” knowledge. The

“has” knowledge corresponds to the Has association

of the ODP. Typically, an agent initially has all capa-

bilities its class provides. During runtime, certain ca-

pabilities might vanish, because an agent is no longer

able to perform these certain tasks. In such a case,

the HAS knowledge is manipulated to reﬂect the loss

of the capability and the application usually has to be

reconﬁgured to become functional again.

Note, that in addition to ODP in AgentService

some more communication infrastructure is needed

for passing Resources between Agents. While on

ODP-level this can simply be done by changing as-

sociations, on code-level it is necessary to implement

some handshake protocols. Therefore, agents incor-

porate two additional basic behaviors (besides the DO

behavior): GIVE and TAKE. GIVE and TAKE are

used to exchange resources between agents consis-

tently. They implement an exchange protocol which

basically consists of a handshake, the transmission or

reception of the resource itself and a concluding ac-

knowledgment. The GIVE and TAKE behavior can

be restricted with knowledges (i.e. to whom resp.

from whom resources may be given/taken). This

models the Input and Output associations of the ODP.

A Role is also implemented as a knowledge. This

knowledge describes which Capability of the generic

DO behavior the agent is currently conﬁgured to per-

form. It also states from which agents resources

should be accepted and to which they are to be given.

This is done by setting speciﬁc knowledges, which

conﬁgure (together with the knowledges represent-

ing the Input and Output associations) the GIVE and

TAKE behaviors. Role allocations are in consequence

a set of (role) knowledges. Summarizing a role in

AgentService means: (1) accepting certain resources

(with the TAKE behavior), (2) processing them (with

the DO behavior) and (3) relaying them (with the

GIVE behavior)

Tasks are not explicitly translated. This is be-

cause the current implementation aims only at self-

healing and self-conﬁguring systems. Therefore tasks

do not change dynamically. In the current imple-

mentation they are explicitly part of the virtual Ob-

server/Controller agent. In future additions it seems

to be possible to map them to speciﬁc knowledges.

The Resources which are processed by the agents

are mapped to knowledges as well. Resources are ex-

changed between agents according to the roles. Tech-

nically this is done using the GIVE and TAKE behav-

iors.

5 CASE STUDY

This section illustrates the presented transformations

on a real-world case study. The case study is an appli-

cation from production automation. In this paper only

a brief and informal description of it is given. A more

detailed description of the application and a report on

safety/self-healing related questions may be found in

(G¨udemann et al., 2006b; G¨udemann et al., 2006).

5.1 Application

The example describes a vision of tomorrow‘s pro-

duction systems. In contrast to a traditional pro-

duction cell, where the interaction between robots is

ﬁxed, a new adaptive production cell will dynami-

cally change its interaction schemes. In the example,

assume a production cell consisting of three robots,

which are connected with autonomous transportation

units.

Not all agents have all three parts. For examples agents

which produce or consume resources do not have TAKE

resp. GIVE.

IMPLEMENTING ORGANIC COMPUTING SYSTEMS WITH AGENTSERVICE

The functional goal of the cell is to process work-

pieces following a given speciﬁcation. Every robot

can accomplish three tasks: drilling a hole in a work-

piece, inserting a screw into a drilled hole and tighten-

ing an inserted screw. These tasks are done with three

different tools that can be switched. One scenario is,

that every workpiece must be processed with all three

tools in a given order (1st: Drill, 2nd: Inserter, 3rd:

Screwdriver). Workpieces are transported from and

to the robots by autonomous carts. Changing the tool

of a robot requires a lot of time (compared to using

it). Therefore the standard role allocation of the sys-

tem is to spread out the three tasks between the three

robots, and the carts transfer workpieces accordingly.

This situation is shown in Fig. 3.

Figure 3: The adaptive production cell.

Figure 4: Reconﬁgured production cell.

If now one robot has some kind of defect (for ex-

ample the drill of robot 1 brakes), then the cell can

reconﬁgure itself, such that production is again pos-

sible. This situation is shown in Fig. 4. Robot 3

and Robot 1 have switched their jobs and the carts

changed their routes accordingly. Other reconﬁgura-

tions work analogously.

5.2 The Application as Instance of the

Design Pattern

This example system is now designed using the ODP.

Fig. 5 shows the resulting design as an instantiation of

the organic design pattern. Some classes in this ﬁgure

carry a link to the corresponding super element of the

design pattern in the upper right corner.

The production cell model comprises three types

of Agents: Robots, AutonomousCarts and Storages.

Each agent encapsulates the functionality of the cor-

responding functional part of the system.

The capabilities of robots are Tools, autonomous

carts can Transport workpieces and storages can Store

workpieces. Each robot is equipped with a Drill, an

Inserter and a Screwdriver. Therefore Robot agents

get corresponding capabilities: Drill, Inserter and

Screwdriver. Due to the nature of the system Work-

pieces (instances of Resource) can only be given from

Robots (or Storages) to Carts or vice versa. This is

captured by restricting Input and Output associations.

The Task is a description of what has to be done

with the Resources. In the example: “ﬁrst drill a hole

(use Drill), then insert a screw (use Inserter) and ﬁ-

nally tighten the screw (use Screwdriver)”. A Robot-

Role deﬁnes which tool a robot has to use, from which

carts it is supposed to pickup workpieces and to which

carts it should give the workpieces.

This case study showed, that the organic design

pattern can be applied to organic applications without

difﬁculty. It turned out that the separation of func-

tional and organic aspects during the design process

is possible and very useful. Note, that only the static

aspects of the system are modeled and the reconﬁg-

uration is captured in the VirtualCentralizedO/C. The

next step to be done is to extend the pattern, espe-

cially the VirtualCentralizedO/C, with adequate soft-

ware engineering methods to include the currently

missing dynamics in the development process. A

more detailed discussion on modelling this case study

as an instance of ODP may be found in (Seebach

et al., 2007).

5.3 The Case Study in AgentService

The generic mapping of ODP to AgentService was

applied to this case study. Exemplary for all parts

of the case study, the mapping of robot agents is de-

scribed in a little more detail now. As mentioned

above, robot agents have three different capabilities

(Drill, Inserter, Screwdriver). They can give and take

ENASE 2008 - International Conference on Evaluation of Novel Approaches to Software Engineering

Figure 5: Instantiation of the organic design pattern for the adaptive production cell.

instances only from and to carts and they will per-

form their assigned role, whenever a workpiece is

available. If a tool brakes the robot triggers a re-

conﬁguration of the production cell which ultimately

leads to a new role allocation by the virtual Ob-

server/Controller. The following paragraphs show

how this behavior is modeled in AgentService with

the help of ODP artifacts.

Every agent contains a message ﬁlter which dis-

patches incoming conversationsto the behavior which

handles the protocol case. This ﬁlter receives the ﬁrst

message of a conversation and creates – depending

on the message’s content – a new behavior instance

which will handle the protocol. E.g. a Cart connects

to a robot and sends a “READY-FOR-UNLOADING”

message, thus indicating that it is currently carrying a

workpiece. The robot acknowledges the message and

starts the TakeWorkpieceFromCart behavior which is

an instance of the abstract TAKE behavior outlined in

section 4. The agent waits until a currently processed

workpiece has been retrieved by another cart and then

initiates a new conversation to the waiting cart. It sig-

nals that it is ready to get the workpiece from the cart,

the workpiece is transmitted and the cart is dismissed.

After the workpiece has been received, the behavior

ProcessWorkpiece (DO) is started. Now, the work-

piece is transformed according to the current role of

the Robot. The generic ProcessWorkpiece behavior

looks up the agent’s role in the corresponding knowl-

edge and compares it to the capabilities available to

the robot. If the role is part of the capabilities, the

workpiece is processed. After processing, the robot

checks if there is a cart available to pick up the work-

piece or waits for a cart to arrive. The cart must

announce its availability by sending a “READY-FOR-

PICKUP” message to the robot. When the cart has ar-

rived, the GIVEWorkpieceToCart behavior (GIVE) is

instantiated to transmit the workpiece to the cart. Af-

ter the protocol has ﬁnished, the loaded cart proceeds

to the next way point on its route and the robot is

ready to receive another workpiece. Note, that in this

implementation communication is asymmetric. Carts

are always the actors, who initially send messages.

Choosing symmetric or asymmetric communication

and deciding, which types of agents initiate commu-

nications is a domain speciﬁc design decision.

All agents can be reconﬁgured by the VirtualCen-

tralizedO/C, which is also implemented as an agent

in the following called O/C-agent. If one of the

agents indicates a failure to the O/C-agent, a “BEGIN-

RECONFIGURE” message is sent to all peers. On re-

ception of such a message, the robot aborts its on-

going conversations and all currently performed tasks

and sends its current conﬁguration (i.e. the HAS

IMPLEMENTING ORGANIC COMPUTING SYSTEMS WITH AGENTSERVICE

knowledge containing its capabilities) to the O/C-

agent (this is done by a speciﬁc RECONFIGURE be-

havior). By accumulating all received conﬁguration

data, the O/C-agent can compute optimal solutions.

Currently, the collected data is discarded and an al-

ternate, predeﬁned conﬁguration is transmitted to the

agents. Implementing different algorithms is current

work (right now constraint solvers like ALLOY (Jack-

son, 2000) are under evaluation). As different re-

conﬁguration algorithms do not have an inﬂuence on

the implementation of the system (besides the O/C-

agent), we will not go into more detail on computing

Role Allocations.

After a Role Allocation has been computed, the

the new DO knowledges are distributed among the

agents. For the robot this means in most cases that

it “switches its tool and changes the carts from/to

which it takes/gives workpieces”, e.g. from Drill to

Screwdriver. If this happens, it is usually necessary

to reroute the carts to reﬂect the new order of the

robots. After the exchange is complete all agents re-

set themselves and indicate their ability to continue

normal operation to the O/C-agent (implemented as

READY behavior). As soon as the O/C-agent has re-

ceived acknowledgments from all agents it resumes

the application by sending a “BEGIN-OPERATION”

message. RECONFIGURATION and READY behav-

iors are shared by all agent classes. The O/C-agent

uses one behavior to handle the communication dur-

ing a reconﬁguration cycle and one to generate the

new role allocation. The latter behavior is a stub and

can be used to implement the algorithm for this task

in the future.

Summary: The case study showed, that the

generic implementation helps a lot for building Or-

ganic Computing systems. A broad class of sys-

tems can be conveniently designed using the Or-

ganic Design Pattern. The presented architecture

gives a good guideline for implementation. Never-

theless some additional design decisions (like choice

of communication) have to be made during this pro-

cess. On the other hand this allows for more ef-

ﬁcient implementations. Technically, we made the

experience that AgentService is still a very young

framework. In particular, memory leaks appear dur-

ing runtime relatively frequently. As allocation and

de-allocation of knowledges is handled very deeply

within the AgentService runtime, we were not able

to ultimately solve these problems. We are in touch

with the AgentService developers in Genoa and it can

be hoped, that these problems will be solved in the

near future. We also connected the presented control

system to a physical simulation of the adaptive pro-

duction cell (using Microsofts Robotics Studio (Mi-

crosoft, )). This showed, that communication over-

head (introduce by a multi-agent platform) is not an

issue.

6 CONCLUSIONS

Organic Computing systems offer the door to a new

generation of software controlled systems. Their self-

X properties make them interesting for many domains

where dependability is an important aspect. On the

other hand, design, analysis, and construction of such

systems is a difﬁculttask. A useful aid in these project

stages is the use of guidelines and patterns.

In this paper we presented a design pattern for or-

ganic computing applications and a method for im-

plementation using C# and the multi-agentframework

AgentService. It turned out that a generic implemen-

tation is possible and that it is of great help when

building speciﬁc applications. The current state of

work only allows for a centralized controller and is

thus trimmed for medium scale applications, where

the number of agents is limited (<100) and computa-

tion time is not scarce. In future work a decentralized

controller using leader election seems not to difﬁcult

to implement.

When evaluating the implementation of the case

study, some minor technical problems with AgentSer-

vice’s libraries (i.e. memory leaks) were found. For

this reason the implementation of the case study took

longer than expected and some restrictions to func-

tionalities had to be applied. However, there is hoped

that these problems will be solved with the next ver-

sion of AgentService. It is also interesting to see how

efﬁciently other case studies can be implemented with

this generic implementation. Another open topic is

to compare the presented C# implementation with a

JAVA based generic implementation using the Jadex

framework.

REFERENCES

Boccalatte, A., Gozzi, A., Grosso, A., and Vecchiola, C.

(2004). Agentservice. In Maurer, F. and Ruhe, G.,

editors, SEKE, pages 45–50.

Boccalatte, A., Grosso, A., and Vecchiola, C. (2006). Im-

plementing a mobile agent infrastructure on the .net

framework. 4th International Conference in Central

Europe on .NET Technologies.

Branke, J., Mnif, M., M¨uller-Schloer, C., Prothmann, H.,

Richter, U., Rochner, F., and Schmeck, H. (2006).

Organic Computing – Addressing complexity by con-

trolled self-organization. In Proceedings of the 2nd In-

ternational Symposium on Leveraging Applications of

ENASE 2008 - International Conference on Evaluation of Novel Approaches to Software Engineering

Formal Methods, Veriﬁcation and Validation (ISoLA

2006).

FIPA ACL (2002). FIPA ACL Message Structure Speciﬁca-

tion. http://www.ﬁpa.org/specs/ﬁpa00061/.

FIPA Website (1996). FIPA, Foundation for Intelligent

Physical Agents. http://www.ﬁpa.org/.

G¨udemann, M., Ortmeier, F., and Reif, W. (2006a). Formal

modeling and veriﬁcation of systems with self-x prop-

erties. In Autonomic and Trusted Computing 2006,

Proceedings. Springer LNCS.

G¨udemann, M., Ortmeier, F., and Reif, W. (2006b). Formal

modeling and veriﬁcation of systems with self-x prop-

erties. In Yang, L. T., Jin, H., Ma, J., and Ungerer, T.,

editors, Proceedings of the Third International Con-

ference on Autonomic and Trusted Computing (ATC-

06), volume 4158 of Lecture Notes in Computer Sci-

ence, pages 38–47, Berlin/Heidelberg. Springer.

G¨udemann, M., Ortmeier, F., and Reif, W. (2006). Safety

and dependability analysis of self-adaptive systems.

In Proceedings of ISoLA 2006, 2nd Symposium on

Leveraging Applications of Formal Methods, Veriﬁca-

tion and Validation. IEEE CS Press.

Jackson, D. (2000). Automating ﬁrst-order relational logic.

In Proceedings of the ACM SIGSOFT 8th Interna-

tional Symposium on the Foundations of Software En-

gineering (FSE-00), volume 25, 6 of ACM Software

Engineering Notes, pages pp. 130 – 139. ACM press.

Microsoft. Microsoft robotics studio developer center.

M¨uller-Schloer, C., von der Malsburg, C., and W¨urtz, R. P.

(2004). Organic computing. Informatik Spektrum,

27(4):332–336.

Object Management Group, O. (2003). UML 2.0 OCL

Speciﬁcation.

Seebach, H., Ortmeier, F., and Reif, W. (2007). Design

and Construction of Organic Computing Systems. In

Proceedings of the IEEE Congress on Evolutionary

Computation 2007. IEEE Computer Society Press. ac-

cepted for publication.

IMPLEMENTING ORGANIC COMPUTING SYSTEMS WITH AGENTSERVICE