Method and apparatus for monitoring data distribution service function

Abstract

The present disclosure relates to a method and device for monitoring a data distribution service function, comprising: obtaining a target call message generated when a first check unit in a target logical monitoring chain is called, the target logical monitoring chain comprising at least one check unit, the target call message comprising first information for indicating the first check unit; obtaining a configuration file associated with the target data distribution service function, the configuration file being configured with call rule information of each check unit; determining an execution result corresponding to the first check unit according to the configuration file and the first information in the target call message, the execution result being used to indicate whether the call of the first check unit conforms to the call rule information; and determining running information of the target data distribution service according to the execution result. In this way, the running of the data distribution service function can be found in time once it is abnormal, and the driving safety of the vehicle is improved.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle technology, and more particularly to a method and apparatus for monitoring a data distribution service function. Background Technology

[0002] With the rapid development of vehicle manufacturing technology and deep learning technology, configuring deep learning-based autonomous driving models on vehicles can achieve autonomous driving, and vehicle intelligence and vehicle-to-vehicle connectivity have become an inevitable trend. Specifically, configuring a publish-subscribe communication middleware in the vehicle to provide Data Distribution Service (DDS) functionality, offering various Quality of Service (QoS) policies, can ensure real-time, efficient, and flexible data distribution, meeting the needs of various distributed real-time communication applications.

[0003] Currently, the operation of vehicle data distribution services is typically implemented by functional programs containing numerous functions. However, if an error occurs during the execution of a function within these programs, it will cause the data distribution service to malfunction. If this malfunction is not detected in time, it can lead to vehicle communication failures, thereby affecting driving safety. Summary of the Invention

[0004] To overcome the problems existing in related technologies, this disclosure provides a method and apparatus for monitoring data distribution service functions.

[0005] According to a first aspect of the present disclosure, a method for monitoring a data distribution service function is provided, comprising:

[0006] When the target data distribution service function is running, the target call message generated when the first check unit in the target logic monitoring chain is called is obtained. The target logic monitoring chain includes at least one check unit. The at least one check unit is set in the running program of the target data distribution service function. The first check unit is any one of the at least one check unit. The target call message includes first information for indicating the first check unit.

[0007] Obtain the configuration file associated with the target data distribution service function. The configuration file contains the calling rule information of each inspection unit in the target logical monitoring chain.

[0008] Based on the configuration file and the first information in the target call message, determine the execution result corresponding to the first check unit, wherein the execution result is used to indicate whether the call of the first check unit conforms to the call rule information;

[0009] Based on the execution results, determine the operational information of the target data distribution service.

[0010] In some implementations, the configuration file specifies the calling order of each check unit in the target logical monitoring chain; the first check unit is the Nth check unit called during the operation of the target data distribution service function, where N is a positive integer.

[0011] The above determination of the execution result corresponding to the first inspection unit based on the configuration file and the target call message includes:

[0012] The second check unit corresponding to the Nth position in the call order of the configuration file is compared with the Nth check unit indicated by the first information to obtain the execution result corresponding to the first check unit, where:

[0013] If the preset conditions are met between the second checking unit and the Nth checking unit, the execution result indicates that the call to the first checking unit conforms to the calling rule information;

[0014] If the preset conditions are not met between the second checking unit and the Nth checking unit, the execution result indicates that the call to the first checking unit does not conform to the calling rule information.

[0015] In some implementations, the configuration file contains the calling rule information for each inspection unit in the M logical monitoring chains, and the target logical monitoring chain is any one of the M logical monitoring chains; the target calling message also includes second information for indicating the target logical monitoring chain, where M is an integer greater than 1.

[0016] The above determination of the execution result corresponding to the first inspection unit based on the configuration file and the first information in the target call message includes:

[0017] Based on the second information in the target invocation message, determine the target invocation rule information in the configuration file that corresponds to the target logical monitoring chain;

[0018] Based on the target invocation rule information and the first information in the target invocation message, determine the execution result corresponding to the first inspection unit.

[0019] In some implementations, the communication middleware corresponding to the target data distribution service function has N data distribution service threads, and the N data distribution service threads run the running programs of N data distribution service functions, where N is an integer greater than or equal to M.

[0020] Each of the M logical monitoring chains corresponds to the running program of at least one data distribution service function. The inspection unit in each logical monitoring chain is set in the running program of at least one data distribution service function corresponding to it, and the running programs of at least one data distribution service function corresponding to different logical monitoring chains are different.

[0021] In some implementations, the target logic monitoring chain corresponds to the runtime programs of multiple data distribution service functions, and the runtime programs of the multiple data distribution service functions have different source codes.

[0022] In some implementations, the method further includes:

[0023] When the first check unit in the target logic monitoring chain is invoked, second information associated with the target logic monitoring chain and first information of the first check unit are generated, and a target invocation message for the first check unit is formed based on the second information and the first information of the first check unit; or,

[0024] When the Kth check unit in the target logic monitoring chain is called, the first information of the Kth check unit is generated, and the target call message of the Kth check unit is formed based on the second information and the first information of the Kth check unit. The second information is the information generated when the first check unit in the target logic monitoring chain is called.

[0025] In some implementations, the target call messages generated when each check unit in the target logic monitoring chain is invoked are cached in thread-local storage associated with the target logic monitoring chain.

[0026] The above methods may also include:

[0027] If the first check unit is determined to be the last check unit in the target logic monitoring chain, clear the cached call messages in the thread-local storage associated with the target logic monitoring chain.

[0028] According to a second aspect of the present disclosure, a monitoring device for a data distribution service function is provided, comprising:

[0029] The message acquisition module is used to acquire the target call message generated when the first check unit in the target logic monitoring chain is called during the runtime of the target data distribution service function. The target logic monitoring chain includes at least one check unit, which is set in the runtime of the target data distribution service function. The first check unit is any one of the at least one check unit. The target call message includes first information for instructing the first check unit.

[0030] The configuration file acquisition module is used to acquire the configuration file associated with the target data distribution service function. The configuration file contains the calling rule information of each inspection unit in the target logical monitoring chain.

