- Email: [email protected]
The Role and Trends of Modeling and Simulation in Managing Manufacturing Complexity
THE ROLE A:\" 0 TRE:\" OS OF MOOELI:\"G Al\"O SIMULATlO:\" I:\" MA:\"AGI:\"G MA:\"UFACTURI:"G COMPLEXITY
:\1. Garetti, M. l\1acchi Politecnico di Milano, Dipartilllenlo di Ingegneria Gestionale Pia::::a Leonardo da VillCi, 32 - 1-20133 Milano Corre,\ponding (llIthor: E-lIIail: IIwrco,garelli@polillli,it Fcn ++39223992700 Abstract: Complexity is the underlying common character of modem manufacturing systems and business processes, Modeling and simulation are the I\vo main ways through which concept. analysis. dimensioning and evaluation of performances of complex systems are performed, While modeling and simulation techniques arc steadily developing, together with more available and cheaper computer power, a tremendous increase of the po\\'er of such computing techniques is expected from the merge between modeling and simulation. In fact after decades of separate development the traditional gap between mode ling and simulation is becoming to be considered a problem to deal with and that can be solved. On one hand. the continuous development of simulation tools still continue to find strong barriers for large diffusion and use in the difficulty of building and testing the simulation model. On the other hand (logical) modeling of complex systems is trying to cover a comprehensive, integrated and global view of the whole enterprise (enterprise modeling). Unfortunately, as it is well known, after building a complex logical model, the model itself could not predict system behavior unless translated in a corresponding simulation model. This process might be exceptionally speeded-up if integration between logical and simulation modeling might be achieved by automatic model translation, thus realizing a process we might call "virtual design and evaluation of complex systems". Of course, to achieve such a result full integration between mode ling and simulation should be achieved. Copl'right @2003 IFAC Keywords: Manufacturing Systems modeling, Systems Engineering.
ADDRESSING COMPLEXITY IN SYSTEMS DESIGN For the sake of clarity, we will divide the area of design of complex systems considering three different focuses of the design activity. Therefore we will consider:
Information Systems (for achieving integration among different software applications, IT infrastructures, and business users [Ver98]).
I.
I.
2.
3.
Simulation, Manufacturing
In the above mentioned fields design processes are carried out following similar paths (see for example [Ver99] for 8PE area and [Car88] for MSE area), i.e. through two main steps: a modelling activity, for developing a logical model of the considered system (i.e. a system model [Ver99]): a simulation activity, for developing a simulation model of the system (i.e, an executable model of the considered system for evaluating dynamic system behaviour under given experimental conditions), For example, in the \1SE (Manufacturing Systems Engineering) area, the process of system analysis and design activity is carried out through the steps
Manufacturing Systems Engineering (MSE), which is the design activity concerned with the analysis and design/redesign of manufacturing facilities (for improving and optimising manufacturing performances [8ar98]. [8ar99]): 8usiness Process Engineering (8PE), which deals with the analysis and design/redesign of business processes, enterprise activities and organisations (for improving and optimising overall business systems [Ver98]): Infonnation Systems Engineering (ISE). which deals with the analysis and design/redesign of
129
highlighted in Fig. 1. In fact dcsign (or re-design) starts from a target manufacturing system, which must be empowered or re-engineered, aiming at achieving defined objectives and comply with givcn constraints. The design process is accomplished through the subsequent phases of concept (assisted by logical modeling), draft design and draft evaluation of performances (assisted by steady statc analysis) and detailed design (assisted by dynamic analysis through simulation). To accomplish thcse processes, mode ling methods and simulation tools are needed.
Modelling Cateoory BPM: Business Process Modelling MSE: Manufacturing Systems Modelling ISE: Information Systems Engineering
.\lanufacturing
System
Logical Modelling Methods SADT [Mar88], IEM [Spu93], CIMOSA [Ver98], GRAI [Dou96], IOEF [Men98], ARIS rSch991 Xspec [Jud90], JR-nct [Par97], MES [Bar99], HOOMA [Wu95], OMT [Rum91], UML [Lar97], IOEF rMen981 ERM [Che76], SADT [Mar88], OMT [Rum9l], UML [Lar97], use ease driven approach [Jac92] CIMOSA [Ver98], ARIS [Sch99]
Tab. 1 - Modeling methods fOl' system modeling For examplc: - the OMT method [Rum91] was developed for software engineering and uses concepts and definitions typically adopted in the information systems area (e.g., entity relationships, data-flow, state transitions, event-flows); nevertheless, due to its general features, the same method can also be profitably used to describe MSE and BPR processes; - the CIMOSA method [Ver98], devcloped for integrated business and information systems modelling, uses enterprise activities and process oriented concepts and can be typically adopted both in BPR and ISE; - the MES method [Bar99] was developed for the virtual prototyping of manufacturing systems and uses concepts and definitions typically adopted in MSE (e.g., process-oriented and production controloriented concepts). Given the unavailability of a modeling tool with full capabilities for describing manufacturing systems, a survey of most important modeling tools was made for evaluating their "capability" to represent the manufacturing world.
Figure 1 - Design steps in MSE activities
2.
REVIEW OF MODELlNG METHODS
Modelling methods cover different application fields: they were first developed in the software engineering sector (remembcr the Entity/Relationship formalism of '70ties) from which they spread in different fields and were used for instance in manufacturing modeling and business process modeling. In general, modelling methods organise system description (i.e. the system's logical model) into multiple "logical views" (e.g. the OMT method [Rum91] defines three views: i) the static model, ii) the dynamic model, and iii) the functional model for description of static, dynamic and functional aspect of the modelled system). The following Tab. I reports a list of methods developed for system modelling in Software Engineering (Information Systems Modeling, ISM), Manufacturing Systems Modeling (MSM) and Business Process Modeling (BPM). Each method can be defined as a "modelling dialect" and uses specific concepts and definitions inherited from its native engineering field of use (i.e. BPE, MSE or ISE); a method can be more or less specialised for a given enginecring field (i.e. a modelling category) depending on its origin and features.
2.1
Results ofthe survey
The most important methods developed in quite different fields for logical system description were reviewed and a standard sheet was derived for each method. In particular the following capabilities were evaluated as regards the modeling of a generic manufacturing system: i) capacity to describe the product process planning (functional aspect); ii) capacity to describe the information exchange between system's objects (functional aspect); iii) capacity to describe the system physical structure (stmctural aspect); iv) capacity to describe the behavior of the human component (organizational aspect).
130
Finally a classification scheme of methods was derived weighing the different capabilities of each method: the results of the survey are summarized in Tab. 2. where the partial and final scores given to each method are reported (more detailed information can be found in [MacO 1]).
Process planning
InJonrution exchang.e
Stnlt.:tural Q'S\.TipliOl1
HunRIl beh.l\ior
Clohal score
£'4).25
I~~.25
£'-0.2'
P--o.~5
E'R
Imu
13';·"
25~/(J
65fJu
19:·u
OFD
61!~u
5{)~u
J5
fJ
U
(J;"
3/f}'u
STD
f!;u
](r~,
15
fJ
,u
(/:'0
/ J~\,
SAOT
311;'v
6/1'·v
28'\/
(f1/o
]l/!-u
JoCksOl1
J(J',~o
13 1'/1
131~U
l3
,u
14'Yu
Wal1ller-Orr
311f/u
53(~(J
13~'u
/Y?u
2(f!-'o
SOD
3('~o
60~~u
28(.~/{I
m"
If,l,~(!
SSAOM
7iff/v
73~'u
65~!fJ
65 :,u
&\j";u
lJ
1
ClOSA
Ii!'u
13';"
25 !,u
65(~1)
l/':>"~u
OOA
25lj/u
4J!!'u
33(~'o
(j5~'u
4/'}o
f
category BSM: Business Process Simulation MSS: Manufacturing Systems Simulation ISS: Information Systems Simulation
OMT
55~u
93~'u
7]'.hJ
65~/u
7/~~'u
IOEF4
25~u
43fj/u
5(f}/u
65%
4t'f}u
ClOSE
4iff/u
63~/u
33'}'u
65iJ'u
51f}'u
00/\0
4(J!,o
63r:,v
5g~u
65:',u
56f]/u
UML
55lj/u
93%
73~/)
65~u
71%
IOEFO
6(ff/v
6(fl-'o
2lf}/u
(Jf'u
37%
IDEFIx
liff/v
/3lf/u
25~u
65'7u
2:S<7u
IOEF3
6iff/v
6(fyu
/3'/'0
(f;-u
33%
GIM
65~u
80%
28~u
4(ff/v
53~u
OMaSA
7iff/v
73%
4(fYv
liXfYu
71%
65'"7u
66~u
HOOMA
55'7u
73'7u
73'}u
JR-:\et
60%
3lff/v
75~u
lI~v
4/f}u
MES
7iff/v
3lff/v
63'?v
7ifYu
5/fyu
[SysOO]. SiMPLE++ Witness [LanOO], Chi
Witness [LanOO]. Qase [Ast97]. Mimic Snmp Agent Simulator [Gam97]
Each simulation tool can be regarded as a "simulation dialect" and may adopt specific constructs for an elective field of usage, often addressing different engineering fields through customised simulation libraries. For example: Arena [SysOO], originally developed for MSS, is also capable of simulating BPE activities, using appropriate application libraries: FirstSTEP [LevOO], specifically developed for BPE, is specialised for this application field; - SiMPLE++ [Aes97]. being an object-oriented simulation environment, has been used more easily in different engineering fields. Since each simulation tool is able to capture the specific features of a modelling category, more than one simulation system is potentially needed to develop simulation models addressing an Enterprise Engineering view point. Conversely, different simulation models need to be inter-operated. 4.
PROPOSAL OF FRAMEWORK
AN
INTEGRATION
Considering the push towards integrating all different areas to achieve Enterprise Engineering modelling capability, Garetti and Maechi [GarOO] proposed the vision that "integration should be pursued while maintaining diversitv", meaning that the value, the details, and the power of specific tools should be preserved, while extending the covered field (as far as the whole enterprise) by combining different tools. Therefore the following framework was proposed for integrating i) engineering fields, ii) modelling methods, and iii) simulation tools in an overall "worldview" that was defined as "House of Enterprise Engineering". organised according to the scheme reported in Fig. 2. The roof of the house (level 4) represents the EE domain itself; The under roof (level 3) is divided into different engineering fields (i.e. the EE thematic areas previously considered); The first floor (level 2) is correspondingly divided into rooms assigned to different modelling techniques:
As a conclusion we can say none method has full modeling capability for manufacturing systems description, while the best performances are reported by UML, OMT and CIMOSA.
REVIEW OF SIMULATION TOOLS
For simulation modelling too there is a lot of specialised simulation tools for the different application fields. The following Tab. 4 reports a list of simulation tools, classified according to three categories, corresponding to di fferent application engineering fields (BPE, MSE, ISE). Modelling
Arena [Aes97], [Van96]
Tab. 3 - Simulation tools/or s\'Slem simulation
Tab. 2 - Survey ofmedelling methods
3.
Tools Arena SiMPLE++ [SysOO]. [Aes97]. FirstSTEP [LevOO]. ARIS Simulation [Sch99]
Simulation
131
model to the simulation model identify a vertical integration line.
The ground floor (level I) is likewise divided into rooms for simulation tools
The "House of EE" needs integration of its building elements, in particular has to be achieved along two axis of the house and at different levels: along the X-axis (horizontal integration), integration at logical modeling level must be achieved in order to: i) cover different aspects ("world views") of the considcred system (i.e. BPE, MSE or ISE), ii) avoid information dispersion into heterogeneous and loosely conncctcd models; along the Y-axis (vertical integration), integration between modcling and simulation tools must be achieved in order to improve mode ling efficiency; along the X-axis, again, (horizontal integration), integration between different simulation models should be achieved to allow interoperation simulation models themselves.
House levels
Yaxis
Level 2: System Modeling
Level I: System Simulation
4.1 : : ,
Horizontal integration should be achieved independently on level 2 (system modelling) and on level I (system simulation). On level 2, horizontal integration means that system modelling should produce EE models, whose "logical views" must be connected accordingly, as required by their information content. For this kind of integration, ISO 14258 [IS097] should be considered, which suggests three ways to achieve interoperability of enterprise models: I. the integrated approach; 2. the unified approach; 3. the federated scenario. - In the integrated approach, a standard model is used to collect information from heterogeneous EE models; therefore, the overall EE· model IS represented by the collection of information from the different models, given by the standard model. - In the unified approach, a unified meta-model template supports model translation, and establishes semantic equivalence across EE models; therefore, the overall EE model is represented by the independent worldview of each model. - Finally, the federated scenario leverages on the capability of each model to address information exchange with other models through a standard communication interface; therefore, the overall EE model is represented again by the independent world view of each model.
Information ~y~!~.n.lyi~':V World Manufacturing yiews sy~t~111yi~~v _.
Business process view
X axis
Fig. 2 - House o/Enterprise Engineering Symbols used in Fig. 2 are reported in Fig. 3.
Multiple logical views of system model
~ Relationship between ---.
logical views of svstem model
Simulation model building
Simulation model
Synchronization and data exchange between simulation models
Fig 3 - Symbols 0/ the House Engineering
Horizon/al integra/ion
0/ En/erprise
Each modelling and simulation tool contained in Tab.1 and Tab. 2-3 is located in its (their) corresponding(s) room(s). In particular, while modelling methods, on level 2, describe the system's logical model as divided into multiple "logical views", the corresponding simulation model on level I is unique. In addition, the arrows connecting the logical views of system models on kwl 2 and the simulation models on level I identify horizontal integration actions. Finally, the arrows crossing leYeI 1 and 2 to connect the logical views of the systcm's
On level I, horizontal integration means that system simulation should address interoperability among simulation models. Here, interoperability solutions should basically follow a federated approach. To this end, thc High Level Architecture (HLA), developed to support interoperability among modelling and simulation systems in the US Department of Defence
132
[Dah98], should be considered. HLA is based on the notion of federation, where a federation is a collection of federates - that is simulation systems and other systems - that interoperate using services provided by the architecture itself (namely by its Run Time lnfrastmcture, HLA/RTI). Within HLA, each federate plugs into the federation by means of a HLA interface specification. The interface specification allows the federate to access RTI services, so that communication and synchronisation with other federates is possible By providing inter-process communication from tightly synchronous to completely asynchronous [Fuj97], HLA is an effective solution for the synchronisation and data exchange requirements of a federation of simulation models.
4.2
This approach is discussed in detail in the next paragraph.
4.3
Interfacing modelling to simulation
At NIST research work is going on addressing the considered integration problem, the work is inspired by similar research carried out on standard infonnation exchange between different tools. Following NIST approach a flexible solution should be adopted for automated model building: the approach should leverage on a Neutral file adopted as a standard interface to implement translation from a system logical model in the simulation target of translation In fact, as already stated, system logical models are generated through adoption of a specific mode ling tool. Afterwards, they are translated according to the standard interface specification. The model built according to the standard interface specification is then converted to a simulation model, according to simulation constmcts of a specific simulation tool (see Fig. 4).
Vertical integration
should be achieved Vertical integration independently within each EE area. Starting from the system model developed on level 2, a transfonn function should support building of a simulation model for level I (integrating the different views of the system model). Automatic building of the simulation model may be achieved in two ways: I. Custom interface, linking a modelling tool to a specific simulation tool (application case approach); 2. Modular building, linking elements of a modelling ontology to elements taken from a simulation ontology (ontology case approach). With respect to the application case approach, several interfaces have been developed between modelling and simulation tools, including: Visio is a graphical BPM tool for business process engineering (i.e. BPE area), whose models may be directly transfonned into Arena simulation models [SysOO] by means of a specific Visio-Arena interface; ARIS models may be automatically translated to Simple++ simulation models to dynamically evaluate the perfonnances of ARIS process models (ARIS Simulation [Sch99]); VisFactory is a MSM tool for manufacturing systems engineering (i.e., MSE area), whose layout design and production models may be translated into a VisSim simulation model ([Eai99]) or into a Witness simulation model ([LanOO)). With respect to the ontology case approach, model building is carried out based on close correspondence between modelling objects stored in a logical model base and simulation objects stored in a simulation model library. For example, the Systems Entity Stnlcture/Model Base environment proposed by Zeigler [Zei90], provides a logical model base (storing conceptual components of reality) for which procedural models reside in a simulation model base
Modellng tool I
-""",,,,,,,,,,,,,,.,,,Y~-----y'
==,;"""'_
Neutral file - Interface
Fig. 4 - Flexible approach to model building Note that "n" logical models can be used to describe a manufacturing system (that is "n" modeling views), but, at the end of translation process, a unique simulation model is got (a simulation model which can be mn in a specific simulation tool). As regards the standard interface, reference can be made to IMES (Initial Manufacturing Exchange Specification), provided by NIST [NST98] for data exchange between different simulation tools. The alternative to the flexible approach, which can be defined to solve the integration problem, is a customized approach, which proposes a transfonnation "point to point", from system logical models. generated in a specific modeling tool, to a simulation model using a specific simulation tool. In this case a specific interface should be designed and implemcnted for any mode ling tool.
133
As a conclusion wc can say that next generation modeling and simulation tools will probably achieve impressive power from integration and interoperation allowing improved capability of virtual design of complex systems.
At a first sight, the two compcting approaches standard interface vs. customized interface - require the development effort listed in Tab. 4.
ACKNOWLEDGEMENTS System entity structure System entity structure design design 2
Model base design
Thanks are due to master thesis students Diego Cattaneo, Angelo Marco Roccia and Paolo Sotgiu for their contribution to the content of the paper.
Model base design Neutral file design
3
process
Transform design
REFERENCES [Aes97] Aesop GmbH (1997) SiMPLE++ Reference Manual Vcrsion 4.1. Aesop GmbH, Stuttgart, 1997.
Pre-processor design Post-processor design
[Ast97] Ast Engineering Services (1997). Qase Performance Engineering.
Table 4 - Development effort
[Bar98] Bartolotta A., Garetti M., Corradi E., Molteni L., Gronchi D. 1998. Using Plantfaber to design and re-engineer manufacturing systems. In Proceedings of the International Conference Competing in the information society, Genoa, June 24-26, 1998. (ESPRIT PROJECT W 22031).
As it can be seen, major design effort is expected from the standard interfacc approach. Moreover, the use of a standard interface probably implies thc necessity of an editing activity to provide further information required by simulation modeling activity, while a customized interface is supposed to be already organized in such a way as to guarantee a complete translation. Obviously, the higher time spent in designing and integrating information is recovered when changing logical modeling tools: in this situation a customized interface must be completely modified while a standard interface needs only a pre-processor set-up. 5
[Bar99] Bartolotta, A., Corradi, E., Garetti, M. (1999). Developing an ontology for the modelling of manufacturing systems. In Proceedings of IEMC99, Verdal, Norway, June 14-16. [BerO 1] Bernus P. (200 I). Some thoughts enterprise mode ling. Production Planning Control, 2001, vo!. 12, no. 2, 110-118.
CONCLUSIONS
The most important empowerment to tools supporting the design of complex manufacturing and logistics systems is coming from integration between mode ling and simulation techniques. In particular the following points are to be kept in mind: upgrading and enlarging the mode ling approach to the whole supply-chain or to the whole enterprise requires impressive power from corresponding tools; on the other hand, the solution of developing a global tool for logical mode ling or for simulation mode ling appears to be unrealistic; therefore strong efforts are to be made for integrating different tools from the vertical and horizontal point of view; integration between modeling methods has to be achieved through communication and overlapping between different tools; integration between simulation programs could be achieved through the use of communication and synchronization standards like High Level Architecture.
on &
[Car88] Carrie, A. (1988). Simulation of manufacturing systems. John Wiley & Sons, 1988. [Che76] Chen, P.P. (1976). The entity-relationship model. ACM transactions on database systems, vol.l, n. I, march, pp. 9-37. [Dah98] Dahmann, l.S., Fujimoto, R.M., Weatherly, R.M. (1998). The DoD High Level Architecture: an uodate. In Proceedings of the 1998 Winter Simulation Conference, pp. 797-804. [Dou96] Doumeingts, G., Girard, P., Eynard, B. (1996). GIM: GRAI Integrated Methodology for Product Development. In: Design for X, Concurrent Engineering Imperatives, Chapman & Hall, 1996. [Eai99] Engineering Automation Inc. (1999). Open Virtual factory. http://www.eai.com/products. [Fuj97] Fujimoto, R.M. (1997). Zero look ahead and repeatability in the High Level Architecture. 1n
134
Proceedings ot Ihe 1997 Spring Simulalion 1nleroperabilil.l' Workshop. Orlando, FL March 3-7.
[Spu93] Spur, G.. Mertins K, Jochem, R. (1993). Integrierte Unternehmensmodellierung. Bcuth Verlag. Berlin. 1993.
[Gam97] Gambit Communications (1997). Mimic Snmp Agent Simulator.
[Sch99] Scheer, A. W. (1999). ARIS- Business Process Modeling Springer-Verlag, Berlin, 1999
[lfi98] IFIP-IFAC Task force (1998). GERAM: Generalized Enterprise Reference Architecture and Methodology (1998) Annex A 10 1S0 15704. ISO TCI84/SC5/WGI N423.
[SysOO] Systems modelling corporation (2000). Simulation solutions from Systems Modelling. http://www.sm.com [Van96] van de Mortel-Fronczak, J.M. and Rooda J.E. (1996). On the integral modelling of control and production management systems. In Proceedings of Advances in Production Management Systems. 1996, pp. 171-176.
[IS097] ISO (1997) ISO 14258: industrial automation systems -- concepts and rules for enterprise models. http://www.mel.nist.gov [Jac92] Jacobsen. I. (1992). Object-Orientcd Software Enginecring: a Use Case Driven Approach. Addison Wesley.
[Ver98] Vernadat. F. B. (1998). The CIMOSA languages. In Handbook on Architectures on Information Systems, Springer-Verlag, Berlin, 1998, chapter 11.
[Jud90] Judd. R.P .. Vanderbok. R.S .. Brown. ME. Sauter. J.A. (1990). Manufacturing system design methodology: execute the specification. In proceedings of CIMCO 90, 133-152.
[Ver99] Vernadat F. B. (1999). Requirements for th simulation tools in Enterprise Engineering. 15 Int. Conf. On CAD/CAM, Robotics and Factories of the Future, Aguas de Lindoia. SP, Brazil, August 18, 1999.
[LanOO] Lanner Group. (2000). Lanner Technology solutions. http://www.lanner.com [Lar97] Larman, C (1997). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Prentice Hall. 1997.
[Wi191] Williams, TJ.. The Purdue Enterprise Reference Architecture. a technical guide for CIM planning and implementation. 1992, Instrument Society of America, Research Triangle Park, North Carolina, USA.
[LevOO] Levi, M. H., and Klapsis M.P. (2000). FirstSTEP Process Modeler- a CIMOSA Compliant Modeling Tool. Interfacing Technologies Corp .. http://www.interfacing.com
[Wu95] Wu, B. (1995). Object-oriented systems analysis and definition of manufacturing operations. International Journal of Production Research, 1995, voU3, no.4, 955-974.
[MacOl] Macchi. M. and Garetti, M. (2001). Enterprise Interoperability: a Critip} Survey of Modelling Methods with Special Concern to Manufacturing Systems Engineering, Proc. INCOM 200 I, Wien, Sept. 2001. [Mar88] Marca, D.A. and McGowan. CL. (1988). SADT: Structured Analysis and Design Technique. Prenctice Hall, New Jersey.
[Zei90] Zeigler, B.P .. Lou. C.1., Kim, T.G. (1990). Model Base Management for Multifacetted Systems. IEEE. 1990, pp. 25-31.
[Men98] Menzel, C, and Mayer, R.. J. (1998) The IDEF family of languages. In: Handbook on Architectures of Information Systems, SpringerVerlag, Berlin. 1998. chapter 10. [Par97] Park. T.Y .. Han, K.H., Choi, B.K. (1997). An object-oriented modelling framework for automated manufacturing systems. International Journal Computer Integrated Manufacturing, 1997, voL I 0, no.5, 324-334 [Rum91] Rumbaugh 1., Blaha M.. Premerlani W., Eddy F., Lorensen W. (1995). Object-oriented modeling and design. Prenctice-Hall international, Englewood Cliffs. 1991.
135
:\1. Garetti, M. l\1acchi Politecnico di Milano, Dipartilllenlo di Ingegneria Gestionale Pia::::a Leonardo da VillCi, 32 - 1-20133 Milano Corre,\ponding (llIthor: E-lIIail: IIwrco,garelli@polillli,it Fcn ++39223992700 Abstract: Complexity is the underlying common character of modem manufacturing systems and business processes, Modeling and simulation are the I\vo main ways through which concept. analysis. dimensioning and evaluation of performances of complex systems are performed, While modeling and simulation techniques arc steadily developing, together with more available and cheaper computer power, a tremendous increase of the po\\'er of such computing techniques is expected from the merge between modeling and simulation. In fact after decades of separate development the traditional gap between mode ling and simulation is becoming to be considered a problem to deal with and that can be solved. On one hand. the continuous development of simulation tools still continue to find strong barriers for large diffusion and use in the difficulty of building and testing the simulation model. On the other hand (logical) modeling of complex systems is trying to cover a comprehensive, integrated and global view of the whole enterprise (enterprise modeling). Unfortunately, as it is well known, after building a complex logical model, the model itself could not predict system behavior unless translated in a corresponding simulation model. This process might be exceptionally speeded-up if integration between logical and simulation modeling might be achieved by automatic model translation, thus realizing a process we might call "virtual design and evaluation of complex systems". Of course, to achieve such a result full integration between mode ling and simulation should be achieved. Copl'right @2003 IFAC Keywords: Manufacturing Systems modeling, Systems Engineering.
ADDRESSING COMPLEXITY IN SYSTEMS DESIGN For the sake of clarity, we will divide the area of design of complex systems considering three different focuses of the design activity. Therefore we will consider:
Information Systems (for achieving integration among different software applications, IT infrastructures, and business users [Ver98]).
I.
I.
2.
3.
Simulation, Manufacturing
In the above mentioned fields design processes are carried out following similar paths (see for example [Ver99] for 8PE area and [Car88] for MSE area), i.e. through two main steps: a modelling activity, for developing a logical model of the considered system (i.e. a system model [Ver99]): a simulation activity, for developing a simulation model of the system (i.e, an executable model of the considered system for evaluating dynamic system behaviour under given experimental conditions), For example, in the \1SE (Manufacturing Systems Engineering) area, the process of system analysis and design activity is carried out through the steps
Manufacturing Systems Engineering (MSE), which is the design activity concerned with the analysis and design/redesign of manufacturing facilities (for improving and optimising manufacturing performances [8ar98]. [8ar99]): 8usiness Process Engineering (8PE), which deals with the analysis and design/redesign of business processes, enterprise activities and organisations (for improving and optimising overall business systems [Ver98]): Infonnation Systems Engineering (ISE). which deals with the analysis and design/redesign of
129
highlighted in Fig. 1. In fact dcsign (or re-design) starts from a target manufacturing system, which must be empowered or re-engineered, aiming at achieving defined objectives and comply with givcn constraints. The design process is accomplished through the subsequent phases of concept (assisted by logical modeling), draft design and draft evaluation of performances (assisted by steady statc analysis) and detailed design (assisted by dynamic analysis through simulation). To accomplish thcse processes, mode ling methods and simulation tools are needed.
Modelling Cateoory BPM: Business Process Modelling MSE: Manufacturing Systems Modelling ISE: Information Systems Engineering
.\lanufacturing
System
Logical Modelling Methods SADT [Mar88], IEM [Spu93], CIMOSA [Ver98], GRAI [Dou96], IOEF [Men98], ARIS rSch991 Xspec [Jud90], JR-nct [Par97], MES [Bar99], HOOMA [Wu95], OMT [Rum91], UML [Lar97], IOEF rMen981 ERM [Che76], SADT [Mar88], OMT [Rum9l], UML [Lar97], use ease driven approach [Jac92] CIMOSA [Ver98], ARIS [Sch99]
Tab. 1 - Modeling methods fOl' system modeling For examplc: - the OMT method [Rum91] was developed for software engineering and uses concepts and definitions typically adopted in the information systems area (e.g., entity relationships, data-flow, state transitions, event-flows); nevertheless, due to its general features, the same method can also be profitably used to describe MSE and BPR processes; - the CIMOSA method [Ver98], devcloped for integrated business and information systems modelling, uses enterprise activities and process oriented concepts and can be typically adopted both in BPR and ISE; - the MES method [Bar99] was developed for the virtual prototyping of manufacturing systems and uses concepts and definitions typically adopted in MSE (e.g., process-oriented and production controloriented concepts). Given the unavailability of a modeling tool with full capabilities for describing manufacturing systems, a survey of most important modeling tools was made for evaluating their "capability" to represent the manufacturing world.
Figure 1 - Design steps in MSE activities
2.
REVIEW OF MODELlNG METHODS
Modelling methods cover different application fields: they were first developed in the software engineering sector (remembcr the Entity/Relationship formalism of '70ties) from which they spread in different fields and were used for instance in manufacturing modeling and business process modeling. In general, modelling methods organise system description (i.e. the system's logical model) into multiple "logical views" (e.g. the OMT method [Rum91] defines three views: i) the static model, ii) the dynamic model, and iii) the functional model for description of static, dynamic and functional aspect of the modelled system). The following Tab. I reports a list of methods developed for system modelling in Software Engineering (Information Systems Modeling, ISM), Manufacturing Systems Modeling (MSM) and Business Process Modeling (BPM). Each method can be defined as a "modelling dialect" and uses specific concepts and definitions inherited from its native engineering field of use (i.e. BPE, MSE or ISE); a method can be more or less specialised for a given enginecring field (i.e. a modelling category) depending on its origin and features.
2.1
Results ofthe survey
The most important methods developed in quite different fields for logical system description were reviewed and a standard sheet was derived for each method. In particular the following capabilities were evaluated as regards the modeling of a generic manufacturing system: i) capacity to describe the product process planning (functional aspect); ii) capacity to describe the information exchange between system's objects (functional aspect); iii) capacity to describe the system physical structure (stmctural aspect); iv) capacity to describe the behavior of the human component (organizational aspect).
130
Finally a classification scheme of methods was derived weighing the different capabilities of each method: the results of the survey are summarized in Tab. 2. where the partial and final scores given to each method are reported (more detailed information can be found in [MacO 1]).
Process planning
InJonrution exchang.e
Stnlt.:tural Q'S\.TipliOl1
HunRIl beh.l\ior
Clohal score
£'4).25
I~~.25
£'-0.2'
P--o.~5
E'R
Imu
13';·"
25~/(J
65fJu
19:·u
OFD
61!~u
5{)~u
J5
fJ
U
(J;"
3/f}'u
STD
f!;u
](r~,
15
fJ
,u
(/:'0
/ J~\,
SAOT
311;'v
6/1'·v
28'\/
(f1/o
]l/!-u
JoCksOl1
J(J',~o
13 1'/1
131~U
l3
,u
14'Yu
Wal1ller-Orr
311f/u
53(~(J
13~'u
/Y?u
2(f!-'o
SOD
3('~o
60~~u
28(.~/{I
m"
If,l,~(!
SSAOM
7iff/v
73~'u
65~!fJ
65 :,u
&\j";u
lJ
1
ClOSA
Ii!'u
13';"
25 !,u
65(~1)
l/':>"~u
OOA
25lj/u
4J!!'u
33(~'o
(j5~'u
4/'}o
f
category BSM: Business Process Simulation MSS: Manufacturing Systems Simulation ISS: Information Systems Simulation
OMT
55~u
93~'u
7]'.hJ
65~/u
7/~~'u
IOEF4
25~u
43fj/u
5(f}/u
65%
4t'f}u
ClOSE
4iff/u
63~/u
33'}'u
65iJ'u
51f}'u
00/\0
4(J!,o
63r:,v
5g~u
65:',u
56f]/u
UML
55lj/u
93%
73~/)
65~u
71%
IOEFO
6(ff/v
6(fl-'o
2lf}/u
(Jf'u
37%
IDEFIx
liff/v
/3lf/u
25~u
65'7u
2:S<7u
IOEF3
6iff/v
6(fyu
/3'/'0
(f;-u
33%
GIM
65~u
80%
28~u
4(ff/v
53~u
OMaSA
7iff/v
73%
4(fYv
liXfYu
71%
65'"7u
66~u
HOOMA
55'7u
73'7u
73'}u
JR-:\et
60%
3lff/v
75~u
lI~v
4/f}u
MES
7iff/v
3lff/v
63'?v
7ifYu
5/fyu
[SysOO]. SiMPLE++ Witness [LanOO], Chi
Witness [LanOO]. Qase [Ast97]. Mimic Snmp Agent Simulator [Gam97]
Each simulation tool can be regarded as a "simulation dialect" and may adopt specific constructs for an elective field of usage, often addressing different engineering fields through customised simulation libraries. For example: Arena [SysOO], originally developed for MSS, is also capable of simulating BPE activities, using appropriate application libraries: FirstSTEP [LevOO], specifically developed for BPE, is specialised for this application field; - SiMPLE++ [Aes97]. being an object-oriented simulation environment, has been used more easily in different engineering fields. Since each simulation tool is able to capture the specific features of a modelling category, more than one simulation system is potentially needed to develop simulation models addressing an Enterprise Engineering view point. Conversely, different simulation models need to be inter-operated. 4.
PROPOSAL OF FRAMEWORK
AN
INTEGRATION
Considering the push towards integrating all different areas to achieve Enterprise Engineering modelling capability, Garetti and Maechi [GarOO] proposed the vision that "integration should be pursued while maintaining diversitv", meaning that the value, the details, and the power of specific tools should be preserved, while extending the covered field (as far as the whole enterprise) by combining different tools. Therefore the following framework was proposed for integrating i) engineering fields, ii) modelling methods, and iii) simulation tools in an overall "worldview" that was defined as "House of Enterprise Engineering". organised according to the scheme reported in Fig. 2. The roof of the house (level 4) represents the EE domain itself; The under roof (level 3) is divided into different engineering fields (i.e. the EE thematic areas previously considered); The first floor (level 2) is correspondingly divided into rooms assigned to different modelling techniques:
As a conclusion we can say none method has full modeling capability for manufacturing systems description, while the best performances are reported by UML, OMT and CIMOSA.
REVIEW OF SIMULATION TOOLS
For simulation modelling too there is a lot of specialised simulation tools for the different application fields. The following Tab. 4 reports a list of simulation tools, classified according to three categories, corresponding to di fferent application engineering fields (BPE, MSE, ISE). Modelling
Arena [Aes97], [Van96]
Tab. 3 - Simulation tools/or s\'Slem simulation
Tab. 2 - Survey ofmedelling methods
3.
Tools Arena SiMPLE++ [SysOO]. [Aes97]. FirstSTEP [LevOO]. ARIS Simulation [Sch99]
Simulation
131
model to the simulation model identify a vertical integration line.
The ground floor (level I) is likewise divided into rooms for simulation tools
The "House of EE" needs integration of its building elements, in particular has to be achieved along two axis of the house and at different levels: along the X-axis (horizontal integration), integration at logical modeling level must be achieved in order to: i) cover different aspects ("world views") of the considcred system (i.e. BPE, MSE or ISE), ii) avoid information dispersion into heterogeneous and loosely conncctcd models; along the Y-axis (vertical integration), integration between modcling and simulation tools must be achieved in order to improve mode ling efficiency; along the X-axis, again, (horizontal integration), integration between different simulation models should be achieved to allow interoperation simulation models themselves.
House levels
Yaxis
Level 2: System Modeling
Level I: System Simulation
4.1 : : ,
Horizontal integration should be achieved independently on level 2 (system modelling) and on level I (system simulation). On level 2, horizontal integration means that system modelling should produce EE models, whose "logical views" must be connected accordingly, as required by their information content. For this kind of integration, ISO 14258 [IS097] should be considered, which suggests three ways to achieve interoperability of enterprise models: I. the integrated approach; 2. the unified approach; 3. the federated scenario. - In the integrated approach, a standard model is used to collect information from heterogeneous EE models; therefore, the overall EE· model IS represented by the collection of information from the different models, given by the standard model. - In the unified approach, a unified meta-model template supports model translation, and establishes semantic equivalence across EE models; therefore, the overall EE model is represented by the independent worldview of each model. - Finally, the federated scenario leverages on the capability of each model to address information exchange with other models through a standard communication interface; therefore, the overall EE model is represented again by the independent world view of each model.
Information ~y~!~.n.lyi~':V World Manufacturing yiews sy~t~111yi~~v _.
Business process view
X axis
Fig. 2 - House o/Enterprise Engineering Symbols used in Fig. 2 are reported in Fig. 3.
Multiple logical views of system model
~ Relationship between ---.
logical views of svstem model
Simulation model building
Simulation model
Synchronization and data exchange between simulation models
Fig 3 - Symbols 0/ the House Engineering
Horizon/al integra/ion
0/ En/erprise
Each modelling and simulation tool contained in Tab.1 and Tab. 2-3 is located in its (their) corresponding(s) room(s). In particular, while modelling methods, on level 2, describe the system's logical model as divided into multiple "logical views", the corresponding simulation model on level I is unique. In addition, the arrows connecting the logical views of system models on kwl 2 and the simulation models on level I identify horizontal integration actions. Finally, the arrows crossing leYeI 1 and 2 to connect the logical views of the systcm's
On level I, horizontal integration means that system simulation should address interoperability among simulation models. Here, interoperability solutions should basically follow a federated approach. To this end, thc High Level Architecture (HLA), developed to support interoperability among modelling and simulation systems in the US Department of Defence
132
[Dah98], should be considered. HLA is based on the notion of federation, where a federation is a collection of federates - that is simulation systems and other systems - that interoperate using services provided by the architecture itself (namely by its Run Time lnfrastmcture, HLA/RTI). Within HLA, each federate plugs into the federation by means of a HLA interface specification. The interface specification allows the federate to access RTI services, so that communication and synchronisation with other federates is possible By providing inter-process communication from tightly synchronous to completely asynchronous [Fuj97], HLA is an effective solution for the synchronisation and data exchange requirements of a federation of simulation models.
4.2
This approach is discussed in detail in the next paragraph.
4.3
Interfacing modelling to simulation
At NIST research work is going on addressing the considered integration problem, the work is inspired by similar research carried out on standard infonnation exchange between different tools. Following NIST approach a flexible solution should be adopted for automated model building: the approach should leverage on a Neutral file adopted as a standard interface to implement translation from a system logical model in the simulation target of translation In fact, as already stated, system logical models are generated through adoption of a specific mode ling tool. Afterwards, they are translated according to the standard interface specification. The model built according to the standard interface specification is then converted to a simulation model, according to simulation constmcts of a specific simulation tool (see Fig. 4).
Vertical integration
should be achieved Vertical integration independently within each EE area. Starting from the system model developed on level 2, a transfonn function should support building of a simulation model for level I (integrating the different views of the system model). Automatic building of the simulation model may be achieved in two ways: I. Custom interface, linking a modelling tool to a specific simulation tool (application case approach); 2. Modular building, linking elements of a modelling ontology to elements taken from a simulation ontology (ontology case approach). With respect to the application case approach, several interfaces have been developed between modelling and simulation tools, including: Visio is a graphical BPM tool for business process engineering (i.e. BPE area), whose models may be directly transfonned into Arena simulation models [SysOO] by means of a specific Visio-Arena interface; ARIS models may be automatically translated to Simple++ simulation models to dynamically evaluate the perfonnances of ARIS process models (ARIS Simulation [Sch99]); VisFactory is a MSM tool for manufacturing systems engineering (i.e., MSE area), whose layout design and production models may be translated into a VisSim simulation model ([Eai99]) or into a Witness simulation model ([LanOO)). With respect to the ontology case approach, model building is carried out based on close correspondence between modelling objects stored in a logical model base and simulation objects stored in a simulation model library. For example, the Systems Entity Stnlcture/Model Base environment proposed by Zeigler [Zei90], provides a logical model base (storing conceptual components of reality) for which procedural models reside in a simulation model base
Modellng tool I
-""",,,,,,,,,,,,,,.,,,Y~-----y'
==,;"""'_
Neutral file - Interface
Fig. 4 - Flexible approach to model building Note that "n" logical models can be used to describe a manufacturing system (that is "n" modeling views), but, at the end of translation process, a unique simulation model is got (a simulation model which can be mn in a specific simulation tool). As regards the standard interface, reference can be made to IMES (Initial Manufacturing Exchange Specification), provided by NIST [NST98] for data exchange between different simulation tools. The alternative to the flexible approach, which can be defined to solve the integration problem, is a customized approach, which proposes a transfonnation "point to point", from system logical models. generated in a specific modeling tool, to a simulation model using a specific simulation tool. In this case a specific interface should be designed and implemcnted for any mode ling tool.
133
As a conclusion wc can say that next generation modeling and simulation tools will probably achieve impressive power from integration and interoperation allowing improved capability of virtual design of complex systems.
At a first sight, the two compcting approaches standard interface vs. customized interface - require the development effort listed in Tab. 4.
ACKNOWLEDGEMENTS System entity structure System entity structure design design 2
Model base design
Thanks are due to master thesis students Diego Cattaneo, Angelo Marco Roccia and Paolo Sotgiu for their contribution to the content of the paper.
Model base design Neutral file design
3
process
Transform design
REFERENCES [Aes97] Aesop GmbH (1997) SiMPLE++ Reference Manual Vcrsion 4.1. Aesop GmbH, Stuttgart, 1997.
Pre-processor design Post-processor design
[Ast97] Ast Engineering Services (1997). Qase Performance Engineering.
Table 4 - Development effort
[Bar98] Bartolotta A., Garetti M., Corradi E., Molteni L., Gronchi D. 1998. Using Plantfaber to design and re-engineer manufacturing systems. In Proceedings of the International Conference Competing in the information society, Genoa, June 24-26, 1998. (ESPRIT PROJECT W 22031).
As it can be seen, major design effort is expected from the standard interfacc approach. Moreover, the use of a standard interface probably implies thc necessity of an editing activity to provide further information required by simulation modeling activity, while a customized interface is supposed to be already organized in such a way as to guarantee a complete translation. Obviously, the higher time spent in designing and integrating information is recovered when changing logical modeling tools: in this situation a customized interface must be completely modified while a standard interface needs only a pre-processor set-up. 5
[Bar99] Bartolotta, A., Corradi, E., Garetti, M. (1999). Developing an ontology for the modelling of manufacturing systems. In Proceedings of IEMC99, Verdal, Norway, June 14-16. [BerO 1] Bernus P. (200 I). Some thoughts enterprise mode ling. Production Planning Control, 2001, vo!. 12, no. 2, 110-118.
CONCLUSIONS
The most important empowerment to tools supporting the design of complex manufacturing and logistics systems is coming from integration between mode ling and simulation techniques. In particular the following points are to be kept in mind: upgrading and enlarging the mode ling approach to the whole supply-chain or to the whole enterprise requires impressive power from corresponding tools; on the other hand, the solution of developing a global tool for logical mode ling or for simulation mode ling appears to be unrealistic; therefore strong efforts are to be made for integrating different tools from the vertical and horizontal point of view; integration between modeling methods has to be achieved through communication and overlapping between different tools; integration between simulation programs could be achieved through the use of communication and synchronization standards like High Level Architecture.
on &
[Car88] Carrie, A. (1988). Simulation of manufacturing systems. John Wiley & Sons, 1988. [Che76] Chen, P.P. (1976). The entity-relationship model. ACM transactions on database systems, vol.l, n. I, march, pp. 9-37. [Dah98] Dahmann, l.S., Fujimoto, R.M., Weatherly, R.M. (1998). The DoD High Level Architecture: an uodate. In Proceedings of the 1998 Winter Simulation Conference, pp. 797-804. [Dou96] Doumeingts, G., Girard, P., Eynard, B. (1996). GIM: GRAI Integrated Methodology for Product Development. In: Design for X, Concurrent Engineering Imperatives, Chapman & Hall, 1996. [Eai99] Engineering Automation Inc. (1999). Open Virtual factory. http://www.eai.com/products. [Fuj97] Fujimoto, R.M. (1997). Zero look ahead and repeatability in the High Level Architecture. 1n
134
Proceedings ot Ihe 1997 Spring Simulalion 1nleroperabilil.l' Workshop. Orlando, FL March 3-7.
[Spu93] Spur, G.. Mertins K, Jochem, R. (1993). Integrierte Unternehmensmodellierung. Bcuth Verlag. Berlin. 1993.
[Gam97] Gambit Communications (1997). Mimic Snmp Agent Simulator.
[Sch99] Scheer, A. W. (1999). ARIS- Business Process Modeling Springer-Verlag, Berlin, 1999
[lfi98] IFIP-IFAC Task force (1998). GERAM: Generalized Enterprise Reference Architecture and Methodology (1998) Annex A 10 1S0 15704. ISO TCI84/SC5/WGI N423.
[SysOO] Systems modelling corporation (2000). Simulation solutions from Systems Modelling. http://www.sm.com [Van96] van de Mortel-Fronczak, J.M. and Rooda J.E. (1996). On the integral modelling of control and production management systems. In Proceedings of Advances in Production Management Systems. 1996, pp. 171-176.
[IS097] ISO (1997) ISO 14258: industrial automation systems -- concepts and rules for enterprise models. http://www.mel.nist.gov [Jac92] Jacobsen. I. (1992). Object-Orientcd Software Enginecring: a Use Case Driven Approach. Addison Wesley.
[Ver98] Vernadat. F. B. (1998). The CIMOSA languages. In Handbook on Architectures on Information Systems, Springer-Verlag, Berlin, 1998, chapter 11.
[Jud90] Judd. R.P .. Vanderbok. R.S .. Brown. ME. Sauter. J.A. (1990). Manufacturing system design methodology: execute the specification. In proceedings of CIMCO 90, 133-152.
[Ver99] Vernadat F. B. (1999). Requirements for th simulation tools in Enterprise Engineering. 15 Int. Conf. On CAD/CAM, Robotics and Factories of the Future, Aguas de Lindoia. SP, Brazil, August 18, 1999.
[LanOO] Lanner Group. (2000). Lanner Technology solutions. http://www.lanner.com [Lar97] Larman, C (1997). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Prentice Hall. 1997.
[Wi191] Williams, TJ.. The Purdue Enterprise Reference Architecture. a technical guide for CIM planning and implementation. 1992, Instrument Society of America, Research Triangle Park, North Carolina, USA.
[LevOO] Levi, M. H., and Klapsis M.P. (2000). FirstSTEP Process Modeler- a CIMOSA Compliant Modeling Tool. Interfacing Technologies Corp .. http://www.interfacing.com
[Wu95] Wu, B. (1995). Object-oriented systems analysis and definition of manufacturing operations. International Journal of Production Research, 1995, voU3, no.4, 955-974.
[MacOl] Macchi. M. and Garetti, M. (2001). Enterprise Interoperability: a Critip} Survey of Modelling Methods with Special Concern to Manufacturing Systems Engineering, Proc. INCOM 200 I, Wien, Sept. 2001. [Mar88] Marca, D.A. and McGowan. CL. (1988). SADT: Structured Analysis and Design Technique. Prenctice Hall, New Jersey.
[Zei90] Zeigler, B.P .. Lou. C.1., Kim, T.G. (1990). Model Base Management for Multifacetted Systems. IEEE. 1990, pp. 25-31.
[Men98] Menzel, C, and Mayer, R.. J. (1998) The IDEF family of languages. In: Handbook on Architectures of Information Systems, SpringerVerlag, Berlin. 1998. chapter 10. [Par97] Park. T.Y .. Han, K.H., Choi, B.K. (1997). An object-oriented modelling framework for automated manufacturing systems. International Journal Computer Integrated Manufacturing, 1997, voL I 0, no.5, 324-334 [Rum91] Rumbaugh 1., Blaha M.. Premerlani W., Eddy F., Lorensen W. (1995). Object-oriented modeling and design. Prenctice-Hall international, Englewood Cliffs. 1991.
135