Log In   View a printable version of the current page.
Added by Janice Wix, last edited by Janice Wix on Feb 11, 2007  (view change)
Labels: 
(None)


Model System

Overview

Provides the information concerning systems where a system is a grouping of elements. In the context of a distribution system, all of the elements that are grouped to form the system should be subtypes of IfcDistributionElement.
As well as enabling the description of complete systems, this functional part enables the grouping of elements into subsystems.
Within the IFC 2x2 Addendum 1 schema, for an electrical system, the subtype IfcElectricalCircuit is used. This provides a simple approach to validate that only electrical items are connected to the electrical system.
The information provided about a system includes:

  • Specification of a name and description for the system if required
  • The elements that are grouped together to form the system

Note that the shape representation of a system is derived from the shape representation of the elements that are grouped together within the system. The system itself has no 'own' shape representation.
Further information about the system may be provided through locally defined property sets. There are no predefined property sets for systems.

Concept of System

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.
Systems are identified using the inherited Name attribute from IfcRoot (IfcSystem.Name). This resolves to a simple STRING data type.

Multifunctionality

Subsystems

Results

Specification of the system and the elements that make up the system.

Description Entity/Pset/Functional Part MAN REC OPT
Specify the system occurrence in which elements will participate
A system opening is directly specified as an occurrence. It does not have a defining type entity.
IfcSystem
OR
IfcElectricalCircuit
   
Set the global unique identifier IfcSystem.GlobalId::IfcGloballyUniqueId
OR
IfcElectricalCircuit.GlobalId::IfcGloballyUniqueId
   
Assert the owner history of the system IfcSystem.OwnerHistory::fp_apply_owner_history
OR
IfcElectricalCircuit.OwnerHistory::fp_apply_owner_history
   
Specify the name of the system.
Although this is an optional attribute within IFC, it must be asserted for system.
It is strongly recommended that system names are taken from a list of allowable names that have been agreed between organizations that will make use of system information (to ensure that there is common understanding of the system purpose). The list of allowable names may be taken from a published source such as a classification system or standard reference or it may be agreed in the context of project.
IfcSystem.Name::IfcLabel
OR
IfcElectricalCircuit.Name::IfcLabel
   
Specify a description for the system
Whilst the description does not add value to the semantics of the system, it can provide significant information for later project stages, particularly in terms of providing an insight into a designers intent that remains available at operating and maintenance stages of a project.
IfcSystem.Description::IfcText
OR
IfcElectricalCircuit.Description::IfcText
   
Note that there are no predefined property sets for systems within the IFC model at present. It is possible however that locally defined property sets for systems may be defined and, where this is the case, the functional part 'fp_define_property_set' should be used to assist with the definition.      
Define the property set(s) for system fp_define_by_properties    
Specify the elements that are to participate in the system.
Note that, for a system, a WHERE rule is applied that constrains the related objects to be subtypes of IfcElement
IfcElement<subtype>    

 
Note that there is no specific placement or shape representation of a system. The actual placement and shape of the system is determined by the products that participate in the system.

 
For practical reasons, to establish a coherent shape representation for the system as a whole, the type of shape representation of the participating products must be consistent (this does not necessarily mean that each participating product must have the same type of shape representation but that the combination of types must provide a consistent representation form).

 
Placement and shape representation are only relevant for a system where it is to be visually represented.

IfcElement.ObjectPlacement::fp_place_object
IfcElement.Representation ::fp_represent_product
   
Assert the relationship that assigns the set of elements that will participate in the system
This is defined in a separate functional part
fp_assigns_to_group    
Assert the relationship between a system and a spatial structure element (site, building, storey, space) that it services
This is defined in a separate functional part
fp_services_building    

IFC Entities Required

  • IfcElectricalCircuit
  • IfcElement
  • IfcGroup
  • IfcObject
  • IfcProduct
  • IfcRoot
  • IfcSystem

IFC Datatypes Required

  • IfcGloballyUniqueId
  • IfcLabel
  • IfcText

IFC Functions Required

  • -
    IFC Property Sets Required
  • -

IDM Functional Parts Required

  • fp_assigns_to_group
  • fp_apply_owner_history
  • fp_define_by_properties
  • fp_place_object
  • fp_represent_product
  • fp_services_building

