J-2 Orientation Media Programming Narrative.pdf

AV SYSTEMS

CARRIAGE ENTRY

CONGRESSIONAL CROSSROADS

CVC ENTRY

WELCOME AREA

ORIENTATION GALLERY

SHOW CONTROL SYSTEM

Theory of Operation version 1

Document: SN347 LoC - SCS Narrative

Date: August 14, 2023

Attachment J-2

LIBRARY OF CONGRESS AV SYSTEMS SHOW CONTROL SYSTEM

SN347 LoC - SCS Narrative_In Progress Page 2/25

Table of Contents

1. INTRODUCTION

2. ABBREVIATIONS & LEGEND

3. SHOW SYSTEM COMPONENTS

3.1. AUDIO

3.1.1. Q-SYS

3.2. VIDEO PLAYBACK

3.2.1. BrightSign Local 4K Signage Player

3.2.2. Local Media Computers (Origin PC)

3.3. VIDEO RENDERING

3.3.1. Panasonic Projectors

3.3.2. Displays

3.4. LIGHTING

3.4.1. Custom Lighting Assemblies

3.5. FIRE ALARM

4. NETWORK ARCHITECTURE

5. SCS ARCHITECTURE

5.1. CORE ARCHITECTURE

5.1.1. Hardware

5.1.2. Software - ISAAC Workspace

5.1.1. Software - Node-RED

5.2. OPERATION INTERFACES

5.2.1. Housekeeping Computer

5.2.2. Rack Console

5.2.3. Operator Console

5.3. SUBSYSTEMS INTERFACES

5.3.1. GPIO Interface

5.3.2. Serial Interface

5.3.3. IP-Controlled Reboot Device

6. SCS THEORY OF OPERATION

6.1. SCHEDULE

6.2. MANUAL OPERATION & MAINTENANCE

7. APPENDICES

8. Bill of Materials…………………………………………………………………………………………………………………………..…25

SN347 LoC - SCS Narrative_In Progress Page 3/25

1. Introduction In collaboration with Kubik Maltbie Inc, Smart Monkeys Inc. (SMI) has drafted this document to present the design of the “Show Control System” and Audiovisual System Monitoring for the Orientation Gallery, Carriage Entry, Congressional Crossroads, CVC Entry and Welcome Area at the Library of Congress, in Washington DC.

To be concise, the system will be described herein as the Show Control System (SCS) and the property as the Library of Congress, or LoC.

This document, in conjunction with the logical concept diagram(s), system diagram(s), and equipment list, describes the design intent for Audio, Video, and Control systems in the referenced venue.

2. Abbreviations & Legend Below is a list of abbreviations used in this document:

API Application Programming Interface

BGM Background Music

UI User Interface (physical device)

GUI Graphical User Interface

ICD Interface Control Document

MxM Medialon XObject Modules

LLC Medialon Low Level Communicator

LTC Linear Timecode

PLC Programmable Logic Controller

SCS Show Control System

SOD/EOD Start Of Day / End Of Day

Below is a reference to the series of icons that will aid in reviewing this document. These icons will assist with noting areas of the document that have been revised and referencing additional supporting documents.

This section refers to an additional document provided as an appendix or hyperlink.

This section has been updated since the last version of this document.

This section has been added since the last version of this document.

SN347 LoC - SCS Narrative_In Progress Page 4/25

3. Show System Components The following sections contain descriptions of the show elements that will require interfacing with the SCS for either monitoring/telemetry or for show action cueing.

Below is an inventory of show elements.

System Component Interface

Audio Q-SYS Core Network

Video Playback Brightsign 4K Player

Network

Video Playback Origin PC

Video Rendering Panasonic Projectors

Video Rendering Displays 65”

Video Rendering Displays 27” Touchscreen Displays N/A

Video Rendering Displays 55” Network

Video Rendering 86” Touchscreen Table Display Network

Video Rendering Touchscreen Table Network

Video Rendering Touchscreen Display Network

Lighting Custom Assemblies

Controller NUC Network

Power Controller iBoot device Network

Fire Alarm Q-SYS Core Digital Input

Lighting Controller (doorways) TBD TBD

DJ Kiosk Lighting & Buttons Art-NET

