Control Systems

Introduction

This chapter covers the primary components, ICT architecture considerations, and best practices for planning, designing, and deploying control systems for integrated AV systems.
A control system consists of three key components:
  • User Interface is the method of receiving input from, or representing the system status to the user
  • Control Processor would traditionally have been a piece of intermediary hardware bringing together disparate third-party controllable devices as a cohesive integrated whole. This function can now be performed by either hardware or software, and can be server-based.
  • Asset Management is the method of reporting and analytics for maintenance and support purposes
A control system is a network of connected devices and computers communicating over a variety of control interfaces and communication protocols. Automation of the connected devices is managed by a hardware or software processor running control code. The control processor communicates with equipment associated with the AV system and building services by transmitting and receiving commands with third-party controllable devices.
Control communications may be established through a variety of signal types and methods, and the control system must feature the correct hardware or software interface to communicate with any given device. For instance, if a device only features an RS232 port for third-party control, the control system must also feature an RS232 port.
However, with modern server or cloud-based control systems, it is possible to run all the communications over the network using standard managed switching, provided all the devices have either IP control or a device to convert IP control to the correct protocol for the device (eg. RS232).
The following diagram represents the traditional hardware based approach. In a software based system, all devices would connect to the ‘Control Processor’ via IP.

Scope of this Section

This chapter focuses on control systems as it relates to commercial AV integrated technology.
Other specialised control systems such as show control (Midi or SMPTE), lighting (DMX), and industrial mechanised automation are outside the scope of this document. However, ultimately it is possible to integrate any system with the AV control system, where this makes sense.
Reference will be made to integrations with Building Management Systems (BMS) and ICT enterprise solutions as a catalyst for further consideration of what is possible to achieve within an organisation’s systems architecture.

Glossary of Terms

Term
Definition
API
A software program through which software may interact with an AV system component, third-party software, or sub-system.
BMS
Building Management System (BMS) also known as Building Automation System (BAS) is a control system for automating and monitoring a building mechanical and electrical equipment such as ventilation, lighting, power, fire, and security systems
Control System
A control system is a collection of hardware and software components that work together in a cohesive manner to perform a task.
Control Processor
A computer that processes that runs control processor software
Control Processor Software
Custom back-end software running on a control processor
Control Interface
The communication interface port between two AV system components for the transmission of control signals (RS232, IR, Ethernet IP, et al).
Enterprise-grade
Products designed to integrate into an ICT infrastructure with high compatibility with ICT standards, minimal complexity, and remote management support
GUI
Graphical User Interface (GUI) is an interactive user interface presented on an LCD or LED display. Typically touch-enabled and commonly referred to as a “Touch Panel”
IR
Infrared. In AV systems, IR is typically used for one-way control and automation of third-party controllable devices
IP Address
An Internet Protocol Address (IP Address) is used for network communication between computer devices. The IP address allows a device to be identified on the network
LAN
Local Area Network (LAN) is a network of interconnected computers within a building or department
Middleware
Back-end software to unify disparate system components to function as a cohesive whole.
Module
Similar to an Application Programming Interface, a module is a software program for simplifying control processor programming required to communicated with a third-party controllable device
Relay
Contact closure relay is a mechanical switch that activates to complete an electrical circuit which sends a signal to, and causes a third-party controllable device to perform an action in response
RS232;
RS422;
RS485
A telecommunications standard for serial communication and data transmission. In AV systems, typically used for point-to-point two-way control and automation of third-party controllable devices
TCP/IP
A suite of communications protocols to connect computers on the internet and is the standard for transmitting data over networks.
Third-Party Controllable Device
Equipment that features a control interface for receiving and processing control commands and performing the corresponding action
Turing Complete
A system capable of solving any computational problem. Such systems are capable of arithmetic (adding, subtracting, multiplying, dividing, et al), logic (if, else conditional statements), and managing data (store, retrieve, erase)
User Input
An interaction with the control system via the user interface initiated by the end user
User Interface
The method by which the user may tell the control system what to do, and if applicable receive indications of the control system status.
VLAN
Virtual Local Area Network is a logical partition of a physical LAN. Multiple computers may be physically connected to the same network switch, but may be part of various isolated VLANs. Assigning groups of computers to VLANs allows for compartmentalisation and segregation of network traffic and may also improve network security

