eVSM to QUEST Interface

 

Overview

The CCAT eVSM Utilities tool with the DELMIA QUEST (http://3ds.com) option allows you to export Value Stream Map information to the DELMIA QUEST (QUeuing Event Simulation Tool).

 

CCAT has developed a set of Simulation Control Logic (SCL) macros in QUEST for importing plain text files in tab-delimited format, and transforming that data into QUEST modeling constructs.

 

The CCAT eVSM Utilities makes it very easy to generate the plain text files and automates the subsequent import within QUEST.

Terminology

• QUEST - QUeuing Event Simulation Tool.  This is Discrete Event Simulation Software provided by Dassault Systemes, and is used for the modeling and simulation of stochastic manufacturing systems
• eVSM - electronic Value Stream Mapping software (http://evsm.com).
• NVU - Name-Value-Unit.  An NVU is a construct within eVSM for holding process data.  The Name portion describes the name of the data, the Value is simply the data value, and Unit is the name of the unit the Value is measured in

Format Overview

The overall format for importing to QUEST is as such:

• Two rows of column header information
• One row delineating units in columns
• Process information in rows

 

Each row of simulation data represents a process in QUEST.  Each column holds different data about the process.

 

There are three pieces of required data for each process in eVSM:

• Cycle Time - The processing time of the process
• Workstation - The name of the machine resource where the process is completed.  This may also be a comma-delimited list of machines, each machine being capable of running the same process
• Product - The name of the product part class of the process

Configuration Files

The eVSM->QUEST SCL macros were built to be flexible enough to import VSM data from eVSM using whatever standardized NVU names you want.  An eVSM->QUEST configuration file has a .esm file extension, and is simply a list of setting names and values, similar to a QUEST .inc file.

 

The CCAT eVSM Utilities come with a pre-configured configuration file called QUEST_DIRECT.esm, and is stored in the DATA folder of the QUEST library you install the macros to.  This file is used as the default configuration file for exporting directly from eVSM.

 

Aside from mapping NVU names to data fields the SCL builder macros need, there are also several high-level settings that can be used to control how the SCL builder macros run.  The following are descriptions of several of these settings:

• CELL_DELIM - The delimiting character between columns in the input text file.  By default this is tab, but a comma can be used (and can be generated by MS Excel)
• COMMENT_LINE - This character tells the SCL builder macros that a line is not to be read as a process.  The default value is the # character
• Geo - These settings allow you to specify the default geometry for buffers and machines
• Workcell spacing options - These settings allow you to specify the spacing from a machine where the input and output buffers are to be placed.  You may also offset the location of the machine labor point in the y-axis using the LABOR_Y_SPACING setting
• Logic - These settings allow you to specify the logics to assign to various elements by default (in-buffer routing logic, process logic, etc...).  The SCL file in which the logics are located must be compiled before the build.  This can be done by listing your logic files in your configuration file with the variable name as SCL_FILE#, where # is a number between 1 and 5, and where no two listed logic files share the same number.  These files will be compiled before the SCL builder macros execute

Data Overview

As previously mentioned, there are three required pieces of information you must provide for a process in eVSM.  In reality, there are six pieces of data the SCL builder macros need in order to build a model; however, the following three pieces of data are automatically populated for you within eVSM :

• Operation- The name of the process
• Tag - A unique identifier for the process (no other process can have the same tag, but may have the same name)
• Next Op - The Tag of the process downstream of the current process.  This is used for identifying process sequences and routings

In addition to this required information, there is a set of optional NVUs you may provide to the SCL builder macros:

• Changeover Time - The time required to change a machine from one process to another - modeled as a setup process in QUEST, between each process on the machine
• Load Time - The time required to load a part onto a machine before the cycle process begins.  This is modeled as a setup process and is executed when the same process is performed twice in a row.  This means the load time must be included in changeover time, as the first load time is not run
• Operator - The name of the laborer class to be required on a process.  If a process has a changeover and/or load time assigned to it, the operator is assigned to the load/changeover process(es).  Otherwise the operator is assigned to the cycle process
• Operators - Depending on the assign_all_operators_to_process setting in the configuration file used.  If the setting is 0, then the operators value represents the number of laborers in the labor class.  If the setting is 1, then that number of operators is assigned to the process the laborer is assigned to
• Num Elements - The number of elements in the machine class
• MTTR/MTBF/Uptime - This is machine reliability data commonly used in simulation. Two of the three listed NVUs must be present to properly assign QUEST failures to the machines.  If Uptime is provided, the NVU not present (MTTR or MTBF) is calculated based on the Uptime value and whatever value is present
• Scrap - The rejection rate of the process.  The rejection rate tells QUEST what percentage of parts to scrap, which means the parts are destroyed, and not repaired.  The SCL builder macros do not currently support part repair
• Geometry -  The display geometry file name for the listed Workstation.  This will override the configuration file level setting
• TimeToNext - The time for the part to get to its next operation.  The time delay is executed on the output buffer of the machine which the process is run on, and is not resource-constrained.  The part enters the buffer, and after the TimeToNext is elapsed it moves on to the next process.  This may be used for modeling outside operations which are not being modeled.  This value may be provided as an SCL expression (meaning you may use build-in distribution functions)
• Shifts - The number of shifts the listed Workstation of the process works.

Units

The builder assumes that the data file coming in was created using eVSM.  As of eVSM version 4, units are placed in the third row, and so the builder assumes row 3 of the data file it reads contains the units for all the NVU's.  The builder will look to these units to determine the units for: cycle time, setup time, load time, IAT, time to next operation, and Mean Time To Repair (MTTR).  If no units are found for a specific variable, default values are assumed (minutes for cycle, setup, and load times; hours for IAT & MTTR)

Location/Layout Information

The SCL builder macros need to know where to put the machines listed in the Workstation NVU of a process.  This can be provided multiple ways:

• Shape of the Value Stream Map
• Locations from an eVSM Spaghetti Chart
• Manual location

When building from eVSM, you only have a choice between laying out machines in the shape of the VSM, or getting locations from an eVSM Spaghetti Chart. 

 

If you choose the shape of the VSM, the SCL builder macros will place a machine in the location of the first process that uses that machine in its Workstation NVU.  To locate based off an eVSM Spaghetti Chart, you must provide the name of the page the Spaghetti Chart is on, and the column from Excel corresponding to the place names set in the eVSM Spaghetti Chart.  For example, if you name all your Spaghetti Places based on the values from your Workstation NVUs, you would tell the builder interface in eVSM to use the Workstation column for locating machines.

CCAT eVSM Utilities interface to SCL Builder Macros

Layout Options

Select a radio button to tell the builder how to locate machines in QUEST.  Using "No layout" or "Layout file" will locate machines in the shape of the VSM.  Using "Layout from page" requires that you specify the name of the eVSM Spaghetti Chart page, and the name of the column in the eVSM Excel Calculator spreadsheet which matches up processes with the location names in your eVSM Spaghetti Chart

 

esm File

You may specify an esm configuration file, if you have a customized file you need to use for the export.  If left blank, the default QUEST_DIRECT.esm is used.

 

Pre- and Post-Build BCL Commands

You may specify a list of BCL commands to be executed before and after the SCL builder macros are executed.  You may wish to compile logic files before the build, or to run different SCL macros after the builder execution.

 

These commands should be stored in the eVSM Excel Calculator spreadsheet.  The worksheet the BCL commands are stored in should be named the same as the page your VSM is in, with "_BCL" appended on the end of the name.  The easiest way to set this up is to click the "Import BCL from Excel" button, and the worksheet will be created, if necessary.

 

You must specify which columns contain which commands, where Pre-build BCL commands must have " *--PRE_BUILD_BCL*" in the first row cell of the pre-build commands column.  " *--POST_BUILD_BCL*" must be in the first row cell of the post-build commands column.

 

Build Process

Once you have your settings complete in the CCAT eVSM Utilities, click the "Build" button.  This will execute the eVSM Calculator, after which the CCAT eVSM Utilities will export the machine locations to Excel, as well as the Next Op data for each process (based on the connections between processes in your VSM).  Finally, the CCAT eVSM Utilities will export your Excel data to a tab-delimited text file, and start QUEST and tell it to execute a BCL script generated with your pre- and post-build BCL commands, as well as commands to run the SCL builder macros.

 

The SCL builder macros begin by reading the spreadsheet data to an internal string array, and identifying all the column names, as well as reading units for different NVUs.  Next, the builder copies data it has mapped to specific fields to a different string array, and begins the build process.

 

The build process begins with building part classes based on the Product column, then it builds a process for each row in the data array.  Next, the process products and requirements are set based on the links between processes and their products.  For instance, if two processes both have a process with tag "B10", the builder will interpret the process as an assembly process, and will require one of each of the Product part classes from the feeding processes.  Then, based on the Product of the process, the process will be set to either pack one of the requirements into the other, or it will create a new part (if the product is not one of the requirements).

 

Next, shifts are added to machines based on the Shift data, if provided.  If a machine is listed as having more than three shifts, then each shift is set as a time of 24 hours divided by the highest shift number found.  If the maximum shift number is 3 or less, then each shift is set as 8 hours.  Later on in the build, these shifts will be assigned to your machines.  If the shift times need to be changed this can easily be done either manually or through BCL.  The hardest part is done for you, which is creating and assigning the shifts to machines.

 

Next, workstations are created.  A workstation is just a machine, an input buffer, and an output buffer.  An input buffer receives and holds work until its machine can take it.  An output buffer holds finished work until it can be moved to the next workstation. 

 

As noted above, if TimeToNext is provided for a process, the workstation's output buffer will hold the part for whatever that TimeToNext value is.

 

Each workstation gets added to its own group so you may easily move a workstation around within a model.

 

Next, the builder will build connections between workstations.  This is done based on the requirements of the processes on different machines.

 

Next, laborers are assigned to processes.  If a process has loading or changeover associated with it then the laborer is assigned only to the loading/changeover process(es).  Otherwise the laborer is assigned to the cycle process.

 

Next, loading and changeover machines are assigned to machines.  After that, the builder assigns a process sequence to each part class, based on the chain of requirements and products of all the processes previously built.  One noted problem with this is that the BCL statement to build a process sequence must contain the names of all the processes in the sequence, rather than simply adding one process to the sequence.  This means that you may run against a string size limit when building a model with many long-named processes.  To fix this, modify the BIG_STRING_SIZE constant in the build_from_vsm_generic.scl file to something larger.

 

The builder then assigns action logics, if applicable, as listed in the configuration file.  Next comes machine failures, which are created and assigned if a process lists a machine's reliability as detailed above.

 

Lastly, the builder goes back to the original input array and finds any data columns that were not mapped to known constructs, and creates user attributes on the processes holding that data.  This means you can very easily pass data between eVSM and QUEST without customizing the build_from_vsm_generic.scl file.

 

The builder then cleans up any build errors and data arrays, and saves the model to QUESTLib\Last_Build_Model.mdl.  Also, the builder creates a BCL script of all BCL commands that get executed throughout the build process, and a log file is kept at QUESTlib\Output\writer_log.txt.