The document introduces the Capital Investment & Facilities Location, Industrial Modeling Framework (CIFL-IMF) which models capital investment and facilities location problems. It describes a flowsheet example involving multiple unit operations producing and storing products. The framework uses a Unit-Operation-Port-State Superstructure (UOPSS) and Quantity-Logic-Quality Phenomena (QLQP) modeling approach to represent complex industrial systems. It formulates the problem as a mixed-integer linear program to maximize net present value over time considering capital costs, production costs, and budget constraints.

1. Capital Investment & Facilities Location, Industrial Modeling Framework
(CIFL-IMF)
J.D. Kelly1 & A. Vazacopoulos2
i n d u s t r IAL g o r i t h m s
January, 2013
Introduction to Capital Investment & Facilities Location, UOPSS and QLQP
Presented in this short document is a description of what is typically known as a capital
investment or facilities location problem involving fixed-charge and economies-of-scale details
(Williams, 1993 and Winston, 1994). It is also known as a long-range strategic capacity
expansion problem (Sahinidis et. al. 1989, Lui and Sahinidis, 1995, 1996 and Lui et. al., 1996).
Figure 1 below depicts two processing unit-operations (batch and continuous) producing
product stocks D and E from feed stocks A, B and C. Each feed and product has dedicated
storage where product E is only produced if capital is expended to install a new continuous-
process unit either consuming A or B but not both. The capacity of the batch-process unit can
also be expanded or extended where D is an intermediate product. Cash-flows are also shown
constrained by budgetary restrictions which represent both a fixed-charge amount and a
variable-charge amount scaled by the throughput of the units i.e., batch, charge or lot-sizes.
Figure 1. Capital Investment & Facilities Location Flowsheet Example.
1
jdkelly@industrialgorithms.ca
2
alkis@industrialgorithms.com

2. A full description of the objects found in Figure 1 (as well as other objects not shown) can be
found in Kelly (2004b) and Zyngier and Kelly (2009) and is based on our Unit-Operation-Port-
State Superstructure (UOPSS) and our Quantity-Logic-Quality Phenomena (QLQP) (Kelly,
2005). In UOPSS, the units represent physical equipment which can have one or more
procedural operations assigned, attached or associated with it. The cross-product of a unit with
an operation creates a projectional unit-operation which is sometimes referred to as a virtual,
logical or hypothetical object. We impose symmetry with the projectional port-state where the
port is physical and the state is procedural where the state characterizes the type of substance
passing through the port-state. Connectivity is modeled as paths between unit-operations and
port-states and represents the flow of something. The key idea of UOPSS is its ability to
explicitly manage the fact that a single unit can have multiple operations each with a different
configuration of port-states (e.g., BATCH and CONTINUOUS in Figure 1) and allows for very
complex flowsheets to be depicted graphically. An important notion that we exploit with respect
to the QLQP is our novel phenomenological decomposition3 of logistics and quality. Logistics is
the combination of quantity and logic where quantities are flows, holdups, yields and rates and
the logic aspects are related to the setup, startup, switchover, shutdown, status, etc. (Kelly and
Zyngier, 2007) of unit-operations and is solved using mixed-integer linear programming (MILP),
meta-heuristics (Genetic Algorithms, Simulated Annealing, etc.) and/or constraint programming
(CP).
The industrial shipping model presented above is MILP4 based but most process industry
production or manufacturing problems also contain a quantity times quality (sub-)problem due to
intensive variables such as densities, components, properties and conditions multiplied by
extensive quantities such as flows and holdups and is solved using nonlinear programming
(NLP). Furthermore, our modeling framework is based on a discrete-time time-indexed
formulation which requires each time-period to have the same time duration. Other time-
indexed formulations classed as continuous-time models are available and have several
variations based on whether the asynchronous time-periods are defined for a global/common
time grid or local/specific to each unit. However, for our industrial planning and scheduling
problems we have found discrete-time to be not only computationally effective (Maravelias,
2012) but also appropriate when dealing with the many nuances of the problem specification
especially handling partially specified plans or schedules in the future i.e., manually locking or
fixing certain future activities and solving around or between them. This is very important for
industrial decision-making problems where some level of transparency for the user, modeler or
analyst is required in terms of how the planning or scheduling solution is computed from
essentially black-box solvers5.
Industrial Modeling Framework (IMF), IMPRESS and SIIMPLE
To implement the mathematical model of this and other systems, Industrial Algorithms offers a
unique approach and is incorporated into our Industrial Modeling and Pre-Solving System we
call IMPRESS. IMPRESS has its own modeling language called IML (short for Industrial
Modeling Language) which is a flat or text-file interface as well as a set of API's which can be
called from any computer programming language such as C, C++, Fortran, Java, C# or Python
3
Other decompositions are well known such as hierarchical, structural, spatial and temporal but the concept
of phenomenological decomposition is new at least in name for advanced planning and scheduling problems.
4
Although MH and CP as well as local search (LS) solvers can be integrated, at present they are not.
5
Most industrial scheduling applications are still simulation-based where the schedules are built manually and
incrementally one decision at a time so feedback in terms of cause and effect is important to the user.

