Patent Application
20250140027
Vehicles or transports, such as cars, motorcycles, trucks, planes, trains, etc., generally provide transportation needs to occupants and/or goods in a variety of ways. Functions related to vehicles may be identified and utilized by various computing devices, such as a smartphone or a computer located on and/or off the vehicle.
One example embodiment provides a method that includes one or more of receiving sensor data from a hardware sensor of a vehicle, where the sensor data comprises values of a route sensed as the vehicle is travelling on the route, identifying a speed limit of the route, generating a sequence of predicted speed limit offset values for the vehicle at future locations on the route based on execution of a machine learning model on the received sensor data and the identified speed limit of the route, determining a range estimation of the vehicle based on a current amount of charge of a rechargeable battery of the vehicle and the generated sequence of predicted speed limit offset values for the vehicle at future locations on the route, and displaying the range estimation on a user interface within the vehicle.
Another example embodiment provides a system that includes a storage configured to store a machine learning model, and a processor configured to one or more of receive sensor data from a hardware sensor of a vehicle, where the sensor data comprises values of a route sensed as the vehicle is travelling on the route, identify a speed limit of the route, generate a sequence of predicted speed limit offset values for the vehicle at future locations on the route based on execution of the machine learning model on the received sensor data and the identified speed limit of the route, determine a range estimation of the vehicle based on a current amount of charge of a rechargeable battery of the vehicle and the generated sequence of predicted speed limit offset values for the vehicle at future locations on the route, and display the range estimation on a user interface within the vehicle.
A further example embodiment provides a computer readable storage medium that includes instructions, that when read by a processor, cause the processor to perform one or more of receiving sensor data from a hardware sensor of a vehicle, where the sensor data comprises values of a route sensed as the vehicle is travelling on the route, identifying a speed limit of the route, generating a sequence of predicted speed limit offset values for the vehicle at future locations on the route based on execution of a machine learning model on the received sensor data and the identified speed limit of the route, determining a range estimation of the vehicle based on a current amount of charge of a rechargeable battery of the vehicle and the generated sequence of predicted speed limit offset values for the vehicle at future locations on the route, and displaying the range estimation on a user interface within the vehicle.
It will be readily understood that the instant components, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of at least one of a method, apparatus, computer readable storage medium and system, as represented in the attached figures, is not intended to limit the scope of the application as claimed but is merely representative of selected embodiments. Multiple embodiments depicted herein are not intended to limit the scope of the solution. The computer-readable storage medium may be a non-transitory computer readable media or a non-transitory computer readable storage medium.
Communications between the vehicle(s) and certain entities, such as remote servers, other vehicles and local computing devices (e.g., smartphones, personal computers, vehicle-embedded computers, etc.) may be sent and/or received and processed by one or more ‘components’ which may be hardware, firmware, software or a combination thereof. The components may be part of any of these entities or computing devices or certain other computing devices. In one example, consensus decisions related to blockchain transactions may be performed by one or more computing devices or components (which may be any element described and/or depicted herein) associated with the vehicle(s) and one or more of the components outside or at a remote location from the vehicle(s).
The instant features, structures, or characteristics described in this specification may be combined in any suitable manner in one or more embodiments. For example, the usage of the phrases “example embodiments,” “some embodiments,” or other similar language, throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one example. Thus, appearances of the phrases “example embodiments”, “in some embodiments”, “in other embodiments,” or other similar language, throughout this specification can all refer to the same embodiment. Thus, these embodiments may work in conjunction with any of the other embodiments, may not be functionally separate, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the diagrams, any connection between elements can permit one-way and/or two-way communication, even if the depicted connection is a one-way or two-way arrow. In the current solution, a vehicle may include one or more of cars, trucks, Internal Combustion Engine (ICE) vehicles, battery electric vehicle (BEV), e-Palettes, fuel cell bus, motorcycles, scooters, bicycles, boats, recreational vehicles, planes, drones, Unmanned Aerial Vehicle (UAV) and any object that may be used to transport people and or goods from one location to another. In the diagrams, any connection between elements can permit one-way and/or two-way communication, even if the depicted connection is a one-way or two-way arrow. In the current solution, a vehicle may include one or more of cars, trucks, walking area battery electric vehicle (BEV), e-Palette, fuel cell bus, motorcycles, scooters, bicycles, boats, recreational vehicles, planes, and any object that may be used to transport people and or goods from one location to another.
In addition, while the term “message” may have been used in the description of embodiments, other types of network data, such as, a packet, frame, datagram, etc. may also be used. Furthermore, while certain types of messages and signaling may be depicted in exemplary embodiments they are not limited to a certain type of message and signaling.
Example embodiments provide methods, systems, components, non-transitory computer readable media, devices, and/or networks, which provide at least one of a transport (also referred to as a vehicle or car herein), a data collection system, a data monitoring system, a verification system, an authorization system, and a vehicle data distribution system. The vehicle status condition data received in the form of communication messages, such as wireless data network communications and/or wired communication messages, may be processed to identify vehicle status conditions and provide feedback on the condition and/or changes of a vehicle. In one example, a user profile may be applied to a particular vehicle to authorize a current vehicle event, service stops at service stations, to authorize subsequent vehicle rental services, and enable vehicle-to-vehicle communications.
Within the communication infrastructure, a decentralized database is a distributed storage system which includes multiple nodes that communicate with each other. A blockchain is an example of a decentralized database, which includes an append-only immutable data structure (i.e., a distributed ledger) capable of maintaining records between untrusted parties. The untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify the database records without a consensus being reached among the distributed peers. For example, the peers may execute a consensus protocol to validate blockchain storage entries, group the storage entries into blocks, and build a hash chain via the blocks. This process forms the ledger by ordering the storage entries, as is necessary, for consistency. In public or permissionless blockchains, anyone can participate without a specific identity. Public blockchains can involve crypto-currencies and use consensus-based on various protocols such as proof of work (PoW). Conversely, a permissioned blockchain database can secure interactions among a group of entities, which share a common goal, but which do not or cannot fully trust one another, such as businesses that exchange funds, goods, information, and the like. The instant solution can function in a permissioned and/or a permissionless blockchain setting.
Smart contracts are trusted distributed applications which leverage tamper-proof properties of the shared or distributed ledger (which may be in the form of a blockchain) and an underlying agreement between member nodes, which is referred to as an endorsement or endorsement policy. In general, blockchain entries are “endorsed” before being committed to the blockchain while entries, which are not endorsed are disregarded. A typical endorsement policy allows smart contract executable code to specify endorsers for an entry in the form of a set of peer nodes that are necessary for endorsement. When a client sends the entry to the peers specified in the endorsement policy, the entry is executed to validate the entry. After validation, the entries enter an ordering phase in which a consensus protocol produces an ordered sequence of endorsed entries grouped into blocks.
Nodes are the communication entities of the blockchain system. A “node” may perform a logical function in the sense that multiple nodes of different types can run on the same physical server. Nodes are grouped in trust domains and are associated with logical entities that control them in various ways. Nodes may include different types, such as a client or submitting-client node, which submits an entry-invocation to an endorser (e.g., peer), and broadcasts entry proposals to an ordering service (e.g., ordering node). Another type of node is a peer node, which can receive client submitted entries, commit the entries and maintain a state and a copy of the ledger of blockchain entries. Peers can also have the role of an endorser. An ordering-service-node or orderer is a node running the communication service for all nodes and which implements a delivery guarantee, such as a broadcast to each of the peer nodes in the system when committing entries and modifying a world state of the blockchain. The world state can constitute the initial blockchain entry, which normally includes control and setup information.
A ledger is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions may result from smart contract executable code invocations (i.e., entries) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). An entry may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain (also referred to as a chain), which stores an immutable, sequenced record in blocks. The ledger also includes a state database, which maintains a current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which they are a member.
A chain is an entry log structured as hash-linked blocks, and each block contains a sequence of N entries where N is equal to or greater than one. The block header includes a hash of the blocks' entries, as well as a hash of the prior block's header. In this way, all entries on the ledger may be sequenced and cryptographically linked together. Accordingly, it is not possible to tamper with the ledger data without breaking the hash links. A hash of a most recently added blockchain block represents every entry on the chain that has come before it, making it possible to ensure that all peer nodes are in a consistent and trusted state. The chain may be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), efficiently supporting the append-only nature of the blockchain workload.
The current state of the immutable ledger represents the latest values for all keys that are included in the chain entry log. Since the current state represents the latest key values known to a channel, it is sometimes referred to as a world state. Smart contract executable code invocations execute entries against the current state data of the ledger. To make these smart contract executable code interactions efficient, the latest values of the keys may be stored in a state database. The state database may be simply an indexed view into the chain's entry log and can therefore be regenerated from the chain at any time. The state database may automatically be recovered (or generated if needed) upon peer node startup and before entries are accepted.
A blockchain is different from a traditional database in that the blockchain is not a central storage but rather a decentralized, immutable, and secure storage, where nodes must share in changes to records in the storage. Some properties that are inherent in blockchain and which help implement the blockchain include, but are not limited to, an immutable ledger, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, and the like.
In some embodiments, a service to a particular vehicle and/or a user profile that is applied to the vehicle may be provided. For example, a user may be the owner of a vehicle or the operator of a vehicle owned by another party. The vehicle may require service at certain intervals, and the service needs may require authorization before permitting the services to be received. Also, service centers may offer services to vehicles in a nearby area based on the vehicle's current route plan and a relative level of service requirements (e.g., immediate, severe, intermediate, minor, etc.). The vehicle needs may be monitored via one or more vehicle and/or road sensors or cameras, which report sensed data to a central controller computer device in and/or apart from the vehicle. This data is forwarded to a management server for review and action. A sensor may be located on one or more of the interior of the vehicle, the exterior of the vehicle, on a fixed object apart from the vehicle, and on another vehicle proximate the vehicle. The sensor may also be associated with the vehicle's speed, the vehicle's braking, the vehicle's acceleration, fuel levels, service needs, the gear-shifting of the vehicle, the vehicle's steering, and the like. A sensor, as described herein, may also be a device, such as a wireless device in and/or proximate to the vehicle. Also, sensor information may be used to identify whether the vehicle is operating safely and whether an occupant has engaged in any unexpected vehicle conditions, such as during a vehicle access and/or utilization period. Vehicle information collected before, during and/or after a vehicle's operation may be identified and stored in a transaction on a shared/distributed ledger, which may be generated and committed to the immutable ledger as determined by a permission granting consortium, and thus in a “decentralized” manner, such as via a blockchain membership group.
Each interested party (i.e., owner, user, company, agency, etc.) may want to limit the exposure of private information, and therefore the blockchain and its immutability can be used to manage permissions for each particular user vehicle profile. A smart contract may be used to provide compensation, quantify a user profile score/rating/review, apply vehicle event permissions, determine when service is needed, identify a collision and/or degradation event, identify a safety concern event, identify parties to the event and provide distribution to registered entities seeking access to such vehicle event data. Also, the results may be identified, and the necessary information can be shared among the registered companies and/or individuals based on a consensus approach associated with the blockchain. Such an approach could not be implemented on a traditional centralized database.
Various driving systems of the instant solution can utilize software, an array of sensors as well as machine learning functionality, light detection and ranging (Lidar) projectors, radar, ultrasonic sensors, etc. to create a map of terrain and road that a vehicle can use for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors and the like can also be used in autonomous vehicles in place of Lidar.
The instant solution includes, in certain embodiments, authorizing a vehicle for service via an automated and quick authentication scheme. For example, driving up to a charging station or fuel pump may be performed by a vehicle operator or an autonomous vehicle and the authorization to receive charge or fuel may be performed without any delays provided the authorization is received by the service and/or charging station. A vehicle may provide a communication signal that provides an identification of a vehicle that has a currently active profile linked to an account that is authorized to accept a service, which can be later rectified by compensation. Additional measures may be used to provide further authentication, such as another identifier may be sent from the user's device wirelessly to the service center to replace or supplement the first authorization effort between the vehicle and the service center with an additional authorization effort.
Data shared and received may be stored in a database, which maintains data in one single database (e.g., database server) and generally at one particular location. This location is often a central computer, for example, a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored on a centralized database is typically accessible from multiple different points. A centralized database is easy to manage, maintain, and control, especially for purposes of security because of its single location. Within a centralized database, data redundancy is minimized as a single storing place of all data also implies that a given set of data only has one primary record. A blockchain may be used for storing vehicle-related data and transactions.
Any of the actions described herein may be performed by one or more processors (such as a microprocessor, a sensor, an Electronic Control Unit (ECU), a head unit, and the like), with or without memory, which may be located on-board the vehicle and/or or off-board the vehicle (such as a server, computer, mobile/wireless device, etc.). The one or more processors may communicate with other memory and/or other processors on-board or off-board other vehicles to utilize data being sent by and/or to the vehicle. The one or more processors and the other processors can send data, receive data, and utilize this data to perform one or more of the actions described or depicted herein.
As described herein, range estimation is a process of estimating how far a vehicle can travel (i.e., a driving distance, driving range, etc.) based on its battery capacity, also referred to as, a current state-of-charge (SOC) of the battery. In many cases, both the range estimation and the state of charge of the battery may be displayed on a dashboard within the electric vehicle.
One of the drawbacks of electric vehicles (EVs) is that current range estimation processes are not accurate. Recent road tests on vehicles from a number of different manufacturers showed that range estimations can be upwards of 20% off. One of the reasons for the lack of accuracy include a lack of standardization in the range estimation process. Other reasons for the lack of accuracy in the range estimation process are caused by dynamic context in the environment such as poor weather, high temperatures, poor driving habits, and the like. In many cases, these attributes can significantly impact the range of the vehicle. Othe reasons for the lack of accuracy include the differences in the way that drivers use their vehicles and the result it has on energy consumption. Some drivers may drive more careful, resulting in more energy being conserved, while others may drive more erratic resulting in less energy being conserved.
The example embodiments are directed to a machine learning system that can estimate the range of a vehicle based on contextual attributes of a driver and contextual attributes about the environment where the vehicle is being driven. In particular, a speed profile of a driver can be generated using machine learning. The speed profile may include contextual attributes of the driver's behavior such as how fast vehicle is moving over a sequence of points, the acceleration/deceleration of the vehicle over a sequence of points, how closely the driver follows the speed limit over a sequence of points, etc. Other contextual attributes may also be acquired, including a current roue of the vehicle, settings of equipment within the vehicle such as HVAC settings, windows, heated seats, etc., tire pressure, ambient temperature, and the like.
The speed profile and the other contextual attributes may be input to an energy consumption estimation model (such as another machine learning model), which can estimate the amount of energy that will be consumed by the vehicle over a plurality of successive points in the future based on the input speed profile and the contextual attributes. The amount of energy to be consumed can be used to calculate the estimated range of the electric vehicle. This information may be displayed on a dashboard within a vehicle. As another example, the estimated range may be used to plan a trip using a vehicle navigation software such as a GPS-based navigation system that displays a geographic map and a route within the map on a screen of a user interface of the navigation system.
The speed profile can be generated using different machine learning models, for example, an encoder-decoder model, a deep learning neural network, or the like. In some embodiments, the system may create multiple speed profiles using multiple different models and compare them to each other to generate a final speed profile. The system can use the contextual attributes to create a more accurate estimation of the range of the electric vehicle. Furthermore, by providing multiple different models, the results/outputs of the models can be compared and used in some combination such as by averaging the two, or taking one over the other.
Meanwhile, the indirect learning model 130 may indirectly learn from the driver's behavior, for example, the acceleration habits of the driver, the deceleration habits of the driver, a rate of speed with respect to a current speed limit, and the like. For example, the indirect learning model 130 may include a deep learning neural network, but embodiments are not limited thereto. This data may be used to build a second speed profile 130.
The speed profile 122 and the speed profile 132 may be transmitted to a range estimator module 140 which can generate a first estimate for an amount of energy to be consumed by the vehicle based on the first speed profile 122 and generate a second estimate for an amount of energy to be consumed by the vehicle based on the second speed profile 122. The range estimator 140 may also receive contextual attributes of the route, the ambient temperature, the status of vehicle equipment and systems, and the like, and use this information to estimate the energy consumption. For example, the range estimator 140 may include a machine learning model that can determine an amount of energy that will be consumed based on the speed profile and other attributes such as the route, the ambient temperature, vehicle status, etc. The estimated energy consumption can be used to generate an estimated range value 142.
In this example, the system 100 can improve the range estimation for an electric vehicle by generating a “speed profile” personalized to the driver of the vehicle based on a current route of the vehicle. The speed profile and the contextual attributes can be input to the range estimator to estimate the amount of energy that will be consumed over time. The estimated energy consumption can be input to a calculation unit that can estimate a range/total range left for the vehicle based on the battery from the estimated energy consumption and additional contextual attributes including information about the route to be traveled by the vehicle, power status of various equipment and devices in the vehicle, ambient air temperature, and the like. Furthermore, the calculation unit can estimate a range (e.g., distance) of travel available for the vehicle based on the current state of charge of the battery.
The encoder may receive the historical data points from the driving history database 152 as input and convert the input data into a vector that is input to the decoder. In response, the decoder may generate a sequence of predicted data points for the vehicle along the route that the vehicle will be travelling. Each data point 124 may include metadata 126 that includes predicted attributes about the vehicle (such as speed, etc.) at the data point.
However, the output from the indirect learning model 130 is different. Rather than identify the speed of the user directly, additional context is added to compare the speed to a speed limit of the road, etc. This provides the energy calculation model with additional context about the driver's driving habits that can affect the range of the battery.
In the example embodiments, the machine learning system 100 may store a driving history of the driver of the vehicle in the driving history database152 as shown in the example of
For example, given route information, a speed profile may be generated by using start-of-the-art machine learning models. By leveraging techniques such as federated learning and continual learning, a driver's contextual driving habits and preferences are also considered. The generated speed profile can be used by energy consumption models to improve the estimation of the range of the vehicle during the trip.
If a destination is given, the navigation system can provide candidates route and relevant attributes such as the speed limit of each segment, road type of each segment, distance to the next intersection/stop sign, number of lanes, etc. to the machine learning models as input. If real-time traffic information is available, it can also provide the average speed of each segment to the models as input. The easiest way to generate a speed profile is based on the speed limit (or real-time average speed, if available). Because the speed limit could be discontinuous (e.g., 40 mph in one segment and 70 mph in the next segment), some acceleration/deceleration value may be used to connect different segments.
The energy consumption estimation model 142 may receive the inputs (e.g., future route information, vehicle states, speed profile, etc.) and estimate the energy required to finish the trip. This energy model can be physical formula-based or machine learning-based model. The development of the energy model is not the focus of this invention. No matter what kind of model is used, the more accurate the input, the more accurate the output. The example embodiments are focused on generating an accurate speed profile to improve the estimation. To determine the remaining battery state of charge, the speed profile (from direct learning or indirect learning) may be used as the input of the energy consumption estimation model 142. This model can be a physical model (i.e., equations derived from physical laws and human expertise) or another machine learning model. The output from the energy consumption estimation model 142 is the energy that will be consumed along the route.
Furthermore, if the machine learning system 100 uses the direct learning model 120 and the indirect learning model 130 at the same time, (e.g., executed in parallel), the results may be combined in some way to generate a final range estimation value. For example, one way may be to average the two estimates. As another example, the models can output a confidence number, that can be used as a weight when generating the average. As another example, the model can be evaluated on the fly and the weight adjusted dynamically by a user.
Flow diagrams depicted herein, such as
It is important to note that all the flow diagrams and corresponding processes derived from
The instant solution can be used in conjunction with one or more types of vehicles: battery electric vehicles, hybrid vehicles, fuel cell vehicles, internal combustion engine vehicles and/or vehicles utilizing renewable sources.
Although depicted as single vehicles, processors and elements, a plurality of vehicles, processors and elements may be present. Information or communication can occur to and/or from any of the processors 204, 204′ and elements 230. For example, the mobile phone 220 may provide information to the processor 204, which may initiate the vehicle 202 to take an action, may further provide the information or additional information to the processor 204′, which may initiate the vehicle 202′ to take an action, may further provide the information or additional information to the mobile phone 220, the vehicle 222, and/or the computer 224. One or more of the applications, features, steps, solutions, etc., described and/or depicted herein may be utilized and/or provided by the instant elements.
The processor 204 performs one or more of receiving sensor data from a hardware sensor of a vehicle, where the sensor data comprises values of a route sensed as the vehicle is travelling on the route in 244C, identifying a speed limit of the route in 246C, generating a sequence of predicted speed limit offset values for the vehicle at future locations on the route based on execution of a machine learning model on the received sensor data and the identified speed limit of the route in 248C, determining a range estimation of the vehicle based on a current amount of charge of a rechargeable battery of the vehicle and the generated sequence of predicted speed limit offset values for the vehicle at future locations on the route in 250C, and displaying the range estimation on a user interface within the vehicle in 252C.
The processor 204 performs one or more of using a deep learning neural network to generate the sequence of predicted speed limit offset values in 244D, generating a sequence of predicted acceleration values for the vehicle at the future locations on the route based on execution of the machine learning model on the received sensor data and the identified speed limit of the route, and further determining the range estimation of the vehicle based on sequence of predicted acceleration values for the vehicle at the future locations on the route in 245D, determining the range estimation further comprises determining an estimated amount of energy needed to finish a trip along the route based on execution of a second machine learning model on the current amount of charge of the rechargeable battery and the generated sequence of predicted speed values at the future locations on the route in 246D, receiving one or more of a current setting of a heating ventilation and air conditioning (HVAC) setting within the vehicle and a tire pressure sensor value, and the determining further comprises determining the range estimation of the vehicle based on the one or more of the current HVAC setting and the tire pressure sensor value in 247D, training the machine learning model based on historical driving data of a user associated with the vehicle to generate a user-specific machine learning model, and the determining comprises determining the range estimation of the vehicle based on execution the user-specific machine learning model on the current amount of charge of the rechargeable battery and the generated sequence of predicted speed limit offset values for the vehicle at future locations on the route in 248D, generating a sequence of predicted speed values for the vehicle at the future locations on the route based on execution of a different machine learning model on the received sensor data, and determining a second range estimation of the vehicle based on the current amount of charge of the rechargeable battery and the generated sequence of predicted speed values at the future locations on the route in 249D, and generating a final range estimation based on a combination of the range estimation of the vehicle and the second range estimation of the vehicle, and the displaying comprises displaying the generated final range estimation in 250D.
While this example describes in detail only one vehicle 202, multiple such nodes may be connected to the blockchain 206. It should be understood that the vehicle 202 may include additional components and that some of the components described herein may be removed and/or modified without departing from a scope of the instant application. The vehicle 202 may have a computing device or a server computer, or the like, and may include a processor 204, which may be a semiconductor-based microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and/or another hardware device. Although a single processor 204 is depicted, it should be understood that the vehicle 202 may include multiple processors, multiple cores, or the like without departing from the scope of the instant application. The vehicle 202 could be a vehicle, server or any device with a processor and memory.
The processor 204 performs one or more of receiving a confirmation of an event from one or more elements described or depicted herein, wherein the confirmation comprises a blockchain consensus between peers represented by any of the elements 244E and executing a smart contract to record the confirmation on a blockchain-based on the blockchain consensus 246E. Consensus is formed between one or more of any element 230 and/or any element described or depicted herein, including a vehicle, a server, a wireless device, etc. In another example, the vehicle 202 can be one or more of any element 230 and/or any element described or depicted herein, including a server, a wireless device, etc.
The processors and/or computer readable media 242E may fully or partially reside in the interior or exterior of the vehicles. The steps or features stored in the computer readable media 242E may be fully or partially performed by any of the processors and/or elements in any order. Additionally, one or more steps or features may be added, omitted, combined, performed at a later time, etc.
Referring now to
The vehicle 302A sends data from the one or more sensors 304A to the machine learning subsystem 306A. The machine learning subsystem 306A provides the one or more sensor 304A data to the learning model 308A, which returns one or more predictions. The machine learning subsystem 306A sends one or more instructions to the vehicle 302A based on the predictions from the learning model 308A.
In a further embodiment, the vehicle 302A may send the one or more sensor 304A data to the machine learning training system 310A. In yet another example, the machine learning subsystem 306A may send the sensor 304A data to the machine learning subsystem 306A. One or more of the applications, features, steps, solutions, etc., described and/or depicted herein may utilize the machine learning network 400 as described herein.
The example embodiments may communicate with a host platform 320, as shown in the examples of
For example,
In this example, the host process 322 may control access to and execution of models that are stored within a model repository 323. For example, the models may include artificial intelligence (AI) models, machine learning models, neural networks, or the like. The system 300B may trigger the execution of a model from the model repository 323 via submission of a call to an application programming interface (API) 321 of the host process 322. The request may include an identifier of a model or models to be executed, a payload of data (e.g., to be input to the model during execution), and the like. The host process 322 may receive the call from the system 300B and retrieve the corresponding model from the model repository 323, deploy the model within a live runtime environment, execute the model on the input data, and return a result of the execution to the system 302. The result of the execution may include an output result from the execution of the model.
In some embodiments, the system 300B may provide feedback from the output provided by the model. For example, a user may input a confirmation that the prediction output by the model is correct or provide a notification that the model is incorrect. This information may be added to the results of execution and stored within a log 324. The log data may include an identifier of the input, an identifier of the output, an identifier of the model used, and feedback from the recipient. This information may be used to subsequently retrain the model, for example, using the model development environment shown in the example of
The system 300C may be used to design a model (via a user interface of the IDE), such as a machine learning model, etc. The model can then be executed/trained based on the training data established via the user interface. For example, the user interface may be used to build a new model. The training data for training such a new model may be provided from a training data store 325, which includes training samples from the web, from customers, and the like. Here, the model is executed on the training data via the host platform 320 to generate a result. The execution of the model causes the model to learn based on the input training data. When the model is fully trained, it may be stored within the model repository 323 via the IDE 340, or the like.
As another example, the IDE 340 may be used to retrain an existing model. Here, the training process may use executional results previously generated/output by the model 330 (including any feedback, etc.) to retrain the model 330. For example, predicted outputs that are identified as accurate, best, good, etc., may be distinguished from outputs that are inaccurate, incorrect, bad, etc. One or more of these types of outputs can be identified and used for retraining the model to help the model provide better outputs.
In the example of
In another example, the name of the object can be identified from a web page or a user interface 350 where the object is visible within a browser or the workspace 354 on the user device. A pop-up within the browser or the workspace 354 can be overlayed where the object is visible, which includes an option to navigate to the identified web page corresponding to the alternative object via a rule set.
Instead of breaking files into blocks stored on disks in a file system, the object storage 360 handles objects as discrete units of data stored in a structurally flat data environment. Here, the object storage may not use folders, directories, or complex hierarchies. Instead, each object may be a simple, self-contained repository that includes the data, the metadata, and the unique identifier that a client application 300C can use to locate and access it. In this case, the metadata is more descriptive than a file-based approach. The metadata can be customized with additional context that can later be extracted and leveraged for other purposes, such as data analytics.
The objects that are stored in the object storage 360 may be accessed via an application programming interface (API) 361. The API 361 may be a Hypertext Transfer Protocol (HTTP)-based RESTful API (also known as a RESTful Web service). The API 361 can be used by the client application 300C to query an object's metadata to locate the desired object (data) via the Internet from anywhere on any device. The API 361 may use HTTP commands such as “PUT” or “POST” to upload an object, “GET” to retrieve an object, “DELETE” to remove an object, and the like.
The object storage 360 may provide a directory 365 that uses the metadata of the objects to locate appropriate data files. The directory 365 may contain descriptive information about each object stored in the object storage 360, such as a name, a unique identifier, a creation timestamp, a collection name, etc. To query the object within the object storage 360, the client application 300C may submit a command, such as an HTTP command, with an identifier of the object 362, a payload, etc. The object storage 360 can store the actions and results described herein, including associating two or more lists of ranked assets with one another based on variables used by the two or more lists of ranked assets that have a correlation above a predetermined threshold.
The term ‘energy’, ‘electricity’, ‘power’, and the like may be used to denote any form of energy received, stored, used, shared, and/or lost by the vehicles(s). The energy may be referred to in conjunction with a voltage source and/or a current supply of charge provided from an entity to the vehicle(s) during a charge/use operation. Energy may also be in the form of fossil fuels (for example, for use with a hybrid vehicle) or via alternative power sources, including but not limited to lithium-based, nickel-based, hydrogen fuel cells, atomic/nuclear energy, fusion-based energy sources, and energy generated on-the-fly during an energy sharing and/or usage operation for increasing or decreasing one or more vehicles energy levels at a given time.
In one example, the charging station 406B manages the amount of energy transferred from the vehicle 402B such that there is sufficient charge remaining in the vehicle 402B to arrive at a destination. In one example, a wireless connection is used to wirelessly direct an amount of energy transfer between vehicles 408B, wherein the vehicles may both be in motion. In one embodiment, wireless charging may occur via a fixed charger and batteries of the vehicle in alignment with one another (such as a charging mat in a garage or parking space). In one example, an idle vehicle, such as a vehicle 402B (which may be autonomous) is directed to provide an amount of energy to a charging station 406B and return to the original location (for example, its original location or a different destination). In one example, a mobile energy storage unit (not shown) is used to collect surplus energy from at least one other vehicle 408B and transfer the stored surplus energy at a charging station 406B. In one example, factors determine an amount of energy to transfer to a charging station 406B, such as distance, time, as well as traffic conditions, road conditions, environmental/weather conditions, the vehicle's condition (weight, etc.), an occupant(s) schedule while utilizing the vehicle, a prospective occupant(s) schedule waiting for the vehicle, etc. In one example, the vehicle(s) 408B, the charging station(s) 406B and/or the electric grid(s) 404B can provide energy to the vehicle 402B.
In one embodiment, a location such as a building, a residence, or the like (not depicted), communicably coupled to one or more of the electric grid 404B, the vehicle 402B, and/or the charging station(s) 406B. The rate of electric flow to one or more of the location, the vehicle 402B, the other vehicle(s) 408B is modified, depending on external conditions, such as weather. For example, when the external temperature is extremely hot or extremely cold, raising the chance for an outage of electricity, the flow of electricity to a connected vehicle 402B/308B is slowed to help minimize the chance for an outage.
In one embodiment, vehicles 402B and 408B may be utilized as bidirectional vehicles. Bidirectional vehicles are those that may serve as mobile microgrids that can assist in the supplying of electrical power to the grid 404B and/or reduce the power consumption when the grid is stressed. Bidirectional vehicles incorporate bidirectional charging, which in addition to receiving a charge to the vehicle, the vehicle can take energy from the vehicle and “push” the energy back into the grid 404B, otherwise referred to as “V2G”. In bidirectional charging, the electricity flows both ways; to the vehicle and from the vehicle. When a vehicle is charged, alternating current (AC) electricity from the grid 404B is converted to direct current (DC). This may be performed by one or more of the vehicle's own converter or a converter on the charger 406B. The energy stored in the vehicle's batteries may be sent in an opposite direction back to the grid. The energy is converted from DC to AC through a converter usually located in the charger 406B, otherwise referred to as a bidirectional charger. Further, the instant solution as described and depicted with respect to
In one embodiment, anytime an electrical charge is given or received to/from a charging station and/or an electrical grid, the entities that allow that to occur are one or more of a vehicle, a charging station, a server, and a network communicably coupled to the vehicle, the charging station, and the electrical grid.
In one example, a vehicle 408C/404C can transport a person, an object, a permanently or temporarily affixed apparatus, and the like. In one example, the vehicle 408C may communicate with vehicle 404C via V2V communication through the computers associated with each vehicle 406C and 410C and may be referred to as a car, vehicle, automobile, and the like. The vehicle 404C/408C may be a self-propelled wheeled conveyance, such as a car, a sports utility vehicle, a truck, a bus, a van, or other motor or battery-driven or fuel cell-driven vehicle. For example, vehicle 404C/408C may be an electric vehicle, a hybrid vehicle, a hydrogen fuel cell vehicle, a plug-in hybrid vehicle, or any other type of vehicle with a fuel cell stack, a motor, and/or a generator. Other examples of vehicles include bicycles, scooters, trains, planes, boats, and any other form of conveyance that is capable of transportation. The vehicle 404C/408C may be semi-autonomous or autonomous. For example, vehicle 404C/408C may be self-maneuvering and navigate without human input. An autonomous vehicle may have and use one or more sensors and/or a navigation unit to drive autonomously. All of the data described or depicted herein can be stored, analyzed, processed and/or forwarded by one or more of the elements in
ECUs 410D, 408D, and Head Unit 406D may each include a custom security functionality element 414D defining authorized processes and contexts within which those processes are permitted to run. Context-based authorization to determine validity if a process can be executed allows ECUs to maintain secure operation and prevent unauthorized access from elements such as the vehicle's Controller Area Network (CAN Bus). When an ECU encounters a process that is unauthorized, that ECU can block the process from operating. Automotive ECUs can use different contexts to determine whether a process is operating within its permitted bounds, such as proximity contexts such as nearby objects, distance to approaching objects, speed, and trajectory relative to other moving objects, and operational contexts such as an indication of whether the vehicle is moving or parked, the vehicle's current speed, the transmission state, user-related contexts such as devices connected to the transport via wireless protocols, use of the infotainment, cruise control, parking assist, driving assist, location-based contexts, and/or other contexts.
Referring to
The processor 420E includes an arithmetic logic unit, a microprocessor, a general-purpose controller, and/or a similar processor array to perform computations and provide electronic display signals to a display unit 426E. The processor 420E processes data signals and may include various computing architectures, including a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture implementing a combination of instruction sets. The vehicle 410E may include one or more processors 420E. Other processors, operating systems, sensors, displays, and physical configurations that are communicably coupled to one another (not depicted) may be used with the instant solution.
Memory 422E is a non-transitory memory storing instructions or data that may be accessed and executed by the processor 420E. The instructions and/or data may include code to perform the techniques described herein. The memory 422E may be a dynamic random-access memory (DRAM) device, a static random-access memory (SRAM) device, flash memory, or another memory device. In some embodiments, the memory 422E also may include non-volatile memory or a similar permanent storage device and media, which may include a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other mass storage device for storing information on a permanent basis. A portion of the memory 422E may be reserved for use as a buffer or virtual random-access memory (virtual RAM). The vehicle 410E may include one or more memories 422E without deviating from the current solution.
The memory 422E of the vehicle 410E may store one or more of the following types of data: navigation route data 418E, and autonomous features data 416E. In some embodiments, the memory 422E stores data that may be necessary for the navigation application 418E to provide the functions.
The navigation system 418E may describe at least one navigation route including a start point and an endpoint. In some embodiments, the navigation system 418E of the vehicle 410E receives a request from a user for navigation routes wherein the request includes a starting point and an ending point. The navigation system 418E may query a real-time data server 404E (via a network 402E), such as a server that provides driving directions, for navigation route data corresponding to navigation routes, including the start point and the endpoint. The real-time data server 404E transmits the navigation route data to the vehicle 410E via a wireless network 402E, and the communication system 424E stores the navigation data 418E in the memory 422E of the vehicle 410E.
The ECU 414E controls the operation of many of the systems of the vehicle 410E, including the ADAS systems 416E. The ECU 414E may, responsive to instructions received from the navigation system 418E, deactivate any unsafe and/or unselected autonomous features for the duration of a journey controlled by the ADAS systems 416E. In this way, the navigation system 418E may control whether ADAS systems 416E are activated or enabled so that they may be activated for a given navigation route.
The sensor set 412E may include any sensors in the vehicle 410E generating sensor data. For example, the sensor set 412E may include short-range sensors and long-range sensors. In some embodiments, the sensor set 412E of the vehicle 410E may include one or more of the following vehicle sensors: a camera, a Lidar sensor, an ultrasonic sensor, an automobile engine sensor, a radar sensor, a laser altimeter, a manifold absolute pressure sensor, an infrared detector, a motion detector, a thermostat, a sound detector, a carbon monoxide sensor, a carbon dioxide sensor, an oxygen sensor, a mass airflow sensor, an engine coolant temperature sensor, a throttle position sensor, a crankshaft position sensor, a valve timer, an air-fuel ratio meter, a blind spot meter, a curb feeler, a defect detector, a Hall effect sensor, a parking sensor, a radar gun, a speedometer, a speed sensor, a tire-pressure monitoring sensor, a torque sensor, a transmission fluid temperature sensor, a turbine speed sensor (TSS), a variable reluctance sensor, a vehicle speed sensor (VSS), a water sensor, a wheel speed sensor, a GPS sensor, a mapping functionality, and any other type of automotive sensor. The navigation system 418E may store the sensor data in the memory 422E.
The communication unit 424E transmits and receives data to and from the network 420E or to another communication channel. In some embodiments, the communication unit 424E may include a DSRC transceiver, a DSRC receiver, and other hardware or software necessary to make the vehicle 410E a DSRC-equipped device.
The vehicle 410E may interact with other vehicles 406E via V2V technology. V2V communication includes sensing radar information corresponding to relative distances to external objects, receiving GPS information of the vehicles, setting areas as areas where the other vehicles 406E are located based on the sensed radar information, calculating probabilities that the GPS information of the object vehicles will be located at the set areas, and identifying vehicles and/or objects corresponding to the radar information and the GPS information of the object vehicles based on the calculated probabilities, in one example.
For a vehicle to be adequately secured, the vehicle must be protected from unauthorized physical access as well as unauthorized remote access (e.g., cyber-threats). To prevent unauthorized physical access, a vehicle is equipped with a secure access system such as a keyless entry in one example. Meanwhile, security protocols are added to a vehicle's computers and computer networks to facilitate secure remote communications to and from the vehicle in one example.
Electronic Control Units (ECUs) are nodes within a vehicle that control tasks such as activating the windshield wipers to tasks such as an anti-lock brake system. ECUs are often connected to one another through the vehicle's central network, which may be referred to as a controller area network (CAN). State-of-the-art features such as autonomous driving are strongly reliant on implementing new, complex ECUs such as advanced driver-assistance systems (ADAS), sensors, and the like. While these new technologies have helped improve the safety and driving experience of a vehicle, they have also increased the number of externally-communicating units inside of the vehicle, making them more vulnerable to attack. Below are some examples of protecting the vehicle from physical intrusion and remote intrusion.
In one embodiment, a CAN includes a CAN bus with a high and low terminal and a plurality of electronic control units (ECUs), which are connected to the CAN bus via wired connections. The CAN bus is designed to allow microcontrollers and devices to communicate with each other in an application without a host computer. The CAN bus implements a message-based protocol (i.e., ISO 11898 standards) that allows ECUs to send commands to one another at a root level. Meanwhile, the ECUs represent controllers for controlling electrical systems or subsystems within the vehicle. Examples of the electrical systems include power steering, anti-lock brakes, air-conditioning, tire pressure monitoring, cruise control, and many other features.
In this example, the ECU includes a transceiver and a microcontroller. The transceiver may be used to transmit and receive messages to and from the CAN bus. For example, the transceiver may convert the data from the microcontroller into a format of the CAN bus and also convert data from the CAN bus into a format for the microcontroller. Meanwhile, the microcontroller interprets the messages and also decide what messages to send using ECU software installed therein in one example.
To protect the CAN from cyber threats, various security protocols may be implemented. For example, sub-networks (e.g., sub-networks A and B, etc.) may be used to divide the CAN into smaller sub-CANs and limit an attacker's capabilities to access the vehicle remotely. In one embodiment, a firewall (or gateway, etc.) may be added to block messages from crossing the CAN bus across sub-networks. If an attacker gains access to one sub-network, the attacker will not have access to the entire network. To make sub-networks even more secure, the most critical ECUs are not placed on the same sub-network, in one example.
In addition to protecting a vehicle's internal network, vehicles may also be protected when communicating with external networks such as the Internet. One of the benefits of having a vehicle connection to a data source such as the Internet is that information from the vehicle can be sent through a network to remote locations for analysis. Examples of vehicle information include GPS, onboard diagnostics, tire pressure, and the like. These communication systems are often referred to as telematics because they involve the combination of telecommunications and informatics. Further, the instant solution as described and depicted can be utilized in this and other networks and/or systems, including those that are described and depicted herein.
Upon receiving the communications from each other, the vehicles may verify the signatures with a certificate authority 4061 or the like. For example, the vehicle 408I may verify with the certificate authority 4061 that the public key certificate 404I used by vehicle 402I to sign a V2V communication is authentic. If the vehicle 408I successfully verifies the public key certificate 404I, the vehicle knows that the data is from a legitimate source. Likewise, the vehicle 402I may verify with the certificate authority 4061 that the public key certificate 410I used by the vehicle 408I to sign a V2V communication is authentic. Further, the instant solution as described and depicted with respect to
In some embodiments, a computer may include security processor. In particular, the security processor may perform authorization, authentication, cryptography (e.g., encryption), and the like, for data transmissions that are sent between ECUs and other devices on a CAN bus of a vehicle, and also data messages that are transmitted between different vehicles. The security processor may include an authorization module, an authentication module, and a cryptography module. The security processor may be implemented within the vehicle's computer and may communicate with other vehicle elements, for example, the ECUs/CAN network, wired and wireless devices such as wireless network interfaces, input ports, and the like. The security processor may ensure that data frames (e.g., CAN frames, etc.) that are transmitted internally within a vehicle (e.g., via the ECUs/CAN network) are secure. Likewise, the security processor can ensure that messages transmitted between different vehicles and devices attached or connected via a wire to the vehicle's computer are also secured.
For example, the authorization module may store passwords, usernames, PIN codes, biometric scans, and the like for different vehicle users. The authorization module may determine whether a user (or technician) has permission to access certain settings such as a vehicle's computer. In some embodiments, the authorization module may communicate with a network interface to download any necessary authorization information from an external server. When a user desires to make changes to the vehicle settings or modify technical details of the vehicle via a console or GUI within the vehicle or via an attached/connected device, the authorization module may require the user to verify themselves in some way before such settings are changed. For example, the authorization module may require a username, a password, a PIN code, a biometric scan, a predefined line drawing or gesture, and the like. In response, the authorization module may determine whether the user has the necessary permissions (access, etc.) being requested.
The authentication module may be used to authenticate internal communications between ECUs on the CAN network of the vehicle. As an example, the authentication module 308J may provide information for authenticating communications between the ECUS. As an example, the authentication module may transmit a bit signature algorithm to the ECUs of the CAN network. The ECUs may use the bit signature algorithm to insert authentication bits into the CAN fields of the CAN frame. All ECUs on the CAN network typically receive each CAN frame. The bit signature algorithm may dynamically change the position, amount, etc., of authentication bits each time a new CAN frame is generated by one of the ECUs. The authentication module may also provide a list of ECUs that are exempt (safe list) and that do not need to use the authentication bits. The authentication module may communicate with a remote server to retrieve updates to the bit signature algorithm and the like.
The encryption module may store asymmetric key pairs to be used by the vehicle to communicate with other external user devices and vehicles. For example, the encryption module may provide a private key to be used by the vehicle to encrypt/decrypt communications, while the corresponding public key may be provided to other user devices and vehicles to enable the other devices to decrypt/encrypt the communications. The encryption module may communicate with a remote server to receive new keys, updates to keys, keys of new vehicles, users, etc., and the like. The encryption module may also transmit any updates to a local private/public key pair to the remote server.
In one embodiment, a vehicle may engage with another vehicle to perform various actions such as to share, transfer, acquire service calls, etc. when the vehicle has reached a status where the services need to be shared with another vehicle. For example, the vehicle may be due for a battery charge and/or may have an issue with a tire and may be in route to pick up a package for delivery. A vehicle processor resides in the vehicle and communication exists between the vehicle processor, a first database, and a transaction module. The vehicle may notify another vehicle, which is in its network and which operates on its blockchain member service. A vehicle processor resides in the another vehicle and communication exists between the vehicle processor, a second database, the vehicle processor and a transaction module. The another vehicle may then receive the information via a wireless communication request to perform the package pickup from the vehicle and/or from a server (not shown). The transactions are logged in the transaction modules and of both vehicles. The credits are transferred from vehicle to the another vehicle and the record of the transferred service is logged in the first and databases, assuming that the blockchains are different from one another, or are logged in the same blockchain used by all members. The first database can be one of a SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and may be on board the vehicle, may be off-board the vehicle, may be accessible directly and/or through a network.
The blockchain transactions 520 are stored in memory of computers as the transactions are received and approved by the consensus model dictated by the members' nodes. Approved transactions 526 are stored in current blocks of the blockchain and committed to the blockchain via a committal procedure, which includes performing a hash of the data contents of the transactions in a current block and referencing a previous hash of a previous block. Within the blockchain, one or more smart contracts 530 may exist that define the terms of transaction agreements and actions included in smart contract executable application code 532, such as registered recipients, vehicle features, requirements, permissions, sensor thresholds, etc. The code may be configured to identify whether requesting entities are registered to receive vehicle services, what service features they are entitled/required to receive given their profile statuses and whether to monitor their actions in subsequent events. For example, when a service event occurs and a user is riding in the vehicle, the sensor data monitoring may be triggered, and a certain parameter, such as a vehicle charge level, may be identified as being above/below a particular threshold for a particular period of time, then the result may be a change to a current status, which requires an alert to be sent to the managing party (i.e., vehicle owner, vehicle operator, server, etc.) so the service can be identified and stored for reference. The vehicle sensor data collected may be based on types of sensor data used to collect information about vehicle's status. The sensor data may also be the basis for the vehicle event data 534, such as a location(s) to be traveled, an average speed, a top speed, acceleration rates, whether there were any collisions, was the expected route taken, what is the next destination, whether safety measures are in place, whether the vehicle has enough charge/fuel, etc. All such information may be the basis of smart contract terms 530, which are then stored in a blockchain. For example, sensor thresholds stored in the smart contract can be used as the basis for whether a detected service is necessary and when and where the service should be performed.
In one embodiment, a blockchain logic example includes a blockchain application interface as an API or plug-in application that links to the computing device and execution platform for a particular transaction. The blockchain configuration may include one or more applications, which are linked to application programming interfaces (APIs) to access and execute stored program/application code (e.g., smart contract executable code, smart contracts, etc.), which can be created according to a customized configuration sought by participants and can maintain their own state, control their own assets, and receive external information. This can be deployed as an entry and installed, via appending to the distributed ledger, on all blockchain nodes.
The smart contract application code provides a basis for the blockchain transactions by establishing application code, which when executed causes the transaction terms and conditions to become active. The smart contract, when executed, causes certain approved transactions to be generated, which are then forwarded to the blockchain platform. The platform includes a security/authorization, computing devices, which execute the transaction management and a storage portion as a memory that stores transactions and smart contracts in the blockchain.
The blockchain platform may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environment, etc.), and underpinning physical computer infrastructure that may be used to receive and store new entries and provide access to auditors, which are seeking to access data entries. The blockchain may expose an interface that provides access to the virtual execution environment necessary to process the program code and engage the physical infrastructure. Cryptographic trust services may be used to verify entries such as asset exchange entries and keep information private.
The blockchain architecture configuration of
Within smart contract executable code, a smart contract may be created via a high-level application and programming language, and then written to a block in the blockchain. The smart contract may include executable code that is registered, stored, and/or replicated with a blockchain (e.g., distributed network of blockchain peers). An entry is an execution of the smart contract code, which can be performed in response to conditions associated with the smart contract being satisfied. The executing of the smart contract may trigger a trusted modification(s) to a state of a digital blockchain ledger. The modification(s) to the blockchain ledger caused by the smart contract execution may be automatically replicated throughout the distributed network of blockchain peers through one or more consensus protocols.
The smart contract may write data to the blockchain in the format of key-value pairs. Furthermore, the smart contract code can read the values stored in a blockchain and use them in application operations. The smart contract code can write the output of various logic operations into the blockchain. The code may be used to create a temporary data structure in a virtual machine or other computing platform. Data written to the blockchain can be public and/or can be encrypted and maintained as private. The temporary data that is used/generated by the smart contract is held in memory by the supplied execution environment, then deleted once the data needed for the blockchain is identified.
A smart contract executable code may include the code interpretation of a smart contract, with additional features. As described herein, the smart contract executable code may be program code deployed on a computing network, where it is executed and validated by chain validators together during a consensus process. The smart contract executable code receives a hash and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor. If the hashes of the hash identifier and the hash created from the stored identifier template data match, then the smart contract executable code sends an authorization key to the requested service. The smart contract executable code may write to the blockchain data associated with the cryptographic details.
The instant system includes a blockchain that stores immutable, sequenced records in blocks, and a state database (current world state) maintaining a current state of the blockchain. One distributed ledger may exist per channel and each peer maintains its own copy of the distributed ledger for each channel of which they are a member. The instant blockchain is an entry log, structured as hash-linked blocks where each block contains a sequence of N entries. Blocks may include various components such as those shown in
The current state of the blockchain and the distributed ledger may be stored in the state database. Here, the current state data represents the latest values for all keys ever included in the chain entry log of the blockchain. Smart contract executable code invocations execute entries against the current state in the state database. To make these smart contract executable code interactions extremely efficient, the latest values of all keys are stored in the state database. The state database may include an indexed view into the entry log of the blockchain, it can therefore be regenerated from the chain at any time. The state database may automatically get recovered (or generated if needed) upon peer startup, before entries are accepted.
Endorsing nodes receive entries from clients and endorse the entry based on simulated results. Endorsing nodes hold smart contracts, which simulate the entry proposals. When an endorsing node endorses an entry, the endorsing nodes creates an entry endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated entry. The method of endorsing an entry depends on an endorsement policy that may be specified within smart contract executable code. An example of an endorsement policy is “the majority of endorsing peers must endorse the entry.” Different channels may have different endorsement policies. Endorsed entries are forward by the client application to an ordering service.
The ordering service accepts endorsed entries, orders them into a block, and delivers the blocks to the committing peers. For example, the ordering service may initiate a new block when a threshold of entries has been reached, a timer times out, or another condition. In this example, blockchain node is a committing peer that has received a data block 582A for storage on the blockchain. The ordering service may be made up of a cluster of orderers. The ordering service does not process entries, smart contracts, or maintain the shared ledger. Rather, the ordering service may accept the endorsed entries and specifies the order in which those entries are committed to the distributed ledger. The architecture of the blockchain network may be designed such that the specific implementation of ‘ordering’ (e.g., Solo, Kafka, BFT, etc.) becomes a pluggable component.
Entries are written to the distributed ledger in a consistent order. The order of entries is established to ensure that the updates to the state database are valid when they are committed to the network. Unlike a cryptocurrency blockchain system (e.g., Bitcoin, etc.) where ordering occurs through the solving of a cryptographic puzzle, or mining, in this example the parties of the distributed ledger may choose the ordering mechanism that best suits that network.
Referring to
The block data 590A may store entry information of each entry that is recorded within the block. For example, the entry data may include one or more of a type of the entry, a version, a timestamp, a channel ID of the distributed ledger, an entry ID, an epoch, a payload visibility, a smart contract executable code path (deploy tx), a smart contract executable code name, a smart contract executable code version, input (smart contract executable code and functions), a client (creator) identify such as a public key and certificate, a signature of the client, identities of endorsers, endorser signatures, a proposal hash, smart contract executable code events, response status, namespace, a read set (list of key and version read by the entry, etc.), a write set (list of key and value, etc.), a start key, an end key, a list of keys, a Merkel tree query summary, and the like. The entry data may be stored for each of the N entries.
In some embodiments, the block data 590A may also store transaction-specific data 586A, which adds additional information to the hash-linked chain of blocks in the blockchain. Accordingly, the data 586A can be stored in an immutable log of blocks on the distributed ledger. Some of the benefits of storing such data 586A are reflected in the various embodiments disclosed and depicted herein. The block metadata 588A may store multiple fields of metadata (e.g., as a byte array, etc.). Metadata fields may include signature on block creation, a reference to a last configuration block, an entry filter identifying valid and invalid entries within the block, last offset persisted of an ordering service that ordered the block, and the like. The signature, the last configuration block, and the orderer metadata may be added by the ordering service. Meanwhile, a committer of the block (such as a blockchain node) may add validity/invalidity information based on an endorsement policy, verification of read/write sets, and the like. The entry filter may include a byte array of a size equal to the number of entries in the block data 510A and a validation code identifying whether an entry was valid/invalid.
The other blocks 582B to 582n in the blockchain also have headers, files, and values. However, unlike the first block 582A, each of the headers 584A to 584n in the other blocks includes the hash value of an immediately preceding block. The hash value of the immediately preceding block may be just the hash of the header of the previous block or may be the hash value of the entire previous block. By including the hash value of a preceding block in each of the remaining blocks, a trace can be performed from the Nth block back to the genesis block (and the associated original file) on a block-by-block basis, as indicated by arrows 592, to establish an auditable and immutable chain-of-custody.
The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination of the above. A computer program may be embodied on a computer readable media, such as a storage medium. For example, a computer program may reside in random access memory (“RAM”), flash memory, read-only memory (“ROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, hard disk, a removable disk, a compact disk read-only memory (“CD-ROM”), or any other form of storage medium known in the art.
An exemplary storage medium may be coupled to the processor such that the processor may read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application-specific integrated circuit (“ASIC”). In the alternative, the processor and the storage medium may reside as discrete components. For example,
The distributed ledger 520E includes a blockchain which stores immutable, sequenced records in blocks, and a state database 524E (current world state) maintaining a current state of the blockchain 522E. One distributed ledger 520E may exist per channel and each peer maintains its own copy of the distributed ledger 520E for each channel of which they are a member. The blockchain 522E is a transaction log, structured as hash-linked blocks where each block contains a sequence of N transactions. The linking of the blocks (shown by arrows in
The current state of the blockchain 522E and the distributed ledger 522E may be stored in the state database 524E. Here, the current state data represents the latest values for all keys ever included in the chain transaction log of the blockchain 522E. Chaincode invocations execute transactions against the current state in the state database 524E. To make these chaincode interactions extremely efficient, the latest values of all keys are stored in the state database 524E. The state database 524E may include an indexed view into the transaction log of the blockchain 522E, it can therefore be regenerated from the chain at any time. The state database 524E may automatically get recovered (or generated if needed) upon peer startup, before transactions are accepted.
Endorsing nodes receive transactions from clients and endorse the transaction based on simulated results. Endorsing nodes hold smart contracts which simulate the transaction proposals. When an endorsing node endorses a transaction, the endorsing nodes creates a transaction endorsement which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated transaction. The method of endorsing a transaction depends on an endorsement policy which may be specified within chaincode. An example of an endorsement policy is “the majority of endorsing peers must endorse the transaction.” Different channels may have different endorsement policies. Endorsed transactions are forward by the client application to ordering service 510E.
The ordering service 510E accepts endorsed transactions, orders them into a block, and delivers the blocks to the committing peers. For example, the ordering service 510E may initiate a new block when a threshold of transactions has been reached, a timer times out, or another condition. In the example of
The ordering service 510E may be made up of a cluster of orderers. The ordering service 510E does not process transactions, smart contracts, or maintain the shared ledger. Rather, the ordering service 510E may accept the endorsed transactions and specifies the order in which those transactions are committed to the distributed ledger 520E. The architecture of the blockchain network may be designed such that the specific implementation of ‘ordering’ (e.g., Solo, Kafka, BFT, etc.) becomes a pluggable component.
Transactions are written to the distributed ledger 520E in a consistent order. The order of transactions is established to ensure that the updates to the state database 524E are valid when they are committed to the network. Unlike a cryptocurrency blockchain system (e.g., Bitcoin, etc.) where ordering occurs through the solving of a cryptographic puzzle, or mining, in this example the parties of the distributed ledger 520E may choose the ordering mechanism that best suits that network.
When the ordering service 510E initializes a new data block 530E, the new data block 530E may be broadcast to committing peers (e.g., blockchain nodes 511E, 512E, and 513E). In response, each committing peer validates the transaction within the new data block 530E by checking to make sure that the read set and the write set still match the current world state in the state database 524E. Specifically, the committing peer can determine whether the read data that existed when the endorsers simulated the transaction is identical to the current world state in the state database 524E. When the committing peer validates the transaction, the transaction is written to the blockchain 522E on the distributed ledger 520E, and the state database 524E is updated with the write data from the read-write set. If a transaction fails, that is, if the committing peer finds that the read-write set does not match the current world state in the state database 524E, the transaction ordered into a block will still be included in that block, but it will be marked as invalid, and the state database 524E will not be updated.
Referring to
The block data 550 may store transactional information of each transaction that is recorded within the new data block 530. For example, the transaction data may include one or more of a type of the transaction, a version, a timestamp, a channel ID of the distributed ledger 520E, a transaction ID, an epoch, a payload visibility, a chaincode path (deploy tx), a chaincode name, a chaincode version, input (chaincode and functions), a client (creator) identify such as a public key and certificate, a signature of the client, identities of endorsers, endorser signatures, a proposal hash, chaincode events, response status, namespace, a read set (list of key and version read by the transaction, etc.), a write set (list of key and value, etc.), a start key, an end key, a list of keys, a Merkel tree query summary, and the like. The transaction data may be stored for each of the N transactions.
In one embodiment, block 563 may include one or more of receiving sensor data from a hardware sensor of a vehicle, where the sensor data comprises values of a route sensed as the vehicle is travelling on the route, identifying a speed limit of the route, generating a sequence of predicted speed limit offset values for the vehicle at future locations on the route based on execution of a machine learning model on the received sensor data and the identified speed limit of the route, determining a range estimation of the vehicle based on a current amount of charge of a rechargeable battery of the vehicle and the generated sequence of predicted speed limit offset values for the vehicle at future locations on the route, and displaying the range estimation on a user interface within the vehicle.
Although in
The block metadata 560 may store multiple fields of metadata (e.g., as a byte array, etc.). Metadata fields may include signature on block creation, a reference to a last configuration block, a transaction filter identifying valid and invalid transactions within the block, last offset persisted of an ordering service that ordered the block, and the like. The signature, the last configuration block, and the orderer metadata may be added by the ordering service 510E. Meanwhile, a committer of the block (such as blockchain node 512E) may add validity/invalidity information based on an endorsement policy, verification of read/write sets, and the like. The transaction filter may include a byte array of a size equal to the number of transactions in the block data 500D and a validation code identifying whether a transaction was valid/invalid.
In computing node 600 there is a computer system/server 602, which is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with computer system/server 602 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like.
Computer system/server 602 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computer system/server 602 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.
As shown in
The bus represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnects (PCI) bus.
Computer system/server 602 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server 602, and it includes both volatile and non-volatile media, removable and non-removable media. System memory 606, in one example, implements the flow diagrams of the other figures. The system memory 606 can include computer system readable media in the form of volatile memory, such as random-access memory (RAM) 608 and/or cache memory 610. Computer system/server 602 may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, memory 606 can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a “hard drive”). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such instances, each can be connected to the bus by one or more data media interfaces. As will be further depicted and described below, memory 606 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of various embodiments of the application.
Program/utility, having a set (at least one) of program modules, may be stored in memory 606 by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules generally carry out the functions and/or methodologies of various embodiments of the application as described herein.
As will be appreciated by one skilled in the art, aspects of the present application may be embodied as a system, method, or computer program product. Accordingly, aspects of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present application may take the form of a computer program product embodied in one or more computer readable media(s) having computer readable program code embodied thereon.
Computer system/server 602 may also communicate with one or more external devices via an I/O device 612 (such as an I/O adapter), which may include a keyboard, a pointing device, a display, a voice recognition module, etc., one or more devices that enable a user to interact with computer system/server 602, and/or any devices (e.g., network card, modem, etc.) that enable computer system/server 602 to communicate with one or more other computing devices. Such communication can occur via I/O interfaces of the device 612. Still yet, computer system/server 602 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via a network adapter. As depicted, device 612 communicates with the other components of computer system/server 602 via a bus. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with computer system/server 602. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.
In one embodiment, onboard processing power is leveraged to perform real-time analysis of sensor data and generate speed profiles without relying on cloud-based systems. This would reduce latency and enhance the system's responsiveness to changing driving conditions.
In one embodiment, vehicles incorporate driver biometric sensors to assess factors like driver stress levels, fatigue, and health conditions. These inputs could be integrated into the range estimation system to provide a more personalized and adaptive approach to energy consumption prediction.
In one embodiment, the system includes hardware sensors within the vehicle, such as GPS, speed sensors, and battery state-of-charge sensors. These sensors can provide real-time data about the vehicle's location, speed, and battery charge level. The data is transmitted to the system for further processing. The instant solution involves the use of a machine learning model, preferably an encoder-decoder neural network, to generate a sequence of predicted speed values for the vehicle at future locations on the route. The machine learning model must be sufficiently trained and calibrated to convert the received sensor data into accurate speed predictions, including geographical location and other contextual attributes. The instant solution determines the range estimation of the vehicle that requires a calculation unit that considers the current state-of-charge (SOC) of the rechargeable battery and the predicted speed values at future locations on the route. An energy consumption estimation model, which could be physical or machine learning-based, is integrated into the system to calculate the energy needed to complete the trip.
In one embodiment, the system is equipped to receive sensor data from various hardware sensors within the vehicle. These sensors may include GPS, speed sensors, and other data sources that provide information about the vehicle's current route and performance. The system can identify the speed limit of the route where the vehicle is traveling. This can be achieved through geographical location data within the received sensor data, such as GPS coordinates that correspond to specific road segments with known speed limits. A machine learning model, such as a deep learning neural network, should be employed to process the received sensor data and the identified speed limit of the route, including an input layer to handle the input data, one or more hidden layers for processing, and an output layer responsible for generating predicted speed limit offset values for future locations on the route. To determine the range estimation, the method considers the current amount of charge in the vehicle's rechargeable battery. This involves continuously monitoring the battery's state-of-charge (SOC). The system calculates an estimated amount of energy needed to complete the trip, which may be based on the predicted speed limit offset values, vehicle acceleration patterns, and other factors. This estimation can be performed using a second machine learning model or physical models.
In one embodiment, the instant solution employs a deep learning architecture consisting of multiple layers of artificial neural networks. These layers include an input layer, one or more hidden layers, and an output layer. The deep learning model is designed to handle the input data effectively and produce accurate predictions. The input layer of the deep learning neural network is configured to receive the sequence of predicted speed limit offset values for the vehicle at future locations on the route. This input data is preprocessed to ensure it is in a format suitable for the neural network's requirements. The neural network includes one or more hidden layers responsible for processing the input data and extracting relevant features. The configuration of these hidden layers, including the number of neurons and the choice of activation functions, are determined through experimentation and optimization to achieve accurate predictions. The output layer of the neural network is designed to output an average speed limit offset. This layer's architecture aligns with the specific goal of generating an average offset value based on the predicted speed limit offset values for future locations on the route.
The model executes a rigorous training process involving iteratively adjusting the model's internal parameters (weights and biases) to minimize prediction errors. Optimization techniques like gradient descent are employed to fine-tune the model. The trained model is capable of real-time inference, allowing it to process incoming sensor data and generate predictions promptly
The instant solution identifies the speed limit of the route where the vehicle is traveling. This can be achieved through the analysis of geographical location data within the received sensor data, such as GPS coordinates linked to specific road segments with known speed limits. The system makes effective use of the sensor data received from various hardware sensors within the vehicle. These sensors may include GPS, speed sensors, and others that provide essential information about the vehicle's current route and performance. To predict acceleration values, a machine learning model is employed that considers the identified speed limit of the route as a key input feature. The sensor data and the identified speed limit are preprocessed to ensure it is in a suitable format for input into the machine learning model. This preprocessing may involve data normalization, scaling, and feature extraction. The machine learning model is configured to generate a sequence of predicted acceleration values for the vehicle at future locations on the route. The model's architecture, including the number of layers and neurons, is designed to effectively capture the relationships between input data, speed limits, and predicted accelerations. Adequate training data is available for the machine learning model to learn patterns and make accurate predictions. Historical sensor data containing known acceleration values, corresponding speed limits, and route information is used for model training. The model undergoes a thorough training process involving the adjustment of internal parameters (weights and biases) to minimize prediction errors. Training involves techniques such as gradient descent and backpropagation. After training, the model is validated and tested using separate datasets to assess its ability to generalize and make accurate predictions on unseen data.
In one embodiment, the instant solution incorporates an energy consumption estimation model. Depending on the chosen approach, This model can be machine learning-based or physical formula-based. Continuous monitoring of the vehicle's battery SOC is vital. This involves real-time tracking of the current amount of charge in the rechargeable battery. Accurate SOC data is crucial for precise energy consumption estimation. The system considers various input data, including the predicted speed values, acceleration values (if available), and other relevant contextual attributes such as HVAC settings, tire pressure, and any additional data that may impact energy consumption. In the case of a machine learning-based energy consumption model, calibration is essential. The model is trained and validated using historical data that includes information about routes, speed profiles, battery SOC, and actual energy consumption. This calibration process helps the model learn the relationships between these variables. The energy consumption estimation model calculates the estimated amount of energy needed to complete the trip based on the input data. It should consider factors such as speed, acceleration, route characteristics, and the current state of the battery. Information about the route, including its length and characteristics (e.g., hilly terrain or highway driving), is integrated into the energy consumption model. The system is capable of real-time processing to continuously update the energy estimation as the vehicle progresses on its route.
A secondary energy consumption estimation model is integrated into the instant solution in one embodiment. This model may be either machine learning-based or utilize physical formulas. Its primary function is to calculate the energy consumption based on input data. Continuous monitoring of the vehicle's battery SOC is crucial. This involves real-time tracking of the current charge level in the rechargeable battery. Accurate SOC data is essential for precise energy consumption estimation. The system considers various input data, including the predicted speed values, acceleration values (if available), route information, and other contextual attributes such as HVAC settings, tire pressure, and ambient temperature. This information informs the secondary energy consumption model. In the case of a machine learning-based energy consumption model, model calibration is essential. The model is trained and validated using historical data that includes information about routes, speed profiles, battery SOC, and actual energy consumption. This calibration process helps the model learn the relationships between these variables. The secondary energy consumption estimation model calculates the estimated amount of energy needed to complete the trip based on the input data. It considers factors such as speed, acceleration, route characteristics, and the current state of the battery. Information about the route, including its length, terrain, traffic conditions, and other characteristics, is integrated into the energy consumption model, ensuring that the model's energy estimations are tailored to the specific journey. The solution is capable of real-time processing to continuously update the energy estimation as the vehicle progresses on its route. This ensures that drivers receive up-to-date information about their trip's energy requirements.
The instant solution is designed to receive and collect data from additional sensors and vehicle systems in one embodiment. This includes gathering information on the current setting of the vehicle's heating, ventilation, and air conditioning (HVAC) system, tire pressure sensor values, and other sensors. The data from these additional sensors, including HVAC settings and tire pressure values, should be integrated into the overall system. This involves processing and normalizing the data to make it compatible with the range estimation process. The system incorporates these contextual attributes, such as HVAC settings and tire pressure, into the range estimation calculation. For example, HVAC settings may impact the energy consumption of the vehicle's climate control system, while tire pressure affects rolling resistance and energy efficiency. When the range estimation relies on machine learning models, these models adapt to include the new contextual attributes. This adaptation may involve modifying the model's input features and training it with data that includes these attributes.
In one embodiment, the machine learning model is trained based on historical driving data to generate a user-specific machine learning model for range estimation, which involves several crucial steps and considerations. The system gathers historical driving data associated with the user to create a user-specific machine-learning model. This data includes information about routes, driving behavior, energy consumption, and battery states of charge. The system identifies and associates the collected data with the specific user of the vehicle. This may involve user profiles or authentication to ensure that the historical data is correctly matched with the user. The system determines the relevant features or input variables that will be used to train the user-specific machine-learning model. These features may include driving speed, acceleration patterns, route characteristics, battery SOC, and contextual attributes like HVAC settings. The historical driving data is preprocessed to make it suitable for training the machine learning model. This may involve data cleaning, normalization, and feature engineering to extract relevant information. The user-specific machine learning model is trained using the preprocessed historical data. The model learns to recognize patterns in the data and creates associations between the input features and range estimations. The trained model is validated and tested using separate datasets that were not used for training. This step ensures that the user-specific model can generalize and make accurate predictions for unseen data. The user-specific model continuously adapts and updates as new driving data becomes available. This ensures that the model remains relevant and reflective of the user's evolving driving habits.
In one embodiment, multiple machine learning models are incorporated for range estimation. These distinct models utilize different algorithms, architectures, or input features. Each machine learning model is provided with the appropriate data and input features. These features may include speed profiles, route information, battery state-of-charge (SOC), and any other relevant contextual attributes. The different machine learning models are selected to be used considering the model's ability to capture diverse aspects of range estimation, which may include variations of neural networks, regression models, decision trees, or any other suitable algorithms. Each machine learning model is separately trained, ensuring that they are optimized to make accurate range estimations based on their specific input features. Calibration and fine-tuning may be required to achieve optimal performance. A parallel execution system is implemented where both machine learning models generate their respective range estimations simultaneously in real time as the vehicle is in operation. A mechanism for combining the two range estimations is implemented, where the combination can be weighted based on the confidence or accuracy of each model's prediction. For example, if one model consistently performs better, it may carry more weight in the final estimation. Dynamic adjustment is allowed for the weighting factors based on the ongoing performance of the machine learning models. If one model starts to exhibit better accuracy during a particular drive, its contribution to the final estimation can be increased in real time. The final range estimation is calculated by combining the outputs of the two machine learning models. This provides a more robust and accurate estimation that considers multiple aspects of the vehicle's operation and contextual attributes.
Although an exemplary embodiment of at least one of a system, method, and non-transitory computer readable media has been illustrated in the accompanied drawings and described in the foregoing detailed description, it will be understood that the application is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications, and substitutions as set forth and defined by the following claims. For example, the capabilities of the system of the various figures can be performed by one or more of the modules or components described herein or in a distributed architecture and may include a transmitter, receiver or pair of both. For example, all or part of the functionality performed by the individual modules, may be performed by one or more of these modules. Further, the functionality described herein may be performed at various times and in relation to various events, internal or external to the modules or components. Also, the information sent between various modules can be sent between the modules via at least one of: a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device and/or via plurality of protocols. Also, the messages sent or received by any of the modules may be sent or received directly and/or via one or more of the other modules.
One skilled in the art will appreciate that a “system” could be embodied as a personal computer, a server, a console, a personal digital assistant (PDA), a cell phone, a tablet computing device, a smartphone or any other suitable computing device, or combination of devices. Presenting the above-described functions as being performed by a “system” is not intended to limit the scope of the present application in any way but is intended to provide one example of many embodiments. Indeed, methods, systems and apparatuses disclosed herein may be implemented in localized and distributed forms consistent with computing technology.
It should be noted that some of the system features described in this specification have been presented as modules to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or the like.
A module may also be at least partially implemented in software for execution by various types of processors. An identified unit of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions that may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together but may comprise disparate instructions stored in different locations that, when joined logically together, comprise the module and achieve the stated purpose for the module. Further, modules may be stored on a computer-readable medium, which may be, for instance, a hard disk drive, flash device, random access memory (RAM), tape, or any other such medium used to store data.
Indeed, a module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set or may be distributed over different locations, including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.
It will be readily understood that the components of the application, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the detailed description of the embodiments is not intended to limit the scope of the application as claimed but is merely representative of selected embodiments of the application.
One having ordinary skill in the art will readily understand that the above may be practiced with steps in a different order and/or with hardware elements in configurations that are different from those which are disclosed. Therefore, although the application has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent.
While preferred embodiments of the present application have been described, it is to be understood that the embodiments described are illustrative only and the scope of the application is to be defined solely by the appended claims when considered with a full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms etc.) thereto.
