DE102022113112A1 - Method and system for collecting data for vehicles - Google Patents

Abstract

Data from multiple data sources (SWC, CS) should be able to be collected efficiently. For this purpose, a system and a method for collecting data from multiple data sources (SWC, CS) of a data system for vehicles (FZ) are proposed. A logging campaign is created with specific filter configurations for the respective data sources (SWC, CS). The filter configurations are automatically distributed to the multiple data sources (SWC, CS). The respective data sources (SWC, CS) are automatically configured with the specific filter configuration. Finally, data from each data source (SWC, CS) is transferred to a central data collection device (DL) of the data system according to the respective filter configuration.

Description

The present invention relates to a method for collecting data from multiple data sources of a data system for vehicles. In addition, the present invention relates to a system for collecting data from multiple data sources, which has a central unit and at least one vehicle, the multiple data sources being distributed across the central unit and the at least one vehicle.

So-called “connected cars” are wirelessly connected to a device for data transmission. For example, a vehicle door can be opened using a smartphone, the vehicle's charge status can be retrieved remotely, or a remote diagnosis can be carried out.

The functions of “connected cars” can be distributed across many software components, ECUs (electronic control units) in the vehicle, but also in IT systems in the (cloud) backend. For a single function, several software components often work together over long function chains (in the vehicle and/or cloud backend). In order to be able to optimally analyze the behavior of these long function chains in the event of an error and also for vehicles in development, production and "in the field", protocol or log data (i.e. log entries produced by the software components themselves, which provide information about the internal behavior of the respective software component) from all components involved can be brought to a central analysis point (data lake or data collection device, if necessary with an analysis system) and can be evaluated there in the correct chronological order. The problem here is bandwidth and resource limitations, especially in the vehicle on the communication route between the vehicle and the cloud backend (mobile wireless networks). A naive approach of collecting all log data at the highest verbosity level is therefore not feasible.

The publication US 2020/0219388 A1 discloses a method and system for card data construction in which basic security information data is collected and processed to generate the card data.

Furthermore, the publication reveals DE 10 2017 218 561 A1 a method for evaluating traffic data, in which the traffic data is recorded and evaluated by a central device and/or a cloud.

Furthermore, the publications reveal US 2020/0263992 A1 , US 2020/0263995 A1 and US 2020/0263993 A1 each a method and system for providing a campaign management platform for validating card data, a campaign being, for example, the obligation of a vehicle fleet to collect sensor data.

The publication EP 3 492 872 A1 discloses a method for storing and transmitting measurement data from measurement vehicles. A measurement campaign is started with a number of measurement vehicles. A measurement setting can be changed when a certain number of required measurements have been achieved.

Furthermore, the publication reveals DE 10 2020 007 072 A1 a method for collecting data via a plurality of connected service providers. A data collection campaign is provided with a predetermined starting criterion. The starting criterion can be, for example, a time or a traffic jam detected by an IOT device.

The object of the present invention is to collect data from multiple data sources as needed.

According to the present invention, a method for collecting data from multiple data sources of a data system for vehicles is provided. The data system has, for example, a (cloud) backend and one or more vehicles and possibly other components of an IOT system (such as smartphones). The data sources are distributed across the units of the data system. For example, a vehicle component or a backend component can represent a data source. In particular, a software component in the vehicle or the backend system can also represent a data source. The data sources are connected to a central unit of the data system for data exchange.

In a first step of the method, a logging campaign is created in the central unit, which includes a specific filter configuration for each of the multiple data sources, each of which has an identifier for the respective data source and one or more filter conditions for the respective data source. For example, a cloud backend has a logging management system that can be part of the central processing unit. For example, the logging campaign is created in this logging management system. The logging campaign is used to retrieve specific log data from the data sources or software components and, if necessary, store or analyze them. The logging cam pagne contains a specific filter configuration for each of the multiple data sources. A specific filter configuration in turn has an identifier of the respective data source (e.g. data source ID) and one or more filter conditions that should apply to the data source with regard to sending data. For example, the filter condition states that only error messages should be transmitted from the data source to the central processing unit. Due to these filter conditions, other data from the data source is then not transmitted to the central unit.

In a second step of the method according to the invention, the filter configurations of the logging campaign are automatically distributed to each of the multiple data sources. The logging campaign created in the central unit is now transmitted in terms of a data stream from the data sources to the central unit upstream to the data sources, if necessary. It is not necessary that the entire logging campaign is transmitted to every data source. Rather, it is sufficient if only the filter configuration from the logging campaign that is assigned to the respective identifier of the data source is sent to each data source. If each data source receives the entire logging campaign and therefore all filter configurations, it must have its own intelligence to extract the filter configuration specific to it. Otherwise, if the data source only receives the filter configuration intended for it from the logging campaign, an intelligence must be connected between the central unit and the data source (e.g. concentration device or concentrator), which distributes the filter configurations from the logging campaign to the various data sources realized.

In a subsequent step, the respective data source is automatically configured with the specific filter configuration. Each data source that has received its specific filter configuration from the logging campaign from the central processing unit must be automatically configured according to this filter configuration or configure itself according to this filter configuration.

Finally, in a further step of the method according to the invention, data is transferred through each data source to a central data collection device (data lake) of the data system in accordance with the respective filter configuration. Preferably, the central data collection device is also part of the central unit in the cloud backend. This means that first the filter configurations are transmitted upstream from the central processing unit to the data sources and then data from the data sources are transmitted downstream to the central processing unit.

Advantageously, campaign-based collection, filtering, if necessary buffering, extraction and, if necessary, central evaluation of attributed log data from fleets of “connected cars” is possible, optionally including the log data from the cloud backend systems connected to them.

