A Systems Thinking Approach to the Development of Historic Building Information Modelling: Part 2—Definition of Requirements

Abstract

Historic Building Information Modelling (HBIM) is the application of BIM, a digital information management and 3D modelling technique, to cultural heritage (CH) assets. It will assist with the ongoing sustainable management of CH in line with the United Nations’ Sustainable Development Goals (i.e., SDG 11 and SDG 13) by providing an enduring record of asset information and enabling the energy-efficient use and adaption of assets. However, the application of HBIM is currently limited by a lack of defined end-user requirements and standard methodology in its application. This paper is the second piece in a series of works where the authors adopted a systems thinking approach, utilising both the Soft Systems Methodology (SSM) and hard systems engineering (SE), for the development of HBIM. This paper presents the results of an extensive survey undertaken with the UK Heritage Community. It validates forty-one previously proposed information requirements, identifies a further twenty new information requirements for HBIM, and utilises the SE process to define thirty-three system requirements for HBIM according to the end user.

1. Introduction

1.1. Background

Historic Building Information Modelling (HBIM) is the application of BIM, a digital information management and 3D modelling technique, to cultural heritage (CH) assets. The term ‘CH’ is used throughout in place of similar terms, such as ‘built heritage’, so as not to unintentionally limit the scope of work at this stage of the research. Whilst HBIM has the potential to improve the efficiency, longevity and, consequentially, sustainability of CH management in line with the United Nations’ (UN’s) Sustainable Development Goal (SDG) 11 (Sustainable Cities and Communities [1]), its actual application is limited by a lack of defined requirements and standard methodology [2]. As is the case with any developing field [3], whilst the technology supporting the modelling and information storage elements of HBIM is advanced and continuously developing [2], the theoretical justification of why techniques are developed and why certain information is stored is lacking. Without standards that define what should be stored in an information system, “new technologies can do little more than present bad data in a deceptively good way” [4].

This paper is the second part of a piece of work undertaken by the authors, which proposes and applies systems thinking processes to the development of HBIM [5]. The International Council on Systems Engineering (INCOSE) define systems thinking as “a way of thinking used to address complex and uncertain real-world problems. It recognises that the world is a set of highly interconnected technical and social entities which are hierarchically organised producing emergent behaviour” [6].

There are two elements of systems thinking that are being applied to the development of HBIM by the authors. These are categorised as ‘hard’ systems engineering (SE) [7] and Soft Systems Methodology (SSM) [8]. In the first part of this paper series [5], SSM was applied to explore the problematic situation (i.e., the management and maintenance of CH). The term ‘problematic’ is used in place of ‘problem’ as SSM views management situations as situations that can be improved as opposed to problems that can be solved [8,9]. In ref. [5], SSM was also used to give the root definition of HBIM, more detailed discussion of which will be given in Section 1.2.3. Within SSM, a root definition refers to the core purpose of a purposeful action undertaken to improve a problematic situation [8]. In the context of this research, the purposeful action proposed is the application of HBIM for the management and maintenance of CH. To date, the application of HBIM is plagued by disparate methodologies resulting from differing intended use cases [2]. Thus, it is the hope of the authors that a defined overarching purpose of HBIM will provide a focus to align HBIM development. The application of SSM, detailed in Part 1 of this paper series, was a necessary first step in the wider SE process as it enables the validation of any future HBIM system, e.g., does the system work the way it is expected to in the expected environment [10]?

Systems thinking is, to the best of the authors’ knowledge, a novel proposition for HBIM development. However, it has been previously proposed for other digital information management developments within the UK. One comparable example is the recommendation by the Centre for Digital Built Britain (CDBB) that systems thinking should be applied to the creation of a National Digital Twin, a series of digital twins within a connected network of shared data [11].

This paper will continue the application of systems thinking to the development of HBIM by employing SE processes to the definition of end-user requirements for HBIM. SE is arguably easier than SSM to understand within an HBIM context since the use of SE for the creation of an information system, defined by the National Institute of Standards and Technology (NIST) as “a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information” [12], is well established. The application of SE typically follows the process outlined in Figure 1. The first two stages (system requirement analysis and system requirement elicitation) will be encompassed within this paper (see Section 2.5 for more details). Stages 3–5 are not discussed herein as they are beyond the scope of the survey to date. However, they will be addressed in future work by the authors (see Section 6 for details). The requirements defined in this article will enable the evaluation of the quality and value provided by any future HBIM system, the evaluation of which is, in part, dependent on whether it satisfies the end-user needs [13,14,15].

The authors acknowledge the suggestion by Checkland and Scholes [8] that any action dealing with a complex problematic situation must be a flexible methodology that cannot be reduced to a series of actions. Therefore, the requirement definition for an HBIM system should focus on what needs to be achieved (outcomes) as opposed to how it will be achieved (outputs). This is not a novel approach within the CH sector. For instance, UNESCO et al. [16] discuss how management effectiveness can be measured by how well the outputs contribute to the outcomes. They define outputs as the tangible products, goods and services produced by a management system. Therefore, system requirements for HBIM must not be written in terms of BIM outputs such as model level of detail (LOD) [17]. Another reason for this outcome-based requirement definition is that digital systems need to “coordinate and align, rather than command and control” [18] and be flexible to account for “different approaches to modelling, data types and data collection” [11]. This is not unprecedented for a BIM standard as one of the first stages of ISO 19650 [19], which is the existing BIM standard, is the creation of a BIM Execution Plan (BEP) where the project-specific BIM requirements must be defined using the standard as a guiding framework.

Further details of how SE has been applied to this research are given in Section 2. The system requirements within this paper are intended to be applicable to a broad definition of CH and should encompass the majority of potential requirements. However, it is envisioned that any asset owners intending to implement an HBIM system for their own assets will, as is the case for all decision making in a heritage context [20], evaluate all suggested requirements and choose the most appropriate ones for their own use case. Hence, stages 6–11 of the V-process diagram (Figure 1) are not encompassed within this article. It is not expected that all HBIM systems will implement every suggested requirement. Instead, the intention is that the proposed system requirements will guide software and policy development in the field of HBIM.

Figure 1. V-process system diagram. Adapted from [21]. Grey arrows indicate process order. Black arrows indicate validation stage.

Figure 1. V-process system diagram. Adapted from [21]. Grey arrows indicate process order. Black arrows indicate validation stage.

1.2. Research Context

1.2.1. Background and Aim

This report is part of ongoing work by the authors endeavouring to define a standard methodology for HBIM. There are three previous pieces of work by the authors which provide a background to this paper [5,21,22]. Figure 2 outlines the chronological order of the previous works and their contributions to this paper (requirement elicitation, survey creation and SSM), which will be elaborated on in the corresponding sections of this paper. Chronological order has been included so any omissions (primarily relating to information requirements) can be understood. The first two papers provide the theoretical background to the study based on grey and academic literature and the final paper is the first part of the research presented in this article. Whilst the authors would encourage readers to refer to the previous publications for fuller analysis and findings, all elements critical for the understanding of this paper are detailed within Section 1.2. Further details of the wider study are provided in Part 1 of this paper series [5].

The aim of this paper is to establish the end-user requirements for HBIM according to the UK Heritage Community. The Faro Convention defines the Heritage Community as “people who value specific aspects of cultural heritage which they wish, […], to sustain and transmit to future generations” [23]. This research engages a subset of the Heritage Community involved in the management and maintenance of CH. This subset has been chosen as, whilst HBIM may have applicable uses for the whole Heritage Community, it is individuals and organisations involved in the management and maintenance of CH who will contribute the financial and resource investment required to implement HBIM.

The objectives of this paper are as follows:

• Evaluate the validity of the theoretical HBIM information requirements proposed by Lovell et al. [22].
• Identify information requirements additional to the theoretical information requirements proposed by Lovell et al. [22].
• Evaluate the validity of the theoretical functional requirements proposed by Lovell et al. [21].
• Define end-user system requirements for HBIM.

Whilst the contents of this paper only consider the views of the UK Heritage Community, future work being undertaken by the authors will expand the scope to an international perspective.

1.2.2. Survey Creation and Distribution

In Lovell et al. [22], a survey was designed to enable the wider UK Heritage Community to contribute to the creation of standard methodology for HBIM. The survey had two parts, the first of which was intended to determine existing working practices within the heritage sector and how people involved in the management and maintenance of heritage currently manage their data, and the second was to validate the theoretical information requirements proposed by the authors (see Section 1.2.3). The survey asked participants about their experience working with heritage, how they currently manage heritage information, how they would use an HBIM if available, and what information it would need to contain. Participants were asked to identify if information requirements were ‘critical’ (work cannot continue without it), ‘useful’ (the information is value adding but work can continue without it), ‘wish-list’ or ‘not needed’.

Snowball sampling [24] was employed to identify participants for the survey. All participants were members of the Heritage Community (see Section 1.2.1) and the only exclusion criterion was that they had some experience in the management or maintenance of heritage. An initial set of participants were identified from the investigators’ existing links to industry, and via participants’ association with known heritage organisations or historical assets.

Two pilot surveys were conducted. The first occurred during the development of the survey [22] to ensure the accessibility and clarity of questions and responses, and the resulting survey was made available as a two-part online survey or interview (questions were identical regardless of format). The secondary pilot survey was conducted with an initial sample of fourteen participants [5]. Fourteen participants were found to provide sufficient data to determine which questions resulted in duplicated or unclear answers.

As a result of the pilot surveys, two additional information requirements were added: ‘cost of work’ within the maintenance manuals/instructions section and ‘CO₂ levels’ within the environment data section. These additional information requirements were each suggested as important by two participants of the secondary pilot, hence their inclusion in the survey. In addition, it was found that some questions could not be clearly answered within the survey as they were too broad. For instance, participants were asked how frequently maintenance information would need to be updated but it was found that this answer varied depending on the specific item requiring update. It was also found that the length of the survey was discouraging participants from completing both parts. Consequently, some superfluous questions were removed, and it was reduced to a one-part online questionnaire of approximately one hundred questions. Since the questions were not altered, the responses from the secondary pilot questionnaire will be included herein. Further discussion of the removed questions will be given in later sections as appropriate.

Full details of survey distribution and the secondary pilot study, as well as responses to the first half of the survey itself, are provided in Part 1 of this paper series [5]. This paper primarily refers to the second part of the survey which was intended to identify information requirements and system requirements for an HBIM system. The exception to this is responses in the first part of the survey that are directly applicable to the requirement definition, which are appropriately indicated throughout this paper.

Survey response collection occurred over a period of six months, and a total of thirty-three responses were received. The anonymised survey responses and a blank copy of the survey itself are openly available on the UBIRA E Data Repository and are accessible at the following address: https://doi.org/10.25500/edata.bham.00001189 (accessed on 24 October 2024).

