a data model for an assembly planning software system

ELSEVIER

‘.

Printed m Great Britam 095 I-5?4ll/Y7 $l7.00+ l1.00

PII: SO951-5240(97)00019-O

A data model for an assembly planning software system

Phong II-an* and Simmy Grewal?

CSIRO Manufactuting Science and Technology, PO. Box 218, Linajfield, NSW Australia 2070

A simple data model for assembly planning as a foundation for the construction of an innovative task-based assembly planning software system has been designed. The model uses ‘assembly task’ as its central object to which associations with other assembly objects such as ‘part’, ‘assembly’, ‘assembly machine’ and ‘assembly tool’ are made. It was used to derive a data template-based database schema for all assembly planning functions of the software system. The schema was connected with the software system’s front end user interface by pictorial data glyphs. The assembly planning model, the database schema, the user interfaces and the connectivity between the schema and the user interfaces are described. 0 1998 Elsevier Science Ltd. All rights reserved

Keywords: assembly planning software. task planning, database schema, data modeling

Introduction

Assembly planning is about engineering data management of assembly operations of various parts of an assembly. It uses assembly data for the generation of assembly tasks and task sequences of the assembly operations, the estimation of task time, the determi- nation of the number of workers required to produce a finite quantity of the assembly and the allocation of tasks to workers. It also involves analysis on handling automatability of assembly tasks. Assembly planning is hence a major task that requires experience and knowledge in industrial engineering to tackle those activities.

Despite the fact that there has been numerous studies and researches efforts to develop computer systems for the above mentioned activities of assembly planning’-‘, and the fact that those activities are correlated, and have to be concurrently dealt with in the practical environment, neither an integrated software system nor a model that contains all functions for the above mentioned assembly planning activities has been reported. Modeling of such a system remains an area of research interest. As a

*Email: [email protected] ‘[email protected]

result of this, a research project was initiated to develop an assembly-planning software system that has functions for those activities.

The assembly-planning software system, which is new for its kind, was developed for assembly engineers to use for the structure, design and analysis of assembly operations of various assemblies. It is not only innovative in its integration of activities for assembly planning and in its graphical user interface, but also in its concept. The concept is the interactive generation of sequence of work elements with knowledge-based handling analysis and time estimation, and dynamic line balancing. A work element is a task associated with one or more parts of the same kind. The concept was derived from a result of exten- sive research and consultations with practicing assembly and industrial engineers on various issues. The task and part association, the importance of task sequence in assembly planning in relation to part sequence, the complexity of analyzing geometric relationships between parts for sequence generation, the assembly task time estimation, the task-based line balancing, the required amount of data as input, and more importantly the users’ need on practicality of such a planning software-system, were among the areas of investigation. As already discussed in detail

267

268 Data model for an assembly planning software system: P Tran and S Grewal

in other papers8-‘2, the adoption of the concept is due to its merits and reasons which are:

The need to analyze complicated and network-like geometric relationships’ between parts in an assembly is not required in interactive task sequence generation. Only part attributes are required for handling analysis. A part’s assembly sequence, which is a subset of a task sequence, is not sufficient for assembly planning; Automatic task sequence generation, which is still elusive for practical usage, does not address the engineers’ need; Interactive identification and structuring of assembly tasks into a sequence not only is simpler with a high degree of flexibility and practicality, but also allow users to have a better control of the task sequence structure; Knowledge-based handling analysis and time estimation are based on a work element; Line balancing is based on a task sequence.

In the development of a software system*, not only approaches and methodologies for the functions but also graphical-user interface and data modeling were among the R&D activities. The software system has been intensively used in a number of manufacturing companies. The functions, their underlying methodologies and aspects of innovations, the role of assembly data and the graphical user interface have been discussed in detail in other papers”-“. However the data model for the construction of the software system has not be presented so far. In this paper the modeling of the software system, which includes the development of an assembly planning model, a database schema, functions and their connectivity with the user interface, is discussed.

Assembly planning model

