When BIM Meets MBSE: Building a Semantic Bridge for Infrastructure Data Integration

Abstract

The global infrastructure industry is faced with increasing system complexity and requirements driven by the Sustainable Development Goals, technological advancements, and the shift from Industry 4.0 to human-centric 5.0 principles. Coupled with persistent infrastructure investment deficits, these pressures necessitate improved methods for efficient requirements management and validation. While digital twins promise transformative real-time decision-making, reliance on static unstructured data formats inhibits progress. This paper presents a novel framework that integrates Building Information Modelling (BIM) and Model-Based Systems Engineering (MBSE), using Linked Data principles to preserve semantic meaning during information exchange between physical abstractions and requirements. The proposed approach automates a step of compliance validation against regulatory standards explored through a case study, utilising requirements from a high-speed railway station fire safety system and a modified duplex apartment digital model. The workflow (i) digitises static documents into machine-readable MBSE formats, (ii) integrates structured data into dynamic digital models, and (iii) creates foundations for data exchange to enable compliance validation. These findings highlight the framework’s ability to enhance traceability, bridge static and dynamic data gaps, and provide decision-making support in digital twin environments. This study advances the application of Linked Data in infrastructure, enabling broader integration of ontologies required for dynamic decision-making trade-offs.

1. Introduction

The global infrastructure investment gap has grown from USD 0.5 to 0.8 trillion annually [1], exacerbated by the increasing complexity demanded by the requirements of increasingly socio-technical systems and the aspirational Sustainable Development Goals (SDGs) [2]. In the United Kingdom (UK), the investment gap rose from GBP 3.9 billion in 2016 to GBP 5 billion in 2023, a significant challenge that compounds the sector’s historic problems of:

• Highly fragmented and contractually complex industry: 99% of construction companies in the UK have fewer than 50 employees [3].
• Low productivity growth: Productivity lags behind other engineering sectors like aerospace and manufacturing [4].
• Low levels of research and development (R&D) investment: The infrastructure sector invests 1% of revenue in R&D compared to 4% in manufacturing and aerospace sectors [5], limiting its ability to leverage productivity gains through emerging technologies.
• Growing complexity: As construction projects increasingly involve cyber-physical systems, the workload expands, offsetting some of the recent productivity gains.
• Increasing regulatory and technological demands: New requirements, including those driven by the SDGs such as carbon emissions under goal 9 (Industry, Innovation and Infrastructure), add further complexity.

Efforts to digitise project delivery under Industry 4.0 push towards integrated technologies [6] and Building Information Modelling (BIM) has proved to be successful in its initial objective of connecting multidisciplinary silos [7]. However, further emerging demands arising from the Industry 5.0 principles [8] of human-centric, sustainability, and resilience provide a new digitisation challenge that still needs to be adequately addressed.

Digital Twins (DT) have emerged as a promising paradigm for the Architecture, Engineering and Construction (AEC) and infrastructure industries [9,10] to link physical and digital models and allow for real-time dynamic decision-making. For this DT goal to be achieved, the AEC industry must connect disparate datasets to react in a dynamic manner [11], requiring the capture of semantic meaning to understand the emergent properties of the systems they represent, which will support decision-making [12]. For these digital twins to be able to make real-time multi-factorial decisions, the meaning currently held in the static contracts, documentation, and business plans needs to be digitised while preserving semantic meaning. With this, it is possible to combine the models with real-time data to allow for instant intelligent strategic decisions about asset behaviour to be made, like those of engines in the aerospace sector [13].

The UK’s High Speed Two (HS2) railway project exemplifies the challenges of large-scale infrastructure initiatives. To date, the project has generated over 7 million datapoints [14] that equate to petabytes of data that need coordinating. This includes data that must be verified and validated by HS2 Ltd. against thousands of requirements formed from a suite of codes, government needs, design guides, and unique site considerations. This exponential growth of data creates an emerging risk for large projects where data users and decision-makers are drowning in data [15] and professionals risk becoming overwhelmed, hence making them unable to adequately make informed decisions. There is, consequently, growing interest in deploying more systems-based approaches across the lifecycle of infrastructure projects [16,17] in industrial [18] and academic circles [19], aiming to improve the delivery and operation of infrastructure by enabling the connection of submitted data to digital twin aspirations [20]. This drives the need to intelligently architect data input, structure, and ideally automate data processing as it is generated, with links to preserve meaning, to allow for key decisions to be made during all stages of the system’s lifecycle. As the sector continues to develop infrastructure (and buildings), new methods are required to ensure that it can check the compliance of assets and preserve a “golden thread” of information to help prevent disasters like that of the Grenfell Tower in 2017 [21].

