Apollon - Emanufacturing Experimental Setup

DELIVERABLE

Project Acronym: APOLLON
Grant Agreement number: 250516
Project Title: Advanced Pilots of Living Labs Operating in Networks
D.4.2 Experimental Setup
Revision: [V1.0]
Authors:
Deepak Agrawal, SAP AG, Germany

Project co-funded by the European Commission within the ICT Policy Support Programme
Dissemination Level
P Public X
C Confidential, only for members of the consortium and the Commission Services
Apollon – D.4.2 Experimental Setup

Revision History

Revision Date Author Organisati Description

on
1.0 15.09.10 Deepak SAP Deliverable draft structure,

Agrawal Research experimental set up for use cases,
description of hardware software
used and summary
23.09.10 João Lopes Fiapal Experimental setup for the use

cases at Fiapal Living Lab in
Portugal
28.09.10 Zoltán HVEC Experimental setup for use cases

Kabács at HVEC Living Lab, Hungary

The information in this document is provided as is and no guarantee or warranty
is given that the information is fit for any particular purpose. The user thereof
uses the information at its sole risk and liability.

Statement of originality:

This deliverable contains original unpublished work except where clearly
indicated otherwise. Acknowledgement of previously published material and of
the work of others has been made through appropriate citation, quotation or both.
APOLLON ICT PSP Project 2 Final Version, 10/11/2010

Table of Contents
1. Introduction ................................................................................................................ 4
2. Experiments at Living Labs .................................................................................... 5
2.1 Use Case 1: Plant Energy Monitoring and Management...................................... 5
2.1.1 Hardware requirements......................................................................................................... 6
2.1.2 Software requirements ........................................................................................................... 6
2.2 Use Case 2: Asset Viewing and Management .......................................................... 6
2.3 Use Case 3: Logistics traceability and optimization ............................................. 8
3. Middleware for Device Integration ..................................................................... 9
4. Experimental setup SAP Future Factory Living Lab at SAP Research
Center, Dresden, Germany ...........................................................................................10
4.1 Plant energy monitoring and management Use Case ........................................10
4.1.1 Use case specific Hardware.................................................................................................12
4.1.2 Use case specific Software ...................................................................................................12
4.2 Logistics traceability and optimization in a Factory Use Case........................12
5. Experimental setup: FIAPAL Living Lab, Palmela, Portugal .....................17
5.1 Energy Consumption Monitoring Use Case ...........................................................17
5.2 Asset Viewing and Management Use case..............................................................20
5.2.1 Data acquisition for production monitoring................................................................20
6. Experimental setup: HVEC Living Lab, Hungary ...........................................23
6.1 Asset Viewing and Management Use case..............................................................23
6.1.1 Use case specific HW ..............................................................................................................26
6.1.2 Use case specific SW ...............................................................................................................28
7. Summary ....................................................................................................................28


1. Introduction

This deliverable describes the experimental setup for the use cases to be realized and
implemented under the eManufacturing pilot in collaboration with and at the living
labs participating in APOLLON WP4 and partner SMEs situated at different locations
within EU. The use cases requirements and prerequisites are documented in the
deliverable D4.1. We briefly describe the generic use cases identified in consultation
and collaboration among living labs and SME partners. Furthermore the description
of use case at each living lab locations is illustrated. The generic and specific
description of experimental set up highlight the similarities and differences in the
hardware and software of the experimental setups at different living labs and partner
SMEs in Germany, Portugal and Hungary. Finally the document is concluded with
the summary of the experimental set up and collaboration among the living labs and
SMEs within EU.


2. Experiments at Living Labs

