PII:SO951-5240(98)00006-S
ELSEVIER
Application of the ‘Fusion’ method in designing a generic object-oriented modelling shell for manufacturing systems M Ziaaie Moayyed** and G C Vosniakos+ *University of Manchester Institute of Science and Technology, Department of Mechanical Engineering, Manufacturing Division, PO Box 88, Manchester M60 IQD, UK ‘National Technical University of Athens, Department of Mechanical Engineeting, Manufacturing Technology Division, 15780 Zografou, Athens, Greece
A generic object-oriented modelling shell (GOOMS) has been developed. The fusion object-orientation method augmented by a few custom developed auxiliary techniques has been used to create GOOMS. Implementation was based on C+ +. GOOMS can be used for modelling discrete-event systems such as manufacturing systems. The user can define an application domain in GOOMS by using internal or external application oriented information. ‘Job’ data is comprised of different functions, instructions, performance, and reports. The system can analyse a series of defined jobs to produce required functions, to instruct a selected processor for processing material (physical or virtual), and to return the analysed performance of the operation for output. GOOMS is presented at a framework level with little consideration of its user interface. Intermediate results can be obtained relating to manufacturing system scheduling. The main purpose of producing such results is proof of concept, demonstration of integration features of the shell and checking the mechanisms for manipulation of data and information. 0 1998 Elsevier Science Ltd. All rights reserved Keywords: fusion, manufacturing
systems, object-orientation,
Introduction
far. Each particular application selects and uses those characteristics or behaviour-patterns which are required in its own modelling scope. A generic modelling tool is best achievable by object-orientation mainly because of the definition and characteristics of objects”. According to Ref. 14, generic modelling of manufacturing system components is based on fundamental physics and engineering principles, as well as on information engineering principles, relating to the fundamental information inputs and outputs of the components or subsystems and their activities. In an effort to design and implement integrated manufacturing systems the concept of reference models has been explicitly or implicitly recognized to be of fundamental importance and implemented in an object-oriented fashion by Jochem’.
The need of developing a generic software tool for manufacturing system modelling is now accepted widely, the issues being the boundary of the integrated sectors and the generality in different applications and the combination of model types supported. Fishwick in Ref. 3 explains the use of conceptual, declarative, functional, and multimodels all
constraint
being
and
possible
spatial
models
to realise
as object-oriented models. The utilization of object-orientation in system modelling has mainly been application-oriented so *Corresponding author. Tel: 00-30-l-772-1457; 00-30-l-772-1197: e-mail:
[email protected]
system modelling
FaX
25
26
Application of the “Fusion”method: M Ziaaie Moayyed and GC Vosniakos
Coad-Yourdon’s OOA has been used as a modelling methodology for manufacturing systems, slightly modified into a methodology named HOOMA12. The differences are first that HOOMA starts with a functional decomposition of the system in order to define in essence modelling domains. Then, functional decomposition in the form of subsystem relationship diagrams is carried out further before class and object definition. State transition charts and activity cycle diagrams are used mainly for improving ease of derivation of the correct instance and message connections. Vosniakos and Williams” explore concepts relating to building object-oriented reference models for integrated manufacturing systems based on Coad and Yourdon’s object-oriented analysis It is advocated that the pure OOA method retains the possibility for creating ‘executable’ models. The main concepts introduced along with discussion of relevant examples are a phenomenological view, application-related views, abstraction hierarchy of objects and expansion ability of the model to advance from abstract to environment-specific reference models. A shop-floor model constructed using OOA can be seen as a ‘core’ model which can be used as basis for building application-specific views relating to the same domain. Categorizing the types of entities encountered in this domain, i.e. raising the level of abstraction, provides for a modular approach to building ‘custom’ views. Basnet et al.’ describe an object-oriented modelling environment for manufacturing systems. This system was based on the need for separation between the physical components and the information components in a system. Glassey and Adiga4 present a library of software objects for control and simulation of manufacturing systems. The primary objective of this project was to develop a set of simulation modules which simplified the task of assembling special purpose simulation models customized for individual research objectives. The object-orientation paradigm was chosen to provide reuse, extension and simplified maintenance of the software. In Ref. 7 a set of objects classes have been written in C++ as templates for creation of simulation models and simulation packages. A comprehensive description is given of the language’s fitness for this purpose compared with some other languages. In a somewhat application-oriented approach in the domain of FMS modelling application specific objects were created using a class hierarchy. New classes were defined by inheriting the generic features and adding the implementation specific feature?. A particular approach to generic modelling of manufacturing systems is the so-called ‘virtual factory’. The term came to existence in the early 90s after the birth of virtual reality. A typical example is the virtual manufacturing system developed by Onosato et al.‘. The concept mostly relates to the physical and informational aspects of manufacturing
systems. In that particular work extra effort has been put to integrating an object-oriented data-base system with the modelling tool. Virtual factory concepts are demonstrated in some commercial work too,9, where a virtual factory is created by pre-defined 3D-like objects combined with a CAD factory drawing and a link to statistical data. The problems concerning abstraction of a variety of application domains in a generic modelling tool and consequent areas of research are related to either: l
l
the complexity of the domains and interfacesinter-relations; or the lack of a fundamental modelling framework from the early stages of the development.
This work targets the second area of research. The outcome was GOOMS (generic object-oriented modelling shell). It is termed a ‘shell’ because it is not tied to a specific application. Therefore, there was little consideration of the user interface in relation to specific application models. Development of the system is presented in the following sections. Object-oriented
system philosophy
GOOMS The generic software tool developed should model conceptually any type of event-driven system, in order to analyse a defined job, to produce required functions, to instruct a selected processor to process material (either physical or virtual) and to return the analysed performance of the operation as a report to the user. In particular: A job is introduced to the system either by a user or a job jile. The job-data should be analysed by an analyser. The analyser produces required jiuzctions, ready to instruct a processor for processing a specified material. After the completion of the process, the processor will return the performance data to the analyser. The analyser analyses the performance-data for producing the report of the proposed job. The user will be provided with the required report. The modelling system should also be able to use external information relevant to particular applications including alternative jobs, functions, materials, processors, etc. The nature of the proposed software (modelling tool) is event driven. Some natural characteristics of the proposed model are given below, summarizing the nature of object-orientation, as a proper design method: users issue requests for identifying both objects and services provided by objects (operations); users are not able to directly access or manipulate data associated with objects (encapsulation); objects show meaningful classification and ubstraction either to their users or to each other; operations can be generic in that a service can have different implementations for different objects;
27
Application of the “Fusion” method: M Ziaaie Moayyed and GC Vosniakos
l
objects can share the code in their implementations as a whole or partially, without sharing data (modulatity).
Object-orientation and the ‘Fusion’ method
A systematic design method is desirable for a such generic problem domain, which, unlike a formal method, is generally less mathematical for both the representation and process part. In object-orientation the objects are likened to objects in the physical world, which send each other messages. These messages result in the invocation of methods, which perform the necessary actions. Classes are defined as a group of objects sharing the same interface, that is, responding to the same messages in the same ways. Object-orientation follows an executing procedure in which first objects come into existence, then they perform actions, and finally they cease to exist or become inaccessible. Therefore, the model is essentially dynamic (Ref. 2, p. 5). Data abstraction, compatibility, flexibility, reuse, extensibility, and maintenance are some of the advantages of object-orientation. From the variety of development methods available the large majority are first-generation methods. Fusion is a recent systematic second generation approach to object-oriented software development’. The Fusion method consists of three main phases: analysis, design and implementation. The analysis phase produces a set of models that provide a declarative description of the required system behaviour. The design models are developed from high-level constraints provided by the analysis models. The implementation phase shows how to map the design models onto implementation-language constructs.
Object attributes are defined at a high level of abstraction. There is no need at this stage to add application-oriented specifications and identification data to the proposed object. Each function, material, processor, or performance object will have its own identification which has a relation with the job identification while it stands for its own independent identification and attributes. The aggregation mechanism can also be used to provide further abstraction. There are three main aggregate classes in GOOMS object model: userinterface, ruler, operational-unit. The aggregate classes are not included in modelling at this stage, but
Userjntetface User
File
user-id llsqriority us-status
file-id fi_priority fi_status A
Ruler
G
reduces II
GOOMS
design
Analysis
GOOMS’s
analysis steps are as follows:Object model
development
The object model of GOOMS is shown in Figure 1. It is constructed based on information of classes, attributes and relationships. Objects and classes
The following are classes of GOOMS: usel; file, job, analysel; function, processol; material, performance, report. At this stage, only generic attributes are assigned to classes and objects, such as identification ( id), type (-type), status (-status), and priority (gtio;ty). Additional physical or geometric attributes can be considered specially for physical objects such as co-ordinates (_locx). As an example, the following are attributes of the class ‘job’: job-id, ,joh-type, job-status, and job-priority.
Operational_unit
Figure 1 GOOMS Object Model.
Application of the “Fusion” method: M Ziaaie Moayyed and GC Vosniakos
28
this concept is helpful for understanding the performance of the system and the process of modelling. Relationships The following
are typical relationships
of GOOMS
model: introduces, requests, produces, instructs, processes, returns, analyses, provides, checks.
GOOMS has two types of relationships in its modelling development procedures with respect to aggregation classes. For example, analyses Z, produces I, analyses ZZand produces ZZare the internal relationships in the aggregated class of ruler and requests, instructs and returns are external relationships to the aggregated classes of ruler and operational_unit. Both types of relationship are treated equally at the design and implementation stages because of the exclusion of the aggregation concept from the modelling procedures. System inte$ace determination
Scenario timeline diagrams provide a tool for thinking through the consequences of the interface design and visualizing how the system behaves. However, scenarios are limited because they provide only a snapshot of system behaviour. A simplified scenario for introducingjob is shown in Figure 2. In a generic modelling system, a job introduced to the system should be analysed by an appropriate analyser. Selection of the required analyser and its availability recognition are required before job analysis. Similarly, each operation has a logical relation with the next operation or event in the system. In this case, job analysis will be followed by the creation of functions (produce_function_data) required for further modelling purposes.
Note that a life-cycle expression can define a set of scenarios, whereas a timeline diagram can only show a single scenario. The process for forming the lifecycle model of GOOMS is based on generalization of scenarios. The generic life-cycle of GOOMS is: introducingjob. analysingjob. providing_report
instructinggrocessor.
Each of the above generic expressions expands into more detailed expressions describing the sequence of system operations and events. Most of these expressions have been extracted and translated from the scenarios of the model. As an example, a more detailed life-cycle for anatjwingjob will be as follows: request_analyses analyser_availabilit job-data-handling. producefunction_data Operation model
This defines the semantics of system operations declaratively in terms of change of state and the events that are output. The actual composition of the system state at any instant depends on what system operations have been invoked. A system operation may create a new instance of a class, change the value of an attribute of an existing object or send an event to an agent. The operation model specifies operations using preconditions (assumes clauses) and postconditions (results clauses) which are written as a series of descriptive clauses - schema - that have to be either true or false. In addition sends, reads and changes clauses are extracted from the results and assumes. Therefore, there is no information available about the intermediate states through which the system passes while the operation is active. Intermediate states depend on the implementation of the operation. Figure 3 shows a typical schema.
Interface model development
The interface model defines the input and output communication of the system and comprises a lifecycle model and an operation modellife-cycle model The allowable sequences (patterns) of object communication are called the life-cycle of the system.
[
Tcify_modIj.ll
Design
The design phase delivers models that show the following: how system operations are implemented by interacting objects, how classes refer one to another
Operation:
Select_analyser
Description: Select an analyser to analyse job-data.
Descn’ption:
The ‘user’ specifies
a model.
supplied user
Changes:
--
Sends:
analyscr: (select_analyser)
Assumes:
The previous job-data has been analysed completely.
The ‘analyser’
checks the availability of a ‘job’ for the model. If the job is available,
Reads:
then the ‘user’ does
inrroducejob.
Figure 2 Simplified scenario for ‘introducingjob’.
Result:
If am
asks for an analyser. Then a reauest messaee
is sent to the analvser.
Figure 3 ‘Analyser’ class description.
29
Application of the “Fusion ” method: M Ziaaie Moayyed and GC Vosniakos
and attributes of, and operations on, classes. Design entails development of the following models: Object interaction graphs
Visibility graphs
An object
interaction graph is constructed for each system operation to build the object messaging structures that realise the abstract definition of behaviour. It shows what objects are involved in the computation and defines how they collaborate. The first step is identification of the objects that are involved in the realization of a system operation. For instance, the operation request_analyser involves the objects job and analyser. In the second step the role of each object in implementing the operation is decided. Here, the analyser has been taken as controller and the job as a collaborator. The controller receives the system operation message. In the third step, the functionality of the operation will be distributed among the various objects involved. In the final step, the distribution of functionality of the system operation is recorded in an object interaction graph. The object interaction graph for select_analyser is shown in Figure 4.
class Analyser attribute analyser_id: character attribute analyser-priority: integer attribute analyser-status: character attribute analyser-type: character attribute analyser_ruling_file: character attribute constant user: exclusive User attribute constant job: bound Job attribute constant material: exclusive Material attribute constant function: exclusive bound Function attribute constant processor: Processor attribute constant performance: bound Performance attribute constant report: bound Report method analyser_data_handling( method method method method
)
display_analyser_data( ) integrate_analyser_information( ) access_analyser_information( ) display_analyser_information( )
method update_analyser_status( ) method method method method method method method endclass
The developed object interaction graphs have to be checked for both consistency with analysis models and verification of functional effect.
identify_material( ) analyse_job_data( ) build_generic_data( ) produce_function_instruction( ) request_processor( ) analyse_process_performance( ) produce_process_report( )
A sewer object must be visibZe to a client object for the client to send a message to the server. The purpose of a visibility graph is to define the reference structure of classes in the system, i.e. objects referenced by class instances and appropriate kinds of reference to these objects. As an example, for the analyser class, all the message arrows on the relevant object interaction graphs should be looked at. The analyser class has communication with job, function, processor, perforrnante and report classes in the system. The relevant visibility graph for the analyser class is shown typically in Figure 5. Examples of the visibility decisions for analyser are as follows: Reference lifetime: analyser sends messages in many object interaction graphs, therefore, it can be assumed permanent. Server visibility: jimction is the only class receiving messages by analysel; thus these references can be exclusive to analyser. Job and report objects receive messages from both user and analyser, so these references should be shared. Server binding: job, function, perjonnance, and report objects are components of the analyser and have lifetimes that are the same as the analyser. Thus they should be made bound, and appear within the analyser client. Reference mutability: all the references can be marked constant because they do not change with time. The developed visibility graphs are checked for both consistency with the analysis models and mutual consistency. Class description
Class descriptions are initially constructed using information from system object model, object interaction graphs, and visibility graphs. Class description will establish the methods, some data attributes, and object-valued attributes for each class of GOOMS.
(I.11
(1)
analyser_availability . . . . . ..
select_analyser User
lcompletejob
?.?!~:.:-~
Description: operafion: select_analyser Find out if the previous job has been completed. If it has, then check the availability
of selected analyser.
(1.1) (1)
If the analyser is available, then select it for next job-analysis.
Figure 4 ‘Select_analyser’
schema.
Figure 5 ‘Request_analyser’
object interaction
graph.
30
Application of the ‘LFusion” method: M Ziaaie Moayyed and GC Vosniakos
--Ia
Analyser
-l]
4
,
I
Report ]
Figure 6 ‘Analyser’ visibility graph.
As an example, the initial class description for the class analyser is shown in Figure 6. The class analyser acts as a representative generic class for alternative applications with a broad list of attributes covering different possibilities. It is capable of communicating with its environment using different methods to carry out necessary manipulation of objects, to handle data accordingly, to instruct devices properly and finally to provide the user performance reports of the system. The class descriptions are checked to ensure that all data attributes from the system object model are recorded, all object attributes from the visibility graphs are recorded, and all methods and parameters from object interaction graphs are recorded. GOOMS implementation Implementation is based on life cycle provided by the analysis phase object interaction graphs, and class descriptions provided by the design phase. The experience during the development showed that using life cycle is more convenient basis to order events. In the process of implementation, three elements of the translation to C++ code should be considered: life cycles, class implementation and method bodies. Life cycle
A life-cycle expression can be translated into a state machine, ready to implement in the programming language. For ease of implementation, state machines are developed using bubble diagrams, and the final result is expressed in the form of tables. The non-deterministic GOOMS machine is turned into a choiceless machine, see Figure 7. In this case, each possible set of states can be regarded as a new single state, resulting in an overall reduction of states. Taking the product of the choiceless machine, and representing the composite names with ‘.’ separator, gives the product machine in tabular form which can be implemented much easier. In a structured programme, the state machine will be modelled by keeping track of sets of states. This part will be the
foundation of the implemented so-called main programme.
code which is the
Class and method implementation
The developed class descriptions should be translated into class notations of the implementation language. The attributes and method signatures are compatible with C++ class notations. Method declarations in a class description become member functions in C+ +. GOOMS class attributes are kept private. Class friendship provides access from outside the class to these private data whenever required. For instance, class analyser is a dominant active class with a series of functions for manipulating the circulated data in the system, such as job data, function data, performance data, and report data. Therefore, class analyser is declared as a friend class in almost all the important classes in the model. The object interaction graphs from the design stage contain much of the information requirec d for the implementation of method bodies Data communication
The system should be able to communicate iinternally first, to circulate the data and manipulate them as required for any type of generic modelling concept. In addition, the programme will have communication to the external environment to transfer applicationoriented information for further specific modelling purposes. Figure 8 depicts the two layered communication concept. In the implementation process a specific data file has been attributed to each class of object in the system. These data files are declared as the objects of new class ‘file’ in the system. Class ‘file’ is a friend class to all other classes. For any generic model, the required data-files are listed and allocated automatically according to the system objects. The objects are introduced to the system interactively at the beginning of the program run. The second layer belongs to the particular application environment. Each application has its own particular information either as numerical data or as operational instructions. The application-oriented data can be stored in the external data files typically named after a corresponding class and an ‘.inf extension standing for ‘information’. Data handling
As the analyser is the main active class dealing with four important streams of data and information in the modelling system, a series of data handling methods are included as analyser’s methods. Job, function, performance, and report are those four important classes which define the data routes with analyser. Figure 9 illustrates the data handling concept through the main routes between the analyser and the above classes.
Application of the ‘Fusion” method: M Ziaaie Moayyed and GC Vosniakos
A similar concept can be applied to class user having its own data routes with classes job and report, or class processor having its own data routes with classes material, function, and performance with appropriate method definition, which, however, is not implemented yet. The required access to the data and information for analysis purposes can be implemented based on a
Figure 7 GOOMS
choiceless
(state)
machine.
31
hierarchical form. Figure IO shows a schematic structure of the hierarchical form of access.
Results and discussion Results are only of intermediate nature, e.g. attribute values before and after executing a job, obtained interactively on the computer screen to prove the
32
Application of the “Fusion” method: M Ziaaie Moayed and GC Vosniakos
1 access_report_inf. 1
1 accessjobjnf.
r)x(perfo._data_handling
funct._data_handlinl
acccss_perfo._inf.
access_funct._inf.
Figure 10 Hierarchical
Figure 8 Data communication
concept.
job_data_file
function_instruction_fle function-id . ... . . . . 1999fu
form of data access.
concepts implemented. A simple manufacturing system consisting of a number of stations and two automatically guided vehicles (AGVs) serving them was implemented as a testbed-example, see Figure II. For this system there is already experience through simulation in the ECSL language with combined visualization in a CAD system ‘I. The mechanism of modelling is based on the ‘circulation’ of modelling data and application information by a potentially intelligent engine, the analyser. This in the heart of the modelling tool, and can be of different type depending on the nature of the application, i.e. the analyser can be selected from a ‘library’. Job processing is based on the standard GOOMS processing mechanism that can be oriented towards any specific application. A job can be introduced to GOOMS either by the user interactively or from a job-data-file. Any job has its own identification along with other data such as associated material for processing, status and priority. Furthermore, any job can be defined in more detail in an information file. Following the processing of a particular job in the system, e.g. the job of an AGV picking up a palletized part from station no. 3, it is noted that after job introduction the main task of the analyser is to break down the job into functions: finding the origin repeating
.. . .. . .
process_plan_file
finding path segment checking path segment for availability moving AGV on this segment
. . . .. . . . .. . . .. Figure 9 Data and information
routes.
parking AGV on destination picking up palletized part The latter functions:
segment
can also be subdivided
into further
Application of the “Fusion” method: M Ziaaie Moayyed and GC Vosniakos
PARK
r-l TURN 1 NC
-
CENTRE
Rl-
Ill
BI-DIRECTIONALLAYOUT Figure 11 Simple FMS used as test-bed for GOOMS.
setting distance for moving pallet unlatching pallet on station engaging rollers moving out pallet disengaging rollers latching pallet on AGV In addition, a handshaking protocol can be foreseen to simulate communication procedures between AGV and pallet-station. This could be placed and executed first. Each function involves a number of methods, a processor and a material. The processor can be real or virtual. For example, for finding origin the processor is 1ocationJinder which is essentially implemented as a method that scans the location attributes of all network nodes, which are the ‘material’ operated on by the processor in this case. For jindinggath_segment the processor is route_ finder, i.e. essentially an algorithm to find the shortest route between two nodes in the network as well as alternative routes in case some segment is blocked. The material is, of course, path_segment. For checkinggath segment the processor is interjerence_resolver operating on material path-segment. This processor finds whether at any time during movement of the AGV from its origin to the ultimate
destination there could be interference by any other AGV or object in general. For moving_on_segment the processor is motion_ system and the material is the compound AGI/+ pallet+workpiece. The motion system is essentially a collection of methods implementing various types of motion in space. Other functions are related in similar ways to processors and materials. In addition, there are performance data associated with each function. This data is combined by the analyser to form reports which summarize the results of the job undertaken by the system. Performance data in our case are time related, i.e. idle time of transporter, motion time of transporter, pallet and workpiece, blocking time of path segment, waiting time of pallet and workpiece. Each of them is calculated according to associated methods. Complex scenarios have not been analysed yet, e.g. those involving proper scheduling of a number of interacting AGVs, pallets, stations and workpieces. A new class called scheduler should be introduced within analyser in order to cater for such complexity. Note that information files refer to objects and to attributes that combined perform the job introduced, by essentially changing the values of object attributes. The new value is derived according to some
34
Application of the “Fusion” method: M Ziaaie Moayyed and GC Vosniakos
procedure or rule (method) stored in relevant analyser files - status changing files scf - and are referenced by individual class methods. These are obviously application-dependent and may be simple, typically when they refer to one class, or complex when they involve consideration of a number of classes.
References
Conclusions GOOMS can analyse according to externally required logic a series of defined jobs in any domain to produce a sequence of required functions, to instruct a selected processor to process physical or conceptual material and to report operation performance indices to the user. There is some generic data attached to any proposed job regardless of the nature of the job. However, GOOMS constructs have to be ‘instantiated’ by provision of internal data and external information comprised of functions, performance compilation instructions etc. concerning the proposed job. Physical properties of manufacturing system elements can be integrated to conceptual behaviour properties of these elements in the model to provide a comprehensive modelling environment. Work in progress concerns defininition and classification of Analyser functions both independently of and according to application domains. There is also implementation work running in parallel concerning inclusion of simple behaviour rules through external files (as a first step) and knowledge bases (in the longer term) and also integration of CAD-graphics at object definition level.
6
7
8
9 10
11
12
13
14
Basnet CB, Farrington PA, Pratt DB, Kamath M, Karacal SC and Beaumariage TG Experiences in developing an object oriented modelling environment for manufacturing systems. Proc. of the 1990 Winter Simulation Conference. Dallas, Tenas, 1990, pp. 477-481. Coleman D, Arnold P, Bodoff S, Do&n C, Gilchrist H, Hayes F and Jeremaes P Object-oriented Development; the Fusion Method. Ennlewood Cliffs. New Jersev: Prentice Hall. 1994. Fishwick PA-Simulation Model Design. Proc. of the 1995 Winter Simulation Conference. Vitginia, USA, 1995, pp. 209-211. Glasey CR, Adiga S Berkeley library of objects for control and simulation of manufacturing (BLOCS/M). In: Pinson I-J, Wiener RS. editors. Aoolication of Object Oriented Promnmming. Reading, MA: Ad&son-Wesley, 1990. Guo D, Norrie DH and Fauvel OR Object oriented flexible manufacturing system. Proc. of the 1990 Summer Computer Simulation Conference, Calgary, Alberta, Canada, July 1990, pp. 225-230. Jochem R, Rabe M and Sussenguth W An Object Oriented Analysis and Design Methodology for CIM systems, TOOLS’89, 1989, pp. 75-84. Joines JA and Stephen DR Design of Object-oriented Simulation in C+ +. Proc. of the 1994 Winter Simulation Conference, Florida, USA, 1994, pp. 157-165. Onosato, M and Iwata, K ‘Development of a virtual manufacturing system by integrating product models and factory models’, Annals of the CZRP Vo142 No 1 (1993) 475-478 ProModel for Windows Users Manual. Rapid Modeling Corporation, USA, 1996. Vosniakos, G and Williams, M ‘On reference modelling of integrated manufacturing systems using OOA’, IFIP Transactions B: Computer Applications in Technology Vol B-15 (1996) 47-59 Vosniakos GC, Ziaaie-Moayedd M and Mamalis AG Design of a system for computer-aided engineering of manufacturing facilities. Computer Integrated Manufacturing Systems (in press). Wu, B ‘Object-oriented systems, analysis and definition of manufacturing operations’, International Journal of Production Research Vo133 No 4 (1995) 955974 Zobel RN Simulation in Product Design - A Concurrent Engineering Approach. Proceedings of the ITEC 93 Concurrent Engineering Conference, London, UK, 1993, pp. 56-62. Zobel RN Generic Models for Rapid Product Simulation. Proc. of the Conf on Modelling and Simulation, 1994, pp. 1066-1070.
Barcelona,
Spain,
