A glass products manufacturing company presented their automation engineers with a new project last year. Data from manufacturing lines needed to appear in a web-based user interface (UI) the company’s supervisors already used.

Solving the UI problem

The UI showed production goals and sales from the company database. Supervisors needed to see real-time production figures in order to compare them to goals and sales and adjust production accordingly. How hard could it be? Almost everything was on premises.

Field devices on the manufacturing lines were wired to local programmable logic controllers (PLCs), with field device values in counts. 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 counts had to be converted to engineering units.

Next, the PLC data was networked to a PC-based HMI (human-machine interface) and a SCADA (supervisory control and data acquisition) 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 into the company database. Additional programming was required to make the data available to supervisors.

Though expensive and complicated, it worked. The engineers and the IT personnel could finally get back to other projects they’d had to put on hold while figuring this one out. They wished there had been an easier, less costly solution.

And then the company realized that their supervisors needed more information from the manufacturing lines, as well as a way to control some process elements. In addition, new production lines were being planned to manufacture a different kind of glass. The new lines would require control and a similar complex architecture to share data with the supervisors’ interface.

OEM machine designer

At about the same time, an original equipment manufacturer (OEM) in California was rethinking its machine design. The OEM built ovens that were suited for a wide variety of industrial and commercial applications, and the company wanted to differentiate its ovens from those of its competitors in order to increase sales.

Feedback from customers pointed to three ways they could improve:

• Make it easier for customers to integrate the oven with process control systems
• Add human-machine interface (HMI) options, so customers could more easily monitor and control the oven’s operation
• Reduce customer costs, especially for operation and maintenance

The OEM’s engineers explored a number of ways to achieve these customer requests. They thought about ways to simplify integration with popular process control systems—for example, drivers for an OPC UA server. But because control systems are proprietary, a driver would have to be developed separately for each system. Since the company’s ovens were used with many types of systems, a one-at-a-time approach would not be cost effective.

Integration with existing HMIs would run up against the same problem. The engineers considered other options for an HMI, including an improved interface on the machine itself and even a mobile app. These ideas sounded possible but expensive to develop.

Reducing customer costs seemed even more difficult. All their ideas depended on data. If they could get operational data from in-place ovens at customer locations, they could analyze it to improve their products’ efficiency. Data like that could also reduce customer costs by providing a new level of service.

For example, the OEM could track burner ignitors, anticipate failures, and call the customer in advance to avoid unplanned downtime. Scheduled maintenance would likely be reduced as well, replaced by preventive maintenance and even predictive maintenance, to determine the likelihood of failures before they occur.

Customers would appreciate these cost reductions and new services. But to get oven data from a customer’s site, the OEM would have to gain access to the customer’s network. The customer’s IT department would have to open incoming firewall ports and allow the OEM to request, or poll, the data. IT departments would never allow such a potential breach to their network security.

How could the OEM redesign their ovens to meet their customers’ wishes and differentiate their products in the market, without spending so much time and money and causing major security problems?

Challenges of the IIoT

These two projects touch on three of the main challenges most automation engineers find today with the Industrial Internet of Things: complexity, security, and expense. Usually the extent of these challenges is not obvious before a project begins; the challenges become clearer once the project is underway. Any IIoT or data-intensive automation application seems to end up involving far more complexity, many more security risks, and much greater investment in time and money than many companies want to expend or can afford.
Getting data from the edge of the network—from the sensors and actuators in factories, commercial buildings and remote sites—to the databases and people who need to use that data can be daunting. Bi-directional communication, for control as well as monitoring and data acquisition, can be even tougher.

Most control systems and equipment use protocols and networks that are proprietary or specific to automation such as EtherNet/IP, Modbus, PROFIBUS, serial and OPC. But computers and mobile devices use standard Ethernet or wireless networks and open protocols and standards like TCP/IP, HTTP/HTTPS, JSON, and RESTful APIs.

Translating data between these systems and moving it to where it’s needed involves a lot of expense and middleware: computers, gateways, drivers, parsers, custom software, licenses. As soon as data moves outside its immediate network or off premises—for use in the company computer network, or remote locations, or on a tablet or smartphone connected to the internet—middleware increases and security concerns balloon. A typical setup includes many steps.

New approach to IIoT Automation

Controls engineers are familiar with PLCs (programmable logic controllers) and PACs (programmable automation controllers). Both have been used and improved over many years, incorporating capabilities that used to be found only in SCADA systems, adding communications with Microsoft Windows-based HMIs, running on standard Ethernet networks, and so on.

But now, for the kinds of applications companies want to do currently and in the future, there is a need for a new approach that simplifies connections and communication—a new approach that does much more than a PLC or even a PAC. There is also a need to shrink or eliminate the middleware and move data from where it’s produced to where it needs to be in many fewer steps.

