Emerson Exchange 365

• Not Answered

DV Database rollbacks after migration to V14.3.1

Few months ago the company I work for upgraded from DV V11.3.1 to DV V14.3.1.

From that time, I noticed occasional and apparently random DeltaV database rollbacks. This applies to expressions in phase actions / EM commands. The structure (phase step connections, number of actions etc) remains the same, however expressions seem to be rolling back to previous values. The database gets extended clean up every night.

Has anyone noticed such issue? What can be the root cause?

Thank you

Thomas

ThomasZiel

• 27 Apr 2020 12:27 PM
• Cancel

3 Replies

• Lun.Raznik

  

  • 27 Apr 2020 4:05 PM

  Just to clarity, you please define what rollback mean? VCAT can do rollback but someone needs to manually download the changes for that to take effect.
  
  And to add context. DeltaV generally have offline configuration supported by Objectivity database and then online or running configuration. The online configuration is owned/downloaded to the controller/workstation and generally does not change without explicit download.
  
  So, are expressions changing offline or the values are changing online?

  • Cancel
• Andre Dicaire

  

  • 27 Apr 2020 4:36 PM

  Thomas, There was an issue in v11 and previous versions of DeltaV where the database could find itself with Embedded blocks that were referenced by multiple modules. An Embedded block is technically supposed to exist in the context of one module, as opposed to a Composite block that can be inserted as a Linked Composite. When you create or convert a block to an embedded block, it gets a system assigned name that is a Globally Unique ID or GUID.
  
  In our SIS system, the Logic solvers will reject a configuration that has two or more SIS modules that reference the same Embedded block. This has always been the case. If the SIS modules referencing the same Embedded block were assigned to different logic solvers, the configuration would download successfully. Only when they were assigned to the same LS did the download get rejected.
  
  However, the DeltaV controllers were not so picky, so you could have embedded blocks that were referenced in multiple modules.
  
  In v12, the Import utility will reject a module that references an embedded block that is already referenced and the uniqueness of each embedded block is enforced. So the Migration Utility will evaluate the configuration and any where that a multiple reference exists, it creates a new copy of the Embedded Block, and references this new block in the second module. More copies are made for every additional module reference to the same Embedded block.
  
  I'm getting there.
  
  When we modify a parameter in DeltaV, the FHX will contain a override statement indicating the "latest" value for the parameter. On the system where I experienced this, the configuration had been created from a single original module that contained an Embedded block and this module was copied externally as an FHX to create multiple instances that were to be identical. Before the copy, the Embedded block had been refined and adjusted to get the desired working logic, including some adjusted parameters. When you adjust the block parameters from inside the Embedded block (Drill down), the overrides are placed in the block. When you adjust the exposed parameters of an embedded block from the module level, the override applies at the module.
  
  Once the modules were copied and created, the user never adjusted the Embedded block parameters by drilling down into the block. They adjusted timers and such from the module level. If they had modified the Embedded blocks, they would have saved with unique GUID's and overtime, every copy would have had its own dedicated Embedded block, but they did not.
  
  Here it is.
  
  When they migrated, the v11.3.1 FHX contained Embedded blocks referenced by multiple modules. The migration utility created new blocks and linked each to one module. The problem is that the new embedded blocks had a new date code than the module they were linked to. This resulted in the overrides in the Embedded block to be imported over that of the overrides in the module. Now these modules had the wrong values in them.
  
  If you compare your v11.3.1 FHX with the migrated one, and this is the source of your issue, you will find Embedded blocks in v11 that have multiple modules assigned. However, in v14.3.1 FHX, you now find additional Embedded blocks and each has one module defined.
  
  I don't know if this explains your situation, but it is a known issue when migrating from v11.3.1 or earlier. If you migrated v11 to v12 and then v12 to v14, you should investigate this. I don't know if this was ever addressed in the v13 migration utility, and whether migrating from v11 to v13 and then v13 to v14 would yield a different result. All you need to do is find one instance of an embedded block with two or more module references and you confirm this is possible. You would then need to confirm if your issue involves embedded blocks. Any affected configuration that is contained in an Embedded block is a likely candidate to be seeing "old" data showing up after migration.

  Andre Dicaire

  • Cancel
• Dave Ward

  

  • 28 Apr 2020 12:39 AM

  Great Logic,

  This is the Thinking Demming used in the 1950’s

  Compare one that works with one that does not

  What is different

  Make the one the does not work the same as the one that does

   

  • Cancel