INTEROPERABILITY IN AECO AND THE OIL & GAS SECTORS: OBJECT-BASED STANDARDS AND SYSTEMS

SUMMARY: This research proposes recommendations that could improve interoperability in the architecture, engineering, construction and operations (AECO) sector, by connecting domains, building lifecycles, and software systems with each other and the web. The objective has been to identify methods that promote evolution from file-based formats by advancing object-based data exchange solutions. The research design is a mapping of standards and systems that have affected the nature of object-based data exchanges, and which have either been proposed or implemented in AECO and the Oil & Gas sector. This is an approach which allows for the range and diversity of information to be examined. A review of the Oil & Gas sector confirms a norm where object-based, rather than file-based, transactions have shaped data exchange models, formats, use case methodologies, and collaboration mechanisms, thus contributing towards semantic connectivity across its diverse systems. Key research questions address the nature of these sectors, the promise that object-based data exchange offers, and examine recommendations that would improve standards and systems. The paper affirms that measures taken to improve interoperability in the Oil & Gas sector have relevance for the AECO sector, and that better understanding, and recognition of the structure of AECOs interoperability ecosystem is central to effecting lasting and significant change. Thus, we make recommendations that acknowledge the hybrid nature of AECO data exchanges and propose an interoperability ecosystem that connects both distributed and centralised federated models. Improved standards to define application programming interfaces (APIs) and adaptors, based on a modular approach, would be central to this proposal. We also make recommendations to improve use case definitions, and to ensure that semantic connectivity at the object level is scalable to web-based transactions. Finally, we assert that, to realise these changes, the developers and vendors of its systems should recognise and address the AECO sector’s pressing needs and concerns.


INTRODUCTION
The AECO sector is fragmented and comprised mainly of small to medium sized enterprises (SME) which are project, rather than strategically, focused. Though integrated projects do occur, the sectors' workflow mainly consists of systems and processes operating in silos, as noted by Owen (2013, p. 10). Consequently, and unlike other sectors of industry, there is no single organisation with the financial strength or intellectual capability to control software development. The fragmented nature of the AECO sector precludes the development of a single proprietary software system that might integrate data exchanges. Furthermore, it continues to resist such a concept because it would provide a vendor with monopoly control, as noted by Sacks et al. (2018, p. 88, 94). In consequence, as Owen et al. (2010, p. 236) affirm, due to its diversity and complexity, software in the AECO sector frustrates integration between users despite the ambitions of the founders of BIM who recognised the need for interoperability in the sector over 50 years ago.
It was in the late 1970s that Charles Eastman and colleagues at Carnegie-Mellon University, U.S. developed research which led to the concept of Building Information Modelling (BIM), the system which aims to foster interoperability in the AECO sector. In the early 1990s, BIM initiated development of standards defined by the end-users of software applications. The Industry Foundation Class (IFC), a non-proprietary, open standard, emerged in 1995 to facilitate data exchange between proprietary software systems. These data exchanges are filebased, while IFC is an object-based modelling language. Soon after IFCs introduction this dichotomy led to development of BIM servers, or repositories, to better manage data exchanges and transactions at the object level.
Since the inception of IFC in 1995, many of the same interoperability issues in the AECO sector have been reported by researchers and practitioners. Consequently, software applications used every day in the AECO sector are failing to exchange data reliably which translates into poor quality workmanship, compromised teamwork, excessive cost, a waste of resources, and time delays. But, while it is clear that the IFC file-based format needs to evolve, solutions to advance this have had limited success. A recent 'Technical Roadmap' published by buidlingSMART acknowledges the need to transform IFC into an object-based data exchange to accord with exigencies for interoperability between software systems and web-based services (buildingSMART, 2020, p. 10). Thus, the transformation from file-based to object-based data exchange standards, systems and tools has not yet begun, as noted by Afsari, Eastman and Sheldon (2017).
Interoperability issues faced by the AECO sector are similar to those encountered by other sectors which deal with comparably complex data exchanges across project life cycles. Hence, we investigate other sectors' solutions to these problems and the lessons that can be learnt by the AECO sector. The Oil & Gas sector faces similar challenges to the AECO sector due to market fragmentation and the proliferation of vendors' solutions. Researchers from the Centre for Digital Built Britain (cdbb) highlight these similarities and affirm that the Oil & Gas sector is ahead of AECO in its progress towards digitalisation (Lamb, 2018). Thus, our paper examines these common challenges addressed by the Oil & Gas sector.
The AECO sector is already working to align with the Geospatial sector. The Open Geospatial Consortium (OGC) and its members develop standards for the geospatial sector to enable location information and services to be FAIR -Findable, Accessible, Interoperable, Reusable (OGC, 2021). The Integrated Digital Built Environment (IDBE) initiated in 2014 is a joint working group under buildingSMART International (bSI) and the OGC which aims to achieve better software interoperability and data integration in the geospatial and built environment domains (Gilbert et al., 2020). This work has addressed interoperability between modelling standards, IFC, CityGM, InfraGML, LandInfra, GeoSciML, and others (Plume, 2021). The aim of this ongoing work is to facilitate a cycle of reuse between modelled as-built environments and the context that defines new development. As part of the IDBE, the OGC and bSI are also collaborating on standards-based alignment of digital twins, beginning with the definition of alignment concept models.
The AECO sector's workflows and processes have been compared with those of the Manufacturing & Electronics sectors (Gann, 1996). In the AECO sector, the emerging concept of Building Lifecycle Management (BLM) derives its impetus from PLM systems developed in the automobile industry in the 1980s. Several authors promote development of BLM (Vanlande, Nicolle and Cruz, 2008, Malagnino et al., 2017, Di Bicarri et al., 2018, Mangialardi et al., 2018, while Dassault Systèmes provide a PLM solution to the AECO sector that provides a closed integrated, object-based system with full operability between many applications (Doe, 2020, p. 4). However, a key disadvantage of proprietary, closed integrated systems is that their implementation is exclusive to purchasers of the software (Schodek et al., 2005, p. 233). Hence, the BLM concept challenges the desire, consistently expressed by the AECO sector, for user defined, vendor neutral, openly integrated systems which conform to open standards, and for modelling techniques that avoid using a single modelling language (Taylor et al., 2009, buildingSMART, 2020, p. 11, Hub, 2020. Thus, in contrast to AECO and the Oil & Gas sectors, the Manufacturing & Electronics sectors' economic power and long-term working relationships have enabled them to drive the development of proprietary, closed software systems suitable for design, modelling, fabrication and collaboration throughout the product's lifecycle. This has resulted in a small number of proprietary, closed-source PLMs servicing the sector. This paper addresses the proposition that interoperability in the AECO sector can be improved through comprehensive implementation of object-based data exchanges. It does this by examining and comparing standards and systems that have either been proposed or implemented to improve interoperability in both AECO and the Oil & Gas sectors.

