• September 1, 2022
• Adam Hanson

How often does an AV system get designed, commissioned, and programmed, and then never touched again? The answer is: Not often! AV systems must be adaptable to meet users’ changing needs. Starting with a “simple” design that meets current requirements, while keeping in mind the potential for future growth, always sounds like an effective strategy. But how often is future-proofing truly considered in today’s system design and programming?

The ability to take advantage of growth potential and ease of implementation highly depends not only on the physical installation and hardware design but also on the design of the control software that defines the system operation. There is a difference between programming a system with a sole focus on current needs and architecting software that has been built modularly with a vision for future growth and modification.

A critical component of any control software is the device modules, drivers, or plugins that make the integration between each piece of equipment easy to control and reliable to operate. It is important to note that the module, driver, or plugin terminology is specific to different control manufacturers and can be used interchangeably. For the purposes of this piece, we will use the terminology module.

Architecting a solid foundation for growth and adaptability starts with the extensibility of a module allowing for consistent control for one or many of each device within a system and the ability to easily add functionality without incurring significant impact on existing programming.

Consider a scenario where an existing system supports four audio zones and the needs for the space have changed requiring two additional audio zones. The audio system itself supports up to eight zones, so the two additional zones can be accommodated by the existing system without exceeding the system’s capabilities.

How will the AV system programming for the two additional zones be handled?

This is where the design of the audio zone modules comes into play. Let’s consider three types of audio zone modules: one that supports a single zone, one that supports a fixed number of zones, and one that supports a flexible number of zones.

Using a single zone audio module may seem like an obvious choice – just add two modules to the existing four. No problem!

However, the issue with this design comes down to overhead. Since the hardware that the module connects to will report information for one or many zones via its application programming interface (API), one connection from a module to the hardware could handle all the communication. Instead, by using the single zone module model in this instance, six modules will each be connecting and querying for data. Each module will then receive all data for all zones, requiring each instance to ignore data for zones it isn’t interested in. Six connections sending redundant data, most of which is not needed, is not an optimal design.

A design that includes a module with a fixed number of zones helps improve the overhead issue in the previous example, but still has an issue of scale. Chances are one of the modules will only be partially used. For example, a module that supports four zones will require two modules with two unprogrammed zones in one of the modules. While this scenario could be thought of as providing the opportunity for “future growth,” it is not best practice to include additional program logic that is unnecessary.

The optimal solution would be one that can be tailored to specifically match the requirement and can be easily modified to support change – six zone modules that all communicate through one connection where each module only receives the information for the zone it represents.

But how do the six zone modules communicate through a single connection?

The answer is to create a separate object that acts like a gateway to manage communication of all zones – sending queries and commands from each zone to the audio system and routing responses to the appropriate zone module.

This gateway model solves the issue of overhead by maintaining a single connection to the audio system and filtering communication to all the zone modules appropriately. It also acts as the message router, so each zone will only receive its own messages. This greatly improves the volume of messages on the network and the overall performance of the zone modules.  The gateway also solves the issue of scale as the number of zones that could register with the gateway is not limited. Adding an additional zone to the solution can be achieved without disrupting the existing programming for other zones. This makes for simple, effective upgrades with minimal effort.

In this example, adding two zones to make a total of six may not truly demonstrate the impact of the gateway approach.  Instead, imagine a system with 40 or 400 zones adding 20 or 200 additional zones. That is where the power and the critical importance of an efficient and scalable module design prevent communication issues, data overruns, and unwanted network traffic that can be detrimental to system performance.

There are other advantages to the gateway concept. A single point of communication simplifies securing the connection when required. For security considerations, fewer network connections reduce potential network vulnerabilities.  With more and more manufacturers implementing secure communications to make their products more IT-friendly and respecting network safeguards, the gateway model will be regarded as a highly favorable approach.

One of the differentiators of Control Concepts’ module development is our attention to module architecture. It is important that the approach taken for module design will address the requirements of typical systems with an eye on future needs for ease of scalability, modification, and enhanced functionality.  We collaborate closely with manufacturers to develop modules that work seamlessly with their products. Control Concepts’ module development process includes a thorough understanding of hardware architecture and processing of the APIs including security requirements required for communication.

To learn more about Adam Hanson, connect with him on LinkedIn!

If you have hardware that needs integration into the AV ecosystem, we can help! Click here to learn more about how Control Concepts helps manufacturers with modules, drivers & plugins development for a variety of control platforms such as AMX, Crestron, Crestron Home, Control4, Elan, Extron, Q-SYS, RTI, and URC.

Talk to an expert