Vehicle communication diagnosis method, device and system based on SOA and DDS

Abstract

The SOA and DDS oriented vehicle-mounted communication diagnosis method, device and system of the present disclosure comprises: detecting data of communication parties MPU in at least two MPU communication execution processes at the vehicle end; specifically comprising: obtaining real-time publication and subscription RTPS messages and data distribution service DDS log information; determining chain building information according to the RTPS messages, the chain building information comprising hierarchical relationships under a domain and a relationship between one of the two MPUs as a reader and the other as a writer, generating a communication connection structure diagram according to the chain building information, and obtaining a whole vehicle communication state according to the communication connection structure diagram and the DDS log information, the whole vehicle communication state being used to reflect whether a communication link between the at least two MPUs is normal, so that the state of the DDS communication node can be intuitively and real-timely monitored at the vehicle end, the safety of inter-network communication is improved, and the real-time performance in the transmission process is ensured.

Description

Technical Field

[0001] This invention relates to the technical field of inter-domain communication security protection, and in particular to a method, apparatus and system for vehicle communication diagnosis based on SOA and DDS. Background Technology

[0002] Automotive Ethernet is a new local area network technology that uses Ethernet to connect electronic units within a vehicle. As a development dimension of automobiles, it has brought a new revolution to vehicle communication and upper-level services. However, the functional safety of automotive Ethernet, as another development dimension, cannot be ignored.

[0003] As the automotive revolution deepens, SOA (Service-Oriented Architecture) is bringing increasingly diverse changes to the automotive industry. SOA can be implemented using SOME / IP or DDS (Data Distribution Service). SOME / IP, as part of the AUTOSAR (Automotive Open System Architecture) specification and relying on the reliability of the TCP transport layer, already considers the protection of communication function security. In contrast, the DDS-RTPS (Real-time Publish-Subscribe) protocol provides reliability independent of the TCP transport layer.

[0004] During the design phase, the network topology, logical topology, and QoS (Quality of Service) characteristics of DDS are typically defined. During development, these designs are implemented through standard interfaces and configuration files. However, in the integration phase, users lack direct means to verify the consistency between design and development, as well as the rationality of the design. When problems are exposed downstream, such as "not working" or "packet loss," the location of the problem is inaccurate. Furthermore, users lack an intuitive way to monitor the status of all DDS communication nodes. Summary of the Invention

[0005] In view of this, in order to solve the problem of DDS communication node failure on SOA architecture, the present invention provides a vehicle communication diagnostic method, device and system based on SOA and DDS.

[0006] In a first aspect, the present invention provides a vehicle communication diagnostic method based on SOA and DDS, the method comprising: detecting the data of the MPUs of at least two microprocessors (MPUs) in the vehicle during the communication process; The process involves detecting data from both MPUs in communication, including: acquiring real-time publish / subscribe (RTPS) messages and data distribution service (DDS) log information; determining link establishment information based on the RTPS messages, including hierarchical relationships within the domain and the relationship between one MPU as a reader and the other as a writer; generating a communication connection structure diagram based on the link establishment information; and obtaining the vehicle communication status based on the communication connection structure diagram and DDS log information, which reflects whether the communication link between at least two MPUs is normal.

[0007] In conjunction with the first aspect, in one possible implementation, determining the link establishment information based on the RTPS message includes: parsing the RTPS message to obtain the participant ID of the data packets transmitted between MPUs, the participant ID being used to determine the identity of the currently receiving MPU; based on the identity of the MPU determined from the participant ID, finding at least one reader or writer associated with the MPU; and based on the found at least one reader or writer, establishing a mapping relationship between at least one reader and writer, the at least one mapping relationship being the link establishment information.

[0008] In conjunction with the first aspect, in another possible implementation, generating a communication connection structure diagram based on the link establishment information includes: establishing a communication connection structure diagram based on at least one mapping relationship.

[0009] In conjunction with the first aspect, in another possible implementation, the DDS log information includes at least one indication message, which indicates whether a participant has been created, whether a topic has been created, and whether the QoS configuration items corresponding to the reader and writer are consistent. The vehicle communication status is obtained based on the communication connection structure diagram and DDS log information, including: determining whether the vehicle communication network deployment conforms to the design specifications, whether packet loss occurs during the communication process, and whether the transmission latency meets performance requirements and whether the configuration items are equal to the preset values, based on the communication connection structure diagram and at least one indication information; if all of these are true, the data communication detection between the vehicle MPUs is determined to be normal; if at least one of the following occurs, such as non-compliance with design specifications, packet loss, transmission latency exceeding the threshold, or configuration items not equal to the preset values, the data communication is determined to be abnormal.

[0010] In conjunction with the first aspect, in another possible implementation, determining whether the vehicle transmission delay meets the performance requirements includes: obtaining the first time of the received data packet and the second time of the sent data packet; calculating the time difference between the first time and the second time; if the time difference is greater than or equal to a time threshold, then determining that a timeout has occurred and a delay exists; otherwise, no delay has occurred.

[0011] In conjunction with the first aspect, in another possible implementation, determining whether packet loss occurs during the vehicle communication process includes: Obtain the first sequence number filled in by the first MPU when sending data packets; the first MPU is the data sender. Obtain the second sequence number filled in by the second MPU when receiving data packets; the second MPU acts as the data receiver. If the first sequence number matches the second sequence number, it is determined that no packets were lost during the communication transmission.

[0012] In conjunction with the first aspect, in yet another possible implementation, the communication process between at least two MPUs at the vehicle end also includes: detection of the communication link between at least two MPUs; The communication link detection for at least two MPUs includes: carrying user-configured DDS communication settings in the logs and messages during the communication process; and checking whether the configuration settings are correct.

[0013] In conjunction with the first aspect, in another possible implementation, detecting whether the configuration item is correct includes: comparing the configuration item with a pre-configured communication configuration item, and determining whether the configuration item in the configuration file is correct through comparison and verification.

[0014] In conjunction with the first aspect, in another possible implementation, during the communication process between at least two MPUs at the vehicle end, the method further includes: verifying whether the multicast address is correct, and / or allowing the multicast address to be open.

[0015] In conjunction with the first aspect, in another possible implementation, before detecting the data of the MPUs of both communicating parties, the method further includes: verifying the environment before communication; verifying the environment before communication includes: determining whether the communication network is normal, and checking whether the IP address configuration of the service provider meets the requirements of the vehicle communication deployment.

[0016] In conjunction with the first aspect, in another possible implementation, determining whether the communication network is normal includes: checking whether the corresponding communicating parties can ping each other by automatically configuring the ping command; if they can, the communication network is determined to be normal; if they cannot ping each other, the network is determined to be abnormal.

[0017] In conjunction with the first aspect, in another possible implementation, the IP address configuration of the service provider is checked to see if it meets the requirements for vehicle communication deployment, including: obtaining the DDS version; comparing the DDS version with the specified version; if the versions match, it is determined that it meets the requirements for vehicle communication deployment; otherwise, it does not.

[0018] In conjunction with the first aspect, in another possible implementation, the environment before communication is verified, including: tracing the function call chain of the toolchain to check whether each function is called correctly and whether it runs according to the software design logic; if it runs normally according to the software design logic, it is determined that the DDS application version is deployed and used correctly; if it does not run according to the software design logic, it is determined that the deployment is wrong and the host computer is instructed to return an error code.

[0019] Secondly, this application also provides an in-vehicle communication diagnostic device based on SOA and DDS, the device comprising: The acquisition module is used to acquire real-time publish-subscribe RTPS messages and data distribution service (DDS) log information during the communication execution of at least two microprocessors (MPUs) on the vehicle side. The determination module is used to determine the connection establishment information based on the RTPS message. The connection establishment information includes the hierarchical relationship under the domain, as well as the relationship between the two MPUs, one as a reader and the other as a writer. The generation module is used to generate a communication connection structure diagram based on the chain establishment information. The diagnostic module is used to obtain the vehicle communication status based on the communication connection structure diagram and DDS log information. The vehicle communication status is used to reflect whether the communication link between at least two MPUs is normal.

[0020] Secondly, this application also provides an in-vehicle communication diagnostic system, which includes: a vehicle-side component and a cloud-side component; wherein the vehicle-side component includes at least two microprocessors (MPUs), each MPU being used to execute the method described in the first aspect or any embodiment of the first aspect; and the cloud-side component is used to receive the communication diagnostic results from the vehicle-side component.

[0021] Thirdly, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the vehicle communication diagnostic method based on SOA and DDS described in the first aspect or any corresponding embodiment thereof.

[0022] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the SOA and DDS-based vehicle communication diagnostic method of the first aspect or any corresponding embodiment thereof.

[0023] The method, apparatus, and system provided in this embodiment detect the data of both MPUs during the communication execution process of the vehicle-side processor MPU. Specifically, based on the acquired RTPS messages and Data Distribution Service (DDS) log information, the link establishment information is determined, and a communication connection structure diagram is generated based on the link establishment information. Furthermore, the vehicle communication status is obtained based on the communication connection structure diagram and DDS log information. This vehicle communication status reflects whether the communication link between at least two MPUs is normal. For example, it can determine whether the vehicle communication network deployment conforms to design specifications, whether packet loss occurs during communication, whether the transmission latency meets performance requirements, and whether configuration items are equal to preset values. This allows for intuitive and real-time monitoring of the DDS communication node status on the vehicle side, improving the security of inter-network communication and ensuring real-time performance during the verification transmission process. Attached Figure Description

[0024] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0025] Figure 1 This is an overall architecture diagram of a self-diagnostic system provided in an embodiment of the present invention; Figure 2 This is a flowchart of a vehicle communication diagnostic method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a data detection process during communication execution provided by an embodiment of the present invention; Figure 4 This is a flowchart illustrating a service deployment diagnosis method provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of a log parsing process provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of a data display interface provided in an embodiment of the present invention; Figure 7 This is a flowchart of a configuration diagnostic method provided by an embodiment of the present invention; Figure 8 This is a structural block diagram of an in-vehicle communication diagnostic device provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] First, some basic concepts and application scenarios mentioned in the embodiments of the present invention will be introduced: Service-Oriented Architecture (SOA), proposed by Gartner, is widely used in internet software architecture. Currently, internet service protocols such as HTTP are developed based on SOA, providing transparent service interfaces for each layer of protocols while reducing external influence on these layers. SOA is a typical software technology introduced from the IT / internet industry to the automotive industry. There is currently much discussion and practice surrounding SOA in the automotive industry, mainly focusing on the concept of SOA itself and its practical applications in intelligent vehicles.

