All entities having semantic significance derive from IfcRoot, where instances are identifiable within a data set using a compressed globally unique identifier (IFC-GUID). This identifier must never change during the lifetime of an object, which allows data to be merged, versioned, or referenced from other locations.

Resource-level instances (not deriving from IfcRoot) do not have any identity, such that two instances having identical state are considered equal. For example, if an object has coordinates described by an IfcCartesianPoint instance, another object with the same coordinates may have a separate instance of IfcCartesianPoint or share the same instance; such difference is a matter of data storage optimization and does not imply any semantic relationship. This also implies that non-rooted instances may only exist if referenced by at least one rooted instance through either a direct attribute or inverse attribute, or following a chain of attribute references on instances.

The distinction between rooted and non-rooted (resource-level) entities achieves several goals:

  • File size may be reduced by interning (sharing) non-rooted data instances;
  • Database retrieval may be more efficient by storing non-rooted data local to rooted data instances;
  • Storage size may be reduced by avoiding IFC-GUID storage for items not requiring direct retrieval;
  • Comparisons of differences may be done at a higher level where the context of such change is apparent;
  • Implementations may treat non-rooted data instances as immutable for efficiency or simplified usage.
]]>
An object needs to be identifiable for accurate processing by both human and automated processes. Identification may be through several attributes such as Identification, Name, or GUID. The GUID is compressed for the purpose of being exchanged within an IFC data set - the compressed GUID is refered to as "IFC-GUID". While the IFC-GUID is normally generated automatically and has to be persistent, the Identification may relate to other informal registers but should be unique within the set of objects of the same type. The Name and Description should allow any object to be identified in the context of the project or facility being modelled.

Various objects may have additional identifications that may be human-readable and/or may be structured through classification association.

Various file formats may use additional identifications of instances for serialization purposes, however there is no requirement or guarantee for such identifications to remain the same between revisions or across applications. For example, the IFC-SPF file format lists each instance with a 64-bit integer that is unique within the particular file.

]]>
While objects may reflect a final state, they may also be continually revised over the course of a project lifecycle and reflect transient state. For scenarios of multiple users making updates to the same information, there is a concept of local copies of information based upon a shared repository supporting multiple users. Such shared repository is often referred to as a model server. A model server is similar in concept to a document revision server, but is able to identify changes declared on a per-object basis rather than inferring changes from differences in text. A model server has a concept of revisions on a per-project basis, where each revision consists of a set of changes to contained objects by a particular user at a particular time.

To support a model server scenario, each object may be marked with a change action indicating the object was added, modified, deleted, or has no change since the project was retrieved from the server at a particular revision sequence. Given an object's identity (IFC-GUID) and change action, the state of the object may be merged when submitted to a model server. An object is considered modified when any of its direct attributes change, attributes on a referenced resource definition (any entity not deriving from IfcRoot) change, items are added or removed from sets, or items are added, removed, or reordered within lists.

For cases when multiple users make conflicting changes to the same objects, users may choose to keep their own changes, accept changes from others, merge both changes, or a combination thereof upon submitting to a server. Alternatively, to avoid such merge scenario and coordinate work, objects may be locked such that a particular user has exclusive access to read and/or write a particular object at the current time.

Project libraries may also be retrieved from model servers having particular revision, and potentially different server URI than the referencing Project. As a project may include multiple revisions of the same project library (a common scenario when multiple users are involved using libraries revised by others), the IfcRoot.ObjectIdentifier IFC-GUID is only valid within the scope of the referencing project, and a separate library reference identifies a project library based object within its originating model server.

