System and method for simulating OTA software updates for vehicles

Abstract

Methods, computing systems, and techniques for testing an update controller within a virtual environment are presented. An exemplary computing system accesses data that outlines the rules for delivering over-the-air (OTA) software updates. The computing system determines the actions to be taken to implement the OTA software update. These actions are based on the rules for delivering the OTA software update and mock behavior of external software services available to the update controller. The mock behavior simulates the response of external software services to requests from the update controller within an isolated virtual environment. The computing system accesses data that indicates the vehicle simulator is available for the OTA software update. The computing system generates a task package that includes the OTA software update and outlines the actions to be taken to implement it. The computing system outputs the task package to the vehicle simulator.

Description

Technical Field

[0001] Priority Claim This application claims the priority of U.S. Provisional Application No. 63 / 503,609, having a filing date of May 22, 2023, and U.S. Non - Provisional Application No. 8 / 353,587, having a filing date of July 17, 2023, and the entire contents of both are incorporated herein by reference in their entirety.

[0002] The present disclosure broadly relates to simulating the performance of a controller configured to perform over - the - air (OTA) software updates for a vehicle within a virtual environment.

Background Art

[0003] OTA (over - the - air) updates include the process of wirelessly updating the software of devices such as smartphones, IoT (Internet of Things) devices, or vehicles. OTA updates enable manufacturers to remotely push updates and patches to devices without the user having to connect the device or manually install the update. OTA updates are generally used for fixing software bugs, improving device performance, adding new features, and addressing security vulnerabilities. OTA updates have become increasingly common in recent years as more devices are connected to the Internet, making it easier for manufacturers to distribute updates quickly and efficiently.

Summary of the Invention

[0004] Aspects and advantages of implementations of the present disclosure are described in part in the following description, or will be understood from the description, or will be understood by practice of the implementations.

[0005] One exemplary aspect of this disclosure relates to a computing system. The computing system includes a control circuit configured to test an update controller for delivering over-the-air (OTA) software updates within an isolated virtual environment. The control circuit is configured to access data indicating rules for delivering the OTA software updates. The control circuit is configured to determine the actions taken to implement the OTA software updates. The actions are based on the rules for delivering the OTA software updates and mock behavior of external software services available to the update controller. The mock behavior simulates the response of the external software services to a request from the update controller within the isolated virtual environment. The control circuit is configured to access data indicating that a vehicle simulator is available for the OTA software updates. The control circuit is configured to generate a task package for the vehicle simulator that includes the OTA software updates and indicates the actions taken to implement the OTA software updates. The control circuit is configured to output the task package to the vehicle simulator within the isolated virtual environment.

[0006] In one embodiment, the control circuit is further configured to provision an isolated virtual environment which includes a simulated instance of the update controller, and which includes simulated management services and simulated vehicle services.

[0007] In one embodiment, to provision an isolated virtual environment, the control circuit is configured to provision a vehicle simulator, a simulated consumer service, and proxies to facilitate mock behavior of multiple external software services within the isolated virtual environment.

[0008] In one embodiment, rules for distributing OTA software updates are provided by a simulated consumer service.

[0009] In one embodiment, the simulated consumer service is configured to send communications to the vehicle simulator to trigger the vehicle simulator to provide data indicating that the vehicle simulator is available for an OTA software update.

[0010] In one embodiment, mock behavior is registered with the proxy before running a simulation test of the update controller.

[0011] In one embodiment, the mock behavior is based on the behavior of an external software service in a live environment.

[0012] In one embodiment, mock behavior is based on log data generated during communication between an update controller and an external software service in a live computing environment. The log data includes request parameters associated with the update controller, a response payload provided by the external software service, and a response time indicating the duration until the external software service responds to the update controller.

[0013] In one embodiment, log data is processed to determine the expected behavior of an external software service, and mock behavior is based on the expected behavior of the external software service.

[0014] In one embodiment, the control circuit is further configured to access information to help the vehicle simulator implement an OTA software update based on mock behavior of an external software service. The task package includes information to help the vehicle simulator implement an OTA software update.

[0015] In one embodiment, the external software service is a vehicle configuration service, and the information to assist the vehicle simulator in implementing an OTA software update includes vehicle configuration data for vehicle components associated with the OTA software update.

[0016] In one embodiment, the control circuit utilizes a cloud-based computing platform infrastructure.

[0017] In one embodiment, the isolated virtual environment is a first isolated virtual environment, and the control circuit is configured to provision a second isolated virtual environment which is separate from the first isolated virtual environment and includes a simulated instance of an update controller separate from the first isolated virtual environment.

[0018] In one embodiment, the control circuit is further configured to eliminate the isolated virtual environment.

[0019] Another exemplary aspect of this disclosure relates to a computer implementation method for testing an update controller for delivering over-the-air (OTA) software updates in an isolated virtual environment. The method includes accessing data indicating rules for delivering OTA software updates. The method includes determining actions to be taken to implement the OTA software update. The actions are based on the rules for delivering the OTA software update and mock behavior of external software services available to the update controller. The mock behavior simulates the response of the external software services to a request from the update controller in the isolated virtual environment. The method includes accessing data indicating that a vehicle simulator is available for the OTA software update. The method includes generating a task package for the vehicle simulator containing the OTA software update and indicating actions to be taken to implement the OTA software update. The method includes outputting the task package to the vehicle simulator in the isolated virtual environment.

[0020] In one embodiment, the method further includes provisioning an isolated virtual environment containing a simulated instance of an update controller.

[0021] In one embodiment, the method further includes accessing information to assist the vehicle simulator in implementing an OTA software update based on mock behavior of an external software service. The task package includes information to assist the vehicle simulator in implementing an OTA software update.

[0022] In one embodiment, the isolated virtual environment is a first isolated virtual environment, and the method further includes provisioning a second isolated virtual environment separate from the first isolated virtual environment.

[0023] In one embodiment, the method further includes removing the isolated virtual environment.

[0024] A further exemplary aspect of this disclosure relates to one or more non-temporary computer-readable media storing instructions executable by a control circuit configured to test an update controller for delivering an over-the-air (OTA) software update within an isolated virtual environment. The control circuit is configured to access data indicating rules for delivering the OTA software update. The control circuit is configured to determine the actions taken to implement the OTA software update. The actions are based on the rules for delivering the OTA software update and mock behavior of external software services available to the update controller. The mock behavior simulates the response of the external software service to a request from the update controller within the isolated virtual environment. The control circuit is configured to access data indicating that a vehicle simulator is available for the OTA software update. The control circuit is configured to generate a task package for the vehicle simulator that includes the OTA software update and indicates the actions taken to implement the OTA software update. The control circuit is configured to output the task package to the vehicle simulator within the isolated virtual environment.

[0025] Other exemplary aspects of this disclosure include other systems, methods, vehicles, apparatus, tangible non-transient computer-readable media, and devices for the technologies described herein.

[0026] These features, aspects, and advantages of various implementations, as well as other features, aspects, and advantages, will be better understood by referring to the following description and the appended claims. The appended drawings incorporated herein and constituting part thereof illustrate implementations of this disclosure and are useful in illustrating the relevant principles together with the description. A detailed description of the implementation forms targeted at those skilled in the art is described in this specification with reference to the accompanying drawings.

Brief Description of the Drawings

[0027] [Figure 1] An example of a computing ecosystem according to an embodiment of the present disclosure is shown. [Figure 2A] A diagram of an exemplary computing architecture for an on-board computing system of a vehicle according to an embodiment of the present disclosure is shown. [Figure 2B] A diagram of an exemplary computing architecture for an on-board computing system of a vehicle according to an embodiment of the present disclosure is shown. [Figure 2C] A diagram of an exemplary computing architecture for an on-board computing system of a vehicle according to an embodiment of the present disclosure is shown. [Figure 2D] A diagram of an exemplary computing architecture for an on-board computing system of a vehicle according to an embodiment of the present disclosure is shown. [Figure 3] A diagram of an exemplary computing platform located remotely from a vehicle according to an embodiment of the present disclosure is shown. [Figure 4] A diagram of a computing ecosystem for providing OTA software updates for a vehicle according to an embodiment of the present disclosure is shown. [Figure 5] A diagram of an exemplary update controller according to an embodiment of the present disclosure is shown. [Figure 6] A diagram of an exemplary virtual environment for testing an update controller according to an embodiment of the present disclosure is shown. [Figure 7] A diagram of an exemplary data flow within an exemplary virtual environment according to an embodiment of the present disclosure is shown. [Figure 8] A diagram of an exemplary system and data flow for generating mock behavior according to an embodiment of the present disclosure is shown. [Figure 9]A flowchart illustrating an exemplary method according to one embodiment of this disclosure is shown. [Figure 10] A diagram of an exemplary computing ecosystem having computing components according to one embodiment of this disclosure is shown. [Modes for carrying out the invention]

[0028] One aspect of this disclosure relates to simulating the performance of a controller configured to perform OTA software updates for vehicles within an isolated virtual environment. Many different systems may be involved in the provisioning of OTA software updates (also referred to herein as “OTA updates”). For example, as a distributed IoT ecosystem, the OTA computing environment may include several heterogeneous systems connected via one or more networks, including in-vehicle systems and platform systems (e.g., cloud-based systems) that communicate with each other to perform end-to-end OTA software updates for vehicles. An exemplary platform-based system that may help facilitate the distribution of OTA updates is an update controller system (also referred to herein as “update controller”).

[0029] The update controller can function as a point of contact for the in-vehicle system and as an orchestrator for the OTA update workflow. For example, the update controller may obtain rules for distributing OTA updates, such as "All 2021 models will be upgraded to infotainment platform version 1.6." The update controller may communicate with one or more backend services (or "external dependencies"), and may obtain vehicle information from these backend services according to the rules in order to properly implement the OTA update. The update controller may package the collected information about the target vehicle so that the vehicle's onboard computing system can take appropriate actions to implement the OTA update.

[0030] The update controller may be part of an ecosystem of several heterogeneous systems that work together collaboratively to meet the demands of OTA software updates across various use cases with varying levels of complexity. This can present challenges when testing these use cases end-to-end. For example, it may be useful to test software changes made to the update controller end-to-end before updating live environments where actual consumer systems and vehicles may be negatively affected by software issues (e.g., latency).

[0031] Traditionally, this could be addressed by having one or more additional complete environments of the entire software chain for integration and testing purposes. However, this solution has drawbacks, particularly with regard to integration with external dependencies. Since the systems in these environments may be owned and operated separately, they may rely on common, well-known environments such as "DEV" and "INTEGRATION." However, some simulation properties can benefit from even more test environments. Furthermore, data consistency issues can arise, for example, if several instances of an update controller environment depend on the same vehicle configuration service instance. Additionally, while load testing of the update controller can be useful, it can overload dependencies in non-production environments that are not necessarily scaled to handle peak traffic.

[0032] To help address these issues, the technology of this disclosure provides an isolated virtual environment for the update controller. The virtual environment may allow testing to be performed without affecting actual external dependencies or the vehicle. For example, the virtual environment may contain a fully functional instance of the update controller with dedicated underlying cloud infrastructure components. The virtual environment can exist isolated from the actual environment (e.g., from a network perspective). The technology of this disclosure allows multiple such virtual environments to be provisioned and operate simultaneously (e.g., on the cloud) without conflict.

[0033] The virtual environment may include other components provisioned for the purpose of testing the update controller. For example, in the virtual environment, the vehicle may be replaced by a software-based vehicle simulator, the consumer system may be disguised by integration testing (which may also control the vehicle simulator), and external dependencies may be mocked with explicit, devised behavior.

[0034] The technology disclosed herein can provide several technical benefits and computing improvements through its ability to mock external dependencies using devised behaviors. For example, instead of deploying individual mock instances for all external dependencies, a single proxy can be used by the update controller within a virtual environment for multiple (e.g., all) external dependencies. From the update controller's perspective, it only needs to know that it is calling a particular service with a given request and expecting some response in a given schema. For example, the update controller (e.g., its simulated instance) may not know how the call is routed to a particular service or who is actually responding. Within a virtual environment, integration tests can set up the mocks necessary to execute a given set of test cases. Integration tests can define the behavior of external services using a full-featured mocking framework. This approach allows the definition of the expected behavior of external services to remain localized to the test triggering it.

[0035] Having integration tests that explicitly specify the behavior of external dependencies can offer clear advantages over using actual external dependencies in the integrated environment. For example, this can enable testing of edge cases and sporadic errors that are difficult to reproduce. Specifying behavior becomes computationally more efficient by using a mocking framework. In this way, a virtual environment can be used to reliably test specific error cases involving external dependencies.

