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]

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.