Techniques for reactive behavior while handling the task of updating vehicle wireless software.

Abstract

A method relating to over-the-air (OTA) vehicle software updates includes obtaining OTA vehicle software updates for multiple vehicles and determining a task for a first vehicle among the multiple vehicles based on the OTA vehicle software updates. The task may be associated with multiple task states. The method further includes determining, while processing the task with respect to the first vehicle, that the task has experienced a task state transition from a first task state to a second task state, and selecting a response action from multiple response actions in response to the task state transition, the response action including a computing action performed in response to the task state transition. The method further includes processing the response actions independently of the first vehicle performing the task.

Description

Technical Field

[0005] , ,

[0001] The present disclosure generally relates to performing over-the-air (OTA) updates of vehicles. In particular, the present disclosure relates to processing reactive operations while tasks are being processed for OTA updates related to a vehicle.

Background Art

[0002] Over-the-air (OTA) updates refer to the process of wirelessly updating the software of devices such as smartphones, Internet of Things (IoT) devices, or vehicles. OTA updates enable manufacturers to remotely push updates and patches to devices without requiring the user to connect the device or manually install the updates.

[0003] OTA updates are generally used to fix software bugs, improve device performance, add new features, and address 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 deliver updates quickly and efficiently.

Summary of the Invention

[0004] Aspects and advantages of embodiments of the present disclosure may be learned in part from the following description, or may be learned by studying or by practicing the embodiments described.

Means for Solving the Problems

[0005] One exemplary aspect of the present disclosure relates to a computer implementation method relating to over-the-air (OTA) vehicle software updates. The computer implementation method may include: obtaining OTA vehicle software updates for a plurality of vehicles; determining a task for a first vehicle of the plurality of vehicles based on the OTA vehicle software updates, the task being associated with a plurality of task states; determining, while processing the task with respect to the first vehicle, that the task has experienced a task state transition from a first task state of the plurality of task states to a second task state of the plurality of task states; selecting a response action from a plurality of response actions in response to the task state transition, the response action including a computing action performed in response to the task state transition; and processing the response action independently of the first vehicle performing the task.

[0006] In one embodiment, the reaction operation is logically and temporally separated from the task state transition from the first task state to the second task state.

[0007] In one embodiment, selecting a reaction action from a plurality of reaction actions includes identifying the reaction action based on an action associated with the task.

[0008] In one embodiment, the action includes upgrading the software version installed in the first vehicle.

[0009] In one embodiment, the method further includes retrieving information about the response behavior when a first task state transitions to a second task state.

[0010] In one embodiment, the method further includes queuing the reaction operation so that the reaction operation is processed asynchronously with the first vehicle performing the task.

[0011] In one embodiment, a plurality of vehicles belong to the same class of vehicles, and the computer implementation method further includes determining the actions to be performed by the class of vehicles and associating the response actions with the actions.

[0012] In one embodiment, the response action includes at least one of the following: (a) sending a notification regarding the status of an OTA vehicle software update to a first vehicle and / or a user associated with the first vehicle; (b) sending information about the OTA vehicle software update to an external computing system that tracks status information of OTA vehicle software updates associated with multiple vehicles; (c) changing a property associated with the first vehicle in the external computing system; or (d) waking up a network device associated with the first vehicle.

[0013] In one embodiment, a task corresponds to a connection action of a first vehicle connecting to one or more computing systems via a network, and a connection action is defined by associating a response action with the connection action.

[0014] Another exemplary aspect of the present disclosure relates to a computing system having a control circuit. The control circuit may be configured to obtain over-the-air (OTA) vehicle software updates for a plurality of vehicles, determine a task for a first vehicle of the plurality of vehicles based on the OTA vehicle software updates, the task being associated with a plurality of task states, and while processing the task with respect to the first vehicle, determine that the task has experienced a task state transition from a first task state of the plurality of task states to a second task state of the plurality of task states, select a response action from a plurality of response actions in response to the task state transition, the response action including a computing action performed in response to the task state transition, and processing the response action independently of the vehicle performing the task.

[0015] In one embodiment, the reaction operation is logically and temporally separated from the task state transition from the first task state to the second task state.

[0016] In one embodiment, the control circuit is configured to retrieve information regarding the response operation when the first task state transitions to the second task state.

[0017] In one embodiment, the control circuit is configured to queue reaction actions so that the reaction actions are processed asynchronously with respect to the first vehicle performing the task.

[0018] In one embodiment, multiple vehicles belong to the same class of vehicles, and the control circuit is configured to determine the actions performed by the vehicle class and to associate the response behavior with the actions.

[0019] In one embodiment, the response actions processed by the control circuit include at least one of the following: (a) sending a notification regarding the status of an OTA vehicle software update to a first vehicle and / or a user associated with the first vehicle; (b) sending information about the OTA vehicle software update to an external computing system that tracks status information of OTA vehicle software updates associated with multiple vehicles; (c) changing a property associated with the first vehicle in the external computing system; or (d) waking up a network device associated with the first vehicle.

[0020] In one embodiment, a task corresponds to a connection action of a first vehicle connecting to one or more computing systems via a network, and a connection action is defined by associating a response action with the connection action.

[0021] A further exemplary aspect of the present disclosure relates to one or more non-temporary computer-readable media for storing instructions, wherein the instructions are executable by a control circuit to perform an action. The control circuit may obtain over-the-air (OTA) vehicle software updates for a plurality of vehicles, determine a task for a first vehicle of the plurality of vehicles based on the OTA vehicle software updates, the task is associated with a plurality of task states, and while processing the task with respect to the first vehicle, determine that the task has experienced a task state transition from a first task state of the plurality of task states to a second task state of the plurality of task states, select a response action from a plurality of response actions to be processed in response to the task state transition, and process the response action independently of the first vehicle performing the task.

[0022] In one embodiment, the reaction operation is logically and temporally separated from the task state transition from the first task state to the second task state.

[0023] In one embodiment, the response action includes at least one of the following: (a) sending a notification regarding the status of an OTA vehicle software update to a first vehicle and / or a user associated with the first vehicle; (b) sending information about the OTA vehicle software update to an external computing system that tracks status information of OTA vehicle software updates associated with multiple vehicles; (c) changing a property associated with the first vehicle in the external computing system; or (d) waking up a network device associated with the first vehicle.

[0024] 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.

[0025] These and other features, aspects, and advantages of the various embodiments will become better understood with reference to the following description and the appended claims. The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and, together with the description, serve to explain the related principles.

[0026] A detailed description of embodiments directed to those skilled in the art is set forth in this specification, which refers to the accompanying drawings.

Brief Description of the Drawings

[0027] [Figure 1] An exemplary computing ecosystem according to an exemplary embodiment of the present disclosure is shown. [Figure 2A] An overview of a vehicle computing system according to an exemplary embodiment of the present disclosure is illustrated. [Figure 2B] An overview of a computing platform remote from a vehicle according to an exemplary embodiment of the present disclosure is shown. [Figure 3] An exemplary task state machine showing an exemplary state of a task according to an exemplary embodiment of the present disclosure is shown. [Figure 4] An exemplary schematic diagram for processing reaction operations while processing a task according to an exemplary embodiment of the present disclosure is shown. [Figure 5A] An exemplary schematic diagram for processing task state change operations while processing a task according to an exemplary embodiment of the present disclosure is shown. [Figure 5B] An exemplary schematic diagram of reaction queue processing operations while processing a task according to an exemplary embodiment of the present disclosure is shown. [Figure 5C] [[ID=3३]]An exemplary schematic diagram of notification reaction handler operations while processing a task according to an exemplary embodiment of the present disclosure is shown. [Figure 6] A flowchart diagram of an exemplary method 6000 for processing tasks and reaction operations related to wireless (OTA) vehicle software updates according to an exemplary embodiment of the present disclosure is shown. [Figure 7]A block diagram of an exemplary computing ecosystem having computing components according to exemplary embodiments of this disclosure is shown. [Modes for carrying out the invention]

[0028] Aspects of this disclosure relate to a method and computing system for transmitting OTA software updates over a network (e.g., a cellular network), along with response operations corresponding to computing operations performed in response to task state (task stage) transitions that occur during the processing of tasks associated with OTA software updates.

