J. Opf Res. Soc. Vol. 39, No.1, pp.

55--60, 1988
Printed in Great Britain. All rights reserved
0160-5682/88 $3.00 + 0.00
Copyright 1988 OJ'lerational Research Society Ltd
A Computable Algorithm for Ensuring
Segregation in a Complex Piping Network
J. C. HINES
Faculty of Mathematical Studies, University of Southampton
Given a number of proposed routes through a large network of pipes and valves, it was desired to test
whether each route was separated from all others by at least two closed valves. An algorithm to test a
given combination of valves settings is described. It has been coded in two different computer languages.
Key words: computer, data-base, network, piping, segregation
BACKGROUND
The problem is concerned with a large and complex piping network inside a petrochemical plant.
The network is used for moving a number of liquefied hydrocarbon gases, and the terminating
points consist of the storage vessels, processing plants and links outside the plant, such as road
and rail loading equipment and the marine terminal. There are sufficient linkages that it is possible
to connect any terminating point with any other, and the variety of operations is such that a very
large number of these options are used. The problem is made more complex because many
movements are taking place simultaneously. When a movement has been completed, that part of
the network can be emptied and used, in part or in whole, for some other movement.
The task of the operating group requires that they select a route for each movement which
provides complete segregation from all other movements. The hydrocarbon streams are of high
value, and any mixing is liable to decrease their value. This problem would be trivial if valves never
leaked, because the existence of a single dosed valve in every line connecting two routes would
be sufficient to ensure complete segregation. As commercial valves may leak slightly when dosed,
it has been normal practice to define complete segregation as meaning at least two dosed valves
in series between any two movements at every possible connection. This makes the problem more
difficult.
The complexity of the network is such that mistakes are sometimes made. It was therefore
proposed that some system should be evolved which would detect all cases where there was
insufficient segregation. The intention was that the user should be able to test planned routeings
before implementing them, and errors detected.
DEFINITIONS
For the purposes of the algorithm which is about to be described, some definitions will be
convenient. A valve is regarded as being part of a stream if the material can flow through it. Thus
a valve can be part of a stream only if it is open. It is regarded as being connected to a stream
if only one flange is wetted by it and is therefore dosed. Thus a valve which is part of more than
one stream represents a cross-over, and a valve which is connected to two streams represents single
valve separation. These are the only two error coftditions which can exist. A valve is regarded as
being an original member of a stream if it was used to define the route of that stream in the first
place. It is not an original member if it is found to be part of the stream later.
TWO SUB-PROBLEMS
The problem subdivides into two sub-problems. One is to evolve some way of organizing the
data which describes the network and the streams, and the other is to evolve the processing
algorithm which will handle the data.
55
Journal of the Operational Research Society Vol. 39, No. 1
THE NOTATION AND COMPUTER LANGUAGE
It was recognized from the beginning that the algorithm would ultimately be coded in a computer
language. It was also recognized that it would be desirable to select a language which was in wide
use in the company so that the ability to do maintenance or enhancement work would not be
restricted to a few individuals. This in itself suggested a data notation and organization because
the major language already in use handles relational data-bases. The data were therefore organized
into tables in third normal form. The programming could have been done using conventional
programming in lower-level languages like COBOL or FORTRAN, but the effort and time would
have been much greater.
This is not the proper place for a treatise on data-bases, relational algebra or third normal form.
These are covered by Date! and Martin.
2

