An application of CIMOSA concepts in the development of change ...

12 downloads 68437 Views 683KB Size Report
iii a number of large end user companies have adopted its use, and. Ž . iv the authors had previous experience of its application and had previous involvement ...
Computers in Industry 40 Ž1999. 243–257 www.elsevier.nlrlocatercompind

An application of CIMOSA concepts in the development of change capable manufacturing cells R.P. Monfared ) , R.H. Weston

1

MSI Research Institute, Loughborough UniÕersity, Loughborough, Leicestershire, LE11 3TU, UK

Abstract A new approach to the design and reconfiguration of change capable manufacturing cells is described. The approach is based on Ži. the development of particular models of cells, where the use of CIMOSA modelling constructs is structured and informed by a semi-generic model of similar manufacturing cells and Žii. the use of new constructs and tools that operationalise particular models in the form of an explicit, model-based configuration of cell resources and software components. The paper describes key elements of the semi-generic model and a case study application of the approach when designing and prototyping a case study manufacturing cell. q 1999 Elsevier Science B.V. All rights reserved. Keywords: Reconfiguration; Enterprise modelling; Component-based systems; Manufacturing cells; CIMOSA

1. Need for a new approach to the design and reconfiguration of manufacturing cells Human and technical resources are often grouped together within manufacturing cells that have defined capabilities, i.e., to carry out certain types of operation on a product family w9,11x. Based on this knowledge, cells can be assigned roles, responsibilities and tasks that match the capabilities they possess. Unfortunately, however, contemporary practice used to define and realise structural relationships in a manufacturing cell is largely ad hoc in nature. Consequently, current generation manufacturing cells

) 1

Corresponding author. E-mail: [email protected] E-mail: [email protected]

cannot readily accommodate change unless the nature of this change can be predicted and catered for in advance. This can limit the operational performance andror lifetime of cells and curtail the breadth of their application. Whereas this paper will consider the specification, development and proof-of-concept testing of a model-driven, component-based approach to the design and construction of shop floor manufacturing cells. The approach has its foundation in CIMOSA concepts w6x that have been extended and operationalised w4x to structure the design and reconfiguration of cells, even in the event of largescale, unanticipated change. The approach makes explicit and communicable the configuration of structural relationship between cell entities, so that these relationships can be reconfigured and extended readily. This provides means of improving the per-

0166-3615r99r$ - see front matter q 1999 Elsevier Science B.V. All rights reserved. PII: S 0 1 6 6 - 3 6 1 5 Ž 9 9 . 0 0 0 2 8 - 7

244

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

formance of a cell on an ongoing basis and can extend its useful life.

2. A new approach to the life-cycle engineering of manufacturing cells From previous experience of developing and using various bottom-up cell design and build approaches with industrial partners, general requirements of a model-driven component-based approach to engineering manufacturing cells were specified and are listed in Table 1 w7x. The approach conceived to meet these general requirements is illustrated by Fig. 1 and incorporates the following paragraphs below. ŽI. An enterprise engineering framework to organise in a holistic way Ža. roles, responsibilities and activities of supervisory, control and resource elements within and external to a cell and Žb. the development and use of computer models and modelling tools during the design, construction, operation, development and change of a cell. ŽII. Process-oriented modelling to capture and reuse requirements descriptions describing jobs,

tasks, operations and activities to be carried out by a cell. ŽIII. A modelling environment that underpins ŽI. and supports ŽII. to structure and facilitate the capture, development and operationalisation of semigeneric requirements specifications, requirements specifications Žspecific to a cell., conceptual designs, detailed designs and implementation descriptions for manufacturing cells. ŽIV. A semi-generic model of manufacturing cells describing common activities and activity relationships in cells, software components Žthat can be selected and configured to produce a suitable ‘control system’ for a particular cell., support tools and resource elements Žthat are assigned to a particular cell. and their interrelationships in a given application domain. The main purpose of this semi-generic model is to provide a modelling structure that establishes a base level of design expertise during the design of component-based cells. This model is required to lend structure to design and construction activities needed to produce a specific Žor particular. manufacturing cell. Here, a particular cell must be a ‘constituent member’ of the broader application domain covered by the semi-generic model of cells.