Modeling of assembly planning activities is about depicting how and what objects and functions related to assembly operations are associated with each other in the making of a finite quantity of an assembly. The model is an important foundation for the construction of the software. In order to model assembly planning activities, it is important to understand the underlying concept of assembly planning. Assembly planning is a series of activities that deals with the operations of assembling parts to make a known quantity of an assembly within constraints, such as assembly line capacity and available resources. Assembly operations are a series of assembly tasks to join parts together. A task is always associated with one or more parts of the same kind, and as such the association of task and part is called a work element. For example, ‘load part A to part B’, ‘tighten part A to part B with screw driver’ are two work elements involving two tasks ‘load’ and ‘transfer’. There are always more tasks than the number of parts in an

assembly. Tasks are also associated with other objects such as assembly tools (in the above example the screw driver) and machines used for enabling assembling operations. Tasks are sequenced and grouped and each group of tasks is assigned to a worker. Tasks are therefore the center of activities of assembly planning. In other words, assembly planning is about planning of assembly tasks, which are the work elements. One aspect of assembly planning is to define and organize work elements into certain sequences (task sequence generation) and then to analyze each of them (task analysis). The analysis uses user-defined part’s attributes and its handling characteristics as data input for determining the handling device and assembly machines or tools to be used (equipment selection), and for estimating assembly time (time estimation). The second aspect of assembly planning is to group tasks (line balancing) to determine the number of workers required and to allocate groups of tasks to workers. The assembly planning activities, namely tasks and task sequence generation’, handling analysis and equipment selection’“, time estimation” and line balancing’*, are modeled as shown in Figure 1.

The model in Figure 1 shows six object classes namely ‘Part’, ‘Assembly’, ‘Assembly machine’, ‘Assembly tool’, ‘Task Sequence’ and ‘Assembly task’. While the first four object classes are real, the last two classes are associations modeled as object classes. An object class is depicted by a unique name on the top and its attributes and functions below. The model indicates that many ‘Parts’ are assembled onto

consists of 1

uses 1

Figure 1 Assembly planning MODEL.

Data model ,for an assembly planning software system: P Tran and S Grewal 269

themselves to make an ‘Assembly’. A solid circle with the notation ‘n’ attached to one end of the link implies many (one or more)13. An ‘Assembly’ becomes a ‘sub’ when used to assemble into other ‘Part’ for a larger ‘main’ assembly. An association- typed ‘Assembly task’ is always associated with either one or more ‘Part’ or ‘Assembly’. Many ‘Assembly tasks’ are structured into a ‘Task sequence’. ‘Assembly machines’ and ‘Assembly tools’ are used in ‘Assembly task’. Many ‘Tasks’ can be associated with an ‘Assembly tool’ or an ‘Assembly machine’. There is a possibility of (n) task sequences for making an assembly.

The model shows object class ‘Assembly task’ is the center of all associations with the other object classes. Object classes ‘Part’, ‘ Assembly’, ‘Assembly machine’ and ‘Assembly tool’ are associated with each other through object class ‘Assembly task’ and ‘Task sequence’. This is in line with the understanding of assembly planning described earlier. Assembly planning functions associated with these object classes are sequence_generation(), line_balancing(), equipment_selection() and time_estimation(). The sequence_generation() function is used for creating instances of the ‘Task sequence’ and ‘Assembly task’. The line-balancing0 function is for the line balancing on a created instance of the ‘Task sequence’. The equipment_selection() and time_ estimation0 functions are used on each instance of the ‘Assembly task’ for selecting handling equipment or estimating assembly time.

The database schema

The model in Figure I is used as a basis for deriving a database schema from which instances of object

classes can be created and stored. A database management system called Data Glyph System (DGS) was used for creating the schema. A database schema is a structure of data templates or data tables in the database. The DGS14, a Sun Microsystem (Inc.)‘s Xview’O-based system developed by a software house called The Preston Group PiLtd, uses data templates in comparison with data tables in other relational database systems, such as Oracle”,‘“, as the base for creating schemas. It is an in-house developed system suitable for applications in which object aggregation and association play an important role. It is found suitable for supporting the assembly planning model in which ‘Assembly’ is an aggregation of ‘Part’, and when ‘Assembly tool’ and ‘Assembly machine’ are the indirect associates of ‘Part’ and ‘Assembly’. The DGS-based data templates of object classes ‘Part’, ‘Assembly’, ‘Assembly machine’ and ‘Assembly tool’ are shown in Figures 2-5, respectively. The data template namely ‘task_ref’ of the object class ‘Assembly task’ is shown in Figure 6.