[0031] The execution result determination module is used to determine the execution result corresponding to the first checking unit based on the configuration file and the first information in the target call message. The execution result is used to indicate whether the call of the first checking unit conforms to the call rule information.

[0032] The monitoring module is used to determine the operational information of the target data distribution service based on the execution results.

[0033] In some implementations, the configuration file specifies the calling order of each check unit in the target logical monitoring chain; the first check unit is the Nth check unit called during the operation of the target data distribution service function, where N is a positive integer.

[0034] The execution result determination module can be used for:

[0035] The second check unit corresponding to the Nth position in the call order of the configuration file is compared with the Nth check unit indicated by the first information to obtain the execution result corresponding to the first check unit, where:

[0036] If the preset conditions are met between the second checking unit and the Nth checking unit, the execution result is an indication that the call to the first checking unit conforms to the calling rule information;

[0037] If the preset conditions are not met between the second checking unit and the Nth checking unit, the execution result is an indication that the call to the first checking unit does not conform to the calling rule information.

[0038] In some implementations, the configuration file contains the calling rule information for each inspection unit in the M logical monitoring chains, and the target logical monitoring chain is any one of the M logical monitoring chains; the target calling message also includes second information for indicating the target logical monitoring chain, where M is an integer greater than 1.

[0039] The above-mentioned execution result determination module may include:

[0040] The call rule information determination unit is used to determine the target call rule information corresponding to the target logical monitoring chain in the configuration file based on the second information in the target call message.

[0041] The execution result determination unit is used to determine the execution result corresponding to the first inspection unit based on the target invocation rule information and the first information in the target invocation message.

[0042] In some implementations, the communication middleware corresponding to the target data distribution service function has N data distribution service threads, and the N data distribution service threads run the running programs of N data distribution service functions, where N is an integer greater than 1;

[0043] Each of the M logical monitoring chains corresponds to the running program of at least one data distribution service function. The inspection unit in each logical monitoring chain is set in the running program of at least one data distribution service function corresponding to it, and the running programs of at least one data distribution service function corresponding to different logical monitoring chains are different.

[0044] In some implementations, the target logic monitoring chain corresponds to the runtime programs of multiple data distribution service functions, and the runtime programs of the multiple data distribution service functions have different source codes.

[0045] In some embodiments, the apparatus further includes:

[0046] The message generation module is used for:

[0047] When the first check unit in the target logic monitoring chain is invoked, second information associated with the target logic monitoring chain and first information of the first check unit are generated, and a target invocation message for the first check unit is formed based on the second information and the first information of the first check unit; or,

[0048] When the Kth check unit in the target logic monitoring chain is called, the first information of the Kth check unit is generated, and the target call message of the Kth check unit is formed based on the second information and the first information of the Kth check unit. The second information is the information generated when the first check unit in the target logic monitoring chain is called.

[0049] In some implementations, the target call messages generated when each check unit in the target logic monitoring chain is invoked are cached in thread-local storage associated with the target logic monitoring chain.

[0050] The device may also include:

[0051] The message clearing module is used to clear the call messages cached in the thread-local storage associated with the target logical monitoring chain when the first checking unit is determined to be the last checking unit in the target logical monitoring chain.

[0052] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; and a monitoring method for reading executable instructions from the memory and executing the instructions to implement the data distribution service function provided in the first aspect of the present disclosure.

[0053] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided that stores computer program instructions thereon, which, when executed by a processor, implement the steps of a monitoring method for the data distribution service function provided in the first aspect of the present disclosure.

[0054] According to a fifth aspect of the present disclosure, a vehicle is provided that stores a set of instructions, which are executed by the vehicle to implement a monitoring method for the data distribution service function provided in the first aspect of the present disclosure; the method also includes a monitoring device for the data distribution service function provided in the second aspect of the present disclosure.

[0055] The technical solutions provided by the embodiments of this disclosure can include the following beneficial effects: By configuring a target logic monitoring chain including at least one inspection unit and a configuration file, when the data distribution service function is running, the vehicle can determine the execution result of the call to indicate whether the call of the first inspection unit conforms to the call rule information based on the configuration file and the target call message when the first inspection unit is called. The vehicle can also determine the running information of the data distribution service based on the execution result, thereby enabling real-time monitoring of the operation of the data distribution service function. If the data distribution service function is abnormal, it can be detected in time, improving the vehicle's driving safety. In addition, the target logic monitoring chain can enable multiple inspection units to be set at any position in the running program of the data distribution service function, making the setting of inspection units more flexible. Moreover, by running the running program of the data distribution service function once, it is possible to detect whether multiple functions that need to be monitored by the running program are normal, resulting in a smaller amount of data during the monitoring process of the data distribution service function.

[0056] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0057] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0058] Figure 1 This is one of the flowcharts illustrating a monitoring method for a data distribution service function according to an exemplary embodiment.

[0059] Figure 2 This is a second flowchart illustrating a monitoring method for a data distribution service function according to an exemplary embodiment;

[0060] Figure 3 This is a second flowchart illustrating a monitoring method for a data distribution service function according to an exemplary embodiment;

[0061] Figure 4 This is a block diagram illustrating a monitoring device for a data distribution service function according to an exemplary embodiment.

[0062] Figure 5 This is a block diagram illustrating a vehicle according to an exemplary embodiment.

[0063] Figure 6 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0064] The exemplary embodiments will now be described in detail with reference to the accompanying drawings.

[0065] It should be noted that the relevant embodiments and accompanying drawings are only for describing and illustrating exemplary embodiments provided by this disclosure, and not all embodiments of this disclosure, nor should this disclosure be understood to be limited to the relevant exemplary embodiments.

[0066] It should be noted that the terms "first," "second," etc., used in this disclosure are only used to distinguish different steps, devices, or modules. These terms do not represent any specific technical meaning, nor do they indicate any order or interdependence between them.

