Since my earliest days in broadcasting I have been involved with automation projects. My experience in automation has generally been that the driving force for acquiring the system was to reduce operational costs by reducing manpower. The addition of PC control and interfaces to the systems increased efficiency and flexibility. It became possible to blend traffic and MC automation into a cohesive unit so that a log created on a dedicated traffic platform could be transferred to a dedicated MC automation platform, and tasks such as pull lists and reconciliation could be accomplished with less manpower.
The early interfaces between traffic and MC automation were crude, generally relying on a computer disk print file being manually walked from traffic to the MCR and the automation-generated as-run being transferred back to traffic via the same sneakernet. As local area networking developed, it was added to the system and eliminated the need to manually transfer disks from one operational area to another.
AUTOMATING THE FUTURE
Now, as we move into the digital television world, we have to take a step back and consider what the goals and needs of our DTV stations are. At Iowa Public TV, we see a number of services in our future. Some are very similar to what we currently do, such as HDTV broadcasting, and others are fairly different, such as datacasting. Regardless of the type of service or services we are providing, we are still going to want to schedule, regulate and monitor those services to ensure that the content that was supposed to be transmitted was sent at the right time.
The current IPTV operation consists of eight analog transmitters located throughout Iowa. Those stations are fed programming from our control room in Johnston via dedicated DS-3 fiber. A single operator in the MCR controls the content sent to all of these transmitters and monitors the eight separate return feeds and transmitter remote controls. In the DTV world, which for the foreseeable future will operate in parallel with the analog world, IPTV will operate matching DTV transmitters which place the MCR operator in the position of controlling 16 transmitters, eight of which are DTV and may at any time be sending out multiple program streams and datacasts.
Also, we are in the process of acquiring a ninth station in the Davenport area with its associated DTV signal, so now we'll have 18 transmission systems. In addition to switching and monitoring basic content, the MCR operation will be changing modes of operations and managing fixed and opportunistic data feeds and any number of yet-to-be-developed services. To look at automating an operation of this scope in terms of simply expanding the existing control technologies would create an unwieldy system that could not be effectively managed or monitored by a single MCR operator.
VEGAS PLAN
In planning our attack strategy for NAB2003, I instructed our team to not lock their thought processes into our current MCR, but to try and visualize how we would structure our future operation to effectively monitor and control a diverse range of equipment and systems.
How do we deal with this rapidly approaching flood of complex systems? First, don't look for one system that will directly monitor and control all of the hardware at the station or stations. Having a single computer control the router, the switchers, VTRs, servers, CGs, stillstores, encoders, multiplexers and transmitters would require an enormous processing capability and complexity that would exceed the sum of the needs of all of the subsystems. Dedicated sub-processing systems are still an extremely effective way of managing multiple complex systems. In our application, what we are truly looking for is commonality and intelligence in the interface between these complex systems.
CROWDED COCKPIT
Some time back I compared the modern DTV MCR to the cockpit on a modern fly-by-wire jetliner. It's impossible to provide dedicated monitor and control functions for all systems because the sheer number of dials and switches would make it virtually impossible for a pilot to fly the aircraft during normal operations and would lead to certain disaster during an emergency.
Instead, the cockpit is set up under normal conditions to monitor a finite number of critical systems for nominal operation, and problems in those systems are immediately brought to the center of view for the pilot. Less critical systems are also monitored and when attention is needed they are automatically routed to the pilot display.
In our MCR, the focus is on making sure that the content is leaving correctly. We have a line-out monitor system for that. We also monitor the return feeds from our transmitter sites. Those are smaller monitors and are within the field of view of the MCR operator but not directly centered. In the event of a loss of signal from any site, the MCR operator can quickly glance at the bank of monitors and determine which transmitter signal is off-line. The operators can then move to the appropriate computer station and take appropriate action.
However, during this time, the operator loses contact with the other systems, and if something happens at another site, the operator may be unaware of it. In this example, a transmitter failure is generally pretty catastrophic and easy to spot. But how does an operator determine if the opportunistic data that is traveling with the DTV signal is correct, and what does he or she do if it isn't? Most importantly, who's minding the store while the MCR operator is trying to track down the problem and institute the appropriate correction action?
As part of our research and planning, we are looking at systems and asking the manufacturer how this hardware will interface within our operation. I want an on-call engineer to be able to interrogate and take appropriate corrective action from his home, if possible. I have really become interested in SNMP as a methodology for interconnecting systems and providing an unobtrusive level of command and reporting that may provide the best compromise between flexibility and functionality. Whereas as I don't expect to be able to instruct a robot at a transmitter site to replace an IOT, being able to monitor and control the hardware to adjust for the parameter changes and recalibrate correctors to make the signal receivable is not beyond the scope of the plan.
