*** Recall of Citect SCADA 2018 / 2018 R2 Updates (July - October 2020)

Hi everyone, 

It's with regret that I share that we have identified a regression in recent Citect SCADA Monthly Updates that can affect the operational view of Alarm information including Alarm Summary, Alarm Counts, and other Alarm-related views, and it’s important that we notify our customers who could potentially be affected.

We have shared this message with potentially affected customers who have downloaded any of the following Monthly Updates;

  • Citect SCADA 2018 Update 22 (Jul 2020)
  • Citect SCADA 2018 Update 23 (Aug 2020)
  • Citect SCADA 2018 Update 24 (Sept 2020)
  • Citect SCADA 2018 Update 25 (Oct 2020)
  • Citect SCADA 2018 R2 Update 08 (Jul 2020)
  • Citect SCADA 2018 R2 Update 09 (Aug 2020)
  • Citect SCADA 2018 R2 Update 10 (Sept 2020)
  • Citect SCADA 2018 R2 Update 11 (Oct 2020)

 

The set of steps that produces this issue is complex, and involves systems including Alarm Redundancy, a large number of Clients, and events which are causing the Alarm Servers to switch roles and Display Clients to switch their connection. This can occur with cases of Domain Users and/or local Citect users. Most concerning, the occurrence of this can appear to be random, with the outcome being that the Alarm Counts, Alarm Summary and/or Alarm view components may fail silently. 

With our strongest recommendation we advise the following actions;

  1. If you haven’t yet implemented any of these Updates, postpone the installation.
  2. If you have implemented any of these Updates, uninstall these Updates and roll-back your implementation to the June 2020 Update, available from the AVEVA Knowledge & Support Center website at https://softwaresupport.aveva.com/. The Uninstallation process needs to be performed individually for each Update listed above.
  3. These Updates should be considered “recalled”; please delete any local copies so they’re not accidentally installed in future.
  4. If you have shared any of the above Updates with someone else, please also share this message with them.

 

For a Redundant configuration, our recommended order would be to first roll-back Primary Servers (across all Clusters, if required), followed by Clients, and finally any Standby Servers.

If you have any questions or concerns regarding the roll-back procedure for your Citect SCADA system, please reach out to your local Distributor and/or AVEVA Support team for specific advice – they will be your best contact for any questions.

Our investigations into the root cause of this issue are ongoing, and we will be publishing a new Update to resolve this issue as soon as possible. Unfortunately, I’m not yet able to forecast when a new Update might be available.

We have also taken the decision to delay the release of the November Update for both Citect SCADA 2018 & 2018 R2 versions as we prioritise the investigation and resolution of this issue, which is our highest development priority. I’ll provide further updates when I have more news regarding this investigation and the availability of a new Update.

I sincerely apologise for the inconvenience.

Kind Regards,

Brad Shaw
Product Manager – SCADA/HMI

Parents
  • Hi ,
    I'm sorry to hear this problem still persists for you after installing the December update.
    I would recommend you try take note of which Alarm Server the client is connected to when the problem occurs (check the Client kernel, "page table tran" window for details). It sounds from your description that the problem could be impacting Standby Server.
    Just to clarify default client behaviour, the client will stay connected to the server once connected, unless there is a shutdown or interruption on the server side. It won't switch to another server under normal circumstances. This behaviour occurs for Trend, Alarm and Report Servers. While the IO behaves differently by default. It will always switch to the "best available" IODevice, which could mean it switches from Standby to Primary under normal operations. There is a parameter to override the default behaviour for Alarm clients, such that they will prefer one specific server over the other. See "[ClusterName.ServerType]Priority=" to achieve this.
    Please continue to work with AVEVA support to help diagnose this issue. I haven't heard of any other cases with this same issue.
    Please double check what patch/update is applied on all your machines (Server and client), make sure any special parameters have been removed (only required for customers who upgraded from July-Oct patch to Nov).
    Kind regards
    Olivier
Reply
  • Hi ,
    I'm sorry to hear this problem still persists for you after installing the December update.
    I would recommend you try take note of which Alarm Server the client is connected to when the problem occurs (check the Client kernel, "page table tran" window for details). It sounds from your description that the problem could be impacting Standby Server.
    Just to clarify default client behaviour, the client will stay connected to the server once connected, unless there is a shutdown or interruption on the server side. It won't switch to another server under normal circumstances. This behaviour occurs for Trend, Alarm and Report Servers. While the IO behaves differently by default. It will always switch to the "best available" IODevice, which could mean it switches from Standby to Primary under normal operations. There is a parameter to override the default behaviour for Alarm clients, such that they will prefer one specific server over the other. See "[ClusterName.ServerType]Priority=" to achieve this.
    Please continue to work with AVEVA support to help diagnose this issue. I haven't heard of any other cases with this same issue.
    Please double check what patch/update is applied on all your machines (Server and client), make sure any special parameters have been removed (only required for customers who upgraded from July-Oct patch to Nov).
    Kind regards
    Olivier
Children
No Data