Integration of EMU Overall Design Model Based on Ontology–Knowledge Collaboration

Abstract

The whole train design of an Electric Multiple Unit (EMU) involves multiple domains and scenarios, thus requiring comprehensive consideration of various factors during the design process. Traditional design methods often utilize text-based approaches to model systems; however, such documentation-based designs often suffer from semantic heterogeneity, inconsistent data sources, and also struggle to provide a more intuitive overview of the overall design process. To address these issues, this paper proposes a method based on ontology–knowledge collaborative drive to achieve integration of the overall EMU design. Firstly, we employ the System Modeling Language (SysML) to construct the Model-Based Systems Engineering (MBSE) model of the EMU, establishing functional and physical architecture element models, with the EMU MBSE model serving as input. Subsequently, in the requirement model, architecture model, and traceability model, we utilize top-level ontology to construct the EMU ontology framework in a top-down manner. Lastly, leveraging the Neo4j database, we employ a knowledge graph (KG) approach to fill domain knowledge into each model in a bottom-up manner, thereby realizing the ontology–knowledge collaborative drive for the overall EMU design construction. The effectiveness of the proposed method is validated using the EMU Passenger Information System (PIS) and Traction transformer System (TS) as examples.

1. Introduction

An EMU is a multi-car train powered by electric propulsion devices that includes nine key technologies, including overall assembly, a car body, bogie, traction transformer, main inverter, traction motor, traction drive control system, train control network system, and a braking system [1,2]. It is usually a large and complex piece of equipment that falls under the category of EMU system integration, which involves a wide range of disciplines such as mechanical, electronic, materials, software, and control. Traditional methods for designing complex equipment are primarily document-based, wherein the text describes the overall concepts, design principles, design structures, and detailed design aspects. This often leads to ambiguous understanding [3], poor information exchange, and inadequate visualization of the design process [4]. To address these issues, the International Council on Systems Engineering (INCOSE) proposed the concept of MBSE, aiming to formalize the application of modeling methods to address issues such as semantic inconsistency, non-intuitive expression of logical relationships, difficulty in fault tracing, and design changes [5].

The introduction of MBSE has shifted the overall design of complex systems from being “text-based” to “model-based”, reducing the ambiguity of text using graphical models, achieving the decoupling of complex systems from top to bottom, and improving the traceability of system design. At present, the concept of MBSE has been widely applied to various industries. For example, in the aerospace field, MBSE has addressed issues such as inconsistent requirements analysis in manned spaceflight engineering [6], unresponsive aircraft management systems [7], and difficulty in test verification [8].

In the aviation field, MBSE has addressed challenges in civil aircraft forward design, including the high coupling of modeled objects [9], the low maturity of model traceability and reusability [10], the low maturity of aircraft intelligent fault prediction technology [11], and the insufficient decision-making capability in flight and ground support processes [12]. In the shipbuilding field, MBSE has addressed difficulties in verification and iteration in the overall design of power engineering [13], lack of experience in ship type and hydrodynamic performance design, and low knowledge conversion rates [14]. In the medical field, MBSE has addressed issues such as unbalanced deployment of emergency medical equipment [15] and complexity in hospital department management processes [16]. From the current research results, MBSE has shown advantages in improving design quality, increasing production efficiency, reducing development risks, enhancing team communication, and strengthening knowledge transfer [17]. As a complex piece of equipment, an EMU design features system complexity, long R&D cycles, significant manpower, capital investment, and strict requirements for safety and reliability, thus necessitating the use of system engineering methods [18]. In the MBSE-based design process of the EMU, the association between models ensures the traceability of information throughout the entire design process and helps designers optimize the iterative process of existing designs.

In the design of key systems of an EMU, some scholars have conducted preliminary explorations utilizing MBSE. Wang B. et al. [2,5,17,19] used the MBSE concept to model, simulate, and verify the pantograph of an EMU, proposing a modeling method for requirement modeling and the Operational–Functional–Architecture–Physical (OFAP) modeling method applicable to the entire vehicle logic. In addition, MBSE-based design approaches have been applied to the door systems [18] and traction systems [20] of an EMU. Yuan, W et al. [19] built a domain meta-model for the high-voltage system of an EMU, improving the efficiency of the design. The construction of the overall EMU model based on the MBSE concept involves using the M-Design modeling tool and the SysML modeling language to perform MBSE modeling of requirements, architectures, and traceability. The activity of white-box reverse design is carried out based on the forward design idea, which designs a target system that is accurate, traceable, easy to modify, and reusable. However, the use of the MBSE modeling concept in modeling the EMU involves many different domains, including mechanical and electrical engineering, among others. Different domains have different expressions for the same or similar content, resulting in a lack of a unified system model for data consistency, which reduces the performance of manufacturing systems throughout their lifecycle [21]. To address this issue, semantic integration technology, as an integration method considering context and numerical semantic relationships, has shown good results in solving the problem of semantic heterogeneity in system engineering. Ontology and KGs are important methods for achieving semantic integration [22].

Ontology is a formal specification for shared conceptual models that focuses on the abstract essence of objective facts, providing a description of object types, concepts, attributes, and relationships shared in a specific domain. It is widely used in software engineering, library science [23], and information architecture [24], and commonly used ontology languages include Extensible Markup Language (XML), Resource Description Framework (RDF) and Web Ontology Language (OWL), DARPA Agent Markup Language (DAML), and Loom [25]. Wang, H et al. established an ontology-driven framework for complex product system design information reuse, improving the interoperability between system design information and design information from different engineering disciplines [26]; Page Risueno et al. simulated aircraft production based on the Ontology-based Engineering (OBE) framework. In the development process of the aerospace machining industry, following the manufacturing model methodology principles established by Meski et al. [27], this paper describes the stages from the analysis and development of a structural model of a knowledge base to the implementation of a knowledge engineering tool, using the aerospace machining industry as an example [28]. Hu, X et al. demonstrated knowledge-based decision support in the aerospace machining industry, proposing an ontology-based system for functional integration and process automation design, speeding up the design process and enhancing design quality [29]. In the development of aircraft industry systems, the challenge of using related modeling languages and distributed proprietary formats for integrated requirement verification is faced, based on the cognitive digital twin method with ontology as the center, aiming to stimulate the potential of MBSE ontology integration in different models and achieving optimized digital consistency, interoperability, and reusability [30]. It can be seen that the ontology has normativity, sharing, expressive flexibility, and semantic interoperability. Therefore, in regard to the overall design process of an EMU, this paper introduces the concept of ontology to solve the problem of semantic integration and inconsistent data sources and uses the ontology framework to standardize the expression of facts, condense concepts, and establish logical relationships.

A KG can be regarded as a specific instance application under the ontology framework. A KG, as a graphical model for organizing and representing knowledge, quantitatively represents concepts, entities, relationships, and attributes, and its information representation structure and logical relationships are closer to the pattern of the human cognitive world [31], providing better management and understanding of massive knowledge [32]. Scholars have applied KGs to complex system design, including telemetry [33], power grids [34], medicine [35], and enterprise management [36], with outstanding results being seen in system design and intelligent question-answering services. In complex equipment research, the National University of Defense Technology introduced KGs into complex equipment requirement perception and development research, constructing a requirement KG ontology and conducting research based on new energy vehicles, proving that the proposed method can not only simplify the requirement analysis of complex equipment and achieve automated requirement analysis to a certain extent but also lay the foundation for knowledge management of complex equipment throughout its lifecycle. It can be seen that KGs have efficient data integration capabilities and advantages in visualization display, intelligent reasoning, and easy maintenance and updating.

Therefore, to achieve the complex overall design of an EMU, this paper proposes an EMU overall design model integration method based on an ontology–knowledge collaboration. The main contributions to this paper are as follows:

(1)

This paper develops an EMU ontology based on the top-level ontology to capture requirements and architecture. The EMU functional meta-model and physical architecture meta-model are built based on the EMU MBSE model and their ontology models are generated.

(2)

A model integration method based on ontology–knowledge collaboration is proposed. Utilizing the ontology construction tool Protégé, the requirements, architecture, and traceability of an EMU are established top-down by constructing a top-level domain ontology framework. On this basis, a knowledge graph is constructed to address issues such as semantic heterogeneity and diverse data sources in an EMU, thereby achieving knowledge reusability.

