COINS Library 1.1
A COINS Library is a universal designation for a model that complies with the COINS standard but that can be utilized beyond a specific project scope. Typical applications are:
- Catalogue part library
A set of catalogue part descriptions that can be reused in various projects. - Property types set
Set of standard property types. - Templates
Global information structure of a specific product type, e.g. bridge template, highway template, office template, etc. - All COINS models that are imported in a sub-model hierarchy
especially practical in large project (various sections of a railway project that are tendered to various contractors) or to organize variant elaborated designs.
The remainder of this article will focus on the various ways to set up a catalogue part library.
Inhoud |
Catalogue Part Library
A catalogue part library contains a set of catalogue part objects which collectively may structure a type hierarchy and/or decomposition structure.
The catalogue part object class has a rich set of relation types that is able to support complex hierarchical information structures. The next paragraphs will give a walk through of the various modelling constructs.
Properties
Specifying properties is probably the most basic modelling construct for catalogue part objects.
The CBIM schema distinguishes Property Types and Property Values, where a Property Value always references a Property Type.
Take for example a beam catalogue part with dimensional properties length, width and height.
Amount property type
A special kind of property is the amount property. An amount object keeps the amount of a certain catalogue part with regard to an assembly object. Such an assembly object could be a physical object node in the object tree. To compile a bill of quantities most catalogue parts will be counted piecewise. For this reason the CataloguePart class is a subclass of the PropertyType class. The amount property is in that case identical to the catalogue part itself. But in other cases it could be that the quantity of a catalogue part is measured by its length or area or volume or mass, etc. One of the properties of the catalogue part is then selected as the amount property.
Complex property
Simple properties are single valued. A complex property however may handle a set of properties.
Complex property values are part of the reference framework Functional Specifying.
A typical example of a complex property is material. A specific material will contain a set of standard properties (e.g. density, melting point) which are universal for all materials and a set of specific properties that only occur for a certain group of materials (e.g. yield strength).
Complex property values are stored in catalogue part objects and will generally form a family using the supertype construct.
A property type definition can be defined complex by setting its value domain index to complex value and by selecting a so called template. The template will form the root of all selectable values of this property type.
If the root of the family tree (here Material) is selected as template all descendant complex values in the family tree are qualified for value selection. If for example Steel is assigned as template only descendant values of Steel will appear in the selection box of selectable values.
Supertype hierarchy
A Catalogue Part may reference another Catalogue Part as its supertype. This modelling construct introduces (single) inheritance into a catalogue part library. The supertype semantics allow both property type as well as property value inheritance.
Figure 6 and 7 show an example where a catalogue part Concrete Beam inherits from a catalogue part Beam both property types and associated property values. Because the inherited property values cannot be overwritten the Navigator represents these rows dimmed. The semantics are that the subtype catalogue part is also a supertype catalogue part (it belongs to the same category), overwriting a property value would violate this condition.
The material property is not inherited and its value may freely be chosen (although the naming of the catalogue part seems to restrict this freedom).
If the supertype catalogue part specifies a property type without giving it a value (value attribute of the property value object is empty) the semantics are that subtype catalogue parts are free to give it a value (or not: delegating this degree of freedom further down the type hierarchy).
This modelling construct facilitates the specification of catalogue part families, in this example a family of beams with different lengths.
Assembly hierarchy
The catalogue part data-structure facilitates also a modelling construct to build assembly hierarchies (decomposition). The basic approach is that a new catalogue part can be specified by combining already available catalogue (sub)parts. For example a portal can be composed from two column parts and a beam part.
