Inter-operability of Manufacturing Applications in a Simulated Environment via CMSD Information Model

Transcription

1 Inter-operability of Manufacturing Applications in a Simulated Environment via CMSD Information Model Esfandyar Mazhari and Young-Jun Son Systems and Industrial Engineering, The University of Arizona Abstract The goal of this project is to demonstrate inter-operability of manufacturing applications in a simulated environment for a generic job shop via Core Manufacturing Simulation Data Information Model (CMSDIM). In particular, three applications considered in this project are Lekin job shop scheduler (freeware), Wildcat order and inventory system (custom developed as part of this project), and Arena simulation package. In this project, XML-schemas for various data elements (e.g. Work, Resource, Setup, Part Status, and Information) considered in our demonstration have been automatically generated from CMSD Part1 - Architecture v3.1 (available in Enterprise Architect). They have been then modified manually to overcome the discrepancies between what s supported by UML (CMSD) and XML-schema. XML documents conforming to the XML-schemas are then created using XML Editor Lite 3.2 software, and their validity has been confirmed via Exchanger XML Editor Lite 3.2 software as well. Then, we have developed translators/converters for each of the above mentioned three applications (Lekin, Wildcat, Arena), which translate neutral description (in an XML form) about the considered job shop facility as well as its corresponding information (e.g. products, orders, process plans) to/from the data format (e.g..txt for Lekin,.mdb for Wildcat,.doe for Arena) required by the applications. It is noted that the translators that we have developed are generic, and therefore, can be applicable to any specific job shops. The developed modules in this project have been implemented and demonstrated successfully for a specific job shop involving 5 machines, 11 queues, and 5 types of products. Keywords: information Simulation, manufacturing simulation, inter-operability, neutral definitions for

2 1. Introduction The main goal in this research is to demonstrate how Core Manufacturing Simulation Data Information Model (CMSDIM) aids us to integrate/interoperate multiple manufacturing applications in a simulated environment. In particular, three applications considered in this project are Lekin job shop scheduler (freeware), Wildcat order and inventory system (custom developed as part of this project), and Arena simulation package. In Section 8, motivations behind selecting these software systems are discussed in more details. In addition, a generic job shop has been used to illustrate our integration/interoperability methodologies that we have developed in this project. Figure 1 depicts an overview of our entire project activities (e.g. CMSD standards, XML schema generation and modification, XML document creation, XML document validation, considered manufacturing applications, translators between XML document and input/output to/from the manufacturing applications, illustration and demonstration), where each module will be discussed in detailed for the rest of this report (see Section numbers next to each module in Figure 1). In Figure 1, the upper part (development stage) denotes development (initialization) stage of the modules/tools that we have developed, and the bottom part denotes operation stage of them. The development stage involves CMSD standard, XML schemas, XML instances, XML validation and static information of a factory system (e.g. machines, queues, products, process plans, etc) (see Section 5.1 Development stage) whereas the operation stage involves dynamic information of the factory (e.g. orders) (see Section 5.2 Operation Stage).

3 CMSD Information Model XML Schema Generator (EA) XML Schemas User Validate XML using Exchanger XML XML Instance XML Factory Description Converter / Converter / 9.1 Translator 9.1 Translator 9.1 Converter / Translator Arena Format Lekin Format WildCat Sys Format Arena Engine Lekin Scheduler WildCat System Arena Format Lekin Format WildCat Sys Format 9.2 Converter / 9.2 Converter / 9.2 Translator Translator Converter / Translator XML (Factory Status) 9.3 Converter / 9.3 Converter / 9.3 Translator Translator Converter / Translator Arena Format Lekin Format WildCat Sys Format Figure 1: Overview of project activities conducted in this project

4 2. CMSD Information Model (IM) CMSDIM is composed of two parts, including Parts I (UML part) and Part II (XML part conforming to UML part). As not all the data elements available in UML were available to us in XML, we needed to created XML Schema and documents conforming to the UML part as part of this project (see Figure 1). CMSD Package is the top-level package of CMSDIM (Part I). This package is composed of five packages which are nested within it., Four of them have been used directly in this project to describe our manufacturing system (job shop) including 4.7 Resource Information Package, 4.8 Part And Inventory Information Package, 4.9 Production Operations Package, and 4.10 Production Planning Package. The other package in CMSD top-level package is Support Package which most of the packages in the CMSDIM depend on information defined in one of the sub-packages of the support 2.1 UML Definition of CMSDIM The information model defined using the Unified Modeling Language (UML) is presented in CMSDIM, Part 1. The draft version of CMSDIM part one (revision date is September 13, 2006) was sent to us by NIST. All the concepts and data structure in this research are mainly based on this document. We received CMSDIM in two different formats, including 1) a hard copy of CMSDIM (or an acrobat pdf file format) and 2) an enterprise architect data model structure (EAP format: Enterprise Architect Project). Figures 2 to 5 depict samples from the pdf file, and Figure 6 depicts a sample from the EAP file in Enterprise Architect application environment. Figure 2 depicts an example on UML representation of Resource class; Figure 3 depicts UML representation of Part class. Figure 4 and Figure 5 depict an example on UML representation of Order class and Process plan class, respectively. These UML diagrams are used in our research to represent machines (workstations) and queues (buffers), part (jobs or products), orders and process plans (routing sequence of parts).

5 Figure 2 : CMSDIM section 4.7 example, resource class Figure 3: CMSDIM section 4.8 example, part class,

6 Figure 4: CMSDIM section 4.9 example, order class Figure 5: CMSDIM section 4.10 examples, process plan class

