Common language is the foundation of good communication. It allows us to describe our thoughts, our intentions, clearly, consistently and unambiguously. Without commonality, understanding is limited, interpretation is subjective, and errors occur. Describing the constituent parts of a Building Information Model has suffered from apathy, despite the benefits of standardisation being evident and an integral part of traditional CAD data production. For reasons unknown naming and consistent segregation of data has taken a backseat to the hype of BIM, with software developers and BIM Coordinators satisfied with inconsistent conventions and unclear descriptions.


Even BS8541-1, the British Standard for the identification and Classification of Library objects for architecture, engineering and construction, offers two standards: one for “classified objects” and another for “objects without associated classified attributes”. The difference between the two is whether an object carries a specific “Classification” property as part of its metadata. If it does, you are allowed to truncate the naming convention used, presuming that the objects can be searched easily for the classification, and therefore requiring less categorisation:

SOURCE (Manufacturer or object owner) – TYPE – SUB-TYPE (product)

e.g. ACME-Door-Type3

To use this short naming convention, the object would require a Classification property which would have a value, using the current Uniclass v1.4, of G322.

Without the Classification property, the object naming would become:


e.g. MN-G322-M3-ACME-Door-Type3

MN stands for “Manufacturer”.

The problem comes, as with many aspects of BIM standards and generalised approaches to classification, when these conventions are applied to BIM data production.

Firstly, it requires software developers to adopt the conventions, something which is far harder than you would imagine for many of them to agree to, despite it being a “british standard”. I use quotes as even us Brits can’t agree on whether this is the object naming standard or not. As a contradictory example, look at the NBL, the National Building Library, object naming convention which uses abbreviations to reduce the length of the name:

e.g. nbl_Door_Ext-Sgl-Vsn-Pnl-01-910X2100

It’s actually very similar but without a classification code in the name. That makes the abbreviated descriptions very difficult to work out. Sure, “Door” is obvious, and you should be able to work the rest of that one out, but try “nbl_CncldGrid_RectTileMnrl-FrmMtl-Insul” for a cryptic puzzle. “CncldGrid”? Yep, that’s exactly what a classification system is designed to avoid!

Secondly, if the simpler BS8541-1 convention is to be adopted, greater functionality needs to be provided to identify an object by its “hidden” metadata. This is not as straightforward as you might hope, when browsing using Windows or in-built project browsers are systems designed to display the main object name only.

Even with the full BS8541-1 naming convention, defined “in accordance with BS1192:2007, Clause 5”, there is uncertainty and inconsistency. Aside from the reversal of the location of “Role” and “Originator” between the two standards, it is not possible to ascertain the “view” of a two-dimensional, M2, object (whether it is a plan representation or an elevation) nor its graphical complexity. The AEC (UK) BIM Protocols overcomes these necessary aspects of objects during design activities by expanding the convention:


Fields in parentheses are optional; role, for example, being implied by the model naming in which it exists. Additional codes are provided for 2-dimensional objects, including P for Plan and E for Elevation.

e.g. MN-G322-DoorInternal-ACME-Type3-M3-G1

or G322-DoorInternal-910x2100-M3-G1 for non-manufacturer specific door.

With such diversity and non-conformity in fundamentals such as this, is it any wonder that the industry is in a state of confusion and there is so much difficulty in interrogating other disciplines’ models. Consider how much more compounded this problem will become if the data is presented in a COBie spreadsheet, where multiple conventions may exist, depending on the software used (Revit employs no standard, using arbitrary descriptions; Bentley ABD uses the AEC (UK) protocols in the UK, but no standard in the US).


This is where a classification system comes into play. By using a consistent classification, in both the object name and its metadata, clarity can be attained when placing or editing graphical objects within BIM production software and in any form of non-graphical output.

In the UK, up until now, Uniclass has been the de-facto standard. Developed and published by CPIC, the Construction industry Project Information Committee, representing the CC, RIBA, RICS and CIBSE, Uniclass has been widely adopted and adapted for more effective use across the construction sector. In particular the classification has been expanded to better describe civil engineering projects, Crossrail being the major contributor. …And just when it had reached a more usable state, Uniclass gets a complete redesign. The reasons for this overhaul have been cited as inconsistency in scope, coding, depth, granularity and alignment. All of these are true: the current Uniclass is an amalgamation of independently authored tables, none of which matter to 99% of the user population.

As with any classification system it is initially intensely confusing. You are faced with a number of different tables – groups of classifications – and a whole string of codes, intended to organise the chaos of arbitrary English descriptions of our everyday construction components. The ordered design of the “unified” Uniclass isn’t in question, as a structure it is well-thought out and does its analytical creators justice. All of that is completely unimportant if it can’t be used to classify the very BIM objects the redesign was proposed to improve. And here’s where applicability to a BIM modelling system gets difficult: it describes objects in an analytical manner, system- or activity-based , definitions, often contrary to the way objects need to be isolated in a design environment. The best example of this is the classification of structures. In Uniclass v2, the whole of a building’s structure is described as a structural framing system, further broken down by material type. It does not, however, provide distinction between beams, columns or bracing, all of which are fundamental definitions needed by almost every structural design activity. To segregate those objects into groups, an additional arbitrary human description needs to be added, negating the major benefit of a well-designed classification system.