Table 1 General requirements General requirements of an approach to the design and construction of change capable manufacturing Ø Achieve fast, effective, efficient and holistic a design, prototyping, implementation and integration of manufacturing cells. Ø Achieve fast, effective, efficient and holistic redesign, reconfiguration, development and extension of cells in response to different types, sources and magnitudes of change in the environment in which cells are used. Ø Structure, detail and support cell design, build and development activities carried out by members of project teams concerned with the ongoing engineering of cells. Ø Produce broadly applicable, changeable and communicable descriptions of the requirements of cells, in terms of jobs, tasks, operations and activities and the functional capabilities needed to achieve those requirements. Ø Enable requirements and solution visualisation, synthesis and performance analysis. Ø Flexibly systemise the way in which sets of cell resources are organised and attributed, so that their interoperation remains aligned to defined requirements. Ø Define the functional capabilities of sets of reusable system building blocks capable of organising, co-ordinating, controlling and monitoring the interoperation of resource sets. Ø Develop descriptions of and support mechanisms for sets of resource elements and sets of reusable software components that facilitate their configuration and interoperation in cell systems. Ø Retain design semantic and cell control system architecture of specific cells in the form of computer executable models that enable system redesign, reconfiguration, analysis and development. Ø Establish means of continuing to deploy human and technical resource sets in current use in different application domains in which cells are used. a

This study has involved three types of holism, namely a need to consider Ž1. global and local issues, Ž2. business, socialrhuman and technical factors, and Ž3. multiple views Žor foci of concern. of enterprise personnel Žincluding managers, supervisors, operators, vendors, consultants and technical personnel..

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

245

Fig. 1. Conceptualisation of the model-driven, component-based approach.

ŽV. A model-driven, component-based Žsoftware. architecture for manufacturing cells Žlinked to ŽIII.. that structures the design, implementation and runtime interoperation of a pre-defined set of software components that are commonly used to organise, co-ordinate, control, and monitor the operation of the resource elements of a particular cell. ŽVI. A set of modelling and model enactment tools that support the selection, implementation, interoperation, and ongoing change of software components used to organise, co-ordinate, control and monitor the operation of a cell. As part of this research it was necessary to: Ž1. design and construct a proof-of-concept Modelling EnÕironment capable of conceptualising, visualising, analysing and communicating descriptions Žmodels. of cell requirements Žin terms of jobs, tasks, operations and activities and functional requirements., and

Ž2. flexibly systemise the way that descriptions Žmodels. of control system components and cell resources are organised and attributed, so that their interoperation remains aligned to defined requirements. Here, it was necessary to design and construct a proof-of-concept set of software tools referred to here as Cell Design Tools ŽCDTools. that function to operationalise the conceptual models of manufacturing cells developed within the modelling environment. The collective purpose of the modelling environment and CDTools is to enable rapid prototyping and reconfiguration of cell resources and associated of cell control system Žsoftware. components by retaining and reusing knowledge of mappings between: modelling constructs used during conceptual design Ži.e., in the modelling environment.; a different set of modelling constructs used during detailed design

246

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

Žwithin CDTools.; and primitive software constructs Ži.e., primitive IT components. used to generate software elements of the runtime cell control system. In general, it was assumed that a particular cell will require a control system comprising cell control applications and infrastructure services Ži.e., interaction services, information support services and physical device interfaces.. In general, cell control applications must be organised so that collectively they control and monitor the interoperation of a set of resources assigned to a cell. Generally, these resources were expected to include electro-mechanical machines, human resources, and a set of supportive application tools Žreferred to here as Cell Application Tools, or CATools.. The proof-of-concept CDTool developed in this study semi-automatically generates and configures CATools from primitive software components Žas well as cell control applications and infrastructure services., with the purpose of increasing the reconfigurability Ži.e., change capability. of resultant cells. Hence, the approach to engineering cells is targeted Žas far as proved practical. on reconfiguring cells from reusable software components and human and machine resource elements. A key decision made was to base the implementation of the conceptual modelling environment on the CIMOSA specification because: Ži. it has a proven track record with respect to the conceptual design of enterprise systems Žincluding manufacturing cells.; Žii. it has excellent public domain documentation; Žiii. a number of large end user companies have adopted its use, and Živ. the authors had previous experience of its application and had previous involvement in the development of the SEWOSA CASE tool w1,2x. However, previous research of the authors w2,8x had illustrated the need for new concepts and modelling tools to operationalise CIMOSA models, particularly with respect to the generation of component-based systems Ži.e., systems that are configured largely from reusable software components and human and machine resource elements.. Following investigatory use of SEWOSA Žand hence, CIMOSA. at the requirements definition, design specification, and implementation description modelling levels to produce particular models of cells, it became evident that although the CIMOSA

