Techniques for deploying software in vehicle

Abstract

The invention relates to management of software in a vehicle. For example, the present disclosure provides a computer-implemented method for deploying software in a vehicle. A method includes, at a controller of a vehicle: obtaining a set of capability information for each of a plurality of electronic control units (ECUs) of the vehicle, the set of capability information describing capabilities of the ECUs; in response to the container of the software being available for deployment, obtaining a set of demand information for the container, the set of demand information describing required ECU capabilities required by the container for deployment on one or more of the plurality of ECUs; and selecting a target ECU for deploying the container from the plurality of ECUs based on the capability information set and the demand information set, such that a capability of the target ECU described by the capability information set of the target ECU satisfies a required ECU capability described by the demand information set of the container.

Description

Technical Field

[0001] The present disclosure generally relates to techniques for managing software in a vehicle. More specifically, the present disclosure relates to a method for deploying software in a vehicle including a plurality of electronic control units (ECUs). Background Art

[0002] Managing software in a vehicle is a relatively new feature that has not been previously required and thus has not been well addressed. As the transition to software-defined vehicles has begun, there is a need to provide new features and security updates throughout the vehicle's lifespan. Vehicles are equipped with various electronic control units (ECUs) that serve different purposes and are equipped with different software. This requires keeping the software of the ECUs up-to-date during the vehicle's lifespan and also requires extending or correcting errors in the software.

[0003] Although several problems in deploying and managing software to heterogeneous systems in a vehicle and ensuring compatibility during updates have been solved by using orchestration (e.g., using Kubernetes), there are still some problems that have not been solved. For example, the software may need to execute platform-provided resources to execute correctly.

[0004] The present disclosure addresses these drawbacks and provides a solution for improving the deployment and management of software in a vehicle and ensuring a match between the available platform capabilities and the capabilities requested by the software when installing / updating the software. Summary of the Invention

[0005] The present disclosure relates to improving the management of software in a vehicle, including deployment, installation, and updates. The independent claims set forth the main aspects.

[0006] According to a first aspect of the present disclosure, there is provided a computer-implemented method for deploying software in a vehicle. The method includes, at a controller of the vehicle: obtaining a set of capability information for each of a plurality of electronic control units (ECUs) of the vehicle, the set of capability information describing the capabilities of the ECU; obtaining a set of requirement information for the container in response to the container of the software being available for deployment, the set of requirement information describing the required ECU capabilities that the container requires for deployment on one or more of the plurality of ECUs; and selecting a target ECU for deploying the container from the plurality of ECUs based on the set of capability information and the set of requirement information such that the capabilities of the target ECU described by the set of capability information of the target ECU satisfy the required ECU capabilities described by the set of requirement information of the container.

[0007] In some examples of the first aspect, selecting a target ECU may include, at a controller: comparing a set of capability information with a set of requirement information to determine the capabilities of the target ECU that meet the required ECU capabilities.

[0008] In some examples of the first aspect, the requirement information may describe the minimum requirements of the required ECU capabilities that the capabilities of the target ECU are to meet.

[0009] In some examples of the first aspect, the requirement information may include: runtime environment requirements, which indicate the runtime environment required for a container, which is a required ECU capability, to run on one or more of a plurality of ECUs; and / or resource requirements, which indicate the resources required for a container, which is a required ECU capability, to run on one or more of a plurality of ECUs.

[0010] In some examples of the first aspect, the capability information may include: runtime environment capabilities, which indicate the runtime environment available at the ECU as a capability for running a container; and / or resource capabilities, which indicate the resources available at the ECU as a capability for running a container.

[0011] In some examples of the first aspect, the runtime environment may include information related to one or more of the following: operating system, software, libraries, and configuration parameters. In some examples of the first aspect, the resources may include information related to one or more of the following: processors, memory, capacity, network devices, input / output devices, and accelerators.

[0012] In some examples of the first aspect, the computer-implemented method may further include, at the controller: determining the availability of a container or an update of the container at a server via an over-the-air (OTA) connection; and downloading the container or the update from the server via the OTA connection.

[0013] In some examples of the first aspect, the computer-implemented method may further include, at the controller: validating the container or the update; and storing the container in a local registry of the vehicle, or using the update to update the container in the local registry so that the container can be used for deployment.

[0014] In some examples of the first aspect, the computer-implemented method may further include, at the controller: determining whether the vehicle is in a valid state that allows the deployment of the container; and based on the valid state, delaying or continuing to select the target ECU.

[0015] In some examples of the first aspect, the computer-implemented method may further include, at the controller: deploying the container to the target ECU for installation on the target ECU to thereby deploy software.

[0016] In some examples of the first aspect, the computer-implemented method may further include, at the target ECU: installing a container to deploy software; verifying the installation status of the container on the target ECU; and in response to a verification failure, uninstalling the container and restoring the previous version of the container.

[0017] In some examples of the first aspect, the multiple ECUs include ECUs of different platforms, and the different platforms include at least one of the following: different hardware platforms, different operating systems, different virtual runtime environments, different application programming interfaces.

[0018] According to a second aspect of the present disclosure, there is provided an apparatus for use in a vehicle. The apparatus includes a processor configured to perform one or more examples of the examples of the first aspect. For example, the processor may be configured to: obtain a set of capability information of each ECU of a plurality of electronic control units (ECUs) of the vehicle, the set of capability information describing the capabilities of the ECU; in response to a container of software being available for deployment, obtain a set of requirement information of the container, the set of requirement information describing the required ECU capabilities for the container to be deployed on one or more of the plurality of ECUs; and select a target ECU for deploying the container from the plurality of ECUs based on the set of capability information and the set of requirement information, such that the capabilities of the target ECU described by the set of capability information of the target ECU satisfy the required ECU capabilities described by the set of requirement information of the container.

[0019] According to a third aspect, there is provided a computer program product. The computer program product includes instructions that, when executed by a computer, cause the computer to perform one or more examples of the examples of the first aspect.

[0020] According to a fourth aspect, there is provided a computer-readable data carrier. The computer-readable data carrier stores the computer program product of the third aspect thereon.

[0021] The present invention content aims to provide a brief overview of some of the aspects and features according to the present disclosure. Therefore, it should be understood that the above features are merely examples and should not be construed as narrowing the scope of the present disclosure in any way. Other features, aspects, and advantages of the present disclosure will become apparent from the following detailed description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] A better understanding of the present disclosure can be obtained when considering the following detailed description of various exemplary embodiments in conjunction with the accompanying drawings, wherein:

[0023] Figure 1 FIG. illustrates a vehicle having various electronic components according to an embodiment of the present disclosure.

[0024] Figure 2 The figure shows Figure 1 a block diagram of various electronic components of the vehicle shown in

[0025] Figure 3 The figure shows Figure 1 a block diagram of an orchestration system in the vehicle shown in

[0026] Figure 4 The figure shows a method for deploying software in a vehicle according to an embodiment of the present disclosure.

[0027] Figure 5 The figure shows a structure to be used by a method for deploying software in a vehicle according to an embodiment of the present disclosure.

[0028] Figure 6 The figure shows a flowchart corresponding to aspects of a method for deploying software in a vehicle according to an embodiment of the present disclosure.

[0029] Figure 7 The figure shows another flowchart corresponding to aspects of a method for deploying software in a vehicle according to an embodiment of the present disclosure.

[0030] Figure 8 is a graphical representation of internal components of a computing system that implements the functions described herein. Detailed Description

[0031] Before explaining the exemplary embodiments of the present disclosure in more detail, some basic principles related to the present disclosure are briefly explained to help understand the technology underlying the examples.

[0032] Figure 1 The figure shows a vehicle 100 having various electronic components according to an embodiment of the present disclosure. For example, a passenger car is shown. However, any other vehicle can also be considered a vehicle. Examples of vehicles include buses, commercial vehicles (especially trucks), agricultural machinery, construction machinery, motorcycles, rail transit vehicles, other mobile systems such as storage elevators, and so on. The present disclosure generally applies to land vehicles, rail transit vehicles, water vehicles, and aircraft. This application is mainly intended for the field of vehicles. However, use in the field of fieldbuses, i.e., in the fields of automation technology, process technology, etc., can also be considered.

[0033] In a vehicle 100, multiple electronic control units (ECUs) are used to control various functions of the vehicle 100. The vehicle 100 includes an interconnect 150 for connecting the ECUs to other electronic components of the vehicle 100, such as sensors, displays, user interfaces, etc. The ECUs 120, 130, 140 are used to control one or more of the electrical systems or subsystems in the vehicle 100. The vehicle further includes a controller 110. The controller 110 is used to control one or more of the ECUs 120, 130, 140. The controller 110 may include a wireless communication module (not shown) or be connected to a wireless communication module for communication via an over-the-air (OTA) interface 160.

[0034] Examples of the ECUs 120, 130, 140 may include at least one of the following: engine control module (ECM), powertrain control module (PCM), transmission control module (TCM), brake control module (BCM or EBCM), central control module (CCM), central timing module (CTM), general electronic module (GEM), body control module (BCM), suspension control module (SCM), and so on.

[0035] The ECUs of the vehicle 100, such as the ECUs 120, 130, 140, may be represented by separate computers. In some examples, the integration of the ECUs includes several separate control modules (e.g., the PCM typically controls both the engine and the transmission). The controller 110 performs settings for, for example, the center of mass, inertia, axles, steering, braking, tires, powertrain (engine, clutch, transmission, retarder, driveline), driver assistance, and safety assistance.

[0036] Figure 2 The figure shows a block diagram of various electronic components of the vehicle 100 according to an embodiment of the present disclosure. Figure 1 shown in

[0037] The vehicle 100 includes a controller 110 (e.g., central control, main control unit), multiple ECUs 220, and a local registry 230. For ease of illustration, Figure 2Four ECUs 220-A through 220-D are shown, which represent multiple ECUs 220. The controller 110 and the multiple ECUs 220 are connected to each other via an interconnect 150. The interconnect 150 can include any type of wired or wireless connection, including a serial connection, a bus, or a network (e.g., a local area network). The local registry 230 can also be connected to the interconnect 150 or can be directly coupled to the controller 110 via any type of local connection (e.g., UART, USB, etc.). The controller 110 is also connected to an OTA server 210 via a wireless communication module (e.g., an OTA interface). The OTA server 210 can be a server on the Internet.

[0038] In some examples, the controller 110 can be a Linux-based computing system that acts as a containerized central node or an orchestration node.

[0039] The term "orchestration" as referred to herein has an established meaning in the field of system management. Thus, orchestration involves the automated configuration, coordination, and management of computer systems and software. Exemplary tools for orchestration include Kubernetes and AWS CloudFormation. In other words, the controller 110 configures, coordinates, and manages the multiple ECUs 220 and the software of the multiple ECUs 220.

[0040] The term "software" as referred to herein relates to all types of software required for a vehicle-based computing system, including, for example, software for the basic input / output system (BIOS), firmware, hardware-specific code, hardware drivers, protocol software, application software, etc. In other words, the term "software" relates to instructions or commands that, when executed by any kind of computing or processing device, cause the computing or processing device to perform operations associated with the instructions or commands. In this regard, the term "software" also includes software routines, software modules, software libraries, software components, etc.

[0041] As described above, multiple ECUs 220 are used to control various functions of the vehicle 100. Generally, the multiple ECUs 220 include ECUs of different platforms. For example, different platforms may include at least one of the following: different hardware platforms (e.g., Intel-based processors, ARM-based processors, etc.), different operating systems (e.g., Linux-based operating systems, Android-based operating systems, Unix / Posix-based operating systems, etc.), different virtual runtime environments (e.g., Vmware-based environments, Java virtual machine-based environments, etc.), different application programming interfaces (e.g., Java, C, Python, etc.). Different platforms may also include different platform as a service (PaaS) product sets that use OS-level virtualization to deliver software in software packages called containers.

[0042] In some examples, the multiple ECUs 220 may include Linux-based ECUs and non-Linux-based ECU computing systems that act as containerized nodes. Some of the multiple ECUs 220 may also include high-compute platforms.

[0043] In other words, the controller 110 and the multiple ECUs 202 may support or implement OS-level virtualization (i.e., containerization). OS-level virtualization is referred to as an operating system (OS) virtualization paradigm in which the kernel of the OS allows for the existence of multiple isolated user space instances, called containers for example. From the perspective of programs running in these instances, these instances may appear to be real computers. A computer program running on a normal OS (e.g., Linux, etc.) typically sees all the resources of that computer (connected devices, files and folders, network shares, CPU power, quantifiable hardware capabilities). Programs running inside a container typically only see the contents of the container and the devices allocated to the container.