[0036] In some implementations, techniques may be used to prevent mock behavior from deviating too far from their real-world results. For example, mock behavior may deviate from the actual behavior of external dependencies. If the deviation is too large, the tests may become unreliable indicators of whether a particular piece of code works in the real world. To address this situation, as further described herein, the techniques of this disclosure can use data collected by calling a given external service in the real world to inform a model that manages how the external service responds in a virtual environment (e.g., as represented by its mock behavior).

[0037] Furthermore, the technology disclosed herein is designed so that virtual environments are dynamically provisioned, tested, and removed (e.g., dismantled, deleted) via an automated CI / CD pipeline, enabling virtual environments to be considered "zero-click." Integrating the provisioning, testing, and removal (e.g., dismantling) of virtual environments within a modern CI / CD pipeline system provides significant flexibility when performing end-to-end integration testing early in the software development lifecycle.

[0038] When integration with external systems is tested end-to-end on a dedicated shared environment, developers must merge their code changes into a repository, build a shared integration environment, deploy to it, and then run end-to-end tests. This creates a long cycle between coding and integration testing, with a lot of idle time spent waiting for build and deployment to complete. In contrast, with the isolated virtual environment and supporting CI / CD pipeline of this disclosure, it is more efficient and easier to run integration tests even before the code is merged into the repository. This can be achieved by calling provisioning / execute / destroy pipelines within a pull request pipeline, which can be triggered when a request is made to merge code into the repository. The pull request pipeline can then build the branch requested to pull, deploy it to a virtual environment, and test it by calling three virtual environment pipelines. In some implementations, integration test failures can be used as a gate to prevent the completion of the pull request, preventing code with integration issues from being committed to the repository in the first place.

[0039] Ultimately, the technology of this disclosure provides an improvement to vehicle (or other end-user device) computing technology. As an example, a computing system may be configured to test an update controller for delivering OTA software updates in an isolated virtual environment. Within the virtual environment, the computing system may provision a simulated instance of the update controller. The update controller can access data that indicates the rules for delivering OTA software updates. The update controller can determine the actions to be taken to implement the OTA software update. The actions may indicate one or more actions that the vehicle should take to properly download and implement the OTA software update on its onboard computing system. The actions may be based on the rules for delivering the OTA software update and mock behavior of external software services available to the update controller. The mock behavior may simulate the response of external software services to requests from the update controller in the isolated virtual environment. The update controller can access data that indicates that the vehicle simulator is available for the OTA software update. The update controller can generate a task package for the vehicle simulator that includes the OTA software update and indicates the actions to be taken to implement the OTA software update. The update controller can output task packages to a vehicle simulator in an isolated virtual environment.

[0040] In this way, the update controller can be tested and validated in a simulated environment before deployment in the actual live environment. Having all mock backend dependencies of the vehicle simulator and update controller within a single, isolated virtual environment that does not need to interact with the outside world makes it easier to avoid disruptions to the simulation functionality, leading to more stable and predictable testing. Furthermore, simulation can improve the effectiveness and reliability of the update controller. This improves the reliability of delivering OTA software updates for vehicles and avoids wasting computing resources on deliveries that could end in implementation errors. Ultimately, this can improve vehicle functionality and performance because the vehicle's onboard software can be updated more efficiently and effectively.

[0041] Hereinafter, embodiments will be referenced in detail. One or more examples are shown in the drawings. Each example is provided for the purpose of describing an embodiment and does not limit the disclosure. In fact, it will be apparent to those skilled in the art that various modifications and variations can be made to embodiments without departing from the scope or spirit of the disclosure. For example, features illustrated or described as part of one embodiment can be used in combination with another embodiment to result in yet another embodiment. Thus, aspects of the disclosure are intended to encompass such modifications and variations.

[0042] The technologies of this disclosure may include the collection of data associated with a user if the user explicitly authorizes such collection. Such authorization may be provided by the user through explicit user input to a user interface in response to a prompt explicitly requesting such authorization. The collected data may be anonymized, pseudonymized, encrypted, noised, securely stored, or otherwise protected. The user may opt out of such data collection at any time.

[0043] The following description illustrates over-the-air (OTA) software update technologies within the context of a vehicle. The technologies described herein may be used in other Internet of Things (IoT) contexts and environments. For example, computing devices and device simulators may be used instead of vehicles and vehicle simulators.

[0044] Figure 1 shows an example of a computing ecosystem 100 according to one embodiment of the present disclosure. The ecosystem 100 may include a vehicle 105, a remote computing platform 110 (hereinafter also referred to as the computing platform 110), and a user device 115 associated with a user 120. The user 120 may be the driver of the vehicle. In some implementations, the user 120 may be a passenger in the vehicle. In some implementations, the computing ecosystem 100 may include a third-party (3P) computing platform 125, as further described herein. The vehicle 105 may include a vehicle computing system 200 mounted on the vehicle 105. The computing platform 110, the user device 115, the third-party computing platform 125, and / or the vehicle computing system 200 may be configured to communicate with each other via one or more networks 130.

[0045] Systems / devices in Ecosystem 100 may communicate using one or more Application Programming Interfaces (APIs). This may include external APIs for communicating data from one system / device to another. External APIs enable systems / devices to establish secure communication channels over secure access channels on Network 130 through any number of methods, such as web-based forms, programmatic access via RESTful APIs, Simple Object Access Protocol (SOAP), Remote Procedure Calls (RPC), and script access.

[0046] The computing platform 110 may include a computing system located remotely from the vehicle 105. In one embodiment, the computing platform 110 may include a cloud-based server system. The computing platform 110 may be associated with an entity (for example, operated by an entity). For example, the remote computing platform 110 may be associated with the OEM responsible for the manufacturer and model of the vehicle 105. In another example, the remote computing platform 110 may be associated with a service entity contracted by the OEM to operate a cloud-based server system that provides computing services to the vehicle 105.

[0047] The computing platform 110 may include one or more backend services to support the vehicle 105. These services may include, for example, teleassist services, navigation / routing services, and performance monitoring services. The computing platform 110 may host or otherwise include one or more APIs for communicating data with the vehicle 105's computing system 130 or user device 115.

[0048] The computing platform 110 may include one or more computing devices. For example, the computing platform 110 may include a control circuit and a non-temporary computer-readable medium (e.g., memory). The control circuit of the computing platform 110 may be configured to perform various operations and functions described herein. Further descriptions of the computing hardware and components of the computing platform 110 are provided herein with reference to other figures.

[0049] The user device 115 may include a computing device owned by or accessible to user 120. For example, user device 115 may include a telephone, laptop, tablet, wearable device (e.g., smartwatch, smart glasses, headphones), personal digital assistant, gaming system, personal desktop device, other handheld device, or other types of mobile or non-mobile user device. As further described herein, user device 115 may include one or more input components such as buttons, touchscreens, joysticks or other cursor controls, styluses, microphones, cameras or other imaging devices, motion sensors, user device 115 may include one or more output components such as display devices (e.g., display screens), speakers, etc. In one embodiment, user device 115 may include components such as a touchscreen that are configured to receive user input and perform output functions for presenting information to user 120. As further described herein, user device 115 may execute one or more instructions for running an instance of a software application and presenting the user interface associated therewith. In one embodiment, a user-network session with the computing platform 110 may be initiated by launching a software application.

[0050] The third-party computing platform 125 may include a computing system located remotely from the vehicle 105, the remote computing platform 110, and the user device 115. In one embodiment, the third-party computing platform 125 may include a cloud-based server system. The term “third-party entity” may be used to refer to an entity distinct from the entity associated with the remote computing platform 110. For example, as described herein, the remote computing platform 110 may be associated with an OEM responsible for the manufacturer and model of the vehicle 105. The third-party computing platform 125 may be associated with the OEM’s suppliers, maintenance providers, mapping service providers, emergency providers, or other types of entities. In another example, the third-party computing platform 125 may be associated with an entity that owns, operates, manages, etc., software applications that are available to or downloaded onto the vehicle computing system 200.

[0051] The third-party computing platform 125 may include one or more backend services provided by a third-party entity. The third-party computing platform 125 may provide services accessible by other systems and devices in the ecosystem 100. These services may include, for example, map services, routing services, search engine functionality, maintenance services, entertainment services (e.g., music, video, images, games, graphics), emergency services (e.g., roadside assistance, 911 support), or other types of services. The third-party computing platform 125 may host or include one or more APIs for communicating data between the third-party computing system 125 and other systems / devices in the ecosystem 100.

[0052] Network 130 may be any type of network or combination of networks that enables communication between devices. In some implementations, network 130 may include one or more of the following: local area networks, wide area networks, the Internet, secure networks, cellular networks, mesh networks, peer-to-peer communication links, or combinations thereof, and may include any number of wired or wireless links. Communication over network 130 may be achieved, for example, through a network interface using any type of protocol, protection scheme, encoding, format, packaging, etc. In one embodiment, communication between the vehicle computing system 200 and the user device 115 may be facilitated by near-field or short-range communication technology (e.g., Bluetooth® Low Energy protocol, radio frequency signaling, NFC protocol).

[0053] Vehicle 105 may be a vehicle that can be operated by user 120. In one embodiment, vehicle 105 may be a car or another type of ground vehicle that is manually driven by user 120. For example, vehicle 105 may be a Mercedes-Benz® passenger car or van. In some implementations, vehicle 105 may be an aircraft (e.g., a personal airplane) or a water vehicle (e.g., a boat). Vehicle 105 may include operator assistance functions such as cruise control and advanced driver assistance systems. In some implementations, vehicle 105 may be a fully autonomous vehicle or a semi-autonomous vehicle.

[0054] Vehicle 105 may include a powertrain and one or more power sources. The powertrain may include motors (e.g., internal combustion engines, electric motors, or hybrids thereof), e-motors (e.g., electric motors), transmissions (e.g., automatic transmissions, manual transmissions, continuously variable transmissions), drive shafts, axles, differentials, e-components, gears, etc. The power sources may include one or more types of power sources. For example, vehicle 105 may be a fully electric vehicle (EV) that can use an electric battery to operate the vehicle's powertrain (e.g., for propulsion) and on-board functions. In one embodiment, vehicle 105 can use flammable fuel. In one embodiment, vehicle 105 may include a hybrid power source, for example, a combination of flammable fuel and electricity.

[0055] Vehicle 105 may include a passenger compartment (interior, interior). The passenger compartment may include, for example, an area inside the vehicle body of Vehicle 105, including a cabin for the user of Vehicle 105. The passenger compartment of Vehicle 105 may include seats for the user, a steering mechanism, an accelerator interface, a brake interface, etc. The passenger compartment of Vehicle 105 may include display devices such as a display screen associated with an infotainment system, as will be further explained with respect to Figure 3.

[0056] Vehicle 105 may include the exterior of the vehicle (the outside of the vehicle). The exterior of the vehicle may include the outer surface of Vehicle 105. The exterior of the vehicle may include one or more lighting elements (e.g., headlights, brake lights, accent lights). Vehicle 105 may include one or more doors for accessing the passenger compartment, for example, by operating door handles on the exterior of the vehicle. Vehicle 105 may include one or more windows, including a windshield, a driver's side window (door window), a passenger side window, a rear window, a sunroof, etc.

[0057] The systems and components of the vehicle 105 may be configured to communicate via a communication channel. The communication channel may include one or more data buses (e.g., a Controller Area Network (CAN)), an onboard diagnostic connector (e.g., OBD-II), or a combination of wired or wireless links. Onboard systems may transmit or receive data, messages, signals, etc., to or from each other via the communication channel.

[0058] In one embodiment, the communication channel may include direct connections such as those provided via a dedicated wired communication interface, such as an RS-232 interface or a Universal Serial Bus (USB) interface, or via a local computer bus, such as a Peripheral Component Interconnection (PCI) bus. In one embodiment, the communication channel may be provided via a network. The network may be any type or form of network, such as a personal area network (PAN), local area network (LAN), intranet, metropolitan area network (MAN), wide area network (WAN), or the internet. The network may utilize different layers or stacks of technologies and protocols, such as the Ethernet protocol, Internet Protocol Suite (TCP / IP), ATM (Asynchronous Transfer Mode) technology, SONET (Synchronous Optical Networking) protocol, or SDH (Synchronous Digital Hierarchy) protocol.

