RP5 Performance issues

Support | Order Placement | ProScada Home Page | Download Demos

RP5 Driver performance

RP 570 Protocol commands Supported By the FIX RP5 Driver

Initialisation

SCI & RTU responds with EXR

Polling (SCADA -> RTU)

DI's (RTU->SCADA)

IDS

IDM

ERMI (logged to Relational DB)

AI's (RTU->SCADA) (Max 256 objects)

The Analog inputs are 12 bits ranging +/- 2047, scaleable to any engineering units

AVS

AVM

DO's & AO's & Controls (SCADA -> RTU)

SPM (16 bits) (Max 256 objects)

GOM (1,8 or 16 bits), for 1 bit use GOMS in RTU for 8 use GOM8, 16 available for Virtual IO (Max 256 objects)

IXC (Pulse start Pulse stop commands drives 2 outputs) (Max 2048 objects)

Time Synchronisation (SCADA -> RTU)

TSI

RTU Status Bits (RTU->SCADA)

TSTA

Pulse counter messages(RTU->SCADA)

The pulse counters contain the analog value (Current Count of the Counter) & the 8 Status bits of the counter

PCM

PCT

Commands not supported

All messages not mentioned here, most of these are RTU configuration messages like FTAB & FCOM

Polling performance of RP5 driver

I am making the following predictions based on a system running with a baud rate of 9600 baud & a RTU response time of < 30 milliseconds. If the RTU comms is Program scan cycle dependent this could result in slower response times

This protocol is completely event driven, this means that the SCADA interrogates each RTU in turn for change of state data. Typically we have seen interrogation rates of 20+ interrogations per second (RTU responding with no change of state). Obviously when the RTU’s have data to report this will slow down a little.

Example

If you have 10 RTU’s each RTU will be interrogated every 0.5 seconds. If the system is reporting several Change of state events, this may be reduced to 0.5 to 1.0 seconds. The response times are relatively independent of IO count size.

Optimisations

1/ It is assumed that the RTU’s are properly set-up so that jittery Digital & analogue inputs are not reporting continuously.

2/ Increased baud rates

3/ RTU response time

4/ Splitting RTU’s onto more serial ports

Update time performance from driver memory image to operator Screen

Inside the FIX System there are two Levels of update time,

Process database scantime

Picture update time

Process Database Scantime

Every AI & DI point in the database can have a Scantime (default 1sec) or can be exception based

If set to exception based the database scantime delay is negligible.

The RP5 driver allows all points to be exception based.

Picture update time

Each mimic file has an individual "Refresh rate", the default is 0.1 Sec

Disadvantages of high Picture refresh rate

If there are many IO points on the picture (< 30 is considered small) the VIEW application starts taking the lions share of the CPU time. Generally increasing Refresh period to 0.2 sec solves this

This is also the rate at which data is requested by VIEW nodes across the network. If you have many VIEW nodes OR your network bandwidth is limited The FIX networking may overload the WAN e.g. if you are connecting remote sites with narrow band WAN links (NS Carrier is implementing a narrow band WAN). Here we recommend increasing Refresh period to 0.5 or more sec.