Installing and updating software in vehicle

Abstract

The invention relates to installing and updating software in a vehicle. A method for updating software in a vehicle including a controller and a plurality of electronic control units (ECUs) of different platforms. The controller receives a container associated with one of the different platforms used by at least one of the plurality of ECUs, the container including a plurality of container layers including at least a software application layer having a software application package installable at the platform. The controller determines at least one ECU of the plurality of ECUs that utilizes the platform. The controller initiates installation of the software application package at the at least one ECU. Effective software installation is achieved at the vehicle as compared to, for example, installation of the entire software system of the vehicle.

Description

Technical Field

[0001] The present disclosure generally relates to a method of installing software in a vehicle including an electronic control unit (ECU) having a plurality of different platforms. Background Art

[0002] Over-the-air (OTA) remote software updates in vehicles are a relatively new feature and have not been well handled because they were not previously required. As the transition to software-defined vehicles has begun, there is a need to provide new features and security updates throughout the vehicle's life. Vehicles are equipped with various electronic control units (ECUs) that are used for different purposes and are equipped with different software. This requires keeping the software of the ECUs up-to-date during the life of the vehicle and extending or correcting errors in the software. Summary of the Invention

[0003] Therefore, there is a need for software updates in vehicles.

[0004] According to a first aspect, there is provided a method of updating software in a vehicle including a controller and a plurality of electronic control units (ECUs) of different platforms. The controller receives a container associated with a platform used by at least one of the plurality of ECUs in the different platforms, the container including a plurality of container layers, the container layers at least including a software application layer having a software application package capable of being installed at the platform. The controller determines at least one ECU among the plurality of ECUs that utilizes the platform. The controller initiates installation of the software application package at the at least one ECU.

[0005] In some examples of the first aspect, the container layer further includes an installation layer having an installer configured to install the software application package at the at least one ECU. The method further includes using the installer to install the software application package at the at least one ECU.

[0006] In some examples of the first aspect, the container layer further includes a library layer having libraries for running the container and a manifest having configuration information of the container.

[0007] In some examples of the first aspect, the container is received from a software update repository storing software updates for ECUs of different platforms or from an original equipment manufacturer of the at least one ECU.

[0008] In some examples of the first aspect, the container is received through a communication interface of the vehicle, the communication interface being configured to receive containerized software updates for ECUs of different platforms.

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

[0010] In some examples of the first aspect, the method further includes performing a test installation in a virtual system that emulates the platform associated with the container before installing the software application package at at least one ECU; verifying the test installation; and if the verification is positive, installing the software application package at the at least one ECU.

[0011] In a second aspect, there is provided a vehicle assistance system for performing vehicle control functions, the vehicle assistance system including a control unit and a plurality of computing units, the vehicle assistance system being configured to perform a computer-implemented method as described herein.

[0012] In a third aspect, there is provided a vehicle including the vehicle assistance system for installing software in a vehicle as described herein.

[0013] In a fourth aspect, there is provided a computer program containing instructions that, when executed by a computer, cause the computer to perform the method described herein.

[0014] These and other objects, embodiments, and advantages will become apparent to those skilled in the art from the following detailed description of the embodiments with reference to the accompanying drawings. The present invention is not limited to any particular embodiment. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Aspects and examples of the present disclosure are described with reference to the following drawings, in which:

[0016] Figure 1 The (intelligent) vehicle described herein is shown.

[0017] Figure 2 A flowchart of the software update described herein is depicted.

[0018] Figure 3 The vehicle area described herein is shown.

[0019] Figure 4 The container layer described herein is depicted.

[0020] Figure 5 Another flowchart of the software update described herein is depicted.

[0021] Figure 6 Additional container layers described herein are shown.

[0022] Figure 7 A software repository for storing software updates is depicted.

[0023] Figure 8 Shows a vehicle interface for installing and updating software as described herein.

[0024] Figure 9 Shows the platform described herein.

[0025] Figure 10 Describes a third flowchart of the software update described herein.

[0026] Figure 11 Shows a vehicle assistance system.

[0027] Figure 12 Schematically shows a vehicle including the vehicle assistance system described herein.

[0028] Figure 13 Is a graphical representation of the internal components of a data processing system included in a vehicle assistance system. Detailed Description

