Monitoring Agents in Complex Products

Enhancing a Discovery Robot with an Agent for Monitoring, Maintenance

and Disaster Prevention

Leo van Moergestel

, Erik Puik

, Dani

el Telgen

, Hendrik Folmer

, Matthijs Gr

unbauer

Robbert Proost

, Hielke Veringa

and John-Jules Meyer

HU Utrecht University of Applied Sciences, Utrecht, The Netherlands

Utrecht University, Utrecht, The Netherlands

Keywords:

Agents, Monitoring Agent, Product Life Cycle.

Abstract:

Monitoring of computernetworks, complex technical systems like aeroplanes is common practice. In this paper

we discuss the use of a monitoring agent in a product. The product itself could be any product with sufﬁcient

hardware capabilities, but the focus is on the product enhancement by adding an embedded agent. This so-

called product agent can be a member of a multiagent system. In this way exchange of parts and subsystems

is possible. The possibilities and advantages of this concept are discussed as well as a more elaborate example

of the implementation in an experimental discovery robot.

1 INTRODUCTION

Agent technology for agile manufacturing was the

starting point of this research. In this research the

concept of a product agent was introduced. Every

product to be made starts as a software entity or agent

that is programmed to meet its goal: the production

of a single product. To be able to reach its goal this

agent knows what should be done to create the prod-

uct. This entity is called a product agent and it guides

the product along the production cells to be used for

manufacturing and it will collect all kinds of impor-

tant manufacturing data during the production pro-

cess. When the product is ﬁnished, this agent has all

the manufacturing details and this agent is still avail-

able for further use containing valuable information

about the product. The next step in this approach is to

investigate and study the roles of this product agent in

the other phases of the life cycle of the product.

In this paper we study the implementation of a

product agent that has not been used to create the

product itself, but this agent is created for a speciﬁc

phase in the life cycle of the product. First the use and

roles of agents in all phases of the life cycle are dis-

cussed as well as how agents could be implemented

for these different phases. Next we focus on the use

phase. The case study for our product agent in the

use phase is based on a discovery robot. This robot is

also introduced and globally described. After this de-

scription of the product, the embedding of the product

agent is discussed and some results of the implemen-

tation of the product agent in this complex system are

shown.

2 ROLE OF AGENTS IN THE

LIFECYCLE OF A PRODUCT

In ﬁgure 1 the life cycle of an arbitrary product is

shown. After the design, the product is manufac-

tured in the production phase, next the product is dis-

tributed. A very important phase is the use of the

product and ﬁnally the product should be recycled. In

all these phases, the product agent can play a role that

will be globally described in the next sections

Design Manufacturing Distribution Use Recycling

Figure 1: Life cycle of a product.

2.1 Design and Production

In our view the design of a product will be greatly

inﬂuenced by the individual end-user requirements.

This means that cost-effective small scale manu-

facturing will become more and more important.

In (Puik and Moergestel, 2010) and (Moergestel et al.,

2010) a manufacturing system based on a grid of

van Moergestel L., Puik E., Telgen D., Folmer H., Grünbauer M., Proost R., Veringa H. and Meyer J..

Monitoring Agents in Complex Products - Enhancing a Discovery Robot with an Agent for Monitoring, Maintenance and Disaster Prevention.

DOI: 10.5220/0004184500050013

In Proceedings of the 5th International Conference on Agents and Artiﬁcial Intelligence (ICAART-2013), pages 5-13

ISBN: 978-989-8565-39-6

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

cheap and versatile production units called equiplets

is described. This grid is capable of agile multipar-

allel production. In this model every single prod-

uct is guided through the production environment by

the already introduced product agent. This agent is

responsible for the manufacturing of the product as

well as for collecting relevant production information

of this product. This is normally a function of the

so-called Manufacturing Execution System (MES)

(Kletti, 2007). The result is that every product has

its own production journal in contrast to batch pro-

duction using a MES that generates one journal for a

whole batch of products. In ﬁgure 2 the agent based

manufacturing is depicted. In this ﬁgure the product

agent is hopping from equiplet to equiplet to guide the

product along the production machines or equiplets

and monitor success or failure of the production steps

(Moergestel et al., 2011). To make a smooth transition

equiplet A

equiplet C

equiplet B

equiplet agent

frontend A

product agent

product

agent

path

product flow

equiplet agent

