Users who are building large-scale facilities are now spending more on software integration than they are on hardware.
As the chairman of a SMPTE committee committed to mapping out the future of control systems for broadcast, I spent an interesting year or two studying the topic. The Advanced System Control Architectures Group set out to plot the likely future courses for technological development in areas of automation and studio control.
The Group produced a system overview document, a brief summary of which is below. In the end, however, the Group faced significant challenges, and this month will be dissolved. This is in spite of the current situation as users have described it to me.
Users who are building large-scale facilities are now spending more on software integration than they are on hardware. Those who develop custom, one-off solutions face high development costs, dead-end support, and have no migration pathway to new technology. Frequently, users decide that the easiest solution is to go back to the lowest common denominator. Rather than design systems that work well and solve problems, users hire people and put them in jobs where, through no fault of their own (just try to add up a series of show and commercial times under the pressure of live television), they make repeated mistakes that cost their companies money day in and day out.
Users express frustration because they know solutions potentially exist. They know that if manufacturers would get their act together, systems could be built that work well together. They are beginning to look at IT and Internet-based solutions that support connectivity rather than purpose-built broadcast applications. But users are confused about all the different standards from SMPTE, the IT world, Internet RFCs and how they work together. (They do work together right?)
So let's look at the system overview and how control systems could be built in the future.
System overview
The overview document describes a system of planes and layers as illustrated in Figure 1.
The planes in the model normalize access to the primary studio assets, namely content, network and devices. A usage abstraction from content through to device is provided to support varying levels of workflow within the studio. (See Figure 2.)
Functional planes exist as the front line interface between the studio applications and the functionality of the control system. The four functional planes are defined below:
- Content Management Plane Manages content in the studio Understands physical storage allocation for the content Performs activities including content distribution, content creation, scheduled operations and storage management Presents a view of content as required for data streaming
- Service Plane Combines multiple content streams into complete services Maps services onto resources available in the path plane Abstracts the mapping of content to individual pieces of equipment Uses content sources to create paths
- Path Plane Facilitates the physical connection between devices for the purposes of data streaming Manages the physical links between devices Manages the resources required for these connections
- Device Plane Contains the interfaces used to access studio equipment Provides specific information for device IO capability (ports) Based on a SMPTE-defined hierarchy of functional classifications Provides for extensible interfaces
The planes are organized into a form of usage abstraction from content to service to path to device. Adjacent planes cooperate to carry out individual operations as generated by the studio applications. Though this abstraction is beneficial in most cases, it is not explicitly required. Applications can access functionality at any plane, or planes can access any other plane in order to get the task accomplished.
These functional planes represent logical partitioning within the control system. From an implementation point of view, the devices themselves will likely be responsible for running local software that will contribute to the functionality of one or more of the planes. For example, within a network router, software exists at runtime that is responsible for some path plane functionality.
Functional layers
Figure 3 shows the relationship between the component layers of the system. The layers provide access to the reusable system functions as provided by the studio devices/resources. It also provides physical device independence and physical network independence where possible to allow for the highest degree of application portability.
While many of the systems issues faced by broadcasters are unique, there are a great many technologies and standards that have been developed in other industries that have direct application to our area of interest. Our methodology was simple — develop a model and then identify existing standards that can be used to implement the model. If existing standards were insufficient, then we would draft the appropriate standards.
While the overview document provided a picture of how complex systems could be designed, it did not contain sufficient detail or specificity to allow interoperable implementations to be built. The group felt there were certain base assumptions that needed to be tested before work could continue. We established an ad-hoc Primitive Issues group to delve into the next level of detail.
After several meetings, the group uncovered significant issues. First, some companies have investment in solutions other than those proposed. Second, some companies do not see any compelling business reason to do the development work. This issue is manifested in two ways — some companies do not believe there is a control problem to be solved, while some companies do not believe customers will pay for systems which have the functionality described in the overview document. Third, some felt that the group had not given adequate consideration to all use cases. Fourth, and perhaps most significantly, the companies who are most active in the industry in this area were not participating in the activities of the group.
With the Primitive Issues Group at a standstill, and with participation flagging, it became clear the group was losing traction.
Many of the original goals of the larger Advanced Systems Architecture Group were met. However, some were not. We were able to reach consensus about an overall approach. Choosing specific technology to allow integrated implementation proved very difficult.
The disbandment of my group does not mean that work in this area is not desirable or attainable. For example, users would benefit from standardized messages between applications and in standardized SNMP MIBs for devices.
The Group has produced documents that we hope will become the basis for a unified control architecture of the future. We believe that the system overview document provides a useful further development of the ideas first presented in the EBU/SMPTE Task Force Report.
Brad Gilmer is executive director of the AAF Association and president of Gilmer & Associates, a broadcast consulting firm.