[0028] SOME / IP is a communication middleware solution for automotive or embedded systems. This protocol is an IP-based, service-oriented application layer network communication protocol with scalability, extensibility, and the ability to be used on different operating systems for communication between various devices.

[0029] DDS (Data Distribution Service) is a next-generation distributed real-time communication middleware protocol. Its high real-time performance, high reliability, open architecture, and decoupled publish / subscribe capabilities greatly accelerate and simplify the development of distributed systems, making it highly suitable for the automotive field. It can not only meet the needs of big data transmission in the intelligent driving domain of automobiles, but also meet the requirements of SOA architecture.

[0030] AUTOSAR, short for Automotive Open System Architecture, is a collaborative development framework for automotive electronic systems, involving global automakers, parts suppliers, and various research and service organizations. It establishes an open standard software architecture for automotive control units (ECUs).

[0031] The technical solution provided in this application is applicable to developers using DDS and to debugging DDS link tests. Testers can use it to monitor relevant information about DDS, monitor relevant information about the application, display relevant attributes of DDS, and determine communication failure processes.

[0032] Distributed Nodes (DDS) are currently used as a mainstream distributed communication system in vehicle service communication. In practical DDS applications, a large number of DDS communication nodes are typically deployed. During the design phase, the network topology, logical topology, QoS characteristics, etc., of the DDS are defined; during the development phase, these designs are implemented through standard interfaces and configuration files. However, during the integration phase, users lack direct means to verify the consistency between design and development, as well as the rationality of the design; when problems are exposed downstream, such as "no connection" or "packet loss," users lack effective methods for localization; and users also lack an intuitive way to monitor the status of all DDS communication nodes. To address these user pain points, this application provides a DDS diagnostic and monitoring method to solve the technical problem of inaccurate localization of communication anomalies in SOA and DDS.

[0033] In order to understand the communication status of distributed nodes and related information of DDS communication nodes, the technical solution of this application connects with external diagnostic devices through a diagnostic program to obtain relevant diagnostic information of DDS communication nodes. By capturing logs, messages and other information, the relevant information of the DDS process user can be diagnosed.

[0034] See Figure 1 This is a diagram illustrating the overall architecture of a self-diagnostic system provided in this embodiment of the invention. The system includes a cloud platform and a vehicle-side component. The vehicle-side component includes a host computer, a DDS (Data Center System), at least one application (APP), and an SOA (Service-Oriented Architecture) toolchain. The cloud platform includes at least one network device, such as a data center, a network server, a cloud server, or a cloud server cluster.

[0035] Specifically, based on the above business requirements, the modules to be developed need to be divided as follows: Toolchain (or SOA toolchain) To quickly view the service deployment status and vehicle communication status, and to monitor all DDS communication nodes, service information is proactively reported through protocol matching callback functions, and function call tracing is achieved through pre-embedded functions.

[0036] As an orchestratable service-oriented architecture, the SOA toolchain needs to diagnose whether the deployment versions of each functional service are consistent. Using the relevant APIs of DDS, service registration can be completed, and related function information can be parsed. An entity can be constructed based on this function information, and a path function call diagnosis can be performed based on this information.

[0037] Application side (including at least one APP) To ensure users correctly utilize the DDS configuration file and perform resource usage checks, DDS must communicate normally, and the configuration file must be correct. Configuration file checks and modifications, as well as monitoring of DDS entity information, include CPU utilization, memory usage, communication outgoing ports and IP addresses, running process IDs, number of participants, and matched peers. This information is then transmitted to the host computer via DDS.

[0038] host computer Users import the messages into relevant diagnostic tools, such as diagnostic centers. The diagnostic tools then extract important information and provide the analysis results to the users. During communication, both ends send RTPS (Real-time Publish-Subscribe) messages. The acquired RTPS messages are parsed to extract data from multiple stages of DDS communication, such as the discovery phase, connection establishment phase, and data phase. This data is then analyzed to form a table, creating a tree-like relational structure according to the communication flow. Communication decisions are then made based on this tree-like relational structure.

[0039] Similarly, by connecting between two controllers, RTPS packets can be captured and parsed in real time, and a communication connection structure diagram can be constructed, avoiding the waste of time and manpower by manually scanning packets. Furthermore, this function can also perform reverse engineering of data, importing it into an IDL (Interface Description Language) file. This allows for the deserialization of data packets from RTPS, as well as the data sent during communication, thus ensuring real-time verification during transmission.

[0040] The technical solution provided in this application will be described in detail below.

[0041] This invention provides a vehicle communication diagnostic method based on SOA and DDS. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although the logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0042] This application primarily focuses on diagnosing a functional point of a DDS based on an SOA architecture. DDS communication within an SOA architecture mainly falls into two categories: like Figure 2As shown, the process includes step S100: verifying the environment before communication; and step S101: detecting the data of the MPUs of both communicating parties during the communication process of at least two microprocessors (MPUs) on the vehicle side.

[0043] Step S100 mainly includes: determining network connectivity, IP reachability, address configuration, domainid configuration, etc. It also includes: determining the DDS version, CM module version, QoS, application version, etc.

