Service call chain monitoring analysis method and device, vehicle, equipment and medium

Abstract

The invention relates to a service calling chain monitoring analysis method and device, a vehicle, equipment and a medium. Lightweight monitoring of a service calling chain can be realized. The method comprises the following steps: configuring a calling field in a transmission message protocol of each service node; during a service calling period, assigning a calling field according to actual calling information to obtain metadata to be added; on the basis of a preset metadata transmission mode between the nodes, adding and burying point conversion transmission is carried out on the metadata to be added according to the calling path until the metadata arrives at a tail node, and a calling link is completed; and uploading the target call transmission message received by the tail node of the one or more call links to the server, so that the server analyzes the call chain monitoring index according to the target call transmission message. The calling link covers at least two metadata transmission modes; when it is determined that the same node is called and the metadata transmission mode corresponding to calling is different according to the actual calling information, the conversion of the metadata transmission mode is triggered, and the calling path continues to conduct transmission.

Description

Technical Field

[0001] The present disclosure relates to the technical field of vehicle and service call monitoring, and in particular to a method, device, vehicle, equipment and medium for monitoring and analyzing a service call chain. Background Art

[0002] In related technologies, with the popularity of microservice architecture, the service call chain may span multiple services and servers. For example, in a service-oriented architecture (SOA), a service is a self-contained, modular business function unit that can be called by different applications or business processes. As the concept of software-defined cars is gradually becoming a reality, the scale, complexity, and integration of automotive software are growing exponentially, and this trend will continue in the future. Therefore, the complexity of the call relationship of processes or data flow in the vehicle system has also increased significantly. For the vehicle system, call chain monitoring can analyze abnormal nodes, delays, etc., which helps to improve the operating performance of the vehicle software system.

[0003] In the process of realizing the concept of the present disclosure, it was found that the following technical problems exist in the related technology: since computing resources in the vehicle system need to be allocated preferentially to tasks related to safe driving, the corresponding resources for call chain monitoring are limited. Currently, the tracking or analysis of the service calls of the vehicle system is mostly based on logs. The logs are records generated by each service node according to its own operating status. Since the log data is scattered, it is generally necessary to capture the logs of each service node and then manually analyze the associations and call paths between the service nodes, or experienced personnel write corresponding integrated analysis algorithms for analysis. When the call relationship is complex and the data volume is large, the analysis efficiency is low and it is easy to cause omissions in the link links, and it also consumes a lot of computing resources or labor costs. Summary of the invention

[0004] In order to overcome the problems existing in the related art, the present disclosure provides a method, apparatus, vehicle, equipment and medium for monitoring and analyzing a service call chain.

[0005] According to the first aspect of the embodiment of the present disclosure, a method for monitoring and analyzing a service call chain is provided. The above method includes: configuring a call field in the transmission message protocol of each service node; during a service call, assigning a value to the call field according to the actual call information to obtain metadata to be appended; and based on the preset metadata transmission method between nodes, appending and converting the metadata to be appended according to the call path until the call link is completed at the tail node; the above call link covers at least two metadata transmission methods; wherein, when it is determined according to the above actual call information that the same node is called and the metadata transmission method corresponding to the call is different, the conversion of the metadata transmission method is triggered so that the call path continues to be transmitted; the target call transmission message received by the tail node of one or more call links is uploaded to the server, so that the above server analyzes the call chain monitoring indicators according to the target metadata in the above target call transmission message.

[0006] In some embodiments, when the first metadata transmission mode corresponding to the intermediate node as the called node is different from the second metadata transmission mode corresponding to the intermediate node as the calling node, the intermediate node obtains the prior metadata corresponding to the prior calling path by parsing the first call transmission message corresponding to the first metadata transmission mode; based on the second metadata transmission mode, the metadata to be appended of the intermediate node is appended to the prior metadata and the buried point conversion processing is performed to obtain the second call transmission message of the intermediate node and transmit it to the corresponding called node.

[0007] In some embodiments, the metadata to be appended is appended and converted and transmitted according to the call path based on the preset metadata transmission method between nodes, including: for the first node in the call link, based on the preset metadata transmission method between the first node and the called node, the metadata to be appended of the first node is embedded in the call transmission message under the corresponding metadata transmission method and transmitted to the called node of the first node. For each intermediate node in the call link, the first call transmission message from the calling node is received and parsed to obtain the previous metadata corresponding to the previous call path; the metadata to be appended of the current intermediate node is appended to the previous metadata to obtain the current link metadata; the metadata of the current link is directly embedded or converted in the embedding format according to the preset metadata transmission method between the called node and the called node, to obtain the second call transmission message of the current intermediate node and transmit it to the corresponding called node. Among them, when the first metadata transmission mode corresponding to the current intermediate node as the called node is the same as the second metadata transmission mode corresponding to the current intermediate node as the calling node, direct point embedding processing is performed on the above-mentioned current link metadata; when the first metadata transmission mode corresponding to the current intermediate node as the called node is different from the second metadata transmission mode corresponding to the current intermediate node as the calling node, point embedding format conversion processing is performed on the above-mentioned current link metadata.

[0008] In some embodiments, during the service call, the call field is assigned a value according to the actual call information to obtain the metadata to be appended; including: during the service call in the vehicle MCU or the vehicle cross-MCU service call, the call field of the current node is assigned a value according to the actual call information of each calling node to obtain the metadata to be appended. Among them, the above-mentioned call field includes: the parent node identifier of the call, the one or more child node identifiers called, the monitored call link identifier and the transmission message protocol identifier. The above-mentioned assignment of the call field of the current node according to the actual call information of each calling node includes: assigning the first node identifier corresponding to the current node as the above-mentioned parent node identifier; assigning the second node identifier of one or more nodes to be called by the current node as the above-mentioned child node identifier; assigning the link identifier generated during the service call as the above-mentioned call link identifier; assigning the message identifier of the call transmission message constructed between the current node and the one or more nodes to be called based on the corresponding metadata transmission method as the above-mentioned transmission message protocol identifier. The above call link covers at least two of the following metadata delivery methods: service-oriented communication middleware SOME / IP, data distribution service DDS, communication middleware TOX, variable transmission method, and MQTT, a transmission protocol based on the message publish-subscribe mode. The call field configured in the above transmission message protocol is stored in the message body content cache area in the transmission message protocol, and the metadata obtained after the corresponding assignment of the above call field is stored by occupying the preset redundant storage space of the above message body content cache area.

[0009] In some embodiments, uploading the target call transmission message received by the tail node of one or more call links to the server includes: determining whether the reporting trigger condition is met based on the exit function; the reporting trigger condition includes at least one of the following: the total delay corresponding to one or more call links exceeds the pre-configured time threshold; or, whether the total number of messages corresponding to one or more call links exceeds the pre-configured number threshold; in response to meeting the reporting trigger condition, triggering the execution of the reporting task, the reporting task is used to batch upload the target call transmission messages received by the tail node of one or more call links to the server. Among them, the exit function is used to call at the end position of the service operation corresponding to the tail node of one or more call links; the total delay is obtained by accumulating the delay corresponding to one or more call links, and the delay of each call link is obtained by calculating the difference between the timestamps recorded by the start function and the exit function, and the start function is used to call at the start position of the service operation corresponding to the head node of one or more call links.

[0010] In some embodiments, the tail node is the end node corresponding to the real data flow during the service call, and the end node is one of the following two types: a first type of end node corresponding to a complete data flow transfer during the service call; a second type of end node corresponding to an exception during the service call that results in a successful transfer of part of the data flow but a remaining part that has not yet been transferred. The tail node is determined in the following manner: during the service call, for each calling node, whether the current calling node is a tail node is determined based on the transfer status of whether the data flow between the current calling node and the called one or more service nodes is successfully transferred; if the data flow between the current calling node and the called one or more service nodes is not successfully transferred, the current calling node is marked as a tail node.

