Broadcast control depends on interoperability

Some manifestation of control is extolled as a value-add feature by nearly every manufacturer and supplier in the broadcast industry. But control can mean a great many things to a great many people. It can, in fact, be interpreted as everything from the power switch to the management style of the CEO. More often than not, control is merely a box to be ticked on a request for proposal, and we think that’s a little disingenuous, perhaps even cheeky in the absence of a more definitive description of what actually is, or can be, controlled.

Automation Update: That’s the definitions, what does Rascular do in the field of control?

Roddy Pratt: We specialize in the on-air manual control of broadcast equipment, and here’s precisely what I mean by that. Operators need the ability to perform specific, often minute, adjustments to control virtually any piece of broadcast equipment to perform a specific task, and oftentimes the ability to make those adjustments just isn’t available. It’s a bit like having a full socket set, except for the one socket you actually need at any given time. Manufacturers provide some form of control for their own equipment, but it usually has its limitations (often to “protect” the user) and includes scant, if any, extensibility to other devices in the system.

The control capabilities we provide are product specific, and with interoperability being an ever-important factor in modern broadcast operations, the need for agnostic, and extensive, device control has never been greater. In short, we provide a system that controls disparate devices in a product-specific way, but is manufacturer agnostic. For example, our technology enables a user to control multiple routers made by a number of different manufacturers, yet, to the operator, they appear as a single device. This has a number of distinct advantages in terms of efficiency, monitoring and control.

Automation Update: What are typical requirements you get from broadcasters?

Roddy Pratt: The types of control we are most often asked to address fall into one of the following scenarios. The first is manual control to override/adjust system automation; next is emergency manual control in case of automation system failure; then manual control in live sections of a normally automated channel; and finally entirely manual operation of channels that have no automation system.

The level of control required may be simple like fading a station bug on or off, or more complex — to select and play a video clip on a server, route the server output to the presentation mixer and perform a fade or wipe to take the clip to air.

In contrast, manufacturers typically provide one or more of the following “control interfaces” to their equipment:

  • Front-panel control allows the operator to perform all control and configuration operations directly from the equipment front panel. The advantage of front-panel control is that it’s a cheap, reliable diagnostic tool. Unfortunately, it also means the operator has to visit the machine room often, which is wholly unsuited to on-air operations.
  • PC-based configuration and control systems that connect to remote equipment via serial or Ethernet has the obvious advantage of remote operation, but it’s still too complex for on-air applications.
  • Equipment-specific remote control panels, typically via RS-422 or Ethernet, are, at last, usable for simple on-air control, but take up considerable valuable space in the control room and are typically tied to a single piece of equipment.

Automation Update: And you see drawbacks to those interfaces?

Roddy Pratt: All of the aforementioned systems have two distinct limitations: They cannot be customized to the operator’s exact requirements, and they cannot integrate control of equipment from multiple manufacturers.

Of course, some manufacturers do provide configurable systems, but these are usually expensive, difficult to configure and manage and still only apply to a subset of the products that the manufacturer can provide.

Automation Update: How do you believe you have solved these issues?

Roddy Pratt: For our part, we’ve addressed the need for user-configurable, multivendor broadcast system control with Helm, which addresses the critical issues of integrating control of equipment from different manufacturers and allowing engineers to design the control interfaces that give the operators the exact functions that they need — and no more. We’re all aware of the “feature creep” that is virtually endemic in our industry, and while it’s perfectly normal that manufacturers refer to a control system of some kind in order to sell their products, their control systems are usually designed with their equipment, rather than the operator, in mind. This makes sense for them because every operator will typically want something different and it’s not possible to be all things to all people, even though some manufacturers may make that claim. In order to help sort out this problem, we entered the market with our own ideas about control.

It’s fair to say that “system control” best describes what we provide with Helm. That means that we are controlling devices, modules and multiple channels of disparate devices such as a logo inserter, mixer, router or multiviewer. Helm may not be thought of as the classic means of control for channels running under automation, but that suits us just fine. Helm can act in a monitoring role in that case — reflecting the status of the channel equipment, and bolstering the confidence of the operators.

Automation Update: Can you give some real examples?

Roddy Pratt: There are a couple of good examples of how Helm is being used, one of which is at UPC Hungary, which uses Helm for emergency bug insertion on 50 Miranda Imagestores — simply because there’s no room for conventional control panels in the gallery.

A-Medialynx in Berlin has replaced conventional master control switchers with Helm systems, using its existing router and branding hardware. This switch gave it the ability to view and control eight channels from a single screen with a high degree of system reliability and resilience.

Automation Update: Is the Helm system an enhancer or an enabler?

Roddy Pratt: I’d say it’s both. In some installations, Helm could be considered an enhancer — in principle doing nothing that couldn’t be achieved using conventional control panels; but, Helm in this application allows station engineers to produce a control solution that is more compact, operator-friendly and flexible.

In other [applications], Helm is definitely an enabler. An example would be ganged channel control, where an operator needs to perform actions simultaneously across several broadcast channels — maybe an SD and HD variant of the same feed. Manufacturers’ control systems typically don’t allow this kind of flexibility, yet this kind of capability is easy to achieve with Helm. And Helm can do this even when the equipment on the separate channels is from different manufacturers, running different protocols.

So, I would urge broadcast system operators to take a another long, hard look at their system to determine just how much control they actually have, and what’s more important, how much they would like to have, and press their suppliers to provide it. Failing that, we’ve solved most of those control problems already.

For more information, see