You are here: Home Page » /aps » /aps/infrastructure » Workflow integration

Workflow integration

May 1, 2005 12:00 PM, By Brad Gilmer

Recently, I was part of a team that launched a new, nationwide cable satellite music channel. Because we started from scratch, we looked at a number of different options for our facility.

In the end, we outsourced the origination and uplink of the channel. However, all management, programming, traffic, commercial sales and promotion are handled in-house. Because the channel is music video oriented, we decided to use a radio music scheduling system for programming the music elements, but a conventional traffic system to schedule half-hour and hour programming. Just to make things a little more complicated, we selected a hosted traffic system. The actual traffic computer is located at the traffic vendor's location, and we connect to it via the Internet. Figure 1 shows a simplified drawing of the configuration.

Figure 1. Simplified diagram of traffic system. Click here to see an enlarged diagram.

This operation is different from many conventional television networks because of the music scheduling software. In radio, each piece of music in the library is classified into groups such as hot-hit, rock, oldie and so on. It is the responsibility of the program director to classify the music and to create clocks for different parts of the day. A clock describes what kind of events will be played in what order during any given 60-minute period. The program director creates several clocks for different times of day. For example, he or she may create clocks for morning drive, morning, day, evening drive, night and overnight. A clock might say, “Play an ID at the top of the hour, followed by a hot-hit, followed by a rock title, followed by another hot-hit, followed by an oldie, followed by a commercial break, etc.”

The key to radio automation is that the scheduler module automatically places songs on the log based on the song's classification, the clock in use at the time, and other parameters such as “do not play this particular song more than three times in a 24-hour period.” This saves a tremendous amount of manual work.

While the music scheduling software works well, it does not contain all of the tools available in a television traffic system. Our music video network plays music video blocks, but it also airs conventional half-hour and one-hour precompiled multisegment shows. A television traffic system is the perfect tool to use in this environment. The challenge we faced was to get the two systems to work together. We decided to have the two systems create separate logs, and then merge them together into one log to send to our origination and playout facility.

In the end, the TV traffic system company modified an existing merging application so it would take the two logs and produce a final log. We required some custom development and while a few minor bugs remain, the system works well. I wish I could say the same for interfacing the traffic system to the automation interface.

As I mentioned earlier, we do not have the physical computer for the traffic system at our facility. Instead, the system is located in a data center maintained by the vendor. The traffic system clients at our facility connect to the hosted traffic computer over the Internet. We established a Virtual Private Network (VPN) between the two facilities — actually, between individual client computers in our facility and a router at the hosting location. Once the VPN is connected, we run a Citrix client application on the desktop. This client connects to a Citrix server at the hosting location. (Citrix is an application that provides remote connectivity over the Internet.) When the connection is complete, traffic system users are presented with a virtual traffic system on their desktop.

As the traffic person works with the system, client session data is passed over the Internet between the host and the desktop. While overall the system has worked well, we have had unexplained interruptions in this virtual traffic system connection. We are still working to find the problem. It would be easy to blame the outages on the Internet, but this is a system with a number of components, so the problem may be at the hosting site, within the configuration of the Citrix environment, or in the desktop environment. Overall, the hosted solution has been satisfactory, but the interruptions have made work difficult at times.

By far, the most challenging part of this project has been the connection between the traffic system and the automation system. This should be a fairly straightforward interface. As you can see from Figure 2, we are exchanging playlists, dub lists and as-run logs between these two systems.

Figure 2. Typical interchange elements between traffic and automation. Click here to see an enlarged diagram.

This is a very common interface requirement — I have been working with systems exchanging these sorts of lists for many years, and I assume you probably have, too. In this particular case, one of the vendors was almost completely unresponsive. Because each vendor had its own proprietary interchange format, something had to give. One of the vendors was willing to work with us. It had an interface that had worked with the other vendor's equipment in the past, so we gave it a try. It failed completely.

None of the traffic elements made it to the automation system. Obviously something had changed. We contacted the nonresponsive vendor, and after several weeks, it provided us with marginal support. After trying four or five different interface configurations, we were finally able to get information to pass between the two systems. We were successful but only with the most basic log elements. We still needed to pass secondary events to control IDs and logos. As soon as we added these elements to the log, the conversion failed. Once again, we contacted the nonresponsive vendor, and after quite some time, we were able to get things working but not without trial and error.

Not to belabor the point, but it turns out that our problems were not over. When we started working with as-run log data, we wrote a conversion that worked for a while but then quit. One of the assumptions we made about the as-run conversion was invalid, but there was no documentation of any kind on the as-run log format, so we had no alternative but to guess until we got it right.

The good news is that there is a new group within SMPTE that is working to standardize data interchange. This group, called the Working Group on Data Exchange, has taken on the task of standardizing the various data exchange elements required in the broadcast environment. The group has more than 100 members and meets regularly. It has made a lot of headway in defining a data dictionary of interchange terms and XML schema for the exchange of things such as playlists, purge lists and as-run logs. The group is also developing a communications framework for interchange between different systems.

Good news on the horizon

The focus of the group is on programming systems, automation systems, traffic systems and content delivery systems, though many other systems will also benefit from this standardization effort. Speaking as the head of a group of users who have provided input to the group, we are extremely pleased with the progress so far. When can we buy it?

Brad Gilmer is President of Gilmer & Associates, Executive Director of the Video Services Forum and Executive Director of the AAF Association.

Send questions and comments to: brad_gilmer@primediabusiness.com