Utilities: Cómo abordar la definición del modelo de datos de activos para Operaciones y Mantenimiento cuando no hay un estándar en el sector.

 

En modelical, participamos en la definición de los requisitos de información de activos para numerosos clientes de diferentes sectores, incluyendo compañías eléctricas, empresas del sector del agua o en centros de datos, entre otros, y frecuentemente nos encontramos con esta problemática: encontrar la mejor manera de identificar cada activo y sus propiedades asociadas para cumplir con diferentes casos de uso de cara a la explotación.

 

Pongamos el ejemplo de dos tipos de proyectos bastante diferentes, un centro de datos y una planta desalinizadora. En ambos casos será útil conocer información sobre el material que compone ciertos elementos. Sin embargo, cuando entramos en el detalle, en el caso de la planta desalinizadora nos interesará tener a mano la propiedad, Presión de prueba, presión a la que un objeto debe someterse para probar su estanqueidad e integridad estructural, en activos como bombas, compresores o mezcladores.
Por otro lado, en un centro de datos, es mucho más importante conocer la Capacidad de carga, la cantidad máxima de energía eléctrica que la PDU puede distribuir de manera segura a los dispositivos conectados, en una Unidad de Distribución de Energía.

En ambos casos es importante clasificar la bomba o la PDU, para ser capaz de comparar, agregar, o monitorizar datos en el contexto de varios proyectos dentro de un portfolio.

 

Y añadimos otro ejemplo más, una bomba en dos situaciones diferentes. En una sala de bombas de un edificio residencial, y en una planta desalinizadora. El objeto es el mismo, pero el mantenimiento asociado, la revisión, y las consecuencias si algo no va bien son muy distintas. Por eso mismo, el modelo de datos para ambas situaciones tampoco coincidirá. En el segundo caso, interesará describir el proceso al que da servicio, o la disciplina, mientras que en el edificio residencial, no es relevante.

A continuación, explicamos cómo abordamos esta necesidad para uno de nuestros clientes del sector del agua.

¿Crear una clasificación ad-hoc, o utilizar una clasificación existente?

Esta es la primera pregunta que nos hacemos.
Clasificar es importante para identificar los activos dentro de un portfolio de proyectos. Sin una clasificación estandarizada de activos y propiedades, no podremos analizar datos.

No obstante no siempre existen clasificaciones que encajen al 100% con nuestras necesidades específicas.

En España, recientemente, la Asociación Española de Abastecimientos de Agua y Saneamiento lanzó su propia clasificación. En el Reino Unido, British Water está trabajando en la suya. Sin embargo, cuando comenzamos este proyecto en 2022, ninguna de estas clasificaciones estaba disponible.

¿Creamos nuestra propia clasificación? La respuesta es no. Continuamos investigando en sectores similares enfocados en procesos y decidimos trabajar con CFIHOS, una clasificación madura del sector Oil & Gas, que tenía numerosos puntos en común con nuestras necesidades.

 

¿Y qué es CFIHOS?

CFIHOS es un estándar desarrollado para definir y gestionar la información requerida durante el ciclo de vida de instalaciones industriales de gran escala, desde la fase de diseño y construcción hasta la operación y el mantenimiento. CFIHOS proporciona un marco común y un conjunto de requisitos que aseguran que la información crítica sea correctamente recopilada, organizada y transferida entre las distintas partes interesadas y fases del proyecto. CFIHOS cuenta con la siguiente documentación publicada:

• Especificación técnica
• Modelo de datos
• Guía de implementación
• Diccionario
• Requisitos de software para su implementación

Puedes leer algo más sobre cómo ha evolucionado a lo largo del tiempo, aquí.

 

¿Por qué elegimos CFIHOS?

En 2022, al no existir ningún estándar para el sector del agua, CFIHOS proporcionaba las siguientes ventajas:

• Un estándar maduro y en uso desde 2012 por industrias de proceso como oil and gas.
• Un estándar enfocado en asegurar que la información de activos sea correctamente transferida a Operaciones.
• Un modelo de datos robusto con una jerarquía y relaciones entre entidades contrastadas.
• Una clasificación de activos amplia.

Este conjunto de aspectos nos permitía partir de una base fiable y cubrir las necesidades de nuestro cliente. El siguiente gráfico muestra parte del esquema del modelo de datos publicado por la organización que adaptamos a nuestro caso.

 

Ejemplo de la estructura y relaciones del modelo de datos de CFIHOS

 

En definitiva, utilizar una clasificación existente es preferible a crear una personalizada. ¿Por qué? Porque expertos en el ámbito ya han dedicado tiempo a desarrollar una primera versión, la cual generalmente ha mejorado gracias a las aportaciones de otras empresas del sector.

 

Cómo adaptamos CFIHOS al sector del agua

En una primera fase, en colaboración con SENER, realizamos el ejercicio de listar todos los activos involucrados en los diferentes tipos de proyectos, organizándolos en forma de jerarquía según el modelo de datos definido por CFIHOS. Cabe destacar que las tipologías son dispares, incluyendo plantas, estaciones o redes.

