Validació · 2026-06-28 · 20 min

Verificador de models IFC: la guia completa de validació IFC, qualitat del model i IDS

Guia del verificador de models IFC: l'esquema, la qualitat del model (44 regles + Health Score) i l'IDS són tres capes independents. Confondre-les provoca fallades de lliurament. Desglossament complet per a coordinadors BIM.

Verificador de models IFC: la guia completa de validació IFC, qualitat del model i IDS — IFC Viewer Online article cover

3 — capes de validació independents
44 — regles de qualitat del model
6 — facetes de l'IDS (buildingSMART 1.0)
0 — bytes pujats — només al navegador

Tota conversa sobre lliurament d'IFC acaba topant amb el mateix mur. L'enginyer d'estructures diu que el fitxer ha superat el validador. El coordinador BIM veu que falta la meitat dels conjunts de propietats i pregunta quin validador s'ha fet servir. L'EIR del client especifica requisits d'IDS que ningú ha comprovat. El CDE rebutja la pujada. Tres setmanes després, tothom té dubtes sobre què vol dir realment «vàlid».

La confusió és comprensible: la paraula «validació» cobreix tres operacions completament diferents que comparteixen el mateix nom. Desfer aquest embolic és una de les coses més decisives que pot fer un coordinador BIM per a un projecte.

Tres problemes de validació completament diferents

Pensa en una sol·licitud de llicència d'obres. El tècnic municipal verifica de manera independent tres coses: si els plànols són llegibles i complets (integritat del fitxer), si el disseny compleix la normativa d'edificació (qualitat i compliment) i si respon a l'encàrrec específic del client (requisits del projecte). Un plànol llegible pot ignorar completament la normativa contra incendis. Un projecte que compleix la normativa contra incendis pot no tenir en compte cap especificació acústica del client. Són preguntes separades amb respostes separades.

Nivell 1 — Integritat IFC

És el fitxer un IFC vàlid segons ISO 10303-21 i ISO 16739-1? Els GlobalId són únics i compleixen el format? La jerarquia espacial és coherent? Comprovació binària a nivell d'esquema.

Nivell 2 — Qualitat del model

Les dades són realment útils per a la coordinació? Els conjunts de propietats estan omplerts? Els elements segueixen les convencions de nomenclatura? Hi ha classificacions presents? Això és el que governa els lliuraments reals, no el compliment de l'esquema.

Nivell 3 — Validació IDS

El model satisfà els requisits d'informació contractuals d'aquest projecte? Requisits d'EIR i AIR codificats com a especificacions IDS llegibles per màquina, comprovats faceta per faceta en cada element.

Aquestes tres capes són completament independents. Un fitxer pot ser vàlid segons l'esquema de Nivell 1 i alhora inútil per a la coordinació perquè no s'ha exportat cap conjunt de propietats. Una comprovació IDS pot superar-se per a tots els requisits declarats mentre el model té 400 GUID duplicats. Un Health Score de 91 no diu res sobre si els requisits de resistència al foc del client estan codificats i complerts. Cada capa respon una pregunta diferent — les tres calen abans d'un lliurament formal.

Nivell 1: integritat del fitxer IFC — és això un IFC vàlid?

El Nivell 1 és la comprovació d'esquema. Respon una pregunta binària: aquest fitxer compleix l'esquema IFC (ISO 16739-1) i el format físic de fitxer (ISO 10303-21 STEP)? La majoria de parsers d'IFC accepten en silenci fitxers que fallen les comprovacions de Nivell 1 — són permissius per disseny, perquè un rebuig estricte trencaria massa fluxos de treball. Aquesta permissivitat amaga el dany fins que aflora més avall en el procés.

Què cobreix la comprovació d'integritat de Nivell 1