EXPRESS-G

EXPRESS Schema

SCHEMA FP_MODEL_SYSTEM;

  TYPE IfcGloballyUniqueId = STRING (22) FIXED;
  END_TYPE;

  TYPE IfcLabel = STRING;
  END_TYPE;

  TYPE IfcText = STRING;
  END_TYPE;

  ENTITY IfcObject
    ABSTRACT SUPERTYPE
    SUBTYPE OF(IfcRoot);
      ObjectType : OPTIONAL IfcLabel;
    WHERE
      WR1 : SIZEOF(QUERY(temp <* IsDefinedBy | 'IFC2X2_FINAL.IFCRELDEFINESBYTYPE' IN TYPEOF(temp))) <= 1;
  END_ENTITY;

  ENTITY IfcRoot
    ABSTRACT SUPERTYPE;
      GlobalId     : IfcGloballyUniqueId;
      Name         : OPTIONAL IfcLabel;
      Description  : OPTIONAL IfcText;
      OwnerHistory : fp_apply_owner_history;
    UNIQUE
      UR1 : GlobalId;
  END_ENTITY;

  ENTITY fp_apply_owner_history;
  END_ENTITY;

  ENTITY IfcSystem
    SUBTYPE OF(IfcGroup);
    WHERE
      WR1 : SIZEOF (QUERY (temp <* SELF\IfcGroup.IsGroupedBy.RelatedObjects |  NOT('IFC2X2_FINAL.IFCELEMENT' IN TYPEOF(temp)))) = 0;
  END_ENTITY;

  ENTITY IfcElectricalCircuit
    SUBTYPE OF(IfcSystem);
  END_ENTITY;

  ENTITY IfcGroup
    SUBTYPE OF(IfcObject);
  END_ENTITY;

  ENTITY fp_services_building;
  END_ENTITY;

  ENTITY fp_assigns_to_group;
  END_ENTITY;

  ENTITY fp_define_by_properties;
  END_ENTITY;

END_SCHEMA;

Examples of System

Example 1: Grouping elements into a 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 fulfil 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.
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 with 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 (other than where there use is intentionally multifunctional).
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 IfcSystem. 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.
The illustration below shows a system with pipework, fittings, valves and a heat emitter expressed as a flow terminal. The main purpose here is to show how the system is connected and consequently, attributes of the various components such as size, length, etc. are not developed. Similarly, the types to which the various elements in the system conform are not elaborated.

/* Owner History instances */
#2=IFCOWNERHISTORY( .. );

/* Element definitions */
#1001=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1001', #2, $, $, $, $, $, $);
#1002=IFCFLOWFITTING ('abcdefghijklmnopqrs1002', #2, $, $, $, $, $, $);
#1003=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1003', #2, $, $, $, $, $, $);
#1004=IFCFLOWCONTROLLER ('abcdefghijklmnopqrs1004', #2, $, $, $, $, $, $);
#1005=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1005', #2, $, $, $, $, $, $);
#1006=IFCFLOWFITTING ('abcdefghijklmnopqrs1006', #2, $, $, $, $, $, $);
#1007=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1007', #2, $, $, $, $, $, $);
#1008=IFCFLOWFITTING ('abcdefghijklmnopqrs1008', #2, $, $, $, $, $, $);
#1009=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1009', #2, $, $, $, $, $, $);
#1010=IFCFLOWFITTING ('abcdefghijklmnopqrs1010', #2, $, $, $, $, $, $);
#1011=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1011', #2, $, $, $, $, $, $);
#1012=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1012', #2, $, $, $, $, $, $);
#1013=IFCFLOWCONTROLLER ('abcdefghijklmnopqrs1013', #2, $, $, $, $, $, $);
#1014=IFCFLOWTERMINAL ('abcdefghijklmnopqrs1014', #2, $, $, $, $, $, $);
#1015=IFCFLOWCONTROLLER ('abcdefghijklmnopqrs1015', #2, $, $, $, $, $, $);
#1016=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1016', #2, $, $, $, $, $, $);
#1017=IFCFLOWFITTING ('abcdefghijklmnopqrs1017', #2, $, $, $, $, $, $);
#1018=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1018', #2, $, $, $, $, $, $);
#1019=IFCFLOWFITTING ('abcdefghijklmnopqrs1019', #2, $, $, $, $, $, $);
#1020=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1020', #2, $, $, $, $, $, $);
#1021=IFCFLOWFITTING ('abcdefghijklmnopqrs1021', #2, $, $, $, $, $, $);
#1022=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1022', #2, $, $, $, $, $, $);
#1023=IFCFLOWFITTING ('abcdefghijklmnopqrs1023', #2, $, $, $, $, $, $);
#1024=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1024', #2, $, $, $, $, $, $);
#1025=IFCFLOWFITTING ('abcdefghijklmnopqrs1025', #2, $, $, $, $, $, $);
#1026=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1026', #2, $, $, $, $, $, $);
#1027=IFCFLOWCONTROLLER ('abcdefghijklmnopqrs1027', #2, $, $, $, $, $, $);
#1028=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1028', #2, $, $, $, $, $, $);
#1029=IFCFLOWFITTING ('abcdefghijklmnopqrs1029', #2, $, $, $, $, $, $);
#1030=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1030', #2, $, $, $, $, $, $);

