See discussions, stats, and author profiles for this publication at: [Link]

net/publication/273478726

A new object model of batch equipment and procedural control for better
recipe reuse

Article in Computers in Industry · June 2015

DOI: 10.1016/[Link].2015.02.002

CITATIONS READS

3 1,776

5 authors, including:

Giovanni Godena Igor Steiner

Jožef Stefan Institute INEA doo
20 PUBLICATIONS 107 CITATIONS 6 PUBLICATIONS 71 CITATIONS

SEE PROFILE SEE PROFILE

S. Strmcnik
Jožef Stefan Institute
133 PUBLICATIONS 1,356 CITATIONS

SEE PROFILE

All content following this page was uploaded by Giovanni Godena on 13 November 2018.

The user has requested enhancement of the downloaded file.

 A new object model of batch equipment and procedural control
for better recipe reuse

Giovanni Godena, Tomaž Lukman, Igor Steiner, Franc Bergant, Stanko Strmčnik

ABSTRACT
Application of the ISA-88 standard in industrial batch-process control often leads to repetition of
information in recipes and to a low level of their reuse. This problem stems from the deficiencies of
the standard batch-process control object model. A solution to the problem is proposed that is
based on a more sophisticated object model of equipment and procedural control, with dynamically
defined and potentially overlapping unit classes. The new concept, together with its elements, is
described, and its use is illustrated and validated by means of a real batch control project. The
validation is carried out as a comparison of the number of master recipes and unit procedures
created under the new object model with the number of master recipes and unit procedures needed
to perform the same functionality using the standard object model. The comparison demonstrates
that the proposed approach has a significant advantage.

KEYWORDS
batch control, recipes reuse, information repetition, equipment object model, overlapping unit
classes

1. INTRODUCTION

There is broad consensus among the manufacturers of automation equipment, service providers,
and end users of the need to comply with the ISA-88 standard [1] in batch-process control,
regardless of the level of automation. The reason lies in the many attractive features of this
standard, e.g., it represents a common language for engineering and operations management; it is a
standard that reduces the engineering cost for automation; it can be used to identify the appropriate
level of automation, etc. [2]. Furthermore, it is compatible with the ISA S95 standard, and as such
represents an important framework for design and implementation of control, optimization, and
decision functions on various hierarchical levels of the enterprise (see e.g. [3, 4]). However, there
are also certain problems concerning the application of the ISA-88 standard and the batch tools that
are based on it, see e.g. [5].

1
One of the problems encountered in real life applications of batch control is the high degree of
repetition of information in the recipes and their low degree of reuse, resulting in the need for
increased effort regarding recipe management and in a higher probability of errors in the recipes.
This problem stems, in our opinion, from the deficiencies of the standard batch-process control
object model, caused by its fixed structure of unit classes and (too) simple class hierarchy.
Surprisingly, the above-mentioned problem is not recognized in the technical and scientific
literature. An extensive literature search in several databases, including INSPEC, Science Direct,
and Google Scholar, did not turn up any paper dealing with this problem. The search was
performed using various combinations of the following keywords: “batch”, “process”, “control”,
“recipe”, “reuse”, “repetition of information”, and “reusability”.
In our opinion, a proper solution to the problem is the introduction of a more sophisticated object
model of equipment and procedural control. A step towards a more sophisticated object model has
already been made in Part 2 of the ISA-88 standard, [6] which introduces a more complex kind of
class hierarchy in the form of multiple inheritance in the units object model by allowing an
equipment entity to belong to more equipment classes. However, this concept concerns assigning
different roles to a particular unit, such as a vessel being both a reactor and a holding tank, and has
no impact on the repetition of information in the recipes and their reuse.
The aim of this paper is to present a new proposal for the object model of batch equipment and
procedural control that to a large extent minimizes the repetition of information and maximizes the
reuse of recipes. The proposal is based on a concept involving dynamically defined and potentially
overlapping unit classes or a multiple inheritance relationship between the units and the unit
classes, i.e., on the possibility of a certain unit belonging to more than one unit class.
The paper is structured in the following manner. Section 2 introduces object technology as a means
of information-repetition prevention and reuse enhancement in the domain of batch-process
control. Section 3 describes the ISA-88 standard object model of equipment and procedural control
as it is used in most batch control tools and comments on its deficiencies. Section 4 presents a new
proposal for the object model of equipment and procedural control. Section 5 briefly describes the
implementation of the new concept in an in-house-developed batch tool and illustrates the
advantages of the new approach in a real-life industrial application. Section 6 presents the
validation of the proposed concept and Section 7 the conclusions.