Unicitat del GlobalId: cada entitat IfcRoot ha de tenir un GlobalId únic de 22 caràcters amb l'alfabet base-64 de l'IFC. Els GlobalId duplicats són una infracció de l'esquema que els parsers accepten però que corromp en silenci els fluxos de treball de BCF, el versionat del CDE i els registres d'actius de FM.
Compliment del format del GlobalId: el primer caràcter d'un GlobalId IFC vàlid només pot codificar valors de 0 a 3 (dos bits significatius d'un UUID de 128 bits). Els scripts que trunquen UUID de manera ingènua produeixen caràcters inicials fora de rang — invàlids segons l'especificació, però tolerats per la majoria de parsers i rebutjats pels validadors estrictes.
Completesa de la jerarquia espacial: l'esquema IFC exigeix IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey. Els nodes que falten (un Building directament sota Project, elements físics dins d'IfcSite) són infraccions de l'esquema amb conseqüències reals més avall en el procés.
Integritat de la cadena IfcRelAggregates: les entitats de relació que construeixen l'arbre espacial han de referenciar entitats existents. Les referències penjants — quan una relació apunta a una entitat suprimida o inexistent — trenquen la navegació de l'arbre en totes les eines més avall en el procés.
IfcRelContainedInSpatialStructure: els elements físics han d'estar continguts en un element espacial (normalment IfcBuildingStorey). Els elements sense relació de contenció són orfes — invisibles en la navegació espacial de la majoria d'eines.
Exactament un IfcProject: tot fitxer IFC vàlid ha de contenir exactament un IfcProject com a arrel de la jerarquia. Els submodels que l'ometen es parsegen sense error però no tenen cap ancoratge espacial.
Camps de capçalera FILE_NAME i FILE_DESCRIPTION: la capçalera del fitxer STEP porta metadades de traçabilitat. La ISO 19650-2 exigeix que estiguin omplerts — la majoria d'eines els deixen com a cadenes buides.
Validesa de la geometria: malles no manifold, cares amb àrea zero, cossos amb l'ordre de les normals invertit, representacions de contorn autointersecants que no arriben a produir sòlids vàlids en les eines receptores.

Què NO comprova el Nivell 1

Si els conjunts de propietats estan omplerts o són correctes — un model vàlid segons l'esquema amb zero Psets supera el Nivell 1.
Si els noms dels elements segueixen alguna convenció de nomenclatura del projecte.
Si hi ha codis de classificació presents, correctes o coherents.
Si es compleixen els requisits de quantitats de LOD (IfcElementQuantity a LOD 300 o superior).
Si el model compleix cap requisit d'informació específic del projecte o contractual.

El buildingSMART Validation Service per al Nivell 1

El buildingSMART IFC Validation Service (validate.buildingsmart.org) és la referència de facto per al compliment de l'esquema de Nivell 1 — utilitza el mateix motor desplegat per a la certificació de programari IFC. Fes-lo servir quan: necessitis certificar la sortida IFC d'un exportador propi, estiguis diagnosticant un fitxer que els parsers tracten de manera inconsistent, o una clàusula contractual exigeixi explícitament un certificat d'esquema de buildingSMART.

El que no fa: comprovar la qualitat de les dades, validar convencions de nomenclatura, inspeccionar la completesa dels conjunts de propietats, comprovar camps de metadades ISO 19650, o avaluar si el model compleix cap requisit del projecte. És una eina d'esquema, no un filtre de lliurament de projecte.

Inspecciona un IFC real complex — les tres capes de validació

Un edifici d'oficines de diverses plantes exportat des de Revit. Obre la pestanya de Validació per veure l'informe complet de qualitat de 44 regles i el Health Score. Després prova de carregar una especificació IDS per veure la comprovació de Nivell 3 sobre el mateix model.

IFC4 · 14 MB

Obre el visor IFC interactiu

Nivell 2: comprovació de la qualitat del model — la capa que realment governa els lliuraments

La comprovació de qualitat del model és la capa que la majoria de coordinadors BIM tenen al cap quan diuen «validació IFC», encara que rarament la designin amb aquest nom. Respon preguntes pràctiques: hi són les dades? Són correctes? Són coherents? Pot algú, més avall en el procés, fer servir realment aquest model per a la coordinació, la planificació de costos o la FM?

A diferència del Nivell 1, la comprovació de qualitat no és binària. Un model no simplement passa o falla — té un perfil de qualitat en desenes de dimensions. El Health Score (0–100) agrega aquestes dimensions en un únic número que es pot fer constar al BEP, seguir al llarg de les revisions i adjuntar als lliuraments com a prova de la qualitat de l'entrega.

Què cobreix la comprovació de qualitat de 44 regles

Regles estructurals bàsiques (18)

GUID duplicats, elements orfes, contenció incorrecta, agregats trencats, IfcProject absent, noms d'element buits, ubicació de planta invàlida. Les regles que provoquen més rebuigs al CDE a la pràctica.

Espacial + capçalera del fitxer (11)

Camps de metadades ISO 19650 a IfcProject, autoria i organització de FILE_NAME, ubicació de l'emplaçament enfront de coordenades compartides, associació element-planta, completesa de les plantes.

LOD, classificació, MEP (9)

Presència d'IfcElementQuantity a LOD 300 o superior, IfcRelAssociatesClassification en elements estructurals i arquitectònics, connectivitat de sistemes MEP, ús excessiu de proxy (IfcBuildingElementProxy com a % del model).

Geometria + integritat de plantes (6)

Validesa de la caixa contenidora de l'element, ordenació de la cota de les plantes, elements per sota de la rasant, absència de llosa de forjat a la planta, desplaçament de l'origen de coordenades respecte al WCS, detecció de col·lisions (regla opcional, desactivada per defecte).

