DeltaV FHX exports: compare, review and trace every configuration change

On a running plant, the risk in a DeltaV modification rarely lies in the change itself. It lies in what nobody noticed: a parameter changed by accident, an older version of a module brought back, a quick fix made during a shutdown and never documented.

FHX exports give us a simple and robust way to see exactly what changes, before and after a modification. No special software and no guesswork: just a disciplined use of a file that every DeltaV system can produce. Here is how we use it on our projects.

What an FHX file is

An FHX file is a text export of the DeltaV configuration: modules, function blocks, parameters, sequences and their settings, written out as readable text. That has a very practical consequence: any text comparison tool can show the differences between two exports, line by line. Answering the question “what is different between these two versions?” does not depend on memory or on someone's notes.

We use that property in four ways.

1. Compare two exports to see what really changed

Comparing a fresh export with the previous backup shows the real difference between two points in time, module by module and parameter by parameter. It is the quickest way to:

• confirm that a modification contains what was requested — and nothing else;
• detect changes made outside the planned scope, for example a tuning parameter adjusted on site;
• rebuild the history of a system when documentation is missing or out of date.

  MODULE  FIC-101
- PID1  GAIN         1.2
+ PID1  GAIN         1.5
  PID1  RESET        30 s
- HI ALARM LIMIT     85 %
+ HI ALARM LIMIT     90 %

The comparison works best with discipline on the export side: the same scope each time, consistent file names and a dated folder, so that two exports of the same object can always be put side by side.

2. Review a modification before it reaches the running system

On a live plant, we prepare and check modifications away from the running system whenever possible — on an offline copy or on a virtual machine — and export the result. Before anything is imported, that export is compared with the current configuration and reviewed:

• does the difference match the change request, item by item?
• are parameters, alarm limits or interlock settings affected that should not be?
• is the change consistent with the functional analysis and the parameter list?

The review can be done by a second engineer who was not involved in the modification — exactly what a four-eyes principle requires. The implementation itself is then planned with operations, like any other change on a running plant.

3. Prepare bulk changes consistently

Some modifications concern dozens of similar objects: the same alarm text on every pump, the same parameter on every valve module, a new naming convention. Clicking through each object one by one is slow and error-prone. Because the export is text, similar changes can be prepared in a consistent way and then checked by comparison: every modified object should show the same, expected difference — and nothing else.

The comparison is what makes this safe. A bulk change that cannot be reviewed line by line is not one we would put on a running plant.

4. Keep a clean history: what, when and why

A dated export before and after each modification, stored with the reference of the change request, builds a history anyone can read:

• what changed — the comparison between the two exports;
• when — the dates of the exports and of the implementation;
• why — the change request, deviation or punch item that triggered it.

When an auditor, a client or a colleague asks why an alarm limit was moved, the answer takes minutes rather than days.

Why it matters for management of change

Management of change (MOC) on a control system is about knowing that what is configured is what was approved. A disciplined use of FHX exports supports each step:

• impact assessment — the comparison shows the full extent of a change, not only the part someone remembers;
• approval — reviewers approve a concrete difference, not a description of it;
• implementation — the export taken after the change records the configuration as it now stands;
• audit — the archive of exports and change requests still answers questions years later.

In regulated environments, GMP pharma in particular, this traceability is not optional. But in chemicals or oil & gas too, it is what allows a team to modify a running plant with confidence.

In short

FHX exports turn configuration changes into something you can see, review and archive. Used with a little discipline, they make management of change safer and audits painless. Need an extra engineer for modifications on a running DeltaV system? See our DeltaV engineering services.