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
C
Confidential, only for members of the consortium and the Commission Services
X
Apollon – D.4.2 Experimental Setup
Revision History Revision Date
Author
Organisati on
Description
1.0
15.09.10 Deepak Agrawal
SAP Research
Deliverable draft structure, 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 Kabács
HVEC
Experimental setup for use cases 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
Apollon – D.4.2 Experimental Setup 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.2.1 Hardware requirements......................................................................................................... 7 2.2.2 Software requirements ........................................................................................................... 7 2.3 Use Case 3: Logistics traceability and optimization ............................................. 8 2.3.1 Hardware requirements......................................................................................................... 8 2.3.2 Software requirements ........................................................................................................... 9 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 4.2.2 Use case specific Hardware.................................................................................................14 4.2.3 Use case specific Software ...................................................................................................17 5. Experimental setup: FIAPAL Living Lab, Palmela, Portugal .....................17 5.1 Energy Consumption Monitoring Use Case ...........................................................17 5.1.1 Use case specific Hardware.................................................................................................17 5.1.2 Use case specific Software ...................................................................................................18 5.2 Asset Viewing and Management Use case..............................................................20 5.2.1 Data acquisition for production monitoring................................................................20 5.2.2 Use case specific Software ...................................................................................................22 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
APOLLON ICT PSP Project
3
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup
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.
APOLLON ICT PSP Project
4
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup
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.
APOLLON ICT PSP Project
5
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup
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 APOLLON ICT PSP Project
6
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup 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 2.2.1 Hardware requirements a) Standard x86 processors based operating environment with at least 1 GB RAM and 2 GB free Hard Disk space. b) Plant assets like machines, personnel, software to be monitored at the plant. 2.2.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.
APOLLON ICT PSP Project
7
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup
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). 2.3.1 Hardware requirements a) Standard x86 processors based operating environment with at least 1 GB RAM and 2 GB free Hard Disk space. b) Devices, tools, material, machines etc. to be traced in the plant. c) Location aware sensors
APOLLON ICT PSP Project
8
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup 2.3.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) 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 APOLLON ICT PSP Project
9
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup 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
APOLLON ICT PSP Project
10
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup
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.
APOLLON ICT PSP Project
11
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup
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.
APOLLON ICT PSP Project
12
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup 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
APOLLON ICT PSP Project
13
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup 4.2.2 Use case specific Hardware 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.
APOLLON ICT PSP Project
14
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup
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
APOLLON ICT PSP Project
15
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup 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
APOLLON ICT PSP Project
16
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup 4.2.3 Use case specific Software 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. 5.1.1 Use case specific Hardware 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
APOLLON ICT PSP Project
17
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup 5.1.2 Use case specific Software a) Monitoring application for displaying the data b) Customized MDI Agents
Figure 13: Smart Meter ISA
Figure 14: Electrical Board Imeguisa
APOLLON ICT PSP Project
18
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup
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.
APOLLON ICT PSP Project
19
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup
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 small components
Welding
Assembly
Sequencing
Inspection
Segregation of defective boards
Testing
Assembly and touch-‐up
Final assembly
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:
APOLLON ICT PSP Project
20
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup 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
APOLLON ICT PSP Project
21
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup
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
5.2.2 Use case specific Software 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
APOLLON ICT PSP Project
22
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup 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 APOLLON ICT PSP Project
23
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup 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.
APOLLON ICT PSP Project
24
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup
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 APOLLON ICT PSP Project
25
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup 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
APOLLON ICT PSP Project
26
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup
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. APOLLON ICT PSP Project
27
Final Version, 10/11/2010
Apollon – D.4.2 Experimental Setup
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 ICT PSP Project
28
Final Version, 10/11/2010