[0044] Step S101 can be summarized as business monitoring during the actual execution process. The specific detection process of step S101 will be explained in detail below.

[0045] Figure 2 This is a flowchart of an in-vehicle communication diagnostic method based on SOA and DDS according to an embodiment of the present invention. The process can be executed by a diagnostic center on the MPU side of the vehicle or by a host computer. The process includes the following steps: Step S100: Detect the communication link between the at least two MPUs.

[0046] Step S101: During the communication process between at least two microprocessors (MPUs) on the vehicle side, the data of the MPUs of both communicating parties is detected.

[0047] Specifically, step S101 includes the following aspects: 1) Determine the information of the two communicating parties (server-vehicle), such as participants, whether a topic has been created, readers, writers, and construct the whole vehicle communication connection structure diagram.

[0048] 2) Use IDL (Interface Description Language) files to extract the data content during the communication process and compare it with the actual data that needs to be communicated.

[0049] In actual execution, the communication link between the two communicating parties—the client and the server in the vehicle—is checked to confirm its functionality. Communication link detection includes: configuration information detection and data detection between the communicating parties. The specific implementation method is to import the acquired RTPS messages and DDS logs into the diagnostic center. The diagnostic system will build a communication link tree based on the link establishment information, output the vehicle communication status, and determine whether the communication link is normal based on the communication status.

[0050] The data detection method between the two communicating parties described above will be described in detail below.

[0051] See Figure 3The present invention provides a vehicle communication diagnostic method based on SOA and DDS, wherein step S101 specifically includes: Step S1011: Obtain real-time publish / subscribe RTPS messages and data distribution service DDS log information.

[0052] like Figure 4 As shown, the vehicle-side includes at least one MPU, each MPU can act as both a reader and a writer. Figure 4 In the vehicle, there are 3 MPUs, such as MPU1 to MPU3. Each MPU can contain a diagnostic center, as well as a set of information such as service information registration, service information deregistration, switch registration, and service information reporting. It can send and receive service information data with the diagnostic center and receive the data reporting results returned by the diagnostic center.

[0053] Other MPUs may contain DDS programs for registration with other MPUs, module deployment, etc. For example, MPU1 sends service information data to MPU2, and MPU2, after receiving the service information data, forwards it to the internal diagnostic center.

[0054] The service information data may be in the form of RTPS messages, and may also include DDS log information.

[0055] Each MPU can function as either a server or a client, depending on whether it is a sender or a receiver.

[0056] Step S1012: Determine the connection establishment information based on the RTPS message. The connection establishment information includes the hierarchical relationship under the domain, and the relationship between one MPU as a reader and the other as a writer.

[0057] Specifically, one implementation involves parsing RTPS messages to obtain the participant ID of the data packets transmitted between MPUs, the participant ID being used to determine the identity of the currently receiving MPU; based on the identity of the MPU determined from the participant ID, finding at least one reader or writer associated with the MPU; and based on the found at least one reader or writer, establishing a mapping relationship between at least one reader and writer, the at least one mapping relationship being the link establishment information.

[0058] Furthermore, one implementation method for parsing RTPS messages is as follows: Figure 5As shown, all payload data is analyzed. Using the source MAC address as the primary key, IP packets with the same ID are stored in a list. Data that doesn't need to be grouped is filtered out, such as packets with only one ID. The remaining packets are then grouped. The grouping process specifically includes: identifying packets with the same ID; and concatenating the payload data based on the more Fragment and FragmentOffset (the position of the fragment offset from the beginning of the original data packet) to obtain the data packet information transmitted between MPUs. This data packet information includes at least one participant and each participant's GUID (Globally Unique Identifier). The GUID is a 128-bit binary identifier generated by an algorithm, used to identify objects such as registry entries, class and interface identifiers, databases, and system directories.

[0059] Step S1013: Generate a communication connection structure diagram based on the established connection information.

[0060] Specifically, step S1013 includes: establishing a communication connection structure diagram based on at least one mapping relationship, such as the association between a writer and a reader.

[0061] Step S1014: Obtain the vehicle communication status based on the communication connection structure diagram and the DDS log information. The vehicle communication status is used to reflect whether the communication link between the at least two MPUs is normal.

[0062] Specifically, the diagnostic center is used to diagnose client / server communication transmission messages. If the message is an RTPS message, the following steps are performed: The RTPS messages between the MPU1 client and the MPU2 server are obtained. These RTPS messages reveal the process of entity construction and establishing a communication link. Then, the participant's GUID is extracted from the SPDP diagnostic data packets within the RTPS messages. This participant's GUID is used to identify the current client and is a unique identifier for the client; because each client corresponds to a reader.

[0063] Furthermore, there is a hierarchical relationship between readers and writers. A domain contains multiple participants, and each participant contains multiple writers and multiple readers. A writer communicates with one reader. All sent data is retrieved based on the GUID, and a table is created. This table contains the relationships between readers and writers, such as... Figure 6As shown, the participants parsed from the message include: writer1, writer2, reader3, and reader4. For each participant, a matching participant is found in the preset correspondence. For example, if the participant writer's topic name and GUID are known, the matching reader is found based on the GUID. For example, the participant matching writer1 is reader1, which is determined based on the GUID. Then, a mapping relationship is established between writer1 and reader1.