Since the questions did not vary between the interview format and the online survey format, the responses are reported together to enable direct comparison.

1.2.3. Theoretical Requirement Elicitation

In Lovell et al. [21], theoretical information and functional and modelling requirements for BIM-enabled facility management (BIM-FM) were identified from the literature. Two functional requirements were identified: the ability to access and input data in the field [25] and the ability to record previous work and create intelligent maintenance schedules [26]. As part of the work, it was determined that the modelling requirements for BIM-FM should be further investigated.

Six information requirement categories for BIM-FM for existing assets (heritage and non-heritage) were identified by Lovell et al. [21]. Subsequently, in Lovell et al. [22], a further six information categories specific to HBIM were identified. The theoretical information requirements proposed by Lovell et al. [22] are shown in

Table 1. Theoretical information requirements for HBIM identified by Lovell et al. [22].

Information Category	Information Requirement
Geometric surveys—This is defined as the geometric information gathered with which to create the model. These data will typically be provided by techniques such as photogrammetry or laser scanning. These techniques produce point clouds, which are collections of thousands of points that provide a 3D representation of an area.	The geometric survey itself
	Details about the geometric survey, e.g., how and by whom it was carried out
Information (data) about the fabric of the asset—This is defined as the physical material/structure that makes up the asset.	Material data, e.g., what materials are used
	Architectural data, e.g., floor plans
	Current building fabric status data
Condition assessments—This is defined as inspections of the physical condition of an asset which could include, but is not limited to, assessments of decay or energy performance.	The raw data from the assessment
	The results and recommendations of the assessments
	Details about the assessments, e.g., how and by whom they were carried out
Legal requirements—This is defined as any requirement that may affect your ability to carry out certain work. This may include a planning regulation (e.g., Grade Listing, etc.) or statutory document (e.g., other requirements such as conditions of bequest).	Planning regulations
	Statutory documents affecting the asset
Historical information—This is defined as archaeological data (including data about lost heritage) and major changes to an asset (not regular conservation works) over time. It does not refer to historical significance.	Archaeological evidence
	Changes that have occurred over time
Environment data—This is defined as more detailed data about the specific environment (or space) of an asset which may affect its condition or performance. This may be at a large scale (e.g., whole building) or smaller scale (e.g., light levels in a specific room affecting a specific object).	Light levels (internal and external)
	Vibration levels
	Weather
	Dust levels
	Humidity
Safety and security information—This is defined as any information related to the safety and security of the asset. This could include fire evacuation drawings, locations of fire alarms, and accessibility information such as wheelchair-accessible routes.	Fire safety
	H&S
	Potential threats/risks and vulnerabilities
	Security
	Accessibility information
Space data—This is defined as information about how the physical space of an asset is broken down and used. This may include, but is not limited to, room allocations (space breakdown), which areas are open to the public/private (space usage), occupancy limits or average footfall (visitor information), etc.	Space usage
	Space breakdown
	Visitor information
Maintenance manuals/instructions—This is defined as information provided or required to help plan and/or carry out maintenance and conservation works on an object.	Required equipment
	Minimum level of performance
	Whether the maintenance can be performed by a normal user or requires skilled personnel
	Intervention type (work required)
	Intervention frequency
	Previous maintenance including conservation history
Historical significance—This is defined as the tangible or intangible significance which attribute to the importance of the asset, e.g., how it evidences a way or life/practice, architectural or structural importance, associations with notable figures, etc.	For education
	To inform management decisions
Location data—This is defined as information about the wider location surrounding the asset. This may or may not be owned by you. For example, a local river may be prone to flooding and a risk to your asset. Alternatively, it may be information about the grounds surrounding the asset itself, e.g., the boundaries of the land.	Setting of the asset (e.g., in grounds)
	Nearby physical hazards
	Related assets nearby
	Other generic locational information
Objects not part of the building’s fabric—This is defined as important objects not necessarily considered part of the building which could be artistic (e.g., tapestries, artwork, sculptures, etc.) or other moveable assets (e.g., old factory machinery, furniture with a specific significance, etc.).	Moveable objects
	Artistic objects

.

In Part 1 of this paper series [5], a further three information categories were identified from information already possessed by the participants. The additional information categories and corresponding requirements are detailed in

Table 2. Additional information categories identified by Lovell et al. [5].

Information Category	Information Requirement
Visual depictions—This is defined as images, drawings or surveys which provide a visual representation of all or part of an asset.	The visual depiction itself
	Details about the visual depiction, e.g., how and by whom a survey was carried out, the source of an image or drawing, etc.
Management plans/policies—This is defined as documents recording or dictating the strategic management objectives of an asset.	Management data and records
	Conservation policies
	Conservation management plans
Project files for proposed and/or previous capital works—This is defined as information created or required as part of the conception and design stages of a capital project (assumed to correspond with suggested information exchanges for RIBA stages 0–4 [27])	Schedule of works
	Feasibility studies
	Company minutes and correspondence
	Business plans
	Specification of works
	Design documents

. Since the information categories and corresponding requirements in Table 2 were identified from the results of the survey, their validation will not occur in this paper. Furthermore, after the survey response period, the authors identified that an additional information requirement (temperature) from the environment data category, which had been identified in their previous work [21], was erroneously excluded from the survey [22].

The generality of the information categories and requirements proposed in Table 1 and Table 2 should not be considered detrimental. They are intended to reflect the concept of Organisational Information Requirements (OIRs) given in ISO 19650, which “explain the information needed to inform high-level strategic objectives within the appointing part” [19] and are thus the high-level requirements. They are considered one of the initial starting points for BIM implementation and are subsequently expanded into more detailed requirements by subject-specific experts as BIM progresses. Part of this involves the creation of a BEP, where an organisation must decide project-specific BIM requirements. The expectation is that no project will have identical BIM requirements but there will be similarities across projects of the same type or by the same organisation. ISO 19650 does propose some OIRs for BIM implementation, but these are designed to be taken as a guide, not a constraint. Likewise, the information requirements given in this paper should also be taken as a guide and will not always be universally applicable to all cultural heritage.

1.2.4. The Problematic Situation and SSM

Part 1 of this paper series [5] explored the management and maintenance of CH, e.g., the problematic situation that HBIM will attempt to improve. It discussed the results of the first half of the survey, which explored working practices, and current and desired information management processes in the Heritage Community. SSM was then utilised to reflect on the survey responses and propose a root definition (core purpose) of an HBIM system. The authors believe this is a critical step in the SE process, which must occur before any system requirement can occur, as it allows any resulting system to be validated, e.g., ensures the system achieves the purpose it is intended for and behaves as expected in its given environment [10]. The proposed root definition was as follows:

“A system owned and maintained by members of the Heritage Community involved in the management and maintenance of cultural heritage, which, utilising BIM and HBIM technology financially viable to the Heritage Community, contains, in a structured and connected manner, all the information required for Heritage Management. The system makes information easy to locate to ensure informed management decisions” [5].

The key feature of the definition is a focus on structured information management. Requirement definition within this article is conducted with the expectation that HBIM should perform this given purpose.

2. Method

2.1. Overview of Applied Methodology

This section details the main research methodology applied herein. Section 2.2, Section 2.3, Section 2.4 and Section 2.5 provide additional explanation of the contents of this article. The three main stages of the research methodology, as well as the relevant section of this article, are depicted in Figure 3.

The first stage involved stakeholder engagement. This was conducted via a survey of members of the UK Heritage Community (see Section 1.2.2 for details of the survey and question types). Section 3 provides a brief overview of the participants of the survey. For more detail regarding the experience and expertise of participants, readers should refer to Part 1 of this paper series [5] or to the anonymised survey responses.

In the second stage (Section 4 of this article), discussions of survey responses regarding information, modelling and functional requirements for HBIM are detailed in the following order:

• Information requirements for HBIM (Section 4.1).
• Modelling requirements for HBIM (Section 4.2).
• Functional requirements for HBIM (Section 4.3). This includes an evaluation of the functional requirements suggested in previous work by the authors (Section 1.2).

The second stage presents the ‘raw’ responses without the use of SE terminology or processes. The requirements identified in Section 4 are not system requirements; they instead reflect the basic needs and wants of the UK Heritage Community. SE processes require a full understanding of these wants/needs before system requirements can be defined.

In the final stage of the applied methodology (Section 5), SE techniques are utilised to define system requirements for a future HBIM system. The responses presented in Section 4 provide the rationale for these system requirements.

Future work by the authors is discussed in Section 6.

2.2. Information Requirement Definition

Section 4.1 proposes the information requirements for HBIM, including the criticality of requirements, and the expected format and frequency of requirements. The main focus of the discussion centres around the information requirements given in Table 1. However, additional information requirements identified from participant responses are discussed in Section 4.1.18, and an updated proposal of information requirements for HBIM is made in Section 4.1.19.

Section 4.1.1 and Section 4.1.2 will provide a general evaluation of the validity of the proposed requirements and any job-specific variation, respectively. Section 4.1.3, Section 4.1.4, Section 4.1.5, Section 4.1.6, Section 4.1.7, Section 4.1.8, Section 4.1.9, Section 4.1.10, Section 4.1.11, Section 4.1.12, Section 4.1.13 and Section 4.1.14 will detail any additional comments made regarding each proposed information category. Whether the required information is pre-existing (Section 4.1.15), how frequently it is required (Section 4.1.16), and the expected format of information (Section 4.1.17) will also be discussed.

2.3. Modelling Requirement Definition

Since model creation is a major theme of existing research [2], Section 4.2 evaluates participant responses regarding whether an accurate modelling object is required to understand the proposed information categories.

2.4. Functional Requirement Definition

Section 4.3.1 details functional requirements for HBIM requested by participants throughout both halves of the survey.

As stated in Section 1.2.3, previous work by the authors of this paper [21] identified two key functionalities for BIM-FM: (i) the ability to access and input data in the field, and (ii) the ability to record previous work and create intelligent maintenance schedules. The responses from the survey serve as preliminary validation for these proposed functionalities, and their applicability to HBIM and will be addressed in Section 4.3.2.

2.5. System Requirement Definition

Section 4 presents requirements and end-user needs without using systems engineering techniques. Therefore, Section 5.1 defines the system requirements for HBIM proposed by the authors in response to the views expressed by the survey participants. A system requirement should be an unambiguous statement in response to a need/capability given by the end users [28,29]. System requirements focus on what the system must achieve without consideration of how it will be achieved. The system requirements in this report have been defined according to INCOSE guidance on requirement definition [30,31].

However, there are two key considerations where the requirement definition utilised herein differs from the guidance: technical feasibility and financial restraints. HBIM is a developing technology so it is the hope of the authors that if a given requirement is not yet technically feasible, the recommendations of this paper will help inform future development. Moreover, evaluation of the technical feasibility of the requirements according to currently available technology is intended as part of ongoing research by the authors.

In addition, financial restraints will differ according to the organisation implementing HBIM. Therefore, it is not feasible to define requirements accounting for this. However, the authors must acknowledge that, in the first part of the survey [5], participants mentioned a lack of/difficulty accessing funding both when asked about challenges they face with regard to working with heritage, and perceived barriers to HBIM implementation. Participants also suggested that existing hardware/software may be insufficient, and access to better hardware/software was not thought likely to be possible. Therefore, the only financial restraints the authors would like to suggest at this stage are that HBIM implementation should have a pragmatically low up-front cost, and should utilise hardware and software viably available to the proposed end users.

There are also some key exclusions to the defined requirements. Firstly, Section 5.1 does not define any information requirements to avoid duplicating the contents of Section 4.1.19. The exception to this is information requirements which have a tangible impact on the form of the HBIM system (e.g., location data).

Furthermore, some needs given by the participants can be interpreted as prerequisites of a good information system and good information management. For instance, Connor [15] states that an information system is well defined if, as well as satisfying the user’s real information requirements, it has the following characteristics:

• Easy to use and operate.
• Easy to maintain (i.e., to correct problems that occur).
• Easily enhanced.

These factors correspond with comments made by participants throughout the survey. Since these needs are prerequisites of information systems, they have been excluded from Section 5.1 for efficiency. In addition, in the first part of the survey [5], participants suggested a quality control procedure would be required for HBIM implementation. The authors suggest that this would be enabled by the realisation of the requirements in Section 5 and should be a standard aspect of good information management.

Another notable exclusion is risk management, which was mentioned by several participants throughout the survey. The Association for Project Management defines risk management as “a process that allows individual risk events and overall risk to be understood and managed proactively, optimising success by minimising threats and maximising opportunities and outcomes” [32]. The authors believe that since risk management is a process involving understanding and evaluating risks and their impact and is often intrinsically linked to Health and Safety (H&S), it is not realistic, nor is it safe to propose that an information management system may be able to perform risk management. HBIM may yet assist with the process of risk management by providing easier access to relevant information or by helping to facilitate collaborative risk analysis. However, the authors do not feel it is appropriate to include risk management as a system requirement for HBIM.

The requirement definition has intentionally not considered existing BIM guidance and requirements so as not to influence the requirement definition. The requirements defined in Section 5.1 should, consequently, be a true reflection of the survey responses. The intention was also to avoid technical jargon inherent to standards where possible so that the proposed requirements can be validated by consultation with the Heritage Community in future work by the authors.

Section 5.2 includes an initial discussion on the realisation of the modelling requirements for HBIM. The authors deem it necessary to provide some additional clarification and thoughts regarding modelling within this article since the creation of HBIM models is a prevalent area of research [2].

3. About the Participants

The participant IDs, job titles and organisations (where appropriate consent has been gained) of the thirty-three participants are detailed in

Table 3. Participant job roles and organisation. This table is also given in Part 1 of the paper series [5]. […] suggests an anonymised response.

Participant ID	Job Title	Organisation
1	Museum Manager	[…]
2	Carbon and Sustainability Manager	University of Birmingham
3	Contracts Manager	[…]
4	Operational Programme Manager	[…]
5	Site Engineer	[…]
6	Head of Service—NDSU	BCC [Birmingham City Council]
7	Data Manager	University of Birmingham
8	Head of Historic Buildings	Historic Royal Palaces
9	Committee Member and Trustee	The Moseley Society
10	Facilities Manager (Head of Facilities and Asset Management Department)	Birmingham Museums Trust
11	Assistant Building Surveyor	National Trust
12	Collections and House Officer	National Trust
13	[…]	[…]
14	Head of BIM and Digital Assets	University of Birmingham Estates
15	Senior Building Surveyor	[…]
16	[…]	[…]
17	Secretary	Romsey & District Buildings Preservation Trust
18	[…]	[…]
19	Project Development Manager	[…]
20	Project Manager Conserving the Historic Estate	[…]
21	Author and Editor	[…]
22	[…]	[…]
23	[…]	[…]
24	Archaeological Illustrator	[…]
25	Architect (Director)	Rodney Melville & Partners
26	HBIM Coordinator	[…]
27	[…]	[…]
28	Engineer	[…]
29	CEO	Heritage Lincolnshire
30	Head of Infrastructure	Severn Valley Railway
31	Chief Executive	Portsmouth Naval Base Property Trust
32	Infrastructure Manager	Gloucestershire Warwickshire Steam Railway
33	Head of Building Conservation	English Heritage

. The participant IDs will be used to refer to answers given by specific participants throughout this report.

All participants were members of UK organisations and had some experience in the management and maintenance of heritage. The participants were grouped into three broad job areas so that any differing requirements could be inferred. These job areas were as follows [5]:

• Heritage Management—Individuals who are involved in the management and maintenance of heritage assets specifically.
• General Management—Individuals who are involved in the management of a number of assets, which includes some heritage assets, or individuals who look after an asset because of the function it serves.
• Architecture, Engineering and Construction (AEC)—Individuals involved in the AEC industry. This incorporates both organisations specialising in heritage projects and organisations who typically deal with non-heritage assets.

Over 60% of the participants worked within Heritage Management, with approximately 20% working in AEC, and 15% working in General Management.

4. Requirement Definition

4.1. Information Requirements

4.1.1. Validation of Theoretical Information Requirements

For each suggested information requirement, participants were asked to indicate whether it was ‘critical’ (work cannot continue without it), ‘useful’ (assists with/adds value to a task but work can progress without it), for a ‘wish-list’, or ‘not needed’. In order to determine the overall importance of a given requirement or category, the responses were given three points, two points and one point for critical, useful and wish-list responses, respectively. Subsequently, the average overall importance of each information requirement was determined using Equation (1).

$$Average importance of requirement={\displaystyle \frac{(3\times no.\mathrm{‘}Critical\mathrm{’})+(2\times no.\mathrm{‘}Useful\mathrm{’})+(1\times no.\mathrm{‘}Wish-list\mathrm{’})}{no.responses}}$$

(1)

As previously stated, CO₂ levels and cost of work were added late and not all participants answered all the questions, so the importance has been averaged accordingly to allow direct comparison. The number of responses (n) for an information requirement is 30 unless overwise stated.

The average importance of a requirement has been included in response to comments made by the participants regarding challenges in working with heritage and perceived barriers to HBIM implementation. In Part 1 of this paper series [5], approximately 65% of respondents suggested that access and availability of funding/resources was a challenge for working with heritage and approximately 40% of respondents perceived the required cost as a barrier to HBIM implementation. Thus, it appears evident to the authors that HBIM implementation is likely to be a staggered process. Therefore, understanding the importance of a given requirement may help end users establish a priority for what information should be gathered and populated within an HBIM system first. Furthermore, in later sections of this paper, the importance of the information requirement will be compared to other requirements of HBIM. For instance, in Section 4.2, the importance of information requirements will be compared to participants’ comments regarding modelling requirements to justify conclusions on modelling requirements.

Figure 4 and Figure 5 depict the responses collected from the survey and the relative importance of the proposed information type. The information requirements are grouped into the information categories given in Table 1. Both the average importance for both the individual information requirements and their associated information category are shown in Figure 4 and Figure 5. There was some variation between individual information requirements within a single category, but this was not more than one point for any category. The two most important information categories were ‘Information (data) about the fabric of the asset’, where no information requirement was perceived as ‘not needed’, and ‘Safety and security information’, which received the largest number of critical responses. The most important information requirement overall was ‘materials data’.

Figure 4 and Figure 5 illustrate a large amount of consensus with the proposed theoretical information requirements for HBIM. No information requirement had more than 27% of respondents state it was not needed. Only eight information requirements had more than 15% of respondents state that the information was not needed. This included all six subtypes for ‘Environment Data’ (light levels, vibration levels, weather, dust levels, humidity, and CO₂ levels), space usage and moveable objects. Environment data were deemed the least important category overall.

Whilst there is variation in information criticality across all the proposed information requirements and the sample size is small, this should not be considered detrimental to the validation of the proposed information requirements for HBIM as consensus suggests each is useful. Furthermore, in the first part of this paper series [5], eleven of the twelve theoretical information categories in Table 1 were found to correspond with information already possessed by the survey participants. The theoretical information requirements for HBIM proposed by Lovell et al. [22] are thus confirmed. Future work could seek to increase the sample size of the survey to provide additional support. However, the purpose of the survey is not to provide a definitive list of all HBIM information requirements. Instead, the purpose is to define potential information requirements which are likely to be required for the majority of cases. The generalisations inherent to creating a standard mean that the limitations of the survey are insignificant.

4.1.2. Job-Specific Variation

Since the survey encompassed many different job titles and three distinct job areas (Heritage Management, General Management and AEC), some job-specific variation was expected. Evidence of this variation across job areas is provided in Figure 6 and Figure 7. They depict the average importance of each information requirement for each of the three job areas. Whilst there are insufficient responses for each information requirement from the AEC (n ≈ 7) and General Management (n ≈ 6) sectors to provide a conclusive discussion of the information requirements of the sectors, there is a clear difference in the average importance of each requirement. This may reflect differences in working practices/ethos. For instance, the ‘Society for the Protection of Ancient Buildings (SPAB) approach’, credited for launching the conservation movement in the UK [33], stresses the importance of understanding the fabric of the asset and its current condition. Appropriately, individuals involved in Heritage Management considered these requirements more important than those involved in the General Management sector.

Likewise, individuals involved in Heritage Management were more interested in the changes that had occurred over time than those who worked within General Management or the AEC sector. Participant 18, who worked within Heritage Management, believed it would be “invaluable”, whereas Participant 26, from the AEC sector, suggested information of this sort was only needed by a historian. Future work may seek to more thoroughly consider job-specific variation.

4.1.3. Geometric Surveys

Geometric surveys are included here as a distinct information source as opposed to a tool with which models can be created. No participant stated that the geometric survey itself was not needed, and at least 37% of participants believed details about the survey were critical, which corresponds with Historic England guidance that survey metadata should be a contractual requirement [34]. However, it must be recognised that the perception of 3D geometric surveys from the participants was not completely positive and was, in some instances, contradictory. For instance, Participant 10 suggested that surveys should be checked every time they are updated so the condition of the buildings can be summarised. Conversely, Participant 25 was concerned that “the greater the degree of information held within the geometric survey, the higher the risk that this becomes the basis for information gathering and generation, rather than first hand inspection and survey which is more likely to enable interrogation of findings and significance”, implying they did not believe digital surveys were a sufficient replacement for in-person surveying. Moreover, both Participants 21 and 32 suggested that the need for geometric surveys was related to the age/complexity of the asset, with Participant 32 saying the assets they worked with (rail assets) were “not that complicated” and Participant 21 saying the “older and more complex the more you need it”. Participant 26 believed conducting geometric surveys was time-intensive, and Participant 18 suggested the storage and processing requirements were too high to be feasible for small organisations to implement. Even Participants 10 and 29, who were both positive about geometric surveys, acknowledged that their level of detail or frequency of updates would be cost-dependent.

Many of these perceived barriers, many of which were also identified in Part 1 of this paper series [5], will arguably become obsolete in the (near) future. For instance, whilst it is true that investing in surveying equipment that provides the highest level of geometric detail and visual accuracy (typically a combination of LiDAR and photogrammetry equipment [34,35]) remains prohibitively expensive for many small organisations, the quality achievable from more financially accessible surveying equipment is becoming increasingly better, making them a feasible alternative [36,37]. Even LiDAR, generally assumed to be too costly for small organisations, is becoming more accessible, with ongoing research looking at the feasibility of using phone-based LiDAR systems for actual surveying activities [38,39]. However, it must be noted that this remains theoretical at this time. Where storage requirements are concerned, many new surveying tools allow surveys to be hosted on a web-based platform, reducing the pressure on internal servers [40,41]. Furthermore, there is a large research focus within the field of HBIM on the automatic processing of these geometric surveys [42,43,44,45,46,47], which is likely to reduce the processing time and expertise required to generate the surveys. Regarding the cost of processing software, there are many types of Free Open-Source Software (FOSS), which are free to install and use and allow the processing or viewing of geometric surveys. For instance, Graphos (v0.92 bn 32) [48] and CloudCompare (v2.13.2) [49] are both FOSS which were designed specifically for the field of CH. Furthermore, Gaspari et al. [50] detail a project that utilises FOSS for the 3D documentation of heritage and for digital storytelling within a heritage context. Even proprietary software is becoming more accessible. For instance, RealityCapture (v1.5.1), a photogrammetry software created by Epic Games, is now free for companies earning less than USD 1 million in annual revenue [51]. To recoup the cost of the survey itself, Participant 29 suggested using the point cloud data along with 3D printing to create products for retail activities. This idea was evidenced by Participant 31 who had collaborated with artists to make retail items from their point cloud survey.

In light of this, the authors suggest the main barrier to the use and retention of geometric surveys for the management of cultural heritage appears to be a lack of awareness and expertise within the Heritage Community. This can be evidenced by Participant 29 who had previously worked on a project where a geometric survey had been conducted. They observed that “the data was incredibly useful” and that it was “useful for the architects and the design teams to have conversations together”. However, at the conclusion of the project, they did not have the organisational expertise or the software to use the data. They suggested that “it mystifies [the surveys] a little bit, and it makes [the surveys] seem like a thing that we don’t really need”.

4.1.4. Information (Data) About the Fabric of the Asset

Participant 18 suggested that utilising BIM for recording details about the fabric of the asset was a “valuable use case […] avoiding the usual practice of architects in hashing/shading elevation drawings to denote brick, concrete, steels etc.”. They did note that there were likely to be issues obtaining these data. Whereas BIM is likely to only contain information about what materials were used, the participants of the survey suggested that HBIM also needed to include the current condition as this allows day-to-day management as well as any strategic planning (Participant 3 and Participant 29). With regard to ‘information about the fabric of the asset’, Participant 29 hoped it would ensure all parties were using the same drawings and nomenclature.

4.1.5. Condition Assessments

The ‘raw data from the assessments’ and the ‘results and recommendations of the assessments’ were deemed critical by approximately 50% and 66% of participants, respectively. This reflects the ‘SPAB approach’ discussed in Section 4.1.3. However, Participants 17 and 21 suggested the level of detail for condition assessments was dependent on the intended use of the data or intentions for the asset.

Whilst not as critical as the surveys themselves, details of how condition assessments were carried out were deemed critical by approximately 23% of the participants. There were varying reasons for this, primarily regarding compliance or knowledge retention. Participant 30 discussed the need to ensure compliance with listed building constraints and Participant 31 talked about ensuring contractual compliance. This would correspond with a desire for quality control procedures. Participant 29 discussed needing the information so that in the future, it would be possible to recall who carried out the survey, how it was carried out and how much it cost.

4.1.6. Legal Requirements

Legal information was the third most important category overall. However, Participant 30 suggested that, whilst legal information and former planning applications/conditions are something their organisation possessed, current resources are “fragmented”. Therefore, it would be useful to have information in one place, and more searchable information would increase the speed at which information could be identified and accessed.

It was also noted that legal information is relevant at varying degrees of granularity. For instance, Participant 18 suggested it was geographic in scale, whereas Participant 17 referred to specific asset features.

4.1.7. Historical Information

The results suggest that participants require historical information for two primary reasons: firstly, to have a historical reference to how an asset has changed and what was there before (Participants 6 and 30), and then to understand how the changes have impacted the asset itself. Participants 3 and 10 suggested it would allow them to understand the current building condition and any issues, with Participant 3 elaborating that they could infer how the current operation of the building varied from how it was designed. This would inform decisions “by flagging up opportunities for reinstatement, or curtailing progression of certain options due to otherwise unforeseen obstacles” (Participant 3). Participants 29 and 31 believed it would help them understand any previous interventions, with Participant 29 specifying that a ‘searchable’ system would enable them to find information more quickly.

4.1.8. Environment Data

As previously stated, environment data were deemed the least important category overall. Participant 31 suggested they were only needed if you required a controlled environment or if architects needed to prove compliance with design. However, it is important to note that, for all the requirements within the ‘environment data’ category, at least two participants stated that the information requirement was critical. Participants 29 and 30 suggested weather and humidity data were important as they are elements which can cause deterioration to assets. Other participants were already using environment data to help with the management of their assets or could envision their benefits. For instance, Participant 6 was already using CO₂ sensors to help monitor the occupancy of rooms. Participant 10 believed it would be critical for “tracking progress towards Carbon Zero target” and for “understanding and monitoring actual levels against cost”. Thus, it is evident that environment data are applicable to more use cases than just controlled environments.

4.1.9. Safety and Security Information

Safety and security information was considered highly important overall. However, there was some variation in which specific information type was more important. For instance, Participant 30 suggested fire information was critical as it could result in total loss of the historic fabric, whereas Participant 10 suggested security information was more critical for museums. Participant 21 summarised the variations by suggesting that exact information needs are client-dependent.

4.1.10. Space Data

The importance of space data varied according to job area. For instance, ‘space usage’ was considered more important by those involved in General Management than those involved in Heritage Management. This might reflect the greater opportunities for dynamic space management in General Management compared to Heritage Management where it is reasonable to assume that conservation activities or significance constraints would dictate the use of a space more rigidly. Similarly, the purpose of the information was specific to the assets being managed. For example, Participants 18, 21, 29, 30, 31 and 33 all thought that space data were important, but this was primarily due to the fact the assets that they looked after were open to members of the public, so they had to ensure their safety or desired to record visitor numbers and fluctuations. Alternatively, Participants 5 and 10 believed space data were most useful for planning change.

4.1.11. Maintenance Manuals/Instructions

For all information types within the maintenance manuals/instructions category, over 75% of respondents stated that the information was either critical or useful (see Figure 4). Participant 31 suggested an additional requirement, proposing that, as well as required equipment, it should also include what materials are required for any maintenance work, which is especially applicable when there are listed building constraints.

The participants also suggested some requirements for how maintenance information should be presented. Participant 25 stated that “maintenance information is often used by people with no construction experience or background and so its storage and presentation should consider this aspect”. Expressing a similar sentiment, Participant 29 suggested maintenance information gets lost because it is prepared by others (architects, designers and the construction team), and at the point where the end users require the information, the significance of the information and where it is stored are no longer known. They suggest maintenance information should be stored in a logical way to counteract this. Participant 3 suggested that using a 3D model may enhance how information is documented. However, Participant 18 suggested that storing maintenance information digitally would represent a significant shift in working practices where information is paper-based, as also evidenced by Participant 6 who referred to Operation and Maintenance (O&M) documentation being available but stored in a paper format.

4.1.12. Historical Significance

Only Participants 3 and 5, who both worked within the construction industry, suggested historical significance was not needed for their role. As shown in Figure 5, over 60% of participants believed using historical significance ‘to inform management decisions’ was a critical requirement. Participant 6 believed it would be useful to store it within HBIM as it would assist with funding applications (e.g., Heritage Lottery), and Participant 25 summarised the importance of historical significance by stating “conservation strategies, issues, risks and policies are key to heritage projects, future works and maintenance operations”.

Historical significance ‘for education’ was deemed less critical, with only around 33% of participants stating it was critical. However, a further 43% (approximate) of participants believed it would be useful. Participant 18 believed it was critical for museums for preparing materials and that the adoption of tools for their management and creation would greatly improve the quality. Similarly, Participant 29 suggested it would be useful to be able to easily access and share information they generated as part of historical research projects. There was some variation in the intended audience of the information. For instance, whilst Participants 18 and 29 appeared to intend for the information to be shared with external stakeholders, Participant 31 suggested it was important to teach internal team members about the significance of the asset as it will impact how they care for it. This disparity in intended audiences was referenced by Participant 30, who suggested there was a need to present information according to different levels of interest and knowledge (basic or deeper).

4.1.13. Location Data

As shown in Figure 5, at least 90% of participants suggested that information regarding the ‘setting of the asset’ and ‘nearby physical hazards’ was at least useful. Similarly, at least 75% of participants believed ‘related assets nearby’ and ‘other generic locational information’ was at least useful. This was deemed particularly important for participants within AEC and Heritage Management (see Figure 6). Participants commented on various elements of planning and risk management: the need to understand the location and land boundaries when planning activities (Participants 5 and 29), changes to the nearby surroundings which may present increased risk to the asset or its content (Participant 10), or nearby physical hazards with a particular emphasis on flooding (Participants 6, 30 and 31).

Both Participant 30 and Participant 31 thought it would be useful to contain information about similar assets nearby. However, Participant 31 was referring specifically to similar assets within their own estate to inform new works, whereas Participant 30 was referring to assets owned by other railways. Participant 30 also suggested it would be useful to include information about assets nearby that had influenced their assets. For instance, the one station within their heritage railway had serviced a nearby coalmine which consequently heavily influenced the operation of the railway. This link contributes to the intangible heritage of the railway. Similarly, Participant 6 referred to geological investigations which had occurred at the former public baths they managed, which revealed that the baths were one of the first to be filled via municipal water as opposed to from the water table. It is evident that for both Participant 6 and Participant 30, the inclusion of location data is crucial for understanding the history of, and subsequently managing, an asset.

