Hello
We ask ourselves the following: Where are requirements laid down in the IFC?
e.g. In our understanding, fire rating is a property of a component, not a requirement. This property can exceed the requirement, but should not be less than this.
These questions arise with AcoustingRating, FireRating, ThermalTransmittance. Maybe there are more.
How do you take into account the difference between requirement and property in daily work?
Thank you for your feedback.
It would be good if IFC has these two separately:
However, normally these requirements handles through IDM/MVD approach (IDM Configurator/Toolkit)
You build mvdXML which you can compare your MVD model against the mvdXML which holds requirements, and extra data/information
To develop IDM/MVD you have to use IfcDoc or other similar tools (which as long as I know IfcDoc is complete than others, even when still has some limitations)
Hi Ehsan
Thank you for your Feedback.
I may not have expressed myself precisely. I try again:
For example, a corridor wall consists of two sections. One has an EI60 requirement, the second has an EI90 requirement. However, the builder uses one type of wall, lets say concret with the properties EI90. He can do this because the requirements for both sections are met.
We believe it is important to differentiate between requirements (planning) and properties (components or products). However, this would mean that two entries in IFC are required for âFireRatingâ: 1) for the requirement, 2) for the property (of the product or component)
An other solution could be to have two models: 1) with the requirements and one with the probertyes under the same propertyes in the IFC.
how do you see that?
Hi Boris
I understood what youâre mentioning about:
Some properties need two attributes together like FireRating, one says whatâs needed and another says whatâs provided
So thereâre two ways to do rule-based auditing:
Or I donât know, maybe it would be good if IFC has two attributes, one for the requirement and one for its actual condition
The Pset_*Common properties, such as FireRating and AcousticRating commonly express the specification in the model. Depending on the context, the specification may be more restricted than the actual requirement (based on building code, regulations).
In one of the standardization working groups Iâm following, there was a suggestion to amend them with their ârequirementsâ counterpart (by added Req at the end of the property name), so you can both express the requirement and the specification.
To be complete, youâd probably also have to add the actual obtained performance⌠e.g. after the contractor chose the final products and materials, which should be at least of the same level as the specification.
There are a few property sets in IFC4 which have ârequirementâ in their name:
There are some properties which have requirement in their nameâŚ
Thanks a lot for this feedback! is it allowed to add an other property under the Pset_**Common? Do we than not have the problem that we are not in the structure of the ifc? Otherwies we can do a costum PSet?
I think for a lot of users this will not be so easy to manage in the Pset_*Common. But i think it is important to do distinction.
Itâs a normal approach, you can develop your own Pset_*Common or add some properties to a ready-to-use one
The âPset_â prefix is reserved for official psets. You can create your own psets though and not use the prefix âPset_â in your pset name. In general, you should map to official properties (almost 1700 of them) and if you do not find them you create your own pset with the property definition you require.
FireRating is one such property that is available in the IFC specification so you should not create your own pset for it, just use the existing one.
Thank you for the hint to the working group, that made the mentioned suggestions. Could you please give some more details about the working group? What other possibilities have there been discussed?
Iâm speaking about CEN/TC 442/WG3. You have to be a member of a European national standardisation mirror committee to be allowed as expert delegate to actively participate in such working groups. I cannot share intermediate results for groups I follow, but the final guidance documents will be published via CEN.
It is a slow process, but quite necessary to allow unified approach and the development of standards. E.g. where buildingSMART explains that you cannot use PSet_ as a prefix, since they are reserved by them, such a committee may then describe recommendations for e.g. a naming convention when adding your own property sets.
It seems that itâs around a year Psets reserved
Also, whatâs those 1700 Psets? Around 400-450 of them are official in current IFC4s (if we exclude infra and other new parts)
However, I think @Brunner mentioned an important topic, sometimes thereâs a need to have both spec and requirement as Psets and objects/classes, attributes, etc
Ok, so we need an other one of a ePset_someting.Parameter. The goal was to following ifc as close as possible. But in the end we always have round 10% of the parameters left we can not put into a standard place in ifc. Also because a lot of consultants are not be able to handle there expensive Software from america or germany to export useful standard IFC files. As an enduser it is a little bit frustrating. The same Time there are endless presentations how we change the world to the better with bimâŚ
IfcXtreme will solve all issues and challenges, but itâs open source and needs contribution:
Please consider that this was base idea and during a year the idea has evolved a lot and will change the AECOO (the (Digital) Built Environment) industry completely 
Properties mate, not psets. 
Thank you Sergej, yes official properties are almost 1700
Beware the âEPset_â prefix is also reserved by buildingSMART for official extended property sets. There are recommendations being discussed to make the prefix based on Country and Organisation. e.g. âBEabcâ or similar.
I understand that there may be a confusion for the end user, when some properties may be covered in an official buildingSMART âPset_â whereas additional, maybe country specific, but related properties are to be found in another property set.
Interesting topic.
So from what I understand is that by using Pset_blablabla for a new set or properties is not quite following the bsI standard? I have a case where we are using Pset_DoorCustom or Pset_SpaceCustom. I do not understand why would the prefix âPsetâ is not allowed to be uses to extend the structure. By agreement (ex. BEP) it could be clear that, what is IFC standard and what are additional extensions. Or?
As far as the main topic of this post, about the requirements. To my knowledge there are two types of information or properties. The first one is the requirement of components in order to get a permit to be built which is usually the minimum criteria which a certain component must fulfill. The second one is the built in property on the construction site. If the construction company builds a higher property that is required, why do I still need the first requirement as a property? How does this help the DigitalTwin in the exploitation phase? Doesnât it just raises another question (maybe 20 years in the future), that someone asks: why does this wall have higher firerating property than it is required.
Beside the important question âwhere are requirements mapped in the IFC?â in current BIM practice I would like to sketch a target bearing for future BIM developments:
In the light of actual research on decentralised common data environments and linked building data
(e.g. https://www.researchgate.net/publication/335947234_Towards_a_Decentralised_Common_Data_Environment_using_Linked_Building_Data_and_the_Solid_Ecosystem)
I see the possibility of a long-term shift
Currently this information can be collected in IFC files but I would not recommend.
In the long-term systematic requirements-engineering based on the industrial V-model are promising.
Hi agron!
This is described here, for instance: https://standards.buildingsmart.org/IFC/RELEASE/IFC4_1/FINAL/HTML/schema/ifckernel/lexical/ifcpropertyset.htm
âIn addition any user defined property set can be captured. Property sets that are not declared as part of the IFC specification shall have a Name value not including the âPset_â prefix.â
Technically you can name it as you want, until this is only about your own specific needs. But to prevent mixing official and customized elements, if you go to public with yours properties sets, it is needed to follow by this notice.
Regards,
Alexey
Hi Boris,
In brief - you compare values of IFC-attributes with requirements. These attributes and requirements are about the same characteristic of object/statement.
There are a lot of world-wide examples, how to do it - Norway, Korea, Australia, New Zealand, Singapore, USA, UK, Russia etc. For example, you can read it from here: http://www.eubim.eu/wp-content/uploads/2019/08/2019-08-28_EU_BIM_Task_Group_Statsbygg_BIM_Manual_20_v101.pdf and here: https://www.researchgate.net/publication/320293111_A_Methodology_of_Building_Code_Checking_System_for_Building_Permission_based_on_openBIM
In common, you need three parts - BIM-server, Requirements Database and Verification tool. Practically, the most difficult is to digitalize natural language into machine-reading format. This is not a technical difficulty but the difficulty with clear interpretation of requirements into rules.
The way of a modeling is the key-role here. It also directly depends on a software which is used for this. For example, construction works and finishing works are different stages and elements. Finishing (covering) is belonged to room/space. So, for the example with a corridor which has to have different fire-ratings on its path, I do the accordant finishing (if the construction wall is the same - for example, concrete) or different walls and finishing (if the construction wall is different along a corridorâs path). Next, you can compare fire-requirement of a zone (room/space) with fire-rating of surrounding elements - walls, slabs, doors and windows, as well as with fire-ratings of finishing (or - check and insure that there are not flammable materials if there has to be any defined fire-rating or fire/explosive-class of a zone). EI60 and EI90 means different concrete - different additions, if we are speaking about pure concrete wall without any fire-resistant covering. So, at least yours builder doesnât follow by yours design documentation and requirements. Practically, it is usually agreed between sides, if the builder can use other material (it also has to be approved by expertise, in some cases, because it can influences on other structural characteristics and finally - on residential safety) and controlled by architectural- and technical supervisions. Next task - you can compare âas builtâ with âas designedâ, because the supervision fixes actual statement (including materials) of the building. Differences which will be found here can also be compared with technical requirements (permissible variations), in the same way as designâs expertise.
Regards,
Alexey