ECOSYSTEM INTEROPERABILITY FOR THE ARCHITECTURE, ENGINEERING, CONSTRUCTION & OPERATIONS (AECO) SECTOR

SUMMARY : Substandard performance between information systems and applications remains a problem for the Architecture, Engineering, Construction, and Operations (AECO) sector leading to significant economic, social and environmental costs. The sector suffers from poor interoperability because it lacks a holistic ecosystem for exchanging data and information. Through qualitative research involving AECO sector industry partners’ views and opinions, this research extends understanding of issues which affect ecosystem interoperability in the AECO sector. Research questions guided a literature review, survey, semi-structured interview, focus group meeting, and interpretation of the results. The authors believe that incorporating AECO sector industry partners' views is essential for meaningful proposals to emerge. Open questions asked of industry partners received candid responses and confirmed key issues including: the need for the Industry Foundation Class (IFC) to be fully interoperable; the side effects and impacts of vendor lock-in; integration problems caused by multiple Common Data Environments (CDEs); handover data and information challenges; the impacts of poor interoperability on sustainable development. Through engagement with industry this research offers better understanding of interoperability challenges in the AECO sector and has generated more meaningful actions and solutions capable of improving the sector’s data and information ecosystem.


INTRODUCTION 1.1 Problem
Almost 30 years ago in 1994 the incipient International Alliance for Interoperability (IAI) heralded 'The End of Babel', with a promotional video presented by James Burke (IAI, 1994), promising that a new common language the Industry Foundation Class (IFC) would bring interoperability to the architecture, engineering, construction and operations (AECO) sector, and an end to poor communication between vendors' Computer Aided Design (CAD) products.The economic cost of poor interoperability for the AECO sector in the U.S., was estimated at US$15.8 billions per annum (Gallaher et al., 2004), due to manual rework, re-entering of data, delay costs caused by downtime, bottlenecks and other issues.These economic cost issues range across a building's entire lifecycle.We hypothesise that inevitably the costs extend to impact society and the environment.

Significance
The paper contributes to the resolution of interoperability issues in the AECO sector which challenge the flow of reliable data and accurate information between domains, disciplines and across lifecycle stages.The results of this paper's research were gathered from engagement with industry partners following a survey and semi-structured interview around issues relevant to all stages of a building's lifecycle from design to construction, and from development to operation.This engagement provided better understanding of the complex nature of AECO's organisation and mode of working and led to meaningful proposals to improve ecosystem interoperability in the sector.

Research Questions
To improve our understanding of the challenges which affect ecosystem interoperability in the AECO sector and their impact on society and the environment we asked the following research questions, • RQ1 (Primary): What issues continue to affect interoperability in an AECO organisation?
• RQ2 (Secondary): Is sustainable development affected by interoperability issues?

Background & Contribution
In previous work the authors compared interoperability challenges in AECO and the Oil & Gas sectors (Doe et al., 2021).In both, though global and industry standards are being created, published, and used, fragmentation challenges interoperability of the information exchange ecosystem (Hooper, 2022).In our current research the focus is on the AECO sector and the unique traits which define organisation of its processes, as summarised by Beetz et al (2010), Here, one-of-a-kind artifacts are designed in a collaborative effort by nonrecurring, temporary and multi-disciplinary teams that are mainly composed of members of small and medium enterprises (SMEs).(Beetz et al., 2010) We have extended understanding of the sector and its interoperability challenges with qualitative research into industry partner views and opinions, and the solutions they have implemented to meet these challenges.Our research questions guided a literature review, survey, semi-structured interview and focus group discussions, and shaped our interpretation of the results.We believe this qualitative approach is essential for understanding the complexity of interrelationships and issues which affect interoperability in the AECO sector and plays an essential part in the formulation of meaningful solutions.
Interoperability research often focusses on technological problems thereby excluding the people trying to manage day-to-day workflows.Our research has focused on the people and the problems they face because, essentially interoperability is quite simple -as Patrick MacLeamy, former Chair, buildingSMART International (bSI) observed it's when, '…my computer understands completely what your computer program is saying' (Group, 2022a).

Limitations
We recognise limitations to the scope of our research.We have sought the views of two industry partners to better understand the AECO sector's ecosystem interoperability challenges.However, engagement with these industry partners developed one year prior to the qualitative approach that was taken.The partners themselves represent significant interfaces with the AECO sectors global information exchange ecosystem, while their multidisciplinary reach into operational and information exchange issues provided significant insights into interoperability challenges faced by AECO sector teams and individuals.

Section 2 -Literature and Standards
The research questions (RQs) guided the review of literature and standards.We aimed to extend understanding of the AECO sector's interoperability ecosystem with a review of standards, systems and servers, sustainability's relationship to interoperability, and prior research by the authors.

Section 3 -Results
This section reports on our understanding of interoperability challenges in the AECO sector following engagement with two industry partners, GHD and DBM Vircon.The timeframe was as follows: • 22.10.2022Survey online, 10 questions (Appendix A).

Survey
We asked ten open questions (Appendix A) guided by the research questions.The Survey responses were auto coded using NVivo then manually re-coded to identify preliminary themes that would guide engagement, while a hierarchy chart assisted visualisation.

Semi-Structured Interview
The ten questions also formed the structure for the Semi-Structured Interview, which examined in detail issues reported in the Survey.A transcript of the interview was auto coded by NVivo and manually re-coded to identify themes and sub-themes.These were then manually catalogued, and new codes created to keep similar themes together, while a hierarchy chart assisted visualisation.A concept map of the hierarchy of themes and sub-themes was manually created to explain relationships.This map guided analysis of themes and sub-themes which are reported alongside narrative by the researchers with quotations by industry partners depicting themes and issues raised.
Between the Semi-Structured Interview and the Focus Group Meeting we issued a Report to the industry partners which provided feedback with follow-up queries based on the Semi-Structured Interview.We examined challenges posed by the industry partners and made a proposal for a 'connected CDE' or 'the main CDE'.In this interim period between the Report and the Focus Group Meeting on 31/3/2023 we also gathered written feedback on the proposal from industry partners and from Léon van Berlo, Technical Director, bSI.Though the contents of the Report are confidential we can confirm some of the interim period feedback on the proposal.For example, bSI characterised the holistic nature of the problem when exchanging information in the AECO sector, There is no single source of truth, but many specialized, partial sources of truth that need to be coordinated.

Focus Group Meeting
The Focus Group Meeting discussed the proposal in detail based on theory, knowledge and implementation of work by the UniSA STEM Industrial AI research team over the past decade to resolve interoperability issues in in the Oil & Gas sector.This proposal provided a 'connected CDE' solution.On reflection, we believe this forestalled further evaluation and formulation of alternative actions and proposals arising from the results of the Semi Structured Interview.Hence, rather than present full analysis and interpretation of the results of the Focus Group Meeting we present sentiments around issues arising from the approach proposed.These sentiments are relevant to approaches the AECO sector might adopt to improve data and information exchange.A transcript of the meeting was autocoded by NVivo then manually re-coded to identify negative, positive or neutral sentiments, while a hierarchy chart assisted visualisation.Narrative by the researchers with quotations by the industry partners analysed sentiments and issues raised.

Section 4 -Discussion
In this section, alongside interpretation of the Results relative to the research questions, we make recommendations to guide meaningful action for improving ecosystem interoperability in the AECO sector.

Section 5 -Conclusion
In this section we summarise the results of our research, identify priorities for action, and propose future research to improve ecosystem interoperability.

LITERATURE & STANDARDS
Guided by research questions RQ1 and RQ2, and to better understand ecosystem interoperability issues discussed with our industry partners, we carried out a review of standards, systems and servers, sustainability's relationship to interoperability, and of prior research by the authors.

Global, industry & web-based standards
We began examining RQ 1 with a review of standards which influence the interoperability of information exchanges, systems and applications in the sector.We note three main types of standards: Global (includes regional and domain level implementations); Industry; and Web-based.