specification provided a suitable general purpose modelling framework and methodology for enterprise modelling, its use by cell system designers and builders needed to be targeted and further facilitated by defining and imposing the use of structural and methodological guides that ensure the end result will be a component-based cell with appropriate change capabilities. Therefore, it was necessary to define and capture one or more semi-generic models of manufacturing cells to provide an exemplar modelling structure. There was a need to be able to reuse such a model to guide the design and construction of many different instances of cells, each designed to meet a particular set of manufacturing requirements and utilise a particular set of control system components and resources. 3. A semi-generic model of pcb manufacturing cells A semi-generic modelling structure for manufacturing cells was developed based on an analysis of common requirements and solutions found within a number of printed circuit board Žpcb. manufacturing cells deployed by a collaborating company. In this case, the particular cells modelled are in-production cells used for electronic component kitting, pcb drilling, pcb assembly, pcb test and computer product assembly. First, a set of generic tasks Ži.e., structured sets of enterprise activities. in use within the in-production cells were identified. This first part of the semigeneric model corresponds to the requirements definition level of CIMOSA modelling structure and models the generic tasks in the form of Business Entities ŽBE. w3x, including generic models of Domain Processes, Business Processes Enterprise Activities and Reference Procedural Rules Žfor details the reader is referred to Ref. w8x. This part of the semigeneric model conceptualises the requirements for the design of the manufacturing cells regarding the function, information, resource and organisation aspects, although prime focus was on developing function and information views w10x of the modelling structure. The first part of the semi-generic modelling structure was captured and developed using the SEWOSA general purpose enterprise modelling tool w1x.

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

A second part of the semi-generic modelling structure was specified and developed that conforms to the design specification level of CIMOSA modelling. However, to realise that the study aims modelling at this level also needed new modelling concepts targeted towards the detailed design of component-based solutions. During conceptual and detailed design modelling of a particular cell, control

247

system entities must be selected and configured to organise, co-ordinate, control, and monitor the interoperation of resources in a cell so that they achieve specific cell requirements. It was decided that specific cell requirements should be defined by fleshing out particular instances of generic tasks Ždefined by the first part of the semi-generic modelling structure.. Indeed, when developing the second part of the

Fig. 2. Generation of the particular models using the semi-generic model.

248

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

semi-generic modelling structure, it was found that four types of modelling construct were needed to guide the modelling and assignment of elemental building blocks of functionality Žto be deployed in a particular cell at runtime. to each atomic activity element Ži.e., enterprise activity.. These modelling constructs required included reference descriptions of: Ž1. Function Entity constructs, used to represent the functional capabilities of physical resources in a cell; Ž2. computer application tools required to support various tasks deemed to be within the design scope of a particular cell; Ž3. information modelling constructs that are specified during the development of a detailed design information model Žin this approach the information model w5x is generated in EXPRESS format based on the information description defined at the previous stage of modelling.; and Ž4. cell control applications needed to organise, synchronise, control, and monitor the operation of the generic tasks by the resource elements used in the cell. Fig. 2 illustrates how the modelling of a particular cell is structured and informed by elements of the semi-generic model.

4. A case study application Having developed a semi-generic structure for the modelling approach with reference to different types of pcb manufacturing cell, commercial circumstances made it difficult to gain sufficient access to company data to conduct a full case study based on current and possible future practices at a manufacturing site of the original collaborating partner. Also, the actual configurations of cell resources currently deployed within cells by the collaborating company was found not to be ideal in terms of fully testing the approach. Therefore, a decision was taken to evaluate the use of the project concepts and tools in an alternative and more accessible manufacturing domain. This led to a case study based on manufacturing cells used to produce high-pressure hydraulic components in small- and medium-sized batches. The first author had previously been responsible for the design and development of cells within that company and had sufficient access to company information required. Choice of this experimental study was therefore seen

to have two advantages in comparison with corresponding pcb manufacturing studies. Firstly, the case study could more thoroughly test the capabilities embedded into the modelling system under close to real plant conditions, as sufficient data was readily available to enable comprehensive tests to be performed. Secondly, use of a semi-generic model of pcb cells could be tested in a distinctly different type of manufacturing domain, thereby at least in part testing the ‘generality’ of the modelling and model enactment approach. 4.1. Description of the case study cell The case study company is a manufacturer of high-pressure vessels, pipes, couplings and various types of hydraulic equipment. The company has approximately 800 employees. Each year it produces circa 60 large high-pressure vessels, 500 km of gas pipes in different sizes, and a large number of different types of hydraulic equipment Žincluding 2000 hydraulic cylinders.. The company sells 60% of its products to the oil industry in its home country but 20% of its products are exported to Europe Žespecially its hydraulic components.. The company has several production lines that deploy metal forming, machining and forging processes and associate materials handling processes. Within the manufacturing section, a cellular manufacturing system has been implemented to cope with a broad range of product types and production order quantities Žmainly in small quantities.. The cells have been organised in a process-oriented way. The manufacturing section deploys several cells, mainly cutting, machining, heat-treatment, and finishing cells. The actual case study chosen is based on manufacturing cells used during the manufacture of high-pressure hydraulic cylinders. Although individual processes used by the company within their manufacturing section are not particularly complex, the variety of product specifications Žsize, tolerances, surface quality requirements, etc.., and the uncertain rates at which orders impact on production makes this section one of the most problematic manufacturing lines used by the company. These problems are a source of many production delays and conflicts. A sample product and typical process flow along the ‘Hydraulic Cylinder’ production line are illus-

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

