Obsah kapitoly

• 6.1 BUILDING SERVICES TYPE, OCCURRENCE AND PERFORMANCE HISTORY ENTITIES
• 6.1.1 Concepts of building service type definitions
• 6.1.1.1 Repre­sentation maps
• 6.1.1.2 Repre­sentation types
• 6.1.1.3 Assigning properties to the type definition
• 6.1.2 Concepts of building service occurrence elements
• 6.1.2.1 Assigning properties to the occurrence element
• 6.1.2.2 Overriding properties assigned to the type in the occurrence element
• 6.1.2.3 Concepts of the performance history control
• 6.2 CONCEPT OF CONNECTIVITY
• 6.2.1 Concept of Logical Connectivity
• 6.2.1.1 Logical Connectivity With Ports
• 6.2.1.2 Logical Connectivity Without Ports
• 6.2.2 Concept of physical connectivity
• 6.3 SPECIFIC CONCEPTS FOR SELECTED BUILDING SERVICE ELEMENTS
• 6.3.1 Concept of Flow Moving Device
• 6.3.1.1 Creating Pump Aggregations
• 6.3.1.2 Creating Pump Sets
• 6.3.1.3 Common Properties of Pump Types
• 6.3.1.4 Specifying The Pump Motor
• 6.3.2 Concept of Energy Conversion Device
• 6.3.2.1 Identifying Water Heaters
• 6.3.2.1.1 Property Sets Associated With a Water Heater
• 6.3.2.1.2 Water Heaters as Electrical Appliances
• 6.3.2.2 Air Handling Units
• 6.3.2.2.1 Spe­cifying The Fan Motor
• 6.3.3 Concept of Flow Storage Device
• 6.3.3.1 Tanks as Flow Storage Devices
• 6.3.3.2 Property Sets Associated With a Tank Type
• 6.3.3.2.1 Tank Shape
• 6.3.3.2.2 Sectional Tanks
• 6.3.3.3 Property Sets Associated With a Tank Occurrence
• 6.3.3.3.1 Com­partmentalized Tanks
• 6.4 BUILDING SERVICE SYSTEM ENGINEERING CONCEPTS
• 6.4.1 Concept of system
• 6.4.1.1 System Naming
• 6.4.1.2 System Naming in Applications
• 6.4.1.3 Multi­functionality
• 6.4.1.4 Subsystems

6 Building services elements and related concepts

The support for building service elements has been greatly enhanced in IFC2×2, the use of types (as subtypes of IfcTypeProduct) is now strongly encouraged.
Also the definitions for ports (as IfcDistributi­onPort) have been reworked.

6.1 Building services type, occurrence and performance history entities

In IFC2×2, the notions of type and occurrence have been formalized in the building services model architecture, as has the concept of a performance history entity which is used to store state-specific properties that come and go during the life-cycle of the occurrence.
The occurrence entity is related to its type via the IfcRelDefinesByType relationship and to zero or many IfcPerformance­History entities via the IfcRelAssigns­ToControl relationship. The following figure illustrates these concepts:

Figure 62 : Type, Occurrence and Performance History Concepts

Each type specific entity has an attribute PredefinedType.
It refer to an enumeration of special types of the component, which further specializes the component tree and allows the allocation of specific property sets to the type.

The depth of the subtyping tree is different for the occurrences and for the types, the occurrence specialization tree is shallow, whereas the type specialization tree is deep. The listing of all occurrence entities with the applicable type entities and the predefined enumeration is shown in Table 8. within Appendix 1.

6.1.1 Concepts of building service type definitions

Building service type definitions are used to define common properties for occurrence elements.
Each instance of a building service occurrence element gets its full description (aside from the local placement, local connectivity, occurrence properties, etc.) from its type definition including the block- type geometry, shared properties, basic type name and description, etc. These are exchanged through IFC2×2 as subtypes of IfcTypeProduct.

Therefore each building service element subtype of IfcFlowDistri­butionElement refers to an instance of an IfcTypeProduct subtype using the IfcRelDefinesByType relationship. The IfcTypeProduct handles the:

• type name as IfcTypeProduct.Name
• description of the type as IfcTypeProduc­t.Description
• shared properties, common for all occurrences, as IfcTypeProduc­t.HasProperty­Sets
• shared geometric representation as IfcTypeProduc­t.Representati­onMaps This information is independent of the actually inserted building service element and may even be exchanged without any occurrence instance.

In this case it enables the exchange of catalogues or libraries of type definitions.
Within IFC2×2 the building service type definition has been greatly enhanced.
For each entity representing an occurrence of a building service component, an equivalent abstract type object exists.
All inherit from the IfcDistributi­onElementType.

Each non abstract subtype of IfcDistributi­onElementType adds another attribute, the PredefinedType. The PredefinedType represents a further level of specialization. It can either be set to a specific enumerator or to either .USERDEFINED. or .NOTDEFINED.. In case of .USERDEFINED. the attribute

ElementType should hold a user specific component type name, in case of .NOTDEFINED. no further specialization is available.

6.1.1.1 Repre­sentation maps

The representation maps specify one or many representations of the building service element (and they are therefore comparable to the concept of multi-view blocks or library objects, or intelligent macros, as often used in CAD systems).