However, BIM models for new constructions will typically focus on the built element of a single asset as opposed to its surroundings. Furthermore, location data are not typically encompassed by existing BIM authoring tools and are usually contained in a GIS system. Since BIM and GIS were developed separately, there is currently limited interoperability of the two systems. There is existing research investigating the integration of BIM and GIS both for FM [25,52,53,54,55,56] and HBIM [43,57,58,59], but this is still a developing field. The inclusion of location data will also have modelling implications for HBIM, which will be discussed in Section 5.2.

4.1.14. Objects Not Part of the Building’s Fabric

BIM is primarily used in the AEC industry and typically encompasses information up to the handover stage of a project lifecycle. Consequentially, it is rare for a BIM model to include information about other objects within a structure (e.g., furniture, equipment or artwork) unless they are integral to the building’s function. This is further evidenced by Participants 3 and 5, who both work within the construction industry and stated that information about objects not part of the building fabric is not needed in their current role.

However, information about objects not part of the building fabric appears more important for ongoing management of assets. For instance, as shown in Figure 4, over 65% of participants believed that information regarding both ‘moveable objects’ and ‘artistic objects’ was at least useful in their role. Participant 29 even said that it is “essential to have” from an asset management perspective. On a similar note, Participant 10 suggested it was needed and should be “updated for insurance cover and asset records”. This may suggest that information regarding objects not part of the building fabric should be included in any BIM system for ongoing asset management.

This information has particular importance for museums or similar visitor-oriented attractions. Both Participants 18 and 29 suggested the information was crucial for museums, with Participant 18 suggesting an HBIM approach would be “far more useful” than the written reports they had previously used. On a similar note, Participant 31 suggested it could be used to plan how items were placed to improve the viewing experience of visitors. However, they also noted that they had achieved the same result using a paper-based scale model, so an HBIM approach to the same function would be nice to have but not essential. Both Participants 4 and 29 suggested that some items have environmental restrictions regarding where they can be sited (e.g., not within direct sunlight) so including the restrictions or combining the information about the assets with the environmental data would allow them to be sited accordingly. This once again supports the necessity of environmental data within HBIM despite their apparent unimportance in Figure 8.

Objects not part of the building’s fabric also contribute to the historical significance of an asset. Interestingly, this was mostly in reference to ‘moveable objects’ as opposed to ‘artistic objects’. For example, Participant 6, who managed a former public bath turned community centre, suggested it would be interesting to include information about some of the machinery they retained which had formerly been integral to the function of the baths. Furthermore, Participant 30, who worked with a heritage railway, suggested that it would “allow future generations to understand the relationship between the function of the site”. They gave the example of “a garage that’s housing a historic delivery vehicle”, illustrating the interrelationship between the function of an asset and its form. This suggests that for fully informed decisions to be made, information about objects not part of the building’s fabric is essential.

4.1.15. Is Information Pre-Existing?

Participants were asked whether they already possessed the given information categories (Figure 8). The intention was to infer the amount of additional work that would be required to implement HBIM. For instance, if an information type was found to be of high importance, but was not something that people already possessed, then any project to fully implement HBIM would have to allow for the creation/gathering of this information. The average importance of each information category (calculated previously from Equation (1)) is also depicted.

For every information category, less than 33% of participants stated that they already possessed the information and at least 20% of participants did not possess the requirement at all. It was expected that the average importance of an information requirement would correspond with participants already possessing the information. However, as illustrated in Figure 8, this was not the case. For instance, ‘information about the fabric of the asset’, which was deemed the most important information category overall, had only one participant state they already possessed the information. Likewise, more participants possessed information about ‘objects not part of the building’s fabric’ than ‘historical information’ despite the fact that ‘historical information’ was deemed more important. Thus, it can be concluded that successful HBIM implementation will also require a period of data collection and generation to populate the system.

4.1.16. Updating Information

During the secondary pilot stage of the questionnaire, participants were asked how frequently each information requirement would need to be input into the HBIM, output from the HBIM, and accessed within the HBIM. However, perhaps due to the broadness of the information categories, there was very little consensus in responses, and the questions were subsequently removed from the final version of the questionnaire. The lack of consensus is evidenced by Figure 9, which depicts the responses to “how often do you need to update this specific information requirement?” and shows no clear preference. When participants stated ‘rarely’, they were asked to specify what that meant. Only two participants stated that the information was not likely to change and one stated that they did not have the information at all. Further answers provided by participants revealed that the frequency of output, input and access to any specific information type was dependent on specific project stages or determined on an as-needed basis. Three participants suggested specific time periods when information changes, which ranged from 1 year up to 25+ years. Furthermore, Participants 5 and 16 provided further comments suggesting individual information types should be updated as needed or at varying frequencies depending on the end use/project stage. The frequency with which information is required is also dependent on the use of the asset. For instance, Participant 6 suggested that since they managed a public building, their risk assessments had to be monitored on an almost daily basis. The information types that needed the most frequent update were ‘environment data’ and ‘space data’. For instance, Participant 3 suggested environment data should be collected every thirty minutes since they are constantly changing data. Both Participant 3 and Participant 29 suggested space data needed to be updated almost in real time, so they had an accurate record of how a space was being utilised, whereas Participant 4 only suggested it should be reviewed as designs change, implying they were referring to new works. It is evident that the frequency of need is dependent on individual use cases and job roles. However, this information is not explicitly obtainable from the survey.

Whilst the questionnaire was unable to provide specific guidance on how often information needs to be accessed, input or output from HBIM, it does provide evidence that all the suggested information will need to be updated or altered over time. Participants 4 and 21 suggested all information should be dated to allow traceability and assurance that information is up to date. Similarly, Participant 10 mentioned checking information on the system is accurate. Participant 29 suggested all changes need to be recorded along with information about where removed items are stored. Participant 18 had previous experience using BIM for recording fire safety and maintenance information but suggested a challenge is keeping the information up to date with any changes made. An HBIM which is not easy to update and cannot act as a live tool will not be a sustainable long-term tool for asset management.

4.1.17. Format of Information

The format of information determines how it is stored within HBIM systems. Therefore, for each information category, participants were asked in what format they would require the information. The question allowed a free text response, so responses varied considerably. For clarity,

Table 4. Required formats of information.

Format	This Includes (and Assumptions)
Text	Text, written.
Image	Photographs, images, visual formats, etc.
Both	Taken as one count for image and one count for text.
Drawing	Plans and drawings were taken as the same thing. Assumption is plans refer to architectural plans. Diagrams and illustrations.
Report	Assumed to consist of multiple formats (e.g., text and image) and to only make sense as a whole.Report, document/documentation, manuals, handbooks, conservation plans.
BIM format	Including any mention of BIM, BIM exchange formats (e.g., Industry Foundation Class (IFC), etc.), BIM authoring tools (e.g., Revit).
Other modelling format	Any mention of 3D, any mention of survey formats, any mention of CAD or GIS.
Digital	Any other mention of a digital/electronic/online/site format (excluding BIM and other modelling formats).
Maps	Maps
Data	Data, numeric data, historical data, data sets, tables, spreadsheets, condition data, survey data, charts.
Unknown	No answer given or not known by respondent.
Other	See Table 5.

includes the given formats as well as any other answers that were grouped into a format or assumptions that have been made by the authors. For instance, images, visual formats and photographs are grouped under the umbrella format ‘images’. Figure 10 contains the required formats suggested by the participants for each information category. The most common responses were ‘text’ or ‘image’, which were provided to participants as example formats within the question. Several participants listed both text and image individually. For every information category, at least seven participants either did not provide an answer or stated that the required format was unknown. To the best of the authors’ knowledge, the only format given by the participants which is not a native capability of BIM authoring tools is GIS.

Table 5. Other format requirements suggested by participants.

Information Category	‘Other’ Format/Details	No. Suggestions
Geometric surveys	Possibility to extract dimensions	1
	2D	1
	A user-friendly format	1
Condition assessments	Cost	2
Legal requirements	Contact information	1
Environment data	Parameters	1
Environment data	Graphical	1
Safety and security information	Guidance	1
Space data	Dimensions	1
Maintenance manuals/instructions	Guidance	1
	Historic records	1
Location data	Display form at a visitor centre	1
Objects not part of the building’s fabric	Lists	1
	Significance	1
	Emergency response	1
	Inventory	1

contains format requirements provided by the participants which do not align sufficiently with the categories given in Table 4.

For certain information requirements, particularly condition assessments, the information was prepared by external companies (suggested by Participants 6 and 26). This results in information being prepared in report format with a combination of the raw data, text explanation and images (Participants 10 and 18). All these elements are important as raw data allow for sense checking (Participant 31), images provide a visual reference, and the explanation makes it accessible to non-experts. Participant 18 suggested that the current format of condition assessments does not enable easy collaboration.

4.1.18. Additional Information Requirements

Table 6. Additional information requirements identified from the survey.

Information Category	Additional Information Requirement	Participant No.
Information about the fabric of the asset	Whether any materials require additional protection during any building works.	4, 24
	Current sources of materials.	30
	Presence of hazardous material, e.g., asbestos.	3
	Historically correct building processes.	24
	Risks to the material, e.g., elements increasing degradation, existing defects, or materials reaching end of life.	12, 19–20, 28, 31
Condition assessments	Structural reports.	30
Legal information	Risk appointment, e.g., who is holding what commercial risk at what point.	31
Environment data	Footfall.	6
Maintenance manuals/instructions	What materials need to be used for maintenance activities, e.g., because of the type of building, to comply with listed building constraints, etc.	31

contains additional information requirements identified from the survey. Additional requirements were either explicitly stated or inferred from participant responses. The additional information requirements have been grouped according to the information categories given in the survey.

4.1.19. Complete Proposed Information Requirements for HBIM

Whilst the responses to the survey validated the information requirements proposed by the authors previously, they also revealed additional information already possessed by the participants (Table 2) and additional information requirements (Table 6). Furthermore, the omitted information requirement (temperature data) is a key part of the environmental management requirements of the participants. Therefore, the authors would thus like to propose an alteration to their previous work presented by Lovell et al. [22].

Table 7. Information requirements for HBIM.

Information Category	Information Requirement
Geometric surveys—This is defined as the geometric information gathered with which to create the model. These data will typically be provided by techniques such as photogrammetry or laser scanning. These techniques produce point clouds, which are collections of thousands of points that provide a 3D representation of an area.	The geometric survey itself
	Details about the geometric survey, e.g., how and by whom it was carried out
