Service diagnostic architecture, vehicle, method and storage medium

Abstract

The application relates to the technical field of service diagnosis, in particular to a service diagnosis architecture, a vehicle, a method and a storage medium, wherein the architecture comprises: one or more data distribution service (DDS) applications; a management module configured to provide a data query interface for a diagnosis application, and to communicate with a server through a network communication protocol; when receiving a data request of the diagnosis application or the server, the management module is configured to acquire service inventory data of the DDS application through a publish-subscribe event or an application program interface of the DDS application, and to send the service inventory data to the server or the diagnosis application; the server is configured to send the service inventory data to the diagnosis application, so that the diagnosis application performs service diagnosis on the DDS application based on the service inventory data. Therefore, the problems that, in the related art, the service diagnosis effect is poor, the convenience is poor, and the user experience is poor when the services between the DDS applications cannot normally communicate are solved.

Description

Technical Field

[0001] This application relates to the field of service diagnostics technology, and in particular to a service diagnostics architecture, vehicle, method, and storage medium. Background Technology

[0002] Currently, in the development and use of DDS (Direct Digital Synthesizer) applications, two DDS applications can only communicate with each other through the same topic after publishing and subscribing to services or registering for subscription and notification events. However, in larger projects, multiple DDS applications are involved, and the complexity of the topics also increases. Furthermore, during the integration testing phase, when different application modules are connecting, the registered services may not be able to communicate properly.

[0003] There is currently no quick and convenient method to diagnose the inability of services between DDS applications to communicate properly, which urgently needs to be addressed. Summary of the Invention

[0004] This application provides a service diagnostic architecture, vehicle, method, and storage medium to address the problems in related technologies, such as poor service diagnostic performance, low convenience, and poor user experience when services between DDS applications cannot communicate normally.

[0005] A first aspect of this application provides a service diagnostic architecture, including: one or more Data Distribution Service (DDS) applications; a management module, configured to provide a data query interface for the diagnostic applications and communicate with a server via a network communication protocol; upon receiving a data request from the diagnostic application or the server, obtaining service list data of the DDS application through publish and subscribe events or the application programming interface of the DDS application, sending the service list data to the server or the diagnostic application, and the server sending the service list data to the diagnostic application, enabling the diagnostic application to perform service diagnostics on the DDS application based on the service list data.

[0006] Based on the above technical means, the embodiments of this application can communicate with the server through the management module and obtain the service list data of the DDS application by using two methods: publishing and subscribing to events or the application programming interface of the DDS application. Then, the service list data of the DDS application can be sent to the diagnostic application, or the service list data can be sent to the server first and then sent to the diagnostic application through the server. This can effectively realize convenient and fast service diagnosis of the DDS application, improve the convenience of service diagnosis, and enhance the user experience.

[0007] Optionally, in one embodiment of this application, the management module defines a request service list service and a response service list request service. The request service list service includes a first service subscription event and a first service publication event. The DDS application registers the first service subscription event to support the diagnostic application in requesting service list data; the diagnostic application registers the first service publication event to request service list data from the DDS application. The response service list request service includes a second service subscription event and a second service publication event. The DDS application registers the second service publication event to send service list data to the diagnostic application; the diagnostic application registers the second service subscription event to receive service list data sent from the DDS application.

[0008] Based on the above technical means, the embodiments of this application can provide a data query interface for diagnostic applications through the request service list service and response service list request service defined by the management module, thereby enabling diagnostic applications to conveniently and quickly obtain service list data and improve the user experience.

[0009] Optionally, in one embodiment of this application, for any online DDS application and the target DDS application, the online DDS application and the target DDS application multicast to the same multicast address and send a heartbeat protocol. After the target DDS application sends a heartbeat response protocol to the online DDS application, the handshake is successful, and they send each other a unified topic name of the data protocol to send the published or subscribed service information to the peer application to provide support for the management of the service list data.

[0010] Based on the above technical means, the embodiments of this application can achieve a successful handshake between an online DDS application and a target DDS application by multicasting and sending a heartbeat protocol, thereby providing the preconditions for communication between the two applications and sending service information to each other, thus providing effective support for service list data management and facilitating subsequent service diagnosis.

[0011] Optionally, in one embodiment of this application, the management module is further configured to: determine new services and / or offline services in the DDS application based on a callback function that matches a publish and subscribe event, and update the service list data based on the new services and / or offline services.

[0012] Based on the above technical means, the embodiments of this application can update the service list data through a callback function, thereby achieving effective management of the service list data.

[0013] Optionally, in one embodiment of this application, the management module is further configured to: identify whether the update identifier of the service list data meets the update conditions at intervals of a first preset time; when the update identifier meets the update conditions, store the current service list data and reset the update identifier.