New controller technology called EPIC (for Edge Programmable Industrial Controller) provides a device that eliminates middleware and shrinks the steps required to get the needed data—reducing complexity, lessening security risks, and decreasing the time and expense required for installation and maintenance. By looking at each part of the acronym, it is possible to learn what this technology means for automation applications.

Edge

All data acquisition starts at the edge, because that’s where data is produced. A manufacturing line or shipping department in a factory, refrigerated rooms or barcoded containers in a warehouse, pumps and pipes and storage tanks at remote sites: all are at the edge of the network and all have data that could be used to improve processes and profits.

If that data is obtained directly from the source, then it’s accurate. So 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 or other devices to gather their data and issue commands, if needed.

An EPIC device at the edge of the network actively works on the data as well, filtering out anomalies, labeling, storing and transmitting only by exception to reduce unnecessary volume, and converting values from one protocol to another. All this preprocessing makes operations, enterprise, and business cloud applications far more efficient.

Because it is the single source for data, an EPIC device can also securely share this data with software and equipment, including other control systems, building management systems, databases, cloud services, and others.

An edge device like this has integrated hardware and software that can perform control, monitoring, data acquisition, operator interface, edge data processing, and analytical functions. Key features include quad-core processing power using a real-time, open-source operating system, along with two or more independent Ethernet network interfaces to segment a trusted network (for example, an internal automation network) from an untrusted one (for example, a network with internet access).

Gateway functions and a configurable internal firewall enable access control for all network interfaces. Authentication and encryption is built into all communications, to eliminate default usernames or passwords.

User account creation and management should be based on required access to specific software on the system, with support for modern security standards like PKI-standard certified connections to servers and clients using SSL certificates.

Standard Ethernet network interfaces and standard modern computer ports like USB and HDMI should be utilized for communications. Multiple methods may be implemented for communicating via standard automation and internet protocols, with multiple software options available for programming and data communications.

An integrated, user-configurable, web-based HMI that runs in a web browser (independent of device screen size, manufacturer, or operating system) can be used to implement an integrated high-resolution color touchscreen for local configuration of I/O and networks, troubleshooting, and system visualization.

The controller’s open-source operating system and quad-core processing provide the intelligence and speed of a computer. Programming and communication options, PC-like ports, solid-state drives, and file space offer options not available on a PLC or PAC. For example, users can store project files (like panel drawings, P&IDs, installation notes) on an EPIC device, so they can be accessed in the field by authorized technicians.

For visualization, an EPIC device includes software for building a web-based, mobile-ready HMI. The HMI is not limited to data and controls from one manufacturer only, but can let authorized users see and send data and manipulate controls, if required, for multiple automation systems, software, and cloud services. Visible on the EPIC’s touchscreen, this HMI is web-based and therefore also available to authorized users on computers, laptops, tablets, and smartphones.

Other options may also be available such as open-source Node-RED for wiring together devices, databases, cloud applications, and APIs (application program interfaces) with simple logic flows.

Programmable

An EPIC device is not a PLC, not a PAC, and not a PC, but like them it must be programmed for control. An EPIC device provides several programming options, some of which reflect traditional automation tools and others that come from PC and internet backgrounds.

Users can program control using 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)

Users more familiar with higher level languages can gain access to the controller’s open-source OS and choose to build custom programs in languages such as C/C++, Java, Python, or others. The device does not limit programming options like PLCs and PACs that may force users to learn a new programming language in order to use it. Instead, it leverages what the user already knows to help build control, data exchange, and HMI programs more quickly.

Industrial

Engineers often have to place controllers in severe environmental locations. One problem with PCs in industrial automation is that an off-the-shelf PC cannot be trusted to stand up to harsh environments. In contrast, EPIC technology grew from real-world automation experience and is designed to withstand tough conditions.

Industrial-grade components and processors are designed for long life. UL hazardous locations approval and ATEX compliance are standard. Operating temperature ranges are wide, for example, -20 to 70 °C and its I/O is hot swappable. THe stainless-steel chassis comes in different sizes to fit enclosures or machine designs and can be DIN-rail or panel mounted.

Controller

At heart, an EPIC device is a real-time industrial controller designed to run control applications. Programmed with standard automation tools, like flowcharting, structured text, and even traditional ladder logic, it works just like a PLC or PAC in a control system. But the device is more than just a controller.

For example, its I/O modules offer multiple channels. Modules with isolated channels are available. Analog and discrete I/O accept a variety of signals, with each channel usually software configurable.

Because EPICs were designed by control engineers, they include features that simplify commissioning and troubleshooting:

• A built-in touchscreen is usable with a finger, a stylus, or while wearing gloves.
• A web-based system management application can configure I/O and networking on touchscreen in the field, or using a computer or mobile device.
• I/O module specs and wiring diagrams are viewable in the field, on device itself.
• Spring-clamp terminals and integrated, covered wireways accommodate a variety of wire sizes.
• LEDs on each I/O module indicate module health and discrete channel status.

Taken as a technology group, edge control systems technology offers significant options for automation and IIoT projects that help future-proof a company’s technology investment. And in the area of security, unlike older automation controllers, an edge device includes tools to help make the system as secure as possible.

So how could an EPIC device help the glass products manufacturer and the OEM with their projects?

The Glass manufacturer

The glass products manufacturer already uses PLCs to control their existing manufacturing lines. An EPIC device can connect to these existing PLCs and communicate their data.

The manufacturer won’t need to purchase PLCs for the new lines they’re going to add, however. EPIC processors can be used instead, connecting directly to sensors and actuators to provide control, while communicating data wherever it is needed.

Because the EPIC 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 simpler with an EPIC, which includes software such as Node-RED to acquire that data through pre-built nodes. Data from all sources—PLCs, sensors and devices wired to the EPIC, and the company database—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 connections to PLCs and databases, an HMI, and real-time control, an EPIC can also move data among OPC servers, business systems like MES and ERP, and cloud services and software.

Data from new sources can be added to the system without middleware. IIoT connections are encrypted and authenticated. New data, controls, and authorized users can be easily added to the HMI, with changes pushed out to users.

The OEM machinery builder

The OEM’s engineers discovered the solution to both their security and cost. An edge controller in the oven replaces the PLC or industrial PC—or both—that used to be required. It is wired directly to sensors and actuators in the oven and provides control, monitoring, data processing, communication, and visualization in a single unit.

For control programming, the OEM can use flowcharting, IEC 61131-3 languages, or Secure Shell access (SSH) for a custom program running on the Linux OS. For an improved HMI, the OEM has choices:

• On smaller ovens, the built-in touchscreen can provide local visualization.
• On larger ovens, an industrial monitor can be added, plugged into the unit’s HDMI port.
• For all ovens, the OEM can build a secure web-based HMI for use on computers and mobile devices. This HMI can be used by customers and also by the OEM.

Because the technology’s system management software is web-based, the OEM can apply software updates and manage the oven from their location, rather than having to go to the customer’s site.

Secure data from customer sites

Perhaps the greatest advantage of edge control for the OEM, however, is the ability to get the data they want from their ovens at customer sites, without causing security issues for the customer. In addition to the usual request/response method for data communication, the technology offers another method: publish/subscribe.

Publish/subscribe, or pub/sub, works by setting up a central broker, either on premises or in the cloud. The broker handles all data communications. Each data source sends data to the broker only when it changes (report by exception). Equipment and software that need data subscribe to only the data they need, and they receive it from the broker only when it changes.

Most important from a security standpoint, all communications are device-originating, outbound-only connections from the EPIC to the broker over secure, encrypted connections. (Secure, device-originating, outbound connections are normally permitted by most IT departments.)

Once initiated, data can flow in both directions. Firewalls allow outbound communications, so there’s no need to open unsecure ports in firewalls. Security is maintained and IT involvement is reduced.

Because it greatly reduces network traffic and maintains security, a pub/sub communication method is well-suited for remote locations. With an EPIC controller in their ovens, the OEM can set up a pub/sub broker at their facility or in the cloud and transfer data from ovens at customer sites, via outbound communications, anywhere they need to use it.

For example:

• In the HMI for monitoring and controlling
• In a database for analysis to improve oven design
• In software for tracking individual customer service
• In online artificial intelligence and machine learning services for analyzing wear and determining preventive maintenance schedules, or predicting when failures might occur to reduce or eliminate downtime.

Looking ahead

As we’ve seen, edge controller technology not only gives automation engineers real-time control for all kinds of traditional automation applications, but it also positions them to be able to provide the IIoT and data-based tasks companies want to do now.

The technology frees engineers to focus on what needs to be done: connecting to legacy systems and smart systems, getting data and transforming it into actionable information, visualizing it and performing real-time control.

Because systems are scalable, they can be applied to smaller applications and then expanded with virtually no limitation. Users can see how the technology works before committing significant resources.

It also offers a simple, secure, maintainable, and cost-effective solution for data communication. If solving the latest challenge involves complex steps, expensive middleware, or security issues, take a look at edge controller technology. It may very well shrink those steps, reduce costs, and help provide the security needed.

Technology report by Opto 22