Call us! 512-349-0334 or (877) INDUSOFT

How Are Driver Messages Prioritized and Sent in InduSoft Web Studio?

The way that Driver Task Messages are placed into the Driver Messages Queue in InduSoft Web Studio SCADA/HMI software depends on two factors:  Timestamp and Priority.

Messages with higher priority are executed before messages with lower priority, regardless of their Timestamps (time when the messages were triggered). Messages with the same priority are executed according to their timestamp, in a FIFO (First In, First Out) manner.

Note: If the user specified a number of retries in the communication driver Settings >> Advanced dialog, the communication driver keeps retrying to execute the message the number of times specified by the user in case the communication fails. When the number of retries expires, the message is removed from the queue, even if the communication was not successful.

Because the Driver Runtime in InduSoft Web Studio inserts the messages into the queue in the order that they must be executed (which is based on the priority and timestamp of each message), the Communication Driver executes the topmost message on the message stack first, removing it from the queue after executing it, regardless if the communication was successful or not.

Figure 1 and Table 1 illustrate how the Driver Runtime task inserts the messages in the queue according to their priority/timestamp and how the Communication Driver executes the message from the top of the message stack and removes it after executing it.

Figure 1: Driver Runtime creating the message queue

Note: Prior to InduSoft Web Studio v6.1+SP5 (Build, messages from the Enable Read When Idle commands had an even lower priority (priority 4). Then, these messages would not even be sent to the queue, unless there was at least one driver instance (thread) available (idle) to execute it. This behavior was not necessary wrong, but it led to confusion, so it was modified for newer versions.

Table 1: Message Type and Priority


Communication Driver Modes

The simplest scenario for the Communication Driver interface is one instance of a Communication Driver exchanging data with one device (Figure 2).

Figure 2: Driver Runtime Task and Driver Communication Thread (<DriverName>.dll)


The Driver Runtime task in InduSoft Web Studio is able to handle more than one Communication Driver simultaneously. The maximum number of Communication Drivers supported simultaneously by the Driver Runtime task is limited by the product license (Figure 3).

Figure 3: Driver Runtime Task with Several Communication Drivers

Additionally, the same Communication Driver can exchange data with several devices (Figure 4).

Figure 4: Driver Runtime with a single instance of the driver talking to multiple devices

Each instance of a Communication Driver executes the messages from the Driver Messages Queue synchronously. This means that the Communication Driver does not execute the next message in the queue until the current message is completely executed (i.e., receives a successful reply from the device, receives an error from the device, or times-out.

This behavior is suitable for many small and medium sized systems. However, in large systems, this scenario might not provide expected performance, because the Communication Driver becomes a bottleneck when communicating with several devices, or even with one single device.

When the Communication Driver is exchanging data with more than one device, and at least one of them is not available (i.e., disconnected from the network), this situation can significantly decrease the performance of the whole communication interface. This is because the Communication Driver does not execute the subsequent messages in the message stack for other device(s) properly connected to the network during the time that it is attempting execution of the message(s) for the disconnected device. Since the “Time-Out” time is typically set in order of seconds, it can cause serious delays in the communications to all devices.

InduSoft Web Studio provides a solution for these architecture bottlenecks by using “Simultaneous Connections” for the same Communication Driver.


Simultaneous Connections

Note: The maximum number of simultaneous requests depends on the device and protocol specifications. Please consult the device manufacturer’s documentation for more information about the device and protocol that you are using.

The user can configure the number of simultaneous connections for the same Communication Driver in the Settings >> Advanced dialog interface of the driver (Figure 5). During runtime, IWS creates an independent instance (thread) of the Communication Driver for each simultaneous connection configured by the user.

Figure 5: Driver Settings and Advanced Settings Showing Simultaneous Connections.

Figure 6: Driver showing two simultaneous connections to the same device

Figure 6 illustrates the internal structure of the communication interface of IWS when the user configures two simultaneous connections for the same device.

It is important to mention that the instances (threads) of the driver are created in memory, and are transparent to the user.

Each simultaneous connection of the Communication Driver works in parallel with the others. When an instance executes one message, it removes it from the queue and looks for the next suitable message in the queue starting at the top of the message stack.

IWS implements various mechanisms to make sure that simultaneous connections of the driver do not attempt to execute the same message in the Driver Messages Queue. When one instance (thread) of the communication driver looks for a message in the Driver Messages Queue, it might not take the topmost message, if it is addressed for a device which is already in communication with the maximum number of connections (other communication driver instances) configured by the user. In this scenario, the communication driver that is idle looks for the topmost message for a device that is not in communication with the maximum number of connections configured by the user – which may not be necessarily the topmost message in the queue.

Figure 7: Driver showing two simultaneous connections to two different devices

Figure 7 illustrates the internal structure of the communication interface of IWS when the user configures two simultaneous connections, with one per device. In this scenario, there will be one instance (thread) of the communication driver for each device. Should one device not respond to the driver requests, this situation will not decrease the communication performance of the other device.

Note: Simultaneous connections cannot be implemented with serial protocols because the physical layer does not support asynchronous requests on the serial line (peer-to-peer). Moreover, drivers that use third-party libraries will support simultaneous connections only if the third-party library supports it too.


More information regarding the operation, setup and configuration of the Communications Drivers can be found in the main Help manual (Techref.pdf) for InduSoft located at Contents >> Communications with Other Devices >> Drivers and in the Driver Help Manual for the specific driver <DriverName>.pdf.

Additionally, more information regarding driver operation, the driver task, communications background information, and a discussion regarding protocols can be found in the Tech Note, “Driver Runtime” located here.

Comments are closed.