Mechatronics 12 (2002) 12391258

Design and simulation of component-based manufacturing machine systems

Josef Adolfsson a, Amos Ng a,*, Petter Olofsgrd a, a b b Philip Moore , Junsheng Pu , Chi-Biu Wong b
b

Department of Engineering Science, Centre for Intelligent Automation, University of Skvde, S-541 28 Skvde, Sweden o o Faculty of Computing Sciences and Engineering, Mechatronics Research Group, De Montfort University, Leicester LE1 9BH, UK

Abstract This paper presents the modular machine design environment (MMDE), a software environment that enables the virtual design/engineering of component-based manufacturing machine systems. It consists of a suite of highly integrated tools supporting the visualisation, design, programming, verication and evaluation of machine systems built from mechanical, electronic and software components/modules in a virtual environment. Using three-dimensional (3-D) graphical simulation with a number of add-on tools, MMDE supports visualisation, design, simulation and verication of both the physical model and control logic for design and/or re-conguring machine systems to satisfy new or changed application/customer requirements before any real implementation is made. System design, implementation techniques, and evaluation of MMDE in a real industrial test case are covered in detail. 2002 Published by Elsevier Science Ltd.
Keywords: Modular machine design and control; Virtual machine components; 3-D graphical simulation; IEC-1131-3

1. Introduction Agility has been recognised as one of the most important attributes for manufacturing machine systems to satisfy the needs of global competitive markets. By

Corresponding author. Fax: +46-0500-448598. E-mail address: amos@ite.his.se (A. Ng).

0957-4158/02/$ - see front matter 2002 Published by Elsevier Science Ltd. PII: S 0 9 5 7 - 4 1 5 8 ( 0 2 ) 0 0 0 2 7 - 2

1240

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

agility, it means that manufacturing machine systems are able to respond rapidly and cost eectively to production changes both in terms of volume and variety. To accomplish such a requirement, re-congurability, re-usability and extendibility are characteristics, which are highly desirable to have embodied from an early phase in the design and implementation process of the manufacturing machine systems. One prevalent approach to achieve enhanced re-congurability of machine systems is to adopt modular design and the use of standard components [1,2], so that agility is at least in-part realised by utilising existing components, simply by re-using and re-conguring machine elements, in response to new or changed application/ customer requirements. Numerous attempts, both from industry and academic sources have tried to address various aspects and levels of modular manufacturing machine system design and operation, from structural components, sensing and actuation components to control hardware and software. On one side, the endeavour of standardisation bodies is to address the open systems issues, allowing components from dierent vendors to be inter-operable and inter-changeable. At the same time, the emergence of distributed control technology makes it possible to distribute control and intelligence down to the device level [3]. It can be envisaged that such standards and advanced machine components with intelligent control capability could provide the basic building blocks of next-generation machine systems [4]. Nevertheless, until and when the number and variety of such components become widespread, it is critically important to have the supporting tools for machine builders to select, evaluate, aggregate and manage these building blocks in a systematic and exible manner. Such tools should facilitate engineers to design a system conceptually, to analyse and prove the functionality of the design in a virtual environment (information/software) and then generate the real machine system (e.g. control system conguration, control logic code, etc.) smoothly. 3-D graphical modelling and simulation tools have proven to be highly eective for rapid prototyping, visualisation and testing what-if scenarios in the manufacturing engineering domain [5]. The design of large scale manufacturing systems often utilises various discrete-event simulation tools for layout design, bottleneck analysis, throughput analysis, etc. [6]. Whereas, continuous simulation tools, such as computer aided robotic systems [7] are often utilised for the design, analysis and programming of individual workstations. Such systems provide facilities for evaluating dierent automation designs and equipment capabilities, in particular industrial robot based applications. Moreover, the same environment can be used for o-line programming the real equipment via code generation, thereby further shortening the machine delivery time. It can be seen that realisation of a virtual design/engineering environment for manufacturing machine systems can be achieved with existing or emerging computing platforms and software tools. However, when applying 3-D graphical simulation to the design of a component-based machine system, one critical issue is to ensure an eective and viable methodology for building machines from their associated components so that the tools emerging can be exploited to their best eect in the machine system design process. Such methods should allow the transfer of the design between the virtual environment and the real environment seamlessly. Other than the graphical visualisation of the machines physical com-

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

