Control Philosophy Document

Join Date
Feb 2012
Location
UK
Posts
57
Hi All,
I have to write a Control Philosophy document describing a small automation process. I searched for sample document on Internet but couldn't find anything with Industrial Standard, there is lot of Jargon out there.
Can anyone PLEASE help me out with their previous experience or post some good Control philosophy document samples.

Thanks in Advance.đź“š
 
Is this for school, or for a customer? If it's for a customer, then I would ask for an example of what they are looking for. Control Philosophy document could mean a number of different things.

Off hand, I'm thinking of a flow chart diagram.
 
"Control philoosophy" is a pretty nebulous concept. For example, keep it simple, make the HMI operator friendly, and thoroughly document the logic are philosophies.

I suspect what the owner really wants are a functional description or loop descriptions. These typically describe the control system functions, actions on high and low readings, alarms and actions, equipment protection functions, displayed data, etc. Verify what they are looking for before you spend any time on this.
 
Just describe what the system (or the sub-section that is within you scope of supply) is going to do.

On start-up / while running / shutdown.

Also include at least a description of what or how the rest of the plant (outside of your scope) is supposed to interact with your kit.

Then get the customer to agree that's what he wants and approve it!!!!!
 
Before writing about any control method or control "philosophy", you first have to STUDY and LEARN what and how the controls should operate. That is usually the big stumbling block. The next problem is learning how to write sentences. Then you simply describe how the controls should operate. Here is an example.
 
Last edited:
A Control Philosophy incorporates the process functions on the plant and specifies the control parameters, operational and maintenance philosophies .

How must the plant control react in detail? How must operations react under certain conditions?

You mus list all interlocks, all alarms, all sequences associated with your process. If you require a programmer to code of a control philosophy you need to reflect tag details within your control philosophy.

I would break down a control philosophy as follows.

1. Plant Description - What is the plant for?
2. Process Description (Normally from Functional Specification explaining associated equipment)
3. System Parameters - Setpoints of Instruments, analogs.
4. Sequences (Startup,Shutdown)
5. System Interlocks.
5. Alarm Handling and Response.
6. Operator Functions.
7. Maintenance Functions.
8. Reference Drawings and documentation (P&ID's, Schematics ect.)


This is the one document where you can never have too much detail describing operations and control. Your amount of detail will determine how well the system integrator can program the control system.
 
Last edited:
I speak from experience, don't assume anything.
I have experience of doing a project in 2 phases where the 2nd phase went badly because the contractor used a different programmer who "Did something else" to the first programmer!!!
 
In Ozz it is usually referred to as a 'functional specification'.
Many young ****s who have some sort of degree/certificate in programming reckon they can program anything from a functional specification.
I disagree - if one does not understand the machine or process and all the required interlocks etcetera they always get into trouble.
Be extremely specific and highly detailed so you can 'nail them' if they stuff up.
 
I have to write a Control Philosophy document describing a small automation process.
The big mistake that I see all the time is not correctly defining the scope. In your case you need only describe this ONE small process. Do not try to describe the entire plant, or other lines, or the type of cheese on the moon. Stick to the job at hand and tell as much (or as little) as you know about how to make it work. Listing and trying to describe the parts that you do not understand is always a mistake.

Many young ****s who have some sort of degree/certificate in programming reckon they can program anything from a functional specification.
I am an old ****, but if I have a very well-written description, then my program will be better than if I only have someones one-line sentence from a meeting or a phone call. It all depends on the degree of detail. Yes, you can describe interlocks in a way that a programmer can translate. A very effective way is to add an Interlock list to each loop sheet.
 
Last edited:

Similar Topics

Hey! I have an .acd and .apa files from a facility (RSlogix5000) and I need to see their programming. I can't find a way to do so.I am happy...
Replies
5
Views
1,981
I have to start out by saying I am not a PLC programmer and I have basic programming skills but mainly use software as a troubleshooting tool. I...
Replies
0
Views
34
Hi, I have a 1500 that controls a station with diferents warehouses, but i also have a 1200 that controls one of those warehouses, i have been...
Replies
9
Views
208
I have to provide remote access and control to a touch screen. I was thinking about using Weintek and the Weincloud. Does anyone know if this is...
Replies
1
Views
100
Back
Top Bottom