El Health Score: la qualitat del model en un únic número

El Health Score utilitza una ponderació de penalització logarítmica. Els errors d'esquema pesen 3 vegades més que els avisos; els avisos pesen 3 vegades més que les comprovacions informatives. La 1.000a instància del mateix problema resta molts menys punts que la 10a — això evita que els models grans i densos semblin arbitràriament pitjors que els models petits i dispersos amb la mateixa densitat de problemes subjacent. Un model amb 800 avisos de nomenclatura pot obtenir un 83; un model amb 12 referències espacials trencades obté un 41. El que determina la puntuació és la gravetat, no el volum.

31/100 — Crític — fallades estructurals, no lliurar
58/100 — Deficient — cal una esmena significativa
74/100 — Acceptable — només per a revisió interna
87/100 — Bo — llest per al lliurament a un CDE
96/100 — Excel·lent — qualitat de fita d'ISO 19650

Què NO fa la comprovació de qualitat del model

Verificar els requisits d'informació específics del projecte — això és el Nivell 3 (IDS). Les regles de qualitat són comprovacions genèriques de bones pràctiques, no el teu EIR.
Corregir el model — la comprovació de qualitat produeix un informe. L'esmena es fa a l'eina d'autoria o, per a correccions de propietats i GUID, en un editor de propietats IFC.
Proporcionar el certificat de compliment d'esquema que exigeixen els programes de certificació de buildingSMART — això és el Nivell 1 via el buildingSMART Validation Service.
Dir-te si el model és geomètricament correcte — s'inclouen algunes comprovacions d'integritat geomètrica, però un verificador de qualitat no és una eina de detecció de col·lisions ni d'autoria BIM.

Nivell 3: validació IDS — requisits d'intercanvi en forma de codi llegible per màquina

L'IDS (Information Delivery Specification) és un estàndard de buildingSMART per codificar requisits d'informació específics del projecte en un format XML llegible per màquina. És l'enllaç que faltava entre un EIR — que és un document de text — i un motor de validació capaç de comprovar sistemàticament un model contra aquest EIR. L'IDS 1.0 es va convertir en estàndard oficial de buildingSMART el 2023.

Què és realment l'IDS de buildingSMART

Un fitxer IDS és un document XML que conté una o més especificacions. Cada especificació té una secció d'aplicabilitat (a quins elements s'aplica?) i una secció de requisits (què han de tenir aquests elements?). El motor comprova cada element del model que coincideixi amb l'aplicabilitat, verifica que compleix tots els requisits i informa de superat o no superat per element i per especificació. El resultat és un rastre d'auditoria generat per màquina del compliment contractual.

El conjunt de proves de referència de buildingSMART conté 100 testcases oficials que defineixen el comportament esperat de qualsevol motor IDS conforme — són l'especificació en forma executable. Un motor IDS que supera els 100 testcases ha demostrat que interpretarà les especificacions .ids de manera coherent amb l'estàndard.

Les sis facetes de l'IDS

Entity: restringeix l'aplicabilitat o els requisits per tipus d'entitat IFC (IFCWALL, IFCDOOR, IFCBEAM) i, opcionalment, per tipus predefinit. És el filtre amb què comencen la majoria d'especificacions.
Attribute: comprova valors d'atribut IFC que resideixen directament a l'entitat — Name, Description, ObjectType, Tag, PredefinedType. Els atributs són diferents dels conjunts de propietats i es comproven d'una altra manera.
Property: comprova una propietat concreta dins d'un conjunt de propietats concret (Pset_WallCommon.FireRating, Pset_DoorCommon.IsExternal). És la faceta més utilitzada. Admet restriccions de tipus de dada i concordança de patrons en els valors.
Classification: comprova que els elements portin una referència de classificació via IfcRelAssociatesClassification — Uniclass 2015, OmniClass, NBS o un esquema personalitzat. Pot restringir el nom del sistema de classificació i el patró del codi.
Material: comprova que els elements tinguin un material assignat via IfcMaterial, IfcMaterialLayerSet o IfcMaterialConstituentSet. Opcionalment restringeix el nom del material — útil per a requisits de resistència al foc o sostenibilitat.
PartOf: comprova que els elements participin en una relació espacial o lògica requerida — contingut en una planta, agregat en un sistema de l'edifici, allotjat en un edifici concret. La faceta que exigeix el compliment de la jerarquia espacial per a tipus d'element concrets.