[0029] In some examples, if additional workflow actions are added to an OTA update workflow (e.g., notifying the user about an update), a new task state may be introduced into the OTA workflow and the task state machine (e.g., adding a task state "staged_notification" after a "staged" task state), and the computing system may be configured to perform the notification action in response to the task state reaching the "staged_notification" state. However, this approach dramatically increases the complexity of the computing system as new workflow actions (task states) are added to a task (e.g., increased use of computing resources). Furthermore, it is necessary to support multiple versions for tasks that require a notification action and tasks that do not. If another workflow action is added to a task, four versions would need to be supported. In contrast to this approach, according to the examples of this disclosure, the reaction action is performed as a "side effect" when the first task state changes or transitions to the second task state.

[0030] For example, a computing system (e.g., a cloud-based computing platform) may include a control circuit configured to retrieve OTA vehicle software updates for multiple vehicles and determine a task for a first vehicle among the multiple vehicles based on the OTA vehicle software updates. A task may be associated with multiple task states. While processing a task with respect to the first vehicle, the control circuit may be further configured to determine that the task has experienced a task state transition from a first task state among multiple task states to a second task state among multiple task states. In response to a task state transition, the control circuit may select a response action from several response actions to be processed. A response action may include computing actions performed in response to a task state transition. The control circuit may be further configured to process response actions independently of the vehicle performing the task.

[0031] Reaction behavior may not be defined as part of a task state or task state machine, or may not be included in it. Instead, reaction behavior may be defined in relation to, or in connection with, the action of a rule referenced at the time of a task state transition.

[0032] According to some embodiments, the reaction actions address the side effects of task state transitions without interfering with the task workflow performed to successfully complete the OTA software update. Since the reaction actions are merely side effects of the general OTA workflow and are separated from it, the general OTA workflow remains efficient and stable. For example, the reaction actions can be logically and temporally separated from the underlying task state transitions by an indirect queuing mechanism for reaction processing triggered by task state changes. That is, the reaction actions may be stored in a reaction queue or other storage device and may be processed asynchronously with respect to task processing.

[0033] In one embodiment, the computing system may process reactive actions in response to changes in the state of tasks for connection tasks (for example, for connection actions for vehicles connecting to a backend system).

[0034] In some implementations, the response may include (a) sending a notification regarding the status of the OTA vehicle software update to the first vehicle and / or a user associated with the first vehicle; (b) sending information about the OTA vehicle software update to an external computing system that tracks the status information of OTA vehicle software updates associated with multiple vehicles; (c) modifying properties associated with the first vehicle in the external computing system; or (d) waking up a network device (e.g., a gateway) associated with the first vehicle (e.g., associated with the vehicle identification number), or a combination thereof.

[0035] The technology disclosed herein offers several computing improvements and technical benefits. For example, the technology disclosed herein can improve the efficiency of computing resources by reducing the complexity of OTA workflows, reducing the number of workflow versions, and increasing the stability of OTA workflows. For example, the response actions described herein are performed independently of the workflow actions of the OTA software update workflow (e.g., in a logically and temporally separated manner). For example, in a first approach in which the OTA update workflow also includes notifying a user (e.g., a customer), a new task state such as "Staged_Notification" can be introduced after "Staged," and the computing system is configured to perform a notification action in response to the task state reaching the "Staged_Notification" state. However, this approach dramatically increases the complexity of the computing system (e.g., increased use of computing resources) as new workflow actions (task states) are added to a task. Furthermore, it is necessary to support multiple versions for tasks that require notification actions and tasks that do not. If another workflow action is added to a task, four versions need to be supported. In contrast to the first approach, according to the examples of this disclosure, the reaction action is performed as a “side effect” when the first task state changes or transitions to the second task state. The described reaction action does not interfere with the task state transition itself. For example, the reaction action is logically and temporally separated from the underlying task state transition by an indirect queuing mechanism for reaction processing triggered by the task state change, as described herein.

[0036] The technologies of this disclosure may also improve computing technologies for distributing tasks, along with operations that may be associated with those tasks, and may improve the performance of the computers of task recipients, such as vehicles, and the performance of computing systems that transmit tasks, such as service providers or cloud-based computing platforms (e.g., manufacturers or other entities responsible for providing or managing software updates). For example, a computing system (e.g., a cloud-based computing platform) may include a control circuit configured to retrieve OTA vehicle software updates for multiple vehicles and determine a task for a first vehicle among the multiple vehicles based on the OTA vehicle software updates, with the task being associated with multiple task states. The control circuit may further be configured, while processing a task with respect to a first vehicle, to determine that the task has experienced a task state transition from a first task state among multiple task states to a second task state among multiple task states, and to select a response from multiple response actions in response to the task state transition, the response action including computing operations performed in response to the task state transition. The control circuit may further be configured to process the response actions independently of the vehicle performing the task. In this way, the computing system can improve the efficiency and frequency with which download tasks (e.g., OTA updates) are successfully delivered to vehicles, while also allowing the computing system to handle reactive operations in an independent and efficient manner. This is because, by adding task states as described above, the wasted computation or added complexity associated with performing the operation can be reduced. This can lead to improved use of computing resources in the system (and network).

[0037] As illustrated by the examples disclosed herein, a vehicle-mounted computing system may be more likely to receive updates and stay up-to-date by avoiding the addition of task states to the OTA workflow, which can increase the complexity of the OTA workflow and the likelihood of errors occurring during task processing.

[0038] Hereinafter, embodiments are referenced in detail, with one or more examples shown in the drawings. Each example is provided as a description of the embodiments, not as a limitation of the disclosure. Indeed, it will be apparent to those skilled in the art that various modifications and variations can be made to the embodiments without departing from the scope or spirit of the disclosure. 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, aspects of the disclosure are intended to encompass such modifications and variations.

[0039] 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 stop such data collection at any time.

[0040] While some of the technologies described herein utilize modern vehicles as client devices to receive OTA updates, the technologies can be implemented by any computing device that is networked, communicates with other devices, collects and exchanges data, and performs various functions without requiring human intervention. These devices can range from simple sensors that measure temperature or humidity to more complex devices such as home automation systems, smart appliances, industrial machinery, and modern vehicles.

[0041] Figure 1 shows an exemplary computing ecosystem 100 according to an exemplary embodiment of the present disclosure. The ecosystem 100 may include a vehicle 105, a remote computing platform 110 (for example, a computing system which may also be referred to herein as the computing platform 110), and a user device 115 associated with a user 120. The user 120 may be the driver or passenger 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 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.

[0042] Systems / devices in the computing 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 may enable systems / devices to establish secure communication channels via secure access channels on the 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 scripting access.

[0043] 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 an 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.

[0044] 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.

[0045] 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.

[0046] The user device 115 may include a computing device owned by or otherwise accessible to the user 120. For example, the user device 115 may include a telephone, laptop, tablet, wearable device (e.g., smartwatch, smart glasses, headphones), personal digital assistant, game system, personal desktop device, other handheld device, or other types of mobile or non-mobile user device. For example, as further described herein, the 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, the user device 115 may include one or more output components such as display devices (e.g., display screens), speakers, etc. In one embodiment, the user device 115 may include components such as a touchscreen, configured to perform input and output functions for receiving user input and presenting information for the user 120. The user device 115 may execute one or more instructions for running an instance of a software application and presenting the user interface associated therewith, as further described herein. In one embodiment, launching a software application may initiate a user-network session with the computing platform 110.

[0047] 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.

[0048] 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 otherwise include one or more APIs for communicating data between the third-party computing platform 125 and other systems / devices in the ecosystem 100.

[0049] 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 any combination thereof, and may include any number of wired or wireless links. Communication over network 130 may be achieved via a network interface using, for example, 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 short-range or near-field communication technologies (e.g., Bluetooth® Low Energy Protocol, radio frequency signaling, NFC protocol).

[0050] 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® car or a van. In some embodiments, 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 embodiments, vehicle 105 may be a fully or semi-autonomous vehicle.

[0051] 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, manual, continuously variable), drive shafts, axles, differentials, e-component 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 105's powertrain (e.g., for propulsion) and the vehicle's onboard 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.

[0052] Vehicle 105 may include the interior of the vehicle. The interior of the vehicle may include areas inside the body of the vehicle 105, such as a cabin for the user of the vehicle 105. The interior of the vehicle 105 may include seats for the user, a steering mechanism, an accelerator interface, a braking interface, and so on. The interior of the vehicle 105 may include display devices such as a display screen associated with an infotainment system.