1241

ponents, simulation and verication of the control and application logic in a virtual environment is also a viable aspect. The accompanying tools implemented should be highly integrated and supported by a component repository so that existing virtual components and company knowledge can be re-used and managed eectively. This paper presents the modular machine design environment (MMDE), a virtual design/engineering software environment that enables the visualisation, verication and evaluation of the physical design and control logic of component-based manufacturing machine systems. It is an integral part of the VIR-ENG (see Section 2) research project, which addresses the research issues identied above. Within the VIR-ENG research programme, the objective of the MMDE work-package was to develop an environment that facilitates machine design engineers to design a system conceptually, to analyse and prove the functionality, to visualise and test what-if scenarios in the machine design process, using advanced three-dimensional (3-D) graphical modelling and simulation technology. Delmia simulation products, Quest [8] and IGRIP/Envision [9], were adopted in MMDE to make use of the features of both discrete-event simulation and continuous simulation respectively. Furthermore, these packages represent advanced simulation technology widely used in both industry and academia. The objective in creating MMDE was to utilise an underlying components-based paradigm in the realisation of a modular machine design tool-set. To facilitate the integration of Quest and IGRIP/Envision within such a components-based environment, a generic software model for creating virtual components in these packages have been devised in MMDE. Software tools that build on this model have also been developed using the services oered by the simulation packages. Such a generic model and its corresponding tool-set integrated with Quest and IGRIP/Envision will also be discussed. This paper is organised as follows: Section 2 gives a brief overview of the VIRENG project. MMDE is presented in Section 3. The generic model for building virtual components is discussed in Section 4. The implementation techniques applied for MMDE are described in Section 5. Section 6 briey introduces the VIR-ENG demonstrator, an assembly workcell that demonstrates the VIR-ENG concepts and tool-set.

2. VIR-ENGa brief overview MMDE was a major facet of the ESPRIT/IST research project Integrated design, simulation and distributed control of agile modular manufacturing machine systems (VIR-ENG). The project aim was to develop highly integrated design, simulation and distributed control environments for building agile modular manufacturing machine systems which oer the inherent capacity to allow rapid response to product model changes and feature variants [10]. Four work-packages and their associated tasks were identied to facilitate the project. Fig. 1 depicts these packages and their inter-relationships. Among these work-packages, MMDE and DCSE are the major environments, which support dierent facets and activities in the machine system life cycle. While

1242

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

Fig. 1. Work-packages in VIR-ENG.

MMDE provides the tools to support all facets of the design process using graphical simulation, DCSE is designed to provide an integrated environment to facilitate distributed control system design and its operation. Uniquely, DCSE is partitioned into three main elements, namely, the control system design environment (CSDE), the component design environment (CDE) and the distributed run-time environment (DRE). MMDE and DCSE are highly integrated, whereby the physical layout, kinematics, mechanical constraints and sensing scheme of the virtual machine system designed and validated in MMDE are transferred to DCSE as the blueprint for the further development and deployment of the control systems. The control logic created in MMDE, which is used to drive the simulation, is also transferred to DCSE for developing the machine and application code of the real machine systems. Furthermore, run-time data, once available from the real machine system, is gathered from DCSE and can be used to validate and calibrate the virtual model developed in MMDE. This serves as the feedback in the machine design process. In order to facilitate the seamless integration between MMDE and DCSE, the underlying infrastructure & integration services (IIS) is needed to provide the services for these two environments to exchange design models, information and data. All VIRENG packages are designed and implemented to support and encourage re-usability of machine components. In particular, IIS comprises a component library, which serves as a central repository for components designed in the VIR-ENG environments.

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

1243