This paper demonstrates that Model-Based Systems Engineering (MBSE) models can be used to represent documents and specifications in digital formats for the construction industry. We deploy Linked Data principles to connect this information with BIM data and provides a key novel model-to-model data exchange for multiple spaces and the associated fire safety elements captured within them, allowing for the ability to import back into the MBSE models for the validation of building information against associated requirements.

Following this Introduction, background research is set out in Section 2, exploring the advancing concepts of BIM, digital twins, MBSE, Linked Data, and semantic web technologies. Section 3 presents the research methods and analysis and explores the workflow and technologies required for the potential use of an MBSE-BIM framework. Section 4 then provides a summary of the research undertaken and explores the results and contextualises them in the wider context. The Section 5 presents the conclusions of the research and provides a discourse around the limitations and future research directions.

1.1. The Research Context and Literature

1.1.1. The Evolution of BIM Data

The project delivery collaborations required to deliver major infrastructure projects can essentially be considered as large socio-technical information processing and producing systems [22], where tools and information artefacts are required to enable the transaction of requirements and products between highly fragmented project stakeholders. Information management has continually been recommended as a key enabler of productivity improvement with three key areas of policy, process, and technology [23].

The UK continues to be a driving force in the advancement of digital capabilities for the AEC and infrastructure industries [24,25,26], with initiatives that push the sector forward with research and mandates for adoption. The ISO 19650 series provides the policy and procedural framework for information management over an asset’s lifecycle; with core principles [27], the delivery phase [28], the operational phase [29], information exchange [30], and information security [31] driving the delivery of information in Common Data Environments (CDEs) and BIM models. This suite of standards sets out the approach that links together the ideas around organisational information requirements (OIRs), high-level strategic objectives, through to technical and project-level information deliverables. Though the standards have relatively high uptake in the delivery phase of the project, their uptake remains lower for the operational phase of the asset’s lifecycle [32,33]. This may be due to the validation and integration of information still being developed, with much of the guidance focused on semi-structured tables where requirement decomposition and aggregation methods [34] are still to be established.

The technology field of BIM has been fruitful in advancing the ability of software, hardware, and equipment to provide information about the assets they represent as a response to policy. It began with object-oriented approaches to represent physical elements and their associated attributes [35,36], which has progressed computational design to incorporate a wide range of tools for parametric, generative, and algorithmic design [37]. Platforms now provide a multitude of users with different needs [38] for increasingly more accurate but data-heavy models, to represent the systems and their environments, throughout the delivery lifecycle. A study of BIM implementation over 32 major projects reported significant benefits, including a 40% reduction in unbudgeted change, a 7% reduction in project time, an 80% reduction in time needed for cost estimates, and a 10% saving on the contract value [39,40]. Further analysis suggests that for every GBP 1 invested in improving information management, an estimated GBP 6–7.40 of savings could be achieved [41]. Whilst great strides have been made in progressing the modelling of the physical elements into the digital world, the mapping of the systems to their purpose has not yet been achieved in a flexible or traceable manner. The connection of the physical to the intended purpose of the system provides a unique opportunity yet to be addressed.

Part of this information management opportunity lies in the push towards a more systemic view of the assets [42] and the formal adoption of the digital twin paradigm. The vision for digital twins in the built environment and infrastructure sectors is to create “twins” of not only single assets but networks that can be connected to form aggregations of digital twins to create a national [digital] twin [43], effectively acting as a system of systems representation [44] of the UK’s infrastructure assets. There are, however, gaps in multiple areas of data modelling in terms of systems architecture, user requirements, reference modelling, and ontological mapping, where data continue to be siloed and restricted when operating at a single enterprise or organisational level.

1.1.2. Digital Twins in AEC and Infrastructure

Digital twins are seen as one of the developing methods for managing emergence from complex systems [45]. Arising from the mirror modelling of physical assets by NASA in the 1970s [46], where replicas of the active Apollo mission craft were used to replicate the craft status to troubleshoot mission-critical issues. The digital twin term emerged around 2002 and was associated with mirror space models being explored in product lifecycle management [47], setting out the physical, virtual, and linking mechanisms (Figure 1).

One of the earliest uses of the term “digital twin” appears in NASA’s technology roadmaps [49], describing a vision for high-fidelity simulation models connected to the “flying twin” through sensors. These sensors collect real-time data to enable forecasting to enact change to optimise the vehicle. Tao [50] later expanded on the concept, proposing that the virtual model should incorporate data stores and virtual services required to execute the simulations, an expansion of the virtual space initially defined by Grieves.