[0067] It should be noted that the terms “a,” “a plurality of,” and “at least one” used in this disclosure are illustrative rather than restrictive. Unless otherwise expressly indicated in the context, they should be understood as “one or more.”

[0068] It should be noted that the term "and / or" used in this disclosure is used to describe the dependency relationship between dependent objects, and generally indicates that there are at least three dependencies. For example, A and / or B can at least represent: A exists alone, A and B exist simultaneously, and B exists alone.

[0069] It should be noted that the various steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Unless otherwise specified, the scope of this disclosure is not limited by the order in which the steps are described in the relevant embodiments.

[0070] It should be noted that all actions involving the acquisition of signals, information, or data in this disclosure are carried out in compliance with the relevant data protection laws and policies of the country where the location is situated, and with authorization from the owner of the relevant device.

[0071] Exemplary methods

[0072] Figure 1 This is a flowchart illustrating a monitoring method for a Data Distribution Service (DDS) function according to an exemplary embodiment, which is applied to an electronic device. Figure 1 As shown, the monitoring method for the DDS function includes the following steps S110 to S140.

[0073] Step S110: When the target DDS function is running, obtain the target call message generated when the first check unit in the target logical supervision chain (CLSC) is called. The target logical supervision chain includes at least one check unit, which is set in the running program of the target DDS function. The first check unit is any one of the at least one check unit. The target call message includes first information for indicating the first check unit.

[0074] In this embodiment, the target DDS function can be any DDS function implemented by a publish-subscribe communication middleware installed in the vehicle. This communication middleware can have at least one thread during operation, and each thread provides DDS functionality to a component in the vehicle (such as a domain controller). That is, when the DDS function of a thread is running, the DDS component can achieve communication between the corresponding components.

[0075] The aforementioned vehicle is pre-configured with the aforementioned target logic monitoring chain, and the target logic monitoring chain includes at least one inspection unit. Each inspection unit can be a running program set in the aforementioned DDS function. When the running program of the DDS function is running, the DDS function is running. When the running program reaches the location of the inspection unit, the inspection unit is called.

[0076] It should be noted that when the target logic monitoring chain includes multiple inspection units, the target logic monitoring chain also includes the calling order of the multiple inspection units.

[0077] The aforementioned check unit can be any function that can be set in the DDS function's runtime program and can be called when the program runs. Specifically, the check unit can be a check point (CP), and the CP can be inserted into any function in the DDS function's runtime program.

[0078] The aforementioned target invocation message may be generated when the first checking unit is invoked, and the target invocation message includes first information. This first information may be any information capable of indicating the first checking unit corresponding to the target invocation message.

[0079] Specifically, the first information can be the identity (ID) of the first checking unit. For example, if the first checking unit is the stub function, the first information can be the function name (NAME) and timestamp of the stub function. Of course, the first information can also be other preset strings.

[0080] It should be noted that the above-mentioned vehicles may be equipped with only the aforementioned target logic monitoring chain, and each monitoring unit in the target logic monitoring chain is located in the same DDS function's running program, and the target logic monitoring chain is only used to monitor the operation of the DDS.

[0081] When the DDS function in the vehicle is running, the vehicle can obtain the target call message generated when the first check unit in the aforementioned target logic monitoring chain is invoked.

[0082] For example, such as Figure 2 As shown, a health management service module can be installed in the vehicle. This module monitors whether the DDS function corresponding to DDS thread A in the aforementioned communication middleware is operating normally. The configured logical monitoring chain CLSC B (i.e., the target logical monitoring chain) includes multiple CPs, such as CP1, CP2, ..., all of which are located within the running program of the DDS function corresponding to DDS thread A. When the DDS function is running, DDS thread A can sequentially call CP1, CP2, ..., if the running program of the DDS function corresponding to DDS thread A reaches CP... i When (i is a positive integer), DDS thread A calls this CP. i And provide feedback on CP to the health management service module. i The target invocation message when invoked may include CP. i The function name and timestamp (i.e., the first information).

[0083] Step S120: Obtain the configuration file associated with the target DDS function. The configuration file contains the calling rule information of each inspection unit in the target logic monitoring chain.

[0084] In this embodiment of the application, the configuration file associated with the above-mentioned DDS function may be pre-stored in the vehicle, and the configuration file associated with the DDS function is called when the DDS function is running.

[0085] For example, if the vehicle is equipped with the aforementioned health management service module, the health management service module stores a configuration file associated with the DDS function corresponding to the aforementioned DDS thread A, and when the health management service module detects that the DDS function corresponding to the aforementioned DDS thread A is running, it calls the configuration file associated with the aforementioned DDS function corresponding to the aforementioned DDS thread A.

[0086] The configuration file may contain the calling rule information for each inspection unit in the target logic monitoring chain, and the calling rule information may be any information used to determine whether the call of its corresponding inspection unit is compliant.

[0087] For example, if the first information includes the function name of each CP and the timestamp of the call, then the calling rule information may include the function name of the corresponding CP and the preset calling timestamp range of that CP.

[0088] It should be noted that step S110 can be executed after step S110, before step S110, or even simultaneously with step S110. Figure 1 Only the case where step S120 is executed after step S110 is shown; other cases are not shown, but are not limited here.

[0089] Step S130: Determine the execution result corresponding to the first checking unit based on the configuration file and the first information in the target call message, wherein the execution result is used to indicate whether the call of the first checking unit conforms to the call rule information.

[0090] In this embodiment of the application, after obtaining the target call message and the configuration file, the vehicle can determine whether the call of the first inspection unit conforms to the call rule information based on the configuration file and the first information, and obtain the execution result corresponding to the first inspection unit.

[0091] For example, if the first information includes the function name of each CP and the timestamp of its call, and the calling rule information includes the function name of the corresponding CP and the preset timestamp range of that CP, then if... Figure 2 The health management service module shown receives the CP sent by DDS thread A. i The function name and timestamp are then used by the health management service module to find the corresponding CP in the configuration file. i The function name calling rule information, and determine CP. i To determine the execution result, check if the timestamp falls within the preset timestamp range specified in the call rule information.