frontend B

equiplet agent

frontend A

equiplet agent

frontend C

Figure 2: Product agent and equiplet agents during produc-

tion.

from design to production possible, the product agent

is designed as a co-design for the product. Because

of the fact that the same equiplets that are used in the

production phase are also used in the product design

phase, a short time-to-market can be realised. Though

this is all based on our own special production envi-

ronment, we expect this approach to be useful in other

production environments as well.

The concept of using agents for production is not

new. Among others a multiagent-based production

system is also developed by Jennings and Bussmann

(Bussmann et al., 2004). This system focuses on relia-

bility and minimizing downtime in a production line.

This approach is used in the production of cylinder-

heads in car manufacturing. The roles of the agents in

this production system differ from our approach.

2.2 Distribution

Product agents can negotiate with logistic systems

to reach their ﬁnal destination. Logistic applications

based on multi agents systems already exist (Burmeis-

ter et al., 1997). Information of product handling and

external conditions, like temperature, shocks etcetera

can be measured by cheap wireless sensors and col-

lected by the guidance agent during the transport or

after arrival at the destination. The handling and ex-

ternal conditions during transport can be important

during product use, especially for product quality,

maintenance and repair.

2.3 Use

The role of the product agent during the use of the

product could focus on several topics. The ﬁrst ques-

tion one should ask is: who will beneﬁt from these

agents, i.e. who are the stakeholders. In a win win sit-

uation both the end-user as well as the manufacturer

could beneﬁt from the information. If a product is a

potential hazard (in case of misuse) for the environ-

ment, the environment could also be a winner if the

agent is capable of minimizing the effects of misuse

or even prevent it.

2.3.1 Collecting Information

A product agent can log information about the use of

the product as well as the use of the subsystems of the

product. Testing the health of the product and its sub-

systems can also be done by the agent. These actions

should be transparent for the end-user. If a product

needs resources like fuel or electric power, the agent

can advise about this. An agent can suggest a product

to wait for operation until the cost of electric power is

low i.e. during the night.

2.3.2 Maintenance and Repair

Based on the logging information about the product

use and the use of the subsystems, an agent can sug-

gest maintenance and repair or replacement of parts.

Repairing a product is easier if information about its

construction is available. Also the use of a product or

the information about transport circumstances during

distribution can give a clue for repair. An agent can

also identify a broken or malfunctioning part or sub-

system. This could be achieved by continuous mon-

itoring, monitoring at certain intervals or a power-on

self test (POST).

An important aspect of complex modern products

is the issue of updates or callbacks in case of a lately

discovered manufacturing problem or ﬂaw. In the

ICAART2013-InternationalConferenceonAgentsandArtificialIntelligence

worst situation, a product should be revised at a ser-

vice center or the manufacturing site. Information

about updates or callbacks can be send to the prod-

uct agent that can alert the end-user in case it discov-

ers that it ﬁts the callback or update criteria. This is

a better solution for a callback than globally advertis-

ing the problem and alert all users of a certain product

when only a subgroup is involved.

2.3.3 Miscellaneous

Use of product agents could result in transparency of

the status of a product after maintenance by a third

party. The agent can report to the end-user what hap-

pened during repair so there is a possibility to check

claimed repairs. Of course the agent should be iso-

lated from the system during repair to prevent tamper-

ing with it. Recovery, tracking and tracing in case of

theft or loss are also possible by using this technique.

When the end-user wants to replace a certain device

by a new one, the product agent can give advice about

the properties the replacing device should have, based

on what the product agent has learned during the use

phase.

2.4 Recycling

Complex products will have a lot of working subsys-

tems at the moment the end-user decides it has come

to the end of its life cycle. This is normally the case

when a certain part or subsystem is broken. The other

remaining parts or subsystems of the product are still

functional, because in a lot of complex products the

mean times between failure (MTBF) of the subsys-

tems are quite different. The product agent is aware

of these subsystems or components and depending on

the economical value and the remaining expected life-

time these components can be reused. This could be

an important aspect of ’green manufacturing’. An im-

portant issue here is that designers should also take in

account the phase of destruction or recycling. Disas-

sembly and reuse of subsystems should be a feature

of a product for this approach to be successful.

The product agent can reveal where rare or expen-

sive material is situated in the product so this material

can be recovered and recycled. This way the prod-

