Vehicle-specific calculation management system for cloud data processing

Abstract

Vehicle control and calculation system, comprehensive: a task control (25) in the vehicle (10); a vehicle-specific computation manager (40) in a cloud network (12) with multiple cloud servers, wherein the cloud network (12) has a separate vehicle-specific computation manager (40) for each respective vehicle (10) that is authorized to use a respective cloud data processing server system, and wherein at least one cloud server is dynamically scalable and adaptable; and a wireless data channel that couples the task control (25) and the cloud network (12); wherein the task control (25) performs operational tasks in the vehicle (10) using data-related resources in the cloud network (12); where, when one of the operational tasks is initiated, the task controller (25) sends an exchange signal to the computation manager (40) as a resource request; wherein the computation manager (40) calls at least one cloud-based agent from a database (46) of predefined agents in response to the exchange signal; and wherein the task control (25) completes the operational task by communicating with the called agent, and wherein each vehicle-specific calculation manager (40) is coupled to a central manager (45) which is set up so that a service provider can exercise master control over all vehicle-specific calculation managers (40).

Description

[0001] The present invention relates generally to automotive applications that use cloud data processing, and in particular to the interface between a vehicle and cloud data processing resources.

[0002] Internal vehicle computing units (for example, microprocessor-controlled electronic modules such as powertrain controls, driver information systems, and entertainment systems) are generally limited by the relatively low processing power of vehicle computers, small data storage capacities, and a lack of easy access to programming updates or other data created after the vehicle has been put into service. Advances in mobile connectivity between vehicles and external computing cloud infrastructure are beginning to enable new classes of electronic features that are not limited in this way.

