Vehicle workload unload

Abstract

The invention provides a'vehicle workload offload '. A system and method performed on a vehicle includes determining a selected Internet of Things (IoT) device from a plurality of IoT devices separate from the vehicle, wherein the selected IoT device is selected based on tasks capable of performing computations and / or stores including vehicle subsystems; decomposing the task into a plurality of workloads to be offloaded for processing on the respective selected IoT devices; and transmitting the workload to the corresponding selected IoT device.

Description

Technical Field

[0001] The present disclosure relates to offloading a workload from a vehicle. Background Art

[0002] The vehicle may include one or more computing devices and memory for performing various computing and storage operations of the vehicle. Computing devices in the vehicle (e.g., electronic control units (ECUs), etc.) may communicate with each other via one or more vehicle networks, and / or may communicate with computing devices external to the vehicle via one or more networks and / or communication protocols. Summary of the invention

[0003] The vehicle may include computing and / or storage devices for performing various computing tasks and / or storage tasks of the vehicle, but due to the need for additional tasks, it may be necessary to prioritize these computing and / or storage resources based on the limited computing and storage resources of the vehicle. Internet of Things (IoT) devices may also include numerous computing and storage devices for performing computing and storage operations, and a portion of these computing and / or storage resources may be designated as shared resources. According to the present disclosure, various offloadable computing and / or storage tasks of the vehicle (such as those that can be performed asynchronously) can be offloaded from the vehicle to be performed using the shared resources of nearby IoT devices. When it is determined that such tasks are suitable for offloading from the vehicle, the tasks can be split into multiple containers and sent to appropriate IoT devices to perform computing and / or storage operations on the tasks, and the returned result data can be aggregated at the vehicle to complete the task.

[0004] According to the present disclosure, various tasks and various types of tasks may be suitable for being offloaded. For example, a task for training a machine learning model used by a vehicle's smart cruise control may be offloaded because it does not need to be performed in real time. Data collected from the smart cruise control system for training the machine learning model may be sent to IoT devices, such as to a user's mobile device and controllers of nearby traffic lights, to perform training calculations on the data. The resulting data may be collected at the vehicle from the IoT devices, aggregated, and used to refine the machine learning model in the vehicle.

[0005] In another example, the task of storing large amounts of video data for later analysis may include splitting up the video data and offloading it to a storage device of a nearby traffic camera and another vehicle with excess storage capacity. The stored video data may then be asynchronously uploaded to a central computer (e.g., the cloud), and a notification of task completion may be sent back to the vehicle. Alternatively, the storage location data may be returned to the vehicle so that the stored data may be accessed later for analysis, such as by a central computer or the vehicle based on the storage location data.

[0006] In other examples and use cases, workloads can be offloaded to save vehicle power. This can apply to electric vehicles (EV), internal combustion engine (ICE) vehicles, or hybrid vehicles. In one use case, the vehicle may offload computations that consume a lot of resources and / or processing time and then shut down. In another use case, the workload can be offloaded to move with the user.

[0007] In one or more embodiments of the present disclosure, a system may include a vehicle computer of a vehicle, the vehicle computer having a processor and a memory. The memory may store instructions that are executable by the processor so that the computer is programmed to: determine a selected Internet of Things (IoT) device from a plurality of IoT devices separate from the vehicle, wherein the selected IoT device is selected based on being able to perform tasks including computing and / or storage of vehicle subsystems; decompose the tasks into a plurality of workloads to be offloaded for processing on the corresponding selected IoT devices; and send the workloads to the corresponding selected IoT devices.

[0008] Another embodiment may also include instructions for determining that the task is offloadable based on the task being allowed to use asynchronous processing.

[0009] In other implementations, the instructions for determining the selected IoT device may include instructions for evaluating available shared resources of IoT devices within a threshold distance relative to the vehicle.

[0010] In one embodiment, the instructions for determining the selected IoT device may include instructions for evaluating the quality of service (QoS) of the plurality of IoT devices.

[0011] In another embodiment, the instructions for evaluating the QoS of the plurality of IoT devices may include instructions for filtering the plurality of IoT devices based on network connection parameters of the plurality of IoT devices.

[0012] In other implementations, the instructions for evaluating the QoS of the plurality of IoT devices may include instructions for filtering the plurality of IoT devices based on encryption compatibility of the plurality of IoT devices.

[0013] In another embodiment, the instructions for evaluating the QoS of a plurality of IoT devices may include instructions for ranking the plurality of IoT devices based on the best fit of available shared resources for a task and selecting first few of the plurality of IoT devices as selected IoT devices to offload the task.

[0014] Embodiments of the system may also include instructions for encoding the plurality of workloads into a plurality of respective containers, each container including code and dependencies of one of the workloads of the decomposed tasks.

[0015] In another embodiment, the instructions for sending the workload to the respective selected IoT devices may include instructions for transmitting each of the plurality of containers to a respective IoT device among the selected IoT devices.

[0016] Another embodiment of the system may include instructions for receiving and aggregating result data from selected IoT devices of a workload of a task to complete processing of the task.

[0017] In one or more embodiments of the present disclosure, a method performed on a vehicle may include: determining a selected Internet of Things (IoT) device from a plurality of IoT devices separate from the vehicle, wherein the selected IoT device is selected based on being able to perform tasks including computing and / or storage of a vehicle subsystem; decomposing the task into a plurality of workloads to be offloaded for processing on the corresponding selected IoT device; and sending the workload to the corresponding selected IoT device.

[0018] Implementations of the method may also include determining that the task is offloadable based on the task being allowed to use asynchronous processing.