(3)

Taking the PIS and TS systems of an EMU as examples, the SysML models are used as input. The requirements ontology is constructed through ReqIF, the architecture ontology is established using GOPPRR and MDA meta-model construction methods, and the traceability ontology is built using elements of the traceability matrix. Finally, the knowledge graph is constructed bottom-up using the Neo4j database. These two EMU systems are used to verify the feasibility and effectiveness of the proposed method in the overall integration of an EMU.

2. Integrated Design Model for EMU

The traditional overall design process of an EMU is often based on Traditional Systems Engineering, facing issues such as poor model readability, low reusability, and inconsistent data sources. Therefore, this paper introduces the modeling approach of MBSE into the overall design process of an EMU, employing a top-down forward design approach for EMUs and driving MBSE modeling through ontology and KG technologies.

The MBSE-based overall design process of an EMU includes processes for requirements, functions, physical architecture, and traceability. Due to the involvement of multiple domains in the vehicle design process, there are semantic heterogeneities in each domain, leading to problems such as different data sources, low semantic integration efficiency, and semantic inconsistency. To address these issues, this paper proposes a bidirectional ontology–knowledge collaborative-driven integrated design model. In this method, the functions and physical architecture in the entire vehicle design process are collectively referred to as architecture, and the bidirectional ontology–knowledge drive is applied in requirements, architecture, and traceability. The technical route is shown in Figure 1. The MBSE model serves as input, dividing the entire EMU overall design into three parts: requirements, architecture, and traceability. Requirements are divided into the following three stages: requirement collection, requirement identification, and requirement analysis. During requirement identification, collected requirements are structured using the top-level ontology, and during requirement analysis, they are presented through the KG. In the architecture analysis process, the functional meta-model and physical architecture meta-model are constructed using the top-level ontology. Finally, in the traceability part, requirements and architecture are traced to ensure that the EMU design meets the requirements.

Ontology and KG methods play vital roles in achieving semantic integration, effectively addressing the issue of semantic heterogeneity in systems engineering. Ontology offers a structured, formalized description that standardizes conceptual knowledge, facilitating better organization and representation of data. In this study, we opted to employ Basic Formal Ontology (BFO) [37] to construct the ontology framework. BFO, serving as a fundamental formal ontology, enables the description of concepts and relationships across various domains, offering high generality and flexibility suitable for modeling requirements in diverse fields. On the other hand, KG technology serves as a methodological toolset for representing, organizing, and managing knowledge. It organizes accumulated information into usable knowledge at minimal cost and enables precise data linkage for knowledge searches.

This paper realizes the overall design of an EMU through bidirectional coordination of ontology and KG-driven model integration. Initially, we construct the ontology framework using a top-down approach to ensure project-wide consistency and integrity, thereby reducing omissions or errors in subsequent development phases. Subsequently, the KG fills in the analysis and confirmation of requirements from the bottom-up, starting with detailed aspects and instances and gradually establishing an understanding and confirmation of requirements. In the overall design process of an EMU, the KG is leveraged to collect and organize various domain knowledge and corresponding requirements, leading to a deeper comprehension of the essence and specifics of requirements. Through continuous filling and refining of the KG, the team can progressively distill accurate requirement specifications, ensuring their alignment with real-world business scenarios. Furthermore, within the overall design process encompassing electrical, mechanical, and material domains, the synergy between ontology and KG facilitates consistency in the team’s understanding of domain knowledge, thereby reducing communication costs and enhancing design quality.

3. Integration of EMU Requirement Models

The requirement model is integral to the entire lifecycle of EMU design. Constructing the requirement model involves stakeholder analysis, requirement collection, requirement identification, and requirement analysis. The design process of the requirement model is illustrated in Figure 2.