Key Stakeholders

Below is a list of stakeholders commonly involved in the planning, deployment, and maintenance of a control system solution:
  • AV and ICT Managers (design of integrated technology)
  • End Users (functionality, features, and user experience)

Purpose of a Control System

High-level Objectives:

A short and non-exhaustive list of reasons to use an integrated control system include:
  • simple, consistent user experience for operation of AV systems and their individual components
  • achieving cohesion by integrating disparate AV devices so they perform effectively as a unified system operated by a single user interface
  • integration with building management systems (BMS)
  • integration with Emergency Warning and Intercommunication System (EWIS)
  • achieving energy-saving goals by switching devices off or into standby mode through scheduling and automated processing
A control systems may also be utilised for advanced applications:
  • reporting and analytics for asset management
  • system faults and warning notifications (e.g. text message, email, or log file)
  • integration with room booking system (e.g. session start/end notifications)
  • dynamic and contextual user guide integrated into graphical user interfaces
  • enterprise-grade control processing server software as a centralised ICT architecture alternative to traditional appliance-based control processing solutions

Specific Room Functionality:

Common examples of AV system control found in an educational space:
  • switching a source device to one or many output destinations
  • control of individual source devices, e.g. pan/tilt/zoom (PTZ) cameras, visualisers
  • volume and mute control of audio sources (including microphones) and destinations
  • automatic startup or shutdown of systems based on occupancy and/or schedule
  • lecture recording control and system feedback
  • automated and manual control of lighting and motorised blind systems
  • control of mains power delivery to meet energy-saving goals (e.g. by turning off 240-Volt power to amplifiers at midnight, and restoring power at 7am)

User Interface and User Experience

First you need to define how the users will interact with the AV system. A good starting point is to determine the end user’s competency with technology. Consider the following examples:
  • non-technical end users may need a simple user experience with limited options, and increased automated sequences
  • “power users” may be comfortable with added complexity with extra options and flexible automation preferences
  • technicians may require an additional set of diagnostic functions available to troubleshoot the control system and allow the application of temporary settings for an event or monitoring.
The following are some simple solutions for consideration when looking to meet functional requirements for a user. It is important to understand that there are always multiple ways to meet user requirements, and your control systems strategy will determine the starting point for deciding the most appropriate method.
  • a system with one or two sources may be best achieved using occupancy sensing or scheduling, auto-switching based on signal detection and control directly from the room’s interactive display
  • a keypad/push-button user interface with onboard control processor may be suitable for a simple AV system capable of selecting devices, turning a display on and basic source volume control
  • a touch panel user interface is preferable for an AV system with input switching, multiple output destinations, microphones or devices that require specific control
  • a central server may the appropriate place to control a fleet of small systems based on automated scheduling from enterprise systems and triggers from a BMS that drive actions locally within the room
  • the local touch panel in the room may be augmented by providing a web or app -based version to the scheduled users mobile device, giving them access to a basic set of functionality to control the room just prior to and during their session
At times, specific device controls may exist that are easier to provide via a dedicated device than to fully integrate with an AV system. For example:
  • a pan-tilt-zoom control may be best achieved with a dedicated PTZ joystick or software in a simulation control room
  • a visualier power state may be controlled by system startup/shutdown on a push-button controller, but the device’s on-board fine motor controls are used directly by the user.
  • A dedicated video conferencing control system may provide a better user experience than integrating it with a third-party control system’.
In these types of scenarios, the key consideration is the end user’s experience, a consistent set of controls and tools and an ease-of-use that requires no or minimal explanation.

Third-Party Controllable Devices

Define the quantity and compatibility of third-party controllable devices:
  • Check each device specification and ensure it is compatible to be controlled by a control processor
  • Some devices may communicate using a proprietary control command protocol. If this is the case, these devices may not be suited for third-party control by a control processor