Hicimos algunas adaptaciones estratégicas para asegurarnos de que cumplía con todas nuestras necesidades, sin perder de vista el objetivo de desarrollar un sistema compatible con el estándar original. La jerarquía propuesta responde al siguiente ejemplo.

• Site: Código que define la región o zona en la que se encuentra. Lo define la organización.
• Plant: Identificador del activo, agrupado por tipología. Lo define la organización.
• Process: Se listaron todos los procesos posibles en los diferentes tipos de proyectos. Aunque la disciplina ayuda a agrupar activos, en este tipo de proyectos es crítico identificar el proceso al que pertenecen.
• Subprocess: Se listaron todos los subprocesos o sistemas asociados a cada uno de los procesos identificados.
• Component: Cada uno de los activos finales a los que asociamos la información. Estos componentes, en fases posteriores se pueden desdoblar en subcomponentes.

 

 

 

Al llegar a la unidad más pequeña, el componente, asociamos el código de CFIHOS correspondiente a ese activo. En algunos casos, el nivel de detalle del estándar no fue suficiente, lo que nos llevó a crear nuevos componentes. En términos generales, de todos los activos listados, el 50% procedían del estándar y el otro 50% los añadimos nosotros, con el fin de incluir la mayoría de los elementos que se pueden encontrar en este tipo de proyectos.

De manera similar, realizamos el mismo ejercicio con las propiedades que debía tener cada objeto. Tomamos del estándar las propiedades aplicables, con sus respectivos códigos, y añadimos las nuestras propias, asignándoles un código propio. Solo tuvimos que añadir el 7% de los atributos; el resto eran perfectamente aplicables a nuestro caso, como por ejemplo, Operating voltage (CFIHOS-40000603). Aquí es donde se demuestra que el estándar es totalmente válido para otros sectores industriales. Las necesidades de cara a la operación son similares.

 

Una vez completado este trabajo, contamos con un listado de componentes y sus propiedades, cada uno identificado con su código, ya sea de CFHIOS o creado por nosotros. No inventamos nada nuevo; simplemente ampliamos una clasificación existente, aprovechando su modelo de datos.

 

Como se entienden CFHIOS y BIM

En este ámbito, llevamos a cabo dos acciones clave. La primera fue integrar esta clasificación con las clases IFC (Industry Foundation Classes), formato de datos abierto y neutral utilizado para describir, compartir e intercambiar información en la industria de la construcción y la arquitectura.

Revisamos todos los componentes, definiendo su IFC Entity para asegurar la estandarización y consistencia en la entrega de todos los proyectos. A continuación mostramos una tabla resumen de este ejercicio.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.

 

 

Además, buscamos compatibilizar nuestra propuesta con el formato de entrega de información estándar en el sector AEC, COBie (Construction-Operations Building Information Exchange). Como se muestra a continuación, los esquemas son compatibles. La diferencia fundamental está en la tercera línea, donde COBie, orientado principalmente a edificaciones, busca catalogar los activos en un espacio (nivel y zona). En cambio, CFIHOS, orientado a procesos, clasifica cada activo dentro de un proceso, subproceso o sistema, lo que es más relevante en este tipo de proyectos.

 

Ejemplo de la estructura de COBie y CFIHOS.

 

Conclusión

 

Cuando una organización busca digitalizar sus operaciones necesita definir qué información de cada activo es relevante para su negocio. Y es muy probable que sus necesidades sean muy similares a las de otras compañías del mismo sector. A veces, ese sector ya tiene unas reglas marcadas y nos adaptamos. Otras veces, esas reglas no existen, y debemos crearlas. Desde nuestro punto de vista, si estamos en segundo caso, creemos firmemente que vale la pena investigar en sectores vecinos, por si pudiéramos partir de algo ya establecido, contrastado y robusto.

 

Resumiendo lo descrito en este ejemplo práctico, las acciones que consideramos necesarias para llevar a cabo la tarea de adaptar una especificación a las necesidades de una compañía son las siguientes:

• Investigar sobre casos similares, dentro y fuera del sector.
• Verificar que los objetivos entre el estándar y nuestros casos de uso están alineados.
• Utilizar en la medida de lo posible la estrategia y documentación disponible.
• Definir nuestras propias necesidades, conociendo los puntos en común, y nuevas consideraciones.
• Incluso proponer a la organización que dirige la especificación, en este caso IOGP (International Association of Oil & Gas Producers), el trabajo realizado para aportar a la comunidad nuevos puntos de vista.

En Modelical podemos acompañarte en este camino, tenemos experiencia en la definición de requisitos de información en múltiples tipos de proyectos de varias industrias. Conocemos los estándares y clasificaciones, y cómo poner en marcha una estructura de datos que sea compatible con otras fuentes de datos. Este artículo dibuja un ejemplo concreto. Si quieres conocer otros, ponte en contacto con nosotros.