Performance issues for the ASE driver

Support | Order Placement | ProScada Home Page | Download Demos

Performance Issues for ASE Driver

The ASE Driver exclusively uses polling to extract information from the ExCOM device. The ABB EXCOM protocol has no support for sending unsolicited data.

The EXCOM communication handler in the ABB Process Controller that is responsible for receiving and processing requests from external devices, is unfortunately a low priority task. The priority can not be modified. This means that in systems with a high processor utilization, the EXCOM communication handler will have severely limited performance. In systems with varying processor load, the performance of the EXCOM communication handler will fluctuate in accordance with the overall processor utilization.

Because of the low priority that the EXCOM communication handler has, it does not influence other tasks in a system to any greater extent. Only tasks with lower priority, such as the task that communicates with the programming tool (MasterAid) through the programming port on the CPU, may be affected by the EXCOM communication handler. In a system with a high processor utilization, the programming tool may loose contact with the target system when the additional load of the EXCOM communication handler impacts the system.

On an idle system, a fully utilized EXCOM communication link running at the highest speed (19,200 bit/s) only incurs at most 1-3% processor utilization (processor specific).

Performance calculation

This calculation is based on ideal conditions, with a fully utilized communication link where the EXCOM communication handler is capable of delivering data in the same speed as the communication link can transfer it.

Message size

The ABB EXCOM protocol allows a maximum message size of 326 bytes.

Overhead

Each message consist of an address part and a data part. There are also a couple of bytes used to delimit one message from another. If a checksum is generated, 3 more bytes are needed. The optional checksum, delimiter characters plus the address part is an overhead which can only be minimized by trying to maximize the length of the message sent by the EXCOM communication handler. The size of the overhead for each message is 14 bytes.

Value size

Depending on which logical file that values are extracted from, each reported value have the following size requirements:

DI and DO 5 bytes max 62 values / message

AI and AO 18 bytes max 17 values / message

DAT 2-13 bytes max 24 values / message

Calculation

A communication link configured with 19,200 bit/s, 1 start bit, 8 bits / character, 1 stop bit, and no parity, is capable of transmitting 19,200 / (1+8+1) = 1920 bytes/s. Assuming that all messages being sent by the EXCOM communication handler are filled with as many objects/values as it can hold, and that a checksum is generated, the following performance can be expected under ideal circumstances:

Using only DI or DO objects, 62*(1920 / 5*62+14) = 367 objects/s

Using only AI or AO objects, 17*(1920 / 18*17+14) = 102 objects/s

Using only DAT objects, 24*(1920 / 13*24+14) = 141 values/s

Depending on the mix of objects, the number of objects/values reported may vary between 102 and 367 objects or values updated/s. In reality, the performance will rarely approach the ideal. In most cases, the number of objects/values updated/s is anywhere between 50 and 100. In highly utilized systems, the update rate may be very poor, dropping below 10 objects or values updated/s.

Tests show that a system with an average CPU utilization of 92% can deliver approximately 30 DAT values/s.

Writing

On most systems writing data down to the DCS occurs so rarely that there is no effect on performance. The only setups where writing occurs continuously are where you need to perform continuos control e.g. a PID loop in the SCADA driving an output in the DCS. Another more common requirement may be to write a value coming from another IO driver e.g. a PLC to the DCS. In all cases AVOID continuously writing the same value, only write changes of state. This normally dramatically reduces the writing overhead.

if you chain an AO/DO block to an AI/DI, setup the AI/DI to be exception based
write a program block that compares the value to be written with input feedback from the IO then writes if the two differ by a specified deadband.

Read performance will inevitably suffer when sending updates to the EXCOM device. The ASE driver only writes data when the operator changes something. This means that when sending new values to the EXCOM device, the read performance will drop to approximately 50% of what you get when not sending any values to the EXCOM device.

EXCOM Specific optimizations

DI's use 5 bytes to indicate the value of 1 BIT. A more efficient solution is to copy all DI's to 32 bit DAT blocks & poll these instead of the DI's (9 bytes for 32 BITS)
Do the same for analogs
Try to keep all you IO in contiguous blocks (reduce number of pollrecords)
Put analogs on minimum poll time client will accept e.g. 5 sec.
The DSCA 114 has several comm. ports - use multiple comm. ports to same DCS

See Tips on Optimizing Most Drivers