Para poder utilizar de forma correcta un modelo BIM, es necesario que éste sea coherente, no tenga deficiencias ni errores ni en su geometría ni en su meta-información. De tal forma que un uso de un modelo incorrecto dará lugar a fallos en cualquiera de los usos que se le vayan a dar: mediciones, uso en obra, mantenimiento etc.
Algunos ejemplos:
En cuanto a la comprobación de las geometrías, podemos valorar la posibilidad de comprobar si los pilares por ejemplo se han modelado con unas dimensiones correctas, ventanas, etc.
Así mismo podemos pensar en dimensiones mínimas, separación mínima de elementos, alturas máximas, alturas mínimas, incluso sacarnos multitud de comprobaciones que se pudieras hacer en cuanto al CTE.
Todos estos controles, se pueden automatizar mediante una serie de reglas de comprobación del software Solibri Model Checker de forma que sólo introducir el modelo podemos hacer la revisión del mismo en cuanto a estas reglas con un solo click:
Así mismo, si el proyecto está sujeta a una codificación de los elementos BIM como puede ser Omniclass, uniclass, SFB-NL o la española GUBIMClass. Se puede igualmente automatizar una regla para que compruebe que todos los elementos, se han clasificado o no, y además dependiendo de la entidad (muro, ventana, puerta etc), comprobar si el código es correcto, y así mismo dependiendo del material (metal, madera, hormigón) comprobar si se ha codificado correctamente. No tiene el mismo código un muro de ladrillo que un muro de hormigón.
Por otra parte, de cara a una correcta estandarización de los modelos BIM, se han de comprobar que los elementos son de carga/no de carga, son exteriores/interiores para que se cumpla el estándar de en entrega OPEN-BIM de la Building Smart para que nuestro IFC final será totalmente compatible con los diferentes agentes de nuestro proyecto, hablando el mismo lenguaje.
En BIMnD siempre apostamos por la calidad de los modelos realizando a los mismo un exhaustivo control de calidad mediante las reglas del “BIM Basis ILS” de origen Holandés que utilizamos para la revisión y control de calidad de todos nuestros proyectos.
Analicemos estas reglas que vienen agrupadas en dos apartados 3 y 4, en cuanto a su estructura e información interna:
Esta regla comprueba que el IFC tiene relleno el parámetro,IFC Project, para asegurarnos de que está identificado. Un ejemplo sería:
Ed.Severo Ochoa 35_Arquitectura_Módulo B
Asegurar siempre una nomenclatura uniforme y consistente de los dentro del proyecto.
Siempre utilizamos un cubo de 1x1x1 en cada una de las disciplinas, de tal forma que cuando se carga, por ejemplo, arquitectura e instalaciones, ambos modelos tienen ese cubo y visualmente se puede comprobar que coincide y no hay desfase alguno entre las coordenadas de ambos modelos.
3.2.1: Comprueba que el modelo no está (demasiado) lejos de cero. Esta línea comprueba si algún componente está más allá de las distancias preestablecidas del punto cero:
3.2.2: Esta línea comprueba si un objeto de tipo *cero* punto* está presente. Si no es así, se crea un problema.
Comprueba que se han creado los niveles y que tienen un nombre correcto. Así mismo, se comprueba y analizan todos los elementos del modelo, y detecta aquellos que están asignados a un nivel incorrecto.
Esta regla comprueba lo siguiente:
Un ejemplo es si pensamos un canecillo del alero en una 5ª planta, que estuviera vinculado a la planta baja; esto nos lo marcaría como error al detectar el desfase de altura.
Así mismo se comprueba si los nombres de los pisos utilizados aparecen en la lista permitida de nombres.
Con esto vamos a comprobar que la exportación a IFC es correcta al asignar la entidad de cada elemento. Una ventana tiene que ser IfcWindow, una puerta IfcDoor de tal forma que si hemos exportado incorrectamente estos elementos, Solibri Model Checker nos avisará de que esta regla no se cumple. Así mismo, como hemos clasificado los elementos, cada uno de ellos tendrá su código.
Esta regla comprueba que todos los elementos tienen rellenos de forma correcta los campos de Nombre y Tipo de elemento. No dejando ninguno de ellos indefinido ya que generaría una falta de información vital en el modelo de calidad.
Mediante esta regla comprobaremos, por una parte que todos los elementos tienen la codificación asignada según nuestro sistema de codificación y que el código sea el correcto según el tipo de elemento en el IFC.
Por ejemplo: Según clasificación SFB:
Dos Ejemplos:
Mediante esta regla, comprobamos que todos los elementos tienen relleno el campo IfcMaterial, no dejando lugar a falta de información en este apartado. Además comprueba que se hayan puesto los materiales correctos.
Dos Ejemplos:
Básicamente, no se permiten intersecciones no duplicaciones en un modelo.
Por lo tanto esta regla comprobará que no existan de la siguiente forma:
“GRUPO VIRDATED SL ha sido beneficiaria del Fondo Europeo de Desarrollo Regional cuyo objetivo es mejorar el uso y la calidad de las tecnologías de la información y de las comunicaciones y el acceso a las mismas y gracias al que ha desarrollado una Implantación en modalidad de cloud computing de una solución CRM, para la mejora de competitividad y productividad de la empresa. Esta acción ha tenido lugar durante la Convocatoria 2023 (año 2023). Para ello ha contado con el apoyo del Programa TicCámaras de la Cámara de Comercio de Granada.”
Fondo Europeo de Desarrollo Regional
Una manera de hacer Europa