[0029] The present disclosure relates to a method of installing software in a vehicle. Before discussing specific aspects of the present disclosure, some general aspects are revisited and terms used hereinafter are briefly explained.

[0030] Software updates are relevant aspects of vehicle maintenance and feature growth throughout the life of a vehicle. However, the complexity of the hardware systems and software architectures actually makes software updates in vehicles a difficult task for many original equipment manufacturers (OEMs). In addition, the software supply chain involves many different partners, such as software developers, manufacturers, and suppliers who create complex software for different parts of vehicle functions, and the software typically needs to be integrated together in one system of the vehicle and tested and verified before it may enter production, which further complicates software updates in vehicles.

[0031] Current vehicles already have up to 150 million lines of software code, and an increasing number of hardware platforms (such as sensors and software features) need to address many issues, such as hardware and software dependencies, resource availability and consumption, backward compatibility, and safety and security requirements.

[0032] In addition, there is currently no standardized hardware or software platform for abstracting dependencies on dedicated hardware and basic services to simplify the software update process. Today, each OEM creates its own way of software updating (such as over-the-air (OTA) software updates) as well as its own way of software separation. This includes physical separation for different ECUs, for example, virtualization using a hypervisor (e.g., virtual machines) or software architectures that attempt to separate software modules from each other. Therefore, managing the increasing complexity and number of ECUs in a vehicle has become a challenge for original equipment manufacturers (OEMs).

[0033] Currently, there are some early standards (such as eSync) that attempt to unify the update process. The standards focus on a secure and reliable way to provide bits from a server in the cloud to a vehicle. However, so far, the standards do not provide a solution for updating the software of different platforms (e.g., ECUs of different OEMs) in a consistent and reliable manner. In addition, the standards do not address issues such as software packaging.

[0034] The term "installing software" as mentioned here includes the first installation of software or software components, as well as the update, upgrade, and flashing of software and software components. In addition, the term "software" as mentioned here refers to all types of software required for a vehicle-based computing system, including, for example, software for the basic input / output system (BIOS), hardware-specific code, hardware drivers, protocol software, and application software.

[0035] For example, the flashing scheme allows the ECU to provide new software during engineering, manufacturing, and after vehicle delivery in a repair shop or directly in a customer vehicle. Over-the-air (OTA) updates enable the software in the vehicle to be updated remotely and also enable several vehicles to be flashed in parallel. As part of this process, the entire ECU software image can be replaced with a newer version, and the time taken to update the software often takes several hours to complete. This depends partly on the size of the software update, the target memory, the protocol, and whether encryption is used. The previously installed software may have no relevance to the new update, which may be beneficial if the previous version needs to be completely replaced rather than a specific part upgraded. The size of the image binary affects the time taken to transfer and download the file. The new updated software image must also be stored within the target ECU, which requires redundant storage, for example, to facilitate any future software updates. On the other hand, when using differential or incremental file flashing for software updates, the base file can be compared with the file of the new version, and a delta or differential file can be created, thus reducing the size of the update. Compared with a full binary software update, the differential or incremental software update is approximately 10% less than the full binary file size. The delta file is transferred much faster, reducing the total transfer time by up to 90%.

[0036] A zonal ECU architecture in a vehicle means that there is a variety of heterogeneous software for many existing ECUs in the vehicle. Vehicle zones form a layer that is part of the vehicle's electrical / electronic (E / E) architecture, which connects the vehicle's computing layer to (hundreds of) actuators, sensors, mechatronics, and intelligent ECUs. In a vehicle zone, an ECU can act as a zonal gateway ECU for providing functions for the vehicle zone, such as switching IP devices and backbones, performing gateway functions for legacy devices (LIN, CAN...), power delivery (PoDL, power cables), eSwitch / eFuse functions, additional computing power capabilities, etc. The zonal architecture will facilitate sensors and actuators to be independent of the central vehicle computing node. Therefore, the hardware and software update cycles can be different, and the sensor and actuator designs can last through more vehicle design cycles. The zonal architecture will reduce the number of ECUs and cable lengths, simplifying the vehicle architecture and associated system verification efforts. As an example, the zonal architecture can save 50% or more of the wire harness length for controlling and distributing data and power distribution within the vehicle.