Different types of “digital twins” can be defined for different stages of a product’s lifecycle: digital twin prototypes (DTPs) for artefacts typically in design, digital twin instances (DTIs) for individual products, and digital twin aggregates (DTAs) [51] that pull information together to show emergent behaviours of a complex system and its associated sub-systems. To deliver these twins Qi [52] describes a potential series of configurable technologies and tools required to realise a digital twin approach. When the current digitisation efforts within construction are compared against Qi’s technology map, geometric and physical models are captured by the BIM space, behavioural modelling is captured by the various simulations and analysis models, but rule models are loosely defined with a wide range of techniques that do not allow for ease of connection between the associated model.

Since 2016, there has been an exponential increase in interest in DTs, with over 96% of 850 articles published since 2016 focusing on DTs [53]. Whilst the infrastructure sector only holds a small portion of this published work, the interest in the topic is increasing significantly. Within this push, industry reports developed the idea of five levels of digital twins based on capabilities [54] derived by metrics of autonomy, intelligence, learning, and fidelity. To be able to achieve improved levels of digital autonomy and decision-making, data integration between disparate models remains a critical challenge. Research has shown the ability to provide a workflow required to reach the third level, where predictive maintenance, analytics, and insights were demonstrated against the UK’s iconic Clifton Bridge [55]. To be able to progress to the fourth level, where automated decision-making can take place, there is a need to link other information to the models to define the constraints and set out the requirements of the asset and the business.

Within the built environment geometric and physical modelling can be seen in the GIS and BIM models, with behavioural models explored through specific analysis packages such as ANSYS. Rule modelling is focused on tacit knowledge and predefined logic used to make decisions that are often elicited through contracts, codes, and standards. Currently, most documents are held in static formats (PDFs, Word documents) with ambiguous wording, requiring human interpretation, which is often viewed in a siloed manner that makes compliance checking difficult.

1.1.3. Model-Based Compliance Checking Challenges

Compliance checking of project and system requirements is manually intensive, costly, and susceptible to errors [56]. Initial research around BIM data compliance checking focused on building code and accessibility criteria, using rule-based inference in machine-readable formats and model design data. This approach continues to attract increasing interest from digital researchers within the sector, with methods including hard-coded systems [57,58], semantic markup [59], logic-based methods, and ontological approaches [60]. Object-oriented methods [61] have demonstrated increased efficiency for compliance checking.

Whilst the AEC sector has produced systems that can check quantitative objective requirements, such as well-structured numerical properties about objects [62], they have struggled with more ambiguous or vague requirements, such as “must be safe”, that require human interpretation. Current compliance checking methodologies operate at a granular geometric and component level, often produced in a bottom-up manner, such as the buildingSMART information delivery specification (IDS) [63]. Whilst some requirements, such as fire safety will be mandatory, other interconnected requirements that look to maximise light or floor space claims are not. Parametric modelling begins to tackle interrelated parts [64], but the number of connected requirements is often low and abstracted into simplified lists that lack traceability back to their origins. As such, it is not always clear how high-level requirements are decomposed from their intended purpose to the lower-level, more granular requirements in an object-oriented machine-readable environment.

The MBSE approach may offer a means of decomposing and aggregating requirements in a structured and machine-readable environment that can provide traceability and enable trade-offs to be completed both manually and automatically.

1.2. The Systems Engineering Opportunity

Systems engineering (SE) is an interdisciplinary approach that facilitates the realisation of systems and their components to ensure they holistically adhere to specified requirements throughout their lifecycle [65]. Since its inception in the 1940s, it has been developed and deployed across a diverse range of industries, ranging from computer science to biology. The methodology is critical to capture, manage, and validate requirements throughout a product’s lifecycle using modelling, simulation, and optimisation techniques to balance trade-offs [66]. This approach to understanding interrelated requirements offers the opportunity to understand the impact of changes and make appropriate decisions when delivering and operating assets.

SE has been suggested to be a potential methodology to improve requirements capture for construction and BIM [67], acting as a method to improve the value and traceability of requirements to the modelled representations of assets. The successful delivery of the Øresund Bridge from Denmark to Sweden [68] highlighted SE’s effectiveness in managing complex infrastructure projects, ensuring on-time and within budget completion (performance metrics that are traditionally difficult to control [69]). Critically, as the sector advances towards more digital approaches for delivery, the document-centric nature of traditional systems engineering becomes increasingly unsustainable due to the increased volume of digital and physical artefacts and the exponentially greater number of relationships between them. The natural evolution of SE, MBSE, offers a potential solution to tackle complex systems in a holistic manner.

1.3. MBSE

MBSE is the formalised application of modelling to support system requirements, design, analysis, verification, and validation activities throughout a system’s lifecycle [66]. It utilises the SE process defined in ISO 15288 [70] with digital tools and modelling languages to provide a standardised visual approach with rigour to system development.