3. called IPL (short for Industrial Programming Language) to both build the model and to view the
solution. Models can be a mix of linear, mixed-integer and nonlinear variables and constraints
and are solved using a combination of LP, QP, MILP and NLP solvers such as COINMP, GLPK,
LPSOLVE, SCIP, CPLEX, GUROBI, LINDO, XPRESS, CONOPT, IPOPT and KNITRO as well
as our own implementation of SLP called SLPQPE (successive linear & quadratic programming
engine) which is a very competitive alternative to the other nonlinear solvers.
The underlying system architecture of IMPRESS is called SIIMPLE (we hope literally) which is
short for Server, Interacter (IPL), Interfacer (IML), Modeler, Presolver Libraries and Executable.
The Server, Presolver and Executable are primarily model or problem-independent whereas the
Interacter, Interfacer and Modeler are typically domain-specific i.e., model or problem-
dependent. Fortunately, for most industrial planning, scheduling, optimization and control
problems found in the process industries, IMPRESS's standard Interacter, Interfacer and
Modeler are well-suited and comprehensive to model the most difficult of production and
process complexities allowing for the formulations of ubiquitous conservation laws, rigorous
constitutive relations, empirical correlative expressions and other necessary side constraints.
User or adhoc constraints can be augmented or appended to IMPRESS when necessary in
several ways. For MILP or logistics problems we offer user-defined constraints configurable
from the IML file or the IPL code where the variables and constraints are referenced using unit-
operation-port-state names and the quantity-logic variable types. It is also possible to import a
foreign LP file (row-based MPS file) which can be generated by any algebraic modeling
language or matrix generator. This file is read just prior to generating the matrix and before
exporting to the LP, QP or MILP solver. For NLP or quality problems we offer user-defined
formula configuration in the IML file and single-value and multi-value function blocks writable in
C, C++ or Fortran. The nonlinear formulas may include intrinsic functions such as EXP, LN,
LOG, SIN, COS, TAN, MIN, MAX, IF, LE, GE and KIP, LIP, SIP (constant, linear and monotonic
spline interpolation) as well as user-written extrinsic functions.
Industrial modeling frameworks or IMF's are intended to provide a jump-start to an industrial
project implementation i.e., a pre-project if you will, whereby pre-configured IML files and/or IPL
code are available specific to your problem at hand. The IML files and/or IPL code can be
easily enhanced, extended, customized, modified, etc. to meet the diverse needs of your project
and as it evolves over time and use. IMF's also provide graphical user interface prototypes for
drawing the flowsheet as in Figure 1 and typical Gantt charts and trend plots to view the solution
of quantity, logic and quality time-profiles. Current developments use Python 2.3 and 2.7
integrated with open-source Dia and Matplotlib modules respectively but other prototypes
embedded within Microsoft Excel/VBA for example can be created in a straightforward manner.
However, the primary purpose of the IMF's is to provide a timely, cost-effective, manageable
and maintainable deployment of IMPRESS to formulate and optimize complex industrial
manufacturing systems in either off-line or on-line environments. Using IMPRESS alone would
be somewhat similar (but not as bad) to learning the syntax and semantics of an AML as well as
having to code all of the necessary mathematical representations of the problem including the
details of digitizing your data into time-points and periods, demarcating past, present and future
time-horizons, defining sets, index-sets, compound-sets to traverse the network or topology,
calculating independent and dependent parameters to be used as coefficients and bounds and
finally creating all of the necessary variables and constraints to model the complex details of
logistics and quality industrial optimization problems. Instead, IMF's and IMPRESS provide, in
our opinion, a more elegant and structured approach to industrial modeling and solving so that
you can capture the benefits of advanced decision-making faster, better and cheaper.