Information (data) about the fabric of the asset—This is defined as the physical material/structure that makes up the asset.	Material data, e.g., what materials are used
	Architectural data, e.g., floor plans
	Current building fabric status data
	Whether any materials require additional protection during any building works.
	Current sources of materials.
	Presence of hazardous material, e.g., asbestos.
	Historically correct building processes.
	Risks to the material, e.g., elements increasing degradation, existing defects, or materials reaching end of life.
Condition assessments—This is defined as inspections of the physical condition of an asset which could include, but is not limited to, assessments of decay, structural reports, or energy performance.	The raw data from the assessment
	The results and recommendations of the assessments
	Details about the assessments, e.g., how and by whom they were carried out
Legal requirements—This is defined as any requirement that may affect your ability to carry out certain work. This may include a planning regulation (e.g., Grade Listing, etc.) or statutory document (e.g., other requirements such as conditions of bequest).	Planning regulations
	Statutory documents affecting the asset
	Risk appointment
Historical information—This is defined as archaeological data (including data about lost heritage) and major changes to an asset (not regular conservation works) over time. It is not referring to historical significance.	Archaeological evidence
	Changes that have occurred over time
Environment data—This is defined as more detailed data about the specific environment (or space) of an asset which may affect its condition or performance. This may be at a large scale (e.g., whole building) or smaller scale (e.g., light levels in a specific room affect a specific object).	Light levels (internal and external)
	Vibration levels
	Weather
	Dust levels
	Humidity
	CO2
	Footfall
	Temperature
Safety and security information—This is defined as any information related to the safety and security of the asset. This could include fire evacuation drawings, locations of fire alarms, and accessibility information such as wheelchair-accessible routes.	Fire safety
	H&S
	Potential threats/risks and vulnerabilities
	Security
	Accessibility information
Space data—This is defined as information about how the physical space of an asset is broken down and used. This may include, but is not limited to, room allocations (space breakdown), which areas are open to the public/private (space usage), occupancy limits, average footfall (visitor information), etc.	Space usage
	Space breakdown
	Visitor information
Maintenance manuals/instructions—This is defined as information provided or required to help plan and/or carry out maintenance and conservation works on an object.	Required equipment
	Required materials
	Minimum level of performance
	Whether the maintenance can be performed by a normal user or requires skilled personnel
	Intervention type (work required)
	Intervention frequency
	Previous maintenance including conservation history
	Cost of work
Historical significance—This is defined as the tangible or intangible significance which attributes to the importance of the asset, e.g., how it evidences a way of life/practice, architectural or structural importance, associations with notable figures, etc.	For education
	To inform management decisions
Location data—This is defined as information about the wider location surrounding the asset. This may or may not be owned by you. For example, a local river may be prone to flooding and a risk to your asset. Alternatively, it may be information about the grounds surrounding the asset itself, e.g., the boundaries of the land.	Setting of the asset (e.g., in grounds)
	Nearby physical hazards
	Related assets nearby
	Other generic locational information
Objects not part of the building’s fabric—This is defined as objects not necessarily considered part of the building which could be artistic (e.g., tapestries, artwork, sculptures, etc.) or other moveable assets (e.g., old factory machinery, furniture with a specific significance, etc.).	Moveable objects
	Artistic objects
	Asset register
Visual depictions—This is defined as images, drawings or surveys which provide a visual representation of all or part of an asset.	The visual depiction itself
	Details about the visual depiction, e.g., how and by whom a survey was carried out, the source of an image or drawing, etc.
Management plans/policies—This is defined as documents recording or dictating the strategic management objectives of an asset.	Management data and records
	Conservation policies
	Conservation management plans
Project files for proposed and/or previous capital works—This is defined as information created or required as part of the conception and design stages of a capital project (assumed to correspond with suggested information exchanges for RIBA stages 0–4 [27])	Schedule of works
	Feasibility studies
	Company minutes and correspondence
	Business plans
	Specification of works
	Design documents

collates the new proposed information requirements for HBIM. Items described in italics represent additions and alterations to Table 1. The suggested information requirements now consist of fifteen information categories and sixty-two information requirements.

Future work by others may seek to repeat the survey with the new information requirements included to provide additional validation. However, the authors believe the suggested information requirements can be, in their current form, utilised as a guide to aid those looking to implement HBIM. It is expected that the actual information contained within an HBIM system will vary across different assets and organisations. The onus for determining what information is fundamental for a specific use case rests with the end user.

4.2. Modelling Requirements

Defining the appropriate modelling requirements for BIM is an often-confused process. Currently, there is a large focus in HBIM research on the generation of high-detail model objects [2,60,61,62,63,64,65,66]. Conversely, within the field of BIM-FM, there is a trend towards simplified model objects [67,68] and visualisation is considered low priority [69]. Furthermore, individual countries utilise different modelling classifications, albeit often with similar terminology, causing inconsistency in practical BIM applications worldwide [70,71]. Consequently, the authors of this paper previously suggested [21] that further research was required to understand the actual modelling requirements of BIM for existing buildings encompassing heritage. As such, participants were asked to indicate their agreement with the statement “an accurate 3D model object is needed for you to understand this information requirement?” for each information category. The results are displayed in Figure 10. The average importance of each information category is also depicted on the graph. It must be noted at this point that between 10% and 23% of the total survey participants did not provide a response to the question for every information requirement and Figure 11 only depicts the responses received.

There are a few key observations that can be made from the graph. Firstly, whilst at least 29% of the participants agreed that an accurate modelling object was needed, less than 50% of participants agreed with the statement for six out of the twelve categories. Furthermore, the two information categories deemed the second and third most important overall (legal requirements and safety and security information) only had 29% and 50% of participants agree with the statement, respectively. This would seemingly suggest that the high geometric accuracy of model objects is not a critical requirement for HBIM end users.

However, several of the participants did recognise the benefits of 3D visualisation. For instance, whilst they did not believe it would be directly applicable to their own role, Participant 3 suggested 3D models would provide better visualisation compared to existing plans and envisioned potential advantages of overlaying building services information to “aid in energy management conversations and decision making”. Likewise, Participant 30 suggested it would allow people to contextualise information by placing themselves within the room where the information was attributed, and Participant 6 suggested that, whilst they did already possess the information that a geometric survey would provide, having one would “bring [the information] to life a bit more”. Similarly, Participant 29, in reference to safety and security information, suggested that the information itself was essential and the model would be “nice to have” as it would make the information more readable by a wider audience. Participant 21 believed that geometric modelling would not improve the understanding of historical significance unless new things were discovered as a result of the modelling. However, the discovery of hidden items is a proven use case of HBIM as evidenced by Woodward and Heesom [72].

It is reasonable to suggest that the three information categories where at least 60% of participants agreed with the statement (geometric surveys, information about the fabric of the asset, and space data) could be encompassed by retaining an accurate 3D survey within/or linked to the HBIM. This suggestion is also supported by Part 1 of this paper series [5] where many of the perceived benefits of HBIM were attributed to the capabilities of the 3D surveys themselves and the improved visualisation opportunities they provide compared to photographs or plan drawings. In this way, the inclusion of a geometric survey entails an additional level of information linked to the model which helps meet the actual requirements of the end user.

4.3. Key Functionalities Required

4.3.1. Functions Suggested by Participants

Near the end of the first part of the questionnaire, participants were asked “what are the key functionalities you would require a HBIM to perform in order for it to assist with your role?”. Several participants suggested additional functions as the survey progressed, so they have also been included here. However, many of the answers given were described more as general needs as opposed to functions. Consequentially

Table 8. End-user needs for HBIM according to survey participants.

No.	End-User Needs of HBIM According to Survey Participants	Participant Number
1	Easy to use/navigate/input/update data.	5, 15, 18, 19, 22, 23, 27, 31, 32
2	Data management structure that provides a comprehensive and accurate record of all asset information (regardless of form).	4, 5, 8, 18, 19, 20, 27, 33
3	Easily accessible.	17, 19, 22, 24, 27
4	Inform/record maintenance, mandatory compliance checks, and testing schedules.	11, 14, 20, 28, 29
5	Increasing public engagement, interactivity, information sharing, accessibility, and visitor experience.	1, 6, 12, 21
6	Include information about the materials used.	20, 21, 28, 30
7	Able to view data in different degrees of granularity.	2, 3, 8, 13, 17, 18
8	Comprehensive and accurate as-is record of an asset including form and function.	19, 21, 30, 33
9	Integrate with other systems without duplicating information.	10, 31, 18
10	Flexible to allow extension and customisation of the system.	18, 22, 25
11	Record all details of previous and ongoing works, e.g., what was carried out, by who, what materials and equipment were used, and how much they cost.	12, 29, 30
12	Able to store and edit digital images and their associated metadata.	5, 17, 33
13	Associate visual and archival information with a specific location.	6, 8, 13
14	Exportable and accessible in multiple formats/hardware including existing (iOS and Microsoft) and new (AR/VR).	4, 17, 24
15	Ability to share/receive information and collaborate with third parties.	4, 6, 21, 26
16	Include geometric and spatial data.	5, 16, 28
17	Record/contain all changes to the asset over time (including form and function).	21, 29
18	Ability to search information.	29, 30
19	Accessible and updateable in the field.	10
20	Record historic data in relation to the as-is condition.	30
21	Ability to compare data.	5
22	Easy to adopt from the 2D environment.	23
23	“Flag high energy consuming assets […] Also enable visualisation of changes in energy performance (both positive and negative) over time (hourly, daily, weekly, monthly, yearly). Integration with other sources of data (weather, occupancy, etc.) would add value”.	2
24	Include lifecycle to drive asset management strategy.	13
25	Allow ongoing asset management.	30
26	Act as a tool for cost estimation utilising dynamic pricing to increase the accuracy of estimate.	31

includes the end-user needs suggested. Answers are listed in order of commonality.

The most common need was that it should be easy to use/navigate/input and update data. This was generally due to the perceived digital literacy within the participant’s organisation. The second most common need was that the system must provide a comprehensive and accurate record of all asset information. Multiple formats of information were suggested.

4.3.2. Theoretical Function Validation—Ability to Access and Input Data in the Field

Participant 10 explicitly stated that one of their required functions was the ability to access data in the field (see Table 8). Furthermore, Participant 29 suggested that, in reference to maintenance manuals and instructions, the information was primarily needed in the field. They suggested that given that much of the work occurred in remote locations, workers relied on paper copies of documents due to unreliable mobile signal. This suggests that HBIM systems need to allow information to be accessed in the field but there should be an allowance for work in remote locations, e.g., ability to download information to a device in advance or delay the update of information until signal is acquired. This is already possible with many BIM tools which are designed to be used on construction sites where mobile signal is not guaranteed (e.g., Autodesk Construction Cloud: Build [73]). The responses of Participants 10 and 29 suggest the first function (accessibility in the field) proposed by Lovell et al. [21] is both applicable to HBIM and supported by the end users.