[0092] Step S140: Determine the running information of the target DDS based on the execution results.

[0093] In this embodiment of the application, the above-mentioned determination of the target DDS's operating information based on the execution result can be based on the execution result to determine whether the target DDS's operation meets the requirements, that is, the operating information is used to indicate whether the target DDS's operation meets the requirements.

[0094] Whether the operation of the target DDS meets the requirements can be determined by whether the operation time of the target DDS meets the requirements; or by whether the target DDS is operating normally.

[0095] Determining whether the target DDS is operating normally can be done by determining that the target DDS is operating normally if the execution result indicates that the call of the first checking unit conforms to the calling rule information; or by determining that the target DDS is not operating normally if the execution result indicates that the call of the first checking unit does not conform to the calling rule information.

[0096] For example, if the above CP i If the timestamp falls within the preset timestamp range in the call rule information, then the aforementioned health management service module can determine that the DDS function corresponding to the aforementioned DDS thread A is operating normally; if the aforementioned CP i If the timestamp is not within the preset timestamp range in the call rule information, then the above health management service module can determine that the DDS function corresponding to the above DDS thread A is not operating normally.

[0097] In this embodiment, by configuring a target logic monitoring chain including at least one inspection unit and a configuration file, when the DDS function is running, the vehicle can determine the execution result of the call to the first inspection unit, which indicates whether the call conforms to the call rule information, based on the configuration file and the target call message when the first inspection unit is called. The vehicle can also determine the DDS operation information based on the execution result, thereby enabling real-time monitoring of the DDS function's operation. This allows for timely detection of any abnormalities in the DDS function, improving vehicle driving safety. Furthermore, the target logic monitoring chain allows for setting multiple inspection units at any location within the DDS function's running program, making the setting of inspection units more flexible. Moreover, by running the DDS function's running program once, it is possible to detect whether multiple functions required for monitoring by the running program are functioning correctly, resulting in a smaller amount of data during the DDS function monitoring process.

[0098] In some implementations, the configuration file specifies the calling order of each check unit in the target logic monitoring chain; the first check unit is the Nth check unit called during the operation of the target DDS function, where N is a positive integer.

[0099] The above determination of the execution result corresponding to the first inspection unit based on the configuration file and the target call message may include:

[0100] The second check unit corresponding to the Nth position in the call order of the configuration file is compared with the Nth check unit indicated by the first information to obtain the execution result corresponding to the first check unit, where:

[0101] If the preset conditions are met between the second checking unit and the Nth checking unit, the execution result indicates that the call to the first checking unit conforms to the calling rule information;

[0102] If the preset conditions are not met between the second checking unit and the Nth checking unit, the execution result indicates that the call to the first checking unit does not conform to the calling rule information.

[0103] In this embodiment, by configuring the calling order of each inspection unit in the target logic monitoring chain in the configuration file, it is possible to determine whether the calling of the first inspection unit conforms to the calling rule information based on whether the order in which the first inspection unit is called is the same as its position in the calling order in the configuration file. This makes determining whether the calling of the first inspection unit conforms to the calling rule information more accurate and simple, which not only improves the accuracy of determining the DDS's running information but also improves processing efficiency.

[0104] In this embodiment of the application, the configuration file is configured with the calling order of each inspection unit in the target logic monitoring chain, and in the calling order, each inspection unit is in a preset arrangement position.

[0105] The above-mentioned comparison of the second check unit corresponding to the Nth position in the configuration file call order with the Nth check unit indicated by the first information can be achieved by the vehicle determining the check unit at the Nth position in the configuration file call order as the second check unit when the target call message of the Nth check unit is obtained, and comparing whether the second check unit and the first check unit indicated by the first information meet the preset conditions. If they meet, the call of the first check unit is determined to conform to the call rule information; otherwise, the call of the first check unit is determined to not conform to the call rule information.

[0106] The above comparison of whether the second inspection unit and the first inspection unit indicated by the first information meet the preset conditions can be a comparison of whether the second inspection unit and the first inspection unit indicated by the first information match.

[0107] The comparison of whether the second inspection unit matches the first inspection unit indicated by the first information can be configured in the configuration file as well as the indication information of the inspection units at each arrangement position. If the first information includes the indication information of the second inspection unit, then the second inspection unit is determined to match the first inspection unit; otherwise, the second inspection unit is determined not to match the first inspection unit.

[0108] For example, such as Figure 2 The health management service module shown receives the CP sent by DDS thread A. i If the function name and timestamp are specified, the health management service module can find the check unit CP, which is the i-th position in the call sequence, in the configuration file. i ’ and obtain CP i ’ The function name (i.e., the instruction information), if CPi ’ function name and CP i If the function name matches, the health service management module can determine the inspection unit CP. i ’ With inspection unit CP i If a match is found, then the check unit CP is determined. i ’ With inspection unit CP i Mismatch.

[0109] In some implementations, the configuration file contains the calling rule information for each inspection unit in the M logical monitoring chains, and the target logical monitoring chain is any one of the M logical monitoring chains; the target calling message also includes second information for indicating the target logical monitoring chain, where M is an integer greater than 1.

[0110] The above determination of the execution result corresponding to the first inspection unit based on the configuration file and the first information in the target call message may include:

[0111] Based on the second information in the target invocation message, determine the target invocation rule information in the configuration file that corresponds to the target logical monitoring chain;

[0112] Based on the target invocation rule information and the first information in the target invocation message, determine the execution result corresponding to the first inspection unit.

[0113] In this embodiment, by configuring the calling rule information of M logical monitoring chains in the configuration file, and the target calling message also includes second information, the vehicle can determine the execution result based on the second information in the target calling message and the calling rule information of the target logical monitoring chain and the first information. In this way, the vehicle can monitor the operation of multiple DDS functions simultaneously through M logical monitoring chains.

[0114] The second piece of information mentioned above can be any information that can indicate the target logical monitoring chain among the M logical monitoring chains. Specifically, the second piece of information can be the identity identifier (CLSC ID) of the target logical monitoring chain.

