An ontology-based autonomous transportation system architecture diagnostic method

Abstract

An ontology-based autonomous transportation system architecture diagnostic method is disclosed, relating to the field of autonomous transportation system architecture diagnostic technology. This method addresses the problem that existing system architecture diagnostic methods, due to their reliance on specific scenarios, cannot autonomously diagnose the correctness and completeness of architecture design. The invention represents concepts in the architecture as classes, adds class hierarchies and creates class attributes, establishing a prior ontology and a diagnostic ontology for the autonomous transportation system architecture. These classes include requirement-related classes, function-related classes, and physical object-related classes. Based on the prior ontology, the method verifies the correctness of classes and their hierarchical structure in the diagnostic architecture ontology, as well as the correctness and completeness of requirement-related, function-related, and physical object-related classes. It also outputs errors present in the diagnostic architecture ontology, thereby completing the diagnosis of the correctness and completeness of the architecture design. This invention can help designers avoid potential errors during the autonomous transportation system architecture design process.

Description

Technical Field

[0001] This invention relates to the field of autonomous transportation system architecture diagnostics, and more specifically to an ontology-based autonomous transportation system architecture diagnostics method. Background Technology

[0002] With the development of technologies such as autonomous driving and vehicle-to-infrastructure (V2I) communication, existing transportation systems are evolving from intelligent transportation systems to autonomous transportation systems. The essence of autonomous transportation systems is to reduce human intervention and complete passenger and freight transportation through self-organized operation and autonomous services. Autonomous transportation system architecture can be described in an abstract way, independent of traffic scenarios, from logical, functional, and physical perspectives. This makes the diagnostic methods for autonomous transportation system architecture design scenario-independent. By diagnosing the user-designed autonomous transportation system architecture, potential problems in the architecture design can be identified before the implementation of the autonomous transportation system, ensuring its smooth implementation.

[0003] An ontology is a well-defined specification of a conceptual model, used to describe concepts and relationships within a specific domain or even a broader scope. It ensures that these concepts and relationships have a shared, clear, and unique definition, enabling communication between humans and machines, as well as between machines themselves. An ontology provides domain-specific concepts, object types, hierarchical semantic relationships, and their attributes. Existing ontology-based traffic system diagnostic methods are designed for traditional traffic systems and depend on specific traffic scenarios; therefore, they cannot be used for diagnosing autonomous traffic systems. Summary of the Invention

[0004] In view of the above problems, this invention proposes an ontology-based autonomous transportation system architecture diagnosis method to solve the problem that existing system architecture diagnosis methods cannot autonomously diagnose the correctness and completeness of the architecture design because they depend on specific scenarios.

[0005] An ontology-based autonomous transportation system architecture diagnostic method includes the following steps:

[0006] Step 1: Represent the concepts in the architecture as classes, add class hierarchies to form a class hierarchy, and create class attributes to express the relationships, thereby establishing the prior ontology and the architecture to be diagnosed for the autonomous transportation system architecture; the classes include requirement-related classes, function-related classes, and physical object-related classes;

[0007] Step 2: Based on the prior ontology of the autonomous transportation system architecture, verify whether the classes and their hierarchical structure in the ontology of the architecture to be diagnosed are correct, whether the requirement-related classes, function-related classes, and physical object-related classes are correct and complete, and output the errors and error types existing in the ontology of the architecture to be diagnosed, thereby completing the diagnosis of the correctness and completeness of the architecture design to be diagnosed.

[0008] Furthermore, the attributes of the class mentioned in step one include data attributes and object attributes, wherein the object attributes are used to express the association relationship between two classes.

[0009] Furthermore, the requirement-related classes mentioned in step one include multiple subclasses; the function-related classes include service domain classes, service classes, sub-service classes, and atomic function classes; the physical object-related classes include first-level physical object classes, second-level physical object classes, third-level physical object classes, and fourth-level physical object classes.

[0010] Furthermore, the specific steps of step two include:

[0011] Step 2: For each class in the architecture ontology to be diagnosed, check whether there is a class with the same name in the prior ontology. If not, the error type is concept reference error. If it exists, check whether the level of the class in the architecture ontology to be diagnosed is consistent with the level in the prior ontology. If they are inconsistent, the error type is concept level error.

[0012] Step 22: Using the requirements corresponding to the requirement-related classes in the architecture ontology to be diagnosed as the query conditions, query the service domain class corresponding to the requirement in the prior ontology; compare whether the service domain class corresponding to the requirement in the architecture ontology to be diagnosed is consistent with that in the prior ontology. If they are inconsistent, output the error type as "service domain and requirement do not match"; if they are consistent, check the hierarchical relationship of service domain class, service class, sub-service class, and atomic function class in the architecture ontology to be diagnosed layer by layer to see if it is correct. If it is incorrect, output the error type as "functional inclusion relationship error".

[0013] Steps 2 and 3: Using the service domain corresponding to the service domain class in the architecture ontology to be diagnosed as the query condition, query the physical object class corresponding to the service domain in the prior ontology; compare whether the physical object class corresponding to the service domain in the architecture ontology to be diagnosed is consistent with that in the prior ontology. If consistent, continue to check the correspondence between service class and physical object class; if inconsistent, output the error type as "current layer physical object reference error"; and check the correspondence between service class, sub-service class, atomic function class and physical object class in the architecture ontology to be diagnosed layer by layer according to the above process, and output the error type.

[0014] Step 24: For each function corresponding to the function-related class in the architecture ontology to be diagnosed, query its predecessor or successor function, as well as the inflow or outflow data flow, in both the architecture ontology to be diagnosed and the prior ontology, and compare the query results. If the predecessor or successor function of the function in the prior ontology is inconsistent with that in the architecture ontology to be diagnosed, the output error type is "Inter-function connection error". If the inflow or outflow data flow of the function in the prior ontology is inconsistent with that in the architecture ontology to be diagnosed, the output error type is "Inter-function data flow error". Then, in the above process, examine the above logical relationships of service domain class, service class, sub-service class and atomic function class in the architecture ontology to be diagnosed layer by layer, and output the error type.