[0011] According to the second aspect of the embodiment of the present disclosure, a device for monitoring and analyzing a service call chain is provided. The above-mentioned device includes: a configuration module, a metadata appending and transmission module, and a reporting module. The above-mentioned configuration module is used to configure the call field in the transmission message protocol of each service node. The above-mentioned metadata appending and transmission module is used to assign values ​​to the call field according to the actual call information during the service call to obtain the metadata to be appended; and based on the preset metadata transmission method between the nodes, the metadata to be appended is appended and converted and transmitted according to the call path until it reaches the tail node to complete the call link; the above-mentioned call link covers at least two metadata transmission methods; wherein, when it is determined according to the above-mentioned actual call information that the same node is called and the metadata transmission method corresponding to the call is different, the conversion of the metadata transmission method is triggered so that the call path continues to be transmitted. The above-mentioned reporting module is used to upload the target call transmission message received by the tail node of one or more call links to the server, so that the above-mentioned server analyzes the call chain monitoring indicators according to the target metadata in the above-mentioned target call transmission message.

[0012] According to a third aspect of an embodiment of the present disclosure, a vehicle is provided, storing a set of instruction sets, which are executed by the vehicle to implement the method for monitoring and analyzing the service call chain provided by the first aspect of the present disclosure.

[0013] According to the fourth aspect of an embodiment of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing executable instructions of the above-mentioned processor; the above-mentioned processor, for reading the above-mentioned executable instructions from the above-mentioned memory, and executing the above-mentioned executable instructions to implement the service call chain monitoring and analysis method provided by the first aspect of the present disclosure.

[0014] According to a fifth aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, on which computer program instructions are stored. When the program instructions are executed by a processor, the steps of the method for monitoring and analyzing the service call chain provided in the first aspect of the present disclosure are implemented.

[0015] The technical solution provided by the embodiments of the present disclosure may have the following beneficial effects:

[0016] By configuring the call field in the transmission message protocol of each service node, during the service call, the call field is assigned a value according to the actual call information to obtain the metadata to be appended; as the service call occurs, the current service node performs an additional point-of-sale conversion and transmission on its own metadata to be appended in the previously occurring call path, that is, the metadata to be appended by the current service node itself is added in an additional manner to the appended metadata corresponding to one or more service nodes that have already had a call relationship in the call path, and during the transmission process, the metadata is converted and transmitted based on the preset metadata transmission method between nodes until it reaches the tail node to complete the call link. The tail node only needs to upload the target call transmission message to realize the analysis of the call chain monitoring indicators, effectively realizing the lightweight monitoring of the service call chain. Since the overall call link covers at least two metadata transmission modes, when the same node (for example, a node C is a link in the call path A→B→C→D, which is both a service called by service B and a service calling service D) is called and the corresponding metadata transmission modes are different (for example, the metadata transmission mode corresponding to B→C is SOME / IP, and the metadata transmission mode corresponding to C→D is JSON global variable), the metadata transmission mode is also converted when appending, so that the call path can continue to be transmitted according to the corresponding metadata transmission mode after the conversion (for example, the metadata Y to be appended of the node C itself is converted into the metadata Y to be appended). C Append to the appended metadata of the call path A→B before B {Y A , Y B}, we get {Y A , Y B , Y C}; and convert the metadata transfer mode from SOME / IP to JSON global variable mode, so that {Y A , Y B , Y C} is transmitted to node D in the form of JSON global variables); in this way, as the calling process occurs and the metadata to be appended is transmitted through appending and embedding conversion, the target call transmission message received by the tail node of the calling link carries a collection of metadata of all service nodes before the tail node, and the call chain monitoring indicators can be analyzed according to the target metadata in the target call transmission message received by the tail node. The server does not need to communicate with each service node on the calling link in real time and obtain the data of all service nodes for integration and analysis, thereby reducing the computing resources or labor costs required for the server-side integration and analysis. For a resource-constrained operating environment, during the service call, the interactive resources required for the running service nodes to frequently report their own call information to the server are saved, and the tail node only needs to upload the target call transmission message, thereby effectively realizing lightweight monitoring of the service call chain.

[0017] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0019] Figure 1 The present invention is a flowchart of a method for monitoring and analyzing a service call chain according to an exemplary embodiment.

[0020] Figure 2 The diagram is a schematic diagram showing configuration of a call field in a transmission message protocol according to an exemplary embodiment.

[0021] Figure 3A The diagram is a schematic diagram showing a calling path and metadata transfer method of a calling link according to an exemplary embodiment.

[0022] Figure 3B The diagram is a schematic diagram showing a calling path and metadata transfer method of another calling link according to an exemplary embodiment.

[0023] Figure 4 The present invention is a schematic diagram of a process of appending and converting the additional metadata according to a call path based on a preset metadata transmission method between nodes according to an exemplary embodiment, wherein (a) is the processing process of metadata appending and transmission corresponding to when the current node is service node A; (b) is the processing process of metadata appending and transmission corresponding to when the current node is service node B; (c) is the processing process of metadata appending and transmission corresponding to when the current node is service node C; (d) is the processing process of metadata appending and transmission corresponding to when the current node is service node D.

[0024] Figure 5 The present invention is a block diagram of a device for monitoring and analyzing a service call chain according to an exemplary embodiment.

[0025] Figure 6 is a block diagram of a vehicle according to an exemplary embodiment.

[0026] Figure 7 It is a block diagram of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

[0027] Exemplary embodiments will be described in detail below with reference to the accompanying drawings.

[0028] It should be pointed out that the relevant embodiments and drawings are only for describing exemplary embodiments provided by the present disclosure, rather than all embodiments of the present disclosure, and it should not be understood that the present disclosure is limited to the relevant exemplary embodiments.

[0029] It should be noted that the terms "first", "second", etc. used in the present disclosure are only used to distinguish different steps, devices or modules, etc. The related terms neither represent any specific technical meanings nor indicate the order or interdependence between them.

[0030] It should be noted that the modifications of the terms "one", "multiple", and "at least one" used in the present disclosure are illustrative rather than restrictive. Unless otherwise clearly indicated in the context, it should be understood as "one or more".

[0031] It should be noted that the term "and / or" used in this disclosure is used to describe the association relationship between associated objects, and generally indicates that there are at least three association relationships. For example, A and / or B can at least indicate the existence of three association relationships: A exists alone, A and B exist at the same time, and B exists alone.

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

[0033] It should be noted that all actions of acquiring signals, information or data in the present disclosure are carried out in compliance with the relevant data protection laws and policies of the country where the device is located and with the authorization given by the owner of the corresponding device.

[0034] Monitoring the service call chain in a resource-constrained system consumes a lot of computing resources. Taking the vehicle's onboard system as an example, since computing resources in the onboard system need to be allocated first to tasks related to safe driving, the corresponding resources for call chain monitoring are limited. At present, when tracking or analyzing the service calls of the onboard system, most of them are based on logs. Logs are records generated by each service node based on its own operating status. Since the log data is scattered, it is generally necessary to capture the logs of each service node and then manually analyze the associations and call paths between each service node, or experienced personnel write corresponding integrated analysis algorithms for analysis. In the case of complex call relationships and large data volumes, the analysis efficiency is low and it is easy to cause omissions in the link links, and it also consumes a lot of computing resources or labor costs.

[0035] In view of this, an embodiment of the present disclosure provides a method, apparatus, vehicle, equipment and medium for monitoring and analyzing a service call chain, the method comprising: configuring a call field in the transmission message protocol of each service node; during a service call, assigning a value to the call field according to actual call information to obtain metadata to be appended; and based on a preset metadata transmission method between nodes, appending and converting the metadata to be appended according to the call path until the call chain is completed at the tail node; the call chain covers at least two metadata transmission methods; wherein, when it is determined according to the actual call information that the same node is called and the metadata transmission methods corresponding to the call are different, the conversion of the metadata transmission method is triggered so that the call path continues to be transmitted; the target call transmission message received by the tail node of one or more call chains is uploaded to the server, so that the server analyzes the call chain monitoring indicators according to the target metadata in the target call transmission message.

