What is an industrial device driver?
Before OPC and standardized drivers existed, every application that needed data from a field device had to contain its own communication code for every device it might connect to. A SCADA system connecting to five different PLC brands needed five separate communication implementations, each maintained independently, each potentially conflicting when run simultaneously, and each requiring re-engineering whenever a device firmware revision changed. The driver model, introduced with OPC in 1996, replaced that approach with a single shared communication layer.
An industrial device driver is a software module that knows one thing deeply: how to communicate with a specific device or family of devices using their native protocol. The driver handles all the low-level details: framing request packets in the format the device expects, parsing the response, managing connection state, retrying on failure, respecting timing constraints, and extracting individual register or tag values from the response payload. Everything above the driver, including the OPC server interfaces (OPC DA, OPC UA), the client applications (SCADA, historian, MES), and the enterprise data layer, works with the abstracted tag data that the driver produces rather than with the raw device protocol.
A driver is not the same as an OPC server. The OPC server (like TOP Server) is the host application that provides the OPC DA and OPC UA interfaces to client applications. Drivers are the components within the OPC server that handle specific device communication protocols. One instance of TOP Server can run dozens of drivers simultaneously, each talking to different device types. The OPC server aggregates all the device data from all its drivers into a single OPC namespace accessible to any OPC client.
Why drivers exist: the pre-OPC problem
The driver model solved a fragmentation problem that had made industrial integration expensive and fragile for decades. Understanding what that problem was explains why the driver abstraction layer remains important even in modern OT architectures.
Driver anatomy: channels, devices, tags
In TOP Server and similar OPC server architectures, the configuration hierarchy that organizes driver instances has three levels: channels, devices, and tags. Understanding these levels is essential for configuring drivers correctly and for diagnosing communication problems.
Tag addressing across different drivers
Every driver has its own tag addressing syntax, because every device protocol has its own way of identifying data points. Understanding the addressing convention for a given driver is the most common practical task when configuring a new device connection.
For drivers like the ControlLogix Ethernet driver, automatic tag generation (ATG) eliminates manual tag address entry by querying the tag database directly from the connected controller and importing all tags with their data types, array sizes, and UDT structures automatically. For drivers like Modbus where no tag database exists on the device itself, tags must be entered manually or imported from a CSV mapping file prepared from the device's register documentation.
Scan modes and polling behavior
How often a driver polls a device for new data, and under what conditions, is controlled by the scan mode configured for each device object. TOP Server provides five scan mode options, each designed for a different integration scenario.
| Scan mode | Behavior | When to use it |
|---|---|---|
| Respect client rate Default | Polls the device at the rate requested by the fastest connected OPC client. If no client is connected, polling stops. | Most SCADA and OPC DA/UA scenarios. The client application controls how frequently it needs data updates, and the server matches that rate. Efficient: no polling when nothing is listening. |
| Fixed rate | Polls the device at a configured fixed interval regardless of what clients request. The fixed rate overrides any client-requested rate. | When you need consistent device polling independent of client activity. Useful when clients connect and disconnect frequently and you want to ensure tag cache freshness. |
| Respect client, floor | Follows client-requested rate, but will not poll faster than a configured minimum interval even if a client requests a faster rate. | When device responsiveness or network constraints limit how fast you can realistically poll. Prevents a misconfigured client from overloading a slow or constrained device. |
| Demand poll | The device is not polled automatically. Reads are only triggered by an explicit client request or by writing to a special _DemandPoll system tag. | SCADA systems in oil and gas, water/wastewater, and other telemetry applications where devices are geographically distributed, bandwidth is constrained, and the client controls when each device is polled. |
| Do not poll | The driver never polls the device. Only explicit write operations from clients cause device communication. | Devices that are write-only from the OPC server's perspective, or scenarios where the device pushes data to the server via unsolicited messaging. |
Scan rate is not the same as data update frequency. The scan rate tells the driver how often to ask the device for new values. The device's own response time, the network latency, and the protocol's efficiency all determine how quickly a new value arrives after the request. On a fast Ethernet network with a responsive PLC, a 100 ms scan rate typically achieves near-100 ms update latency. On a slow serial RTU over a cellular modem, the same scan rate might produce 2-5 second actual update latency as the driver waits for the device's response.
Deadband filtering
A deadband is a filtering threshold that suppresses tag updates when a value changes by less than a configured amount. It exists to prevent noisy or slowly drifting analog measurements from generating a flood of updates, most of which carry no actionable information change.
A temperature sensor with natural noise that fluctuates ±0.3°C around its true value without a deadband would generate a new OPC update on every scan, even though nothing operationally significant has changed. With a 0.5°C absolute deadband configured, updates are only delivered to clients when the value moves more than 0.5°C from the last reported value. For a process where ±1°C of drift is operationally insignificant, this reduces the tag update rate by 80% or more without losing any meaningful information.
Deadbands are typically configured as a percentage of the tag's engineering unit range (a 2% deadband on a 0-100% level tag means updates are suppressed for changes smaller than 2 units) or as an absolute value (a 0.5°C deadband on a temperature tag). The OPC server applies the deadband before delivering updates to client applications: the device is still polled at the scan rate, but the OPC server filters what it reports to clients.
Driver categories in TOP Server
TOP Server's 140+ driver library covers the full range of industrial device communication scenarios. Drivers are organized by vendor, protocol family, and industry application.
Configuring a driver: what the process looks like
Setting up a new device connection in TOP Server follows a consistent workflow regardless of the specific driver being used.