30 October 2008

Tony Paine of Kepware Technologies explains the importance of the communications driver to the efficiency of the entire manufacturing system.

Sure, the engineer is proud of his HMI, highlighting the realism in his displays, the colour coordination of his data and the mastery of his navigation. And then there is the plant manager, gushing over his KPI dashboard and how effectively the plant is running with the implementation of his new MES solution. The historian and analytic solution get all the credit when a plant control crisis is averted. Does anyone ever think to thank the lowly communications driver? Without data, the HMI is just a pretty picture, and the best analytics in the world are only ideas without any basis in fact. And, you spend tens or hundreds of thousands on that, while the driver budget isn’t even a line item on the spec sheet.

Next time you are considering a driver, think about how well your plant would run if it failed, and allocate your budget appropriately

Tony Paine, executive VP/CTO and co-owner of Kepware Technologies The plain truth is that the communication driver is one of the most important aspects of any automation system. It is the blood that powers your system. The communication arteries and veins reach out to all areas of your plant, sending and receiving data, efficiently and tirelessly ensuring your ability to acquire, analyse and adapt to the situations at hand. Windows came along with technology to share information between applications through Dynamic Data Exchange. This sparked the idea of a common interface, enabling all software vendors to interoperate. Microsoft technology progressed and in 1995 the OPC Foundation was created, with the idea to leverage the newest Microsoft technologies (Object Linking and Embedding – OLE), to develop an interoperability standard enabling automation applications to exchange data for process control. Drivers benefited immediately. Finally, there would be a high performance standard that drivers could leverage for connectivity to more than one vendor.

Vendors quickly adopted the OPC standards. Their native driver interfaces were augmented with additional OPC interfaces. Their client applications became OPC-enabled so they could leverage third party drivers and products across all Microsoft operating systems, from desktop and server to Windows Embedded. Independent driver developers could now find a wider market for their drivers, generally developed as part of some system integration effort. An industry was born.

OPC was a major step in the right direction, but it was not the model of perfection. While OPC exists for interoperability, it is up to the developers to adhere to that standard and also validate interoperability – to the point of reaching a self-certification designation. Drivers developed by different developers will fundamentally behave differently and will have different user interfaces, methods of operation, and diagnostics. A driver developed for one specific application will not necessarily excel in all other applications. And, unless there is a significant volume for the application of a driver, the long-term cost of maintenance can become prohibitive.

These factors all resulted in a driver marketplace delivering varying levels of performance, reliability, functionality and overall quality. Even drivers from major vendors that offer communications along with their more strategic HMI/SCADA and historian offerings, may suffer from the lack of ongoing attention and overall enhancement due to the maintenance costs involved. Many vendors have chosen to migrate to an outsourced driver model, leveraging the high volume and industry wide experience of a dedicated driver development company.

In February of 2008 the OPC Foundation introduced a new level of certification. In the past, testing tools and vendor interoperability meetings were the only path to certification, through a self certification process. Today there is an OPC Foundation authorised independent test laboratory located in Germany. This lab performs exhaustive testing over a period of several days to prove all aspects of OPC conformance, in addition to making recommendations with regard to installation and usability. In the end, vendors can earn a ‘Certified OPC Compliant’ logo. Buyers should look for the certified logo for a number of reasons. It shows the product has reached a level of quality that is to be expected. It shows that the company has made the significant effort necessary to achieve that level of quality and hence indicates that this driver is likely to be supported into the future. But what features should you look for in a driver? It isn’t just about getting data from point A to point B. Drivers need to be designed for performance, ease of use, reliability and optimum operation in the event of a disruption in operation. The latter is a major point, often overlooked in the development of communications.

Performance falls into a number of categories. There is, for instance, the performance of communications. Devices generally offer a variety of mechanisms for the acquisition of information. They may support single variable reads, reads of blocks of data, or the ability to subscribe to data and receive unsolicited updates. The best drivers will navigate these options for the user, autoselecting the method based on data requirements. Performance needs to account for the priorities of various tasks.

Writing information to devices needs to be done efficiently, and needs to be guaranteed in periods of stress. High demands in reading cannot override the ability to send write commands. And, writes cannot dominate – for example, writing a thousand variables needed for a recipe change could easily disrupt the normal read processes and could impact the data acquisition of a critical high speed process. The demands of a communication driver should not overly impact the operation of the PC on which it is running.

Applications often have tag counts into the hundreds of thousands, some updating frequently, others only when diagnostics are active. Drivers must be optimised for multi-threaded operation, must allocate memory effectively, and must clean up after themselves to avoid impacting other processes running in the computer.

Ease of use would seem straightforward. Configuration menus should be simple and self-explanatory. Help menus should not be an afterthought. They need to be detailed and context sensitive. Ideally, the driver should deliver features for autoconfiguration wherever possible. Many devices today contain the details of their configuration, either within the device itself, or in a programming file that can be readily decoded by a self-configuration driver. Often, function is performed at the trigger of a configuration wizard. However, some drivers can enable this as an automatic feature.

It is rare that an engineer would configure a driver through menus and be done. A more likely scenario is to configure one portion of a process, perhaps one of many production lines, then use copy and paste tools, or import and export tools, to replicate the configuration, with any necessary tweaks. Microsoft Excel is still the most widely used tool used in automation for auto-naming and replication of I/O lists. One area of challenge is the ability to reconcile the configurations of different drivers from different vendors. As said earlier, drivers from different developers are all completely different from a configuration database point of view. A solution to this problem is only possible by selecting drivers from a vendor that has focused on consistency across their entire driver library, not only in operation, but also in all configuration tools.

Reliability is a must in this industry. So, how do you make a driver reliable? The key elements are experience, the reuse of proven code, testing with industry solutions, interoperability meetings and internal practices in order to develop and properly quality-assure a driver solution before it is installed on site.

What about operation when things are going wrong? Huh? That’s important? It is so easy to make a driver work and perform well in the best of conditions. But that isn’t always the case. Drivers may be communicating through wireless and may receive garbled messages due to static during storms. Drivers may be communicating with hundreds of devices, some working, some not. The failure of one device should not inadvertently affect communications to others. It takes attention to details in the design of communications buffers, timeout designs and polling strategies to maximise operations under adverse conditions. Often, drivers will deliver tuning parameters for auto-demotion features, enabling a driver to demote the polling of a failed device to reduce impact on the overall system.

The best drivers have been designed to handle all of the above, and deliver this functionality consistently across the broadest suite of protocols, giving process engineers one source for all of their device connectivity.

ABOUT THE AUTHOR

Tony Paine is the executive VP/CTO and co-owner of Kepware Technologies. Tony joined Kepware in 1996 and has been pivotal in the architectural development of all Kepware products including its flagship product, KEPServerEX. Tony has represented Kepware in various open standards committees and is currently a member of the Technical Advisory Committee for the OPC Foundation, where he helps to drive the technical direction of the industry. Tony has a Bachelor’s degree in Electrical Engineering from the University of Maine in Orono.

This article first appeared in the Autumn 2008 edition of Prime magazine.

Add a comment