Software Upgrade Best Practices

Reconfigurable I/O (RIO) systems (NI Single-Board RIO, NI CompactRIO, and so on) are used for several years in embedded applications. It is necessary to maintain these systems to ensure the expected results over the entire lifetime of the product lifespan. Software is an integral component of these systems and therefore needs to be maintained. This document will review the rationale for regular software upgrades and the best practices for upgrading software.
 

Rationale to Upgrade Software

Developers find the need to upgrade software for various reasons. When new hardware is used in a system a developer needs to upgrade software to a supported version. Similarly, developers need to upgrade an application to utilize new software features. Other times, developers are forced to upgrade software because components of their system (operating systems, hardware, software, etc.) become obsolete. When the components are upgraded, developers need a compatible software version. In many situations a software upgrade is inevitable.

The main rationale to upgrade software regularly is to always have a mainstream supported software version in use. NI will release patches at their discretion for software with mainstream support. If bugs are found in software that are not covered by mainstream support it is not likely they will be fixed.

Another consideration for regular software upgrades is that whether you are updating for new hardware or software features, system component compatibility, or a bug fix, regular incremental upgrades will allow more seamless transitions than large version jumps. For example, upgrading every two software version releases will ensure continued mainstream support and need a substantially lower amount of effort than updating every six software version releases.

Software Upgrade Best Practices

When updating a small application it may be tempting to upgrade to the new software version and hope for the best. NI recommends using these best practices regardless of the application. The time and effort involved with these practices will scale appropriately with the size and complexity of each application.

For a comprehensive document on the best software upgrade practices, refer to Upgrading Your Version of LabVIEW.  A general overview to software upgrade best practices is found below. The practices outline upgrading software from the current version to the upgrade version.

1. Develop Documentation Standards
   
   Developing, deploying, and upgrading an application is always made easier with clear documentation. When a developer begins an application, he or she should have specific documentation standards. Standards allow easy navigation of an application to identify key components, work arounds used, and low level functions. They can also be used to document the plan, progress, and next steps of the upgrade process. These standards are especially useful when a team is working in parallel on a software upgrade. When the documentation standards are clearly defined, anyone should be able to step in to the upgrade process and understand what needs to happen next and where to find everything they need.
    
2. Identify Compatible Modules, Drivers, and Toolkits
   
   Each version of LabVIEW is compatible with a specific set of modules, drivers, and toolkits. When upgrading LabVIEW from the current version to the upgrade version, you will need to know what module, driver, and toolkit versions are compatible. Before starting the upgrade process, identify all modules, drivers, or toolkits the application uses. Find the versions compatible with the upgrade LabVIEW version. This information is often found in readme files and online (see LabVIEW Upgrade Notes for more detail).
    
3. Cross Reference and Document Applicable Bug Fixes, Upgrade Notes, and Known Issues
   
   Software may behave differently after the upgrade. This may be due to bug fixes or low level optimization, but it may also be caused by known issues with LabVIEW. The effects may introduce race conditions because of optimized timing, eliminate the need for a work around because of a bug fix, or render a section of code inoperable. Cross reference these documents with the application. Document locations in the application these changes will likely affect and the expected change in behavior. Take note of suggested work arounds to use. Turn to these notes first if the code behaves differently after the upgrade.
    
4. Test and Benchmark Current Code
   
   Part of the update process is being able to designate a software upgrade as a success or failure. In order to do so define specific tests and benchmarks the application must adhere to. These could include functionality, timing, and performance among other things.
   
   Create a test that clearly defines all functionality of the code including every state the code runs. Ensure the application handles errors as expected. Define a test for any data logging, confirming files are saved correctly. Determine the necessary execution timing for each state of the code. While execution timing often affects functionality of certain states, pay close attention to time sensitive tasks that may complete successfully but outside of the allotted timing. Upgrading code can affect both memory and processing usage. Benchmark this usage for reference after the upgrade.
   
   Once the tests and benchmarks are clearly defined and documented proceed with the upgrade. These tests will be used after the software upgrade to guarantee the process was a success.
    
5. Create a Separate Upgrade System
   
   Upgrading an application can result in temporarily inoperable code. Reverting back to the current software version after an upgrade can be a difficult task. To avoid system downtime NI strongly recommends creating a separate system for the upgrade process. This ensures a running development version of the application regardless of the upgrade outcome.
   
   Ideally, this separate system will include a test machine along with any NI hardware the system needs. Using a test machine that matches features of the development machine as close as possible will reduce the chance of upgraded VIs behaving differently between the two systems. These features include CPU, RAM, operating system, and versions of software.
   
   Avoiding costly system downtime is the primary benefit of using an upgrade system. The main principle is to separate the development and upgrade environments to avoid conflict. While creating an upgrade system is the preferred method, a virtual machine can accomplish the same objective.
    
6. Upgrade Software
   
   Start by updating drivers compatible with both the current and upgrade versions of LabVIEW. Test the application after each install to ensure it meets application standards. This helps identify the source of problems that may arise in the code. After all drivers compatible with both versions of LabVIEW are installed, install the upgrade version of LabVIEW followed by modules, then drivers, then toolkits (re. After all software components are installed mass compile the application and resolve any errors or broken code (see the LabVIEW Upgrade Notes for more detail). Use the documentation created in step 3 to help resolve any issues that arise. The code is upgraded once all VIs compile in the upgraded version of LabVIEW.
    
7. Test and Benchmark Upgraded Code
   
   After all VIs compile the next step is to ensure the upgrade process was successful by running all of the tests defined in step 4. These tests will determine whether the upgraded application has the same functionality, timing, and processing and memory performance. Use the documentation created in step 3 and the LabVIEW Upgrade Notes to help find the cause of issues and resolve any differences in test results. Once the application passes the tests established the software upgrade is completed.

Additional Notes

Unknown Bugs

NI completes thorough testing on software before release to resolve any bugs that may be present; however, it is not possible to test every use case. Unknown bugs may present themselves during the upgrade process. Document any unknown bugs that arise. Isolate the behavior to a small code snippet and escalate the bug to NI. NI will create a Corrective Action Request (CAR) and release a patch or work around.

Code Modularity

Problems can arise at any point of your application’s code. Code Modularity is a good programming practice that can help identify the source of any issues. Individual subVIs can be tested to find root causes of problems that occur and ultimately lead to a faster resolution.