On many DCS projects, the functional specification is written early, approved, and then quietly overtaken by the configuration. By the time of the FAT, nobody is quite sure which of the two is right.
We work the other way round. The functional analysis is written precisely enough to configure from, and precisely enough to test from. When the configuration is finished, the document becomes the test script — and the FAT checks the system against something everyone has already read and approved.
Why precision pays
Every ambiguity in a functional specification will be resolved by someone: the programmer at their desk, the tester during the FAT or the operator at start-up. The later it happens, the more it costs. A sentence such as “the pump stops if the level is low” leaves many questions open: which level, with what delay, does the pump restart on its own, is there an alarm, and what does the sequence do in the meantime? A good functional analysis answers those questions before the first module is configured.
What goes into every functional analysis
An SFC or GRAFCET for each sequence
Each sequence is drawn as an SFC (or GRAFCET) with:
- every action written inside its step: which valve, which pump, which setpoint;
- every transition condition written in full, including timers and the instruments involved;
- the initial and final states clearly identified.
Written this way, the diagram can be read by the process engineer, the programmer and the tester alike — and each transition becomes a test step.
The parameter list
Every adjustable value — setpoints, timers, thresholds, alarm limits — is listed with its unit, range and default value. The list is the reference for configuration and for testing, and later for operations, when someone asks why a timer has the value it has.
The alarm and interlock database
One line per alarm or interlock, with its cause, its effect, its priority and its bypass and reset rules. The database is the single source for the configuration, the test protocols and the operator documentation. Keeping it in one structured table, rather than scattered through paragraphs of text, is what makes systematic testing possible.
What happens on failure, abort and restart
This is the part most often missing, and the one that causes most trouble at start-up. For each sequence, the analysis states:
- what happens when equipment fails during a step — a pump trip, a valve that does not open;
- what an abort does, and in which state it leaves the equipment;
- how, and from where, the sequence can restart: from the beginning, from the interrupted step, or only after checks by the operator.
Not only the happy path: the unhappy paths are where a plant spends its worst nights.
How the analysis becomes the FAT script
Once these elements exist, the test protocol almost writes itself:
- each SFC transition gives a test step: set the condition, check the change of step and the actions;
- each line of the alarm and interlock database gives a test: create the cause, check the effect, the priority and the reset;
- each failure, abort and restart case gives an abnormal-situation test;
- the parameter list gives the values to check in the configuration.
Traceability is built in: every test refers to a line of the specification. During the FAT, each deviation is clear — either the configuration does not match the document, or the document needs to change — and both outcomes are recorded.
Keeping the document alive
A functional specification is only useful if it stays true. Changes found during testing, commissioning or later modifications go back into the analysis, with a revision index and a short description of what changed. The configuration and the document stay in step, and the next engineer who joins the project — or who modifies the plant years later — starts from a reliable reference. For changes on a running DeltaV system, comparing configuration exports before and after each modification closes the loop (see our article on FHX exports).
In short
An SFC or GRAFCET with complete actions and conditions, a parameter list, an alarm and interlock database, and the failure, abort and restart cases written down: that is what turns a functional specification into the cheapest FAT you will ever do. Read more about our DeltaV configuration and documentation work.
Functional analyses to write, or to bring back up to date?
Tell us about your project: answer within 48 hours.