[0036] As the calling process occurs and the metadata to be appended is transmitted through appending and embedding conversion, the target call transmission message received by the tail node of the calling link carries a collection of metadata of all service nodes before the tail node. The call chain monitoring indicators can be analyzed according to the target metadata in the target call transmission message received by the tail node. The server does not need to communicate with each service node on the calling link in real time and obtain the data of all service nodes for integration analysis, which reduces the computing resources or labor costs required for the server integration analysis. For resource-constrained operating environments, during the service call, the interactive resources required for the running service nodes to frequently report their own call information to the server are saved. The tail node only needs to upload the target call transmission message, which effectively realizes lightweight monitoring of the service call chain.

[0037] Technical terminology

[0038] Micro-controller Unit (MCU): A small computer that integrates a microprocessor, memory, and input / output (I / O) peripherals on a single chip. MCUs are widely used in embedded systems, such as automotive electronics, medical equipment, industrial control, and consumer electronics.

[0039] Vehicle-mounted MCU: The corresponding Chinese name can be expressed as: vehicle-mounted microcontroller, vehicle-mounted microcontroller unit, vehicle-mounted single-chip computer, vehicle-mounted microcontroller chip, etc.

[0040] Service call chain: A call chain refers to a series of call relationships formed by multiple services calling each other in a distributed system. Whenever a service calls another service, a call chain is formed. The call chain can show the call sequence and hierarchical relationship between services, helping developers understand and track the execution flow of the code.

[0041] Trace: A trace represents the complete execution process of a request or transaction from start to finish. For example, the process from receiving a request from a client to processing it is a trace. A trace can be seen as a tree structure that contains multiple call processes (spans). Each trace is assigned a unique link identifier, Trace ID, which remains unchanged throughout the entire call chain of a request. When you need to trace or debug the entire request process, you can retrieve all relevant information through the Trace ID.

[0042] Logical operation unit (Span) in the call chain: Span is the smallest tracking unit of distributed tracing, representing a single logical operation in the call chain, which can be a method call, a program block call, or an RPC / database access. Each Span has an operation identifier Span ID, and records the start time and end time of the operation. Span also records the call parent node identifier (Parent Span ID), that is, which upstream Span calls the current Span, indicating the parent-child relationship in the call relationship. Spans are linked through parent-child relationships to form a call chain.

[0043] Tracking: Tracking is to insert code or instructions before or after a method to obtain information such as the execution time or parameters of the method.

[0044] SOME / IP: is a scalable service-oriented communication middleware. SOME / IP is the abbreviation of "Scalable service-oriented MiddlewarE over IP", which is released by AUTOSAR (a set of standard protocols jointly established by major global automobile manufacturers, automobile parts suppliers, and automotive electronic software system companies). SOME / IP supports communication mechanisms such as Field, Event, and Method.

[0045] Data Distribution Service (DDS): It is a data-centric middleware protocol and API (application programming interface) standard released by the Object Management Group (OMG). It adopts a distributed publish / subscribe architecture, provides communication services in the form of middleware, and emphasizes data-centricity.

[0046] Communication middleware TOX: A high-performance cross-domain communication protocol (Talks-Over-X, X means everything), suitable for all network types and communication terminals. TOX is a SOME / IP-like communication middleware that implements communication mechanisms such as Field, Event, and Method.

[0047] Variable transmission method: The data carried in the variable is transmitted by calling the variable. For example, by defining a global variable or a global function, data transmission is realized when the global variable or global function is called by another class or thread. For example, a JSON (a data exchange format) global variable can be used. The JSON global variable converts a set of data in a JS object into a string for transmission.

[0048] MQTT (Message Queuing Telemetry Transport), a message publishing-subscribing model-based transmission protocol: MQTT is a lightweight, publish-subscribe model-based message transmission protocol suitable for resource-constrained devices and low-bandwidth, high-latency or unstable network environments. It is popular in IoT applications and enables efficient communication between sensors, actuators, and other devices.

[0049] Exemplary Methods

[0050] Figure 1 The present invention is a flowchart of a method for monitoring and analyzing a service call chain according to an exemplary embodiment.

[0051] Reference Figure 1 As shown, the first exemplary embodiment of the present disclosure provides a method for monitoring and analyzing a service call chain, and the method includes the following steps: S110, S120 and S130.

[0052] The above method can be applied to vehicles, drones, intelligent robots or other types of electronic devices, and can realize lightweight monitoring of service call chains for resource-constrained systems, effectively solving problems faced by monitoring service call chains in resource-constrained systems, such as low analysis efficiency and easy omission of link links, and consuming a large amount of computing resources or labor costs. It is understandable that the method provided by the embodiment of the present disclosure can also be applied to systems with sufficient resources and realize lightweight monitoring of service call chains.

[0053] In step S110, a call field is configured in the transmission message protocol of each service node.

[0054] A service node refers to a node that acts as a service provider and / or service demander. This node can correspond to one or more of a process, thread, service, function, server, client, etc. All kinds of objects that can provide services or call services can be regarded as service nodes. The same service node can have one of the following roles: service provider, called by other nodes; service demander, calling services of other nodes; both a service provider and a service demander, called by some nodes and calling services of other nodes.

[0055] Taking a vehicle as an example of the executor of the above method, the vehicle implements calls between various services based on the SOA architecture, wherein calls between multiple service nodes can occur within the vehicle-mounted MCU, and calls between service nodes can also occur between multiple vehicle-mounted MCUs, that is, service calls can occur across vehicle-mounted MCUs.

[0056] Figure 2 The diagram is a schematic diagram showing configuration of a call field in a transmission message protocol according to an exemplary embodiment.

[0057] In the embodiments of the present disclosure, corresponding transmission message protocol forms are preset between each service node, including but not limited to: service-oriented communication middleware SOME / IP, data distribution service DDS, communication middleware TOX, variable transmission method, transmission protocol MQTT based on message publish-subscribe mode, etc.

[0058] Reference Figure 2 As shown, the call field configured in the above-mentioned transmission message protocol is stored in the message body content cache area (Payload) in the transmission message protocol, and the metadata obtained after the corresponding assignment of the above-mentioned call field is stored by occupying the preset redundant storage space of the above-mentioned message body content cache area.

[0059] By configuring the call field in the transmission message protocol of each service node, the above call field serves as the key information of the call related information. Figure 2As shown, the call field may specifically include but is not limited to the following information: the calling parent node identifier (span_parent_id), one or more called child node identifiers (span_peer_id), the monitored call link identifier (trace_id) and the transmission message protocol identifier (SOA_protocol_id).

[0060] Specifically, refer to Figure 2 As shown, taking service node X and service node Y having a calling relationship as an example, the preset transmission message protocol form between service node X and service node Y is SOME / IP (other protocol forms can also be understood by reference, here as an example), and the transmission message includes a message header (Header) and a message body content cache area (Payload). When service node X wants to call service node Y, service node X sends a message SOME / IP Message corresponding to the call request to service node Y, or calls service node Y based on calling the service interface (Service), or calls service node Y based on calling the method (Method).

[0061] Reference Figure 2 As shown in the figure, the message header can store some or all of the following information: one of the message ID, the calling service ID, and the calling method ID; one of the request ID, the client ID, and the session ID; the protocol version, the interface version, the message type, and the return code, etc.

[0062] Continue to refer to Figure 2 As shown, a call field is configured in the message body content cache area (Payload) of the above-mentioned transmission message protocol, and the metadata (message MetaData) obtained after the corresponding value of the call field is stored by occupying the preset redundant storage space of the above-mentioned message body content cache area Payload. Figure 2 The data types corresponding to each call field are also illustrated, such as the 32-bit unsigned integer type uint32, the 64-bit unsigned integer type uint64, etc.

[0063] By configuring the above-mentioned call field in the transmission message protocol and embedding it into the message body content cache area Payload in the form of metadata embedding, it is convenient for each service node's own metadata to be appended to the appended metadata corresponding to the previous node as the call process occurs. At the same time, since the metadata is stored by utilizing the preset redundant storage space in the Payload, there is no need to open up additional space for storing metadata, which realizes the use of preset space in the existing framework, so that the Payload can also be used as a carrier of metadata, improving the storage space utilization rate in the message.