[0059] In one embodiment, the systems / devices of the vehicle 105 may communicate via an intermediate storage device, or more generally, an intermediate non-temporary computer-readable medium. For example, a non-temporary computer-readable medium 140, which may be outside the computing system 130, may function as an external buffer or repository for storing information. In such an example, the computing system 130 may retrieve or receive information from the non-temporary computer-readable medium 140.

[0060] For the sake of brevity, specific routines and conventional components (e.g., the engine) of vehicle 105 are not illustrated and / or described herein. Those skilled in the art will understand the operation of conventional vehicle components within vehicle 105.

[0061] Vehicle 105 may include a vehicle computing system 200. As described herein, the vehicle computing system 200 is mounted on vehicle 105. For example, the computing devices and components of the vehicle computing system 200 may be housed, arranged, or included on or inside vehicle 105. The vehicle computing system 200 may be configured to perform computing functions and operations of vehicle 105.

[0062] Figure 2A shows an overview of the operating system of the vehicle computing system 200. The operating system may be a layered operating system. The vehicle computing system 200 may include a hardware layer 205 and a software layer 210. The hardware layer 205 and the software layer 210 may include sublayers. In some implementations, the operating system of the vehicle computing system 200 may include other layers (e.g., above, below, or between the layers shown in Figure 2A). In one example, the hardware layer 205 and the software layer 210 may be a standardized base layer of the vehicle's operating system.

[0063] Figure 2B shows a diagram of the hardware layer 205 of the vehicle computing system 200. In the layered operating system of the vehicle computing system 200, the hardware layer 205 can reside (exist) between the physical computing hardware 215 installed in the vehicle 105 and the software (e.g., the software layer 210) installed and running on the vehicle 105.

[0064] The hardware layer 205 may be an abstraction layer containing computing code that enables communication between software within the vehicle computing system 200 and the computing hardware 215. For example, the hardware layer 205 may include interfaces and calls that enable the vehicle computing system 200 to generate hardware-dependent instructions to the computing hardware 215 of the vehicle 105 (e.g., processor, memory, etc.).

[0065] Hardware layer 205 may be configured to assist in the coordination of hardware resources. The architecture of hardware layer 205 may be service-oriented. These services may help provide computing power for the vehicle computing system 105. For example, hardware layer 205 may include a domain computer 220 of vehicle 105 that may host various functions of vehicle 105, such as intelligent functions of the vehicle. The specifications of each domain computer may be tailored to the functional and performance requirements when services are abstracted to the domain computer. For example, this may allow a specific processing resource (e.g., a graphical processing unit) to support the functionality of a central in-vehicle infotainment computer for rendering graphics to one or more display devices for navigation, games, etc., or to support an intelligent autonomous driving computer to achieve certain industry guarantees.

[0066] The hardware layer 205 may be configured to include a connectivity module 225 for the vehicle computing system 200. The connectivity module may include code / instructions for interface with the communication hardware of the vehicle 105. This may include, for example, interface with communication controllers, receivers, transceivers, transmitters, ports, conductors, or other hardware for communicating data / information. The connectivity module 225 may enable the vehicle computing system 200 to communicate with other computing systems located remotely from the vehicle 105, for example, a remote computing platform 110 (e.g., an OEM cloud platform).

[0067] The architecture design of the hardware layer 205 may be configured to interface with computing hardware 215 for one or more vehicle control units 225. The vehicle control units 225 may be configured to control various functions of the vehicle 105. These may include, for example, a central exterior and interior controller (CEIC), a charging controller, or other controllers as further described herein.

[0068] The software layer 205 may be configured to provide software operations for executing various types of functions and applications of the vehicle 105. Figure 2C shows a diagram of the software layer 210 of the vehicle computing system 200. The architecture of the software layer 210 may be service-oriented and may be configured to provide software for various functions of the vehicle computing system 200. To do so, the software layer 210 may include multiple sub-layers 235A to 235E. For example, the software layer 210 may include a first sub-layer 235A including firmware (e.g., audio firmware) and a hypervisor, a second sub-layer 235B including operating system components (e.g., open-source components), and a third sub-layer 235C including middleware (e.g., for flexible integration with applications developed by the relevant entity or a third-party entity).

[0069] The vehicle computing system 200 may include an application layer 240. The application layer 240 may enable integration with one or more software applications 245 that are downloadable or accessible by the vehicle 105. The application layer 240 may be configured to integrate with applications developed by various different entities, for example, using a container interface.

[0070] The layered operating system and onboard computing resources of the vehicle may enable the vehicle computing system 200 to collect and communicate data, as well as to operate the systems mounted and implemented in the vehicle 105. Figure 2D shows an exemplary system and data block diagram of the vehicle 105.

[0071] The vehicle 105 may include one or more sensor systems 305. The sensor system may include, or communicate with, sensors of the vehicle 105 and modules for processing sensor data 310 associated with sensors configured to acquire sensor data 305. This may include sensor data 310 associated with the surrounding environment of the vehicle 105, sensor data associated with the interior of the vehicle 105, or sensor data associated with a particular vehicle function. The sensor data 310 may indicate conditions observed inside the vehicle, outside the vehicle, or in the surrounding environment. For example, the sensor data 305 may include image data, in-vehicle / out-of-vehicle temperature data, weather data, data indicating the location of a user / object inside the vehicle 105, weight data, motion / gesture data, voice data, or other types of data. The sensors may include one or more of the following: cameras (e.g., visible spectrum cameras, infrared cameras), motion sensors, sound sensors (e.g., microphones), weight sensors (e.g., vehicle seats), temperature sensors, humidity sensors, light detection ranging (LIDAR) systems, radio detection ranging (RADAR) systems, or other types of sensors. The vehicle 105 may include other sensors configured to acquire data associated with the vehicle 105. For example, the vehicle 105 may include an inertial measurement unit, a wheel odometry device, or other sensors.

[0072] Vehicle 105 may include a positioning system 315. The positioning system 315 may be configured to generate location data 320 (also called position data) indicating the location (also called position) of vehicle 105. For example, the positioning system 315 may determine the location by using one or more of the following: inertial sensors (e.g., inertial measurement units), satellite positioning systems, triangulation based on IP addresses and / or proximity to network access points or other network components (e.g., cellular towers, Wi-Fi access points), or other appropriate techniques. The positioning system 315 may determine the current location of vehicle 105. The location may be expressed as a set of coordinates (e.g., latitude, longitude), address, semantic location (e.g., "workplace").

[0073] In one embodiment, the positioning system 315 may be configured to locate the vehicle 105 within its environment. For example, the vehicle 105 may have access to map data that provides detailed information about the environment surrounding the vehicle 105. The map data may provide information about the identification and location of various roads, road sections, buildings, or other objects; the location and direction of lanes (e.g., the location and direction of parking lanes, turning lanes (right or left turn lanes), bicycle lanes, or other lanes within a particular road); traffic regulation data (e.g., the location, timing, or instructions of signs (e.g., stop signs, yield signs), traffic signals (e.g., stop signals), or other traffic signals or control devices / markings (e.g., pedestrian crossings)); or any other data. Based on the map data, the positioning system 315 may locate the vehicle 105 within its environment (e.g., across multiple axes). For example, the positioning system 155 can process specific sensor data 310 (e.g., LIDAR data, camera data, etc.) and match it with a map of the surrounding environment to determine the vehicle's position within that environment. The determined position of the vehicle 105 can then be used by various systems of the vehicle computing system 200 or other computing systems (e.g., remote computing platform 110, third-party computing platform 125, user device 115).

[0074] The vehicle 105 may include a communication unit 325 configured to enable the vehicle 105 (and its vehicle computing system 200) to communicate with other computing devices. The vehicle computing system 200 may use the communication unit 325 to communicate with a remote computing platform 110 or one or more other remote computing devices via the network 130 (for example, via one or more radio signal connections). For example, the vehicle computing system 200 may use the communication unit 325 to receive platform data 330 from the computing platform 110. This may include, for example, an OTA (over-the-air) software update for the operating system of the vehicle computing system 200. Additionally or alternatively, the vehicle computing system 200 may use the communication unit 325 to transmit vehicle data 335 to the computing platform 110. The vehicle data 335 may include any data acquired in the vehicle, such as sensor data 310, location data 320, diagnostic data, user input data, data indicating the current software version or currently running application, occupancy data, data associated with the user 120 of the vehicle 105, or other types of data acquired (e.g., obtained, accessed, generated, downloaded, etc.) by the vehicle computing system 200.

[0075] In some implementations, the communication unit 325 may enable communication between one or more systems mounted on the vehicle 105. For example, in some implementations, the communication unit 325 may enable a system mounted on the vehicle 105 to communicate with a wheel hub display (not shown).

[0076] In one embodiment, the communication unit 325 may be configured to allow the vehicle 105 to communicate with and receive data from a user device 115 (shown in Figure 1). The communication unit 325 may utilize various communication technologies, such as Bluetooth® Low Energy protocol, radio frequency signaling, or other short-range or near-field communication technologies. The communication unit 325 may include any suitable components for interfacing with one or more networks, such as a transmitter, receiver, port, controller, antenna, or other suitable components that may help facilitate communication.