Each representation map has an origin (normally 0.,0.,0.) and a representation, which has a representation identifier and representation type, identifying its use within different representation views (see also 9.1.4.1).

Example: A specific elbow type (here IfcDuctFittingType) should be exchanged as the underlying type of (one or several) building service elements (here IfcFlowFitting). The example shows how are the name and description is exchanged.

It also shows, how two different representation maps (one for the body used in the 3D model view, the second for the footprint used in the floor plan view) can be sent.

Figure 63 : example of block definition for elbow

6.1.1.2 Repre­sentation types

There are several geometric representations foreseen for building service types:

• Representation identifier ‚Axis‘, representation type ‚GeometricSet‘
• Representation identifier ‚FootPrint‘, representation type ‚GeometricSet‘
• Representation identifier ‚Body‘, representation type ‚SurfaceModel‘, ‚Brep‘ or ‚SweptSolid‘

Each of the representation types can be replaced by „MappedRepresen­tation“, if the type concept, i.e. the use of an IfcMappedItem for sharing the geometric representation(s) of the type is used. The principle concept of using IfcMappedItem is introduced in 9.1.4.2, its use in conjunction with the IfcTypeProduct is shown in 10.1.4.

From IFC2×2 onwards the use of the type concept is now strongly encouraged, the entity type information about the building service element now lies in the type object.

Example: The following example shows four wash basins (as a type of IfcSanitaryTer­minalType and occurrences of IfcFlowTerminal) inserted as instances of a library object.
Each instance has its own local placement, and the geometric representation of its ‚Body‘ is given by ‚MappedRepresen­tation‘, being the IfcMappedItem, referring to the common IfcRepresenta­tionMap. Each mapped item has a transformation matrix relative to the object coordinate system, given by the IfcLocalPlacement, (here always scale 1 and no translation or rotation).

Figure 64 : Example of building service element occurrences

The examples show how the geometry that is associated to the IfcTypeProduct subtype IfcSanitaryTer­minalType is referenced by the IfcMappedItem (which could be done for multiple geometric representations).

The Cartesian transformation operator places the IfcRepresenta­tionMap (given within its own coordinate system, provided by IfcRepresenta­tionMap.Mappin­gOrigin) into the object coordinate system (given by supertype IfcProduct.Ob­jectPlacement).
Although not used in the example, translation, rotation and scaling (uniform and non-uniform) of the IfcRepresenta­tionMap is possible.

6.1.1.3 Assigning properties to the type definition

In addition to the shared geometric representation each building service element type can also hold the shared (or type specific) properties (including property values).
These are exchanged as property sets directly attached to the type (and do not need to be multiplied for each occurrence) using the IfcTypeObject­.HasPropertySets attribute.

Example: A washbasin type (here IfcSanitaryTer­minalType) should be exchanged as the underlying type of (one or several) building service elements (here IfcFlowTerminal).
The example shows how are the name and description is exchanged. It also shows, how the commonly shared properties are exchanged (the geometric representation is omitted in that example).

Figure 65 : example of block or library definition for washbasin

6.1.2 Concepts of building service occurrence elements

The occurrence entity represents the physical manifestation of the type. All building service elements inherit the concepts and UoF associated to elements, which are provided by IfcElement. It includes:

• „Identification“ and „Change management“, see section 3.1.
• „Generic Type Assignment“ and „Generic Property Attachment“, see section 9.2, refined as element type assignment for selected building elements.
• „External References“ to documents, classifications and libraries, see section 10.4.
• „Generic Decomposition“
• „Placement“ see section 9.1.2, and „Shape Representation“, see section 9.1.3, refined as building element specific shape representation (also referred to as geometry use cases) within this section.
• „Element in Spatial Structure Containment“, see section 3.
• „Element quantities“, see section 10.3.
• „Material assignment“, see section 10.2. refined as building element specific material assignment (e.g. for walls) within this section.
• „Element Connectivity“, see section 6.2.

All building service element occurrence entities are exchanged by an IFC2×2 file as instances of subtypes of IfcDistributi­onElement. If the appropriate semantic classification exists in the IFC2×2 specification (and within the originating application) then the building element is exported by the appropriate subtype entity. If this is not the case, then the IfcDistributi­onElement entity should be used instead.

NOTE: The use of IfcBuildingEle­mentProxy is not encouraged and might be limited to the current edition of IFC2×2.

Figure 65 shows the hierarchy for all currently defined building service occurrence elements. All subtypes of IfcDistributi­onElement are out of the stable platform.

NOTE: The area of building service elements will continue to undergo changes with future editions of the IFC2×2 model.

The various subtypes of IfcDistributi­onFlowElement do not elaborate any further attributes. These subtypes are introduced solely for the purpose of semantics and logical structuring of the model.. Each of the subtypes inherit the following attributes and inverse relationships from IfcDistribiti­onFlowElement:

ENTITY IfcDistributi­onFlowElement GlobalId : IfcGloballyUni­queId; OwnerHistory : IfcOwnerHistory; Name : OPTIONAL IfcLabel; Description : OPTIONAL IfcText; ObjectType : OPTIONAL IfcLabel; ObjectPlacement : OPTIONAL IfcObjectPlacement; Representation : OPTIONAL IfcProductRepre­sentation; Tag : OPTIONAL IfcIdentifier; INVERSE IsDefinedBy : SET OF IfcRelDefines; HasAssociations : SET OF IfcRelAssociates; HasAssignments : SET OF IfcRelAssigns; Decomposes : SET [0:1] OF IfcRelDecomposes; IsDecomposedBy : SET OF IfcRelDecomposes; ReferencedBy : SET OF IfcRelAssigns­ToProduct; ConnectedTo : SET OF IfcRelConnectsE­lements; ConnectedFrom : SET OF IfcRelConnectsE­lements; FillsVoids : SET [0:1] OF IfcRelFillsElement; HasCoverings : SET OF IfcRelCoversBldgE­lements; HasProjections : SET OF IfcRelProjectsE­lement; HasOpenings : SET OF IfcRelVoidsElement; HasPorts : SET OF IfcRelConnectsPor­tToElement; IsConnectionRe­alization : SET OF IfcRelConnectsWit­hRealizingEle­ments; ProvidesBoundaries : SET OF IfcRelSpaceBou­ndary; ContainedInStruc­ture : SET [0:1] OF IfcRelContaine­dInSpatialStruc­ture; HasControlElements : SET [0:1] OF IfcRelFlowCon­trolElements; END_ENTITY;

Figure 66 : Hierarchy chart of building service elements

6.1.2.1 Assigning properties to the occurrence element

Beside the shared properties already attached to the type as shown above, each occurrence of a building service element can have its occurrence specific properties attached, using the general principle as introduced in 10.1.2.1.

Example: Extending the example, reflected in Figure 63 by occurrence specific properties, two additional properties should be added: a serial number and an asset number. Both vary by occurrence for each of the four washbasins.
The complete sum of properties for each occurrence of a building service element is therefore the sum of those property sets assigned thought the shared type (via IfcRelDefines­ByType) and those assigned directly (through IfcRelAssigns­ByProperties).

6.1.2.2 Overriding properties assigned to the type in the occurrence element

In addition there is the possibility to override shared properties, assigned through the type by using the overriding mechanism of IfcRelOverrides­Properties.
This allows the ability to handle exceptions for a few shared properties that have different values for some occurrences. The principle mechanism is described in 10.1.2.2

Example: One occurrence of the washbasins has a different production year (although otherwise identical), this can be exchanged by overriding the shared property, attached to the type.

6.1.2.3 Concepts of the performance history control

Building service occurrences come into existence at different phases of the building-lifecycle. Furthermore, they have properties that change over time, such as the temperature of the air in a duct.

The performance history concept was introduced in IFC2×2 to capture such properties independently from the occurrence element itself. This allows for the possibility of the exchange file to capture all known historical information associated with an element.
As a subtype of IfcControl, IfcPerformance­History entities can be related to subtypes of IfcFlowDistri­butionElement via the IfcRelAssigns­ToControl relationship. The IfcPerformance­History entity handles the:

• type name as IfcObject.Name
• description of the type as IfcObject.Des­cription
• lifecycle phase using the IfcPerformance­History.LifeCy­clePhase attribute
• property sets using IfcObject.IsDe­finedBy and the IfcRelDefines relationship

6.2 Concept of connectivity

Connectivity between building service and electrical components is an important concept within IFC2×2. There are two ways to handle connectivity:

• as a logical connectivity concentrating on the fact that two components connect via their ports
• as a physical connectivity where the physical manifestation of the connection is explicitly described as well

6.2.1 Concept of Logical Connectivity

The concept of connectivity is generally associated with things that are directly or physically connected. However, there are circumstances where it is important to know that there is a connective relationship between two (or more) objects but where there is no physical connection to identify this fact.
A simple idea of this could be seen in the IfcRelContaine­dInSpatialStruc­tures relationship. Whilst this is not intended to show connectivity, it does identify the connection of an element within a particular spatial structure.

The idea of non-physical connection may be termed logical connectivity in the sense that there is a logical or implied connection between objects. Logical connectivity may be achieved using instances of IfcPort (or its subtype IfcDistributi­onPort) or it may need to be handled by more general connectivity concepts where ports are not present or cannot be used.
The use of ports for connectivity is the normal way to handle connectivity for building service components.

6.2.1.1 Logical Connectivity With Ports

A particular example of logical connectivity that can be achieved using ports is the connection between a light switch and the lights that are turned on and off by that switch.

Frequently, the cable that connects the switch with a light will not be instantiated in a model and so the physical connection cannot be achieved. In this case, the cable making the connection has to be implied.

Figure 67: Logical connection between switch and light fixture

Figure 68: Entities used in logical connectivity with ports

Because both the light switch (as an instance of IfcFlowController) and the light fixture (as an instance of IfcFlowTerminal) may have related instances of IfcDistributionPort (bound through the IfcRelConnectsPor­tToElement), then logical connection may be achieved using ports.

IfcRelConnectsPorts has an additional attribute, RealizingElement, that enables the specification of a realizing element. In this case, the realizing element is the implied cable connection between the switch and the light fixture. This can be instantiated although, since the connection is logical, it cannot have a representation.

Similarly, the implied connection is made as a single occurrence; it is not possible with such a logical connection to express in detail a cable routing. Strictly speaking: the instantiation of the realizing element would create a physical connectivity (see 6.2.2).

