RDNodeSync
RDNodeSync
RDNodeSync block synchronizes its parent node (and its sub-node tree) state with other applications in the redundant application group. RDNodeSync needs also an RDSynchronizer block existing in the application.
On startup, RDNodeSync locates and connects the local RDSynchronizer component named in the SynchronizerNode property. The RDSynchronizer then acts as the manager for RDNodeSync by giving information about available applications in the redundancy group and setting the RDNodeSync into the correct syncing mode (either leader or follower).
Node Discovery for Synchronization
RDNodeSync discovers all the children (and their children, recursively) of the application or component where the RDNodeSync has been added to (either manually or auto-created at runtime). RDNodeSync then selects the nodes that need to be synced based on different filter properties like (Exclude, Include, ExcludeModels and ExcludeValues) and forms the list of nodes whose values will be kept synchronized (exposed in the SyncedNodes property).
Note: There is no need to configure anything (no need to set any routings, etc) at the CDP node side for the RDNodeSync to be able to sync their values. The only requirement is that the CDP value that needs to be synchronized has to be created as a CDPNode in C++ code and be listed by its parent CDPNode::FillNodeChldren(). Note that all existing configurable elements in CDP Resource tree and the values in them in CDP Studio can be synced as they match the abovementioned requirement.
The RDNodeSync discovers all the children (and their children) nodes of the application and component that have the same processing context - i.e. their owner component Priority and fs property value is the same. When a subcomponent with different Priority or fs property value is encountered then additional RDNodeSync is needed to be added at that level.
Note: RDNodeSync has a helper run-time configuration mechanism included - it auto-creates additional RDNodeSync (with identical configuration to itself) when it detects a subcomponent that has a different processing context.
RDNodeSync also stops discovering down from the child that already has pre-configured RDNodeSync. This feature can be used to synchronize different parts of the application using different RDNodeSync configurations (like different AllowedSyncModes).
For example, in the picture above there is an example application with 3 subcomponents. The Component1 will be synchronized by the top-level RDNodeSync because its processing context matches the top-level (application) processing context . On the other hand, the Component2 processing context is different than the parent so it can not be synced by the top-level RDNodeSync. Therefore it has its own RDNodeSync added, for synchronization. Finally, although the Component3 has the same processing context as the top-level RDNodeSync it will not be synchronized by it because it has its own RDNodeSync manually pre-configured.
Synchronization Modes
RDNodeSyncs listens for synchronization mode messages from its controlling RDSynchronizer. When RDSynchronizer detects the leader mode it orders RDNodeSyncs to start sending out value sync messages to all other applications in the redundant application group. Value sync messages will be sent out after each processing cycle, after all components, operators and all other blocks of that processing context have finished their Process() calls and all routed values are synced to their destinations.
At the same time, RDNodeSyncs in all other redundant applications will then be set to follower mode by their RDSynchronizers and they start waiting and applying the received value sync messages to their nodes. They will apply the values before the Process() cycle of the processing context start.
There are 3 different synchronization modes in value sync messages:
Diff sync and checksum sync both fall back to full sync mode in cases when the all values checksum comparison detects, that the current syncing mode was not able to keep the values in the leader and in the follower to be equal. The AllowedSyncModes property can be adjusted to allow or disallow switching to the diff sync and checkusm sync mode.
Value Flags Affecting Syncing
ExcludeValues property can be used to filter what value types will be synced. By default, read-only values, routed values, and changes in routing string (or routing list) values are excluded from syncing.
But, values can be excluded or included for synchronization explicitly, by setting CDP value node flag either in the model XML file or in C++ (library) code. The following flags can be set:
| Setting In XML model | Setting in C++ code | Description |
|---|---|---|
| IsNonSticky="1" | CDPNode::AddNodeModeFlags(CDP::StudioAPI::eValueIsNonSticky) | Indicates that node value can be set but it will be re-calculated in every processing cycle. This flag instructs RDNodeSync to always exclude the value from syncing (despite the ExcludeValues filter set). The flag is useful for values like action trigger values, operator output values that are listed by FillNodeChildren() and can not be made read-only but whose values have no meaning to be synced to other redundant applications. |
| IsState="1" | CDPNode::AddNodeModeFlags(CDP::StudioAPI::eValueIsState) | Indicates that the node value is not re-calculated in every cycle (or is calculated very occasionally). This flag instructs RDNodeSync to always include the value to syncing (despite the ExcludeValues filter set). The flag is useful to make state values or accumulated values (like integrals) to be always synchronized (even when they are set read-only). |
| IsInputDerived="1" | CDPNode::AddNodeModeFlags(CDP::StudioAPI::eValueIsInputDerived) | Indicates that the node is an output value in some parent node (e.g. in the operator) and it is calculated purely from the parent node input values (e.g. from operator input arguments) and the calculation is 100% repeatable i.e. the same value will always be calculated when the parent input values remain the same. This flag instructs RDNodeSync to exclude the value from the redundancy syncing when the value is residing in the cyclically calculated block. On the other hand, when the value is not re-calculated in every cycle (e.g. when it is located in the event-driven sequencer blocks) then the flag instructs RDNodeSync to always include the value to syncing. Note, that RDNodeSync uses CDPSchedulable::IsScheduled() method to query if the block is cyclically calculated or not. |
| IsIOServer="1" | CDPNode::AddNodeModeFlags(CDP::StudioAPI::eNodeIsIOServer) | Indicates that the node is a block that directly communicates with IO. This instructs redundancy that the block (including its children) should be excluded from synchronization. |
RDNodeSync Properties
| Name | Special flag | Description |
|---|---|---|
| SynchronizerNode | Local RDSynchronizer name to connect and use for synchronization management. Defaults to value "RDSynchronizer". | |
| AllowedSyncModes | Sync modes that RDNodeSync is allowed to switch to. By default diff sync is allowed but checksum sync is disabled. | |
| Exclude | Semicolon-separated list of child names (or relative paths) to exclude from sync. Prepend the name with a dot when the name needs to be matched beginning from the top level. By default CDP internal components (like CDP and CDP2Qt), and also properties that have no importance for redundant control system work like Alias, Description, HtmlPage and Unit values are excluded. | |
| Include | Semicolon-separated list of child names (or relative paths) to forcibly include to sync. Prepend the name with a dot when the name needs to be matched beginning from the top level. By default empty. | |
| ExcludeModels | Semicolon-separated list of child models (types) to exclude from sync. By default, CDPAlarms and all IOServer-based components are excluded. | |
| ExcludeValues | Flags that specify value types that will NOT be synced. By default, read-only values, routed values and changes in the routing string (or routing list) values are excluded from syncing. See Routed Value Synchronization Exclusion for more info. | |
| VerifyTimestamp | Set to true (checked) to instruct RDNodeSync to verify if timestamps received in synchronization messages from leader are in sync with the follower | |
| SyncStatus | Read-only | Shows runtime synchronization status. Empty (0) value means there are no issues with synchronization. See SyncStatusFlags for possible flags. |
| CurrentSyncMode | Read-only | Shows current sync mode (full sync, diff sync or checksum sync). |
| SyncedNodes | Read-only | At runtime, lists nodes that are currently included in the value synchronization. Node names that are suffixed with '(R)' are routed nodes whose values are actually currently skipped from synchronization (see Routed Value Synchronization Exclusion for more info). |
| SyncedNodesInError | Read-only | At runtime, lists nodes that caused the SyncStatus error status. When the SyncStatus is not empty, this list can be used to find out which nodes are causing the synchronization issues. |
SyncStatus Flags
SyncStatus property can have the following flags set:
| Flag indicator letter | Description | Modes Where Flag Can Appear | Description |
|---|---|---|---|
| C | Configuration fault | Leader and follower | Startup configuration fault was detected |
| O | No sync messages received from the leader | Follower | No synchronization packets have been received from the leader (yet) |
| N | Node list checksum mismatch | Follower | Node list is out of sync with the leader. When set, then the SyncedNodesInError property will then list the nodes that are out of sync. |
| V | Value checksum mismatch | Follower | Values out of sync with the leader. Can happen when diff sync or checksum sync is not able to keep the values in sync. Then RDNodeSync is automatically switched to l {FullSync} {full sync} mode. |
| v | Values can not be set | Follower | Values can not be set. When set, the SyncedNodesInError property will list the nodes that can not be set. Usually, this is because they have some value validators that prevent the values from changing. For these nodes, it should be decided if they need to be synced at all or if needed should improve the validator to allow setting values |
| M | Message decoding error | Follower | Error in decoding the synchronization message. Can indicate communication problems with the leader. |
| T | Message timestamp out of cycle | Follower | Timestamp received in redundancy messages from the leader are not in sync with the follower. This can indicate that the system clocks are not synced between the leader and the follower which can affect the failover quality. |
| L | Loss in value sync packets from the leader | Follower | Synchronization packets have not been received in time from the leader |
| F | Checksum-mismatch sync failed on the first cycle | Follower | Indicates that the checksum sync sync mode is not suitable for the component (and subcomponents) because the values selected for sync are changing differently on leader and follower. The checksum sync should be disabled using AllowedSyncModes property. |
CDPAlarm and Alarm Operator Aggregation
By default, RDNodeSync marks all CDP alarms and alarm operators to generate aggregatable events. This means that if the same alarm is triggered in multiple companion applications, then only one aggregated alarm row will be shown in the CDP Studio and the CDPEventList GUI widget.
For this aggregation to happen, the CDPAlarm ExtendedData property is modified by the RDNodeSync. The ExtendedData property is appended to contain the RDAppList key with a value that equals the companion application name list that have a similar alarm.
When for some reason this aggregation is not wanted and the alarms should be shown as separate entities then a ExtendedData should be set to have an RDAppList key with an empty value preset, like RDAppList=. The the RDNodeSync does not change the existing RDAppList key; as it is empty, the alarms will be shown as not aggregated.
Routed Value Synchronization Exclusion
The routed value exclusion that can be applied via the ExcludeValues property is somewhat special. When the exclude routed values filter is applied then the routed values will still be included in the synchronization list, but the actual value synchronization starts to depend on the routing status. When the value routing is connected then the value synchronization will be stopped immediately. When the routing is disconnected again (for whatever reason: it can be that the Routing property was cleared or the routing target got disconnected), then the value will be included in the synchronization immediately again. The current synchronization status can be inspected from the SyncStatus property - when the list entry for the node is suffixed with '(R)' then the node is routed, and its value is currently not actually synced.
Note: Note that the routed value exclusion applies only to the nodes that are inside of the scheduled processing context. The routed values inside of the event-driven processing context (like in the Sequencer blocks) are always included in the synchronization (because in the event-driven processing context routing propagation is not happening regularly).
See also RDSynchronizer.
Get started with CDP Studio today
Let us help you take your great ideas and turn them into the products your customer will love.