Transformation of construction project management toward situational awareness

Abstract

Purpose

With the ongoing digitalization of the construction industry (CI), situational awareness (SA) is becoming increasingly important in construction management. The purpose of this article is to identify the requirements of SA system development in the CI and to provide recommendations for the future development of SA systems.

Design/methodology/approach

In this exploratory multi-case research study, a literature review and five Finnish cases were used to gather the evidence on how system developers have planned SA systems and what motives and objectives were behind their development efforts. An analysis of the cases, along with a review of SA models and concepts from other sectors, was used to identify requirements and deficiencies of the SA systems developed by CI actors.

Findings

This study reveals deficiencies in the recent SA systems. The systems seemed to be based on traditional project models, in which the role of the individual as the creator and interpreter of an SA system is still significant. Major requirements and future development of the systems are related to better SA levels of perception and projection and data quality.

Research limitations/implications

This study contributes to an understudied area of SA in the construction context and provides new insights into how construction companies develop their SA systems. The main study limitations are its geographically limited case selection and the limited generalizability of the results.

Practical implications

The research (1) shows what requirements and systemic weaknesses SA developers in the CI must consider in future development work and (2) shows developers the requirements to obtain holistic SA.

Originality/value

The study provides insights into the content of newly developed SA models and integrates developers' requirements into the SA theory.

Citation

Lappalainen, E.M., Seppänen, O., Peltokorpi, A. and Singh, V. (2021), "Transformation of construction project management toward situational awareness", Engineering, Construction and Architectural Management, Vol. 28 No. 8, pp. 2199-2221. https://doi.org/10.1108/ECAM-12-2020-1053

1. Introduction

Construction projects are known for their delays, budget overruns and quality problems, as well as contractual claims related to these issues (Abdul-Rahman et al., 2006; Love et al., 2010). Poor management often leads to these negative phenomena (AlSehaimi et al., 2013). The construction industry (CI) is moving toward digitalized management by transferring the controlling and reporting of construction projects to digital platforms (Dong et al., 2006; El-Omari and Moselhi, 2011). The assumption in the CI is that data-driven, transparent situational awareness (SA) that leverages these digital applications and platforms will play a key role in solving traditional problems of construction projects (Aasland and Blankenburg, 2012; Alassaar, 2017; Fast-Berglund et al., 2016; Kaya et al., 2014). These expectations of CI actors are rooted in the origins of SA.

The fundamental need for SA originally arose from numerous fatal accidents in military air traffic. Air traffic controllers' and pilots' incomplete awareness of tactical situations led to the creation of the SA concept (Harrald and Jefferson, 2007; Sarter and Woods, 1991; Endsley, 1995). The concept has since been expanded to several industries, including construction. The basis of holistic SA is the integration of knowledge based on recurring situation assessments and the creation of a coherent picture from these recurring situation assessments (Sarter and Woods, 1991). Endsley (1995) described situation assessments as a complex process of perception and pattern matching, limited by working memory and attentional capacity. In essence, the purpose of SA is thus to support human decision-making in a dynamically changing environment by considering the limited human data-processing capacity that earlier led to several serious accidents in the aviation industry.

