Nodel is an open source digital media control system for museums and galleries, although there are many valid uses for Nodel outside of this scope where device control, monitoring, and scheduling is required.

In response to the pending renewal at the Australia Centre for the Moving Image, the technical services team decided to trial Nodel to assess it’s suitability as the control system for future exhibits and installations. I put my hand up to build a small Nodel implementation example, and write some documentation on the lessons learnt that would help future employees deploy Nodel around the organisation. This documentation will come in the form of four posts; Basic Concepts, Implementing a Simple Nodel System, Nodel System Design, and Coding Tips.

Nodel System Design, is the third of the write ups that will discuss Nodel. This post will describe a methodology on how to approach designing a more complex system, with ACMI’s very own Cleverman Exhibition used as an example use case. It is highly recommended that you read Basic Concepts and Implementing a Simple Nodel System before going ahead and consuming this post.

Before explaining the steps required to design a Nodel System in a methodical way two things should be briefly touched upon as they have not been mentioned, the Scheduler Node, and the ACMI Management Node Recipe.

The Scheduler Node

In almost every system things are going to have to be scheduled. Whether it is to preserve equipment lifetime, ensure the correct content is presented, or to save power, some form of scheduling will be required. This is where the Scheduler Node comes into play.

The Scheduler Node can be defined as a Management Node. Using a variety of different techniques it schedules the emitting of Local Events at specific intervals or one off dates. As explained in Basic Concepts: Control With Remote Events, Remote Events within Management Nodes can be triggered by the emission of another nodes Local Event. This Management Node Remote Event can then call a Local Action from the Management Node in a Remote Event handler function. This is how a Scheduler Node can trigger the calling of various Actions within a Management Node.

A variety of Scheduler Node recipes exist within the Museum Victoria’s Nodel Recipe Repository with varying levels of complexity. This includes the scheduler recipe, the advscheduler recipe, and the Microsoft Exchange Schedule Retriever which if implemented correctly can use a Microsoft exchange calendar as a scheduler. The ACMI Scheduler, a derivative of the advscheduler recipe is a particular easy scheduler to implement.

The ACMI Management Node Recipe

Using the techniques described in Basic Concepts and Implementing a Simple Nodel System, the ACMI Management Node Recipe was created. Using Parameters, it features a simple user interface that allows a user to create Local Actions, Local Events, and integrate “Member Nodes” without writing a single line of code. When adding Member Nodes a series of Local Events, Remote Actions, Remote Events and handler functions are automatically created and wired. In addition, triggering the ACMI Management Nodes Local Actions with the emission of another Nodes Local Event is possible using the “Remote Events Triggering” Parameter which is often required when integrating a Scheduler Node in a system.

Animation 1 shows the setup of a Management Node using the ACMI Management Node Recipe to control two of the Device Nodes used in Implementing a Simple Nodel System.

Animation 2 shows the setup of a Scheduler Node using the ACMI Scheduler Recipe to schedule the calling of a Local Action in this Management Node.

The code for these Recipes can be found here. With these two concepts out of the way, we can now move on to Nodel System Design.

Nodel System Design Scope

Designing a Nodel System can be done in a methodical way with a simple scope that will ensure the system remains functional, adaptable, and understandable to a wide range of people. This scope can be defined as the following:

1. To control, schedule, and monitor a specific use case in the most simple way possible.
2. To reduce the development time of the control, scheduling, and monitoring system.
3. To develop a control, scheduling, and monitoring system that can be altered and adapted to changing requirements in a quick and simple manner.
4. To develop a control, scheduling, and monitoring system that can altered, adapted, maintained, and operated by individuals with differing skill sets (i.e. individuals who are not software engineers).

These goals should always be kept in mind when designing a Nodel system.

Nodel System Design Steps

If it is known Nodel is going to be used for control and monitoring, keep this in mind when deciding which technology is going to be used in the exhibit. Ideally the technology used in each exhibit will have the ability to have a variety of parameters controlled and monitored via a network. With this being said, the following steps are a good guideline:

1. Develop a naming convention for individual nodes: This might include the type of node, the technology the node uses, the area a node exists in a physical sense, or other identifying features.
2. Define a control requirements list and accompanying control naming convention: This will include the the control attributes required for various nodes throughout the system.
3. Develop a Node System Table: This table details all nodes as well as the Node Name as defined by the naming convention, Node Type (management/device), Parent Node Name (if a member of a Management Node), Area Name (location of hardware that is being controlled by the node), Control Attributes which are required by the node, and Technical Notes which should include implementation details and controlled hardware details in the case of Device Nodes.
4. Develop a Scheduler Node Recipe: This Recipe will most likely be chosen from existing recipes rather than being developed from scratch.
5. Develop a Management Node Recipe: While a custom Recipe can be developed, the ACMI Management Node recipe should be able to do everything a Management Node needs to do.
6. Develop the required Device Node Recipes: These recipes should directly control hardware or software that is external to Nodel. Based on the Device Nodes defined within the Node System Table, it should be clear what Device Node Recipes need to be created. Ideally, this is the only time code development should be required.
7. Create system using Nodel Interface: All the information required to create the system should be accessible from the Node System Table, making the system creation a relatively straight forward task.
8. Test system: The system should be tested in the real world to ensure each Node is functioning correctly.

