Do you remember the days when every time you needed to connect a new printer to your PC, you had to hunt down the disk with the original software to install the printer driver? Often, you even had to manually adjust the operating system settings to get the computer's port working and establishing communication with the printer. And then you'd check the cables over and over, thinking there was a problem or that you'd done something wrong, even when there wasn't. It was a frustrating and time-consuming task—just like setting up industrial equipment today.
However, it doesn't have to be this way. As PC and peripheral manufacturers have embraced Ethernet and collaborated on standards, connecting equipment and running applications has become increasingly simple and easy. Today, it takes just a moment to install a new printer, download and transfer files, integrate different types of documents, or access email from virtually anywhere in the world. With the increasing adoption of Ethernet in manufacturing operations, systems developers expect that the same type of functionality found in Ethernet-based office systems will further simplify their factory commissioning efforts. One of the most important ways to achieve this is by improving interoperability and streamlining the configuration process so that hardware and software from different manufacturers can work together.
However, one of the factors limiting equipment manufacturers' ability to achieve interoperability is the engineering bandwidth they can dedicate to software interfaces for configuration and parameterization. Even in Ethernet, with at least five major standard versions (Profinet, EtherNet/IP, Modbus TCP, EtherCAT, and Fieldbus H1) and a large number of minor variants and legacy systems, achieving standardized parameterization when the controller attempts to connect to the equipment is a daunting task. To further complicate matters, once the connection is established, each controller has proprietary programming software that often doesn't support a particular plug-in or equipment application (think of how a web browser behaves). For the user, this means being forced to load more manufacturer software, navigate through various different windows, and re-copy data into unfamiliar registers to get everything working.
Nevertheless, some forward-thinking manufacturers are finding ways to advance the interoperability agenda and develop common systems that allow equipment from different vendors to communicate with each other within the same factory. Industry groups are working to develop open standards. This will ultimately make it easier for engineers to install systems without having to use cumbersome and time-consuming manual methods to enable networking.
The Advancement of the Manufacturing Process:
One area to look for solutions is the manufacturing process, which has been promoting the use of Field Device Template (FDT) software containers for some time. This standard allows companies to control the incorporation of standardized Device Template Managers (DTMs) from equipment manufacturers. DTMs allow a piece of equipment to appear within an application at the system level.
For example, field devices such as control valves or flow meters in a storage tank on a farm can be calibrated and parameterized so that the entire system functions correctly. Using FDTs, a Distributed Control System (DCS) can introduce a common container application that allows a commDTM software object from each vendor to appear within the container to configure the device. The appearance and operability across devices will remain consistent, interoperability is excellent, and the user performs the configuration with the assurance that they have placed the correct parameters in the correct fields for all devices, regardless of make and model.
In discrete manufacturing, the adoption of this technology has been slow but has been accelerated by a movement to unite disparate standards such as EDDL and FDT into a single, powerful standard that provides a universal method for connecting and sharing data using OPC UA. EDDL (Electronic Equipment Description Language) is used in the core processes of industrial manufacturers to describe the information accessible on devices during configuration. OPC (OLE for Process Control) is managed by the OPC Foundation and is a way to present data from manufactured equipment in a standardized format so that a descriptive data label can be used in various higher-level applications.
EDDL is especially important for diagnostics and parameterization. The strength of OPC lies in data collection and visualization, while the advantage of FDT lies in the configuration and organization of equipment connections. Combining these two features and merging them into a single standard is a highly desirable goal for all users. A combined standard would allow equipment vendors to include a single, standardized plug-in for all sectors and applications. Each vendor's monitoring systems could then navigate the equipment, find the standardized labels, and display them consistently within the container application, appearing as a single, unified software component. What we're hoping for is simply the same ease of use as today's modern printers.
The new combined standard is called FDI (Field Device Integration) and is backed by five major networking organizations and some of the biggest names in the industry (including collaborating companies such as ABB, Emerson Process Management, Endress+Hauser, Honeywell, Invensys, Rockwell Automation, Siemens, Smar, and Yokogawa). It is scheduled for release in the summer of 2010, with preliminary information from working groups already showing considerable enthusiasm. Although initially planned to meet the interests of the process industry, the breadth of manufacturer support and the market presence of collaborators provide the confidence to adopt it widely in all industrial applications.
Barriers to Adoption
While the benefits of such a system are clear, there are also barriers to its adoption. The first is that some automation companies have traditionally tried to retain their customers by using proprietary systems, closed software structures, or variations of standards. In a proprietary system, customers have difficulty acquiring certain equipment from other manufacturers because of these special variations. An open system means that companies compete purely on the merits of the value they deliver. Some vendors are wary of pursuing such a strategy, given the challenges of the global economy and the historical ease of customer retention based on legal ownership ties.
Another barrier is simply resistance to change. Some companies have just integrated a previous standard and are reluctant to immediately undertake another project improvement. Others have laid off engineering staff due to the current economic climate and do not have the personnel to adopt and learn a new system right now. An additional factor is that many industrial customers are overly patient and frequently tolerate implementation problems.
Having worked in various sectors, I'm astonished to discover that industrial manufacturers tolerate substandard interfaces in their automation systems. I've observed systems engineers working on the factory floor for two weeks, struggling to get something working before giving up and moving on to a different system. They wouldn't tolerate this if they'd bought a product on sale; if they couldn't get it working in thirty minutes, they'd immediately return it to the store and demand a refund. Perhaps we need some of this justified outrage in the world of industrial systems.
Available Solutions
Knowing this, vendors and users already have some options to make automation systems work better in discrete manufacturing environments without waiting for further standardization and adoption. Some automation system manufacturers are already opening up different parts of their software to allow third-party devices to communicate directly with their equipment on the network. This isn't the same as having a universal, open standard, but it at least allows partner companies to access more third-party areas.
For example, Rockwell Automation allows equipment manufacturers to develop Additional Instructions (AOIs). These are partially standardized software elements that allow third parties to include various lines of instruction code that tell the software system how to prepare their equipment on an AR network. This allows for the development of more descriptive parameters instead of just using addressing options. It also makes third-party equipment behave more like other equipment in the Rockwell system.
Another option is for third-party vendors to work with an AR (Allen-Bradley Operator) to create comprehensive additional profiles using parameter tables for their equipment, which will then function as Allen-Bradley equipment within the software system. A third-party vendor cannot accomplish this independently; they must provide certain information to Rockwell Automation and compile it as an object for the software system. However, at least the profiles offer consistent, integrated access for users.
Rockwell also allows third-party vendors to export logic from the control program via DeviceLogix®, a system that enables the third-party vendor to accept the core logic object from outside the Rockwell Automation programming environment and incorporate it into their equipment so it can be programmed over the network. This allows a local I/O block to execute simple logic on the equipment itself instead of externally at the controller. The third-party device can then be programmed in a way that is very familiar to the AR user. This is a small but very useful step on the path to full integration.
Another good example of Rockwell Automation's open software elements is RSLinx®, a communication server that provides plant equipment connectivity for a wide variety of Rockwell software applications, enabling the system to communicate remotely with field equipment. Molex Incorporated uses RSLinx through a DLL interface that allows them to connect to their equipment via AR paths. While the user still relies on a third-party tool to prepare their equipment, tracing parameter settings and establishing configurations through the routing tables that Rockwell has created using RSLinx offers greater integration and is easier to implement than installing new connections. A systems engineer can use RSLinx as a "jump box" mechanism to automatically recognize each device. Mechanisms like this represent good intermediate steps as we move toward a common open Ethernet standard.
Although we have used Rockwell Automation as an example, many major automation vendors have similar ways for third-party devices to connect to their systems, provided they have the time and money to implement it individually. Taking this process a step further—such as using FDI structures as a common industry standard—would mean vendors would no longer face these significant time and cost barriers to achieving true interoperability across the diverse systems on the market. Engineers would no longer need to write individual instructions for each system from different manufacturers. Innovation and ease of use could advance even further if the time and money wasted supporting competitors' approaches were instead invested in providing greater usability. Technology support costs would decrease if all market players focused on the low-profile nuances of the common system.
Having a single platform sets goals for people to innovate. Instead of worrying about establishing basic connections and being able to communicate with a device, system developers can use a common platform to focus on optimizing their applications and making them simpler and easier to use.
The difference between open and proprietary systems in industrial automation is like the revolution we see with products like the iPhone or Blackberry today. It's easy to develop applications for these devices because they are simple and very open. As a result, third-party companies can assist leading manufacturers with a wealth of applications that enhance the user experience, many of which become essential and eagerly anticipated by the market. Innovation flourishes and accelerates as developers gain confidence in the platform.
Similarly, for an industrial automation engineer tasked with creating diverse applications for systems from Emerson, Rockwell, or Siemens, the motivation is not to develop cutting-edge applications, but rather to spend their time maintaining basic connectivity. If they suddenly have the freedom to innovate beyond the basics because the connections and form factor are already in place, system optimization and customer satisfaction will increase dramatically. It is up to everyone involved in industrial automation to make this a reality.
Molex strongly supports the development of an integrated approach. We, along with other companies, have adopted FDT and OPC and are working to unite them in the FDI standard. With a long history of integrating products from various system vendors, we appreciate the challenges and benefits that the shift to FDI will bring to enhance the customer experience. It is clear that the work will be much simpler with the adoption of a common platform like FDI.
Molex is a registered trademark of Molex Incorporated.
DeviceLogix and RSLinx are registered trademarks of Rockwell Automation.
All other product and company names are trademarks of their respective owners.
