Ontology-based complex system design process demand tracing method

Abstract

The invention belongs to the technical field of complex system design and demand management, and particularly relates to an ontology-based complex system design process demand tracing method. The method specifically comprises the following steps: constructing an integrated ontology framework comprising a demand ontology and a framework ontology; for a complex system, demands of different sources, different levels and different types are collected, and a demand ontology is designed based on a ReqIF demand exchange format; aiming at a complex system, designing an architecture body based on a GOPPRR-E element modeling method; determining a demand model and demand ontology mapping rule, and mapping the demand models of different sources, different levels and different types into a demand ontology based on a unified framework; determining a mapping rule of the architecture model and the architecture body, and mapping the architecture model into the architecture body based on the unified framework; and establishing a traceability relationship between the demand and a superior demand, and establishing a traceability relationship between the demand and the architecture design element.

Description

Technical Field

[0001] The present invention belongs to the technical field of complex system design and demand management, and specifically relates to a complex system design process demand tracing method based on ontology. Background Art

[0002] The design of complex systems involves multiple disciplines such as mechanics, electronics, software, and control, and covers multiple levels such as system level, subsystem level, component level, module level, and part level. The design process involves massive amounts of data. Traditional document-based system design methods have become increasingly difficult to meet the design of large and complex systems, facing challenges such as inconsistent data and difficult to trace requirements. Based on this, the International Organization for Systems Engineering (INCOSE) proposed the concept of model-based systems engineering (MBSE), which uses the formal application of modeling methods to support system requirements, design, analysis, verification, and validation activities, starting from the conceptual design stage and continuing throughout design development and all subsequent life cycle stages. Models provide a standardized and visual way to express requirements and architectures more clearly and intuitively, making it easier to trace requirements.

[0003] In the MBSE-based complex system design process, requirement traceability is a key link to ensure that the systems involved can meet both the initial design requirements and adapt to changing requirements. Requirements traceability aims to record the relationship between requirements and their superior requirements, and between requirements and the architectural model in the design process. Through requirement traceability, it can be ensured that every requirement has received full attention and implementation during the system design process. When requirements change, the impact can be quickly evaluated and adjusted accordingly.

[0004] Existing requirements traceability methods mainly include manual traceability, tool-based traceability, model-based traceability, version control system and ontology-based traceability. Manual traceability manually records requirements and their relationships through spreadsheets or documents. This method is simple and easy to use, but with the increase in the number and complexity of requirements, the maintenance cost is high and it is prone to errors. Tool-based traceability uses special requirements management tools (such as IBM Rational DOORS, MagicDraw) to record and manage requirements and their relationships. Although the efficiency and accuracy of traceability are improved, the tool dependence is strong. IBM Rational DOORS only supports the construction of traceability relationships between requirements and architecture models between IBM series tools, and MagicDraw only supports the construction of requirement traceability relationships between MagicDraw models through Satisfy Requirement Matrix and Allocation Matrix (SysML allocatin Matix). Model-based traceability manages and traces requirements through requirement models such as SysML requirement diagrams and UML use case diagrams, and cannot support requirement traceability between heterogeneous requirement models. Version control systems (such as Git and SVN) are mainly used to record the change history of requirement documents and design documents to ensure that the evolution process of each requirement is traceable. This method is mainly used for historical tracking of documents, and its requirement relationship management function is limited. Ontology-based traceability realizes requirement traceability by constructing semantic models of requirements and designs and performing semantic associations, which ensures semantic consistency between heterogeneous models and can effectively realize requirement traceability and analysis in complex system design processes. However, existing ontology-based requirement traceability methods mainly focus on the research of traceability between requirements and between requirement models and architecture models constructed with a single modeling language, but lack research on the traceability between requirement models and architecture models constructed with heterogeneous modeling languages. In addition, existing requirement traceability methods mainly focus on the construction of requirement traceability relationships and lack analysis of requirement traceability relationships.

[0005] The Chinese invention patent with application publication number CN 115688446 A discloses a requirement tracing and coverage checking method based on MBSE. The method is represented by a certain type of vehicle transmission system. According to the development characteristics of a certain type of vehicle transmission system, the types of requirements involved in the transmission system design include functional requirements, performance requirements, and design constraints. Combined with SysML syntax, three relationship models of derive, satisfy, and verify are used to define the relationship between requirement decomposition tracing, requirement design tracing, and requirement test tracing; among them, requirement decomposition tracing records the decomposition process of the design requirements of the overall task book to system requirements, subsystem requirements, and component requirements; requirement design tracing records the design tracing relationship between the architectural design elements of the system, subsystem, and component and the corresponding requirements. Functional requirements are generally covered by structure or behavior, performance requirements and quantitative design constraints are covered by indicator parameters, and qualitative design constraints are covered by structure; requirement test tracing records the test tracing relationship between the test cases of the system, subsystem, and component and the corresponding requirements. Using the tools corresponding to the SysML modeling language and the Profile expansion mechanism, the requirement traceability matrix or requirement diagram is used to establish the Derive relationship between requirements at all levels; the requirement traceability matrix or requirement diagram is used to establish the Satisfy relationship between architectural design elements at all levels and requirements; and the requirement traceability matrix or requirement diagram is used to establish the Verify relationship between architectural design elements at all levels and requirements. And by defining and calculating the requirement decomposition coverage, requirement design coverage, and requirement test coverage, the requirement traceability relationship is checked and improved. Although this method realizes the traceability of requirements of different levels and types, and the traceability from requirements to design and testing, it can check and improve the requirement traceability relationship. However, this method is mainly aimed at the SysML modeling language and SysML modeling tool. Complex system design involves multiple disciplines, such as machinery, electronics, software, and control. The requirements and design standards and modeling languages ​​between different disciplines are different, and this method cannot solve the semantic integration and requirement traceability of heterogeneous models.