1.3.1. Modelling Languages: UML, SysML, and UAF

Several modelling languages can be used to support an MBSE approach, depending on the type of system being developed. The Unified Modelling Language (UML) is generally used for software-intensive systems [71], the Systems Modelling Language (SysML) for non-specific complex systems [72], and the Unified Architecture Framework (UAF) [73] for high-level enterprise architectures for systems of systems. As this paper focuses on the traceability of digital representations and their associated requirements, the capabilities of SysML were explored.

SysML 1.5 is a general-purpose systems modelling language building on, but also extending, UML to offer additional modelling capabilities such as the modelling of requirements and parametrics. It uses nine key types of diagrams (Figure 2) to represent systems in a visual manner and enables requirements hierarchies to be connected to a system’s modelled behaviours and structures [74].

SysML acts to capture information relating to systems and their associated components within the context of digital twins [76], providing a means of requirements traceability [77] and establishes a means of modelling interactions between cross-domain system models [78]. It provides a framework for holistic modelling and preserves the semantic meaning between elements.

1.3.2. BIM and MBSE

There is growing interest around BIM and MBSE compatibility for managing the lifecycle of complex systems [79] that aim to leverage the respective strengths of the two approaches to improve decision-making. BIM provides a digital representation of the physical systems and their functions, and MBSE provides digital representations of the system’s lifecycle relating to business and operational requirements with the approaches to verify and validate them.

The combined use of SysML and BIM has been explored to capture the overarching architecture of a web app for BIM viewing and interaction [80], using Structured Query language (SQL) databases. However, this approach struggled to dynamically connect the datasets in a way that supports the verification and validation of design changes to support impacts that can be easily visualised. SysML parametric models have been used to establish building envelopes in sustainable buildings [81]; however, the models stop short of integrating the BIM data with the MBSE models, instead treating them as concurrent but separate processes that rely on manual data updates when changes occur within either model.

Two significant barriers to implementing MBSE are the integration of the design processes and demonstration of knowledge capture and representation [82] within existing MBSE-deployed areas. As MBSE is less well known in the infrastructure sector, there is a need to convey information through existing and familiar formats. There has been little research around how MBSE information can be provided for AEC sector designers and operators in a format that is intuitive and accessible relative to the digital representations often seen within BIM.

Even once requirements and system representations have been digitised, a form of semantic glue is required to connect the information together and ensure that the information sources can be federated. The following section explores an approach to achieving this.

1.4. Linked Data and Semantic Integration

System integration across increasingly complex modelling tools remains a key challenge for the AEC sector [83]. Semantic web technologies provide a potential solution to overcome siloed information and compliance checking processes by their individual tools [84] across disparate systems. These technologies provide a way of preserving meaning and establishing relationships between the data across tools.

1.4.1. The Semantic Web

The semantic web [85] concept transformed the Web of Documents, a creation of structured data that creates a machine-readable network of information with preserved meaning through the relationships captured. This interconnected goal and technology are underpinned by the semantic web stack [86], which forms the foundation for knowledge held in semantic graphs and the semantic web technology stack (visualised in Figure 3).

The main principles of Linked Data are [88,89]

• Uniform Resource Identifiers (URIs) for resource names;
• Hypertext Transfer Protocol (HTTP) to access URIs;
• Structured data representations: Resource Description Framework (RDF) and RDF query language (SPARQL);
• Links to other URIs (relationships).

The eXtensible Markup Language (XML) provides a means of tagging and structuring documentation [90], while the Web Ontology Language (OWL) [91] provides a basis for describing entities and their relations as vocabularies. Resource Description Framework (RDF) [92] graphs provide the syntax notation and formats to exchange graph data.

The RDF structure contains statements called semantic triples (RDF triples or just triples), a codified statement in the sequence of subject, predicate, and object seen in Figure 4.

The nature of the structure allows for the statements to be treated as directly labelled graphs [93]. Under this representation, the RDF schema (RDFS) enables the specification of classes and properties [94] that enriches the amount of data held by the representations. This collection of data can be connected to ontologies, such as the Web Ontology Language (OWL), to attach semantics to the schema and allow for meaning to be inferred from individual or multiple RDFS. Rule-based reasoning can be conducted through Linked Datasets using specified “rule languages”, such as the Rule Interchange Format (RFI) [95] or SPARQL [96], allowing for custom rules to be created and used to validate RDF graphs against a set of conditions.

1.4.2. Linked Data Usage in Construction

Interest in the application of Linked Data within the construction sector continues to grow across a number of fields [97,98], with efforts to convert building information into Linked Data from AEC groups, such as the Linked Data Working Group within buildingSMART international BSI and the Linked Data Building (LBD) community group.