A DGS-based data template contains two important fields, ‘TEMPLATE NAME' and ‘Data Fields’. The value of the ‘TEMPLATE NAME' is the data template’s identifier. The ‘Data Fields’ contains a list of members of the data template. The data type of a data field can either be integer (int), float, string (char), pointer (ptr) to another data template, or data-template (tmpl). A pointer (ptr) field is used to allow access to data fields of the data-template to which the pointer is set. A ‘tmpl’ field must have an existing data-template attached. In this case the attached data-template becomes a sub-data template of the data template to which the ‘tmpl’ data field belongs. This sub-data template can only be accessed through its main data template. The value of the first

a dat_o bJ “part”

EMPLATE NAME : part

([ICON FILE]) : $PFAHOME/iconshart_icons/generJc_icons/default m [HELPI : dss: object ql wh

ICON FOREGROUND COLOR : m ! &.;;. k%

ICON BACKGROUND COLOR : m yellow

SUB OBJECT LMEL? : @

SUB MEET NUMBER? : m (Data Fields T) II) (ncllf) (3) GENERIC ICON) (41 PHOTO ICW)

(5))( ) 6) PHYSICAL STRUCTURE (7))

c6, K~(cl) (STCWDARI)) (101 STRUCIURAL C0NDI-M)

(11) ENVELOPED SHAPE) (123 DIMENWM) 13) SYI+ETRV A6OUT X-AXIS)

f 14) SVMTRV AWJT V-AXIS) (is> SVttmw llBOUT 2-AXIS)

(161 DETECTA6LE OFIIENI-INC FEATURES) (17) PHVSICAL FEATURES)

(181 MAX. ROT. ANGLE)

([OPTIONS] v)

Figure 2 data template ‘part' for object class ‘part'.


Figure 3 Data template assembly’ for object class ‘assembly’.

Ia, dat_obj “assembly”

TENPLATE NW : assembly,

([Iccm) : ~PFAMWicons/general_icons/esseebly.icon

[HELP] : dgs:object qlyph

SUB OBJECT LABEL? : @

SUB OBJECT NUMBER? : a

(Data- R (23) (3)] (4, CREATE B.O.H.)

5) SEQ SET (6) CREATE T&K BOX) (7) PRODUCTIOH DATA)

(8))

([opTIoNsI)

member listed in the ‘Data Fields’ of a data template is defined as the identifier of each instance of the data template.

Shown earlier in Figure 2 and Figure 3, respectively, are the complete lists of the data fields of the data templates ‘part’ and ‘assembly’. The diagram in Figure

7 partially shows the structure of the DGS-based data fields of the data template ‘assembly’. Seen in the diagram are rectangular boxes having two notations in each box. A data template is described as a gray rectangular box with the data template’s identifier on top and the notation ‘obj’ below. Other boxes are the data fields of the data template from which the data fields descend. The boxes have the top and lower notations as their data field names and data field

types, respectively. The data field names are those seen listed in the ‘Data Fields’ of a data-template. Data template ‘assembly’ has two ‘tmpl’ data fields called ‘CREATE B.O.M' and ‘SEQ. SET'. They contain data templates ‘part_ref ’ and ‘sequence-set’, respectively. The data template ‘part_ref’ has a pointer field ‘ASSY'S PART' set to point to the independent data template ‘part’ and an integer field ‘QTY' for the quantity of the ‘part’. Each instance of the data template ‘part_ref’ is an element (a part and its quantity) of the assembly’s BoM. The data template ‘assembly’ has a one-to-many association with data templates ‘part_ref ‘ and ‘sequence-set’, i.e. an instance of the data template ‘assembly’ can have (n) instances of data template ‘part_ref’ and (n)

1 dat_obj “process equip lib”

TEWLATE NAME : process equip lib

(FILE]) : $PFAHOHE/icons/general_icons/urocess eauip.icon

[HELP] : dgs:object_glyph

ICOH FOREGROUND COLOR : a -frMt@ uUe:< I,,

ICON BACKGROUND COLOR : @ y~#hs ~ ;.,

SUB OBJECT LABEL? : a

SUB OBJECT NUMBER? : @

(Data) (1) (NAEE) (31 OPERATIONAL PIPE) (43 CYCLE TIR TYPE)

(53 CYCLE TfK (SEC.)-) (6)m) (71) (8)m-j

(9) PART LOAD TIME) (101 PART UNLOAD TM)

