Patent Application
20150178799
This patent document pertains generally to minimization problems, and more particularly, but not by way of limitation, to a system and method of fuel filling to minimize fuel cost.
During a planned trip among a plurality of stops, a vehicle may need to fill up on fuel multiple times. The price of fuel at each stop may vary and therefore the total cost of fuel for the trip may also vary depending on how much fuel is filled up at each stop. Additionally, different vehicles consume (e.g., use) fuel at different rates. Accordingly, there may be many different fuel costs scenarios for a given trip.
Some embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which:
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of some example embodiments. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.
Consider a vehicle that is on a transit path through a plurality of stops (e.g., cities, states, countries). In various examples, the vehicle may be an aircraft, cargo, trailer, truck, maritime vessel, etc. Much of the cost of the trip may be based on the amount of fuel used during the trip. Accordingly, a person may determine how much fuel should be filled up at each stop of the trip. One solution is to fill up the vehicle to its capacity at each stop. However, in such an solution there is no control for costs.
In various examples, in order to minimize costs, different amounts of fuel may be filled up at the different stops. Thus, the problem may be generalized as a constraint minimization problem. Some factors that may be considered in solving this minimization problem may include, but are not limited to, the price difference for fuel from stop to stop, the vehicle should be filled to reach their next destination, the vehicle should not be too filled as it increases weight and thus may lower fuel efficiency, and different vehicles have different fuel consumption functions in regard to weight, speed, and other parameters.
In various examples, a fuel optimization system is described that determines, for a given transit route, the amount of fuel to fill up at each stop along the transit route. The fuel optimization system may include three general operations: (1) data collection of vehicle types, local fuel prices, travel distances; (2) applying a differential evolution algorithm using the collected data and defined operational contains and objectives to optimize fuel filling; (3) and visualizing the results of the differential evolution algorithm.
In various examples, utilization of the system may result in a minimal fuel cost while maintain a safe fuel remainder at each stop along a transit route. Additionally, when differential evolution is used and the relationship between vehicle weight and consumption of fuel is known, the system may be used regardless of the type of vehicle. Thus, in contrast to linear programming methods, using only predefined types of vehicles may not be needed.
Network 106 may include local-area networks (LAN), wide-area networks (WAN), wireless networks (e.g., 802.11 or cellular network), the Public Switched Telephone Network (PSTN) network, ad hoc networks, personal area networks (e.g., Bluetooth) or other combinations or permutations of network protocols and network types. The network 106 may include a single local area network (LAN) or wide-area network (WAN), or combinations of LAN's or WAN's, such as the Internet. The various devices coupled to network 106 may be coupled to network 106 via one or more wired or wireless connections.
Web server 108 may communicate with file server 114 to publish or serve files stored on file server 114. Web server 108 may also communicate or interface with the application server 110 to enable web-based presentation of information. For example, application server 110 may consist of scripts, applications, or library files that provide primary or auxiliary functionality to web server 108 (e.g., multimedia, file transfer, or dynamic interface functions).
In addition, application server 110 may also provide some or the entire interface for web server 108 to communicate with one or more of the other servers in fuel optimization system 102 (e.g., database management server 112). Web server 108, either alone or in conjunction with one or more other computers in fuel optimization system 102, may provide a user-interface to input transit stops and a type of vehicle. The user-interface may be implemented using a variety of programming languages or programming methods, such as HTML (HyperText Markup Language), VBScript (Visual Basic® Scripting Edition), JavaScript™, XML® (Extensible Markup Language), XSLT™ (Extensible Stylesheet Language Transformations), AJAX (Asynchronous JavaScript and XML), Java™, JFC (Java™ Foundation Classes), and Swing (an Application Programming Interface for Java™)
User terminal 104 may be a personal computer or mobile device. In an embodiment, user terminal 104 includes a client program to interface with fuel optimization system 102. The client program may include commercial software, custom software, open source software, freeware, shareware, or other types of software packages. In an embodiment, the client program includes a thin client designed to provide query and data manipulation tools for a user of user terminal 104. The client program may interact with a server program hosted by, for example, application server 110. Additionally, the client program may interface with database management server 112.
Operations database 116 may be composed of one or more logical or physical databases. For example, operations database 116 may be viewed as a system of databases that when viewed as a compilation, represent an “operations database.” Sub-databases in such a configuration may include a vehicle tank capacity database, a distances database, a fuel prices database, a safety threshold database, and a fuel consumption function database. Operations database 116 may be implemented as a relational database, a centralized database, a distributed database, an object oriented database, or a flat database in various embodiments.
During operation, data from multiple data sources is imported into operations database 116. Data sources may exist within an organization offering the fuel optimization systems or exist at an external source, such as commercial database or a public record source. The data may be imported and stored in the operations database on a scheduled basis, such as weekly, monthly, quarterly, or some other regular or periodic interval to maintain current data. Alternatively, the data may be imported on-demand (e.g., each time a user wants to determine the amount of fuel to use).
After data importation, the data may be standardized and then stored in operations database 116. For example, database records from internal or external sources may not be in a compatible format with the operations database. Data conditioning may include data rearrangement, normalization, filtering (e.g., removing duplicates), sorting, binning, or other operations to transform the data into a common format (e.g., using similar date formats, name formats, and address fields).
While illustrated as separate components in diagram 100, the various components may be combined or split into additional servers. Additionally, one or more of the components may not be utilized during operation of the present disclosure. Additionally, the components may be rearranged. For example, a user terminal may be part of the file optimization system instead of communicating through the web server.
The operations and functionality discussed below may be implemented by computing instructions stored on a storage device that are executed by one or more processors of the computing device. In various examples, the storage device is a non-transitory storage medium. In various examples, non-transitory refers to excluding propagating signals and does not refer to whether or not the storage device is mobile.
In various examples, structured data collection 202 is data that has been collected for data fusion component 208 (e.g., from internal or external sources). Data fusion component 208 may retrieve data that is relevant to the fuel optimization for a specific request of a user. For example, structured data collection 202 may include the distance (e.g., miles, kilometers) between locations of a transit route where a vehicle may be filled with fuel. Distance data 216 may include a plurality of entries identifying two locations and the distance between the locations. In various examples, distances data 216 may include entries for stops along a transit route that has been inputted by a user (e.g., using user terminal 104). Local fuel prices data may have entries that correlate the price of fuel (e.g., per gallon, per barrel, etc.) with a location. In various examples, locations may have an identifier that is shared across data sources. Thus, an entry in distances data 216 may identify a location with the same identifier as that used in local fuel prices data 218. The data in local fuel prices data 218 may be retrieved on a periodic basis in order to have up-to-date prices. In various examples, the data collected for data fusion component 208 is considered available publically and may be collected manually or in an automated fashion (e.g., using scripts, APIs, etc.).
In various examples, vehicle characteristics such as tank capability data 220 and safety threshold data 222 includes entries on minimum and maximum capabilities of fuel in vehicles. For example, for a given vehicle there may be a minimum amount of fuel that should be in the tank for safety reasons. In various examples, this amount may be above zero. The maximum capability may include the maximum amount of fuel that the tank may support. In various examples, the maximum capability may be less than the fuel capacity of the tank of the vehicle. In various examples, a vehicle may be identified using a common identifier between tank capability data 220 and safety threshold data 222. Accordingly, if a query is inputted into computing device 204, both tank capability data 220 and safety threshold data 222 may be retrieved using the same vehicle identifier. A lookup table may also be stored that correlates a vehicle (e.g., type, make, model, etc.) with a vehicle identifier, allowing a query to use the vehicle name or other features as the input.
As discussed previously, fuel filling optimization may be treated as minimization problem with several inequality constraints. To solve this problem, difficulties are laid on the function expression of fuel consumption with respect to the amount of filled fuel and travel distance. One reason that this function is often complicated in the real world, is the varied types of vehicles. A more detailed description of optimization is described in the next sections.
In various examples, differential evolution algorithm 226 defines the problem and inequality constraints for determining the cost minimization as it relates to fuel. In an example, it is assumed that there are a total of n transfer terminals (i.e., locations in a transmit path of a vehicle) along the path. In an example, wi denotes the amount of fuel filling in the i-th terminal and pi denotes the local per-unit price of fuel (e.g., oil price). In this way, the fuel cost during the whole travel may be expressed as:
Cost=Σi=1npiwi (1)
In the above way, the fuel filling optimization problem may be treated as the minimization of the above cost function. Meanwhile, in an example, remainder fuel (e.g., oil, gas) before filling must be larger than a given threshold Tat every turn. Specifically, the amount of the remainder oil after travel from i−1 to i may be represented by Ri, therefore all the constraints may be expressed as:
R
i
>T, i=2, 3, . . . , n
In various examples, to solve this problem, it is provided that fuel consumption model from terminal i−1 to i is represented as f (Ri-1, wi-1, Di-1,i) which is a function of Ri-1, wi-1 and Di-1,i (distance between terminal i−1 and i). In this way, the following function may be obtained:
R
i
=R
i-1
+w
i-1
−f(Ri-1,wi-1,Di-ti). (2)
Therefore n−1 constraints for the minimization may be listed as:
In various examples, fuel consumption models are nonlinear to wi, thus this problem may be solved by using nonlinear programming methods. In various examples described herein is a generic solution to optimize the amount of fuel filling by differential evolution (DE), which is efficient for real-parameter optimization regardless specific expression of f(Rn-1, wn-1, Dn-1,n). Differential evolution is a population based method that optimizes a problem by iteratively trying to improve a candidate solution with regard to fitness evaluation. A flowchart of a simple DE is shown in
In various examples, a DE beings with initialization (e.g., using initialization operation 214) of a plurality of chromosomes. In various examples, a chromosome may also be considered a candidate scenario. Chromosomes are interpreted as solutions of the problem, which are amount of fuel filling at each transfer terminal/location along a transmit path. In an examples, there are N chromosomes that are generated with initial values. In an embodiment, the values are random. In various examples, each chromosome contains n elements (n is the number of transfer terminals). In an example, the random values of chromosomes is limited in a range between 0 and the capacity of a fuel container for a vehicle, which is denoted as C. The capacity data may be retrieved from tank capability data 220. The random value may be a float (e.g., 1.2).
In various examples, after initialization has occurred of N chromosomes, mutation operation 234 and crossover operation 236 may be performed. During the mutation operation and crossover operation the following terminologies are used:
{right arrow over (X)}
D,G
={right arrow over (X)}
T,G
+F·({right arrow over (X)}1,G−{right arrow over (X)}2,G)
where F is a scalar number and, in various examples, is set in the interval of [0.4, 1.0].
Then a binomial crossover may be implemented as
where rand[0,1] is a random number between 0 and 1, jrand is a random integer number between 1 and I (I is the number of items/genes in the chromosome). XT,j,G is the j-th item of target vector {right arrow over (X)}T,G. In various examples, XD,j,G is the j-th item of donor vector {right arrow over (X)}D,G.
In various examples, an evaluation operation is utilized to evaluate the fitness of each chromosome and total cost (e.g., fuel cost evaluation 232). In the evaluation operation, the total cost of fuel may be calculated according to the chromosomes. Specifically, in an example, the i-th element of the k-th chromosome Xk,j,G (k=1, 2, . . . , N, i=1, 2, . . . , n) corresponds to wi in Eq. (1). Therefore, a fitness function may be expressed as:
Fitness({right arrow over (X)}k,G)=Σi=1npiXk,i,G (4)
In various examples, an infeasible solution repair operation is performed at those solutions (i.e., chromosomes) that violate the constraints in Eq. (3). In various examples, a certain percentage P (e.g., as set by a user or a default value) of high fitness infeasible chromosome (e.g., those solutions that evaluate to be better than X percentage of the other solutions) and repair them. In an example, evaluating the constraints may include checking the remainder (e.g., remainder evaluation 230) fuel of each transfer terminal sequentially according to Eq. (2). In an example, if Ri<T, i=2, 3, . . . , n, Ri is set to T then wi-1 may be repaired as:
w
i-1
=T−R
i-1
+f(Ri-1,wi-1,Di-1,i). (5)
In various examples, to keep population size constant over generations, a fixed number of chromosomes are selected to the next generation based on the fitness evaluation. In various examples, it is known that there are N chromosomes in the population. After mutation and crossover processing, each target chromosome generates a trail chromosome. In other words, N associated offspring are generated. For each target and trail chromosome pair, the one with better fitness (or repaired fitness) is selected for inclusion in the next generation.
Ina various examples, the above process is completed until a stopping condition occurs. In an example, the stopping condition may be a certain number of iterations of the above process (e.g., 500 iterations). In an example, the stopping condition may be when the solutions converge. In an example, converging means that the lowest cost solution does not change over X number of iterations or does not change more than Y %. In an example, combinations of stopping conditions may be used (e.g., 500 iterations or convergence).
In various examples, once the stopping condition has been met, a visualization of the results may be presented to a user. Presenting may include transmitting the results for display on a user terminal. The transmitted data may include data from the lowest cost solution after differential evolution. The data may include how much fuel to use at each transfer location along a path, the cost of fuel at each transfer location, a name of each location, and a total cost.
In various examples, upon receiving the request the fuel optimization system may collect data for determining the quantities of fuel to dispense into the vehicle at each terminal. For example, vehicle characteristics may be accessed for the vehicle from a database. One characteristic may be the fuel consumption function which defines the rate at which the vehicle uses fuel at various weights. The fuel consumption function may also indicate how much fuel is used over a particular distance. In other words, if a distance and starting amount of fuel are used an inputs, the fuel consumption function may output how much fuel will be left after the vehicle travels the inputted distance. Other characteristics data may include fuel capacity of the vehicle and safety thresholds for filling the fuel container of the vehicle (e.g., if the vehicle is an airplane there may be a minimum/maximum fuel levels at take-off and landing). Additionally, local fuel prices (e.g., in a cost-per unit of fuel dispensed) at each of the terminals may be retrieved, and the distances between the terminals.
At block 604, according to various examples, a set of candidate fueling scenarios is initialized. Each candidate fueling scenario may include an initial array of values, each value in the array of values indicating a quantity of fuel to dispense to the vehicle at one of the plurality of terminals along the transit route. In various examples, the initialized values are limited to the maximum fuel capacity of the vehicle as previously accessed. In an example, the initialized values are random (e.g., between 0 and the maximum fuel capacity).
At block 606, in various examples, the set of candidate scenarios is iteratively modified. For example, the candidate scenarios may be modified using a differential evolution method as discussed above. For example, the candidate scenarios may each go through mutation and crossover operations. Additionally, infeasible candidate scenarios may be repaired (e.g., changing a value in the array to meet safety thresholds, etc.). Determining whether a candidate is infeasible may include examining the values of the array against the safety threshold for the vehicle at each stop as well as using the fuel consumption function to make sure there is enough fuel to arrive at each terminal. In various examples, the resulting candidate scenarios may be compared against the original candidate scenarios to determine the most fit (e.g., lowest total cost) scenarios. The process of mutation and cross over may be repeated until a stopping condition occurs. The stopping condition may be set according to the user who submitted the request or by the fuel optimization system.
At block 608, the lowest total fuel cost candidate scenario of the set of candidate fueling scenarios is identified according to various examples. For example, a fitness value of each candidate scenario in the set may be calculated based on the cost of fuel at each of the plurality of terminals and the array of values in a respective candidate scenario. For example, the fitness value for a respective candidate scenario may be based on, for each terminal, multiplying the retrieved fuel cost for a terminal by the value in the array associated with that terminal, and then summing these values. According to various examples, the lowest total fuel cost scenario is the scenario with the lowest fitness value.
At block 610, according to various examples, the quantities of fuel to dispense in the vehicle at each of the plurality of terminals according to the identified lowest total fuel cost candidate scenario are transmitted for display. For example, the quantities may be transmitted back to the computing device from which the request was received and displayed in a graphical format.
In various examples, the following pseudo code may be used for fuel cost optimization:
Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules/components, etc may constitute either software modules (e.g., code embodied (1) on a non-transitory machine-readable medium or (2) in a transmission signal) or hardware-implemented modules. A hardware-implemented module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more processors may be configured by software (e.g., an application or application portion) as a hardware-implemented module that operates to perform certain operations as described herein.
In various embodiments, a hardware-implemented module may be implemented mechanically or electronically. For example, a hardware-implemented module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware-implemented module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware-implemented module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
The example computer system 700 includes a processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 704 and a static memory 706, which communicate with each other via a bus 708. The computer system 700 may further include a video display unit 710 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 700 also includes an alphanumeric input device 712 (e.g., a keyboard), a user interface (UI) navigation device 714 (e.g., a mouse), a disk drive unit 716, a signal generation device 718 (e.g., a speaker) and a network interface device 720.
The disk drive unit 716 includes a machine-readable medium 722 on which is stored one or more sets of instructions and data structures (e.g., software) 724 embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 724 may also reside, completely or at least partially, within the main memory 704 and/or within the processor 702 during execution thereof by the computer system 700, the main memory 704 and the processor 702 also constituting machine-readable media.
While the machine-readable medium 722 is shown in an example embodiment to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions or data structures. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, including by way of example semiconductor memory devices, e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
The instructions 724 may further be transmitted or received over a communications network 726 using a transmission medium. The instructions 724 may be transmitted using the network interface device 720 and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), the Internet, mobile telephone networks, Plain Old Telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.
Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.
Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.
