Guide For Creating Redundancy-Aware Blocks

In terms of redundancy, there are three types of values inside CDP blocks:

• Startup configuration parameters that are read-only at runtime. They need not be synchronized as they are configured to be the same in all redundant instances by the application clone and can not change during the runtime.
• Stateless internal variables. These are calculated from the input values over and over each cycle. They need no synchronization as they are calculated by all the redundant instances autonomously, assuming the blocks have equal input values.
• Stateful internal variables. They are either calculated using values from the previous cycles like there are integrals, averages, etc or they depend on very occasional and short changes in input values that change(toggle) the stateful value and that therefore can be missed by some Follower that is not up yet. These values usually need to be synchronized from Leader to Follower instances, to ensure that all the Follower instances are in the same state as they are in the Leader instance despite when they came online or what the Follower input values or input events have been so far.

CDP redundancy is created so that simpler CDP blocks can be created without any modification needed to be fully redundant. By default, all the writable values visible via CDP Studio inside the CDP blocks are automatically synchronized between the instances of redundant applications without any need for any additional measure in the block code or configuration.

However, for some complex custom-created blocks (like custom IOServers) there can be a need to manually adjust what values will be synchronized and what will not. The following sections describe how to adjust the default value synchronization behavior for the custom-created blocks.

Ensuring Value Will Be Synchronized

To ensure some block internal value change will be synchronized from Leader instance to Follower follow these rules:

• In the block C++ code, create the value using a class that is based on CDPNode (like CDPProperty). In other words, this means that simple C++ internal variables like int, double, bool, etc. can not be synchronized.
• Expose the value via StudioAPI in the CDPNode::FillNodeChildren() method in the block C++ code. In other words, make the value visible in CDP Studio during runtime.
• Ensure the value is not read-only or, when it must be read-only (to prevent user modification), it has to be flagged as a State. Flagging can be done by setting the IsState flag in the CDP model or by calling the CDPNode::AddNodeModeFlags(CDP::StudioAPI::eValueIsState) in the C++ code.
• Ensure the value is not flagged NonSticky. In other words, ensure there be no IsNonSticky flag set in the block CDP model and no CDPNode::AddNodeModeFlags(CDP::StudioAPI::eValueIsNonSticky) call in the C++ code.

Excluding Value From Synchronization

In many cases, blocks can contain some entirely internal values that do not need to be synchronized. It can even be that synchronization of these values does not cause any problems for the block redundancy, however, synchronization of these consumes network and CPU resources, so it is good to exclude these values from synchronization.

To ensure some block internal value will be excluded from Leader to Follower synchronization follow these rules:

• Create the internal value as simple C++ variable (like int, double, bool, etc.) in the block C++ code. These values can not be exposed to StudioAPI and therefore can not be synchronized.
• Make the value read-only
• If for some reason the value still has to be writable via StudioAPI, flag the value as NonSticky. Flagging can be done by setting the IsNonSticky flag in the block CDP model or by calling the CDPNode::AddNodeModeFlags(CDP::StudioAPI::eValueIsNonSticky) in the C++ code.