The experiments are set at three different locations in Germany, Portugal and
Hungary within EU for realizing the use cases. There are one or more use cases
to be implemented at each Living Lab (LL) location. Three use cases under this
work packages are described to give an overview of the reader. Each living lab
location will implement one or more of these use case with their SME partners.
Following is the list of use cases which will be implemented at each of the three
locations.
1) Future Factory living lab of SAP Research Center, Dresden (SAP AG)
(a) Monitoring the energy consumption of machine in a factory
(b) Tracking and tracing of tools and material in a factory
environment
2) Fórum da Indústria Automóvel de Palmela , Portugal (FIAPAL)
(a) Monitoring the energy consumption of an assembly line
(b) Asset viewing and management in a factory
3) Hungarian Vehicle Engineering Cluster, Hungary (HVEC)
(a) Asset viewing and management in a factory
2.1 Use Case 1: Plant Energy Monitoring and Management

The objective of this scenario is to monitor and manage energy consumption by
the machines in the production line of a plant. The energy consumption is
measured with the help of Smart Energy Meters connected to the plant machines
and consumption data are communicated to the energy monitoring applications
(An example of application UI is shown in Figure below) through the Device
Integration and Management Middleware. The middleware for device
integration (MDI) from SAP is Prototype software. There are different types of
smart energy meters available in the market. These meters either can
communicate directly with the middleware or through the intermediate
programmable logic control (PLC). A high-‐level view of how the energy
consumption and corresponding alert can be displayed is shown below (for
demonstration only). Different alert levels can be pre-‐defined according to the
amount of energy consumed. These alerts indicates the higher than expected
energy consumption which will be an indicator for the supervisor and or plant
manager to investigated the reason of high consumption and fix the problem to
bring the energy consumption within limit thus the energy consumption will be
managed.
The benefits of energy saving and its impact on carbon foot print of production
process demands production companies effective control on their energy
consumption and continuously monitor the energy consumption. Energy
monitoring and management services developed collaboratively by the IT SMEs
will be consumed by the end users and or other SMEs. Thus SMEs will be able to
collaborate and share their knowledge and expertise with other SMEs and other
stakeholders under the framework of this project and may pave the way for
future collaboration among them.


Figure 1: Energy Monitoring User Interface Mock-‐up © SAP AG, 2010
2.1.1 Hardware requirements

a) Standard x86 processors based operating environment with at least 1 GB
RAM and 2 GB free Hard Disk space.
b) Smart Energy Meter for measuring the energy consumption
c) Machines of which energy consumption is to be monitored
2.1.2 Software requirements

a) SAP Middleware for Device Integration
b) Standard Microsoft XP or Vista operating system preferred although the
platform can also execute on certain distributions of Linux.
c) A Java runtime Version 6 is required in addition to the free Eclipse IDE.
Other free libraries and dependencies will be provided.
d) Backend systems (such as databases, ERP (if required)).
e) Application software or advanced visualization libraries such as Adobe
Flex for visualizing consumption data.
2.2 Use Case 2: Asset Viewing and Management

Plant managers or shop floor supervisors like to know the status and health of
assets (machine, material, software and personnel) in a plant or at the shop floor
respectively. Asset related information helps them in optimizing the assets
utilization as well as in production planning. The objective of this scenario is to
present a uniform view of geographically distributed plant assets, such as
devices, machines, enterprise software systems, and personnel in the form of a
tree hierarchy and also update their health status (such as red, yellow, and
green) on a near real-‐time basis. The goal here is to give a high-‐level grouping
perspective based on different categories of entities to the plant managers or

shop floor supervisors. For illustration, the following figure shows how a
tentative asset hierarchy might look in the frontend UI of the platform (for
demonstration only). This scenario results will provide an administrator or the
shop-‐floor manager an overview of the distributed resources, their configuration
statistics and operational status. Furthermore, the visual hierarchy makes it easy
to group similar categories of entities and enables easy configuration of
electronic devices which communicate via standard data-‐transfer protocols.

Figure 2: Asset Viewing Mock-‐up © SAP AG, 2010

b) Plant assets like machines, personnel, software to be monitored at the
plant.

a) SAP Middleware for Device Integration.
e) Application software or advanced visualization libraries such as Adobe
Flex for visualizing consumption data.