[0044] Accordingly, the term "container" as referred to herein is understood to have a well-established meaning in the field of computer virtualization. Thus, the containers covered by this disclosure are cloud or non-cloud computing environments that surround the functionality and portability of an application and are independent of other environments. A container may contain one or more different software applications and run isolated processes by packaging together related configuration files, libraries, and dependencies. Containers can eliminate most of the complexity surrounding the deployment, installation, and configuration of software. Thus, containers are particularly suitable for automotive environments where it is desirable to install a certain software or software component independently of other software and software components and ensure security.

[0045] The local registry 230 may include any type of storage device for storing data (such as software, containers, updates, etc. that the controller 110 is to deploy to multiple ECUs 220). Similarly, the OTA server 210 may include any type of server device (e.g., cloud server, web server, file server, etc.) that provides software, containers, updates, etc. to be deployed to the ECUs of a vehicle (e.g., vehicle 100). The OTA server 210 allows software to be pushed to the vehicle 100 (e.g., the controller 110 of the vehicle 100) or allows the controller 110 of the vehicle 100 to pull software.

[0046] Turning now to Figure 3 , a block diagram of an orchestration system 300 in the vehicle 100 shown in Figure 1 accordance with an embodiment of the present disclosure will be described.

[0047] The orchestration system 300 includes the controller 110, multiple ECUs 200, and a local registry 230 (not shown) as described above with reference to Figure 2 . For ease of illustration, Figure 3 two ECUs 340 and 350 are shown, which represent the multiple ECUs 220. In some examples, the orchestration system may implement Kubernetes tools.

[0048] The controller 110 may represent the central node or master node of the orchestration system (i.e., the containerized central node or orchestration node). For example, the controller 110 may be a Linux-based computing system that includes an orchestration scheduler 310 for controlling and scheduling the automatic configuration, coordination, and management of multiple ECUs 220 and the software running on these ECUs 220. Examples of the orchestration scheduler 310 may include the Kubernetes scheduler.

[0049] The orchestration scheduler 310 may include one or more extensions implementing aspects of embodiments of the present disclosure. For example, as will be described in more detail below, the orchestration scheduler 310 may include an extension 342 for obtaining and processing a set of capability information describing the capabilities of the ECUs 220 of the vehicle 100, and an extension for obtaining and processing a set of requirement information describing the software requirements that enable software to run on or be executed by the ECUs 220.

[0050] ECUs 340 and 350 can represent worker nodes of an orchestration system. For example, ECU 340 can be a Linux-based computing system that includes an orchestration agent 344 for controlling ECU 340 and the configuration and management of software running on ECU 340 according to control performed by controller 110. ECU 350 can be a RTOS-based computing system that includes an abstract orchestration agent 354 for controlling ECU 350 and the configuration and management of software running on ECU 350 according to control performed by controller 110.

[0051] The orchestration agent 344 and the abstract orchestration agent 354 can each include one or more extensions implementing aspects of embodiments of the present disclosure. For example, as will be described in more detail below, the orchestration agent 344 and the abstract orchestration agent 354 can each include an extension 352 for providing and processing a set of capability information describing the capabilities of the corresponding ECU of vehicle 100.

[0052] In an example of the present disclosure, an abstract orchestration agent (or abstract worker node agent) 354 is provided to allow non-Linux-based nodes (e.g., RTOS) to be added to the orchestration system of vehicle 100, thereby adding non-Linux-based nodes to the in-vehicle cluster, and an orchestration agent (or worker node agent) 344 is provided to allow Linux-based nodes to be added to the orchestration system of vehicle 100. The extension 352 can provide an abstract node capability description as capability information, while the extension 342 can provide a node capability description as capability information. The extensions of the orchestration agents 344, 354 can also include an orchestrator optimization client to optimize orchestration on the ECU.

[0053] In some examples of the present disclosure, the extension of the orchestration scheduler 310 can include extensions for container configuration resources and runtime expectations. The extension 342 is provided to consider node custom resources (i.e., obtaining and processing a set of capability information describing the capabilities of the ECU of the vehicle).

[0054] Reference Figures 4 to 7 , a method for deploying software in a vehicle according to an embodiment of the present disclosure will now be described.

[0055] Figure 4 FIG. illustrates a method 400 for deploying software in a vehicle according to an embodiment of the present disclosure.

[0056] Method 400 can be performed in, such as Figure 1Execute in a vehicle such as the vehicle 100 shown above. As described above, the vehicle 100 may include a plurality of ECUs (such as ECUs 120, 130, 140) and a controller 110. More specifically, the method 400 may be executed by the controller 110. Generally, as described above, the plurality of ECUs include ECUs of different platforms.

[0057] The method 400 begins with obtaining a set of capability information of the ECUs of the vehicle (block 410). The set of capability information describes at least one capability of the ECUs. More specifically, in block 410, a set of capability information of each ECU among the ECUs connected and managed by the controller of the vehicle is obtained. For example, as Figure 1 shown, the set of capability information may be obtained by the controller 110 from each of the ECUs 120, 130, 140.

[0058] For example, the set of capability information may include runtime environment capability information, and the runtime environment capability information indicates a runtime environment available at the ECU as a capability of the ECU for running software (e.g., containers). The runtime environment defines the environment in which the software can be executed, including a software platform for executing the software, an engine for compiling or interpreting the software, etc. Exemplary runtime environment capability information indicating the runtime environment includes information related or associated with one or more of the following: software running on or provided by the ECU (e.g., operating system, application, library, firmware), configuration parameters (e.g., access policy, variables, permissions, configuration of the software), data (e.g., system data or user data, specific files or folders), etc. For example, the runtime environment capability information of the ECU 120 may include, but is not limited to, information that a Linux-based operating system is running on the ECU 120, version information of the kernel of the Linux-based operating system, information on whether the Linux-based operating system provides real-time capabilities, information on applications such as interpreters of programming languages (e.g., Python, C, Java, etc.) provided by the ECU 120, information on libraries or modules provided by the ECU 120, and version or configuration information of the library or module.