2. OBJECT TECHNOLOGY IN BATCH-PROCESS CONTROL

Object technology has enabled a significant positive shift in the general process of software
development. Two of the positive effects of introducing object technology that are the most
relevant for the research presented in this paper are enhancing reuse [7, 8] and reducing
2
information repetition [9]. This should also hold true for batch-process control tools in accordance
with the ISA-88 standard, i.e., the introduction of object models for equipment and procedural
control should prevent the repetition of information in the recipes and enable their reuse.
At this point, some important terms and concepts of the ISA-88 standard should be introduced. The
standard describes batch control by means of three models, namely the process model, physical
model, and procedural control model. The process model describes the hierarchical subdivision of a
batch process in terms of entities relevant from a process engineering perspective, namely
processes, process stages, process operations, and process actions. The physical model describes
the hierarchy of physical assets of an enterprise in terms of enterprises, sites, areas, process cells,
units, equipment modules, and control modules. The procedural control model describes
(equipment) procedural elements that are combined in a hierarchical manner to accomplish the task
of a complete process as defined by the process model. The hierarchy consists of the procedure
level (consisting of a sequential-concurrent combination of unit procedures), the unit procedure
level (consisting of a sequential-concurrent combination of operations), and the operation level
(consisting of a sequential-concurrent combination of phases). The entities of the procedural
control model in fact represent the processing capabilities of the entities of the equipment model,
where phase is the smallest processing entity. The entities of the three models have the following
relation: the entities from the procedural control model, combined with the entities from the
physical model, provide process functionality to carry out entities from the process model. Besides
the three described models, there are also recipes with their recipe procedures, which provide a
hierarchical-sequential-concurrent decomposition of the processing required to produce a certain
product. The elements of a recipe procedure are in fact references to the elements of equipment
procedural control. Thus, for example, at the lowest level of a recipe procedure, a recipe phase is an
abstract notation giving a reference (link) to the corresponding equipment phase. There can be
many recipe phases for a given equipment phase, as the processing of an equipment phase may be
used by many recipe procedures. For more detailed information on the above-described concepts,
see Sections 5.1, 5.2, and 5.3. of [1]. Detailed information on the recipe procedure/equipment
procedural control linking can be found in [1], Section [Link].
The equipment and procedural control models implemented in various tools compliant with the
ISA-88 standard are based on classes and instances of equipment, and on unit procedures that can
be written for a class or an instance of an equipment unit. The basis of unit classification is its
capability, i.e., the set of phases of a particular unit. A unit class represents units of the same
capability, i.e., the same set of phases. A unit procedure for a unit class is written only once for the
unit class and may be executed on any unit of that class. A unit class can also represent units that
are not completely identical. In that case, the unit class only has the phase classes whose instances

3
can be found in all the units of that class. The other phases appear as specific phases of particular
units. A unit procedure written for a unit class can only contain the common phases. If we would
like to use some of the specific phases in the recipe, the unit procedure has to be written for a
specific unit.
The above-described model works fine in simple cases, in particular where the equipment consists
of unit classes with identical unit instances, without specific phases. On the other hand, in more
complicated cases with not fully homogeneous unit classes (unit instances having specific phases),
which in our experience is quite common in industry, the model fails to avoid the duplication of
information in the recipes and does not allow the maximization of their reuse. In these cases, a
model based on multiple inheritance, instead of single inheritance, would give much better results.
Inheritance is one of the most prominent concepts of object-oriented technology and the key
mechanism that facilitates reuse [10, 11] and reduces redundancy, i.e., the repetition of information
[9]. Inheritance should be applied to model commonality and specialization [12, 13]; however, it
can also be used to model kind-of roles, transactions, and devices [14].
Nevertheless, its use must be carefully applied since it can be dangerous when used incorrectly
[15]. It is effectively just a mechanism for extending an application’s functionality by reusing the
functionally of the parent classes [13]. Inheritance can be categorized into two distinct types, i.e.,
single inheritance, where a child class inherits from only one parent class, and multiple inheritance,
where a child class inherits from two or more parent classes. Multiple inheritance is more powerful
and expressive than single inheritance [16]. It also increases reuse (because of multiple sub-
classing) [13] and allows a more natural definition of the relationships between classes [17]. The
implementation and use of multiple inheritance is non-trivial [18], since it introduces several
potential problems, e.g., repeated inheritance [19]. Consequently, multiple inheritance is only used
in some of the available object-oriented programming languages (e.g., C++ and Eiffel). Whether
multiple inheritance simplifies or complicates the object-oriented technology remains a matter of
debate [16]. However, the benefits of multiple inheritance have outweighed its drawbacks in some
specific domains where it is used in object-oriented modeling. For instance, the use of multiple
inheritance in geographic data modeling is essential [20, 21].
Despite the controversy, we believe that multiple inheritance is the right mechanism for addressing
the problem of the high repetition of information in recipes and their low reuse in the domain of
batch-process control. In the remainder of this paper we present an approach to solving the above-
mentioned problem. The approach is based on the definition of a new object model of equipment
and procedural control, with dynamically configurable and potentially overlapping unit classes.