[0006] By analyzing the above existing demand tracing methods, we can find the following problems that need to be solved in demand tracing:

[0007] (1) Difficulty in demand tracing between heterogeneous demand models

[0008] Complex system design involves different levels such as systems, subsystems, and components. Stakeholders at different levels use requirement models in different formats such as SysML (SysML) requirement diagrams, ReqIF (Requirements Interchange Format) requirement entry forms, Excel, etc. to express requirements at different levels. The data structures and semantics of these requirement models are heterogeneous, making it difficult to transfer models and establish traceability relationships between requirements.

[0009] (2) Difficulty in tracing requirements between heterogeneous requirement models and architecture models

[0010] Complex system design involves different fields such as mechanics, electrical, hydraulics, and control. Engineers in different fields usually use different modeling languages ​​to express requirement models and architecture models. Modeling in heterogeneous languages ​​leads to semantic differences between requirement models and design process models, which cannot guarantee the effective transfer of models and makes it difficult to establish a traceability relationship between requirement models and architecture models.

[0011] (3) Lack of assessment of demand traceability

[0012] Current research mainly focuses on the establishment of demand traceability relationships, and lacks research on the evaluation of demand traceability. Summary of the invention

[0013] In view of this, the present invention provides an ontology-based complex system design process requirement tracing method, which supports the evaluation of requirement traceability.

[0014] The technical solution for implementing the present invention is as follows:

[0015] A requirement tracing method for complex system design process based on ontology, the specific process is as follows:

[0016] Build an integrated ontology framework including requirement ontology and architecture ontology;

[0017] For complex systems, collect requirements from different sources, at different levels, and of different types, and design the requirements ontology based on the ReqIF requirements exchange format; for complex systems, design the architecture ontology based on the GOPPRR-E metamodeling method;

[0018] Determine the mapping rules between demand models and demand ontology, and map demand models of different sources, different levels, and different types into demand ontology based on a unified framework; determine the mapping rules between architecture models and architecture ontology, and map architecture models into architecture ontology based on a unified framework;

[0019] Establish a traceability relationship between requirements and their superior requirements, and establish a traceability relationship between requirements and architectural design elements.

[0020] Furthermore, the present invention introduces the top-level ontology BFO and the middle-level ontology IoF-Core to construct an integrated ontology framework including the demand ontology and the architecture ontology.

[0021] Furthermore, the present invention also includes the evaluation of traceability relationships, that is, evaluating the traceability relationship between a requirement and its superior requirement, and evaluating the traceability relationship between a requirement and an architectural design element; the traceability relationship between the requirement and its superior requirement and the traceability relationship between the requirement and the architectural design element are evaluated, and when the traceability relationship is not satisfied, the traceability relationship is re-established.

[0022] Furthermore, in the present invention, the sources of requirements collected from different sources, different levels and different types include user requirements, regulatory requirements, market requirements and internal enterprise requirements, the requirement levels include system level, subsystem level, component level, module level and part level, the requirement types include functional requirements, performance requirements, design constraints, safety requirements, environmental requirements and legal and regulatory requirements, and the requirement ontology is designed based on the requirement exchange format ReqIF.

[0023] Furthermore, the requirement ontology of the present invention includes requirement attribute definitions, requirement data types, requirement items, requirement item associations, requirement forms, requirement association groups, and requirement hierarchies.

[0024] Furthermore, the mapping rule between the demand model and the demand ontology is determined as follows:

[0025] Map the requirement meta-metamodel to the classes and first-level subclasses in the requirement ontology;

[0026] Map the requirement metamodel to the secondary subclass or the subclass of the primary subclass in the requirement ontology;

[0027] The demand model layer is mapped to the instance of the corresponding class or first- and second-level subclasses in the demand ontology, and the relationship between the elements in the demand model layer is mapped to the object attributes between the corresponding instances.

[0028] Furthermore, the architecture ontology of the present invention includes graphs, objects, points, attributes, relationships, roles, and extended constraints.

[0029] Furthermore, the mapping rule between the architecture model and the architecture ontology is determined as follows:

[0030] Map the graph metamodel, object metamodel, attribute metamodel, point metamodel, relationship metamodel, and role metamodel to classes in the architecture ontology;

[0031] Map the graph metamodel, object metamodel, attribute metamodel, point metamodel, relationship metamodel, and role metamodel to subclasses of the corresponding classes in the architecture ontology;

[0032] The model layer is mapped to an instance of a corresponding subclass or an instance of a subclass of a subclass in the architecture ontology, and the relationship between elements in the model layer is mapped to the object attributes of the corresponding class or subclass.

[0033] Furthermore, the present invention establishes a traceability relationship between a requirement and its superior requirement by decomposing the system requirement into subsystem requirements and component requirements layer by layer through the object attribute "derivation", and establishing a traceability relationship between the requirement and its superior requirement.

[0034] The traceability relationship between the evaluation requirement and its superior requirement is: if a requirement is derived from its superior requirement, or it derives other requirements, then the requirement meets the traceability between the requirement and its superior requirement; if a requirement has neither a superior requirement nor derives other requirements, then the requirement does not meet the traceability between the requirement and its superior requirement.