3. Modular machine design environment From the viewpoint of end users, MMDE consists of two major environments: (1) the design and simulation environment and (2) the programming environment. The design and simulation environment in MMDE is where the virtual model of the machine system is produced, tested and evaluated. The programming environment of MMDE provides the programming interface that allows users to dene the control logic for driving the virtual machine system. As one of the unique features introduced by VIR-ENG, the control logic to drive the simulation entities is described using programming languages dened in IEC-1131-3 [11]. The same control logic, represented using IEC-1131-3 languages, once proven on the virtual machine is also used with the real machine. 3.1. Using IEC-1131-3 standard languages Nowadays, most commercial simulation software packages provide one or several programming interfaces (largely language-based) for design/simulation engineers to develop programs to control and process the simulation models. Whilst these languages are generally powerful and exible to control every aspect of the simulation models, however, users have to be procient with these languages in order to program the simulation to resemble real-world behaviour. At the same time, the programming models of these languages usually contrasted greatly with real machine programming. O-line program generation can be very useful in translating the simulation program to machine control code. However, such features are only generally available for conventional machinery such as industrial robots and CNC machines. O-line programming for special purpose automation equipment that is built from components such as sensors, actuators and motion controllers, etc., is not available. Current practice in the main on such systems is that no use is made of simulation tools and the control logic is developed on the machine system once built. However, even where graphical simulation has been applied during the design process the control engineers have to re-implement the control logic described in a simulation model when developing the software for the real control system. Misinterpretation and sub-optimal implementation is likely to be the result of such a discontinuity in the process and many of the inherent benets from the use of simulation are lost [12]. Furthermore, the accelerating trend towards mass customisation and rapid product introduction is dictating the need for ever-more exible machine systems/automation solutions produced in much shorter lead times with proven design concepts. On the other hand, it has been recognised that complexity in the design process is increased from the need to use simulation languages to describe application-related logic. For example, application logic that determines the part routing, co-ordination of dierent components, exception handling, etc. As a matter of fact, the logic, as well as the corresponding simulation code to control a primitive machine component is usually fairly simple and straightforward. For example, actuating and retracting a pneumatic cylinder, lifting up and down an elevator, robot grippers to grasp and

1244

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

release a part, etc. In all these examples, the machine components are driven sequentially by Boolean logic, which can be represented by very simple state transition abstractions. However, complexity in the logic increases enormously when controlling a workcell which is built from several workstations which in turn are the aggregates of tens or even hundreds of such primitive components. Based on these important observations, it is believed that it is possible to extract the complex highlevel logic out from the simulation code and delegated this to an external control logic execution engine. The essential simulation code used to drive the primitive simulation entities can then be much simplied. Based on the above observations and concepts, the use of a standard industrial programming language, IEC-1131-3, to program and control simulation models, is adopted by MMDE. When compared with other related research, MMDE is unique in that IEC-1131-3 is not only used as the language for users to program the simulation model but also serves as the control logic specication for the further development of the control system design and deployment in DCSE (see Section 2). To accomplish the notion of using IEC-1131-3 to program the simulation logic, one could take two dierent approaches: (1) to develop a translator to convert IEC1131-3 programs into the native simulation language that drives the simulation entities; or (2) directly use the IEC-1131-3 execution program to control the simulation. The second approach requires the development of a communication medium that enables data to be exchanged. Whilst the rst approach sounds straightforward, it has a number of disadvantages in terms of concepts and implementation that prohibited its use. While IEC-1131-3 consists of a set of standard languages, simulation languages are not standardised. Implementing individual translators for each simulation package would be tedious and error prone. Furthermore, there are inevitably many discrepancies between the software models of graphical simulation software and the physical control system. This makes automatic translation extremely dicult if not totally infeasible. On the other hand, direct control by exchanging data enables us to facilitate the principle of encapsulation and information hiding. Such data generally represent the control signals and device status but also MMDE-specic data (e.g. simulation clock time, etc.) are also included. Internal information and procedures of the IEC-1131-3 execution program and the simulation software are separated from each other. Since both environments see only the data shared. Once the format of data exchanged has been dened, it gives the exibility to continue the development in each side independently. In other words, it facilitates the loose coupling between the control logic execution engine and the simulation software package, so that it is possible to control the simulation model using dierent kinds of control logic execution programs. 3.2. Organisation of the MMDE modules Based on such a conceptual framework, several interface modules have been developed to provide the linkages between the two environments as well as the supporting tools. The basic organisation of these modules is illustrated in Fig. 2. The

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

1245

Fig. 2. Basic organisation of the MMDE software modules.