4
3. STANDARD OBJECT MODEL OF EQUIPMENT AND PROCEDURAL CONTROL

The model that will be used in this paper is based on the ISA-88 procedural control model,
collapsed to three levels, with the operations level omitted. This reduction is made because the tool
in which the new model was implemented [22] has a three-level control recipe procedure without
the operations level. The reduction has no effect on the basic idea of the new object model, which
could easily be scaled to four levels, as defined by the ISA-88 standard. Detailed information on
procedural control collapsibility can be found in [1], Section [Link].

3.1 The structure of the standard model

The collapsed procedural control model is shown in Figure 1. The figure also shows that the recipe
structure goes down to the phase level; as a consequence, the equipment control only consists of
equipment phases. In other words, the recipe adaptability is extended down to the level of phases.

class StandardModel-Collapsed

RecipeProcedure

1
*
{ordered}

RecipeUnitProcedure

*
{ordered}
-references
RecipePhase EquipmentPhase
* 1

Figure 1: The collapsed procedural control model

shows the standard object model of equipment and procedural control up to the unit procedure
level, as defined in [1] and [6]. At the top level the model describes generic equipment by means of
unit classes and their phase classes. At the lower level there are concrete units, which are instances
of unit classes. Every unit has one phase instance for each phase class of the corresponding unit
class and may also have additional specific phases. The unit procedures may be unit-class based,
meaning they contain only phases that are instances of the phase classes belonging to the unit class,
or unit based, which may also contain specific phases. The part of the model within the red frame
5
represents the predefined part of the model that contains the parts of the control system that are
defined during the development of the control system and cannot be altered later by users. The part
of the model outside the red frame contains recipes that are created by users.

class StandardModel

Predefined part +classifier

UnitClass
1 1
+instance 0..* 1

1 Unit 1..*
1
1 PhaseClass

+classifier 1 1..*

0..* 1..* +instance 0..*

SpecificPhase Phase
1..*
0..*

UnitProcedure

1 1 1 0..*

UnitInstanceBasedUnitProcedure UnitClassBasedUnitProcedure
0..*

Figure 2: The standard model of equipment and procedural control

The part of the model within the red frame represents the predefined part of the model, which
contains the parts of the control system that are defined during the development of the control
system and cannot be altered later by users. The part of the model outside the red frame contains
recipes, which are created by users.
In the development process using the traditional batch tools based on the standard object model, the
equipment model is built in a top-down manner in both the aggregation and classification
hierarchy. The building of its predefined part starts with the unit classes and their phase classes,
followed by units and their possible specific phases. The flexible part then consists of recipes
composed of three levels (or fewer, if the levels have been collapsed), namely the procedure level,
unit procedure level, and operation level.

6
3.2 The deficiencies of the standard object model