Finally, objects may also carry informational attributes indicating when an object was created, who, when, and what application was used to last modify an object, and who currently owns the object, potentially having exclusive use according to its lock state.

]]>
Objects may have descriptions included to aid in human identification of the object.

]]>
All files contain a single IfcProject instance indicating overall context and a directory of objects contained within.

]]>
The project provides a directory of objects contained within using declaration relationships.

]]>
The project context includes the definition of the default units within the IFC data set. Default units are those units that apply:

  • to all geometric representation items within the geometric representation contexts;
  • to all attributes with a defined datatype indicating a measure datatype;
  • to all properties and quantities with a defined datatype indicating a measure datatype and with no local unit definitions provided.
]]>
SI units are defined according to standard prefix and standard name.

]]>
Conversion units are defined according to a conversion factor (and conversion offset for temperature) relative to a specified base SI unit.

]]>
A project representation context indicates the coordinate system orientation, direction of true north, precision, and other values that apply to all geometry within a project or project library.

]]>
Projects may define classification structures, which may be used to classify objects contained within the same project, or other referencing projects (incorporating the current project as IfcProjectLibrary.

]]>
Projects may define external documents, which may be used to attach arbitrary information to objects contained within the same project or referencing projects.

]]>
Projects may define libraries holding revisions of the project such as model servers or databases. Multiple libraries may be referenced to indicate multiple revisions, multiple branches, and/or multiple servers.

]]>
Objects, type objects, properties, and some resource schema entities can be further described by associating references to external sources of information. The source of information can be:

  • a classification system;
  • a dictionary server;
  • any external catalogue that classifies the object further;
  • a service that combine the above features.

An individual item within the external source of information can be selected. It then applies the inherent meaning of the item to the object or property.

]]>
Any object or property can have associated documents indicating external files. Documents may be referenced in their entirety such as to capture product brochures, data sheets, multimedia content, or thumbnail images. Contents within documents may be referenced from any object, and may be used to synchronize information in other files such as work schedules for project management applications.

]]>
Any object, type object, property, and some resource schema entities can have associated library entities indicating the source of data such as from a model server or product library, or simply enriching the data with more details. Libraries may be referenced in their entirety from projects or project libraries indicating the master source and version of data. Contents within libraries may be referenced from any object, type object, property, and some resource schema entities within a project or project library.

]]>
Any object or property can have associated approvals indicating who is required to approve the data, the status of whether it has been approved, and the date/time of such approval. Approvals may require multiple parties fulfilling various roles.

]]>
Any object or property may have associated constraints indicating a qualitative objective or a quantitative metric to be met.

Constraints based on metrics are measurable, such that the status of a metric being valid is computer-interpretable. Metric constraints are based on simple conditional logic such as greater than a particular value or included within a specified list or table. Constraints may be combine multiple metrics using boolean logic such as AND, OR, XOR, or NOT.

]]>
The constraint model may be used to indicate mappings between data in the IFC model and external documents. This concept template may also be used by software applications to translate data to/from spreadsheets without necessarily instantiating constraint relationships within an IFC data set.

To indicate an explicit mapping to a particular file or database, IFC classes may be mapped to tabular data formats using IfcResourceConstraintRelationship attached to IfcDocumentInformation.

Default mappings may be indicated using the IfcRelAssociatesConstraint relationship, with RelatingConstraint pointing to IfcObjective.

An IfcObjective of type EXTERNAL has ConstraintSource set to the name of the IFC entity (e.g. 'IfcSpace') with Benchmarks containing a single IfcMetric with DataValue set to an IfcTable. On IfcTable, the Name is set to the name of the external database table or worksheet, and the Columns attribute indicates the external table columns in order as IfcTableColumn. For each IfcTableColumn, the Name indicates the field name or column header, and the ReferencePath identifies the corresponding object attribute, for which standard mappings are indicated.

