Emerson Exchange 365

DeltaV upgrade from 8.4.1 to 13.3.1

hi 

i am going to upgrade my plant from 8.4.1 to 13.3.1 .let me know is it possible to upgrade to 13.3.1 without implementing migration path ?

migration path says :8.4.1 then 8.4.2 then 11.3.1 then 13.3.1.

samy

• 25 Feb 2018 8:11 AM
• Cancel

3 Replies

• Terence

  

  • 26 Feb 2018 6:39 AM

  No, should go to 8.4.2 at least.

  • Cancel
• Maarten van der Waal

  

  • 26 Feb 2018 9:58 AM

  Going from 8.x.y to 13.n.m requires installation on new hardware and operating system. An 'online' installation will not be possible.
  So I would advise to do an install for version 8.4.1 on a virtual machine, do all upgrading tasks (installing the required versions for DeltaV on VMs) and transfer the result to a new installed system. This way you have the minimum downtime for your plant.

  • Cancel
• Andre Dicaire

  

  • 26 Feb 2018 5:44 PM

  For a Migration from 8.4.1. to 13.3.1, you should engage your Emerson Service provider and possibly the services from the factory to assist in planning and executing your upgrade. The upgrade plan will be more complex as it must address several major changes in the database and the runtime environment. The plan should include testing of the migration as there are significant changes to database and runtime structures.
  
  If this is an offline upgrade, you need not worry about online switchover of controllers, but the migration plan should be fully understood, and a careful review of the database migrations should be done. For an Online Migration, you absolutely need to fully test the behavior of controllers through switchover. Not sure if a v13.3.1 standby will successfully become available with a v8.3.1 Active controller, and this is the crucial online requirement. The configuration will have a major impact on this.
  
  One key change occurred in v12 where the FHX import now checks for multiple Embedded block usage. Technically, an Embedded composite is only referenced by its host module. But when configurations are built by copying FHX exports and performing text replacement, the database ended up with Embedded blocks that were referenced in the database. The user is unaware of this as these blocks are named by DeltaV. If you edited an embedded composite after import, it would be renamed and the duplicate reference "disappears." The DeltaV Controllers did not care and allowed such configurations to download. Logic Solvers however rejected the downloads as they enforced unique embedded composite references within the same logic solver. But two SIF's could share the same embedded block if downloaded to two different logic solvers. Anyway, the software was updated to remove such duplicate references automatically on import.
  
  The resolution for this is to edit any modules with embedded blocks created by a copy so that the database uniquely names them prior to migration. During import, if a duplicate reference is found, the new block created to eliminate this is assigned a timestamp that can alter how the default values downloaded to the controller. When a module is edited, a user can either set the value of an exposed Embedded Composite parameter by selecting the block and its parameter, or by "drilling" down into the block to change the same parameter. If the last parameter change was done at the module level, but there were overrides made previously by drilling down in the block, the last change was at the module level. After import, if the block was a duplicate, the new replacement is time stamped at the time of import, and the override in the block takes precedence over the override in the module (the expected value).
  
  We experienced this on some modules where timer values had been tuned, but the import created the new blocks and the timer values took on the overrides of the block. All this is avoided by ensuring there are no duplicate Embedded Composite references.
  
  I mention this as an example of some of the things to be aware of, and that engaging someone familiar with upgrades will ultimately save you from what you don't know. Researching the release notes is a must, but experience in upgrades is by far the biggest benefit to the team.
  
  Your new hardware will be Server 2016 and Windows 10 based, so you will not be able to use this for migrating to a v11 (Server 2008, 32bit OS). Having a resource that can provide a temporary platform for the Pro Plus migration is also a valuable asset to the migration team.
  
  So you don't have to migrate all the nodes to the interim versions if you are upgrading off line, but you do have to migrate the database through these releases to ensure all migration related items are properly migrated.
  
  Good luck.

  Andre Dicaire

  • Cancel