Audio Visual Design Guidelines

Control processor

4 views November 19, 2019 November 19, 2019 aetm 0

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
  • Turing complete
  • Commonly available control interfaces:
    • RS232 / RS422 / RS485
    • Infrared (IR)
    • One-way serial
    • 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 necessary, 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

Was this helpful?