Last year a glass products manufacturing company in Ohio presented their automation engineers with a new project: data from manufacturing lines needed to appear in a web-based user interface (UI) the company’s supervisors already used.
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.
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?
THE CHALLENGE 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—EtherNet/IP, Modbus, Profibus, serial, 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, as shown in the “Challenge” diagram.
A NEW APPROACH TO AUTOMATION AND THE IIOT
As controls engineers, we’re 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 we need more from our automation systems. For the kinds of applications we want to do now and in the future, we need a new approach that simplifies connections and communication—a new product that does much more than a PLC or even a PAC. We need an automation product that shrinks or eliminates the middleware and lets us move data from where it’s produced to where it needs to be in much fewer steps.
Fortunately, that product has recently appeared on the market. It’s called EPIC—an Edge Programmable Industrial Controller. An EPIC device eliminates middleware and shrinks the steps required to get the data we need, thus reducing complexity, lessening security risks, and decreasing the time and expense required for installation and maintenance.
What exactly is EPIC? Let’s take a look at each part of the acronym and see what it means for the automation applications we’re building, today and tomorrow: Edge Programmable Industrial Controller.
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 we can get that data directly from the source, then we know 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 also connects 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 of truth 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.
- Quad-core processing power on a real-time, open-source operating system.
- 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 to control access to all network interfaces.
- Authentication and encryption built into all communications; no default usernames or passwords.
- User account creation and management based on required access to specific software on the system.
- Support for modern security standards, for example PKI-standard certified connections to servers and clients using SSL certificates.
- Standard Ethernet network interfaces and standard modern computer ports like USB and HDMI for communications.
- Multiple methods for communicating via standard automation and internet protocols.
- Multiple software options 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.
- An integrated high-resolution color touchscreen for local configuration of I/O and networks, troubleshooting, and system visualization.
- Agency approvals and compliance for hazardous areas.
- Ratings for a wide range of operating and storage temperatures and relative humidity.
Three main challenges most automation engineers find today with the industrial internet of things are complexity, security, and cost.
Far more than just a controller, an EPIC’s open-source operating system and quad-core processing provide the intelligence and speed of a computer. Its programming and communication options, PC-like ports, solid-state drives, and file space offer options not available on a PLC or PAC. For example, you 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 on an EPIC device. One example is open-source Node-RED for wiring together devices, databases, cloud applications, and APIs (application program interfaces) with simple logic flows.
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 gives you several programming options, some of which reflect traditional automation tools and others that come from PC and internet backgrounds.
You 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)
If you are more familiar with higher level languages, you can gain access to an EPIC’s open-source OS and choose to build custom programs in languages you know, such as C/C++, Java, Python, or others.
An EPIC device does not limit your programming options like PLCs and PACs or force you to learn a new programming language in order to use it. Instead, it lets you leverage what you already know, so you can build control, data exchange, and HMI programs more quickly.
As engineers, we 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. Only a much more expensive industrial PC will work.
In contrast, EPIC devices grew from real-world automation experience and were 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. EPIC I/O is hot swappable.
Stainless-steel chassis come in different sizes to fit enclosures or machine designs and can be DIN-rail or panel mounted.
At heart, an EPIC device is a real-time industrial controller designed to run control applications—a device that does everything we have always expected from a PLC or PAC. Programmed with standard automation tools we already know, like flowcharting, structured text, and even traditional ladder logic, an EPIC works just like a PLC or PAC in a control system.
But an EPIC device is much more than just a controller. 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, usable with a finger, a stylus, or while wearing gloves.
- A web-based system management application to configure I/O and networking on the touchscreen in the field, or using a computer or mobile device.
- I/O module specs and wiring diagrams viewable in the field, on the device.
- Spring-clamp terminals and integrated, covered wireways that accommodate a variety of wire sizes.
- LEDs on each I/O module that indicate module health and discrete channel status.
A LOOK AHEAD
Taken as a whole, an EPIC system offers significant options for automation and IIoT projects that help future-proof your investment. So how could an EPIC device help our glass products manufacturer and our OEM with their projects? In next month’s conclusion, we’ll go through their application and its success.
FOR MORE INFORMATION
With thirty years’ experience in IT and industrial automation, Benson Hougland 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 non-technical people to the IoT. Opto 22 designs and manufactures industrial control products and Internet of Things platforms that bridge the gap between information technology (IT) and operations technology (OT). Based on a core design philosophy of leveraging open, standards-based technology, Opto 22 products are deployed worldwide in industrial automation, process control, building automation, industrial refrigeration, remote monitoring, and data acquisition applications. For more information, call 951.695.3000 or visit www.opto22.com.
MODERN PUMPING TODAY, July 2019
Did you enjoy this article?
Subscribe to the FREE Digital Edition of Modern Pumping Today Magazine!