6.2.1.2 Logical Connectivity Without Ports

An example of a logical connectivity without ports may be seen from the situation of a water supply pipe taken to discharge into a tank (the particular situation in this example being a potable water pipe which is taken to discharge into a tank containing non potable water in which case, a specific distance between the outlet of the potable discharge and the waterline of the non potable water in the tank must be maintained).

In this case, the discharge end of the pipe will have a distribution port that is unfulfilled (i.e. it does not otherwise participate in a connection relationship). However, the surface of the tank water content does not contain a port to which a connection can be made.

Figure 69: Tank with logical connection between discharge and waterline using an air gap

Theoretically, a port could be introduced at the waterline of the tank and a connection made using IfcRelConnectsPor­ts. It is considered unlikely that this facility will be offered in software and, in fact, is considered to be undesirable since it would break the useful concept that an unfulfilled port describes an open end in a pipe.

Figure 70: Defining logical connectivity without ports

Sine the waterline does not have a port, an alternative connection needs to be defined. This can be achieved using the IfcRelConnectsE­lements relationship. In this case, the elements concerned will be the flow segment describing the open ended pipe and the tank.
Questions of the distance from the discharge end of the pipe to the water surface have to be answered by deriving appropriate coordinate values from the positioning data available.

Figure 71: Alternative logical connectivity without ports using a realizing element

An alternative approach would be to use ifcRelConnectsWit­hRealizingEle­ment in which case an appropriate entity for the object realizing the connection relationship would need to be determined.

6.2.2 Concept of physical connectivity

If the logical connectivity (as described in section 6.2.1) is enhanced by a realizing element, it constitutes a physical connectivity.

The new IFC2×2 substantially enhances the ability to traverse connected building services elements. This is handled primarily through the IfcDistributionPort and IfcRelConnectsPorts and IfcRelConnectsPor­tToElement relationships.
The following figures exemplify these using a duct segment connecting to a tee and distributing air out through two connecting duct segments as shown in Figure 71.

Figure 72 : Duct segments connected to a tee fitting

Any building services element can have a related IfcDistributionPort instance related to it via the IfcRelConnectsPor­tToElement relationship (see Figure 72). Although the port has a local placement, which allows it to be aligned with its related element, it typically does not have any physical manifestation, and consequently there is no corresponding type definition for the port concept.

Use the IfcDistributi­onPort.Name attribute to define the sequential port number assigned to each element. This is necessary for relating property set values that contain lists of properties associated with a port, such as connection type, size, etc. Ports are connected together using the

Figure 73 : Connectivity example between two building services elements

Relating other engineering properties, such as flow characteristics, etc. to the port is accomplished as shown in Figure 73. Note that instances of IfcFluidFlowPro­perties and property set information containing connection-specific parameters are shared between both ports rather than duplicated.

Figure 74 : Assigning flow characteristics to ports

6.3 Specific concepts for selected building service elements

There are specific guidelines available to handle different building service elements. Currently included within this section of the Model Implementation Guide are:

• flow moving devices
• energy conversion devices
• flow storage devices

6.3.1 Concept of Flow Moving Device

An IfcFlowMovingDevice is defined as a device that participates in a distribution system and is used for moving or impelling a fluid, such as a liquid or a gas, around a system. Generally, a flow moving device may be thought of as a fan, pump, or compressor.

As is normal for components in building services systems, flow moving devices are specified by type through a type entity (e.g. IfcPumpType) with each occurrence of a flow moving device specified using IfcFlowMovingDe­vice.
The occurrence of IfcFlowMovingDevice is typed as e.g. a pump through an instance of the IfcRelDefinesByType relationship class.

Figure 75: Pump type and occurrence definition

/* definition of the type -no geometry shown or property sets defined- / #1= IFCPUMPTYPE(‚ab­cdefghijklmnop­qrst11‘, #2, ‚Pump₁‘, $, ‚IfcFlowMovin­gDevice‘, $, (#1011), $, $, .CIRCULATOR.); / definition of the occurrences

• no geometry shown- */

#10=IFCRELDEFI­NESBYTYPE(‚ab­cdefghijklmnop­qrst10‘, #2, $, $, (#20), #1); #20=IFCFLOWMO­VINGDEVICE(‚ab­cdefghijklmnop­qrst20‘, #2, $, $, $, #10001, #10002, $);

6.3.1.1 Creating Pump Aggregations

Pumps are typically installed complete with a set of isolating valves that enable the pump to be removed for maintenance or exchange.
It is possible to make an aggregation of the physical pump and the valves (and any connecting pipework and fittings) and treat them as though they were a single object.
In this case, the object that is the target of the aggregation becomes also an IfcFlowMovingDe­vice. The bringing together of the objects into an aggregation is achieved using the relationship class IfcRelAggregates.

