Batch Utility to Compute Manufacturing Context

The standalone DLMMfgContextSolver program helps to compute manufacturing context (filtered-including Volume based filtered/non-filtered), volumetric context and save the computed contexts to manufacturing hub. The DLMMfgContextSolver program needs a license of V5 Process Context Builder (PCR) for execution.

The solver provide options to compute the manufacturing context in the scope of a parent process or parent product. This option reduces the computation time and hence improves the performance as the search is limited within the scope of the parent process/product.

The solver batch utility is a client of the Manufacturing Hub server and can be executed from the command prompt.
 

Inputs to Compute Context

The XML file containing the parameters for the context computation.

Manufacturing Hub username and password of the user for computing the context. The user account have read/write permission to the process node on which the context detailing is to be saved. The process node is specified in the input XML file as Reference Process. See Syntax for Starting the Solver

Syntax for Starting the Solver

To launch the solver using the CATSTART utility, use the syntax below as an example:

<V5 Installation directory >\intel_a\code\bin\CATSTART.exe -run "DLMMfgContextSolver.exe -file <absolute path to the input xml file> -username <manufacturing hub user name> -password <manufacturing hub password>" -<V5 environment name> -direnv "C:\Documents and Settings\User Folder\Application Data\DassaultSystemes\CATEnv"

Capabilities of XML File

The input XML file has the capability to define the type of context to be computed. A detailed list of capabilities is given below:

ReferenceProcessID: This is the OID of the process on which the context needs to be stored. This is a mandatory element.

