IIoT installations are increasing across the process industries, but current solutions are often too complex and expensive. The following example from a glass products manufacturer in Ohio describes the challenges and solutions for implementing an IIoT project.
A critical aspect of the project was transferring existing data from its manufacturing lines to a web-based user interface (UI) already in use by the company’s management team.
The existing UI displayed production goals and sales from the company’s enterprise resource planning database, and the team needed to add real-time production figures for comparison. With this information on hand, they could make better decisions regarding production.
At first glance, this seemed to be a simple problem because all the required hardware and software was in place — with secure data transfer from the production lines to the UI as the only new item. But further examination revealed a host of difficulties in terms of cost, complexity and cybersecurity.
Glass manufacturer challenges
The specific challenges faced by the glass manufacturer were as follows, and many of these issues are common across the process industries.
Field devices on the manufacturing lines were wired to local programmable logic controllers (PLCs), handling field device values in raw count format. Getting data from the PLCs required device-specific communication drivers. The engineers purchased and installed them, chose the desired points and mapped the points in a spreadsheet. Data in count format then had to be converted to engineering units.
Next, the PLC data was networked to a PC-based human-machine interface (HMI) and a supervisory control and data acquisition (SCADA) system. These systems required the engineers to configure data tags, drivers and polling rate assignments.
Then, working with their information technology (IT) department, the engineers also configured the HMI and the SCADA system to transport the data to the company database. Additional programming was required to make the data available to supervisors.
Although expensive and complicated, it worked. The engineers and the IT personnel could finally get back to other projects they had put on hold, but they wished there had been an easier, less costly and more secure solution.
The need for such a solution became urgent when the company realized the management team needed more information from the manufacturing lines, as well as a way to make adjustments in real time, which would require two-way communication. In addition, new production lines were being planned to manufacture a different kind of glass. The new lines would require control and, once again, a complex architecture to share data with the supervisors’ interface.
IIoT issues
The challenges faced by this manufacturer are common to many IIoT implementations and involve three main issues: complexity, security and expense. Many IIoT or data-intensive automation applications become far more complex with more security risks than initially anticipated. The result is that the final cost and human resource requirements are more than many companies can expend or afford.
Getting data from sensors and actuators to the people who need to use that information can be daunting. Bidirectional communication for control can be even tougher.
Most industrial automation systems and components use protocols and networks proprietary or specific to automation, such as EtherNet/IP, Modbus, Profibus, serial, OPC or others. But commercial computers and mobile devices use standard Ethernet or wireless networks and open protocols and standards such as TCP/IP, HTTP/HTTPS, JSON and RESTful APIs (application program interface).
Translating data between these disparate industrial and commercial systems and then moving it where it is needed involves a lot of expense and middleware, including computers, gateways, drivers, parsers, custom software, licenses and other add-ons.
As soon as data moves outside the immediate network or off premises — for use in the company computer network, remote locations or on a tablet or smartphone connected to the internet — middleware requirements increase and security concerns balloon. A typical configuration to enable these communications requires many components and significant configuration and programming (see Figure 2).
Figure 2. Traditional methods of exchanging data between field devices and cloud-based or on-premises applications require many hardware and software components.
Addressing challenges and issues
Control system engineers are familiar with PLCs and programmable automation controllers (PACs). Both have been used and improved over many years, incorporating capabilities formerly found only in proprietary SCADA systems, adding communications with Microsoft Windows-based HMIs, running on standard Ethernet networks and so on.
But for IIoT and other challenging applications, more is often desired from automation systems. For these and future applications, a new approach is needed to simplify connections and communication that does much more than a PLC or even a PAC.
What’s needed is a class of automation solutions that shrinks or eliminates the middleware and lets users move data from where it is produced to where it needs to be in fewer steps (see Figure 3). This new type of controller is referred to as an edge programmable industrial controller (EPIC). Examining each part of the EPIC acronym provides a more precise definition of this type of controller.
Figure 3. An edge programmable industrial controller can be used to replace multiple hardware and software middleware components.
Edge: All data acquisition starts at the edge because that is where data is produced. It is best to collect and process this data directly at the source to ensure accuracy, perform preprocessing and prepare it for transmission. An EPIC device sits at the edge and connects directly to sensors and actuators through its I/O — the inputs and outputs that gather sensor data and send control commands. It can also connect to existing PLCs, HMIs and other control system components to gather data and issue commands.
Programmable: Like a PLC, an EPIC device must be programmed for control. Typical options include programming with familiar automation tools like flowcharting or any IEC 61131-3 compliant language, including:
- Function block diagram (FBD)
- Structured text (ST)
- Sequential function charts (SFC)
- Ladder diagram (LD)
Access is also available to an EPIC’s open-source operating system for custom programming in languages such as C/C++, Java, Python and others.
Industrial: One problem with using PCs in industrial automation is that an off-the-shelf PC cannot be trusted to stand up to the harsh environments often found in process plants where only a much more expensive industrial PC will work reliably. In contrast, EPIC devices incorporate real-world automation experience and are built to withstand tough conditions. Industrial-grade components such as solid-state drives are designed for long life.
Controller: At heart, an EPIC device is a real-time industrial controller designed to run control applications and programmed with standard automation tools such as flowcharting, structured text and even traditional ladder logic. The first of many anticipated EPIC devices on the industrial automation market comes from Opto 22.
Glass manufacturer solution
The glass products manufacturer already uses PLCs to control its existing manufacturing lines. An EPIC device was installed to connect to these existing PLCs and communicate their data.
However, the manufacturer did not need to purchase PLCs for the new lines they planned to add. EPIC processors were used instead, connecting directly to sensors and actuators to provide control, while communicating data wherever it was needed.
Because the EPIC device provides data in standard engineering units, no conversion software is required. Once configured with plain-language names, I/O channels are available automatically as tags in all EPIC software, so no spreadsheets are needed to keep track of points.
Incorporating production goals and sales from the company’s database is much simpler with an EPIC device, which includes software such as Node-RED to acquire this type of data through prebuilt nodes. Data from all sources — PLCs, company databases and sensors and components wired to the EPIC device — is easily made available to authorized users in the EPIC’s HMI software.
Using EPIC devices also makes future changes or expansion easier and more secure. In addition to providing an HMI, real-time control and connectivity to PLCs and databases, an EPIC device can also move data among OPC servers, cloud services, cloud software and manufacturing execution systems (MES) and enterprise resource planning (ERP) business systems. Data from new sources can be added to the system without middleware, and IIoT connections are encrypted and authenticated. New data, controls and authorized users can be easily added, with changes pushed out to users, as shown in Figure 4.
Figure 4. EPIC devices are often the best solution for collecting data from many different sources and distributing it to a web-based user interface (UI).
Conclusion
EPIC devices can provide real-time control for all kinds of traditional automation applications and can handle IIoT and data-based tasks. These devices offer a simple, secure, maintainable and cost-effective solution for IIoT data communication by flattening the architecture required to transfer data from the field to a cloud-based or an on-premises application.
Benson Hougland has 30 years of experience in IT and industrial automation. He drives strategy for Opto 22 products connecting the real world to computer networks. Hougland speaks at trade shows and conferences, including IBM Think, ARC Forum and ISA. His 2014 TEDx Talk introduces nontechnical people to IoT.