uct agent can contribute to the concept of zero waste.

Zero waste is just what it sounds like - producing, con-

suming, and recycling products without throwing any-

thing away (Gunther, 2007).

3 PRODUCT TYPES

This approach of having an agent for a product could

be used on different kind of products, but one should

investigate if the ﬁnal product has intelligence and

hardware to communicate with the agent. Some prod-

ucts have this by nature (computers, cell-phones); for

other products (cars, machinery, domestic appliances)

it should be a small investment. An important aspect

will be the possibility to connect to certain subsys-

tems for monitoring important events. If temperature

is an important item for the product agent, connection

to a temperature sensor or at least a place where this

temperature data is available is a must. If this con-

nection is not available, a temperature measurement

system should be added to the agent.

3.1 Where do these Agents Reside?

A product agent should stay alive or at least the infor-

mation the agent has collected and the knowledge the

agent has learned should be available under all cir-

cumstances. To accomplish this, two solutions are

available. The agent can be a mobile agent moving

from platform x to platform y as depicted in ﬁgure 3a.

The other solution requires moving data (beliefs of

the agent) from one agent to a newly created agent as

shown in ﬁgure 3b. In our case both agents should

be product agents. The second solution is much eas-

product agent

Beliefs

product agent

Figure 3: Mobile agent versus moving data.

ier to implement because of the fact that only trans-

port of data is required, while in the case of mov-

ing agents, the whole executable should be adapted

to the new situation. Another advantage of the sec-

ond approach is that a product agent can be added

in any phase of the life cycle. This is also what has

been done for this speciﬁc research. A product agent

was added to a system in the use phase. The biggest

challenge for implementing the approach of a prod-

uct agent or guidance agent will be in the use phase.

This is where the product is under control of the end-

user and not as during the production under control

of the manufacturer. In the latter case an agent-based

MonitoringAgentsinComplexProducts-EnhancingaDiscoveryRobotwithanAgentforMonitoring,Maintenanceand

DisasterPrevention

infrastructure can be implemented for the production

system or production line. The same is true for trans-

port and even disassembly of the product. In case of

the use phase, the agents should reside in a system

that is connected to the product, but should be avail-

able at the moment the product itself is broken. This

is comparable to the case of the so-called black box in

aeroplanes. There are several possibilities, depending

on the type of product:

• The agent runs on its own separate hardware that

is closely tied to the product;

• The agent runs on the hardware of the product but

stores information on a special place on the prod-

uct itself. This information can be recovered after

breakdown;

• The agent runs on the hardware of the product but

stores information on a remote system;

• The agent runs on a remote system that has a con-

tinuous connection;

• The agent runs remote on a system using a ’con-

nect when necessary’ approach.

The last two options require a stub or entry point for

the remote agent to make contact with the product

system. The connection with the environment could

be established by wired or wireless sensors or sen-

sor networks as well as computer subsystems in the

product. Interaction with humans in the environment

could be established by a messaging system or human

computer interface (HCI).

4 DISCOVERY ROBOT

This section gives details of the a discovery robot that

was built by our research group. To investigate the

implementation of the product agent during the use

phase, the product agent was embedded in this com-

plex technical system. To understand the details of the

product agent implementation, it is important to have

a global understanding of the construction and work-

ing of the discovery robot. In this section we present a

short overview of the robot capabilities, the architec-

ture, the software and an example of a result produced

by the robot system.

4.1 Robot Capabilities

The robot that will be used as a platform for the prod-

uct agent is capable of mapping a room with objects

by using a laser scanner. The robot can move by itself

using the map that has been created by the laser-scan.

It is possible to direct the robot to a certain point in its

map. The robot is also capable to avoid newly intro-

duced obstacles and other moving objects. This robot

is used as a system that will be enhanced by a product

agent.

4.2 Architecture

Figure 4 shows a picture of the hardware of the robot.

Two motors are connected to two wheels. Two swiv-

elling wheels are added to keep the platform in bal-

ance. Attached to the platform is the laser scanner,

printed circuit boards, a WiFi transceiver, a camera

and a set of ultrasonic sensors placed in a circle at the

edges of the platform. These ultrasonic sensors are

not yet used at this stage.

A block diagram of the robot is depicted in ﬁg-

ure 5. An important aspect is shown in this ﬁgure. An

external computer is part of the system. This com-