[0064] In step S120, during a service call, the call field is assigned a value according to the actual call information to obtain metadata to be appended; and based on the preset metadata transmission method between nodes, the metadata to be appended is appended and converted and transmitted according to the call path until it reaches the tail node to complete the call link.

[0065] The above-mentioned call link covers at least two metadata transmission methods; among them, when it is determined according to the above-mentioned actual call information that the same node is called and the metadata transmission method corresponding to the call is different, the conversion of the metadata transmission method is triggered so that the call path continues to be transmitted.

[0066] In the terminology of the present disclosure, the call link refers to the overall call path corresponding to the tail node (which can be regarded as a static concept), and the call path is a real-time path that is gradually transmitted and extended during the service call (dynamically changes as the call process occurs).

[0067] In some embodiments, during a service call, the call field is assigned a value according to the actual call information to obtain metadata to be appended; including: during a service call within the vehicle-mounted MCU or a service call across vehicle-mounted MCUs, the call field of the current node is assigned a value according to the actual call information of each calling node to obtain metadata to be appended.

[0068] The above-mentioned calling field includes: the calling parent node identifier, the identifier of one or more called child nodes, the monitored calling link identifier and the transmission message protocol identifier.

[0069] The above-mentioned assignment of the call field of the current node according to the actual call information of each calling node includes: assigning the first node identifier corresponding to the current node as the above-mentioned parent node identifier; assigning the second node identifier of one or more nodes to be called by the current node as the above-mentioned child node identifier; assigning the link identifier generated during the service call as the above-mentioned call link identifier; and assigning the message identifier of the call transmission message constructed between the current node and one or more nodes to be called based on the corresponding metadata transmission method as the above-mentioned transmission message protocol identifier.

[0070] For example, continue to refer to Figure 2 As shown, when an actual call occurs, service node X (corresponding identifier is node X) calls service node Y (corresponding identifier is node Y). Service node X can clearly identify the actual call information according to the execution logic, specifically: the object to be called is service node Y, the adopted SOA protocol is SOA_protocol_001, and the call link identifier monitored this time is initialized to trace_1; then the call fields in the message body content cache area Payload: span_parent_id, span_peer_id, trace_id and SOA_protocol_id are assigned values ​​respectively to obtain the metadata to be appended.

[0071] The following are examples of assignment results:

[0072] span_parent_id == (== indicates assignment) node X;

[0073] span_peer_id == node Y;

[0074] trace_id == trace_1;

[0075] SOA_protocol_id==SOA_protocol_001.

[0076] As an example, the preset metadata transmission method between service node X and service node Y is SOME / IP, then service node X will add metadata Y to be appended X :{span_parent_id: node X; span_peer_id: node Y; trace_id: trace_1; SOA_protocol_id: SOA_protocol_001} is transmitted to the called service node Y based on SOME / IP. Figure 2 The following is only an example of how to obtain the metadata to be appended and embed the call field in the message body content cache area in the transmission message protocol.

[0077] Next, combine Figure 3A and Figure 3B Two calling paths of the example, combined with Figure 4 This article introduces the detailed process of appending and converting the metadata according to the call path based on the preset metadata transmission method between nodes during a service call until it reaches the tail node to complete the call link.

[0078] Figure 3AThe diagram is a schematic diagram showing a calling path and metadata transfer method of a calling link according to an exemplary embodiment. Figure 3B The diagram is a schematic diagram showing a calling path and metadata transfer method of another calling link according to an exemplary embodiment. Figure 4 The present invention is a schematic diagram of a process of appending and converting the additional metadata according to a call path based on a preset metadata transmission method between nodes according to an exemplary embodiment, wherein (a) is the processing process of metadata appending and transmission corresponding to when the current node is service node A; (b) is the processing process of metadata appending and transmission corresponding to when the current node is service node B; (c) is the processing process of metadata appending and transmission corresponding to when the current node is service node C; (d) is the processing process of metadata appending and transmission corresponding to when the current node is service node D.

[0079] Refer to the following Figure 3A and Figure 3B To exemplarily describe the call paths of two call links, one is a chain call link, and the other is a call link with a branch call path.

[0080] Reference Figure 3A As shown, a call link DL11 for service calls across vehicle-mounted MCUs is illustrated. In the call link DL11, there is the following call path: service node A→(arrows represent calls, and the arrows point from the calling node to the called node, and the following is the same and will not be repeated) service node B→service node C→service node D→service node E, where service node A, service node B, and service node C are located in vehicle-mounted MCU1, and service node D and service node E are located in vehicle-mounted MCU2.

[0081] Since the call field is set in the payload of the transmission message protocol, the metadata transmission method corresponding to the metadata obtained by assigning the call field value corresponds to the preset transmission message protocol form between the service nodes with the call relationship. Figure 3A As shown, the transmission message protocol format preset between service node A and service node B is: SOME / IP, and the corresponding metadata transmission method is also: SOME / IP. The transmission message protocol format preset between service node B and service node C is: SOME / IP, and the corresponding metadata transmission method is also: SOME / IP. The transmission message protocol format preset between service node C and service node D is: JSON global variable, and the corresponding metadata transmission method is also: JSON global variable. The transmission message protocol format preset between service node D and service node E is: SOME / IP, and the corresponding metadata transmission method is also: SOME / IP.

[0082] Reference Figure 3BAs shown, another call link DL12 for service calls in an in-vehicle MCU is illustrated. In the call link DL12, there are two branched call paths DL121 and DL122, call path DL121: service node A→service node B→service node F→service node H; call path DL122: service node A→service node C→service node G→service node H. The above service nodes A, B, F, H, C, G, and H are all located in the in-vehicle MCU1.

[0083] Continue to refer to Figure 3B As shown, the transmission message protocol format preset between service node A and service node B is: SOME / IP, and the corresponding metadata transmission method is also: SOME / IP. The transmission message protocol format preset between service node B and service node F is: variable transmission method (for example, it can be JSON global variable method), and the corresponding metadata transmission method is also: variable transmission method. The transmission message protocol format preset between service node F and service node H is: variable transmission method, and the corresponding metadata transmission method is also: variable transmission method.

[0084] The default transmission message protocol format between service node A and service node C is: SOME / IP, and the corresponding metadata transmission method is also: SOME / IP. The default transmission message protocol format between service node C and service node G is: variable transmission method, and the corresponding metadata transmission method is also: variable transmission method. The default transmission message protocol format between service node G and service node H is: SOME / IP, and the corresponding metadata transmission method is also: SOME / IP.

[0085] It should be noted that the method provided in the embodiments of the present disclosure can be applied to call links corresponding to various forms of call paths. For call links of various complex types, one or more chain-like call links can be parsed according to the call relationship in the actual call information. The method for one call link in the embodiments of the present disclosure can also be applied to multiple call links; it is also applicable to call links with branches or complex forms.

[0086] In the embodiments of the present disclosure, the call link covers at least two of the following metadata delivery methods: service-oriented communication middleware SOME / IP, data distribution service DDS, communication middleware TOX, variable transmission method, and transmission protocol MQTT based on message publish-subscribe mode. Figure 3A and Figure 3BAs shown, taking SOME / IP and variable transmission methods as examples, the application scenarios of the embodiments of the present disclosure can be expanded to combinations of more metadata transmission methods, or combinations of other types of metadata transmission methods, etc.

[0087] In some embodiments, based on a preset metadata transmission method between nodes, the additional metadata is appended and converted and transmitted according to the call path, including:

[0088] For the first node in the call link, based on the preset metadata transmission method between the first node and the called node, the metadata to be appended of the first node is embedded in the call transmission message under the corresponding metadata transmission method and transmitted to the called node of the first node;

[0089] For each intermediate node in the call link, a first call transmission message from the calling node is received and parsed to obtain the previous metadata corresponding to the previous call path; the metadata to be appended of the current intermediate node is appended to the above-mentioned prior metadata to obtain the current link metadata; the above-mentioned current link metadata is directly processed or converted into a format according to the preset metadata transmission method between the called node, and the second call transmission message of the current intermediate node is obtained and transmitted to the corresponding called node.

