Desarrollo de Un Algoritmo para La Incorporación Masiva de Datos A Los Modelos Bim de Obras Civiles

Trabajo de Fin de Grado
Ingeniería Civil
DESARROLLO DE UN ALGORITMO PARA LA

INCORPORACIÓN MASIVA DE DATOS A LOS
MODELOS BIM DE OBRAS CIVILES
Autor: Ángel Díaz Murillo
Tutor: Blas González González
Dpto. Construcciones Arquitectónicas I

Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2020
i
Trabajo de Fin de Grado
Ingeniería Civil
DESARROLLO DE UN ALGORITMO PARA LA

INCORPORACIÓN MASIVA DE DATOS A LOS
MODELOS BIM DE OBRAS CIVILES
Autor:
Ángel Díaz Murillo
Tutor:
Blas González González
Dpto. de Construcciones Arquitectónicas

Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2020
iii
Trabajo de Fin de Grado: DESARROLLO DE UN ALGORITMO PARA LA INCORPORACIÓN
MASIVA DE DATOS A LOS MODELOS BIM DE OBRAS CIVILES
Autor: Ángel Díaz Murillo
Tutor: Blas González González
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes
miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2020
El Secretario del Tribunal
v
A mi familia
A Tania
Agradecimientos
A mi familia por todos los esfuerzos y por el apoyo incondicional. A Dani, Antonio, José,
Carlos, Javier e Ibón por permitirme desconectar todos estos años de carrera. A Jesús y
Julián por ser el apoyo para sacar adelante tantas asignaturas
Al equipo de TeamBIM Civil. A Francisco García por enseñarme todo lo que sé de
modelado y por ser una referencia como Ingeniero. A Luis por su ayuda desinteresada y
por lo buenos ratos mientras hablábamos de IFC. Y Blas por permitirme conocer al equipo
completo y por su guía durante todos estos meses
A Tania, porque sin ella no hubiera llegado hasta aquí.
vii
Resumen
El presente trabajo se ha enfocado a investigar sobre la tecnología BIM aplicada a las

infraestructuras civiles (lineales y nodales) en aquellos aspectos que pueden añadir valor al
proceso de construcción digital de dichas obras civiles, como pueden ser analizar y
determinar posterior a dicho análisis, los flujos de trabajo más eficientes para el modelado
de carreteras, y por otro parte el enriquecimiento de la información de construcción del
modelo o modelos BIM generados con programas comerciales de modelado.
En la primera parte del trabajo se ha profundizado en los elementos necesarios para
establecer un modelo BIM de carreteras, que no por obvio está bien estructurada su
implantación en algunos programas de modelado de carreteras, y en particular en el
software Civil3D utilizado en este trabajo.
Se ha profundizado en el análisis y definición de contenidos de todos los modelos digitales
necesarios para conseguir un modelo BIM federado de la carretera como han sido el
modelo digital del terreno -entendido este no solo como la definición habitual utilizada por
la disciplina de Topografía que es la de la superficie topográfica, sino como masa 3D con
los estratos geotécnicos y sus parámetros-, modelo de obra lineal, modelos de obras de
paso, y modelos de equipamiento viario.
Este conocimiento de los contenidos necesarios de los modelos digitales y de las
funcionalidades del propio programa de modelado Civil3D, ha permitido fijar una
propuesta de futura Guía de Uso para modelado BIM de infraestructuras civiles.
En la segunda parte del trabajo se ha investigado sobre el presente grado de
interoperabilidad de los modelos BIM de obras civiles, que en el estado actual de la
tecnología presenta carencias muy importantes que deben ser subsanadas urgentemente,
si se desea su implantación en los métodos de trabajo ordinarios de los ingenieros civiles.
Dicha carencia proviene de dos aspectos básicos a saber, uno por la definición actual del
esquema IFC (formato estándar para garantizar la interoperabilidad de los modelos BIM)
que aún no recoge entre sus clases todos los conceptos necesarios para poder estructurar
un modelos BIM que sea exportable al formato IFC; y otro por la gestión de la información
de construcción (datos de proyecto y de obra) que debe ser incorporada a los modelos
BIM civil, con la misma eficacia que ocurre actualmente con los modelos BIM de
edificación.
Por ello en el trabajo se ha profundizado en el conocimiento del estado actual del esquema
IFC y en especial en su estructura de conceptos y relaciones, para los dos estándares
actuales más demandados como son el IFC 2x3 y el IFC 4x1 (en el momento de redacción
del presente trabajo existe otro estándar IFC 4x3). Se han podido contrastar las carencias
de estos para la gestión de la información de los objetos de las obras de infraestructuras
civiles.
Como aportación a la comunidad de la ingeniería civil que está activa en la implantación
de la tecnología BIM tanto para la redacción de proyectos constructivos como para la
gestión de la obra, se ha desarrollado tres programas por el autor del trabajo (código fuente
en lenguaje Python) que permiten iniciar una propuesta de automatizar los procesos de
incorporación y/o extracción de datos de las propiedades asignadas a los objetos de los
modelos BIM civil. La necesaria prueba de validación del funcionamiento de dichos
programas, que permita garantizar su uso por los profesionales del sector AEC, ha sido
completamente satisfactorio, habiéndose realizado sobre modelos BIM de carreteras y de
edificación.
Palabras Clave:
BIM civil, IFC, Industry Foundation Classes, VDC, Property Set Automation, Ingeniería Civil,
Obra lineal, Civil Information Modelling, CIM, Python
ix
Abstract
This Bachelor’s Thesis is focused on the Building Information Modelling application to Linear
and Nodal Infraestructure, specially regarding those workflows related to construction
Information enrichment of Highway-BIM Models developed using common commercial
software.
The first part of the Bachelor’s thesis considers the which BIM elements are required in order
to fulfil proper information management, due to actual lack existing on nowadays existing
software – in particular regarding Civil3D, the one used for this study case modelling.
One particular aspect considered is the effective BIM Federated model division into several
parts- which refers not also to the Topography model but the Geotechnical 3D strata one -
where Soil Properties are included- the actual corridor model and highway and drainage
equipment as well.
This knowledge obtained during this research -and the software development associated-
derived into a WhiteBook future proposal for Civil Infraestructure BIM Models.
The second part of this work consists on the critical study of the -reduced- interoperability
exhibited by commercial programs according to civil BIM Models. These issue should be
corrected in order to ensure a proper workflow in Civil Engineering practice.
This lack is due to two basic aspects: on one hand, the nowadays IFC schema which not
considers basic classes actually present on Civil Engineering practice- and then, the object
classification derived is not properly defined. On the other hand, construction data
management is a time consuming task not properly resolved.
This Bachelors tesis develop a deep research on recent IFC schema- specially regarding
those standards well known- such as IFC 2X3 an FC 4X1 and IFC4x3 currently as candidate.
All of them present a non-proper construction data management workflow and issues are
detected.
As a contribution for Civil Engineering Community, three programs are developed -using
Python 3 as language- which allow Civil Engineers to include User Defined Properties related
to BIM Civil Models. Several validation test were held in order to approve the proper working
process of these piece of software – including both highways and Building models. All
validation tests ended up with a proper behaviours and a correct evalutation of results.
Keywords:
BIM civil, IFC, Industry Foundation Classes, VDC, Property Set Automation, Ingeniería Civil,
Obra lineal, Civil Information Modelling, CIM, Python
Índice
Agradecimientos vii
Resumen viii
Abstract x
Índice xi
Índice de Tablas xiv
Índice de Figuras xv
1 Objeto y alcance del documento 11
1.1 Alcance del Trabajo 11
1.2 Objetivos del trabajo 12
2 Aproximación a la metodología BIM 14
2.1 Trabajo colaborativo 14
2.2 Interoperabilidad 14
2.3 Visualización de la futura Realidad a construir 16
2.4 Nivel de Detalle (Level of Development) 17
2.5 Usos de BIM 18
3 Metodología desarollada 21
3.1 Modelado de una obra de carreteras construida 21
3.2 Estudio del estándar IFC 23
3.3 Desarrollo de los programas 23
3.4 Herramientas informáticas para utilizar 24
4 Revisión bibliográfica 26
4.1 Trabajos académicos 26
4.1.1 Modelos BIM de obras civiles 26
4.1.2 Otros modelos BIM 27
4.2 Artículos en Revistas Científicas 28
5 Modelado de la obra construida 31
5.1 Descripción del Proyecto de Construcción 31
5.2 Estudio inicial del modelado 32
5.3 Los Accesos Directos a Datos 33
5.4 Estrategia de modelado en C3D 34
6 El Estándar IFC 36
6.1 ¿Qué es el estándar IFC? 37
xi
6.2 Estructura básica del IFC 41
6.2.1 Entidad 41
6.2.2 Atributos 42
6.2.3 Las superclases en IFC 43
6.3 Mapeo de clases 47
6.4 Esquemas IFC utilizados 47
6.4.1 Esquema del estándar IFC 2x3 48
6.4.2 Esquema del estandar IFC 4x1 50
6.4.3 Diferencias entre esquemas IFC 54
6.4.4 Ultima versión candidata 56
6.5 El formato IFC para infraestructuras civiles 60
7 La información en el esquema IFC 63
7.1 Propiedades de la información 63
7.2 Los datos de los objetos 65
7.2.1 Proceso de exportación a formato IFC 65
7.2.2 Análisis del fichero IFC 67
7.2.3 La organización de los datos 67
7.3 Visión de la información 77
7.4 Las clasificaciones en IFC 80
7.4.1 Usos de las clasificaciones 81
7.4.2 Conceptos de Clasificación en IFC 82
8 Automatización de Procesos de Información 83
8.1 Etapa Inicial: Búsqueda de objeto 84
8.1.1 Diseño del algoritmo central (Asignación de Nombres) 85
8.1.2 Código Fuente de Programa1_Nombres.py 90
8.2 Etapa 2: Estrategia de lectura de propiedades 93
8.3 Etapa 3: Escritura de Datos 96
8.4 Etapa 4: Eliminación de Propiedades y/o valores 110
8.5 Test de Funcionamiento 111
8.5.1 Prueba 1 – Tramo de Apartadero Ferroviario del Puerto de Sevilla 111
8.5.2 Prueba 2 – Pequeño Edificio 117
8.5.3 Prueba 3 – Tramo parcial del modelo BIM de la Vte. de BEAS 121
8.5.4 Prueba 4 – Modelo BIM de la Vte. de BEAS completo 125
9 Conclusiones 129
10 Futuras Líneas de Investigación 130
11 Referencias 131
12 Anejos 134
12.1 ANEJO I - ESTRATEGIA DE MODELADO DE OBRAS DE CARRETERAS 134
12.1.1 Edición de los Accesos Directos a Datos 134
12.1.2 Modelo 3D en Civil 3D 136
12.1.3 Alineación 138
12.1.4 Perfil longitudinal de una alineación 141
12.1.5 Secciones Tipo 145
12.1.6 Obra Lineal 163
12.1.7 Modelado de Estribos en Obras de Paso 176
12.1.8 Modelado de Obras de Drenaje Transversal 181
12.1.9 Generación de Sólidos para la exportación de IFC 192
12.2 ANEJO II – INFORMACIÓN DE OBRA A INTRODUCIR EN EL MODELO 3D 210
12.3 ANEJO III – ARCHIVO IFC DEL MODELO BIM COMPLETO DE LA VTE. DE BEAS 213
xiii
ÍNDICE DE TABLAS
Tabla 1 - Fichero XLS de entrada de datos (elaboración propia) 94

Tabla 2 - Ficha de grupo (elaboración propia) 95
Tabla 3 - Ficha de tipo de objeto (elaboración propia) 95
Tabla 4 - Ficha de ejemplo (elaboración propia) 101
Tabla 5 - Coordenadas locales de la información en las fichas (elaboración propia) 101
Tabla 6 -Tabla de datos a añadir - Prueba 1 (Elaboración propia) 114
Tabla 7 - Fichas de propiedades del archivo de datos (Elaboración propia) 118
Tabla 8 - Ficha de propiedades (elaboración propia) 123
Tabla 9 - Resumen de la prueba 3 (elaboración propia) 125
Tabla 10 - Propiedades del modelo de la prueba 4 (elaboración propia) 126
Tabla 11 -Resumen de la prueba 4 de ENRIQUECIMIENTO de modelo BIM de carreteras (elaboración propia) 128
Tabla 12 - Estado Inicial del Modelado (elaboración propia) 138
Tabla 13 - Datos que la Dirección de Obra rquiere del Modelo BIM AsBuilt (elaboración propia) 210
Tabla 14 - Archivo de Datos (Elaboración Propia) 210
ÍNDICE DE FIGURAS
Ilustración 1 - Estudio de evacuacion la Estacion de Blas Infante con UNITY ENGINE (Fuente: Ing. Luis Castro) ___________________________________________ 16
Ilustración 2 - Especificacion de LOD (Fuente BIMFORUM) _______________________________________________________________________________________ 17
Ilustración 3 - Propuesta de LOD para infraestructuras civiles (fuente: MTHojgaard) _______________________________________________________________ 18
Ilustración 4 - Diagrama de Gantt. (fuente: elaboracion propia) __________________________________________________________________________________ 19
Ilustración 5 - Ventajas de la Planificación 4D (Fuente: TFM del ingeniero de caminos J.B. Bermejo) __________________________________________________ 20
Ilustración 6 - Flujo de Trabajo de un Modelo de Infraestructura de Carreras (Fuente: Tutor) _______________________________________________________ 22
Ilustración 7 - Flujo de Trabajo en el Estudio del IFC (elaboración propia) ________________________________________________________________________ 23
Ilustración 8 - Flujo de Trabajo de Programación de Algoritmo (elaboración propia) _______________________________________________________________ 24
Ilustración 9 - Mapa de Revistas Cientificas con los artículos sobre IFC (Fuente WoS) _____________________________________________________________ 29
Ilustración 10 – Hoja de Plano de Planta General del proyecto de construcción (elaboración propia) _________________________________________________ 32
Ilustración 11 - Esquema de EDC para Civil3D en carreteras (Fuente: Tutor) ______________________________________________________________________ 32
lustración 12 - Modelo 3D inicial del Enlace 2 (Fuente: Tutor) ___________________________________________________________________________________ 33
Ilustración 13 - Flujo de Trabajo de Modelado de carreteras con Civil3D (Fuente: Tutor) ____________________________________________________________ 35
Ilustración 14 - Versiones de los esquemas IFC (Fuente: BuildingSMART.org) ______________________________________________________________________ 36
Ilustración 15 - Modelo BIM de cámara (EMASESA) editado por visualizador BIMData.io (Fuente: Tutor) _______________________________________________ 38
Ilustración 16 - Encabezdo de un archivo IFC (elaboración propia) ______________________________________________________________________________ 40
Ilustración 17 - IFCdoor (vía BuildingSmart.org) _______________________________________________________________________________________________ 41
Ilustración 18 - Clases y tipos de IFC en REVIT (Fuente Autodesk)________________________________________________________________________________ 42
Ilustración 19 - Atributos de IFCDoor (vía BuildingSmart.org) ___________________________________________________________________________________ 42
Ilustración 20 - Atributos predeterminados de la clase ifcLoadBering (Fuente Autodesk)___________________________________________________________ 43
Ilustración 21 - Parámetros por defecto asignados en REVIT (Fuente Autodesk) ___________________________________________________________________ 43
Ilustración 22 - Parámetros predeterminados no incorporados por REVIYT para un muro _________________________________________________________ 43
Ilustración 23 - Atributos de IFCROOT (vía BuildingSmart.org) __________________________________________________________________________________ 44
Ilustración 24 - Herencia de IFCObjectDefinition (vía BuildingSmart.org) _________________________________________________________________________ 45
Ilustración 25 - Herencia de IFCObject (vía BuildingSmart.org) _________________________________________________________________________________ 45
Ilustración 26 - Herencia de IFCRelationship (vía BuildingSmart.org) ____________________________________________________________________________ 45
Ilustración 27 - Herencia de IFCPropertyDefinition (vía BuildingSmart.org) _______________________________________________________________________ 46
Ilustración 28 - Herencia de IFPropertySetDefinition (vía BuildingSmart.org) _____________________________________________________________________ 46
Ilustración 29 Herencia de IFCPropertyTemplateDefinition (vía BuildingSmart.org) ________________________________________________________________ 46
Ilustración 30 - Ejemplo de TABLA DE MAPEO DE IMPORTACION de parámetros IFC en REVIT (Fuente Autodesk) ________________________________________ 47
Ilustración 31 - Propuesta de agregación espacial de elementos para carreteras (Fuente Lee,S-H et alters) __________________________________________ 48
Ilustración 32 - Relaciones entre los elementos espaciales y elementos físicos (Fuente Lee, S-H et alters) ___________________________________________ 48
Ilustración 33 – Arquitectura IFC 2x3 (vía BuildingSmart.org) __________________________________________________________________________________ 49
Ilustración 34 - Esquema Completo IFC (elaboracióin propia) ___________________________________________________________________________________ 51
Ilustración 35 - Herencia de IFCObjetDefinition (Elaboracon propia) _____________________________________________________________________________ 52
Ilustración 36 - Herencia del IFCPropertyDefinition (Elaboración propia) ________________________________________________________________________ 53
Ilustración 37 - Herencia del IFCRelationsip (Elaboración propia) _______________________________________________________________________________ 53
Ilustración 38 - Esquemas del IFC (vía BuildingSmart.org) _____________________________________________________________________________________ 55
Ilustración 39 - Esquema de las vistas de modelo - MVD (Fuente Autodesk) ______________________________________________________________________ 55
Ilustración 40 - IFC Elemento (vía BuildingSmart.org) _________________________________________________________________________________________ 57
Ilustración 41 - Esquema 2x3 (vía BuildingSmart.org) _________________________________________________________________________________________ 57
Ilustración 42 - Esquema 4x1 (vía BuildingSmart.org)__________________________________________________________________________________________ 58
Ilustración 43 - IFCGeothecnicalElement (vía BuildingSmart.org) _______________________________________________________________________________ 59
Ilustración 44 IFCGeothecnicalAssembly (vía BuildingSmart.org)________________________________________________________________________________ 59
Ilustración 45 - IFCGeotechnicalStratum (vía BuildingSmart.org) _______________________________________________________________________________ 59
Ilustración 46 - IFCFacility (vía BuildingSmart.org)____________________________________________________________________________________________ 60
Ilustración 47 - Evolución esperada del formato IFC para infraestructuras (Fuente Sacyr) _________________________________________________________ 60
Ilustración 48 - Esquema conceptual del IFC 4x3 para carreteras (Fuente SACYR) _________________________________________________________________ 61
Ilustración 49 - Propiedades y entidades del ifcRoad (Fuente Sacyr) _____________________________________________________________________________ 61
Ilustración 50 - Propiedades y entidades del ifcPavement (Fuente SACYR) _______________________________________________________________________ 62
Ilustración 51 - Otras entidades del IFC 4x3 para carreteras (Fuente SACY) ______________________________________________________________________ 62
xv
Ilustración 52 - IFCPropertySet (vía BuildingSmart.org) _______________________________________________________________________________________ 64
Ilustración 53 - Gestióin de datos y objetos de IFC (elaboración propia) __________________________________________________________________________ 64
Ilustración 54 - Líneas de código del ifcPropertySet___________________________________________________________________________________________ 64
Ilustración 55 - Modelo de Infraestructura ferroviaria (Fuente: Elaboración propia) _______________________________________________________________ 65
Ilustración 56 - Exportar a IFC desde Civil 3D (elaborado por mi) _______________________________________________________________________________ 66
Ilustración 57 - Recursos a Exportar a IFC desde Civil 3D (elaborado por mi) _____________________________________________________________________ 66
Ilustración 58 - Nuevos parametros a Exportar desde Civil 3D (elaboración propia) _______________________________________________________________ 67
Ilustración 59 - Exportar Persona a IFC desde Civil 3D (elaborado propia) _______________________________________________________________________ 67
Ilustración 60 - Líneas de código de ifcProject (Elaboración propia) _____________________________________________________________________________ 69
Ilustración 61 - Líneas de código de la información general del proyecto (Elaboración propia) _______________________________________________________ 70
Ilustración 62 - Asignación en la exportación IFC (Elaboración propia) ___________________________________________________________________________ 72
Ilustración 63 - Líneas de código de la estructura espacial (Elaboración propia) __________________________________________________________________ 72
Ilustración 64 - Definición espacial (vía BuildingSmart.org) ____________________________________________________________________________________ 73
Ilustración 65 - Esquemas de pisos (vía BuildingSmart.org) ____________________________________________________________________________________ 73
Ilustración 66 - Propiedades de Pset_BuildingUse (Fuente: BuildingSmart) ______________________________________________________________________ 75
Ilustración 67 - Conjunto de Propiedades de Pset_BuildingUseAdjacent (vía BuildingSmart)_________________________________________________________ 76
Ilustración 68 - Modelo del Rail con usBIMviewer (fuente: elaboración propia)____________________________________________________________________ 78
Ilustración 69 - Clases del Objeto RAIL en us.BIMviewer (Elaboración propia) _____________________________________________________________________ 78
Ilustración 70 - Propiedades del Objeto _____________________________________________________________________________________________________ 79
Ilustración 71 - Atributos propios y heredados (Elaboración propia) _____________________________________________________________________________ 80
Ilustración 72 - Propiedades del Modelo _____________________________________________________________________________________________________ 80
Ilustración 73 - Nombre del Objeto según un visor de IFC (Fuente elaboración propia) _____________________________________________________________ 85
Ilustración 74 - Flujograma de Asignación de NOMBRES ________________________________________________________________________________________ 86
Ilustración 75 – Flujograma para la búsqueda de OBJETOS (elaboración propia) __________________________________________________________________ 87
Ilustración 76 – Flujograma de la función ID_IFC (elaboración propia) ___________________________________________________________________________ 89
Ilustración 77 – Código Fuente (elaboración propia)____________________________________________________________________________________________91
Ilustración 78 – Ejemplo de visualización de Datos (elaboración propia) _________________________________________________________________________ 94
Ilustración 79 - Flujograma para ENRIQUECIMIENTO DE PROPIEDADES (Elaboración propia) _________________________________________________________ 97
Ilustración 80 – Inicio de Ficha (elaboración propia) _________________________________________________________________________________________ 100
Ilustración 81 - Flujograma de la Función Lectura_Prop (Elaboración propia) ____________________________________________________________________ 102
Ilustración 82 - flujograma de la función P_set (elaboración propia) ___________________________________________________________________________ 103
Ilustración 83 - Esquema de propiedades en el IFC (elaboración propia) ________________________________________________________________________ 104
Ilustración 84 - Código fuente del Algoritmos de ESCRITURA DE PROPIEDADES (elaboración propia) _________________________________________________ 106
Ilustración 85 - Flujograma de Programa4_EliminarPSets (elaboración propia) ___________________________________________________________________ 110
Ilustración 86 - Código fuente del algoritmo central de este tercer programa (elaboración propia) __________________________________________________ 111
Ilustración 87 – Modelo de Infraestructuras Ferroviarias (Elaboración beca de prácticas en TeamBIM Civil S.L.)_______________________________________ 112
Ilustración 88 – Algoritmo de búsqueda de objetos ___________________________________________________________________________________________ 112
Ilustración 89 – Ventana emergente de inicio del PROGRAMA1_NOMBRE.PY (elaboración propia)_____________________________________________________ 113
Ilustración 90 - Lista de objetos ____________________________________________________________________________________________________________ 113
Ilustración 91 – Objetos del Modelo BIM ferroviario procesado por el algoritmo. (elaboración propia) ________________________________________________ 113
Ilustración 93 – Subprograma de Enriquecimiento de datos____________________________________________________________________________________ 114
Ilustración 93 – Ventana emergente (elaboración propia) _____________________________________________________________________________________ 115
Ilustración 94 - Fichero enriquecido (Fuente elaboración propia) _______________________________________________________________________________ 115
Ilustración 95 – Resumen de la prueba (elaboración propia) ___________________________________________________________________________________ 116
Ilustración 96 – Icono del algoritmo de Eliminación (elaboración propia) _________________________________________________________________________ 116
Ilustración 97 – Modelo BIM sin Propiedades (elaboración propia) ______________________________________________________________________________ 117
Ilustración 98 – Modelo de Edificación (Fuente: repositorio de la Universidad de Auckland) _________________________________________________________ 117
Ilustración 100 – Ventana emergente del primer programa (elaboración propia)__________________________________________________________________ 117
Ilustración 100 – Ejecución del segundo programa (elaboración propia) _________________________________________________________________________ 119
Ilustración 101 – Visualización en BimDATA.io y us.BIMviewer (elaboración propia) ________________________________________________________________ 120
Ilustración 102 – Resumen de la prueba (elaboración propia)___________________________________________________________________________________ 121
Ilustración 103 – Modelo BIM de un tramo de la Variante de Beas en formato IFC (Elaboración propia) _______________________________________________122
Ilustración 104 – Ejecución del Primer programa (elaboración propia) ___________________________________________________________________________122
Ilustración 105 – Ejecucción del Segundo programa (elaboración propia) _______________________________________________________________________ 123
Ilustración 106 – Comprobación de datos (elaboración propia) _________________________________________________________________________________124
Ilustración 107 Modelo Completo de la Variante de Beas (elaboración propia) _____________________________________________________________________125
Ilustración 108 – Ejecución del primer programa (elaboración propia)__________________________________________________________________________ 126
Ilustración 109 – Ejecución del segundo programa(elaboración propia) __________________________________________________________________________127
Ilustración 110 – Modelo sin propiedades (elaboración propia) __________________________________________________________________________________127
Ilustración 111 – Modelo con propiedades (elaboración propia) __________________________________________________________________________________127
Ilustración 112 – Comprobación del ENRIQUECIMIENTO del modelo con las propiedades de usuario (elaboración propia) ________________________________ 128
Ilustración 113 - Entorno del programa (elaboración propia) ___________________________________________________________________________________ 135
Ilustración 114 - Buscar y Reemplazar (elaboración propia) ____________________________________________________________________________________ 135
Ilustración 115 - Ventana de buscar y Reemplazar (elaboración propia) _________________________________________________________________________ 135
Ilustración 116 - Establecer Carpeta de Trabajo(elaboración propia) _____________________________________________________________________________136
Ilustración 117 - Flujo de Trabajo del Proyecto Piloto (elaboración propia) ________________________________________________________________________136
Ilustración 118 - Listado en planta (elaboración propia) ________________________________________________________________________________________138
Ilustración 119 - Alineaciones dibujadas en Civil 3D (elaboración propia) _________________________________________________________________________139
Ilustración 120 - Flujo de trabajo del Perfil longitudinal (elaboración propia) ______________________________________________________________________ 141
Ilustración 121 - Listado del Perfil y conversión a TXT (elaboración propia) _______________________________________________________________________ 142
Ilustración 122 - Crear perfil a partir de Archivo (CIvil 3D) _____________________________________________________________________________________ 143
Ilustración 123 - Crear perfil de Superficie (elaboración propia) ________________________________________________________________________________ 144
Ilustración 124- Crear Visualización de Perfil (elaboración propia) ______________________________________________________________________________ 144
Ilustración 125 - Sección Tipo del eje principal (proyecto original) ______________________________________________________________________________ 145
Ilustración 126 - Planta del Eje principal _____________________________________________________________________________________________________ 146
Ilustración 127 - Diseño en Subassembly Composser (elaboración propia) _______________________________________________________________________ 146
Ilustración 128 - Algoritmo diseñado (elaboración propia) _____________________________________________________________________________________ 148
Ilustración 129 – Parámetros (elaboración propia) ___________________________________________________________________________________________ 149
Ilustración 130 - Adaptación a desmonte y terraplén (elaboración propia) _______________________________________________________________________ 149
Ilustración 131 – Condición (elaboración propia) ______________________________________________________________________________________________150
Ilustración 132 - Detalle de la sección (elaboración propia) ____________________________________________________________________________________150
Ilustración 133 - Código de Punto (Autodesk)_________________________________________________________________________________________________ 151
Ilustración 134 - Código de Enlace (vía Autodesk) _____________________________________________________________________________________________ 152
Ilustración 135 - Código de Forma __________________________________________________________________________________________________________ 152
Ilustración 136 - Códigos en SAC (elaboración propia)_________________________________________________________________________________________ 152
Ilustración 137 - Carril de Cambio de Velocidad (Google MAPS) _________________________________________________________________________________ 153
Ilustración 138 – Offset (elaboración propia) ________________________________________________________________________________________________ 153
Ilustración 139 - Algoritmo del SAC (elaboración Propia) ______________________________________________________________________________________ 154
Ilustración 140 - Sección en SAC (elaboración propia) _________________________________________________________________________________________ 155
Ilustración 141 - Sección sin carril de cambio de velocidad (elaboración propia) ___________________________________________________________________ 155
Ilustración 142 – Condición (elaboración propia)______________________________________________________________________________________________ 155
Ilustración 143 - Inicio Rama Positiva (elaboración propia) _____________________________________________________________________________________156
Ilustración 144 - Algoritmo de la Sección Central (elaboración propia) ___________________________________________________________________________156
Ilustración 145 Inicio de Algoritmo de Diseño del Ramal (elaboración propia) _____________________________________________________________________156
Ilustración 146 - Condicional para la ampliación de la cimentación (elaboración propia) ____________________________________________________________ 157
Ilustración 147 - Sección tipo de los Ramales ________________________________________________________________________________________________ 157
Ilustración 148 - Sección tipo en SAC (elaboración propia) ____________________________________________________________________________________158
Ilustración 149 - Algoritmo de SAC (elaboración propia) _______________________________________________________________________________________159
Ilustración 150 - Ramal Bidireccional (proyecto original) ______________________________________________________________________________________160
Ilustración 151 - Sección en SAC (elaboración propia) _________________________________________________________________________________________160
Ilustración 152 – Sección tipo glorieta (proyecto original) _____________________________________________________________________________________ 161
Ilustración 153 - Sección en SAC (elaboración propia) _________________________________________________________________________________________ 161
Ilustración 154 - Sección tipo Camino Agrícola (proyecto original) ______________________________________________________________________________ 162
Ilustración 155 - Algoritmo general (elaboración propia) ______________________________________________________________________________________ 162
Ilustración 156 - Lado derecho de la calzada (elaboración propia) ______________________________________________________________________________ 162
Ilustración 157 - Algoritmo para el diseño de cunetas (elaboración propia) _______________________________________________________________________163
Ilustración 158 - Herramiento Obra Lineal (elaboración propia)_________________________________________________________________________________ 164
Ilustración 159 - Ventana de Asignación de Alineación, Perfil y Ensamblaje (elaboración propia) _____________________________________________________ 164
Ilustración 160 - Tramos de Obra Lineal (elaboración propia) __________________________________________________________________________________165
Ilustración 161 - Objetivos de Obra Lineal ____________________________________________________________________________________________________165
Ilustración 162 - Obra Lineal Eje 62 (elaboración propia)_______________________________________________________________________________________166
Ilustración 163 - Eje 73 (elaboración propia) _________________________________________________________________________________________________166
Ilustración 164 - Eje 1 (elaboración propia) ___________________________________________________________________________________________________ 167
Ilustración 165 – Ejes 20, 129 y 61 (elaboración propia) ________________________________________________________________________________________ 170
Ilustración 166 - Eje 21 (elaboración propia) _________________________________________________________________________________________________ 171
Ilustración 167 - Eje 64 (elaboración propia) _________________________________________________________________________________________________ 171
Ilustración 168 - Eje 124 (elaboración propia) ________________________________________________________________________________________________ 172
Ilustración 169 - Propiedades de Obra Lineal (Civil 3D) ________________________________________________________________________________________ 173
Ilustración 170 Superficie de Obra Lineal (elaboración propia) __________________________________________________________________________________ 173
Ilustración 171 - Puntos para Superficie (elaboración propia) ___________________________________________________________________________________ 174
Ilustración 174 - Líneas Características a añadir (elaboración propia) ___________________________________________________________________________ 174
Ilustración 175 - Detalle de SAC (elaboración propia) __________________________________________________________________________________________ 175
xvii
Ilustración 176 - Superficie Obra Lineal 27 (elaboración propia)_________________________________________________________________________________176
Ilustración 177 - Estribos en un Viaducto en el Proyecto Original (Proyecto Original) _______________________________________________________________ 177
Ilustración 178 - Ensamblaje Completo (elaboración propia) ____________________________________________________________________________________ 177
Ilustración 179 - Ensamblaje vacío (elaboración propia)________________________________________________________________________________________178
Ilustración 180 - Dividir Región (elaboración propia) __________________________________________________________________________________________178
Ilustración 181 - Forma en Planta (elaboración propia) _________________________________________________________________________________________179
Ilustración 182 - Elevar a Superficie (elaboración propia) ______________________________________________________________________________________179
Ilustración 183 - Crear líneas características a partir de Objetos (elaboración propia)____________________________________________________________ 180
Ilustración 184 - Crear Explanación (elaboración propia)______________________________________________________________________________________ 180
Ilustración 185 – Modelización (elaboración propia) ___________________________________________________________________________________________ 181
Ilustración 186 - Desembocadura tipo Caño (via Google) ______________________________________________________________________________________ 182
Ilustración 187 - Planta de una ODT (elaboración propia) ______________________________________________________________________________________ 183
Ilustración 188 - Crear Líneas Características a partir de Objetos (elaboración propia) ___________________________________________________________ 183
Ilustración 189 - Crear Grupo de Explanación (elaboración propia) _____________________________________________________________________________ 184
Ilustración 190 - Herramientas de Creación de Explanación (elaboración propia) _________________________________________________________________ 185
Ilustración 191 - Lado de Explanación (elaboración propia)_____________________________________________________________________________________ 186
Ilustración 192 - Añadir Contorno (elaboración propia) _______________________________________________________________________________________ 188
Ilustración 193 - Resultado Final (elaboración propia) ________________________________________________________________________________________ 189
Ilustración 194 - Obra de Drenaje Transversal en SAC (elaboración propia)_______________________________________________________________________ 191
Ilustración 195 - Obra lineal del Colector (elaboración propia) _________________________________________________________________________________ 192
Ilustración 196 - Secciones trasversales (elaboración propia) _________________________________________________________________________________ 193
Ilustración 197 Extraer Sólidos de Obra Lineal (elaboración propia) ____________________________________________________________________________ 193
Ilustración 198 - Solidos a extraer (elaboración propia) _______________________________________________________________________________________194
Ilustración 199 - Datos de Propiedades (elaboración propia) __________________________________________________________________________________ 195
Ilustración 200 Sólido (elaboración propia) _________________________________________________________________________________________________ 196
Ilustración 201 Propiedades añadidas por el usuario (elaboración propia) ________________________________________________________________________197
Ilustración 202 - Superficies Planas (elaboración propia) _____________________________________________________________________________________ 198
Ilustración 203 - Sólido de Comparación (elaboración propia) _________________________________________________________________________________ 199
Ilustración 204 - Extraer de Superficie (elaboración propia) __________________________________________________________________________________ 199
Ilustración 205 - Extraer Sólido desde Superficie (elaboración propia) _________________________________________________________________________ 200
Ilustración 206 - Sólidos Completos (elaboración propia) _____________________________________________________________________________________ 201
Ilustración 207 - Modelo Completo (elaboración propia) ______________________________________________________________________________________ 202
1 OBJETO Y ALCANCE DEL DOCUMENTO
Este documento titulado DESARROLLO DE UN ALGORITMO PARA LA INCORPORACIÓN
MASIVA DE DATOS A LOS MODELOS BIM DE OBRAS CIVILES se encuentra dentro de la
normativa asociada al Trabajo de Fin de Grado de la Escuela Técnica Superior de
Ingeniería, centro perteneciente a la Universidad de Sevilla para la obtención de los
créditos ECTS de la asignatura “Trabajo Fin de Grado” de la titulación de Ingeniería Civil, por
parte del alumno D. Ángel Díaz Murillo, que ha cursado en dicha escuela los estudios
correspondientes a dicha titulación, y tiene como objetivo último mostrar una parte de la
capacidades profesionales que dichos estudios universitarios le han permitido adquirir.
Este Trabajo de Fin de Grado está dentro de la línea de investigación en materia de
Construcción Digital aplicada a la Ingeniería Civil que está desarrollando el Departamento
de CONSTRUCCIONES ARQUITECTÓNICAS I, siendo el tutor de este trabajo, el ingeniero de
caminos, canales y puertos D. Blas González González, profesor del Departamento y que
imparte la docencia de la asignatura de Construcciones Civiles dentro de la titulación de
Ingeniería Civil, e investigador en la aplicación de la tecnología BIM en materia de
construcciones civiles.
1.1 Alcance del Trabajo

El objetivo básico de este trabajo es investigar en una parte concreta de la tecnología del
modelado de información de construcción (Building Information Modeling1) como es la de
la gestión de la información con la que hay que dotar a los modelos BIM si se quiere que
estos tengan una verdadera utilidad en la gestión de activos (información para y de la
obra) y no se queden en unas simples presentaciones de la geometría 3D de los proyectos,
ya validas de por sí.
La construcción digital, de la cual la tecnología BIM es la más recientemente incorporada
al sector profesional AEC – architecture, engeenering and construction-, está en continuo
avance y permite una evolución no vista hasta ahora tano de la tecnología de redacción
de proyectos de construcción como de la gestión. de la propia construcción (obra); que
en España se está incorporando con lentitud a la docencia universitaria como se deduce
de los estudios bien de una forma natural en los estudios de arquitectura y de ingeniería de
edificación como señalan los trabajos de Jurado et alters [1], y el estudio sobre la
implantación de la metodología BIM en la titulación de Arquitectura [2] y los de estudios de
[4] sobre herramientas BIM como innovación en la educación superior de estudios de
ingeniería civil y arquitectura, o los señalados en [5], y más lentamente a los estudios de la
ingeniería civil como se pueden analizar en [6] y [7].
Estas nuevas tecnologías de construcción digital (Modelos BIM, Realidad Virtual, Realidad
Aumentada, Inteligencia Artificial aplicada a los datos de obra, etc.) están permitiendo la
transición digital de la ingeniería civil desde el actual nivel de tecnología CAD hasta un nivel
superior de excelencia en la gestión de la información de la construcción, en la cual la
automatización de la incorporación de datos va a ser decisiva; y esto va a constituir un
hecho diferencial de como los profesionales ejerzan sus trabajos ordinarios. Aquí hemos
1BIM es el acrónimo de esta técnica que se estableció definitivamente por el profesor Eastman en su libro [48] sobre BIM que significo la
consolidación de esta tecnología en la arquitectura
11
DESARROLLO DE UN ALGORITMO PARA LA INCORPORACIÓN MASIVA
12 DE DATOS A LOS MODELOS BIM DE OBRAS CIVILES
encontrado una de las razones para abordar este trabajo de investigación.