[0014] Based on the above technical means, the embodiments of this application can periodically determine the update flag of the service list data, and when the conditions are met, store the service list data and reset the update flag, thereby achieving minimal data backup.

[0015] Optionally, in one embodiment of this application, the management module is further configured to: send the service list data to the server at second preset intervals.

[0016] Based on the above technical means, the embodiments of this application can periodically send service list data to the server so that the server can obtain the service list data.

[0017] Optionally, in one embodiment of this application, the DDS application is any application under a service-oriented architecture (SOA).

[0018] A second aspect of this application provides a vehicle including the service diagnostic architecture described in the above embodiments.

[0019] A third aspect of this application provides a service diagnosis method, which is applied to the service diagnosis architecture of the above embodiments. The method includes the following steps: obtaining a data request from a diagnostic application or a server; invoking a publish / subscribe event or the application programming interface of the DDS application according to the data request to obtain service list data of the DDS application; sending the service list data to the server or the diagnostic application, wherein the server sends the service list data to the diagnostic application, so that the diagnostic application performs service diagnosis on the DDS application based on the service list data.

[0020] Based on the above technical means, the embodiments of this application can obtain the service list data of the DDS application by using two methods after obtaining the data request of the diagnostic application or the server: publish and subscribe to events or the application programming interface of the DDS application. Then, the service list data of the DDS application can be sent to the diagnostic application, or the service list data can be sent to the server first and then sent to the diagnostic application through the server. This can effectively realize convenient and fast service diagnosis of the DDS application, improve the convenience of service diagnosis, and enhance the user experience.

[0021] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the service diagnostic method as described in the above embodiments.

[0022] Therefore, this application has at least the following beneficial effects:

[0023] 1. In this embodiment, the management module can communicate with the server and obtain the service list data of the DDS application by using two methods: publishing and subscribing to events or the application programming interface of the DDS application. Then, the service list data of the DDS application can be sent to the diagnostic application, or the service list data can be sent to the server first and then sent to the diagnostic application through the server. This can effectively realize convenient and fast service diagnosis of the DDS application, improve the convenience of service diagnosis, and enhance the user experience.

[0024] 2. In this embodiment of the application, the request service list service and response service list request service defined by the management module can provide a data query interface for the diagnostic application, thereby enabling the diagnostic application to obtain service list data conveniently and quickly, and improving the user experience.

[0025] 3. The embodiments of this application can achieve a successful handshake between an online DDS application and a target DDS application by multicasting and sending heartbeat protocols, thereby providing the prerequisite for communication between the two applications and sending service information to each other, thus providing effective support for service list data management and facilitating subsequent service diagnosis.

[0026] 4. The embodiments of this application can update the service list data through callback functions, thereby achieving effective management of the service list data.

[0027] 5. This application embodiment can periodically determine the update flag of the service list data, and when the conditions are met, store the service list data and reset the update flag, thereby achieving minimal data backup.

[0028] 6. In this embodiment of the application, service list data can be sent to the server periodically so that the server can obtain the service list data.

[0029] 7. In this embodiment of the application, after obtaining a data request from a diagnostic application or server, the service list data of the DDS application can be obtained by using two methods: publish and subscribe to events or the application programming interface of the DDS application. Then, the service list data of the DDS application can be sent to the diagnostic application, or the service list data can be sent to the server first and then sent to the diagnostic application through the server. This can effectively realize convenient and fast service diagnosis of the DDS application, improve the convenience of service diagnosis, and enhance the user experience.

[0030] This solves the technical problems in related technologies, such as poor service diagnosis, low convenience, and poor user experience when services between DDS applications cannot communicate normally.

[0031] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0032] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0033] Figure 1 This is a schematic diagram of the service diagnostic architecture provided according to the embodiments of this application;

[0034] Figure 2 This is a business architecture diagram for online service list data management provided according to embodiments of this application;

[0035] Figure 3 This is a flowchart illustrating the application service list discovery and management process according to embodiments of this application.

[0036] Figure 4 This is a flowchart illustrating the offline management process of the application service list according to embodiments of this application.

[0037] Figure 5 This is a flowchart illustrating the application service list data archiving process according to an embodiment of this application.

[0038] Figure 6 Flowchart for the periodic reporting of application service list data to the cloud according to the embodiments of this application;

[0039] Figure 7 This is a flowchart of a service diagnosis method provided according to an embodiment of this application. Detailed Implementation