Research Design
Firstly, we asked, what can the AECO sector learn from the Oil & Gas sector's implementation of interoperability measures which are focussed on object-based data exchanges? Secondly, can interoperability in the AECO sector be improved by object-based, rather than file-based, data exchanges? Thirdly, what standards and systems are required in the AECO sector to reinforce object-based data exchanges?
In Section 2, we examine the nature of interoperability ecosystems in AECO and the Oil & Gas sectors and their influence on standards and systems. We also briefly compare and contrast these with other industry sectors' interoperability ecosystems. In Section 3, we begin to answer the first research question through a comparative review of standards and systems in AECO and the Oil & Gas sectors, a mapping approach which assists with evaluation of the broad nature of the subject matter and the diverse range of disciplines involved. In Section 4, we examine the second research question by discussing the prevalent data exchange problems and how object-based data exchange standards and specifications can address these problems in the AECO sector. The predominant data exchange standards used in the Oil & Gas sector are object-based, but there are other interoperability issues in the Oil & Gas sector, which are discussed in this section. The third research question is answered in Section 5, where we synthesise the findings and recommendations for object-based data exchange solutions appropriate to the AECO sector. In Section 6, we explore future research avenues and summarise conclusions.

BACKGROUND
In the AECO sector, interoperability 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) In the Oil & Gas sector, a definition of interoperability references systems engineering knowledge, …the capability of two or more entities to exchange items in accordance with a set of rules and mechanisms implemented by an interface in each entity, in order to perform their specified tasks. ((ISO), 2019) These definitions focus on the technological complexity of interoperability, common to all sectors of industry, which require integrated, reliable and scalable methods for exchanging data. In addition to achieving interoperability at the technological level, interoperability needs to be addressed at management level to facilitate collaboration across the entire lifecycle of the asset or building. Methodologies at the management level include open and trusting contractual relationships fostered by partnering, and approaches such as integrated project delivery (IPD), which nurture collaborative workflows and integrated exchanges of information. However, these management level methods which foster collaborative interoperability are excluded from the scope of this research. Instead, it is the reliability and scalability of data exchanges in AECO and the Oil & Gas sectors, influenced by standards and systems, that is the focus of this paper.
In both AECO and the Oil & Gas sectors, standards are being created, published, and used, but fragmentation of the sectors challenges interoperability due to the multitude of bespoke solutions which prohibit adoption of a single sector-wide standard. A typical project lifecycle in both sectors involves collaboration across multi-disciplinary teams using different software tools. Thus, interoperability becomes an essential requirement for seamless data exchange at software levels between diverse applications, where each application may have its own internal data structure. Mappings from each application's internal data structure to standard models, such as IFC for AECO and MIMOSA CCOM for Oil & Gas, facilitate interoperability.
In the Oil & Gas sector, standards define data exchanges which occur between domains and their systems. While in the AECO sector, standards define data exchanges which occur both between domains and their systems via an intermediary system (e.g., IFC BIM server), and between domains and systems (e.g., IFC), as in the Oil & Gas sector. These interoperability ecosystem differences are illustrated below (Figure 1).

Figure 1. Interoperability Ecosystems by Sector.
Both of these ecosystems may be described as 'federated'. In the information technology sector federation refers to the ability of many separate computer resources, such as collections of data, to be searched at the same time, which better describes the Oil & Gas sector's distributed federated approach. But, more generally, the term federated refers to a group of organisations joined to form a larger organisation, which better describes the AECO sector's centralised federated approach.

STANDARDS & SYSTEMS
The following review examines standards and systems that address the interoperability of data exchanges in AECO and the Oil & Gas sectors. Though many national and organisational standards bodies influence these sectors, we have focused on the principal generic and international standards and specifications published by bSI and MIMOSA (Figure 2), as described in the sub-sections below.

buildingSMART International (bSI)
In the AECO sector, the governance of standards and guidelines is the responsibility of bSI, a not-for-profit, open, neutral organisation dependent on global collaboration between discipline and industry experts (2021b). With the development of BIM, the AECO sector acknowledged that the reliability of data exchanges should be determined primarily by user-defined exchange standards and use cases. Based on this approach, in 2005 bSI began to address construction industry concerns by developing 'smart model-based collaboration tools', some also defined by other international standards, including, • IFC (Industry Foundation Class, ISO 16739-1:2018), a non-proprietary, open standard, file-based method of transaction. • IDM (Information Delivery Manual, ISO 29481-1:2016), the standard for defining use cases and workflow processes, plus ISO 19650 series for organising BIM workflows. • MVD (Model View Definition), though IFC is the basis for full interoperability, each use case needs precise definition with the IDM, which is mapped to the MVD by information technology experts. bSI release the MVD to the software vendor, with testing and certification of implementations following. • BCF (Building information modelling Collaboration Format), enables the sending of model mark-ups, clash reports and general comments between team members. • bSDD (bSI Data Dictionary), is an online service that hosts classifications and their properties, allowed values, units and translations. The bSDD allows linking between all the content inside the database and is based on ISO 12006-3 for Industry Foundation Dictionaries (IFD).
To facilitate interoperability, bSI asserts its commitment to 'sharable projects' and 'seamless collaboration' across domains and building lifecycles via the concept of openBIM. In their 'Technical Roadmap -Getting Ready for the Future', ('Technical Roadmap'), bSI identify the following key requirements to drive these changes between 2020-2023 (buildingSMART, 2020, pp. 10, 17), • Methodologies that have equivalence in multiple, modern computer interpretable languages e.g., XSD, OWL and JSON. • Modularity to facilitate separation of responsibilities, and to create additional domains (e.g., via use cases) and extensions. • Standardised Application Programming Interfaces (API) with a data driven approach to meet the requirements of Digital Twins, Smart Buildings and Smart Cities. • Workflow standards that rationalise the IDM, ISO 19650-1:2018 and other workflow and process standards which are to be defined as a new machine-readable Information Delivery Specification (IDS).

MIMOSA
In the Oil & Gas sector, MIMOSA is a not-for-profit industry trade association which develops and encourages adoption of open, supplier-neutral information technology (IT) and information management (IM) standards and specifications to enable digitalisation and interoperability for asset life-cycle management. The MIMOSA solutions process seeks to avoid reinvention by leveraging existing standards such as ISA-95, ISO 8000, ISO 15926, and ISO 18435, which are part of a complex mosaic of existing and emerging standards, each developed with a different focus. To achieve 'system of systems' interoperability these standards are used together in a repeatable and scalable manner via technical specification ISO/TS 18101-1:2019 ((ISO), 2019), published by the ISO Technical Committee 184/Working Group 6. This promotes the OIIE (Open Industrial Interoperability Ecosystem) specification as a portfolio approach to interoperability which uses existing standards in a complementary manner to achieve system of systems interoperability in the Oil & Gas, petrochemical, power generation, public utilities and other asset-intensive industries. Unlike other technical specifications, ISO/TS 18101-1:2019 is not intended to develop new standards. Instead, it incorporates the use of a standardised connectivity architecture and a use case architecture to describe a supplier-neutral, open, industrial digital ecosystem and the interoperability requirements of standardised industry use cases.
MIMOSA also leads the OpenO&M initiative, which is an open, collaborative effort to bring diverse groups of standards and best practice publishing organisations, such as ISA, MESA, Open Applications Group, Inc. (OAGi), and the Open Platform Communications (OPC) Foundation in an effort to harmonise the standards used for the exchange of data and the associated context, with the focus on operations and maintenance stage. Each of these organisations bring the subject matter expertise in their respective fields. For example, ISA (International Society of Automation) publishes standards related to instrumentation and automation, and MESA (Manufacturing Enterprise Solutions Association) International focusses on best practice around the use of IT in manufacturing. The scope of OAGi is broader since it develops standards for integrating applications and businesses that can be utilised across industries, while the OPC foundation is an industry consortium that creates communication standards for automation devices and systems.
To achieve standards-based interoperability in the asset-intensive industries MIMOSA collaborates with these standards organisations to manage the development, validation and maintenance of the OIIE specification (MIMOSA, 2021) under the OpenO&M initiative. All standards and specifications included in the OIIE are licensed by their respective organisations and are validated by the OIIE OGI Pilot (Oil & Gas Interoperability Pilot) to work with each other, and to support standardised industry use cases.
In addition to MIMOSA, there are other standards bodies and industry consortiums which publish and maintain standards, specifications and industry best practice for the Oil & Gas sector, such as the International Association of Oil & Gas Producers (IOGP), Capital Facilities Information Handover Specification (CFIHOS) and POSC Caesar Association (PCA). The IOGP identify and share best practice around health, safety, environment and other related aspects for the Oil & Gas industry professionals. CFIHOS is one of the IOGP projects (JIP 36) that produce information handover specifications such that necessary information needed to operate, maintain and decommission a facility is exchanges, specifically for process and energy sectors. Energistics is an industry consortium that publish standards for data definition, handling, storage and exchange specifically related to upstream oil and natural gas industry. PCA promotes and publishes open specifications for enabling interoperability. The major standard initiated and promoted by PCA is ISO 15926, which is about integration of lifecycle data for process plants, with focus on Oil & Gas production facilities.

