Asset Tagging - Tracking the Duty of an Asset not the Product

by Iain Miskimmin

When we talk about asset information requirements we talk about the pieces of information we need to answer critical questions throughout the life-cycle of a “thing”.

There will be databases, documents, drawings, metadata, spreadsheets, 3D/4D/5D 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 a unique identifier that will help us link every instance of the asset at every stage and in whatever form it appears.

This unique identifier is called an asset tag, and it is associated with the “Duty of the Asset”.

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.

Strategy

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.

Concept

During the concept phase, we may just know that a structure is required in a specific location, but we have no idea of its make-up 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. 

Design

When we get to the Design phases, we will know much more about the make-up 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.)

Construction

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. 

Asset Register

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 Project Information Model (PIM), 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 life-cycle.

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.

Temporary works

We need to treat our temporary works the same way we treat our permanent assets. I am 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.

Naming convention

There are two polarised views on how we should deal with an asset tagging strategy. One view is that the tag should contain useful information about the asset - the other view is 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 (Facility code) – Functional grouping code – Function – 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.

Open to All BIM session 23rd March

By Iain Miskimmin

On the 23^rd of March COMIT held an Open to All session aimed at giving a common understanding to all parties about this thing called “BIM”.

Even though it was sponsored by one of our technology members, Bentley Systems and we are a mobile technology community, the session was not about software but about the background, reasons, standards, methods and principles that need to be understood and linked together to really understand what it’s all about.

The 16 strong audience was made up of Owners, Contractors, Consultants, Universities and Technology vendors. Some were just starting down their BIM journey, others were BIM consultants for their organisations, which meant that the conversations and discussions surrounding each area of interest were a learning curve for everyone!

The session started with the financial crash and looking at what options the UK had for growing the economy. This spawned the Construction Strategy and ultimately the drive to deliver BIM on all government funded assets.

Taking the audience through the Government Soft Landings document and it’s vision for a more socially, economically and environmentally positive outcome for our assets, it then plunged down through the details of what is an asset, how do we break then down, and how we ought to identify the duty rather than the product.

Finally taking everyone through the 8 pillars of BIM wisdom and making sure they know why they are being asked to comply with things like COBie, Uniclass and the suite of 1192 documents.

The big lesson from the event was that we have things in place to manage, process, secure, classify, exchange, number and identify our assets, but we are still lacking the fundamental building block of WHAT information we require at each stage (not for a product but for an assets duty).

This information is needed to answer the critical questions throughout the life-cycle, but these still have not been clearly defined.

Everyone in the audience will have different critical questions to answer, depending on how they engage and interact with an asset, but they all understood that delivering the information using the same classification, asset data dictionary, templates, libraries, coordinate systems, standards and workflows ensures that there is a consistency involved that significantly reduces the risk of whole life-cycle asset procurement.

Some of the COMIT member feedback so far:

“Your fire and your enthusiasm for the topic “BIM” was absolutely infective and exemplary.” - Owner

“May everyone get the chance to join one of your presentations, you are indeed preparing the ground for reaching a new level in the construction fields.” - Owner

“I found it extremely useful and very interesting” - Contractor

“Highly impressed of what can be done and we all took inspiration and understanding with us” – Consultant

“The best BIM overview I have seen delivered anywhere. It’s a must for all people interested in this subject” - Contractor

“Presented in such a way we can all understand what our part is in the BIM story” - Academics

“Thank you for your time and extremely interesting and well-articulated presentation, even though we felt ourselves BIM aware, this session took us to new levels of understanding” – Technology Vendor

If you would like to know more about BIM or COMIT, then please visit our website or contact us to see how you could get involved.

AI Go challenge win spells boon not doom

So Google's AI has won the final game in the Go challenge against a master player - making it 4 games out of 5. If you are unfamiliar with Go or with the challenge then you might want to read the BBC story about the victory.

This has prompted a new spate of humans-doomed-by-AI stories. However, this misses one fundamental aspect that seems to be missing in a lot of the stories about AI lately - namely that they relate to the application of AI to things that people are naturally bad at.

