- Email: [email protected]
The Product Structure — The Backbone of CIM
The Product Structure
- The Backbone of CIM
Lars Lindberg, Professor Erik Agerman (2) Received on January 14,1992
In rhis paper we argue that the product s t r u c ~ r eshould be used as the backbone for the modelling and documentation of the product. Fiat a general architecture of a Technical Informadon System. T I S . based on Functional Sysrcms is presented. Then three major subsystems of the TIS are identified. and one of these, the F'roduct structure System is discussed in greater detail. The product structure is shown to be in a sense both complete and stable, thus providing a foundation for a m e CIM system. A simple, yet venariie, data model is presented, allowing variants and views of the product to be represented. Key words: Design, Data model, Product s n u c m
2. Information System Architecture 1. Introduction
The production process can be viewed as a flow of data. when the customer specification successively is aansformed into the manufacturing documentation. which in turn is used for the actual manufacturing of the product (figure I). This process generally consists of two different phases: a development phase and an order phase. (figure 2). cf [Sohlenius 76). The development phase produces as a main result a producr remplare. i.e. a generic documentation of the product. including a product structure, design rules, planning macros. parametric drawings etc to defme the family of products covend by the tempIate. During the order phase the product template is used with the specific order data to create a (possibly unique) instance of the product documentation. These primary or rechnicddarnflows are controlled by parallel flows to follow up costs. schedules. quality etc. Thee controlling flows will, however, not be further discussed in this paper. Here we will concentrate our discussion on the role of the product structure in this Jam flow. We will do so by fmt briefly discuss the major activities and typical daca volumes associated with these. Then we will give a general characterization of these data. and based on this suggest a general archirectum of a computer system to sbpport these activities. This architecture will as a major component have a subsystem to handle the product smcture. and this subsystem will be the main theme for the remainder of this paper.
CQT Customer Order
[-&qlcmfao n
Cust Doc Cornpl.
CQT
cost, Quality. Time Material
I
CQT I
I
Schedh& Product Manufacturina
---_ Figure I. Busic dataflow in a man@acricnng company Policies
Desrgn,Systematics
"he major activities within the primary data flow are related to the sales, design. planning and scheduling functions of the company. Some of these functions do often conrain major subactivices; the design function for instances may comprise technical calculations, layout design and detailed design, and the planning function may include process planning, operation planning and NCprogramming. Typical for the data tlow is that most activities are serially connected i.e. an activity takes its input from an 'upstream' activity and delivers its output to a 'downstream' activity. The actual activities urried out, and thus the amount of data handled, are of course highly dependent on the complexity of the product. if it is made to order or made to stock. if it is a standard product or if it is one of a kind etc. Nevertheless our investigations [Agerman 911 suggest that the output from ir.ictivity is roughly an order of magnitude larger than the input. A small number of let's say 20 input data from the customer can therefore eaS;!y generate 20.000 or more data to be tised in the manufacturing process. and this for one order only. 2.1 The Functional System Approach
It is well beyond the c m n t state of the art to maintain the relationships between the data mentined above (and this might not even be desirable). but the requirements from the secondary data tlow Le. the flow controlling cost. quality and time) enforces a structuring of the dau of the primary data flow. We suggest that the general architecture of this system is founded on a set of independent but cooperating subsystems. called Functional Systems Nugoson 871. Further we suggest that each of these Functional Systems share a common architccrure. with three major subsystems: a Technical Adminismtive System. a Product Smcturc System and a Geometry System. W i will call this system a Technical Information System. TIS. The main rationale behind the Fuiictional System approach is the observation that each activity in the data flow outlined above is carried out by an autonomous unit within the company, by Hugoson called Functional Unit. Each of these units have: a chaner (i.e a well defined task to carry out), responribiliiy to carry this task out, and the necessary resources to do so. These resources should also include any computer support needed for the task A key thing to note is that the Functional Units are reasonably stable w e r time. compared with e.g. the actual organization. Each unit should therefon: be supported by a system of its own, a Functional System. FS. The different functions, and thus FSs, must of course communicate data between each other. We will call these data documenrs. in analogy with a manual system. Genenlly these documents share some fundamentalproperties:
-
a simple structure (cf below). stability, i.e. the structure and contents do not vary over time. - have low volume. . are not time critical. In a manufacturing environment all documents share a common overall suucture. Each document has a:
-
primutypun. the 'title block' of the document.
subjecrpan. the actual content of the document. revisionpar!. the history of the document.
The primary pan has nttributes like: idenriry (i.e. a unique identifier of the document). owner (i.e. the functional unit responsible for the document). ~rarus (i.e. 'approved', 'under revision', etc). rype ( i t . a specificationof the content of the document). etc. The attributes of h e subject part is dependent on the application and type of document. Order
The revision p m has at !east a revision index to uniquley identify each revision of the document. It should be noted that an FS uses other ddta than documents recieved from other FSs. These internal data may often be documents in their own right, e.g. the product template used in the order process.
Figure 2: Developmenr and order phuses of manyucruriny process
Our general system architecture can thus be summarized in the following picture (figure 3):
Annals of the CIRP Vol. 41/1/1992
165
'8
production engineer databases for e.g. tools. fixtures and machines, and a sales engineer needs a module to calculate the product cost for tendering purposes. etc. We do. however. view these systems as auxiliary systems to the general core of the ITS.comprising the above three subsystems.
3. Product Structure Handling The Product Structure is a model of the product describing the amibutes of the constituent parts and their relationships. Structures of products have been represented for a long time in MRP systems. These systems are, however, specifically railored for planning and scheduling purposes and do nor provide a general snucture handling capability. Now we are beginning to sec commercial systems with some of this functionality, e.g. PDM from Intergraph [Intergraph 901.Dese systems do, however, not yer show aiy greater sophistication.
I
It is of comse also an i m p o m t question to ask whether we need a separate Smctun system at all? Can't the Geometry system be used to handle the structure as well? There are several reasons to keep these systems apart:
!
-
the large volumes of attribute data needed for a complex product calls for a specifically railoied representation.
I: should be suessed that the FSs are not inregrated in the xnre :hat they do not
-
use the same physical data. and they do not generally operate on a common data structure. However, we do believe that the Functional System apprnach has some distinctive benefits comparcd to more 'integrated' approaches. These knefits can be expressed as independence i n terms of:
the connections to systems for monitoring and controlling cost quality and time require that the product structure isexplicidy available.
-
tht product smcture is reasonably stable for modifications to the product. which means that similar structures can be used for different insunces of a product family.
-
the product structure is complete in he sense that all pans that m needed to manufacture the product are included.
-
the structure is flexible in that new types of data can easily be included, as well as new views of the product, cf below.
-
the geometry model is representing continuous aspects of the product (shape and dimension), while the suuctun model is discrete.
Figure 3. Funcrionul Sysrems communicating wirh hiocurnenrr
- functions. i.e. a modification (e.g. of data structures or functionality) of one FS does not affect any other FS.
- rechnicafsolurions, i.e. a new FS can be included at any time. and any two FSs may use different basic hard- and software.
- rime. i.e. an FS is not dependent on any other FSs being run concurrently. To summanze: the FS approach gives a stable. incrementally upgradable and flexible system. 2.2 TIS Architecture We will use the operarional definition of a Technical Information Svstem, TIS. as being the computer system used in the activities of the primary data how. The TIS will thus include the systems used to produce and vlllidate the data needed to manufacture the product. The systems needed to monitor this process. in terms of cost, quality and time, arc nor included. The TIS for a whole company consists of many Functional Systems. However, we suggest that they a11 have a common basic architecture. To arrive at the major components, or subsystems, of a TIS,we note that the data handled by the TIS are always directly related to the product and its documentarion.Three major categories of data can be distinguished:
The discussion here on the functionality needed and documentation principles used are largely taken from the experiences at Asea [Asea 761. [ABB 891. The simple product example is taken from [WF 901.We will s m off this presentation with some general definitions and concepts, and then move on to two important issues: how to represent a large number of variants of one product. 'open snucms'. and how to represent different views of the same pmduct, 'parallel suuctuzes'.
- mera-dara. i.e. 'data about data', or basically the data contained in the primary pan of the documents, cf above.
3.1 Structure Handling: General Concepts
- data describing the shape of the pans making up the product and the relarive posirions of these pans. or geometry for short. - data describing the arrribures of the pans and the pan-of relation to other pans. or (producr)srrucfurefor short.
A designer typically represents geomerry in 3D models and drawings. and
structure in pans lists. For a production engineer the interesting geometry may be the NC tool paths and the surfaces used to generate them. and the suucture the lists of operations and material for each part. For an engineer carrying out calculations the geometry may be represented as a finite element mesh and the attributes being material data and boundary conditions. The TIS will correspondingly consist of the three subsystems: the Technical Adminisative System (or TA-system), the Geometry System and the Product Srructure System (figure 4). The TA- sysem will have three major functions: to serve as a 'posunaster', i.e. handle the convnunicurion with other FSs, to handle rhe docwnenr odimisrration, i.e. the approval cycle prescribed e.g. by the I S 0 9000 family of standards [IS0 871, and to connect the Geometry and Suucturc subsystems. The TA-system will not be funher discussed here. for a further description see &idberg 911. Neither will the Geometry System be discussed here; the literature on geometric modelling and CAD-systems IS prolific. The Product Structure System will be the main theme for the rest of this paper.
-I
When manufacturing a product. raw material is machind to produce compoi~ents which are assembled (with other. purchased, components) to create different semifinished products and finally the complete product. as the simple example in figure 5 shows. Each step on the path from raw material to finished pmduct is called a refining level. The documenration of the product is generally tied to the refining levels, by one ponr list and possibly one derail or assembly drawing for each level. This smcturc is strictly hierarchical. Like aU other structures we are going to discuss here. We will refer to a node in the structure as a purr, irresFcctiveof where in the structure we find it. A component is a leaf node in the structure. We will sometimes refer to the root node as theproducritself.
%
Grinder 0021
Conveyor 0008 A e e d e r 0001
Technical Administrative
System
Structure System
s i
GearBox 0018 Tool 0011
b
Figure 5 Simple example of product sfruccure
i
To npnsent this and similar product smctures. we suggest the following data model, figure 6.
System Figure 4 TlS arclurecrure It should be noted that the three wbsystems above of couise not aie the oiilv
modules of a TIS. A n analyst w ~ l lobviously need e g
166
Below we will present some basic data models representing the Product Structure. These data models will be given as Entity-Relationship (ER) models [Chen 761. using the notation of 'Enhanced ER' in Elmasri 891.
J
FE package,
documenr generarion. As mentioned above the norm31 way of documenting a product smcture is through pans lists. These lists must be possible to generate from the structure system. 3.2 The Configuration Problem: Open Structures
I
In this section we will discuss some of the problems related to srmcture handling and variant design. A problem we encounter when we create variants of a product. is the proliferation of similar parts. If we e.g. were to design a variant of the Grinder (figure 5). only by changing the Tool (0011). we would have to create new parts on all superior levels, i.e. Agitator, Drive Unit, Rocessor and Gnnder. to maintain the uniqueness of the pan numbers. Each of these new pans should be documented by a pans !is.
COnSISiS-Of
jRefDacumentl Figure 6: Dara model;or Product Structures The term matrix for this model is ( w i t h the number of attributes kept minimum):
10 :I
Ohjeccs: Physical Part (oan,descnption, geomeny-pointer) Non Geom Pan (Dan,description) description, doc-type) Ref Document -, descnption, mfg-address) Operation Parameter !oariJ-, descripnon, default-valuej Occurence fgccurcnce id, quanrity) Catalogue karaloeue id, descnption. type)
C u ,
Relanonships: part-occ @an no. occurence id) consists-of (occurence idl. occurence id?. item-no) catalogue-pan
(w)
The key elements of this model 321: the Pan and Occurence entities. These entities represents the clarses of pans end their specific occurences respecnvely. Tliis splii is necessq to represent pans occurring at several places in one stnictiitr, like the Scnw W20. i n our example. The dcrual structure IS represented by the simple recursive relationship consists-of
In h e darn model the Part entity has been specialized into several different types of 'pxts' to illusrate how easy the data model can be augmented The following list of specializations is by no means exhaustive:
-
physical pans. with a geometric representation. All parts shown in figure 5 belong to this category.
-
physical pans without a geomemc representation. Paint and glue are typical examples here, but minor standard parts like screws may belong to this category.
~
-
referenced documents, most importantly the drawing, but also Technical Rovisions. Testing Insmctions. Quality Conuol Procedures etc. manufacturing operations; the process plan for a part can be regarded as a subsnucture of the p a n
- pmacccrs, used e.g. to generate a drawing or process plan for a paramemc Pan. Some of these specializationsof the Pan entity may also require a specializationof the corresponding Occurence entity. This specialization is suggested by the das!ied lines of figure 6. The Catalogue entity has been included to provide a simple way of finding the root nodes of a snucture. As for the Occucence entity specializations of the Catalogue could often be motivated. Actual products could be stored in one catalogue. standard pans in another, operations in a third etc. Above we have given a reasonably detailed data model of a structure handling
system. Some of the basic user functions needed are listed below. We want to s u e s that several additional functions may be desirablc, and that the question of user interface is quite complex and well beyond the scope of this paper.
-
~
One solution to this problem. well-known from many application areas as a conjigwarion problem, which successfully has been employed by Asea [As- 761 for many years (a similar approach is taken by Scania for mcks [Scania 901). is built on two observations:
- the structure is identical for all variants of the product.
-
for every (manufactured) variant it is only n e c e s s q to save the data needed to unambiguously recreate the manufacturingdata.
These observations yield a solution where a generic variant of the product is documented, just like a unique product above. including pans, components etc. However. for each position in the structure where a variant is possible. we simply specify that the acmal variant (i.e. pan number) will be specified in a separate document. the Order Document, OD. In the generic structure we specify this by an additional attribute to the corresponding Pan entity. This means that our product suuctm is not completely specified. We call this tyrx of s r m c ~ r open e and consequentIy the not completely specified nodes in the smcture openings. We call the process to unambiguously specify the openingsclosing the smcture. The number of documents needed to specify the product with its variants is in the magnitude of the sum of the variants for each component. In addition to this an OD fot every order is needed. The Order Document should contain the necessary data to unambiguously specify a distinct vuiant. It must thus contain: - An Order nwnber, i.e. an identifier for a specific order or product instance, and the Parf n u d e r for the pan defining the open structure. These dam will make up the unmbiguous identity of the order specific producr
- The pan number (part-no) of the part used to close each opening. In OUT data model we can regard the OD as a Pan (e.g. of the type referenced document), which is contained in a special Order Catalogue. In many cases it is known from the very beginning that some variants are in f q u e n t demand. These variants can then & d y during the development phase be documented as shown above, i.e. by rn Order number (which now rather should be regarded as a pan number (pan-no) for an unambiguously documented product), a part number for the open pmluct. and a list of part numbers to close the smcture. This way it is possible to camlogue and stock frequent variants, while the flexibility to manufacture a ccstomer specific variant is retained. The above discussion can very well be applied, not only for the complete producL but for any subassembly level as well. So far. we have only specified the pan number for the actual pan. It is simple enough also to specify the quantity of a certain pan in the Order Document. For more complex products like power transformers. cf [Agemati 91). it is convenient to allow the quantiry for a cenain pan to be zero, i.e. that pan should not be included in this specific pmduct. Some other atmbutes to parts. e.g. dimensions of raw material like plates and bars. could also be included in the Order Document. In case of complex products it might be required to create specific orderbound pans lists. instead of, or as a complement to the OD.
of the data model.
In passing we note that the rufes needed to close the open structure easily can be included in OUT data model as another specialization of the Pan entity. The open structure with these rules form an important part of the product template mentioned initially.
navigare, display. These are functions to display entities or (parts of) smctures, and to define a 'current position' in the structure.
3.3 Parallel Structures
- create, edit, delere enn'fy. These are the basic functions to manipulate the entities ~
If we thus were to provide a product with a wide range of options for the componects (i.e. leaf nodes of the structure), we would end up in a huge documentation problem. The number of p3RS lists needed would be in the magnitude of the product of the number of vanants for each component To create these parts lists would clearly be a tedious anderror prone task, and probably to a largt: extent meaningless, since a majority of h e documented variants most likely will never be produced. Just the amount of work needed 10 maintain this documentation would be prohibitively large.
andparre node. These are the functions to edit a structure, where one node (and all nodes betow it) may he cut from its current position and possibly pasted at another (also in another structure). These operations. innocent as they may seem, are in reality quite complex, depending on what is expected to happen with the nodes above the positions where the operations are performed. These nodes (i.e. parts) are of course modified, and if they have occurences in other s m c m s it may be necessary to create new parts on the above levels, to substitute the old ones. CUI
search. One of the key functions of a smcture system is to be able to search for pans fulfilling some criieria, both on attnbute values and on relationships. t.g. consists-of.
Above we showed that our data model (figure 6) allows the inclusion of different entities as specializations of for instance the part entity. This allows e.g. a production planner to add his own entities and atmbutes. This does. however, often not provide the necessary flexibility. since it does not allow the structure itself to be manipulated. It is a general requirement, at least for assembled products (and definitely for plants). to be able to view the product from different perspectives and represent each perspective in a separate struc~re.As-designed, e as-manufactued. as-tested. as-shipped. as-erected are examples of s m c ~ r types used in practice. Some (slightly fabricated) examples using the Grinder are shown in figures 7 and 8. Informally we can say that we rake our original structure apan until we get the building block we are interesid in and then we reassemble them in 3 new way.
167
thus crating a new smcmre The key observation to make here, is that these two s ~ c t u r e snot only contain the same pans. but the same occurences of rhesc pans. We call a set of swctures. which in this way contains the same occurentcs for parallel suuctures.
a node at an assembly level in one swcture may be placed as a leaf n d e in mother smcture. a node at an assembly level can be placed at an assembly level in another swcture if rhe ser uf all leaf nodes in rhe rwo srriLcnues are idenricul. This rule expresses the fact that it actually is the components that make up r product. not the order in which they are assembled. the thRe previous rules must apply to any two smctures in a structures.
set
of parallel
if one Occurence in the database repttsents more than one physical item (the quanti?, amibute has a value p t e r than one). then these items must be mated as a unit. each structure should be smcdy hierarchical. i.e. each node has exactly one parent node.
Tool 0011
Processor Box 0012
Pvallel souctures allow each Functional Unit within the company to represent the product in the smrurc(s) best suited for the application at hand: sales, design. producnor, planning etc. Another feature is that a modification in one smc:urc automatiwlly updates, not only h e current s a u c ~but , all other where the pan occurs. The dditions needed. for handling parallel smcmres. to the functions described earlier an straightforward. Of course, it must be possible to define the acrual s The system must also check swcmre and m select among the s w c ~ r e defined. that the above rules are fulfilled Finally. a system for handling parallel smcmres requires a rather sophisticated user interface.
Figure 7: Assembly structure of Processor
4. Summary
Leg 0015
In this paper we have presented 3 general TIS architecmre and discussed one of its major components. the Product-Smcmre System. in some detail. We have shown that a flexible and easily upgadable mhitectun is achievable if the basic Functional Units of the company and the interfaces between these units are identified. Funher we have discussed the impomnce of the product s ~ c t uand ~ , shown that a simple data model can be developed to cater for the specific needs of different Functional Units. thus providing the backbone to which all product related dam can be attached.
Conveyor 0008
Figure 8: Shipping srrucmrefor Grinder Parallel S ~ C N R San easily incorporated in our data model; figure 9 shows the new version. There are three major differences between this version and the previous one:
5. Acknowledgement The work here presented is pan of the EPDS project, funded by the Swedish National Board for Industrial and Technical Development (luZEK).
- a new entity Swcturc-type is included to keep track of the different srucmres. - the conristspf relationship is now ternary between Structure-type and Occurence. Note that each Occurence may be contained in more than one other Occurence, beloning to different suuctures.
-
a new entity. Assembled-part is needed. since an assembled pan very well may be represented by more than one swcture. i.e. more than one Pan.
part-occ
6. Rererences
[ABB 891
ARCADE Konsrrukr6rshandledning. Handbok ZOO0 1953-2. Asea Brown Boveri. VSsteriZs. 1989.
[Agerman 9 1J
E. Agerman: On rhe Design Process for Customized Producrs and Demands upon a Technical Information Sysrem. CIRP 41st General Assembly. Stanford, California. 1991.
[Aser 761
Beskrivning av ASEAs produktbehandlingssysrem for katalogfi6rdu och andra reperinva produkrer. Asea I KS. Visteras. 1976.
(Chen 761
P. Chen: Thc Enriry Relationship Model . Toward a Unified View of Daru, ACM Transactions on Database Systems, vol I. no I . 1976.
[Elmasri 891
R. Elmasri, S . B. Nsvathe: Fundomenials of Darabase Sysrems. The BenjamidCummings Publishing Company Inc., 1989.
[Hugoson 871
M. A. Hugoson: Sysremsrrukrurering, Programator, Gbteborg. 1987.
[Intergraph 901
I I PDM Reference Manual, Intergraph Corporation. Huntsville, Alabama. 1990.
consists of
Figure 9: Data modelforparallel prodtrcr srrucrtires The changes to the tern1 matrix for the ER-model in figure 9, relative to figui': 6. are:
[IVF 901
0blecr.s: Assembled Part [ a m l nQ. description) Structure-type ( s m .description)
[IS0 871
I S 0 9000-9001,Quality Standards, ISO. 1987.
[Lindkrg91]
L. Lindberg: On Tecnical Information Sysrems Archirecrure and Functional Requiremenrs, KTH. Stockholm. 1991, ISRN KMSDKTLA--91/03--SE.
[Sohlenius 761
G. Sohlenius et al.: Samordnad produkrframragning. IVF-resulwt 76604, 1976.
[Scmia 901
S. Sjiistrom: The modular system in truck manufacruring, The Saab-Scania Griffin 1990/91, Linkoping 1990.
Relationships: consists-of (occurence idl. occiireiice id2. struct id, itrm-llo) pan-doc (~D;u[no. DLR ne) There are some rules that must be obeyed when manipulating p?rallel strtlcttires: ~
~
there can be ar most one occurence of each parr occuence (Occurence) in one smcture (all Occurencesdoes thus not have to be used in every structure). a leaf node in one structure, may be placed suuture. i.c. also at an assembly level.
168
at
an a r b i u p position
in
another
1-A Raberg: Koppling CADCAM. databar, IVF PM 9005-14, Goteborg, 1990.
- The Backbone of CIM
Lars Lindberg, Professor Erik Agerman (2) Received on January 14,1992
In rhis paper we argue that the product s t r u c ~ r eshould be used as the backbone for the modelling and documentation of the product. Fiat a general architecture of a Technical Informadon System. T I S . based on Functional Sysrcms is presented. Then three major subsystems of the TIS are identified. and one of these, the F'roduct structure System is discussed in greater detail. The product structure is shown to be in a sense both complete and stable, thus providing a foundation for a m e CIM system. A simple, yet venariie, data model is presented, allowing variants and views of the product to be represented. Key words: Design, Data model, Product s n u c m
2. Information System Architecture 1. Introduction
The production process can be viewed as a flow of data. when the customer specification successively is aansformed into the manufacturing documentation. which in turn is used for the actual manufacturing of the product (figure I). This process generally consists of two different phases: a development phase and an order phase. (figure 2). cf [Sohlenius 76). The development phase produces as a main result a producr remplare. i.e. a generic documentation of the product. including a product structure, design rules, planning macros. parametric drawings etc to defme the family of products covend by the tempIate. During the order phase the product template is used with the specific order data to create a (possibly unique) instance of the product documentation. These primary or rechnicddarnflows are controlled by parallel flows to follow up costs. schedules. quality etc. Thee controlling flows will, however, not be further discussed in this paper. Here we will concentrate our discussion on the role of the product structure in this Jam flow. We will do so by fmt briefly discuss the major activities and typical daca volumes associated with these. Then we will give a general characterization of these data. and based on this suggest a general archirectum of a computer system to sbpport these activities. This architecture will as a major component have a subsystem to handle the product smcture. and this subsystem will be the main theme for the remainder of this paper.
CQT Customer Order
[-&qlcmfao n
Cust Doc Cornpl.
CQT
cost, Quality. Time Material
I
CQT I
I
Schedh& Product Manufacturina
---_ Figure I. Busic dataflow in a man@acricnng company Policies
Desrgn,Systematics
"he major activities within the primary data flow are related to the sales, design. planning and scheduling functions of the company. Some of these functions do often conrain major subactivices; the design function for instances may comprise technical calculations, layout design and detailed design, and the planning function may include process planning, operation planning and NCprogramming. Typical for the data tlow is that most activities are serially connected i.e. an activity takes its input from an 'upstream' activity and delivers its output to a 'downstream' activity. The actual activities urried out, and thus the amount of data handled, are of course highly dependent on the complexity of the product. if it is made to order or made to stock. if it is a standard product or if it is one of a kind etc. Nevertheless our investigations [Agerman 911 suggest that the output from ir.ictivity is roughly an order of magnitude larger than the input. A small number of let's say 20 input data from the customer can therefore eaS;!y generate 20.000 or more data to be tised in the manufacturing process. and this for one order only. 2.1 The Functional System Approach
It is well beyond the c m n t state of the art to maintain the relationships between the data mentined above (and this might not even be desirable). but the requirements from the secondary data tlow Le. the flow controlling cost. quality and time) enforces a structuring of the dau of the primary data flow. We suggest that the general architecture of this system is founded on a set of independent but cooperating subsystems. called Functional Systems Nugoson 871. Further we suggest that each of these Functional Systems share a common architccrure. with three major subsystems: a Technical Adminismtive System. a Product Smcturc System and a Geometry System. W i will call this system a Technical Information System. TIS. The main rationale behind the Fuiictional System approach is the observation that each activity in the data flow outlined above is carried out by an autonomous unit within the company, by Hugoson called Functional Unit. Each of these units have: a chaner (i.e a well defined task to carry out), responribiliiy to carry this task out, and the necessary resources to do so. These resources should also include any computer support needed for the task A key thing to note is that the Functional Units are reasonably stable w e r time. compared with e.g. the actual organization. Each unit should therefon: be supported by a system of its own, a Functional System. FS. The different functions, and thus FSs, must of course communicate data between each other. We will call these data documenrs. in analogy with a manual system. Genenlly these documents share some fundamentalproperties:
-
a simple structure (cf below). stability, i.e. the structure and contents do not vary over time. - have low volume. . are not time critical. In a manufacturing environment all documents share a common overall suucture. Each document has a:
-
primutypun. the 'title block' of the document.
subjecrpan. the actual content of the document. revisionpar!. the history of the document.
The primary pan has nttributes like: idenriry (i.e. a unique identifier of the document). owner (i.e. the functional unit responsible for the document). ~rarus (i.e. 'approved', 'under revision', etc). rype ( i t . a specificationof the content of the document). etc. The attributes of h e subject part is dependent on the application and type of document. Order
The revision p m has at !east a revision index to uniquley identify each revision of the document. It should be noted that an FS uses other ddta than documents recieved from other FSs. These internal data may often be documents in their own right, e.g. the product template used in the order process.
Figure 2: Developmenr and order phuses of manyucruriny process
Our general system architecture can thus be summarized in the following picture (figure 3):
Annals of the CIRP Vol. 41/1/1992
165
'8
production engineer databases for e.g. tools. fixtures and machines, and a sales engineer needs a module to calculate the product cost for tendering purposes. etc. We do. however. view these systems as auxiliary systems to the general core of the ITS.comprising the above three subsystems.
3. Product Structure Handling The Product Structure is a model of the product describing the amibutes of the constituent parts and their relationships. Structures of products have been represented for a long time in MRP systems. These systems are, however, specifically railored for planning and scheduling purposes and do nor provide a general snucture handling capability. Now we are beginning to sec commercial systems with some of this functionality, e.g. PDM from Intergraph [Intergraph 901.Dese systems do, however, not yer show aiy greater sophistication.
I
It is of comse also an i m p o m t question to ask whether we need a separate Smctun system at all? Can't the Geometry system be used to handle the structure as well? There are several reasons to keep these systems apart:
!
-
the large volumes of attribute data needed for a complex product calls for a specifically railoied representation.
I: should be suessed that the FSs are not inregrated in the xnre :hat they do not
-
use the same physical data. and they do not generally operate on a common data structure. However, we do believe that the Functional System apprnach has some distinctive benefits comparcd to more 'integrated' approaches. These knefits can be expressed as independence i n terms of:
the connections to systems for monitoring and controlling cost quality and time require that the product structure isexplicidy available.
-
tht product smcture is reasonably stable for modifications to the product. which means that similar structures can be used for different insunces of a product family.
-
the product structure is complete in he sense that all pans that m needed to manufacture the product are included.
-
the structure is flexible in that new types of data can easily be included, as well as new views of the product, cf below.
-
the geometry model is representing continuous aspects of the product (shape and dimension), while the suuctun model is discrete.
Figure 3. Funcrionul Sysrems communicating wirh hiocurnenrr
- functions. i.e. a modification (e.g. of data structures or functionality) of one FS does not affect any other FS.
- rechnicafsolurions, i.e. a new FS can be included at any time. and any two FSs may use different basic hard- and software.
- rime. i.e. an FS is not dependent on any other FSs being run concurrently. To summanze: the FS approach gives a stable. incrementally upgradable and flexible system. 2.2 TIS Architecture We will use the operarional definition of a Technical Information Svstem, TIS. as being the computer system used in the activities of the primary data how. The TIS will thus include the systems used to produce and vlllidate the data needed to manufacture the product. The systems needed to monitor this process. in terms of cost, quality and time, arc nor included. The TIS for a whole company consists of many Functional Systems. However, we suggest that they a11 have a common basic architecture. To arrive at the major components, or subsystems, of a TIS,we note that the data handled by the TIS are always directly related to the product and its documentarion.Three major categories of data can be distinguished:
The discussion here on the functionality needed and documentation principles used are largely taken from the experiences at Asea [Asea 761. [ABB 891. The simple product example is taken from [WF 901.We will s m off this presentation with some general definitions and concepts, and then move on to two important issues: how to represent a large number of variants of one product. 'open snucms'. and how to represent different views of the same pmduct, 'parallel suuctuzes'.
- mera-dara. i.e. 'data about data', or basically the data contained in the primary pan of the documents, cf above.
3.1 Structure Handling: General Concepts
- data describing the shape of the pans making up the product and the relarive posirions of these pans. or geometry for short. - data describing the arrribures of the pans and the pan-of relation to other pans. or (producr)srrucfurefor short.
A designer typically represents geomerry in 3D models and drawings. and
structure in pans lists. For a production engineer the interesting geometry may be the NC tool paths and the surfaces used to generate them. and the suucture the lists of operations and material for each part. For an engineer carrying out calculations the geometry may be represented as a finite element mesh and the attributes being material data and boundary conditions. The TIS will correspondingly consist of the three subsystems: the Technical Adminisative System (or TA-system), the Geometry System and the Product Srructure System (figure 4). The TA- sysem will have three major functions: to serve as a 'posunaster', i.e. handle the convnunicurion with other FSs, to handle rhe docwnenr odimisrration, i.e. the approval cycle prescribed e.g. by the I S 0 9000 family of standards [IS0 871, and to connect the Geometry and Suucturc subsystems. The TA-system will not be funher discussed here. for a further description see &idberg 911. Neither will the Geometry System be discussed here; the literature on geometric modelling and CAD-systems IS prolific. The Product Structure System will be the main theme for the rest of this paper.
-I
When manufacturing a product. raw material is machind to produce compoi~ents which are assembled (with other. purchased, components) to create different semifinished products and finally the complete product. as the simple example in figure 5 shows. Each step on the path from raw material to finished pmduct is called a refining level. The documenration of the product is generally tied to the refining levels, by one ponr list and possibly one derail or assembly drawing for each level. This smcturc is strictly hierarchical. Like aU other structures we are going to discuss here. We will refer to a node in the structure as a purr, irresFcctiveof where in the structure we find it. A component is a leaf node in the structure. We will sometimes refer to the root node as theproducritself.
%
Grinder 0021
Conveyor 0008 A e e d e r 0001
Technical Administrative
System
Structure System
s i
GearBox 0018 Tool 0011
b
Figure 5 Simple example of product sfruccure
i
To npnsent this and similar product smctures. we suggest the following data model, figure 6.
System Figure 4 TlS arclurecrure It should be noted that the three wbsystems above of couise not aie the oiilv
modules of a TIS. A n analyst w ~ l lobviously need e g
166
Below we will present some basic data models representing the Product Structure. These data models will be given as Entity-Relationship (ER) models [Chen 761. using the notation of 'Enhanced ER' in Elmasri 891.
J
FE package,
documenr generarion. As mentioned above the norm31 way of documenting a product smcture is through pans lists. These lists must be possible to generate from the structure system. 3.2 The Configuration Problem: Open Structures
I
In this section we will discuss some of the problems related to srmcture handling and variant design. A problem we encounter when we create variants of a product. is the proliferation of similar parts. If we e.g. were to design a variant of the Grinder (figure 5). only by changing the Tool (0011). we would have to create new parts on all superior levels, i.e. Agitator, Drive Unit, Rocessor and Gnnder. to maintain the uniqueness of the pan numbers. Each of these new pans should be documented by a pans !is.
COnSISiS-Of
jRefDacumentl Figure 6: Dara model;or Product Structures The term matrix for this model is ( w i t h the number of attributes kept minimum):
10 :I
Ohjeccs: Physical Part (oan,descnption, geomeny-pointer) Non Geom Pan (Dan,description) description, doc-type) Ref Document -, descnption, mfg-address) Operation Parameter !oariJ-, descripnon, default-valuej Occurence fgccurcnce id, quanrity) Catalogue karaloeue id, descnption. type)
C u ,
Relanonships: part-occ @an no. occurence id) consists-of (occurence idl. occurence id?. item-no) catalogue-pan
(w)
The key elements of this model 321: the Pan and Occurence entities. These entities represents the clarses of pans end their specific occurences respecnvely. Tliis splii is necessq to represent pans occurring at several places in one stnictiitr, like the Scnw W20. i n our example. The dcrual structure IS represented by the simple recursive relationship consists-of
In h e darn model the Part entity has been specialized into several different types of 'pxts' to illusrate how easy the data model can be augmented The following list of specializations is by no means exhaustive:
-
physical pans. with a geometric representation. All parts shown in figure 5 belong to this category.
-
physical pans without a geomemc representation. Paint and glue are typical examples here, but minor standard parts like screws may belong to this category.
~
-
referenced documents, most importantly the drawing, but also Technical Rovisions. Testing Insmctions. Quality Conuol Procedures etc. manufacturing operations; the process plan for a part can be regarded as a subsnucture of the p a n
- pmacccrs, used e.g. to generate a drawing or process plan for a paramemc Pan. Some of these specializationsof the Pan entity may also require a specializationof the corresponding Occurence entity. This specialization is suggested by the das!ied lines of figure 6. The Catalogue entity has been included to provide a simple way of finding the root nodes of a snucture. As for the Occucence entity specializations of the Catalogue could often be motivated. Actual products could be stored in one catalogue. standard pans in another, operations in a third etc. Above we have given a reasonably detailed data model of a structure handling
system. Some of the basic user functions needed are listed below. We want to s u e s that several additional functions may be desirablc, and that the question of user interface is quite complex and well beyond the scope of this paper.
-
~
One solution to this problem. well-known from many application areas as a conjigwarion problem, which successfully has been employed by Asea [As- 761 for many years (a similar approach is taken by Scania for mcks [Scania 901). is built on two observations:
- the structure is identical for all variants of the product.
-
for every (manufactured) variant it is only n e c e s s q to save the data needed to unambiguously recreate the manufacturingdata.
These observations yield a solution where a generic variant of the product is documented, just like a unique product above. including pans, components etc. However. for each position in the structure where a variant is possible. we simply specify that the acmal variant (i.e. pan number) will be specified in a separate document. the Order Document, OD. In the generic structure we specify this by an additional attribute to the corresponding Pan entity. This means that our product suuctm is not completely specified. We call this tyrx of s r m c ~ r open e and consequentIy the not completely specified nodes in the smcture openings. We call the process to unambiguously specify the openingsclosing the smcture. The number of documents needed to specify the product with its variants is in the magnitude of the sum of the variants for each component. In addition to this an OD fot every order is needed. The Order Document should contain the necessary data to unambiguously specify a distinct vuiant. It must thus contain: - An Order nwnber, i.e. an identifier for a specific order or product instance, and the Parf n u d e r for the pan defining the open structure. These dam will make up the unmbiguous identity of the order specific producr
- The pan number (part-no) of the part used to close each opening. In OUT data model we can regard the OD as a Pan (e.g. of the type referenced document), which is contained in a special Order Catalogue. In many cases it is known from the very beginning that some variants are in f q u e n t demand. These variants can then & d y during the development phase be documented as shown above, i.e. by rn Order number (which now rather should be regarded as a pan number (pan-no) for an unambiguously documented product), a part number for the open pmluct. and a list of part numbers to close the smcture. This way it is possible to camlogue and stock frequent variants, while the flexibility to manufacture a ccstomer specific variant is retained. The above discussion can very well be applied, not only for the complete producL but for any subassembly level as well. So far. we have only specified the pan number for the actual pan. It is simple enough also to specify the quantity of a certain pan in the Order Document. For more complex products like power transformers. cf [Agemati 91). it is convenient to allow the quantiry for a cenain pan to be zero, i.e. that pan should not be included in this specific pmduct. Some other atmbutes to parts. e.g. dimensions of raw material like plates and bars. could also be included in the Order Document. In case of complex products it might be required to create specific orderbound pans lists. instead of, or as a complement to the OD.
of the data model.
In passing we note that the rufes needed to close the open structure easily can be included in OUT data model as another specialization of the Pan entity. The open structure with these rules form an important part of the product template mentioned initially.
navigare, display. These are functions to display entities or (parts of) smctures, and to define a 'current position' in the structure.
3.3 Parallel Structures
- create, edit, delere enn'fy. These are the basic functions to manipulate the entities ~
If we thus were to provide a product with a wide range of options for the componects (i.e. leaf nodes of the structure), we would end up in a huge documentation problem. The number of p3RS lists needed would be in the magnitude of the product of the number of vanants for each component To create these parts lists would clearly be a tedious anderror prone task, and probably to a largt: extent meaningless, since a majority of h e documented variants most likely will never be produced. Just the amount of work needed 10 maintain this documentation would be prohibitively large.
andparre node. These are the functions to edit a structure, where one node (and all nodes betow it) may he cut from its current position and possibly pasted at another (also in another structure). These operations. innocent as they may seem, are in reality quite complex, depending on what is expected to happen with the nodes above the positions where the operations are performed. These nodes (i.e. parts) are of course modified, and if they have occurences in other s m c m s it may be necessary to create new parts on the above levels, to substitute the old ones. CUI
search. One of the key functions of a smcture system is to be able to search for pans fulfilling some criieria, both on attnbute values and on relationships. t.g. consists-of.
Above we showed that our data model (figure 6) allows the inclusion of different entities as specializations of for instance the part entity. This allows e.g. a production planner to add his own entities and atmbutes. This does. however, often not provide the necessary flexibility. since it does not allow the structure itself to be manipulated. It is a general requirement, at least for assembled products (and definitely for plants). to be able to view the product from different perspectives and represent each perspective in a separate struc~re.As-designed, e as-manufactued. as-tested. as-shipped. as-erected are examples of s m c ~ r types used in practice. Some (slightly fabricated) examples using the Grinder are shown in figures 7 and 8. Informally we can say that we rake our original structure apan until we get the building block we are interesid in and then we reassemble them in 3 new way.
167
thus crating a new smcmre The key observation to make here, is that these two s ~ c t u r e snot only contain the same pans. but the same occurences of rhesc pans. We call a set of swctures. which in this way contains the same occurentcs for parallel suuctures.
a node at an assembly level in one swcture may be placed as a leaf n d e in mother smcture. a node at an assembly level can be placed at an assembly level in another swcture if rhe ser uf all leaf nodes in rhe rwo srriLcnues are idenricul. This rule expresses the fact that it actually is the components that make up r product. not the order in which they are assembled. the thRe previous rules must apply to any two smctures in a structures.
set
of parallel
if one Occurence in the database repttsents more than one physical item (the quanti?, amibute has a value p t e r than one). then these items must be mated as a unit. each structure should be smcdy hierarchical. i.e. each node has exactly one parent node.
Tool 0011
Processor Box 0012
Pvallel souctures allow each Functional Unit within the company to represent the product in the smrurc(s) best suited for the application at hand: sales, design. producnor, planning etc. Another feature is that a modification in one smc:urc automatiwlly updates, not only h e current s a u c ~but , all other where the pan occurs. The dditions needed. for handling parallel smcmres. to the functions described earlier an straightforward. Of course, it must be possible to define the acrual s The system must also check swcmre and m select among the s w c ~ r e defined. that the above rules are fulfilled Finally. a system for handling parallel smcmres requires a rather sophisticated user interface.
Figure 7: Assembly structure of Processor
4. Summary
Leg 0015
In this paper we have presented 3 general TIS architecmre and discussed one of its major components. the Product-Smcmre System. in some detail. We have shown that a flexible and easily upgadable mhitectun is achievable if the basic Functional Units of the company and the interfaces between these units are identified. Funher we have discussed the impomnce of the product s ~ c t uand ~ , shown that a simple data model can be developed to cater for the specific needs of different Functional Units. thus providing the backbone to which all product related dam can be attached.
Conveyor 0008
Figure 8: Shipping srrucmrefor Grinder Parallel S ~ C N R San easily incorporated in our data model; figure 9 shows the new version. There are three major differences between this version and the previous one:
5. Acknowledgement The work here presented is pan of the EPDS project, funded by the Swedish National Board for Industrial and Technical Development (luZEK).
- a new entity Swcturc-type is included to keep track of the different srucmres. - the conristspf relationship is now ternary between Structure-type and Occurence. Note that each Occurence may be contained in more than one other Occurence, beloning to different suuctures.
-
a new entity. Assembled-part is needed. since an assembled pan very well may be represented by more than one swcture. i.e. more than one Pan.
part-occ
6. Rererences
[ABB 891
ARCADE Konsrrukr6rshandledning. Handbok ZOO0 1953-2. Asea Brown Boveri. VSsteriZs. 1989.
[Agerman 9 1J
E. Agerman: On rhe Design Process for Customized Producrs and Demands upon a Technical Information Sysrem. CIRP 41st General Assembly. Stanford, California. 1991.
[Aser 761
Beskrivning av ASEAs produktbehandlingssysrem for katalogfi6rdu och andra reperinva produkrer. Asea I KS. Visteras. 1976.
(Chen 761
P. Chen: Thc Enriry Relationship Model . Toward a Unified View of Daru, ACM Transactions on Database Systems, vol I. no I . 1976.
[Elmasri 891
R. Elmasri, S . B. Nsvathe: Fundomenials of Darabase Sysrems. The BenjamidCummings Publishing Company Inc., 1989.
[Hugoson 871
M. A. Hugoson: Sysremsrrukrurering, Programator, Gbteborg. 1987.
[Intergraph 901
I I PDM Reference Manual, Intergraph Corporation. Huntsville, Alabama. 1990.
consists of
Figure 9: Data modelforparallel prodtrcr srrucrtires The changes to the tern1 matrix for the ER-model in figure 9, relative to figui': 6. are:
[IVF 901
0blecr.s: Assembled Part [ a m l nQ. description) Structure-type ( s m .description)
[IS0 871
I S 0 9000-9001,Quality Standards, ISO. 1987.
[Lindkrg91]
L. Lindberg: On Tecnical Information Sysrems Archirecrure and Functional Requiremenrs, KTH. Stockholm. 1991, ISRN KMSDKTLA--91/03--SE.
[Sohlenius 761
G. Sohlenius et al.: Samordnad produkrframragning. IVF-resulwt 76604, 1976.
[Scmia 901
S. Sjiistrom: The modular system in truck manufacruring, The Saab-Scania Griffin 1990/91, Linkoping 1990.
Relationships: consists-of (occurence idl. occiireiice id2. struct id, itrm-llo) pan-doc (~D;u[no. DLR ne) There are some rules that must be obeyed when manipulating p?rallel strtlcttires: ~
~
there can be ar most one occurence of each parr occuence (Occurence) in one smcture (all Occurencesdoes thus not have to be used in every structure). a leaf node in one structure, may be placed suuture. i.c. also at an assembly level.
168
at
an a r b i u p position
in
another
1-A Raberg: Koppling CADCAM. databar, IVF PM 9005-14, Goteborg, 1990.