Comment: This is an optional element where you can add comments. The comments are persisted in the MHub database in the same object where the context information is persisted (i.e. in the blob). The clients can provide the capability to read this comment and display it.

  1. ManufacturingContext: This is an optional element, which instructs the solver to compute the Manufacturing Context. If this element is not specified, the existing Manufacturing Context (if any) stored on the Reference Process will be retained as it is.
    1. Option: The "Option" attribute is a mandatory element that specifies whether to compute a new context, retain, or delete the previously saved Manufacturing Context. Valid Values are:
      • ComputeContext - Query the database to compute the context considering the inputs. A query of the context will automatically replace the existing Manufacturing Context (if any) stored on the Reference Process with the newly computed context.
      • DeleteContext - If this is specified, it is assumed that you do not want to compute the Manufacturing Context and the intention is to permanently remove the existing Manufacturing Context (if any) stored on the Reference Process. Any other inputs specified will be ignored.
      • RetainContext - If this is specified, it is assumed that you do not want to update the existing Manufacturing Context (if any) stored on the Reference Process. Any other inputs specified will be ignored
    2. RootProcessID: RootProcessID is a mandatory element. It instructs the solver to compute the Manufacturing Context with respect to the Root Process specified.
    3. RootProductID: This is an optional element. This is mandatory only if you wishes to include products in the context computation. It instructs the solver to compute the Manufacturing Context with respect to the Root Product specified. This element will reduce the time to compute the context.
    4. RootResourceID: This is an optional element. This is mandatory only if you wishes to include resources in the context computation. It instructs the solver to compute the Manufacturing Context with respect to the Root Resource specified. This element will reduce the time to compute the context.
    1. ProcessRelation/RelationName: RelationName is used to specify the relation that is used to compute the Manufacturing Context. Valid values are: process_mustprecede_process and process_runsbefore_process.
    2. ProductRelation/RelationName: RelationName is used to specify the relation that is used to compute the Manufacturing Context. Valid values are: proc_processes_prod, proc_creates_prod, proc_firstprocesses_prod, and proc_removes_prod. Any combination of relations can be specified (between one and four). Specifying only proc_removes_product will cause the solver to ignore the Manufacturing Context computation for products.
    3. ResourceRelation/RelationName: This is used to specify the Relation that is used to compute the Manufacturing Context. Valid values are: process_attaches_resource and process_detaches_resource.  Any combination of relations can be specified. Specifying only process_detaches_resource will cause the solver to ignore the Manufacturing Context computation for resources.   If none of the relations are specified, the solver will ignore the Manufacturing Context computation. An error will be reported in the Log file generated.
    4. BoundingBoxCoordinates: "BoundingBoxCoordinates"  is an optional element for the Manufacturing Context. The values for the six parameters of the bounding box will be used to filter the computed Manufacturing Context within the specified volume. The bounding box values should be specified in world (absolute) co-ordinates.
    5. BoundaryOperator: BoundryOperator specifies the mode of filtering the ManufacturingContext.  This element is mandatory if the BoundingBoxCoordinates are defined. Valid Values are: FullyIn and PartlyIn.
    6. Filters: "Filters" is an optional element. Filters are applicable only for context computation and is not a mechanism for creating multiple contexts, one per filter set (i.e: multiple Manufacturing contexts per different filter set is not supported). The following filters are supported:
      • ProcessFilter (string as well as Calculation Model)
      • ProductFilter (string as well as Calculation Model)
      • ResourceFilter (string as well as Calculation Model)
      • Date Effectivity (along with effectivity mode)
      • Line Number filter
      • Label filter
      • Planning State Filter (owner and other)
      • Process extended effectivity (filter string as well as Calculation Model)
      • Product extended effectivity (filter string as well as Calculation Model)
      • Resource extended effectivity (filter string as well as Calculation Model), Please refer to the Filters in VolumetricContext.
    1. ExpirationDate:The "ExpirationDate" attribute is an optional attribute that specifies the last date the context must be computed. After midnight localtime of this date, the solver will ignore the request to compute the Manufacturing Context. Valid Values are: Any date in the format "YYYY-MM-DD". For example, "2008-12-28" represents December 28, 2008.
  1. Volumetric Context: This is an optional element, which instructs the solver to compute the Volumetric Context. If this element is not specified, the existing Volumetric Context (if any) stored on the Reference Process will be retained as it is.
    1. Option: The Option attribute is a mandatory element that specifies whether to compute a new context, retain, or delete the previously saved volumetric context. Valid values are:
      • ComputeContext - Query the database to compute the context considering the inputs. A query of the context will automatically replace the existing Volumetric Context (if any) stored on the Reference Process with the newly computed context.
      • DeleteContext - If this is specified, it is assumed that you do not want to compute the Volumetric Context and the intention is to permanently remove the existing Volumetric Context (if any) stored on the Reference Process. Any other inputs specified will be ignored.
      • RetainContext - If this is specified, it is assumed that you do not want to update the existing Volumetric Context (if any) stored on the Reference Process. Any other inputs specified will be ignored.
    2. BoundingBoxCoordinates: All six bounding box values (Xmin, Xmax, Ymin, Ymax, Zmin, and Zmax) are mandatory if the Volumetric Context element is defined. The values for the six parameters of the bounding box will be used to compute the Volumetric Context. If the bounding box values are not specified in the Volumetric Context computation will be ignored. The bounding box values should be specified in absolute co-ordinates.
    3. BoundaryOperator: BoundryOperator specifies the mode of computing the Volumetric Context. This element is mandatory if the BoundingBoxCoordinates are defined. Valid values are: FullyIn and PartlyIn.
    4. Filters: Filters is an optional element. Filters are applicable only for context computation and is not a mechanism for creating multiple contexts, one per filter set (i.e: multiple volumetric contexts per different filter set is not supported). Filters are applied only to the products, since the context is computed on the products. The following filters are supported:
      • ProductFilter (string as well as Calculation Model)
      • Date Effectivity (along with effectivity mode)
      • Line Number filter
      • Label Filter
      • Planning State Filter (owner and other)
      • Product extended effectivity (filter string as well as Calculation Model)

      • Example of specifying the filter values in the Input XML file:

        • Date Effectivity Filter
          <StartDateEfffectivityFilter>03/02/2009</StartDateEfffectivityFilter>

          <EndDateEfffectivityFilter>03/05/2009</EndDateEfffectivityFilter>

          <EfffectivityFilter Mode>Mode Value</EfffectivityFilterMode>

          For Effectivity Filter Mode, one of the following rule values can be supplied:
          • Give the objects whose begin and end dates contains the begin and end date filter values. The rule value is 1.
          • Give the object whose begin and end dates are within the begin and end dates filter values. The rule value is 2.
          • Give the object whose begin date value is lesser than the begin date filter value and the end date value on the object is contained within the begin and end date filter values. The rule value is 4.
          • Give the object whose begin date value is contained within the begin and end date filter values and the end date value on the object is greater than the end date filter value. The rule value is 8.
          • Give the object whose begin and end dates exactly match with that of the begin and end date filter values. The rule value is 16. The combination of the above said rules can also be used. For example: If you wants the combination of rule A and C, then the value of 5 should be passed.
            If you have not specified any value for this filter, then a default value of 31 (combination of all rules) will be used.
        • Extended Effectivity Filter:
          CASE1: Extended Effectivity Product Filter (when only filter string is applied)
          Filter String can be logical combination of Line Numbers, SA-Codes, and Label Filters.
          <ProductExtendedEffectivityFilter>R(110)&XXX Token</ProductExtendedEffectivityFilter>
          <ProductExtendedEffectivityFilterCalcModelID></ProductExtendedEffectivityFilterCalcModelID>

          CASE2: Extended Effectivity Product Filter (when only Calculation Model is applied)
          <ProductExtendedEffectivityFilter></ProductExtendedEffectivityFilter>
          <ProductExtendedEffectivityFilterCalcModelID>Calc.Model1,0</ProductExtendedEffectivityFilterCalcModelID>

          CASE3:Extended Effectivity Product Filter (when Filter String and Calculation Model are both applied)
          <ProductExtendedEffectivityFilter>R(110)&XXX|Token1<ProductExtendedEffectivityFilter>
          <ProductExtendedEffectivityFilterCalcModelID> Calc.Model1,0</ProductExtendedEffectivityFilterCalcModelID>   
        • Product Component Filter:
          CASE1: Product Filter (when only filter string is applied)
          <Product Filter>Token1,Token2</ProductFilter>
          <ProductFilterCalcModelID></ProductFilterCalcModelID>.

          CASE2: Product Filter (when only calculation model is applied)
          <Product Filter></Product Filter>
          <ProductFilterCalcModelID>Calc. Model1,,0</ProductFilterCalcModelID>
        • Label Filter
          <Label Filter>XXX,YYY</Label Filter>
        • Line Number Filter
          <LineNumberFilter>1,3,510,20berFilter</LineNumberFilter>
        • Planning State Filter
          <PlanningStateOwnerFilterID>ID of Planning State ID of Planning State</PlanningStateOwnerFilterID>
          <PlanningStateOtherFilterID>ID of Planning State ID of Planning State</PlanningStateOtherFilterID>
  2. ExpirationDate: The ExpirationDate attribute is an optional attribute that specifies the last date the context must be computed. After midnight localtime of this date, the solver will ignore the request to compute the VolumetricContext. Valid values are: Any date in the format (YYYY-MM-DD).

