¿Qué tipo de información podemos encontrar en modelos BIM?
Hoy en día es fácil encontrar información acerca de la metodología BIM o de cómo funcionan sus herramientas (como, por ejemplo, Revit), sin embargo, sigue habiendo cierta confusión cuando pensamos en qué contienen exactamente los modelos de información o para qué pueden ser usados.
Es muy común pensar en BIM y rápidamente asociarlo con Revit o con un modelo geométrico, pero nada más lejos de la realidad. BIM es una metodología que engloba procesos, tecnología, colaboración e información de entre otros. Debemos recordar que, como se suele decir, la letra más importante de BIM es la “I” de información y que cada vez más, las personas que trabajamos en BIM y solemos relacionarnos con proyectos bajo estos estándares asumimos funciones de gestores de la información y, por lo tanto, es importante conocer qué tipos de modelos y qué tipos de información podemos encontrar en un proyecto desarrollado bajo esta metodología.
The urban rebounder provides a safe, fun and effective totally body workout: bodybuilding &45; the natural approach byrd chest fitness arnold schwarzenegger bodybuilding exercises | bodyweight workouts
Tipos de información
Más adelante hablaremos sobre modelos de información y veremos que en ellos la información es fundamental y que esta, se modifica y crece a lo largo del ciclo de vida del activo.
Indistintamente de la fase en la que se encuentre el proyecto, un modelo de información solo puede existir si contiene los siguientes tipos de información:
- Geometría, es decir, la representación tridimensional de los elementos en base a unas coordenadas y a escala 1:1.
- Datos, es decir, todos los datos relacionados con los distintos elementos del proyecto (largo, ancho, marca, fabricante, etc.).
- Documentación; es decir, todos los documentos relacionados con el proyecto (planos, fichas técnicas, informes, etc.).
Debido a las etapas de madurez del proyecto y lo tipos de información existentes, existen tres requisitos a tener en cuenta para la gestión de la información:
- Definición de requisitos de la información
- Planificación del desarrollo de la información
- Desarrollo de la información
Tipos de modelo
Como ya hemos mencionado, debemos dejar de pensar en modelos que únicamente contienen la geometría o la documentación de un proyecto los cuales, por lo general, dejan de tener utilidad tras la ejecución de este.
Para saber que tipo de información podemos obtener debemos saber previamente de donde obtenerlo y aquí el concepto cambia.
La norma UNE-EN ISO 19650 nos explica que debemos comenzar a entender los modelos BIM como “modelos de información”. Un modelo de información es un conjunto de contenedores de información (archivo, sistema o aplicación de almacenamiento jerarquizado) que se puede utilizar para transmitir la intención de diseño o la representación virtual del activo que se va a construir.
Por lo tanto, la tipología de un modelo de información viene definida por su objetivo o la necesidad a la que debe dar respuesta y la fase constructiva en la que se genera.
Por ello, podemos encontrar dos agrupaciones para modelos de información;
- Modelo de información del proyecto, PIM: Modelo de información relacionado con la fase de desarrollo (ejecución).
- Modelo de información del activo, AIM: Modelo de información relacionado con la fase de operaciones (mantenimiento).
La diferencia entre un modelo de información y lo que normalmente se entiende como un modelo BIM (modelo de Revit, IFC, etc.) es que el concepto cambia, y no nos limitamos a un modelo como tal, sino a un repositorio de información que puede ser una CDE (Common Data Environment) donde conectamos bidireccionalmente todo y donde a través de un middleware, podemos obtener la información y traspasarla a otros softwares. Por lo tanto toda la información está conectada y relacionada entre sí y los datos se convierten en el protagonista de la historia. De manera más simple, es como si uniéramos un modelo geométrico con una base de datos.
Uno puede pensar que un modelo de Revit de por sí, es una base de datos puesto que, por ejemplo, yo tengo un modelo con sus elementos y todos los datos de estos, ¿pero realmente tengo toda la información que debe contener un modelo de información según define la ISO 19650?
La realidad es que no, no podemos garantizar la bidireccionalidad y la relación paramétrica entre los tres tipos de información definidos por la ISO. Por ejemplo, en Revit podríamos en cualquier caso asociar una ficha técnica a un activo mediante un parámetro, introduciendo la URL donde se encuentra la ficha. Esto sin embargo no funcionaría en un modelo de información puesto que no es bidireccional, y yo no podría desde la ficha localizar el elemento en el modelo.
Conclusión
Como hemos podido ver, la tendencia es cada vez más centrarse en la información o, mejor dicho, en los datos de estos proyectos, sacando del foco principal al modelo geométrico que tan acostumbrados estamos a ver.
Evidentemente para que este sistema funcione, el modelo geométrico debe estar correctamente desarrollado, del mismo modo que la definición de los datos o la documentación.
Debemos recordar que BIM busca la interoperabilidad y la colaboración de agentes siempre en base a un modelo 3D y que cada vez se hace más evidente la necesidad de contar con modelos fiables con información que nos permita hacer un uso correcto y optimo de los edificios y esto pasa por contar con datos e información correctamente relacionada con los elementos de un modelo.
No nos sorprendería que esta tendencia comience a coger fuerza y de aquí un tiempo podamos comenzar a incluso valorar la necesidad de distintos modelos de información según contextos o necesidades que aún no se contemplan en la ISO. Lo que es seguro es que los modelos de información y la gestión de datos han llegado para quedarse.
¿Por qué Dynamo? Vol. VII: Gestión de parámetros a través de Dynamo
Como sabéis los modelos BIM son bases de datos que incluyen información gráfica y no gráfica. En toda base de datos es importante contar con parámetros a los que asociar valores.
Estos parámetros pueden ser los que vienen por el propio programa, pero en la mayoría de casos hemos de generar nuevos o añadir parámetros adicionales a los existentes por diferentes motivos: usar los mismos parámetros entre proyectos, se nos quedan cortos los parámetros de sistema que trae Revit, un modelo es gestionado por diferentes equipos y cada uno de ellos. En el post de hoy veremos varios scripts que nos permiten gestionar parámetros tanto en el contexto de proyecto como en el contexto de las familias.
¿Cómo creamos diversos parámetros a la vez en un proyecto?
Es probable que nos interese, en un determinado proyecto, crear diversos parámetros de una misma vez. Si estos parámetros, además, deben garantizar una trazabilidad de la estructura de la información entre modelos de diferentes disciplinas, es recomendable que sean del tipo compartido. Ya que responden al mismo identificador GUID y será más fácil identificarlos entre modelos.
Los parámetros compartidos, como sabéis, se crean de una forma muy tediosa a través de la interfaz de Revit y además luego se han de asociar al proyecto. Con el sencillo script que os proponemos a continuación podremos hacer estos dos pasos a la vez y facilitar el archivo txt de parámetros compartidos al resto de agentes para que puedan cargar los parámetros, ya creados, en sus modelos.
Este script, a través de nodos que vienen por defecto con Dynamo. A través de, principalmente, strings definimos el nombre del parámetro y sus características: tipo de parámetro, grupo de parámetros dentro del modelo (Ilustración 2) y grupo de parámetros dentro del archivo txt de parámetros compartidos (Ilustración 3).
En este caso la creación de parámetros se ha realizado a través de escritura de parámetros únicos en codeblocks. Para numerosos parámetros podría realizarse a través de un archivo Excel en el que definiéramos distintas categorías o tipologías de parámetro distintas para cada parámetro.
Para ello crearemos una hoja de Excel que contenga la información necesaria para la creación de parámetros compartidos:
Y deberemos leer esta información y transformarla para asociarla al mismo nodo de la manera en la que lee la información:
¿Cómo añadimos parámetros compartidos existentes a un proyecto?
Una vez creado el txt, y se comparta con los colaboradores, estos podrán cargarlos dentro de su proyecto y asociarlos a las categorías pertinentes. Es un trabajo muy repetitivo que también puede automatizarse a través del siguiente script:
En este ejemplo se han asociado a la misma categoría cubiertas, pero también podría leerse la información del Excel que veíamos más arriba leyendo la información del mismo y filtrándola.
Conclusiones
Con el fin de automatizar procesos repetitivos, vemos que Dynamo nos puede servir también para crear todos aquellos parámetros que vayamos a necesitar en el proyecto o incluso para cargarlos en los diferentes modelos que componen el modelo federado. Debemos preparar herramientas que nos permitan cada vez realizar tareas repetitivas más rápido y con mayor volumen de parámetros
¿Por qué Dynamo? Vol. V: Auditorías de metadata o información no gráfica
Como sabéis los modelos BIM son bases de datos que incluyen información gráfica y no gráfica. En toda base de datos es importante mantener una consistencia y una coherencia entre elementos para garantizar que los modelos se realizan de una forma correcta.
La idea de comprobar que la definición geométrica de un modelo es correcta está muy extendida. A través del análisis de colisiones podemos detectar errores en los modelos por lo que respecta a información gráfica o geométrica, ¿pero que pasa con la información no geométrica?
¿Cómo comprobamos la información no geométrica?
Hay diversas maneras de comprobar que un parámetro está rellenado o no: podemos realizar tablas de planificación, filtros en una vista, revisión manual del modelo parámetro a parámetro… Maneras hay muchas, pero todas las anteriores comparten algo entre sí, y es que en todas ellas se tarda mucho tiempo en comprobar que todo está correcto. Si además tenemos en cuenta que en un proyecto puede haber diversos modelos o archivos que comprobar, la cantidad de tiempo que hay que invertir en comprobar todos los parámetros puede desesperarnos o bien empujarnos a no comprobarlo.
De la misma manera que utilizamos los análisis de colisiones para comprobar y corregir errores a nivel geométrico, deberíamos usar las auditorías de metadata como herramienta que nos permita detectar errores a nivel de información no gráfica, inconsistencia e incoherencia de datos o cualquier descuido que pueda desestructurar nuestra base de datos para poder corregirla.
Antecedentes
En el siguiente proyecto se federó a través de 7 modelos distintos con distintas zonas del proyecto e instalaciones. El proyecto corresponde a una parada del metro junto con un intercambiador.
La información que debe revisarse corresponde a parámetros de ubicación y localización, estado en obra, descripciones, clasificaciones, unidades de medida, mediciones, etc.
Revisar todos estos modelos hubiera llevado demasiado tiempo ya que supone entrar en todos los modelos y realizar una comprobación visual de forma individual. Con la intención de agilizar el proceso se opta por hacerlo a través de automatizaciones.
Script
El script tiene 3 partes, una que recoge los elementos y los valores de los parámetros que nos interesa analizar, tratamiento de estos datos y volcado de los resultados a Excel.
Para generar este script se han usado los siguientes paquetes:
- Rhythm
- Orchid
Recogida de información
Para realizar la comprobación primero deberemos extraer la información necesaria del modelo: elementos y valores de parámetros de los elementos. Dentro de un modelo Revit tenemos muchos parámetros y no los queremos analizar todos, solo aquellos que nos exige el cliente. De forma que extraeremos los elementos del modelo [1], leeremos de nuestra base de datos (Excel) los nombres de los parámetros que queremos leer [2] y lo cruzaremos con los elementos detectados en el modelo para obtener los valores [3].
Tratamiento de la información
Una vez que hemos extraído los datos, debemos comprobar que se encuentran debidamente rellenados. Es muy difícil realizar esta comprobación ya que tendríamos que realizar previamente una base de datos donde se mostrara para cada elemento que valor debería visualizarse. En este caso, lo que se hace es comprobar que no se encuentre vacío, con un espacio o con el texto “A emplenar” que es el texto de partida. Eso es lo que comprobamos con el primer Python Script llamado MSI.Excluidor. Muchas de estas funciones se pueden realizar con nodos existentes de Dynamo, pero practicar y no perder el uso de este lenguaje, si son pocas líneas de código, opto por escribirlo yo mismo.
Con el segundo lo que buscamos es recoger todos los id’s de elementos que no estén debidamente rellenados y los escribo en un formato beneficioso para nuestros modeladores. Dentro de Revit tenemos la opción de seleccionar varios elementos de golpe, la función se llama Selección por id. Si somos capaces de seleccionar todos los elementos que requieren del rellenado de un parámetro, será fácil para el equipo de modelado encontrarlos y poder rellenarlos. Pero para ello es necesario extraerlos con un formato concreto: id1, id2, id3, etc. Es necesario que de una lista generemos un string donde se dividan los antiguos índices mediante comas. El segundo Python Script, MSI.Compactador ID’s, se encarga de realizar esta última tarea.
A través de un codeblock calculamos el % de elementos analizados y el porcentaje de elementos que se encuentran incorrectamente rellenados, así tendremos un indicador del estado de parametrización del modelo parámetro a parámetro.
Volcado de los resultados a Excel
Una vez realicemos esta acción para cada parámetro que queramos analizar, recogeremos todos los resultados en una lista y lo exportaremos a una hoja de Excel. Dicha hoja se llamará de la misma manera que el documento que estamos analizando. Por lo que deberemos ejecutar este script en cada uno de los archivos que conforman el modelo federado.
El aspecto con el que cuentan las distintas hojas para cada modelo en el Excel es este:
Una columna para el nombre del parámetro analizado, otra con los ID’s de los elementos que necesitan ser rellenados y al lado el % de elementos debidamente rellenado.
Como resumen, generamos una tabla donde podemos ver el estado general del proyecto comparando los diversos % de los modelos y del conjunto.
De esta manera podremos identificar en qué modelos y qué parámetros están más o menos trabajados.
Conclusiones
La gestión de datos a través de automatizaciones es indispensable si queremos mantener la calidad de los modelos y su información a la vez que controlamos los costes derivados de la generación y auditoria de los modelos. Debemos preparar herramientas que nos permitan cada vez realizar tareas de comprobación más rápido y con mayor volumen de datos.
Preguntas frecuentes sobre objetos BIM
A menudo, surgen
muchas dudas relacionadas con los Objetos
BIM que usamos en los modelos. No en cuanto a su proceso de creación sino a
las diferentes implicaciones que tiene utilizar nuestras propias familias o las
de un fabricante, a las necesidades de nuestra propia biblioteca, tamaños
máximos de archivo, etc.
A lo largo de
implantaciones y formaciones realizadas por MSI Studio surgen preguntas y cuestiones
recurrentes, como las siguientes:
¿Qué diferencia hay entre un Objeto BIM y una familia?
Los Objetos BIM
son modelos geométricos realizados con softwares paramétricos de forma que permitan
modificar sus atributos. Cuando hablamos de Objetos BIM, siempre nos referimos
a formatos abiertos. Cuando hablamos de Familias, nos referimos a los Objetos
BIM que creamos con una herramienta específica: Autodesk Revit.
¿Qué es mejor: descargarse las familias de internet o crearse uno mismo sus propias familias?
Es una pregunta
muy amplia y lo que está claro es que nunca hay una solución única, pero
sí una más adecuada para cada caso. Se deberían tener en cuenta una serie de aspectos
relacionados con las familias en función de su procedencia:
- Las
familias que descargamos de internet suelen venir de diversos bancos de
familias en los que cada una está realizada bajo un estándar distinto. Muchos
de estos elementos tendrán los mismos atributos,
pero nombrados de forma distinta, con lo que estaríamos contribuyendo a la
desestructuración de la base de datos. - Si
utilizáramos familias que provienen únicamente de un repositorio de objetos BIM entonces conseguiríamos
tener una base de datos estructurada,
pero con información que posiblemente no nos interese.
Al realizar
implantaciones siempre facilitamos una caja
de herramientas al cliente para que pueda trabajar con unas familias que
cumplan con nuestros propios controles de calidad y, así, poder garantizar su
funcionamiento. Además, al estar todas realizadas bajo el mismo estándar,
garantizan que la base de datos esté organizada y los modelos sean consistentes
entre sí.
¿Utilizaremos los mismos objetos en las distintas fases de proyecto?
Dependiendo de
lo que queramos obtener a través de las familias podremos utilizarlas, o no, a
lo largo de todo el proyecto:
- Si
nos encontramos en fase de diseño y debemos adaptar las familias que
descargamos a nivel gráfico para que se representen de una forma parecida
probablemente no nos salga a cuenta usar familias de fabricante. Deberíamos
entrar en las diferentes familias y adaptarlas gráficamente. Además, en fase de
diseño aún no sabemos ni el modelo ni el producto que se acabará instalando por
lo que hay una alta probabilidad que esa familia sea substituida más adelante.
Es recomendable usar elementos genéricos para las fases de diseño. Genérico
significa que tiene unas determinadas propiedades o necesidades (como, por
ejemplo, la resistencia frente a incendio o bien la absorción acústica) pero no
corresponde a ningún producto comercial específico (Modelo “X” de la casa “Y”).
En ningún momento asociamos a un elemento genérico con un elemento que no esté dotado
de información sino de elementos que, debido a la fase en la que se modelan,
hay determinados campos de información que aún no pueden tener asociados. - Como
comentábamos, en fase de obra, al cambiar de manos la propiedad de los modelos,
momento en el que se deciden los productos y elementos que se van a instalar en
obra, hay una alta probabilidad que las familias sean substituidas. En este
caso, puede cobrar mucho sentido utilizar familias de fabricantes ya que
cuentan con toda la información del producto embebida y la recopilación de
información para el modelo As Built es mucho más sencilla. - Para
la fase de operaciones, como el modelo ya se encuentra realizado, no deberemos
escoger entre unos u otros. Si viene con elementos de distintos fabricantes, deberemos
invertir tiempo en organizar los atributos y la información de todos los
elementos del modelo. Al venir de diferentes fabricantes, cada familia estará
creada de una forma distinta. En el caso de que los elementos sean genéricos y
hayan sido realizados por un despacho o ingeniería concretos, solo deberemos
comprobar que se han realizado de forma correcta para que la extracción de la
información se realice de forma correcta.
¿Es necesaria una Biblioteca de objetos BIM?
Sí, es
necesaria. No solo por
lo que representa tener una gran cantidad de componentes que reutilizar en
diversos proyectos (y reutilizar es ahorrar recursos) sino para garantizar que
todas estén realizadas de la misma manera y nos permitan asumir los objetivos
para los que se han creado, que cuenten con una representación gráfica común y
propia de la organización, cuenten con una determinada información asociada,
etc.
Aun así, no
podemos tener una biblioteca que disponga de elementos pertenecientes en
futuros proyectos, por lo que es necesario dejar detallado el proceso de
creación de esta familia, o bien los requisitos con los que ha de cumplir, para
asumir un determinado nivel de calidad. Por lo que podríamos decir que una Biblioteca de Objetos BIM es fruto de
un Estándar de creación de Objetos BIM.
¿Qué estándares de creación de objetos BIM encontramos?
Podemos
encontrar diferentes tipos de estándar en función de si son estándares de Familias o estándares de Objetos BIM. Los estándares de familias
pretenden establecer un protocolo de creación para que la gente sepa cómo crear
nuevos Objetos BIM para un software determinado, Revit en este caso. Configuraciones de programa y
recomendaciones de modelado, como por ejemplo el Revit Style Guide desarrollado por BimObject.
En cambio, los estándares de objetos BIM
defienden los formatos abiertos y se centran en la información que deberían contener para poder darles uso a lo largo
de su ciclo de vida. Algunos ejemplos son: el NBS BIM Object Standard realizado por la National BIM Society (UK), OBOS: Open BIM Object Standard realizado por Natspec (AU) y Masterpec
(NZ) así como el eCOB: Estándar de
Creación de Objetos BIM.
Éste último (eCOB), realizado por el ITeC
(Instituto de Tecnologia de la Construcción), se basa en el esquema IFC ampliándolo con un determinado
número de atributos e información adicionales. Es un estándar que puede usarse
tanto a nivel internacional como local debido a que se encuentra adaptado al
Código Técnico de la Edificación (CTE), al Catálogo de Elementos Constructivos
(CEC) y a la normativa aplicable a los productos de la construcción.
¿Para qué establecer un control de calidad para las familias? ¿Las familias deben tener un mantenimiento?
Debido a que el
secreto de las familias es la estandarización y estas se someten a una mejora
continua, vale la pena controlar que todas las familias que estén en nuestra
biblioteca estén realizadas bajo las mismas directrices. La cual cosa solo es
posible a través de controles de calidad del contenido que hemos creado.
Los controles de
calidad nos permiten comprobar que las familias que creamos se hayan realizado
de forma correcta, pero para comprobar que con, el paso de los proyectos o con
las actualizaciones de los protocolos, los elementos siguen cumpliendo con los
requisitos necesitamos realizar un “mantenimiento” de nuestra biblioteca de
objetos. Pensad que a lo largo de los distintos proyectos las familias pueden
ser manipuladas, en algunos casos mejorándolas y, en otros casos,
empeorándolas.
Las familias son las piezas que conforman
nuestros modelos y vale la pena que destinemos esfuerzos en obtener unas piezas
de calidad, ya que la calidad de nuestros objetos definirá la calidad del
modelo.
Os animo a que si tenéis más dudas sobre los
objetos BIM o sobre las familias de Revit (tamaño máximo de las familias,
consideraciones para la exportación a IFC, etc), nos las hagáis llegar a través
de los comentarios que encontraréis más abajo.
