​​AMX Technical Support was recently asked to respond to a request from a dealer that wanted to offer redundancy to the audio video system in their client's installation.

For the purposes of this Tech Note the term “redundancy" is defined as an automated or programmatic change from one set of hardware to another, to postpone a service call until it is convenient for the dealer and the client.

The concept of redundancy is challenging and may not be practical, mostly based on the devices being controlled. However, the devices being controlled are not the only challenge. For example, let's say there is system that is requesting redundant power supplies for the master. A relay device could be introduced that would switch between power supplies. What could be added to the system provide a redundant back up to the relay device? For every device added to the system to provide redundant capabilities, there would require additional devices to back up the redundant devices which will complicate the installation. There must be a stopping point defined in the design and implementation of a redundant device system. The only scenario that comes to mind to offer redundancy is a complete and total duplication of the AV system.

Here are some thoughts to support the above statement. It is possible to offer redundancy for the master processor; this can be done via master-to-master as long as there is redundancy to the network infrastructure. It may be possible to have redundancy for devices communicating via IP. However it may not be practical to offer redundancy for devices that are communicating via a hard wired connection i.e. power, IR, Serial, IO, Relay, AxLink, ISCNet, ICSHub, HDMI, component, s-video, composite, speaker level, microphone level, etc.., as all of these would most likely require someone to physically change the cables from the device that is failing to the back-up device.

The question was raised to provide more information about offering a redundant processor system, specifically related to touch panel connection, as the paragraph above mentions the possibility of using master-to-master to accomplish redundancy. Is there a way to configure the panels to connect or transition to a backup master in the event the primary master fails?

The scenario describe below will presume that the masters and panels have power and network connectivity, otherwise it is moot.

The first piece of this puzzle is the connectivity of masters. Please refer to AMX Tech Note #919 for details on master-to-master.919-Comprehensive explanation of Netlinx Master-to-Master.pdf​ and 919-Master-to-Master unveiled.pdf​

The second piece of this puzzle involves the touch panel connectivity to the masters. As listed in the setup pages as “Master Connection" “Type" and “Mode". The “Type" must be set to “Ethernet". The “Mode" must be set to “Listen". This “Mode" tells the device, the panel in this instance, to “listen" for the master to initiate contact, and requires the master to have the IP or host name in its URL list. There should only be one master at a time that is configured with the panels URL.

The third piece of the puzzle is programming the masters to transition the panel(s) from the primary master to the backup master when the primary master fails. It is possible to manipulate the URL list on a master via the NetLinx code the panels can be programmatically added and removed to enable them to transition from a primary master to a back up master. Then transition the panels from the backup master to the primary master when the primary master is restored to operation. To accomplish this here are some minimum specifications.

PRIMARY Master

• The primary master must have the panels defined in code.
• The primary master must have a local structure to minimally contain the IP addresses of the panels.
• The primary master must have a virtual device defined locally, used to verify status of master and as a transport medium for messages between the primary and backup masters, such as variable state.
• When the virtual device reports online the NetLinx code must add the IP addresses of the panels to its URL list, if they aren't already there.
• The primary master must have the backup master defined in its URL list.

BACKUP Master

• The backup master must have the virtual device defined in the primary master in code, this is used to verify master status and as a transport medium for messages between the primary and backup masters, such as variable state.
• The backup master must have the panels defined in code.
• The backup master must have a local structure to minimally contain the IP addresses of the panels.
• When the virtual device reports offline the NetLinx code must add the IP addresses of the panels to its URL list, if they aren't already there. When the virtual device comes online the NetLinx code must remove the IP addresses of the panel's from its URL list, if they are there.

In the above specifications the backup master is only using the online state of the virtual device defined in the primary master as the trigger to determine if the primary master is operating or not. When using integrated masters it would be appropriate to use additional methods to confirm the primary master operating status such as serial ports, or minimally a link between the IO's and RELAY's on the unique masters.

The fourth piece of the puzzle is making sure the variable values are synchronized between the primary and backup masters so the panels can pick up where they left off prior to the transition. This can be as basic or complicated as programmer needs to make it since it is up to the programmer and the end user on where the panels should pick up after a transition. The more transparent the transition is, the more complicated the programming becomes.

In our simple test, 2 masters with 2 panels, we observed that it took an average of 42 seconds for the panels to transition from the primary master to the backup master, during this time the panels were unusable as they were not connected to either master. However, it only took an average of 15 seconds to transition from the backup master to the primary master.

The code we used during our test of this panel transition between masters is found listed on the webpage below. This is for reference, and is not intended to be the starting point for a redundant master system.

Even though the panels have the ability to transition between a primary to back up masters, if the master is not able to connect to the other devices in the system via the communication mediums listed above the master redundancy is useless.

Our recommendation for dealers who want to offer redundancy would be to provide the customer an opportunity to purchase a Service Level Agreement that would allow the dealer to stock replacement hardware and cover the costs of a site visit to replace the devices in the unfortunate event they fail, which should minimize system downtime.

See example in attachment 961-DL1-redundant master test.zip: 961-DL1-redundant master test.zip