Case Study: First Steps Toward IIoT in a SME Environment

Case Study: First Steps Toward IIoT in a SME Environment

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, firstly, I will show how a software integration platform with pre-built connectors for machine data communication can help to overcome these limitations. And secondly, what can be first practical applications for real-time machine data in a small factory which starts its journey towards the Industrial Internet of Things.

About the customer and his requirements

The customer is a small industry supplier that provides mostly stainless-steel sheet metal products with small batch sizes 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 state-of-the-art robotic laser welding into the production process.

Aside from the process itself, integrating such a robotic welding solution into production planning, getting the necessary data for cost calculation, quality control etc. is another challenge.

The customer’s IT environment

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.

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.

The production environment

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. Therefore, this article focuses solely on the robotic welding application and its integration needs.

The welding system is a turn-key solution from a well-known 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 less than 10 datapoints which 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, however the situation might change.

The first steps

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

The client chose the OPC UA communication protocol which 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.

So instead of custom coding, the client opts in for an integration platform that has a pre-built OPC UA connector with an easy to use interface and a possibility to connect to back-office systems like ERP, CRM, various document managements systems or databases – local and cloud-based, and a reasonable price tag.

Direct control of these systems via the integration platform is not a target, as it could potentially violate the single point of control principle necessary for machine safety. 

Frequency of data polling

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 would like 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. Other components are not possible to integrate: the robot’s PLC has only the OPC Classic interface, and the transition to the Unified Architecture is challenging at the moment; and the camera system is tied to the entire machine’s PLC and seems not the be accessible by outside clients.

OPC UA for the laser source

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 integration platform, 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.

A big question: how to use this machine 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 the OPC UA connector. 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.

Conclusion

As written above, this project is in its staring phase and a still a long way from being a fully functional IIoT solution. Going with an integration platform with pre-built connectors instead of programming the whole integration 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.

Disclaimer

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. The integration platform with an OPC UA connector used in the facility was provided by Connecting Software, a producer of integration and synchronization solutions.

 

This article was written by 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 (mostly interfaces between different software products and production planning applications). He holds a master’s degree in Mathematics from the University of Vienna.