[0077] The vehicle 105 may include one or more human-machine interfaces (HMIs) 340. The human-machine interfaces 340 may include display devices as described herein. The display devices (e.g., touchscreens) may be visible to users of the vehicle 105 (e.g., user 120) located in the front of the vehicle 105 (e.g., driver's seat, passenger seat). Additionally or alternatively, a display device (e.g., rear unit) may be visible to users located in the rear of the vehicle 105 (e.g., rear seats). The human-machine interfaces 340 may present content 335 via a user interface and display it to user 120.

[0078] Vehicle 105 may include multiple vehicle functions 350A to C. Vehicle functions 350A to C may be functions configured to be performed by vehicle 105 based on detected inputs. Vehicle functions 350A to C may include one or more of the following: (i) vehicle comfort functions, (ii) vehicle staging functions, (iii) vehicle environment functions, (vi) vehicle navigation functions, (v) driving style functions, (v) vehicle parking functions, or (vi) vehicle entertainment functions. User 120 may interact with (dialogue with) vehicle functions 250A to C through user input (e.g., adjustable input device, input to UI element) that specifies the settings of the vehicle functions 250A to C selected by the user.

[0079] Each vehicle function may include controllers 355A-C associated with that particular vehicle function 355A-C. Controllers 355A-C for a particular vehicle function may include control circuits configured to operate the associated vehicle function 355A-C. For example, a controller may include circuits configured to turn on a seat heater function, turn off a seat heater function, set a specific temperature or temperature level, etc.

[0080] In one embodiment, controllers 355A-C for specific vehicle functions may include or be associated with sensors that acquire (capture) data indicating whether the vehicle function is on or off, the settings of the vehicle function, etc. For example, the sensors may be audio sensors or motion sensors. The audio sensor may be a microphone configured to capture voice input from user 120. For example, user 120 may provide voice commands to activate the radio function of vehicle 105 and request a specific station. The motion sensor may be a visual sensor (e.g., a camera), infrared, RADAR, etc., configured to capture gesture input from user 120. For example, user 120 may provide a hand gesture to adjust the temperature function of vehicle 105 to lower the temperature inside the vehicle.

[0081] Controllers 355A-C may be configured to transmit signals to other in-vehicle systems. These signals may encode data associated with their respective vehicle functions. The encoded data may indicate, for example, function settings, timing, etc. For example, such data may be used to generate content (e.g., showing the current settings) to be presented via the display device 345. Additionally or alternatively, such data may be included in the vehicle data 335 and transmitted to the computing platform 110.

[0082] Figure 3 shows a diagram of a computing platform 110 located remotely from a vehicle, according to one embodiment of the present disclosure. As described herein, the computing platform 110 may include a cloud-based computing platform. The computing platform 110 is implemented on one or more servers and may include or access one or more databases. In one example, the computing platform 110 may be implemented using different servers based on geographical area.

[0083] In some implementations, the computing platform 110 may include a layered infrastructure comprising multiple layers. For example, the computing platform 110 may include a cloud-based layer associated with functions such as security, automation, monitoring, and resource management. The computing platform 110 may also include a cloud application platform layer associated with functions such as charging station functions, live traffic, vehicle functions, and vehicle sharing functions. The computing platform 110 may include applications and services built on top of these layers.

[0084] The computing platform 110 may be a modular, connected services platform that includes multiple services available to the vehicle 105. For example, the computing platform 110 may include a container-based microservices mesh platform. These services may be represented or implemented as systems within the computing platform 110. The computing platform 110 may also include functions related to the simulation of its components, services, and subsystems. As further described herein, this may be achieved through the use of a test computing system that is part of (or at least communicates with) the computing platform 110.

[0085] The computing platform 110 may include a user system 405. The user system 405 may create, store, manage, or access user profile data 410. The user profile data 410 may include multiple user profiles, each associated with a different user 120. The user profiles may contain various information about each user 120, including user preferences (e.g., music, comfort settings), frequently visited / previously visited destinations, past routes, etc. The user profiles may be stored in a secure database. In some implementations, when a user 120 enters the vehicle 120, the user's key (or user device) may provide the vehicle 105 with a signal containing a user or key identifier. The vehicle 105 may transmit data indicating the identifier to the computing platform 110 (e.g., via its communication system 325). The computing platform 110 may look up the user profile of user 120 based on the identifier and transmit the user profile data 410 to the vehicle computing system 200 of the vehicle 105. The vehicle computing system 200 may use user profile data 410 to implement user 120 preferences, current and past destination locations, etc. The user profile data 410 may be updated based on information periodically provided by the vehicle 105. In some implementations, the user profile data 410 may be provided to the user device 120.

[0086] The computing platform 110 may include a remote assistance system 415. The remote assistance system 415 may provide assistance to the vehicle 105. This may include providing the vehicle 105 with information to assist with charging (e.g., recommended charging locations), remote control of the vehicle (e.g., AV assistance), roadside assistance (e.g., collision, flat tire), etc. The remote assistance system 415 may acquire assistance data 420 to provide its core functions. The assistance data 420 may include information that may help the remote assistance system 415 assist the vehicle 105. This may include information related to the current state of the vehicle, the current state of the occupants, the location of the vehicle, the route of the vehicle, charge / fuel levels, incident data, etc. In some implementations, the assistance data 420 may include vehicle data 335.

[0087] The remote assistance system 415 may transmit data or command signals to the vehicle 105 to provide assistance. This may include providing data indicating the relevant charging location, providing remote control commands to move the vehicle or connect to an emergency provider, etc.

[0088] The computing platform 110 may include a security system 425. The security system 425 may be associated with one or more security-related functions for accessing the computing platform 110 or the vehicle 105. For example, the security system 425 may process security data 430 for purposes such as identifying digital keys for accessing services / systems of the computing platform 110, data encryption, and data decryption. Additionally or alternatively, the security system 425 may store security data 430 associated with the vehicle 105. A user 120 may request access to the vehicle 105 (for example, via a user device 115). If the request includes a digital key for the vehicle 105 as indicated in the security data 430, the security system 425 may provide a signal to lock (or unlock) the vehicle 105.

[0089] The computing platform 110 may include a navigation system 435 that provides backend routing and navigation services to the vehicle 105. The navigation system 435 may provide map data 440 to the vehicle 105. The map data 440 may be used by the vehicle 105's positioning system 315 to determine the vehicle 105's location, points of interest, etc. The navigation system 435 may also provide a route to a destination requested by the vehicle 105 (for example, via user input to the vehicle's head unit). The route may be provided as part of the map data 440 or as separate routing data. The data provided by the navigation system 435 may be presented as content on the vehicle 105's display device 345.

[0090] The computing platform 110 may include an entertainment system 445. The entertainment system 445 can access one or more databases for entertainment data 450 for the user 120 of the vehicle 105. In some implementations, the entertainment system 445 can access the entertainment data 450 from another computing system associated with a third-party service provider of entertainment content (e.g., via an API). The entertainment data 450 may include media content such as music, video, and game data. The vehicle 105 can output the entertainment data 450 through one or more output devices of the vehicle 105 (e.g., a display device, speakers, etc.).

[0091] The computing platform 110 may include a vehicle software system 455 configured to provide one or more software updates 460 to a vehicle 105. The vehicle software system 455 may include, or communicate with, one or more backend services for providing the software updates 460 to the vehicle. For example, the vehicle software system 455 (or its services) may maintain or access data structures (e.g., lists, tables) that indicate the current software or its version downloaded to a particular vehicle. The vehicle software system 455 (or its services) may also maintain data structures that indicate software packages or versions downloaded by a particular vehicle. In some implementations, the vehicle computing system 200 may maintain data structures that indicate computing hardware, charging hardware, or other hardware resources installed in a particular vehicle. These data structures may be organized by a vehicle identifier (e.g., VIN) so that the computing platform 110 can perform a lookup function based on the vehicle identifier to determine the relevant software (and updates) for a particular vehicle.

[0092] When vehicle 105 is connected to computing platform 110 and available for software updates, vehicle 105 can request a software update from computing platform. Computing platform 110 can provide vehicle 105 with one or more software updates 410 via network 130 as OTA (over-the-air) software updates (also known as "OTA updates").

[0093] Figure 4 shows a diagram of a computing ecosystem for providing OTA software updates for a vehicle 105 according to one embodiment of the present disclosure. Figure 4 shows a portion of a computing platform 110, such as a vehicle software system 455. To coordinate the delivery of software updates 460 (e.g., OTA updates) to the vehicle, the computing platform 110 (e.g., vehicle software system 455) may include a remote update controller system 500. The remote update controller system 500 is also referred to herein as the update controller 500. The update controller 500 may be configured to function as an orchestrator for OTA updates, as well as a point of contact for the vehicle 105 when acquiring OTA updates.

[0094] The update controller 500 includes and can communicate with various systems / components to coordinate OTA updates. Figure 5 shows a diagram of the update controller 500, as well as other systems with which the update controller 500 can communicate to coordinate the distribution of OTA updates. Figure 5 may represent the update controller 500 and its ecosystem in a real-world live environment for distributing OTA updates to actual vehicles.

[0095] The update controller 500 may be implemented on the cloud computing infrastructure 505, which may include the infrastructure of the computing platform 100. The cloud computing infrastructure 505 may include underlying frameworks and components that enable the delivery of cloud computing services over a network (e.g., the Internet). The cloud computing infrastructure 505 may be provided by a cloud computing service provider, which can enable entities to access computing resources on demand and adjust / consume resources as needed. The cloud computing infrastructure 505 can provide a foundation for deploying and running a variety of cloud-based services, including Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS).

[0096] The cloud computing infrastructure 505 may include hardware, software, networking, and storage resources to support cloud-based applications, data storage, and processing. For example, the cloud computing infrastructure 505 may include one or more servers. Servers may include physical or virtual machines that host and run applications, store data, and perform computing tasks in the cloud. Servers may be distributed across multiple data centers. The cloud computing infrastructure 505 may be managed and controlled through a software platform that provides functions such as resource provisioning, monitoring, security, and automation.

[0097] Cloud computing infrastructure 505 may include storage and network resources. For example, cloud computing infrastructure 505 may provide various types of storage options, such as object storage, file storage, and block storage. These storage resources are accessible over the network, enabling entities to store and retrieve data. Cloud computing infrastructure 505 may include networking components such as routers, switches, and load balancers that enable communication between different components of the cloud system. Network connectivity can ensure data transmission and accessibility across distributed servers and data centers.

[0098] Cloud computing infrastructure 505 can incorporate a variety of security measures to protect data, applications, and infrastructure from unauthorized access, data breaches, and other threats. This includes encryption, firewalls, access control, and security monitoring systems.

[0099] Cloud computing infrastructure 505 may utilize virtualization technology. Virtualization technology can enable the creation of virtual instances of servers, operating systems, and other resources. This can help provide efficient resource allocation, scalability, and isolation for different cloud tenants (users or entities) on a shared physical infrastructure.

[0100] The update controller 500 can communicate with numerous services and systems to manage the distribution of OTA updates. For example, the update controller 500 may be configured to communicate with the vehicle computing system 200 (not shown in Figure 5) of the vehicle 105. The update controller 500 can receive requests (or other types of communications) generated by the vehicle computing system 500 indicating that the vehicle 105 is available for the OTA update 515. For example, the vehicle 105 may be considered available for the OTA update 515 if it has network connectivity to receive the package / payload associated with the OTA update 515 and / or sufficient computing resources (e.g., processing, memory, power, etc.) necessary to download and configure the OTA update 515 on the vehicle 105.

[0101] The update controller 500 may communicate with one or more consumer systems 520. The consumer system 520 may be a computing system configured to create rules 522 for distributing OTA updates 515.

[0102] Rule 522 may be associated with, for example, a campaign to update a specific software version on a group of vehicles (e.g., a specific vehicle model in year X), or a campaign to provide a new software package to a group of vehicles (e.g., a new in-car chatbot for finding music content). Rule 522 can define which vehicles are eligible for / applicable to the software update, and which OTA update 515 should be provided to the eligible vehicles. For example, Rule 522 may be a combination of characters, text strings, etc., that explicitly describe the intention to deliver a given OTA update 515 to a particular set of vehicles.

[0103] A "task" can represent an instance of rule 522 when applied to an individual vehicle 105. For example, when vehicle 105 communicates with the update controller 500, the update controller 500 notifies vehicle 105 of a task, and the vehicle computing system 200 executes it. A task can include actions that vehicle 105 should perform to implement an OTA update 515. This could include, for example, downloading a software update package over the network, or updating / modifying the configuration of components in vehicle 105.

[0104] The consumer system 520 can either automatically create rule 522 or allow manual creation of rule 522. For example, the consumer system 520 may be configured to automatically create rule 522 when the OTA update 515 is verified, deployed, posted, or made available for distribution. Additionally or alternatively, the consumer system 520 may include a display device configured to present a user interface to the user of the consumer system 520. The user interface may allow the user to provide user input for creating rule 522.

[0105] The update controller 500 may communicate with one or more external software services 525 to facilitate the distribution of OTA updates 515 in accordance with rule 522. These external software services 525 are sometimes referred to herein as “dependencies” 525. These external software services 525 may include platform-based systems such as backend software services (e.g., microservices). These external software services 525 may include services that process or maintain information that can help determine whether rule 522 applies to a particular vehicle 105 and what actions the vehicle 105 should take to implement the OTA update 515 associated with rule 522. For example, a dependency 525 may include a vehicle calling service that maintains / accesses one or more data structures containing the vehicle identification numbers (VINs) of all vehicles. A dependency 525 may include a vehicle configuration service configured to access the vehicle configuration of each vehicle, as well as any associated external data. In another example, a dependency 525 may include a vehicle documentation (VDOC) service. VDOC services may include external vehicle metadata services that maintain records of the current and / or past configurations for each of each vehicle, as well as any documentation (e.g., required by regulations).

[0106] The update controller 500 may include one or more services, components, systems, etc., configured to assist in the orchestration of OTA updates. For example, the update controller may include a vehicle service 530 that responds to traffic from vehicle 105. For example, vehicle service 530 may be configured to receive requests 510 for OTA updates 515 from vehicle 105. The request 510 may include data indicating that vehicle 105 is available for an OTA update if there is an applicable OTA update for vehicle 105. In some implementations, the request 515 may be an explicit request for a specific (or any) OTA update 515. Vehicle service 530 may be configured to respond to the request 510 with a payload indicating the OTA update 515 and the actions that vehicle 105 should take to implement the OTA update 515.

[0107] The update controller 500 may include one or more controller components 535. A controller component 535 may be a software service configured to map rules and actions to vehicle-specific tasks and perform several other related responsibilities. For example, a controller component 536 may be configured to communicate with an external software service 525 or to determine which external software service 525 to communicate with to collect information about a particular OTA update 515. This can help the update controller 500 determine what actions a vehicle 105 should take with respect to a particular OTA update 515. The controller components 535 may include, for example, rule services (e.g., microservices for evaluating rules), response services for evaluating vehicle inventory, device services, data synchronization services, and so on.

[0108] The update controller 500 may include a management service 540 configured to expose an interface for a consumer system 520 to interact with the update controller 500. The management service 540 may be configured to access data indicating rule 522 and to interact with the controller component 535 to advance rule 522 within the ecosystem. For example, the management service 530 may be configured to coordinate with the rest of the update controller ecosystem so that when the vehicle service 530 receives a request 510 from a vehicle 105 that meets the requirements (qualifies) for the OTA update 515, the vehicle service 530 can notify the vehicle 105 of the actions that need to be taken for the implementation of the OTA update 515.

[0109] For example, the management service 540 may obtain a rule 522 for distributing an OTA update 515, such as "All 2021 models will be upgraded to navigation version 6.1.6." The update controller 500 may also communicate with an external software service 525 (for example, via a controller component 535), and the update controller 525 may obtain information about the vehicle 105 from the external software service 525 in accordance with rule 522 in order to properly implement the OTA update 515. The update controller 500 may package the collected information about the target vehicle 105 and output such information to the vehicle 105 via the vehicle service 530. This allows the vehicle computing system 200 (installed in the vehicle 105) to take appropriate action to implement the OTA update 515.

[0110] Adjusting the update controller across various heterogeneous systems can involve complex computational processes. Therefore, it may be useful to test the update controller 500 end-to-end before updating the live environment in which the actual consumer system 520 and vehicle may be adversely affected by software issues (e.g., latency).

[0111] The technology disclosed herein enables an efficient and reliable approach to testing the update controller 500. To do so, the technology disclosed herein allows testing and simulation of the functionality of the update controller and its corresponding ecosystem (e.g., as shown in Figure 5) within an isolated virtual environment, while still utilizing applicable cloud computing infrastructure. As further described herein, this allows testing to be performed without affecting actual external dependencies or vehicles.

[0112] Figure 6 shows exemplary virtual environments 600A-C for testing an update controller 605 according to one embodiment of the present disclosure. A test computing system 610 may be configured to perform a simulation for testing the update controller 605. As further described herein, the update controller 605 may be a fully functional simulated instance of the update controller 500, including its services, components, etc. The test computing system 610 may include a control circuit configured to test the update controller 605 for delivering OTA software updates 650 within isolated virtual environments 600A-C. The following describes components and operations that may be performed by the test computing system 610 to perform such a test. For example, the control circuit of the test computing system 610 may be configured to perform such operations.

[0113] The test computing system 610 may utilize a cloud-based platform infrastructure. For example, the update controller 605 and / or virtual environments 600A-C may be implemented on the cloud computing infrastructure 615. The test computing system 610 can create virtual environments 600A-C and run simulation tests of the update controller 605 on the cloud computing infrastructure 615. For example, the test computing system 610 may utilize the cloud computing infrastructure 615 to provision virtual environments 600A-C for testing the update controller 605. The cloud computing infrastructure 615 may include at least some of the components of the cloud computing infrastructure 505 used in the actual live environment. In this way, the testing and simulation of the update controller 605 may be performed on at least some of the same (or similar) hardware, software, networking, and storage resources used to support cloud-based applications, data storage, and processing by the computing platform 110 in the real-world environment.

[0114] The test computing system 610 may provision one or more virtual environments 600A-C for testing the update controller 605. The virtual environments 600A-C may include software-based emulations of physical computing environments. The virtual environments 600A-C may include isolated, self-contained spaces within a computing system (e.g., running on cloud computing infrastructure 615) where applications, software, and mock dependencies are installed and can run independently of the underlying operating system and other applications (e.g., those of computing platform 110). Therefore, the virtual environments 600A-C and the simulations running within them can run on the cloud computing components of computing platform 110 but be isolated from the real-world environment. This allows testing to be performed without affecting actual external dependencies or vehicles (or other endpoint devices).

[0115] The test computing system 610 can provision multiple virtual environments 600A to C that exist simultaneously. Each virtual environment 600A to C can be isolated from each other. They can run separate simulations of the update controller 605. The simulations may run concurrently. For example, the test computing system 610 can provision a first isolated virtual environment 600A. The first isolated virtual environment 600A may include an update controller 605, which may be a simulated instance of the update controller 500. The test computing system 610 can provision a second isolated virtual environment 600B, which is separate from the first isolated virtual environment 600A and includes a simulated instance of an update controller separate from the first isolated virtual environment 600A. The test computing system 610 can provision a third virtual environment 600C, which is isolated from the first virtual environment 600A and the second virtual environment 600B. Virtual environments 600A-C may exist simultaneously within overlapping timeframes. Each of virtual environments 600A-C may be removed, dismantled, or destroyed separately. Each of virtual environments 600A-C may be removed, dismantled, or destroyed simultaneously within overlapping timeframes, or before or after each other.

[0116] Provisioning the virtual environment 600A may involve provisioning various elements of the virtual environment 600A for testing the update controller 605. For example, the test computing system 605 may provision the virtual environment 600A which includes a simulated instance of the update controller 605. This may include a fully functional instance of the update controller 500 with dedicated underlying cloud infrastructure components. The simulated instance of the update controller 605 may include a simulated management service 620 and a simulated vehicle service 625. The simulated management service 620 may perform the functions of the management service 540 within the virtual environment 600A. The simulated vehicle service 625 may perform the functions of the vehicle service 530 within the virtual environment 600A.

[0117] The test computing system 610 may provision a vehicle simulator 635 within an isolated virtual environment 600A. The vehicle simulator 635 may be a software-based simulator capable of representing a vehicle 105 within the virtual environment 600A. The vehicle simulator 635 includes software that can simulate at least some of the performance of the operation of a vehicle computing system 200 installed in the vehicle 105.

[0118] The test computing system 610 may include one or more integration tests 645. An integration test may include one or more modules configured to function as a simulated consumer service. As further described herein, an integration test 645 may help set up and run a test using mock behavior of an external software service / dependency 525. An integration test 645 can also work in conjunction with a vehicle simulator 635 to coordinate the test process end-to-end. For example, an integration test 645 (e.g., a simulated consumer service) may be configured to send communications to the vehicle simulator 635 to trigger the vehicle simulator 635 to provide data indicating that an OTA update 650 is available.

[0119] The test computing system 500 may provision one or more mock external software services 640 (also referred to herein as “mock dependencies 640”). The mock external software services 640 may represent or simulate one or more external services 525 that may be invoked by the update controller in a real live environment. However, within the virtual environment 600A, the behavior of external services 525 may be mocked with explicitly devised behaviors (“mock behaviors”). Mock behaviors may be automatically defined by a module associated with the integration test 645 based on the performance of the live external software services 525. Additionally or alternatively, mock behaviors may be defined based on user input via a user interface and stored in the integration test 645.

[0120] To facilitate the use of mock behavior, the test computing system 605 may include, for example, a proxy within a virtual environment 600A to facilitate mock behavior of multiple external software services. Figure 7 shows a diagram of a first virtual environment 600A with a proxy 700, and an exemplary data flow to facilitate mock behavior 705 of one or more mock external software services 640. The mock behavior 705 (e.g., a devised behavior within the virtual environment 600A) can be based on the behavior of the corresponding external software service 525 in the live environment that is currently being simulated within the virtual environment 600A.

[0121] To implement mock behavior 705 within virtual environment 600A, a proxy 700 may be included within virtual environment 600A. For example, instead of deploying individual mock instances (mock external dependencies) for all mock external software services 640, a single proxy 700 may be used within virtual environment 600A for all mock external software services 640. From the perspective of the update controller, the update controller 605 may only know that it is calling a specific service with a given request and expecting a response in a given schema. The update controller 605 may not know how the call is routed to a particular service or which system / service is actually responding.

[0122] In virtual environment 600A, integration test 645 may set up mock behaviors 705 to execute a given set of test cases. Integration test 645 may define one or more mock behaviors 705 for one or more mock external software services 640 using a full-featured mock framework. This approach allows for the maintenance of a definition of the expected behavior of the mock external software service 640, localized to the test that triggers it. After defining the mock behaviors 705, integration test 645 may register the mock behaviors 705 with proxy 700. The mock behaviors 705 may be registered with proxy 700 before running a simulation test of the update controller 605. In this way, during simulation execution, all requests to a given mock external software service 640 may be forwarded and returned to a listener of integration test 645 that executes the mock behaviors 700 of the mock external software service 640.

[0123] For example, integration test 645 may define mock behavior 700 for a mock external software service A ("Service A"). Service A may represent, for example, a mock instance of a vehicle configuration service. Integration test 645 may define mock behavior 700 that should be executed when the update controller 605 calls Service A. Integration test 645 may register the mock behavior 705 of Service A with the proxy 700.

[0124] The integration test 645 can communicate with the update controller 605 to invoke operation "F". Operation F may represent a rule activation process. For example, operation F may include an instruction to activate rule 655 (shown in Figure 6), which is then translated into one or more actions 660 (shown in Figure 6) that can proceed through the update controller 605 and be provided to the vehicle simulator 635. Within the virtual environment 600A, the update controller 605 can "invoke service A" by accessing proxy 700 in response to operation F. The invocation may be forwarded by proxy 700 to a listener in the integration test 645 that executes mock behavior 700 of service A. Mock behavior 700 may define that certain information from service A (e.g., vehicle configuration data) should be provided in response to a request from the update controller 605. Thus, the integration test 645 can return such information to proxy 700, which can then provide that information to the update controller 605.

[0125] As described herein, the mock behavior 700 simulates the response of an external software service 525 (e.g., in a live environment) to a request from an update controller 605 in an isolated virtual environment 600A. To do so, the mock behavior 700 can be developed based on the historical performance of the external software service 525 that is intended to be mocked. This allows the mock behavior 700 to be defined based on real data accumulated in the actual live environment.

[0126] Figure 8 shows an exemplary system 800 and data flow diagram for generating mock behavior 700 according to an embodiment of the present disclosure. System 800 may include an update controller 500 and an external software service 525 operating in a real environment 805 (e.g., a non-virtual real-world environment). System 800 may include a logging and analysis store 810 configured to store log data 815 acquired by the update controller 500 and to make such data accessible for analysis. System 800 may include a dependency analyzer 820 configured to generate a model of the behavior of the external software service 525 when it interacts with the update controller 500 in the real environment 805. Such information may be provided to a module of integration test 645 (or another system) to compute mock behavior 700 for use in a virtual environment 600A. Thus, mock behavior 700 may be based on log data 815 generated during communication between the update controller 500 and the external software service 525 in the real computing environment 805.

[0127] For example, in a real environment 805, the update controller 500 may log metadata / information each time it invokes an external software service 525 (dependency 525). This may include invoking external service A. The information logged by the update controller 500 may include log data 815. The log data 815 may include one or more request parameters 825A associated with the update controller 500. The request parameters 825A may indicate the content of the request made by the update controller 500 when invoking external service A. This may include the type of information requested by the update controller 500. The log data 815 may include a response payload 825B provided by the external software service 525. The response payload 825B may indicate the information provided by external service A in response to the request communicated by the update controller 500. In some implementations, the log data 815 may include a response time 825C indicating the duration until the external software service 525 responds to the update controller 500. Log data 815 may also include other selected metadata (e.g., related external service A).

[0128] The log data 815 may be provided to the logging and analysis store 810. The logging and analysis store 810 may store the log data 815 in a data structure such that it indicates that it is associated with an external software service 525 (e.g., external service A).

[0129] Log data 815 may be processed to determine the expected behavior of its associated external software service 525. Log data 815 may be processed by a dependency analyzer 820. For example, the dependency analyzer 820 may be configured to build a model of the behavior of service A based on the log data 815 and the service behavior model.

[0130] In some implementations, the service behavior model may include a rule-based model that weights log data 815 to determine, for example, the response patterns and response times from an external service A. The rule-based model may include a set of predefined rules or heuristics that can be processed to achieve a purpose (for example, for applying weights for configuration analysis and selection).

[0131] In some implementations, the service behavior model may include one or more machine learning models. The machine learning models may include unsupervised learning models. In one embodiment, the machine learning models may include neural networks (e.g., deep neural networks) or other types of machine learning models, including nonlinear and / or linear models. The neural networks may include feedforward neural networks, recurrent neural networks (e.g., long-term memory recurrent neural networks), convolutional neural networks, or other forms of neural networks. Some exemplary machine learning models may leverage attentional mechanisms such as self-attention. For example, some exemplary machine learning models may include multi-head self-attention models (e.g., transformer models).

[0132] The service behavior model may be a predictive model trained to predict the behavior of the external software service 525. For example, the service behavior model may be a machine learning modal trained with training data showing past requests by the update controller 500 and responses from external service A. In some implementations, the training data may show the response time of external service A. The training data may also include labeled log data 815 associated with external service A.

[0133] Machine learning models can be trained using objective functions such as loss functions. For example, using labeled training data, a model can be trained to minimize a loss function based on a comparison between the predicted response of a dependency and ground truth, which represents the real-world response of the dependency. The model can be retrained and its parameters reweighted until a threshold level of prediction accuracy is reached.

[0134] The service behavior model may be configured to generate an output that shows the predicted behavior of the external service 525. The output may describe, for example, information that is expected to be provided by the external service A in response to a request from the update controller 500. For example, the predicted behavior of service A may show that when the input is "x", the response is likely to be "y", or when the input size is greater than 20KB, the response latency is typically 100ms. The dependency analyzer 820 can use the service behavior model and these outputted predicted behaviors to generate a model of the behavior of service A.

[0135] The mock behavior 700 may be based on the expected behavior of an external software service 525. For example, a module of integration test 645 in a virtual environment can generate and define the mock behavior 700 using a model of the service's behavior. This can be used in addition to, or instead of, explicit mocks. This approach may be useful for certain "real-world" tests, such as load tests.

[0136] In some implementations, model-based behavior can be represented in relation to mocks. This can help avoid additional adjustments in how tests are run in the virtual environment 600A.

[0137] Over time, modified or new behaviors of the external software service 525 may exist. Additionally or alternatively, new external software services may be provided to the ecosystem for access in the actual environment 805. The framework and process described with respect to Figure 8 may be one exemplary approach to considering such changes in behavior or added services by logging data indicating newer behavior and / or new external services. In a manner similar to that described herein, mock behaviors can be generated using such logged data, thereby allowing these new behaviors / services to be considered when simulating the performance of the update controller.

[0138] Returning to Figure 6, the virtual environment 600A is designed to be dynamically provisioned, tested, and removed (e.g., dismantled, deleted) via an automated CI / CD pipeline, and can therefore be considered, for example, "zero-click."

[0139] One or more CI / CD pipelines can be used to help achieve zero-click behavior for virtual environments 600A-C. For example, a provisioning virtual environment pipeline might include automation for creating cloud computing infrastructure 615 using an Infrastructure-as-Code (IaC) framework, deploying an instance of update controller 605, setting up proxy 700 used to mock external software services 640, deploying an instance of vehicle simulator 635, and deploying integration tests 645. In some implementations, the provisioning virtual environment pipeline can be extended to dynamically generate mocks based on a dependency analyzer model and inject them into integration tests 645. An execution virtual environment test pipeline can run one or more integration tests 645 deployed in a given virtual environment 600A-C and report the results. A destroy virtual environment pipeline can remove / destroy everything provisioned for a given virtual environment 600A-C. In some implementations, pipelines can be called from other pipelines triggered by specific actions, such as committing to a source code branch.

[0140] Figure 9 shows a flowchart of an exemplary method 900 for simulating an update controller according to one embodiment of the present disclosure. Method 900 may include an end-to-end test process using elements of the virtual environment 600A in Figure 6. The method may be performed by a computing system described with reference to other figures (e.g., test computing system 610). In one embodiment, method 900 may be performed by a control circuit of the computing system. One or more parts of the method may be implemented as algorithms on hardware components of the devices described herein. For example, steps of the method may be implemented as actions / instructions that can be executed by computing hardware.

[0141] Figure 9 illustrates, for illustrative and explanatory purposes, the elements performed in a specific order. Those skilled in the art will understand, by using the disclosures provided herein, that any element of the methods discussed herein may be adapted, rearranged, expanded, omitted, combined, or modified in various ways without departing from the scope of this disclosure.

[0142] Figure 9 is illustrated, for example, for illustrative purposes, with reference to and not intended to limit elements / terminology described in relation to other systems and figures (e.g., Figure 6). One or more parts of the method may be performed additionally or alternatively by other systems.

[0143] In one embodiment, method 900 may begin with operation 905 in which a computing system provisions an isolated virtual environment containing a simulated instance of an update controller, or may otherwise include such provisioning. For example, a test computing system 610 may provision a first virtual environment 600A containing an update controller 605, which is a simulated instance of an update controller 500 (e.g., used in a real-world environment). As described herein, the update controller 605 may include a simulated management service 620 and a simulated vehicle service 625. Within the first virtual environment 600A, the test computing system 610 may provision a vehicle simulator 635, a simulated consumer service (e.g., represented by integration test 645), and a proxy 700 to facilitate mock behavior 705 of several external software services.

[0144] In one embodiment, method 900 may include an operation 910 in which a computing system accesses data indicating rules for delivering an OTA software update. For example, a simulated management service 620 of a test computing system 610 may access data indicating rules 655 for delivering an OTA update 650. Rules 655 for delivering an OTA update 650 may be provided by a simulated consumer service (e.g., integration test 645). For example, in the case of a test simulation run, rule 655 may include the instruction "All 2021 models will be upgraded to infotainment platform version 1.6".

[0145] Method 900 in one embodiment may include an operation 915 in which a computing system determines the actions to be taken to implement an OTA software update. For example, a test computing system 610 may determine an action 660 to be taken to implement an OTA update 650. The action 660 may include actions that a vehicle simulator 635 should take to properly implement the OTA update 650.

[0146] Action 660 may be based on rule 655 for delivering the OTA update 650 and mock behavior 705 of external software services available to the update controller 605. For example, the update controller 650 may process rule 655 and invoke one or more mock external software services 640 in a virtual environment 600A to access information 665 that may help implement the OTA update 650. This may include invoking mock external software services 640 (e.g., mock dependencies 640) that represent services that the update controller 500 can invoke in a real live environment. The response of the mock external software service 640 may include mock behavior 700 (e.g., simulating the response of the corresponding external software service 525) to a request from the update controller 640 in an isolated virtual environment 600A.

[0147] For example, in response to the rule that "all 2021 models will be upgraded to infotainment platform version 1.6," the update controller 640 (for example, its simulated controller component 630) may call the vehicle calling service to obtain the VIN of the 2021 model. Furthermore, the new infotainment software vehicle may behave differently depending on whether the vehicle is equipped with ambient lighting. When this software is delivered, in order to enable the proper implementation of the corresponding OTA update 625, the software may be accompanied by appropriate configuration regarding this ambient lighting feature. Therefore, the update controller 605 may call the mock vehicle configuration service to obtain this configuration information based on the VIN of the 2021 model.

[0148] As described herein, within the first virtual environment 600A, a call may be directed to a proxy 700 where mock behaviors 700 for these services are registered. Through the proxy 700, a call may be directed to an integration test 645 which defines mock behaviors 700 for responding to an update controller request.

[0149] In one embodiment, method 900 may include an operation 920 in which a computing system accesses information to help a vehicle simulator implement an OTA software update based on mock behavior of an external software service. For example, based on mock behavior 700, integration test 645 may provide update controller 605 with vehicle configuration data of requested VINs (e.g., a list of fake VINs) and ambient lighting features. The update controller 605 can access this information 665 to help the vehicle simulator 635 implement an OTA update 650 (e.g., an upgrade to infotainment platform version 1.6).

[0150] Method 900 in one embodiment may include an operation 925 in which a computing system accesses data indicating that a vehicle simulator is available for an OTA software update. For example, a test computing system 610 (e.g., an update controller 605) may access data indicating that a vehicle simulator 635 is available for an OTA update 650. To do so, an integration test 645 may send a communication to the vehicle simulator 635 to trigger the vehicle simulator 635 to provide data indicating that the vehicle simulator 635 is available for an OTA update 650. In one example, this data may be formatted as a request 670 for any available update that may be applicable to the vehicle simulator 635. The vehicle simulator 635 may provide an identifier, such as a VIN associated with the vehicle simulator 635. This may be a fake VIN that matches an entry in a list of fake VINs obtained by the update controller 605 based on the mock behavior 700 of the mock dependency 640.

[0151] In one embodiment, method 900 may include an operation 930 in which a computing system generates a task package for a vehicle simulator that includes an OTA software update and indicates actions taken to implement the OTA software update. For example, a test computing system 610 may generate a task package 675 for a vehicle simulator 635 that includes an OTA update 650 and indicates actions 660 taken to implement the OTA update 650. As an example, an update controller 605 may generate a task package 675 that includes an upgrade to infotainment platform version 1.6, or a reference, pointer, link, address, etc. to it. The task package 675 may also indicate actions 660 taken by the vehicle simulator 635, including, for example, an implement command or instruction for a service to contact.

[0152] Task package 675 may include information 665 to help the vehicle simulator 635 implement the OTA update 650. For example, task package 675 may include vehicle configuration data for ambient lighting features to properly implement an infotainment software upgrade for that particular vehicle simulator 635.

[0153] Method 900 in one embodiment may include an operation 935 in which a computing system outputs a task package to a vehicle simulator in an isolated virtual environment. For example, a test computing system 610 (e.g., an update controller 605) may output a task package 675 to a vehicle simulator 635 in an isolated virtual environment 600A.

[0154] The performance of the update controller 605 can be evaluated based on the end-to-end process. For example, the performance of the update controller 605 (and its ability to handle new OTA updates 650) can be measured by analyzing the capabilities of the update controller. This includes processing rule 655, calling the appropriate mock external software service 640, identifying the action 660 to be taken by the vehicle simulator 635, processing the request 670 from the vehicle simulator 635, generating task package 675, and / or delivering task package 675 to the vehicle simulator 635. Each operation can be measured in terms of efficiency (e.g., timing, latency, etc.) and accuracy (e.g., whether task package 675 contains the appropriate information). Higher efficiency and accuracy indicate better performance of the update controller 605. Additionally or alternatively, the performance of the update controller 605 can be measured by an error metric. The error metric may indicate the frequency, type, or severity of errors encountered during end-to-end simulations performed within the virtual environment 600A. The higher the error metric (for example, due to higher frequency, repeated error types, and higher severity), the lower the performance of the update controller 605. In some implementations, the update controller 605 may enter a validation state when its performance reaches a certain performance threshold.

[0155] In one embodiment, method 900 may include an operation 940 in which the computing system provisions another isolated virtual environment separate from an isolated virtual environment. For example, as described herein, the isolated virtual environment (e.g., used in the aforementioned test for a new infotainment software version 1.6) may be a first isolated virtual environment 600A. The test computing system 610 may provision a second isolated virtual environment 600B separate from the first isolated virtual environment 600A. This may enable the test computing system 610 to run separate isolated simulations on different simulated instances of the update controller 500 for different rules, such as OTA updates, or to run simultaneous simulations for multiple results relating to the same test.

[0156] Method 900 in one embodiment may include an operation 945 in which the computing system removes an isolated virtual environment. This may include destruction, dismantling, deletion, etc. For example, a first isolated virtual environment 600A after one or more tests have been performed, after a performance threshold has been reached, or after a verification state has been achieved. A second isolated virtual environment 600B may remain even after the first isolated virtual environment 600A has been destroyed.

[0157] Figure 10 shows a block diagram of an exemplary computing system 7000 according to one embodiment of the present disclosure. The system 7000 includes a computing system 6005 (e.g., a computing system mounted in a vehicle), a remote computing system 7005 (e.g., a server computing system, a cloud computing platform, a test computing system, etc., located remotely from the vehicle), and a user device 8005 (e.g., a user device for a vehicle user), all of which are communicably coupled via one or more networks 9050. The computing system 6005, the remote computing system 7005, the user device 8005, and the network 9050 may represent systems (and components of those systems) and networks described herein with reference to other figures.

[0158] The computing system 6005 may include one or more computing devices 6010 or circuits. For example, the computing system 6005 may include a control circuit 6015 and a non-temporary computer-readable medium 6020, also referred to herein as memory. In one embodiment, the control circuit 6015 may include one or more processors (e.g., microprocessors), one or more processing cores, a programmable logic circuit (PLC) or programmable logic / gate array (PLA / PGA), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other control circuit. In some implementations, the control circuit 6015 may be part of, or form part of, a vehicle control unit (also referred to as a vehicle controller) that is embedded in or otherwise located in a vehicle (e.g., a Mercedes-Benz® car or van). For example, the vehicle controller may be an infotainment system controller (e.g., an infotainment head unit), a telematics control unit (TCU), an electronic control unit (ECU), a central powertrain controller (CPC), a charge controller, a central external and internal controller (CEIC), a zone controller, or any other controller, or may include these. In one embodiment, the control circuit 6015 may be programmed by one or more computer-readable or computer-executable instructions stored in a non-temporary computer-readable medium (non-temporary CRM) 6020.

[0159] In one embodiment, the non-temporary computer-readable medium 6020 may be a memory device, also called a data storage device, which may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The non-temporary computer-readable medium 6020 may, for example, form a hard disk drive (HDD), a solid-state drive (SDD) or solid-state integrated memory, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), dynamic random access memory (DRAM), portable compact disc read-only memory (CD-ROM), digital multipurpose disc (DVD), and / or memory stick.

