Breunese, Arno P.J.

de Vries, Theo J.A.

English

In this paper, we analyse the problems associated with product models in computer–based support systems for conceptual design of mechatronic systems. Basically, current product models fail in the sense that they seriously limit the designer in possibilities for making and modifying a description of the system under design. Based on the analysis, we propose a product model structure that is more suitable in this respect

University of Twente Research Information

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGNICED ’95PRAHA, AUGUST 22–24, 19951430STRUCTURING PRODUCT MODELS TO FACILITATE DESIGN MANIPULATIONSTheo J.A. de Vries and Arno P.J. BreuneseABSTRACTIn this paper, we analyse the problems associated with product models in computer–basedsupport systems for conceptual design of mechatronic systems. Basically, current productmodels fail in the sense that they seriously limit the designer in possibilities for making andmodifying a description of the system under design. Based on the analysis, we propose aproduct model structure that is more suitable in this respect.1. INTRODUCTIONWe consider here the design of mechatronic systems. Examples of such systems are assemblymachines, automatic guided vehicles, consumer products like CD–players and video cameras,etc. Buur [1] proposed a concise definition of mechatronics: it is ‘a technology whichcombines mechanics with electronics and information technology to form both functionalinteraction and spatial integration in components, modules, products and systems’. Benefitsclaimed to result from the use of a mechatronic design approach are mainly the increase offunctionality (more intelligence and flexibility), of performance and of reliability withoutincreasing cost. The mechatronic approach specifically influences the conceptual design task,as it is during this task that most of the decisions are taken with respect to functionalinteraction and spatial integration of the system under design. Hence, if we are to enhancemechatronic design, we should offer sophisticated support for conceptual design of multi–disciplinary systems.Engineering design in general, and thus also conceptual design of mechatronic systems,essentially addresses two issues:1. Determine the requirements for the product to be designed.2. Formulate a model (the proposed design solution) that satisfies these requirements andthat can be realised.1431As conceptual design is an ill–structured process, these issues are not addressed sequentially,but rather iteratively. That is, conceptual design is a process of continually refining theproposed design solution on the basis of an evolving set of requirements. Consequently, thelist of requirements will (partly) be dependent of the proposed design solution and vice versa[2]. Therefore, it is fruitful to incorporate both requirements and proposed design solutionintegrally in one design product model.In many computer–based design systems, product models consist of either a set of constraints(the requirements-oriented form) or an assembly of components or features (the solution-oriented form). To properly capture dependencies of requirements and proposed solution, anintegration of both forms is required. Recently, several propositions have been made to obtainthis [3]. Characteristic for such product models is that they are ‘knowledgeable’; quite somedata about properties of the proposed design solution and relationships between parts of it arecontained a product model. Therefore, a library of reusable product models is indispensable incomputer–based support systems featuring integrated product models [4].With respect to integrated, knowledgeable product models for conceptual design ofmechatronic systems, we have identified the following problems:1. Proper integration of requirements and proposed solutions in a product model involvingassemblies of components is difficult. This is worked out in section 2, where a productmodel structure is proposed that solves this problem.2. Gradual refinement of the proposed solution is generally not supported; fully specifiedassemblies or components need to be selected during synthesis and structured search foralternatives is hard. In section 3, this aspect is analysed and an addition to the aboveproposition is given to deal with this.3. Libraries of product models are unstructured and, when of adequate size, hard tomaintain. This obstructs reuse of design knowledge. Section 4 addresses this issue, and itis shown how this can be improved by further extending the proposed product modelstructure.Conclusions are listed in section 5.2. INTEGRATING REQUIREMENTS AND PROPOSED SOLUTIONSCADET [4, 5] is a system supporting embodiment design in which requirements andproposed solution are effectively combined in a product model. In this system, the proposedsolution is described as a set of interconnected components (tangible parts) and interfaces(interactions between components). Both components and interfaces are characterised byparameters, specifying for example material and material properties, geometry and relativepositioning. Requirements are incorporated in the product model as inequality constraintsupon (combinations of) parameters of components and interfaces. This product modelstructure is effective, because requirements and proposed solution are clearly distinguishable,and at the same time their dependencies are explicit and they can be treated integrally asconstraints to be satisfied in the remainder of the design process.However, to apply the same ideas in our situation, a few difficulties with respect to theproduct model structure in CADET must be resolved:14321. It is tailored towards mechanical design, in the sense that interconnections imply forceexchange and relative positions. In mechatronics, also electric and electro–mechanical(and other) interconnections are present. Hence, this requires generalisation of the productmodel structure.2. It is focused on description of static behaviour, with extensions foreseen to includekinematics. For mechatronic design, however, dynamic behaviour is the major concern.3. As reported so far [5], it is not yet fit for describing an assembly of components andinterfaces as one ‘composite subsystem’. Mechatronic systems typically involve a largenumber of components. Composite subsystems are indispensable then, as they introduce a‘part–of hierarchy’ in the product model, thus enabling the designer to keep track of thesystem under design. This principle is intuitively applied by many designers to keep thedesign problem and its proposed solution tractable.In order to structure the model of the interaction between systems or processes, the interfacebetween components is specified in terms of ports and parameters. A port represents avariable (or set of variables) that links the ‘outer world’ (the related subsystems) and the‘inner world’ (the detailed description of the behaviour) of the subsystem. A parameterrepresents a characteristic property that is available to the outer world for use in requirements,and to the inner world for use in the composition of parameters of lower level subsystems.The use of ports allows for the description of interconnections beyond the mechanicaldomain. It also provides an extension towards dynamic models. The values of the portvariables can vary over time. By specifying constitutive equations that define relationsbetween the port variables and involve the parameters of the subsystem, the dynamicbehaviour of a system can be expressed.Using a uniform interface in terms of ports and parameters, it becomes possible to treat acomposite subsystem in the same way as a component. The interface of a compositesubsystem consists of those ports and parameters of all constituent parts that are not usedexclusively for internal connections. This technique is not limited to a single level: it ispossible to have composites within composites.The propositions made above lead to a powerful product model structure in the form ofhierarchical networks. This structure indeed supports mechatronic design by addressing therelevant issues. The generic structure is depicted in figure 1a. A concrete example of a simpleelectro–mechanical system (figure 1b) shows how the structure is used in practice.3. REFINABLE PRODUCT MODELSA difficulty with the product model structure proposed in the previous section, and in fact ofmost product models in design support systems, is that when incorporating a subsystem in thedesign, the design freedom is limited to parameter modifications; structural modifications arenot possible. That is, we have to select a full model for a subsystem as soon as we want toinclude it in our design. For example, if we want to describe the outline of the simple electro–mechanical system, we have to be explicit about the composition of the motor or itsequations. In conceptual design, however, we typically do not want to be bothered by suchdetails rightaway. When including a motor in a design, we merely mean to say that we need atransducer from the electric to the rotation-mechanical domain; in due time, we will refine themodel and be explicit about the exact kind of motor, and thus its internal structure.1433a bFigure 1 Product model structure in the form of hierarchical networksa) General structureb) Example of a simple electro–mechanical systemThe proposed product model structure can be extended to support this in the following way.We should distinguish essential characteristics and incidental characteristics in a subsystemdescription. Essential characteristics are those characteristics on basis of which a subsystemis classified (that ‘make it what it is’), and incidental characteristics are the remaining data.In other words, we modularise a subsystem description into a type (defining the essential part)and a specification (defining the incidental part). For an electric motor, the electric port,where power enters the subsystem, the rotation-mechanical port, where power flows out ofthe system, and the transduction ratio (the motor constant) are essential characteristics; theparts of which it its composed or the equations that describe its behaviour may take varyingforms, and thus are incidental characteristics. This is mostly true: ports of a subsystem andsome of its parameters are essential attributes, and hence should be defined in the type; itsstructure (the ‘inner world’) and remaining parameters are incidental characteristics, andhence part of the specification. As incidental characteristics may take varying forms, we canthink of multiple specifications for one type; i.e. types become polymorphic. Thispolymorphism can be exploited in two important ways [6]: to describe a subsystem in varyingresolution or in alternative forms. Figure 2 depicts the adapted structure for the productmodel.Note that a type in fact determines a set of equivalent artefacts [7], and that a specificationmay be either a set of equations (i.e. a particular parametrisation) or a structure of lower levelsubsystem types (i.e. a particular combination of smaller subsets of artefacts). That is, onlythe combination of a type and an elementary specification make up a fully specifiedsubmodel. The combination of a type and a composite specification just determine one levelin the model hierarchy; lower level layers are left undetermined.1434Figure 2: Modularisation of a subsystem description into a type and a specification4. MODEL LIBRARIESUse of integrated product models of the kind discussed here is only effective if the building ofthese models does not require the designer to perform many extra actions that he wouldotherwise not do. In effect this implies that models should preferably be built duringconceptual design as if the designer was making a sketch or scheme. This is feasible byproviding to the designer a (large) library of connectable ‘icons’, where each icon represents amodel of a subsystems.There is at least one condition for this approach to work: the library must cover modelsranging from quite abstract, functional subsystems (‘a transducer’) to commercially available,concrete and completely known subsystems (‘a permanent magnet DC servo motor of vendorA, type X’). In terms of the previous sections, an abstract subsystem is described by asubsystem type with unknown parameters and a default or no specification, and acommercially available, concrete subsystem is described by a type with particular parametervalues and with a particular specification, of which the types have particular parameter valuesand a particular specification, etc. In other words, an abstract subsystem is a model hierarchyof minimum depth (= 1), with all parameters unknown, and a concrete subsystem is a fullydetermined model hierarchy, where all parameters have an exact value.To deal with this, we introduce the concept of a realisation. A realisation is a description of apiece of model hierarchy and of the associated parameters. Therewith, it is the properinstrument to store in a library anything between an abstract subsystem and a commerciallyavailable, completely known subsystem.In order to obtain an extendible library that can be well maintained and contains reusabledesign knowledge, these models must not only be available, but also be systematised in aknowledge structure tailored to support design manipulations. The product model structureproposed so far is well suited for this for the following reasons:14351. Subsystem types can be meaningfully organised in a kind–of hierarchy using subtyping.Each type is specified as a special kind of its supertype, inheriting all the essentialproperties of the supertype and adding additional properties. The importance of this is thatby changing the type of a subsystem to the supertype (generalisation) or to one of thesubtypes (specialisation), it can be made to describe a more or a less abstract subsystem[6]. Also, the possibility for incremental definition of the type properties leads to acoherent, practical library structure that is well understandable, extendible andmaintainable.2. Realisations can be categorised under the type that is at the top of their hierarchy. Withinone type, realisations can be listed according to the amount of detail incorporated, andrealisations (partly) incorporating the same lower level subsystems and/or parameters canbe grouped. In this way, related variants of subsystem types are readily available.The basis for the product model structure as proposed here is the concept of polymorphicmodelling [8]: modularise a subsystem into a type and a specification, and relate types in akind–of hierarchy. This proposition has been implemented in a system for conceptual designof mechatronic systems, called MAX [9, 10]. Space limitations prevent us from discussing thefunctionality of this system; interested readers are encouraged to refer to the references or tocontact the authors. Also the SCHEMEBUILDER system [11] features a product modelcomparable to the one proposed here.5. CONCLUSIONSProper integration of requirements and proposed solution in a product model can be obtainedif each subsystem therein is characterised by two kinds of information: its ports and itsparameters. A port is a set of variables that is available to the ‘outer world’ of a subsystem tomake connections to, and that is available to the ‘inner world’ of a subsystem for expressionof its behaviour. A parameter is a characteristic property of the subsystem that is available tothe outer world to be used in e.g. requirements, and that is available to the inner world as e.g.the composition of parameters of lower level subsystems or equations. In this way, the systemunder design is modelled in the form of a hierarchy of networks.In conceptual design, it must be possible to include in the proposed design solution asubsystem that is only partly characterised. To support this, we propose to modularise asubsystem description into a type, which defines the essential characteristics that hold for allrealisations of the subsystem, and a specification, which defines the remaining, incidentalcharacteristics that may take varying forms. This ‘polymorphism’ can be exploited in twoimportant ways: to describe a subsystem with varying detail or in an alternative form.In order to have an extendible subsystem library that can be well maintained and containsreusable design knowledge, the models in it must range from abstract and generic to concreteand fully parametrised. Also, they must be systematised in a knowledge structure tailored tosupport design manipulations. This can be obtained by organising subsystem types in a kind–of hierarchy, and by providing for each subsystem type an appropriate set of realisations,which describe a less or more complete subsystem hierarchy. Such a structure enables guidedmodification of a subsystem in a proposed design solution to less or more abstract versions.1436REFERENCES[1] Buur, J. (1990), A theoretical approach to mechatronics design, PhD thesis, Institutefor Engineering Design, Technical University of Denmark, Lyngby, Denmark[2] Hoover, S.P., J.R. Rinderle and S. Finger (1991), Models and abstractions in design,Proc. of ICED '91 (Zurich, Switzerland), WDK-20, Heurista, Zurich, Switzerland[3] Roozenburg, N.F.M. (1993), Proceedings of the ICED ’93 (The Hague, Netherlands),WDK-22, Heurista, Zurich, Switzerland[4] Thornton, A.C. and A. Johnson (1993), Constraint specification and Satisfaction inEmbodiment Design, in [3], 1319–1326[5] Johnson, A.L., A.C. Thornton and C.F. Fong (1993), Modelling functionality inCAD: implications for product representation, in [3], 1610–1617[6] Vries, T.J.A. de, J. van Amerongen, and P.C. Breedveld (1993), A model of thedesign process for development of CAE systems,  in [3], 1409–1417[7] Ward, A.C. (1989), A theory of quantitative inference for artifact sets, applied to amechanical design compiler, PhD thesis, Artificial Intelligence Laboratory, MIT,Cambridge, MA[8] Vries, T.J.A. de, P.C. Breedveld and P. Meindertsma (1993), Polymorphic modellingof engineering systems, Proc. Int. Conf. Bond Graph Modeling and Simulation ’93, SanDiego, CA, 17–20 January 1993, 17–22[9] Vries, T.J.A. de (1994), Conceptual design of controlled electro–mechanical systems,PhD thesis, University of Twente, Enschede, Netherlands[10] Breunese, A.P.J., T.J.A. de Vries, J. van Amerongen and P.C. Breedveld (1995),MAXimizing impact of automation on modeling and design, internal report no. 010R95,Control Laboratory, University of Twente, Enschede, Netherlands; submitted to J.Dynamic Systems, Measurement and Control[11] Bracewell, R.H., D.A. Bradley, R.V. Chaplin, P.M. Langdon and J.E.E. Sharpe(1993), Schemebuilder, a design aid for the conceptual stages of product design, in [3],1311–1318CORRESPONDENCETheo J.A. de Vries Phone: +31 53 892817EL-BSC-RT Fax: +31 53 340045Mechatronics Research Centre Twente E–mail:  T.J.A.deVries@el.utwente.nlUniversity of TwenteP.O.Box 2177500 AE EnschedeNetherlandsView publication stats

Structuring Product Models to Facilitate Design Manipulations

https://ris.utwente.nl/ws/files/169838325/063_R95.pdf

Structuring Product Models to Facilitate Design Manipulations

Abstract

Similar works

Full text

Available Versions

University of Twente Research Information