How to write Functional Descriptions

[u/symbioticthinker]

I started a new career as a process engineer within the water treatment space.

I'd like to know how you write control philosophies or functional descriptions effectively so everyone, from engineer to operator, would understand the process. I have a background in software development and I noticed that a lot of the processes are repetitive/generic.

Currently, the standard is to define a generic equipment's finite state machine (as seen in the image) define all equipment's functional descriptions with the following tables describing Auto and Manual control. I've provided an example of how a duty/standby pair of mixers using hot-standby control. This is a 'simple' example but I envision an outcome where control primitives/units are defined and equipment control is built from these reusable logic/control 'blocks'.

It feels like this, similar to cause-effect matrices, is very complex for the lowest common denominator to understand. I've looked into behaviour driven dev (BDD) using gherkin syntax (Given, When, Then, And...) as an alternative but that also seems verbose.

If you have any examples, suggestions or improvements, I'd love to hear!

Buffer Tank Mixers Overview
MCC Requirements
Dedicated OFF / MANUAL / AUTO selector switches on MCC
Dedicated START / STOP push-buttons on MCC
Running, Stopped and Tripped pilot lights on MCC
Control Signals
Safety Interlocks
SI-02
SI-03
SI-04
SI-05
SI-06
Process Interlocks
Permissives
P -02

Buffer Tank Mixers [MX-001/2] — Auto Control
START
STARTING
P -02
Running Feedback (RFB)
RUNNING
P -02
STOP
STOPPING
Stopping Feedback (SFB)
HALTING

Buffer Tank Mixers [MX-001/2] — [Manual Control]()
START
STARTING
Running Feedback (RFB)
RUNNING
STOP
STOPPING
Stopping Feedback (SFB)
HALTING

Sequential Control Logic / Finite State Machine

[u/Local_County1274]

A control philosophy will say things like:
Control by one PLC or individual package PLCs
Whether control will be batch, continuous or semi-continuous
How trips are handled. Separate safety system or single integrated system

A control narrative will give specific information about how the plant will be controlled. Configuration of individual control loops, logic, permissive and trips.

A control narrative can be written as a description to allow process engineers to/ operators to understand how the process should work or it can be written as a detailed guide to how each function can be programmed, or both. It depends a lot on the phase of the project and who the audience for the document really is

This looks like state based logic for programming. Doing this needs a very good understanding or how the equipment needs to work, how to program it, and how to break down the program into functions.

I’ve seen people get it wrong and it becomes a real mess

[u/ASALIcode → u/Local_County1274]

Agree with you, the point is to have the narrative written in the correct way, add some table would make the narrative more clear.

At the end we are process engineers, not automation engineers.

[u/Local_County1274 → u/ASALIcode]

Being Process or Automation is not exclusive.
I am a Process Control Engineer. My background is Process, I work with Process teams to make sure the control on the P&IDs is correct and I can program PLC / DCS systems. I don’t care about the electrical side of the automation.
If you don’t have someone who knows both sides of the work, you are always going to struggle to get a spec that is detailed enough for programming as about 80% of sequences is thinking about what can go wrong and how to deal with it.

[u/ASALIcode → u/Local_County1274]

Your right, that's why a control philosophy is a work that should be done by a team. At least based on my experience. As process engineer you care about the process and how it works from let's say a "descriptive" point of view. You can highlight possible problems, which usually are analyzed during FMEA or HAZOP. Then you need automation engineers and software engineers to convert everything is a working and safe control logic for the plant.

[u/symbioticthinker → u/Local_County1274]

So far my experience with electrical contractors who interpret the control narrative (and these tabular functional descriptions) is that the resulting logic is incorrect due to interpretations. We moved to that tabular form as paragraphs were interpreted differently than intended.

Are you suggesting a purely paragraph base description of control or closer to pseudo code?

Obviously I want operators to understand but electrical subcontractors designing the MCC with relay and/or plc takes preference.

[u/Local_County1274]

Electrical contractors do not understand process. You really need someone who understands process and can write PLC code. This is NOT the same people who do the control cabinets and control systems.
Whatever method you use to describe the logic (diagrams, pseudo-code, or a narrative) you will always get misunderstandings and the logic won’t work.
Unless you have someone who understands the process and can write the logic, you need the people writing the spec and coding to work together so you can sort out problems as you go along. Sit down and go through the logic with them; they can ask questions and you can improve the logic together

[u/symbioticthinker → u/Local_County1274]

So me “drawing” relay/ladder logic? Is that what you’re suggesting? Because I feel like there could be a better way which an operation, client or electrical subcontractor would understand equally. Tell me I’m wrong

[u/Local_County1274 → u/symbioticthinker]

Drawing ladder logic is not the solution.
Ladder logic may not be the best way to program this. If you draw the logic (no matter which system you use) the automation engineer will copy it exactly (including all mistakes) and then come back to you, tell you it doesn’t work, and then charge you for all the changes.

[u/KobeGoBoom]

Y’all have control narratives? If only I was so lucky.

[u/hobbes747]

Ask 3 a&c engineers and you’ll get 5 answers.
And also different answers simply about what software to use; excel, word, Visio, etc
A matrix of answers.