2.3 Use Case 3: Logistics traceability and optimization

An important requirement of day-‐to-‐day functioning of distributed factory and
warehouse operation is the ability to track inventory. Inventory, amongst other
things, may mean tools, materials, and personnel. As part of this scenario,
partners will be involved in designing a localization architecture which will
facilitate tracking of tagged entities in a distributed factory/warehouse setting.
The overview of this scenario is illustrated in the following diagram:

Figure 3: Logistic traceability and optimization Mock-‐up © SAP AG, 2010
Here, wireless sensors installed at different locations of the plant emit signals
indicating the approximate location of an asset. An important element of this
scenario is to map these approximate coordinates into absolute warehouse/shop
floor locations which are identifiable in the warehouse management systems.
Localization architecture will help in identifying material flow on the shop-‐floor.
Furthermore, it will aid in asset monitoring and management (a part which is
essential in Warehouse Management).

b) Devices, tools, material, machines etc. to be traced in the plant.
c) Location aware sensors

a) SAP Middleware for Device Integration.
e) 3D tracking devices/sensors for locating assets across shop floor.
f) External database e.g. NewDB, SQL etc
3. Middleware for Device Integration

The Middleware for Device Integration (MDI) connects sensors, devices, systems,
and users in the physical world with the backend business systems. It provides a
lean, robust, scalable, and flexible architecture to enable the development of real
world integration applications across all industries. Furthermore, it has the
facility to offer a service development and composition framework for deploying
eManufacturing services across varied scenarios. MDI has three major parts
namely site manager, central instance and node.
MDI Site Manager is the design time tool for configuration. It is a plug-‐in for
Eclipse [www.eclipse.org]. Site Manager connects to the MDI Central Instance
(CI) which centrally holds the master copies of all configuration data and run
time agent code.
The run time consists of one or more MDI nodes. Each MDI node is a system
running the agents responsible for device connectivity and/or integration logic.
An MDI node may run on a regular PC server, an embedded PC, or within a
virtual machine. The MDI run time is built on Java technology and therefore
platform-‐independent (for instance, Microsoft and Linux builds are available).
MDI can be scaled by deploying additional MDI nodes. For example, an entire site
may be managed by one MDI node while a certain part of the site is managed by
a separate MDI node. MDI nodes are able to communicate in a peer-‐to-‐peer
fashion (e.g. an agent in one MDI node may subscribe to events dispatched by an
agent that runs on a different MDI node). All agents deployed within an MDI
node run in an OSGi environment [www.osgi.org; eclipse.org/equinox] which
enables dynamic code deployment without restart. This OSGi functionality
enables a minimal footprint for the run time while allowing the growth of this
foot print according the changing requirements.
All real-‐world entities that MDI communicates with are modelled as objects.
Objects are of a defined object type which can represent any abstract
representation or grouping of an entity (e.g. Site, ERP system, weigh scale,
Siemens S7-‐300 PLC). MDI comes with a number of pre-‐defined object types but
also allows the user or system integrator to define custom object types. All
objects are organized in a tree under the root object. The object hierarchy (also
referred to as the asset hierarchy) is entirely defined by the user and depends on
the actual use case. Normally, the object hierarchy mirrors the organization of

objects in the real world (for example, Plant Site > Production Line > Machine >
Barcode scanner).
If an object is not merely used as a grouping construct (e.g. Site), it is linked to
exactly one agent which provides the functionality to communicate with the
object. For example, an object of the type “weigh scale” may be linked to an agent
that provides connectivity to a manufacturer specific weigh scale.
Each object is uniquely identified throughout the entire MDI object hierarchy via
a custom-‐entered ID (e.g. “PLANT_DRESDEN_BARCODE_SCANNER_3”). If an
agent instance is linked to the object it will have the same ID as the object it is
linked to. This ID can be used by external systems to reference the object and the
services and events it provides.
4. Experimental setup SAP Future Factory Living Lab at