[0037] An ECU utilizes or runs on one or more platforms. The term "platform" as used here can refer to any kind of software and / or hardware platform. In some embodiments, different platforms for vehicle ECUs can refer to different computing or software platforms, such as different operating systems, different computing architectures, different processor architectures, different protocol stacks, different virtualization mechanisms.

[0038] For example, some vehicle ECUs run on UNIX or LINUX platforms, while other vehicle ECUs are small embedded systems with only a few hundred lines of code (e.g., using a microkernel or even having no operating system at all). Other ECUs can be high-performance systems, such as a central controller. Other ECUs can run on dedicated platforms such as radar- or camera-based sensors. Some ECUs can run on an Intel x86 processor architecture, while other ECUs can run on an ARM processor architecture. ECUs can be characterized by multiple different platforms. For example, one ECU can be characterized by an Intel x86 processor architecture and run a high-level OS (HLOS) such as LINUX, while another ECU can be characterized by an ARM processor architecture and run an RTOS (real-time OS) such as VxWork, and another ECU can be characterized by an ARM processor architecture and run a Red Hat LINUX distribution. In some embodiments, the platform can include virtual machines, as described in subsequent paragraphs of this disclosure.

[0039] In fact, the typical heterogeneity of ECUs in terms of their different platforms involves different roles and functions of the ECUs (as described above, ranging from high-end computing machines to lightweight embedded systems including, for example, different specific sensors). Different ECUs are also typically provided by different OEMs, and the OEMs use different platforms for their ECUs. For example, one ECU provided by a first OEM is characterized by a first platform, while another ECU provided by a second OEM is characterized by a second platform.

[0040] The term "container" as referred to herein is understood to have its established meaning in the field of computer virtualization. A container image can include a portable package having executable code and its dependencies, libraries, etc. A runtime container can include an independent runtime instance in an operating system created from the container image, and the container image separates the code within the container from the host and other containers. Thus, the containers encompassed by the present disclosure are functional and portable cloud or non-cloud images around an application, and are independent of other environments. A container can contain one or more different software applications and also run isolated processes by bundling relevant configuration files, libraries, and dependencies together. Thus, containers eliminate most of the complexity of installing and configuring software, and are therefore suitable for automotive environments where the installation of a particular software or software component is particularly desired to be independent of other software and software components and secure.

[0041] Containers can be configured to be isolated; however, containers can send and receive requests to other applications (such as vehicle applications) by using corresponding communication technologies.

[0042] The term "containerized application" as referred to herein is understood to be a software application that runs in a container providing the isolated runtime environment described above. The container encapsulates the application with all its dependencies, including system libraries, binaries, and configuration files. This encapsulation allows the application to run consistently on different hosts, thereby enabling, for example, a development team to write the application once and run the application on multiple hosts, making the containerized application portable. Containerized applications do not include their own operating systems. Instead, different containerized applications running on a host system share the existing OS provided by that host system. The process of converting an application into its separate, abstract form is called containerization. Containerized applications can be tested as a unit and deployed as container image instances to a host operating system.

[0043] Figure 1The current intelligent vehicle 1 is shown. The vehicle 1 includes a controller 2 and multiple electronic control units (ECUs) 3, 4, 5 that control one or more electrical systems or subsystems in the vehicle 1. The ECUs 3, 4, 5 may include at least one of the following: an engine control module (ECM), a powertrain control module (PCM), a transmission control module (TCM), a brake control module (BCM or EBCM), a central control module (CCM), a central timing module (CTM), a general electronic module (GEM), a body control module (BCM), and a suspension control module (SCM).

[0044] The ECUs of the vehicle (such as the ECUs 3, 4, and 5 of vehicle 1) may form separate computers. In some embodiments, the components of an ECU include several separate control modules (for example, the PCM often controls both the engine and the transmission). The controller 2 performs settings such as for the center of mass, inertia, axles, steering, braking, tires, the powertrain (engine, clutch, transmission, reducer, driveline), driver assistance, and safety assistance.

[0045] As described above, at least some of the ECUs 3, 4, 5 of vehicle 1 are characterized by one or more different platforms, for example, they serve different functions and / or are provided by different OEMs.