[0035] Furthermore, the present invention establishes a traceability relationship between a requirement and an architecture design element as follows: establishes a traceability relationship between a requirement entity and an architecture design element entity in an integrated ontology, and connects the requirement entity and the architecture design element entity through the object attribute "traceability";

[0036] If there is no traceability relationship between the requirements and the architectural design elements, the traceability between the requirements and the architectural design elements is not met; if there is one or more traceability relationships between the requirements and the architectural design elements, it is defined as meeting the traceability between the requirements and the architectural design elements.

[0037] Beneficial Effects

[0038] First, the present invention proposes an integrated ontology of requirements and architecture, supports the unified semantic expression of heterogeneous requirement models and architecture models, and further realizes requirement traceability between heterogeneous requirement models and between requirement models and architecture models.

[0039] Second, the present invention combines the ReqIF standard and the GOPPRR-E metamodeling method to propose an ontology-based complex system design process requirement tracing method, which supports requirement tracing between heterogeneous requirement models and design process models in the complex system design process.

[0040] Third, based on the top-level ontology BFO and the middle-level ontology IoF-Core, the present invention designs the integrated ontology of complex system requirements and design process from top to bottom, and supports the semantic unified expression of heterogeneous requirement models and design process models in the complex system design process. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0042] Figure 1A flowchart of a method for tracing requirements of a complex system design process based on ontology according to the present invention;

[0043] Figure 2 It is the integrated ontology framework diagram;

[0044] Figure 3 It is a schematic diagram of the design requirement ontology;

[0045] Figure 4 This is the four-layer structure framework diagram of the meta-object mechanism;

[0046] Figure 5 It is a schematic diagram of the mapping rules between the demand model and the demand ontology;

[0047] Figure 6 Schematic diagram of GOPPRR-E metamodeling;

[0048] Figure 7 Design the architectural ontology diagram based on the GOPPRR-E meta-modeling method;

[0049] Figure 8 Schematic diagram of the mapping rules between architecture model and architecture ontology. DETAILED DESCRIPTION

[0050] The embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0051] It should be noted that the following embodiments and features in the embodiments may be combined with each other in the absence of conflict; and, based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in the field without making any creative work are within the scope of protection of the present disclosure.

[0052] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein may be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on the present disclosure, it should be understood by those skilled in the art that an aspect described herein may be implemented independently of any other aspect, and two or more of these aspects may be combined in various ways. For example, any number of aspects described herein may be used to implement the device and / or practice the method. In addition, other structures and / or functionalities other than one or more of the aspects described herein may be used to implement this device and / or practice this method.

[0053] The embodiment of the present application provides a complex system design process requirement tracing method based on ontology, and its design concept is:

[0054] Firstly, the top-level ontology BFO (Basic Formal Ontology) and the middle-level ontology IoF-Core (Industrial Ontologies Foundry, IoF) are introduced, and an integrated ontology framework of requirement ontology and architecture ontology is proposed. Under the guidance of the integrated ontology framework, the requirement ontology is designed based on the requirements exchange format ReqIF (Requirements Interchange Format, ReqIF), and the mapping rules between the requirement model and the ontology are defined to achieve the semantic unified expression of the requirement model.

[0055] Secondly, based on the GOPPRR-E (graph, object, point, attribute, role, relationship six meta-metamodels and the rules and constraints between them) metamodeling method, the architecture ontology is designed, and the mapping rules between the architecture model and the ontology are defined to achieve the semantic unified expression of the architecture model; a top-down, well-structured integrated ontology of requirements and architecture is formed, and the semantic unified expression of the requirement model and the architecture model is achieved through the integrated ontology.

[0056] Finally, the semantic expression of the traceability relationship between the requirement model and the architecture model is realized based on the integrated ontology, and the evaluation of requirement traceability is realized by constructing semantic query rules. The specific steps are as follows: Figure 1 shown.

[0057] Step 1: Build an integrated ontology framework including requirement ontology and architecture ontology

[0058] First, we introduce the top-level ontology BFO. BFO is a top-level ontology developed to support the integration, analysis, and integration of scientific research data. It is designed to be more concise and convenient for scientists in different fields and granularity levels to reuse. It is small and precise. BFO provides a general, basic top-level ontology framework for describing concepts and relationships in various fields.

[0059] Then, the middle-level ontology IoF-Core is introduced. The IoF-Core ontology is extended based on the BFO ontology. The introduction of the IoF-Core ontology aims to ensure that the demand ontology and architecture ontology in the engineering field are developed in a structured and semantically consistent way, and solve the problem of interoperability between the demand ontology and architecture ontology in the complex system design process.

[0060] This method is mainly used to achieve semantic integration of heterogeneous requirement models and architecture models in complex system design in the engineering field (semantic integration refers to the integration of knowledge from different sources to ensure that the system can understand and process this knowledge and maintain its semantic consistency), which is consistent with the requirements specification and design specification content under the information content entity in the IoF-Core ontology. Therefore, the design integration ontology framework is as follows Figure 2 shown.

[0061] Step 2: Design a requirements ontology for complex systems

[0062] Collect requirements from different sources, levels and types of complex systems, and design the requirement ontology based on the requirement exchange format ReqIF and the ontology language OWL (Web Ontology Language, OWL).

