Impl reference manual_for_quantities
Upcoming SlideShare
Loading in...5
×
 

Impl reference manual_for_quantities

on

  • 120 views

The IML file is our user readable import or input file to the IMPL modeling and solving platform. IMPL is an acronym for Industrial Modeling and Programming Language provided by Industrial Algorithms ...

The IML file is our user readable import or input file to the IMPL modeling and solving platform. IMPL is an acronym for Industrial Modeling and Programming Language provided by Industrial Algorithms LLC. The IML file allows the user to configure the necessary data to model and solve large-scale and complex industrial optimization problems (IOP's) such as planning, scheduling, control and data reconciliation and regression in either off or on-line environments.

The data configurable in the IML file are broken-down into several categories or classes where these data categories are used as further sections in this basic reference manual. This reference manual is specific only to the quantity dimension of what we refer to as the Quantity-Logic-Quality Phenomena (QLQP). The QLQP provides a useful phenomenological break-down of the problem complexity where the quantity dimension details quantities such as flows, rates, holdups and yields where the quantities can be related to any stock or signal including time. The other two dimensions are not the focus of this documentation but for completeness of the description, logic data have setups, startups, switchovers-to-itself, shutdowns and switchover-to-others (sequence-dependent transitions) and quality data have densities, components, properties and conditions. In addition to the QLQP , we also have what we call the Unit-Operation-Port-State Superstructure (UOPSS). This provides the flowsheet or topology of the IOP in terms of the various shapes, constructs or objects necessary to configure it. The UOPSS is more than a single network given that it is comprised of two networks we call the "physical" network and the "procedural" network. The physical network involves the units and ports (equipment, structural) and the procedural network involves the operations and states (activities, functional). The combination or cross-product of the two derives the "projectional" superstructure and it is these superstructure constructs or UOPSS keys that we apply, attach or associate specific QLQP attributes where projections are also known as hypothetical, logical or virtual constructs. Ultimately, when we augment the superstructure with the time or temporal dimension as well as including multiple sites or echelons i.e., sub-superstructures, we essentially are configuring what is known as a "hyperstructure".

Statistics

Views

Total Views
120
Views on SlideShare
118
Embed Views
2

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 2

http://www.steampdf.com 2

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Impl reference manual_for_quantities Impl reference manual_for_quantities Document Transcript

    •                         i  M  P  l     Industrial  Modeling  Language  (IML)     "(Basic)  Reference  Manual  for  Quantities"                       i  n  d  u  s  t  r  I  A  L  g  o  r  i  t  h  m  s    LLC.   www.industrialgorithms.com                 Version  1.0   April  2014   IAL-­‐IMPL-­‐IML-­‐RMQ-­‐1-­‐0.docx       Copyright  and  Property  of  Industrial  Algorithms  LLC.    
    • Introduction     The  IML  file  is  our  user  readable  import  or  input  file  to  the  IMPL  modeling  and  solving  platform.    IMPL  is   an  acronym  for  Industrial  Modeling  and  Programming  Language  provided  by  Industrial  Algorithms  LLC.     The  IML  file  allows  the  user  to  configure  the  necessary  data  to  model  and  solve  large-­‐scale  and  complex   industrial  optimization  problems  (IOP's)  such  as  planning,  scheduling,  control  and  data  reconciliation   and  regression  in  either  off  or  on-­‐line  environments.     The  data  configurable  in  the  IML  file  are  broken-­‐down  into  several  categories  or  classes  where  these   data  categories  are  used  as  further  sections  in  this  basic  reference  manual.    This  reference  manual  is   specific  only  to  the  quantity  dimension  of  what  we  refer  to  as  the  Quantity-­‐Logic-­‐Quality  Phenomena   (QLQP).    The  QLQP  provides  a  useful  phenomenological  break-­‐down  of  the  problem  complexity  where   the  quantity  dimension  details  quantities  such  as  flows,  rates,  holdups  and  yields  where  the  quantities   can  be  related  to  any  stock  or  signal  including  time.    The  other  two  dimensions  are  not  the  focus  of  this   documentation  but  for  completeness  of  the  description,  logic  data  have  setups,  startups,  switchovers-­‐ to-­‐itself,  shutdowns  and  switchover-­‐to-­‐others  (sequence-­‐dependent  transitions)  and  quality  data  have   densities,  components,  properties  and  conditions.    In  addition  to  the  QLQP  ,  we  also  have  what  we  call   the  Unit-­‐Operation-­‐Port-­‐State  Superstructure  (UOPSS).    This  provides  the  flowsheet  or  topology  of  the   IOP  in  terms  of  the  various  shapes,  constructs  or  objects  necessary  to  configure  it.    The  UOPSS  is  more   than  a  single  network  given  that  it  is  comprised  of  two  networks  we  call  the  "physical"  network  and  the   "procedural"  network.    The  physical  network  involves  the  units  and  ports  (equipment,  structural)  and   the  procedural  network  involves  the  operations  and  states  (activities,  functional).    The  combination  or   cross-­‐product  of  the  two  derives  the  "projectional"  superstructure  and  it  is  these  superstructure   constructs  or  UOPSS  keys  that  we  apply,  attach  or  associate  specific  QLQP  attributes  where  projections   are  also  known  as  hypothetical,  logical  or  virtual  constructs.    Ultimately,  when  we  augment  the   superstructure  with  the  time  or  temporal  dimension  as  well  as  including  multiple  sites  or  echelons  i.e.,   sub-­‐superstructures,  we  essentially  are  configuring  what  is  known  as  a  "hyperstructure".     How  we  specifically  apply  the  QLQP  attributes  to  these  UOPSS  keys  is  made  possible  by  our  concept  of   "frames".    Frames  are  similar  to  sheets  in  a  spreadsheet  where  a  frame  has  multiple  "features"  and   "fields"  in  a  particular  "format".    There  are  "feeder"  features  where  the  UOPSS/QLQP  data  is  contained   and  a  beginning  or  starting  "leader"  feature  and  a  corresponding  ending  or  finishing  "trailer"  feature.    
    • The  fields  are  separated  by  comma  delimiters  and  can  be  of  the  integer,  real  or  string  data  type.    The   data  sections  to  follow  detail  several  basic  frames  and  their  fields  necessary  to  configure  quantity-­‐only   types  of  IOP's.     The  symbol  "&"  denotes  an  address,  index,  pointer  or  key,  the  "@"  denotes  an  attribute,  property,   characteristic  or  value  and  the  prefix  "s"  stands  for  string  of  which  there  are  two  other  prefixes  "r"  and   "i"  for  reals  (double  precision)  and  integers  respectively.    String  addresses  and  attributes  are  case   sensitive  and  do  not  require  any  quotes  where  essentially  any  character  is  allowed  including  spaces   except  for    ",".    Each  address  string  field  may  have  no  more  than  64  characters  for  it  to  be  considered  as   unique  and  each  attribute  string  field  may  have  no  more  than  512  characters.     Cite  Data     IMPL  supports    the  ability  to  easily  configure  one  or  more  “sites”  within  the  same  problem  (Cite  Data).     When  IMPL  encounters  the  frame  below,  it  simply  prefixes  the  site  name  to  all  of  the  unit  names   encountered  until  the  next  site  name  is  found  thereby  changing  the  name-­‐space  of  the  current  sub-­‐ problem  within  the  overall  problem.    This  means  that  all  UOPSS  keys  are  explicitly  modified  by  the  site   name.      The  other  QLQP  set,  index  or  key  names,  essentially  the  quality  names,  are  not  modified  by  the   site  name  given  that  the  QLQP  sets  are  global  for  the  entire  problem  name-­‐space.     &sSite   SITE   &sSite     The  usefulness  of  this  approach  to  incrementally  configure  multiple  sites  or  sub-­‐problems  one  after  the   other  is  that  each  sub-­‐problem  can  be  solved  independently  (on  its  own)  from  which  troubleshooting   and  debugging  of  the  model  and  its  data  can  be  performed.    Then  of  course,  when  each  sub-­‐problem  is   properly  configured,  they  can  be  included  one-­‐by-­‐one  into  the  larger  problem’s  configuration  data.       In  the  future  this  same  approach  can  be  used  to  include  several  Case  Data  “scenarios”  (situations,   samples,  runs,  trials,  outcomes,  etc.)  one-­‐at-­‐a-­‐time  into  the  overall  problem  by  modifying  each   scenario’s  unit  name-­‐space  to  make  them  unique  within  the  entire  problem’s  configuration  data.     However,  scenarios  also  require  an  extra  attribute  relating  to  the  probability,  plausibility,  possibility,  
    • provability,  etc.  that  the  scenario  will  happen  or  exist.    And  thus,  the  one  overall  or  composite  solution,   considering  or  incorporating  all  weighted  scenarios,  will  be  a  robust  and/or  reliable  solution  to  the   problem  subject  to  varying  manifestations  or  realizations  of  some  level  or  amount  of  expected   uncertainty.     Calculation  Data     IMPL  allows  all  number  fields  (integer  and  real)  to  be  entered  as  mathematical  expressions.    Expressions   may  include  arithmetic  operators:  +,  -­‐,  *,    /  and  ^,  intrinsic  functions:  ABS,  SQRT,  LN,  LOG,  EXP,    SIN,  COS,   TAN,  DEG,  RAD,  FACT,    INT,  ROUND,  FLOOR,  CEILING  and  SIGN,  relational  functions:  MIN,  MAX,  IF,  NOT,     EQ,  NE,  LE,  LT,  GE  and  GT  and  special  functions:  MNL,  MXL  (n-­‐ary  minimum  and  maximum),  CIP,  LIP,  SIP   and  KIP  (constant,  linear,  monotonic  spline  and  constrained  spline  interpolation)  ,  URN,  NRN  (uniform   and  Normally  distributed  random  noise)  and  XFCN  (extrinsic  user-­‐coded  function).    The  "calc"  frame  can   be  added  anywhere  in  the  IML  file  as  long  as  the  "calc"  is  created  before  it  is  to  be  used  which  is  typical   of  a  dynamically-­‐typed  interpreted  language.     &sCalc,@sValue   CALC,EXPRESSION   &sCalc,@sValue     Concatenation  Data     IMPL  allows  any  number  of  include  files  to  be  specified  anywhere  in  the  IML  file  but  only  one  include  file   can  be  nested  or  embedded  within  another.     Include-@sFile_Name   DRIVE:DIRECTORY1DIRECTORY2FILENAME.EXT   Include-@sFile_Name     The  file  name  must  specify  the  drive,  directories  and  extension  delimited  by  either  "/"  or  "".    If  the   include  file  cannot  be  found  then  a  file  not  found  error  will  occur.     Chronological  (Calendar)  Data  
    •   IMPL  includes  two  time  models  called  "discrete-­‐time"  and  "distributed-­‐time"  for  all  future  events  and   only  discrete-­‐time  for  the  past/present  time-­‐horizon.    Discrete-­‐time  digitizes  or  divides  the  time-­‐horizon   into  time-­‐periods  of  equal  size  using  a  specified  time-­‐period  duration.    Distributed-­‐time  digitizes  or   distributes  the  future  time-­‐horizon  into  time-­‐periods  of  unequal  duration  where  the  time-­‐points  are   determined  by  finding  all  of  the  unique  or  distinct  time-­‐points  given  all  of  the  begin  and  end  event   timings  found  in  the  Command  Data.    Computing  all  of  the  discretized  or  distributed  time  data  is  what   we  call  our  "digitization  engine".       @rPastTHD,@rFutureTHD,@rTPD   PTHD,FTHD,TPD   @rPastTHD,@rFutureTHD,@rTPD     The  past  and  future  time-­‐horizon  durations  (PTHD,  FTHD)  are  both  set  as  positive  real  numbers   specifying  the  amount  of  time  where  past  and  future  events  can  be  contained.    The  time-­‐period   duration  (TPD)  is  also  a  positive  real  number  and  is  mandatory  for  at  least  the  past  time  horizon   discretization.    If  any  negative  real  numbers  are  specified  then  these  are  simply  converted  to  positive   numbers.    It  should  be  noted  that  further  referencing  of  time-­‐points  within  the  past/present  time-­‐ horizon  are  specified  as  negative  numbers  given  that  our  overall  timeline  extends  from  -­‐PTHD  to  FTHD   inclusively.     Construction  Data     As  mentioned,  IMPL  is  based  on  our  UOPSS  shapes  which  allow  the  user  the  ability  to  construct  or   configure  the  flowsheet  in  any  arrangement  necessary.    The  first  frame  specifies  the  unit  and  operation   names  with  its  corresponding  type,  subtype  and  use  enumerations.       &sUnit,&sOperation,@sType,@sSubtype,@sUse   UNIT,OPERATION,TYPE,SUBTYPE,USE   &sUnit,&sOperation,@sType,@sSubtype,@sUse     The  types  are  applied  to  the  physical  unit  only  and  are  "perimeter",  "pool",  "processb",  "processc",   "processd",  "parcel",  "pipeline"  and  "pileline"  where  processes  are  classed  into  batch  ("b"),  continuous   ("c")  and  dimensional    ("d").    The  subtypes  are  only  applied  to  processc's  and  they  are  "blender",  
    • "splicer",  "selector",  "splitter",  "separator",  "reactor",  "fractionator",  "blackbox",  "blackblox"  and   "blankbox".    For  the  other  two  processes  the  implied  subtype  is  blackbox  only.    If  the  types  or  subtypes   for  processes  prefix  or  suffix  a  "%"  in  their  string  then  an  overall  quantity  balance  will  be  configured  i.e.,   the  sum  of  all  flows  in  must  equal  the  sum  of  all  the  flows  outs.     For  quantity  problems,  subtypes  are  implied  to  be  blackboxes  which  represent  what  are  known  as  input-­‐ output  or  Leontief  process  models.    These  kinds  of  processes  simply  state  that  the  flow  in  to  or  out  of  a   port-­‐state  on  a  unit-­‐operation  is  determined  by  multiplying  the  characteristic  batch-­‐size  or  charge-­‐size   (lot-­‐size)  of  the  process  unit-­‐operation  by  the  port-­‐state  "yield".    The  other  two  subtypes  that  may  be   used  in  quantity  problems  are  the  splicer  and  selector.    The  splicers  provide  the  ability  to  add  and   subtract  flows  through  the  process  unit-­‐operation  similar  in  signal  flow  processes  such  as  adders  or   subtractors  by  configuring  positive  and  negative  yields.    Selectors  are  also  signal  flow  processing   constructs  and  will  "select"  the  maximum  or  largest  flow  into  a  process  unit-­‐operation  amongst  two  or   more  in-­‐port-­‐states.    It  essentially  assumes  that  there  are  no  lower  yield  bound  inequalities  and  that  the   upper  yield  values  are  unity  or  one  (1).         The  uses  "contiguous"  (default)  and  "noncontiguous"  are  applied  to  perimeters  only  and  "contentious"   (default)  and  "noncontentious"  are  for  processc's  only.    The  word  noncontiguous  means  that  given  a   specified  release  and  due-­‐date,  the  quantity  of  substance  flowing  in  or  out  must  be  satisfied  within  the   time-­‐window,  interval  or  span  although  continuous,  consecutive  or  contiguous  flow  is  not  implied.    The   term  noncontentious  implies  that  scheduling  of  the  physical  unit  is  not  required  in  the  sense  of  allowing   only  one  procedural  operation  to  occur  in  any  one  time-­‐period  but  planning  of  it  is  necessary  in  terms   what  portion  of  time  within  a  time-­‐period  it  will  be  operated  in  for  a  given  operation.    These  planning   and  scheduling  time-­‐period  uses  or  disciplines  mentioned  are  also  known  as  "big"  and  "small"  time-­‐ buckets  in  the  Operations  Research  literature.         The  second  frame  specifies  the  unit,  operation,  port  and  state  names  with  corresponding  type  and   subtype  enumerations.    Any  number  of  port-­‐states  can  be  attached  to  a  unit-­‐operation  as  long  as  the   port-­‐state  pair  is  unique  irrespective  of  whether  it  is  an  in  or  out  port  type.     &sUnit,&sOperation,&sPort,&sState,@sType,@sSubtype   UNIT,OPERATION,PORT,STATE,TYPE,SUBTYPE   &sUnit,&sOperation,&sPort,&sState,@sType,@sSubtype  
    •   The  types  are  actually  applied  to  the  physical  port  only  and  are  simply  "in"  and  "out".    The  subtypes  are   "stock",  "utility",  "utensil",  "signal",  "task"  and  "time"  where  the  subtypes  other  than  stock  are  really   only  considered  as  "nonstock"  port-­‐states.    Stock  port-­‐states  can  be  included  in  overall  quantity   balances  on  processes  (as  indicated  by  "%"  in  its  unit  type  and  subtype)  however  nonstock  port-­‐states   are  never  included  (i.e.,  always  excluded).      There  are  simple  construction  restrictions  relating  to   attaching  port-­‐states  to  unit-­‐operations  for  specific  unit  types  and  subtypes  and  they  are  as  follows:     1)  "perimeter"'s  can  have  any  number  of  in-­‐port-­‐states  and  out-­‐port-­‐states  but  not  both.   2)  "pool"'s,  "pipeline"'s  and  "pileline"'s  can  only  have  only  one  in-­‐port-­‐state  and  only  one  out-­‐port-­‐state.   3)  "processb"'s,  "processc"'s  and  "processd"'s  can  have  any  number  of  in-­‐port-­‐states  and  out-­‐port-­‐ states.       a)  "blender"'s,  "splicer"'s  and  "selector"'s  can  have  any  number  of  in-­‐port-­‐states  but  only  one   out-­‐port-­‐state.     b)  "splitter"'s,"separator"'s  and  "fractionator"'s  can  have  any  number  of  out-­‐port-­‐states  but  only   one  in-­‐port-­‐state.     c)  "reactor"'s,  "blackbox"'s,  "blackblox"'s  and  "blankbox"'s  can  have  any  number  of  in-­‐port-­‐ states  and  out-­‐port-­‐states.       The  third  frame  specifies  the  upstream  (from)  unit,  operation,  port,  state  names  to  any  downstream  (to)   unit,  operation,  port,  state  names  and  these  connections,  arcs,  links,  routes,  streams  or  paths  have  no   types  or  subtypes.     &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState   UNIT,OPERATION,PORT,STATE,  UNIT2,OPERATION2,PORT2,STATE2   &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState     The  paths  have  a  single  configuration  restriction  where  they  must  be  connected  from  an  out-­‐port-­‐state   to  an  in-­‐port-­‐state  only  else  an  error  will  occur.     Convenience  Data    
    • IMPL  allows  the  user,  for  convenience  purposes,  the  ability  to  configure  an  "alias"  where  the  same  alias   can  be  assigned  to  one  or  more  unit-­‐operation  names.    Aliases  are  substitute  names  for  the  UOPSS  keys   and  allows  the  user  to  specify  Capacity  Data  for  the  alias  whereby  IMPL  will  propagate  those  data   entries  to  or  across  all  of  the  UOPSS  keys  configured  for  that  alias.     &sAlias,&sUnit,&sOperation   ALIAS,UNIT,OPERATION   ALIAS,UNIT2,OPERATION2   &sAlias,&sUnit,&sOperation     Each  alias  must  be  defined  consecutively  or  contiguously  which  means  that  if  a  previous  alias  is  found   somewhere  after  it  has  been  completely  configured  or  populated  an  error  will  occur.             Two  other  aliases  are  available  for  the  unit-­‐operation-­‐port-­‐states  and  the  unit-­‐operation-­‐port-­‐state-­‐unit-­‐ operation-­‐port-­‐states  projections.     &sAlias,&sUnit,&sOperation,&sPort,&sState   ALIAS,UNIT,OPERATION,PORT,STATE   ALIAS,UNIT2,OPERATION2,PORT2,STATE2   &sAlias,&sUnit,&sOperation,&sPort,&sState     &sAlias,&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState   ALIAS,UNIT,OPERATION,PORT,STATE,  UNIT2,OPERATION2,PORT2,STATE2   ALIAS,UNIT3,OPERATION3,PORT3,STATE3,  UNIT4,OPERATION4,PORT4,STATE4   &sAlias,&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState     Capacity  Data     In  accordance  with  the  QLQP,  IMPL  allows  quantity  Capacity  Data  to  be  configured  with  each  UOPSS   shape  in  the  form  of  a  flowrate,  holdup  and  yield.    Internally  IMPL  will  convert  the  flowrate  to  a  flow  per   time-­‐period  by  simply  multiplying  the  flowrate  by  the  time  duration  of  each  time-­‐period.    We  configure   flowrate  instead  of  flow  per  time-­‐period  explicitly  in  order  to  have  more  generality  of  the  input  data   when  the  time-­‐period  duration  is  parametric  i.e.,  is  changed  exogenously  by  the  user.    Except  for   perimeters,  each  unit-­‐operation  projection  has  either  a  flowrate  or  a  holdup.    Pools,  batch-­‐processes,   parcels  and  pilelines  have  holdup  where  continuous  and  dimensional  processes  have  flowrates  and   pipelines  have  both.      These  flows  and  holdups  through  or  on  unit-­‐operations  are  also  referred  to  as  lot-­‐ size,  batch-­‐size,  charge-­‐size,  throughput,  etc.  
    •   &sUnit,&sOperation,@rRate_Lower,@rRate_Upper   UNIT,OPERATION,LRATE,URATE   &sUnit,&sOperation,@rRate_Lower,@rRate_Upper     &sUnit,&sOperation,@rHoldup_Lower,@rHoldup_Upper   UNIT,OPERATION,LHOLDUP,UHOLDUP   &sUnit,&sOperation,@rHoldup_Lower,@rHoldup_Upper     Each  port-­‐state  attached  to  a  unit-­‐operation  has  two  flowrates  called  the  "tee"  and  "total"  flows.    The   total  flows  are  the  total  flow  of  substance  flowing  through  the  port-­‐state  and  tee  flows  are  the   individual  or  separate  flows  moving  into  an  in-­‐port-­‐state  (from  an  out-­‐port-­‐state)  or  out  of  an  out-­‐port-­‐ state  (from  an  in-­‐port-­‐state).    Specific  path  connection  flowrates  can  be  further  configured  in  the   Command  Data  which  will  override  or  overload  the  tee  flowrates.     &sUnit,&sOperation,&sPort,&sState,@rTeeRate_Lower,@rTeeRate_Upper   UNIT,OPERATION,PORT,STATE,LTEERATE,UTEERATE   &sUnit,&sOperation,&sPort,&sState,@rTeeRate_Lower,@rTeeRate_Upper     &sUnit,&sOperation,&sPort,&sState,@rTotalRate_Lower,@rTotalRate_Upper   UNIT,OPERATION,PORT,STATE,LTOTALRATE,UTOTALRATE   &sUnit,&sOperation,&sPort,&sState,@rTotalRate_Lower,@rTotalRate_Upper     Given  our  input-­‐output  or  Leontief  quantity  modeling  of  unit-­‐operation  processes,  it  is  also  necessary  to   configure  "yields".    Yields  (coefficients,  intensities,  ratios,  etc.)  are  intensive  quantities  where  flows  and   holdups  are  extensive  because  they  vary  with  the  size  of  the  system.    Yields  on  the  other  hand  do  not   and  represent  a  ratio  of  the  total  flow  in  or  out  on  a  port-­‐state  divided  by  the  flow  or  holdup  of  the   process  unit-­‐operation.       &sUnit,&sOperation,&sPort,&sState,@rYield_Lower,@rYield_Upper,@rYield_Fixed   UNIT,OPERATION,PORT,STATE,LYIELD,UYIELD,FYIELD   &sUnit,&sOperation,&sPort,&sState,@rYield_Lower,@rYield_Upper,@rYield_Fixed     The  "fixed"  yield  is  applied  to  the  "setup"  of  unit-­‐operation  and  is  similar  to  that  found  in  fixed-­‐charge   network  flow  problems.    Setup's  are  logic  or  binary  variables  that  have  the  value  of  zero  (0)  if  the  unit-­‐ operation  is  not  setup  for  the  time-­‐period  and  is  one  (1)  is  it  is  setup.    For  batch-­‐processes  the  fixed  yield   is  applied  to  its  startup.    Details  on  setup's  and  startup's  as  well  as  other  relevant  logic  variables  can  be   found  in  Kelly  and  Zyngier,"An  improved  modeling  of  sequence-­‐dependent  switch-­‐overs  for  discrete-­‐ time  scheduling  problems",  I&ER,  46,  (2007).  
    •   Cost  Data     IMPL  optimizes  a  total  objective  function  which  is  maximized  and  contains  four  terms  called  "profit",   "performance1",  "performance2"  and  "penalty".    The  profit  term  is  a  sum  across  all  flows  and  holdups   times  their  respective  profit-­‐weight  and  summing  across  all  time-­‐periods.    Costs  are  configured  as   negative  profit-­‐weights  and  prices  are  specified  as  positive.    The  two  mutually  exclusive  performance   terms  are  used  to  minimize  "deviation"  variables  from  its  soft  target  bound  in  either  a  1-­‐norm  (absolute)   or  2-­‐norm  (squared)  sense  and  should  be  entered  as  positive  numbers.    The  1-­‐norm  performance   requires  an  LP  whereas  the  2-­‐norm  requires  a  QP.    Only  if  a  non-­‐zero  performance-­‐weight  exists  will  the   target  deviations  be  minimized  even  if  a  target  exists.    Positive  penalty-­‐weights  can  also  be  specified   where  "excursion"  variables  from  either  its  hard  lower  or  upper  bound  (artificial,  elastic  variables,  safety   valves,  infeasibility-­‐breakers,  etc.)  will  be  minimized.    Only  if  a  non-­‐zero  penalty-­‐weight  exists  will  the   lower  and  upper  excursion  variables  be  generated.    It  is  recommended  that  only  if  the  solving-­‐system  is   hard  infeasible  should  penalty-­‐weights  be  configured.           &sUnit,&sOperation,     @rFlowPro_Weight,@rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight   UNIT,OPERATION,WFPRO,WFPER1,WFPER2,  WFPEN   &sUnit,&sOperation,     @rFlowPro_Weight,@rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight     &sUnit,&sOperation, @rHoldupPro_Weight,@rHoldupPer1_Weight,@rHoldupPer2_Weight,@rHoldupPen_Weight UNIT,OPERATION,WHPRO,WHPER1,WHPER2,  WHPEN   &sUnit,&sOperation, @rHoldupPro_Weight,@rHoldupPer1_Weight,@rHoldupPer2_Weight,@rHoldupPen_Weight   &sUnit,&sOperation,&sPort,&sState,     @rFlowPro_Weight,@rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight   UNIT,OPERATION,PORT,STATE,WFPRO,WFPER1,WFPER2,  WFPEN   &sUnit,&sOperation,&sPort,&sState,     @rFlowPro_Weight,@rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight     &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState,     @rFlowPro_Weight,@rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight   UNIT,OPERATION,PORT,STATE,  UNIT2,OPERATION2,PORT2,STATE2,WFPRO,WFPER1,WFPER2,  WFPEN   &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState,     @rFlowPro_Weight,@rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight    
    • Content  (Current)  Data     IMPL  has  two  time-­‐horizons  one  for  the  past/present  data  set  in  negative  time  and  the  other  for  future   data  specified  in  positive  time.    To  configure  events  that  have  occurred  in  the  past/present  and  may   continue  into  the  future  time-­‐horizon  we  use  a  "start"  time  to  set  when  a  unit-­‐operation  has  started  in   the  past/present  as  well  as  its  value  is  specified.    The  start  time  should  be  specified  as  a  negative   number  and  we  do  not  require  a  "finish"  time  given  that  if  the  activity  has  finished  before  the  beginning   of  the  future  time-­‐horizon  then  this  data  is  irrelevant  to  the  future  decision-­‐making.    The  management   of  the  past/present  and  future  timelines  or  horizons  is  what  we  call  our  "demarcation  engine"  and  in   specialty  chemicals  and  batch  processing  this  is  commonly  referred  to  as  managing  the  "wet  plant"   problem  or  initial/starting  conditions.     &sUnit,&sOperation,@rRate_Value,@rStart_Time   UNIT,OPERATION,VRATE,START   &sUnit,&sOperation,@rRate_Value,@rStart_Time     &sUnit,&sOperation,@rHoldup_Value,@rStart_Time   UNIT,OPERATION,VHOLDUP,START   &sUnit,&sOperation,@rHoldup_Value,@rStart_Time     &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState,     @rRate_Value,@rStart_Time   UNIT,OPERATION,PORT,STATE,UNIT2,OPERATION2,PORT2,STATE2,VRATE,START   &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState,     @rRate_Value,@rStart_Time     Command  (Control)  Data     A  unique  aspect  or  feature  of  IMPL  is  that  it  allows  all  lower,  upper  and  target  bounds  to  be  exogenously   time-­‐varying  i.e.,  they  are  indexed  by  a  time-­‐period.    This  affords  us  the  ability  to  control  or  manipulate   the  future  time-­‐horizon  for  any  variable  configured  by  IMPL.    Each  lower,  upper  and/or  target  triple   (tuple)  has  a  begin  and  end  time  which  usually  occurs  at  some  time  within  the  future  time-­‐horizon   although  transaction,  activity,  event,  order  or  command  timing  that  exceed  the  future  time-­‐horizon  are   simply  ignored  in  the  digitization  engine.    For  each  command,  the  digitization  engine  cumulatively  sums   over  all  of  the  digitized  time-­‐periods  contained  within  its  begin  and  end-­‐time.    Hence,  any  commands  
    • overlapping  in  continuous-­‐time  and  thus  overlapping  in  digitized-­‐time  will  have  their  digitized  quantities   summed  together.     For  logic  data  such  as  setups  and  startups  there  are  no  target  data  required.    For  a  quantity  only   problem,  the  two  logic  data  frames  below  must  specify  for  each  unit-­‐operation  projection  and  unit-­‐ operation-­‐port-­‐state-­‐unit-­‐operation-­‐port-­‐state  path  fixed  logic  data  i.e.,  the  lower  and  upper  bounds   must  be  equal  to  either  zero  (0)  or  one  (1).    It  should  be  noted  that  for  logistics  problems,  which  are   usually  solved  using  mixed-­‐integer  linear  programming  (MILP),  the  lower  and  upper  bounds  can  be   different  i.e.,  lower  bound  equals  zero  (0)  and  upper  bound  equals  (1).      If  any  UOPSS  shape's  or   construct's  setup  logic    is  not  configured  then  its  lower  and  upper  bound  are  defaulted  to  zero  (0).     &sUnit,&sOperation,@rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time   UNIT,OPERATION,LSETUP,USETUP,BEGIN,END   &sUnit,&sOperation,@rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time     &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState,     @rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time   UNIT,OPERATION,PORT,STATE,  UNIT2,OPERATION2,PORT2,STATE2,LSETUP,USETUP,BEGIN,END   &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState,     @rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time     The  remaining  frames  configure  their  respective  flows  and  holdups  where  if  the  target  field  is  left  blank   then  it  is  assumed  to  equal  what  we  refer  to  as  our  "non-­‐naturally  occurring  number"  (NNON).    This   special  number  usually  represented  by  "-­‐99999"  (a  negative  number  with  many  nines)  is  commonly  used   in  other  fields  such  as  multivariate  statistics  to  represent  a  missing  data  or  missing  values.    If  a  non-­‐zero   performance  weight  is  specified  but  the  target  is  NNON,  then  the  target  will  not  be  respected  as  a  soft   bound  in  the  optimization  i.e.,  for  that  those  time-­‐periods  where  it  is  NNON  no  deviation  variables  will   be  generated.     &sUnit,&sOperation,@rRate_Lower,@rRate_Upper,@rRate_Target,@rBegin_Time,@rEnd_Time   UNIT,OPERATION,LRATE,URATE,TRATE,BEGIN,END   &sUnit,&sOperation,@rRate_Lower,@rRate_Upper,@rRate_Target,@rBegin_Time,@rEnd_Time     &sUnit,&sOperation,     @rHoldup_Lower,@rHoldup_Upper,@rHoldup_Target,@rBegin_Time,@rEnd_Time   UNIT,OPERATION,LHOLDUP,UHOLDUP,THOLDUP,BEGIN,END   &sUnit,&sOperation,     @rHoldup_Lower,@rHoldup_Upper,@rHoldup_Target,@rBegin_Time,@rEnd_Time    
    • &sUnit,&sOperation,&sPort,&sState,     @rTotalRate_Lower,@rTotalRate_Upper,@rTotalRate_Target,@rBegin_Time,@rEnd_Time   UNIT,OPERATION,PORT,STATE,LRATE,URATE,TRATE,BEGIN,END   &sUnit,&sOperation,&sPort,&sState,     @rTotalRate_Lower,@rTotalRate_Upper,@rTotalRate_Target,@rBegin_Time,@rEnd_Time     &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState,     @rRate_Lower,@rRate_Upper,@rRate_Target,@rBegin_Time,@rEnd_Time   UNIT,OPERATION,PORT,STATE,  UNIT2,OPERATION2,PORT2,STATE2,LRATE,URATE,TRATE,BEGIN,END   &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState,     @rRate_Lower,@rRate_Upper,@rRate_Target,@rBegin_Time,@rEnd_Time     In  addition,  IMPL  also  supports  the  configuration  of  selected  weight-­‐orders  which  can  vary  the  pricing   over  time  i.e.,  time-­‐varying  weights.       &sUnit,&sOperation,&sPort,&sState,@rFlowPro_Weight, @rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight,@rBegin_Time,@rEnd_Time   UNIT,OPERATION,PORT,STATE,WFPRO,WFPER1,WFPER2,  WFPEN,BEGIN,END   &sUnit,&sOperation,&sPort,&sState,@rFlowPro_Weight, @rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight,@rBegin_Time,@rEnd_Time     Configuration  Demo  (AON  PERT/CPM  Optimization  Problem)     The  Configuration  Demo  provided  below  is  a  small  activity-­‐on-­‐node  (AON)  project/program  evaluation   review  technique  (PERT)  and  also  known  as  the  critical  path  method  (CPM)  as  shown  in  Figure  1.0.    The   flows  are  actually  flows  of  time  (signals)  and  there  are  ten  (10)  activities  configured  as  processc's  where   the  unit  names  range  from  "A"  to  "J"  and  each  activity's  integer  time  duration  is  used  as  its  operation   name.    There  are  two  (2)  dummy  nodes  called  "BEGIN"  and  "END"  which  represent  the  typical  source   and  sink  nodes.    There  are  also  three  (3)  selector  processes  where  their  names  "CF",  "DI"  and  "EHJ"   indicate  the  in-­‐port-­‐state  streams  that  will  be  selected  from  to  find  the  largest  or  maximum  flow  of  time   into  the  selectors  and  these  times  will  of  course  flow  out  of  its  out-­‐port-­‐state  to  some  connected   downstream  in-­‐port-­‐state  on  another  unit-­‐operation.     The  objective  or  goal  of  the  problem  is  to  minimize  the  total  time  required  to  complete  the  network  of   activities  or  tasks  and  this  is  configured  as  a  minimizing  the  flow  of  time  to  the  "END"  sink  unit-­‐operation   node;  the  minimum  completion  or  makespan  time  possible  is  194  time-­‐units.    It  is  configured  with  a   profit-­‐weight  of  -­‐1.0  which  indicates  that  it  is  a  cost.    The  other  interesting  configuration  aspect  of  our   AON  PERT/CPM  problem  in  IMPL  is  that  the  duration  of  time  for  each  activity  is  modeled  using  the  
    • "fixed"  yield  field  in  the  Capacity  Data.    This  will  add  the  variable  amount  of  time  coming  into  the  activity   unit-­‐operation  node  and  then  it  will  be  added  by  its  duration  contained  in  the  fixed  yield.    For  example,   if  the  time  into  the  node  is  101  and  the  time  duration  is  20  then  the  flow  of  time  out  will  be  101  +  20  =   121  time-­‐units  where  the  101  is  the  variable  part  of  the  yield.       Figure  1.0  Flowsheet  of  AON  PERT/CPM  Optimization  Problem.     i M P l (c) Copyright and Property of i n d u s t r I A L g o r i t h m s LLC. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Calculation Data (Parameters) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sCalc,@sValue START,-1.0 BEGIN,0.0 END,1.0 PERIOD,1.0 MINMAX,-1 &sCalc,@sValue !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Chronological Data (Periods) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! @rPastTHD,@rFutureTHD,@rTPD START,END,PERIOD @rPastTHD,@rFutureTHD,@rTPD !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Construction Data (Pointers) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sUnit,&sOperation,@sType,@sSubtype,@sUse A,90,processc,, B,15,processc,, BEGIN,,perimeter,, C,5,processc,, CF,0,processc,selector, D,20,processc,, DI,0,processc,selector, E,21,processc,, EHJ,0,processc,selector,
    • END,,perimeter,, F,25,processc,, G,14,processc,, H,28,processc,, I,30,processc,, J,45,processc,, &sUnit,&sOperation,@sType,@sSubtype,@sUse &sUnit,&sOperation,&sPort,&sState,@sType,@sSubtype A,90,IN,,in, A,90,OUT1,,out, A,90,OUT2,,out, A,90,OUT3,,out, B,15,IN,,in, B,15,OUT,,out, BEGIN,,OUT,,out, C,5,IN,,in, C,5,OUT,,out, CF,0,IN,1,in, CF,0,IN,2,in, CF,0,OUT,,out, D,20,IN,,in, D,20,OUT1,,out, D,20,OUT2,,out, D,20,OUT3,,out, DI,0,IN,1,in, DI,0,IN,2,in, DI,0,OUT,,out, E,21,IN,,in, E,21,OUT,,out, EHJ,0,IN,1,in, EHJ,0,IN,2,in, EHJ,0,IN,3,in, EHJ,0,OUT,,out, END,,IN,,in, F,25,IN,,in, F,25,OUT,,out, G,14,IN,,in, G,14,OUT,,out, H,28,IN,,in, H,28,OUT,,out, I,30,IN,,in, I,30,OUT,,out, J,45,IN,,in, J,45,OUT,,out, &sUnit,&sOperation,&sPort,&sState,@sType,@sSubtype &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState A,90,OUT1,,B,15,IN, A,90,OUT2,,F,25,IN, A,90,OUT3,,I,30,IN, B,15,OUT,,C,5,IN, BEGIN,,OUT,,A,90,IN, C,5,OUT,,CF,0,IN,1 CF,0,OUT,,G,14,IN, D,20,OUT1,,E,21,IN, D,20,OUT2,,H,28,IN, D,20,OUT3,,DI,0,IN,1 DI,0,OUT,,J,45,IN, E,21,OUT,,EHJ,0,IN,1 EHJ,0,OUT,,END,,IN, F,25,OUT,,CF,0,IN,2 G,14,OUT,,D,20,IN,
    • H,28,OUT,,EHJ,0,IN,2 I,30,OUT,,DI,0,IN,2 J,45,OUT,,EHJ,0,IN,3 &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Convenience Data (Pointers) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sAlias,&sUnit,&sOperation ALLPARTS,A,90 ALLPARTS,B,15 ALLPARTS,BEGIN, ALLPARTS,C,5 ALLPARTS,CF,0 ALLPARTS,D,20 ALLPARTS,DI,0 ALLPARTS,E,21 ALLPARTS,EHJ,0 ALLPARTS,END, ALLPARTS,F,25 ALLPARTS,G,14 ALLPARTS,H,28 ALLPARTS,I,30 ALLPARTS,J,45 &sAlias,&sUnit,&sOperation &sAlias,&sUnit,&sOperation,&sPort,&sState ALLINPORTS,A,90,IN, ALLINPORTS,B,15,IN, ALLINPORTS,C,5,IN, ALLINPORTS,CF,0,IN,1 ALLINPORTS,CF,0,IN,2 ALLINPORTS,D,20,IN, ALLINPORTS,DI,0,IN,1 ALLINPORTS,DI,0,IN,2 ALLINPORTS,E,21,IN, ALLINPORTS,EHJ,0,IN,1 ALLINPORTS,EHJ,0,IN,2 ALLINPORTS,EHJ,0,IN,3 ALLINPORTS,END,,IN, ALLINPORTS,F,25,IN, ALLINPORTS,G,14,IN, ALLINPORTS,H,28,IN, ALLINPORTS,I,30,IN, ALLINPORTS,J,45,IN, ALLOUTPORTS,A,90,OUT1, ALLOUTPORTS,A,90,OUT2, ALLOUTPORTS,A,90,OUT3, ALLOUTPORTS,B,15,OUT, ALLOUTPORTS,BEGIN,,OUT, ALLOUTPORTS,C,5,OUT, ALLOUTPORTS,CF,0,OUT, ALLOUTPORTS,D,20,OUT1, ALLOUTPORTS,D,20,OUT2, ALLOUTPORTS,D,20,OUT3, ALLOUTPORTS,DI,0,OUT, ALLOUTPORTS,E,21,OUT, ALLOUTPORTS,EHJ,0,OUT, ALLOUTPORTS,F,25,OUT, ALLOUTPORTS,G,14,OUT, ALLOUTPORTS,H,28,OUT, ALLOUTPORTS,I,30,OUT,
    • ALLOUTPORTS,J,45,OUT, &sAlias,&sUnit,&sOperation,&sPort,&sState &sAlias,&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState ALLPATHS,BEGIN,,OUT,,A,90,IN, ALLPATHS,A,90,OUT1,,B,15,IN, ALLPATHS,B,15,OUT,,C,5,IN, ALLPATHS,C,5,OUT,,CF,0,IN,1 ALLPATHS,F,25,OUT,,CF,0,IN,2 ALLPATHS,G,14,OUT,,D,20,IN, ALLPATHS,D,20,OUT3,,DI,0,IN,1 ALLPATHS,I,30,OUT,,DI,0,IN,2 ALLPATHS,D,20,OUT1,,E,21,IN, ALLPATHS,E,21,OUT,,EHJ,0,IN,1 ALLPATHS,H,28,OUT,,EHJ,0,IN,2 ALLPATHS,J,45,OUT,,EHJ,0,IN,3 ALLPATHS,EHJ,0,OUT,,END,,IN, ALLPATHS,A,90,OUT2,,F,25,IN, ALLPATHS,CF,0,OUT,,G,14,IN, ALLPATHS,D,20,OUT2,,H,28,IN, ALLPATHS,A,90,OUT3,,I,30,IN, ALLPATHS,DI,0,OUT,,J,45,IN, &sAlias,&sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Capacity Data (Prototypes) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sUnit,&sOperation,@rRate_Lower,@rRate_Upper ALLPARTS,0.0,1000.0 &sUnit,&sOperation,@rRate_Lower,@rRate_Upper &sUnit,&sOperation,&sPort,&sState,@rTeeRate_Lower,@rTeeRate_Upper ALLINPORTS,0.0,1000.0 ALLOUTPORTS,0.0,1000.0 &sUnit,&sOperation,&sPort,&sState,@rTeeRate_Lower,@rTeeRate_Upper &sUnit,&sOperation,&sPort,&sState,@rTotalRate_Lower,@rTotalRate_Upper ALLINPORTS,0.0,1000.0 ALLOUTPORTS,0.0,1000.0 &sUnit,&sOperation,&sPort,&sState,@rTotalRate_Lower,@rTotalRate_Upper &sUnit,&sOperation,&sPort,&sState,@rYield_Lower,@rYield_Upper,@rYield_Fixed ALLINPORTS,1,1,0.0 A,90,OUT1,,1,1,90.0 A,90,OUT2,,1,1,90.0 A,90,OUT3,,1,1,90.0 B,15,OUT,,1,1,15.0 C,5,OUT,,1,1,5.0 D,20,OUT1,,1,1,20.0 D,20,OUT2,,1,1,20.0 D,20,OUT3,,1,1,20.0 E,21,OUT,,1,1,21.0 F,25,OUT,,1,1,25.0 G,14,OUT,,1,1,14.0 H,28,OUT,,1,1,28.0 I,30,OUT,,1,1,30.0 J,45,OUT,,1,1,45.0 &sUnit,&sOperation,&sPort,&sState,@rYield_Lower,@rYield_Upper,@rYield_Fixed !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Cost Data (Pricing) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    • &sUnit,&sOperation,&sPort,&sState, @rFlowPro_Weight,@rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight END,,IN,,MINMAX*1.0 &sUnit,&sOperation,&sPort,&sState, @rFlowPro_Weight,@rFlowPer1_Weight,@rFlowPer2_Weight,@rFlowPen_Weight !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Command Data (Future Provisos) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! &sUnit,&sOperation,@rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time ALLPARTS,1,1,BEGIN,END &sUnit,&sOperation,@rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState, @rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time ALLPATHS,1,1,BEGIN,END &sUnit,&sOperation,&sPort,&sState,&sUnit,&sOperation,&sPort,&sState, @rSetup_Lower,@rSetup_Upper,@rBegin_Time,@rEnd_Time &sUnit,&sOperation,&sPort,&sState, @rTotalRate_Lower,@rTotalRate_Upper,@rTotalRate_Target,@rBegin_Time,@rEnd_Time END,,IN,,0,200,,BEGIN,END &sUnit,&sOperation,&sPort,&sState, @rTotalRate_Lower,@rTotalRate_Upper,@rTotalRate_Target,@rBegin_Time,@rEnd_Time