In the process of constructing the requirement model, the initial step involves requirement collection. During this phase, stakeholders, including clients, users, and management, are engaged in communication to comprehend their expectations and needs and to gather user stories, use cases, scenarios, etc. The design team meticulously defines and identifies all stakeholders pertinent to the project, encompassing individuals who directly and indirectly benefit from it, such as end-users, clients, management, and development teams. Face-to-face interaction with stakeholders plays a pivotal role in ensuring precise requirement gathering. Through interviews, the team can delve deeper into stakeholders’ expectations, preferences, and concerns, thereby enhancing their understanding of the project’s context and background. Following this, requirements are identified, adhering to specific rules. Finally, requirement analysis ensues, wherein the identified requirements are furnished to the architectural design, laying the groundwork for architectural development.

3.1. Requirements Ontology Construction

When constructing the ontology framework for the requirements domain, the selection of an appropriate ontology aids in defining and organizing the concepts, relationships, and attributes of requirements. For the construction of the requirements ontology for the EMU, this study opts for the BFO as a fundamental formalization ontology to delineate entities and relationships across various domains. This ensures the standardization of the requirements ontology and its compatibility with other ontologies. Furthermore, the design of BFO incorporates scalability, allowing for the customization and extension of the requirements ontology to meet specific project needs.

The construction of the requirements ontology can mitigate issues such as vague requirement definitions, communication barriers, and uncontrolled requirement changes. By utilizing an ontology, teams can articulate requirements in a more formalized and precise manner, thereby enhancing communication efficiency, reducing ambiguity, and facilitating effective management of requirement changes. This approach ensures that project teams gain a better understanding of and meet system requirements throughout the entire software development lifecycle.

During the transformation process from requirements to ontology, employing a unified requirement exchange format is essential. This process aims to establish a consistent, easy-to-maintain, and extendable ontology for improved understanding and management of system requirements.By integrating architecture through a top-level ontology and using a unified requirement exchange format as a medium, an effective connection between requirements and ontology is achieved. The process from requirements to ontology is depicted in Figure 3. Upon completing requirement collection, standardized requirements are imported into the ontology using the Requirements Interchange Format (ReqIF) [38] standard to form the requirement ontology model. This process employs a unified requirement exchange format as a medium to standardize and represent requirements from diverse sources, thereby reducing ambiguity and misunderstanding in the transformation process from requirements to ontology. Moreover, it simplifies requirement mapping and conversion tasks, ensuring consistency across multiple domains or systems.

The ReqIF was standardized by the Object Management Group in 2011 and is currently utilized in various fields such as transportation, industrial automation, and medical devices [39]. ReqIF, an XML-based exchange format, is designed to define a tool-independent standard for representing key features of requirement data. The standard encompasses requirement data elements such as attribute data elements, links (traces), requirement data views, and permission data forms. Its primary objective is to achieve a “single-source-of-truth” for requirements, ensuring consistency among different requirements and reducing defects from requirements to engineering work products, accelerating information exchange and collaborative solution development while also lowering costs. In software development and systems engineering, different requirement management tools are utilized to collect, analyze, and track project requirements, which possess varying data formats and structures, necessitating a standardized approach to pass requirement information. ReqIF offers universality, scalability, and structured data, serving as a generic requirement exchange format applicable to different domains and project types. Being XML-based, ReqIF supports meeting specific requirements management tool needs by adding custom tags or extending existing ones. ReqIF files organize requirement information in a structured manner, encompassing requirement attributes, relationships, and hierarchy. The standard is published by the International Electrotechnical Commission (IEC) and enjoys international recognition, with the terminology table being elaborated on in

Table 1. ReqIF terminology.

ReqIF	ReqIF Is an XML-Based Request Format, Used as an Exchange Format, XML Data Is Usually Stored in Files with an ReqIF Extension
Specifications	Requirement forms, organizing the objects of organizational requirements through a requirement form.
Objects	Requirement entry, a data structure used to store requirement information.
Relations	Requirement entry association, describes the linking relationship between two requirement entries.
Hierarchy	Hierarchy of Requirements, describe the hierarchical relationship between requirement entries.
Type	Requirement types, including attribute definitions and data type definitions.

.

Utilizing ReqIF to export its requirement data streamlines the sharing and collaboration of requirement information. Hence, in the process of constructing the requirement model for an EMU, ReqIF is employed to standardize requirement specifications, ensuring the accurate transmission of requirements.