[0160] Non-temporary computer-readable medium 6020 can store information that can be accessed by the control circuit 6015. For example, non-temporary computer-readable medium 6020 (e.g., a memory device) can store data 6025 that can be acquired, received, accessed, written, manipulated, created, and / or stored. Data 6025 may include, for example, any of the data or information described herein. In some implementations, computing system 6005 can acquire data from one or more memories located remotely from computing system 6005.

[0161] The non-temporary computer-readable medium 6020 may also store computer-readable instructions 6030 that can be executed by the control circuit 6015. Instructions 6030 may be software written in any suitable programming language, or they may be implemented in hardware. Instructions may include computer-readable instructions, computer-executable instructions, and so on. As described herein, in various embodiments, the terms “computer-readable instructions” and “computer-executable instructions” are used to describe software instructions or computer code configured to perform various tasks and operations. In various embodiments, where computer-readable or computer-executable instructions form a module, the term “module” broadly refers to a set of software instructions or code configured to cause the control circuit 6015 to perform one or more functional tasks. Modules and computer-readable / executable instructions may be described as performing various operations or tasks when the control circuit 6015 or other hardware components execute the module or computer-readable instructions.

[0162] Instruction 6030 may be executed in a separate logical and / or virtual thread on the control circuit 6015. For example, non-temporary computer-readable medium 6020 may store instruction 6030, which, when executed by the control circuit 6015, causes the control circuit 6015 to perform any of the operations, methods, and / or processes described herein. In some cases, non-temporary computer-readable medium 620 may store computer-executable instructions or computer-readable instructions, such as instructions for performing at least a portion of the method shown in Figure 9.