[0053] Vehicle 105 may include the exterior 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 interior of the vehicle, for example by operating door handles on the exterior of the vehicle. Vehicle 105 may include one or more windows, including windshields, door windows, passenger windows, rear windows, sunroofs, etc.

[0054] 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 on-board diagnostic connector (e.g., OBD-II), or a combination of wired or wireless links. The on-board systems may transmit or receive data, messages, signals, etc., between themselves and each other via the communication channel.

[0055] 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, including, for example, the Ethernet protocol, Internet Protocol Suite (TCP / IP), ATM (Asynchronous Transfer Mode) technology, SONET (Synchronous Optical Networking) protocol, or SDH (Synchronous Digital Hierarchy) protocol.

[0056] 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 that may be outside the vehicle computing system 200 may function as an external buffer or repository for storing information. In such an example, the vehicle computing system 200 may retrieve or otherwise receive information from the non-temporary computer-readable medium.

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

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

[0059] Figure 2A illustrates an overview of a vehicle computing system 200 according to an exemplary embodiment of the present disclosure.

[0060] The vehicle 105 may include one or more sensor systems 305. The sensor systems may include, or otherwise communicate with, sensors of the vehicle 105 and modules for processing sensor data 310 associated with sensors configured to acquire sensor data 310. 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 310 may include image data, internal / external temperature data, weather data, data indicating the location of a user / object inside the vehicle 105, weight data, motion / gesture data, audio 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, audio sensors (e.g., microphones), weight sensors (e.g., vehicle seats), temperature sensors, humidity sensors, light detection and ranging (LIDAR) systems, radio detection and 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.

[0061] 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, based on an IP address, by using triangulation and / or proximity to a network access point or other network component (e.g., a cellular tower, a Wi-Fi access point), or by other suitable 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").

[0062] 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 different roads, road sections, buildings, or other items, the location and direction of lanes (e.g., the location and direction of parking lanes, turning lanes, bicycle lanes, or other lanes within a particular road), traffic control data (e.g., the location, timing, or instructions of signs (e.g., stop signs, yield signs), traffic lights (e.g., stop lights), 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 315 may process specific sensor data 310 (e.g., LIDAR data, camera data, etc.) and match it with a map of the surrounding environment to understand the vehicle's position within that environment. The determined position of the vehicle 105 can 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).

[0063] The vehicle 105 may include a communication system 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 system 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 system 325 to receive platform data 330 from the computing platform 110. This may include, for example, over-the-air (OTA) software updates for the operating system of the vehicle computing system 200. Additionally or alternatively, the vehicle computing system 200 may use the communication system 325 to transmit vehicle data 335 to the computing platform 110. The vehicle data 335 may include any data mounted on the vehicle that is acquired, 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 by the vehicle computing system 200 (e.g., acquired, accessed, generated, downloaded, etc.).

[0064] In some implementations, the communication system 325 may enable communication between one or more systems mounted on the vehicle 105.

[0065] In one embodiment, the communication system 325 may be configured to enable the vehicle 105 to communicate with or otherwise receive data from a user device 115 (shown in Figure 1). The communication system 325 may utilize a variety of communication technologies, such as Bluetooth Low Energy Protocol, radio frequency signaling, or other short-range or near-field communication technologies. The communication system 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.

[0066] The vehicle 105 may include one or more human-machine interface systems 340. The human-machine interface system 340 may include a display device as described herein. The display device (e.g., a touchscreen) may be visible to a user of the vehicle 105 (e.g., user 120) located in front of the vehicle 105 (e.g., driver's seat, passenger seat). Additionally or alternatively, a display device (e.g., a rear unit) may be visible to a user located at the rear of the vehicle 105 (e.g., rear passenger seats). The human-machine interface system 340 may present content (e.g., vehicle speed, mileage, fuel level, charging range, navigation / routing information, audio selection, streaming content, internet search results, comfort or climate settings, etc.) based on various data (e.g., sensor data 310, location data 320, platform data 330, vehicle data 335, etc.) via a user interface for display to user 120.

[0067] Vehicle 105 may include a plurality of vehicle functions 350A, 350B, and 350C. Vehicle functions 350A, 350B, and 350C may be functions configured to be performed by vehicle 105 based on detected inputs. Vehicle functions 350A, 350B, and 350C 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 one or more of the vehicle functions 350A, 350B, and 350C through user input specifying the settings of one or more of the vehicle functions 350A, 350B, and 350C selected by the user.

[0068] Each vehicle function may be associated with one or more of the controllers 355A, 355B, and 355C. Controllers 355A, 355B, and 355C for a particular vehicle function may include control circuits configured to operate that associated vehicle function. For example, a controller may include circuits configured to turn on a seat heating function, turn off a seat heating function, set a specific temperature or temperature level, etc.

[0069] In one embodiment, a controller for a particular vehicle function may include, or be otherwise associated with, a sensor that captures data indicating whether the vehicle function is on or off, the settings of the vehicle function, etc. For example, the sensor may be an audio sensor or a motion sensor. The audio sensor may be a microphone configured to capture audio input from user 120. For example, user 120 may provide a voice command to activate the radio function of vehicle 105 and request a specific station. The motion sensor may be a vision 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.

[0070] Controllers 355A, 355B, and 355C may be configured to transmit signals to other onboard 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 for presentation via the display device 345 (e.g., showing the current settings). Additionally or alternatively, such data may be transmitted to the computing platform 110.

[0071] Figure 2B shows an overview of a computing platform 110 located remotely from a vehicle, according to an exemplary 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 otherwise access, one or more databases. In one example, the computing platform 110 may be implemented using different servers based on geographical area.

[0072] 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.

[0073] The computing platform 110 may be a modular connectivity 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. The services may be represented or implemented as systems within the computing platform 110.

[0074] In one example, the computing platform 110 may include a vehicle software system 405 configured to provide one or more OTA software updates 410 to a vehicle 105. The vehicle software system 405 may maintain data structures (e.g., lists, tables) that indicate the current software or its version downloaded to a particular vehicle. The vehicle software system 405 may also maintain data structures that indicate software packages or versions downloaded by a particular vehicle. In some implementations, the vehicle software system 405 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 OTA updates) for a particular vehicle.

[0075] When vehicle 105 is connected to computing platform 110 and available for software updates, vehicle 105 can, for example, request a software update from computing platform. Computing platform 110 can provide vehicle 105 with one or more software updates 410 as wireless software updates via network 130.

[0076] 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., for collisions, punctures), etc. The remote assistance system 415 may acquire assistance data 420 to provide its core functionality. The assistance data 420 may include information that can 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.

[0077] 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, remote control commands to move the vehicle, and connections to emergency providers.

[0078] 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 to identify digital keys, data encryption, data decryption, etc., for accessing services / systems of the computing platform 110. 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.

[0079] 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.

[0080] 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.).

[0081] The computing platform 110 may include a user system 455. The user system 455 may create, store, manage, or access user profile data 460. The user profile data 460 may include multiple user profiles, each associated with a respective user 120. The user profiles may represent various information about each user 120, including user preferences (e.g., music, comfort settings), frequently visited / past destinations, past routes, etc. The user profiles may be stored in a secure database. In some implementations, when user 120 enters vehicle 105, the user's key (or user device) may provide vehicle 105 with a signal having a user or key identifier. 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 user 120's user profile based on the identifier and transmit the user profile data 460 to vehicle computing system 200 in vehicle 105. The vehicle computing system 200 may use user profile data 460 to implement user 120 preferences, current and past destination locations, and preferences for the frequency or timing of OTA vehicle software updates. The user profile data 460 may be updated based on information periodically provided by the vehicle 105. In some implementations, the user profile data 460 may be provided to the user device 115.

[0082] The technology of this disclosure enables a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) to perform an OTA update (e.g., an OTA vehicle software update) for a vehicle computing system 200, in conjunction with processing a response operation. More specifically, the computing system (e.g., computing platform 110, third-party computing platform 125, etc.) may be configured to implement a predefined task state machine to process tasks associated with the OTA workflow. For example, the task state machine can be implemented using various tools and frameworks, including a state machine library, a workflow engine, etc. In response to a task state transition (e.g., transitioning from a first task state to a second task state among multiple task states), the computing system (e.g., computing platform 110, third-party computing platform 125, etc.) may be configured to select a response operation from a plurality of response operations, the response operation including a computing operation performed in response to the task state transition. Furthermore, computing systems (e.g., computing platform 110, third-party computing platform 125, etc.) may be configured to process reaction actions independently of the vehicle 105 (vehicle computing system 200) performing the task.

