GB2598109A

GB2598109A - A method for transmitting at least one data package from a central electronic computing device to at least one electronic computing device of a motor vehicle

Info

Publication number: GB2598109A
Application number: GB2012862.5A
Authority: GB
Inventors: Nunes Rodrigo; Spatzier Thomas; Brouwer Markus; Schober Markus
Original assignee: Daimler AG
Current assignee: Mercedes Benz Group AG
Priority date: 2015-07-29
Filing date: 2020-08-18
Publication date: 2022-02-23
Also published as: GB202012862D0

Abstract

The invention relates to a method for transmitting at least one data package (12) from a central electronic computing device (14) to at least one electronic computing device (16) of at least one motor vehicle (18) by a system (10), wherein the data package (12) is stored in a storing device of the central electronic computing device (14) and the stored data package (12) is transmitted to the electronic computing device (16) of the motor vehicle (18), wherein the data package (12) is stored by using container technology and the containerized data package (12) is transmitted to the electronic computing device (16) of the motor vehicle (18). Furthermore, the invention relates to a corresponding system (10).

Description

A METHOD FOR TRANSMITTING AT LEAST ONE DATA PACKAGE FROM A CENTRAL ELECTRONIC COMPUTING DEVICE TO AT LEAST ONE ELECTRONIC COMPUTING DEVICE OF A MOTOR VEHICLE, AS WELL AS A SYSTEM

FIELD OF THE INVENTION

[0001] The invention relates to the field of automobiles. In particular, the invention relates to a method for transmitting at least one data package from a central electronic computing device to at least one electronic computing device of at least one motor vehicle by a system, as well as to a corresponding system.

BACKGROUND INFORMATION

[0002] From the state of the art it is known that the electronic computing device of a motor vehicle, which may also be referred to as a head unit, runs for example an infotainment system, including a navigation system, a digital radio tuner, and applications such as parking and search applications. This software is flashed as a monolith when a motor vehicle rolls off the factory line of a producer of the motor vehicle.

[0003] Developing an application for the head unit in the dash board of a motor vehicle requires a deep understanding of the underlying architecture, a manufacturer's hardware, and the low-level functionality of the custom hardware and its framework. According to the state of the art, changes to this software typically required recertification and requalification of the whole monolith. This is a time-consuming process, involving rigorous quality assurance and physical test drives.

[0004] Furthermore, it is known that the development model poses another challenge. As with any connected loT (Internet of Things) device, connectivity restrictions limit the types of applications that can be offered. Besides the infotainment system, other vehicle applications use controlled interfaces to interact with a vehicle's sensors and systems to monitor functions, such as gas level, speed, and GPS location. These applications were created by several development teams, which may also be referred to as third-party suppliers, who have to coordinate their efforts closely. Release timelines were hampered by the dependencies among the applications created by the external specialists, those built by the head unit manufacturer teams, and others created by domain-specific teams inside the company.

[0005] US 10180823 B2 discloses systems and methods related to creating applications using building blocks linked together with metadata. A user interface can enable a user to create an application. Creating the application can include defining a new building block configured to generate output data The new building block can include one or more system building blocks and the metadata associated with the existing building blocks. For example, a building block can include at least one input/output feature configured to receive inputs and/or generate outputs. Further, the existing building block can correspond to a data structure including external input/output features. The new building block can be linked to an existing building block by mapping an external input/output feature of the existing building block to an open input/output feature of the new building block. The mapping can be stored in metadata associated with the new building block.

[0006] With the limitations according to the state of the art, teams for developing connected cars updated its software infrequently in a bundle released one or two times a year. Therefore, there is a need in the art for a more efficient method and/or a system for development of software in the motor vehicle.

SUMMARY OF THE INVENTION

[0007] It is an object of the invention to provide a method as well as a system whereby a more frequent transmission of a data package to an electronic computing device of a motor vehicle may be provided.

[0008] This object is solved by a method as well as a system according to the independent claims of the present invention. Advantageous embodiments thereof are presented in the dependent claims.

[0009] One aspect of the invention relates to a method for transmitting at least one data package from a central electronic computing device to at least one electronic computing device of at least one motor vehicle by a system, wherein the data package is stored in a storing device of the central electronic computing device, wherein the motor vehicle checks whether the motor vehicle has already stored the data package, and if the motor vehicle has not stored the data package the stored data package is transmitted from the central electronic computing device to the electronic computing device of the motor vehicle.

[0010] In one aspect of the invention, the data package is stored by using the container technology and the containerized data package is transmitted to the electronic computing device of the motor vehicle.

[0011] By using the container technology, a more frequent transmission of the at least one data package to the electronic computing device of the motor vehicle may be realized. In other words, the invention relates to a microservices-based architecture that relies on containers to fetch and push data packages, in particular application updates, at the scale of the Internet of Things (loT). Therefore, an overall architecture and frame work for the electronic computing device of the motor vehicle, which may also be referred to as a head unit of the motor vehicle, is provided, to allow containers to be integrated with the existing native software components. These containers enable for example developers to quickly and iteratively develop and deploy production ready data packages, and decoupling those data packages from the major head unit fresh-up cycles. By utilizing container technology and developing a framework and development platform, the method enables the central electronic computing device to deliver new and updated applications to the electronic computing device of the motor vehicle more frequently than it does in the state of the art and independently of major manufacturing releases. These containers may for example run in a sandbox, with controlled isolation, for security and stability of the platform.

[0012] It is obvious, that the data package may be transmitted to a plurality of motor vehicles. Furthermore, each motor vehicle may comprise a plurality of electronic computing devices, wherein the plurality of electronic computing devices may be updated by the method according to the invention.

[0013] In one embodiment, the data package is developed by using container technology. Therefore, the developers of the data package are using container technology as well. The data package is developed by container technology and the developed data package is stored by container technology on the central electronic computing device. The containerized stored data package is then transmitted to the electronic computing device of the motor vehicle.

[0014] In another embodiment, the data package may be developed by a third-party supplier. Because of the container-based platform, third-party suppliers may develop individual applications and then deliver them to the central electronic computing device in a secure and compact way, for example but not limited to over the air technology, using any programming language of their choice.

[0015] In another embodiment, the data package is stored and computed in a sandbox of the electronic computing device of the motor vehicle. Therefore, it is possible, that the data package runs in a controlled isolation system, whereby security and stability of the platform may be raised. The sandbox is a security mechanism for separating running programs, usually in an effort to mitigate system failures or software vulnerabilities from spreading. It is used to execute untested or untrusted programs or code, possibly from unverified or untrusted third-party suppliers, users or websites, without risking harm to the host machine or operating system. A sandbox at least provides a tightly controlled set of resources for guest programs to run in, such as storage and memory scratch space. The sandbox is implemented by executing the software restricted operating system environment, thus controlling the resources that a computing process may use. In particular, this sandbox is implemented in the head unit of the motor vehicle. Therefore, a reliable way for deploying the data package on the electronic computing device of the motor vehicle may be realized.

[0016] In a further embodiment the data package is provided as an application for the electronic computing device of the motor vehicle. In particular connected cars use a plurality of applications. These applications may be updated infrequently. Furthermore, a user of the motor vehicle may choose different applications from a server, in order to personalize the electronic computing device of the motor vehicle. These applications and updates for these applications may then be provided as the containerized data package and may be updated independently from an update of the operation system of the electronic computing device of the motor vehicle.

[0017] In another embodiment the containerized data package is more frequently transmitted to the electronic computing device of the motor vehicle than an operation system update of the electronic computing device of the motor vehicle. Therefore, a speeding up of the development and the deployment of the data package may be realized, whereby the data package is more frequently transmitted to the electronic computing device of the motor vehicle to implement continuous integration (Cl) and continuous deployment (CD) practices inside the car.

[0018] In another embodiment the central electronic computing device is provided as cloud-native central electronic computing device, wherein a plurality of different data packages may be provided in a plurality of different registries of the cloud-native central electronic computing device. This embodiment ensures that the deployment of the new data packages works smoothly, and images are stored as close as possible to the fleet of the plurality of motor vehicles.

[0019] In a further embodiment the containerized data package is transmitted via a mobile network from the central electronic computing device to the electronic computing device of the motor vehicle. The containerized data package is in particular a small data package, therefore the containerized data package may be transmitted via a mobile network, whereby a more frequent transmitting of data packages may be realized.

[0020] Another aspect of the invention relates to a system for deploying a data package from a central electronic computing device to an electronic computing device of a motor vehicle, wherein the data package is provided as a containerized data package, and wherein the system is configured to perform a method according to the preceding aspect. In particular, the method is performed by the system.

[0021] Advantageous forms of the method are to be regarded as advantageous forms of the system. Therefore, the system comprises means for performing the method according to the preceding aspect.

[0022] Further advantages, features, and details of the invention derive from the following description of preferred embodiments as well as from the drawings. The features and feature combinations previously mentioned in the description as well as the features and feature combinations mentioned in the following description of the figures and/or shown in the figures alone can be employed not only in the respectively indicated combination but also in any other combination or taken alone without leaving the scope of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The novel features and characteristics of the disclosure are set forth in the appended claims. The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and together with the description serve to explain the disclosed principles. In the figures, the same reference signs are used throughout the figures to refer to identical features and components. Some embodiments of a system and/or method in accordance with embodiments of the present subject matter are now described below, by way of example only, and with reference to the accompanying figures.

[0024] Fig. 1 a schematic side view of an embodiment of the system.

[0025] Fig. 2 a schematic block diagram according to an embodiment of the system.

[0026] In the figures the same elements or elements having the same function are indicated by the same reference signs.

DETAILED DESCRIPTION

[0027] In the present document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

[0028] While the disclosure is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will be described in detail below. It should be understood, however, that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternatives falling within the scope of the disclosure.

[0029] The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion so that a setup, device or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus preceded by "comprises" or "comprise" does not or do not, without more constraints, preclude the existence of other elements or additional elements in the system or method.

[0030] In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense.

[0031] Fig. 1 shows a schematic side view of an embodiment of a system 10 for transmitting a data package 12 from a central electronic computing device 14 to an electronic computing device 16 of a motor vehicle 18, wherein the data package 12 is provided as a containerized data package 12.

[0032] As shown in Fig.2 the central electronic computing device 14 is provided as a cloud-native central electronic computing device 28. Furthermore, it is shown, that the containerized data package 12 is transmitted via a mobile network 20 from the central electronic computing device 14 to the electronic computing device 16 of the motor vehicle 18.

[0033] In an embodiment, the data package 12 is developed by using the container technology. Furthermore, the data package 12 is developed by at least one third-party supplier 22. In this embodiment, it is shown that two third-party suppliers 22 develop the data package 12. The data package 12 is in particular stored and computed in a sandbox 24 of the electronic computing device 16 of the motor vehicle 18. The data package 12 may be provided as an application for the electronic computing device 16 of the motor vehicle 18.

[0034] Fig. 2 further shows a schematic block diagram according to an embodiment of the method. In particular a metadata configuration system and the vehicle delivery platform is shown in Fig. 2. In particular, an overall architecture and framework for the electronic computing device 16 of the motor vehicle 18 is shown in this embodiment in order to allow containers to be integrated with the existing native software components.

S

Containers enable the central electronic computing device 14 and its developers, in particular the third-party suppliers 22, to quickly and iteratively develop and deploy production-ready data packages 12 independently of data packages 12 from the major electronic computing device fresh-up cycles of the motor vehicle 18. By using container technology and developing a framework and development platform, the central electronic computing device 14 is enabled to deliver new and updated data packages 12 to the electronic computing device 16 of the motor vehicle 18 quicker than it does in the state of the art and independently of major manufacturing releases. These containers run in the sandbox 24 of the electronic computing device 16, with controlled isolation, for security and stability of the platform.

[0035] A full set of tools and cloud infrastructure to support the lifecycle and bootstrapping, abstracting the complicated integration with the electronic computing device 16 and the vehicle sensors is also provided.

[0036] Therefore, an improvement of the concept-to-market of the electronic computing device 16 is provided by removing entry barriers to development teams and making it easy and more intuitive to focus on the functionality only instead of system details. Therefore, an increase of the innovation speed and delivery of the software by sending smaller, isolated and more frequent updates to the electronic computing device 16 of the motor vehicle 18, minimizing certification time and confining changes to a containerized data package 12 that runs in the sandboxed area of the electronic computing device 16 of the motor vehicle 18 is provided. Therefore, a decouple development process from release management process and certification by utilizing feature toggles that allow the development teams to move faster without impacting the quality of software delivered may be realized.

[0037] Fig. 2 shows the updating process according to a vehicle customer configuration 26. The motor vehicle 18 is connected to the central electronic computing device 14. The central electronic computing device 14 is in particular provided as a cloud-native central electronic computing device 28. At a web page 30 the customer can ask for different data packages 12 which may be stored in different registries 32. The data package 12 may then be transmitted to the motor vehicle 18 and stored in the electronic computing device 16 of the motor vehicle 18. In more details, containers may offer several key advantages. With the cloud-native central based containerized platform, the third-party suppliers 22 may develop individual applications and then deliver them in a secure and compact way via a mobile network 20 using any programming language of their choice. The container solution may also provide a software-only solution, which frees the third-party suppliers 22 from the timelines that constrain the hardware teams. The developed codes may be designed and tested as independent micro services containing specific functions.

[0038] The container-based motor vehicle 18 service is designed to be working when the driver of the motor vehicle 18, in particular the customer, may start the motor vehicle 18. Then the electronic computing device 16 of the motor vehicle 18 sends a request using the mobile network 20 to connect to the service across the mobile network 20. The central electronic computing device 14 supports two platforms, one for containerized application creation and the other for application configuration and delivery to the motor vehicle 18. The central electronic computing device 14 runs the key service, for example the orchestration service is the containerized platform for the electronic computing device 16. Furthermore, the source code repository service is an abstraction of the Git repo providers. The Cl service acts as the pipeline management system by abstracting the Cl/CD providers and establishing the applications initial pipeline. The feature configuration service abstracts the tools that provide feature toggling and that are used to provision the project and resources for a new application of the electronic computing device 16 of the motor vehicle 18.

[0039] On the development side, the data package 12 is also constructed as a container image. The image is pushed to the private registry of the central electronic computing device 14. The data package metadata and configuration details, including deployment specifications and pod specifications, are pushed to the central electronic computing device 14 and made available for use in the testing stage. In the motor vehicle 18 a head unit orchestration agent compares an update request to the versions already owned by the driver, pulls the correct image from the closest registry 32 and the registry 32 sends it back to the motor vehicle 18.

[0040] In the development process of the data package 12, an API gateway may be used, a component of an API Management, accepts API calls and routes them to the back ends, effectively decoupling the back-end APIs from the micro services. Furthermore, the backend APIs augment the functionality of the containerized application and secure any external communication needed from the head unit of the motor vehicle 18 during the application execution, effectively preventing applications from reaching out to external non-approved URLs/endpoints that are outside of the control of a manufacturer of the motor vehicle 18. The API gateway also verifies the certificates and API keys. All API Management endpoints and any external endpoints of the central electronic computing device 14 declared in a containerized application configuration must have a specific domain and needs to be certified by a specific certification authority.

[0041] During the development of the data package 12 in a first phase a build release is realized. When a developer, in particular the third-party supplier 22, commits a change, the pipeline of the central electronic computing device 14 is triggered to start a build in the provisioned project process. The container is tagged with the new version and pushed to the private registry. In particular, the build pipeline generates two container images of the same application version, wherein one is suitable to run in an architecture, which is compatible with the vehicle's head unit and test benches hardware, and another one is suitable to run in architectures for the emulator. So, when a "pull" of this image is started from the motor vehicle 18 or a test bench, the image version for the motor vehicle 18 is automatically selected. If the pull is started from the emulator, which simulates the electronic computing device of the motor vehicle 18 in a computer or a virtual machine in the cloud, the version for the emulator is automatically selected. If required, the container is also pushed to separate container registry instances in different regions worldwide, which is shown with the reference sign 32. In a second step the deployment to integration is realized. The pipeline pushes the manifests and associated images, one for each build, to the quality team's private registry. At the same time, the new candidate version is signed and registered with the central electronic computing device 14.

[0042] In a third phase, the release is tested. The qualification team is notified to begin the integration testing using an emulator for the electronic computing device 16 of the motor vehicle 18 or in a test vehicle. If the application does not fit the requirements of the qualification team, the application may be sent back to the developer. A test bench may be considered as a test vehicle, which includes the necessary hardware for the vehicle's computing unit in a test lab.

[0043] In a fourth phase the data package 12 is transmitted to a release management. The pipeline triggers an approval process using a manual gate. This manual gate may be only accessible to a release manager, and will add an electronic signature to the application manifest/configuration that is required by the motor vehicle computing unit of customer cars. This mechanism prevents test applications, unapproved versions or any containerized applications supported by the framework to be obtained by a customer vehicle to run without the "stamp of approval" from the manufacturer. The approved build is pushed to the production registry, and the version configuration updates are stored in the central electronic computing device 14.

