The future and the d4SU Platform
d4SU Platform Context
The future, driven by the so much needed Digital Transformation will call for a Platform that provide a consistent access to and management of reference technical data for Buildings and Infrastructure.
This is what the d4SU Platform is aiming at.
The diagram above add a few items to the previous one:
| Item | Description |
|---|---|
| d4SU | A platform that provides technical support to the handling of IFC files for validation, filtering and extraction of relevant data for spatial units. The d4SU Platform is focused on being an enabler and not a replacement for dedicated business solutions. This documentation site provides information on the architecture, the data model and initial features of d4SU. As usual, all aspects are subjects to change, with the notable exception of its adherence to the KISS principle: simplicity comes first! |
| Data for Spatial Units | The LCA, BAMB, EPC, DBP, 3DC, REM, PRA, DBL, ... domains require specific construction data. With increasing standardization, formal API will probably emerge. API, whether standardized or custom are all collectivelly referred to as Data for Spatial Units. |
| Data Dictionary | A set of international and national reference data for construction, engineering and operations. The set includes the buildingSMART Data Dictionary (bSDD) which is a collection of interconnected data dictionaries with definitions of terms to describe the built environment. The service is provided by buildingSMART for free, to enable easy access from all software solutions. The content is published by independent organisations, spanning international classifications, national standards and company-specific agreements. Source buildingSamrt The set also includes - generally speaking - business relevant structured data that can be unambiguously referenced by all parties. This includes Mechanical, Electricity and Plumbing (MEP) Nomenclature not included in bSDD |
| IFC | Industry Foundation Classes (IFC) are a set of standardized, digital descriptions of the built asset industry. It is an open, global standard published under a Creative Commons license, and as ISO 16739. IFC provides machine interpretability of information and thereby enables automation of workflows. It is vendor-neutral and available to everyone. Source buildingSmart At its heart, an IFC file includes several components that define the structure and data included in the file. The IFC schema not only captures geometric data and material properties but also includes how different elements relate to each other. This structured approach ensures an accurate depiction of the built environment. Here’s what each component entails: - Entities: these are the core building blocks that represent objects or elements in the model. Think of examples like ‘IfcDoor’ or ‘IfcWall’. - Attributes: detailed properties of an entity, such as materials, dimensions, and so on, offering an in-depth view of the components. For example, an ‘IfcDoor’ may include an attribute such as ‘OverallHeight’. - Relationships: the IFC model maps out how different entities interact and depend on each other. Inheritance: model entities can inherit properties from parent entities. This helps create a hierarchical and modular data structure. - Property Sets (Psets): this relates to groups of properties that are attached to an entity, e.g. ‘Pset_WallCommon’, which could include properties like acoustic performance for walls or the fire rating. Source BimCollab |
| IDS | Information Delivery Specification (IDS) is a buildingSMART standard for defining information requirements in a computer interpretable form. It allows for automatic compliance checking of IFC models, that increases quality control and fidelity of data. IDS also aids the efficient delivery of the data, by setting the expectations and providing clear guidelines of what needs to be exchanged. A user of IDS can specify how objects, classifications, materials, properties, and even values should be delivered in an IFC model. Source buildingSmart. There is an excellent presentation of IDS by Léon van Berlo CTO of buildingSmart. |
| BCF | The BIM Collaboration Format (BCF) is an open standard for managing issues on a BIM project. BCF is an international openBIM standard, developed and maintained by buildingSMART International. BCF is available in many BIM software tools. There are two different ways to utilize BCF – via a file-based exchange or via a web service. The BCF-API supports the exchange of BCF issues between software applications via a RESTful web interface, which means that data is exchanged via HTTP query parameters and JSON bodies. Every resource described in this API has a corresponding JSON schema. Source buildingSmart. |
From Requirements to Validated Data for Spatial Units
Industry and Public Sector initital coordination
-
The first step is the identification of what is needed and of the required 'semantic content' to be provided for each of the domains, i.e. for LCA, BAMB, EPC, DBP, 3DC, REM, PRA, DBL, and others as appropriate. In other words, it is essential to define the collection of sources that will compose the Data Dictionary and ensure that appropriate data format is machine-readable.
-
Thereafter, objects and property set are listed for all domains so that the IDS files can be build. There are numerous options for creating the IDS files given that since 2022 most actors in the AECO insdustry have adopted IDS and have either a free or paying version of an IDS editor. As appropriate to the use case several IDS files can be consolidated.
-
Appropriate IDS are made available to the AECO professionals. They are, for the domains at hand (LCA, BAMB, ...), not specific to a particular construction instance and relativemly stable over time.
-
Mapping can be configured in the AECO Tool to cater for a corresponding export template.
The industry is making tremendous progress on this process
For instance, BIMids, which is a join effort of Buildwise (Belgium) and CRTI.B (Lu) provides a suite of IDS across construction disciplines and stages and also corresponding configurations for Archicad and Revit.
Execution: IDS, IFC, BCF
- For each project, the appropriate IDS is used and corresponding data are generated/exported by the AECO tool. The exported file is validated against the IDS.
- The IFC is submitted via a portal & integration plaform.
- A validation process is started in the d4SU platform. This is a double check as the validation would normally be run at the AECO side prior to submission.
- If errors are found, a BCF report of issues is provided to the sender otherwise, processing continue. While BIM Collaboration Format (BCF) is by default available, other formats such as json and html are supported.
Execution: Other processes
Further processing can be applied to secure that all needed information is provided to the Admin Tool handling the domain (LCA, BAMB, EPC, DBP, ...). This is typically done in the d4SU platform.
Needed Features
The list of features cited hereunder is not complete and is no substitute for proper domain requirements to be established by domain experts.
For the domains hereunder, the features required are mostky the capability the verify the presence and capture the value of:
- Elements such as sites, buildings, storeys, spaces, and product containment for walls, slabs,... and distribution elements
- Relationships that links those elements (aggregation, containment, boundary,... )
- Propertysets (Pset) - Almost all needed metrics & characteristics can be captured in Psets
- Geometry, often in basic form (location & orientation, dimensions) that can be captured by a bounding box, while detailed 3D geometry (which may be quite complex) is required for realistic visualization but not for efficiency values computation and is often not present at all in curent data of public admin tools.
| Domain | Features |
|---|---|
 |