4. CIFL-IMF Modeling Details
At this point it is prudent to elucidate more of the modeling details found in Figure 1. The
production facility or plant is represented by a supply of raw materials A, B and C which can be
used to produce finished product D in an existing batch-process unit-operation labeled BATCH,
EXISTING. Batch-processes exhibit a distinct "fill-hold-draw" holdup or inventory profile over
time (Zyngier and Kelly, 2009) where the feeds can be filled or loaded into the batch vessel
either continuously or intermittently over the duration of the batch known as its cycle or
processing-time. Finished product E is produced in a (future) continuous-process unit named
CONTINUOUS requiring D and A for operation INSTALLATION1 and D and B for
INSTALLATION2. Continuous-processes exhibit no or negligible holdup during the processing
and as such simultaneously produce E the instant D and A or B is available where the fill-hold-
draw profile collapses to a concurrent fill-draw with no hold of course. The non-material or non-
stock flow called CAPITAL is a pecuniary or currency resource and is located on what we call a
port-state.
Port-states allow flow into and out of a unit-operation and can be considered as flow-interfaces
similar to ports on a computer i.e., nozzles, spouts, spigots. Port-states also provide an
unambiguous description of the flowsheet or superstructure in terms of specifically what type of
materials or resources are being consumed and produced by the unit-operation. Port-states
can also represent utilities (steam, power), utensils (operators, tools) as well as signals such as
data, time, tasks, etc. Each of the two products D and E have tanks available for storage and is
a requirement when balancing the production-side supply with the transportation-side demand
of the value-chain. Finally, the lines or arcs between the unit-operations and port-states and
across an upstream unit-operation-port-state to a downstream unit-operation-port-state
correspond to flows as one would except given that the superstructure is ultimately composed of
a network or graph of nodes/vertices and arcs/edges (directed).
We now feature the capital investment or facilities location details of the problem where the
objective function of the problem is to maximize the net-present-value6 (NPV) of the profit
(revenue minus feed costs and capital costs) over time. The time-horizon is usually modelled
over several years where the time-periods are in years or sub-years such as quarters. These
time-periods can also be non-uniform in the sense that their durations can be variable but
exogenously defined (known a priori). These types of problems may have different aggregated
or disaggregated formulations such as lot-sizing reformulations (Liu and Sahinidis, 1996) which
are not applied explicitly in this model7.
The unit BATCH is existing but its capacity can also be expanded at a cost. This cost is well
known to have essentially two parts, a fixed and a variable cost where the fixed cost is applied
to the binary or logic variable determining the existence of the expansion (i.e., its setup or
startup logic) and the variable cost is applied to its throughput or batch-size. When known
power-law relationships of capital cost versus throughput are available such as found in Gary
and Handwerk (1994), Johnson (1996) and Kaiser and Gary (2007), simple linear regression
can be applied to convert these to approximated fixed+variable coefficients (Liu et. al. 1996 and
Kelly 2004a) that can be easily used inside MILP formulations such as that presented here.
6
NPV simply discounts the objective function coefficients according to an inflation or deflation rate parameter
which can also be time-varying or time-dependent.
7
These types of reformulations can be generated automatically for each unit or unit-operation that is
identified as having a lot-sizing structure for example.