[0044] The use of containers also simplifies testing for developers, who previously had no way to preview an application's appearance or behavior. Individual functional components were too complex to emulate with software and interacted in complex ways. Developers had to ship a new software build to get it integrated into the head unit image and then flash the image onto a hardware device. If the testing process uncovered a bug, the whole cycle started over, leading to weeks of delay. According to the invention, the developers may now build self-contained applications, they may deploy containers into the platform without needing to wait to flash the complete hardware device on scheduled cycles. Another advantage is that by running the emulated vehicle computing unit in the cloud, the development teams may test their applications in a plurality of vehicle configurations and older released versions of the overall software monolith, still deployed to customer vehicles on the road. This is now be maintained in a central computing place available on-demand in the cloud, and maintained by a single team. An emulator that runs on the central electronic computing device 14 enables developers to run the whole system locally. Individuals may test their applications without needing access to hardware test benches, and may also provide large combinations of input parameters, simulating conditions that their application would encounter when interacting with the vehicle functions provided by a real automotive computing unit, like gas level, speed, or geolocation.

[0045] After these automated tests are run in simulated vehicles in the cloud or locally on an emulator of a developer, developers may map their application to a test car. The test car's electronic computing device connects to the cloud during vehicle ignition, locates the newly assigned application, retrieves its metadata, pulls the described container image, and starts the application. Furthermore, the emulated vehicle computing units allow developer teams to start building applications for future generation of motor vehicles 18, before the complete hardware details of those future units are formalized and the initial hardware samples are available in test benches or test vehicles [0046] In particular, the container images and the metadata need to be physically near the motor vehicles during deployment. Therefore, the web page 30 requests to the nearest data center in order to ensure that the deployment works smoothly and the images are stored as close as possible to the fleet.

[0047] Furthermore, the container features may be monitored by the central electronic computing device 14. The central electronic computing device 14 may monitor the performance of the container workloads deployed on the motor vehicle 18 and collects memory and processor metrics from controllers, nodes, and containers. Plus, when a developer enables monitoring in a cluster, the add-on for the motor vehicle 18 monitoring automatically kicks in.

[0048] In particular, Fig. 1 and Fig. 2 show a rapid development and continuous deployment of a head unit edge application.

Reference Signs system 12 data package 14 central electronic computing device 16 electronic computing device 18 motor vehicle mobile network 22 third-party supplier 24 sandbox 26 vehicle and customer configuration 28 cloud-native central electronic computing device web page 32 registry

Claims

CLAIMS1. A method for transmitting at least one data package (12) from a central electronic computing device (14) to at least one electronic computing device (16) of at least one motor vehicle (18) by a system (10), wherein the data package (12) is stored in a storing device of the central electronic computing device (14), wherein the motor vehicle (18) checks whether the motor vehicle (18) has already stored the data package (12), and if the motor vehicle (18) has not stored the data package (12) the stored data package (12) is transmitted from the central electronic computing device (16) to the electronic computing device (16) of the motor vehicle (18), characterized in that the data package (12) is stored by using container technology and the containerized data package (12) is transmitted to the electronic computing device (16) of the motor vehicle (18).
2. A method according to claim 1, characterized in that the data package (12) is developed by using the container technology.
3. A method according to claim 2, characterized in that the data package (12) is developed by a third-party supplier (22).
4. A method according to any one of claims 1 to 3, characterized in that the data package (12) is stored and computed in a sandbox (24) of the electronic computing device (16) of the motor vehicle (18).
5. A method according to any one of claims 1 to 4, characterized in that the data package (12) is provided as an application for the electronic computing device (16) of the motor vehicle (18).
6. A method according to any one of claims 1 to 5, characterized in that a containerized data package (12) is more frequently transmitted to the electronic computing device (16) of the motor vehicle (18) than an operation system update of the electronic computing device (16) of the motor vehicle (18).
7. A method according to any one of claims 1 to 6, characterized in that a newly developed data package (12) from a third-party supplier (22) is tested in a virtual environment of the central electronic computing device (14) and/or in a test motor vehicle before being transmitted to the electronic computing device (16) of the motor vehicle (18).
8. A method according to any one of claims 1 to 7, characterized in that, the containerized data package (12) is transmitted via a mobile network (20) from the central electronic computing device (14) to the electronic computing device (16) of the motor vehicle (18).
9. A method according to claim 1, characterized in that the central electronic computing device (14) is provided as a cloud-native central electronic computing device (28), wherein a plurality of different data packages (12) may be provided in a plurality of different registries (32) of the cloud-native central electronic computing device (28).
10. A system (10) for transmitting a data package (12) from a central electronic computing device (14) to an electronic computing device (16) of a motor vehicle (18), wherein a containerized data package (12) is transmitted to the electronic computing device (16) of the motor vehicle, (18), and wherein the system (10) is configured to perform a method according to any one of claims 1 to 9.