¿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.
¿Qué es un modelo único de documentación?
Cuando se trabaja en un proyecto con Revit,
es común dividir el edificio en distintos archivos. De este modo se
consigue no concentrar toda la información en un único modelo que
resultaría demasiado pesado como para trabajar cómodamente en él.
En función de las necesidades requeridas en un
proyecto, se pude estructurar el trabajo y el desarrollo de un proyecto BIM
de varias maneras. Un criterio que se puede seguir para desarrollar los archivos
de un proyecto es plantear los modelos siguiendo las distintas disciplinas
existentes, dando como resultado un archivo de arquitectura (ARQ), uno de
estructuras (STR) y otro de instalaciones (MEP).
Estos archivos se van desarrollando paralelamente entre sí hasta que llega el momento de documentar el proyecto. Llegados a este punto muchas personas se preguntan qué es mejor, ¿obtener todos los planos de los distintos archivos o generar un cuarto archivo de Revit (DOC) donde generar y gestionar las tablas, planos, imágenes, leyendas, etc. de un proyecto?
Funcionamiento
El funcionamiento de un archivo único de
documentación es sencillo. La forma de trabajar en él es el mismo que en un
archivo estándar con vínculos de otras disciplinas sólo que en este
caso, por lo general, no existirá ningún elemento modelado y todas las labores
de documentación se realizarán sobre los modelos vinculados de arquitectura,
estructuras e instalaciones.
La idea es agrupar toda la información del
modelo en un único archivo donde se encuentren todos los planos de las
distintas disciplinas, las vistas gráficas (plantas, secciones, 3D, etc.),
tablas de planificación, leyendas, todos los tipos de elementos gráficos como
líneas o textos, familias de anotación, imágenes y evidentemente los vínculos.
Es por eso que en este tipo de modelos se debe
tener un gran control sobre los vínculos (Insertar>Gestionar vínculos) y
sobre el visualizador de gráficos. Es posible que la visualización de
ciertos elementos cambie dependiendo de en qué vínculo se encuentre con lo que
es muy probable que cada vínculo tenga su propio visualizador de gráficos personalizado.
Sin embargo, no se podrá generar ninguna vista
si previamente no se han generado niveles. Para este tipo de elementos
(niveles, rejillas, etc.) lo más recomendable es utilizar la herramienta “Copiar
y monitorizar” para contar con los mismos elementos de referencia que los
archivos que contienen los modelos y además ser avisados si alguno de ellos
cambia o se suprime.
Pros y contras
El principal objetivo
cuando se recurre a esta solución es mejorar el rendimiento ya no solo
del modelo, sino también el del ordenador.
Es bien sabido que,
a más elementos en un modelo, peor rendimiento. Cuantas veces nos hemos
encontrado modelos donde es prácticamente imposible orbitar alrededor
del edificio o donde se ejecuta alguna herramienta y debemos esperar varios minutos
hasta que se cumple la orden. Incluso puede darse el caso en el que no sea
posible contar con un ordenador suficientemente potente para trabajar con
programas tan exigentes como los de modelado BIM. Todos estos problemas pueden
resultar especialmente molestos en fases de documentación donde constantemente
se están añadiendo elementos como cotas, textos, etiquetas,
etc. Separar la documentación de los modelos afecta directamente al rendimiento
del ordenador, el cual consumirá menos recursos y funcionará mejor.
Trabajar con un modelo único de documentación
también permite definir responsabilidades con más claridad dentro de un
proyecto. En algunos casos hemos podido ver equipos que externalizan el trabajo de documentación y que, al tener un modelo
a parte y único, evitaba los clásicos problemas que pueden aparecer flujos de
trabajo estándar donde se pueden llegar a eliminar o editar elementos del
modelo. De esta manera también se consigue tener toda la documentación del
proyecto concentrada en un único modelo y no dividida en varios.
El problema lo
podemos encontrar en proyectos muy grandes, donde ya de por sí hay varios
modelos de cada disciplina y se pueden complicar las labores de gestión
de estos. Además, cualquier cambio que se precise en los modelos se deberán
hacer desde sus respectivos archivos, con lo cual, si se detectase algún error,
se debería cerrar el archivo de documentación o descargar el link, para
abrir el archivo que contenga el modelo y cambiarlo.
Por lo general si
un vinculo se descarga del archivo de documentación y ya hay cotas o etiquetas
colocadas, estas no se pierden siempre que se vuelva a cargar este mediante las
opciones “volver a cargar” o “volver a cargar desde”, pero hay que tener en
cuenta que estos archivos son más sensibles a cambios y si que se puede llegar
a perder alguna información y más aún en casos en que los modelos siguen vivos
y se están editando al mismo tiempo que se genera la documentación.
En
cualquier caso, si que se eliminaran las etiquetas o las cotas que hagan
referencia a un elemento el cual ha modificado su ID. Esto puede darse
cuando un elemento se elimina o se “remodela”. Por eso es
importante que los equipos de modelado y documentación estén bien coordinados
entre sí y entiendan que un elemento que ya está acotado o etiquetado en el
archivo de documentación no se debe suprimir si se quiere modificar, siempre
será mejor editarlo.
Por otro lado, se debe preparar muy bien el
visualizador de gráficos y hacer uso de los filtros de vista. Es común
que estos modelos cuenten con un gran número de filtros de vista para modificar
el grafismo de los distintos elementos puesto que no solo basta con configurar
la visualización de gráficos de los vínculos como “personalizado”. Esto puede
suponer un problema cuando al modelo acceden personas que no conocen bien el
funcionamiento de este, y generan más filtros o editan la configuración cuando
realmente no es necesario. Esto puede afectar a plantillas de vista o a
configuraciones que ya estaban establecidas de una manera determinada y que den
como resultado vistas de entrega defectuosas.
Por último, hay que tener presente que los
vínculos entre sí no se pueden unir, y que en el caso de distintos
vínculos que muestren elementos que deban estar unidos entre sí, se deberá
pensar alguna solución para disimular las juntas que se generarán mediante regiones
rellenadas, de máscara o similares.
Conclusión
Para resolver la pregunta que nos hacíamos al principio, no podemos decir que una opción sea mejor que otra. Realmente, como todo en este mundo del BIM y el Revit, depende de la estrategia que sigamos o de los criterios establecidos en el contrato. Lo importante en situaciones como estas es pensar bien cuales van a ser nuestras necesidades y qué es lo que necesitamos obtener del modelo o del proyecto.
En MSI
particularmente preferimos homogeneizar los elementos necesarios para obtener
documentación como cotas, carátulas, textos y demás, y obtener la información
gráfica directamente de los modelos correspondientes siempre que sea posible. A
pesar de esto, creemos que siempre es necesario analizar las condiciones del
proyecto y buscar la solución más optima.
Si optamos por homogeneizar los archivos y en el
caso de necesitar planos en común como el índice, hacemos uso de la herramienta
Insertar vista desde archivo (Insertar>Insertar desde
archivo>Insertar vista desde archivo) para así insertar los planos de los
demás vínculos. Esto permite tener el plano y los elementos contenidos en él,
como vistas, tablas, leyendas, etc.