In this day of widespread computer networking, most of us know about the OSI software stack. This allows an application, for example an Internet browser, to not have to be concerned with how to communicate over a given network. The operating system the application is riding on top of knows how to use each particular communications scheme that might be required. All the application needs to be able to do is to call on the services of software layers below it. The services required for reliable communications over an intranet or Internet have undergone stratification. The most common way to ensure dependable communications between two computers is via TCP/IP. The application requiring the communications calls on the services of the TCP layer, which provides notification that the sent data has successfully arrived at the desired location. It does this by wrapping chunks (packets) of your applications data with information to enable successful recovery at the receive end and rules for feedback to the sender if something has gone awry. The TCP layer hands your wrapped data to the IP layer. The IP layer adds another layer of wrapping; this time the address of the destination is added. These two layers are referred to as the Transport and Network layers respectively. The IP layer hands this doubly wrapped data off to the Datalink layer below it. This layer knows how to negotiate the physical network that your computer is connected to - the most common LAN in use being the Ethernet. Below the Network layer is the Physical layer. This is the coax, or twisted pair, hubs, AUI boxes, etc. that comprise the local LAN. An application running on one PC requiring communication with another application on another PC would call on the services of the layers below it. The application, which resides in a layer known as the "application" layer would call upon the layer below it, which calls on the layer below it, etc. The layer below the application layer is the Presentation layer. This layer invokes other applications needed to present data to the user. Such as video/audio players, and browsers if the data being received requires these services. The next layer down is the Session layer. This is the layer that sets up a communication layer between applications residing on separate PCs. This layer tears down the session when it is complete. This layer can conduct multiple sessions at once, assigning each one a virtual port number. Some applications like FTP, and Web browsers use assigned port numbers, whereas other port numbers are dynamically assigned as needed. Next is the Transport layer. This layer makes sure that data sent from one application to another arrives in tact. This layer is where the TCP part of TCP/IP resides. The next layer down is the Network layer. It adds the addressing necessary to get the data to its intended destination. This layer houses the IP portion of TCP/IP. The next layer is the Data-Link layer. This layer is specific to the local network connection that the PC has. This layer knows the protocol required to communication on the LAN the PC is connected to: such as Ethernet, Token Ring, FDDI, ISDN, Frame Relay, etc. The bottom layer is the Physical Layer. This consists of the electrical drivers and receivers connected to the actual port on the back of your PC. The cabling, hubs, and other physical items that comprise your local network are all considered part of the physical layer.
This layering approach to dividing up the chores used in software is used in the average television station also. The major tasks that must be carried out in a commercial television station include selling the commercial time, making sure that the clients' spots are successfully scheduled to run and running the correct spot at the right time. Finally, there must be the necessary hardware to air the commercials and some programming as well. We have names for these tasks: Sales, Traffic, Operations, Engineering. Of course, there are other departments, but these four make up the direct conduit from sales to cash flow. We can conceptualize these entities as a stack of layers. At the top would be sales. Sales activity is funneled into traffic. As most of us know, traffic takes sales orders and contracts along with the shows the station airs and determines when every item is played. The output of the traffic department is a program log. Traffic departments are faced with filling every second of commercial inventory while getting the most money to be had for that particular commercial slot. This means that sponsors and their accompanying media (the spot) are often in a game of musical chairs right up to the day of air, and often up to the hour of air.
The program log, also known as an event list, is handed off to operations. Until recently, operations had to manually locate the programming and commercial spots and load them into the appropriate playback device. If the spot or program was not in house, it had to be bicycled in, recorded off satellite or obtained by some other terrestrial means. Someone also had to manually start the playback device and switch to the desired source. There have been control systems above master control switchers for quite some time that would automate the playback and switching operations. But today, most new installations are adding a much broader control layer over the equipment or physical layer. This layer is generally called automation, and in some installations it nearly covers the entire physical layer below it. A final component in the sales-to-payday path is reconciliation. Once a client's spot has been successfully played, the information must be sent back to traffic, which lets accounts receivable know that there is money to be collected. If all has gone well operations completes the cycle by sending an "as-run" list back up to the business layer.
The name of the game is to minimize the number of discrepancies. The whole cycle just mentioned must function together to accomplish that. One of the traffic vendors' biggest arguments for using their particular system is how low their particular discrep rates are. As you would expect, each claims to have the lowest percentage. At the operations level you need the automation system to perpetuate a low discrep rate. Of all the systems you might invest in for your facility, automation is the farthest from being a cookie cutter product. A good automation vendor will spend a lot of time trying to understand your operations and expectations.
Building blocks Automation consists of a number of basic and required components. Additional capability and quantity of devices controlled (how wide the automation layer will be over the physical layer) is available a la carte. The basic building blocks consist of Media Management, Event Control and Device Control.
Media management software controls ingest and preparation of material. What this means for most facilities is that it controls the ingest of material into a server and maintains the database that organizes the media for the human operator and the rest of the automation system. Some vendors split this function up into separate applications - one for ingest and preparation, and another for management of the material on the server(s) or tape playback system. As you probably already know, the Event Manager needs to communicate with the traffic layer above it. But the Media Manager must also exchange data with traffic. Either traffic or automation, and often both, needs to know what media is missing in the playback systems. This is one reason that most systems have a computer known as a server. It is used in some systems to sort data traffic between the traffic and automation layers to either the Media Manager or the Event Manager. You might wonder how the traffic system and the automation talk. The traffic vendors publish Automation Interface Protocols that the automation systems speak. Early protocols were batchlike in nature. They sent information to the automation or received feedback from the automation layer only when instructed to do so. Newer protocols have continual dialogs between the two layers as needed.
The next component is the Event Manager. This software receives the playlist from traffic. The playlist can come straight from traffic in some systems, or can be sent first to the systems server and stored as a database that can be accessed by the Event Manager. Some systems have the playlist and Master Control operators GUI on the same PC. Other systems separate the two. The playlist is sent to a PC called a machine or device server. This is the third basic automation component. Once the playlist is in the device server, the rest of the system could be taken offline and the list could simply run on its own as long as the event list didn't need editing and the required devices were connected to that device server. Some device servers can control as many as 64 devices, mainly via RS-422. Most local television stations don't require half that many controlled devices. If more controlled devices are required, then additional device servers can be added. Some systems don't send the event commands to the device server until shortly before the event happens. Although most installations require only a single device server, vendors allow for two device servers to run in parallel, one acting as a backup. A single device server is a single point of failure that will have immediate impact on your operation.
Additional playlists and the number of controlled devices are purchased as needed. The basic system usually comes with at least the on-air playlist, but often you must purchase the capability of using more than one playlist at once. Additional playlists are needed for multichannel operations. Other uses would be for automated satellite operations. Some device controllers can run multiple playlists at once. Some vendors allow devices on one device to be controlled by playlists on other device servers. Some also let the same device be shared by multiple playlists. Some systems have elaborate software that will automatically search the system for media not already loaded which is needed by a playback device, and will then copy the required material when found. The philosophy in selling device control is different among the various vendors. Some simply sell port capability, while others charge per device controlled. Plus, at least one vendor requires your software to be modified and re-compiled if devices are added. While on the subject of additional costs and fees, most vendors charge a yearly software and support fee. Plus, automation systems require a substantial amount of installation and training time at your facility. You get to pay for that also. Also, there are other costs associated with implementing automation. If you have a media management database for your commercial server already, can that database be converted for use by the automation database or must the inventory be reloaded back onto the server to create a new database? Although different databases will use the same server file format, you might have to reload media just to create an external database useable by the new media manager.
It is not unusual for even a small automation system to be comprised of four or five PCs. As mentioned already, many systems require not only a server PC, but also PCs supporting media management, on-air (controlling the air playlist), and one or more device servers. For the sake of operating efficiency and human ergonomics, additional PCs will often be required for various options, such as an installation running various event or playlists. The required PCs usually are connected via an Ethernet. This local LAN usually sits off by itself away from the LAN for the rest of the facilities. The gateway between the two is usually via the automation systems server. Some systems use high level communications schemes such as TCP/IP, but others use lower level schemes such as NetBEUI (NetBIOS Extended Use Interface). NetBIOS is a simple protocol that allows quick messaging between PCs. It provides session communications over a LAN without a lot of overhead. NetBIOS resides on the Session and Transport Layers. NETBEUI provided a standard frame format for packets. Philosophies differ as to which communications schemes make sense when trying to control real-time events. Some get around any real-time delay problems by storing the event or playlist in the device server. That way the device server doesn't need real-time triggers from another PC via LAN. Others use lower level communications protocols that don't have the overhead that higher level protocols have. A drawback to the low-level approach is that you can't build an automation system over a WAN. If the automation network requires routers or switches, some low level communications schemes won't be able to negotiate those items.
Vendors also differ on operating systems used. While most use Windows of some flavor (often NT) on some computers, most do not for PCs acting as servers. Some feel that Windows has too much overhead for a real-time environment. These vendors argue that variants of Unix such as QNX or even O/S2, which allows loading only modules of the operating system required, are better choices. They further argue that real-time machine control needs a leaner OS geared towards real-time events. Most agree though that "business" type apps, which comprise a major portion of automation system software, do make sense running on Windows. That said, there is at least one automation vendor that has been successful building systems that ran totally on DOS, and now on Windows. The mix of OS can affect how a system handles real-time commands such as starting events or commercial breaks, on the fly. Some handle these situations better than others.
So besides a bunch of server-and-client-type PCs, plus a chunk of LAN, automation systems are a collection of software applications often running on a couple of different operating systems. This software is often centered around one or more databases, and a messaging system to let the applications distributed on various PCs stay in sync. The user applications manipulate the database(s), and the database are used to create activity (event) lists that end up in device server PCs that drive RS-422 (or GPI) ports that command the physical layer to do the bidding of the operation and business layers above. Automation needs to act as a component, albeit a large one, that is part of the larger station system. Automation systems promise two things: efficiency and fewer mistakes in your operation.
RICHARD TYRRELL-EAD Digital television transmission produces new management challenges for stations. Multicasting, datacasting, electronic program guides (EPGs), and selectable subtitles and language audio tracks are only a few of the options digital transmission affords station operators. Yet, how does automation manage this transition from analog to digital and enable a station to optimize its resources?
Equipment The difference between analog and digital automation starts with the equipment used for information management and transmission. While analog automation can work with tape and tape machines and requires no transmission information, digital automation stores material in video servers and can require CD/digital tape players along with control information for encoders/decoders. For transmission, analog requires no forward control of the transmitter, while digital transmission can require extensive control and information for the encoding and transmission process. Digital transmission can be transmitted terrestrially via ATSC signal, or can take advantage of Fibre Channel/ATM, WAN, LAN, and satellite allowing for centralization and reuse of material.
Asset Management An analog automation system works with a database - tracking where a program or commercial resides (e.g. tape 1, 2 or 3). Digital automation requires a much larger, more complex database that coordinates encoding and transmission information for the program/commercial's metadata (e.g. multilingual names, descriptions, synopses, credits, V-chip information, CA and categorizations) between the business side (traffic and program control) and material management. Digital video servers provide for a second copy of the metadata to be stored with the clips and programs.
A database that centralizes transmission information is essential for digital transmission. Transmission information that resides in a common database synchronizes all of the transmission equipment with the information required for every piece of material transmitted. By centralizing these instructions (playlists) changes can be made once and all transmission components will follow.
Bandwidth Analog allows broadcasters to deliver one channel per transmitted signal (pipe) to viewers. Digital compression allows a station to make choices. A broadcaster can choose to have one high-definition channel or choose to segment spectrum in a multicast environment (implement multiple channels). To keep overhead from going up, the station's automation system must provide the capacity for one operator to run these multiple schedules.
The Next Step While you're counting the benefits of digital automation - improved productivity from integrating databases; simplifying a more complex operation than analog; providing a system that allows last-minute changes, reduces errors, and improves monitoring - look ahead to the next step in the progression of automation. As the availability of more customer-specific content increases, automation systems will provide broadcasters with more opportunity to re-purpose material into different pipelines of distribution including digital transmission, Internet, intranet and beyond.