/* System definitions */
#2001=IFCSYSTEM ('abcdefghijklmnopqrst2001',#2,'HeatingSystem',$,'MainSystem');

/* Assignment of Elements to Systems */
#3001=IFCRELASSIGNSTOGROUP ('abcdefghijklmnopqrst3001',#2,$,$,(#1001,#1002,#1003,#1004,#1005,#1006,#1007,#1008,#1009,#1010, #1011,#1012,#1013,#1014,#1015,#1016,#1017,#1018,#1019,#1020,#1021,#1022,#1023,#1024,#1025,#1026, #1027,#1028,#1029,#1030),.PRODUCT.,#2001);

Example 2: Nesting subsystems within a system

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).
A subsystem needs to be defined separately to the system of which it is part.

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). 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.
The illustration below shows a system (main system that is a heating system) that contains two subsystems, one for the dropping pipe and one for the heat emitter. These subsystems may be defined for various purposes, in this case it may be assumed that each will be fabricated off-site.

/* Owner History instances */
#2=IFCOWNERHISTORY( .. );

/* Element definitions */
#1001=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1001', #2, $, $, $, $, $, $);
#1002=IFCFLOWFITTING ('abcdefghijklmnopqrs1002', #2, $, $, $, $, $, $);
#1003=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1003', #2, $, $, $, $, $, $);
#1004=IFCFLOWCONTROLLER ('abcdefghijklmnopqrs1004', #2, $, $, $, $, $, $);
#1005=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1005', #2, $, $, $, $, $, $);
#1006=IFCFLOWFITTING ('abcdefghijklmnopqrs1006', #2, $, $, $, $, $, $);
#1007=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1007', #2, $, $, $, $, $, $);
#1008=IFCFLOWFITTING ('abcdefghijklmnopqrs1008', #2, $, $, $, $, $, $);
#1009=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1009', #2, $, $, $, $, $, $);
#1010=IFCFLOWFITTING ('abcdefghijklmnopqrs1010', #2, $, $, $, $, $, $);
#1011=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1011', #2, $, $, $, $, $, $);
#1012=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1012', #2, $, $, $, $, $, $);
#1013=IFCFLOWCONTROLLER ('abcdefghijklmnopqrs1013', #2, $, $, $, $, $, $);
#1014=IFCFLOWTERMINAL ('abcdefghijklmnopqrs1014', #2, $, $, $, $, $, $);
#1015=IFCFLOWCONTROLLER ('abcdefghijklmnopqrs1015', #2, $, $, $, $, $, $);
#1016=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1016', #2, $, $, $, $, $, $);
#1017=IFCFLOWFITTING ('abcdefghijklmnopqrs1017', #2, $, $, $, $, $, $);
#1018=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1018', #2, $, $, $, $, $, $);
#1019=IFCFLOWFITTING ('abcdefghijklmnopqrs1019', #2, $, $, $, $, $, $);
#1020=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1020', #2, $, $, $, $, $, $);
#1021=IFCFLOWFITTING ('abcdefghijklmnopqrs1021', #2, $, $, $, $, $, $);
#1022=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1022', #2, $, $, $, $, $, $);
#1023=IFCFLOWFITTING ('abcdefghijklmnopqrs1023', #2, $, $, $, $, $, $);
#1024=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1024', #2, $, $, $, $, $, $);
#1025=IFCFLOWFITTING ('abcdefghijklmnopqrs1025', #2, $, $, $, $, $, $);
#1026=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1026', #2, $, $, $, $, $, $);
#1027=IFCFLOWCONTROLLER ('abcdefghijklmnopqrs1027', #2, $, $, $, $, $, $);
#1028=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1028', #2, $, $, $, $, $, $);
#1029=IFCFLOWFITTING ('abcdefghijklmnopqrs1029', #2, $, $, $, $, $, $);
#1030=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1030', #2, $, $, $, $, $, $);

