Steve Greenblatt, CTS
Control Concepts, Inc.
www.controlconcepts.net
AV over IP (Audio Visual Over Internet Protocol or AVoIP) switching solutions are becoming the norm in the AV landscape. What was once only a cost-effective solution for large scale needs has now become the go to technology for almost any application or system size outside of the specialized or limited budget applications.
While the challenges of AVoIP solutions have historically been a reliance on the network for AV signal transport and the added complexity of troubleshooting that comes along with using the network as the backbone for signal flow, the benefits of ease of growth along with the freedom to implement the exact number of inputs and outputs necessary to support needs without the constraints of a minimum or maximum number of inputs and outputs is incredibly valuable. Additionally, most AVoIP solutions offer signal processing, expansion of control points through their endpoints, and software upgradability.
With traditional matrix switching solutions that have limited configuration, including a finite number of inputs and outputs, there is a physical product with one communication interface for control. Control commands are issued and received through a single control port which processes the command, executes the action, and returns a reply. This is very typical of most devices that have limited options and are static rather than scalable.
For AVoIP solutions, whose inherent advantages include flexibility and scalability, the ability to have virtually any number of inputs and outputs (each of which being individually addressable) presents unique requirements and scenarios to be mindful of when it comes to control. The number of communication connections between a control system and a AVoIP system, the amount of communication traffic on the network, and the load on a control system processor that could grow significantly with larger deployments and more complex systems are all factors that require consideration as they can present an unexpected challenge if not managed properly.
In traditional matrix switching products, where the hardware has a maximum number of inputs and outputs, the control solution has limited variables and unknowns and thus can be handled in a straightforward manner. However, the inherent flexibility of AVoIP systems requires a different approach to control that will expose a critical fail point if not handled properly. As systems expand and equipment, programming, and the network become more taxed, control solutions that work for simpler systems can exhibit performance issues if not architected properly.
The ability to take advantage of the power of AVoIP solutions, including the flexibility, growth potential, and ease of upgradability, highly depends not only on the design of the physical hardware and network but also on the approach to the control software that defines the system operation. There is a difference between programming a system for a fixed setup and limited potential growth and architecting software that has been built modularly with a vision for future expansion and flexibility.
A critical component of any control software is the device modules, drivers, or plugins that make integrating each piece of equipment easy to control and reliable to operate. (Note: The module, driver, or plugin terminology is specific to different control manufacturers and can be used interchangeably.)
Architecting a solid foundation for growth and adaptability starts with the extensibility of a module, driver, or plugin, allowing for consistent control for one or many of each device within a system and the ability to easily adjust functionality without incurring a significant impact on existing programming.
For AVoIP solutions, the conversation does not become about the value of a module, driver, or plugin but rather about the critical importance of architecting a module, driver, or plugin suite to accommodate flexibility, establish adaptability, and ensure stress-tested reliability.
Three distinct approaches can be taken to design a module, driver, or plugin for controlling an AVoIP solution: one that supports each endpoint individually, one that supports a fixed number of endpoints (perhaps eight or 16), and one that supports a flexible number of endpoints.
Single Endpoint Approach
The single endpoint approach seems like the most practical because it allows for the number of inputs and outputs to be set and modified as needed; however, the issue with this design comes down to overhead. Since the hardware that the module, driver, or plugin connects to will report status for as many endpoints as are being used via its application programming interface (API), each module, driver, or plugin will then receive all the data for all the endpoints when it only cares about the endpoint it is assigned to and can ignore the rest. As the number of inputs and outputs needed for a system grows and each endpoint will be connecting and querying for data, the amount of communication will be detrimental to the performance of the control program, processor, and network. This is not an optimal design.
Fixed Number of Endpoints Approach
A design that includes a module, driver, or plugin with a fixed number of endpoints helps improve the overhead issue in the previous example, but still has an issue of scale. Consider a module, driver, or plugin that supports factors of eight inputs and eight outputs. For a system with nine inputs and 12 outputs, an eight by eight module, driver, or plugin would need to be upgraded to a 16 input and 16 output module, driver, or plugin. This is where the fixed number of endpoints approach starts to introduce inefficiencies with seven unused inputs and four unused outputs existing in the project
program. While this scenario could be thought of as providing the opportunity for “future growth,” for larger systems that jump to 32 input and 32 output or 64 input and 64 output modules, drivers, or plugins, the number of unused inputs and outputs becomes significant, and the additional programming logic, processor overhead, and communication traffic has a greater impact. For these reasons and those similar to the single endpoint approach, fail points will be exposed in larger systems or projects with more complex programming requirements.
Flexible Number of Endpoints Approach with Gateway
The optimal approach would be one that can be tailored to specifically match the requirement and can be easily modified to support change – endpoint modules, drivers, or plugins that all communicate through one connection where each module, driver, or plugin only receives the information for the endpoint it represents.
How do multiple modules, drivers, or plugins in a program communicate through a single connection?
The answer is to create a separate module, driver, or plugin object that acts like a Gateway to manage communication of all endpoints – sending queries and commands from each endpoint and routing responses to the appropriate endpoint module, driver, or plugin.
This Gateway model solves the issue of communication overload that is detrimental to the performance of the control program, processor, and network by maintaining a single connection to the “AVoIP solution” and filtering communication to all the endpoint modules, drivers, or plugins appropriately. By acting as the message router, each endpoint will only receive its own messages. This greatly improves the volume of messages and the overall performance of the endpoint modules, drivers, or plugins. The Gateway also solves the issue of scale as the number of endpoints that could register with the Gateway is not limited. An additional endpoint can be included in the system without disrupting the existing programming for other endpoints. This makes for simple, effective upgrades with minimal effort. Imagine a system with 32 or 320 endpoints, adding 16 or 160 additional endpoints. This is where the power and the critical importance of an efficient and scalable module, driver, or plugin design prevents communication issues, data overruns, and unwanted network traffic that can harm system performance.
The Gateway concept has other advantages. A single point of communication simplifies securing the connection when required. For security considerations, fewer network connections reduce potential network vulnerabilities. As more manufacturers implement secure communications to make their products more IT-friendly and respect network safeguards, the Gateway model will be regarded as a highly favorable approach.
While module, driver, and plugin solutions may exist for many manufacturers’ AVoIP solutions, how many of them invest in having their module, driver, or plugin
development architected to their specific needs using an approach that emphasizes scalability, efficiency, and stress-tested reliability?
When evaluating AVoIP solutions, criteria should not be limited to signal quality, latency, and bandwidth requirements. Control reliability is a critical aspect of their success, followed by ease of programming and support. The availability of manufacturer-endorsed, maintained, and field-tested control modules, drivers, and plugins that are architected effectively will provide the confidence that integrators and end users need to be successful