[0163] The computing system 6005 may include one or more communication interfaces 6035. The communication interfaces 6035 may be used to communicate with one or more other systems. The communication interfaces 6035 may include any circuits, components, software, etc., for communicating over one or more networks (e.g., network 750). In some implementations, the communication interfaces 6035 may include, for example, one or more communication controllers, receivers, transceivers, transmitters, ports, conductors, software, and / or hardware for communicating data / information.

[0164] The computing system 6005 may also include one or more user input components 6040 that receive user input. For example, a user input component 6040 may be a touch-sensitive component (e.g., a touch-sensitive display screen or touchpad) that is sensitive to the touch of a user input object (e.g., a finger or stylus). The touch-sensitive component may function to implement a virtual keyboard. Other exemplary user input components include a microphone, a conventional keyboard, a cursor device, a joystick, or other devices to which the user may provide user input.

[0165] The computing system 6005 may include one or more output components 6045. The output components 6045 may include hardware and / or software for generating content audibly or visually. For example, the output components 6045 may include one or more speakers, earphones, headsets, handsets, etc. The output components 6045 may include a display device that may include hardware for displaying a user interface and / or messages for the user. For example, the output components 6045 may include a display screen, CRT, LCD, plasma screen, touchscreen, TV, projector, tablet, and / or other suitable display components.