SAP Research Center, Dresden, Germany
4.1 Plant energy monitoring and management Use Case
This use case in the Future Factory Living Lab of SAP Research Dresden is about
energy consumption monitoring of the machines used in the lab e.g. milling
machine, 3D printer, robots etc for energy efficiency and sustainable production.
The experimental setup uses the energy meters for measuring the energy
consumption of variety of machines. The energy meters from different vendors
are used for this purpose e.g. Mitsubishi Electric, Plogg, and NZR energy meter
etc. Energy meter from Mitsubishi electric and Plogg are shown in Figure 4 and
Figure 5 respectively for your perusal.

Figure 4: Smart Energy Meter from Mitsubishi Electric © SAP AG, 2010


Figure 5: Smart Energy Meter ‘Plogg’ © SAP AG, 2010
The energy meters measure the energy consumption of the machine running in
the Future Factory e.g. milling machine and the consumption related data e.g.
time stamp, consumption in kWh and instantaneous consumption in kW are
communicated to ubigrate CC link adapters. MDI HTTP agent subscribes to the
data from glasnost using the MDI HTTP agent. The data are collected every few
seconds (schedule time can be adjusted) by the middleware and are event based.
Event based architecture register the events only to filter the data and avoid the
work load i.e. if there is change in consumption data then only new data are
communicated to the logic agent of MDI. There is another Xcelsius agent (SAP
BuinessObjects Xcelsius is an SAP reporting solution) which facilitates the
communication between MDI logic agent and the SAP Xcelsius Energy Dashboard
application (Shown in Figure 1). The block diagram of the architecture of the use
case is shown in Figure 6. The data received from the energy meters can be
stored in the external database (not shown in the figure 6) using the database
connector agent. These data can be used for future analysis and statistical
calculations.



Figure 6: Architecture of Energy Monitoring Use case © SAP AG, 2010
4.1.1 Use case specific Hardware

a) Smart Energy Meters used for the scenarios are meters from Mitsubishi
electric model EN96NSR and Plogg
(http://www.plogginternational.com/).
b) CC Link module from Mitsubishi
c) Milling Machines
4.1.2 Use case specific Software

a) Ubigrate adapter named glasnost (www.ubigrate.com)
b) SAP Xcelsius Dashboard for displaying energy monitoring in user friendly
mode
c) New DB database for storing the data received from the smart meters.
4.2 Logistics traceability and optimization in a Factory Use Case

Tracking of tools and materials is an important in factory’s shop floor because
time and effort required to search the desired objects on requirement delays the
production processes thus increases the overall cost of production. It also
generates the undesired inventory just because of lack of information about the
availability of the assets in the factory. Thus overall utilization efficiency of
available asset and production planning is reduced due to lack of information of
assets whereabouts.

Wireless localization is important for the object tracking because identification
of exact positions of moving objects allows accessing the asset quickly whenever
required specially in case of emergencies and plan most effective routes. The
wireless localization setup used for this use case is from partners SME Agilion.
We have used the hardware and related software for localization of assets on the
ground floor. The description of hardware and related software sourced from
Agilion is described later in this section. The localization information of the asset
are communicated to the Device Integration middleware (MDI) where the data
are processed and communicated to BECKHOFF PLC running OPC foundation’s
(www.opcfoundation.org) Unified Architecture (UA) server. The OPC UA is the
next generation OPC standard that provides a cohesive, secure and reliable cross
platform framework for access to real time and historical data and events.
ICONICS GraphWorkX (www.iconics.com) is the OPC Data Access client
applications, which cancan easily plug-‐n-‐play not only with ICONICS servers and
components, but other 3rd-‐Party hardware interface drivers and software as
well. GraphWorkX creates the graphics for Human-‐Machine Interface (HMI)
needs. GraphWorkX is used as a front end for displaying the localization data in
easy to understand way. The architecture of the asset tracking and tracing use
case is shown in figure 7.

