*** 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
  • Hello
    I was happy in mid-November, when you officially confirmed that it was updates that created alarm problems.
    Only then could I breathe out & use the workarond that restarted the standby alarm server every hour.

    ** Tried most things before, because in July computers were changed from Win7 to Win10, Citect was upgraded from 5.40 to 2018 R2, with latest update (July).
    - checked Windows 10 security, firewalls, creating hosts locally on computers, Network monitors, but nothing helped until November when you confirmed the bug :).
    ** Noticed i.a. that if dynamic IP was used, alarms could start appearing again if networks were restarted on the faulty alarm client ..

    I was happier that you have now released an update that fixes previous alarm problems!
    - - in addition to redundancy, computers are used for load distribution for e.g. sql export to different databases, and it was discovered after a while that some functions were running at the same time as the standby alarm server was restarted, so had to adjust a little more ..


    I will update on Citect which has 5 servers ..
    2 redundant I / O servers & 2 redundant alarm / trend / report servers on a cluster, and an I / O server on its own cluster.
    All 5 citect PC servers have dual networks, a private lan, and a common lan that is primarily used for communication between citect computers.
    Since Scada is used on a CHP plant and district heating network, where minimal downtime is a requirement, it is probably an online upgrade with parameter adjustment [Alarm] JulOctOnlineUpgrade = 1 to be used.

    To avoid unnecessary interruptions, I want to be pretty sure that the upgrade order will be correct.

    Is it correctly understood that parameter adjustment only needs to be done on Alarm servers (2 pcs)?
    ** There are 3 more Citect I / O servers, in addition to the 2 alarm servers.

    Will it work well if the upgrade takes place according to this for the 5 Citect servers?:
    1. Primary Alarm, clust 1
    2. Standby Alarm, clust 1
    3. Primary I / O, clust 1
    4. Standby I / O, clust 1
    5. No Redundant I / O, clust 2

    - Or should all Primary regardless of IO or alarm server be done,??
    Ex;
    1. Primary Alarm, clust 1
    2. Primary I / O, clust 1
    3. No Redundant I / O, clust 2
    4. Standby I / O, clust 1
    5. Standby Alarm , clust 1.

    ** All I / O servers are also alarm clients

    Thanks in advance!
    // Michael
Reply
  • Hello
    I was happy in mid-November, when you officially confirmed that it was updates that created alarm problems.
    Only then could I breathe out & use the workarond that restarted the standby alarm server every hour.

    ** Tried most things before, because in July computers were changed from Win7 to Win10, Citect was upgraded from 5.40 to 2018 R2, with latest update (July).
    - checked Windows 10 security, firewalls, creating hosts locally on computers, Network monitors, but nothing helped until November when you confirmed the bug :).
    ** Noticed i.a. that if dynamic IP was used, alarms could start appearing again if networks were restarted on the faulty alarm client ..

    I was happier that you have now released an update that fixes previous alarm problems!
    - - in addition to redundancy, computers are used for load distribution for e.g. sql export to different databases, and it was discovered after a while that some functions were running at the same time as the standby alarm server was restarted, so had to adjust a little more ..


    I will update on Citect which has 5 servers ..
    2 redundant I / O servers & 2 redundant alarm / trend / report servers on a cluster, and an I / O server on its own cluster.
    All 5 citect PC servers have dual networks, a private lan, and a common lan that is primarily used for communication between citect computers.
    Since Scada is used on a CHP plant and district heating network, where minimal downtime is a requirement, it is probably an online upgrade with parameter adjustment [Alarm] JulOctOnlineUpgrade = 1 to be used.

    To avoid unnecessary interruptions, I want to be pretty sure that the upgrade order will be correct.

    Is it correctly understood that parameter adjustment only needs to be done on Alarm servers (2 pcs)?
    ** There are 3 more Citect I / O servers, in addition to the 2 alarm servers.

    Will it work well if the upgrade takes place according to this for the 5 Citect servers?:
    1. Primary Alarm, clust 1
    2. Standby Alarm, clust 1
    3. Primary I / O, clust 1
    4. Standby I / O, clust 1
    5. No Redundant I / O, clust 2

    - Or should all Primary regardless of IO or alarm server be done,??
    Ex;
    1. Primary Alarm, clust 1
    2. Primary I / O, clust 1
    3. No Redundant I / O, clust 2
    4. Standby I / O, clust 1
    5. Standby Alarm , clust 1.

    ** All I / O servers are also alarm clients

    Thanks in advance!
    // Michael
Children
No Data