In a perfect world, traffic, playback automation and digital delivery (content delivery and program management) systems would talk to each other seamlessly. Any time Traffic logged a new spot, it would access the Master Control Room’s playback automation system to select, schedule and play the commercial as required. Whenever playback occurred, a message from MCR’s automation system would be sent back to Traffic’s database without any human intervention whatsoever. Meanwhile, whenever new content came in digitally, Traffic would know what it was, where it was stored, and be able to access it quickly. All told, the perfect world TV station would run like a tightly integrated, fully automated machine.
However, we live in the real world; one where different IT systems typically don’t play nicely together. Add the fact that broadcasters are moving towards centralcasting—many channels being controlled by a centralized MCR with minimal staff—and the need for TV operations systems to talk to each other has never been more pressing.
“Unfortunately, current traffic and automation system technology just hasn’t kept up with the ways broadcasters need to work today,” says Chris Lennon; chairman of the SMPTE S22-10 Data Exchange Working Group and program manager for Harris’ Broadcast Communications Division’s Software Systems business unit. “When you factor in detecting and forwarding metadata from digital video to the HDTV transmission chain, clearly something has to be done to make these systems start talking to each other.”
SMPTE To The Rescue
In order to resolve this issue, the SMPTE S22 Committee on Television Systems Technology created the S22-10 Data Exchange Working Group in 2004. Its mission: To devise a standard that manufacturers could follow to allow traffic, automation, programming management and content delivery systems to all talk to each other.
Prior to S22-10, individual manufacturers, such as VCI, were already working on the problem so that its traffic system could talk more freely with automation. What S22-10 did was get all the major players talking to each other, which is what their customers want.
“The goal of the S22-10 standard encompasses two important concepts: (1) the ability to make last minute changes of content (commercial or programming) and (2) the ability to have a single industry standard that governs the transactions required to make (1) possible,” says Peter Storer; S22-10 member and president of Peter Storer & Associates. “Program Management is a major element of the S22-10 focus since much of what is involved ultimately ties back to rights management of content,” he adds; “either from the commercial traffic point of view or from the program management point of view.”
Functionally, a proposed S22-10 standard is akin to a “docking adapter”; the kind that allowed the U.S. Apollo and Russian Soyuz spaceships to link up in the 1970s, even though their technologies were incompatible. “A docking adapter is an easy way of defining what we’re trying to create,” says Melanie Duval; S22-10 co-facilitator and automation specialist with traffic management systems manufacturer VCI. “We want to make it possible for a traffic system to seamlessly send information into an automation system, and vice versa.”
The first step in making operations software systems interoperable is to understand how they might communicate with each other. To do this, “we gathered together all the major players in America, sat down in a room and basically shared information from our databases,” says Rick Stora; S22-10 member and Sundance Digital’s director of broadcast operations. From this sharing between 30 companies and 99 participants, a concept for a SMPTE standard was born: To create a realtime messaging system that could ferry information between disparate software systems, so that they could all talk to each other.
Of course, such “conversations” required the systems to understand each other: Given that these are different proprietary programs made by different companies for different purposes, some sort of translation had to be compiled first. As a result, the members of the S22-10 Working Group have spent a lot of time compiling a Data Dictionary. “Although many of our systems do the same basic things, we often use different terms to tell the other systems what to do,” says Lennon. “Creating a common set of terms and concepts, which form the basis of the Data Dictionary, was a necessary first step.”
The next step was to decide which technology the Data Exchange software should employ. “Currently, ASCII files are used,” says Duval. “However, for the SMPTE S22-10 standard, we opted to use XML instead.” Short for Extensible Markup Language, “XML was one of the easiest decisions the Working Group came to,” says Lennon. “XML is the most flexible, commonly known and easily supportable means by which we could get disparate systems to talk to each other.”
With a common set of terms and the technology selected, the S22-10 Working Group and its member vendors got down to writing code. The result: By the time NAB 2005 rolled around, several vendors showed initial products that displayed the kind of communication S22-10 is working towards.
For instance, Sundance Digital’s FastBreak NXT and Titan automation systems were able to talk to Myers Information Systems’ ProTrack traffic software for PBS, and VCI’s STARS II+ traffic management system for commercial broadcast and cable. “Interactivity between automation and traffic is finally a reality,” said Sundance Digital president Robert C. Johnson in a company news release. “This new messaging system provides the missing link to drive workflow to an unparalleled level of effectiveness in all television stations.”
Meanwhile, Harris demonstrated live integration between its BMS and Paradigm traffic systems and their ADC automation system using Harris’ Live Update data exchange product. “Live Update enables live day-of-air changes made to the log within the BMS or Paradigm traffic systems to be automatically reflected on the ADC automation system,” says Lennon. “Live Update also includes a back channel to provide feedback from automation to traffic of changes made in the automation playlist. In addition, feedback on the success or failure of updates received from traffic is included.”
Possibilities
With traffic and automation systems finally able to communicate, today’s TV stations will be many, many steps closer to the perfect world described at the top of this article.
A case in point: In a fully-integrated station entirely based on digital video ingest, storage and playback, many of the functions currently handled by Master Control would migrate into Traffic’s turf.
For instance, when a commercial is sold and scheduled, Traffic will be able to tell the automation system when the spot is being digitally delivered by a service such as Pathfire; where the spot will be stored; when and how often to play it—with playback confirmations being logged on Traffic’s database—and finally when it can be billed and erased. “This methodology will turn the traffic log into the actual playlist,” says Stora. “It will break down the barrier that has so far kept Traffic and Master Control separate; freeing up MCR staff to manage a number of stations, rather than just one.”
This is just the beginning. A fully integrated station’s salespeople would be able to critically analyze each day’s playlist, to see where new opportunities might be found. “Sure, it would be a nice value-added feature if we could tell the Democrats every time we play their spots right after we play them,” Stora says. “But imagine if the station would also tell the Republicans: This might motivate them to buy slots right after the Democrats’ ads; at a few minutes’ notice!” The same logic could be used to sell extra spots to car dealers, soft drink sellers and fast-food chains.
The new standard will also improve matters for content delivery and program management, says Duval. “For content delivery, this standard will enable all systems to have the exact [same] metadata [associated with] a piece of content... without rekeying any information,” she says.
“Sharing metadata with these management systems well in advance of air will provide additional opportunities within the traffic and scheduling processes,” adds Jamie Meyer, Pathfire’s product manager for station products. “Providing this detailed information eliminates the costly steps of manually harvesting the metadata locally. Add to this that the process is duplicated across all facilities, and the expense becomes obvious.”
Current Status
At press time, the S22-10 Working Group was making the final tweaks to its Data Dictionary, and “beginning schema work,” says Lennon. “Once that’s complete, we will present it to SMPTE for validation and approval.”
“How long it will take them to work through the standard validation process is anyone’s guess,” Stora says.
One thing is certain: The advent of communication between traffic, automation, programming management and content delivery systems will bring television broadcasting from the 1950s into the 21st century, where it belongs. With true integration, broadcasters will be able to program, manage and sell airtime on a range of centrally-controlled channels, without substantially increasing MCR manpower.
Moreover, the day will come when “interface-wise, it will become unimportant which traffic and automation systems a broadcaster uses, because they will all be able to talk using a common language,” says Chris Lennon. “This will allow broadcasters to focus on their core business, and vendors as well. We can get back to competing on value-added features and product benefits, rather than having to waste time writing hundreds of application-specific interfaces.”
James Careless covers the television industry. He can be reached at jamesc@tjtdesign.com.