Global standards
In the mid-1990s the AECO sector began to develop standards to improve interoperability through the U.S. based International Alliance for Interoperability (IAI).The IAI established other regional, national and international chapters and developed the Industry Foundation Class (IFC) (Group, 2022b), the common language that would enable software authoring tools and applications to communicate with each other.IFC is defined by ISO 16739-1:2018ISO 16739-1: (2018b) ) and can be encoded in various formats including eXtensible Markup Language (XML), JavaScript Object Notation (JSON) and STEP Physical File Format (SPFF) as defined in the EXPRESS schema.Therefore it can be transmitted via the web, imported and exported, and managed in centralised or linked databases (buildingSMART, 2024b).
The IAI changed its name in 2005 to a more user-friendly buildingSMART International (bSI), the industry body responsible for governance of standards and guidelines for the sector.bSI is a not-for-profit, open, and vendor neutral organisation dependent on global collaboration between discipline and industry experts (buildingSMART, 2021a).With the development of bSI, the AECO sector acknowledged the reliability of information exchange standards which are user-defined, rather than vendor-defined -vendors may be 'significant partners' but not board members of bSI.
AECO sector global standards are implemented by mapping workflows to a standard.For example, the ISO 19650 (2018a) series provides a common unified framework for effective collaboration, production and management of information across the lifecycle of a built asset using building information modelling (BIM).Correspondingly, ISO 16739-1: 2018 (2018b) (IFC) includes definitions of that cover data required for buildings over their life cycle, It is an open, international standard (ISO 16739-1:2018) and promotes vendor-neutral, or agnostic, and usable capabilities across a wide range of hardware devices, software platforms, and interfaces for many different use cases.
Global standards may be augmented by numerous regional or domain specific standards.For example, the buildingSMART Data Dictionary (bSDD), developed by bSI from ISO 12006-3, ISO 23386 and Linked Data standards, can store global (e.g.UniClass), national, domain-specific (e.g.ETIM, a German open standard for technical products) and company classification systems and standards (buildingSMART, 2021a).bsDD provides a standardised workflow to guarantee data quality, information consistency and interoperability.
The Construction Operations Building information exchange (COBie) global standard defines information exchanges between building completion stage and handover to the client or operator.COBie was developed in 2007 by E. William East for the U.S. Army Corps of Engineers.It facilitates exchange of information to allow facility managers and operators to determe optimal performance, repairs, and maintenance issues over the lifecycle.It was published in 2009 by bSI as 'Basic FM Handover IFC 2.3 MVD' (buildingSMART, 2021b) and has several formats including an analogue spreadsheet representation (e.g.CSV), a digital representation in file format STEP-Part 21 (IFC), and an ifcXML digital format (cdbb, 2021).
Global standards are also essential to ensure interoperability between different domains and use cases.For example, geospatial standard GML is facilitated by IFC 4.3 which integrates buildings with infrastructure (buildingSMART, 2020).Hooper (2022) asserts IFCs reach across sectors due to its ability to integrate vertical (buildings) with horizontal assets (roads, rail etc.), …there is nothing in the industry, besides IFC, that can accomplish so much in terms of connecting information across so many domains (Hooper, 2022).

Industry standards
Implemented alongside global standards, industry standards are defined by CAD software vendors to map data models to a file format (e.g.Autodesk Revit -RVT), or by other software vendors to map data to more familiar document formats (e.g.Adobe Acrobat -PDF, Microsoft Excel -XLS).The process of mapping raw data to recognisable file formats is defined as 'serialisation' while the reverse is 'deserialization'.
The dilemma faced by CAD software vendors is the degree to which they support interoperable global standards which might lessen their own product's market dominance (Stapleton, Gledson and Alwan, 2014).Whereas global standards aim to facilitate interoperability between vendors' products, industry standards aim to facilitate the operability of vendors' products.Though the common language is IFC, bSI conformance testing to certify the ability of vendors' software tools to interoperate with IFC is widely reported as unreliable (Lipman, Palmer and Palacios, 2011, Jabin, Dimyadi and Amor, 2019, Kiviniemi, 2008).Inconsistencies in vendor's IFC import/export translators lead to data loss and errors as noted by (De Gaetani, Mert and Migliaccio, 2020).

Web-based standards
The 'Semantic Web', a term coined by Tim Berners-Lee, defines a holistic approach based on computers' ability to find and link semantic meaning in data, and to use rules to infer reason through logic (Berners- Lee, Hendler and Lassila, 2001).The World Wide Web Consortium (W3C), led by Tim Berners-Lee, promotes this approach through the Linked Building Data Community Group (LBDCG).Instead of files, information is represented in 'structured graphs' which can be integrated with different sources of data and repositories (Pieter Pauwels, Zhang and Lee, 2017a).
The LBD approach implements standards via Internet Protocol (IP), Transmission Control Protocol (TCP), Domain Name System (DNS), Hypertext Transfer Protocol (HTTP), and others.W3C LBDCG have developed web-based standards (W3C, 2014) including, • Resource Description Framework (RDF) uses a Uniform Resource Identifier (URI) to name relationships and two ends of a link (a 'triple') to form the structure of a 'directed, labelled graph'.
• Web Ontology Language (OWL) builds on RDF by providing a 'language for defining structured, webbased ontologies which enable richer integration and interoperability of data among descriptive communities'.
• SPARQL, a query language which accesses diverse linked data sources across the web.bSI's Linked Data Working Group (LDWG) launched 2015 developed W3C's standards.RDF and OWL allowed '…building data to be easily linked to material data, geographic information system (GIS) data, product manufacturer data, sensor data, classification schemas, social data, and so forth ' (bSI, 2024b).Official bSI formats include the following, • ifcOWL which translates the IFC schema into a 'semantic web graph' to enable 'partitioning' of IFC information (Beetz, de Vries and van Leeuwen, 2009).ifcOWL files are large because they contain all terms of the IFC specification, also making them difficult to understand, thus compromising usability for developers (Rasmussen et al., 2020).
An alternative bSI candidate/provisional format is, • IfcJSON, introduced by Afsari et al. ( 2017) is a lightweight data exchange format with 'higher parsing efficiency' than ifcXML.The authors expressed impatience with the status quo, Unless ifcJSON schema is completely established, the data on [the] Web will lean towards proprietary schemas with no common structure or standard schema to translate between vendor-specific data contents (Afsari, Eastman and Castro-Lacouture, 2017 p.41).
W3C LBDCG continues to develop web-based formats including, • Building Topology Ontology (BOT), which defines relationships between components of a building to provide a means for representing and reusing information in the AECO sector (Sadeghineko and Kumar, 2022).It's described by its originator as a 'modular building ontology' for expressing the topology of a building e.g.site, building, space and building element (Rasmussen et al., 2020).
• Ontology for Managing Geometry (OMG), provides a means to link building objects to their geometry thus allowing web-based reuse of these objects (W3C, 2019).
In 2007 a pioneering LBD approach was implemented at the Sydney Opera House, NSW, Australia by combining IFC and the semantic web using RDF and OWL to enable '…loosely coupled software applications to collaborate as if they were one application' (Schevers et al., 2007) (Werbrouck et al., 2021)

