Cross-processing unit migration of application execution

Abstract

The invention relates to cross-processing unit migration of application execution. Techniques and systems for migrating application execution across processing units are described herein. The first processor executes the first coordinator to initiate execution of the application. The target processor executes a second coordinator in communication with the first coordinator to migrate execution of the application to the target processor. When the target processor is ready to migrate the application, the second coordinator communicates to the first coordinator that the migration may proceed. When the first processor receives the communication, execution of the application is migrated to the target processor. The migration performed in this manner may result in better resource balancing for different drive states, save power by reducing the number of actively running processors, and / or accelerate boot time by initially running an application on a low-power real-time processor and then migrating the application to a high-power processor.

Description

Technical Field

[0001] The present invention relates to the migration of application execution across processing units. Background Art

[0002] Motor vehicles are becoming more advanced and computerized. They can include many different systems from sensor systems (e.g., vehicle entry systems, radar systems, camera systems) and driver assistance systems (e.g., adaptive cruise control (ACC), lane assist systems) to entertainment systems and mechanical systems (e.g., engine, brake system, transmission system). As computing resources expand in motor vehicles, managing these resources and the related power issues associated with the computing resources become more challenging. Summary of the invention

[0003] One or more aspects of the migration of application execution across processing units are described herein. In one aspect, a vehicle system that migrates the execution of applications across multiple processors on a vehicle includes: a first processor on the vehicle, the first processor executing multiple applications until the migration of the execution of at least one application transfers the execution of the application to a target processor having available resources for executing the application. The vehicle system includes at least one target processor, the target processor including a target processor having available resources to execute the execution of the application using the available resources. Within the system architecture, a first coordinator executes on the first processor to initiate the execution of the application and then manages the migration to the target processor. A second coordinator executes on the target processor and communicates with the first coordinator, indicating the available resources for taking over the execution of the application, and communicates with the first coordinator to migrate the execution of the application to the target processor to resume where the execution stopped on the first processor.

[0004] These and other described techniques can be performed by hardware or a combination of hardware and software executed thereon. For example, a computer readable storage medium (CRM) can have instructions stored thereon, and when the instructions are executed, a processor is configured to perform the described techniques. A system may include a device for performing the described techniques. A processor or processing unit may be a part of a system configured to perform the methods and techniques described herein.

[0005] This Summary introduces simplified concepts related to cross-processing unit migration of application execution, which is further described in the Detailed Description and Figures. This Summary is not intended to identify essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The details of the cross-processing unit migration of application execution are described in this document with reference to the accompanying drawings. The drawings may use the same reference numerals to refer to similar features and components, and numbers with hyphens refer to variations of these similar features and components. The drawings are organized as follows:

[0007] Figure 1-1 An example vehicle is shown in which application execution migration across processing units may be applied in accordance with the techniques of the present description;

[0008] Figure 1-2 An example data flow for application execution migration across processing units according to the techniques of this disclosure is shown;

[0009] Figure 2 An example abstraction layer configured for application execution migration across processing units according to the techniques of this disclosure is shown;

[0010] Figure 3 An exemplary allocation flow for application execution migration across processing units according to the techniques of this disclosure is shown; and

[0011] Figure 4 An example method for implementing application execution migration across processing units according to the technology of this disclosure is shown. DETAILED DESCRIPTION

[0012] Overview

[0013] Motor vehicles have many systems controlled by processing circuits, such as microcontrollers, electronic control units (ECUs), systems on chips (SoCs), and other processors. The system software (e.g., applications, services, device drivers) executed by these processing units have varying levels of processing requirements and power requirements. In addition, processing requirements and power requirements may change during the operation of a particular system. For example, some applications used to operate these systems may have less processing and power requirements during startup and initialization than when performing the primary functions of these applications, while other applications or systems may require more processing and power resources at startup. In addition, the total power provided to the system may need to be carefully managed during vehicle ignition or when the engine is not running (e.g., when the engine is shut down to save fuel at a traffic stop).

[0014] Many different processing circuits can be integrated into a vehicle system, including a range of hardware architectures from basic, low-power processors to complex, high-power processors. Each different type of hardware architecture typically requires its own executable binary that has been compiled for the specific type of hardware architecture. That is, an executable binary compiled for one hardware architecture may not be executable on a different hardware architecture.

[0015] One solution to the problem of computing and energy resource management is to port these applications to different hardware architectures and / or migrate applications between low-power processors and high-power processors. During low-power mode (e.g., the engine is not running, during vehicle startup), the application can be executed on the low-power processor, and then migrated to the high-power processor when the high-power processor is ready to receive the application. However, migrating applications in this way has many challenges. The main challenge is the diversity of hardware architectures integrated in modern vehicles. A common way to achieve portability between architectures is to recompile the source code for each specific type of hardware architecture. This may be problematic for quickly distributing updated applications on a variety of hardware architectures. In addition, the layout or configuration of data in memory may be different for each architecture that has been previously addressed by serializing different memory architectures into common and (usually) different portable data representations. In addition, testing each separately compiled binary file corresponding to each different hardware architecture may be time-consuming.

[0016] Another challenge is to effectively implement application migration so that each system operates as expected. A common method to achieve this is to compile the application code into bytecode in the runtime environment and execute the bytecode on a virtual machine running on each corresponding processor. This method overcomes the need to test compiled binaries for each individual hardware architecture, but there are inherent inefficiencies in running bytecode in the runtime environment, which is not ideal for embedded automotive applications. Some of these inefficiencies are related to garbage disposal and exception handling, which may be unacceptable for real-time, deterministic situations. In addition, many current migration processes, in addition to porting and testing application code for different hardware applications, usually require complex application code to serialize and deserialize the application state. This makes cross-architecture migration economically unattractive for automotive applications.