Within this document, attribute paths (as used for IfcReference) are encoded using syntax in the form 'IfcSpace.OwnerHistory\IfcOwnerHistory.CreationDate' with the following conventions:

  • The period character dereferences an attribute from an entity.
  • The backslash character casts an entity into a subtype, where a backslash without a subtype indicatings mapping to the type itself.
  • A bracket sequence with an asterisk ("[*]") dereferences a collection into each member.
  • A bracket sequence with an encoded string (e.g. "['SerialNumber']" dereferences a collection into a specific member by name.

Upon import from a spreadsheet, tables shall be identified by worksheet name regardless of order, and columns shall be identified by header name regardless of order. For export to a new spreadsheet, worksheets shall be provided with identifying name for each entity and sequenced in the order specified, and within each worksheet a header row shall be provided with with each column having an identifying name and sequenced in the order specified.

Attributes are mapped to spreadsheet cells, where either NULL, an empty string, or the reserved value 'n/a' indicates a null value. Specific base types are mapped as follows:

  • STRING: String types are represented as strings.
  • REAL: Real number types are represented as real numbers.
  • ENTITY Entity references are represented as strings identifying by name (IfcRoot.Name).
  • SET Set-based collections are represented as strings identifying each object by name and separated by a comma.

Specific mappings are defined at corresponding entities, where the following standard column names are used:

  • Name: Indicates the name of the object, corresponding to IfcRoot.Name.
  • ExtObject: Indicates the IFC type of the object by identifying the IFC entity by name (e.g. 'IfcBoiler'). If omitted upon import, the IFC entity shall be the base type where the concept is indicated (if non-abstract); otherwise no entity shall be imported.
  • ExtSystem: Indicates the application that currently owns the object, mapping to IfcApplication.ApplicationIdentifier.
  • ExtIdentifier: Indicates the GUID of the object encoded in the same format described at IfcGloballyUniqueId, mapping to IfcRoot.GlobalId. If omitted upon import, such GUID shall be constructed dynamically. If merging changes upon import, such identifier shall be used to identify an existing object (i.e. this maintains identity if an object is renamed (the Name attribute changing).
]]>
Constraints may be applied to type definitions for indicating parametric dependencies.

]]>
Value=PARAMETRIC
Value=REQUIREMENT This template enables a tabular representation of items that may be used to validate the building model and/or automatically generate requirement elements within the building model.

Tables may be used for various scenarios, such as available configurations of product types, equipment schedules, and mappings to tabular data formats.

]]>
Any product or product type can have associated materials indicating the physical composition of an object. Materials can have representations for surface styles indicating colors, textures, and light reflectance for 3D rendering. Materials can have representations for fill styles indicating colors, tiles, and hatch patterns for 2D rendering. Materials can have properties such as density, elasticity, thermal resistance, and others as defined in this specification. Materials can also be classified according to a referenced industry standard.

An object can be comprised of a single material or a set of materials with a particular layout. Several examples include:

  • a slab may have an associated layer of concrete;
  • a beam may have an associated I-Shape profile of steel;
  • a door may have associated constituents for framing and glazing;
  • a port may have an associated profile and/or material flowing through it such as hot water.
]]>
Materials are directly associated with products and product types to indicate a uniform material for the entire object.

]]>
Material layer sets are associated with product types to indicate a parametric specification of layers having specified thickness filling a boundary defined on occurrences of the type. Examples of such product types are slabs, walls, and plates.

]]>
Material layer set usage defines layout at occurrences to indicate a direction and offset from the 'Axis' reference curve, and a reference extent such as for a default wall height.

]]>
Material profile sets are associated with product types where materials are placed in cross-sections of specified dimensions following a path defined at occurrences of the type. Examples of such products are beams, columns, members, reinforcing, footings, piles, pipe segments, duct segments, and cable segments.

]]>
Material profile set usage defines layout at occurrences to indicate the offset from the 'Axis' reference curve according to cardinal point, and a reference extent such as for a default column height.

]]>
Material constituents are associated with products where materials are placed arbitrarily (unlike 1D material profiles or 2D material layers). The mapping of materials to geometry may be accomplished using IfcShapeAspect.

]]>
Object Occurrences may be defined by a particular Object Type, where such type describes common characteristics. Such characteristics include common properties, shapes, materials, composition, and other concepts described at particular entities. An object occurrence may have similar state as its object type, overridden state for particular characteristics, or have no defined type object.

A pair of entities are defined for various object occurrences and object types, where such object occurrence entity may only be defined using a particular object type entity. For example, the IfcTank occurrence object entity has a corresponding IfcTankType type object entity.

Many object occurrence and object type entities have an attribute named PredefinedType consisting of a specific enumeration. Such predefined type essentially provides another level of inheritance to further differentiate objects without the need for additional entities. Predefined types are not just informational; various rules apply such as applicable property sets, part composition, and distribution ports.

For scenarios of object types having part compositions, such parts may be reflected at object occurrences having separate state. For example, a wall type may define a particular arrangement of studs, a wall occurrence may reflect the same arrangement of studs, and studs within the wall occurrence may participate in specific relationships that do not exist at the type such as being connected to an electrical junction box.

]]>
The concept template Property Sets describes how sets of properties (usually defined by a name, value, unit triple) are associated to objects or object types.

]]>
Any specialization of object can be related to multiple property set occurrences. A property set contains multiple property occurrences. The data types of property occurrences are single value, enumerated value, bounded value, table value, reference value, list value, and combination of property occurrences.

]]>
For object types, property sets are defined directly.

]]>
For performance history, properties are in the form of time series, for tracking data at points in time.

]]>
Properties on occurrences may be required to be present for specific information exchanges.