data shared between the environments is termed virtual I/O (VIO) because it generally contains the data that represents the real I/O in an industrial control system. However, other IEC-1131-3 data such as function block data and simulation data such as simulation clock time are also exchanged through this mechanism. The communication gateway is therefore called VEVIO, standing for VIR-ENG virtual I/O. Since multiple parties can run and update the shared data concurrently. VEVIO applies a sophisticated synchronisation algorithm to provide mutual exclusion for the shared data with minimal overhead. Virtual component controllers are the software units that control the objects in the simulation. They are developed using native simulation language or generalpurpose languages such as C/C compiled and linked with the libraries containing simulation functions supplied by the package. Through the VEVIO interface, virtual component controllers possess the capability to link to the VEVIO. To facilitate the design process using the component-based paradigm, an integrated interface is provided for both the programming environment and the design and simulation environment. Users can also design and create new components to be added to the component library under the same environments through a set of MMDE-specic modelling aid functions. These functions are developed to provide modelling aids to the machine designer so that they can construct the virtual models of the machine components in an ecient and error-free way, especially those unique virtual components, which are introduced by MMDE. One kind of these components is the virtual sensor. The programming environment also provides a suite of monitoring and debug tools. These tools allow dynamic visualisation and debugging of the control logic

1246

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

ow through real-time interaction with the graphical simulation model. These functions allow users to select dierent views of the system and focus on the potential problem area in order to verify and debug the control logic.

4. A generic model for creating virtual component controllers In contrast to the physical world in which real components could be driven by almost an innite form of media, all kinematic movement in the virtual world involves only a set of function calls that updates the graphical entities and their corresponding data attributes. Therefore, it is believed that the essential simulation code used to drive a simulation entity can be, to a large extent, generalised into a set of parameterised routines which, can be predened and saved in form of code templates or libraries, provided that all high-level control logic is extracted from the simulation code and delegated to an external control logic execution engine. In MMDE, such preconditions have been fullled by having the IEC-1131-3 engine to execute the coordination logic. Despite the idea of having such parameterised routines being conceptually sound, considerable eort would be required to develop such routines for every simulation package used, which in principle are used to drive the same component in the virtual world. Therefore, extensive study and testing has been undertaken on how to generalise the programming models of dierent simulation packages in order to produce a single generic model. Firstly, the model is devised to be platform-independent. It allows implementation using dierent simulation software packages and utilising their own simulation language features. Secondly, as the model provides a systematic and coherent way of programming virtual components, it should lead to a process, which is benecial to both MMDE developers and nal users. To us, the MMDE developers, it provides the guidelines for developing the parameterised simulation routines and the supporting graphical user-interface (GUI) tools. From the user perspective, this process opens the possibility of automatic or semi-automatic simulation code generation. They can select from the list of predened templates, input corresponding parameters and then generate the virtual component controllers required according to the guidelines derived from the generic model. Fig. 3 gives a schematic illustration of how a virtual component controller is developed, starting with the generic model used by the MMDE developers. It is worth noting that the format of the templates and virtual component controllers during various phases are intentionally left unspecied because these must be platform-dependent. They may exist in a form of Windows dynamic linked library or text le containing source simulation code. 4.1. Virtual components and simulation entities In the MMDE virtual environment, a virtual component is dened as the abstracted counterpart, which represent a real component in the physical world. The word component is utilised because it possesses the same meaning as the term

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

1247

Fig. 3. The process of creating a virtual component controller based on the generic model.

component used throughout VIR-ENG packages. It exists in the form of an information structure, containing the attributes that represent the specication of the component. In other words, attributes of a virtual component are actually the attributes of the real component. For a motor, these attributes denote the items in its electrical and mechanical specications. Fig. 4 shows the relationship between virtual components and simulation entities using UML class diagram notation [13]. A virtual component contains one or many simulation entities. For a virtual component to be able to be retrieved, assembled and tested in the MMDE environment, it must have one or several corresponding simulation entities. In contrast with virtual components, simulation entities are more tightly linked to the simulation software. They represent the concrete software objects that exist and function in the simulation software, on behalf of the virtual components that contain them. In the simulation software, they may exist as the basic simulation units supplied by the software (e.g. elements in Quest or devices in IGRIP/Envision) or programming units (e.g. procedures or functions) executed by the simulation engine or mixtures of both. They are called entities mainly to distinguish them from components. Attributes of a simulation entity are thus also tightly linked to the simulation software. These attributes are signicant to the simulation software only. Their values might be derived from the attributes of the real component or even have no relation to them at all (e.g. for those concerned with graphical display). For the purpose of graphical simulation, a basic classication scheme has been adopted in order to develop the model for virtual component controllers. The basic classication of simulation entities is also been shown in Fig. 4.