Psets need to be defined and verified for materials linked to Environment Product Declarations (EPDs) with defined Global Warming Potential (GWP) and with corresponding volume, weight and area measures. As a minimum for construction components, but can be extended to MEP components. IDS comes as primary support to express and verify the information requirements. BIMids provides IDS files for LCA which are partial but already relevant. |
 |
Also Psets for construction materials and MEP, but also for elements assemblies. |
 |
Again, most or all can be expressed as Psets on elements (construction & HVAC). When EPC are needed for Building Units and depend on the occupancy type, it is needed to assign spaces to distinct Spatial Units. Hence, Spaces or Spatial Zone information requirement must be embodied in the IDS or handled in another way. BIMids provides IDS files for EPC (denoted PEB) which are partial but already relevant. For the EPC calculation, the IFC model will provide a lot of information via the spaces and their space boundaries, with their connection geometry and the properties of connected walls, slabs, windows, doors, ... Also, the distribution elements will provide the required HVAC data. |
 |
A whole lot of requirements can be met on the basis of Psets as done for the Digital Building Permit in Finland. However, there are other requirements that refers to neighboring constructions and may require geometry processing, including sight from windows on neighboring private inner spaces. BIMids provides IDS files for DBP which are partial but already informative. |
 |
Cadastre has requirements that can be captures by Psets but aso quite a number of requirements that require geometry processing. One specific aspect is the conversion from local coordinates to geodetic ones (WGS 84 or other). BIMids provides IDS files for 3DC (Vertical Cadastre of Luxemburg) which are partial but already relevant. |
 |