How much the described standard object model can contribute to avoiding the repetition and
ensuring the reuse of the information included in the recipes depends on the similarities and
variability among the units. If the unit classes are homogeneous (grouping completely identical
units) and the units of the different unit classes are completely dissimilar, then the standard model
is suitable. In cases where the first assumption does not hold, (i.e., if the unit classes are not
perfectly homogeneous), the unit procedures that contain any specific phase must be written more
than once. Such a situation is, of course, highly undesirable. Another problem occurring in the case
of similar units of different unit classes is not so obvious. It stems from an inability to optimize the
unit procedures by writing similar parts of the unit procedures for different unit classes only once.
Let us assume that we have three unit classes, each one with its own capabilities (phases), and that
there are non-empty intersections (common phases) for each pair of unit classes (i.e., three
intersections) and the intersection of all three unit classes. All the unit procedures that use the
capabilities of any intersection may be common to all the members of the intersection. However, in
a system based on the currently employed object model, this is not possible and there is a repetition
of the unit procedures with identical parts for different unit classes.
In our opinion, the main source of the above-described problems of the standard object model of
equipment and procedural control stems from the fixed structure of the unit classes. By fixed we
mean predefined during the system development and without the possibility to be changed by users
(process engineers) during the operating phase of the control system life-cycle. The solution to the
problem lies in the introduction of an improved object model of equipment and procedural control
with flexibly defined unit classes and the possibility of these unit classes having overlapping
capabilities (phases). Such a new object model is described in the next section.

4. THE NEW OBJECT MODEL OF EQUIPMENT AND PROCEDURAL CONTROL

The new object model of equipment and procedural control is presented in Figure 3. It includes
units that may belong to (i.e., inherit from) multiple unit classes or, in other words, there are
overlapping unit classes. This is denoted by the cardinality “0..*” at the connection between “Unit”
and “UnitClass”, stating that a Unit may belong to multiple unit classes, which in fact represents a
form of multiple inheritance. Another, even more important feature of the new model is that these
unit classes do not need to be defined by the developers of the control system, as is the case with
the standard model and the corresponding tools. Instead, they may be defined by the process
engineers (recipe creators) at any time during the entire operation phase of the control system life-
cycle. This feature is particularly important when new products that require the creation of new

7
recipes are introduced. The main structural difference between both models is that the new model
includes only three predefined elements, i.e., phase classes, units, and phases, as shown in the red
frame in Figure 3, while the standard model consists of the same three and an additional two
predefined elements, i.e., the unit classes and the specific phases, as shown in Figure 2.

class New Model-UpToTheUnitProcedureLev el

UnitProcedure

1..*
UnitBasedUnitProcedure UnitClassBasedUnitProcedure

0..* 1..*
1..* 1..* 1
1..* 0..*
UnitClass
PhaseClass
- nominalVolume
1 +classifier {UnitClass has
phase classes that 0..* +classifier
1..* 1..* +instance are common to all
units of the unit
Phase class}

1..*
1 ScalingFactor

- value
Unit +member
1
- volume 1..*

Figure 3: The new model of equipment and procedural control up to the unit procedure level

In a development process that uses the new object model, the building of the system begins by
defining the phase classes, followed by defining the units and selecting their phases from the set of
previously defined phase classes. At this point the development work is finished; henceforth the
building of the recipe-based control system is up to the process engineers, i.e., the users of the
control system.
The building of the recipe-based control system by a process engineer begins by defining the unit
classes, which are composed of a specific subset of units, in such a way that a particular unit may
be contained in multiple unit classes. A unit class has a set of phase classes that is an intersection of
the sets of phases of the individual units assigned to the unit class. As a detail, let us note that a
8
new unit can be added to a unit class only if its addition would not cause the set of phase classes of
the unit class to become an empty set. As another detail, let us consider the sizes of the individual
units and unit classes. Every unit has a size attribute (volume), and every unit class has a nominal
size attribute (nominal volume), which is equal to the size of its largest unit. Furthermore, every
unit has a basic scaling factor in relation to a particular unit class of which it is a member.
Obviously, a particular unit may have different basic scaling factors for the different unit classes to
which it belongs. Hence, the basic scaling factor of a unit may be considered as an association class
between that unit and one of the unit classes to which the unit belongs.
The building of the system continues by defining the unit procedures (having omitted the operation
level), which can be written for a unit class or for a unit. If a unit procedure is written for a unit
class, it may contain only phase classes defined for that unit class, and if it is written for a unit, it
may contain only phases defined for that unit.
The next step is to define the lines, which are composed of units, and line classes, which are
composed of unit classes and are generalizing lines. Here again we encounter some rules and
constraints. So, for example, for each unit class belonging to a line class, there is a requirement that
at least one of its units must belong to each unit class of the line class. In other words, we can only
assign to a line class those lines that have at least one unit for each unit class of that line class.
Next, every line has a size attribute (volume) and every line class has a nominal size attribute
(nominal volume). The size of a particular line is equal to the size of its dominant unit (which is not
necessarily its largest unit), which is selected by the process engineer. Finally, the nominal size of a
line class is equal to the size of its largest line.
The last step in building a recipe-based control system is to define the master recipes and their
recipe procedures, which can be written for a line class or for a line. If the recipe procedure is
written for a line class, it can only contain unit procedures written for any of the unit classes that
are contained in the line class. If the recipe procedure is written for a line, it can only contain unit
procedures written for any of the units that are contained in the line.
The complete new model of equipment and procedural control, up to the level of lines and recipe
procedures, is shown in Figure 4.