[0063] This step takes a certain type of electric vehicle automatic driving system as an example. According to the design characteristics of a certain type of electric vehicle automatic driving system, its demand sources include user demand, regulatory demand, market demand, and internal enterprise demand; the demand levels involved cover different levels such as system level, subsystem level, component level, module level, and part level; the demand types involved include functional requirements, performance requirements, design constraints, safety requirements, environmental requirements, and legal and regulatory requirements. In order to achieve a unified semantic expression of requirements from different sources, different levels, and different types, a demand ontology is designed based on the demand exchange format ReqIF and the ontology language OWL (Web Ontology Language, OWL), such as Figure 3 In this step, the demand ontology refers to the specific content of the demand, but due to the different sources of demand, different demand models will exist between different demands.

[0064] Step 3: Determine the mapping rules between the demand model and the demand ontology

[0065] Since the expression models of different sources, levels and types may be different, this step is needed to uniformly map different demand models into the expression of demand ontology under the integrated ontology framework, so as to achieve semantically consistent expression of demand.

[0066] Meta Object Facility (MOF) is a metadata description specification proposed by OMG and has been incorporated into ISO standard ISO / IEC 19502:2005. MOF defines an abstract language and framework for specifying, building and managing technology-independent metamodels (such as UML, etc.). The framework consists of four layers, such as Figure 4 shown.

[0067] The MOF framework promotes the standardization and interoperability of metadata. The specific meanings of the M3-M0 layers are as follows:

[0068] Meta-metamodel layer (M3): The meta-metamodel layer is the highest level of abstraction in the MOF framework.

[0069] Metamodel layer (M2): A metamodel is an instance of a meta-metamodel.

[0070] ●Model layer (M1): The model is an instance of the metamodel, and the model is built based on the metamodel.

[0071] ●System perspective layer (M0): The system perspective is a perspective that describes real-world objects / systems. It describes the areas and issues that stakeholders are concerned about, such as the demand perspective of complex equipment systems.

[0072] Based on the MOF mechanism, determine the mapping rules between the demand model and the classes, subclasses, instances, object attributes and other elements in the demand ontology. Figure 5 As shown (In OWL, assertions are used to describe the relationship between instances or the relationship between instances and classes.).

[0073] (1) Meta-metamodel layer mapping

[0074] The requirement meta-metamodel is mapped to the classes and sub-classes (first-level sub-classes, i.e., the next-level sub-classes are also included) in the requirement ontology. For example, the "requirement form" meta-metamodel based on the ReqIF standard is mapped to the class-requirement form.

[0075] (2) Metamodel layer mapping

[0076] The requirement metamodel, i.e., the specific requirement form type, requirement item type, requirement item association type, association group type, attribute definition type, and data type, is mapped to a subclass (second-level subclass, excluding the next-level subclass) or a subclass of a subclass (a subclass of a first-level subclass) in the requirement ontology. For example, "functional requirement form type" is mapped to a subclass of the requirement form with type - functional requirement form type. In addition, the relationship between the requirement metamodel is mapped to object attributes between classes (subclasses) and classes (subclasses), for example, the "has" relationship between "functional requirement form type" and the "name" attribute is mapped to an object attribute. The inherent attributes of the requirement metamodel are mapped to the annotation attributes possessed by the class (subclass), for example, the unique identifier of the "functional requirement form type" is mapped to the annotation attribute - identifier.

[0077] (3) Model layer mapping

[0078] The model layer is mapped to the instance of the corresponding class or subclass in the requirement ontology, for example, "electric vehicle functional requirement model" is mapped to the instance of the class-functional requirement form type. The relationship between the elements in the requirement model is mapped to the object attributes between the corresponding instances, for example, the "has" relationship between the "autonomous driving functional requirement model" and the "brake control" requirement is mapped to the object attributes between the corresponding instances of the two. In addition, the inherent attributes of the requirement model are mapped to the annotation attributes of the class (subclass), for example, the unique identifier of the requirement model is mapped to the annotation attribute -identifier.

[0079] Based on the above mapping rules, semantically consistent expression of requirements is achieved by mapping requirement models of different formats into requirement ontology based on a unified framework.

[0080] Step 4: Design an architectural ontology for complex systems

[0081] The architectural ontology designed based on the GOPPRR-E meta-modeling method includes: graphs, objects, points, attributes, relationships, roles, and extended constraints.

[0082] In the design process of an electric vehicle autonomous driving system, this step involves using SysML parameter diagrams to define the parameters of the autonomous driving system, using BPMN (Business Process Model and Notation, BPMN) flowcharts to describe the functional scenario process of the autonomous driving system, and using EAST-ADL's vehicle feature model to describe the features of the autonomous driving system. Architecture models described by different modeling languages ​​face the problem of data structure and semantic heterogeneity. For example, the autonomous driving system parameter definition model uses "v" to represent the vehicle speed, and the autonomous driving system vehicle feature model uses "speed" to represent the vehicle speed, making it difficult to ensure consistent traceability and verification of requirements in various models.

[0083] In order to achieve the unified semantic expression of heterogeneous architecture models, by comparing the existing meta-meta models, it is found that GOPPRR has the strongest architecture description capability. Based on the MOF mechanism and the GOPPRR meta-meta model and its extension, the GOPPRR-E meta-modeling method is formed, such as Figure 6 shown.

[0084] The connotation of GOPPRR-E is as follows:

[0085] Diagram: A collection of entities such as objects, relationships, and roles, presented in a specific layout (e.g., a SysML module definition diagram).