In recent years, several researchers have studied and applied the SA model in the CI. Scholars have focused on improved occupational safety and the utilization of work machines and equipment, the role of building information modeling (BIM) in SA (e.g. Lonsdale, 2004; Li et al., 2018; Oloufa et al., 2003; Niu et al., 2016), location-based planning and control (Dror et al., 2019; Reinbold et al., 2019; Görsch et al., 2020) and construction logistics management (Ghanem et al., 2018; Seppänen and Peltokorpi, 2016; Tetik et al., 2020), among other areas. In addition to finding individual sub-solutions, research has also been conducted to establish a more holistic picture of the situation (O'Reilly et al., 2005) and to integrate decentralized information in the CI (Kärkkäinen et al., 2019 ).

Despite the existence of these studies on sub-solutions, little empirical research has been made related to the requirements of SA in the CI. Research on the requirements of SA systems is, thus, important for several reasons. First, as in any system development, it is critical to identify key requirements in the early development stages, as deficiencies in their identification can lead to deficient SA system design and, in the worst case, SA system failures (Chen and Zeng, 2006). Second, the identification of user needs can help in identifying SA system requirements. Finally, understanding the requirements of SA systems can help members of the organization better shape future development strategies for SA.

The overall purpose of this paper is to identify the requirements of SA system development in the CI. We will use the literature research and case study approaches to explore these requirements. By observing these cases in the early development phase of SA systems, we aim to contribute to identifying areas for improvement in the further development of SA systems in the CI.

2. Literature review

The first phase of this research focused on exploring the theory of SA as well as the conceptual frameworks and models rooted from this theory. This part of the study was based on a literature review. After reviewing the definitions of SA, we identified journals that have published articles with the keywords “situational awareness.” Papers with these specific terms were further limited to subject areas in sectors (e.g. “cyber security”). From the articles we reviewed in the literature review, we classified the basic structures underlying the theory and the similarities/differences of the models used in different fields from the original model.

2.1 Situational awareness models

The most commonly used SA model is Endsley's (1995) three-level model of SA: (1) perception of the current situation, (2) comprehension of the current situation and (3) projections of the future. In Endsley's model, the terms “decision-making,” “action” and “feedback loop” are separate functions at the outer perimeter of the model, although interconnections of SA and decision-making are evident. As Endsley and Garland (2000) argued, “SA is a precursor of decision making.” While the SA model has spread in other industries, the term “alert” has also been added to some frameworks, originating from cyber security (Sharma and Kate, 2014) and military (Salerno et al., 2004).

For teamwork environments, Nofi (2000) proposed the term “shared situational awareness” (SSA). Since work in construction projects is also mainly the effort of teams and groups (Dulaimi et al., 2007), the use of SSA can tie together the SA theory and practice. For SA to be truly beneficial, teams and groups must have this shared and unified situational picture at every level of the project organization (Franz et al., 2017). Endsley's (1995) model is the primary basis for SA models in other fields, and while the terms used in sectoral models differ, the fundamental structure ofEndsley's (1995) model underlies and connects the sectoral models. This link can be seen from the properties of the SA models found in different industries (Table 1).

The structure of Endsley's model is repeated in the sectoral models, despite the use of different naming conventions (Janlov et al., 2005; Livnat et al., 2005; Barford et al., 2010; Jajodia et al., 2011; Boyle et al., 2012; Kim et al., 2012; Albanese and Jajodia, 2014; Baumgartner et al., 2014; Sharma and Kate, 2014; Souza et al., 2015; Mykich and Burov, 2017; Alavi et al., 2018). Repetitive structures may be generalized to the state of the environment, the perception of elements in the current situation, comprehension of the current situation, the projection of future status, alerts, decision-making, the performance of actions and feedback loops.

Reporting seems to be neglected in the current SA models, however, with only Alcaraz and Lopez (2013) mentioning reporting as part of SA. In most models, decision-making and SA are differentiated (Gutwin and Greenberg, 2002; Shaker, 2002; Barford et al., 2010; MacEachren et al., 2011; Alcaraz and Lopez, 2013; Sharma and Kate, 2014; Lenders et al., 2015; Livnat et al., 2005; Lundberg, 2015).

2.2 Review of partial situational awareness solutions in the construction sector

A relatively small body of literature focuses on SA in the construction sector. The research on these partial solutions may be divided into three recurring themes: (1) safety, (2) situation information of machines and equipment and (3) the utilization of BIM. Table 2 summarizes various authors' evaluations of the advantages/disadvantages of each partial solution, as well as our evaluation of where previous researchers focused on the construction project's life cycle and at which SA level the partial solution was examined. The evaluation is focused only on features relevant to SA. SA levels according to Endsley's (1995) model were identified as follows: Level 0 (data collection only), Level 1 (current situation perception), Level 2 (current situation comprehension) and Level 3 (future projections). Table 2 lists the different labels.

Some articles (“Other” in Table 2) did not fit into the three main categories of safety, machinery/equipment status information and BIM. These articles were more comprehensive than other reported solutions and included more SA levels. O'Reilly et al. (2005) and Yang et al. (2018) addressed the extremes, design and operation phases of the project life cycle, while Kärkkäinen et al. (2019) created a holistic model for both design and construction, although these more comprehensive systems were either based on local solutions or were conceptual models that lacked validation. Previous studies have not investigated the requirements needed in SA system development in the CI, however.

3. Research methods

The purpose of this study was to explore the requirements of the SA systems used in the CI. An exploratory multiple case study approach was selected to gain an understanding of how system developers have planned SA systems. The case study approach also allowed us to discover the motives and objectives behind the development effort and to compare them with theoretical SA models. Since there are no public databases and no possibility to take a random sample from SA developers, we selected the cases based on our expectations about their information content (Flyvbjerg, 2006) and their novelty in the CI market. Our sample consisted of five organizations known by the research team who had developed SA systems for their own or consulting use and therefore had first-hand experience in the development and use of SA systems. Due to the novelty of research objects, the selection process for the case studies was started by identifying the users and developers of SA systems in industry seminars and by exchanging information among researchers. In addition, the literature research phase provided additional information about sub-solutions and their developers. In the second phase, the case solution providers that came to the researchers' attention were contacted and asked for consent to participate in the study.

3.1 Data sources

Our primary data source consisted of semi-structured interviews, enriched by the data provided by the case companies, as well as public seminar presentations and introductory videos on the internet, including social media. In general, the use of varying data sources allows for triangulation between the sources and increases the validity of an analysis (Yin, 2018). Table 3 summarizes the case project characteristics and the information we collected about the case projects during the study. Interviews were the first step in data collection. After interviews, further data were provided by the case companies, and we also collected any publicly available material about the case.

The interviews served as a framework for data collection, enriched with documentation from the companies as well as data collected from public sources. We conducted five interviews, in which we asked open-ended questions of seven interviewees at the beginning of the interviews and more structured questions at the end. In this way, we sought to minimize our questions from influencing the interviewees' unrestricted views of their own SA systems as well as the systems' features, requirements and needs. Our informants (three executives, one chief digital officer, one chief technical officer, one technology manager and one SA system manager) were all familiar with their respective companies' efforts to develop an SA system.

There are several sources of requirements in system development (Chen and Zeng, 2006; Bahill and Dean, 1999), and we established our interviews based on these generic definitions. Bahill and Dean (1999) stated that requirements should include four characteristics: (1) the ultimate need of the customer (e.g. a customer wants nails from a hardware retailer, but in reality, the customer's ultimate need is to attach two pieces of wood together and glue could work as well or better for the customer's need) (2) the essential requirements of the system and from which all other requirements arise to create value and benefit for its users (e.g. pieces of wood must remain attached to each other both in indoor and outdoor conditions at least five years without any maintenance), (3) a common understanding of the desired features of the system (e.g. a common understanding is reached of what is really desired from joining pieces of wood) and (4) what the system should fundamentally do. The requirements should indicate what the system needs to do; however, they should not specify how the system does it (Bahill and Dean, 1999). For the interviews, we divided these main characteristics into five specific themes: (1) key requirements, (2) key properties, (3) the technical and functional solutions of SA system, (4) identified problems and (5) identified development needs. As we set these themes to seek key requirements for a coherent SA in the CI, we also developed our interview questions for identifying systemic weaknesses and improvement areas in SA systems.

The interview research questions were based on established structure and approaches reported in the literature on requirements gathering, analysis and benchmarking (de Marrais and Lapan, 2003; Jacob and Furgerson, 2012; Maritan, 2015). The interviews consisted of three phases. First, during the open-ended part of the interview, we asked about the background of the informant and the advantages, features, absolute requirements, problems and areas for development of the SA system. In this context, all interviewees openly talked about the history of the system and its objectives for their company. In the second, semi-structured section of the interview, informants were asked to name the key requirements of their own SA system and rate their importance on a scale of 1 (minor), 3 (important) or 9 (very important). Interviewees were then asked to indicate what technical and operational solutions had been developed for the above requirements and what kinds of challenges they had faced. In the third, structured part of the interview, the interviewees were asked to respond to a table of requirements for the SA system prepared in advance by the researchers. The interviews lasted 45–90 min and were recorded on a completed interview form at the time of the interview. The data collected in the interviews were combined into an Excel spreadsheet where the responses could be compared. The semi-structured and structured interview questions are presented in Table 4.

We took several steps to ensure the validity of the information (Yin, 2018). First, we constructed the interviews in such a way that we avoided asking introductory and speculative questions with the open-ended questions we asked in the early stages of the interviews. Second, during the interviews, we asked our own structured questions at the end of the interview to avoid guiding the participants. Third, we gathered data from the interviewees and from publicly available data sources such as seminar presentations and video presentations from event web pages, company web pages and social media. Fourth, we triangulated the interview data with other data sources and our visual observations in the interview situation in the control room. In the interview situation, we also emphasized the anonymous publication of the results, thereby encouraging the interviewees to respond openly and honestly.

3.2 Data analysis

We started the data analysis by combining and tabulating the interview data. We first focused on topics we had identified in the literature review (and to which we had also found answers in the open-ended section of the interviews) and looked for similarities and differences between the cases and the literature. Data from the structured part of the interviews were compiled and grouped into a table for comparison. From the answers given on the numerical scale, the mean and SD were calculated and grouped in order of value. The open-ended part of the interviews was grouped into categories by theme for comparison. We then went through the responses as well as the other data sources we had collected and sought to identify the key properties of SA we had identified from the literature review. After completing the data analysis, we developed and refined our preliminary conclusions from our findings and compared them between the cases.

Our primary target for this study was the question, “What is required to develop SA systems in the CI?” To understand this question better, we needed to study SA theories, partial solutions in the CI and existing development cases. We sought to find similarities and differences between the cases, and we categorized and sorted out the most important requirements from the interviews. Our second target was to identify systemic weaknesses in already-developed SA systems and to identify areas for improvement in the further development of SA systems in the CI. Hence, we first evaluated the level of SA in our cases. In evaluating the level of the SA, we also used interviews, observations and other material to help us deduce which elements of the SA theory were included in the systems, what was missing and which areas from the SA theory the system developers had identified as future development themes and which aspects had been neglected.

4. Case study descriptions

For all case projects, we collected magazine articles from online technical magazines in the field and social media; we also found seminar presentations from Cases C and E and videotaped presentations for Cases A and E through an online search. This information, similarly to the documentation we received from the companies, was initially created primarily for marketing purposes, although the interview results were in line with this commercial material. While the case projects were from a geographically limited area, the needs, objectives and implementation modalities varied widely.

4.1 Case A

Case A is a Finnish start-up company focused on SA software development that offers SA services for construction sites. The company calls these services “digital engineer services.” The term “digital engineer” refers to the person who collects data from the site (by drones and 360-degree camera sets in this case); the data are analyzed at the company's premises, from where it is distributed to users through a Web-based interface. The core function of the system is to provide a timestamped snapshot of the various phases of a construction project made from 360-degree cameras. The users of the system are able to follow the progress on the site chronologically and also to make their own visual observations. The service includes editing the information in such a way that it can be used in decision-making.

The system has several different functionalities, from schedule management to cleanliness measurements, which can be used as a single unit or as separate parts. The service also includes various sensors and positioning devices. The system was in the operating phase, and the company had several clients in Finland and internationally. We made three visits to the company's physical space (the “control room”), where engineers centrally analyzed all the data they had collected from various sites. The company actively developed artificial intelligence (AI) as part of its software. We obtained system and process documentation from the company, as well as publicly available video presentations and other data. The material included the SA system's general specification, service description, preliminary delivery terms and a data protection agreement related to pan-European legislation. The company's motivation seemed to be to develop an SA system to integrate new technologies, particularly AI, into the construction production process.

4.2 Case B

Case B is a Finnish-owned company specializing in design and project management (mainly in Finland) that developed its system primarily to support its own business. According to the developers, however, the goal is to sell the services to customers as well. The company had also built a physical space on the company's premises and called this space the “command centre.” The company had developed this physical space in collaboration with a technology partner, whose special expertise was in computer-aided virtual environments (CAVE). The company mainly focuses on visualizing the results of data analysis to support SA system users' decision-making. The company had also developed a mobile application for the site that could be used to collect situation data from the field. The functionality of the system is based on the processing of information collected from the construction site by a mobile device.

The system includes various filtering functionalities that can be used to classify and present information for different purposes. The most important parts of the system are the monitoring of progress and the documentation of observations and inspections at the site. According to the company, the software can also be used to record and monitor decision-making and visualization, mainly with the help of commercial business intelligence software. Data collection is done manually, and the data are collected by site personnel. The data analysis was not centralized, and the system users were responsible for editing the data. The system did not include sensors or positioning systems, but data transfer from these systems over an open interface would also be possible.

As background material, Case B provided a general brochure on the SA system and examples of SA screens. The company's motivation was to improve the transparency of its own design and project operations while simultaneously developing an SA system suitable for customer projects that could also have wider commercial potential.

4.3 Case C

Case C is a major municipal infrastructure project that built a physical space for the use of project management to improve transparency in the outputs of a complex project; SA information was also widely shared with company stakeholders. In the model the company developed, SA was based on traditional schedule management and key performance indicators such as earned value, cash flow analysis and the monitoring of progress versus plans.

Case C provided project SA reports and photos of the physical space as well as a process description of the SA system. The company used partly in-house know-how, and partly third-party technology, to automate data collection. The system's data collection was carried out by a separate team, which was responsible for monitoring the collection of progress reporting on the various aspects of the project. The data analysis was done manually by creating weekly SA views for use by the project team and monthly for the company's board of directors. The SA was in digital format, but reporting took place after weekly meetings via email. The forecast was prepared using contract-specific forecast data provided by the project contractors. The system did not use any sensor or location data. The main motivation for the case to build the SA system consisted of delays in the previous phase of the project. The SA system aimed to prevent similar delays in the second phase.

4.4 Case D

Case D is a Finnish-owned engineering company with operations in Scandinavia and the Baltic region that developed an SA system to improve design information flow between different stakeholders. During the interview phase, the development work was focused on improving the information flow between the client and the designers. The company decided to build an SA system on top of its existing location-based technology, which is related to the company's business in infrastructure construction and master planning; this scenario explains why the company's digital platform is an electronic map enriched with information. When customers use the platform, their municipality gains comprehensive, up-to-date SA of population data related to the municipality's vacant plots, for example.

The company is currently developing more interaction between its own designers and various stakeholders. It aims to build its system in two levels, with the operational perspective as the first perspective and the strategic perspective as the second, depending on stakeholder needs. At the time of the interview, however, information was not obtained from the interviewee about the system's data collection and how much it was to be automated, because the system was at such an early stage of development. Instead, the material obtained after the interview revealed that drone usage is one of the data collection methods the company plans to use. The interview also did not reveal any information related to further processing of the data the company had collected, or its management. The use of sensors was not mentioned in the interview (although location-based systems were used as the basis of the system), but the interviewee did not directly reveal the development work related to the positioning technology. Case D did not provide any detailed documentation of its systems. The key motivation for the development appeared to be to streamline the firm's own design activities and to improve efficiency in the design work itself. The company does not plan to develop a physical space for SA.

4.5 Case E

Case E is a Swedish-owned international engineering and construction management company whose local subsidiary was developing an SA system for its own needs in Finland. These needs mainly consisted of the necessity for company management and supervisors to see in real time the progress of company-led design and project management projects. The interview clearly highlighted the company's goal of doing away with several different Excel spreadsheets and to obtain unified information about one's own operations that would be available through one system and open to all supervisors. As with Case D, Case E was at a very early stage in its development of the system, and the interviewee did not reveal how the system's data collection had been designed or how much of it could be automated and what part humans would play in the data collection.

The interview did not reveal the details of the further processing of the data the company had collected or its organization, nor did the utilization of sensors or positioning come up in any way in the interview. The interviewee did reveal, however, that the company intended to use an enterprise resource planning (ERP) system and financial management software for data collection, although this was not reflected in the additional material obtained from the case from public sources. As motivation, the interviewee stated that the goal was to improve productivity and to generate value for customers' projects and thus also for the company. The company was planning a digital SA system, although additional material was not provided to the researchers.

5. Results

Table 5 shows which SA levels were implemented in the different case studies' SA systems, using the same classification we used to compare the different SA models from the literature (Table 1). Interestingly, three of the case studies (A, C and E) had attempted to address all three SA levels by evaluating the state of the environment, comprehending the current situation and projecting to the future. This finding indicates that building a coherent and comprehensive SA system for construction projects is possible. All the case studies we analyzed lacked one or more features of full SA systems; for example, alerts and action performance were associated with just two SA systems. Despite the incompleteness and gaps in systems, the cases mainly followed the SA theory, and we observed no fundamental deviations.

We found that the developers clearly differed in their data collection methods. Case A was obviously at the forefront of introducing new technology and utilized drones, helmet cameras and various sensors to collect situational data. Case B collected data mainly on mobile phones. Case C used the Web application it had developed to collect progress data from the field, but in other respects, other situational information was manually collected from different systems, without integration. Case D, whose system was still under development, planned to collect SA data from the BIM model as well as drone data from the site. Case E, which was also in the development phase, was also planning to utilize BIM data as well as the company's ERP and financial management systems to create an SA system. To illustrate in more detail the SA system inputs, outputs and connections to SA levels, Table 6 provides a summary of these SA system features.

From the structured part of the interviews, the main requirements were identified out of 21 different pre-set requirements. The importance of the requirements was emphasized by the three-point scale used in the responses (Franceschini and Rupil, 1999; Maritan, 2015). The key findings included requirements related to customizability and reliability, where all cases had the highest ratings by all case study participants (mean 9.0, SD [SD] 0.0). Other important requirements pertained to the SA system's social applicability, technical lifespan, ease of implementation, ease of use and data security. The developers gave the lowest ratings to economic aspects and to the data quality (mean 1.4, SD 0.9) and technical quality (mean 1.0, SD 0.0) of the system. To better understand systemic weaknesses and areas for improvement in SA systems, we combined various challenges raised by the interviewees by using case-specific information from the open-ended part of the interviews, associated requirements from the structured part of the interviews and specific solutions and connections to SA levels, as shown in Table 7.

As a summary, all five cases revealed structures and requirements that were largely in line with the SA theory. The digitization of data collection was also considered by all, although manual steps were clearly visible in every system. Identified yet unresolved challenges included data quality variation, utilization of legacy data, overlaps with existing systems, avoidance of human misunderstandings and system decentralization. For future status projection (SA Level 3), the developers used very traditional methods (the prediction of schedule and cost being the main part), although sensor technology was used in one case. This dimension of the SA was the least developed part of the cases we studied.

The interviewees' responses varied regarding the significance of BIM: during the structured part of the interviews, all but Case A (which assigned a grade of 6) gave a grade of 3 (mean 4.2, SD 2.7). Only Case A raised BIM on their own initiative in the open interview section, while for the other interviewees, BIM only came up obliquely in the structured interview, during the review of the list of requirements prepared in advance by the researchers.

6. Discussion

In this study, we have analyzed what requirements for SA systems are needed in the CI. We have also explored what SA models exist in other industries and can be utilized to develop CI-based SA systems. Our research has shown that, based on the case studies, the development of SA systems in the CI mainly consists of meeting different company-specific needs, rather than on systematic development based on ready-made frameworks and the SA theory. Although SA levels could be found in the developers' systems in our case studies, the developers did not seem to be aware of Sarter and Woods' (1991) original concept, which distinguishes the human perception of the situation from the actual state of the system. The development of systems instead seemed to be based on traditional project models, in which the role of the individual as the creator and interpreter of an SA system is still significant, despite the limits of human cognitive ability. The case studies showed how digital aids have been introduced in data collection, but a large proportion of SA levels of perception and projection still occur manually.

Based on the interviews, the largest unresolved challenges in the development of SA systems are related to data quality. Upon our closer review of the results, we noted that this unresolved problem in SA systems is typical in the CI. For example, poor data quality (and its negative effects on projects) is a well-known phenomenon in the CI (Rivas et al., 2011; Wambeke et al., 2011; Westin and Sein, 2014). The results we obtained are therefore somewhat worrying. The developers of SA systems recognize a general problem in the CI, but so far, they have only been able to solve the problem from a technological point of view. The responses emphasized platform choice and reliable test practices for coding but also pointed to human intervention (e.g., digital engineering services and project managers' roles as “status detectors” and “explanators” of the data) and instructions for responsible persons. At this stage, the development of SA systems, thus, seems to rely on the competence of individuals, which is contrary to the general principles of the SA theory. The theory assumes that an individual's ability in a dynamic environment is limited, and that SA systems' main function is to support individuals' decision-making (Sarter and Woods, 1991; Endsley, 1995).

In the SA systems' data collection, only part of the data was collected purely digitally. For example, so far, 360-degree images and drone data are mere raw data that are valid for processing in all systems only by a human being. Only one actor had tried to develop AI for data analysis, while in other systems, information was both collected and interpreted by humans. Based on a review of the literature, this is a fundamental difference from other disciplines and from the SA theory.

While the development of SA systems opens up novel opportunities for the exploitation of BIM (Garcia et al., 2021), this study has shown that the use of BIM is not generally considered an essential part of as-yet-developed SA systems in the CI, even for those developed by engineering companies. Given that design errors and design delays are both significant issues in construction disputes (Kumaraswamy, 1997), and that the use of BIM is key in modern construction projects (Smith, 2014; Sacks et al., 2018), we find it surprising that SA system developers have not yet fully utilized the potential of BIM when developing their systems. The development of SA systems without considering the possibilities that BIM brings and the fact that BIM is a real-time database that can produce SA of the design situation will end up with SA systems that can manage only part of the project. A situation in which one essential part of the project is missing does not lead to a better overall picture of construction projects (Sacks et al., 2020). This was another remarkable shortcoming of the SA system development found in our case studies.

We, therefore, encourage scholars and practitioners who are developing and studying SA systems in the CI to focus on two key findings of this study: first, how SA theories and frameworks, in particular the limited nature of human capability in dynamic environments, can be considered in the development of SA systems in the CI. And second, we need further research to focus on how the information found in BIM may be better utilized as an integral part of the SA model in project activities. As our literature review has shown, BIM-based sub-solutions have been studied, through which functional entities could be developed to form a holistic situational picture (Fang et al., 2016; Niu et al., 2016; Reinbold et al., 2019). Integrating the development of BIM into the SA system requires an automatic “sensing system” of design (Hooper, 2015). By the term “sensing system,” in this context we mean an automatic design situation recorder that could be integrated into an SA system (Sacks et al., 2020; Garcia et al., 2021). The development of such a sensing system, together with SA systems, should also decrease human intervention and errors between the levels of SA.

7. Conclusion

To summarize this study's contribution, our aim was to analyze which key requirements are needed for SA systems in the CI. We reviewed SA models in other industries and identified partial CI solutions from the literature. The concept of SA has not been sufficiently studied in the CI. This study's findings have revealed levels of SA systems, key requirements of SA systems and the needs of SA development in the CI. The case study approach we used has provided insights into how well the SA systems developed by CI actors are aligned with the SA theory and what the key requirements for SA are in the CI.

Based on our research, we argue that the conceptual frameworks developed in other fields are insufficiently used in the development of SA systems in the CI. We did observe SA levels in the SA systems under development, although the developers mainly focused on the first level of SA by collecting data digitally and then combining the data and presenting it visually. In SA systems, however, the mere collection and presentation of data are not enough; the system must also include the second and third levels of SA (having an understanding of and projecting SA, respectively) for the system to be called an SA system. Based on the case studies and sub-solutions we reviewed, this is the most significant weakness in first-generation SA systems in the CI, especially since the second and third layers are currently produced mainly by individuals. Another significant shortcoming related to the inadequate use of the SA theory in the development of SA systems is the disregard for the original purpose of SA in development work. The SA systems developed by the case study companies allowed significant human involvement and interaction between the SA levels, which cannot lead to the achievement of the original SA theory's objectives.

The study's second important contribution is that even though BIM is widely perceived as an important tool in the industry, both in the design and implementation phases, BIM was hardly utilized in the development of the case studies' SA systems. We clearly need further research that focuses on the utilization of information in BIM as part of the SA model. We have shown in this study that partial solutions have already been studied, but wider integration of partial solutions requires more information about the design situation collected through automation.

As a practical contribution, based on our findings, SA system developers and scholars should think about our findings related to the shortcomings of SA system development. By learning from these shortcomings in SA theory utilization, developers can correct systemic deficiencies in their systems before they are deployed on a larger scale in the CI. We also hope that the clear shortcomings in the utilization of BIM in the early development of SA systems will improve after this study, and that BIM can fulfil its role in the SA of the design phase of construction projects.

Finally, our study does have a few limitations. One major limitation is the small number of cases and their geographical homogeneity. Still, in science, sometimes, a single sample has yielded significant progress, and we believe our exploration of our five case studies will pave the way for the development of new and improved research questions (Siggelkow, 2007). The second limitation is the small number of interviewees, which could lead to bias (Eisenhardt and Graebner, 2007). We do believe, however, that the different focuses and backgrounds of the SA system developers, as well as the different needs of system development and the data triangulation we used, will reduce this bias.

Table 1

SA model properties from other industries

Code	Status	Perception	Comprehension	Projection	Alerts	Decisions	Actions	Feedback loop	Other	Source
C2	X		X	X						Tianfield (2016)
C3	X	X				X	X			Lenders et al. (2015)
C4	X	X	X	X	X	X		X		Sharma and Kate (2014)
E1	X	X	X							Chen et al. (2011)
E2	X	X	X	X						Alavi et al. (2018)
E4	X	X	X	X						Kim et al. (2012)
H1	X	X	X	X						Boyle et al. (2012)
H2	X		X				X	X		Fore and Sculli (2013)
H3	X	X	X	X						Souza et al. (2015)
H4	X		X	X						Singh et al. (2012)
H5	X		X	X						Schulz et al. (2017)
M1	X		X		X					Salerno et al. (2004)
M2	X	X	X	X						Jajodia et al. (2011)
M3	X	X	X	X		X	X	X		Barford et al. (2010)
M4	X						X			Skopik et al. (2012)
M5	X	X	X	X						Janlov et al. (2005)
M8	X	X	X	X						Albanese and Jajodia (2014)
M9	X	X	X							Björkbom et al. (2013)
M10	X	X	X							Chmielewski (2009)
M12	X	X	X							Koskinen-Kannisto (2013)
M14	X	X					X	X	X	Alcaraz and Lopez (2013)
N1	X	X	X							Huang et al. (2015)
N2	X	X	X			X				MacEachren et al. (2011)
N3	X	X	X							Timonen et al. (2014)
P3	X		X		X					Ghimire et al. (2017)
T3	X	X	X	X		X	X	X		Endsley (1995)
T4	X		X			X	X			Endsley and Garland (2000)
T5	X			X		X	X	X		Lundberg (2015)
T11	X	X	X	X			X			Baumgartner et al. (2014)
W5	X	X	X			X				Shaker (2002)
W6	X	X	X							Daum (2006)
D57	X	X	X			X	X	X		Gutwin and Greenberg (2002)
D59	X	X	X	X						Mykich and Burov (2017)
D62	X		X		X					Li (2015)
D63	X						X			Yang, et al. (2018)
D64	X	X	X	X		X				Livnat et al. (2005)
Total	36	25	31	17	4	10	11	7	1

Note(s): C = cyber security, E = energy, H = health and safety, M = military and defense, N = natural disasters, P = project management, T = traffic control, W = “war rooms”, D = other. (The term “war room” is a space where project teams or management can view and discuss SA based on collected data (Aasland and Blankenburg, 2012))

Table 2

Advantages/disadvantages of partial SA solutions in the CI

Partial solution	Advantages/disadvantages	Construction project phase	SA level	Source
Safety (8 articles)
Avoidance of fall-related accidents	+ Improved worker SA + Use of digital images, animation, video – No results on impacts	Construction	0	Lonsdale (2004)
Distributed surveillance and coordinated movements of robots	+ Distributed SA database – Errors in location and collisions of robots	Construction	0 and 1	Hsieh et al. (2007)
Construction crew's SA	+ Improved construction crew SA – No results on impacts	Construction	0 and 1	Mitropoulos and Memarian (2012)
Safety training by virtual reality (VR)	+ Scenarios – No clear advantage of site safety in general	Construction	–	Sacks et al. (2013)
Hazard recognition and communication model	+ Improved team SA – Only six sites observed	Construction	0	Albert and Hallowell (2014)
Eye-tracking technology measuring workers' SA	+ Identification of workers with low SA + Pinpointing of opportunities to provide proactive training for workers – Focus on individual SA	Construction	0	Hasanzadeh et al. (2016)
Hazard recognition via augmented reality (AR)	+ Factors that positively influenced workers highlighted – Complete SA model not used	Construction	0 and 1	Bhandari et al. (2018)
VR-based safety training and improved SA	+ Suitable VR/AR systems available – VR/AR safety systems in different projects or work tasks not considered	Construction	3	Li et al. (2018)
Equipment and machines (3 articles)
Global positioning system (GPS)-based positioning system of construction equipment	+ Collision detection + Wireless real-time position data of equipment – Variety of methods used for data transfer – Limited data bandwidth – Poor signal reliability	Construction	0 and 1	Oloufa et al. (2003)
Laser scanner-based tower crane operation	+ Blind-spot minimizing – Blind-spot analysis and site-layout evaluation is offline and not fully automated – Manual point cloud noise-removal process – Complexity in handling data sets	Construction	1 and 2	Cheng and Teizer (2014)
Reduced struck-by safety hazards	+ Novel spatiotemporal and network-based models for struck-by safety – No real construction sites – GPS measurement errors – Unsuitable for wear by workers	Construction	0, 1, 2	Wang (2018)
BIM functionality (3 articles)
BIM- and cloud-enabled radio frequency identification (RFID) localization system	+ Cloud server data enables real-time remote monitoring and collaboration – Limited RFID network coverage – Quick changes in site conditions	Construction	0	Fang et al. (2016)
Integration of indoor positioning system and BIM	+ Resource location, availability and production rates – Concept not validated	Construction	0, 1, 2	Reinbold et al. (2019)
Smart construction objects and ability to interact on- or off-site	+ BIM enhancement + Improved information sharing/exchange – Concept not validated	Design and construction	0, 1, 2	Niu et al. (2016)
Other (3 articles)
Command console	+ Work progress visualization + Conflicts visualization between activities + Shared SA – Long development time of SA systems – Local solution	Design	0, 1, 2, 3	O'Reilly et al. (2005)
Intelligent management and service on university campuses	+ Multi-network convergence – Concept not validated	Operational	0, 1, 2, 3	Yang et al. (2018)
Conceptual model of construction information management for SA	+ Conceptual model of SA in operations management – Concept not validated	Design and construction	0, 1, 2	Kärkkäinen et al. (2019)

Table 3

Case study data sources

Case	Main objective for SA	Actor type	Phase of SA system development	Evidence sources
A	Production management	Service provider and software developer	In operation	Three control room visits System/process documentation The company's introductory videos One interviewee (chief executive officer (CEO)) Articles from industry magazines and social media
B	Project management; design management	Engineering and construction management company	In operation	Two control room visits; two virtual meetings Partial system/process documentation Two interviewees (CEO and chief technical officer (CTO)) The company's introductory videos Articles from industry magazines and social media
C	Project management	Large infrastructure project	In operation	Several control room visits System and process documentation The company's public seminar presentations One interviewee (SA system manager) Articles from industry magazines and social media
D	Design management	Engineering company	Under development	The company's public seminar presentations One interviewee (chief digital officer (CDO)) Articles from industry magazines and social media
E	Design management	Engineering and construction management company	Piloting phase	The company's public seminar presentations Two interviewees (CEO and technology manager)

Table 4

Semi-structured and structured interview questions

Interview questions	Context	Part
Q1: What are the best properties of the SA system?	Advantages	Semi-structured
Q2: What are the most unfavorable properties of the SA system?	Problems	Semi-structured
Q3: What are the absolute requirements for the SA system related to your work?	Absolute requirements	Semi-structured
Q4: What are the key properties for the SA system related to your work?	Features	Semi-structured
Q5: What problems have been encountered in the SA system during its operation?	Problems	Semi-structured
Q6: What features could be developed in your SA system?	Areas for development	Semi-structured
Q7: What requirements the SA system should meet?	Features	Semi-structured
Q8: How would you rate the requirements for the SA system (list of requirements)?	Key requirements	Structured
Q9: What are the technical and functional solutions for the Q7 and Q8 requirements in your SA system?	Features	Semi-structured

Table 5

Case studies: level of SA in already-developed systems

SA level	Case A	Case B	Case C	Case D	Case E
SA Level 0 (data collection)	X	X	X	X	X
SA Level 1 (environment state)	X	X	X	X	X
SA Level 2 (current situation comprehension)	X	X	X	X	X
SA Level 3 (future status projections)	X		X		X
Alerts	X	X
Decision-making			X	X	X
Action performance	X				X
Feedback loop	X		X	X	X

Table 6

Case studies: list of inputs and outputs of the SA systems

Case	Input (SA Level 0)	Output	Output SA level
A	360-degree video cameras with positioning from site visits Drone video/images with positioning from site visits Fixed cameras from site Concrete sensors from site Indoor air sensors from site Positioning tags from site Client applications through the application programming interface (API) BIM systems through the API Design documentation through the API Schedule progress data through the API	(1) Visualized dashboards	1, 2
		(2) 3D model with positioning	1, 2
		(3) Still images with positioning	1, 2
		(4) Live camera feed	1, 2
		(5) Visualized resource location	1, 2
		(6) Visualized condition information	1, 2
		(7) Safety report or safety calibration report	1, 2
		(8) Quality status reports	1, 2
		(9) Conditions status reports	1, 2
		(10) Concrete drying and strengthening reports and forecast	1, 2, 3
		(11) Technical completion rate reports	1, 2
		(12) Productivity reports	1, 2
		(13) Schedule visualization	1, 2, 3
B	Photos from the site from mobile devices Supervisor observations recorded on a mobile device	(1) Visualized dashboards by business intelligence tools	1, 2
		(2) Still images	1, 2
		(3) Task lists with verified processing chains	1, 2
		(4) Safety reports	1, 2
		(5) Quality status reports	1, 2
C	Schedule progress data from Web application Cost progress data from Web application Risk data from risk database Quality, health and safety data from site measurements Collaboration data from collaboration platform	(1) Visualized dashboards	1, 2
		(2) Safety reports	1, 2
		(3) Quality, health and safety status reports	1, 2
		(4) Collaboration reports	1, 2
		(5) Key performance indexes	1, 2
		(6) Cost and schedule risk reports (top 3)	1, 2
		(7) Schedule visualization	1, 2, 3
D	BIM data Photogrammetric models from site visits Project documentation through the API	(1) Data sharing platform	1
		(2) Design status information	1, 2
		(3) Cost, schedule and risk reports	1, 2
E	Project data from ERP system Financial data from financial management systems BIM data	(1) Design situation reports	1, 2
		(2) Visualized dashboards by business intelligence tools	1, 2
		(3) BIM visualizations	1, 2
		(4) Resource reports	1, 2
		(5) Key performance indexes	1, 2
		(6) Profit reports	1, 2

Table 7

Interview results: challenges, solutions and connection to SA levels and requirements

Challenges	Specific solutions	Connection to requirement	Connection to SA level	Case
Unreliable data	Platform choice; reliable test practices; digital engineering service and instructions for responsible persons	Data quality (minor requirement)	0	B, C
Data variation	No solutions mentioned	Data quality (minor requirement)	0	B
Insignificant and useless data	Project managers determine statuses and provide explanations	Data quality (minor requirement)	0, 1	B
Preceding project data cannot be utilized	No solutions mentioned	Data quality (minor requirement)	0	E
Resistance to change	Process for communicating the issue to customers; client education; open, transparent communication; user surveys	Social applicability (important requirement)	2	A, B
Misuse of tracking related to individuals	No solutions mentioned	Social applicability (important requirement)	2, 3	E
Failure to follow instructions	No solutions mentioned	Social applicability (important requirement) Ease of use (important requirement) Instructions (minor requirement)	1, 2	E
Problems in implementation	Encouragement; user rights without extra cost; timestamp follow-up	Implementation (important requirement)	0, 1, 2, 3	B, E
Overlap with the traditional system	No solutions mentioned	Implementation (important requirement)	0, 1, 2, 3	A, B
Difficulties in using	Simple navigation; short user manual; logical interfaces; project-specific licenses; use of portal/web page data; use of MS Office software; data displayed in a separate situation/control room; human effort to ensure that data are in an easily accessible format; use of touchscreens	Ease of use (important requirement)	2, 3	D, E
Misunderstanding of system indicators	No solutions mentioned	Ease of use (important requirement) Visuality (important requirement)	2	E
Data security	Use of cloud services; internal security provider; standalone computers that can be isolated from the internet if needed, with normal firewalls	Data security (important requirement)	0	A
Decentralized solutions	No solutions mentioned	No connection to the requirements	0	D