[0019] In another embodiment, determining the selected IoT device may include evaluating available shared resources of IoT devices within a threshold distance relative to the vehicle.

[0020] In other embodiments, determining the selected IoT device may include evaluating the quality of service (QoS) of the plurality of IoT devices.

[0021] In an embodiment, evaluating the QoS of the plurality of IoT devices may include filtering the plurality of IoT devices based on network connection parameters of the plurality of IoT devices.

[0022] In another embodiment, evaluating the QoS of the plurality of IoT devices may include filtering the plurality of IoT devices based on encryption compatibility of the plurality of IoT devices.

[0023] In other embodiments, evaluating the QoS of the plurality of IoT devices may include ranking the plurality of IoT devices based on a best fit of available shared resources for the task and selecting first few IoT devices of the plurality of IoT devices as selected IoT devices to offload the task.

[0024] Implementations of the method may also include encoding the plurality of workloads into a plurality of respective containers, each container including code and dependencies of one of the workloads of the decomposed tasks.

[0025] In another embodiment, sending the workload to the respective selected IoT devices may include transmitting each of the plurality of containers to a respective IoT device among the selected IoT devices.

[0026] Another embodiment of the method may also include receiving and aggregating result data from selected IoT devices of the workload of the task to complete processing of the task. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 is an illustration of an example system for providing vehicle workload offloading.

[0028] Figure 2 is an example diagram of an offload workload manager for a vehicle.

[0029] Figure 3 is an example flow chart of an offload workload manager for a vehicle.

[0030] Figure 4 is an example operational diagram of off-board workload management.

[0031] Figure 5 is an example operation diagram of the backup master mechanism.

[0032] Figure 6 is an example flow chart for evaluating and selecting Internet of Things (IoT) devices to offload tasks.

[0033] Figure 7 is an example flow chart for offloading vehicle tasks to IoT devices. DETAILED DESCRIPTION

[0034] refer to Figure 1 , the connected vehicle system 100 can provide communication between the vehicle 102 , a central computer 120 , and a plurality of IoT devices 124 .

[0035] The vehicle 102 is a set of components or parts used to perform a function or a set of operations in the vehicle 102, including hardware components, and typically also software and / or programming. The vehicle subsystem 106 typically includes a braking system, a propulsion system, and a steering system, as well as other subsystems, including but not limited to advanced driver assistance systems (ADAS) (including various driver assistance technologies (DAT)), body control systems, climate control systems, lighting systems, and human-machine interfaces (HMI) systems that may include head-up displays (HUDs), instrument panels, and infotainment systems. The propulsion subsystem converts energy into rotation of the wheels of the vehicle 102 to propel the vehicle 102 forward and / or backward. The braking subsystem can slow down and / or stop the movement of the vehicle 102. The steering subsystem can control the vehicle 102 as it moves, such as turning left and right, maintaining a straight path, etc.

[0036] The computer including one or more vehicle computers 104 discussed herein (e.g., one or more electronic control units (ECUs)) and the central computer 120 includes a corresponding processor and memory. The computer memory may include one or more forms of computer-readable media and store instructions that can be executed by the processor for performing various operations (including operations as disclosed herein). For example, the computer may be a general-purpose computer with a processor and memory as described above, and / or an ECU, controller, etc. for a specific function or set of functions, and / or a dedicated electronic circuit including an ASIC manufactured for a specific operation, such as an ASIC for processing sensor data and / or transmitting sensor data. In another example, the computer may include an FPGA (field programmable gate array), which is an integrated circuit manufactured to be configurable by a user. Typically, hardware description languages ​​such as VHDL (very high speed integrated circuit hardware description language) are used in electronic design automation to describe digital and mixed signal systems such as FPGAs and ASICs. For example, an ASIC is manufactured based on VHDL programming provided before manufacturing, and the logic components inside the FPGA can be configured based on, for example, VHDL programming stored in a memory electrically connected to the FPGA circuit. In some examples, a combination of a processor, an ASIC, and / or an FPGA circuit may be included in the computer.

[0037] The computer memory may be of any suitable type, for example, EEPROM, EPROM, ROM, Flash, hard drive, solid state drive, server, or any volatile or non-volatile medium. The memory may store data, such as the memory of an ECU. The memory may be a device separate from the computer, and the computer may retrieve information stored in the memory, for example, one or more computers 104 may obtain the data to be stored via a vehicle network 112 in the vehicle 102 (e.g., via an Ethernet bus, a CAN bus, a wireless network, etc.). Alternatively or in addition, the memory may be part of the computer 104, i.e., as a memory of the computer 104 or firmware of a programmable chip.

[0038] One or more vehicle computers 104 (e.g., one or more ECUs) may be included in a vehicle 102, which may be any suitable type of ground vehicle 102, such as a passenger car or commercial vehicle, such as a sedan, coupe, truck, sport utility vehicle, crossover, van, minivan, etc. As part of a driver assistance system or advanced driver assistance system (ADAS), the vehicle computer 104 may include programming to operate one or more of braking, propulsion (e.g., by controlling one or more of an internal combustion engine (ICE), electric motor, hybrid ICE / electric propulsion, etc. to control the acceleration of the vehicle 102 and control the transmission of power therefrom), steering, climate control, interior and / or exterior lights, etc. of the vehicle 102 and determine whether and when the computer controls such operations as compared to a human operator, such as by sending vehicle data over a vehicle network 112. Additionally, the vehicle computer 104 may be programmed to determine whether and when a human operator controls such operations.

