4. Configuration
87
Overflow Signalling
The overflow signalling of the CPU queue occurs in two situations:
If the CPU queue is partially occupied and the available space isn't enough to store the new
events generated in the execution cycle
If the CPU has stoped the generation of events (because were detected more events in a single
execution cycle than the total size of the CPU queue)
As well as in the CPU queue, the signalling of overflow for the consumer queue occurs in two
situations:
When the consumer queue is partially occupied and there is not enough space to store new events
If the CPU has stoped the generation of events (because were detected more events in a single
execution cycle than the total size of the CPU queue)
Consumers
Consumers are typically communication drivers that will communicate with a SCADA or HMI. After
being stored in the CPU queue, consumers receive events related to communication points mapped in
its configuration. These events are then stored in an event queue of the client, whose size and
operation is described in the driver-specific section.
Queue Operation Principles
Once stored in the CPU queue, each event is transmitted to the consumer that owns this
communication point in its database. In the above figure, Event 0 refers to a communication point
mapped to two DNP3 control centers (Client 1 and 2). Event 1 refers to a communication point
mapped only for one DNP3 control center (Client 2). Event 2 refers to a communication point
mapped to a 61850control center.
The events remain stored in the CPU queue until all consumers confirm receipt. The criterion used to
confirm receipt is specific to each consumer. In the specific case of the DNP3 Server, confirmation
occurs only when the control center (SCADA) acknowledges the receipt of the message (which is
useful against events losses in case of network failures). As for other types of consumers (Buffered
Reports in 61850Server, for example), confirmation occurs when the event was transferred to the
internal queue of the driver. The occupation of the CPU event queue can be monitored through the
diagnostics available in the CPU diagnostics area by DG_HX3040.tDetailed.Events. * variable,
which also provides information on the queue overflow, among others.
Producers
Producers are typically communication drivers or internal elements of the RTU that are capable of
generate events. The figure above shows some examples:
DNP3 Client Driver: The events are generated and stored in Outstations, and then are read by the
driver and entered in the CPU queue.
HX1110 and HX1120: The events are internally generated and stored in the module, and then are
read by the RTU local bus and inserted in the CPU queue.
61850 GOOSE Subscriber: The events are generated when the CPU gets a GOOSE message (as
long as the received data cause some change in the variable value), and then are inserted in the
CPU queue.
Internal Points: This is an internal element in the RTU firmware, which detects events at each
execution cycle (MainTask) for those communication points that do not have a defined origin,
and then insert them in the CPU queue. The maximum number of events that can be detected at
each cycle of the MainTask is the same as the size of the CPU events queue. If the it is generated
a number f events greater than this noe in a same MainTask cycle, the surpassing events are lost.
MODBUS Driver (Client/Server/Master/Slave): The CPU detects changes in the value of the
variables at each cycle of the MainTask when they are caused by MODBUS readings/writings.
