Entrant details
Role or Job Title on the Project
Project Manager
Employer
ACCA Software S.p.A.
Contrada Rosole 13,
83043 BAGNOLI IRPINO (AV) - Italy
Employer Role
Technology or Software Development Company
Are you or your employer a member of buildingSMART?
Yes - Sponsor Member (Standard, Multinational or Strategic)
Submission details
Submitting Party Company Name
ACCA software
Submitting Party Company Location
Italy
Submitting Party Role on Project
Software House / Software Developer
Submitting Party Company Website
Full Project Name
usIFC.server
Project Location (Country)
Italy
Project Objectives
usIFC.server revolutionizes the concept we have of IFC files today by transforming their use in the BIM process from static to dynamic.
It is known that IFC models are monolithic, difficult to manage and update, with usIFC.server becomes not only possible but also easy and fast to keep them updated using any client software and/or device and without the need for proprietary formats.
Practically usIFC.server makes IFC files available simultaneously to multiple users who collaborate with each other and share the model completely in openBIM format with the ability to read and modify it dynamically with different software or device.
openBIM Achievements
openBIM and in particular the IFC file format is the foundation of the entire project. This is a revolution since the IFC models, actually tought as a “static” snapshot can now really be tought as “dynamic” models that evolve over time, especially when the native/bim authoring application will not be available anymore (think about years after the Handover during the Maintenance Phase where some of the objects could be moved, added, removed, and properties and object specifications changes over time aswell).
The results achieved are unique in the world, never seen before even with the use of proprietary formats.
openBIM used
IFC 2x3, IFC4, ifcXML, MVD
openBIM or open standards used other than those listed above
JSON (for partial model exchange and server communication)
Software used
usIFC.server, usBIM.platform, usBIM.editor, usBIM.browser, Revit, usBIM.facility, Solibri, usBIM.viewer+, usBIM.reality
Highlights
-
Revolutionized the concept of an IFC file: from a static to a dynamic and evolving object
-
Possibility of high-level Server interaction from any Client and any source (BIM Authorings, BIM Tools, IoT, Virtual Reality, Smartphone, etc.)
-
Edit and update of the IFC models during all the Life Cycle of the building / infrastructure projects
-
Querying of the information of the IFC models, even in case of federations (i.e. the query can span over different models)
-
No need to know the cumbersome of the STEP IFC specification, whether it is about editing or querying about information
Project and Stakeholder Logos (compiled into one .ppt/pptx file for upload)
Project Address
Project Type
(Other)
Size of Project
Detailed description of the project
The usIFC.server Project revolutionizes the concept of IFC as we know nowadays. We think about an IFC model as a static snapshot in time of the construct, or, rather, as a specific exchange of information for a particular purpose. But IFC models can be much more than that. They can, and should, be an evolving object that has the same life span of the building / infrastructure that it digitalizes. IFC models, in fact, are the (openBIM) digitalization of the building / infrastructure and hence should undergo the same changes and updates as the “real” counterpart. This vision has been also understood by buildingSMART and different projects are already addressing some of the issues with the current IFC STEP serialization mainly in order to simplify it and make the data structures serializable in other common structures such as XML, RDF, HDF5, JSON and so on. Some of these are more suitable for storage, some other are more appropriate for transactional and partial model exchange. One of the achievement of the usIFC.server project is to conveniently store the IFC data structures on a server. This gives the possibility to have access to every single information that is stored in the model and to easily modify it and hence it is easy to achieve partial model exchange with such data structures. On top of that, many high level APIs that simplifies the editing of such information allowing any Client to use APIs even without knowing the details of the IFC specification. There are many possible operations for different use cases that span over the entire life cycle of the building / infrastructure. Here are listed some, but we really think that to see all of this in action is the way to go, hence please refer to the attached video which explains everything while showing it in practice for the full experience and understanding of the incredible potentialities and revolution that this project is bringing to the table.
As some example usages, a BIM Authoring application may be the Client that is sending to the Server the movement of the entities, or, as an evolution of such use case, the Client may be requesting informations only for part of (different) models, let’s say, structural columns from one model and MEP pipes from another. Due to the partial model exchanges, the Client will receive informations only on the requested entities, not the whole models, and updates and editing to such entities will can be automatically addressed to the belonging IFC model, in fact making the federation of models real seamless in regard to the end-user perception. Another use case may be a facility management application that needs to update the object position in real-time, since the object may be attached to a beacon which signals position changes, or a browser or any other client such as a Virtual Reality client which is requesting information for visualization or update. usIFC.server is the first of this kind of applications where the IFC data structures are made editable and hence dynamic and it proved successfully that this is a feasible road to follow. It already applies to many existing use cases that are not actually in the scope of the current IFC’s existing MVDs (Model View Definitions) and more can be added with ease, having the possibility to edit every single information of the IFC model meaning that it is possible to cover every possible add / update / remove of information from the model. It is really up to the clients to create new and diverse workflows and use cases for the end users. Existing informations in the models can also be obtained via queries that can also span different IFC models in case of federations. At any time the STEP serialization can give back the modified IFC models from the Server in order to have the most common IFC data schema used nowadays that is compatible with the many applications available on the market, but the real innovations stands in the partial model exchange and of course the editing of every information of the IFC models. OpenBIM really opens your mind and within the mission of developing new technologies with the use of openBIM, with usIFC.server we have really achieved results unique in the world, never seen before even with the use of proprietary formats. Again, please refer to the attached video for a practical usage of such revolutionary technology.
Detailed description of openBIM on the project
A practical overview of different use cases with the use of usIFC.server can be found in the attached video. Please refer to it for a full understanding of the usIFC.server technology. In the following of this section, a more detailed technical overview is summarized.
usIFC.server is a Cloud Server where the open IFC data structures can be stored. Today, we think that an IFC model has to be bound to be stored on a file, but the data structures defined are feasible to be stored in different medium with different serialization options. buidingSMART International is aware of this and, in fact, as stated in the other answers, some projects are already exploring different serialization options for different purposes. This is what bSI envisioned and will be the IFC of the future. With some semplifications of the schema (which is actually considered to have quite an high threshold to be effectively implemented by software developers) these open data structures will allow any software from any domain to join and integrate themselves with the existing ecosystem of applications. This is incredibly powerful because at that point different stakeholders will contribute with their existing / new systems integrated with the open IFC models and their complexities.
usIFC.server is already there, and is a proof that the vision from buildingSMART is feasible and the technology stack available today is already sufficient for the task at hand.
In order to achieve this incredible results, unique in the world and never seen before even with the use of proprietary formats, usIFC.server uses the concept of APIs for client / server communications.
First of all, the the usIFC.server provides REST APIs for Upload and Download of IFC models, so any client that wants to upload a new IFC model or download a modified one, can use such APIs.
Once the IFC models are stored on the usIFC.server, they can be queried for exising informations. Here, again, some APIs and an SQL-like language allows to compose queries that can also span different IFC models. The results are communicated in JSON, another open file format commonly used for data exchange over clients and servers.
Other than that, the client can read and write (hence update) every single information of the IFC model. In order to achieve that and to flatten the IFC STEP complexity, the server exposes high-level API for common updating operations (move / rotate entities, add new ones, modify properties, add groupings, etc.), so the client does not need to have a deep knowledge of the IFC complex data structures, but can accomplish the necessary updates with ease. As an example, if the client wants to move an entity, it will be simply asked for the translation of such entity, without going into the details of object placements, relative placements and all the complexities that the current IFC data structures are composed of. This extremely simplifies the client’s burden and makes everything as easy as some basic APIs calls. Of course, usIFC.server has also more detailed APIs that can go into the very finest details of the IFC complexities, should the clients ever need to go into that level of detail.
Operations are atomic and can be executed concurrently from different clients. Clients also gets notified on changes that are happening in the model in real-time for updating themselves and react to changes.
In case there is need to require data from only part of the model (or part of different models, as in the case of visualization or update of different entites of a federation) the server will do partial model exchange, in order to optimize the traffic generated. This is also very important for to have thin clients and to be able to update models regardless of their size.
All the described generic mechanisms are really powerful as different clients from completely different domains could be interested in different aspect of the same model. In this way, all the clients can contribute to the keep the open IFC model up to date and can in turn react and trigger other actions and updates.
At any point in time, the updated IFC file can be requested from the server as always using APIs for doing so using the classic IFC STEP serialization.
Software ecosystem map
openBIM Supporting Evidence
Benefits from using openBIM
Open formats encourage competition between software developers instead of ensuring only one manufacturer's control over all user-made content through the proprietary format. Data access is guaranteed over time and the ownership of the data is guaranteed aswell, all thanks to the open formats. The use of openBIM and in particuar IFC file format is being more and more required in every construction project, and the adoption of this format will grow exponentially in the next few years. While some problems have already been addressed and solved, many still needs to be faced in order to have data structures that are not only feasible for storage as they are already today but also capable of dealing with dynamic use cases that cover all the life cycle of the evolving building / infrastructure. Having a growing pool of software applications that can easily handle such data is very important as this will allow to create bulletproof data structures open for authorities and to any software developer that can join and integrate seamlessly with the ecosystem of existing application from any domain. Simplification of the IFC schema is important and is being already addressed by buildingSMART and this will be very important as will guarantee an official and impartial data schema but it will be the software vendors that in the end will implement such data structures and data exchanges hence the more applications will be available that will cover any possible use case the more benefits for the end user. usIFC.server is a first of it’s kind of application where the IFC data structures are made easily editable and hence dynamic covering a variety of use cases that as of today where not possible to be “captured” in the IFC model, being it a static snapshot in time of the constructed building / infrastructure. This really frees the mind of some burden that comes with the current static “snapshot” view of the IFC models, and breaking such misconception really allows a completely new degree of freedom in thinking out of the box on what can really be achieved with the use of openBIM models in their maximum expression.
"We were able to innovate using openBIM."
Absolutely. Thanks to the openBIM we had the freedom in thinking that we needed in order to develop such technologies unique in the world that as of today are not even obtained with proprietary file format. As per the official bSI Projects, mainly the IFCJSON Project from the Product Room and the more general NextGen-IFC Project, the openBIM IFC data structures are undergoing some major changes in the future in order to simplify it’s adoption and lower the threshold for the new implementers. This will be achieved with a more transactional-oriented and technology independent data schema more convenient for the editing of the single informations contained in the model and the partial model exchange, which is crucial in order to have a widespread adoption and integration also from different domains (think about IoT systems, Digital Twins, and so on). This project is a revolution also in that sense as it is the proof that the direction envisioned from buildingSMART is feasible and that the technology stack available today is already sufficient for the task at hand. Please refer to the attached video to see everything in action where already some Clients are making use of such technology in order to address some use cases that as of today where not possible to be addressed due to the “static” nature of the IFC models.
"We were able to identify where we need openBIM to develop further."
Further simplification of the IFC specification in order to lower the implementation threshold for the widespread adoption of the IFC data structures in any domain is already being addressed mainly in the undergoing IFCJSON and NextGen-IFC Projects and this alone is a great possibility for the future use of the IFC data schema. These projects are still in the early phases, but hopefully they will undergo the same bSI Process as any other Project, such as the Infrastructure Extension Deployment Project, the Railway Project and so on. This would mean that specific use cases will be identified from the domain experts from all over the world and then there will be a technical implementation of the details from the software vendors and the interested parties. As of today, this approach has proven to be very successful in guaranteeing an international consensous on the decisions made during the different projects and we expect this to be guaranteed aswell for these projects should they follow the same bSI Process. This would also maximize the number of interested parties and stakeholders involved and would (hopefully) guarantee that there will be a widespread adoption of these next-generation IFC data structures in the whole construction industry in any domain (IoT systems, Digital Twins, etc.). Certification processes, as already done for some of the most common MVDs (Model View Definitions), can also ensure a high quality of such implementations from software vendors and can be extended to any kind of application that is able to handle IFC data structures with the new use cases that will emerge from this new, technology independent, IFC data structures.
BIM Uses were defined on the project
I agree to be contacted about the project BIM uses outside of this awards program.
Stakeholders
ACCA software, Contrada Rosole 13 83043 BAGNOLI IRPINO (AV) - Italy,
https://www.accasoftware.com, Software Developer / Software House, Michelangelo Cianciulli