trated by Fig. 3. Raw material is delivered to the ‘cutting cell’ Žtypically in the form of steel bars and thick cylinders. where the material is cut and roughly sized. The cutting cell includes three conventional and two precision cutting machines. The cell receives material inputs from the material store and receives daily orders Ži.e., information inputs. from the shop floor manager. The sized materials are passed onto the ‘heat treatment cell’ that carries out ‘stress relieve’ processes. Subsequently, the material is retained in an intermediate buffer which is located between heat treatment and machining cells. The ‘cylindrical machining’ cell Žreferred to in the following text for simplicity as the ‘machining cell’. carries out the main machining processes required during the production of hydraulic cylinders. Therefore, the case study centred on a study of this machining cell. The cell includes: four copy-lathe machines capable of machining parts up to 30 to 350 mm in diameter, and 100 to 2200 mm in length; three CNC lathe machines capable of machining parts up to 260 and 1850 mm in diameter and length which has a

249

tool magazine with 32 tools including a side drilling head; two vertical boring machines capable of internally boring cylinders with a maximum diameter of 320 mm and length of 2000 mm. Material is manually loaded into one of four copy-lathe machines within the cell so that they perform ‘rough and finish turning’ processes on external surfaces of cylinders Žsee Fig. 3.. Subsequently, parts are loaded into the CNC lathe machines that perform ‘face turning’, ‘threading’, and ‘chamfering’ processes on both ends of the cylinder. Part unloading, part loading into boring machines and ‘boring’ processes are then carried out to complete the sequence of machining operations. Having completed machining processes, parts are transferred to the ‘surface finishing cell’. This finishing cell carries out a ‘surface hardening Žcoating.’ process, that improves the surface quality and protects against abrasion and erosion. Surface hardening is followed by a ‘honing’ process that is carried out on the internal surface of the cylinders and is performed by two horizontal hydraulic-stroke honing machines. Alternatively, for parts that are less than

Fig. 3. Sample product and machining cell Žhydraulic cylinder cell. within the production line.

250

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

300 mm in length, a typical ‘grinding’ process is carried out. Finally, a sample of parts is transported to the ‘quality control cell’ for checking. In the case study company, a selection of resource elements used in its manufacturing cells are connected to a computer network system Ža Local Area Network with connections established by Windows NT platforms.. The network and associated network management system enable and control access to a central database system that maintains and manipulates orders and production data, thereby providing authorised access to manufacturing information. A networked scheduler Ži.e., a software tool. supports the manual definition of input and output files in specific formats. 4.2. Use of the modelling enÕironment and CDTools The following description ‘walks through’ the basic procedure used to design and prototype 2 the ‘Hydraulic Cylinder Machining’ cell. This illustrates use of the modelling environment and prototype CDTool. Figs. 4 and 5 are extracts from graphical models produced to represent the case study cell at the requirement definition level of modelling, Fig. 5 being only one part of the behaviour model. The models were captured and represented using the SEWOSA CASE tool. A further decomposition of BPs in the cell into EAs was also carried out but has not been shown in full because of space constraints. The complete set of EAs is described in Ref. w7x. The following steps were followed to design and configure the case study cell. Ž1. At the requirement definition level of modelling, the approach conforms to the CIMOSA specification. A set of BEs were defined with reference to tasks carried out in the case study cell. This particu-

2 Here, the term ‘prototype’ is used to convey the fact that implementation of a case study cell was realised under laboratory conditions, where the control software and support tools were implemented in a form that could be used in the production cell but the operation of the machine elements of the cell was emulated by specially designed software processes. This simplified the implementation work. It also allowed attention to be focused on demonstrating and testing the extent to which the overall approach to cell control can accommodate different types of change.