[0017] In contrast, the techniques described herein can make migration of application execution across hardware architectures (e.g., live migration) economically beneficial for embedded applications such as automotive systems. A single binary executable file (e.g., an application) can be compiled to execute on a virtual machine (e.g., a runtime environment) running on each processor (e.g., a first processor and a target processor). The binary executable file can initially be executed on a first processor (e.g., a low-power, fast-start processor) together with a first coordinator that manages the final migration of the execution of the application (e.g., transferring the contents of the processor's random access memory to the target processor). Once the target processor (e.g., a high-power, complex processor) is ready, the second coordinator running on the target processor sends a communication to the first coordinator to enable the first processor to initiate the migration (e.g., when the target processor is in a ready state for migration). The binary executable file can then be migrated to the target processor. That is, before migrating on the target processor, the execution of the application is stopped on one processor and resumed in the same state (or updated for time changes); the migration occurs without any intermediate compilation steps. In other cases, the same executable code may already reside in the memory of each processor before migration, in which case there is no need to migrate the memory portion (e.g., RAM) containing the same executable code. The state of the machine is fully specified and fully portable. The internal state may not contain information about the external environment that may be different after migration (e.g., resources such as allocated ports or file descriptors). It is sufficient to transfer stacks and memories and can remain portable across architectures. The virtual architecture creates the same data layout for both processors. In addition, applications can also be migrated from high-power processors to low-power processors. In some cases, the application can be divided into an initialization portion configured to perform initialization functions (e.g., initialization process, initialization CAN communication, establishment of communication on the network), and a main portion configured to perform the main function of the application. Once the initialization is completed, the initialization portion of the application can be ported to the target processor that has already executed the main portion, which is waiting for the migration of the initialization portion. The target processor can then continue the operation of the application (e.g., establish sensor connections, perform the main functions of the application). The allocation of processing and power resources can be effectively managed.

[0018] Techniques and systems for cross-processing unit migration of application execution are described herein. A first processor executes a first coordinator to initiate execution of an application. A target processor executes a second coordinator that communicates with the first coordinator to migrate execution of the application to the target processor. When the target processor is ready for migration of the application, the second coordinator communicates to the first coordinator that the migration can proceed. When the first processor receives the transmission, execution of the application is migrated to the target processor. Migration performed in this manner can result in better resource balancing for different drive states, save power by reducing the number of processors that are actively running, and / or speed up startup time by initially running the application on a low-power real-time processor and then migrating the application to a high-power processor.

[0019] Exemplary Systems

[0020] Figure 1-1 An exemplary vehicle 102 according to the technology of the present disclosure is shown, in which application execution migration across processing units can be applied. The vehicle 102 includes one or more first processing units 104 (e.g., first processors) and one or more second processing units 106 (e.g., target processors). The first processing unit 104 and the second processing unit 106 are communicatively coupled via a communication link 120.

[0021] exist Figure 1-1 , the vehicle 102 is shown as a passenger car. However, the vehicle 102 may represent other types of motor vehicles (e.g., trucks, motorcycles, buses, tractors, semi-trailer trucks), non-motor vehicles (e.g., bicycles), rail vehicles (e.g., trains), watercraft (e.g., ships), aircraft (e.g., airplanes), spacecraft (e.g., satellites), etc. In some aspects, the vehicle 102 is a software-defined vehicle.

[0022] The first processing unit 104 and the second processing unit 106 include processors 108 and 110 (e.g., microprocessors, digital signal processors (DSPs), ECUs, SOCs, and other processing circuits) and computer-readable storage media (CRMs) 112 and 114 (e.g., non-transitory storage devices such as hard disk drives, solid-state drives (SSDs), flash memory, read-only memory (ROM), erasable programmable ROM (EPROM), or electrically erasable programmable ROM (EEPROM). CRMs 112 and 114 may store instructions for executing the techniques described in this document, including coordinators 116 and 118, respectively, and other related instructions.

[0023] One or more first processing units 104 and one or more second processing units 106 can communicate via a communication link 120. The communication link 120 can be a wired or wireless link and in some cases includes a communication bus. In some cases, the communication link 120 is based on Ethernet and may also include a power rail for supplying power to the processing units 104 and 106.

[0024] In some aspects, the first processing unit 104 includes one or more low-power processors 108. The low-power processor 108 generally consumes less power and boots faster than the high-power processor 110. In contrast, the high-power processor 110 can generally handle more complex computing tasks than the low-power processor 108. Both the low-power processor 108 and the high-power processor 110 can have a different range of hardware architectures and software operating systems. The first processing unit 104 can generally be used for more specific, computationally simple tasks (e.g., FOB key systems, mechanical systems, partition controllers used as hubs for sensors within physical parts of the vehicle, etc.), and the second processing unit 106 is generally used for centralized computing tasks and / or computationally more complex tasks (e.g., centralized servers, system domain controllers, etc.).

[0025] CRMs 112 and 114 include coordinators 116 and 118, respectively. In some aspects, coordinators 116 and 118 may reside in the respective application managers or may be external to the respective application managers and execute in parallel and concurrently with the respective application managers. When vehicle 102 is started (or during any situation where it is desired to start an application on low-power processing unit 104), both processing units 104 and 106 begin their startup processes. Typically, first processing unit 104 can start faster than second processing unit 106, and therefore, application 122 can execute on the first processing unit faster. During the transition time between executing application 122 on first processing unit 104 and target second processing unit 106 being up and running, application 122 is able to perform certain initialization processes, such as diagnostics. During this transition time, coordinator 116 waits for communication (e.g., a message) from coordinator 118 indicating that target second processing unit 106 is ready for application 122 to be migrated. When the communication is received, the coordinators 116 and 118 manage the migration of the execution of the application 122 from the first processing unit 104 to the second processing unit 106. For example, the vehicle system includes a first processor (e.g., the first processing unit 104), the first processor executing a first coordinator (e.g., the coordinator 116) to initiate the execution of the application (e.g., the application 122) on the vehicle (e.g., the vehicle 102). The vehicle system also includes a target processor (e.g., the second processing unit 106), the target processor executing a second coordinator (e.g., the coordinator 118) that communicates with the first coordinator to migrate the execution of the application from the first processor to the target processor, wherein, in response to initiating the execution of the application, the first coordinator waits for a communication from the second coordinator indicating that the target processor is ready for the migration of the application execution, and upon receiving the communication, the first processor migrates the execution of the application to the target processor. In addition, in some cases, it may be necessary to migrate the execution of the application 122 from the second processing unit 106 back to the first processing unit 104, and in these cases, the coordinator handles the migration in a similar manner. The communication made by coordinators 116 and 118 and the management of application 122 will be combined with Figure 1-2 Further description.

[0026] Figure 1-2An example data flow of a migration across processing units performed according to an application of the techniques of the present disclosure is shown. In this example, vehicle 102 is started. First processing unit 104 executes operating system 124 and second processing unit executes operating system 126. For this example, it is assumed that low-power processor 108 of first processing unit 104 starts operating system 124 in a working state faster than high-power processor 110 of second processing unit 106 starts operating system 126, or low-power processor 108 consumes less energy than high-power processor 110. Operating system 124 can be the same type of operating system as operating system 126, or they can be different types of operating systems.

[0027] The coordinator 116 and the virtual machine 128 are executed on the first processing unit 104. Alternatively, the coordinator 116 may be executed within the virtual machine 128. At a communication step 132, the coordinator 116 communicates with the application 122, waiting for an indication that the application 122 has reached a certain state ready for migration. The particular state may include a stable state suitable for migration once the application 122 has performed some diagnostic or other simple startup tasks. Likewise, the coordinator 116 waits for an indication that the coordinator 118 is ready for the migration process.

[0028] At some point in time (e.g., at the same time as the first processing unit 104 starts booting, or at some time after the first processing unit 104 starts booting), the second processing unit 106 starts its booting process. The second processing unit 106 starts the operating system 126 and executes the coordinator 118 and the virtual machine 130. Similar to the coordinator 116, the coordinator 118 may also alternatively execute within the virtual machine 130. When the coordinator 118 determines that the virtual machine 130 is in a state ready to migrate at the communication step 134, the coordinator 118 indicates to the coordinator 116 that the second processing unit 106 is ready to migrate the execution of the application 122 at the communication step 136. The communication steps 132, 134, and 136 may use different techniques when indicating the state of readiness between different software actors, such as callbacks, polling, publish / subscribe, web sockets, push notifications, etc. At the communication step 138, the coordinators 116 and 118 manage the migration of the application 122 from the first processing unit 104 to the second processing unit 106. The migration may include the binary executable file, the current (e.g., frozen) state of the application 122, and other relevant data (e.g., sensor-related data, input / output-related data) related to the application 122 contained in a memory (e.g., random access memory (RAM)). After the application 122 is received by the second processing unit 106, the application 122 resumes execution on the second processing unit 106 in its state at the migration point (e.g., unfrozen). In this way, power and computing resources may be efficiently managed in an embedded environment such as a motor vehicle.

[0029] Example Implementation

[0030] Figure 2 An example abstraction layer configured for cross-processing unit migration of application execution according to the techniques of this disclosure is shown. The abstraction layer demonstrates how to abstract software from hardware so that application execution can be migrated. A device driver can be initialized on a low-power processing unit (e.g., low-power processing unit 104) and then migrated to a high-power processing unit (e.g., high-power processing unit 106). Layer 202 is a hardware abstraction layer. The hardware can include sensors (e.g., radar systems, camera systems), hardware related to mechanical systems (e.g., braking systems, transmission systems, engine controllers), or other automotive systems.

[0031] Layer 204 is a device local abstraction layer (e.g., a low-level abstraction layer). At this layer, the native operating system running on the processing unit communicates with the hardware using low-level instructions. The operating system can pass instructions between higher abstraction layers (e.g., layers 206 and 208) and the device local abstraction layer 204.

[0032] Layer 206 is the execution environment abstraction layer. The virtual machine executes at this layer and runs within the operating system. The virtual machine can access the device local abstraction layer 204 by communicating with the native operating system. Software libraries reside at this layer and contain instructions that enable applications (e.g., device drivers, applications 122) to communicate with layer 204.

[0033] Layer 208 is the application abstraction layer. This is the layer where the application (in this case, the device driver) is executing. The application has been compiled into a native binary format for the virtual machine. When the application begins execution, it can instruct the device to start and initialize. When migrating, the content of the RAM containing the executable application and the related library (at layer 206) with the native binary format for the virtual machine, together with the application state and the information dedicated to the device (for example, the absolute memory address associated with the virtual machine) can be frozen and migrated to another processing unit (for example, processing unit 106) running a similar virtual machine using the same native binary format. This other processing unit may include an abstraction layer similar to that shown here. Once the migration including the RAM content is completed, the application can resume execution in the same state, where the same information as before the migration is used for execution. Using these technologies to migrate applications, services, device drivers, etc. enables the use of low-power processors to execute applications, and then transfers the application to a target high-power processor with the computational complexity required for the main purpose of the application.

[0034] Figure 3An exemplary allocation flow 300 for cross-processing unit migration of application execution according to the technology of the present disclosure is shown. At 302, the source code of an application 304 is developed. The application 304 can be developed in isolation from other applications and system updates. The source code can be developed using a variety of programming languages. The source code can be precompiled (e.g., compiled in advance (AoT: ahead-of-time)) into a binary format that is independent of the hardware architecture. That is, the binary executable file of the application 304 can have a format that is native to the virtual machine rather than the hardware architecture. This enables the binary executable file to be executed by different types of hardware architectures. Contrary to the many files that must be tested for each different type of target hardware architecture, the compiled application 304 can be tested as a single file. In other cases, for both small and large processing units, it may be reasonable to transform the portable virtual program in a machine-specific format using AoT compilation of the virtual program for a specific machine to make execution on a specific machine more efficient. The data layout (RAM) can remain the same, but in these cases, the stack can then be serialized and deserialized.

[0035] At 306, the developed application 304 may be uploaded to a cloud network or other database for distribution to the host system. The host system 308 may download the application 304 from the cloud as an over-the-air (OTA) update. Similarly, the application 304 may be downloaded to the host system 308 by other means (e.g., from a hard drive via a wired connection) and at predetermined intervals (e.g., during a maintenance check). In some cases, the host system 308 includes one or more servers of the vehicle, which may distribute updates to different embedded systems 310 integrated on the vehicle. The embedded system 310 may receive the application 304 and implement the techniques described herein. Distributing the application 304 in this manner allows the application 304 to be developed more efficiently, and the application 304 may be quickly updated and distributed to the target system.

[0036] Exemplary Methods

[0037] Figure 4 An example method 400 for cross-processing unit migration of application execution according to the technology of the present disclosure is shown. The method 400 is shown as a set of operations (or actions) performed, but is not necessarily limited to the order or combination of operations shown here. In addition, any of one or more operations can be repeated, combined or reorganized to provide other methods.

[0038] In step 402, a first processor (e.g., first processing unit 104, low power processor 108) is caused to execute a first coordinator to start execution of an application (e.g., application 122) on a vehicle. The first processor may be a fast-starting, low-power consumption processor that is computationally less complex for a target processor (e.g., second processing unit 106, high power processor 110) that is the final target processor of the application. A non-limiting example of the first processor is a controller of a FOB for keyless entry into a vehicle. Initialization of the application may include initializing network communications. The first processor may perform step 404 by executing a plurality of applications on the vehicle. The first processor may also execute a first coordinator on the first processor to start execution of the application.

[0039] In step 404, the second processor is caused to execute the second coordinator that communicates with the first coordinator to migrate the execution of the application from the first processor to the target processor. The first processor executes the application and can enable the application to start using less power and time than the target processor may consume when starting the application. The first processor can execute the application through initialization of the application and keep the application in a stable state waiting for communication, as described in step 406. Simultaneously or asynchronously, the target processor starts and runs the second coordinator to jointly manage the migration of the application.

[0040] In step 406, in response to initiating execution of the application, the first coordinator waits for communication from the second coordinator that the target processor is in a ready state for execution of the migrated application. The target processor may have a different type of hardware architecture than the first processor and may run a different operating system than the first processor. However, the application has been compiled into a binary format independent of the hardware architecture and can be run on a virtual machine running on the first processor and the target processor. For example, when the first coordinator is executed on the first processor to initiate execution of the application, the first processor determines whether the first coordinator is to migrate execution of the application to the target processor with available resources to execute the application on the vehicle.

[0041] At step 408, in response to the first coordinator receiving the communication, the first processor is caused to migrate execution of the application to the target processor. For example, the first processor communicates with a second coordinator executing on the target processor, the communication indicating that resources are available to take over execution of the application; and in response, determines that migration will occur. The first coordinator can communicate with the second coordinator to migrate execution of the application to the target processor to resume where the execution stopped on the first processor.

[0042] In some cases, the first coordinator can manage the migration together with the second coordinator. The migration can include at least some binary contents of a random access memory associated with the first processor. The binary contents can include executable binary code of the application, the state of the application, and / or other relevant data associated with the application. The binary contents can also include an absolute memory address pointing to the inside of the virtual machine, which remains the same throughout the migration. The application can run on the target processor and control any other hardware without the additional step of reinitializing the corresponding hardware accessible to it.

[0043] Additional Examples

[0044] Some additional examples of cross-processing unit migration of application execution are provided below.

[0045] Example 1: A system for migrating the execution of an application across multiple processors on a vehicle, the system comprising: a first processor on the vehicle, the first processor executing multiple applications until migration of the execution of at least one application transfers the execution of the application to a target processor having available resources for executing the application; at least one target processor, the at least one target processor comprising a target processor having the available resources to execute the execution of the application using the available resources; a first coordinator, the first coordinator executing on the first processor to start the execution of the application and then managing the migration to the target processor; and a second coordinator, the second coordinator executing on the target processor and communicating with the first coordinator to indicate available resources for taking over the execution of the application and communicating with the first coordinator to migrate the execution of the application to the target processor to resume at the point where the execution on the first processor stopped.

[0046] Example 2: The vehicle system of Example 1, wherein the first coordinator initiates execution of the application by executing the application through an initialization process, the initialization process including establishing communications on a network of the vehicle.

[0047] Example 3: A vehicle system according to any of the preceding examples, wherein the first coordinator and the second coordinator migrate execution of the application from the first processor to the target processor by migrating at least some contents of a first random access memory related to the application and accessible by the first processor to a second random access memory accessible by the target processor.

[0048] Example 4: A vehicle system according to Example 3, wherein, before the first coordinator and the second coordinator migrate the execution of the application from the first processor to the target processor: the contents of the first random access memory include executable code that causes the first processor to perform an initialization function of the application; and the contents of the second random access memory include executable code that causes the processor to execute one or more main functions of the application.

[0049] Example 5: The vehicle system of Example 3 or 4, wherein the content of the first random access memory that is migrated to the second random access memory includes a current state and data related to the application.

[0050] Example 6: A vehicle system according to any one of Examples 3 to 5, wherein the contents of the first random access memory that are migrated to the second random access memory include: absolute memory addresses associated with different virtual machines independently executed on each of the first processor and the target processor.

[0051] Example 7: A vehicle system according to any one of Examples 3 to 6, wherein the first coordinator and the second coordinator migrate the execution of the application from the first processor to the target processor in the following manner: migrating the execution of the application from the first processor to the target processor comprises: the first coordinator causes the first processor to stop the execution of the application in a current state; and the second coordinator causes the target processor to resume the execution of the application from the current state.

[0052] Example 8: A vehicle system according to any of the preceding examples, wherein the first processor has a different hardware architecture than the target processor, and wherein migrating execution of the application from the first processor to the target processor includes migrating the main memory to the target processor by copying the contents of a main memory associated with the first processor using the same data structure without serializing and deserializing the main memory.

[0053] Example 9: A vehicle system according to any of the preceding examples, wherein the first processor is a partition controller of the vehicle that serves as a hub for sensors within a physical portion of the vehicle, and the target processor is a domain controller that performs centralized server functions for the vehicle.

[0054] Example 10: The vehicle system of any of the preceding examples, wherein during a low power situation, the second coordinator migrates the application from the target processor back to the first processor.

[0055] Example 11: A vehicle system according to any of the preceding examples, wherein the application is compiled in a binary format that is independent of the hardware architecture of the first processor and the target processor, and wherein the application is compiled before being distributed to the vehicle system.

[0056] Example 12: A vehicle system according to any of the preceding examples, wherein the first coordinator communicates with the second coordinator to migrate execution of the application to the target processor to resume at the point where execution on the first processor was stopped by: checking whether the transmitted information indicates: there is migration to the target processor; or communication from the second coordinator indicates that the target processor is in a ready state for the migration; and in response to determining that there is migration or in response to receiving the communication, causing the first processor to send data to the second coordinator to migrate execution of the application to the target processor.

[0057] Example 13: A vehicle system according to any of the preceding examples, wherein the application is a service application or a device driver application.

[0058] Example 14: A vehicle system according to any of the preceding examples, wherein the first coordinator and the second coordinator: reside in corresponding application managers executed on the first processor and the target processor; or are external to the corresponding application managers and executed in parallel with the corresponding application managers.

[0059] Example 15: A method for migrating the execution of an application across multiple processors on a vehicle, the method comprising the following steps: executing multiple applications by a first processor on the vehicle; executing a first coordinator on the first processor by the first processor to initiate execution of the application; determining by the first processor whether the first coordinator is to migrate execution of the application to a target processor having available resources for executing the application on the vehicle; communicating by the processor with a second coordinator executing on the target processor, the second coordinator indicating that the resources are available to take over execution of the application; and migrating execution of the application to the target processor by the first coordinator communicating with the second coordinator to resume at the point where execution on the first processor stopped.

[0060] Example 16: A system comprising an apparatus for performing the method according to Example 15.

[0061] Example 17: A non-transitory computer readable medium comprising instructions that, when executed, cause a first processor and a target processor to perform the method according to Example 15.

[0062] in conclusion

[0063] Although various embodiments of the present disclosure have been described in the foregoing description and shown in the accompanying drawings, it should be understood that the present disclosure is not limited thereto, but may be implemented in various ways within the scope of the appended claims. From the foregoing description, it is apparent that various changes may be made without departing from the spirit and scope of the present disclosure as defined by the appended claims. Problems associated with application processors that consume a lot of power and require additional time during startup may occur in other systems. Therefore, although described as a way to migrate applications across hardware architectures embedded in automobiles, the techniques described above may be applied to other systems that may benefit from managing power and computing resources at startup time. In addition, these techniques may also be applied to other systems with multiple embedded systems having different types of architectures.

[0064] The use of "or" and grammatically related terms indicates non-exclusive substitution without limitation unless the context clearly indicates otherwise. As used herein, a phrase referring to "at least one" of a list of items refers to any combination of those items, including single members. As an example, "at least one of: "a, b, or c" is intended to cover any combination of a, b, c, ab, ac, bc, and abc, and multiples of the same elements (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc or any other order of a, b, and c).

Claims

1. A vehicle system for migrating execution of an application across multiple processors on a vehicle, the vehicle system comprising: a first processor on the vehicle, the first processor executing a plurality of applications until migration of execution of at least one application transfers the execution of the application to a target processor having available resources to execute the application; at least one target processor including said target processor having said available resources, said target processor performing said execution of said application using said available resources; a first coordinator executing on the first processor to initiate the execution of the application and then manage migration to the target processor; as well as A second coordinator, which executes on the target processor and communicates with the first coordinator, indicates the available resources for taking over the execution of the application, and communicates with the first coordinator to migrate the execution of the application to the target processor to resume at the point where the execution stopped on the first processor.

2. The vehicle system according to claim 1, wherein: The first coordinator initiates the execution of the application by executing the application through an initialization process, the initialization process including establishing communications on a network of the vehicle.

3. The vehicle system according to claim 1 or 2, wherein: The first coordinator and the second coordinator migrate the execution of the application from the first processor to the target processor by: At least some contents of a first random access memory associated with the application and accessible by the first processor are migrated to a second random access memory accessible by the target processor.

4. The vehicle system according to claim 3, wherein: Before the first coordinator and the second coordinator migrate the execution of the application from the first processor to the target processor: The content of the first random access memory includes executable code for causing the first processor to execute an initialization function of the application; and The contents of the second random access memory include executable code that causes the target processor to perform one or more main functions of the application.

5. The vehicle system according to claim 3 or 4, wherein: The content of the first random access memory that is migrated to the second random access memory includes a current state and data related to the application.

6. The vehicle system according to any one of claims 3 to 5, wherein: The content of the first random access memory that is migrated to the second random access memory includes: Absolute memory addresses associated with different virtual machines independently executing on respective ones of the first processor and the target processor.

7. The vehicle system according to any one of claims 3 to 6, wherein: The first coordinator and the second coordinator migrate the execution of the application from the first processor to the target processor by: Migrating the execution of the application from the first processor to the target processor includes: causing the first processor to stop executing the application in a current state through the first coordinator; and The target processor is caused to resume the execution of the application from the current state by the second coordinator.

8. The vehicle system according to any one of claims 1 to 7, wherein: The first processor has a different hardware architecture than the target processor, and wherein the migration of the execution of the application from the first processor to the target processor comprises: The main memory associated with the first processor is migrated to the target processor by copying contents of the main memory associated with the first processor using the same data structure without serializing and deserializing the main memory.

9. The vehicle system according to any one of claims 1 to 8, wherein: The first processor is a zone controller of the vehicle that acts as a hub for sensors within a physical portion of the vehicle, and The target processor is a domain controller that performs centralized server functions for the vehicle.

10. The vehicle system according to any one of claims 1 to 9, wherein: During a low power available condition, the second coordinator migrates the application from the target processor back to the first processor.

11. The vehicle system according to any one of claims 1 to 10, wherein: The application is compiled in a binary format that is independent of a hardware architecture of the first processor and the target processor, and wherein the application is compiled prior to being distributed to the vehicle system.

12. The vehicle system according to any one of claims 1 to 11, wherein: The first coordinator communicates with the second coordinator to migrate the execution of the application to the target processor to resume at the location where the execution stopped on the first processor by: Check if the transmitted information indicates: There is a migration with the target processor, or a communication from the second coordinator indicating that the target processor is in a ready state for the migration; as well as In response to determining that there is migration or in response to receiving the communication, causing the first processor to send data to the second coordinator to migrate the execution of the application to the target processor.

13. The vehicle system according to any one of claims 1 to 12, wherein: The application is a service application or a device driver application.

14. The vehicle system according to any one of claims 1 to 13, wherein: The first coordinator and the second coordinator: resident in respective application managers executing on the first processor and the target processor, or It is external to the corresponding application manager and executes in parallel with the corresponding application manager.

15. A method for migrating execution of an application across multiple processors on a vehicle, the method comprising the steps of: executing a plurality of applications by a first processor on the vehicle; executing, by the first processor, a first coordinator on the first processor to start execution of the application; determining, by the first processor, whether the first coordinator is to migrate the execution of the application to a target processor having available resources to execute the application on the vehicle; communicating, by the first processor, with a second coordinator executing on the target processor, the second coordinator indicating that the resource is available to take over the execution of the application; as well as The execution of the application is migrated to the target processor by the first coordinator in communication with the second coordinator to resume where the execution stopped on the first processor.

Images