Mechanical/Material Handling and ISA 88

rlmunoz

Member
Join Date
Dec 2002
Posts
12
I'm new here so bear with me. The project I am working on works off the ISA 88 standard for batch process. However, I feel like I am in a tug of war in mechanical handling about this. ISA 88 works nice for batch and its associated recipes, but mechanical handling seems to work better using discrete programming. However, I am told to model after ISA 88 in my functional spec.

Some history:
I am one of those electrical engineers with more experience in the low level languages such as C++ and assembly. I trained in the microprocessor software and hardware world and due to an unfortunate economy ended up in controls engineering. Not to say this is a bad thing because I seem to work with better people and the transition from lower level programming to higher level industrial programming is much easier than likewise.

My problem:
Due to the low level programming experience I have, object oriented programming is a term I've heard thrown around numerous times...and implemented as well. I can see how ISA 88 is taking this object oriented concept and transitioning it into the industrial world. However, I think that they limit how it should be implemented in explaining it as this "batch" concept. Most examples use this batch concept and model it on a generic tank with its associated temperature, level, pressure, and material addition modules (others if need be). The project that I am on requires that the functional specs follow the ISA 88 model.

So in all this, my question is: How do you implement ISA 88 on mechanical handling equipment which is more discrete than the concurrent tank example shown above? I know how I want to model it, but I'm not sure if it is correct. Let me give you a very simple example (analogous to my job):

Lets say we have a bogie that transports a can from point A to point B in a transfer system. Point A and Point B have positioning instrumentation, the bogie has a motor and brakes, and these work together to get the job done. Here is an ISA 88 physical model scenerio I have:

Unit module - Transfer System

Equipment module - Bogie drive system

Equipment module - Point A instrumentation

Equipment module - Point B instrumentation

I tend to think as the physical model more of the nouns of the mechanical handling process...the objects so to say.

Now, we move on to the procedural control definitions. I tend to think of the following as examples of this:

Unit procedure - Can Transfer

Operations - Insert can
Move Bogie from Point A to Point B
Retrieve can
Move Bogie from Point B to Point A

Phases - can detect (same at point A and point B)
move bogie (same for moving bogie to point A/B or B/A with different parameters)
bogie detect (same for both A and B with different parameters)
stop bogie (same at point A and point B)

I tend to think as the procedural control definitions more of the verbs of the mechanical handling process.

Is this feasible? Am I thinking of this all wrong? Someone who is familiar with ISA 88 please help.
 
S88, the easy way.

So far, it looks like you've divided your process correctly into the S88 pieces. Well done!

Now, unless you are planning on using one of the S88 batch engines (iBatch, inlBatch, Batch, etc.), I suggest you set all that asside for a momemt (almost, but not quite, in that round thing in the corner).

As you've pointed out, the thing that S88 excels at is batching. That isn't to say that it can't be used in other places (I personally have used it to run a 20,000 TON chiller plant), but the key to success is the RECIPE.

In your transfer system, do you have a recipe? Are there settings that need to come from some "higher place" (ERP, DCS, SCADA, or just different tables in the PLC) ?

If so, what does that recipe "look like". Remember that a recipe is composed of
  1. Header Information (which, from a PLC standpoint, is extraneous);
  2. Equipment requirements (which, for a hard-piped, mechanical system (like yours?), is also irrelevant (from a PLC standpoint), because you shouldn't even be given a recipe from the "higher place" if the machinery can't handle it physically);
  3. The recipe setpoints (now we're talking);
  4. The Procedure (this is the one that most people forget about, from R&D to ERP to the PLC programmer)
So, first off, does the procedure change from batch to batch, or is fixed? Which answer you have doesn't matter - but you must know the answer.



I could go on (and I will), but I'm going to interrupt myself here to go into S88 theory a bit. What I'm describing is the "Top-down" approach to S88 progamming. Start with the recipe. Figure out what units (and associated unit operations) it goes to, or rather, what pieces of the recipe go to which units. Then figure out which equipment module (and associated equipment operations) the fragments of the pieces of the recipe goes to. And so on.

S88 is great, and I'm a big proponent. But I consider the models usually too big for a single PLC.

So I cheat. By S88 rules, you don't HAVE to have all the levels (or rather you have, for example, a unit that composed of a single equipment module which means that, for all practical purposes, you don't have an equipment module).

I also tend to simplify my thinking in merging the physical and procedural models. The reason for this is that my ultimate goal is to write PLC code. S88 helps make it modular and, at the same time, easy to explain (relatively).

What I'm left with is the following breakdown:

Unit: From a PLC standpoint, the unit is going to "run" the recipe. (It may be more correct to say that the recipe is going to "run" the unit. But I think of the unit as a 'record player' and the recipe as the 'record' that it's going to run.

The unit starts (and sometimes stops) the phases, and passes to the phase whatever setpoints they need to run.

Phases: These are short sequences that preform a specific task. They usually have a single critical setpoint associated with them, with some number of 'auxillary' setpoints. The critical setpoint is the one that, when met, causes the phase to stop executing (or - it tells the phase WHEN to run (or stop running), while the auxillary setpoints tell the phase HOW to run. Sample phase: Run the agitator at 300 RPM for 10 minutes. The 10 minutes would be the critical setpoint, the 300 RPM an auxillary). None of this is S88 exactly, but it helps (me) break up the phases. If I see two critical setpoints in a phase, I take a hard look to make sure that I don't really have two phases.)

Another way I identify phases (which you seem to have done, but I'm on a roll here) is that a phase usually moves a "something" from one point to another. That something can be material ("Meter in 30 gal water"), or energy ("Heat at 100º for 20 min), or even time ("Let the dough rise for 10 minutes"). I usually count a single source and a single destination as one phase, although it is perfectly acceptable to have a "Transfer" phase with the destination as an auxillary setpoint.

The phases start (and stop) the control modules, based on their internal sequence. The sequence can be as little as one step (although I usually have three steps as a minimum - "Idle - Waiting to Start, "Working", and "Complete - Waiting for Reset")

Control Modules: For personal reasons, I usually call these things "Devices". Almost always, these are no more and no less than each individual output from the PLC. Occasionally, two outputs will be combined into a single device (for example, the DO which is the agitator RUN signal, and the AO which is speed signal to the agitators VFD). In practice, I ignore the PLC inputs in my early thinking about devices. They provide feedback - what I'm designing is control.



Rather than take the "Top-down" approach, I perfer the "Bottom-up" approach. In actual practice, there's an element of both.

I start with the devices, and ask the costomer what kind/how much device control he wants & needs. Auto/Manual. Faults (now I start to look at the inputs). Interlocks and Permissives.

I'll go ahead and program all the devices as stand-alone pieces of code. Usually the rules for all of them are the same - if so, I'll put all my code in For-Next loops, and thereby enforce the common rules.

Auto/Manual are the key. If the device is in Manual mode, the operator has control. If the device is in Auto mode, the phase(s) have control. Whether the device can be in Manual mode when the phase is calling for it, and other such rules need to be worked out at the beginning of the project.

But there is a bit "A phase wants this device to run if it's in auto mode" (called "Auto Run") for every device.

Also, don't confuse "Fault" (the proper feedback response didn't occur withing a specified time frame) from "Alarm" (notifying the operator that a fault occurred). The two are seperate modules that share common bits.

Once the devices are done, it's time for phases. Again, I ask the customer up front how much individual phase control that he wants / needs. Auto/Manual. Single step through the sequences (if applicable - often isn't). Interlocks and Permissives. Faults.

Again, Auto means that the higher level (in this case, the Unit) has control and is responsible for giving it the setpoints. Manual means that the operator enters the setpoints

The sequncers for phases are usually dirt-simple. And each phase may drive some output on each step. You can find a sample of how it might be done HERE.

That just leaves units. In some systems, there won't be any unit level control - each phase, each get-the-'something'-from-here-to-there", will be run manually. Remember that not only can phases run devices, but they can also run other phases. If your sequence is truly fixed, and if no phases repeat, and if there is no desire to run each phase independently, then you can do all your sequencing at the phase level. As one phase completes, its last act is to start the next phase.

There won't be an Auto/Man for Units, since there is no higher level. But there will be a sequence, and usually a more complex one than that at the phase level. But ultimately it comes down to the Unit sequencer (=~ the Recipe) setting an Auto Run bit for the phase. (Or Auto Start/Auto Stop bits - it will depend on how you model it. Not the physical/procedural model, but what kind of state logic you want it to have).

Is this strictly S88? No. But S88 has so much flexibility built into it, and so much is subject to interpretation, that the above is S88 aware (there is no such thing as S88 "compliance").

<hr></hr>

Now looking at your specific situation.

Unit:
  • Transport line
Phases:
  • Insert can.
  • Move Bogie from Point A to Point B.
  • Retrieve can.
  • Move Bogie from Point B to Point A.
Devices:
  • Whatever outputs you've got.

Details of Phase "Move Bogie from Point A to Point B."
  1. Wait for start
  2. Wait For Can Detection (drive no devices)
  3. Run Conveyor (wait for bogie to reach Point B"
  4. Start "Retreive can" phase (Stop conveyor)
  5. Complete (wait for reset? OR go to step 1)

Anyway, that's one approach. It will produce good, clean, modular code, which is what you want. The details for what goes on inside the code are endless. In addition to the way I linked to, I've programmed phase seqencers with "valve matrices", a table with every valve and a "Must be Open" / "Must Be Closed" / "Don't Care" designation. The "Open" and "Closed" become ones and zeros in a masked move, the "Don't Care" becomes the mask.

There are condiserations for what to do when two phases want control of the same device (one solution - as part of the phase sequence, have a step: "Gather resources". The phase checks to see if a device "In use by phase" number = zero. If so, it writes it's number in the register (thereby "booking" that device). If not, it sits on that step, waiting for the phase that's using it to release it. This is not as good as what you can get from a PC-based S88 batching program, but it works well in most circumstances.

Is all this enough to get you started?

Is any of it helpful?

If you've got more questions, feel free to ask. This is my specialty, and what I'm most interested in, re PLCs.
 
Wow...nice reply.

Yes, this is a great starting point. The example I stated wasn't specific, and I don't think I can get into those, but it was very simple and general and got my point across. Its very difficult to implement ISA 88 in mechanical handling instrumentation. You see, ISA 88 fits perfectly for the product/recipe/batch inside of this "can". In mechanical handling, there really is no recipe or batch. The equipment that transports this can, however, is more discrete. There is no concurrent action to easily segregate the physical model and procedural control like the common example of the tank that has level, temperature, pressure, addition, and whatnot happening all at once. However, I have been told to do my best in modeling ISA 88 in my functional spec. My overall question to them is: "How can ISA 88 apply if I really have no batch?" with no concrete answer. So what I am doing is trying to do is get the finer points out of ISA 88 in that what comes out of it is bug-free code that is more portable. For example, have a bogie move module that can be used for other bogies if need be. Just set different parameters for the new bogie and go. Another point is that I am a system engineer. I know the details of my system but do not know yet the details of the programming we are doing. This is considered a good thing when writing object oriented code because I don't worry about the details, I just tell the programmer how my stuff works and model it on the higher levels. I am basically the coordinator that tells my actual programmer "here is how this portion of my system works. Here are my inputs and I want these outputs. How you do it is of no concern to me as long as I get the output from the given inputs in a correct manner.". I have a subtle awareness that what I am doing isn't the actual ISA 88 standard. But I am told to model it as closely as possible to it since this is the project standard and I think I am doing OK so far. Thanks for the help and sorry I couldn't give much of the details and specifics but you know how company politics work.
 
I understand what you are saying about having difficulty modeling a non-batch system using S88.

As I said, I did a chiller plant, which is a continuous process with only tw setpoints (demand and temperature), all the equipment modules running in parallel (4 chillers, 12 cooling towers, 6 chilled water pumps, 5 condenser water pumps). My "recipe" was the demand curve charts.

At any given point on the charts, I knew how many of each kind of equipment module I needed, and would sequence throught the starting and stopping of that number of equipment modules, and in such a way so as not to trip the chillers on low flow.

For you, it may be that you don't have any unit level control. It's not required by S88. You may just wind up having a bunch of independed phases or equipment modules which trigger each other ("When Equipment Module A detects a bogie at its exit point, it starts Equipment Module B. It also transfers all of it's knowledge about the bogie at the same time (ID, status, setpoints that future EMs will need, whatever)".)

I can see the difficulty if there are multiple bogies within Equipement module A - you would in essence be running multiple copies of the same phase to track each bogie. Not necessarily the cleanest way to do it.

Sometimes you just have a square peg that's too big to fit in the round hole, and you aren't allowed to trim it to fit. That may be what you have here. But it sounds like you are on the right track.
 
Later on ...

Dear pals

I got absorbed with the so called ISA88 standard. I would be greatful if anybody can show me a web link for more to read.

Regards

P.S : Sorry for my English
 
S88 Sites

Unfortunately, I don't know of any sites that provide comprehesive, non-brand-specific, free information about S88.

The standard can be downloaded for free (www.isa.org), if you are an ISA member ($72).

Outside of the ISA, there's the World Batch Forum (www.wbf.org). There's some papers on S88 HERE, but they don't go into too much detail.

I've heard Jim Parshall speak on S88 - he's excellent, and based in the real world (well, Ben & Jerry's anyway), and has written a book on S88, available at http://www.batchcontrol.com/
 
Thanx

I will check'em out Allen Thanx for your help and generosity.

Regards


P.S : Marry christmass
 

Similar Topics

I've run into a non-plc issue that is proving hard to solve. I'm designing a mechanical device that has a base/foundation that must satisfy the...
Replies
3
Views
381
We have an existing VSD where a three phase circuit breaker feeds the drive, and two phases also tee off to a contactor, which is energised to...
Replies
12
Views
1,455
greetings to everyone. I want to learn big Mechanical presses like in the picture. Can you help me find documentation about this from...
Replies
11
Views
2,870
Hi all, This is actually a personal project, if that's ok. My uncle has some property that has a well, he wants to have the well automatically...
Replies
7
Views
2,448
Just curious how anyone else has controlled a VFD driven motor with a mechanical brake. I was using a PLC output to fire a brake relay while also...
Replies
19
Views
4,449
Back
Top Bottom