[0115] It should be noted that the call message generated when any check unit in the above M-tuning logic monitoring chain is invoked includes first information for indicating the check unit and second information for indicating the logic monitoring chain to which the check unit belongs.

[0116] The above-mentioned determination of the target call rule information of the target logic monitoring chain in the configuration file based on the second information in the target call message can be made by determining the call rule information of the target logic monitoring chain indicated by the second information from the call rule information of M logic monitoring chains.

[0117] After the vehicle determines the aforementioned target invocation rule information, it can determine the execution result corresponding to the first inspection unit based on the target invocation rule information and the first information in the target invocation message. Since the process of determining the execution result based on the invocation rule information and the first information has already been described above, it will not be repeated here.

[0118] In some implementations, the communication middleware corresponding to the target DDS function has N DDS threads, and the N DDS threads run the running programs of N DDS functions, where N is an integer greater than 1; each of the M logical monitoring chains corresponds to the running program of at least one DDS function, and the checking unit in each logical monitoring chain is set in the running program of the at least one DDS function corresponding to it, and the running programs of the at least one DDS function corresponding to different logical monitoring chains are different.

[0119] In this embodiment, the inspection unit of each logical monitoring chain can be set in the running program of at least one DDS function, thereby enabling the operation of at least one DDS function to be monitored through a logical monitoring chain, making the monitoring range of the logical monitoring chain wider.

[0120] Each of the above M logical monitoring chains corresponds to at least one DDS function's running program. This means that the checking unit in each logical monitoring chain is set in only one DDS function's running program, and the checking units of different logical monitoring chains are located in different DDS function's running programs. In other words, the above communication middleware has only M DDS threads, and the M DDS functions running on these M DDS threads correspond one-to-one with the above M logical monitoring chains.

[0121] Each of the M logic monitoring chains mentioned above corresponds to the running program of at least one DDS function. Alternatively, at least some of the M logic monitoring chains may correspond to the running programs of multiple DDS functions. In this case, N is an integer greater than M.

[0122] For example, such as Figure 3 As shown, the communication middleware has four DDS threads, including DDS thread 1, DDS thread 2, DDS thread 1-1, and DDS thread 2-2. The vehicle is equipped with two logical monitoring chains, including logical monitoring chain CLSC1 and logical monitoring chain CLSC2. The stub functions in logical monitoring chain CLSC1 can be set in the DDS function execution programs run by DDS thread 1 and DDS thread 2, respectively. The stub functions in logical monitoring chain CLSC2 can be set in the DDS function execution programs run by DDS thread 1-1 and DDS thread 2-2, respectively. The health management service is configured with call order 1 corresponding to CLSC1 and call order 2 corresponding to CLSC2.

[0123] During the operation of each DDS function, each stub function in the logical monitoring chain CLSC1 and logical monitoring chain CLSC2 can be called in the order of its position in the logical monitoring chain. When a stub function is called, a call information is sent to the health management service. If the call order of any stub function does not conform to the call order in the health management service, it is determined that the DDS function containing that stub function is not operating normally; otherwise, it is operating normally.

[0124] In a specific example, if any stub function from CP-T1-1 to CP-T1-n in the logical monitoring chain CLSC1 is called in a manner that does not conform to the calling order 1, then the DDS function run by DDS thread 1 is determined to be malfunctioning; if any stub function from CP-T2-1 and CP-T2-2 in the logical monitoring chain CLSC1 is called in a manner that does not conform to the calling order 1, then the DDS function run by DDS thread 2 is determined to be malfunctioning, and so on.

[0125] In some implementations, the target logic monitoring chain corresponds to the running programs of multiple DDS functions, and the running programs of multiple DDS functions have different source codes, thereby enabling the monitoring of whether DDS functions with different source codes are functioning normally through the same logic monitoring chain.

[0126] For example, such as Figure 3 As shown, the programs running the DDS functions of DDS thread 1 and DDS thread 2 can have the same source code, and the programs running the DDS functions of DDS thread 1-1 and DDS thread 2-2 can have the same source code.

[0127] Of course, in the case where the above target logic monitoring chain corresponds to the running programs of multiple DDS functions, it is also possible that the running programs of at least some of the above multiple DDS functions have different source code, which is not limited here.

[0128] It should be noted that the check units in the running program of the same DDS function in the above-mentioned logical monitoring chains may or may not have a calling relationship with the function (e.g., the function of the instrumentation function) in the running program, and this is not limited here.

[0129] In addition, each inspection unit in the above-mentioned logical monitoring chain can be set at any position in its running program, and the positions set in the running programs of multiple DDS functions corresponding to the logical monitoring chain can have intersections or not, which is not limited here.

[0130] In some embodiments, the above method further includes:

[0131] When the first check unit in the target logic monitoring chain is invoked, second information associated with the target logic monitoring chain and first information of the first check unit are generated, and a target invocation message for the first check unit is formed based on the second information and the first information of the first check unit; or,

[0132] When the Kth check unit in the target logic monitoring chain is called, the first information of the Kth check unit is generated, and the target call message of the Kth check unit is formed based on the second information and the first information of the Kth check unit. The second information is the information generated when the first check unit in the target logic monitoring chain is called.

[0133] In this embodiment, the second information of the logical monitoring chain only needs to be generated when the first check unit in each logical monitoring chain is called. When subsequent check units in the logical monitoring chain are called, the second information generated when the first check unit is called can be used directly, thereby reducing the waste of computing resources.

[0134] For example, such as Figure 3 As shown, when the stub function CP-T1-1 in the logical monitoring chain CLSC1 is called, the DDS thread 1 of the intermediate communication device can generate the ID of the logical monitoring chain CLSC1 (i.e., CLSC1) and send the ID and the NAME of the stub function CP-T1-1 (i.e., CP-T1-1) as a call message to the health management service module; while when any stub function from CP-T1-2 to CP-T2-2 in the logical monitoring chain CLSC1 is called, the DDS thread where the stub function is located only generates the NAME of the stub function and sends the NAME of the stub function and the ID of the logical monitoring chain CLSC1 as a call message to the health management service module, and so on.