[0090] Among them, when the first metadata transmission mode corresponding to the current intermediate node as the called node is the same as the second metadata transmission mode corresponding to the current intermediate node as the calling node, direct point embedding processing is performed on the above-mentioned current link metadata; when the first metadata transmission mode corresponding to the current intermediate node as the called node is different from the second metadata transmission mode corresponding to the current intermediate node as the calling node, point embedding format conversion processing is performed on the above-mentioned current link metadata.

[0091] For example, when the first metadata transmission mode corresponding to the intermediate node as the called node is different from the second metadata transmission mode corresponding to the intermediate node as the calling node, the intermediate node obtains the prior metadata corresponding to the prior calling path by parsing the first call transmission message corresponding to the first metadata transmission mode; based on the second metadata transmission mode, the metadata to be appended of the intermediate node is appended to the prior metadata and the buried point conversion processing is performed to obtain the second call transmission message of the intermediate node and transmit it to the corresponding called node.

[0092] Combine the following Figure 3A and Figure 4 , the process of adding and converting the additional metadata according to the calling path in the calling link DL11 is described. Figure 4 In FIG, the current service node is indicated by a dotted circle.

[0093] Reference Figure 3A and Figure 4 As shown in (a), for the current service node A in the call link DL11 (as an example of the first node), the call field is assigned according to the actual call information (service node A→service node B), and the metadata Y to be appended corresponding to the service node A is obtained. A :{span_parent_id: node A; span_peer_id: node B; trace_id: trace_101; SOA_protocol_id: SOA_protocol_001 (for example, indicating the transmission method corresponding to SOME / IP)};Based on the preset metadata transmission method SOME / IP between the service node A and the called node: service node B, the metadata Y to be added of the service node A is sent to the service node B. A The call transmission message M in the form of embedding to SOME / IP AB In the above call transmission message M AB Sent to serving node B.

[0094] As the call path is transmitted, refer to Figure 4 As shown in (b), for the current service node B (as an example of the current intermediate node) in the call link DL11, the first call transmission message based on the SOME / IP transmission corresponding to the previous call path: service node A→service node B is received, that is, M AB , and parse the previously added metadata Y A . Assign the call field value according to the actual call information (service node B → service node C) to obtain the metadata Y to be appended corresponding to service node B B :{span_parent_id: node B; span_peer_id: node C; trace_id: trace_101; SOA_protocol_id: SOA_protocol_001}. The metadata Y to be added to the service node B B Append to previous metadata Y A In the current link metadata {Y A , Y B Since the metadata transfer mode preset between the current service node B and the called service node C (as an example of the second metadata transfer mode) is still SOME / IP, which is the same as the metadata transfer mode corresponding to the current service node B as the called node (the metadata transfer mode corresponding to the service node A→service node B, i.e., the first metadata transfer mode) SOME / IP, the current link metadata {Y A , Y B} to directly embed the point, that is, the current link metadata {Y A , Y B} The second call transmission message M in the form of SOME / IP to be sent to the corresponding service node C is embedded in the service node B. BC The current service node B will call the transmission message M BC Transmit to the corresponding called node: service node C.

[0095] As the call path is transmitted, refer to Figure 4 As shown in (c), for the current service node C (as an example of the current intermediate node) in the call link DL11, the first call transmission message based on the SOME / IP transmission corresponding to the previous call path: service node B→service node C is received, that is, M BC , and parse the previously appended metadata {Y A , Y B}. Assign the call field value according to the actual call information (service node C → service node D) to obtain the metadata Y to be appended corresponding to service node C C :{span_parent_id: node C; span_peer_id: node D; trace_id: trace_101; SOA_protocol_id: SOA_protocol_002 (for example, indicating the transmission method corresponding to the JSON global variable)}. The metadata Y to be added of the service node C C Append to previous metadata {Y A , Y B}, get the current link metadata {Y A , Y B , Y C}. Since the metadata transfer method preset between the current service node C and the called service node D (as an example of the second metadata transfer method) is no longer SOME / IP, but a JSON global variable, which is different from the metadata transfer method corresponding to the current service node C as the called node (the metadata transfer method corresponding to the service node B→service node C, that is, the first metadata transfer method) SOME / IP, the current link metadata {Y A , Y B , Y C} to convert the embedding format, that is, convert the current link metadata {Y A , Y B , Y C} The second call transmission message M in the JSON global variable format corresponding to the service node C is sent to the service node D. CDThe current service node C will call the transmission message M CD Transmit to the corresponding called node: service node D.

[0096] As the call path is transmitted, refer to Figure 4 As shown in (d), for the current service node D in the call link DL11 (as an example of the current intermediate node), the first call transmission message based on JSON global variable transmission corresponding to the previous call path: service node C→service node D is received, that is, M CD , and parse the previously appended metadata {Y A , Y B , Y C}. According to the actual call information (service node D → service node E), the call field is assigned a value to obtain the metadata Y to be appended corresponding to service node D D :{span_parent_id: node D; span_peer_id: node E; trace_id: trace_101; SOA_protocol_id: SOA_protocol_001}. The metadata Y to be added of service node D D Append to previous metadata {Y A , Y B , Y C}, get the current link metadata {Y A , Y B , Y C , Y D Since the metadata transfer method preset between the current service node D and the called service node E (as an example of the second metadata transfer method) is SOME / IP, which is different from the metadata transfer method corresponding to the current service node D as the called node (the metadata transfer method corresponding to the service node C→service node D, that is, the first metadata transfer method) JSON global variable, the current link metadata {Y A , Y B , Y C , Y D} to convert the embedding format, that is, convert the current link metadata {Y A , Y B , Y C , Y D} The second call transmission message M in the form of SOME / IP to be sent to the service node E is embedded in the service node D. DE The current service node D will call the transmission message M DE Transmit to the corresponding called node: service node E.

[0097] In the above embodiment, when performing the tracking point format conversion process, the specific conversion execution subject can be set according to actual needs, and can be executed by the current service node itself, or by calling a third-party function interface.

[0098] As the service call occurs, the current service node will perform an additional point-of-sale conversion and transmission of its own metadata to be appended in the call path that has already occurred. That is, the metadata to be appended by the current service node itself is added in an additional manner to the appended metadata corresponding to one or more service nodes that have already had a call relationship in the call path, and during the transmission process, the metadata is converted and transmitted based on the preset metadata transmission method between nodes until it reaches the tail node to complete the call link. The tail node only needs to upload the target call transmission message to realize the analysis of the call chain monitoring indicators, thereby effectively realizing lightweight monitoring of the service call chain.

[0099] It can be understood that for Figure 3B The call link with branches in the example can be regarded as two call links. Other forms of complex call links can also be tracked and recorded without omission through metadata appending and point-of-entry conversion transmission and transmitted to the target metadata of the target call transmission message corresponding to the tail node. The specific process of other forms of call links can be understood by referring to the description details of metadata appending and point-of-entry conversion transmission described above.

[0100] In step S130, the target call transmission message received by the tail node of one or more call links is uploaded to the server, so that the server analyzes the call chain monitoring indicators according to the target metadata in the target call transmission message.

[0101] In the embodiment of the present disclosure, since the target metadata in the target call transmission message carries at least the appended metadata on all call paths before the tail node, it can represent the complete call information and the corresponding link, thereby enabling the analysis of the call chain monitoring index. By uploading the received target call transmission message to the server by the tail node, the operation of analyzing the call chain monitoring index is set to be executed on the server, and the on-board MCU does not need to consume or allocate more resources to analyze the call chain monitoring index, saving the analysis resource consumption on the vehicle side.

[0102] On the server side, the collector set by the server side can analyze the call chain monitoring indicators, including data filtering, data tagging, tail sampling, data modeling, etc. The server side can even store the analyzed call chain monitoring indicators and provide visual viewing and other service support. The above call chain monitoring indicators include but are not limited to: the delay of a single service, the end-to-end delay of one or more call links.

[0103] The specific server can be based on the metadata set {Y A , Y B , Y C , Y D}Get the complete call path and specific delay information. The delay information can be obtained by adding the call timestamp information to the target metadata and calculating the difference between the timestamp sent by the calling node and the timestamp received by the called node.

[0104] For example, by providing APIs, including but not limited to insert functions and exit functions. The insert function is mainly used for data management: obtaining metadata and corresponding timestamps. The insert function is called at the beginning of the service operation. The exit function is mainly used for data management and sending the operation results of the current Span. The Span can be sent in the form of SOME / IP Message or other transmission protocols. The exit function is called at the end of the service operation.

[0105] By calculating the difference between the timestamps in the insertion function and exit function of a single service node, the latency information of a single service node can be monitored. By calculating the difference between the timestamps in the insertion function of the first node and the exit function of the last node in the entire SOA call chain, the end-to-end latency information of the entire SOA call chain can be monitored.

[0106] On the vehicle MCU side, a program often needs to be completed through multiple services. Generally speaking, when a problem occurs, such as a program timeout, error, or exception, it is difficult to quickly locate the problem. The lightweight monitoring method provided by the embodiment of the present disclosure, after obtaining the call chain monitoring index, can also achieve troubleshooting, performance optimization, system monitoring, etc. by further analyzing the above call chain monitoring index.

[0107] Troubleshooting: When a program fails or an error occurs, call chain monitoring indicators can show the path between services and the execution status of each service, helping R&D engineers quickly locate the problem.

[0108] Performance optimization: By monitoring the call chain indicators, R&D engineers can understand the execution time and bottlenecks of the program in the system and make optimizations accordingly.

[0109] System monitoring: Call chain monitoring indicators can provide real-time system monitoring and analysis, helping R&D engineers understand the health status and resource utilization of the system.

[0110] In some embodiments, the tail node may continue to append metadata and then report, wherein the appended metadata of the current tail node includes a termination identifier of the call link; or, when the current node is identified as the tail node, the node identifier of the current tail node and the call transmission message (described as a target call transmission message) received by the current tail node are reported to the server.

[0111] For example, in one implementation scenario, as the call path is transmitted, after reaching the current service node E (as an example of the tail node), the first call transmission message M received by the service node E at this time DE The metadata contained in is a metadata set with the entire link of the previous call path appended {Y A , Y B , Y C , Y D}. The current service node can continue to assign the call field according to the actual call information (service node E→no null (regarded as the end mark of the call link)). Since service node E is the tail node of the call link DL11, the end mark null of the call link is included in the metadata assigned to the current node; for example, the metadata Y to be appended corresponding to service node E is obtained. E :{span_parent_id: node E; span_peer_id: nodenull; trace_id: trace_101; SOA_protocol_id: null}. Then, the target metadata carried in the target call transmission message reported by service node E to the server can be the metadata Y added to itself E The metadata set {Y A , Y B , Y C , Y D , Y E}. In this way, the server can obtain the call chain monitoring indicators by analyzing the target metadata.

[0112] Alternatively, in another implementation scenario, as the call path is transmitted, after reaching the current service node E (as an example of a tail node), the tail node determines that the current node is the tail node based on its actual call information, and the current service node E receives the call transmission message M. DE The target call transmission message is reported, and the report also carries the node identifier of the current service node E. In this way, the service end can obtain the call chain monitoring index by analyzing the target metadata.

[0113] In some embodiments, the tail node is an end node corresponding to the real data flow during the service call, and the end node is one of the following two types:

[0114] The first type of end node corresponding to the complete data flow transfer during the service call; for example, refer to Figure 3A As shown, if the complete data flow transmission occurs, the tail node is the service node E, which belongs to the first type of end node;

[0115] An exception occurs during the service call, resulting in a portion of the data stream being successfully delivered while the remaining portion has not yet been delivered to the corresponding second-type end node; for example, refer to Figure 3A As shown, if there is an exception during the service call of service node D, service node E cannot be called (the specific reason may be, for example, that service node E is offline), then service node D serves as the tail node and belongs to the second type of end node.

[0116] The embodiments of the present disclosure also provide a logic for dynamically determining a tail node.

[0117] Specifically, the above-mentioned tail node is determined in the following manner: during the service call, for each calling node, whether the current calling node is the tail node is determined based on the transmission status of whether the data flow between the current calling node and the called one or more service nodes is successfully transmitted; if the data flow between the current calling node and the called one or more service nodes is not successfully transmitted, the current calling node is marked as the tail node.

[0118] In some embodiments, the delivery status of whether the data stream is successfully delivered is determined in the following manner: during a service call, for each calling node, based on the response information after the current calling node sends the call request corresponding to the call transmission message, it is determined whether one or more called nodes of the current calling node have timed out to respond; in the case of a timed out response, based on the preset retry logic, the call request is resent to one or more called nodes of the current calling node and a response is waited for; if a timed out response still occurs after the retry, it is deemed that the data stream has not been successfully delivered.

[0119] For example, take remote procedure call based on SOEM / IP.

[0120] (1) Set a timeout. First, set a timeout for SOME / IP communication. You can set it in the Socket options using the setsockopt function. For example, set a specific timeout to limit the time to wait for a server response.

[0121] (2) Send a request and wait for a response. After setting the timeout, the client (as the caller role) sends a request to the server (as the callee role) and waits for a response. Use the recv function to receive the server's response data.

[0122] (3) Check for timeout. If the recv function returns -1 and errno is set to EAGAIN or EWOULDBLOCK, it means that the receive operation has timed out.

[0123] (4) Post-timeout processing. After a timeout is detected, the request can be resent. For example, a threshold for the number of times a request is resent can be set.

[0124] (5) After the timeout and the threshold of the number of times the request is resent is reached, the response timeout processing logic is executed. For example: the tail node of the call chain is updated.

[0125] In the embodiments of the present disclosure, a global variable Flag can be defined to mark the status of the service node. For example, a variable of Boolean type, bool isTailNode = false. At the appropriate location of the code logic, the value of Flag is set according to whether the data stream is successfully transmitted or not. For example, if the data stream fails to be transmitted, isTailNode is set to True (that is, the second type of end node is set to the tail node); if the data stream is successfully transmitted, it is set to False (that is, the first type of end node is set to the tail node).

[0126] In other parts of the code logic, the value of this Flag is checked to determine whether the current service node is the tail node, and then the corresponding logic is executed. For example, the logic of metadata appending and point conversion transmission is executed for the intermediate node, and the logic of target call transmission message reporting to the server is executed for the tail node.

[0127] In other embodiments, the delivery status for determining whether a data stream is successfully delivered does not include the logic of a retry mechanism, for example: during a service call, for each calling node, based on the response information after the current calling node sends a call request corresponding to a call transmission message, it is determined whether one or more called nodes of the current calling node have timed out to respond; in the case of a timed out response, the data stream is deemed to have not been successfully delivered.

[0128] The method of determining whether the data stream is successfully transmitted can also be changed into other forms not listed, which will not be described in detail here. Those skilled in the art can set and adjust according to actual conditions.

[0129] In an embodiment including the above steps S110 to S130, by configuring a call field in the transmission message protocol of each service node, during a service call, the call field is assigned a value according to the actual call information to obtain metadata to be appended; as the service call occurs, the current service node performs an additional point-of-sale conversion and transmission on its own metadata to be appended in the previously occurring call path, that is, the metadata to be appended by the current service node itself is added in an additional manner to the appended metadata corresponding to one or more service nodes in the call path that have already had a call relationship, and during the transmission process, the metadata is converted and transmitted based on a preset metadata transmission method between nodes until it reaches the tail node to complete the call link. The tail node only needs to upload the target call transmission message to realize the analysis of the call chain monitoring indicators, thereby effectively realizing lightweight monitoring of the service call chain.

[0130] Since the overall call link covers at least two metadata transmission methods, when the same node (for example, a node C is a link in the call path A→B→C→D, which is both a service called by service B and a service calling service D) is called and the corresponding metadata transmission methods are different (for example, the metadata transmission method corresponding to B→C is SOME / IP, and the metadata transmission method corresponding to C→D is JSON global variables), the metadata transmission method is also converted when appending, so that the call path can continue to be transmitted according to the corresponding metadata transmission method after the conversion (for example, the metadata Y to be appended of the node C itself is converted into the metadata Y to be appended). C Append to the appended metadata of the call path A→B before B {Y A , Y B}, we get {Y A , Y B , Y C}; and convert the metadata transfer mode from SOME / IP to JSON global variable mode, so that {Y A , Y B , Y C} is transmitted to node D in the form of JSON global variables); in this way, as the calling process occurs and the metadata to be appended is transmitted through appending and embedding conversion, the target call transmission message received by the tail node of the calling link carries a collection of metadata of all service nodes before the tail node, and the call chain monitoring indicators can be analyzed according to the target metadata in the target call transmission message received by the tail node. The server does not need to communicate with each service node on the calling link in real time and obtain the data of all service nodes for integration and analysis, thereby reducing the computing resources or labor costs required for the server-side integration and analysis. For a resource-constrained operating environment, during the service call, the interactive resources required for the running service nodes to frequently report their own call information to the server are saved, and the tail node only needs to upload the target call transmission message, thereby effectively realizing lightweight monitoring of the service call chain.

[0131] In the embodiments of the present disclosure, considering that the vehicle-mounted MCU is a resource-constrained system, based on the basic hardware and software environment of MCU, OSEK OS (a real-time operating system standard), and AUTOSAR CP (a software architecture standard in the automotive industry), if the reporting logic is implemented in a task manner, and the reporting logic task is executed each time a span is generated, the CPU performance loss and memory usage will be increased.

[0132] In view of this, the embodiment of the present disclosure also provides a trigger mechanism, that is, by setting a quantity threshold or time threshold, when the accumulated quantity exceeds the set quantity threshold or the delay time (referred to as delay) exceeds the set time threshold, the task of executing the reporting logic is triggered. In this way, while realizing lightweight monitoring of the service call chain, it can also reduce the CPU performance loss and resource occupation required for frequent reporting, and minimize the delay and performance impact caused by running the call chain on the vehicle MCU side.

[0133] In some embodiments, considering that adding a new task will occupy resources, the reporting trigger condition of whether the quantity threshold or time threshold is reached is determined by using the existing exit function (to achieve the reuse of the exit function, save the resources required for creating a new task, and only need to add a judgment logic to the existing function).

[0134] Specifically, in the above step S130, uploading the target call transmission message received by the tail node of one or more call links to the server includes:

[0135] Based on the exit function, determine whether a reporting trigger condition is met; the reporting trigger condition includes at least one of the following: the total delay corresponding to one or more call links exceeds a pre-configured time threshold; or the total number of messages corresponding to one or more call links exceeds a pre-configured number threshold;

[0136] In response to satisfying the above-mentioned reporting triggering condition, the execution of the reporting task is triggered, and the above-mentioned reporting task is used to batch upload the target call transmission messages received by the tail nodes of one or more call links to the server.

[0137] Among them, the above-mentioned exit function is used to call the service operation end position corresponding to the tail node of one or more call links; the above-mentioned total delay is obtained by accumulating the delays corresponding to one or more call links, and the delay of each call link is obtained by calculating the difference between the timestamps recorded by the start function and the above-mentioned exit function. The above-mentioned start function is used to call the service operation start position corresponding to the first node of one or more call links.

[0138] In some embodiments, the system configuration file includes: a pre-configured time threshold and quantity threshold. The exit function can determine the reporting trigger condition by reading the time threshold, quantity threshold, etc. in the configuration file.

[0139] Exemplary Devices

[0140] Figure 5 The block diagram of a device for monitoring and analyzing a service call chain according to an exemplary embodiment is shown. The device of this embodiment may be a vehicle, an onboard device or other intelligent device with limited resources, or various electronic devices with unlimited resources.

[0141] Reference Figure 5 As shown, the second exemplary embodiment of the present disclosure provides a device 500 for monitoring and analyzing a service call chain. The device 500 includes: a configuration module 510 , a metadata appending and delivery module 520 , and a reporting module 530 .

[0142] The configuration module 510 is used to configure the call field in the transmission message protocol of each service node.

[0143] The above-mentioned metadata appending and transmission module 520 is used to assign values ​​to the call fields according to the actual call information during the service call to obtain the metadata to be appended; and based on the preset metadata transmission method between nodes, the metadata to be appended is appended and converted and transmitted according to the call path until it reaches the tail node to complete the call link; the above-mentioned call link covers at least two metadata transmission methods; wherein, when it is determined according to the above-mentioned actual call information that the same node is called and the metadata transmission method corresponding to the call is different, the conversion of the metadata transmission method is triggered so that the call path continues to be transmitted.

[0144] The reporting module 530 is used to upload the target call transmission message received by the tail node of one or more call links to the server, so that the server analyzes the call chain monitoring indicators according to the target metadata in the target call transmission message.

[0145] For more details, beneficial effects, etc. of this embodiment, reference can be made to the method for monitoring and analyzing the service call chain in the first embodiment above, which will not be repeated here.

[0146] Example Vehicles

[0147] Figure 6 1 is a block diagram of a vehicle according to an exemplary embodiment. The vehicle may be a fuel vehicle, a hybrid vehicle, an electric vehicle, a fuel cell vehicle or other types of vehicles.

[0148] Reference Figure 6 As shown, the vehicle 600 may include multiple subsystems, for example, a driving system 610, a control system 620, a perception system 630, a communication system 640, an information display system 650, and a computing system 660. The vehicle 600 may also include more or fewer subsystems, and each subsystem may also include multiple components, which are not described one by one here.

[0149] The driving system 610 includes components that provide power movement for the vehicle 600, such as an engine, an energy source, a transmission device, etc.

[0150] The control system 620 includes components that provide control for the vehicle 600, such as vehicle control, cockpit equipment control, and driving assistance control.

[0151] The perception system 630 includes components that provide surrounding environment perception for the vehicle 600, such as a vehicle positioning system, a laser sensor, a voice sensor, an ultrasonic sensor, a camera device, etc.

[0152] The communication system 640 includes components that provide communication connections for the vehicle 600, such as mobile communication networks (such as 3G, 4G, 5G networks, etc.), WiFi, Bluetooth, and Internet of Vehicles.

[0153] The information display system 650 includes components that provide various information displays for the vehicle 600, such as vehicle information display, navigation information display, entertainment information display, etc.

[0154] The computing and processing system 660 includes components that provide data computing and processing capabilities for the vehicle 600. The computing and processing system 660 may include at least one processor 661 and a memory 662. The processor 661 may execute instructions stored in the memory 662.

[0155] The processor 661 may be any conventional processor, such as a commercially available CPU. The processor may also include a graphics processor (Graphic Process Unit, GPU), a field programmable gate array (Field Programmable Gate Array, FPGA), a system on chip (System on Chip, SOC), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC) or a combination thereof.