lar selection of BEs was made with reference to the ‘generic entities’ defined by the semi-generic model. The BEs defined in this way are illustrated by Fig. 4. The SEWOSA tool also generated a textual form of this model, Ži.e., ‘model templates’.. The text was used to transfer the model definition to the next level of modelling. Ž2. Procedural rules also need to be particularised based on an understanding of BE relationships within the actual machining cell. Therefore, procedural rules were defined and assigned to enterprise activities. However, procedural rules allocated in this way need to be further particularised to suit individual requirements of cell groups and this was also achieved with support from the ‘CDTool’. Ž3. In addition to defining functional entities, information entities need to be defined, populated with real plant data, and organised as part of the design of an overall data storage system. Therefore, generic information elements ŽIE., information object Õiews ŽOV., and enterprise objects ŽEO. previously defined as part of the semi-generic modelling structure were partially populated with data related to the actual machining cell. Initially, only information entities related to selected BEs were attributed, where reference was made to the generic information entity types also previously defined as part of the semi-generic modelling structure. Initial information entities defined in this way were enterprise objects EO-01, EO-02 and EO-03. Subsequently, these OEs are assigned object views OV-11 to OV-36 along with related IEs. OVs are information objects that should be attached to atomic functional objects Ži.e., enterprise actiÕities .. Ž4. At the design specification level, particular model development was targeted towards the design of a component-based system. Initially, at this level of modelling, suitable cell resources were selected from the library of available resource types and populated with real data. Table 2 classifies the resources selected and assigned with respect to the case study machining cell. Ž5. Also during design specification generic function entities were populated with reference to capability requirements of BEs of the cell. Table 3 shows the function entities defined in this case. Ž6. The project methodology supports a decomposition of cells into ‘groups’. This simplifies the

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

251

Fig. 4. Requirements definition level of semi-generic model developed for particular hydraulic cylinder machining cell.

organisation of the cell and facilitates control of the resources in the cell via an appropriate CATool Žrealised as a defined configuration of elemental software components.. A CATool was generated for each cell group. Entities modelled and particularised were allocated to defined groups in the manner illustrated by Fig. 6.

The case study ‘machining cell’ was divided into three groups, namely a ‘supervisor group’ and two ‘operator groups’. Choice here was based on an appraisal of the physical cell layout and an understanding of the similarity of the production processes that each group had responsibility for.. Each group was allocated: Ža. responsibility for a set of BEs, i.e.,

Fig. 5. Behaviour diagram of the processes carried out by the CNC machines within the cell Ždeveloped using the SEWOSA CASE Tool..

252

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

Table 2 Resource classification for the ‘hydraulic cylinder machining’ cell Cell resources

Resource name

Resource ID

Human resource

One supervisor Three lathe-copy operators Two lathe-CNC operators Two boring operators One assistant operator Four copy-turning machines Two CNC turning machines Two horizontal boring machines LAN ClientrServer Network PC-basedrScheduler Software Windows Database Management System

HS1 HCO1 and HCO2 and HCO3 HNO1 and HNO2 HBO1 and HBO2 HAO1 MCT1 to MCT4 MNT1 and MNT2 MB1 and MB2 Networking system Scheduler DBMS

Machine resource

Computer tools

actual tasks that should be carried out by each group in the cell; Žb. a set of cell resources capable of performing the tasks; and Žc. a suitable CATool with a capability to control and monitor system elements within the groups. The BEs selected during step 1 were allocated to each group in the machining cell. In addition, the function entities were particularised Žsee Table 3. and allocated to groups. The tasks involved in machining the ‘hydraulic cylinders’ are specified by enterprise actiÕity definitions listed in this table. In addition, descriptions of the BEs and their requirements were used to select corresponding ‘software components’ previously specified at the

‘detailed design level’. Model definitions in respect to each group in the case study cell are illustrated by Table 4. Ž7. Having formally defined the functional elements of the cell system, its information aspects also need to be modelled. Information objects were specified during step 3, when model construction was carried out at the requirement definition level of modelling. Whereas at the design specification level, a particular information model Žwith a structure developed with reference to the semi-generic modelling structure. was generated and populated with plant data. Fig. 7 shows part of the EXPRESS information

Table 3 Populating the generic function entities with the test case data Generic function entities

Particular function entities

Description

Ordering system Cell supervisor

Manual HS1

Cell operator

HNO1 and HNO2, HBO1 and HBO2 Schedulerrdrivers

Performs manually by HS1 Cell supervisor receives the job-list ŽW–T–L. and distributes within the cell This function entity was instantiated by four cell operators who use this modelling entity when using the modelling system. This is a driver Žinterface to the scheduler software available to the cell supervisor. ŽThis software was also used as the master scheduler of the company.. Cell application tool was developed for the cell supervisor. These cell application tools were developed for each type of operators ŽCATool-1 and 2. and were individualised for each user based on the user’s properties and access restrictions Žversion A and B.. In this test case, the modelling system was not physically linked to the execution system

Schedulerrdispatcher

Supervisor application Operator application

CATool-1 CATool-2 ŽA and B. CATool-3 ŽA and B.

Physical devices message dialogue monitoring

Not implemented in this cell

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

253

Fig. 6. Layout of the machining cell including cell control application, supportive tools, and infrastructure services.

