6. HX3040 Redundancy
268
END_IF
Above there is an example of logic in ST language, where the redundancy switchover commands can
be executed through two variables from different communication ports.
Where:
var_StandBy_command_Ethernet_relation: Bool type variable assigned to an Ethernet
communication Coil that will execute the command to put the local CPU in Stand-By.
var_StandBy_command_Serial_relation: Bool type variable assigned to a Serial communication Coil
that will execute the command to put the local CPU in Stand-By.
DG_HX3040_01.tRedundancy.RedCmdLoc.bStandbyLocal: This command executes an action
similar to command “Switch to Stand-by” triggered by the display menu, in the local CPU.
Diagnostics, Commands and User Data Structure
Each CPU has several data structures related to redundancy. The following structures belong to the
DG_HX3040_01 symbolic variable, which is automatically allocated and is available to the user:
RedDgnLoc: Provides diagnostics from the local CPU related to the redundancy, as the CPU
redundancy state, for instance.
RedDgnRem: It is a copy from the other CPU RedDgnLoc, which was received through the
redundant synchronism channels. Thus, this local CPU can access the remote CPU’s diagnostics.
RedCmdLoc: Provides commands, which must be applied on the CPU with the “Local” suffix or
on the CPU with “Remote” suffix. E.g., the StandbyLocal field of this data structure corresponds
to a command, which must be executed in the local CPU, while the StandbyRemote field
corresponds to a command, which must be executed in the remote CPU.
RedCmdRem: It is a RedCmdLoc CPU’s copy, received through the redundant synchronism
channels. It is used only for visualization or information purposes.
RedUsrLoc: It contains 128 data bytes freely filled by the user (e.g. communication diagnostics
with a SCADA system). These 128 data bytes can be interchanged with the Remote CPU
RedUsrRem: It is a RedUsrLoc CPU’s copy, received through the synchronism channels.
RedUsrRem: it’s a copy from the other CPU RedUsrLoc, received through NETA/NETB;
The following sub-sections provide further details regarding the Redundancy Diagnostics Structure
(see Redundant RTUs Maintenance):
User Information Exchanged among CPUA and CPUB
Cyclic Synchronization Services through Redundancy Synchronism Channels
This section describes the three synchronization services, which occur cyclically in a redundant CPU
between CPUA and CPUB, through two internal synchronism channels. These channels are designed
to synchronize redundant variables, diagnostics, redundant user memory area, events queue, project
synchronization and commands.
These services are executed at the beginning of each MainTask cycle, in the following order:
Diagnostics Exchange and Commands (First)
Redundant Data Synchronization (Second)
These services are executed in both STOP and RUN mode. Variables, which are changed and forced
through monitoring in MasterTool, are synchronized between the CPUs, even when in STOP mode.
Diagnostics and Commands Exchange
This service is responsible by the interchange of the following data structures, in each MainTask
cycle:
