DE102022001441A1 - Diagnostic method for distributed software applications in a vehicle - Google Patents

Abstract

The invention describes a distributed tracing method for acquiring log data of at least one trace (40, 50) of a distributed software application, the software services (200 to 233) of at least one first runtime environment (10) arranged independently of a vehicle and at least one other runtime environment (10) in one Vehicle arranged runtime environment (20) claimed. In at least one runtime environment (10, 20), the substructures (401 to 503) of the trace (40, 50) processed there in chronological succession are identified. Features (601, 602) are determined for each substructure (401 to 503). At least one cluster (610 to 640) is formed based on the features (601, 602), from which an assigned cluster description is determined and transmitted to a detailed trace analysis (17) offered by the first, vehicle-independent runtime environment (10). The sequence of the clusters (610 to 640) corresponding to the chronological sequence of the substructures (401 to 503) in the trace (40, 50) is determined and transmitted to the detailed trace analysis (17).

Description

The invention relates to a method for acquiring log data of a distributed software application (distributed tracing method) with at least one runtime environment arranged in a vehicle according to the preamble of claim 1.

Complex software applications in a vehicle can be based on a decentralized, distributed software architecture that is comparable to the architecture of distributed systems in data centers. Functional scopes are separated into microservices (microservices), which are encapsulated from each other and are offered by different runtime environments both in a vehicle and outside, for example by a server. Such microservices are more scalable than monolithic software applications and can be developed independently.

Distributed logging methods known as distributed tracing are known for troubleshooting in distributed systems. A runtime instance of a function sequence, for example a software process or thread, which is referred to as a span, is clearly identified using an identifier (ID). Such a function flow can initiate further function flows downstream, which are offered by different microservices potentially offered by different runtime environments and which can run at least partially in parallel. An ID is also assigned to these subordinate functional flows, referred to as child spans.

Thus the call hierarchy of all runtime instances involved in a certain functional sequence is characterized by a tree of spans. The root of this tree corresponds to the entry point into the functional sequence. This root, and thus also the tree, is identified by an assigned ID. Such a tree is called a trace and the associated ID is called a trace ID.

Using distributed tracing, diagnostic and runtime information, such as the start and end time of execution, error or status codes, return values, assertions or debug outputs, can be recorded for each span of a trace. Formats, methods and programming interfaces for distributed tracing are known from the prior art, for example through the open standard Open Telemetry.

An increasing number of control units are being used in vehicles, which offer or claim software services in the form of microservices from one another and/or with device-independent software applications in the vehicle, but also with central software systems outside the vehicle. Therefore, in addition to the use of metrics and simple log files (logs), distributed tracing is also required to analyze weak points or malfunctions.

However, the software systems available in a vehicle are subject to greater restrictions in terms of computing power, storage space and in terms of the availability and bandwidth of communication links than distributed systems in a data center. There is therefore a need for a method for distributed tracing that reduces the number of logged traces and/or the amount of data to be transmitted with a trace protocol compared to known methods and that also enables logging across runtime environments that are not reliably communication-capable.

The invention is based on the object of specifying an improved method (distributed tracing method) for acquiring log data of a distributed software application which claims software services of at least one first runtime environment arranged independently of a vehicle and at least one further runtime environment arranged in a vehicle.

The object is achieved according to the invention by a method having the features of claim 1.

Advantageous configurations of the invention are the subject matter of the dependent claims.

In a distributed tracing method, log data is recorded for at least one trace that is started by a distributed software application. The distributed software application claims software services of at least a first runtime environment arranged independently of a vehicle and at least one further runtime environment arranged in a vehicle.

This vehicle-independent runtime environment offers a detailed trace analysis as a software service, with which log data from traces of the distributed software application can be examined in detail. For example, the detailed trace analysis can identify anomalies or errors on the basis of a call frequency of traces or partial sequences of traces and record them in a statistical relationship.

For example, the first, vehicle-independent runtime environment can be designed as a data cloud that offers software application services on a central, vehicle-independent server architecture. The at least one additional, vehicle-bound runtime environment can be designed, for example, as a high-performance computing (HPC) software application, with which control units in a vehicle are queried and/or controlled and which provides a connection to a central, vehicle-independent server architecture. In the following, such a vehicle-bound, and thus mobile, software application that enables a connection to a vehicle-independent (central) runtime environment will be referred to as an edge device runtime environment.

The distributed software application to be logged, and thus also the trace to be logged, can use software services that are provided by different runtime environments.

According to the invention, substructures of the trace to be logged that are processed in chronological succession are recorded in at least one runtime environment. Such substructures include a span or a sequence of spans and optionally further child spans started from it, which can run on the same or on a different runtime environment.

Characteristics are determined for each substructure, for example the structure of the call hierarchy of spans, the signature of one or more operations or microservices called from spans, the runtime (latency) and/or an error or return code. These features can be in the form of categorical data and assigned to individual components of a multidimensional feature vector, with the components of the feature vector spanning a feature space.

Based on the features determined for each substructure, at least one cluster is formed in such a way that feature vectors assigned to one and the same cluster have the greatest possible similarity and that feature vectors assigned to different clusters have the lowest possible similarity.

A cluster description is determined for each cluster, which in particular indicates the position of the cluster in the feature space. Such a cluster description can include, for example, one or more representative substructures that have been assigned to the respective cluster. As an alternative or in addition, such a cluster description can include a cluster center that captures a point in the feature space that is located centrally (in the middle) of the cluster.

Furthermore, a sequence of clusters is determined, which have been assigned to the chronological sequence of the substructures in the trace to be logged. This sequence is also sent to the detailed trace analysis.

One advantage of the method according to the invention is that instead of the raw data from a large number of traces, only the comparatively much less extensive sequences of associated clusters have to be transmitted from a vehicle. As a result, bandwidth and data volume of a mobile data connection of the edge device can be saved. Furthermore, if this mobile data connection is interrupted, this comparatively less extensive data can be buffered on the edge device until the connection for detailed trace analysis is restored.

In one embodiment of the method, at least one trace is selected as representative by at least one runtime environment. The selection is preferably made using locally, ie within the runtime environment, available features of the trace. For example, those traces are selected that represent or are expected to represent a typical course in certain error situations. The selected trace is identified against any other runtime environment. The trace ID of the selected trace is preferred; further parameters (for example trace ID of a calling parent trace, start time and/or call parameters) are optionally transmitted to the respective other runtime environments.

Each runtime environment collects local log data from a trace selected as representative by this or another runtime environment and transmits this log data to the detailed trace analysis. In the event of an interruption in a mobile data connection during transmission from a runtime environment designed as an edge device, for example, this log data is temporarily stored in a local trace cache of the respective runtime environment until transmission to the detailed trace analysis has been successfully completed.

This embodiment of the method offers the advantage that an end-to-end acquisition of a trace selected as representative is possible across different runtime environments with little communication effort. This enables a more detailed evaluation by the trace detailed analysis and thus a more precise one Determination of causal relationships between one or more software anomalies in a trace and their effects in different runtime environments.

In one embodiment of the method, features for a substructure or for a plurality of temporally consecutive substructures are determined by means of an autoencoder. Autoencoders are methods of supervised learning in which a model (for example an artificial neural network) is trained to form encoded data from raw data and to reconstruct the original raw data from the encoded data. As a result, particularly low-redundancy and at the same time meaningful characteristics for substructures can be determined.

Exemplary embodiments of the invention are explained in more detail below with reference to drawings.

• 1 schematisch ein Ablaufdiagramm für parallele Analysepipelines von verteilten Protokolldaten,
• 2 schematisch ein Ablaufdiagramm für die Analyse von Protokolldaten,
• 3 schematisch eine Aufrufhierarchie von Softwarediensten,
• 4 schematisch die zeitliche Abfolge von in Substrukturen zusammengefassten Softwarediensten sowie
• 5A und 5B schematisch die Anordnung von Clustern in einem Merkmalsraum.

show:

• 1 schematically a flowchart for parallel analysis pipelines of distributed protocol data,
• 2 schematically a flowchart for the analysis of log data,
• 3 schematically a call hierarchy of software services,
• 4 schematically the chronological sequence of software services combined in substructures as well as
• 5A and 5B schematically shows the arrangement of clusters in a feature space.

Corresponding parts are provided with the same reference symbols in all figures.

1 shows schematically a flowchart describing the analysis of log data in a distributed system. The distributed system includes a data cloud 10 as a first, central subsystem. The data cloud 10 offers services that are implemented, for example, as apps, microservices and/or processes on a server or, usually, on a plurality of interconnected servers and that are hereinafter referred to as cloud services 11. Such cloud services 11 can exchange data with each other via data connections with high speed and bandwidth.

Furthermore, the distributed system includes at least one, usually several Industrial Internet of Things (IIoT) devices, hereinafter referred to as Edge Device 20, which are connected to the data cloud 10 and potentially also to one another via the Internet. An edge device 20 is set up to convert an internet protocol transmitted in a wide area network (WAN) into an internet protocol which is transmitted in a local area network (LAN).

An edge device 20 offers services to a mobile environment independent of the data cloud 10 in the form of apps, microservices and/or processes, which are referred to as edge device services 21 below.

An edge device 20 is preferably in an in 1 Arranged motor vehicle not shown in detail and connects this via a mobile data connection, for example according to the Long Term Evolution (LTE) mobile radio standard and / or in a network of the fifth mobile generation (5G), with the data cloud 10. The exchange of data via such a mobile data connection is possible with only limited speed, bandwidth and availability compared to the exchange of data between cloud services 11 .

Complex software applications use, for example, software services 11 , 21 embodied as microservices, both of data cloud 10 and of edge device 20 , which communicate bidirectionally via service communication 31 . The control flow of such a complex software application, which can switch between at least one edge device 20 and the data cloud 10, is thus represented by a sequence of calls to individual microservices. Each of these calls creates a span, ie a sequence of related operations that are each executed in a common runtime environment 10, 20, with a unique span identification (span ID). Spans can in turn initiate further spans (i.e. further microservices).

Traces 40, 50 record the log data of all spans of such a tree, taking into account their predecessor-successor relationships. Traces 40, 50 are in 1 not shown in detail, but are explained below with reference to 3 and 4 explained in more detail. Within a trace 40, 50 there can be one or more substructures which are connected to one another in a tree-like manner via edges (calls), which are referred to as subtraces.

The invention proposes distributed logging with which the behavior of the software services 11, 21 and their dependencies can be observed and understood using traces 40, 50, with the traces 40, 50 or their spans also being distributed over the runtime The environment 10, 20 of the respective software service 11, 21 (i.e. on the edge device 20 for the edge device services 21 and on the data cloud 10 for the cloud services 11) is recorded and, at least temporarily, stored.

For this purpose, an assigned edge device analysis pipeline 2 or data cloud analysis pipeline 1 is set up both on edge device 20 and on data cloud 10, which have the same structure but are independent of one another and in which traces 40, 50 (for edge device 20 and the data cloud 10) potentially different representations recorded and analyzed as a stream (ie as a sequence of spans of a trace 40, 50 according to their predecessor - successor - relationship).

For this purpose, a logging activity referred to as a cloud trace collector 12 is started by the respective cloud service 11 . Analogously, a logging activity referred to as Edge Device Trace Collector 22 is started by the respective edge device service 21 . The log data of the spans of a trace 40, 50 recorded by the logging activities 22, 12 at the respective execution locations (edge device 20 or data cloud 10) are temporarily stored in a respective subsequent storage activity referred to as cloud trace cache 13 or edge device trace cache 23.

The log data of all spans of a trace 40, 50 are temporarily stored by means of the trace caches 13, 23 for so long that the complete evaluation of the trace 40, 50 is possible.

The protocol data temporarily stored in the trace caches 13, 23 are analyzed in a cloud trace analysis 14 or in an edge device trace analysis 24. Clusters of traces 40, 50 and/or subtraces are formed in a cloud trace/subtrace clustering 15 or edge device trace/subtrace clustering 25. The method of trace analysis 14, 24 is based on the 2 and 4 explained in more detail.

Using a cloud trace sampler 16 or an edge device trace sampler 26, raw data from the respective caches 13, 23, analysis results determined by the respective trace analysis 14, 24 and the data determined in the respective trace/subtrace clustering 15, 25 are selected according to whether a Detailed Trace Analysis 17 should be applied to it. In particular, representative traces 40, 50 and/or representative subtraces are selected for this, as will be explained in more detail below.

Using a sampler communication 32, a first trace sampler 16, 26 (e.g. the edge device trace sampler 26) informs the other trace sampler 26, 16 (e.g. the cloud trace sampler 16) which traces 40, 50 and/or subtraces as were chosen to be representative. As a result, the respective other trace sampler 26, 16 is able to select and provide the detailed trace analysis 17 with log data for those spans that the first trace sampler 16, 26 (but not the other trace sampler 26, 16) were determined to be representative.

As a result, on the one hand, the logging data can be recorded and analyzed locally (i.e. in the assigned execution environment - either on the edge device 20 or in the data cloud 10), insofar as this is necessary for the determination of representative traces 40, 50 or subtraces. take place. On the other hand, representative traces 40, 50 or subtraces can be subjected to a detailed trace analysis 17 even if they include spans that were executed in different execution environments, without log data of all executed spans having to be transmitted to the detailed trace analysis 17 as a whole .

In the extended detailed trace analysis 17, based on the representative traces 40, 50 transmitted by the trace samplers 16, 26 and based on the cluster data transmitted by means of the trace/subtrace clustering 15, 25, a complete system overview can be obtained comprising both information about the cloud services 11 and also be created to the edge device services 21 . Optionally, in the detailed trace analysis 17, the debugging of specific representative traces 40, 50 (selected via a graphical user interface, for example) can be made possible.

The agreement on whether or which traces 40, 50 should be recorded (sampled) takes place between the runtime environments 10, 20 via the service communication 31. A trace 40, 50 is identified by its trace ID, which is sent to the other runtime environment 10, 20 is transmitted. According to the trace ID, the local trace collector 12, 22 is instructed to temporarily store the locally called spans.

2 FIG. 12 shows a schematic flowchart that explains the analysis of log data temporarily stored in a trace cache 13, 23 along an analysis pipeline 1, 2 in each case.

In a substructure detection step 41, different runtime environments 10, 20 distributed traces 40, 50 divided into subtraces, which include repeatedly called subroutines. Such subtraces are used as input data for unsupervised representative learning methods and for cluster methods.

In a structure learning step 42, structural information is recorded which is contained in the graphs of the spans of a trace 40, 50 (arranged according to their predecessor-successor relationship in the call hierarchy). In a parallel feature learning step 43, one or more spans of an analyzed trace 40, 50 are assigned features, for example a signature (a name, a parameter list, a return type) to identify a service, a microservice or an operation and/or a Call determined latency value and/or a status (e.g. a return value or an error status). All of the features of a span or of a subtraces comprising several spans are encoded in a feature vector. Methods for encoding feature vectors are known from the prior art.

In a cluster learning step 44 that follows both the structure learning step 42 and the feature learning step 43, a latent representation is determined, on the basis of which a common or a similar behavior of traces 40, 50 can be determined. The formation of clusters 610 to 640 based on feature vectors that have been assigned to traces 40, 50 is based on the 5A and 5B explained in more detail.

The cluster learning step 44 acts on both the structure learning step 42 and the feature learning step 43 via a regularization feedback 45 each. In other words: which structural information is recorded in the structure learning step 42 and/or which features are determined in the feature learning step 43 is controlled on the basis of the results of the cluster learning step 44 . Such a control can, for example, be implemented numerically by means of a penalty term, which is superimposed on an optimization criterion of the respective learning step 42, 43. Alternatively or additionally, such a control or regularization can also be implemented algorithmically, for example through rule-based selection.

In a subsequent cluster assignment step 46, a trace 40, 50 is broken down into its subtraces determined by the preceding substructure detection step 41 and the preceding learning steps 42 to 44. Exactly one cluster 610 to 640 is assigned to each of these subtraces, as explained below with reference to FIG 5A and 5B will be explained in more detail. The assignment takes place in such a way that subtraces assigned to one and the same cluster 610 to 640 have the greatest possible similarity and that subtraces assigned to different clusters 610 to 640 have the lowest possible similarity. In this way, a cluster sequence 47 of clusters 610 to 640 is assigned to a trace 40, 50 in accordance with the chronological sequence of its subtraces. Thus, the trace 40, 50 can be described more simply and briefly by the order of the assigned clusters 610 to 640 instead of by the order of the parameters of its subtraces.

With the assignment of its subtraces to clusters 610 to 640, a trace 40, 50 can be used not only for adaptation (ie: for training or learning a model that can be used for future evaluations). In addition, a trace 40, 50 clustered in this way can also be subjected to processing, for example a classification, based on a current model state. As a result, the current performance (for example a throughput or the occurrence of errors in the current execution of software services 11, 21) can be determined.

3 shows schematically the relationship between software services 200 to 233 that are provided by different runtime environments 10, 20. In this case, client applications 101, 102 are shown in rectangular boxes. In the 3 The arrows shown point from a client application 101, 102 or a software service 200 to 233 to a software service 200 to 233 called by it.

A first client application 101 is a remote tester 101 offered via the data cloud 10. A second client application 102 is embodied as a workshop tester 102, which is offered by a workshop diagnostic device, not shown in detail.

In the 3 Client applications 101, 102, shown only as examples, independently call a diagnostic software service 200, which calls operations of a hardware diagnostic software service 210, a software diagnostic software service 220 and an access rights management software service 230.

The hardware diagnostics software service 210 calls operations of a control unit communication software service 211 .

The software diagnostics software service 220 invokes operations of a logging cache software service 221, a metrics cache software service 222, and a trace cache software service 223.

The access rights management software service 230 invokes operations of a certificate handler software service 231 and a token handler software service 232 . The certificate handler software service 231 optionally invokes operations of a certificate authority software service 233 .

Thus, the workshop tester 102 with the subordinate software services 200 to 233 forms a first trace 40 and the remote tester 101 forms a second trace 50 with the same software services 200 to 233 that are called up independently of the first trace 40 and potentially also with other parameters.

These traces 40, 50 are subsequently based on 4 explained in more detail in their chronological sequence along a timeline t.

In the first trace 40, the diagnostic software service 200 is used by the (in 4 not shown in detail) workshop tester 102 is called from. For example, the diagnostic software service 200 can offer a "completeDiagnosis" operation, which is invoked by the workshop tester 102 .

Within the first trace 40, a “getToken” operation of the access rights management software service 230, then a “shortTest” operation of the hardware diagnostics software service 210 and then an operation “getObservabilityData” of the software diagnostics software service 220 are called in succession .

The access rights management software service 230 first calls up a “checkCertificate” operation of the certificate handler software service 231 and then an operation “generateToken” of the token handler software service 232 . Together with the access rights management software service 230, these calls form a first substructure 401 of the first trace 40.

The hardware diagnostic software service 210 calls the operations "dtc/ecu1", "dtc/ecu2" and "dtc/ecu3" in sequence, all of which are provided by the control unit communication software service 211 and are used to retrieve error codes from one or more control units are recorded. Together with the hardware diagnosis software service 210, these calls form a second substructure 402 of the first trace 40.

The software diagnostics software service 220 sequentially performs a “recentLogs” operation of the logging cache software service 221, then a “recentMetrics” operation of the metrics cache software service 222 and then a “recentTraces” operation of the trace cache software service 223 called. Together with the software diagnosis software service 220, these calls form a third substructure 403 of the first trace 40.

In an analogous manner, in the second trace 50, the diagnostic software service 200 is used by the (in 4 not shown) remote tester 101 called from. For example, the diagnostic software service 200 can offer a “completeDiagnosis” operation that is called from the remote tester 101 .

Within the first trace 40, a “getToken” operation of the access rights management software service 230, then a “shortTest” operation of the hardware diagnostics software service 210 and then an operation “getObservabilityData” of the software diagnostics software service 220 are called in succession .

The access rights management software service 230 first calls up a “checkCertificate” operation of the certificate handler software service 231 and then an operation “generateToken” of the token handler software service 232 . In addition to these calls already included in the first substructure 401 of the first trace 40 , the certificate handler software service 231 calls an operation “revocationList”, which is offered by the certificate authority software service 233 . Together with the access rights management software service 230, these calls form a first substructure 501 of the second trace 50.

The hardware diagnostic software service 210 calls the operations “dtc/ecu1”, “dtc/ecu2”, “dtc/ecu3” and “dtc/ecu4” in sequence, all of which are provided by the control unit communication software service 211 . Together with the hardware diagnosis software service 210, these calls form a second substructure 502 of the second trace 50.

The software diagnosis software service 220 first calls up a “recentLogs” operation of the logging cache software service 221 and then an operation “recentTraces” of the trace cache software service 223 in chronological succession. Together with the software diagnosis software service 220, these calls form a third substructure 503 of the second trace 50.

As in 4 clarifies, both traces 40, 50 each have three consecutive substructures 401 to 403, 501 to 503, which are similar to one another but not the same: the first substructure 401, 501 of the first as well as the second trace 40, 50 includes calling the "getToken" operation of the access rights management software service 230 and calling the "checkCertificate" and "generateToken" operations of the certificate handler software service 231 or the token handler software service 232. In addition, the first substructure 501 of the second traces 50 the call of the “revocationList” operation of the certificate authority software service 233.

Correspondingly, the second and third substructures 402, 502, 403, 503 of the first and second traces 40, 50 have the same but also different calls for operations: in the second substructure 502 of the second trace 50, the hardware diagnosis - Software service 210 calls the operation "dtc / ecu4" in addition to the calls to the second substructure 402 of the first trace 40, which is provided by the control unit communication software service 211. In the third substructure 403 of the first trace 40, the software diagnosis software service 220 calls the operation “recentMetrics” in addition to the calls to the third substructure 503 of the second trace 50, which is provided by the metrics cache software service 222.

The mutually corresponding substructures 401 and 501, 402 and 502 and 403 and 503 of both traces 40, 50 therefore have a logical connection, but can have different runtime behavior depending on the trace 40, 50 from which they are started . By way of example, mutually corresponding substructures 401 to 503 can have different latency times and/or different status or return values and/or trigger or process different events and/or be started with different attributes or parameters.

The structure (for example number or sequence of operations called) and other features of the substructures 401 to 503 are encoded in an embedded feature vector by means of an autoencoder, not shown in detail. In this case, a numerical or categorical value, for example, is assigned to each component of the embedded feature vector.

Such an embedded feature vector describing the characteristic properties of a trace 40, 50 can be obtained from the prior art, for example from the publication P. Las-Casas, G. Papakerashvili, V. Anand, and J. Mace: “Sifter: Scalable Sampling for Distributed Traces, without Feature Engineering,” in Proceedings of the ACM Symposium on Cloud Computing, Santa Cruz CA USA, Nov. 2019, pp. 312-324. doi: 10.1145/3357223.3362736 and from the publication N Mrabah, M Bouguessa, and R Ksantini: "Adversarial Deep Embedded Clustering: on a better tradeoff between Feature Randomness and Feature Drift", IEEE Trans. Knowl. Data Eng., p. 1-1, 2020, doi: 10.1 109/TKDE.2020.2997772 known methods.

Using a cluster method, the embedded feature vectors are clustered or grouped in such a way that similar substructures 401 to 503 are assigned to the same groups or clusters 610 to 640 and at the same time different substructures 401 to 503 are assigned to different clusters 610 to 640, which are explained in more detail below.

5A shows schematically the position of a first to third cluster 610 to 630 at a first point in time t1 in a feature space 600, which is spanned as a level of only two features 601, 602 for simplified representation. Each cluster 610-630 is represented by a cluster center 611-631. The cluster center 611 to 631 is determined by the feature vector (ie: that location in the feature space 600) which has been assigned to a trace 40, 50 that best matches this cluster 610 to 630. A best possible assignment is determined by a predetermined distance metric, for example the Euclidean distance in feature space 600 . A trace 40, 50 assigned as a cluster center 611 to 631 is stored in a long-term cache.

The cluster center 611 to 631 is in each case surrounded by a cluster area which is elliptical in the present exemplary embodiment. Traces 40, 50 are assigned to a cluster 610 to 630 if they are described by an embedded feature vector that lies in the respective cluster area. In addition to the trace 40, 50 assigned to the cluster center 611 to 631, further traces 40, 50 representative of the respective cluster 610 to 630 are optionally stored in the long-term buffer, in particular those that record the position and extent of the respective cluster 610 to 630 . For example, in addition to the cluster center 611, traces 40, 50 can also be stored at the edge of the cluster 610 to 630.

Cluster characteristics of clusters 610 to 630 formed locally (that is to say: in the respective runtime environment 10, 20) are transmitted to a backend of the detailed trace analysis 17. Due to the higher bandwidth and availability, such cluster features can be transmitted from the data cloud 10 at shorter time intervals than from the edge device 20.

• basierend auf den Merkmalen der Substruktur 401 bis 503 kann die Lage eines oder mehrerer Cluster 610 bis 630 im Merkmalsraum 600 angepasst werden.

When a new trace 40, 50 to be examined is detected in the respective runtime environment 10, 20, it is first broken down into its substructures 401 to 503. Each of the substructures 401 to 503 can be used for cluster training, i.e.:

• based on the features of the substructure 401 to 503, the location of one or more clusters 610 to 630 in the feature space 600 can be adjusted.

This is illustrated schematically by the changed position of the second cluster 620 in 5B to a opposite of the situation of 5A later point in time t2.

It is also possible that traces 40, 50 between the times t1 (corresponding to 5A) and t2 (corresponding to 5B) were newly analyzed, clusters 610 to 640 disappear (here the third cluster 630) and/or are newly formed (here the fourth cluster 640).

It is also possible that a cluster center 611 to 641 (in this case the cluster center 611 assigned to the first cluster 610) is adjusted because a trace 40, 50 newly analyzed between the times t1 and t2 is more representative than the trace assigned as the cluster center 611 at the time t1 40, 50 is. In such a case, the previously assigned trace 40, 50 is replaced by the newly assigned trace 40, 50 in the long-term buffer.

Such a long-term buffer for storing traces 40, 50 can be configured depending on the resources available in the respective runtime environment 10, 20, in particular depending on the available computing power and the available memory. Comparatively more representative traces 40, 50 are advantageously stored in a runtime environment embodied as a data cloud 10, which provides fewer restricted resources, than in a runtime environment embodied as an edge device 20, which is subject to narrower restrictions. In particular, for a runtime environment configured as an edge device 20, the number of representative traces 40, 50 stored per cluster 610 to 640 can be limited by a predetermined upper limit.

Cluster features, in particular the associated representative traces 40, 50 are transmitted from the respective runtime environment 10, 20 to the detailed trace analysis 17. Cluster features recorded by a data cloud 10 are advantageously transmitted at shorter time intervals than cluster features recorded by an edge device 20, which is subject to greater restrictions in terms of availability and bandwidth of a network connection to the detailed trace analysis 17 than the data cloud 10.

Traces 40, 50 can use software services 200 to 233 in only a single runtime environment 10, 20. In this case, the respective runtime environment 10, 20 decides whether such a trace 40, 50 is recorded and then analyzed in the assigned analysis pipeline 1, 2.

If traces 40, 50 claim software services 200 to 233 from a first runtime environment 10 and at least one further runtime environment 20, then their collection is coordinated via the service communication 31 between the runtime environments 10, 20 involved.

The selection of representative traces 40, 50 takes place autonomously, i.e.: within a runtime environment 10, 20 based on the software services 200 to 233 used there and/or the operations combined into substructures 401 to 503 by the software services 200 to 233 of the respective runtime environment 10, 20 were claimed.

If a runtime environment 10 selects a trace 40, 50 as representative, the at least one other runtime environment 20 is informed of this selection and instructed to log the software services 200 to 233 used there by the selected trace 40, 50. For this purpose, the first runtime environment 10 transmits the trace ID of the selected trace 40, 50.

The at least one other runtime environment 20 is notified immediately after the trace 40, 50 is selected, so that its log data (related to the software services 200 to 233 used in the other runtime environment 20) is still available in the local trace cache 13, 23.

If log data of a representative trace 40, 50 cannot be transmitted instantaneously to the detailed trace analysis 17 from the runtime environment 10, 20, in particular from an edge device 10, due to availability or bandwidth restrictions (e.g. due to an interruption in a mobile radio connection), this log data is stored in the long-term buffer next to the representative traces 40, 50 stored there until transmission to the detailed trace analysis 17 is possible again.