Survey the different control interfaces required for devices within a design. Ensure that they have a way to interface with the control processor.
  • If all devices may be controlled by Ethernet, then the devices and control processor must be accessible to each other on a network. This has become the most common method of controlling devices due to its scalability and flexibility.
  • If the devices of an AV system feature various control interfaces (RS232, IR, Relay, contact closure, et al), these too require a way to get commands back to the control processor. It is common to use control interface expansion devices where a useful AV device does not include an Ethernet port.
  • USB is a common method for control of sub-system elements that interface with a PC (e.g. document cameras, meeting room interfaces, PTZ cameras). Ensure that control considerations include USB functionality and that standards and limitations are understood and tested when designing control systems.
Understand behaviour of the third-party controllable devices. If the behaviour is logical and predictable, then programming and automation of a device becomes more easily managed:
  • If the device ignores incoming messages during its power-up or power-down sequence, make sure any control messages are buffered or delayed until the device is ready to receive messages.
  • If the device has any default modes or settings, make sure these will not impact the operation of the AV system.
  • Ensure the device behaviour is predictable. A sequence of commands may need to be included in the control system software to set the device to a known state.
  • If the device has a sleep timer that puts the device into a standby mode after a period of inactivity, make sure the control system software is able to account for this and only allow a standby state to be managed appropriately whilst maintaining control over the required device.
  • If the device requires a handshake message to initiate communications via its control interface, ensure the handshake message is included for all messages sent by the control system software.
  • If the device requires an open network port to initiate communications via IP, ensure the network port is open and ready. to receive messages sent by the control system software
  • If the device is able to report its current status, ensure the status information is accurate and applicable for the control system software or management suite used.

ICT Architecture Requirements

It is critical to define the network connectivity requirements for the AV systems and components and work with your wider ICT teams. ICT policy may require that AV network traffic be routed, and treated differently to other network traffic:
  • Dedicated VLAN for AV network traffic - AV devices must be connected to specific switch ports for AV VLAN as specified by the organisation’s ICT policy. Subnet is reserved for AV devices only.
  • Converged LAN for all network traffic - AV devices must be connected to specific switch ports as specified by the organisation’s ICT policy. Subnet is inclusive of multiple departments and device categories
  • Strictly no AV network traffic - AV devices must be connected to a dedicated network switch air-gapped from the ICT architecture
It is a requirement to determine the quantity of network-connected devices and required IP addresses for the AV systems. Coordinate with the ICT manager so an IP address range can be allocated for AV devices
Identify which devices require a static IP address and use an IPAM (Internet Protocol Address Management) tool to manage these assignments. At a minimum record this information in a spreadsheet or database of network connected devices
Consider using hostnames as a means of communicating with devices from your control system and determine whether it is a suitable approach to be used at your organisation. Consider the additional services required such as DNS (Domain Name System) as compared to static assignment of addresses and determine if it can improve deployment and support capabilities whilst maintaining a robust control system
Devices requiring a specific network configuration should have very clear instructions, protocols and port details, typically presented in a ‘white paper’. This document should be reviewed by the AV designer and provided to your network teams for review to ensure that device requirements and operation are fully understood.
Identify the network ports used by the AV system. Coordinate with the network teams whenever a device requires a specific firewall or security policy to operate. Present these requirements early on in testing of a new device to ensure that it meets the requirements of your organisation.
Identify which devices require an internet connection to function correctly, assess whether it is definitely required and coordinate this requirement with your network teams

Asset Management, Monitoring and Analytics Requirements

A software dashboard for tracking for AV assets (both devices and systems) which includes:
  • serial, MAC address, asset details
  • specific configuration or location note
  • projector lamp hours, or other consumables
  • warranty status
  • associated support model - e.g. standard, unique or unsupported
  • maintenance history
  • technology lifecycle
  • installation contractor
  • schedule preventative maintenance and servicing