[0040] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0041] The service diagnostic architecture, vehicle, method, and storage medium of embodiments of this application are described below with reference to the accompanying drawings. To address the problems mentioned in the background section, this application provides a service diagnostic architecture. In this architecture, embodiments of this application can communicate with a server through a management module and obtain service inventory data of the DDS application using either publish / subscribe events or the application programming interface (API) of the DDS application. The service inventory data of the DDS application can then be sent to the diagnostic application, or it can be sent to the server first and then to the diagnostic application via the server. This effectively enables convenient and quick service diagnostics of the DDS application, improving the ease of service diagnostics and enhancing the user experience.

[0042] Specifically, Figure 1 This is a schematic diagram of a service diagnostic architecture provided in an embodiment of this application.

[0043] like Figure 1 As shown, the service diagnostic architecture includes one or more Data Distribution Service (DDS) application and management modules.

[0044] The management module provides a data query interface for the diagnostic application and communicates with the server via a network communication protocol. When it receives a data request from the diagnostic application or the server, it obtains the service list data of the DDS application through the publish and subscribe event or the application programming interface of the DDS application, and sends the service list data to the server or the diagnostic application. The server sends the service list data to the diagnostic application, enabling the diagnostic application to perform service diagnosis on the DDS application based on the service list data.

[0045] It is understood that the embodiments of this application can communicate with the server through the management module and obtain the service list data of the DDS application by using two methods: publishing and subscribing to events or the application programming interface of the DDS application. Then, the service list data of the DDS application can be sent to the diagnostic application, or the service list data can be sent to the server first and then sent to the diagnostic application through the server. This can effectively realize convenient and fast service diagnosis of the DDS application, improve the convenience of service diagnosis, and enhance the user experience.

[0046] Specifically, such as Figure 2As shown, to decouple the acquisition of the target application's online service list data, this application embodiment can adopt a non-intrusive architecture, including the following two implementation methods:

[0047] Method 1 involves obtaining service inventory data by matching callback functions during the endpoint discovery protocol phase through publish and subscribe events.

[0048] Method 2: Obtain service list data through the API (Application Programming Interface) methods published by DDS, such as get_discovered_topics.

[0049] Secondly, the acquired service list data can be managed and maintained. Newly discovered services are added to the service list, while offline applications are removed. Additionally, data support for diagnostic applications can be provided in two ways:

[0050] Method 1 involves subscribing to a service that sends service inventory data, thereby providing the diagnostic tool with service inventory data.

[0051] Method 2 involves sending the service list data to the server via network communication protocols, and then using diagnostic tools to display the acquired data.

[0052] The embodiments of this application can conveniently and quickly diagnose situations where DDS applications cannot communicate normally due to service integration issues under SOA (Service-Oriented Architecture) architecture. Especially in formal release environments, where debugging and diagnostic methods are limited, the advantages of the embodiments of this application are even more evident. Through the method proposed in the embodiments of this application, service diagnosis can be performed on any application that uses DDS for communication, further demonstrating the wide application range of the embodiments of this application.

[0053] Optionally, in one embodiment of this application, the management module defines a request service list service and a response service list request service. The request service list service includes a first service subscription event and a first service publication event. The DDS application registers the first service subscription event to support the diagnostic application in requesting service list data. The diagnostic application registers the first service publication event to request service list data from the DDS application. The response service list request service includes a second service subscription event and a second service publication event. The DDS application registers the second service publication event to send service list data to the diagnostic application. The diagnostic application registers the second service subscription event to receive service list data sent from the DDS application.

[0054] It is understood that, in this embodiment of the application, the request service list service and response service list request service defined by the management module can provide a data query interface for the diagnostic application, thereby enabling the diagnostic application to obtain service list data conveniently and quickly, and improving the user experience.

[0055] Specifically, the online service inventory application provides a data query interface for third-party diagnostic applications, enabling these applications to obtain service inventory data and generate diagnostic reports. An example is provided below; to support the query interface, the method is as follows:

[0056] (1) Define two services with the following names:

[0057] (a) Request service list: The topic name can be Get_TopicInfo_skeleton_request.

[0058] (b) Response service list request: The topic name can be Get_TopicInfo_skeleton_reply.

[0059] (2) Request service list: The service list application registers the Get_TopicInfo_skeleton_request service subscription event to support the diagnostic application in requesting service list data; the diagnostic application registers the Get_TopicInfo_skeleton_request publication event to request service list data from the service list application.

[0060] (3) Responding to service list requests: The service list application registers the Get_TopicInfo_skeleton_reply publish event to send service list data to the diagnostic application; the diagnostic application registers the Get_TopicInfo_skeleton_reply subscribe event to receive service list data sent from the service list application.