Figure 7: Architecture for Tracking and Tracing of Tools and Material use case
© SAP AG, 2010

a) Agilion Mobile Tag: The mobile tags will be located in the wireless network.
People, material, tools and devices could be equipped with those tags. The
transmission of additional application specific data from and to the mobile
tags is also possible for getting the exact location of assets. There are two
types of wireless tag for this use case one is handheld tag shown in Figure
8. Wireless Handheld tags are used just by attaching it to the object need to
be tracked. A smaller wireless tag for personal tracking is shown in Figure
9. Small size makes it suitable for keeping inside the pocket of clothes worn
by the person. More information about the tags and or other parts
mentioned below is available at
http://www.agilion.de/Localization.htmlhttp://www.agilion.de/Localizati
on.html.

Figure 8: Agilion Wireless Tag Handheld © SAP AG, 2010

Figure 9: Agilion Wireless Tag for Personnel © SAP AG, 2010
b) Agilion Anchor: The anchor nodes are fixed at a position in the localization
network. These are the base points for positioning and could be used for
forwarding the position information as well. An Agilion Anchor is shown in
the Figure 10.



Figure 10: Agilion Wireless Anchor © SAP AG, 2010
c) Agilion Gateway: Gateways are the base points in the localization network
like Anchors. Furthermore they are the interface between the IT
infrastructure (e.g. Ethernet) and the wireless localization network. The IT
infrastructure is used for the exchange of localization information and
application specific data between the wireless localization network and the
localization database server. Depending on the size of localization
networks for larger number of mobile tags and correct position
information, large numbers of gateways are recommended for use. We
have used one Gateway in SAP Research Future Factory living lab in
Dresden, Germany.

Figure 11: Agilion Wireless Gateway Ethernet © SAP AG, 2010

d) BECKHOFF Programmable Logic Controller (PLC): The localization data
received from the Agilion localization wireless network is processed by the
MDI and communicated to the BECKHOFF PLC which host OPC UA server.
OPC UA server provides an interface with the ICONICS GraphWorkX where
the processed information is presented in user friendly format.

Figure 12: BECKHOFF PLC © SAP AG, 2010

a) ICONICS GraphWorkX: UI Application for displaying the data processed by
the middleware.
b) OPC UA Server & Client: Interface between middleware and UI application.
c) Agilion Location server: The Agilion Location server contains localization
and communication server applications for the determination of position
and tracking within the WIRELESS LOCATION SYSTEM as well as Client
applications for administration management and visualization. The
position calculation of the mobile tags is done on the localization server.
The server has interfaces for access to position information and application
specific data. Position information of mobile tags can be viewed using
Agilion 2D View application. Agilion 2D view is a client for visualization of
WIRELESS TAGs in plants upon ground plan or top view photographs.
Following are the software tools used for management and visualization.
Agilion Network Configuration is an administrative client for set up of the
wireless communication infrastructure and for configuration of
infrastructure components and WIRELESS TAG‘s. Agilion Localization
Configuration is an administrative client for configuration of localization
zones and configuration of localization technologies. Agilion User
Management is an administrative client for user management and
administration within the WIRELESS LOCATION SYSTEM. Agilion System
Management is a client for assignment of persons or processes to
WIRELESS TAGs. Typical personal numbers or delivery note numbers could
be referred to a WIRELESS TAG. Agilion 2D View is a client for visualization
of WIRELESS TAGs in plants upon ground plan or top view photographs.
5. Experimental setup: FIAPAL Living Lab, Palmela,

Portugal
5.1 Energy Consumption Monitoring Use Case
This use case in the Fiapal Living Lab will be carried out at SME Imeguisa. It will
consist of energy consumption monitoring at the main electricity board through
which all the machines are powered and also two key machines; CNC milling
machine and Pipe forming machine individually. The experimental setup uses
the energy meters for measuring the energy consumption.