AECO Sector
• IFC (Industry Foundation Class) is a non-proprietary, open, object-based file format specification, defined by ISO 16739-1:2018 ((ISO), 2018) intended to describe architectural, building and construction industry data. The development of IFC began concurrently with the founding of the Industry Alliance for Interoperability (IAI) in 1994, initially a consortium of 12 U.S. companies initially advising on developing a set of C++ classes to support integrated application development. In 1996 the consortium became an international effort and changed its name to the International Alliance for Interoperability. IFC's evolution has continued under bSI since 2005. IFC supports different encodings by defining multiple file formats to exchange data, including SPF (STEP Physical File), XML, and ZIP. IFC data exchange is currently considered the most promising solution for achieving reliable and scalable interoperability in the AECO sector, as asserted in a recent report by the UK's BIM Interoperability Expert Group (BIEG) (Hub, 2020). • COBie is an information exchange specification for the life-cycle capture and delivery of information needed by facility managers. Developed in 2007 by E. William East, for the U.S. Army Corps of Engineers, it specifies the minimum information set needed to operate and maintain buildings. Thus, COBie is the information exchange between the delivery team and client. It was published in 2009 by bSI as 'Basic FM Handover IFC 2.3 MVD ' (buildingSMART, 2021c). Unlike other MVDs, it has an analogue spreadsheet representation which effectively replicates the IFC schema, or it can be delivered digitally in IFC format (cdbb, 2021). COBie links information about building systems and assets to the spaces or locations from where they can be accessed. Over 20 Commercial-off-the-Shelf Software (COTS) products support COBie which allows it to be used on projects regardless of size and technological sophistication (NatSpec, 2021).

Oil & Gas Sector
• IEC 62714 AutomationML (Automation Markup Language) is an open standard based on XML for storage and exchange of plant engineering information. • IEC 62264 B2MML (Business to manufacturing Markup Language) and IEC 61512 Batch ML (Batch Markup Language) published by MESA International are XML-based models that define an exchange format for data conforming to ANSI/ISA-95 and ANSI/ISA-88 information models respectively across enterprise and control systems. • ISO 15926 is a standard used for representation and exchange of data supporting the life cycle of industrial plants which includes the engineering, construction, and maintenance phases; with a focus on information handover. • IEC 62541 OPC UA (Open Platform Communications, Unified Architecture), is an object-based machine-to-machine communication protocol for industrial automation devices and systems developed by OPC Foundation. • MIMOSA CCOM (Common Conceptual Object Model) serves as an information model for the exchange of asset life cycle information, including engineering, asset, configuration, operation and condition data, required for the operation and maintenance of plants and complex facilities. In addition, CCOM can be used to provide the contextual basis for defining and maintaining Digital Twins and for performing Big Data Analytics. The mission of CCOM is to facilitate interoperability between systems by allowing them to exchange data through adaptors. • MTConnect is a manufacturing standard providing XML based exchange format for exchanging data between shop-floor and software applications. • PRODML is a set of XML based standards and a data exchange format used in the upstream Oil & Gas sector for supporting workflows in production operations, published by Energistics. • IEC 62424 CAEX (Computer Aided Engineering Exchange) is an object-oriented XML based exchange format for storing hierarchical structure of plants, documents, products etc. and is primarily used for exchanging data between process engineering and process control engineering tools.

Use Cases
To support interoperability across any industry, it is recognised that a consistent method for describing and specifying different sets of interactions, or use cases, is required. By describing use cases consistently, specific interoperability concerns can be addressed in a prioritised manner so that participants know what to expect when taking part in an interaction within the digital ecosystem.

buildingSMART Use Cases
The bSI have developed ISO 29481-1:2010 to define the methodology for capturing use cases and specifying processes and information workflows using Information Delivery Manuals (IDMs). These consist of use case process definitions and exchange requirements. The use case captures a brief description, the objective, benefits and metadata of similar disciplines and lifecycle stages. The process definition includes the services to be performed and the results to be achieved for each stage added for the use case and can be expressed as a process map, interaction map or transaction map, using the Business Process Modelling Notation (BPMN) (buildingSMART, 2021e). The exchange requirements define model-based information in non-technical format, which is then translated to a technical specification of the exchange requirements via the Model View Definition (MVD). The MVD is a subset of the IFC schema which fulfills the exchange requirements of a use case. The MVD becomes the basis for the import and export capability of software systems participating in the information exchange for a certain use case.
By 2010, it was claimed that the IFC schema's 'breadth and flexibility… leaves room for errors', and that it had made no significant impact on interoperability (Eastman et al., 2010). A key reason for these errors were use cases that did not clearly define information exchange interactions between users. In the study noted, the authors developed more detailed procedures to capture use cases and for defining the IDM. Thus, the Exchange Model (EM) and Exchange Object (EO) tied specification of the IDM to a more accurate MVD, as noted by Eastman et al. (2010). In this same study, the authors were concerned that many IDMs would be needed, 'possibly several hundred' (Eastman et al., 2010, p. 33). Since then, it has been asserted that IDMs are difficult to search, share or reuse for the following reasons (Kahyun and Lee, 2018, p. 2), • Development process is complex and laborious, demanding substantial time and cost.
• Lack of a standard format for exchanging information between an IDM and an MVD, e.g., XML schema.
• Tools are needed to integrate the development process, e.g., automated quality checks for the IDM and the MVD.
• Difficult to share and reuse IDMs and MVDs without shared servers and more administrators.
The MVD requires that software supporting IFC exchange implement a subset of the IFC schema with additional restrictions applied. These MVDs also define the conformance level expected of software implementations. But MVDs are not interchangeable and do not guarantee interoperability between MVDs themselves. Also, as a subset of IFC, they can only be revised if the whole schema is changed.