[0135] In some implementations, the target call messages generated when each check unit in the target logic monitoring chain is invoked are cached in thread-local storage associated with the target logic monitoring chain.

[0136] The above methods may also include:

[0137] If the first check unit is determined to be the last check unit in the target logic monitoring chain, clear the cached call messages in the thread-local storage associated with the target logic monitoring chain.

[0138] In this embodiment, after calling the last check unit in the target logic monitoring chain, the call message cached in the thread local storage associated with the target logic monitoring chain can be released in a timely manner, thereby realizing the timely release of the cache in the thread local storage associated with the target logic monitoring chain.

[0139] For example, such as Figure 3 As shown, when the vehicle is equipped with the above-mentioned logical monitoring chain CLSC1 and logical monitoring chain CLSC2, the above-mentioned health management service module is also configured with thread local storage 1 and thread local storage 2. Thread local storage 1 is used to store the call messages when each stub function in logical monitoring chain CLSC1 is called, and thread local storage 2 is used to store the call messages when each stub function in logical monitoring chain CLSC2 is called.

[0140] If the health management service module detects that the stub function indicated by NAME in the received call message is the stub function CP-T2-2 in the logical monitoring chain CLSC1, then the health management service module will clear the call message cached in thread local storage 1; if the health management service module detects that the stub function indicated by NAME in the received call message is the stub function CP-T2-2-2 in the logical monitoring chain CLSC2, then the health management service module will clear the call message cached in thread local storage 2.

[0141] Exemplary device

[0142] Figure 4 This is a block diagram illustrating a monitoring device with DDS functionality according to an exemplary embodiment. (Refer to...) Figure 4 The device 400 includes a call message acquisition module 410, a configuration file acquisition module 420, an execution result determination module 430, and a monitoring module 440.

[0143] The call message acquisition module 410 can be used to acquire the target call message generated when the first check unit in the target logic monitoring chain is called during the runtime of the target DDS function. The target logic monitoring chain includes at least one check unit, which is set in the runtime program of the target DDS function. The first check unit is any one of the at least one check unit. The target call message includes first information for indicating the first check unit.

[0144] The aforementioned target DDS function can be any DDS function implemented by a publish-subscribe communication middleware set up in the vehicle.

[0145] The aforementioned check unit can be any function that can be set in the DDS function's runtime program and can be called when the program runs. Specifically, the check unit can be a check point (CP), and the CP can be inserted into any function in the DDS function's runtime program.

[0146] The aforementioned target invocation message may be generated when the first checking unit is invoked, and the target invocation message includes first information. This first information may be any information that can indicate the first checking unit corresponding to the target invocation message, such as the identity identifier of the first checking unit.

[0147] The configuration file acquisition module 420 can be used to acquire the configuration file associated with the target DDS function. The configuration file contains the calling rule information of each inspection unit in the target logical monitoring chain.

[0148] The configuration file associated with the DDS function can be pre-stored in the device 400. When the DDS function is running, the configuration file acquisition module 420 calls the configuration file associated with the DDS function.

[0149] The execution result determination module 430 can be used to determine the execution result corresponding to the first checking unit based on the configuration file and the first information in the target call message. The execution result is used to indicate whether the call of the first checking unit conforms to the call rule information.

[0150] After obtaining the target call message and the configuration file, the execution result determination module 430 can determine whether the call of the first checking unit conforms to the call rule information based on the configuration file and the first information, and obtain the execution result corresponding to the first checking unit.

[0151] The monitoring module 440 can be used to determine the running information of the target DDS based on the execution results.

[0152] The above-mentioned determination of the target DDS's running information based on the execution results can be based on the execution results to determine whether the target DDS's running meets the requirements. That is, the running information is used to indicate whether the target DDS's running meets the requirements, such as whether the running time of the target DDS meets the requirements, or whether the target DDS is running normally.

[0153] In some implementations, the configuration file specifies the calling order of each check unit in the target logic monitoring chain; the first check unit is the Nth check unit called during the operation of the target DDS function, where N is a positive integer.

[0154] The above-mentioned execution result determination module 430 can be used specifically for:

[0155] The second check unit corresponding to the Nth position in the call order of the configuration file is compared with the Nth check unit indicated by the first information to obtain the execution result corresponding to the first check unit, where:

[0156] If the preset conditions are met between the second checking unit and the Nth checking unit, the execution result is an indication that the call to the first checking unit conforms to the calling rule information;

[0157] If the preset conditions are not met between the second checking unit and the Nth checking unit, the execution result is an indication that the call to the first checking unit does not conform to the calling rule information.

[0158] The configuration file specifies the calling order of each inspection unit in the target logic monitoring chain, and each inspection unit is in a preset arrangement position within this calling order.

[0159] The above-mentioned comparison of the second check unit corresponding to the Nth position in the call order of the configuration file with the Nth check unit indicated by the first information can be performed by the execution result determination module 430. When the target call message of the Nth check unit is obtained, the vehicle determines the check unit at the Nth position in the call order of the configuration file as the second check unit, and compares whether the second check unit and the first check unit indicated by the first information meet the preset conditions. If they meet the conditions, the call of the first check unit is determined to conform to the call rule information; otherwise, the call of the first check unit is determined to not conform to the call rule information.

[0160] In some implementations, the configuration file contains the calling rule information for each inspection unit in the M logical monitoring chains, and the target logical monitoring chain is any one of the M logical monitoring chains; the target calling message also includes second information for indicating the target logical monitoring chain, where M is an integer greater than 1.

[0161] The above execution result determination module 430 may include:

[0162] The call rule information determination unit is used to determine the target call rule information corresponding to the target logical monitoring chain in the configuration file based on the second information in the target call message.

[0163] The execution result determination unit is used to determine the execution result corresponding to the first inspection unit based on the target invocation rule information and the first information in the target invocation message.

