Building Automation for Modular Structures

Contents:

It's 2017 and the Internet of Things (or IoT) paradigm is now the driving force in the automation industry. Historically, there have been dozens of proprietary approaches taken to automation, all looking to achieve more or less the same goals. The Internet of Things has enabled the industry to standardize on ubiquitous interconnection technologies and protocols, and to eschew proprietary solutions, driving down cost and greatly enhancing flexibility. We cannot predict the future but we can say with great certainty the future will be networked via TCP/IP, Ethernet, and CAN-bus.

ICE-9 is an next-generation distributed` building automation system built upon the IoT standards which have been universally adopted by industry players such as IBM, AT&T, Intel, Google, and Amazon just to name a few. ICE-9 combines highly successful hardware platforms for advancing quick development with the most successful software framework for interconnecting resources on any scale to create a system which has unsurpassed flexibility, adaptability, openness, and customizability.

The ICE-9 system is not tied to singular vendors, is exceptionally efficient, exceptionally flexible, and is as future proof as possible. If the customer wants it, we’ll connect it.
 ICE-9 Design Philosophy, Objectives, & Notes: This system design meets several objectives:

•  Minimize design time
•  Minimize cable requirements in terms of both total length and varieties
•  Minimize installation requirements
•  Minimize system cost
•  Minimize support cost
•  Minimize operational cost / energy consumption
•  Minimize prerequisite knowledge for programming & reconfiguration

•  Maximize reliability 
•  Maximize serviceability  
•  Maximize flexibility & reconfigurability 
•  Maximize information security 
•  Maximize hacker resistance 
•  Maximize efficiency of resource usage once installed
•  Maximize interoperability with ecosystems & devices from other vendors
•  Maximize use of open standards and open source tools
•  Maximize manufacturability
•  Maximize design lifespan
•  Maximize the number of people who can design future components for the system

Design time is minimized through the use of standardized system core modules which are based on ARM processors and programmed through widely adopted development environments with ubiquitous support in the STEM world. The bulk of the sensing and control resource nodes are based on the Teensy 3.2 platform which makes use of efficient ARM Cortex M4 micro controllers with integrated CAN-bus controllers. This platform allows the Arduino Integrated Development Environment to be utilized to customize behavior of individual modules. More computation intensive modules with video output are based on the Raspberry Pi 3 single board Linux computer with additional IMS circuitry and open source tools from vendors such as IBM.

All modules are joined via RJ-45 cabling which provides both data and power, resulting in a scenario where modules are simply plugged into each other to create a finished system. As the needs for a building change, its functionality can be changed on a module by module basis without having to enlist a contractor to reengineer the system. Standard Cat5 Ethernet cable is used for module interconnection. This allows all cables to be pre-tested, color coded, and available from stock at almost any cable vendor. The rest of the cables in the system are all standard HDMI, Ethernet, USB, DMX, or TOSlink. No proprietary connectors are used.

The use of an in-house designed system allows IMS to deliver exactly what is required for the application. The granularity provided by ICE-9 allows any subsystem to be addressed individually and to be configured to exactly what is required by the application. If that application is redefined or the needs change, the system may be easily reconfigured to fit the new needs without re-engineering. 

Each module uses a standardized design, most requiring zero configuration. Software configuration is not required by any building resource module and for modules such as lighting controllers where are you could conceivably have more than one zone of operation, a small rotary switch allows the zone to be selected with a small screwdriver. Individual modules maybe replaced by service personnel in minutes from a standard parts stock or even cannibalized from another location in an emergency. No system reconfiguration is necessary. All modules contain self diagnostics and functionality that allows a system hub to monitor their healthy operation.

By providing centralized monitoring and control of energy consumption, energy expenditures can be reduced or eliminated.

All system components are designed for robust, high reliability operation and long life. A system monitor constantly scans all devices in use and will summons maintenance at the first indication of trouble, proactively eliminating downtime or occupant discomfort.

Because all system components are joined with modular wire connections, the resources in any given building may be redefined at moments notice and almost without restriction. At the top level all system switches and sensors become inputs and all devices which perform work become outputs. The building engineer has complete flexibility to draw any association between any input and any output as well as the ability to add timers, counters, and other logic. These configurations may range from a simple system like a switch controlling a lighting fixture all the way to a complex scenario where that light is also controlled by a schedule on a timer and affected by occupancy sensors with the additional capacity to be remotely controlled and monitored.

Data is kept secure by making it physically inaccessible. All CAN-bus connections remain inside the locked structure, inaccessible from the outside. Ethernet is delivered to the structure through hard conduit, making unauthorized access exceptionally difficult. No secure data is transmitted over insecure RF links and no RF links are used in most system configurations.

With programming, ICE-9 will integrate with Apple’s Home Kit. This provides access to a great number of third-party solutions including door locking systems which have already been vetted by Apple. 

ICE-9 integrates with the system hubs from a number of other vendors including the Amazon echo, the Google whatever you call it, and IKEA’s Tradfri hub for home automation components. This provides access to a great number of third-party solutions such as voice control, (insert Tradfri components here).

 ICE-9 Architectural Overview: ICE-9 leverages the power of three principle technologies; the Internet, Node Red, and CAN-bus. At its most basic level, you can think of ICE-9 as a collection of building resources connected to a CAN-bus network in each room, monitored and controlled via Node Red software. Node Red is then connected to the Internet for remote monitoring and control. While most people are familiar with the Internet, Node Red and CAN-bus may be new. Node Red is a graphical drag-and-drop software environment for interconnecting resources on any scale which is powered by Javascript, the language that literally runs the web. Written by IBM's emerging technologies division, Node Red was placed into open source and now enjoys adoption across the industry by players as large as AT&T where it forms the basis of their IoT offerings. Node Red allows a building engineer to construct control programs in minutes using a graphical interface which used to take weeks of work from an expensive and specialized programmer.

CAN-bus is a worldwide standard for industrial automation networks which controls cars, refineries, operating room diagnostic devices, elevators, industrial robots, Boeing and AirBus airplanes, and new NASA spacecraft among other uses. Thanks to its high reliability, CAN-bus has become the dominant local control network in industrial automation, replacing countless proprietary approaches. CAN-bus adds a level of the invisible fault tolerance, ensuring that all communications reach their destinations.

CAN-bus uses a daisy chained topology where each device is plugged into the next device in-line. In a typical installation this network would encircle the perimeter of the room, interconnecting all of the resources. In the ICE-9 implementation of CAN-bus, up to approximately 50 devices may be connected together on a single segment of cable which may be up to 200 m long. If more than 50 devices are required, CAN-bus hubs may be used to interconnect multiple segments of cable to accommodate those additional devices. IMS presently has designs for both two and four port hub devices which should accommodate all foreseeable installations, providing support for 200 devices and several hundred meters of cable in a single net. Multiple hubs may be used to expand capabilities even further. 

One of the devices in each CAN-bus network is a more powerful computer based on the Raspberry Pi 3, a quad core 1.2GHz ARM based system running Linux. This computer runs the Node Red software as well as providing a number of other higher-level services. Typically for a classroom or other media rich configuration there will be one Pi-based node controlling every room. For economy or to accommodate unforeseen needs it is possible to connect up to 16 rooms per Pi using hubs. Architecturally, each Pi can support up to 16 lighting zones or 16 HVAC zones maximum. Many vendors utilize RF communication for interconnecting their sensing and control networks. RF communications bring with them a great number of downsides. RF is susceptible to interference so proper operation cannot always be assured and all data is available for public reception necessitating extreme care and complexity when it comes to data security in the design. RF Systems are always more open to hacking and disruption and as time goes on the RF spectrum will only become more and more congested. When utilizing a radio connection power must still be supplied via wires so cable savings between wired and RF systems may be trivial while the potential reliability of an RF system is considerably less. 

For these reasons ICE-9 is principally a wired system although it supports a wide array of wired and wireless technologies transparently. ICE-9 is interoperable with Ethernet, Bluetooth, Wi-Fi, and 315/488 MHz RF which is utilized by a number of systems from Philips’ HUE lighting to Samsung’s StartThings line to home automation devices from a number of vendors. 



ICE-9 includes architectural compatibility with future ZigBee 802.15.4, Z wave, or other RF interfaces if these ecosystems are desired. 

Under the hood an array of additional technologies including ARM, Javascript, Node.js, JSON, MQTT, and many others do the heavy lifting to enable a uniquely powerful system. 

Internally, this system makes use of IBM’s MQTT protocol for message transport and IBM's open source Node Red product to provide complex high-level control. MQTT and Node Red have been adopted as standards by IBM, AT&T, and many other organizations as the core of their Internet of Things technologies. Most large vendors are adding subscription database cloud services to their IoT offerings, however IMS provides this database functionality as an inherent part of the system; built-in. This database functionality allows for logging of all environmental parameters and energy monitors. Bridges to both BACnet IP and WWW are provided for remote monitoring and control. At a speed of 1 Mbit/s, a maximum cable length of about 40 meters (130 ft.) can be used. This is because the arbitration scheme requires that the wave front of the signal can propagate to the most remote node and back again before the bit is sampled. In other words, the cable length is restricted by the speed of light. A proposal to increase the speed of light has been considered but was rejected because of its inter-galactic consequences. Other maximum cable lengths are (these values are approximate) – 100 meters (330 ft) at 500 kbit/s 200 meters (650 ft) at 250 kbit/s 500 meters (1600 ft) at 125 kbit/s 6 kilometers (20000 ft) at 10 kbit/s ICE-9 Core Module, Raspberry Pi, & Customization: Designing an automation system for use in buildings with a 100 year service life requires careful consideration of all of the technologies involved. Most electronic components have a lifespan which is defined by their use, however some components have a lifespan defined by their age. IMS avoids the use of as many of these age-defined technologies as possible however the use of one of these technologies is simply unavoidable, that being Flash memory. In Flash memory, the device itself has a lifespan which is defined by use however the data contained within it has a lifespan defined by the elapsed time since the data was written. Almost all embedded processors today utilize Flash memory for firmware storage and while Flash is a mature technology that we rely on everywhere, it should be realistically categorized as long term temporary storage which in time will forget its contents unless they are refreshed.

Flash memory utilizes microscopic pieces of electrically insulated silicon to store data as electrical charges. Depending on the technology used to fabricate the Flash memory cell, these charges may last anywhere from 15 to 100 years under ideal circumstances. Elevated heat or atomic scale defects in the chip reduce that data retention time. In general, electronics today will have a service life which is shorter than the retention time of the Flash memory used within them so this lifespan issue isn’t considered in most designs. Because our products are built to last a century, we have no choice but to treat Flash data integrity like no other builder and to solve the Flash data lifespan conundrum in our automation components.

Sensor and actuator automation nodes are built from a common core electronics module based on the ARM Cortex M4 processor, a relative the processor that powers iPhones and countless other electronic devices. This core module actually contains a pair of ARM processors, each with the ability to load data into the operating firmware memory of the other one. One of the two processors connects to the IMS CAN-bus, sensors, and other external hardware and is in charge of the operation of the node. A second, much smaller processor is charged with the task of insuring the primary processor’s operating firmware is in tact, and reprogramming it if necessary. The primary processor is able to check and reprogram the second processor if necessary as well.

Flash is difficult to optimize for data retention when it is fabricated on the same silicon die as a high-performance, low-power CPU. In typical consumer applications this doesn't pose any sort of issue as 15 to 20 years of retention is typical however Flash may retain data for 100 years or more in chips which are optimized for storage. To address this retention issue we add a separate Flash memory device to the design which is optimized for data retention and characterized with a 100 year retention time while also being large enough to contain quadruple redundant copies of all operating firmware to allow for fault tolerance. 

Once per decade, all nodes in the system undergo a flash memory refresh procedure to ensure that they will be reliable for the next decade and beyond. This feature differentiates IMS automation components from all other known automation systems.

To enable fast prototyping, the core module may optionally be built using a pre-programmed version of the second ARM which contains the PJRC Teensy Bootloader. This renders the core module compatible with the Teensy single board computer product line and programmable via the Arduino IDE. Once a prototype is completed. 

This approach also leverages the scale of economy used to build these two computing platforms and reduces manufacturing requirements for IMS modules. The bulk of the IMS modules’ circuitry consists of I/O components to connect these computing cores with the outside world. Both of these core modules use ARM processors. One is better suited to provide the intelligence of individual building functions while the other is better suited to providing higher-level services. Ice core circuit description: The Ice-9 embedded automation core module includes a large number of features in a very small package. The following bill of materials table lists all of the components used in the core module, their function, and criteria for choosing the specific devices used. The major challenges include creating a design which can be built as (1) just to the application ARM processor, (2) the application ARM plus an integrity and reprogramming ARM, or (3) the application ARM processor with a Teensy boot loader. Option (1) covers typical building automation system deployments. Option (2) covers long life, high integrity installations. Option (3) allows for firmware development using the Arduino integrated development environment. Embedding the Raspberry Pi for IMS All the higher level functions of this automation system such as running Node Red, CAN routing, serving web pages, or providing video output are handled by nodes based on a single board computer running Linux; the Raspberry Pi 3 Model B. While initially intended as a computer for the educational market, the Pi has now been adopted by major manufacturers as an embedded Linux computer module for production use in high end consumer and professional grade electronics. Companies as large as NEC are now using the Pi core for intelligence in new products. The Pi 3 Model B (shown to the right) comes as a bare motherboard which requires a couple additional resources to become a full fledged computer and a couple more to be an effective embedded core controller for an automation system. The cost of these additional components is trivial when compared to the savings provided by taking advantage of the Pi’s scale of economy in manufacture and enormous development community. The Pi is presently the number one computer in education and it enjoys worldwide support on grand scale throughout the STEM community. The I/O capabilities of the Pi and it's open source operating system provide an ideal foundation for a powerful embedded controller. Code for the Pi can be written in JavaScript, C, Python, PHP, or a plethora of other languages. Adding IMS Peripherals Using the Pi as a building block allows an exceptional amount of intelligence and capability to be built into the system at a cost which is comparatively trivial but it does require some adaptation to meet IMS’ needs. To utilize the pie as a building controller, a small selection of additional peripherals is necessary. The first of these peripherals is a CAN-bus interface for communication with ICE-9 modules throughout the structure. A typical example of a CAN-bus peripheral expansion “hat” for the Raspberry Pi is shown to the right. This example uses different connectors for the bus than the IMS solution and is situated such that only a tiny heatsink may be used on the CPU or Ethernet/USB controller. Therefore, off-the-shelf products with this physical configuration are not suitable for production use by IMS however the circuitry required to implement this function is fairly trivial. The second additional peripheral required is in an uninterruptible power supply system with a long standby lifespan and zero danger of the ignition. This is necessary in order to ensure that the Pi, which is a Linux computer, is able to perform a clean shutdown in the event of power loss. There are multiple technologies available to use in a UPS design however most of them have serious downsides. Nickel metal hydride batteries have short lifespans with only moderate energy density and they are prone to leakage. They're not an option. Lithium polymer batteries have wonderful energy density however they experience substantially shorter lifespans when maintained at full charge and their lifespan can be measured in the low hundreds of charge/discharge cycles even when used as intended. Lithium polymer batteries also have serious issues with fire. These issues banned their use on the space shuttle and they require today’s flight attendants to undergo additional training to deal with lithium metal fires. This technology would be a poor choice in a classroom setting. Another potential is the use of large super capacitors. Super capacitors offer several benefits including unlimited charge/discharge cycles, almost immediate charging, and long life. Unfortunately they are also quite expensive and limited in energy density. A super capacitor based solution is feasible but only to the extent of providing clean system shutdown immediately upon power loss. Even in this capacity, their use This could be problematic in the case of multiple short duration outages where are the power fluctuates wildly so a more stable supply with a longer run time is necessary. One of the newest options is the lithium iron phosphate or “LiFe” battery. These cells combine the very high energy density of lithium chemistry with faster charging rates than typical lithiums and charge/discharge cycle counts in the low thousands, and without the fire and ignition issues of other lithium chemistries. The LiFe battery is the best solution available presently to provide not only clean system shutdown but to also maintain Data logging and operation during brief power outages, eliminating the need to reboot when power is reapplied unless the outage is prolonged.

A low volume commercial offering for such a LiFePO4 battery based micro-UPS has been identified from LiFePO4wered/Pi™. While the functionality of this design may be duplicated in volume fairly easily, it does utilize parts which are difficult to source in small quantities outside of China. For this reason in the near term it will be desirable to integrate this pre-existing solution with the other additional peripherals by providing a connector where it can simply plug in. The UPS subsystem must be capable of monitoring battery conditions and acting accordingly through software. This subsystem should also provide the facility to toggle power to the pie via a button. The identified solution provides these capabilities. The battery used is a standard 18650 form factor cell which snaps into a standard cell holder for easy replacement in 15 years. Chemical systems like batteries don't last forever.

The third peripheral required is a battery backed real-time clock to ensure consistency of timestamps in file access and data logging. This is accomplished with a single-chip solution using a Dallas DS1307 or DS1232 real-time clock chip which is powered directly from the battery supply. An example of such a clock board is shown to the right in red. Again, the commercial offering in the example shown prevents the use of effective passive cooling.

Off-the-shelf Pi expansion boards providing all of these functions individually are available however there is no single offering which contains all of these peripherals and the offerings which are available all compete for use of the same I/O pins on the Pi. Additionally these peripherals must be provided while not compromising the space available for a high-efficiency passive heatsink for the CPU. 

In the typical Pi configuration, only a single add-on peripherals may be used and that board sits directly above the CPU which needs additional cooling to operate at full speed. While that's not an issue when the Pi is used for educational purposes or for tinkering, it becomes a very serious consideration for embedded systems. To address this issue and turn the Pi into a workhorse embedded computer, the Raspberry Pi Foundation has re-issued the core of the Pi as a “compute module” in the form factor of a standard memory module which can plug into a board containing additional peripherals customized to needs. 

Using this compute module for IMS’ needs would require re-implementation of both the ethernet/USB controllers and ports as well as the HDMI connector. These connections involve signals as fast as 5 GHz so this task would require professional electrical CAD software such as Altium Designer to be done properly. Designer is a $10,095 dollar package for the 1st year’s license and $1850 for year 2 and on. Because of the quantities used by IMS, implementation of a complete new controller using the Pi compute module will not be cost-effective in comparison to use of the Pi 3 Model B unless a multiple thousand unit order is being filled. Even then there is probably little savings to realize in a compute module based design because of the additional requirements for manufacturing. There is no apparent downside I can see to use of the standard Pi 3 Model B along with a peripheral expansion board in a custom case. Removing the extremely high-speed signals from the IMS PCBs to be produced allows the CAD work to be accomplished using CERN’s KiCAD which is open source and free. 
 
Like all personal computers, the Pi does generate heat while in operation. For maximum operational reliability and lifespan, cooling for three chips on the Pi board must be provided and everything must be placed into a case which can allow for adequate convection cooling while also being transparent enough to RF energy for the Wi-Fi and Bluetooth radio modules to operate inside it.

The thermal image on the left shows a Raspberry Pi in basic operation with no cooling or heat sinking. The white spot over the CPU shows the temperature extremes reached by the silicon as it does it's work. Without removal of this heat the processor will slow its clock speed dynamically in order to limit operating temperature and avoid immediate damage. Higher temperature operation will lead to a shorter lifespan of the Pi. Two other chips on the board, the USB + Ethernet interface and the HDMI framer on the bottom of the circuit board, also generate heat during operation which must be removed. This is typically accomplished using a fan however a fan is not desirable in a high reliability embedded system. 

The most basic approach to dealing with these heat issues is to install small aluminum heatsinks using thermal tape. The dimensions of these heatsinks are typically limited by height and thus surface area, in order to accommodate expansion “hat” circuit boards which sit above and parallel to the Pi PCB in what could potentially be a stack of circuit boards. Because a Pi occupies the bottom most position in a stack, the capacity to cool the CPU becomes greatly compromised without forced air. The IMS expansion hat architecture rotates the position of the expansion circuit board 180° relative to the expansion connector. This makes the pie case wider but it leaves the vertical space over the CPU and ethernet/USB controller free. 

While the small heatsinks help they are insufficient for creating a high reliability embedded controller. With the height restriction removed we are free to add heatsinks with far greater heights and therefore far greater surface areas to distribute heat.

The case example on the right shows a passive design in which the heat of CPU and ethernet/USB controller is removed and dispersed into the case via two clearly visible heat pipes in the center. This example case is well-suited for hobbyists but it lacks space to include the additional interfaces and peripherals required by IMS. It also lacks the RF transparency required by the onboard Wi-Fi and Bluetooth interfaces to achieve optimum range. 

A custom case which he uses this heat dispersal architecture is worthy of study but would require considerable machine work and be comparatively expensive. Until such time as the work to produce a milled aluminum case is deemed necessary, sufficient cooling for the CPU should be able to be achieved through the use of the high performance heatsinks shown to left which are available off-the-shelf from vendors such as Digikey and Mouser. The ethernet/USB controller produces less heat then the CPU albeit it can still get quite hot. This controller is packaged differently from the CPU and will not accept the same heat sink design used for the CPU however it may be adequately cooled using a taller version of the standard Pi solution applied with either thermal epoxy or thermal adhesive tape. The HDMI framer chip on the rear of the board also produces heat and may be most effectively cooled through the use of a large heat spreader with exposure to passive air convection.

Because of the unique requirements for this automation system, no Pi case currently on the market has been identified which is suitable. The lifespan of electronic components and their temperature is directly proportional. In almost all instances where the Pi is used as an embedded controller it is also equipped with a fan, however fans come with the inherent disadvantages of noise and wear which make them highly undesirable in an embedded controller. A passive heatsink with sufficient thermal mass is capable of keeping these chips cool, however the case these sinks sit within must also provide adequate convention airflow to maintain the operational efficiency of the heatsinks. Building the cases for the Pi nodes is actually one of the largest technical challenges of manufacturing the system.

Finally, a 5 volt power supply with sufficient capacity and a highly reliable power connection must also be provided. In the teaching wall this is accomplished with a 5 volt switching power supply which supplies a number of other functions with DC. In the center building module this may be accommodated with a plug in power supply or a quality commercial switching supply from a vendor such as Meanwell which also provides DC voltage to the ICE-9 modules distributed throughout the room.

All Pi based modules run from the exact same FLASH configuration in order to simplify firmware distribution. The IMS peripheral board paired with the Pi identities the desired functionality of that node to the OS during boot and loads operating software accordingly. Firmware is stored on 32GB Samsung PRO+ line microSD cards. The 32GB Samsung PRO+ is higher capacity than required for most uses today but was specifically selected in contrast to other lines and other densities in the same line based on testing from a number of sources. This particular microSD card demonstrates superior performance in terms of data transfer speed and therefore operation of the Pi. Should the firmware of any Pi based module become damaged, the RCP1 may be used to restore a functional operating system on the corrupted card by inserting that card into a USB adapter and then booting that Pi system. When a secondary microSD card containing an operating system is detected at boot, that card is automatically checksummed. If the checksum is found to be in error, the card will be erased and a new copy of the operating firmware will be installed. 

IMS embeds the Pi for three different uses: 

The first is the RCP1 or Remote control panel type 1 which is a Pi equipped with a 7 inch touch screen, LiFePO4 UPS, a CAN-bus controller, and a real time clock. This module runs Node Red software which is used for monitoring and control of building resources including HVAC, lighting, security, and also for logging environmental and power consumption data. It makes this data available in both raw and graphical form using a dashboard interface available both inside the room and anywhere on the Internet to those with the proper security credentials. 

The second use of the Pi is in the MC1 or Media Controller Type 1 which controls the presentation systems in a classroom or conference room configuration. Its hardware includes a Pi, a LiFePO4 UPS, a CAN-bus controller, and a real time clock. This pie is responsible for integration of all audio visual capabilities. It provides a universal text/video message board interface, a streaming audio receiver, a streaming video receiver, a video player, a slideshow player, a PowerPoint player, a dashboard interface to the building control systems, general web browsing, and a display for local weather station data.

Finally, in the CLMB1 clock/message board configuration the Pi in tandem with an LCD monitor is used to provide a wall clock which may also be used for text or graphical messages or video streaming. For this use CAN-bus and a real time clock are unnecessary but a UPS is still required to prevent microSD card corruption. In the clock/message board configuration the pie is never writing files and it can obtain the real time over the network, removing the need for a local real-time clock in this module. Ultimately all modules which operate with the knowledge of real-time keep their internal clocks updated via network time services from the NIST atomic clock in Fort Collins, Colorado. This insures all nodes always maintain a synchronized time.

 Software details go here……. Raspberry Pi based nodes are responsible for: Node Red - Room resource control and mappings Node Red - Room energy management Node Red - HVAC schedule Node Red - Lighting schedule Node Red - Environmental data logging Apache - Web server for room dash board Apache - Web server for room control panel SQLite - Database services for data logging to USB drive in teaching wall HDMI Video Message Board System with text, graphics, & video support Streaming audio/video receiver for intercom Streaming audio/video encoder/transmitter for intercom/monitoring Mosquito - MQTT Broker BACnet IP <-> MQTT Bridge CAN-bus <-> MQTT Bridge TCP/IP <-> CAN-bus Bridge CAN-bus network time services Class Clock USB hosting of files on thumb drives for slide shows Bluetooth communication with Apple TV to coordinate media mode switching Bluetooth communication with remote controls Camera interface (potential) Multimedia System Design The goal of IMS’ multimedia system design is to provide a highly capable system with exceptional ease-of-use. This system is flexible enough to keep pace with evolving A/V standards while at the same time allowing for single button control from a user who wants to remain insulated from all operational details. Presentation systems are evolving at a rapid pace. ICE-9 accommodates this rapid progression as well as the desire for a wide range of different customer configurations by providing a set of tools which can be used to integrate off-the-shelf A/V components and to control them in a way which is completely transparent to the user. Depending on the target audience, there may be an extremely wide array of different A/V configurations which are desired. The SDIR1 Signal Director module simulates the operation of up to eight individual IR remote control transmitters, allowing a single queue from an application to trigger the SDIR1 to issue any set of control commands necessary to properly configure all of the AV components in the system to a given state. The SDIR1 provides eight 3.5 mm TRS sockets and each of these sockets may be connected directly too a device to be controlled via a patch cord if that device has an IR input jack, or they may be connected to IR repeater LEDs adjacent to the receivers of the devices to be controlled. The SDIR1 also includes an output to control a solid-state relay to allow hard power down of all presentation system components for energy savings. Several other modules including the MIP1 input panel, AMIX1 audio mixer, ACP1 audio control panel, and MC1 media controller round out of the building blocks for a presentation system. Most of the higher level functions of ICE-9 are handled by either the RCP1 Remote Control Panel or the MC1 Media Controller module. The MC1 module is primarily in charge of governing the multimedia systems in a room and also plays an active role in presentation by streaming video and or audio or presenting webpages through those systems. The MC1 and the RCP1 modules work in concert and share any operational information necessary to perform their tasks. This degree of integration allows a single button press to turn on monitors, configure video inputs, configure audio outputs, dim the room lights, darken the windows, set an initial volume for payback, and start playing a video. Complete integration with a Bluetooth Remote control is also possible. The Apple TV remote is one such candidate. All multimedia system components are supplied to power through a Brick Wall surge suppressor. Additional information on the Brick Wall device is presented in the next section. IMS has multiple reference designs for presentation systems built from modular components. The most ornate of these designs includes two monitors and up to six video sources including two MIP1 panel inputs, HDMI from the MC1 Pi, Apple TV, Chromecast, and a classroom computer which may be a Mac or PC with an HDMI port. Each of the signal sources is fed into an HDMI splitter and the splitter outputs are distributed to two six input HDMI switches, one connected to each monitor. Both HDMI switch outputs as well as the Media Controller Pi’s output are passed through audio extractors which have TOSlink optical outputs and the capability to decode 5.1 channel audio as a stereo signal. All three TOSlink cables from the extractors then feed into the AMIX1 Digital/ analog audio mixer module. This allows the monitor’s volume to be kept at zero with all audio handled by the AMIX1. If 5.1 audio is required, the volume of the extracted stereo signal can be lowered to zero well the volume on one of the monitors which is connected directly to a speaker system is raised. This allows 5.1 audio to be a transparent option requiring only the installation of additional speakers to support. The AMIX1 also provides several analog inputs to accommodate up to two wired or wireless microphone systems and utility audio from the CLMB1 clock/message board module. The ACP1 audio control panel provides two rotary encoders for intuitive control of volumes in the system, one for media content and the other for microphones. OR