4.3.3. Theoretical Functions Validation—Ability to Record Previous Work and Create Intelligent Maintenance Schedules

Regarding the first aspect of the suggested function (ability to record previous work), no participant stated that information regarding ‘previous maintenance including conservation history’ or ‘changes over time’ was not needed. Therefore, the ability to record previous work can be considered a critical function for HBIM.

Intelligent maintenance schedules would theoretically include information about when maintenance activities are required, and any details required to carry them out, allowing organisations to undertake proactive maintenance. The information needed for this should be encompassed within the maintenance manuals/instructions category. No participant explicitly referred to the creation of intelligent maintenance schedules. However, in Part 1 of this paper series [5], participants suggested the ability to plan activities would be a beneficial application of HBIM for facility management. Moreover, as discussed in Section 4.1.11 for all information types within the maintenance manuals/instructions category, which would enable the realisation of this function, over 75% of respondents stated that the information was either critical or useful.

Furthermore, the participants suggested functions and requirements which would arguably be encompassed within an intelligent maintenance schedule. Participant 30 suggested that having details of the ‘intervention frequency’ and ‘whether the maintenance can be performed by a normal user or requires skilled personnel’ would allow anyone to be able to “pick it up” and understand when work needed to occur and how. Participant 4 suggested that any HBIM system should also allow you to “review that planned maintenance is being completed as per recommendations”. Participant 33 suggested that any information should be immediately updated to reflect any changes to equipment. Reviewing the participants’ information requirements and their expressed views on how they would use an HBIM system. The authors thus conclude that the ability to create intelligent maintenance schedules is a valid function for HBIM. However, given the presentation requirements for maintenance manuals/instructions also discussed in Section 4.1.11, they should be designed to be understood and usable by non-experts.

5. Systems Thinking for HBIM

5.1. Defined System Requirements

Table 9. System requirements for HBIM.

Requirement Theme	ID	Requirement	Rationale for Capability	Section Number of Part 1 [5]	Section Number of Part 2 (This Work)
Information management	I1	The HBIM system will contain a comprehensive and accurate record of asset information (regardless of form). Note—The types of asset information will likely correspond with the information requirements identified herein (see Table 7) but exact information will be asset-specific.	Need explicit identification by participants.	N/A	4.3.1
	I2	The HBIM system will allow new information to be added over time whilst retaining previous information.	Ongoing asset management was an identified need, so it is expected that new information will be generated over time. This was supported by the conclusion that all information types need to be updated at varying frequencies. Poor access to historical records/information is a key challenge of working with heritage so the system should retain any old data. If it is not easy to add new data, then the HBIM system will become obsolete over time.	3.3.5	4.1.16, 4.3.1
	I3	The HBIM system will have a search function for finding information.	Searchable data were explicitly requested by participants. Furthermore, currently, a key challenge to information management is that there is too much information stored in too many ways. Some participants had to rely on institutional knowledge of where information was stored, and this resulted in lost information due to staff turnover. Searchable information would also increase the speed at which information can be identified and accessed.	3.2.2	4.1.6, 4.1.7, 4.3.1
	I4	The HBIM system will have a structured, reportable and viewable data storage schema.	As previously mentioned, for many people, the problem is not insufficient data, it is too much data stored in too many different ways and reliance on institutional knowledge previously led to data loss due to staff turnover. Another participant suggested that if the information is prepared by others, by the time it is needed, the significance is often lost and then the data themselves are lost. Hence, the location where data are stored should be logical and should be recorded so others can find them later or if the asset changes ownership. This will also assist with the participants’ desire to share systems with their successors.	3.2.2	4.1.11
	I5	The HBIM system will allow information to be viewed at different degrees of granularity.	This was explicitly identified as a required need. Participants also mentioned wanting to be able to break down information from the whole asset to part of the asset. For instance, they suggested legal information is required at different degrees of granularity, e.g., just a wall or the whole asset.	3.4.8	4.1.6, 4.3.1
	I6	The HBIM system will allow all information to be accessed from a single source.	Currently, information is stored in too many different places, so it takes time to collate it, especially when planning new renovation or restoration works. Data being accessible from one place (even if they are not stored in one place) will reduce the time and resources required.	3.4.4, 3.4.5	N/A
	I7	Information in the HBIM system should be associated with a digital entity with a known position in space.	Associating visual and archival information with a specific location was a need explicitly identified by participants. Some participants mentioned being able to select BIM objects and see information associated with that object.	N/A	4.3.1
	I8	The HBIM system will record and report each change made to asset information.	Participants suggested that changes to information should be traceable so they can be checked and understood by others and that HBIM should allow version control.	3.4.4, 3.4.11	N/A
Collaboration	C1	The HBIM system will present current planning/legislative/listing restraints in a manner clearly understandable to users without expert knowledge.	Planning/legislative/listing constraints were identified as a key challenge for working with heritage. Participants also discussed issues communicating the implication of these constraints to clients, suggesting there was disparity between client aspiration and expectations compared to what was feasibly possible.	3.3.5	N/A
	C2	The HBIM system can share and receive information for related assets (both internally within an organisation or externally).	The benefits of sharing/receiving information regarding similar assets nearby were mentioned by several participants. They suggested both their own assets and assets owned by others, and suggested it may allow improved knowledge or a more comprehensive database of information.	3.4.6	4.1.13
	C3	The HBIM system can present the same information in differing ways for a defined audience.	Throughout the survey, participants mentioned the need to share information with people who may have differing levels of knowledge, interest or security clearance. For instance, they mentioned members of management who may work with multiple assets so may not have in-depth knowledge, and they mentioned preparing heritage displays for people with just general knowledge or who wished to undertake specific research. They also mentioned the fact that information is usually prepared by experts and then given to non-experts (e.g., maintenance information given to an asset owner or listing constraints explained to an asset owner). Communication with clients was listed as a specific challenge.	3.4.8, 3.4.11	4.1.11, 4.1.12
	C4	The HBIM data will be shareable with specified access controls.	Participants worked with external contractors/volunteers. They needed to share information with them whilst complying with any associated data security needs. This also extended to members of the public or members of their internal team who may have different access permissions.	3.3.4	4.1.12, 4.3.1
	C5	The HBIM system will be aligned with existing BIM practices for non-heritage assets	Participants suggested that having a system applicable to both modern and historic assets would increase opportunities for cross-sector collaboration. BIM for new assets is the more mature sector and many of the tools already being used by the participants aligned with existing BIM processes, so the alignment should be with the existing procedures.	3.2.3, 3.4.8	4.1.17
	C6	The HBIM system will integrate with other systems without duplicating information.	A need explicitly identified by participants. Participants also explicitly identified a need for information to be exportable and accessible in multiple formats/hardware including existing (iOS and Microsoft) and new (AR/VR).	N/A	4.3.1
System operability	S1	The HBIM system will be accessible from multiple locations at the same time.	Participants suggested they have hybrid working patterns involving some home working or site working so a central system would not be practical. All but one of the participants worked in teams of more than one person, so it can be assumed that multiple people will need access to the same information.	3.3.3, 3.3.4	N/A
	S2	The HBIM information will be accessible to users without an internet connection.	Participants suggested there was a need to access data in the field, where there is no or insufficient internet connection.	3.4.12	4.3.1
	S3	Users without an internet connection can record new information to be input into the HBIM system.
Resource management and planning	R1	The HBIM system will indicate whether an area is private or open to the public and any restraints this poses, e.g., maintenance timing or increased level of risk for the public.	It was identified from the survey that an asset/area being open to the public has implications for the management of that asset. For instance, it may have seasonal opening times to allow for maintenance periods or restrict maintenance to occurring at night. Major projects then rely on long closures. Furthermore, H&S sometimes changes depending on whether the public are around.	3.3.2	N/A
	R2	The HBIM system will collate and prepare information required for funding applications.	Participants suggested there is limited staff and time available to prepare funding applications. Moreover, significant resources are required to complete funding applications, so reducing this could provide a financial benefit of HBIM.	3.3.5	N/A
	R3	The HBIM system will collate and prepare information required to undertake defined activities.	Participants suggested there was limited time, staff and resources for planning activities. If HBIM can make this process quicker or less labour-intensive, it will provide a financial benefit to HBIM. Note—These functionalities could also be applied to risk management.	3.3.5	N/A
	R4	The HBIM system can be used to digitally simulate planned activities.
	R5	The HBIM system will calculate the expected costs of user-defined work.	Participants identified the need for cost estimations for work (particularly maintenance work). One participant suggested that dynamic pricing that could reflect real-time cost estimates would allow more accurate cost estimation.	N/A	4.3.1
	R6	The HBIM system will record and report all details of each work activity undertaken and each future work activity planned.	It became clear from participant comments regarding conservation works that HBIM should be an ongoing tool used for continuous monitoring and tracking. Participants suggested it should record all details of previous and ongoing works, e.g., what was carried out, by who, what materials/equipment were used and how much they cost. Recording of previous work was considered a key function.	3.4.6, 3.4.9, 3.4.11	4.3.1
	R7	The HBIM system will assist with the creation of proactive maintenance schedules utilising both mandatory testing intervals, previous maintenance records and current asset condition.	Participants explicitly identified the need for HBIM to inform/record maintenance, mandatory compliance checks, and testing schedules. Section 4.3.3 provides further explanation.	N/A	4.3.1, 4.3.3
Visualisation	V1	The HBIM system will record and visually display information associated with the location of the asset.	Location data were deemed crucial for Heritage Management.	3.2.3, 3.3.5, 3.4.11	4.1.13
	V2	The HBIM system will record and visually display each historic change to an asset (both large changes and small changes).	Participants suggested that for renovations and restorations, it would be useful to be able to review past repairs and alterations, over all periods of time. Others suggested that it would be beneficial to see how much of an original structure/material remains and how historic data relate to the as-is condition. Changes over time were also linked to the historical significance, form and function of an asset.	3.4.5, 3.4.5, 3.4.11	4.3.1
	V3	The HBIM system will provide a 3D visualisation of an asset.	Participants believed 3D visualisation can help with informed decision making and, for renovation or restoration projects, would provide a clearer vision of the end product. They believed that a 3D environment would make information easier to understand and find as a non-expert.	3.3.4, 3.4.5	4.3.1
	V4	The HBIM system will contain an accurate visual record of the current asset condition.	Participants wanted an accurate representation of the current asset condition and form. This was particularly so they could plan restoration works or track progress as work progressed. This was also deemed critical for translocations.	3.4.5, 3.4.10	4.3.1