To show how following these steps can result in the quick implementation of a Nodel System in a real world setting, ACMI’s Cleverman exhibition will be used as an example use case for designing a Nodel System.

Nodel System Design For Cleverman

In the case of this example, Cleverman: The Exhibition located in ACMI’s Gallery 2 space had already been installed before designing this Nodel System. Cleverman consists of several exhibits that have multiple pieces of playback and display technology. Due to the small size of the Exhibition these exhibits were not separated in to areas. The main method of playback was through BrightSign players, while a variety of screens were used to display the content. Unfortunately none of these screens were connected to the network, however by toggling the HDMI output the screen automatically powered on and off respectively. Due to this, no screens in the exhibit where treated as Nodes.

The initial control software used for the exhibition was the BrightSign App, which had a variety of control features such as Reboot (reboots the player), audio mute/unmute, display off/on (turns off HDMI output), and pause/resume content playback. Status of the screens and BrightSign players was not available, although through the app it was possible to see if the player was “Online” or “Offline”. When designing the Nodel System it was decided that at a minimum these features should be replicated. You might ask yourself what benefits to be had by using Nodel in this case seeing as most the control is being conducted by BrightSign players. By implementing a Nodel System, it because possible to integrate other pieces of technology to the system in the future.

The following table was available at the time of designing to give an idea of individual pieces of technology being used. Using all the information it is possible to move forward with the design of the Nodel System.

Step 1: Develop a Naming Convention for Individual Nodes

Based on the available information a naming convention was developed that would allow both easy identification and quick identification of a Device Node’s associated technology. For management type nodes, the naming convention would be the following:

<SPACE NAME>_<NODE NAME>

For device type nodes the naming convention would be the following:

<SPACE NAME>_<PARENT NODE NAME>_<ADDITIONAL IDENTIFIER>_<DEVICE NAME>_<CODE>

Step 2: Define a Control Requirements List and Accompanying Control Naming Convention

After consulting with various stakeholders and reviewing the existing control system the following Control Requirements List and accompanying naming convention was developed. This list was heavily influenced by the way each BrightSign player was configured at the time of installation to accept UDP commands as a way of controlling various parameters.

Step 3: Define a Node System Table

With the information obtained from the initial research and steps 1 and 2, the following Node System Table was created.

Step 4: Develop a Scheduler Node Recipe

For the purposes of this example, the ACMI Scheduler recipe will be used so a new recipe does not need to be developed. While this recipe provides a rudimentary interface for scheduling Nodel Events, it is usually quite sufficient for small Nodel Systems and is very quick and simple to setup.

Step 5: Develop a Management Node Recipe

For the purposes of this example, the ACMI Management Node Recipe will be used so a new recipe does not need to be developed. This recipe generally provides all the functionality a Management Node requires with a simple to use interface.

Step 6: Develop the required Device Node Recipes

As defined in Step 3, the only two devices that require direct control and monitoring are the BrightSign LS442, and the BrightSign HD1023 as the Robosonics MP3 Trigger boards were unable to be controlled via a network. Due to the way BrightSign players are configured, only one Device Node recipe needs to be developed for these BrightSign players.

The ACMI Brightsign Recipe was developed for this purpose. Once a node is created using the Recipe, a port and IP address needs to be entered as a parameter. These parameters will be used to send UDP commands to a BrightSign player when told to do so by the calling of Local Actions. The UDP command strings are as defined in the Control Requirements List.

Step 7: Create system using Nodel Interface

Animation 2 shows the result of creating the Nodel System using the Nodel Interface using the Node System Table as a reference. The animation shows all the created Nodes as well as some of the Local Events and Actions created in certain nodes.  All up implementing this Nodel System took around 45 minutes which included some rudimentary testing.

Step 8: Test system

Finally, the entire should be tested in the real world in the physical presence of the hardware that is controlled by the Device Nodes. Notes should be made on control failures, and these issues should be fixed.

Conclusion

This post has broadly touched on how to go about creating larger Nodel systems in a methodical way using the example of ACMI’s Cleverman exhibition. Techniques described in Basic Concepts, and Implementing a Simple Nodel System have been used to create a Nodel System in a relatively short amount of time. Some Recipes created at ACMI have been shown as good tools to use when designing Nodel Systems that are quick to implement, and flexible enough to update in a easy manner without having to resort to developing new code. It was also shown that planning Nodel Systems in a methodical way is in general a good idea that can save time in the future.

Coding Tips will be the final post in this Nodel series. General advice about coding with Nodel will be explained that will give a leg up when coding Device Node Recipes for the first time.