During the EMU requirement construction process, meticulous requirement collection, identification, and analysis take precedence to ensure a comprehensive grasp of various system aspects. This entails close collaboration with multiple stakeholders, such as vehicle manufacturers, operators, and maintenance personnel, to ensure thorough consideration of all stakeholders’ expectations and requirements. Through requirement collection and analysis, a comprehensive roster of requirements gradually emerges, encompassing system functionality, performance characteristics, safety standards, and other facets. Integrating these collected, identified, and analyzed requirements with an ReqIF to construct the requirement ontology for an EMU facilitates the unified management and exchange of requirements, ensuring consistency and traceability. This step contributes to establishing an ontology characterized by hierarchy, coherence, and precise definitions, furnishing a dependable foundation for EMU design and development.

Figure 4 and Figure 5 visually depict the stakeholders and some requirements of the EMU requirement model. These graphical representations aid in intuitively comprehending the structure and relationships of EMU requirements. Figure 4 delineates the relationships among various stakeholders, including manufacturers, maintenance teams, crew members, etc., vividly showcasing the diversity and complexity of requirements. Meanwhile, Figure 5 offers a stakeholder-centric analysis of requirements, furnishing specific content for the EMU system’s requirements.

The construction of this requirement model and its graphical representation facilitate communication among team members, rendering the comprehension of system requirements more intuitive and comprehensive. Simultaneously, it serves as an effective tool for future requirement changes and tracking, ensuring the entire EMU project proceeds in accordance with well-defined requirements.

During the construction of the ontology, users can clearly visualize the structure of the EMU requirement ontology and understand the hierarchical relationships between various classes and the definition of attributes using the Protégé tool [40]. This visual representation assists users in gaining a better understanding of the organizational structure of the requirements ontology, quickly identifying the connections between concepts, and thereby engaging in more targeted ontology editing and expansion. The construction of the EMU requirement ontology, facilitated by Protégé, as depicted in Figure 6 and Figure 7, provides users with an intuitive and efficient operational platform. This not only enhances the efficiency of ontology construction but also furnishes users with better tools and support to ensure the quality and consistency of the requirement ontology.

The specific transformation process is depicted in Figure 8, with the rules being as follows:

• The ReqIF model is converted into a framework comprising top-level classes.
• Core concepts and relational constructs within the ReqIF model are transformed into subclasses that correspond to classes within the domain ontology framework.
• Instances are derived from the ReqIF model by leveraging the associated subclasses.
• These instances are then translated into a knowledge graph representation.
• Subsequently, through employing the aforementioned steps, the ReqIF model is transmuted into a domain ontology of requirement items articulated in the OWL language.

3.2. Construction of Requirement KG

After completing the construction of the requirement ontology, it is further instantiated and expanded through the KG. Serving as the formal specification of knowledge, the ontology defines the overall concepts, relationships, and attributes of the requirements, forming the structural and semantic foundation of the graph. Combined with graph technology, specific information about the requirements is integrated and shared with other relevant domain knowledge, achieving the instantiation representation of requirements. By incorporating the requirement ontology into this framework, richer and more accurate information can be provided to the KG, making the expression of the entire KG more comprehensive and precise. Therefore, the combination of the requirement ontology and the KG can fully leverage the role of the ontology in KG construction, enhancing the expressive power and application value of the KG, thus providing greater impetus for domain research and practical applications.

The KGs are represented in the form of triplets, i.e., (Entity1, Relationship, Entity2) or (Entity, Relationship, Attribute), where entities and attributes are nodes and relationships are directed edges connecting the two nodes. Triplets link entities or attributes and their relationships to form a KG with a network structure [41]. Commonly used large-scale KGs include Freebase, Google KG, DBpedia, and YAGO [42]; commonly used graph databases include Neo4j [43], Amazon Neptune, and Onto text Graph DB. In recent years, KG technology, with its ability to integrate data and efficiently query, visualize, intelligently infer, and easily maintain and update, has been applied in various fields such as smart education [44], aviation KG [45], smart healthcare [46], and smart e-commerce [47],achieving significant results. In smart education, the previous knowledge model about extracting knowledge from digital textbooks has been expanded [44]. Knowledge management of natural language text through knowledge graphs in the Aviation Assembly Domain [45]. The methods for constructing knowledge bases typically include automated construction, semi-automated construction, and manual construction. In the field of EMU, due to the high requirements for KGs, simple automated construction methods result in poor subsequent application effects in regard to the KG. To ensure the high-quality construction of the knowledge base, the seven-step method proposed by Stanford University for domain ontology construction [48] was adopted on the basis of manual construction of the knowledge base to construct the KG model of EMU requirements. The data of EMU overall design are mostly semi-structured and unstructured, and the knowledge corpus is complex. To meet the requirements of high accuracy and visualization of the KG, the EMU overall design adopts a combination of “top-down” based on ontology and “bottom-up” based on KGs for construction.

