A new broadcast facility should, in theory, be engineered and implemented based on a business plan and capital budget passed down from upper management. The problem today is that no solid future business plan exists for most broadcasters. The current broadcast business environment is unsustainable over the long haul — new revenue streams will be a necessity. It is becoming evident that stations will need to produce multiple real-time and non-real-time program streams.
If multichannel is the future, then the way business is conducted must change. The requirements for multichannel operations are radically different than those for traditional single-service operations. The challenge is to support the additional services with the same number and level of personnel. Current automated operations are typically governed by plant workflow and organized by a software layer presiding over hardware functions. Automation has evolved along the same timeline as digital video, starting with separate stand-alone islands and growing into a contiguous control layer. Media are increasingly being treated as object modules by client applications that control, manage and use data. Drilling down to basics, automation aggregates all scheduling information for allocated resources and ensures that media and associated metadata are available when and where they are needed. The basic automation applications include ingest, conforming, media management, playout and, potentially, archiving. Automation systems will need to be able to handle these functions for more services in the future, while decreasing the ratio of operators to program channels.
Automation must be flexible enough to migrate to new business models as they evolve. It must also manage essence and its associated metadata, as well as track rights management across multiple outlets.
Multichannel applications
It's quite possible that, in the future, workflow will be geared for content management, rather than program-channel management, as is the case today. Most broadcasters will likely continue to use one real-time stream to carry live and network-pass-through content. Other content will increasingly be configured as files that are played out under automation control with little human intervention (aside from the creation of policies). The most talked-about repurposing of content today is an automated newsreel. A number of vendors are now offering applications that will build and play out a secondary news channel with little care and feeding by humans. Hopefully, creative broadcasters will discover other programming opportunities for DTV's additional channels, as most markets won't support multiple local newsreels.
Multichannel automation's ability to push tasks farther from traditional operating positions also makes it possible to share labor across multiple facilities. Stations in different markets airing the same programming don't each need to conform the show. Media can be delivered to each station by distribution groups such as Pathfire or DG Systems, or by a broadcaster's own distribution system. Each station can then add its own metadata, and programming will be ready for playout without additional media preparation.
Workflow changes
Multichannel presents a considerable change in what operators do and the tools they require. Operators in an automated multichannel environment tend to react to systemic problems and faults, rather than actively switching between sources. In multichannel operations, they need to react to alarms and problems in one program log that may ripple across to other logs. In fact, monitoring the health of multiple programs can consume a fair amount of the operator's time. Bringing more channels online reduces the ratio of operators to channels, thus lowering the cost of additional service deployment.
Application processes controlling the hardware in a multichannel environment need to be more collaborative and cohesive. Automation, typically driven by traffic, must control ATSC encoder/muxing elements to change their service profiles. Also, multiple traffic logs and dynamic PSIP tables must be kept in coordination so that programming matches the PSIP information. This coordination can become cumbersome with certain types of live programming, such as sporting events that don't run their scheduled length.
Middleware
Automation control is spreading as more hardware is brought under its umbrella — facilitated by an increasing amount of middleware. Automation systems have long relied on middleware to implement SQL protocol for database access, remote procedure calls via CORBA, and Microsoft's COM technologies through ActiveX controls for application collaboration and client/server processes. Now, technologies such as Microsoft's .NET are enabling Web services to become tools in the control and operation of the facility. XML now allows the sharing of information between subsystems that need to work together to implement the desired workflow, as long as they subsystems agree on consistent information tags. Many newsroom systems use Media Object Server (MOS) protocol, which is formed using XML. Other Internet-based protocols, such as Web Services Description Language (WSDL) and Simple Object Access Protocol (SOAP) are used for spreading control though the Web. In fact, one of the goals of SOAP is to encapsulate remote procedure calls using the extensibility and flexibility of XML. At least one automation vendor uses SOAP as part of its bag of tricks. An important recent development that relies on XML is the Programming Metadata Communication Protocol (PMCP). This ATSC candidate standard will allow for greater interaction between a broadcaster's PSIP system and other system applications, such as automation and traffic. Ultimately, an automation system implementing PMCP will be able to support a more dynamic environment, allowing program changes to be made more easily and efficiently.
Another technology that is being incorporated in the automation arena is Simple Network Management Protocol (SNMP). SNMP is used in the computer networking and telco industries to get information from devices and to change the values of configuration parameters as required. For a device to participate in an SNMP network, it needs to be able to host a software database called a management information base (MIB), which responds to messages from an SNMP manager and notifies the manager when predetermined events occur. This technology will become much more important as multichannel operations staffs become monitors of systems (both locally and remotely, as in the case of multicasting) and are tasked with responding to developing problems and failures.
A changing landscape
Today, automation systems must manage content and build program streams, relying on human intervention mainly media is missing. Multichannel operations will require a control layer that encompasses more processes and aspires to be much more than simply a machine- and device-control system. New multichannel automation systems will need to provide control over more process than most systems currently support. Automatic construction of secondary program offerings will be desirable. Non-real-time offerings could become common fare with Windows Media 9 and MPEG-4 support in future generations of set-top boxes.
It should be noted that the ATSC is currently evaluating new encoding technologies for providing these advanced services. Programming could be delivered through datacasting or IP, with embedded metadata instructing use and context of the media for reassembly at the receiver. The television broadcasting landscape could be radically different in a few years: The control layer in place to orchestrate programs and associated services should be radically different also.
Jim Boston is an industry consultant based on the West Coast, and Mark Brown is CTO of SignaSys.