OIIE Use Case Architecture
In 2007, representatives from the Oil & Gas and Petrochemical industries participated in an OpenO&M End-User Advisory Group with the aim of identifying the highest value use cases, matched to interoperability scenarios, for organisations to meet their business objectives (OpenO&M, 2020). These use cases are documented using the OIIE Use Case Architecture and are incrementally extended to incorporate new functionality. Each use case is validated by the OIIE OGI Pilot while new use cases are included based on guidance from industry partners (MIMOSA, 2020).
The OIIE Use Case Architecture identifies four components for describing use cases in a decomposable way: Use Cases; Scenarios; Events; and User Stories. Use Cases describe common interactions and context to achieve an interoperability goal and are decomposed into Scenarios. Each Scenario provides additional details and requirements on how to achieve an interaction based on a specific group of Events. The Events describe specific message exchanges and their requirements while being general enough to be reused and support different realisations across different protocols and data formats. Finally, these three components are tied together by User Stories, which abstract from the underlying components to provide a higher-level, graphical overview of interactions and to connect Use Cases in a logical flow.

BCF
The BCF (Building information modelling Collaboration Format) allows different BIM applications to communicate an 'issue' between project collaborators, alongside IFC data that has already been shared. Each BCF 'issue' is registered with a Globally Unique Identifier (GUID) confirming the status of the model and the domain users' responsibilities. It enables workflows which transfer XML data from captured views, either by emailed .bcfzip file exchange between team members, or via a web-based exchange using the RESTful server hub (buildingSMART, 2021a).
BCFier is a set of plugins and standalone applications that handle BCF and integrate directly with some BIM tools, including Autodesk's Revit, enabling specific data sets to facilitate coordination issues ( Van Berlo, Natrop andKorpershoek, 2017, BCFier, 2021). In early development work BIMserver successfully used modular, reusable components to test a BCF workflow, as recorded by van Berlo and Krijnen (2014).

ISBM
In the Oil & Gas sector, the OpenO&M ISBM specification is an open specification that provides a vendor-neutral interface to the communication infrastructure of the OIIE Architecture. It is an open, supplier-neutral standard that can in theory be used by any industry, as it allows the transmission of any information model, including MIMOSA CCOM, ISO 15926, MESA B2MML and others. ISBM addresses a typical IT environment where a federation of systems is implemented from multiple software vendors that work together to support business processes by providing a standard interface. ISBM specification defines a SOAP (Simple Object Access Protocol) Web Service and a HTTP/JSON REST implementation of the ISA-95.00.06 Messaging Service Model (MSM). ISBM offers further interoperability via application-to-application communications by exposing a single, standardised interface, instead of a custom-built interface, for every version and format of message exchange systems.
Unlike the BCF REST API, which is used primarily for exchanging BCF issues between software applications, ISBM web-services provide a wide range of interfaces to act as the complete communication backbone of an ecosystem. Though there is no corresponding open specification or standard used in the AECO sector to support intra-enterprise and inter-enterprise collaborative communication, BIM servers provide a similarly neutral interface for object-based data exchanges.

bSDD
The buildingSMART Data Dictionary (bSDD) is a library that contains objects and their properties for the building and construction industry which links concepts with similar meaning in different classifications, contexts and languages. The bSDD is used to search, identify, and share objects and their properties and is available as an open REST API which can be searched for concepts and their relationships in different classifications systems, including IFC. Each concept in bSDD is assigned a GUID which serves as a unique, language independent serial number. The use of bSDD can significantly improve communication in the AECO sector by facilitating unification of technical terms regardless of the underlying language. It is a service, rather than a standard, that will play a significant role in the future with the implementation of multiple use cases in the AECO sector, and it will also facilitate the compliance checking of Product Data Templates (PDTs) based on classifications derived from bSDD (buildingSMART, 2020, p. 23).

RDL
The use of Reference Data Libraries (RDLs) is vital to achieve interoperability between systems within and across an enterprise because it enables all partners to have a common understanding of the data being exchanged. The OIIE utilises mappings to multiple external RDLs published by various organisations including, ISO 15926-4, CFIHOS RDL, ECCMA eOTD, IEC CDD and Energistics UOM, in addition to MIMOSA CCOM RDL which is the system of record for any managed reference data.
MIMOSA defines the OpenO&M Web Service Common Interoperability Registry (ws-CIR) specification which provides a standards-based, vendor-neutral approach for the construction of an object registration server. This specification supports a harmonised and standardised lookup of locally unique identifiers for an identical object, including data dictionary classifications and attributes, used in multiple information systems. This can be used, not only for linking to RDL, but for mapping local application identifiers into shared identifiers for non-RDL elements of a model. Like bSDD, the ws-CIR attaches a Universally Unique Identifier (UUID) to each object to ensure its global uniqueness.

Data Exchange Problems
With the increasing complexity of AECO projects, the success of interoperability depends on the reliability and scalability of data exchanges. Before scalability can be addressed, reliability needs to improve, but IFC has often been defective in its ability to deliver timely and error free data exchanges. In the U.S. in 2004, the wider costs of poor interoperability caused by delay, avoidance and mitigation were estimated to be $15.8BN USD (Gallaher et al., 2004). 3. Visualisation-level; enables reliable representation of models being exchanged 4. Semantic-level; allows common meaning of models exchanged to be understood.
It was at levels 3 and 4 that problems occurred. Visualisation issues included different domains' choices of colour based on actual appearance (domain: architect), regulatory coding and type of object or material, e.g., concrete slab and supporting beam (domain: quantity surveyor). Semantic misunderstanding could have an even wider impact and could occur due to the lack of preservation of unique object identifiers (e.g., GUIDs), which then affect versioning and change-tracking functionality. Semantic issues could also arise between a model used by an analysis tool which reads encoded objects differently to the original model's software, e.g., steel grade may be encoded either as an object description or within the material type. The International Framework for Dictionaries (IFD) addresses some of these issues. Semantic issues can also affect coverage of a domain by an IFC model, e.g., an architect might model an upstand beam as a wall element, however a quantity surveyor's analysis tool may not recognise this difference; the solution here is for better modelling conventions and guidelines.

File-based Transactions
A detailed examination by Lee et al (2014, p. 211) confirmed the following file-based transaction issues, 1. File-based data exchange or file-based data storage does not allow object-level data queries. 2. Extracting a subset of a model is not possible without using additional tools.
3. It is difficult to track changes in the histories of models. 4. Different access privileges cannot be assigned to different users based on type of data, because the accessibility of data can only be controlled at file level, not at object level.
Though IFC is an object-based 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. By contrast, an object-based transaction parses and saves a model at object level, e.g., wall, column, or beam. A transaction is defined as, …a unit sequence of reading, writing, and creating data… (Sacks et al., 2018, p. 113) An object-based transaction does not usually require a full model exchange because it primarily comprises an incremental update of an object and its parameters, where the amount of data is small compared to an equivalent set of files, as explained by Sacks et al. (2018, p. 376). The same authors suggest that defective interoperability continues to be 'a serious impediment to collaborative design' largely due to the immaturity of the interoperability tools employed, which are a result of poorly defined standards and the lack of available AECO sector funding to change the status quo (Sacks et al., 2018, p. 386).

