How OPC Can Improve Operational Vision

• By Rodrigo Restrepo
• Operations and Maintenance

Summary

Flexible communications software and services can help upgrade functionality while preserving existing HMI and other automation system components.

Manufacturing sites simply do not appear in their final form overnight. They are instead developed over years and decades, with production lines usually made up of many subsystems for processing, assembling, packaging, and more. End users undertake expansions and upgrades when justified to increase production and to improve efficiency and quality.

While large expansions may offer the opportunity to make wholesale changes, the reality is that users much more commonly perform incremental upgrades. Sometimes these add functional capability. In other cases, users take on digital transformation projects to add Internet of Things (IoT) data gathering capabilities to their systems. 

During these modernization or enhancement projects, not only must new equipment be mechanically fitted, but often there is great complexity from an automation standpoint when attempting to add new and desirable functionality while preserving as much of the legacy automation systems and equipment as possible. Systems integration efforts to seamlessly merge new and old technology can be difficult, eating into the expected value of new tech and digitalization. For this reason, end users and systems integrators (SIs) are always looking for more options they can add to their toolkit to improve the success of system upgrades, and the right portfolio of software tools is essential for these projects.

Assessing existing operations

Typical automation system architectures include programmable logic controllers (PLCs), often one per machine, for monitoring sensors, processing logic, and controlling actuators and motors. A local human-machine interface (HMI) gives operators visibility, and many PLCs and HMIs may be networked together and to a supervisory control and data acquisition (SCADA) system.

Any newly installed automated machinery is likely to have its own onboard complement of PLCs and HMIs, which need to be interfaced with the greater facility. Even newer sensing systems and field devices are often intelligent, with onboard microcontrollers, along with wired or wireless networking capabilities.

A major complication is that there are many different product vendors and industrial networking communication protocols, and interoperability is never guaranteed. Sometimes the various makes and models of products are intentionally selected because they are the best-of-breed, but more likely the resulting products are simply all that was available. Standardization and compatibility have improved somewhat over the years, with development and acceptance of the open platform communications (OPC) protocol as just one example. However, there are still many roadblocks when integrating so many disparate devices.

Connecting it all

Many projects use simple hardwired interconnects and relays to perform basic handshakes between equipment, but newer Ethernet-capable systems are likely to have a large amount of valuable operational and diagnostic data available over the network—if users can tap into it. It is usually more attractive to integrate a new system using one network cable, if possible, instead of dozens of hardwired connections. So while traditional system architectures tended to be very hierarchical—from field device, to PLC, to HMI, to enterprise—it is now possible and often desirable for almost any automation element to interact with any other element, if the right networking and communication software provisions are in place.

One manufacturing operation found itself in exactly the situation described above. Some processing equipment used proprietary controllers, and others used PLCs from various vendors. The HMI and historian were from yet another vendor. When the end users first began integrating their equipment several years before, they eventually engaged a solution provider offering a universal device server software.

The solution provider in this case is not a systems integrator, but instead someone who focuses on supporting end users and SIs for the selection and application of the right industrial automation integration software. The universal device server recommended by the solution provider lets users connect all types of industrial devices into a modern OPC environment.

Automation systems have a fundamental need for such a product, because there are thousands of devices in the field, many legacy but some new, which do not have an off-the-shelf OPC driver. Designers have commonly avoided close integration of these devices due to the complications involved, but today’s IIoT initiatives demand the acquisition of this data.

Therefore a flexible universal device server lets users visually configure the required protocol messages to any type of field device, and effectively translates those specialty communications into a standard OPC format compatible with PLCs, HMIs, and other automation devices and software. Drag-and-drop configuration makes this possible without custom code. 

For the original universal device server installation, the solution provider helped with the end user integration efforts. The resulting solution proved rock solid over many years, enabling all the automation elements to communicate smoothly.

Keeping a new eye on production

Eventually, as part of their process for continuous improvement, the quality assurance (QA) team at this end user company wanted to add an advanced digital vision surface inspection system to one of the production lines. This system inspected and rapidly identified problems in the produced material. The QA initiative had the potential to save a lot of money, and a successful implementation could be scaled out to many other production lines and sites.