Por otro lado la contratación pública de proyectos y obras en España, tras el impulso
realizado por el Ministerio de Fomento en 2.016 constituyendo la Comisión es.BIM con
trabajos sobre BIM en infraestructuras lineales [8], la posterior modificación2 de la legislación
de contratos del sector público [9] y posteriormente en 2.019 formalizando una Comisión
Interministerial para implantación BIM en las administraciones públicas españolas, para
cumplir con la Directiva 2004/18/CE del Parlamento Europeo y del Consejo, de 31 de marzo
de 2004, hace necesario la adopción en el campo del proyecto y la ejecución de obras
de ingeniería de la tecnología BIM; y como señala [10] además ya se ha identificado los
procesos de licitación en los que es posible aplicar la tecnología de construcción digital
mediante el uso de modelado BIM
Ante estas necesidades actuales para el profesional de la ingeniería civil, el Grupo BIM Civil
del Departamento de Construcciones Arquitectónicas I de la Universidad de Sevilla, se ha
fijado entre sus objetivos implantar la enseñanza de la construcción digital en las asignaturas
de la cual es responsable de su docencia, y fruto de esa línea de trabajo se enmarca la
investigación acometida en el desarrollo de este trabajo fin de grado.
1.2 Objetivos del trabajo

Este trabajo tiene dos objetivos principales: (i) completar3 la estrategia de modelado BIM
para infraestructuras líneas -como es el caso de un proyecto de carreteras- desarrollado
por el ingeniero civil J. Monar, y (ii) desarrollar la automatización de la incorporación masiva
de información en los modelos BIM, según los flujos de información actuales de los
proyectos de construcción.
Para conseguir el primer objetivo nos basaremos en una obra ya ejecutada4 de la cual
elaboraremos un modelo BIM, cuyo uso sea la base del Proyecto de Liquidación de la obra
(As Built), es decir, construir su gemelo digital continuando los trabajos realizados por el
ingeniero J. Monar. La ejecución de este gemelo digital permitirá adquirir los conocimientos
sobre la estrategia más optima del modelado 3D de carreteras (y por tanto de cualquier
tipo de obra lineal) y como implementar la información de construcción en él, para que
dicho modelo digital alcance la categoría de un modelo BIM.
En este trabajo se pretende también analizar el estado actual de la funcionalidad de una
de las herramientas5 que permite aplicar la tecnología BIM para obras de infraestructuras
lineales, en la elaboración de un modelo BIM As Built. Esto nos permitirá determinar el flujo
de trabajo óptimo para la elaboración de un modelo digital de carreteras para así poder
analizar las mejoras a introducir en la metodología propuesta por la actual normativa6 sobre
BIM.
El segundo objetivo y el más importante, será identificar los procesos de edición de la
información dentro del modelo BIM, pero bajo la condición ser realizado en ficheros que
garanticen la interoperabilidad (OpenBIM). Para posteriormente identificar los flujos de
2 Que en su diposicion adicional 15, en su apartado 6 señala “Para contratos públicos de obras, de concesión de obras, de servicios y concursos de
proyectos, y en contratos mixtos que combinen elementos de los mismos, los órganos de contratación podrán exigir el uso de herramientas electrónicas
específicas, tales como herramientas de modelado digital de la información de la construcción (BIM) o herramientas similares. En esos casos,
ofrecerán medios de acceso alternativos según lo dispuesto en el apartado 7 de la presente Disposición adicional hasta el momento en que dichas herramientas
estén generalmente disponibles para los operadores económicos.”
3 Complentado el avance de los trabajos desarrollados en [1] J por el ingeniero civil D. Javier Monar
4 Obra de mejora de la carretera nacional N-435 a su paso por Beas (Huelva)
5 Autodesk CIVIL 3 D verison 2.019.
6 UNE-EN ISO 19650
12
trabajo que nos permita avanzar en la automatización de la incorporación de la
información de construcción de forma masiva a los modelos BIM -inicialmente a los de
infraestructuras civiles y posteriormente a los de otras disciplinas-, y por tanto disminuir el
tiempo dedicado a esta actividad de enriquecer los modelos BIM en formatos nativos, y
garantizar una mayor calidad del trabajo, tanto del técnico proyectista como del técnico
de obra, en el campo de la ingeniería civil, siguiendo los trabajos iniciados entre otros
autores de referencia, por Jiménez Abós, P et alter en [11].
13
2 APROXIMACIÓN A LA METODOLOGÍA BIM

A continuación, y con objeto de recopilar algunos conceptos sobre esta tecnología de
construcción digital vamos a exponer determinadas informaciones útiles para una mejor
compresión del trabajo y el contexto en el que se realiza.
El sector de la construcción, en concreto la elaboración de proyectos de construcción, ha
encontrado en los últimos años la oportunidad de un avance tecnológico. A finales del siglo
XX el sector se vio sacudido por la introducción de herramientas de diseño asistido por
ordenador (CAD). Años después, el modelado 3D ha sido la conclusión de este avance
inicial en la técnica de proyectar.
Detrás de estos avances, en segundo plano, surgió en los inicios del siglo XXI una nueva
metodología que de una vez por todas va a permitir que la computación y el tratamiento
automático de la información de construcción pueda formar parte de metodología de la
elaboración de un proyecto de construcción, y que se basa en los siguientes principios
fijados por varios autores y entre ellos Eastman, C. [12].
2.1 Trabajo colaborativo

La metodología BIM tiene como uno de sus paradigmas que se debe garantizar una
transferencia de archivos independiente de las herramientas informáticas con las que se
haya generado, así como el medio físico en el que se soporte. Es decir, las herramientas
utilizadas para esta metodología permiten la gestión de archivos en la nube como parte
de un entorno colaborativo de trabajo (Entorno Común de Datos -ECD cuyo acrónimo en
inglés es conocido como CDE-). El ECD es un entorno tecnológico (software -SW- y hardware
-HW-) en el que todos los ingenieros que trabajen el proyecto podrán ir realizando
actividades de modificación del diseño mediante la carga y actualización de los datos del
proyecto cuando se está modelando -es lo que se ha denominado entorno colaborativo-.
La materialización de este ECD tiene un sinfín de posibilidades, puede ser desde un disco
duro físico al que todos los equipos de la oficina estén conectados hasta un servicio de
nube o un servidor tipo NAS. Incluso, un ordenador personal puede servir de host del EDC.
2.2 Interoperabilidad
En la redacción del proyecto de construcción es muy importante para conseguir la máxima
eficiencia en su redacción (máxima eficacia al menor coste) y la máxima garantía de
calidad del proceso, que todos los equipos de trabajo estén coordinados para que el
desarrollo del proyecto sea lo más coherente posible.
Además, tenemos la dificultad de que para cada estudio específico se necesita un
programa informático acorde con dicha especificidad (diseño, calculo estructural, cálculo
hidráulico, planificación, costes y presupuesto, etc.), por lo que un archivo que cumpla la
estandarización de la estructura de la información de la construcción, que permita la
conexión entre distintos programas es vital.
Como define Jiménez Adbós, P en [11], “La metodología BIM, por definición, implica la colaboración
de los diferentes agentes para la creación y gestión del modelo BIM. Para poder llevar a cabo esto de forma
14
óptima, es necesario que exista lo que se denomina Interoperabilidad”
De aquí que garantizar la interoperabilidad7 (openBIM) entre los programas de modelado
y de las otras disciplinas es esencial, ya que permite a cada equipo de trabajo, realizar su
labor en el programa más útil para su tarea permitiendo la conexión con el resto de los
programas, y además como señala Jiménez Adbos en la referencia citada nada nos
garantiza que el formato nativo del software utilizado en fase de diseño, pueda ser usado
en las fases de construcción, operación y mantenimiento, o bien pueda ser consultado y/o
editado en el futuro, y para ello debe recordarse que la vida útil legal de nuestras
construcciones es como mínimo de 50 años.
Además de la etapa de redacción de proyecto, se debe facilitar la labor en la obra de la
información del proyecto. Si la administración pública (cliente por excelencia en España
para las infraestructuras civiles) tiene bien implementado la tecnología BIM, el Director de
Obra y su equipo así como el Jefe de Obra y su equipo de producción, se debe pasar de
la tecnología CAD (planos) a la gestión con modelos 3D (certificación de obra /
seguimiento de la planificación) con su terminal personal (Tablet) y para ello necesitara de
programas ligeros de visionado 3D e introducción de datos en obra de diferentes tipos
desde textos a fotos.
Por tanto, la metodología BIM aplicada a la Ingeniería Civil, debe permitir la
heterogeneidad de programas para desarrollar el proyecto, lo cual por ahora es un
objetivo por alcanzar y si bien en los proyectos de arquitectura, esto casi es una realizada
al alcance de la mano, aunque aún falto un tramo del camino, en los proyectos de
ingeniería civil se está en el inicio de dicho camino prometedor, pero siendo realistas
estamos en el tramo medio de dicho camino.
Los modelos digitales que se elaboren con la tecnología informática a usar bajo la
denominada metodología BIM deben ser abiertos, es decir accesible a todos, esto debe
permite que se puedan manejar con cualquier software (que se adhiera a los estándares
fijados para BIM y que son desarrollado por [13]). La entidad buildingSMART permite a todo
el sector AEC mejorar el intercambio de información a lo largo del ciclo de vida del
proyecto o activo, dado que el fijar un estándar para la organización de la información de
la construcción y así romper los silos de información aislados que las herramientas de diseño
actuales producen, los usuarios finales pueden colaborar y cooperar independientemente
de la aplicación de software que estén utilizando. El núcleo técnico de buildingSMART se
basa en Industry Foundation Classes (IFC), que obtuvo la certificación ISO en 20138.
IFC representa la estandarización de los datos de la industria de la construcción, que
adema es un estándar internacional abierto ( ISO 16739-1: 2018 ) y promueve las
capacidades de ser utilizables los archivos de los modelos BIM en una amplia gama de
dispositivos de hardware, plataformas de software e interfaces para muchos casos de uso
diferentes.
Esto permite la gran potencialidad del uso de la metodología BIM, que es la de hacer
realidad todo el ciclo de vida de la información de la obra. Mediante la interoperabilidad
del soporte físico (archivo digital), el modelo puede ir adquiriendo valor añadido desde el
modelado de la geometría 3D, hasta la planificación/programación de obra, el
presupuesto de la obra, las especificaciones para el mantenimiento etc.
7 Como definición de interoperabilidad en España, podemos tener la establecida en el GLOSARIO DE TERMINOS del R.D. 4/2.010 por el que
se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Adminsitracion Electronica: ”la interoperabilidad es la capacidad de los
sistemas de información, y de los procedimientos a los que éstos dan soporte, de compartir datos y posibilitar el intercambio de información y conocimiento
entre ellos”
8 Mediante la ISO 16739 y posteriormente adoptado como Euronorma y por tanto vigente en España desde 2.017 como UNE-EN ISO
16739:2016
15
No obstante como señalan los trabajos de Wu, J [14] no es raro ver usos indebidos de las
entidades IFC durante la creación de los modelos BIM. Dichos usos indebidos impiden una
automatización exitosa de las tareas compatibles con BIM porque la clasificación
incorrecta de objetos en BIM puede tener consecuencias negativas significativas en las
aplicaciones posteriores debido a la información semántica incorrecta proporcionada.
2.3 Visualización de la futura Realidad a construir

La excelencia de calidad que da esta tecnología a los proyectos de Ingeniería Civil y que
hasta ahora no ha sido posible, es la modelización digital tridimensional del concepto del
proyecto y al mismo tiempo ser dicho modelo un contenedor de información de
construcción. Es decir, hasta ahora la forma en la que el cliente y el usuario en los procesos
de información pública previstos en las legislaciones sectoriales como la ambiental, veía el
resultado del proyecto era mediante planos de la representación 2D de las infraestructuras
lineales de transporte y demás infraestructuras civiles (hidráulicas, portuarias, etc.) y su
presentación virtual en 3D mediante infografía estáticas y sin contenido de información.
Ahora se puede realizar modelos que desarrollados en un motor gráfico como son los
utilizados en la industria del videojuego, se le puede enseñar al cliente un recorrido virtual
por la obra que se ha de construir y que permite una compresión del proyecto, así como
una verificación mucho más eficiente, bien del cumplimiento de la normativa o de las
simulaciones constructivas previas entre otras posibilidades. Esto implementado con la
realidad virtual, puede dar una visión previa del estado de la obra antes de que esta esté
finalizada. En la industria del videojuego se realizan modelados de infraestructura de una
forma usual, por lo que implementar flujos de trabajos para que los modelos de los
proyectos adquieran una imagen más realista es una práctica que debería ser norma en
toda empresa consultora e incluso constructora.
Un ejemplo de este recorrido virtual por el gemelo digital de una obra puede ser el
presentado por el ingeniero informático D. Luis Castro en las III JORNADAS DE BIM CIVIL EN
ANDALUCIA, sobre la realización de un caso real9 de modelo BIM As Built de la Estación Blas
Infante de la Línea 1 de Metro de Sevilla. Este modelo, se caracteriza por ser un modelo
transitable virtual, que si se implementa en un sistema de realidad virtual puede dar una
experiencia muy similar a la que tienen los usuarios del Metro y podría ayudar en los
preventivos estudios de evacuación en caso de accidentes o incendios.
Ilustración 1 - Estudio de evacuación la Estación de Blas Infante con UNITY ENGINE (Fuente: Ing. Luis Castro)
9 realizado por la empresa consultora TEAM BIM CIVIL S.L.
16
2.4 Nivel de Detalle (Level of Development)
LOD son las siglas un término que, aunque se interpreta muchas veces como dos conceptos
que parecen similares (Detalle geométrico / Detalle de Información), no pueden
confundirse, y el término correcto para aplicar debería ser el de desarrollo geométrico. Esta
última acepción refleja literalmente el nivel de desarrollo referido al desarrollo del modelo
y de la información gráfica que este debe tener.
Este concepto se fijó el American Institute de Architects inicialmente y ha ido ampliándose
mediante sucesivas publicaciones publicadas por BIMFORUM en cuya versión de 2.017 [15],
de forma detallada y grafica nos presenta seis niveles de desarrollo, denominados10
LOD100, LOD200, LOD300, LOD350, LOD400 y LOD500, según la clasificación/codificación
de elementos constructivos Uniformat / Omniclass
Ilustración 2 - Especificación de LOD (Fuente BIMFORUM)
A continuación, se detallan los que se consideran necesarios para las infraestructuras

lineales
1) LOD 100: Es el nivel básico. Es el mínimo desarrollo de un elemento dentro de un
proyecto. En este nivel el elemento no tiene por qué ser más que una representación
de este. Es un concepto de lo que después se puede desarrollar. Se suele usar para
hacer un estudio aproximado del presupuesto y de la programación
2) LOD 200: En este nivel el elemento tiene una definición gráfica aproximada (por
ejemplo, la ubicación, y las dimensiones a grandes rasgos) Además, al tener una
geometría (y esta ser bastante aproximada) ya puede contar con información
intrínseca que pueda ser útil en el proyecto. Por lo que puede ser utilizado para el
presupuesto, programación y para su encaje aproximado con otros objetos
3) LOD 300: Este nivel debe de definir con exactitud el modelo gráfico. Para ello debe
de tener una descripción realista de sus dimensiones y la ubicación dentro del
proyecto (incluida la relación con otros elementos de este). Dentro de este nivel, el
arquitecto J. A. Madrid (GAMÉZ CHOCLÁN et al., 2015a) habla de un nivel LOD 350:
“Equivalente al nivel LOD 300 pero incluyendo la detección de interferencias entre distintos elementos.
Es propio de proyectos complejos desarrollados independientemente por disciplinas u otra
desagregación de proyecto específica.” Este LOD 350 incluye conexiones y montajes
entre diferentes elementos
4) LOD 400: Hereda todo el desarrollo de los anteriores niveles además de dar una
10 Sus definiciones detalladas pueden contrastarse en la pagian 13 de dicho documento en su capitulo FUNDAMENTAL LOD DEFINITIONS
17
descripción visual (también mediante la información que contiene) de tal forma que
puede ser construido a partir de él.
No obstante este concepto está en evolución como se ha comentado en el trabajo de J.
A. Madrid en su propuesta [16] de adaptación a España; o bien una propuesta de la
administración danesa [17] muy reciente del año 2.020, que es de las pocas referencias
que trata los LOD para infraestructuras civiles
Ilustración 3 - Propuesta de LOD para infraestructuras civiles (fuente: MTHojgaard)
El nivel LOD que se fije para nuestro modelo de infraestructuras civiles, requerirá dos tipos de
acciones diferentes. La más básica relacionada con el nivel de detalle geométrico a
desarrollar y la otra relacionada con el nivel de información no grafica a incorporar; por ello
es necesario estudiar los actuales flujos de trabajo que están implementados en los
programas de modelado, para mejorar y ampliar la capacidad de introducir información
de construcción en los modelos con procesos automatizados, que garanticen alcanzar un
LOD alto con un mínimo esfuerzo.
2.5 Usos de BIM

Vamos a referirnos a los usos BIM a utilizar en la ingeniería civil, existiendo alguno más de los
expuestos a continuación
Definición espacial de la obra (Dimensión BIM 3D)
Este es el uso de la metodología BIM más utilizado en la actualidad. Nace de incluir datos
en contenedores de información dentro de modelos tridimensionales. Esto da como
resultado unos entregables y un modelo en el que, además de la información gráfica se
encuentra la información analítica añadida.
Planificación de Obra (Dimensión BIM 4D)
Como define el ingeniero de caminos J. B. Bermejo en su Trabajo de Fin de Máster [18] “Es
el resultado de añadir la variable tiempo al modelo BIM 3D. Permite controlar la dinámica
del proyecto, realizar simulaciones de las diferentes fases de la ejecución de la obra o
diseñar el plan de ejecución y compartirlo con todos los oficios, empresas y demás agentes
intervinientes en el proceso.”
18
Hay dos conceptos clásicos en la redacción de un proyecto. La programación y
planificación de actividades. La planificación consiste en la identificación y ordenación de
las actividades a realizar para llegar al objetivo establecido en el proyecto, analizando las
relaciones entre actividades y su importancia. La programación consiste en el
establecimiento de esta actividad en un tiempo concreto, dotando a las actividades de
fecha de inicio, final y por lo tanto duración. La herramienta más común para la
programación es el diagrama de Gantt (también es muy usado el método de Pert). Este
diagrama, presenta un gráfico en el que se reflejan las actividades a realizar a lo largo del
tiempo de obra
Ilustración 4 - Diagrama de Gantt. (fuente: elaboración propia)
Con la entrada de la tecnología BIM, esta forma de programar y planificar ha sido

mejorada en todos los sentidos, es decir, al darle un cuarto eje al modelo 3D permite ver su
evolución durante el tiempo. Asociar un modelo 3D a un espacio temporal permite hacer
una “simulación” del proceso de construcción. Es decir, simular las actividades, con su
duración y su relación entre ellas para poder ver si la programación es coherente
resolviendo los conflictos espaciales y de movilidad de los equipos de maquinaria que de
otra forma solo una gran y contrastada experiencia del equipo de ingeniería de
construcción puede vislumbrar.
Además, permite la colaboración dentro de la elaboración del modelo BIM 4D entre todos
los equipos de producción de la empresa y sobre todo una validación de las posibles
alternativas al proceso de construcción decidido. Un resumen de sus ventajas se muestra
en la ilustración siguiente.
19
Ilustración 5 - Ventajas de la Planificación 4D (Fuente: TFM del ingeniero de caminos J.B. Bermejo)
Para poder hacer una simulación de construcción (con el modelado 3D de la obra, es

decir, el gemelo digital) se deben utilizar programas que permitan realizar una planificación
y programación de obra enlazado al modelo 3D. Hay varias herramientas BIM que se
pueden utilizar como son: PowertProject. Navisworks, Synchro PRO, Vico Office, etc.
Una vez definido este concepto, se puede suponer otra ventaja que conlleva el uso de BIM.
BIM permite que el ingeniero que está en obra gane en comodidad. Un gemelo digital
cargado de información puede tener varios apartados destinados a la dirección de obra.
Con el uso del modelo y de la interacción de este con un 4º eje (el temporal) permite que,
tanto el director de obra como el jefe de obra, sepan en qué estado debería estar el
proyecto en cualquier fecha. Además, permite hacer la certificación y consultar el modelo
sin la necesidad de trabajar con papel.
Control económico de la obra (Dimensión BIM 5D)
Esta nueva dimensión permite establecer una conexión entre los presupuestos del proyecto
y el modelo 3D. Para ello, los programas encargados de realizar presupuestos relacionan
diferentes partidas o Unidades de Obra, con los elementos tridimensionales (piezas) del
modelo digital para obtener una medición más verificable y por tanto más fiable.
Esto provoca una mejora en cuanto a calidad de los presupuestos, ya que, aunque siguen
necesitando una gran experiencia para estimar los precios de las partidas, la medición es
cuasiautomática.
Gestión de Activos (Dimensión BIM 7D)
En esta dimensión se encuentran todas las actividades relacionadas con la gestión de la
obra durante su vida útil, así como los procesos para su mantenimiento.
20
3 METODOLOGÍA DESARROLLADA
Para la realización de este Trabajo de Fin de Grado y en base a los objetivos fijados para su
desarrollo, se han seguido una serie de fases para alcanzar los mismos, y que a continuación
se describen.
1. Realizar una REVISION BIBLIOGRAFICA sobre aquellos aspectos que permitiesen
alcanzar un conocimiento del estado del arte actual sobre:
a. Estrategias de modelado BIM de infraestructuras civiles
b. Estructura de información de un modelo BIM de infraestructuras civiles, pero
en formatos interoperables, que no depende de formatos nativos de las
herramientas BIM comerciales
c. Métodos para incorporar la información de construcción
2. Fijar la ESTRATEGIA DE MODELADO DIGITAL de un proyecto constructivo de una obra
lineal ejecutada11 de forma que se pueda:
a. Establecer los modelos digitales necesarios para definir el modelo BIM As Built,
en base a un estudio de las necesidades de la gestión de la información de
la construcción en su explotación.
b. Realizar la ejecución del modelado de las obras realizadas, en base a la
información obtenida por parte de las empresas colaboradoras.
c. Elaborar el modelo digital 3D de la carretera, mediante la generación de
algunos12 de los elementos solidos que la componen que entre otros son los
terraplenes, los desmontes, las obras de drenaje y las obras de paso
3. Establecer una INFORMACION DE CONSTRUCCIÓN a incorporar, que a juicio del
equipo de dirección de obra sea representativa de las potencialidades que un
modelo BIM As Built requeriría.
4. Analizar la ESTRUCTURA DE INFORMACION DEL MODELO BIM EN FORMATO IFC, que
permita comprender su funcionamiento, para poder automatizar el flujo de trabajo
de la incorporación masiva de datos de obra al modelo BIM que garantice la
calidad de la incorporación de información eliminando los errores humanos del
proceso de introducción de datos en el modelo BIM.
5. Desarrollar ALGORITMOS PARA INTRODUCION MASIVA DE DATOS en el modelo BIM
en formato IFC, realizando:
a. Las pruebas de funcionamiento de dicho desarrollo informático con varios
casos
b. Estimando el rendimiento de este.
3.1 Modelado de una obra de carreteras construida

El desarrollo completo de un modelo BIM de infraestructuras de carreteras se ha realizado
11que en este caso es de la Variante de Beas perteneciente a la Red de Carreteras del Estado en la provinvia de Huelva.
12 Debido a la extensión acotada en esfuerzo y tiempo que tiene un trabajo de este tipo, no ha sido posible la modelizacion de todos los
elementos que componen la carretera incluido todo su equipamiento viario como es la señalización, el balizamiento, la integración ambiental
y los elementos del dominio publico viario.
21
mediante la conversión de un proyecto CAD de carreteras, (utilizando los entregables del

proyecto) mediante una herramienta de diseño de carreteras que permite la generación
de un modelo 3D en el que se establecerá una estructura13 de información de
construcción, evolucionando dicho modelo a un verdadero modelo BIM en el cual está la
estructura de información, pero no tendrá los datos necesarios de la obra.
Para el desarrollo del modelado de una infraestructura de carreteras se va a seguir el
siguiente flujo de trabajo (Ver Ilustración 6), con objeto de completar los trabajos iniciados
por J. Monar y B. Gonzalez en [19].
Se establece los siguientes modelos digitales:
1. MODELO DIGITAL DEL TERRENO, que debe contemplar al menos las siguientes
superficies:
a. Superficie Topográfica
b. Superficies de los estratos geológicos
2. MODELO FEDERADO DE OBRA LINEAL, que debe incluir:
a. los modelos de obras lineales de los diferentes ejes que componen la obra.
En nuestro caso el tronco principal y varios ejes secundarios
b. el drenaje longitudinal (cunetas) incorporado en las secciones tipo
parametrizables (secciones que denominamos inteligentes, dado que deben
3. MODELOS DE OBRAS DE DRENAJE TRANVERSAL
Ilustración 6 - Flujo de Trabajo de un Modelo de Infraestructura de Carreras (Fuente: Tutor)
13En el caso de la herramienta utilizada que será el programa CIVIL 3D 2020 de la empresa Autodesk, así como en el formato estándar IFC a
dicha estructura de información se la denomina PROPIERTIES SET.
22
3.2 Estudio del estándar IFC
Después de tener el modelo BIM completo, es necesario estudiar el formato IFC en sus
diferentes versiones que conviven actualmente. El primer paso es analizar los distintos
esquemas y sus características y como los programas modeladores exportan toda la
información al formato IFC.
Ilustración 7 - Flujo de Trabajo en el Estudio del IFC (elaboración propia)
Este estudio será el que me permita analizar en que contenedores de información se

encuentran las propiedades (datos) y como se puede automatizar todo el proceso de
incorporación y/o extracción de datos.
3.3 Desarrollo de los programas

Una vez que se haya definido la información que hay que añadir a la que ya contengan
los elementos del modelo BIM, modelo que se ha realizado con un programa de modelado,
hay que desarrollar un algoritmo que en base a los flujos de trabajos establecidos para
añadir información a los modelos digitales
Para el desarrollo del algoritmo principal se procederá a realizar diferentes algoritmos de
cada una de las etapas del flujo de trabajo (subalgoritmos) que permita entender que es
lo que ocurre en cada fase del proceso y controlar los posibles errores, para su depuración
Definida cual es la información de construcción (datos de los parámetros de los elementos
BIM) como se ha comentado más arriba, se editara la misma por el usuario, en un fichero
de datos -fichero en el que el usuario introduje los valores de las propiedades, y por tanto el
formato de dicho fichero de datos debe estar en un estándar cómodo para el usuario
como son los formatos XLS o CSV-, el algoritmo debe incorporar los valores de los parámetros
a los elementos del modelo digital; la incorporación de dicha información se realizara al
archivo del modelo BIM en formato IFC.
La traducción del algoritmo a un lenguaje de programación debe de ser un proceso
sencillo, para lo que se ha elegido un lenguaje de programación actual como es Python
(Ver Ilustración 8). La elección de Python ha sido porque es un lenguaje de programación
interpretado cuya filosofía hace hincapié en la legibilidad de su código; y se trata de un
23
lenguaje de programación multiparadigma, ya que soporta orientación a objetos,

programación imperativa y, en menor medida, programación funcional. Es un lenguaje
interpretado, dinámico y multiplataforma. Es administrado por la Python Software
Foundation. Posee una licencia de código abierto, denominada Python Software
Foundation License, que permite cumplir con los objetivos de OpenBIM y OpenSource al ser
este un trabajo académico de investigación.
Ilustración 8 - Flujo de Trabajo de Programación de Algoritmo (elaboración propia)
Cuando el algoritmo esté completo, se hará test de funcionamiento mediante la ejecución

de los programas desarrollados con varios modelos BIM de distinta tipología (infraestructuras
civiles y edificación) para ver si cumple las expectativas establecidas en los objetivos fijados
para el Trabajo del Fin de Grado. Las conclusiones de los resultados de las pruebas
realizadas se mostrarán para demostrar la validez del software desarrollado
3.4 Herramientas informáticas para utilizar

Para desarrollar las fases de modelado en el trabajo, se ha requerido el uso de varias
herramientas informáticos como han sido:
• Herramienta de Modelado Civil 3D (C3D). Software de diseño y modelado 3D
aplicado al campo de la Ingeniería Civil. Este programa dispone de todas las
herramientas para asegurar que podemos aplicar la metodología BIM como nos fija
la normativa actual (interoperabilidad): Exportación/Importación de IFC, gestión del
entorno común de datos, configuración de la información aplicada al modelo etc.
• Herramienta de Modelado de Secciones Tipo SubAssembly Composer (SAC).
Software de programación orientada a objetos, que permite la parametrización de
la sección transversal de una obra lineal, a modo de las familias en REVIT, pero
programable y no modelando geométricamente la sección tipo.
• Herramientas de Visores de modelos BIM, como
o BimVision: Este programa es un visor de modelos en formato IFC. Esto permitirá
realizar controles de calidad al modelo elaborado, tanto a la geometría
como de la información
o usBIMviewer: Este software es otro visor de IFC. En este caso es un visor que
permite editar el archivo IFC, incluso, importar modelos 3D en formato nativo
y exportarlo como modelo IFC.
• Herramientas de programación Dynamo: Es un software que permite la
programación visual para modelos BIM paramétricos
Para desarrollar la formulación del algoritmo se ha utilizado como se ha justificado más
arriba, el lenguaje de programación PYTHON, en el cual se desarrollarán varios
24
programas, en una versión inicial14 con las funcionalidades mínimas para un entorno de
operación básico para la verificación de su funcionamiento y en el contexto de un
trabajo de investigación como es el ámbito de este Trabajo Fin de Grado.
De todos los lenguajes de propagación, se ha elegido Python por las siguientes razones:
a. Es unos de los lenguajes más usados en el mundo
b. Es un lenguaje muy cómodo para personas recién iniciadas en la programación
como es el caso de los ingenieros civiles que aplican tecnología BIM
c. Desde la versión Civil 3D 2020 este programa tiene una herramienta de
programación visual desarrollado por Autodesk llamado Dynamo. Esta
programación visual está acotada por Autodesk exceptuando los nodos del
algoritmo, que pueden ser modificados con algoritmos creados con Python. Por lo
que se puede llegar a implementar este trabajo dentro del programa Civil 3D 2020
d. Existen iniciativas similares de traducciones del formato IFC a un formato escrito con
Python, como IFCOpenShell. Esta iniciativa ayuda a la edición de la geometría del
formato. Por lo que entendía que este trabajo podría ser una ampliación de esa
iniciativa
Pero en contra, tiene que no es un lenguaje de programación con el que se haya
desarrollado ninguno de los programas modeladores. Pero se quiere hacer énfasis en que
no importa realmente el lenguaje de programación ya que los algoritmos se pueden
traducir en un futuro al cualquier lenguaje.
14El desarrollo complerto de la herramienta ADM_DATA_IFC exigirá la escritura de un código de programa mucho mas amplio de forma
que el entorno con el usurario sea de fácil y universal uso.
25
4 REVISIÓN BIBLIOGRÁFICA
En este capítulo se procede a realizar una revisión bibliográfica sobre los objetivos
principales del trabajo (pág. 19):
i. completar la estrategia de modelado BIM para infraestructuras líneas -como es el
caso de un proyecto de carreteras-
ii. desarrollar la automatización de la incorporación masiva de información en los
modelos BIM, según los flujos de información actuales de los proyectos de
construcción.
Para ello se procedió a una revisión bibliográfica en las siguientes tres fuentes:
a) Trabajos académicos que tratasen sobre el modelado digital de infraestructuras
civiles, en los repositorios de las universidades españolas de libre distribución
b) Artículos de investigación, sobre los aspectos de la incorporación de información a
los modelos digitales de construcción, bajo estándar de formatos interoperables, es
decir sobre el formato IFC.
c) Bibliografía de referencia, que se puede consultar de la Biblioteca de la Universidad
de Sevilla.
4.1 Trabajos académicos

Una vez analizados los trabajos académicos localizados por el ingeniero M. Benavente en
[20], se ha completado dicha buscada con otros trabajos académicos del tipo Trabajos Fin
de Grado, Trabajos Fin de Máster y las Tesis Doctorales, ya no solo dentro de la Universidad
de Sevilla que nos permitan ampliar el panorama de las líneas de investigación que se están
desarrollando actualmente, y que versaran sobre los dos aspectos señalados en los
objetivos del trabajo.
4.1.1 Modelos BIM de obras civiles
1) Vera Galindo, C. and González González, B. (2018) ‘Trabajo Fin de Máster MODELO
BIM 5D COSTES’. Available at:
http://bibing.us.es/proyectos/abreproy/71274/fichero/TFM-1274-VERA.pdf.[21]
2) Ferreiro Morales, M. A. and Gonzalez Gonzalez, B. (2018) Aplicacion de la
Metodologia BIM a un proyecto de Construccion de Corredor de transporte para un
complejo industrial. Modleos BIM 3D OBRA LINEAL.[22]
3) Juan Bautista Bermejo and Blas González González (2018) ‘Aplicación De La
Metodología Bim Al Proyecto De Construcción De Un Corredor De Transporte Para
Un Complejo Industrial - Modelo Bim 4D Planificación’. Available at:
http://bibing.us.es/proyectos/abreproy/71273/fichero/TFM-1273-BERMEJO.pdf.[23]
4) Redondo Mariin, A. and González González, B. (2019) Aplicación de la Metodología
BIM 4D a un Proyecto de Infraestructura Nodal. Available at:
https://idus.us.es/handle/11441/94127 (Accessed: 31 August 2020).[24]
5) Monar González, J. and González González, B. (2020) Modelado BIM para Proyecto
AS-BUILT de Infraestructuras Lineales. Available at:
26
6) Benavente Lepe, M. M. and González González, B. (2019) Diseño de modelos BIM
para infraestructuras civiles con DYNAMO. Available at:
7) Martin, A. y González, B. - Trabajo de Fin de Grado Ingeniería Civil Aplicación de la
Metodología BIM 4D a un Proyecto de Infraestructura Nodal
8) Desarrollo de una aplicación de Visualización de Carreteras [25]
9) Estudio sobre BIM integrado. Análisis del caso práctico de la ampliación de la tercera
compuerta en la esclusa de Beatriz y ensanchamiento del canal de Lek
(Holanda)[26]
10) Análisis de la gestión de proyectos mediante la metodología Building Information
Modeling (BIM). Aplicación al proyecto de ampliación del puerto deportivo Pobla
Marina (Puebla de Farnals, Valencia)[27]
11) Elaboración efectiva del modelo de información de construcción de una nave
industrial trabajando bajo plataforma BIM[28]
12) García Lobato, Francisco José - Levantamiento BIM del estado actual del Parking
CC. Los Arcos
13) Hidalgo Sánchez, Fco Manuel - INTEROPERABILIDAD ENTRE SIG Y BIM APLICADA AL
PATRIMONIO ARQUITECTÓNICO. Exploración de posibilidades mediante la
realización de un modelo digitalizado de la Antigua Iglesia de Santa Lucía y posterior
análisis
14) Martín Rodríguez, Antonio - Predicción de deterioro y Conservación Preventiva
mediante sistemas BIM de la muralla del Recinto I del Real Alcázar de Sevilla (Casas
7 y 8 del Patio de Banderas)
15) Galeote Escalante, María del Mar - VEHÍCULOS AUTOMÓVILES MEDIANTE LA
PLATAFORMA BIM-REVIT MEMORIA DESCRIPTIVA
16) Gómez Rodríguez, Matías - Integración de procesos BIM en levantamiento de
edificios existentes: edificio de laboratorios de la E.T.S.I.E., Campus Universitario Reina
Mercedes, Sevilla
17) Carmona, Jorge Mateo y Domingo, Aranda - ANTEPROYECTO DEL TRAMO DE
CARRETERA N-232 A SU PASO POR HÍJAR (TERUEL). MODELADO BIM[29]
18) Rosell Esteve, Miguel Angel - Proyecto de construcción de un depósito de regulación
en el TM de San Juan de Alicante (Alicante)[30]
19) Marí Guaita, Carles - Aplicación de la metodología Building Information Modeling
(BIM) para el estudio de viabilidad de la ampliación de la autopista M13 entre
Hillerød y Copenhague en Dinamarca.
20) Przygocka, Monika - Design project of the structure of a residential building in the city
of Castellón street Paseo Ribalta n•1
21) Duque Carmona, Simón David - Análisis y aplicación de la metodología BIM en una
obra de carácter civil en el Reino Unido[31]
4.1.2 Otros modelos BIM
1) Bravo Sánchez, Alberto - Establecimiento de los criterios de diseño de zonas

hospitalarias para pacientes oncológicos. Aplicación, medición y
27
evaluación.
2) García Bautista, María del Rocío - El Bim Manager: incorporación a la ley de
ordenación de la edificación. Aplicación a un caso práctico
3) Gonçalves da Rocha Jimenez, Manoel - Guía visual de implementación BIM
para arquitectos en España
4) Uribe Davies, Juan Luis - Revit Samples. El BIM como herramienta proyectual[7]
5) Haba Bartolomé, Juan José - Técnicas BIM aplicadas a la reconstrucción
virtual del yacimiento arqueológico Mleiha 5 (E.A.U.)
6) Moreno Sánchez, Pablo - Técnicas BIM aplicadas a la reconstrucción 3D del
yacimiento arqueológico MLEIHA-6.
7) Jurado Egea, José - Aprendizaje integrado en arquitectura con modelos
virtuales: implementación de metodología BIM en la docencia universitaria
8) Díez Dancausa, Héctor - Aplicación de la metodología BIM en el diseño de
Centros de Procesamiento de Datos
9) González Sato, Javier - Evaluación y análisis de la tecnología Building
Information Modeling (BIM)
10) Pezo Manya, Marquinho Andre del - Protocolo para el diseño de un plan de
ejecución de Historic Building Information Modelling (HBIM) en la planificación
de la gestión de la infraestructura del parque arqueológico de
Sacsayhuamán en Cusco, Perú
11) Dushi, Denada - Gestión de procesos para la integración de Building
Information Modeling (BIM) e ingeniería de sistemas en proyectos de
construcción.
12) Mogena Sánchez, Roberto - Diseño de un protocolo para la definición LOD
en HBIM aplicado a la Capilla de Santa Bárbara de San Juan del hospital en
la ciudad de Valencia.
4.2 Artículos en Revistas Científicas