[0083] A task can be a fundamental element for an OTA update. A task may be, for example, an instance of an OTA-related action that applies to a given vehicle, and rules may be defined in relation to a group or class of vehicles. For example, if a rule is defined as "Vehicles belonging to set X must perform action A" and A is the action "upgrade from 2.1 to 2.2", then the task may be defined as "Vehicle C must be upgraded from 2.1 to 2.2", and C belongs to set X.

[0084] A task may have a lifecycle that follows a predefined task state machine. For example, a task may be considered “staged” when a computing system prepares an action to be sent to a vehicle. When the task is sent to the vehicle, the task state may change from “staged” to “pending.” When the vehicle reports the success or failure of the task's execution, the task state may transition to “success” or “failure,” respectively. The task state machine may include multiple states, transitions, and actions that define the behavior of a task. Each state may represent a stage in the task's lifecycle and may include labels other than those described above, such as “created,” “in progress,” “completed,” or “cancelled.” Transitions can define conditions and triggers that move a task from one state to another, such as the completion of the task or the occurrence of an event. Response actions, as described herein, may include actions performed or processed in response to a transition, such as sending a notification, updating a record, or calling an external service.

[0085] Figure 3 shows an exemplary task status machine 3000 that indicates an exemplary state of a task according to an exemplary embodiment of the present disclosure. At the start 3050 of the task status machine 3000, a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) determines whether task staging was successful or failed.

[0086] For example, task staging may include preparing and setting up the environment for an OTA software update task, indicating that the task is ready to be sent (e.g., to vehicle 105). Task staging may include performing various checks, validations, and configurations before executing the update. For example, task staging may include a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) determining or verifying that the vehicle computing system 200 is ready to receive or capable of receiving the update (e.g., by verifying available storage space, battery level, network connectivity, etc.). For example, task staging may include a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) downloading or receiving an update package containing new / updated firmware or software from a remote server or source. This may include the computing system (e.g., computing platform 110, third-party computing platform 125, etc.) establishing a secure connection, verifying the integrity of the update package, and ensuring sufficient network bandwidth for the download. For example, task staging may include a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) verifying the downloaded update package to ensure its authenticity and completeness (e.g., by checking for digital signatures, hash values, or other checksum mechanisms). For example, if the update package is compressed or archived, task staging may include a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) decompressing and extracting the firmware or software files.For example, task staging may include a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) performing compatibility checks to ensure that the update package is applicable to the vehicle computing system 200 (by checking, for example, hardware and software version requirements, system dependencies, and other compatibility factors).

[0087] If task staging fails, the task status machine 3000 may transition to the “staging failed” state 3100, and the computing system (e.g., computing platform 110, third-party computing platform 125, etc.) may need to take various corrective actions (e.g., download the update package again, obtain a different version of the update package, etc.) to ensure that the task is ready to be submitted.

[0088] When task staging is successful, the task state machine 3000 may transition to a “staged” state 3150, and the computing system (e.g., computing platform 110, third-party computing platform 125, etc.) may continue processing the task via the task state machine 3000 by then proceeding to a “pending” state 3200.

[0089] For example, the “pending” state 3200 may refer to the state of a task that has been staged and is awaiting further action or confirmation before it can proceed to the next stage. The “pending” state 3200 may indicate that a task has been sent to the vehicle 105 (e.g., the vehicle computing system 200), but the task execution has not been completed, or that a report has not been received indicating whether the task execution was completed successfully or failed. The “pending” state 3200 may also indicate that a task is ready to be executed, but requires additional authorization or verification. For example, a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) may need to receive additional authorization or confirmation from an authorized entity before proceeding with the actual update (e.g., sending it). Authorization may include receiving user input (e.g., user consent or action), administrative approval, or verification from a central server. User input may include authorization for the vehicle computing system 200 to receive the update package, input indicating an appropriate time for installation, etc.

[0090] The "pending" state 3200 may also include a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) waiting for an appropriate amount of time to execute (or send) a task. For example, in the "pending" state 3200, the computing system (e.g., computing platform 110, third-party computing platform 125, etc.) may avoid conflicts with other tasks (e.g., updates) being performed with respect to the vehicle computing system 200, or it may wait for other tasks (e.g., updates) that may need to be performed (e.g., as prerequisites) before the update package can be installed to be completed. For example, if a given vehicle does not have the ability to process multiple updates simultaneously, the task state machine 3000 may remain in the "pending" state 3200 to ensure that the instruction is not sent for simultaneous updates. For example, in the "pending" state 3200, the computing system (e.g., computing platform 110, third-party computing platform 125, etc.) may perform additional checks to ensure that the update package can be installed by re-verifying network connectivity, the readiness of the vehicle computing system 200, or any specific requirements for the update process.

[0091] Once the necessary permissions, user interactions, or external dependencies are resolved, the task state machine can transition from the "pending" state 3200 to the "success" state 3250 if the task (e.g., update package) has been successfully executed (e.g., installed), or to the "failed" state 3300 if the task (e.g., update package) has not been successfully executed (e.g., not installed). For example, a vehicle 105 (e.g., a vehicle computing system 200) may be configured to report to a computing system (e.g., a computing platform 110, a third-party computing platform 125, etc.) that the task has been successfully executed and the task state has moved to the "success" state 3250, or that the task has been unsuccessfully executed and the task state has moved to the "failed" state 3300. For example, when a task transitions to the "success" state 3250, a computing system (e.g., a computing platform 110, a third-party computing platform 125, etc.) may be configured to update a separate computing system responsible for tracking which software versions are present in each vehicle.

[0092] Figure 4 shows an exemplary schematic diagram of an exemplary embodiment of the present disclosure for processing a reaction operation while processing a task.

[0093] In Figure 4, the reaction processing overview 4000 shows the flow of operation including the task state processor 4100, the task state change trigger processor 4300, and the reaction processor 4500. Each of the task state processor 4100, the task state change trigger processor 4300, and the reaction processor 4500 may represent or correspond to a software component or module of an application or program of a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) that processes operations related to a task. For example, the task state processor 4100 may include a component or module configured to process or manage state changes of a task processed by a computing system (e.g., computing platform 110, third-party computing platform 125, etc.). The task state processor 4100 may be configured to receive notifications or events when the state of a task changes, such as when a task is staged, when a task is pending, or when a task is successfully or unsuccessfully completed. The task state processor 4100 may be configured to update the task state, perform any necessary actions or validations based on the state change, and trigger subsequent processes or components in response to the task state change.

[0094] For example, the task state change notification queue 4200 may receive information indicating a change in the task state from the task state processor 4100. The task state change notification queue 4200 may include a message queue or a queue-like data structure used to store and manage notifications or events related to task state changes. When the task state changes, a notification or event may be generated (for example, by the task state processor 4100), and the notification or event may be stored in the task state change notification queue 4200. The task state processor 4100 or the task state change trigger processor 4300 may be configured to process notifications from the task state change notification queue 4200 and to process and address the task state change.

[0095] For example, the task state change trigger processor 4300 may include components or modules configured to trigger actions or processes in response to changes in the state of a task. The task state change trigger processor 4300 may be configured to listen for task stage change events or notifications that indicate the completion of a particular stage or step within a task. For example, in 4350, in response to the reception of a task stage change event, the task state change trigger processor 4300 may be configured to determine whether the task has one or more response actions associated with it, determine or retrieve the type of each response action, select one or more response actions, determine the context and parameter information associated with each response action, and form a response context for each response action.

[0096] The reaction queue 4400 may be configured to store information about reaction actions. For example, the reaction queue 4400 may include a message queue or data structure configured to store and manage reaction actions or responses to specific events or triggers within a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) in response to changes in the state of a task. The storage of reaction actions (or information about reaction actions) in the reaction queue 4400 enables the isolation of tasks from reaction actions, including enabling asynchronous processing of tasks and reaction actions. For example, when an event or trigger occurs, such as a change in the state of a task, a corresponding reaction action may be determined and stored in the reaction queue 4400 for further processing. For example, as shown by 4450, information including reaction type, reaction parameters, and reaction context may be stored together with or separately from the corresponding reaction action in the reaction queue 4400.

