The Unsung Hero of Automation

Sure, the Engineer is proud of his HMI, highlighting the realism in his displays, the color 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 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…

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 acquire, analyze and adapt to the situations at hand. Over the years, drivers have changed. In the beginning… There was DOS. I'll keep this brief – I know this may be before your time… Drivers were part of the primary application. If you were using an HMI, the device driver was provided by the HMI vendor and would only work with that HMI. Along came Windows with technology to share information between applications through a technology called DDE (Dynamic Data Exchange). Though making progress, the years of major investment in custom drivers was too great to throw away. In 1995, the OPC foundation was created, with the idea to leverage the latest Microsoft technologies, to develop an interoperability standard enabling automation applications to

exchange data. Drivers benefitted immediately. Finally, there would be a high performance standard that drivers can 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. Independent driver developers could now find a wider market for their drivers, generally developed as part of some system integration effort. And, an industry was born.

While a step in the right direction, this was not the model of perfection. While a standard exists for interoperability, it is up to the developers to adhere to that standard and test interoperability – to the point of reaching a self certification level. Drivers developed by different developers will fundamentally behave differently and will have different user interfaces, methods of operation, diagnostics, etc. 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, delivering drivers 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.

New Standards will improve driver interoperability. In February of 2008, the OPC Foundation introduced a new level of certification. Where 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 authorized 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 had made the significant effort necessary to achieve that level of quality and hence indicates that this driver is likely to be supported now and 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 being a major point, often overlooked in the development of communications. We'll review these in more detail.

Performance falls into a number of categories. There is 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, auto selecting 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. Finally, 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 optimized 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 straight forward. 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 auto-configuration wherever possible. Many devices today, contain the details of their configuration either within the device itself, or in a programming file that a self-configuring driver can readily decode. Often, this function is triggered by 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. Excel is still the most widely 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 driver library, not only in operation, but in all configuration tools.

Reliability is a must in this industry. Our automation systems are the core to the world's infrastructure. A batch of drugs may be worth millions of dollars. Failure is not an option. So, how do you make a driver reliable? Experience, the reuse of proven code, testing with industry solutions, interoperability meetings, and internal practices to develop and properly QA a driver solution before it in installed on site. Unfortunately, many drivers are born out of a system integration need, and are then repurposed as a standard offering. In the world of drivers, Buyer Beware. A good deal often isn't, and it is easy to invest over ten times the cost of a driver in configuration, and fine tuning efforts. What about operation when things are going wrong? It is very easy to make a driver work and perform well in the best of conditions. But you can't count on having the best conditions. There are many types of communication failure modes that are often overlooked by the casual driver developer. Drivers may be communicating through wireless and may receive garbled messages due to static, storms, etc. Drivers may be communicating with hundreds of devices, some working, some not. The failure of one device should not inadvertently affect communications to others. Other software programs may inadvertently attempt to communicate with the driver, flooding it with unexpected messages. It takes attention to detail in the design of communications buffers, timeout designs and polling strategies to maximize 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 to 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. Next time you are considering a driver, think about how well your application would run if it failed, and allocate your budget appropriately.
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..... See More Details.