Patent Application
20150207859
Not Applicable.
Not Applicable.
The present invention relates in general to automotive applications using cloud computing, and, more specifically, to the interface between a vehicle and cloud computing resources.
Onboard vehicle computing devices (e.g., microprocessor-controlled electronic modules such as powertrain controllers, driver information systems, and entertainment systems) are generally limited to relatively low processing power of vehicle computers, small data storage, and lack of easy access to programming updates or other data that is created after the vehicle is put into service. Advances in mobile connectivity between vehicles and an off-board computational cloud infrastructure are beginning to enable new classes of electronic features that are not limited in this way.
The wireless connection available for wireless vehicle communication is often characterized by variable bandwidth, variable latency, and sporadic availability. The typical in-vehicle computer or electronic control unit (ECU) is characterized by high reliability, high durability, hard real-time response, low processing power and very small memory (particularly non-volatile memory). The ECU is mobile, lasts the life of the vehicle, and is part of the vehicle purchase. Data created in the ECU tends to be related to events that have happened in the past on very short time scales. In contrast, cloud computers are characterized by high-reliability, high-computational power, large memory and (from the perspective of the vehicle) lack of real-time response. They are stationary, managed systems that are replaced frequently and operate on a lease, own, or fee-for-use basis. Data created in the cloud tends to have a forecast nature that tells what can be expected sometime into the future, rather than what has happened in the past.
While an onboard, networked control architecture remains the dominant approach for safety critical and real-time functionalities, cloud-computing applications can provide enhanced automotive control/adaptation and new functionalities. For example, cloud computing can provide resource intensive services to achieve leaner, safer, smarter, greener, and more enjoyable automotive operations.
Cloud computing is a model for enabling network access to a shared pool of configurable computing resources that have virtually unlimited storage space and essentially unlimited computational power. Areas in which cloud computing offers improved vehicle performance and driver convenience include dealing with traffic congestion, route planning, adapting target speeds to road and traffic conditions, calibrating vehicle systems (e.g., active suspension) to changing environmental conditions, and many others.
Access to cloud resources needs to be rapidly provisioned and released with minimal management effort or service provider interaction. The operational interfacing and computational management for accessing cloud resources should be optimized to the relative limitations and strengths of the two processing environments.
The invention provides a computation management system for supervising and implementing computation-related tasks using cloud resources, in a manner that efficiently meets the demands of real-time communication between in-vehicle networks and the cloud server, the calling of on-demand agents (e.g., running and releasing), on-line and off--line computing and storage, frequent computation cycles (e.g., starting, running, and ending), information processing (e.g., classifying, sharing, storing), and robust and reliable operation and communication.
The complexity of the computations can be managed through different combinations of priorities and demands. The local computations conducted in the in-vehicle networks range from being simple (demanding less computational resources) to complex (demanding more computational resources). The same is true for the remote computations conducted in the cloud computing servers (CCS), resulting in the following possible combinations:
For each respective task initiated onboard the vehicle that depends on any interaction with the cloud resources, a respective software entity known as an agent may be deployed in the cloud. The agents exemplify the benefits of integrating cloud computing with vehicle controls. The agents may generally perform tasks according to three main groups: service, supervisory, and crowdsourcing. Service agents deal primarily with data management, and they focus on handling, organizing, summarizing, and storing information in the CCS. Supervisory agents expand the capability of onboard vehicle controls by executing broad control tasks that require significant computational resources and that are not suitable for on-board implementation, e.g., learning driver models, estimating vehicle states, calculating optimal speed profile along a specified route, real-time control calibrations, etc. The crowdsourcing agents gather and summarize information from multiple vehicles, fuse this information with other cloud information sources (e.g., weather conditions, traffic updates, geographical data) and estimate the states of groups of vehicles, such as characterizing current traffic and road conditions at a specific location.
In one aspect of the invention, a vehicle control and computation system comprises a task controller in the vehicle and a vehicle-specific computation manager in a cloud network. A wireless data channel couples the task controller and the cloud network. The task controller performs operational tasks in the vehicle using data-related resources in the cloud network. Upon initiating one of the operational tasks, the task controller sends a handshake signal to the computation manager as a resource request. The computation manager calls at least one cloud-based agent from a database of predetermined agents in response to the handshake signal. The task controller completes the operational task via communication with the called agent.
The wireless data channel is shown in greater detail in
denotes the collection of all the relevant actuators in the vehicle,
is the vehicle plant,
is the is collection of all sensors, and
is the collection of all the controllers. Further,
represents the driver, and
denotes the references. Δ
l is the incremental control generated from local vehicle measurements, Δ
r is the incremental control generated from both the local and cloud information, Δ
l is the incremental reference generated from local vehicle measurements, and Δ
r is the incremental references generated from both local and cloud information.
represents the wireless communication devices.
r is the collection of the data storage, data processing, computing, and software units in cloud 12. u
, which passes through a digital-to-analog converter a before commanding the actuator
. uD represents the driver's control commands that are influenced by i) unknown information denoted yD as observed by the driver, ii) yA, which is the senor measurements of the actuators, iii) yk, which is the digital sensor measurements by passing the outputs of
through analog-to-digital converter d, and iv) rk, which is the reference signal. gl
and Δ
l. gr
and Δ
r, and σl
and Δ
l. σr
and Δ
r, γr
and
r.
The complexity of computations to be conducted in or for a vehicle that is operating together with a cloud server is very different from the typical onboard computations that have been conducted conventionally in local, self-contained ECUs in a vehicle. In conventional onboard architectures, ECUs have mainly conducted computations independently and with minimal information being shared through in-vehicle networks, such as CAN. All the computational powers have been dedicated to individual ECUs, and it has been impossible to switch the service objects of ECUs. In cloud computing of the present invention, a cloud server is dynamically scalable and adaptable, creating a virtual ECU that has unlimited computational power and unlimited storage space. Such an “extended” ECU can potentially be adapted to serve any vehicle and perform any desired functions. The computational needs for each vehicle or the implemented functions of each vehicle can be managed through various combinations of priorities, arbitration, supervision, and cycling.
VCM 40 is connected to a central manager 45 through which a service provider exercises master control over all the VCMs. Center manager 45 and VCM 40 are coupled to an agent database 46 wherein a plurality of predetermined agents are stored which have been previously developed in order to perform predefined tasks that are being made available to individual vehicles. Each agent is configured to be called (i.e., invoked) by a respective VCM in order to achieve a respective task which may, when necessary, communicate with or use additional cloud resources 47.
VCM 40 (which is dedicated to a particular individual vehicle) includes a task list 50, a data archive 51, and an agent workspace 52 for managing and executing operational tasks defined by vehicle requests that invoke data-related resources of cloud network 12. Task list 50 is used to keep track of multiple simultaneous resource requests that have been initiated by a corresponding vehicle, so that the simultaneous tasks can be prioritized according to predefined criteria. Archive 51 stores vehicle-specific information to support operational tasks that may employ historical data. Agent workspace 52 is maintained in order to support the creation of individual instances of the predefined agents being invoked to respond to vehicle requested operational tasks.
According to the invention, when any one of the task controllers within a vehicle initiates an operational task that invokes an interaction with the cloud-computing resources, a handshake signal is generated for sending to the vehicle-specific computation manager (VCM) in the cloud. The handshake signal may have the following structure.
Using the task list, a dispatching task 62 is performed to identify and locate prototype instances of the desired agent or agents 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 agent workspace of the
VCM, at which point each task is called by the computation manager. Upon being called, an agent initialization task 64 is performed wherein the initial data and/or other task-related conditions needed by each specific agent are initialized via the computation manager. Initialization can be conducted through several mechanisms, such as a) using average values of the involved variables as measured or computed onboard the vehicle, b) average values of the involved variables determined from crowdsourcing data, or c) historical data of the involved variables as stored in the data archive within the vehicle-specific computation manager.
After initialization, the agent or agents use the vehicle or cloud data to conduct the target computation(s) in a starting task 65. For starting task 65, all inputs, data, and necessary computation models are assembled together in the specific working space as necessary to support the operational task(s) identified from the original handshake signal.
Formal running of the called agent or agents is conducted at agent running task 66. Potential outcomes of running of the agents includes either in agent rebalancing task 67, a failure task 68, or a results task 70. In rebalancing task 67, dynamically changing agents may be replaced as a result of changing conditions of the vehicle (e.g., where changing conditions necessitate use of a different set of inputs in order to perform the desired operational task). Thus, if a need for rebalancing is is detected a return is made to dispatching task 62 to re-identify another agent which is then retrieved, initialized, and started.
In the event that running task 66 results in an error or other failure to produce the desired result, then failure task 68 checks to determine whether or not the operational task can be successfully performed in view of the current conditions. If not, then a termination task 71 is performed. Otherwise, the existing instance of the agent is reinitialized in agent re-initialization task 72 and then restarted at restarting task 73 before returning to tasks 65 and 66.
If successful results are obtained at results task 70, then the result is formatted for transmitting back to the task controller in the vehicle, with the results potentially being prioritized for transmission with respect to other ongoing processes involving the same vehicle. After delivery of the results, the termination task 71 is performed including a freeing of the associated resources (e.g., in the agent workspace and task list) at task 74. Once the associated resources are freed, the computation manager is done with respect to the associated operational task.
