Scoping – Q0: Baseline preparation and understanding of existing portfolio.
Why do you have a portfolio of physical assets?
These physical assets deliver your business outcomes. To achieve this the client must understand the interaction between them by using a set of Organisational Information Requirements linked to the asset policies, strategies and plans with the assistance of the ISO 55000 framework. To create, manage, update and maintain this asset information is no easy (or cheap) task and the considerations listed in Question 0 help to understand the areas required.
If during the analysis of Q0 the information available is either missing or lacking in its support for the Organisational Information Requirements or ISO 55000 then the collection plan, Functional Information Requirements and the Asset Information Requirements will need to be updated.
Constant monitoring of your assets through digital or analogue means will help the business to understand the performance of their assets in supporting the business outcomes. So, when you identify a problem you either have the information to resolve it, or you have enough to understand what to procure.
Asset Information Requirements (AIR)
To make good decisions about our assets at any time throughout its lifecycle we need to have well defined good quality, consistent information and the Asset Information Requirements database is where to do this.
Making those decisions starts earlier than you may think.
Most of the assets we will interact with in the near future are either those that already exist or ones that will replace existing functions, i.e. a replacement or upgrade project. So, our asset lifecycle starts before we even know that we need something new. Having information about our current asset portfolio on how it is performing against a set of pre-defined criteria and if it is carrying out the function required by the business is imperative. This is coupled with information from our maintenance database recording how frequently and how expensive it is to maintain in its current state.
These two sets of information will tell us if we are achieving our organisational outcomes with the current portfolio and will inform us whether the asset needs to be replaced, upgraded, decommissioned, augmented or simply left alone.
The information that allows us to make this decision will need to be defined and recorded in a database called an Asset Data Dictionary, basically a big list of what information is needed at what point during its lifecycle and how it should be recorded.
This Asset Data Dictionary (ADD) is informed primarily by the asset strategy put together through ISO 55000 and needs to be based on what is needed or valued by the various end users of the information. As we have seen in previous chapters there are many different end users throughout the lifecycle and whilst this asset data dictionary ought to contain all of these requirements this would be a huge undertaking, so it is recommended to start with the areas that will give you the best value to your organisation.
Throughout this lifecycle information will need to be exchanged between various parties and this is described as a “data drop” and illustrated by a green “ball” in the various standards. The diagrams are slightly misleading showing that an exchange of data is only done at the end of a lifecycle phase whereas it needs to be more of a dialogue that is exchanged when required to answer a question, make a decision or carry out an activity rather than just a ball to be lobed over the fence!
At the beginning of the new projects lifecycle, a subset of the Organisational Information Requirements that are relevant or have an impact on this project will need to be taken into consideration so that the course of action taken, takes into account things like political will, social, environmental and economic impact when deciding what to do and how to define the new outcome.
Taking the information from the Asset Information Requirements and the Project Information Requirements combined with the live Digital Construction Expectations document, the client should be able to brief the supply chain as to their desired outcomes through the Exchange (Employers) Information Requirements (see section below). This needs to be done not only in a document but also through a series of presentations and workshop to ensure everyone has a common understanding about what is required.
This briefing package must also include existing asset information that is relevant to this project direct from the Asset Information Model.
During the concept phase the consultant will deliver conceptual ideas of how they will fulfil the client’s outcomes. There will be information that is important to the client and this needs to be defined in the AIR so that they can evaluate the different options delivered by the consultant depending on what is important to them. This concept will be made up of high-level functions that will fulfil the desired outcome.
The design phase will take those high-level functions and break them down into a finer granularity of functional units. The asset data dictionary will need to define how these are best described so the client has confidence that the consultant is meeting their needs and the contractor will be able to procure or create a physical thing to fulfil it.
Up until now the information build up has been focused around the functional requirements and the information to define, record, measure and monitor them. It is only now that we start to look at the products, materials or service that will fulfil this need. The information listed in the ADD here will need to reassure the client that whatever the contractor is planning will succeed in achieving their outcomes.
It is hoped that because there has been a constant dialogue of information exchanges between supply chain and client up until now, whatever has been designed and procured will meet the desired outcomes. This commissioning part of the ADD will define the information used to test both that the physical asset is fit for purpose and the information package delivered with it is correct.
During everyday operations, information on the status, performance and usage of the asset needs to be gathered to ensure the Asset Information Model is up to date. What this information is, needs to be defined and documented in the ADD. The AIM in turn will need to contain operational manuals, instructions and procedures to ensure the asset is run efficiently according to the outcomes of the organisation.
An interesting example of active feedback on status and performance came from a metro system in India. Many of the assets in the public areas had labels on them with a data matrix code and the commuters all had an App on their phones for timetables, alerts and bookings. The App also had a reporting function that allowed the user to let the metro owners if there was a problem with the asset. Simply by scanning the data matrix code, taking a photo of the issues and adding some text, the owners could gather performance, function and customer satisfaction against their assets, greatly enhancing the feedback loop.
Effective and timely maintenance is key to ensuring a safe and healthy asset whilst delivering the end user the outcomes they expect. Understanding what information is required for maintenance will be difficult without getting on side the people who actually do the job. A maintenance manager will only be able to tell how to manage and schedule a maintenance regime, whilst the engineer who knows what needs to be done will closely guard that secret to ensure they are kept employed. A significant amount of time and money is wasted in this phase due to not having access to trusted information. Don’t just think about data about the individual asset, but also how it will be accessed, the tools and PPE required, as well as the other assets physically or functionally effected when the asset is taken out of use for work to be carried out.
This is the phase you hope never happens and frustratingly is little documented in the BIM or Digital Twin world. If there is a fire, flood, terrorist or other incident then having rapid information that can be given quickly to the attending response team, can mean the difference between life and death.
The end user in these scenarios will be the police, fire, ambulance or national security teams that will limit the impact of an incident. They need to be engaged to define in the ADD what information they will need and how they need to consume it. I came across a great example in China recently where all the latest disaster information was synchronised into a tablet device, so it could be handed over to the incident controller when that emergency team arrived.
During decommissioning the contractor will need to understand any resale, recycle or reuse targets and follow specific instructions on ensuring assets are disposed of responsibly. This information will impact on the design and build phases, educating the consultant and contractor as to what is the priority.
Defining the data at each of these stages or data drops should be done by the relevant people asking the critical questions.
Having a comprehensive Asset Data Dictionary with its metadata definitions for each asset down to the maintainable level will deliver significant benefits to the client at every stage of the asset. However, if this is delivered on a nationwide level, giving a standard across the board to road, rail, power, water, prisons, hospitals and schools, we find that delivering our asset information will become more cost efficient, as contractors and owners talk a common information language. This also has a wider benefit of driving interoperability between technologies, as they will all begin to describe their objects in a common and interchangeable way.
Strategy for creating an ADD and metadata.
Without significant investment of time, resources and money a fully comprehensive ADD and its metadata will be difficult to achieve. So, an initial strategy called “Critical Questions” is used to help create our first iteration.
Critical Questions requires the ADD author to engage with a group of metadata users for each task in each discipline at each of the data drops that will be covered. These users will be asked to write down the critical questions they would ask in relation to a specific asset. Once analysed these questions will lead directly to the metadata needed to answer them. Using this methodology, we can gather significant amounts of critical metadata requirements for our ADD. Like with our OIR, the relationships between the metadata (information requirements) and the related questions needs to be kept so that this can be used later to track if we are successful and also to assist with role-based information sets. It is also useful to record how that information needs to be presented, whether in document, metadata, drawing or some other method.
The next step is to define the replacement criteria and required performance/ functionality. This information combined with ongoing condition and performance surveys will help to determine the degradation of the asset and with good analysis, will predict when the asset needs replacing.
Between these steps we should be able to collect at least 80% of all the information required across the lifespan of our assets.
In the example below we will use a humble, yet complex earthwork to show how this might be accomplished
We can have the best systems, technologies, standards, workflows, security and protocols in place, but if we don’t know what information will help us to answer a question, make a decision or carry out a task, then we cannot be successful in our digital asset endeavours.
ADD, AD4, PDT and PDS
This Asset Data Dictionary is populated by AD4’s (Asset Data Definition Dictionary Documents) each one will tell those working on the project, what information they are expected to generate, what form it comes in and when they need deliver it. The term document is actually a little misleading, the ADD is a database and the AD4 is just a report created from the database to tell someone what information is relevant to this type of asset.
By now most of the people paying attention to the BIM world will have heard both the PDT / PDS (product data template/ sheet) and AD4 terms being bounded around. Understandably there is confusion about them and worries that they are duplicating or wasting effort. In fact, they fit together very well indeed and compliment what is required to deliver our digital assets and our better decisions.
“The AD4 describes what the information requirements are, and the PDT provides the information to answer those needs”
The Asset Tag concept is covered in another chapter, put simply, the tag is a collection of information that helps define what the asset is, what it needs to do, what is it part of, what information is legally required.
The Blue Side covers the AD4 and the green side that tells you what equipment, product or material will meet the requirements of the blue side is the PDT/ PDS.
“When we look at a complete lifecycle, very rarely will we know what product, equipment or material will fulfil the requirement until we get to the construction phase.”
“When we are maintaining something, at some point we will get rid of that product and buy a new one based on the AD4 generated requirements, rather than replacing a like for like product.”
In summary the AD4 tells you what you need, and the PDT ensures you get what you require!
Asset Breakdown strategy
One of the key items on any digital journey for an owner should be to work out their asset breakdown strategy. This helps them to understand the links, dependencies and interdependencies of their assets. So, if one asset does not function as required whether through planned maintenance, breakdown, vandalism or natural disaster then the impacts on their other assets and the overall functions that support your business outcomes is understand.
This impact study will define what urgency and resources are put into rectifying the issue.
It is also paramount to define your asset breakdown structure so that it forms the basis of how your CAD team set their modelling strategy.
There are many different types of links and dependencies, the most common being the systems that the assets are part of. But others might be human, financial, political, maintenance, operational, environmental and functional to name a few. Each of which will take time and effort to map but will allow the owner to truly understand the impact of their asset on many levels.
If this is being done for a new asset then it can be a part of the design, but when it is existing, especially when its infrastructure related, then the following should be taken into account:
It will be a system of systems
It will not always obvious
It can be buried and hidden
It will be complex in their own right
It will have evolved over time
Ownership will have changed over time
There will be multiple suppliers
They will have been upgraded at some point
Parts of it will have become obsolete
They will be poorly recorded
They will be recorded in different formats and on different systems
They will be heavily dependent
They will be interdependent
They are all deeply connected
They will not be isolated to one sector
Whatever the reason for creating the links and forming the breakdown structure, it should always be done with the end in mind, so talk to the people who will use this information and find out what is important to them before spending time and money creating it.
There is a generic hierarchy naming and explanation convention that will help.
The level you go down to will depend on the time and resources you have available.
Levels of Information Needed
This breakdown structure also helps us during the lifecycle to define our levels of definition. If you imagine a new road project, at briefing phase, we know a new road Facility is required. We can create an identity for that level and start to hang information off of that instance. Moving into the concept phase, we now know that there is going to be a bridge Primary Functional Unit along that road, we can create an identity and build up further information that will impact the Facility.
In the detailed design phase, we now can identify Functional Units and individual Elements that will make up the PFU. Once again allowing us to build more information that will have an impact all the way back up the asset breakdown structure.
Finally, when we get to construction, we can then talk to the manufacturers who will supply us with products that will be specified by the functional requirements at each level.