model developed in this way. Information model generation was much simplified by having a knowledge of selected OVs required for the cell. The OVs were themselves chosen with reference to the BEs defined during step 1. Here, CIMOSA conformant information entities were converted into equivalent EXPRESS computer executable language constructs Žsee Fig. 7.. Ž8. Construction of the particular model of the case study cell was continued at the implementation level of modelling. Here, a CATool was generated for each group within the cell, with reference to the requirements of BEs 3 allocated to each group. CATools designed for each group comprise a number of ‘software components’ which conform to previously specified business processes of the semigeneric modelling structure. It was found that, in practice, a particular CATool developed for a group should be further individualised to cater for specific end-user preferences and restrictions. For example, in the case study CATool-2 was designed for ‘group-2’ of the machining cell. This

3

In principle, the CATools and their corresponding software components could have been designed and implemented with respect to requirements of each common enterprise activity; these common enterprise activities being defined by the semi-generic model. This can increase the configurability of the cell control software. However, because of a lack of sufficient development resources in this project, it only proved possible to design and implement generic software components at the granularity of each business process type.

tool comprises software components corresponding to BEs BP-1 to BP-5, that relate to domain process 2 that previously was allocated to this group. In addition, CATool-2 was configured separately for end-users HNO1 and HNO2, i.e., as CATool-2A and CATool-2B, respectively. Using these configured versions of CATool-2, specific end-users only have limited access to the information system, i.e., they only have access to information entities required to carry out particular tasks allocated to them. Furthermore, the properties of the graphical user interface ŽGUI. of each tool can be set up based on specific user preferences Žalthough this facility was not implemented in this research.. CATools also comprise a configured set of software components. This enables the CATools to provide programming functions that facilitate access to the system infrastructure. Thereby, cell elements can interact with each other and with systems elements outside the scope of the case study cell. Ž9. During this final step, pre-existing computer systems Ži.e., their hardware and software. should be configured to provide the services required to allow the CATools to interoperate with supporting systems. In this case, pre-existing systems used to support the operation of the case study cell included a database management system, scheduler software, a LAN communication system, and a computer server. The CATools can run on individual computer hosts, connected to the server via the local area network Žsee Fig. 6.. In this way, the CATools can be distributed but still gain access to the information system so that they can receive defined schedules of activities such

254

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

Table 4 Allocation of the business entities to the machining cell groups Cell groups

Domain process

Business process

Enterprise activity

Group 1 ŽSupervisor group.

DP-1, DP-2

Group 2 ŽOperator group. Group 3 ŽOperator group.

DP-2 DP-2

BP-1 to BP-6 BP-1 to BP-5 BP-1 to BP-T BP-1 to BP-5

EA1 to EA11 and EA14, EA2 to EA17 EA2 to EA17 EA2 to EA17

as job list, tool lists and other information required to complete a job. This approach also enables the definition of tools with a capability to collect real-time data from system elements for the purposes of monitoring and analysis Žalthough this was not implemented in this study because of time constraints.. The supervisor group also required access to the scheduling software to enable the distribution of tasks within the cell. Regarding the design and operation of the supporting information system, ‘core data’ related to the cell should be located in the database system with SQL addressing information added to identify rele-

vant information objects. These objects will be called as required by software components that comprise the CATools. Although as part of the design of the semi-generic modelling structure the use of an integration infrastructure Žsuch as CIM-BIOSYS. is advised, in the case study it was found to be sufficient and expedient to establish direct connections between system entities via network connections and management capabilities of a commercial database system—in this case, Microsoft ODBC. However, in practice, as the cell control system needs to expand to cover other parts of the manufacturing system, it will

Fig. 7. Part of the EXPRESS information model developed for the machining cell.

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

become necessary to implement a suitable integration infrastructure to enable consistent access to the information system and flexible and scalable interoperation between system elements. By using the modelling environment and CDTools to design and build the case study system, the resultant solution can be reconfigured and extended in scope with relative ease when compared with similar cell systems designed and built by conventional means. Indeed, inherent reconfiguration and extensibility capabilities embedded into cells via use of this model-driven component-based approach allows a system to be developed on an ongoing basis, even where requirements change unpredictably. Thereby, improved performance of the cell should be enabled and its lifetime increased via: ŽI. the organised Žre.structuring Žand Žre.targeting. of activities carried out by people Ži.e., engineering, managerial, supervisory and operator personnel. and machines that function as part of a target cell; ŽII. the organised Žre.supporting of activities Žand Žre.grouping. of activities by computer tools; and ŽIII. by maintaining consistency between changes made to ŽI. and ŽII.. However, the extent to which system reconfiguration and extension can be enabled by the methods and tools developed by this research needed to be assessed. Therefore, case study work was extended to assess likely benefits and practical constraints on the approach and on cell solutions developed via the approach. However, it must be emphasised that it was not practical to realise actual connections to Žand therefore actual control of. the case study cell. Rather, a pseudo-real Žor prototype. cell system was developed and run in the laboratory with modelledrsimulated machines and partially modelledrsimulated personnel. 4.3. System reconfiguration and extension— an initial appraisal Various types of change that have influence on the design and configuration of the ‘Hydraulic Cylinder Machining Cell’ were considered and classified and the ability of the model-driven, component-based approach Ždescribed in this paper. to accommodate each type was studied. The main classes of system change that were found to impact on the case study environment, and on the machining