[0166] The remote computing system 7005 may include one or more computing devices 710. In one embodiment, the remote computing system 7005 may include one or more server computing devices, or otherwise be implemented therein. If the remote computing system 7005 includes multiple server computing devices, such server computing devices may operate according to a sequential computing architecture, a parallel computing architecture, or any combination thereof.

[0167] The remote computing system 7005 may include a control circuit 7015 and a non-temporary computer-readable medium (non-temporary CRM) 7020, also referred to herein as memory 7020. In one embodiment, the control circuit 7015 may include one or more processors (e.g., microprocessors), one or more processing cores, a programmable logic circuit (PLC) or programmable logic / gate array (PLA / PGA), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other control circuit. In one embodiment, the control circuit 7015 may be programmed by one or more computer-readable or computer-executable instructions stored in the non-temporary computer-readable medium 7020.

[0168] In one embodiment, the non-temporary computer-readable medium 7020 may be a memory device, also called a data storage device, which may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The non-temporary computer-readable medium may, for example, form a hard disk drive (HDD), a solid-state drive (SDD) or solid-state integrated memory, random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), dynamic random-access memory (DRAM), portable compact disc read-only memory (CD-ROM), or digital multipurpose disc (DVD), and / or memory stick.

[0169] Non-temporary computer-readable medium 7020 can store information that can be accessed by the control circuit 7015. For example, non-temporary computer-readable medium 7020 (e.g., a memory device) can store data 7025 that can be acquired, received, accessed, written, manipulated, created, and / or stored. The data 7025 may include, for example, any of the data or information described herein. In some implementations, a remote computing system 7005 can acquire data from one or more remotely located memories from the remote computing system 7005.

[0170] The non-temporary computer-readable medium 7020 may also store computer-readable instructions 7030 that can be executed by the control circuit 7015. Instructions 7030 may be software written in any suitable programming language, or they may be implemented in hardware. Instructions may include computer-readable instructions, computer-executable instructions, and so on. As described herein, in various embodiments, the terms “computer-readable instructions” and “computer-executable instructions” are used to describe software instructions or computer code configured to perform various tasks and operations. In various embodiments, where computer-readable or computer-executable instructions form a module, the term “module” broadly refers to a set of software instructions or code configured to cause the control circuit 7015 to perform one or more functional tasks. Modules and computer-readable / executable instructions may be described as performing various operations or tasks when the control circuit 7015 or other hardware components execute the module or computer-readable instructions.

[0171] Instruction 7030 may be executed in a separate logical and / or virtual thread on the control circuit 7015. For example, non-temporary computer-readable medium 7020 may store instruction 7030, and when instruction 7030 is executed by the control circuit 7015, it causes the control circuit 7015 to perform any of the operations, methods, and / or processes described herein. This may include operations described as being performed by the test computing system 610. In some cases, non-temporary computer-readable medium 7020 may store computer-executable instructions or computer-readable instructions, such as instructions for performing at least a portion of the data flows and methods / processes shown in Figures 5–9.

[0172] The server computing system 7005 may include one or more communication interfaces 7035. The communication interface 7035 may be used to communicate with one or more other systems. The communication interface 7035 may include any circuits, components, software, etc., for communication over one or more networks (e.g., network 9050). In some implementations, the communication interface 7035 may include, for example, one or more communication controllers, receivers, transceivers, transmitters, ports, conductors, software, and / or hardware for communicating data / information.

[0173] The computing system 6005 and / or the server computing system 7005 may also communicate with a user device 8005 that is connected to the network 9050 in a communicative manner.

[0174] The user device 8005 may include one or more computing devices 8010. The user device 8005 may include a control circuit 8015 and a non-temporary computer-readable medium (non-temporary CRM) 8020, also referred to herein as memory 8020. In one embodiment, the control circuit 8015 may include one or more processors (e.g., microprocessors), one or more processing cores, a programmable logic circuit (PLC) or programmable logic / gate array (PLA / PGA), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other control circuit. In one embodiment, the control circuit 8015 may be programmed by one or more computer-readable or computer-executable instructions stored in the non-temporary computer-readable medium 8020.

[0175] In one embodiment, the non-temporary computer-readable medium 8020 may be a memory device, also called a data storage device, which may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The non-temporary computer-readable medium may form, for example, a hard disk drive (HDD), a solid-state drive (SDD) or solid-state integrated memory, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), dynamic random access memory (DRAM), portable compact disc read-only memory (CD-ROM), digital multipurpose disc (DVD), and / or memory stick.

[0176] Non-temporary computer-readable medium 8020 can store information that can be accessed by the control circuit 8015. For example, non-temporary computer-readable medium 820 (e.g., a memory device) can store data 8025 that can be acquired, received, accessed, written, manipulated, created, and / or stored. The data 8025 may include, for example, any of the data or information described herein. In some implementations, a user device 8005 can acquire data from one or more memories located remotely from the user device 8005.

[0177] The non-temporary computer-readable medium 8020 may also store computer-readable instructions 8030 that can be executed by the control circuit 8015. Instructions 8030 may be software written in any suitable programming language, or they may be implemented in hardware. Instructions may include computer-readable instructions, computer-executable instructions, and so on. As described herein, in various embodiments, the terms “computer-readable instructions” and “computer-executable instructions” are used to describe software instructions or computer code configured to perform various tasks and operations. In various embodiments, where computer-readable or computer-executable instructions form a module, the term “module” broadly refers to a set of software instructions or code configured to cause the control circuit 8015 to perform one or more functional tasks. Modules and computer-readable / executable instructions may be described as performing various operations or tasks when the control circuit 8015 or other hardware components execute the module or computer-readable instructions.

[0178] Instruction 8030 may be executed in a separate thread, either logically or virtually, on the control circuit 8015. For example, non-temporary computer-readable medium 8020 may store instruction 8030, which, when executed by the control circuit 8015, causes the control circuit 8015 to perform any of the operations, methods, and / or processes described herein. In some cases, non-temporary computer-readable medium 8020 may store computer-executable instructions or computer-readable instructions, such as instructions for performing at least a portion of the method shown in Figure 9.

[0179] The user device 8005 may include one or more communication interfaces 8035. The communication interfaces 8035 may be used to communicate with one or more other systems. The communication interfaces 8035 may include any circuits, components, software, etc., for communicating over one or more networks (e.g., network 9050). In some implementations, the communication interfaces 8035 may include, for example, one or more communication controllers, receivers, transceivers, transmitters, ports, conductors, software, and / or hardware for communicating data / information.

[0180] The user device 8005 may also include one or more user input components 840 that receive user input. For example, user input component 8040 may be a touch-sensitive component (e.g., a touch-sensitive display screen or touchpad) that is sensitive to the touch of a user input object (e.g., a finger or stylus). The touch-sensitive component may function to implement a virtual keyboard. Other exemplary user input components include a microphone, a conventional keyboard, a cursor device, a joystick, or other devices to which the user may provide user input.

[0181] The user device 8005 may include one or more output components 8045. The output components 8045 may include hardware and / or software for generating content audibly or visually. For example, the output components 8045 may include one or more speakers, earphones, headsets, handsets, etc. The output components 8045 may include a display device which may include hardware for displaying a user interface and / or messages for the user. For example, the output components 8045 may include a display screen, CRT, LCD, plasma screen, touchscreen, TV, projector, tablet, and / or other suitable display components.

[0182] One or more networks 9050 may be any type of communication network, such as a local area network (e.g., an intranet), a wide area network (e.g., the Internet), or any combination thereof, and may include any number of wired or wireless links. In general, communication over networks 9050 may be carried over any type of wired and / or wireless connection using a wide variety of communication protocols (e.g., TCP / IP, HTTP, SMTP, FTP), encoding or formatting (e.g., HTML, XML), and / or protection schemes (e.g., VPN, Secure HTTP, SSL).

[0183] Further consideration of various embodiments Embodiment 1 relates to a computing system. The computing system includes a control circuit configured to test an update controller for delivering OTA (over-the-air) software updates within an isolated virtual environment. The control circuit is configured to access data indicating the rules for delivering the OTA software updates. The control circuit is configured to determine the actions taken to implement the OTA software updates. The actions are based on the rules for delivering the OTA software updates and mock behavior of external software services available to the update controller. The mock behavior simulates the response of external software services to requests from the update controller within the isolated virtual environment. The control circuit is configured to access data indicating that a vehicle simulator is available for the OTA software updates. The control circuit is configured to generate a task package for the vehicle simulator that includes the OTA software updates and indicates the actions taken to implement the OTA software updates. The control circuit is configured to output the task package to the vehicle simulator within the isolated virtual environment.

[0184] Embodiment 2 includes the computing system of Embodiment 1. In this embodiment, the control circuit is further configured to provision an isolated virtual environment which includes a simulated instance of the update controller, which includes simulated management services and simulated vehicle services.

[0185] Embodiment 3 includes the computing system described in Embodiment 1 or 2. In this embodiment, to provision an isolated virtual environment, the control circuit is configured to provision proxies within the isolated virtual environment to facilitate mock behavior of a vehicle simulator, simulated consumer services, and multiple external software services.

[0186] Embodiment 4 includes the computing system described in any of Embodiments 1 to 3. In this embodiment, the rules for delivering OTA software updates are provided by a simulated consumer service.

[0187] Embodiment 5 includes the computing system described in any of Embodiments 1 to 4. In this embodiment, the simulated consumer service is configured to send communications to the vehicle simulator to trigger the vehicle simulator to provide data indicating that the vehicle simulator is available for an OTA software update.

[0188] Embodiment 6 includes the computing system described in any of Embodiments 1 to 5. In this embodiment, mock behavior is registered with the proxy before running a simulation test of the update controller.