/* definition of the occurrences being aggregated -no geometry shown- / #20=IFCFLOWMO­VINGDEVICE(‚ab­cdefghijklmnop­qrst20‘, #2, $, $, $, #10001, #10002, $); #21=IFCFLOWCON­TROLLER(‚abcdef­ghijklmnopqrst21‘, #2, $, $, $, #10003, #10004, $); #22=IFCFLOWCON­TROLLER(‚abcdef­ghijklmnopqrst22‘, #2, $, $, $, #10005, #10006, $); #23=IFCFLOWFIT­TING(‚abcdefghij­klmnopqrst23‘, #2, $, $, $, #10007, #10008, $); #24=IFCFLOWFIT­TING(‚abcdefghij­klmnopqrst24‘, #2, $, $, $, #10009, #10010, $); #25=IFCFLOWFIT­TING(‚abcdefghij­klmnopqrst25‘, #2, $, $, $, #10011, #10012, $); #26=IFCFLOWFIT­TING(‚abcdefghij­klmnopqrst26‘, #2, $, $, $, #10013, #10014, $); / defines the pump aggregation / #50=IFCRELAGGRE­GATES(‚abcdef­ghijklmnopqrst50‘, #2, $, $, #60, (#20,#21,#22,­#23.#24,#25,#26­)); / specification of the aggregation – without placement or representation/ #60=IFCFLOWMO­VINGDEVICE(‚ab­cdefghijklmnop­qrst60‘, #2, $, $, $, $, $, $); / definition of occurrence property set / #300=IFCPROPER­TYSET(‚abcdef­ghijklmnopqrst300‘, #2, ‚Pset_FlowMovin­gDevicePump’, $, (#310,#311,#312)); #301=IFCPROPER­TYSET(‘abcdef­ghijklmnopqrst301', #2, ‚Pset_FlowMovin­gDevicePump’, $, (#320,#321,#322)); / defines specific properties for a pump / #310=IFCPROPER­TYENUMERATEDVA­LUE(‘PumpCompo­sition', $, (‘ELEMENT’), #351); #311= …… ; #312= …… ; #320=IFCPROPER­TYENUMERATEDVA­LUE(‚PumpCompo­sition‘, $, (‘COMPLEX’), #351); #321= …… ; #322= …… ; / defines property enumerations used in specific type property set / #351=IFCPROPER­TYENUMERATION(‘PE­num_PumpCompo­sition’, (‘COMPLEX’, ‘ELEMENT’, ‘PARTIAL’, ‘NOTKNOWN’, ‘UNSET’), $); / definition of properties for the occurrences */ #410=IFCRELDE­FINESBYPROPER­TIES(‚abcdefghij­klmnopqrst410‘, #2, $, $, (#20), #300); #411=IFCRELDE­FINESBYPROPER­TIES(‚abcdefghij­klmnopqrst411‘, #2, $, $, (#60), #301);

Figure 76: Specifying a pump aggregation

As with flow storage devices (tanks), pumps can be identified as being elemental or complex through the property PumpComposition contained in the property set Pset_FlowMovin­gDevicePump. Note that this property set is defined for pump occurrences and not for pump types.

6.3.1.2 Creating Pump Sets