a) Smart Energy Meters used are meters from ISA – iMeterRail
( www.isasensing.com ) shown in figure 13
b) Main electrical board shown in figure 14
c) CNC Milling Machine shown in figure 15
d) Pipe forming machine shown in figure 16

a) Monitoring application for displaying the data
b) Customized MDI Agents

Figure 13: Smart Meter ISA

Figure 14: Electrical Board Imeguisa



Figure 15: CNC milling machine Imeguisa

Figure 16: Pipe forming machine Imeguisa
The use case architecture is shown in Figure 17. The data is collected from the
sensors by an ISA proxy, it's then cached and available to the MDI agents using
web services. The agents then process and save the information in the database
to be available in the MDIMDI Site manager interface.


Figure 17: Architecture for Energy Monitoring use case
5.2 Asset Viewing and Management Use case

This use case under the FIAPAL Living Lab will be carried out at the Learning
Factory of CENI. The base scenario is a part of a manufacturing process of
electronics goods, which is presented in the following picture.
Insertion of Welding Sequencing Inspection Segregation of

small defective
components boards
Assembly Testing Assembly and Final assembly

touch-‐up

Figure 18:-‐ The process that provides the context for monitoring
5.2.1 Data acquisition for production monitoring

The sub-‐processes and workstations were selected considering two main
conditions:

a) The demonstration of a asset monitoring using different types of data
collected in industrial facilities and
b) The characteristics of existing equipment (automatic, semi-‐automatic and
manual)
Three processes were selected – board sequencing, assembly and touch-‐up. It is
not intended to monitor all variables characterising the whole production
process but simply to demonstrate the use of the platform for asset viewing and
management using the selected data in the selected workstations. The data from
following objects were collected.
Loader: The loader has several sensors that can be used for condition
monitoring and for output counting. Data is to be obtained at the output
connectors of a PLC OMRON SYSMAC C60P.
Screw drivers: The screw drivers have controllers (DOGA XS-‐38D) that supply
power and receive torque signal. Variables that can be read -‐ event OK, event not
OK and event cycle completion.
Manual welding tools: The manual welding tools do not provide any data
beyond energy consumption. A switch to detect the presence of a board in a jig
will be used.

(a) Loader (b) PLC
Figure 19: Loader from CENI and PLC from OMRON


Figure 20: Welding Station CENI

The monitoring application will calculate the higher level parameters like
Equipment Status; Units produced etc. and provide an intuitive HM interface to
display the selected variables on a visual dashboard. Output can be further used
for evaluation of:
-‐ Cycle time
-‐ Historical data for each variable and workstation
The global process provides an industrial scenario and the high-‐level application
demonstrates the value the complete solution may offer.
The three workstations present different challenges to test the Device
Integration middleware developed by SAP and an opportunity for expertise
development by the partners to do device integration.
From the application point of view, the data collected will be used to
• Monitor process / equipment status in real time
• Analyse historical (aggregated data), to decide, for example, where to
concentrate improvement effort
• Monitor production progress
• Characterise process performance with distribution functions and
features of some variables in order to create accurate models

a) Monitoring application for displaying the data
b) Customized MDI Agents
The use case architecture is shown in Figure 21. The data is collected from the
sensors by a proxy using RJ12 socket; it's then cached and made available to the
agents using the web services. The agents then process and save the information

in the database to be available through the ‘MDI Site manager’ interface.

Figure 21: Architecture of Asset Viewing and Management Use case at FIAPAL,
Portugal
6. Experimental setup: HVEC Living Lab, Hungary

6.1 Asset Viewing and Management Use case
This pilot project has the intention to collect assets information in the database
and to monitor production equipments for improving production efficiency. It is
very important, for maintenance and production planning, to know machine
efficiency and capacity for production works. This information is needed in real
time for fast reaction. This information will be collected through the sensors and
with the MDI developed agent thus helps to save time in data collection,
evaluation, reporting and visualization. A better maintenance and production
planning can be achieved. Visualization of real time data helps management for
faster reaction and better decision.
At present, data collection of machine failures, waiting times is done by operator
manually. The information is written in an Excel sheet. The evaluation of these
sheets happening once a week. This evaluation is made in Excel by using macros,
reporting briefly in PowerPoint or similar format.
Information to collect:
a) Nr. Of order
b) Nr. Of Asset

