Maritime Industrial Modeling Framework - IMPRESS

283 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
283
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Maritime Industrial Modeling Framework - IMPRESS

  1. 1. Maritime Industrial Shipping, Industrial Modeling Framework (MIS-IMF) J.D. Kelly1 & A. Vazacopoulos2 i n d u s t r IAL g o r i t h m s January, 2013Introduction to Maritime Industrial Shipping, UOPSS and QLQPPresented in this short document is a description of what is typically known as a marineindustrial shipping problem as opposed to liner or tramp shipping (Christiansen et. al. 2004 andJetlund and Karimi, 2004). It is also known as a "maritime inventory routing problem" (MIRP)given that it involves both immobile (tanks) and mobile (ships) inventory management(Christiansen et. al., 2007 and Goel et. al., 2012).Figure 1 below depicts two processing unit-operations (batch and continuous) producingproduct stocks C, D and E from feed stocks A and B. Each product has dedicated storage fromwhich these materials are marine transported via three ships to two customers each with andwithout inventory. The ships have two possible routes each with varying size and number ofcargoes (compartments or holds) to store products C, D and E destined for either of its twocustomers. All of the materials are in the liquid phase where the shipping is for liquid-bulk only. Figure 1. Maritime Industrial Shipping Flowsheet Example. 1 jdkelly@industrialgorithms.ca 2 alkis@industrialgorithms.com
  2. 2. A full description of the objects found in Figure 1 (as well as other objects not shown) can befound in Kelly (2004) 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 moreprocedural operations assigned, attached or associated with it. The cross-product of a unit withan 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 theport is physical and the state is procedural where the state characterizes the type of substancepassing through the port-state. Connectivity is modeled as paths between unit-operations andport-states and represents the flow of something. The key idea of UOPSS is its ability toexplicitly manage the fact that a single unit can have multiple operations each with a differentconfiguration of port-states (e.g., SHIP2 and SHIP3 in Figure 1) and allows for very complexflowsheets to be depicted graphically. An important notion that we exploit with respect to theQLQP is our novel phenomenological decomposition3 of logistics and quality. Logistics is thecombination of quantity and logic where quantities are flows, holdups, yields and rates and thelogic aspects are related to the setup, startup, switchover, shutdown, status, etc. (Kelly andZyngier, 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 industryproduction or manufacturing problems also contain a quantity times quality (sub-)problem due tointensive variables such as densities, components, properties and conditions multiplied byextensive quantities such as flows and holdups and is solved using nonlinear programming(NLP). Furthermore, our modeling framework is based on a discrete-time time-indexedformulation which requires each time-period to have the same time duration. Other time-indexed formulations classed as continuous-time models are available and have severalvariations based on whether the asynchronous time-periods are defined for a global/commontime grid or local/specific to each unit. However, for our industrial planning and schedulingproblems 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 specificationespecially handling partially specified plans or schedules in the future i.e., manually locking orfixing certain future activities and solving around or between them. This is very important forindustrial decision-making problems where some level of transparency for the user, modeler oranalyst is required in terms of how the planning or scheduling solution is computed fromessentially black-box solvers5.Industrial Modeling Framework (IMF), IMPRESS and SIIMPLETo implement the mathematical model of this and other systems, Industrial Algorithms offers aunique approach and is incorporated into our Industrial Modeling and Pre-Solving System wecall IMPRESS. IMPRESS has its own modeling language called IML (short for IndustrialModeling Language) which is a flat or text-file interface as well as a set of APIs which can becalled from any computer programming language such as C, C++, Fortran, Java, C# or Pythoncalled IPL (short for Industrial Programming Language) to both build the model and to view the 3 Other decompositions are well known such as hierarchical, structural, spatial and temporal but the conceptof 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 andincrementally one decision at a time so feedback in terms of cause and effect is important to the user.
  3. 3. solution. Models can be a mix of linear, mixed-integer and nonlinear variables and constraintsand 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 wellas our own implementation of SLP called SLPQPE (successive linear & quadratic programmingengine) which is a very competitive alternative to the other nonlinear solvers.The underlying system architecture of IMPRESS is called SIIMPLE (we hope literally) which isshort for Server, Interacter (IPL), Interfacer (IML), Modeler, Presolver Libraries and Executable.The Server, Presolver and Executable are primarily model or problem-independent whereas theInteracter, Interfacer and Modeler are typically domain-specific i.e., model or problem-dependent. Fortunately, for most industrial planning, scheduling, optimization and controlproblems found in the process industries, IMPRESSs standard Interacter, Interfacer andModeler are well-suited and comprehensive to model the most difficult of production andprocess complexities allowing for the formulations of ubiquitous conservation laws, detailedconstitutive relations and other necessary side constraints.User or adhoc constraints can be augmented or appended to IMPRESS when necessary inseveral ways. For MILP or logistics problems we offer user-defined constraints configurablefrom 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 aforeign LP file (row-based MPS file) which can be generated by any algebraic modelinglanguage or matrix generator. This file is read just prior to generating the matrix and beforeexporting to the LP, QP or MILP solver. For NLP or quality problems we offer user-definedformula configuration in the IML file and single-value and multi-value function blocks writable inC, 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 monotonicspline interpolation) as well as user-written extrinsic functions.Industrial modeling frameworks or IMFs are intended to provide a jump-start to an industrialproject implementation i.e., a pre-project if you will, whereby pre-configured IML files and/or IPLcode are available specific to your problem at hand. The IML files and/or IPL code can beeasily enhanced, extended, customized, modified, etc. to meet the diverse needs of your projectand as it evolves over time and use. IMFs also provide graphical user interface prototypes fordrawing the flowsheet as in Figure 1 and typical Gantt charts and trend plots to view the solutionof quantity, logic and quality time-profiles. Current developments use Python 2.3 and 2.7integrated with open-source Dia and Matplotlib modules respectively but other prototypesembedded within Microsoft Excel/VBA for example can be created in a straightforward manner.However, the primary purpose of the IMFs is to provide a timely, cost-effective, manageableand maintainable deployment of IMPRESS to formulate and optimize complex industrialmanufacturing systems in either off-line or on-line environments. Using IMPRESS alone wouldbe somewhat similar (but not as bad) to learning the syntax and semantics of an AML as well ashaving to code all of the necessary mathematical representations of the problem including thedetails of digitizing your data into time-points and periods, demarcating past, present and futuretime-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 andfinally creating all of the necessary variables and constraints to model the complex details oflogistics and quality industrial optimization problems. Instead, IMFs and IMPRESS provide, inour opinion, a more elegant and structured approach to industrial modeling and solving so thatyou can capture the benefits of advanced decision-making faster, better and cheaper.
  4. 4. MIS-IMF Modeling DetailsAt this point it is prudent to elucidate more of the modeling details found in Figure 1. Withrespect to the production facility or plant, it is represented by a supply of raw materials A and Bwhich can be used to produce finished product C in a batch-process unit-operation labeledABC. 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 eithercontinuously or intermittently over the duration of the batch known as its cycle or processing-time. Finished products D and E are produced in a continuous-process unit-operation namedBDE requiring only B. Continuous-processes exhibit no or negligible holdup during theprocessing and as such simultaneously produce D and E the instant B is available where the fill-hold-draw profile collapses to a concurrent fill-draw with no hold of course. Because there aretwo flows in and one flow out for the batch-process, this type of process is also known asconvergent flow path. One flow in with two or more flows out is known oppositely as divergentflow path where both types are found often and together in the process industries as in ourexample. These types of processes can be modeled easily with IMPRESS given our use ofport-states.Port-states allow flow into and out of a unit-operation and can be considered as flow-interfacessimilar to ports on a computer i.e., nozzles, spouts, spigots. Port-states also provide anunambiguous description of the flowsheet or superstructure in terms of specifically what type ofmaterials or resources are being consumed and produced by the unit-operation. Port-statescan also represent utilities (steam, power), utensils (operators, tools) as well as signals such asdata, time, tasks, etc. Each of the three products C, D and E have tanks available for storageand is a requirement when balancing the production-side supply with the transportation-sidedemand 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 ultimatelycomposed of a network or graph of nodes/vertices and arcs/edges (directed).We now feature the industrial shipping details of the problem where the inverted triangle inFigure 1 indicates what we call a parcel unit-operation i.e., any vessel that moves material fromlocation to location on land or sea. SHIP1 can carry cargoes of C and D of variable sizeaccording to two routes and delivers these products to their respective CUSTOMER1 each withon-site storage tanks. The different routes can relate to different shipping channels (requiringdifferent amounts of travel or hauling-time) where the order or sequence of delivery (unloading)i.e., C then D or D then C, is fundamentally set by the release and due-dates of the customerorders. Usually the time-windows (difference between the release and due-dates) are three-days in length and is referred to as the laytime or laycan of the ship at the berth, jetty or wharf6.Deviations outside these time-windows may incur demurrage charges depending on the berthsutilization and can be setup as penalties in the optimization either on the quantity or the logicvariable for the corresponding time-period.One of the most important aspects of industrial shipping is the round-trip or return-trip time fromthe plant to one or more customers and then back to the plant to continue the cycle. During theloading (filling) at the plant then hauling (holding) or traveling to the customer(s) for unloading 6 A harbor or marine port will have one or more berths and may include single point/buoy mooring for verylarge ships (VLCCs) which will then require what is known as the operation of lightering. This will then requireberth-assignment details and a sub-shipping model to be configured to also manage the lightering ships (i.e., tugsand barges).
  5. 5. (drawing) there is obviously a dead-time where the ship must return back to the plant. Duringthis time the ship can neither load nor unload where it must not be engaged in any otheroperation, task or activity. The sum of all of these times; loading, hauling, unloading, returningis called the round-trip time and is surprisingly similar to the way a batch-process operates in aplant. Hence, the parcel unit-operation is modeled identical to a batch-process unit-operationexcept that the parcel unit-operation has one or more batch or cargo-sizes (as indicated by thematching inlet and outlet port-states in Figure 1) whereas the batch-process unit-operation hasonly one batch-size.SHIP2 also has two possible routes but ROUTE1 has two cargoes C and D going to theirrespective CUSTOMER1 and ROUTE2 adds cargo E destined for CUSTOMER1 but C and Dcargoes go to their respective CUSTOMER2. This is an example where the same physical shipcan have different routes with different cargoes going to different customers. SHIP3 also has adifferent arrangement of port-states or cargoes for each of its routes where ROUTE1 carries twocargoes each of C and E assigned to different customers. ROUTE2 is similar with two cargoeseach of D and E. The deliveries of material to CUSTOMER1 can be unloaded to a pool unit-operation or tank where CUSTOMER2 either has no inventory buffer or it is not known to thisproblem. For these types of demand points we have two uses or options we call contiguousand non-contiguous. Contiguous use is similar to a pipeline connection where the flows mustbe within lower and upper bounds for each time-period as specified by the demand order. Non-contiguous use relaxes this restriction by defining a release and due-date or time-window and aholdup lower and bound. In order to not incur an infeasibility, the solution must ensure thatwithin the time-periods defined by the time-interval the aggregated or summed flow (equal to theholdup) must be within bounds.MIS-IMF Solving DetailsOnce the flowsheet has been configured as in Figure 1, a *.UPS file (short for UOPSS) isconstructed 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 beincluded 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 ofthe UPS file is the application of "aliases". Aliases allow the capacity configuration of manyUOPSS objects simultaneously - see ALLPARTS, ALLINPORTS, ALLOUTPORTS andALLPATHS.TBDReferencesChristiansen, M., Fagerholt, Ronen, D., "Ship routing and scheduling: Status & Perspective",Transportation Science, 38, 1, (2004).Jetlund, A., Karimi, I.A., "Improving the logistics of multi-compartment chemical tankers",Computers & Chemical Engineering, 28, 1267, (2004).Kelly, J.D., "Production modeling for multimodal operations", Chemical Engineering Progress,February, 44, (2004).
  6. 6. Kelly, J.D., "The unit-operation-stock superstructure (UOSS) and the quantity-logic-qualityparadigm (QLQP) for production scheduling in the process industries", In: MISTA 2005Conference Proceedings, 327, (2005).Christiansen, M., Fagerholt, Nygreen, B., Ronen, D., "Maritime transportation", In: C. Barnhart &G. Laporte, Eds., Transportation. Handbook in Operation Research & Management Science,14, 189, (2007).Kelly, J.D., Zyngier, D., "An improved MILP modeling of sequence-dependent switchovers fordiscrete-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 LogisticsChallenges in the Enterprise", Springer, 61-95, (2009).Goel, V., Furman, K.C., Song, J-H, El-Bakry, A., "Large neighborhood search for LNG inventoryrouting", Journal of Heuristics, 18, 821, (2012).Maravelias, C.T., "On the combinatorial structure of discrete-time MIP formulations for chemicalproduction scheduling", Computers and Chemical Engineering, 38, 204, (2012).Appendix A - MIS-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,288!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Unit-Operation-Port-State-Superstructure (UOPSS) *.UPS File.! (This file is automatically generated from the Python program IAConstructer.py)!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!&sUnit,&sOperation,@sType,@sSubtype,@sUseA,,perimeter,,ABC,BATCH,processb,,B,,perimeter,,BDE,CONTINUOUS,processc,,C,,pool,,C_CUSTOMER1,C,perimeter,,C_CUSTOMER1,C,pool,,C_CUSTOMER2,C,perimeter,,D,,pool,,D_CUSTOMER1,D,perimeter,,D_CUSTOMER1,D,pool,,D_CUSTOMER2,D,perimeter,,E,,pool,,E_CUSTOMER1,E,pool,,E_CUSTOMER1,E,perimeter,,E_CUSTOMER2,E,perimeter,,SHIP1,ROUTE1,parcel,,SHIP1,ROUTE2,parcel,,SHIP2,ROUTE1,parcel,,SHIP2,ROUTE2,parcel,,SHIP3,ROUTE1,parcel,,SHIP3,ROUTE2,parcel,,&sUnit,&sOperation,@sType,@sSubtype,@sUse! Number of UO objects = 22&sAlias,&sUnit,&sOperationALLPARTS,A,ALLPARTS,ABC,BATCHALLPARTS,B,ALLPARTS,BDE,CONTINUOUSALLPARTS,C,ALLPARTS,C_CUSTOMER1,CALLPARTS,C_CUSTOMER1,CALLPARTS,C_CUSTOMER2,CALLPARTS,D,ALLPARTS,D_CUSTOMER1,DALLPARTS,D_CUSTOMER1,DALLPARTS,D_CUSTOMER2,DALLPARTS,E,
  7. 7. ALLPARTS,E_CUSTOMER1,EALLPARTS,E_CUSTOMER1,EALLPARTS,E_CUSTOMER2,EALLPARTS,SHIP1,ROUTE1ALLPARTS,SHIP1,ROUTE2ALLPARTS,SHIP2,ROUTE1ALLPARTS,SHIP2,ROUTE2ALLPARTS,SHIP3,ROUTE1ALLPARTS,SHIP3,ROUTE2&sAlias,&sUnit,&sOperation&sUnit,&sOperation,&sPort,&sState,@sType,@sSubtypeA,,A,,out,ABC,BATCH,A,,in,ABC,BATCH,B,,in,ABC,BATCH,C,,out,B,,B,,out,BDE,CONTINUOUS,B,,in,BDE,CONTINUOUS,D,,out,BDE,CONTINUOUS,E,,out,C,,C,,in,C,,C,,out,C_CUSTOMER1,C,C,,out,C_CUSTOMER1,C,C,,in,C_CUSTOMER1,C,C,,in,C_CUSTOMER2,C,C,,in,D,,D,,in,D,,D,,out,D_CUSTOMER1,D,D,,out,D_CUSTOMER1,D,D,,in,D_CUSTOMER1,D,D,,in,D_CUSTOMER2,D,D,,in,E,,E,,in,E,,E,,out,E_CUSTOMER1,E,E,,out,E_CUSTOMER1,E,E,,in,E_CUSTOMER1,E,E,,in,E_CUSTOMER2,E,E,,in,SHIP1,ROUTE1,C,,out,SHIP1,ROUTE1,C,,in,SHIP1,ROUTE1,D,,out,SHIP1,ROUTE1,D,,in,SHIP1,ROUTE2,C,,in,SHIP1,ROUTE2,C,,out,SHIP1,ROUTE2,D,,in,SHIP1,ROUTE2,D,,out,SHIP2,ROUTE1,C,,in,SHIP2,ROUTE1,C,,out,SHIP2,ROUTE1,D,,in,SHIP2,ROUTE1,D,,out,SHIP2,ROUTE2,C,,out,SHIP2,ROUTE2,C,,in,SHIP2,ROUTE2,D,,in,SHIP2,ROUTE2,D,,out,SHIP2,ROUTE2,E,,out,SHIP2,ROUTE2,E,,in,SHIP3,ROUTE1,C,,in,SHIP3,ROUTE1,C,,out,SHIP3,ROUTE1,C2,,in,SHIP3,ROUTE1,C2,,out,SHIP3,ROUTE1,E,,in,SHIP3,ROUTE1,E,,out,SHIP3,ROUTE1,E2,,in,SHIP3,ROUTE1,E2,,out,SHIP3,ROUTE2,D,,out,SHIP3,ROUTE2,D,,in,SHIP3,ROUTE2,D2,,out,SHIP3,ROUTE2,D2,,in,SHIP3,ROUTE2,E,,in,SHIP3,ROUTE2,E,,out,SHIP3,ROUTE2,E2,,out,SHIP3,ROUTE2,E2,,in,&sUnit,&sOperation,&sPort,&sState,@sType,@sSubtype! Number of UOPS objects = 60&sAlias,&sUnit,&sOperation,&sPort,&sStateALLINPORTS,ABC,BATCH,A,ALLINPORTS,ABC,BATCH,B,ALLINPORTS,BDE,CONTINUOUS,B,ALLINPORTS,C,,C,ALLINPORTS,C_CUSTOMER1,C,C,ALLINPORTS,C_CUSTOMER1,C,C,ALLINPORTS,C_CUSTOMER2,C,C,ALLINPORTS,D,,D,ALLINPORTS,D_CUSTOMER1,D,D,ALLINPORTS,D_CUSTOMER1,D,D,ALLINPORTS,D_CUSTOMER2,D,D,ALLINPORTS,E,,E,ALLINPORTS,E_CUSTOMER1,E,E,ALLINPORTS,E_CUSTOMER1,E,E,ALLINPORTS,E_CUSTOMER2,E,E,ALLINPORTS,SHIP1,ROUTE1,C,ALLINPORTS,SHIP1,ROUTE1,D,ALLINPORTS,SHIP1,ROUTE2,C,
  8. 8. ALLINPORTS,SHIP1,ROUTE2,D,ALLINPORTS,SHIP2,ROUTE1,C,ALLINPORTS,SHIP2,ROUTE1,D,ALLINPORTS,SHIP2,ROUTE2,C,ALLINPORTS,SHIP2,ROUTE2,D,ALLINPORTS,SHIP2,ROUTE2,E,ALLINPORTS,SHIP3,ROUTE1,C,ALLINPORTS,SHIP3,ROUTE1,C2,ALLINPORTS,SHIP3,ROUTE1,E,ALLINPORTS,SHIP3,ROUTE1,E2,ALLINPORTS,SHIP3,ROUTE2,D,ALLINPORTS,SHIP3,ROUTE2,D2,ALLINPORTS,SHIP3,ROUTE2,E,ALLINPORTS,SHIP3,ROUTE2,E2,ALLOUTPORTS,A,,A,ALLOUTPORTS,ABC,BATCH,C,ALLOUTPORTS,B,,B,ALLOUTPORTS,BDE,CONTINUOUS,D,ALLOUTPORTS,BDE,CONTINUOUS,E,ALLOUTPORTS,C,,C,ALLOUTPORTS,C_CUSTOMER1,C,C,ALLOUTPORTS,D,,D,ALLOUTPORTS,D_CUSTOMER1,D,D,ALLOUTPORTS,E,,E,ALLOUTPORTS,E_CUSTOMER1,E,E,ALLOUTPORTS,SHIP1,ROUTE1,C,ALLOUTPORTS,SHIP1,ROUTE1,D,ALLOUTPORTS,SHIP1,ROUTE2,C,ALLOUTPORTS,SHIP1,ROUTE2,D,ALLOUTPORTS,SHIP2,ROUTE1,C,ALLOUTPORTS,SHIP2,ROUTE1,D,ALLOUTPORTS,SHIP2,ROUTE2,C,ALLOUTPORTS,SHIP2,ROUTE2,D,ALLOUTPORTS,SHIP2,ROUTE2,E,ALLOUTPORTS,SHIP3,ROUTE1,C,ALLOUTPORTS,SHIP3,ROUTE1,C2,ALLOUTPORTS,SHIP3,ROUTE1,E,ALLOUTPORTS,SHIP3,ROUTE1,E2,ALLOUTPORTS,SHIP3,ROUTE2,D,ALLOUTPORTS,SHIP3,ROUTE2,D2,ALLOUTPORTS,SHIP3,ROUTE2,E,ALLOUTPORTS,SHIP3,ROUTE2,E2,&sAlias,&sUnit,&sOperation,&sPort,&sState&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sStateA,,A,,ABC,BATCH,A,ABC,BATCH,C,,C,,C,B,,B,,ABC,BATCH,B,B,,B,,BDE,CONTINUOUS,B,BDE,CONTINUOUS,D,,D,,D,BDE,CONTINUOUS,E,,E,,E,C,,C,,SHIP1,ROUTE1,C,C,,C,,SHIP1,ROUTE2,C,C,,C,,SHIP2,ROUTE1,C,C,,C,,SHIP2,ROUTE2,C,C,,C,,SHIP3,ROUTE1,C,C,,C,,SHIP3,ROUTE1,C2,C_CUSTOMER1,C,C,,C_CUSTOMER1,C,C,D,,D,,SHIP1,ROUTE1,D,D,,D,,SHIP1,ROUTE2,D,D,,D,,SHIP2,ROUTE1,D,D,,D,,SHIP2,ROUTE2,D,D,,D,,SHIP3,ROUTE2,D,D,,D,,SHIP3,ROUTE2,D2,D_CUSTOMER1,D,D,,D_CUSTOMER1,D,D,E,,E,,SHIP2,ROUTE2,E,E,,E,,SHIP3,ROUTE1,E,E,,E,,SHIP3,ROUTE1,E2,E,,E,,SHIP3,ROUTE2,E,E,,E,,SHIP3,ROUTE2,E2,E_CUSTOMER1,E,E,,E_CUSTOMER1,E,E,SHIP1,ROUTE1,C,,C_CUSTOMER1,C,C,SHIP1,ROUTE1,D,,D_CUSTOMER1,D,D,SHIP1,ROUTE2,C,,C_CUSTOMER1,C,C,SHIP1,ROUTE2,D,,D_CUSTOMER1,D,D,SHIP2,ROUTE1,C,,C_CUSTOMER1,C,C,SHIP2,ROUTE1,D,,D_CUSTOMER1,D,D,SHIP2,ROUTE2,C,,C_CUSTOMER2,C,C,SHIP2,ROUTE2,D,,D_CUSTOMER2,D,D,SHIP2,ROUTE2,E,,E_CUSTOMER1,E,E,SHIP3,ROUTE1,C,,C_CUSTOMER1,C,C,SHIP3,ROUTE1,C2,,C_CUSTOMER2,C,C,SHIP3,ROUTE1,E,,E_CUSTOMER1,E,E,SHIP3,ROUTE1,E2,,E_CUSTOMER2,E,E,SHIP3,ROUTE2,D,,D_CUSTOMER1,D,D,SHIP3,ROUTE2,D2,,D_CUSTOMER2,D,D,SHIP3,ROUTE2,E,,E_CUSTOMER1,E,E,SHIP3,ROUTE2,E2,,E_CUSTOMER2,E,E,&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState! Number of UOPSPSUO objects = 43&sAlias,&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sStateALLPATHS,A,,A,,ABC,BATCH,A,
  9. 9. ALLPATHS,B,,B,,ABC,BATCH,B,ALLPATHS,B,,B,,BDE,CONTINUOUS,B,ALLPATHS,ABC,BATCH,C,,C,,C,ALLPATHS,C_CUSTOMER1,C,C,,C_CUSTOMER1,C,C,ALLPATHS,SHIP1,ROUTE1,C,,C_CUSTOMER1,C,C,ALLPATHS,SHIP1,ROUTE2,C,,C_CUSTOMER1,C,C,ALLPATHS,SHIP2,ROUTE1,C,,C_CUSTOMER1,C,C,ALLPATHS,SHIP3,ROUTE1,C,,C_CUSTOMER1,C,C,ALLPATHS,SHIP2,ROUTE2,C,,C_CUSTOMER2,C,C,ALLPATHS,SHIP3,ROUTE1,C2,,C_CUSTOMER2,C,C,ALLPATHS,BDE,CONTINUOUS,D,,D,,D,ALLPATHS,D_CUSTOMER1,D,D,,D_CUSTOMER1,D,D,ALLPATHS,SHIP1,ROUTE1,D,,D_CUSTOMER1,D,D,ALLPATHS,SHIP1,ROUTE2,D,,D_CUSTOMER1,D,D,ALLPATHS,SHIP2,ROUTE1,D,,D_CUSTOMER1,D,D,ALLPATHS,SHIP3,ROUTE2,D,,D_CUSTOMER1,D,D,ALLPATHS,SHIP2,ROUTE2,D,,D_CUSTOMER2,D,D,ALLPATHS,SHIP3,ROUTE2,D2,,D_CUSTOMER2,D,D,ALLPATHS,BDE,CONTINUOUS,E,,E,,E,ALLPATHS,E_CUSTOMER1,E,E,,E_CUSTOMER1,E,E,ALLPATHS,SHIP2,ROUTE2,E,,E_CUSTOMER1,E,E,ALLPATHS,SHIP3,ROUTE1,E,,E_CUSTOMER1,E,E,ALLPATHS,SHIP3,ROUTE2,E,,E_CUSTOMER1,E,E,ALLPATHS,SHIP3,ROUTE1,E2,,E_CUSTOMER2,E,E,ALLPATHS,SHIP3,ROUTE2,E2,,E_CUSTOMER2,E,E,ALLPATHS,C,,C,,SHIP1,ROUTE1,C,ALLPATHS,D,,D,,SHIP1,ROUTE1,D,ALLPATHS,C,,C,,SHIP1,ROUTE2,C,ALLPATHS,D,,D,,SHIP1,ROUTE2,D,ALLPATHS,C,,C,,SHIP2,ROUTE1,C,ALLPATHS,D,,D,,SHIP2,ROUTE1,D,ALLPATHS,C,,C,,SHIP2,ROUTE2,C,ALLPATHS,D,,D,,SHIP2,ROUTE2,D,ALLPATHS,E,,E,,SHIP2,ROUTE2,E,ALLPATHS,C,,C,,SHIP3,ROUTE1,C,ALLPATHS,C,,C,,SHIP3,ROUTE1,C2,ALLPATHS,E,,E,,SHIP3,ROUTE1,E,ALLPATHS,E,,E,,SHIP3,ROUTE1,E2,ALLPATHS,D,,D,,SHIP3,ROUTE2,D,ALLPATHS,D,,D,,SHIP3,ROUTE2,D2,ALLPATHS,E,,E,,SHIP3,ROUTE2,E,ALLPATHS,E,,E,,SHIP3,ROUTE2,E2,&sAlias,&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState

×