Not Exactly PLC related, but pertinent anyway...

Hi guys,

In the past we have often discussed the need for thorough specifications for jobs to be quoted. Since I have never had to go outside my own shop for program development before, my abilities to develop a decent spec in that area are notably lacking.

I am hoping someone might have a nice guideline for developing program specifications and requirements.

For my particular application, I already know all my I/O and equipment...none of that is an issue. What I really don't know is how to cover all my bases when defining the program in advance.

I imagine some of you will wonder how I can know all my I/O without already knowing and understanding everything the machine must do. Well, I do know. The kicker is that the software will have to do a great deal of behind-the-scenes calculations and such and that is the part I need to contract out. What I am afraid of is my own inability to write the specification tightly enough without being too tight at the same time (if that makes any sense).

What kind of wording is best? To what level should I try to define my functions? Are there typically programming things that are "understood", and if so, what might those be?

In the end, I have little doubt that I will end up with the machine working as needed. Of that I am confident. What I want to prevent is a lot back-end development time and added expense. This needs to be a win-win situation for my company and the programmer.

Any thoughts or ideas will be greatly appreciated.

Steve

Steve

I think you rise discussion that somehow affect on most of us.
just look on robert post http://www.plctalk.net/qanda/showthread.php?s=&threadid=5357.
I never thought to argue on what is PLC.
So Its we hard for me to express my self in English like I do in Hebrew but as someone who running business for over then 15 years.
I have some rules:
1.Never write specification in rash.
2.Dont be lazy and dont save word.
3.Spend time with your customer and dig all the info he have. detailed your understanding on the proposed system.much as you can.
your customer read that and can give you feedback,and allways you can say that what I understand and that what I did.and that part of your contract.
4.Before you send quot spend time and think well how to do the job other wise you will spend time and money in the future.
5.write down how much inputs and outputs you offer.in that way your customer canot came and ask for extra with out to pay.
6.detailed all the equipment you supplying models manufacturers etc.
7.Add at least 10% to your quot as un known expenses. for future problems.Dont forget "Merfy never sleep"


I hope in the end of this topic we will get model of specification
and quotation for the benefit of all of us.

I forgot very important thing

Dont fall to the trap which call "Customer specification".
Read it very carefully.If you going to change something ask it written.

Steve-
Arik's point #2 is the most important in my view. If you have to ask yourself if it needs to go into the spec, it needs to go into the spec.
You sound like you know exactly what the machine needs to do. That is usually the most difficult part. Don't worry about specifying your programmer into a corner unless you hope you will get a better baseline machine design or operation sequence out of them. If you know what you want, put it down.
I work for a custom equipment OEM. Our customers often know what they want in pretty good detail before they come to us. What I like to see is a macro-to-micro approach.
1) Assuming you don't give away proprietary information doing it, indicate in as much detail as you can what the machine/section does. If this is a section of a larger in-line process, some details on upstream and downstream equipment can also be helpful as well as upstream/downstream information interface.
2) Provide a sequence of operation from the operator perspective. What is the operator supposed to do and what devices/functions need to be provided to allow this.
3) Provide a machine sequence of operation for any automatic functions.
4) List the major machine sub-systems. A quick piece on what they are and what they are supposed to do is very helpful.
5) Include a complete I/O list includign function and component type (if you know that already).
6) Detail the major subsystems. Indicate any minor systems as well as any I/O associated with this. This is where you would list any calculations that are required. If you know algorithms, list them. If you have a desired function instead, just list that.
7) Make sure the operator interface requirements are known. This may be a separate issue but sooner or later there needs to be a mating of addresses.
8) If you have any personal/company programming standards also list them. If you don't like indirect addressing or lots of subroutine calls, make that very clear. This is the most variable part of the process. People will program how they feel comfortable unless told to do otherwise. Make it VERY clear if you have and specific programming forms you want followed. Don't assume anything here.

It sounds to me like the hard part will be you are too close to this. You will need to really be careful you don't leave something out because you unconciously assume it is common knowledge. It's just human nature. Programmers tend to be curious. It comes with the personality type. The more info you can include the better off you will be.