However, the first step would require integrating the new and relatively complicated vision system with an assortment of existing control platforms. Because the engineering team already relied on data handling products for operating the plant, they looked to the provider of these products for the new integration solution.

The existing automation system would need to inform the vision system about what product recipe was actively running so it could base inspection upon the proper preconfigured profile. The vision system would need to acknowledge receipt of this information, and notify operators via the automation system when deviations were detected.

Potentially problematic protocols

As is the case in most operating facilities, the team wanted to minimize downtime, interference, and modification of existing systems. They preferred to find a way to use the existing infrastructure communication servers or HMI drivers to the greatest extent possible, and hoped they could use their already-in-service universal device server, which is an OPC DA and OPC UA server (but not a client), to integrate with their HMI system.

For this project, they needed to connect to the vision system’s native OPC UA server interface. However, even though OPC UA is a standard industrial communication protocol, it is a massive specification and there are many aspects of the protocol that may or may not be implemented by a specific software application or hardware device.

In this case, the vision system used the OPC UA methods facet sub-specification in its UA Server interface, which would require a new approach at the site. At this point, the end user team engaged their familiar solution provider for additional expertise.

Wrapping up a solution

As specialists in the field, the solution provider consultants already had expertise in helping users understand what various communications protocols are capable of, unraveling the real technical needs, and then finding off-the-shelf solutions. In this case, they suggested the addition of another software product to route OPC messages because it could interact with the type of OPC UA server methods used by the vision system’s OPC UA server interface. In turn, the OPC router would interact with the existing universal device server. The following methodology was developed:

• The OPC router subscribes to a trigger in the device server and the associated recipe ID.
• The HMI writes to the recipe ID and sets the trigger item when a new recipe is selected.
• The OPC router acts on the trigger and calls the appropriate vision system OPC method, transmitting the recipe data to the vision system, then resets the trigger.
•  As confirmation, the OPC router reads back the recipe information from the vision system, and supplies this information to the HMI.

This careful coordination is a good example of how OPC router software can solve interoperability problems between different systems. In this case, the vision system required a specific handling of methods to prepare for the next job, start it, and read back the information.

Field installation

With the plan in place, the next challenge was scheduling the installation and commissioning of the solution. All activities needed to work around production commitments, which meant the system was only available during brief downtimes at odd hours. It also meant the team had to exercise the utmost care to not affect upcoming operations.

For these reasons, the team designed the software solution to avoid interference with any existing functions, making it possible for the end user to bring the upgrades online quickly and confidently as opportunities presented themselves. Solution provider personnel were available via remote access methods to connect to the systems and work “virtually” side by side with the end users, providing support to augment efforts on site. Readily available professional services can make all the difference in supporting SIs and end users alike to help projects succeed.

Following this approach, installation ended up being quick and seamless. The solution was brought online and is providing the desired monitoring and warning capabilities. Now, many types of production issues are identified quickly, reducing manufacturing costs and minimizing wasted product.

Framework for the future

This installation has been in service for months, working reliably. The end user is happy with the performance and is preparing to scale the implementation up to other production lines. The company is also thinking about adding closed-loop control functionality, such as monitoring the vision system for alarms and alerting the production control systems to act accordingly.

Applications such as this are common throughout industry and are on the rise as more field devices become intelligent and users are moving ahead with digital transformation projects. The OPC routing software can also communicate to cloud-based servers using MQTT, a standard lightweight protocol popular for IoT applications, and it supports web services integration. Both are important as users look to develop more sophisticated IoT solutions.

Users want to realize operational value by using IoT methods for accessing and interconnecting smart sensor information in conjunction with new and existing PLCs, HMIs, and SCADA systems. Solutions providers with the right products and expertise are essential to support both SIs and end users, helping bring these projects online quickly with minimal disruption to existing operations.

Related resources

Find these InTech articles online at www.isa.org/intech-home/intech-archives.

• “Business transformation through digitalization,” May/Jun 2020
• “Solving big data problems with a little data approach,” Mar/Apr 2020 
• “Analytics for predictive, preventative maintenance,” Jan/Feb 2020 
• “OPC Field Level Communications: A controller-to-controller specification within reach,” Jul/Aug 2020

• Facebook
• Twitter
• Linked In