9
 class New Model-Complete

Procedure

LineBasedProcedure LineClassBasedProcedure

1..* 1..*
UnitProcedure
{Only unit procedures of units that {Only unit procedures of unit classes
are assigned to the line for which that are assigned to the line class for
the procedure is written} which the procedure is written}

1..* 0..*
UnitBasedUnitProcedure UnitClassBasedUnitProcedure

1..* 1..* 1..*

1
1..* 0..*

PhaseClass UnitClass

- nominalVolume
1 +classifier {UnitClass has
phase classes that 1..*
1..* 1..* +instance are common to all
0..* +classifier
units of the unit
class}
Phase

1..* Predefined part

1 ScalingFactor

- value
Unit +member
1
- volume 1..*

1 1..* 1
0..* 1..*
Line LineClass
{Only lines that have at least one unit for
- volume each unit class belonging to the line class} - nominalVolume

+member 1..* +classifier 0..*

Figure 4: The complete new model of equipment and procedural control

5. APPLICATION OF THE NEW CONCEPT

5.1 Implementation of the new concept in a batch-process control tool

The new concept described was implemented in a new tool for recipe-based control of batch
processes according to the ISA-88 standard referred to as PLCbatch [22, 23]. Field experience with
the new tool has shown that the new object model slightly increases the level of abstraction and
consequently the complexity of using the recipe system, but in return enables complete elimination
of the repetition of information in the recipes and maximization of their reuse. Note that the tool

10
also allows building the object models of equipment and procedural control in the standard manner,
as in other batch control tools. It is therefore up to the user how or whether the new option is used.
The developed tool has a number of other interesting features, such as [24]:
• execution of the state-transition algorithm of individual phases extended by the notion of
super-states and a rich set of processing sequences;
• a special tabular presentation of the recipes;
• relocation of the execution of recipes from the inherently unreliable PC platform to the
considerably more reliable PLC platform1.
Thus far, the new tool has been successfully used in four medium-sized batch-process control
projects, namely the carburizing and quenching of steel products, the improvement of plastic semi-
products in autoclaves, the mixing of paints and impregnating agents for industrial felt, and resin
synthesis, which is described in the next subsection.

5.2 Real-life implementation in a resin synthesis batch control system

In order to validate the proposed concept and illustrate the use of the developed tool, we applied it
in a real life situation. It includes basic elements of the “case study” approach, which is a common
method of validation in software engineering [25].
The batch process considered in this case study is the synthesis of resins carried out in a process
cell consisting of 6 lines, with each line consisting of 2 units – the batch reactor and the thinning
tank. The batch reactor is equipped with a jacket, which is a heating/cooling system that enables
control of the reactor temperature. One of the 6 resin synthesis production lines is shown in Figure
5.
The production process starts by dosing the necessary ingredients into a batch reactor. After dosing
the ingredients, the content of the reactor is heated up to the temperature necessary to start the
reaction. The heating is carried out in a controlled manner, following the prescribed linear course
with a controlled pace, i.e., a ramp. The heating of the reactor’s contents results in the emanation of
a vapor, which is led through the condenser, where the distillation water by-product is separated.
At the same time, a vacuuming process is performed to speed up the synthesis process. After the
completion of the synthesis process, the produced resin is pumped into the thinning tank. Prior to
pumping, the thinning tank needs to be filled with the required quantity of solvents. The contents of
the thinning tank are cooled down during the dissolution of the resin, and the temperature in the
thinning tank is controlled by means of the speed of extrusion of the resins from the reactor to the

1
Note that the fact that the recipes are executed on the PLC platform implies much higher reliability compared to
common PC-based solutions, but also some restrictions due to the limitations of the platform. As an example of such
restriction, let us mention the limit of 20 unit procedure recipe parameters, in the current version of the tool.