[0039] The vehicle computer 104 may include or be communicatively coupled to (e.g., via a vehicle network 112, such as a communication bus as further described below) more than one processor, for example, included in sensors and cameras 108, electronic controller units (ECUs), etc. included in the vehicle 102 for monitoring and / or controlling various vehicle components, such as a powertrain controller, a brake controller, a steering controller, etc. The computer is typically arranged to communicate on the vehicle 102 communication network, which may include a bus in the vehicle 102, such as a controller area network (CAN), etc., and / or other wired and / or wireless mechanisms. Alternatively or additionally, in the event that the computer actually includes multiple devices, the vehicle network 112 can be used for communication between devices represented as computers in this disclosure.

[0040] The vehicle network 112 is a network via which messages can be exchanged between various devices in the vehicle 102. The vehicle computer 104 can generally be programmed to send and / or receive messages from other devices in the vehicle 102 (e.g., any or all of ECUs, sensors, cameras, actuators, components, communication modules, human-machine interfaces HMI, etc.) via the vehicle network 112. Additionally or alternatively, messages can be exchanged between various such other devices in the vehicle 102 via the vehicle network 112. In the case where the vehicle computer 104 includes multiple devices, the vehicle network 112 can be used for communication between devices represented as computers in the present disclosure. In some embodiments, the vehicle network 112 can be a network in which messages are communicated via a vehicle 102 communication bus. For example, the vehicle network 112 may include a CAN in which messages are communicated via a controller area network (CAN) bus, or a LIN in which messages are communicated via a local interconnect network (LIN) bus. In some embodiments, the vehicle network 112 may include a network in which messages are communicated using other wired communication technologies and / or wireless communication technologies (e.g., Ethernet, Wi-Fi, Bluetooth, ultra-wideband (UWB), etc.). In some embodiments, other examples of protocols that may be used to communicate via the vehicle network 112 include, but are not limited to, Media Oriented Systems Transport (MOST), Time Triggered Protocol (TTP), and FlexRay. In some embodiments, the vehicle network 112 may represent a combination of multiple networks that may be of different types that support communication between devices in the vehicle 102. For example, the vehicle network 112 may include: CAN, where some devices in the vehicle 102 communicate via a CAN bus; and a wired or wireless local area network, where some devices in the vehicle 102 communicate according to Ethernet or WI-FI communication protocols.

[0041] The vehicle computer 104 and / or the central computer 120 may communicate via the wide area network 116. In addition, the various computing devices discussed herein may communicate directly with each other, such as via direct radio frequency communication according to a protocol such as Bluetooth. For example, the vehicle 102 may include a communication module 110 for providing communications with devices and / or networks that are not included as part of the vehicle 102, such as, for example, global positioning satellites (GPS, not shown) and the wide area network 116. The communication module 110 may provide various communications, such as vehicle-to-vehicle (V2V), vehicle-to-infrastructure or the outside world (V2X), or vehicle-to-the outside world (including cellular communications (C-V2X) wireless communications cellular, dedicated short range communications (DSRC), etc.), typically providing communications to another vehicle or infrastructure via direct radio frequency communications, and / or typically providing communications to, for example, the central computer 120 via the wide area network 116. The communication module 110 may include one or more mechanisms by which the vehicle computer 104 may communicate, including any desired combination of wireless (e.g., cellular, wireless, satellite, microwave, and radio frequency) communication mechanisms and any desired network topology (or multiple topologies when multiple communication mechanisms are utilized). Exemplary communications provided via the module may include cellular, Bluetooth, IEEE 802.11, DSRC, Cellular V2X (CV2X), etc.

[0042] The vehicle 102 according to the present disclosure includes a plurality of sensors and cameras 108 that may support driver assistance or ADAS operations. For example, the sensors and cameras 108 may include, but are not limited to, one or more wheel speed sensors, steering angle sensors, GPS sensors, front cameras, side cameras, rear cameras, ultrasonic parking assist sensors, short-range radars, mid-range radars, light sensors, rain sensors, accelerometers, wheel torque sensors, inertial sensors, yaw rate sensors, and the like.

[0043] The vehicle 102 according to the present disclosure also includes an offload workload manager 105, which can be used to offload appropriate computing and / or storage tasks (hereinafter tasks). The offload workload manager 105 is connected to the communication module 110 through the vehicle network 112 to exchange data with the IoT device 124 or the central computer 120, such as via the wide area network 116 or directly via V2V, V2X, Bluetooth, Wi-Fi, etc. The offload workload manager 105 may include hardware components (i.e., processors and memory) as well as software and / or programming to perform the operations discussed herein.

[0044] The central computer 120 may be connected to a database (not shown) and may provide data about nearby (i.e., within a specified distance of the location of the vehicle 102) IoT devices 124 to the offload workload manager 105. Alternatively or in addition, the offload workload manager 105 may use the communication module 110 to search for nearby IoT devices 124 within a specified distance of the location of the vehicle 102 using standard techniques (i.e., based on the IoT devices 124 broadcasting their locations and sharing resources using V2V, V2X, Wi-Fi, Bluetooth, etc.).

[0045] refer to Figure 2 , an example schematic diagram of an offload workload manager 105 for a vehicle 102 is shown.

[0046] The offload workload manager 105 includes a master 210 , which is a module that includes program instructions (in the form of software or a combination of hardware and software) for performing the various operations of the offload workload manager 105 .