7 2.2 XML Definition of CMSDIM The information model defined using the XML (extensible Markup Language) Schema is presented in another document: CMSDIM, Part II. In this project, Part II of CMSDIM was not available. Instead, NIST has sent us some sample XML Schema files and XML documents conforming to it. A small part of an XML file which was sent from NIST is shown in Figure 6. Error! Reference source not found. Figure 6 : An example from NIST XML sample files. 3. XML Schemas A schema is a way to describe and validate data in an XML environment. A schema is a model for describing the structure of information. XML files should be well formed and validated before they can be used. As shown in Figure 1, we have generated XML schema from data elements in CMSD (in the form of UML). In this project work, we have employed Enterprise Architect (EA) for UML model, and used Generate Schema XML function in EA for automatic generation of schemas. As mentioned before, some schemas for data in CMSDIM were sent by NIST. However all the schemas were generated again based on the CMSDIM Enterprise Architect Project file. (V3.1). Figures 7 to 9 depict the steps for generating a schema using UML diagrams in an EAP file.

8 Figure 7 : Steps to generate a schema in EA application (1) Figure 8 : Steps to generate a schema in EA application (2)

9 Figure 9 : Steps to generate a schema in EA application (3) After major XML schemas are generated, we modified them manually due to the discrepancies between what s supported by the available UML and XML schema. In this project, 34 schemas have been generated, where 5 of them where used in the demo (Resource.xsd, ResourceClass.xsd, Part Information.xsd, Work.xsd and Process Plan.xsd). Small parts of each of these 5 used schemas are shown in Figures 10 to 14. A complete list of the generated schemas is shown in appendix A. Examples for generated and used XML schemas are given in Appendix B.

10 Figure 10: XML Schema example 1, Resource.xsd Figure 11: XML Schema example 2, ResourceClass.xsd

11 Figure 12 : XML Schema example 3, Part Information.xsd Figure 13 : XML Schema example 4, Process Plan.xsd

12 Figure 14 : XML Schema example 5, Work.xsd 4. XML Documents In this research we used two XML editors to work with XML files: 1. Exchanger XML Editor Lite XML Marker 1.1 Both of the software systems are freeware, which can be downloaded online at for Exchanger XML Editor 3.2 and at for XML Marker 1.1. The first XML editor mentioned above is capable of checking compliance with the XML schema files for validation.

13 Exchanger XML Editor Lite 3.2 example

14 XML Marker 1.1 Example 4.1. XML Document Creation After generation of schema (.xsd) files with EA application, Exchanger XML was used to build an XML file based on the generated schemas (this was done using Infer XML command in Exchanger XML). This preliminary XML file was later edited manually with Exchanger XML. In Figure 15 a small part of an XML document is shown. Figure 15 : Edited XML document sample

15 4.2. XML Document Validation After the generated XML documents were edited manually, they were validated against the available schemas using the validation option of Exchanger XML application (see the snapshot of the validation process below): 5. Overview of Demonstration As mentioned earlier, in order to demonstrate inter-operability in a simulated environment, we have employed three applications (Lekin job shop scheduler, Wildcat order and inventory system, and Arena simulation package). XML format has been chosen as common communication format between these three packages.

16 Error! Reference source not found.figure 1 shows an overview of how the demonstration works. Each element in this figure has been and will be explained in detail in this report. The whole process, as shown in the Figure 1, is divided into two main phases, Development Stage and Operation Stage, and they are explained below. 5.1 Development Stage In Development Stage, information contained in the Factory Description XML file is used to generate 1) a simulation model, 2) Lekin job shop scheduler (machine definitions and part definitions), and 3) Wildcat order and inventory system. In this phase, essentially static information is translated into the considered packages. At the end of this phase, the generated simulation model is ready to be started. 5.2 Operation Stage In next phase, Operation Phase, the major structure of the applications (e.g. resources and products information in Arena simulation, Lekin job shop simulator, and Wildcat order and inventory system) will not change any more. Only dynamic information (e.g. orders) will be exchanged between different elements of the system. 6. Control Panel Developed For Demonstration The main control panel of the demonstration, which is designed in VBA, is shown in Figure 16 and Figure 17. Each figure corresponds to a different stage. Buttons 2, 3, 5 and 6 in the development stage corresponds to different converters/translators that are explained in Section 9. Also, buttons 8, 9A, 11 and 13 in the operation stage correspond to convertors/translators that are explained in Section 9. The screen captured movie files (avi version of the demonstration) is available in the following web site: Complete functionality of buttons in the control panel is discussed in next two sections in details.

17 Figure 16 : Control Panel, Development Stage 6.1. Development Stage Control Panel Step 1: This button opens and shows FactoryDescription.xml, which contains information about the static aspect of the factory such as Machines, Buffers, Orders, Products, and Process Plans Step 2

18 Based on an XML file shown in step 1, two text files are generated, which will be the input for an external scheduler Lekin Step 3 The factory information (XML file shown in step 1) is used to initialize WildCat Inventory and Orders system Step 4 This button opens Lekin scheduling software and loads two input files which were created at step 2 into the software. A schedule should be devised manually using Lekin software (as Lekin does not support VBA-like automation capability). A generated schedule will be saved as a text file Step 5 This button converts the text file (containing schedule information) generated at step 4 to the XML file (conforming to CMSD standard), and shows it Step 6 Based on an XML file shown in step 1, this button generates a simulation model automatically Step 7

19 This button runs simulation based on the external schedule generated at step 5 and external order and Inventory information in FactoryDescription.xml (step 1). In fact, as this is the initial execution of the generated simulation with initial schedule and inventory/order, this step can be seen as the first step of the Operation Stage, which is a repetition of this step with dynamically updated information. Figure 17 Control Panel, Operation Stage 6.2. Operation Stage Control Panel