puter is used to do the heavy calculation to generate

the map information, to display the map in real-time

and to plan the path the robot has to follow. A wireless

Ethernet connection (WiFi) connects the robot with

this external system.

Figure 4: Discovery robot.

WiFi

Main board

(Debian Linux)

Laser

scanner

Camera

Mechanical

Subsystem

(motors,

wheels

controller,

encoder)

External System

(Ubuntu Linux)

Robot

WiFi

Figure 5: Block diagram of the robot.

4.3 Software

The software for this robot is based on ROS. ROS

is an acronym for Robot Operating System (Quigley

et al., 2009). ROS is not really an operating system

ICAART2013-InternationalConferenceonAgentsandArtificialIntelligence

/talker

/chatter

/listener

node

topic

Figure 6: Two nodes connected by a topic.

but it is middle-ware specially designed for robot con-

trol and it runs on Linux. In ROS a process is called

a node. These nodes can communicate by a publish

and subscribe mechanism. In ROS this communica-

tion mechanism is called a topic. Figure 6 shows the

relation between two nodes and one topic.

A node that produces data can publish this in one

or more topics. Other nodes interested in these data

can subscribe to one or more topics. TCP/IP is used to

actually carry out the communication. This platform

has been chosen for the following reasons:

• open source, so easy to adapt, compliant with a lot

of open source tools;

• wide support by an active community;

• huge amount of modules already available;

• nodes that are parts of ROS can live on several

different platforms, assumed that a TCP/IP con-

nection is available.

The mapping is done using SLAM. SLAM stands for

Simultaneous Localisation And Mapping (Durrant-

Whyte and Bailey, 2006). This module was already

available in ROS and ﬁtted well to the on board laser

scanner.

4.4 Results

The results of a mapping in progress are displayed in

ﬁgure 7.

Here the robot mapped the corridors in a rather

big building with three wings. The corridors are plot-

ted as a light grey shape. The length of the longest

corridor in this map is about 50 meters. In this stage,

the robot is not yet autonomous, but is controlled by a

human operator that uses the external system and the

on-board camera to guide the robot during the map-

ping. When the map is completed, the robot is capa-

ble to navigate autonomously to a given point in the

map, even if new or moving obstacles are introduced

in the mapped environment.

5 EMBEDDED PRODUCT AGENT

This section describes the product agent and also

shows some results of its functioning.

Figure 7: 2D Mapping of a building.

5.1 Functional Requirements

The product agent that is added to the robot has the

following requirements:

• monitoring status of the system or subsystems;

• monitoring health of the system or subsystems.

The difference between health and status will be

explained in the next subsection;

• react only in case of emergency;

• the robot should operate without the agent;

• making useful data available to the outside world,

like construction details, materials used and its lo-

calisation in the robot.

5.2 Implementation

The ﬁrst step in implementing this robot is to make

an overview of information available in the system.

Different types of information are considered:

1. status: is data available and of interest to the prod-

uct agent and/or the end-user;

2. health: has to do with the condition of compo-

nents that have mechanical parts or deteriorate

during use;

3. alarm: an internal condition that could result in a

troublesome situation or disaster;

4. additional information: this is the information that

was conceived in earlier phases of the life-cycle.

Because the ROS environment is already available, it

seems a natural choice to use this environment to im-

plement the agent. The agent consists of ROS-nodes,

ROS topics and some other subsystems. In ﬁgure 8

the internal modules of the agent are shown. All parts

surrounded by an ellipse are ROS nodes. The rectan-

gles represent topics. For human interfacing a small

MonitoringAgentsinComplexProducts-EnhancingaDiscoveryRobotwithanAgentforMonitoring,Maintenanceand

DisasterPrevention

health

status

alarm

System_logger

WiFi_monitor

R_motor_monitor

L_motor_monitor

Battery_monitor

Product Agent

Web_server

Alarm_Handler

Figure 8: Architecture of the product agent.

Product

Agent

Web_client

Data_storage

OS Shutdown

WiFi

Motors

Battery

Linux OS

Figure 9: The product agent and its environment.

web server is included. This server is capable to serve

static pages, containing technical data about the robot

as well as dynamic pages containing data collected

during use. Figure 8 shows the the internal parts of the

product agent and ﬁgure 9 shows the product agent in

its the environment. The product agent interacts with

