Organising data for Asset Managment
The “Internet of Things” or “Internet of Everything” is grabbing the attention of many. Asset managers want a more cost effective way of managing their “things”, unfortunately acquiring the information from existing internet devices can be challenging and overwhelming. Yes, the data may be there and available using a legacy software application, or even using a local web browser, but too often it relies on users to interpret what is presented, making some sense of it and categorising it as useful or useless information. However, even if the information is captured in a data concentrator application like a SCADA system or subsequently pushed into a process historian or relational database like SQL, MySQL, Oracle or database management systems (DBMS), the data descriptions (meta tags) may not be organised in such a way that an asset system can digest it with ease. For ASSET MANAGEMENT systems, the acquisition of SCADA data is excessive (too much, too frequent and irrelevant). Unless the data is summarised and conditioned, it will never make the grade in terms of what the Asset Management system is looking for.
Important Factors in Marriage
There are key factors to consider when acquiring data from front end SCADA systems or similar operational applications for use by back end ASSET MANAGEMENT systems. The single most important fundamental is that the management of assets and the operation of assets are profoundly different. The data needs for an asset manager are vastly different to the data needs required to operate the asset. The conventions used to name assets and their operational attributes are never the same as the convention used in asset management or financial systems and their attributes. In fact the operational definition of an asset will always have different attributes associated with it than what is required for an asset management or financial system. While both sets of attributes are very important in their respective systems they are of less interest to the other system. What this fundamentally suggests, is that two different organisational minds must meet in the middle and either the Operational focus must align with the Asset team, or vice versa. This implies massive reinvestment costs if attempting to match an operational system to “marry” an existing enterprise asset system. Rarely does the marriage work without the right support. So what support is required?
Compromise, an essential part of good relations
Both Operations and Asset Management/Financial systems need to run effectively complying with industry standards. This focus should not be reduced by introducing new custom standards for either how to manage operations or assets without causing a divorce. Mapping information from operations to the relevant asset attributes smooths the transition of organised operational data so it can find its happy home in the right placeholder in the asset world.
This seems overly simple to describe in words but this would be a colossal understatement in reality. Historically this mapping concept was performed by extremely experienced software programmers with some learned knowledge of both operational data sets and asset management system interface expectations. The middleware custom application developed by these programmers to push Ops data to Asset databases, has never been easy to maintain. That has meant supporting one person who typically possessed all of the intimate knowledge and IP associated with “custom code”. It has implied supporting proprietary software and a higher degree of risk than most CIOs are comfortable with.
Does Big Data overcome these issues?
Mining unorganised information repositories and finding needles in the hay stack using sophisticated algorithms is a powerful deliverable of Big Data applications today. Yes this is available right now, for certain types of data. Although this can be compared to our Ops to Asset model described above, Big Data data stores do not compare to an Enterprise Asset Management system in any way. As valuable as they may be to any organisation, Asset Management Systems do not provide big data algorithm sorting functionality. EAM systems expect clearly defined and structured inputs.
What does this mean in terms of my Enterprise Asset Management System?
Many of the Enterprise Asset Management (EAM) vendors have struggled to acquire meaningful data about how assets operate in real time. At the best of times snap shot or summary data is presented as “conditioned” information at the back door of the EAM system. This isn’t bad, it is fit for purpose and as designed. If anything, it is exactly how you want it.
Understanding these issues with an impetuous not to reengineer either the Ops system or Asset system for the marriage to work, EAM gateways provide the very linkage with point and click functionality so it’s like match making one relationship at a time. The difference between this point and click matching is it works 100% of the time. No failed connections like you would expect from any other type of online matchmaking.
The point and click EAM Gateway means life just got easy. SCADA and Operational Applications as “unorganised” as they seem to be to Asset Managers, can be made to appear as perfect partners, if the right matches and relevant configuration is put in place at the time of inception. A little bit of planning by “data champions” supported by technology partners (not highly experienced customer application developers) means more sustainable management of the enterprise assets, including the information asset infrastructure than no longer needs to set off “spaghetti code” alarm bells to the CIO!
M is for marriage, M is for matching.
To see more about EAM solutions and Enterprise Information Systems and going beyond simple transformation of data between systems see: https://www.parasyn.com.au/solutions/#smartmachines