[0189] Embodiment 7 includes the computing system described in any of Embodiments 1 to 6. In this embodiment, the mock behavior is based on the behavior of external software services in a live environment.

[0190] Embodiment 8 includes the computing system described in any of Embodiments 1 to 7. In this embodiment, the mock behavior is based on log data generated during communication between the update controller and an external software service in a live computing environment. The log data includes request parameters associated with the update controller, a response payload provided by the external software service, and a response time indicating the duration until the external software service responds to the update controller.

[0191] Embodiment 9 includes the computing system described in any of Embodiments 1 to 8. In this embodiment, log data is processed to determine the expected behavior of an external software service. The mock behavior is based on the expected behavior of the external software service.

[0192] Embodiment 10 includes the computing system described in any of Embodiments 1 to 9. In this embodiment, the control circuit is further configured to access information to help the vehicle simulator implement an OTA software update based on mock behavior of an external software service. The task package includes information to help the vehicle simulator implement an OTA software update.

[0193] Embodiment 11 includes the computing system described in any of Embodiments 1 to 10. In this embodiment, the external software service is a vehicle configuration service, and the information to assist the vehicle simulator in implementing an OTA software update includes vehicle configuration data of the vehicle components associated with the OTA software update.

[0194] Embodiment 12 includes the computing system described in any of Embodiments 1 to 11. In this embodiment, the control circuit utilizes a cloud-based computing platform infrastructure.

[0195] Embodiment 13 includes the computing system described in any of Embodiments 1 to 12. In this embodiment, the isolated virtual environment is a first isolated virtual environment, the control circuit is configured to provision a second isolated virtual environment separate from the first isolated virtual environment, and includes a simulated instance of an update controller separate from the first isolated virtual environment.

[0196] Embodiment 14 includes the computing system described in any of Embodiments 1 to 13. In this embodiment, the control circuit is further configured to eliminate isolated virtual environments.

[0197] Embodiment 15 relates to a computer implementation method for testing an update controller for delivering OTA (over-the-air) software updates within an isolated virtual environment. In this embodiment, the method includes accessing data indicating rules for delivering OTA software updates. The method includes determining the actions to be taken to implement the OTA software update. The actions are based on the rules for delivering the OTA software update and mock behavior of external software services available to the update controller. The mock behavior simulates the response of external software services to requests from the update controller in an isolated virtual environment. The method includes accessing data indicating that a vehicle simulator is available for the OTA software update. The method includes generating a task package for the vehicle simulator that includes the OTA software update and indicating the actions to be taken to implement the OTA software update. The method includes outputting the task package to the vehicle simulator in an isolated virtual environment.

[0198] Embodiment 16 includes the method described in Embodiment 14. In this embodiment, the method further includes provisioning an isolated virtual environment containing a simulated instance of the update controller.

[0199] Embodiment 17 includes the method according to any one of Embodiments 1 to 16. In this embodiment, the method includes accessing information to help the vehicle simulator implement an OTA software update based on mock behavior of an external software service. The task package includes information to help the vehicle simulator implement an OTA software update.

[0200] Embodiment 18 includes the method of any one of Embodiments 1 to 17. In this embodiment, the isolated virtual environment is a first isolated virtual environment, and the method further includes provisioning a second isolated virtual environment separate from the first isolated virtual environment.

[0201] Embodiment 19 includes the method of any one of Embodiments 1 to 18. In this embodiment, the method further includes removing the isolated virtual environment.

[0202] Embodiment 20 relates to one or more non-temporary computer-readable media that store instructions executable by a control circuit configured to test an update controller for delivering OTA (over-the-air) software updates within an isolated virtual environment. In this embodiment, the control circuit is configured to access data indicating rules for delivering OTA software updates. The control circuit is configured to determine the actions taken to implement the OTA software update. The actions are based on the rules for delivering the OTA software update and mock behavior of external software services available to the update controller. The mock behavior simulates the response of the external software service to a request from the update controller in the isolated virtual environment. The control circuit is configured to access data indicating that a vehicle simulator is available for the OTA software update. The control circuit is configured to generate a task package for the vehicle simulator that includes the OTA software update and indicates the actions taken to implement the OTA software update. The control circuit is configured to output the task package to the vehicle simulator in the isolated virtual environment.

[0203] Additional disclosures Where used herein, adjectives and their possessive forms shall be used interchangeably unless otherwise evident from the context and / or explicitly indicated. For example, “vehicle components” may be used interchangeably with “vehicle components” where appropriate. Similarly, words, phrases and other disclosures herein are intended to encompass obvious variations and synonyms, even if such variations and synonyms are not explicitly listed.

[0204] Computing tasks and operations discussed herein as being performed on or by a remote computing device from a vehicle may instead be performed in the vehicle (e.g., via a vehicle computing system), and vice versa.

[0205] The technologies described herein refer to servers, databases, software applications, and other computer-based systems, as well as actions performed and information transmitted to and from such systems. The inherent flexibility of computer-based systems allows for a wide variety of possible configurations, combinations, and divisions of tasks and functions between components. For example, the processes described herein may be performed using a single device or component, or multiple devices or components operating in combination. Databases and applications may run on a single system or be distributed across multiple systems. Distributed components may operate sequentially or in parallel.

[0206] While the subject matter has been described in detail with respect to various specific exemplary embodiments thereof, each example is provided for illustrative purposes only and not as an limitation of the disclosure. Those skilled in the art, having achieved the foregoing understanding, can readily generate modifications, variations, and equivalents of such embodiments. Therefore, the disclosure does not exclude such modifications, variations, and / or additional inclusions to the subject matter, as will be readily apparent to those skilled in the art. For example, features illustrated or described as part of one embodiment may be used in conjunction with another embodiment to result in yet another embodiment. Thus, the disclosure is intended to encompass such modifications, variations, and equivalents.

[0207] The aspects of this disclosure are described in relation to exemplary implementations thereof. Numerous other implementations, modifications, or variations within the scope and spirit of the appended claims may be recalled to those skilled in the art from the examination of this disclosure. Any and all features in the following claims may be combined or rearranged in any possible manner. Thus, the scope of this disclosure is illustrative and not limiting, and this disclosure does not exclude such modifications, variations, or additional inclusions to the subject matter, as will be readily apparent to those skilled in the art. Furthermore, terms are used herein with reference to lists of exemplary elements joined by conjunctions such as “and,” “or,” and “but.” It should be understood that such conjunctions are provided for illustrative purposes only. The terms “or” and “and / or” may be used interchangeably herein. For example, a list joined by a particular conjunction such as “or” may refer to “at least one” or “any combination” of the exemplary elements enumerated therein, and “or” shall be understood as “and / or” unless otherwise indicated. Also, terms such as “based on” should be understood as “at least partially based on.”

[0208] Those skilled in the art will understand, by using the disclosures provided herein, that any element of the claims, actions, or processes discussed herein may be adapted, rearranged, expanded, omitted, combined, or modified in various ways without departing from the scope of this disclosure. Sometimes, elements may be enumerated in the specification or claims using letter references for illustrative purposes and not intended to be limiting. Where used, letter references do not imply a particular order of actions or the importance of any particular element listed. For example, letter identifiers such as (a), (b), (c), ..., (i), (ii), (iii), ... may be used to indicate actions or different elements within a list. Such identifiers are provided for the convenience of the reader and do not indicate a particular order, importance, or priority of steps, actions, or elements. For example, an action indicated by a list identifier such as (a), (i) may be performed before, after, or concurrently with another action indicated by a list identifier such as (b), (ii).

Claims

1. A computing system, The system includes a control circuit configured to test an update controller for delivering over-the-air (OTA) software updates within an isolated virtual environment, the control circuit being: Access the data that specifies the rules for distributing the aforementioned OTA software update, Actions taken to implement the OTA software update, the actions being determined based on the rules for distributing the OTA software update and the mock behavior of external software services available to the update controller, The mock behavior simulates the response of the external software service to a request from the update controller within the isolated virtual environment. Access data indicating that the vehicle simulator is available for the OTA software update, For the vehicle simulator, a task package is generated that includes the OTA software update and indicates the actions taken to implement the OTA software update. A computing system configured to output the task package to the vehicle simulator in the isolated virtual environment.

2. The aforementioned control circuit is The computing system according to claim 1, further configured to provision the isolated virtual environment, which includes a simulated instance of the update controller, which includes simulated management services and simulated vehicle services.

3. To provision the isolated virtual environment, the control circuit, Within the isolated virtual environment, the vehicle simulator, simulated consumer services, and proxies to facilitate mock behavior of multiple external software services are provisioned. The computing system according to claim 2, configured as described above.

4. The computing system according to claim 3, wherein the rules for distributing the OTA software update are provided by the simulated consumer service.

5. The computing system according to claim 3, wherein the simulated consumer service is configured to send a communication to the vehicle simulator to trigger the vehicle simulator to provide the data indicating that the vehicle simulator is available for the OTA software update.

6. The computing system according to claim 3, wherein the mock behavior is registered with the proxy before the simulation test of the update controller is performed.

7. The computing system according to claim 1, wherein the mock behavior is based on the behavior of the external software service in a live environment.

8. The computing system according to claim 7, wherein the mock behavior is based on log data generated during communication between the update controller and the external software service in the live computing environment, the log data including request parameters associated with the update controller, a response payload provided by the external software service, and a response time indicating the duration until the external software service responds to the update controller.

9. The computing system according to claim 8, wherein the log data is processed to determine the predicted behavior of the external software service, and the mock behavior is based on the predicted behavior of the external software service.

10. The aforementioned control circuit is Based on the mock behavior of the external software service, the vehicle simulator is further configured to access information to assist in implementing the OTA software update. The computing system according to claim 1, wherein the task package includes the information for assisting the vehicle simulator in implementing the OTA software update.

11. The computing system according to claim 10, wherein the external software service is a vehicle configuration service, and the information for assisting the vehicle simulator in implementing the OTA software update includes vehicle configuration data of vehicle components associated with the OTA software update.

12. The computing system according to claim 1, wherein the control circuit utilizes a cloud-based computing platform infrastructure.

13. The computing system according to claim 1, wherein the isolated virtual environment is a first isolated virtual environment, and the control circuit is separate from the first isolated virtual environment and is configured to provision a second isolated virtual environment which includes a simulated instance of the update controller separate from the first isolated virtual environment.

14. The computing system according to claim 1, wherein the control circuit is further configured to remove the isolated virtual environment.

15. A computer implementation method for testing an update controller for delivering over-the-air (OTA) software updates within an isolated virtual environment, Access the data that specifies the rules for distributing the aforementioned OTA software update, Actions taken to implement the OTA software update, the actions being determined based on the rules for distributing the OTA software update and the mock behavior of external software services available to the update controller, The mock behavior simulates the response of the external software service to a request from the update controller within the isolated virtual environment. Access data indicating that the vehicle simulator is available for the OTA software update, For the vehicle simulator, a task package is generated that includes the OTA software update and indicates the actions taken to implement the OTA software update. A computer implementation method comprising outputting the task package to the vehicle simulator in the isolated virtual environment.

16. The computer implementation method according to claim 15, further comprising provisioning the isolated virtual environment which includes a simulated instance of the update controller.

17. The further includes accessing information to assist the vehicle simulator in implementing the OTA software update based on the mock behavior of the external software service, The task package includes the information to help the vehicle simulator implement the OTA software update. The computer implementation method according to claim 15.

18. The isolated virtual environment is a first isolated virtual environment, and the method is Further comprising provisioning a second isolated virtual environment separate from the first isolated virtual environment, The computer implementation method according to claim 15.

19. The computer implementation method according to claim 15, further comprising removing the isolated virtual environment.

20. One or more non-temporary computer-readable media storing instructions executable by a control circuit configured to test an update controller for delivering over-the-air (OTA) software updates within an isolated virtual environment, wherein the control circuit is: Access the data that specifies the rules for distributing the aforementioned OTA software update, Actions taken to implement the OTA software update, the actions being determined based on the rules for distributing the OTA software update and the mock behavior of external software services available to the update controller, The mock behavior simulates the response of the external software service to a request from the update controller within the isolated virtual environment. Access data indicating that the vehicle simulator is available for the OTA software update, For the vehicle simulator, a task package is generated that includes the OTA software update and indicates the actions taken to implement the OTA software update. Output the task package to the vehicle simulator in the isolated virtual environment. A non-temporary computer-readable medium configured in such a way.

Images