In a preferred embodiment of the method according to the invention, it is provided that the data system has at least two elements from the set of vehicles, cloud and terminals, and the multiple data sources are software components of the respective element. This means that the data system includes, for example, one or more vehicles and a cloud. If necessary, the data system can also have, for example, a vehicle and a terminal. In an advantageous embodiment, the above-mentioned central unit in which the logging campaign is created is integrated into the cloud. The data sources mentioned are preferably software components in the vehicles, in the cloud or in the end devices. The aim is then, for example, to analyze a functional chain from a software component of a vehicle to a software component in the cloud or in the end device.

In an advantageous embodiment, the filter configurations are automatically distributed by a concentration device that splits the logging campaign so that each data source only receives that filter configuration that corresponds to its identifier. In this case, the filter configurations of the logging campaign are distributed upstream through the one or more concentration devices. As a result, each data source preferably only receives the filter configuration or configurations that are intended for the respective data source. So, for example, if a filter configuration is associated with a data source ID, only the specific data source with the specific ID will receive the filter configuration. In this way, the amount of data upstream can be reduced right down to the last branches.

In a preferred development of the method, it can be provided that when data is transmitted from at least two of the data sources, a partial data stream is sent to the concentration device, the partial data streams are concentrated in the concentration device to form a total data stream and the total data stream is transmitted to the central data collection device. This means that the data is stored downstream using concentration Device(s) are combined or concentrated into the overall data stream. This in turn has the advantage that the efficiency of data transmission is increased with the wireless transmission of the entire data stream to the central unit, which is usually necessary.

In addition, it can be provided that the data system has at least one further concentration device of the type mentioned in addition to the concentration device in a data stream from one of the data sources to the central data collection device. Since a concentration device represents a branch of the data stream, several concentration devices one behind the other in the data stream mean a multiple branching of the data stream. In principle, the data stream can be branched as required. For example, a concentration device can be housed in a control unit of a vehicle. A central control device can then have a central logging concentrator, from which the entire data stream of a vehicle is then transmitted to the central data collection device or central unit.

In a likewise preferred exemplary embodiment, it is provided that, in addition to the filter configurations, the logging campaign has at least one element of preprocessing instructions, trigger conditions, runtimes, storage specifications and attributes, the at least one element being distributed to one or more of the data sources during the automatic distribution and that Automatic configuration and transfer of data also takes place depending on the distributed at least one element. This means that the logging campaign can be based on additional attributes that are distributed to the respective data sources with the filter configurations. For example, so-called scripts can be distributed to the data sources as preprocessing instructions. Trigger conditions can provide the data source trigger, for example when data should be collected. Runtimes can be defined to limit the time of data collection. In addition, storage specifications can be created as part of the logging campaign and distributed to the data sources with the filter configurations, for example to specify the size of a ring buffer or a storage location. In addition, other attributes, for example regarding authentication and encryption, can also be transmitted with the filter configurations. In this case, one or more of the above-mentioned elements or attributes are transferred to the data source in addition to the respective filter configuration and used there for the automatic configuration. For example, a data source is automatically configured with a specific filter configuration and a specific preprocessing script and a specific trigger condition, etc.

As shown above, a filter configuration consists of a data source identifier and one or more filter conditions. The filter conditions can be selected, for example, from a) criticality levels of the data, b) logging categories, c) data protection categories, d) security categories, e) value range specifications and f) pre-processing scripts, i.e. scripts that can be loaded into the vehicle as part of the campaign configuration can implement advanced filter algorithms). One or more of these filter conditions can be included in the respective filter configuration. In the criticality level, for example, the data is divided into classes such as error, warning, information and the like. In the logging category, a distinction can be made as to how detailed the logging should take place and to what extent, for example, files should be embedded. The privacy and security categories can be used to take into account privacy rights and security requirements. Value range specifications, for example, enable values to be limited using comparison operators. The filter conditions are not limited to the variants mentioned. With their diverse design, they make it possible to adapt the logging campaign very individually and to reduce the necessary data flows to a minimum.

The data system can, for example, have a vehicle, with the logging campaign being transmitted wirelessly from the central unit to the vehicle and the filter configurations being distributed to software components as data sources in the vehicle. For example, the logging campaign is transmitted from the central unit to the vehicle via a so-called OTA connection (over the air). Such OTA connections can be used in conventional vehicle operation. Alternatively, a local network or a memory or USB stick can be used to transfer the logging campaign to the vehicle, for example in a service point (backend or central unit). Wireless transmission of the logging campaign allows you to avoid the hassle of wired transmission of campaign data.

In a further preferred embodiment of the method according to the invention, the data system has a backend with a cloud, the central unit being integrated into the backend, the logging campaign being transferred from the central unit to a backend system in the cloud and in The backend system distributes the filter configurations to several cloud services as data sources. In this case, the backend with the central unit, which in turn has the central data collection device, is connected to a cloud with which the backend can exchange data. Just as the control devices in vehicles have software components, cloud backend systems can have cloud services as data sources. Such a cloud service can, for example, establish a connection with a terminal device, in particular a smartphone or with another IOT device (Internet of Things). This makes it possible to distribute a logging campaign not only to different vehicles, but also to cloud backend systems and even to devices such as smartphones. Conversely, this also enables the collection of data downstream from the cloud services to the central data collection facility, if necessary via logging concentrators in the cloud backend systems.

In the event that the data system has a vehicle, the vehicle can have a ring buffer, with the ring buffer being read out in accordance with a trigger condition of the logging campaign for the data to be transferred. In this case, the vehicle's ring buffer is filled with a continuous data stream, for example. If the predeterminable trigger condition occurs, the ring buffer is read out in whole or in part. For example, the ring buffer is read out if there is an error message as a trigger condition. This means that logging data is only transferred if there is an error. In this way, data transfer capacity can be systematically saved and the history of the log entries that were generated by the data sources before the error occurred can be saved.

In a further advantageous exemplary embodiment, all data sources of the data system provide their data to be transmitted with a time stamp that is based on a common time base. Such a central time stamp enables all data in the data system to be synchronized and therefore evaluated in a more targeted manner.

Furthermore, it is favorable if all data sources of the data system provide their data to be transmitted with an identifier of the respective data source that is unique within the data system. This means that in the backend or in the central unit it can be precisely traced which data source supplied the respective data. This means, for example, that an error can be found in a more targeted manner.

As mentioned, the data system can have one or more concentrators with which the logging campaign can be distributed upstream and the data can be concentrated downstream. Each concentration facility can carry out filtering and/or pre-processing of data according to the logging campaign. A concentration facility can therefore also be seen as a data source that can be automatically configured using the logging campaign. In particular, a concentration device can thus be configured with regard to its filtering effect of data flowing downstream or also of upstream filter configurations. The same applies to any pre-processing functions of the concentration facility(s).

In a specific exemplary embodiment, the data system can, as indicated above, have a vehicle with several control devices and a central control device, with several data sources of the data system being distributed among the several control devices, and the central control device taking over the automatic distribution of the filter configurations of the logging campaign to the control devices . In particular, each control device can have one or more software components as data sources that can be configured according to the logging campaign. The data can then be concentrated downstream, for example in each control device by a respective concentration device, before being transmitted to the central control device, where it can in turn be centrally concentrated. In this way, very efficient data transmission can also be achieved within a vehicle.

• - einer Zentraleinheit,
• - mindestens einem Fahrzeug,
• - den mehreren Datenquellen verteilt über die Zentraleinheit und das mindestens eine Fahrzeug,
• - einer Managementeinrichtung in der Zentraleinheit zum Erstellen einer Logging-Kampagne, die für jede der mehreren Datenquellen eine spezifische Filterkonfiguration umfasst, welche jeweils eine Kennung für die jeweilige Datenquelle und eine oder mehrere Filterbedingungen für die jeweilige Datenquelle aufweist, und
• - einer Konzentrationseinrichtung zum automatischen Verteilen der Filterkonfigurationen der Logging-Kampagne an jede der mehreren Datenquellen, wobei
• - jede Datenquelle dazu ausgebildet ist, sich automatisch mit der jeweils spezifischen Filterkonfiguration zu konfigurieren und Daten zu einer Datensammeleinrichtung der Zentraleinheit entsprechend der jeweiligen Filterkonfiguration zu übertragen.

The above-mentioned task is also achieved according to the invention by a system for collecting data from multiple data sources

• - a central unit,
• - at least one vehicle,
• - the multiple data sources distributed across the central unit and the at least one vehicle,
• - a management device in the central unit for creating a logging campaign, which includes a specific filter configuration for each of the multiple data sources, each of which has an identifier for the respective data source and one or more filter conditions for the respective data source, and
• - a concentrator for automatically distributing the filter configurations of the logging campaign to each of the plurality of data sources, wherein
• - Each data source is designed to automatically configure itself with the respective specific filter configuration and to transmit data to a data collection device of the central unit in accordance with the respective filter configuration.

The advantages and possible variations described above in connection with the method according to the invention also apply mutatis mutandis to the system according to the invention. In particular, the process features described in connection with the method can be seen as functional features of corresponding components of the system.

Optionally, a computer program can also be provided which includes commands which, when the program is executed by a control device of a data system of the above type, cause it to carry out an above-mentioned method. Furthermore, a computer-readable storage medium can be provided, comprising instructions which, when executed by a control device of a data system of the above type, cause it to carry out an above-mentioned method.

The present invention will now be based on 1 explained in more detail, which schematically shows an exemplary embodiment of a method according to the invention for collecting data from multiple data sources in a flow chart.

The individual blocks can also be seen as corresponding hardware components of a system for collecting data.

The exemplary embodiments described in more detail below represent preferred embodiments of the present invention.

1 shows a central unit or a backend BE in which a data collection or logging campaign can be created and the corresponding data can be collected. Next to it shows 1 As a frontend, for example, a so-called Internet-of-Things IOT on both sides of the backend BE. However, the IOT should be viewed as a whole and only for the sake of clarity 1 divided into two. The IOT includes, for example, vehicles or their control devices SGP-1, ..., SGP-m (generally SGP) and Z, but also end devices such as smartphones SP, as shown in 1 are shown on the right. The latter can be connected to a central data collection device DL of a cloud CL.

A logging campaign can, for example, be created by a campaign creator KE using a logging management system LMS in the backend BE or in the central unit, for example for the ongoing operation of a vehicle fleet. Alternatively, the logging campaign can also be created, for example, for the development phase or the production phase by a developer EW or production technician in a production system PS.

• - Eine Sammlung von Filterkonfigurationen beispielsweise in Form eines n-Tupel [Datenquelle-ID, Filterbedingung(en)], wobei die Datenquellen Software-Komponenten (SWC beziehungsweise CS) sein können und die Filterbedingungen unten näher definiert sind.
• - Vorverarbeitungsanweisungen (z.B. Skripte)
• - Triggerbedingungen, mit denen definiert werden kann, wann Logdaten erzeugt werden sollen.
• - Laufzeiten, mit denen definiert werden kann, dass eine Kampagne in einem bestimmten Zeitraum ausgeführt werden soll, wobei beispielsweise pro Fahrzeug auch mehrere Kampagnen parallel ausgeführt werden können.
• - Speichervorgaben beispielsweise für einen Ringpuffer FR (Flight Recorder) in einem Fahrzeug, wie etwa Ablageort im Dateisystem, maximale Größe des Ringpuffers für die Kampagne, maximal nutzbarer Speicher auf einem Flash-Speicher eines Zentralsteuergeräts Z oder auf einem externen Speichermedium (z.B. USB-Stick) z.B. für sogenannte „Snapshots“ (Datenschnappschüsse) der Kampagne und maximale Größe pro Snapshot-Datei.
• - Attribute (Parameter/Werte-Paare) z.B. für die Angabe von Authentifizierungsinformationen oder Schlüsselinformationen für die Verschlüsselung der Snapshot-Dateien.

A logging campaign can be seen as a data element and contains, for example, one or more of the following components:

• - A collection of filter configurations, for example in the form of an n-tuple [data source ID, filter condition(s)], where the data sources can be software components (SWC or CS) and the filter conditions are defined in more detail below.
• - Preprocessing instructions (e.g. scripts)
• - Trigger conditions that can be used to define when log data should be generated.
• - Runtimes that can be used to define that a campaign should be carried out within a certain period of time; for example, several campaigns can be carried out in parallel per vehicle.
• - Storage specifications, for example for a ring buffer FR (flight recorder) in a vehicle, such as storage location in the file system, maximum size of the ring buffer for the campaign, maximum usable memory on a flash memory of a central control device Z or on an external storage medium (e.g. USB stick ) e.g. for so-called “snapshots” (data snapshots) of the campaign and maximum size per snapshot file.
• - Attributes (parameter/value pairs) e.g. for specifying authentication information or key information for encrypting the snapshot files.

The filter conditions for configurable data sources can be defined using the filter configurations. Selectable and configurable data sources include so-called “log channels” from software components SWC in the software partitions of control devices SGP-1 to SGP-m, i.e. corresponding sources with source indices Q1-1 ... Q1-n, .. ., Qm-1 ... Qm-n in a vehicle in question. The “log channels” can also be parts of these data sources. Furthermore, “log channels” can also be used by so-called cloud services CS1-1 ... CS1-n, ..., CSm-1 ... CSm-n (generally CS) in various cloud backend systems BES-1, ..., BES-m, which are involved in the implementation of a connected car function, for example.

• - Maximaler Log-Level: Z.B. Kategorien wie „Fatal“, „Error“, „Warning“, „Info“, „Debugg“, „Verbose“ (sortiert nach steigendem Datenumfang).
• - Logging-Kategorie: Z.B. die Kategorien „Trace“, „Log“, „Recording“, wobei „Log“ ein standardmäßiges Logging, „Trace“ ein ausführlicheres Logging und „Recording“ ein Logging mit zusätzlich eingebetteten Referenzen (z.B. Videodateien) bedeuten kann.
• - Datenschutzrechtliche Relevanz der Logdaten (z.B. keine Erfassung von personenbezogenen Daten erlaubt, Indikation einer notwendigen Verschleierung von Standortdaten).
• - Sicherheitsrelevanz der Logdaten: Z.B. keine, authentisch, vertraulich
• - Wertebereiche von beliebigen Attributen, d.h. Konfigurationsinformationen: Z.B. Auswahl von Parameter/Werte-Paaren unter Eingabe eines oder mehrerer Vergleichsoperatoren und eines Referenzwerts, mit dem der jeweilige Wert verglichen werden soll.

One or more of the following conditions can be used as filter conditions:

• - Maximum log level: E.g. categories such as “Fatal”, “Error”, “Warning”, “Info”, “Debugg”, “Verbose” (sorted according to increasing data size).
• - Logging category: E.g. the categories “Trace”, “Log”, “Recording”, where “Log” can mean standard logging, “Trace” can mean more detailed logging and “Recording” can mean logging with additional embedded references (e.g. video files). .
• - Relevance of the log data under data protection law (e.g. no collection of personal data permitted, indication of necessary concealment of location data).
• - Security relevance of the log data: E.g. none, authentic, confidential
• - Value ranges of any attributes, ie configuration information: E.g. selection of parameter/value pairs by entering one or more comparison operators and a reference value with which the respective value should be compared.

In the main use case, as indicated above, campaigns are created by users (campaign creator KE) using, for example, a logging management system LMS in a cloud backend (backend in a cloud). The LMS in turn automatically distributes the campaigns to selected vehicles or entire vehicle fleets, for example using an order management service DCOM of a vehicle fleet data collection system GDC. The LMS also configures, for example, the cloud backend systems BES-1, ..., BES-m connected to the vehicles so that the filter configurations contained in the campaign for the backend data sources (e.g. smartphone SP) are sent to the affected cloud services (CS1-1 ... CS1-n, ..., CSm-1 ... CSm-n) are distributed (during the period for which a campaign is active). This occurs “upstream” (solid arrows in 1 ; against the downstream flowing log data stream (dashed arrows)) via a cascade of logging concentration devices VLK-1, ..., VLK-m or BLK-1, ..., BLK-m (generally VLK or BLK) to to the cloud services CS1-1 ... CS1-n, ..., CSm-1 ... CSm-n (generally CS) affected by a campaign, whose log channels are configured accordingly so that they only contain the desired data to produce. This may involve forwarding from CS to end devices SP (smartphone).

After creation by the order management service DCOM, the campaigns and the filter configurations they contain for the SWC software components in the vehicles are sent to the respective vehicle in the IOT via wireless connections (over-the-air, OTA) and there, for example, in the central control unit Z ( Gateway) is received by the data collection master DCM and forwarded, for example, to the ring buffer FR. The ring buffer FR can control the runtime of a campaign in the vehicle, i.e. in which period of time the log data sources there should be configured with the filter configuration data contained in the campaign.

When the campaign is active, the filter configuration data is first passed on, for example, from the ring buffer FR to the central logging concentration device VLK-Z in the central control unit Z. Afterwards, a cascade of intermediate collection points, so-called “logging concentrator services” VLK or VLK-1 ... VLK-m, initially distributes (routing) the filter configurations “upstream” to fine-grained, selectable log data sources (“log channels”). ) in the software components of the control units in the vehicle. This results in extensive control of the log data volume that occurs via the filter configurations contained in the campaign.

If possible, the filter configurations should already be applied at the sources so that only the minimum amount of log data has to be processed downstream. Depending on the performance of the systems (both on-board and in the cloud), it can be decided whether more complex filter conditions will also be implemented in the logging concentrator services VLK.

The advantage of these filter configurations, which can be set in detail, makes it possible to access precisely those data sources that are suspected of being responsible for an error pattern reported in the field, for example, in a selective and fine-grained manner, possibly including historical log data that led to an error event. This means that efficient troubleshooting and analysis can be carried out in a resource-saving manner and despite low bandwidth resources and, if necessary, transmission volumes.

• Entwickler EW wollen direkt am Fahrzeug die Logdatenquellen für die Analyse eines beobachteten Fehlers konfigurieren. Sie erstellen hierzu ähnlich wie der Kampagnenhersteller KE eine Kampagne, die in diesem Fall beispielsweise über ein lokales Netz LN oder ein Speichermedium ins Zentralsteuergerät Z des Fahrzeugs übertragen wird. Im Zentralsteuergerät Z empfängt der Fahrzeugdiagnoseservice VDS die Kampagne und übergibt sie an den Ringpuffer FR. Von dort wird die Kampagne stromaufwärts über den Loggingkonzentrator VLK-Z des Zentralsteuergeräts Z an Software-Komponenten SWC QZ-1 ... SWC QZ-n des Steuergeräts Z und/oder an andere Steuergerät-Softwarepartitionen SGP-1 ... SGP-m verteilt. Die Loggingkonzentratoren VLK-1 ... VLK-m der Steuergerät-Softwarepartitionen SGP-1 ... SGP-m verteilen die jeweiligen Filterkonfigurationen der Loggingkampagne an die steuergerätinternen Software-Komponenten SWC Q1-1 ... SWC Q1-n, ..., SWC Qm-1 ... SWC Qm-n.

The system described is open to further use cases with alternative introduction of campaigns. In addition to defining campaigns via the logging management system LMS and the data collection system for vehicle fleets GDC, the invention makes it possible to introduce campaigns via diagnostic access to the vehicle. For example, there is a component in the vehicle called vehicle diagnostic service VDS provided. This enables, for example, the following two use cases:

• Developers EW want to configure the log data sources directly on the vehicle for analyzing an observed error. To do this, you create a campaign similar to the campaign manufacturer KE, which in this case is transmitted, for example, via a local network LN or a storage medium to the central control unit Z of the vehicle. In the central control unit Z, the vehicle diagnostic service VDS receives the campaign and transfers it to the ring buffer FR. From there, the campaign is sent upstream via the logging concentrator VLK-Z of the central control unit Z to software components SWC QZ-1 ... SWC QZ-n of the control unit Z and/or to other control unit software partitions SGP-1 ... SGP-m distributed. The logging concentrators VLK-1 ... VLK-m of the ECU software partitions SGP-1 ... SGP-m distribute the respective filter configurations of the logging campaign to the ECU-internal software components SWC Q1-1 ... SWC Q1-n, .. ., SWC Sqm-1 ... SWC Sqm-n.

During the campaign, the log data generated according to the respective filter configurations of the data sources flows from the software components via the logging concentrators according to the dashed arrows 1 preferably to the ring buffer FR. According to the configuration of the campaign, snapshots SN can be obtained from the ring buffer. After the campaign has ended, the created snapshots SN can be downloaded to the developer system (symbolized by the developer EW) via the vehicle diagnostic service VDS or manually transferred to the central data collection device DL. For example, this transfer can take place from the central control device Z to the developer system using a USB stick.

In another application, in vehicle production (factory), the internal behavior of the software components SWC on the control devices or the control device partitions SGP should be observed during commissioning in order to be able to detect production errors, for example. For this purpose, the factory's IT systems, such as a production system service PS, can introduce campaigns via the local network LN via the vehicle diagnostic service VDS into the ring buffer FR or filter configurations into the central logging concentrator VLK-Z for further distribution. In this way, exactly the relevant log channels can be tapped for each production step.

• - Eindeutige Angabe der Logdatenquelle (Logkanal) per UUID oder anderer global eindeutiger Identifikationsinformation; beispielsweise besitzt eine Software-Komponente SWC einen oder mehrere Logkanäle.
• - Hochauflösender (z.B. 1µs) und präziser Zeitstempel (z.B. Abweichung maximal +/- 50 µs von der global synchronisierten Referenzzeit SRZ, die beispielsweise in jedem Steuergerät beziehungsweise jedem Cloud-Backend-System BES zur Verfügung steht und auf eine Referenzzeit RZ einer zentralen Zeitbasis bezogen ist). Der Zeitstempel sollte immer in eine absolute Zeit beispielsweise als Differenz zum Datum 01.01.1970 UTC umgerechnet werden können. Hierzu kann es notwendig sein, dass ein Integer-Datentyp mit 64 Bit Größe zur Verfügung gestellt wird. Mit einem derartigen Zeitstempel kann sichergestellt werden, dass in der zentralen Datensammeleinrichtung DL alle Lognachrichten zeitlich korrekt einsortiert werden können. Somit lässt sich eine hohe Datenqualität für gute Auswerteergebnisse beispielsweise in einem großen Datenanalysesystem BDAS, welches mehrere Datenanalysesysteme DAS1 ... DASn aufweisen kann, sicherstellen.
• - Ein sogenannter Logglevel, d.h. eine Kritikalitätsstufe der Lognachrichten, kann beispielsweise folgende Werte annehmen:
  • • FATAL (fataler Fehler)
  • • ERROR (Fehler in Bezug auf korrekte Funktionalität)
  • • WARN (Warnung, wenn korrektes Verhalten nicht sichergestellt werden kann)
  • • INFO (hochrangige Information)
  • • DEBUG (detaillierte Information für Programmierer)
  • • VERBOSE (ausführliche Debug-Nachricht)
• - Nicht-unterdrückbar-Flag: Falls dieses Flag gesetzt ist, darf die Nachricht nicht ausgefiltert werden. Hiermit markierte Lognachrichten werden für die Propagierung interner Fehler des Logging-Systems verwendet.
• - Liste von Attributen (Parameter-Werte-Paare). Eine Lognachricht kann also beispielsweise folgende Attribute aufweisen:
  • • „Sicherheitsniveau“ beziehungsweise „Security Level“ (mögliche Werte:
    • keines, authentisch, vertraulich): Gibt die Schutzwürdigkeit der Lognachricht an in Bezug auf Cyber-Security-Eigenschaften wie „Authentizität“ und „Vertraulichkeit“. Das Sicherheitsniveau wird zur Filterung und Entscheidung verwendet, ob die Logdaten über bestimmte Verbindungen gesendet beziehungsweise auf Medien gespeichert werden dürfen beziehungsweise in welcher Form (z.B. verschlüsselt). Fehlt die Angabe, so wird die höchste Schutzwürdigkeit angenommen (d.h. vertraulich).
  • • „Datenschutzniveau“: Gibt die Schutzwürdigkeitsklasse der Lognachricht in Bezug auf ihre datenschutzrechtliche Relevanz an. Bei fehlender Angabe soll die höchste Schutzwürdigkeitsklasse angenommen werden, da eine datenschutzrechtliche Signifikanz nicht bewertet werden kann.
  • • „Kategorie“ mit folgenden möglichen Werten:
    • ▪ „Trace“: Diese Kategorie weist beispielsweise darauf hin, dass die Lognachricht instrumentierten Code aufweist.
    • ▪ „Log“: Hierbei kann es sich um Standard-Lognachrichten durch Programmablauf handeln.
    • ▪ „Recording“: Bei dieser Kategorie kann die Lognachricht eingebettete Dateien im Ereignisstrom aufweisen, wie etwa einen Screenshot.
    • ▪ „Referenz“: Die Lognachricht erhält einen Verweis auf eine Datei beziehungsweise Nachricht, die persistent in dem System gespeichert ist (z.B. in Form einer URI, die für ein Log-Ereignis abgelegt ist).
    • ▪ „Statistik“: Statistische Informationen
    • ▪ „Performance“: Performance-relevante Informationen
• - Nachrichteninhalt(e) („Payload“): Pro Lognachricht, d.h. pro Zeitstempel und gemeinsamen Attributen, können auch mehrere Nachrichteninhalte registriert werden.

The production and forwarding of log data is explained in more detail below. Log data may consist of individual log messages, for example with the following properties and data fields:

• - Clear indication of the log data source (log channel) via UUID or other globally unique identification information; For example, a software component SWC has one or more log channels.
• - High-resolution (e.g. 1µs) and precise time stamp (e.g. maximum deviation of +/- 50 µs from the globally synchronized reference time SRZ, which is available, for example, in every control unit or every cloud backend system BES and based on a reference time RZ of a central time base is). The timestamp should always be able to be converted into an absolute time, for example as a difference to the date 01/01/1970 UTC. For this purpose, it may be necessary to provide an integer data type with a size of 64 bits. With such a time stamp it can be ensured that all log messages can be sorted in the correct time in the central data collection device DL. This makes it possible to ensure high data quality for good evaluation results, for example in a large data analysis system BDAS, which can have several data analysis systems DAS1 ... DASn.
• - A so-called log level, ie a criticality level of the log messages, can, for example, assume the following values:
  • • FATAL (fatal error)
  • • ERROR (error related to correct functionality)
  • • WARN (warning when correct behavior cannot be ensured)
  • • INFO (high-level information)
  • • DEBUG (detailed information for programmers)
  • • VERBOSE (verbose debug message)
• - Non-suppressable flag: If this flag is set, the message may not be filtered out. Log messages marked here are used to propagate internal errors in the logging system.
• - List of attributes (parameter-value pairs). For example, a log message can have the following attributes:
  • • “Security level” or “Security Level” (possible values:
    • none, authentic, confidential): Indicates the level of protection of the log message in relation to on cyber security properties such as “authenticity” and “confidentiality”. The security level is used to filter and decide whether the log data can be sent over certain connections or stored on media or in what form (e.g. encrypted). If the information is missing, the highest level of protection is assumed (ie confidential).
  • • “Data protection level”: Indicates the level of protection of the log message in relation to its relevance to data protection law. If no information is provided, the highest level of protection should be assumed, as significance under data protection law cannot be assessed.
  • • “Category” with the following possible values:
    • ▪ “Trace”: This category indicates, for example, that the log message contains instrumented code.
    • ▪ “Log”: This can be standard log messages from the program flow.
    • ▪ “Recording”: In this category, the log message can have embedded files in the event stream, such as a screenshot.
    • ▪ “Reference”: The log message receives a reference to a file or message that is persistently stored in the system (e.g. in the form of a URI that is stored for a log event).
    • ▪ “Statistics”: Statistical information
    • ▪ “Performance”: Performance-relevant information
• - Message content(s) (“Payload”): Multiple message contents can be registered per log message, ie per timestamp and common attributes.

The log data can be transferred and stored in a standardized format. Such a standardized format (“canonical form”) can, with given flexibility, enable the conversion or embedding of other existing log data formats into this “canonical form”. However, other log data formats (e.g. AUTOSAR DLT) can also be adapted to support the above properties and data fields.

The log messages from the respective sources resulting from the application of the filter configurations are forwarded “downstream” via the same cascade of logging concentrators VLK or BLK - as mentioned above - to a central data collection device DL in the backend BE.

• - Direkte Weiterleitung einzelner Lognachrichten vom zentralen Logging-Konzentrator VLK-Z über den Datensammlungsmaster DCM und die Drahtlosschnittstelle OTA via das Datensammelsystem GDC für die Fahrzeugflotte beziehungsweise dessen Datenpumpe DP in die zentrale Datensammeleinrichtung DL.
• - Ringpuffer-Funktionalität („Flight Recorder“ FR): Hierbei zunächst onbordseitige Aufzeichnung und Zwischenspeicherung mehrerer Lognachrichten in Form von Schnappschüssen SN („Log Snapshot Dateien“) in einem persistenten Speicher des Zentralsteuergeräts Z (z.B. Flash-Speicher, am Zentralsteuergerät Z angeschlossener USB-Stick, et cetera). Anschließend erfolgt eine Abgabe der Schnappschüsse SN an den Datensammlungsmaster DCM mit OTA-Weiterleitung an das Datensammelsystem GDC und die Datensammeleinrichtung DL, oder die Schnappschüsse SN werden über die Diagnoseschnittstelle des Fahrzeugs beziehungsweise den Fahrzeugdiagnoseservice VDS ausgelesen.

There are several options from the vehicle:

• - Direct forwarding of individual log messages from the central logging concentrator VLK-Z via the data collection master DCM and the wireless interface OTA via the data collection system GDC for the vehicle fleet or its data pump DP into the central data collection device DL.
• - Ring buffer functionality (“Flight Recorder” FR): Initially, on-board recording and buffering of several log messages in the form of snapshots SN (“Log Snapshot Files”) in a persistent memory of the central control unit Z (e.g. flash memory, USB connected to the central control unit Z -Stick, etc.). The snapshots SN are then sent to the data collection master DCM with OTA forwarding to the data collection system GDC and the data collection device DL, or the snapshots SN are read out via the diagnostic interface of the vehicle or the vehicle diagnostic service VDS.

The log data is forwarded in a preferably uniform, standardized format. A possible specification of the format could, for example, become part of the “AUTOSAR” standard.

Optionally, filtering and preprocessing can take place in the logging concentrators or concentrator devices VLK and BLK. The introduction of the “intermediate collection points” VLK and BLK in the collection cascade enables pre-processing (e.g. pre-analyses, extended filtering options, data compression, etc.) already in the vehicle (“IOT Edge Computing”) by aggregating and temporarily storing the log data (= “Flight Recorder” functionality). .

The preprocessing instructions to be carried out are introduced, for example, in the form of scripts as part of the campaign data. LUA, for example, can be used as a scripting language.

Optionally, a special triggering of the snapshots from the ring buffer FR can also take place. By aggregating log data in one or more ring buffers (at least one per campaign and its filter configurations) and storing them as snapshot files when the trigger conditions defined in the campaign are met, the history of log messages up to a specific event (e.g occurrence of an error). For example, you can always use the last two minutes The number of log messages can be stored in the ring buffer and retrieved when required.

• - Der Erhalt einer (bestimmten) Lognachricht auf einem (bestimmten) Logkanal.
• - Eine konfigurierbare Boole'sche Verknüpfung mehrerer Filterbedingungen, die auf die im Ringpuffer FR ankommenden Logdaten angewendet werden.
• - Ein Ergebnis einer Vorverarbeitung per Skript. Dies ermöglicht z.B. auf Statistiken oder Voranalysen der im Ringpuffer FR ankommenden Logdaten basierende Triggerungen.
• - „Manuelle Trigger“: Hierbei handelt es sich um einen expliziten Methodenaufruf am Ringpuffer FR (z.B. durch andere Services im Fahrzeug), der die Speicherung des aktuellen Ringpuffer-Inhalts als Schnappschuss auslöst.

Trigger conditions can be:

• - The receipt of a (specific) log message on a (specific) log channel.
• - A configurable Boolean combination of several filter conditions that are applied to the log data arriving in the ring buffer FR.
• - A result of pre-processing via script. This enables, for example, triggering based on statistics or pre-analyses of the log data arriving in the ring buffer FR.
• - “Manual trigger”: This is an explicit method call on the ring buffer FR (e.g. by other services in the vehicle), which triggers the storage of the current ring buffer contents as a snapshot.

The log data in the snapshots is preferably stored in a uniform standardized format, which in turn can be part of the AUTOSAR standard.

Through the optional use of a data collection system GDC for an entire vehicle fleet, the campaigns can be extended to vehicle fleets in order to be able to use analysis methods based on machine learning (e.g. automatic error pattern recognition, correlation with environmental events, etc.). Such analyzes can be carried out in a large data analysis system BDAS, which, for example, has several data analysis services DAS1 ... DASn (generally DAS). For this purpose, the data analysis system BDAS can access the logging files of the central data collection device DL. Customers KD, Sales VT and Quality Assurance QS can benefit from the corresponding analysis systems.

In special exemplary embodiments, it can be provided that the central evaluation of the log messages from the distributed sources is ensured by specifying a time-synchronized timestamp (synchronized time reference SRZ) and a unique identification of log messages with a source UUID. It can also be advantageous to additionally influence the filtering by using a data protection attribute in the log data. Furthermore, a selection of cyber security procedures to be applied between the concentration points can be made possible by using a security attribute in the log data. In a further advantageous embodiment of the method or system according to the invention, log data filters can be adjusted automatically or dynamically. Further advantages can be achieved when using a canonical data log and configuration data transfer format or protocol.