Constraints may be attached to property sets to enforce conformance of the building model to indicated values. The associated IfcObjective has its type set to DESIGNINTENT to indicate that any nonconforming value should be flagged accordingly but not necessarily automatically updated as is done for other types such as PARAMETRIC. The IfcObjective contains one or more IfcMetric items corresponding to each IfcProperty that is constrained, where IfcMetric.ValueSource corresponds to IfcProperty.Name. The IfcMetric.ReferencePath identifies the attribute on related objects (IfcRelDefinesByProperties.RelatedObjects) that is to be checked, where the reference path is relative to the associated object, in this case the IfcPropertySet.

Within this document, attribute paths (as used for IfcReference) are encoded using syntax in the form 'IfcSpace.OwnerHistory\IfcOwnerHistory.CreationDate' with the following conventions:

  • The period character (".") dereferences an attribute from an entity.
  • The back slash character ("\") casts an entity into a subtype, where a backslash without a subtype indicatings mapping to the type itself.
  • The forward slash character ("/") filters an entity according to its PredefinedType.
  • A bracket sequence with an asterisk ("[*]") dereferences a collection into each member.
  • A bracket sequence with an encoded string (e.g. "['SerialNumber']" dereferences a collection into a specific member by name.

Constrained values are interpreted as follows:

  • IfcBoolean: checks for the presense of one or more matching elements, where True indicates one or more exist, and False indicates none exist.
  • IfcInteger: checks for the count of elements, where the number indicates the quantity of matching elements found.
  • IfcValue: for all other value types such as labels or measure values, checks for matching value.
]]>
Value=DESIGNINTENT
Properties may be defined for materials indicating physical characteristics.

]]>
Properties may be defined for profiles indicating custom parameter-driven shapes.

]]>
Any specialization of object can be related to multiple quantity set occurrences. A quantity set contains multiple quantity occurrences. The data type of quantity occurrence are count, length, area, volume, weight, time, and combination of quantity occurrences.

]]>
Any specialization of object can be related to multiple quantity set occurrences. A quantity set contains multiple quantity occurrences. The data type of quantity occurrence are count, length, area, volume, weight, time, and combination of quantity occurrences.

]]>
Property set templates describe extensible parameters that may be configured on objects. Each property is identified by name, and indicates data type and access mode.

]]>
Many object occurrence and object type entities have an attribute named PredefinedType consisting of a specific enumeration. Such predefined type essentially provides another level of inheritance to further differentiate objects without the need for additional entities. Predefined types are not just informational; various rules apply such as applicable property sets, part composition, and distribution ports.

]]>
Objects may provide services to other objects, where the "assigned from" object acts upon or observes requirements of the "assigned to" object. There is a general cycle of assignments where actors (people) issue controls (such as work orders or schedules), which may result in groups (such as building systems) comprised of products (such as building elements) operated upon by processes (such as construction tasks) performed by resources (such as labor) which may in turn be fulfilled by actors (people). Requirements are established at the "to" side and are fulfilled at the "from" side, where costs, time, scope, or other metrics may be calculated in the "from-to" direction.

]]>
Actors may have assignments indicating objects for which they have responsibility. An example of such assignment is a work order assigned to an organization.

]]>
Controls may have assignments indicating objects that must observe the established requirements. An example of such assignment is a labor resource assigned to a calendar.

]]>
Groups may have assignments indicating products that are members of the group. An example of such assignment is an air handler belonging to an air conditioning system.

]]>
Products may have assignments indicating processes that operate upon the product. An example of such assignment is a task to construct a wall.

]]>
Processes may have assignments indicating resources consumed or occupied by the process. An example of such assignment is a carpenter labor resource building a wall.

]]>
Resources may have assignments indicating sources available to be used. An example of such assignment is a person fulfilling a carpenter labor resource.

]]>
Product types may have assignments indicating re-usable process types for which occurrences may operate on occurrences of the product type. An example of such assignment is a task type for placing concrete in slabs on grade.

]]>
Process types may have assignments indicating re-usable resource types for which occurrences may be consumed or occupied by occurrences of the process type. An example of such assignment is a concrete mixer resource type for delivering concrete.

]]>
Resource types may have assignments indicating re-usable product types for which occurrences may be sourced by occurrences of the resource type. An example of such assignment is a particular crane model that may be used for a crane equipment resource used for erecting steel.

]]>
Objects may be assigned to actors indicating the actor demands services of the object. Specific semantics are defined at concepts.

]]>
Objects may be assigned to controls indicating the control demands services of the object. Specific semantics are defined at concepts.

]]>
Objects may be composed into parts to indicate levels of detail, such as a building having multiple storeys, a framed wall having studs, or a task having subtasks. Composition may form a hierarchy of multiple levels, where an object must have a single parent, or if a top-level object then declared within the single project or a project library.

]]>
Aggregation indicates an unordered part composition relationship.