(--+)

Figure 4 Data template ‘process equip lib’ for object class ‘assembly machine’.


P dat_obj “tool lib”

TEfiPMTE NME : tool lib,

(FILE]) : SPFAHOWicons/general icons/tool.icon

[HELP] : dgs:object_glyph

ICON FORECROLIND COLOR : m fraae blue

ICON BACKCROLIND COLOR : m $&$k ‘:‘: :i :”

SUB OBJECT LABEL? : w

SUB OBJECT NUMER? : m

Data Fields v ) (1) (2)) (3)) (41 CYCLE TIME TYPE)

(5) FIXED CYCLE TIM (sec.>) (%%i?ii) (7))

(a)) (91 PhRT HANDLING TYPE) (IO) PMT SUPPLY TYPE)

(11) TOOL LOCU) TIE) (12) TOOL UNLOAD TIME) (13) TOOL HANDLER TYPE)

([OPTIONS])

Figure 5 Data template ‘tool lib’ for object class ‘assembly tool’.

instances of data template ‘sequence-set’. This reflects the fact that an assembly can have many parts and many assembly task sequences. Similarly data template ‘sequence-set’ has a one-to-many association with data template ‘task_ref’ through its ‘CREATE TASKS' data field. It has an integer field to store the

number of workers required to make a finite quantity of the assembly. Each instance of the data template ‘sequence-set’ can have (n) instances of the data- template ‘task_ref ‘.

Shown earlier in F@AW 6 is the complete list of the data fields of the data template ‘task_rcf’. The

TEMPLATE tiAM : task ref

m blLq : $pFAHOME/icons/task_icons/default_task.icon

[HELP] : &s:object_glyph

ICON FOREGROUND COLOR : m framla b$w

SUB OBJECT LPBEL? : m

SUB OBJECT NUFBER? : @

Data kislds D . . . . . . . . ..I..._I._._.-..-_--_._.._ 3 TASK m (2> __..______~_____ ______________.___.______ ) 3) lASK kULL NAW (43 ____.....-._________ ------__----I__~_---- 53 t- (6) ASS- . .._______.__~~___ --___".- .____"~~__--.--_-___ ,,

Cs) C1D) (sec.r)

__TYPEZj_)

-VW)

FLOAT TASK m

Figure 6 Data template ‘task_ref’ for object class ‘assembly task’


diagram in Figure 8 shows a number of those data fields and their structures. As indicated earlier in the object model in Figure 1, ‘Assembly task’ is associated with ‘Part’, ‘Assembly’, and ‘Assembly machine’ or ‘Assembly tool’. As seen in Figure 8, the data field ‘EQUIPMENT INVOLVED' of the data-template ‘task_ref’ is an array of pointers pointing to independent data templates ‘process equip lib’ and ‘tool lib’. ‘Process equip lib’ and ‘tool lib’ are the data templates of object classes ‘Assembly machine’ and ‘Assembly tool’, respectively. Data template ‘associated-part’, which descends from the ‘tmpl’ data field ‘ASSOCI-

ATED PART' of the ‘task_ref’, has two data fields: a pointer data field pointing to the data template ‘part_ ref’ of the data template ‘assembly’ and an integer field for the quantity of the part associated with the ‘task_ref’. The data field ‘PRECEDENT TASKS' of the ‘task_ref’ is a pointer set to point to the data template ‘task_ref ’ itself, i.e. the pointer of one instance of the data template ‘task_ref’ can be set to point to other instances of the ‘task_ref’ to indicate that the instance that owns the pointer is preceded by the other instances to which the pointer is set.

An example of the schema described in Figures 7 and 8 is shown in Figure 9. Figure 9 partially shows