Reference symbol list

BDAS

large data analysis system

BE

Backend

ES

Cloud backend system

BLK

Logging concentrator

CL

Cloud

C.S

Cloud service

THE

Data analysis service

DCM

Data Collection Master

DCOM

Data collection order management

DL

Data collection facility

DP

Data pump

EW

developer

FR

Ring buffer

FZ

vehicle

GDC

Vehicle fleet data collection system

IOT

Internet of Things

KD

Customer service

KE

Campaign creator

LMS

Logging management system

LN

Local network

OTA

Wireless connection

P.S

Production system

Q1-1 ...Sqm-n

Source index

QS

quality assurance

QZ-1 ...QZ-n

Source index

RZ

Reference time

SGP

ECU software partition

SN

snapshot

SRZ

synchronized time reference

SWC

Software component

VDS

Vehicle diagnostic service

VLK

Logging concentrator

VT

distribution

Z

Central control unit

Currently

Central time base

QUOTES INCLUDED IN THE DESCRIPTION

This list of documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• US 20200219388 A1 [0004]
• DE 102017218561 A1 [0005]
• US 20200263992 A1 [0006]
• US 20200263995 A1 [0006]
• US 20200263993 A1 [0006]
• EP 3492872 A1 [0007]
• DE 102020007072 A1 [0008]

Claims (15)

Method for collecting data from multiple data sources (SWC, CS) of a data system for vehicles (FZ). - Creating a logging campaign that includes a specific filter configuration for each of the multiple data sources (SWC, CS), each containing an identifier for the respective data source (SWC, CS) and one or more filter conditions for the respective data source (SWC, CS) has, in a central unit, - automatic distribution of the logging campaign's filter configurations to each of the multiple data sources (SWC, CS), - automatic configuration of the respective data source (SWC, CS) with the specific filter configuration, - Transferring data through each data source (SWC, CS) to a central data collection device (DL) of the data system according to the respective filter configuration. Procedure according to Claim 1 , where the data system has at least two elements from the set of vehicles (FZ), cloud (CL) and terminal devices (SP), and the multiple data sources (SWC, CS) are software components of the respective element. Procedure according to Claim 1 or 2 , whereby the automatic distribution of the filter configurations is carried out by a concentration device (VLK, BLK), which splits the logging campaign so that each data source (SWC, CS) only receives that filter configuration that corresponds to its identifier. Procedure according to Claim 3 , whereby - when transmitting data from at least two of the data sources (SWC, CS), a partial data stream is sent to the concentration device (VLK, BLK), - the partial data streams are concentrated in the concentration device (VLK, BLK) to form an overall data stream, and - the overall data stream is transmitted to the central data collection device (DL). Procedure according to Claim 3 or 4 , wherein the data system has at least one further concentration device (VLK, BLK) of the type mentioned in a data stream from one of the data sources (SWC, CS) to the central data collection device (DL) in addition to the concentration device (VLK, BLK). Method according to one of the preceding claims, wherein - the logging campaign has at least one element of preprocessing instructions, trigger conditions, runtimes, storage specifications and attributes in addition to the filter configurations, - the at least one element is distributed to one or more of the data sources (SWC, CS) during the automatic distribution and - the automatic configuration and transfer of the data also takes place depending on the distributed at least one element. Method according to one of the preceding claims, wherein the filter conditions are selected from criticality levels of the data, logging categories, data protection categories, security categories and value range specifications. Method according to one of the preceding claims, wherein the data system has a vehicle (FZ), the logging campaign is transmitted wirelessly from the central unit to the vehicle (FZ), and in the vehicle (FZ) the distribution of the filter configurations to software components as Data sources (SWC, CS). Method according to one of the preceding claims, wherein the data system has a backend (BE) with cloud (CL), the central unit is integrated into the backend (BE), the logging campaign from the central unit to a backend system of the cloud (CE) is transferred, and the filter configurations are distributed to several cloud services as data sources (SWC, CS) in the backend system. Method according to one of the preceding claims, wherein the data system has a vehicle (FZ), the vehicle (FZ) has a ring buffer (FR), and for transmitting the data the ring buffer (FR) is read out according to a trigger condition of the logging campaign. Method according to one of the preceding claims, wherein all data sources (SWC, CS) of the data system provide their data to be transmitted with a time stamp which is based on a common time base. Method according to one of the preceding claims, wherein all data sources (SWC, CS) of the data system provide their data to be transmitted with an identifier of the respective data source (SWC, CS) that is unique within the data system. Procedure according to one of the Claims 3 until 5 , wherein filtering and/or preprocessing of data takes place in the concentration device (VLK, BLK) according to the logging campaign. Method according to one of the preceding claims, wherein the data system has a vehicle (FZ) with several control devices (SGP-1 ... SGP-m) and a central control device (Z), several data sources (SWC, CS) of the data system on the several control devices (SGP-1 ... SGP-m) are distributed, and the central control device (Z) takes over the automatic distribution of the filter configurations of the logging campaign to the control devices (SGP-1 ... SGP-m). System for collecting data from multiple data sources (SWC, CS). - a central unit, - at least one vehicle (FZ), - the multiple data sources (SWC, CS) distributed across the central unit and the at least one vehicle (FZ), - a management device (LMS) in the central unit for creating a logging campaign, which includes a specific filter configuration for each of the multiple data sources (SWC, CS), each of which has an identifier for the respective data source (SWC, CS) and one or more filter conditions for the respective data source (SWC, CS), - a concentrator (VLK, BLK) for automatically distributing the filter configurations of the logging campaign to each of the multiple data sources (SWC, CS), where - Each data source (SWC, CS) is designed to automatically configure itself with the specific filter configuration and to transmit data to a data collection device of the central unit in accordance with the respective filter configuration.

Images