<?xml version="1.0" encoding="UTF-8"?>
<ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://standards.buildingsmart.org/IDS ids_09.xsd">
  <ids:info>
    <ids:title>Stage 3 Architecture — EIR Data Requirements</ids:title>
    <ids:description>Fire safety and classification requirements.</ids:description>
    <ids:ifcVersion>IFC4</ids:ifcVersion>
  </ids:info>
  <ids:specifications>

    <!-- All walls must carry a fire rating property -->
    <ids:specification name="Wall FireRating required" minOccurs="1">
      <ids:applicability>
        <ids:entity>
          <ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:property dataType="IFCLABEL">
          <ids:propertySet><ids:simpleValue>Pset_WallCommon</ids:simpleValue></ids:propertySet>
          <ids:baseName><ids:simpleValue>FireRating</ids:simpleValue></ids:baseName>
        </ids:property>
      </ids:requirements>
    </ids:specification>

    <!-- Structural walls must carry a Uniclass 2015 classification -->
    <ids:specification name="Structural wall classification" minOccurs="0">
      <ids:applicability>
        <ids:entity>
          <ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
          <ids:predefinedType><ids:simpleValue>SOLIDWALL</ids:simpleValue></ids:predefinedType>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:classification>
          <ids:system><ids:simpleValue>Uniclass 2015</ids:simpleValue></ids:system>
        </ids:classification>
      </ids:requirements>
    </ids:specification>

  </ids:specifications>
</ids:ids>

D'EIR a IDS: el pas de traducció que la majoria d'equips es salten

Un EIR especifica quina informació necessita el client. Un IDS codifica aquests requisits perquè una màquina els pugui comprovar. La traducció entre tots dos és el pas que gairebé ningú fa — perquè exigeix algú que entengui prou bé tant els requisits d'informació com l'esquema XML de l'IDS per escriure una especificació que comprovi exactament el que demana l'EIR, ni més ni menys.

La conseqüència: els equips o bé es salten l'IDS del tot i confien en una revisió manual informal en el lliurament, o bé fan servir un fitxer IDS genèric que no reflecteix el seu EIR real. Totes dues opcions produeixen una falsa confiança. Una comprovació IDS que se supera contra una especificació genèrica no diu res sobre si es compleixen els requisits específics del teu client.

IDS basat en perfils: un punt de partida pràctic

No tots els equips escriuen l'IDS des de zero. Un enfocament pràctic és mantenir una biblioteca de perfils IDS reutilitzables: un per a la Fase 3 d'arquitectura, un per a MEP a la Fase 4, un per al lliurament d'estructures. Cada perfil cobreix els requisits més habituals per a aquesta fase i disciplina, i s'amplia per a cada projecte amb afegits específics del client. Els perfils IDS es poden carregar directament al motor de validació i combinar-se — es poden executar diversos fitxers .ids contra el mateix model i agregar els resultats.

Com funcionen junts els tres nivells — el pipeline de validació

Les tres capes formen un filtre de qualitat que un model travessa en seqüència. Cada nivell té una cadència diferent: el Nivell 1 s'executa a cada exportació (una comprovació de sanitat), el Nivell 2 s'executa abans de qualsevol pujada al CDE (el filtre de qualitat), el Nivell 3 s'executa abans de les fites formals de lliurament (la comprovació contractual). Executar-los fora d'ordre malbarata temps — no té sentit executar l'IDS contra un fitxer amb una jerarquia espacial trencada.


  ┌──────────────────────────────────────────────────────┐
  │  EXPORT IFC from authoring tool                      │
  │  (Revit, ArchiCAD, Tekla, Allplan, Vectorworks…)     │
  └───────────────────────┬──────────────────────────────┘
                          │
                          ▼
  ┌──────────────────────────────────────────────────────┐
  │  LEVEL 1 — IFC Integrity                             │
  │  • GlobalId uniqueness & format (leading char 0–3)   │
  │  • Spatial hierarchy: Project→Site→Building→Storey   │
  │  • IfcRelAggregates chain integrity                  │
  │  • IfcRelContainedInSpatialStructure (no orphans)    │
  │  • Exactly one IfcProject                            │
  │  • FILE_NAME header traceability fields              │
  └─────────┬────────────────────────────────────────────┘
  Fail ◄────┤  Fix in authoring tool (or IFC property editor)
            │  Pass
            ▼
  ┌──────────────────────────────────────────────────────┐
  │  LEVEL 2 — Model Quality (44 rules)                  │
  │  • Naming conventions / empty element names          │
  │  • Property set completeness (Pset_WallCommon etc.)  │
  │  • ISO 19650 metadata (IfcProject.LongName etc.)     │
  │  • Classification presence and consistency           │
  │  • LOD quantity sets, proxy audit, MEP connectivity  │
  │  → Health Score 0–100                                │
  └─────────┬────────────────────────────────────────────┘
  Score<80 ◄┤  Fix properties / names in IFC editor or authoring tool
            │  Score ≥ 80
            ▼
  ┌──────────────────────────────────────────────────────┐
  │  LEVEL 3 — IDS Validation                            │
  │  • Project-specific EIR / AIR requirements           │
  │  • .ids specification(s) for this milestone          │
  │  • Six facets: entity, attribute, property,          │
  │    classification, material, partOf                  │
  └─────────┬────────────────────────────────────────────┘
  Fail ◄────┤  Fix per IDS issue report → export BCF → remediate
            │  All requirements met
            ▼
  ┌──────────────────────────────────────────────────────┐
  │  DELIVER TO CDE                                      │
  │  Attach: Health Score report + IDS pass certificate  │
  └──────────────────────────────────────────────────────┘

