By Kevin Canham – Product & Applications Manager of HARTING Ltd
The concept of integrated industry can be defined as the transformation of today’s factories into “smart” factories, where the orchestration of services represents the definitive solution for fully modularised automation. This article covers some of the smart solutions and the benefits they can provide.
Customer-tailored manufacturing requires a high degree of flexibility in production. In smart factories, modular production units are connected together to form executable processes. Here, the orchestration of services, their standardised description, and service-oriented software architectures all play a central role.
Since traditional systems are incapable of meeting flexible customer requirements, manufacturing processes must be modularised and assembled for individual processes depending on the situation. This entails the integration of various technologies into a smart factory: automation technology, sensors, RFID and, last but not least, information technology.
In the smart factory, production is controlled by components and products in a largely decentralised and autonomous manner. Via sensors, objects detect the state of their surroundings; they can be uniquely identified, possess built-in object memory, and exchange information with other objects – regarding their processing state, for example. Through the addition of embedded systems, objects become “cyber-physical systems” (CPS). The result is a maximum of flexibility and the ability to profitably produce even the smallest batch sizes.
The co-ordination of individual CPS in the smart factory takes place in service-oriented architectures (SOA), which have been successfully employed in information technology for years. The basic idea is to encapsulate individual components as services. Here, a CPS can function as service provider or service consumer.
When orchestrating services, modular production units are assembled into executable production processes. For the modelling, various programming approaches such as BPML (Business Process Modelling Language) and BPEL (Business Process Execution Language) are available.
In addition to the orchestration of services, one of the biggest challenges is the formal description of the services and their standardisation. System integration requires a reference architecture that enables providers and users to connect individual components with one another with “plug & play” capability. This will have to be cleverly designed, since directly transferring IT approaches to automation is not generally possible.
Automatic ID integration
One way in which these different worlds of automation and IT systems can be linked is through automatic ID integration.
When transferring information between media – say from paper to IT systems – much data can be lost. As a result, the potential for efficiency gains and cost reduction can fall by the wayside. In the case of production processes under the joint burdens of high expectations and cost pressures, however, this is unacceptable. Auto-ID technologies are capable of minimising such data loss, but in order to achieve this they need to be sufficiently integrated into both the worlds they connect.
Currently, three Auto-ID technologies are deployed in industry: barcodes (including quick-response or QR codes), image recognition and RFID. Each of these systems has its clear strengths. Barcodes are extremely favourable in terms of costs and are easy to implement, and image recognition does not require any additional information. RFID, however, is the only technology that simultaneously permits unique identification, confers the object with memory, and allows bidirectional communication between the object and the IT world.
The information gained by means of Auto-ID must be prepared in such a way that the target IT system can process it. Depending on the application, entirely different software components are necessary for this process: a PLC function block, middleware, the application suite or the SAP module Auto-ID Infrastructure (AII). The following are some examples of integration, ranging from simple to complex, in which different components are used for integration in each case:
- Example 1: Local trains are getting longer and longer, while the platforms are not. Naturally, only doors which open onto a platform should be opened. This can be detected by way of RFID. The RFID reader switches on a relay that shows the train operator which doors he or she can open.
- Example 2: Modern machines consist of numerous modules. Executing a PLC program that does not match the current module configuration can cause serious damage to machines. The RFID reader recognises the modules and communicates with the PLC by means of a function block, thereby ensuring that only authorised programs are executed (Fig.1).
- Example 3: Service calls are expensive, which makes trouble-free processing and sequences all the more important. By way of example, a handheld device is used to identify a machine listed for servicing. The service technician is led through the process step by step via an app (implemented via the application suite). Each step is simultaneously documented and archived in a database.
- Example 4: Today, the receipt of goods should be posted automatically. Using RFID, hundreds of objects can be simultaneously detected and the data sent directly to the SAP AII module via Ha-VIS Middleware.
Figure 1. RFID in modern machinery
From sensors to the Cloud and back
It is common practice in modern production facilities to record sensor data in order to control production processes and monitor system units. But what would happen if, within a fraction of a second, this sensor data could be stored and subsequently become available again for further analysis – for example to predict failures or unplanned outages? It is precisely this scenario that forms part of the integrated industry concept.
The potential effects are far-reaching, and the organisational and economic benefits are striking. Consequently, the HARTING Technology Group has developed a “predictive maintenance” demonstrator together with SAP based on the SAP HANA database Cloud technology (Fig.2).
Figure 2. Predictive maintenance deomonstrator
Working on the basis of these two specifications, a complete “water works” featuring pumps, water circulation, sensors and an embedded microcomputer with management control software designed by the company was developed within a period of six weeks. The aim of this demonstrator is to test the robustness of a concept under essentially real conditions and in which errors in processes or components can be detected early on in order to order spare parts in advance, minutely plan replacement work, and be able to make appropriate remedial measures available to technical service personnel.
Inside the “waterworks” (Fig.3), water is continuously pumped out of a container and back into it. Sensor data from the pressure and flowmeter are queried at extremely short intervals by the embedded microcomputer and then relayed to the SAP HANA database. In the event that a change in sensor data is registered with respect to the circulation, an algorithm stored in the SAP HANA database can mathematically and precisely determine the instant of the potential failure.
A graphical interface is employed to display status messages that can be used to analyse errors. In addition, a pumping cycle that shows signs of failure can be disabled and switched over to a second one that is also integrated into the demonstrator. This permits the malfunction to temporarily be bypassed.
Figure 3. Simulation of a waterworks on the predictive maintenance demonstrator, illustrating diagnosis of a system failure
Visualisation during service and maintenance
To resolve the error, in addition to the information on the faulty component, the technician also has access to a detailed 3D drawing based on current CAD diagrams, which can assist in performing replacement work.
Further development of the demonstrator is planned: with the help of HARTING RFID transponders attached to each component, in tandem with the company’s Ha-VIS Middleware and Ha-VIS Application-Suite, the scenario could be extended to encompass maintenance and repair. The RFID transponders permit components to be uniquely identified, and the history of every component can be documented.
As a result, maintenance intervals can be precisely planned down to the component level.
How does the right app find its way onto a service technician”s mobile reader? Who makes sure that the required process steps are mapped and depicted? How should such requirements be efficiently programmed and maintained from a central location? This solution goes by the name of the Ha-VIS Application-Suite, and is illustrated by way of the following scenario:
A work shift gets under way in the maintenance and service department of a factory. We accompany a technician who performs maintenance on equipment within the company. This activity must be thoroughly documented and centrally recorded in an in-house database system.
But the technician doesn’t grab a folder full of checklists from the shelf that details the work he needs to complete to-day. Instead, he picks up a mobile RFID reader with an integrated touch panel. After logging on to the device, his work can begin.
Arriving at the first maintenance location, the machine scheduled for servicing is uniquely identified by UHF RFID with the aid of the mobile RFID reader.
The maintenance checklist is automatically shown to the technician on the display, including the correct machine/object identification. Maintenance work is digitally documented directly on the mobile recording device. Thanks to RFID identification, any mix-up with the wrong checklist or an incorrect maintenance object is ruled out.
Who ensures that the recorded data are stored in the correct database? How complex is the maintenance of such a system? What happens if different recording devices are used? Can an application potentially be adapted to new work processes in a flexible manner? Does the mobile recording device need to be permanently connected to the server?
It is here that the Ha-VIS Application-Suite takes over and organises these tasks (Fig.4). The client-server based architecture of this solution platform makes it possible to create hardware-independent and operating system independent applications (apps). In concrete terms, this means that an app runs on a central server and can be updated and maintained there.
Figure 4. Principal architecture of the Ha-VIS Application-Suite
The predominantly mobile client devices receive the necessary information and interfaces from this central location. But, unlike a conventional client-server based mobile app, more than just a web-site is displayed on the client. Extensive job steps such as maintenance work can be performed offline. The mobile device loads necessary data once into memory and can then continue to work offline.
In addition, in contrast to pure Web-based applications, the hardware of the mobile end device can be accessed – for example, that of the RFID reading unit.
To accomplish this, device-specific connections are available. As a result, during the actual app creation the device-dependent properties can be ignored. The advantage of this technique is that an app that is created can run on different end devices.
This suite extends the Auto-ID product portfolio including the powerful Ha-VIS Middleware, which is compliant with the EPCglobal ALE 1.1 standard.
Learn more about HARTING RFID Systems by visiting the HARTING website
HARTING Limited Northampton, Northamptonshire
Can be contacted via: Tel: +44 (0) 1604 827500 Fax: +44 (0) 1604 706777