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.
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.
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.
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.