La taula comparativa: Nivell 1 vs. Nivell 2 vs. Nivell 3

Dimensió	N1: integritat IFC	N2: qualitat del model	N3: validació IDS
Pregunta que respon	És el fitxer un esquema IFC vàlid?	Les dades són útils per a la coordinació?	Compleix els requisits d'informació del projecte?
Estàndard	ISO 10303-21 (STEP), ISO 16739-1 (IFC)	Bones pràctiques BIM, normes ISO 19650	buildingSMART IDS 1.0 (esquema XML)
Definit per	buildingSMART (esquema fix)	Equip BIM / EIR (regles acordades pel projecte)	Client / promotor (per projecte)
Resultat	Superat / no superat + llista d'errors d'esquema	Health Score 0–100 + llista d'incidències prioritzada	Superat / no superat per especificació
Pot substituir els altres?	No	No	No — calen els tres
Cadència	Cada exportació IFC	Abans de pujar al CDE	Abans de la fita de lliurament
Passa aquest però falla l'altre?	Zero Psets, sense noms → passa N1, falla N2	Falta la resistència al foc (especificació IDS) → falla N3	GUID duplicats, jerarquia trencada
Eines d'exemple	bSmart Validator, IFC Viewer Online	IFC Viewer Online, Solibri, IfcOpenShell	IFC Viewer Online (motor IDS), Solibri

Quan fer servir el buildingSMART Validation Service — una valoració honesta

El buildingSMART IFC Validation Service comprova els fitxers contra l'esquema oficial amb un motor de diverses parts: sintaxi del fitxer físic STEP, regles EXPRESS de l'esquema IFC, regles de proposició informal derivades de l'especificació i regles de restricció normatives de l'IFC. És l'eina de referència per al compliment de l'esquema de Nivell 1.

Fes-lo servir quan

Certifiquis l'exportació IFC d'un exportador propi: el verificador de buildingSMART produeix el resultat de referència utilitzat per a la certificació de programari. Cap altra eina el pot substituir en contextos de certificació.
Diagnostiquis inconsistències de parser: quan un fitxer s'obre correctament en una eina i dona error en una altra, el verificador de buildingSMART estableix quin comportament és correcte segons l'esquema. Això és diagnòsticament valuós encara que el fitxer sigui utilitzable per altres vies.
Una clàusula contractual ho exigeixi: algunes especificacions de contractació fan referència al compliment de l'esquema de buildingSMART com a requisit de lliurament. En aquest cas, el certificat del servei oficial és el que satisfà la clàusula.
Validis el mateix fitxer IDS: el validador d'esquema IDS de buildingSMART comprova si el teu fitxer .ids és un document IDS vàlid — cosa diferent d'executar-lo contra un model.

No el facis servir com a substitut de

La comprovació de qualitat del model — el servei no comprova la completesa dels conjunts de propietats, les convencions de nomenclatura, la classificació ni cap regla de qualitat de dades.
La validació específica del projecte — el compliment de l'esquema no diu res sobre si el model satisfà l'EIR del client.
La confirmació prèvia al lliurament al CDE — un model vàlid segons l'esquema amb Psets buits i noms en blanc superarà el verificador de buildingSMART i fallarà qualsevol filtre de qualitat significatiu.

Validador IFC al núvol vs. validador IFC al navegador

La distinció entre validació al núvol (el fitxer es puja a un servidor remot) i validació al navegador (el fitxer es processa localment via WebAssembly) importa més del que la majoria d'equips es pensen — especialment en projectes governamentals, de defensa i comercials sensibles.

Validació al navegador

El fitxer IFC mai surt del dispositiu
Compleix el RGPD per disseny — cap transferència de dades
Funciona sense connexió: visites a obra, xarxes restringides
Sense quota de pujada ni límit de mida de fitxer
Resposta instantània — sense latència d'anada i tornada per xarxa
Rendiment constant, independent de la càrrega del servidor
No cal cap compte, clau d'API ni subscripció
Funciona en entorns de xarxa restringits governamentals

Validació al núvol

