Keeping your LabVIEW Real Time Measurement Systems Up To Date

There is a distinctive feature of real-time systems and any special purpose machine, which is you can control the whole system. This total changes our options compared to general-purpose systems as described in the previous part in this series.

For LabVIEW Real-Time systems, in particular, you have two strategies for updating and commissioning them: Image-based Installation and Package-based Installation

Image-based Installation

Image-based installation means that each update is delivered by totally wiping the existing system and providing a full new system image including the OS, drivers and applications.

Full system imaging is available on all NI real-time systems and guarantees a consistent state. Images are almost always the easiest approach for bringing a new system online.

For older NI systems (based on Pharlap ETS or VxWorks), there is a crucial limitation which is that a host system must push the image directly onto the controller. For LinuxRT systems, it can be initiated by a host or run directly by the controller itself. This direct option means that they can download updates and install them locally, which makes it much easier on remotely deployed systems.

Images have some pretty key problems to consider though:

If the image is corrupted during transfer or the process is interrupted, it can render systems useless and inaccessible by via a corporate network.
You must be careful about the configuration not to remove user data.
Image files can be large and often the whole image isn't really required.

Package Based Installation

NI are pushing packages more and more for all of their systems. And with good reasons. Packages are lightweight but good at describing dependencies to ensure everything works. They also support automation.

The are a pretty new technology on NI Real-Time systems but we will be putting our first customers on it in the next few months and expect it to significantly streamline the management of their systems.

Automation

When you have 10, 100 or even 1000 systems with either technology, you can't be initiating each update manually. This is where update automation comes in.

SystemLink

NI provides SystemLink for automating packages to a large number of systems. This allows you to control the deployment of packages to a large number of connected systems by grouping similar systems and controlling the rollout like this.

There are also features for data collection and asset monitoring which means as a whole package in a target industry it would be a great option. Systemlink looks great for production and asset monitoring environments where a plug and play system is needed with minimal IT knowledge.

Salt

I've also been working with Salt (or SaltStack) which is the technology under SystemLink for package management. Why work with it directly?

I can use the same technique to work with NI and non-NI systems and technologies. (my first project deploying Salt is with non-NI Linux based systems)
Learning SaltStack opens up all the other capabilities such as deploying images, templating configurations and others.
If the only feature of SystemLink you need is package management, you can get it all with an open-source tool.

Salt is also a declarative technology. That means that rather than defining what should be done, you set the state the system should be in and the software figures out the steps to get there. This declarative approach reduces the risk of human error.

It is harder to work with though. Out of the box you get a command line to do everything with so if you want something fairly plug and play, you probably want Systemlink.

Push vs. Pull

Both these systems are push-based technologies though. You tell the server to push the update to all systems. You may also need to consider a pull-based system where the system itself decides on a good time to update itself. (You don't want to restart in the middle of a critical procedure)

I believe (but have not tested) this is possible with Salt as well. In the past I have also allowed systems to download their own update files from a web server at a time that is appropriate for them

Testing, Testing, Testing

Bear in mind that if these systems are unattended failures can be a pain to deal with - possibly requiring a site visit. So I always recommend having a development system locally to test changes against first. Some ideas for testing include:

Try pulling the network cable at different stages and seeing if the system survives, or if you can make changes to make it more robust.
Use additional routers to simulate separated and firewalled networks and see what still works.

Even then role out to a few friendly* sites before updating everything.

*physically accessible and understanding local technicians