c) Name of product
d) Nr. Of shift
e) Production time
f) Preparation time
g) Waiting times:
i. No gas supply
ii. No energy supply
iii. Overheating
iv. No worker dedicated
v. Waiting for fork lift
vi. Waiting for material
vii. Waiting for Quality expert
viii. Maintenance
ix. SW failure
x. Machine failure
xi. Administration
xii. Shift change
xiii. Break for worker
xiv. “Smoking break”
xv. Machine check
xvi. Organizational, communicational failure
h) Indicators:
i. second / minutes
ii. number of failures
Today the performance and workload of the machines are monitored using the
manual documentation by the workers they also do manual evaluation and
summary.


Figure 22: Chart of operation time in Excel
KUKA would like to change the manual data collection to automatic real time
data gathering to reach following achievements
a) measure the real working time
b) collect the cause of work break and stopping time (these codes of
problem would come from the operator)
c) the status of machines would be visible on the PC of the machine room
group leader
d) there would be a bigger display to show the status of all machines (visual
colored information in real time)
Figure 23: Architecture of Asset Viewing and Management use case at HVEC in
Hungary
Sensors and relays installed on the machine send Data from the machine to the
Omron PLC. Omron PLC communicates with the middleware for device
integration through the Ethernet interface. Data received and processed by the
MDI are stored in the external database. A user interface will be developed

according to the requirement of application. The developed UI will fetch data
from through the MDI from the data base and or from the OMRON PLC for real
time asset monitoring.

Figure 24: Flow chart of monitoring
6.1.1 Use case specific HW

a) CP1W-‐CIF41 Ethernet interface
b) Terminal type: NT11-‐NT21
Data such as the production status and production results can be displayed on
terminal NT11-‐NT21. The display, numeric keys, and function keys are all
integrated into the front panel, which is convenient for the user. Bar graph
displays allow the progress of processes to be checked at a glance. More
information is avalaible here:
http://www.ia.omron.com/product/family/1889/index_l_u.htmlhttp://www.ia.
omron.com/product/family/1889/index_l_u.html



Figure 25: Terminal
c) Production machines of KUKA:
i. Trumph TC 500 cutting machine
ii. Trumph TC 5000 cutting machine
iii. Trumph TC 6000 laser-‐cutting
iv. Trumph L3030 laser machine
v. Amada LCE 645 laser machine
vi. Trumph V130 bending machine
vii. Trumph V130 bending machine
viii. Trumph V50 bending machine
ix. Trumph V170 bending machine
x. Amada HF -‐50 bending machine
From the above machines will be experimented min. three machines in the
usecase. Should there be positive impact on the daily process with these
machine, the experimetn will be extended to the other machines as well.
d) Sensors of the machines
Built in sensors of the machine or additional built on sensors will be used.
Which sensors will fit best for desired data collection is to be investigated.



Figure 26: An example: Laser cutting machine
6.1.2 Use case specific SW

a) Omron CP1E-‐N40DR-‐A PLC software
b) Developed user Interface/Monitoring Application
7. Summary
In this document we have briefly described three use cases and common
hardware and software required for the experimental set up of use cases. The
use cases were presented, discussed and agreed with partner living labs and
participating SMEs of the work package. The use case description is followed by
the brief description of SAP prototype middleware for device integration. SAP
middleware for device integration connect devices at the shop floor with the
business systems. The usage of hardware and application software varies due to
use of hardware from different vendors. These differences are highlighted in the
description of use cases to be realized at different living labs in Portugal and
Hungary respectively. The middleware will facilitate the collaboration among the
SMEs at different locations. For example service developed by the SME in
Germany can be consumed by the SMEs in Portugal using the hardware
manufactured by the SME in Portugal or SME in Hungary and vice versa.