Real-Estate Management will also mostly require appropriate Psets, some of them simply grounded on Facility Management Psets. |
 |
Again, most if not all needed data are contained in the elements tree and Psets. |
 |
Again, most if not all needed data are contained in the elements tree and Psets for Construction and HVAC elements. |
A more detailed context diagram
On the next diagram 'links' are better rendered without darkmode
block-beta
columns 4
block:actors:4
columns 4
aeco_a(("AECO roles<br /> <br />Architects, Engineers, Builders<br /> <br />Facily Managers"))
advisor_a(("Constituent<br />and/or Advisory & Technical <br />Expert roles"))
admin_a(("Public Service roles<br /> <br />Agents, Inspectors, Domain<br />Experts"))
end
block:systems:4
columns 4
aeco_sys["Architecture<br />Engineering<br />Construction<br />Facily Management"]
tep_sys["Technical encoding & processing <br />for permits, autorizations and <br />certificates<br />with API to d4SU"]
case_sys["Constituent Portal<br />Case Management<br />Licensing & Permitting"]
admin_sys["Licenses, Permits, Certificates<br />Land Administration (LADM)<br />Digital Building Logbook (DBL)"]
end
block:references:4
ids_ref((("Information Delivery<br /> Specifications <br />IDS's")))
datadict_ref(((" Data Dictionary: <br />bSDD, ...")))
end
block:db:4
columns 4
aeco_db[("<br />AECO<br />Architecture, Engineering,<br /> Construction & Operation<br />Data")]
pointcloud_db[("<br />Point Cloud")]
case_db[("<br />Public Service<br />CRM<br />Case Management DB")]
admin_db[("<br />Cadastre, Environment,<br />Housing, Infrastructure,<br /> City Urban Administraion DB")]
end
block:int:4
columns 4
aeco_int(["<br /> <br />AECO Integration Platform<br />e.g. Speckle<br /> "])
block:ifcbcf:1
columns 1
bcf_int[/"BCF<br /> as issues<br />format"/]
ifc_int[/"IFC<br /> as exchange<br />format"/]
other_int[/"<br /> Other (bespoke)<br />formats<br /> "/]
end
block:d4sublock:1
columns 1
d4su_int(["<br /> <br />d4SU Server<br />Data for Spatial Units<br /> <br /> "])
d4su_db[("<br />D4SU DB & File Storage")]
end
ai4su_ml(["<br />ai4SU<br />AI Learning<br /> for Spatial Units<br /> "])
end
aeco_a --> advisor_a
advisor_a --> aeco_a
admin_a --> advisor_a
advisor_a --> admin_a
aeco_a --> aeco_sys
advisor_a --> tep_sys
advisor_a --> case_sys
admin_a --> admin_sys
aeco_sys --> aeco_db
case_sys --> case_db
admin_sys --> admin_db
tep_sys --> d4su_int
tep_sys --> other_int
aeco_db --> aeco_int
pointcloud_db --> aeco_db
aeco_db --> ifc_int
case_db --> admin_db
aeco_int --> ifc_int
ifc_int --> d4su_int
other_int --> d4su_int
d4su_int --> case_db
d4su_int --> admin_db
d4su_int --> d4su_db
d4su_int --> ai4su_ml
d4su_db --> ai4su_ml
admin_db --> ai4su_ml
d4su_int --> bcf_int
bcf_int --> aeco_db
style actors fill:#fff
style systems fill:#fff
style db fill:#fff
style int fill:#fff
style references fill:#fff
style ifcbcf fill:#fff
style d4sublock fill:#fff
style aeco_a color:white,fill:#991D58
style advisor_a color:white,fill:#991D58
style admin_a color:white,fill:#991D58
style aeco_sys color:white,fill:#0070C0
style case_sys color:white,fill:#5725D7
style tep_sys color:white,fill:#5725D7
style admin_sys color:white,fill:#5725D7
style aeco_db color:white,fill:#0070C0
style case_db color:white,fill:#5725D7
style admin_db color:white,fill:#5725D7
style pointcloud_db color:white,fill:#0070C0
style aeco_int color:white,fill:#0070C0
style ifc_int color:black,fill:#bad9f5
style bcf_int color:black,fill:#bad9f5
style other_int color:black,fill:#bad9f5
style d4su_int color:white, fill:#148F77
style ai4su_ml color:white,fill:#7ec2b5
style d4su_db color:white,fill:#148F77
style ids_ref color:white,fill:#5725D7
style datadict_ref color:white,fill:#5725D7
Arrows to-from Data Dictionary and IDS are not depicted on the diagram as these data are used by most other components.
Way forward when there is no BIM to start with
As shown on the above diagram, there is a flow between the Technical encoding & processing for permits, autorizations and certificates with API to d4SU and d4SU with an Other (bespoke format) exchange.
Indeed, it cannot be assumed that for all existing construction, there is a BIM model available. So, there is a temptation to build end-to-end monoliths instead.
The proposed way forward is to adopt a modular design and separate data entry from data management and business logic:
- Simple cases can be handled without a BIM tool while leveraging all the capabilities of OpenBIM tools such as IfcOpenShell. Instead of reinventing the wheel with yet another data model for construction, the data model can be based on IFC with CRUD capabilities of IfcOpenShell. If there is no need of geometry, that is not an issue: in IFC, geometry is optional.
- Complex cases are de facto handled with a BIM tool. Asking for re-encoding everything in a custom tool is both inefficient and costly. And there is also the additional cost of creating and maintaining a model that that can handle the complexities that have already been addressed in IFC.
Initiatives that rely on BIM/IFC or promote BIM/IFC in administrative processes
There is much to say on that. The following document provides in a single place a lot of information:
The future of IFC with IFC5 - A better file format and more capabilities
IFC is a mature standard, managed by buildingSMART. The first version appeared in 1996 (IFC1.5.1). IFC2X3 was submitted to ISO and published in 2008. IFC 4.0 was released in 2013. The current version is IFC 4.3.2 (aka IFC4X3 ADD2) (2024) which is also an ISO Standard.
Full documentation of IFC 4.3.2 is available on the web.
IFC5 aims to be a better version of IFC, without the limitations of the STEP format. IFC5
is not yet a standard and is still evolving. More information is available on the IFC5 developmnt site.
There has been aan exploration phase, then a pre-alpha release, then an alpha release, with a consistency in the objectives to be attained, but a significant evolution of the underlying technical concepts and schemas from one release to another.
Both the pre-alpha and alpha releases borrow concepts from USD (Universal Scene Description). In IFC5 pre-alpha version, the Def, Class, Over, Inherits, and some others concepts from USD were borrowed. This has been simplified in IFC5 alpha version.
- IFC5 foster composability. Different teams can work independently on different parts of the building or infrastruction definition. In USD, this is embodied in layers. In IFC5 layers are materialized as files; this means that a buidling or infrastructure can be represented by an ordered sequence of file that each contain a number of components and characteristics.
- Core representation is based on the MESH geometry, which is simple and efficient
- The format is JSON
- IFC5 borrows concepts and capabilities from USD, but is not USD and has its proper grammar.
IFC5 composability is most probably there to stay. This will enable to decompose an IFC in an orderly sequence of files depending on the need. For instance, as an illustration, a decomposition might possibly be:
- A first file with the base structure
- A second file with the common spatial parts
- A third file with the HVAC
- A series of files with the details of each of the private spatial parts
Other decomposition will be possible, such as having different options or opinions for a given part of the construction.
IFC5 is in development, meaning that most things are subjected to change. Clearly, d4SU will follow on IFC5.
Books
Rajabifard, A., et al. BIM and Urban Land Administration. 1st ed., CRC Press, 2019