its environment. The agent gets its information from

the robot and its operating system. The agent will log

this information and can also display information on

a web browser (web client) by using the aforemen-

tioned webserver. A shutdown can be performed in

case of a certain alarm condition.

5.3 Monitoring Status

The monitoring function is an important aspect of the

product agent. In our prototype a selection of pos-

sibilities was made. A node will monitor the use of

the motors and this will be available to subscribers of

the health topic. The status topic is comparable to the

health topic, but here information is made available

that is not a result of the wear and tear of for example

mechanical parts or of the de-charging of the battery,

but is a result of measurements of interesting data like

the strength of the WiFi signal. There is one topic

that can trigger a node that will issue a system shut-

down. This topic is called the alarm topic. Apart from

these nodes, the agent can also retrieve its information

directly from the Linux environment. Commands are

available to get the CPU-load and memory usage. The

pseudo ﬁlesystem /proc offers also a wealth of tech-

nical information that can be useful for the product

agent. Examples of what can be retrieved from the

product agent are plots displayed in the following two

ﬁgures. Figure 10 shows a picture of the strength of

Figure 10: Strength of the WiFi signal.

Figure 11: CPU load.

the WiFi signal. The robot ﬁrst moved away from the

wiﬁ access point and then returned towards the wiﬁ

access point again. The plotted data show a global

decreasing and again an increasing trend but there are

also strong ﬂuctuations. These ﬂuctuations are nor-

mal and due to all kinds of reﬂections and interference

that occur in an indoor environment. In ﬁgure 11 the

load of the processor is plotted. This curve is quite

smooth and shows that the available processor power

is adequate to operate the robot platform.

5.4 Monitoring Health

In the robot there are two candidates for monitoring

the health. The motors and the battery. The battery

should be monitored because of the fact that, like al-

most all rechargeable batteries, it can be re-charged

and de-charged a ﬁnite amount of times and informa-

tion of its remaining charge is valuable information to

the end-user that operates the robot. In ﬁgure 12 the

status of the battery is plotted during 90 minutes of

operation of the robot. A steady decrease is shown as

might be expected.

5.5 Alarm Conditions

In this section an alarm condition will be described.

The fact that the type of battery that is used in the

robot should never be completely discharged gives

rise to such an alarm condition. When the charge ca-

pacity drops below 10% a system shut-down action

should be triggered. By shutting down the system,

ICAART2013-InternationalConferenceonAgentsandArtificialIntelligence

Figure 12: Charge status of the battery.

the discharge of the battery will stop, thus prevent-

ing the loss of a rather expensive component. To im-

plement this feature an Analog to Digital Converter

(ADC) should be available to check the status of the

battery.

5.6 Extra Functionality

The extra functionality that is offered by our imple-

mentation is embedded documentation and a mapping

of materials and components that are of interest dur-

ing the recycle phase. The information is offered us-

ing the same web-interface as was used in the moni-

tor section previously discussed. The documentation

is comparable to printed documentation that could be

bundled with any device. This includes a user manual,

a technical manual and a maintenance manual includ-

ing a trouble shooting section.

In ﬁgure 13 a webpage is displayed showing the

subsystems of the robot. This allows the user to select

a subsystem to get more dertailed information about

that speciﬁc subsystem. Important information for the

recycle phase is also offered using the web interface.

Figure 13: Discovery robot.

Two different approaches are implemented. Using the

web interface, one could point at any part of the robot

and receive information about the ’ingredients’. An

example is given in ﬁgure 15. Here the wheels are se-

lected and as a response the information about the ma-

terial available in these parts is displayed (ﬁgure 14).

The materials as well as other relevant information

is displayed. Another approach is presented in ﬁg-

Figure 14: Motor and wheel subsystem.

Figure 15: Materials in the robot.

Figure 16: Where is the gold hidden?

ure 15. A list of interesting materials is presented and

by clicking on an item, the subsystems containing this

material are highlighted as shown in ﬁgure 16, where

the subsystems containing gold are shown.

These examples only show the interface designed

for human users. The information is also available in

a machine readable form using XML.

MonitoringAgentsinComplexProducts-EnhancingaDiscoveryRobotwithanAgentforMonitoring,Maintenanceand

DisasterPrevention

6 RELATED WORK

The work on ROS played a very important role in

this research. By using ROS we had a stable and