[0047] As an operation, the master device 210 maintains a list or device map 212 of nearby IoT devices 124, which may include device identifiers (IDs), distances of the IoT devices 124 from the vehicle 102, and other information such as available shared resources, access levels, network connections, encryption compatibility, device constraints, device owners, etc. for each IoT device 124. The master device 210 may maintain the device map 212 in any suitable manner. For example, the master device 210 may periodically download a list of nearby IoT devices 124A-124n from a database maintained by the central computer 120 based on the current location of the vehicle 102. In another embodiment, the master device 210 may maintain the device map 212 by periodically scanning for communications from the devices. In one variation, the search algorithm may use a combination of Bluetooth Low Energy (BLE) and IPv6 meshing according to conventional techniques for discovering nearby IoT devices 124A-124n. Alternatively or in addition, the master device 210 may use machine learning techniques to scan and then intelligently discover nearby IoT devices 124A-124n to which tasks may be sent. For example, a machine learning program such as a neural network may be trained with various device parameters (such as processing power (or an identifier of a processor), available memory, etc.), and then a set of nearby devices may be considered "discovered" based on the output from the machine learning program. The discovered or identified devices may be limited based on a predefined distance (e.g., 1000m) from the vehicle 102 to limit the number of IoT devices 124A-124n in the device map 212 to those within a specified proximity to the vehicle 102. Alternatively or in addition, the scan for devices may be terminated when a predefined number (e.g., 20) of IoT devices 124 closest to the vehicle 102 is reached, which may vary based on location, time of day, etc. In other embodiments, the scan may be terminated when a predetermined amount of available resources is reached.

[0048] The IoT devices 124A to 124n may include various types of devices, including infrastructure elements or edge devices, such as traffic lights 124A (i.e., controllers associated with traffic lights), mobile devices (such as cellular phones 124B), computers and / or ECUs in other vehicles (such as nearby vehicles 124C), and / or other IoT devices 124n. Furthermore, while referred to as IoT devices, as will be understood, such IoT devices 124A to 124n typically include embedded sensors and computing devices that may, but are not necessarily connected to the Internet / World Wide Web and are at least capable of joining a network to exchange data using one or more standard protocols. The IoT devices 124A-124n may include shared resources that may be reported as fixed or variable quantities available for use by other devices, including the vehicle 102 and its offload workload manager 105.

[0049] In one embodiment, the device map 212 may store a minimum amount of information for identifying a specific IoT device 124, such as a device ID and a distance from the vehicle 102, and additional information about the IoT device 124 (such as shared resources, access levels, network connections, encryption compatibility, device constraints, device owners, etc.) may be offloaded and stored at a central computer or in other IoT devices 124, such as in accordance with the offload principles of the present disclosure. Alternatively or in addition, the device map 212 may store data sufficient to identify a specific IoT device 124, such as a device ID, a distance from the vehicle 102, shared resources, and capabilities. Additional data about the IoT device 124 (such as access levels, network connections, encryption compatibility, device constraints, device owners, etc.) may be offloaded and stored at a central computer or in other IoT devices 124.

[0050] The offload workload manager 105 includes a task pool that can be stored in a task pool database 220. As used herein, a task includes a computing and / or data storage workload requested by any of the various vehicle subsystems 106, and a task pool is a collection or task set of tasks that need to be completed. For the corresponding tasks in the task pool, the task pool database 220 may include a task ID, a category (e.g., computing, storage, or both), a state (e.g., new, ongoing, processing, or completed), a computing type (e.g., CPU, ASIC, etc.), an expiration time of the task, an assigned priority relative to other tasks, etc. In one embodiment, the task pool database 220 may contain both tasks that can be offloaded from the vehicle 102 and tasks that cannot be offloaded from the vehicle 102 based on various operational or safety constraints. In another embodiment, the task pool database 220 may only contain tasks that can be offloaded from the vehicle 102.

[0051] Figure 3 An example flow diagram of an offload workload manager 105 for a vehicle 102 is shown. Figure 3 The arrows in the figure show possible data transfer between devices. Figure 2 Similarly, the offload workload manager 105 includes the previously described master device 210 and task pool database 220. As indicated by the arrow, the master device 210 can retrieve tasks with a status such as "to do" indicating that the workload of the task is ready to work from the task pool database 220. As used herein, the overall workload of a task includes the computing components / requirements of the task and the storage components / requirements of the task, each of which can be subdivided into multiple parts as separate workloads. In addition, as used herein, a container is a software package that contains elements (code and dependencies, such as runtime, libraries, etc.) for virtualizing an operating system and running in any environment.

[0052] The offload workload manager 105 also includes a task decomposition module (TDM) 230. The TDM 230 can be software or a combination of hardware and software that splits a task (i.e., decomposing the overall workload of the task according to any suitable technique, as is typically done for parallel or distributed computing operations) into multiple parts (i.e., decomposed workloads) and creates multiple containers that include code and dependencies for each decomposed workload for executing the task. In one embodiment, the computing workload can be split based on the elements required for one or more discrete calculations, the elements are based on a specific set of dependencies, and the storage workload can be split in any logical manner that maintains data integrity. The TDM 230 can be controlled by or be part of the master control device 210. The code and dependencies include information such as what is needed to process the workload and how to encrypt the results. As discussed further below, any suitable container can be used, such as any Open Container Initiative (OCI) standard container, such as a Docker or Podman container. After the master device 210 determines that the task can be offloaded, the master device 210 sends the task to the TDM 230 so that the task is split into multiple containers, and updates the status of the task in the task pool database 220 to "processing", etc., indicating that the workload of the task is being acted on. Since the TDM 230 splits the task into multiple containers, the compromise of security in a single IoT device 124 will not compromise the security of the task.