[0097] The reaction processor 4500 may include components or modules configured to process reaction actions from the reaction queue 4400. For example, the reaction processor 4500 may be configured to listen for (receive) reaction actions stored in the reaction queue 4400, dequeue reaction actions from the reaction queue 4400, and perform various actions or operations associated with each reaction action. The reaction processor 4500 may be configured to handle and process reaction actions in an asynchronous manner isolated with respect to tasks.

[0098] The behavioral flow described with respect to the reaction processing overview 4000 in Figure 4 normalizes heterogeneous types of reaction behaviors (including notifications, vehicle property updates, and virtually any other software-driven side effects) within a single framework. This offers the advantage of separating task state changes from reaction types, allowing computing systems (e.g., computing platform 110, third-party computing platform 125, etc.) to mix and match a set of clearly defined task state transitions and potentially open-ended reaction behaviors while ensuring a stable OTA workflow without requiring numerous versions of the task state machine. To further minimize the impact on the OTA workflow and the task state machine, information about any reaction behavior being performed is not persisted with the task itself, but instead is retrieved from the rule action definition when processing notifications that a task state change has occurred. For example, information about a reaction behavior can be retrieved when the first task state transitions to the second task state. Further details regarding the behavioral flow described with respect to the reaction processing overview 4000 in Figure 4 are described with respect to Figures 5A-5C.

[0099] Figure 5A shows an exemplary schematic diagram of handling task state change behavior while a task is being processed, according to an exemplary embodiment of the present disclosure. Figure 5B shows an exemplary schematic diagram of response queue processing behavior while a task is being processed, according to an exemplary embodiment of the present disclosure. Figure 5C shows an exemplary schematic diagram of notification response handler behavior while a task is being processed, according to an exemplary embodiment of the present disclosure.

[0100] Each of the components shown in Figures 4 and 5A to 5C (for example, the task state processor 4100, the task state change notification queue 4200, the task state change trigger processor 4300, the response queue 4400, the response processor 4500, the task state change topic 5110, the task state change trigger 5120, the rule definition cache 5130, the management service 5140, the response queue 5150, the response queue 5210, the response processor 5220, the response handler registry 5230, the response handler 5240, the response processor 5310, and the notification response handler 5320) may be included in a computing system (for example, the computing platform 110, the third-party computing platform 125, etc.) as, for example, a software component of a program or application, or as a database or storage device (for example, the task state change notification queue 4200, the response queue 4400, the rule definition cache 5130, the response queue 5150, the response queue 5210, and the response handler registry 5230). The operation and functions of these components described herein may be performed by one or more control circuits described herein (e.g., control circuit 715, control circuit 1015, control circuit 1115, etc.) and via computer-readable code or instructions that can be stored in one or more storage devices described herein (e.g., non-temporary computer-readable medium 720, non-temporary computer-readable medium 1020, non-temporary computer-readable medium 1120, etc.).

[0101] In Figure 5A, the exemplary task state change summary 5100 indicates that a message is sent to the response queue 5150 in response to a task stage change notification from the task state change topic 5110. More specifically, in response to a change in the task state (for example, from "staged" to "pending"), the task state change topic 5110 may send a task state change notification message 5112 to the task state change trigger 5120 (for example, corresponding to the task state change trigger processor 4300 in Figure 4). In response to receiving the task state change notification message 5112, in operation 5122, the task state change trigger 5120 may be configured to retrieve a rule definition from the rule definition cache 5130.

[0102] The rule definition cache 5130 may be a component configured to store and manage rules or conditions associated with task state changes. For example, a rule definition may be retrieved directly from the rule definition cache 5130 based on an identifier associated with the rule definition. Box 5132 shows alternative behavior when a rule definition is not present in the rule definition cache 5130. For example, in 5133, the rule definition cache 5130 may be configured to retrieve or request a rule definition from the management service 5140. In 5142, the management service 5140 may be configured to send a rule definition to the rule definition cache 5130, and in 5134, the rule definition cache 5130 may be configured to cache the rule definition according to an identifier associated with the rule definition. Then, in 5135, the rule definition cache 5130 may be configured to send a rule definition to the task state change trigger 5120.

[0103] Box 5136 shows the actions that occur in response to the task state change trigger 5120 receiving a rule definition. For example, a rule definition may include response actions associated with actions from the rule definition; that is, response actions are associated with actions in a rule. The task state change trigger 5120 may be configured to determine whether each action from the rule definition is associated with (includes) one or more response actions. In action 5137, the task state change trigger 5120 may be configured to construct a response context associated with the response actions based on the rule definition, and in action 5138, to send (push) a response message to the response queue 5150 (corresponding to the response queue 4400 in Figure 4). The response message may include information about the type of response action, related data, and any other additional contextual information necessary to process the response action.

[0104] By pushing reaction messages to the reaction queue 5150, computing systems (e.g., computing platform 110, third-party computing platform 125, etc.) can separate reaction processing from the rule evaluation process associated with the task. By using the queue, computing systems (e.g., computing platform 110, third-party computing platform 125, etc.) can handle reaction operations asynchronously and in a more scalable manner. For example, the reaction processor 4500 in Figure 4 may be configured to listen to the reaction queue 5150 independently of the task being executed and to process reaction operations at the appropriate time. As shown in Figure 5A, in operation 5152, the reaction queue 5150 may be configured to send a reaction message to a task state change trigger 5120, and the reaction message may be sent to a task state change topic 5110 in operation 5139.

[0105] In Figure 5B, an exemplary reaction queue processing overview 5200 shows that, in response to a reaction message being generated and stored in the reaction queue 5210, it can determine the appropriate reaction handler 5240 for processing the reaction operation. For example, a reaction message is processed by the reaction processor 5220 from the reaction queue 5210 by inspecting the reaction message and determining the appropriate reaction handler 5240 for this type of message. The context and parameters of the reaction operation are dispatched to this particular reaction handler 5240 by the reaction processor 5220. More specifically, in operation 5212, the reaction processor 5220 (corresponding to the reaction processor 4500 in Figure 4) may be configured to listen for (receive) reaction messages from the reaction queue 5210 (corresponding to the reaction queue 4400 in Figure 4).

[0106] In operation 5222, the reaction processor 5220 may be configured to deserialize a reaction message or a reaction operation contained within a reaction message. For example, deserializing a reaction message or reaction operation may include converting the received reaction message or reaction operation from its serialized form to a structured or usable format. For example, deserialization may include extracting relevant data and reconstructing a reaction object from the serialized reaction message or reaction operation.

[0107] In response to a response message or response operation being deserialized, the response processor 5220 may be configured in operation 5224 to fetch an appropriate handler for the response operation from the response handler registry 5230. The response handler registry 5230 may include components (e.g., a database or other storage device) that store or track available response handlers within a computing system (e.g., computing platform 110, third-party computing platform 125, etc.). The response handler registry 5230 may include a centralized repository or database for storing information about registered response handlers. The response handler registry 5230 may be configured to maintain metadata associated with each response handler, such as its name, description, and input and output requirements. In operation 5232, the response handler registry 5230 may be configured to send information about available response handlers to the response processor 5220.

[0108] In operation 5226, the reaction processor 5220 may be configured to send a reaction message and its associated context and / or parameters (e.g., reaction action information) to the reaction handler 5240. The context may include relevant information or data necessary for processing the reaction action (e.g., input values, context details, or configuration settings required by the reaction handler 5240 to perform the requested reaction action). In operation 5242, the reaction handler 5240 may be acknowledged to confirm receipt, and in operation 5228, the reaction processor 5220 may be configured to send a completion message to the reaction queue 5210.

[0109] In Figure 5C, the exemplary notification response handler overview 5300 illustrates a type of response handler that sends notifications to an external system. For example, in response to receiving context and parameter information about a response operation from the response processor 5310, the notification response handler 5320 may be configured to send (push) a notification message to an outbound notification topic 5330 (an external computing system).

[0110] More specifically, in operation 5312, the reaction processor 5310 (corresponding to the reaction processor 4500 in Figure 4 and the reaction processor 5220 in Figure 5B) may be configured to send a reaction message and its associated context and / or parameters (e.g., reaction operation information) to a notification reaction handler 5320, where the notification reaction handler 5320 may correspond to a reaction handler deemed appropriate by the reaction handler registry 5230 in Figure 5B. In operation 5322, the notification reaction handler 5320 may be configured to construct a notification message and, in operation 5324, to send (push) the notification message to an outbound notification topic 5330 (an external computing system). In operation 5332, the outbound notification topic 5330 may be configured to acknowledge receipt of the notification message, and in operation 5326, the notification reaction handler 5320 may be configured to acknowledging in the reaction processor 5310 that the outbound notification topic 5330 has received the notification message.