Keith

Thanks for the quick replys. You both make very good points.

ArikBy: In this application, I am actually the customer so I am trying to develop the initial scope of the project. I am pretty sure I already know who my supplier is (I believe he has a truly unique product) and from previous work with him, I feel confident he will follow your rules quite closely.

kamengas: It seems to me that your focus on sequence of operations has the right ring to it. Incidentally, my application is proprietary but I will be covering that issue contractually.

I may be that once I develop my sequence of operations that my fears will evaporate. I sure hope so. It is a good place to start in any event.

As this is a completely new design for me, I believe I am not yet too close to it (I will certainly watch out for it though). I appreciate the advise.

Steve

A sea of words in a desert of ideas

Sorry guys! By the time you have finish defining those specs, the shop might already be closed.

Of course you can define the brands and some other details to make sure of hardware compatibility. And also you can add some technological transfer prerequisites.

In the end what counts is results.

The best spec is one based on performances.

You state what needs to be accomplish with this automation job and how it will be tested. Done!

If you don't leave any freedom to the Firm which gets the contract then why don't you do it yourself. No time? Spend less time playing around with detailed specs and maybee you'll have some to do actual work.

Don't take me wrong Steve, I don't blame you to tinck about this aspect of work specification but you must realise that ANYTHING YOU LEAVE OUT IS NOT YOURS TO DECIDE ANYMORE.

If your specs are too tight you will see that the Firm will go for those details you left out.

I have a very good relation with my clients. They usually ask of me to help them accomplish things. I submit my hunderstanding of what they want with what they need and what they can afford and they always end-up with a little bit more than what was quoted. This liberty I have is because of the specs.

I have dealt with companies that have BOOKS of specs. they usually are so dumb that no one can remeber half the reasons why some of the stuff is in there.You tinck my saying dumb is unfair? Well, in a place where those specs are very rigourus for the outside guy, how do you tinck they deal with the inside people. Same thing. After a few years they don't have one once of initiative or imagination anymore.

You must have a basic specs. Keep it short, precises and again short . Whatever you write in this keeps you from some pretty nice inovations. My gosh you could even endup being stuck using AB

Spend more time on detailing what you want to accomplish. This is where you will have the biggest miscommunication with outsiders. You know exactly what you want. They don't. How to do it? Leave that to the Firm .

A standard specification is a mosnter which grows. Every time you will redefine it it will be bigger. Never smaller.

Pierre,

I want to respond to two separate issues; first, pros and cons of standard specifications and, second, my real need (which is not a set of standard specifications).

To the first point:

I absolutely agree with you that the can, and usually do, eliminate inovation and create loop-holes that create problems for both the customer and the vendor. I think you have done a good job pointing out many of those problems. I must say, though, that standard specifications also serve two very important purposes that can have far reaching value to most organizations:

1) Standardization - reduces trainings, parts inventory, and downtime.

2) Helps eliminate oversights - if certain verbage is already written in standard specifications, no one has to waste time remembering to specify them. These include things like "electrical must meet NEC2003 Code", "Vendor to supply 3 hardcopies of schematics and 1 electronic version in AutoCAD DWG format" and so on.

To the second point:

I am not interested in creating a standard set of specifications right now (I already have a set that was developed to eliminate the excess verbage I talked about above). I just want to try to find a way to document what I want without leaving large gaps and, consequently, increasing costs and delaying start-up. I am looking for structured ways to think and approach the process of doing this.

I know my vendor will happily and willingly work with me to develop a good spec as you have already talked about, but I need to be sure I can capture all my needs up front. Its probably worth noting that this vendor will be supplying very little hardware but is going to do vertually all the programming (I would certainly do the programming myself if it was in a PLC type language...it is not, though. It is in a proprietary language that is WAY advanced. I will definitely be learning it over time, but I need him to do the first round of programming).

Today, I am really just needing a good way to think it through.

Steve

more guidance

I jsut returned from a loooooooong startup where the mechanical
details were not all defined, and the installation contractor
was hired on a 'time and materials' basis.

His final billing number was very large, and the crew lead
man gave me another catch phrase to add to my lexicon:

"Where there's confusion, there's money."

Each of us, whether supplier or specifier, should remember
this phrase...ESPECIALLY when specifying something to someone
who will use the confusion to extract our money.

Steve Etter said:

1) Standardization - reduces trainings, parts inventory, and downtime.

Click to expand...

And I agree with that.

Steve Etter said:

2) Helps eliminate oversights - if certain verbage is already written in standard specifications, no one has to waste time remembering to specify them. These include things like "electrical must meet NEC2003 Code", "Vendor to supply 3 hardcopies of schematics and 1 electronic version in AutoCAD DWG format" and so on.

Click to expand...

And I agree with that.

Steve Etter said:

I am not interested in creating a standard set of specifications right now (I already have a set that was developed to eliminate the excess verbage I talked about above). I just want to try to find a way to document what I want without leaving large gaps and, consequently, increasing costs and delaying start-up. I am looking for structured ways to think and approach the process of doing this.

Today, I am really just needing a good way to think it through.

Steve

Click to expand...

And I agree with that.

These are all good intentions. Who could be against virtue?

IMHO, The only way to manage this kind of "BLackBox" is to do it in a principle oriented way.

Some of the things will automaticly be included if you start by the principles.
1. PLC Must be of the same brand and model as we have in the plant .

• 
  [*]AB model xxxx
  [*]AB model xxxy
  [*]AB model xxz

Here the principle is very clear, when you add the models you have included some precision into your specs but the principle prevents you or the next guy with your job from asking why the heck do we have only this PLC model in the specs, 5 years from now.

2. PLC programs must be well documented

• 
  [*]3 lines of comments per rung
  [*]no more than 2 parallel branches per rung
  [*]In ladder logic format

Write down the list of PRINCIPALS you want to use to guide your supplyer so he can satisfy you.

Only for inside:
Always write in advance the level of satisfaction you will accept. Write what this level means. Write down I WILL BE SATISFIED THAT THIS JOB MEETS MY EXPECTATION WHEN WE HAVE REACHED THIS POINT: and write down what it is.BEFORE THE CONTRACT GET OUT.

When you will read it later, after completion you will find that most of your expectations will have been meet and more. You will find that as the project advances you sort'a assumed some things where included but they where not.

I write specs in three broad sections, copied from the AIA (?) format.

The first is "General" with a description of the system, and includes an overall description of the project with objectives and limitiations, quality assurance, vendor qulifcations, and submittal requirements, a definition of the suppliers services, spare parts, and warranty requirements. In this section you should also define who owns the code, any requirements for source code and documentaion on CD or print or whatever, and drawing submittals for approval. You can put general requirements like all code must be documented, etc. but saying things like "every rung of logic must include three lines of comments" often descends into silliness.

The second section is "Products" and defines number of panels, I/O point list for each panel, PLC and operator interface brands, enclosure ratings, front panel devices, preferred vendors for field devices, communications network requirements, and loop descriptions for the logic. I break down the loop descriptions into alarms, data logging, and control. The best method for loops is to identify the field devices associated with each loop, control signals in, outputs from the loop, and a description of any special sequencing and logic required.

The last section is "Execution". It defines inspection, tuning, and testing requirements, mounting and wiring responsibilties, training requirements, demonstration or explanation of the logic, etc. Make sure you identify who is to do the wiring or field debugging or other contentious responsibilities. This section should also define any progress payments, and the criterion for payment approval at each stage.

This format isn't appropriate for all projects or systems, but it isn't a bad starting point.

Pierre