5. Each of the expansion and installation unit-operations shown i.e., EXPANSION1, etc. have a
CAPITAL port-state which carries the NPV cash-flow to the unit-operation named BUDGET
(diamond shaped). The inlet port-state of this unit-operation will have a time-varying NPV cash-
flow lower and upper bound to constrain the expansions and/or installations according to the
expected cash-flow profiles in the future. An additional restriction required, sometimes referred
to as a side-constraint, is the fact that if an expansion/installation unit-operation is selected in
some future time-period then it must be setup for the rest of the time-horizon. This can be
modeled using our up-time8 logic constraint where a lower or minimum up-time is configured as
the time-horizon length of the problem (Wolsey, 1998, Kelly and Zyngier, 2007 and Zyngier and
Kelly, 2009).
The unit CONTINUOUS is non-existing and requires a completely grass-roots or green-field
installation or construction. If selected, based on its economic viability with respect to its
expected installed cost and projected revenue of E, it will use D and either A or B as its co-feeds
and will produce final product E which also requires its own newly installed storage vessel. This
unit is also strictly conditional on either of the BATCH unit's expansion operations being
selected. That is, the CONTINUOUS unit will not be installed unless either EXPANSION1 or
EXPANSION2 operation is chosen. This is known as an implication or sequence-dependency
type of constraint and is managed by the fact that if there is no flow of D from the BATCH unit to
the CONTINUOUS unit then the CONTINUOUS unit cannot be installed or constructed given
that an infeasibility will occur during the branch-and-bound search of the MILP solution.
CIFL-IMF Solving Details
Once the flowsheet has been configured as in Figure 1, a *.UPS file (short for UOPSS) is
constructed using the UOPSS object names via a Python 2.3 macro (IALconstructer.py)
embedded in the Dia drawing package and is shown in Appendix A. This file can then be
included into the IML file or the IPL code and will define the necessary named keys or index-
sets for the various capacity data necessary to create the mathematical model. A useful facet of
the UPS file is the application of "aliases". Aliases allow the capacity configuration of many
UOPSS objects simultaneously - see ALLPARTS, ALLINPORTS, ALLOUTPORTS and
ALLPATHS.
TBD
References
Sahinidis, N.V., Grossmann, I.E., Fornari, R.E., Chathrathi, M., "Optimization model for long
range planning in the chemical industry", Computers & Chemical Engineering, 13, 1049, (1989).
Williams, H.P., "Modeling building in mathematical programming", 3rd Edition, John Wiley &
Sons, (1993).
Gary, J.H., Handwerk, G.E., "Petroleum refining technology and economics", 3rd Edition, Marcel
Dekker, New York, (1994).
Winston, W.L., "Operations research: applications and algorithms", Wadsworth Publishing
Company for Duxbury Press, Belmont, California, (1994).
8
Up-time is also known as a run or campaign-length and essentially restricts a shutdown of the unit-operation
for a specified number of time-periods in the future.

