Patent Application
20210241138
The present disclosure relates to vehicle powertrain analysis, and more particularly, to systems and methods for optimizing vehicle powertrain configurations.
When a decision is made for a group of vehicles operating as part of a networked vehicle fleet, the factors that affect cost and benefits for powertrain configurations can vary widely, and may require substantial data input that represents actual proposed uses of the vehicles in the fleet. Using conventional fleet management techniques and systems, the time and effort required to obtain reliable and accurate representative data may be untenably inefficient. Current techniques may not consider lifecycle operating data associated with each vehicle, such as, for example, environmental conditions, operating conditions (e.g., mountain driving, city driving, drive time calculations, engine speed, idle time, damage event records, weather, etc. Such information may be useful to evaluate and predict a total lifecycle cost of fleet vehicle ownership in view of a particular powertrain option.
Although some known methods may track lifecycle cost-of-ownership for vehicles in a vehicle fleet, the conventional methods may fail to track operation and maintenance conditions, track expenses, or provide authentication functionality to verify the type and quality of work performed on the vehicles in the fleet. Moreover, known techniques may not predict and quantify uncertainty of customer-specific total cost of ownership within predetermined ranges of precision over a vehicle lifecycle.
The detailed description is set forth with reference to the accompanying drawings. The use of the same reference numerals may indicate similar or identical items. Various embodiments may utilize elements and/or components other than those illustrated in the drawings, and some elements and/or components may not be present in various embodiments. Elements and/or components in the figures are not necessarily drawn to scale. Throughout this disclosure, depending on the context, singular and plural terminology may be used interchangeably.
The systems and methods disclosed herein are configured to track crowdsourced cost-of-ownership data associated with vehicles in a networked vehicle fleet, and provide vehicle powertrain recommendations using a machine learning analytical model. In some aspects, the system may include a cloud-based portion configured and/or programmed to track vehicle-level and fleet-level operating conditions, track vehicle maintenance information, and track related expenses associated with vehicle ownership. The system may also include a vehicle-based portion that tracks maintenance events, operating conditions, and other aspects associated with particular vehicles. The vehicle-based portion may monitor maintenance and other events, using a vehicle telematics system(s) (among other tools), contextualize information associated with the vehicle(s), and report the contextualized information to one or more cloud-based centralized server(s). The system(s) may alternate between vehicle(s) and cloud-based infrastructure such that vehicles, and in some embodiments, specific vehicle parts, are tracked from manufacture to retirement from use in order to capture an accurate estimation of cost of ownership for the vehicle over its lifecycle in the fleet.
The tracked information can include maintenance data associated with the vehicle, which may provide specific and measurable information associated with how a vehicle in the fleet has been maintained, and also include operational information that quantifies a vehicle is used in the fleet. For example, the maintenance data can include individual vehicle-level maintenance information that includes identification for service personnel and organizations that have serviced the vehicle(s), and that include date, time, and other detailed information associated with vehicle repairs. The disclosed system(s) may utilize visual recognition systems that are installed and operable onboard the vehicles in the fleet to determine what maintenance was performed, and determine qualitative information associated with the maintenance such that the overall maintenance for the vehicle may be quantified and compared against other information to determine a path forward with respect to powertrain changes. In some aspects, this qualitative information include and/or incorporate maintenance details, such as (for example) a parts history of particular parts installed and/or replaced on each respective vehicle. The qualitative information may further include vehicle use information such as, for example, vehicle location tracking, weather information, vehicle use, and other factors. The operational data may include information from the on-board telematics system and/or the cloud-based infrastructure, that details particular vehicle usage and information.
The vehicle can also track sensor information of use, emissions, and environmental conditions to assess predicted parts degradation. The disclosed systems may use blockchain and/or other techniques to authenticate vehicle and parts data, and to distribute invoices associated with particular vehicle maintenance. On-vehicle sensors may detect and verify types and locations of maintenance performed. For example, a refueling station may automatically transmit an invoice pertaining to the vehicle. Vehicle sensors can further verify the quantity of fuel received.
Using the cloud-based and vehicle-based infrastructure to obtain crowdsourced information from the vehicle fleet in real-time (and/or substantially real-time) may save valuable time and significantly increase the accuracy of the data. The data obtained by the disclosed systems may have enhanced levels of accuracy and reliability because the vehicle and authentication network may provide immutable sources for the data, while resolving the reporting inconsistencies associated with conventional systems. Machine learning techniques may be utilized to generate actionable vehicle recommendations that recommend powertrain changes that optimize real-world factors specific to the fleet vehicles under consideration.
These and other advantages of the present disclosure are provided in greater detail herein.
The disclosure will be described more fully hereinafter with reference to the accompanying drawings, in which exemplary embodiments of the disclosure are shown, and not intended to be limiting.
As illustrated in
The server(s) 125 may be and/or include one or more mainframes, one or more Reduced Instruction Set Computers (RISCs) and/or architecture-based servers, one or more blade servers, or other cloud-based computing infrastructure. The one or more server(s) 125 may include and/or be communicatively coupled with one or more storage devices 130. In one or more example embodiments, the server(s) 125 may receive fleet operation data and maintenance data 115 (hereafter collectively referred to as “vehicle data 115”) from the vehicle(s) 105 in the fleet 110, and determine, at least in part based on the vehicle data 115, a total cost of lifecycle ownership for the vehicles in the fleet 110. The vehicle data 115 may include, for example, identification information associated with service technician(s) 160 that have serviced the vehicle(s) 105.
The server(s) 125 may be configured to perform aspects of the present disclosure both alone, and in conjunction with automobile computing devices installed on-board the vehicle(s) 105. One such example is an automotive computer 210, described hereafter with respect to
The server(s) 125 and/or a fleet manager computing system 135 may perform these steps using an analytical model for fleet prediction(s) minimization(s), and management 140 (hereafter “the analytical model 140”). Accordingly, the server(s) 125 may generate, based at least in part on total cost of lifecycle ownership analytics 145 for the vehicle(s) 105, and one or more vehicle powertrain configuration recommendation(s) 150. The server(s) 125 may also generate one or more messages comprising purchasing recommendation(s) 155 based at least in part on the recommendation(s) 150.
The vehicle(s) 205 may be a car, truck, or other type of passenger vehicle, a bus or other type of multiple passenger vehicle, a work vehicle, work machine, or other vehicle not shown or explicitly discussed herein. The vehicle(s) 205 may be substantially similar to the vehicle(s) 105 described with respect to
In some cases, the engine 215 may be customizable to allow operation of the vehicle(s) 205 as described with respect to embodiments described herein, and may be controlled using an engine controller 235 (which may be, in some aspects, an autonomous vehicle controller, a semi-autonomous vehicle controller, and/or another type of vehicle control module).
In some aspects, the sensor(s) 230 may include one or more audio and/or video input devices, such as a camera or other sensing mechanisms, that may be configured for receiving information indicative of vehicle operational conditions, maintenance data, vehicle damage event data, and other information. For example, one or more proximity sensors, piezoelectric sensors, or other type(s) of sensor may be configured to produce signal feedback information indicative of whether a damage event has damaged one or more parts. Additionally, the sensor(s) 230 may include one or more navigational receiver(s) such as, for example, a global positioning system (GPS. 100231 The sensor(s) 230 may include a visual recognition system having a camera, a microphone, and one or more proximity sensors configured to recognize human activity and interaction with the vehicle. For example, the visual recognition system may recognize individuals servicing the vehicle, and to recognize events during the day-to-day use of the vehicle such as, for example, refueling and driving. In another embodiment, the sensor(s) 230 may include a facial recognition system configured to determine one or more identities of individuals servicing the vehicle (e.g., the service technician(s) 160 depicted in
In an embodiment, the sensor(s) 230 may receive data such as refueling information, and other information described herein. For example, the sensor(s) 230 may function as part of a vehicle telematics system(s) that may work in conjunction with on-vehicle visual recognition system(s) that monitor maintenance and other events. The sensor(s) 230 may include various types of fuel sensors that may determine a quality and/or quantity of fuel used for the vehicle. For example, in an embodiment, the sensor(s) 230 may include one or more fuel-type sensors configured to evaluate a fuel quality, a fuel type, and/or other information associated with a refueling event. In one non-limiting example, the sensor(s) 230 may provide vehicle maintenance information that includes part-specific information, such as, for example, a radio frequency identification device (RFID) tag associated with a mechanical or electrical part installed on the vehicle(s) 205. In another aspect, the maintenance data may include parts data indicative of a part repair or part replacement associated with the vehicle(s) 205.
The automotive computer 210 may further include vehicle maintenance analytics tracking 240, and a vehicle operation analytics tracking system 250. One or more mobile device(s) 245 may be configured to communicate data to and from the automotive computer 210 using one or more wireless and/or wired communications protocols described herein. For example, one or more wireless transceiver(s) 255 may communicate information to and from the automotive computer 210 via the network(s) 120 (depicted in
As shown in
The computer 300 may include one or more network communications adapter(s) 325 enabled to communicatively connect the computer 300 with one or more networks 120. In some example embodiments, the network(s) 120 may be or include a telecommunications network infrastructure, which may connect the mobile device 245 with the server(s) 125. In such embodiments, the computer 300 can further include one or more telecommunications adaptor(s) 340. The computer 300 may further include and/or connect with one or more input devices 345 and/or one or more output devices 350 through the I/O adapter(s) 315.
The one or more processor(s) 305 are collectively a hardware device for executing program instructions (aka software), stored in a computer-readable memory (e.g., the memory 310). The one or more processor(s) 305 can be a custom made or commercially-available processor, a central processing unit (CPU), a plurality of CPUs, an auxiliary processor among several other processors associated with the server(s) 125, a semiconductor based microprocessor (in the form of a microchip or chip set), or generally any device for executing instructions.
The one or more processor(s) 305 may be disposed in communication with one or more memory devices (e.g., the memory 310 and/or one or more external database(s) 330, etc.) via a storage interface 320. The storage interface 320 can also connect to one or more memory devices including, without limitation, one or more database(s) 330, and/or one or more other memory drives (not shown in
The memory 310 can include any one or a combination of volatile memory elements (e.g., dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), etc.) and can include any one or more nonvolatile memory elements (e.g., erasable programmable read only memory (EPROM), flash memory, electronically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), etc.
The instructions in the memory 310 can include one or more separate programs, each of which can include an ordered listing of computer-executable instructions for implementing logical functions. In the example of
In one example, the memory 310 may include instructions for generating vehicle recommendation(s) indicative of powertrain changes for the vehicles in the fleet 110. For example, the processor(s) 305 may execute the instructions in the memory 310 to perform various acts described herein that generate one or more vehicle recommendation that can indicate one or more powertrain changes for the vehicle(s) 105, 205, etc. For example, the processor(s) 305 may determine the cost of lifecycle ownership using an analytical method (described hereafter in greater detail), which may be based on the fleet operation and maintenance data 115 (depicted in
In one example embodiment, the processor(s) 305 may perform analytical steps using the cost of ownership value(s), including determining one or more mean values of vehicle data. The processor(s) 305 may generate one or more set(s) of weighted information using the instructions in the memory 310, such as, for example, powertrain selection constraints. For example, the instructions, when executed by the one or more processor(s) 305, may cause the processor(s) to perform acts including determining a first standard deviation value associated with a first powertrain design option, determining a second standard deviation value associated with a second powertrain design option, and weighting the first standard deviation value and the second standard deviation value with one or more operations constraint values of a set of predetermined operations constraint values.
Accordingly, the processor(s) 305 may store information in or more data stores communicatively coupled with the server(s) 125. In one aspect, the server(s) 125 may access the database(s) 330 to retrieve information needed for calculation(s) described herein, such as, for example, a set of predetermined operations constraint values (which may be known and/or experimentally determined values associated with drivetrain workload, drive range of particular electric and/or hybrid drivetrain configurations, etc.) stored as part of the database(s) 330.
The program instructions stored in the memory 310 can further include application data 360, and instructions for controlling and/or interacting with the computer 300.
The I/O adapter 315 can connect a plurality of input devices 345 to the server(s) 125. The input devices can include, for example, a keyboard, a mouse, a microphone, a sensor, etc. The output device 350 can include, for example, a display, a speaker, a touchscreen, etc.
The I/O adapter 315 can further include a display adapter coupled to one or more displays. The I/O adapter 315 can be configured to operatively connect one or more input/output (I/O) devices 350 to the server(s) 125. For example, the I/O adapter 315 can connect a keyboard and mouse, a touchscreen, a speaker, a haptic output device, or other output device. The output devices 350 can include but are not limited to a printer, a scanner, and/or the like. Other output devices can also be included, although not shown in
According to some example embodiments, the server(s) 125 can include a mobile communications adapter 340. The mobile communications adapter 340 can include global positioning system (GPS), cellular, mobile, and/or other communications protocols for wireless communication.
In some embodiments, the server(s) 125 can further include a communications adapter 340 for coupling to the one or more network(s) 120.
The network(s) 120 can be and/or include Internet protocol (IP)-based network(s) for communication between the server(s) 125 and any external device. The network(s) 120 may transmit and receive data between the server(s) 125 and devices and/or systems external to the server(s) 125. In an exemplary embodiment, the network(s) 120 can be a managed IP network administered by a service provider. The network(s) 120 can be implemented in a wireless fashion, e.g., using wireless protocols and technologies, such as Wi-Fi, WiMAX, etc. The network(s) 120 can also connect with and/or include a wired network, e.g., an Ethernet network, a controller area network (CAN), etc., having any wired connectivity including, e.g., an RS232 connection, etc. The network(s) 120 can also be and/or include a packet-switched network such as a local area network, wide area network, metropolitan area network, the Internet, or other similar type of network environment. The network(s) 120 can be a fixed wireless network, a wireless local area network (LAN), a wireless wide area network (WAN) a personal area network (PAN), a virtual private network (VPN), intranet or another suitable network system.
Referring first to
In another example embodiment, information associated with the maintenance of the vehicle(s) 105B may include service quantification data that can quantify (numerically associate) service quality with events observed and recorded using the sensor(s) onboard the vehicle(s) 105B. For example, the vehicle data 115 may include maintenance technical data with an identification of the service technician(s) 160, an identification of the service address, dealership, mechanic's shop, etc., parts-level data indicating one or more parts associated with the vehicle(s) 105B, etc. It should be appreciated that, although not described in great detail, it is known in the art of vehicle tracking and maintenance to associated parts-level data within a database structure to track the life of a product from manufacture to retirement (that is, the date the part exceeds its useful life within the vehicle(s) 105B by replacement, destruction, malfunction, etc.). The maintenance data may include parts data indicative of one or more part replacement(s) associated with the vehicle(s) 105.
When parts are destroyed or replaced, the vehicle data 115 may also provide such an indication. For example, the operational and/or maintenance data (collectively the vehicle data 115) may include damage event data indicative of one or more damage events associated with the vehicle(s) 105. The vehicle data 115 may further include vehicle telematics data indicative of one or more vehicle use metrics associated with the vehicle. Vehicle use metrics can include, for example, a drive time, a drive distance, date information, engine information (RPMs, etc.), braking information, energy usage, battery life information, etc.
In another example, the operational data may include emission tracking data associated with the vehicle(s) 105. In another aspect, the maintenance data comprises a service quantification value indicative of a quality of vehicle service associated with the vehicle(s) 105.
At step 415, the method 400 may further include determining, based at least in part on the operational data and the maintenance data, a total cost of lifecycle ownership for the vehicle(s) 105. The cost of ownership analytics 145 may be a function of one or more analytical tools executed such as, for example, the vehicle maintenance analytics tracking 240 (as shown in
With respect to the direct modeling method, determining the total cost of ownership may be based at least in part on a Gaussian Process (GP) Model
y(x)=y′(x)+ε,
where y is a value indicative of a cost of ownership associated with one or more fleet configurations x, y′ is an operational variability value, and ε is a value indicative of a zero-mean Gaussian random variable associated with an unknown variance λ, such that λ is associated with an experimental variability. Considering this method in greater detail, the GP model for yt(x) is denoted by,
y′(x)˜GP(m(x),V(x,x′)).
where m(x) and V(x, x′) are the mean function and the covariance function, respectively, of the GP model.
A frequently used form of the mean and covariance functions may be represented by,
where p is the dimension of x, i.e. x=(x1, x2, . . . , xp)T. h(x) is a vector of user-predefined polynomial functions used to represent the prior mean, β is a vector of coefficients associated with h(x) for polynomial regression of a mean value, σ is a prior standard deviation for a single random variable in a random process, and ω=[ω1, ω2, . . . , ωp]T is the vector of roughness parameters that can be used to quantify nonlinearity of the process.
Constructing the GP model of the observed response y(x) may be similar to estimating the unknown parameters of the GP, i.e., ϕ={β, σ, ω, λ} by a Maximum Likelihood Estimation (MLE) approach, and thus may be solved using a numerical optimization strategy.
After the most likely values of ϕ are determined, the GP model is fully determined and can subsequently be used to predict the values at other designs. One benefit of using GPR is that GPR can quantify the interpolation uncertainty at the locations that have not yet been tested, and the experimental variability.
With respect to the Calibration model method, determining the total cost of ownership may be based at least in part on a Model Calibration process such that,
y(x)=ym(x)+δ(x)+ε,
where y is a cost of ownership value associated with one or more fleet configurations x, y′ is an operations variability value, δ(x) is a bias function associated with at least one predetermined experimental value, and ε is a value indicative of a zero-mean Gaussian random variable associated with an unknown variance λ, such that λ is an unknown variance associated with an experimental variability.
Using the mean and covariance function equation,
m(x)=b(x)Tβ.
the concept of GP modeling may be applied by parameterizing δ(x) by {βδ, σδ, ωδ}. In one example method for tracking the equation, it may be beneficial to generate a GP model for the existing model ym(x) (a “model of the model”, sometimes referred to as a “metamodel”), by {βm, σm, ωm}. Therefore, the set of unknown parameters ϕto be estimated for this option is {βδ, σδ, ωδ, βm, σm, ωm, λ}. In some aspects, it may be computationally more expensive than estimating the smaller parameter set in direct modeling method, but in return the accuracy may be higher, as the Calibration model uses information from ym(x) that is derived from past experience and knowledge.
After determining the total cost of ownership for the vehicle using one or more processes and/or models described above, at step 420, the method 400 may include generating, based at least in part on the total cost of ownership for the vehicle(s) 105, a vehicle recommendation (e.g., one or more of the recommendation(s) 150 and/or 155 in
The operational data 510 may include any one or more operational data types, including for example, damage event data 518, telematics data 520, vehicle use data 522, emissions tracking data 528, and/or refueling data 530. The vehicle use data 522 may include information such as, for example, GPS data 524, and/or other data 526 (representing an open-ended category of information that may indicate operational aspects of a vehicle).
It is understood in advance that although this disclosure includes a detailed description on cloud computing, implementation of the teachings recited herein are not limited to a cloud computing environment. Rather, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed.
In the above disclosure, reference has been made to the accompanying drawings, which form a part hereof, which illustrate specific implementations in which the present disclosure may be practiced. It is understood that other implementations may be utilized, and structural changes may be made without departing from the scope of the present disclosure. References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a feature, structure, or characteristic is described in connection with an embodiment, one skilled in the art will recognize such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
It should also be understood that the word “example” as used herein is intended to be non-exclusionary and non-limiting in nature. More particularly, the word “exemplary” as used herein indicates one among several examples, and it should be understood that no undue emphasis or preference is being directed to the particular example being described.
A computer-readable medium (also referred to as a processor-readable medium) includes any non-transitory (e.g., tangible) medium that participates in providing data (e.g., instructions) that may be read by a computer (e.g., by a processor of a computer). Such a medium may take many forms, including, but not limited to, non-volatile media and volatile media. Computing devices may include computer-executable instructions, where the instructions may be executable by one or more computing devices such as those listed above and stored on a computer-readable medium.
With regard to the processes, systems, methods, heuristics, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps could be performed simultaneously, that other steps could be added, or that certain steps described herein could be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating various embodiments and should in no way be construed so as to limit the claims.
Accordingly, it is to be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications other than the examples provided would be apparent upon reading the above description. The scope should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that future developments will occur in the technologies discussed herein, and that the disclosed systems and methods will be incorporated into such future embodiments. In sum, it should be understood that the application is capable of modification and variation. All terms used in the claims are intended to be given their ordinary meanings as understood by those knowledgeable in the technologies described herein unless an explicit indication to the contrary is made herein. In particular, use of the singular articles such as “a,” “the,” “said,” etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary. Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments could include, while other embodiments may not include, certain features, elements, and/or steps. Thus, such conditional language is not generally intended to imply that features, elements, and/or steps are in any way required for one or more embodiments.