[0164] The second information mentioned above can be any information capable of indicating the target logical monitoring chain among the M logical monitoring chains. Specifically, the second information can be the identity identifier (CLSC ID) of the target logical monitoring chain.

[0165] The above-mentioned determination of the target call rule information of the target logic monitoring chain in the configuration file based on the second information in the target call message can be achieved by the execution result determination module 430 determining the call rule information of the target logic monitoring chain indicated by the second information from the call rule information of the M logic monitoring chains as the aforementioned target call rule information.

[0166] In some implementations, the communication middleware corresponding to the target DDS function has N DDS threads, and the N DDS threads run the execution programs of N DDS functions, where N is an integer greater than 1.

[0167] Each of the M logical monitoring chains corresponds to the running program of at least one DDS function. The inspection unit in each logical monitoring chain is set in the running program of at least one DDS function corresponding to it, and the running programs of at least one DDS function corresponding to different logical monitoring chains are different.

[0168] In this context, each of the M logical monitoring chains corresponds to at least one DDS function's running program. This means that the checking unit in each logical monitoring chain is set in only one DDS function's running program, and the checking units of different logical monitoring chains are located in different DDS function's running programs. In other words, the communication middleware has only M DDS threads, and the M DDS functions running on these M DDS threads correspond one-to-one with the M logical monitoring chains.

[0169] In some implementations, the target logic monitoring chain corresponds to the runtime of multiple DDS functions, and the runtime of multiple DDS functions has different source code.

[0170] It should be noted that the check units in the running program of the same DDS function in the above logical monitoring chains may or may not have a calling relationship in the function they are in.

[0171] In addition, each inspection unit in the above-mentioned logical monitoring chain can be set at any position in its running program, and the positions set in the running programs of multiple DDS functions corresponding to the logical monitoring chain can have intersections or no intersections.

[0172] In some embodiments, the device 400 further includes:

[0173] The message generation module is used for:

[0174] When the first check unit in the target logic monitoring chain is invoked, second information associated with the target logic monitoring chain and first information of the first check unit are generated, and a target invocation message for the first check unit is formed based on the second information and the first information of the first check unit; or,

[0175] When the Kth check unit in the target logic monitoring chain is called, the first information of the Kth check unit is generated, and the target call message of the Kth check unit is formed based on the second information and the first information of the Kth check unit. The second information is the information generated when the first check unit in the target logic monitoring chain is called.

[0176] In some implementations, the target call messages generated when each check unit in the target logic monitoring chain is invoked are cached in thread-local storage associated with the target logic monitoring chain.

[0177] The device may also include:

[0178] The message clearing module is used to clear the call messages cached in the thread-local storage associated with the target logical monitoring chain when the first checking unit is determined to be the last checking unit in the target logical monitoring chain.

[0179] The monitoring device for DDS function provided in this application embodiment can achieve... Figure 1 The various processes implemented in the method embodiments shown achieve the same technical effects, and will not be described again here to avoid repetition.

[0180] Exemplary vehicle

[0181] Figure 5 This is a block diagram illustrating a vehicle 500 according to an exemplary embodiment. The vehicle 500 may be a gasoline vehicle, a hybrid vehicle, an electric vehicle, a fuel cell vehicle, or other types of vehicles.

[0182] Reference Figure 5 The vehicle 500 may include multiple subsystems, such as a drive system 510, a control system 520, a sensing system 530, a communication system 540, an information display system 550, and a computing processing system 560. The vehicle 500 may also include more or fewer subsystems, and each subsystem may include multiple components, which will not be described in detail here.

[0183] The drive system 510 includes components that provide power to the vehicle 500. These include, for example, an engine, an energy source, and a transmission.

[0184] The control system 520 includes components that provide control for the vehicle 500. These include, for example, vehicle control, cockpit equipment control, and driver assistance control.

[0185] The perception system 530 includes components that provide the vehicle 500 with perception of its surroundings. Examples include a vehicle positioning system, laser sensors, voice sensors, ultrasonic sensors, and camera equipment.

[0186] The communication system 540 includes components that provide communication connectivity for the vehicle 500. These may include, for example, mobile communication networks (e.g., 3G, 4G, 5G networks), WiFi, Bluetooth, and vehicle-to-everything (V2X) connectivity.

[0187] The information display system 550 includes components that provide various information displays for the vehicle 500. These include, for example, vehicle information displays, navigation information displays, and entertainment information displays.

[0188] The computing processing system 560 includes components that provide data computing and processing capabilities for the vehicle 500. The computing processing system 560 may include at least one processor 561 and a memory 562. The processor 561 can execute instructions stored in the memory 562.

[0189] Processor 561 can be any conventional processor, such as a commercially available CPU. Processors may also include graphics processing units (GPUs), field-programmable gate arrays (FPGAs), systems-on-chips (SoCs), application-specific integrated circuits (ASICs), or combinations thereof.

[0190] The memory 562 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0191] In this embodiment of the disclosure, a set of instructions is stored in the memory 562, and the processor 561 can execute the set of instructions to implement all or part of the steps of the monitoring method for the data distribution service function described in any of the exemplary embodiments above.

[0192] Exemplary electronic devices

[0193] Figure 6 This is a block diagram illustrating an electronic device 600 according to an exemplary embodiment. The electronic device 600 may be a vehicle controller, an in-vehicle terminal, an in-vehicle computer, or other types of electronic devices.

[0194] Reference Figure 6The electronic device 600 may include at least one processor 610 and a memory 620. The processor 610 can execute instructions stored in the memory 620. The processor 610 is communicatively connected to the memory 620 via a data bus. In addition to the memory 620, the processor 610 can also be communicatively connected to an input device 630, an output device 640, and a communication device 650 via the data bus.

[0195] Processor 610 can be any conventional processor, such as a commercially available CPU. The processor may also include, for example, a Graphics Processing Unit (GPU), a Field Programmable Gate Array (FPGA), a System on Chip (SOC), an Application Specific Integrated Circuit (ASIC), or a combination thereof.