6. Liu, M-L., Sahinidis, N.V., “Computational trends and effects of approximations in an MILP
model for process planning”, Industrial & Chemistry Engineering Research, 34, 1662, (1995).
Liu, M-L., Sahinidis, N.V., “Long range planning in the process industries: a projection
approach”, Computers & Operations Research, 23, 237, (1996).
Liu, M-L., Sahinidis, N.V., Shectman, J.P., "Global optimization in engineering design",
Grossmann, I.E. (editor), Kluwer Academic Publishers, Boston, (1996).
Johnston, D., "Complexity index indicates refinery capability, value", Oil & Gas Journal, 94, 12,
(1996).
Wolsey, L.A., "Integer programming", Wiley-Interscience, New York, (1998).
Kelly, J.D., "Formulating production planning models", Chemical Engineering Progress,
January, 43, (2004a).
Kelly, J.D., "Production modeling for multimodal operations", Chemical Engineering Progress,
February, 44, (2004b).
Kelly, J.D., "The unit-operation-stock superstructure (UOSS) and the quantity-logic-quality
paradigm (QLQP) for production scheduling in the process industries", In: MISTA 2005
Conference Proceedings, 327, (2005).
Kaiser, M.J., Gary, J.H., "Study updates refinery investment cost curves", Oil & Gas Journal,
105, 82, (2007)
Kelly, J.D., Zyngier, D., "An improved MILP modeling of sequence-dependent switchovers for
discrete-time scheduling problems", Industrial & Engineering Chemistry Research, 46, 4964,
(2007).
Zyngier, D., Kelly, J.D., "Multi-product inventory logistics modeling in the process industries", In:
W. Chaovalitwonse, K.C. Furman and P.M. Pardalos, Eds., Optimization and Logistics
Challenges in the Enterprise", Springer, 61-95, (2009).
Maravelias, C.T., "On the combinatorial structure of discrete-time MIP formulations for chemical
production scheduling", Computers and Chemical Engineering, 38, 204, (2012).
Appendix A - CIFL-IMF.UPS (UOPSS) File
i n d u s t r I A L g o r i t h m s
All Rights Reserved (c)
checksum,184
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Unit-Operation-Port-State-Superstructure (UOPSS) *.UPS File.
! (This file is automatically generated from the Python program IAConstructer.py)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
&sUnit,&sOperation,@sType,@sSubtype,@sUse
A,,perimeter,,
A,,pool,,
B,,perimeter,,
B,,pool,,
BATCH,EXISTING,processb,,
BATCH,EXPANSION1,processb,,
BATCH,EXPANSION2,processb,,
BUDGET,EXPENDITURE,perimeter,,