[0156] Memory 662 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 memory, flash memory, magnetic disk or optical disk.

[0157] In the embodiment of the present disclosure, a set of instruction sets is stored in the memory 662, and the processor 661 can execute the instruction set to implement all or part of the steps of the service call chain monitoring and analysis method described in any of the above exemplary embodiments.

[0158] Exemplary Electronic Devices

[0159] Figure 7 is a block diagram of an electronic device 700 according to an exemplary embodiment. The electronic device 700 may be a vehicle controller, a vehicle terminal, a vehicle computer or other types of electronic devices.

[0160] Reference Figure 7 , the electronic device 700 may include at least one processor 710 and a memory 720. The processor 710 may execute instructions stored in the memory 720. The processor 710 is communicatively connected to the memory 720 via a data bus. In addition to the memory 720, the processor 710 may also be communicatively connected to an input device 730, an output device 740, and a communication device 750 via a data bus.

[0161] The processor 710 may be any conventional processor, such as a commercially available CPU. The processor may also include a graphics processor (Graphic Process Unit, GPU), a field programmable gate array (Field Programmable Gate Array, FPGA), a system on chip (System on Chip, SOC), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC) or a combination thereof.

[0162] The memory 720 may be implemented by any type of volatile or nonvolatile 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 memory, flash memory, magnetic disk or optical disk.