A pump set is considered to be an aggregation of 2 or more pumps that can act either together in series or in parallel or on a run and standby basis (i.e. one pump switched on and working whilst a second pump, and typically same sized pump, is inoperative but ready to become operative in the case of the first pump failing or being taken out of action.

Figure 77: Different levels of pump composition

In this case, the pump set aggregation consists of two or more of the pump aggregations as above (comprising the pump, valves, pipework and fittings), the valve, pipework and fitting that may be installed as a bypass line (i.e. a line forming part of the pump set but in which flow can bypass the installed pumps) and any pipework and fittings used to bring all of the individual aggregations together into a total aggregation.

Figure 78: Specifying a pump set aggregation

6.3.1.3 Common Properties of Pump Types

The common properties of a pump type are given in Pset_PumpTypeCommon and includes such ideas as: FlowRateRange, FlowResistance­Range, ConnectionSize, CasingMaterial, ImpellerMaterial, ImpellerSealMa­terial, TemperatureRange, NetPositiveSuc­tionHead, NominalRotati­onSpeed.

Note that the values for flow rate; flow resistance and temperature range are specified as bounded values (which means that an upper and/or lower limit value can be set).

6.3.1.4 Specifying The Pump Motor

A pump is typically driven by an electric motor. There are two ways in which a pump motor can be specified:

1. directly at the pump by using a property set for the motor and defining it directly for the pump (most frequently used for a close coupled pump),

2. indirectly through a motor connection.

Figure 79: Directly specifying a pump motor

Where the motor is specified indirectly, type and occurrence specifications are required for the pump, the motor and the connection made between the pump and the motor.

Figure 80: Types and occurrences for indirect motor connection

When the occurrences have been specified, they can be connected together using the relationship IfcRelConnectsWit­hRealizingEle­ment.
This is a clear example of where the ternary or third relationship capability can be used since the specific intention of a motor connection is to realize the connection made between a motor as the driving device and (in this case) the pump as the driven device. By so doing, only one relationship is required.
If the connections were made using other, conventional connection relationships, two separate relationships would be needed, one for the connection between motor and motor connection and one between the pump and the motor connection.

The actual type of the motor connection can be specified by the enumeration value IfcMotorConnec­tionTypeEnum that allows identification of whether direct drive, belt drive or coupling (e.g. fluid or viscous coupling) is used.

Figure 81: Realizing the indirect motor connection

6.3.2 Concept of Energy Conversion Device

An IfcEnergyConver­sionDevice is defined as a device that is used to perform energy conversion or heat transfer and that typically participates in a flow distribution system.
In the context of general energy conversion, it may be used to identify a device that converts energy from one form to another such as an electric motor. In the context of heat transfer, it may be used to identify a device in which heat is transferred from a primary medium to a secondary medium such as a boiler, water heater, chiller etc.

In the heat transfer context, energy conversion is concerned both with the circumstance in which the secondary medium is heated (boiler, water heater) and that in which the secondary medium is cooled (chiller).

As is normal for components in building services systems, an energy conversion device is specified by type through IfcEnergyConver­sionDeviceType with each occurrence of e.g. a boiler specified using IfcEnergyConver­sionDevice.

Figure 82: Energy conversion device type and instance

See Table 8 for particular types of energy conversion device that are defined as subtypes of IfcEnergyConver­sionDeviceType.

The Figure 82 shows the subtypes: IfcEnergyConver­sionDeviceType

Figure 83: Hierarchy of IfcEnergyConver­sionDeviceType

/* definition of the type -no geometry shown or property sets defined- / #1= IFCBOILERTYPE(‚ab­cdefghijklmnop­qrst01‘, #2, ‚Boiler₁‘, $, ‚IfcEnergyCon­versionDevice‘, $, (#1011), $, $, .WATER.); / definition of the occurrences

• no geometry shown- */

#10=IFCRELDEFI­NESBYTYPE(‚ab­cdefghijklmnop­qrst10‘, #2, $, $, (#20), #1); #20=IFCENERGY­CONVERSIONDEVI­CE(‚abcdefghij­klmnopqrst20‘, #2, $, $, $, #10001, #10002, $);

Energy conversion devices handle a substantial number of concepts in building services. Some particular issues that can arise and how they may be dealt with in an IFC file are discussed further below.

6.3.2.1 Identifying Water Heaters

In general, a water heater may be defined as an energy conversion device. In the sense that it heats water, it may be considered to be a boiler whose predefined type is ‘water’.

Figure 84: Types of water heater

Various different forms of water heater may be defined based on the mechanism used for heating the water (the primary energy source) and whether the water is to be heated and stored (storage type) or made available for instant use (instantaneou­s type).

6.3.2.1.1

Property Sets Associated With a Water Heater More detail about a specific type of water can be given in the Pset_BoilerTy­peCommon property set that is attached at the type entity.

Figure 85: Applying the common property set to a boiler type

Table 1: Values in Pset_BoilerTy­peCommon

In this case, because gas is used as the primary medium, the water heater is considered to be ‘Direct’ fired.
This would be the case also if the primary medium were ‘Electric’. For indirect heaters using heat transfer from water or steam, the values would be prefixed by ‘Indirect’ (as in INDIRECT_WATER, INDIRECT_STEAM).

In the above example, the property set is partially expanded to show some of the properties. In this example, the actual enumeration value used for the primary medium and the operating mode is shown but the enumeration references from which they are taken are not quoted.

6.3.2.1.2

Water Heaters as Electrical Appliances It should be noted that the IFC model also contains the concept of a water heater as an electrical appliance (as a value within the IfcElectricalAp­plianceTypeEnum).
This should be used only for examples of small, movable water heaters that have local plug connections (i.e. are not directly wired to an electrical system or that do not use plugs that are expected to be permanently placed).
Such a water heater will also not use the Pset_BoilerTy­peCommon for attribute information.

Other than as above, the IfcElectricalAp­plianceTypeEnum=­.WATERHEATER. should not be used.

6.3.2.2 Air Handling Units

Air handling units (air handlers) are instances of IfcUnitaryEqu­ipmentType used for the purpose of changing air conditions (humidity and/or temperature) between the entry and exit points.

Air handling units may be supplied by a manufacturer as a complete package or constructed of discrete components. Even when an air handling unit is delivered as a complete package, there may be a need to deal with information at a component based level for design or maintenance purposes.

Therefore, it is necessary to be able to handle information directly at the component level and at the aggregated air handling unit level. The aggregation is achieved using IfcRelAggregates.

Figure 86: Aggregation of components in an air handling unit

6.3.2.2.1 Spe­cifying The Fan Motor

The fan, the motor and the connection between them can be connected together using the relationship IfcRelConnectsWit­hRealizingEle­ment.
The type of the motor connection can be specified by the enumeration value IfcMotorConnec­tionTypeEnum that allows identification of whether direct drive, belt drive or coupling (e.g. fluid or viscous coupling) is used. See also 6.3.1.4.

Figure 87: Realizing the indirect motor connection

6.3.3 Concept of Flow Storage Device

An IfcFlowStorage­Device is defined as a device that participates in a distribution system and is used for temporary storage of a fluid such as a liquid or a gas. Generally, a flow storage device may be thought of as a tank although other types of storage device could be specified.

6.3.3.1 Tanks as Flow Storage Devices

A tank is the most general form of flow storage device. As is normal for components in building services systems, tanks are specified by type through IfcTankType with each occurrence of a tank specified using IfcFlowStorage­Device. The occurrence of IfcFlowStorage­Device is typed as a tank through an instance of the IfcRelDefinesByType relationship class.

Figure 88: Flow storage device type and occurrence

/* definition of the type -no geometry shown or property sets defined- / #1= IFCTANKTYPE(‚ab­cdefghijklmnop­qrst11‘, #2, ‚Tank₁‘, $, ‚IfcFlowStora­geDevice‘, $, (#1011), $, $, .PREFORMED.); / definition of the occurrences

• no geometry shown- */

#10=IFCRELDEFI­NESBYTYPE(‚ab­cdefghijklmnop­qrst10‘, #2, $, $, (#20), #1); #20=IFCFLOWSTO­RAGEDEVICE(‚ab­cdefghijklmnop­qrst20‘, #2, $, $, $, #10001, #10002, $);

6.3.3.2 Property Sets Associated With a Tank Type

More detail about a specific type of tank can be given in property sets that are attached at the type entity.

Figure 89: Property sets associated with a tank type

Several possibilities are defined as standard property sets within the IFC model:

• Properties Common To All Types of Tank
  • Pset_TankTypeCommon
• Properties Specific to A Type of Tank
  • Pset_TankType­Expansion
  • Pset_TankType­PressureVessel
  • Pset_TankType­PreformedTank
  • Pset_TankType­SectionalTank

As an example, consider a storage tank with a nominal capacity of 6000 litres. The common properties given within the Pset_TankTypeCommon for such a tank are:

Table 2: Properties for Tanks as defined in Pset_TankTypeCommon

6.3.3.2.1 Tank Shape

Geometrically, a tank may be specified as rectangular, as a horizontal or vertical cylinder or as a spherical container.

Figure 90: Types of tank shape

This shape is defined as a property PatternType defined as an enumeration within the property set Pset_TankType­PreformedTank e­.g.

Table 3: Setting the value for tank shape

Additionally, values are defined that enable the curvature of the ends of a horizontal or vertical cylinder.
This allows specification of whether the ends are concave, convex or flat (or whether, as in the case of a spherical tank, unset). Values are defined in pairs so that it is possible to specify concave/convex etc.
In this case, it is necessary to define a convention that enables the identification of which end is which.

The convention applied is that the first value in the pair represents the base (in the case of a vertical cylinder) or the left hand side (in the case of a horizontal cylinder when viewed as a front elevation). This becomes relevant when specifying the radius of curvature of shaped ends (below).

Radii of curvature are found from the properties FirstCurvature­Radius and SecondCurvatu­reRadius defined in the property set Pset_TankType­PreformedTank. As identified from the convention, the ‘First’ value is base or left hand side whilst ‘Second’ is the top or right hand side.

The actual values given for radii of curvature must be positive (through specification of the use of IfcPositiveLen­gthMeasure). This means that the curvature directions are identified from the terms ‘concave’ (for inward curvature) and ‘convex’ (for outward curvature.

Table 4: Setting values for curved end shapes

6.3.3.2.2 Sectional Tanks

A rectangular tank may be preformed or it may be sectional. Preformed tanks are generally relatively small with the body of the tank it is delivered to site in one piece.
Sectional tanks tend to be large and are constructed on site from plate sections that are bolted together.

In the case of a sectional tank being specified, the property set Pset_TankType­SectionalTank is also used to specify the number of sections to be used together with the length and width of each section.

It should be noted that, in a sectional tank, the overall size is given by Pset_TankTypeCommon and the section sizes by Pset_TankType­SectionalTank.
There is no automatic cross checking that the overall size matches the tank size that would be determined by adding together the sizes of sections. It is up to the user, or the application employed by the user, to reconcile these sizes.

6.3.3.3 Property Sets Associated With a Tank Occurrence

Individual occurrences of a tank can also have properties. These are attached to the flow storage device occurrence however and not to the tank type

Figure 91: Property set associated with a tank occurrence

Table 5: Setting values in the tank occurrence property set

6.3.3.3.1 Com­partmentalized Tanks

Tanks may be provided so that fluid storage is in one compartment (the whole tank) or in multiple, separated compartments.
The latter will be particularly the case with large tanks. This predominantly relates to rectangular tank constructions but could also relate to other shapes.
The situation is similar to that of spatial structure elements where an element can be described as complex (multiple units), element (single unit) or partial (part of a unit).

Figure 92: An individual tank compartment

The Solution can be determined by:

• Applying the composition principle to tanks.
• A compartment is an IfcFlowStorage­Device specified as a partial element through the occurrence level property set Pset_FlowStora­geDeviceTank by setting the TankComposition value to PARTIAL
• A tank is an IfcFlowStorage­Device specified as a complete element through the occurrence level property set Pset_FlowStora­geDeviceTank by setting the TankComposition value to ELEMENT
• Multiple tanks acting together through interconnection are an instance of IfcTankType specified as a complex element through the occurrence level property set Pset_FlowStora­geDeviceTank by setting the TankComposition value to COMPLEX
• Use IfcRelNests to connect compartments to tanks (since both are instances of IfcTank)

Figure 93: Aggregating multiple compartments into a single tank

Figure 94: Aggregating individual tanks into a tank complex

Each compartment of the tank can be recognized with its own properties instead of trying to capture these within an overall tank property set.
A tank with compartments of different sizes can be composed (instead of assuming that all compartments are the same size) and
separate tanks acting together to fulfil a common role can be identified as a tank complex.

Figure 95: Connections from tank compartments

6.4 Building service system engineering concepts

The concepts of system and zoning for building service elements are important to building services specific view definitions of IFC2×2 – however they don't form part of the basic coordination view.

6.4.1 Concept of system

A system is defined as an ‘organized combination of related parts within an AEC product, composed for a common purpose or function or to provide a service’.
The key concepts of this definition are that the parts are related and that, in composition, they fulfill a common purpose. Within the IFC Model, a system is defined as a subtype of IfcGroup. That is, it acts as a functional related aggregation of objects.
However, whilst the IfcGroup can aggregate any set of instances that are subtypes of IfcObject, the IfcSystem is restricted by a WHERE rule so that it can only aggregate subtypes of IfcElement or other (sub-)systems.

Whilst this allows for any subtype of element to participate in an IfcSystem, the definition that they should be related is significant.
Typically, an IfcSystem will act for a particular purpose and the elements that are aggregated into the system should be consistent withy that purpose.
For instance, in an architectural context, a system might be used to define a functionally related set of walls.
In structural engineering, this might be beams and columns whilst in a building services context, a system will comprise distribution elements (pipes or ducts or cables and related items).
Objects that are clearly intended for use within one purpose should not be mixed in a system with objects that are clearly intended for a different purpose.

Figure 96 : Elements aggregated into a system

In general, it is expected that the elements that comprise a system will be connected together in a ‘systematic’ way. However, there is no enforcement of a connectivity requirement within IfcSystem14.

Therefore, if there is a need for elements to be connected (e.g. to establish a flow path), this has to be defined prior to an IFC export or be determined by applying external rules procedures to the exported information.

6.4.1.1 System Naming

There may be many instances of IfcSystem within a building, each system fulfilling a different purpose. To distinguish between them, it is important that each system is named or identified according to what it does.
There are two potential strategies that can be used for system naming. These are explicit naming and classification.

For explicit naming, systems are identified using the inherited Name attribute from IfcRoot. This resolves to a simple STRING data type.

Note also that the attribute ObjectType inherited from IfcObject may be optionally used to qualify the system name further. The latter is particularly used together with property set or type definitions attached to the IfcSystem.

An enumeration of system types is not used, firstly because of the enormous range of system types that can exist and secondly because naming of system types is likely to vary from place to place.

Where selection is to be made from a constrained list, it is strongly recommended that the classification strategy is used and that a list of system types within a published classification is used. For detailed information on implementation of classification within IFC, a reference is made to the relevant section

10.4.2. An example of classified system types extracted from the UNICLASS15

specification is given below. In UNICLASS, systems are identified within sections G5 (Mechanical) and G6 (Electrical):

Table 6 : Example of UNICLASS system definitions

Note¹⁴ Up to IFC 2×2 Addendum 1

Note¹⁵ UNICLASS is a facetted classification system based on the classification systems framework of ISO 12006 Part 2 and developed for use within UK practice.

6.4.1.2 System Naming in Applications

There are many cases where system names provided through an IFC exchange need to comply with particular system types. Examples include:

• application of varying design parameters in different system types;
• checking that a system or parts of a system comply with the requirements of building codes.

It is likely that agreements on system naming will need to be made according to local or project usage or through use of a named classification system.
In either case, it is important that the application exports a system name or identity that can be understood by the downstream (receiving) application according to the defined criteria.

6.4.1.3 Multi­functionality

Some elements can participate in more than one group (generically) or more than one system (specifically).
The ability of an element to participate in more than one performing group is termed multifunctionality.
Multifunctionality is achieved by assigning an element to more than one instance of IfcGroup (or its subtype IfcSystem) through the definition of multiple instances of IfcRelAssigns­ToGroup. For instance, a pipe may belong to one system group for fabrication purposes, a second system group for building code checking purposes and a third group for scheduling purposes. Each group in this case may be defined as a subsystem (see below), the element still participates in only one overall system.

Figure 97 : Multifunctional element in multiple subsystems

Alternatively, an element may be performing a distribution role in one system context but a structural role in a different system context.
In this case, the element is assigned to two completely separate systems through two instances of IfcRelAssigns­ToGroup.

Figure 98 : Multifunctional element in multiple system contexts

6.4.1.4 Subsystems

There is often a need to be able to identify related subsets of elements within a system.
Subsets, or subsystems, may be required for many purposes including for off-site fabrication, identification for building code compliance, construction scheduling (and 4D animation).

Figure 99 : A group can contain other groups

Within IFC 2×2, an IfcGroup (the supertype of IfcSystem) is specified as a subtype of IfcObject. Other objects are related to that group through IfcRelAssigns­ToGroup. The IfcRelAssigns class (which is the supertype of IfcRelAssigns­ToGroup) is used to provide the set of related instances of IfcObject. Because it is a subtype of IfcObject, an instance of IfcGroup can participate as a member of the set of objects forming another group.

Figure 100 : Elements aggregated into subsystems

Figure 101 : Systems and subsystems with hierarchical relations

A nesting relationship is considered to exist between a system and a subsystem (as opposed to the grouping relationship that exists between a system and its contained elements).
Within IFC 2×2, a nesting relationship is defined as a decomposition of objects of the same type.
That is, an IfcSystem can also nest other instances of IfcSystem.