Systems & Servers
Continuing to examine RQ 1 we reviewed systems and servers which have been implemented to improve interoperability in the AECO sector.These challenges coalesce around attempts to integrate streams of information from different project team members across building lifecycle stages.Developed for this purpose, the Database Management System (DBMS) allows organisation, storage, and retrieval of data from a computer.DBMS models include flat file (e.g.Excel or CSV), relational, hierarchical, and object-oriented approaches.The first DBMS was the Integrated Data Store developed in 1960 by Charles Bachman (Computing, 2009).
In the AECO sector a BIM server is a domain specific version of a DBMS with its own distinguishing requirements, including object-based management capabilities and an allowance for, …query, transfer, updating, and management of model data, partitioned and grouped in a wide range of ways to support a potentially heterogenous set of applications' (Sacks et al., 2018).
BIM is linked to the sector's global standards, as noted in Section 2.1.1,but it is primarily a concept which describes a broad framework of interoperable workflows in the AECO sector focussed on the CAD model.It has been summarised as, …a modelling technology and associated set of processes to produce, communicate and analyse building models (Sacks et al., 2018).
BIM progressed from a focus on design and construction to wider incorporation of all lifecycle phases (Malagnino et al., 2017) plus consideration of workflow practices from the manufacturing sector e.g.Product Lifecycle Management (PLM) (Mangialardi et al., 2018).It evolved in the early 1970s based on work by Charles Eastman and colleagues and developed from the mid-1990s at Georgia Tech School of Architecture, U.S., refining the concept of collaborative approaches to information sharing across building lifecycle stages through a building model (Charles Eastman et al., 2010).
In …all users agree that the archiving function, and the certainty that the latest information is in one place, make the BIMserver software added value for any engineering consortium (Beetz et al., 2010).
The functionality of BIMserver was extended with the BIM Collaboration Format (BCF) which enabled 'issues' or problems to be exchanged and resolved between parties (van Berlo and Krijnen, 2014).
BIM server systems comprised a single, shared model stored in a centralised repository which facilitated full collaboration between parties, a configuration defined as level 3 BIM, and described as 'the holy grail' or full interoperability (Gasparek and Ondrej, 2017).BIM levels are based on degrees of collaboration and interoperability in the AECO sector ranging from 0 -3.In 2011, the UK Government's BSI PAS (Publicly Available Specifications) 1192 framework formalised workflows to achieve BIM level 2, expanded the concept of the CDE, and documented best practice for implementation of COBie.It was then upgraded to global standard ISO 19650 series in 2018, incorporated into the UK BIM Framework (bsi, 2024a), and became an Australian Standard in 2019.Thus, only recently has BIM been recognised as significant for delivering interoperability in the AECO sector (Hub, 2020).Furthermore, Tomczak et al. (2022) note many other standards, systems and methods for describing data and information exchanges in the AECO sector including, Product Data Templates (PDT), Model View Definition (mvdXML), Information Delivery Manual (IDM), Level of Information Need (included in ISO 19650-1:2018), Data Dictionaries (ISO 23386:2020), IFC property templates, Information Delivery Specification (IDS), and Linked Data with Shapes Constraint Language (SHACL).
Currently, file-based exchange of structured information (geometrical models, schedules and databases) between applications and servers is the norm.However, the file-based approach compromises the function and performance of cloud-based BIM servers (Afsari, Shelden andEastman, 2016, Afsari, Eastman andShelden, 2017).Lee et al (2014, p. 211) reported file-based transaction issues including: inability to query objects; restricted access to subsets of models; difficulties tracking changes; difficulties assigning access privileges.Though IFC is an objectbased data modelling format these issues occur partly because, during a file-based transaction, the entire model is transferred and stored as a file in a database.In contrast, an object-based exchange parses and saves a model at object level (e.g., wall, column, or beam).Object-based exchanges have been defined as, …a unit sequence of reading, writing, and creating data… (Sacks et al., 2018, p. 113) Accordingly, to improve efficiency and speed, data rather than files will become the shared base for exchange of information, either by using adaptors or via an Application Programming Interface (API).For example, IFC 5 will enable object-based or partial exchanges of information, rather than whole file-based exchanges, thus providing the necessary foundation for integration with digital twins and smart cities (Berlo et al., 2021).
An industry inspired solution for object-based exchange of information emerged between 2015-17 with flux io, a cloud-based server founded on Siemens' Parasolid software which exchanged data using adaptors and a Data Interchange Hub (DIH) (Siemens, 2017).This significantly improved collaboration and interoperability in the AECO sector by allowing real-time push and pull of data between different software applications.Speckle developed from Dimitrie Stefanescu's PhD thesis (2020) uses a similar approach.The Speckle Server Admin (SSA) allows objects and information to be linked without any need to convert from one format to another (Poinet, Stefanescu and Papadonikolaki, 2020).Both flux io and Speckle define an industry standard -the former based on Parasolid, the latter on SpeckleObject which is open source.Speckle has been described as a 'distributed' CDE because it operates across locations and between different applications (Poinet, Stefanescu and Papadonikolaki, 2020).