[0015] Furthermore, the method for verifying whether the level of the class in the architecture ontology to be diagnosed is consistent with the level in the prior ontology in step 21 is as follows: compare whether the object attributes of the class are the same in the architecture ontology to be diagnosed and the prior ontology. If they are the same, it means that they are consistent.

[0016] Further, step two-two includes the following specific steps: diagnosing whether there is a mismatch between service domains and requirements in the architecture to be diagnosed by comparing whether the service domains associated with two identical requirement-related classes in the architecture to be diagnosed and the prior ontology are the same; diagnosing whether there is a mismatch between services and service domains in the architecture to be diagnosed by comparing whether the service sets associated with two identical service domain classes in the architecture to be diagnosed and the prior ontology are the same; diagnosing whether there is a mismatch between sub-services and services in the architecture to be diagnosed by comparing whether the sub-service sets associated with two identical service classes in the architecture to be diagnosed and the prior ontology are the same; and diagnosing whether there is a mismatch between atomic functions and sub-services in the architecture to be diagnosed by comparing whether the atomic function sets associated with two identical sub-service classes in the architecture to be diagnosed and the prior ontology are the same.

[0017] Furthermore, the specific steps of steps two and three include: diagnosing whether there is a mismatch between the set of physical objects and the service domain in the architecture to be diagnosed by comparing whether the sets of physical objects associated with two identical service domain classes in the architecture to be diagnosed and the prior ontology are the same; diagnosing whether there is a mismatch between the set of physical objects and the service in the architecture to be diagnosed by comparing whether the sets of physical objects associated with two identical service classes in the architecture to be diagnosed and the prior ontology are the same; diagnosing whether there is a mismatch between the set of physical objects and the sub-service in the architecture to be diagnosed by comparing whether the sets of physical objects associated with two identical sub-service classes in the architecture to be diagnosed and the prior ontology are the same; and diagnosing whether there is a mismatch between physical objects and atomic functions in the architecture to be diagnosed by comparing whether the physical object classes associated with two identical atomic function classes in the architecture to be diagnosed and the prior ontology are the same.

[0018] Further, the specific steps of step two and four include: diagnosing whether there are service domain connection errors in the architecture to be diagnosed by checking whether the set of precedent service domains of the service domain class in the architecture to be diagnosed is a subset of the set of precedent service domains associated with the service domain class corresponding to that service domain class in the prior ontology; diagnosing whether there are service connection errors in the architecture to be diagnosed by checking whether the set of precedent service domains of the service class in the architecture to be diagnosed is a subset of the set of precedent service domains associated with the service class corresponding to that service class in the prior ontology; diagnosing whether there are sub-service connection errors in the architecture to be diagnosed by checking whether the set of precedent sub-service domains of the sub-service class in the architecture to be diagnosed is a subset of the set of precedent sub-service domains associated with the sub-service class corresponding to that sub-service class in the prior ontology; diagnosing whether there are atomic function connection errors in the architecture to be diagnosed by checking whether the set of precedent atomic functions of the atomic function class in the architecture to be diagnosed is a subset of the set of precedent atomic functions associated with the atomic function class corresponding to that atomic function class in the prior ontology; and diagnosing whether there are atomic function connection errors in the architecture to be diagnosed by checking whether the set of precedent atomic functions of the atomic function class in the architecture to be diagnosed is a subset of the set of precedent atomic functions associated with the atomic function class corresponding to that atomic function class in the prior ontology; and diagnosing whether there are atomic function connection errors in the architecture to be diagnosed by checking whether the set of precedent atomic functions of the service domain .... The system diagnoses whether there are service domain inflow reference errors in the architecture under diagnosis by verifying whether the inflow data flow set of the service domain class in the architecture under diagnosis is a subset of the inflow data flow set associated with the corresponding service domain class in the prior ontology; it also diagnoses whether there are service inflow reference errors in the architecture under diagnosis by verifying whether the inflow data flow set of the service class in the architecture under diagnosis is a subset of the inflow data flow set associated with the corresponding service class in the prior ontology; it further diagnoses whether there are subservice inflow reference errors in the architecture under diagnosis by verifying whether the inflow data flow set of the subservice class in the architecture under diagnosis is a subset of the inflow data flow set associated with the corresponding subservice class in the prior ontology; and it further diagnoses whether there are atomic function inflow reference errors in the architecture under diagnosis by verifying whether the inflow data flow set of the atomic function class in the architecture under diagnosis is a subset of the inflow data flow set associated with the corresponding atomic function class in the prior ontology.

[0019] The beneficial technical effects of this invention are:

[0020] This invention proposes an ontology-based diagnostic method for autonomous transportation system architecture. It uses ontology modeling to describe the autonomous transportation system architecture from three aspects: logic, function, and physical. This includes the composition of the autonomous transportation system architecture, the relationships between the components, and the integrity rules of the architecture. Based on this ontology and the diagnostic rules built upon it, the method diagnoses the autonomous transportation system architecture designed by the user and discovers the errors in the architecture and the types of errors.

[0021] This invention establishes a conceptual model of an autonomous transportation system architecture based on ontology, and proposes an architecture diagnostic method based on this model. It has the characteristic of being independent of traffic scenarios, and can help designers avoid possible errors and ensure the correctness of the architecture design during the autonomous transportation system architecture design process. Attached Figure Description

[0022] The present invention can be better understood by referring to the description given below in conjunction with the accompanying drawings, which together with the following detailed description are included in and form part of this specification, and are used to further illustrate preferred embodiments of the invention and explain the principles and advantages of the invention.

[0023] Figure 1 A flowchart illustrating an ontology-based autonomous transportation system architecture diagnostic method provided in this application embodiment;

[0024] Figure 2 A logical block diagram of an ontology-based autonomous transportation system architecture diagnostic method provided in another embodiment of this application;