well developed platform for our robot. The use of

proven modules prevented reinventing solutions to al-

ready solved problems. The work on discovery robots

is huge, (Wnuk et al., 2006) and (Blazovics et al.,

2011) show some developments focussing on multi-

agent and swarm solutions. Agents for distribution,

logistic applications and product manufacturing al-

ready exist (Paolucci and Sacile, 2005). In most sit-

uations agents represent human operators or negotia-

tors. Jennings and Bussmann introduce the concept of

a product agent, in their terms workpiece agents, dur-

ing the production. These agents do not however per-

form individual product logging. The use of a product

is also studied by observing and/or interviewing end-

users (Nielsen and Levy, 1994) (Nielsen and Mack,

1994). Some software applications do connect with

their originating company to report the use by end-

users.

Several proposals and implementations of includ-

ing monitoring and documentation within the product

itself are made and implemented. Burgess (Burgess,

1998) (Burgess et al., 2002) describes Cfengine that

uses agent technology in monitoring computer sys-

tems and ICT network infrastructure. In Cfengine,

agents will monitor the status and health of software

parts of a complex network infrastructure. These

agents are developed and introduced in the use phase

of this infrastructure and focus on the condition of the

software subsystems. In our approach this monitoring

function for hardware and software is the role of the

product agent but that role has been played already by

an agent during the manufacturing phase where valu-

able information that can be useful to the end-user has

been collected. Actually this product agent in the use

phase is not necessarily the same software entity that

played the role of product agent during production,

but the belief base of the product agent is kept intact

and handed over to a new incarnation of the product

agent.

In (Hamilton et al., 2007) an integrated diagnos-

tic architecture for autonomous underwater vehicles

is described. In this work the focus is on an intelligent

system for system diagnostics. The architecture uses

a variety of domain dependent diagnostic tools (rule-

base, model-based methods) and domain independent

tools (correlator, topology analyzer, watcher) to ﬁrst

detect and then diagnose the location of faults. This

work could be used and combined with the model

present in the current paper, because the artiﬁcial in-

telligence based techniques can applied in the product

agent. Our work expands the idea of diagnosis and

related data to the whole lifecycle of a product. By

using this same agent again in the ﬁnal phase of the

life-cycle, component reuse and smart disassembly is

a very important aspect when it comes to recycling of

rare or expensive building material. The status of the

quality of used sub-parts is available from and pre-

sented by the product agent.

In (Ashton, 2009) the concept of the ’Internet of

Things’ is explained by the ﬁrst user of the term ’In-

ternet of Things’. The main idea of this concept is that

the content of Internet is not only built and used by

humans and therefore largely depending on humans,

but the content will also be built by things connected

to the Internet that are programmed to do so. The

work presented in the current paper shows a possible

technique to implement this concept of the ’Internet

of Things’.

7 DISCUSSION

In this paper the focus was on implementing a prod-

uct agent in a complex product. This product was a

discovery robot but could have been any other tech-

nical system. For every system the requirements for

a product agent should be speciﬁed. However some

global speciﬁcations are applicable for every system.

The choices for monitoring subsystems made in this

research were limited only to a few due to the fact that

a proof of concept was the goal of this research. The

actions the agent can perform are in this case display-

ing and storing system status and system health sta-

tus as well as system design and technical data. The

agent is not inﬂuencing the robot itself however one

alarm condition is implemented resulting in a system

shut-down. It is not a difﬁcult task to expand the ca-

pabilities of the agent. The robot itself will be further

developed. For the product agent a wide variety of fu-

ture enhancements is possible, especially when prod-

uct agents of a certain type of product are united in a

multiagent system:

• A model that builds a failure overview of subsys-

tems. This way an accurate insight in the relia-

bility of subsystems and components can be ob-

tained. This model only works if a huge amount

of product agent are participating.

• On behalf of the end-user, a product agent can re-

port component failure and suggest or order re-

placement parts.

• An interesting model to implement the previ-

ous feature could be a marketplace in cyberspace

where product agents can negotiate with other

ICAART2013-InternationalConferenceonAgentsandArtificialIntelligence

product agents about exchanging parts.

In all these enhancements special attention should be

paid to security and the protection of privacy of the

end-users of product agent enhanced systems. An im-

portant aspect is the fact that the agent should store its

information at a safe place in case the robot hardware

will fail. In our case this is the remote system where