instances of the data template ‘assembly’ and its sub-data templates. Seen in the instance of the data template ‘assembly’ are the values of its data fields: the identifying value ‘fcvrassy’ and name ‘Front ccvr assy’, the identifiers of the instances of the ‘part_ref’ following the ‘tmpl’ data field ‘CREATE B.o.M', the identifier ‘Set#l:fcvrassy’ of one instance of the data template ‘sequence-set’ following the ‘tmpl’ data field ‘SEQ. SET'. Seen in the instance of the ‘part_ref’ are its identifying value ‘47M15598Pl’ following the data field ‘ASSY'S PART' and an integer value ‘1’ following the data field ‘QTY'. Because the ‘ASSY'S PART' is a pointer data field pointing to the independent data template ‘part’ (Figure 7), its identifying value is inherited from the identifier of the instance of the ‘part’ to which the pointer is set. Seen in the instance of ‘the sequence-set’ are the identifying task numbers of instances of the data template ‘task_ref’ following the ‘tmpl’ data field ‘PCREATE TASKS'. Seen in the instance of the data template ‘task_ref’ are the identifying task number, task description, the identifying task number of another instance of the data template ‘task_ref’ following the data field ‘PRECEDENT TASKS', the identifier of an instance of the data template ‘tool lib’ following the data field

I n

CREATE TASKS

Figure 7 DGS-based data fields of data template ‘assembly’.


--

l TASK NUMBER I

ASSOCIATED PART 1 1 PRECEDENT TASKS

-- tmpl II pointer to “task_ref”

Fgj Figure 8 DGS-based data fields of data template ‘task_ref.

EQUIPMENT INVOLVED

pointer to “process equip lib” or “tool lib”

assembly “fcvrascy”

ASSY ID : fcvrass~

SEQ SET NRME : setwl : fcvrassv-

SET NUMBER : 1

CURRENT TASK NUMBER : 22

<CREATE TASKS) <l, l:l:fcvrassy> c2) 1:3:fCVraSSy) <3) 1:4:fCVraSSY>

(4) 1:5:fcvrassy] (5) 1:e:fcvrassy> C6) 1:7:fcvrassy) -___

<73 1:a:fcvrassy> <a, l:s:fcvrassY) cs, 1:lo:fcvrassYj .__.“______________._._._.....__/ -.....----.-.- _-I-- --_-___--

m CREATE TASKS **1:7:fCVraPsY”

I TASK NUMBER

TASK DESCRIPTIG+d

1:7: fcvrassv-

Tl shten

< LY-~ Pas j

CF TASK FULL N*M T, ghten AAODOI ~2.5~6~

CR1 C:p_~.EC~_~~N.~_~.~~~> c 15 1:1s:fcvrassy) _......._.^^.......... - . . . . . . . . . ..-

SEQ cAN, (EQUIPMENT IrwoLvm] Cl> tool 2)

<GO c-AN”* ASSOCIATED PART : C 1) AAOOD~~Z. 5x6~)

Figure 9 An instance of object class ‘assembly’.


‘EQUIPMENT INVOLVED' and the identifier of an instance of the data template ‘part_ref’ following the data field ‘ASSOCIATED PART'.

Connectivity between the schema and the front end user interface

The main window of the developed assembly planning software system is shown in Figure IO. Seen in Figure 20 is a task sequence of assembly ‘Front cover assy’ selected from a list of assemblies in the DGS database. The task sequence is visualized through two types of data glyphs as the front end user interface for creating and editing assembly data. As seen in the figure, the darkened pictorial glyphs are for tasks and the others for parts. A part glyph is attached to a task glyph to represent a work element of an assembly operation. A work element is created from a generic task list and the bill of materials (BoM), i.e. parts and their quantities, of an assembly. A task has to be interactively specified first before a part can be attached. An arrowed line between two task glyphs represents a precedent link between the two tasks. It is used to create a task sequence. The task list and the BoM are shown in the pop-up window at the right hand side of the main window. Parts with their attributes are individually and independently created and stored in the database.

The example seen in Figure 9 is visualized in Figure IO. Instances of the data template ‘assembly’ and instances of the data template ‘part_ref’ are created using function born-create0 embedded in the button ‘Assembly’. Instances of the data template ‘part_ref’

are linked to items of the BoM’s listing. The name ‘Front cover assy’ of the instance of the data template ‘assembly’ is shown above the button ‘Assemblies’. Instances of the data template ‘part’ are created using function part-create0 embedded in the button ‘Parts’. Instances of data templates ‘process equip lib’ and ‘tool lib’ are created by two functions mc_create() and tool_create() embedded in button ‘Equipment’. The instance of the data template ‘sequence set’ identified as ‘Set #l: fcvrassy’, which owns instances of the data template ‘task_ref’ as seen in Figure 9, are shown. An instance of the data template ‘task_ref’ is created when a task item in the task list at the right hand side of the window is selected and placed on the window’s canvas. It is visualized by a task glyph. The setting of the pointer in the data field ‘PRECEDENT TASKS' is done by ‘mouse-clicking’ on two task glyphs sequentially. The association between an instance of the data template ‘task_ref’ and an instance of the data template ‘part_ ref’ is made when an item in the BoM’s listing is selected and placed on the task glyph representing the instance of the ‘task_ref’. A ‘double click’ on a task glyph will open other windows for data input, such as setting pointer to one of the instances of the data template ‘process equip lib’ or ‘tool lib’, to the data fields of its instance.