[0111] Figure 6 shows a flowchart of an exemplary method 6000 for handling tasks and response operations related to over-the-air (OTA) vehicle software updates, according to exemplary embodiments of the present disclosure. Method 6000 may be performed by a computing system (e.g., a remote computing platform 110, a third-party computing platform 125, a user device 115, etc.) as described with reference to other drawings. In one embodiment, one or more operations of Method 6000 may be performed by a control circuit of the remote computing platform 110, the third-party computing platform 125, or the user device 115 as shown in Figures 1 to 5C and / or Figure 7. One or more parts of Method 6000 may be implemented as algorithms on hardware components of the devices described herein (e.g., as shown in Figures 1 to 5C and / or Figure 7, etc.). For example, steps of Method 6000 may be implemented as operations / instructions that can be executed by computing hardware.

[0112] Figure 6 illustrates, for illustrative and explanatory purposes, the elements to be 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, extended, omitted, combined, or modified in various ways without departing from the scope of this disclosure. Figure 6 is illustrated, and is not intended to be limited, for illustrative purposes, by reference to other systems and elements / terms described in relation to the figure. One or more parts of Method 6000 may be performed by other systems, additionally or alternatively. For example, some aspects of Method 6000 may be performed by the control circuits of computing platform 110, while other aspects of Method 6000 may be performed by third-party computing platform 125.

[0113] In one embodiment, method 6000 may begin with operation 6100, or otherwise include, an operation that enables a computing system (e.g., a remote computing platform 110, a third-party computing platform 125, a user device 115, etc.) to obtain over-the-air (OTA) vehicle software updates for multiple vehicles. For example, the multiple vehicles may belong to the same class of vehicles. For example, the OTA vehicle software updates may be received by the remote computing platform 110 from the third-party computing platform 125.

[0114] Method 6000 in one embodiment may include an operation 6200 that allows a computing system (e.g., a remote computing platform 110, a third-party computing platform 125, a user device 115, etc.) to determine a task for a first vehicle among several vehicles based on an OTA vehicle software update. For example, a task may be associated with multiple task states. As described herein, a task may correspond to an instance of an OTA-related action applicable to a given vehicle, and the rule may be defined in relation to a group or class of vehicles. For example, an action may include upgrading a software version (e.g., to upgrade the software version installed on a vehicle). As another example, if the rule is defined as "Vehicles in set X must perform action A" and A is the action "Upgrade software version from 2.1 to 2.2", then the task is defined as "Vehicle C must upgrade software version from 2.1 to 2.2", where C is in set X. As yet another example, a task may correspond to or include a connection action of a first vehicle connecting to one or more computing systems over a network, and a connection action may be defined by associating a response action with the connection action. For example, as mentioned above, a task may have a lifecycle that follows a predefined task state machine. The task state machine may include multiple states, transitions, and actions that define the behavior of the task. Each state may represent a stage in the task's lifecycle and may include states such as "staged," "staged failed," "pending," "successful," or "failed," or other labels such as "created," "in progress," "completed," or "cancelled."

[0115] Method 6000 in one embodiment may include an operation 6300 that allows a computing system (e.g., remote computing platform 110, third-party computing platform 125, user device 115, etc.) to determine that a task has experienced a task state transition from a first task state to a second task state among a plurality of task states while processing a task with respect to a first vehicle. For example, as described with reference to Figures 4 and 5A, the task state processor 4100 may include a component or module configured to process or manage state changes of tasks processed by the computing system (e.g., computing platform 110, third-party computing platform 125, etc.). For example, a task state change notification queue 4200 may receive information from the task state processor 4100 indicating a task state change (e.g., from "pending" to "successful," or from "staged" to "pending").

[0116] In one embodiment, method 6000 may include an operation 6400 in which a computing system (e.g., a remote computing platform 110, a third-party computing platform 125, a user device 115, etc.) can select a response operation from a plurality of response operations in response to a task state transition, the response operation including a computing operation performed in response to a task state transition.

[0117] For example, as illustrated with reference to Figures 4 and 5A, the task state change trigger processor 4300 and the task state change trigger 5120 may be configured to determine whether a task has one or more response actions associated with the task (or more specifically, with rule-defined actions), determine or retrieve the type of each response action, select one or more response actions, determine the context and parameter information associated with each response action, and form the response context for each response action. For example, the task state change trigger processor 4300 and the task state change trigger 5120 may be configured to retrieve information about response actions when a first task state transitions to a second task state (for example, when processing a notification that a task state change has occurred). For example, the task state change trigger processor 4300 and the task state change trigger 5120 may be configured to select a response action from a plurality of response actions by identifying the response action based on the action associated with the task (for example, as illustrated with reference to actions 5135-5138 in Figure 5A).

[0118] As described herein, a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) may be configured to determine actions to be performed on a class of vehicle and to associate response actions with those actions. Generally, when a task changes a state to a state S (where S can be any task state), a response action R may be performed, and R may be selected from a plurality of available responses.

[0119] For example, a response action may include at least one of the following: (a) sending a notification regarding the status of an OTA vehicle software update to a first vehicle and / or a user associated with the first vehicle; (b) sending information about the OTA vehicle software update to an external computing system that tracks status information of OTA vehicle software updates associated with multiple vehicles; (c) changing a property associated with the first vehicle in the external computing system; or (d) waking up a network device (e.g., a gateway) associated with the first vehicle (e.g., associated with a vehicle identification number).

[0120] In one embodiment, method 6000 may include operation 6500, in which a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) may be configured to process the reaction operation independently of the first vehicle performing the task. For example, the reaction operation may be logically and temporally separated from the task state transition from a first task state to a second task state.

[0121] As described herein, the computing system (e.g., computing platform 110, third-party computing platform 125, etc.) is configured to handle reaction actions in a manner that does not interfere with (and is isolated from) the main OTA workflow as defined by the task state machine. In other words, reaction actions respond to side effects of task state transitions without interfering with the task workflow performed to successfully complete the OTA software update. Since reaction actions are merely side effects of the general OTA workflow and are isolated from the general OTA workflow, the general OTA workflow remains efficient and stable. For example, reaction actions may be logically and temporally isolated from the underlying task state transitions by an indirect queuing mechanism for reaction processing triggered by task state changes. For example, the reaction queue 4400 may include a message queue or data structure configured to store and manage reaction actions. For example, queuing reaction actions allows for the isolation of tasks from reaction actions and also allows for asynchronous processing of tasks by the vehicle with respect to the processing of reaction actions.

[0122] The processing of a reaction action may further include a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) determining an appropriate reaction handler to handle the reaction action, as described with reference to Figures 5B and 5C, and the reaction handler performing the reaction action (e.g., by sending a notification message to an external computing system).

[0123] In exemplary embodiments, response actions may be processed by a computing system (e.g., computing platform 110, third-party computing platform 125, etc.) in conjunction with connection actions, and connection actions are defined by one or more associated responses. For example, an instance of a vehicle connection action (connection task) may proceed via a task state machine, as with any other type of task. For example, during a connection task, the task state changes immediately from pending to successful when the vehicle connects to a backend system (e.g., a remote computing platform), without the vehicle having to do anything other than check in. For example, response actions may be processed in response to a change in the task state. Thus, connection actions may be used to design or to include a workflow that includes response actions (e.g., side effects).

[0124] Figure 7 shows a block diagram of an exemplary computing system 700 according to one embodiment of the present invention. The computing system 700 includes a computing system 705 (e.g., a vehicle-mounted computing system including a vehicle computing system 200), a server computing system 1005 (e.g., a remote computing system, a cloud computing platform, a remote computing platform 110, a third-party computing platform 125, etc.), and a user device 805 (e.g., corresponding to a user device 115), all of which are communicably coupled via one or more networks 750.

[0125] The computing system 705 may include one or more computing devices 710 or circuits. For example, the computing system 705 may include a control circuit 715 and a non-temporary computer-readable medium 720, also referred to herein as memory. In one embodiment, the control circuit 715 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 715 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 715 may be programmed by one or more computer-readable or computer-executable instructions stored in a non-temporary computer-readable medium 720.