[0064] The reader and writer parsed in the previous step, as well as the relationship between them, are formed into a mapping table and saved. After parsing the data packet, the connection status of each topic under the participant can be obtained, and a communication connection structure diagram (or vehicle communication link tree) is formed based on these connection statuses. Relevant communication information can be obtained from this communication connection structure diagram.

[0065] The DDS log information includes at least one indication message, which indicates whether a participant has been created, whether a topic has been created, whether the reader and writer have been created, and whether the QoS configuration items corresponding to the reader and writer are consistent.

[0066] Furthermore, DDS log information is used to determine all DDS communication processes. Any process that uses DDS communication can obtain relevant DDS information. First, log information can be filtered by its level. The configuration field of the application process can be used to obtain its configuration items, and entity creation can be determined by the entity field. DDS log information can be printed to the running program and output to the Ethernet via the control panel or a file. The host computer can then obtain this information through DDS communication.

[0067] Step S1014 above: Obtain the vehicle communication status based on the communication connection structure diagram and the DDS log information, including: Based on the communication connection structure diagram and the at least one indication information, determine whether the vehicle communication network deployment complies with the design specifications, whether packet loss occurs during the communication process, whether the transmission delay meets the performance requirements, and whether the configuration item is equal to the preset value; if all of these are true, then the data communication detection between different MPUs in the vehicle is normal; if at least one of the following occurs: non-compliance with design specifications, packet loss, transmission delay exceeding the threshold, or configuration item not equal to the preset value, then the data communication is abnormal.

[0068] Based on the communication connection structure diagram and DDS log information, determine the following information: which participant is created under each domain, which writer or reader the participant corresponds to, and what the corresponding QoS configuration items are, etc.

[0069] In step S1013 above, relevant information from both the sending and receiving ends is obtained, forming a matching communication connection structure diagram. This allows us to determine which devices are on the other end of each MPU (i.e., which reader corresponds to the writer it created, and the writer relationship between the created reader and the writer), what relevant data was sent, and how the host computer can parse the specific communication content between the two parties through RTPS messages. This also allows us to determine whether the sending is in accordance with the user definition, whether the receiving is normal, whether the writer or reader instance was successfully created, and the time of the obtained data printout. Based on the printout time, we can determine whether there is transmission delay or packet loss.

[0070] Specifically, in one possible implementation, step S1014 above, determining whether the vehicle transmission delay meets the performance requirements, includes: obtaining the first time (t1) of receiving the data packet and the second time (t2) of sending the data packet; calculating the time difference Δt between the first time (t1) and the second time (t2); if the time difference Δt is greater than or equal to the time threshold, it is determined that a timeout has occurred and a delay exists; otherwise, no delay has occurred.

[0071] Optionally, in another possible implementation, step S1014 above, determining whether packet loss occurred during the vehicle communication process, includes: obtaining the first write sequence number filled in by the first MPU when sending data packets, with the first MPU acting as the data sender; obtaining the second write sequence number filled in by the second MPU when receiving data packets, with the second MPU acting as the data receiver; if the first write sequence number matches the second write sequence number, then it is determined that no packet loss occurred during the communication transmission process.

[0072] Specifically, when the writer sends data, it fills in `writer_seqnum` (the first write sequence number). The reader receives the corresponding `writer_seqnum` (the second write sequence number) in the received message. Through this one-to-one correspondence, the receiver's `writer_seqnum` should equal the sender's `writer_seqnum`. If this is the case, then there is no packet loss during communication; otherwise, packet loss exists.

[0073] Furthermore, the entire communication process and data can be dynamically diagnosed through matching between two participants on the UI (User Interface). This information can also be processed in the cloud, with the cloud server determining whether the communication link is functioning correctly or not.

[0074] One criterion is to determine whether data communication is normal, that is, whether the deployment of the vehicle communication network complies with the design specifications, whether packet loss occurs during communication, and whether the transmission latency meets the performance requirements.

[0075] If, based on the generated communication connection structure diagram, it is determined that the write sequence number of the writer and the corresponding reader are equal, the latency is less than the threshold, and the configuration items are equal to the preset values, then the communication is normal, and the transmission in the network is confirmed to be normal.

[0076] If, according to the generated communication connection structure diagram, the writer_seqnum of the writer and the corresponding reader are not equal, or the latency is greater than or equal to the threshold, or the configuration item is not equal to the preset value, then the network communication is determined to be abnormal.

[0077] The method provided in this embodiment, based on the SOA architecture DDS communication node, detects the data of both MPUs during the MPU communication process of the vehicle-side processor. Specifically, based on the acquired RTPS packets and DDS log information, it determines the link establishment information, generates a communication connection structure diagram based on the link establishment information, and obtains the vehicle communication status based on the communication connection structure diagram and DDS log information. This vehicle communication status reflects whether the communication link between at least two MPUs is normal. For example, it can determine whether the vehicle communication network deployment meets the design specifications, whether packet loss occurs during the communication process, whether the transmission latency meets performance requirements, and whether the configuration items are equal to the preset values. Thus, the status of the DDS communication node can be monitored intuitively and in real time on the vehicle side, improving the security of inter-network communication and ensuring the real-time performance of the verification transmission process.

[0078] Optionally, in the above embodiments, step S101, the detection during the actual execution process, further includes: detection of the communication link between at least two MPUs, specifically including: detection of configuration item information.