[0086] Object: An entity that constructs a diagram, for example, a module in a SysML module definition diagram.

[0087] Attributes: are inherent properties of metamodel diagrams, objects, relationships, roles, and nodes, such as the name of a module.

[0088] Point: is an additional port of an object, for example, a flow port, a proxy port, etc. in a SysML internal block diagram.

[0089] Relationship: A connection between points and / or objects, for example, a connection "directed combination" in a SysML module definition diagram.

[0090] Role: used to define the direction and form of expression at both ends of a relationship. A relationship is associated with two roles. For example, the starting role of the relationship "Directed Combination" in the SysML module definition diagram is a solid diamond, and the terminal role is an arrow.

[0091] Extension: refers to the constraints on which objects / points the roles at both ends of the relationship can be connected to. For example, the starting role of the "directed combination" relationship in the SysML module definition diagram can be connected to the module.

[0092] Design the architecture ontology based on the GOPPRR-E meta-modeling method, such as Figure 7 shown.

[0093] Step 5: Determine the mapping rules between the architecture model and the architecture ontology

[0094] In step 4, the requirement architecture is based on GOPPRR-E metamodeling. In order to unify the requirement architecture into the integrated ontology framework, this step is required to map it into the expression of the architecture ontology under the integrated ontology framework, so as to achieve semantically consistent expression of the architecture model.

[0095] Based on the MOF mechanism and GOPPRR-E metamodeling method, the mapping rules between the architecture model and the classes, instances, object attributes and other elements in the architecture ontology are constructed. Figure 8 shown.

[0096] (1) Meta-metamodel layer mapping

[0097] The graph metamodel, object metamodel, attribute metamodel, point metamodel, relationship metamodel, and role metamodel are mapped to classes in the architecture ontology; for example, the "graph metamodel" is mapped to a class-graph.

[0098] (2) Metamodel layer mapping

[0099] The graph metamodel, object metamodel, attribute metamodel, point metamodel, relationship metamodel, and role metamodel are mapped to subclasses of the corresponding classes in the architecture ontology; for example, the graph metamodel "module definition diagram" is mapped to the subclass "module definition diagram" of the class-diagram, and the object metamodel "module" is mapped to the subclass "module" of the class-object. The relationship between metamodels is mapped to the object attributes between subclasses, for example, the "inclusion" relationship between the graph metamodel "module definition diagram" and the object metamodel "module" is mapped to the object attribute "inclusion". In addition, the inherent attributes of the metamodel are mapped to the annotation attributes of the class, for example, the "local name" is mapped to the annotation attribute "local name".

[0100] (3) Model layer mapping

[0101] The model layer is mapped to the instance of the corresponding subclass in the architecture ontology or the instance of the subclass of the subclass, for example, the "vehicle control system functional architecture model" is mapped to the instance of the subclass "module definition diagram". The constraint relationship between the elements in the model is mapped to the object attributes of the corresponding class or subclass, for example, the "inclusion" relationship between the "vehicle control system functional architecture model" and the "acceleration control function" is mapped to the object attribute "inclusion" of both. The "refinement" relationship between the "autonomous driving function" and the "acceleration control function" is mapped to the instance of the "refinement" subclass of the "relationship", as well as the instances of the "refinement role start" and "refinement role end" of the "role" subclass. The "refinement role start" can be connected to the "autonomous driving function" and mapped to the extended instance. In addition, the inherent attributes of the model are mapped to the annotation attributes of the instance, for example, the "shape" of the object is mapped to the annotation attribute "shape" of the object instance. The attribute content of the model is mapped to the data attributes of the attribute metamodel instance. For example, the attribute "speed" of the module of "acceleration control function" is "100km / h", which is mapped to the attribute metamodel instance "speed", and its data attribute value is "100km / h".

[0102] Based on the above mapping rules, by mapping heterogeneous architecture models into architecture ontology based on a unified framework, the semantically consistent expression of architecture models in the complex system design process is achieved.

[0103] Step 6: Establish demand traceability relationship

[0104] Step 6.1: Establish a traceability relationship between the requirement and its parent requirement

[0105] Decompose system requirements layer by layer into subsystem requirements and component requirements through object attribute "derivation", and establish a traceability relationship between requirements and their superior requirements.

[0106] Define the object attribute "derived" to indicate the relationship that a requirement is derived from its previous requirement, clarify the source of the requirement, and record the decomposition process of the requirement from system-level requirements to subsystem requirements and component requirements. Based on the concepts and relationships in the requirement ontology, establish a traceability relationship between the requirement entity and its parent requirement entity in the integrated ontology, and connect the requirement entity with the requirement entity through the object attribute "derived".

[0107] This step takes a certain model of electric vehicle automatic driving system as an example. In the design process of a certain model of electric vehicle automatic driving system, the system requirements need to be decomposed into subsystem requirements and component requirements layer by layer to ensure that the requirements at all levels can be effectively implemented and verified. For example, the system-level requirement "the automatic driving system needs to achieve autonomous driving on the highway" is decomposed as follows:

[0108] System-level requirements: The autonomous driving system needs to achieve autonomous driving on highways.

[0109] Subsystem requirements: 1-The perception system needs to be able to detect and identify obstacles ahead; 2-The control system needs to be able to make corresponding driving decisions based on the input from the perception system.

[0110] Component requirements: 1-The radar sensor needs to be able to accurately detect obstacles within a range of 200 meters; 2-The computing unit needs to be able to process the perception data and generate control instructions within 100 milliseconds.