[0025] Figure 3 Example diagram of an autonomous transportation system architecture ontology model built using Protégé, provided for embodiments of this application;

[0026] Figure 4 An example diagram of the ontology model of the autonomous vehicle safety system architecture provided in this application embodiment. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present invention, exemplary embodiments or examples of the present invention will be described below in conjunction with the accompanying drawings. Obviously, the described embodiments or examples are merely some, not all, of the embodiments or examples of the present invention. All other embodiments or examples obtained by those skilled in the art based on the embodiments or examples of the present invention without inventive effort should fall within the scope of protection of the present invention.

[0028] The design of autonomous transportation system architecture involves a significant amount of repetitive and specialized work, requiring designers to possess extensive knowledge and meticulous reasoning and analytical skills. Since user-designed autonomous transportation system architectures may contain conceptual hierarchy errors, incorrect inclusion relationships in functional architectures, incorrect references to physical objects in physical architectures, and errors in inter-functional connections or data flow in logical architectures, these errors can all impact the implementation of the autonomous transportation system derived from the architecture. Therefore, this invention provides an ontology-based diagnostic method for autonomous transportation system architectures. By modeling the concepts and relationships between concepts in the autonomous transportation system architecture, and standardizing and structuring the designer's knowledge to form diagnostic rules, intelligent diagnosis of the user-designed architecture is achieved. Furthermore, by formally expressing the autonomous transportation system architecture through ontology and combining it with diagnostic rules, intelligent diagnosis of the autonomous transportation system architecture is realized.

[0029] The method of this invention first represents concepts in the architecture as classes, adds class hierarchical relationships to form a class hierarchy, and creates class attributes to express these relationships, thereby establishing a prior ontology of the autonomous transportation system architecture and an ontology of the architecture to be diagnosed. The classes include requirement-related classes, function-related classes, and physical object-related classes. Then, based on the prior ontology of the autonomous transportation system architecture, the method verifies the correctness of the classes and their hierarchical structure in the ontology of the architecture to be diagnosed, and checks the correctness and completeness of the requirement-related classes, function-related classes, and physical object-related classes. It also outputs the errors present in the ontology of the architecture to be diagnosed and their types, thus completing the diagnosis of the correctness and completeness of the architecture design to be diagnosed. The implementation process of this invention is described in detail below.

[0030] This invention provides an ontology-based autonomous transportation system architecture diagnostic method, such as... Figure 1 As shown, the method includes the following steps:

[0031] Step 1: Based on the concepts in the autonomous transportation system architecture and the relationships between them, establish the prior ontology of the autonomous transportation system architecture.

[0032] According to embodiments of the present invention, the components of an autonomous transportation system architecture include requirements, functions, and physical objects. The autonomous transportation system architecture comprises a functional architecture, a physical architecture, and a logical architecture. The functional architecture describes the functions of the autonomous transportation system and the relationships between these functions; it is divided into four layers according to abstraction level, from high to low: service domain layer, service layer, sub-service layer, and atomic function layer. The functions in the atomic function layer are indivisible; that is, they correspond to the service domain class, service class, sub-service class, and atomic function class included in the function-related classes in the ontology, respectively. The physical architecture describes the physical objects of the autonomous transportation system architecture, the functions implemented by these physical objects, and the information flow between them. The functions implemented by the physical objects in the physical architecture correspond one-to-one with the functions described in the functional architecture, that is, they correspond to the physical object-related classes in the ontology. The logical architecture constructs a view from function triggering to traffic business implementation from the perspective of data flow; the logical architecture describes the data flow and logical relationships between functions. Using ontology modeling tools, the conceptual system of the autonomous transportation system architecture is modeled to obtain a priori ontology.

[0033] Step 2: Establish the ontology of the user input architecture.

[0034] According to embodiments of the present invention, in order to perform functional and structural diagnosis on the user-input architecture (i.e., the architecture to be diagnosed), the user-input architecture is first parsed based on its data format to extract the functional architecture, physical architecture, and logical architecture. Then, using ontology modeling tools, the conceptual system of the user-input architecture is modeled to obtain the user-input architecture ontology (i.e., the architecture to be diagnosed ontology).

[0035] Step 3: Verify the correctness of the concepts and their hierarchical structure referenced in the user input architecture ontology.

[0036] According to an embodiment of the present invention, each concept in the user-input architectural ontology is sequentially traversed, and it is checked whether there is a corresponding concept in the prior ontology. If there is no corresponding concept in the prior ontology, a concept reference error is output. Otherwise, it is further diagnosed whether the level of the concept in the user-input architectural ontology is consistent with its level in the prior ontology. If they are consistent, proceed to step four; otherwise, a concept level error is output.

[0037] Step 4: Diagnose the integrity of the functional architecture in the user input architecture.

[0038] According to an embodiment of the present invention, firstly, using the requirements in the user-input architecture ontology as the query condition, the service domain corresponding to the requirements is queried in the prior ontology. The service domain corresponding to the requirements in the user-input architecture ontology is compared with the service domain obtained from the prior ontology. If they do not match, the output service domain does not match the requirements; if they match, the inclusion relationships of service domains, services, sub-services, and atomic functions are checked layer by layer to ensure they are correct. If correct, proceed to step five; if incorrect, the inclusion relationship of the output functions is incorrect.

[0039] Step 5: Diagnose the integrity of the physical architecture in the user input architecture.

[0040] According to an embodiment of the present invention, the correspondence between service domains and physical objects is first checked. Using the service domain in the user-input architecture ontology as the query condition, the physical object corresponding to the service domain is queried in the prior ontology. The physical object corresponding to the service domain in the user-input architecture ontology is compared with the physical object retrieved from the prior ontology. If the result is consistent, the correspondence between services and physical objects is further checked; otherwise, an error in the physical object reference of the current layer is output. This process is repeated layer by layer to diagnose the correspondence between services, sub-services, functions, and physical objects.

[0041] Step Six: Diagnose the integrity of the logical architecture in the user input architecture.