[0079] Furthermore, the configuration item information detection involves checking whether the configuration items configured by the user for communication using DDS are correct, as the logs and messages during the communication process carry the corresponding configuration items. This ensures the normal operation of the communication.

[0080] Specifically, one method to check if a configuration item is correct is, such as Figure 7 As shown, first obtain the DDS configuration file, compare the configuration items with the pre-configured communication configuration items, and determine whether the configuration items in the configuration file are correct through comparison and verification.

[0081] Detection method: Correct (pre-configured) communication configuration items are pre-set in the diagnostic center. Then, the obtained configuration items are compared with the correct ones. The configuration file items are compared and verified to check for any incorrect configuration items. If the comparison is inconsistent, an incorrect configuration item is confirmed; otherwise, the configuration item is diagnosed as correct. Optionally, if the configuration is correct, the parameter is displayed in green; if the configuration is incorrect, a red alarm is used.

[0082] In addition, during the communication process between at least two MPUs on the vehicle side, the following steps are also included: verifying whether the multicast address is correct, and / or allowing the multicast address to be open.

[0083] Specifically, this involves verifying whether the multicast address is correct, whether multicast is enabled, and whether loopback is allowed. This can be done in two ways: first, by verifying the communication connection between one MPU and another; second, by verifying that the local IP addresses used by different controllers are effective; and third, by providing methods to modify configurations and correct any errors.

[0084] In the actual execution phase, it also includes: monitoring entity information. Some code is pre-embedded in the DDS library to obtain relevant information about application processes using the protocol stack in the system. This allows for monitoring of program load and reporting some basic information about the program itself to the diagnostic center, such as CPU usage and memory usage. In turn, the diagnostic center obtains the usage and calling information of each thread in the application process and uses this information to detect whether the communication link is normal.

[0085] The method provided in this embodiment enables communication link detection during MPU communication execution, specifically by detecting configuration item information, thereby enabling real-time detection of the communication status between the two ends of the transmission.

[0086] In addition, such as Figure 2 As shown, in another embodiment, step S100 above: verifying the environment before communication, specifically includes: determining whether the communication network is normal, and checking whether the IP address configuration of the service provider meets the requirements of the vehicle communication deployment.

[0087] Specifically, environmental detection 1: determine whether the communication network is normal. One implementation method is to check whether the corresponding communication parties can ping each other by automatically configuring the ping command. If they can, the communication network is normal and normal communication can be carried out. If they cannot ping each other, the network or communication is abnormal and the user needs to check the hardware environment.

[0088] The ping command is a network diagnostic tool applicable to Windows, Unix, and Linux systems. It is part of the TCP / IP protocol and is used to determine whether a local host can exchange datagrams with another host. Based on the returned information, one can infer whether the TCP / IP parameter settings are correct and whether the operation is normal, i.e., whether the ping is successful.

[0089] Environment Detection 2: Check whether the IP address configuration of the business party meets the requirements of vehicle communication deployment. One specific implementation method is to obtain the DDS version; compare the DDS version with the specified version; if the versions are consistent, it is determined that it meets the requirements of vehicle communication deployment; otherwise, it does not meet the requirements.

[0090] For example, the host computer checks whether the IP address configuration of the service provider conforms to the vehicle communication deployment, and whether the domainid configuration of the communication service provider conforms to the settings, etc. The detection methods include: obtaining the DDS version and comparing it with the specified version to determine if the version is normal; reading the module version number of the communication module layer (CM) and comparing it with the version number agreed upon by the service provider; obtaining the application's QoS to determine if it conforms to the communication specifications; and reading the application's version to ensure alignment between the two communicating parties, etc.

[0091] Environment Detection 3: DDS Application Version Detection under SOA Architecture.

[0092] One implementation involves tracing the function call chain of the toolchain to check whether each function is called correctly and whether it runs according to the software design logic. If it runs normally according to the software design logic, it is determined that the DDS application version is deployed and used correctly. If it does not run according to the software design logic, it is determined that the deployment is wrong, and the host computer is instructed to return an error code.

[0093] Specifically, for function call chain diagnosis of SOA architecture, each DDS process using SOA architecture will call the same set of function call chains. Therefore, during the release process, code points are pre-installed in the architecture, and logs are output synchronously during the call process. The program can output the logs to the console. At the same time, the function call chain content is transmitted out through a specific interface. By subscribing to this interface, the self-diagnostic system can obtain the content and perform a function call diagnosis.

[0094] Detection method: By tracing the function call chain of the toolchain, it is confirmed whether each function is called correctly and whether it runs according to the software design logic. If it runs normally according to the software design logic, the DDS application version is deployed and used correctly. If it does not run according to the software design logic, the deployment is incorrect, the host computer returns an error code, and prompts the user to change the code software.

[0095] Finally, the diagnostic information obtained from environmental detection 1 to environmental detection 3 is uploaded to the cloud. The data is obtained from the remote control link through a request to the cloud and then uploaded to the cloud. The data is parsed in the cloud, and the parsed diagnostic results are displayed through a visualization interface. The results of multi-terminal diagnosis can be displayed, or the data can be uploaded to the cloud and cached in the cloud after local diagnosis access. This can reduce the network load caused by the large amount of data uploaded from the vehicle to the cloud. This method can reduce the network load pressure.