[0046] According to one aspect, Figure 2 A flowchart for updating software in an (intelligent) vehicle 1 is shown. The (intelligent) vehicle 1 includes a controller 2 and electronic control units ECUs 3, 4, 5 of multiple different platforms. In activity 10, the controller 2 receives a container associated with one platform used by at least one of the multiple ECUs 3, 4, 5 in different platforms. The container includes multiple container layers, and the container layers at least include a software application layer having a software application package that can be installed on the platform. In activity 11, the controller 2 determines at least one of the multiple ECUs 3, 4, 5 that utilizes the platform. In activity 12, the controller 2 initiates the installation of the software application package at the at least one ECU. Since the container is isolated from other containers, software applications for individual vehicle functions can be installed (and updated) in their own containers at vehicle 1.

[0047] In particular, using one and the same container standard (or de facto standard) for any software update of any ECU in a vehicle makes the software update process in the vehicle less complex, because the controller unit responsible for controlling any software update only needs to handle this type of container, and the remaining software update heterogeneity in terms of different platforms, different software types, different update types, etc. is hidden within the container. The container brings the software to be updated or the software to be installed, the routine for unpacking the software update, the installation routine specifically adapted to the target platform of the ECU to be updated, etc.

[0048] In an embodiment, the container itself can carry specifications, such as an identifier indicating which platform and / or ECU's software package the container carries. The central update controller in the vehicle (e.g., controller 2 of vehicle 1) reads this identifier and calls the container with the corresponding target ECU as a parameter. In an embodiment, the identifier related to the ECU can be in the functional data related to or included in the container and can be accessed by the central update controller of the vehicle. For example, the identifier can be part of the manifest of the container. The identifier can include the unique identifier of one or more ECUs (or nodes) for which the software package must be installed or the software upgrade must be performed. The unique identifier may have been previously stored at controller 2 and the corresponding ECUs so that controller 2 can precisely schedule the distribution of the container to those ECUs to which the container is bound.

[0049] Thus, compared to the installation of, for example, the entire software system of vehicle 1, Figure 2 the method enables efficient software installation at the vehicle. In addition, Figure 2 the method shown can facilitate a more secure software installation.

[0050] In some embodiments, ECUs 3, 4, 5 can be vehicle area controllers for controlling areas of the vehicle. The areas of the vehicle can include computers, controllers, sensors, and actuators responsible for certain functions of the vehicle, such as the control of electric motors, braking and steering systems, driver assistance systems, etc., as will be described in detail for some examples below. Figure 3 Vehicle 1 is shown, which includes a plurality of vehicle areas controlled and supervised by ECUs, such as area 300 controlled by ECU 300, area 400 controlled by ECU 400, and area 500 controlled by ECU 5.

[0051] Each vehicle sensor and actuator can be connected to a local vehicle area controller based on its location and function within the vehicle. The area controller can perform local data transformation, can aggregate data and can place the data on a single high-speed cable connected to the vehicle computer. The area controller can handle communication (commands, signals, data) with end devices via a Controller Area Network (CAN) or Local Interconnect Network (LIN) bus to sensors and actuators related to the ECU or body control, or via an Ethernet or Low-Voltage Differential Signaling (LVDS) interface to cameras or other Advanced Driver Assistance System (ADAS) sensors, thus adopting the data formats used by these devices. The area controller can aggregate the transmitted data onto Ethernet or PCI Express for, e.g., high-bandwidth ADAS sensors, or onto CAN-FD (CAN - Flexible Data Rate) for low-bandwidth body control functions, and can send the data to the appropriate domain controller. In this way, the I / O is separated from the vehicle computer.

[0052] As an example of an area controller, the Powertrain and Chassis Controller (PCC) is responsible for vehicle dynamics, which includes the electric motor / transmission, braking, steering, and suspension. As another example, the Central Vehicle Controller (CVC) can be responsible for body control and overall network management. The CVC can be composed of one or more of Controller 2 or ECUs 3, 4, 5, and can serve as the body and powertrain master device for all area controllers of Vehicle 1. The CVC can also handle the communication of Vehicle 1 with the outside world. The CVC can receive software programs and updates for installation at ECUs 3, 4, 5, for example, via an Over-the-Air (OTA) interface 9 as shown, and distribute them to ECUs 3, 4, 5 in Vehicle 1 as needed. The CVC can have its own direct connection to area controllers (such as ECUs 3, 4, 5) for sending software programs and updates to the area controllers for installation at vehicle end devices (including sensors and actuators connected to them). Figure 3 In an implementation, the container can be implemented by a (virtually) standardized container image like the OCI standard. Such a standardized or virtually standardized container is general-purpose and allows encapsulation of any kind of software that can be updated. The software can include files, application runtime containers with corresponding dependencies, firmware, a base operating system (OS) image.