Solver Working Mode

The solver reads the input file, process the parameters, computes the context, and saves a context detailing on the Reference Process. The input XML file has the capability to request the solver to compute the Volumetric Context and/or the Manufacturing Context. Both contexts can be computed either in maximum configuration mode or for a specific configuration. Since the input parameter file has the option to compute either Volumetric Context or Manufacturing Context, you can decide what type of context needs to be computed. In the event one of the contexts was previously computed but not at a later time, the default behavior of the solver is to retain the existing context.

The solver saves the context every time it is computed. The context will be saved as a context detailing on the Reference Process. The Context blob will have the result of the Volumetric Context (if it was computed) and the Manufacturing Context (if it was computed). If a Bounding Box is specified for the Manufacturing Context, then the volume filtered Manufacturing Context will be saved in the blob. A reference process can contain only one context detailing at a given time. The Context detailing will not contain any configuration information. If the context is computed in maximum configuration mode, it is the responsibility of individual clients that consume the context to configure the context information per the configuration filters the user applies while using the clients.

Context Detailing Data

The Context data is saved to the Manufacturing Hub as a context detailing on the reference process object. The following data is persisted in the context detailing:

  • Volumetric Context
  • Manufacturing Context
  • The Envelope contain all the parameters specified in the Input XML file. This envelope information is purely for reference purposes. Envelope information contains, when (date and time) the context was computed, the user who computed the context, comments, other parameters such as filters applied during computation, volume box applied, the reference process and product against which the context was computed, the process relations used to traverse the process graph, and other rules ( fully-in, partly-in bounding box etc.) For any given process, only one context detailing will be stored in the Manufacturing Hub database. It is up to individual applications that consume the context to show the context information in that application desired format.

The solver will ignore the request to compute the Context (both Volumetric and Manufacturing) if the reference process is in ReadOnly for the Manufacturing Hub user, in which case the log file will be recorded with the reason for ignoring the context computation.

The solver will store the Manufacturing Context information in the database as a "flat list" of objects.

Relation Supported by Manufacturing Context

The Manufacturing Context support the following process to product relations:

  • Process creates Product (PCP)
  • Process first processes Product (PFPP)
  • Process processes Product (PPP)
  • Process removes Product (PRP)