When applying any technology to automate a human activity, be it physical or mental, it makes total sense to look at activities that human beings struggle with. After all, there has to be a commercial aspect to the application, even if to start with only in principle. Nobody would argue that mechanical excavators are a threat to a species with a finite capacity for digging, rather they are seen as a boon, so what is it with AI and games?

Games, by definition, need to be fun and an important part of that comes from the challenge they represent - they need to be hard and require some effort to learn, to play or to master. Go is a game that has a perfectly logical basis but a vast number of permutations. Part of the challenge to a human player is to persuade that three pound organ of general intelligence in our heads to apply itself to that domain. This is not easy - it is not a task for which our brains were optimised by our evolutionary past; which is part of what makes it fun.

However, those same brains can determine what are more optimal strategies and while we cannot change our brains to apply them we can embed them in machines that do - machines dedicated to that domain. So we can create computers that can beat Go Grand Masters - or even the best human players at "Jeopardy".

The mistake, is to assume that because we can do something as humans and we find it hard, that means it must be fundamentally hard to do - or alternatively, that because we find something easy, that it must be easy to do. I'm old enough to remember that in the early days of AI it was assumed that it would take a long time to develop a human-beating chess computer but a relatively short time to develop software that could understand human speech. That assumption could not have been more wrong. Chess turned out to be a relatively trivial AI problem, where as speech recognition in comparison was fiendishly difficult.

So what does this mean for the Google AI Go victory and why is this article on a construction related blog? Well, the point is that AI is getting better and better at doing the kinds of things that people find fundamentally hard to do - and as it happens the construction industry contains a great many of those things.

The way in which we currently estimate, plan, schedule, manage and design has many aspects that require human beings to make decisions that they are fundamentally bad at. Decisions where people are apt to overlook things or make mistakes or simply reach non-optimised solutions. The construction industry has made great strides in mechanising (and even automating) its physical processes and it has certainly applied computer technology to marshalling ever increasing amounts of data - but as yet the use of AI to help the decision making process is all but absent.

The application of domain-specific AI to construction could lead to as many benefits as mechanisation. It could free people up to do what people are good at and lead to major improvements in quality, efficiency, safety and most importantly for all of us working in the industry, job satisfaction. The concept of "big data" is just starting to touch on that potential but the application of the kind of AI involved in the Go challenge could and probably will be revolutionary.

So if the current AI developments are a boon, when should we start to worry? Probably when it becomes artificial general intelligence and starts to be better than us at things that human beings find easy to do. Such as understanding the meaning of something within an arbitrary context - or even convincingly demonstrating an understanding of what meaning actually is.

Oxford Brookes & Gender Balance in Construction

I had the pleasure last night of delivering the COMIT guest lecture to second-year Construction Project Management and QS students at Oxford Brookes University. Part of our remit at COMIT is to engage with the next generation of construction professionals and this fixture has become a regular event on our calender. Previous lectures have been delivered by Neill Pawsey and Stephen Smith as well as by me.

The lecture is primarily about the use of mobile computing in construction. However, I always find it helps to put things into context so I inevitably cover a number of the broader issues that the industry faces - particularly those that influence the use of technology - as well as a bit of history.

Since yesterday was International Women's Day it made sense to touch on the issue of gender balance - or more accurately imbalance - in construction. This is something that I have always been aware of and during my time working in the industry I have been pleased to see it improving.

However, it was not until I went hunting for some actual figures to use in my presentation that I realised just how bad the situation is:

(Image source: http://www.cnplus.co.uk/Pictures/web/u/v/e/Gender-balance-by-sector-ons-data-on-percentage-of-women-in-each-industry.jpg)

I was not surprised that construction is among the worst industries for gender imbalance (I expect mining would be similar if separated from energy and water), but at 12% I was surprised at just how bad it is. Especially since, as I mentioned earlier, I have seen significant improvements in my time in the industry. When I first entered construction some twenty years ago female site engineers were virtually unheard of. Now, in some companies I deal with, close to 50% of new graduate engineers are women.

This imbalance is something that has always be in evidence at COMIT community days. There have been a number of campaigns recently aimed at getting more women into engineering in general and into construction in particular. COMIT strongly supports these initiatives, but it is hard to know how best to help beyond re-posting positive messages on social media.

I was encouraged to see a number of women in the audience at Oxford Brookes and afterwards I spoke to Henry Abanda, Senior Lecturer and organiser of the event about the gender balance. Henry made a really interesting observation - although they had far fewer women on the course than men, the women tended to be among his best students.

I assumed this would be because they were more motivated - if they are seeking to join an industry that generally seems to discourage women and have overcome the societal expectation that it is a "male" career, then they must really want to be civil engineers. But Henry put me right. Almost without exception the women on the course had relatives who already worked in construction. Consequently they knew exactly what they wanted to do and exactly what they needed in order to do it.

For me this was a light-bulb moment. Women with first-hand knowledge of the industry know that it can be a rewarding and fulfilling career choice for them and while, given the poor gender balance, there are still many barriers, these are not significant enough for their relatives already in the industry to succeed in putting them off. In other words the problem is not just one of internal reality but of external perception.

I believe this is reinforced by the furore that erupted around the Construction Computing Awards ("The Hammers") last November following the sexist nature of the entertainment booked for the event. While the organisers clearly failed in their duty to ensure the material was appropriate, what strikes me is that the comedian concerned equally clearly held the view that a "construction" event was akin to a old-fashioned northern working-men's club.

This point is made by some of the commentators on Sue Butcher's excellent blog about the night. Many of those within the industry found the "entertainment" offensive, but those providing it were not familiar with the industry and clearly thought it appropriate.

Given that women only make up about 12% of the construction workforce the industry clearly has a very long way to go. However, the improvements that have taken place over the last couple of decades are dramatic. I would have imagined that would have been the hardest part - actually changing attitudes and the opportunities for women within the industry itself - but perhaps the hardest part is actually communicating those changes to the wider public.

Maybe re-posting positive messages on social media is not such an insignificant contribution to improving the gender balance in construction after all.

BIM - Employer's Information Requirements (EIR)

By Iain Miskimmin

Be careful what you ask for!

The EIR is an Employer’s chance to define their requirements for information, but they need to be very careful what they ask for. Too prescriptive and you are preventing innovation and progress, too loose and you will probably receive something that you did not expect!

As an Employer, if you just demand that you want Level 2 BIM, you may be sadly deluded in the fact that it has not been finalised and will not go down to the level of detail required to stop the Employee running contractual rings around you.

If I asked every one of you to put the word BOW into a sentence, then I would get many different answers or interpretations of my requirement.

• I play a bow and fiddle...
• I shoot arrows with my long bow...
• The middle of my arm is an elbow...
• The front of the ship is called a bow...
• When meeting the Queen I bow...
• I wear a bow tie with my dinner jacket...

To get the answer you require you need to define the context, the same applies when asking for BIM. So let’s start at the beginning. Why is it an Employer’s Information Requirement rather than a Client’s?

The EIR needs to be present and used at every level of the supply chain, not just during the relationship between the client and the tier 1 contractor. Everyone at every level needs to understand what is needed of them and to be able to produce their information to the same quality. We are all employers, all the way down the supply chain.

So, let us state the obvious: A considerable proportion of the cost of creating information about an asset is not clear at the beginning and picking the lowest bid will not always get you the most cost effective asset information. To combat this, we need to be more specific about what we want. We do not necessarily have to define how the employee creates that information, but we do have to make sure they understand the validation it needs to go through and the way it needs to be delivered, so that you can make the best use of the information that you, as the employer, are paying for.

Contents

In the end, the EIR is what YOU want, not what others think you should be asking for, so the table of contents needs to reflect your priorities. The best way to test your EIR is to ask it a plain language question (see the AIR document) and see if you can get an answer that will help you to make a good decision in relation to the asset. If you cannot, then it is time to go back to the drawing board.

When writing what you want, you need to make sure that whatever you receive has gone through a rigorous enough validation process that you can trust what it tells you. To do this you must think about what is delivered, how it is delivered, who delivers it, where they deliver it to and when they hand it over (I also include validation in the delivery).

In the beginning

It is suggested that at the beginning you may want to define the following:

• Priority of contract documents
• Obligations of the employer
• Obligations of the employee
• Electronic data exchange
• Use of information models
• Liability of the information model
• Termination
• Definition of the Social, Environmental and Financial outcomes and the 3 year term used to measure their success.

People

We must then think about the people who are required to deliver the information. We must ensure that all members of the supply chain give someone the responsibility of delivering the information requirements. This is normally a GSL (government soft landings), IM (information manager) or BIM role that understands the importance of information and the risks of poor quality information.

A good source of information on this might be BS1192:2007

If their supply chain does not have the level of skills required for the project, this should not be a barrier to engagement and so defining how they might up-skill those people is an important response to the EIR in the BEP (BIM Execution Plan) - but unless you ask them how they might do this, it will not be a part of their plan.

What information might I get and what do I have to provide?

So that the Employee can respond with clarity, you must be clear on what information they will receive in the briefing data drop. This should be defined in the AIR and reflect your current assets and constraints. The AIR will tell you what information is to be provided, but the EIR will give the specifics of this particular project.

You also need to define what Common Data Environment the Employer has in place that the Employee needs to either use or interface with. This may also ask them to define a master delivery list within their BEP.

OIRs, AIRs and Classification systems

To ensure that the entire supply chain from top to bottom understands the client’s vision and the objective of the project, the EIR must define some of the Organisational Information Requirements.

The Classification of assets, or how we commonly identify things is important to allow the employee to structure their information and ensure we are all speaking the same asset language.

For example if Employer classified a particular asset as a stool, the tier 1 as a chair and the manufacturer as a seat -  and I asked the question “how many chairs are on site?” I could get very different answers, depending on who I talked to.

It must also reference the AIR, which needs to be comprehensive in its definition of the information needed at Facility, Entity and Element level.

Data Standards

To ensure that information can be federated into a joined up Data Model, we must make sure that everyone is using the same libraries, templates and coordinate systems etc.

• File attributes/ metadata
• Container naming conventions
• Location coding
• Zoning methods
• Suitability codes
• Revisions and versions
• Coordinate reference systems
• Units
• File formats
• Digital model file sizes
• Classification (data & Information)
• Security

This is not an exhaustive list but gives you a starting point.

Two things to note here are that you are not defining how the employee creates information, you are defining what it is when they deliver it. Also some may not think that size matters, but it does! If you do not define the physical size of the files you are expecting to receive, your own IT infrastructure might not be able to cope.

Libraries

It is really important that when generating information whether it is CAD, Document, Asset, GIS or Metadata that all the Employees follow the Employer's libraries and templates, so that this information can be picked up out of the PIM (Project Information Model) and placed in the AIM (Asset Information Model) without the need for translation and used to answer the questions that will allow good decisions to be made - i.e. taking into account everything known.

So with that in mind, the EIR must reference documents, standards or libraries for 2D & 3D CAD models, structured data, drawings and documentation.

Working methods

To ensure there is a consistency of information throughout the supply chain and all information that is generated no matter by whom, the EIR must set out a minimum standard of working methods to create a base line of quality and trust. This should prevent information being regenerated because of lack of trust between partners.

Procedures

Most procedures will already be defined in the standards and methods of working, but if they are not, then as a minimum the EIR needs to set out the processes for the following:

• Create/ Amend information
• Undertake container compliance checks
• Review and approve information
• Review and authorise information
• Review and accept information
• Mobilise resources
• Undertake assurance and change control
• Appointment close out

Benchmarking & certifying

During many projects we find that the Employees that were originally promised to the team are taken off and put somewhere else. They are invariably replaced (through no fault of their own) by less competent Employees which increase the risk to the Employer’s asset delivery.

To prevent this from harming the Employer’s vision of delivering a world class asset with a reduced maintenance and operations cost, the EIR should define how the Employee is assessed.

This should take place prior to the bid through some form of self-assessment tool such as the BIM Compass, during bid through case studies and finally throughout the project phase by ongoing  audits.

Summary

The EIR is a great method for ensuring that the Employers get what they need from the information delivered during the lifecycle of an asset, but it needs to be comprehensive enough to ensure that there are no misunderstandings. A good way of doing this may be to hold pre-tender briefings with potential Employees to explain in some length what is meant by each section and show examples of how it might be delivered.

It is a fine balance between dictating what is delivered and how the employee creates that deliverable. One reduces the risk of asset procurement and the other decreases innovation and pushes up costs.