DE102022004312A1 - Procedures for managing data products within a data network - Google Patents

Abstract

The invention relates to a method for managing data products (18) within a data network for controlling a motor vehicle (10), in which data products (18) are transmitted between different domains (D1, D2) of a vehicle architecture comprising different control devices of the motor vehicle (10), wherein a specific data product (18) is selected by a first application (22) of a first control device and by a second application (24) of a second control device from a respective data product catalog (38) of data products (18) from the respective domains (D1, D2) and is called up by means of a data product catalog management system (36) in an electronic computing device electronically coupled to the control devices. The invention further relates to an electronic computing device.

Description

The invention relates to a method for managing data products within a data network for controlling a motor vehicle. The invention also relates to a motor vehicle.

Data mesh is a data platform architecture that uses information in companies and provides users with information about where to find this information via a self-service infrastructure. This enables a new way of looking at data, namely that this data is seen as a product that can be managed, owned and made available. Data mesh makes it easy to structure large amounts of data. Data can be found more quickly, is generally accessible and secure. This type of architectural approach also helps companies make decisions and ensures a faster value chain. The main focuses of data mesh are the following: data decentralization, data distribution, data management.

From the EN 10 2021 004 346 A1 A method for setting up and maintaining a vehicle type library has already been disclosed. In this case, a vehicle type library authoring system is provided with suggestions for setting up and/or further developing the vehicle type library using artificial intelligence, with the vehicle type library authoring system being managed by domain experts who create and maintain the vehicle type library in an authoring process. In addition, the so-called "Type-based Product Line Engineering" (TPLE) method is known, which describes the basics for enabling lifelong functional updates for an OEM's vehicle fleet. A method for creating and maintaining this documentation basis is described here, with the creation being used exclusively in the OEM's backend system.

From the EN 10 2020 005 474 A1 A method for processing data in a vehicle is disclosed, wherein the data is recorded by several recording units of the vehicle and the recorded data is transmitted to a data processing system of the vehicle. The recorded data is evaluated using the data processing system of the vehicle, wherein the evaluated data is stored as context information in a storage unit of the data processing system. In addition, individual information for vehicle components and/or vehicle systems is generated using various program functions of the data processing system depending on the context information. The generated individual information is stored in the storage unit and the stored individual information is made available to the respective vehicle components and/or vehicle systems.

From the EN 10 2020 005 474 A1 A method for processing data in a vehicle using a context management system and a data processing system is disclosed, which describes an onboard synchronization of various software functions using a given two-dimensional grid, horizontally sequentially in time and vertically in the sense of an abstraction. This document builds on this concept and enables the fixed grid to be overcome and the interaction of independent domains or processes in an onboard system based on a combination of the TPLE and the data mesh approach.

The idea of the invention is to apply the data mesh approach known in a cloud environment to distributed systems within a complex, connected IoT device such as an automobile or motor vehicle. The automotive application context is described in more detail below. However, this concept can also be applied to other complex systems-of-systems determined by software functions, such as airplanes, helicopters, drones, ships, trains, construction machinery, industrial plants, spaceships, two-wheelers, etc. The challenge with this type of system is that they must both apply and integrate new innovations driven by the software, and at the same time implement all protection-relevant or safety-relevant functions reliably, robustly and in a fail-safe manner. These safety-relevant functions must exhibit deterministic behavior in all system states in order to achieve conformity with officially prescribed regulations. Due to these risks, a further challenge is that the regulations are different in different regions of the world. In terms of platform development of systems that are offered worldwide, this is another dimension of complexity that must be taken into account.

Based on the state of the art and the development of such systems, the object of the invention is to provide a method for creating a data mesh approach, in which a middle way for the satisfaction of two basic requirements is to be made possible, namely on the one hand the integration and application of innovations in compliance with protection requirements and on the other hand the application of different Different regions of the world have different regulations.

This object is achieved according to the invention by a method having the features of patent claim 1. Advantageous embodiments with favorable further developments of the invention are the subject of the dependent claims.

One aspect of the invention relates to a method for managing data products within a data network for controlling a motor vehicle, in which data products can be transmitted between different domains of a vehicle architecture comprising various control devices of the motor vehicle. This means that the data products of the respective control devices are linked to one another so that a transmission of necessary information or a necessary data set is possible.

In order to achieve the object of the invention, it is provided that a specific data product is selected by a first application of a first control device and by a second application of a second control device from a respective data product catalog of data products from the respective domains and is called up by means of a data product catalog management system in an electronic computing device electronically coupled to the control devices. This means that each linked control device has a domain which provides at least one data product, in particular a plurality of data products, which can be called up by other domains of further control devices. The data products can be made available and called up by means of the data product catalog management system. In other words, the respective control devices are coupled to the electronic computing device so that the data products can be transmitted back and forth, depending on the specification, necessity and call sequence.

An advantageous embodiment of the invention provides that a registration of the respective applications is carried out before the selection from the respective data product catalog. Through the registration, the respective applications and the respective authorization requirements as well as roles and rights are checked, assigned and saved in order to make future processes faster or to accelerate the application of the method according to the invention.

A further advantageous embodiment of the invention provides that data products are checked for specifications before they are included in the data product catalog. This checks the accuracy of the information as well as its completeness in order to substantially reduce or even completely avoid possible conflicts and error messages.

In a further advantageous embodiment of the invention, it is provided that the retrieval of specific data products by one of the applications is checked and permitted or rejected depending on rights and roles. When retrieving, the rights and roles should be checked using the default settings of the registration as well as the information provided in order to avoid or ward off unauthorized access and processes, in particular the intrusion of third parties into the system.

In yet another advantageous embodiment of the invention, it is provided that a risk assessment is carried out by calling up specific data products. In this case, the possible cases of errors are to be analyzed and evaluated, after which the classification of the errors in terms of their type and frequency initiates predetermined risk levels.

An embodiment of the invention has also proven advantageous in which a system integrity warning is triggered depending on the risk assessment.

For example, if the risk level is too high, a signal is generated and sent to an environment to provide a warning that will initiate immediate data protection measures.

An embodiment of the invention has also proven to be advantageous in which, depending on the risk assessment, a shutdown of essential system functions of the electronic computing device and/or the respective control devices is triggered. If the model of an administrative function contains rules that make it absolutely necessary for the data consumers to be registered for the specific data product and this registration does not take place or takes place in an unexpected way, a risk assessment of the situation can be carried out, which in extreme cases could lead to a system integrity warning being sent to corresponding monitoring components from the data security area. This could be an unauthorized system intervention, which in the worst case could lead to the vehicle being shut down or essential system functions being shut down.

An embodiment of the invention has also proven to be advantageous in which the specific data products are called up between the applications depending on the rights and roles that already exist. This means that after rights and roles have been assigned, it is no longer necessary to use an administrative function in the electronic computing device, since the applications of the respective control devices communicate directly with one another and a direct exchange of data is made possible or provided for.

Finally, in a further advantageous embodiment of the invention, a self-service approach is used for an at least partially automated calling of specific data products by the respective applications. This means that the applications are programmed in such a way that, depending on the settings and rights and roles, they call up the required data products without requiring renewed registration or renewed instructions, i.e. without having to search for the data product again in the data product catalog.

A further aspect of the invention relates to a motor vehicle with an electronic computing device for carrying out a method according to the invention for managing data products within a data network for controlling a motor vehicle, in which data products can be transmitted between different domains of a vehicle architecture comprising different control devices of the motor vehicle, wherein a specific data product is selected by a first application of a first control device and by a second application of a second control device from a respective data product catalog of data products from the respective domains and is called up by means of a data product catalog management system in an electronic computing device electronically coupled to the control devices.

Further advantages, features and details of the invention emerge from the following description of preferred embodiments and from the drawings. The features and combinations of features mentioned above in the description as well as the features and combinations of features mentioned below in the description of the figures and/or shown alone in the figures can be used not only in the combination specified in each case, but also in other combinations or on their own, without departing from the scope of the invention.

• 1 ein erstes Bilddiagramm zur schematischen Darstellung einer Onboard Data Mesh Architektur;
• 2 ein zweites Bilddiagramm zur schematischen Darstellung eines OCMS/Onboard Data Mesh Management System (ODMMS) mit zwei bespielhaften Applikationen;
• 3 ein drittes Bilddiagramm zur schematischen Darstellung eines Ablaufs einer Registrierung eines ersten Datenprodukts von der zweiten Applikation aus;
• 4 ein viertes Bilddiagramm zur schematischen Darstellung eines Ablaufs einer Abfrage nach Datenprodukten durch die erste Applikation; und
• 5 ein fünftes Bilddiagramm zur schematischen Darstellung einer Nutzung eines zweiten Datenproduktes durch die erste Applikation.

Showing:

• 1 a first image diagram for schematically representing an onboard data mesh architecture;
• 2 a second image diagram schematically showing an OCMS/Onboard Data Mesh Management System (ODMMS) with two example applications;
• 3 a third image diagram for schematically illustrating a process of registering a first data product from the second application;
• 4 a fourth image diagram for schematically illustrating a process of querying data products by the first application; and
• 5 a fifth image diagram for schematically representing a use of a second data product by the first application.

In the figures, identical or functionally identical elements are provided with identical reference symbols.

1 shows a first image diagram B1 for the schematic representation of an onboard data network architecture or “onboard data mesh” architecture with an integration of a TPLE approach as an administration function 12 or governance function. TPLE stands for “Type-based Product Line Engineering” (TPLE), an approach by means of which lifelong function updates are made possible for an OEM’s vehicle fleet. In other words, a local administration with a TPLE runtime system 14 is shown within a vehicle 10, whereby a local instance 16 represented as a TPLE data model with a defined version XYZ is used for this.

As an example, four domains D1, D2, D3, D4 are listed here, each of which offers several data products 18 which are in the 1 are represented as pins, and at the same time also use data products 18 from other domains. These are shown connected to one another using dashed lines. These domains D1, D2, D3, D4 are the main domains of current vehicle architectures, which together implement different functions. The vehicle architectures are assigned to a vehicle 10. As examples, the first domain D1 is responsible for body and comfort, the second domain D2 for infotainment, the third domain D3 for autonomous driving and the fourth domain D4 for driving and charging. The dashed lines show the respective links between the data products 20, whereby the data products 18 are different and belong to the respective domain D1, D2, D3, D4.

Depending on the maturity level and strategy of a particular vehicle project, an initial implementation of this concept could use exclusively analytical data as the basis for this data mesh architecture. The operational data required for the immediate function could continue to be exchanged using classic communication protocols and mechanisms. This would have the advantage that safety-relevant aspects such as real-time capability, "fail-safe operation", etc., do not have to be taken into account in the implementation. In further expansion stages, however, the entire communication bandwidth between the domains D1, D2, D3, D4 could be handled using this data mesh approach. The focus is on the additional networking of different domains D1, D2, D3, D4 and on the provision of internal data that tends to be analytical in nature and enables value-added services "on top" of the actual driving functions.

Like in the 1 As indicated, a first domain D1 for body and comfort could offer some data products 18 that provide data on the infrastructure in the interior. For example, analysis results on seat occupancy could be used in a second domain D2 for infotainment to offer passengers activating infotainment offers if the infotainment system concludes that the passengers could be bored or restless due to their seating behavior. Another possible added value function could be in a third domain D3 for autonomous driving, where it could be concluded based on the data from the first domain D1 that, for example, a particularly defensive and gentle driving maneuver strategy should be implemented because the passengers in the back seat have fallen asleep. In particular, the 1 the possible combinations of data exchange from the data products are presented.

• - die erste Applikation 22 in der Rolle als Datenkonsument und
• - die zweite Applikation 24 in der Rolle als Datenlieferant.

2 shows a second image diagram B2 for the schematic representation of a management system 20 or also (English) “Onboard Context Management System” (OSMC) or also (English) “Onboard Data Mesh Management System” (ODMMS) with two exemplary applications 22, 24,

• - the first application 22 in the role of data consumer and
• - the second application 24 in the role of data provider.

The applications 22, 24 each have a first business logic module 22a, 24a or “Business Logic Module” and a data mesh abstraction module 22b, 24b or “Data Mesh Abstraction Module”.

A database for a management function 26 was previously created in a TPLE runtime system 28 or “TPLE Runtime System” with a local instance 30 represented as a TPLE data model with an installed defined version X.Y.Z. Here, TPLE refers to a method for setting up and maintaining a vehicle type library, namely the “Type-based Product Line Engineering” method, which describes the basics for enabling lifelong function updates for an OEM’s vehicle fleet.

In a data mesh access management system 32 or in a “Data Mesh Access Management System”, a first database 34 for rights and roles or a “Rights and Roles Database” is arranged, wherein a first database 34 is formed from basic data so that the roles and rights of the respective applications 22, 24 listed here are known and locally available.

A data product catalog 38 is arranged in a data product catalog management system 36 or in a “Data Product Catalog Management System” (DPCMS), whereby this is initially dataless.

Based on the second image diagram B2 from the 2 should be in the 3 , 4 and 5 the respective procedural steps are presented.

3 shows a third image diagram B3 for schematically illustrating a process of registering the first data product 18 from the second application 24, wherein the third image diagram B3 is designed analogously to the second image diagram B2 to explain the method according to the invention.

In particular, an interaction of the components is shown in the process of a registration of the data product 18 carried out in a first step S1. The second application 24 has instantiated the abstraction module 24b, which encapsulates access to the management system 20. In a second step S2, an identity of the second application 24 is verified against the first database 34 to check the rights and roles. In a third step S3, the query is made to the TPLE runtime system 28. The local instance 30 of the TPLE data model contains all relevant data objects that are relevant for the current vehicle 10 in its current complete type configuration across all local systems, functions, components and type instances are necessary and relevant. This makes it possible, for example, to rule out that the data product 18 violates legal requirements in the current country for which the vehicle 10 was manufactured. If this check is successful, the new data product 18 is registered in the data product catalog 38 in a fourth step S4.