20 6.2.1 Step 8 This button transfers current factory information (e.g. orders, parts, and inventory) from simulation model to FactoryStatus.XML. This file complies with CMSD. The file will be shown afterwards Step 9-A Based on the new information from "FactoryStatus.XML", this button updates the "Order and Inventory" system Step 9-B This button generates new orders in "WildCat Order and Inventory system Step 10 If any changes have happened in "Order & Inventory" system, "FactoryStatus.XML" should be updated. This button checks for changes and updates the "Order and Inventory" system Step 11 This button reads updated file "FactoryStatus.XML", generate and show new text files which will be new information used for scheduler software (Lekin). This step is similar to step 2 in development stage.

21 Step 12 This button opens Lekin scheduling software and loads two input files which were created at step 11 into the software. A schedule should be devised manually (as Lekin does not support VBA-like automation capability). A generated schedule will be saved as a text file. This step is similar to step 4 in the development stage Step 13 This button converts the text file (containing schedule information) generated at step 12 to the XML file (conforming to CMSD standard). This step is similar to step 5 in the development stage Step 14 Simulation continues after reading the new information from XML files updated or generated in Operation stage. 7. Considered Manufactuing Systems (Generic Job Shop) and Their Factory Description (XML Instance) Figure 18 depicts a particular job shop considered in this project. It is noted that while job shop shown in Figure 18 is used to illustrate the modules developed in this project, they are generic so will be applicable to any other job shop systems. For the demonstration in this research, we implemented an arbitrary production case with 5 products (5 families of products) and 5 machines. See Error! Reference source not found. and Figure 21 for process plans for each of these products.

22 Back to Main Buffer Main Buffer Waiting Area Input Buffers Resources Output Buffers Figure 18 : example job shop considered in this project for illustration. This section describes factory description, a major input needed to create input files for the considered manufacturing applications in this project (see Figure 1). It is noted that this XML document has been developed via all the processes (CMSD, XML Schema creation, manual edition and validation) which were discussed in Sections 2, 3 and 4. Factory Description XML file describes physical or informational objects and their attributes in a factory. (e.g. hardware, software/information, human, tools, materials, etc). The demonstration starts by reading all the necessary information from a XML file (called Factory Description ) which contains all the data to build and run the packages and the simulation model. In our job shop demonstration, Factory Description contains information about Machines and their Capacity, Queues ( Buffers ) and their capacity and queuing rule, Products, Process Plan for each Product and Orders that we have from customer or production plan for each product. Because

23 these data are available in the XML format, the very next step is to translate/convert these data to other formats which are understandable by those packages that we use. Therefore in development stage, all the data go through the convertors/translators before they are used by other packages. Figure 19 depicts a small part of factory description file, where the highlited area depicts information about a resource. Figure 19: Example for resource information in "Factory Description" XML file There is also information about inventory, process plans and orders in Factory Description XML file. An exemplary process plan for one product is shown in Figure 21.

24 Figure 20 Example for process plan in "Factory Description" XML file Process plans for jobs 1 to 5 (Product families 1 to 5) in our demo are depicted in Table 1. Table 1 : Process Plan for 5 families of products Machine Number Job Number 1 st 2 nd 3 rd 1 M3 M2 M1 2 M2 M3 M1 3 M3 M1 M2

25 Machine Number Job Number 1 st 2 nd 3 rd 4 M1 M3 M2 5 M2 M1 M3 The same process plans (sequences of operations) are used for Lekin application, and their representation in Lekin software are depicted in Figure 22. Figure 21 : Process plan representation in Lekin application 8. Choosing Applications and Particular Software Systems As explained earlier, we have employed three applications in this research to demonstrate the inter-operability of manufacturing applications and simulation systems. In selecting manufacturing applications and specific software systems, the following criteria was considered:

26 1. Application should be affordable (we were looking for freeware or very low cost applications) 2. Application should have the automation ability (i.e. it should have an internal macro/module engine or should support a programming language) 3. Application should be able to Import/Export from/to common file formats. Or application should use input/output files which are in a well known and easy to interpret format. 4. Application involves rich data elements (duing the development stage or operation stage) to increase the amount of data items of CMSD to be involved in the interoperability demonstration. Arena Simulation software was chosen as simulation engine. Both The University of Arizona as well as NIST has an access to the professional version of Arena. In addition, trial version of Arena is also available with no cost. In addition to availability, Arena 10.0 supports Visual basic for application (VBA) language, which facilitates automation in importing/exporting data. Another application chosen for this research is Lekin (freeware), which is a manufacturing environment job shop scheduler. Lekin does not have import/export capability and does not support any kind of automation via programming languages, however, input file and out put file of Lekin are in simple text format which allows us to communicate this application with other applications. The third application (Wildcat order and inventory system) is an inventory/order system which is based on Microsoft Access database. Obviously MS-Access support automation capabilities with VBA, which allows us to import/export various types of files. In this project, we did not use built-in XML import/export capabilities of MS-Access. Instead, we used our own developed converter/translator (see Section 9). 9. Converters/Translators As shown in Figure 1, we have developed several converters/translators in this project, which translate information contained in the XML files to the data in a format needed by the considered applications or vice versa. All of the converters in this project have been written in VBA (Visual Basic Application)