[0053] The offload workload manager 105 also includes a decomposed task queue 240, in which containers for tasks are queued before being sent to the scheduler 250. The decomposed task queue 240 can be accessed by the master control device 210, for example, can be stored in a short-term memory accessible to the master control device 210. The queued containers can be sorted based on the priority within the decomposed task queue 240. Priorities can be assigned based on the expiration time of the task, the assigned priority relative to other tasks, on a first-in-first-out basis, or in any other suitable manner. The decomposed task queue 240 can be software or a combination of hardware and software that performs its corresponding operations.

[0054] The offload workload manager 105 also includes a scheduler 250 that operates to transmit the next container from the decomposed task queue 240 (i.e., schedules to send multiple containers of tasks to the corresponding multiple selected IoT devices 124 to execute the code of the containers via the shared resources of the corresponding selected IoT devices 124 using the dependencies of the corresponding containers. The scheduler 250 can be software or a combination of hardware and software that performs its corresponding operations. In one embodiment, the scheduler 250 can work with the master device 210 or receive an allocation of selected IoT devices to determine compatible IoT devices 124 nearby that have shared resources sufficient to execute each corresponding workload, thereby determining which containers are scheduled to which IoT devices 124 of those selected IoT devices, for example, as shown in the process 600 discussed below. The scheduler 250 can be controlled by the master device 210 or be part of the master device.

[0055] The multiple containers of the task are unpacked and executed at the corresponding selected IoT device 124 to execute the corresponding decomposed workload associated with the task. When each decomposed workload of the task is completed at the corresponding selected IoT device 124, the IoT device 124 transmits the result data back to the offload workload manager 105, where the result data is received by the aggregator 260. The aggregator 260 decrypts the result data received from the selected IoT device 124 and aggregates the results belonging to the same task in the aggregate data set. The aggregated data is sent by the aggregator 260 to the master device 210, where the master device 210 can then also process the result, such as by providing the result to the vehicle subsystem 106 requesting the task to be executed through the network 112 or transmitting the result to the central computer via the communication module 110. The master device 210 can also update the status of the task in the task pool database 220 to "completed", etc., so that if the task is not a repeated task, the task can be deleted from the task pool database 220. Aggregator 260 may be controlled by master device 210 or be a part of the master device.

[0056] Figure 4 An example operational diagram of an offload workload management process 400 is shown.

[0057] To obtain new task 405, master 210 may request task 410 via a message to task pool database 220. At 415, task pool database 220 may return the task and mark the task as "in process" in the database.

[0058] To offload task processing of the task, the master device 210 retrieves a list of IoT devices at 425. In this example, the master device 210 may perform a search algorithm with respect to nearby IoT devices 124 to create a device map 212 with a list of IoT devices 124. In other examples, the master device may retrieve the IoT list from the central computer 120, or may access additional storage details of the device map 212 that have previously been offloaded to the storage resources of the IoT device 124.

[0059] At 430, the master device 210 analyzes the task to determine the time requirements of the task (substantially real-time or asynchronous processing) and / or what computing and / or storage resources are needed to complete the task. Only tasks that can be processed asynchronously (i.e., at a later point in time based on, for example, a set time when the task expires) can be offloaded. Other factors may also be considered, and some tasks may have restriction parameters indicating that they cannot be offloaded (such as because the data being processed is a category or type that is considered unsuitable for offloading). Then, when the asynchronous processing time requirements and / or other factors of the task allow it to be offloaded and the required resources are available from the nearby IoT device 124, the master device 210 makes an offload decision at 435. Tasks with real-time processing requirements are generally not offloaded and executed on the vehicle 102. In addition, if the resources required for the task are not currently available from the nearby IoT device 124, even tasks with asynchronous processing time requirements may not be offloaded at that time, but may be processed on the vehicle 102.

[0060] After making the offload decision at 435, the master 210 encodes the offload task at 440. Encoding the task at 440 may include splitting the workload of the task into multiple parts, and for each part of the workload, encoding a container with code and dependencies to execute the part of the workload. Any OCI standard container, such as Docker or Podman containers, may be used to encode the task into multiple containers for multiple parts of the workload of the task. Figure 3 As shown, TDM 230 may perform this operation and place the resulting container into decomposed task queue 240 .

[0061] The master device 210 then unloads the container by sending the container to the selected IoT device 124 at 445. Figure 3 As shown, this can be performed by a scheduler 250, which may be included in or controlled by the master device 210, to determine compatible IoT devices 124 nearby that have shared resources sufficient to execute each corresponding workload, thereby determining which containers are scheduled to which IoT devices 124 of those selected IoT devices in order to match the shared resources to the workload.

[0062] The selected IoT device 124 receives the container and decodes the container by performing any necessary decryption and unpacking the code and dependencies within the container at 450. Each IoT device 124 can then process its corresponding workload using the code and dependencies at 455 and encode the data with the resultant data produced by the processing at 460.

[0063] Typically, the IoT device 124 will have a primary operation, but may also have additional or extra resources that can be shared for processing offloaded workloads. These shared resources should be isolated from the primary resources of the primary operation. Therefore, the offloaded workload should not have any access to the non-shared resources of the IoT device 124. Data transmission to and from the IoT device 124 may be encrypted, and the IoT device 124 may be able to decrypt the received data and encrypt the data before transmitting it to the workload manager 105. The shared resources of the IoT device 124 may vary and include at least one of a shared storage device, shared memory, and shared computing power. For example, a task may involve storing data for later analysis, and therefore shared memory resources may be required. The computing task may require fast access to data, and therefore shared cache memory resources may be required, or sufficient cores may be required for workload execution, and therefore shared computing resources may be required.

[0064] After encoding the data at 460, the IoT device 124 may encrypt the encoded data and return the encoded data to the host device 210 at 465. At 470, the host device 210 decrypts and decodes the encoded data. Figure 3 Aggregator 260 may work with or under the control of master device 210 to decrypt and decode the encoded data at 470 and aggregate the results belonging to the same task into an aggregated data set. The aggregated result data may be sent by aggregator 260 to master device 210, which may then further process the result data.

[0065] The offload workload management process 400 may also operate to clean up the task pool at 480. In this process, the master device 210 indicates the task completion to the task pool database 220 at 480. The task pool database may then mark the task as completed and delete it from the task pool database 220 at 485.

[0066] about Figure 5 , shows an example operational diagram of a process 500 for operating a backup master 510. A backup master 510 may be provided for redundancy purposes.

[0067] The standby master mechanism 520 is initiated by a standby master 510 having the same hardware and software as the master 210, requesting a periodic status check 525 from the master 210. If the master 210 indicates to the standby master 510 at 530 that the master 210 is responding normally or is healthy, the standby master 510 determines at 535 that the master 210 controls the operation and continues to wait for the next periodic status check 525. If the master 210 indicates to the standby master 510 at 540 that the master 210 has failed or if the master 210 has not sent a response, the standby master 510 may determine at 545 that the standby master 510 should take over and continue to interoperate with the task pool database 220 on behalf of the master 210.

[0068] Figure 6 An example flow diagram of a process 600 of evaluating and selecting Internet of Things (IoT) devices to offload tasks is shown. The IoT devices 124 that perform the workload of the offloaded task can be selected based on their suitability to perform the workload based on their available resources and quality of service (QoS) as determined in the process 600, as now explained.

[0069] Thus, in a first block 610, the master device 210 retrieves an offloadable task from the task pool database 220. Although this example assumes that the task is offloadable, in other implementations, the master device 210 may retrieve the task and determine whether the task is offloadable from the vehicle 102. If not, the task may be sent to the vehicle 102 for processing on board using one or more computers 104 of the vehicle 102, as described below. Figure 7 shown.

[0070] After retrieving offloadable tasks at block 610 , the master device 210 may evaluate the resources required to execute the workload associated with the task, which may be used to match the workload with an appropriate IoT device 124 .

[0071] In the next box 620, the master device 210 can access the device map 212 and filter the IoT devices 124 based on the threshold distance from the vehicle 102. By using the nearby IoT devices 124, the communication network can be used efficiently, for example, V2V and V2X communications and / or short-range networks or protocols (e.g., using Bluetooth or Wi-Fi) can be used to reduce cellular network load. Therefore, transmitting data to and receiving data from the nearby IoT devices 124 may be more efficient than using cellular communications that must then stay within the same cellular node and / or utilizing a wide area network mechanism that may be less efficient (e.g., due to limited bandwidth, limitations of the transmission medium, etc.) to transmit data to a remote location through multiple links. In addition, the use of nearby IoT devices 124 can allow the computing and storage resources of the vehicle 102 to be effectively utilized for tasks that cannot be offloaded.

[0072] In block 630, the nearby IoT devices 124 may be filtered based on the level of access to required resources within the shared resources of the nearby IoT devices 124. Thus, IoT devices that are not allowed access to the kinds of resources (e.g., CPU, RAM, cache, storage, etc.) required to execute the workload of the task may be eliminated from consideration.

[0073] In block 640, nearby IoT devices 124 that are allowed access to the correct type of resource from block 630 are evaluated based on the current availability of their shared resources (e.g., CPU, RAM, cache, storage, etc.). Since the workload of a task can be split between different IoT devices 124, the current availability of resources can be used to decide how the task can be split and how many IoT devices 124 can be used to offload the task. For example, if the storage workload of the task requires 10MB of storage, currently available devices with 3MB of shared storage and 8MB of shared storage can be used to offload the task, where the storage workload is split into 2.5MB and 7.5MB, respectively. In another example, the computational workload of the task may include a computation that requires access to cached data and two other computations that do not require access to cached data. The available devices may include one device with a CPU with a large cache and multiple devices with CPUs with small caches or no cache. In this case, the tasks can be offloaded to three devices by splitting the computational workload so that the computational workload of calculations that require access to cached data is performed by the CPU of one device with a large cache and the computational workloads of the other two calculations are performed by the corresponding CPUs of two of the other devices.

[0074] In block 650 , the IoT devices 124 may be filtered based on network connectivity, such as based on connection speed, connection signal strength, packet error rate, etc.

[0075] In block 660 , the IoT devices 124 may be filtered based on whether they are compatible with the encryption used by the communication module 110 and / or the offload workload manager 105 .

[0076] In block 670 , the IoT devices 124 may be filtered based on constraints of the task, such as a time constraint within which the task must be completed, possible security constraints, etc.

[0077] Each of blocks 630, 640, 650, 660, and 670 may be performed in any suitable order, and may be omitted or modified in certain circumstances. These blocks in any combination may be considered to constitute an evaluation and filtering of IoT devices 124 based on quality of service (QoS), and may further consider transmission reliability, IoT device reliability, latency based on requests and response time after handshake, and / or any other suitable metric that may affect the predictability or timeliness of transmission or execution of offloaded workloads.

[0078] In a final block 680, suitable IoT devices 124 are ranked based on the best fit determined according to any suitable technique for a plurality of workloads for a particular task, thereby generating an ordered list of suitable IoT devices 124 for the task. For example, in one embodiment, the best fit may be achieved by scoring a plurality of parameters such as resource availability, connectivity, preferred IoT devices 124 and / or owners, distance, security capabilities of IoT devices 124, etc., and then ranking the IoT devices 124 based on the scores. A plurality of IoT devices 124 sufficient to complete the workload of the task in a timely manner may be selected from the ordered list of suitable IoT devices 124 for the task. A plurality of containers for the task may then be transferred to the selected IoT devices 124 for processing.

[0079] Figure 7 An example flow diagram of a process 700 for offloading vehicle tasks to selected IoT devices or processing tasks on-board the vehicle is shown.

[0080] The process begins at a first block 710, where the master device 210 retrieves tasks from the task pool database 220. If the task pool database 220 includes only offloadable tasks that do not require real-time processing for operation of the vehicle 102, the process 700 may move to block 730, discussed below. If the task pool database 220 includes both tasks that must be processed on the vehicle 102 (typically real-time tasks associated with the current operation of the vehicle 102) and offloadable tasks that do not require real-time processing for operation of the vehicle 102, the process 700 moves to decision block 720.

[0081] In decision block 720, a determination is made as to whether the task retrieved in block 710 is an offloadable task from a category that limits tasks that do not require real-time processing for operation of the vehicle 102 (e.g., tasks that can be processed asynchronously) and that is otherwise based on limiting tasks that do not need to be processed within the vehicle 102, etc. Decision block 730 may also initially determine whether a nearby IoT device has a task that performs an otherwise offloadable task (e.g., Figure 6 The required resources of the box 620 to 640 of FIG. 720 ) and the task can be determined to be not unloadable at the current time based on the lack of required resources. If the task is not unloadable (ie, “No”) at box 720 , the process 700 moves to box 725 .

[0082] In box 725, the master device 210 sends the task to be executed / processed on the vehicle on one or more of the computers 104, and then after completing the task, proceeds to box 728, where the master device 210 operates to mark the task completed and delete the task from the task pool database 220.

[0083] If the task is offloadable at block 720 ("yes"), process 700 moves to block 730, where master device 210 determines the task to be offloadable based on the Figure 6 The process 600 evaluates the QoS and resources of the IoT devices 124 to select a plurality of selected IoT devices 124 from an ordered list of suitable IoT devices 124 for executing a workload of a task.

[0084] In the next block 740, the master device 210 or the TDM 230 splits the task into multiple workloads corresponding to the selected IoT devices 124. For example, if the task has computation and storage workloads, the computation workload may be split among multiple IoT devices 124, and the storage workload may be allocated to one or more of the same or different IoT devices 124 based on the available shared resources available on the various IoT devices 124. In one embodiment, the master device 210 or the TDM 230 may split the task into multiple workloads before selecting the corresponding IoT device.

[0085] After splitting the task into multiple workloads at box 740, the master device 210 or TDM 230 can encode the multiple workloads of the task into associated containers of the selected IoT device 124 in box 750, and can send the container to the decomposed task queue 240 to be sent to the selected IoT device 124.

[0086] In the next block 760 , the master device 210 or the scheduler 250 may transmit the multiple containers of the task to the selected IoT device 124 to process the multiple workloads of the task.

[0087] In block 770 , the master device 210 or the aggregator 260 decodes the result data returned from the selected IoT devices and aggregates the data associated with the task to complete the processing of the task by the master device 210 .

[0088] In block 780 , the master device 210 interacts with the task pool database 220 to mark the task as completed and delete the task from the task pool database 220 , after which the process 700 for the particular task ends.

[0089] While the above is disclosed with respect to certain implementations, various other implementations are possible without departing from this disclosure.

[0090] The use of "in response to," "based on," and "upon determining..." herein indicates a causal relationship, not just a temporal relationship. In addition, unless otherwise expressly indicated herein, all terms used in the claims are intended to be given their ordinary and customary meanings as understood by those skilled in the art. Unless a claim recites an express limitation to the contrary, the use of singular articles such as "a / kind," "the," etc. should be interpreted as reciting one or more of the indicated elements.

[0091] In the accompanying drawings, the same or similar reference numerals indicate the same or similar elements. In addition, some or all of these elements may be changed. With respect to the media, processes, systems, methods, etc. described herein, it should be understood that although the steps of such processes, etc. have been described as occurring in a particular order, unless otherwise specified or as can be seen from the context, such processes may be practiced in the case where the steps are performed in an order other than the order described herein. Similarly, it should also be understood that certain steps may be performed simultaneously, other steps may be added, or certain steps described herein may be omitted. In other words, the description of the process herein is provided for the purpose of illustrating certain embodiments and should never be construed as limiting the present disclosure.

[0092] The present disclosure has been described in an illustrative manner, and it is to be understood that the terminology which has been used is intended to be in the nature of words of description rather than limitation. Many modifications and variations of the present disclosure are possible in light of the above teachings, and the present disclosure may be practiced in other ways than specifically described.

[0093] According to the present invention, a system is provided, the system having a vehicle computer of a vehicle, the vehicle computer including a processor and a memory, the memory storing instructions executable by the processor so that the computer is programmed to: determine a selected Internet of Things (IoT) device from a plurality of IoT devices separate from the vehicle, wherein the selected IoT device is selected based on being able to perform tasks including computing and / or storage of vehicle subsystems; decompose the tasks into a plurality of workloads to be offloaded for processing on the corresponding selected IoT devices; and send the workloads to the corresponding selected IoT devices.

[0094] According to one embodiment, the invention also features instructions for determining that a task is offloadable based on the task being allowed to use asynchronous processing.

[0095] According to one embodiment, the instructions for determining the selected IoT device include instructions for evaluating available shared resources of IoT devices within a threshold distance relative to the vehicle.

[0096] According to one embodiment, the instructions for determining the selected IoT device include instructions for evaluating a quality of service (QoS) of a plurality of IoT devices.

[0097] According to one embodiment, instructions for evaluating QoS of a plurality of IoT devices include instructions for filtering the plurality of IoT devices based on network connection parameters of the plurality of IoT devices.

[0098] According to one embodiment, instructions for evaluating QoS of a plurality of IoT devices include instructions for filtering the plurality of IoT devices based on encryption compatibility of the plurality of IoT devices.

[0099] According to one embodiment, instructions for evaluating QoS of a plurality of IoT devices include instructions for ranking the plurality of IoT devices based on best fit of available shared resources for a task and selecting first few of the plurality of IoT devices as selected IoT devices to offload tasks.

[0100] According to one embodiment, the invention also features instructions for encoding a plurality of workloads into a plurality of respective containers, each container including code and dependencies of one of the workloads of the decomposed tasks.

[0101] According to one embodiment, the instructions for sending the workload to the respective selected IoT devices include instructions for transmitting each of the plurality of containers to a respective one of the selected IoT devices.

[0102] According to one embodiment, the invention also features instructions for receiving and aggregating result data from selected IoT devices of a workload of a task to complete processing of the task.

[0103] According to the present invention, a method performed on a vehicle includes: determining a selected Internet of Things (IoT) device from a plurality of IoT devices separate from the vehicle, wherein the selected IoT device is selected based on being able to perform tasks including computing and / or storage of a vehicle subsystem; decomposing the task into a plurality of workloads to be offloaded for processing on the corresponding selected IoT device; and sending the workload to the corresponding selected IoT device.

[0104] In one aspect of the invention, the method includes determining that a task is offloadable based on the task being allowed to use asynchronous processing.

[0105] In one aspect of the invention, determining the selected IoT device includes evaluating available shared resources of IoT devices within a threshold distance relative to the vehicle.

[0106] In one aspect of the invention, determining the selected IoT device includes evaluating the quality of service (QoS) of the plurality of IoT devices.

[0107] In one aspect of the invention, evaluating the QoS of the plurality of IoT devices includes filtering the plurality of IoT devices based on network connection parameters of the plurality of IoT devices.

[0108] In one aspect of the invention, evaluating the QoS of the plurality of IoT devices includes filtering the plurality of IoT devices based on encryption compatibility of the plurality of IoT devices.

[0109] In one aspect of the present invention, evaluating QoS of the plurality of IoT devices includes ranking the plurality of IoT devices based on best fit of available shared resources for tasks and selecting first few IoT devices among the plurality of IoT devices as selected IoT devices to offload tasks.

[0110] In one aspect of the invention, the method includes encoding a plurality of workloads into a plurality of respective containers, each container including code and dependencies of one of the workloads of the decomposed tasks.

[0111] In one aspect of the invention, sending the workload to the respective selected IoT devices includes transmitting each of the plurality of containers to a respective IoT device among the selected IoT devices.

[0112] In one aspect of the invention, the method includes receiving and aggregating result data from selected IoT devices of a workload of a task to complete processing of the task.

Claims

1. A method performed on a vehicle, comprising: determining a selected Internet of Things (IoT) device from a plurality of IoT devices separate from the vehicle, wherein the selected IoT device is selected based on being able to perform tasks involving computation and / or storage of a vehicle subsystem; decomposing the task into a plurality of workloads to be offloaded for processing on corresponding selected IoT devices; as well as The workload is sent to the corresponding selected IoT device.

2. The method of claim 1, further comprising: The task is determined to be offloadable based on the task being allowed to use asynchronous processing. 3 . The method of claim 1 , wherein determining the selected IoT device comprises evaluating available shared resources of IoT devices within a threshold distance relative to the vehicle. 4 . The method of claim 1 , wherein determining the selected IoT device comprises evaluating a quality of service (QoS) of the plurality of IoT devices. 5 . The method of claim 4 , wherein evaluating the QoS of the plurality of IoT devices comprises filtering the plurality of IoT devices based on network connection parameters of the plurality of IoT devices. 6 . The method of claim 4 , wherein evaluating the QoS of the plurality of IoT devices comprises filtering the plurality of IoT devices based on encryption compatibility of the plurality of IoT devices.

7. The method of claim 4, wherein the evaluating the QoS of the plurality of IoT devices comprises sorting the plurality of IoT devices based on the best fit of available shared resources for the task and selecting first few of the plurality of IoT devices as the selected IoT devices to offload the task.

8. The method of claim 1, further comprising encoding the plurality of workloads into a plurality of respective containers, each container comprising code and dependencies of one of the workloads of the decomposed tasks. 9 . The method of claim 8 , wherein sending the workload to the corresponding selected IoT device comprises transmitting each of the plurality of containers to a corresponding IoT device among the selected IoT devices.

10. The method of claim 1, further comprising receiving and aggregating result data from the selected IoT devices of the workload of the task to complete processing of the task. The method of claim 10 , further comprising marking the task as completed after processing of the task is completed. 12 . The method of claim 1 , further comprising searching for nearby IoT devices to maintain a device map of IoT devices to evaluate the task.

13. The method of claim 3, wherein determining the selected IoT device comprises evaluating a quality of service (QoS) of the plurality of IoT devices.

14. The method of claim 13, wherein the evaluating the QoS of the plurality of IoT devices comprises sorting the plurality of IoT devices based on the best fit of available shared resources for the task, and selecting first several IoT devices among the plurality of IoT devices as the selected IoT devices to offload the task.

15. A system comprising a vehicle computer of a vehicle, the vehicle computer comprising a processor and a memory, the memory storing instructions executable by the processor, the processor being programmed to perform the method according to any one of claims 1 to 14.

Images