255

and other cells in use in the host company, were classified as follows. 4.3.1. Class 1 change: operational process change This is a common class of change that impacts on the case study cell. Here operational details Že.g., product size and quantities, machining process and tooling deployed. may need to change even when the same class of product is being produced using similar sets of resources. In the case study cell, the approach and particular cell model developed for the ‘machining cell’ was found to be effective and efficient in accommodating this type of change readily by using modelling tools to modify information on the new processes and by rescheduling ‘job-lists’. 4.3.2. Class 2 change: physical resource change This class of system change is especially common when a semi-automated cell system is used to produce simple Žpossibly low quality. or make-to-order products. Examples of this class of change are adding an extra machine or operator to the cell to perform a specific process Žor processes. on semi-finished parts, or the unavailability of a machine because of maintenance procedures. For example, a ‘cylinder holder’ needs to be welded to hydraulic cylinders for a limited number of part types. Exceptional orders are handled by adding a welding process Žand related welding machine and operator. to the cell, operated after the copy-turning processes. Consequent on physical resource change rescheduling of roles, tasks and activities will be required to achieve an appropriate reorganisation of interrelationships between resources. It was concluded that in the case study system change of this type relies heavily on the expertise of the cell supervisor Žincluding knowledge of how to reschedule and balance the machining activities in the cell.. Using the model-driven, component-based approach, rescheduling knowledge is not formalised within the modelling structure, therefore the approach proposed is not designed to facilitate this type of change. However, if the supervisor requires a reorganisation of resources then as a result of applying a model-driven, component-based approach, the ability to rapidly and methodologically reconfigure mechanisms used to control, monitor and connect resources can much improve the ease and speed with which a designated change can be implemented.

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

256

Table 5 Modelling configurations required for accommodating the ‘machining cell’ changes Modelling step

Change on physical cell system

Change on modelling configurations

Cell tasks

Intermediate inspection. Data should be collected and sent to SPC for control and analysing.

Change on BEs. Adding DP-3 Žinc. BP13 and 14, EA6 to 10. Generating the allocated procedural rules for each inspection unit. Adding information enterprise object EO-4 Žinc. OV-41 to 44, IE041 to 418.. Populating data in database, providing accessing information. Adding to human resources—HI1 and HI2 Adding Cell Application Tools CATool-4 ŽA and B. to be used by HI1 and HI2. Adding cell inspection group Žgroup-4. Regenerating all the CATools based on the new modelling system configuration. Reconfiguring the network connects and accessing authorities.

Procedural rules Information requirement

The quality control information and instructions are required for inspection processes.

Cell resources Assign cell functional elements Cell grouping Generate cell control applications

Two inspection operators Žusing manual devices.. Inspection operators should receive their ‘job-list’ and report the control results in real-time. Inspection group Application tools Žand a computer host. for each inspection operator.

4.3.3. Class 2 change: production methods change The case study cell will, in general, require design modification to enable new production methods to be deployed, such as in the event of a need to manufacture a significantly different type of hydraulic cylinder or to cater for a significantly different mix of products. For example, for a future yet-to-be-designed high precision part, the grinding process may need to be replaced by or followed by a honing process and this might also require the use of new inspection activities and support tools. Use of the modelling system to produce prototype cells with different and changing production methods showed that this kind of change can often be realised quickly and effectively. An actual example change in production method that took place within the case study cell will be considered in detail in Section 4.4 that considers in further detail the effectiveness of the semi-generic modelling environment to cope with particular sources and types of change. 4.4. A worked example A real in-plant need for production method change occurred at the case study company where it was found that for ‘hydraulic cylinder’ production, an additional inspection process should be carried out within the ‘quality control’ cell. To tackle this problem in the real environment, it was decided that two quality control units should be used, one within the

‘machining cell’ to achieve ‘in-process’ inspection and the other in the quality control department to monitor and analyse longer term trends via the use of statistical process control tools ŽSPC.. The stepwise reconfiguration process illustrated by Table 5 shows the systematic way that the modelling environment and CDTools were used to facilitate the re-engineering of the cell in response to an unexpected change that was outside the original system scope.

5. Conclusions This research has developed and demonstrated the feasibility of a model-driven approach to design and build of change capable manufacturing cells. Essentially, the approach is a hybrid in that it marries formal top–down design and bottom-up componentbased build concepts. It operationalises enterprise models captured within a CIMOSA modelling framework, as this provides effective support for requirements capture and conceptual design decompositions. It complements CIMOSA concepts with detailed design modelling concepts that have defined mappings: to CIMOSA conceptual design modelling concepts; and to primitive blocks of functionality that can be realised by software components and assigned to specific activities in a cell. Thereby, semantic information generated during detailed de-