[0053]

[0054] ​A container according to an embodiment may include an image having a layered format. The container image may provide a single functional unit, may have an independent release cycle, and may provide deployment and runtime isolation. The container image may be a standard box for software. The box may have a standard interface that remains the same regardless of the application stored inside it. Through the container image, any kind of software deployed to the vehicle software can be independently encapsulated and loaded. In addition, the container image can implement software updates and tool standardization in the complete path starting from, for example, the cloud to the vehicle 1. Due to the layered format of the image, incremental / differential updates are possible, thereby reducing the amount of data sent to the vehicle. Therefore, by placing any kind of software running in the vehicle 1 into a standardized container, the software build, test, shipment, and installation in the vehicle 1 can be simplified and performed more efficiently.

[0055] After the image is built, it can be shared by, for example, the corresponding software development team on a network such as a cellular network. Then, an operator such as a vehicle maintenance team can copy it to the machines (such as the ECUs 3, 4, 5 of the vehicle 1) where they want to run the encapsulated software.

[0056] A container, such as a standard container using a standard package format, may include additional and / or updated software applications for one or more containerized platforms and for one or more non-containerized platforms. In some embodiments, the container includes runtime containers, such as application containers and / or installation containers.

[0057] In some embodiments and as Figure 4 shown, the container layers 21, 22 also include an installation layer 22 having an installer configured to install software application packages, such as Figure 4 applications 1 and 2, at at least one of the ECUs 3, 4, 5. The container layer 21 may include, for example, one or more software applications to be installed. As Figure 5 shown, the update of the software in the (intelligent) vehicle 1 also includes using the installer at the controller 2 to install software application packages at at least one of the ECUs 3, 4, 5. Considering the specific hardware and software requirements of the ECUs 3, 4, 5, the installation layer 22 having the installer is particularly configured to install system software on the ECUs 3, 4, 5.

[0058] The installation of the software application package can be controlled by the controller 2 by, for example, controlling and manipulating a container engine that runs the container. The container engine may include software components that enable the controller 2 to act as a container host. The container engine can start and manage the container. The container engine may include a container runtime for running the container and for handling the storage needs of the container on the local system.

[0059] In an embodiment, the installation of the software application package at one or more ECUs can be performed by an agent-based system, where the controller 2 operates as the master unit, and software installation agents are installed at each ECU. The agents utilize container standards applicable to different ECU types to perform software installation and updates. The agents make the ECUs visible to the master controller 2 and enable a unified software installation and update process at the ECUs of the vehicle 1.

[0060] When receiving a container for software installation or software update at certain ECUs, the master controller 2 can identify the corresponding ECU, for example, by using the unique identifier of each ECU included in the manifest of the container. Then, the master controller 2 can instruct the corresponding agent of the ECU to perform the requested software installation and update. In response, the agent can extract the container from, for example, a (local) repository located at the controller 2 and can push the container to the ECU. Then, the agent can open the container, install the files, set the necessary permissions and report to the master controller 2.

[0061] The agent-based system or the lightweight agent-based system can also be applied to software installation and updates in an embedded system integrated in the vehicle 1, where the embedded system applies an application programming interface (API) as a standard interface for receiving software packages, for example, from the master controller 2.

[0062] The installation layer 22 can include a flashing application or a flasher for installing the software application package. The flasher can be updated together with the image to ensure compatibility. Thus, there is no need to maintain a specific installer on the vehicle platform.

[0063] The image can include a package for transmitting the software to be installed in the vehicle 1. Once the software is installed in the vehicle 1, the image may be corrupted.