La búsqueda de artículos de investigación sobre el formato IFC se ha realizado en
la plataforma de recursos científicos Web of Science15, y los resultados iniciales
agrupados por revistas científicas, fueron son los mostrados en la siguiente
ilustración.
facilitada bajo la licencia de la Universidad de Sevilla que tiene de la Fundacion Española para la Ciencia y la Tecnología (FECYT) del
15
Ministerio de Ciencia e Investigación
28
Ilustración 9 - Mapa de Revistas Científicas con los artículos sobre IFC (Fuente WoS)
De las relaciones obtenidas de tan extensa producción científica, se ha realizado una

selección de los que pudieran realizar aportaciones útiles al presente trabajo de
investigación. De aquellos que no han podido ser obtenidos completos, se ha procedido a
su localización en la plataforma SciencDirect de ELSEVIER con la licencia de la
Universidad de Sevilla.
Se relacionan a continuación, los más interesantes por su aportación a este trabajo.
1. Ghazal, Mai Monir - Application of knowledge discovery in database (KDD)
techniques in cost overrun of construction projects [32]
2. Lee, S. H. - IFC extension for road structures and digital modeling [33]
3. Zhang, Lu - Automated IFC-based building information modelling and
extraction for supporting value analysis of buildings [34]
4. Kwon, Tae Ho - Design of railway track model with three-dimensional
alignment based on extended industry foundation classes [39]
5. Vieira, Renato - Supporting building automation systems in BIM/IFC: reviewing
the existing information gap [35]
6. Nawari, Nawari O. - Generalized Adaptive Framework for Computerizing the
Building Design Review Process [36]
7. Deng, Xueyuan - Generic language for partial model extraction from an IFC
model based on selection set [37]
8. Du, Xiaozhi - IFC File Content Compression Based on Reference Relationships
[38]
Otros artículos de investigación que se consideran interesantes por aportaciones colaterales
al tema central de este trabajo son los siguientes:
9. Sun, Zheng; Xie, Jiangtao ; Zhang, Yingying; Cao, Yongkang - As-built BIM for
a fifteenth-century Chinese brick structure at various LoDs
10. Matarneh, Sandra - BIM-based facilities information: streamlining the
29
information exchange process

11. Ninić, Jelena - Integrated parametric multi-level information and numerical
modelling of mechanised tunnelling projects
12. Missbauer, Hubert - Order release planning by iterative simulation and linear
programming: Theoretical foundation and analysis of its shortcomings
13. Fano, David - New Models of Building: The Business of Technology
14. Zhu, Junxiang - Automatically processing IFC clipping representation for BIM
and GIS integration at the process level
15. Kouhestani, Sobhan - IFC-based process mining for design authoring
16. Isailović, Dušan - Bridge damage: Detection, IFC-based semantic enrichment
and visualization
17. Akbarieh, Arghavan - BIM-based end-of-lifecycle decision making and digital
deconstruction: Literature review
18. Hor, A-H. - BIM-GIS integrated geospatial information model using semantic
web and rdf graphs
19. Davila Delgado, Juan Manuel - BIM data model requirements for asset
monitoring and the circular economy
20. Krijnen, Thomas - An efficient binary storage format for IFC building models
using HDF5 hierarchical data format
21. Doukari, Omar - Automatic generation of building information models from
digitized plans
22. Ramaji, Issa J. - IFC-Based BIM-to-BEM Model Transformation
23. Lee, Jin Kook - Generation of Entity-Based Integrated Model View Definition
Modules for the Development of New BIM Data Exchange Standards
24. Boje, Calin - Semantics for linking data from 4D BIM to digital collaborative
support
25. Lu, Qiuchen - Semi-automatic geometric digital twinning for existing buildings
based on images and CAD drawings
26. De Gaetani, Carlo Iapige - Interoperability analyses of BIM platforms for
construction management
27. Theißen, Sebastian - Using open BIM and IFC to enable a comprehensive
consideration of building services within a whole-building LCA
30
5 MODELADO DE LA OBRA CONSTRUIDA
En este capítulo se va a detallar tanto la estrategia de modelado como los propios flujos de
trabajo de elaboración del modelo federado que servirá como modelo BIM As Built, y que
tiene sus precedentes en el trabajo del ingeniero civil J. Monar [19].
Todo el proceso que es tan importante para fijar bien el flujo de trabajo en lo referente a los
datos compartidos se describe con detalle en el epígrafe de este trabajo denominado
ANEJO I - ESTRATEGIA DE MODELADO DE OBRAS DE CARRETERAS.
Con los contenidos desarrollados en este Anejo I, se cumple con el primer objetivo fijado en
este trabajo de investigación, que dada lo prolijo y denso de dichos contenidos se ha
optado por ubicarlo en el primer anejo del trabajo. Es una propuesta de una futura Guía de
Usos BIM para Modelado de Carreteras.
A continuación, se expone solo una parte de las cuestiones desarrolladas para el modelado
de la obra construida, que son las consideradas básicas para una mejor comprensión del
proceso de modelado, y que son:
• Estudio inicial del proyecto
• El trabajo colaborativo, mediante la técnica de “Accesos a Datos” del programa
C3D
• La estrategia de modelado en C3D
Para modelar la obra de carretera, se han utilizado los softwares16 CIVIL 3D (para la obra
lineal) y REVIT (para las obras puntuales); además, también se ha usado el programa
SUBASSEMBLY COMPOSER y el editor de ACCESOS DIRECTOS A DATOS.
5.1 Descripción del Proyecto de Construcción

Para poder cumplir con el primer objetivo fijado para el trabajo, se ha procedido a modelar
una parte del proyecto de construcción de la nueva variante de la N-435 a su paso por
Beas (Huelva). Este proyecto consiste en una actualización de la traza de la carretera,
situado entre los enlaces de Beas Sur/Trigueros Norte y Triguero Sur. En este tramo se han
construido 25 estructuras, 9 Pasos superiores, 7 inferiores, 6 viaductos y 3 estructuras de
enlace (Ver Ilustración 10)
Esta obra supone una mejora en la movilidad y de la seguridad vial en una de las carreteras
de la red principal del país y que supone un punto de conexión importante entre
Extremadura (Badajoz) y Andalucía Occidental (Huelva).
Para la realización del modelo 3D de la carretera no se ha elegido el tramo completo del
proyecto constructivo, sino un tramo de cinco kilómetros de los 16 kilómetros
(aproximadamente) de que consta todo el proyecto de construcción pues el tiempo
excede de los límites de un trabajo fin de grado, en concreto desde el P.K.6+500 hasta el
P.K. 11+500.
16 Todos estos programas son de la casa Autodesk y se han utilizado con la licencia educativa que tiene la Universidad de Sevilla
31
Ilustración 10 – Hoja de Plano de Planta General del proyecto de construcción (elaboración propia)
Se ha elegido ese tramo por ser de una longitud adecuada al estudio y por qué en él se
encuentra todas las tipologías de elementos viarios que se pueden encontrar también en
otros tramos de la obra, lo cual nos sirve como caso de estudio del problema.
5.2 Estudio inicial del modelado

Para empezar a modelar y ante la ausencia de un Plan de Ejecución BIM, cuestión que fija
la norma actual UNE 19650 [40], la primera actividad fue la de familiarizarse con la parte del
proyecto de construcción original y los planos de construcción facilitados por la asistencia
técnica a la dirección de obra17, ya que el modelo BIM As Built debe de ser un gemelo
digital de la obra ya construida.
Una vez que se conoce en qué estado está el proyecto hay que decidir con todo el equipo
de trabajo cual va a ser el entorno común de datos y la forma de guardar y de compartir
la información (Ver Ilustración 11). Aunque del proyecto se encargue solo una persona, hay
que facilitar el acceso del resto de personas integrantes del equipo para que la entrada de
un nuevo miembro al equipo de trabajo sea eficiente y así cumplir con los principios
metodológicos que he expuesto en el capítulo 2 del trabajo.
Ilustración 11 - Esquema de EDC para Civil3D en carreteras (Fuente: Tutor)
17 Gracias a la colaboración del ingeniero de caminos, canles y puertos D. Andres Gonzalez Fabre de la empresa URCI CONSULTORES, SL.
32
Como EDC se ha determinado que el directorio de los archivos de trabajo sea una carpeta
para localizar en el equipo de sobremesa y en concreto en la partición D del disco duro de
la máquina. El motivo de esta anomalía como EDC estaba justificada para facilitar el
trabajo en casa del posible equipo de especialistas que intervendrían en un verdadero
proyecto desarrollado mediante las herramientas informáticas descritas en el epígrafe 2.1
del trabajo.
Esta decisión se demostró muy acertada pues luego fue esencial durante el confinamiento
de la pandemia del Covid-19. Es decir, si se diseñan todas las rutas de guardado y de
accesos directos a datos en el disco local (partición D) de la máquina de trabajo (dirección
usual de los discos externos), el trabajo en el proyecto fuera de los equipos de la oficina
podrá seguirse, siempre que se guarde en este disco externo.
lustración 12 - Modelo 3D inicial del Enlace 2 (Fuente: Tutor)
Este sistema de salvado no permite el trabajo colaborativo; que debe basarse en una
infraestructura física del EDC que tenga una arquitectura del tipo NAS o servidores de datos.
Con este flujo de trabajo se debe utilizar programas de sincronización de archivos18 de
forma que garanticen la integridad de la copia de seguridad en el EDC. De esta forma, los
archivos guardados en la ruta del disco D se sincronizarán con otra ruta de destino, que
será el servidor NAS de la empresa.
5.3 Los Accesos Directos a Datos

El modelado BIM tiene unos de sus pilares en el trabajo colaborativo, por lo que es necesario
tener un EDC accesible desde el software de modelado. En ese sentido las actuales
versiones de la herramienta C3D, no tienen una buena solución para dicho trabajo
colaborativo, como si lo tiene la herramienta REVIT para trabajar con EDC basados en
18En nuestro caso se ha utilizado la herramienta FreeFileSync, de distribución gratuita. Cualquier cambio en los archivos que se haga fuera
de la oficina (teletrabajo sin una buena conectividad de internet -aun no están desarrolladas las redes 5G en España) se sincronizará los
archivos realizados fuera de la oficina con el equipo personal de la oficina al conectar el necesario disco duro externo (portable) o bien se haya
restituido la conexión remota con el equipo personal de la oficina.Mediante esta sincronización indirecta, que permite el trabajo colaborativo
dentro de la oficina y el posible trabajo fuera de la oficina sin conexión de internet a tiempo total.
33
servidores o NAS. En cambio, dentro del programa tiene unas herramientas que permite un
grado de trabajo colaborativo por disciplinas, pero mediante un flujo de trabajo específico
adaptado al programa, y estas son los ACCESOS DIRTECTOS A DATOS, que suponen una
evolución superior de lo que son las referencias externas del programa AutoCAD (padre del
programa de C3D).Hay que tener en cuenta que al ser una herramienta BIM y trabajar con
elementos tridimensionales paramétricos (contenedores de información) estos necesitan un
tratamiento específico al de una referencia externa.
El Acceso Directo a Datos es una herramienta que tiene AutoCAD C3D para crear
referencias a objetos inteligentes que no se encuentran en el dibujo actual. Esto permite el
trabajo colaborativo19 o incluso conseguir modelos complejos sin aumentar el tamaño del
archivo que supondría modelarlo todo en un solo archivo. En este sentido indicar que el
tamaño máximo de archivo está limitado a 200 Mb, por la UNE 19.650 [40].
5.4 Estrategia de modelado en C3D

Para hacer un modelo 3D de carreteras en Civil 3D hay que seguir un flujo de trabajo
definido para la ingeniería de carreteras y no por otras disciplinas20 que, aunque tengan un
alto conocimiento de la metodología BIM, no tienen ni los conocimientos ni las habilidades
específicos para desarrollar un proyecto de modelado de carreteras.
El esquema básico de proceso que está basado en el esquema presentado en la Ilustración
13 es el siguiente:
• Hay que definir los ejes de los viales: la alineación, el perfil longitudinal y el perfil
transversal. Para ello, el proyecto original nos ha dado todos los datos necesarios.
• Todo modelo 3D debe de tener una cartografía digital21 (una superficie en Civil 3D)
que unida a la información geotecnia permitirá realizar el Modelo BIM del Terreno (el
ámbito de incorporar la estratigrafía geotecnia ha quedado fuera de este trabajo)
para poder realizar sobre este modelo todos los flujos de trabajo.
• Diseño de los Ensamblajes de cada sección tipo (utilizando los facilitados por el
propio programa C3D, o bien diseñándolos con el programa SAC), que permitirá el
modelado de las Obras Lineales de cada Eje del proyecto
• Federación de todas las Obras Líneas, para poder definir el Modelo 3D de la
carretera.
• Extracción de solidos del Modelo 3D anterior, para generar el modelo BIM de
Carretera, al que se añadirán los Conjuntos de Propiedades (Property Set) y las
propiedades individuales.
• Exportación del modelo BIM de la cartera al formato IFC, para enriquecerlos con
todos los datos que se vayan produciendo en obra, mediante su incorporación a las
propiedades diseñadas en proyecto, o requeridas por la Dirección de Obra.
19 Una disciplina como puede ser la de TOPOGRAFIA puede estar actualizando el levantamiento topográfico durante la ejecución de la obra,
por mayor precisión y detalle de las zonas de trabajo; y el equipo de OFICINA TECNICA puede seguir su trabajo de medición o de
introducción de informacacion de construcción de forma paralela.
20 El hecho que determinados profesionales de Arquitectura u otras ingenierías estén realizando las funciones de BIM Manger en proyectos
de infraesturuas civiles como carreteras, líneas ferroviarias, metros, puertos, lado aire de aeropuertos, etc, como se esta observando en la
licitación publica de redacción de proyectos por parte de las admisnitraciones publicas como ha sido recientemente el Puerto de Sevilla, que
exigía como BIM Manaher de un apartadeero ferroviario a realizar con tecnología BIM a un arquitecto, explica la confusión del panorama
actual.
21 En este caso, la cartografía ha sido suministrada por la empresa que realizó el proyecto original. En el caso de que no se disponga de un
levantamiento topográfico se puede disponer de una cartografía en los organismos oficiales (como las Comunidades Autónomas).
34
Ilustración 13 - Flujo de Trabajo de Modelado de carreteras con Civil3D (Fuente: Tutor)
35
6 EL ESTÁNDAR IFC
Cuando en el año 1.995 Autodesk lanza la idea de tener un formato de intercambio entre
herramientas BIM, se inicia un proceso que culmino en la creación de la asociación
BuildingSMART; y que establece el formato Industry Foundation Classes (IFC), que desde el
año 2.005 tiene ya una norma ISO que comenzó a fijar el estándar; que desde el
lanzamiento de IFC4, el formato IFC cumple con una norma ISO reconocida (ISO 16739:2013
y que actualmente su última formulación -la versión IFC 4.0.2.1- es la norma ISO 16739-1:2018.
IFC (Industry Foundation Classes) es un estándar abierto utilizado en el diseño y la
construcción de edificaciones para permitir la interoperabilidad entre programas
dedicados al modelado BIM. Es decir, permite el intercambio de modelos de datos de
construcción entre programas de distintas casas comerciales sin perder información del
modelo; de aquí que no nació ni está enfocado a las infraestructuras civiles, y este proceso
de adaptarse a este tipo de proyectos se está haciendo actualmente a partir del estándar
IFC 4. [41]
Ilustración 14 - Versiones de los esquemas IFC (Fuente: BuildingSMART.org)
El estándar IFC para los modelos de edificación es el estándar IFC 2x3 normalizado el año
2.005 con la ISO / PAS 16.739:2005, cuestión no resuelta aun en el campo de la ingeniería
civil, entre otras razones por las siguientes.
Si analizamos los datos de un proyecto de Ingeniería Civil, por ejemplo, un proyecto de
carreteras, hay muchos datos del estudio, como en el resto de otras disciplinas como
36
Arquitectura, pero que son específicos de este tipo de proyectos (Levantamiento
Topográfico / Información Geotécnica de las estratigrafías atravesadas / Información de
Impacto Ambiental / Estructuras de obras de paso y de drenaje / Trazado / etc.) y que no
han sido recogidos en las versiones iniciales del estándar IFC como es en la versión 2x3.
6.1 ¿Qué es el estándar IFC?

Es un estándar para los archivos informáticos de los modelos BIM que contiene información
geométrica e información de datos, así como un conjunto de relaciones entre ellos.
A diferencia como el resto de los archivos nativos de los modeladores como REVIT o
ALLPLAN, es la característica esencial es que es un formato abierto, es decir, todos sus
contenidos (líneas de código) están a disposición del usuario para poder realizar cambios
o incluso desarrollar software para trabajar con él; pero que no es editable por los
programas actuales de modelado, y no parece que lo vaya a ser así, y por tanto no se va
a modelar en este formato. Por ahora representa una visión estática del modelo BIM en un
momento dado y su misión es ser exportado/importado por otros programas.
El formato IFC está caracterizado por:
i. Ser un formato orientado a objetos, basado en definiciones de clases que
representan a objetos (elementos constructivos, espacios, propiedades, formas,
relaciones, etc.)
ii. Poder contener información generada a lo largo de un ciclo de vida que se defina
para esta mediante su enriquecimiento continuo.
iii. Estar estructurado en capas (submodelos) con sus entidades, tipos y relaciones entre
tipos. Las entidades están agrupadas en esquemas, representativos de conceptos
concretos, que se ensamblan dando lugar a un único modelo.
iv. Disponer del concepto de vista (subconjunto de datos) del modelo (Model View
Definition) que cubre un área específica del proyecto.
Esto lo cual permite garantizar los dispuesto en la legislación actual como se ha señalado
en el epígrafe 1.2 del presente trabajo donde se señalaba que en la disposición adicional 15
de la LCSP [9], en su apartado 6 señala “Para contratos públicos de obras, de concesión de obras, de
servicios y concursos de proyectos, ….. los órganos de contratación podrán exigir el uso de herramientas
electrónicas específicas, tales como herramientas de modelado digital de la información de la construcción
(BIM) o herramientas similares. En esos casos, ofrecerán medios de acceso alternativos ……. hasta el
momento en que dichas herramientas estén generalmente disponibles para los operadores económico”, lo cual
quiere decir que para garantizar la publica concurrencia las administraciones públicas
europeas22 están deberán exigir el formato IFC además de cualquier formato nativo de los
programas de modelado.
La potencia de este formato reside ahí. Es un formato que permite, sea cual sea la
complejidad del proyecto, plasmarlo en un formato de texto. Esto abre toda una ventana
de posibilidades para poder automatizar una gran cantidad de procesos de gestión de la
información sin tener que pasar por un software de una casa comercial determinada.
Como señala la propia casa Autodesk [42] “En un escenario ideal, el archivo IFC debería utilizarse con
fines de coordinación en un visor IFC, o bien a modo de referencia en el software de edición. Por ejemplo, un arquitecto
podría recibir un archivo IFC de un ingeniero de instalaciones para ver dónde está ubicada la instalación. Este es el flujo
de trabajo de coordinación y está incluido en las vistas de coordinación de modelos en IFC.” Por lo que está
22Recordar que esta disposición emana de la transposición de la Directiva Europea [49] que fija la obligatoriedad de dichos conceptos, para
los estados miembros.
37
llamado a ser la base de la tendencia openBIM actual, y es una de las razones ultimas de
la elección de este trabajo.
Es importante señalar que en cambio sí es editable por programa de tratamiento de texto
normales; es decir se puede ver todos los contenidos y es leído por todos los programas
visores de modelos BIM, como se muestra en el siguiente ejemplo.
Ilustración 15 - Modelo BIM de cámara (EMASESA) editado por visualizador BIMData.io (Fuente: Tutor)
A continuación, se puede ver la parte -inicial- del archivo en formato IFC del modelo BIM
de una cámara de conexión de tuberías de 1200 mm de diámetro de un proyecto de
construcción de EMASESA (Ver Ilustración 15).
Dicho archivo tiene 59.224 líneas de código, por lo que su gestión debe ser realizada con
desarrollos informáticos específicos, dado que para un usuario de metodología BIM sería
algo muy alejado de su actividad, y esto provoca la dependencia de las casas comerciales
de software de modelado.
ISO-10303-21;
HEADER;
/******************************************************************************************
* STEP Physical File produced by: The EXPRESS Data Manager Version 5.02.0100.07 : 28 Aug 2013
* Module: EDMstepFileFactory/EDMstandAlone
* Creation date: Tue Jul 07 00:40:17 2020
* Host: DESKTOP-DM4QTP8
* Database: C:\Users\PCJUAN~1\AppData\Local\Temp\{9157F21A-DE52-4B01-A199-276FA15734A4}\ifc
* Database version: 5507
* Database creation date: Tue Jul 07 00:40:08 2020
* Schema: IFC2X3
* Model: DataRepository.ifc
* Model creation date: Tue Jul 07 00:40:09 2020
38
* Header model: DataRepository.ifc_HeaderModel
* Header model creation date: Tue Jul 07 00:40:09 2020
* EDMuser: sdai-user
* EDMgroup: sdai-group
* License ID and type: 5605 : Permanent license. Expiry date:
* EDMstepFileFactory options: 020000
******************************************************************************************/
FILE_DESCRIPTION(('ViewDefinition [CoordinationView_V2.0]'),'2;1');
FILE_NAME('0001','2020-07-07T00:40:17',(''),(''),'The EXPRESS Data Manager Version 5.02.0100.07 : 28 Aug 2013','20180216_1515(x64) - Exporter 19.3.0.0 - Alternate UI 19.3.0.0','');
FILE_SCHEMA(('IFC2X3'));
ENDSEC;
DATA;
#1= IFCORGANIZATION($,'Autodesk Revit 2019 (ENU)',$,$,$);
#5= IFCAPPLICATION(#1,'2019','Autodesk Revit 2019 (ENU)','Revit');
#6= IFCCARTESIANPOINT((0.,0.,0.));
#10= IFCCARTESIANPOINT((0.,0.));
#12= IFCDIRECTION((1.,0.,0.));
#14= IFCDIRECTION((-1.,0.,0.));
#18= IFCDIRECTION((0.,-1.,0.));
#22= IFCDIRECTION((0.,0.,-1.));
#24= IFCDIRECTION((1.,0.));
#26= IFCDIRECTION((-1.,0.));
#28= IFCDIRECTION((0.,1.));
#30= IFCDIRECTION((0.,-1.));
#32= IFCAXIS2PLACEMENT3D(#6,$,$);
#33= IFCLOCALPLACEMENT(#186,#32);
#36= IFCPERSON($,'','olgaprogallardo@gmail.com',$,$,$,$,$);
#38= IFCORGANIZATION($,'','',$,$);
#39= IFCPERSONANDORGANIZATION(#36,#38,$);
#42= IFCOWNERHISTORY(#39,#5,$,.NOCHANGE.,$,$,$,1594074882);
#43= IFCSIUNIT(*,.LENGTHUNIT.,$,.METRE.);
#44= IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#45= IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#46= IFCSIUNIT(*,.PLANEANGLEUNIT.,$,.RADIAN.);
#47= IFCDIMENSIONALEXPONENTS(0,0,0,0,0,0,0);
#48= IFCMEASUREWITHUNIT(IFCRATIOMEASURE(0.0174532925199433),#46);
#49= IFCCONVERSIONBASEDUNIT(#47,.PLANEANGLEUNIT.,'DEGREE',#48);
#50= IFCSIUNIT(*,.MASSUNIT.,.KILO.,.GRAM.);
#51= IFCDERIVEDUNITELEMENT(#50,1);
#52= IFCDERIVEDUNITELEMENT(#43,-3);
#53= IFCDERIVEDUNIT((#51,#52),.MASSDENSITYUNIT.,$);
#55= IFCSIUNIT(*,.TIMEUNIT.,$,.SECOND.);
#56= IFCSIUNIT(*,.FREQUENCYUNIT.,$,.HERTZ.);
39
#57= IFCSIUNIT(*,.THERMODYNAMICTEMPERATUREUNIT.,$,.KELVIN.);
#58= IFCSIUNIT(*,.THERMODYNAMICTEMPERATUREUNIT.,$,.DEGREE_CELSIUS.);
#62= IFCDERIVEDUNIT((#59,#60,#61),.THERMALTRANSMITTANCEUNIT.,$);
#64= IFCSIUNIT(*,.LENGTHUNIT.,.DECI.,.METRE.);
#67= IFCDERIVEDUNIT((#65,#66),.VOLUMETRICFLOWRATEUNIT.,$);
#69= IFCSIUNIT(*,.ELECTRICCURRENTUNIT.,$,.AMPERE.);
#70= IFCSIUNIT(*,.ELECTRICVOLTAGEUNIT.,$,.VOLT.);
#71= IFCSIUNIT(*,.POWERUNIT.,$,.WATT.);
#72= IFCSIUNIT(*,.FORCEUNIT.,.KILO.,.NEWTON.);
#73= IFCSIUNIT(*,.ILLUMINANCEUNIT.,$,.LUX.);
#74= IFCSIUNIT(*,.LUMINOUSFLUXUNIT.,$,.LUMEN.);
#75= IFCSIUNIT(*,.LUMINOUSINTENSITYUNIT.,$,.CANDELA.);
El archivo IFC del modelo BIM es un archivo físico STEP escrito con alguna versión del
programa EXPRESS Data Manager.
La estructura del archivo IFC tiene dos partes:
• Encabezado: Donde se indica una serie de datos de los modelos, la versión del
esquema IFC y el software utilizado, el MVD, el nombre del equipo en el que se ha
realizado, ruta donde se ha guardado, etc.
• Cuerpo: que contiene la información sobre la geometría y la información de los
objetos del modelo.
Las Líneas de código que tienen la estructura: #número de líneas de código= IFC…..
(___expresiones____), donde se clasifica, se identifica de forma única y se nombra el objeto.
En la cabecera del archivo, podemos encontrar información relacionada con el archivo
exportado.
Ilustración 16 - Encabezado de un archivo IFC (elaboración propia)
Se puede ver que las primeras líneas muestran una descripción del modelo, los datos de
guardado (como nombre del fichero, ruta de guardado, quien es el autor etc.) y el
esquema de IFC que se ha utilizado
A su vez existen varios formatos de archivos IFC:
• .ifc que es el formato estándar basado en la norma par intercambio de datos de
40
modelos del producto (STEP, en sus siglas en ingles)
• .ifcZIP
• .ifcXML Representación de datos IFC basada en XML, requerida por algunos
programas de cálculo
En este capítulo también se introducirá en la arquitectura de los estándares utilizados en los
modelos BIM de edificación que son el IFC 2x3 y el IFC 4x1. No existe actualmente un
estándar IFC adaptado a las infraestructuras civiles, siendo el candidato actual IFC 4x3, el
primero que introducirá especificaciones para estas.
6.2 Estructura básica del IFC

A continuación, se expone unas definiciones básicas para comprender la estructura del
esquema IFC.
6.2.1 Entidad
Lo primero que hay que entender es que una entidad a efectos del esquema IFC es lo que
se denomina CLASE. En la web de la organización [43], se puede encontrar la definición de
Entidad como “clase de información definida por atributos y restricciones comunes tal
como se define en [ISO 10303-11]”; similar al término "clase" en los lenguajes de
programación comunes, pero solo describe la estructura de datos (no el comportamiento,
como los métodos).
Una clase es un listado de parámetros que define un objeto, donde un objeto puede ser
material o abstracto. En este grupo de parámetros se define el nombre del parámetro y el
tipo que es: alfabético, booleano, numérico etc.
Las entidades pueden ser cualquier tipo de objeto, por ejemplo, un objeto físico como un
muro o un objeto abstracto como el IFCActor23.
Dentro de algunas entidades podemos encontrar clases predefinidas que son unas
subcategorías de las entidades. Existen clases predefinidos ya creados en IFC y otros que
pueden ser creados por el usuario. Por ejemplo, el objeto físico” puerta” tiene una clase
predefinida que se denomina ifcDoor, que está incluida como subcategoría dentro de las
siguientes clases.
Ilustración 17 - IFCdoor (vía BuildingSmart.org)
Por otra parte y ciñéndose solo a los objetos físicos según la referencia [42] “Una entidad IFC
es un objeto definido de forma única en el modelo de datos IFC. Dependiendo de la asignación de la entidad y
23 IfcActor define a todos los actores o agentes humanos involucrados en un proyecto durante su ciclo de vida completo. Facilita el uso de
definiciones de personas y organizaciones en la parte de recursos del modelo de objetos IFC. Esto incluye nombre, dirección, direcciones de
telecomunicaciones y roles.
41
tipo de definición, al objeto se le asignan ciertos atributos y dependencias por defecto dentro del Esquema IFC.
Elegir la entidad correcta es crucial cuando se quiere exportar el archivo a IFC: si un muro no está asignado
a la entidad IfcWall, no se le asignan todos los atributos que requiere para ser descrito claramente. Esto
significa que no es interpretado correctamente por otros programas de coordinación o evaluación. …”
Ilustración 18 - Clases y tipos de IFC en REVIT (Fuente Autodesk)
6.2.2 Atributos
Todas las entidades tienen atributos, que son una unidad de información. Es decir, si se toma
la clase (entidad) ifcDoor, se puede observar que como atributos tiene los señalados en la
siguiente ilustración.
Ilustración 19 - Atributos de IFCDoor (vía BuildingSmart.org)
Al transferir modelos de datos IFC es necesario que la información pueda ser interpretada
y evaluada correctamente por otros programas como programas especializados (ejemplo
planificación de obra y herramientas de cálculo), independientemente de la estructura de
atributos internos y las descripciones dentro de las respectivas aplicaciones.
6.2.2.1 Atributos predeterminados
Las propiedades de IFC se pueden formular en general utilizando atributos

predeterminados. Estos atributos son almacenados en la definición IFC y tienen nombres en
42
inglés. Por ejemplo, para un muro, el valor del parámetro 'apoyo' se asigna
automáticamente al atributo ifcLoadBearing, como se puede apreciar en la ilustración
siguiente.
Ilustración 20 - Atributos predeterminados de la clase ifcLoadBering (Fuente Autodesk)
6.2.2.2 Parámetros predeterminados
Todos los parámetros predeterminados definidos en el formato IFC es proporcionada por

buildingSMART en la forma de conjuntos de parámetros (P-sets). Como ejemplo, los
parámetros predeterminados para un muro pueden estar incorporados por la herramienta
del modelador (ejemplo el programa REVIT) como se ve en la ilustración siguiente.
Ilustración 21 - Parámetros por defecto asignados en REVIT (Fuente Autodesk)
Y otros como los que se muestran en la siguiente ilustración que no están incorporados por
el programa modelador citado.
Ilustración 22 - Parámetros predeterminados no incorporados por REVIYT para un muro
El nombre exacto de los parámetros se encuentra en la documentación de la

BuildingSMART.
6.2.3 Las superclases en IFC

Son aquellas clases que están en la zona superior del esquema IFC y que a continuación se
43
realizaría una descripción de estas.
6.2.3.1 ifcRoot
Dentro de la estructura del esquema IFC, hay una entidad que es la base de todas y es la
ifcRoot. De acuerdo con BuildingSmart se define como “…… la clase más abstracta y raíz para
todas las definiciones de entidad que se enraíza en el núcleo o en las capas posteriores de la especificación IFC.
Por lo tanto, es el supertipo común de todas las entidades IFC, además de las definidas en un esquema de
recursos IFC. Todas las entidades que son subtipos de IfcRoot se pueden usar de forma independiente, mientras
que las entidades de esquema de recursos, que no son subtipos de IfcRoot, no se supone que sean entidades
independientes.”
En el IFCRoot se definen una serie de atributos que serán aplicados a todas las clases
(entidades) del proyecto:
Ilustración 23 - Atributos de IFCROOT (vía BuildingSmart.org)
IFCRoot es la lista de parámetros madre del formato, conocido como Supertype. Hay tres
tipos de entidades fundamentales en el modelo IFC, que se derivan de IfcRoot; y forman el
primer nivel de especialización dentro de la jerarquía de entidades. En la página de
BuildingSmart se puede observar el esquema de herencia de esta entidad donde se ven
estas entidades fundamentales.
Es importante el término de “herencia” dentro de un formato diseñado para ser orientado
a objetos. La herencia permite que una clase hija obtenga los atributos de una clase madre.
Esta es la razón por la que IFCRoot tiene como atributos el ID (entre otros), ya que este
atributo es esencial para la definición de las clases y se debe de encontrar en todos.
6.2.3.2 ifcObjectDefinition
BuildingSMART define el ifcObjectDefinition así “IFCObjectDefinition es un supertipo abstracto,

y representa todos los elementos físicamente tangibles (como paredes, vigas o cubiertas), elementos
físicamente existentes (como espacios), o elementos conceptuales, (como cuadrículas o límites
virtuales). También representa procesos como tareas de trabajo, controles como elementos de costo,
recursos como recursos laborales o actores como personas involucradas en el proceso de diseño.”
Los ObjectDefinition se especializan en:
• Ocurrencias de objetos, IfcObject, que indica cualquier objeto individual en el
espacio, tiempo u otro contexto de representación, en tipos de objetos
• IfcTypeObject que indica las definiciones comunes como un tipo o artículo que son
idénticos para todas las ocurrencias de objetos,
• Proyectos básicos o contexto de biblioteca, IfcContext.
Un objeto y tipo de objeto obtiene su información de las relaciones en las que está
involucrado. Esto incluye la relación de definición con la información de propiedad o la
44
relación de escritura para asignar un tipo de objeto subyacente a un objeto.
Ilustración 24 - Herencia de IFCObjectDefinition (vía BuildingSmart.org)
6.2.3.3 ifcObject
ifcObject es una entidad que define un objeto físico. Según lo define BuildingSMART “Un
IfcObject es la generalización de cualquier cosa o proceso semánticamente tratado. Los objetos son cosas tal
como aparecen, es decir, ocurrencias.”
Los ejemplos de IfcObject incluyen elementos físicamente tangibles como paredes, vigas o
revestimientos, elementos físicamente existentes como espacios o elementos conceptuales
como cuadrículas o límites virtuales. También representa procesos como tareas de trabajo,
controles como elementos de costo o actores como personas involucradas en el proceso
de diseño.
Ilustración 25 - Herencia de IFCObject (vía BuildingSmart.org)
6.2.3.4 IFCRelationship
El IFCRelationship es una clase que permite la relación entre varios objetos. BuildingSmart la
define como “IFCRelationship maneja las relaciones entre los objetos. Esto permite mantener propiedades
específicas de relación directamente en el objeto de relación y desacoplar la semántica de relación de los
atributos del objeto. La introducción de las relaciones a objeto también permite el desarrollo de un árbol de
subtipos separado para la semántica de las relaciones”
Ilustración 26 - Herencia de IFCRelationship (vía BuildingSmart.org)
45
6.2.3.5 IFCPropertyDefinition
BuildingSmart lo define como “la definición de propiedad, IfcPropertyDefinition, es la generalización de

todas las características de los objetos. Compartido entre varias instancias de objeto, refleja la información
específica de un tipo de objeto, pero también puede representar la información de ocurrencia del objeto real en
el contexto del proyecto, si se asigna solo a una instancia de objeto único”.
La definición de propiedad se aplica a los objetos utilizando el concepto de relaciones.
Ilustración 27 - Herencia de IFCPropertyDefinition (vía BuildingSmart.org)
En la herencia, se puede ver que la entidad IFCPropertyDefinition tiene dos subentidades:

IFCPropertySetDefinition y IFCPropertyTemplateDefintion.
a) IfcPropertySetDefinition es una generalización de todos los conjuntos de propiedades
individuales que se pueden asignar a un objeto o tipo de objeto.
Ilustración 28 - Herencia de IFPropertySetDefinition (vía BuildingSmart.org)
B) IFCPropertyTemplateDefintion: es una generalización de todas las propiedades y

plantillas de conjunto de propiedades.
Ilustración 29 Herencia de IFCPropertyTemplateDefinition (vía BuildingSmart.org)
La definición del conjunto de propiedades puede ser la de “Conjuntos de propiedades extensibles

dinámicamente: IfcPropertySet, un conjunto de propiedades para las que la especificación IFC solo
proporciona una especie de "metamodelo", que se declarará por acuerdo”. Esto significa que no existe
una definición de entidad de las propiedades dentro de la especificación IFC.
La declaración se realiza asignando un valor de cadena significativo al atributo Nombre de
la entidad como se define en la entidad IfcPropertySet y en cada subtipo de IfcProperty,
referenciado por el conjunto de propiedades.
Los conjuntos de propiedades definidos dinámicamente pueden tener una plantilla
subyacente proporcionada por IfcPropertySetTemplate. Es decir, unas propiedades
definidas por los usuarios que no están previstos en el esquema IFC
Hay conjuntos de propiedades definidas estáticamente IfcPreDefinedPropertySet, una
46
entidad de conjunto de propiedades que existe dentro de la especificación IFC. El
significado semántico de cada conjunto de propiedades estáticamente definido se
declara por su tipo de entidad y el significado de las propiedades se define por el nombre
y el tipo de datos del atributo explícito que lo representa.
Es decir, existen conjunto de propiedades que se le pueden aplicar a un objeto, que
pueden estar predefinidas en el esquema IFC (estáticas) o no (Dinámicas).
6.3 Mapeo de clases

Las entidades (clases) IFC, tendrán otras definiciones en cada programa de modelado o
herramientas de cálculo, para ello será necesario realizar tablas de mapeo de parámetros
que, tanto para importación como para exportación, a o desde los ficheros nativos se
tenga la relación entre las clases IFC y los parámetros nativos.
Como ejemplo en la ilustración siguiente se muestra la table de mapeo de importación en
REVIT
Ilustración 30 - Ejemplo de TABLA DE MAPEO DE IMPORTACION de parámetros IFC en REVIT (Fuente Autodesk)
6.4 Esquemas IFC utilizados

Dentro de los programa de modelado para edificación más potentes como REVIT O
ARCHICAD, o bien para obras lineales como CIVIL3D o ISTRAM, los esquemas del formato
IFC más utilizado son el IFC 2x3 (en estado maduro para edificación) y el IFC 4 actualizado;
proceso vivo en la actualidad que está permitiendo ir incorporando entidades y conjuntos
de propiedades de obras civiles, que los trabajos como los de Lee, S-H en [33] de la
Universidad de Yonset (Seúl, Corea) ya comenzaron en 2.011 a definir.
47
Ilustración 31 - Propuesta de agregación espacial de elementos para carreteras (Fuente Lee,S-H et alters)
Solo hay que señalar que los actuales y futuros trabajos de incorporación de entidades al
esquema IFC deberían respetar al ISO 6707-1 Building and civil engineering – Vocabulary, a
efectos de garantizar la interoperabilidad tanto de los archivos como de la propia
información.
Ilustración 32 - Relaciones entre los elementos espaciales y elementos físicos (Fuente Lee, S-H et alters)
6.4.1 Esquema del estándar IFC 2x3