7. C,,pool,,
C,,perimeter,,
CONTINUOUS,INSTALLATION1,processc,,
CONTINUOUS,INSTALLATION2,processc,,
D,,pool,,
D_CUSTOMER,D,perimeter,,
E,INSTALLATION,pool,,
E_CUSTOMER,E,perimeter,,
&sUnit,&sOperation,@sType,@sSubtype,@sUse
! Number of UO objects = 16
&sAlias,&sUnit,&sOperation
ALLPARTS,A,
ALLPARTS,A,
ALLPARTS,B,
ALLPARTS,B,
ALLPARTS,BATCH,EXISTING
ALLPARTS,BATCH,EXPANSION1
ALLPARTS,BATCH,EXPANSION2
ALLPARTS,BUDGET,EXPENDITURE
ALLPARTS,C,
ALLPARTS,C,
ALLPARTS,CONTINUOUS,INSTALLATION1
ALLPARTS,CONTINUOUS,INSTALLATION2
ALLPARTS,D,
ALLPARTS,D_CUSTOMER,D
ALLPARTS,E,INSTALLATION
ALLPARTS,E_CUSTOMER,E
&sAlias,&sUnit,&sOperation
&sUnit,&sOperation,&sPort,&sState,@sType,@sSubtype
A,,A,,out,
A,,A,,in,
A,,A,,out,
B,,B,,in,
B,,B,,out,
B,,B,,out,
BATCH,EXISTING,A,,in,
BATCH,EXISTING,B,,in,
BATCH,EXISTING,C,,in,
BATCH,EXISTING,D,,out,
BATCH,EXPANSION1,A,,in,
BATCH,EXPANSION1,B,,in,
BATCH,EXPANSION1,C,,in,
BATCH,EXPANSION1,CAPITAL,,out,
BATCH,EXPANSION1,D,,out,
BATCH,EXPANSION2,A,,in,
BATCH,EXPANSION2,B,,in,
BATCH,EXPANSION2,C,,in,
BATCH,EXPANSION2,CAPITAL,,out,
BATCH,EXPANSION2,D,,out,
BUDGET,EXPENDITURE,CASH,,in,
C,,C,,in,
C,,C,,out,
C,,C,,out,
CONTINUOUS,INSTALLATION1,A,,in,
CONTINUOUS,INSTALLATION1,CAPITAL,,out,
CONTINUOUS,INSTALLATION1,D,,in,
CONTINUOUS,INSTALLATION1,E,,out,
CONTINUOUS,INSTALLATION2,B,,in,
CONTINUOUS,INSTALLATION2,CAPITAL,,out,
CONTINUOUS,INSTALLATION2,D,,in,
CONTINUOUS,INSTALLATION2,E,,out,
D,,D,,out,
D,,D,,in,
D_CUSTOMER,D,D,,in,
E,INSTALLATION,E,,out,
E,INSTALLATION,E,,in,
E_CUSTOMER,E,E,,in,
&sUnit,&sOperation,&sPort,&sState,@sType,@sSubtype
! Number of UOPS objects = 38
&sAlias,&sUnit,&sOperation,&sPort,&sState
ALLINPORTS,A,,A,
ALLINPORTS,B,,B,
ALLINPORTS,BATCH,EXISTING,A,
ALLINPORTS,BATCH,EXISTING,B,
ALLINPORTS,BATCH,EXISTING,C,
ALLINPORTS,BATCH,EXPANSION1,A,
ALLINPORTS,BATCH,EXPANSION1,B,
ALLINPORTS,BATCH,EXPANSION1,C,
ALLINPORTS,BATCH,EXPANSION2,A,
ALLINPORTS,BATCH,EXPANSION2,B,
ALLINPORTS,BATCH,EXPANSION2,C,
ALLINPORTS,BUDGET,EXPENDITURE,CASH,
ALLINPORTS,C,,C,
ALLINPORTS,CONTINUOUS,INSTALLATION1,A,
ALLINPORTS,CONTINUOUS,INSTALLATION1,D,
ALLINPORTS,CONTINUOUS,INSTALLATION2,B,
ALLINPORTS,CONTINUOUS,INSTALLATION2,D,
ALLINPORTS,D,,D,
ALLINPORTS,D_CUSTOMER,D,D,
ALLINPORTS,E,INSTALLATION,E,