Apollon - Emanufacturing Experimental Setup

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apollon - Emanufacturing Experimental Setup

Uploaded by

Copyright:

Available Formats

Project Acronym: APOLLON

Grant Agreement number: 250516

Project Title: Advanced Pilots of Living Labs Operating in Networks

D.4.2 Experimental Setup

Deepak Agrawal, SAP AG, Germany

Revision Date Author Organisati Description

1.0 15.09.10 Deepak SAP Deliverable draft structure,

23.09.10 João Lopes Fiapal Experimental setup for the use

28.09.10 Zoltán HVEC Experimental setup for use cases

Statement of originality:

APOLLON ICT PSP Project 2 Final Version, 10/11/2010

APOLLON ICT PSP Project 3 Final Version, 10/11/2010

APOLLON ICT PSP Project 4 Final Version, 10/11/2010

2. Experiments at Living Labs

2.1 Use Case 1: Plant Energy Monitoring and Management

APOLLON ICT PSP Project 5 Final Version, 10/11/2010

2.1.1 Hardware requirements

2.1.2 Software requirements

2.2 Use Case 2: Asset Viewing and Management

APOLLON ICT PSP Project 6 Final Version, 10/11/2010

2.2.1 Hardware requirements

2.2.2 Software requirements

APOLLON ICT PSP Project 7 Final Version, 10/11/2010

2.3 Use Case 3: Logistics traceability and optimization

2.3.1 Hardware requirements

APOLLON ICT PSP Project 8 Final Version, 10/11/2010

3. Middleware for Device Integration

APOLLON ICT PSP Project 9 Final Version, 10/11/2010

4. Experimental setup SAP Future Factory Living Lab at

APOLLON ICT PSP Project 10 Final Version, 10/11/2010

APOLLON ICT PSP Project 11 Final Version, 10/11/2010

4.1.1 Use case specific Hardware

4.1.2 Use case specific Software

4.2 Logistics traceability and optimization in a Factory Use Case

APOLLON ICT PSP Project 12 Final Version, 10/11/2010

APOLLON ICT PSP Project 13 Final Version, 10/11/2010

APOLLON ICT PSP Project 14 Final Version, 10/11/2010

APOLLON ICT PSP Project 15 Final Version, 10/11/2010

APOLLON ICT PSP Project 16 Final Version, 10/11/2010

5. Experimental setup: FIAPAL Living Lab, Palmela,

5.1.1 Use case specific Hardware

APOLLON ICT PSP Project 17 Final Version, 10/11/2010

APOLLON ICT PSP Project 18 Final Version, 10/11/2010

APOLLON ICT PSP Project 19 Final Version, 10/11/2010

5.2 Asset Viewing and Management Use case

Insertion of Welding Sequencing Inspection Segregation of

Assembly Testing Assembly and Final assembly

5.2.1 Data acquisition for production monitoring

APOLLON ICT PSP Project 20 Final Version, 10/11/2010

APOLLON ICT PSP Project 21 Final Version, 10/11/2010

Figure 20: Welding Station CENI

5.2.2 Use case specific Software

APOLLON ICT PSP Project 22 Final Version, 10/11/2010

6. Experimental setup: HVEC Living Lab, Hungary

APOLLON ICT PSP Project 23 Final Version, 10/11/2010

APOLLON ICT PSP Project 24 Final Version, 10/11/2010

APOLLON ICT PSP Project 25 Final Version, 10/11/2010

Figure 24: Flow chart of monitoring

6.1.1 Use case specific HW

APOLLON ICT PSP Project 26 Final Version, 10/11/2010

APOLLON ICT PSP Project 27 Final Version, 10/11/2010

6.1.2 Use case specific SW

APOLLON ICT PSP Project 28 Final Version, 10/11/2010

You might also like