1248

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

Fig. 4. Relationship between virtual components and simulation entities.

4.1.1. Virtual sensing entities These are the simulation entities that function as virtual sensors. By utilising the low-level functions supplied by the simulation software. Part/product location and identity in the virtual environment are detected and the corresponding signal is written to the VIO. The format and semantic of the data that a virtual sensing entity passes to the connected VIO channel are solely determined by the real sensing component it represents. Examples are: Simple sensorsTrue or false signals for a simple proximity or photoelectric sensors. Part detection sensorsDetect the part types and transform them into numbers or strings of characters, e.g. bar-code readers. Intelligent sensorsLife-cycle data (e.g. counts) and status of the sensors. 4.1.2. Virtual process and non-process entities Both process and non-process entities are associated with one or several VIO connections. They possess internal states and carry out actions. Process entities are dened as the entities that carry out actions, which are related to manufacturing/ assembly processes and transportation in the virtual environment. In the simulation software, these actions are realised by changing the attributes and position of the

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

1249

graphical virtual part. Compared with process entities, actions carried out by nonprocess entities do not directly inuence the virtual part. In most cases, they serve as the auxiliary entities to process entities, which would determine their actions to be taken by referencing the states of a set of associated non-process entities. A typical example is a pneumatic-actuated stopper, which is placed in the middle between two conveyor sections modelled as two virtual process entities. The stopper changes state to up or down and updates the graphics to reect the change according to the value in the Boolean I/O channel. Unless the state of the stopper is down, the rst conveyor section may not transfer the part to the next section. 4.1.3. Virtual static entity Static components represent static physical objects and may exist in a broad range of varieties (e.g. containers, proles, stands, to name but a few). They do not respond to any control signal and possess no internal state and so they are not related to any VIO connection. Therefore, this kind of entity will be excluded from our further discussion. Nonetheless, it should be pointed out that they are important elements for the machines structural design and overall system layout. 4.2. Structural model of simulation entity Virtual process and non-process entities are the most complex type of simulation entity in our model. Fig. 5 below shows the structural relationship between objects that constitute such an entity. The relationship between the virtual component and simulation entity has been described in Section 4.1. Discussions on other objects will be given in the following sub-sections. 4.2.1. Graphical entity Graphical entities represent the graphical object manipulated by a simulation entity. Since a simulation entity may exist as a pure programming unit. In such case, it is possible for a simulation entity to exist without owning any graphical entity. 4.2.2. Action table The term action is used here as the generic name to denote all functions or operations carried out by a virtual process or non-process entity. As mentioned, actions carried out by process entities are exerted to the virtual part/product while actions of non-process entity do not have direct eect on them. In the simulation software, actions are equivalent to low-level simulation function calls and usually involve kinematic movement of the graphical entities. Therefore, an action table contains the information that relates the low-level simulation functions, kinematic functions/ data and index to the run-time attributes that accomplish actions of the process or non-process entity. In 3-D graphical simulation, kinematic functions are signicant in producing visualisation eects. But more importantly, they provide the timing data of the actions carried out by the simulation entities. Depending on the simulation software being selected, kinematics may represent dierent software abstraction. There are two common approaches: (1) make a function call to the simulation

1250

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

Fig. 5. Structural relationship between objects which compose a virtual component.

engine and (2) the simulation engine reads in and executes kinematic scripts saved in form of les. For the latter approach, users need to prepare such scripts in advance and save them into les before running the simulation. Some other software packages are more exible in that they allow kinematic scripts to be generated on the y. In either case, parameters represent the properties that govern the movement of the graphical entities. 4.2.3. State transition table The term state transition table (STT) is used to describe the data structure that relates the internal states, transitions and actions of a simulation entity. It is important to note that every process (and non-process) entity may contain one and only one STT. Each STT may only be associated with the simulation entity that owns it. The implication of such a structural arrangement is that a simulation entity cannot access the state of another entity for a state transition in order to prevent any hidden co-ordination logic between virtual components. At the same time, the STT is concealed from external clients, implying that only the simulation entity can change its own state. This is based on observations described early in this section. All highlevel and co-ordination logic must be programmed in the IEC-1131-3-based programming environment, and thereby can be veried and tested with the external IEC-1131-3 control logic engine.

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

1251