[0003] Wireless vehicle communication is often characterized by variable bandwidth, variable latency, and sporadic availability. The conventional in-vehicle computer, or electronic control unit (ECU), is characterized by high reliability, high robustness, hard real-time response, low processing power, and very small memory (especially non-volatile memory). The ECU is portable, lasts the lifetime of the vehicle, and is included with the vehicle purchase. Data generated by the ECU typically relates to events that occurred in the past on very short timescales. Cloud computers, on the other hand, are characterized by high reliability, high computing power, large memory, and (from the vehicle's perspective) a lack of real-time response.They are stationary, managed systems that are frequently replaced and operated on a rental, ownership, or usage-fee basis. Data generated in the cloud is generally predictive in nature, forecasting what might happen a certain time in the future, rather than what happened in the past.

[0004] While an in-vehicle, connected control architecture remains the dominant approach for safety-critical and real-time functionality, cloud computing applications can provide enhanced vehicle control / adaptation and new functionalities. For example, cloud computing can offer resource-intensive services to achieve leaner, safer, smarter, greener, and more enjoyable vehicle operation.

[0005] Cloud computing is a model for enabling network access to a shared pool of configurable computing resources that offer virtually unlimited storage space and essentially unlimited computing power. Areas where cloud computing provides improved vehicle performance and driver convenience include managing traffic congestion, route planning, adjusting target speeds to road and traffic conditions, calibrating vehicle systems (such as active suspension systems) to changing environmental conditions, and many others.

[0006] Access to cloud resources must be readily available and deployed with minimal management effort or service provider interaction. Operational interface communication and billing management for accessing cloud resources should be optimized based on the relative limitations and strengths of the two processing environments.

[0007] US 2011 / 0 270 468 A1 and DE 10 2012 214 390 A1 disclose generic vehicle control and calculation systems.

[0008] The invention provides an invoice management system for controlling and implementing invoice-related tasks using cloud resources according to the subject matter of claim 1 in a manner that efficiently meets the requirements of real-time communication between in-vehicle networks and the cloud server, calling up retrievable agents (for example, running and publishing), online and offline data processing and storage, frequent computation cycles (for example, starting, running and ending), information processing (for example, classifying, sharing, storing) and robust and reliable operation and communication.

[0009] The complexity of the calculations can be managed through various combinations of priorities and requirements. Local calculations performed on the vehicle's internal networks range from simple (requiring fewer computing resources) to complex (requiring more computing resources). The same applies to remote calculations performed on cloud computing servers (CCS), resulting in the following possible combinations: Performing simple calculations in the local ECUs with a fast sampling rate and using available CCS data to improve local calculations at a slow sampling rate, resulting in an LSRS (Local-Simple-Remote-Simple) strategy. Performing simple calculations in the local ECUs with a fast sampling rate and outsourcing complex calculations to the CCS for cloud data processing agents to perform this at a low sampling rate, resulting in an LSRC (Local-Simple-Remote-Complex) strategy. Performing complex calculations compatible with the capabilities of current ECUs at a fast sampling rate, and using available CCS data to improve local calculations at a slow sampling rate, resulting in an LCRS (Local-Complex-Remote-Simple) strategy, and Performing complex calculations compatible with the capabilities of current ECUs at a fast sampling rate, and outsourcing even more resource-intensive calculations to the CCS for cloud data processing agents to perform them at a slow sampling rate, resulting in an LCRC (Local-Complex-Remote-Complex) strategy.

[0010] The invention's calculation management system distributes calculation tasks according to the corresponding complexity that must be taken into account.

[0011] For each task initiated in the vehicle that depends on interaction with cloud resources, a corresponding software entity, called an agent, can be used in the cloud. These agents exemplify the benefits of integrating cloud data processing with vehicle control systems. Generally, agents can perform tasks according to three main groups: service, control, and crowdsourcing. Service agents primarily handle data management, focusing on processing, organizing, summarizing, and storing information within the CCS (Cloud Communication System).Control agents extend the capabilities of in-vehicle controls by performing broad control tasks that require significant computational resources and are not suitable for in-vehicle implementation. Examples include learning driver models, estimating vehicle states, calculating optimal speed profiles along a specified route, and real-time control calibrations. Crowdsourcing agents collect and aggregate information from multiple vehicles, combine it with other cloud information sources (e.g., weather conditions, traffic updates, geographic data), and estimate the states of groups of vehicles, such as characterizing current traffic and road conditions at a specific location.

[0012] In one aspect of the invention, a vehicle control and computing system comprises a task controller in the vehicle and a vehicle-specific computing manager in a cloud network. A wireless data channel connects the task controller and the cloud network. The task controller performs operational tasks in the vehicle using data-related resources in the cloud network. When initiating one of the operational tasks, the task controller sends an exchange signal ("handshake") to the computing manager as a resource request. In response to the exchange signal, the computing manager calls at least one cloud-based agent from a database of predefined agents. The task controller completes the operational task by communicating with the called agent. Fig. Figure 1 is a diagram showing vehicle communication with cloud resources via a wireless communication system. Fig.Figure 2 is a block diagram showing vehicle systems according to an embodiment of the invention. Fig. Figure 3 is a block diagram that shows a communication channel in more detail. Fig. Figure 4 is a model showing various functional elements of the vehicle / cloud data processing environment of the invention. Fig. Figure 5 is a block diagram of a computation management system according to an embodiment of the invention. Fig. 6 is a block diagram that shows computation management tasks for the system of Fig. 5 shows.

[0013] Fig.Figure 1 shows a cloud data processing system, where vehicles 10 and 11 communicate wirelessly with cloud resources 12 via a data communication system based on a mobile cellular communication system. Vehicle 10 communicates with a cellular carrier network 13 via a cellular mast 14, and vehicle 11 communicates with a cellular provider network 15 via a cellular mast 16. Provider networks 13 and 15 are interconnected. The cloud resources 12 are coupled to the cellular networks via a gateway 17. The cloud 12 can contain any collection of resources, including multiple servers 20-22.

[0014] Fig.Figure 2 shows a generic data processing architecture within the vehicle 10, where data processing resources are distributed among several electronic modules, including a task controller 25 and a task controller 26. Each task controller in the vehicle 10 can interact, for example, with respective sensors 27, actuators 28, and a human-machine interface (HMI) 29. Task controllers 25 and 26 are connected to each other via an internal vehicle interface or a communication bus 24 known in the technology. A wireless data interface 30 is coupled to task controllers 25 and 26 via the bus 24 to create a wireless data channel that connects the task controllers to the cloud network.

[0015] The wireless data channel is described in more detail in Fig.Figure 3 shows that several different communication technologies can be used to help ensure maximum connectivity between the vehicle and cloud resources. A cloud data processing network 12 is coupled to a cellular network 31, including cell towers, for wireless data exchange with an in-vehicle cellular modem 32 and / or a driver's mobile device 33 to carry network communication packets to and from in-vehicle networks via the bus 24. The in-vehicle wireless data interface 30 can include a communication port 34, extending communication capabilities to Wi-Fi, Bluetooth, and USB-connected devices. Furthermore, a hardwired communication port 35 can be provided for other types of network communication modes, such as Ethernet.

[0016] Fig.Figure 4 shows a vehicle-cloud interface model, where A denotes the collection of all relevant actuators in the vehicle, P the vehicle factory, S the collection of all sensors, and C the collection of all controllers. Furthermore, D represents the driver, and R denotes the references. Within this model, ΔCl is the incremental controller generated from local vehicle measurements, ΔCr is the incremental controller generated from both local and cloud information, ΔRl is the incremental reference generated from local vehicle measurements, and ΔRr are the incremental references generated from both local and cloud information. W represents the wireless communication equipment. Gr is the collection of data storage, data processing, and software units in the cloud.“uCk” denotes the digital control signal generated by controllers “C” and passed through a digital-to-analog converter “a” before the actuator “A” receives a command. “uD” represents the driver’s control commands, which are influenced by i) unknown information, designated yD, as observed by the driver, ii) “yA”, which is the sensor readings from the actuators, iii) “yK”, which is the digital sensor readings obtained by sending the outputs of “S” through the analog-to-digital converter “d”, and iv) “rk”, which is the reference signal. “ρlk” represents the signal communicated between “R” and ΔRl. “ρrm” is the signal communicated between “R” and ΔRr, and “ρlk” is the signal communicated between “C” and ΔCl. “σrm” is the signal that is communicated between “C” and “ΔCr”, and “γrm” is the signal that is communicated between “W” and “Gr”.

