EBF WG3 Common aspects file

Status - Development ongoing – this version is for comment and is incomplete

Comments are invited by Email 

1. Preamble

The scope of SP 88, Part 1 states that it "defines reference models for batch control as used in the process industries and terminology that helps explain the relationships between these models and terms".

At the April 1995 meeting of the European Batch Forum in Dublin a number of participants expressed the view that while the SP 88 draft standard seeks to cover only batch processes, there was a necessity to cater for certain non-batch processes and other activities found in typical "batch" industries.

During the concluding discussions of the meeting, it was decided to form a new group, to be known as Working Group 3, to investigate these issues and to report back to the next E.B.F. meeting.

EBF working group 3 reported in Noordwijk in Holland in Feb 96 and it was decided that the work should continue.

Since then much work has been done on the topic, much of this being deep philosophical discussions in bars and restaurants around Europe. And we have actually produced some tangible work:

Many flipcharts

Two imaginary but realistic plant designs to demonstrate the application of S88.01 and to illustrate the issues that are involved. (the milkshake plant and the chemical/pharmaceutical plant)

A detailed analysis of these plants.

This document discusses analysis in general - ie - the aspects that apply regardless of the details of a particular plant. Companion documents concentrate on the particular issues that each plant illustrates.

Providing a batch control system involves a number of activities. S88.01 is a standard which is intended to be applied to the definition of the Requirements for the control of a batch plant. This is stated very clearly in the introduction to the standard.

"This part of this international standard on Batch Control provides standard models and terminology for defining the control requirements for batch manufacturing plants."

The term S88.01 Requirements Analysis is used in this document to describe the process of analysing a plant and putting the requirements into a form that conforms with S88.01

One point about S88.01 is that it does not say how to carry out this process of analysis. Much of what follows represents the writers, and WG3 members,. please send your opinions about the analysis.

The diagram shows the main activities, and is oriented around the physical and procedural models.

S88.01 defines these models generically - that is to say that the models are universal and apply to any plant. The analysis process must take these generic models and then apply them to the particular plant. For example the physical model in S88 shows Control Modules. The requirements analysis should identify what are the actual modules required by the particular plant.

The diagram above shows that there are pre-requisites before the detailed analysis is done.

These starting points include

Piping & Instrument Diagrams:

•  

  • What level of flexibility is required? The plant may be dedicated to a single product and always use the same recipe. Or the plant may be intended to make a large range of products. These issues can influence the requirements’ analysis considerably.
  • How far up the procedural model should the automation extend? For example, some operators want phases automated but operations and procedures to be manual.
  • What level of batch reporting and management information will be required?
  • Who builds the recipes?
  • Who operates the plant?
  • Where do the operators work?
  • What skill levels they will have?

Process Description

2.1 S88 is a guide not an instruction book

S88.01 provides a general framework. There are within this many different ways of doing things. This section discussed some of the choices that can be made. These should always be made in the context of the capabilities of the users of the system, the type of plant and processes and so on.

2.2. Push the functionality down into control modules?

Control Modules can be very simple and only act upon a single loop or device.

Alternatively higher level control modules can be applied on loop of the basic loops and devices - for example it is possible to design a control module that can handle all of the modes of operation of a complex heat/cool system and have the procedural control simply pass down a set of parameters to this control module.

A control module can even contain sequential logic, such as for example the sequence that will change the control of a heat/cool system between heating and cooling modes.

Alternatively the procedural control can operate on each of the loops with the phase or operation setting the modes and parameters of each simple control module.

2.3. Phase logic within operations or separate phases?

It is possible to include the phase logic within operations, or alternatively that the operations start separate phases.

3. Design to avoid conflicts

It is possible, and unfortunately quite common, that the set of operations and/or phases that the recipe designer is provided with can be combined in such a way as to cause conflicts. For example if two phases both send set points to the same loop, or open and close the same valve and these two are a run together then the loop or valves may be given conflicting commands. Avoiding this possibility is essential in the design. There are various approaches to this. One is to ensure that the recipe designer is not able to build procedures at the phase level and has to work at the operation level combined with the enforcement of a rule that only one operation can run in a unit at one time.

3.1. Are all Control Modules in defined states?

The Unit state matix approach is one way of doing this. All combinations of commands such as set points, modes etc, are held in a table and the appropriate state is set for all steps of the process

4. Requirements Analysis independent of implementation

What do you want your plant to do is one question.

What your control system is programmed to do is another.

Ideally the two are similar, however there should be some distinction in order to know if the system is doing what is required and to be sure that limitations are not introduced without a conscious decision.

The ideal is to make the requirements analysis completely independent of the technological solution. In reality this is an exaggeration – any requirements analysis should recognise what is possible. However there should be no interference of specific system attributes with the analysis. This is one great advantage of S88.01 in that it sets a reasonable framework to do this.

The next stage - that of matching the implementation to the requirements - should make it clear what decisions have been made in order to fit the application into the chosen control system. Some required functions may have been modified and it may then be necessary to update the requirements to reflect what is implemented. This recognises that the requirements have been adapted to the system, and the difference between the original and the implemented requirements shows the compromises that have been made.

Of course it would be quite unrealistic if the Functional Requirements were such that no system on the market could implement them. To take this to an extreme, if the FR says that the recipes are to be deduced by reading the mind of the process chemist, then there is no chance of achieving this, at present. A major benefit of using S88 as the basis of the analysis is that the standard has been developed in the light of what is reasonable.

5. What is a Storage Tank?

Is it a Unit - or a Common Resource? This topic can cause a considerable amount of lively discussion in a group of batch specialists.

It’s not a Unit - Tanks can certainly have a batch in them, however they also often have a mix of batches. Of course a proper S88 Unit never has a mix of batches in it, so this type is not a unit under the present definition

It’s a Unit Arguably if it only stores one batch and does something to look after the batch (even just monitoring it) then such a tank could be a unit.

Or

On another tack, does the concept of equipment requirements in a Master Recipe look like it should apply to a tank? A storage or buffer vessel is not necessary to actually make the batch, so why should a recipe even refer to it?

What if the product, once it has been made, continues to have equipment requirements? In a sense this seems reasonable if it is applied to the storage conditions for the material. Interestingly exactly the same applies to products made in continuous or even in discrete plants.

One possibility might be to add a section to the recipe to describe storage requirements and so on. Now we are beginning to have a complete material description – so maybe the recipe should be better seen as an attribute of the material (it’s manufacturing method.) Then one material can have several alternative recipes to make it. And it may even be that there are both batch and continuous ways of making the same product. So the Material Definition may be a higher level than the Recipe and may include many basic Recipes.

What if it is a common resource?

At this point it is worth reviewing the S88 concept of common resources. According to S88.01

There are also a number of references to Common Resources elsewhere in the standard.

A storage tank seems to fit as a common resource all ways

But the CIP system, the utilities or an AGV seem to be much more true to the concept.

But ask most suppliers of Batch software and they want to make the storage tanks Units - or their software treats Units and Common Resources the same, or they even have a different paradigm. (Comments from Siemens, Wonderware, PID and any other suppliers please)

Material Tracking

This is the most popular requirement, but S88 says little about it. even though it is not that difficult conceptually. The contents of a batch or even a continuous product can be traced by measuring the process inputs and outputs , given some simple physics and maybe chemistry.

Batch

In the case of batch processes the batch is the main quantity of measurement is volume (or weight, or amount) of stuff and no single batch is made by more than one recipe.

Continuous

In the case of continuous processes the main quantity of measurement is time and the recipe is instantaneous.