[0042] According to an embodiment of the present invention, for each function in the user input architecture, its preceding or succeeding functions, as well as the inflow or outflow of data streams, are queried in both the user input architecture ontology and the prior ontology, and the query results are compared. If the results are consistent, step seven is executed; otherwise, if the preceding or succeeding functions of the function in the prior ontology are inconsistent with the preceding or succeeding functions of the function in the input ontology, then the connection between output functions is incorrect; if the inflow or outflow of data streams of the function in the prior ontology is inconsistent with the inflow or outflow of data streams in the input ontology, then the data stream between output functions is incorrect. The logical relationships of the service domain layer, service layer, sub-service layer, and atomic function layer are checked sequentially.

[0043] Step 7: Diagnostic process complete.

[0044] Another embodiment of the present invention provides an ontology-based diagnostic method for autonomous transportation system architecture. This embodiment utilizes the Protégé ontology modeling function developed by Stanford University to establish an ontology model of the autonomous transportation system architecture. Custom SWRL rules are written using the SWRLTab plugin in the Protégé software, and after running the rules, diagnostic results are obtained. Figure 2 As shown, the specific implementation of this embodiment includes the following steps:

[0045] Step 1: Based on the concepts and relationships between concepts in the autonomous transportation system architecture, establish the prior ontology of the autonomous transportation system architecture, including the classes corresponding to the concepts of the autonomous transportation system architecture, the data attributes of the classes, the hierarchical structure of the classes, and the object attributes of the classes.

[0046] In this embodiment, as Figure 3 As shown, the ontology modeling capabilities provided by Protégé are used to represent the concept of an autonomous transportation system architecture as classes. These classes include demand-related classes, function-related classes, and physical object-related classes. The demand-related classes can be further subdivided into 764 subclasses. The function-related classes include 9 service domain classes, 54 service classes, 163 sub-service classes, and 436 atomic function classes. The physical object-related classes include 5 first-level physical object classes, 17 second-level physical object classes, 72 third-level physical object classes, and 347 fourth-level physical object classes. The first-level physical object classes are user entities, vehicles, infrastructure, transported goods, and the traffic environment. The hierarchical structure of these classes is formed through their hierarchical relationships.

[0047] In the prior ontology, relationships are expressed through attributes. Attributes include object attributes and data type attributes, with different classes having specific data type attribute definitions. Object attributes use the `Has` or `Is` keywords to express the association between two classes, such as `HasProvider` and `IsProviderOf`. The components of the autonomous transportation system architecture interact and drive the development of the transportation system architecture through direct or indirect relationships. To meet the needs of specific transportation scenarios, it is necessary to combine transportation business-oriented services; specific functions support the implementation of services, and physical objects, as participating units in the actual scenario, provide the implementation modules for functions.

[0048] Step 2: Establish the ontology of the user input architecture.

[0049] In this embodiment, the architecture of a V2X-based vehicle collision warning system at an unsignalized intersection is analyzed, and a user input architecture ontology is established. This ontology includes 10 requirement classes, 1 service domain class, 3 service classes, 4 sub-service classes, 20 atomic function classes, and 5 physical object classes. Among these, the classes related to the functional architecture are divided into four levels according to their abstraction hierarchy, from high to low, such as... Figure 4 As shown.

[0050] The classes related to the physical architecture include five physical object classes: driver, vehicle, roadside communication equipment, roadside sensing equipment, and roadside computing equipment. These classes are associated with function-related classes in the user input architecture ontology through object attributes. Physical objects either serve as providers of functions or as objects served by functions. For example, the semantics of the object attribute `HasProvider(Roadside Unit Sensing Information, Roadside Sensing Equipment)` is that the roadside sensing equipment completes the roadside unit sensing information function; the semantics of the object attribute `ServiceFor(Roadside Unit Sensing Information, Roadside Computing Equipment)` is that the information output by the roadside unit sensing information function serves as the input to the roadside computing equipment.

[0051] In the logical architecture, the data flow and logical relationships between functions are also modeled through object properties. For example, the semantics of the object property HasPriority (generates collision warning information, processes surrounding vehicle data) is that the function of generating collision warning information is a prerequisite for the function of processing surrounding vehicle data; the semantics of the object property HasPostfix (generates collision warning information, publishes collision warning information) is that the function of generating collision warning information should be executed before publishing collision warning information.

[0052] Step 3: Verify the correctness of the concepts and hierarchical structure referenced in the user input architecture.

[0053] In this embodiment, each class of the user-input architecture ontology is traversed sequentially, and it is checked whether a class with the same name exists in the prior ontology. If no class with the same name exists in the prior ontology, a concept reference error is output. Otherwise, it further diagnoses whether the hierarchy of the class in the user-input architecture ontology is consistent with the hierarchy of the class in the prior ontology. If they are consistent, proceed to step four; otherwise, a concept hierarchy error is output. Let O1 be the prior ontology, O2 be the user-input architecture ontology, T1 and T2 be the sets of classes of the prior ontology O1 and the user-input architecture ontology O2, respectively, and A1 and A2 be the classes of the prior ontology and the user-input architecture ontology, respectively. The diagnostic rules are as follows:

[0054] Rule1:AllClassIs(O1,?T1)^AllClassIs(O2,?T2)^ →FaultModeIs(T1∪T2-T1, Conceptual Reference Error)

[0055] This rule diagnoses whether there are concept reference errors in the user input schema by determining whether the classes in the user input schema ontology are classes in the prior ontology.

[0056] Rule 2: The class of the prior ontology O1 (?A1)^The class of the user input architecture ontology O2 (?A2)^^hasURI(?A1,?URI1)^hasURI(?A2,?URI2)^swrlb:equal(?URI1,URI2)^hasObjectProperties(?A1,?OP1)^hasObjectProperties(?A2,?OP2)^DifferentFrom(?OP1,?OP2)→FaultModeIs(?A2, Conceptual Hierarchy Error)