[0096] Furthermore, this embodiment also provides an in-vehicle communication diagnostic device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0097] This embodiment provides an in-vehicle communication diagnostic device based on SOA and DDS, such as Figure 8 As shown, the device includes: an acquisition module 801, a determination module 802, a generation module 803, a diagnosis module 804, and other functional modules, such as a storage module.

[0098] The acquisition module 801 is used to acquire real-time publish-subscribe RTPS messages and data distribution service (DDS) log information during the communication execution of at least two microprocessors (MPUs) on the vehicle side.

[0099] The determination module 802 is used to determine the connection establishment information based on the RTPS message. The connection establishment information includes the hierarchical relationship under the domain and the relationship between one MPU as a reader and the other as a writer.

[0100] The generation module 803 is used to generate a communication connection structure diagram based on the chain establishment information.

[0101] The diagnostic module 804 is used to obtain the vehicle communication status based on the communication connection structure diagram and the DDS log information. The vehicle communication status is used to reflect whether the communication link between the at least two MPUs is normal.

[0102] In this embodiment, the vehicle communication diagnostic device is presented in the form of a functional unit. Here, a unit refers to an ASIC circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0103] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0104] In addition, this embodiment also provides an in-vehicle communication diagnostic system, the architecture of which can be referred to the foregoing. Figure 1 As shown, it includes: vehicle-side and cloud-side; it may also include a host computer, which may be located inside or outside the vehicle-side as a separate device.

[0105] The vehicle-side component includes at least two microprocessors (MPUs), each MPU being used to execute the vehicle communication diagnostic method described in the aforementioned embodiments; the cloud-side component is used to receive the communication diagnostic results from the vehicle-side component.

[0106] In addition, the host computer can also execute the vehicle communication diagnostic method in the aforementioned method embodiment. The specific process is the same as the MPU execution method on the vehicle side, and will not be described again in this embodiment.

[0107] This invention also provides an electronic device having the above-described features. Figure 8 The vehicle-mounted communication diagnostic device shown.

[0108] Please see Figure 9 This is a schematic diagram of the structure of an electronic device provided in an optional embodiment of the present invention, such as... Figure 9 As shown, the electronic device includes one or more processors 10, a memory 20, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processor can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces).

[0109] In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple storage devices, if needed. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 9 Take a processor 10 as an example.

[0110] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0111] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0112] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device as displayed on a mini-program landing page. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0113] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0114] The electronic device also includes an input device 30 and an output device 40. The processor 10, memory 20, input device 30, and output device 40 can be connected via a bus or other means. Figure 9 Taking the example of a connection between China and Israel via a bus.

[0115] Input device 30 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 40 may include display devices, auxiliary lighting devices (e.g., LEDs), and haptic feedback devices (e.g., vibration motors). The aforementioned display devices include, but are not limited to, liquid crystal displays, light-emitting diodes, displays, and plasma displays. In some alternative embodiments, the display device may be a touch screen.

[0116] The electronic device also includes a communication interface for communicating with other devices or communication networks.

[0117] Optionally, the aforementioned electronic device can be a vehicle-mounted device, a cloud-based network device, or a device that includes a host computer.

[0118] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0119] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A diagnostic method for vehicle communication based on SOA and DDS, characterized in that, The method includes: During the communication process between at least two microprocessor MPUs on the vehicle side, the data of the MPUs of both communicating parties is detected; The detection of data from the MPUs of both communicating parties includes: Obtain real-time publish / subscribe RTPS messages and data distribution service (DDS) log information; The connection establishment information is determined based on the RTPS message. The connection establishment information includes the hierarchical relationship under the domain, as well as the relationship between one MPU as a reader and the other as a writer. Generate a communication connection structure diagram based on the established chain information; The vehicle communication status is obtained based on the communication connection structure diagram and the DDS log information. The vehicle communication status is used to reflect whether the communication link between the at least two MPUs is normal. The step of determining the link establishment information based on the RTPS message includes: Parse the RTPS message to obtain the participant ID of the data packet transmitted between MPUs. The participant ID is used to determine the identity of the currently receiving MPU. Based on the identity of the MPU determined from the participant ID, locate at least one reader or writer associated with the MPU; Based on the searched at least one reader or writer, establish at least one mapping relationship between readers and writers, wherein at least one of the mapping relationships is the chain-building information; The DDS log information includes at least one indication message, which is used to indicate whether a participant has been created, whether a topic has been created, and whether the QoS configuration items corresponding to the reader and writer are consistent. The step of obtaining the vehicle communication status based on the communication connection structure diagram and the DDS log information includes: The data content during the communication process is decrypted using the IDL file. Based on the communication connection structure diagram and the at least one indication information, it is determined whether the vehicle communication network deployment complies with the design specifications, whether packet loss occurs during the communication process, whether the transmission delay meets the performance requirements, and whether the configuration items are equal to the preset values. If all are yes, then the data communication between the vehicle's MPUs is detected as normal. If at least one of the following occurs: non-compliance with design specifications, packet loss, transmission delay exceeding the threshold, or configuration item not equal to the preset value, then the data communication is determined to be abnormal.

2. The method according to claim 1, characterized in that, The step of generating a communication connection structure diagram based on the chain establishment information includes: Based on the at least one mapping relationship, establish the communication connection structure diagram.

