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 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:
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.
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.
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.
I’ve also been working with Salt (or SaltStack) which is the technology under SystemLink for package management. Why work with it directly?
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.
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
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:
Even then role out to a few friendly* sites before updating everything.
*physically accessible and understanding local technicians
Part 3: How Do I Keep My Real-Time Systems Up To Date