BS1192:2007, the standard for collaborative production of AEC information, is one of the principle documents on which data production within the UK is based. It was, and still is, a critical standard, covering the structure of digital construction information and the process of sharing that data. It is, however, in need of an update to bring it into line with current best practice & contradictions now present in more recent publications. Here are 10 reasons why:
It’s sooo last century
BS1192 is nearly 10 years old in its current form. In reality, many of the principles remain unchanged from its original 1990 release, meaning we’re expected to base our current working practices on principles that were formulated over 25 years ago. Times have changed, processes have evolved considerably in the last couple of years, let alone decades, and it is imperative that BS1192 is revised to reflect these improvements.
Following terminology used in other related documents (PAS1192-2 for example) and the BIM Maturity wedge, BS1192 is fundamental to the production of Level 2 BIM projects and it needs to be revised to account for that in its wording. An example of this can be found in Annex B where standard validation checks do not refer to LOD / LOI, and reference to a BIM Execution Plan should be included for additional clarity.
For BS1192 to remain relevant post-2016, it needs to incorporate the BIM standards which it itself informs.
Field separators are inconsistent
Perhaps one of the most contentious, but ultimately unimportant, standards contained in BS1192 is the arbitrary use of the underscore character to separate the description from the other fields. If there was a valid reason for a different field separator just in this one location (machine-readability? Why does an underscore make it any more machine-readable?), it has become irrelevant in common working practice. With the advent of Uniclass 2015 and its extensive use of underscores, the sole exception to a consistent hyphen separator reduces clarity.
It is now time to standardise, along with other documents that specify a hyphen as a field separator and an underscore within fields (e.g. BS8541), the conventions in BS1192.
Speaking of Uniclass 2015, while BS1192 does allow for any classification system compliant with ISO12006, it does specifically state in clause 11.2 that the UK uses Uniclass Table G, H, J, L and F. This is out-of-date and needs to be removed from the standard.
BS1192’s role codes, defined in clause 10.2, do not include many of today’s common design disciplines: there is no acoustic engineering, no energy analysis, no environmental engineering; no BIM coordination, often a unique role separate to other disciplines. Even the provided codes do not allow for the distinction that is common in the workplace: bridge design, road engineering, water are all grouped into a single “Civil” role, which simply does not reflect the reality of infrastructure design teams and responsibilities.
Standard type codes
Something lacking from BS1192 since day one is the ability to identify varying types of file types. In a document management system it may be sufficient to use “M2” for all 2D model files or “M3” for 3D, but in reality, in a file-based operating system, much more clarity is required. 2D models are commonly split out into plans, elevations or details, and 3D models too may be of different types: assembly models, components. When a standard becomes too limiting, as BS1192 is in this instance, compliance becomes very difficult to achieve in a normal working environment.
Other representational views of elements (cut, hidden, etc)
BS1192 does not allow for “multiple” representations of the same element in its layer naming. This is presumably linked to the age of many of its conventions, but it is a common necessity to represent cut, hidden, elevated and reflected linework of a single element differently. In layer-based systems this needs to be handled by unique layers, not strictly compliant with BS1192 in its current form.
The newer “pillars” of BIM
Including documents such as PAS1192-2:2013, PAS1192-5 (security requirements), BS1192 needs a full review to ensure it aligns with these other parts of its own British Standard (once they become standards). Even if there are few direct edits required, cross-referencing these associated documents is critical. PAS1192-5 especially so when outlining the principles of a Common Data Environment.
If it needs a complete document to explain how it is supposed to work (“BS 1192 and Building Information Modelling – A Standard Framework and Guide to BS 1192”), it perhaps wasn’t written clearly enough in the first place.
Isn’t it time container naming was updated to make it more human readable? The simple addition of Description would make navigating even a small list of files much easier. And why is an object treated differently, having its own naming standard? Is an object not a container?
Photo by Cindy Tang on Unsplash