Public engagement	P1	The HBIM system will assist with the creation, and dissemination of, audience-appropriate informative materials and educational resources with the public.	The use of HBIM ‘as a virtual tool used to share heritage with the public’ was the most preferred potential use of HBIM. This applied to all job areas. For instance, public engagement aids projects as it can the public are considered a powerful stakeholder in the AEC sector. Furthermore, for many heritage organisations, it is an inherent expectation that the public will be involved in all projects since public engagement and education are often requirements of heritage funding applications or charitable remits. Participants also mentioned a need to make sure information is appropriate for the target audience to ensure engagement, understanding and accessibility.	3.3.2, 3.3.5, 3.4.7	N/A
Environmental management	E1	The HBIM system will record and visually display environmental hazards associated with the asset.	Climate change and its impacts (e.g., flooding) are a key challenge of working with heritage, and end users need to be aware of what these are. Recording and displaying this information will allow end users to use HBIM for environment-focused risk management.	3.2.3, 3.3.5, 3.4.11	4.1.13
	E2	The HBIM system will monitor and report the near-real-time environmental conditions of the asset. Environmental conditions are derived from information under the ‘Environment data’ category.	This need was explicitly identified by participants. There is also a desire for tangible evidence of work towards net zero targets and an ability to better manage energy usage to reduce electricity costs (potential financial incentive for HBIM). Assessing current energy performance (via performance and environment monitoring) will allow the determination of areas of potential improvement. Furthermore, several participants mentioned that they required/already utilised multiple sources of environment/condition data for both the day-to-day management of an asset (e.g., CO2 to monitor occupancy) and also for understanding potential sources of deterioration (e.g., humidity causing damp).	3.4.4, 3.4.9	4.1.8, 4.3.1
	E3	The HBIM system will monitor and report the near-real-time performance of the asset. Performance will be evaluated against organisation-specific targets.
	E4	The HBIM system will allow the comparison of current energy performance with predicted outputs of alterations and upgrades.	Eco-friendly design in heritage assets is difficult, so tools to assist that would be beneficial.	3.4.4	N/A

contains the thirty-three new system requirements for HBIM defined by the authors and the rationale for each capability. The requirements were developed in response to both explicit statements from the participants and implicit needs based on their current experience working with heritage. Thus, both parts of this paper series were used to develop the requirements. Consequently, Table 9 indicates the appropriate section in both this article and the previous part of this paper series [5] for reference.

As previously stated (see Section 2.5), the technical feasibility of the requirements is not considered at this time. This will be encompassed by future work by the authors. It is the hope of the authors that, if this future work identifies any requirements as beyond the current capabilities of HBIM technology, this article will provide evidence to support the investment needed to realise these requirements.

System design is typically hierarchical, with a system consisting of many system elements and subsystems [10]. It has been long established that, due to the limited number of concepts the human mind can consider simultaneously, the optimum number for this is 7 ± 2 [74,75]. Hence, the requirements have been grouped into seven themes: information management, collaboration, system operability, resource management and planning, visualisation, public engagement, and environmental management. Each theme has less than nine requirements within it. The theoretical functions discussed in Section 4.3.2 and Section 4.3.3, have been rephrased to comply with system requirement processes and now correspond with requirements S2 and S3 (ability to access and input data in the field) and R6 and R7 (ability to record previous work and create intelligent maintenance schedules) in Table 9.

It is the belief of the authors that the realisation of an HBIM system designed according to the requirements given in Table 9 will provide tangible benefits for the Heritage Community. These benefits will include improved information management in a way that is transmissible to future generations of heritage managers, improved resource efficiency, and an enduring visual record of cultural heritage. These benefits will thus contribute to the realisation of the UN’s SDG 11: Sustainable Cities and Communities. Moreover, if Requirements E1–4 are realised, the implementation of HBIM in cultural heritage will also actively contribute to the realisation of SDG 13: Climate action [76]. The requirements also support the proposed root definition of HBIM with a focus on information management and informed decision making.

5.2. Achieving Modelling Requirements

It is the belief of the authors that too much emphasis is placed on the generation of detailed HBIM model objects without consideration of why these models are needed. Instead, HBIM users should consider how combinations of data (e.g., a simplified model combined with additional information) can fulfil their actual information needs. This is akin to the reflections of Castellano-Román and Pinto-Puerto [71] and is now reflected in international BIM standards. In particular, the new ‘Level of information need’ BIM standard, ISO 7817-1:2024 [77], “defines the extant and granularity of information to be exchanged” in terms of geometrical information, alphanumerical information and documentation. This standard will enable a more consistent specification of geometrical information within BIM. However, its application to BIM for existing buildings has received minimal consideration from the research community to date. This section provides preliminary consideration of how actual modelling requirements may be met. Future work by the authors will investigate alternative visualisation strategies for HBIM.

As discussed in Section 4.1.13, and subsequently in Requirement V1, HBIM should contain location data about an asset. However, this scale of modelling is typically not encompassed by BIM authoring tools, and the interoperability between BIM and GIS, the format which typically includes wider location data, is currently insufficient [54,78]. Two participants discussed their existing methodologies for storing location data: Participant 32 stated they use “Ordnance Survey CAD maps as basis for asset location and other details” and Participant 18 suggested it was “often sufficient to have just building footprint in site plans” but that an “accurate location e.g., from manual or topographic survey is critical for decision making”. However, these approaches risk siloing information. It is also important to note here that HERs are often linked to GIS systems [79].

Table 10. Potential solutions for modelling location data.

Option	Details
Do nothing	Utilise existing methodologies for storing and presenting location data, e.g., methodologies given by Participants 18 and 32.
Improve the interoperability of BIM and GIS tools	Sufficient interoperability would allow BIM and GIS information to be transferred across systems without loss of data.
Create new tools capable of storing and presenting GIS and BIM information in a single platform.	This would involve the creation of new software or exchange formats able to record data at all scales.

suggests three potential solutions for modelling location data. The simplest solution is to do nothing and to continue using methodologies like those suggested by Participants 18 and 30. The other two solutions are areas of research currently being undertaken: improving the interoperability of BIM and GIS tools [80,81] or creating new tools capable of storing and presenting GIS and BIM information in a single platform [82,83]. It remains to be determined which, if any, of these solutions will most effectively record location data within HBIM.

Regarding the historic asset itself, a key conclusion of the survey is that participants require 3D visualisation of the asset and the ability to access information from within this visualisation (see Requirements I7 and V2–4). However, they did not explicitly state that this should be the BIM object itself. In fact, in Section 4.2, less than 50% of participants agreed that an accurate modelling object was required for six of the twelve information categories. It was also found, in the first part of the survey [5], that many of the perceived benefits of HBIM were attributed to geometric surveys as opposed to the model objects.

Therefore, the authors suggest that simplified model objects are sufficient for the majority of HBIM applications, provided an accurate 3D geometric survey is undertaken, and retained by the end user.

Currently, efforts to create highly accurate HBIM models within BIM authoring tools represent a considerable investment in terms of cost and time [84]. Pivoting the focus from creating accurate BIM objects to retaining accurate geometric surveys would help meet the financial restraint of a pragmatically low up-front cost for HBIM (see Section 2.5). However, this statement may change if ongoing research efforts [85,86,87,88,89,90,91] to automate the creation of accurate HBIM models prove viable.

6. Future Work

The system requirements proposed herein are a product of the authors’ interpretation of the survey responses. Consequently, they may be unconsciously influenced by their own implicit assumptions. Thus, future work by the authors will seek to validate the system requirements for HBIM proposed here. This will be achieved by recirculating the proposed requirements to the Heritage Community for feedback. The intention is that this will also allow the interpretation of the relative importance of each requirement. Consequently, this will allow the evaluation of the ‘value’ of an HBIM system, defined by INCOSE as “a measure of worth of a specific product or service by a customer, and potentially other stakeholders and is a function of (1) the product’s usefulness in satisfying a customer need, (2) the relative importance of the need being satisfied, (3) the availability of the product relative to when it is needed, and (4) the cost of ownership to the customer.” [14].

The feedback-gathering stage will expand the scope of the study by seeking feedback from the international Heritage Community. This will be used to evaluate whether the requirements proposed herein are only applicable to the UK Heritage Community or whether they have an international relevance.

Assuming the requirements are sufficiently validated, they will be compared to available BIM technology/practice and existing BIM standards/guidance to identify how the requirements can be achieved and what opportunities for improvement exist. This will encompass the ‘requirements analysis’, ‘preliminary design’ and ‘detailed design’ stages (stages 3, 4 and 5) of the V-process diagram in Figure 1. The CDBB [18] suggested twelve ‘building blocks’ for enabling an ecosystem of connected digital twins, of which one was the creation of ‘soft standards and frameworks’. The future work outlined in this section should result in the creation of soft standards and frameworks for HBIM.

These standards are intended to be applicable to a broad definition of CH; hence, some generalisation is required. However, as previously mentioned, this does not mean that HBIM will be the same for every type of historic asset. It is envisioned that any asset owners intending to utilise an HBIM standard will tailor its application as appropriate for their own use case. This is the same way the existing BIM standard (ISO 19650 [19]) works, e.g., BIM for a hospital will vary considerably compared to BIM for a residential building, but the same standard is applied for both.

7. Conclusions

This paper presented the second half of a systems thinking approach to the development of HBIM. This two-part paper series presented the results of a survey conducted with members of the Heritage Community involved in the management and maintenance of heritage in the UK. The survey identified how heritage is managed, what problems are faced regarding working with heritage and with information management within the heritage sector, what information an HBIM should contain, and other capabilities required by the Heritage Community. This paper further developed the prior application of Soft Systems Methodology for the definition of the core purpose of HBIM in the first part of the paper series and employed ‘hard’ systems engineering to define system requirements for HBIM.

The forty-one information requirements proposed by Lovell et al. [22] were validated, and a further twenty information requirements were identified. This included an additional three information categories: visual depictions, management plans/policies, and project files for proposed and/or previous capital works. The two functional requirements proposed by Lovell et al. [21] were also found to be consistent with the needs expressed by the survey participants.

INCOSE guidelines were used to translate desired capabilities expressed by the survey participants into thirty-three system requirements for HBIM. Future work by the authors will involve the recirculation of the proposed system requirements to the Heritage Community for validation. If found to be valid, the system requirements will be compared to available standards (process, data, and technology standards/ontologies) and technology for HBIM to identify opportunities for requirement realisation and areas for improvement.