[0017] The complexity of calculations to be performed in or for a vehicle operating in conjunction with a cloud server differs significantly from typical vehicle-based calculations traditionally performed in local, self-contained ECUs within the vehicle. In conventional vehicle-based architectures, ECUs primarily performed calculations independently, relying on minimal information shared through in-vehicle networks such as CAN. All computing power was allocated to individual ECUs, and switching between ECU service objects was previously impossible. With the cloud data processing of the present invention, a cloud server is dynamically scalable and adaptable, creating a virtual ECU with unlimited computing power and storage capacity.Such an "extended" ECU could potentially be designed to serve any vehicle and perform any desired functions. The computational needs of each vehicle, or the implemented functions of each vehicle, could be managed through various combinations of prioritization, arbitration, control, and cycling.

[0018] Fig. Figure 5 shows a preferred embodiment for a computation management system used within the cloud network 12. A separate vehicle-specific computation manager (VCM) 40-43 is provided for each vehicle authorized to use a respective cloud data processing server system. Internal details and other cloud network connections are shown only for VCM 40.

[0019] The VCM 40 is connected to a central manager 45, through which a service provider performs master control over all VCMs. The central manager 45 and the VCM 40 are coupled with an agent database 46 containing several predefined agents, previously developed to perform predefined tasks that are made available to individual vehicles. Each agent is configured to be called (i.e., claimed) by a specific VCM to accomplish a particular task, which, if necessary, can communicate with or utilize additional cloud resources 47.