The Linked data approach has been used to demonstrate the ability to extend the data captured in BIM models and allow for connections to additional data linkages [99] around use cases such as the Linked Data approach for converting areas into ontologies and SHAQL [100], structuring and querying product information in areas such as planning [84], cost estimation and appraisals [101], and a semantic rule checking environment [102]. Several ontologies, such as the Building Topology Ontology (BOT) [103] and Building Product ontology [104], provide machine-readable data structures that preserve the semantic meaning of the information for zones and elements based on the bounding of spaces within the modelling domain.

1.5. Summary and the Paper’s Focus Based on Research Gaps

In summary, previous work has brought AEC research to an inflexion point where the need for connected disparate datasets is being actively pursued. Compliance checking for model quality through standardisation efforts is driving improved model connectivity and quality.

Both MBSE and BIM have been highlighted as paradigms that can connect and identify conflicting interactions between specifications [105] and propose software integrations as a solution. However, the solutions to date have been high-level and ambiguous with regard to how linkages are achieved. This paper suggests the use of Linked Data as the bridge between the BIM and MBSE tools.

This research builds on these advancements by offering a means of integrating Linked Data with MBSE and BIM to create a unified framework for compliance validation, connecting the “why” elicited in MBSE models with the “what” of BIM data. By connecting the unstructured documents, BIM models, and MBSE representations, the framework allows for enhanced traceability and lays the foundations for automated verification and validation applications.

2. Materials and Methods—Workflow, Data Sources, and Tools

This section sets out the proposed workflow, adapted from a previous work [106], integrating insights from earlier investigations into MBSE system models as representations for construction assets [81] and avenues for Linked Data [105]. It details the construction of MBSE and BIM models necessary for enabling semantic linkage and compliance checking between system requirements and building data. Figure 5 illustrates the paper’s focus and main contribution (red in Figure 5) within this wider system integration landscape.

This paper explores the framework through a case study to demonstrate the relevant steps needed for the successful exchange of data.

2.1. Workflow

• System selection: This step is completed through triangulating the available data models from the client’s CDE, as submitted by contractors (see Section 2.1.1).
• System modelling: Document and database abstraction to capture requirements and system definitions in SysML to include the following views: requirements, structure, and resource definitions. Workshops with subject matter experts (SMEs) verified these views. This step was iterative and linked to step (3) (see Section 2.1.2).
• Information model quality checks: Ensuring the datasets have sufficiently tagged data attributes and model maturity. Choice of an appropriate ontology to represent the Industry Foundation Classes (IFC) elements based on the system of interest (see Section 2.1.3).
• Data conversions: This step requires multiple translations and validations to ensure that all models retain semantic meaning (Section 2.1.4).

2.1.1. Problem and System Definition

Following the methodology outlined in the author’s previous work [107], environmental, data management, and contractual document representations were selected as initial seed artefacts. They were used to generate a set of 20 SQL queries within the EDMS that identified interdependencies based on the references and database metadata. Graph theory analysis using degree centrality and betweenness centrality was used to rank artefact complexity. These queries identified the fire safety system of a railway station for the HS2 project as highly interlinked based on the metrics attained from the document relationships. While other documents scored higher, they were discounted during data validation workshops with system owners and discipline leads due to artefact suitability. The selected system included a range of elements applicable to spatial configuration, safety strategies, and regulatory mapping.

2.1.2. MBSE Modelling

Following a combination of the MBSE/BIM framework proposed by Valdes [105], Friedenthal [74], ISO 15288:2023 [70], and the data architecture set out in a previous work

• Model organisation: SysML package diagrams were created to logically organise the system and separate requirements and structural elements, providing the overarching system model.
• Analyse stakeholder needs: Define the model types to be used based on the needs of the system.
• Requirements specification: Capture text-based requirements and model the system, its context, and the potential scenarios. Ensure that all decomposed requirements are aligned with the applicable standards referenced in the modules and documentation.
• Systems architecture and decomposition: Block diagrams were used to represent the systems and their sub-systems (e.g., detectors, alarms, sprinkler systems, etc.) and their interactions.
• Knowledge allocation: System components were aligned with BIM attributes (GUIDs, IFC element types, and PSETs), allowing for semantic traceability between SysML and BIM environments.

2.1.3. Model Quality Checks

All models were imported into Revit 2024 [108] using the standard IFC class mappings and edited to include the system elements highlighted from the requirements. Checks were completed against the existing data models to ensure they had a base level of elements to allow for a comparison to be made. Fire detectors and alarms were added under the ifcsensor element and given predefined types of SMOKESENSOR or HEATSENSOR (Figure 6) to a mix of spaces as a means of demonstrating a missing compliance element from a given room.

