Upgrading from v7.30 SR1, v7.40, v7.40 SR1 and v8.0
- Check that you have added the following parameters on the .INI file to all your server nodes before you start the online upgrade:
- Add the following parameter on the .INI file to all your server nodes before you start the online upgrade.
- Restart the servers after adding the parameter for the changes to take effect.
- On the primary server:
- Before stopping the primary runtime, validate dynamic one-line pages, device communications, and Event Notification Module (ENM) operation if installed.
- Shut down runtime on the primary server.
- Validate one-line pages, device communications, and Event Notification operation on the standby server. You should see a messages similar to this in the ENM diagnostics tab (
http://localhost:85 ) on the standby when it becomes active. - If the standby server has not assumed ENM operations the primary server will have to be brought back online. You will have to troubleshoot the system redundancy.
- Upgrade the primary server according to the Offline upgrade.
- Place the backed-up Alarm database in the [CtEdit]Data directory. This will allow a quicker synchronization of alarm servers.
- Restart the primary server. It is now upgraded.
- Check all functionality on the new Power Operation 2022.
- Check the dynamic one-line operation, device communications, pop-up graphics, the alarm log, and any other critical functionality. Validate that the ENM emails are being sent through the ENM standby server (Diagnostics tab, "Email Sent..." messages). If possible, validate the emails from other alarms.
- Power Operation 2022 server will synchronize its alarm database with the running older version standby server.
- When the Alarm Servers synchronization starts you should see the following message:
Alarm: Peer update request sent. - Then you should see a number of messages with Update packets (number is dependent on your Alarm historic events and configuration).
Alarm: Update packet XXXX received. - Finally, the following messages will indicate that the synchronization has been finalized successfully:
Alarm: Database objects state synchronization completed.
Alarm: Database is initialized, preparing to Start the Alarm Engine.
Alarm: Starting Alarm Engine.
Alarm: Server startup complete. - Verify event notification functionality on the Primary Server.
- Upgrade your client nodes one by one. On each client complete the steps 1 through 3 and 7 of the Offline upgrade. In step 2, only the citect.ini file is relevant for client machines. When the newly upgraded v2021 server assumes the primary server role it will migrate the entire alarm database to the new format, and you should now be able to see Alarm Summary data on all migrated Clients.
- After you are confident that synchronization of alarms, trends etc., is complete, and that your v2022 clients are working correctly, shut down the standby server and confirm operation of the new Power Operation 2022 primary server. Verify correct operation of dynamic one-lines, device communications, and event notification operation on the primary server.
- Now that the standby server is upgraded, restart it and check system functionality:
- Check for hardware alarms when it is connected to the primary server.
- Check dynamic one-line operation, device communications, popups, alarm log, etc. Validate that the heartbeat notifications are being sent from the primary server's event notifications system. If possible, validate emails from other alarms as well.
- If there are issues with the advanced one-line displays, begin troubleshooting with the AdvOneLineStatusLog, found in your project folder.
-
Restore and check event notifications on the Standby server:
On the Primary Server, open the event notification settings and save the settings. Accept the prompt to automatically synchronize the configuration to the Standby Alarm Server. See Creating Notifications.
Verify event notification functionality on the Standby Server.
- Check functionality of the system as a whole. It is a good idea to check the log files in the [Logs] folder on both servers. There may be errors about deprecated parameters being used, invalid file paths, logins from clients that weren't upgraded, untrusted connections (clients/servers with different Server Passwords), or other errors.
- Finally, test redundancy by switching off the primary server and checking that the standby server takes over Event Notification and Power SCADA clients all switch over.
- On both servers remove upgrade-related parameters that were set in prerequisites for an Online upgrade and parameters noted Troubleshooting online upgrade.
For v7.30: [LAN]EarliestLegacyVersion = 7300.
For the other versions: [LAN]EarliestLegacyVersion = 7400.
Wait for the synchronization process to finish; this will depend upon the size of your alarm database. The synchronization information is available from the main kernel window of the Alarm Process and the syslog.
Check the status of the alarm server synchronization using the Alarm Server Kernel, on the Main Window:
Trends from the Standby server will fill the time period the Primary server was offline. Monitor the Kernel pages PAGE QUEUE TrnRdn.GapFillDelayQue
and PAGE QUEUE TrnRdn.GapFillSentQue
. Wait for the queues to be empty before shutting down and upgrading the standby server, if possible. Go to the AVEVA Knowledge & Support Center website for information on Plant SCADA.
It is helpful to leave one client on the existing version of the software in case there is anything not functioning properly in the new version. This is also helpful in order to verify if anything was negatively affected by the upgrade versus having been non-functional prior to the upgrade. Once both servers have been upgraded, these clients will need to be upgraded as well.
Special Considerations
Alarm Summary
The 2022 Summary feature will be disabled when connecting to a v7.30 server. You may still see summary records for active alarms.
Alarm Save Files
When doing an online upgrade from v7.30 to 2022 check that any pre-7.20 Alarm Save files are removed from the 2022 project folders (e.g. <project_cluster>_ALMSAVE.DAT and <project_cluster>_ALMINDEXSAVE.DAT)
Historical Alarm Events
Set the [Alarm.<Cluster Name>.<Server Name>]ArchiveAfter .INI parameter to a date prior to the earliest historical event date from which you want to migrate.