La arquitectura del estándar IFC 2x3 según la BuildingSMART [44] se presenta en la siguiente
ilustración donde se muestra los dominios, elementos, extensión y recursos que forman parte
48
de la misma.
Ilustración 33 – Arquitectura IFC 2x3 (vía BuildingSmart.org)
Si por ejemplo examinamos, la extensión de PRODUCTOS, podemos observar las entidades

(clases) que lo componen, y si de ellas examinamos la entidad IFCBuildingElement que es
la que normalmente tendrá los objetos físicos de nuestra obra de edificación, tendremos su
esquema de herencias como se ha señalado en el epígrafe 6.2.3 del trabajo
EXPRESS specification:
ENTITY IfcBuildingElement
ABSTRACT SUPERTYPE OF(ONEOF(IfcBuildingElementProxy, IfcCovering, IfcBeam, IfcColumn, IfcCurtainWall, IfcDoor,
IfcMember, IfcRailing, IfcRamp, IfcRampFlight, IfcWall, IfcSlab, IfcStairFlight, IfcWindow, IfcStair,
IfcRoof, IfcPile, IfcFooting, IfcBuildingElementComponent, IfcPlate))
SUBTYPE OF (IfcElement);
END_ENTITY;
Inheritance graph
ENTITY IfcBuildingElement;
ENTITY IfcRoot;
GlobalId : IfcGloballyUniqueId;
OwnerHistory : IfcOwnerHistory;
Name : OPTIONAL IfcLabel;
Description : OPTIONAL IfcText;
ENTITY IfcObjectDefinition;
INVERSE
HasAssignments : SET OF IfcRelAssigns FOR RelatedObjects;
IsDecomposedBy : SET OF IfcRelDecomposes FOR RelatingObject;
Decomposes : SET [0:1] OF IfcRelDecomposes FOR RelatedObjects;
HasAssociations : SET OF IfcRelAssociates FOR RelatedObjects;
ENTITY IfcObject;
ObjectType : OPTIONAL IfcLabel;
49
INVERSE
IsDefinedBy : SET OF IfcRelDefines FOR RelatedObjects;
ENTITY IfcProduct;
ObjectPlacement : OPTIONAL IfcObjectPlacement;
Representation : OPTIONAL IfcProductRepresentation;
INVERSE
ReferencedBy : SET OF IfcRelAssignsToProduct FOR RelatingProduct;
ENTITY IfcElement;
Tag : OPTIONAL IfcIdentifier;
INVERSE
FillsVoids : SET [0:1] OF IfcRelFillsElement FOR RelatedBuildingElement;
ConnectedTo : SET OF IfcRelConnectsElements FOR RelatingElement;
HasCoverings : SET OF IfcRelCoversBldgElements FOR RelatingBuildingElement;
HasProjections : SET OF IfcRelProjectsElement FOR RelatingElement;
HasStructuralMember : SET OF IfcRelConnectsStructuralElement FOR RelatingElement;
ReferencedInStructures : SET OF IfcRelReferencedInSpatialStructure FOR RelatedElements;
HasPorts : SET OF IfcRelConnectsPortToElement FOR RelatedElement;
HasOpenings : SET OF IfcRelVoidsElement FOR RelatingBuildingElement;
IsConnectionRealization : SET OF IfcRelConnectsWithRealizingElements FOR RealizingElements;
ProvidesBoundaries : SET OF IfcRelSpaceBoundary FOR RelatedBuildingElement;
ConnectedFrom : SET OF IfcRelConnectsElements FOR RelatedElement;
ContainedInStructure : SET [0:1] OF IfcRelContainedInSpatialStructure FOR RelatedElements;
ENTITY IfcBuildingElement;
6.4.2 Esquema del estándar IFC 4x1

El esquema IFC 4 – Addemdum 1 contiene 768 entidades y 410 conjuntos de propiedades
(property set), pero este ha ido evolucionando en el tiempo. A continuación, y para mayor
compresión del resto del trabajo, se considera necesario detallar la arquitectura del
estándar actual IFC 4x1 versión 4.1.0.0 de junio de 2.018. Actualmente existe como
candidato el esquema IFC 4x3 RC1 (abril, 2.020), habiéndose retirado el estándar IFC 4x2.
Para analizar el esquema IFC 4x1, y dado que la propia organización BuilgdingSMART no ha
realizado una descripción funcional como para el estándar IFC 2x3, se ha desarrollado para
el trabajo el esquema completo de la herencia del ifcRoot, y los esquemas detallados de
los supertipos siguientes:
1. Esquema detallado de la herencia del ifcObjetDefiniton
2. Esquema detallado de la herencia del ifcPropertyDefinition
3. Esquema detallado de la herencia del ifcRelationship
mediante las siguientes ilustraciones
50
Ilustración 34 - Esquema Completo IFC (elaboracióin propia)
51
Ilustración 35 - Herencia de IFCObjetDefinition (Elaboración propia)
52
Ilustración 36 - Herencia del IFCPropertyDefinition (Elaboración propia)
Ilustración 37 - Herencia del IFCRelationsip (Elaboración propia)
53
6.4.3 Diferencias entre esquemas IFC
El esquema IFC está en continuo avance en el tiempo desde su nacimiento en 1.996 (IFC
1.0), adaptándose a las nuevas necesidades que los profesionales del sector AEC van
demando al ir incorporándose diferentes disciplinas a las tecnologías de modelado digital
de la construcción, y en especial a la metodología BIM. Como muestra de esta rápida
evolución, desde que este trabajo se empezó (en el primer cuatrimestre del curso
académico 2.019-2.020) hasta la fecha de su terminación, la BuildingSmart ha empezado
a mostrar un avance de la siguiente versión de su formato de interoperabilidad estándar
IFC 4x3.
Cierto es que el esquema IFC para infraestructuras civiles aún no está en un estado óptimo
para su uso, comparado con la madurez que si tiene en edificación, pero su uso en
proyectos de ingeniería civil en él se utilice la tecnología BIM es muy recomendable porque
permite la incorporación/extracción de información de construcción (datos); funciones
que los actuales programas de modelado de infraestructuras civiles no las tienen
plenamente integradas, y debe ser el usuario el que debe definir sus conjuntos de
propiedades (property set) siendo por tanto muy débil la interoperabilidad de la
información al carecer de estandarización.
Por ello, en este apartado se va a analizar las diferencias sustantivas que hay entre los
esquemas descritos más arriba. El primero propio de proyectos de edificación y que no
incluye ninguna entidad de obras civiles; y el segundo que ya comienza a incorporar
entidades y conjuntos de propiedades específicas de este tipo de construcciones, del cual
también se procederá a exponer aspectos de la última versión accesible, en la fecha de
redacción de este trabajo.
Para obtener la información de cuáles son las versiones que se encuentran activas, hay que
acudir a la página https://technical.buildingsmart.org/standards/ifc/ifc-schema-
specifications/.
En esta página se encuentra la base de datos de las especificaciones de los esquemas IFC,
donde se indican las versiones oficiales, sus componentes y la documentación necesaria
para la compresión de estos formatos (Ver Ilustración 14).
Los formatos activos son IFC 4 ADD2 TC1 (año 2.017) y el IFC 2x3 TC1 (año 2.007), ambos
sustentado por versiones de la norma ISO 16.739; y el IFC 4x1 (año 2.018) que no tiene
soporte de norma de estandarización.
Un modelo BIM exportado en IFC puede tener muchas representaciones una con más
detalle que otras, también con una información asociada muy dispar, pero no todos los
agentes que intervienen en el modelo van a necesitar la misma información ni el mismo
nivel de detalle en la geometría del modelo.
54
Ilustración 38 - Esquemas del IFC (vía BuildingSmart.org)
La diferencia más notoria entre ambos estándares se encuentra en la definición de vista de

modelo (Model View Definition- MVD). Las definiciones de vistas de modelos se utilizan para
optimizar el esquema IFC, es decir, se puede considerar un filtro para la trasmisión de
información entre sistemas. De tal forma, el MVD garantiza una trasmisión de información
sin información inútil ni redundante.
Ilustración 39 - Esquema de las vistas de modelo - MVD (Fuente Autodesk)
55
La versión 2x3 TC1 tiene un MVD denominado Coordination View, una definición de la vista
del modelo que pretende la coordinación entre las distintas disciplinas participantes en el
diseño. En este caso, al ser una versión más antigua se tiene como base el diseño de
edificaciones y es la segunda versión de este MVD. Es el MVD más utilizado porque se
encuentra en una de las versiones más estables y con más uso de IFC.
En cuanto a la versión 4 ADD2, cuenta con un MVD definido como Reference View. Es una
representación geométrica del espacio y de relaciones del componente, para permitir la
transferencia de información de un software de trabajo a otro, pero está pensado para una
geometría definida. Es decir, la exportación de un diseño ya realizado, pero en el que se
quiere seguir trabajando en otros aspectos (como por ejemplo el presupuesto) que
requieren que la definición geométrica sea trasvasada sin perder calidad, pero sin la
necesidad de que esta pueda ser modificada.
Otro MVD que existen en el esquema IFC 4 ADD2 es el Desing Transfer View que es un MVD
que permite exportar modelos en formato IFC para que sean importados en otro programa
modelador BIM, por lo que requiere una representación geométrica detallada.
La base del formato 2x3 era ser la llave de un trabajo colaborativo entre los distintos sectores
que trabajan en el diseño de un edificio (ahora, extendido al diseño de infraestructuras).
Con su evolución hacia el IFC 4, la BuildingSMART quería que los MVD fueran definiciones
específicas para los objetivos de la exportación, es decir, que una exportación basada en
un esquema concreto (con un MVD) no sirviera a la vez para la planificación y para el
diseño, ya que habría mucha información y definición geométrica que sería
desaprovechada por alguna de las disciplinas. En este sentido se dividió el MVD para tener
una referencia visual para la coordinación entre sistemas y un MVD (Desing Transfer View)
que permite el diseño después de un proceso de exportación-importación.
6.4.4 Ultima versión candidata

Para que una versión del esquema IFC sea definitiva y reciba la certificación, es necesario
que primero sea un formato candidato para después ser aprobado por la BuildingSMART.
La versión más actualizada que está pendiente de obtener la categoría de formato oficial
es la versión IFC 4x3 RC1.
Esta versión es una continuación lógica del esquema 4x2 que no llegó a ser una versión
oficial y que realizó cambios importantes en el esquema de 4x1.
El esquema 4x3 hereda el sistema MVD creado para la versión 4x1. Por lo que los cambios
más importantes se encuentran en la definición de las entidades (clases) (Ver Ilustración 40)
Lo primero que va a notar el usuario si este esquema se hace oficial (y se certifica para la
exportación en los principales programas de modelado BIM) es el cambio en los objetos
tangibles.
Estas entidades son las que se le van a asociar a los objetos tangibles de un modelo BIM. Un
usuario modelador, estará acostumbrado que al exportar un modelo BIM en un esquema
IFC todos los objetos que se han creado en su programa modelador se conviertan en
objetos herederos de estas clases. Con la diferencia, de que los elementos como IFCWall,
IFCDoor etc. se encuentran incluidos en una clase IFCBuildingElement extinta. (como se
puede comprobar en el esquema 4x1 mostrado en apartados anteriores)
56
Ilustración 40 - IFC Elemento (vía BuildingSmart.org)
La diferencia es solo una palabra Building, pero es una declaración de intenciones de

BuildingSMART que elimina dicha palabra de las entidades más utilizadas para la
exportación de modelos BIM. Quita la palabra BUILDING (edificio) (o construcción, según
se mire) para incluir la palabra BUILT (construido). Quieren dejar a un lado la “exclusividad”
del formato IFC para modelos de edificación para expandir a modelos de construcción
mucho más genéricos. En esta línea, vienen todos los cambios, por lo que se podría decir
que esta versión es la versión del cambio a un formato más adecuado para exportar
modelos de infraestructura.
Además, hay una diferencia significativa en cuanto al número de objetos que se pueden
modelar específicamente (no de forma genérica), si se compara la versión 2x3 -21
entidades- con el estándar 4x1 -30 entidades- (Ver Ilustración 41 e Ilustración 42)
Ilustración 41 - Esquema 2x3 (vía BuildingSmart.org)
57
Ilustración 42 - Esquema 4x1 (vía BuildingSmart.org)
Se incluyen entidades como IFCPavement e IFCRail como grandes elementos para la

exportación de modelos de infraestructura (también IFCTrackElement). Pero aún con estos
nuevos elementos, la novedad más importante es que el objeto que se utilizaba hasta
ahora por los programas modeladores para exportar cualquier objeto que pudiese
pertenecer a un modelo de infraestructura (ifcBuildingElement) queda obsoleto a partir de
esta versión y piden que no se exporte. Lo cual plantea una situación en la que todos los
sólidos modelados por Civil 3D pertenecientes al movimiento de tierras (por poner un
ejemplo) de una obra de infraestructuras no tienen un objeto al que puedan ser exportados
con claridad. Por lo que habrá que esperar para saber si a este objeto físico (volúmenes de
movimiento de tierras) es porque se espera una nueva versión con el IFCRoad -por fin
implementado- o porque le van a dar cabida en otro elemento genérico
Otra clase que podría ser un contenedor válido para elementos de obra de infraestructura
es el ifcCivilElement, pero también se ha declarado su obsolescencia.
Una clase nueva, que es importante para los modelos de cualquier tipo de construcción es
el ifcGeotechnicalElement, el cual es un supertipo abstracto que será contenedor de
objetos geotécnicos. Este es un avance importante para que los modelos BIM exportados
en este formato adquieran un carácter útil para el diseño de infraestructuras civiles. Dentro
de esta superclase se encuentra otras dos entidades, como puede verse en la siguiente
ilustración.
58
Ilustración 43 - IFCGeothecnicalElement (vía BuildingSmart.org)
La clase ifcGeotechnicalAssembly es una clase en la que se encuentra ifcBorehole

(sondeo), ifcGeomodel y el ifcGeoslice.
Ilustración 44 IFCGeothecnicalAssembly (vía BuildingSmart.org)
En la otra clase hija de ifcGeotechnicalAssembly, como es la ifcGeotechnicalStratum se

encuentra en la representación del modelo geotécnico gracias a la representación de los
sólidos (estratos), ya sean sólidos, llenos de agua (oquedad con agua) o de aire (cueva)
Ilustración 45 - IFCGeotechnicalStratum (vía BuildingSmart.org)
Uno de los grandes problemas para la utilización del formato IFC para exportar un modelo
de infraestructuras es la definición espacial del modelo. Se definía espacialmente una
infraestructura utilizando elementos para localizar plantas de un edificio; lo que ha supuesto
un poderoso freno a la aplicación de los modelos BIM en infraestructuras civiles de carácter
lineal (carreteras, ferrocarriles, etc.)
Esta actualización es el primer paso para que el esquema IFC pueda soportar y definir los
modelos de infraestructura por lo que, como no podía ser de otra manera, la definición
geométrica (espacial) ha cambiado. En el esquema 4x2 ya se definían otras formas de
dotar al modelo de un sistema de referencias local y global.
En este esquema se han definido también otras entidades (ifcFacility) como son las que se
indican en la siguiente ilustración. Señalar la confusión de la BuilgindSMART al señalar los
elementos de infraestructuras civiles (puentes, edificios, instalaciones portuarias, ferrocarriles
59
y carreteras) como instalaciones (Facility)
Ilustración 46 - IFCFacility (vía BuildingSmart.org)
Además de ifcBuilding que alberga la información definida por un sistema de referencia

global para que a partir de este definir la geometría del modelo, BuildingSMART ha definido
las entidades: ifcBridge (ya se encontraba en 4x2), ifcMarineFacility, ifcRailway e ifcRoad.
Todas estas clases albergan la información espacial para los modelos de puentes, de
puertos, de vías de ferrocarriles y de carreteras. Esto es un gran paso en la evolución del
formato.
6.5 El formato IFC para infraestructuras civiles

Podemos concluir no obstante que hasta la llegada del IFC 5 que va más retrasado no
podrá aplicarse dicho formato IFC con plena potencia a los proyectos de infraestructuras
civiles.
Ilustración 47 - Evolución esperada del formato IFC para infraestructuras (Fuente Sacyr)
Para ello se ha seguido un esquema conceptual mostrado en la ilustración siguiente.
60
Ilustración 48 - Esquema conceptual del IFC 4x3 para carreteras (Fuente SACYR)
En este sentido el proyecto de investigación ROADBIM realizado en España por un consorcio

de empresas [45] ha supuesto un avance muy importante para realizar una propuesta de
modificación del formato IFC en su evolución hacia el estándar IFC 5, incorporando los
nuevos definiciones de los dominios de infraestructuras establecido por el IFC 4x3, y así se
establece las nuevas entidades con su esquema de propiedades, como por ejemplo
puede apreciarse para la entidad ifcRoad en la siguiente ilustración.
Ilustración 49 - Propiedades y entidades del ifcRoad (Fuente Sacyr)
61
O bien para el ifcPavement en la siguiente ilustración, tanto con sus entidades
ifcPavementTypeEnum, como la ifcPavementLayer.
Ilustración 50 - Propiedades y entidades del ifcPavement (Fuente SACYR)
Y las otras entidades necesarias para el proyecto de carreteras.
Ilustración 51 - Otras entidades del IFC 4x3 para carreteras (Fuente SACY)
62
7 LA INFORMACIÓN EN EL ESQUEMA IFC
Para que un modelo 3D se pueda considerar un modelo BIM es necesario que este modelo
albergue información más allá de la información geométrica. Eso implica, que los archivos
deben de ser contenedores de información y que deben de tener previstas en su definición
la posibilidad de crear nuevas líneas de información. En este sentido, el esquema IFC es uno
de los formatos en los que la posibilidad de añadir información es casi ilimitada, se puede
incluir casi cualquier tipo de información y que aparezca relacionada a cualquier tipo de
objeto.
El flujo de trabajo de muchos usuarios de la tecnología BIM es añadir información a un
modelo 3D desde los programas modeladores usados para diseño digital. Esto implica, que
la gestión de datos está limitada a la funcionalidad que te permita el programa modelador
para hacerlo. A partir de la versión de 2020 Civil 3D, Autodesk ha implementado el
complemento de Dynamo en el programa, por lo que se abre una vía de automatización
en la de gestión de información, pero se depende de la empresa desarrolladora del
software. En otras casas de programas destinados al modelado de infraestructuras ni si
quieran dejan esta opción.
Entre los objetivos de este trabajo esta automatizar los procesos de incorporación de
información para verificar la interoperabilidad de los modelos BIM; esto significa la
necesidad de utilizar archivos producidos bajo el esquema IFC, que, al ser un estándar
neutro, debe ser la base de la necesaria gestión masiva de datos y de información en
modelos de construcción.
7.1 Propiedades de la información

El primer paso para la gestión de información dentro de un formato IFC es entender como
este formato clasifica y relaciona la información. Todos los objetos, tienen atributos
predefinidos y propiedades definidas previamente. Esto es importante, ya que muchas de
la información que se crea, desde por ejemplo Revit, tiene su equivalencia directa en el
formato IFC, pero no proporciona al usuario la libertad necesaria para la gestión autónoma
de datos. Pero como ya se ha comentado antes, el esquema IFC sí que da esta posibilidad,
gracias a los conjuntos de propiedades (Pset). Contenedores de información, definidos
autónomamente al modelo y que pueden ser asociados a cada uno de los objetos. Este es
el verdadero potencial del formato IFC, que la información se define y se gestiona
independiente a los objetos y que en última instancia se relaciona.
Dentro de los conjuntos de propiedades se encuentra propiedades (donde se define un
nombre y un valor). IFCPropertySet se encuentra en ese lugar del esquema IFC (Ver
Ilustración 52) por lo que hereda de las clases madre todos sus atributos. Además, añade
como atributo el número de sentencia en el que se encuentran las propiedades
pertenecientes al conjunto.
63
Ilustración 52 - IFCPropertySet (vía BuildingSmart.org)
Analizando la estructura de IFCPropertySet en un archivo IFC se puede comprender como

un programa modelador escribe los conjuntos de propiedades y así poder tener un
programa que escriba de forma automática los conjuntos de propiedades que el usuario
quiera. Hay que entender, que la información realmente se encuentra en las propiedades,
el conjunto de propiedades es una forma de optimizar la relación entre propiedades y
objetos y así evitar información redundante. Las propiedades se definen por un nombre y
por un valor que puede tener varios formatos, todos los permitidos por IFCValue (ya que
mediante este objeto es con el que le agregamos información).
Para que toda la información se vaya agregando a los objetos que el usuario quiere, IFC
utiliza las relaciones. Por lo que el comportamiento de la información en un IFC es como el
que se muestra en la siguiente ilustración.
Ilustración 53 - Gestión de datos y objetos de IFC (elaboración propia)
Esto se traduce en el lenguaje del formato de la siguiente forma, en la que a partir de la

correspondiente línea de código #nnnnnn= IFCPROPERTYSET(…………………… #nnnnn1,
#nnnnn2, ……..) se colocan líneas de código en la información de construcción dentro de
las sentencias #nnnnn1= IFCPROPERTYSINGLEVALUE(……, ……………………..), como se ve a
continuación.,
Ilustración 54 - Líneas de código del ifcPropertySet
Siguiendo esta estructura, se puede implementar al modelo una cantidad de información

enorme, que, si se tiene que implementar de una manera manual, por un usuario en un
programa modelador supondría un coste en tiempo excesivo. Por lo que la evolución de la
tecnología BIM, en lo referido a una gestión de la información que de verdad aumente la
64
calidad del modelo no puede pasar por un enriquecimiento manual y que conlleve la
dedicación exclusiva de un ingeniero modelador a labores repetitivas. Por lo tanto, esta
información masiva de datos debe de ser añadida mediante procesos automatizados.
7.2 Los datos de los objetos

Para comprender como el formato IFC gestiona la información de construcción (datos), se
procede a estudiar la información de un objeto físico que está incluido dentro de un modelo
BIM de ferrocarril, como es el rail ferroviario. Este rail ha sido modelado como parte de una
línea ferroviaria del proyecto de apartadero ferroviario del Ramal del Cortijo del Cuarto del
Puerto de Sevilla.
Este objecto se ha obtenido mediante la técnica de extracción de sólidos de una obra
lineal -podemos definirlo como un sólido por extrusión- con el software C3D. Al objeto
extraído (cuya información de construcción inicial del modelo 3D es básica y muy pobre
para sustentar sobre la misma un verdadero modelo BIM) se han asociado un conjunto de
propiedades adicionales creadas por el usuario (en este caso asimilando nuestro trabajo al
de ingeniero civil de construcción) que permitan introducir datos para la construcción -
modelo BIM As Built-. Propiedades adicionales definidas por el usuario que podemos
analizar en la siguiente ilustración. (Conjunto de Propiedades con el nombre Carriles)
Ilustración 55 - Modelo de Infraestructura ferroviaria (Fuente: Elaboración propia)
El análisis de este objeto se va a utilizar (i) un editor de .txt para ver cómo se definen todos
los atributos de un elemento (en nuestro caso un sólido exportado por C3D), y (ii) un visor
de modelos BIM como es el us.BIMviewer ya que permite una edición de las propiedades
de una forma mucho más sencilla que en C3D.
7.2.1 Proceso de exportación a formato IFC
El proceso de exportación de un objeto desde el software C3D comienza con la

herramienta que se selecciona en el menú desplegable de inicio, de Inicio>exportar, en
formato IFC.
Al exportar, se despliega un menú (ver Ilustración 56) en el que se pueden definir varios
parámetros generales del proyecto. Se puede definir el número y el nombre, así como la
ruta de guardado del archivo. En las opciones se puede especificar el esquema IFC que se
quiere para exportar (en este caso el 4x1).
65
Ilustración 56 - Exportar a IFC desde Civil 3D (elaborado por mi)
En la ficha de RECURSO Y ASIGNACIÓN DE IFC, opción de RECURSO se encuentra las

primeras clases (entidades) a definir en la exportación.
Ilustración 57 - Recursos a Exportar a IFC desde Civil 3D (elaborado por mi)
Aquí se puede establecer la información más general como es la información del equipo
de proyecto, con las siguientes clases. La dirección ifcAdress (de los autores del proyecto)
y el ifcActor que define todas las personas físicas y jurídicas que participan en el modelado
del proyecto. Dentro de esta entidad, se puede establecer ifcPerson e ifcOrganization (y
relacionarlos entre sí). Para añadir una dirección (tanto postal como electrónica) hay que
pinchar con el botón derecho y seleccionar >nuevo. En el cuadro del margen derecho se
puede rellenar las propiedades que C3D tiene establecidos para estas entidades.
66
Ilustración 58 - Nuevos parámetros a Exportar desde Civil 3D (elaboración propia)
El mismo proceso se puede establecer para las entidades IFCPerson y para la

ifcOrganization.
En ifcPersonAndOrganization se asigna una entidad ifcPerson e ifcOrganization.
Ilustración 59 - Exportar Persona a IFC desde Civil 3D (elaborado propia)
7.2.2 Análisis del fichero IFC

Una vez efectuada la exportación y generado el correspondiente fichero IFC, el primer
análisis del archivo de texto lo primero que se puede ver que es un archivo muy extenso.
El formato IFC con su sistema de entidades y relaciones está pensado para que el tamaño
del archivo sea reducido, dado que por ejemplo un modelo tan simple como este llega a
casi 5.000 líneas de código (sentencias), que se eleva a más de 300.000 para modelos BIM
algo más complejos. Aunque la mayoría de ellas son referencias geométricas.
7.2.3 La organización de los datos
En la primera línea de código (sentencia) del conjunto de datos se puede encontrar:
67
En esta primera sentencia se encuentra la entidad de ifcPerson (definida antes). Esta

