An Architecture and Interfaces for Distributed Manufacturing Simulation. SIMULATION Transac
https://www.wendangku.net/doc/4c9517397.html,
SIMULATION
DOI: 10.1177/0037549705052326
2005; 81; 15 SIMULATION Charles McLean, Frank Riddick and Y. Tina Lee
An Architecture and Interfaces for Distributed Manufacturing Simulation https://www.wendangku.net/doc/4c9517397.html,/cgi/content/abstract/81/1/15
The online version of this article can be found at:
Published by:https://www.wendangku.net/doc/4c9517397.html,
On behalf of:
Society for Modeling and Simulation International (SCS)
can be found at:SIMULATION Additional services and information for https://www.wendangku.net/doc/4c9517397.html,/cgi/alerts Email Alerts: https://www.wendangku.net/doc/4c9517397.html,/subscriptions Subscriptions: https://www.wendangku.net/doc/4c9517397.html,/journalsReprints.nav Reprints:
https://www.wendangku.net/doc/4c9517397.html,/journalsPermissions.nav Permissions:
An Architecture and Interfaces for Distributed Manufacturing Simulation
Charles McLean Frank Riddick Y.Tina Lee
National Institute of Standards and T echnology (NIST)100Bureau Drive,Stop 8260Gaithersburg,MD 20899-8260charles.mclean@https://www.wendangku.net/doc/4c9517397.html,
This article presents an overview of a neutral reference architecture and data model for integrat-ing distributed manufacturing simulation systems with each other,with other manufacturing software applications,and with manufacturing data repositories.Other manufacturing software applications include but are not limited to systems used to design products,specify processes,engineer manu-facturing systems,and manage production.The architecture identi?es the software building blocks and interfaces that will facilitate the integration of distributed simulation systems and enable the in-tegration of those systems with other manufacturing software applications.The architecture builds on the High Level Architecture standard for simulation.The National Institute of Standards and T ech-nology and its collaborators have created several implementations of portions of the architecture using commercial off-the-shelf simulators.These implementations demonstrated the feasibility of the architecture and highlighted the need for a neutral data model for exchanging manufacturing data between simulations.
Keywords:Manufacturing simulation,information model,HLA,XML
1.Introduction
Scientists and engineers within the National Institute of Standards and Technology (NIST)Manufacturing Systems Integration Division of the Manufacturing Engineering Laboratory have developed an architecture for distributed manufacturing simulation in collaboration with represen-tatives from a number of outside organizations.The organi-zations were principally participants in the IMS MISSION project [1].MISSION is just one of many international,collaborative projects that have been conducted as part of the IMS Program.
The goal of MISSION was to integrate and utilize new,knowledge-aware technologies of distributed persistent data management,as well as conventional methods and tools,in var-ious enterprise domains,to meet the needs of globally distributed enterprise modelling and simulation.This will make available method-ologies and tools to support the de?nition of
||||
SIMULA TION,Vol.81,Issue 1,January 200515-32
?2005The Society for Modeling and Simulation International DOI:10.1177/0037549705052326
appropriate manufacturing strategies and the design of appropriate organizations and busi-ness processes.This goal will be achieved by establishing a modelling platform incorporat-ing engineering knowledge and project infor-mation that supports space-wise and control-wise design,evaluation and implementation over the complete enterprise life cycle.This will be the foundation stone for an architecture to support engineering co-operation across the value chain of the entire extended enterprise.[1,p.4–5]
NIST served as the U.S.regional coordinator for the IMS MISSION project.Participants on the U.S.MISSION team included NIST,the Defense Department’s Modeling and Simulation Of?ce,a number of U.S.simulation soft-ware vendors,universities,and Black and Decker.For fur-ther information on the overall IMS Program,see the IMS Web page at https://www.wendangku.net/doc/4c9517397.html,.For information on re-search conducted by IMS MISSION collaborators from the European and Japanese regions,see Rabe,Garcia de Gurtubai,and J?kel [2];Rabe and J?kel [3];Hibino and Fukuda [4];and Hibino et al.[5].Collaborators on the U.S.team jointly decided to focus on investigating two major
McLean,Riddick,and Lee
research issues:(1)the feasibility of using the U.S.Depart-ment of Defense(DoD)High LevelArchitecture(HLA)for distributed manufacturing simulation and(2)the develop-ment of manufacturing supply chain simulations.
Prototype simulations were developed under the IMS MISSION project that demonstrated that various combi-nations of the commercial simulators of the project team could be interconnected under the architecture to con-struct distributed simulations.The interconnection pro-cess was simpli?ed through the use of the NIST dis-tributed manufacturing simulation(DMS)adapter software [6].With the DMS adapter,the feasibility demonstrations were implemented with no changes to the internals of the commercial simulation engines.Time synchronization and data exchange were successfully demonstrated in several distributed supply chains simulation prototypes.Of the six different commercial off-the-shelf(COTS)simulation products used,each product was used in at least one imple-mentation.A key reason for developing the DMS adapter was to reduce the complexity in dealing with the HLA, which should foster greater use of distributed simulation technology in the manufacturing arena.
In the HLA,data interfaces are speci?ed in a federation object model(FOM).Early in this work,it was recog-nized that the traditional approach to developing a FOM would need to be changed if the HLA technology were to be adopted by the manufacturing industry.NIST staff rec-ommended that the Extensible Markup Language(XML) standards be used to encode data that would be exchanged between simulations in the future[7].MISSION project participants recognized the need for information models for these data,but due to limited time and resources,this aspect of the problem was not addressed.In a project initi-ated shortly after the completion of MISSION,NIST began working with collaborators on the development of neu-tral interfaces for exchanging manufacturing data between simulations and other applications.
NIST staff believe that standard interfaces could help reduce the costs associated with simulation model con-struction and data exchange between simulation and other software applications—and thus make simulation technol-ogy more affordable and accessible to a wide range of po-tential industrial users.Currently,small machine shops do not typically use simulation technology because of various dif?culties and obstacles associated with model develop-ment and data translation.Small shops typically do not have staff with the appropriate technical quali?cations re-quired to develop custom simulations of their operations or custom translators to import their data from other software applications.
NIST worked with a number of industrial partners and researchers to develop neutral formats for machine shop data to facilitate simulation and modeling activities.A ma-chine shop data model,as a neutral interface format,has been under development to support both NIST’s System In-tegration of Manufacturing Application(SIMA)program and the Software Engineering Institute’s(SEI’s)Tech-nology Insertion Demonstration and Evaluation(TIDE) program.SIMA supports NIST projects in applying in-formation technologies and standards-based approaches to manufacturing software integration problems[8].The TIDE program is sponsored by the Department of De-fense and SEI;it is currently engaged in a number of other projects with various small manufacturers in the Pittsburgh, Pennsylvania,area.The technical work is being carried out as a collaboration between NIST,SEI,Carnegie Mellon University,Duquesne University,the iTAC Corporation, and the Kurt J.Lesker Company(KJLC).
KJLC is an international manufacturer and distributor of vacuum products and systems to the research and in-dustrial vacuum markets.KJLC manufactures complete, automatically controlled vacuum systems with special em-phasis on custom-designed,thin-?lm deposition systems for research in alloys,semiconductors,superconductors, and optical and opto-electronics.A small machine shop is contained within the KJLC manufacturing facility.KJLC’s machine shop operation has been used to help de?ne the requirements for simulation modeling and data interface speci?cation activities described in this article.Their fa-cility will also be used as a pilot site for testing and eval-uation of the simulation models,neutral data interfaces, and other software developed under this TIDE project.For more information on KJLC,see https://www.wendangku.net/doc/4c9517397.html,.
The machine shop information model was developed with two goals in mind:(1)support for the integration of software applications at a pilot facility(KJLC’s ma-chine shop)and(2)promotion as a standard data inter-face for manufacturing simulators and possibly for other software applications.The information model is continu-ing to evolve based on experience and feedback from the KJLC’s implementation and from others involved in this effort.The information model provides a core set of data speci?cations that have applicability beyond the machine shop environment.Work on information modeling and the interface speci?cation continues today.
The objective of the information modeling effort is to develop a standardized,computer-interpretable represen-tation that allows for exchange of information in a ma-chine shop environment.The information model,when completed,must satisfy the following needs:support data requirements for the entire manufacturing life cycle,en-able data exchange between simulation and other manu-facturing software for machine shops,provide for the con-struction of machine shop simulators,and support testing and evaluation of machine shops’manufacturing software. Data structures contained within the information model include organizations,calendars,resources,parts,process plans,schedules,and work orders for machine shops.
The remainder of the article is organized as follows. Section2provides a summary of the architectural work completed as a part of MISSION.Issues concerning the distributed simulation architecture,the DMS adapter,and
16SIMULATION Volume81,Number1
ARCHITECTURE FOR DISTRIBUTED MANUFACTURING SIMULA TION
how HLA is related to this work are discussed.Section3 provides an overview of the information modeling and in-terface speci?cation activities that were undertaken after MISSION as a part of the NIST SIMA and SEI TIDE pro-grams.In this section,issues relating to the modeling tools and methodologies used are also discussed.In section4,a synopsis of the information described in this article is pre-sented,along with a discussion of possible future research activities related to this work.
2.Distributed Manufacturing Simulation Architecture
This document takes a broad view of DMS.Normally,a DMS may be thought of as a manufacturing simulation that is composed of multiple software processes that are independently executing and interacting with each other. Together,these simulation software processes may model something as large as a manufacturing supply chain down to something as small as an individual piece of industrial machinery.Different software vendors may have devel-oped the basic underlying simulation software.The mod-ules may run on different computer systems in geograph-ically dispersed locations.The simulation may be dis-tributed to take advantage of the functionality of a speci?c vendor’s products,protect proprietary information associ-ated with individual system models,and/or improve the overall execution speed of the simulation through the use of distributed computer processing.
DMS may also refer to a distributed computing environ-ment where nonsimulation manufacturing software appli-cations are running and interacting with one or more sim-ulation systems.Engineering systems may interact with simulation systems through service requests.That is,they submit data to a simulator for evaluation.For example,a computer-aided manufacturing application that has gener-ated a control program for a machine tool may submit that program to a simulator to verify that it is correct.
Another view of DMS is a computer environment composed of multiple,functional modules that together form what today is commonly a single simulation system. Such an environment may include model-building tools, simulation engines,display systems,and output analysis software.
2.1Why Build Distributed Manufacturing Simulation Systems?
A distributed approach increases the functionality of sim-ulation.For example,it could be used to
1.model supply chains across multiple businesses
where some of the information about the inner work-
ings of each organization may be hidden from other
supply chain members;
2.simulate multiple levels of manufacturing systems
at different degrees of resolution such that lower
level simulations generate information that feeds
into higher levels;
3.model multiple systems in a single factory with dif-
ferent simulation requirements such that an individ-
ual simulation-vendor’s product does not provide the
capabilities to model all areas of interest;
4.allow a vendor to hide the internal workings of a
simulation system through the creation of runtime
simulators with limited functionality;
5.create an array of low-cost,runtime simulation mod-
els that can be integrated into larger models;
6.take advantage of additional computing power,spe-
ci?c operating systems,or peripheral devices(e.g.,
virtual reality interfaces)afforded by distributing
across multiple computer processors;
7.provide simultaneous access to executing simulation
models for users in different locations(collaborative
work environments);
8.offer different types and numbers of software li-
censes for different functions supporting simulation
activities(model building,visualization,execution,
analysis).
The next section outlines the role that software architec-tures will play in enabling the development of distributed manufacturing simulations.
2.2Software Architecture
In their book Software Architecture:Perspectives on an Emerging Discipline,Mary Shaw and David Garlan[9] explain the signi?cance of software architectures: As the size and complexity of software sys-
tems increase,the design and speci?cation of
overall system structure become more signif-
icant issues than the choice of algorithms and
data structures of computation.Structural is-
sues include the organization of a system as
a composition of components;global control
structures;the protocols for communication,
synchronization,and data access;the assign-
ment of functionality to design elements;the
composition of design elements;physical dis-
tribution;scaling and performance;dimen-
sions of evolution;and selection among de-
sign alternatives.This is the software archi-
tecture level of design.(p.1–2)
A distributed manufacturing simulation architecture is needed to address the integration problems that are cur-rently faced by software vendors and industrial users of simulation technology.Neutral simulation interfaces
Volume81,Number1SIMULATION17
McLean,Riddick,and Lee
would help reduce the cost of data importation and model sharing and thus would make simulation technology more affordable to users.The de?nition of a neutral architecture for distributed manufacturing simulation is the?rst step toward identifying the information models,interfaces,and protocols for integrating these systems.
This step can be achieved by decomposing the dis-tributed manufacturing simulation architecture into three major functional views:distributed computing systems, simulation systems,and manufacturing systems.Each ar-chitectural view de?nes a set of system elements,data mod-els,and interface speci?cations for integrating distributed manufacturing simulations.Aspects of each view are in-terrelated to and interconnected with aspects of the other views.The views can be thought of as three sides of a cube.
2.3Distributed Computing Systems View
This architectural view is concerned primarily with simu-lation as a set of computers and software processes that are simultaneously executing and communicating with each other across a computer network.This view also addresses issues pertaining to the general management and integra-tion of the software applications that are used to generate models and data for the simulations.The fact that the soft-ware processes are simulations or simulation related is not particularly critical in this view.This view is not concerned with simulation or manufacturing data content.
This view provides the infrastructure that allows us to implement simulation development and execution en-vironments as distributed systems.Elements of this view include hardware computing platforms,operating systems,distributed computer processes,integration in-frastructures,process initialization and synchronization, software development environments(including but not limited to editors,compilers,system build utilities,debug-gers,source code,general subroutine and header libraries, runtime modules,and system test data),communications systems,information models and data dictionaries,work ?ow management systems,database management systems and databases,product data management systems,version control and con?guration management,computer?le sys-tems and?les,system installation and maintenance utili-ties,computer security and data protection services,license veri?cation systems,and World Wide Web access mecha-nisms.It also includes various input and output peripheral devices such as digital cameras,scanners,monitors,pro-jection displays,printers,and virtual reality interfaces.
There are?ve major clusters of information systems that are relevant to the distributed manufacturing sim-ulation problem:(1)software development systems;(2) design,engineering,production planning,and simulation model development systems;(3)distributed manufacturing simulation execution systems;(4)manufacturing manage-ment,control,production,and support systems;and(5) distributed manufacturing data repository systems.
Figure1groups these systems into four computing en-vironments and a shared,common data repository.The ?gure presents a logical grouping of system elements.Un-doubtedly,each implementation of this architecture will be based on different information systems and physical con-?gurations.The major elements of the?gure are described brie?y below.
The software development environment is used to de-velop simulation engines,visualization systems,integrat-ing infrastructures,and other software applications.It is not the central focus of the architecture and will not be ad-dressed in this article.The design,engineering,production planning,and simulation model development environment contains the systems that generate models and data used by simulation and manufacturing itself.It is described in further detail below.The distributed manufacturing simu-lation execution environment contains simulation engines executing models,visualization systems,and infrastruc-ture systems to manage and integrate those simulations. The manufacturing management,control,production,and support systems environment is made up of the“real”sys-tems that are used to run and perform the manufacturing operations.
There are?ve component elements of the design,engi-neering,production planning,and simulation model devel-opment environment:(1)product design applications and tool kits,(2)manufacturing engineering applications and tool kits,(3)production management applications and tool kits,(4)simulation model development applications and tool kits,and(5)work?ow management systems.In this environment,the work?ow management system provides the integrating infrastructure.It manages and sequences activities within the applications and tool kits that gener-ate manufacturing models and data.Tool kits are tightly coupled suites of applications that work together to per-form a related set of functions.Tool kits may be manually driven or more automated expert systems.
Product design applications may include conceptual and detailed design,solid modeling,bill of materials genera-tion,design handbooks,parts catalogs,and various anal-ysis tools.Some manufacturing engineering applications may include process planning and process speci?cation, plant layout,machine tool programming,time standards development,line balancing,and tool and?xture design. Production management applications may include man-ufacturing resource planning,batch and lot sizing,and scheduling applications.Simulation model development tools include functions such as?owcharting,diagramming, model de?nition,and user-level programming.
A communications network connects environments with each other and the manufacturing data repository.The repository is a consolidation of the various data stores and management systems that are used by the various infor-mation systems environments.It logically integrates the ?le systems,Web pages,databases,and libraries used for the storage of data by design,engineering,production
18SIMULATION Volume81,Number1
ARCHITECTURE FOR DISTRIBUTED MANUFACTURING SIMULA TION
Figure1.Relationships between the major elements of the distributed manufacturing simulation(DMS)architecture
planning,real manufacturing systems,simulation model development,and executing distributed manufacturing simulations.In different implementations of the architec-ture,the repository may reside on a single computer sys-tem or a?le server or be geographically distributed across a network.
The distributed manufacturing data repository may in-clude the following types of data stores and manage-ment systems:computer?le systems,Web pages and ?les,object-oriented database management systems,re-lational database management systems,special-purpose library management systems,and source-code control systems for software.A common data access interface mechanism will be used to simplify access to the data repository by all software environments and applications within those environments.References to documents in the data repository may be speci?ed as Uniform Resource Locators(URLs)(see[10]).This will allow the identi?-cation of documents,both remotely and locally stored us-ing the well-established,standard,World Wide Web access mechanism.
Figure2shows a decomposition of the distributed man-ufacturing data repository into its component elements. All of the types of data stores indicated in the?gure do not necessarily have to be included in an implementation of the architecture.In the future,additional data manage-ment schemes and data stores may be added to the repos-itory structure.From this point forward in this document, the distributed manufacturing data repository and common data access mechanism will be treated and represented as
a single module.
2.4Simulation Systems View
This architectural view is concerned with the speci?cs of building,initializing,running,observing,interacting with, and analyzing simulations.In this view,simulation sys-tems,tools,and supporting applications should be viewed generically(i.e.,independent of the manufacturing do-main).The same system elements could be used for simu-lating other problem domains.Major elements of this view include simulation coordination and management,visual-ization systems,manufacturing data preparation and model development tools,simulation models,discrete event and process simulation engines,component module and tem-plate libraries,mathematical and analytical models,input distributions,timing and event calendars,and output anal-ysis tools.
Figure3illustrates the relationship between the various elements of the distributed manufacturing simulation exe-cution environment.The integration infrastructure for this environment,the runtime infrastructure(RTI),is based on the U.S.Department of Defense HLA,developed by the Defense Modeling and Simulation Of?ce(DMSO)[11]. The HLA was developed by DMSO to provide a consis-tent approach for integrating distributed defense simula-tions.Several implementations of the HLA RTI software are currently available from different sources.There is, however,no interoperability across RTI implementations.
A distributed simulation running on different computer sys-tems across a network must use the same RTI software as an integration infrastructure.
An HLA-based distributed simulation is called a federa-tion.Each simulator,visualization system,real production system,or output analysis system that is integrated by the HLA RTI is called a federate.One common data de?nition is created for domain data that are shared across the entire federation.It is called the FOM.Each federate has a sim-ulation object model that de?nes the elements of the FOM that it implements.
Volume81,Number1SIMULATION19
McLean,Riddick,and Lee
Figure2.Decomposition of the distributed manufacturing data repository
Figure3.Distributed manufacturing simulation environment elements integrated by the High Level Architecture(HLA)runtime infrastructure
20SIMULATION Volume81,Number1
ARCHITECTURE FOR DISTRIBUTED MANUFACTURING SIMULA TION
A DMS adapter module is incorporated into each DMS federate.The DMS adapter will handle the transmission, receipt,and internal updates to all FOM objects used by a federate.The DMS adapter module will contain a subrou-tine interface and data de?nition?le that will facilitate its use as an integration mechanism by software developers. The goal of the DMS adapter is to ease the development of distributed manufacturing simulations by reusing imple-mentations for some of the necessary housekeeping and administrative work.The DMS adapter provides a simpli-?ed time management interface,automatic storage for lo-cal object instances,management of lists of remote object instances of interest,management and logging for inter-actions of interest,and simpli?ed object and interaction ?ltering.
Several functions may be needed for the proper opera-tion of a distributed simulation that are logically outside of any one simulation federate.In the distributed manufactur-ing simulation environment,the manufacturing simulation federation manager is the architectural element that pro-vides these functions.It may implement functionality to execute initialization scripts that launch federates,to pro-vide initialization data to federates,to assist in federation time management,and to provide a user interface so that users can monitor and manipulate the federation and invoke federation services.
2.5Manufacturing Systems View
This architectural view is concerned with modeling the behavior and data of speci?c manufacturing organizations and systems,from the supply chain down to individual machines on the factory?oor.Major elements of this view include but are not limited to
1.manufacturing organizational templates and struc-
tures,as well as business process and organizational
models;
2.supply chain systems—re?neries,mills,factories,
warehouses,distributors,transportation systems,
wholesalers,retailers,customers;
3.manufacturing facility departments,areas,and
subsystems—design,engineering,procurement,?-
nance,production shops,work cells,production
lines,workstations,inventory storage areas,ship-
ping and receiving;
4.production resources and support equipment—
machine tools,inspection equipment,material han-
dling systems,storage buffers,robots,workers;
5.tools and materials—cutting tools,hand tools,jigs
and?xtures,consumables,components,part blanks,
sheet and bar stock,work-in-process inventory;
6.manufacturing information systems—design,engi-
neering,production planning and scheduling,tool
management,shop?oor data collection systems;
7.manufacturing documents and data—work?ow pat-
terns,orders,jobs,product data,part designs,pro-
cess plans,production calendars,schedules,layouts,
and other reference data(machinability data,statis-
tical distributions).
Different manufacturers will create different supply chain organizations and arrangements of systems within each or-ganization.The DMS architecture must be?exible enough to allow these different system con?gurations but still en-able increased integration.As such,the architecture does not mandate a particular manufacturing organization.It does require the development and speci?cation of one DMS FOM.
Many objects in the FOM may reference documents containing more detailed information that are stored in a ?le system,PDM system,or database.An example of such a document might be a part design?le or a process plan. The XML can be used to de?ne new document types[12]. XML allows for the de?nition of data that have semantic information in addition to the data values.A variety of schema languages can be used to to de?ne new document formats.Advantages of this approach include
?the set of supported document types can be easily ex-
tended;
?each individual document format can be easily modi?ed;
?COTS tools are available to implement creation,parsing,
interpreting,and displaying the documents;
?XML documents from other sources can easily be sup-
ported;
?different instances of?le structures may be created to con-
vey the same semantic information;
?XML-enabled browsers can intelligently display the data;
?semantic validation of the?les is possible.
There are potentially many document types that will be stored as distributed manufacturing simulation data.Some of these document types have widely accepted or standard-ized formats.Examples of these include the many kinds of CAD?les(DXF,IGES,etc.),image?les(GIF,TIFF,BMP, etc.),and executables(EXE,com,bat,dll,etc.).However, many manufacturing documents do not have a standard-ized format.Schedules,bills of materials(BOMs),and process plans are examples of such documents.While it is easy to come up with acceptable representations for such data that are appropriate for short-term use,it is highly likely that these representations will need modi?cations, possibly major modi?cations,over time.A mechanism is needed to allow the de?nition of extensible formats for new document types without adversely affecting the rest of the DMS architecture or interfaces.XML can be that mechanism.Schemas for the different document formats
Volume81,Number1SIMULATION21
McLean,Riddick,and Lee
must be stored in and uniquely accessible from the DMS data repository.An initial set of document formats should be developed and allowed to expand over time as the need arises.
2.6Integration via DMS Adapter and the HLA/RTI In the discussion and diagrams below,the changes neces-sary for integrating a legacy simulation into a distributed simulation using the HLA and the DMS adapter will be discussed.The term legacy simulation is used to indicate a manufacturing-oriented or general-purpose discrete event simulation tool that does not have native support for the HLA or DMS adapter technologies.Such systems are typ-ically created using COTS simulation software packages. They may also be created from scratch using a combi-nation of general-purpose and special-purpose computer programming languages.
2.6.1Simpli?ed Simulation Execution
Architecture
In Figure4,a simpli?ed view of a nondistributed legacy simulation application is shown.It consists of a simulation execution system executing a simulation model.The simu-lation model is a behavior-oriented description of the log-ical system that is to be simulated.Simulation execution systems often support the visualization of the executing model and statistical reporting of the simulated events that are generated during execution.Data that are needed as input to or that are generated by the executing simulation are maintained in the persistent data store.
2.6.2Integration Using the HLA/RTI
Figure5shows the architecture of a legacy simulation that has been integrated into a distributed simulation using the HLA.On the right side of the diagram,a simpli?ed view of the HLA architecture is presented(constructs or con-cepts that are beyond the scope of this presentation have been left out for brevity).The FOM is a description of the data that can be exchanged between federates.The FOM is usually different for each distributed simulation that is developed.The RTI Ambassador implements the interface through which federates send information to the RTI.This interface contains methods that provide the capability to manage federation creation,manage object class de?ni-tions,manage information exchange using objects and in-teractions,and manage the advancement of time for the federation.
While the RTI Ambassador provides the mechanism for sending information to the RTI,an implementation of the Federate Ambassador interface is necessary to be able to receive information from the RTI.The Federate Ambas-sador is an interface that contains methods that de?ne how the RTI sends information to a federate asynchronously in response to changes in the state of the federation.These state changes may be in response to calls to the methods
Figure4.Simpli?ed view of a typical legacy simulation system
Figure5.Legacy simulation integration using the High Level Architecture(HLA)/runtime infrastructure(RTI)
on the RTI Ambassador interface made by any federate in the federation.An implementation of the Federate Ambas-sador interface is not provided with the RTI software.The rules of the HLA require that an implementation of the Federate Ambassador be provided by the legacy simula-tion.Furthermore,this implementation must be consistent with the information de?ned in the FOM that is being used in this federation.
22SIMULATION Volume81,Number1
ARCHITECTURE FOR DISTRIBUTED MANUFACTURING SIMULA TION
2.6.3HLA/RTI Integration Issues
Since legacy simulation systems are not designed to be used with the HLA/RTI,code must be developed to adapt the legacy simulation system for such purposes.Normally, this code is complex.In addition,although some of the code can be reused,a signi?cant amount of code will need to be added or modi?ed for each distributed simulation that is developed.In the rest of this section,some of the important issues related to the complexity and reusability of the adaptation code are discussed.
RTI interface complexity.There are roughly120meth-ods in the RTI Ambassador interface and40methods in the Federate Ambassador interface.Depending on the cur-rent state of the RTI,the federation,and the data that are de?ned in the FOM,invoking a method can cause vastly different outcomes to occur.While the richness of the RTI’s interfaces provides for an extremely?exible simulation in-tegration approach,a side effect is that the learning curve for understanding these interfaces is quite high.
The RTI’s implicit invocation architecture.The archi-tecture of the RTI is based on what is called an“implicit invocation architecture.”In this approach,a federate can modify the state of the federation by invoking methods of the RTI Ambassador https://www.wendangku.net/doc/4c9517397.html,rmation relating to changes in the state of the federation is passed back as asyn-chronous callbacks to methods in the FederateAmbassador that was implemented by the federate.While this is an ef?-cient and?exible approach,it makes adapting legacy simu-lation dif?cult because legacy simulations usually provide only procedurally oriented mechanisms for integration.
Inadequate integration mechanisms are provided by the legacy simulations.To use the interfaces of the RTI,some adaptation code must be written using a language sup-ported by one of the RTI language mappings.Mappings currently exist for languages such as C,C++,Java,and CORBA IDL[13].While some simulation systems provide mechanisms to call functions written in such languages na-tively,many do not.Integrating those legacy simulations usually requires a combination of proprietary language code,?le input/output,and socket programming,depend-ing on which mechanisms are provided.This situation in-creases the complexity of developing and maintaining the adaptation code.
Cooperative time management.In distributed simula-tions in which federates must cooperatively manage the advancement of time,the legacy simulation must be mod-i?ed to cede some of the control over the advancement of time where previously it had complete control.Because the RTI provides multiple mechanisms for coordinating time advancement,choosing the appropriate mechanism and properly implementing the adaptation code to support it can require signi?cant forethought and development.
Storage and maintenance for instances of FOM objects. Many legacy simulations have internal representations for entities such as parts or machines,and these simulations can maintain the information about such entities as they are created during a simulation execution.The de?nitions of these entities will differ between different legacy sim-ulations.To enable the exchange of data relating to these entities,neutral representations of these entities are usu-ally de?ned in the FOM as object classes and associated attributes.However,the HLA/RTI provides no mechanism for storing object class instances.It only provides for stor-age of information related to the owner of a particular ob-ject instance,the class of the instance,and the attributes that are associated with an instance.Therefore,storage for instances of FOM objects must be provided by the legacy simulation.This is in addition to whatever storage has been set aside to maintain the legacy simulation’s internal repre-sentation of an object.Adaptation code to maintain FOM object storage and to coordinate state changes between the internal representations and the FOM representations of objects must be developed.
2.6.4Integration Using the DMS Adapter
In the previous section,some of the issues that are related to integrating legacy simulations using just the facilities of the HLA were discussed.It shows that developing the Fed-erate Ambassador and adaptation code can be a signi?cant undertaking when developing a distributed simulation,and this effort must be repeated for each legacy simulation that is to be integrated.
Figure6shows the architecture of a legacy simulation that has been integrated into a distributed simulation using the DMS adapter.Instead of having legacy simulations in-tegrated directly with the HLA/RTI,those simulations will interact with the interface of the adapter.The goal of the adapter is to provide a simpli?ed method for integrating legacy simulations into distributed simulations while also providing as much of the capabilities of the HLA/RTI as possible.The reader should note that simpli?ed does not imply simple.Adaptation code must still be developed to integrate a legacy simulation system with the DMS adapter. However,by reducing the complexity of the interface to which the legacy simulation is being integrated,the level of effort for performing the integration should be greatly reduced.
2.6.5Architectural Goals for the DMS Adapter What follows is a list of design goals for the architecture of the DMS adapter.If met,implementing distributed simula-tions using the DMS adapter should be simpler than when using the approach that was depicted in Figure5.
Reduce interface complexity.The interface of the adapter will have approximately35methods instead of the120methods with40callbacks de?ned by the RTI and Federate Ambassadors.
Remove Federate Ambassador implementation issues from the legacy simulation.Legacy simulations will not
Volume81,Number1SIMULATION23
McLean,Riddick,and Lee
Figure6.Integrating simulations using the distributed manufacturing simulation(DMS)adapter
have to develop Federate Ambassador implementations. The adapter will implement a federate ambassador and use it to receive information from the RTI.
De?ne an interface that facilitates integration with pro-cedurally oriented legacy simulations.The results of in-voking most of the methods in the adapter’s interface will be returned immediately to the legacy https://www.wendangku.net/doc/4c9517397.html,rma-tion that must be passed back asynchronously to a federate will be stored in a message queue in the adapter associated with that federate.This includes information that is gener-ated by the activities of other federates in the federation. The adapter will provide the storage for this information and provide methods to access this information upon re-quest from the legacy simulation.
Minimize the impact of changes to the information model through the development of generic FOM objects that contain XML document fragments.To overcome the problem of having to develop different FOMs for each dis-tributed simulation con?guration,the information about the classes and attributes for the objects that are to be ex-changed will not be de?ned in the FOM.A generic object class will be de?ned in the FOM,and instances of this object will be exchanged between federates.This generic FOM object class will have an attribute of type string that is meant to hold an XML document fragment.The infor-mation will de?ne the semantic content for the object.The XML document fragment is the information that will be passed to the legacy simulation.The generic FOM object class will also contain information about the type of data contained in the XML document fragment.This will fa-cilitate?ltering and routing of object updates by the RTI. There are?ve major bene?ts to this approach:
1.Only one FOM needs to be developed for use with
the DMS adapter.
2.Only one implementation of the Federate Ambas-
sador needs to be developed for use with the DMS
adapter.
3.The DMS adapter does not have to be modi-
?ed and recompiled for each distributed simulation
con?guration.
4.The information model(the de?nition of the entities,
attributes,and messages that will be exchanged be-
tween simulations)can be changed without chang-
ing the FOM,FederateAmbassador implementation,
or the DMS adapter implementation.
5.Implementations of mechanisms for manipulating
XML data are widely available and can be used in
the development of both the DMS adapter and the
adaptation code for legacy simulations.
Maintain storage for the objects that are to be ex-changed between simulations.As discussed in a previous section,the de?nition of an object(class and associated at-tributes)that is to be exchanged between simulations will differ from the internal de?nition that each simulation sup-ports for that object.Since each legacy simulation only
24SIMULATION Volume81,Number1
ARCHITECTURE FOR DISTRIBUTED MANUFACTURING SIMULA TION
provides storage for its internal objects and the RTI pro-vides no mechanism for the storage of objects,storage and maintenance for the objects that are to be exchanged must be provided.The DMS adapter will provide this capability.
Each adapter will provide methods that allow a legacy simulation to create,modify,and delete objects that can be shared with other federates in the federation.Objects will have“owners,”and ownership will be granted initially to the adapter(and associated legacy simulation)that cre-ated it.Ownership is required for modi?cation or deletion operations on an object to succeed.Storage for“owned”objects will be provided by the DMS adapter that owns the object.In addition,storage for copies of objects owned by other DMS adapters will be provided.Each DMS adapter will use the services of the RTI to distribute object update information for the objects it owns and will incorporate object update information it receives about objects owned by other DMS adapters.In this way,the DMS adapters in the federation can work cooperatively to maintain up-dated information about all the objects in the federation, without the direct intervention of their associated legacy simulations.
Simplify time coordination.The RTI provides a multi-tude of time synchronization methods that are extremely ?exible and powerful but are also quite complicated.The adapter implements a“time-stepped”synchronization ap-proach.DMS adapter methods are provided to declare that the associated legacy simulation wishes to advance to a cer-tain simulation time and to check if it is okay to advance to this time.When the DMS adapter indicates to the legacy simulation that it is okay to advance,the legacy simula-tion can then“simulate”from its current simulation time to the new simulation time that it requested.It can then use the other methods in the DMS adapter interface to get information about what was going in the rest of the federa-tion while it was executing its“simulation step.”When all of the simulations use this method,the functionality of the RTI’s time management services ensures that the collective advancement of all of the simulations proceeds properly.
While meeting the architectural goals for developing the DMS adapter will provide a mechanism for exchanging in-formation between manufacturing simulation applications, for meaningful information exchange to take place,the se-mantic content of the information to be exchanged must be de?ned.In the next section,the development of an infor-mation model that de?nes the semantics for the meaningful exchange of manufacturing simulation-related information is discussed.
3.Manufacturing Simulation Interface
Speci?cations
An information model provides a sharable,stable,and or-ganized representation of information in a selected do-main area.The Integrated Computer Aided Manufacturing (ICAM)De?nition Language1Extended(IDEF1X),EX-PRESS,Uni?ed Modeling Language(UML),and XML are most often used by the manufacturing enterprises for information modeling.IDEF1X is a formal graphical lan-guage for relational data modeling,developed by the U.S. Air Force[14].EXPRESS[15]was designed to meet the needs of the STandard for the Exchange of Product model data,commonly called STEP[16],and it has been used in a variety of other“large-scale”modeling applications.UML is a graphic representation for artifacts in software systems, and is also useful for database design[17].XML is a for-mat for structured documents,and it helps make possible information exchange in a globally distributed computing environment[18].
Section3.1provides an overview of the concept behind the machine shop information model.Section3.2explains the constructs used to de?ne the information model,as well as how the model will be used,and gives some detailed examples of a small portion of the model.
3.1Concept for the Data Model
In this section,the concept of the shop information model is introduced from the user perspective.The primary ob-jective was to develop a structure for exchanging shop data between various manufacturing software applications,in-cluding simulation.The idea was to use the same data struc-tures for managing actual production operations and sim-ulating the machine shop.The rationale was that if one structure can serve both purposes,the need for translation and abstraction of the real data would be minimized when simulations are constructed.The mapping of real-world data into simulation abstractions is not,for the most part, addressed in the current data model.
Maintaining data integrity and minimizing the dupli-cation of data are important requirements.For this reason, each unique piece of information appears in only one place in the model.Cross-reference links are used to avoid the creation of redundant copies of data.The machine shop data model contains20major elements.Each major data element is italicized in the discussion that follows.The data elements are called organizations,calendars,resources, skill de?nitions,setup de?nitions,operation de?nitions, maintenance de?nitions,layout,parts,bills of materials, inventory,procurements,process plans,work,schedules, revisions,time sheets,probability distributions,references, and units of measurement.Figure7illustrates some of the major elements of the conceptual data model and their rela-tionships to each other.Due to space limitations,the entire model is not shown or discussed in detail.For more de-tailed information on the model,see McLean et al.[19]. The remainder of this section discusses the data elements and their signi?cance.
Perhaps a good place to start the discussion of the data model is with the customer.Machine shops are businesses. They typically produce machined parts for either internal or external customers.Data elements are needed to main-tain information on customers.The types of organizational
Volume81,Number1SIMULATION25
McLean,Riddick,and Lee
Figure7.Concept for the machine shop data model
information that is needed about customers are very similar to the data needed about suppliers that provide materials to the shop.The same types of organizational data are also needed about the machine shop itself.For this reason,an organizations element was created to maintain organiza-tional and contact information on the shop,its customers, and its suppliers.
Organizations can be thought of as both a phone book and an organization chart.The element provides subele-ments for identifying departments,their relationships to each other,individuals within departments,and their con-tact information.Various other types of information need to be cross-referenced to organizations and contacts within the structure(e.g.,customer orders,parts,and procure-ments to suppliers).
The operation of the machine shop revolves around the production of parts(i.e.,the fabrication of parts from raw materials such as metal or plastic).The raw materials typ-ically come in the form of blocks,bars,sheets,forgings, or castings.These materials are themselves parts that are procured from suppliers.The parts data element was cre-ated to maintain the broad range of information that is needed about each part that is handled by the machine shop.Part data include an identifying part number,name, description,size,weight,material composition,unit of is-sue,cost,group technology classi?cation codes,and revi-sion(change)data.Cross-reference links are needed for the customers who buy the parts from the shop and/or the suppliers that provide them as raw materials.Links are also needed for other data elements,documents,and?les that are related to the production of parts,including part spec-i?cation documents,geometric models,drawings,bills of materials,and process plans.
The bills-of-materials element is basically a collection of hierarchically structured parts lists.It is used to de?ne the parts and subassemblies that make up higher level part assemblies.A bill of materials identi?es,by a part num-ber reference link,the component or subassembly required at each level of assembly.The quantity required for each part is also indicated.Cross-references links are needed between parts that are assemblies and their associated bill of materials.
The parts and bills-of-materials elements establish the basic de?nition of parts produced or used by the shop.An-other element,inventory,is used to identify the quantity of part instances at each location within the facility.Inven-tory data elements are provided for parts,tools,?xtures, and materials.Materials are de?ned as various types of stock that may be partially consumed in production(e.g., sheets,bars,and rolls).Structures are provided within in-ventory to keep track of various stock levels(e.g.,reorder point level)and the speci?c instances of parts that are used in assemblies.
The procurements element identi?es the internal and external purchase orders that have been created to satisfy order or part inventory requirements.Cross-reference links
26SIMULATION Volume81,Number1
ARCHITECTURE FOR DISTRIBUTED MANUFACTURING SIMULA TION
are de?ned to parts to identify the speci?c parts that are being procured and to work to indicate which work items they will be used to satisfy.
The work data element is used to specify a hierarchi-cal collection of work items that de?ne orders,production, and support activities within the shop.Support activities include maintenance,inventory picking,and?xture/tool preparation.Work is broken down hierarchically into or-ders,jobs,and tasks.
Orders may be either customer orders for products or internally generated orders to satisfy part requirements within the company(e.g.,maintenance of inventory lev-els of stock items sold through a catalog).Orders contain both de?nition and status information.De?nition informa-tion speci?es who the order is for(i.e.,customer cross-references),its relative priority,critical due dates,what output products are required(a list of order items,i.e.,part references and quantities required),special resource re-quirements,precedence relationships on the processing of order items,and a summary of estimated and actual costs. Order items are also cross-referenced to jobs and tasks that decompose the orders into individual process steps performed at workstations within the shop.Status infor-mation includes data about scheduled and actual progress toward completing the order.
Jobs typically de?ne complex production work items that involve activities at multiple stations and ultimately produce parts.Tasks are lower level work items that are typically performed at a single workstation or area within the shop.
The process plans element contains the process speci?-cations that describe how production and support work is to be performed in the shop.Major elements contained within process plans include routing sheets,operation sheets,and equipment programs.Routing and operation sheets are the plans used to de?ne job-and task-level work items,re-spectively,in the work hierarchy.These process plans de-?ne the steps,precedence constraints between steps,and resources required to produce parts and perform support activities.Precedence constraints de?ned in a process plan are used to establish precedence relationships between jobs and tasks.Equipment program elements establish cross-reference links to?les that contain computer programs that are used to run machine tools and other programmable equipment that process speci?c parts.Each part in the parts element contains cross-reference links to the process plans that de?ne how to make that part.Jobs and tasks contain links back to the process plans that de?ned them.
The resources element is used to de?ne production and support resources that may be assigned to jobs or tasks in the shop,their status,and scheduled assignments to speci?c work items.The resource types available in the machine shop environment include stations and machines,cranes, employees,tool and tool sets,?xtures,and?xture sets.
The skill de?nitions,setup de?nitions,operations de?-nitions,maintenance de?nitions,and time sheets elements provide additional supporting information associated with resources.Skill de?nitions lists the skills that an employee may possess and the levels of pro?ciency associated with these skills.Skills are referenced in employee resource re-quirements contained in process plans.Setup de?nitions typically speci?es tool or?xture setups on a machine. Tool setups are typically the tools that are required in the tool magazine.Fixture setups are work-holding devices mounted on the machine.Setups may also apply to cranes or stations.Operation de?nitions speci?es the types of op-erations that may be performed at a particular station or group of stations within the shop.Maintenance de?nitions speci?es preventive or corrective maintenance to be done on machines or other maintained resources.Time sheets is used to log an individual employee’s work hours,leave hours,overtime hours,and so on.
The layout element de?nes the physical locations of re-source objects and part instances within the shop.It also de?nes reference points,area boundaries,paths,and so forth.It contains references to external?les that are used to further de?ne resource and part objects using appro-priate graphics standards.Cross-references links are also provided between layout objects and the actual resources that they represent.
Schedules and calendars data elements are used to deal with time.Schedules provides two views of the planned assignment of work and resources.Work items(orders, jobs,and tasks)are mapped to resources,and conversely, resources are mapped to work items.The planned time events associated with those mappings are also identi?ed (e.g.,scheduled start times and end times).Calendars iden-ti?es scheduled workdays for the shop,the shift schedules that are in effect for periods of time,planned breaks,and holiday periods.
The four remaining major data elements are revisions, references,probability distributions,and units of measure-ment.The revisions element is used repeatedly throughout many levels of the data model.It provides a mechanism for identifying versions of subsets of the data,revision dates, and the creator of the data.The references element identi-?es external digital?les and paper documents that support and further de?ne the data elements contained within the shop data structure.It provides a mechanism for linking to outside?les that conform to various other format spec-i?cations or standards(e.g.,STEP part design?les).The probability distributions element de?nes probability distri-butions that are used to vary processing times,breakdown and repair times,availability of resources,and so on.Dis-tributions may be cross-referenced from elsewhere in the model(e.g.,equipment resources maintenance data).Units of measurement speci?es the units used in the?le for vari-ous quantities such as length,weight,currency,and speed.
The next section provides a detailed illustration of a small portion of the overall data model,as well as UML and XML?le structures.
Volume81,Number1SIMULATION27
McLean,Riddick,and Lee
3.2Speci?cation of the Information Model
An information model is a representation of concepts,rela-tionships,constraints,rules,and operations to specify data semantics for a chosen domain of discourse.The advantage of using an information model is that it can provide a share-able,stable,and organized structure of information re-quirements for the domain context.An information model serves as a medium for transferring data among computer systems that have some degree of compliance with this information model.For proprietary data,implementation-speci?c arrangements can be made when transferring those data[20].
In general,the contents of an information model include a scope,a set of information requirements,and a speci?https://www.wendangku.net/doc/4c9517397.html,rmation requirements serve as the foundation of the speci?cation of the information model.A thorough requirements analysis is a necessity.The initial goal for the machine shop information model is to support data transferring needed for KJLC’s machine shop operations. This information model,ultimately,will be promoted as a standard data interface to be used by other machine shops. Thus,the completeness and correctness of the information requirements and a consensus on the data requirements from the industry are also important issues.
The speci?cation of the information model de?nes ele-ments,attributes,constraints,and the relationship between elements for the domain context.The speci?cation should be laid out using some formal information modeling lan-guage.An information modeling language provides a for-mal syntax that allows users to unambiguously capture data semantics and constraints.Three types of methods that im-plement information models are currently used by the man-ufacturing community:
?Data transfer via a working form,which is a structured,in-
memory representation of data.The method uses a mech-
anism that accesses and changes data sequentially without
actually moving the data around.All shared data are stored
in memory.
?Data transfer via an exchange?le,which is a?le with
a prede?ned structure or format.This method requires a
neutral?le format for storing the data.The application
systems read and write from?les.
?Data transfer using a database management system.This
method uses a database management system where infor-
mation is mapped onto and retrieved from databases.
These implementation methods can be accomplished through translators that are developed using programming languages and database management systems.The selec-tion of an implementation method is heavily dependent on the target environment where the application system resides.While the relational database is generally desir-able for data transfer,the traditional?le-oriented sys-tems are being used continually by many manufacturing applications.
A speci?cation for the machine shop information model has been developed based on the data model concept de-scribed in section3.1.The shop data element,the top-level element in the model,is represented by an identi?er and a number.Optional elements include type,name,descrip-tion,reference keys,revisions,units of measurement,or-ganizations,calendars,resources,skill de?nitions,setup de?nitions,operation de?nitions,maintenance de?nitions, layout,parts,bills of materials,inventory,procurements, process plans,work,schedules,time sheets,references,and probability distributions.
Type is an attribute of shop data and is an enumeration to describe types about shop data.Identi?er is a key to uniquely identify the object internally within the system, and it is generated automatically by the system when the object is created.Number is also a unique key for identify-ing the object either when taken alone or possibly together with the object type,and the uniqueness is to the user or the user’s organization.Identi?er and number are required https://www.wendangku.net/doc/4c9517397.html, is used to identify the object by the user or user’s organization.It is provided for readability sake. Description is used to describe the nature of the subject. Reference keys refers to reference documents or?les that are stored external to the model.When a data element’s name suf?xes with“-key”or“-keys,”these data elements serve as pointers to the model to avoid rede?ning the same set of information.All other attributes,such as organiza-tions,calendars,resources,and so on,are major elements of the model that were introduced in section3.1.
The machine shop data model speci?cation is docu-mented using both UML and XML structures.XML is cho-sen to support Web users,while UML’s standard graphical notations provide visual communications.UML is a graph-ical representation;the language is for specifying,visual-izing,constructing,and documenting,rather than process-ing.XML is a format for structured documents,and thus XML documents are decodable.
The current version of the speci?cation includes XML documents that are well formed but may or may not be validated.Data should be validated before being imported to a legacy system.An XML schema is a speci?cation of the elements,attributes,and structures;it is useful not only for documentation but also for validation or process-ing automation[21].To facilitate automated validation,the format of the XML documents that make up the speci?ca-tion will be de?ned using the World Wide Web Consortium (W3C)XML Schema,an XML Schema language.
UML provides several modeling types,from functional requirements and activity analysis to class structures and component description.The modeling type used to map to the XML documents is the UML class diagram.A UML class diagram can be constructed to visually represent the structural and behavioral features.Since the behavioral fea-ture is not relevant to the XML speci?cation,that feature is omitted here[22].
28SIMULATION Volume81,Number1
ARCHITECTURE FOR DISTRIBUTED MANUFACTURING SIMULA TION
The complete speci?cation is not given here due to its size.Instead,a sample data element speci?cation is de-scribed.The data element of orders is chosen for illustra-tion in this section(see Fig.8).Orders is a subgroup of work and consists of a set of individual order data ele-ments.It speci?es a collection of production work orders to be processed within the shop.Each order contains the order de?nition and/or order status section.The order def-inition contains attributes of the order,including a list of order items(i.e.,a listing of individual parts that make up a particular order).The order status describes information about scheduled and actual progress toward completing the order.The same part may be listed in the order multiple times in different order items if each instance has unique attributes(e.g.,different due dates).
3.2.1UML Modeling
As mentioned before,the UML class diagram is one rep-resentation for the speci?cation of the information model.
A number of software tools are available for generating UML diagrams.The UML class diagrams introduced here have been generated using Microsoft Visio2000.A UML class diagram can be constructed to graphically represent the classes,attributes,and relationships.A UML class is the abstraction of a concept in the domain of discourse;it is de?ned by a set of attributes.An attribute is an additional piece of information associated with a UML class.Each attribute de?nes its type(such as string,integer,date,or user-de?ned data type)and relationships,and it optionally speci?es its default value.A special type of class,named DataType,is used to specify enumeration items.
Relationships between classes are shown with the con-necting line;the role and cardinality relationship may be presented along the relationship line.The role describes how the related class is used.There exist cardinality rela-tionships between a class and its attributes,as well as be-tween classes.The cardinality relationship speci?es how many speci?c instances of an element could be related to another element.The cardinality relationship may be“one”to“zero or one,”“one”to“zero or more,”“one”to“one or more,”or exactly“n”occurrences and is presented in the Figure8as0..1,0..*,1..*,n,respectively.The cardinality relationship used for attributes is enclosed by brackets.
The UML information model for the orders element is shown in Figure8.The orders element is a subelement of the work element,which is a subelement of the shop data element,which is the top element of the model.The orders element has the attributes of type(which is an optional string),an identi?er(which is an“int”or integer value),a number(which is a string),an optional name(which is a string),an optional description(which is a string),and op-tional reference keys and revisions(they are user-de?ned data types).Figure8illustrates the role and cardinality relationships among orders,order,order de?nition,and order status.An orders element contains order elements.Each order is de?ned by order de?nition and has an order status.Orders and order have a“one”to“one or more”relationship(i.e.,there may exist one or many order in-stances for an orders instance).Similarly,there may exist zero or one order de?nition instance and zero or one order status instance for an order instance.Each order de?nition instance is de?ned by one customers instance,one due dates instance,and zero or one of priority rating,order items,precedent constraints,resources required,and cost summary instances.
3.2.2XML Speci?cation
XML supports the development of structured,hierarchical data entities that may contain a high level of semantic con-tent that is both human and machine interpretable.There are several supporting standards from W3C that make working with XML easier.These include Document Object Management(DOM)for manipulating XML documents, XML Schema for de?ning the format of XML documents, and Extensible Style-sheet Language(XSL)for translat-ing XML documents to other formats(see https://www.wendangku.net/doc/4c9517397.html,). There also exist a wide variety of software applications to implement creation,parsing,interpreting,and displaying of XML documents.
An XML document is a collection of parsed and un-parsed pieces.An element is one of the basic type of nodes in the tree represented by an XML document.A well-formed document has one unique root element that contains all other elements.Elements follow one another, or appear inside one another,but may not overlap.All elements must have a start tag and an end tag that sur-round their contents.An element begins with
The same attribute can appear inside the start tag once only.However,the same child element may appear in the element more than once if it carries different instances.At-tributes are unordered while child-elements are presented in order.When an element has no content between the start tag and end tag or omits the end tag and terminates the start tag with“/>,”the element is an empty element.An empty element may contain attributes,however.
The XML structure for the orders element is shown as follows:
Volume81,Number1SIMULATION29
McLean,Riddick,and Lee
Figure8.Uni?ed Modeling Language(UML)model of the orders object
In the above structure,the element of orders is de?ned by the attributes of type,identi?er,and number,as well as the child elements of name,description,reference keys, revisions,and order.Order is further de?ned by the at-tributes of type,identi?er,and number,as well as the child elements of name,description,reference keys,revisions, order de?nition,and order status.All attribute values are unde?ned in this case.Child elements are empty elements. Data types,cardinality relationships,constraints,default values,and enumerations are not included in this sample XML document.They will be de?ned in the XML schema that is currently under development.
4.Conclusions and Next Steps
This article has provided a brief overview of the distributed manufacturing simulation architecture that was developed to enable the integration of COTS manufacturing simu-lators using the DOD HLA.The architecture facilitates integration of existing commercial systems with minimal new development work or modi?cation to the commercial software.The architecture also should enable experimen-tation with research systems that are based on evolving
30SIMULATION Volume81,Number1
ARCHITECTURE FOR DISTRIBUTED MANUFACTURING SIMULA TION
technology.The architecture describes the major system modules,data elements or objects,and interfaces between those modules.It uses HLA and the RTI as an integra-tion mechanism.Several prototype implementations were developed,tested,and integrated with commercial simula-tion systems,modeling tools,and other related manufac-turing software applications as part of the IMS MISSION project.After demonstrating the feasibility of integration using HLA and the NIST adapter,a neutral data model was needed to enable the sharing of information content between simulations.
Under the TIDE and SIMA programs,NIST worked with external collaborators to develop a neutral model and data exchange format for machine shop data.The objec-tive of the information modeling effort was to develop a standardized,computer-interpretable representation that allows for the ef?cient storage and exchange of manufac-turing life cycle data in a machine shop environment.The information model will continue to evolve based on the ex-perience and feedback from others involved in this effort. The model is now being transformed into a schema using an XML Schema language.The information model and as-sociated schema de?nitions will be proposed as a candidate standard to be considered by a formal standards body.A preliminary plan is in process for standardization through the Institute of Electrical and Electronics Engineers Stan-dards Association(IEEE SA)1516Committee[23],which was responsible for the Department of Defense HLA.
There are also experimental development activities un-der way to test the viability of the model with real-world applications.A generic manufacturing simulator is being developed at NIST for the TIDE program[24].The model is also being used in the TIDE program to integrate a manu-facturing execution system with a real-time adaptive sched-uler and the manufacturing simulator.An aerospace man-ufacturer is also working on a prototype simulation based on the speci?cation.An initial database implementation is currently under way.
There are also plans to expand the model to include assembly line,supply chain,and other domain areas.The current model addresses the exchange of real-world data between simulation and other manufacturing software ap-plications.Another information model and exchange?le format is needed to support the simulation abstraction pro-cess.This model would be used to maintain data regard-ing the mapping of real-world objects into their simulated representation.For example,as part of the abstraction pro-cess,data values may be approximated,different colors may be substituted for real objects,shapes and sizes may be changed,and probabilistic distributions may be substi-tuted for actual arrivals and other time-dependent events.
5.Acknowledgments and Disclaimer
NIST’s SIMA program,the SEI TIDE program,and the Wright Patterson Air Force Base sponsored the work de-scribed in this article.SIMA supports NIST projects that apply information technologies and standards-based ap-proaches to manufacturing software integration problems. No approval or endorsement of any commercial product by the National Institute of Standards and Technology is intended or implied.The work described here was funded by the https://www.wendangku.net/doc/4c9517397.html,ernment and is not subject to copyright. 6.References
[1]MISSION Consortium.1998.Intelligent Manufacturing System
(IMS)project proposal:Modelling and simulation environments
for design,planning and operation of globally distributed enter-
prises(MISSION).Version3.3.Tokyo:Shimuzu Corporation. [2]Rabe,M.,G.Garcia de Gurtubai,and F.J?kel.2001.Modelling and
simulation for globally distributed enterprises.In Proceedings of
the2001EUROSIM Conference,Delft,Germany.
[3]Rabe,M.,and F.J?kel.2001.Non military use of HLA within dis-
tributed manufacturing scenarios.In Proceedings of the2001Sim-
ulation and Visualization Conference,Magdeburg,Germany. [4]Hibino,H.,and Y.Fukuda.2002.A study on support system for dis-
tributed simulation system of manufacturing systems using HLA.
In Proceedings of the5th International Conference on Design
of Information Infrastructure Systems for Manufacturing,Osaka,
Japan.
[5]Hibino,H.,Y.Fukuda,Y.Yura,M.Nakano,and S.Fujii.2002.A study
on distributed simulation systems to evaluate manufacturing sys-
tems using HLA.In Proceedings of the2002Japan-USA Flexible
Automation Conference,Hiroshima,Japan.
[6]Riddick,F.2004.The distributed manufacturing simulation adapter
reference guide.Gaithersburg,MD:National Institute of Stan-
dards and Technology.
[7]Sall,K.2002.XML family of speci?cations:A practical guide.Boston:
Pearson Education.
[8]Carlisle,M.,and J.Fowler.2001.Systems integration for manufactur-
ing applications biennial report:Fiscal years1999-2000.NISTIR
6721,National Institute of Standards and Technology,Gaithers-
burg,MD.
[9]Shaw,M.,and D.Garlan.1996.Software architecture:Perspectives
on an emerging discipline.Upper Saddle River,NJ:Prentice Hall.
[10]Berners-Lee,T.,R.Fielding,and L.Masinter.1998.Uniform Re-
source Identi?ers(URI):Generic Syntax(RFC2396).Internet
Engineering Task Force.
[11]Kuhl,F.,R.Weatherly,and J.Dahmann.1999.Creating computer
simulations:An introduction to the High Level Architecture.Up-
per Saddle River,NJ:Prentice Hall.
[12]Goldfarb,C.,and P.Prescod.2000.The XML handbook.Upper Sad-
dle River,NJ:Prentice Hall.
[13]Ben-Natan,R.1995.CORBA:A guide to the common object request
broker architecture.New York:McGraw-Hill.
[14]Appleton Company,Inc.1985.Integrated information support sys-
tem:Information modeling manual,IDEF1-Extended(IDEF1X).
Fairborn,OH:Wright Patterson Air Force Base.
[15]International Organization for Standardization.1994.ISO IS10303-
11:Product data representation and exchange—Part11.The EX-
PRESS language reference manual.Geneva,Switzerland:Inter-
national Organization for Standardization.
[16]International Organization for Standardization.1994.ISO IS10303-
1:Product data representation and exchange—Part1.Overview
and fundamental principles.Geneva,Switzerland:International
Organization for Standardization.
[17]Object Management Group(OMG).2003.Uni?ed Modeling Lan-
guage.Accessed February26,2004,from https://www.wendangku.net/doc/4c9517397.html,/uml [18]WorldWideWeb Consortium(W3C).2000.Extensible Markup Lan-
guage(XML)1.0.2nd ed.Accessed February26,2004,from
https://www.wendangku.net/doc/4c9517397.html,/TR/REC-xml.html
Volume81,Number1SIMULATION31
McLean,Riddick,and Lee
[19]McLean,C.,T.Lee,G.Shao,F.Riddick,and S.Leong.2003.Shop
data model and interface speci?cation.Gaithersburg,MD:Na-
tional Institute of Standards and Technology.
[20]Lee,https://www.wendangku.net/doc/4c9517397.html,rmation modeling:From design to imple-
mentation.In Proceedings of the Second World Manufacturing
Congress,edited by S.Nahavandi and M.Saadat,https://www.wendangku.net/doc/4c9517397.html,let,
Alberta,Canada:International Computer Science Conventions.
[21]van der Vlist,E.2002.XML Schema.Sebastopol,CA:O’Reilly&
Associates.
[22]Carlson,D.2001.Modeling XML applications with UML:Practical
e-Business applications.Boston:Addison-Wesley.
[23]Institute of Electrical and Electronics Engineers.2001.IEEE Std
1516-2000:IEEE standard for modeling and simulation(M&S)
high level architecture(HLA)—Framework and rules.New York:
Institute of Electrical and Electronics Engineers.
[24]McLean,C.,A.Jones,T.Lee,and F.Riddick.2002.An architecture
for a generic data-driven machine shop simulator.In Proceedings
of the2002Winter Simulation Conference,edited by E.Yucesan,
C.Chen,J.L.Snowdon,and J.M.Charnes,1108-16.Piscataway,
NJ:Institute of Electrical and Electronics Engineers.
Charles McLean is a computer scientist and leads the Manu-facturing Simulation and Modeling Group.He has managed re-search programs in manufacturing simulation,engineering tool integration,product data standards,manufacturing automation, and manufacturing simulation&visualization at NIST since 1982.He has authored more than50technical papers on topics in these areas.He is on the Executive Board of theWinter Simulation Conference and the Editorial Board of the International Journal of Production,Planning,and Control.He is formerly the vice chair-man of the International Federation for Information Processing (IFIP)Working Group on Production Management Systems(WG 5.7).He is also the NIST representative to the Department of De-fense’s Advanced Manufacturing Enterprise Subpanel.He holds an M.S.in information rngineering from the University of Illinois at Chicago and a B.A.from Cornell University.
Frank Riddick is a computer scientist in the Manufacturing Sim-ulation and Modeling Group in the U.S.National Institute of Standards and Technology(NIST)Manufacturing Systems Inte-gration Division.He has participated in research and authored several papers relating to manufacturing simulation integration and product data modeling.He holds a master’s degree in math-ematics from Purdue University.
Y.Tina Lee is a computer scientist in the Manufacturing Simula-tion and Modeling Group at NIST.She joined NIST in1986.Most recently,she has been working on the design and development of interface information models to support the Software Engi-neering Institute(SEI)Technology Insertion Demonstration and Evaluation(TIDE)project.Previously,she worked at the Con-tel Federal Systems and at the Sperry Corporation.She received her B.S.in mathematics from Providence College and an M.S.in applied science from the College of William and Mary.
32SIMULATION Volume81,Number1
全国各地旅游景点一览表格
全国经典旅游景点一览表 北京 故宫博物院、天坛公园、颐和园、（八达岭-慕田峪）长城旅游区、明十三陵景区、恭王府景区、石花洞风景名胜、店人遗址、什刹海、京杭大运河、八大处、密云县古北口镇、九渡河镇、东坝古镇、王四营 燕京八景：太液秋风、琼岛春阴、金台夕照、蓟门烟树、西山晴雪、玉泉趵突、卢沟晓月、居庸叠翠 天津 古文化街旅游区（津门故里）、盘山风景名胜区、大悲禅院、文庙、挂甲寺、五大道租借区、平津战役纪念馆、天塔湖风景区、南市食品街、周恩来邓颖超纪念馆、大沽口炮台、九龙山国家森林公园、九山顶自然风景区、八仙山国家级自然保护区、霍元甲纪念馆、凯旋王国主题公园、意式风情区 上海 明珠广播电视塔、野生动物园、科技馆、豫园、陆家嘴、外滩万国建筑群、路步行街、世博园 重庆 大足石刻景区、巫山（小三峡）、武隆喀斯特旅游区(天生三桥、仙女山、芙蓉洞) 、酉阳桃花源景区、奉节小寨天坑、白帝城、青龙瀑布红岩革命纪念馆、抗战遗址博物馆、綦江黑山谷景区、南川金、武陵山大裂谷、飞庙 河北 ：避暑山庄及周围寺庙景区
：山海关景区、北戴河风景名胜区 ：安新白洋淀景区、野三坡景、大慈阁 ：西柏坡景区、清西陵 市：清东陵、南湖景区 ：崆山白云洞、峡谷群 江 ：园林（拙政园、虎丘、留园）、昆山周庄古镇景区、金鸡湖景区、吴江同里古镇景区、寒山寺、网师园、狮子林、沧浪亭、环秀山庄、退思园、锦溪镇、周庄镇、同里镇、甪直镇、木渎镇、虎丘、乐园、玄妙观、盘门三景、乐园 ：钟山-陵园景区、夫子庙-淮河风光带景区、明孝陵、鸡鸣寺、玄武湖、灵谷寺、总统府、朝天宫、江南贡院、莫愁湖、燕子矶、阅江楼、雨花台、明城墙、甘熙宅第、瞻园、栖霞寺、汤山温泉、博物院、、莫愁湖、长江大桥、梅花山、白鹭洲公园、中华门、将军山风景区、阳山碑材、静海寺、天妃宫 ：影视基地三国水浒景区、灵山大佛景区、鼋头渚风景区、锡惠公园、灵山胜境、善卷洞、竹海 ：恐龙城休闲旅游区、武进太湖湾旅游度假区、嬉戏谷、中华孝道园、中国春秋淹城旅游区、淹城春秋乐园、淹城野生动物世界、淹城遗址、大运河、天宁风景名胜区、红梅公园、东坡公园、舣舟亭、红梅阁、青枫公园、亚细亚影视城、武进市新天地公园、天目湖旅游度假区、南山竹海、吴越弟一峰、熊猫馆、天目湖御水温泉、茅山风景名胜区、茅山盐湖城 ：瘦西湖景区、高邮旅游集聚区、宝应旅游集聚区、仪征旅游集聚区、抗日战争最后一役纪念馆、大明寺、个园、仙鹤寺、汉陵苑、神居山、盂城驿、龙虬庄遗址、镇国寺塔、文游台、古悟空寺、中国邮驿文化城、高邮湖芦苇荡湿地公园、高邮湖滩郊野公园 ：濠河风景区、博物苑、狼山、如皋水绘园 ：梅兰芳纪念馆、溱湖国家湿地公园、溱潼古镇、兴化垛田风光带、凤城河景区 ：三山景区（金山-北固山-焦山）、茅山、赤山、宝华山、南山、伯先公园、英国领事馆、西津渡、蒜山、招隐寺、圌山、五柳堂、五卅演讲厅、扬中园博园 ：云龙湖、云龙山、龟山汉墓、祖园、邳州艾山风景名胜区、马陵山风景区、沛县汉城、汉画像石艺术馆、窑湾古镇、蟠桃山佛教文化景区、安湖湿地公园、博物馆、大洞山风景区、
世界33大著名旅游景点(组图)
第1位—美国大峡谷-TheGrandCanyon 美国大峡谷是一个举世闻名的自然奇观，位于西部亚利桑那州西北部的凯巴布高原上，总面积2724．7平方公里。由于科罗拉多河穿流其中，故又名科罗拉多大峡谷，它是联合国教科文组织选为受保护的天然遗产之一。
第2位—澳大利亚的大堡礁—GreatBarrierReef 世界上有一个最大最长的珊瑚礁群，它就是有名的大堡礁—GreatBarrierReefo它纵贯蜿蜒于澳洲的东海岸，全长2011公里，最宽处161公里。南端最远离海岸241公里，北端离海岸仅16公里。在落潮时，部分的珊瑚礁露出水面形成珊瑚岛。 第3位—美国佛罗里达州—Flori—dl
佛罗里达风景最亮丽的棕榈海滩是全球著名的旅游天堂之一，适宜的气候、美丽的海滩、精美的饮食、艺术展览和文艺演出，即使是最挑剔的游客，在棕榈海滩也能满意而归。每年的四月，棕榈海滩的艺术活动是最丰富多彩的，包括各种海滩工艺品展览，其中于4月4 日启动的棕榈海滩爵士节以展示美国最杰出的爵士音乐而赢得了艺术爱好者的青睐。 第4位—新西兰的南岛-Soutls—land
新西兰位于南太平洋，西隔塔斯曼海与澳大利亚相望，西距澳大利亚1600公里，东邻汤加、斐济国土面积为二十七万平方公里，海岸线长6900千米，海岸线上有许多美丽的海滩。 第5位—好望角一CapeTown
好望角为太平洋与印度洋冷暖流水的分界，气象万变，景象奇妙，耸立于大海，更有高逾二干尺的达卡马峰，危崖峭壁，卷浪飞溅，令人眼界大开。 第6位—金庙-GoldenTemple
金庙位于印度边境城市阿姆利则。作为锡克教的圣地，阿姆利则意为“花蜜池塘”。金庙由锡克教第5代祖师阿尔琼1589年主持建造，1601年完工，迄今已有400年历史。因该庙门及大小19个圆形寺顶均贴满金箔，在阳光照耀下，分外璀璨夺目，一直以来被锡克人尊称为“上帝之殿”。 第7位—拉斯维加斯-LasVegas
全国各省旅游景点大全
北京:八达岭故宫什刹海圆明园玉渊潭龙庆峡 十三陵天安门香山颐与园天坛十渡 百花山潭柘寺雍与宫幽谷神潭紫竹院黑龙潭 康西草原中央电视塔 澳门 : 妈祖阁大三巴牌坊澳门文化中心澳门博物馆玫瑰圣母堂竹湾海滩辽宁 : 沈阳故宫千山昭陵玉佛苑本溪水洞金石滩 虎滩乐园鸭绿江大桥辽宁省博物馆棒棰岛大孤山风景名胜区海王九岛 赫图阿拉城怪坡星海公园 重庆; 三峡大坝葛洲坝瞿塘峡歌乐山巫峡渣滓洞 白帝城白公馆丰都鬼城石宝寨芙蓉洞缙云山 金佛山宝顶山四面山 西藏: 珠穆朗玛峰大昭寺然乌湖布达拉宫纳木错墨脱 圣湖八廓街扎什伦布寺桑耶寺神山色拉寺 羊卓雍湖哲蚌寺罗布林卡古格王朝日喀则绒布寺 青海; 青海湖塔尔寺茶卡盐湖鸟岛日月山坎布拉 格尔木柴达木盆地北禅寺东关清真大寺黄河源孟达天池 倒淌河 宁夏: 沙湖西夏王陵贺兰山岩画长江源青铜峡108塔沙坡头 玉皇阁中卫高庙宏佛塔 台湾: 宝岛美景阿里山日月潭阳明山玉山太鲁阁 台北故宫板桥林家花园野柳赤嵌楼溪头秀姑峦溪 鹅銮鼻合欢山七美岛 山西: 五台山恒山平遥古城壶口瀑布乔家大院云冈石窟 王家大院北武当山晋祠悬空寺显通寺日升昌票号 广胜寺庞泉沟应县木塔南山寺善化寺 黑龙江: 大兴安岭漠河镜泊湖太阳岛吊水楼瀑布冰雪大世界 极乐寺亚布力滑雪场扎龙自然保护区圣索菲亚大教堂 甘肃; 嘉峪关莫高窟玉门关郎木寺伏羲庙麦积山石窟 炳灵寺石窟崆峒山 湖北: 三峡神农架武当山黄鹤楼归元寺葛洲坝 东湖西陵峡五道峡大九湖九畹溪香溪源 燕子垭 内蒙古: 呼伦贝尔草原成吉思汗陵阿斯哈图石林赤峰五当召响沙湾 扎兰屯锡林浩特达里诺尔湖大青沟格根塔拉草原黑里河 天津: 古文化街盘山食品街独乐寺大沽口炮台天后宫 天成寺舍利塔太平寨千像寺八卦城清真大寺蓟县白塔 新疆: 塞里木湖喀纳斯那拉提草原吐鲁番魔鬼城火焰山 交河故城高昌古城喀什博斯腾湖阿尔泰山白杨沟 博格达山楼兰卡拉库里湖罗布泊果子沟艾丁湖