Drivers bring automation systems to life

Sure, the engineer is proud of his human-machine interface (HMI), highlighting the realism in the displays, the color coordination of the data and the mastery of the navigation.


Sure, the engineer is proud of his human-machine interface (HMI), highlighting the realism in the displays, the color coordination of the data and the mastery of the 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 manufacturing execution system. 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 %%MDASSML%% or hundreds %%MDASSML%% of thousands of dollars on these, 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 to acquire, analyze and adapt to the situations at hand.


Birth of an industry

Drivers have changed significantly over the years. In the beginning %%MDASSML%% there was DOS (which stands for disk operating system, and pre-dates Windows). I’ll keep this brief %%MDASSML%% 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 work with only that HMI.


Along came Windows with technology to share information among applications through a technology called Dynamic Data Exchange (DDE). 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, and to develop an interoperability standard enabling automation applications to exchange data. Drivers benefited immediately. Finally, through OPC, 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 %%MDASSML%% 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 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 resulted in a driver marketplace delivering varying levels of performance, reliability, functionality and overall quality. Even drivers from major vendors %%MDASSML%% delivering drivers along with their more strategic HMI/SCADA and historian offerings %%MDASSML%% 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, 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 regarding 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.


Driver design

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, which is often overlooked in the development of communications.


Performance falls into a number of categories. First 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 %%MDASSML%% 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 should 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 %%MDASSML%% or import and export tools %%MDASSML%% 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 completely different from a configuration database point of view. A solution to this problem is possible only 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. A batch of drugs may be worth millions of dollars. Failure is not an option. So, how do you make a driver reliable? Reliability is the result of 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, it’s “buyer beware.” A good deal often isn’t, and it is easy to invest more than 10 times the cost of a driver in configuration and fine tuning efforts.


Drivers in operation


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 or other forms of interference. Drivers may be communicating with hundreds of devices %%MDASSML%% 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 these situations, and deliver this functionality consistently across the broadest suite of protocols, giving process engineers a source for 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.


A properly designed driver enables communication and interoperability among devices and between the devices and the HMI %%MDASSML%% regardless of the vendor.


The HMI is the operator’s window into the plant’s processes, enabling visualization beyond the control room walls. While the HMI represents the eyes of the plant, the communication represents the arteries and veins and the drivers represent the blood that powers the system.



Author Information
Roy Kok is the vice president of marketing and sales for Kepware Technologies, joining the company in July of 2007. Previously, he managed product marketing and product management of GE Fanuc’s HMI/SCADA solutions, primarily CIMPLICITY and iFIX HMI/SCADA products and associated communication drivers. Prior to GE Fanuc, Kok held key positions with notable automation industry companies including Intellution, VenturCom, Sytech, Nematron, Intec Controls and Kaye Instruments. As of 2008, Kok has more than 30 years of experience in the automation industry.


The Top Plant program honors outstanding manufacturing facilities in North America. View the 2015 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
Each year, a panel of Control Engineering and Plant Engineering editors and industry expert judges select the System Integrator of the Year Award winners in three categories.
Doubling down on digital manufacturing; Data driving predictive maintenance; Electric motors and generators; Rewarding operational improvement
2017 Lubrication Guide; Software tools; Microgrids and energy strategies; Use robots effectively
Prescriptive maintenance; Hannover Messe 2017 recap; Reduce welding errors
The cloud, mobility, and remote operations; SCADA and contextual mobility; Custom UPS empowering a secure pipeline
Infrastructure for natural gas expansion; Artificial lift methods; Disruptive technology and fugitive gas emissions
Mobility as the means to offshore innovation; Preventing another Deepwater Horizon; ROVs as subsea robots; SCADA and the radio spectrum
Research team developing Tesla coil designs; Implementing wireless process sensing
Commissioning electrical systems; Designing emergency and standby generator systems; Paralleling switchgear generator systems
Natural gas engines; New applications for fuel cells; Large engines become more efficient; Extending boiler life

Annual Salary Survey

Before the calendar turned, 2016 already had the makings of a pivotal year for manufacturing, and for the world.

There were the big events for the year, including the United States as Partner Country at Hannover Messe in April and the 2016 International Manufacturing Technology Show in Chicago in September. There's also the matter of the U.S. presidential elections in November, which promise to shape policy in manufacturing for years to come.

But the year started with global economic turmoil, as a slowdown in Chinese manufacturing triggered a worldwide stock hiccup that sent values plummeting. The continued plunge in world oil prices has resulted in a slowdown in exploration and, by extension, the manufacture of exploration equipment.

Read more: 2015 Salary Survey

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.
The maintenance journey has been a long, slow trek for most manufacturers and has gone from preventive maintenance to predictive maintenance.
Featured articles highlight technologies that enable the Industrial Internet of Things, IIoT-related products and strategies to get data more easily to the user.
This digital report will explore several aspects of how IIoT will transform manufacturing in the coming years.
Maintenance Manager; California Oils Corp.
Associate, Electrical Engineering; Wood Harbinger
Control Systems Engineer; Robert Bosch Corp.
This course focuses on climate analysis, appropriateness of cooling system selection, and combining cooling systems.
This course will help identify and reveal electrical hazards and identify the solutions to implementing and maintaining a safe work environment.
This course explains how maintaining power and communication systems through emergency power-generation systems is critical.
click me