Sistemas de
clasificación.
El nombre lo elige quien modela. El código de clasificación es el mismo para todos.
Cinco nombres para el mismo muro.
Cada empresa, programa y persona nombra a su manera. Sin un código común, ni las mediciones ni las búsquedas cuadran.
Clasificar es decir qué es.
Un código de clasificación agrupa objetos por lo que tienen en común. No dice cuál es cada uno ni cómo es.
Un objeto, varias tablas.
La misma puerta es parte de un espacio, un elemento con una función, un producto que se compra y un trabajo que se ejecuta. Cada mirada tiene su tabla.
- ¿Dónde está? · espacio
- ¿Qué hace? · elemento o sistema
- ¿Qué se compra? · producto
Un código se lee de lo general a lo concreto.
Cada par de cifras baja un nivel. Cortar el código por la derecha da una clase más amplia que sigue siendo válida.
Un código, cinco usos.
El código es el enlace estable entre el modelo y todo lo que viene después: presupuesto, pliego, búsquedas, requisitos y mantenimiento.
Cada uso pide su tabla.
Antes de clasificar hay que saber para qué. El presupuesto mira elementos y trabajos; el mantenimiento, productos y espacios.
| Uso | Espacio | Elemento | Sistema | Producto | Trabajo |
|---|---|---|---|---|---|
| Presupuesto en fase de diseño | ● | ● | |||
| Mediciones de ejecución | ○ | ○ | ● | ||
| Especificación y pliego | ● | ● | ○ | ||
| Programa de espacios | ● | ||||
| Mantenimiento de activos | ○ | ○ | ● |
● tabla principal · ○ complementaria. Lectura propia a partir del marco ISO 12006-2. Inferido
La clase dice qué; las propiedades, cómo.
Un diccionario de datos une cada clase con sus propiedades, unidades y un identificador único en internet. Así una máquina entiende el código.
Un sistema, una edición, por escrito.
Se decide antes de modelar qué sistema, qué tablas y qué versión. Un código sin su edición es un número que puede cambiar de significado.
Un marco, muchos sistemas.
La norma internacional no trae códigos: dice qué tablas debería tener un sistema. Cada país las rellena con su contenido.
Cada país, su sistema.
No hay una clasificación mundial. Hay familias nacidas de la misma norma y casi siempre ligadas al pliego o a la base de precios de cada país.
| País o región | Sistema | Mantiene | Código de ejemplo |
|---|---|---|---|
| Reino Unido | Uniclass | NBS | EF_25_10 |
| EE. UU. y Canadá | OmniClass · MasterFormat · UniFormat | CSI · CSC | 03 30 00 |
| Dinamarca y CCI | CCS / CCI (ISO 81346-12) | Molio y socios | L-BD |
| Suecia | CoClass | Svensk Byggtjänst | — |
| Países Bajos | NL-SfB | DigiGO | 21 |
| Alemania | DIN 276 (costes) | DIN | 300 |
| España | GuBIMclass | GuBIMCat | 40.10.10.10 |
Quince tablas, cuatro revisiones al año.
El sistema británico es el más vivo y es gratuito. Un tabique de oficina lleva un código por cada mirada.
Tres sistemas para tres momentos.
En Norteamérica, UniFormat ordena el presupuesto por elementos, MasterFormat el pliego por trabajos y OmniClass reúne ambos en 15 tablas.
Clasificar y señalar cada pieza.
La escuela nórdica une las dos cosas: qué tipo es cada objeto y una designación única que dice qué función cumple, de qué está hecho y dónde está.
Sin tabla oficial, GuBIMclass de hecho.
No hay una tabla estatal obligatoria. La más usada nació en Cataluña: clasifica cada elemento por su función principal en cuatro niveles.
| GuBIMclass | 28 % |
| Propia | 22 % |
| Sin definir | 22 % |
| Uniclass | 19 % |
Tres casillas y un parámetro.
Trae UniFormat y OmniClass de serie. Cualquier otro sistema se escribe en un parámetro con nombre y sintaxis fijos para que el IFC lo entienda.
La clasificación es nativa.
Desde 2017, cada elemento puede llevar un código de varios sistemas a la vez, y los sistemas se importan como ficheros.
Cada programa, su casilla.
El dato cambia de sitio en cada programa, pero el destino común es el mismo: una clasificación en el IFC con sistema y código.
| Programa | Dónde se clasifica | Extra |
|---|---|---|
| Tekla Structures | Organizer: categorías con código | Exporta el código al IFC |
| BricsCAD BIM | Códigos de clasificación del objeto | Tablas cargables |
| Bonsai | Clasificación IFC directa | Busca en bSDD sin salir |
| Navisworks | No clasifica: filtra | Conjuntos de búsqueda por código |
| Presto | Código de partida del BC3 | Mide el modelo por partida |
Un diccionario en internet.
buildingSMART publica en una sola plataforma cientos de clasificaciones con dirección web fija para cada clase. Los programas la consultan por su API.
Encontrar el código y usarlo.
Los buscadores oficiales dan el código correcto; los visores y el entorno común lo convierten en filtros, colores y vistas guardadas.
Tres entidades llevan el código.
El sistema, el código y el vínculo con los objetos van por separado. Así un mismo objeto puede llevar varios sistemas sin mezclarlos.
Traducir no es copiar.
Los sistemas miran con criterios distintos y casi nunca hay equivalencia uno a uno. Mejor llevar cada sistema en su sitio que convertir uno en otro.
Seis errores que vacían los filtros.
Casi todos pasan al exportar: el código existe en el modelo pero llega sin sistema, con otro nombre o en otro campo.
Cinco preguntas a cada objeto.
Que tenga código no basta. Tiene que ser del sistema pactado, de la tabla correcta, existir en esa edición y encajar con lo que el objeto es.
El requisito, en un fichero.
Un IDS dice «todo muro lleva un código de esta tabla y este sistema». Cualquier comprobador lo lee igual, y basta una letra distinta en el nombre del sistema para fallar.
| IFC de prueba | Muros bien | Muros mal | Resultado |
|---|---|---|---|
| Código EF_25_10 o un hijo | 2 | 0 | Pasa |
| Un muro sin código | 1 | 1 | Falla |
| Un muro con código de sistemas (Ss) | 1 | 1 | Falla |
| Sistema llamado «Uniclass 2015» | 0 | 2 | Falla |
Comprobar contra la tabla.
Un IDS no sabe si un código existe. Un script de Python compara cada código del IFC con la lista oficial de la edición pactada.
Comprobar antes de exportar.
El error más barato es el que se ve en el programa de origen: una tabla de planificación o un filtro de color por código antes de cada entrega.