Aggregation is used on building elements to indicate parts such as studs within a wall.

Aggregation is used on systems to indicate subsystems such as branch circuits.

]]>
Provision of an aggregation structure where the element is part of another element representing the composite. The part then provides, if such concepts are in scope of the Model View Definition, exclusively the following:

  • Body Geometry — The partial body shape representation and its placement;
  • Material — The material information for the part.

The part may also provide, in addition to the aggregate, more specificly the following:

  • Property Sets — The parts may have individual property sets assigned, solely or in addition to the composite;
  • Quantity Sets — The parts may have individual quantity sets assigned, solely or in addition to the composite.

The part should not be contained in the spatial hierarchy, i.e. the concept Spatial Containment shall not be used at the level of parts. The part is contained in the spatial structure by the spatial containment of its composite.

EXAMPLE  An IfcBeam may be aggregated into an element assembly using the objectified relationship IfcRelAggregates, refering to it by its inverse attribute SELF\IfcObjectDefinition.Decomposes. Any subtype of IfcElement can be an element assembly, with IfcElementAssembly as a special focus subtype. In this case it should not be additionally contained in the spatial hierarchy, i.e. SELF\IfcElement.ContainedInStructure should be NIL.
]]>
Provision of an aggregation structure where the element, representing the composite, is decomposed into parts represented by other elements.

The composite then provides, if such concepts are in scope of the Model View Definition, exclusively the following:

  • Placement — the common object coordinate system to which the parts are placed relative

By default the following constraints apply to an element being decomposed by Element Decomposition:

  • Body Geometry — composite is constructed from the sum of the Body Geometry of the parts;
  • the composite shall not have an own Body Geometry, body geometry is provided at the parts;
  • the composite shall not have an own Material assignment, material is assigned to the parts.
]]>
Provision of a spatial structure of the project by aggregating spatial structure elements. The spatial structure is a hierarchical tree of spatial structure elements (site, building, storey, space) ultimately assigned to the project. Composition refers to the relationship to a higher level element (e.g. this storey is part of a building).

The order of spatial structure elements being included in the concept are from high to low level: IfcProject, IfcSite, IfcBuilding, IfcBuildingStorey, IfcSpace. Therefore an spatial structure element can only be part of an element at the same or higher level.

]]>
Provision of a spatial structure of the project by aggregating spatial structure elements. The spatial structure is a hierarchical tree of spatial structure elements (site, building, storey, space) ultimately assigned to the project. Decomposition refers to the relationship to lower level elements (e.g. this storey has spaces).

The order of spatial structure elements being included in the concept are from high to low level: IfcProject, IfcSite, IfcBuilding, IfcBuildingStorey, fcSpace. Therefore an spatial structure element can only has parts of an element at the same or lower level.

]]>
Elements may have voids defined, which may be partial recess or extending full depth. Voids for openings may optionally be filled by another element such as a door or window.

]]>
Nesting indicates an ordered arrangement relationship.

Nesting is used on building elements to indicate features placed in sequence such as ports.

Nesting is used on control objects to indicate specification hierarchies.

Nesting is used on process objects to indicate subordinate task details.