[0020] The VCM 40 (dedicated to a single vehicle) contains a task list 50, a data archive 51, and an agent workspace 52 for managing and executing operational tasks defined by vehicle requests that claim data-related resources from the cloud network 12. The task list 50 is used to maintain an overview of multiple concurrent resource requests initiated by a given vehicle, enabling the prioritization of concurrent tasks according to predefined criteria. The archive 51 stores vehicle-specific information to support operational tasks that can utilize historical data. The agent workspace 52 facilitates the creation of individual instances of claiming predefined agents to respond to operational tasks requested by the vehicle.

[0021] If any of the task controllers within a vehicle initiates an operational task that requires interaction with cloud data processing resources, an exchange signal is generated according to the invention for sending to the vehicle-specific computation manager (VCM) in the cloud. The exchange signal can have the following structure. Exchange signal byte Byte value and meaning 0 0 No requirements from local ECUs and the cloud. No communication between the cloud and local ECUs. 1 0 Inactive Communication requirement 1 Local ECUs request cloud data, but the cloud data is not needed by local ECUs (used for LSRS or LCRS). 2 Cloud requires local ECU information; local ECUs do not request data from the cloud. 3 Local ECU and cloud exchange data. 2 0 Inactive Data storage requirement 1 Local ECUs send data to the cloud and request the cloud to store data in specified categories. 2 Local ECUs send data to the cloud and request the cloud to store data in unspecified categories (the cloud must determine where to store it). 3 0 Inactive Calculation requirement 1 Local ECUs request the cloud to perform certain calculations based on cloud data. 2 Local ECUs send data to the cloud and request the cloud to perform certain calculations based solely on local ECU data. 3 Local ECUs send data to the cloud and request the cloud to perform certain calculations based on both local ECU data and cloud data. 4 Local ECUs and the cloud should have dynamic data exchange, meaning that calculation depends on data exchange at each time step. 4 0 Inactive Crowdsourcing requirement 1 Cloud requires local ECUs to send vehicle data needed for cloud sourcing purposes. 2 Local ECUs send event-based data to the cloud and request the cloud to use the event-driven data for crowdsourcing purposes. 5 to end ... Labels of any length. May contain names or IDs of specific agents to be called and / or vehicle data to support requested tasks. Usage data

[0022] Fig.Figure 6 shows a preferred embodiment of interface tasks to be performed by the vehicle-specific computation manager in response to an incoming exchange signal transmitted by a task controller in the vehicle when initiating one of its operational tasks that requires support from cloud resources. Thus, a request task 60 is initiated in the VCM to parse and analyze the content of the exchange signal. If a single request contains multiple agents to be called, or if one or more agents for other operational tasks have already been called and are currently executing in the agent workspace of the VCM, then a priority task 61 prioritizes the execution and communication functions associated with the respective agents (for example, based on a predefined priority order or dynamically determined function availability).As a result of prioritization, the task list maintained by the VCM is populated with information defining which agents are called, the time they are called, and the location to find or store data used by the agents, along with information defining the desired results and any respective locations where the calculation results are to be stored.

[0023] Using the task list, a submission task 62 is performed to identify and locate prototype cases of the desired agent(s) within a central agent database maintained within the cloud computing network. In an agent request task 63, the identified agent prototypes are retrieved and transferred to the VCM agent workspace, at which point each task is called by the compute manager. Upon being called, an agent initialization task 64 is performed, in which the initial data and / or other task-related conditions required by each specific agent are initialized by the compute manager.Initialization can be performed through various mechanisms, such as a) using average values ​​of the variables used, as measured or calculated in the vehicle, b) using average values ​​of the variables used, determined from crowdsourced data, or c) using historical data of the variables used, as stored in the data archive in the vehicle-specific calculation manager.