[0163] In the embodiment of the present disclosure, executable instructions are stored in the memory 720, and the processor 710 can read the executable instructions from the memory 720 and execute the instructions to implement all or part of the steps of the method for monitoring and analyzing the service call chain described in any of the above exemplary embodiments.

[0164] Exemplary computer-readable storage media

[0165] In addition to the above methods and devices, the exemplary embodiments of the present 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 implement all or part of the steps described in any method in the above exemplary embodiments.

[0166] The computer program product may be written in any combination of one or more programming languages ​​to write program codes for performing the operations of the embodiments of the present application, including object-oriented programming languages, such as Java, C++, etc., and also conventional procedural programming languages, such as "C" language or similar programming languages ​​and scripting languages ​​(e.g., Python). The program code may be executed entirely on the user computing device, partially on the user computing device, as an independent software package, partially on the user computing device and partially on the remote computing device, or entirely on the remote computing device or server.

[0167] The computer readable storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can include, for example, but is not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples of readable storage media include: a static random access memory (SRAM) with one or more wires electrically connected, an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic storage, a flash memory, a magnetic disk or an optical disk, or any suitable combination of the above.

[0168] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the present disclosure. This application is intended to cover any variations, uses or adaptations of the present disclosure, which follow the general principles of the present disclosure and include common knowledge or customary technical means in the art that are not disclosed in the present disclosure. The specification and examples are to be considered as exemplary only, and the true scope and spirit of the present disclosure are indicated by the following claims.

[0169] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A method for monitoring and analyzing a service call chain, characterized in that: include: Configure the call field in the transmission message protocol of each service node; During a service call, the call field is assigned a value according to the actual call information to obtain metadata to be appended; and based on the preset metadata transmission method between nodes, the metadata to be appended is appended and converted and transmitted according to the call path until the call link is completed at the tail node; the call link covers at least two metadata transmission methods; wherein, when it is determined according to the actual call information that the same node is called and the metadata transmission methods corresponding to the call are different, the conversion of the metadata transmission method is triggered so that the call path continues to be transmitted; The target call transmission message received by the tail node of one or more call links is uploaded to the server, so that the server analyzes the call chain monitoring indicators according to the target metadata in the target call transmission message.

2. The method according to claim 1, characterized in that When a first metadata transmission mode corresponding to the intermediate node as a called node is different from a second metadata transmission mode corresponding to the intermediate node as a calling node, the intermediate node obtains the prior metadata corresponding to the prior calling path by parsing the first calling transmission message corresponding to the first metadata transmission mode; Based on the second metadata transmission method, the metadata to be appended of the intermediate node is appended to the prior metadata and a buried point conversion process is performed to obtain the second call transmission message of the intermediate node and transmit it to the corresponding called node.

3. The method according to claim 1 or 2, characterized in that: The method of transmitting metadata based on the preset metadata between nodes, treating the additional metadata as appended and converted according to the call path, includes: For the first node in the call link, based on the preset metadata transmission method between the first node and the called node, the metadata to be appended of the first node is embedded in the call transmission message under the corresponding metadata transmission method and transmitted to the called node of the first node; For each intermediate node in the call link, a first call transmission message from the calling node is received and parsed to obtain the previous metadata corresponding to the previous call path; the metadata to be appended of the current intermediate node is appended to the previous metadata to obtain the current link metadata; the current link metadata is directly buried or buried format converted according to the preset metadata transmission method between the called node and the called node, and the second call transmission message of the current intermediate node is obtained and transmitted to the corresponding called node; Among them, when the first metadata transmission mode corresponding to the current intermediate node as the called node is the same as the second metadata transmission mode corresponding to the current intermediate node as the calling node, direct point embedding processing is performed on the current link metadata; when the first metadata transmission mode corresponding to the current intermediate node as the called node is different from the second metadata transmission mode corresponding to the current intermediate node as the calling node, point embedding format conversion processing is performed on the current link metadata.

4. The method according to claim 1, characterized in that: During the service call, the call field is assigned a value according to the actual call information to obtain metadata to be appended; including: When a service call occurs within the vehicle MCU or across vehicle MCUs, the call field of the current node is assigned a value according to the actual call information of each call node to obtain metadata to be appended; The calling field includes: a calling parent node identifier, one or more called child node identifiers, a monitored calling link identifier, and a transmission message protocol identifier; The assigning of a value to the call field of the current node according to the actual call information of each calling node includes: assigning the first node identifier corresponding to the current node as the value of the parent node identifier; assigning the second node identifier of one or more nodes to be called by the current node as the value of the child node identifier; assigning the link identifier generated during the service call as the value of the call link identifier; assigning the message identifier of the call transmission message constructed between the current node and one or more nodes to be called based on the corresponding metadata transmission method as the value of the transmission message protocol identifier; The call link includes at least two metadata delivery modes: Service-oriented communication middleware SOME / IP, data distribution service DDS, communication middleware TOX, variable transmission method, and transmission protocol MQTT based on message publish-subscribe mode; The call field configured in the transmission message protocol is stored in the message body content cache area in the transmission message protocol, and the metadata obtained after the corresponding value of the call field is stored by occupying the preset redundant storage space of the message body content cache area.

5. The method according to claim 1, characterized in that The uploading of the target call transmission message received by the tail node of one or more call links to the server includes: Based on the exit function, determine whether a reporting trigger condition is met; the reporting trigger condition includes at least one of the following: the total delay corresponding to one or more call links exceeds a pre-configured time threshold; or whether the total number of messages corresponding to one or more call links exceeds a pre-configured number threshold; In response to satisfying the reporting trigger condition, triggering the execution of a reporting task, wherein the reporting task is used to batch upload target call transmission messages received by tail nodes of one or more call links to a server; Among them, the exit function is used to call the service operation end position corresponding to the tail node of one or more call links; the total delay is obtained by accumulating the delays corresponding to one or more call links, and the delay of each call link is obtained by calculating the difference between the timestamps recorded by the start function and the exit function respectively. The start function is used to call the service operation start position corresponding to the first node of one or more call links.

6. The method according to claim 1, characterized in that The tail node is the end node corresponding to the real data flow during the service call, and the end node is one of the following two types: a first-type end node corresponding to a complete data flow transfer during the service call; a second-type end node corresponding to an exception during the service call that results in a successful transfer of part of the data flow but a remaining part that has not yet been transferred; The tail node is determined by: During the service call, for each calling node, according to the transmission status of whether the data flow between the current calling node and the called one or more service nodes is successfully transmitted, determining whether the current calling node is a tail node; In the case that the data flow between the current calling node and the called one or more service nodes is not successfully transmitted, the current calling node is marked as a tail node.

7. A device for monitoring and analyzing a service call chain, characterized in that: include: A configuration module, used to configure the call field in the transmission message protocol of each service node; The metadata appending and transmission module is used to assign values ​​to the call fields according to the actual call information during the service call to obtain the metadata to be appended; and based on the preset metadata transmission method between nodes, the metadata to be appended is appended and converted and transmitted according to the call path until it reaches the tail node to complete the call link; the call link covers at least two metadata transmission methods; wherein, when it is determined according to the actual call information that the same node is called and the metadata transmission method corresponding to the call is different, the conversion of the metadata transmission method is triggered so that the call path continues to be transmitted; The reporting module is used to upload the target call transmission message received by the tail node of one or more call links to the server, so that the server analyzes the call chain monitoring indicators according to the target metadata in the target call transmission message.

8. A vehicle, characterized in that: A set of instruction sets is stored, and the instruction sets are executed by the vehicle to implement the method described in any one of claims 1-8.

9. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is used to read the executable instructions from the memory and execute the instructions to implement the method described in any one of claims 1-6.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the program instructions are executed by a processor, the steps of the method described in any one of claims 1 to 6 are implemented.

Images