writing good specifications came to help you.
I can understand that its pain in the ***.
lot of Paper work!
I talking from the side of the costumer who want the most compatible staff.for him. and from the side of system integrator.
I do both. I will never let to machine manufacture to put any Siemens
PLCs Or Modicon.Is easy to get mortgage in the bank then to get service.in Isreal.
Evry thing must to be on my suppliers shelves in 1-2 hour drive.
(That the benefit of small country).I want to avoid down time.
Because I responsiable as his consultant I will do my best.
But in same cases I will approve some other things.In that case I will buy spare parts.or I will be ready with substitutes.
From the side of System Integrator I try to give my customer exactly
what he want and he approve evry change.
So he is happy and I happy he can not complain he sign on that.
Of course if he chnge his mind from SLC to PLC5 he will pay.(it happened to me).
When I writing exactly what I want or what I going to give.dos not matter machine logic or equipment. I protact my self from problem in the future.
Pay Attention
Not evry thing based on performances .
What I can do if machine stoped after year and no one can take care on the "black box".Should I be down because of that.
I buy what I can fix and not be depend on others (if I can)who located
far away especially in critical part.
Even if your specs are too tight.If your customers happy they will not go for those details you left out.
You need to keep them happy.
To sum up specifications is good any how if you want to be satisfied
and want happy customer.and less headaches.

Only 2 parallel branches per rung Pierre? That IS limiting.
Sometimes a flow chart can help. A picture is often worth a thousand words.
beerchug

BobB said:

Only 2 parallel branches per rung Pierre? That IS limiting.
Sometimes a flow chart can help. A picture is often worth a thousand words.
beerchug

Click to expand...

Come on BobB its only an example (although taken from real specs I've seen in the past)

While gazing admirably at a huge sculpture of an elephant, a visitor asked the sculptor how he was able to produce such beautiful work. The sculptor said, "Aw, Heck! It was easy! If I want to sculpt an elephant, I simply start with a huge block of granite, and then chip away anything that doesn't look like an elephant! How could it not turn out beautiful?"

Of course, as a logical method, that sounds ridiculously illogical. However, putting aside the sculptor/elephant example, is that particular method really illogical?

While gazing admirably at two bins of balls, one containing blue and red balls and the other containing green balls, a visitor asked the 5-year-old, standing proudly next to the bins, how he was able to accomplish this feat of color separation? The 5-year-old said, "Aw, Heck! It was easy! I started with one bin full of red, blue and green balls. I wanted that bin to contain only green balls (an elephant?). So, I simply took out anything in that bin that wasn't a green ball (elephant?) and put it in that other bin! I ended up with a bin full of green balls (an elephant!). How could I possibly fail?"

I wonder if that kid could uncover an elephant in a block of granite.

The point is... sometimes, it is just as valid, just as important, to describe what something is NOT.

When it comes to communicating ideas, the "speaker" has a distinct advantage over the "listener". The "speaker" has the "vision"... or at least, he has a "general idea of the vision". However, sometimes, and all too often, the "speaker" does NOT really have the "vision" at all.

The speaker's "vision" might be as simple-minded as...
"Everytime I push this button, a widget pops out of this door on this black-box!"

A little lacking... don't you think? However, if that is the "spec"... then the programmer is free to do anything he can think of to make it so. On the one hand, this gives the programmer a tremendous amount of freedom. On the other, the spec-writer might end up receiving a program that is far removed from his "vision".

The programmer might set up the program such that when the button is pressed, a little bell rings at some "Midnight Widget Shop". The crew runs out, steals a widget, and returns it to the black-box. Upon arrival, they toss the widget out of the door in the black-box!

The process meets every specification, as written, and is, therefore, a complete success!

The speaker might have been able to better refine his spec by declaring that there would be no "Midnight Widget Shop" involved in the process.

That, of course, leaves the programmer free to use the "Eight O'Clock Widget Shop".

The spec-writer would have done much better by declaring that the production of the widget will occur strictly within the confines of the black-box. That would eliminate the use of any "Widget Shops" or any other external facilities.

It would then be an incredibly mind-warping and time consuming exercise in futility for the spec-writer to try to think of every other possible thing or method that he doesn't want the process to use.

The spec-writer needs to really know what he wants so that he can clearly describe it in terms of "what it is" as well as "what it is not". The programmer then has access to all of the flexibility he might need... within those constraints.

All too often, it is assumed that "what it is not" is automatically inferred from "what it is". Consider this...

A school bus is a yellow, multi-passenger, vehicle... unquestionably.
Does that mean that all yellow vehicles with more than one passenger are school buses?

Not necessarily so.

Terry
Could you please explain me in plain english what is "Eight O'Clock Widget Shop".