11
thinning tank. During the dissolution the contents of the thinning tank need to be agitated
continuously. After carrying out quality control in the thinning tank, the product is ready to be
pumped into the storage tanks.

Figure 5: Resin synthesis production line

The six reactors differ with regard to their capabilities and size. Reactors 1, 5, and 6 are large,
reactor 2 is medium-sized, and reactors 3 and 4 are small. Regarding their capabilities, i.e., the
available phases of a particular reactor, the reactors differ mainly in the available material-dosing
phases, since not all the materials can be dosed into all the reactors. The only difference that does
not concern materials dosing is the reactor-thinning tank end-synchronization phase, which is
present for reactors 1, 2, 3, 5, and 6, while reactor 4 does not have this phase, since the end-
synchronization has to be done manually, with the operator’s confirmation. The materials are
grouped into seven groups, namely dicyclopentadiene, glycols, oils and fatty acids, solvents, AMK
solution, AFK solution, and styrene. The last of these cannot be dosed into any reactor, but only
into the thinning tanks, so there are six groups of materials that can be dosed into the reactors.
Reactors 1 and 2 support the dosing of the materials from all these six groups; reactors 4, 5, and 6

12
support the dosing of the materials from five groups (oils and fatty acids excluded); and reactor 3
supports the dosing of the materials from four groups (dicyclopentadiene and AMK solution
excluded).
The process engineers developed the recipe-based control system by employing the above-
mentioned PLCbatch tool, which in turn enabled a high degree of recipe reuse and a reduction in
information repetition. They defined the following reactor unit classes (the reactors included in a
particular unit class can be seen from the class name): R_12_56, R_12_456, R_123, R4, R_123456.
As stated above, a set of phase classes is assigned to each unit class; this set is an intersection of the
phase classes assigned to each unit of a unit class. So, for example, unit class R_123 has the same
phase classes as unit R_3 (since the phase classes of this unit are a subset of the phase classes of
units R_1 and R_2, and these two units have the same set of phase classes). Another example is
unit class R_123456 (all reactors), which has, among the dosing-phase classes, only the phase
classes related to the dosing of materials from the glycols, solvents, and AFK solution groups,
since these are the only three material groups that can be dosed into all reactors. Furthermore, the
following line classes were defined: L_12, L_12_56, L_3, and L_4. Line class L_12 contains
reactor unit classes R_123 and R_123456; line class L_12_56 contains reactor classes R_12_56,
R_12_456, and R_123456; line class L_3 contains unit classes R_123 and R_123456; and, finally,
line class L_4 contains unit classes R_4, R_12_456, and R_123456.
As a concrete illustration of the benefits of the new model, let us closely focus on a part of the
example in the case study. The (class-based) unit procedures with the highest potential for reuse are
those written for unit class R_123456, since these unit procedures may be used in a master recipe
(more precisely, in its recipe procedure) for any line class, namely L12, L12_56, L3, and L4, which
means that they would appear only once instead of four times. As an example of such a class-based
unit procedure, let us consider the unit procedure Doz_AFK_1, which is shown in Figure 6. This
unit procedure contains, among phases performing tempering, condensation, and mixing (columns
1, 3, and 5), also a combination of the system and technological phases (column 2), which is used
for selecting the method of dosing AFK (automatic in solution form or manual in scale form) and
for performing the dosing. The core of this combination of phases is composed of the phases
Branch and Jump, which form an appropriate “OR” recipe structure. So, the phase
DataEntry_1_Rxx in the second row prompts the operator to enter his decision on the method of
dosing. If the manual method is chosen, the phase Branch in the third row performs a jump to the
sixth row, where the phase Message_1_Rxx then prompts the operator to perform the manual
dosing and waits for his confirmation. After the operator’s confirmation, the Message_1_Rxx
phase terminates and the recipe passes to the seventh row, where the unit procedure terminates its
execution. If, on the other hand, the automatic method is chosen, after the completion of the Branch

13
phase in the third row, a transition to row four occurs. At that point the automatic dosing is
performed, and then, in the fifth row, the Jump phase performs a jump to the seventh row, where
the unit procedure terminates its execution. A more detailed description of PLCbatch tool recipe
structures and execution can be found in [22].

Figure 6: The AFK dosing unit procedure

As mentioned above, the described unit procedure can be found in a number of master recipes for
all four line classes, therefore it is very important that it can be reused. Figure 7 shows a recipe
procedure for line class L_12_56 where the described unit procedure is used (see line 4).

