Physical Objects & Data Corrosion
Over the years I've been lucky enough to see a lot of client asset management databases from a range of industries. There were some common themes that I'd continuously see, but I lacked a framework to explain any of these themes.
In a blog post last year I touched on the subject of temporal asset data in an attempt to explain some of the inaccuracies in asset management databases that I've encountered. The premise was that asset data is treated largely as a static entity in most asset management systems, when in reality the data is temporal - that is it has a start and end date to its validity.
I've since come across a significantly better framework to explain this - the work of the ISO15926 community. In an excellent web site on this subject the author states "...One of the key concepts of ISO 15926 is that of "temporal parts", providing the means to place information about instances of PossibleIndividual in the time. It is the cornerstone of lifecycle information integration...". Further reading from the same author can be found here.
So lets step back and see this in the context of my previous blog post on the Pool Shed.
Functional Physical Object
We have a process design which defines the functional physical objects to support the process. For example, we have two TAG's (E-2 & E-7) for pumps in the process. These functional objects exist on the design and are not dependent on the actual pumps selected for their existence. They exist for the whole life of that process design.
These functional physical objects come from the engineering process design and we would not expect this to change unless there is a corresponding engineering design change, such as changing the process itself.
By and large my observation is that the functional physical objects in asset management systems are relatively accurate - to put a number on it lets say >90% accurate. This data comes from engineering and doesn't change without an accompanying engineering change, which is typically very well controlled. But there are still a couple of common issues I see with functional physical objects.
In our process design we had another equipment item called E-9 / POOL FILTER. I've looked and looked, but I simply can't find that E-9 / POOL FILTER anywhere. That's not to say that its not there - it is saying that I'm unable to locate it. If I'm unable to locate it then it is going to be pointless telling my kids they need to go and clean this filter as part of their weekly chores.
Similarly, if you can't physically locate a TAG in your facility, sending a crew out to perform preventative maintenance on it is going to be a waste of time and money. Conversely, if you have verified that it can be physically located, have a geolocation to precisely locate it, and a photo to show the crew precisely where they can find it, then you remove any ambiguity and save a significant amount of time on the part of the people you are dispatching to work on the equipment. How much time are we talking about? Our clients report that it can take 3 hours or more to locate a single TAG in a large facility, and in other cases the TAG can't be physically located at all.
But just as there is equipment that couldn't be found, there is new equipment that was not on the process design. And if it doesn't exist in the asset management system, nobody is looking after it through its life to ensure its safe and reliable. At some stage over the last few years my pool guy had to replace E-3 / PRE-FILTRATION DEVICE. In order to do that I can see that he has installed a valve in pipeline P-5 taking water from E-3 / PRE-FILTRATION DEVICE to waste. My pool guy obviously just went ahead and did this when doing the job. For whatever reason he didn't reflect this change in an as-built update of the process design.
By and large though, the asset management system will generally be relatively accurate when it comes to the definition of the functional physical objects from engineering. Whilst the changes don't happen often, there is still an issue to ensure the process design matches the as-built physical facility on an ongoing basis.
Materialized Physical Object
When we select equipment to fulfil a particular function role that becomes the materialized physical object.
As I touched on in my previous blog post, my pool guy talked up the HYDROSTORM 100 from WATERCO. He suggested that for simplicity we should get the same model of pump to fulfil the function of both the E-2 & E-7 TAG's. My pool guy further agreed that as he was the prime contractor that he'd get me all of the equipment attributes (make/model/serial no) and documentation so I could have that as a reference for warranty claims, spares purchasing, and scheduling maintenance in compliance with manufacturer's specifications.
So we should be all set. I had an agreement with my pool guy to purchase the equipment we agreed on, install it, and provide me with all the information I requested. I placed my purchase order with him. I really needed this installed before the end of October as my kids were having a pool party with 30 kids coming coming over, and Melbourne's famously fickle weather meant that you needed to have heating in place or it wasn't going to happen.
My pool guy however had other commitments at that time, so he subcontracted the job to a mate of his. The subcontractor grabbed equipment he had in stock that met the functional engineering requirements as my pool guy hadn't given him enough time to arrange purchase and delivery of the agreed equipment and still meet the required installation deadline. The subcontractor also told me that he didn't have time to get the equipment information together that I had agreed with my pool guy, so I had a choice - force him to get the information I requested and delay the installation and cancel the pool party for the kids, or drop the information requirement and get the installation completed in time for the pool party to continue. So of course I dropped the information requirement, got the system installed, and the pool party went off as planned.
I see clients all the time that have spent years and literally millions of dollars specifying extremely detailed handover requirements. However, the reality is that it is an overhead to the contractor and when faced with a choice of supplying information, or getting to startup on time, every project manager is going to drop the information requirement.
So at the end of my swimming pool project I'm left with the following data about the equipment I've purchased - looking at TAG E-7 as an example.
The functional physical objects have been handed over well, but the materialized physical objects are sadly lacking. That mimics what I see among our clients. The engineering data handover is getting more sophisticated, commonly using systems from Intergraph, Aveva or Bentley Systems as the platform for engineering handover. And as long as there is a solid process to ensure that the functional physical objects from engineering are easily physically locatable and are kept up to date with the as-built facility, that side can generally be pretty accurate.
The materialized physical objects on the other hand are where there are huge issues. These objects are temporal in that they can, and generally are, swapped out over the life of the facility. In my own swimming pool scenario, as I'll describe in future posts, all of the equipment I originally had installed has been replaced over time as new models were released and the cost to repair individual items exceed the cost of installing new items.
In my small scale case I can simply walk into my pool shed and get all of the materialized data that the subcontractor failed to deliver from the equipment itself, and look up on the web to get the documentation I require. But if I had a hundred thousand pieces of equipment spread over a geographic area of hundreds of square kilometres then I have a major problem.
Just how big a problem is this? If a client has more than 50% of their equipment with materialized data then they would be among the better performers I've encountered. I've seen clients with less than 10% of their equipment with materialized data.
Maybe it is obvious, but if you don't know what is installed then how do you ensure you have the required spares in stock, and how do you ensure your maintenance strategies are appropriate for the equipment? Your strategies are compromised.
As described above, the materialized data is temporal in nature. Just because you captured this data once, don't expect that to be a reflection of what is physically installed at any point in time. Change is constant, and whilst I'm not aware of definitive studies on this, a rule of thumb I've generally used with clients is that your materialized data could be expected to corrode at a rate of between 1% - 2% per month.
As a way of demonstrating this, I often ask clients if they were about to make a purchase of $100,000 would they blindly accept the contents of their asset management system as completely accurate, or would they send someone out to physically verify the name plate on the equipment. I've never found anyone that would just accept the content of their asset management system as accurate.
Thanks for reading this blog post. As always, I'd welcome any feedback