27 language. Chilkat ActiveX Component is used to facilitate working with XML files. Therefore, before running the software demo, Chilkat library should be installed in VBA. Overall, we have developed 6 different types of converters in this research, each of which is explained below. i. XML to Text converter This converter reads information from the XML files and returns simple text information which is transferred to scheduler software. (e.g. Machine information, Process Plan information) ii. XML to Access database This converter reads data from XML files and transfers those data into the appropriate tables in the WildCat order and inventory system. (e.g. orders information) iii. XML to Arena simulation application This converter reads data from XML files and translate/convert those data into internal variable/strings values in simulation engine. (e.g. resource information, queues information, etc.) iv. Text to XML converter Output of scheduler application is a text file. This text file should be converted to XML. Then this information will be used by simulation application during the development and the operation stages. v. Access data to XML converter When the Order and Inventory system is updated (for example when new orders are issued by customer), the new information should be converted to XML format and the Factory Status XML file should be updated. This file is used in operation stage. vi. Arena simulation application to XML converter/translator During the operation stage, result of simulation becomes translated/converted and written into the FactoryStatus.XML. Result of simulation is in form of values for some internal variables

28 and strings inside Arena environment. Converter/Translator reads this data and writes them as text into the XML file Converter/Translators from FactoryDescription. XML to Other Types As shown in Figure 1, first type of Converters/Translators, read information/data from Factory Description XML file and convert (translate) them to the format required by the used application (i.e. *.doe for Arena, *.txt for Lekin and *.mdb for WildCat system).in development stage: Figure 22 : Representation of Machine in XML file Figure 23 : Representation of Machines in Scheduler software Lekin file format

29 Figure 24 : Representation of Machine in Lekin Scheduler software after opening the translated/converted file Figure 25 : Representation of Machine in Arena Simulation software after transferring translated/converted data from XML file

30 Figure 26: Representation of machines and their assigned I/O buffer in Wild-Cat order/inventory system after transferring converted/translated data from XML file into Wild-Cat system. Converters/translators for Arena have been built into Arena, read information directly from XML files and convert them to values for variables or strings which are understandable by Arena. Converters/translators for Lekin scheduler software read data directly from an XML file and convert it to a specific text format which is understandable for Lekin software. Converters/translators for Wild Cat system also read information directly from XML files and write them into appropriate tables in MS Access. 9.2 Converter/Translators from Other Types to XML format Converters/translators here convert data in an application-specific form into the XML format. Information considered here might be an output file (e.g. schedule (text file) which is an output file from Lekin) or might be application internal variable values (e.g. data about queues, resources in Arena during simulation run). This information is read by VBA and is translated/converted back to the XML format and written into Factory Status XML file, which has a very similar structure to Factory Description file but does not contain the static data that was needed to construct the simulation model during the development stage.

31 All the converters/translators in Section 9.2 have been written in VBA language. Converter/translator for Arena is built into Arena, reads data/information from values for variables or strings, and converts and write them to an XML file. Converters/translators for Lekin scheduler software, read data directly from Lekin output file (text file) and convert and write it into XML. Converter/translator for WildCat system reads updated/changed/new data from tables (in MS Access) and transfers them into the Factory Status XML file. 9.3 Converter/Translators from FactoryStatus. XML to Other Types Converters/translators in this section are same as those discussed in Section 9.1, but their XML input file is Factory Status XML file, which gets updated repeatedly while the operation phase is in progress. As mentioned earlier, Factory Status XML file is very similar to Factory Description XML file. They both include the same type of information. The only difference is that Factory Description file is only used at the development stage. While simulation is running ( operation stage ), results of simulation are used to update the information in the Factory Status file. For example after a job is completed, order and inventory information is updated. This updated information is used in the next iteration to continue the simulation. At the same time, new orders may be issued due to customer demand. This information is read from the Order and Inventory system and is used to update the Factory Status file as well. 9.4 XML Read/Write Toolkit To facilitate read/write process to/from XML file using VBA, we used ChilkatXmlActiveX components for VBA in this project. This toolkit is freeware and can be downloaded at Source Code for Converters/Translators Developed in this Research As mentioned earlier, all the translators/converters are coded in VBA. Source code for these converters/translator can be found in Appendix D. 10. Lekin Scheduler Application: Lekin is a scheduling system developed at the Stern School of Business, NYU. Major parts of the system were designed and coded by Columbia University students. Lekin was created as

32 an educational tool with the main purpose of introducing the students to scheduling theory and its applications. Besides that, the system s extensibility allows (and encourages) to use it in algorithm development Features of Lekin Lekin supports 6 basic workspace environments: single machine, parallel machines, flow shop, flexible flow shop, job shop, and flexible job shop. In this research, for demonstration, job shop with multiple machines and multiple jobs is used Lekin supports various dispatching rules and heuristics. In this research, for demonstration purposes, ATCS scheduling rule is used. But any other scheduling rule can be used. Type of the rule used for scheduling does not affect the demo; it only changes the output file of Lekin. Translators/Converters developed in this research are capable of reading the output file of Lekin no matter which rule is used to produce them. The functionality of demo does not depend on the rule chosen in scheduler software. For more explanation about different rules, refer to Table Lekin environment supports Gantt chart with drag-and-drop capability Lekin application has a graphic tool for comparative analysis of different schedules Supported Scheduling Rules in Lekin Table 2 depicts different rules available for scheduling in Lekin. Table 2: Different Scheduling rule in Lekin software Rule Name Description

33 Rule Name ATCS EDD MS FCFS LPT SPT WSPT CR Description Apparent Tardiness Cost (with Setups). The most complicated rule for optimizing the Total Weighted Tardiness. ATCS is a compromise between WSPT and MS. Prompts for two parameters. Earliest Due Date. A simple rule for optimizing the Maximum Tardiness. Does not take job weights into account. Optimal only for single machine and zero release dates. Minimum Slack. A variation of EDD. First Come First Served. Schedules the jobs in the order of their release dates. Not a good rule. Longest Processing Time first. Balances the jobs, trying to equalize the load of different machines. Optimizes Make span for some settings. Shortest Processing Time first. Optimizes Total Flow Time for some settings. Weighted Shortest Processing Time first. A Weighted version of SPT. Optimizes Total Weighted Flow Time for some settings. Critical Ratio rule. Schedules jobs according to the ratio of the time left until the due date and the remaining processing time. A compromise between EDD and LPT Input/Output File Formats Each schedule (output from Lekin) is saved as a text file with.seq extension. This text file can be viewed as text with any text viewer software. Lekin generates a Gantt chart based on the same file which is a graphical representation of the schedule with time scale in horizontal axis. Example: This is a Lekin scheduler output (*.seq) file opened with text viewer:

34 Schedule: ATCS (1, 1) RGB: 31;58;176 Time: 1 Machine: W001 Oper: J002 Oper: J003 Oper: J001 Machine: W002 Oper: J002 Oper: J001 Oper: J003 Machine: W003 Oper: J002 Oper: J003 Oper: J001 Figure 27 Lekin output file which contains sequence information The information in the above mentioned file is not enough to describe a complete schedule. This information along with the jobs information in another text file (which is one of the two input files to Lekin ) are used together to represent a schedule completely. The latter file is also a text file with.job extension. Figure 29 depicts the complementary Job information text file to the sequence information in Figure 27. Shop: Job Job: J001 Oper: W002;2;A Release: 0 Due: 0 Weight: 1 Oper: W001;4;A Release: 0 Due: 0 Weight: 1 Oper: W003;1;A Release: 0 Due: 0 Weight: 1 Job: J002 Oper: W002;1;A Release: 0

35 Due: 0 Weight: 1 Oper: W003;1;A Release: 0 Due: 0 Weight: 1 Oper: W001;3;A Release: 0 Due: 0 Weight: 1 Job: J003 Oper: W003;3;A Release: 0 Due: 0 Weight: 1 Oper: W001;1;A Release: 0 Due: 0 Weight: 1 Oper: W002;2;A Release: 0 Due: 0 Weight: 1 Figure 28 : Lekin input file which contains job information Sequence and Job file, have enough information for Lekin to generate a graphical representation of the schedule, which is shown below:

36 In this sample, there are three machines (W001, W002, and W003) and three jobs (J001, J002, and J003) scheduled in the Gantt chart. The other input file is a text file which has information about machines in the system. This file has.mch extension: Ordinary: Workcenter: W001 Release: 0 Status: A Workcenter: W002 Release: 0 Status: A Workcenter: W003 Release: 0 Status: A Figure 29 : Lekin file which contains machine information 10.4 Lack of Automation Support Unfortunately, Lekin does not support any script/programming language to create macros or modules inside the software to automate tasks. Thus, input files should be loaded into Lekin manually (buttons available in Lekin) and the schedule should be generated and saved into the output file manually (using buttons available in Lekin) during the demonstration. 11. Arena Simulation In this research Arena has been chosen as simulation engine. One of the advantages of using Arena as a simulation engine in inter-operability projects is the VBA support by this application which facilitates automation and communications with other software Automatic Model Generator Information in FactoryDescription.XML file is used to generate the simulation model. Arena automatic model generator is made up of two main parts. The first part reads information about the job shop (e.g. resources, queues) from an XML file. The second part then uses this information to build a model. After a model is built, we manually edit/modify the model to

37 improve the cosmetics of the animation. It is noted that functionality of the model remains unchanged. Figure 30 shows the animation part of the Arena model after modification. In this figure, there are five machines (resources), out of which one is busy and others are idle at the moment the figure was captured from screen. Jobs (products) are shown with green boxes. Jobs 4 and 5 are waiting in the waiting area to be pulled according their next step in the process plan. Job 1 is currently in machine 3 and jobs 2 and 3 are moving between the main buffer and resources. Figure 30: Arena model animation 11.2 Modifications Made to Handle Internal Sequence Vs. External Sequence In Arena Simulation, each entity (or each part) has its own process plan and has a memory which keeps the information about how far that particular entity has progressed within its predefined process plan. Regarding machine stations, when parts arrive at a machine station while the machine is busy, they enter the queue based on the specified rules (e.g. first come first service, shortest processing time, highest priority among others). When a machine becomes available, the first part (if any) waiting in the queue seizes the machine and the processing starts.

38 For example if process plan for an imaginary part is M1, M3, M2 (M stands for machine), and part has just finished being processed at Machine M3, it goes to M2 afterwards. Also, each queue dedicated to each machine has its own rule which will be used to sequence the parts arriving at the corresponding machine station while the machine is busy. This type of scheduling is suitable for most cases. However, in our project, in addition to the process plan for each part, external schedules (a predefined order of jobs for each machine) obtained from Lekin software are provided to Arena simulator. In this case an entity can not enter a machine unless the machine is waiting for that particular entity (part) as well. Therefore, we have changed the default logic of Arena to handle the external schedules in this project (see Section 11.3). This type of predefined order for both machines and jobs (which practically happens in many production systems, such as job shop system) is considered as an external schedule. External schedules can be produced by human or software. In this demo, Lekin scheduler software generates schedules using different scheduling rules (see Table 2 for different rules) Used Logic for Simulation Engine To demonstrate inter-operability of manufacturing applications with simulation, we have used Arena simulation engine for the illustration purposes. However, the developed modeling logic is generic so that it can be implemented in any other simulation software Main Buffer Main buffer is a queue (or waiting area or buffer) with large (or unlimited) capacity. All parts start their routing in simulation software from this location. Each parts after each step of progress in its process plan goes back to this location and will go to next step from this place. This type of area may or may not exist in real world depending on the facility layout of the manufacturing environment Task Generator Data/Information about orders will be read from an XML file. For each single order item, an entity will be created and will be transferred to the main buffer. This task, in Arena, is done by Task Generator which is a collection of modules in a loop in which one single dummy entity

