No Downtime Upgrade

I have had multiple conversations on software upgrade with a number of customers and wanted to share this particular usage scenario of virtualization technology. Software upgrade traditionally requires

  1. Delivery of new software to the embedded system
  2. Shutdown of service
  3. Shutdown of the system
  4. Installation of the new binaries
  5. Reboot of the system
  6. Restoration of service

Between 2 and 6 of course the system is 'down', no service is provided, which is a bad state for many embedded systems.

Virtualization allows the user to run two virtual boards, on a single processor if needed. Only one of these virtual boards is actively in service, the other is dormant, it takes some memory space, but not processor time.

When it is time to upgrade the system the second virtual board is upgraded with new software, it is booted and verified to be operational. Up until now the first virtual board has still been handling service, there has not been any disruption. Once the second virtual board (with the upgraded software) has reported that it is available for service, it can take over service from the first virtual board.

The first board can now go dormant and be ready for the next software upgrade and the entire sequence can be repeated again.

Virtualization enables running of the two boards and scheduling them to make use of the processor and devices. The software development team has to handle the actual upgrade and the switching of service, whether this is network traffic or other content.

Switching of service can be done in multiple ways. As an example, let's assume that the system is handling network content. If the system has a single ethernet card to send/receive data on, then both virtual boards can have access to that very ethernet card, but they will have to coordinate access. Another possibility is to give the system two ethernet cards and assign one card to each virtual board.

The two virtual boards in the scenario above can run on a single core processor, on a single core in a multicore processor, or on different cores in a multicore processor, all depending on the needs of the user.