[0196] The memory 620 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0197] In this embodiment of the present disclosure, the memory 620 stores executable instructions, and the processor 610 can read the executable instructions from the memory 620 and execute the instructions to implement all or part of the steps of the monitoring method for the data distribution service function described in any of the exemplary embodiments above.

[0198] Exemplary computer-readable storage media

[0199] In addition to the methods and apparatus described above, exemplary embodiments of this disclosure may also be a computer program product or a computer-readable storage medium storing the computer program product. The computer product includes computer program instructions that can be executed by a processor to perform all or part of the steps described in any of the methods in the exemplary embodiments described above.

[0200] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages, and scripting languages ​​(e.g., Python). The program code can be executed entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0201] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: static random access memory (SRAM) having one or more electrically connected wires, electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk, or any suitable combination thereof.

[0202] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of this disclosure. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0203] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for monitoring a data distribution service function, characterized in that, include: When the target data distribution service function is running, a target invocation message generated when the first inspection unit in the target logic monitoring chain is invoked is obtained. The target logic monitoring chain includes at least one inspection unit, which is set in the runtime of the target data distribution service function. The inspection unit is a stub function, which is inserted into any function in the runtime of the target data distribution service function. The inspection unit is invoked when the runtime of the target data distribution service function reaches the location of the inspection unit. The first inspection unit is any one of the at least one inspection unit. The target invocation message includes first information for indicating the first inspection unit. Obtain the configuration file associated with the target data distribution service function, wherein the configuration file contains the calling rule information of each of the inspection units in the target logical monitoring chain; Based on the configuration file and the first information in the target call message, the execution result corresponding to the first checking unit is determined, wherein the execution result is used to indicate whether the call of the first checking unit conforms to the call rule information; Based on the execution results, determine the operational information of the target data distribution service function.

2. The method according to claim 1, characterized in that, The configuration file specifies the calling order of each of the inspection units in the target logical monitoring chain; the first inspection unit is the Nth inspection unit called during the operation of the target data distribution service function, where N is a positive integer; The step of determining the execution result corresponding to the first inspection unit based on the configuration file and the first information in the target call message includes: The second check unit corresponding to the Nth position in the call order of the configuration file is compared with the Nth check unit indicated by the first information to obtain the execution result corresponding to the first check unit, wherein: If a preset condition is met between the second checking unit and the Nth checking unit, the execution result indicates that the call to the first checking unit conforms to the calling rule information; If the preset conditions are not met between the second checking unit and the Nth checking unit, the execution result indicates that the call to the first checking unit does not conform to the calling rule information.

3. The method according to claim 1, characterized in that, The configuration file contains the calling rule information for each inspection unit in the M logical monitoring chains, and the target logical monitoring chain is any one of the M logical monitoring chains; the target calling message also includes second information for indicating the target logical monitoring chain, where M is an integer greater than 1; The step of determining the execution result corresponding to the first inspection unit based on the configuration file and the first information in the target call message includes: Based on the second information in the target invocation message, determine the target invocation rule information in the configuration file corresponding to the target logical monitoring chain; The execution result corresponding to the first inspection unit is determined based on the target invocation rule information and the first information in the target invocation message.

4. The method according to claim 3, characterized in that, The communication middleware corresponding to the target data distribution service function has N data distribution service threads, and the N data distribution service threads run the running programs of N data distribution service functions, where N is an integer greater than or equal to M. Each of the M logical monitoring chains corresponds to the running program of at least one data distribution service function. The inspection unit in each logical monitoring chain is set in the running program of the at least one data distribution service function corresponding to it, and the running programs of the at least one data distribution service function corresponding to different logical monitoring chains are different.

5. The method according to claim 4, characterized in that, The target logic monitoring chain corresponds to the running programs of multiple data distribution service functions, and the running programs of the multiple data distribution service functions have different source codes.

6. The method according to claim 3, characterized in that, Also includes: When the first inspection unit in the target logic monitoring chain is invoked, second information associated with the target logic monitoring chain and first information of the first inspection unit are generated, and a target invocation message of the first inspection unit is formed based on the second information and the first information of the first inspection unit. or, When the Kth check unit in the target logic monitoring chain is invoked, first information of the Kth check unit is generated, and a target invocation message of the Kth check unit is formed based on second information and the first information of the Kth check unit. The second information is information generated when the first check unit in the target logic monitoring chain is invoked.

7. The method according to claim 1, characterized in that, The target call messages generated when each of the inspection units in the target logic monitoring chain is invoked are cached in the thread-local storage associated with the target logic monitoring chain; The method further includes: If the first checking unit is determined to be the last checking unit in the target logic monitoring chain, the call messages cached in the thread local storage associated with the target logic monitoring chain are cleared.

8. A monitoring device for a data distribution service function, characterized in that, include: The message acquisition module is used to acquire a target invocation message generated when the first inspection unit in the target logic monitoring chain is invoked during the runtime of the target data distribution service function. The target logic monitoring chain includes at least one inspection unit, which is a stub function. The stub function is inserted into any function in the runtime of the target data distribution service function. The inspection unit is invoked when the runtime of the target data distribution service function reaches the location of the inspection unit. The at least one inspection unit is set in the runtime of the target data distribution service function. The first inspection unit is any one of the at least one inspection unit. The target invocation message includes first information for indicating the first inspection unit. The configuration file acquisition module is used to acquire the configuration file associated with the target data distribution service function. The configuration file contains the calling rule information of each inspection unit in the target logical monitoring chain. The execution result determination module is used to determine the execution result corresponding to the first checking unit based on the configuration file and the first information in the target call message, wherein the execution result is used to indicate whether the call of the first checking unit conforms to the call rule information; The monitoring module is used to determine the operation information of the target data distribution service function based on the execution result.

9. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the monitoring method for the data distribution service function as described in any one of claims 1-7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the program instructions are executed by the processor, they implement the steps of the monitoring method for the data distribution service function as described in any one of claims 1-7.

Images