2/23/2014

1 3 4 2 1 2 4 5 7 9 6 8 10

7 9

8 10

17

21

25

31 42

45 50 35 36

11 2 7 12 13 3 8 18 22 26 29 32 37 39 41 40 51 43 46

Path and Equipment Allocation for Multiple, Concurrent 30 Plant 34 Processes on Networked Process Units Part 2 48 27 38
14 15 16 5 10 20 24 28 33 19 23 4 9

49 52

44

47

'On entry, s() contains the array of inadmissable nodes; 'on exit, it is augmented with nodes labelled during the search Sub Dijkstra(N, Dsn, Dtn, PFound) Const WAYBIG = 9999 Dim pi(MAXARCS) As Integer 'pi(i) distance of node i to source node

From Flowsheet Specification to Goal Realization with Examples and Code

James A. Uthgenannt

Path and Equipment Allocation for Multiple, Concurrent Processes on Networked Process Plant Units Part 2: From Flowsheet Specification to Goal Realization with Examples and Code Listings James A. Uthgenannt Abstract A method of automatic assignment of concurrent, non-interfering path and equipment allocations among networked process units is presented. Guidance is offered for the analysis and rendition of plant topologies to conform with the solution methodology presented. A working automatic implementation is presented as a companion application. Example problems are provided along with input data for use in the application. Revision History
Revision Date Description

February 23, 2014

1 2

17-Feb-2014 23-Feb-2014

First Issue Changes to incorporate use of indirect min-heap priority queue and corrected/updated performance notes comments in the Code Implementation section.

Introduction: Previously [1], a methodology was presented to automatically assign flow paths among interconnected process units. The method allows assignment of concurrently active, non-interfering flow paths subject to an important class of qualitative constraints including equipment availability and compatibility. Extensions of the previous method are also provided. The method uses results from the discipline of network analysis [2, 3]. The treatment here is somewhat analogous to that used in modern roadway map routing systems; one readily expects a navigation system to properly route you from New York to Los Angeles. Further refinements might specify NY to LA via Memphis while avoiding Albuquerque. The method described here functions analogously on networked chemical process units. An additional requirement from that application space would be to avoid overlapping paths, or more specifically, a given path must be isolated from any other concurrently operating one. In the roadway map routing space, this would be like providing the specified route from NY to LA and a separate, nonoverlapping route from Philadelphia to San Antonio. Two example systems are provided to accompany the application. The first system was considered in the earlier paper [1]. The second system illustrates the methods use when temporary connections may be present in the network, as may be found when employing flexible hose with dry disconnect couplings or transfer panels with U-bend spool pieces. Flowsheets with their respective program input renditions are provided. The overall procedure requires some upfront analysis to render the process flowsheet into the format of a directed graph; this occurs in the design phase and provides input configuration for the application. The user then specifies source, destination, and any intermediate equipment necessary to participate in a particular transfer as well as any equipment that is to be excluded from the search. Upon completion, Feb. 2014 Page 2 of 12

if a path is feasible, the path nodes are presented as well as those nodes that isolate the path; these nodes are excluded from the search space of any subsequent but concurrently allocated transfer. Nodes excluded from the search space of a path goal include those allocated to current transfers as well as user-specified exclusions (for instance, equipment may be out of service, soiled, or incompatible with a given recipe). A more formal treatment of the overall procedure and method is given in [1]. The method described does not consider flow capacity limitations or material balance requirements. Flowsheet Rendition A flowsheet must first be rendered into a directed graph format. Equipment such as vessels, pumps and valves are represented as nodes. The physical flow paths among this equipment are represented as arcs. Mixed abstraction levels are easily accommodated and encouraged during flowsheet rendition. For example, valves associated with utility services or intra-unit controls that are not relevant to transfer of material among units and interposing modules are not depicted. So, this approach may leverage the ISA-88.00.01 unit, equipment module, and control module models widely used in industry. Figure 1 illustrates how a simple flowsheet may be represented as a directed graph, and in turn, an arclist data structure. The arc-list will be the underlying numerical representation of the flowsheet. Each potential flowpath between 2 nodes is represented by a directed arc. Each arc is weighted (or assigned a length or cost); the weights are additive as we traverse a path of nodes. So, if each arc was to have a length of 1, a shortest path from a source to a destination would simply be that path that minimizes the number of nodes traversed. Arc weights/costs can be assigned at the designers discretion to otherwise favor one path over another when redundant paths are available. Additionally, the designer can discourage assignment of pathological flow paths by not defining arcs that might represent some circuitous backflow condition, despite the fact that such paths are physically feasible. In practice, once the flowsheet elements are identified and indexed (as in Figure 1A), the arc list (Figure 1C) may readily by created by inspection. Thus, a directed graph drawing (Figure 1B) should usually not be required. Appendix 1 provides rendition tips for process elements other than simple discrete valves.