[0057] This rule diagnoses whether there are conceptual hierarchy errors in the user input schema by comparing whether the object properties of two identical classes in the user input schema ontology and the prior schema are the same.

[0058] Step 4: Diagnose the integrity of the functional architecture in the user input architecture.

[0059] In this embodiment, the user-input requirements in the architecture ontology are first used as the query condition to query the service domains corresponding to the requirements in the prior ontology. The service domains corresponding to the requirements in the user-input architecture ontology are compared with the service domains retrieved from the prior ontology. If they do not match, the output service domain does not match the requirements; if they match, the inclusion relationships of service domains, services, sub-services, and atomic functions are checked layer by layer. If correct, proceed to step five; if incorrect, the inclusion relationship of the output functions is incorrect.

[0060] The diagnostic rules are as follows, where D represents the requirement and S represents the requirement. dom Let S be the service domain, and S be the set of services s. sub Serving children sub The set of functions f, where F is the set of functions f:

[0061] Rule 3: The requirement class of prior ontology O1 (?D1) ^ The requirement class of user input architecture ontology O2 (?D2) ^ ^ hasURI (?D1, ?URI1) ^ hasURI (?D2, ?URI2) ^ swrlb:equal (?URI1, ?URI2) ^ The set of service domains associated with the requirements of prior ontology O1 ^User input architecture ontology O2 requirements associated with service domains ^ →FaultModeIs( (Mismatch with demand)

[0062] This rule diagnoses whether there is a mismatch between service domains and requirements in the user input architecture by comparing whether the service domains associated with two identical requirement classes in the user input architecture ontology and the prior ontology are the same.

[0063] Rule 4: Service domain class of prior ontology O1 ^User input architecture ontology O2 service domain class ^^hasURI ^hasURI ^swrlb:equal(?URI1,?URI2)^service domain associated service set of prior ontology O1 ^User input architecture ontology O2 service domain associated service set ^(S1≠S2)→FaultModeIs(S2, does not match the service domain)

[0064] This rule diagnoses whether there is a service-service domain mismatch in the user input schema by comparing whether the service sets associated with two identical service domain classes in the user input schema ontology and the prior schema are the same.

[0065] Rule 5: Service class of prior ontology O1 (?s1) ^ Service class of user input architecture ontology O2 (?s2) ^ ^ hasURI (?s1, ?URI1) ^ hasURI (?s2, ?URI2) ^ swrlb:equal (?URI1, ?URI2) ^ Set of service-related sub-services of prior ontology O1 ^User input architecture ontology O2 service association sub-service set ^ →FaultModeIs( (Incompatible with service)

[0066] This rule diagnoses whether there is a mismatch between subservices and services in the user input architecture by comparing whether the sets of subservices associated with two identical service classes in the user input architecture ontology and the prior ontology are the same.

[0067] Rule 6: Sub-service classes of prior ontology O1 ^Sub-service class of the user input architecture ontology O2 ^^hasURI ^hasURI ^swrlb:equal(?URI1,?URI2)^The set of atomic functions associated with the sub-services of the prior ontology O1 ^The set of atomic functions associated with sub-services of the user input architecture ontology O2 ^(F1≠F2)→FaultModeIs(F2, does not match the sub-service)

[0068] This rule diagnoses whether there is a mismatch between atomic functions and subservices in the user input architecture by comparing whether the sets of atomic functions associated with two identical subservice classes in the user input architecture ontology and the prior ontology are the same.

[0069] Step 5: Diagnose the integrity of the physical architecture in the user input architecture.

[0070] In this embodiment, the correspondence between service domains and physical objects is first checked. Using the service domain in the user-input architecture ontology as the query condition, the physical object corresponding to the service domain is queried in the prior ontology. The physical object corresponding to the service domain in the user-input architecture ontology is compared with the physical object retrieved from the prior ontology. If they match, the correspondence between services and physical objects is further checked; otherwise, an error in referencing the physical object at the current layer is output. This process is repeated layer by layer to diagnose the correspondence between services, sub-services, atomic functions, and physical objects. The diagnostic rules are as follows, where S... dom For the service domain, s is the service, s sub For the purpose of serving the sub-functions, F is the set of atomic functions f, and P is the set of physical objects p:

[0071] Rule 7: Service domain class of prior ontology O1 ^User input architecture ontology O2 service domain class ^^hasURI ^hasURI ^swrlb:equal(?URI1, ?URI2)^The set of physical objects associated with the service domain of the prior ontology O1 ^The set of physical objects associated with the service domain of the user input architecture ontology O2 ^(P1≠P2)→FaultModeIs(P2, service domain mismatch)

[0072] This rule diagnoses whether there is a mismatch between the physical object set and the service domain in the user input schema by comparing whether the physical object sets associated with two identical service domain classes in the user input schema ontology and the prior schema are the same.

[0073] Rule 8: The service class of prior ontology O1 (?s1) ^ The service class of user-input architecture ontology O2 (?s2) ^ hasURI (?s1, ?URI1) ^ hasURI (?s2, ?URI2) ^ swrlb:equal(?URI1, ?URI2) ^ The set of physical objects associated with the service of prior ontology O1 (?s1, ?P1) ^ The set of physical objects associated with the service of user-input architecture ontology O2 (?s2, ?P2) ^ (P1≠P2) → FaultModeIs(P2, service mismatch)

[0074] This rule diagnoses whether there is a mismatch between the physical object set and the service in the user input architecture by comparing whether the physical object sets associated with two identical service classes in the user input architecture ontology and the prior ontology are the same.

[0075] Rule 9: Sub-service classes of prior ontology O1 ^Sub-service class of the user input architecture ontology O2 ^^hasURI ^hasURI ^swrlb:equal(?URI1, ?URI2)^The collection of physical objects associated with the sub-services of the prior ontology O1 ^The collection of physical objects associated with sub-services of the user input architecture ontology O2 ^(P1≠P2)→FaultModeIs(P2, mismatch with sub-service)

[0076] This rule diagnoses whether there is a mismatch between the physical object set and the subservice in the user input architecture by comparing whether the physical object sets associated with two identical subservice classes in the user input architecture ontology and the prior ontology are the same.

[0077] Rule 10: Atomic function class of prior ontology O1 (?f1) ^ Sub-service class of user input architecture ontology O2 (?f2) ^ ^ hasURI (?f1, ?URI1) ^ hasURI (?f2, ?URI2) ^ swrlb:equal (?URI1, ?URI2) ^ Physical object associated with atomic function of prior ontology O1 (?f1, ?p1) ^ Physical object associated with atomic function of user input architecture ontology O2 (?f2, ?p2) ^ hasURI (?p1, ?URI2) p1 )^hasURI(?p2,?URI p2 )^swrlb:notEqual(?URI p1 ,? URI p2 →FaultModeIs(p2, Error matching atomic function)

[0078] This rule diagnoses whether there is a mismatch between physical objects and atomic functions in the user input architecture by comparing whether the physical object classes associated with two identical atomic function classes in the user input architecture ontology and the prior ontology are the same.

[0079] Step Six: Diagnose the integrity of the logical architecture in the user input architecture.

[0080] In this embodiment, for each function in the user input architecture, its preceding or succeeding functions, as well as the inflow or outflow of data, are queried in both the user input architecture ontology and the prior ontology. The query results are then compared. If the results match, step seven is executed; otherwise, if the preceding or succeeding functions of the function in the prior ontology are inconsistent with those in the input ontology, an error in the connection between output functions is found; if the inflow or outflow of data for the function in the prior ontology is inconsistent with those in the input ontology, an error in the data flow between output functions is found. The logical relationships of the service domain layer, service layer, sub-service layer, and atomic function layer are checked sequentially.

[0081] This embodiment diagnoses whether there are function connection errors in the user input architecture by checking whether the set of precedent functions of a function in the user input architecture ontology is a subset of the set of precedent functions associated with the function corresponding to that function in the prior ontology.

[0082] The diagnostic rules are as follows:

[0083] Rule 11: Service domain class of prior ontology O1 ^User input architecture ontology O2 service domain class ^^hasURI ^hasURI ^swrlb:equal(?URI1,?URI2)^The set of prior service domains associated with the service domain of prior ontology O1 ^The set of preceding service domains associated with the service domain of the user input architecture ontology O2 ^ →FaultModeIs( (Service domain connection error)

[0084] This rule diagnoses whether there are service domain connection errors in the user input schema by checking whether the set of precedent service domains of the service domain class in the user input schema ontology is a subset of the set of precedent service domains associated with the service domain class corresponding to that service domain class in the prior ontology.

[0085] Rule 12: Service class of prior ontology O1 (?s1) ^ Service class of user input architecture ontology O2 (?s2) ^ ^ hasURI (?s1, ?URI1) ^ hasURI (?s2, ?URI2) ^ swrlb:equal (?URI1, ?URI2) ^ Precedence service set associated with the service of prior ontology O1 (?s1, ?S a The set of pre-services associated with the user input architecture ontology O2 (?s2, ?S) b )^ →FaultModeIs(s2, Service connection error)

[0086] This rule diagnoses whether there are service connection errors in the user input architecture by checking whether the set of precedent services for a service class in the user input architecture ontology is a subset of the set of precedent services associated with the service class corresponding to that service class in the prior ontology.

[0087] Rule 13: Sub-service classes of prior ontology O1 ^Sub-service class of the user input architecture ontology O2 ^^hasURI ^hasURI ^swrlb:equal(?URI1,?URI2)^The set of preorder subservices associated with the subservices of the prior ontology O1 ^The set of pre-order sub-services associated with the sub-services of the user input architecture ontology O2 ^ →FaultModeIs( Sub-service connection error)

[0088] This rule diagnoses whether there are subservice connection errors in the user input architecture by checking whether the set of precedent subservices of a subservice class in the user input architecture ontology is a subset of the set of precedent subservices associated with the subservice class corresponding to that subservice class in the prior ontology.

[0089] Rule 14: Atomic function class of prior ontology O1 (?f1) ^ Atomic function class of user input architecture ontology O2 (?f2) ^ ^ hasURI (?f1, ?URI1) ^ hasURI (?f2, ?URI2) ^ swrlb:equal (?URI1, ?URI2) ^ Preorder atomic function set associated with the atomic function of prior ontology O1 (?f1, ?F a The set of preorder atomic functions associated with the atomic functions of the user input architecture ontology O2 (?f2, ?F) b )^ →FaultModeIs(f2, Atomic function connection error)

[0090] This rule diagnoses whether there are atomic function connection errors in the user input architecture by checking whether the set of preorder atomic functions of an atomic function class in the user input architecture ontology is a subset of the set of preorder atomic functions associated with the atomic function class corresponding to that atomic function class in the prior ontology.

[0091] This embodiment verifies the correctness of data flow between functions by executing the following rules. Here, DF represents the data flow into the function:

[0092] Rule 15: Service domain class of prior ontology O1 ^User input architecture ontology O2 service domain class ^^hasURI ^hasURI ^swrlb:equal(?URI1,?URI2)^The inflow data stream set associated with the service domain of prior ontology O1 ^The set of inflow data streams associated with the service domain of the user input architecture ontology O2 ^ →FaultModeIs( (Inflow data stream reference error)

[0093] This rule diagnoses whether there are incorrect references to the inflow data streams of service domains in the user input architecture by examining whether the set of inflow data streams for service domain classes in the user input architecture ontology is a subset of the set of inflow data streams associated with the service domain class corresponding to that service domain class in the prior ontology.

[0094] Rule 16: Service class of prior ontology O1 (?s1) ^ Service class of user input architecture ontology O2 (?s2) ^ ^ hasURI (?s1, ?URI1) ^ hasURI (?s2, ?URI2) ^ swrlb:equal (?URI1, ?URI2) ^ Set of incoming data streams associated with the service of prior ontology O1 (?s1, ?DF) a The set of incoming data streams associated with the service of the user input architecture ontology O2 (?s2,?DF) b )^ →FaultModeIs(s2,Inflow data stream reference error)

[0095] This rule diagnoses whether there are service inflow reference errors in the user input architecture by examining whether the set of inflow data flows for a service class in the user input architecture ontology is a subset of the set of inflow data flows associated with the service class corresponding to that service class in the prior ontology.

[0096] Rule 17: Sub-service classes of prior ontology O1 ^Sub-service class of the user input architecture ontology O2 ^^hasURI ^hasURI ^swrlb:equal(?URI1,?URI2)^The set of inflow data streams associated with the sub-services of the prior ontology O1 ^The collection of inflow data streams associated with sub-services of the user input architecture ontology O2 ^ →FaultModeIs (Inflow data stream reference error)

[0097] This rule diagnoses whether there are incorrect references to the inflow data streams of sub-services in the user input architecture by checking whether the set of inflow data streams of sub-service classes in the user input architecture ontology is a subset of the set of inflow data streams associated with the corresponding sub-service class in the prior ontology.

[0098] Rule 18: Atomic function class of prior ontology O1 (?f1) ^ Sub-service class of user input architecture ontology O2 (?f2) ^ ^ hasURI (?f1, ?URI1) ^ hasURI (?f2, ?URI2) ^ swrlb:equal (?URI1, ?URI2) ^ Set of incoming data streams associated with the atomic function of prior ontology O1 (?f1, ?DF) a The set of incoming data streams associated with the atomic functions of the user input architecture ontology O2 (?f2, ?DF) b )^ →FaultModeIs(f2,Inflow data stream reference error)

[0099] This rule diagnoses whether there are incorrect references to the inflow data streams of atomic functions in the user input architecture by examining whether the set of inflow data streams of atomic function classes in the user input architecture ontology is a subset of the set of inflow data streams associated with the atomic function class corresponding to that atomic function class in the prior ontology.

[0100] It should be noted that the above Rules 1-Rule 18 are custom SWRL rules written in a language that describes logic using the SWRLTab plugin in the Protégé software, where "?" represents alternative values.

[0101] Step 7: Diagnostic process complete.

[0102] Although the invention has been described with respect to a limited number of embodiments, those skilled in the art will understand from the foregoing description that other embodiments are conceivable within the scope of the invention described herein. The disclosure of the invention is illustrative and not restrictive, and the scope of the invention is defined by the appended claims.

Claims

1. A diagnostic method for autonomous transportation system architecture based on ontology, characterized in that, Includes the following steps: Step 1: Represent the concepts in the architecture as classes, add class hierarchies to form a class hierarchy, and create class attributes to express the relationships, thereby establishing the prior ontology and the architecture to be diagnosed for the autonomous transportation system architecture; the classes include requirement-related classes, function-related classes, and physical object-related classes; The autonomous transportation system architecture includes functional architecture, physical architecture, and logical architecture; The functional architecture describes the functions of the autonomous transportation system and the inclusion relationships between functions; it is divided into four layers from high to low according to the level of abstraction: service domain layer, service layer, sub-service layer, and atomic function layer. The physical architecture describes the physical objects of the autonomous transportation system architecture, the functions implemented by the physical objects, and the information flow between the physical objects. The functions implemented by the physical objects in the physical architecture correspond one-to-one with the functions described in the functional architecture, that is, they correspond to the relevant classes of the physical objects in the ontology. From the perspective of data flow, the logical architecture constructs a view from function triggering to traffic business implementation. The logical architecture describes the data flow and logical relationships between functions. Using ontology modeling tools, the conceptual framework of the autonomous transportation system architecture is modeled to obtain the prior ontology; Step 2: Based on the prior ontology of the autonomous transportation system architecture, verify whether the classes and their hierarchical structure in the ontology of the architecture to be diagnosed are correct, whether the requirement-related classes, function-related classes, and physical object-related classes are correct and complete, and output the errors and error types in the ontology of the architecture to be diagnosed, thereby completing the diagnosis of the correctness and completeness of the architecture design to be diagnosed. The error types include concept reference errors, concept hierarchy errors, service domain and requirement mismatch, function inclusion relationship errors, current layer physical object reference errors, inter-function connection errors, and inter-function data flow errors.

2. The ontology-based autonomous transportation system architecture diagnostic method according to claim 1, characterized in that, The attributes of the class mentioned in step one include data attributes and object attributes, wherein the object attributes are used to express the association relationship between two classes.

3. The ontology-based autonomous transportation system architecture diagnostic method according to claim 2, characterized in that, The requirement-related classes mentioned in step one include multiple subclasses; the function-related classes include service domain classes, service classes, sub-service classes, and atomic function classes; the physical object-related classes include first-level physical object classes, second-level physical object classes, third-level physical object classes, and fourth-level physical object classes.

4. The ontology-based autonomous transportation system architecture diagnostic method according to claim 3, characterized in that, Step two includes the following steps: Step 2: For each class in the architecture ontology to be diagnosed, check whether there is a class with the same name in the prior ontology. If not, the error type is concept reference error. If it exists, check whether the level of the class in the architecture ontology to be diagnosed is consistent with the level in the prior ontology. If they are inconsistent, the error type is concept level error. Step 22: Using the requirements corresponding to the requirement-related classes in the architecture ontology to be diagnosed as the query conditions, query the service domain class corresponding to the requirement in the prior ontology; compare whether the service domain class corresponding to the requirement in the architecture ontology to be diagnosed is consistent with that in the prior ontology. If they are inconsistent, output the error type as "service domain and requirement do not match"; if they are consistent, check the hierarchical relationship of service domain class, service class, sub-service class, and atomic function class in the architecture ontology to be diagnosed layer by layer to see if it is correct. If it is incorrect, output the error type as "functional inclusion relationship error". Steps 2 and 3: Using the service domain corresponding to the service domain class in the architecture ontology to be diagnosed as the query condition, query the physical object class corresponding to the service domain in the prior ontology; compare whether the physical object class corresponding to the service domain in the architecture ontology to be diagnosed is consistent with that in the prior ontology. If consistent, continue to check the correspondence between service class and physical object class; if inconsistent, output the error type as "current layer physical object reference error"; and check the correspondence between service class, sub-service class, atomic function class and physical object class in the architecture ontology to be diagnosed layer by layer according to the above process, and output the error type. Step 24: For each function corresponding to the function-related class in the architecture ontology to be diagnosed, query its predecessor or successor function, as well as the inflow or outflow data flow, in both the architecture ontology to be diagnosed and the prior ontology, and compare the query results. If the predecessor or successor function of the function in the prior ontology is inconsistent with that in the architecture ontology to be diagnosed, the output error type is "Inter-function connection error". If the inflow or outflow data flow of the function in the prior ontology is inconsistent with that in the architecture ontology to be diagnosed, the output error type is "Inter-function data flow error". Then, in the above process, examine the above logical relationships of service domain class, service class, sub-service class and atomic function class in the architecture ontology to be diagnosed layer by layer, and output the error type.

5. The ontology-based autonomous transportation system architecture diagnostic method according to claim 4, characterized in that, The method for verifying whether the hierarchy of the class in the architecture ontology to be diagnosed is consistent with the hierarchy in the prior ontology in step two is as follows: compare whether the object attributes of the class are the same in the architecture ontology to be diagnosed and the prior ontology. If they are the same, it means that they are consistent.

6. The ontology-based autonomous transportation system architecture diagnostic method according to claim 5, characterized in that, Step 22 includes the following steps: diagnosing whether there is a mismatch between service domains and requirements in the architecture to be diagnosed by comparing whether the service domains associated with two identical requirement-related classes in the architecture to be diagnosed and the prior ontology are the same; diagnosing whether there is a mismatch between services and service domains in the architecture to be diagnosed by comparing whether the service sets associated with two identical service domain classes in the architecture to be diagnosed and the prior ontology are the same; diagnosing whether there is a mismatch between sub-services and services in the architecture to be diagnosed by comparing whether the set of sub-services associated with two identical service classes in the architecture to be diagnosed and the prior ontology are the same; and diagnosing whether there is a mismatch between atomic functions and sub-services in the architecture to be diagnosed by comparing whether the set of atomic functions associated with two identical sub-service classes in the architecture to be diagnosed and the prior ontology are the same.

7. The ontology-based autonomous transportation system architecture diagnostic method according to claim 6, characterized in that, The specific steps in steps two and three include: diagnosing whether there is a mismatch between the set of physical objects and the service domain in the architecture to be diagnosed by comparing whether the sets of physical objects associated with two identical service domain classes in the architecture to be diagnosed and the prior ontology are the same; diagnosing whether there is a mismatch between the set of physical objects and the service in the architecture to be diagnosed by comparing whether the sets of physical objects associated with two identical service classes in the architecture to be diagnosed and the prior ontology are the same; diagnosing whether there is a mismatch between the set of physical objects and the sub-service in the architecture to be diagnosed by comparing whether the sets of physical objects associated with two identical sub-service classes in the architecture to be diagnosed and the prior ontology are the same; and diagnosing whether there is a mismatch between physical objects and atomic functions in the architecture to be diagnosed by comparing whether the physical object classes associated with two identical atomic function classes in the architecture to be diagnosed and the prior ontology are the same.

8. The ontology-based autonomous transportation system architecture diagnostic method according to claim 7, characterized in that, Step 2.4 specifically includes the following steps: Diagnosing whether there are service domain connection errors in the architecture to be diagnosed by checking whether the set of precedent service domains of the service domain class in the architecture to be diagnosed is a subset of the set of precedent service domains associated with the service domain class corresponding to that service domain class in the prior ontology; diagnosing whether there are service connection errors in the architecture to be diagnosed by checking whether the set of precedent service domains of the service class in the architecture to be diagnosed is a subset of the set of precedent service domains associated with the service class corresponding to that service class in the prior ontology; diagnosing whether there are sub-service connection errors in the architecture to be diagnosed by checking whether the set of precedent sub-service domains of the sub-service class in the architecture to be diagnosed is a subset of the set of precedent sub-service domains associated with the sub-service class corresponding to that sub-service class in the prior ontology; diagnosing whether there are atomic function connection errors in the architecture to be diagnosed by checking whether the set of precedent atomic functions of the atomic function class in the architecture to be diagnosed is a subset of the set of precedent atomic functions associated with the atomic function class corresponding to that atomic function class in the prior ontology; and diagnosing whether there are atomic function connection errors in the architecture to be diagnosed by checking whether the set of precedent atomic functions of the service domain class in the architecture to be diagnosed is a subset of the set of precedent atomic functions associated with the atomic function class corresponding to that atomic function class in the prior ontology; and diagnosing whether there are service domain connection errors in the architecture to be diagnosed by checking whether the set of precedent service domains ... The system diagnoses whether there are service domain inflow reference errors in the architecture to be diagnosed by checking whether the inflow data flow set of service domain classes in the architecture to be diagnosed is a subset of the inflow data flow set associated with the corresponding service domain class in the prior ontology; it also diagnoses whether there are service inflow reference errors in the architecture to be diagnosed by checking whether the inflow data flow set of service classes in the architecture to be diagnosed is a subset of the inflow data flow set associated with the corresponding service class in the prior ontology; it further diagnoses whether there are subservice inflow reference errors in the architecture to be diagnosed by checking whether the inflow data flow set of subservice classes in the architecture to be diagnosed is a subset of the inflow data flow set associated with the corresponding subservice class in the prior ontology; and it further diagnoses whether there are atomic function inflow reference errors in the architecture to be diagnosed by checking whether the inflow data flow set of atomic function classes in the architecture to be diagnosed is a subset of the inflow data flow set associated with the corresponding atomic function class in the prior ontology.

Images