Nesting is used on resource objects to indicate subordinate resource allocations.

]]>
Ports indicate possible connections to other objects according to specified system types, flow direction, and connection properties. Ports are typically connected between devices via cables, pipes, or ducts.

Ports may have placement defined indicating the position and outward orientation of the port relative to the product or product type.

Ports may have material profile sets defined indicating the flow area and connection enclosure.

]]>
Ports may be specified on types, following the same rules as defined for corresponding occurrences.

]]>
Objects may participate in various connectivity relationships with other objects.

]]>
Spatial structures, such as site, building, storey, or spaces, may contain physical elements, including building elements, distribution elements, and furnishing elements. The containment relationship between the physical elements and the spatial structures is hierarchical, i.e. a physical element shall only be contained within a single spatial structure.

EXAMPLE  An IfcBeam is placed within the spatial hierarchy using the objectified relationship IfcRelContainedInSpatialStructure, refering to it by its inverse attribute SELF\IfcElement.ContainedInStructure. Subtypes of IfcSpatialStructureElement are valid spatial containers, with IfcBuildingStorey being the default container.

The spatial containment relationship, together with the Spatial decomposition relationship, being hierarchical as well, establishes the hiearchical project tree structure in a building information model.

EXAMPLE  The IfcBuildingStorey that logically contains the IfcBeam decomposes the IfcBuilding using the IfcRelAggregates relationship. Therefore the IfcBeam is also indirectly contained in the building.
]]>
The Spatial Container concept defines a spatial structure element as being the spatial container for physical elements, such as building elements, distribution elements, or furnishing elements.]]> Spatial structures may contain physical elements, including building elements, distribution elements, and furnishing elements.

]]>
Spaces may have boundaries defined by building elements such as walls, slabs, doors, and windows. Such information may be used to determine heat transmission through surrounding materials.

]]>
Elements may be connected to other elements, where the RelatingElement is of equal or higher priority, is generally constructed first, and/or anchors the RelatedElement.

]]>
Elements based on an 'Axis' representation such as walls, beams, and columns use a path connectivity relationship to indicate parameters for the connection, indicating which side takes precedence for material layers or profiles.

]]>
Ports on objects may be connected using elements such as cables, ducts, or pipes.Once Components within a System has some ports, then the connectivity should be complete and continuous. The presence of ports for air, water and electrical connections on complex equipment does not imply that all such connectivity is expected: only that if for example the HVAC segments and fittings have ports, then they will need to connect properly to the equipment's air ports.

]]>
At least two ports may be expected on duct segments.

]]>
At least one port is expected on duct fittings

]]>
All ports are to be twinned with a complementary port on another Component

]]>
Ports on objects may be connected using elements such as cables, ducts, or pipes.Once Components within a System has some ports, then the connectivity should be complete and continuous. The presence of ports for air, water and electrical connections on complex equipment does not imply that all such connectivity is expected: only that if for example the HVAC segments and fittings have ports, then they will need to connect properly to the equipment's air ports.

]]>
Control elements (such as sensors) that monitor or control behavior of flow elements (such as valves) use this relationship to indicate control flow logical behavior.

]]>
Elements such as doors and windows may be placed inside openings of walls, slabs, or other elements.

]]>
Processes that occur in time use this relationship to indicate the order of occurrence, such as for tasks, procedures, and events.

]]>
Elements may interfere with other elements, such as cable carriers going through walls. The interference relation enables precedence of interfering elements to be asserted.

]]>
Spaces may have coverings applied to fill surrounding flooring, walls, ceilings, or other aspects parametrically.

]]>
Elements may have voids defined, which may be partial recess or extending full depth. Vodis for openings may optionally be filled by another element such as a door or window.

]]>
Contact information indicates roles and addresses of people and organizations.

]]>
Project participants are indicating using IfcActor. The Name must indicate a human-readable unique identifier of the actor, such as their email address, which enables automatic association of authoring information based on login credentials.

]]>
Tasks may be scheduled to run continously, at a single period in time, or multiple recurring periods in time.

]]>
Events may indicate whether they represent the start of a condition, intermediate status of a condition, or exiting of a condition.

]]>
Events may be scheduled to be raised at particular intervals or handled upon particular conditions.

]]>
The Facilities Management Handover 2013 Edition supports information exchanges for construction and operations.