4.2.4. Virtual I/O connection When running the simulation, each simulation entity reads/writes values to the VIO connection objects that are associated to it individually. However, instead of being directly linked to the simulation entity, VIO connections are aggregated objects to virtual components. Every connection has a data type and index. In order to establish the run-time connections, users have to correctly relate the VIO channels with the components when preparing the simulation model. 4.2.5. Run-time attribute Run-time attributes contain the data that determines the behaviour, mostly concerning timing issues of the activities carried out by a simulation entity. They are accessed by the simulation entity when performing actions on the part. It could be possible that run-time attributes are embraced into the simulation attributes. They are intentionally separated into individual objects so that they can be accessed and updated by the DRE package as individual units. 4.2.6. Part transfer table Part transfer table (PTT) is the lookup table that relates the states of simulation entities to the output (next simulation entity) where they should transfer the part/ product to. Such transfer may be implemented as attaching the part to another virtual machine or formally passing the part using functions of the simulation language. The latter usually occurs in the case of discrete-event simulation. Only a virtual process entity contains PTT as they directly deal with transportation issues. In contrast to STT, PTT may relate the states of more than one simulation entity. For example, the following is a rule stored in a PTT: ThisEntity:State Standby AND NextEntity:State Standby AND StopperBetween:State Down THEN Transfer to NextEntity ENDIF IF It is the sum-up state of the active process entity and its related non-process entity that determines the transfer action on a workpiece. 4.2.7. Monitoring error A monitoring error object species an error that is inconspicuous or hard to be detected by simply looking at the animation or checking the simulation results and thus preferably monitored and reported automatically by the simulation software. Such errors include: Collision errorsThe unexpected overlapping of two graphical objects. These errors reect incorrect timing or bad synchronisation logic, which must be detected when running the simulation.

1252

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

Logic errorsErrors due to conicting values or an illogical combination in the states of simulation entities. Occurrence of such errors usually reects a programming error in the control logic execution engine. In most cases the occurrence of a collision error is the result of a logic error. Collision errors are much more demanding to be monitored than logic errors because of the computations spent to detect overlapping graphical envelopes. It is the responsibility of the user to identify suitable forms of error monitoring and avoid any redundancy. 4.3. Behaviour model of the simulation entities The behaviour model of a simulation entity can be illustrated by the sequence diagram of a very simple example. Consider a virtual workplace component, which is modelled by a single process entity called wp1. wp1 can be only in one of two states, namely, standby and rotated. It is connected to the VIO channel boolChannel1. When the channel value is FALSE, wp1 should stay at or switch to the standby position. By the same sense, it should stay at or switch to the rotated state when the channel value is TRUE. The only condition for wp1 to transfer a part to the downstream component (simply assume it to be workplace wp2 represented by a similar process entity) is when wp2 is at standby state and wp1 itself is being rotated. The sequence diagram in Fig. 6 shows the activities and interaction between objects

Fig. 6. Sequence diagram showing the interactions between objects within a virtual component.

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

1253

that constitutes the virtual component. For the sake of brevity, activities of wp2 are not shown in detail here. As shown in Fig. 6, it should be noticed that only actions would consume simulation time. Other activities consume computation (real time), but without the simulation clock being advanced. In other words, there would be no latency due to the operation of the model.

5. Implementation techniques The implementation of MMDE involved integrating a range of software tools including both in-house developed modules and packages supplied by third parties. The design and simulation environment in MMDE was developed using IGRIP/ Envision and Quest. The IEC-1131-3 programming environment is built on ISaGRAF PRO and I/O development tools supplied by AlterSys [14]. These particular software packages were chosen because of their functionality and extendibility, which enables the MMDE implementation. 5.1. Continuous simulation in MMDE IGRIP/Envision is a continuous simulation package for simulation and o-line program generation of automated manufacturing equipment, in particular industrial robots. In MMDE, IGRIP/Envision was used for dening motions and behaviours of machine components and individual workstations. Customisation of the IGRIP/ Envision simulation package has been implemented using the shared library (SHLIB), AXXESS API and low-level telerobotic interface (LLTI) [8]. Fig. 7 shows

Fig. 7. Implementation of the MMDE modules using IGRIP/Envision and ISaGRAF.

1254

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

