Patent Application
20250236197
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 determining a health level of a battery of a first vehicle and a health level of a battery of a second vehicle when the battery of the first vehicle and the battery of the second vehicle are connected to at least one node associated with a location; determining an energy consumption of devices in the location; providing energy to the devices by the battery of the first vehicle; and, in response to the determined energy consumption being above a consumption threshold, providing additional energy to the devices by the battery of the second vehicle, wherein at least one of: providing the energy to the devices by the battery of the first vehicle is commensurate with the health level of the battery of the first vehicle; or providing the additional energy to the devices by the battery of the second vehicle is commensurate with the health level of the battery of the second vehicle.
Another example embodiment provides a system that includes a memory communicably coupled to a processor, wherein the processor performs one or more of determines a health level of a battery of a first vehicle and a health level of a battery of a second vehicle when the battery of the first vehicle and the battery of the second vehicle are connected to at least one node associated with a location; determines an energy consumption of devices in the location; provides energy to the devices from the battery of the first vehicle; and, in response to the determined energy consumption is above a consumption threshold, provides additional energy to the devices from the battery of the second vehicle, wherein at least one of: the energy provided to the devices by the battery of the first vehicle is commensurate with the health level of the battery of the first vehicle; or the additional energy provided to the devices by the battery of the second vehicle is commensurate with the health level of the battery of the second vehicle.
A further example embodiment provides a computer readable storage medium comprising instructions, that when read by a processor, cause the processor to perform one or more of determining a health level of a battery of a first vehicle and a health level of a battery of a second vehicle when the battery of the first vehicle and the battery of the second vehicle are connected to at least one node associated with a location; determining an energy consumption of devices in the location; providing energy to the devices by the battery of the first vehicle; and, in response to the determined energy consumption being above a consumption threshold, providing additional energy to the devices by the battery of the second vehicle, wherein at least one of: providing the energy to the devices by the battery of the first vehicle is commensurate with the health level of the battery of the first vehicle; or providing the additional energy to the devices by the battery of the second vehicle is commensurate with the health level of the battery of the second 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,”, “a first embodiment”, or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the one or more embodiments may be included in one or more other embodiments described or depicted herein. Thus, the one or more embodiments, described or depicted 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. Although described in a particular manner, by example only, or more feature(s), element(s), and step(s) described herein may be utilized together and in various combinations, without exclusivity, unless expressly indicated otherwise herein. In the figures, 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 connection, such as an arrow.
In the instant solution, a vehicle may include one or more of cars, trucks, Internal Combustion Engine (ICE) vehicles, battery electric vehicle (BEV), fuel cell vehicles, any vehicle utilizing renewable sources, hybrid vehicles, e-Palettes, buses, 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 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.
Example embodiments provide a service to a particular vehicle and/or a user profile that is applied to the vehicle. 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 may 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, global positioning system (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 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.
In some embodiments, the processor 139 determines a health level of a battery 113 of the first vehicle 102 and a health level of a battery 123 of the second vehicle 106, when the battery 113 of the first vehicle 102 and the battery 123 of the second vehicle 106 are connected to at least one node 107 associated with a location 108. For example, the node 107 may include a first connection point 131 for connecting to the battery 113 through a battery management system 112 of the first vehicle 102. Similarly, the node 107 may include a second connection point 132 for connecting to the battery 123 through a battery management system 122 of the second vehicle 106. In some embodiments, the processor 139 may determine the health level of the battery 113 of the first vehicle 102 by interrogating the battery management system 112 of the first vehicle 102. Likewise, the processor 139 may determine the health level of the battery 123 of the second vehicle 106 by interrogating the battery management system 122 of the second vehicle 106. In one alternate embodiment, the battery 113 may be connected directly to the first connection point 131, and the battery 123 may be connected directly to the second connection point 132, with the processor 139 determining the health level of the battery 113 over the first connection point 131 and determining the health level of the battery 123 over the second connection point 132.
In some embodiments, the health level of the battery 113 is determined by the battery management system 112 measuring the impedance of the battery 113. Similarly, the health level of the battery 123 can be determined by the battery management system 122 measuring the impedance of the battery 123. By measuring impedance, the internal resistances of the batteries 113 and 123 may be determined, to thereby provide a level of overall battery health. For example, a battery with a high health level may be associated with a low battery impedance. When battery impedance measurements are taken over time, impedance values can be a useful trending tool signaling potential battery problems much earlier than voltage testing alone. Over time, a battery's internal resistance, or impedance, typically increases, indicating degradation in the battery. Battery impedance can be measured over months and years, each time comparing the impedance measurement to previous values on record to create a base line.
In some embodiments, the processor 139 determines an energy consumption of devices 145 at the location 108. For example, the processor 139 may monitor a smart panel 141 at the location 108 to determine a current drain for one or more devices 145, such as a refrigerator, an oven, an air conditioning system, a heating system, a fan, lighting, computer equipment, medical equipment, or another type of device that consumes electricity. The battery 113 of the first vehicle 102 may be connected through the battery management system 112 to the first connection point 131. The processor 139 may direct a providing of electrical energy to the devices 145 from the battery 113 of the first vehicle 102 by sending an instruction to the smart panel 141. Alternatively, or additionally, the processor 139 may direct the providing of electrical energy to the devices 145 by enabling the first connection point 131 to pass electrical energy from the battery 113 of the first vehicle 102 to the smart panel 141 and/or to the devices 145.
In some embodiments, the battery 123 is connected through the battery management system 122 to the second connection point 132. In response to the determined energy consumption of the devices 145 being above a consumption threshold, the processor 139 may direct the smart panel 141 to provide additional electrical energy to the devices 145 from the battery 123 of the second vehicle 106. Alternatively, or additionally, the processor 139 may direct the providing of the additional electrical energy to the devices 145 by enabling the second connection point 132 to pass electrical energy from the battery 123 of the second vehicle 106 to the smart panel 141 and/or to the devices 145.
In some embodiments, the energy consumption is determined by the processor 139 and/or the smart panel 141 monitoring a current consumption and/or a kilowatt-hour usage of the devices 145 to determine whether or not the consumption threshold has been reached. The consumption threshold can be expressed in terms of current consumption, kilowatt-hour usage, or another measurement of energy consumption may be employed. In some embodiments, the energy provided to the devices 145 by the battery 113 of the first vehicle 102 is commensurate with the health level of the battery 113. Additionally, or alternatively, the energy provided to the devices 145 by the battery 123 of the second vehicle 106 is commensurate with the health level of the battery 123.
In some embodiments, the energy and the additional energy are provided to at least one device of the devices 145 with an energy consumption above a threshold within a set of peak hours for an electrical grid 143. At least one of the providing of the energy or the providing of the additional energy may be ceased outside the set of peak hours for the electrical grid 143. For example, the processor 139 may communicate over a network 104 with a grid server 144 operatively coupled to the electrical grid 143. The grid server 144 may include data specifying a set of peak hours for the electrical grid 143. In response to the processor 139 receiving information from the grid server 144 indicating that the electrical grid 143 is operating within peak hours, the processor 139 can direct the smart panel 141 to provide the energy and the additional energy to the at least one device of the devices 145. Alternatively, or additionally, the processor 139 can enable the first connection point 131 to pass the energy from the battery 113 to the smart panel 141 and/or the at least one device of the devices 145 and can enable the second connection point 132 to pass the additional energy from the battery 123 to the smart panel 141 and/or the at least one device of the devices 145.
In response to the processor 139 receiving information from the grid server 144 indicating that the electrical grid is not operating within peak hours, the processor 139 may direct the smart panel 141 to cease providing the additional energy to the at least one device of the devices 145. Alternatively, or additionally, the processor 139 may disable the second connection point 132 such that the additional energy is not passed from the battery 123 to the smart panel 141.
In some embodiments, the processor 139 identifies a highest-health battery among the battery 113 of the first vehicle 102 and the battery 123 of the second vehicle 106. For example, the processor 139 may communicate with the battery management system 112 over the first connection point 131 to determine an impedance of the battery 113, where the impedance is indicative of the health level of the battery 113. Likewise, the processor 139 may communicate with the battery management system 122 over the second connection point 132 to determine an impedance of the battery 123, where the impedance is indicative of the health level of the battery 123. A battery among the battery 113 and the battery 123 having the lowest impedance may be regarded as the highest-health battery. The processor 139 can direct the smart panel 141 to cease providing the energy or the additional energy from the highest-health battery in response to a state-of-charge (SoC) of the highest-health battery dropping below a minimum SoC threshold. Alternatively, or additionally, when the highest-health battery is the battery 113, the processor 139 disables the first connection point 131 in response to the SoC of the battery 113 dropping below the minimum SoC threshold; or, when the highest-health battery is the battery 123, the processor 139 can disable the second connection point 132 in response to the SoC of the battery 123 dropping below the minimum SoC threshold.
In some embodiments, the processor 139 directs the providing of the energy or the providing of the additional energy from a battery among the battery 113 and the battery 123 that is not the highest-health battery of either the first vehicle 102 or the second vehicle 106. For example, the energy or the additional energy can be provided by a least-healthy battery of the battery 113 and the battery 123.
In some embodiments, the processor 139 detects a power outage of the electrical grid 143. For example, the processor 139 may receive power outage information for the electrical grid 143 from the grid server 144 over the network 104. Alternatively, or additionally, the processor may detect a power outage by monitoring the smart panel 141, to determine whether or not the smart panel 141 is receiving power from the electrical grid 143. In response to the detecting of the power outage, the processor 139 controls the providing of the energy and the providing of the additional energy, wherein an SoC of the battery 113 of the first vehicle 102 and an SoC of the battery 123 of the second vehicle 106 approach an equal state-of-charge. For example, the processor 139 may selectively enable and/or disable the first connection point 131 to control the SoC of the battery 113. Likewise, the processor 139 may selectively enable and/or disable the second connection point 132 to control the SoC of the battery 123. Alternatively, or additionally, the processor 139 may control the SoCs of the battery 113 and the battery 123 by instructing the smart panel 141 to utilize energy from the battery 113 and/or the battery 123 to supply energy to the devices 145, such that the SoCs of the batteries 113 and 123 become balanced over time.
In some embodiments, the processor 139 ranks the devices 145 based on a necessity of the devices 145. For example, a first device of the devices 145 may be a critical or life-essential piece of medical equipment, such as a dialysis machine, a heart-lung machine, or an insulin pump. A second device of the devices 145 may be an entertainment device, such as a television set or electronic game, which is not critical or essential for maintaining human life. In this example, the processor 139 may rank the first device of the devices 145 as having a higher necessity than the second device of the devices 145. In some embodiments, the processor 139 ensures that at least one of the battery 113 of the first vehicle 102 or the battery 123 of the second vehicle 106 maintains an SoC greater than an SoC threshold when a device of the devices 145 is ranked above a necessity threshold. For example, a device that is a critical or life-essential piece of medical equipment may be ranked above the necessity threshold, whereas an entertainment device may be ranked below the necessity threshold.
In some embodiments, the processor 139 directs a providing of energy to a first set of devices 153 in a first portion 156 of the location 108 from the battery 113 of the first vehicle 102. The processor 139 directs a providing of additional energy to a second set of devices 157 in a second portion 158 of the location 108 from the battery 123 of the second vehicle 106. For example, the processor 139 may instruct the smart panel 141 to provide electrical power to the first set of devices 153 from the first connection point 131, wherein the battery 113 of the first vehicle 102 is connected to the first connection point 131 through the battery management system 112. Likewise, the processor 139 may instruct the smart panel 141 to provide electrical power to the second set of devices 157 from the second connection point 132, wherein the battery 123 of the second vehicle 106 is connected to the second connection point 132 through the battery management system 122.
In one embodiment, the instant solution integrates with a local smart grid that includes renewable energy sources like solar panels or wind turbines. The health of the vehicle batteries is determined and used to supplement the smart grid's energy during peak demand hours. This integration provides an additional energy source that balances the load on the grid. Vehicle-to-Grid (V2G) technology allows electric vehicles (EVs) to communicate and interact with the power grid. V2G enables the charging of EVs and discharging of their stored energy back to the grid or other devices. The instant solution constantly monitors the health and charge level of the batteries in connected vehicles. This includes assessing factors like battery capacity, charge cycles, temperature effects, and impedance. A central controller manages energy flow based on battery health, demand supply in the grid, and renewable energy availability. The controller decides when and how much energy should be drawn from or supplied to the EVs. When renewable sources generate excess energy (e.g., sunny or windy conditions), and the demand on the grid is low, the excess energy is used to charge the EVs connected to the grid. The charging is controlled based on the health of the EV batteries, ensuring that it does not degrade the batteries. During peak hours, if the grid requires additional energy, the controller assesses the health of all connected EV batteries. Vehicles with healthier batteries can then supply their stored energy to the grid. The instant solution dynamically adjusts which vehicle's energy is used based on the ongoing battery health assessment. The instant solution maintains a feedback loop with renewable energy sources, adjusting the charging and discharging cycles of the EVs based on real-time generation data.
In one embodiment, the instant solution identifies EVs with the healthiest batteries and uses them to power critical devices, such as medical equipment, during an emergency response situation such as a natural disaster or power outage. The instant solution dynamically assesses which vehicle batteries can provide the most reliable energy source and switches among them as their battery levels fluctuate, ensuring a consistent power supply. The instant solution continuously evaluates the health of connected EV batteries, factoring in charge level, age, temperature effects, and charging history. It identifies and prioritizes devices based on their importance in emergency scenarios, like medical equipment, communication devices, and lighting. The instant solution leverages vehicle-to-device (V2D) connectivity to directly transfer power from the vehicles to the critical devices, bypassing grid connectivity. The instant solution utilizes software to make real-time decisions about which vehicle's battery to use for power supply based on battery health and the power requirements of the connected devices. In an emergency, the instant solution first identifies critical devices that require uninterrupted power. These devices may range from life-saving medical equipment to communication and lighting systems. The instant solution dynamically allocates power based on the battery health data and the power needs of the critical devices. It draws energy from the vehicle (or vehicles) with the healthiest battery, ensuring an efficient and sustained power supply. The instant solution also considers the long-term health of the vehicle batteries. It avoids completely depleting any single battery and rotates between multiple vehicles, if available, to distribute the load and preserve battery life. Throughout an emergency, the instant solution monitors the devices' battery status and power needs. It makes real-time adjustments to respond to changing conditions, such as a reduction in battery capacity or a change in the priority of devices needing power.
In one embodiment, EVs at a location can collaboratively charge each other. The instant solution assesses the health of each vehicle's battery. It allows EVs with higher health batteries to transfer charge to those with lower health, effectively balancing the battery health across vehicles. This can be particularly useful in parking lots or company fleets, ensuring all vehicles are adequately charged for their next journey. The instant solution continuously assesses the health of each EV's battery, considering factors like charge level, age, temperature effects, and charging cycles. A smart controller determines the direction and amount of energy transfer between vehicles based on their battery health. The instant solution includes a user interface to allow vehicle owners to opt in, set preferences, and receive information about their vehicle's battery status and energy-sharing activities. Upon entering the shared parking area, the instant solution assesses each EV's battery health. This includes evaluating the state-of-charge, battery degradation, and overall performance metrics. The instant solution analyzes the battery health data and determines which vehicles need charging and which can provide charge. Vehicles with higher battery health are selected as donors and those with lower health as recipients. Once the charging dynamics are established, the instant solution facilitates energy transfer from donor vehicles to recipient vehicles. The process is carefully managed to ensure that the donor vehicles retain sufficient charge for their needs. The instant solution continuously monitors battery statuses throughout the charging process and adjusts the energy transfer as necessary. When a donor vehicle's battery health decreases, or a recipient's battery reaches an optimal level, the instant solution modifies the charging accordingly.
In one embodiment, the instant solution manages a dynamic energy pricing model based on battery health. The instant solution adjusts the charging price based on the assessed battery health. Healthier batteries are charged at a lower rate as they are less likely to degrade the grid's performance. Conversely, vehicles with poorer battery health are charged at a higher rate, encouraging owners to maintain or replace batteries. The instant solution evaluates the health of the EV's battery in real-time, considering factors like charge capacity, degradation, temperature effects, and charging history. An algorithm adjusts the charging price based on the assessed battery health, charging healthier batteries less and poorer batteries more. The instant solution communicates the dynamic pricing with smart charging stations so they can apply the appropriate charging rates. Additionally, the instant solution allows the smart charging stations to communicate with the larger electrical grid, helping to manage the load and integrate the dynamic pricing model into the overall energy system. EV owners receive information about battery health, corresponding charging rates, and tips for maintaining or improving battery health. When an EV connects to a smart charging station, the battery's health is immediately assessed. Based on the battery health assessment, the dynamic pricing algorithm determines the charging rate for that session. The instant solution communicates with the electrical grid to understand current demand and supply and refine pricing.
In one embodiment, the instant solution distributes energy in residential areas based on battery health. EVs with lower health batteries are charged during off-peak hours to reduce strain on the grid, while EVs with healthier batteries are used as temporary energy storage to supply power to homes during peak hours. The instant solution manages energy distribution within a residential community, integrating home energy systems, EV charging, and discharging. The instant solution continuously evaluates the health of EV batteries parked at residences, including factors such as charge capacity, degradation rate, and usage history. It intelligently directs energy flow between EVs and residential units based on battery health, energy demand, and grid conditions. Users monitor their energy usage and control settings and receive updates on their EV battery status and participation in energy sharing. Upon an EV's arrival at the residence, the instant solution assesses its battery health. This involves checking the state-of-charge, battery degradation, and other health indicators. Based on the battery health data and the residential energy demands, the instant solution plans the energy distribution, deciding whether to store energy in the vehicle, use it for the home, or reserve it for later use. During peak hours or when renewable energy generation is low (e.g., solar panels not generating enough power), the instant solution draws energy from EVs with healthier batteries to power homes, reducing grid dependency and energy costs. The instant solution ensures that no single vehicle's battery is overused. It balances the energy contribution from different EVs to prevent premature battery degradation. Users can interact with the instant solution through a control panel, setting preferences for how their vehicle's battery is used or limiting how much energy can be drawn from their vehicle.
In one embodiment, the instant solution details a method for managing the distribution of electrical energy from vehicle batteries to external devices, particularly when those vehicles are electrically connected to a node at a specific location. The instant solution includes at least two vehicles, each equipped with its own battery management system and a battery, and a node that serves as a junction point for connecting these vehicle batteries to a network of devices requiring power. The first vehicle and the second vehicle interface with the node to provide a comprehensive assessment of each battery's health. The instant solution does this by measuring the impedance of the batteries of both vehicles, which indicates their internal resistance and, by extension, their overall health. A lower impedance corresponds to a healthier battery, providing a more reliable energy supply. When the vehicles are connected to the node, the instant solution evaluates both batteries' health levels simultaneously. The instant solution also determines the energy consumption needs of the devices at the location by monitoring a smart panel equipped to report the current energy demands of the connected devices, such as home appliances, office equipment, etc. The instant solution directs energy from the healthier battery to the devices when their consumption levels surpass a predefined threshold. When the energy demand continues to rise, the instant solution engages the battery from the second vehicle to supply additional energy to meet this increased demand. The engagement is executed in a balanced manner, ensuring that the energy drawn from both batteries is commensurate with their respective health levels, thereby preventing over-exertion of a less healthy battery. Additionally, the energy provision is responsive to each battery's state-of-charge (SoC). If the SoC of either battery falls below a critical threshold, the instant solution will halt energy provision from that battery to preserve its longevity.
In one embodiment, the instant solution distributes energy within different portions of a given location. The instant solution, in collaboration with a node, is programmed to control the distribution of energy from a first EV battery to devices located in a first portion of the location and, similarly, to manage the distribution of energy from a second EV battery to devices situated in a second, different portion of the location. This targeted distribution is made possible through the integration of the smart panel, which acts as the operational interface for the server to execute its control over the energy supply. The server communicates directly with the battery management systems of each vehicle through established connection points and receives real-time data on the health and SoC of each battery through the connection points. With this information, the instant solution can make informed decisions on energy allocation based on the current needs and the capacity of each battery to supply power without compromising its health. The instant solution's architecture allows for a granular approach to energy management, where the instant solution can allocate energy reserves from the vehicles to specific devices in a prioritized manner. For instance, if the first portion of the location includes critical infrastructure or devices requiring a constant power supply, the instant solution can ensure that the healthier and more capable battery provides the necessary energy. Conversely, less critical devices in the second portion may receive power from the second vehicle's battery, which may be less healthy or have a lower SoC. The instant solution also communicates over a network and can respond to broader electrical grid demands during peak hours, thereby contributing to a more balanced and efficient electrical grid operation.
In one embodiment, the instant solution includes an advanced prioritization scheme designed to manage and allocate energy resources based on the criticality of devices within a location. This scheme involves the interaction of multiple vehicle batteries with a network of devices requiring power. In coordination with a node, the instant solution ranks devices based on their necessity. The ranking is crucial for ensuring that devices deemed essential, particularly in scenarios such as medical emergencies or critical infrastructure support, are given priority in power distribution. The instant solution communicates with the battery management systems of the first and second vehicles through respective connection points. It assesses the health and state-of-charge (SoC) of each vehicle's battery and evaluates the energy consumption requirements of the devices in the location through a smart panel. The instant solution dynamically ensures that at least one of the vehicle's batteries maintains an SoC above a predetermined threshold when a device is identified as having a necessity above a critical threshold. For example, if a dialysis machine, which is a life-essential medical device, is connected to the location, the instant solution prioritizes the maintenance of a sufficient SoC in the battery of the vehicle assigned to provide energy to that medical device. The instant solution is designed to be responsive not only to the immediate energy consumption of the devices but also to their ranked necessity. The instant solution, through a network, may receive or determine the necessity rankings and adjust the energy supply accordingly. When a device's necessity ranking is high, the instant solution ensures that the vehicle battery with the healthiest state (the first or second vehicle's battery) is ready to supply energy, safeguarding critical device operation. Additionally, the instant solution includes communication capabilities over the network with a grid server, which provides data on grid conditions that may influence the necessity ranking. For instance, during a grid outage, the necessity of maintaining power to medical equipment becomes paramount, and the instant solution may adjust its energy allocation to reflect this heightened priority.
In one embodiment, the instant solution leverages the battery resources of EVs to supply energy to a network of devices, with an intelligent mechanism to adapt to the varying demands of the electrical grid over time. The instant solution determines the health levels of the batteries and manages the distribution of energy to the devices based on the consumption patterns and the health of the batteries. The instant solution monitors and responds to a set of peak hours for the electrical grid, as determined by a grid server with which it communicates over a network. During peak hours, the instant solution provides additional energy to devices with consumption above a certain threshold, effectively reducing the load on the electrical grid when it is under the most stress. A smart panel acts as the control hub for this operation, executing the instant solution's instructions to draw energy from the appropriate vehicle batteries. The panel switches the energy supply on or off to various devices based on instructions received from the instant solution, which are informed by real-time data on grid conditions received from the grid server. Outside of peak hours, the instant solution is programmed to conserve the battery resources of the vehicles. This is achieved by ceasing the supply of additional energy to the devices, thereby preserving the batteries' state-of-charge and ensuring their longevity and readiness for subsequent peak periods or for their primary function of vehicle operation.
In one embodiment, the instant solution manages the distribution of energy from EV batteries to external devices based on the health of the batteries while also considering the operational longevity of the batteries. The instant solution responds to the fluctuating needs of a location's devices by utilizing the battery that is in the best condition, referred to as the “highest-health” battery while safeguarding against the depletion of any battery beyond a critical threshold. The instant solution interfaces with the battery management systems (BMS) of a first and a second vehicle via established connection points. The instant solution monitors and compares the health levels of both batteries by assessing their impedance, which serves as an indicator of their internal resistance and overall condition. It identifies the battery with the lower impedance as the highest-health battery, which is more capable of providing energy without rapid degradation. Upon determining the healthiest battery, the instant solution directs the energy provision to the devices from the highest-health battery. Additionally, the instant solution includes a safeguard: to cease energy provision from the highest-health battery if its state-of-charge (SoC) falls below a minimum SoC threshold. This is crucial to prevent any battery from discharging to a level that may harm its long-term functionality and lifespan. When the highest-health battery's SoC approaches this critical minimum threshold, the instant solution switches the energy provision responsibility to the other battery, ensuring an uninterrupted power supply to the location's devices while also maintaining the health of both vehicle batteries. The instant solution is connected to a network, which allows it to communicate with a grid server. This communication channel provides the instant solution with additional data regarding the broader state of the electrical grid to further inform the decision on when to cease or resume energy provision from either vehicle's battery.
In one embodiment, the instant solution introduces a method of provisioning energy directly from a battery that is not identified as the highest-health battery between a first and a second EV. This allows the use of EV batteries for energy supply while preserving the battery with the highest health for more critical or long-term use. The instant solution orchestrates energy distribution to devices at a location. The instant solution communicates with a node, which acts as the intermediary connection hub for the EVs, and a smart panel, which interfaces with the location's devices. Through the battery management systems of the first vehicle and the second vehicle, the instant solution evaluates the health of each vehicle's battery by assessing factors such as impedance, which indicates internal resistance and overall battery condition. The instant solution identifies the highest-health battery based on this assessment to determine which battery to draw energy. The instant solution then supplies the energy from the battery that is not the highest-health battery. This reserves the highest-health battery for scenarios where it may be urgently needed, such as during a power outage or for essential travel with the vehicle. The instant solution constantly monitors the state-of-charge (SoC) of both batteries. When the SoC of the non-highest-health battery approaches a critical minimum threshold, indicating that further discharge may potentially damage the battery, the instant solution reevaluates the situation and draws energy from the highest-health battery. The instant solution maintains a balance between the immediate energy needs of the location and the long-term preservation of the EVs' battery health. Network connectivity enables the instant solution to receive data from a grid server regarding the overall state of the electrical grid. This information allows the instant solution to make more informed decisions about energy distribution, especially in consideration of grid demand and vehicle usage patterns.
In one embodiment, the instant solution maintains an energy supply in the event of an electrical grid outage, utilizing the batteries of EVs to provide a balanced power source to a location. The instant solution manages the state-of-charge (SoC) of each vehicle's battery to ensure equitable usage and to prevent any one battery from being excessively depleted. The instant solution communicates with a node connecting the EVs to a smart panel. The smart panel controls the location's devices, enabling the selective provision of power to these devices based on current needs and the status of the electrical grid. When the instant solution detects a power outage through direct communication with a grid server via a network or by monitoring the power status at the smart panel, it triggers a response mechanism. This mechanism controls the energy drawn from the batteries of the first vehicle and the second vehicle, ensuring that the SoC of both batteries approaches a substantially equal level over time. This approach not only provides an immediate solution to the power outage but also manages the long-term viability of the batteries by avoiding the scenario where one battery is completely drained while another remains relatively full. The instant solution actively manages the connection points that link the EV batteries to the smart panel. It adjusts the flow of power from each battery, balancing the SoC levels based on real-time consumption by the devices. The instant solution can selectively enable or disable these connection points to modulate the power supply based on the dynamic requirements of the location and the condition of the electrical grid.
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 determining a health level of a battery of a first vehicle and a health level of a battery of a second vehicle when the battery of the first vehicle and the battery of the second vehicle are connected to at least one node associated with a location 244C; determining an energy consumption of devices in the location 246C; providing energy to the devices by the battery of the first vehicle 248C; and, in response to the determined energy consumption being above a consumption threshold, providing additional energy to the devices by the battery of the second vehicle, wherein at least one of: providing the energy to the devices by the battery of the first vehicle is commensurate with the health level of the battery of the first vehicle; or providing the additional energy to the devices by the battery of the second vehicle is commensurate with the health level of the battery of the second vehicle 250C.
The processor 204 performs one or more of providing the energy to the devices in a first portion of the location by the first vehicle; and providing the additional energy to the devices in a second portion of the location by the second vehicle 244D; ranking the devices based on a necessity of the devices; and ensuring that at least one of the first vehicle and the second vehicle maintains an SoC greater than an SoC threshold when a device of the devices is ranked above a necessity threshold 245D; providing the energy and providing the additional energy to at least one device of the devices with an energy consumption above a threshold within a set of peak hours for an electrical grid; and ceasing at least one of the providing of the energy or the providing of the additional energy outside the set of peak hours for the electrical grid 246D; identifying a highest-health battery among the battery of the first vehicle and the battery of the second vehicle; and ceasing the providing of the energy or the providing of the additional energy from the highest-health battery in response to a state-of-charge of the highest-health battery dropping below a minimum state-of-charge threshold 247D; providing the energy or providing the additional energy from the battery that is not the highest-health battery of either the first vehicle or the second vehicle 248D; and detecting a power outage of an electrical grid; and in response to the detecting, controlling the providing of the energy and the providing of the additional energy, wherein a state-of-charge of the battery of the first vehicle and a state-of-charge of the battery of the second vehicle approach an equal state-of-charge 249D.
While this example describes in detail only one vehicle 202, multiple such nodes may be connected to the blockchain. 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 may 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 and executing a smart contract to record the confirmation on the blockchain consensus. 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 may fully or partially reside in the interior or exterior of the vehicles. The steps or features stored in the computer readable media 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 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 (ML) models, neural networks, or the like. The system 302 may trigger the execution of a model from the model repository 323 via invocation of 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 invocation from the system 302 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 302 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
In one embodiment, the host process 322 may include Generative AI (GenAI), which may be used by the instant solution in the transformation of data. Vehicles may be equipped with diverse sensors, cameras, radars, and LIDARs, which collect a vast array of data, such as images, speed readings, GPS data, and acceleration metrics. However, raw data, once acquired, undergoes preprocessing that may involve normalization, anonymization, missing value imputation, or noise reduction to allow the data to be further used effectively.
The GenAI may execute data augmentation following the preprocessing of the data. Due to the limitation of datasets in capturing the vast complexity of real-world vehicle scenarios, augmentation tools are employed to expand the dataset. This might involve image-specific transformations like rotations, translations, or brightness adjustments. For non-image data, techniques like jittering can be used to introduce synthetic noise, simulating a broader set of conditions.
In the instant solution, data generation may be then performed on the data. Tools like Generative Adversarial Networks (GANs) and Variational Autoencoders (VAEs) are trained on existing datasets to generate new, plausible data samples. For example, GANs might be tasked with crafting images showcasing vehicles in uncharted conditions or from unique perspectives. As another example, the synthesis of sensor data may be performed to model and create synthetic readings for such scenarios, enabling thorough system testing without actual physical encounters.
A critical step in the use of GenAI, given the safety-critical nature of vehicles, is validation. This validation might include the output data being compared with real-world datasets or using specialized tools like a GAN discriminator to gauge the realism of the crafted samples.
The process 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 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 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 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 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 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/408B 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 transfer energy from the vehicle to 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 charging station 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 charging station 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 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, 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 compact disc read only memory (CD-ROM) device, a digital versatile disk read only memory (DVD-ROM) device, a digital versatile disk random access memory (DVD-RAM) device, a digital versatile disk rewritable (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 (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 Light Detection and Ranging (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 global positioning system (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 402E or to another communication channel. In some embodiments, the communication unit 424E may include a dedicated short-range communication (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 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.
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 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 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 decides 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 406I or the like. For example, the vehicle 408I may verify with the certificate authority 406I 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 406I 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 a 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 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 another vehicle and communication exists between the vehicle processor, a second database, the vehicle processor, and a transaction module. The other 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 the vehicle to the other vehicle and the record of the transferred service is logged in the first database, 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 forwarded 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’ 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 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 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 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 520E 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, and 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 node 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 forwarded by the client application to the 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 522E. The architecture of the blockchain network may be designed such that the specific implementation of ‘ordering’ 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 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 the 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 (shown in
In one embodiment of the instant solution, the blockchain data 563 may include data for determining a health level of a battery of a first vehicle and a health level of a battery of a second vehicle when the battery of the first vehicle and the battery of the second vehicle are connected to at least one node associated with a location; determining an energy consumption of devices in the location; providing energy to the devices by the battery of the first vehicle; and in response to the determined energy consumption being above a consumption threshold, providing additional energy to the devices by the battery of the second vehicle, wherein at least one of: providing the energy to the devices by the battery of the first vehicle is commensurate with the health level of the battery of the first vehicle; or providing the additional energy to the devices by the battery of the second vehicle is commensurate with the health level of the battery of the second vehicle.
Although in
The block metadata 560 (
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,
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 Interconnect (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 may 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, redundant array of independent disks (RAID) systems, tape drives, and data archival storage systems, etc.
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” may 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, RAM, tape, or any other such medium used to store data.
Indeed, a module of executable code may 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.