Feb. 2014

Page 3 of 12

1 3 4

1 3 5 6 7 9

2 4 8 10

7 9

8 10

Origin Node 1 2 3 3 4 4 5 5 6 6 7 8

Terminal Node 3 4 5 7 6 8 6 7 5 8 9 10

Arc Cost 1 1 1 1 1 1 1 1 1 1 1 1

Figure 1A Flowsheet fragment assume flow directions down and across

Figure 1B Directed graph representation of flowsheet fragment arcs indicate connections and flow directions

Figure 1C Arc list representation of flowsheet fragment each row describes an arc. Flow is directed from origin node to terminal node of a given arc

Goal / Policy Declaration Once the arc-list is defined, goals and policies can be input to generate material flow paths. The goal may be as simple as (from Figure 1) specify a flowpath from node 1 to node 9. Upon successful execution, the path from 1 to 9 will be found. The path of length 3 with path node set {1, 3, 7, 9} along with the isolation node set {5} would be returned. This information can be used to lock valve 5 while implementing the transfer with the path node set in a real-time application. (see Figure 2).
1 3 5 7 9 6 8 10 7 9 2 4 1 3 5 6 8 10 7 9 2 4 1 3 5 6 8 10 2 4

Figure 2A Flow path from node 1 to 9; node 5 isolates the path.

Figure 2B Flow path from node 1 to 9 with concurrent flow path from 2 to 10; nodes 5 and 6 isolate the paths.

Figure 2C Flow path from node 1 to 10; nodes 4 and 7 isolate the path. (A concurrent flow path between 2 and 9 is infeasible).

In Figure 2B, two concurrent allocations are active. The first allocation was described in Figure 2A whereas the second allocation represents a transfer from node 2 to node 10; {6} is the isolation node set for the second transfer. Note that path node sets of concurrent allocations are disjoint whereas, in general, their isolation node sets may not be (for example, if valve 6 was absent from the flowsheet, { 5} would be the isolation node set for each of the 2 aforementioned allocations). In Figure 2C, the desired transfer is from 1 to 10; a path of length 5 with path node set {1,3,5,6,8,10} and isolation node set {4, 7} is determined. If a desired transfer from 2 to 9 was requested concurrently, the path would be deemed infeasible (the path nodes and isolation nodes of the first transfer are made inadmissible for concurrent path goals).

Feb. 2014

Page 4 of 12

Technology/Algorithm Summary The technology is formalized in [1] and is now summarized. A process flowsheet is rendered to a directed graph which is then represented as a forward and reverse star data structure [3]. Dijkstras label-setting shortest path algorithm is used to find the shortest path between a specified source/destination from among admissible nodes. Node inadmissibility constraints are accomplished by pre-populating the labeled node set prior to executing the shortest path search. Once the path node set is found, all nodes neighboring each of those in the path set are identified and used to create an isolation node set. All allocated path node sets and their isolation node sets are made inadmissible to subsequent, concurrent allocations. Discussion The method alone could be useful for the process analyst to quickly identify process elements necessary to set up a flow path and isolate it. The results would be useful for hard-coding valve/equipment lineups for transfer sequences. The method could also be integrated in a real-time environment for allocation and path assignment. One may wonder when the complexity of a flowsheet/process would warrant the effort to implement a real-time application. The answer to that question isnt straightforward. Factors that would tend to favor a realtime implementation include: High flowsheet complexity in relation to the number of transfer paths available coupled with a high number of process elements that participate in each transfer. Requirement for concurrent transfers that may compete for shared resources Processes where redundant/multiple paths are available to achieve a given transfer. Requirements for ad hoc exclusion of process element(s) from the flowsheet. Flowsheet/process topology subject to change Desire to more loosely couple particular flowsheet topologies from general sequence recipes (the prospect for a design shift from hard-coding exact valve lineups to merely specifying source/destination when implementing transfers)

A real-time implementation of this method would need to be coupled with other essential elements of process control. This includes but is not limited to control module, equipment module, and unit definitions, sequence definitions, recipe information, and operator interface requirements.

Feb. 2014

Page 5 of 12