[0111] The requirement ontology is used to achieve a unified description of the requirements at different levels. In the requirement ontology, the system-level requirement (autonomous driving requirement) entity is decomposed into subsystem requirement entities (perception system requirements, control system requirements) through the object attribute "derivation". The subsystem requirement (perception system requirement) entity is further decomposed into component requirement (radar sensor requirement) entity through the object attribute "derivation". The subsystem requirement (control system requirement) entity is further decomposed into component requirement (computing unit requirement) entity through the object attribute "derivation". This enables the traceability between requirements and their superior requirements.

[0112] Step 6.2: Establish traceability between requirements and architectural design elements

[0113] In the integrated ontology, a traceability relationship is established between the requirement entity and the architecture design element entity, and the requirement entity and the architecture design element entity are connected through the object attribute "traceability".

[0114] Define the object attribute "traceability" to indicate the traceability relationship between requirements and architectural design elements, and to clarify which architectural design elements satisfy or verify the requirements. Based on the concepts and relationships in the requirements ontology and the architectural ontology in the integrated ontology, establish a traceability relationship between the requirements entity and the architectural design element entity in the integrated ontology, and connect the requirements entity and the architectural design element entity through the object attribute "traceability".

[0115] This step takes a certain type of electric vehicle autonomous driving system as an example. In the design process of a certain type of electric vehicle autonomous driving system, system requirements need to be mapped layer by layer to specific architecture design elements to ensure that requirements at all levels can be effectively implemented and verified. For example, system-level requirements include autonomous driving requirements, subsystem-level requirements include perception system requirements and control system requirements. Among the architecture design elements, the perception system architecture includes cameras, radars, and lidars; the control system architecture includes decision algorithm modules and controller hardware; and the communication system architecture includes V2X (vehicle-to-everything communication) modules and internal buses.

[0116] An integrated ontology is used to achieve a unified semantic expression of the demand model and the architecture model. Based on the integrated ontology, the system-level requirements (autonomous driving requirements) are mapped to the perception system architecture, control system architecture, and communication system architecture through the object attribute "traceability". The perception system requirements (detecting obstacles ahead) are mapped to the camera, radar, and lidar design elements through the object attribute "traceability". The control system requirements (generating driving decisions) are mapped to the decision algorithm module and controller hardware design elements through the object attribute "traceability".

[0117] By defining and using the object attribute "traceability", the traceability relationship between requirements and architectural design elements can be accurately represented and recorded in the requirements ontology and architecture ontology. In this way, it is clear which architectural design elements satisfy or verify the requirements, thereby effectively supporting the traceability and management of requirements in complex system design.

[0118] Step 7: Requirements traceability assessment

[0119] The integrated ontology achieves semantic consistency between models built by different modeling languages ​​and tools through semantic integration of requirement models and architecture models, thereby supporting information association and traceability of requirement models and architecture models. By tracing requirements to their superior requirements, it is possible to ensure that the source and purpose of the requirements are clear, and to maintain consistency and integrity in system design. By tracing requirements to corresponding architectural design elements, it is helpful to ensure that each requirement is considered and processed accordingly during the design phase, thereby further ensuring that the requirements are met. Therefore, in order to ensure that each requirement is traced back to its source and implementation, a requirement traceability assessment is performed based on the integrated ontology.

[0120] Step 7.1: Assessment of traceability between requirements and their superior requirements

[0121] If a requirement is derived from its parent requirement, or it derives other requirements, then the requirement meets the traceability between the requirement and its parent requirement. If a requirement has neither a parent requirement nor other requirements, then the requirement does not meet the traceability between the requirement and its parent requirement. This evaluation method ensures that the source and derivation relationship of each requirement in the system design process are clear, thereby ensuring the integrity and consistency of requirement management.

[0122] This step takes a certain model of electric vehicle automatic driving system as an example. The design of a certain model of electric vehicle automatic driving system includes multiple levels of requirements, from system-level requirements to subsystem requirements and then to component requirements. The example is as follows:

[0123] (1) Demand decomposition

[0124] A. System-level requirements: The autonomous driving system needs to achieve autonomous driving on highways.

[0125] B. Subsystem requirements: 1- The perception system needs to detect obstacles ahead in real time; 2- The control system needs to generate safe driving decisions.

[0126] C. Component requirements: 1-The camera must be able to identify obstacles; 2-The decision-making algorithm module must generate a driving path based on the perception data.

[0127] (2) Traceability between requirements and their superior requirements

[0128] A. System-level requirements (autonomous driving) derive subsystem requirements (perception system requirements and control system requirements).

[0129] B. Subsystem requirements (perception system requirements) further derive component requirements (camera requirements).

[0130] C. Subsystem requirements (control system requirements) further derive component requirements (decision-making algorithm module requirements).

[0131] (3) Traceability between requirements and their superior requirements based on integrated ontology

[0132] A. There is an object attribute "derived" relationship between the system-level requirements (autonomous driving) entity and the perception system requirements entity and the control system requirements entity, which complies with traceability.

[0133] B. There is an object attribute "derivation" relationship between the perception system requirement entity and the camera requirement entity, which complies with traceability.

[0134] C. There is an object attribute "derivation" relationship between the control system requirement entity and the decision algorithm module requirement entity, which complies with traceability.

[0135] D. Although there is no object attribute "derivation" relationship between the camera requirement entity and the decision algorithm module requirement entity, there is an object attribute "derivation" relationship between other requirement entities and the camera requirement entity, so it also complies with traceability.