[0059] In some examples, the set of capabilities information may additionally or optionally include resource capabilities information, where the resource information indicates the resources available at the ECU as the capabilities of the ECU for running software (e.g., containers). Resources generally define one or more hardware resources of the ECU. Exemplary resource capabilities information indicating resources includes information related to or associated with one or more of the following: processors, memory (e.g., the type or size of the main memory, or at least the size of the main memory provided by the ECU for running software), capacity (e.g., the type or size of the storage device of the ECU, or the type or size of the devices installed on or available to the ECU), network devices (e.g., the type or speed of the network device), input / output devices (e.g., sensors or displays), and accelerators (e.g., graphics devices). For example, the resource capabilities information of ECU 120 may include, but is not limited to: information that the ECU has a single processor including four cores, information about the type of the single processor (e.g., an ARM-based processor), information about the total main memory (e.g., 8 gigabytes) and the available main memory (e.g., 2 gigabytes), information about the available storage space on the storage device (e.g., 8 gigabytes), information about the temperature sensor connected to or associated with ECU 120, and information that ECU 120 provides a graphics processor and a network device.

[0060] In response to the software to be deployed becoming available, method 400 proceeds to obtain a set of requirements information for the software (block 420). For example, the software (e.g., a container of the software) is available to the vehicle's controller 110 for deployment to one or more of ECUs 120, 130, 140. In response, controller 110 obtains the set of requirements information for the software at block 420. The set of requirements information describes one or more requirements of the software that enable the software to run on or be executed by the ECU. For example, the set of requirements information describes the required ECU capabilities needed when the software (e.g., a container) is deployed on the ECU. As Figure 1 shown, controller 110 may obtain the set of requirements information from the software (e.g., a container) available for deployment to ECUs 120, 130, 140.

[0061] For example, the requirements information includes runtime environment requirements information, which indicates the runtime environment required for software (e.g., a container) as a required ECU capability to run on the ECU. As described above, the runtime environment defines the environment in which the software needs to execute, including the software platform on which the software can be executed, the engine for compiling or interpreting the software, etc. Exemplary runtime environment requirements information indicating the runtime environment includes information related to or associated with one or more of the following: software required for the software to be deployed to run on the ECU (e.g., an operating system, an application, a library, firmware), configuration parameters (e.g., access policies, variables, permissions, configuration of the software), data (e.g., system data or user data, specific files or folders), etc. For example, the runtime environment requirements information of the software may include, but is not limited to, that the software needs a Linux-based operating system to run, and thus requires information about the Linux-based operating system provided by, for example, ECU 120, version information of the kernel of the Linux-based operating system, information on whether the Linux-based operating system needs to provide real-time capabilities, information on applications such as interpreters of programming languages (e.g., Python, C, Java, etc.) required by the software, information on libraries or modules required by the software, and version or configuration information of the library or module.

[0062] In some examples, the requirements information set may additionally or optionally include resource requirements information, which indicates the resources required for software (e.g., a container) as a required ECU capability to run on the ECU, and thus indicates the resources required for the software to be runnable on the ECU. As described above, resources generally define one or more hardware resources of the ECU required for the software to run on the ECU. Exemplary resource requirements information indicating the resources includes information related to or associated with one or more of the following: a processor, a memory (e.g., the type or size of the main memory, or at least the size of the main memory), a capacity (e.g., the type or size of the storage device of the ECU, or the type or size of the device installed on or available to the ECU), a network device (e.g., the type or speed of the network device), an input / output device (e.g., a sensor or a display), and an accelerator (e.g., a graphics device). For example, the resource requirements information of temperature measurement software (as an example) running on an ECU (e.g., ECU 120) may include, but is not limited to: information that the software needs at least one ARM-based processor, information that the software needs at least 2 gigabytes of main memory available to it, information that the software needs a temperature sensor connected to or associated with ECU 120, and information that the software needs a network device.

[0063] Typically, in some examples, the requirements information obtained in block 420 describes the minimum requirements of the required ECU capabilities that the capabilities of the ECU (also referred to as the target ECU) need to meet in order to deploy software to the ECU and run it thereon. For example, the requirements information may describe the minimum version of the kernel of the operating system based on Linux that the software requires, and / or the minimum requirements of the main memory.

[0064] In block 430, one or more ECUs (i.e., one target ECU or multiple target ECUs) for software deployment are selected from multiple ECUs. This selection is based on the set of capabilities information obtained in block 810 and the set of requirements information obtained in block 820. More specifically, the selection is made such that the capabilities of the target ECU described by the set of capabilities information of the target ECU meet the required ECU capabilities described by the set of requirements information of the software. In other words, the set of capabilities information of the target ECU is to satisfy or conform to the set of requirements information of the software. For example, as Figure 1 shown, the controller 110 may select the (multiple) target ECUs from the ECUs 120, 130, 140 based on the set of capabilities information obtained from the ECUs 120, 130, 140 in block 810 and the set of requirements information obtained from the software to be deployed in block 820.

[0065] In some examples, selecting the (multiple) target ECUs may include comparing the set of capabilities information with the set of requirements information to determine the capabilities of the target ECU that meet the required ECU capabilities. In other words, the controller 110 of the vehicle will compare the set of capabilities information obtained from the ECUs 120, 130, 140 in block 810 with the set of requirements information obtained from the software to be deployed in block 820, so as to determine the set of those capabilities information of the (multiple) target ECUs that meet the set of requirements information of the software to be deployed.

[0066] For example, as described above, the requirements information may describe the minimum requirements of the required ECU capabilities that the capabilities of the target ECU need to meet in order to deploy software to the target ECU and run on the target ECU. In such an example, selecting the (multiple) target ECUs includes determining which of the set of capabilities information of the ECUs of the vehicle satisfies the minimum requirements of the software to be deployed. For example, if the requirements information describes the minimum version of the kernel of an operating system based on Linux and / or the minimum requirements of the main memory, then it is determined whether the set of capabilities information of the ECU includes information related to the operating system of the ECU, information related to the version of the kernel of the operating system, and information on the available main memory. For each determined set of capabilities information, it is compared with the requirements information of the software, including comparing the information related to the operating system of the ECU with the operating system required by the software (e.g., an operating system based on Linux), comparing the information related to the version of the kernel of the operating system of the ECU with the minimum version of the kernel of the operating system required by the software based on Linux (e.g., to determine whether the version is equal to or higher than the minimum version), and comparing the information on the available main memory of the ECU with the minimum requirements of the main memory required by the software (e.g., to determine whether the available main memory is equal to or greater than the minimum requirements of the main memory).

