Factory Automating Process - start to finish

[Jieve]

Question for you guys who work for yourselves or for companies as programmers:

What is the process by which your customers convey to you the information necessary to complete a job from start to finish? Do you just show up, sit down with them and they hand you a book of their required specs and you just go from there? Or is there lots of discussion between you and those responsible for the plant? And who exactly is in charge of determining what specs are necessary for the machinery, is it plant technicians, maintenance? Or is it someone higher up, engineers who designed the plant layout maybe? Do they usually give you documentation directly from the machine designers/builders to work from or is there a lot more involved documentation? And what kind of documentation, do you get more technical docs like function charts and wiring diagrams, or what exactly?

If you could explain from your experience how the process usually goes, in what order with whom and what docs that would be great, as no One has ever really explained to me the bigger picture of how all of this stuff comes together.

Thanks!

 

[RheinhardtP]

To start the process of i would request a functional specification from the client. This would normally be a point where process engineers were already involved to define operation, general equipment ect.

The clients standards are at this point passed on and we will generate a quotation based on these parameters. A draft Rev 0 P&ID would be present if you are lucky.

When initiating the detailed design the focus would move to the P&ID, Control Philosophies,Single Line Diagrams, Loop Drawings and all associated design documentation.

This will kick off with a "HAZOP" where all plant engineers and stakeholders would be present.

We would then do reviews of all design documentation and would Issue Rev 1 - "For Client comment".

After extensive sessions with the client we would then update all drawings and have the associated documents issued to Rev 2 - "Issue for Approval".

After the initial approval and some more reviews meetings ect. We would have a issue for construction. Rev 3 - "Issue for construction".

During the development of documentation the software development carries on in parallel, this normally happens on client standards but if they dont have standards we ensure they "sign off" the standards to be used this will define control modules. Symbol display colors alarms and everything associated with the software.

We have initial sessions to show each type of symbol/block to be used within the software to sign off the functionality only then we commence with populating plant areas with these standard symbols and blocks.

When then Have a Factory Acceptance Test (FAT) that shows the process, sometimes we might have some simulation software running in the background for a proof of concept.

Before actually taking the control panels or MCC to site we then have a Site acceptance Test (SAT). This test the interface of the software with the actual control panel and we would test all IO in a Simulated fashion from the Field connection terminals through to the SCADA layer. This ensures that when you are actually on site minimal work goes into the panels and the focus remains on devices in the field.

Throughout this process the client sign off "punch" items that are generated during all the tests/reviews with the client. Having everything documented gives you good visibility on items that require focus, and ensures that scope creep is dealt with in a managed fashion.

After SAT and all document are at R00 Issue for construction, we mobilize on site and start installation. All commissioning sheets are documented for sign off purposes. The client has a representative witness and sign off each piece of kit that is tested.

Documents we use are-

1. Functional Specification
2. P&ID's and PFD's
3. Instrument Data Sheets
4. IO Lists
5. Single Line Diagrams
6. Motor Circuit Schematics
7. Cable Racking and Routing Diagrams
8. Cable Lists
9. Lighting and Power diagrams
10. SAT sheets per device
11. Commissioning sheets per device
12. Alarm Lists
13. Instrument Hook Up drawings
14. Instrument Location Drawings
15. Earthing drawings
16. All associated training documentation required to operate the plant.

I cannot understate the importance of customer involvement and sign off during the review processes. They are the ones that sign of your plant and pay you. There will always be scope creep and if not documented properly can cost your company a fortune in hardware and "man hours".

That is the process in short we follow. One last piece of advise. Never mobilize on site unless your software and panels have been tested in a controlled environment.

I know you asked from a programmers view. I think it is important to understand all the dependencies that go with ensuring you receive the correct documentation to code properly.

Rheinhardt

 

[JeffKiper]

Excellent write up.

 

[Jieve]

Rheinhardt,

Thanks so much for that detailed description. I admit I had to look up a good number of those acronyms. So your description at the start was assuming the plant equipment had not yet been installed, like füll plant build from start to finish, correct? And does the software writing start immediately after the functional specification is received? Is there enough information in there to get a lot of what needs to be programmed completed? And I'm curious, from what perspective is this information coming from? It seems you're involved heavily in the equipment layout, machinery and control components as well as the programming.

My knowledge is somewhat limited in this area, a previous co-worker spent a number of years writing industry plc programs, mostly in the automotive industry but he worked for an independent company. In most of the auto assembly lines, he said everything was already installed on site, and they wrote the programs On site. He gave me the impression that this is how its generally done.

 

[RheinhardtP]

Rheinhardt,

Thanks so much for that detailed description. I admit I had to look up a good number of those acronyms. So your description at the start was assuming the plant equipment had not yet been installed, like füll plant build from start to finish, correct? And does the software writing start immediately after the functional specification is received? Is there enough information in there to get a lot of what needs to be programmed completed? And I'm curious, from what perspective is this information coming from? It seems you're involved heavily in the equipment layout, machinery and control components as well as the programming.

My knowledge is somewhat limited in this area, a previous co-worker spent a number of years writing industry plc programs, mostly in the automotive industry but he worked for an independent company. In most of the auto assembly lines, he said everything was already installed on site, and they wrote the programs On site. He gave me the impression that this is how its generally done.

Hi Jieve,

So this description was based on "Greenfields" installations , so mostly new equipment. The software development happens simultaneously with the plant design. It varies slightly in different areas of industry.

From a programmers point of view the important thing to define is the structure. This will depend heavily on what type of plant /operations you have to code for. Some plant have little to no operator interface,others are heavily dependent on human interaction.

Some plants have a set of software standards others have no standards. There are many ways to achieve the same results with code but i prefer the use of predefined function blocks. This makes duplication/ expansion quick and easy.

As for when you can start coding. A functional specification is what a programmer require to be able to code all devices and their interfaces. I would however only start off once this is signed over by the plant/process engineer.

I tend to spend most of the time creating and testing the function blocks that make out the building blocks of the software, for this you dont require the functional specification but a understanding of what the requirements are.

I spend the least time doing interlocking, creating instances of the different control modules.Again most of this depends on your project and your client.

What they need and what they want? It will vary on every project and you need to be able to adapt.

Hope this info helps.

Rheinhardt

 

[DwSoFt]

Excellent write up.

I Agree!

 

[Tom Jenkins]

Excellent, Rheinhardt. Could I have your permission to borrow some of that for classes and such?

I can't imagine anything less efficient than doing all programming on site. First off, site time is the most expensive. Second, undistrated programming time on site is hard to get until everyone else has left the plant. My experience may be skewed, since on site I usually worked perched on a five gallon bucket, but it still makes sense to me to do as much as possible before you get on site.

 

[JeffKiper]

Tom you got to love the 5 gallon bucket and laptop on your lap.

I do very little process control so this is very interesting to me.

 

[KalleOlsen]

Excellent write up.

Agree to.

Tom, my alternative to the bucket, the high comfort variant:

 

[RheinhardtP]

Excellent, Rheinhardt. Could I have your permission to borrow some of that for classes and such?

I can't imagine anything less efficient than doing all programming on site. First off, site time is the most expensive. Second, undistrated programming time on site is hard to get until everyone else has left the plant. My experience may be skewed, since on site I usually worked perched on a five gallon bucket, but it still makes sense to me to do as much as possible before you get on site.

No problem Tom you are more than welcome to grab what you need.

 

[RheinhardtP]

Agree to.

Tom, my alternative to the bucket, the high comfort variant:

Seen to many of these in my lifetime. Excellent comfort rating!!!