Master control automation

Despite the changing face of today's automation systems, there are two primary reasons why master control automation exists: to achieve a consistent on-air look and to save costs.


The complex master control operations of many broadcast channels, including cable and other services, may be approaching the point where a single human cannot consistently achieve the on-air look. Snipes, voice-overs, complex graphics attached to real-time push of data and screen geometry changes are only a small part of the complexity that makes manual automation difficult. As master control moves to multiple streams in most applications, DTV and other multi-program service providers, it will be a physical impossibility for an operator to push the buttons without automation assistance.

Saving costs

As complexity goes up, the need to add people is clear, but the revenue is not always there to justify the labor cost. In major markets, with the value of commercials high and the potential for loss of revenue an unacceptable risk, automation may be mandated to decrease liability mistakes. In such a case, the problem only moves upstream to the traffic department.

The traffic department has the most complex job. Not only does the department's log need to be accurate, but the log must also contain the commands needed to achieve all of the richness and complexity the station sells and delivers as its product.

When they're well done and thoughtfully implemented, automation systems have the potential to lower labor costs. Many stations find that although they may choose to have an operator present during prime revenue hours, they can operate in the wee hours of the night unattended. Others have found that automation allows largely unattended operation full-time. If implemented as part of a centralized operations strategy, the benefits may accrue more quickly.

Balancing this, of course, is the cost of the operators in master control. If the wages are low, the cost of automation hardware, software and support may add up to an insufficient total to justify reducing labor dramatically. This equation is sensitive to the needs of each station. There are no pat answers.

If the labor cost is stabilized by automation, but the revenue can grow, then the sweet spot has been reached. The station retains valued employees who deliver the product to customers, and the quality of the output can rise.


Over the last several decades, automation has become more effective, adaptable and comprehensive. Ties between automation and traffic have always been part of the process of automating, except in the case where logs were manually typed into the automation system, a practice not generally done today. But modern automation systems are tied closely to other software systems, such as asset management, archive management and playout servers. The degree of integration between these systems is approaching a point where it is hard to tell where one stops and another begins.

One major vendor is developing a platform strategy that holds the promise of tying programming, traffic, automation, asset management and archive management together on one common platform. In such a case, low-level calls between applications make it difficult to separate each component from the holistic effect that is promised.

There is, of course, a downside. Complex software systems are difficult to thoroughly model and inherently more difficult to troubleshoot. When things go wrong, they can go horribly wrong. But when things work out, the promise is elegant and highly desirable.

Other automation companies tightly integrate their products with traffic systems. One supplier has major investments from a number of broadcast group owners who hope to achieve the same level of integrated operation.

Times have changed. Stations are no longer interested in finding best-of-breed solutions and attempting to manage the implementation themselves. Increasingly, system integrators are tapped to take program responsibility, and contracts often require multiple vendors to deliver a holistic system in close association with each other.

A change in dynamics

Important dynamics are slowly changing the automation business. Software that was written only a decade ago for the dominant operating systems is now hardly supportable. Some systems have been recompiled for new operating systems so many times that it is hard to call a new release anything other than a maintenance patch. Operating systems and the underlying computer hardware are so far removed from those available a few years ago that a complete rewrite is often the only practical strategy.

In addition, where RS-422 was the dominant mode of communication between automation devices and software systems a few years ago, TCP/IP communication is rapidly becoming dominant. SMPTE is in the process of defining the interface between devices and controllers, an effort that has been on its plate in one form or another for more than two decades.

The devices being controlled have changed too. Master control switchers have become branding engines, absorbing multiple functions. MPEG splicing and compressed bit-stream processing are now practical ways to automate. One automation vendor is introducing a complete software and hardware solution this year. It includes clip playback, branding and automation in one box. Controlling this variety is now a difficult task for the software engineer and the system planner.

Closing comments

To the degree that software systems and computers supply complex and feature-rich results to program stream providers, broadcasters will have achieved a lofty goal. Let's hope the result is understandable by mere humans and supportable far into the future. If the complexity requires constant tweaking, we will have achieved the opposite of progress.

John Luff is the senior vice president of business development for AZCAR.

Send questions and comments