[0061] Optionally, in one embodiment of this application, for any online DDS application and target DDS application, the online DDS application and target DDS application multicast to the same multicast address and send a heartbeat protocol. After the target DDS application sends a heartbeat response protocol to the online DDS application, the handshake is successful, and they send each other a unified topic name of the data protocol to send the published or subscribed service information to the peer application to support the management of service list data.

[0062] It is understood that the embodiments of this application can achieve a successful handshake between the online DDS application and the target DDS application by multicasting and sending heartbeat protocols, and send service information to each other's applications, thereby providing effective support for service list data management and facilitating subsequent service diagnosis.

[0063] Specifically, the service list data source processing logic in this application embodiment is as follows: discovery and handshake between two DDS applications are prerequisites for communication between them; after a successful handshake, the two applications with matching topic names will send data to the peer application via the Data(w) and Data(r) protocols; the obtained data contains the service information required by this application embodiment. The process is as follows:

[0064] (1) Online service list applications, such as application A, and target applications, such as application B, multicast to the same multicast address, and after discovering each other, they perform a unicast.

[0065] (2) Application A sends a Heartbeat protocol to Application B, and Application B sends a Heartbeat response protocol to Application A, thus Application A and Application B successfully shake hands.

[0066] (3) The two applications send Data(w) and Data(r) to each other. The purpose is to send service information with the same topic name and successfully published or subscribed to the upper endpoint to the other application.

[0067] (4) Applications can obtain service discovery and offline status by using the callback functions matched in the publish and subscribe event API, thereby providing support for service inventory data management.

[0068] Optionally, in one embodiment of this application, the management module is further configured to: determine new services and / or offline services in the DDS application based on the callback function matching the publish and subscribe events, and update the service list data based on the new services and / or offline services.

[0069] It is understood that the embodiments of this application can update the service list data through callback functions, thereby achieving effective management of the service list data.

[0070] Specifically, such as Figure 3 and Figure 4 As shown, the service list data management module in this embodiment includes: core logic for managing service list data and processing service list data. The core logic may include:

[0071] (1) Data basic management logic: including data addition, deletion and retrieval.

[0072] (2) Service list data update logic: This includes implementing the service publishing and subscription registration event service matching callback function, handling the data addition logic when the service is discovered in the callback function, and the data deletion logic when the service is offline. Among them, the service being offline can be when there is no response after the heartbeat with the peer application.

[0073] (3) Data content: Domain ID (IDentity, identity number), target application unique identifier ID and topic name list.

[0074] Optionally, in one embodiment of this application, the management module is further configured to: identify whether the update identifier of the service list data meets the update conditions at intervals of a first preset time period; when the update identifier meets the update conditions, store the current service list data and reset the update identifier.

[0075] It is understood that the embodiments of this application can achieve minimal data backup by periodically determining the update flag of the service list data and storing and resetting the update flag of the service list data when the conditions are met.

[0076] Specifically, such as Figure 5 As shown, the core logic for processing service list data in this embodiment of the application also includes: in order to back up the data to a minimum, the application can achieve this by periodically archiving the service list data. At regular intervals, the application will determine the change flag of the service list data. If the service list data changes, the application will archive the current service list data and write the data to a text file in a refresh manner. Otherwise, it will not archive.

[0077] Optionally, in one embodiment of this application, the management module is further configured to: send service list data to the server at second preset intervals.

[0078] It is understood that, in the embodiments of this application, service list data can be sent to the server periodically so that the server can obtain the service list data.

[0079] Specifically, such as Figure 6 As shown in the embodiment of this application, the data is managed through a server-supported online service list application, providing more channels for querying and displaying the service list data. The server obtains the service list data in the following ways:

[0080] (1) The server can request service list data from the online service list application at any time.

[0081] (2) The service list application periodically reports data to the server.

[0082] Optionally, in one embodiment of this application, the DDS application is any application under a service-oriented architecture (SOA).

[0083] According to the service diagnostic architecture proposed in this application, the management module can communicate with the server and obtain the service inventory data of the DDS application using either publish / subscribe events or the application programming interface (API) of the DDS application. The service inventory data can then be sent to the diagnostic application, or it can be sent to the server first and then forwarded to the diagnostic application. This effectively enables convenient and quick service diagnostics of the DDS application, improving the ease of service diagnostics and enhancing the user experience. Therefore, it solves the problems of poor service diagnostic performance, low convenience, and poor user experience in related technologies when services between DDS applications cannot communicate normally.

[0084] Secondly, this application provides a vehicle that includes the service diagnostic architecture described in the above embodiments.

[0085] like Figure 7 As shown in the embodiments of this application, a service diagnosis method is also provided. The method is applied to a service diagnosis architecture, and includes the following steps:

[0086] In step S101, a data request is obtained from the diagnostic application or server.

[0087] In this application, data requests can be obtained in various ways, such as through online service list applications, without being specifically limited to any particular method.

[0088] In step S102, the service list data of the DDS application is obtained by calling the application programming interface of the publish and subscribe event or the DDS application according to the data request.

[0089] It is understood that there are two ways to obtain the service list data of DDS applications in this application embodiment, which improves the flexibility and efficiency of data acquisition.

[0090] In step S103, service list data is sent to the server or diagnostic application. The server sends the service list data to the diagnostic application, enabling the diagnostic application to perform service diagnostics on the DDS application based on the service list data.

[0091] It is understood that, in the embodiments of this application, the service list data of the DDS application can be sent to the diagnostic application, or the service list data can be sent to the server first, and then sent to the diagnostic application through the server. This can effectively realize convenient and fast service diagnosis of the DDS application, improve the convenience of service diagnosis, and enhance the user experience.

[0092] It should be noted that the foregoing explanation of the service diagnostic architecture embodiment also applies to the service diagnostic method of this embodiment, and will not be repeated here.

[0093] According to the service diagnosis method proposed in this application, the service list data of the DDS application is obtained by acquiring data requests from the diagnostic application or server and by using two methods: publishing and subscribing to events or the application programming interface of the DDS application. Then, the service list data of the DDS application can be sent to the diagnostic application, or the service list data can be sent to the server first and then sent to the diagnostic application through the server. This can effectively realize convenient and fast service diagnosis of the DDS application, improve the convenience of service diagnosis, and enhance the user experience.

[0094] This application also provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the service diagnosis method as described in the above embodiments.

[0095] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0096] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0097] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0098] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0099] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware, and the program can be stored in a computer-readable storage medium. When executed, the program includes one or a combination of the steps of the method embodiments.

[0100] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A service diagnostic architecture, characterized in that, include: One or more Data Distribution Service (DDS) applications; The management module provides a data query interface for the diagnostic application and communicates with the server via a network communication protocol. When it receives a data request from the diagnostic application or the server, it obtains the service list data of the DDS application through publish and subscribe events or the application programming interface of the DDS application. In the endpoint discovery protocol phase, the service list data is obtained by matching callback functions through publish and subscribe events, and the service list data is sent to the server or the diagnostic application. The server sends the service list data to the diagnostic application, so that the diagnostic application can perform service diagnosis on the DDS application based on the service list data. The management module is further configured to: determine new and / or offline services in the DDS application based on callback functions that match published and subscribed events, and update the service list data based on the new and / or offline services.

2. The architecture according to claim 1, characterized in that, The management module defines a request service list service and a response service list request service, wherein... The request service list service includes a first service subscription event and a first service publication event, wherein the DDS application registers the first service subscription event to support the diagnostic application in requesting service list data; the diagnostic application registers the first service publication event to request service list data from the DDS application. The response service list request service includes a second service subscription event and a second service publication event, wherein the DDS application registers the second service publication event to send service list data to the diagnostic application; and the diagnostic application registers the second service subscription event to receive service list data sent from the DDS application.

3. The architecture according to claim 1, characterized in that, For any online DDS application and the target DDS application, where, The online DDS application and the target DDS application multicast to the same multicast address and send a heartbeat protocol. After the target DDS application sends a heartbeat response protocol to the online DDS application, the handshake is successful, and they send each other a unified topic name of the data protocol to send the published or subscribed service information to the peer application to support the management of the service list data.

4. The architecture according to claim 1, characterized in that, The management module is further used for: The update flag of the service list data is identified at a first preset interval to determine whether the update condition is met. When the update flag meets the update condition, the current service list data is stored and the update flag is reset.

5. The architecture according to claim 1, characterized in that, The management module is further used for: The service list data is sent to the server at a second preset interval.

6. The architecture according to any one of claims 1-5, characterized in that, The DDS application is any application under the service-oriented architecture (SOA).

7. A vehicle, characterized in that, Includes the service diagnostic architecture as described in any one of claims 1-6.

8. A service diagnosis method, characterized in that, The method is applied to the service diagnostic architecture as described in any one of claims 1-6, wherein the method includes the following steps: Request data from diagnostic applications or servers; Based on the data request, call the publish and subscribe event or the application programming interface of the DDS application to obtain the service list data of the DDS application; The service list data is sent to the server or diagnostic application. The server sends the service list data to the diagnostic application, so that the diagnostic application performs service diagnostics on the DDS application based on the service list data.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the service diagnostic method as described in claim 8.

Images