Cómo utilizar las clasificaciones OmniClass y Uniclass en Revit

Las clasificaciones BIM permiten describir los elementos de un modelo con un lenguaje común. En lugar de identificar una puerta, una unidad de tratamiento de aire o un acabado únicamente por su nombre, el proyecto puede asociarlos a códigos que indican qué son, a qué sistema pertenecen, qué función cumplen o qué resultado de construcción representan. Esta información facilita la coordinación entre arquitectura, estructuras, instalaciones, contratistas y propietarios.

OmniClass y Uniclass son dos sistemas de clasificación habituales en entornos internacionales. OmniClass se utiliza especialmente en proyectos vinculados con Norteamérica y organiza la información mediante tablas relacionadas con entidades de construcción, espacios, elementos, productos, materiales y resultados de trabajo. Uniclass 2015, muy extendido en Reino Unido y en proyectos que adoptan estándares británicos, emplea códigos como EF para elementos y funciones, Ss para sistemas, Pr para productos y Co para complejos o entidades de construcción.

Revit puede almacenar parte de esta información mediante parámetros integrados, códigos de ensamblaje, tablas de clasificación y parámetros compartidos. Sin embargo, el programa no transforma automáticamente un modelo desordenado en una estructura normalizada. La calidad del resultado depende de la estrategia de implantación, de la selección de códigos y de la revisión de los datos en familias, tipos y ejemplares.

Una clasificación bien configurada mejora las tablas de planificación, las búsquedas, las mediciones, la coordinación interdisciplinar y la entrega del modelo. También ayuda a relacionar los objetos con requisitos de mantenimiento, especificaciones técnicas, análisis de costes y criterios de sostenibilidad en BIM, siempre que la información se mantenga coherente durante todas las fases del proyecto.

Qué aportan OmniClass y Uniclass a un modelo BIM

OmniClass no es una única lista lineal, sino un conjunto de tablas que describen distintas perspectivas de una construcción. La tabla 21 clasifica los elementos, la tabla 22 los resultados de trabajo y la tabla 23 los productos. Otras tablas pueden abordar espacios, fases, disciplinas, propiedades o materiales. Esta separación permite escoger el nivel de información adecuado para cada uso, aunque también exige definir previamente qué tabla se aplicará a cada parámetro.

Uniclass 2015 sigue una lógica jerárquica formada por códigos de dos letras y varios niveles numéricos. Por ejemplo, una clasificación puede comenzar por un complejo, continuar con una entidad de construcción, descender a un sistema y terminar en un producto. Los códigos Ss describen sistemas, como una instalación de climatización o una cubierta; los Pr identifican productos; y los EF se relacionan con elementos y funciones. La estructura permite navegar desde una descripción general hasta una categoría muy concreta.

La diferencia principal no está en que un sistema sea válido y el otro incorrecto, sino en el contexto contractual y geográfico del proyecto. OmniClass puede ser obligatorio en determinados estándares norteamericanos, mientras que Uniclass suele formar parte de requisitos de información basados en normas británicas. Adoptar ambos sin una regla de equivalencia puede generar duplicidades, códigos contradictorios y tablas difíciles de interpretar.

Antes de modelar, conviene revisar el EIR, el BEP, las especificaciones del cliente y los requisitos de intercambio. El documento de gestión BIM debe indicar qué clasificación se utilizará, qué tabla corresponde a cada categoría, quién asignará los códigos y en qué hitos se comprobará la información. Si el proyecto exige OmniClass para productos y Uniclass para sistemas, esa combinación debe quedar documentada en lugar de resolverse de forma improvisada dentro de Revit.

Configurar la información de clasificación en Revit

El parámetro Assembly Code de Revit se emplea para asociar elementos con códigos de ensamblaje. Su contenido depende del archivo de clasificación seleccionado en la configuración del proyecto y suele relacionarse con sistemas como UniFormat, aunque también puede configurarse mediante una tabla de códigos compatible. El parámetro Assembly Description muestra la descripción vinculada y resulta útil en tablas de planificación, etiquetas y documentación.

La configuración se revisa desde la gestión de archivos y parámetros adicionales relacionados con los códigos de ensamblaje. La ubicación exacta puede variar según la versión y el idioma de Revit, por lo que es importante verificar qué archivo de clasificación está activo antes de cargar o editar información. Cambiar este archivo en mitad del proyecto puede modificar descripciones disponibles y afectar a elementos que ya tenían códigos asignados.

OmniClass suele incorporarse mediante parámetros específicos disponibles en determinadas categorías o plantillas, como OmniClass Number y OmniClass Title. Su disponibilidad puede depender de la versión, de la plantilla empleada y de la familia. Por esta razón, el equipo debe comprobar en un proyecto de prueba si los parámetros aparecen como integrados, como parámetros de tipo o como parámetros de ejemplar. No conviene asumir que todos los objetos del modelo los incluyen de la misma forma.

Uniclass normalmente requiere una solución más personalizada. La práctica habitual consiste en crear parámetros compartidos para el código y el título de cada nivel necesario, por ejemplo, Uniclass Ss Code, Uniclass Ss Title, Uniclass Pr Code y Uniclass Pr Title. Estos parámetros pueden incorporarse a categorías seleccionadas mediante un archivo de parámetros compartidos y asociarse desde una plantilla de proyecto. Mantener separados el código y la descripción facilita las comprobaciones y evita que una modificación textual rompa la búsqueda por identificadores.

Asignar códigos a familias, tipos y sistemas

La clasificación debe asignarse en el nivel que representa correctamente la información. Si todos los tipos de una familia comparten el mismo código, puede utilizarse un parámetro de tipo. Una familia de puertas puede tener códigos distintos para una puerta cortafuegos, una puerta acústica y una puerta metálica, aunque pertenezcan a la misma categoría. En cambio, un dato que cambia según la ubicación o la fase del proyecto debe ser un parámetro de ejemplar.

En instalaciones MEP, es útil distinguir entre el sistema y los componentes que lo forman. Una red de suministro de aire puede recibir un código de sistema Uniclass Ss, mientras que la rejilla, el conducto, la compuerta y el difusor pueden asociarse a códigos de producto Pr u OmniClass de producto. Esta separación mejora las tablas y permite filtrar los elementos sin confundir una clasificación funcional con una descripción comercial.

Para asignar datos de forma manual, se selecciona la familia o el elemento, se localizan los parámetros de clasificación en la paleta de propiedades y se introduce el código aprobado. En el editor de familias, los parámetros de tipo pueden incorporarse antes de cargar la familia en el proyecto. Cuando existe una biblioteca corporativa, resulta preferible clasificar las familias en esa biblioteca y bloquear los valores mediante una convención de nomenclatura y un proceso de revisión.

En modelos medianos o grandes, la edición manual genera errores repetitivos. Dynamo, complementos de gestión de parámetros y hojas de cálculo controladas permiten cargar códigos mediante correspondencias entre categoría, familia, tipo y clasificación. El flujo debe conservar una columna de identificador estable, como el nombre de familia y tipo o un identificador GUID, y no basarse únicamente en nombres que pueden cambiar durante el desarrollo.

Crear tablas y revisar la consistencia de los datos

Las tablas de planificación convierten la clasificación en información operativa. Una tabla de puertas puede mostrar categoría, familia, tipo, nivel, fabricante, código Uniclass Pr y descripción. Otra tabla de sistemas puede agrupar por código Ss, disciplina, servicio, caudal o fase. En un modelo federado, las mismas columnas permiten comparar arquitectura, estructuras y MEP con una estructura de datos común.

Los filtros y agrupaciones deben diseñarse según el objetivo del intercambio. Para una medición, puede interesar agrupar por producto y tipo; para coordinación, por sistema y disciplina; para mantenimiento, por equipo, ubicación y código de activo. Utilizar el título como campo principal puede ocultar variaciones ortográficas, por lo que el código debe actuar como identificador y la descripción como apoyo legible para el usuario.

Una comprobación básica consiste en localizar valores vacíos, códigos que no existen en la tabla oficial y descripciones que no corresponden al identificador. También conviene detectar el mismo código aplicado a categorías incompatibles, por ejemplo, un código de producto sanitario asignado a un elemento estructural. Las tablas de planificación pueden servir como auditoría interna si incluyen campos de control como estado de revisión, responsable y fecha de validación.

Para revisiones más profundas, los datos pueden exportarse a Excel, Power BI, Solibri, Navisworks o herramientas de auditoría específicas. El análisis debe comparar el modelo con el diccionario de datos del proyecto y no solo con la apariencia geométrica. Un objeto correctamente modelado puede tener una clasificación equivocada, y un objeto con geometría provisional puede contener información válida para una fase temprana. La revisión debe valorar ambos aspectos por separado.

Integrar la clasificación en el flujo de trabajo BIM

La clasificación funciona mejor cuando se incorpora desde la creación de la plantilla. La plantilla debe incluir parámetros compartidos, unidades de información, tablas de control, filtros de vista y familias aprobadas. También debe definir qué campos son obligatorios en cada etapa: diseño conceptual, coordinación, licitación, construcción y operación. No todos los datos tienen que completarse al principio, pero sí debe conocerse cuándo serán exigibles.

El equipo puede establecer una matriz de responsabilidad para evitar que arquitectos, ingenieros y gestores de información asignen códigos con criterios diferentes. El modelador introduce los datos de la familia, el coordinador verifica la correspondencia con la tabla oficial y el responsable BIM valida el conjunto antes de cada entrega. En proyectos con varios contratistas, esta secuencia ayuda a conservar una clasificación común al vincular modelos externos.

También es importante controlar las revisiones de las tablas OmniClass y Uniclass. Un código puede conservar su identificador mientras cambia su título, o puede quedar sustituido por una nueva entrada. Guardar una copia de la versión utilizada, registrar la fecha de consulta y documentar equivalencias evita que una actualización externa altere silenciosamente el significado del modelo. Las decisiones de mapeo deben formar parte de la documentación de entrega.

La clasificación adquiere mayor valor cuando se conecta con otros identificadores, como códigos de activos, espacios, sistemas, zonas, COBie, Omniclass o Uniclass, parámetros de fabricante y requisitos de mantenimiento. Esa relación debe ser explícita: un código de clasificación no sustituye al número de activo, al código de coste ni al identificador único del elemento. Cada campo tiene una finalidad diferente y la estructura de datos debe impedir que se mezclen durante la exportación.

Un flujo sólido en Revit combina una plantilla controlada, familias con parámetros consistentes, asignación en el nivel correcto, automatización cuando el volumen lo requiere y auditorías antes de cada intercambio. Así, OmniClass y Uniclass dejan de ser etiquetas añadidas al final del proyecto y se convierten en una base ordenada para consultar, coordinar y reutilizar la información BIM.