The construction process of the EMU requirement KG involves obtaining requirement entities and extracting requirement relationships. Through this step, we obtained a series of triplets of entities and entity relationships. These triplets are stored in the Neo4j database in an ordered manner according to the type of relationship, forming a knowledge base related to requirement engineering. The Neo4j database, as the storage engine of the knowledge base, has the advantages of a graph database. This storage method helps to effectively handle complex relationships between entities and supports flexible query operations, making the knowledge base efficient and available. Through the front-end display function of Neo4j, the EMU architecture KG can be intuitively displayed. This provides the project with an intuitive visual display, allowing users to delve into the knowledge structure and relationships of the EMU overall design domain. This display method not only enhances the comprehensibility of the KG but also provides intuitive and powerful support for subsequent analysis and decision-making.

4. Integration of EMU Architecture Models

During the construction process of the EMU architecture model, the meta-model stands out as the most critical aspect. Graph, Object, Point, Property, Role and Relationship (GOPPRR) is a goal-oriented and problem-oriented meta-modeling method designed to assist in analyzing and solving design and implementation issues in complex systems. GOPPRR divides the modeling process into stages such as goal modeling, problem modeling, representation modeling, presentation modeling, and implementation modeling, aiding in the management and control of the system design and development process. In the overall architecture of the EMU, GOPPRR is combined with the Model-Driven Architecture (MDA) method to achieve the overall design of the EMU. The GOPPRR method is employed to analyze and describe the requirements and structure of the system (M0 layer), after which the MDA’s M1-M3 layers are utilized to establish corresponding models and meta-models.

4.1. Construction of Architecture Ontology

In establishing the architecture ontology of the EMU, based on the MBSE model, the requirement meta-model and the physical architecture meta-model of the EMU are constructed initially. Building upon this foundation, the architecture ontology model of the EMU is established. The ontology design of the EMU adopts the BFO framework, facilitating the conversion between the meta-model and the ontology framework. During the process of building the meta-model, one commonly used modeling method is GOPPRR, as illustrated in Figure 9.

Meta Object Facility (MOF), as a standardized framework, provides methods for defining and manipulating meta-models, supporting the implementation of MDA. MOF abstracts models into the following four levels: the meta-meta model M3, the meta-model M2, the model M1, and the instance M0, as illustrated in Figure 10.

The M0 layer represents the most concrete model layer, housing specific domain-specific models. These models delineate detailed information and characteristics of the system or problem. The M1 layer constitutes the model layer, where models ascend in abstraction, no longer entailing details of specific domains but focusing on the essence and fundamental features of the problem. The M2 layer serves as the meta-model layer, elucidating the structure and semantics of M1 layer models. Meta-models define the types and characteristics of various elements (such as classes, attributes, relationships, etc.) used in the models, as well as their relationships. The M3 layer constitutes the meta-meta model layer, where the structure and semantics of the meta-model are delineated. In other words, the M3 layer defines the types and characteristics of the elements (classes, attributes, relationships, etc.) of the meta-model as well as their relationships. The meta-meta model furnishes a framework for defining meta-models that is typically utilized to define the language or form of meta-models.

Combining the two methods of meta-model construction mentioned above, a specific approach integrating GOPPRR and MDA is illustrated in Figure 11. The basic concepts and relationships of GOPPRR are defined as the M3 layer, while building meta-models for different structures of the EMU set using GOPPRR is designated as the M2 layer. Based on the meta-model of the EMU set, the overall architectural model is constructed at the M1 layer and concrete models are represented at the M0 layer.

