When we talk about asset information requirements we talk about the pieces of information we need to answer critical questions, make informed decisions or carry out key activities throughout the lifecycle of a “thing”.
There will be databases, documents, drawings, metadata, spreadsheets, 3D/4D/5D/6D models and all number of pieces of information generated in many forms before we know what physical thing or product is going to fulfil that role.
We identify this virtual need and the space it occupies with an Asset Tag, this in turn has a unique identifier that will help us link every instance of the asset at every stage and in whatever form it appears.
This Duty, is the specification of what the thing needs to achieve. During the early phases of a project we know very little about what we require, but there will be critical questions that need answering with information generically defined in our AIR but attached to a specific instance.
Why do I need to know what type of thing I am?
- It creates a common understanding as to what I am.
- It helps to categorize me with like minded things.
- I can be quickly identified and critical information associated with me.
- My performance can be assessed against all the others of my type.
Why do I need to know what function I carry out?
- It ensures that I meet the specific requirements at every stage of my lifecycle, even when nobody knows which piece of equipment will fulfil this.
- It helps to set my performance criteria for continued monitoring
- When I need to be replaced there might be new technology that will do this better
Why do I need to know what functional group or system I belong out?
- It associates me with those things that I interact with and work together to perform a joint functionality
- It identifies other things that may be effected if I stop working
- It helps to ensure I can be isolated and the impact of my existence is understood.
Why do I need to know what information is important at any stage?
- At every stage, there will be important decisions to be made, this ensures that information is available and in the right format.
- This information helps answer critical questions fast and efficiently when time is of the essence. i.e. Disaster situations.
- This helps the project understand what information is required, when and why.
Why do I need to know my location?
- When I am being designed and constructed it is known where I will be placed.
- If something happens to things in the same location as me, their impact, even if not part of the same functional grouping can be assessed.
- It’s the first question anyone asks, “Where is it?”
I need to how I will be identified because
- When I am identified on any media (drawing, document, model, database etc) I need to be unique.
- When someone notices a problem in the physical world, I need to know they have correctly identified me.
- When the physical equipment that fulfils my function is replaced, it helps to ensure that we are talking about the same thing.
These need to be kept relevent and deliver value at every stage of the lifecycle.
When we are thinking about the overall Strategy we will need to generate information on a facility level to ensure what we are creating provides the social, environmental and economical outcomes desired. In infrastructure these tags will typically be for hubs or connectors.
During the concept phase, we may just know that a structure is required in a specific location, but we have no idea of its makeup or design. Thus it is essential that we start tracking the fact that there is a need for a structure here, and pursue the questions that need to be answered. By acknowledging this, we can/should assign an asset tag at Entity level.
When we get to the Design phases, we will know much more about the makeup of the structure and be able to tag an asset down to Element level, thus providing that unique ID for each individual asset down to the maintainable level. (i.e. a window rather than the glass, sealant, hinges, locks etc)
All the tags starting from Facility, through Entity and down to Element should be related in a hierarchy to show how assets are associated with each other and their breakdown structure.
Finally, when we arrive at construction we will have built up a set of performance requirements (the duty of the asset) and we can use this information to go and purchase a product to fulfil that role.
The asset tags at various levels have appeared in all the documents, drawings and models during this build up, but the most important place for them to be is in the asset register.
This register of assets needs to be accessible from every information creating, gathering and consuming system used in the PIM (Project Information Model), ensuring the “things” mentioned in all these sources of information are linked back to the relevant asset tag, this enables us to have all the information required to answer our critical questions throughout the lifecycle.
This asset register will not only contain information about the duty of an asset, but eventually it will include information on similar products which can fulfil that need, along with all the information about the physical thing.
My advice here is to never lock this register away in a CAD package and restrict its access to a small percentage of your team. Data is for databases so that it can be analysed, reported and linked rather than duplicated.
We need to treat our temporary works the same way we treat our permanent assets. I’m not suggesting that we tag every piece of scaffolding, but we are recommending that it is broken down into “supporting service” level, where each temporary works element supports a maintainable asset.
We should record these the same way in every drawing, document or model and ensure that they appear in the asset register to help answer any critical questions. Bear in mind that if they are abandoned in place, they will need to be handed over just like any other permanent asset.
There is a difference
As you have seen, the term “Asset Tag” covers what we want the asset to do, not what physical thing that performs this duty. This in turn, is different from the identification code we use to ID this duty during the lifecycle and finally it is different from the physical label affixed to define where this duty is required.
AD4s and PDTs
Whilst looking at your asset tagging strategy you will come across the two terms AD4 (asset data definition dictionary document) and PDT (product data template)
The AD4 describes what the information requirements are and the PDT provides the information to answer those needs.
There are two polarised views on how we deal with an asset tagging naming strategy. Firstly that the tag should contain useful information about the asset and secondly that it should just be a unique ID that means nothing, because all the information is kept in the asset register/ database.
If you wish to put meaning into the name, then I recommend the following:
Location – Functional grouping code – Classification – Unique numerical number.
This will allow you to understand how assets relate to each other and the function they play without needing to delve into the asset register/ database.
Thanks for reading!
Please enjoy a limited number of articles over the next 30 days.
For total access log in to your The BIM Hub account. Or register now, it's free.