IIoT and Industry 4.0 are omnipresent topics in today’s industry tradeshows and blog posts. A lot of products promise to help you achieve vertical integration of production flow and data and enterprise software like ERP. But usually, there’s also a catch: either you get very complex products with a similarly shocking price tag - or despite IIoT’s promise of full cross-vendor interoperability you will turn vendor-locked, especially if you consider software solutions that are sold by production machine vendors in conjunction with their equipment.  

For smaller companies with limited resources and small or one-person IT departments, this is a dilemma. While such companies rely on flexibility to compete with larger enterprises and thus need to adopt paradigms like Industry 4.0, it usually comes with a huge investment and a wall of seemingly insurmountable technical complexity.  

In this case study, I’d like to show how Connecting Software’s Connect Bridge integration platform helps to fill this gap and provides an easy to use toolkit for quickly starting to develop custom IIoT solutions.  

The customer is a small industry supplier that provides mostly stainless-steel sheet metal products with small batch sizes (down to one) and a complex product portfolio.  

To be able to compete with other manufacturers in this area, the factory needs technological advancement and constant evolution of the production process. Therefore, the customer has started to introduce robotic laser welding into the production process. While solid-state laser-welding has many advantages such as lower distortion, little to none post-production of welding seams, etc., it is also a challenging process to implement due to its inherent need for accuracy and other complex requirements.  

Another challenge is integrating such a robotic welding solution into production planning, getting the necessary data for (post) calculation of costs, quality control etc.  

Despite the rise of collaborative robotics and thus permeation of such applications into production, today they are mostly used for highly repetitive tasks with very little change in the products/processes handled. Therefore, the choice for production planning software that fulfills the needs of my client is practically non-existent, thus the need for a custom solution that grows with the continued adaption of the laser-welding process into his manufacturing chain.  

The requirements in short: 

• Data acquisition from the robotic welding system (and its components respectively) for purposes of (post) cost calculation, quality control, production planning
• Integration of this data into the customer’s custom ERP environment
• Provide a production planning tool for robotic welding that is open for future improvements (e.g. offline programming)
• Adaptable solution that grows with the company
• Avoid vendor lock-in and keep the complexity and maintenance needs of the overall software ecosystem as low as possible

The customers IT landscape is a naturally grown one and therefore inherently complex. At its foundation, it uses a legacy ERP system that is extended by custom PHP web-based applications and interfaces to other software products (e.g. CAD, CAM like laser nesting software, …) and customer systems for direct data exchange. All this within a mixed Windows/Linux server environment and an almost exclusively Windows-based client pool in an Active Directory. File services are based predominantly on Windows shares and (to a smaller extent) on Dropbox.  

With an ongoing migration towards Microsoft Windows 10 and Office 365, topics like the implementation of SharePoint or OneDrive into the company’s IT processes may be of interest.   

In general, the customers strategy is to reduce the complexity of its IT infrastructure by trying to reduce the amount of different technologies used (LAMP stacks, AD, Windows, O365, legacy systems, etc.), thus increasing manageability and reducing maintenance costs of the entire ecosystem.

Production machinery has usually an inherently long use period. Therefore, not all machines are equipped for Industry 4.0 applications or provide very limited functionality in this area. This paper focuses therefore solely on the robotic welding application and its integration needs. 

The welding system is a turn-key solution from a well-known German manufacturer consisting of a solid-state laser source, a robot with rotary-tilt-table, a machining head with a camera system, protective cell needed for high-power laser applications, control systems and auxiliary systems (suction, dust collecting, cooling).  

The components of this system communicate via a variety of standard industrial interconnects (digital IOs, Profinet, EtherCat, standard ethernet). By the vendor’s specifications, only one standard ethernet interface is exposed towards the customer’s network infrastructure. This interface is connected to the machine vendors overall PLC system and offers only very limited access to the machines data and control system. It offers an OPC UA interface with only very few datapoints (below 10) available. And they are only populated if the factory uses the machine vendor’s production planning software running on the machine’s PLC. Therefore, this interface proved to be not too useful for my customer now. This situation might change. However, since this exposed OPC UA interface is a work-in-progress, it will probably get more useful features with future updates. 

But since many of the machines sub-components use standard ethernet as a method of communication, more access is possible. Within the machines internal networks, the PLCs of the robot, the laser source and the welding-heads camera system is reachable. But without further modification, not all of them offer the necessary tools to provide easy OPC UA access.  

As the first step, the goal was to acquire data directly from the machine’s components.  

Direct control of these systems via the Connect Bridge (CB) is not a target, as it could potentially violate the single point of control principle necessary for machine safety.  CB provides an easy to use interface to the OPC UA standard that is increasingly common in today’s PLCs and machines. While this standard can be used to establish real-time communication and therefore replace functions currently implemented by industrial field-bus-systems, in our scenario, real-time capabilities are not necessary. While SDKs are available for direct integration of the OPC UA stack in my customer’s application, they are usually intricate and thus contradict the goal of reducing complexity.  

Therefore, the choice fell on the Connect Bridge with its advantages of easy setup, hassle-free SQL based interface not only to OPC UA, but also to other local and cloud-based services, and extremely competitive price tag. 

In this factory, the new technology is going through the adaptation process, so the robotic welding system only operates in a single-shift and the machine is not running constantly even during working hours. Therefore, the data acquired at this point may be useful, but might also prove unreliable for future use or predictive purposes. This is based on the customer’s experience with data harvested from other production machines, e.g. laser cutting machines. Certain factors - whether the machine operator was present when a production cycle finished, when the data acquisition was triggered - proved that even seemingly highly accurate data could paint a wrong picture, and that fine-granularity is not always necessary to judge the efficiency of the production process. 

Thus, a rather low polling frequency of 30 seconds is currently used for data acquisition.  

In this first step, the customer wants to poll data from these 3 main components:  

• the laser source, 
• the robot’s PLC,
• the camera system. 

However, at this moment only the laser source can be connected, with the robot’s PLC and the camera system unavailable for their reasons.  

The robot PLC is accessible via ethernet but runs a legacy OPC interface. Due to software constraints by its manufacturer, it can’t run OPC UA. An OPC – OPC UA interface might be able to salvage this situation, but without green light from the machine’s manufacturer in terms of compatibility, the installation of such software did not seem feasible. At the moment, the customer is developing a work-around: the robot’s PLC’s digital IOs will be connected via an industrial PC to get accurate information (e.g. when a production process was started or finished) and to trigger a tighter data acquisition window.  

The camera system is tied to the entire machine’s PLC and seems not the be accessible by outside clients. Since vision would be useful for quality control purposes and process documentation, the use of an additional, external camera system is currently being evaluated to solve this problem.

This leaves the laser source. Fortunately, this system is equipped with a state-of-the-art controller that incorporates a sophisticated OPC UA interface with several levels of access: anonymous access with limited read capabilities, read-only, read-and-write. As mentioned before, read-and-write access was out of the question for the reasons of machine safety. Therefore, read-only access was chosen.  

This interface offers up a plethora of data:  

• Overall state of the laser system
• Operation periods, power used, …
• Error and maintenance messages

With the CB, the customer developed a Windows service in C# to periodically poll the data and compile it into several SQL database tables for future use. The tables can provide such information as general data, equipment usage, tables for maintenance/error messages produced by the laser source.  

But how to apply this data? 

The first valuable insight is the compilation of machine log messages. My customer’s experience in the past was that not all machines keep their log files through restarts. Also, machine operators not always accurately report malfunctions and errors to their supervisors. This can result in longer than necessary machine downtimes when a serious malfunction occurs. If the machine was running on this day at all – is an important question. 

For easy access by the company’s technical management, such daily reports are generated as PDF files and stored in a shared Dropbox, in case a support call to the machine vendor needs to open.  

Of course, this is currently only a very limited application of the immense capability of CB. The next steps the customer is developing are:  

• Connection to the robot’s PLC (via digital IOs if not otherwise possible) to get accurate start/stop timing of production cycles. 

In conjunction with the company’s timesheet system this will allow for better understanding of how much time the machine is actually in production and how much time is used for teaching (robot programming) and/or loading/unloading/maintenance; 

• Camera system access: since laser welding is a different welding process, my client’s customers need to certify this production method before any real products are delivered. Such processes will be much more easily achieved if complete documentation of the welding process can be delivered constantly and automatically. 

Furthermore, with the planned reduction in complexity and services used, a move from Dropbox-Shared to OneDrive is imminent, once this is rolled out on all concerned clients. The customer is also interested in possible data analysis for predictive maintenance. 

As written above, this project is in its staring phase and a still a long way from being a fully functional IIoT solution. But with little initial effort, a useful demonstrator for the customer could be developed leveraging the powerful abilities of the Connect Bridge. As a developer, it helped me by avoiding the need to get into the details of yet another connection stack (like OPC UA or the Dropbox API). And for my customer it provided a centralized communication stack for future applications that is also very competitively priced compared to solutions from other vendors that sometimes feature complicated licensing setups with licenses based on the number of devices accessed by its tool and even the number of data points acquired. 

CB – the Connect Bridge integration platform

PLC – Programmable logic controller 
Generally a real-time capable computer system with relatively low processing power (compared to standard PC devices) with industrial fieldbus interfaces and digital IOs used to control machinery. 

IIoT – the Industrial Internet of Things 

OPC UA – OPC Unified Architecture 

CAD – Computer Aided Design 

CAM – Computer Aided Manufacturing 

This case study analyzes the application of the OPC UA protocol for gathering up-to-date machine data in a small production facility in Austria. An OPC UA connector built on the Connect Bridge integration platform by Connecting Software was used to pull machine data into report tables for timely equipment maintenance in the production facility. The integration platform accepts simple Create, Read, Update and Delete (CRUD) SQL queries through standard ODBC, JDBC and Web Services drivers. These queries are then translated to standard API calls native to the target system. A number of pre-built connectors allow to deliver these data to ERP, MES, CRM, DMS systems, etc. for further exploitation. 

Richard Majer, Founder of flupo Systemtechnik e.U. specializing in industrial IT and automation technology for SMEs. Before starting his own company, Richard worked in an R&D institute for high-power laser applications (gaining experience in laser technology, FEM simulations, industrial robotics, PLC programming, industrial fieldbus systems), and has more than 10 years of experience in general IT with a focus on software development in SME environments (interfaces between different software products, production planning applications). He holds Master's degree in Mathematics from the University of Vienna