Method for updating applications of an electronic motor vehicle control unit

Abstract

The invention relates to a method (100) for updating an application (2) of an electronic motor vehicle control unit (1), comprising the following steps: converting (101) the application (2) of the electronic motor vehicle control unit (1) into a bytecode representation (3) of the application; modifying (102) a bytecode representation (3) of the application program at least with respect to at least one input and / or output interface thereof, the at least one input and / or output interface enabling communication with at least one other application program (2 ') and / or with at least one other electronic motor vehicle control unit (1'); -deploying (103) a bytecode representation of the application (3) on the electronic motor vehicle control unit (1) and / or at least one other electronic motor vehicle control unit (1 '). The invention also relates to a computer program, an apparatus and a storage medium for this purpose.

Description

Technical Field

[0001] The invention relates to a method for updating an application program of an electronic motor vehicle control unit. The invention also relates to a computer program, a device and a storage medium for this purpose. Background Art

[0002] Modern vehicles include a large number of different hardware and software components. It is often the case that software components are designed specifically for the underlying hardware platform, which can make the software components very inflexible. Therefore, a long-term goal in the field of motor vehicles in particular is to make software components independent of the deployment and the underlying hardware platform, which has led to the standardization of the layered software architecture AUTOSAR, for example. In AUTOSAR, the Virtual Function Bus (VFB) scheme can provide infrastructure independence (e.g., hardware and deployment independence) at design time. However, after compilation and deployment, software components may be tied to their hardware platform and the communication between components may be hard-coded. In modern cars, software updates are more frequent and additional software may be installed throughout the life cycle of the car, so a more flexible approach may be needed in these modern cars to change the deployment in a just-in-time manner (On-the-Fly-Weise) or to update functionality incrementally (inkrementell).

[0003] Thinking further, offloading computational loads to roadside infrastructure may also require greater flexibility in the deployment of components. Adapting existing software, especially software written for classic AUTOSAR, to a modern, future-proof, dynamic ecosystem can be challenging and not easy. The concept of software component clusters in AUTOSAR in particular has attempted to reduce the effort of recompiling and redeploying updated code bases. However, it may further require recompiling the entire software cluster, including the basic software components (BSW) in the cluster. In addition, reprogramming a single software cluster may require restarting the entire ECU, as the behavior of the cluster may not be guaranteed during reprogramming of the cluster. In short, existing solutions do not particularly support updates during runtime.

[0004] Existing classic AUTOSAR applications can thus be bound to the hardware platform and use standard interfaces that are fixed after compilation. Changes to the deployment, which may also include remapping of the application to other ECUs, may require a complete recompilation and update of the components and ECUs involved.

[0005] The software stack of AUTOSTAR may rely heavily on the C implementation language. Writing applications in different programming languages ​​(such as Rust) and incrementally updating multiple parts of the software can be challenging and time-consuming. Summary of the invention

[0006] According to aspects of the invention, a method having the features of claim 1, a computer program having the features of claim 8, a data processing device having the features of claim 9 and a computer-readable storage medium having the features of claim 10 are provided. Further features and details of the invention are disclosed in the respective dependent claims, the description and the drawings. Features and details described in the context of the method according to the invention also correspond to the computer program according to the invention, the data processing device according to the invention and the computer-readable storage medium according to the invention, and vice versa in each case.

[0007] According to one aspect of the present invention, a method for updating an application program of an electronic motor vehicle control unit is provided, wherein the method comprises the following steps:

[0008] -Converting an application program of an electronic motor vehicle control unit into a bytecode representation of the application program (Bytecode- ),

[0009] - modifying the bytecode representation of an application at least with respect to at least one input and / or output interface thereof, wherein said at least one input and / or output interface enables communication with at least one other application and / or with at least one other electronic motor vehicle control unit,

[0010] - installing the bytecode representation of the application on the electronic motor vehicle control unit or on at least one further electronic motor vehicle control unit.

[0011] In the context of the present invention, an application may be a software module that provides a function in a vehicle, such as adaptive speed regulation. The application may be a software module according to the standardized software framework AUTOSAR. The application may be provided on an electronic motor vehicle control unit. The application may be executed at runtime of the electronic motor vehicle control unit. Converting the application to a bytecode representation may be a compilation of the application, in particular to provide a WebAssembly bytecode. The modification may also include providing at least one new function or modifying an existing function of the bytecode representation of the application. In an alternative, the bytecode representation is deployed on an edge computing device and / or a vehicle computer and / or a roadside computing node and / or a cloud service, instead of an electronic motor vehicle control unit and / or at least one other electronic motor vehicle control unit. The method may be advantageous in providing an update of the application without having to update the electronic motor vehicle control unit as a whole, so that, for example, basic software components according to AUTOSAR do not have to be reinstalled. In addition, the application may advantageously become portable (migrierbar) in terms of its bytecode representation, because the bytecode representation may be irrelevant (agnostisch) with respect to the corresponding operating system and / or the corresponding hardware in which the application is deployed.

[0012] Possibly, the method further comprises the following steps:

[0013] - generating an access module, wherein the access module provides at least one input and / or output interface and a communication channel in order to enable communication with at least one other application and / or with at least one other electronic motor vehicle control unit by means of the at least one input and / or output interface and the communication channel.

[0014] The access module can advantageously enable channel-based communication between applications, where the applications can be in the same runtime or in a remote runtime, such as on another electronic motor vehicle control unit. Multiple channels can abstract the underlying communication mechanisms from the application logic to advantageously improve portability. The at least one input and / or output interface may be a WebAssembly System Interface (WASI), or in other words, a WebAssembly system interface may be used to provide at least one input and / or output interface. In particular, WASI is an application programming interface (API) designed to provide access to an operating system interface.

[0015] In another example, the method further includes the following steps:

[0016] - executing the application and the bytecode representation of the application to provide output of the application and output of the bytecode representation of the application,

[0017] - validating the bytecode representation of the application program based on a comparison of the output of the bytecode representation of the application program with the output of the application program,

[0018] The deployment is performed using a verified bytecode representation of the application.

[0019] Not only the application but also the bytecode representation of the application can be executed at runtime of the electronic motor vehicle control unit. The verification can advantageously check whether the bytecode representation of the application can provide the same functionality as the application by comparing these outputs. The verification can be performed by a verification component created during the conversion, since it may depend on the specific converted bytecode representation. In one example, the execution of the deployment depends on the verification result of the verification. The verification result can be positive if the output of the bytecode representation of the application is identical to the output of the application or deviates only within a defined threshold. The deployment can only be performed if the verification result is positive.

[0020] The bytecode representation of the application can also be executed at runtime on a data processing unit separate from the electronic motor vehicle control unit, in particular on a vehicle computer, a roadside computing node or a cloud service. This can be advantageous in the sense that additional computing power can be provided by the separate data processing unit while also relieving the electronic motor vehicle control unit of the computing workload required to execute the bytecode representation of the application.

[0021] Possibly, the method may further comprise the following steps:

[0022] - define a threshold for the deviation of the output of the bytecode representation of the application relative to the output of the application,

[0023] - If the output of the representation of the bytecode of the application deviates from the output of the application by less than a defined threshold, then the bytecode representation of the application is verified.

[0024] The threshold may advantageously be defined according to specific requirements or implementations of the electronic motor vehicle control unit.If no threshold is defined, the output of the bytecode representation of the application and the output of the application must be identical in order to validate the bytecode representation of the application.

[0025] In another example, the method further includes the following steps:

[0026] - Preferably initiating feedback to the user, wherein the feedback indicates the result of the validation.

[0027] Feedback to the user may be advantageous in that the user may react accordingly to the result, for example by initiating countermeasures or by at least temporarily discarding the bytecode representation of the application. The feedback may be provided on a user interface.

[0028] Modifying the bytecode representation of an application may also include the following steps:

[0029] - modifying the bytecode representation of the application to provide: explicit communication, in which case data is exchanged via shared memory or global variables,

[0030] implicit communication, in which case data is buffered during execution of an application and / or a bytecode representation of an application, and / or

[0031] Time-controlled communication in which data are transmitted directly between the electronic motor vehicle control unit and at least one other electronic motor vehicle control unit.

[0032] Explicit, implicit and time-controlled communication may be advantageous in order to provide that the bytecode representation of the application complies with the communication semantics defined by AUTOSAR.

[0033] In another aspect of the invention, a computer program, in particular a computer program product, may be provided, comprising instructions which, when executed by a computer, cause the computer to perform the method according to the invention. Thus, the computer program according to the invention may have the same advantages as those described in detail with reference to the method according to the invention.

[0034] In another aspect of the invention, a device for data processing designed to perform the method according to the invention may be provided. As the device, for example, a computer may be provided that executes a computer program according to the invention. The computer may include at least one processor that can be used to execute the computer program. In addition, a non-volatile data memory may be provided, in which the computer program may be stored and by which the computer program may be read from the non-volatile data memory for execution.

[0035] According to another aspect of the present invention, a computer readable storage medium may be provided, comprising a computer program and / or instructions according to the present invention, which, when executed by a computer, cause the computer to perform the steps of the method according to the present invention. The storage medium may be designed as a data storage device, such as a hard disk and / or a non-volatile memory and / or a memory card and / or a solid state drive. For example, the storage medium may be integrated into a computer.

[0036] Furthermore, the method according to the present invention may be realized as a computer-implemented method. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Further advantages, features and details of the present invention will become clear from the following description, in which embodiments of the present invention are described in detail with reference to the accompanying drawings. In this regard, the features mentioned in the claims and the description may be essential to the present invention individually or in any combination. Among them:

[0038] Figure 1 The method, computer program, storage medium and device according to the embodiment of the present invention are shown.

[0039] Figure 2 A schematic diagram showing a plurality of electronic motor vehicle control units according to an embodiment of the invention is shown. DETAILED DESCRIPTION

[0040] Figure 1 A computer program 20, a storage medium 15 and an apparatus 10 according to an embodiment of the invention are shown.

[0041] Figure 1 A method 100 for updating an application 2 of an electronic motor vehicle control unit 1 according to an embodiment of the invention is also shown. In a first step 101, the application 2 of the electric vehicle control unit 1 is converted into a bytecode representation 3 of the application. In a second step 102, the bytecode representation 3 of the application is modified at least with respect to at least one of its input and / or output interfaces. The at least one input and / or output interface enables communication with at least one other application 2' and / or with at least one other electronic motor vehicle control unit 1'. In a third step 103, the bytecode representation 3 of the application is deployed on the electronic motor vehicle control unit 1 and / or at least one other electronic motor vehicle control unit 1'.

[0042] Figure 2A schematic diagram of an electronic motor vehicle control unit 1 and a separate data processing unit 6 according to an embodiment of the present invention is shown. The electronic motor vehicle control unit 1 on the left includes an application 2 with a runtime environment 8, a basic software component 9, an access module 4 (also referred to as an EA (input / output) module), and a runtime 5. The motor vehicle control unit 1 on the left also includes a bytecode representation 3 of the application and a corresponding runtime 5 for executing the bytecode representation 3 of the application. The communication at runtime can be transmitted via a channel 7. The motor vehicle control unit 1' on the right only includes an application 2' with a runtime environment 8, a basic software component 9, an access module 4 (also referred to as an EA (input / output) module), and a runtime 5. A separate data processing unit 6 is shown on the right, which can be implemented as, for example, a vehicle computer, a roadside computing node, or a cloud service. On the separate data processing unit 6, a bytecode representation 3 of the application is deployed, which is executed at a runtime 5 that can communicate with the electronic motor vehicle control unit 1 via a channel 7.

[0043] In addition to the WASI system interfaces (i.e., in particular the access modules 4), the runtime environment 8 can also additionally integrate parts of the basic software components 9 as libraries and make these APIs available to the WebAssembly modules (i.e., in particular the corresponding bytecode representation 3 of the application). Thus, these WebAssembly modules can also advantageously address the AUTOSAR APIs via the runtime environment 8.

[0044] One aspect of the invention may be a method for converting an application 2 of a respective motor vehicle control unit 1 into a virtualized component, i.e. a bytecode representation 3 of the application, which can be flexibly deployed on an ECU in the vehicle and, if necessary, also on a separate data processing unit 6, such as a roadside computing node. One motivation may be that AUTOSAR software components may be tightly coupled to a specific hardware platform after compilation with a fixed deployment setup for all communication partners. This may limit the flexibility of software updates and deployment of additional software.

[0045] The following method according to an embodiment of the present invention may be embedded in a distributed edge computing ecosystem. The ecosystem may include an electronic motor vehicle control unit 1 connected via a network switch or conventional Ethernet.

[0046] Each electronic motor vehicle control unit 1 may have a runtime 5 which may provide a securely isolated sandbox execution environment, in particular with built-in security checks, which may also manage the internal resource reservation of the electronic control unit, and provide an abstraction of the operating system and the hardware. Additionally, a channel scheme may be provided to decouple the communication between the modules of the runtime 5 from the underlying implementation. Furthermore, the runtime 5 may provide control over whether a module (i.e., in particular, a bytecode representation of an application) is allowed to be published externally via an output suppression mode, wherein the output suppression mode enables the possibility of generating a passive hot standby module (passives Hot-Standby-Module), which receives input, processes the input but does not issue any confirmation instructions. The runtime 5 itself is capable of executing modules compiled into bytecode, such as WebAssembly, i.e., a bytecode representation 3 of an application.

[0047] Depending on the application requirements, an orchestrator (not shown) may be needed to deploy and manage the real-time execution modules on different runtimes 5 .

[0048] A verification component (not shown) may be used to compare the output generated by the application 2 and the bytecode representation of the application 2. This component may be generated during transformation, as it may depend on the specific bytecode representation being transformed.

[0049] An access module 4, also referred to as an EA module, may be generated during the conversion process to decouple access to values ​​of other electronic control units or values ​​of sensors and actuators from the underlying industrial fieldbus. The access module 4 may enable access to EA values ​​over runtime 5 communications.

[0050] The state transfer can be realized by a method call to the memory access API. The memory access API can package the internal memory state of the electronic motor vehicle control unit 1 as a binary blob (binary large object) and then transmit it via TCP (client (coordinator) / server (electronic control unit)) by using protocol buffers or similar basic messaging / RPC implementations.

[0051] The following method according to an embodiment of the present invention can enable the application 2 to migrate to a reliable distributed (edge) computing ecosystem that can provide advantages such as flexibility, modularity and reliability. It can realize dynamic redeployment of software, even standard software, without reimplementing software components. It can also additionally realize: incremental replacement and / or addition of software components written in modern programming languages ​​in a hardware- and OS-independent manner. The method can embed the converted AUTOSAR application 3, that is, the bytecode representation 3 of the application, in the hardware- and OS-independent execution module of the runtime 5, while still following the AUTOSAR communication semantics. Therefore, the converted and abstracted application 3 can be more flexible, easier to maintain and modular, and / or can be distributed on different edge computing nodes.

[0052] Figure 2 An overview of the proposed method is provided. In order to fully virtualize an AUTOSAR software component, i.e., an application 2, on an electronic control unit, the application 2 can be compiled into WebAssembly, i.e., a bytecode representation 3 of the application, and executed by using a runtime 5, preferably a runtime 5 with RDS capabilities, where RDS can represent a reliable distributed system (Reliable-Distributed System). For other legacy AUTOSAR components, an access module 4, or otherwise referred to as an EA module, can be generated, and the communication calls of the runtime environment 5 (RTE) of these software components can be replaced by data exchange with the access module 4. The access module 4 can implement: channel-based communication via a channel 7 between modules, i.e., an application 2 or a bytecode representation 3 of the application, on the same or remote runtime 5. Multiple channels 7 can abstract the underlying communication mechanism from the application 2 logic to improve portability. OS-based calls from application 2 can be replaced by WASI interfaces. WASI is an API designed to provide access to operating system interfaces.

[0053] In one scenario, the virtualization method according to an embodiment of the present invention can be used to move legacy AUTOSAR components, i.e., applications 2, from a dedicated electronic motor vehicle control unit 1 executed on a real-time operating system to other computing nodes, i.e., separate data processing units 6, such as vehicle computers with POSIX-based operating systems, roadside computing nodes, or cloud services, as long as the communication semantics specified by AUTOSAR are retained after redeployment. This virtualization method can also achieve: partially replace existing software with new implementations or algorithms that may be written in a language different from the original implementation language, such as Rust. In addition, completely new software components can also be integrated into the system, which may not comply with the AUTOSAR standard and implement data exchange with existing legacy code. Since the access module 4 or EA module can replace part of the communication of the runtime environment 8, it may have to follow the execution semantics of AUTOSAR. This can include, for example, explicit, implicit, and time-controlled communications.

[0054] Explicit communication means in particular: exchanging data via shared memory / global variables. In this case, the access module 4 provides the last available data point during each read process of the AUTOSAR component, ie the application 2. Write processes to variables can pass data directly to the recipient of the reliable distributed system infrastructure.

[0055] In case of implicit communication, the input data of a component can be buffered during its execution. In particular, this means that the same data is read for each access during execution. In this case, the access module 4 may need to buffer the data during the execution cycle from the first access until the module ends execution, which can be specified by a dedicated OS call in classic AUTOSAR. The next read access can re-buffer the data until the end of execution. In case of write access, the data can be buffered until the execution is completed. After ending an execution cycle, all written variables can be published to the subscribers of the written data points.

[0056] In the case of time-controlled communication, also known as logical execution time (LET), data exchange is not shared via global variables, but directly between the communication partners to ensure deterministic data age (Datenalter). An example is: data execution between a component that is executed in a cycle of 10 milliseconds, that is, an application 2 or a bytecode representation 3 of an application, and another component that is executed in a cycle of 5 milliseconds. These components can exchange data deterministically once every 10 milliseconds shortly before the next release of each component. The logic of this communication mode can be generated in the access module 4. In this example, a component that is executed once every 5 milliseconds can only send data to the 10 millisecond component every other execution. Each data point can be consumed by the buffer. For example, even if the second execution of the 5ms component completes execution before the 10ms component starts execution, the new data may not be used until the synchronization point is reached.

[0057] The above explanation of the embodiment describes the present invention in the context of examples. Of course, as long as it is technically feasible, the various features of the embodiment can be freely combined with each other without departing from the protection scope of the present invention.

Claims

1. A method (100) for updating an application program (2) of an electronic motor vehicle control unit (1), the method comprising the following steps: - converting (101) the application (2) of the electronic motor vehicle control unit (1) into a bytecode representation (3) of the application, - modifying (102) the bytecode representation (3) of the application at least with respect to at least one input and / or output interface thereof, wherein the at least one input and / or output interface enables communication with at least one other application (2') and / or with at least one other electronic motor vehicle control unit (1'), - deploying (103) the bytecode representation (3) of the application on the electronic motor vehicle control unit (1) and / or on the at least one other electronic motor vehicle control unit (1').

2. The method (100) according to claim 1, characterized in that: The method (100) further comprises the following steps: - generating an access module (4), wherein the access module (4) provides at least one input and / or output interface and a communication channel (7) so as to enable communication with the at least one other application (2') and / or with the at least one other electronic motor vehicle control unit (1') by means of the at least one input and / or output interface and the communication channel (7).

3. The method (100) according to any one of the preceding claims, characterized in that The method (100) further comprises the following steps: - executing the application (2) and the bytecode representation (3) of the application to provide an output of the application (2) and an output of the bytecode representation of the application (2), - verifying the bytecode representation (3) of the application based on a comparison of the output of the bytecode representation (3) of the application with the output of the application (2), The deploying (103) is performed using a verified bytecode representation (3) of the application.

4. The method (100) according to claim 3, characterized in that: The bytecode representation (3) of the application is executed at runtime (5) on a data processing unit (6) separate from the electronic motor vehicle control unit (1), in particular on a vehicle computer, a roadside computing node or a cloud service.

5. The method (100) according to any one of claims 3 or 4, characterized in that: The method (100) further comprises the following steps: - defining a threshold for the deviation of the output of the bytecode representation (3) of said application relative to the output of said application (2), - if the output of the bytecode representation (3) of the application program deviates from the output of the application program (2) by less than a defined threshold, then verifying the bytecode representation (3) of the application program.

6. The method (100) according to any one of claims 3 to 5, characterized in that: The method (100) further comprises the following steps: - initiating feedback, wherein said feedback indicates a result of said verification.

7. The method (100) according to any one of the preceding claims, characterized in that Modifying the bytecode representation of the application (3) further comprises the following steps: - modifying the bytecode representation of the application (3) to provide: explicit communication, in which case data is exchanged via shared memory or global variables, implicit communication, in which case data is buffered during execution of the application (2) and / or a bytecode representation of the application (3), and / or Time-controlled communication, in which data are transmitted directly between the electronic motor vehicle control unit (1) and at least one other electronic motor vehicle control unit (1').

8. A computer program (20) comprising instructions which, when the computer program (20) is executed by a computer (10), cause the computer (10) to perform the method (100) according to any one of the preceding claims.

9. A data processing device (10) comprising means for executing the method (100) according to any one of claims 1 to 7.

10. A computer-readable storage medium (15) comprising instructions which, when executed by a computer (10), cause the computer (10) to perform the steps of the method (100) according to any one of claims 1 to 7.

Images