Lack of communication is a frequently mentioned issue when employees are evaluating their managers, and vice versa. In talking with a group of broadcasters who have been automating multiple channels, either in the same or far-flung markets, lack of communication between different pieces of equipment was a key issue too.
Machine-to-machine communication has been a problem for as long as I can remember. It used to be that the only way you were going to be sure different machines were going to be able to talk with one-another was to buy them all from the same manufacturer.
Buying all the equipment with the same nameplate on them gives you a certain advantage, even if all of the equipment doesn't communicate well when you first take it out of the box. At least you, the buyer, won't have to take an active role in the finger-pointing game.
Instead, you can just light a fire under the salesman who assured you the equipment communicated and say "hey, these are going to work together or they're going back."
All of the "it's his fault," "no, it's his fault" discussions then go on behind closed corporate doors. It's up to your salesman to facilitate a solution.
Supposedly, machine-to-machine communication problems have been reduced greatly by protocol standards, an agreement on a common set of instructions for writing operating software.
In theory, this means that when a machine from manufacturer A sends out a "record" instruction, a machine from manufacturer B actually starts recording.
That's in theory, at least.
"Standards don't really mean much, because everybody has their own iteration of them," said one automation expert. Others echoed his thoughts on this.
Most of those I spoke with said the automation supplier sent a software engineer out during installation to customize the code, closing communication gaps that existed. So if you see a hefty line-item for "services" in a quote for an automation package, the expectation of such code customization is probably built in.
LEGACY GAPS
In fairness to the automation folks, some of the blame lies in legacy equipment that was never designed with sophisticated automation control in mind. One broadcaster I spoke to wanted audio cart machines integrated into the operation. The only machine control instructions these dinosaurs were capable of taking was a general-purpose interface start pulse.
"I think the biggest thing we had to do was come out of the 1950s as far as technology," said another broadcaster. This means a leap across the chasm from analog to digital gear. "The learning curve that we had was really just bringing our own understanding up to current levels," he said.
This was not just on an operational level, but also for the maintenance crew. A broadcast video server requires a distinctly different skill set than what it took to lovingly nurse more life out of a reel-to-reel tape machine. Hopefully it also means a lot less maintenance in general.
One piece of advice I got from a systems integrator some time back may be well applied to putting together an automation package: "Don't fall in love with a particular piece of technology," he said. He might as well have said "don't make trouble for yourself."
Because certain manufacturers work better together, it stands to reason their individual pieces of equipment may work better together. So it makes sense to find broadcasters with successful automation installations that deliver the capabilities you require, and find out from them what equipment talks to what equipment best.
Also pay attention to what it's costing to integrate legacy equipment. It may well be that the cost of integration (along with continued maintenance headaches) is telling you to pitch that clunky old device for a modern piece of gear.
There's a movement on the automation horizon that may make intermachine communication a moot point. What if there were no separate machines to talk with one another? What if the whole automation package, control device, video server, switcher, audio control and the rest were all contained in a single server?
At least one automation maker, OmniBus, will be introducing such a device at NAB. The block drawing has the broadcaster's log input from its traffic system, audio and video inputs to allow spots and program material to be ingested, inputs so a station can do live newscasts, and outputs to the transmitter or transmitters (or cable or satellite head-ends).
There is still some machine-to-machine communication going on, since devices like TVRO satellite dishes have to be pointed at the appropriate sources, . However, but the fewer machines that have to talk with one another, the simpler the installation and operation.
This is not vaporware. I've seen a demonstration. Whether it's where broadcasters want to go is an only-time-will-tell matter. In general, it makes sense to me. It's still a communication business, whether it's people-to-people, people-to-machine or machine-to-machine.
CATEGORIES
LATEST ARTICLES