Teaching manufacturing systems integration through data modelling and network exchange simulation George C. Vosniakos National Technical University of Athens, School of Mechanical Engineering, Manufacturing Division, GR 15780 Zografou, Athens, Greece E-mail:
[email protected] Abstract This work outlines an approach for teaching the concepts and practicalities of manufacturing systems integration to mechanical engineers. The approach taken is that of data or soft integration. The aim is to achieve ‘minimalist’ integration among six computer-based manufacturing system areas: design, production planning, process planning, material control, shopfloor scheduling and control, and quality assurance. Reference models describing the data exchange between these areas are given. Data flow and concurrency, the formulation of queries and composition of answers between applications are discussed based on an implementation of data models as a relational database system. The data refer to a bicycle-making company and serve as a realistic basis for experimenting with the realities of designing and putting in operation an integrated manufacturing system. Keywords manufacturing education; CIM; manufacturing systems integration; databases; information management
A wide variety of manufacturing programmes have been implemented in schools of engineering, in schools of technology, in community colleges, in technical schools and in schools of business. The subject was and is still attracting interest and support not only from within higher education but also from industry and government [1]. Modern manufacturing systems concepts encompass three views: data or information flow, materials processing and communication technologies. Training and education can target all three of them, but if a single view had to be concentrated on as a vehicle for introducing the nature of manufacturing systems and their integration at a conceptual level, that would have to be the information flow view [2]. Much of the research work on manufacturing integration in recent years has led to a very high level of complexity, and has proved to be both inappropriate according to cost–benefit analyses and very inflexible regarding education and training matters. Results of interest include CASE tools for extension and implementation of CIM-OSA, an interface specification for open applications software and a model execution framework [3]. Complementary work to the above aimed at integration in process- or product-centred fashion [4]. Simultaneous engineering has been addressed through various kinds of ‘engineering moderators’ [5], primarily within the CAD–CAM link. CIM-OSA Integrating Infrastructure Services [6] have been influential. In addition, the US National Bureau of Standards has addressed fundaInternational Journal of Mechanical Engineering Education 31/2
114
George C. Vosniakos
mental issues related to distributed data management [7]. Earlier and more tangible work on linking free-standing specific production management, process planning and CAD systems in GEC-Traction has also been reported [8], and data states have been defined to facilitate coordination and integration [9]. There are undoubted competitive advantages to be gained from integration, but it is in the interest of both small and medium-size enterprises and the manufacturing systems engineering student that these advantages come with minimum complexity, which can be termed a ‘minimal’ approach to integration. Training and education with this approach in mind, in a top-down fashion, in the author’s view, naturally starts with information modelling of a manufacturing system and experimentation with information flow scenarios, and can be followed by studies of technology enabling material processing and communications. However, several other approaches can be found in the literature. Iwainsky and Kurth [10] give a short report of a project concerning the development and validation of concepts and prototype subsystems for the configuration, simulation, valuation and explanation of essential objects and processes of integrated manufacturing. That paper highlights a first prototype subsystem, for the configuration, visualisation and explanation of stock-keeping equipment, for the simulation of corresponding stock-keeping processes and for the valuation of the configurated equipment within a CIM environment. The CIM Institute [11] defined and built a teaching and research environment which focuses attention on the business process, including the increasingly important semi-externalised business processes. Projects and research were undertaken to examine the complexity of information management in supply chains. Networking with other universities and companies established an environment close to the leading edge of industrial need. Though the requirements of manufacturing education have changed significantly in recent years, the methodology of teaching manufacturing is claimed not to have changed much to cope with this trend [12]. The approach suggested is similar to the one practised in law or medicine, where case studies are the vehicle for discussion. The course described is based around a typical manufactured product whose design, production, marketing, and management functions are covered to demonstrate the concept behind manufacturing integration. Use of multimedia in teaching manufacturing systems has been explored [13] through two projects referring to new technical approaches in multimedia communication networks and training applications which aim to increase concurrent engineering and JIT training in one-off manufacturing and assembly. Recently, a system integration project [14] was carried out in which the development of a multimedia educational tool for designing simple mechanical parts resulted in new procedures for CIM. The procedures utilised the Internet for seamless integration of CAD, CAPP and CAM. The result is a www-based CIM environment which not only promotes design for manufacture (DFM) but also seeks to decrease manufacturing time in a rapid prototyping service based on milling. The approach employed in this work is outlined in principle in the next section and is analysed further in section ‘Reference data interfaces.’ Data models, their International Journal of Mechanical Engineering Education 31/2
Teaching manufacturing systems integration
Fig. 1
115
The main product of the Bicycle Makers Company.
implementation and their use follow and the main findings and conclusions are presented last. The proposed approach The approach outlined is intended for a team of between 6 and 12 students. It has been applied to final-year students in mechanical/manufacturing systems engineering courses. A substantial data modelling exercise is proposed. Each student or group of up to three students undertakes to model the data communication requirements of a specific function in the fictitious Bicycle Makers Company. The company manufactures just one classic type of bicycle (Fig. 1), with few variations, for example in the braking system (self-aligning or calliper brakes), transmission system (0, 3 or 11 gears) and seat (narrow and wide). The bicycle is well suited to this type of exercise, because it is familiar enough to most people, let alone engineering students, yet it is complicated enough to justify a real-world manufacturing system devised for its manufacture. The facilities available in the Bicycle Makers are not clearly specified at the earliest stage. The requirements should be discussed among the teams/groups and the project should be structured around them. As a starting point it is suggested that the company makes only the main metal parts of the bicycle (i.e. frame, gears, transmission) and buys and assembles the rest into a complete product. The main ‘functions’ of the manufacturing system whose data requirements are to be modelled are: design, production planning, process planning, material control (and resource procurement), shopfloor scheduling and control, and quality assurance. Each of these functions involves technical knowledge, managerial skills and International Journal of Mechanical Engineering Education 31/2
116
George C. Vosniakos
experience, and requires information, some of which is supplied by the other functions, in order to reach its respective output. All the data processing required within each function or for decision making (e.g. derivation of process plans, shop schedules, designs etc.) is irrelevant to the exercise and should be assumed or carried out in an approximate fashion. What is important to the exercise is the kind of data that forms the interface between functions, that is, what each function has to know from the other functions. The project has the following technical objectives:
• • • • •
Specifying a conceptual model for the exchange of information between the above functions. (Clarification of the workings of the company is a prerequisite.) Mapping this conceptual model onto a relational database schema. It should be possible to break this down into a number of sub-schemas, each corresponding to one of the functions stated above. Implementing the relational schema into a ParadoxTM intensional and extensional database. Identifying query scenarios between functions and quantifying data traffic. Demonstrating the mode of operation of a virtual distributed database by simulating communication of the functions in a token-passing network.
The pedagogical objectives of the exercise, which should be attained gradually through technical achievement as outlined above, are as follows:
• • • •
•
•
The distinct areas of decision making within a production facility should become clear, firstly based on functionality (e.g. design, process planning, etc.) and secondly based on ‘decision threads’. It is important to realise how the ‘decision thread’ approach to manufacturing leads to the integration concept, as every decision usually spans a number of ‘traditional’ departments. The variety and sheer volume of data involved in any decision in a manufacturing environment should be appreciated, even though, or perhaps because, a single product with very limited model variation is assumed in this case. The way networks and databases work together to form the spine of any CIM system should also be appreciated, because this is simulated manually, first by breaking down queries and directing them to all relevant parties (departments), and second by following a predefined protocol (token ring) for passing such messages around. The practicalities of putting a manufacturing business together should be appreciated, although this is considered a secondary aim, which is further emphasised by deliberately leaving a lot of freedom to the students, within a predefined framework, to determine the way in which their own system should work in terms of manufacturing and data manipulation procedures and even by allowing modification of the initial scenarios given by the instructor. The coordinated team-based approach to manufacturing is also emphasised throughout. The teams representing ‘departments’ or ‘functional areas’ should work together according to a project plan.
International Journal of Mechanical Engineering Education 31/2
Teaching manufacturing systems integration
117
GLOBAL QUERY COMPOSITION & DISTRIBUTION
REFERENCE INTEGRATION MANAGER
REFERENCE DISTRIBUTION SCHEMA
GLOBAL INTERFACE
LOCAL INTERFACE
LOCAL DATA SCHEMA
Application communication
Data process connection
REFERENCE INTERACTION SCHEMA
REFERENCE GLOBAL DATA SCHEMA
SCHEMA MAPPING
Inter-process connection
Fig. 2 Distributed database architecture.
Next, the theoretical background to the exercise is given in general terms (under ‘Reference data interfaces’) and specific technical terms (under ‘Relational data models’). Reference data interfaces The term ‘reference’ characterises the fact that commonly agreed data have to be defined for communication among the six main functions of a manufacturing system [15]. These data may have to be mapped to actual data used by the functions of a real-world manufacturing system. Such a system would have to be supported by a distributed database whose architecture would be designed in reference terms and be composed of a global data schema, a distribution schema and an interaction schema (see Fig. 2). It would also need software for managing interactions between the six manufacturing system areas (through queries and answers) and software for schema mapping in order to link the global schema with several local ones at the corresponding decentralised nodes where the data would physically reside (see Fig. 2). This link can also combine the reference to actual data mapping. In essence, the main object of this distributed database system that this work tackles is the reference global data schema, whereas the simulation of data interactions International Journal of Mechanical Engineering Education 31/2
118
George C. Vosniakos
naively replaces the reference interaction schema and the functionality of the reference integration manager operated through a global interface (see Fig. 2). Reference data schema A composite reference data schema comprises minimal data models of all sub-systems to be integrated, the spine being production planning, scheduling and control. The last is central to manufacturing system requirements and it also interfaces with business systems. The following sub-systems are considered in their computerised form:
• • • • • •
CAD (design), CAPPl (production planning), CAPP (process planning), CAMMC (material control). CASSC (shopfloor scheduling and control), CAQ (quality assurance),
Concurrent engineering is considered predominantly within CAD–CAPP and CAPPl–CAPP interactions. The manufacturing system structure applicable to discrete jobbing/batch manufacture via cellular structures is the main focus. Within each of the above sub-systems/applications, there are the data necessary to obtain the applications output. Some of the input data come from other applications and some of the output data go to other applications. These data constitute the data interactions between applications. The rest of the data used are generated and ‘consumed’ within the application and are irrelevant. The type and volume of interaction data depend on the nature of the application (automatic, interactive or manual) and of the (primary) functions/procedures that this entails. The level of abstraction of the data structures employed can vary from very high to very low. As an example, consider a process planning application where part design information is needed from the design application in order to recognise which areas need machining. This recognition can be either manual (i.e. performed by the human process planner) or automatic (i.e. performed by special recognition software). The interaction data in the former case are just one entity, albeit very comprehensive, i.e. the drawing. In the latter case the data may range from a complete topologic and geometric model, if the recognition engine needs to recognise ‘form features’, to a number of parameters, if the part model has been created as a ‘feature’ model. In summary, reference data describe all entities that can potentially be used in a data exchange among the six defined areas of the manufacturing system. Reference integration manager The coordination of data exchange, its completion and similar transactions is to be provided by the reference integration manager (complemented by query composition and distribution – see Fig. 2), replaced within the context of the project described above by a simulation ‘game’ (see ‘Use and experimentation’, below). International Journal of Mechanical Engineering Education 31/2
Teaching manufacturing systems integration
119
Integration management is seen in the context of this work at three levels explained next. First, multidisciplinary information is made available to any CIM sub-system, so that, for example, when a new product is being designed the designer has access to the tooling database, to process plans, to NC programs, to material orders, to stock status, etc. This level could be termed data concurrency, and should be largely complemented by the functionality of the data management mechanism. Second, the interactions are defined between data from different disciplines (viz. sub-systems) and the effect that changes on particular data may have on related data to it, through typical/standard and customised scenarios. These could be defined in terms of rules applicable in particular circumstances. For example, when updating the design of a product stock levels of a particular component may have to be checked, and, depending on the result, a different design solution may have to be adopted. Third, interactions are distributed. This is equivalent to initiating queries from application programs of CIM sub-systems, decomposing them and distributing them to the databases of the appropriate CIM sub-systems, then obtaining their responses, composing a single response and directing it back to the original sub-system. Translation from actual to reference terms should be carried out (as indicated above) wherever necessary. Concurrency issues Concurrency means that while an application is manipulating some data another application, either of the same or of a different type, is manipulating data related to it. The relationship can be of the ‘dependency’ type, where true concurrency cannot be implemented, or of the ‘complement’ type, where there is nothing to prevent parallel workings (see Fig. 3). Concurrency rules are taken into account in the simulation ‘mock-up’ of the integration manager. Some data are duplicated in different applications. The integration manager should ensure consistent updating of data. Also, the same data may have different status when used by different applications. In any case, data precedence (dependency) relationships are applicable. Function precedence is not taken into account directly, but only inasmuch as it is associated with data dependency. Authority of an application to modify or create data has to be assigned. Only one application can do this directly, although perhaps at the request of other applications. This can be implemented according to a locking mechanism. To illustrate, see Fig. 3, version nB of a piece of data B will result in an updated version mA+1 of data A in application Local-1. Version kC in Local-3 should be based on version mA+1, therefore A is locked until Local-1 provides the result. In case of multiple requests by different applications a priority system has to be in place. Then, if a data update cannot be effected, the application which originated it has to undo all changes that led to the update request through a roll-back mechanism. The initial concept of the user interface supporting the integration manager, cum query/answer composition, is shown in Fig. 4. International Journal of Mechanical Engineering Education 31/2
120
George C. Vosniakos
LOCAL-1 LOCAL-2
B A
A
GLOBAL
B
A LOCAL-3
C
B
A C
Fig. 3
Data concurrency approach.
Relational data models A general diagram of the activities involved in a manufacturing system is depicted in Fig. 5. The areas of interest to this work are boxed and numbered. The numbers are cross-referenced in Table 1, which summarises the main data exchange between these applications, irrespective of the existence of computerisation. In Table 1 note that some areas involve particular data in both input and output. For example, shopfloor scheduling and control needs part of the master production schedule (MPS) and updates it following the realities of scheduling. Also note that quality assurance interfaces everywhere through performance measures and quality reports. The flow of data between activities in Table 1 can be visualised and largely explained by referring to the respective arrows in Fig. 5. Figs 6–11 attempt to analyse the ‘interface’ data further. They correspond to the relational tables defined by the students, each table representing one relation. All relations comprising a function constitute essentially an ‘external’ relational model and corresponding schema (or view). In these tables, inputs (or read-only data) are designated with black background fields for attributes of the relations. Inputs are the main elements of interface among activity areas. Outputs (or write data) are designated with white background fields. Mixed input/output or read/write data are designated with grey background fields. Note that the elementary input or output data is a field and not a complete relation. In fact, a relation contains a mix of input data and output data. International Journal of Mechanical Engineering Education 31/2
Teaching manufacturing systems integration
121
TRANSACTIONS ID TYPE
query, answer, insertion, deletion, copying
SENDER RECEIVER TABLE QUEUE
ERROR HANDLING TYPE
OK, no pre-requisites, no mapping
TABLE FIELD REMOVE TRANSACTION
MODIFY TRANSACTION
CONCURRENCY CONTROL TRANSACTION ID STATUS
wait, ready, in progress
PARENT PARENT STATUS CHILD Fig. 4
Proposed global user interface.
Fig. 6 refers to design. Since inputs from external sources such as marketing and feasibility studies in Fig. 4 are outside the scope of the model, design specifications are not featured anywhere in Fig. 6. Note the ‘Function’ relation, which lists all important functional characteristics of each part and sub-assembly. Fig. 7 (production planning) contains the largest amount of information. Note the relatively many mixed input–output fields; for instance, ‘Utilisation’ contains the most recently updated information by the production planning activity through International Journal of Mechanical Engineering Education 31/2
122
George C. Vosniakos
TABLE 1
Main function interactions.
No.
Area
Input data
From
Output data
To
1
Design
Functional and technical specifications Improvement reports
External
BOM
2,4
6
Manufacturing instructions Performance measures
3 6
External 1 1 5 6
Production schedule/MPS Performance measures
2,5 6
2
Production planning
Order Product specifications BOM Refined MPS Improvement reports
3
Process planning
Component shape/accuracy Manufacturing instructions Improvement reports
1 1 6
Process/assembly plan NC program Setup drawing Operator instructions Performance measures
5 5 4 4 6
4
Material control
MPS Lead times BOM Improvement reports
2 2 1 6
EBQ/EOQ Delivery time Parts order Inventory status Performance measures
5 5 2 2,3 6
5
Shopfloor scheduling and control
Part drawing Process plan NC program MPS EBQ Operator instructions Improvement reports
1 3 2 2 2 2 4
Refined MPS Warning messages Scrap Performance measures
2 External 4 6
6
Quality assurance
Performance measures
Quality report Improvement report
External 1–5
1–5
information from shopfloor scheduling and control. The relation ‘Order-list’ contains a ‘Supplier’ field although suppliers are outside the scope of the model. However, supplier information is used by the material control area with which production planning interfaces. Note also that this area interfaces with all other five areas. Fig. 8 refers to process planning. Routings are produced based on equipment information (machines, tools). The logic for creating routings is internal to process planning, and so does not feature as interface data. This simplifies matters a lot, since this kind of information is complex and may constitute a large database in itself. Fig. 9 represents materials control activities including inventory management and order issue. Note that inventory concerns not only sub-assemblies and raw materials, but also machines and tools. Purchase orders are directed to production planning and not directly to purchasing or suppliers. Fig. 10 refers to shopfloor scheduling and control. It contains a number of fields originating from other areas but being updated here, for instance ‘cycle time’ of cells International Journal of Mechanical Engineering Education 31/2
Teaching manufacturing systems integration
123
Customer
Marketing
Sales and Service
Demand Forecasting
Feasibility Studies
3
1 Design and Bill of Maerials
Manufacturing Resource Planning
Master Production Scheduling
Supplier
Procurement
Material Requirements Planning
Process Planning
Incoming Control
Inventory Control
Shopfloor Scheduling
Engineering Release Control
Distribution
Packing
Manufacturing and Shopfloor Monitoring
Maintenance
Final Inspection and Testing
Assembly
2
4 5
6
Fig. 5
BOM
PARTLIST
DRAWING
FUNCTION
Computer-based manufacturing system functions.
Current_Assy
Level
BOM_ID
Parent_Assy Q
1
0
34
0
Part#
Func_characteristic
Material
100.001
Spoke-ISO 1923594 ST 100 Cr 6
Current_assy
Drawing_no
3
006.DDE.5
Drawing_no
Func_characteristic
Value
006.DDE.5
Frame_angle
30
uantity 1
Description Racing_bicycle_04
Fig. 6 Interface model for design.
and labour, ‘utilisation’ and ‘scrap rate’. This is expected because the activities involved in this area occur towards the bottom of the hierarchical ‘chain’ of activities in the manufacturing system (see Fig. 5). Fig. 11 refers to quality assurance activities. A relation represents specifications in a generic way, making use of referenced entities that may come from any area, setting targets and allowable deviations for them. Then, a quality measurement relation records actual values for these entities and another relation gives a report on quality status and recommendations for improvement. Note that quality assurance activity works with a kind of ‘meta-data’, i.e. the values of referenced attributes International Journal of Mechanical Engineering Education 31/2
124
George C. Vosniakos
CUSTOMER _ORDER
Order_ID 968
Description Handle_03_blue
Quantity 200
Due_date 12/5/95
MARKET
Part# 3
Forecast forecast1.dat
History history1.dat
PART
Part# 3
Description Handle_03_blue
PLANNED _CELL
Cell# 11
Description Handle_forming
Capacity 350
Utilisation 70
MANUFACTURE
Part# 11
Holding_cost 8
Setup_cost 6
Replenishment_cost Unit_cost
Subcontracting_cost Wage
8
70
4
FINANCE
Report# 76.239
Total_annual_cost Unit_cost 123.500 70
Holding_cost 8
Setup_cost 6
Date 28/12/95
MAKE
Make_ID 23
Quantity D 10
ue_date 10/10/95
Released_date 10/11/95
EBQ 125
MAKE_LIST
Part# 11
Make_ID 23
Cell# 11
ORDER
Order# 21
Quantity 100
Released_date 10/4/95
Due_date 20/4/95
EOQ 75
ORDER_LIST
Part# 3
Order_ID 21
Supplier# 170.332
PLANSHOP (MPS)
Plan# 111
Cell# 11
Actual_cycle_time Production_rate 2 80
Scrap 5 3
Priority Urgent
Fig. 7 Interface model for production planning. PROCESSING
TOOLING
ROUTING
Processing_data# Machine#
M/C type
Operation#
M/C condition
Tool#
4
3
Boxfordsaw
10.000.1
1500
6
Tool#
Tool_type
Tool_size
Tool quantity
5
sawblade
1000 mm - 60 tpi
0
Routing#
Part#
Operation#
Operation_type
Processing_data# Cycle_time
7
100.001
003
Handle-pin assy
2
NC data file
First Operation#
Last Operation#
100001a.nc
005
012
NC PROGRAM Part# 100.001
Fig. 8
2
Interface model for process planning.
in its tables appear as attribute names themselves in tables of the other five activities. The distinction between ‘read’ and ‘write’ data is important because it signifies the way in which the data may be distributed. One distribution model would be to keep all data created (i.e. written) by an activity within that activity’s scope or local database. All activities needing to read these data could do so remotely; for example, Tooling data are kept within material control activity (see Fig. 9), and are copied by process planning and by shopfloor scheduling and control activities for local use (see Figs 8 and 10). Data that are read and written by more than one activity such as ‘Cell utilisation’ by production planning (written once and then read) and by shopfloor scheduling and control (updated) activities (see Figs 7 and 10) need a time-stamping mechanism to control priority of writing. Apart from those cases all other data (written) are created within a single activity which has the exclusive right of creation. International Journal of Mechanical Engineering Education 31/2
Teaching manufacturing systems integration
125
MATERIAL
Material#
Description
Stock_on_hand
Stock_on_order
Status
INVENTORY
100.002
reflector-445.554
100
250
processing
PURCHASE
Order#
Item
Quantity
Lead_time
Supplier#
Date_received
Date_issued
ORDER
002
Pedal_assy_003
250
4
350.120
-
7/1/97
TOOLING
Tool#
Tool_type
Tool_size
Stock_on_hand
Stock_on_order
Status
5
sawblade-ISO 199A
1000 mm - 60 tpi
0
12
processing
Machine#
Feature
Value
5
max.rpm
6000
MACHINE
Fig. 9
Interface model for material control.
Machine#
M/C Type
Cell#
Capacity
Utilisation
Scrap_rate
2
Gear_hobbing
1
350
34
2
CELL
Cell#
Description
Utilisation
Mean_cycle_time
17
Frame_fabrication 1
LABOUR
Cell#
Description
Capacity
Utilisation
Mean_cycle_time
Hours / week
17
Fitter
168
87
115
42
Plan#
Routing#
Cell#
Order#
Quantity
Start_before
Finish_by
17344
6
17
100.12.44
120
12/1/96-07.00
12/1/96-21.00
MACHINE
PLAN
PLAN
Plan#
Status
STATUS
17342
45
TOOLING
Routing#
Tool#
5
54
100
Fig. 10 Interface model for shopfloor scheduling and control.
QUALITY
QS#
Reference_type
Referenced_entity Date_set
Target
Deviation
SPEC
1
Cell-utilisation
001
95
-5
QUALITY
QM#
MEASURíMNT 3
19/12/95
QS#
Date_measured
Actual_value
1
7/12/96
87
QUALITY
QR#
Date_issued
Recipient
File
REPORT
17
15/2/96
Shop_planning
17.TXT
Fig. 11
Interface model for quality assurance.
Implementation Relational schemata were designed first using standard symbols for entities, relations, attributes and relationship sets [16]. It was found that relationship sets can be made to correspond to interactions, that is queries that link data from different relations. This notion, however, cannot be exhaustively exploited as it would require a complete listing of all intended ways of interaction, that is all query scenarios rather than sample ones. Note that data normalisation was carried out up to the third normal form [16]. International Journal of Mechanical Engineering Education 31/2
126
George C. Vosniakos
(a)
(b)
(c)
(d)
(e)
Fig. 12 Sample query results.
The intentional database (relational data tables) was implemented by the students on the ParadoxTM database management system [17]. The extensional database (actual data) are filled in as sample data. Queries are associated with a ‘form’, which is a feature of ParadoxTM as well as of most other database management systems. Forms standardise and facilitate the way queries are formulated and the way results are obtained. A formal language supporting query forms is SQL. An example of a query expressed in SQL is given below. The answer sought is the utilisation of all machines that gave scrap rate higher than 7% on 20 August 1999. The purpose of such a query might be to verify an explanation relating high scrap rates to high utilisation. SELECT machine, utilisation, Scrap_rate FROM Processing(P), Quality_measurement (M), Quality_spec (S), Machine(E) WHERE M.qs#=Q.qs# AND S.Reference_type LIKE %scrap_rate% AND S.Referenced_entity=P.machine AND E.machine#=P.machine International Journal of Mechanical Engineering Education 31/2
Teaching manufacturing systems integration
127
AND M.Date_measured LIKE %20.08.1999% GROUP BY Scrap_rate HAVING M.Actual_value >7.00
Instead of using SQL statements, a form may be defined expressing these very statements graphically. The answer to such a query may be given in a relational table format or as a form, too. In the query above, note that the table ‘Machine’ resides in the shopfloor scheduling and control area, the table ‘Processing’ resides in the process planning areas, whereas the tables ‘Quality_Measurement’ and ‘Quality_Spec’ reside in the quality assurance area. These three areas need to collaborate in order to formulate the answer to the query. Also, note that the Scrap_rate field used in the Machine table refers to the average value over a long period, whereas the Scrap_rate values sought by the query refer to a daily horizon. As regards the computing resources that are necessary for implementation purposes, any Pentium-generation personal computer would be suitable, provided that a matching version of the Paradox software is installed, too. Indeed, the first implementation of the project was carried out on Pentium 133 machines with 32 MB of RAM with absolutely no complaints on speed of execution. Use and experimentation After building the relational tables in ParadoxTM, an experiment was conducted to simulate the way queries are formulated. Each relational model corresponding to one of the six manufacturing system areas resides on one personal computer running ParadoxTM. All six computers are part of a network. If a query by one of the areas needs to be answered, it has first to be formulated. In order to formulate a query, the relational models (termed ‘external’) of all six areas have to be known, in order to check first whether there is enough information to answer that query and then to use the correct relation and attribute names. Standard queries are the answer to this synthetic task. Once a query has been formulated it has to be passed to all interested parties, that is to all areas of the manufacturing system from which an answer is required to compose the complete answer. In other words, the way in which the query will be processed has to be known in order to prioritise the individual answers (viz. Boolean or, more generally, query operations) and so pass the query sequentially in the correct order to the areas involved. In our simulated query distribution situation, the computer network is used to pass the query from node to node. Note that a LAN or even Internet with e-mail facilities can be used. The ‘message’ (text file) passed specifies the sequence of recipients and the corresponding query operations to be executed by each recipient. Each time the query is delivered to the right recipient, it has to be executed on the local PC in ParadoxTM and the answer (a table) has to be attached to the ‘message’ along with the rest of the recipients and query operations required. The last recipient will ‘find out’ the ultimate answer and will send it through the network again as a ‘message’ to the querying node. International Journal of Mechanical Engineering Education 31/2
128
George C. Vosniakos
Fig. 12a–c shows examples of answers to simple queries in straight-forward presentation. Fig. 12d,e shows examples of answers to relatively simple queries making use of forms. Some more elaborate examples of queries are as follows:
• • • • • •
Design may need the parts of a certain assembly that are made of cast iron. Production planning may need the total planned production items to be delivered in a particular period in time. Process planning may need a classification of operation types according to the total cycle time allocated to them. Material control may need stock quantities and order status for a particular item, e.g. blue handlebars. Shopfloor scheduling and control may need to know a particular machine’s performance in terms of scrap and utilisation. Quality assurance may need to know all tool types that exhibit a frequency of breakage higher than a particular threshold.
The approach was tried with several classes of mechanical/manufacturing engineering final-year students initially at UMIST (UK) and then at NTUA (Greece) as a major project in CIM and manufacturing systems courses, respectively. Note that the exercise was given to students in the second half of the semester, following approximately 24 hours of lectures on CIM principles and issues. The pedagogical aims were largely achieved. The main hypothesis of the author – that CIM is best thought of as integration of data – proved correct, given that interactions of data islands ‘owned’ by individual ‘departments’ or ‘cells’ or even just ‘teams’ governed to a large extent the way that the manufacturing enterprise was run. Unless data details were appreciated, students would have never comprehended the CIM concept. It became clear, too, that the performance of one ‘department’ or ‘team’ depends on:
• •
the actual performance of its ‘neighbours’; how well each department or ‘team’ know the way that its neighbours work and how well it has adapted its internal workings to optimise the system rather than its own output alone;
Students also had the opportunity to demonstrate their team-oriented abilities; for example, some would act well as leaders and others would prefer to be given tasks to execute. It was observed that a large amount of time, perhaps up to one-third of the total duration of the project, was devoted to teams establishing a common model of thinking and also a common data model, and both parts proved significant. An interesting point invariably observed was that the team that was devoted to quality assurance was considered by the other teams as some kind of ‘outsider’ to the actual problems or decisions faced by them, perhaps playing the role of the ‘inspector’, which is never popular. The calls of those teams for better quality were hardly taken into account by the others, and this was disappointing for the quality assurance teams and left them feeling excluded. International Journal of Mechanical Engineering Education 31/2
Teaching manufacturing systems integration
129
The parts of the exercise that proved the least successful were those associated with network simulation. Although an appreciation of network functions was certainly given, it was felt by the students that ‘manual’ simulation can easily become tiresome and also that more sophisticated means (e.g. use of networked PCs with proprietary software to instigate messages, to allow their breakdown by the user, to direct them in a token ring fashion and to synthesise a single answer under total control of the users) would add more useful detail to the exercise. The general impression of both students and assessors was very positive; suggested improvements related to the provision of richer data on the manufacturing processes of the Bicycle Makers Company. The issue of data sources within a predominantly data modelling exercise is certainly an important one. There were essentially two choices: one was to supply all necessary data to the students in a form ready to be used and the other was to supply to the students a loose description of just the type of data and give a closer description of the functions which use these data (design, production control, etc.). The first choice was thought to be too restrictive and incapable of allowing the students fully to appreciate the multitude of approaches used in making a product. The second choice was favoured in order to force the students to instantiate the loose data model and make decisions for themselves as to the necessary procedures for putting together a manufacturing system. In that way the exercise encompasses not only integration issues, but more fundamental ones, too, which are often reverted to when integration is sought. The drawback of this choice is that the instructor has to provide answers to a variety of manufacturing system configurations that the students may think of, and the details have to be realistic. This is not always possible, if the data are not taken or adapted from a real business. Therefore, either such a business has to be backing the project, the instructor(s) being the mediator(s), or the students have to be left to make their own contact with such businesses and set up their own data for whatever product seems more suitable after consultation with the instructor. The latter solution was never tried in our case because the inherent lack of control by teaching staff was deemed prohibitive and also the repeated visits to companies that would have been involved were considered too time consuming for the purposes of this project. It took the student teams about 7 hours a week for 6 weeks to set up the data and model them in ParadoxTM. Two timetabled hours were spent each week initially in the classroom and later in the computer room. The rest of the time was spent outside official schedules. Note that no student had worked on ParadoxTM before, so familiarisation with the database management system was accounted for inside the total time calculated. Some students had worked with MS Access but at a very elementary level. It, then, took students another 10 hours to experiment with the data and devise scenarios of communication with the other teams. Some students were so keen on computerisation of the data models and scenarios that they spent two to three times as long in the computer lab experimenting. Most of them, however, invested time on improving the user interface for queries and so on, and not on the data models as such. All in all, the exercise required an International Journal of Mechanical Engineering Education 31/2
130
George C. Vosniakos
average 50 hours of work per student; therefore it had to account for 50% of the subject marks as far as assessment was concerned. Concluding remarks Manufacturing system integration depends primarily on information circulation. Education and training in this discipline have to give a feeling of what kind of information is needed as a minimum for successful integration, what kind of queries are possible and how this communication can be structured in a distributed environment. The approach proposed in this work is data modelling in relational databases and simulation of the flow of information manually on a personal computer network. Models, queries and simulations constructed by mechanical/manufacturing engineering student classes demonstrated the substantial size of the task through both volume of data and complexity of the exchange scenarios. The pedagogical aims were largely achieved. The main hypothesis of the author, that CIM is best thought of as integration of data, proved correct. One-third of the total duration of the one-semester project was devoted to teams establishing a common model of thinking and also a common data model. Team inter-dependency was a prerequisite and teamwork was easily promoted as a recipe for success. The only part that was considered relatively poor was network simulation, which ran the risk of becoming boring and should, therefore, become more sophisticated, perhaps by enhancing its computer basis. The next step would be to elaborate more information exchange scenarios. In fact, the project is open ended in that respect. Scenarios can be defined to cover a variety of circumstances in the manufacturing business, such as short-term change scenarios (e.g. sudden loss or acquisition of orders, change of capacity) as well as longerterm change scenarios (e.g. new product introduction, flexibility introduction, manufacturing process re-engineering due to new technology). These scenarios should be associated with a requirement for estimation of the data communication time and data traffic, which are realistic feasibility criteria in real implementations of distributed databases supporting CIM. References [1] V. J. Vitagliano, ‘CIM in higher education: overview, industry perspective’, Robotics and ComputerIntegrated Manufacturing, 9(1) (1992), 3–4. [2] J. L. Burbidge, P. Falster, J. O. Riis and O. M. Svendsen, ‘Integration in manufacturing’, Computers in Industry, 9 (1987), 297–305. [3] M. W. C. Aguiar and R. H. Weston, ‘A model-driven approach to enterprise integration’, International Journal of Computer Integrated Manfacturing, 8(3) (1995), 210–224. [4] J. A. Harding and K. Popplewell, ‘Driving concurrency in a distributed concurrent engineering project team: a specification for an engineering moderator’, International Journal of Production Research, 34(3) (1996), 841–886. [5] A. H. S. Al-Ashaab and R. I. M. Young, ‘Modelling manufacturing process information using EXPRESS’, Concurrent Engineering: Research and Applications, 5(1) (1997), 27–34. International Journal of Mechanical Engineering Education 31/2
Teaching manufacturing systems integration
131
[6] M. Klittich, ‘CIM-OSA Part 3: Integrating infrastructure, the operational basis for integrated manufacturing systems’, International Journal of Computer Integrated Manufacturing, 3(4) (1990), 168–180. [7] A. Jones, E. Barkmeyer and W. Davis, ‘Issues in the design and implementation of a system architecture for computer integrated manufacturing’, International Journal of Computer Integrated Manufacturing, 2(2) (1989), 65–76. [8] J. S. Busby, D. G. Hay and D. Hutchinson, ‘Linking computer systems in a manufacturing company’, International Journal of Computer Integrated Manufacturing, 3(2) (1990), 73–83. [9] G. Harhalakis, C. P. Lin, L. Mark and P. R. Muro-Medrano, ‘Information systems for integrated manufacturing (INSIM): a design methodology’, International Journal of Computer Integrated Manufacturing, 4(6) (1991), 351–363. [10] A. Iwainsky and R. Kurth, ‘Stock-keeping processes in the framework of computer-aided engineering education in CIM’ , International Journal of Engineering Education, 10(6) (1994), 523–529. [11] P. Sackett and D. McCluney, ‘Inter enterprise CIM – a mechanism for graduate education’, Robotics & Computer-Integrated Manufacturing, 9(1) (1992), 9–13. [12] S. K. Vajpayee and A. Jain, ‘Teaching manufacturing as law/medicine’, International Journal of Applied Engineering Education, 7(4) (1991), 258–263. [13] H. Hebenbrock and H. Panse, ‘Multimedia communication and training applications in computerintegrated manufacturing’, International Journal of Continuing Engineering Education, 2(2/3/4) (1992), 126–134. [14] W. H. Chui and P. K. Wright, ‘A WWW computer integrated manufacturing environment for rapid prototyping and education’, International Journal of Computer Integrated Manufacturing, 12(1) (1999), 54–60. [15] G. C. Vosniakos and M. Williams, ‘On reference modelling of manufacturing systems using CoadYourdon’s OOA method’, IFIP Transactions B: Computer Applications in Technology, B-15 (1996), 47–59. [16] C. J. Date, An Introduction to Database Systems, 7th edition (Addison-Wesley, Boston, MA, 1999). [17] Borland International, Paradox Manuals, version 5.0 (1997).
International Journal of Mechanical Engineering Education 31/2