El fitxer es puja a un servidor remot per processar-lo
Cal un acord de tractament de dades (DPA) per al RGPD
Adequada per a pipelines de validació CI/CD automatitzats
Registre d'auditoria centralitzat entre projectes i equips
Integració amb API i webhooks per automatitzar el lliurament
Escala horitzontalment per al processament per lots de models
Es pot executar sense navegador (headless)
Els resultats es poden consultar en execucions històriques

Quan té sentit la validació al núvol

Pipelines CI/CD automatitzats: quan la validació s'ha de disparar automàticament cada vegada que es fa commit o es puja un model — de manera similar a com els equips de programari executen tests automatitzats a cada push de codi. Les API al núvol amb webhooks són l'arquitectura adequada aquí.
Auditoria a nivell d'organització: quan un BIM manager necessita un registre centralitzat de les execucions de validació entre múltiples projectes i equips. Els serveis al núvol poden agregar i analitzar tendències en dades entre execucions d'una manera que les eines locals no poden.
Processament per lots: auditar una biblioteca de models existents — tots els fitxers IFC lliurats a un CDE durant els darrers dos anys — és pràctic en mode per lots al núvol i poc pràctic de fer manualment al navegador.
Models no sensibles: en projectes en què els requisits de tractament de dades no prohibeixen pujar-los al núvol, els validadors al núvol ofereixen una integració CI/CD que les eines de navegador no igualen.

Quan la validació al navegador és la millor opció

Projectes governamentals i de defensa: els models per a infraestructura pública, instal·lacions de defensa i actius segurs solen tenir restriccions de tractament de dades que prohibeixen pujar-los a serveis de tercers. La validació al navegador és l'única opció que compleix la normativa.
Projectes residencials i comercials sensibles: els models BIM sovint contenen informació d'ocupants, adreces de propietaris i metadades d'actius que qualifiquen com a dades personals segons l'article 4 del RGPD. Processar-los en un servidor de tercers sense un DPA vàlid i una base legal és incompliment normatiu.
Ús a obra i en camp: un fitxer IFC de 200 MB per una connexió 4G es puja lentament i de manera poc fiable. La validació al navegador el processa localment en segons, sense dependre de l'amplada de banda de pujada.
Prevalidació abans de pujar al núvol: fins i tot quan un equip fa servir un validador al núvol com a filtre formal, executar primer una comprovació al navegador detecta problemes evidents sense necessitat de pujar el fitxer — reduint els costos i la freqüència d'ús del núvol.

Sis errors de validació que cometen els equips BIM — i què signifiquen realment

Error 1: «L'IDS ha passat — el model és correcte»

L'IDS només valida el que declara l'especificació .ids. Si el teu fitxer exigeix FireRating als murs però el teu EIR també exigeix IsExternal a les portes, codis Uniclass als elements estructurals i conjunts de quantitats a les lloses — i no s'han escrit aquestes especificacions — el motor informarà que es compleixen tots els requisits mentre la meitat del teu EIR queda sense comprovar. Un IDS superat és una confirmació contractual contra una especificació concreta. No és un certificat general de qualitat.

Error 2: «El verificador de buildingSMART ha dit que és vàlid»

La validesa d'esquema és el terra, no el sostre. Un fitxer en què cada element té Name='' i zero conjunts de propietats és perfectament vàlid segons l'esquema. Un model sense IfcElementQuantity, sense classificació i amb cada element físic col·locat directament a IfcSite en lloc d'una planta és perfectament vàlid segons l'esquema. Superar el verificador de buildingSMART vol dir que el fitxer STEP té el format correcte — no diu res sobre si les dades són útils.

Error 3: «El puc obrir en un visor, així que està bé»

Els visors IFC són permissius per disseny — estan fets per mostrar geometria independentment de la qualitat de les dades. Un visor que es negués a obrir fitxers invàlids segons l'esquema o pobres en dades seria inutilitzable. Que la geometria es representi correctament no diu res sobre la completesa dels conjunts de propietats, les convencions de nomenclatura, l'estabilitat dels GUID, la classificació ni cap de les 44 dimensions de qualitat. Visualitzar un fitxer és categòricament diferent de validar-lo.

Error 4: comprovar només la geometria, ignorant les dades de propietats

Un reflex habitual és obrir l'IFC, inspeccionar el model 3D i, si l'edifici es veu correcte, donar el fitxer per bo. La geometria representa aproximadament el 30 % del que fa útil un fitxer IFC. Els conjunts de propietats, les classificacions, els noms d'element, les assignacions de tipus i els conjunts de quantitats són el que realment consumeixen els sistemes de FM, els gestors de costos i els registres d'actius del CDE. Un fitxer geomètricament correcte amb conjunts de propietats en blanc falla en el lliurament.

Error 5: validar només una vegada, a la data límit de lliurament

