The Architecture of a Template

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.

Template Details

Template Details

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.

  1. The BuildingSMART data dictionary (bsDD) language definitions.
  2. 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.

  • CiSFb
  • 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].

  • Building
  • System
  • Floor
  • Space
  • Zone
  • Product

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.

LED TV Enumerated list of attributes

LED TV Enumerated list of 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].

  • Manufacturer
  • Specifier
  • Installer
  • Procurer
  • Transporter
  • Commissioner
  • Performance
  • Maintainer
Attribute relevance

Attribute relevance

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.

29-03-2016 13-24-51

Template export 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.

29-03-2016 13-26-09

Product library data service link to templater

Here master data sets are synchronised and managed by the templater service. Above is how it appears, indicating that a data set needs updating.

29-03-2016 13-41-39

Updating Product Library Template managed in template

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.

29-03-2016 14-11-08

Creating products in the Product Library

When a product is added or edited a template from the suppliers subscribed templates is selected.

29-03-2016 14-28-43

How the template is used in the product library

When you select Attributes all the attributes are in the template are displayed.

29-03-2016 14-19-32

Attributes at product level

If a template is assigned then you can edit with template.

29-03-2016 14-19-47

template as a controlled input form in the product library

This controls the inputs and validates the values facilitating smooth transportation of data between systems.

29-03-2016 15-00-16

Export options at the product model level

The resultant export as COBie

29-03-2016 15-09-22

COBie Attributes

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.

 

29-03-2016 15-09-09

CibSe Format PDS

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.

Advertisements

2 thoughts on “The Architecture of a Template

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s