[0126] In one embodiment, the non-temporary computer-readable medium 720 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 720 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.

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

[0128] The non-temporary computer-readable medium 720 may also store computer-readable instructions 730 that can be executed by the control circuit 715. Instructions 730 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 715 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 715 or other hardware components execute the module or computer-readable instructions.

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

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

[0131] The computing system 705 may also include one or more user input components 740 that receive user input. For example, a user input component 740 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.

[0132] The computing system 705 may include one or more output components 745. The output components 745 may include hardware and / or software for generating content audibly or visually. For example, the output components 745 may include one or more speakers, earphones, headsets, handsets, etc. The output components 745 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 745 may include a display screen, CRT, LCD, plasma screen, touchscreen, TV, projector, tablet, and / or other suitable display components.

[0133] The server computing system 1005 may include one or more computing devices 1010. In one embodiment, the server computing system 1005 may include one or more server computing devices, or be otherwise implemented therein. In cases where the server computing system 1005 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.

[0134] The server computing system 1005 may include a control circuit 1015 and a non-temporary computer-readable medium 1020, also referred to herein as memory 1020. In one embodiment, the control circuit 1015 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 1015 may be programmed by one or more computer-readable or computer-executable instructions stored in the non-temporary computer-readable medium 1020.

[0135] In one embodiment, the non-temporary computer-readable medium 1020 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), digital multipurpose disc (DVD), and / or memory stick.

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

[0137] The non-temporary computer-readable medium 1020 may also store computer-readable instructions 1030 that can be executed by the control circuit 1015. Instructions 1030 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 1015 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 1015 or other hardware components are executing the module or computer-readable instructions.

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

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

[0140] The computing system 705 and / or the server computing system 1005 may also communicate with user devices 1105 that are commutably coupled via one or more networks 750.

[0141] The user device 1105 may include one or more computing devices 1110. The user device 1105 may include a control circuit 1115 and a non-temporary computer-readable medium 1120, also referred to herein as memory 1120. In one embodiment, the control circuit 1115 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 1115 may be programmed by one or more computer-readable or computer-executable instructions stored in the non-temporary computer-readable medium 1120.

[0142] In one embodiment, the non-temporary computer-readable medium 1120 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), digital multipurpose disc (DVD), and / or memory stick.

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

[0144] The non-temporary computer-readable medium 1120 may also store computer-readable instructions 1130 that can be executed by the control circuit 1115. Instructions 1130 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 1115 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 1115 or other hardware components execute the module or computer-readable instructions.

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

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

[0147] The user device 1105 may also include one or more user input components 1140 that receive user input. For example, a user input component 1140 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 may include a microphone, a conventional keyboard, a cursor device, a joystick, or other devices to which the user may provide user input.

[0148] The user device 1105 may include one or more output components 1145. The output components 1145 may include hardware and / or software for generating content audibly or visually. For example, the output components 1145 may include one or more speakers, earphones, headsets, handsets, etc. The output components 1145 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 1145 may include a display screen, CRT, LCD, plasma screen, touchscreen, TV, projector, tablet, and / or other suitable display components.

[0149] One or more networks 750 can 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 one or more networks 750 can 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 methods (e.g., VPN, Secure HTTP, SSL). Further consideration of various embodiments

[0150] Embodiment 1 relates to a computer implementation method related to over-the-air (OTA) vehicle software updates. The computer implementation method may include: obtaining OTA vehicle software updates for a plurality of vehicles; determining a task for a first vehicle among the plurality of vehicles based on the OTA vehicle software updates, wherein the task is associated with a plurality of task states; determining, while processing the task with respect to the first vehicle, that the task has experienced a task state transition from a first task state among the plurality of task states to a second task state among the plurality of task states; selecting a response action from a plurality of response actions in response to the task state transition, wherein the response action includes a computing action performed in response to the task state transition; and processing the response action independently of the first vehicle executing the task.

[0151] Embodiment 2 includes the method described in Embodiment 1. In this embodiment, the reaction operation is logically and temporally separated from the task state transition from the first task state to the second task state.

[0152] Embodiment 3 includes the method described in Embodiment 1. In this embodiment, selecting a reaction action from a plurality of reaction actions includes identifying a reaction action based on an action associated with a task.

[0153] Embodiment 4 includes the method described in Embodiment 3. In this embodiment, the action includes upgrading the software version installed in the first vehicle.

[0154] Embodiment 5 includes the method of any one of Embodiments 1 to 4. In this embodiment, the method further includes retrieving information about the response behavior when a first task state transitions to a second task state.

[0155] Embodiment 6 includes the method of any one of Embodiments 1 to 5. In this embodiment, the method may include queuing the reaction actions so that the reaction actions are processed asynchronously with respect to the first vehicle performing the task.

[0156] Embodiment 7 includes the method of any one of Embodiments 1 to 6. In this embodiment, a plurality of vehicles belong to the same class of vehicles, and the computer implementation method further includes determining the actions to be performed by the class of vehicles and associating the response actions with the actions.

[0157] Embodiment 8 includes the method of any one of Embodiments 1 to 7. In this embodiment, the response action includes at least one of the following: (a) sending a notification regarding the status of an OTA vehicle software update to a first vehicle and / or a user associated with the first vehicle; (b) sending information about the OTA vehicle software update to an external computing system that tracks status information of OTA vehicle software updates associated with a plurality of vehicles; (c) changing a property associated with the first vehicle in the external computing system; or (d) waking up a network device associated with the first vehicle.

[0158] Embodiment 9 includes the method of any one of Embodiments 1 to 8. In this embodiment, a task corresponds to a connection action of a first vehicle connecting to one or more computing systems via a network, and a connection action is defined by associating a response action with the connection action.

[0159] Embodiment 10 relates to a computing system. The computing system may include a control circuit. The control circuit may obtain over-the-air (OTA) vehicle software updates for multiple vehicles, determine a task for a first vehicle among the multiple vehicles based on the OTA vehicle software updates, the task is associated with multiple task states, and while processing the task with respect to the first vehicle, it determines that the task has experienced a task state transition from a first task state among the multiple task states to a second task state among the multiple task states, select a response action from multiple response actions in response to the task state transition, the response action may include a computing action performed in response to the task state transition, and the response action may be processed independently of the vehicle performing the task.

[0160] Embodiment 11 includes the computing system of Embodiment 10. In this embodiment, the response operation is logically and temporally separated from the task state transition from a first task state to a second task state.

[0161] Embodiment 12 includes a computing system according to either Embodiment 10 or 11. In this embodiment, the control circuit is configured to retrieve information regarding the response behavior when the first task state transitions to the second task state.

[0162] Embodiment 13 includes the computing system of Embodiment 12. In this embodiment, the control circuit is configured to queue reaction actions so that the reaction actions are processed asynchronously with respect to the first vehicle performing the task.

[0163] Embodiment 14 includes a computing system as described in any of Embodiments 10 to 13. In this embodiment, multiple vehicles belong to the same class of vehicles, and a control circuit is configured to determine the actions performed by the class of vehicles and to associate the response behavior with the actions.

[0164] Embodiment 15 includes a computing system as described in any of Embodiments 10 to 14. In this embodiment, the response actions processed by the control circuit include at least one of the following: (a) sending a notification regarding the status of an OTA vehicle software update to a first vehicle and / or a user associated with the first vehicle; (b) sending information about the OTA vehicle software update to an external computing system that tracks status information of OTA vehicle software updates associated with a plurality of vehicles; (c) changing a property associated with the first vehicle in the external computing system; or (d) waking up a network device associated with the first vehicle.

[0165] Embodiment 16 includes a computing system as described in any of Embodiments 10 to 15. In this embodiment, a task corresponds to a connection action of a first vehicle connecting to one or more computing systems via a network, and a connection action is defined by associating a response action with the connection action.

[0166] Embodiment 17 relates to one or more non-temporary computer-readable media that store instructions executable by a control circuit to perform an operation. The control circuit obtains over-the-air (OTA) vehicle software updates for a plurality of vehicles, determines a task for a first vehicle among the plurality of vehicles based on the OTA vehicle software updates, the task is associated with a plurality of task states, and while processing the task with respect to the first vehicle, determines that the task has experienced a task state transition from a first task state among the plurality of task states to a second task state among the plurality of task states, selects a response action from a plurality of response actions to be processed in response to the task state transition, and may process the response action independently of the first vehicle performing the task.