3. The method according to claim 1, characterized in that, The determination of whether the vehicle transmission latency meets the performance requirements includes: Get the first time of receiving the data packet and the second time of sending the data packet (as printed); Calculate the time difference between the first time and the second time; If the time difference is greater than or equal to the time threshold, a timeout is determined and a delay exists; otherwise, no delay has occurred.

4. The method according to claim 1, characterized in that, The determination of whether packet loss occurs during the vehicle communication process includes: Obtain the first sequence number filled in by the first MPU when sending data packets, where the first MPU is the data sender; Obtain the second sequence number filled in by the second MPU when receiving data packets, where the second MPU acts as the data receiver; If the first written sequence number matches the second written sequence number, it is determined that no packets were lost during the communication transmission.

5. The method according to claim 1, characterized in that, During the communication execution process of at least two MPUs on the vehicle side, the method further includes: detecting the communication link of the at least two MPUs; The communication link detection of the at least two MPUs includes: The logs and messages during the communication process carry the configuration items for using DDS for communication configured by the user. Check if the configuration items are correct.

6. The method according to claim 5, characterized in that, Checking whether the configuration items are correct includes: The configuration items are compared with the pre-configured communication configuration items. Through comparison and verification, it is determined whether the configuration items in the configuration file are correct.

7. The method according to claim 5, characterized in that, The process of at least two MPU communications on the vehicle side also includes: Verify that the multicast address is correct, and / or allow the multicast address to be open.

8. The method according to any one of claims 1-7, characterized in that, Before detecting the data of the MPUs of both communicating parties, the process also includes: verifying the environment before communication; The verification of the environment before communication includes: Determine if the communication network is functioning properly, and check if the IP address configuration of the service provider meets the requirements for vehicle communication deployment.

9. The method according to claim 8, characterized in that, The determination of whether the communication network is normal includes: By automatically configuring the ping command, we can check whether the corresponding communicating parties can ping each other. If ping is successful, the communication network is considered to be normal; if ping fails, the network is considered to be abnormal.

10. The method according to claim 8, characterized in that, The check of whether the IP address configuration of the service provider meets the requirements of the vehicle communication deployment includes: Get the DDS version; Compare the DDS version with the specified version; If the versions are consistent, then it is determined that it meets the requirements for vehicle communication deployment; otherwise, it does not.

11. The method according to claim 8, characterized in that, The verification of the environment before communication includes: By tracing the function call chain of the toolchain, we can check whether each function is called correctly and whether it runs according to the software design logic. If the software runs normally according to the design logic, then the DDS application version is correctly deployed and used. If the software does not operate according to the design logic, a deployment error is identified, and the host computer is instructed to return an error code.

12. A vehicle communication diagnostic device based on SOA and DDS, characterized in that, The device includes: The acquisition module is used to acquire real-time publish-subscribe RTPS messages and data distribution service (DDS) log information during the communication execution of at least two microprocessors (MPUs) on the vehicle side. The determination module is used to determine connection establishment information based on the RTPS message. The connection establishment information includes hierarchical relationships under the domain and the relationship between one MPU as a reader and the other as a writer. Determining the connection establishment information based on the RTPS message includes: parsing the RTPS message to obtain the participant ID of the data packets transmitted between the MPUs, the participant ID being used to determine the identity of the currently receiving MPU; based on the identity of the MPU determined from the participant ID, finding at least one reader or writer associated with the MPU; and establishing a mapping relationship between at least one reader and writer based on the found at least one reader or writer, where at least one of the mapping relationships constitutes the connection establishment information. The generation module is used to generate a communication connection structure diagram based on the chain establishment information; The diagnostic module is used to obtain the vehicle communication status based on the communication connection structure diagram and the DDS log information. The vehicle communication status reflects whether the communication link between at least two MPUs is normal. The DDS log information includes at least one indication, which indicates whether a participant has been created, whether a topic has been created, and whether the QoS configuration items corresponding to the reader and writer, and the reader and writer, are consistent. Obtaining the vehicle communication status based on the communication connection structure diagram and the DDS log information includes: reversing the data content during the communication process through the IDL file, and judging whether the vehicle communication network deployment conforms to the design specifications, whether packet loss occurs during the communication process, and whether the transmission latency meets the performance requirements and whether the configuration items are equal to the preset values, based on the communication connection structure diagram and the at least one indication. If all are true, the data communication detection between the vehicle MPUs is determined to be normal. If at least one of the following occurs: non-compliance with design specifications, packet loss, transmission latency exceeding the threshold, or configuration items not equal to the preset values, the data communication is determined to be abnormal.

13. A vehicle-mounted communication diagnostic system, characterized in that, The system includes: vehicle-side and cloud-side components; The vehicle end includes at least two microprocessors (MPUs), each MPU being used to perform the method as described in any one of claims 1 to 11; The cloud is used to receive the communication diagnostic results from the vehicle.

14. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory and the processor are connected. The memory stores computer instructions; The processor executes the computer instructions to perform the vehicle communication diagnostic method based on SOA and DDS as described in any one of claims 1 to 11.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions; The computer instructions are used to cause the computer to execute the vehicle communication diagnostic method based on SOA and DDS as described in any one of claims 1 to 11.

Images