HBO uses Harris ADC-100 automation across its operations. Photo courtesy of Nils Walter Studio.
In an age where computers are embedded in everything from cell phones to PDAs, to the dashboard of your car, the concept of computer control over the playout of TV or radio programming seems entirely logical. To an entire generation, it must be hard to imagine a time when computers did not have such ubiquitous control over disparate aspects of our lives. Though I was not born in that generation, I guess I had something to do with their genesis, as my youngest daughter has followed my path into broadcasting. Still, I can see how the concepts of workflow automation in broadcasting may appear a bit obtuse, even to the latest generation in our industry.
The concept of workflow is the key to understanding how automation can and often does affect playout of programming. In the simplest terms, automation systems replicate the actions humans would do without their assistance. They collate the information needed to assemble a daily log, review its contents to be sure everything is present, go looking for missing tapes or programs, flag numbers that don't look right, make dub lists, and organize the purging of old content that is no longer needed. Automation rolls VTRs and servers, takes crosspoints on switchers, watches the clock and puts in the ID on the hour, keeps meticulous notes about what has happened, and puts the log in the out basket at the end of the shift. It does not figure out where bathroom breaks are but, short of that, an automation system is the computerized workflow equivalent of a human's actions.
It is entirely logical that it should be this way. There are many possible reasons for automation. It can be used to reduce errors or to allow more complex facilities to be controlled by fewer people (although not by zero people — yet). Or broadcasters might implement automation to assure the closed loop of communications between traffic, air operations and back to traffic, as well as deal with a host of housekeeping details. A good automation system provides such thorough workflow automation that a human can intuitively understand the process the automation system is using to find, cue, roll and log segments and interstitials. It doesn't exactly take a genius to recognize the obvious. Any good software that replaces repetitive tasks by human workers must in fact replicate at least the effect of the workflow that humans use naturally in the workplace. The first steps might be to define the task and gather the information needed to accomplish the task. Then the system might organize the work logically, perform the task by acting on outside devices and report the results for accounting and billing. I think a college professor might have told me something like that if I had really been listening in my Fortran class.
So, broadcast automation at the core is a pretty understandable process of duplication of human action. What is different about automation today is that the amount of information that must be presented to an operator is nothing less than staggering. As a result, the software now must do more than just the simple tasks of importing a traffic log, finding the media, keeping track of the media, cueing and playing, and reporting. It must also create a user interface that allows an operator to see and intuitively understand what is happening on perhaps a dozen channels at once. That is the first nontrivial exercise the code writer must face after he is taught what master control is all about. Think of the myriad of details an operator must be trained to take care of, and extrapolate that to the task of programmers of a modern system. They must know the workflow in a broadcast station and what can go wrong and how to get out of a jam. In short, they need to know the workflow of a software development company and the workflow of their clients.
Today, playout automation increasingly interacts with other computers as sources of content, including scheduling, PSIP generators, DTV muxes and control systems, as well as switchers and other devices with rich control sets. Take, for instance, the automation of a “branding engine,” a new term often mistaken for new-era master control switchers. Branding engines have crosspoints that require take commands, but they also contain rich display sets for background graphics, overlay pages, and audio and video clip files for logos and other content. Automation must gather the data from traffic, parse it correctly to figure out what commands are necessary to load and run the right elements, and then parse it again into the language of the interface to the branding engine. As these elements get more complex, the lingua franca is not static but, instead, becomes a family of languages needed to talk to similar devices from disparate manufacturers.
Out of this arises a need to have a rich language that can be used to define an API that all character generators, for instance, would understand from the outside. Indeed, a language is needed that all automation systems might use as the basis of simplifying the job of the many code writers from many companies involved. A consortium of manufacturers, including Pinnacle and others, is exploring MOS as the structure for standardizing the API. MOS is XML-based and well-defined. As such, the code can be human-readable, at least on one side of the interface, though the driver inside the controlled device is still a bit of a mystery. At least they theoretically need to write only one MOS driver to talk to a large number of automation systems.
As systems continue to grow more complex, it seems inevitable that items like archive, media asset management and WAN architectures will become a standard part of broadcast systems. The development of standard interfaces between automation and other devices will make it much easier to interface software modules for these systems into one holistic facility automation system. This holds the promise of reducing the complexity of large implementations and facilitating much more complex small installations in the future. Today, the cost of many software packages integrated together explodes when you take integration management and labor into account.
It is worth noting that we may be seeing movement away from RS-422 as the de facto interface between automation and controlled devices. IP communication has become so simple and cheap that it is practical to implement as a standard control on many devices. Certainly, it is simpler for a computer to spit out all the commands on one port via Ethernet. The ability to extend IP communications over WAN circuits is appealing for distributed environments like centralized broadcast operations. Servers, branding, character generators, clip players and, indeed, nearly all devices have embedded processors that facilitate communication via TCP/IP.
Finally, the ability to write complex graphical user interfaces using standardized tools is a tremendous boon to automation companies. For instance, it can allow users to customize the display for individual tastes, or spread the interface across two monitors, using tools that come with graphics cards and software embedded in operating systems. Viva simplicity! It gives us all more time to concentrate on the core issue of workflow.
John Luff is senior vice president of business development at AZCAR.
Send questions and comments to:john_luff@primediabusiness.com