The specific transformation process is depicted in Figure 10, with the rules being as follows:

• The core framework of GOPPR is transformed into the domain ontology class framework of the architectural model. The interrelationships within GOPPR are converted into object attributes, serving as the M3 layer of MDA.
• The GOPPR meta-model is converted into corresponding subclasses.
• The GOPPR model is transformed into instances corresponding to the subclasses.
• Instances are converted into a knowledge graph.
• The MBSE architectural model, representing the real-world view, is translated into an architectural domain ontology described in the OWL language.

The MOF provides a standardized approach for defining and manipulating meta-models, thereby supporting the implementation of MDA [49]. To enhance the comprehensibility and expressiveness of models, the GOPPRR method can be employed to represent entities and relationships within each layer of the MOF models. By integrating GOPPRR with MDA, the advantages of its intuitiveness and flexibility can be fully leveraged, thereby enhancing the reusability of models.

By utilizing the BFO framework, the integration of the EMU set architecture is accomplished, and the corresponding relationships are illustrated. In this framework, the basic concepts and relationships of GOPPRR are transformed into class frameworks and properties, the EMU set meta-model is transformed into subclasses, and the overall architectural model is transformed into instances. The class constructed using the SysML language is used to build the meta-model, which includes the following components: Graph, Object, Property, Role, and Relationship. For instance, the functional meta-model is illustrated in Figure 12.

Building upon the physical architecture of the EMU set, meta-models for various subsystems of the EMU set are constructed, including the traction control meta-model, the auxiliary power supply system meta-model, the air conditioning system meta-model, the traction system meta-model, the braking system meta-model, and the network system meta-model. Through the construction of subsystem meta-models, the overall architectural model of the EMU set is obtained.

4.2. Architecture KG Construction

Upon completing the construction of the architectural ontology for the EMU set, it is instantiated and expanded through the KG, as shown in Figure 13. With the KG, the architectural ontology of the EMU set can be instantiated and expanded, introducing new instances into the system such as specific vehicle models, components, production plans, etc., thus continuously updating and enriching the knowledge base. The KG connects different entities through semantic relationships, enabling the system to better understand their relationships and enhancing the semantic expression and comprehension of information. Triples extracted from the EMU set architecture are systematically stored in the Neo4j database, categorized by their relationship types, and displayed on the frontend.

5. Integration of EMU Traceability Model

After the construction of the requirements and architecture, coupling relationships are resolved through traceability matrices to verify whether the EMU meets its requirements during the overall design process. The traceability matrix contains model elements, requirements, and relationships, as depicted in Figure 14.

When constructing the ontology of the traceability matrix, SysML_Model_Element and ReqIF_Model_Element are considered framework subclasses. The elements in the traceability matrix are instantiated as instances and the relationships in the traceability matrix are treated as attributes, thus facilitating the conversion from the traceability matrix to the ontology, as shown in Figure 15.

The conversion rules are described as follows:

• The traceability matrix is converted into a class framework of the domain ontology.
• Instances from the ReqIF model and the SYSML architectural model are transformed into subclasses.
• The elements of the traceability matrix, which represent the relationships between instances in the ReqIF model and the SYSML architectural model, are converted into corresponding instances within the ontology.
• By utilizing the instances and the elements of the traceability matrix, the traceability matrix is transformed into a traceability domain ontology that is described in OWL language.

6. Study of EMU Design with Ontology–Knowledge Collaboration

The development of EMUs has undergone years of technological accumulation and research, encompassing technological innovations and integrations across various fields such as the mechanical, electrical, and control fields. The key technologies included in EMU are overall assembly, car body, bogie, main inverter, traction motor, the traction drive control system, the train control network system, TS and PIS, etc. The overall architecture design of EMUs is gradually transitioning towards modularization and intelligence. Modular design offers high flexibility and scalability, enabling an EMU to swiftly adjust the number and configuration of carriages according to actual operational needs. MBSE serves as a vital method for the top-down design of an EMU, providing a more systematic and scientific approach to its design and optimization.

Building upon the MBSE ontology–knowledge collaborative-driven holistic design method proposed earlier, this paper advances the research by conducting a case study on the development process of the PIS and TS for EMUs.