Monitoring and remote support tools of all system components across all AV systems in real-time, providing::
  • network connectivity status
  • in-use / available status
  • vendor-specific remote support client and server application access (e.g. DSP configuration software)
  • real-time notifications for technical support (email, text message, live chat)
  • remote virtual touch panel control of the AV systems
  • remote visual monitoring to reduce unnecessary travel and increase efficiency
  • remotely controllable power distribution units for power cycling
It is also possible to better understand room and technology utilisation through data analytics via the room booking history and AV system usage data, using:
  • room utilisation
  • room bookings/schedule
  • AV system usage data including source usage, touch panel heatmaps and on-times
  • system uptimes
  • system failure rates
Ideally, all of the above functionality is available in a single tool or interface for the various levels of design and support team personnel and management, allowing them the ability to create reports for improved planning and to assess trends with real data to inform design decisions. Where disparate systems are required, care should be taken to minimise data management overhead, and reduce duplication of functions across systems.

Control System Key Components

A control system is generally comprised of the following elements to support a user’s experience within a teaching or meeting space:
  • User Interface - a method for capturing user input or change of state in the user environment, and for providing feedback of AV system status
  • Control Processor - hardware or software to provide automation, computer processing, and communication with third-party controllable devices and systems
  • Asset Management - facilitates maintenance and support by monitoring AV systems and associated components

User Interface Functionality

A user interface should provide, at a minimum:
  • an interactive method for users to operate the AV system by providing user input or occupancy-based triggers
  • feedback to indicate that a user input has been successfully registered with the control system
  • feedback to indicate the current state of the AV system

User Interface Types

Common types of user interfaces for AV systems:
  • touch panel
  • keypad
  • app or web-based control for use with fixed computers
  • app or web-based control for use with mobile device (tablet, phone)
  • sync or hot plug detect (e.g. connecting an HDMI to laptop to turn on AV system)
  • occupancy sensor (e.g. AV system turns on/off based on room occupancy)
  • room booking (e.g. AV system turns on/off based on a schedule)

User Interface Design Best Practice

Best practice guidelines for user interfaces for AV systems:
  • The user interface must meet the specification
  • If required by the specification, ensure consistency by designing user interfaces that are stylistically and functionally matching with the organisation’s current AV systems in operation
  • The user interface should be consistent across multiple systems to help end users become familiar with operating all AV systems on campus
  • The user interface, and behaviour of the AV system must always make the user feel like they are in control of the AV system
  • For each user input, there should be instantaneous feedback to indicate the user input has registered
  • For each user input, there should be an option to reverse (undo) the control system’s response to the user input
  • Use of Icons and text to label user interface elements:
    • An interactive element (press button, connect cable, et al) must be clearly labelled to indicate its associated function
    • A function must be predictable based on the interpretation of the label
    • Always use text, only use icons that suit the text label
    • Never use icons only
    • Avoid using uncommon icons, or text that may be open to interpretation
  • Graphical user interface (GUI) design:
    • On-screen elements must look distinctive to indicate to the user what parts of the screen are interactive
    • Of the interactive on-screen elements, navigation buttons (page flips) must look distinctly different from control buttons (ie volume up, laptop input, video conference dial pad, et al)
    • The user interface should avoid presenting too many options or interactive elements to the user unless such complexity is necessary
    • The user interface should always allow the user to return to a familiar “Home Page” with a single button press
    • A setup page should be included with access restricted to administrators only. The setup page should allow for setting optional variables related to the way the AV system operates. The scope of the setup page must meet specification.

User Documentation

Clear, accurate, and concise user documentation (eg quick reference guides) must be produced for all AV systems that feature a user interface.

Control Processor

A control processor is defined as follows:
  • Computer hardware and software for the automation of AV systems
  • Communicates with third-party controllable devices via a variety of control interfaces and protocols
  • Capable of executing automated sequences of functions
  • Capable of performing logic calculations and conditional statements
  • Capable of triggering functions as a response to user input
  • Capable of triggering functions at a time of day
  • Capable of triggering functions after a delay period has elapsed