Code Implementation The algorithms for path allocation are presented as a companion Microsoft Excel 2007 application using a Visual Basic for Applications (VBA) module and two worksheets. Arc list data is read from the worksheet, Flowsheet Configuration. Results are output to the worksheet, Path Results. This implementation medium was chosen for a couple of reasons: 1. Excel is widely used and would allow use of this application directly by process analysts, designers, researchers, and the otherwise curious. 2. The data structures, instruction set, and control structures are relatively primitive and should allow the application to be easily ported to commercial real-time system platforms, primarily programmable logic controllers and those employed by distributed control systems. Other notes 1. 2. 3. 4. 5. 6. The application presented should be considered proof of concept. Both arc costs and node designations must be positive integers. No validation is performed on the arc list representation of the flowsheet. Little or no error checking is performed on user inputs during path assignment setup. Garbage in equals garbage out (if it gets that far). The user interface is intentionally primitive so as not to hide or obscure the workings of the application. The novelty of the application lies primarily in the routine, PathNav. Other routines simply support this one; their inner workings are detailed in [2, 4] or are accessible with simple internet searches (for the Shellsort routine, for instance). For this reason, the PathNav routine is more extensively annotated than the other routines. Node designations assigned during flowsheet rendition represent an index to some named equipment. Ideally, the index should start at/near 1 and be incremented with closely spaced intervals (ideally 1). This will help keep array sizes as small as possible. Theoretical worst case performance of the algorithm is provided: a. Shells method for sorting the arc lists (during initialization only) and is o(m3/2) where m is the number of arcs. Actually performance should be far better since it is assumed the lists will be nearly sorted to begin with. b. Dijkstras shortest path with linear search priority queue is o(n2), where n is the number of nodes. This approach is employed in FlowNav.txt. c. Dijkstras shortest path with indirect minimum heap priority queue is, very conservatively, o((m+n)*log2(n)). This approach is employed in FlowNav0201.txt. Once comfortable with the rendering process, the reader/user is encouraged to make modifications to the example flowsheets and respective arc lists to experience the ease with which changes/redefinition can be accommodated. (For example, add additional units/valves and select them in new desired flowpaths). Static only memory allocation is employed.

7.

8.

9.

10.

Feb. 2014

Page 6 of 12

Using the Application The application was implemented in Microsoft Excel 2007 with Visual Basic Applications and is contained in the file, FlowNav.xlsm. Since most public file hosting sites do not support sharing embedded macros (such as .xlsm filetypes), the application was deconstructed. The application is easily reconstructed as follows (procedure below applies to Microsoft Excel 2007): 1. 2. 3. 4. 5. 6. 7. NB: Rename the file FlowNav.txt to FlowNav.bas Open the file FlowNav.xlsx with Microsoft Excel Select the Developer tab and then click on the Visual Basic editor From the Visual Basic editor, click File, then Import File From the Import File dialog box, locate and select the file FlowNav.bas, then click Open Save the workbook as a Macro-Enabled workbook (with .xlsm filetype) The reconstructed FlowNav.xlsm should be ready to roll Substitute FlowNav0201 in place of FlowNav in steps 1 and 5 above to substitute minimum heap in place of linear search as the priority queue employed in the shortest path algorithm.

In order to input meaningful requests to the application, have hardcopies of the example flowsheets before you; these will allow you to choose meaningful path requests and make sense of the results provided by the application. The worksheet, Flowsheet Configuration, contain arc-list renderings of the example flowsheets. When the application is first reopened, a Security Warning will be presented with an Options button. Click the Options button, select the Enable this content button, then click ok. From the Path Results worksheet, click the Run Program button that appears on the left. Prompts will appear for you to enter flowsheet option (blending or pharma), Source Node, Destination Node, (any) intermediate nodes, and (any) exclusion nodes. Path information will be displayed in the table provided. Prompts will then appear to deallocate paths created followed by a prompt to enter a new transfer goal (or quit). You must quit in order to run the application against the other flowsheet or before modifying a flowsheet.

Feb. 2014

Page 7 of 12

Examples Two examples are provided below and are rendered in the worksheet, Flowsheet Configuration. Example 1 (Blending) The first flowsheet example was considered earlier [1] and is given below. It is comprised of five storage tanks, three blenders, four pumps, and forty valves. This example is useful to explore how redundant paths may be assigned as well as how the algorithm adapts to user-excluded nodes.

17

21

25

31 42

45 50 35 36

11 2 7 12 13 3 8 30 14 9 15 16 5 10 20 24 28 33 19 23 27 18 22 26 29 32 34 38 37 39 41 40 51 43 46 48

49 52

44

47

Feb. 2014

Page 8 of 12