the agent has the possibility to store important data.

8 CONCLUSIONS

Product agents can play an important role in every

part of the life cycle of a product. An important prop-

erty of these agents is that they should have no direct

impact on the product or system they are living in.

However useful information should be collected and

in case of disaster, these agents should keep a log of

the events leading to the disaster.

Product agents can be a virtual digital equivalent

of a product and this concept will be an enabling tech-

nology in implementing the internet of things.

The concept presented here is a natural evolu-

tion of the concept of using agents during produc-

tion. However in case of products made by production

technology not based on agent technology, a product

agent can be added afterwards, as described in our

case study. The information that could have been

collected during design and production is added af-

terwards and will play a role in the recycle phase or

maintenance during use phase.

The ROS platform proved to a very good plat-

form to implement the product agent. This is because

of the fact that the data-communication infrastructure

between nodes is already implemented in a way that

helps a lot in both the design and the implementation

of the product agent.

REFERENCES

Ashton, K. (2009). That ’the internet of things’ thing. RFID

Journal, (22 july).

Blazovics, L., Varga, C., Csorba, K., Fehr, M., Forstner,

B., and Charaf, H. (2011). Vision based area dis-

covery with swarm robots. Second Eastern European

Regional Conference on the Engineering of Computer

Based Systems, ecbs-eerc, pages 149–150.

Burgess, M. (1998). Cfengine as a component of computer

immune-systems,. Proceedings of the Norwegian In-

formatics Conference.

Burgess, M., Hagerud, H., Straumnes, S., and Reitan, T.

(2002). Measuring system normality. ACM Transac-

tions on Computer Systems (TOCS) Volume 20 Issue

2, pages 125–160.

Burmeister, B., Haddadi, A., and Matylis, G. (1997). Appli-

cation of multi-agent systems in trafc and transporta-

tion. IEEE Proceedings on Software Engineering 144

(1), page 5160.

Bussmann, S., Jennings, N., and Wooldridge, M.

(2004). Multiagent Systems for Manufacturing Con-

trol. Springer-Verlag, Berlin Heidelberg.

Durrant-Whyte, H. and Bailey, T. (2006). Simultaneous lo-

calization and mapping (slam): Part i the essential al-

gorithms. Robotics and Automation Magazine 13 (2),

pages 99–110.

Gunther, M. (2007). The end of garbage. Fortune.

Hamilton, K., Lane, D., Brown, K., and Taylor, J. (2007).

An integrated diagnostic architecture for autonomous

underwater vehicles. Journal of Field Robotics,

(24(6)):497–526.

Kletti, J. (2007). Manufacturing Execution System - MES.

Springer-Verlag, Berlin Heidelberg.

Moergestel, L. v., Meyer, J., Puik, E., and Telgen, D. (2010).

Simulation of multiagent-based agile manufacturing.

CMD 2010 proceedings, pages 23–27.

Moergestel, L. v., Meyer, J., Puik, E., and Telgen, D. (2011).

Decentralized autonomous-agent-based infrastructure

for agile multiparallel manufacturing. ISADS 2011

proceedings, pages 281–288.

Nielsen, J. and Levy, J. (1994). Measuring usability: pref-

erence vs. performance. ACM.

Nielsen, J. and Mack, R. (1994). Usability Inspection Meth-

ods. John Wiley & Sons.

Paolucci, M. and Sacile, R. (2005). Agent-based manufac-

turing and control systems : new agile manufacturing

solutions for achieving peak performance. CRC Press,

Boca Raton, Fla.

Puik, E. and Moergestel, L. v. (2010). Agile multi-parallel

micro manufacturing using a grid of equiplets. IPAS

2010 proceedings, pages 271–282.

Quigley, M., Gerkey, B., Conley, K., Faust, J., Foote, T.,

Leibs, J., Berger, E., Eheeler, R., and A., N. (2009).

Ros: an open source robot operating system. Open-

Source Software workshop of the International Con-

ference on Robotics and Automation (ICRA).

Wnuk, K., Fulkerson, B., and Sudol, J. (2006). A scal-

able architecture for multi agent vision based robot

scavenging. American Association for Articial Intelli-

gence.

MonitoringAgentsinComplexProducts-EnhancingaDiscoveryRobotwithanAgentforMonitoring,Maintenanceand

DisasterPrevention