4 shows a fourth image diagram B4 for schematically illustrating a sequence of a query for data products 18 by the first application 22.

In a first step S1, a first query is started in which a search is carried out for available data products in the data product catalog 38 from the perspective of the first application 22. This means that the first business logic module 22a makes the first query to the abstraction module 22b, which queries for the available data products. The abstraction module 22b transmits this query to the data network access management system 32, which in turn transmits the query to the data product catalog management system 36 depending on the rights and roles from the first database 34 and checks or searches for the data products in the data product catalog 38 accordingly. The data products found, in particular a specific data product 18 of the second application 24, are thus found by the management system 20. In a fourth step S4, a check is carried out in the TPLE runtime system 28 of the administration function 26 to determine whether the first application 22 is permitted to consume this specific data product 18. If this check is positive, the first application 22 can access the specific data product 18 in the future. Such an authorization is stored.

Ideally, this specific use of the product data 18 of the second application 24 by the first application 22 is already modeled in the TPLE data model, whereby the integrity of the overall system or the management system 20 can be validated. If there are rules in the model of the administration function 26 or in the “governance” model that make it absolutely necessary for the first application 22 to register as a data consumer for the specific data product 18 and this registration does not take place or takes place in an unexpected way, this administration function 26 can carry out a risk assessment of the situation, which in extreme cases could lead to a system integrity warning being sent to corresponding monitoring components from the data security area. This could be an unauthorized system intervention, which in the worst case could lead to the vehicle 10 being shut down or essential system functions being switched off.

5 shows a fifth image diagram B5 for schematically representing use of the specific data product 18 by the first application 22. In particular, the process of using the specific data product 18 is to be shown. First, in the first step S1, the first query about the specific data product 18 is made from the first business logic module 22a to the abstraction module 22b. In a second step S2, the query is transmitted from the first application 22 directly to the second application 24, where it is first transmitted to the abstraction module 24b of the second application 24. Then, in a third step S3, the query is transmitted from the abstraction module 24b to the business logic module 24a of the second application 24. From there, the answer is transmitted directly back to the first application 22, without having to take the detour via the management system 20 in this process. It can be advantageous to use GraphQL technology when querying the specific data product 18 in the sense of a self-service approach. This must correspond to the properties of the specific data product 18 and must also be implemented accordingly at the data source in the second application 24.

List of reference symbols

B1, B2, B3, B4, B5

Image diagrams

D1, D2, D3, D4, D5

Domains

10

vehicle

12

Administrative function

14

TPLE runtime system

16

local instance

18

Data product

20

Management system/ODMMS

22

first application

22a

Business logic module

22b

Abstraction module

24

second application

24a

Business logic module

24b

Abstraction module

26

Administrative function

28

TPLE runtime system

30

local instance

32

Data Network Access Management System

34

first database

36

Data product catalog management system

38

Product catalogue

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 accepts no liability for any errors or omissions.

Cited patent literature

• DE 102021004346 A1 [0003]
• DE 102020005474 A1 [0004, 0005]

Claims (10)

Method for managing data products (18) within a data network for controlling a motor vehicle (10), in which data products (18) are transmitted between different domains (D1, D2) of a vehicle architecture comprising different control devices of the motor vehicle (10), characterized in that a specific data product (18) is selected by a first application (22) of a first control device and by a second application (24) of a second control device from a respective data product catalog (38) of data products (18) from the respective domains (D1, D2) and is called up by means of a data product catalog management system (36) in an electronic computing device electronically coupled to the control devices. Procedure according to Claim 1 , characterized in that a registration of respective applications (22, 24) is carried out before the selection from the respective data product catalogue (38). Procedure according to Claim 1 or 2 , characterized in that a check of data products (18) for specifications is carried out before they are transferred to the data product catalogue (38). Method according to one of the preceding claims, characterized in that the calling of specific data products (18) by one of the applications (22, 24) is checked and permitted or rejected depending on rights and roles. Method according to one of the preceding claims, characterized in that a risk assessment is carried out by calling up respective specific data products (18). Procedure according to Claim 5 , characterized in that a system integrity warning is initiated depending on the risk assessment. Procedure according to Claim 5 or 6 , characterized in that, depending on the risk assessment, a shutdown of essential system functions of the electronic computing device and/or the respective control devices is initiated. Method according to one of the preceding claims, characterized in that the specific data products (18) are called up depending on already existing rights and roles between the applications (22, 24). Method according to one of the preceding claims, characterized in that a self-service approach is used for an at least partially automated call of respective specific data products (18) by the respective applications (22, 24). Electronic computing device for carrying out a method according to one of the Claims 1 until 9 .

Images