[0064] In some embodiments and as Figure 6 shown, the container layer further includes a library layer 23 and a manifest 24, the library layer 23 having libraries for running the containers, and the manifest 24 having configuration information of the containers.

[0065] The libraries can include a general collection of code templates and algorithms that allow for easy implementation of common data structures such as queues, lists, and stacks. Multiple containers can also allow sharing of the libraries or other digital resources through volumes and still remain separated while doing so. The manifest 24 can include an image manifest that provides the configuration and requirements for a single container image for a specific architecture and operating system, such as those for regions 300, 400, and 500 of the vehicle 1.

[0066] The image can be reconstructed at the target system of the vehicle 1 (e.g., at the ECUs 3, 4, 5). The reconstruction of the image can be driven by Listing 24. Additionally, the container can include a registry that stores records of the container layers and how the layers contribute to the reconstruction of the image.

[0067] When installing and updating software in a vehicle, using containers for installing and updating software in the vehicle enables the application of unified standards. The container standards enable different software development teams and companies to independently build software, integrate the software into the entire codebase of the vehicle, and perform automated tests. The container standards also enable faster software integration, reduce software errors, and enable timely updates via over-the-air (OTA) before and after the vehicle is manufactured. Containers according to embodiments contain everything required at build time and generally solve individual problems by encapsulating software dependencies and allowing for secure and easy software installation and updates. Thus, the reusability and replaceability of software (components) are enhanced. Generally, containerized applications are immutable, but once installed in, for example, an area of the vehicle, these applications can be changed between different environments. Thus, containerized applications also enable easier testing of software components with respect to a specific environment. Additionally, containerized applications enable the migration of traditional functions from electronic control units to a centralized domain controller without adversely affecting the security of the general system.

[0068] In Figure 7 Some of the embodiments shown, the container 7 is received from a software update repository 6 that stores the software to be installed and software updates for the ECUs 3, 4, 5 for different platforms or from the original equipment manufacturer (OEM) of at least one ECU. The software update repository 6 can include a cloud platform operated by the OEM manufacturer or software manufacturer / supplier or other third-party supplier. In some embodiments, a local repository installed at the vehicle 1 can be applied to pull software packages from the update repository 6. The local repository can store the current version of the container image and can also store, for example, previous image versions for remedying software errors that occur in the ECUs.

[0069] In some embodiments and as Figure 8 shown, the container 7 is received via a communication interface 8 of the vehicle 1, and the communication interface 8 is configured to receive containerized software updates for the ECUs 3, 4, 5 for different platforms. Thus, software installations and updates from different development teams and manufacturers can be installed on the vehicle 1.

[0070] As has been described in the present disclosure and in Figure 3As shown, the communication interface may include an Over-the-Air (OTA) interface. This enables the downloading of software applications, services, and configurations via a mobile or cellular network. Via OTA (e.g., Figure 3 OTA 9), software installation and updates can be delivered remotely and do not require a visit to a dealership or mechanic. This simplifies the software update process and allows for, e.g., easy bug fixes, thereby improving the reliability of the vehicle and its functions. Software updates using OTA address the issues associated with customer disruption and the inherent latency between the availability of a new software update and the deployment of that update to the target vehicle. Via vehicle connectivity, new automotive software updates can be pushed or pulled to the target vehicle at any time. For example, a software update pull request can be initiated by a consumer as part of an after-sales software upgrade or an additional automotive function. Push updates can be applied by an Original Equipment Manufacturer (OEM) or vehicle manufacturer to address identified software bugs or vulnerabilities, thereby circumventing the return / recall process and the required inherent latency.

[0071] In an embodiment and as Figure 9 shown, different platforms 30 include at least one of different hardware platforms 31, different operating systems 32, different virtual runtime environments 33, different application programming interfaces 34. This enables the platform to be adapted to the specific functions and groups of functions performed by the vehicle 1.