R.P. Monfared, R.H. Westonr Computers in Industry 40 (1999) 243–257

sign can also be retained and reused. It utilises a semi-generic modelling structure that facilitates and targets the way that manufacturing cells are designed and built, thereby specialising the use of more general CIMOSA concepts in a way that leads to model-driven, component-based, change capable manufacturing cells. The approach is partially supported by a modelling and model enactment environment. This comprises an organised set of software components. Use of this environment facilitates and targets cell Žre.design in conjunction with control system Žre.construction and debugging. Application of the approach has been partially tested with respect to its ability to accommodate change when producing prototype pcb and metal cutting cells of different types. To date, the approach has only been tested under laboratory conditions and the runtime control and monitoring of real-world cells based on the approach has yet to be demonstrated. However, real-world data has been used to populate cell prototypes Ži.e., to operationalise specific instances of particular models of cells. Further research is needed to gain an improved understanding of the way that the concepts embedded into the approach can or cannot accommodate different kinds of change. Following access to such findings, it is probable that the approach could be practically and effectively deployed by industry. It is likely, however, that the prime constraint on industrial take up will arise from a need for: various well proven Žand proprietary. software components Žand their primitive building blocks.; and explicit models of these components and of resources in common use within different manufacturing cell domains.

References w1x M.W.C. Aguiar, Executing manufacturing models of open systems: PhD Thesis, Loughborough University, 1995. w2x M.W.C. Aguiar, R.H. Weston, CIM-OSA and stochastic time Petri nets for behavioural modelling and model handling in CIM systems design and building, Journal of Engineering Manufacture 207 Ž1993. 147–158, Proc. Instn. Mech. Engrs., Part B. w3x ESPRIT Consortium AMICE ŽEd.. CIMOSA: Open System Architecture for CIM, Vol. 1 of Research Reports ESPRIT, Project 688r5288 AMICE, Springer-Verlag, 2nd revised and extended edn., 1993.

257

w4x G. Bruno, R. Agarwal, C. Reyneri, B. Chiavola, M. Varani, Making CIMOSA operational, in: Proc. of the European workshop on integrated manufacturing systems engineering, Grenoble, France, 12–14 December 1994, pp. 97–106. w5x H.R. Jorysz, F. Vernadat, CIMOSA—Part 2, Information View, Int. J. CIM 3 Ž1990. 157–167. w6x K. Kosanke, T. Klevers, CIMOSA: architecture for enterprise integration, CIM Systems 3 Ž1. Ž1990. 317–324. w7x R.P. Monfared, A component-based approach to design and construction of change capable manufacturing cell control systems, PhD Thesis, Loughborough University, 1999. w8x R.P. Monfared, R.H. Weston, The reengineering and reconfiguration of manufacturing cell control systems and re-use of their components, Journal of Engineering Manufacture 211 Ž1997. 495–508, Proc. Instn. Mech. Engrs., Part B. w9x J. Smith, S. Joshi, A shop floor controller class for CIM, Int. J. CIM 8 Ž5. Ž1995. 327–339. w10x F.B. Vernadat, Enterprise Modelling and Integration: Principles and Applications, Chapman and Hall, London, 1996. w11x R.H. Weston, J.D. Gascoigne, B. Zhang, An Open Systems Environment for Building Shop and Cell Controllers, EPSRCrACME final review report. Grant GRrJ56424, Swindon, UK, 1995. Radmehr P. Monfared gained his BSc degree in Mechanical Engineering from the Amirkabir University in Iran. He worked for some years in Computer Integrated Manufacturing Systems from Loughborough University. He is near to completing his PhD degree in the modelling and control of manufacturing cell systems. His research interests include the formal modelling manufacturing systems, applying distributed object technologies and system integration concepts and understanding related human issues. He currently works as a research associate in the MSI Research Institute. Richard Weston, PhD, BSc Ž1st Class Hon. is Head of the MSI Research Institute and Professor of Flexible Automation at Loughborough University. He has carried out personal research and supervised over 50 postgraduate staff and students in areas of enterprise modelling, enterprise integration, software systems engineering and flexible automation. He is author of around 300 publications. He is vice chair of the IFIP Working Group 5.12 on Architectures for Enterprise Integration; he is a member of various national ŽEPSRC, DTI, LINK and BS. committees and on the editorial boards of five journals. He is a visiting fellow for the EPSRC Business Process Resource Centre at Warwick University and Consultant Professor at Harbin Institute of Technology in China.