Conformance and Interoperability Testing
The literature reports that current conformance testing used in the AECO sector for certifying the ability of BIM software tools to interoperate with data exchange standards (e.g., IFC, COBie) is not reliable (Lipman, Palmer and Palacios, 2011, Jabin, Dimyadi and Amor, 2019, Kiviniemi, 2008. The conformance tests are conducted by buildingSMART for IFC and the U.S. National Institute of Building Sciences for COBie. These tests check mappings of the inherent representation of data in the software tools with the exchange standard and vice versa. The list of successfully mapped attributes is produced as a result of the conformance test and the software tool is marked as certified software (e.g., IFC 4 certified). Researchers have argued that these conformance tests are testing the ability to exchange information rather than measuring the quality of information exchanged (Jabin, Dimyadi and Amor, 2019). The true measure of interoperability between systems is the ability to effectively use the exchanged information and hence the quality and accuracy of information exchanged is vital. Thus, the conformance tests do not accurately convey the real capability of a software tool, leading to false expectations for end users who expect a certified software tool to provide completely error-free and lossless information exchange. This problem has far reaching consequences because end-users are unaware of the underlying unreliable information exchange when importing and exporting data (Kiviniemi, 2008).

Data loss during import and export
Multi-disciplinary collaboration on building projects requires one-to-one interactions between heterogeneous software tools, where each discipline has its own domain knowledge and uses disparate software tools to implement tasks. Thus, interoperability relies on mappings between the internal schema of these diverse software tools and the IFC models which imported and exported between them. Interoperability issues arises when these mappings go wrong due to human error, lack of understanding and knowledge, or where domain-specific objects are involved which cannot be accurately represented and mapped into the software of other domains (Lai and Deng, 2018). Recent testing of IFC data exchanges between software applications confirms that data loss and errors are a persistent and continuing problem. For example, De Gaetani et al (2020, p. 13) noted that interoperability was dependent on the following, 1. The capability of the software developer's IFC import/export translators.
2. The configuration of the IFC file.
3. The range of data object types exchanged.
In this case the authors tested IFC import and export capability based on a sample BIM model and modelling software by Tekla Structures and Edificus, IFC viewers by usBIM and Solibri Model Checker, and project management software by Autodesk Navisworks, Bently Synchro Pro and Microsoft Project. All of the data exchanges resulted in some errors and data loss and of the 16 elements, 1-3 geometrical, 0-16 material, and 2-16 phase elements were affected, or no data was exchanged, between pairs of software applications.
A study by Jeong et al (2007, p. 1) benchmarked data interoperability between architect and precast fabricator. Based on proprietary architectural software, Autodesk Revit, Graphisoft ArchiCAD, Bentley Microstation, and Digital Project, exported IFC files were checked before being imported into engineering software Structureworks and Tekla Structure. Results indicated broad differences between these applications' IFC files of the same building model, and the authors concluded that tighter BIM standards for defining IFC objects' relationship with building elements and domains were required. Solutions suggested by the authors included development of an IDM for precast architectural facades.
In other related research, Lee (2011, p. 5) created product models in Autodesk Revit, Bentley Triforma, and Tekla Structures and exported each to IFC format. The intersections of pairs of data sets were compared revealing that, of 66 exchangeable entities, between 5-13 entities were not exchanged between pairs. Lee noted four IFC data exchange issues, 1. Incomplete coverage of a data model, or exchange format, e.g., an IFC data model might exclude definition of a reinforcing bar. 2. Translator problems; non-native file imports, and native file exports lack development guidelines (N.B. bSI's IDMs were a response to this issue). 3. System bugs. 4. Software domain problems, e.g., an application may not be able to read structural load information.
The author concluded that the common problems were lack of semantic understanding between applications about what could and could not be exchanged, and poor definition of exchangeable sets of information between different applications. For example, if there is no semantic interconnectivity between applications there cannot be 'complete lossless data exchange.' Solutions suggested included better data dictionaries, and tools that supported mapping between 'homonyms and synonyms'.

Data Exchange Solutions
It was the structural organisation of the AECO sector, as described in section 2 which resulted in centralised federation where design, engineering, construction, and operations models are merged into a federated model within a centralised server. This approach allowed for the storage, management and coordination of combined data, while changes to the digital models were made by the distributed AECO organisations. Authors have described BIM servers object-based exchanges, which allow this coordination of complex data flows, as an evolution from file-based data exchanges (Sacks et al., 2018, p. 113). Servers object-based data management allows querying, transfer, updating, and the partitioning and grouping of model data to support many software applications, while server updates are limited to objects actually modified, thus reducing the file transfer size and the transaction time of the update.
Vendor-neutral BIM servers only became possible from 1997 with the introduction of IFC (Sacks et al., 2018, p. 122

Proprietary BIM servers include web-based Graphisoft BIM Server and cloud-based Graphisoft BIMcloud,
Graphisoft BIM Server is one of the first major BIM design platforms with a backend database whose unit of management is objects rather than files. (Sacks et al., 2018, p. 123) Dassault's 3D Experience includes a proprietary local or cloud-based server plus many applications for changing the stored data. As described in section 1, these PLMs emerged in the manufacturing and electronics sector. A key difference between Dassault's PLM and BIM Servers is that the former implement a 'single source of truth' via a shared model stored in the database, accessible by all project contributors (Systèmes, 2014). However, if they are to avoid the same interoperability challenges of local BIM servers, authors note that cloud-based servers require open standards that define 'network based data transmission' protocols (Afsari, Eastman and Shelden, 2017, p. 189).
An alternative approach to cloud-based interoperability was Google X's Flux IO project 2015-2017 which exchanged object-based data rather than files by using adaptors or plug-ins for a limited range of proprietary software applications. Flux IO included a 'data interchange hub' for sharing project design, analysis and schedules (Afsari, Eastman and Shelden, 2016, p. 908).
The premise for the AECO sector has been that BIM interoperability is achievable using vendor-neutral or proprietary BIM servers' object-based capabilities. However, the reality is that direct or manual data exchanges between proprietary systems are still common, as noted by Day, Gasparri and Aitchison (2019, p. 5), while data exchanges between proprietary systems and industry preferred, vendor neutral servers is hampered by the same IFC problems noted in section 4.1.1. Therefore, the goal of a centralised federated BIM model with full interoperability remains elusive.

Data Exchange Problems
Challenges affecting data exchange in the Oil & Gas sector are similar to those faced by other industries, including the need for lossless and automated data exchange in order to mitigate the substantial costs caused by inefficient and error-prone data exchanges. Many engineering workflows in the Oil & Gas sector are multi-disciplinary, requiring diverse and specialised software tools which increases dependency on the reliability of each other's outputs. Thus, as noted by Fillinger et al. (2019, p. 265), prominent data exchange issues facing the Oil & Gas sector include the following, • The need for lossless format conversions when exchanging data across diverse systems.
• The use of unstructured document-based data exchange formats, e.g., PDF, Excel, and Word, as the primary means of data exchange. • The lack of agreement on use and management of common reference data leading to inconsistencies across systems. • The need for standardised specification and management of information exchanges.
• The lack of maturity in existing reference standards as no single standard provides the required breadth and depth. • Lock-in to proprietary software systems leading to high switching costs due to lack of standardisation.
These issues have been a major hindrance to achieving interoperability across the ecosystem of the Oil & Gas sector.

Data Exchange Solutions
In the Oil & Gas sector, multiple data models and exchange protocols are implemented to achieve information exchange across systems. The most prominent ones are listed in Section 3.2.2. Additionally, other initiatives include CFIHOS (Capital Facilities Information Handover Specification) for process industries, which does not define an exchange model itself, but rather the contractual means of specifying handover requirements; and DEXPI (Data Exchange in Process Industry) which has taken over the maintenance of an exchange format (Proteus XML) for Process & Instrumentation Diagrams (P&IDs).
In the Oil & Gas sector, object-based, rather than file-based, exchanges have been the primary method of data exchange, with consequently fewer problems associated with AECO's file-based data exchanges discussed in Section 4.1.1. There have been many attempts to standardise the exchange of data for specific purposes with relevance to particular sets of stakeholders, which arises due to vertical separation between upstream, midstream, and downstream sectors. There is also horizontal separation within each vertical segment which is divided between engineering, procurement and construction (EPC) contracts and the owner/operators of a plant or facility.
Unlike the AECO sector, where IFC is the accepted neutral exchange standard, the Oil & Gas sector lacks the existence and use of any one standard data model or exchange format. Inability to reach consensus around this issue arose because the Oil & Gas sector is part of a complex group of asset intensive industries including petrochemical, power generation, and public utilities, all of which share supply chain partners. However, to mitigate interoperability issues across these industries' diverse software tools, systems and exchange standards, the need for 'a supplier neutral industrial digital ecosystem' was recognised by ISO/TS 18101-1, a document which defines requirements, specifications and guidance for a supplier-neutral, industrial digital ecosystem ((ISO), 2019).
To cope with the multitude of diverse and specialised software tools, an organised approach was suggested where standards were applied based on requirements and in accordance with governance by the industries (Chung, Carnahan and delaHostria, 2015). The objective, of utilising a portfolio of existing standards for realising interoperability in the asset-intensive industries, was recognised by ISO Technical Committee 184/Working Group 6, which published technical specification ISO/TS 18101-1:2019 introducing the OIIE framework, as explained above in section 3.1.2.
By adopting object-based concepts such as inheritance, CCOM provides a cleaner and more flexible model for Enterprise Application Integration (Mathew et al., 2012a). CCOM also provides a canonical XML representation of the object model that allows any type of CCOM object to be identified at the root of a data exchange, or at their position in the object hierarchy. This approach allows the object of interest to be the focus of an exchange regardless of the context in which it might appear, for example in asset or equipment hierarchies. The top-level objects then refer to their context and other objects. Moreover, CCOM allows multiple such hierarchies e.g., functional or physical breakdown structures, logical connections or physical connections such as electrical or logistical. These can be overlaid onto the objects independently of one another. Other aspects of CCOM that support object-based data exchanges in a distributed federated environment are, • Immutable and universally unique identifiers (UUID standard, ISO/IEC 9834-8:2008) for each object.
• Ownership and change data for each object (i.e., the system of record, when the object was modified last, and who made the modification). • Optional inclusion of related objects and data elements so that only the information that has changed need be included. (supports event-driven updates).

DISCUSSION & RECOMMENDATIONS
In the following section we address our remaining research question; what standards and systems are required in the AECO sector to reinforce object-based data exchanges? We also expand the discussion to include recommendations that foster web-based semantic connectivity, a prescient and logical progression if object-based data exchanges are implemented.
The AECO sector and bSI both recognise the need for object-based data exchanges to facilitate interoperability. Though some of its components have been identified, we believe that a holistic strategy is needed for implementing interoperability across software systems, domains, building lifecycles and the web. In the Oil & Gas sector, a distributed federated strategy across proprietary software systems was identified as a way to foster the required levels of interoperability. This was prompted and necessitated by the diversity of standards governing the sector. Hence, the OIIE Specification and ISO 18101 promote a supplier and vendor neutral specification which federates existing standards into a coherent ecosystem where each standard provides value in the domains in which they were defined while connecting domains.

An Interoperability Ecosystem
Degrees of collaboration and interoperability in the AECO sector are expressed as maturity levels ranging from level 0 to 3 (NBS, 2014). For example: BIM level 0 equals 'no collaboration' where 2D CAD drafting and manual processes are used; BIM level 1 equals 'partial collaboration', where 2D and 3D CAD information is shared between project members; BIM level 2 equals 'full collaboration' where the focus is on the sharing of information among participants spanning the entire lifecycle of the building. The BIM Framework, UK now supersedes BIM Level 2, as BS 1192 has transitioned to ISO 19650 which also incorporates the concept of a common data environment (CDE). UK BIM Alliance (cdbb, bSI) were responsible for this development between 2016-20, based on Government policy.
To achieve BIM level 3, full interoperability for the CDE, AECO needs to develop an Interoperability Ecosystem in which collaboration between all participants is supported by systems that can interoperate to achieve well defined goals. The key to such an interoperable ecosystem is a standards-based approach leveraging agreed data exchange formats for core data exchange tasks, such as IFC in AECO and CCOM in Oil & Gas, as well as other supporting data exchange standards and component specifications to meet the required functionality.
The exchanges of data that occur within an Interoperability Ecosystem are defined by the nature of the relationships between organisations and systems within these sectors. The means by which these data exchanges are supported can be implemented in three ways: 1. Point-to-point (1-to-1): links between proprietary software applications using adaptors and APIs, that may be standards based or use proprietary APIs provided by the target system. 2. Hub-and-spoke (many-to-1): a single centralised server to which each software application communicates; we identify two subtypes of this approach as relevant to the AECO and other sectors, a. A centralised federated server which collects and manages federated models, e.g. via IFC BIM server. b. A single shared model, or single source of truth, e.g. PLM systems in which proprietary systems provide a single model, though Sacks et al. (2018, p. 89) consider this concept 'practically impossible' for the AECO sector 3. Network-centric (1-to-many): shared messaging service, or middleware, for supporting distributed communication and federation, a. Standardised adaptors and APIs provide access to the ecosystem and data exchanges between the diverse array of applications and systems that participate in the ecosystem.
In the Oil & Gas sector, the distributed nature of engineering, operations, maintenance (OEM), service and analytics providers, across the asset life cycle emphasises the need for a network-centric model (as 3. above), defined by the OIIE specification/ISO 18101. The OIIE also includes components to manage the distributed federated model (2a. above, partly), but network-centric communication (as 3. above) is preferred. Such a model also encourages object-oriented and event-driven data exchanges.
The structural nature and desires of the AECO sector, as described in section 1, are of a similarly distributed nature where the addition of centralised BIM servers also provides value in federating the developed models throughout the lifecycle. The imperative to find a solution is noted by Turk (2020, p. 8) who suggests that a collaborative framework is needed which can accommodate and interoperate with new systems, formats and processes in a plug and play fashion.
Therefore, we propose the hybrid management of distributed and centralised federated models (2a) by leveraging the network-centric model (3). The network-central model supports the distributed nature of the organisations, their interactions, and the changes to models. Moreover, it does not preclude a centralised, federated model, but rather supports the simultaneous update of the federated model by incorporating it, through a BIM server for example, as an application in the ecosystem. This hybrid ecosystem approach is illustrated in Figure 3, which could provide the platform for Smart Buildings, Smart Cities, and Digital Twins.
Recommendation 1: A hybrid Interoperability Ecosystem approach would ensure reliability by addressing the requirement for integrated standards as an essential component in the implementation of object-based data exchanges and transactions and would leverage, • A network-centric communication model to support distributed information exchanges as well as centralised, federated models and model management.
• Existing and, as necessary, new Adaptor and API standards and systems supporting the mapping, translation, and management of application data into object-based IFC data exchanges (and other standards as appropriate). • Standards and specifications for ecosystem management.
• Standardised processes for describing the object-based, and event-driven, interactions in an ecosystem to achieve common/shared goals. • Standards and systems which utilise transaction and web-based data transmission protocols.

5.2
Adapter & API standards and systems

Adapters & Modularity
Currently, in the AECO sector, customised, proprietary API systems are available. Trimble Connect provide a cloud-based, data exchange server with connections between a limited range of proprietary software systems (Trimble, 2021), and Autodesk's Forge assists development of APIs by certified partners or 'Systems Integrators' (Autodesk, 2021). Also, Speckle have developed an API delivered via GraphQL creating a comprehensive set of connectors to embed in design and analysis software to exchange geometry and data in a neutral, open format, cloud-based, 3D viewer (Speckle, 2021). Though not-for-profit, and representing a broad array of AECO industry partners, the Open Design Alliance (ODA) similarly provides software development kits (SDK), which include APIs, and rules for developing software, based on IFC standards developed by bSI (Alliance, 2021).
Correspondingly, in the Oil & Gas sector, proprietary APIs are available and implemented, but MIMOSA strongly advocates the use of standardised APIs to ensure interoperability across a range of software vendors' and suppliers' systems. In the OIIE framework, core standards and specifications define standardised APIs and methods of data exchange, leaving responsibility for the details of individual components to the software vendors and suppliers (Kaur et al., 2018, p. 6). This modular approach encourages COTS software vendors to provide OIIE compliant adaptors, enabling plug-and-play between heterogenous systems and software. With the OIIE approach, modularity allows software vendors to provide compliant adaptors facilitated by object-based data transformations and mappings (Grossmann et al., 2013).
Presently, in the AECO sector, proprietary software vendor's applications are required to implement a subset of, rather than the full, IFC schema. These subsets are the MVDs, which also define the conformance level expected of software vendors' implementations. Adaptors developed by vendors from these MVDs have file-based IFC export and import functionality for an MVD subset isolated from the full IFC schema. In the 'Technical Roadmap', (2020) bSI have noted that improved modularity and reuse would improve the ability to develop adaptors for better defined multiple subsets and attain higher conformance levels. Such modularity and reuse is more effectively realised at object-level with clear requirements, as mappings and transformations are typically object-based definitions, allowing for the separation of mappings into smaller, more understandable, reusable, and maintainable partial transactions.
For example, MIMOSA CCOM supports lightweight incremental updates where the inclusion of related objects and data elements is optional thus exchanging only the information that was last changed. This is supported by the use of immutable and universally unique identifiers (UUID standard, ISO/IEC 9834-8:2008) for each object, which can be tracked and mapped to internal identifiers where necessary.
In the AECO sector, bSI have outlined plans to improve modularity and object identification in IFC version 5 (Berlo et al., 2021). However, legacy issues due to current versions of the standard will remain until new standards are complete and their adoption becomes the norm. In the short term, the implementation of interim methods and frameworks may help to resolve modularity and adaptor issues, while supporting eventual migration to new standards in the longer term.
Acknowledging the clear need for an object-based approach, and to achieve semantic connectivity bSI are developing openCDE (Connected Data Environment) API standard (buildingSMART, 2021d). We propose that this approach, developed using object-based IFC modelling language and situated within the standards and systems of the Interoperability Ecosystem (see Recommendation 1), prioritises the need for modular adaptors for proprietary systems. This would further enable subsequent data exchanges with servers, and the transactions within them, to be reliable and scalable.

Recommendation 2:
In recognition of the AECO sector's dual means of exchanging data, either directly between systems or via a federated server, openCDE should use standardised IFC adaptors, event-driven and object-level, within the context of the Interoperability Ecosystem and its network-centric model. Furthermore, we endorse a modular approach to the development of adaptor and API standards, as proposed in the 'Technical Roadmap' (buildingSMART, 2020, pp. 17), as this would provide shorter release cycles of IFC, faster support for new IFC versions in software vendors' implementations, instant support for new modules or extensions, and stronger interoperability between modules' extensions and domains.
Such adaptors could be built by software vendors or third parties on top-of existing capabilities to begin introducing modularity and object-level exchanges before the latest standards are finalised, thereby supporting migration to the new standards in the future. This could be achieved by leveraging supporting ecosystem components, such as those specified in the OIIE for functionality including, identifier mapping and translation, plus data and model transformations.

Use Cases & Event-Driven Change
Measures that could improve implementation of subsets of the IFC schema in vendor software include improvements to the processes for creation, maintenance, and publication of IDMs and MVDs themselves. With OIIE Scenarios and Events the requirements for achieving a specific interoperable interaction and message exchange are defined in the context of OIIE Use Cases. Similarly, better definition of bSI approved MVDs to address frequently occurring interoperability issues would encourage software vendors' development and implementation of them. This would include enabling vendors to implement subsets of the IFC schema in a more modular and consistent manner.
For object-based IFC data exchanges to be reliable and scalable, use cases should clearly define information exchanges between users. MVDs and IDMs may be improved by the new Information Delivery Specification (IDS), which will allow the definition of exchange requirements that are not tied to IFC schema but to concepts used in IFC (buildingSMART, 2020, p. 18). OIIE Scenarios are similar in that they specify data and exchange requirements in conceptual terms and are not tied to specific CCOM elements. However, the approaches diverge where OIIE aims to promote Scenarios, along with their associated Use Cases and Events, to a level of standardisation for industry agreement, thus allowing broad and prior agreement to be realised on important, common, and frequent exchanges, thus supporting an 'implement once' strategy by software vendors. We suggest that there are benefits in standardising a set of IDMs and MVDs while supporting the future IDS as a constraint overlay that can be defined for specific contexts, including at the local project and contract level. This is similar to OIIE Use Case Architecture development and implementation.
Recommendation 3: Adoption of standardised processes for the creation, publication, and maintenance of MVDs, or their future equivalents, by focusing on specific interoperability challenges and goals. Management of these MVDs can ensure consistency and interoperability, and provide a modular basis for software vendors to implement IFC conformance before IFC 5 becomes the norm.
Recommendation 4: New MVDs should emphasise event-driven exchanges to achieve a greater level of granularity, and to allow the ecosystem to remain up-to-date when changes occur to different models in different contexts.
Recommendation 5: Adoption of standardised processes, similar to OIIE Use Case Architecture, for describing the higher-level context above IDMs and MVDs and to provide a coherent understanding of their integration into broader industry use cases, their logical sequence, and how they are reused across interoperable interactions.
Part of this could involve re-analysing existing IDMs within the framework of the OIIE Use Case Architecture to identify common Use Cases and situate IDMs and MVDs in context. This would improve their understanding and reusability in the short term while simultaneously implementing a framework to anticipate new definitions as standards are developed and proven.
Recommendation 6: Support the planned IDS standard for overlaying additional, dynamic, requirements on top of more general, though well-defined, and modular MVDs. The proposed machine interpretable and modular approach for IDS should support the evaluation and validation of MVDs in addition to broader IFC based exchanges.

Web-Based Semantic Connectivity
Reliable and scalable data exchange depends on semantic understanding, as described in section 4.1.1, yet semantic connectivity in the AECO sector is presently the least supported layer in the interoperability stack ( Figure 4).  (Uslar and Engel, 2015, p. 8, Fig. 6)).
The promise of semantic connectivity is that interoperability will evolve into the possibility for the same content to be loaded into multiple applications, and rather than mapping or converting data, it is simply linked, Reaching full semantic interoperability is one of the long-standing desires in the architectural design and construction industry. (Pauwels, Zhang and Lee, 2017, p. 149) Pauwels et al. (2017), also note that web-based BIM will allow 'data islands' stored by each AECO domain to be integrated, thus reaching full interoperability.
In 2015, bSI launched the Linked Data Working Group (LDWG) to support usage of semantic web technologies and develop an ifcOWL ontology as an equivalent to the IFC EXPRESS schema, thus allowing building data to be linked to 'out-of-the-box' tools for querying and reasoning with data (Schevers and Drogemuller, 2005, Werbrouck et al., 2019. Then, in 2020, bSI launched the Digital Twins Working Group (DTWG) which continues to develop ifcOWL for use in linked data and semantic web applications that consume IFC data via additional languages (XML Schema Definition (XSD), Web Ontology Language (OWL), Javascript Object Notation (JSON)) and file formats (Extensible Markup Language (XML), Resource Description Framework (RDF)) (buildingSMART, 2020). Hence, BIM models will become 'online graphs of building data' using OWL, while XML and RDF will facilitate development of the semantic web, as noted by Pauwels et al. (2017).
Semantic connectivity is addressed in the Oil & Gas sector where semantically meaningful information is required for effective exchange of information among complex asset intensive industries. Such information is made available through Reference Data Libraries (RDLs) and Open Technical Dictionaries (OTDs). Agreeing on shared RDLs and OTDs, which may be defined by contractual arrangements, allows information to be delivered with a shared understanding. Within OIIE the MIMOSA CCOM standard has been designed as a federated model, supporting pointers to arbitrary reference data, and including features that support both object-based and web-based data exchanges (Mathew et al., 2012b). Furthermore, the combining of objects across diverse standards is grounded in an object-based approach, while transformations at the top level of conceptual models are simplified to reinforce semantic interoperability (Selway et al., 2017, Yu, (OAGi) and MIMOSA, 2020). The OIIE specification also includes component services in the ecosystem that support the mapping and linking of objects by their identifiers, both internal and shared, to support translation between different, but often overlapping, RDLs, OTDs, and organisational reference data.
Since semantic connectivity is about shared understanding, human computer interaction is key to its successful implementation, as noted in Section 4.1.1 where it was shown that different domains may model the same element in different ways. Technical solutions, including ifcOWL and linked data, cannot solve these issues if the underlying modelling language contains ambiguities that might be exploited by the user. Moreover, multiple modes of representation may be desirable and necessary to meet the requirements of different domains. Accordingly, clearer modelling guidelines and best practice need to be provided. For example, modelling templates could be used to capture transformation and meaning in multiple ways as required by different systems.
Recommendation 7: Adopt standard services as part of the Interoperability Ecosystem that provide mapping, translation, and transformation functionalities for improved semantic connectivity.
Recommendation 8: Aim to reduce ambiguity in the modelling language and develop clear modelling guidelines, best practice, and modelling patterns. The identification of tool constraints relevant to patterns and guidelines may allow solutions to be developed, such as transformations, that can be applied at the adaptor level or through common services provided to the Interoperability Ecosystem. This would allow improved semantic connectivity between applications as well as within the federated model itself.

CONCLUSION
This research has addressed three questions; 1. What can the AECO sector learn from the Oil & Gas sector's implementation of interoperability measures which are focussed on object-based data exchanges? 2. Can interoperability in the AECO sector be improved by object-based, rather than file-based, data exchanges? 3. What standards and systems are required in the AECO sector to reinforce object-based data exchanges?
We answered these questions by comparing standards and specifications in these sectors, and then by examining the problems identified and solutions implemented that directly address object-based data exchanges. We then evaluated the differences and similarities between AECO and the Oil & Gas sector and made recommendations that aim to improve interoperability focussed on object-based data exchanges.
While we acknowledge work to address interoperability is ongoing in the AECO sector to rectify problems identified in our research, the new standards, including IFC 5, will not be developed and adopted in the short-term. Therefore, we have made recommendations that would facilitate progress while the new standards are under development. Ideally, such steps would lay the groundwork for migration to the new standards once ready for adoption.
Accordingly, we propose the following four priorities to improve integration and interoperability for the AECO sector, Priority 1. A hybrid Interoperability Ecosystem, similar to OIIE, for the AECO sector, with specifications and guidelines which recognise the status quo of the AECO sector and its dual approach to implementation of data exchanges supported by a network-centric communication model. This would secure continued management of, and changes to, distributed models by AECO organisations while developing centralised federated models based on local or cloud servers. Thus, the Interoperability Ecosystem would define object-based IFC standards for adaptors and APIs, and for local and cloud-based server data exchanges. Further consideration of event-based message exchanges would support the development of a future-oriented, standards-based ecosystem for Digital Twins, Smart Buildings, and Smart Cities.
Priority 2. API and adaptor standards to be identified, or developed as necessary, with modularity embedded, supported by the ecosystem approach. Investigation into the development of standards-based, object-level and event-driven adaptors by first and third parties, by leveraging standardised ecosystem components to overcome challenges to interoperability in the AECO sector. This could improve interoperability in the short-term while providing a framework for migration to new standards as they become available.
Priority 3. Use of a standardised process for the identification of priority use cases to place important IDMs and MVDs into context, and to identify possibilities for reuse, prior to defining modular and reusable MVDs that could be standardised and carried forward into future standards and specifications.
Priority 4. Improved semantic connectivity through the use of standardised ecosystem components e.g. for the implementation of mapping, translation, and transformation. Also, the use of bSDD and other RDLs in combination with improved modelling guidelines and templates that could be used to overcome interoperability challenges in the short-term.

Future Work
In future work we aim to examine and test the implementation of standards from the Oil & Gas sector's OIIE Specification, and its components, to evaluate their capability to resolve interoperability issues in the AECO sector, as identified in this paper. We plan to investigate the application of modular, object-based, OIIE configured adaptors, leveraging supporting ecosystem components, to current file-based IFC exchanges to determine the efficacy of the approach suggested in our recommendations. We believe that demonstrating improvements to AECO interoperability in the short-term would be of value, particularly those that support migration towards future standards aimed at resolving interoperability issues more comprehensively.

Summary
The primary theme identified and reported throughout the paper is the need for the AECO sector to advance from file-based to object-based data exchange, and for it to acknowledge the dual approach that is taken where both a distributed federated system and a centralised federated system operate in unison. Comparison with the Oil & Gas sector has highlighted this understanding which has shaped the recommendations and priorities for change noted above. Furthermore, we confirm that this evolution is necessary for the realisation of Smart Buildings, Smart Cities and Digital Twins which are dependent on the provision of semantic connectivity and full interoperability across standardised interfaces.
We are aware that, pivotal to making these changes, are the proprietary software vendors servicing the AECO sector. Accordingly, these new standards should carefully guide vendors to design and create adaptors with fully interoperable outcomes. Flexibility to develop and market diverse products would be provided by a modular approach in the design of these adaptors, allowing a plug-and-play approach to evolve across diverse software systems. If the AECO sector is to fully embrace interoperability in collaboration with vendors then its desires, needs and requirements should be clearly expressed. This underlies the intention of the new Interoperability Ecosystems standards, guidelines and systems proposed.