6. VALIDATION OF THE PROPOSED CONCEPT

The gain in the reuse of recipes and in the reduction of the repetition of information can be seen
from the reduction in the number of master recipes and unit procedures created under the new
object model, compared with the number of such procedural elements that would be needed to
perform the same process functionality and which would be based on the standard object model.
Let us present the results of an analysis of this aspect regarding the selected case study.

14
Figure 7: The recipe procedure reusing the AFK dosing unit procedure

The number of master recipes is 262, while 340 recipes would be needed in the standard model.
The number of created unit procedures is 43, while 108 unit procedures would be needed in the
standard model, which is a 60% reduction (or reduction by a factor of 0.4). All 65 unit procedures
that would be needed additionally in the standard model would in fact represent the amount of
repetition of information in the recipes. Please note that the reduction in the number of unit
procedures (60%, as mentioned above) is much more important than the reduction in the number of
master recipes, since the unit procedures are much more complex and require much more time to
develop and configure. Table 1 contains the most important data from our case study, i.e., it
contains the actual number of unit procedures written for each unit class compared with the number
of unit procedures that would be necessary for the same functionality if the standard object model
of equipment and procedural control was used.
In some cases, the resulting number of unit procedures generated under the new model could be
larger than by using the standard object model. This could occur in the case of the creation of very-
fine-granularity recipe building blocks containing equal processing on different unit classes. In
such a case, the reduction in the number of unit procedures due to the “write each processing only
once” principle would be smaller than the increase in the number of unit procedures due to the

15
partitioning of the processing into (possibly a large number of very small) parts that are unique
across all the unit classes. Nevertheless, even in that case the essential gain would remain, i.e.,
avoiding the repetition of information. However, in the presented example this was not the case,
since all the unit procedures would also appear the same with the standard object model. This is
because all unit procedures were “pure” unit procedures and not ones generated by partitioning into
small parts of equal processing among different unit classes. For this reason, it was also simple to
calculate the above-mentioned reduction in the number of unit procedures: to calculate the number
of unit procedures in a system based on the standard model, every unit procedure in the actual
system has to be multiplied by the number of different unit classes for which that unit procedure
was written.

Unit Class Number of unit procedures Number of unit procedures Reduction factor
using the standard model using the new model
R_12_56 2 1 0.5
R_12_456 51 17 0.33
R_123 36 18 0.5
R4 3 3 1
R_123456 16 4 0.25
Total 108 43 0.4

Table 1: Reduction in the number of unit procedures

As a final remark, let us point out that the gain in recipe reuse would be even greater (as stated by
the process engineers in the factory) if there was not a limitation on the number of unit procedure
recipe parameters, as mentioned in Section 5.1.

7. CONCLUSION

A new object model of equipment and procedural control for recipe-based batch-process control
was developed. The main feature of the new model is that the unit classes can be dynamically
defined and that the structure of these unit classes can overlap.
The advantage of the new object model is that it eliminates the repetition of information in the
recipes and maximizes the reuse of the recipes or their parts. Therefore, in cases where there are
equal parts of the processing procedures in different unit classes, the (partial) unit procedures of
different unit classes are written only once.
The drawback of the new model is its higher level of abstraction, which results in increased
complexity and more difficult use of the corresponding recipe system. However, for less

16
experienced users a control system based on the new model can also be used in the same manner as
standard systems based on the standard object model.
The new object model was implemented in a new batch-process control tool for the PLC platform,
called PLCBatch. Our experiences using the presented approach are very positive, regarding both
the elimination of the repetition of information and the increase in recipe reuse, as well as the
acceptance and understanding of the model by process engineers.

ACKNOWLEDGEMENT

The work was carried out in the framework of the Competence Centre for Advance Control
Technologies. The operation is partly financed by the Republic of Slovenia, Ministry of Higher
Education, Science, and Technology and the European Union (EU) - European Regional
Development Fund within the Operational Programme for Strengthening Regional Development
Potentials for the Period 2007 – 2013.

The support of the Slovenian Research Agency (ARRS) is also gratefully acknowledged.

REFERENCES

[1] ISA-88.00.01-1995, Batch Control Part 1: Models and Terminology.