So, how does the new Uniclass translate to being used in BIM production offices? It appears to work as follows:


  • CO (COMPLEXES) would be used for describing a complete site, the highest-level of Masterplanning. for example.
  • EN (ENTITIES) breaks down the specific buildings (or bridges or civil works) within a site.
  • AC (ACTIVITIES) defines the use of an area. This is where it starts to get tricky, as
  • SP (SPACES) er… is identical to AC.

    It seems to make sense though, if you stick to semantics of areas and spaces. That’s just as confusing, I know, but as an example, it would be the difference between using AC for “this area of the project is going to be retail” (AC-25-64) and SP for “this is a retail unit” (SP-25-64).

The next 3 tables are far harder to work out:

  • EE (ELEMENTS) replaces the well-understood table G for CAD/BIM systems used up to this point. It defines Building Elements. Seems perfectly reasonable, until you take into account the new table SS.
  • SS (SYSTEMS) describes the systems of a project: walls, structural frames, etc. How these differ to Elements, in theory, is clear: an element is a non-specific item, a system is able to be defined. An example would be the difference between:


    • a floor outline on a CAD drawing. It wasn’t necessary to define the type of floor so a single code could be used: previously G22. In the new Uniclass this maps directly to EE-20-40-10.
    • a floor modelled in BIM. You would typically know what the floor was intended to be therefore it would be classified as per the SS table. A concrete floor would be SS-20-12-85-18 in the current proposals.

It may be though, that you are in feasibility stages and are not modelling a complete floor “system”. You may simply be modelling floor locations in a mass. In this case the object could be defined as either EE-20-40 or SS-20.

The same conundrum arises for walls. These can be either the non-specific EE-25 or a wall system SS-25. Which should be used is somewhat arbitrary depending on your activity, although as a general rule of thumb, and to avoid a huge table of layers, employ the granularity of the Systems table which maintains consistency as more detail is added into the model. Think of your objects as whether they are actual elements that can be specified or procured.

For example:

An external cavity wall would be EE-25-20, because it doesn’t really exist as a single system that can be ordered or built. While it can be modelled as a single object, It’s just a placeholder.

Modelling it “properly”, the brick part of that, the system, would be: SS-25-12-10.

The block skin would be SS-25-13-50 or specifically SS-25-13-50-51 for an external cavity wall.

A door and frame would be SS-25-30 rather than an element. Again, it is a system, composed of multiple parts and products (see below). SS-25-30-20 would be a door (or hatch).

A window is SS-25-30-95.

A concrete wall has to be SS-25-10-32-70.

The only difficulty, as mentioned above, is that the whole of a structure is defined in SS as a single system. We’re back to pre-1.4 days:

A steel beam would be SS-15-10-75-35.

A steel column is also SS-15-10-75-35.

To differentiate between beams and columns or bracing, or any other structural component (e.g. windposts) a description is imperative:

An RC column would need to be SS-15-10-75-70-ConcreteColumn (as part of a Reinforced Concrete Framing System)

An RC beam: SS-15-10-75-70-ConcreteBeam.

Without a doubt, in this case, Uniclass v2 is a regression. So much work has been carried put improving the old Uniclass to allow for these requirements, the new proposals should build on previous lessons learned, enhancing rather than classifying for a classification structure’s sake. The structural items need far better segregation. The only alternative is to shift to the Product, PR, table, where concrete beams and columns can be specified… but not steel. From the CPIC website, it states that CPI and NBS need to “actively promote the new Uniclass on its merits, of which coherence and suitability for BIM will be the most significant.” There’s still a bit of work to do before coherence and BIM suitability will be proven for structural engineers! (At this point I will also mention that there is no classification for HVAC either. That is split into Heating & Cooling, SS-60, and Ventilation and Air Conditioning, SS-65. Take your pick, mechanical engineers! It’s one of the most basic classifications you use.)

  • PR (PRODUCTS). The “off the shelf” parts of a system, a catalogue item. For example, a door hardware set, a lintel, even a pre-cast concrete stair (PR-32-90-15) are all products.


    It is, or rather should be, rare that these are modelled graphically in BIM. They would typically form part of the meta-data of an object, and in which case may not be classified in the BIM system itself. Of course this is a generalisation, and there may be times when products need to be modelled – the pre-cast concrete stair being an ideal example. In these cases the PR codes might be used to be able to select and turn off the display of these objects separately from the System objects.

  • WR (WORK RESULTS) = specification, or as described by Uniclass marketing as the “alignment” table. It repeats the System and Products tables to be able to correlate them for the project specification. In terms of BIM work, this table is somewhat redundant as the necessary classifications can be used directly from the Systems and Products tables.

For BIM, the theory seems to be to use the System table, SS, unless there is a reason not to. (Note: theory. Please feel free to argue an alternative viewpoint, I’d be interested in the debate.)

The last part, missing from these new proposals, is the AEC (UK) Table Z that was incorporated into an earlier version Uniclass. There don’t appear to be any plans to update that for Uniclass version 2, certainly none that have been published at any rate. Perhaps it is assumed that, as these parts are never going to form part of the specification or the finished building, they don’t need to, or shouldn’t, be classified. But they do need to be defined and referenced in an identical manner for consistency of model data. None of this is strictly a problem, as the AEC (UK) team will take that task on should it become necessary. For now though, non-physical elements (grids, annotation, hatching, drawing borders) have no relevant Uniclass v2 codes.

To summarise, how’s this all going to look when applied to a CAD layer or a BIM object? I’ll use a single example of a simple 200mm thick concrete wall.

The layer that used to be A-G2502-M-WallsConcrete would become:


The object, using the more BIM-software friendly AEC (UK) enhancements, would be: