In the most basic terms, interoperability is the ability of a system or a product to work with other systems or products — with no special effort required on the part of the user.
Standards only define a certain level or a basis for interoperability. For example, let's take a look at ANSI/SMPTE-259M, the serial digital video interface standard. Companies interpret the document in different ways. For example, for finding vertical sync, some companies lock on the line counter, others on the raising edge of V-blanking, some on the falling edge, and a few even use the field bit. When manufacturers don't use the same logic to determine the start of vertical sync, the result is often a vertical picture shift.
The industry has more or less addressed these discrepancies now, but from time to time, service labs run into difficulty, mainly with new players that have not dealt with this interoperability issue before. Speak with any broadcaster that has a lab, and you are bound to hear lots of interoperability war stories.
While manufacturers met the specifications, it often comes down to how they interpreted the spec. Embedded audio is another nightmare, with two people able to discern two very different meanings within a single paragraph of a standards document. While the standards bodies spend hours — often days and weeks — on a single concept to clearly articulate the meaning, it's just not always possible to cover every angle.
The cause of interoperability issues
It seems that in the single-channel analog world, interoperability “just happened.” Certainly, analog linear workflow had significantly fewer interconnections. Also, the signal paths were typically limited to twisted pair audio, NTSC/PAL video and machine control running over broadcast RS-422 (SMPTE-207M). Other controls for products such as routers, satellite dishes, talk-back intercoms, transmitters and STLs, editing systems, and even graphic systems were all proprietary.
In this more simplistic world, manufacturers would seek out and align with the market leader in any given area to ensure compatibility. If there was no clear market leader, manufacturers invested R&D into protocol converters, providing customers with the advantage of not being married to a single manufacturer's proprietary system.
The switch to digital suddenly gave broadcasters the flexibility to add more channels, but at the price of complexity. While equipment costs dramatically decreased, the digital revolution brought many more standards and interconnection issues. With flexibility comes complexity — and the only path back to simpler times is via interoperability.
“True” interoperability
Although Simple Network Management Protocol (SNMP) has been an established protocol for network management within the network community for many years, broadcasters insisted they would never use such an expensive, complex solution. Today, however, with budgets being squeezed and the constant increase in on-air channels, broadcasters are demanding SNMP, and it is emerging as an important interoperability protocol for the broadcast as well the networking community.
However, it's not enough for manufacturers to simply support a standard version of the SNMP protocol natively at their devices. Device interfaces for SNMP (MIBS) also need to be structured correctly and comply with the ASN specification. Without this important interoperability step, some manufacturers' equipment may only be accessible by their own control system, even though SNMP has been used as the underlying control protocol. For true interoperability, all device interface MIBS need to be validated for compliancy to a broad range of control clients, not just the ones sold by that manufacturer.
So as a customer, it's not enough to expect that checking the box on SNMP will provide the level of interoperability you will need. Manufacturers should offer you proof that their systems comply with the full standard. Ideally, this should be validated by a third-party's compliancy test suite. For this reason, some manufacturers employ a third-party SNMP partner that regularly validates their SNMP solutions for full compliance. Again, be cautious here: Don't accept the “we are using a third-party” story; it needs to be a compliant third party.
The broadcast world is now dependent on a file-based workflow. Program content (assets) contains an increasing amount of information. The essence is now just one part of the information transported via broadcast distribution.
The actual transport between two entities — whether servers, switches, routers, encoders, etc. — is accomplished using a data model. This data model defines the means by which various entities handle, or process, relevant information. It defines their interoperability.
To better understand interoperability, it is easier to break it down into smaller pieces, similar to what the computer geeks do with seven Open Systems Interconnection (OSI) layers. (See Figure 1.)
However, even this breakdown was too complex and has been simplified into a three-layer model. (See Figure 2 on page 78.) For broadcast users, this three-layer structure is ideal for representing different workflow areas, and it helps them to better understand where and why they need interoperability.
Checklist
Figure 3 on page 78 provides an interoperability checklist, mapping out typical products used in the broadcast environment. For simplicity purposes, cameras, monitors and test and measurement equipment are not shown on this chart. As a new addition in the digital world, IP routing has been added to the mix.
When purchasing a routing switch matrix, for example, be aware of “the plumbing.” Are you routing around SDI or PAL/NTSC? Is the audio on coax or twisted pair? Do you want the router controlled with control panels or automation, or perhaps both?
How does the router find vertical? How is audio switched? Is that different for digital? Are tallies needed? What is the automation protocol? The complexity soon builds.
Solving interoperability problems
The software side of broadcasting has traditionally been even more of a mess when it comes to standardization. Traditionally, vendors created point-to-point interfaces when common customers came along, and each interface was normally specific to a pair of systems. This resulted in hundreds of interfaces floating around, certainly not something that lends itself to easy interoperability.
SMPTE recognized this problem and initiated the S22-10 effort, bringing together more than 70 broadcast vendors to find a solution. The group came up with the Broadcast Exchange Format (BXF), a single protocol that can be used by a variety of broadcast systems — including traffic, automation, program management, listing services and content distribution services. The protocol helps to achieve dynamic interoperability, further simplifying and streamlining broadcast operations. There are real savings to be realized by implementing BXF, from reduced manual day-to-day processes to reduced software development and implementation complexity. In addition, there are clear revenue opportunities surrounding day-of-air sales and the ability to easily manipulate content and schedules.
Another example of interoperability being achieved using an industry standard is in the PSIP area. Many systems existed that were capable of managing PSIP data, but this data was trapped within these diverse systems. The ATSC created the Programming Metadata Communications Protocol (PMCP) to enable systems that manage PSIP data to also exchange it. PMCP allowed traffic, automation, program management and PSIP systems to exchange program listing data, overcoming the challenges of multiple data sources, and ultimately shifting ownership of the data over time. This enabled broadcasters to leverage PSIP and to avoid fines already levied by the FCC in this area.
Testing
Some manufacturers have testing environments for the integration of various products. There is a huge difference between integration and interoperability testing. Integration testing ensures that various products work together for a specific requirement and during the development process. Interoperability testing continually verifies various product and software revisions to assure upgrade compatibility.
Conclusion
Both manufacturers and customers must ensure product interoperability exists and that products function properly within a broadcast facility. What can you do? Be aware of the products you are buying, use the interoperability checklist, understand what is required, and don't hesitate to ask your suppliers about interoperability. Don't accept the answer of “we meet industry standards.” Ask how this was verified.
Stan Moote is vice president of corporate development at Harris Broadcast Communications.
