Un fabricante no tiene que elegir entre openBIM y formato nativo: publica IFC como base para todo el catálogo y añade familias nativas (Revit, Archicad) solo donde sus prescriptores las pidan. El IFC es lo que pasa los checks IDS y no caduca. El nativo da comodidad en un programa concreto. Las dos salidas, del mismo dato.
¿openBIM o nativo? La pregunta está mal planteada
“¿openBIM o nativo?” suena a elegir bando. Para un fabricante es una pregunta de canales de salida: cada formato es un envase de tu dato para una audiencia.
- openBIM es el enfoque de buildingSMART: intercambiar y entregar con estándares abiertos —IFC para el modelo, IDS para los requisitos, bSDD para el significado— trabaje cada uno con el programa que quiera.
- Formato nativo es el archivo propio de un programa: una familia
.rfade Revit, un objeto.gsmde Archicad. Funciona de maravilla dentro de ese programa y en ningún otro.
Esta guía decide el formato. Qué tiene que llevar dentro tu IFC lo cuenta IFC para fabricantes; qué versión elegir, qué cambia en IFC 4.3.
IFC frente a nativo: la comparación honesta
| IFC (abierto) | Nativo (Revit, Archicad…) | |
|---|---|---|
| Interoperabilidad | Universal, norma ISO 16739-1 | Solo su ecosistema |
| Verificación automática | Sí (IDS) | Limitada, propietaria |
| Longevidad | Décadas; no caduca con versiones | Atada al ciclo del software |
| Experiencia del proyectista | Correcta y mejorando | Óptima en su software |
| Paramétrico | Limitado | Completo (reglas, tipos, tablas) |
| Coste de mantener | Uno (si se genera del dato) | Uno por software y por versión |
| Riesgo estratégico | Ninguno estructural | Dependencia de un tercero |
La fila que más se olvida es la del coste. Revit no abre archivos guardados en una versión posterior a la suya. Si publicas familias en la versión más nueva, los estudios que van una o dos versiones atrás no pueden usarlas; si publicas en una antigua, te quedas sin lo nuevo. Cada familia nativa es una pequeña deuda de mantenimiento que crece con cada versión.
¿Cuándo tiene sentido el formato nativo?
El nativo no es un error. Es un servicio. Tiene sentido cuando se cumplen dos cosas:
- Tus prescriptores viven en un programa concreto. Si casi todos los estudios que te especifican trabajan en el mismo software, dales su formato.
- El producto es configurable. Una ventana a medida gana mucho con una familia paramétrica que el proyectista ajusta a su hueco. Lo explicamos en paramétrico o estático.
Y tiene una condición: el nativo nunca es la única copia de la verdad. Si la transmitancia de la familia de Revit no sale del mismo sitio que la del IFC y la de la DoP, tarde o temprano divergen.
¿Cuándo es obligatorio el IFC?
- Cuando el proyecto valida con IDS. Un IDS se comprueba contra un IFC, no contra una familia nativa. Sin IFC, tu producto no entra en la validación.
- Cuando el pliego pide entrega openBIM. Cada vez más pliegos, públicos y privados, piden la entrega en formato abierto. Los productos especificados heredan el requisito.
- Cuando el cliente no usa tu programa. Ingenierías, constructoras, gestores de activos: muchos no trabajan en el software de autoría del arquitecto.
- Cuando el dato tiene que durar. Mantenimiento y explotación del edificio duran décadas. Un IFC de hoy se seguirá abriendo; una familia de hoy, quizá no.
La estrategia sensata (la que recomendamos siempre)
- IFC como base garantizada: todo el catálogo, con la clase correcta (
IfcWindow, noIfcBuildingElementProxy) y propiedades estándar (bSDD / ISO 23387). Es lo que pasa las validaciones y lo que no caduca. - Nativos donde tu ICP concreto los pida: si tus prescriptores viven en un software, dales su formato, como cortesía comercial, no como única copia de la verdad.
- Todo generado desde el dato maestro. La regla que evita el desastre: los formatos son salidas; si un envase diverge, se regenera, nunca se edita a mano.
El anti-patrón que vemos constantemente
El catálogo “vive” en archivos nativos hechos a mano. El IFC es una exportación ocasional desde esas familias. Y el dato diverge en silencio.
El síntoma típico: la exportación sale como IfcBuildingElementProxy con un Pset llamado
como la empresa y parámetros como U_marco_vidrio. Abre en cualquier visor. No pasa ni un
IDS. Es IFC por fuera y nativo por dentro.
La prueba rápida: abre tu IFC en un visor y pincha una ventana. Si no ves
Pset_WindowCommon con ThermalTransmittance como número, tu base openBIM no es una base.
Cómo empezar sin rehacer el catálogo
- Lista las propiedades que ya declaras (las de tu ficha técnica y tu DoP).
- Tradúcelas al vocabulario IFC. El traductor de propiedades a bSDD/IFC te dice, columna a columna, qué propiedad IFC le toca a cada una, en qué Pset va y cuáles no tienen equivalente.
- Estructura el dato una vez. El generador de ficha bSDD convierte tu Excel en fichas con propiedades normalizadas, en tu navegador.
- Genera las salidas desde ahí: IFC siempre, nativo si toca.
Dónde encaja BESCOF
Exactamente en la regla 3: Sync mantiene el dato maestro y Channels genera las salidas —IFC siempre, nativos según plan— procesando en tu navegador (la tecnología de ifcvieweronline.eu). Sin bandos: envases al servicio del dato, no al revés.
Fuentes
- Estándares abiertos de buildingSMART (IFC, IDS, bSDD) — technical.buildingsmart.org
- ISO 16739-1:2024 (IFC 4.3) — iso.org
- IDS 1.0, especificación oficial — github.com/buildingSMART/IDS
- ISO 23387:2025 (plantillas de datos), que sustituye a la edición de 2020 — iso.org