6.1. Introduction to PIS System Case Study

This section begins by introducing the application scenario of the case study, followed by demonstrating the application of ontology and the development of an ontology-based KG. Figure 16 illustrates the comprehensive workflow for developing the requirements, architecture, and traceability integrated ontology of the EMU PIS system, based on the application scenario, utilizing the MetaGraph2.0 tool.

Ontology-driven demonstration: In the case study of developing a PIS for an EMU, ontology plays a crucial role. Within the MBSE framework, ontology is employed to define the elements of the system and their relationships. By formalizing entities, properties, and relationships in the ontology language, the system can establish a shared, consistent understanding foundation. In this case study, ontology is applied in the description and construction process of the requirements, architecture, and traceability relationship models of the EMU PIS system. Through traceability relationships, requirements and architecture are connected, as depicted in Figure 17, where the expanded ReqIF model represents the requirements of the EMU and the expanded SysML model represents the architecture of the EMU.

In the development process of the EMU PIS system, the application of a KG also plays a crucial role. Utilizing the structured descriptions provided by the ontology, a KG organizes the system’s data into networks, enabling information to be more efficiently queried, analyzed, and updated. In this paper, the requirements and architecture of an EMU are presented through KGs. Through the analysis above, entities and relationships form a total of 15 CSV files that are stored in the Neo4j database to establish a knowledge base. Due to the complexity of a project’s KG, this section only presents the KG of requirements. The PIS system has three levels of requirements, namely top-level requirements, first-level requirements, and second-level requirements. Top-level requirements are represented by the blue portion, first-level requirements by the yellow portion, and, finally, the pink portion represents second-level requirements, as shown in Figure 18.

The ontology-driven presentation and knowledge-graph-driven presentation complement each other in the development process of the EMU PIS system. By utilizing the BFO upper-level ontology framework and the Neo4j graph database, the dual drive of ontology and knowledge is achieved. This approach is also applicable to other systems within the EMU. By leveraging the advantages of ontology and knowledge graphs, the development team can achieve comprehensive control and effective management of the EMU PIS system.

6.2. Introduction to TS System Case Study

The TS is one of the integral components of an EMU, responsible for providing power and controlling the train’s operation. It typically comprises traction motors, gearboxes, braking systems, and control systems, among other components, to drive the train’s operation through electric power or other energy sources.

The construction process of the traction system is analogous to that of the PIS. Figure 19 illustrates the comprehensive workflow of the traction system, emphasizing that the ontology framework and PIS share similarities, encompassing requirements, architecture, and traceability components, albeit with different entities. In terms of requirements, the PIS focuses more on service-oriented requirements, whereas the traction system places greater emphasis on reliability and safety. Therefore, the input requirements differ, similar to other systems within an EMU, necessitating determination of input entities based on specific systems while maintaining consistency in the ontology framework for requirements. Similarly, the architecture and traceability frameworks remain consistent across different systems, with the ontology framework remaining unchanged while the entities vary according to the respective system. Figure 20 presents a partial KG of the traction system, showcasing the diversity of graphs obtained when using a KG to populate ontologies from the bottom-up, depending on the system.

The aforementioned case analyses demonstrate the potential application of MBSE in the overall architecture design of an EMU. They elucidate the requirements and architecture modeling process-driven by MBSE ontology collaboration. MBSE offers an efficient, flexible, and scalable design methodology. Through the ontology-graph dual-drive approach, this methodology resolves inconsistencies in semantic understanding among modelers, thereby facilitating smarter EMU designs.

7. Conclusions

In conclusion, this paper proposes an ontology–knowledge collaborative-driven modeling approach based on the MBSE philosophy using SysML models as inputs. Through two case studies, this method is validated to support the overall design of an EMU, ensuring the systematic nature and traceability of the models. Additionally, the ontology model of the EMU architecture is constructed by combining GOPPRR and MDA. The KG utilizes the structured description of the ontology to organize data into a network, thereby enabling effective querying, analysis, and updating of information. In summary, the ontology–knowledge collaborative-driven approach to the overall design of an EMU demonstrated feasibility in the case study and showcased its effectiveness and advantages during implementation.