Tractar la validació com l'últim pas abans d'una presentació al CDE vol dir esmenar incidències sota pressió i sense marge. Un model amb 800 incidències de validació descobertes el dia abans de la data límit acabarà lliurant-se amb problemes coneguts o incomplirà el termini. La cadència correcta: Nivell 1 després de cada exportació, Nivell 2 abans de cada revisió interna (setmanal com a mínim), Nivell 3 dues setmanes abans de cada fita formal.

Error 6: ignorar l'estabilitat dels GUID entre reexportacions

Els GUID duplicats dins d'un fitxer són un problema de Nivell 1 i qualsevol validador els detecta. Però la inestabilitat dels GUID entre reexportacions — quan el mateix element rep un GlobalId diferent cada vegada que s'exporta el model — és invisible per a la validació d'un sol fitxer. Quan els GlobalId es desvien entre revisions, cada comentari de BCF, referència d'element del CDE i etiqueta d'actiu de FM esdevé en silenci una referència penjant. Això exigeix comparar dues revisions i revisar la configuració d'exportació, no només validar un únic fitxer.

Un flux de treball de validació pràctic per a coordinadors BIM

Després de cada exportació IFC: executa una comprovació de Nivell 1. Triga menys de 30 segons en qualsevol validador de navegador. Corregeix els GlobalId duplicats, els elements orfes i les ruptures de jerarquia espacial abans que s'acumulin entre revisions.
Abans de cada revisió interna (setmanal o per sprint): executa una comprovació completa de Nivell 2. Revisa la tendència del Health Score. Una puntuació que baixa entre revisions vol dir que s'estan introduint incidències noves — troba'n l'origen abans que es converteixi en un patró.
En rebre qualsevol model de disciplina d'un tercer: executa el Nivell 1 i el Nivell 2 abans de federar-lo. Un model que reps pot portar incidències que heretes al model de coordinació — detecta-les de seguida, no tres setmanes després de la coordinació amb una federació trencada.
Dues setmanes abans de qualsevol lliurament de fita formal: executa els tres nivells. Objectiu de Health Score ≥ 80 abans de l'IDS. Dues setmanes donen marge per esmenar sense pressió. Marca-ho aviat — no consumeixis el marge de temps.
Abans de pujar al CDE: executa el Nivell 2 i el Nivell 3. Adjunta el certificat de Health Score i l'informe de superació de l'IDS al lliurament. Això crea un rastre d'auditoria documentat i dona a l'information manager tot el que necessita per acceptar el lliurament.
Després de qualsevol actualització de l'eina d'autoria o canvi a la configuració d'exportació: reestableix la línia de base d'estabilitat de GUID comparant dues exportacions consecutives. Una actualització de Revit o una configuració d'exportació modificada poden canviar en silenci el comportament de generació de GlobalId.

Consells d'expert

Prioritza per penalització, no per volum

No corregeixis les incidències per ordre de volum — corregeix-les per ordre d'impacte en el Health Score. Tres camps de metadades d'IfcProject absents poden costar 15 punts. Vuit-cents avisos de nomenclatura poden costar 8 punts en total. Fes servir el desglossament per gravetat per prioritzar per impacte.

Bloqueja la configuració d'exportació en una plantilla

Cada vegada que la configuració d'exportació es reconfigura manualment, hi ha el risc de desviar-se cap a una configuració diferent. Crea una configuració d'exportació IFC amb nom a la teva eina d'autoria, fes-ne commit a la plantilla del projecte i documenta la configuració exigida al BEP. La deriva de configuració és l'arrel de la majoria de problemes d'exportació del tipus «l'altra vegada funcionava».

Tradueix l'EIR a IDS a l'inici del projecte

Tradueix les clàusules més crítiques de l'EIR a una especificació IDS en les dues primeres setmanes del projecte. Fins i tot un fitxer .ids parcial — cinc o sis especificacions — és millor que una revisió manual completa de l'EIR en el moment del lliurament, i detecta buits de dades sistemàtics d'hora, quan encara són barats de corregir.

Valida cada model de disciplina abans de federar

Les incidències d'un model de disciplina poden amagar o interactuar amb les d'un altre en una federació. Valida entrades netes, federa net. Validar només el model de coordinació després de federar dificulta assignar les incidències a l'origen correcte.

Preguntes freqüents

Passar el Nivell 1 vol dir que em puc estalviar el Nivell 2?

No. El Nivell 1 i el Nivell 2 mesuren propietats completament diferents d'un fitxer. Un fitxer vàlid segons l'esquema (Nivell 1) pot no tenir cap conjunt de propietats, noms d'element buits, cap classificació i cap metadada ISO 19650 — i obtenir un 20 en una comprovació de qualitat (Nivell 2). Sempre calen els dos. Pensa en el Nivell 1 com «el fitxer està correctament empaquetat» i en el Nivell 2 com «el contingut del paquet és el que s'havia demanat».