One advantage of the proposed method is that the amount of data to be transmitted from an edge device 20 via mobile data connections can be reduced by only representative traces 40, 50 and cluster characteristics for clusters 610 to 640 are transmitted to the detailed trace analysis 17. In particular, this eliminates the repeated transmission of raw data of typical, thus relatively frequent, traces 40, 50, which are identical or very similar and can therefore make little contribution to the detection of an error pattern.

Another advantage is that traces 40, 50 are captured end-to-end across different runtime environments 10, 20. A trace 40, 50 relevant to the detection of an error pattern can thus also be recorded and evaluated in those substructures 401 to 503 of another runtime environment 10, 20 in which an abnormality is not manifested.

Reference List

1

Cloud analytics pipeline

2

Edge device analytics pipeline

10

Data cloud, runtime environment

11

cloud service, software service

12

Cloud Trace Collector, logging activity

13

Cloud Trace Cache, Trace Cache

14

Cloud trace analysis, trace analysis

15

Cloud Trace / Subtrace Clustering

16

Cloud Trace Sampler, Trace Sampler

17

Trace detailed analysis

20

Edge device, runtime environment

21

Edge Device Service, Software Service

22

Edge Device Trace Collector, logging activity

23

Edge Device Trace Cache, Trace Cache

24

Edge device trace analysis, trace analysis

25

Edge device trace / subtrace clustering

26

Edge Device Trace Sampler, Trace Sampler

31

service communication

32

sampler communication

40

first trace

41

substructure detection step

42

structure lesson

43

Trait Tutorial

44

cluster lesson

45

Regularization Feedback

46

cluster assignment step

47

cluster sequence

50

second trace

101

Remote tester application, client application

102

Workshop tester application, client application

200

diagnostic software service

210

Hardware diagnostic software service

211

ECU communication software service

220

Software diagnostic software service

221

Logging Cache Software Service

222

Metrics Cache Software Service

223

Trace Cache Software Service

230

Access Rights Management Software Service

231

Certificate Handler Software Service

232

Token Handler Software Service

233

Certificate Authority Software Service

401 to 403

first to third substructure

501 to 503

first to third substructure

600

feature space

601, 602

feature

610 to 640

clusters

611 to 641

cluster center

t

time beam

Claims (4)

Distributed tracing Method for acquiring log data of at least one trace (40, 50) of a distributed software application, the software services (200 to 233) of at least one first runtime environment (10) arranged independently of a vehicle and at least one further runtime environment (20) arranged in a vehicle, characterized in that in at least one runtime environment (10, 20) - the chronologically consecutively processed substructures (401 to 503) of the trace (40, 50) are identified, - features (601, 602) are determined for each substructure (401 to 503), - at least one cluster ( 610 to 640) is formed, from which an assigned cluster description is determined and transmitted to a detailed trace analysis (17) offered by the first, vehicle-independent runtime environment (10), - which follows the chronological sequence of the substructures (401 to 503) in the trace (40 , 50) corresponding sequence of the clusters (610 to 640) is determined and transmitted to the detailed trace analysis (17). procedure after claim 1 , characterized in that - from at least one runtime environment (10, 20) at least one trace (40, 50) is selected as a representative trace (40, 50) and is identified in relation to every other runtime environment (10, 20), - from every runtime environment ( 10, 20) local log data of a trace (40, 50) identified as representative is recorded and transmitted to the detailed trace analysis (17), with - the local log data being stored in a trace cache until successfully transmitted to the detailed trace analysis (17). (13, 23) are cached. Method according to one of the preceding claims, characterized in that - a subsequent second partial sequence of clusters (610 to 640) of a trace (40, 50) is predicted by means of a prediction model from a first partial sequence of clusters (610 to 640) and - cluster ( 610 to 640) can be adjusted in such a way that the prediction error is reduced. Method according to one of the preceding claims, characterized in that features (601, 602) for a substructure (401 to 503) or for a plurality of substructures (401 to 503) following one another in time are determined by means of an autoencoder.

Images