[0072] For example, the platform 30 can be adapted to the functions required for a driver assistance system involving body control of the driver of the vehicle 1. Body control can be processed via a CAN-FD network having a star topology characterized by a CVC at the center. The star topology is an effective method when the network is organized into manageable multiple regions, and it can support selective wake-up. Communication between ADAS sensors, e.g., constituted by the hardware platform 31, can be processed via a separate network based on the Ethernet Time-Sensitive Networking standard or Automotive PCI Express, and the separate network is connected to the CVC via a separate star topology network. When redundancy is required (at autonomous driving levels 3 and higher), the ADAS sensor network will form two rings, and the main nodes on the rings include a central computing node, a CVC, and a regional controller. Although the ring topology is moderately more expensive than the star topology it replaces, it reliably delivers fail-operational performance without the need for replication. Therefore, it is far more cost-effective than alternative methods for supporting level 3 and higher levels of autonomous driving.

[0073] The operating system 32 may include an operating system (OS) for embedded systems such as embedded Linux, BusyBox, uClibc, musllibc, and buildroot. Regions 300, 400, and 500 include ECUs 3, 4, 5, and other computing units, which may run different operating systems.

[0074] The virtual runtime environment 33 may include a Java runtime environment (JRE), such as a Java virtual machine (JVM). The application programming interface (API) 34 may include a remote API that allows developers to manipulate remote resources via a protocol and / or a specific standard for communication, where the protocol and / or specific standard allows different technologies to work together regardless of language or platform. The API 34 may also include a Web API, which is accessed from a client device (such as a mobile phone) of a driver or passenger of the vehicle 1, for example, using the hypertext transfer protocol (HTTP).

[0075] In an embodiment and as Figure 10 shown, Figure 2 the software update shown may also include, before installing the software application package in at least one ECU, in activity 14, performing a test installation in a virtual system that emulates a platform associated with a container, and in activity 15, validating the test installation; and if the validation is positive, installing the software application package at the at least one ECU. Activities 14 and 15 may be performed, for example, using a virtual laboratory capable of processing and analyzing large amounts of data. The virtual laboratory may include cloud-based software that is designed to process large, complex data sets and, through its optimized interface, is capable of providing a quick overview of the results and a detailed analysis to help identify problems. In addition, by using the virtual laboratory, different types of vehicle bus simulations and controls for all common bus systems such as CAN, LIN, and Flexray may be performed. Activities 14 and 15 may also be performed in a Java runtime environment (JRE) such as a Java virtual machine (JVM).

[0076] According to one aspect and as Figure 11 shown, a vehicle assistance system 40 for performing vehicle control functions is provided, the vehicle assistance system 40 including: a control unit 41 and a plurality of computing units 42 as described in the above paragraphs; the vehicle assistance system being configured to perform the method as described within the present disclosure.

[0077] According to one aspect and as Figure 12As shown, a vehicle 1 is provided, which includes a vehicle assistance system 50 as described in the above paragraphs, and the vehicle assistance system executes any of the methods described in the present disclosure. In the present disclosure, the term "vehicle" includes all types of vehicles, such as automobiles, autonomous driving vehicles, trams, railway cars, etc.

[0078] Figure 13 is an illustration of internal components of a data processing system 600 that implements the functions described herein, such as Figure 12 the vehicle assistance system 50. The data processing system 600 may be located in the vehicle and includes at least one processor 601, a user interface 602, a network interface 603, and a main memory 606 that communicate with each other via a bus 605. Optionally, the data processing system 600 may further include a static memory 607 and a hard disk drive unit (not shown), which also communicate with each other via the bus 605. A video display, an alphanumeric input device, and a cursor control device may be provided as examples of the user interface 602.

[0079] In addition, the data processing system 600 may further include a designated sensing interface 604 that communicates with the imaging system 300 of the vehicle. Alternatively, the data processing system 600 may communicate with the vehicle assistance system 50 via the network interface 603. The data processing system 600 may also be connected to a database system (not shown) via the network interface, where the database system stores at least a portion of the images required to provide the functions described herein.

[0080] The main memory 606 may be a random access memory (RAM) and / or any other volatile memory. The main memory 606 may store program codes for software update control 608 and vehicle assistance system control 609. The memory 606 may also store additional program data required to provide the functions described herein. A portion of the program data 610, the software update control 608, and / or the vehicle assistance system control 609 may also be stored in a separate, such as cloud memory, and executed at least partially remotely. In such an exemplary embodiment, the memory 606 may store the installed software and software updates in a cache 611 according to the methods described herein.