[0136] (4) Handling requirements that do not meet traceability requirements

[0137] Suppose there is a requirement (for example, the requirement for an in-vehicle entertainment system). If it has neither a superior requirement nor derived other requirements, it is necessary to re-examine whether the requirement is reasonable, or to clarify its superior requirements and derived relationships to ensure traceability.

[0138] Step 7.2: Evaluate traceability between requirements and architectural design elements

[0139] A requirement may be implemented by one or more architectural design elements. If there is no traceability relationship between a requirement and an architectural design element, it does not meet the traceability between the requirement and the architectural design element; if there is one or more traceability relationships between a requirement and an architectural design element, it is defined as meeting the traceability between the requirement and the architectural design element. This evaluation method ensures that the requirements can be effectively considered and implemented during the design phase, thereby ensuring the consistency of system design.

[0140] This step takes a certain type of electric vehicle automatic driving system as an example. The design of a certain type of electric vehicle automatic driving system involves multiple architecture design elements, such as sensors, algorithm modules, and control units. These elements work together to achieve the functional and performance requirements of the system.

[0141] (1) Traceability between requirements and architectural design elements

[0142] Autonomous driving requirements are implemented by sensor modules, control algorithm modules, and actuator modules. There is a traceability relationship between autonomous driving requirements and these architectural design elements.

[0143] (2) Traceability between requirements and architectural design elements based on integrated ontology assessment

[0144] There is an object attribute "traceability" relationship between the autonomous driving requirement entity and the sensor module, control algorithm module and actuator module, so the requirement meets the traceability between the requirement and the architectural design elements.

[0145] (3) Handling requirements that do not meet traceability requirements

[0146] Suppose there is a requirement (for example, the user interface requirement of an autonomous driving system). If no traceability relationship with any architectural design element is found, it is necessary to review the requirement or define corresponding architectural design elements to implement the requirement.

[0147] In summary, the method proposed in the present invention solves the problems of semantic inconsistency and difficulty in tracing requirements between heterogeneous models in the design process of complex systems based on MBSE. It can realize the semantic integration of heterogeneous requirement models and architectural models, ensure the semantic consistency between heterogeneous requirement models and architectural models, and support the construction and evaluation of requirement traceability relationships.

[0148] In summary, the present invention belongs to the fields of complex system design, model-based systems engineering, ontology, and demand management, and specifically relates to an ontology-based method for demand tracing in a complex system design process, which includes: constructing an integrated ontology framework of heterogeneous demand models and architecture models; designing a demand ontology; defining mapping rules between demand models and demand ontology; designing an architecture ontology; defining mapping rules between architecture models and architecture ontology; based on the integrated ontology, establishing a traceability relationship between a demand and its superior demand, and a traceability relationship between a demand and an architecture design element; then, automatically evaluating demand traceability, and improving relevant demand traceability relationships based on the evaluation results; in order to more intuitively and clearly display the traceability relationships between demands and demands, and between demands and architecture design elements, the above-mentioned integrated ontology is used to generate a knowledge graph to support visual graph display of demand traceability relationships.

[0149] In the context of complex system design based on MBSE, the present invention proposes a requirement tracing method for the complex system design process based on ontology, focusing on the traceability relationship between system requirements and their superior requirements, and between requirements and architectural design elements. The method realizes the semantically unified expression and tracing of requirement models from different sources, at different levels, and of different types, and the semantically unified expression of these requirement models and architectural models in different fields. Through semantic association, the method can effectively realize requirement tracing and evaluation, thereby significantly improving the efficiency of requirement change and its impact analysis.

[0150] This application has the following innovations:

[0151] First, BFO is a top-level ontology developed to support the integration, analysis, and integration of scientific research data. It supports the interoperability of ontologies in different fields by providing a concise public architecture. The IoF-Core ontology is a middle-level ontology in the engineering field proposed by IoF based on BFO to ensure that the ontology in the engineering field is developed in a structured and semantically consistent manner. The present invention integrates the engineering field requirement ontology and architecture ontology from top to bottom based on BFO and IoF-Core, supports the semantically unified expression and interoperability of heterogeneous requirement models and architecture models, and solves the problem of difficulty in tracing requirements between heterogeneous requirement models and architecture models. The use of internationally common and standardized BFO and IoF-Core ontologies not only improves the structuring and maintainability of the ontology, but also enhances the management and requirement tracing capabilities of various models in the design process of complex systems.

[0152] Second, ReqIF has a rich metamodel that can cross the boundaries of tools and organizations for lossless data exchange. In the field of requirements management, ReqIF has become the OMG standard for exchanging requirements between different requirements management tools. Currently, there is no standard or language that can replace all the functions of the ReqIF standard. The ReqIF standard has become the most applicable and comprehensive requirements standard at present because of its comprehensive definition of requirements and flexible data exchange and management mechanism. Therefore, the present invention designs a requirements ontology based on the ReqIF standard. Through standardized requirements definition and exchange mechanism, it can support the semantically unified expression and interoperability of heterogeneous requirements models, so that requirements models from different sources and formats can be managed and traced within a unified framework, solving the difficulties in demand tracing caused by the heterogeneity of requirement models.

