Advancing Cultural Heritage Structures Conservation: Integrating BIM and Cloud-Based Solutions for Enhanced Management and Visualization

Abstract

Preserving and managing historical cultural heritage necessitates innovative approaches that harmonize technology with historical documentation. This paper presents a case study showcasing an adaptable online database tailored for the incorporation of Building Information Modeling (BIM) models and associated historical records. Notably, this approach offers distinctive integration with historical data, enabling users to contextualize heritage assets historically. The study delves into the database’s capabilities, focusing on its role in cultural heritage structure management. It explores interactive exploration, semantic querying, and attachment features, highlighting BIM’s potential in digital conservation, documentation, and archival efforts for historical structures. Additionally, the paper underscores the database’s significance as a valuable tool for education, research, and collaboration among heritage professionals and the public. While addressing specific modeling challenges, it emphasizes the importance of enhancing software solutions to elevate historical asset management. Historical BIM emerges as a powerful resource bridging the gap between historical structures’ conservation and modern technology.

1. Introduction

Cultural heritage structures stand as a testament to our shared human history, encapsulating centuries of architectural marvels and societal evolution. However, preserving and managing these treasures pose significant challenges, particularly when dealing with historical assets characterized by incomplete data and complex architectural histories [1,2,3]. As technology continues to advance, innovative solutions have emerged to address these challenges and aid in the management and conservation of historical assets.

One such solution is Historical Building Information Modeling (HBIM) [4,5], a versatile online database tailored to address the unique challenges associated with cultural heritage structures management. This pioneering approach seamlessly integrates Building Information Modeling (BIM) models with geographic data, allowing users to visualize historical structures in intricate detail and contextualize them within their geographical surroundings. Such geographic awareness is especially valuable for heritage sites, enabling precise mapping and documentation of historical landmarks [6,7,8].

Within this context, we must recognize the inherent challenges of working with historical assets, from incomplete data to complex architectural histories. These challenges emphasize the importance of continuous software enhancements to accommodate the unique needs of Cultural Heritage preservation against disruptive events such as seismic events.

This paper delves into the multifaceted features of HBIM, shedding light on its capabilities and potential impact in the realm of cultural heritage structures management. We explore its interactive exploration functionalities, allowing users to immerse themselves in BIM models with intuitive 3D visualization, as demonstrated through the case study of the San Felice sul Panaro fortress. Additionally, we discuss its semantic querying capabilities, providing structured access to vital information about historical assets.

The core contribution of this study lies in addressing the challenges of working with technical and historical documentation that are typically heterogeneous for existing structures such as historical assets and providing practical insights, methodologies, and tools to overcome these challenges, thereby improving heritage preservation and rehabilitation. The paper underscores the role of HBIM as a catalyst for cultural heritage structures conservation and the need for continuous software enhancements to bridge the gap between historical preservation and modern technology.

The paper will further highlight the potentialities of this approach to allow interactive exploration, semantic querying, and attachment functionalities, demonstrating how BIM technology significantly contributes to the digital conservation, documentation, and archiving of historical structures. It emphasizes the role of this database as a valuable tool for education, research, and collaboration in the field of heritage preservation. Furthermore, specific modeling challenges and the need for software enhancements are addressed, with an aim to improve historical asset management.

The paper is organized as follows: In Section 2, the paper introduces the case study: the Medieval fortress of San Felice sul Panaro, recently damaged by a powerful earthquake. Section 3 outlines the modeling methodology, which involves the compilation of available documentation and the vectorization of historical plans. The logical organization of the BIM database is also discussed. Section 4 deals with the logical organization of the BIM database, while Section 5 describes the semantic enrichment using patch-like objects. Section 6 then introduces ‘Inception’, a versatile online BIM Database for historical cultural heritage management and, explores the BIM adaptation to seamlessly propagate information through databases. Some concluding remarks end the paper.

2. Case Study Description

The fortress, as shown in Figure 1, is situated in the town of San Felice sul Panaro, within the province of Modena in the Emilia-Romagna region.

One of the initial steps when approaching restoration work is to define the history of a building. Additionally, according to Italian legislation, the attribution of the confidence factor is necessary in the case of structural assessment. Understanding when a building was constructed and how it evolved over the centuries can aid in defining its characteristics, including the techniques and materials used. In HBIM modeling, these elements collaborate to establish relations among various components and enhance their semantics within the mock-up.

However, it is important to note that documents should not be taken for granted. Discrepancies often exist between what was designed and what was built. In the past, both architecture and construction were based on oral transmission of knowledge and empiricism, resulting in uncertainties in design. This is particularly evident in the case of castles and fortresses, which continuously evolved to adapt to new weapons and siege techniques. The fortress we see today, see Figure 1, represents the final stage of its evolution and is just a portion of what the defensive system of San Felice sul Panaro used to be in the past. Here, we present its historical journey.

When the Etruscans and later the Romans arrived, around the late Bronze Age, the region was already sparsely populated by the Umbri, likely due to its inhospitable nature, characterized by swamps. Both populations may have attempted to apply their knowledge of hydraulics to drain some land, but there is little evidence of their settlements in the area, except for some Capuchin tombs and countryside villas. San Felice does not exhibit the typical Roman city plan with a chessboard layout, nor is it easily discernible in the surrounding landscape. Although some historians in the eighteenth century dated the foundation of San Felice to the sixth century CE, this hypothesis has been abandoned today due to the absence of supporting evidence [9].

The earliest recorded mention of a defensive structure at the site of the fortress dates back to 927 CE, when it was referred to as castellum Sancti Felicis. It is cited four more times until 1195, using the terms castellum or castrum [9]. However, these references provide only circumstantial information, offering little insight into the structure’s origins, exact location, or form. When the Carolingian Empire had come to an end in 887, its unity and power were dismantled, leading to a tessellation with very small entities that favored raids from barbarians. Then, these sparse buildings needed protection, and the feudal lords had economic and political interests to keep them safe, so they started building up defensive structures. This phenomenon is called castellation and drove the flourishing of castles all over Europe between the ninth and eleventh centuries. According to the results of archaeological campaigns conducted in the early 2000s [10], the sector beneath the municipality house and the fortress shows traces of settlements that could be consistent with the definition of castra, which were defensive structures made of wood and rammed earth.

Throughout its history, San Felice remained under the influence of Modena and subject to its fate. Consequently, during the turbulent period around the turn of the fourteenth century, the region descended into chaos. The fortress changed hands multiple times, witnessing skirmishes, raids, and sieges [11]. While many chronicles recount these events, emphasizing the castle’s strategic significance and sometimes its strength, there is little information about its actual structure.

After nearly six decades of instability and frequent changes of leadership, the castle came into the possession of the Este family in 1338. Two years later, Marquis Obizzo III decided to bolster the castle by constructing a fortress [12]. While original documents regarding this construction are missing, archaeological excavations suggest a dating in the 1340s [11,12].

Historical chronicles indicate that the fortress was designed by Marquis Della Taude and is often referred to as Zirone, a vernacular term derived from “girone”, denoting a military term for a wall encircling a defensive structure, in this case, a donjon [11,13]. Additionally, it was equipped with a stable and a depot to ensure self-sufficiency during times of attack [11].

With this information, it is reasonable to speculate that the prototype for the fortress of San Felice could have been the “castello-recinto”, see Figure 2, an Italian term for a castle-fence [14]. Such structures typically featured a donjon enclosed by a wall, which could be supplemented with additional towers. However, during the ninth and tenth centuries, the castle’s appearance would have been simpler, with most of the towers added approximately three hundred years later.

Approaching the 1700s, the fortress was in poor condition, losing its defensive purpose. The moat was drained to improve the surrounding sanitary conditions. Devoid of its role as a stronghold, the structure was converted into a residence for guards and their servants, while the underground rooms of the donjon were transformed into dungeons. Correspondence from the time indicates that the overall condition of the structure was inadequate, prompting maintenance for the heavily damaged jails, which were so compromised that they posed a risk of prisoners escaping [10]. With the advancement of long-range weaponry, the wall became obsolete, being too thin to withstand cannonballs, and was subsequently dismantled. The towers, now without a defensive purpose, were sold to private individuals who converted them into residences.

In 1899, the fortress was declared a National Heritage, leading to a decision to restore it, see Figure 3. The initial efforts aimed to repair the damaged sections and restore the fortress’s appearance to what was believed to be its original fifteenth-century form. According to the commission overseeing the restoration, there was a debate about whether to demolish the roofs of the towers, which were considered later additions. After testing the outcome by uncovering one of the roofs, they ultimately decided to retain them. The focus shifted to main structural restorations and some finishing touches. Furthermore, since the fortress was intended to serve as a public structure requiring more space, an additional floor was added to the building beside the west wall. To maintain consistency with the existing structure, this addition was elevated to the level of the brackets, also providing a connection to the patrol walkway between the towers. These restoration efforts were largely completed around the 1910s.

A decade later, in the 1920s, a highly invasive intervention took place within the donjon: a reinforced concrete water tank was constructed within the structure. This operation proved detrimental to the tower. Shortly after the tank was filled, cracks began to appear due to this new load. To prevent further damage and a potential collapse, remedial action was taken.

After World War II, the structure faced considerable danger. The most recent work involving the fortress had damaged the donjon, while other parts lay abandoned. Throughout the 1960s and 1970s, efforts were made to address the structure’s condition. Initially, the focus was on restoring the functionality of the roofs in the western part. These roofs were repaired along with their battlements, which were slightly altered and made taller to conceal the concrete beams intended to act as head beams. Concealing these beams proved challenging, as they were inconsistent with the historical character of the structure. Additionally, their weight imposed a significant burden on the masonry below, and they did not function as intended since they lacked vertical connections to the masonry. A small tower atop the donjon, which once housed a bell used to summon the people, was also demolished, although the bell had been missing for centuries.

Subsequent work began almost a decade later, in 1972. This time, the north-west and south-west towers were the primary focus, as their roofs were leaking and filled with guano. The intervention was overseen by the Superintendence for Heritage of Emilia Romagna and designed by architect S. Piconi, see Figure 4. In this case, unlike previous interventions, efforts were made to reuse as much material as possible to align with conservation principles, particularly the Chart of Venice (1962) and the Italian Chart for Restoration (1972). A reinforced concrete head beam was used again, but this time, attempts were made to better conceal it behind the battlements. However, it was not hidden entirely to avoid historical falsification. Despite the head beam’s potential benefits in distributing loads, adjustments were made to the positioning of purlins and joists for improved functionality.

During the 1980s, the aging and weathering of masonry joints necessitated further work, revealing that punctual interventions in heavily damaged areas were insufficient. A comprehensive restoration was required to fully restore the building’s functionality. In 1985, architect V. Silvani was tasked with designing these works, with a focus on respecting historical stratification and minimizing invasiveness. The restoration began in the late 1980s and was divided into stages for both economic and practical reasons. Areas not under renovation could continue to be used, and payments could be made progressively over time.

The initial work was concentrated on the donjon, which had suffered severe damage due to the presence of the water tank, see Figure 4. To rectify this, the water tank had to be removed, both to recover the two lost spaces and to reduce the load on the structure. The entire structure needed reinforcement, achieved using steel bars and cement mortar infills to create a box-like structure among the perpendicular walls. While this method proved effective during earthquakes, it was somewhat invasive and led to load concentration around the infills due to differences in stiffness between the bars and the masonry. A similar approach, utilizing the Dywidag bar system, was employed for the battlements. These elements were also restored by placing wooden shutters between them, as was done in the past.

The second stage was carried out in the late 1990s, focusing on the southern portion and involving similar interventions as the first stage. This included the reopening of the southern entrance, which had been sealed. Other efforts encompassed plaster restoration, repairs to the roof of the north-eastern tower, restoration of the old patrol path (which could also serve for tourism), and the replacement of wooden stairs with iron and wood alternatives.

The final stage, conducted in 2004, aimed to recreate the old moat as it existed in the fifteenth century, see Figure 5. After archaeological campaigns in the early 2000s, the original clay-brick structure of the ditch was restored and exposed, to create a 50 cm deep basin to resemble the old moat. However, water was not added, and the ditch was transformed into a small grassy park [10].

Today, the fortress is once again undergoing restoration, overseen by the globally renowned Studio Comes Associati, an Italian firm near Florence. Their objective is to restore the fortress to its original appearance while respecting its historical significance. To achieve this, collapsed sections are being reconstructed to replicate the building’s ideal unity when viewed from a distance. However, upon closer inspection, elements are arranged in a way that distinguishes new additions from the original structure. A textured approach is employed, ensuring that each new layer has a slight offset compared to the one below, in line with the principles of Cesare Brandi.

At the beginning of 2012, the province of Modena experienced an earthquake swarm, but of low intensity. Later, in May 2012, a stronger earthquake caused 27 casualties and extensive damage to the building, especially to rural and heritage buildings. The first episodes happened on the 20 May and began with a Ml = 4.0 foreshock at 01:13 (local time, +2), while the biggest one occurred at 04:04 with a magnitude of 5.9 and epicenter in Finale Emilia, 10 km away from San Felice [18]. Since the affected area was mostly rural, the damage was extensive; a typical countryside house in the region is usually made with very low-quality materials. These events were so intense that they also produced ground fractures and scattered sand liquefaction, a phenomenon that occurs when a saturated or partially saturated soil loses stiffness and strength when exposed to specific stresses. These first shakings induced the collapse of the roofs of all the towers of the fortress, see Figure 6, due to the different stiffness and weight of the reinforced concrete head beam over the masonry wall; in addition, these elements were not sufficiently connected since no vertical element was set between them, causing a different behavior under seismic action. The donjon, instead, showed only a shear-type cracking pattern, thanks to the box behavior granted by the structural works that were carried out during the 1990s. In the next nine days, there were many aftershocks, while on the 29th, another big earthquake hit, with Ml = 5.8 and other three aftershocks with a magnitude higher than five, within 5 km from the fortress of San Felice, see Figure 6. From 19 May to 8 June 2012, a total of 1626 events occurred with a magnitude between 1 and 5.9 and can be related to the movements of the Ferrara arc, see Figure 6 [19]. These movements are related to the same arc that generated the catastrophic earthquake that took place in Ferrara in 1570, with an estimated magnitude of around 5.5 only (35 km away). The Ferrara arc pushes along the north–south axis, while the epicenters are aligned in the orthogonal axis.

Between the two earthquakes, there was not enough time to set up an efficient first-aid intervention to the structure and the damages were even bigger. For instance, the north tower suffered the collapse of its eastern corner because of the severe cracks that appeared after the first earthquake; this corner was already weakened as a consequence of the presence of poorly connected masonry and a walled opening (with a thinner cross-section). The type of damage that was registered is of course typical of the masonry and is dependant on the direction of the earthquake. They could be simplified as detachment of the masonry between the towers and the wall in the direction of the earthquake, a drift of the towers in the corner, in-plane shear action, and out-of-plane actions, i.e., damage given by horizontal elements (due to hammering or sliding of the element). Soon after these last earthquakes had settled, first-aid interventions needed to secure the damaged building were put in place. All the cracks were filled with a mortar injection to restore the lost continuity of the masonry, the openings were secured using a wooden frame, and tie rods were put inside the masonry to connect orthogonal walls.

In summary, the history of the fortress can be divided into several distinct phases, each marked by unique activities and events. A detailed timeline of these phases and associated activities is provided in

Table 1. Main phases of the castle, years, and description of activities.

Years	Phase	Description of Activities
927–1195	Medieval castrum	Initial construction of the fortress in response to the need for protection against raids and external threats during the fragmentation of the Carolingian Empire.
12th–18th Century	Early fortress construction	Ongoing development, expansion, and adaptations to the fortress as its role and defensive needs evolved over time.
1899–1910	1899 restoration	Major restoration work in 1899 aimed at preserving and restoring the fortress. Specific details of the restoration efforts during this year.
1939–1945	WW2 danger	Period of vulnerability and potential damage during World War II, with a possible impact on the fortress and its structures.
1980s	1980s restoration	Extensive restoration work was carried out in the 1980s to ensure the preservation and conservation of the historical fortress. Description of the restoration activities conducted during this period.
2000s	2000s archaeological campaigns	Archaeological investigations conducted in the early 2000s, revealing traces of settlements beneath the municipal house and the fortress, aligning with the definition of castra.
2012	Earthquake	Significant earthquake event with structural impact on the fortress, marking a new phase in its conservation and restoration efforts.

, offering a chronological overview of the fortress’s evolution. From its origins as a Medieval castrum to the significant earthquake in 2012, these historical and restoration phases have shaped the fortress’s history, influencing its current state and conservation needs. Understanding these phases is essential for comprehending the challenges and opportunities that come with managing and preserving this cultural heritage site.

3. Modeling Methodology

Several methodologies were employed for the creation of precise mock-ups of existing assets. Additionally, conducting a thorough survey demands a considerable amount of time and planning. First, there is the need to carefully plan the survey campaign, identifying the optimal locations for stations to ensure comprehensive coverage. Then, there is the on-site data acquisition process and the subsequent post-production phase, which involves processing the collected data before it can be effectively utilized.

Moreover, accessibility can be a major concern. Access to a facility or even the ability to remain nearby for surveying purposes is not always guaranteed. This situation may arise when dealing with endangered buildings or assets on the brink of collapse, which can be unsafe for both professionals and their equipment. Similarly, challenges may arise when attempting to model earlier phases of a structure or elements that are no longer physically present. In all the cases where a point cloud of a building was not created and there is no way to register it on purpose, an eBIM mock-up could be made only by retrieving information from other sources, such as older surveys and documents.

The situation is quite similar to the starting point of this study: a fortress that suffered major damages and collapses due to the effects of the earthquake. On top of that, the facility is still a building site with scaffolding and construction material all around it, and because of this, it was not possible to perform either TLS (Terrestrial Laser Scanning) or a photogrammetric survey to acquire a point cloud to be used as a reliable base source for the geometry of its actual state; in any case, it would not have been sufficient to define the collapsed roofs or the state before the restoration in the 1990s. The retrieval of the survey that was done in 1985 and the subsequent design sheets that were produced in the early 1990s for the restoration (both by architect Silvani) allowed us to get the dimensions of the previous states of the fortress. Instead, the post-seismic state of the building has been modeled, subtracting the collapsed portions from those models. Later, it was compared with another reconstruction that was made starting from DWG files that were supplied by Comes Studio Associato, which showed some relevant differences between the two approaches. The focus of this study then became the north tower of the fortress. In particular, the north tower suffered the partial collapse of a corner and the exfoliation of the masonry around it, allowing the definition and validation of a methodology that could be easily reproduced to represent the same problem in other portions.

3.1. Objectives of the Mock-Up Model

The main purpose of this model is to find a suitable approach to construct BIM databases for existing buildings, including 2D digitized supports and to which issues have been encountered, as well as the final model and its effectiveness in describing the real object. Furthermore, it was meant to be part of a more structured research about the capabilities of BIM serving as the geometric basis for other works. Of these, one was exploring the possible import/export of data for objects using Product Data Sheets (PDSs), a predefined collection of entities useful to add semantic meanings to the element [20], while the other analyses the interoperability between BIM models and FEM software [21].

It is important to define the minimum level of information that is necessary to carry out a certain task. According to the UNI 11337:2018 [22], when dealing with existing assets, it should be referred to as the LOD (Level Of Detail) for restoration, which has only two levels: F, for built assets, and G, for already restored/updated ones. Currently, as we are unable to take direct measurements on the building and samples to determine the exact consistency of the materials that have been used, the LOD F is not a feasible target. Despite this, the aim is to be as accurate as possible, in particular about the geometry and the semantics of the elements.

As we explore the capabilities of HBIM, we also acknowledge certain modeling challenges and the need for further refinement in software solutions. We emphasize the importance of bridging the gap between historical preservation and modern technology, with emerging online platforms as a potent resource in this endeavor.

Overcoming these challenges is not solely achievable through the implemented automation of systems, interoperability of computer standards, or enhanced computational capabilities of authoring environments. Instead, it involves a more intricate modeling protocol, both geometric and informative, considering each parametric object as an available digital resource. This necessitates the development of specific ontologies for geometries, materials, and properties, as well as attachments (PDFs, photographs, 360-degree images, videos, etc.). These ontologies are indispensable for the computerized description and translation of the relationship between various objects and the system of relations that intervention on existing structures defines among them. The structure of these mentioned ontologies, seen as the result of subject, verb, and predicate, becomes an essential prerequisite and constraint for geometric and informative modeling, much like the constructive, geometric–morphological, and conservative characteristics of the examined structure.

Finally, the model was meant to be part of the Inception Project, a research program that has received EU Horizon 2020 funds and is coordinated by the University of Ferrara, Italy. It aims to show and enrich European identity through its evolution over long periods, using a database of time-dynamic 3D reconstruction of artifacts, i.e., built and social environments (https://www.inception-project.eu/en, accessed on 10 October 2023). These models should be easily accessible and interoperable regardless of the hardware and software of each machine, which will lead to a semantic web platform for HBIM that can be implemented in user-friendly augmented reality operable on mobile devices. To be consistent with Inception ideas, the model must show some parts of the evolution of the building. Since the documents about the survey of the 1980s, the design of the 1990s, and the plans used for post-earthquake reconstruction, the digital environment will show the last three phases of the evolution of the tower.

3.2. The Modeling Process

After having defined the operative framework and the state of the art that was considered earlier, the work carried out will be explained step-by-step in the following sections. It should be recalled that the BIM workflow is designed to simulate the actual building construction phases [23], so the modeling will start from scratch with the reference system, made up of levels and a grid. In this case, walls and the horizontal systems are set in place. Once the structural system is set, the openings, stairs, and other details will be considered. In the following sections, we will refer specifically to the Autodesk Revit software to describe the procedures used during the modeling of the case study.

3.2.1. Compilation of Available Documentation

As often happens with buildings that have not undergone major works recently, no digital photogrammetry or TLS campaigns were carried out before the earthquake. Therefore, there were no digital data on the state of the tower before May 2012 and there were no opportunities to carry out a digital survey nowadays, so it was necessary to rely only on existing documents. The historical literature survey described how poor the documentation is about the works that the tower underwent through the centuries. Yet, probably due to the bureaucratization of the AEC sector in recent decades, it was possible to retrieve some traces of the last restoration works in the archives. These batches of blueprints represent the survey that was carried out in 1985 and the restoration design proposal of the early 1990s, both made by Arch. Vittorio Silvani. For the post-seismic state, there are the plans made after the earthquake by Comes Studio Associato. Both the series of blueprints were already digitized and delivered as PDF files, although the process and the tools that had been used for the scanning are unknown. Many types of scanners could be used to convert that paperwork, but the most suitable in case of large format support and fragile materials, and also to achieve high fidelity results is the metric scanner. Despite the colorimetric rendering not being important for this research, having a device that could minimize geometrical deformations and distortions could have been better; this is because paper is sensitive to aging, and design sheets are usually stored, stacked, and folded in an A4 shape, leading to permanent deformation of the support approaching the folds (all the drafts were made by Arch). Silvani’s blueprints were stored in this way; thus, they show many slight twists along the creases, especially where orthogonal foldings intersect. This is evident in lines that appear to be shorter or not straight anymore, making them challenging to measure, and therefore, less reliable and more difficult to reproduce correctly in AutoCAD. Alas, this was not the only issue faced with the blueprints, since all of them were missing three very important marks: the scale bar, the geographical orientation, and the triangulation network sat for the measurements.

Instead, the post-seismic situation of the asset will be reproduced using different supports: an accurate series of ten DWG plans, a high-resolution panoramic-image reconstruction of the tower, orthophotos of the whole buildings, and some reports, among which some structural ones (produced by CIRI, a research institute of the University of Bologna).

3.2.2. Vectorization of Historical Plans

Before commencing the actual BIM modeling process, it was essential to gather and consolidate all the floor plans into a DWG file, which would serve as a reference for wall placement. The approach used for this task differed for each of the three phases and will be explained in detail below.

• Pre-1985 Plans: The 1985 survey was conducted to obtain geometric data on the fortress, serving as a reference for the entire restoration project. It consisted of twenty-one sheets, including seven plan views that roughly represented each floor of the fortress, along with elevations and cross-sections.
  The files representing the north tower were selected and imported into AutoCAD 2020, which is released by Autodesk, the same software house as Revit. The goal was to create a single DWG file containing vectorized representations of the walls and openings as seen in the PDFs, accurately positioned in 3D space. This DWG file would then be imported into the Revit environment as an external reference, serving as a trace for modeling the elements.
  However, this process encountered some challenges, primarily due to missing annotations. A minor issue was the absence of “north” indications in all the drawings; it was only present in the small plan of the area within the title block. Moreover, the drawings were not oriented in alignment with the title block map, which introduced uncertainty regarding the correct orientation. Nevertheless, for this work, orientation was not a critical concern.
  Some concerns also arose when loading the PDFs into AutoCAD. Despite being imported with their scale, it did not match the intended scale. This discrepancy could have resulted from approximations during the digitization phase or wrinkles in the paper.
  To enhance accuracy, the PDFs needed to be resized within CAD. This was accomplished by using a known measurement as a reference for each floor [24]. A carefully chosen line, situated away from paper folds to avoid deformations, was used as the reference. For consistency, the internal profile of the eastern wall of the tower was chosen as the reference for scaling the rest of the building, as it was located in a flatter and less folded area of the blueprints, see Figure 7.
  The final missing element was a closed triangulation network. After scaling the plans, the next step was to vectorize them, making them loadable into Revit and allowing interaction for wall placement. A robust triangulation network would have made it easier to reconstruct the geometry of walls and openings, as it provides reliable measurement information through a network of interconnected dimensions.
  Despite the absence of a formal triangulation network, lines could be sketched using a simple typical topographical approach based on the triangulation of points using circles, see Figure 7 [25]. Starting from a line, to determine the orientation of an adjacent one, two circles were centered over the two ends of the first line. The radius of these circles equaled the distance of these two points from the other end of the second segment. This geometric construction allowed the circles to intersect at the final point of the line that needed to be created.
  This method works only with redundant measurements when at least two measurements are converging for each point. In general, the obtained discrepancies were on average about 2 cm or below, which could be assumed as a quite good error when dealing with masonry structures. To sum up, the origin of these differences can be the result of:
  • Absence of a scale bar and a closed polygonal and the redundance of measures.
  • Accuracy, precision, and error of the tools used to take the lengths; since no benchmark points are reported in the documents, it could be assumed that were used mainly analogic instruments.
  • Errors due to rounding of the measurings.
  • Accuracy of the drawings.
  Eventually, once each of the four plans had been completely vectorized, they were stacked according to their reference plane. Since the actual value was not reported on the plan, the section height was assumed 1 m over the flooring, but this will be added directly on Revit when modeling the walls.
  The benchmark to stack one element over the other was a portion of the footing of the north-west tower, since it was the only common element among all the plans. Instead, on the fourth floor, since the corner was hidden by the roof, it was used as a reference to the brick parapet of the courtyard staircase (which was also present in the second-floor plan). Indeed, in this case, it would have been better to have a network of external benchmarks to correctly orientate all the plans according to the very same reference system.
• 1990s Plans: The works carried out during the 1990s did not alter the external geometry of the north tower. However, this set of drawings reveals other completed or proposed interventions. From a visual perspective, these blueprints closely resemble the previous ones, except for the absence of measurements, which were later added with a pencil and roughly approximated from the originals.
  The primary differences between the two sets of drafts were the installation of window frames and the construction of a new spiral staircase to connect the second floor and the battlements.
  The staircase, constructed of wood and steel, was intended to replace a movable wooden ladder that had been used externally on the tower in a corner nearer to the door to avoid interfering with the use of the room.
  As these documents do not provide significant additional information about the structure of the tower, there was no need to vectorize these PDFs either, as they were essentially interchangeable.
• Post-Seismic Plans: The set consisted of ten DWG files, each corresponding to one of the fortress’s levels. Unlike the other blueprints, these plans were highly accurate as they were generated from a TLS (Terrestrial Laser Scanning) survey. They were also very self-explanatory, featuring numerous useful references, such as the north arrow and actual height indications on the cross-sections. Each view was designed to facilitate easy stacking of frames around the plan, showcasing the same area at different heights. The final output resulted in a DWG file similar to the previous one that was created.
  Since the two DWG files were not based on the same reference system, they lacked consistency between them due to the absence of benchmarks connecting both. However, as a final step in the modeling process, a conceptual mass was reproduced using the last DWG as a reference. To place this mass within the same environment as the first one, the north wall of the fortress, connecting the three towers, was assumed as a reference point. This assumption could be supported by the fact that the earthquake propagated along the east–west axis of the fortress, and the wall withstood in-plane stress, indicating that it should not have moved along its axis, making it reliable for qualitative analysis.

4. Logical Organization of the BIM Database

Setting up a project such as in Autodesk Revit software, one of the first logical operations is the definition of levels and grids. The levels were established based on the reference system of the 1985 survey cross-section, with the 0.00 m reference set at the height of the courtyard. These levels played a crucial role in accurately positioning objects within the project. In addition to the floor levels, intermediate levels were created at the springers of the vaults to facilitate element placement, see Figure 7.

Grids are tools that create a reference network extending across multiple layers, simplifying the placement of columns and walls on a plan. However, due to the walls’ decreasing cross-section with height and their random spatial orientation, it was determined that using the DWG plans as a reference for modeling walls and setting openings would be more efficient than relying solely on grids.

4.1. Late Historical Phases and Considered Configurations

The final preparatory step before commencing the actual modeling process involves defining the various phases to be utilized. These phases are crucial for structuring the modeling approach and ensuring accurate representation. The following phases were established:

• 1985: This initial phase is based on the DWG files derived from the survey conducted by architect Savioli in 1985. It serves as the foundational reference for subsequent modeling efforts.
• Support 1: As the name suggests, this phase is not intended to represent a specific historical timeframe, but is designed solely to demolish walls that needed to be recreated in the model for the 1990s phase.
• 1990s: This phase closely mirrors the geometry of the previous 1985 phase. However, it incorporates key updates, such as the addition of the new spiral staircase and windowpanes, reflecting the architectural changes over the decade.
• 2012: In this phase, we focus on representing the collapsed portions of the structure, documenting the impact of the seismic event.
• 2012-LS: The final phase derives from the DWG files produced by Comes Studio Associato. It serves to highlight the differences and potential limitations between the two modeling approaches, offering valuable insights into the structure’s evolution.

• Alongside the definition of these phases, corresponding visualization filters were established, see Figure 8.

This section explores the extensive groundwork involved in capturing the essence of the fortress as it stood in its fundamental configurations concerning the present study: pre-remodeling. Figure 9 shows images of remodeling before the seismic event and remodeling after the seismic event.

4.1.1. Pre-Remodeling

Before embarking on any historical preservation or renovation project, understanding the original state of the structure is of paramount importance. The case study presented in this paper focuses on a historical fortress, offering a glimpse into the meticulous process of creating a digital representation of the structure in its pre-remodeled state.

The significance of this pre-remodeling phase lies in its role as a foundation for subsequent restoration efforts. By accurately documenting the structure’s historical attributes, architectural elements, materials, and spatial configurations, preservationists and restoration experts gain a comprehensive understanding of the fortress’s heritage value. The pre-remodeling phase sets the stage for informed decision-making throughout the project, ensuring that any alterations or interventions align with the historical integrity of the structure, Figure 9a.

4.1.2. After Remodeling—Before Seismic Event

The fortress underwent substantial renovations during its history. In the 1980s, extensive restoration work was initiated due to masonry joint deterioration, guided by architect V. Silvani. Starting in 1985, Silvani’s restoration approach focused on preserving historical layers while minimizing invasive interventions. The restoration efforts were implemented in phases for practical and financial reasons. The initial phase centered on the donjon, involving structural reinforcement and the removal of a water tank, which had caused significant damage. This phase also included the restoration of wooden shutters and other structural elements. In the late 1990s, the second phase of restoration concentrated on the southern part of the fortress, replicating interventions from the earlier phase. Additionally, it encompassed the restoration of the southern entrance, plaster restoration, reconstruction of the northeastern tower’s roof, and the replacement of wooden stairs with iron and wood alternatives.

4.1.3. After the Seismic Event

Comparison of the post-seismic state, following the seismic event, requires subtracting volumes from the 1990s model and another derived from DWG plans generated by TLS. While these models lack a common benchmark for precise orientation within the same environment, they yield valuable insights. The post-seismic state reconstructed from the Comes Studio Associato’s DWG uses in-place elements similar to the patch-like model discussed in the previous paragraph. Notably, it highlights areas where masonry had fallen, offering a comparable representation to that achieved through Boolean subtraction. Furthermore, it reveals a counterclockwise twist in the tower, with the northwest corner misaligned vertically with the rest of the masonry below (as seen in Figure 9c). This twist was not documented in blueprints from 1985 and the 1990s, where the north face’s slope appeared consistent vertically. Oral sources, however, had suggested a slight forward lean of the north side of the fortress. While the model may lack precise metrics on this rotation, it provides a historical perspective on the tower’s alterations due to seismic activity. This historical context can be valuable for preliminary intervention and cost evaluations, despite its limitations in detailing rotations.

4.2. Elements Modeled in Detail

Objects can be modeled according to different techniques and strategies, depending on the result that is sought or the needs. In addition, they could be parametric to adapt to different situations or even nested, when they are used one within element. In the following, we review all the characteristic structural and architectural elements composing the north tower highlighting possible modeling problems that could prevent interoperability when exchanging information through specific software.

4.2.1. Walls

Given that walls are one of the most common elements in a historical building, there are various methods to model them in a BIM environment, which largely depend on their geometry and complexity. Wall modeling can involve using system families for standard elements or creating in-place elements when dealing with unique shapes. It is important to note that the primary objective of this project was to preserve the geometry of the tower, which significantly influenced the choice of modeling methodology.

In the case of the north tower, using system families for walls would not be effective for representing the perimeter of the building. System families are typically designed for straight elements with a constant cross-section. However, the north tower’s walls not only have a varying cross-section with height, but their internal and external faces are also not parallel. The inner face runs straight from the floor to the springers of the vaults, while the outer face is sloped. Similarly, the “Wall by Face” function would not be suitable, because it relies on wall types that are system families and are placed parallel to the reference face.

To preserve the geometry of the walls, the decision was made to initially model components in place. This means that objects were created specifically for this project, even though they could potentially be turned into loadable families and used in other projects. This approach ensures that the elements remain semantically meaningful and inherit typical characteristics, such as the ability to host windows and doors. Before proceeding with modeling, each wall was assigned a name, which would later be used to identify the various elements in schedules. The wall naming convention used “Wall_x_YY”, where ‘x’ is a lowercase letter indicating the position of the element relative to the main façade (f for frontal, r for rear, dx for right, sx for left) and ‘YY’ represents the floor (GF for the ground floor, FF for the first floor, SF for the second floor, TF for the third floor, and so on).

With a name assigned, the next step was to choose from different types of solids (and voids) to shape the wall component. Since both the initial and final cross-sections of the wall were available for each floor, the “Blend” option was selected. The Blend option allows for the creation of a solid shape by blending two profiles together. However, since the cross-sections were located approximately one meter above the floor, directly connecting them was not feasible because the inner faces of the two walls between consecutive floors were not aligned, as shown in the vertical cross-sections. Therefore, each wall needed to start and end at its respective reference level, necessitating a two-step procedure.

Additionally, to minimize construction lines in elevations and ensure a cleaner model, the connection between two adjacent walls was established by joining their inner and outer ends at the corners. While the “Join” command is typically used to connect walls, it was found to be less reliable when dealing with a large number of in-place models. Consequently, the two-step process outlined below was employed for modeling each wall.

Checking the consistency of the model against the interoperability (i.e., exporting as an IFC file) allows a simple and direct assessment of the quality of the model against a wrong class definition, see Figure 10. To resolve issues with the visibility of voids within custom window families during IFC exporting, several approaches were explored. Initially, the IFC exporting settings for window categories were checked to ensure correct class definitions. These settings could be adjusted within the IFC options panel. Despite confirming the correct settings, the issue persisted. Another attempt involved modifying the IFC parameters within the window family, but this also yielded no improvement. As a compromise, sections of the wall containing windows were manually removed and replaced with new elements created from a generic mass. To ensure proper alignment, a slightly larger wall family was used as a reference. The inner side was rectified using a Boolean cut with a generic void.

4.2.2. Vaults

Three different vault systems are present within the north tower:

• Keel Vault: Located on the ground floor.
• Cloister Vault: Situated on the first floor.
• Barrel Vault: Positioned on the ground floor.

To facilitate their integration into the model, all these vault types were meticulously designed as parametric families. This approach served dual objectives: firstly, it allowed for seamless adaptation to the specific contours of the walls they would overlay, ensuring geometric accuracy. Secondly, these parametric families were versatile enough to be applied throughout the entire fortress, accommodating variations in wall shapes and dimensions.

Notably, the Keel vault and the Cloister vault, while visually similar, exhibited distinct dimensions. To optimize modeling efficiency, a single parametric family was crafted, from which two distinct instances could be derived by adjusting parameters.

The modeling process of these elements starts with the definition of three distinct flooring systems, with their respective thicknesses and materials determined based on available reports.

With the flooring systems defined, the next step involved sculpting them to match the vaulted shapes. This was achieved through the use of adaptive families, following this procedure:

(a)

Open a Metric Generic Model Adaptive family template.

(b)

Add four Point elements in a clockwise arrangement under the Reference category. Select all four points and designate them as adaptive.

(c)

Create splines through pairs of adjacent points. Select all the splines and mark them as Reference Lines.

(d)

Shape the adaptive family using the Draw Section tools. Certain dimensions needed to be parameterized based on vault type:

• For the Keel vault, parameters included length, height, radius, and height of the flat portion (known as “schifo” in Italian).
• For the Barrel vault, parameters pertained to both the initial and ending radii.

(e)

Convert the measures created in the previous step into parameters. Ensure proper labeling and determine whether each parameter should be a Type or Instance property based on context. Parameters dependent on other variables should be grouped under “Constraints” in the dropdown menu.

(f)

Create the Void Form necessary for carving away sections from the flooring system. The procedure varies slightly for the two vault types:

• For the Keel vault, select the shape form first, followed by the reference line, and then press the “Void Form” button.
• For the Barrel vault, select both the starting and ending profiles before pressing “Void Form”.

(g)

Save the family and load it into the project. Once correctly positioned, use the “Cut Geometry” function to subtract it from the flooring, achieving the desired vaulted shape.

This meticulous process ensured an accurate representation of the various vaults while maintaining modeling efficiency and adaptability across the fortress structure.

4.2.3. Roofing System

The element was created using the standard command Roof from the footprint, using the concrete head beam of the battlements as a reference for the perimeter. The roof did not survive the earthquake, and few traces are available to obtain its dimension and materials; while thickness, slope, and offset from the head beam were extrapolated from the vertical cross-section, the structural arrangement of the rafters and the purlins was assumed in analogy with the sketch reported in Figure 4 about the north-east tower. The structural elements were added after the placing of the roof, which can be used as a reference plan. The rafters, to which the elements in continuity with the finishing were added using the Structural Beam System, showed an array of objects defining their perimeter, spacing, and, justification. Then, the purlins and, finally, the king post truss were added, see Figure 11.

4.2.4. Openings

Doors 

There are four doors in the tower: two on the ground floor and one each on the first and second floors. The first two doors are unique, as this tower used to serve as the gate between the fortress and the town, and they possess distinctive features.

The external entrance door features two carved wood panels with studs and two metallic door knockers. To model this door, a Metric Model template was used, and the masonry was shaped by combining various types of voids to achieve the actual form. Afterward, all the other elements of the door were added.

The other passage serves as a short gateway with a barrel vault and an old wooden portcullis designed to prevent enemies from entering. Modeling the hole in the masonry required using the Blend tool, as the two sides of the wall have different widths. The lattice wooden structure of the portcullis has also been represented, although it is unclear where it ends, as the cross-section suggests that it may be too short to span the full height.

The last two doors, which grant access to the first and second floor, have a different doorway, but their wooden structure is quite similar. Unfortunately, there was not enough data to design in detail the two panels, since they are only visible in the panoramic reconstruction, while they are simply sketched in the blueprints.

Windows 

Differently from the doors, windows could be grouped according to some sort of archetype, except for the two long and narrow openings facing north, which used to house the lifting harm of the drawbridge, and the other two facing the courtyard, which are protected by iron bars. The two narrow windows, even though they are quite similar (one is just longer than the other) were modeled separately because of the masonry molding. In addition, the ones with iron bars had to be modeled separately, since the metal lattice was not parametrizable and was composed of cylindrical elements. Furthermore, the window facing north on the second floor was modeled separately because of its molding. At first glance, all the windows at the battlement level seem to have the same proportion, but they slightly differ in the rising ratio. In any case, they could be grouped into two main types: large and small ones. Both types were modeled using a Metric Window family, and using a simple hole in the wall since they are just this in reality. In both cases, the height and width are instance parameters, so that each opening could have its measure according to the survey; instead, the radius of the top arch must be set as a constraint function, since it depends on the value of the rise and width of the window.

Merlons 

The merlons had been modeled parametrically since they were all based on the same design; they only had different dimensions. They were designed as a simple swallowtail merlon (or Ghibelline, in Italian) using a Metric Generic Model wall-based template, to allow the creation of elements hosted by a wall: the merlons are connected to a wall that is probably deriving from the rose of the battlement (a parapet with a defensive purpose). In this way, the relationship between the wall and the battlement is preserved. All the main dimensions and the V-shaped notches of the top were parametrized to adapt to any width modification. Later, this object served as a base to shape the other battlements that were unique. In particular, the corner ones needed to be modeled aside, since they had to adhere to walls that have different orientations, but also because their notches were merging along the bisector. The last one to be modeled was the type with the embrasure on the front side. In this case, too, the base was the standard merlon, to which was added a narrow opening that was made parametric, since it was needed by three elements, but all in different positions, heights, and widths.

4.2.5. Stairs

Stairs were modeled using the standard command Stairs for spiral geometry that allows drawing a circle to place the element. They were placed according to the distance from the wall that can be measured in the post-seismic situation.

4.3. Representing Collapsed Portions

To represent the Tower situation after the earthquake including the damage that occurred, we need to represent the collapsed parts too. On the top of the tower, according to the parametric definition of the brackets, the ones that survived had been shortened, while the ones that crashed were simply deleted. Instead, a representation of the fallen corner of the tower was realized by subtracting regions that were cut away from the original configuration (Create Void Form); one orthophoto for each side of the tower was used as a reference, see Figure 12.

5. Semantic Enrichment Using Patch-like Objects

Patches are very powerful tools that can be used to add information to the model since their properties can be managed to add relevant data that can be exported or modified (in Revit using Dynamo). Their purpose is very wide, since they can be used to define material characteristics create a deterioration map, or even define which works are needed or which tests need to be performed. They can either adhere directly to the surface using adaptive points or they can be projected on the model using Dynamo scripts [26], but this last case is more time consuming and it does not always work. For this project, we decided to use the adaptive points, since they are very effective and easily exportable with IFC. It has to be mentioned that when dealing with uneven surfaces, as in the case of the tower, their adherence is not perfect, and sometimes, they are not shown correctly within Revit, see Figure 13.

A similar visibility issue happens with IFC files when opened in viewer software, but since they are exported as BuildingElementProxy, they can be easily selected and shown clearly, see Figure 13. The patches were generated using a Metric Generic Model Adaptive template, adding 20 points (the number depending on the needs) clockwise on a plane, and are consequently made adaptive. Then, the process is similar to the vault construction: the points are selected a pair at a time and connected using the spline tool; after all, they are linked together. The pointer of the mouse must be placed over one of the splines and then the tab button must be pressed until all the splines are selected at once; using the option Is Reference Line, we can check whether this is a Reference Line. Eventually, this line must be selected, and the button Create Form appears. After hitting the button, the software requests whether it a surface or a solid is needed. Selecting the plane object works better because it could be useful to obtain the value of the surface, see Figure 14; this could be useful to evaluate, for instance, the number of interventions that need to be carried out. Once the patch is created, it can be enriched with data, which can be added as Text, Data, or even a Comment from the Family type menu. For this case study, six different types of patches were used to describe the types of masonry that the tower was made of, according to the scheme that was created by Ferrari and Goldoni [10]. These elements were predisposed to collect data about the Masonry Quality Index, mechanical characteristics, and comments, see Figure 15. Depending on the needs, they could also host images taken on-site or documents proving laboratory tests used to define the mechanical characteristics.

6. Inception—A Versatile Online BIM Database for Historical Cultural Heritage Management

6.1. Features and Integration

Inception serves as a powerful online database tailored to accommodate Building Information Modeling (BIM) models and their associated documentation, which includes images and PDF documents as attachments. The platform distinguishes itself with a unique integration with geographic data, enabling users to visualize uploaded models within a geographic context using Google Maps. This geographical awareness significantly enhances its utility, especially for projects with location-specific requirements. While Inception primarily supports models in the IFC format, it also accepts COLLADA (.dae) models, albeit without semantic data, for the sole purpose of enabling 3D visualization of surveyed textures [27,28,29,30].

We aim to integrate structural information resulting from two specific structural analyses: pushover analysis and Natural Frequency analysis (Mode Shapes) into the BIM database. To achieve this, we need to restructure the conventional Finite Element Method (FEM) database to comply with the IFC format, ensuring interoperability. The IFC format does not inherently include a specific object format for storing and visualizing structural information. Therefore, we propose transforming the structural information related to each element into an IfcBuildingElementProxy object and enriching them with the appropriate information that can be attached to this IFC object.

Using a straightforward FEM discretization obtained through the Cloud2FEM procedure [31,32], we convert the hexahedral elements into geometric cube shapes in alignment with the IFC structure. We convey structural information by utilizing attributes such as color, as elaborated in the following section. Additionally, in cases where structural information necessitates visualizing the displacement field (deformed configuration), we simply add the displacement values to the Cartesian coordinates, following the common practice in FEM software visualization. If needed, we apply a magnification factor to the displacement values to facilitate clear displacement plots.

6.2. Interactive Exploration and Semantic Querying

Inception empowers users with the ability to interactively explore BIM models through its intuitive 3D viewer. This viewer offers various features such as element type and floor filtering, see Figure 16a. Additionally, Inception boasts a ’time machine’ feature, enabling users to visualize the state of an asset at specific points in time, see Figure 16b. When it comes to semantic data, Inception supports the querying of IFC elements, generating a convenient tree-like representation of related semantic data. An essential aspect of Inception is its support for attachments, playing pivotal roles in two crucial scenarios. Firstly, attachments provide in-depth descriptions of material zones, as exemplified in the post-earthquake architectural model, where they elucidate features such as masonry textures, see Figure 16e. Secondly, attachments accompany synthetic outcomes of structural analyses, as seen in models such as the pushover curve, see Figure 16d,e [33,34]. Inception, thus, emerges as a versatile tool for visualizing complex data and enhancing data interpretation for diverse stakeholders.

6.3. Management of Historical-Cultural Heritage

Inception’s capabilities seamlessly extend into the domain of historical cultural heritage management, providing a robust toolkit for owners and managers of historical sites and buildings to preserve and safeguard these treasures. Historical structures often demand meticulous attention to detail, and Inception offers features tailored to this need. Users can upload historical BIM models, allowing for comprehensive documentation of architectural elements, materials, and structural intricacies.

We have uploaded three models, as illustrated in Figure 17:

(a)

Three-Phase Model: This model resides within a single IFC file. Although it may initially appear cluttered when viewed using an IFC viewer such as BIMVision, where elements from the three phases are superimposed, Inception automatically segregates these phases. To achieve this, every element in the IFC file must be tagged with the phase to which it belongs. This practical task is accomplished by defining a property set called “INCEPTION-phasing” for each component, which serves as a container to store consistent properties, including phase specifications (e.g., phase = 1990 or phase = 2012). Inception recognizes this property set and effectively segregates the three models. The IFC file was directly exported from Revit.

(b)

North Tower Modal Shape Model: This model represents the modal shape of the north tower. It essentially serves as a synthetic representation of results obtained through finite element analyses conducted on the north tower’s structural behavior [32]. Here, colors represent the Modal Shape amplitudes.

(c)

Pushover Model: Similar to the modal shape model, this model also results from finite element analyses performed on the north tower. These analyses generated a substantial amount of data that is not easily represented within a BIM environment such as Inception. Thus, we aimed to create a synthetic representation of the structural analysis outcomes, which can be readily understood by all stakeholders [24].

In both models (b) and (c), we employed a subsampling technique to simplify the representation of the vast data. Finite element analyses yield results at discrete points in 3D space. We performed subsampling by averaging these data points, effectively condensing them into a voxelized ‘cloud’ of points, each associated with a specific value.

To visualize these results in a BIM environment via an IFC file, we converted each point in the ‘cloud’ into an IFC element, described as a cube in 3D space. The color of each cube represents the value of the result corresponding to its spatial location or technical information. For instance, in the pushover analysis result, white indicates ‘no damage’, yellow represents ‘partial damage’, and red signifies ‘significant damage’. To enhance result readability, we included a standard architectural representation of the remaining parts of the castle, even though we only modeled the north tower. In this context, the graphical overlay of information enables the utilization of multiple technical details within a unified environment.

These models serve as valuable tools for rapidly understanding and communicating the structural behavior and responses of the north tower under different conditions.

This digital preservation ensures that critical historical information is accessible for future generations. Inception’s geographical integration is particularly valuable for heritage sites, allowing for precise mapping and documentation of historical landmarks. It facilitates the creation of digital archives that capture the evolution of heritage sites over time, aiding in restoration, conservation, and research efforts. Furthermore, the platform’s attachment system becomes instrumental in historical cultural heritage management. Attachments can provide historical context, archival photographs, or detailed descriptions of architectural elements, enriching the understanding of these sites. Additionally, Inception supports the integration of structural analysis data, aiding in the assessment of structural integrity and potential restoration needs for historical structures. Inception’s role in heritage management extends beyond documentation; it becomes a vital tool for education, research, and collaboration among heritage professionals, historians, and the public. The platform empowers stakeholders to make informed decisions regarding preservation, maintenance, and restoration, ensuring the continued legacy of historical and cultural heritage.

7. Conclusions

This paper underscores the significant contributions made in the modeling and management of cultural heritage assets through the integration of Building Information Modeling (BIM) and cloud-based solutions. The development of an online database enriched with BIM models and related documentation provides innovative solutions to the complexities associated with historical structures, including incomplete data and endangered building conditions, as graphically described in Figure 18.

Our research reveals the inherent limitations of working with historical assets characterized by incomplete data and complex architectural histories. These challenges underscore the importance of continuous software enhancements tailored to accommodate the unique needs of heritage preservation and rehabilitation.

We have demonstrated the multifaceted utility of our approach. While the accuracy of our final mock-up may fall short of comprehensive rehabilitation design standards, it serves as a crucial starting point. The ability to refine the mock-up through more detailed survey campaigns holds high promise. Furthermore, the existence of a comprehensive library of parametric elements within Inception streamlines future modeling efforts, ensuring greater precision in architectural detailing.

In addition to the architectural aspects, our research emphasizes the capability of visualizing modal shapes and pushover damage over BIM models, providing valuable insights into structural behaviors. This integration of structural analysis with the BIM framework enhances the understanding of historical structures’ response to various loads and paves the way for more informed decision making in structural assessments.

Our work exemplifies the synergy between cutting-edge technology and the preservation of historical treasures. Inception offers a transformative platform for documenting, analyzing, and preserving cultural heritage. It extends its utility well beyond the Architecture, Engineering, Construction, and Operations (AECO) market, catering to a wide array of professionals and researchers. From academic investigations to virtual reality applications, Inception’s cloud-based accessibility democratizes historical and cultural heritage data, making it accessible on a global scale.

By embracing Historical Building Information Modeling (HBIM) and advanced BIM practices, we extend responsible stewardship to cultural and historically significant assets, preserving their legacy while aligning them with contemporary requirements. Our efforts possess the potential to transform the AECO sector and establish a fundamental framework for the conscientious preservation of our collective cultural heritage, facilitating the seamless integration of diverse and heterogeneous information gathered from historical, structural, architectural, conservation, and other realms.

While challenges persist, they serve as driving forces for future innovations and improvements in the field of heritage conservation. As we continue to refine our approach, we are confident that Inception will play a pivotal role in safeguarding our shared cultural legacy for generations to come. The ongoing research and development in the realm of existing asset modeling will be essential to streamline the design and preservation of historical assets. Our work contributes to the progress in HBIM, offering optimism about its future impact.

In summary, our research reveals the transformative potential of BIM technology, emphasizing its role in heritage preservation, structural analysis, and its broader applications. As we navigate the road ahead, innovation and collaboration will be the keys to unlocking new possibilities in the realm of historic preservation and beyond.