39 (it is called dummy because it does not represent any part, product or job) moves frequently. Task generator reads order information from an XML file repeatedly in short time intervals. Whenever it finds a new order or an old order with nonzero quantity left, it generates an entity (task or job). After generating each order, quantities for remaining orders are updated. The following figures depict several possible states which may happen in the task generator. Figure 31 : Task generator (1) Snapshot in Figure 33 depicts an instance moment when no order has been found yet. Figure 32 : Task generator (2)

40 Snapshot in Figure 33 depicts an instance moment when an order is found, but the corresponding task (job) has not been created yet Figure 33 : Task generator (3) Snapshot in Figure : 34 depicts an instance moment when an entity is created for the found order item Figure : 34 Task generator (4) Job Remover Entity remover is the place where controls the correct routing of the jobs based on their process plan. All the jobs will wait in a main buffer (queue). This queue is a detached queue. This means parts in the queue should wait until they become removed from the queue by an

41 external decision or request. Figure 35 shows the job remover logic in Arena. Once again, the same logic can be applied to any other simulation software. Figure 35 Job remover engine 12 WildCat Order and Inventory system WildCat is an Inventory/Order system which is designed and implemented in Microsoft Access. Good support of automation and programming language VBA makes it easy to use Access in interoperability project Factory Description Items Factory description information includes data about machines, queues, process plans, types of products, among others. An example for representation of factory description in Wildcat order and inventory system is shown in Figure 36.

42 Figure 36: Resources, buffers and queues representation in WildCat System Oder Detail Table Another table that is used frequently during the simulation run is the order table. After order is received, this table gets updated. And new information will be updated in the XML file, from which the simulation continuously reads the orders from. Figure 37 : An example for representation of orders in Wildcat order and inventory system 12.3 Resource/Buffer/Queue Information Table

43 As shown in Figure 36, after reading factory information, these data are stored in the table. For each resource, two different queues (one input buffer and one output buffer) are made and assigned. In addition to these queues, we also have a main waiting area. 13. Demonstration, Summary, and Future Works In this project, we have developed solution methodologies to demonstrate interoperability of different manufacturing applications (Lekin scheduling software and Wildcat order and inventory system) in a simulated environment (another manufacturing application, Arena simulator) using CMSD (in UML diagrams) developed by NIST. To this end, we have created several XML schema, XML documents, and converters/translators for the above mentioned applications. The developed modules have been developed and tested for the job shop (see Section 7). The developed systems have been successfully executed in the simulated environment at The University of Arizona, where the simulated system were interoperating with Lekin and Wildcat software systems for 100 minutes of simulation time. It is noted that the developed modules are generic so that they can be applicable any specific job shops. The screen captured movie files (avi version of the demonstration) is available at Future works includes expansion of considered manufacturing applications and to demonstrate the developed modules in a web service based distributed computing environment.

44 Appendix A 1. List of generated schemas: +---Resource Information SkillDefinition and SetupDefinition.xsd Resource.xsd Resource Characteristics.xsd Resource Status Parameters.xsd ResourceClass.xsd +---Changes Changes.xsd +---Extensions Extensions.xsd +---Layout Information Layout Types.xsd +---Part and Inventory Information Inventory Information.xsd Part Information.xsd Part Status Information.xsd BillOfMaterials.xsd +---Production Operations Work.xsd MaintenanceOrder.xsd Schedule.xsd +---Production Planning Organization.xsd Plan Definition Info.xsd Plan Step Info.xsd Process Plan.xsd Calendar.xsd MaintenancePlan.xsd OperationDefinition.xsd \---Support +---Basic Structures Basic Structures.xsd Basic Structures 2.xsd Basic Structures 3.xsd +---Basic Types Basic Types 2.xsd Basic Types 3.xsd Basic Types 1.xsd +---Context Context Entity Relationships.xsd CMSD Context Definition.xsd \---Key Definitions Key Definition 2.xsd Abstract Keys.xsd Complex Keys.xsd Key Definition 1.xsd 2. Full description of generated schemas: 09/11/ :44 PM <DIR>. 09/11/ :44 PM <DIR>.. 09/11/ :56 PM <DIR> Resource Information 09/11/ :59 PM <DIR> Changes 09/11/ :00 PM <DIR> Extensions 09/11/ :00 PM <DIR> Layout Information 09/11/ :00 PM <DIR> Part and Inventory Information 09/11/ :00 PM <DIR> Production Operations 09/11/ :01 PM <DIR> Production Planning 09/11/ :16 PM <DIR> Support 0 File(s) 0 bytes Directory of G:\NIST CMSDIM Schemas\Resource Information 09/11/ :56 PM <DIR>. 09/11/ :56 PM <DIR>.. 09/11/ :39 PM 15,042 SkillDefinition and SetupDefinition.xsd 09/11/ :37 PM 15,042 Resource.xsd 09/11/ :38 PM 15,042 Resource Characteristics.xsd 09/11/ :38 PM 15,042 Resource Status Parameters.xsd 09/11/ :39 PM 15,042 ResourceClass.xsd 5 File(s) 75,210 bytes Directory of G:\NIST CMSDIM Schemas\Changes

45 09/11/ :59 PM <DIR>. 09/11/ :59 PM <DIR>.. 09/11/ :58 PM 103 Changes.xsd 1 File(s) 103 bytes Directory of G:\NIST CMSDIM Schemas\Extensions 09/11/ :00 PM <DIR>. 09/11/ :00 PM <DIR>.. 09/11/ :01 PM 1,365 Extensions.xsd 1 File(s) 1,365 bytes Directory of G:\NIST CMSDIM Schemas\Layout Information 09/11/ :00 PM <DIR>. 09/11/ :00 PM <DIR>.. 09/11/ :07 PM 2,865 Layout Types.xsd 1 File(s) 2,865 bytes Directory of G:\NIST CMSDIM Schemas\Part and Inventory Information 09/11/ :00 PM <DIR>. 09/11/ :00 PM <DIR>.. 09/11/ :09 PM 10,560 Inventory Information.xsd 09/11/ :09 PM 10,560 Part Information.xsd 09/11/ :10 PM 10,560 Part Status Information.xsd 09/11/ :08 PM 10,560 BillOfMaterials.xsd 4 File(s) 42,240 bytes Directory of G:\NIST CMSDIM Schemas\Production Operations 09/11/ :00 PM <DIR>. 09/11/ :00 PM <DIR>.. 09/11/ :11 PM 8,724 Work.xsd 09/11/ :11 PM 8,724 MaintenanceOrder.xsd 09/11/ :11 PM 8,724 Schedule.xsd 3 File(s) 26,172 bytes Directory of G:\NIST CMSDIM Schemas\Production Planning 09/11/ :01 PM <DIR>. 09/11/ :01 PM <DIR>.. 09/11/ :13 PM 11,738 Organization.xsd 09/11/ :14 PM 11,738 Plan Definition Info.xsd 09/11/ :14 PM 11,738 Plan Step Info.xsd 09/11/ :15 PM 11,738 Process Plan.xsd 09/11/ :12 PM 11,738 Calendar.xsd 09/11/ :12 PM 11,738 MaintenancePlan.xsd 09/11/ :13 PM 11,738 OperationDefinition.xsd 7 File(s) 82,166 bytes Directory of G:\NIST CMSDIM Schemas\Support 09/11/ :16 PM <DIR>. 09/11/ :16 PM <DIR>.. 09/11/ :16 PM <DIR> Basic Structures 09/11/ :26 PM <DIR> Basic Types 09/11/ :26 PM <DIR> Context 09/11/ :27 PM <DIR> Key Definitions 0 File(s) 0 bytes Directory of G:\NIST CMSDIM Schemas\Support\Basic Structures 09/11/ :16 PM <DIR>. 09/11/ :16 PM <DIR>.. 09/11/ :25 PM 14,383 Basic Structures.xsd 09/11/ :25 PM 14,383 Basic Structures 2.xsd 09/11/ :25 PM 14,383 Basic Structures 3.xsd 3 File(s) 43,149 bytes Directory of G:\NIST CMSDIM Schemas\Support\Basic Types 09/11/ :26 PM <DIR>. 09/11/ :26 PM <DIR>.. 09/11/ :27 PM 11,153 Basic Types 2.xsd 09/11/ :28 PM 11,153 Basic Types 3.xsd 09/11/ :27 PM 11,153 Basic Types 1.xsd 3 File(s) 33,459 bytes Directory of G:\NIST CMSDIM Schemas\Support\Context 09/11/ :26 PM <DIR>. 09/11/ :26 PM <DIR>.. 09/11/ :33 PM 5,389 Context Entity Relationships.xsd 09/11/ :32 PM 5,389 CMSD Context Definition.xsd 2 File(s) 10,778 bytes Directory of G:\NIST CMSDIM Schemas\Support\Key Definitions 09/11/ :27 PM <DIR>. 09/11/ :27 PM <DIR>.. 09/11/ :35 PM 10,519 Key Definition 2.xsd 09/11/ :33 PM 10,519 Abstract Keys.xsd 09/11/ :34 PM 10,519 Complex Keys.xsd 09/11/ :34 PM 10,519 Key Definition 1.xsd

46 4 File(s) 42,076 bytes Total Files Listed: 34 File(s) 359,583 bytes 38 Dir(s) 881,623,040 bytes free End of appendix A

47 Appendix B In Section 3 we discussed that in this project, 34 schemas have been generated, where 5 of them where used in the demo. (Resource.xsd, ResourceClass.xsd, Part Information.xsd, Work.xsd and Process Plan.xsd). In this appendix, these five used schemas are listed. Sample XSD file: generated schema for Resource.xsd: <?xml version="1.0" encoding="iso "?> <xs:schema xmlns:xs=" <xs:element name="resource" type="resource"/> <xs:complextype name="resource"> <xs:extension base="identifyingcontextentity"> <xs:element name="resourceclass" type="resourceclasskey" minoccurs="0" <xs:element name="resourcegroupmember" type="resourcegroupmember" minoccurs="0" <xs:element name="resourcegrouptype" type="resourcegrouptype" minoccurs="0" <xs:element name="resourcetype" type="resourcetype" minoccurs="1" <xs:element name="resourcecharacteristic" type="resourcecharacteristic" minoccurs="0" <xs:element name="resourcestatusparameter" type="resourcestatusparameter" minoccurs="0" <xs:element name="skilldefinition" type="skilldefinition"/> <xs:complextype name="skilldefinition"> <xs:extension base="identifyingcontextentity"> <xs:element name="skilllevel" type="skilllevel" minoccurs="0" <xs:element name="setupdefinition" type="setupdefinition"/> <xs:complextype name="setupdefinition"> <xs:extension base="identifyingcontextentity"> <xs:element name="childsetup" type="setupdefinitionkey" minoccurs="0" <xs:element name="setupcomponent" type="resourcekey" minoccurs="0" <xs:element name="setupresource" type="resourcekey" minoccurs="1" <xs:element name="setupchangeover" type="setupchangeover"/> <xs:complextype name="setupchangeover"> <xs:extension base="identifyingcontextentity"> <xs:element name="changeovertime" type="duration" minoccurs="1" <xs:element name="currentsetup" type="setupdefinitionkey" minoccurs="1" <xs:element name="newsetup" type="setupdefinitionkey" minoccurs="1" <xs:element name="customparameter" type="customparameter"/> <xs:complextype name="customparameter"> <xs:element name="datatype" type="xs:string" minoccurs="0" <xs:element name="name" type="xs:string" minoccurs="1" <xs:element name="value" type="xs:string" minoccurs="0" <xs:element name="resourcegroupmember" type="resourcegroupmember"/>