[0153] Third, by analyzing and comparing the meta-metamodels of the existing metamodeling methods ARIS, Ecore, GME, GOPPRR, MSDSL Tools and MS Visio, it is found that GOPPRR is one of the most expressive meta-metamodels. The GOPPRR-E metamodeling method is proposed based on GOPPRR to further enrich the expressive power of the metamodel. The construction of metamodels in different fields is realized through the GOPPRR-E meta-metamodel, and the unified construction of heterogeneous modeling languages ​​is realized based on metamodels in different fields, thereby supporting the construction of multi-level / multi-domain architecture models. Therefore, the present invention designs an architecture ontology based on the GOPPRR-E metamodeling method, which can support the unified semantic expression and interoperability of multi-level / multi-domain architecture models, and solves the difficulty of demand tracing caused by the heterogeneity of architecture models.

[0154] The above embodiments are only used to illustrate the present invention, wherein the requirement models and architecture models of each system level can be constructed using different modeling languages ​​and standards. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be regarded as the scope of protection of the present invention.

[0155] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed by the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A complex system design process requirement tracing method based on ontology, characterized in that: The specific process is: Build an integrated ontology framework including requirement ontology and architecture ontology; For complex systems, collect requirements from different sources, at different levels, and of different types, and design the requirements ontology based on the ReqIF requirements exchange format; for complex systems, design the architecture ontology based on the GOPPRR-E metamodeling method; Determine the mapping rules between demand models and demand ontology, and map demand models of different sources, different levels, and different types into demand ontology based on a unified framework; determine the mapping rules between architecture models and architecture ontology, and map architecture models into architecture ontology based on a unified framework; Establish a traceability relationship between requirements and their superior requirements, and establish a traceability relationship between requirements and architectural design elements.

2. The ontology-based complex system design process requirement tracing method according to claim 1 is characterized in that: It also includes the evaluation of traceability relationships, that is, evaluating the traceability relationship between requirements and their superior requirements, and evaluating the traceability relationship between requirements and architectural design elements; the traceability relationship between the requirements and their superior requirements and the traceability relationship between requirements and architectural design elements are evaluated, and when the traceability relationship is not satisfied, the traceability relationship is re-established.

3. The ontology-based complex system design process requirement tracing method according to claim 1 or 2 is characterized in that: The top-level ontology BFO and the middle-level ontology IoF-Core are introduced to build an integrated ontology framework including demand ontology and architecture ontology.

4. The ontology-based complex system design process requirement tracing method according to claim 1 or 2 is characterized in that: The requirements collected from different sources, levels and types include user requirements, regulatory requirements, market requirements and internal enterprise requirements; the requirement levels include system level, subsystem level, component level, module level and part level; the requirement types include functional requirements, performance requirements, design constraints, safety requirements, environmental requirements and legal and regulatory requirements; and the requirement ontology is designed based on the requirement exchange format ReqIF.

5. The ontology-based complex system design process requirement tracing method according to claim 4 is characterized in that: The requirement ontology includes requirement attribute definitions, requirement data types, requirement items, requirement item associations, requirement forms, requirement association groups, and requirement hierarchies.

6. The ontology-based complex system design process requirement tracing method according to claim 5 is characterized in that: The mapping rule between the demand model and the demand ontology is as follows: Map the requirement meta-metamodel to the classes and first-level subclasses in the requirement ontology; Map the requirement metamodel to the secondary subclass or the subclass of the primary subclass in the requirement ontology; The demand model layer is mapped to the instance of the corresponding class or first- and second-level subclasses in the demand ontology, and the relationship between the elements in the demand model layer is mapped to the object attributes between the corresponding instances.

7. The ontology-based complex system design process requirement tracing method according to claim 1 or 2 is characterized in that: The architecture ontology includes graphs, objects, nodes, attributes, relationships, roles, and extension constraints.

8. The ontology-based complex system design process requirement tracing method according to claim 7 is characterized in that: The mapping rules between the architecture model and the architecture ontology are as follows: Map the graph metamodel, object metamodel, attribute metamodel, point metamodel, relationship metamodel, and role metamodel to classes in the architecture ontology; Map the graph metamodel, object metamodel, attribute metamodel, point metamodel, relationship metamodel, and role metamodel to subclasses of the corresponding classes in the architecture ontology; The model layer is mapped to an instance of a corresponding subclass or an instance of a subclass of a subclass in the architecture ontology, and the relationship between elements in the model layer is mapped to the object attributes of the corresponding class or subclass.

9. The ontology-based complex system design process requirement tracing method according to claim 1 is characterized in that: The establishment of the traceability relationship between the demand and its superior demand is: decomposing the system demand into subsystem demand and component demand layer by layer through the object attribute "derive", and establishing the traceability relationship between the demand and its superior demand; The traceability relationship between the evaluation requirement and its superior requirement is: if a requirement is derived from its superior requirement, or it derives other requirements, then the requirement meets the traceability between the requirement and its superior requirement; if a requirement has neither a superior requirement nor derives other requirements, then the requirement does not meet the traceability between the requirement and its superior requirement.

10. The ontology-based complex system design process requirement tracing method according to claim 1 is characterized in that: The establishment of the traceability relationship between the requirements and the architecture design elements is as follows: establishing the traceability relationship between the requirements entity and the architecture design element entity in the integrated ontology, and connecting the requirements entity and the architecture design element entity through the object attribute "traceability"; If there is no traceability relationship between requirements and architectural design elements, then the traceability between requirements and architectural design elements is not met; If there are one or more traceability relationships between requirements and architectural design elements, it is defined as meeting the traceability between requirements and architectural design elements.

Images