entidad tiene de atributos el ID, apellido, nombre de pila, rol (que se establece en otra
entidad, por si vuelve a ser llamado -Sentencia #5).
Si se continua por el .txt, se puede encontrar:
Aquí se encuentra la entidad ifcPostalAddress donde se establece la dirección postal

definida antes. Los atributos de esta entidad son: dirección postal, dirección, ciudad, país y
código postal. El formato no tiene los caracteres: “´” y “ñ” por lo que los escribe con otro
formato. En la siguiente sentencia se define la organización (ifcOrganization) que tiene los
siguientes atributos: ID, nombre de la organización, roles desempeñado por la organización
(#16), dirección (#7). Esta sentencia acude a las sentencias 7 y 16. La sentencia 16 describe
el rol de la organización.
En la siguiente sentencia #21, se define la entidad ifcPersonAndOrganization es una
sentencia que identifica una persona dentro de una organización, que como atributos
tiene la persona (definida dentro de la organización) y la organización (en la que se
encuentra esa persona). Para ello, se acude a la sentencia #1 y #11 que define la persona
y la organización.
7.2.3.1 La información del proyecto
A continuación, vamos a detallar donde se localiza dentro del fichero IFC, la información
del Proyecto, mediante el análisis del resto de líneas de código del archivo realizando la
descripción de las entidades (clases) más significativas.
Para ello se ha identificado grupos de líneas de código que a efectos de este trabajo
denominaremos las secciones del archivo, y que son las siguientes:
• La información general del Proyecto
• El conjunto de propiedades
• La estructura espacial del proyecto
• La geometría del modelo
• La información heredada en el objeto
7.2.3.2 La información general del proyecto
Si se analiza el archivo IFC se puede encontrar las siguientes líneas de código:
68
Ilustración 60 - Líneas de código de ifcProject (Elaboración propia)
En ellas se empieza a definir el proyecto, y en la primera sentencia (la #23) nos encontramos
con la entidad IFCProject. En los atributos de esta entidad se puede encontrar la siguiente
información:
• el ID de la entidad,
• luego se hace referencia a la sentencia #66.
• El ‘005’ se refiere al número de proyecto dado en la exportación de este IFC desde
C3D.
• ‘PruebaRailAutor’ es el nombre del proyecto
• Se termina haciendo referencia a dos sentencias, la #33 y #53.
El IFCProject es la entidad encargada de darle contexto a este archivo, es decir, asociarla
a un modelo concreto, así como definir sus unidades básicas. En la sentencia #33 se puede
encontrar la entidad IFCGeometricRepresationContext. Esta última entidad es un contexto
en los que se basa geométricamente el modelo. Esta entidad tiene como atributos: (i)
Dimensiones del espacio de coordenadas, (ii) precisión, (iii) sistema de coordenadas y (iv)
el norte (en relación con el sistema de coordenadas).
Se puede ver que el modelo tiene 3 coordenadas, con una precisión de 2,54e-8. El atributo
norte verdadero es opcional.
El sistema de coordenadas, se establece la sentencia #49; en la cual se define la entidad
IFCAxis2Placement3D. Esta entidad define la ubicación y orientación en el espacio de los 3
ejes que definen el sistema de coordenadas. Para ello, se establece un punto (que es el
origen de coordenadas) y dos direcciones perpendiculares (por lo que ya solo queda una
dirección posible que cumpla que sea perpendicular a las otras dos por definición). Estas
son las sentencias #37, #41 y #45. Donde la primera establece el punto y las siguientes las
direcciones.
La otra entidad a la que acude la entidad ifcProject está indicada en la sentencia número
#53. Y la entidad que se define es ifcUnitAssigment. Esta entidad define las unidades físicas
que utiliza el proyecto. Para definir las unidades físicas, se acude a las sentencias #55, #56,
#57, #58, #63, #64. Las tres primeras definen las unidades de longitud, área y volumen. La
sentencia #58 define la entidad ifcConversionBasedUnit, que establece una unidad
convertida. En este caso, en los atributos se hace referencia al nombre de la unidad basada
en la conversión (en este caso grados) y el factor. Este factor se define en la sentencia #61
(con la entidad ifcMeasureWithUnit que da la tasa de conversión entre dos unidades y la
unidad en la que se expresa la unidad física (a la que se quiere convertir). Esto último se
define con la sentencia #62, que define otra entidad tipo ifcSIUnit, en este caso para definir
los ángulos con la unidad radián. Volviendo a las últimas dos sentencias que definen las
69
unidades de medidas se puede comprobar que el tiempo y la masa se define con
segundos y gramos.
Si se continua con la siguiente sentencia (#65), se define la entidad ifcApplication. Esta
entidad define la aplicación (compatible con el formato IFC) con el que se ha creado este
modelo. Los atributos que tiene son: el nombre del desarrollador de la aplicación (debe de
ser miembro de BuildingSMART), la versión, el nombre de la aplicación y el ID. También se
define la organización definida en la sentencia #11.
Y por último se puede ver en la sentencia #66 la entidad ifcOwnerHistory, que es la entidad
que define el historial del proyecto. Como se puede ver esta sentencia apunta a otras dos,
la 19 y 65. Esta entidad define el propietario, aplicación de propiedad, estado, acciones de
cambio, última modificación (fecha y hora), último usuario que lo modificó, última
aplicación que lo modificó y fecha de creación.
Siguiendo con la definición del modelo en formato IFC, las siguientes sentencias del fichero
son:
Ilustración 61 - Líneas de código de la información general del proyecto (Elaboración propia)
7.2.3.3 El conjunto de propiedades
La primera sentencia #67 define el conjunto de propiedades mediante la entidad

ifcPropertySet. Esta entidad se utiliza para asignar un conjunto de propiedades (es la
señalada por una cadena de texto). La particularidad de la ifcPropertySet es que estas
entidades contienen todas las propiedades que pueden ser asignadas a una entidad
(clase).
Es decir, es una clase que contiene más clases que pueden ser asociadas a una clase
específica. Este esquema está basado y funciona como el lenguaje humano. Nosotros para
indicar el color, tenemos en nuestra cabeza un elemento ifcPropertySet, que contiene
distintos tipos de propiedades individuales, una de ella puede ser Pset_Color (que tiene
como definición de esta, los distintos colores que existen y puede identificar nuestro órgano
de visión). Entonces nuestro cerebro asocia un atributo de esta propiedad a otra entidad
(coche), y por tanto puede identificar el coche como un coche verde. Esto se utiliza para
mantener la entidad “propiedad” independiente del objeto que la ha adquirido y así poder
usarla tantas veces como se necesite.
Esta entidad tiene como atributos el conjunto de propiedades contenidas en el
ifcPropertySet, además de los atributos genéricos que obtiene por ser herencia24 de la clase
ifcRoot (que serán los atributos que tiene todas las entidades). En este caso, con el fin de
aclarar, los atributos que obtiene este elemento de herencia son: el ID y los atributos
asociados a la entidad (clase) ifcOwnerHistory.
24 Los objetos obtienen atributos también por herencia.
70
En este caso, al no existir este conjunto de propiedades que se quiere definir, es necesario
darle un nombre (cuya denominación se hace como una cadena de texto) que debe de
tener una codificación específica (Pset_XXX, donde XXX es la denominación del conjunto
de propiedades). En este caso, esa propiedad la ha establecido el visor al abrir el modelo
(ACA_Pset_Display_Set es el conjunto de propiedades) y no cumple con esta
recomendación de BuildinSMART, que dentro tiene propiedades individuales (definidas en
las sentencias #74 y #82).
La ifcPropertySingleValue es una entidad que se puede definir como propiedad tal y como
la definimos en el lenguaje humano. Es decir, es una cualidad que se le aplica a un objeto
y que solo puede tener un valor (de ahí el término Single Value). Es decir, si tomamos como
Property el nombre del fabricante del rail (en el ejemplo que se está desarrollando) solo
puede tener un valor único (solo puede haber un fabricante de un objeto), por lo que se le
aplicaría la propiedad definida por ifcPropertySingleValude llamada FABRICANTE y con el
valor del nombre del fabricante comercial:
(IFCPROPERTYSINGLEVALUE (‘Fabricante’,$,IFCLABEL('Metalurgia Inventada'),$)
En la Ilustración 55, se muestra un conjunto de propiedades y unas propiedades individuales,
asignadas al rail en el programa C3D, por lo que cuando en la lectura del archivo ifc
exportado se lleguen a esas líneas de códigos se podrá comprobar como el formato
guarda esta información y como puede ser editada desde el documento de texto.
La siguiente sentencia es la #90, que define la entidad ifcRelDefinesByProperties. Como se
ha visto antes, las propiedades se pueden juntar en un conjunto de propiedades (Property
Set) y este conjunto de propiedades puede ser asociado a un tipo de objeto. Por ejemplo,
el conjunto de propiedades que denominamos Pset_ConcreteElementGeneral que define
las propiedades generales comunes a los diferentes elementos de hormigón puede ser
aplicado a cualquier elemento que pueda estar hecho de hormigón. Bien, esta relación se
realiza con la clase ifcRelDefinesByProperties; esta entidad es una relación 1:N, es decir, que
una relación que asigna una entidad a muchas.
Como atributos propios tiene la referencia a la definición del conjunto de propiedades que
se quiere asociar al objeto. Además, hereda los atributos de ifcRoot, ifcRelDefines (que
referencia a los objetos a los que se quiere aplicar la propiedad) e ifcOwnerHistory. Por lo
que se puede ver en la sentencia, esta contiene un ID, y acude a las sentencias #66
(ifcOwnerHistory), #23 (objeto al que se le aplica el conjunto de propiedades, en este caso
el ifcProject) y #67 (conjunto de propiedades definidas)
7.2.3.3.1 El equipo de trabajo
En la sentencia siguiente, se puede ver la entidad ifcActor que define las personas que
participan en el proyecto. Como atributo tiene información sobre el actor y la referencia a
la relación que lo asocia con un objeto.
En la siguiente línea #105, se define la entidad ifcRelassignstoActor que relaciona objetos a
un actor. Como atributo tiene la sentencia donde se encuentra la información del actor y
su rol. Como herencia, obtiene del ifcOwnerHistory y del ifcRoot, además de asociarlo a un
objeto. Como se puede ver en nuestro ejemplo (ver Ilustración 62) en la exportación a fichero
IFC, se ha asociado “Ángel Díaz” como actor e “Ingeniero” como su rol, al objeto proyecto
(#23). Estos valores se han definido en la exportación de Civil3D.
71
Ilustración 62 - Asignación en la exportación IFC (Elaboración propia)
7.2.3.3.2 Localizacion del modelo

En la sentencia #109 se encuentra ifcSite. Esta entidad define la posición global del
proyecto. Esta posición, será definida acorde con el sistema de coordenadas globales que
se han definido al inicio del proyecto. La ubicación, se define con la entidad
ifcLocalPlacement. En este caso se define el punto (0.0.0) mediante una entidad
IFCAxis2Placement3D.
7.2.3.4 La estructura espacial del proyecto
Si se continua con el archivo IFC se puede encontrar las siguientes líneas de código donde
se va a definir la estructura espacial del modelo
Ilustración 63 - Líneas de código de la estructura espacial (Elaboración propia)
La estructura espacial del proyecto (según BuilsdingSMART) se muestra en la ilustración

siguiente
72
Ilustración 64 - Definición espacial (vía BuildingSmart.org)
La estructura espacial de un proyecto en formato IFC está formada por las 3 entidades:
ifcSite, ifcBuilding e ifcBuildingStorey.
ifcSite ya ha sido definido como el objeto que define la localización del proyecto, y la
entidad ifcBuilding da información sobre la situación del edificio25.
Aquí hay que recordar que el formato IFC nace para los modelos BIM de edificación, este
es el motivo por lo que para definir el proyecto es necesario definir la situación geográfica
del edificio y así tener una referencia en la que poder basar por ejemplo el sistema de
saneamiento o los accesos al edificio desde la vía pública.
Con esta entidad, también se define las alturas que tendrá el edificio, como a continuación
se puede ver, en la ilustración siguiente, el esquema diseñado por BuildingSMART
Ilustración 65 - Esquemas de pisos (vía BuildingSmart.org)
25El objeto ifcBuilding (edificio) no tiene por qué definir la localización de un solo edificio, si no que este objeto puede tener un “complejo de
edificios”
73
Para terminar de analizar la estructura espacial hay que ver la entidad ifcBuildingStorey.
Esta entidad tiene la información geométrica de los pisos. Es decir, la información
geométrica de las plantas de un edificio (elevación).
Estas tres entidades, adquieren su información geométrica con las clases
ifcLocalPlacement.
Para formar la estructura espacial, se relacionan las tres entidades citadas con
ifcRelAggregates, que es una entidad que relaciona partes de un todo.
ifcBuilding y ifcBuildingStorey además de formar parte de la estructura espacial también
forma parte del contenedor de elementos, que se relacionan con la estructura espacial
con ifcRelContainedInSpatialStructure. Esto quiere decir, que hay unos objetos que tienen
una localización (dada por el objeto ifcLocalPlacement) que tienen una localización
dentro del edificio y está en una de las plantas (esa relación viene dada por
ifcRelContainedInSpatialStructure).
Como podemos verificar en nuestro caso de estudio y volvemos al archivo del objeto RAIL,
se puede ver que contiene el ID, la referencia a ifcOwnerHistory, el nombre del proyecto,
una referencia a la sentencia #159 (que es una entidad IFCLocalPlacement, como se ha
comentado anteriormente)-
Por otra parte, en la sentencia #173 se puede ver la línea de código que vuelve a acudir a
la entidad IFCPropertySet para definir un nuevo conjunto de propiedades.
En este caso, este conjunto de propiedades predefinido por BuildingSMART, se llama

PSet_BuildingCommon, que define las propiedades #180, #188, #196, #204, #212, #220,
#228, #236, #244, #252 y #260.
Como se ha dicho antes, un conjunto de propiedades se puede definir a un tipo de objeto,
en concreto, este se establece a todas las instancias que pertenecen a la clase ifcBuilding.
Las propiedades (ifcPropertySinglevalue) que están dentro den este conjunto de
propiedades son:
• ID del edificio (Building ID), si el id asignado es permanente (IsPermanentID),
• ID (referencia dentro del proyecto),
• método de construcción (ConstructionMethod),
• protección contra incendios (FireProteccionClass),
• aspersores (SplinklerProtection, es booleano),
• aspersores automáticos (SprinklerProtectionAutomatic, también booleano),
• tipo de ocupación (OccupancyType),
• área reservada para el proyecto en bruto y neto (GrossPlannedArea y
NetPlannedArea),
• número de pisos dentro del edificio (NumberOfStoreys),
• año de construcción (YearOfConstruction),
74
• año de la última reforma (YearOfLastRefurbishment) y si es un edificio histórico
(IFCLandmarked).
Desde la sentencia #180 hasta la sentencia #260 son definiciones de las propiedades y su
valor asociado.
La siguiente sentencia, #268 es una entidad que relaciona el conjunto de propiedades con
un objeto concreto. Esta entidad es la ya definida ifcRelDefinesByProperties. Esta entidad
relaciona el conjunto de propiedades Pset_BuildingCommon con el objeto ifcBuilding.
En la siguiente sentencia se define otro conjunto de propiedades predefinidas
Pset_BuildingUse. Este conjunto de propiedades predefinidos para una entidad edificio
tiene como propiedades:
• MarketCategory,
• MarketSubCategory,
• PlanningControlStatus,
• NarrativeText,
• VacancyRateInCategoryNow,
• TenureModesAvailableNow,
• MarketSubCategoriesAvailableNow,
• RentalRatesInCategoryNow,
• VacancyRateInCategoryFuture,
• TenureModesAvailableFuture,
• MarketSubCategoriesAvailableFuture,
• RentalRatesInCategoryFuture.
Todas estas propiedades se definen en las sentencias del #277 a #333. La BuildingSMART
define el tipo de propiedad y el tipo de datos de estas propiedades, como se pueden ver
en la ilustración siguiente
Ilustración 66 - Propiedades de Pset_BuildingUse (Fuente: BuildingSmart)
Después se define el Pset_BuildingUseAdjacent. Este conjunto de propiedades contiene:

• MarketCategory
75
• MarketSubCategory
• PlanningControlStatus
• NarrativeText.
Análogamente la BuildingSmart las define como:
Ilustración 67 - Conjunto de Propiedades de Pset_BuildingUseAdjacent (vía BuildingSmart)
Se puede comprobar que son todos los conjuntos de propiedades definidos anteriormente.
Las propiedades de elevación son asociadas a esta entidad porque pertenecen al
esquema espacial comentado antes (son atributos del IFCBuildingStorey).
En la sentencia #458 se puede ver otra nueva entidad. Esta es la entidad
ifcBuildingElementProxyType.
Proxy es un objeto que no tiene información de un objeto específico. Entonces, esta

entidad, define una lista con los conjuntos de propiedades comunes a todos los elementos
proxy que están dentro de la entidad ifcBuilding. Por lo que, hay que entender que es
exactamente el proxy que pertenece a esta entidad (IFCBuildingElementProxy). Como se
ha definido antes, un elemento proxy es una entidad que no tiene información concreta
de ese tipo de entidad, por lo que, en este caso, esta entidad no tiene la información
concreta de una entidad perteneciente al IFCBuilding.
IFCBuildingElementProxyType define una lista de conjunto de propiedades que son
comunes a unos BuildingElementProxy. El atributo que se puede definir en esta entidad es
el tipo predefinido, para definir el tipo de proxy. Aquí se han definidos dos entidades, pero
solo la segunda adquiere un nombre (IFCBuildingElementProxy (1))
7.2.3.4.1 La geometría del modelo
Las siguientes líneas de código son sentencias que definen la geometría del modelo, que
carecen de interés ya que esa definición es un proceso automático y que modificarlo no
es el objetivo de este trabajo.
7.2.3.4.2 La informacion heredada del modelo
En la sentencia #16963 se puede encontrar:
76
En esta primera sentencia se encuentra la definición de un nuevo conjunto de propiedades.
Hay que aclarar, que este objeto de un rail ha sido extraído de una obra lineal, por lo que
este sólido hereda los conjuntos de propiedades que la obra lineal de Civil3D define.
En otro punto de este TFG se explicará como configurar este conjunto de propiedades.
El conjunto de propiedades definido es Información de forma de obra lineal y contienen las
propiedades que indica la sentencia en el paréntesis. Las propiedades que define son:
NombreCódigo, Lado, ElementoCoste, CódigoClasifiación, P.K. inicial del ensamblaje, P.K.
final de ensamblaje y Volumen. Todos están vacíos excepto este último. En esta entidad se
puede definir (además del nombre) el valor que tiene la propiedad. Puede estar vacío, y
las unidades si no se indican lo contrario son las que se han definido al principio del archivo
como predeterminadas. En este caso, utiliza IFCAmountOfSubstanceMeasure que es una
entidad que indica la cantidad de moles.
Como siempre, el siguiente paso es asociar este conjunto de propiedades a un objeto.
Entonces, en la sentencia #17034 ocurre esto. Se define el conjunto de la sentencia #16963
con el objeto de la sentencia #16877.
El objeto del tipo IFCBuildingElementProxy al que se le ha dado una localización. Se utiliza
este elemento de construcción, porque el rail no es objeto que esté dentro de los otros
elementos de construcción como puede ser un muro una viga etc.
Las siguientes sentencias define de la misma forma los conjuntos de propiedades que se
han enseñado al principio.
Por lo que una vez que se conoce como el formato organiza la información, ya tenemos el
contenido para desarrollar una aplicación que añada al formato IFC (como si fuera un
formato .txt) de forma automática propiedades.
7.3 Visión de la información

Para poder comprobar la calidad de datos de nuestros modelos es aconsejable la
utilización de programas visores de IFC, y también para verificar el resultado de la
exportación antes de proceder su envío a otras disciplinas, para así garantizar la
interoperabilidad. Hay muchos programas visores26 de IFC (más de 150, desde el que
patrocina la administración americana NIST hasta los más utilizados en España como es el
BIMvision o los más avanzados27 como BIMDATA.io), que admiten diferentes funciones de
IFC con diferentes niveles de efectividad, dependiendo de su concepción.
A continuación, vamos a estudiar la información del fichero ifc28, generado en la
exportación citada, mediante el visor de modelos señalado en el epígrafe ¡Error! No se
encuentra el origen de la referencia., donde se pueden acceder a las propiedades
26 Un visior de código abierto independiente muy manejable y altamente simplificado, para verificar modelos pequeños y medianos es el FZK
Viewer creado por el Instituto de Tecnología de Karlsruhe (KIT)
27 Basado en tecnología web que permite editar (incorporación / modifiaicon) los datos de los parámetros de las entidades (objetos) desde la
obra en tiempo real.

28 Modelo RAIL-RAIL-COPIA
77
(información) del modelo.
Ilustración 68 - Modelo del Rail con usBIMviewer (fuente: elaboración propia)
Para encontrar las entidades del modelo, se despliega en el menú de la izquierda de la

pantalla (en la herramienta SELECCIONAR -botón con la flecha-); mostrándose las
entidades que lo componen y entre ellas la entidad ifcProject.
Ilustración 69 - Clases del Objeto RAIL en us.BIMviewer (Elaboración propia)
Lo primero que nos muestra el visor, es el número del proyecto (005). Aquí se puede
comprobar las propiedades del objeto, como se puede ver en la ilustración siguiente.
En las ilustraciones siguientes se pueden verificar todas las propiedades del objeto que han
sido incorporadas por el programa C3D y que fueron definidas por el usuario.
78
Ilustración 70 - Propiedades del Objeto
Se puede ver que todas las entidades definidas anteriormente aparecen, además de
algunas añadidas por el visor (Conjunto de propiedades ACA_Pset_DISPLAY_SET).
Comprobamos en el visor, que siguiendo lo comentado en el epígrafe 7.2.3.4 el objeto
ifcBuilding está en el archivo y se encuentran el conjunto de propiedades señaladas,
asociadas al objeto RAIL. Si desplegamos esta opción se puede ver como aparece el
nombre de la entidad ifcBuilding que se ha introducido por el usuario `PruebaRailAutor’
Al activar la entidad ifcBuilding (pinchar en ella), se puede comprobar a la derecha de la

pantalla todas las propiedades asociadas a esta entidad. Por lo que deberían aparecer,
como conjunto de propiedades los definidos anteriormente.
79
Hay que tener cuidado, porque el visor introduce como propiedades los atributos propios y
heredados del esquema como podemos observar en las siguientes ilustraciones.
Ilustración 71 - Atributos propios y heredados (Elaboración propia)
Ilustración 72 - Propiedades del Modelo
7.4 Las clasificaciones en IFC

En los modelos BIM de calidad tenemos la necesidad de organizar sus elementos de forma
que se puedan gestionar la información de estos por otros programas o herramientas BIM
80
especialistas y diferentes de los programas de modelado (elaboración de presupuestos,
planificación de obras, estudio de visibilidad de carreteras, etc.).
La organización de los elementos por clases (clasificar) es necesaria para poder cumplir
con lo establecido en la norma UNE-EN ISO 19650-1; la cual además dispone que se utilice
uno de los sistemas de clasificación establecido. Y que dichos sistemas de clasificación se
realicen de acuerdo con los principios establecidos en la ISO 12006-2.
Para tener dicho sistema de clasificación, debemos establecer unos criterios de
clasificación, que podrá ser funcional, por forma, por materiales, por precio de obra, por
actividad de planificación, etc.; o bien recurrir a los sistemas estándares internacionales
como Uniclass, Omniclass, uniformat, Masterformat, ETIM, o nacionales como GuBIMClass.
A su vez los sistemas de clasificación29 pueden estar estructurados de diversas formas, pero
el más utilizado en el sector de la construcción en España son los estructurados bajo un es
que de tipo árbol (también denominados anidados).
Como establece el esquema IFC4 (2.017) y la norma UNE-EN ISO 16739 las clasificaciones
hay que entenderlas como un conjunto de clases (entidades) relacionadas entre sí
mediante relaciones de dependencias.
7.4.1 Usos de las clasificaciones

Siguiendo a Najera, J. yJimenez Abos, P en su trabajo [46], dichos autores establecen cinco
usos para las clasificaciones de elementos de un modelos BIM, que se pueden reducir a
cuatro:
i. Búsqueda y filtrado de información, especial necesidad de usuarios como los
técnicos de las administraciones públicas.
ii. Vinculación automática de elementos del modelo a las actividades de
planificación, para garantizar el programa de obra con el modelo BIM
iii. Vinculación automática de elementos del modelo a las partidas del presupuesto,
que unidas a las actividades de planificación puede utilizarse los modelo BIM para
aplicar a la gestión integrada de proyecto mediante la metodología del Valor
Ganado (EVA)
iv. Vinculación de información no grafica (documentos y fotografías) a elementos del
modelo, como actas de ensayos, manuales de mantenimiento, fotos de estado o
de incidencia, o fechas de inspección.
No obstante, el uso de clasificaciones de elementos BIM en España, uso con verdadera
eficiencia, está actualmente poco desarrollado entre otras razones por:
• Desconocimiento del estándar IFC
• Promotores públicos o privados, que bajo la influencia de los expertos BIM que
inmensamente provienen del sector de la Arquitectura, adaptan clasificaciones
internacionales que no tienen nada que ver con la forma de gestionar en España
tano los proyectos como las obras.
• El mercado de modelado BIM no está dominado por los usuarios BIM sino por los
desarrolladores de software BIM, que no apuestan aun por el potencial del formato
IFC por pura estrategia comercial.
29Como ejemplo un sistema de clasificación que se usa normalmente en España son los Bancos de Precios o los Pliegos de Prescripciones
Tesnicas -generales o particulares- de proyectos, los códigos de construcción como las Normas Tecnológicas de edificaicon (NTE).
81
7.4.2 Conceptos de Clasificación en IFC
Para la implementación de una clasificación diseñada por una propiedad pública o
privada, o bien por empresas ya sean consultoras, constructoras, o explotadoras de activos,
se ha de seguir lo establecido en el esquema IFC vigente y en la norma ISO 16739 de la
última edición.
Las especificaciones que han de seguirse son al menos dos:
• ifcClassification
• ifc ifcClassificationReference
La ifcClassification nos permite gestionar la información propia de la clasificación: fecha de
edición, descripción, etc.
La ifcClassificationReference, es la que recoge el nodo de cada clasificación asociada a
cada elemento del modelo.
La Ext_Reference, es la que sirven de soporte a la información de cada nodo, mediante las
propiedades: ID, Nombre, localización, descripción.
Hay que tener en cuenta que los elementos deben poderse clasificar en varias ramas de
esta clasificación, mediante relaciones “1 a N”; por ejemplo, tres precios unitarios -nodos-
(el del ‘encofrado`, el del ‘Hormigón HA-30´ y el del ‘Acero BS-500´) para un mismo
elemento (pilote de cimentación). El formato IFC permite para cada elemento
clasificaciones de nodo único y clasificaciones de nodos múltiples.
82
8 AUTOMATIZACIÓN DE PROCESOS DE
INFORMACIÓN
La construcción digital, tanto de un edificio como de una infraestructura civil, adquiere valor
añadido dentro del proceso integral del ciclo de una inversión en equipamientos o
infraestructuras (proyecto, construcción, mantenimiento y explotación de activos), en
función de la cantidad y calidad de la información que tenga los modelos BIM. Dicha
información de construcción (datos) se cuantifica y analiza en función de sus propiedades.
El modelado digital de construcción (BIM), que permite una representación rica de las
propiedades de la construcción (edificación y obra civil), crea una oportunidad para
realizar análisis de valor que se pueden automatizar como señala Zhang, Lu en su trabajo
[34].
Para satisfacer esta necesidad de añadir valor, que tienen los técnicos que realizan los
modelos BIM en los programas de modelado, en este trabajo se propone un método para
la adicción/extracción de información de diseño de un modelo BIM basado en el estándar
Industry Foundation Classes (IFC), mediante el desarrollo por el autor de este trabajo de
varios programas informáticos, escrito en código libre para cumplir con las especificaciones
OpenBIM.
El método se basa en dos elementos principales: (1) ampliar el esquema IFC para incluir las
entidades y conjuntos de propiedades adicionales que se necesitan para representar la
información necesaria en un modelo digital de la infraestructura civil; y (2) introducir y/o
extraer la información de diseño de un modelo BIM de forma automatizada30.
Como se ha comentado, una de las utilidades de los modelos digitales exportados a un
formato IFC es poder visualizar el modelo con programas distintos del programa del
modelado nativo; pero hay otra importantísima utilidad no explorada en profundidad y
anticipada por los trabajos de Zhang, L en [34] y de Najera y Jimenez en [46], como es la
de poder modificar todo el contenido de la información (datos de construcción) al
modificar el fichero IFC desde un programa de edición de formatos TXT31. Esto último abre
la posibilidad de la automatización de flujos de trabajo de tratamiento de la información de
construcción de los modelos 3D.
A continuación, se procederá a describir las etapas que se van a realizar en la inicial
propuesta del flujo de trabajo en la automatización del tratamiento de información
señalado:
• Diseñar un algoritmo que realice la búsqueda de Objetos (elementos) del modelo
BIM, verificando que todos ellos se le proporciona un identificador, a utilizar en las
etapas posteriores del proceso (Se generará un programa ejecutable con el nombre
Programa1_Nombes.py)
• Establecer la estrategia de lectura de las propiedades de los objetos
• Diseñar un algoritmo que realice la escritura de datos en los parámetros
(propiedades) de los Objetos (elementos) del modelo BIM. (Se generará un
programa ejecutable denominado Programa2_Enriquecimiento.py)
• Diseñar un algoritmo que realice la eliminación de propiedades y/o datos que el
30 Automatizacíon según la RAE: “Convertir ciertos movimientos en movimientos automáticos o indeliberados”

31 Como por ejemplo NOTEPAD+ o el BLOC DE NOTAS de Windows.
83
usuario o el cliente no quiera tener en una versión del modelo. (Se genera un
programa ejecutable Programa4_EliminarPSets.py)
8.1 Etapa Inicial: Búsqueda de objeto

Para que el enriquecimiento del modelo resulte efectivo es necesario que el algoritmo a
desarrollar sepa identificar al objeto que el usuario le quiere añadir la información.
El esquema IFC nos facilita para este fin, un concepto que es el atributo “ID” de IFCRoot; la
solución de utilizar un atributo de la clase ifcRoot es la única que nos garantiza que
aparecerá en cualquier objeto por la forma de concepción del esquema IFC.
La utilización del ID del objeto, sería un proceso válido para que el algoritmo determine
dentro del fichero IFC, a donde apuntar para modificar los datos; ya que el ID aparece en
todos los objetos y en todos los programas de visualización y de modelado. Pero es una
forma muy poco intuitiva para el usuario, ya que el ID es un código alfanumérico de muchos
caracteres complicado de memorizar (como ejemplo el siguiente ID de un objeto de un
modelo BIM real '2YrNZQSblvbm0000000IV1'). Por tanto, es recomendable, que la solución
debe pasar por otro atributo de la clase IFCRoot.
El estudio debe de tener en cuenta a los programas modeladores, ya que siempre el
modelo va a nacer de un programa en el que tiene que existir un identificador ID para
todos los objetos que son exportado al fichero IFC.
Por ello, el primer paso es analizar los objetos de un modelo BIM de infraestructura dentro
del programa C3D. Dentro de un modelo de infraestructura realizado por el programa
citado, nos encontramos varios objetos susceptibles de ser contenedores de información,
tales como: alineación, superficie, obra lineal, perfiles longitudinales, ensamblajes y sólidos.
Actualmente, solo se pueden exportar al fichero IFC, las entidades alineación (ifcAlignment)
y la entidad sólida. A su vez estos sólidos son de dos naturalezas, (i) extruidos de las
secciones transversales de la obra lineal y (ii) nacidos por la comparación de la superficie
generada para definir el movimiento de tierras y la cartografía. Los primeros sólidos
(extrusiones), tienen una identificación que indica que es producto de una obra lineal. Los
segundos que son los sólidos de comparación, no hay ninguna forma de identificarlo.
En el programa REVIT también utilizado para el diseño de determinadas obras civiles, hay
más opciones en la exportación de objetos creados en el programa. En este programa
existe la opción de exportar el nombre asociado al objeto al formato IFC. Este nombre, lo
exporta como un atributo del objeto heredado de IFCRoot, denominado “Nombre”. Por lo
que este parece una forma de identificar objetos que puede ser óptima ya que los objetos
en los que se le haya generado el nombre dentro del programa ya lo van a tener
incorporado.
Por tanto, de los dos programas de modelado más utilizados en ingeniería civil tenemos que
para los objetos creados en programa C3D estos deben de ser identificados por el
algoritmo (una vez que se ha desestimado la utilización del ID del esquema IFC). El algoritmo
deberá recorrer todo el archivo IFC en busca de los objetos, comprobar si tienen nombre
asociado y si no lo tiene generarle uno para la identificación a posteriori del usuario. En
concreto, el estándar IFC escribe el nombre en sentencia como la siguiente, utilizado la
clase ifcBuildingElementProxy.
#11500892=IFCBUILDINGELEMENTPROXY('2YrNZQSblvbm0000000IV1',#51,'Objeto 967',$,$,#11500917,#11500927,$,$);
El atributo NOMBRE se encuentra en la posición donde se puede leer ‘Objeto 967’; y en un
programa visor de IFC, aparece de la forma como propiedad de dicha clase, como se ve
84
la siguiente ilustración. Nótese el ID del esquema IFC también mostrado en dicha ilustración
como GlobalID. Cuando no hay asociado ningún nombre en el objeto aparece en la
posición de esa propiedad de la línea de código del fichero IFC, el carácter “$”.
Ilustración 73 - Nombre del Objeto según un visor de IFC (Fuente elaboración propia)
Por lo tanto, este será el sistema utilizado por el algoritmo; que tiene que ir objeto por objeto
y comprobar si ese objeto tiene asociado un nombre por el programa modelador o, sin
embargo, no tiene un nombre y el algoritmo debe darle un nombre.
El nombre que el algoritmo le dará al elemento, lo vamos a generar con la regla de
codificación: Objeto_ NNN, siendo NNN el numero -en orden creciente- del elemento
(objeto) que se encuentra. El nombre para dotar al elemento (“Objeto”) debe de ser
genérico para que funcione para cualquier modelo.
A continuación, se va a describir el algoritmo central y los subprocesos (funciones)
necesarios para conseguir el objetivo descrito.
8.1.1 Diseño del algoritmo central (Asignación de Nombres)

A continuación, y como primer paso, se va a diseñar el flujograma del algoritmo de
asignación de nombres a los elementos del modelo BIM bajo formato IFC (Ver Ilustración
74), para luego escribir el código del programa mediante el elegido lenguaje de
programación Python.
El algoritmo central comienza preguntado al usuario cual es el nombre del archivo IFC que
quiere abrir para su edición. En este caso el usuario debe indicar el nombre del archivo del
modelo BIM exportado desde el programa modelador con la extensión ifc; que se
recomienda que localice en la misma carpeta que el archivo Programa1_Nombres.py
(archivo ejecutable). Si estuviera en otra carpeta, deberá indicar también la ruta donde se
encuentra.
Una vez que el algoritmo central sabe el nombre del archivo a editar, el programa abre el
archivo en modo lectura para generar un vector, en el que cada elemento del vector será
una sentencia del archivo IFC. Después cerrará el archivo IFC para poder abrirlo luego con
otro modo.
Una vez que se ha cerrado el IFC, en el vector generado por el programa, se encuentran
las clases que pueden ser asignadas a los objetos tangibles en un IFC, como puede ser:
'IFCBUILDINGELEMENTPROXY', 'IFCWALL', 'IFCDOOR', 'IFCSLAB', 'IFCBEAM', 'IFCCHIMNEY',
'IFCCOLUMN', 'IFCMEMBER', 'IFCPILE', 'IFCPILE', 'IFCPLATE', 'IFCRAILING', 'IFCRAMP', 'IFCROOF'
85
Ilustración 74 - Flujograma de Asignación de NOMBRES
A continuación, el algoritmo central buscará estos objetos dentro del archivo IFC. Para ello,
he creado la función Búsqueda (que será utilizada en varias ocasiones) que busca un
86
objeto en cada una de las sentencias del formato IFC y devuelve el número de sentencia
en el que se encuentra, con un formato tal que este: #3423.
Es interesante que devuelva el número de sentencia porque es la forma en la que IFC
relaciona las sentencias, es su puntero. Por lo que guardar esa información es la forma más
eficiente encontrada para realizar las diferentes operaciones que hay que realizar
El flujograma de la función Búsqueda se muestra en la ilustración siguiente:
Ilustración 75 – Flujograma para la búsqueda de OBJETOS (elaboración propia)
Para buscar el número de sentencia de la definición de un objeto en un formato IFC hay

que seguir la Función Búsqueda. Para ello, a la función diseñada hay que darle el vector
“Vector_1” donde están guardadas las sentencias en las que el esquema IFC define el
objeto que tiene que buscar, por ejemplo, IFCBUILDINGELEMENTPROXY. La función
Búsqueda irá iterando por todos los elementos del vector, copiando su valor dentro de una
87
cadena. Por ejemplo, si el elemento i-ésimo del vector es #848928
IFCBUILDINGELEMENTPROXY( ETC), la función copiará esta sentencia en una cadena y
buscará el objeto dentro de esta cadena.
La forma en la que busca Python en una cadena es indicando en una variable bandera,
el byte donde se encuentra el primer carácter en el que coincide. Si no encuentra,
devuelve un -1. Por lo tanto, en la mayoría de las sentencias no va a encontrar la definición
de un objeto, y la función Búsqueda debe comprobar que la variable bandera sea distinta
de -1. Una vez que encuentra la sentencia donde está la definición del objeto, la función
Búsqueda empieza a copiar la sentencia en el elemento i-ésimo de un vector creado al
principio de la función (“Copia”). Copia la sentencia hasta que se encuentra con un ‘=’. En
ese momento sigue con la iteración. Así hasta que haya comprobado todos los elementos
del vector “Vector_1” que contiene todas las sentencias del formato IFC.
Una vez que finaliza la búsqueda, la función Búsqueda da como resultado el vector Dev,
donde están todos los números de sentencias en el que se ha definido un objeto del tipo
señalado en el archivo IFC.
Volviendo al algoritmo central, el vector Dev lo iguala a un vector llamado ”IDobjetosIFC”.
Por lo tanto, el algoritmo central va a llamar a la función Búsqueda para que localice la
sentencia de definición de todos los tipos de objetos mencionados anteriormente.
Cuando acabe, tiene que comprobar si en esta sentencia existe una definición del nombre
del objeto o no y en el caso de que no tenga nombre, escribir un nombre con el código
descrito más arriba. Para ello, en el algoritmo central se ha definido una segunda función,
llamada ID_IFC, que necesita los siguientes datos: Vector_1, ifcobjetos, nuidowner,
numeroobjetos. Estos datos entregan a la función ID_IFC:
• los objetos que hemos buscado antes,
• el número de la sentencia en la que se define la clase IFCOwnerhistory
• y el número de objetos que hay en el archivo IFC.
Por lo tanto, la función ID_IFC realiza el siguiente flujo de trabajo:
88
Ilustración 76 – Flujograma de la función ID_IFC (elaboración propia)
Por lo tanto, la función ID_IFC recibe el input desde el algoritmo central y empieza a iterar
con todas las sentencias en las que hay objetos del tipo señalado anteriormente. La función
ID_IFC buscará (mediante un método ya definido en Python) dos palabras clave.
Necesitando dos variables banderas. En la primera bandera se busca el número de
sentencia en el que se declara el objeto IFCOWNERHISTORY, ya que el nombre siempre se
define en el siguiente hueco en el que se señala la sentencia de definición de
IFCOWNERHISTORY.
Esto se puede ver en el ejemplo de antes:
#11500892=IFCBUILDINGELEMENTPROXY('2YrNZQSblvbm0000000IV1',#51,'Objeto 967',$,$,#11500917,#11500927,$,$);.
En esta línea de código se define el nombre, “Objeto 967” siguiendo a #51. La sentencia 51
89
es la siguiente:
#51= IFCOWNERHISTORY(#49,#50,$,$,$,$,$,1596036036);
Si el objeto no tuviera un nombre, en el siguiente hueco aparecería ‘$’. Una solución sería
decir: que si aparece ese carácter (“$”) el objeto no tiene nombre, pero esta solución no
es correcta, ya que podría tener un nombre y no una descripción por lo que en la sentencia
habría un ‘$’. Por lo que el algoritmo deberá encontrar que hay un carácter ‘$’ y que se
encuentra como mucho a 5 caracteres de diferencia del final del hueco que apunta a
IFCOWNERHISTORY. Este es el motivo del condicional doble con la operación lógica ‘AND’.
Si no existe un nombre (es decir aparece ‘$’, a una distancia del número de sentencia de
definición de IFCOwnerHistory no mayor de 5 caracteres.) la función ID_IFC le asociará un
nombre, que será “Objeto” y el número de veces que lo haya escrito más 1, para que los
nombres de los objetos a los que la función ID_IFC le haya puesto nombre sean del tipo:
Objeto 1, Objeto 2, Objeto 3, etc.. Además, apuntará el nombre en un vector que será el
vector de salida. Si el nombre ya estuviera definido, la función ID_IFC simplemente lo
copiaría en el vector. Al final, la función ID_IFC devolverá este vector al algoritmo central.
El algoritmo central, para acabar, pide al usuario el nombre (con extensión .txt, por ejemplo
Proyecto_057_2020.txt) del fichero en el que quiere que se introduzcan los nombres de los
objetos correspondientes. Posteriormente, escribe los nombres. Por lo tanto, el usuario ya
tiene una lista de nombres por los que, gracias a un visor, puede identificar perfectamente
cada objeto y así aplicar propiedades solo a los objetos que le interesen.
8.1.2 Código Fuente de Programa1_Nombres.py

Una vez explicado cómo funciona el programa Programa1_Nombres.py, se muestra el
código fuente en el lenguaje Python, mediante visualizaciones de este en el entorno de la
herramienta de programación (Ver Ilustración 77 y siguientes)
90
Ilustración 77 – Código Fuente (elaboración propia)
91
92
8.2 Etapa 2: Estrategia de lectura de propiedades
El fin de un proceso de automatización es que el usuario realice una acción que a priori es
repetitiva y monótona y está sujeta a posibles errores del factor humana, a una forma más
segura y sencilla que se realice mediante procesos lanzados por rutinas o herramientas
informáticas. Por este motivo, la introducción de parámetros en el modelo BIM en formato
IFC, a realizar por los programas desarrollados en este TFG debe de ser segura, sencilla y
rápida porque de lo contrario, no conseguiría el segundo objetivo marcado para este
trabajo de investigación.
El desarrollo de un programa para el objetivo señalado tiene que ser un proceso en el que
las acciones que realiza el programa deben de ir evolucionando en dificultad. Esto debe
de ser así por varios motivos, el primero porque estos desarrollos informáticos deben ser
realizados por ingenieros civiles que no son expertos en programación, pero que son los
únicos que saben los contenidos y funciones de los elementos de un modelo BIM civil. Y el
segundo motivo es que es más fácil abordar un problema si se compartimenta y se van
consiguiendo soluciones de cada una de las partes más pequeñas del problema en un
proceso lineal.
A continuación, se analizan dos procesos de entradas de datos, desarrollando el segundo
al ser más seguro al garantizar un mayor control sobre el proceso por parte del usuario, y
por tanto elevando la garantía de calidad del proceso.
Directa por consola
Por lo que la primera opción para que el programa guardara las propiedades definidas por
el usuario para el modelo BIM es una entrada directa mediante una pregunta por consola.
Es decir, el usuario debía escribir cada una de las propiedades y valor por pantalla. No hace
falta decir que este método es de todo menos automático
Mediante un fichero de datos
Este es un método más cómodo para introducir propiedades ya que se pueden agrupar la
información, siendo editable por el usuario con más control sobre los datos. Para ello se ha
optado por un fichero de datos en formato XLS o CSV
El usuario se va a encontrar en una hoja Excel, con tres opciones diferentes de introducir
parámetros:
a) La primera es un conjunto de propiedades y propiedades singulares que se
aplicarían a todos los objetos del modelo. Este grupo sería perfecto para definir
parámetros del proyecto o propiedades que deben de tener los objetos (como
fecha de certificación etc.).
b) Otra opción sirve para aplicar propiedades a grupos de objetos concretos. Es decir,
si el usuario quiere aplicarles las mismas propiedades a todos los pavimentos de un
modelo de infraestructura de carreteras, debe utilizar esta forma de proceder
c) La última opción que tiene el usuario es aplicar propiedades por tipo de objeto IFC,
por ejemplo, a todos los ifcWALL.
El usuario debe de utilizar la hoja Excel (Ver Tabla 1) suministrada por el autor del presente
trabajo, ya que el programa Programa2_Enriquecimiento.py lee datos en localizaciones
concretas de la estructura de directorios de la maquina donde se vaya a ejecutar, para
garantizar el control del funcionamiento del programa en esta versión beta de este. Esto es
una limitación de uso, pero a favor tiene que el usuario puede aplicar a los objetos tantas
propiedades como quiera añadiendo tantas filas como crea necesarias.
93
Tabla 1 - Fichero XLS de entrada de datos (elaboración propia)
En la anterior ilustración se muestra el cuadro de PROPIEDADES GENERALES. El fichero XLS

tiene una regla general para simplificar al usuario la gestión:
• solo se pueden añadir filas y siempre al final de las tablas.
• solo se pueden editar las celdas de color verde, que son las que llevan información
relativa al conjunto de propiedades o a las propiedades.
En este caso, el conjunto de propiedades se llamará Pset_Proyecto siendo posible cambiar
el nombre en versiones posteriores del programa. Todas las propiedades y los valores
pueden ser modificados. En el archivo IFC aparecerán como se ve en la ilustración
siguiente.
Ilustración 78 – Ejemplo de visualización de Datos (elaboración propia)
Para la selección por grupos de objetos se utilizará las fichas que están en la parte inferior
de la ficha mostrada anteriormente. Se han creado 22 fichas de grupos de objetos siendo
posible la expansión por parte del usuario. Para ello, debe de copiar y pegar una de las
fichas que ya están creadas justo al final (sin dejar espacios en blancos entre ellas) y el
programa automáticamente se adaptará, por lo que el usuario podrá hacer tantos grupos
de objetos como desee. La forma en la que hay que adjuntar la información será la
mostrada en la tabla siguiente.
94
Tabla 2 - Ficha de grupo (elaboración propia)
El funcionamiento de esta ficha GRUPOS DE OBJETOS es muy similar a la ficha de

PROPIEDADES GENERALES. En este caso, la selección de objetos la realiza el usuario
indicando en “Nombre en IFC” el nombre de todos los objetos en los que quiere que se
aplique las propiedades.
La forma de que en esa celda indicar los objetos será la siguiente, si el usuario quiere
añadirle un conjunto de propiedades a unos objetos concretos.
a. El usuario debe identificar el nombre del objeto en un visor, este nombre
puede ser el generado por un modelador o por el programa ADM_DATA_IFC.
Como ejemplo, imaginemos que el usuario quiere agregar propiedades a los
objetos identificados en el visor de archivo IFC: Pozo de registro 1, Terraplén y
Berma; entonces, el usuario deberá escribir en la celda “Nombre en IFC” lo
siguiente: Pozo de registro 1; Terraplén; Berma.
b. Deberá indicar en “Número de objetos” el número de objetos que quiere
seleccionar; en este caso, 3.
c. Debajo de “Nombre en IFC” el usuario puede añadir cualquier tipo de
propiedad y de valor, y tantas como quiera. Siempre se debe de asegurar
que en “N.º de Propiedades” aparece el número de propiedades que ha
escrito. Es posible que, si introduce más filas de propiedades que las
indicadas, este sumatorio se pare. La solución, pasa por entrar en la fórmula
de la celda y añadir las filas que se han quedado fuera de la fórmula.
La última ficha en la que el usuario puede agregar propiedades es la ficha de SELECCIÓN
DE OBJETO POR TIPO DE OBJETO IFC. Es decir, el usuario puede añadir propiedades a todos
los objetos que sean de un mismo tipo (como por ejemplo IFCBUILDINGELEMENTPROXY). La
ficha se muestra en la siguiente tabla.
Tabla 3 - Ficha de tipo de objeto (elaboración propia)
95
En este caso, el usuario debe indicar en la celda justo por debajo de “TIPO”, el tipo de objeto
al que le quiere aplicar las propiedades. Si justo después del nombre el usuario escribe un
paréntesis (como se puede ver en la imagen) el programa aplicará las propiedades con
mayor rapidez ya que eliminará algunas sentencias que pueden llevar a confusión.
8.3 Etapa 3: Escritura de Datos

Replicar el flujo de trabajo que realiza un programa modelador en la exportación del
modelo a un formato IFC, será la base elegida para formular el algoritmo central de este
segundo programa. El flujograma del algoritmo central este segundo programa se muestra
en la Ilustración 79
El algoritmo central de este segundo programa comienza pidiendo al usuario que indique
el nombre del archivo IFC que quiere enriquecer y el archivo Excel donde guarda la
información. Ambos deben de tener la extensión también indicada. Es recomendable, que
estos archivos estén en la misma ruta de guardado que el segundo programa
Una vez que el usuario indica estos archivos, el algoritmo central de este segundo programa
lee el IFC y lo guarda en un vector llamado “Vector_1”, de tal forma que cada sentencia
del archivo IFC queda almacenada en un elemento del vector. Luego, el algoritmo central
de este segundo programa crea la variable CONTADOR y le da un valor inicial de 1.000.000
(Es un valor inicial32). Con esta acción se crea el número de sentencia de cada sentencia
de propiedades que luego va a escribir el segundo programa
El siguiente paso, es buscar el número de sentencia en el que se define la clase
IFCOWNERHISTORY, para ello, se crea la variable OBJETO dándole de valor la cadena
‘IFCOWNERHISTORY, llamando a la función BÚSQUEDA (ya mencionada anteriormente, en
el primer programa. Es la misma función) que busca en todas las sentencias IFC este nombre
y copia su número de sentencia devolviéndolo al algoritmo central de este segundo
programa. Esta cadena que refleja el número de sentencia se almacena en Nuidowner.
Lo siguiente que hace el algoritmo central de este segundo programa es definir la variable
CONJUNTO, que contiene la cadena ‘Pset_’. Esta variable está preparada para que lea del
fichero de datos XLS, el nombre del conjunto de propiedades que el usuario le quiere dar
al conjunto de propiedades y lo añada a la cadena, quedando, por ejemplo:
Pset_Pavimento.
32Todas las sentencias de IFC tienen al principio la siguiente cadena: #Número, siendo el número cualquier valor. Por lo tanto, le doy una
condición inicial alta para que no haya conflicto.
96
Ilustración 79 - Flujograma para ENRIQUECIMIENTO DE PROPIEDADES (Elaboración propia)
97
98
El algoritmo central de este segundo programa, a continuación, abre el archivo de datos
99
XLS y selecciona la hoja inicial como hoja activa. Lo primero que el algoritmo central de
este segundo programa va a guardar son las propiedades que son aplicadas a todos los
objetos del archivo IFC. El archivo de datos XLS contiene una celda donde escribe el
número de propiedades de proyecto o comunes que el usuario ha escrito. El algoritmo lee
este número y genera dos vectores, uno para los nombres de las propiedades y otro para
los valores de las propiedades. Estos vectores tienen de longitud el número de propiedades
que el algoritmo central de este segundo programa ha leído del Excel. A continuación, el
algoritmo central de este segundo programa comienza a iterar copiando de cada celda
el nombre y el valor en los vectores. Para ello, le he indicado al algoritmo central de este
segundo programa donde debe de buscar estas propiedades, indicando la localización
de las celdas.
Una vez que termine, tendrá guardado toda la información en los vectores y más adelante
las añadirá al archivo IFC. El siguiente paso es seguir extrayendo la información que el
usuario ha dejado en el Excel. Las siguientes fichas que el usuario ha generado son fichas
para aplicar datos a grupos de objetos específicos.
La forma en la que se ha diseñado el archivo de datos XLS permite que este segundo
programa encuentre las fichas de una forma sencilla. Cuando el usuario escribe una ficha
de datos, debe de indicar el número de objetos y nombre a los que les quiere aplicar estas
propiedades. Esta información se copia en un lugar muy concreto de la ficha. La
información de a cuantos números de objetos se le va a añadir propiedades por ficha se
encuentra siempre en la misma columna, esto implica que, el algoritmo puede recorrer esa
columna e ir encontrado que ficha tiene información útil y que ficha no.
Por ello, el algoritmo central de este segundo programa calcula cuantas filas escritas tiene
el archivo de datos XLS. Entonces, empieza a iterar en la columna B, todas las filas. El
algoritmo central de este segundo programa lee cada una de las celdas de la columna B
y busca la ficha en la que se dé la siguiente condición:
Ilustración 80 – Inicio de Ficha (elaboración propia)
En las fichas donde se encuentren objetos a los que aplicar propiedades aparecerá un
número (el número de objetos) justo debajo de la celda que contiene “N.º Objetos”. Esta
celda, nos va a servir como referencia para localizar toda la información organizada en la
ficha. Esto es así, porque el algoritmo central de este segundo programa va a ir recorriendo
esta columna hasta que se encuentre en la celda i la cadena “N.º Objetos”, cuando se la
encuentre va a mirar en la celda de debajo y va a comprobar que el número es distinto de
0. Esta es la confirmación inequívoca de que el usuario quiere utilizar esta ficha, por lo tanto,
el algoritmo central de este segundo programa comienza a leer la información. Si se
cumple la operación lógica AND: Contenido celda i= “N.º Objetos” AND Contenido celda
i+1 distinto de 0, lo siguiente que lee el algoritmo central de este segundo programa es el
número de objetos que hay en la ficha, para crear un vector vacío de esta longitud
Luego, el algoritmo central de este segundo programa se irá a la celda donde se indica el
nombre de los objetos. Encuentra esta celda porque el usuario no debe cambiar la
configuración del Excel, por lo tanto, esta información siempre se encuentra en la misma
100
celda relativa a la celda donde se encuentra la cadena N.º Objetos. Todas las fichas tienen
las mismas coordenadas locales, eso permite homogeneidad.
Tabla 4 - Ficha de ejemplo (elaboración propia)
Tabla 5 - Coordenadas locales de la información en las fichas (elaboración propia)
Por lo tanto, el algoritmo central de este segundo programa siempre va a tener guardada
la fila en la que se encuentra una celda con N.º Objetos dentro de una ficha válida, por lo
tanto, este va a ser el origen de coordenadas locales. El número de objetos siempre va a
estar en la fila i+1 y en la misma columna. Python, entiende que las columnas se denominan
por números, comenzando por 0 (la primera fila también es la fila 0).
Los nombres de los objetos aplicados estarán en la celda con una localización relativa (i-
3,3) (primero se indica la información de las filas y después las columnas). Esto ocurrirá en
todas las fichas (siempre y cuando el usuario no modifique la localización relativa de estas.
Por eso es importante, que bajo ningún concepto el usuario añada columnas.
El algoritmo central de este segundo programa acudirá a este punto y copiará la
información en una variable llamada “listainput”. Esta información, será una cadena del
tipo: “Pozo de registro 1;Terraplén;Berma;”
El algoritmo central de este segundo programa debe disgregar esta información en objetos
individuales para poder tener cada objeto por separado y encontrarlo dentro del archivo
IFC. Para ello, el algoritmo central de este segundo programa va a recorrer toda la cadena
e irá copiando todos los caracteres que se encuentre hasta que llegue a un carácter del
tipo “;”. En ese caso, parará y volverá a comenzar a copiar a partí de ahí en otro elemento
de un vector. Cada objeto se encontrará en un elemento del vector (el vector se llama
“listobjeto”). Para el algoritmo central de este segundo programa es la mejor forma de tener
la información guardada ya que puede ir recorriendo el vector con suma facilidad.
El algoritmo central de este segundo programa, a continuación, busca la sentencia de
definición de los objetos que se encuentran en la ficha, para ello recorre el vector y llama
a la función Búsqueda. Esta devuelve el número de la sentencia, esta información es
necesaria para que al escribir la relación del conjunto de propiedades con el objeto apunte
101
a la sentencia de definición.
Igual que ocurre en con las propiedades comunes, el algoritmo central de este segundo
programa debe de extraer la información que el usuario ha dejado en el Excel. Para ello,
iterará por todos los objetos y llamará a la función “Lectura_Prop” encargada de guardar
en los vectores los nombres y valores de las propiedades. Esta función tiene el siguiente
flujograma
Ilustración 81 - Flujograma de la Función Lectura_Prop (Elaboración propia)
La función Lectura_Prop ira escribiendo en cada elemento de los vectores la información

del Excel. Una vez que ya tenga los vectores completos, el algoritmo central de este
segundo programa escribe en el IFC la información. Para ello, acude a la función “P_set”.
La función P_Set, tienen como entrada el número de sentencia en la que se define la clase
IFCOWNERHISTORY, el ID de la sentencia en la que se define el objeto en concreto de la
iteración, la variable “CONTADOR”, los vectores de las propiedades y la variable que
almacena el nombre del conjunto de propiedades. Antes de que llegue a la función P_set,
el algoritmo central de este segundo programa ha copiado el nombre de la ficha para
renombrar el nombre del conjunto de propiedades. La función P_set devuelve la variable
“CONTADOR” actualizada.
Cuando el algoritmo central de este segundo programa llama a la función P_Set le
devuelve la variable CONTADOR. La función P_set va añadiendo sentencias a las que le
genera un número de sentencia que será igual al contador, y lo actualiza sumando uno.
Una vez que termina, la función P_set exporta este número al algoritmo central de este
102
segundo programa para que la siguiente vez que se llame a la función se escriba las
sentencias con números concatenados. El flujograma de la función P_set es el siguiente:
Ilustración 82 - flujograma de la función P_set (elaboración propia)
103
Esta función es la base de este segundo programa. Es la encargada de recoger la
información ya guardada por el algoritmo central de este segundo programa y escribirla
en el IFC. La base de su diseño es el funcionamiento del esquema IFC para añadir conjunto
de propiedades y propiedades.
Ilustración 83 - Esquema de propiedades en el IFC (elaboración propia)
La función P_set debe de crear un conjunto de propiedades por cada llamada. Para
generar la cadena que se convertirá en la sentencia que define el conjunto de
propiedades lo primero que debe de hacer la función P_Set es darle un número de
sentencia. Por ello, la función recibe el número “contador”. Genera un vector tan grande
como propiedades haya que introducir, más 1. En el elemento i de vector, guardará el
número de sentencia, de la sentencia i, que será igual a contador + i.
La sentencia de definición del conjunto de propiedades necesita el IDIFC, el número de
sentencia de definición de IFCOWNERHISTORY y los números de sentencia, el nombre del
conjunto de propiedades y los números de las sentencias que definen cada propiedad.
Por lo que la función P_set debe de definir lo primero el IDIFC. Este ID es un atributo de
IFCRoot heredado por todos los objetos del esquema IFC. Este atributo se genera de una
forma automática siguiendo unas reglas definidas por la BuildingSMART. Para que el
algoritmo no aumente en complejidad, se ha decidido coger un ID e ir sustituyendo las
últimas cifras por el número de sentencia y así simplificar el contenido.
Por ello la función P_set, crea la variable IFCID, que es un código alfanumérico y le suma el
número de sentencia. (En el caso del id del conjunto de propiedades el número será el
primer elemento del vector cont.
Una vez que se ha definido esto el algoritmo comienza a construir la cadena del conjunto
de propiedades, esta comienza con un ‘=IFCPROPERTYSET( y va añadiendo el id de IFC y el
número de sentencia de la definición de IFCOWNER.
La siguiente sentencia que define la función P_Set es la sentencia de la clase de relación.
Esta sentencia tendrá como número de sentencia el número más alto. La cadena se define
escribiendo =IFCRELDEFINESBYPROPERTIES(, añadiéndole el id de IFC, el número de
sentencia de la definición de IFCOWNERHISTORY.
El resto de la sentencia se escribe como he indicado en la imagen anterior, teniendo en
cuenta que la función P_Set tiene que escribir el número de la sentencia de definición del
objeto al que se le quiere aplicar las propiedades (dada desde el algoritmo central) y el
número de sentencia de definición de la clase IFCPROPERTYSET, que es el primer número
del vector Cont.
104
Ahora solo falta crear las propiedades, para ello la función P_set itera para poder escribir
tantas sentencias como propiedades haya. En cada iteración la cadena recoge el nombre
y el valor correspondiente en los vectores dados por el algoritmo central de este segundo
programa. Una vez que estén todas las cadenas definidas, se escriben dentro del archivo
IFC. Para ello, se escribe primero el número de la sentencia y después se le añaden las
cadenas.
Volviendo al algoritmo central de este segundo programa, el siguiente paso es escribir en
el archivo IFC las propiedades comunes a todos los objetos del archivo. Para ello, el
algoritmo central de este segundo programa debe de buscar el número de la sentencia
que define a cada uno de los objetos que existen en el archivo. Para ello, genera un vector
con todos los tipos de objetos que puede haber en un IFC, objetos que son tangibles y
aplicables en una obra (no busca por ejemplo el objeto IFCOBJECT). Una vez que busca
todos los números de sentencia, calcula cuantos objetos hay que itera para llamar a la
función P_set con cada uno de los objetos que ha encontrado y aplicarle las propiedades
(nombre y valor) definidas anteriormente.
Lo único que falta para terminar este segundo programa es llevar al final las sentencias
escritas, la línea de código de final del archivo: ENDSEC 'END-ISO-10303-21;'. La forma en la
que se puede conseguir esto es sustituir las sentencias ya existentes por espacios en blancos
y añadirlas al final.
Este segundo programa escrito en Python se muestra en las ilustraciones siguientes.
105
Ilustración 84 - Código fuente del Algoritmos de ESCRITURA DE PROPIEDADES (elaboración propia)
106
107
108
109
8.4 Etapa 4: Eliminación de Propiedades y/o valores
Para que el usuario tenga mayor comodidad a la hora de utilizar el segundo programa:
Programa2_Enriquecimiento.py se decidió crear el programa: “Programa4_EliminarPsets”
que eliminase por completos todos los datos introducidos al modelo BIM. A la hora de
exportar el modelo a un fichero IFC desde un programa modelador se crean muchas
propiedades que al usuario puede no interesar o el usuario puede crear por error algunas
propiedades.
Este tercer programa es muy sencillo, pero es muy necesario para aumentar la garantía de
calidad del proceso y para optimizar el tiempo de usuario dedicado a la gestión de la
información.
Ilustración 85 - Flujograma de Programa4_EliminarPSets (elaboración propia)
110
El algoritmo central de este tercer programa abre el archivo IFC que el usuario le indica y lo
vuelca en un vector. Después, el algoritmo central de este tercer programa recorre este
vector buscando en cada elemento del vector las palabras relacionadas con los datos en
IFC: IFCPROPERTYSET, IFCPROPERTYSINGLEVALUE y IFCRELDEFINESBYPROPERTIES
Si encuentra alguna de estas palabras quiere decir que esa sentencia hay que borrarla, por
lo que el algoritmo central de este tercer programa guarda en ese elemento del vector un
carácter vacío. Para terminar, el algoritmo central de este tercer programa es más sencillo
sobrescribe el archivo IFC volcando el vector (donde ya no existen sentencias de
propiedades). EL código fuente en Python del algoritmo central de este tercer programa
se muestra en las ilustraciones siguientes.
Ilustración 86 - Código fuente del algoritmo central de este tercer programa (elaboración propia)
8.5 Test de Funcionamiento

Para comprobar si el conjunto de algoritmos funciona con normalidad se ha diseñado una
prueba mediante una fase de pruebas con distintos modelos corrigiendo posibles errores.
8.5.1 Prueba 1 – Tramo de Apartadero Ferroviario del Puerto de Sevilla

La primera prueba se ha realizado con un modelo de ferrocarriles desarrollado en Civil 3D
111
(Ver Ilustración 87) denominado OF_37_SOLIDOS_VIA3_v11a.ifc. Este modelo BIM es
obtenido como resultado de la extracción de sólidos de una obra lineal.
Ilustración 87 – Modelo de Infraestructuras Ferroviarias (Elaboración beca de prácticas en TeamBIM Civil S.L.)
Este modelo tiene como objetos: los sólidos del movimiento de tierra, el sólido que
representa la plataforma de la vía, el sólido del balasto, los sólidos de las traviesas, de los
raíles y de los postes de que sujetan las catenarias.
Todos estos objetos, al ser exportados a IFC se van a convertir en elementos
IFCBUILDINGELEMENTPROXY sin nombre. Para comenzar la prueba, se procesa el primer
subprograma. Este primer algoritmo es el que realiza la búsqueda de objetos, ejecutándose
con el subprograma PROGRAMA1_NOMBRES.PY
Ilustración 88 – Algoritmo de búsqueda de objetos
Al iniciarse este algoritmo, se pregunta qué modelo IFC se quiere añadir y en que archivo
de salida quiere el usuario que guarde la información de los objetos.
112
Ilustración 89 – Ventana emergente de inicio del PROGRAMA1_NOMBRE.PY (elaboración propia)
El archivo generado por el algoritmo es el que se muestra en la Ilustración 90

Ilustración 90 - Lista de objetos
Por lo tanto, estos son los objetos que hay en el modelo. los dos primeros son aquellos cuyos
nombres lo ha generado el programa modelador C3D, y el resto de los objetos son los que
el algoritmo le ha dado el nombre. En el visor de IFC podemos ver que objetos son los que
tiene el modelo BIM, y podemos determinar aquellos objetos a los que hay que añadirle
propiedades.
Ilustración 91 – Objetos del Modelo BIM ferroviario procesado por el algoritmo. (elaboración propia)
El siguiente paso es añadir propiedades mediante el algoritmo desarrollados, y para ello

hay que utilizar el archivo de datos editado por el usuario (archivo XLS) en el que se debe
añadir las propiedades a los objetos seleccionados.
Las propiedades para añadir al modelo BIM en formato IFC que utilizaremos en esta prueba
113
se puede ver en la tabla siguiente.
Tabla 6 -Tabla de datos a añadir - Prueba 1 (Elaboración propia)
Una vez concluido el proceso de carga de datos en el archivo XLS, ejecutamos el

subprograma de ENRIQUECIMIENTO (denominado PROGRAMA2_ENRIQUECIMIENTO.PY).
Ilustración 92 – Subprograma de Enriquecimiento de datos
Este programa muestra la siguiente ventana de consola para indicarle el nombre del fichero
ifc, que se va a procesar.
114
Ilustración 93 – Ventana emergente (elaboración propia)
Cuando el subprograma termina su ejecución, se cierra esta ventana. Procesado el IFC este
debe de haber adquirido todo el esquema de propiedades que el usuario requiere;
cuestión que verificamos, por lo que forma de comprobar la ejecución correcta del
subprograma es acudir a un visor y cargar el fichero de referencia
OF_037_SOLIDOS_VIA13_v11a.ifc que ya está enriquecido con parámetros de Proyecto, de
Balasto, de Carril del Eje 3 y de Catenaria; como se muestra en las siguientes ilustraciones.
Ilustración 94 - Fichero enriquecido (Fuente elaboración propia)
115
Por lo que la prueba ha sido satisfactoria, dada que la ejecución ha sido completada
correctamente y se presenta el resumen de resultados de proceso: tiempo de ejecución,
números de objetos (16) y de propiedades añadidas (288)
Ilustración 95 – Resumen de la prueba (elaboración propia)
Actualizado 29/08/2020
Inicio de Prueba 11:56

Final de Prueba 12:01
Nº De Objetos 16
Nº de Pset Añadidas 21
Nº Propiedades Añadidas 288
Tipo de Modelo Infraestructuras de Ferrocarriles
Con objeto de entregar al cliente el fichero etc., sin datos para poderlo usarlo en la licitación
pública como modelo BIM base de licitación, se procede mediante el otro subprograma a
limpiar los datos para poder añadir las propiedades que el cliente (administración o
contratista en su oferta de licitación). Para ello pruebo el algoritmo de ELIMINACIÓN, que
es el siguiente PROGRAMA4_ELIMINARPSET.PY.
Ilustración 96 – Icono del algoritmo de Eliminación (elaboración propia)
Ejecutándolo como vemos desde su consola como se ve en la siguiente ilustración
116
Si volvemos a acudir al visor, vemos que ya no hay propiedades en el modelo IFC
Ilustración 97 – Modelo BIM sin Propiedades (elaboración propia)
8.5.2 Prueba 2 – Pequeño Edificio

El siguiente paso es probarlo los algoritmos con un modelo que no sea de infraestructura
(uno de edificación) realizado con otro programa modelador que tiene una gestión de
objetos muy distinta.
El modelo BIM se ha elegido del repositorio de la Universidad de Auckland, y este realizado
con el programa REVIT; y se ha exportado a un nuevo fichero AAA.ifc
Ilustración 98 – Modelo de Edificación (Fuente: repositorio de la Universidad de Auckland)
Como el programa de modelado Revit, ya dota a los objetos de un nombre, este se

transferirá al exportarlo a formato IFC. Si se ejecuta el primer programa, aparecen la
ventana de comandos y genera un archivo de texto con los objetos que hay en el modelo.
Ilustración 99 – Ventana emergente del primer programa (elaboración propia)
117
El programa Programa1_Nombres.py ha encontrado un total de 100 objetos. Ahora se

ejecuta el segundo programa para añadir las siguientes propiedades, que como usuario
hemos preparado en el archivo de datos XLS (Fichero de datos DUPLEX.xls)
Tabla 7 - Fichas de propiedades del archivo de datos (Elaboración propia)

Prop. Generales Propiedad Valor
Este formulario es para añadir Empresa Constructora Constructora S.L.
propiedades a todos los objetos Empresa Proyectista TEAMBIMCIVIL S.L.
del modelo Empresa Promotora Particular
Empresa Cordinadora Seguridad Y Salud TEAMBIMCIVIL S.L.
Localización Avenida de la Constitución/ Quintana de la Serena
Descripción Obra de edificación particular
Fase Obra comenzada
Normativa apicable CTE
Fecha Inicial Obra \Agosto 2020\
Fecha Final de Obra Por definir
Fecha de revisión
Fecha de ensayo
Fecha de Certificado
Fecha de Construcción
Fecha de llegada
Estado del objeto En espera para construir
Cerramiento_PlantaBaja Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY

Tipo de Objeto 1 2 3 4
Tipos Distintos Número de Objetos 4
1 Descripción
Nº De Propiedades Nombre en IFC Basic Wall:Exterior - Brick on Block:138310;Basic Wall:Exterior - Brick on Block:138237;Basic Wall:Exterior - Brick on Block:138157;Basic Wall:Exterior - Brick on Block:138062;
9 Planta Blaja
Material del muro Ladrillo cerámico
Nº OBJETOS Existen ventanas Si
4 Material aislante Polietileno expandidoi
Material de enlucido
Ancho de camara de Aire 0.2 metros
Pintura Pintura de exterior
Color Gris
Marca Por definir
118
Cerramiento_PrimeraPlanta Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY
Tipo de Objeto A 2 3 4
1 Descripción
Nº De Propiedades Nombre en IFC Basic Wall:Exterior - Brick on Block:143410;Basic Wall:Exterior - Brick on Block:143590;Basic Wall:Exterior - Brick on Block:143534;Basic Wall:Exterior - Brick on Block:143478;
9 Planta Primera Planta
Material del muro Ladrillo cerámico
Nº OBJETOS Existen ventanas Si
4 Material aislante Polietileno expandidoi
Material de enlucido
Ancho de camara de Aire 0.2 metros
Pintura Pintura de exterior
Color Gris
Marca Por definir
Cubierta_Plana Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY

Tipo de Objeto 1 2 3
1 Descripción
Nº De Propiedades Nombre en IFC Basic Roof:Live Roof over Wood Joist Flat Roof:184483;Basic Wall:Interior - Partition (92mm Stud):144684;
7 Tipo de Cubierta Cubierta plana
Pendiente 1%
Nº OBJETOS Material impermeable Lámina de polietileno
2 Drenaje Drenaje en cara norte
Situación de canalón Cara norte
Cubierta transitable No es transitable
Complementos Preparado para instalación de placas solares
Puertas Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY

Tipo de Objeto 1 2 3
1 Descripción
Nº De Propiedades Nombre en IFC M_Single-Flush:1250mm x 2010mm:1250mm x 2010mm:146596;M_Single-Flush:1250mm x 2010mm:1250mm x 2010mm:146678;M_Single-Flush:0762 x 2032m
9 Número de Puerta --
Material Madera de Pino
Nº OBJETOS Carpintería Carpintería Hidalgo S.A.
14 Tiempo de transporte 2 días
Inicio de transporte --
Construcción al final de obra --
Tamaño 2x1.5
Zona de almacenamiento Calle la Azaña
Tipo Propiedad Valor

IFCWINDOW( 0 0
Marco Metálico
Dimensiones 2x2 m
Arriba, debajo de tipo indica Material de marco Aluminio
un tipo de elemento dentro Pintura Exterior
de IFC, para aplicar Color Blanco
propiedades a todos los Cristal Vidrio Climalite
elementos de ese tipo Cámara de aire Si, intervidrio
Los tipos de elemento pueden Cerramiento Tipo A
ser por ejemplo: Persianas No
IFCBUILDINGELEMENTPROXY( Hojas 2, correderas
IFCWALL(
IFCDOOR(
IFCSLAB(
Despues del nombre, escriba
un paréntesis para que la
busqueda sea más rapida
Estas propiedades se añadirán al ejecutar el segundo programa

Ilustración 100 – Ejecución del segundo programa (elaboración propia)
Análogamente, para comprobar el correcto del programa, se acude a un visor. Pero

ampliando la prueba a dos tipos de visores: (i) un visor de escritorio en ordenador de portátil
personal y (ii) en un visor web para comprobar la visualización en tabletas.
119
Ilustración 101 – Visualización en BimDATA.io y us.BIMviewer (elaboración propia)
120
Por lo que el resultado es muy satisfactorio, siendo posible su visualización desde una
tableta; fundamental para conseguir la implantación de la metodología BIM en la gestión
en obra (Modelo BIM AsBuilt).
Para resumir esta prueba se presenta los resultados: 16 objetos y 2.052 propiedades.
Ilustración 102 – Resumen de la prueba (elaboración propia)

Nº De Objetos 16
Tipo de Modelo Edificación
8.5.3 Prueba 3 – Tramo parcial del modelo BIM de la Vte. de BEAS

La siguiente prueba se va a realizar sobre una parte del modelo BIM completo desarrollado
en este Trabajo de Fin de Grado y que se ha expuesto en el epígrafe 5 del presente trabajo.
Se ha elegido tramo parcial solo un eje de la Vte. de Beas, generando un modelo “ad hoc”
para esta prueba (Variante de Beas.ifc), y que podemos ver en las siguientes ilustraciones.
121
Ilustración 103 – Modelo BIM de un tramo de la Variante de Beas en formato IFC (Elaboración propia)
Este es un modelo de carreteras, de dimensiones reducidas para comprobar el

funcionamiento de los programas. Ejecutando Programa1_Nombres.py
Ilustración 104 – Ejecución del Primer programa (elaboración propia)
122
Se puede ver que hay 63 objetos, a los que hay que añadirle propiedades. En este caso, al
ser un modelo ASBuilt, se dispone de las propiedades que el cliente requería. Por ello, se han
añadido al archivo de datos BEAS.xls; que es el input para Programa2_Enriquecimiento.py
Tabla 8 - Ficha de propiedades (elaboración propia)
del modelo Empresa Promotora Ministerio de Fomento
Localización N-435
Descripción Modelo As-Built de la variante de Beas
Fase Licitación
Normativa apicable
Fecha Inicial Obra
Fecha Final de Obra
Fecha de revisión
Fecha de ensayo
Fecha de llegada
Estado del objeto Construido
ID Lote Control
Conformidad
Tipo
Procedencia
Fotos
Observación

1 Descripción
Nº De Propiedades Nombre en IFC Objeto 1;Objeto 3;Objeto 4;Objeto 5;Objeto 6;Objeto 7;Objeto 8;Objeto 9;Objeto 10 ;Objeto 11;Objeto 12;Objeto 13;Objeto
14 Inicio
Código BIM 330.01.23
Nº OBJETOS Descripción Sólido Relleno
57 Tipo de C3D
Ud de Medida Metros Cúbicos
Medición
Material Préstamo
Velocidad de Proyecto 20 KM/h
Sección tipo Sección Camino Rural
Número de Eje
Partes de Ensayo
Plano Vigente
Material
Fecha Control
Firmes Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY

Tipo de Objeto A
1 Descripción
Nº De Propiedades Nombre en IFC Objeto 2;Objeto 20;Objeto 28;Objeto 29;Objeto 30;Objeto 31;
7 Inicio Vía 3
Nº OBJETOS Descripción Capa Firme
6 Tipo de C3D
Medición
Material Préstamo/ Suelo Estabilizado
Ejecutándose el segundo programa Programa2_Enriquecimiento.py, podemos incorporar

las propiedades al modelo BIM AsBuilt de carreteras
Ilustración 105 – Ejecución del Segundo programa (elaboración propia)
Para comprobar como en los casos anteriores, si estas propiedades han sido añadidas con
éxitos se acude a los visores. Análogamente, el visor de escritorio y la versión web para
tabletas.
123
Ilustración 106 – Comprobación de datos (elaboración propia)
124
Podemos dar por concluida la prueba con pleno éxito. Los resultados de la prueba se
presentan en la siguiente tabla, con 63 objetos y 2.226 propiedades incorporados.
Tabla 9 - Resumen de la prueba 3 (elaboración propia)

Nº De Objetos 63
Tipo de Modelo Infraestructura de Carreteras
8.5.4 Prueba 4 – Modelo BIM de la Vte. de BEAS completo
Los algoritmos funcionan muy satisfactoriamente con modelos pequeños y con un

orden de creación de propiedades entorno a las 3.000 propiedades. Por lo que la
siguiente prueba consiste en forzar los algoritmos e intentar llegar a añadir 10.000
propiedades.
Para ello se utilizará completo el modelo BIM de la Variante de Beas, que se ha
modelado para este trabajo. Este modelo consta de un eje principal de algo más
de 6 kilómetros y de más de 15 ejes secundarios (además de sus respectivas obras
puntuales como las obras de drenaje transversal o puentes)
El modelo 009_2018_SOL_completo_v1.ifc esta mostrado en la ilustración siguiente.
Ilustración 107 Modelo Completo de la Variante de Beas (elaboración propia)
Este modelo consta de 967 objetos, lo que implica ingresar un número mayor de
propiedades. Para ello, se inicia Programa1_Nombre.py
125
Ilustración 108 – Ejecución del primer programa (elaboración propia)
Las propiedades que voy a añadir en el fichero EXCEL_INPUT.xlsx, se muestran en la siguiente

tabla.
Tabla 10 - Propiedades del modelo de la prueba 4 (elaboración propia)
Propiedad Valor
Empresa Constructora Constructora S.L.
Empresa Proyectista TEAMBIMCIVIL S.L.
Empresa Promotora Ministerio de Fomento
Localización Variante de Beas
Descripción Obra de adecuación de la N-435
Fase Construida, modelo AS BUILT
Normativa apicable EN-ISO 19650
Fecha Inicial Obra
Fecha Final de Obra
Fecha de revisión
Fecha de ensayo
Fecha de llegada
Estado del objeto
EjeCentral Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY
Tipo de Objeto 1
1 Descripción
Nº De Propiedades Nombre en IFC Objeto 480;Objeto 489;Objeto 502; Objeto 513;Objeto 548;Objeto 514;Objeto 567;Objeto 587;Objeto 576;Objeto 619;Objeto 588;Objeto 642;Obj
9 Ensayos apicables
Material Pavimento del eje 001
Nº OBJETOS Localización del objeto Variante de Beas/ Eje 001
18 Volumen
Procedencia Capas de rodadura in situ
Tipo de Pavimento Capa de rodadura (mezcla caliente)
Tramo PK 6+100 PK 11+500
Velocidad de Proyecto 90 KM/H
Sección tipo Sección tipo troncal/ Ensamblaje 001_v11a
126
GlorietaConPesas Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY
Tipo de Objeto A
1 Descripción
Nº De Propiedades Nombre en IFC Objeto 293;Objeto 296;Objeto 299;Objeto 302;Objeto 305;Objeto 131;Objeto 134;Objeto 137;Objeto 140;Objeto 143
10 Pertenece a: Enlace 2
Tipo Glorietas (en pesas)
Nº OBJETOS Situación Este y norte
10 Tramo Beas-Badajoz
Número de Carriles 2
Entradas
Salidas
Isleta Central Ajardinada
Tipo de Jardín Césped
Riego por aspersión Si
EJE12 Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY

Tipo de Objeto 1
1 Descripción
Nº De Propiedades Nombre en IFC Objeto 429;Objeto 430;Objeto 431;Objeto 432;Objeto 410;
8 Tipo de Vía Camino Agrícola
Velocidad de proyecto 20 km/h
Nº OBJETOS PK 3+400 - 5+200
5 Material de Rodadura Grava
Paso de Ganado Sí
Replanteada Si
Certificada por Ángel Díaz Murilloç
Nº de Colegiado NONE
Ramales Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY

Tipo de Objeto 1
1 Descripción
Nº De Propiedades Nombre en IFC Objeto 197;Objeto 204;Objeto 230;Objeto 237;Objeto 244;Objeto 110;Objeto 117;Objeto 359;Objeto 366;Objeto 308;Objeto 315
8 Ramales de N435
Localización Enlace 2
Nº OBJETOS Carril de cambio de velocidad Si
11 Cuña de transición 20 m
VF 90
VI 50
Carriles 1
ODT Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY

Tipo de Objeto 1
1 Descripción
Nº De Propiedades Nombre en IFC Objeto 422;Objeto 2;Objeto 5;Objeto 4;
4 Tipo de Hormigón Hormigón Prefabricado
Diametro 1200
Nº OBJETOS Tipo de ODT Caño
4
Para implementar estos datos al modelo inicio Programa2_Enriquecimiento.py

Ilustración 109 – Ejecución del segundo programa(elaboración propia)
Este modelo, es un modelo muy grande (146 Mb) que no ha permitirlo subirlo al visor web
para visualizarlo en tabletas.
Ilustración 110 – Modelo sin propiedades (elaboración propia)
El modelo con las propiedades añadida solo aumenta de peso en 2 mB. Lo cual es muy
satisfactorio, porque la información de datos alfanuméricos no provoca que los modelos
sean inmanejables. Otra cosa es que se incorporen documentos del tipo PDF (Textos) y JPG
(Fotos)
Ilustración 111 – Modelo con propiedades (elaboración propia)
Por lo tanto, se abrirá el modelo en el visor para comprobar que la información incorporad
es correcta.
127
Ilustración 112 – Comprobación del ENRIQUECIMIENTO del modelo con las propiedades de usuario (elaboración propia)
El resumen de la prueba se presenta en la siguiente tabla, con un total de 967 objetos y

15.878 propiedades incorporadas.
Tabla 11 -Resumen de la prueba 4 de ENRIQUECIMIENTO de modelo BIM de carreteras (elaboración propia)

Nº De Objetos 967
Tipo de Modelo Infraestructura de Carreteras
El programa ha sido capaz de añadir un total de 15.878 datos alfanuméricos, lo cual es un

resultado aceptable; además de hacerlo en un tiempo computacional muy corto.
128
9 CONCLUSIONES
Con el resultado obtenido en este trabajo, se ha puede afirmar que se ha consolidado la
tecnología de construcción digital de carreteras mediante documentación de los flujos de
trabajo con el programa de modelado Civil3D para la creación de un auténtico modelo
BIM de carreteras, preparado para su uso BIM 7D (modelos BIM As Built), que permitirá
establecer las correspondientes GUIAS DE USO BIM para la implantación tanto en
administraciones públicas como en empresas consultoras o en empresas constructoras.
Este Trabajo de Fin de Grado se buscaba consolidar una línea de investigación en el trabajo
la automatización de proceso de edición de información de datos (parámetros) en los
modelos BIM de infraestructuras, iniciada por varios autores de referencia. Mejora que
permitan una reducción del tiempo de modelado en la realización de proyectos y que
permite iniciar el proceso de implantación de la tecnología BIM en los procesos de la
dirección de obra y de ejecución de la obra.
Una de las conclusiones que se puede sacar de este trabajo es la de que la automatización
de procesos de edición de propiedades (incorporación/exportación) es posible mediante
modelos BIM en formato IFC, mediante desarrollo de programas específicos realizados en
lenguajes de programación a objetos, y en especial el lenguaje Python.
Por otra parte, que el estándar IFC es adecuada para este fin, ya que cualquier modelo
BIM se convierte en un archivo de texto de líneas de código. Por lo que incluso con un móvil
o tableta se puede editar las propiedades de los modelos BIM de infraestructuras civiles.
Los programas desarrollados en este trabajo, pueden ser el inicio de un impulso cuantitativo
en la gestión de datos de los modelos BIM de infraestructuras civiles, ya que permite un
enriquecimiento masivo de datos en modelos con formato IFC, con un coste de
almacenamiento muy pequeño, siempre que sean datos alfanuméricos. Con la última
prueba de funcionalidad, el algoritmo programado ha mostrado que es capaz de añadir
mucha información de datos en poco tiempo.
Además de este objetivo, se he conseguido que el programa desarrollado obtenga una
lista de todos los objetos que existen en el modelo IFC y que el usuario pueda eliminar toda
la información de los elementos del modelo, generada por los programas modeladores,
liberándose así de la voluntad de las empresas desarrolladoras de software de programas
de modelado.
129
10 FUTURAS LÍNEAS DE INVESTIGACIÓN

A partir de este Trabajo Fin de Grado se abren otras líneas de investigación como
puedan ser:
• Desarrollo de Clasificaciones para elementos BIM a usar en los modelos de
infraestructuras civiles como son carreteras, ferrocarriles, infraestructuras
hidráulicas, obras portuarias, etc.
• Completar la propuesta de entidades (clases) de objetos de obras civiles y
sus relaciones para el nuevo estándar IFC 5, de forma que pueda implantarse
planamente en los modelos BIM civil.
• Desarrollo de los iniciados algoritmos de gestión de IFC de este trabajo, que
permitan:
o Interfaz Gráfica para la entrada de datos
o Integración de los algoritmos en un servidor
o Ajuste para su funcionamiento en tabletas
• Integración de los algoritmos en una página web para una gestión mediante
terminales del tipo smartphones o tabletas.
• Integración de los algoritmos en un visor de código abierto
• Desarrollo de un nuevo algoritmo para realizar funciones útiles en obra a partir
de información enriquecida en obra de los ficheros IFC: como informes de
certificación, edición de actas de ensayos asociados, etc.
• Algoritmo para la integración de varios modelos BIM en un solo archivo IFC
130
11 REFERENCIAS
[1] O. Jurado Egea, Jose; Liebana Carrrasco, “USO DE BIM COMO HERRAMIENTA DE
INTEGRACIÓN EN TALLERES DE TECNOLOGÍA DE LA EDIFICACIÓN,” EUBIM, 2015.
[2] J. Agullo de Rueda, “Marco Implantacion de Metodologia BIM en titulacion de
Arquitectura,” EUBIM 2016, 2016.
[3] O. Carranza Zavala, AutoCAD 2016. Barcelona : Marcombo, 2016.
[4] F. B. V. M. y D. B. O. Juan Carlos Pomares Torres, F. Javier Baeza de los Santos,
“Herramientas BIM como innovación en la educación superior de estudios de
ingeniería civil y arquitectura: revisión sistemática,” in XV Jornadas de Redes de
Investigación en Docencia Universitaria- REDES 2017 y I Workshop Internacional de
Innovación en Enseñanza Superior y TIC- INNOVAESTIC 2017, 2017.
[5] J. E. Gómez Gómez, V. Hernández, and M. A. Morales, “ARQUITECTURA INTERACTIVA
COMO SOPORTE AL APRENDIZAJE SITUADO EN LA ENSEÑANZA DE LA INGENIERÍA,”
Rev. Educ. en Ing., vol. 10, pp. 88–97, 2015.
[6] D. Puche and E. Humberto, “NUEVAS TECNOLOGIAS EN LA ENSEÑANZA DE LA
INGENIERIA CIVIL: BIM Y REALIDAD VIRTUAL,” Arquetipo, 2015.
[7] I. Vilardaga Rodrigo, “Integración de BIM en la formación del grado en ingeniería
civil,” p. 1, 2017.
[8] E. Puente and G. P. Gt, “Bim en infraestructuras lineales.”
[9] Ministerio de la Presidencia del Gobierno de España, “Ley 9/2017, de 8 de noviembre,
de Contratos del Sector Público, por la que se transponen al ordenamiento jurídico
español las Directivas del Parlamento Europeo y del Consejo 2014/23/UE y 2014/24/UE,
de,” BOE, pp. 1–265, 2017.
[10] V. Domínguez Blanco, “Estudio sobre la implementación de la tecnología BIM en las
contrataciones de obra pública,” 2015.
[11] P. Jimenez Abós and S. Muñoz Gomez, “Edicion del fichero IFC para enriquecer y
explotar la informacion,” Spanish J. BIM, vol. 18/01, pp. 14–24, 2015.
[12] C. Eastman, P. Teicholz, R. Sacks, and K. Liston, BIM Handbook A. .
[13] “buildingSMART - The Home of BIM.” [Online]. Available:
https://www.buildingsmart.org/. [Accessed: 31-Jul-2020].
[14] J. Wu and J. Zhang, “New Automated BIM Object Classification Method to Support
BIM Interoperability,” J. Comput. Civ. Eng., vol. 33, no. 5, Sep. 2019.
[15] P. Organizations, “DEVELOPMENT SPECIFICATION LOD Spec 2017 Guide,” no.
November, 2017.
[16] J. Alonso Madrid, “LOD. Definiciones, innovaciones y adaptación a España.”
[17] MTHoogard, Building Component Catalogue with LOD, no. February. 2020.
[18] Juan Bautista Bermejo: Blas González González, “Aplicación De La Metodología Bim
Al Proyecto De Construcción De Un Corredor De Transporte Para Un Complejo
Industrial - Modelo Bim 4D Planificación,” 2018.
131
[19] J. Monar González and B. González González, “Trabajo Fin de Grado Ingeniería Civil
Modelado BIM para Proyecto AS-BUILT de Infraestructuras Lineales.”
[20] M. B. Lepe, “Diseño de modelos BIM para infraestructuras civiles con DYNAMO,” 2019.
[21] Carmen Vera Galindo; Blas González González, “Trabajo Fin de Máster MODELO BIM
5D COSTES,” 2018.
[22] M. A. Ferreiro Morales and B. Gonzalez Gonzalez, “Aplicacion de la Metodologia BIM
a un proyecto de Construccion de Corredor de transporte para un complejo industrial
. Modleos BIM 3D OBRA LINEAL,” 2018.
[23] Juan Bautista Bermejo: Blas González González, “Aplicación De La Metodología Bim
Al Proyecto De Construcción De Un Corredor De Transporte Para Un Complejo
Industrial - Modelo Bim 4D Planificación,” 2018.
[24] A. Martin Redondo and B. González González, “Aplicación de la Metodología BIM 4D
a un Proyecto de Infraestructura Nodal,” 2019.
[25] J. L. R. Martin, Dearrollo de uan apliacion de Visualizacion de Carreteras. .
[26] S. Calderón Martín, “Estudio sobre BIM integrado. Análisis del caso práctico de la
ampliación de la tercera compuerta en la esclusa de Beatriz y ensanchamiento del
canal de Lek (Holanda),” Sep. 2018.
[27] A. Roca Medina, “Análisis de la gestión de proyectos mediante la metodología
Building Information Modeling (BIM). Aplicación al proyecto de ampliación del puerto
deportivo Pobla Marina (Puebla de Farnals, Valencia).,” Jan. 2019.
[28] J. A. Yáñez Martín, “Elaboración efectiva del modelo de información de construcción
de una nave industrial trabajando bajo plataforma BIM,” 2017.
[29] J. M. Carmona, J. Ángel, and A. Domingo, “ANTEPROYECTO DEL TRAMO DE
CARRETERA N-232 A SU PASO POR HÍJAR (TERUEL). MODELADO BIM,” Oct. 2019.
[30] M. A. Rosell Esteve, “Proyecto de construcción de un depósito de regulación en el TM
de San Juan de Alicante (Alicante),” Nov. 2019.
[31] S. D. Duque Carmona, “Análisis y aplicación de la metodología BIM en una obra de
carácter civil en el Reino Unido,” Oct. 2017.
[32] M. M. Ghazal and A. Hammad, “Application of knowledge discovery in database
(KDD) techniques in cost overrun of construction projects,” Int. J. Constr. Manag., pp.
1–15, Mar. 2020.
[33] S. H. Lee and B. G. Kim, “IFC extension for road structures and digital modeling,” in
Procedia Engineering, 2011, vol. 14, pp. 1037–1042.
[34] L. Zhang and N. M. El-Gohary, “Automated IFC-based building information modelling
and extraction for supporting value analysis of buildings,” Int. J. Constr. Manag., vol.
20, no. 4, pp. 269–288, Jul. 2020.
[35] R. Vieira, P. Carreira, P. Domingues, and A. A. Costa, “Supporting building automation
systems in BIM/IFC: reviewing the existing information gap,” Engineering, Construction
and Architectural Management, vol. 27, no. 6. Emerald Group Publishing Ltd., pp.
1357–1375, 22-Feb-2020.
[36] N. O. Nawari, “Generalized Adaptive Framework for Computerizing the Building
Design Review Process,” Journal of Architectural Engineering, vol. 26, no. 1. American
Society of Civil Engineers (ASCE), 01-Mar-2020.
132
[37] X. Deng, H. Lai, J. Xu, and Y. Zhao, “Generic language for partial model extraction
from an IFC model based on selection set,” Appl. Sci., vol. 10, no. 6, Mar. 2020.
[38] X. Du, Y. Gu, N. Yang, and F. Yang, “IFC File Content Compression Based on Reference
Relationships,” J. Comput. Civ. Eng., vol. 34, no. 3, May 2020.
[39] T. H. Kwon, S. I. Park, Y. H. Jang, and S. H. Lee, “Design of railway track model with
three-dimensional alignment based on extended industry foundation classes,” Appl.
Sci., vol. 10, no. 10, May 2020.
[40] AENOR, “Norma UNE-EN ISO 19650-2:2019 Organización y digitalización de la
información en obras de edificación e ingeniería civil que utilizan BIM (Building
Information Modelling). Gestión de la información al utilizar BIM (Building Information
Modelling). Parte 1,” 2019.
[41] BuildingSMART (Institucion), “Base de Datos de Estandares IF,” 2020. [Online].
Available: https://technical.buildingsmart.org/standards/ifc/ifc-schema-
specifications/.
[42] Autodesk, “Manual de IFC para Revit,” Digit. Inf. Eng. Constr., pp. 1–52, 2018.
[43] B. S. Chapter, “19/10/2019 IFC en español - BuildingSMART Spanish Chapter,” 2019.
[44] buildingSMART, “Esqueam general IFC 2x3.” [Online]. Available:
https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/FINAL/HTML/.
[45] Sacyr, “Estándar IFC para Infraestructuras de Carreteras . Como surge el PROYECTO
ROADBIM ?,” 2019.
[46] J. Nájera Gómez and P. Jiménez Abós, “CÓMO INCORPORAR Y UTILIZAR LAS
CLASIFICACIONES EN IFC,” Spanish J. BIM, vol. 18/01, pp. 14–24, 2015.
[47] G. Costa, A. Jardi, and J. Valderrama, “Mejoras para la automatizacion de procesos
en la importacion de modelos IFC,” Spanish J. BIMJournal BIM, 2015.
[48] C. M. Eastman, BIM handbook : a guide to building information modeling for owners,
managers, designers, engineers, and contractors. Hoboken, NJ: Wiley, 2008.
[49] Parlamento Europeo and Consejo de la Unión Europea, “Directiva 2014/24/UE del
Parlamento Europeo y del Consejo, de 26 de febrero de 2014 , sobre contratación
pública y por la que se deroga la Directiva 2004/18/CE,” D. Of. la Unión Eur., vol. 2014,
no. L 94, pp. 65–240, 2014.
133
12 ANEJOS
12.1 ANEJO I - ESTRATEGIA DE MODELADO DE OBRAS DE CARRETERAS
En el presente anejo se documenta los flujos de trabajo a realizar en el proceso de
modelado digital de carreteras con aplicación de tecnología BIM con el programa de
modelado Civil3D de la casa Autodesk, y del cual se dispone de licencia educativa por la
Universidad de Sevilla.
12.1.1 Edición de los Accesos Directos a Datos

Al ser un modelo ya iniciado, tenía unos archivos compartidos y unos accesos directos ya
creados. El modelado B.I.M. tiene unos de sus pilares en el trabajo colaborativo, por lo que
es necesario tener un bien entorno común de datos, accesible desde el software de
modelado. En ese sentido Civil 3D tiene una herramienta que facilita el trabajo
colaborativo.
El Acceso Directo a Datos es una herramienta que tiene AutoCAD Civil 3D para crear
referencias a objetos inteligentes que no se encuentran en el dibujo actual. Esto permite un
trabajo colaborativo o incluso conseguir dibujos complejos sin el peso que supondría
modelarlo todo en un solo archivo. Esta herramienta funciona así: al seleccionar un objeto
inteligente existe la opción de dar Acceso Directo a Datos, lo que hace AutoCAD es
guardar la ruta de ese dibujo junto con su nombre para que cuando se necesite esta
información en otro dibujo cree una referencia al archivo original.
Por lo que si se va a cambiar de ruta de guardado todos los archivos origen se debe
cambiar en el programa la ruta que utiliza para crear esta referencia. Si esto no se hace, el
programa buscará el objeto original en una ruta en la que ya no se encuentra, por lo que
dará un error. Esto será posible con la aplicación de Autodesk: Editor de Acceso Directo a
Datos.
El editor es una aplicación de Autodesk que permite exactamente eso, cambiar la ruta y
los archivos de origen de las referencias. Su entorno es el siguiente:
134
Ilustración 113 - Entorno del programa (elaboración propia)
El programa consiste básicamente en un listado de objeto inteligentes en los que también

aparece la ruta de guardado del archivo original y su ruta. Entonces pongamos un ejemplo:
Se quiere mover todo el proyecto a otro fichero para organizar mejor el trabajo. Es decir, el
proyecto original está guardado en: C:\Users\usuario\Desktop y se quiere mover a
C:\Users\usuario\Desktop\Ejemplo. Entonces, hay que pinchar en un archivo del listado y
darle a la opción Buscar y Reemplazar (botón situado en la parte superior de la ventana)
Ilustración 114 - Buscar y Reemplazar (elaboración propia)
Aquí aparecerá la ruta de guardado anterior y se debe insertar en Reemplazar la nueva

ruta (que en el caso del ejemplo sería C:\Users\usuario\Desktop\Ejemplo)
Ilustración 115 - Ventana de buscar y Reemplazar (elaboración propia)
135
Con esta acción, se puede conseguir reemplazar solo un objeto (el seleccionado) o todos
los objetos inteligentes encontrados en la misma ruta que este objeto (Si se selecciona la
opción Reemplazar Todo). Una vez que se termine con todos los ficheros hay que guardar,
para ello hay que seleccionar guardar como, y seleccionar la carpeta de guardado. Esto
generará una carpeta _Shortcuts que deberá estar en la carpeta de guardado del
proyecto.
Esta carpeta es la que guarda los accesos directos. Tiene una gran importancia y no debe
de ser modificada si no es con este programa. Es recomendable tener una copia de
seguridad (en general de todo el proyecto y en particular de estos archivos)
En el programa Civil 3D al abrir los ficheros se puede observar que no ha cambiado la
carpeta de Acceso Directo a Datos, sigue estando la original. Hay que hacer un último
paso, hay que establecer una Nueva Carpeta de Trabajo
Ilustración 116 - Establecer Carpeta de Trabajo(elaboración propia)
En el caso de que se pueda seleccionar la carpeta nueva en la que se ha movido el

proyecto, se debe seleccionar (en el caso del ejemplo sería
C:\Users\usuario\Desktop\Ejemplo).
12.1.2 Modelo 3D en Civil 3D

Para hacer un modelo 3D en Civil 3D hay que seguir siempre los mismos pasos. Hay que
definir los ejes en las tres direcciones mediante: la alineación, el perfil longitudinal y el perfil
transversal. Para ello, el proyecto original nos ha dado todos los datos necesarios. El flujo de
trabajo para el modelado es:
Ilustración 117 - Flujo de Trabajo del Proyecto Piloto (elaboración propia)
136
Todo modelo 3D debe de tener una cartografía digital (una superficie en Civil 3D) para
poder realizar todos los flujos de trabajo. En este caso, la cartografía ha sido suministrada
137
por la empresa que realizó el proyecto original. En el caso de que no se disponga de un
levantamiento topográfico se puede disponer de una cartografía en los organismos
oficiales (como las Comunidades Autónomas). El siguiente paso es definir los ejes en planta.
Para este tramo del proyecto, se requieren modelar los siguientes ejes:
Tabla 12 - Estado Inicial del Modelado (elaboración propia)
Eje Alineación hecha Nombre Alineación Tipo de Eje Nombre Perfil Longitudinal (archivo .txt)
1 Si 009_2018_Alin_001_Tronco N-435 009_2018_Eje_001
50 Si 009_2018_Alin_050 Ramal 009_2018_Eje_050
48 Si 009_2018_Alin_048 Ramal 009_2018_Eje_048
43 Si 009_2018_Alin_043 Glorieta 009_2018_Eje_043
109 Si 009_2018_Alin_109 Glorieta 009_2018_Eje_109
49 Si 009_2018_Alin_049 Ramal 009_2018_Eje_049
54 No 009_2018_Alin_054 Camino Auxiliar 009_2018_Eje_054
45 Si 009_2018_Alin_045 Camino Auxiliar 009_2018_Eje_045
44 Si 009_2018_Alin_044 Camino Auxiliar 009_2018_Eje_044
51 Si 009_2018_Alin_051 Ramal 009_2018_Eje_051
12.1.3 Alineación
Para el modelado de alineaciones, se ha seguido el listado en planta suministrado en el
proyecto original. Un ejemplo es el siguiente:
Ilustración 118 - Listado en planta (elaboración propia)
138
Por lo tanto, en el proyecto original se puede encontrar los vértices de cada eje en planta.
Estos se introducen en Civil 3D como puntos, de estos puntos solo importan las coordenadas
x e y ya que forman parte de la definición en planta. Una vez que los puntos estén, se debe
ir tramo por tramo dibujando el tipo de curva que indica el listado. Una vez terminadas
todas las plantas el resultado es:
Ilustración 119 - Alineaciones dibujadas en Civil 3D (elaboración propia)
139
Las polilíneas generadas gracias al listado del proyecto original hay que transformarlas en
alineaciones. Este proceso es posible gracias a la herramienta Crear Alineación a partir de
Objeto
140
12.1.4 Perfil longitudinal de una alineación
Los perfiles longitudinales son otros de los procesos básicos para la definición de un modelo
de carreteras en Civil 3D. En este caso es un modelado de una obra ya construida en la
que el diseño ya está indicado. Es decir, nosotros como usuarios no necesitamos saber a
priori si un tramo está en desmonte o en terraplén ya que el diseño de la Carretera es el que
es y ya está estipulado. Esto conlleva a que de los dos perfiles que se pueden generar en
Civil 3D solo es necesario para el Desarrollo del modelo el perfil de la rasante de diseño. Si
bien es cierto, que tener un perfil completo añadiendo el corte de la superficie cartográfica
por una superficie vertical con la forma en planta de la alineación nos da una información
vital para el control de calidad.
12.1.4.1 Rasante de Diseño
El perfil longitudinal de un eje está vinculada a la alineación. Una vez que se ha definido la
planta, el flujo de trabajo indica que se debe modelar el perfil longitudinal para dotar a la
planta de una cota en todo su recorrido. En este caso, los datos de las cotas también se
encuentran en la documentación oficial del proyecto.
Ilustración 120 - Flujo de trabajo del Perfil longitudinal (elaboración propia)
Por lo tanto, se puede ver en un ejemplo:
141
Ilustración 121 - Listado del Perfil y conversión a TXT (elaboración propia)
Una vez que ya se tiene el archivo TXT prepara con el PK de los vértices y la elevación de
estos hay que introducirlo en Civil 3D. Para ello se utilizar la herramienta Crear Perfil a Partir
de Archivo
142
Ilustración 122 - Crear perfil a partir de Archivo (Civil 3D)
Una vez que el usuario de a aceptar, el programa ya le ha asignado a alineación

seleccionada una rasante
12.1.4.2 Corte de la Superficie Topográfica (Perfil de Superficie)
Una vez generada la rasante, es interesante comparar con el perfil del terreno. Para tener
esta información de forma visual y proceder con el control de calidad (ya que hay perfiles
en los documentos oficiales del proyecto), se realiza un perfil longitudinal de las
alineaciones. El perfil del eje ya se ha modelado con el paso anterior, ahora solo falta que
el programa haga un perfil de la superficie en la zona donde se encuentra el eje. Para ello
se utiliza:
143
Crear Perfil de Superficie → Añadir Superficie Cartográfica
Ilustración 123 - Crear perfil de Superficie (elaboración propia)
Civil 3D realiza un corte de la superficie utilizando una superficie vertical con la forma en
planta de la alineación. Del corte de las dos superficies (una de ellas vertical) da como
producto la altimetría de la superficie en la longitud del eje.
Al ya tener un perfil de la superficie y otro de los ejes, se pueden realizar una visualización
de los perfiles. Para ello:
Crear Visualización de Perfil → Elección del Eje → Ajustes de visualización y de guitarras
Ilustración 124- Crear Visualización de Perfil (elaboración propia)
Por lo tanto, se puede proceder con el control de calidad. Es el primer paso para subsanar
errores que luego pueden provocar un retraso importante en el proceso de modelado.
144
12.1.5 Secciones Tipo
En el proyecto original, hay varias secciones tipo acorde con los distintos ejes que se puede
encontrar en el tramo y también por región (EXPLICARLO, EN LOS PUENTES CAMBIA LA
SECCIÓN Y EN LOS RAMALES, TENGO QUE EXPLICAR ESO).
Estas secciones, no se parecen a las secciones estándares que se pueden construir dentro
de Civil 3D. Por lo que se tiene que recurrir al modelado de las secciones en el software
Subassembly Composer.
Estas secciones son de distintas naturalezas y tienen casuísticas propias.
12.1.5.1 Eje Principal:
Este es la sección tipo del eje de la nueva variante de la N-435. La sección tipo dada en el
proyecto es la siguiente:
Ilustración 125 - Sección Tipo del eje principal (proyecto original)
Esta sección tipo se ve alterada en varios puntos, para empezar en las zonas de desmonte
se disponte de una cuneta para recoger la lluvia que caiga por el talud de desmonte. Otro
punto esencial es la intersección. Esta intersección es la intersección dos diseñada en el
proyecto original. En estos puntos, del eje principal nacen dos ramales hacia las glorietas y
llegan otros dos ramales como se puede ver en la siguiente imagen:
145
Ilustración 126 - Planta del Eje principal
12.1.5.2 Sección tipo característica
La definición de la sección tipo que se usará en más kilómetros de la obra lineal que da
lugar al eje 001 es la siguiente:
Ilustración 127 - Diseño en Subassembly Composser (elaboración propia)
146
147
Ilustración 128 - Algoritmo diseñado (elaboración propia)
La explicación del diseño de un subensamblaje no entra en el objetivo de este trabajo, pero

si es necesario explicar varios conceptos que deben de tenerse en cuenta a la hora de
diseñar un subensamblaje y que no he encontrado en los trabajos de referencia de la
Escuela Técnica Superior de Ingeniería.
Para realizar un subensamblaje de este tipo, hay que tener varios conceptos claros para el
funcionamiento de este dentro de Civil 3D.
Un concepto principal, es tener un subensamblaje parametrizado para que cualquier error
148
o cualquier cambio en el diseño posterior no suponga un problema. Por ello para definir las
longitudes, anchos y ángulos es principal introducirlo desde ‘Input Parameters’
Ilustración 129 – Parámetros (elaboración propia)
Para realizar la intersección de la sección con el terreno, se utiliza la variable ‘Target

Parameters’. Esta variable es muy importante y debe de ser de tipo ‘Surface’. Esta variable
lo que hace es darle un valor a la altura del terreno para toda la sección (es decir, simula
la cota de un terreno completamente horizontal). Luego, Civil 3D guardará en esta variable
la cota del terreno en los puntos donde aplique esta sección. Es importante, saber, que
para evaluar si una sección está en desmote o en terraplén no sirve con establecer la
comparación en un solo punto de la sección ya que el terreno real no es horizontal.
Es decir, en la sección habrá una parte que se construya sea en terraplén o en desmonte.
Esta parte suele coincidir con las capas de pavimento y con las capas de base y subase.
Esto quiere decir, sea terraplén o desmonte, esta zona va a existir con la misma forma por
lo que ahí es donde se debe comparar la altura de la sección con la del terreno.
Ilustración 130 - Adaptación a desmonte y terraplén (elaboración propia)
Hay un detalle que se debe de tener en cuenta, en el desmonte existe una cuneta. Se
puede dar el caso, en el que el terreno se encuentre en por encima del punto de la cuenta,
pero por debajo en el punto comentado anteriormente. Por lo tanto, no solo vale
establecer la igualdad en el punto donde termina el talud de la base, hay que establecer
otra igualdad en el punto final de la cuneta para acotar el caso comentado anteriormente:
149
Ilustración 131 – Condición (elaboración propia)
Es muy importante, el punto en el que se localiza el punto auxiliar. En la vista previa de

Subassembly Composser puede parecer que el ‘Delta X’ que se define es baladí pero no
es así. Hay que tener en cuenta, que este punto luego se llevará a Civil 3D y copiará la cota
del terreno. Por lo que no es lo mismo que el punto esté donde realmente se quiere que
nazcan los taludes y donde realmente se toma la decisión a que esté en el centro de la
sección.
Por la misma razón, es necesario un doble condicional para establecer también la
casuística en la que la sección esté en media ladera. Para ello se debe establecer otro
punto auxiliar en el lado contrario de la sección (o diseñar solo media sección en
Subassembly Composer e insertarla dos veces en Civil 3D).
Otro concepto que adquiere gran importancia y que es fuente común de errores es el
establecimiento de los códigos de punto, de vínculo y de forma. El diseño de estos códigos
marca la diferencia entre un subensamblaje funcional y un subensamblaje que Civil 3D no
sabe cómo implementar. Los códigos sirven para que Civil 3D enlace puntos, líneas y áreas
de las secciones transversales que irá implementando.
Ilustración 132 - Detalle de la sección (elaboración propia)
El P25 se insertará con la frecuencia que el usuario quiera (junto con el resto de la sección).
Entre sección y sección no hay nada, por lo que Civil 3D debe extruir las secciones para
rellenar ese espacio (y que se convierta en un objeto 3D). Antes de que Civil 3D pueda
150
realizar eso, debe de saber la evolución de un punto a lo largo del kilometraje de la
carretera. Es decir, necesita saber en la sección siguiente cual es el punto equivalente al
punto P25. Lo mismo ocurre con las líneas y con las áreas. Para identificar el objeto, se utilizan
códigos (como si fuese un ID en otros lenguajes de programación).
Civil 3D tiene unos códigos predeterminados, se pueden utilizar estos o los que el usuario
quiera, no existe gran diferencia en el comportamiento de la obra lineal, los códigos
definidos por Autodesk son los siguientes:
Ilustración 133 - Código de Punto (Autodesk)
151
Ilustración 134 - Código de Enlace (vía Autodesk)
Ilustración 135 - Código de Forma
Para introducir estos códigos en cada uno de los puntos, líneas y áreas hay que seleccionar
el elemento al que se le quiera añadir el código y después se introduce una de las palabras
de los cuadros anteriores entrecomilladas, como se puede ver en las siguientes imágenes:
Ilustración 136 - Códigos en SAC (elaboración propia)
152
12.1.5.3 Sección Tipo con carril de Cambio de Velocidad
Hay que definir otra sección para implementar el acceso de los ramales al eje principal.
Hay que tener en cuenta varios aspectos importantes.
Ilustración 137 - Carril de Cambio de Velocidad (Google MAPS)
Este es un ejemplo de la A-66, como se puede ver, los ramales interactúan con el eje
principal mediante un carril de cambio de velocidad. Este carril de cambio de velocidad
tiene un ancho que en el caso de que sea un carril de desaceleración llega un momento
en el que el ancho disminuye con el avance del kilometraje. Esta zona se denomina cuña
y debe de ser modelada en Civil 3D.
Por lo tanto, se debe de diseñar un mecanismo que pueda producir este incremento de
ancho, para ello, Civil 3D y Subssembly Composser tiene un mecanismo que lo hace posible.
En ‘Target Parameters’ en el tipo de parámetro que se puede definir existe la posibilidad de
definir un tipo ‘Offset’.
Por lo tanto, si se define un parámetro de esta tipología, luego se debe de definir un punto
auxiliar. En las propiedades de este punto se puede encontrar:
Ilustración 138 – Offset (elaboración propia)
Se puede definir, que el punto auxiliar copie su cota vertical de un punto definido fuera de
Subassembly Composser (normalmente de una superficie ‘Surface Target’) o que copie su
153
Delta X de otro punto definido fuera del programa. Este es el caso que ocupa esta sección,
en Civil 3D, se le asigna a este punto auxiliar el Delta X equivalente a la distancia entre la
alineación del eje a modelar y una alineación determinada (ya se entrará más detalle en
este aspecto)
Por lo tanto, esta es una herramienta muy útil diseñar las cuñas de los carriles de cambio de
velocidad. Por lo tanto, la estrategia es, establecer un punto auxiliar que refleje la posición
de la alineación que indicará el ancho que tendrá el carril y a partir de este punto
establecer la sección complementaria a la sección del tronco para modelar este carril de
cambio de velocidad.
El algoritmo del subensamblaje es el siguiente.
Ilustración 139 - Algoritmo del SAC (elaboración Propia)
154
Ilustración 140 - Sección en SAC (elaboración propia)
Hay que acotar varías condiciones límites, es decir, llegará un momento en que la
alineación objetivo esté a una distancia tal que entre en la sección del eje principal. En este
caso, hay que establecer un mínimo en el ancho establecido. Cuando esto ocurra, la
sección será:
Ilustración 141 - Sección sin carril de cambio de velocidad (elaboración propia)
En esta sección hay que seguir las mismas premisas que en la anterior, con la diferencia de
que el diseño se ha hecho de media sección tipo para acortar los tiempos de diseño ya
que es una sección infinitamente más compleja que la anterior.
Además, esta sección tiene la complicación de que se unen dos ramales al tramo. Al tener
un subensamblaje que se ha diseñado de forma simétrica, es decir, que en el ensamblaje
se introducirá dos subensamblajes, uno al lado derecho y otro al izquierdo hay que tener
en cuenta que el incremento de x al lado izquierdo es negativo.
Por lo tanto, el primer condicional se establece para saber en qué lado está la alineación
objetivo para tratar los ‘delta x’ con su signo.
Ilustración 142 – Condición (elaboración propia)
155
Para ello, se establece dos puntos auxiliares (uno para cada alineación, ya que diseñamos
con dos alineaciones para que la cuneta también decrezca). Este condicional establece
si AP6 es positivo o negativo (en el caso de la previsualización del programa, nunca será
negativo, pero hay que considerar el caso de que este subensamblaje vaya al lado
izquierdo).
Ambas ramas son iguales en cuanto al diseño de la sección, simplemente teniendo en
cuenta el signo, por lo que se analizará solo la rama positiva.
Ilustración 143 - Inicio Rama Positiva (elaboración propia)
El diagrama llega desde la foto anterior por el flujo llamado ‘Lado Derecho’. En la siguiente
decisión se define si se diseña una sección normal del eje principal o se continúa con el
diseño adicional del ramal. Para ello, se establece la condición de que la alineación
objetivo alcance una distancia tal, que no esté dentro de la sección principal.
En la secuencia ‘eje normal’ se encuentra el diseño anterior. El flujo continúa igual que el
comentado en el primer apartado.
Ilustración 144 - Algoritmo de la Sección Central (elaboración propia)
Hay que tener la consideración de que este caso es un diseño de media sección simétrica
por lo que no es necesaria la doble condicional para evaluar el punto del terreno en cada
extremo de la sección. Continuando con el flujo que nos lleva al diseño del ramal nos
encontramos con:
Ilustración 145 Inicio de Algoritmo de Diseño del Ramal (elaboración propia)
156
A este punto, llegan los flujos denominados ’Ramal’ tanto del lado izquierdo o derecho.
Para unificar flujo. En esta secuencia se diseña el tronco de la sección con ramal añadiendo
la transición para el carril de aceleración. Cuando el ancho de la cuña va aumentando,
llega un punto en el que toda la plataforma del carril debe ampliarse junto con el
pavimento.
Ilustración 146 - Condicional para la ampliación de la cimentación (elaboración propia)
Con más detalle, el flujo sale de la secuencia que establece el tronco de la sección y vuelve
a separar el lado del delta positivo del negativo. Centrándonos en lado derecho, llega a
otra decisión. Esta establece el límite geométrico de la berma. Es decir, no es la misma
sección si el ancho del carril todavía no ha salido de la plataforma del eje central o si ha
salido. Ya que, si la cuña es más ancha, hay que ir aportando material desde la base para
conformar la plataforma de la cuña. De ahí esa condición.
El flujo termina, diseñando estas dos opciones junto con los taludes de terraplén o
desmonte.
12.1.5.4 Sección Tipo Ramal
Los ramales comparten secciones tipo, en el proyecto original se diseñó la sección del ramal
Ilustración 147 - Sección tipo de los Ramales
157
Esta sección representa la sección en media ladera, por lo que tenemos los casos de
terraplén y desmonte. Esta sección modelada en Subassembly Composser queda así:
Ilustración 148 - Sección tipo en SAC (elaboración propia)
El algoritmo para llegar a esta sección es el siguiente:
158
Ilustración 149 - Algoritmo de SAC (elaboración propia)
La única complicación del diseño de este subensamblaje es modelar el doble condicional
159
en los dos extremos de la sección para tener en cuenta el caso en el que la sección esté
en media ladera.
12.1.5.5 Sección Ramal Bidireccional
En el enlace, existe un tramo que une las dos glorietas. En este caso, es un ramal que tiene
un carril para cada dirección. En este caso, hay que modelar los dos carriles doblando la
sección anterior
Ilustración 150 - Ramal Bidireccional (proyecto original)
160
12.1.5.6 Sección Tipo Glorieta
En las glorietas, hay una nueva sección tipo. El proyecto original lo diseñó así:
Ilustración 152 – Sección tipo glorieta (proyecto original)
Esta sección tiene una diferencia importante respecto a las anteriores. Existe una isleta a un
lado de la sección. Por lo tanto, la estrategia para modelar este extremo de la sección es,
que ese extremo de la sección no va a tener interacción con la superficie modelada en el
Subassembly Composer, ya que la isleta se va a modelar desde Civil 3D ya que es un
procedimiento más cómodo para esta tipología. Por lo que, la sección modelada en
Subassembly Composer:
La orientación de la parte de la sección que pertenece a la isleta depende de la

alineación. Es decir, el P.K. aumenta en el sentido de las agujas del reloj, la isleta quedará a
la derecha. Si es, al contrario, esta estará situada a la izquierda. De ahí que esta sección no
coincida con la orientación de la del proyecto.
12.1.5.7 Sección Tipo de Caminos Agrícolas
Este proyecto contiene un gran número de ejes. De estos ejes, la mayoría son ejes de
caminos agrícolas que se reponen una vez terminada la obra del eje central. Estos ejes
161
tienen la siguiente sección:
Ilustración 154 - Sección tipo Camino Agrícola (proyecto original)
Esta sección no tiene mucha complejidad en cuanto al diseño en Subassembly Composser

se refiere. Por lo que el algoritmo y la sección queda:
Ilustración 155 - Algoritmo general (elaboración propia)
Primero se define la geometría general de la sección acorde con las medidas de la sección
proyectada. Las secuencias tienen dentro el siguiente algoritmo:
Ilustración 156 - Lado derecho de la calzada (elaboración propia)
162
Para realizar la intersección con el terreno, se diseña igual que en los casos anteriores donde
se evalúa la posición del terreno en los dos extremos de la sección y si hubiera, en los
extremos de las cunetas:
Ilustración 157 - Algoritmo para el diseño de cunetas (elaboración propia)
12.1.6 Obra Lineal

Una vez que en Civil 3D la infraestructura tiene la definición en planta, en perfil y la sección
transversal, el programa tiene la posibilidad de realizar un diseño tridimensional. El proceso
en el que Civil 3D genera un objeto 3D es el siguiente:
El usuario ha definido una planta. Un eje de la vía, al que para cada punto existen dos
cotas, la rasante y la del terreno. Por lo que tiene un eje tridimensional (x e y de la planta; z
del perfil). Por lo que, el programa recorre con una sección transversal todo el eje. Así se
convierte en un objeto tridimensional con la sección de una vía (puede ser una Carretera
o una vía de ferrocarril o cualquier infraestructura).
Este objeto tridimensional es la obra lineal, no es un objeto cualquiera ya que es inteligente.
Esta característica le dota de la capacidad de ser referenciado por otros dibujos, guardado
en el entorno común de datos (mediante los Accesos directos a Datos) y ser editado en
cualquier momento. Además, si cualquiera de los objetos que la definen (alineación, perfil
y sección transversal) es editado, la obra lineal se regenerará en consecuencia. Es decir, la
obra lineal cambiará en consecuencia.
12.1.6.1 Generación de una Obra lineal
Una vez que se definen los tres objetos mencionados anteriormente es sencillo generar una
obra lineal. Para ello hay que seguir los siguientes pasos: Hay que pinchar en la herramienta
Obra Lineal y se desplegará una Ventana en la que el usuario tiene que indicar los tres
163
objetos que definen una obra lineal. Hay que definir que alineación, perfil y sección
transversal tiene la Carretera.
Ilustración 158 - Herramienta Obra Lineal (elaboración propia)
Ilustración 159 - Ventana de Asignación de Alineación, Perfil y Ensamblaje (elaboración propia)
164
Ilustración 160 - Tramos de Obra Lineal (elaboración propia)
Una vez que se da a aceptar, se abre la ventana anterior. En esta ventana, Civil 3D permite
editar la frecuencia de inserción de las secciones transversales, el objetivo, y los tramos de
la obra lineal (incluido sus P.K. inicial y final) Esta ventana, se puede volver a mostrar en
Propiedades de Obra Lineal
Esta ventana es muy importante para la buena implementación del ensamblaje en la obra
lineal. Al pinchar en Objetivo se despliega una ventana en la que aparecen los objetivos
que el ensamblaje tiene. Es decir, si el ensamblaje tiene un Target Parameters de una
superficie, dentro de esta ventana se puede indicar al ensamblaje que superficie tiene que
tomar como objetivo para calcular las secciones en desmontes y en terraplén.
Ilustración 161 - Objetivos de Obra Lineal
Además de este objetivo, se encuentra un objetivo de desfase. Este objetivo será una
alineación que será la que de sentido al ensamblaje de los carriles de cambio de
velocidad.
Los tramos también son una herramienta fundamental en el diseño de carreteras. Estos
tramos permiten la adaptación de la obra lineal a distintas casuísticas tales como: cambios
de secciones tipo, cambios de superficie objetivo (si este fuera el caso) o de alineaciones
165
objetivos, cambio de frecuencia de inserción de las secciones transversales etc.
Una vez que se acepta, la obra lineal se regenera. Para que la obra lineal se genere con
éxito es importante que los códigos del ensamblaje estén especificados como se indicó en
el apartado anterior. Las obras lineales de la Variante de Beas son las siguientes:
Ilustración 162 - Obra Lineal Eje 62 (elaboración propia)
Ilustración 163 - Eje 73 (elaboración propia)
166
167
168
169
Ilustración 165 – Ejes 20, 129 y 61 (elaboración propia)
170
171
Estas son las obras lineales que definen los ejes diseñados en la obra original. Este es el objeto
principal en un modelado de una vía de infraestructuras porque es el que permite un diseño
3D y el inicio de un diseño BIM. Pero lo realmente interesante de este objeto son los
productos que se pueden extraer de él. Gracias a la obra lineal se puede generar una
superficie adaptada a la opción que el usuario quiera. Es decir, el usuario puede generar si
lo necesita una superficie por capa de plataforma o de pavimento. Esto es una gran
ventaja para la gestión del modelo y del diseño.
12.1.6.2 Generación de una Superficie procedente de una Obra Lineal
Para generar una superficie procedente de una obra lineal, se selecciona la obra lineal en
172
el espacio modelo. Cuando se selecciona, se despliega la ficha de obra lineal en la barra
de herramientas. Ahí, se encuentra el siguiente botón:
Ilustración 169 - Propiedades de Obra Lineal (Civil 3D)
Al pinchar en propiedades, se despliega una ventana donde se puede gestionar varios

parámetros de la obra lineal. El que ocupa este apartado, es el de superficie. La ventana
es la siguiente:
Ilustración 170 Superficie de Obra Lineal (elaboración propia)
Para añadir una superficie hay que pulsar la herramienta recuadrada. La superficie se
genera teniendo en cuenta los datos añadidos por el usuario. Estos datos pueden ser de
dos tipologías: Vínculos o Líneas Características.
Las Líneas Características se generan uniendo los puntos generados en las secciones
trasversales que tienen el mismo código. Es decir, si en la sección el usuario ha diseñado un
punto con un código de punto “Crown” (que señala la coronación de la Carretera) el
programa generará líneas características uniendo todos los puntos “Crown” generados en
las secciones transversales insertadas en la obra lineal. Por lo tanto, Civil 3D genera una
superficie a partir de los planos en los que estas líneas están contenidas.
Los vínculos, son las líneas diseñadas en la sección transversal (a las que previamente, el
usuario le ha dado un código de Vínculo -Enlace-). Si estos vínculos, recorren el eje de la
carretera, se convierte en una superficie.
La metodología recomendada es por línea características, porque el usuario puede
173
controlar perfectamente que forma tiene la superficie. La metodología es la siguiente: el
usuario decide previamente que superficies quiere generar y por los puntos por lo que va a
pasar. Por ejemplo:
Ilustración 171 - Puntos para Superficie (elaboración propia)
Para el movimiento de tierras de los caminos agrícolas hay que generar una superficie que
que pase por lo puntos señalados en la ilustración anterior. Civil 3D ha generado unas líneas
características uniendo esos puntos, por lo que para generar la superficie hay que añadir
esas líneas.
Ilustración 172 - Líneas Características a añadir (elaboración propia)
Como se puede ver en la imagen, esa superficie ya tiene añadida 3 líneas, falta añadir la
línea creada por los puntos más bajos de la cuneta. Para ello, se despliega la pestaña del
174
recuadro rojo, se selecciona la opción de “Ditch_Out” y se pincha en el más del recuadro
negro. Hay que tener en cuenta, que si el usuario está utilizando el Civil 3D en su versión
española (Spain Country Kit) hay ocasiones en las que traduce los vínculos, por lo que
puede que no aparezca con el nombre exacto del vínculo anotado en el subensamblaje.
Una vez que se da a aceptar, la superficie se genera. Esta superficie es muy importante ya
que forma parte de la metodología de creación de sólidos de la obra lineal.
Se recomienda al usuario que genere por eje de carreta la superficie correspondiente a la
coronación de la plataforma. Es decir, normalmente al diseñar un ensamblaje en SAC, los
usuarios solemos añadir Shapes solo a las capas pertenecientes a las capas de pavimento,
dejando representado el desmonte y el terraplén solo con la línea de talud.
Ilustración 173 - Detalle de SAC (elaboración propia)
Como se puede ver en la imagen, debajo de la base existe una zona en la que no he
creado ninguna Shape. Por lo que el terraplén se delimita simplemente por el talud. En
siguientes apartados, explicaré como Civil 3D genera sólidos a partir de una obra lineal,
pero puedo adelantar, que el flujo de trabajo que Civil 3D sigue es una extrusión de todas
las Shape que hay en cada sección transversal
Por lo tanto, el movimiento de tierra no va a quedar constatado por ningún sólido. Por lo
que el usuario debe de tener esto en cuenta. Existen dos formas de solucionar esta
problemática:
La primera opción consiste programar la sección inteligente para que genere Shape
acorde con la línea de talud. La segunda opción es generar una superficie que represente
la envolvente de las capas de movimiento de tierra y extraer sólidos por comparación con
la superficie cartográfica.
Para la realización de este Proyecto piloto se ha elegido la segunda opción, por lo que es
vital generara esta superficie, Por ejemplo, la superficie obtenida de la obra lineal del eje21
es la siguiente:
175
Ilustración 174 - Superficie Obra Lineal 27 (elaboración propia)
12.1.7 Modelado de Estribos en Obras de Paso

Civil 3D, cuando recibe la instrucción de generar una obra lineal, lo hace a lo largo de todo
el eje. Esto en algunas situaciones, no modela la realidad ya que un eje de carreteras o de
vías ferroviaria está llena de obras puntuales que deben de ser reflejadas en un modelo.
Estas obras puntuales deben de ser modeladas por el usuario, y es obvio que Civil 3D no
tiene herramientas directas para modelarlas, pero sí que existen flujos de trabajo, que con
las herramientas que contiene el programa, hacen posible su modelización.
En el caso de los estribos, los taludes en este proyecto se sostienen con un muro de hormigón
donde se apoyan las obras lineales. En el proyecto original el estribo se diseñó:
176
Ilustración 175 - Estribos en un Viaducto en el Proyecto Original (Proyecto Original)
Para modelar esta obra lo primero que hay que hacer es dividir en tramos la obra lineal.
Para modelar este tramo hay que generar 2 ensamblajes: un ensamblaje vacío para dejar
el hueco del viaducto, el último un ensamblaje normal del eje de la carretera.
Ilustración 176 - Ensamblaje Completo (elaboración propia)
177
Ilustración 177 - Ensamblaje vacío (elaboración propia)
Por lo tanto, lo siguiente es dividir la obra lineal. Para ello, se selecciona la obra lineal en el
espacio modelo y se pincha en la herramienta Dividir Región.
Ilustración 178 - Dividir Región (elaboración propia)
Una vez que se activa esta herramienta, el programa pide que el usuario indique los P.K. en
los que quiere dividir el tramo. Por lo tanto, el usuario, tiene que indicar los tramos en los que
quiere dividir la obra lineal. Se tiene que generar un tramo para el viaducto. El flujo va a ser
el siguiente: El talud va a llegar normal hasta el inicio del tramo del viaducto. De tal forma,
que hay que modelar el muro de contención. Para ello, se dibuja la forma en planta del
muro de contención. En el caso de la prueba piloto, se dibujará con polilíneas la forma
indicada en la imagen anterior.
178
Ilustración 179 - Forma en Planta (elaboración propia)
Por lo tanto, hay que modelar un muro vertical que se va a construir desde el terreno hasta
el talud de la carretera. Por lo que, en el modelado, hay que seguir un proceso similar. El
proceso continúa llevando la polilínea a la cota de la superficie. Es decir, el usuario puede
utilizar muchas herramientas para dibujar la planta, pero es recomendable utilizar la
polilínea 3D (3Dpol) ya que a esta línea se le puede asignar una cota. Por norma general,
al dibujar en planta, la cota se va a z=0. Para asignar la cota de la superficie a la polilínea
hay que irse a la ficha Modificar, y en el grupo de herramientas llamado Modificar
Elevaciones se selecciona la siguiente herramienta:
Ilustración 180 - Elevar a Superficie (elaboración propia)
Por lo tanto, se tiene que elevar la línea a la superficie cartográfica (o a la superficie del
movimiento de tierras, el proceso es indistinto). Después, se crea una línea característica a
partir de la polilínea.
179
Ilustración 181 - Crear líneas características a partir de Objetos (elaboración propia)
El siguiente paso es generar una explanación. Se utiliza esta herramienta ya que genera
una superficie con el talud que el usuario quiere hasta una superficie objetivo. Es decir, existe
una línea que pertenece a la superficie cartográfica, desde la que se va a generar una
superficie vertical hasta los taludes de la carretera. Es una herramienta muy buena para
modelar este tipo de obras. Para crear la explanación:
Ilustración 182 - Crear Explanación (elaboración propia)
Una vez que se cree la explanación se generará una superficie vertical con la forma en
planta que el usuario le ha dado, por lo tanto, es una modelización muy similar a la
construida.
180
Ilustración 183 – Modelización (elaboración propia)
Este es un flujo de trabajo que permite una modelización muy similar a la construida en obra
con una productividad elevada ya que es un flujo de trabajo muy corto. En general
recomiendo al usuario intentar resolver los problemas de modelización con flujos de trabajo
relacionados con explanaciones ya que es una herramienta muy útil para poder generar
cambios de taludes y modelar el comportamiento real de los taludes.
12.1.8 Modelado de Obras de Drenaje Transversal

Como ocurre con los estribos de los pasos superiores, Civil 3D no tiene una herramienta para
generar obras de drenaje transversal dentro de una obra lineal. Por lo que el usuario debe
de utilizar las herramientas genéricas que el programa tiene para modelizar el
comportamiento de los taludes y de las piezas de hormigón. En el caso de la prueba piloto
todas las obras de drenaje transversal son de tipo caño
181
Ilustración 184 - Desembocadura tipo Caño (vía Google)
Estas se caracterizan por tener dos paredes verticales que sostienen el terraplén
perteneciente a la obra de carreteras. Y una tercera en la que se contiene los tubos que
guían la corriente de agua. Por lo tanto, en Civil 3D hay modificar el talud de la Carretera
de tal forma que donde se encuentra la desembocadura de la obra de drenaje el talud
pasa a ser vertical hasta que llega al terreno natural
Es decir, constructivamente las obras de drenaje transversal se construyen para salvar un
paso de agua en la traza de una infraestructura de carreteras. Por lo tanto, el suelo de la
obra de drenaje transversal se encuentra a la cota de la superficie cartográfica de la que
nacen las paredes verticales. Esto es principal para modelar la obra de drenaje transversal
en Civil 3D
El flujo de trabajo comienza por el dibujo en planta de la obra de drenaje transversal.
182
Ilustración 185 - Planta de una ODT (elaboración propia)
En esta ocasión ocurre lo mismo que con el modelado de los estribos de un viaducto. Es
decir, es una polilínea con cota z=0 que hay elevar para que pertenezca a la superficie
cartográfica. Por lo tanto, esta es la forma que tendrá la plataforma, ahora hay que generar
las paredes verticales (que tiene un flujo de trabajo muy similar a la generación de las
paredes verticales en los estribos)
Ahora se debe convertir en línea característica para poder modelar la explanación a partir
de este objeto. Para ello, se selecciona la opción “Crear línea característica a partir de
Objeto”.
Ilustración 186 - Crear Líneas Características a partir de Objetos (elaboración propia)
183
Ahora, hay que generar la explanación. Para ello primero se debe de crear el grupo de
explanación con una superficie objetivo que sea la superficie generada con la obra lineal.
La explicación es que tenemos la explanada base y ahora hay que modelar la pared
vertical hasta que corte con el talud de la carretera. Para ello se pincha en “Crear grupo
de explanación”
Ilustración 187 - Crear Grupo de Explanación (elaboración propia)
184
Aquí es importante que el usuario seleccione la creación de la superficie y la superficie base
del volumen. Ya que es esencial para el buen funcionamiento del modelo. Una vez
aceptado, se pincha en “Herramientas de creación de explanación”.
Ilustración 188 - Herramientas de Creación de Explanación (elaboración propia)
Una vez que se despliegue la ventana emergente, se pincha en “crear explanación”. Se

selecciona la línea característica que será base de la explanación. Se selecciona la
dirección en la que se quiere los taludes y se indica que no se aplique a toda la longitud ya
que la parte exterior de la base no tiene pared de hormigón.
185
Ilustración 189 - Lado de Explanación (elaboración propia)
186
Una vez que se indique el tramo en el que se quiere modelar los taludes, se indica la
pendiente de los taludes. Las paredes de la desembocadura son verticales, pero como Civil
3D tiene que hacer operaciones para hallar las intersecciones de dos planos es mejor no
ponerle 0:1 (hay que destacar, que en Civil 3D primero se pone el parámetro horizontal y
después el vertical). Así que se indica por teclado el valor 0.1 (se hace una aproximación
para evitar errores). Una vez que se genere la superficie de la explanación hay que cortar
la superficie de la obra lineal. Para ello se toma como contorno la línea característica de la
que nace la explanación.
El motivo por el que se toma este objeto de contorno es que, un contorno que esté fuera
de la superficie de la explanación provocaría que la superficie de la explanación ya no
encontrase la superficie base (indicada como superficie base al generar el grupo de
explanación) por lo que desaparecería.
Para ello, en la pestaña “Prospector” del espacio de herramientas, se encuentra la
carpeta de los objetos inteligentes “Superficies”. Dentro, se encuentran todas las
187
superficies. En la superficie resultado de la obra lineal, hay que pinchar en “Definición” y
en la herramienta “Contornos” con el botón derecho se selecciona la opción “Añadir”.
Ilustración 190 - Añadir Contorno (elaboración propia)
188
En la ventana emergente se indica el nombre del contorno y el tipo. El tipo debe de ser
“Ocultar” para que desaparezcan los triángulos que se encuentran dentro del contorno.
Una vez que se modifica la superficie de la obra lineal, se debe crear una nueva superficie
donde se pegue la superficie de la obra lineal y la superficie de la explanación. El
resultado es el siguiente:
Ilustración 191 - Resultado Final (elaboración propia)
189
Por lo tanto, el modelado de las paredes verticales del caño ya está completo. Ahora solo
falta el colector central, que es un flujo de trabajo más sencillo. Para crear los colectores
hay que acudir a la herramienta obra lineal. Por lo tanto, como ocurre en los ejes de
carreteras hay que tener previamente definido la planta, el perfil y la sección transversal.
La planta será una alineación recta desde el centro de la pared del caño hasta el centro
de la pared del otro lado del terraplén.
Para el perfil, hay que tener en cuenta el proyecto original y la cota del terreno, como
recomendación el usuario debe de tener también en cuenta el punto de inserción del
ensamblaje ya que debe de asegurarse de que el punto más bajo de colector tiene que
quedar a la cota del terreno natural para facilitar el paso del agua.
La sección transversal puede ser creada con SAC o utilizar algunas de las que Civil 3D
tiene guardada en la carpeta del programa. (Es recomendable que el usuario revise estas
secciones, ya que hay muchas que son muy interesantes para la definición de las obras
lineales). En el caso que nos ocupa, he creado un SAC para cada tipo de obra de
drenaje que existe en el proyecto.
190
El diseño en SAC es muy sencillo, dos círculos que contienen una Shape. Lo interesante de
este diseño es que es paramétrico, por lo que sirve para cualquier diámetro nominal con
cualquier espesor de hormigón
Ilustración 192 - Obra de Drenaje Transversal en SAC (elaboración propia)
Por lo tanto, al generar la obra lineal con esta sección transversal ya está modelado el
colector de la obra de drenaje transversal.
191
Ilustración 193 - Obra lineal del Colector (elaboración propia)
12.1.9 Generación de Sólidos para la exportación de IFC

Una vez que se tiene modelada la obra lineal se pueden generar todos los entregables,
tantos los entregables usados en metodología CAD como los entregables usados en
metodología BIM. Para estos últimos es muy importante exportar el modelo en a un formato
IFC y para ello, se debe de generar un sólido 3D que defina la Carretera.
¿Por qué no se puede usar la Obra Lineal como objeto a exportar a IFC? Simplemente no
se puede, IFC no entenderá que es ese objeto y por lo tanto Civil 3D no lo exporta. Esto
ocurre porque en los formatos actuales no hay ninguna clase que pueda representar la
información que representa la obra lineal. Esto tiene mucho sentido lógico ya que la obra
lineal no es una definición tridimensional como tal de una obra de infraestructuras,
técnicamente es una discretización tridimensional de ella. ¿Por qué? Porque la definición
de la infraestructura está completa en los puntos de inserción de los perfiles transversales,
en el resto de los puntos la obra lineal está vacía.
Por lo tanto, el modelado debe de aumentar un nivel y conseguir así una definición
tridimensional como tal, es decir, un modelo 3D. Para ello, los sólidos juegan un papel
esencial.
Civil 3D tiene una herramienta de generación de sólidos a partir de una obra lineal. Esto
funciona de la siguiente forma; como ya he comentado antes, Civil 3D inserta unas
secciones trasversales cada X metros (dependiendo de lo que el usuario le indique). Estas
secciones transversales (que son producto de los ensamblajes) tienen definidos unas Shape
que son unos planos verticales con la forma que el usuario haya querido darle en su
definición del ensamblaje. Por lo tanto, si un plano vertical recorre un eje se convierte un
sólido tridimensional. Por lo tanto, lo que hace Civil 3D es hacer una sección media entre
dos secciones transversales y extruirla. Así genera un sólido tridimensional
192
Como ya he comentado antes, solo obtendremos los sólidos correspondientes a las capas
de pavimentos (si no hemos creado una sección inteligente que genere los Shape
dependiendo de los taludes de desmonte o terraplén). Por lo que además de generar los
sólidos con la herramienta que Civil 3D tiene asociada a la obra lineal, el usuario tiene que
generar los sólidos asociados al movimiento de tierras. Pero primero, voy a explicar cómo
generar los sólidos de la obra lineal
12.1.9.1 Extrusión de las secciones transversales
Si el usuario gira el espacio modelo y hace zoom en la obra lineal puede ver las secciones
trasversales insertadas en la obra lineal. Como se puede ver en la siguiente ilustración:
Ilustración 194 - Secciones trasversales (elaboración propia)
En el espacio intermedio entre las secciones trasversales, Civil 3D calculará la sección

intermedia (que no será muy distintas a las secciones reales) y la extruirá en ese espacio
vacío. El flujo de trabajo comienza seleccionando la obra lineal, una vez hecho esto se
desplegará la fiche de herramientas del objeto inteligente Obra Lineal. Ahí se puede
encontrar la herramienta de extracción de sólidos
Ilustración 195 Extraer Sólidos de Obra Lineal (elaboración propia)
Una vez que se pinche en esta opción se desplegará una Ventana emergente. En esta
Ventana el usuario tiene que indicar en que tramos de la obra lineal quiere realizar la
extrusión y que códigos quiere extruir.
193
Ilustración 196 - Solidos a extraer (elaboración propia)
En la imagen anterior se puede comprobar que en el primer tramo existe un ensamblaje

llamado Camino. Este ensamblaje es el siguiente:
Como se puede comprobar, solo existe una Shape por lo que solo hay un Código que el
programa pueda extruir. Esto se confirma en la Ventana de Extraer Sólidos a partir de una
Obra Lineal donde solo deja seleccionar al usuario un vínculo de tipo forma (Shape en SAC).
¿Qué es lo que Civil 3D realiza cuando se selecciona un Código? Civil 3D solo extruye los
194
objetos que dentro de las secciones trasversales tiene este Código. Como se puede ver, los
códigos en la elaboración de subensamblajes en SAC tienen un carácter vital. Deben de
ser tratados con un cuidado especial
Se puede comprobar que además del Código de Forma el usuario puede seleccionar dos
códigos de líneas (los códigos que le haya indicado a la línea que modele el talud de
desmonte y de terraplén). Si una línea recorre un eje se convierte una superficie, por lo que
este es el motivo por el que en modelados de obras de Carretera se ve que el movimiento
de tierras Civil 3D lo genera como un “cascarón”, es decir, una superficie hueca.
Mi recomendación es que estas superficies se extraigan para el control de calidad de los
sólidos que se generarán para modelizar el movimiento de tierras (en el siguiente apartado
vendrá explicado el flujo del trabajo) y una vez que se ha comprobado que el sólido es
acorde se eliminen para dejar un modelo limpio en el que solo haya objetos
tridimensionales.
Cuando el usuario le dé a aceptar, la siguiente Ventana le mostrará las propiedades con
las que el sólido se generará. Es muy importante este punto del flujo de trabajo ya que se
pueden aplicar propiedades generales al Proyecto de una forma sencilla. Para ello, el
usuario debe de seleccionar con el botón derecho en Propiedades definidas por el Usuario
a la opción Añadir.
Ilustración 197 - Datos de Propiedades (elaboración propia)
195
El nombre se puede cambiar por el usuario. El problema que tiene generar propiedades
por este flujo de trabajos es que se generan valores vacíos o el usuario puede generar uno
por defecto por lo que no se puede adaptar a cada sólido por separado.
En Opciones de Salidas se puede modificar en que dibujo inserta el sólido y que color le
asigna. Como resultado, queda:
Ilustración 198 Sólido (elaboración propia)
196
Ilustración 199 Propiedades añadidas por el usuario (elaboración propia)
12.1.9.2 Generación de Sólidos Por Comparación
Como he comentado anteriormente, los sólidos para modelar el movimiento de tierra

tienen que ser generados por un flujo de trabajo distintos a la generación de sólidos
perteneciente de las capas de pavimento (Repito, en el caso de que la sección inteligente
no cree Shape dependiendo de la línea de talud del terraplén y del desmonte). Este flujo
de trabajo pasa por generar sólidos como la diferencia que existen entre dos superficies
distintas. Es decir, imaginemos que tenemos dos planos (que al final son superficies planas)
uno a cota z=2 otro a cota z=0 (ambos planos son cuadrados)
197
Ilustración 200 - Superficies Planas (elaboración propia)
Entre esas dos superficies existe un espacio tridimensional vació, resultado de la

comparación entre las dos superficies. Si comparamos estas dos superficies, el espacio
vacío se convierte en un sólido cuadrado tridimensional en el que el plano superior está
contenido en la superficie azul y el plano inferior está contenido en la superficie roja
198
Ilustración 201 - Sólido de Comparación (elaboración propia)
Este proceso tan sencillo se puede seguir para superficies más complejas incluidas las
superficies generadas por triángulos. Por lo que, para generar los sólidos del movimiento de
tierras lo que el usuario tiene que hacer es indicar a Civil 3D que genere un sólido por
comparación. Las superficies que tiene que usar es la superficie extraída de la obra lineal
como envolvente del movimiento de tierras y la superficie cartográfica. Lo cual generará
un sólido que represente de forma fidedigna el movimiento de tierra.
Para ello se selecciona una de las dos superficies y se pincha en la herramienta Extraer
Sólidos de Superficies
Ilustración 202 - Extraer de Superficie (elaboración propia)
Entonces se despliega la siguiente ventana:
199
Ilustración 203 - Extraer Sólido desde Superficie (elaboración propia)
Aquí se indica desde que superficie se quiere generar el sólido y que objetivo tiene este. Es
decir, si el usuario quiere un sólido que tenga un espesor determinado, termine a una cota
determinada o que termine cuando intercepte a otra superficie (este es el recomendado).
Además de las opciones de inserción y de color y capa.
Una vez que el usuario indica las dos superficies y crea el sólido se obtendrá el sólido por
comparación. Es importante saber que esta operación tiene a fallar en algunas ocasiones
debido al proceso matemático el programa realiza (extrusión Booleana). Este error se
soluciona generando otra superficie (por ejemplo, a partir de las curvas lineales de la
anterior) para que los triángulos se regeneren.
Para ver el resultado complete:
200
Ilustración 204 - Sólidos Completos (elaboración propia)
En la imagen anterior se puede ver como el programa ha modelado los sólidos

pertenecientes a las capas de pavimentos y el sólido de movimiento de tierras cortado por
la superficie vertical perteneciente al muro de hormigón del estribo de ese viaducto. Por lo
tanto, es un flujo de trabajo completo y satisfactorio
12.1.9.3 Sólidos completos de la prueba piloto
Este flujo de trabajo tiene una problemática clara cuando se requiere para hacer tramos
complejos de infraestructuras y es la lentitud asociada a los sólidos generados. Cuando un
dibujo contiene un número alto de sólidos, el programa se Vuelve lento y pesado.
201
Para la finalización de este proceso de modelado, he insertado en un dibujo todos los
sólidos extraídos de todos los ejes de la prueba piloto (sólidos de movimientos de tierra, de
pavimentos, de obras de drenaje transversal y de estribos) y se ha convertido en un archivo
muy poco productivo en cuanto al manejo de este. Por eso es importante que el flujo de
trabajo lleve la generación de un modelo Federado en el que cada dibujo contenga la
menos información posible, así conseguir un ecosistema de modelos en los que la
información y la fluidez y productividad sean igual de importantes.
A continuación, se pueden ver imágenes de la prueba piloto completa:
Ilustración 205 - Modelo Completo (elaboración propia)
202
203
204
205
206
207
208
209
12.2 ANEJO II – INFORMACIÓN DE OBRA A INTRODUCIR EN EL MODELO 3D
El equipo de Dirección de Obra fijó para la realización de una prueba piloto, los siguientes
datos de obra que consideraba necesarias para ejecutar una prueba sobre la capacidad
de introducción de información.
Esta prueba permitiría verificar varios aspectos críticos para que los modelos BIM alcancen
la madurez para ser utilizados como base de los proyectos de liquidación en España
(proyectos As Built en terminología anglosajona).
Estos aspectos por tipos de información eran los que continuación se presentan y que
fueron los inicialmente seleccionados:
• Parámetros de calidad de materiales, entre los que destacan valores alfanuméricos
según su naturaleza y Actas de Laboratorio
• Parámetros de control de ejecución, entre los que destacan actas y fotos de
inspección
Tabla 13 - Datos que la Dirección de Obra requiere del Modelo BIM AsBuilt (elaboración propia)
En general todos los objetos tienen como parámetros los siguientes: Código BIM,
Descripción, Tipo de Archivo, Unidad de Medida, Medición, Material y 7 parámetros
adicionales dependiendo del tipo de objeto que sea.
Esta información hay que transformarla para poder implementarla en el archivo de datos
(Beas.xlsx), el cual se puede ver en Tabla 14.
Tabla 14 - Archivo de Datos (Elaboración Propia)
del modelo Empresa Promotora Ministerio de Fomento
Localización N-435
Descripción Modelo As-Built de la variante de Beas
Fecha de Control
ID Lote Control
Conformidad
210
Terraplén Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY
Tipo de Objeto 1
1 Descripción
Nº De Propiedades Nombre en IFC Objeto 895;Objeto 894;Objeto 898;Objeto 896;Objeto 159;Objeto 762;Objeto 154;Objeto 1
11 Inicio
Nº OBJETOS Tipo de Obj Capa Firme
33 Tipo de Archivo C3D
Medición
Material Préstamo
Partes de Ensayo
Tipo/Procedencia
Fotos
Observaciones
CunetaTriangular Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY

Tipo de Objeto 1
1 Descripción Cuneta Triangular
Nº De Propiedades Nombre en IFC Objeto 660;Objeto 674;Objeto 675;Objeto 445;Objeto 446;Objeto 21;Objeto 22;Objeto 20;
11 Inicio
Nº OBJETOS Descripción/Familia Cuneta Triangular
Ud de Medida m3
Medición
Material Hormigón HNE
Partes de Ensayo
Planos Vigentes
Fotos
Observaciones
Surf Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY

Tipo de Objeto 1
1 Descripción Capa de Rodadura
12 Inicio
Nº OBJETOS Descripción/Familia Capa de Firme
Ud de Medida m3
Medición
Material Prestamo
Partes de Ensayo
Planos Vigentes
Fotos
Observaciones
Bin Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY

Tipo de Objeto 1
1 Descripción Capa INT Firmes
12 Inicio
Nº OBJETOS Descripción/Familia Capa Firme AC22 bim BC 50/70 S
12 Tipo de Archivo C3d
Ud de Medida m3
Medición
Material Prestamo
Partes de Ensayo
Planos Vigentes
Fotos
Observaciones
211
Base Tipo de Objeto IFC IFCBUILDINGELEMENTPROXY
Tipo de Objeto 1
1 Descripción Capa Base
Nº De Propiedades Nombre en IFC Objeto 491;Objeto 504;Objeto 569;Objeto 644;Objeto 653;Objeto 664;Objeto 681;
12 Inicio
Nº OBJETOS Descripción/Familia Capa Firme AC32 Base BC 50/70 G
7 Tipo de Archivo C3d
Ud de Medida m3
Medición
Material Prestamo
Partes de Ensayo
Planos Vigentes
Fotos
Observaciones
Este archivo de datos será el que se procesará por el Programa2_ENRIQUECIMIENTO.py

desarrollado en el presente trabajo, para añadir valor al modelo BIM nativo de la Vte. de
Beas, modelado en C3D.
212
12.3 ANEJO III – ARCHIVO IFC DEL MODELO BIM COMPLETO DE LA VTE. DE BEAS
Para verificación de los resultados que proporcionan los programas desarrollados en
lenguaje Python, a continuación, se mostrarán extractos del enriquecido archivo IFC
(090_2020_SOL_completo_v1.ifc). Se muestran solo extractos del fichero dada su enorme
extensión (aprox. 800 páginas) y la repetitividad de las sentencias que definen algunas
clases del formato, por lo que se han hecho elipsis en las partes más repetitivas del formato.
A continuación, se muestran las sentencias del fichero STEP con formato IFC
(090_2020_SOL_completo_v1.ifc), más significativas:
Líneas de código 1-7
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [CoordinationView_V2.0, FMHandOverAddonView, ConceptDesignBIM_2010, QuantityTakeOffAddOnView,
SpaceBoundary2ndLevelAddOnView]','ExchangeRequirement[Architecture]','Option [ExcludedObjects: , , , , , , , , , , , , , , , , , , , ,]'),'2;1');
FILE_NAME('D:\\7_Proyectos Civil 3D\\009_2018 Variante de Beas\\70_IFC\\009_2018_SOL_completo_v1.ifc','2020-07-29T17:24:17',('Angel Diaz'),('',''),'EXPRESS Data Manager
stand alone and remote client system - Version 5.00.0310.07.32mod Sep 15 2011','Autodesk Civil 3D 2019 - Espa\X2\00F1\X0\ol (Spanish) Build 13.0.613.0','');
FILE_SCHEMA(('IFC4X1'));
ENDSEC;
Línea 8-57
DATA;
#1= IFCPROJECT('1nHRIFuVb3WOMpiGQ0Qi1X',#51,'001',$,$,'009_2018_SOL_completo_v1',$,(#11),#31);
#11= IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model',3,2.54000000000000E-8,#27,$);
#27= IFCAXIS2PLACEMENT3D(#15,#23,#19);
#31= IFCUNITASSIGNMENT((#33,#34,#35,#36,#41,#42));
#33= IFCSIUNIT(*,.LENGTHUNIT.,$,.METRE.);
#34= IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#35= IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#36= IFCCONVERSIONBASEDUNIT(#38,.PLANEANGLEUNIT.,'degree',#39);
#38= IFCDIMENSIONALEXPONENTS(0,0,0,0,0,0,0);
#39= IFCMEASUREWITHUNIT(IFCREAL(0.0174532925199433),#40);
#40= IFCSIUNIT(*,.PLANEANGLEUNIT.,$,.RADIAN.);
#41= IFCSIUNIT(*,.TIMEUNIT.,$,.SECOND.);
#42= IFCSIUNIT(*,.MASSUNIT.,$,.GRAM.);
#43= IFCORGANIZATION('','','',$,$);
#47= IFCPERSON('','','',$,$,$,$,$);
#49= IFCPERSONANDORGANIZATION(#47,#43,$);
#50= IFCAPPLICATION(#43,'13.0.613.0','Autodesk Civil 3D 2019 - Espa\X2\00F1\X0\ol (Spanish)','2000');
213
#51= IFCOWNERHISTORY(#49,#50,$,$,$,$,$,1596036036);
#77= IFCSITE('2Z81q9Oyn9Ausmv6JFDRHM',#51,$,$,$,#95,$,$,.ELEMENT.,$,$,0.,$,$);
#93= IFCRELAGGREGATES('1ZzvtmIUzFve6z$_k2eajI',#51,$,$,#1,(#77));
#95= IFCLOCALPLACEMENT($,#102);
#109= IFCALIGNMENT('2YrNZQSblvbm0000400CTF',#51,$,$,$,$,$,#127,.NOTDEFINED.);
#127= IFCALIGNMENTCURVE(#130,$,'Alignment(1)');
#130= IFCALIGNMENT2DHORIZONTAL(0.,(#133));
#133= IFCALIGNMENT2DHORIZONTALSEGMENT(.F.,'','',#135);
#135= IFCLINESEGMENT2D(#138,4.75924900194831,42.2610855068426);
#138= IFCCARTESIANPOINT((694021.986052395,4142675.79249705));
#142= IFCRELCONTAINEDINSPATIALSTRUCTURE('2nk1XaXoHAq8IWrfrHwz0p',#51,$,$,(#109),#77);
#144= IFCBUILDING('0WJLS96FD1f9Gk4l8Ns4DA',#51,'009_2018_SOL_completo_v1',$,$,#162,$,$,.ELEMENT.,0.,0.,$);
#160= IFCRELAGGREGATES('2IsD7eecL5YODUKqhra876',#51,$,$,#77,(#144));
#320= IFCPROPERTYBOUNDEDVALUE('RentalRatesInCategoryNow',$,$,$,$,$);
#336= IFCPROPERTYBOUNDEDVALUE('RentalRatesInCategoryFuture',$,$,$,$,$);
#461= IFCELEMENTQUANTITY('2BG6ufSZ545xn$6MMqC3Zc',#51,'BaseQuantities',$,$,(#468,#471,#474,#477,#480,#483));
#468= IFCQUANTITYLENGTH('Height',$,$,0.,$);
#471= IFCQUANTITYAREA('NetFootprintArea',$,$,0.,$);
#474= IFCQUANTITYAREA('GrossFootprintArea',$,$,0.,$);
#477= IFCQUANTITYAREA('NetFloorArea',$,$,0.,$);
#480= IFCQUANTITYAREA('GrossFloorArea',$,$,0.,$);
#483= IFCQUANTITYVOLUME('GrossVolume',$,$,0.,$);
#488= IFCBUILDINGELEMENTPROXYTYPE('0vo9_QY8T1Duu3iIhyJ9_B',#51,'_None',$,$,$,$,$,$,.NOTDEFINED.);
#498= IFCBUILDINGELEMENTPROXY('2YrNZQSblvbm0000000Bse',#51,'Objeto 1',$,$,#525,#535,$,$);
Línea 58
523=
IFCRELCONTAINEDINSPATIALSTRUCTURE('36pcJsyy55egeUfzErJzfB',#51,$,$,(#498,#75710,#76300,#80749,#87987,#93768,#107136,#122583
,#129905,#162128,#182247,#225733,#226078,#230587,#235096,#246297,#262430,#278563,#367108,#392669,#395238,#402191,#404
536,#405505,#426410,#428995,#430116,#431237,#435854,#440471,#449962,#470895,#473488,#474609,#475730,#480347,#484964,#
516749,#526822,#534691,#539306,#541569,#557752,#570619,#587470,#614797,#636388,#639923,#645702,#649665,#653628,#6677
39,#674965,#683595,#690221,#734130,#736679,#738583,#743689,#752301,#759449,#766673,#769217,#771121,#772463,#776105,#778
667,#786295,#791077,#794003,#795757,#807089,#1056577,#1076297,#1109505,#1139181,#1152245,#1169661,#1173909,#1178525,#1183141,
#1207249,#1215705,#1225441,#1228265,#1262497,#1265721,#1267593,#1269377,#1271153,#1276133,#1281133,#1303201,#1307153,#1310765,#
1640389,#1643469,#1666293,#1704345,#1711009,#1712041,#1734721,#1756009,#1763829,#1766893,#1771285,#1788849,#1798841,#1800885
,#1803953,#1805801,#1807637,#1809769,#1811049,#1812885,#1815017,#1816793,#1850577,#1884193,#1924209,#1943165,#1976837,#201227
7,#2038653,#2040365,#2041797,#2044069,#2045217,#2046761,#2048441,#2049985,#2079437,#2093345,#2110173,#2157313,#2179509,
#2206409,#2222645,#2230281,#2239317,#2249161,#2253773,#2259309,#2283589,#2295021,#2308937,#2316219,#2320413,#2322359,
214
#2323333,#2324083,#2327721,#2333979,#2335449,#2350567,#2357233,#2359903,#2363837,#2364159,#2375549,#2393531,#24042
21,#2419951,#2423269,#2428579,#2450389,#2450871,#2469969,#2483843,#2487197,#2491839,#2497045,#2497227,#2498297,#25085
43,#2519721,#2529955,#2531083,#2532211,#2556707,#2557739,
La sentencia anterior es muchos más extensa, indicando más objetos (#nnnnn) del modelo
BIM.
Línea 59- 2.847.328
A continuación, se muestran el grupo de sentencias (definición geométrica de un objeto)
que se repetirá tantas veces como los 967 objetos que tiene el modelo BIM.
Se repetirán grupos de sentencias análogas hasta el final de este lote de sentencias
(2.847.328)
#535= IFCPRODUCTDEFINITIONSHAPE($,$,(#539));
#539= IFCSHAPEREPRESENTATION(#75538,'Body','Brep',(#75525));
#545= IFCFACE((#566));
#550= IFCCARTESIANPOINT((693297.483849685,4140907.6045105,75.5103991241985));
#554= IFCCARTESIANPOINT((693297.546715093,4140907.59005404,75.507716247552
Línea 2.847.329 – 2.861.213 (final del archivo)

El último grupo de sentencias (propiedades de objeto), que análogamente se repetirán
2.226 veces, y que han sido añadías por el programa 2 (Programa2_ENRIQUECIMENTO.py)
#10000000= IFCPROPERTYSET('2YXqgsVV55pRwSMf010000001'
,#51,'Pset_Terraplén',$,(#10000001,#10000002,#10000003,#10000004,#10000005,#10000006,#10000007,#10000008,#10000009,#10000010,#10000011));
#10000001= IFCPROPERTYSINGLEVALUE('Código BIM',$, IFCTEXT('330.01.23'),$);
#10000002= IFCPROPERTYSINGLEVALUE('Tipo de Obj',$, IFCTEXT('Capa Firme'),$);
#10000003= IFCPROPERTYSINGLEVALUE('Tipo de Archivo',$, IFCTEXT('C3D'),$);
#10000004= IFCPROPERTYSINGLEVALUE('Ud de Medida',$, IFCTEXT('Metros Cúbicos'),$);
#10000005= IFCPROPERTYSINGLEVALUE('Medición',$, IFCTEXT(''),$);
#10000006= IFCPROPERTYSINGLEVALUE('Material',$, IFCTEXT('Préstamo'),$);
#10000007= IFCPROPERTYSINGLEVALUE('Partes de Ensayo',$, IFCTEXT(''),$);
#10000008= IFCPROPERTYSINGLEVALUE('Tipo/Procedencia',$, IFCTEXT(''),$);
#10000009= IFCPROPERTYSINGLEVALUE('Fotos',$, IFCTEXT(''),$);
#10000010= IFCPROPERTYSINGLEVALUE('Observaciones',$, IFCTEXT(''),$);
#10000011= IFCPROPERTYSINGLEVALUE('',$, IFCTEXT(''),$);
#10000013= IFCRELDEFINESBYPROPERTIES('2YXqgsVV55pRwSMf010000013', #51,'Properties',$,(#11267044),#10000000);
215
216

Desarrollo de Un Algoritmo para La Incorporación Masiva de Datos A Los Modelos Bim de Obras Civiles

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Desarrollo de Un Algoritmo para La Incorporación Masiva de Datos A Los Modelos Bim de Obras Civiles

Cargado por

Copyright:

Formatos disponibles

Trabajo de Fin de Grado

DESARROLLO DE UN ALGORITMO PARA LA

Dpto. Construcciones Arquitectónicas I

DESARROLLO DE UN ALGORITMO PARA LA

Dpto. de Construcciones Arquitectónicas

Autor: Ángel Díaz Murillo

Tutor: Blas González González

Acuerdan otorgarle la calificación de:

El Secretario del Tribunal

El presente trabajo se ha enfocado a investigar sobre la tecnología BIM aplicada a las

Tabla 1 - Fichero XLS de entrada de datos (elaboración propia) 94

1.1 Alcance del Trabajo

encontrado una de las razones para abordar este trabajo de investigación.

1.2 Objetivos del trabajo

2 APROXIMACIÓN A LA METODOLOGÍA BIM

2.1 Trabajo colaborativo

2.3 Visualización de la futura Realidad a construir

9 realizado por la empresa consultora TEAM BIM CIVIL S.L.

A continuación, se detallan los que se consideran necesarios para las infraestructuras

2.5 Usos de BIM

Con la entrada de la tecnología BIM, esta forma de programar y planificar ha sido

Para poder hacer una simulación de construcción (con el modelado 3D de la obra, es

3.1 Modelado de una obra de carreteras construida

mediante la conversión de un proyecto CAD de carreteras, (utilizando los entregables del

Este estudio será el que me permita analizar en que contenedores de información se

3.3 Desarrollo de los programas

lenguaje de programación multiparadigma, ya que soporta orientación a objetos,

Cuando el algoritmo esté completo, se hará test de funcionamiento mediante la ejecución

3.4 Herramientas informáticas para utilizar

4.1 Trabajos académicos

4.1.1 Modelos BIM de obras civiles

4.1.2 Otros modelos BIM

1) Bravo Sánchez, Alberto - Establecimiento de los criterios de diseño de zonas

4.2 Artículos en Revistas Científicas

Ministerio de Ciencia e Investigación

De las relaciones obtenidas de tan extensa producción científica, se ha realizado una

information exchange process

5.1 Descripción del Proyecto de Construcción

5.2 Estudio inicial del modelado

5.3 Los Accesos Directos a Datos

5.4 Estrategia de modelado en C3D

6.1 ¿Qué es el estándar IFC?

6.2 Estructura básica del IFC

6.2.2.1 Atributos predeterminados

Las propiedades de IFC se pueden formular en general utilizando atributos

6.2.2.2 Parámetros predeterminados

Todos los parámetros predeterminados definidos en el formato IFC es proporcionada por

El nombre exacto de los parámetros se encuentra en la documentación de la

6.2.3 Las superclases en IFC

realizaría una descripción de estas.

BuildingSMART define el ifcObjectDefinition así “IFCObjectDefinition es un supertipo abstracto,

Ilustración 26 - Herencia de IFCRelationship (vía BuildingSmart.org)

BuildingSmart lo define como “la definición de propiedad, IfcPropertyDefinition, es la generalización de

En la herencia, se puede ver que la entidad IFCPropertyDefinition tiene dos subentidades:

B) IFCPropertyTemplateDefintion: es una generalización de todas las propiedades y

La definición del conjunto de propiedades puede ser la de “Conjuntos de propiedades extensibles

6.3 Mapeo de clases

6.4 Esquemas IFC utilizados

6.4.1 Esquema del estándar IFC 2x3

Si por ejemplo examinamos, la extensión de PRODUCTOS, podemos observar las entidades

6.4.2 Esquema del estándar IFC 4x1

Ilustración 37 - Herencia del IFCRelationsip (Elaboración propia)

La diferencia más notoria entre ambos estándares se encuentra en la definición de vista de