There is a further advantage of using a high-level language which is used in the algorithm but
may not be generally familiar. Some computer languages do not permit a variable to exist without
having a value. For example, a numerical variable may be automatically initialized to a value of
zero until the program overrides it. Some languages do not have this limitation. It is possible to
declare the existence of a variable without assigning a value to it, or even to remove a value and
have it unassigned, much as a pigeon-hole can contain a message but does not have to contain
one in order to exist.
THE NETWORK DESCRIPTION
If we consider the network when completely empty and with no streams passing through, it
consists only of valves and of connections. The valves can be open or closed. At this stage, it
appears that the system can be defined using only two tables.
Valve-identifier, valve status
V alve-identifier, connected -valve-identifier
This uses the convention that the keyes) of the table (=file) are underlined. Thus it is necessary
only to specify the valve identifier to determine whether a valve is open or closed. There is a
difficulty with the second table. If there is a connection between two valves, say those with the
identifiers 1 and 2, it could be defined by making an entry of 1, 2 in the second table or an entry
of 2, 1. Thus the absence of an entry 1, 2 would not necessarily mean that there is no connection
between the two valves. Providing both entries would obviously be tautology. The problem was
overcome by distinguishing between the two keys of that table, so that it became
Smaller-val ve-identifier, Larger-valve-iden tifier,
where smaller and larger refer to the value of the identifier, not the size of the valve. Thus a
connection between values 1 and 2 is shown by an entry of 1, 2, and an entry of 2, 1 becomes
impossible.
THE ROUTEING DESCRIPTION
It would be possible to define the routeings through the network merely by including a field in
the valves table which contains the identity of the stream to which the valve is attached. This has
the drawback of providing a sequence which is unordered with respect to the streams.
For example, a valves table might look like:
Valve-identifier
1
2
4
7
8
13
Valve-status
Open
Closed
Closed
Open
Open
Open
56
Stream
2
1
2
J. C. in a Complex Piping Network
Note that the values of valves 2, 4 and 13 are not set; that is, the table 'does not know' whether
the valves are part of a stream or not.
The algorithm needs to be able to say that some valves are part of, or connected to, a stream,
even though they were not specified as such at the outset. It will therefore change the contents of
the stream column of the valves table for some rows as it proceeds. It might have been possible
to arrange a processing sequence using such a table, which would have ensured the exploration
of all connections to valves which were found to be part of a stream. However, it was judged to
be rather confusing to have to jump to and fro through such a table. The same objection applies
to a table of the form:
Stream-identifier, Valve-identifier
as a new entry might be inserted either before or after the valve being at the time of
processing.
The solution adopted was to use a table with the structure
Stream-identifier, Seguence-number, Valve-identifier.
It is not necessary for the sequence numbers to indicate the flow sequence. They are merely to
ensure that any new valve is added by the algorithm at the end of the list for that stream.
ADDITIONAL VALVE DATA
As the object of the exercise is to detect valves which represent errors, by virtue of being single
closed-valve separations or of being cross-overs (no closed valve), it is desirable to include a
field in the valve table which will contain the error, if one exists. For the sake of the user, a
further field is included which flags whether the stream was originally defined by him as part
of the stream or whether it was marked subsequently by the processing algorithm. This is not
needed by the algorithm itself, but can help the user to trace the reason for an error. This can be
useful where there is a long unplanned link between two streams, as only one valve in it will
be marked.
Thus the valve table now becomes:
Valve-identifier, valve-status, stream-identifier, original-member, error.
Of these, the last three fields should start empty before any processing is done. If the computer
language employed provides for a null field, this can be used; otherwise some unambiguous marker
meaning that there is nothing there can be used.
USER INPUT
The user must specify his candidate routeings by loading the stream table with the stream
o identifier, the sequence number and the valve identifier. It is not necessary, although it may be
convenient, that the valves should be specified in any particular order. It is necessary that the valves
in a stream should be kept together and in ascending order of sequence number.
THE PROCESSING ALGORITHM
Having defined the data by reference to its needs, the time has come when the details of the
algorithm must be exposed. The basic concept is to proceed through the network, just as a stream
might, examining each part of the network in turn, until brought up everywhere by reaching closed
valves or other streams. So, considering any valve which is already known to be part of a stream,
the procedure is as follows.
Find the first valve connected to the valve being considered. If it is already marked as being part
of, or connected to, the same stream, there is no problem, and no further processing is necessary.
If the connected valve has not been looked at before, it will not have any value assigned to the
column for its stream. This column should therefore be set with the identifier of the stream being
considered. If the valve is open, it is also part of the stream, and valves on the far side of it must
57
Journal of the Operational Research Society Vol. 39, No.1
o
o
8
o 4
C 5
2
o
o
9
o 6
o 7
FIG. 1. The demonstration network.
3
o
o
10
also be considered. The algorithm must therefore add this valve to the stream table, and this ensures
that the valves connected to it will be examined in due course.
This is the reason for the structure of the stream table. It makes it possible to find the last value
in the stream table which is part of the same stream, and to create a new entry with a sequence
number one larger. The new entry will be inserted at this point. Processing then returns to the point
where it was.
If the algorithm finds a valve whose stream is already set with a stream identifier which is not
the same as that of the stream being considered, it is clearly an error. It should not be possible
to arrive at the same valve from two different streams. If the valve is open, it represents a cross-over;
if it is closed, it represents a single valve separation. In either case, the error field of the valve is
set, and processing continues with the next valve connected to the subject valve in the stream. When
this is finished, it proceeds through all the remaining valves which are part of the stream, whether
originally defined as such or not. Each stream is processed in turn.
AN EXAMPLE
Consider the very simple network shown in Figure 1. This contains 10 valves, whose identifiers
and status are shown. In fact, only valve 5 is closed. The connections table for this network is shown
in Table 1. The user specifies that stream A shall pass through valves 1, 2, 3, and that stream B
shall pass through valves 9, 8, 10. These are put in an odd sequence merely to demonstrate that
it does not affect the basic workings of the algorithm. These are marked as originally part of their
respective streams, but valves 4, 5, 6, 7 are not yet marked at all.
Processing starts with valve 1. This is connected to valve 2, but this is part of the same stream
so nothing need be done. Valve 1 is also connected to valve 4, and this has not been marked with
any stream identifier. It is therefore marked. As valve 4 is open, it is part of the stream, so a new
entry is made in the stream table, reading A, 4, 4.
Processing now continues with valve 2. This is connected to valve 3, which presents no problem,
and to valve 4, which is now already marked with stream identifier A. Valve 2 is also connected
to unmarked valve 6, which is therefore marked with stream identifier A. Valve 6 is open, so
another entry is made to the stream table, reading A, 5,6. Valve 3 adds nothing to the information,
so processing continues with the fourth in sequence of the valves in stream A, i.e. valve 4. This
TABLE 1. Connections table
Smaller- Larger-
valve-identifier valve-identifier
I 2
I 4
2 3
2 4
2 6
3 6
4 5
5 8
5 9
6 7
7 9
7 10
8 9
9 10
58
1. C. Hines-Segregation in a Complex Piping Network
TABLE 2. Original content of stream table
Stream-identifier Sequence no. Valve-identifier
A I I
A 2 2
A 3 3
B I 9
B 2 8
B 3 10
is connected to valves 1 and 2, but these are already marked with stream identifier A, so no
action is required. Valve 4 is also connected to valve 5, and this has no stream marking. It is
therefore marked but, as it is closed, it is not part of the stream and it is not added to the
stream table.
The next valve, 6, does nothing to valves 2 and 3 but is connected to valve 7, and so marks it
and creates yet another entry in the stream table. Valve 7 itself is the next to be processed, passes
by valve 6 but now encounters valve 9, which is already marked as belonging to stream B. Valve
7 is therefore marked as a cross-over error. The connection from valve 7 to valve 10 changes
nothing, so the processing of stream A is complete.
Starting with the first valve in stream B, valve 9, we come to valve 5. This is already marked
as connected to stream A, but it is closed. We have therefore arrived at the same valve by two
different routes. Valve 5 is marked as a single separation. Note that processing must have arrived
at a different side of valve 5 this time because all the routes of stream A were explored fully before
starting on stream B. If the new entries had been put at the end of the table, it would be possible
to arrive at the same side of a closed valve by two different routes, and so class it as a single-valve
separation, even though there may be many closed valves on the 'far' side of it (Table 2).
Processing valves 8 and 10 adds no new information, so the final form of the valve table is shown
in Table 3. Valve 3 has been marked with a 1 as a single-valve separation, and valve 7 as the valve
at which the cross-over between the two streams was detected. Valves 4, 5, 6 have been marked
as valves which are part of a stream but not originally declared as such, but valve 5, although
connected to valve A and a single-valve separation from an unidentified other stream, is not marked
as either originally part or not originally part of any stream.
COMPUTER IMPLEMENTATIONS
The algorithm has been coded and tested in two languages. One is NOMAD2, the relational
data-base manager owned by Dun and Bradstreet Computing Services; the other is Knowledgeman
from Micro Data Base Systems Inc., which runs on an IBM Personal Computer. It would be
possible to code it in many other languages, but the ease with which a search through a table for
the right record can be written made these attractive.
OTHER POSSIBILITIES
The original real problem involves a network which is sufficiently large (around 600 valves and
2000 connections) that lists of the tables will be daunting to a user. It was therefore intended to
be linked to a graphical display system which includes zooming, panning and scrolling, so that the
TABLE 3. Final form of valve table
Valve-identifier Status Stream Originally-part Error
I 0 A Y
2 0 A Y
3 0 A Y
4 0 A N
5 C A
6 0 A N
7 0 A N X
8 0 B Y
9 0 B Y
10 0 B Y
59
Journal of the Operational Research Society Vol. 39, No.1
user can see the network with the errors highlighted by changing the colours in which the valves
are displayed. The user can alter the drawing to 'open' or 'close' valves, and the data a r ~ then passed
to the processing algorithm for another cycle until the user is satisfied. This is a topic of more
interest to computer scientists, and need not be pursued here.
Operational research is more concerned with optimizing, and it would be possible to look for
an optimum route if such could be defined. One possible definition is to look for the routeing
between two defined terminations which does not prejudice any of the existing routeings and which
involves changing the minimum number of valves. It could be argued that this is a short-sighted
strategy, and that it would be preferable to find the solution which maximizes the flexibility to add
still more routes. This definition lacks precision but is 'likely to be one with greater appeal to at
least some of the users of the algorithm. In any case, it is left to other workers to develop.
REFERENCES
1. C. J. DATE, An Introduction to Data-Base Systems, Addison-Wesley, Reading, Mass.
2. J. MARTIN, Computer Data-Base Organisation. Prentice-Hall, Englewood Cliffs, N.J.
60