The following changes have been made in this release:

  • Concepts have been made refactored to be consistent with IFC4, BPie, HVACie, SPARKie, and WSie.
  • Extended property sets have been defined for all fields mapped in spreadsheets, with enumerations included where applicable.
  • Spreadsheet mappings now indicate which fields are to be used as primary keys.
  • Spreadsheet mappings now indicate colors to use for formatting fields.
  • Material constituents and property set templates removed for IFC2x3 compatibility.
  • Entities and attributes that are out of scope are now filtered out of generated schemas.
  • Assemblies for replaceable components are now mapped to connectivity relationship for IFC compatibility.
  • Change logs now filtered to show IFC2x3-IFC4 differences within scope of the model view.
]]>
This exchange includes high-level criteria specific to the building to be constructed, but without regard for particular disciplines.

]]>
This exchange includes discipline-specific criteria, indicating scope and function of building systems and distribution systems.

]]>
This exchange includes initial project information to describe a project and its contents.

]]>
This exchange includes requirements for the spatial layout of a building.

]]>
This exchange includes requirements for physical components of a building.

]]>
This exchange includes building layout information and allocation of products without regard for placement.

]]>
This exchange includes building layout information and allocation of products with placement and connectivity.

]]>
This exchange includes building layout information and allocation of products with placement, connectivity, and assignment to systems and project participants.

]]>
This exchange includes final design information with formal documents, and amended with design issue requests and responses.

]]>
This exchange includes definitions of properties to be captured by product templates.

]]>
This exchange includes product type information for specific product models provided by manufacturers.

]]>
This exchange includes bid submission information with formal documents, and amended with bid issue requests and responses.

NOTE  The IfcActionRequest entity captures all reported issues (or requests to do something), for which tasks may be assigned to carry out work to address an issue.
]]>
This exchange includes product type information for product models selected to be used, without regard for particular placement.

NOTE  Product types may be declared within a project without having any occurrences in IFC4. Project composition excluded (no placeholder building is necessary). Project libraries added (to provide link to originating property set templates).
]]>
This exchange includes detailed system connectivity information for building systems and distribution systems.

]]>
This exchange includes product placement information, including serial numbers at specific installations.

]]>
This exchange includes product inspection issues reported, which may require replacement of installed products.

]]>
This exchange includes construction issues reported, which may require additional labor.

]]>
This exchange includes product part information, which may be used for addressing components for connectivity or replacement.

NOTE  IFC4 allows product types to have assigned process types and resource types, which may indicate standard processes (i.e. manufacturer-defined) for servicing or replacing parts.
]]>
This exchange includes product warranty information for parts and labor.

]]>
This exchange includes product maintenance information, including expected maintenance tasks and procedures.

]]>
This exchange includes system operation information, including system operation procedures and events.

]]>
This exchange includes reporting on the condition of spaces over time.

NOTE  In IFC4, all time-phased information is captured using performance-based properties on IfcPerformanceHistory. This allows for data to be recorded for multiple time periods (avoiding the single property set restriction), and to provide a uniform way of accessing and rendering time-phased data such that software applications need not be aware of particular properites. A property set should be defined for recording space conditions over time.
]]>
This exchange includes reporting on the replacement of product parts over time.

NOTE  In IFC4, the process and resource model has been formalized, such that replacement of parts may be considered as a MAINTENANCE task with assigned resources for materials, labor, equipment, products, crews, subcontracts.
]]>
This exchange includes scheduling occupancy of spaces over time.

]]>
This exchange includes scheduling reconfiguration of spaces over time.

]]>
This exchange includes changing the building layout of an existing structure.

]]>
This exchange includes expanding the building layout of an existing structure.

]]>
This exchange includes demolishing an existing structure partially or in full.

]]>
A space represents an area or volume bounded actually or theoretically. Spaces are areas or volumes that provide for certain functions within a building.

The volume of a space excludes coverings; the vertical dimensions start from the top of the slab below and extend to the bottom of the slab above (excluding floor coverings or dropped ceilings), and the horizontal dimensions are bounded by the extents of walls and columns (excluding coverings such as drywall). The volume of a room, however, is bounded by such coverings, and may be derived by substracting such dimensions and indicated as the NetVolume quantity.

]]>