Entrant details
Role or Job Title on the Project
Project Manager
Employer
Ineco (Ingeniería y Economía del Transporte)
Madrid, Spain
Employer Role
Architecture or Engineering Company
Are you or your employer a member of buildingSMART?
Yes - Chapter Member
Submission details
Submitting Party Company Name
Ineco
Submitting Party Company Location
Madrid, Spain
Submitting Party Role on Project
Promoter/Developer
Submitting Party Company Website
Full Project Name
InBIM - BIM for Linear Infrastructure
Project Location (Country)
Spain
Project Objectives
Research, development and innovation project focused on develop software capable of automatically generate BIM models of existing roads in IFC format (openBIM).
Using information obtained by scanning the road, or with inventory data, or with data from the computer files of the construction project if available, the software (InBIM) is a tool that allows BIM models generation for the thousands of kilometers of existing roads (already built), with the intention that the maintenance and operation of these infrastructures can be done with BIM without the need to redraw them line by line with a layout software.
openBIM Achievements
InBIM generates .IFC files containing BIM models in IFC4Add2 format, generates openBIM, so that they can be imported by any IFC-compatible software.
InBIM focuses only on the automatic generation of the openBIM model in a few minutes or hours for an existing road, so that companies or organizations responsible for its management and operation, can work with the BIM model regardless of the software they use.
With the use of IFC4Add2, our models enable:
- Interoperability
- Open formats
- Collaborative workflows
- Flexibility in the choice of technology to be used by each organization.
openBIM used
IFC4, ifcXML
Software used
InBIM (INECO's own development).
Strategic Alignment
Thanks to openBIM, organizations responsible for the maintenance and operation of existing roads, can use our BIM models with the BIM software they already have or that is of their preference, without having to purchase new software.
This means that thanks to openBIM, the .IFC files containing the road models generated by our software are of interest to any organization, if they want a BIM model of their road we provide it, they only need our file and nothing else, they don't have to worry about the software to be used.
Highlights
- Kilometre point from 116 to 120 on A-92 highway (Spain), has been scanned by Mobile Mapping System, and with the data obtained our software (InBIM), has generated the openBIM model of this road section. The resulting IFC file is opened with MicroStation Suite, BIMVision, Solibri, Naviswork, OpenBuilding, OpenRoad, etc.
- Data from the 16 km layout files of the Beas-Trigueros variant road of the N-435 (Spain) have been exported to Excel. Our software has used the Excel files and has generated an IFC file with the 16 km model. The resulting IFC file is opened with MicroStation Suite, BIMVision, Solibri, Naviswork, OpenBuilding, OpenRoad, etc.
- Models are generated in minutes, e.g. the IFC file with the 16 km road model is generated in 9 minutes.
- Models contain road information every meter, such as axle coordinates, number of lanes, lane width, shoulder width, berm width, longitudinal slope, transverse slope, radius of curvature, etc. They also incorporate vertical and horizontal signalling, protection barriers, milestones, beacons, etc.
Project Address
Our project has consisted of developing a software (capable of automatically generate BIM models of existing roads), no physical work has been done or a building project in a specific address, so there is no building project address as such.
We have only used a physical infrastructure in the validation tests. To validate our software, openBIM models of 2 road in Spain have been generated:
KP from 116 to 120 on A-92 highway (Spain)
Beas-Trigueros variant road of the N-435 (Spain)
Project Type
(Other)
Size of Project
The development of our software InBIM presents the following data:
48.000 lines of code, 3 external libraries used, 7000 working hours, 9 engineers involved from different specialties (6 IT engineer, 2 Civil engineer, 1 Aeronautical engineer), budget (400.000 €).
Our openBIM road models include the following elements: Lanes, outer and inner roadsides (verges), outer and inner shoulders (berms), median crossover, longitudinal lines, traffic signs, half-gantries, gantries, edge milestones, directional panels, milestones sign, delineator posts and protection barriers.
Regarding the roads generated to validate the software these are the main figures:
A-92: 4 km (KP 116-120), built between 1990 and 1992. The dual carriageway has two two-lane roads, each 3.5 m wide, outer verges of 2 m and inner verges of 1 m, a median of 4 m wide, minimum radius in curves of 700 m and maximum slopes of 2.8%.
Variant Beas-Trigueros: 16 km (under construction). The road has one two-lane carriageway, 3.5 m wide each, 1.75 m verges, minimum radius in curves of 1,000 m, maximum slopes of 3%.
Detailed description of the project
Approach and challenges:
Currently, there are software tools with which to carry out a new road project in BIM. So in principle, there are no problems in sight for the realization of new construction projects in BIM.
Where can the PROBLEM be then?
One of the main reasons why legislators bet on BIM, if not the main one, is that it will be a fundamental tool for the maintenance and operation of the infrastructure once it is built. Therefore, if indeed BIM is not only a tool for construction, if we have to change our way of working because BIM brings a substantial improvement in the subsequent management of the infrastructure, in its operation phase… What do we do with the roads that already exist? How can the administrations and companies responsible for maintenance and operation obtain BIM models in a fast, automated and economic way?
There are currently techniques that allow scanning a road and obtaining all its geometric information at a rate of 300 km/day. How can BIM models be obtained using this information? This was the first challenge that Ineco faced at the beginning of the project.
It should also be noted that construction projects for roads built in recent decades have been carried out using software, and these software files contain the information needed to generate the BIM model. There are also road management systems that contain a lot of road information. Can the information contained in these tools be used to generate the BIM model? That was Ineco's second challenge in this project.
Result:
Ineco has developed an application that, based on data obtained through mobile mapping or digital media, is capable of generating an openBIM model of the road.
IFC4 (IFC 4.0 Add 2 TC1) has been used for this purpose, so that the model generated can be used by any software.
Since our BIM models are designed to be used in the exploitation phase (not for construction), we have chosen to obtain LOD 200 models which is sufficient for the maintenance and exploitation tasks of a road. In terms of performance and economy, InBIM is capable of generating at least 300 km of road per day.
How we did it:
As an initial step and before undertaking the development of the application, the final result to be obtained was defined, so the following requirements were established:
- The road assets that would be the object of the study and we would afterwards incorporate to the model.
- The LOD (Level of Development) that we would reach in the final result.
- For each asset of the IFC, the attributes associated with the IFC were defined.
The necessary input data to feed the application are supplied from GIS files (shapes files) whose information reflects what was captured in the point cloud generated in the mobile mapping (for A-92 highway), or from Excels files in which the information from the construction project files was exported (for variant in N-435 road).
Having defined these considerations and the format and structure of the input data, the cycle for creating the complete openBIM model is explained below.
First, the standard general structure of any IFC4 (IFC 4.0 Add 2 TC1) file is created, and it is fed with the most general data that is not associated with any geometric asset of the road. This data corresponds to the information about the file, the application, the author of the model, the place where the road is framed.
Then, for each asset making up the road, a distinction was made between the non-geometric information and the geometric information. The process creates each asset, adding these two types of information and integrating it into the final model.
Non-geometric information consists mainly of information on the attributes of the assets, which is included in the PropertySet, and information on the type of asset that is included in the type relationships.
On the geometric information, that is to say, the information within the model that defines how it is visually represented in IFC, different strategies have been used, depending on the type of asset to represent. Depending on the strategy used, the objects can be divided into:
- Fixed dimensions assets: They are elements of known dimensions and that do not change from one instance to another of the same element. Thus we have approached the representation of vertical traffic signs, directional panels, milestones sign, delineator posts, ...
- Variable dimensions assets: These are elements in which, for each instance, their spatial dimensions are different. This strategy has been used to represent assets of the lanes, protection barriers, lateral road sign, half-gantry, gantry, ...
To represent each of these possibilities in IFC, different techniques have been used to generate the geometry.
In the case of assets with fixed dimensions, a library of objects has been created with the predefined geometric figure for each type of asset, and when we want to represent an asset of this type, we assign it the representation that corresponds to it from the library, and this representation is positioned and oriented in the model according to what is indicated by the input information.
In the case of assets with variable dimensions, not being able to have a predefined geometric figure at the library of assets to use, it has been necessary to create a different representation procedure for each type of element, and for this procedure to accept the dimensions of the element as input and thus create the representation with the exact measurements for each instance of each element.
Detailed description of openBIM on the project
Overview:
During the InBIM development (2017-2019), IFCRoad standard was not finalized. So, the development of our project was based on the latest released standard: IFC4Add2.
To represent the elements that make up the road, in IFC4Add2 we had several entities dependent on the entity ifcElement, and we chose the following ones:
- IfcCivilElement for lanes, shoulders and paint lines.
- IfcGeographicElement for the other elements such as signs, fenders, directional panels, ...
Construction of the IFC file:
InBIM generates the IFC file by following these steps:
- Creation on the file structure with the associated general information.
- Creation of each element:
a) Geometric information
b) Semantic information, PropertySet
c) Relationship information, type assigned to each element
- Element Integration in the complete model.
Each step is explained below.
- Creation on the file structure with the associated general information
The following features have been included:
IfcProject
In an exchange structure it provides the root instance and context for all other included information elements.
The context provided by the IfcProject includes
- The default units of the project.
- The geometric representation context for exchange structures that include shape representations.
- The coordinate system of the project.
- The dimension of the coordinate space
- The accuracy used within the geometric representations.
IfcGeometricRepresentationContext
Defines the type of context in which the representation of the form and the numerical precision applicable to the geometric representation elements defined in this context are defined.
IfcSite
A site may include a definition of the single geographic reference point for this site (global position with WGS84 with longitude, latitude and elevation). The Longitude, Latitude, and Elevation sets the point in WGS84 where the 0., 0., 0. point of the IfcSite LocalPlacement is located.
IfcOwnerHistory
It is used to identify the application and the user of creation and ownership of the associated object, as well as to capture the last modification application and the user.
IfcPerson, IfcOrganization, IfcApplication
They define respectively a person, an organization and an application within the IFC.
- Creation of each element:
a) Geometric information
Depending on the type of element to be represented, two different modes have been used:
- Fixed dimension elements: elements of known dimensions that do not change from one instance to another of the same element. This is for vertical traffic signs, directional panels, milestones sign and edge milestones.
- Elements of variable dimensions: elements in which, for each instance, it is necessary to know their spatial dimensions. This is for lanes, protection barriers, lateral road sign, half-gantry, gantry, ....
For the elements with fixed dimensions, a library of elements has been created with the predefined geometrical figure for each type of element, and when we want to represent an element of this type, we assign it the representation that corresponds to it from the library, and this representation is positioned and oriented in the model according to what is indicated by the input information. For this purpose, the IFC entities IfcCartesianPointList3D and IfcTriangulatedSet have been used. With the combination of both, the external surface of almost any geometric element can be represented, forming a mesh of points that covers the object.
For the elements with variable dimensions, as it is not possible to have a library of elements to use, it has been necessary to create a different representation procedure for each type of element, and for this purpose the IFC entities IfcCartesianPoint, IfcPolyLoop, IfcFace, IfcFaceTedBrep, IfcClosedShell, IfcFaceOuterbound, etc. have been used.
This way of representing the geometric elements is much more flexible than the form used by the IfcTriangulatedSet, but at the time of programming the application it is much more demanding, so it is only used for those elements in which it is strictly necessary.
b) Semantic information, PropertySet
Each type of element has a different set of associated characteristics, its PropertySet.
InBIM uses the IfcProperty entity of the IFC standard to host the information, which includes the following extensions:
IfcComplexProperty (Properties that are formed by other simple or compound properties)
IfcSimpleProperty, which has the following types: IfcPropertyBoundedValue, IfcPropertyEnumeratedValue, IfcPropertyListValue, IfcPropertyReferenceValue, IfcPropertySingleValue, IfcPropertyTableValue.
c) Relationship information, type assigned to each element
Even with the limitations mentioned above, relationships can be established at IFC that indicate an associate of the element. This is done with the IfcCivilElementType entities and the IfcGeographicElementType entity.
With them we have defined new types and later associate them to the elements that are of that type. A customized type has been created for each element type, leaving the relation like this:
IfcCivilElementTypes:
INFRADAPT_IfcArcen (for roadsides-verges)
INFRADAPT_IfcCarril (for lanes)
INFRADAPT_IfcBerma (for shoulders-berms)
INFRADAPT_IfcLineaLongitudinal (for longitudinal lines)
Types of IfcGeographicElement:
INFRADAPT_IfcDefense (for protection barriers)
INFRADAPT_IfcPanelDireccional (for directional panels)
INFRADAPT_IfcHitoArista (for edge milestones)
INFRADAPT_IfcHitoKm (for milestones sign)
INFRADAPT_IfcBanderola (for gantries)
INFRADAPT_IfcCartel (for half-gantries)
INFRADAPT_IfcSenalVertical (for traffic signs)
This action of defining types in the elements, in addition to providing information to the object, fulfils the function of allowing a more granular classification in the future. In other words, when future Ifc standards create their own IFC types derived from IfcCivilElement and IfcGeographicElement, thanks to this type classification it will be easier to adapt InBIM to work with these new elements.
- Element Integration in the complete model
Finally, when an element is completed, that is, geometrically, with its associated semantic information and type, it must be included in the BIM/IFC general model.
In order to include it in the model, it is necessary to take into account the positioning information where to include it. This is done through the entity IfcPlacement and in our case, in which we are always working in 3 dimensions, it is done using the entity IfcAxis2Placement3D.
Benefits from using openBIM
FIRST BENEFIT: openBIM has made it possible to create our BIM models.
The IFC standard has the necessary elements to build our BIM models. As mentioned in one of the previous sections, InBIM builds the BIM model in different steps, and for each of them the IFC standard provides us with the necessary entities and types, being the relationship between the steps and IFC resources the next one:
- Creation on the file structure with the associated general information.
Use the following IFC resources: IfcProject, IfcGeometricRepresentationContext, IfcSite, IfcOwnerHistory, IfcPerson, IfcOrganization, IfcApplication.
- Creation of each element:
a) Geometric information
Use the following: IfcCartesianPointList3D, IfcTriangulatedSet, IfcCartesianPoint, IfcPolyLoop, IfcFace, IfcFaceTedBrep, IfcClosedShell, IfcFaceOuterbound, etc.
b) Semantic information, PropertySet
Use the following: IfcProperty, IfcComplexProperty, IfcSimpleProperty, IfcPropertyBoundedValue, IfcPropertyEnumeratedValue, IfcPropertyListValue, IfcPropertyReferenceValue, IfcPropertySingleValue and IfcPropertyTableValue.
c) Relationship information, type assigned to each element
Use the following: IfcCivilElementType and IfcGeographicElementType
- Element Integration in the complete model.
Use the following: IfcPlacement and IfcAxis2Placement3D.
SECOND BENEFIT: Software independence
InBIM can generate BIM models of thousands of kilometers of road each week, and since the model created is openBIM, our customers are interested because they can use the models without having to change their BIM software.
Small administrations with few resources, if they have no other means can use any of the powerful free software offered by the market and work directly with our road models. The software to work with our models will never be a problem.
THIRD BENEFIT: Collaborative workflows
InBIM is a tool that allows collaborative work, ensuring that all agents involved in the project can use our openBIM files and continue working with their BIM tools, without harming the flow of collaboration between different users.
GENERAL BENEFIT: Interest of our clients
It can be concluded that the main benefit is the interest of our customers in our product. The fact that our models are openBIM has generated interest for several of our clients by having the possibility of obtaining BIM models of their existing infrastructures without having to worry about the necessary software for their management.
"We were able to innovate using openBIM."
Innovation is part of InBIM's DNA, as it was born from the Infra_Adapt project, a collaborative R+D+i project belonging to the FEDER (ERDF) – INNTERCONECTA 2016 ANDALUSIA PROGRAM, and subsidised by the CDTI (Centre for the Development of Industrial Technology), and supported by the Spanish Ministry of Economy, Industry and Competitiveness.
What was the innovation?
The innovation was twofold:
On the one hand, we innovated to automatically obtain openBIM models using existing digital data (inventories, digital project support, roads management systems, GIS, etc.), or, when no digital data exists, obtaining them with scanning technologies such as Mobile Mapping System.
On the other hand, we innovated so that the result would not be a proprietary system. From the beginning, we sought to obtain directly an IFC-openBIM file compatible with any software.
How the innovation was achieved:
- By analyzing how to automatically compose a BIM model composed of thousands of objects.
- Analyzing which parameters are necessary to define each object from a geometric, semantic and data relations point of view.
- Analyzing which tools could offer us the environment and the structure capable of satisfying the previous points.
- Adopting and applying the tool that enabled us to meet our objectives, applying the IFC4Add2 standard. We studied the different entities and types existing in IFC4Add2 and discovered that it covered all the sections we needed to develop InBIM.
As a result, we developed a tool that allows the integration of existing roads when we want to use the BIM methodology for their management. Without a tool like InBIM, it is very difficult for administrations to obtain BIM models of the thousands of km of existing roads they must manage. If a solution like InBIM is not used, do administrations have to manage new roads with BIM and old roads with another system? We have given the possibility to include old roads in the BIM world.
In addition, the methodology we have applied and the knowledge we have acquired, allow us to develop a module for railways that makes it possible to generate openBIM models automatically for the already existing railways.
For all this, InBIM is a 100% innovative tool that allows to bring all the benefits of the OpenBIM methodology to any of the users involved in the operation and maintenance of roads, both new and old.
"We were able to identify where we need openBIM to develop further."
Identification of openBIM development needs
As it is logical when trying to generate road BIM models in IFC standard, we identified a low development for linear infrastructures in IFC4Add2 standard.
In the years when Ineco developed InBIM, the hierarchy of IFC4 entities for building was well developed, in fact ifcBuildingElementType was refined to include at least 21 lower level entities. However, the ifcCivilElementType entity did not incorporate any lower level entities that would allow for more detailed model information.
Obviously, we were not the discoverers of this need, this situation was well known and there were already working groups to solve it.
Using further openBIM development in InBIM
Although we at Ineco are happy to have achieved our goal through IFC4Add2, if the version of IFC housing specific entities within ifcCivilElementType had been released, we would have incorporated them into our project and thus ensured that our IFC files were interpreted in a more homogeneous manner by the different software on the market.
Currently our BIM models are understood by most of the BIM software on the market, however, due to the low detail of definition of the road entities, the interpretation made by each software is different, and as a consequence, the model does not behave in the same way when we use different software.
BIM Uses were defined on the project
I agree to be contacted about the project BIM uses outside of this awards program.
Stakeholders
CDTI (Centro para el Desarrollo Tecnológico Industrial, E.P.E.), Madrid, Spain,
https://www.cdti.es, Sponsor, Jorge del Pozo Martín
AZVI, Seville, Spain,
https://www.azvi.es, Maintenance Highway A-92 responsible. Provides Highway to test our software InBIM., Domingo Pérez Mira
INGENIERÍA INSITU, Lugo, Spain,
https://ingenieriainsitu.com/, Gets data from the Highway A-92 by Mobile Mapping System., Pedro Arias-Sánchez
FERROVIAL AGROMAN, Madrid, Spain,
https://www.ferrovial.com, Construction company. Provides project data on the Beas-Trigueros variant road of the N-435, Francisco Javier Royo Abancens