/* System definitions */
#2001=IFCSYSTEM ('abcdefghijklmnopqrst2001',#2,'HeatingSystem', $,'MainSystem');
#2002=IFCSYSTEM ('abcdefghijklmnopqrst2002',#2,'DropPipeSubsystem', $,'Subsystem');
#2003=IFCSYSTEM ('abcdefghijklmnopqrst2003',#2,'EmitterSubsystem', $,'Subsystem');

/* Assignment of Elements to Systems */
#3001=IFCRELASSIGNSTOGROUP ('abcdefghijklmnopqrst3001',#2,$,$,(#1001,#1002,#1003,#1004,#1005,#1006,#1007,#1008,#1009,#1010,#1011,#1012,#1013,#1014,#1015,#1016,#1017,#1018,#1019,#1020,#1021,#1022,#1023,#1024,#1025,
#1026,#1027,#1028,#1029,#1030),.PRODUCT.,#2001);
#3002=IFCRELASSIGNSTOGROUP ('abcdefghijklmnopqrst3002',#2,$,$,(#1001,#1002,#1003,#1004,#1005,#1006,#1007),.PRODUCT.,#2002);
#3003=IFCRELASSIGNSTOGROUP ('abcdefghijklmnopqrst3003',#2,$,$,(#1008,#1009,#1010,#1011,#1012,#1013,#1014,#1015,#1016,#1017,#1018,#1019),.PRODUCT.,#2003);

/* Nesting of subsystems */
#4001=IFCRELNESTS ('abcdefghijklmnopqrst4001',#2,$,$,#2001,(#2002,#2003));

Example 3: Placing an element in multiple systems

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 through the definition of multiple instances of IfcRelAssignsToGroup.
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.

/* Owner History instances */
#2=IFCOWNERHISTORY( .. );

/* Element definitions */
#1012=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1012', #2, $, $, $, $, $, $);
#1013=IFCFLOWCONTROLLER ('abcdefghijklmnopqrs1013', #2, $, $, $, $, $, $);
#1014=IFCFLOWTERMINAL ('abcdefghijklmnopqrs1014', #2, $, $, $, $, $, $);
#1015=IFCFLOWCONTROLLER ('abcdefghijklmnopqrs1015', #2, $, $, $, $, $, $);
#1016=IFCFLOWSEGMENT ('abcdefghijklmnopqrs1016', #2, $, $, $, $, $, $);

/* System definitions */
#2011=IFCSYSTEM ('abcdefghijklmnopqrst2011',#2,'SchedulingGroup', $,'SubSystem');
#2012=IFCSYSTEM ('abcdefghijklmnopqrst2012',#2,'CodeComplianceGroup', $,'Subsystem');
#2013=IFCSYSTEM ('abcdefghijklmnopqrst2013',#2,'FabricationGroup', $,'Subsystem');

/* Assignment of Elements to Systems */
#3001=IFCRELASSIGNSTOGROUP ('abcdefghijklmnopqrst3001',#2,$,$,(#1012,#1013,#1014,#1015,#1016),.PRODUCT.,#2001);
#3002=IFCRELASSIGNSTOGROUP ('abcdefghijklmnopqrst3002',#2,$,$,(#1012,#1013,#1014,#1015,#1016),.PRODUCT.,#2002);
#3003=IFCRELASSIGNSTOGROUP ('abcdefghijklmnopqrst3003',#2,$,$,(#1012,#1013,#1014,#1015,#1016),.PRODUCT.,#2003);

Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.1.3 Build:#408 Jan 23, 2006) - Bug/feature request - Contact Administrators