Nearly everyone involved in the construction industry are using templates in some form or other be they a creator or consumer of digital information.
In BIM, the common understanding for the use of templates is in the context of components from generic design elements holding specification performance requirements to products with actual performance data.
Templates for other building elements may seem different to those of components but their architecture is identical, it is only the content of the template that differs.
BuildingSMART IFC and more importantly COBie have helped to identify the core elements of any template, and these are well documented.
We only need templates when the data we need to store is not part of the default set of information defined in the schema.
For example in COBie ModelNumber and ModelReference for a product are contained in the Cobie.Type section. If the product is electrical then the information needed would be contained in the Cobie.Attribute section.
Here is how we have defined our template manager architecture.
At the top level is a template definition [Master Template] which has a name and description, it can map to a category [Master Template Category] which is a list of all the IfcTypes but lists them out in a plain language description.
Templates need to be global so that they are applicable to international markets, and assist manufacturers in keeping product data relevant to all markets. To achieve this there language and classifications systems are handled.
- The BuildingSMART data dictionary (bsDD) language definitions.
- Classifications which are used throughout the supply chain within regions.
The bsDD needs only to be matched to one entry but there are different classification system around the world and a template may refer to one or more entries within it.
We have a classification data base which currently stores all the following systems.
- CAWS (Common Arrangement of Work Sections)
- Uniclass 1
- Uniclass 2
- Uniclass 2015
- Omin Class
Within our Product Library application products are associated to a template. A project in our Asset information model application can only use one classification system. When products are exported from the library manually then the user must specify the classification they want to use on that project. If it is imported through a data service then this is selection is automatic. The ownness is on the template definition or furnish all relevant classifications.
As we are using templates for other purposes the template must have a type. Currently we have the following types in [Master Template Type].
Not surprising that the Product Library filters templates on Product but the application does allow the creation of local templates of any kind so it acts as the companies source of templates for other parts of the building. For example BRE and activePLAN will be using this for creating templates to do surveys at the building and space level.
The most critical part of the template is it’s attribute set [Master Template Attributes]. Attributes in this template architecture have to cater for different types of attribute.
- Single Values
- Value selected from lists
- Range values
The data type must be strongly defined so that systems that use the data do not throw an error. For example where a voltage value is provided if the data entry is “210 volts” then the record will have to be corrected so that it is value “210” and unit “v”. There are not many data types.
- Integer (whole number)
- Float (floating point number)
- Date Time (universal date and time format)
- Text ( a text string )
- bool (true/false yes/no)
The BuildingSMART ifc specification identifies units as a types but not the actual SI (standard international) so weight is unit type “mass” but a we need to know if the value is kilograms (Kg) or grams (g) To accommodate this we have [Master Units Type] so the attribute can be set by selection of the type of unit (Mass) and then the specific SI unit. In the COBie schema the Units field will match on the SI unit expression.
Some mechanical services products have settings that are specific to the instance of that product within the building. This needs to be accommodated in the template so that it is relevant to the asset information model. An attribute can be set to Type or Component the latter relating to the instance within a building and the former the that of the product specification.
Manufacturers products can be divided into groups and variants of products. For example a flooring material may come in a variety of finishes and patterns. The material properties are all the same but the finishes and patterns vary. To accommodate this an attribute can be set to only appear at either the product level or the product model level. Product models inherit Product attributes.
The list of attributes is growing list as different interest with the industry require more and more detailed information. The attributes need to be organized into logical groups such as Electrical, sizing, Performance. These groups are commonly known as property sets [Master Template Property Set] . Attributes cannot be created without belonging to a property set.
Both property sets and the attributes within them need to appear in a logical order so each are orderable.
Even when the attributes are ordered into groups and appear logically scrolling through 200 attributes looking for a packaged size or packaged weight can be a chore. Each attribute can be designed to be applicable to an audience [Master Attribute Relevance] which are picked from [Master Actor].
The common modus operandi for using a template is to export into some form of editable document or transcribe into a 3D object definition. Supporting this is easy by exporting the template into different document and data formats.
The templater is a fully API data service, which makes integration into other application very easy to achieve and avoids clumsy document management and import processes.
Product Library application uses the templater API to consume and keep up-to-date master tables and templates . The product library has it’s own built in templater so that custom templates can be created and master templates can be extended to suit the end user requirements.
Here master data sets are synchronised and managed by the templater service. Above is how it appears, indicating that a data set needs updating.
A product Library does not need to have all the templates in the templater service. For example a supplier of lighting would not want templates for pumps and boilers. You should only load templates that you need.
In the product library a supplier record can then subscribe many templates.
When a product is added or edited a template from the suppliers subscribed templates is selected.
When you select Attributes all the attributes are in the template are displayed.
If a template is assigned then you can edit with template.
This controls the inputs and validates the values facilitating smooth transportation of data between systems.
The resultant export as COBie
The CibSe format Product Data Sheet. This is not a template created or approved by CibSe but illustrates how a the templater application can be used to create templates and applications can use the templates to organise the data and export to different formats.
If you have been following my posts then you will know that there are already API’s for some BIM modelling systems that can snap attribute definitions on to components and populate with the correct product data from the product libraries using API data services.
Those that want to produce COBie output from BIM models can easily use these tools but will have to take the responsibility for the data as these BIM System wash out strongly authenticated records such as authorship. They also expose attribute values to corruption.
When product libraries are populated by suppliers of the products rather than 3rd parties, designers or more likely the contractors data will have a level of trust and traceability.
Clients will be using applications that verify output, these will be hard gates in the process and executed before final payments. Ignoring this will result in damaged reputations, loss of credibility and clients.
The Templater, Product Library and Asset Information Model are all part of Better Information Management (BIM) it’s all about making it simpler and efficient.