[0024] After initialization, the agent(s) use the vehicle or cloud data to perform the target calculation(s) in a start task 65. For start task 65, all inputs, data, and necessary calculation models are combined in the specific workspace as required to support the operational task(s) identified by the initial exchange signal.

[0025] Formal execution of the called agent(s) is performed in agent run task 66. Possible results of agent run tasks include either an agent balancing task 67, an error task 68, or a result task 70. In balancing task 67, dynamically changing agents can be replaced as a result of changing vehicle conditions (for example, if changing conditions necessitate the use of a different set of inputs to perform the desired operational task). If a need for balancing is detected, the system returns to dispatch task 62 to identify a different agent, which is then retrieved, initialized, and started.

[0026] If the run task 66 results in an error or other failure to produce the desired result, the error task 68 checks whether the run task can be successfully executed under the current conditions. If not, a termination task 71 is executed. Otherwise, the existing agent case is reinitialized with the agent reinitialization task 72, and then restarted with the restart task 73, before returning to tasks 65 and 66.

[0027] If successful results are obtained for result task 70, the result is formatted for return to the task control in the vehicle. Results may be prioritized for transmission in relation to other ongoing processes affecting the same vehicle. After the results are delivered, completion task 71 is performed, including releasing the associated resources (for example, in the agent workspace and task list) for task 74. Once the associated resources are released, the calculation manager is complete with respect to the associated operational task.

Claims

[1] Vehicle control and calculation system, comprising: a task control (25) in the vehicle (10); a vehicle-specific computation manager (40) in a cloud network (12) with multiple cloud servers, wherein the cloud network (12) has a separate vehicle-specific computation manager (40) for each respective vehicle (10) that is authorized to use a respective cloud data processing server system, and wherein at least one cloud server is dynamically scalable and adaptable; and a wireless data channel that couples the task control (25) and the cloud network (12); wherein the task control (25) performs operational tasks in the vehicle (10) using data-related resources in the cloud network (12); where, when one of the operational tasks is initiated, the task controller (25) sends an exchange signal to the computation manager (40) as a resource request; wherein the computation manager (40) calls at least one cloud-based agent from a database (46) of predefined agents in response to the exchange signal; and wherein the task control (25) completes the operational task by communicating with the called agent, and wherein each vehicle-specific calculation manager (40) is coupled to a central manager (45) which is set up so that a service provider can exercise master control over all vehicle-specific calculation managers (40). [2] System according to claim 1, wherein the calculation manager (40) maintains a task list (50) and a long-term data archive (51) corresponding to the vehicle (10). [3] System according to claim 2, wherein the computation manager (40) receives multiple overlapping resource requests from the vehicle (10), and wherein the computation manager (40) performs a prioritization task to prioritize each received resource request with reference to the task list (50) and to set an execution of a called agent according to the prioritization. [4] System according to claim 2, wherein the computation manager (40) performs an initialization task when calling the called agent in order to set initial data and conditions used by the called agent. [5] System according to claim 4, wherein the initial data and conditions comprise contents of the exchange signal. [6] System according to claim 4, wherein the initial data and the conditions comprise contents of the data archive (51). [7] System according to claim 4, wherein the initial data and conditions comprise data obtained from crowdsourcing which are stored in the cloud network (12). [8] System according to claim 1, wherein the computation manager (40) performs a balancing task to stop a called agent and re-identify a replacement agent in response to changing conditions of the vehicle (10). [9] System according to claim 1, wherein the computation manager (40) performs a result task in order to send results to the task controller (25) in response to a successful operation by the called agent. [10] System according to claims 4 and 9, wherein the computation manager (40) performs an error task in response to an unsuccessful operation of the called agent, the error task comprising a reinitialization to re-establish initial data and conditions used by the called agent and restarting the called agent. [11] System according to claim 10, wherein the computation manager (40) performs a termination task to release the called agent and the data-related resources after 1) execution of the result task or 2) inability of the error task to restart the called agent.

Images