The input XML file specify the type of relations to consider for the context computation. All Products associated to Processes using PCP, PFPP, and PPP will be added to the Manufacturing Context (assembly buildup), while Products associated to the Processes using PRP will be removed from the Manufacturing Context.

The Manufacturing Context supports the following process to resource relations:

  •  Process attaches resource (PAR)
  • Process detaches resource (PDR)

The input XML file should explicitly specify the type of relations to consider for the context computation. All resources associated to Processes using PAR will be added to the Manufacturing Context (assembly buildup), while resources associated to the Processes using PDR will be removed from the Manufacturing Context.  

The Process tree is traversed using the following Process-to-Process relations:

  • Process must precede Process
  • Process runs before Process

The input XML file should specify the types of relations for Process traversal.

Rules to Compute Manufacturing Context

The rules for computing Manufacturing Context are specified below.

For the sake of exposition:

  • The relations PCP, PFPP, PPP, and PAR are considered to integrate products/resources to the manufacturing context, and hence are referred to as integrating relations. The corresponding Processes are referred to as integrating processes.
  • The relation PRP and PDR removes products from the assembly, and hence are referred to as removing relations.
  1. The state of a object is integrated (and hence belongs to the manufacturing context), if:
    • At least one predecessor process is linked with the object via an integrating relation (PCP, PFPP, PPP, or PAR), and no other predecessor process is linked with the object via a removing relation. For example, see Prod11 in below figure.
    •  The object is linked with some predecessor processes via both integrating and removing relations. Further, there exists at least one integrating process for each removing process, such that the integrating process is a successor of the removing process. For example, see Prod121 in below Figure.

  1. The state of a object is removed (and hence does not belong to the manufacturing context), if:
    •  at least one predecessor process is linked with the object via a removing relation, and no other predecessor process is linked with the object via an integrating relation. For example, see Prod13 in below Figure.
    •  The object is linked with some predecessor processes via both integrating and removing relations Further, there exists at least one removing process for each integrating process, such that the removing process is a successor of the integrating process. For example, see Prod141 in below Figure.

  1. The state of a object is undefined (and hence does not belong to the manufacturing context), if the object is linked with predecessor processes via both integrating and removing relations. Further, the last integrating process and the last removing process are concurrent processes. For example, see Prod15 in below Figure.

  1. The state of a object is untouched (and hence does not belong to the manufacturing context), if the object is not linked with any predecessor processes (via integrate or remove relations). For example, see Prod16 in below Figure.

Context Computation Log File

A log-file is generated during the context computation. The log-file is stored in the ContextSolverLog directory in the CATTemp directory. This log-file is in addition to the DELMIA Manufacturing Hub Server side logs. The log file includes the following properties:

  1. The log file name will contain the time which represents the time when the Context Solver was invoked and also the machine name on which the Context Solver was invoked.

  2. The log file name will contain the OID of the Reference Process
    Example: ContextSolver_yearmonthdater_time_referenceProcessID.txt
    In case the OID of the referenceProcess specified in the XML file is invalid, then the log file name will not contain it.

  1. The log file will contain entries detailing the input file, the database user, the reference process, the time when the context solver successfully computed the context (Planning and Manufacturing), and the number of objects in each computed context.

  2. The log file will contain error messages encountered during the execution of the batch solver relating to object licenses, availability, and validity of inputs of the inputs to the solver, context computation, saving of the context detailing etc.

Limitations

  1. Resources may be included in the Volumetric Context computation if they have valid Bounding Boxes specified for them in the Manufacturing Hub.
  2. A specific process can have only one Volumetric Context and Manufacturing Context in the database. In the database, both contexts are stored in a single object (Blob).
  3. When defining the volume filter for the Volumetric context and the Manufacturing Context, only the Fully In and Partly In filtering modes are supported.
  4. Attribute filters are not supported to filter the Manufacturing Context.
  5. The Process structure should obey Hierarchical Order Constraints. When one process precedes another, then all children of the first process implicitly precede all children of the other.
  6. Precedence constraints can only be defined at the same level between processes. The solver will ignore precedence constraints between children processes.
  7. A child process can be contained by only one parent process.
  8. Specifying the reference process and product is applicable only for the computation of the manufacturing context and does not apply to volumetric context.
  9. The Manufacturing Context computation will consider only those processes that are either direct or indirect predecessors to the reference process, and that are within the defined root process.