the interface to IGRIP/Envision in MMDE. The virtual component controllers are implemented as a set of functions that are developed based on the generic model. By invoking the AXXESS and SHLIB functions to manipulate the IGRIP/Envision graphical objects, these extended functions control the behaviour of the simulation entities based on the data in the VIO connections and the conguration of the virtual components. The LLTI processor supplied by IGRIP/Envision is used as the simulation engine that executes these extended functions. A separate user-input module is also developed for users to congure the virtual components before running the simulation. All extended modules in IGRIP/Envision are developed using the C/ C programming language. For the control logic execution, a VIO driver has been developed using the ISaGRAF PRO I/O development toolkit. This driver enables the ISaGRAF target, which is the control logic execution engine to communicate with the LLTI functions via VEVIO. The ISaGRAF workbench is the programming environment for dening the IEC-1131-3 programs. Customisation of the workbench enables users to establish the connection between IEC-1131-3 elements and the VIO channels.

5.2. Discrete-event simulation in MMDE Quest [9] is a 3-D discrete-event simulation package designed for simulating discrete-part production systems. Within MMDE, Quest is used in the design and simulation of the manufacturing machine systems that encompass a number of modular machines. Quest is object-based software in which all entities in the simulation model are classied into a number of element classes. Simulation programs, written in a procedural proprietary simulation language called Simulation Control Language (SCL), can control actions and behaviours of individual elements. Quest also supplies another programming language called Batch Control Language (BCL). It can be viewed as a text-command version of the menu buttons in the GUI to control the Quest environment and manipulate the simulation model. This is in contrast to SCL, which is used to program the detailed rules that govern the behaviour of the model as it runs. Quest allows BCL commands to be called from SCL and vice versa. Such an intermix of SCL and BCL code allows powerful and exible ways for all-facet control of the virtual machine systems in Quest. Based on the same software design, the implementation strategy for integrating Quest within MMDE is fundamentally the same as that used with IGRIP/Envision. The major dierence lies in the fact that SCL and BCL have to be used to act as the low-level code to govern the behaviour of the simulation entities representing VIRENG components within the virtual environment. In other words, in Quest the generic virtual controllers are implemented using a mix of SCL and BCL instead of C with the AXXESS library, which is the case in IGRIP. Similarly, MMDE supplies a rich set of well-dened SCL templates for generating the generic virtual controllers. To add the MMDE-specic functionality to the simulation software, a set of SCL programs are also developed in the form of SCL macros. Each macro

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

1255

program is associated with a user-dened button within the Quest GUI so that from the perspective of users, invoking these MMDE functions is the same as Quests other inherent menu options. An SCL macro has been developed to compile SCL programs generated from the SCL templates and automatically links them to the entities inside the simulation model based on the information dened by the users.

6. A full-scale demonstrator To demonstrate the concepts and tools developed within VIR-ENG to the processes of design, building and operation of machine systems, an exemplar industrial cell was commissioned in Euromation (formerly Volvo Automation, a consortium member of the VIR-ENG project) for the assembly of automotive cylinder heads. The cell was suciently complex to demonstrate all facets of VIR-ENG integrated tool-set and methodology. It consists of several modular machines built from heterogeneous machine components and control systems. The major components of the demonstrator include: A valve-insertion assembly station, which consists of a gantry unit, an assembly head, a tilt table and a valve magazine (controlled by a LON control network). A gantry robot (controlled by a Siemens S7 controller), which is responsible for loading and unloading cylinder heads to and from the feed conveyors of the assembly station. Several sections of powered roller or belt type material handling conveyors (controlled by a SDS control network) for conveying parts within the workcell. An AGV with a guide-wire track (controlled by a LON control network). The central co-ordinator or supervisory system of the demonstrator is a PC-based controller. The control programs are also written using the IEC-1131-3 programming languages. Cylinder heads with 4- and 5-cylinder model variant are the products assembled in the demonstrator. Fig. 8(a) shows the completed simulation model of the demonstrator in Quest. An IGRIP/Envision model of the assembly station is also completed for testing the complex logic of the assembly operation. MMDE tools developed to design and verify the control logic programs of individual machine components and workstations were fully evaluated on the demonstrator. As an illustrative example, Fig. 8(b) shows a snapshot of the process of verifying IEC-1131-3 programs for part of the conveyor system. All application programs were generated in MMDE and transferred to CSDE to be processed to become the nal control logic for the cell. Only additional logic that handles the electrical and air supply have been added in DCSE. It may be concluded that almost 100% of the demonstrator application logic programmed and veried in MMDE has then been seamlessly transferred and applied to control the real machinery.