[0081] According to one aspect, a computer program containing instructions is provided. When the computer executes the program, these instructions cause the computer to execute the methods described herein. The program code embodied in any of the systems described herein can be distributed individually or jointly in various different forms as a program product. Specifically, the program code can be distributed using a computer-readable storage medium having computer-readable program instructions thereon for causing a processor to execute aspects of the embodiments described herein.

[0082] A non-transitory computer-readable storage medium, in essence, can include volatile and non-volatile, as well as removable and non-removable tangible media implemented by 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 also 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 memory technologies, portable compact disc read-only memory (CD-ROM) or other optical storage, magnetic tape cartridges, tapes, magnetic 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.

[0083] 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 transmitted through a wire). Computer-readable program instructions can be downloaded from a computer-readable storage medium to a computer, another type of programmable data processing device, or another device, or downloaded to an external computer or external storage device via a network.

[0084] It should be understood that although specific embodiments and variations are described herein, further modifications and substitutions will be apparent to those skilled in the relevant art. In particular, examples are provided by way of illustration of the principles, and a variety of specific methods and arrangements are provided for making these principles effective.

[0085] 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 concurrently without departing from the scope of the present invention. Additionally, any flowchart, sequence diagram, and / or block diagram can include more or fewer blocks than shown in the embodiments of the present invention.

[0086] The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit the embodiments of the present disclosure. It should also be understood that when used in this specification, the terms "comprising" and / or "including" specify the presence of the stated features, elements, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, elements, steps, operations, elements, components, and / or combinations thereof. Moreover, insofar as the terms "comprising", "having", "containing", "consisting of" or variants thereof are used in the detailed description or claims, these terms are intended to be inclusive in a manner similar to the term "including".

[0087] Although the description of the various embodiments has set forth all of the present invention and although these embodiments have been described in considerable detail, it is not the intention of the applicant to restrict or in any way limit the scope of the appended claims to such details. Further advantages and modifications will be apparent to those skilled in the art. Accordingly, the invention in its broader aspects is not limited to the specific details, representative apparatus and methods, and illustrative examples shown and described. The described embodiments are, therefore, to be considered in all respects only as illustrative and not restrictive, the purpose being to teach the general features and principles and not to limit the scope as defined by the appended claims.

Claims

1. A method for installing software in a vehicle, the vehicle comprising a controller and a plurality of electronic control units (ECU) of different platforms, wherein at the controller, the method comprises the following steps: Receiving a container associated with a platform utilized by at least one of the plurality of ECUs from among the different platforms, the container comprising a plurality of container layers, the container layers comprising at least: A software application layer, the software application layer having a software application package that can be installed on the platform; determining the at least one ECU among the plurality of ECUs that utilizes the platform; and Installation of the software application package is initiated at the at least one ECU.

2. The method according to claim 1, wherein: The container layer further comprises an installation layer having an installer configured to install the software application package at the at least one ECU, and wherein the method further comprises the steps of: The software application package is installed at the at least one ECU using the installer.

3. The method according to claim 1 or 2, wherein: The container layer further includes a library layer and a manifest, the library layer having a library for running the container, and the manifest having configuration information of the container.

4. The method according to any one of claims 1 to 3, wherein: The container is received from a software update repository storing software updates for ECUs of different platforms or from an original equipment manufacturer of the at least one ECU.

5. The method according to any one of claims 1 to 4, wherein: The container is received via a communication interface of the vehicle, the communication interface being configured to receive containerized software updates for ECUs of different platforms.

6. The method according to any one of claims 1 to 5, wherein: The different platforms include at least one of different hardware platforms, different operating systems, different virtual runtime environments, and different application programming interfaces.

7. The method according to any one of claims 1 to 6, further comprising the following steps: prior to installing the software application package at the at least one ECU, performing a test installation in a virtual system emulating a platform associated with the container; verifying said test installation; as well as If the verification is positive, the software application package is installed at the at least one ECU.

8. A vehicle assistance system for performing a vehicle control function, the vehicle assistance system comprising: Control unit; Multiple computing units; The vehicle assistance system is configured to perform the method according to any one of claims 1 to 7.

9. A vehicle comprising the vehicle assistance system according to claim 8.

10. A computer program product comprising instructions which, when executed on a computer, cause the computer to perform the method according to any one of claims 1 to 7.

Images