In critical broadcast workflows it’s common to have redundant processing to guard against equipment failures. Using Shadow Devices, Helm provides the ability to control redundant devices in parallel with the main signal path. Here’s how we set this up.
An example of Shadow Devices
On the Helm panel we have configured two identical routers MAIN and BACKUP. These drive separate physical routers. To show router operation we’ve also added Router Buss controls pointing to each router.
Adding a Shadow device
We set the MAIN router’s Shadow Device property to BACKUP. As of Helm version 4.4.1 you can select the shadow device from a drop-down list of devices on the panel.
Shadow devices in action
So here we are controlling two Black Magic routers in parallel. (In fact we are emulating the routers using RouteMaster, Rascular Technology’s highly flexible router control software). All commands sent to the MAIN router also go to the BACKUP thanks to Shadow Device. The Shadow Device feature is not just limited to routers. You can also set up shadows for Branding Devices, Servers, Multiviewers and Modular Devices.
Note: there can be more to keeping redundant devices in the same state than simply sending the same commands to both. Depending on the application it may be necessary to poll both devices and resolve any differences. Just something to think about when designing your control system.
Shadow Devices are also useful when running multiple broadcast chains which need to be controlled in parallel – e.g SD and HD simulcast.
When are commands sent to Shadow Devices?
Commands are sent to Shadow Devices in the following cases:
- When a script sets a property on a the primary device, the same property is modified on the shadow device.
- When a script asks the primary device to execute a function, the same function is executed on the shadow device.
- When a visual component (e.g. a button) controls the primary device via a property link, then the shadow device is also affected.
Special Notes for Shadow Devices
- When reading status or properties of the primary device, the shadow device is not accessed.
- Setting properties or executing scripts on the shadow device does not affect the primary device.
- Modifying the controlled IP address of the primary device via the “SetIPAddress” function does not affect the IP address that the shadow device is controlling.
- Controls are shadowed at the ‘Helm’ level, rather than the device level. This means you could – for example – have an Evertz router as a shadow of a Probel router, or have two Probel routers (SD and HD?) with different input and output group assignments, but still be able to make the same ‘logical’ routes on both routers.