Article written by Steve Bilow, Senior Product Manager, Infrastructure SW Platforms 

Average reading time: 5-6 minutes

Self-healing!

Another, perhaps even more compelling application for the same Kaleido IP and AMPP behaviors concerns disaster recovery and redundancy.

Consider an example of self-healing redundancy. Suppose we once again have a Kaleido IP displayed on a control room wall. This is our main IP monitoring output.

We can observe and receive alarms from the Kaleido IP and, from that we can drive highly configurable actions. Because AMPP integration is being added to GV Orbit, new possibilities for disaster recovery arise. For example, it is now possible to provide an AMPP-based backup for the Kaleido IP, should it malfunction. Rather than adding a backup Kaleido IP in a different location, it is possible to add an AMPP server and to use a multiviewer that runs in AMPP as a disaster recovery solution. Instead of the capital expense of a second multiviewers that sits idle when unneeded, the AMPP-based multiviewer costs you nothing while it is idle and is only an operational expense in the rare case that it is required. That creates a very cost-effective redundancy strategy. Here we have a Kaleido IP output directed to an AMPP Flow Monitor.

We can use MapView behaviors and bindings to detect a failure and, when one occurs, to reroute the sources to an AMPP multiviewer and that multiviewer output to the flow monitor.

In a matter of seconds, the AMPP workload can be “spun up” by GV Orbit, the routes can be made, and you will be up and running again. The true power here is more than substituting an AMPP server for a Kaleido IP. The real power comes from having that one AMPP server work as a disaster recovery solution for any hardware products that have a corresponding App in AMPP. So, a single (or a few) COTS computer servers can take on the role of redundancy for MANY other devices. This costs you nothing (except for the AMPP server(s)) while the AMPP node is sitting idle. You only pay-as-you-go for the AMPP App IF you need it. That is a game-changer when it comes to cost-effectiveness!

Of course, you won’t understand how this works until you remember that GV Orbit MapView includes a large selection of behaviors and bindings, some of which are related to Kaleido list values and AMPP interfaces.

Some additional constructs connect one type of action to another. We can use some logic and some event bindings to take an action when, for example, a certain value gets to a certain level.

Let’s say that the Kaleido IP is in error. We can be alerted and can take several actions. Say we have a True or False value indicating whether the Kaleido IP is in error, or not. If this “Kaleido IP in error” equals “TRUE” then we want to route nothing into that destination. If it's “FALSE” we want to route to it normally.

Here we see that a Boolean value called “Kaleido IP is in Error” is used in MapView to determine the properties of a video display. If the value is “false” then everyone is happy.

But, what happens if we completely lose power to the Kaleido IP? We've lost the H264 output from the Kaleido IP and our monitor wall has gone blank. Now a failure will be detected. Upon detection of the error we initiate an action that starts a backup AMPP multiviewer workload and then routes whatever had been routed to the physical Kaleido IP into the corresponding AMPP inputs that feed that workload.  The logic behind this is a bit more complex. But the concepts remain the same. One thing you will notice when you look at the diagram below is that the “bindings that allow the AMPP-related behaviors to function are written using JSON. In other words, we use a common underlying syntax and semantics; something that many software people already understand.

So, what’s the result? Your physical multiviewer has failed but you are ready-to-go with an available AMPP node. You are not running the AMPP Kaleido workload, or paying for it, when not using it. But upon detecting an error, GV Orbit will command it to start.  The AMPP workload starts, GV Orbit routes the signals into it, and then GV Orbit directs the output of the AMPP multiviewer to display on a flow monitor so that we can continue working within a few seconds.

Here again is our MapView screen, this time with the sources routed to the AMPP multiviewer and its output routed to the flow monitor.

The principle is simple. A facility can set up AMPP-based disaster recovery mechanisms like this to back up any key component of the facility with a corresponding AMPP application. When the physical device is restored, GV Orbit MapView behaviors will reverse everything, shut down the AMPP multiviewers (or whatever other devices you temporarily replace), and reestablish the original configuration.

This is a practical application of combining AMPP and GV Orbit to achieve a cost-effective disaster recovery strategy that requires minimal additional onsite hardware and that can only be accomplished by leveraging the power of AMPP and GV Orbit in a synergistic combination.

These are just 2 examples. There are thousands more. If you would like to explore the infinite possibilities, contact your local Grass Valley account manager or sales engineer. We look forward to showing you the many exciting possibilities that come from integrating GV Orbit and AMPP to implement workflows and strategies that would otherwise be impossible!

Read Part 1