1256

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

Fig. 8. Modelling and testing of the VIR-ENG demonstrator using MMDE tool-set: (a) the complete simulation model of the VIR-ENG demonstrator in Quest and (b) verifying the IEC-1131-3 programs for part of the conveyor system.

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

1257

7. Conclusions and outlook The use of virtual environments for designing and building component-based manufacturing machine systems can dramatically reduce machine/system development lead-times and provide proof-of-concepts. Selection, verication and evaluation can be done without the need to build, set-up and congure the real mechanical and control hardware for testing during the initial stages of the design process. This paper has presented MMDE, a suite of integrated tools supporting such virtual engineering concepts using 3-D graphical simulation. A current focus is on how to incorporate data gathered from an operational machine system to calibrate the components in the simulation model. Experienced designers can closely estimate the run-time performance of the machine systems. However, it is impossible for them to obtain accurate operating data during the design and simulation stage unless complex dynamic models of the mechanical components and their interactions have been built and embraced into the simulation model, which is not justied in most industrial projects. On the other hand, most modern machine systems are designed to allow operators to adjust or alter the variables on the machines. Changes in such variables imply tuning the run-time performance of the machine, which is subjective to the operators experience. In other words, the accurate operating data of the machine can only be obtained from running the real machine. Accurate calibrated virtual components can improve the delity of the current simulation model but furthermore, it is also important to future designs that re-use or re-congure the same set of machine components. Further details of this technique and other aspects of VIR-ENG will be presented in future publications.

Acknowledgements The contents of this paper are based upon the research output of the VIR-ENG project (ESPRIT Framework IV 25444). The authors gratefully acknowledge the support of the European Commission for the provision of research funding and other consortium partners for their collaborative input.

References
[1] Tsukune H, Tsukamoto M, Matsushita T, Tomita F, Okada K, Ogasawara T, et al. Modular manufacturing. J Manufact 1992;4:16381. [2] Rogers G, Bottaci GL. Modular production systems: a new manufacturing paradigm. J Intell Manufact 1997;8:14756. [3] Wenn D, Warwick K, Glover JPN. Distributed control of multi-axis robot systems using local operating networks. In: International Conference on Control, Coventry, 1994. p. 10005. [4] Pu J, Moore PR. Component-based image/model driven design of distributed manufacturing machine control systems. In: Proceedings of International. Conference on Recent Advances in Mechatronics (ICRAM 95), Istanbul, Turkey, 1416 August 1995, ISBN 975-518-063-X.

1258

J. Adolfsson et al. / Mechatronics 12 (2002) 12391258

[5] West AA, Harrison R, Wright CD, Carrott AJ. The visualisation of control logic and physical machine elements within an integrated machine design and control environment. Mechatronics 2000;10:66898. [6] Nwoke B, Nelson D. An overview of computer simulation in manufacturing. Indust Eng 1993;(July): 4356. [7] Craig J. Simulation-based robot cell design in AdeptRapid. In: Proceedings of the 1997 IEEE international conference on robotics and automation, Albuquerque, New Mexico, April 1997. [8] IGRIP/Envision, version 5.1, Delmia, Dassault Systemes, 2000. [9] Quest, version 5.23, Delmia, Dassault Systemes, 2000. [10] Pu J, Moore PR. Towards paradigm shift in machine design and control. In: Proceedings of Mechatronics 98the 6th UK Mechatronics Form International Conference, Sk vde, Sweden. o Amsterdam: Elsevier Science; 1998. p. 2330. [11] International Electrotechnical Commission. Programmable controllers part 3: Programming languages. Also British Standard BS EN 61131-3: 1993. [12] Wright CD, Case K. Emulation of modular manufacturing machines using CAD modelling. Mechatronics 1995;4(7):71335. [13] Rumbaugh J, Jacobson I, Booch G. The unied modeling language reference manual. AddisonWesley object technology series. Reading, MA: Addison-Wesley; 1998, ISBN 020130998X. [14] ISaGRAF PRO and ISaGRAF PRO I/O development tools, version 4.03, AlterSys Group, 2000.