Control Processor Type - Appliance-based

  • Most flexible and comprehensive industry standard solution for automation and control of AV systems
  • Optimal control system solution for AV systems composed of disparate third-party controllable devices from various manufacturers with various control interfaces
  • Control processor capable of offline operation whereby all AV system components, and third-party controllable devices are not connected to a LAN
  • Control processor software runs on proprietary control processor appliance
  • Features and functionality largely similar across different control processor manufacturers
  • Adheres to standards-based internet protocol TCP/IP
  • Commonly available control interfaces:
    • RS232 / RS422 / RS485
    • Infrared (IR)
    • Ethernet (control over IP)
    • Relay contact closure
    • General Purpose Input-Output (GPIO)
    • Proprietary control bus
    • Control interface expansion options available

Control Processor Type - Enterprise Server Software

  • Optimal control system solution for large-scale AV system fitouts
  • Control processor requires LAN and/or WAN connectivity to operate. May also require internet connectivity
  • Control processor software may run on enterprise-grade hardware (ie Linux Server)
  • Control processor software may run on on-premises server hardware, or cloud-based server
  • Efficient for large-scale deployment of multiple AV systems based on repeatable design types
  • Remote asset management included as standard (typical)
  • Adheres to standards-based internet protocol TCP/IP
  • Turing complete
  • Commonly available control interfaces:
    • Ethernet (control over IP)
  • Control interface expansion options available

Control Processor Type - Audio Digital Signal Processor (DSP)

  • Suitable control system solution for audio systems and zone control (background music, paging system)
  • Control processor limitations:
    • Capability varies depending on DSP platform
    • Control processor operations execute on user input only (typical)
  • Commonly available control interfaces:
    • Proprietary control bus (platform dependent)
    • General Purpose Input-Output (GPIO)
    • Ethernet (control over IP)
  • Limited control interface expansion options

Control Processor Type - Digital Signage System

  • Suitable control system solution for digital signage systems and connected end-points
  • Control processor limitations:
    • Capability varies depending on digital signage platform
    • Control processor operations execute on digital signage schedule only (typical)
  • Commonly available control interfaces:
    • Ethernet (control over IP)
    • RS232 (control interface on signage media player)
  • Limited control interface expansion options

Control System Programming Best Practice

Best practice guidelines for developing AV control processor software:
  • The control processor software must meet the specification
  • If required by the specification, ensure consistency by copying and modifying template control processor software source code owned by the organisation to suit the specification and requirements
  • Control processing software must execute its functions without delay and without fail when a user input is registered or a scheduled event triggers
  • Control processor software must be composed as simply and efficiently as possible. Software that is more complex than necessary is prone to more faults, slower performance, and extended software development time
  • Control processor software source code must include comments from the programmer to sufficiently describe the software’s intended function and usage. Comments can aide comprehension which can mean any maintenance or feature additions are more easily implemented
  • If a user input causes an automated sequence of functions to execute, only mandatory functions must be included in the automated sequence:
    • Automated sequence mandatory functions:
      • Turn on/off display
      • Signal routing to present selected presentation source (input switching, audio DSP routing, et al)
      • Motorised projection screen raise / lower
      • Motorised lifter raise / lower
    • Automated sequence optional functions (to specification only):
      • Lighting preset recall
      • Blinds open / close
      • Default volume setting
      • Microphone mute / unmute
      • Recording start / stop
      • Video call start / stop
      • Audio call start / stop
  • If a user input sets the volume, lighting levels, or other environmental variables then those variables must not be overridden by an automated sequence of functions.

Third-Party Controllable Device Integration Best Practice