[2] [Link]
[Link].
[3] E. Muñoz, A. Espuña, L. Puigjaner, Towards an ontological infrastructure for chemical batch
process management, Computers and Chemical Engineering 34 (2010) 668–682.
[4] E. Muñoz, E. Capón-García, A. Espuña, L. Puigjaner, Ontological framework for enterprise-
wide integrated decision-making at operational level, Computers and Chemical Engineering
42 (2012) 217–234.
[5] F. Vinther, Batch 10+ years after S88, in: WBF European Conference, Mechelen, Belgium,
2006.
[6] ISA-88.00.02-2001, Batch Control Part 2: Data Structures and Guidelines for Languages.
[7] J.A. Lewis, S.M. Henry, D.G. Kafura, R.S. Schulman, An Empirical Study of the Object-
oriented Paradigm and Software Reuse, in: ACM Conference Proceedings on Object-oriented
Programming Systems, Languages, and Applications OOPSLA ’91, New York, 1991, pp.
184–196.

17
 [8] M. Stark, Impacts of Object-oriented Technologies: Seven Years of Software Engineering,
Journal of Systems and Software 23(2) (1993) 163–169.
[9] J.M. Armstrong, R.J. Mitchell, Uses and Abuses of Inheritance, Software Engineering Journal
9(1) (1994) 19–26.
[10] L. Bettini, M. Loreti, B. Venneri, On Multiple Inheritance in Java, in: T. D’ Hondt (Ed.)
Technology of Object-Oriented Languages, Systems and Architectures, Springer
Science+Business Media, New York, 2009, pp. 1–15.
[11] B.S. Heck, L.M. Wills, G.J. Vachtsevanos, Software Technology for Implementing Reusable,
Distributed Control Systems, IEEE Control Systems Magazine 23(1) (2003) 21–35.
[12] L.F. Capretz, P.A. Lee, Object-oriented Design: Guidelines and Techniques, Information and
Software Technology 35(4) (1993) 195–206.
[13] I.S. Deligiannis, M. Shepperd, S. Webster, M. Roumeliotis, A Review of Experimental
Investigations into Object-oriented Technology, Empirical Software Engineering 7(3) (2002)
193–231.
[14] P. Coad, M. Mayfield, Java-Inspired Design: Use Composition, Rather Than Inheritance,
American Programmer 10 (1997) 22–31.
[15] A.J. Riel, Object-oriented Design Heuristics, Addison-Wesley Longman Publishing Co., Inc.,
Boston, MA, USA, 1996.
[16] B. Alpern, A. Cocchi, S. Fink, D. Grove, Efficient Implementation of Java Interfaces:
Invokeinterface Considered Harmless, In: Proceedings of the 16th ACM SIGPLAN
Conference on Object-oriented Programming, Systems, Languages, and Applications
OOPSLA ’01, New York, 2001, pp. 108–124.
[17] G.B. Singh, Single Versus Multiple Inheritance in Object Oriented Programming, SIGPLAN
OOPS Mess 5(1) (1994) 34–43.
[18] E. Tempero, R. Biddle, Simulating Multiple Inheritance in Java. Journal of Systems and
Software 55(1) (2000) 87–100.
[19] K. Thirunarayan, G. Kniesel, H. Hampapuram, Simulating Multiple Inheritance and Generics
in Java, Computer Languages 25(4) (1999) 189–210.
[20] M.J. Egenhofer, A. Frank, Object-oriented Modeling for GIS, Journal of the Urban and
Regional Information Systems Association 4(2) (1992) 3–19.
[21] F.T. Fonseca, M.J. Egenhofer, C.A. Davis Jr, K.A.V. Borges, Ontologies and Knowledge
Sharing in Urban GIS, Computers, Environment and Urban Systems 24(3) (2000) 251–272.
[22] G. Godena, J. Tancek, I. Steiner, PLCbatch: features and application, in: WBF – 2010 North
American Conference, Austin, TX, USA, 2010.

18
 [23] G. Godena, I. Steiner, J. Tancek, M. Svetina, Batch process automation executed on the PLC
platform, in: WBF – 2008 North American Conference, Philadelphia, PA, USA, 2008.
[24] G. Godena, A new proposal for the behaviour model of batch phases, ISA Transactions 48
(2009) 3–9.
[25] P. Runeson, M. Höst, Guidelines for conducting and reporting case study research in software
engineering, Empirical Software Engineering 14(2) (2009) 131–164.

19

View publication stats