Rooms were also allocated spatial properties through the ifcSpatialZoneType of FIRESAFETY for half the building and ifcSpace properties, allowing for the potential connection of safety categories in

Table 1. Broad fire safety categories to BS 5839-1:2017 [109].

System	Category	Comment
Manual systems	M	No fire detectors
Automatic	L	Protection of life
	P	Protection of property

. Edited models were exported using the inbuilt export IFC function with a set up to include property sets.

2.1.4. Data Conversions

The exported IFC model was transformed into the RDF format using the IFC-LBD converter [110], structured using the BOT. This translation retained the building’s data in the terse RDF triple language (TTL) file, resulting in a customisable RDF triple store for use. The TTL file was then filtered and relevant data (e.g., sensor and room relationships) were extracted using SPARQL queries.

A custom Eclipse-based model-to-model (M2M) converter was then used to parse the .ttl RDF output and generate an XMI file in the structure of the defined XMI-MOF metamodel, mapping the BOT elements to the MOF classes compatible with SysML. The metamodel defined the appropriate classes, attributes, and relationships of the RDF (Figure 7) and aligned them with the XMI-MOF elements.

2.2. Data Sources and Tools

This case study uses the publicly available “Duplex Apartment” model (Figure 8) [111], representing a building with two symmetrical residential units; this provided sufficient granularity and spatial differentiation to allow for zoning and testing of the data transfer.

2.2.1. MBSE Model Data

To derive the SysML models, the following data artefacts were used:

• Industry sponsor fire safety strategy;
• BS 5839-1:2017;
• Dynamic Object-Oriented Requirements System (DOORS) database modules;
• IFC and Linked Data RDF schemas.

2.2.2. Tool Configurations

The project’s digital environment is set out in

Table 2. Project environment configuration.

Activity Type	Tool
Requirements management	IBM DOORS
Requirements modelling	EA Sparx Version 17 (Build 1704) [113]
Use case modelling
MBSE Block Diagrams
BIM model manipulation	Autodesk Revit 2024 [108]
IFC to RDF tool	IFC-LBD Version 2.44.0 [114]
Ontology extension	Protégé Desktop 5.6.4 [115]
Final visualisation	Ifc.js [116]
M2M creation	Eclipse IDE (4.33.0) [117]

.

3. Case Study Results

This section explores the outputs and discusses the findings of applying the proposed framework across the key steps outlined in Section 2.

3.1. System Selection

Step 1 (as described in Section 2.1.1) was completed as part of previous work, choosing the fire safety system of a railway station from the HS2 project (EDMS101 in Figure 9) based on its complexity and impact on surrounding data.

3.2. System Modelling

3.2.1. Requirements Modelling

Requirements were extracted from the DOORS database, which contained the contractual and requirements hierarchy (Figure 10); this allowed for requirements to be traced between delivery partners. Requirement levels were replicated in the MBSE requirements diagram hierarchy (Figure 11 and Figure 12), abstracting and capturing the requirements and traceability required for the system and its components.

The sponsor’s requirements were broad in nature and often referred to high-level principles at the project level. While the DOORS requirements were placed into the diagram for traceability, they provided little validation criteria other than Boolean presence checks.

The sponsor strategies at the scheme design level with the joint venture deliverables provided additional detail by introducing the conceptual responses, eliciting how the requirements could be met and the broader systems that would be incorporated. These are captured in the model diagrams “SD1.1.1: Means of escape” and “SD1.1.2: Limit fire and smoke spread” (Figure 11) with the accompanying standards required. However, at the time of the data extraction, the level of information relating to the components was not connected to the DOORS modules in a traceable manner.

To connect the physical properties and system components to the strategies, two more layers of decomposition and abstraction of the associated standards were required. The first was the abstraction of two key concepts set out in BS5839-1: means of escape (protection of life) and control spread of fire (protection of property). This set of concepts sets out the first level of requirements that can be mapped to the physical building properties, as the spaces must have appropriate systems that meet the standards set by the safety categories (Table 1). These categories must be applied to each building space and can be traced to some of the ifcSpatialZoneType of FIRESAFETY.

From this, the system was decomposed to highlight some of the key elements that form the fire safety system. Figure 12 shows the decomposition of the system into its associated sub-systems or component parts.

3.2.2. System Structure

SysML Block Definition diagrams set out the hierarchical structure of the system and capture the relationship between the requirements, system elements, and the multiplicity of the elements. Multiple smoke alarms being required to provide a full fire safety system are represented by (0..*) in Figure 13. This captures the core structures of the fire safety system required for each room, but critically for this research, the ifcsensor, PSET SensorTypeSmokeSensor, and GUID properties were held in the model as parts/properties.

3.3. Model Quality Checks and Extension