Figure 1 – Show Elements Inventory

3.1. Audio

3.1.1. Q-SYS

The audio system is based on a QSC Q-SYS centralized DSP.

The SCS will interface with the DSP (Q-SYS Core) over the network and communication will be based on the Q-SYS ECP API.

The audio DSP programmer will coordinate a list of “Named Controls” with the SCS programmer which will be used by the SCS for both monitoring and control.

Q-SYS core (and other components such as amplifiers) will publish key metrics to the SCS as variables (e.g.; core status, temperature, network errors…). A dedicated user interface will allow the user to create alerts which will be triggered whenever a variable value is out of a predefined range.

SN347 LoC - SCS Narrative_In Progress Page 5/25

A sample naming convention table for named controls is available online in the appendices, see SN347 Q-SYS Named Controls V1.xlsx.

There are two types of Audio Playback devices used in the various experiences:

3.2. Video Playback

There are 2 types of video players in the Venue:

3.2.1. BrightSign Local 4K Signage Player

Brightsign players will be used on local displays and projectors.

Control:

Brightsign players will be controlled by the SCS over ethernet using a UDP messages.

3.2.2. Local Media Computers (Origin PC)

Media computers will be interfaced with the SCS on both hardware, operating system, and software level.

Hardware & OS Layer

Monitoring of Windows based computers hardware and operating system will be accomplished via ISAAC® Workspace. Communication with the computer is established through Telegraf ®.

The following datapoints will be available in ISAAC variables page:

• Temperature

• Disk usage

• Memory usage

• CPU usage

• CPU temperature

• GPU temperature

The following controls will be added on the SCS user interface:

• reboot computer

SN347 LoC - SCS Narrative_In Progress Page 6/25

Application Layer

Control & monitoring of applications developed by Blue Cadet will be accomplished via ISAAC® Workspace. Communication is based on Blue Cadet Rest API. The list of datapoints and controls will be defined during the SCS design phase, below are examples:

Typical Monitoring datapoints:

• Application State (healthy/error/…)

• Application Mode (playback/idle/…)

• Current project file

• Uptime

• Framerate

• App build version

Typical Control commands:

• Load Project

• Restart default project

• Play Media or Sequence

3.3. Video Rendering

3.3.1. Panasonic Projectors

Panasonic projectors will be controlled by the SCS over ethernet using PJLink protocol available online here and in the appendices.

Control:

Typical SCS commands on projectors are power on/off linked to the SOD/EOD sequence as well as shutter open/close. Additional commands may be implemented during show programming.

Monitoring:

Typical SCS monitoring & telemetry points will be error(s), fan(s), lamp(s), temperature(s), filter(s). A dedicated user interface will allow the user to create alerts which will be triggered whenever a variable value is out of a predefined range.

https://pjlink.jbmia.or.jp/english/data_cl2/PJLink_5-1.pdf

SN347 LoC - SCS Narrative_In Progress Page 7/25

3.3.2. Displays

Touchscreen and signage displays, showing locally distributed content will be controlled by the SCS;

APIs, where applicable, are to be exposed through the design phase :

• ELO 2702L 27” HD Touchscreen (QTY 3) In OG AV.03 (10) Jefferson Library

• LG 65UH7J-H UHD 65” LED Display (QTY 2) In Collection Slideshow

• ELO 2072L 27” HD Touchscreen (QTY 1) in OG AV.07 Mixtape

• LG 55UH7J-H UHD 55” LED Display (QTY 2) In AV.04 Digital Signage

• IDEUM 86” Inline Open Frame Touch Table (LG 86” Display) In OG AV.01 Ask a Librarian

Control:

Typical SCS commands on displays are power control and input selection linked to SOD/EOD sequences.

Additional commands may be implemented during show programming. *

Monitoring:

Typical SCS monitoring & telemetry will be EDID configuration, Input selection, fault and error codes. *

*NOTE – ELO 27” touchscreens do not support any external control or monitoring interfaces and will be completely “stand-alone” devices.

3.4. Lighting

3.4.1. Custom Lighting Assemblies

