named set

I remember when I took the DeltaV class in Austin (implementation 1)...and my memory is very fuzzy on this (which is why i am scared) there was a horror story shared with the classroom.

An example was given where someone changed a named set then either did not download it, or downloaded a workstation before a controller....or something? ......and it caused the entire control system to crash and then the entire control network had to be redownloaded. (extended plant downtime occurred).

What am I talking about?  does anyone remember?

I am currently scarred by this story and I dont like downloading changed setup data on a controller.  Someone please let me know how a system can crash due to named set changes.  If I know what causes problems I can be more confident it wont happen to me.

  • What DeltaV version are you using?
    Are you adding a new NamedSet, or modifying an existing one?

    I have had zero issues with adding new NamedSets and then downloading Changed Setup Data to controllers.

    However, there are some KB articles for v 14 regarding Controller Deadlock can occur if the State Mask configuration does not
    match the NamedSet configuration in an EDC Block.

    I would be leery of modifying existing NamedSets.
  • An entire control system crash is nearly unheard of. But it did happen. The incident you are describing was due to a software issue. Basically a 1-256 issue in the database vs. a 0-255 issue in the communications layers of DeltaV (or similar, but this simplifies what happened so we can understand...). When a full name set of 255 was configured, index 256 was allocated in the communications layer, which didn't have a place for that last value. As soon as auto-update / yellowpages distributed that named set to all nodes, every node (computer and controller) experienced an allocation failure in one of the communication tasks and that task failed. From the outside view, everything crashed.

    I was one of the support engineers that took that call and helped determine the root cause. The system was in staging and not yet on production. To the best of my knowledge, this only happened the one time. I wouldn't call it extended plant downtime as the customer was able to tell us he'd just changed a named set and as we looked at the configuration, we noted a set was 'full' and it took very little time for us to suspect that was the issue and test / duplicate the symptom and offer a workaround. This issue was published in KBA AUS1-115-010423161631 Addendum to V5.3SP1 / V5.3.1 Release Notes as issue 33294. (23-MAY-2001).

    Many customers mitigate the unintended behavior risk by having a separate development system to test configuration changes before introducing changes to the production system. I get that it may not be possible to have a development system. One has to weigh the risks vs. the benefits to justify that cost.

    I'm not a configuration expert by any means, so I am not in a position to offer what is or isn't likely to happen on a name set change. But the incident you heard of did happen and resulted in design and test changes so that something similar shouldn't make it to released software ever again.
  • In reply to KeithStThomas:

    yes that is it! ok please let me know the KBA #

    and we are using 13.3.1
  • In reply to Petrisky:

    NK-2200-0045