The baseline duplex model was verified and checked in Revit 2024. During the model update to enable exporting to IFC4, it was identified that the rooms (spaces) needed updating and bounds correcting. Fire alarms from the NBS library were also added to 15 of 18 rooms in the model and allocated the ifcSensor:SMOKESENSOR type (Figure 14).

Once complete, all elements were exported using the default export settings for IFC4 architectural view and checked in a neutral viewer to ensure no data loss had occurred relating to the spaces and their contained elements.

When completing steps 2 and 3, it became clear that certain elements were missing from the model during the alignment of the MBSE model and its associated BIM model. The block models provided by the MBSE environment became a useful reference artefact for the 3D design team to validate what elements they may need to include.

3.4. Use Case Data Conversions

The IFC-LBD [113] desktop tool was used to transform and export the data in an RDF format aligned with the BOT structure. A SPARQL query (Figure 15) has the ability to test the models and extract the relevant information (

Table 3. SPARQL query outputs.

Sensor	SpaceName	Space
https://mbse-bim/1xgjAWE	Bathroom 1	https://mbse-bim/0BTBFW6f90Nfh9Rp1dlxK....
https://mbse-bim/1xgjAWE	Bathroom 2	https://mbse-bim/0BTBFW6f90Nfh9Rp1dlxK....
https://mbse-bim/1xgjAWE	Bathroom 2	https://mbse-bim/resources/0BTBFW6f90Nfh...
https://mbse-bim/1xgjAWE	Bed - no fire	https://mbse-bim/0qZkxwiZrAqu3NlRSr6h...
https://mbse-bim/2NuA4N	East Hallway	https://mbse-bim/1opYGdy5H82B7SWS7cIt...
https://mbse-bim/1xgjAWE	Foyer	https://mbse-bim/0BTBFW6f90Nfh9Rp1dlxK...
https://mbse-bim/1xgjAWE	Room	https://mbse-bim/3uLJpXZZf44hbLX5UFCRx...
https://mbse-bim/2NuA4N	Room	https://mbse-bim/3MuROMZ8b9Hhf8aZ%20G...
https://mbse-bim/2NuA4N	Room	https://mbse-bim/3MuROMZ8b9Hhf8aZ%20G...
https://mbse-bim/1xgjAWE	Utility	https://mbse-bim/2grXFGjRn2HPE%242YODa..
https://mbse-bim/2NuA4N	West Hallway	https://mbse-bim/1opYGdy5H82B7SWS7cIt...

) associated with the spaces (names and IDs) and sensors (IDs) whilst confirming the containment.

The eclipse EMF model (Figure 16) provides the model-to-model translation model, connecting the core concepts of the BOT with the corresponding elements of the MOF framework.

With the M2M framework created, a short java script element was executed (Figure 17) to iterate through the SPARQL data and transform the elements into the desired MOF-XMI output.

The script (Figure 17) took 3.24 s to iterate through the .ttl export and provide the XMI output (Figure 18) that contained the space IDs with the associated elements. This data can then be imported to an MBSE tool and traced to the corresponding structures held in the block diagrams.

4. Discussion

This study develops a novel data exchange mechanism to demonstrate a practical means of exchanging data between the BIM and SysML models through semantic transformation. It establishes a model-to-model pipeline using Linked Data and MOF compliant outputs. This allows for quick data processing from the ontologies into an XMI format that has an appropriate structure to allow for asset data to be processed in an MBSE modelling environment. This step forms a foundation that allows for requirements to be automatically checked using the transformed data. Whilst the approach is time-consuming to set up, once RDF exports and scripts are in place, they can be completed in less than 3 s to extract and transform the information. This enables the relevant compliance information to be extracted and checked at each submission or design change during project delivery, reducing the time and cost associated with the manual checking of requirements against their associated model representations.

In the context of digital twins, the MBSE layer captures requirements, system architecture, and behaviours using SysML diagrams, while the BIM layer provides the physical and functional attributes with the associated 3D geometry. The Linked Data approach enables interoperability while preserving semantic meaning across diverse data sources. In a digital twin, real-time sensor data would hold meaning through its semantic mapping to structures defined in the BIM and MBSE models. This ensures that incoming data is contextually meaningful and tied to specific locations, system functions, and compliance criteria. The result is an augmented digital model where live data can then be checked against the automated rules, simulations completed, and outputs fed back to the model and its real-world counterpart for continuous performance optimisation. This enables maintained semantic meaning during operation and allows for reasoning over dynamic conditions while ensuring that behaviours align with the original intent and regulatory requirements. This can be applied across the lifecycle stages, from the early digital instances (DTIs) used during design through to the operational aggregated digital twins.