KM will develop and prototype a DJ style mixer pad with sixteen rubberized buttons that illuminate via LED lighting from below the buttons. The pad will send user input information to the PC via MIDI protocol. KM will build a custom fixture panel that will hold the lighting and button assembles and integrate into the final kiosk unit. We assume the control box will be integrated into the kiosk or under the kiosk main touch surface. We assume communication with the lighting will be via Art-net communication from the media supplier.

KM will develop a system with off-the-shelf components that utilizes a control box to power LED strips around seven arched doorways. Controller/control box will be local to each zone and can connect via ethernet or USB. Lighting effect will be programmed to run a sequence throughout the day. KM will also custom fabricate a cover over the LED strip that fits around the doorways. KM assumes this will be built into the custom fit out of millwork added in the doorways.

This activity will only be set up as a preprogrammed lighting effect.

SN347 LoC - SCS Narrative_In Progress Page 8/25

3.5. Fire Alarm

The SCS will receive relay contact closures from the Fire Alarm system through an ethernet digital input interface (see section GPIO Interface)

SCS Response

In the event of a Fire Alarm, the SCS will display a message on the UI and will disable further SCS actions/cues on that zone. The Fire Alarm will be logged. Browsing the user interface will still be possible even though certain actions may not be operational.

Video Response

The SCS will trigger the appropriate commands on video equipment in order to set the LED, displays and projectors to black. If regulation requires that one of these display a specific piece of media, the video systems shall be programmed to expose a permanent cue/preset that will be triggered by the SCS.

Note: The SCS is not type 1 rated and thus can only send courtesy commands to the video subsystems, if video mute (or specific media) is a code requirement, then this must be handled by the video system.

Audio Response

The audio system shall respond directly to the Fire Alarm signal and is NOT under the SCS scope.

Lighting Response

The lighting system shall respond directly to the Fire Alarm signal and is NOT under the SCS scope.

Note: When the Fire Alarm is cleared, the user interface(s) will be enabled, however playback on audio/video systems must be manually resumed by the venue operators.

SN347 LoC - SCS Narrative_In Progress Page 9/25

4. Network Architecture

AVC System Network

• We recommend the AVC System Network to live on a dedicated network, separate from the Library administrative network.

• The AVC System Network may eventually be subdivided into separate VLANs and or Subnets, as required.

Gateway Interconnection

