MUSEUM CONTROL GOES NODEL

First Peoples and Think Ahead at Scienceworks (above) were the first exhibitions to be built from the ground up using the Nodel system.Photographer: Rodney Start

Museum Victoria rolls its own decentralised control network.

Text:/ Andy Ciddor

Like every modern major museum organisation, Museum Victoria (MV) understands that audiovisual content and the technologies that deliver it lie at the core of its existence. In 2000, when the Melbourne Museum moved to its spectacular modern premises from the landmark Victorian building that it had shared with the State Library for its first century and a half, it adopted the most advanced AV technologies then available. West Australian technology company PIVoD was engaged to supply and implement its Media and Venue Management System (MVMS), which over the next decade was deployed to all of MV’s permanent galleries and public spaces, controlling some 270 exhibits across its sites at Melbourne Museum, Scienceworks, and the Immigration Museum.

“We were very much at the forefront of deploying digital media and audiovisual exhibits in Australian museums,” recalls MV’s digital media systems manager, Joe Coleman. “We used a centralised control system then, which was actually a much bigger and heftier beast than what we ended up requiring, because it was going to deliver streamed content to the streams and points of presence throughout the building.” Meanwhile, rapid developments in digital media storage and replay technologies meant that individual flash-based replay devices were deployed locally at exhibits rather than streaming the high-bandwidth content across the network from the central media server. MVMS was eventually relegated to being a big, centralised device controller for the new media players.

In 2003 Microsoft terminated development of the software platform underlying MVMS (the ever-so-slightly-quirky Microsoft Java Virtual Machine), which condemned it to running on Windows XP. Add to this the problem that development of the licensed proprietary code in MVMS ceased in 2010, shortly before PIVoD itself stopped trading. Museum Victoria now had no ability to add new types of devices to an increasingly-unreliable and ageing control system that ran on an abandoned operating platform.

MV’s head of production and technical services, Andy Greenwood, assembled a working group to examine the range of options available. The possibilities considered ranged from replacing the current system with an existing commercial off-the-shelf system, buying and tailoring a proprietary system developed for another museum, developing a system from scratch to their own specifications, or simply to keep going with the existing orphaned system.

Using the carefully-considered and highly-detailed wishlist of performance criteria assembled to evaluate the suitability of any replacement system, it became clear that the balance between cost, desire to innovate, suitability to task and risk of failure, came down in favour of a built-to-order system to be developed by Melbourne-based audiovisual system integrators and software development firm, Lumicom, with which MV already had a long-standing relationship.

Every Nodel node has a web interface for configuration and monitoring, providing access to any HTML-capable device on the MV networks (note the logo, please). This allows staff to stand in an exhibition and tweak it by laptop or handheld device.– Exhibition scheduler node –

– Projector device node –

Exhibit controller node

HIGHLY SPECIFIC

The lessons learned from running the museums on MVMS were many and varied, and resulted a specification for a system architecture unlike any other, and a system philosophy that is unusual, and most likely unique in this field.

Keith Vaz, MV’s systems administrator – digital media systems, explained: “One thing we didn’t want it to be was ‘one system to rule them all’. We didn’t want it to do too many things, so we were very focused. The three things we wanted were device control, device scheduling and monitoring.” Rather than the centralised architecture of MVMS and most other control systems like the ones you find running buildings and campuses, the new control system is a cloud of independent nodes. In what can only be described as a masterstroke of marketing savvy and branding insight, the system was given the original and imaginative name of ‘Nodel’. It does however, have a neat logo.

Nodel is a platform-agnostic system… able to run on any device that can host a Java Virtual Machine

ENTER NODEL

Nodel is a platform-agnostic system, being able to run on any device that can host a Java Virtual Machine, which includes every processor-based device from a single-board computer like a Raspberry Pi, any laptop ever made or any desktop, server or mainframe computer. It’s just as happy running on Windows as it is on Apple’s OS X, or any flavour of Linux or Unix (which includes Google’s Android operating system for smartphones).

The core code for Nodel is a message passing system that communicates with other nodes on the network. Nodes communicate with each other using a simple, open, language-independent, human-readable protocol written in JSON (JavaScript Object Notation), a very lightweight data structure which requires only a small amount of processing to decode.

Communication with devices such as media players, projectors, display panels or lighting controllers is implemented through a layer of custom code for each device family, written in Python script. In addition to locally-connected devices, a node can also control other nodes on the network. A node may be programmed to poll another node to retrieve its status or it could instruct a number of other nodes to perform a series of actions at a specific time.

Vaz explains the nature of the nodal architecture: “A node at its most basic level is a single device. That device can be a piece of hardware actually out there in a gallery, or it can be a script or piece of software that’s running on a computer. We tend to gather nodes together in clusters. An exhibit for instance might have a node that turns a projector on and off, and reports on its status. We have a node that controls the media player and each of the other devices that involved with that exhibit, such as a lighting controller node or a general purpose I/O node.

“These device nodes are aggregated to become an exhibit node that gathers the data coming to and from those device nodes. The exhibit nodes are gathered together in an exhibition node or a gallery node, and in the next layer the galleries or exhibitions are gathered under a venue-wide node.”

NODE HIERARCHY

The hierarchical structure of the network is logical rather than physical, so there is no client/server relationship as had existed in the previous system, and thus no single point of failure that could bring down the entire museum.

Joe Coleman explains: “What we tend to do for ease of management, and because we have devices such as the Brightsign players and projectors that can’t natively host their own nodes, is host all of those nodes on a single virtual server in our server room so that they’re all in one place. It’s just kind of easier to set up that way although it really doesn’t have to be. You can run nodes on little boxes like a Raspberry Pi in a broom cupboard if you want to, but from a management perspective it’s easier to aggregate them in one place.”

A group of technologies known as Zero Configuration Networking are used to establish communication on a Nodel network. This enables nodes to be shut down at the end of the day and restarted each morning without requiring access to a central server for network control and configuration. It also allows a group of nodes to be removed from one network and moved to another one (think: touring exhibition) without requiring any additional reconfiguration.

On start-up, just like any other device, the node automatically obtains an IP address from the network it’s connected to (usually via DHCP). Next, it joins the Nodel network using Multicast DNS, a protocol that allows each node on a network to keep its own list of node records without requiring a central server. This allows communication between nodes on the same network using each node’s name without having to know its IP address, which may change each time the node is rebooted.

SHARING: A LA NODE

One of the most unusual aspects of the Nodel project is what Museum Victoria has done with the code it contracted Lumicon to develop. In a bold and innovative move, it has made the core code of the system available to other institutions via an Open Source licence which allows them to use the code at no cost, on the strict condition that any enhancements to the code are made available to all other users. Aside from being amazingly generous, this ensures that there will be a lively community of users continuing to enhance and extend Nodel while substantially lowering MV’s maintenance costs and reducing the risk that the code will be orphaned like MVMS. The device-specific Python code ‘recipes’ are also being made available, although there is no absolute requirement for sharing every detail of the developed code, which may involve proprietary information for some devices.

Since going live with its first exhibition in September 2013 Nodel has now been rolled out to 160 exhibits across eight galleries, with around 700 nodes now active across the three Museum Victoria sites. Many of these rollouts have been seamless retrofits of Nodel to the existing MVMS exhibitions. More impressively Nodel has not been restarted since the system originally fired up.