Conclusion

The developed assembly planning software system is new for its kind. It was developed based on the core data model presented in this paper. The data model

C96797201 AA000lp2.5x6z:Scr bind

Clsw Data Ha "lf . . .

------ -_ (Sub-&q. 0: (PhtParts 9 I----- _~__~_ __-/ I_-_

-

Figure 10 Main window of the assembly planning software.


was designed using ‘assembly task’ as a central object to which associations with the assembly objects ‘part’, ‘assembly’, ‘assembly machine’ and ‘assembly tool’ were made. All assembly planning functions were incorporated into the model. The model was used as a basis for the design of the DGS-based schema and visualized in the software system by a task glyph and a part glyph coupled as a work element in an assembly task sequence. The translation of the entity relationship model and the schema into the software system was transparently simple with the use of the innovative graphical user interface. The simplicity of the data model is reflected by the user-friendliness of the software system in terms of creating instances and their associations, and data input for data fields of instances.

References

1 Nevins, J and Whitney, D Concurrenf Design of Producrs utzd Processes. McGraw-H& Publishing Co. ” ”

2 Boothrovd. G Assemblv Auromation and Product Des&w. Marcel Dekker inc.. New Y&k

</

3 Delchambre, A Computer-Aided A.ssemhly Planning. Chapman and Hall.

4 Homem de Mello, L and Lee, S Computer-Aided Mechnttic~rtl

Assembly Planning. Kluwer Academic Publishers 5 Lee, K and Gossard, D ‘A hierarchical data structure for reprc-

sating assemblies: Part I’, Computer-Aided Desip. Vol I7 No I (19X5) IS-19

6 Walter, J ‘A combinatorial analysis of enumerative data structures for assembly planning’. J. o/‘ Dc.si,p trtul ~M~tttufuc~wirtg.

Vol 2 ( 1992) 93- IO4 7 Boothroyd Dewhurst Inc, Design ji,r il.ssemh~v .SO~~I~CIW Tool-

Lker Mutruul. Boothrovd Dewhurst Inc. 8 Grewal, S n-an, P -and Bhaskare, A ‘Assembly planning

software’. Atrtzuk oft/w CIRP. Vol I No 144 ( 1905) I --h 9 Bhaskare, A ani Newton, R Asxcn~hlv ’ S’cqkrcc Dc.sip

Met/&s. Int’l Conf. On Assembly. Insiitutc of Engineers, Australia (1993), pp IOY- I IS

IO ‘D-an, P Eqttipttwtt Sclecfiorr For A.ssettzh/v ~~petw~iorts, In t’l :;(l;lf;En Assembly, Institute of Engineers. Australia (1YY-i) pp

I1 ‘D-an, P and Grewal, S A,ssett~h!v Tittw E,slittrrrtiotl Itt A.ssctnh!~ Phtzirzg Sofiwwrc. Int’l Mech. Eng. Congress and Exposition. CED-V‘ol. i (1995) pp 47-52. AStiE -

12 ‘D-an. P and Grewal. S Sofiwore For Littc HuktttcittL’. The 6th Int’l ‘Conf. on Manufacturing Engineering. Vol. I i&titute of Engineers, Australia (IYYS) pp f&OX

13 Rumbaugh, J Objcci-Oriettkd Modclittg uttd Dc+l. Prcnticc- Hall International. pp X%-300

14 The Preston Group, 7%~ fX;S C’sw Muttuul. The Preston Group P/L. Australia

1.5 Oracle Systems, C‘o~r:sc~ Notes Ott Onrck RDRMS SQL. Oracle Systems, Australia

16 Rumhaugh, J Oh;(,i.r-0riettrcti Modc/itt,q rrtttl Dcsipt. Prent icc- Hall International. pp 21-45

a data model for an assembly planning software system

Documents