Example 2 (Pharma) The second flowsheet example is comprised of a CIP unit, two preparation units, six transfer panels, one pump, ten totes, and thirty three valves. The CIP system is labeled twice to accommodate a cyclical flow path. This and the transfer panel require special rendering consideration as discussed in Appendix 1. In this example, the ports on the larger transfer panel were indexed whereas the ports on the smaller panels were not; this was done for convenience to more easily delineate arcs. (This too, reflects the discretion afforded the analyst). A CIP cycle might be specified as source: 1, destination: 2, intermediate: 29. The program will define the cyclical path as well as identify those transfer panel connections (as arc numbers) that need to be (manually) made.

Feb. 2014

Page 9 of 12

1,2 CIP 3 4 7 6 5 8

Preparation

9 Transfer Panel 1 (TP1) 11 14 20 12

10 13 15 17 16 53 52 51 21 19 22 27 55 28 54

18 23 24 33 34 43 44 TP1 potential connections 11 12 13 17 14 15 16 35 36 45 25 26 TP2 Totes 37 38

29 30 39 40 46 47

31 32 41 42 48 49 50

TP2 potential connections (typical) 35 36

Feb. 2014

Page 10 of 12

Acknowledgements This work acknowledges all of those who have shared their knowledge both privately and publicly to enrich their respective disciplines and to enlighten both research and practicing communities. References 1. Uthgenannt J. A., Path and Equipment Allocation for Multiple, Concurrent Processes on Networked Process Plant Units. Computers Chem. Engng 20, 1081-1087 (1996). 2. Jensen P. A. and J. W. Barnes, Network Flow Programming. Krieger, Malabar, FA (1987). 3. R.K. Ahuja, T.L. Magnanti, J.B. Orlin, Network Flows. Working paper 2059-88, Alfred P. Sloan School of Management, MIT, Cambridge, MA (1988). Web. February 15, 2014 4. http://jorlin.scripts.mit.edu/docs/SolutionManual/Chapter2.pdf (exercise 2.39) . Web. February 15, 2014

Appendix 1 Handling / Rendering of special case process elements Many process elements are simply modeled as shown in Figure 1. Elements such as open/close valves, pumps, and process units are such examples. These lead to nodes that either block or allow material throughput. Examples of elements requiring special modeling are considered below. Flexible hose with dry disconnect couplings or transfer panel with U-bend spool pieces (hereafter referred to as temporary connections). These elements can be thought of as a set of potentially configurable flow paths/arcs among a set of nodes with the physical restriction that at most one such arc connection to a node can be realized at a time. This restriction itself serves to isolate flow paths. Thus, this topology must be handled differently than fixed connections between nodes in that the categorization of isolation nodes will be different than that illustrated in Figure 1. Additionally, if bidirectional flow capability through a temporary connection is required, additional algorithmic precautions are necessary (assuming that each node has one physical port to which a temporary connection can be made). The following figures illustrate these points.
1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12

Figure A1 Flowsheet fragment with potential temporary connections as gray arcs; at most one per node can be realized at a time. Each double-arrowed line represents 2 arcs, one for each direction.

Figure A2 Flow path from node 1 to 10 with concurrent flow path from 12 to 2; no isolation nodes present. Temporary connections are realized between nodes 4/7 and 9/5.

Figure A3 Flow path from node 1 to 2 is infeasible because node 8 may realize at most 1 temporary connection where two are depicted.

Feb. 2014

Page 11 of 12

In practice, temporary connections may be represented in an arc list in one of two ways. Either an arc attribute can be maintained in an explicit data structure or, as in the case of the pharma example, a special arc weight value can be reserved to indicate a potential temporary connection.

3-way / diverter valves A 3-port valve typically allows flow in one of two paths; it does not block flow, it redirects flow. Such valves may be rendered as follows as in figures A4, A5, and A6.
1 2 3 4 1 2a 2b 5 6 5
Figure A4 Flowsheet fragment with 3-way valves.

3a 3b 6

2a 2b 5

3a 3b 6

Figure A5 Each 3-way valve rendered using 2 nodes.

Figure A6 Flow path from node 1 to 6; nodes 3a and 2b isolate the path.

Each 3-way valve is represented by 2 nodes. In practice, both nodes would have a strictly numeric designation and be indexed to the same control module (or device) that represents the valve. In this case, the commands for the a/b pair would be self consistent (port a is open when port b is closed, and vice versa).

Situations requiring a flow cycle There may be instances when a cyclical path is required, as is the case with a clean-in-place (CIP) system. In this case, the CIP unit may be described as two nodes. A cyclical path is found by specifying the CIP supply as the source, and the CIP return as the destination. The object(s) to clean are specified as intermediate nodes on the path. (See the pharma example)

1,2 3 5 3 6

5 4 6

4
Figure A7 Flowsheet fragment with flow cycle.

Figure A8 Flow cycle rendered using 2 nodes to depict one unit.

Feb. 2014

Page 12 of 12