C300 Redundancy-related notifications
Become Primary command – BECMPRICMD
202 Experion C300 Controller User's Guide R301.1
Honeywell 11/06
Notification Description RDNSYNCSTATE
Note that partner compatibility checks across the
redundancy private-path are periodically attempted when in
the NOPARTNER sync state.
Redun Sync in
Progress
Both the primary and secondary controllers generate this
notification upon commencing initial-sync.
SYNCINPROG
Redun Sync
Maintenance
Both the primary and secondary controllers generate this
notification upon successfully completing initial-sync.
SYNCMAINT
Redun Standby Both the primary and secondary controllers generate this
notification upon entering the Standby sync state either via
the Enable Standby command or due to On Process
Migration.
STANDBY
Redundancy Link
Active
One time information notification sent whenever the
redundancy link transitions from link inactive to link active.
For example, this notification will be generated when the
redundancy link cable is connected.
Redundancy Link
Inactive
One time information notification sent whenever the
redundancy link transitions from link active to link inactive.
For example, this notification will be generated when the
redundancy link cable is disconnected.
Switchover Both the primary and secondary controllers generate this
notification following controller redundancy switchover.
Specifically, switchover breaks the previously existing
notification connection, a new notification connection is
reformed, event regeneration is commanded, and then the
controller generates this notification. This notification is
generated on subsequent commanded event regenerations
until initial-sync is attempted.
Sync Checksum
Fail
The primary and secondary controllers perform a continuous
background checksum on redundancy tracked memory to
explicitly verify that the primary and secondary are in sync.
Failure of this diagnostic indicates that the secondary has
encountered a condition whereby its local copy of
redundancy memory does not match the primary. This fault
is inserted either by {1} a software bug on secondary
controller firmware whereby redundancy tracked memory is
overwritten by code running on the secondary, or {2}
marginal hardware. Given that firmware releases are
formally tested with redundant controllers prior to
distribution, marginal hardware is the most likely culprit.
Moreover, the full redundancy communication path has to be
considered:
In C200 controllers:
Primary CPM Î Primary backplane Î Primary RM Î Fiber
To Next Page
Loading...