8. ALLINPORTS,E_CUSTOMER,E,E,
ALLOUTPORTS,A,,A,
ALLOUTPORTS,A,,A,
ALLOUTPORTS,B,,B,
ALLOUTPORTS,B,,B,
ALLOUTPORTS,BATCH,EXISTING,D,
ALLOUTPORTS,BATCH,EXPANSION1,CAPITAL,
ALLOUTPORTS,BATCH,EXPANSION1,D,
ALLOUTPORTS,BATCH,EXPANSION2,CAPITAL,
ALLOUTPORTS,BATCH,EXPANSION2,D,
ALLOUTPORTS,C,,C,
ALLOUTPORTS,C,,C,
ALLOUTPORTS,CONTINUOUS,INSTALLATION1,CAPITAL,
ALLOUTPORTS,CONTINUOUS,INSTALLATION1,E,
ALLOUTPORTS,CONTINUOUS,INSTALLATION2,CAPITAL,
ALLOUTPORTS,CONTINUOUS,INSTALLATION2,E,
ALLOUTPORTS,D,,D,
ALLOUTPORTS,E,INSTALLATION,E,
&sAlias,&sUnit,&sOperation,&sPort,&sState
&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState
A,,A,,A,,A,
A,,A,,BATCH,EXISTING,A,
A,,A,,BATCH,EXPANSION1,A,
A,,A,,BATCH,EXPANSION2,A,
A,,A,,CONTINUOUS,INSTALLATION1,A,
B,,B,,B,,B,
B,,B,,BATCH,EXISTING,B,
B,,B,,BATCH,EXPANSION1,B,
B,,B,,BATCH,EXPANSION2,B,
B,,B,,CONTINUOUS,INSTALLATION2,B,
BATCH,EXISTING,D,,D,,D,
BATCH,EXPANSION1,CAPITAL,,BUDGET,EXPENDITURE,CASH,
BATCH,EXPANSION1,D,,CONTINUOUS,INSTALLATION1,D,
BATCH,EXPANSION1,D,,D,,D,
BATCH,EXPANSION2,CAPITAL,,BUDGET,EXPENDITURE,CASH,
BATCH,EXPANSION2,D,,CONTINUOUS,INSTALLATION2,D,
BATCH,EXPANSION2,D,,D,,D,
C,,C,,BATCH,EXISTING,C,
C,,C,,BATCH,EXPANSION1,C,
C,,C,,BATCH,EXPANSION2,C,
C,,C,,C,,C,
CONTINUOUS,INSTALLATION1,CAPITAL,,BUDGET,EXPENDITURE,CASH,
CONTINUOUS,INSTALLATION1,E,,E,INSTALLATION,E,
CONTINUOUS,INSTALLATION2,CAPITAL,,BUDGET,EXPENDITURE,CASH,
CONTINUOUS,INSTALLATION2,E,,E,INSTALLATION,E,
D,,D,,D_CUSTOMER,D,D,
E,INSTALLATION,E,,E_CUSTOMER,E,E,
&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState
! Number of UOPSPSUO objects = 27
&sAlias,&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState
ALLPATHS,A,,A,,A,,A,
ALLPATHS,B,,B,,B,,B,
ALLPATHS,A,,A,,BATCH,EXISTING,A,
ALLPATHS,B,,B,,BATCH,EXISTING,B,
ALLPATHS,C,,C,,BATCH,EXISTING,C,
ALLPATHS,A,,A,,BATCH,EXPANSION1,A,
ALLPATHS,B,,B,,BATCH,EXPANSION1,B,
ALLPATHS,C,,C,,BATCH,EXPANSION1,C,
ALLPATHS,A,,A,,BATCH,EXPANSION2,A,
ALLPATHS,B,,B,,BATCH,EXPANSION2,B,
ALLPATHS,C,,C,,BATCH,EXPANSION2,C,
ALLPATHS,BATCH,EXPANSION1,CAPITAL,,BUDGET,EXPENDITURE,CASH,
ALLPATHS,BATCH,EXPANSION2,CAPITAL,,BUDGET,EXPENDITURE,CASH,
ALLPATHS,CONTINUOUS,INSTALLATION1,CAPITAL,,BUDGET,EXPENDITURE,CASH,
ALLPATHS,CONTINUOUS,INSTALLATION2,CAPITAL,,BUDGET,EXPENDITURE,CASH,
ALLPATHS,C,,C,,C,,C,
ALLPATHS,A,,A,,CONTINUOUS,INSTALLATION1,A,
ALLPATHS,BATCH,EXPANSION1,D,,CONTINUOUS,INSTALLATION1,D,
ALLPATHS,B,,B,,CONTINUOUS,INSTALLATION2,B,
ALLPATHS,BATCH,EXPANSION2,D,,CONTINUOUS,INSTALLATION2,D,
ALLPATHS,BATCH,EXISTING,D,,D,,D,
ALLPATHS,BATCH,EXPANSION1,D,,D,,D,
ALLPATHS,BATCH,EXPANSION2,D,,D,,D,
ALLPATHS,D,,D,,D_CUSTOMER,D,D,
ALLPATHS,CONTINUOUS,INSTALLATION1,E,,E,INSTALLATION,E,
ALLPATHS,CONTINUOUS,INSTALLATION2,E,,E,INSTALLATION,E,
ALLPATHS,E,INSTALLATION,E,,E_CUSTOMER,E,E,
&sAlias,&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState