• Not Answered

Correct Import Sequence for DeltaV FHX Backup Files

I have a separate backup and I want to load it into DeltaV. Who knows the correct import sequence according to Emerson’s procedure?

SZ FHX, Area FHX, LSN FHX, CSLS FHX, and Modbus FHX files.

Which one should be imported first during the software import process?”

ahmedD

• 29 Dec 2025 12:54 PM
• Cancel

1 Reply

• Andre Dicaire

  

  • 29 Dec 2025 6:30 PM

  The SZ Export would contain all its hardware configuration including the LSN and Modbus mapping, as well as the hardware configuration of CSLSs defined on its LSN. The SZ controller will also include its assigned Plant Area if it is other than Plant Area A.
  
  The Plant Area FHX will contain all the modules and the Process Cell and Units defined in your hierarchy. Since you want these modules to be assigned to their controller/CSLS, you need to import the Controller before the modules.
  
  NOTE: History is defined in modules but assigned to a History server by assigning the Plant Area. All you have to do is after the import, you have downloaded the modules, simply assign this new plant area to the history server, and download the continuous Historian container.
  
  Where you can get caught is in the global items such as Named Sets, Alarm Types, Alarm Priority names, Engineering Units, etc. The Alarm priorities for instance are defined as string, so if in one system you used "HIGH" but in the destination system you have "CRITICAL", you have to align these names, which can be done by a text substitution in the FHX. Do this carefully and substitute more than just the string in question: i.e. substitute <PRIORITY_NAME="HIGH"> with <PRIORITY_NAME="CRITICAL">. That way you don't substitute the Word "HIGH" anywhere else, such as in an alarm description or in module comments and such.
  
  If you are trying to merge this configuration into an existing database, expect the assigned IP address of the SZ controller to change, and you must commission the controller into the new database. So to start, you should decommission the CSLS's and the SZ so that you import the configuration and commission the hardware in the new system. If the SZ duplicates an IP address currently used by an other device, the FHX import will change this IP address and assign a new one, but if you connect this commissioned SZ to the system, it would have a duplicate IP address and potentially disrupt communication to the existing node.
  
  I would highly recommend you create a new database, preferably in an off line system, import a total export of the existing system and then import your SZ configuration. Check for any warnings or errors and make sure this SZ import does not have any conflicts or naming issues. Once you have identified and fixed all issues, you can then take this tested FHX to your production system.
  
  If you know your global items are all identical between the systems, and that you don't have any naming conflicts, you might be comfortable importing directly to your production system (i.e. you have a true Digital Twin and you are moving a tested configuration to production). When we move a configuration from our development systems to a customer's system, we always start that configuration using a complete import from the site so we have the entire global items and Name Space at site that ensures we don't create conflicts. We also have the customer track any changes they make so when we merge, we know what we have added and can confirm there are no conflicts. If we are not sure, we perform a test import to be sure. (not everyone is diligent about changes, especially over a period of months)
  
  So the steps would be:
  
  Decommission your CSLS and then your SZ controller.
  
  
  Export the "setup" data which contains the Alarm Types, Alarm Names, Named Sets, etc.
  Export the SZ controller after decommissioning.
  Export your Plant Area.
  
  Evaluate and test as needed to ensure Plant Area FHX can import with no errors.
  
  Import new global items: Alarm Types, Alarm Priorities, Named Sets, Engineering Units, etc.
  - Import using "No To All" so that no duplicate items are over written, only new ones are added.
  
  Import Physical Network items
  - SZ controller FHX will define LSN nodes and Modbus Mapping.
  
  Import the Plant Area containing all the modules which are assigned to the SZ or CSLS's.
  
  Now you can commission the SZ and the CSLS hardware to the place holders. If you have more than one CSLS, be careful to commission the correct hardware to the intended place holder.
  
  Download the modules, assign Area for history collection and download History server's Continuous Historian.
  
  The FHX import performs many checks of the syntax and overall integrity of the data in the FHX. Importing No To All will protect the existing configuration by not allowing overwrites of duplicate named items.
  
  Again, I strongly recommend you test this before you proceed on a production database. You can create a new database from your existing system FHX export, set it active and import the new SZ and Area to do testing if you don't have a development system or other option. The most likely issues will be Alarm Priorities, Alarm Types missing, or Named Sets missing/missing Named States. If you are going to have any issues in the import, you want that to happen on a test system.
  
  Good luck,

  Andre Dicaire

  • Cancel