Common Data Environment (CDE)
The CDE is a significant component of ISO 19650-1:2018ISO 19650-1: (2018a) ) which sets out the framework, roles and responsibilities for collaborative BIM working.The CDE solution can include both a DBMS capability to manage 'Information Container' attributes and meta data, and a transmittal capability to issue update notices to team members and maintain the audit trail of information handling.The CDE transfers common data through Information Containers relating to domains, and present in four states -WIP (Work-in-Progress), Shared, Published, and Archived.In the Published state, Information Containers are transferred as 'structured information repositories' e.g., the Project Information Model (PIM) and the Asset Information Model (AIM) -the latter for operations and facility management purposes.The Information Container is defined as a '…named persistent set of information retrievable from within a file, system or application storage hierarchy'.This can include structured information (geometrical models, schedules and databases), and unstructured information (documentation, video clips, sound recordings), all of which comprises the information model itself.
Bucher and Hall (2020) categorised configurations of CDEs, proposing a three-dimensional conceptualisation.
Hence, a one-dimensional CDE (e.g.Autodesk's BIM360) operates within an organisation, a two-dimensional CDE includes several CDEs in an organisation, while a three-dimensional CDE includes multiple CDEs operating across an ecosystem or digital platform.Alternatively, the lifecycle stage might determine the nature of the CDE: for example, Salzano et al. (Salzano et al., 2023) make a case for a centralised CDE linked to sensors and a single IFC BIM model for the operation and facility management of an historic building.Patacas et al. (Patacas, Dawood and Kassem, 2020) also consider lifecycle and the operations phase for development of a CDE which can generate reactive and preventive maintenance tasks using BIMserver, IFC and COBie (Section 2.1.1).Tao et al. (Tao et al., 2021), examining the security issue of a centralised CDE which might suffer loss of access and manipulation of data, propose a 'decentralised peer-to-peer system architecture' using blockchain with data storage provided by an Interplanetary File System (IPFS).
The bSI's OpenCDE API Technical Room are developing a prototype Documents API interface for transferring non-geometrical documents from applications to a CDE (buildingSMART, 2021c).Eventually, OpenCDE aims to provide a set of APIs to connect multiple CDEs (Werbrouck et al., 2021).This will allow seamless transfer of Shared or Published information between authoring tools and a CDE e.g.Oracle Aconex, with direct exchange to a coordination and quality checking tool e.g.Nemetschek's Solibri.CDEs will also need to facilitate object-based, or partial, exchanges of information using IFC 5 in the move towards web-based engagement with artificial intelligence and machine learning (Berlo et al., 2021).
Germany's PAS DIN SPEC 91391 series released 2019 provides a comprehensive definition of expected relationships and open data exchanges between multiple CDEs.
The direct exchange from one CDE to the other CDE is enabled with an openCDE interface and is intended to substitute the manual exchange of information containers, e.g. if a user wants to transfer an information container from the partner CDE to their own CDE ( (DIN), 2019).
A goal of DIN SPEC 91391-1 is that '… tasks and project status are always traceable at a central location'.Nevertheless, the paradox of this goal is acknowledged.Rather than 'a central location', it Léon van Berlo, Technical Director, bSI (Section 1.6.2.2) asserts that information is distributed across locations, hence coordination is paramount, There is no single source of truth, but many specialized, partial sources of truth that need to be coordinated.

Sustainability & Interoperability
Examining RQ 2, we note the Brundtland Report's definition of sustainable development,

Sustainable development is development that meets the needs of the present without compromising the ability of future generations to meet their own needs. 'Our Common
Future' (Brundtland, 1987).
Since the report was produced the integration of physical and virtual worlds challenges us to ensure that information is generated from reliable, accurate and effective data.Interoperability underpins these challenges and has been defined as, …the ability of two or more systems to exchange information and to use the information that has been exchanged.(Hub, 2020) Though interoperability and BIM have received attention, Ozturk (2020) identifies a gap in research connecting sustainability with BIM, a means of effecting interoperability, in the AECO sector, Sustainability studies on BIM are scarce… The impact of design decisions on the sustainability of the building is inevitably acknowledged by all professionals (Ozturk, 2020).
We can only infer the impact of poor interoperability on the environment and society from a detailed analysis of the economic cost in the AECO sector by the National Institute of Standards and Technology (NIST), U.S. (Gallaher et al., 2004).It was estimated to be $15.8 billion per year and three categories of costs were identified: 1. Mitigation e.g., manual rework, and re-entering of data.
3. Avoidance e.g., translators or adaptors needed to allow software applications to communicate.
Nevertheless, Adamus (2013) confirms the contribution of environmental simulation and evaluation methods enabled by interoperable information exchange e.g.open data schema Green Building XML (gbXML) allows BIM, architectural and engineering analysis tools to communicate with each other.Dassisti et al. (2013) concur with the view that interoperability is the foundation layer of the 'three pillars' of sustainability -environmental, social and economic achievement.Mora-Rodriguez & Priest (2016) confirm that for all sectors of industry 'interoperability facilitates sustainability', and that exchange and sharing of information are essential for effective decision making to achieve sustainable outcomes.Lamb (2018), when comparing AECO and the Oil & Gas sectors, confirm the latter's recognition that data and information are as important as physical assets and oil itself.Aranda et al. (2020), via a detailed civil engineering case study, confirm interoperability's positive impact on the sustainable use of resources.

Ecosystem Interoperability
Prior to this paper we defined three main approaches for achieving ecosystem interoperability in the AECO sector (Doe et al., 2022) (Figure 1), 1. Point-to-Point (one-to-one): links between proprietary software applications using standards-based, or proprietary adaptors and APIs.
2. Hub-and-Spoke (many-to-one): a single centralised server to which each software application communicates, a.A centralised federated server which collects and manages federated models, e.g., BIMserver, Trimble Connect, Oracle Aconex, or Speckle Admin Server.
b.A single shared model, or 'single source of truth', used by Product Lifecycle Management (PLM) systems e.g., Dassault 3D Experience.
3. Network-Centric (many-to-many): middleware and linked data approaches, for supporting distributed and/or decentralised communication and federation, a. Middleware operates via a shared messaging service and may include standardised adaptors and APIs which provide access to the ecosystem to allow data exchanges between a diverse array of applications and systems that participate.
b. Linked Building Data (LBD) uses web-based, decentralised sharing of data to improve the level of interoperability generated by IFC and between applications in the AECO sector .We observed that method 2a, Hub-and-Spoke, is the dominant mode of exchange and that it arises from the AECO sector's normative approach whereby data and information is centralised and consolidated.However, we also observed that method 3a, Network-Centric, better supports the distributed nature of the AECO sector.We concluded that, due to legacy issues, method 2a would need to continue to be supported but method 3a should be implemented as a standards-based approach to provide future proof ecosystem interoperability for the sector.We described this approach as a Hybrid Interoperability Ecosystem, and it formed the basis of our response to the industry partners' challenge discussed at the Focus Group Meeting as noted in Section 1.6.2.3.

Summary
Examination of RQ 1 reviewed global, industry and web-based standards, including DBMS and other servers which aim to organise, store, and retrieve data from a computer.We examined the way DBMS have evolved across the decades until their current iteration, the CDE which is in widespread use across the AECO sector.We then reviewed research and standards relevant to managing hierarchical relationships between multiple CDEs.We examined RQ 2 by reviewing current understanding of the relationship between sustainable development and interoperability and revealed that lack of research in this area masks understanding of the degree to which poor interoperability has affected social and environmental interests.Finally, we reviewed prior research which defined three methods to achieve ecosystem interoperability implemented by the AECO sector -Point-to-Point, Hub-and-Spoke, and Network-Centric.

RESULTS
We began discussions with the AECO industry partners with open questions and an online survey.Responses guided interactions and were the basis of a semi-structured interview and a focus group meeting which followed.
We describe the Methodology in more detail in Section 1.6.

Survey
In the survey completed in October 2022 we asked the industry partners ten questions (Appendix A) framed around research questions RQ1 and RQ2.The responses were analysed to assist understanding (Figure 2).Based on the prevalence of words, terms and phrases we began to identify and code significant themes and issues: we omitted questions 7 and 8 which asked for lists of systems and software platforms used by the industry partners.

Data and Software (plus Tools and Applications)
Most interoperability issues involved 'data' and 'software'.Problems with exchange of data from 'one [software] tool to another' across workflow stages prompted suggestions for a solution, such as a 'common or base language' that would facilitate communication between different software tools.The side effects of these problems were also reported.For example, some 'duplication/recreation' of data is required and there may be 'data loss or errors' when importing and exporting data, a broader issue likely due to incompatibility between IFC and proprietary software formats.Comments included, Ability to then use data from one tool or another for upstream or downstream activities.
…exporting data out in a common or base language that can be consumed by others.
…some duplication/recreation of data required.
Import or export data loss or errors.
IFC class data incorrect e.g.project name, owner history, version.
IFC mapping and translation issues, geometry and data loss at conversion.
Specific issues included the exchange of data between completion of the project and handover to the client, a process defined by COBie (Section 2.1.1).Also reported were 'class data incorrect' and 'data loss at conversion' both of which relate to the common language IFC.
We understand the concept 'software' to be similar to 'tools' and 'applications'.For example, Autodesk Revit for architecture is 'software' and an 'application' but also an authoring 'tool', while Projectwise is 'software' and an 'application' but also a collaboration 'tool' for the AECO sector.Hence, we include here issues reported which are relevant to 'software', tools' and 'applications'.
Varying tools to undertake same or similar task.
Many workaround workflows developed to get output from one software to another be it in native forms, IFCs, within one vendors software stack etc.
The first issue above points to the variety of tools which are essentially doing the same thing but which communicate poorly between each other.Workarounds to poor interoperability include 'software integrations' and 'additional software development' carried out by the industry partner as user or client, rather than by the software vendor.The last comment is more specific as it refers again to the software language -'native' (proprietary) rather than 'common' (IFC) -and the effort needed to ensure good integration between them.
Reported was understanding of the connection between sustainable design and the need for interoperable applications: ...efficient sustainable design processes requires inputs and outputs that can move between technical applications.
…consider using applications or offerings from one vendor.
This last comment suggests a solution to interoperability issues in general, an approach which is widespread in the AECO sector and in-line with individual vendors' business models.

Solutions and Platforms
Reported were technically detailed 'systems-level' solutions which follow 'ISO 19650' standard, while solutions were dependent on the 'digital ecosystem'.We note that 'platforms' usually include a suite of products for different AECO disciplines offered by a single vendor e.g.Autodesk Revit, or Bentley MicroStation.
…our work revolves around complex, system-level solutions.
…depending on the digital ecosystem, including software integrations, API-based solutions, additional software development, open format deliverables that multiple platforms can read/write, etc.
To facilitate collaboration, a key component of effective interoperability, examination of each platform is guided by ISO 19650 series standards (Section 2.1.1).
We usually follow ISO 19650 principles, establish CDE solutions and define technology maps for the individual platforms involved in the authoring and processing of information containers.

Specific Information Exchange Issues
Specific information exchange issues experienced by both industry partners included, Classifications missing e.g.UniClass, OmniClass.
Exchange requirements incorrect.
'Classifications' are meta data (information about information) that can be added to IFC or proprietary software formats.This, and comments which followed, suggested user input error and/or failure to implement a standards framework (e.g.ISO 19650) for the exchange of information.'Clashes occurring' refers to the integration, or lack of integration, between the different AECO sector disciplines and suppliers and the different software models that they create and combine into a single or federated data model.

Other Interoperability Challenges
A key issue which frustrates interoperability concerned 'workarounds', Many workaround workflows developed to get output from one software to another.
Also reported was the inadequacy of the common language (IFC) when defining fine grained information about civil engineering works, …necessary granularity not available in the schema (e.g.IFC 2x3 for civil).
The authors note that this issue is partially resolved with IFC 4.3 released May 2023 by bSI, soon to become a global ISO standard.

Semi-Structured Interview
A semi-structured interview completed in November 2022 discussed the survey responses and examined in detail issues reported based on the ten questions asked in the survey (Appendix A).The concept map (Figure 4) was developed from the initial coding of themes (Figure 3) and guided interpretation of the themes and sub-themes and discussion around them.The concept map does not indicate workflow.

Data & Information
When interpreting the transcript and issues which affect interoperability we were careful to separate 'data' from 'information'.Most issues related to data rather than information.Whereas data are individual facts information is the result of organising and interpreting those facts e.g.resources which make a building are data while the completed building is information, or data exchanged between applications becomes information when compiled or interpreted by the application.Sub-themes 'applications' and 'model' have been incorporated into 'data' and 'information' theme analysis e.g.once data has been interpreted and organised by an application it becomes useful information in model or document format.

Data
With the comments which follow, it is noted that loss of data is likely an in-built error in 'translator' or 'mapping' design.When applications attempt to compile or interpret data these in-built errors lead to further errors in the information produced.An example is given where geolocation or coordination data is treated differently by applications.
...because different tools author geometry differently, when you export/import there's naturally a simplification of that information and data loss will occur.
...data loss is more down to how the translator or mapping is built... But, with geometry issues, the default is to get back to the vendor and get them to find a solution, and some vendors are less willing to go the extra mile in resolving interoperability issues.
Yes, each application tends to treat the coordinate system differently.If you get them all landing in one spot you give yourself a high five.
The cost of remedying data loss was confirmed but not quantified.
…no we haven't quantified that.Identifying [costs] is probably the challenge.Over the years it's improved but it would just be accepted that we couldn't reuse that data and that we had to regenerate it in part to use in another system.
IFC, the common language which should facilitate exchange of data between applications, was discussed by both industry partners.For example, the need for collaboration to establish IFC mapping protocols was emphasised.
That's normally a managed process, and we're normally sitting beside a relatively large delivery team which means that we need to have a collaborative way of working when setting guidelines.
Other common languages, or widely used proprietary languages, were also noted as useful for exchanging data and information between applications.
Yes, certainly for us we need to get data from one application to another, and in most cases IFC, or GBXML, or even just simply CSV files sometimes, but IFC from a modelling point of view.
Insight was provided into the way that data can be 'decoupled' from a geometrical model.Data is extracted from different proprietary and IFC models and stored in a shared database using Standard Query Language (SQL) or dRofus.
On the geometry side, we often work with IFC as well.And between tools, in terms of data, we often decouple data from models, so we don't necessarily store all the data in the models themselves.
The models and linked shared data were then consolidated by an Enterprise Resource Planning (ERP) system e.g.IBM Maximo or others.

And then it normally goes into an IBM Maximo or Ellipse [regulatory reporting and data analytics]...
Highlighted was an issue arising from recent introduction of CDE, ISO 19650 which is a means of allowing all project data and information to be accessible and collated across the building lifecycle.The CDE is reviewed and described in Section 2.2.1.
…we have multiple CDEs on a project, and connecting information from one CDE to another is somewhat problematic.
We note that the aim of the CDE is to improve collaboration, accuracy and the management of data.It was reported that multiple CDEs on a single project are a significant problem, both between applications and between stages of building and completion, and especially between the completion and handover or operations stage.

…it's not only interoperability in a point in time with different applications used on the project, but interoperability between lifecycle phases of the project.
…bringing data from a design team to construction to an operations team normally involves quite strong interoperability challenges.

Information
In developing the openBIM environment bSI has introduced standards and services to improve the accuracy and reliability of data exchanges and the richness of information.The industry partners reported that they have not used these standards and services, though proprietary solutions have been implemented.The buildingSMART Data Dictionary (bsDD) is a service which ensures reliable links between information, classification and standards data.

Yes, same. I don't think we've used the bSDD ourselves, we use the Revit classification addin, and the equivalent in ArchiCad in which you can load any classification system as an XML.
Recently introduced, the Information Delivery Specification (IDS) is a bSI standard developed for ease of understanding by humans and readability by computers allowing validation of information exchanges based on information requirements defined by the client.Again, this is yet to be implemented or experienced by the industry partners.
Normally and hopefully that's either in a contract or in a return brief back to the lead appointing party in some sort of exchange information requirement which is normally in an execution plan.
When defining information exchange requirements contractually it was noted that conflicts may arise.

It's more a case of, if the exchange requirements are defined, we don't know what we have to export, or a case of exchanging information in a different manner compared to what is defined in a contract somewhere.
The industry partners identified the need for education and training to ensure staff appreciate the importance of data exchange accuracy and reliability.
…how to get data from one spot to another, needs education, it's not everybody's first thought… There are not too many people who really know the ins and outs.
…who's interested in producing what information, which is again challenging between teams because people are much more interested in populating their own, or producing information for their own purposes… I think there is a conflict there, an interoperability challenge, not in a traditional sense but, interoperability of needs and interests and willingness to actually do stuff.

Management, Team & Project
The hierarchy of 'management' issues (Figure 4) related to poor interoperability descends to 'team' and 'project' with 'design' as a sub-theme.

Management
Information management practice is defined in ISO 19650 series, as described in Section 2.1.1.The industry partners did not perceive that this contributes towards improving interoperability issues.
That's more like a general management hygiene.We follow because it makes the information flows a lot more structured than without it.That [19650] doesn't have much to do with interoperability in my view.
I don't see anything in ISO 19650 that would solve the interoperability challenge in my head, anyway.
Nevertheless, it was confirmed that much effort is made to collaborate and ensure team members understand information exchange guidelines e.g. when intiating mapping of IFC classes in order to ensure team members understand common procedures.
...we normally nowadays do it schedule based because that gives us more granularity.At the beginning of the project.That's normally a managed process, and we're normally sitting beside a relatively large delivery team which means that we need to have a collaborative way of working when setting guidelines.
As noted in Survey response Section 3.1.1,the industry partners expanded on pain points experienced during the exchange, or handover, of information between stages, due to the inadequacies of the Construction Operations Building Information Exchange (COBie), the global standard for this stage (Section 2.1.1).
...there's a lot of push back, a lot of behavioural change management to go through, to actually make it happen.It's a bit of a dead end in terms of its format, like the way you export it out into a COBie export doesn't go anywhere.
It was noted that the client and/or operator will consolidate handed over information into a management system to optimise the performance of the asset or building, reduce operational downtime, and extend its lifecycle.

Team
The difficulties of exchanging information between teams and stages during handover stage reinforced comments recorded earlier, but here made in the context of the many different authoring applications which team members use.

...bringing data from a design team to construction to operations team normally involves quite strong interoperability challenges.
The industry partner's concerns appear to relate to both technical and management issues which frustrate interoperability.

Project
Industry partners described the complex nature of projects which range across disciplines and sectors.
The fact that we are multidisciplinary in-house, we find ourselves crossing the boundaries of sectors, so you might have a typical transport sector project with building requirements and also service requirements all of which might be utilising software chosen by the person, and they're not all the same.
They also discussed the benefits of staying with one vendor on a project.In this case, the exchange of data is assured as no import or export is required to non-native applications.
A typical building project, a typical fit-out for a building, if you're in the same vendor, no need to do any IFC exporting unless it's a client requirement.

Process
'Process' often emerged as a concept during discussion of the import and export of IFC data.
Not because IFC can't manage 2D... but it's more because the export and importing process in the authoring applications are typically very focussed on the 3D and it's really hard to make the 2D interoperability work.
This comment refers to the vendor's internalised export and import 'process'.But continuing discussion in the context of IFC data loss and errors the importance of 'process' definition by the user was also emphasised.
It also depends how well the import and export processes are defined.We are normally quite stringent with our guidelines on how it should be done on a project.
Data processing is a 'proccess' issue at handover stage -a key challenge reported is consolidation of data.Rather than rely on disciplines' authoring tools, and model data is consolidated using specialist data processing applications such as, IBM Maximo, Ellipse, IBM TRIRIGA and SAP, as mentioned above under 'Management' issues in Section 3.2.2.1.Prior to passing on this data at handover, it is stored separately from model geometry.

It can sit in applications like dRofus for example if its buildings data use, which is a pretty good tool to consolidate information from different authoring applications and IFC and have that 'single source of truth' concept.
The 'single source of truth concept' mentioned here refers to the notion that all data and information can be, or is, consolidated centrally and therefore easily accessible.

Key Issue
The qualitative approach revealed issues of all types which frustrate full interoperability.Therefore, our final question to the industry partners asked whether a key issue could be addressed, an issue that fundamentally affects their business workflows.Their response was as follows, …we have multiple CDEs on a project, and connecting information from one CDE to another is somewhat problematic.There might be one CDE which holds the bulk of the data, but there are a lot of vendor based CDEs that you have to use for the application to work and getting the data from one to another involves a little bit of manual handling, which is not the essence of ISO... We'll call it a connected CDE.Normally, one of those will be the main one, the main CDE.
This issue refers to problems arising from the convergence of multiple CDEs (Section 2.2.1).

Focus Group Meeting
The Focus Group Meeting in March 2023 discussed in detail a proposal which responded to RQ 1 and the 'key issue' noted by the industry partners above in Section 3.2.3.2.However, as noted in Section 1.6.2.3 rather than present a full analysis and interpretation of the results of the Focus Group Meeting we present analysis of sentiments around issues arising from the approach proposed.

Version
The following sentiments refer to the version of an application.Versions may be re-issued by vendors annually or at more regular intervals.The challenge for the sector is to keep applications from different vendors up to date so that work-in-progress and archived versions of data can be used by the current application.In this context, industry partners also referred to IFC, the common language, which could alleviate problems arising from application version issues.
If they had a historical record of their designs and data from years ago sitting in IFC it might solve some problems.

Adaptors
The industry partners were also concerned about adding new applications in the form of adaptors, a solution we and others have proposed to facilitate interoperability between different applications.
Any sort of little add-in that has to be added to someone to get something to work, we can't guarantee we're going to distribute that to other companies and get it working correctly.
And because it's the concept of more third-party apps, more this, more that, that, when you get a joint venture, making sure another company has certain versions of stuff is not easy.

Use Case
Use cases are used by all software developers and systems engineers, and by stakeholders at higher levels.They are a list of actions or event steps defining interactions between a role and a system, or between stakeholders and a system, to achieve a goal.Hence, the following question asked by the industry partner is about the level of granularity or detail of a use case which might be the focus of a proposal by the researchers.The implication in this response is that moving from discipline level to work package level would improve access to useful data and information and therefore represent a better use case.
… the information container level that most of us will be going at is already at the discipline level… I was thinking if this was to drill down into, call it trade packages within the discipline… there might be one file that we're sharing, but there's different packages of work in it, or we just want to pull out the state of the steel work in the structural file, even though it's got concrete in it as well… I just wonder, is there a value, is there a benefit to get access into something at a more granular level maybe?

Cloud-based
Storage of data on cloud-based servers is a concern which increases if data is stored on another party's cloud-based server.
We might have access to it by someone's login still, but we're very mindful at this point, everyone's got a lot of cloud data out there and we're just going to make sure in 10 or 20 years time we've still got access to it somehow.
…how do we get searches that can go out and search these cloud-based CDEs for all of this data in 20 years time when it's someone else's cloud, not your own company's cloud?

CDEs
The means by which multiple CDEs are connected is seen as an unresolved issue.So, the question is how they get connected.There's a lot of interactions happening with ProjectWise and other tools, things like that.Are there third party add ins that need to be on everyone's machine for all of this to work.Or, is it some cloud-based, web-based method that needs very little input or version control of an application?

Messaging
In response to the researcher's novel proposal for a 'connected CDE' (Section 4.5.1), the industry partners expressed concern that a method of relaying messages between AECO team members might simply become another CDE.
… certainly, if there was a way to have those talking through some other thing, whatever that thing is… the message bus seems to solve problems as long as that message bus isn't seen as a yet another CDE.

Automation
The desire was expressed that any exchanges of data which take place between multiple CDEs be automatic and therefore require little user input.
I'm thinking there's not much user interface hopefully in that process, which is trusting the fact you put it in one system means it's coming out the other system correctly...

DISCUSSION
In this section we present interpretation of the Results and their relevance to the RQs.
• RQ 1 (Primary): What issues continue to affect interoperability in an AECO organisation?
• RQ 2 (Secondary): Is sustainable development affected by interoperability issues?
Alongside interpretation we make recommendations to guide meaningful action for improving ecosystem interoperability in the AECO sector.

Common Language IFC (RQ 1)
The IAI's promise in 1994 to end poor communication across systems and applications in the AECO sector is work-in-progress with bSI aiming to deliver through development of openBIM standards and services.The Results confirmed that a common language IFC is considered a key component of openBIM highlighting the following IFC development issues: Vendor related: 1. Importing/exporting 2D information inconsistencies (Section 3.2.Issues 1-4 require vendor development if IFC is to become the common language for the AECO sector, in fulfilment of the IAI's promise in 1994.Through bSI the AECO sector has expressed its ambition to develop digital twins, smart buildings and smart cities, but to achieve these goals requires vendors' willingness to develop proprietary models which are interoperable with each other through IFC.Issues 1-4 and their resolution are closely related to the notion of 'vendor lock-in', hence we have addressed them in more detail in Section 4.2. Issues 5-7 require improved understanding of IFC by those in AECO organisations responsible for its implementation.General understanding of IFC is provided by bSI's Professional Certification (PCERT) framework (buildingSMART, 2024a) and is delivered by third parties (e.g.Modmation, Australasia) with core content based on ISO 19650 standards and an introduction to the BIM Execution Plan (BEP), BIM use cases, CDE, IFC, BIM coordination, and other openBIM concepts.
Recommendation 1: As there is no PCERT or similar certification available specifically for IFC, though online tutorials are available (e.g.Geometry Gym, Australia), our recommendation is that Professional Certification IFC (PCERT IFC) be developed by bSI as a framework for delivery by third parties to ensure that user input is correctly understood by those managing and implementing IFC for import and export, to and from proprietary models and CDEs.

Vendor Lock-in (RQ 1)
It was suggested in the Results (Sections 3.1.1,3.2.2.3) that to mitigate interoperability issues only one vendor's products should be used.This is known as 'vendor lock-in' where for reliability and consistency the user decides that it is necessary to subscribe to a single vendor's products thus limiting theirs and the clients choice of alternatives, and lessening impetus towards development of a common language IFC.However, in responses to Survey question 8 (Appendix A) one industry partner noted 6-7 different vendors products regularly in use, while the other noted 12 or more.Hence, despite aspirations for vendor lock-in it would appear to be an unworkable solution because of the number of different vendors products used.Typically, on medium to large scale projects delivered on a project-by-project basis and working across domains and disciplines, the AECO sector uses many different vendors' products.
The end-users desire to interoperate across applications clearly conflicts with vendors' goals.Vendors serve both end-users and share-holders interests and aim to provide a market dominating product which partly explains the limited attention given by vendors to interoperability issues, as noted in Section 3.2.1.1,... some vendors are less willing to go the extra mile in resolving interoperability issues.
Pauwel's et al (2011) concurred with this view, The user remains confined to the schema adopted and thus imposed by the platform developers.It is therefore impossible to describe information that falls out of the original schema, neither is it possible to re-use the information in applications that deploy even a slightly different schema, which both occurs often in the case of the AEC domain.(2011 p. 146) Thus, a significant side effect of vendor lock-in is lack of attention for resolving IFC problems, leading to inconsistent import/export models, mapping and translation problems, plus data loss and errors during information exchanges, issues reported extensively over the past two decades (Sections 2.1.3,3.1.1).We conclude that lasting change requires the leverage of primary stakeholders, and indeed, national and regional jurisdictions are beginning to assert their influence including, • UK: Government mandates the BIM Framework for publicly funded projects and asserts the primary role of the 'appointing party' with reference to ISO 19650 series for managing information (bsi, 2024a) • Denmark: Information Communication Technology (ICT) regulations 118, 119 (2013) cover publicly funded projects and publicly funded housing projects requiring IFC format to be available or provided when bidding for work, during design and construction and on handover to the client.
• Finland: The revised Finnish Building Act, in force from January 2025, will mandate IFC as a building permit document for all new and renovation projects (Lavikka et al., 2023).
• Norway: Statsbygg, the government's building commissioner, property manager and developer, has set requirements for use of BIM since 2011.Statsbygg Building Information Modelling Manual -version 1.2.1 describes Statsbygg's requirements for BIM and IFC (Statsbygg, 2013).
• Singapore: From 1/4/2025, BIM submissions to CORENET X for digital approvals from planning to completion will need to be in an IFC format for new work and alterations with Gross Floor Area (GFA) of 5,000m2 or more (Authority, 2021).
• Australia: o Digital Engineering Framework, DNS ST 208, Transport for New South Wales (TFNSW), NSW Government, road and rail projects include mandates for the delivery of IFC (NSW, 2024).
o Department of Energy and Public Works (DEPW), Queensland Government, mandates BIM for projects with capital costs of AUS $50M or more (Queensland Government, 2024).
Recommendation 2: National and regional jurisdictions should be widely encouraged to improve interoperability best practice by mandating implementation of openBIM, vendor neutrality, and the common language IFC.White paper reports and guidelines would assist stakeholders understanding by explaining the economic, social and environmental impacts of poor interoperability and the means to mitigate these impacts by mandating change in the way that data and information is managed.For example, in 2017 the Australasian BIM Advisory Body (ABAB) which includes buildingSMART Australasia promoted a consistent approach to use of BIM across national jurisdictions.White papers forming the basis of national and regional contractor tendering arrangements thus ensuring that evidence-based research is translated into policy and meaningful action.

Multiple CDEs (RQ 1)
The CDE, for managing 'data' and 'information' exchange issues, is central to the ISO 19650 series (Section 2.2.1).However, the Results report the ISO as more useful for management rather than technical interoperability workflows (Section 3.2.2.1).A significant problem arises with integration of multiple CDEs which can be 'somewhat problematic' (Section 3.2.1.1).The industry partners' desire for 'very little input, or version control', and for automated solutions with limited manual intervention, expressed general frustration with the status quo (Sections 3.3.2.3,3.3.3.2).Other CDE issues concerned accessibility to cloud-based archived data and information stored on another party's CDE (Section 3.3.3.2).Indeed, the Results determined that multiple CDEs are the main issue in need of a solution e.g. a 'connected CDE' or 'the main CDE' which would manage the others (Section 3.2.3.2).But concern was also expressed that a new solution allowing all applications to interoperate might might result in yet another 'third party add-in' (Section 3.3.2.3).While the researchers proposed a technological solution as discussed in Section 4.5, here we make a recommendation for implementation of a standard which will encourage wider development of appropriate solutions.Hence, while DIN SPEC 91391 series is unable at present to refer to relevant technologies and their technical impact on an openCDE, the standard is the best available outline for further development of guidelines and specifications which will influence these technologies.

Handover (RQs 1 & 2)
The Results reported significant impediments to effective handover of data and information on completion of a building (Sections 3.1.1,3.2.1.1).These 'quite strong interoperability' (Section 3.2.2.1) challenges, both technical and managerial, focussed on COBie's complex format for organising information, and on delivery team 'pushback' from those struggling to manage the process (Section 2.1.2.1).Formats for COBie outputs at handover were described as a 'bit of a dead end' (Section 3.2.2.1).Such frustration and lack of clarity poorly impacts client and operator implementation of handover information at the moment when 80% of building lifetime costs will begin to be expended (Matts, 2022).The Results reported that sophisticated tools were used by clients and operators to manage and consolidate disordered information at handover (Section 3.2.2.1).Also reported were strategies to facilitate information management e.g.structured information (geometrical models, schedules and databases) is 'decoupled' from unstructured information (documentation, video clips, sound recordings) (Section 3.2.1.1).
Clearly this moment, when development work is complete and operation of the building begins, tests the concept of a 'single of source of truth' (Section 2.1.3.1,Section 3.2.3.1).More accurately, information and data is contained as 'partial truths' awaiting coordination in multiple formats and packages e.g.maintenance and operations manual, BIM or digital twin models, a health and safety file, a fire and emergency file, a fire statement, as-built records, verified construction details and more.Accordingly, it is helpful to consider the notion of a 'golden thread of information', as defined in the Building Safety Act, UK (2022), running through these tasks and workflows.The Act requires that 'duty holders' (client, principal contractor, principal designer) create and manage a 'golden thread' of information during design and construction until handover when an 'accountable person' (AP) takes on this responsibility through the operations stage.
A concept of 'a golden thread of data and information' would extend accountability.The ISO 19650 series provides a framework into which could be woven a 'golden thread of data and information' asserting accountability across the building lifecycle.This principle of accountability is already embedded in bSI's Information Delivery Specification (IDS) which allows clients to state information exchange requirements at the beginning of a project for validation during the project's lifecycle.
Recommendation 4: COBie should be amended so that format outputs are consistently defined and clearly understood by users, clients and operators.Data and information consolidation tools used by clients and operators at handover should be examined and, where appropriate, referenced in COBie e.g.IBM Maximo, Ellipse, IBM TRIRIGA and SAP (Section 3.2.1).DIN SPEC 91391 series already acknowledges the complexity of data and information that multiple CDEs and COBie need to manage at handover stage.Accordingly, improved COBie formats should be developed alongside emerging global standard DIN SPEC 91391.
Recommendation 5: A 'golden thread of data and information' should be embedded in the ISO 19650 series to ensure accountability for the accuracy and reliability of data and information across the entire building lifecycle, including at handover stage.Similar to the Building Act (2022), UK, accountability should include the nomination of 'duty holders' and 'appointed persons' to embed responsibility into the process, thus ensuring that at all stages, data and information is carefully, reliably and consistently managed.

A 'Connected CDE' (RQ 1)
The Results reported the need for a 'connected CDE' or 'main CDE' as a 'key issue' (Section 3.2.3.2) arising from implementation of the ISO 19650 series.The status quo (Figure 6) is a Hub-and-Spoke approach (Section 2.1.1)where a centralised server communicates with each software application, each server a CDE or centralised federated server which collects and manages federated models and other information.
With this approach no one CDE consolidates information, as noted by the industry partners.In prior research we noted two alternative Network-Centric approaches for supporting distributed communication of data and information exchanges: a shared messaging service (middleware); and linked building data (LBD) (Section 2.1.3).

Network-Centric -Middleware
We proposed a Hybrid Interoperability Ecosystem which combined the Hub-and-Spoke (one-to-one) and Network-Centric -Middleware (many-to-many) approaches -the former in recognition of the current ecosystem which requires continued support, and the latter in anticipation of a shared messaging service which could provide holistic connectivity between CDEs and applications (Figure 7), Our proposal acknowledged the requirement to manage multiple CDEs with a method appropriate to the AECO sector's fragmented and distributed nature (Section 1.4).A novel addition for the AECO sector is the Message Bus (MB) which supports shared messaging interactions between BIM CDEs, authoring tools and other applications across a single interface for communication.The content and meaning of these communications would be understood by all as they are based on accepted global standards including ISO 19650 (BIM) series and ISO 16739-1:2018 (IFC)  (Section 2.1.2.1).The many advantages of the proposed approach include: • Many-to-many network connectivity is configurable to support a variety of system-to-system interactions and organisational workflows: e.g., completely distributed communications between all design and construction team members for any system or application, or communications coordinated by a primary CDE at specific workflow stages, and anything in between.
• The Hybrid Interoperability Ecosystem approach aims to bring together what already exists (i.e., specifications, standards, and technologies) to realise improved capabilities.
• It builds on what is already existing in the AECO sector with an incremental approach to supporting the desired future state, rather than requiring a complete lift-and-replace of infrastructure with new standards and tools that do not yet exist or are in early stages of development.
• Promotes vendor neutrality and choice by organisations, i.e., an organisation can continue to use their preferred and specialised tools for the role they play in projects.
Recommendation 6: We propose implementating a proof-of-concept Network-Centric -Middleware, Shared Messaging Service.This is a novel approach to improve interoperability in the AECO sector.An alternative Network-Centric -LBD approach was noted in Section 2.4 and their similarities and differences are as follows, • Both are distributed ecosystems appropriate to the fragmented AECO sector.
• Middleware decision-making is centred on a project-based community while LBD decision-making is decentralised across sub-communities.
• Middleware implements AECO's global standards while LBD standards are presently defined by the internet community, W3C and bSI (Section 2.1.3).
• LBD has attracted much research as a means to improve AECO sector ecosystem interoperability (Section 2.1.3)while research into Middleware as an alternative approach is lacking.
The Middleware Shared Messaging Service proof-of-concept aims to demonstrate reliable, automated cloud-based ecosystem interoperability with appropriate accessibility across lifecyle stages.
...efficient sustainable design processes requires inputs and outputs that can move between technical applications.
It was reported, depending on industry partner role, that the economic cost of these issues is either difficult to quantify, or their resolution is part of the service offered (Section 3.2.1.1).Correspondingly, and as implied by the Results, while the complexity of interoperability problems in the AECO sector have increased in the past 20 years the significance of the role of digital engineer has grown.No doubt the costs of poor interoperability will also have increased since NIST confirmed impacts on the AECO sector in the U.S. at $15.8 billions annually (Gallaher et al., 2004).
As noted in Section 2.1.5,there is a lack of research evidence and quantified data to support the hypothesis that data loss and errors across a building's lifecycle, especially during the operations stage which accounts for 80% of lifetime costs (Matts, 2022), will have a negative effect on sustainable development.Sustainable development depends on accurate information about materials, safety, logistics, equipment, and performance, based on reliable data about spatial, loading, fire, energy, lighting, heating, cooling, and many other properties.Hence, the economic, social and environmental costs of poor interoperability are presently unknown.
Recommendation 7: The impact of poor interoperability on sustainable development in the AECO sector needs to be better understood through more extensive and thorough research.Provided with accurate information, social and environmental stakeholders would be better informed and able to promote meaningful actions to mitigate the impacts on society and the environment of poor interoperability in the AECO sector.Correspondingly, the AECO sector would be better place to mitigate these impacts.The sector, university researchers and institutions (e.g.Cambridge Institute for Sustainable Leadership (CISL)), social and environmental organisations (e.g.Australian Building Sustainability Association) should assist in providing evidence of the impacts of poor interoperability on sustainable development.

CONCLUSION
This paper examined two research questions by beginning with a review of standards and literature relevant to systems and servers, sustainability and interoperability, plus prior research.Guided by the research questions, we also analysed the results of engagement with industry partners through a survey, semi-structured interview and a focus group meeting.We then evaluated and interpreted the results and made recommendations that aim to improve ecosystem interoperability in the AECO sector.Accordingly, we assert three priorities for improving AECO sector ecosystem interoperability.
Priority 1: A golden thread of data and information exchange, integrated into the ISO 19650 series to ensure accountability for the accuracy and reliability of data and information across the entire building lifecycle, including handover stage.This would be similar to the Building Act (2022), UK, where accountability includes the nomination of 'duty holders' and 'appointed persons' to embed responsibility into the process, thus ensuring at all stages, that data and information is carefully, reliably and consistently managed.
Priority 2: Network-Centric -Middleware & LBD, to improve ecosystem interoperability in the AECO sector with distributed and/or decentralised approaches.Standards, comparative costs, security risks, the costs and benefits to the environment and society should all be key considerations.These approaches should allow objectbased, automated data and information exchanges to flow reliably across lifecycle stages, without loss or errors, and with appropriate accessibility for stakeholders to cloud-based data and information.
Priority 3: openCDE ISO, to be developed promptly from Publicly Available Specification (PAS), DIN SPEC 91391 series, Germany.This will specify that multiple CDEs should be able to mutually exchange data without loss or errors via the concept of an open protocol (openCDE) for the exchange of data between platforms.The openCDE ISO will stimulate novel technological solutions to improve AECO sector ecosystem interoperability and will provide guidance, clarity and reassurance for clients, the sector and software vendors.

Future Work
In future work, we aim to complete a proof-of-concept proposal for a Network-Centric -Middleware, shared messaging service (Section 4.5).This responds to the industry partners' key concern, the requirement for a 'connected CDE' or 'main CDE'.The proof-of-concept is based on DIN SPEC 91391 series, global standards ISO 19650 series (BIM), ISO 16739 series (IFC), and others, and will utilise middleware solutions developed by the authors, plus vendor neutral, open source systems and tools including BIMserver (Beetz et al., 2010), BlenderBIM and IfcOpenShell.
We will also review synergies between Network-Centric -Middleware and LBD approaches, aim to broaden engagement with AECO sector primary stakeholders, continue to advocate for implementation of openBIM and IFC, and extend our research into the impact of poor interoperability in AECO on sustainable development.

Summary
In collaboration with industry partners, our research has improved understanding of interoperability issues faced by the AECO sector.Industry is challenged to provide fixes or workarounds and is subject to disruption when vendors update or change their data models.We assert that a global, standards-based approach is best placed to resolve these challenges and to achieve full interoperability in the AECO sector.
Our proposals contribute to better ecosystem interoperability for AECO sector stakeholders, domains and vendors.They should be of interest where primary stakeholders aim to ensure interoperability across building lifecycles and where accountability for data and information flow is demanded.The proposal should also be of interest for AECO organisations requiring specialised BIM and IFC training and education, and more broadly, for environmental and social stakeholders impacted by the effects of poor AECO interoperability seeking better evidence to support meaningful solutions.Lastly, the proposal for a novel, object-based messaging service should be of interest to stakeholders, domains, and vendors to improve ecosystem interoperability.
Interoperability has been described as the 'backbone' of collaboration, shaped by 'cultural values' and 'contractual relationships' (Grilo and Jardim-Goncalves, 2010).Correspondingly, we believe that improved interoperability will contribute holistically to better collaboration across the AECO sector and will benefit environment and society through the development of digital twins, smart buildings and smart cities.

Figure 1 :
Figure 1: Three methods of data and information exchange in the AECO sector.
The industry partners each have 30 years plus experience and include: a Design & Documentation Manager, GHD (Brisbane), a global multidisciplinary design consultancy; and, an Operations Manager, DBM Vircon (Brisbane), a global digital engineer, servicing client and design consultants across sectors.Responses to open questions reflected their different roles in servicing clients in the AECO sector, delivering various project typologies across domains and disciplines and providing specialist interoperability services.

Figure 2 :
Figure 2: Survey responses and themes auto-coded (NVivo) -larger areas indicate more related terms coded.

Figure 3 :
Figure 3: Transcript themes: auto-coded (NVivo) and manually adjusted -larger areas indicate more related terms coded.

Figure 4 :
Figure 4: Concept map: hierarchy of themes and sub-themes -interpreted and drafted manually by the authors.

Figure 5 :
Figure 5: Sentiments coded to themes by NVivo and manually adjusted to depict positive and negative sentiments of data and information exchange standards and systems -larger areas indicate more related terms coded.

Figure 6 :
Figure 6: Current State of CDE Interactions.

Figure 7 :
Figure 7: Proposed state of CDE and organisational interactions using Network-Centric -Middleware, a shared messaging service with standardised adaptors.
2005Eastman et al. (C.Eastman et al., 2005)reported an innovative DBMS for CIMSteel Integration Standards in the U.S. describing it as, '…a project model repository (PMR) or database implementation' which allowed the management of project data, security of proprietary data, concurrent access, selective collaboration and sharing.In 2010, BIMserver was developed byBeetz and van Berlo (2010)as a research tool and to demonstrate a collaborative, cloud-based, IFC-based, open-source, BIM server environment for AECO team members;

Recommendation 3 :
We recommend that Germany's Publicly Available Specification (PAS), DIN SPEC 91391 series (Section 2.2.1) is promptly developed into a global ISO standard or incorporated intoISO 19650series to provide clarity for the sector and software vendors.DIN SPEC 91391-1 covers CDE solutions applicable for BIM Levels 1-2 while Section 3.13 of the DIN notes that,