In GxP environments, remaining static does not necessarily mean remaining controlled

This article answers the following frequently asked questions:

1. If the system is stable, is it still necessary to update?
2. How can we understand what has changed between versions?
3. How should firmware updates be handled from a validation perspective?
4. Where can documentation and support be obtained?
5. Will we be notified when updates are available?
6. When will the next versions be available?

Validated systems are designed to create confidence. Once a system has been running reliably for some time, a natural conclusion follows: If nothing is wrong, don’t change it. This thinking is understandable.

But in practice, it is often incomplete.

During the webinar “Upgrade Your Continuous Monitoring System with Confidence: Easy Pathways to System Updates,” the questions raised were highly consistent.

How do we ensure systems remain controlled as both the system itself and its surrounding environment continue to evolve?

1. If the system is stable, is it still necessary to update?

Q: What is the importance of having the latest "minor" versions of your system. For example, 5.0.1.77 is our system is it worth updating?

A:

First, 5.0 SU1 is a fine version of viewLinc. With regards to the webinar topic, there is a shift in regulatory approach to encourage updates and upgrades to stay current. So then, how do we define “current”? I would define “current” as a version of the system that is 1) Supported by the vendor, 2) Works for your current purposes, and 3) Doesn’t have any security, functional,  or regulatory shortcomings.

Now, I love that you are on 5.0 SU1, as it makes a good example. Most viewLinc systems run on servers and networks using Microsoft backbones. Basic authentication for email in Microsoft 365 is being deprecated, and they keep pushing the deadline back (currently set for December 2026). What is replacing basic authentication for email? Well, that would be OAUTH2 Authentication. And this matters because viewLinc 5.1 SU9 is required to support OAUTH2.

So if your IT system gets forced by the Microsoft deprecation to move to OAUTH2 for emails, then your viewLinc system will no longer be able to send emails. In this case, your viewLinc version 5.0 SU1 will no longer be “current” by the definition I used today.

If you rely on emails from viewLinc for alarms and other things, I recommend reaching out to helpdesk@vaisala.com and initiating the upgrade process now, so you don’t have to hurry and do it later.

2. How can we understand what has changed between versions?

Q: Does Vaisala have the version changes in a matrix type table to describe the change from previous version to the new version in the areas changed?

A:

We offer information on version changes, but not exactly in the matrix format you are requesting. We offer Release Notes detailing new features and items fixed in each release. This is complemented by an Errata detailing known issues and how and where we fixed them. You can find them here:

• Release Notes
• Errata
   

3. How should firmware updates be handled from a validation perspective?

Q: How changes in firmware versions of the access points should be handled from the validation view?

A:

We didn’t cover the AP10 VaiNet Access Points in the presentation. Even though the AP10 is made by Vaisala, I tend to think of it as a piece of network equipment that is the responsibility of IT, just like any other wireless gateway like a WiFi Router. But still, such devices do need updating and validation/qualification. This should be performed under Change Control, and the validation testing will be comparing the before and after conditions to show they are equivalent. So this might look like a series of steps like this:

• Capture a “before” screenshot viewLinc of Device Manager showing the connected AP10 and which RFL100 dataloggers are using that AP10. 
• Generate a “Before” Location History Report showing that the RFL100 data loggers are connected and actively collecting data. 
• Document the “Before” Firmware level of the AP10 from viewLinc. 
• Update the AP10 Firmware following best practices for your device and restart the device. 
• Capture an “After” screenshot viewLinc of Device Manager showing the connected AP10 and which RFL100 dataloggers are using that AP10. 
• Generate an “After” Location History Report showing that the RFL100 data loggers are connected and actively collecting data. 
• Document the “After” Firmware level of the AP10 from viewLinc. 
• Compare the before and after screenshots/reports to document that the system before and after are equivalent. (You might need to adjust this a little bit, as the RFLs might switch to another available AP10 while you are updating the firmware, depending on how you have configured your system.) 

4. Where can documentation and support be obtained?

Q: How do I request an unexecuted copy of the protocol under our agreement? Where do I find the Server Migration Service protocol?

A:

Reach out to helpdesk@vaisala.com and the Tech Support team will be able to provide you with the latest documents for your version of viewLinc. This is your best point of contact for any service, support, or LCMA (Life Cycle Maintenance Agreement) items.
 

5. Will we be notified when updates are available?

Q: Regarding the software update process, do you provide a way to be notified when a new update is available or do we have to continually search to see what the latest update is?

A:

We do notify users and customers of software updates. The challenge for Vaisala is knowing how to contact you. The software team rarely knows who to contact at a customer, as usually our contact information is for the wrong people. Roles at customers change often, and they do not notify us when there is a new point of contact for the person with overall responsibility for viewLinc administration,  We know the person who was our contact at the time of system implementation, we know the email address that we were given for the main viewLinc administrator, and we know who purchased the LCMA (Life Cycle Maintenance Agreement) if you have one.  

But these email addresses, if they are still in use, usually don’t direct our communications to the people who need to or want to know about updates. What usually happens is that Vaisala gets contacted when things aren’t working, and at that time it’s a little late for a proactive update process.

My recommendation is that you check this page: viewLinc Errata and Service Update Guide

You could even write this into your SOPs to be part of the annual review of viewLinc, where you might check to make sure your users still work for the company, or that your viewLinc configuration hasn’t accidentally been changed.  Simply add to this SOP that you visit our website and check to see if there are any issues with your current version of viewLinc, and what new features may be available in more recent viewLinc versions.

If you want to have more of a white glove service, you can email helpdesk@vaisala.com and ask them the latest version. If you have an LCMA, you could use that touch-point with our Tech Support team to update your  contact information in our systems.
 

6. When will the next versions be available?

Q: Do you know when viewLinc 5.2.3 or 5.3 gets available? We are currently on 5.1 and waiting for 5.3 or 5.2.3 to upgrade directly to that version.

A:

Current plan is to release 5.2 SU3 at the end of June, and 5.3 SU0 in the summer of 2027.

Final thought

Looking across these questions, a consistent pattern emerges.

The focus is not on new functionality.  The focus is on whether systems remain in a controlled state over time.

Systems do not operate in a static environment:

• IT policies evolve 
• Security requirements change 
• Underlying technologies shift 

A system may continue to operate without visible issues, while gradually drifting away from the conditions under which it was originally validated.

Conclusion

Updates are not about chasing the latest version.

Updates are about ensuring that systems continue to meet the requirements for their use, while ensuring that they remain validated.

Because in GxP environments: Control is not defined by whether a system continues to run, but by whether it can still be demonstrated to be in control.