Best practice guidelines for control processor integration with third-party controllable devices:
  • Before sending control commands to a device, the control processor software must ensure the device is ready to receive communications via its control interface. If the device’s ready-status cannot be determined, the control processor software must be able to make a best estimate
  • Two-way communication with a controllable device is preferable to one-way communication. Two-way communication (RS-232, control over IP, et al) may allow the control processor software to monitor and confirm a device’s status in real-time. One-way communication (IR, Relay, et al) strictly means the control processor software can only estimate the device’s status
  • If a device cannot report its status to the control processor software, the software must incorporate a method for tracking the device's status based on previous commands or estimated status based on known device behaviour
  • Modules for controlling third-party devices:
    • Use modules to avoid writing code that has already been written;
    • Use modules to efficiently communicate with third-party controllable devices;
    • Only use modules that have been tested and proven to work;
    • Only use modules that simplify the programming required to communicate with a third-party controllable device
  • If applicable, device presets stored in the third-party controllable device’s memory should be used to recall a device state (ie DSP matrix switching state, or pan/tilt/zoom camera preset). Device presets reduce the control system processor overhead by simplifying the communication between control processor and third-party controllable device
  • If applicable, ensure that limitations are set on a third-party controllable device so that even if it receives a command from the control processor that may exceed the limitation it may ignore the command (eg mechanical limitation for blinds or curtains)
  • If a third-party controllable device is relay-operated, never activate multiple relays simultaneously
  • The control processor software must ensure that no AV system components are damaged as a result of any automated functions executed by the control processor (ie a projector being operational whilst a mechanical lifter is raised, causing the projector to overheat from lack of ventilation)

Building Management Systems Integration Best Practice

Best practice guidelines for control processor integration with building management systems:
  • Building management systems (also known as building automation systems) commonly communicate over dedicated networks using protocols and industry standards such as KNX, CBUS, DALI, et al. A control processor may establish two-way communication with these networks through a communication gateway interface
  • The Emergency Warning and Intercommunication System (EWIS) commonly integrates with the control processor via GPIO contact closure. If an emergency is triggered and detected by the control system, all AV presentations must automatically shut down, and audio playback silenced to ensure the evacuation messages may be heard
  • If applicable, lighting presets may be recalled by the AV control processor by communicating with the building management system
  • If applicable, blinds may be opened or closed by the AV control processor by communicating with the building management system
  • If applicable, the AV control processor may be able to monitor the status of occupancy sensors connected to the building management system
  • If applicable, heating, ventilation and air conditioning (HVAC) may be controlled by the AV control processor by communicating with the building management system

Energy-Saving Best Practice

Best practice guidelines for employing common energy-saving methods:
  • If a switchable power distribution unit is used to switch 240V AC power on and off for connected devices, ensure those devices and their components will not be damaged by repeated power cycles. If required by the manufacturer, ensure the devices are in standby mode before switching 240V AC power
  • Ensure any energy-saving processes only occur when the AV system is not in use, and occupancy sensors do not detect any movement
  • Common methods for detecting occupancy and room utilisation:
    • Occupancy sensor trigger
    • User interaction with user interface
    • User interaction with lighting control interface
    • User interaction with device connected to AV system

ICT Architecture Integration Best Practice

Best practice guidelines for integrating AV control systems with an ICT architecture:
  • If applicable, control system components (control processors and third-party controllable devices) and AV system components must not use manufacturer default administrator username and password

AV System Registration Best Practice

The following best practice and considerations should be considered when registering (onboarding) AV systems with the asset management platform:
  • If applicable, any standards and templates used by the organisation must be adhered to when registering AV systems and/or their individual components (assets)
  • An AV system is commonly referred to by its room name or room number. Ensure the room reference for the AV system matches the building’s room naming conventions as used post-occupancy
  • If the asset manager platform allows registration of individual AV system components (commonly referred to as “assets”) for monitoring and servicing, these components must be named in a strictly consistent manner:
    • Example: If make and model are used to register components instead of their type categorisation (“Amplifier”, “Projector”, et al), then all components must be named according to their make and model
    • Example: Amplifiers must always be registered as “Amplifier”, and not “Amp” or “Power Amplifier”
    • Example: Projectors must always be registered as “Projector” and not “Proj” or “Data Projector”
  • If a device cannot report its status directly to the asset management platform, the control processor software must incorporate a method for tracking the device's status and reporting this information to the asset management platform
Last modified 3d ago