• The AVC System Network boundaries (Internet and eventual interconnections with the Library’s networks should be protected by a firewall.

• We recommend the planning of a local secured interconnection between the AVC System Network and the Library Networks to grand access where needed to the Library Operators to the AVC System Network for daily operations.

• Subnets for the AVC System Network shall ideally be provided by Library IT; this will facilitate firewall configuration.

Internet Access

• The AVC System Network shall have a dedicated Internet access with a public IP address from the first day of integration.

• As the internet connection will support content transfer, it must support a minimum data transfer rate of 100 Mb/s upload and download.

Remote Access

• Remote access with VPN shall be planned for remote integration and support.

SN347 LoC - SCS Narrative_In Progress Page 10/25

LIBRARY NETWORK

AVC DEDICATED NETWORK

VPN

AV INTEGRATOR

LIBRARY OPERATOR

AUDIO

VIDEO

LIGHTING

CONTROL

INTERNET

Figure 2 – Network Topology

SN347 LoC - SCS Narrative_In Progress Page 11/25

5. SCS Architecture The SCS will rely on Node-Red software running on an ISAAC server.

CONGRESSIONAL CROSSROADS

ISAAC®

NATIVE SERVICES

CONTROL

USER

MANAGEMENT

LOGS AND

ALERTS

USER

MANAGEMENT

SCHEDULING

CMS

HOSTED SERVICES

SHOW

CONTROL

(Node-RED)

MEDIA PLAYERS

DISPLAYS

iBOOT

MONITORING

CONTENT MANAGEMENT

LIBRARY OPERATOR

CVC ENTRY

MEDIA PLAYERS

DISPLAYS

iBOOT

WELCOME AREA

MEDIA PLAYERS

DISPLAYS

iBOOT

ORIENTATION GALLERY

MEDIA PLAYERS

DISPLAYS

iBOOT

CARRIAGE ENTRY

MEDIA PLAYERS

DISPLAYS

iBOOT

Figure 3 – Show Elements Inventory

SN347 LoC - SCS Narrative_In Progress Page 12/25

5.1. Core Architecture

5.1.1. Hardware

The hardware foundation is built upon an ISAAC Prelude Cluster, which is a server virtualization platform from Smart Monkeys, Inc. A physical server running a hypervisor will make up the physical aspect of the virtual cluster. The cluster may contain multiple virtual machines (VMs) running operating systems such as Microsoft Windows or Linux. This will allow efficiency by running multiple virtual machines on one enterprise-grade server platform.

Figure 4 – ISAAC® Prelude 210 (1 Host)

High Availability (Optional)

The goal of the HA architecture is to achieve high availability by defining two fundamental resiliency objectives that address common failure points. Specific industry leading resilient technologies are implemented to meet each objective to provide a next-generation control system.

These resiliency objectives are:

• Device resiliency – Prevents a hardware device from causing a failure of the respective subsystem, such as a network switch supervisor, virtual host hypervisor, or storage failure.

• Operational resiliency – Allows continued availability of the control system during planned maintenance such as software updates, routine maintenance, and operational programming.

Figure 5 – ISAAC® Nemesis 610 Cluster (2 Hosts + 1 SAN)

SN347 LoC - SCS Narrative_In Progress Page 13/25

The use of ISAAC’s virtualization technology will allow the software components of the system to operate with a layer of abstraction from the hardware. This will prevent a server hardware failure from affecting the overall system operation.

ISAAC hardware is scalable in both memory and storage for future upscaling if necessary.

5.1.2. Software - ISAAC Workspace

The ISAAC Workspace used for the Venue Control System is a web-based interface designed to consolidate disparate systems into a holistic user experience. It combines user access and roles, logging, alerting, embedding control panels, and scheduling in an easy-to-use yet flexible manner. The ISAAC Workspace is also noted for its flexibility in accommodating other subsystems, allowing them to publish items that can be scheduled, variables to be alerted on, and control panels to access their interfaces more directly. The ISAAC Workspace is the starting point for any non-field device interfaces.

ISAAC Home Page

System Administration and Security

The ISAAC Workspace can facilitate user authentication for all the remote panels, either through the Workspace itself or through a custom PIN. The Workspace is built around the concept of roles. This allows the system to be intelligent enough to recognize specific users in specific locations and tailor custom web interfaces to them even if the interface is not directly served by the ISAAC Workspace.

SN347 LoC - SCS Narrative_In Progress Page 14/25

User Accounts

The SCS will authenticate access by identifying and verifying a user (a person or another application) according to details held in their user account.

An SCS user account has the following properties:

• Represents one user of the SCS

• Holds a username and password

• Is applicable for that workspace

• Cannot have sub-users

Access rights can be specified for each user account. However, to simplify management we recommend that access rights be assigned to group accounts. Assigning access rights for each individual user quickly becomes very difficult to manage.

Group Accounts

Group accounts will contain collections of users. These will be used to simplify management as a change in the access rights assigned to a group is automatically applied to all users in that group. A user will not have to belong to any group but may belong to several. You can define the access rights for all group members.

A group has the following properties:

• It represents a group of users with common access rights

• Is applicable for that workspace

• It can have members

Access Rights

The SCS will use Access Rights to control access to specific areas of the repository, user interfaces and features. This shall be done by assigning privileges to either allow or deny access to a resource in the repository or user interface. As various privileges can be assigned, they must be evaluated to determine which combination is applicable for the current request. The SCS allows you to configure the access rights for both user and group accounts. The same basic principles of evaluation will then be applied to both.

The ISAAC Workspace also exposes an interface allowing the system administrators to view and manage all of the VM’s residing within ISAAC. The VM’s can have snapshots taken, be rebooted, and view their overall resource usage.

SN347 LoC - SCS Narrative_In Progress Page 15/25

Platform Monitoring

The ISAAC Workspace has a dedicated page for monitoring and controlling status of VMs. Users with appropriate rights can read CPU load, Memory load, disk space, and uptime of each VM. It is also possible to change the power state of a VM (start, shutdown, suspend, reboot) as well as create snapshots.

Figure 6 – ISAAC Platform Monitoring Page

SN347 LoC - SCS Narrative_In Progress Page 16/25

Logging

The ISAAC workspace has built-in logging functionality that any subsystem can write to. This log allows for presets to be created based on tags, text search, and date for quick access to specific log views of all log messages sent to and generated by the ESS and SCS.

Figure 7 – ISAAC Action Logs Page

Alerting The ISAAC Workspace allows for users to be alerted when a subsystem has a fault or is operating outside of normal conditions. The alert will appear as a notification in the ISAAC Workspace and can be configured to send a message to relevant users or groups via email, MS Teams, Slack, or other providers using webhooks. There are two different life cycles for Alerts within ISAAC: Notify Only and Action Required. If Notify Only” is selected, it will notify all relevant users as a pop-up notification, then disappear. If Action required is selected, an operator must manually clear the alert once the issue has been resolved.

Figure 8 – ISAAC Variables Page

SN347 LoC - SCS Narrative_In Progress Page 17/25

Control Panels

Control Panels are what bring the most flexibility to the ISAAC workspace. A control panel can embed any webpage, Remote Desktop Connection, VNC connection, document, and various other programming environments. The result is a user having quick links to all the information they need, just a click away.

Any of the custom panels, monitoring data views, or control interfaces can be easily accessed as a Control Panel.

Figure 9 – Typical Control Panel

SN347 LoC - SCS Narrative_In Progress Page 18/25

Scheduling

The ISAAC Workspace offers a very powerful scheduling feature that goes beyond the standard way of managing a wide array of AV systems. The capability of its internal scheduling processes allows AV devices to be programmatically triggered at a specific time. This feature allows non-programmers to manage schedule elements in an easy, user-friendly interface.

Figure 10 – ISAAC Schedule Calendar View

SN347 LoC - SCS Narrative_In Progress Page 19/25

5.1.1. Software - Node-RED

Originally developed by IBM, Node-RED is a NodeJS-based programming environment designed to facilitate the flow of data between systems. It excels at providing ease of programming, stable operation, and simple deployment. While it can create simple to complex web-based user interfaces, it is strongest as the ‘glue’ that links systems and communication together. It has been embedded in PLC systems as an easy-to-approach programming environment and used extensively for large-scale IoT operations.

Figure 11 – Node-RED Programming Workspace

SN347 LoC - SCS Narrative_In Progress Page 20/25

5.2. Operation Interfaces

5.2.1. Housekeeping Computer

Operator interfaces for the system will usually consist of touchpanels, with custom-designed user interfaces representing the most common functions required, however it is anticipated that the SCS will be equipped with a “housekeeping” computer in the IDF or control room as well. This is a single rack height rackmount PC computer, with a folding keyboard, monitor and touchpad, offering a greater level of user-defined and password protected access to setup menus, scheduling options, maintenance and incident event clearing and other special functions. This offers yet another entry point, in addition to user touchpanels and remote access for operators and administrators to easily access all the necessary functions of the SCS system when physically on site.

The operation of the system is facilitated by an onboard KVM system to assume and relinquish command, and the stowage when not in use provides on unobtrusive and secure level of protection and tamper-resistance.

5.2.2. Rack Console

A rack KVM console will allow the system operator or maintenance team to operate and troubleshoot the SCS within the rack room.

Figure 12 – Typical Rack KVM console

5.2.3. Operator Console

The operations and control systems monitoring afforded through the ISAAC platform, as well as the system alerts generated by this system are intended to be integrated to an operator console function, allowing remote surveillance of system functions, and receipt of warnings requiring immediate action.

Warnings and alerts sent to an operator console will be differentiated by severity, with a simple caution or informational message displayed briefly, and a more urgent warning remaining on-screen until positive action allows the warning to be cleared.

Smart Monkeys will provide training and configuration assistance to ensure the operators from the pertinent role assignments will be able to remotely join the supervisor system from anywhere to issue commands as appropriate, and to organize the necessary intervention in the case of system events or alerts.

SN347 LoC - SCS Narrative_In Progress Page 21/25

5.3. Subsystems Interfaces

5.3.1. GPIO Interface

Where digital IO communication is required, the ethernet to GPIO interface shall be the type below:

ControlByWeb X series. Datasheet is available online here and in the appendices.

Figure 13 - ControlByWeb X-401-E (PoE)

5.3.2. Serial Interface

Where RS232 or RS485 serial communication is required, the ethernet to serial interface(s) shall be the type below: Moxa nPort P5150A. Datasheet is available online here and in the appendices.

Figure 14 - Moxa NPort P5150A

5.3.3. IP-Controlled Reboot Device

Where device monitoring faults indicate a reboot is indicated, this functionality shall be achieved through the Dataprobe iBoot G2 device. Datasheet is available online here and in the appendices.

Figure 15 – Dataprobe iBoot G2 https://www.controlbyweb.com/x400/x-400_users_manual.pdf https://cdn-cms.azureedge.net/getmedia/9031ddce-440b-4a3e-a0df-139603bfb72c/moxa-the-security-hardening-guide-for-the-nport-5000-series-tech-note-v1.1.pdf https://dataprobe.com/iboot/ https://www.controlbyweb.com/x401/

SN347 LoC - SCS Narrative_In Progress Page 22/25

6. SCS Theory of Operation

6.1. Schedule

It is assumed that the AV program material will run essentially on a “continuous” or “on demand” schedule, the difference being a show sequence that repeats continuously, or at regular intervals, as opposed to a sequence that is initiated by an operator, or by an automated cue, triggered by visitor input.

In either case, the daily schedule will be characterized by a “Start of Day” sequence and an “End of Day” sequence, during which all equipment is brought on-line and into a ready state at the start of the day, and to a state of inactivity at the end of the day. (see sec. 4.5, “SYSTEM”).

Figure 16 – ISAAC Schedule Page

The schedule page will allow the user to define the “Start of Day” and the “End of Day”, as well as the sequence to be played continuously or on cue for each of the attraction zones. The SOD and EOD times, as well as the sequence schedules may be defined independently for each day of the week, as well as individually for a special day or show.

SN347 LoC - SCS Narrative_In Progress Page 23/25

6.2. Manual Operation & Maintenance

In addition to the advanced scheduling capabilities of the ISAAC system, ample consideration is given to ease of use in manual operations through a manual operations page. It is anticipated that museum operations will most often be concerned with continuous sequences defined by the “Start of Day” (SOD) and “End of DAY” (EOD) sequences, however the manual operations page can be configured with any sequence, function, (Start, Stop, Resume, Next, Previous) as well as diagnostic TEST and curative REBOOT functions. These functions and sequences may be programmed-in at the time of commissioning, and easily upgraded at a later time if the need for a different manual functionality should arise.

Figure 17 – Operation Page Wireframe

SN347 LoC - SCS Narrative_In Progress Page 24/25

7. Appendices Below is the list of additional documents related to this report.

Description File Name

Q-SYS Named Control Template SN347 Q-SYS Named Controls V1.xlsx

ISAAC User Manual SN347 ISAAC User Manual

ISAAC Data Sheet SN347 ISAAC Data Sheet

Q-SYS Named Controls Reference SN347 Q-SYS Named Controls V1.xlsx

PJlink Resources PJLink_5-1_Protocol.pdf

Control By Web Digital IO Resources ControlByWeb_x-400_users_manual.pdf

Figure 18 – Appendices Table

SN347 LoC - SCS Narrative_In Progress Page 25/25

8. Bill of Materials Below is a provisional Bill of Materials for the above scope.

System Qty Manufacturer Model Description

Show Control

1 ISAAC P210 Prelude 210 - Show Control hosting platform

1 ISAAC P210-XC 5-year software/hardware/support full coverage for P210

1 ISAAC 1920L-WVR VM-ready package (Windows 10 Pro license pre-installed in a VM)

1 DELL R3930 Housekeeping computer

1 RARITAN Rackmount KVM drawer

1 CONTROLBYWEB X-401-E Ethernet to GPIO interface (PoE)

1 PFSENSE

NETGATE 6100

BASE Firewall VPN Router

1 PFSENSE 1U Rack Mount Kit 1U Rack Mount Kit

NETGEAR AV Series Network switches (selection by Kubik)

Options

1 ISAAC N400 Nemesis 610 - Show Control hosting platform w/ HA

1 ISAAC N400-XC 5-year software/hardware/support full coverage for N400