Each ontology could be paired with corresponding metamodels to enable efficient processing and data exchange between the IFC models and the multiple views captured by model view definitions in BIM and the systems engineering discipline views in MBSE, allowing for individual models to be mapped to the associated systems and requirements. This decomposition adds additional value by connecting the multiple requirements sets, enabling different teams to analyse their requirements in a connected model that facilitates compliance assessments and supports trade-offs in the event of conflicting requirements. The challenge for wider adoption of this approach lies in the significant upfront cost and effort required to extend the existing ontologies to cover all the appropriate use cases, while enabling translation between the RDF triples and the XMI model in a manner that preserves the integrity of the OWL relationships. It was not possible to translate some hierarchical model elements from the RDF model to the corresponding metamodel, as the ontology requires further extension to support the necessary associations between the models.

The proposed framework can be applied to other sectors such as water, rail, or energy through further ontological mapping to the .ifc extensions for the respective domains. Specific workgroups exist as part of the buildingSMART initiatives and provide additional schemas for the respective domains. The MBSE element of the framework allows for multiple industry domains to map their requirements to their complex regulatory needs. An example of this could be in the water sector where sewerage treatment works model data could be connected to project requirements that are mapped to high-level requirements set by the regulators. This would provide traceability that would help validate solutions in the design stages and allow for network investment decisions to be made.

To further qualify the model and attain confidence, the framework will need to be deployed using more models, both in quantity and domains, to demonstrate its ability to handle domain-specific schema extensions of IFC beyond the building models, such as the infrastructure domain schemas for rail, road, or water. An additional industry-derived model was considered as part of this research, but missing data meant it was unsuitable. Further work will require the extension to existing ontologies and Linked Data exchanges to establish the domain-specific mappings associated with the sub-domains. With multiple domain ontologies mapped, this would facilitate the diverse range of infrastructure sectors and allow for federation of the data within the MBSE models, assisting multidisciplinary analysis to optimise data exchange and decision-making.

5. Conclusions and Recommendations

This research demonstrates the feasibility of integrating MBSE and BIM using Linked Data principles to assist automated compliance checks and validate requirements for infrastructure projects. The proposed approach addresses critical challenges, including fragmented data and static formats, offering a solution for enhancing traceability and decision-making. It provides a means for the rapid checking of design information and shows how there is the potential for linking the requirements to the physical data.

The approach shows the ability to capture requirements from artefacts of varying levels of formalised structure from the infrastructure domain. It uses current best practice around inference and elicitation to form a model that can be viewed and agreed by domain experts, forming machine-readable requirements models that preserve semantic meaning. It shows the ability to use rules represented in the MBSE requirements models to drive SPARQL queries, allowing for filtering and extracting key data. This data can be mapped back to the physical structures also represented in the MBSE block diagrams that are connected to the requirements models, forming a potential golden thread between the project requirements and the digital models representing real-world assets. While not demonstrated as part of this paper, these data models offer the opportunity to quickly check each instance of a particular model for the required features; in this case, it is the model containing the correct sensors as set out in the regulations.

When viewed in the context of the DTs, the method set out in this paper provides a potential means to bridge the gap required for rule abstraction and modelling required for reasoning from the input data. It also allows for the MBSE models to act as configurations that physical models can be assessed against with additional sensor data.

There are opportunities for the first steps of the requirements elicitation process to deploy artificial intelligence/machine-learning driven methods to interpret the ambiguity of requirement wording from existing documentation [118], reducing the time taken to extract requirements from the source documentation. Natural Language Processing could also be used to challenge the ambiguities and generate clarifying questions to subject matter experts, with AI agents that test the requirements against the necessary criteria that are also mapped to the model diagram types for SysML requirements. This would allow for translation into MBSE models [119] by humans or automated means that can then be agreed with the relevant stakeholders. Furthermore, there is the opportunity to drive additional MBSE model verification through the use of structured modelling methods, where the requirements that have been checked within the SysML models for compliance and traceability can be established through the requirements hierarchy.

There is also the opportunity to use requirements as constraints that are connected to the model, with generative design methods being used to optimise multiple requirements over hundreds of potential designs.

As SysML 2.0 is rolled out, the development of application programming interfaces into vendor tools will provide opportunities to allow for seamless connections between these vendor tools and the rest of the proposed framework in real time.

The framework allows for the integration of detailed requirements with high-level requirements within a system architecture. However, it has been identified that further work would be beneficial to compare the validation of a single element using this framework against other compliance checking methods to compare efficiency, accuracy, and broad capabilities.

There is also a need to expand the available ontologies and connect more to the datasets to be able to understand the needs of the data from more stakeholder viewpoints to enable more detailed trade-off analysis if viewed in the context of multiple conflicting requirements.