Utilities: How to define an Asset Data Model for Operations and Maintenance when no Industry Standard exists.

 

At Modelical, we help define asset information requirements for many clients across various sectors, including electric utilities, water companies, and data centers, among others. We frequently encounter a common challenge: determining the best way to identify each asset and its associated properties to meet different use cases for operations.

 

Let’s take two very different types of projects as examples: a data center and a desalination plant. In both cases, it is useful to know the material composition of certain elements. However, when we delve into the details, for a desalination plant, it is essential to have readily available the property “Test pressure,” defined as the pressure to which an object should be subjected to test for leakage and structural integrity, for assets like pumps, compressors, or mixers. On the other hand, in a data center, it is far more important to know the “Load capacity,” defined as the maximum amount of electrical power that the Power Distribution Unit (PDU) can safely distribute to connected devices.

In both cases, it is crucial to classify the pump or the PDU to be able to compare, aggregate, or monitor data across various projects within a portfolio.

 

Let’s add another example: a pump in two different situations—a pump room in a residential building and a desalination plant. The object is the same, but the associated maintenance, inspection, and consequences of any failure are very different. Consequently, the data model for both situations will not be the same. In the second case, it will be important to describe the process it serves or the discipline involved, while in a residential building, that detail is not relevant.

In the following, we explain how we addressed this need for one of our clients in the water sector.

Create an Ad-Hoc Asset Classification or Use an Existing One?

This is the first question we ask ourselves. Classifying assets is important to identify them within a portfolio of projects. Without a standardized classification of assets and properties, we cannot analyze data.

However, existing classifications may not always fully meet our specific needs

Recently, in Spain, the Asociación Española de Abastecimientos de Agua y Saneamiento (the Spanish Association of Water Supply and Sanitation) launched its own classification. In the United Kingdom, British Water is also working on its own. However, when we began this project in 2022, none of these classifications were available.

Should we create our own classification? The answer is no. We continued researching similar process-focused sectors and decided to work with CFIHOS, a mature classification from the Oil & Gas sector, which had many common points with our needs.

 

What is CFIHOS?

CFIHOS is a standard developed to define and manage the information required throughout the lifecycle of large-scale industrial facilities, from the design and construction phases to operations and maintenance. CFIHOS provides a common framework and set of requirements that ensure critical information is properly collected, organized, and transferred among stakeholders and project phases. The CFIHOS documentation includes:

• Technical specification
• Data model
• Implementation guide
• Dictionary
• Software requirements for implementation

You can read more about its evolution over time here.

 

Why did we choose CFIHOS?

In 2022, with no existing standard for the water sector, CFIHOS offered the following advantages:

• A mature standard, in use since 2012 by process industries like oil and gas.
• A standard focused on ensuring that asset information is correctly transferred to Operations.
• A robust data model with a proven hierarchy and relationships between entities.
• A comprehensive asset classification.

These aspects provided us with a reliable foundation to meet our client’s needs. The following diagram shows part of the data model schema published by the organization that we adapted to our case.

 

Example of the CFIHOS data model structure and relationships.

 

Ultimately, using an existing classification is preferable to creating a custom one. Why? Because experts in the field have already invested time in developing an initial version, which has generally improved with input from other companies in the sector.

 

How we adapted CFIHOS to the Water Sector

In an initial phase, in collaboration with SENER, we listed all assets involved in the different types of projects, organizing them into a hierarchy according to the data model defined by CFIHOS. It is worth noting that the typologies are varied, including plants, stations, or networks.

We made some strategic adaptations to ensure it met all our needs while maintaining the objective of developing a system compatible with the original standard. The proposed hierarchy is as follows:

• Site: A code defining the region or zone where it is located. Defined by the organization.
• Plant: Asset identifier, grouped by typology. Defined by the organization.
• Process: All possible processes in different types of projects were listed. While discipline helps to group assets, it is critical in these types of projects to identify the process they belong to.
• Subprocess: All subprocesses or systems associated with each identified process were listed.
• Component: Each of the final assets to which we associate information. These components can later be broken down into subcomponents.

 

 

 

When we reached the smallest unit, the component, we assigned the corresponding CFIHOS code to that asset. In some cases, the level of detail in the standard was not sufficient, leading us to create new components. Overall, of all the assets listed, 50% came from the standard, and the other 50% were added by us to cover most of the elements found in these types of projects.

We conducted the same exercise with the properties that each object should have. We took applicable properties from the standard, with their respective codes, and added our own, assigning them a unique code. We only had to add 7% of the attributes; the rest were perfectly applicable to our case, such as “Operating voltage (CFIHOS-40000603).” This demonstrates that the standard is entirely valid for other industrial sectors. The operational needs are similar.

 

Once this work was completed, we had a list of components and their properties, each identified by its code, whether from CFHIOS or created by us. We did not invent anything new; we simply expanded an existing classification, leveraging its data model.

 

How CFIHOS and BIM understand each other

In this context, we carried out two key actions. The first was to integrate this classification with the IFC (Industry Foundation Classes), an open, neutral data format used to describe, share, and exchange information in the construction and architecture industry.

We reviewed all components, defining their IFC Entity to ensure standardization and consistency in the delivery of all projects. Below is a summary table of this exercise.

 

 

Additionally, we sought to make our proposal compatible with the standard information delivery format in the AEC sector, COBie (Construction-Operations Building Information Exchange). As shown below, the schemas are compatible. The fundamental difference lies in the third line, where COBie, primarily oriented towards buildings, aims to catalog assets in a space (level and zone). In contrast, CFIHOS, focused on processes, classifies each asset within a process, subprocess, or system, which is more relevant in these types of projects.

 

Example of the COBie and CFIHOS structure.

 

Conclusion

 

When an organization seeks to digitalize its operations, it needs to define what information about each asset is relevant to its business. It is very likely that their needs will be very similar to those of other companies in the same industry. Sometimes, the industry already has established rules, and we adapt to them. Other times, those rules do not exist, and we must create them. From our perspective, if we are in the latter case, we firmly believe it is worth exploring neighboring sectors to see if we can start with something already established, tested, and robust.

 

To summarize the case developed above, the actions we consider necessary to adapt a specification to a company’s needs are as follows:

• Investigate similar cases, inside and outside the sector.
• Verify that the objectives of the standard align with our use cases.
• Use the available strategy and documentation whenever possible.
• Define our own needs, knowing the common points and new considerations.
• Even propose the work done to the organization that manages the specification, in this case, the IOGP (International Association of Oil & Gas Producers), to provide new perspectives to the community.

At Modelical, we can guide you through this process. We have experience in defining information requirements across multiple types of projects in various industries. We understand the standards and classifications and how to implement a data structure compatible with other data sources. This article provides a concrete example. If you would like to learn more, please contact us