[0167] Embodiment 18 includes the computing system of Embodiment 17. In this embodiment, the response operation is logically and temporally separated from the task state transition from a first task state to a second task state.

[0168] Embodiment 19 includes a computing system as described in any of Embodiments 17 to 18. In this embodiment, one or more non-temporary computer-readable media store instructions, and instructions are executable by a control circuit to select a response from a plurality of response actions by identifying a response action based on an action associated with a task, retrieve information about the response actions when a first task state transitions to a second task state, and queue the response actions so that they are processed asynchronously with respect to a first vehicle that performs the task.

[0169] Embodiment 20 includes a computing system as described in any of Embodiments 17 to 19. In this embodiment, the response action includes at least one of the following: (a) sending a notification regarding the status of an OTA vehicle software update to a first vehicle and / or a user associated with the first vehicle; (b) sending information about the OTA vehicle software update to an external computing system that tracks status information of OTA vehicle software updates associated with a plurality of vehicles; (c) changing a property associated with the first vehicle in the external computing system; or (d) waking up a network device associated with the first vehicle. Additional disclosures

[0170] 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.

[0171] The technologies discussed herein refer to servers, databases, software applications, and other computer-based systems, as well as the actions performed and the 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 their 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 may be distributed across multiple systems. Distributed components may operate sequentially or in parallel.

[0172] While the disclosed subject matter has been described in detail with respect to various exemplary embodiments thereof, each example is provided for illustrative purposes only and not as an limitation of this disclosure. Those skilled in the art, having achieved the aforementioned understanding, can readily generate modifications, variations, and equivalents of such embodiments. Therefore, this disclosure does not exclude such modifications, variations, and / or additional inclusions to the disclosed 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, this disclosure is intended to cover such modifications, variations, and equivalents.

[0173] The aspects of this disclosure are described in relation to exemplary embodiments. Numerous other implementations, modifications, or variations within the scope and spirit of the appended claims can be recalled by those skilled in the art from the examination of this disclosure. Any and all features in the following claims can be combined or rearranged in any possible way. 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 disclosed subject matter, as will be readily apparent to those skilled in the art. Furthermore, terms are used herein with 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.”

[0174] Those skilled in the art will understand, by using the disclosures provided herein, that any element of the claims, operations, or processes considered herein may be adapted, rearranged, expanded, omitted, combined, or modified in various ways without departing from the scope of this disclosure. Sometimes, elements are enumerated in the specification or claims using letter references for illustrative purposes and are not intended to be limiting. Where used, letter references do not imply a particular order of operations or the importance of any particular element listed. For example, (a), (b), (c), ..., (i), (ii), (iii), ..., etc., may be used to indicate operations 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, operations, or elements. For example, an operation indicated by a list identifier such as (a), (i) may be performed before, after, or concurrently with another operation indicated by a list identifier such as (b), (ii).

Claims

1. A computer implementation method, Obtaining over-the-air (OTA) vehicle software updates for multiple vehicles, The task of a first vehicle among the plurality of vehicles is determined based on the OTA vehicle software update, wherein the task is associated with a plurality of task states. While processing the task with respect to the first vehicle, it is determined that the task has experienced a task state transition from a first task state among the plurality of task states to a second task state among the plurality of task states, In response to the task state transition, a response action is selected from a plurality of response actions, wherein the response action includes a computing action performed in response to the task state transition. The first vehicle processes the reaction operation independently of performing the task, A computer implementation method, including

2. The computer implementation method according to claim 1, wherein the reaction operation is logically and temporally separated from the task state transition from the first task state to the second task state.

3. The computer implementation method according to claim 1, wherein selecting the reaction action from the plurality of reaction actions includes identifying the reaction action based on an action associated with the task.

4. The computer implementation method according to claim 3, wherein the action includes upgrading the software version installed in the first vehicle.

5. The computer implementation method according to claim 1, further comprising retrieving information relating to the reaction operation when the first task state transitions to the second task state.

6. The computer implementation method according to claim 1, further comprising queuing the reaction operation so that the reaction operation is processed asynchronously with the first vehicle that performs the task.

7. The aforementioned multiple vehicles belong to the same class of vehicles, and the computer implementation method is The actions to be performed are determined by the class of the vehicle, The computer implementation method according to claim 1, further comprising associating the reaction operation with the action.

8. The computer implementation method according to claim 1, wherein the response action includes at least one of the following: (a) sending a notification regarding the status of the OTA vehicle software update to the first vehicle and / or a user associated with the first vehicle; (b) sending information regarding the OTA vehicle software update to an external computing system that tracks status information of OTA vehicle software updates associated with a plurality of vehicles; (c) changing a property associated with the first vehicle in the external computing system; or (d) waking up a network device associated with the first vehicle.

9. The task corresponds to a connection action in which the first vehicle connects to one or more computing systems via a network, The computer implementation method according to claim 1, wherein the connection action is defined by associating the reaction operation with the connection action.

10. A computing system, The control circuit is equipped with, Obtain over-the-air (OTA) vehicle software updates for multiple vehicles. Based on the OTA vehicle software update, the task of the first vehicle among the multiple vehicles is determined, and the task is associated with multiple task states. While processing the task with respect to the first vehicle, it is determined that the task has experienced a task state transition from a first task state among the plurality of task states to a second task state among the plurality of task states, In response to the task state transition, a response action is selected from a plurality of response actions, and the response action includes a computing action that is performed in response to the task state transition. A computing system configured to process the reaction operation independently of the vehicle performing the task.

11. The computing system according to claim 10, wherein the reaction operation is logically and temporally separated from the task state transition from the first task state to the second task state.

12. The computing system according to claim 10, wherein the control circuit is configured to retrieve information regarding the reaction operation when the first task state transitions to the second task state.

13. The computing system according to claim 12, wherein the control circuit is configured to queue the reaction operation so that the reaction operation is processed asynchronously with the first vehicle that performs the task.

14. The aforementioned multiple vehicles belong to the same class of vehicles, The aforementioned control circuit is The action to be performed is determined by the class of the aforementioned vehicle, The computing system according to claim 10, configured to associate the reaction operation with the action.

15. The computing system according to claim 10, wherein the response operation processed by the control circuit includes at least one of: (a) sending a notification regarding the status of the OTA vehicle software update to the first vehicle and / or a user associated with the first vehicle; (b) sending information about the OTA vehicle software update to an external computing system that tracks status information of OTA vehicle software updates associated with a plurality of vehicles; (c) changing a property associated with the first vehicle in the external computing system; or (d) waking up a network device associated with the first vehicle.

16. The task corresponds to a connection action in which the first vehicle connects to one or more computing systems via a network, The computing system according to claim 10, wherein the connection action is defined by associating the reaction operation with the connection action.

17. One or more non-temporary computer-readable media containing instructions, wherein the instructions are Obtain over-the-air (OTA) vehicle software updates for multiple vehicles. Based on the OTA vehicle software update, the task of the first vehicle among the multiple vehicles is determined, and the task is associated with multiple task states. While processing the task with respect to the first vehicle, it is determined that the task has experienced a task state transition from a first task state among the plurality of task states to a second task state among the plurality of task states, In response to the aforementioned task state transition, a reaction action is selected from a plurality of reaction actions to be processed. One or more non-temporary computer-readable media, executable by a control circuit to process the reaction operation independently of the first vehicle performing the task.

18. The reaction operation is logically and temporally separated from the task state transition from the first task state to the second task state, one or more non-temporary computer-readable media according to claim 17.

19. The one or more non-temporary computer-readable media according to claim 17, wherein the one or more non-temporary computer-readable media store instructions, the instructions select a response from a plurality of response actions by identifying the response actions based on actions associated with the task, the control circuit is capable of retrieving information about the response actions when the first task state transitions to a second task state, and queuing the response actions so that they are processed asynchronously with the first vehicle performing the task.

20. One or more non-temporary computer-readable media according to claim 17, wherein the response action includes at least one of the following: (a) sending a notification regarding the status of the OTA vehicle software update to the first vehicle and / or a user associated with the first vehicle; (b) sending information about the OTA vehicle software update to an external computing system that tracks status information of OTA vehicle software updates associated with a plurality of vehicles; (c) changing a property associated with the first vehicle in the external computing system; or (d) waking up a network device associated with the first vehicle.

Images