[0067] According to one embodiment, Figure 4 The method 400 shown in may further include determining the availability of the software and downloading the software. For example, as described above, the software may include a container or an update of a container. The software may be available at a remote location of the vehicle, such as at a server on the Internet. The server can be accessed through an OTA connection. That is, the controller 110 of the vehicle 100 can determine the availability of the container or the update of the container at the server through the OTA connection. In response to determining the availability, the controller 110 can download the container or the update of the container from the server through the OTA connection. In other examples, the controller 110 can determine the availability of the software (i.e., a new container or a new update of a container) at a storage device connected to the controller 110. Examples of connecting the storage device to the controller 110 include: a local area network to which both the storage device and the controller 110 are connected, or a serial connection via the corresponding serial interface of the controller 110, such as a Universal Serial Bus (USB) connection. In these examples, the controller 110 can download the software from the storage device.

[0068] In some examples, Figure 4The method 400 shown in [description] may further include validating software and storing the software in a local registry or updating the software in the local registry. For example, in response to downloading software (i.e., a container or an update to a container), the controller 110 may validate the container or the update. For example, the controller 110 may use a hashing algorithm (e.g., MD5 Message-Digest Algorithm or Secure Hash Algorithm (SHA)) to calculate a checksum of the software and compare the calculated checksum with the checksum associated with the software (e.g., obtainable from a download server). The controller 110 may also verify whether the software is available for the vehicle (e.g., the vehicle's manufacturer or model). Validation at the controller 110 may include any confirmation and verification processes to ensure that the software can be deployed to the vehicle's ECU. In response to validating the container or the update, the controller 110 may store the container in the vehicle's local registry (e.g., store the container on a storage device of the controller 110 or in a repository of the vehicle), or use the update to update the container in the local registry. That is, use an update to the container (i.e., a newer version of the container) to update a container that is already available at the vehicle (i.e., an older or previous version of the container). For example, the older or previous version of the container may be replaced by the newer version of the container (i.e., the update), or the older or previous version of the container may be combined with the newer version of the container (e.g., a delta update or patch to the container). In response to storing or updating, the controller 110 may check the software stored at the local registry again (e.g., by validating the checksum).

[0069] According to other embodiments, Figure 4 The method 400 shown in [description] may further include determining whether the vehicle is in a valid state that permits the deployment of software and delaying or proceeding with the selection of the target ECU(s) based on the valid state. For example, a valid state that permits the deployment of software may correspond to a state of the vehicle (e.g., a maintenance state, a non-driving state, or a safe driving state) that permits the deployment of software while ensuring the vehicle's operability and meeting safety requirements. In some examples, the controller 110 may determine whether the vehicle is in a valid state by determining vehicle parameters that define the state of the vehicle and comparing these parameters with specified parameters indicating a valid state (e.g., determining whether the speed of the vehicle is zero).

[0070] According to other embodiments, Figure 4The method 400 shown in [the figure] may further include deploying software to the selected ECU(s) (i.e., the target ECU). For example, the software may be deployed to the selected ECU(s) to install the software on the selected ECU(s), update the software at the selected ECU(s) using the software to be deployed, or replace the software on the selected ECU(s) with the software to be deployed. For example, in response to selecting the target ECU(s), the controller 110 may deploy software (e.g., a container, or a container updated using a container update) to the target ECU(s) by transmitting the software to the target ECU(s) and executing routines to install the software on the selected ECU(s), update the software of the selected ECU(s), etc. Before deploying the software on the target ECU(s), the controller 110 may also verify the software on the selected ECU(s) again as described above.

[0071] In some examples, Figure 4 The method 400 shown in [the figure] may further include installing software (i.e., a container) and verifying the installation status of the software. For example, in response to installing the software at the target ECU(s), the controller 110 and / or the target ECU(s) may verify the installation by performing a health check to determine whether the software has been installed and can run without errors on the ECU(s). In response to a status indicating a failure (i.e., a status where the installation verification fails), the software may be uninstalled and the previous version of the software may be restored. For example, the controller 110 and / or the target ECU(s) may execute a recovery program to uninstall the software installed at the target ECU(s) and restore the previous version of the software (e.g., restore from a backup stored at the target ECU(s) or the controller 110), or by deploying the previous version of the software to the target ECU(s). Once the installation status indicates success, the software (i.e., the container) is deployed to the target ECU(s).

[0072] The method 400 allows for the implementation of a highly flexible and scalable software-defined vehicle platform, ensuring safe and reliable software deployment (e.g., installation or update) in the vehicle and ensuring software compatibility during deployment. More specifically, once the software is available for deployment, the method 400 allows for the selection of ECUs that meet the requirements of the software and on which the software can therefore be deployed, thus enabling the flexibility to select the ECUs for software deployment in a manner similar to "on demand". In some examples, the method 400 also allows for monitoring software health and managing recovery.

[0073] According to one embodiment of the present disclosure, representing Figure 1The electronic components of the controller 110 shown in the figure are configured to execute the examples of the method 400 described above. More specifically, the electronic components may include a processor and a memory storing instructions that, when executed by the processor, cause the processor to perform one or more of the operations of these examples. For example, the electronic components may include the extended orchestration scheduler described above to perform one or more of the operations. In some examples, the electronic components may also include circuitry configured to perform one or more of the operations of these examples.

[0074] Accordingly, the electronic components may obtain a set of capability information (i.e., the capabilities of the ECU) for each ECU of a plurality of ECUs of a vehicle; obtain a set of requirement information for a container (i.e., the required ECU capabilities that the container needs for deployment on one or more of the plurality of ECUs) in response to the container of the software being available for deployment (e.g., in a local registry); and select a target ECU from the plurality of ECUs for deploying the container. The selection may be based on the set of capability information and the set of requirement information such that the capabilities of the target ECU described by the set of capability information of the target ECU meet the required ECU capabilities described by the set of requirement information of the container.

[0075] The electronic components may also compare the set of capability information with the set of requirement information to determine the capabilities of the target ECU that meet the required ECU capabilities.

[0076] The requirement information may include: runtime environment requirements, which indicate the runtime environment required for the container, as the required ECU capabilities, to run on one or more of the plurality of ECUs; and / or resource requirements, which indicate the resources required for the container to run on one or more of the plurality of ECUs as the required ECU capabilities. As Figure 3 shown in the figure, the requirement information may be processed by the extension 320.

[0077] An exemplary structure of the requirement information (also referred to as a container manifest) for a particular container that expects a shared memory device on a worker node may be as follows. The exemplary structure may be obtained by an electronic device (e.g., an orchestration scheduler) from a container of software (i.e., a sample container) available for deployment on one or more worker nodes. apiVersion:v1 kind:Pod metadata: name:sample-container spec: containers: -name:sample-container-image image: "sample-container-image:v0.1" nodeSelector: device: "shared-memory-device" (api version: v1 kind: Pod metadata: name: sample-container spec: containers: - name: sample-container-image image: "sample-container-image:v0.1" nodeSelector: device: "shared-memory-device")

[0078] As described above, the requirements information can describe the minimum requirements of the required ECU capabilities that the capabilities of the target ECU need to meet. An exemplary structure of the requirements information that describes the minimum requirements of the required ECU capabilities can be as follows. More specifically, the exemplary structure describes the minimum requirements of a CAN-bus device that the target ECU needs to provide. apiVersion: v1 kind: Pod metadata: name: sample-container-image spec: containers: - name: image: "sample-container-image:v0.1" resources: limits: canbus-hardware-can1: 1 (api version: v1 kind: Pod metadata: name: sample-container-image spec: containers: - name: image: sample "-container-image:v0.1" resources: limits: CAN bus-hardware-CAN1: 1)

[0079] The ability information may include: runtime environment ability, where the runtime environment ability indicates the runtime environment available for running containers at the ECU as an ability; and / or resource ability, where the resource ability indicates the resources available for running containers at the ECU as an ability. As Figure 3 shown, the ability information can be processed by the extension 320.

[0080] An exemplary structure of the ability information of a specific worker node may be as follows. The worker node indicates that, as a resource ability, the worker node includes a shared memory device. The exemplary structure can be obtained by an electronic device (e.g., an orchestrator scheduler) from the worker node.

[0081] Another exemplary structure of the ability information may be as follows. The worker node indicates that, as a resource ability, the worker node includes two CAN devices. The exemplary structure can be obtained by an electronic device (e.g., an orchestrator scheduler) from the worker node.

[0082] When selecting a target ECU, the electronic component can compare the requirement information of the software's container (e.g., using the manifest of the sample-container shown above) with the ability information of the worker nodes in the vehicle (e.g., using the manifest of the nodes shown above) to determine the ability of the target ECU that meets the required ECU ability. For example, the electronic component can determine whether there is a worker that provides ability information (e.g., device: "shared-memory-device") that meets the requirement information of the container (e.g., device: "shared-memory-device").

[0083] In other examples, the electronic component can determine the availability of a container or an update of a container at a server (e.g., at the OTA server 210), and download the container or the update from the server. The electronic component can further verify the container or the update, and store the container in the local registry of the vehicle (e.g., the local registry 230), or use the update to update the container in the local registry so that the container is available for deployment.

[0084] In some examples, the electronic component can determine whether the vehicle is in a valid state that allows the deployment of the container, and delay or continue to select the target ECU based on the valid state. The electronic component can further deploy the container to the target ECU for installation on the target ECU, thereby deploying the software.

[0085] According to an embodiment of the present disclosure, a representation Figure 1 An electronic control unit (ECU) of a vehicle representing one of the ECUs 120, 130, 140 shown in Figure 1 is configured to cooperate with a controller shown in

[0086] and execute examples of the methods described above. More specifically, the ECU may include a processor and a memory storing instructions that, when executed by the processor, cause the processor to perform one or more of the operations of these examples. For example, the ECU may include an extended (abstract) orchestration agent as described above to perform one or more of the operations. In some examples, the ECU may also include circuitry configured to perform one or more of the operations of these examples.

[0087] Accordingly, the ECU may provide a set of capability information of the ECU (i.e., the capabilities of the ECU) to the controller 110. Figure 3 The capability information may be processed by an extension 320 as shown in

[0088] The exemplary structure of the capability information of a particular worker node is shown and discussed above. The worker node provides the structure to the orchestration scheduler.

[0089] In some examples, the ECU selected by the controller as the target ECU may receive a container for deployment of software on the ECU. Then, the ECU may install the container to deploy the software, verify the installation status of the container, and uninstall the container and restore the previous version of the container in response to an error or failure (i.e., a failure) in the verification.

[0090] Figure 5 FIG. illustrates a structure to be used by a method 400 for deploying software in a vehicle according to an embodiment of the present disclosure.

[0091] In Figure 5 FIG., a controller 110 that may execute method 400 is illustrated. As described above, the controller 110 obtains a set of capability information from the ECUs of the vehicle and obtains a set of requirement information for the software to be deployed.

[0092] In some examples, the software to be deployed may be represented by, or included in, an application container 510. The application container 510 may include one or more images representing the code of the software, and one or more software libraries required by the software. The application container 510 further includes a manifest 520, which represents or describes a set of requirement information for the software to be deployed. The set of requirement information describes one or more requirements of the software that enable the software to run or be executed on the ECU of a vehicle. For example, the set of requirement information describes the required ECU capabilities that the software (e.g., container) needs at the time of deployment. The manifest 520 may have the structure as described above.

[0093] For example, the requirement information may include: runtime environment requirement information, which indicates the runtime environment required for the software, as a required ECU capability, to run on the ECU; and / or resource requirement information, which indicates the resources required for the software, as a required ECU capability, to run on the ECU.

[0094] In other words, the controller 110 obtains the manifest 520 from the application container 510 and determines the set of requirement information based on the manifest 520.

[0095] Similarly, the controller 110 obtains a node manifest 530 from each ECU in the ECU of the vehicle 100 and determines a set of capability information based on the node manifest 530. The node manifest 530 may have the structure as described above.

[0096] The set of capability information describes at least one capability of the ECU and is represented by or described in the node manifest 530. For example, the set of capability information may include: runtime environment capability information, which indicates the runtime environment available at the ECU, as a capability of the ECU, for running software; and / or resource capability information, which indicates the resources available at the ECU, as a capability of the ECU, for running software. In Figure 5 the example shown, the set of capability information may include information about the kernel of the operating system 540 running on the ECU, information about the stable interface (e.g., POSIX) 550 provided by the ECU to the software, and / or information about the hardware resources 560 of the ECU (such as (multiple) capacities, (multiple) network devices, (multiple) input / output (I / O) devices, (multiple) accelerators, etc.).

[0097] Now referring to Figure 6 and Figure 7 , a flowchart illustrating aspects of a method 400 for deploying software in a vehicle according to an embodiment of the present disclosure will be described.

[0098] Flowcharts 600, 700 may be executed in a vehicle such as vehicle 100 as shown in Figure 1 As described above, vehicle 100 may include multiple ECUs (such as ECU 120, 130, 140) and a controller 110.

[0099] First, referring to Figure 6 the flowchart 600 shown in, the controller 110 of vehicle 100 may determine the availability (operation 605) of new software (e.g., a container of software or an update of a container) to be deployed to the vehicle at the server via an OTA connection. For example, the controller 110 may determine that new software exists in the repository of the server, and this information indicates the availability of the new software at the server. In some examples, the server may also indicate to the controller 110 that the new software is available at the server.

[0100] In response to determining the availability of new software to be deployed to the vehicle, the controller 110 may download the new software from the server via an OTA connection (operation 610). In other words, the controller 110 pulls the new software from the server. In some examples, the server may also push the new software to the controller 110.

[0101] In operation 615, the controller 110 may then verify the new software. For example, the controller 110 may verify the checksum of the new software. If the verification of the new software is successful, the controller 110 may store the new software in the local registry of the vehicle (e.g., Figure 2 the local registry 230 shown in), or use the new software to update the software in the local registry. In some examples, the controller 110 may also install the new software in the local registry and configure data in the local registry (or another storage device). The availability of the new software at the controller 110 may trigger a deployment process to deploy (i.e., install or update) the new software to the ECUs 120, 130, 140 of vehicle 100 (operation 620).

[0102] The controller 110 may then determine whether vehicle 100 is in a valid state that allows the deployment of new software (operation 625). In response to determining that vehicle 100 is not in a valid state, the controller 110 may delay the deployment process (operation 630), thus waiting to deploy the new software. Once vehicle 100 is in a valid state, the controller 110 may continue the deployment process and the operation of selecting one or more target ECUs to which the new software is to be deployed.

[0103] In operation 635, the controller 110 starts a deployment process to deploy the new software to the ECUs 120, 130, 140 of vehicle 100.

[0104] As part of this operation 635, the controller 110 obtains a set of capability information of a plurality of ECUs of the vehicle 110 and obtains a set of requirement information of the new software. The set of capability information describes at least one capability of the ECU, including: runtime environment capability information, which indicates a runtime environment available at the ECU as a capability of the ECU for running new software (e.g., a container); and / or resource capability information, which indicates resources available at the ECU as a capability of the ECU for running new software (e.g., a container). The set of requirement information describes one or more requirements of the new software for the new software to run or be executed on the ECU, including: runtime environment requirement information, which indicates a runtime environment required for the new software (e.g., a container) as a required ECU capability to run on the ECU; and / or resource requirement information, which indicates resources required for the new software (e.g., a container) as a required ECU capability to run on the ECU, and thus also indicates resources required for the new software to run on the ECU. In some examples, the controller may obtain a corresponding structure representing the set of capability information from each of the plurality of ECUs of the vehicle 110 and obtain a structure representing the set of requirement information from the new software.

[0105] In addition, as part of operation 635, the controller 110 selects one or more target ECUs from the plurality of ECUs based on the set of capability information and the set of requirement information. If the controller 110 determines that the capabilities of the ECU described by the set of information capabilities of the ECU meet the required ECU capabilities described by the set of requirement information of the container, the controller 110 selects the ECU as a target ECU. In some examples, the controller 110 may compare the set of capability information with the set of requirement information to determine the capabilities of the target ECUs that meet the required ECU capabilities.

[0106] In the case where none of the plurality of ECUs meets the required ECU capabilities (operation 640), the controller 110 may report to the server (operation 645). For example, the controller 110 may report an error that the new software cannot be deployed to any ECU of the vehicle 100. Otherwise, the controller 110 may deploy the new container to one or more target ECUs for installation thereon. For example, the controller 110 may provide the new software to one or more target ECUs and initiate the installation of the new software on one or more target ECUs.

[0107] Now refer to Figure 7In the flowchart 700 shown, each target ECU in the target ECUs can install new software or update existing software with the new software (operation 710). Once the installation / update is complete, the target ECU can verify the installation / update status of the new software on the target ECU (operation 720) and can report the verified status or result to the controller 110. In some examples, in response to a failure determined by the controller 110 based on the reported verification status or result (operation 730), the controller 110 can trigger a recovery process on the target ECU, including uninstalling the new software (operation 740) and restoring the previous version of the software (operation 750). In other examples, in the case where the target ECU determines a failure (operation 730), the target ECU can uninstall the new software (operation 740) and restore the previous version of the software by using a backup of the software or by retrieving and installing the previous version of the software from the controller 110 or the local registry (operation 750). In the case of success (operation 730), the deployment process ends (operation 760), and the target ECU and / or the controller 110 can send a corresponding report to the server.

[0108] Figure 8 is a graphical representation of the internal components of a computing system 800 that implements the functions described herein. For example, the computing system can represent Figure 1 the controller 110 shown in Figure 4 and execute instructions to perform the

[0109] The computing system 800 can be located in a vehicle and includes at least one processor 810, a user interface 820, a network interface 830, and a main memory 860 that communicate with each other via a bus 850. Optionally, the computing system 800 can further include a static memory 870 and a disk drive unit (not shown) that also communicate with the various components via the bus 850. Examples of the user interface 820 can include a video display, an alphanumeric input device, and a cursor control device.

[0110] In addition, the computing system 800 can also include a sensor interface 840 for communicating with the sensors of the vehicle. Alternatively, the computing system 600 can communicate with the sensors via the network interface 830. The sensors can be radar sensors, lidar scanners, light detection and ranging (LIDAR) sensors, etc. The computing system 800 can also be connected to a database system (not shown) via the network interface 830, where the database system stores additional data required to provide the functions described herein. The network interface 830 also connects the computing system 800 to a vehicle bus (e.g., CAN or LIN), and the computing system 800 communicates with other computing systems connected to the vehicle bus via the vehicle bus.

[0111] The main memory 860 can be a random access memory (RAM) and / or any other volatile memory. The main memory 860 can store program code 880 for executing the exemplary methods described herein. The memory 860 can also store additional program data 882 required to provide the functions described herein. Portions of the program data 882 and / or the program code 880 can also be stored in a separate memory (e.g., cloud memory) and executed remotely at least in part, or they can also be stored in the cache 890.

[0112] A computer-readable storage medium (which is inherently non-transitory) can include volatile and non-volatile, as well as removable and non-removable tangible media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. The computer-readable storage medium can further include random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid state storage technologies, portable compact disc read-only memory (CD-ROM) or other optical storage, magnetic tape cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store the required information and can be read by a computer.

[0113] A computer-readable storage medium should not be construed as a transient signal per se (e.g., radio waves or other propagating electromagnetic waves, electromagnetic waves propagating through a transmission medium such as a waveguide, or electrical signals propagating through wires). Computer-readable program instructions can be downloaded from a computer-readable storage medium to a computer, another type of programmable data processing apparatus, or another device, or downloaded to an external computer or external storage device via a network.

[0114] It should be appreciated that although specific embodiments and variations have been described herein, further modifications and alternatives will be apparent to those skilled in the art. In particular, the examples are provided by way of illustration of the principles and to provide a variety of specific methods and arrangements for implementing aspects of the present disclosure.

[0115] In certain embodiments, the functions and / or actions specified in the flowcharts, sequence diagrams, and / or block diagrams can be reordered, processed serially, and / or processed simultaneously without departing from the scope of the present disclosure. Additionally, any of the flowcharts, sequence diagrams, and / or block diagrams can include more or fewer blocks than those shown in the embodiments of the present invention.

[0116] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of embodiments of the present disclosure. It will be further understood that the terms "comprise" and / or "comprising," when used in this specification, specify the presence of stated features, integers, acts, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, acts, operations, elements, components, and / or groups thereof. Further, to the extent that the terms "include," "have," "carry," "comprised of," or variants thereof are used in the detailed description or claims, such terms are intended to be inclusive in a manner similar to the term "comprising."

[0117] Although the description of the various embodiments has set forth all of the content of the present disclosure and although those embodiments have been described in considerable detail, it is not the intention to limit or in any way restrict the scope of the appended claims to such details. Additional advantages and modifications will be apparent to those skilled in the art. Accordingly, the present disclosure is not limited in its broader aspects to the specific details, representative apparatus and methods, and illustrative examples shown and described. Thus, the described embodiments should be understood as being provided by way of example only, intended to teach general features and principles and not to be construed as limiting the scope defined by the appended claims.

Claims

1. A computer-implemented method for deploying software in a vehicle, the method comprising, at a controller of the vehicle: - obtaining a capability information set of each ECU among a plurality of electronic control units ECU of the vehicle, wherein the capability information set describes the capability of the ECU; - in response to the container of the software being available for deployment, obtaining a set of requirement information for the container, the set of requirement information describing required ECU capabilities required for the container in order to be deployed on one or more ECUs of the plurality of ECUs; and -selecting a target ECU for deploying the container from the plurality of ECUs based on the capability information set and the requirement information set, so that the capabilities of the target ECU described by the capability information set of the target ECU meet the required ECU capabilities described by the requirement information set of the container.

2. The computer-implemented method of claim 1, wherein: Selecting the target ECU includes, at the controller: - comparing the capability information set with the requirement information set to determine the capabilities of the target ECU that meet the required ECU capabilities.

3. The computer-implemented method of claim 2, wherein: The requirement information describes the minimum requirements of the required ECU capabilities that the capabilities of the target ECU must meet.

4. The computer-implemented method of any one of claims 1 to 3, wherein: The requirement information includes: a runtime environment requirement, wherein the runtime environment requirement indicates a runtime environment required for the container as the required ECU capability to run on one or more ECUs among the multiple ECUs; and / or a resource requirement, wherein the resource requirement indicates a resource required for the container as the required ECU capability to run on one or more ECUs among the multiple ECUs.

5. The computer-implemented method of any one of claims 1 to 4, wherein: The capability information includes: runtime environment capability, the runtime environment capability indicating the runtime environment that can be used to run the container at the ECU as the capability; and / or resource capability, the resource capability indicating the resources that can be used to run the container at the ECU as the capability.

6. A computer-implemented method as claimed in claim 4 or 5, characterized in that The runtime environment includes information related to one or more of the following: an operating system, software, libraries, and configuration parameters; and / or wherein the resources include information related to one or more of the following: a processor, memory, capacity, network devices, input / output devices, and accelerators.

7. The computer-implemented method of any one of claims 1 to 6, further comprising at the control: - determining the availability of said container or an update of said container at a server via an over-the-air (OTA) connection; and - downloading the container or the update from the server via the OTA connection.

8. The computer-implemented method of claim 7, further comprising, at the controller: - verifying the container or the update; and - Storing the container in a local registry of the vehicle, or updating the container in the local registry with the update, to make the container available for deployment.

9. The computer-implemented method of any one of claims 1 to 8, further comprising at the control: - determining whether the vehicle is in a valid state to allow deployment of the container; and - Based on the validity status, delay or continue selecting the target ECU.

10. The computer-implemented method of any one of claims 1 to 9, further comprising at the control: - deploying the container to the target ECU to be installed on the target ECU, thereby deploying the software.

11. The computer-implemented method of claim 10, further comprising, at the target ECU: - installing the container to deploy the software; - verifying the installation status of the container on the target ECU; and - In response to a verification failure, uninstalling the container and restoring a previous version of the container.

12. The computer-implemented method of any one of claims 1 to 11, wherein: The multiple ECUs include ECUs of different platforms, and the different platforms include at least one of the following: different hardware platforms, different operating systems, different virtual runtime environments, and different application programming interfaces.

13. An apparatus for use in a vehicle, the apparatus comprising a processor configured to perform the method of any one of claims 1 to 12.

14. A computer program product comprising instructions which, when executed by one or more computers, cause the one or more computers to perform the method according to any one of claims 1 to 12.

15. A computer-readable data carrier having stored thereon a computer program product as claimed in claim 14.

Images