The IIoT provides many benefits to machine builders and their customers, but new solutions are needed to reduce complexity and expense while maintaining a high level of security.
Benson Hougland, Opto 22
Like many OEM machine and equipment builders, a California-based oven manufacturer needed to implement an industrial internet of things (IIoT) solution to meet customer demands, improve remote monitoring, and remain competitive in the marketplace.
The OEM builds ovens used in a variety of industrial and commercial applications, and it wants to differentiate its ovens from those of its competitors to increase sales. Feedback from customers points to three ways to improve upon its established offerings:
–Make it easier for customers to integrate the oven with the other process control systems in their plants
–Add human-machine interface (HMI) options so customers can more easily monitor and control oven operation
–Reduce customer costs, especially for operation and maintenance
Initial investigation showed that achieving these goals promised to be difficult due to a number of challenges.
OEM Challenges
The OEM considered ways to simplify integration between their oven automation systems and the leading process control systems found in their customers’ plants. These larger on-site process control systems typically control the entire plant or facility and must interface to the OEM’s ovens.
One method was to develop drivers for intersystem communications, but because the process control systems already in service are proprietary, a custom driver would have to be developed separately for each. Since the company’s ovens are used with many types of process control systems, a one-at-a-time approach would be required. Driver development would be resource intensive and require extensive time from the OEM’s programmers, and it would not be cost effective. This approach would also present future maintenance issues because many different versions of custom driver software would have to be supported, with each version requiring review and possible updates to keep up with changes to the corresponding process control system.
Integration with existing HMIs would run up against the same problem. The OEM’s engineers considered other options for an HMI, including an improved interface on the oven itself and even a mobile app. These ideas sounded possible but expensive to develop and maintain.
Reducing customer costs seemed even more difficult. All of the OEM engineers’ ideas depended on getting the data they needed in a timely manner. If they could get operational data from ovens installed at their customer locations, they could analyze the information to improve oven efficiency. These data could also be used to reduce customer costs by providing a new level of service. For example, the OEM could track burner ignitors, anticipate failures and contact 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 might occur.
The OEM knew its customers would appreciate these cost reductions and new services, but its engineers would have to gain access to the customer’s network to get oven control system data from each site. This would require the customer’s IT department to open incoming network ports in their corporate firewalls and allow the OEM to extract the data. IT personnel would never (and shouldn’t) allow such a potential breach to their network security.
How could the OEM redesign their ovens’ automation systems to meet their customers’ wishes and differentiate their products in the market, without spending so much time and money, along with creating major security risks?
IIoT Issues
The challenges faced by this OEM are common to many IIoT implementations and involve three main issues: complexity, security and expense. Many IIoT or data-intensive automation applications end up being far more complex with more security risks than initially anticipated. The result is that the final cost and human resources required are more than many companies 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 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 like TCP/IP, HTTP/HTTPS, JSON and RESTful APIs.
Translating data between these disparate industrial and commercial systems, and then moving it where it’s needed, involves a lot of expense and middleware: 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 architecture to enable these communications requires many components and significant configuration and programming (Figure 1).
Caption: Traditional methods of exchanging data between field devices and cloud-based or on-premises applications require many components and steps.
Addressing challenges and issues
Control system engineers are familiar with programmable logic controllers (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 needed from automation systems. For these and future applications, a new approach is needed to simplify connections and communication—a new product that does much more than a PLC or even a PAC.
What’s needed is a class of automation products that shrinks or eliminates the middleware and lets users move data from where it’s produced to where it needs to be in fewer steps (Figure 2). This new type of controller can be referred to as an edge programmable industrial controller (EPIC).
An edge programmable industrial controller can be used to replace multiple hardware and software middleware components when transferring data from the field to cloud and on-premises applications.
Let’s look at each part of the EPIC acronym to more precisely define this type of controller.
An EPIC system
Edge: All data acquisition starts at the edge because that’s where data are 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 can be used to improve processes and increase profits.
It’s best to collect and process these 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.
An EPIC device installed at the edge of a network actively works on the data as well by filtering out anomalies, by labeling, by storing and by transmitting only by exception to reduce unnecessary volume, and by converting values from one protocol to another. This data preprocessing makes operations, enterprise and business cloud applications more efficient.
Because it is the single source of truth for data, an EPIC device can also securely share the data with software and equipment including other control systems, building management systems, databases, cloud services and others.
Programmable: An EPIC device is not a PLC, a PAC or a PC, but like them it must be programmed for control. An EPIC device provides programming options, some of which reflect traditional automation tools, and others that come from the PC and internet world.
Typical options include programming with familiar automation tools like flowcharting, scripting or any IEC 61131-3 compliant language, including:
–Function Block Diagram
–Structured Text
–Sequential Function Charts
–Ladder Diagram
Users more familiar with non-automation languages can gain access to an EPIC’s open-source operating system and create custom programs in languages such as C/C++, Java, Python and others. An EPIC device does not limit programming options like PLCs and PACs or force one to learn a new programming language. It instead lets users leverage what they already know to create control, data exchange and HMI programs more quickly.
Industrial: Controllers often have to operate in difficult environmental locations. One problem with using PCs in industrial automation is that an off-the-shelf PC cannot be trusted to stand up to harsh environments.
In contrast, EPIC devices incorporate real-world automation experience and are built to withstand tough conditions. Industrial-grade components like solid-state drives are designed for long life. UL hazardous locations approval and ATEX compliance are usually standard. Operating temperature ranges are wide, for example, -20 to 70 °C. EPIC I/O should be hot swappable, with stainless-steel chassis in different sizes to fit enclosures or machine designs, and with options for DIN-rail or panel mounting.
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, an EPIC fills the role of a PLC or PAC in a control system.
Typically, I/O modules will offer multiple channels, with isolated channels available. Analog and discrete I/O should be available to accept a variety of signals, with each channel usually software configurable.
Because EPICs are typically designed by control engineers, they often include features that simplify commissioning and troubleshooting, such as:
–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 to accommodate a variety of wire sizes
–LEDs on each I/O module that indicate module health and discrete channel status
OEM Solution
Returning to the oven manufacturer challenges discussed earlier, here’s how they could use an EPIC to address their issues.
The EPIC can be wired directly to sensors and actuators in the oven to provide control, monitoring, data processing, communication and visualization in a single unit. For control programming, the OEM can use a flowcharting language, one of the CODESYS IEC 61131-3 compliant languages (like ladder diagram or function block diagram) or Secure Shell access (SSH) for creating a custom program running on the Linux OS.
For an improved HMI experience, the OEM has choices:
–On smaller ovens, the EPIC’s built-in touchscreen can provide local visualization (Figure 3).
–On larger ovens, an industrial monitor can be added and plugged into the EPIC’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.
The first of what are anticipated to be many EPIC devices on the industrial automation market comes from Opto 22 (Figure 3). Their EPIC device was released in May 2018, and quarterly software updates since then have added significant features. This EPIC device features a built-in HMI, sufficient for many OEM applications.
Because the EPIC’s system management software is web-based, the OEM can apply software updates and manage the oven from their location instead of traveling to the customer’s site.
Perhaps the greatest advantage of an EPIC device for the OEM, however, is the ability to get the data needed from their ovens at customer sites, without causing security issues for their customers.
In addition to the usual request/response method for data communication, an EPIC 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 using 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 (Figure 4).
EPIC devices can be employed to securely exchange data between an OEM’s headquarters and its customers’ sites.
Most important from a security standpoint, all communications are initiated outbound from the data source or subscriber to the broker. Once initiated, data can flow in both directions. Most company firewalls allow outbound communications, so there’s no need to open ports in firewalls. Security is maintained and IT involvement is reduced.
EPIC devices can provide real-time control for all kinds of traditional automation applications, and also 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.
Opto22
www.opto22.com
Filed Under: IoT • IIoT • internet of things • Industry 4.0