48 <xs:complextype name="resourcegroupmember"> <xs:extension base="resourcekey"> <xs:element name="connection" type="connection" minoccurs="0" <xs:element name="resourcestatusparameter" type="resourcestatusparameter"/> <xs:complextype name="resourcestatusparameter" abstract="true"> <xs:sequence/> <xs:element name="resourcecharacteristic" type="resourcecharacteristic"/> <xs:complextype name="resourcecharacteristic" abstract="true"> <xs:sequence/> <xs:element name="workassignment" type="workassignment"/> <xs:complextype name="workassignment"> <xs:extension base="resourcestatusparameter"> <xs:element name="event" type="event" minoccurs="0" <xs:element name="workkey" type="workkey" minoccurs="1" <xs:element name="operationalstatus" type="operationalstatus"/> <xs:complextype name="operationalstatus"> <xs:extension base="resourcestatusparameter"> <xs:element name="value" type="resourceoperationalstate" minoccurs="1" <xs:element name="maintenancestatus" type="maintenancestatus"/> <xs:complextype name="maintenancestatus"> <xs:extension base="resourcestatusparameter"> <xs:element name="value" type="resourcemaintenancestate" minoccurs="1" <xs:element name="currentsetup" type="currentsetup"/> <xs:complextype name="currentsetup"> <xs:attribute name="setupdefinitionidentifier" use="optional" type="identifiertype"/> <xs:sequence/> <xs:element name="resourceavailability" type="resourceavailability"/> <xs:complextype name="resourceavailability"> <xs:extension base="resourcestatusparameter"> <xs:element name="effectiveshift" type="effectiveshift" minoccurs="1" <xs:element name="availabilityexception" type="availabilityexception" minoccurs="0" <xs:element name="effectiveshift" type="effectiveshift"/> <xs:complextype name="effectiveshift"> <xs:element name="calendar" type="calendarmultikey" minoccurs="1" <xs:element name="enddate" type="datetype" minoccurs="1" <xs:element name="shift" type="shiftkey" minoccurs="0" <xs:element name="startdate" type="datetype" minoccurs="1" <xs:element name="availabilityexception" type="availabilityexception"/> <xs:complextype name="availabilityexception"> <xs:element name="description" type="xs:string" minoccurs="0" <xs:element name="exceptiondate" type="datetype" minoccurs="1" <xs:element name="employeepaystatus" type="employeepaystatus"/> <xs:complextype name="employeepaystatus"> <xs:extension base="resourcestatusparameter"> <xs:element name="employmentstatus" type="employmentstatus" minoccurs="0" <xs:element name="overtimeeligible" type="xs:boolean" minoccurs="0"

49 <xs:element name="overtimeratemultiplier" type="xs:double" minoccurs="0" <xs:element name="payamount" type="currencytype" minoccurs="0" <xs:element name="payperiod" type="timeunit" minoccurs="0" <xs:element name="meantimebetweenfailure" type="meantimebetweenfailure"/> <xs:complextype name="meantimebetweenfailure"> <xs:annotation> <xs:documentation>is valid for [machine other crane]</xs:documentation> </xs:annotation> <xs:element name="distribution" type="distributiondata" minoccurs="0" <xs:element name="distributionreference" type="distributiondefinitionkey" minoccurs="0" <xs:element name="unit" type="timeunit" minoccurs="0" <xs:element name="value" type="xs:double" minoccurs="0" <xs:element name="meantimetorepair" type="meantimetorepair"/> <xs:complextype name="meantimetorepair"> <xs:annotation> <xs:documentation>is valid for [machine other crane]</xs:documentation> </xs:annotation> <xs:element name="distribution" type="distributiondata" minoccurs="0" <xs:element name="distributionreference" type="distributiondefinitionkey" minoccurs="0" <xs:element name="unit" type="timeunit" minoccurs="0" <xs:element name="value" type="xs:double" minoccurs="0" <xs:element name="modelnumber" type="modelnumber"/> <xs:complextype name="modelnumber"> <xs:extension base="resourcecharacteristic"> <xs:element name="value" type="xs:string" minoccurs="1" <xs:element name="serialnumber" type="serialnumber"/> <xs:complextype name="serialnumber"> <xs:extension base="resourcestatusparameter"> <xs:element name="value" type="xs:string" minoccurs="1" <xs:element name="horsepower" type="horsepower"/> <xs:complextype name="horsepower"> <xs:element name="value" type="xs:double" minoccurs="1" <xs:attribute name="unit" use="optional" type="powerunit"/> <xs:element name="controllertype" type="controllertype"/> <xs:complextype name="controllertype"> <xs:extension base="resourcecharacteristic"> <xs:element name="value" type="xs:string" minoccurs="1" <xs:element name="efficiencyrating" type="efficiencyrating"/> <xs:complextype name="efficiencyrating"> <xs:extension base="resourcecharacteristic"> <xs:element name="value" type="xs:double" minoccurs="1" <xs:element name="workpiececapacity" type="workpiececapacity"/> <xs:complextype name="workpiececapacity"> <xs:extension base="resourcecharacteristic"> <xs:element name="value" type="xs:integer" minoccurs="1" <xs:element name="employeecapacity" type="employeecapacity"/> <xs:complextype name="employeecapacity"> <xs:extension base="resourcecharacteristic">