In a blog post last year I touched on the subject of Big Data in the form of images that are now cheap and easy to capture, even in hazardous areas. In this blog post I'll explore that a little further, along with the limitations of current approaches.

The story so far...

In my previous blog posts I've discussed how I am using my Pool Shed as a platform to describe some typical asset information challenges. And in the most recent blog post I described the different components of asset data - functional & materialized physical objects - and how temporality of that information can cause particularly the materialized data to corrode over time at quite a significant rate.

After reading all of that you might be left thinking that it is all doom and gloom when it comes to asset information. But if I was to contrast that with another asset I own I can see a different situation entirely.

I have a more significant asset - namely my car. I know the make and model of my car, the registration number, and quite a lot of other information that was handed to me at time of purchase. I subcontract maintenance to the local dealership and they manage even more detailed information on my car. 

The downside to that is that I'm wholly reliant on the dealer to be giving the most cost effective solutions - but even that is changing as cars get smarter and provide even richer data on optimum service requirements.

Not all assets are equal, and just like I and my subcontractors know my big/expensive assets relatively well, our clients tend to know their big/expensive assets relatively well also. Whilst there are alway exceptions, large equipment items such as compressors, turbines, generators and the like tend to be more accurately documented than smaller equipment.

However the consequence of failure is not dependent on size/cost of equipment. A fuel pump by itself might be an inexpensive item, but if its role is to supply a generator then a failure of the fuel pump stops the generator which could lead to a greater consequence. Criticality is used as a measure of consequence and we see a lot of equipment with high criticality that has missing materialized data.

Why Big Data in the Pool Shed?

I honestly can't remember when a tradesman of any description came to my house and didn't have a smartphone, and the guy that installed the equipment in the pool shed was no exception.

It is commonplace now for tradesmen to take photos of their work, or the work of others. And a quick search for tradesmen banter  reveals countless Facebook, YouTube and Twitter posts sharing the good, bad and ugly - all recorded on their smartphones.

But one of the more mundane aspects of using a smartphone on site is that it provides a quick and easy method for the tradesman to record precisely what was done on the job. What was installed, where it was installed and when it was installed - all with just a few easy clicks.

So whether it's the tradesman installing the equipment in my pool shed, or someone installing or commissioning equipment in an industrial plant, they are increasingly utilizing digital photographs, and typically on a smartphone.

The guy that installed the equipment in my pool shed took lots of photos of the equipment he installed. Photographs of equipment on a smartphone can be taken very quickly and easily. It was a trivial effort for him to create a record of his work.

Lots of Data, no Information

Having lots of photos of the equipment in the pool shed is one thing, being able to do anything meaningful with it is quite another thing. It is useful to the pool guy in the immediate aftermath of the installation if he needs to refer back to what he did, but not much use to anyone else. The usefulness relies entirely on the photographer's memory of what he took the photos of. So with a limited set of equipment he could probably rely on his memory for a few days after the installation - long enough to sort out any issues if they arose.

Now, let's consider the following couple of photos to demonstrate this. The pool guy takes photos of the name plates of two pumps so he has a record of which pumps from his stock were installed on the job. But there is nothing in this photo that ties these materialized physical objects to the functional physical objects. How do you tell which name plate belongs to TAG E2 and TAG E-7? The file names don't help either since the smartphone names them something like Photo 20-7-2014 10 24 57 am.jpg. All we can tell is that 2 pumps have been installed and when they were there.

Our smart phones can generate very large image libraries, so after the immediate usage has passed the images are usually either deleted or dumped on a server share drive. An iPhone from 4S through to 6 has an 8MP camera which can typically generate 2.5MB files, whilst a Samsung Galaxy 6S has a 16MP camera which can typically generate 5MB files. For the purposes of photographing equipment however there is little to be gained going beyond 1.5MB files so scaling becomes important if you are going to efficiently store and access them for the long term.

Big players in the industry such as Google and Apple have invested significant time and money into photo cataloging, with automatic image scaling, so that we can easily know when, where and of who photos were taken. And whilst that works incredibly well for photos of people and places, for photos of equipment it doesn't help us. The end result I've seen over the years is clients taking photos of equipment, and then dumping them on a server never to be seen again after the immediate requirement has passed

Turning Data into Information

At ORDITAL we are leveraging the wide availability of smartphones to allow many thousands of high resolution photos to be easily captured in such a way that they can be turned into meaningful information that fills the asset information gaps on materialized physical objects on an ongoing basis. To truly ensure that your data about your assets matches your physical assets and deal with data corrosion.

In coming posts we'll be delving into more detail on how this is achieved. In the mean time, I'd love to hear from you.