L'IDS substitueix el buildingSMART Validation Service?

No. L'IDS comprova els requisits d'informació específics del projecte (Nivell 3). El buildingSMART Validation Service comprova el compliment de l'esquema (Nivell 1). Operen en nivells completament diferents i responen preguntes diferents. Un model que superés l'IDS però fallés la validació d'esquema seria una contradicció lògica — la integritat de Nivell 1 és un requisit previ perquè la comprovació de Nivell 3 tingui sentit.

Quines facetes de l'IDS he de prioritzar per a un lliurament BIM estàndard?

La faceta Property cobreix el 70–80 % dels requisits reals d'EIR — la majoria de clients volen valors de conjunts de propietats omplerts en tipus d'element concrets. La Classification cobreix la major part de la resta en projectes regits per Uniclass o OmniClass. La faceta Entity apareix a gairebé totes les especificacions com a filtre d'aplicabilitat. Material i PartOf aborden requisits contractuals específics. Comença per Entity + Property, afegeix Classification si l'EIR ho exigeix, i amplia a partir d'aquí.

Puc validar un IFC sense pujar-lo enlloc?

Sí. Els validadors basats en navegador processen el fitxer íntegrament al teu navegador amb WebAssembly. Els bytes de l'IFC mai surten del teu dispositiu — les 44 regles de qualitat, el càlcul del Health Score i el motor complet de l'IDS s'executen del costat del client. Per a models amb restriccions de tractament de dades — actius governamentals, dades residencials sensibles, infraestructura de defensa — sovint és l'única opció que compleix la normativa.

Quin llindar de Health Score he d'especificar al BEP?

≥ 80 és el llindar estàndard per al lliurament a un CDE i la coordinació de disseny. ≥ 90 per a lliuraments de desenvolupament del disseny amb LOD 300 o superior i per a les presentacions formals de fites d'ISO 19650. ≥ 70 és acceptable per a revisions internes en fase de concepte. Per sota de 60, el model té problemes estructurals de qualitat i no s'hauria de lliurar a cap tercer sota cap circumstància.

Una sola eina pot cobrir els tres nivells de validació?

Algunes eines ho fan. IFC Viewer Online cobreix el Nivell 1 (regles d'integritat, incloent comprovacions de GUID, jerarquia i capçalera de fitxer), el Nivell 2 (comprovació de qualitat de 44 regles amb Health Score) i el Nivell 3 (motor IDS 1.0 validat contra els 100 testcases oficials de bSI). Solibri cobreix el Nivell 2 i el Nivell 3 amb un motor de regles més sofisticat però sense processament basat en navegador. El buildingSMART Validation Service només cobreix el Nivell 1. IfcOpenShell es pot programar per al Nivell 1 i el Nivell 2.

Resum

Vàlid segons l'esquema no vol dir vàlid per al projecte. Vàlid per al projecte no vol dir conforme a l'EIR. Calen les tres capes de validació — i confondre-les és l'arrel de la majoria de fallades de lliurament formal.
IFC Viewer Blog

Nivell 1: executa'l a cada exportació

Integritat de l'esquema, unicitat i format del GlobalId, jerarquia espacial. Triga 30 segons. Detecta les fallades estructurals que corromp en silenci el BCF, el versionat del CDE i els registres d'actius de FM més avall en el procés.

Nivell 2: fes-lo el filtre de cada lliurament al CDE

44 regles de qualitat, Health Score, convencions de nomenclatura, completesa dels conjunts de propietats, metadades ISO 19650. Exigeix ≥ 80 al teu BEP i EIR. Aquesta és la capa que fa útil un model — no només parsejable.

Nivell 3: verifica'l abans de cada fita

Especificacions IDS que codifiquen el teu EIR i AIR en forma llegible per màquina. Tradueix les clàusules crítiques a l'inici del projecte, no la setmana abans del lliurament. Un IDS superat és un rastre d'auditoria contractual documentat.

Executa una comprovació de qualitat completa sobre el teu model actual — en menys de 30 segons, en qualsevol navegador, sense pujar res. Després llegeix la guia de l'IFC Health Score per entendre com es calcula la puntuació i quin llindar fixar al teu BEP. Si cal corregir valors de propietats o GUID en un fitxer rebut, la guia de l'editor d'IFC en línia gratuït tracta l'edició no destructiva de propietats sense passar de nou per l'eina d'autoria. I per als errors estructurals més habituals que provoquen rebuigs de Nivell 1, consulta els 7 errors de validació IFC més comuns.

Verificador de models IFC: la guia completa de validació IFC, qualitat del model i IDS