Systems and methods for assessing equipment with telematics data

Abstract

Systems and methods for assessing a vehicle are described herein. The provider computing system includes one or more processors and at least one memory storing instructions thereon that, when executed by the one or more processors, cause the one or more processors to perform operations. The operations include receiving, from at least one vehicle via a network, vehicle data regarding the at least one vehicle, the vehicle data associated with one or more evaluation factors. The operations include analyzing the one or more evaluation factors to output a valuation metric, transforming the valuation metric into a human-readable message and transmitting, via the network, the human-readable message to a user device. The operations include causing the user device to display the human-readable message including the valuation metric.

Description

SYSTEMS AND METHODS FOR ASSESSING EQUIPMENT WITH TELEMATICS DATATECHNICAL FIELD

[0001] The present disclosure relates generally to systems and methods for assessing equipment, such as vehicles. More particularly, the present disclosure relates to systems, computer-readable media, and methods for assessing equipment, such as a valuation of vehicles, based on telematics data regarding the equipment.BACKGROUND

[0002] Engine-powered systems, such as automotive vehicles, are assessed based on a variety of information such as a type of vehicle, an age of a vehicle, a usage of a vehicle (e.g., a number of operating hours, a travelled miles number, etc. ) , a maintenance history regarding the vehicle, etc. The assessment of the system may be used for a variety of reasons, but generating the assessment can be a difficult endeavor.SUMMARY

[0003] One embodiment relates to a provider computing system. The provider computing system includes one or more processors and at least one memory storing instructions thereon that, when executed by the one or more processors, cause the one or more processors to perform operations. The operations include receiving, from at least one vehicle via a network, vehicle data regarding the at least one vehicle, the vehicle data associated with one or more evaluation factors. The operations include analyzing the one or more evaluation factors to output a valuation metric, transforming the valuation metric into a human-readable message and transmitting, via the network, the human-readable message to a user device. The operations include causing the user device to display the human-readable message including the valuation metric.

[0004] Another embodiment relates to a method for generating an equipment assessment. The method includes receiving, by a computing system and from at least one vehicle via a network, vehicle data regarding the at least one vehicle, the vehicle data associated with one or more evaluation factors. The method includes analyzing, by the computing system, the vehicle data associated with the one or more evaluation factors, and generating, by the computing system and based on analyzing the vehicle data, a valuation metric for the at least one vehicle. The method includes transforming, by the computing system, the valuation metric into a human-readable message, and transmitting, by the computing system, the human-readable message to a user device.

[0005] Still another embodiment relates to a non-transitory computer-readable medium having computer-executable instructions embodied therein that, when executed by at least one processor of a computing system, cause the computing system to perform operations. The operations include receiving, from at least one vehicle via a network, vehicle data regarding the at least one vehicle, the vehicle data associated with one or more evaluation factors. The operations include analyzing the one or more evaluation factors to output a valuation metric and transforming the valuation metric into a human-readable message. The operations include transmitting, via the network, the human-readable message to a user device and causing the user device to display the human-readable message including the valuation metric.

[0006] Numerous specific details are provided to impart a thorough understanding of embodiments of the subject matter of the present disclosure. The described features of the subject matter of the present disclosure may be combined in any suitable manner in one or more embodiments and / or implementations. In this regard, one or more features of an aspect of the invention may be combined with one or more features of a different aspect of the invention. Moreover, additional features may be recognized in certain embodiments and / or implementations that may not be present in all embodiments or implementations.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1 is a block diagram of a system for assessing equipment, such as vehicles, according to an exemplary embodiment.

[0008] FIG. 2 is a flow chart of a method for assessing equipment, such as vehicles, performed by the system of FIG. 1, according to an exemplary embodiment.

[0009] FIG. 3 is a flow chart of a method for assessing equipment, such as vehicles, according to another exemplary embodiment.

[0010] FIG. 4 is a flow chart of a method of applying a degradation model to determine a remaining useful life of equipment, according to an exemplary embodiment.

[0011] These and other features, together with the organization and manner of operation thereof, will become apparent from the following detailed description when taken in conjunction with the accompanying drawings.DETAILED DESCRIPTION

[0012] Following below are more detailed descriptions of various concepts related to, and implementations of methods, apparatuses, and systems for equipment, particularly vehicle, assessment, such as valuation, based on evaluation factors and other vehicle data. The various concepts introduced herein may be implemented in any number of ways, as the concepts described are not limited to any particular manner of implementation. Examples of specific implementations and applications are provided primarily for illustrative purposes.

[0013] Referring to the Figures generally, the various embodiments disclosed herein relate to systems, apparatuses, and methods for determining, identifying, and / or calculating a valuation multiplier based on an estimated remaining useful life of a piece of equipment (e.g., a vehicle) to determine an assessment of the vehicle. As used herein, a “remaining useful life” or RUL refers to the estimated length of time a RUL object (e.g., a vehicle, an engine of a vehicle, an exhaust aftertreatment system of a vehicle, etc. ) before the object reaches a desired inspection point (i.e., an estimated / expected useful life (EUL) , a remaining lifetime, time to failure, etc. ) . The desire inspection point may be variable under various circumstances and can refer to, for example, a failure point, a likely to fail point, and / or a point that requires or may require inspection, repair, and / or replacement regarding the object.

[0014] The systems, apparatuses, and methods disclosed herein relate to operations for assessing equipment, such as vehicles. In one embodiment, the operations include detecting, sensing, predicting, or otherwise determining vehicle data regarding the operation of a vehicle. As used herein, the phrase “vehicle data” and similar terms are used to mean an operational state, a control method or sequence, and / or other parameters of a vehicle. Thus, the vehicle data may include settings for the vehicle or a system thereof (e.g., maximum speed, maximum load, maximum idle time, etc. ) as well as operational characteristics of the vehicle or a system / component thereof (e.g., engine temperatures during certain operating conditions, duty cycle information, etc. ) . The vehicle data may take the form a numeric, alpha, alphanumeric, and / or other types of data structures. The vehicle data may be detected or sensed by an actual sensor (e.g., real sensor) , determined by a virtual sensor based on one or more other acquired data (e.g., a calculation by a processor) , determined by comparing data to a lookup table, determined using one or more statistical models (e.g., a regression model, a machine learning model, etc. ) , and / or another method or process described herein. Examples of vehicle data may include but are not limited to: a maximum allowed engine speed, a maximum allowed load, a maximum torque, a maximum power delivery, maximum values before a derate condition (e.g., throttle and / or boost time) , a fuel consumption rate (e.g., per mile, per time period, etc. ) , and / or other operational parameters associated with a piece of equipment, such as a vehicle. The operational parameters may also include engine, powertrain information, and / or aftertreatment system such as equipment performance data including, but not limited to, efficiency of one or more components or systems (e.g., SCR, DOC, DPF, other catalysts, other systems and / or components such as a turbocharger) , temperatures (e.g., exhaust gas and intake air temperatures) , pressures (e.g., charge, DPF, etc. ) . The vehicle data may, in some embodiments, include metadata such as a vehicle or engine identifier, a timestamp, a geo-location stamp, and / or other suitable metadata. Accordingly, sensors may sense or detect vehicle data including one or more operational parameters, and a processor may transform the detected or determined operational data or parameter to include the metadata.

[0015] As described herein, a provider computing system associated with a provider may be coupled to one or more pieces of equipment (e.g., vehicles) . The provider may provide goods and / or services, such as engines for a vehicle. A provider computing system may advantageously determine an estimated assessment metric (e.g., an estimated valuation multiplier) that accounts for specific data regarding predefined components and / or systems of a vehicle (e.g., predefined critical parts of the vehicle) . For example, the provider computing system may receive vehicle data regarding equipment performance, vehicle maintenance and operation history, and, among other specific data, vehicle appearance / condition (i.e., “the evaluation factors” ) . The provider computing system utilizes these evaluation factors as inputs to one or more models that may determine or estimate a remaining useful life of a vehicle. The remaining useful life output by the model (s) may be directly factored into an assessment metric (e.g., a valuation multiplier) . Based on shifts in the valuation multiplier, the provider computing system can generate recommendations to adjust vehicle operation or schedule maintenance, aiming to support vehicle performance and reduce wear on components. For example, if the assessment metric reflects elevated wear due to abnormal engine operation or infrequent maintenance (e.g., less maintenance than a fleet average or preset threshold) , the provider computing system may recommend a schedule adjustment or changes in operation. Advantageously, the assessment metric and associated recommendations for improving the assessment metric may result in an improvement to operation, such as fuel economy and / or emissions reductions. For example, negative changes may cause an operator to reduce vehicle idle time, thereby improving fuel economy. As another example, negative changes in the assessment metric may cause an operator, vehicle owner, or vehicle provider to schedule maintenance, for example to the aftertreatment system, thereby causing the aftertreatment system to maintain proper emission levels.

[0016] The valuation metric (e.g., valuation multiplier) may be utilized in combination with a current vehicle valuation that is retrieved and / or received from a third-party (e.g., trade in value or bluebook value from a third-party computing system, etc. ) to determine a more accurate vehicle value based on the direct evaluation of the vehicle’s predefined critical parts (e.g., the engine, the transmission, the aftertreatment system, etc. ) (which may change based on a desire of an operator or other manager) . The valuation multiplier, evaluation factors, and recommended vehicle valuation may all be transmitted to and displayed on a client device. In this way, a client (e.g., a vehicle operator, a fleet manager, etc. ) may adjust their vehicle operation based on the changes in the vehicle valuation multiplier and remaining useful life.

[0017] The systems, computer-readable media, and methods described herein provide a technical solution to a technical problem of determining an assessment, and particularly a valuation metric, based on data associated with the operation and maintenance of one or more components of a piece of equipment, and specifically, a vehicle. The current valuation methods do not evaluate vehicle specific powertrain data. Traditional assessment models often rely on general factors like mileage, age, and basic maintenance and operation history, which exclude real-time operational data and / or the specific condition of components of the vehicle. Technically and beneficially, the valuation methods and systems described herein may utilize data associated with predefined components of the vehicle, such as the engine, transmission, and aftertreatment system to reduce information gaps in the valuation process and increase accuracy of estimated vehicle values and / or specific vehicle component values (e.g., the value of the engine, electric motor, transmission, etc. ) . Sensors are integrated throughout the vehicle to collect data associated with the operation of the vehicle. The provider computing system may retrieve data from the sensors frequently (e.g., continuously or nearly continuously) , process the sensor data, and apply one or more models to the sensor data or subsets of the sensor data to generate one or more assessment metrics. Technically and beneficially, the assessment metrics may be utilized to predict upcoming failure of the vehicle or of a specific vehicle component (e.g., by estimating the remaining useful life of the vehicle or the specific vehicle component) . Thus, the present disclosure may provide a technical solution to the technical problem of prognostics and / or diagnostics of vehicle and / or components thereof to improve an overall health of the system or component, enable specific failure predictions, assist with inventory prediction, and other present technical challenges. Additionally, the systems and methods described herein assess the impact of operational actions on a value, a health, or assessment of a vehicle. Technically and beneficially, the systems and methods described herein can provide actionable recommendations for adapting use patterns, vehicle operation, extending the lifespan and value of the vehicle (i.e., improving overall vehicle health and / or health of individual vehicle components) . These and other features and benefits are explained more fully herein below.

[0018] Referring now to FIG. 1, a block diagram of a system 100 for assessing pieces of equipment, such as vehicles, is shown, according to an exemplary embodiment. In some embodiments, the system 100 includes a provider computing system 20 associated with a provider entity, one or more pieces of equipment shown as vehicle (s) 10, and one or more client devices 30. The provider computing system 20, the vehicle (s) 10, and the client device 125 are each communicatively coupled to each other via a network 50. Specifically, the provider computing system 20, the computing and / or control systems of a vehicle 10, and / or the client device 30 are communicatively coupled to the network 50 such that the network 50 permits the direct or indirect exchange of data, values, instructions, messages, and the like (represented by the double-headed arrows in FIG. 1) .

[0019] The network 50 may be any type of wired and / or wireless network, such as a local network, a wide area network, the Internet, a cellular network or any other appropriate type of network. The systems and components described herein may communicate via any combination of wired and / or wireless networks (e.g. a cellular network, the Internet, Wi-Fi, Wi-Max, a proprietary provider network, a proprietary service provider network, and / or any other kind of wireless and / or wired network) . In operation, the network 50 facilitates communication of data between the client device 30 and other computing systems associated with a service provider (e.g. provider 5) or with a customer or business partner of the service provider.

[0020] The client device 30 is a user computing device associated with a user. The user may be an operator of the vehicle 10, an owner of the vehicle 10, and / or a customer of the provider 5. The client device 30 may be a computing device, such as a laptop computer, a desktop computer, a tablet, a smartphone, and the like (i.e., a “user device” ) . In some embodiments, the client device is configured to communicably couple to the vehicle 10. In other embodiments, the client device 30 is a dashboard display or other user display device coupled to the vehicle 10.

[0021] The client device 30 may be configured to store one or more applications and / or executables to facilitate tracking data associated with the system and / or one or more components included therewith (e.g., vehicle data, fleet data, and / or user device data) , managing real-time incoming data, generating or updating statistical models, and / or any other operation described herein. In some arrangements, the applications and / or executables are incorporated with an existing application provided by the provider computing system 20. In some arrangements, the applications and / or executables are separate software applications implemented by the provider computing system 20. The applications and / or executables may be downloaded by the client device 30 prior to its usage, hard coded into the memory of the processing circuit of the client device 30, or be a network-based or web-based interface application such that the provider computing system 20 provides a web browser to access the application, which may be executed remotely from the client device 30.Accordingly, the provider computing system 20 includes software and / or hardware capable of implementing a network-based or web-based application. For example, in some instances, the applications and / or executables include software such as HTML, XML, WML, SGML, PHP (Hypertext Preprocessor) , CGI, and like languages.

[0022] The system 100 may include a plurality of pieces of equipment, such as vehicles 10. The vehicle 10 may be a vehicle having a power unit such as an engine (e.g., a diesel engine, an internal combustion engine, a hybrid engine, an electric engine, etc. ) or other power unit such as a battery, a fuel cell, etc. In some embodiments, the vehicle 10 is part of a fleet that includes one or more vehicles. In some embodiments, the system 100 includes more vehicles than the vehicle 10. For example, the system 100 may include all the vehicles in the fleet. The vehicle 10 and / or the fleet is associated with at least one of the service provider, a direct customer of the service provider, a third party customer, a location (e.g., a city, a state, a region, a country, etc. ) , a vehicle type (e.g., engine type, chassis type, workload type, etc. ) , and / or any other parameter associated with the vehicle 10 or fleet. For example, the vehicle 10 and / or the fleet may be associated with a first customer and may include one or more vehicles.

[0023] In the example shown, the vehicle 10 can be any type of passenger or commercial automobile, such as a commercial on-road vehicle including but not limited to, a line haul truck (e.g., a semi-truck, a school bus, a garbage truck, etc. ) ; a non-commercial on-road vehicle, such as a car, truck, sport utility vehicle, cross-over vehicle, van, minivan, automobile; an off-road vehicle, such as tractor, airplane, boat, forklift, front end loader, etc. ; and / or any other type of machine or vehicle that is suitable for the systems described herein. In some embodiments, the vehicle may be a stationary vehicle (e.g., a generator, an air compressor, etc. ) .

[0024] The vehicle 10 is shown to include at least one vehicle controller 120, at least one communication interface 130, and, optionally, a telematics device 12. The vehicle controller 120 may be structured as one or more vehicle controllers / control systems, such as one or more electronic control units. The vehicle controller 120 may be separate from or included with at least one of a transmission control unit, an exhaust aftertreatment control unit, a powertrain control module, an engine control module or unit, or other vehicle controllers. In one embodiment, the components of the vehicle controller 120 are combined into a single unit. In another embodiment, one or more of the components may be geographically dispersed throughout the system or vehicle. In this regard, various components of the vehicle controller 120 may be dispersed in separate physical locations of the vehicle 10. All such variations are intended to fall within the scope of the disclosure.

[0025] The telematics device 12 may include, but is not limited to, a location positioning system (e.g., GPS, GNSS, etc. ) to track the location of the vehicle (e.g., latitude and longitude data, elevation data, etc. ) , one or more memory devices for storing the tracked data, and one or more electronic processing units for processing the tracked data. In some embodiments, the telematics device 12 is coupled to a communication interface 130 for facilitating the exchange of data between the telematics unit and the vehicle controller 120. The telematics device 12 may enable communication with one or more remote devices (e.g., provider computing system 20) . In other embodiments, the telematics device 12 may be excluded from the vehicle 10, and the communication interface 130 enables in-vehicle and out-of-vehicle communications. For example, the communication interface 130 may be configured as any type of mobile communication interface or protocol including, but not limited to, Wi-Fi, WiMAX, Internet, Radio, Bluetooth, ZigBee, satellite, radio, Cellular, GSM, GPRS, LTE, and the like. In this embodiment, the telematics device 12 may be excluded and the vehicle controller 120 may couple directly to the network 50 (e.g., via wired and / or wireless connections) and exchange information directly without the intermediary of telematics device 12.

[0026] The vehicle 10 may include one or more sensors. The sensors may be one or more physical (real) and / or virtual sensors. For example, the vehicle 10 may include temperature sensors. The temperature sensors acquire data indicative of or, if virtual, determine an approximate temperature of various components or systems, such as the exhaust gas at or approximately at their disposed location. The sensors may also include an emissions sensor that acquire data indicative of or, if virtual, determine an approximate amount or concentration of emissions in the exhaust gas stream at or approximately at their disposed locations (e.g., immediately downstream of the engine, immediately downstream of the aftertreatment system, etc. ) . A speed sensor is configured to provide a speed signal to the vehicle controller 120 indicative of a vehicle speed. In some embodiments, there may be a sensor that provides a speed of the vehicle (e.g., miles-per-hour) while in other embodiments the speed of the vehicle may be determined by other sensed or determined operating parameters of the vehicle (e.g., engine speed in revolutions-per-minute may be correlated to vehicle speed using one or more formulas, a look-up table (s) , etc. ) . The sensors may also include a fuel tank level sensor that determines a level of fuel in the vehicle 10, such that a fuel economy may be determined based on the speed of the vehicle relative to the fuel consumed by the engine (i.e., to determine a distance-per-unit of fuel consumed, such as miles-per-gallon or kilometers-per-liter, etc. ) . Additional sensors may be used alone or in combination to determine a fuel economy for the vehicle 10 include, but are not limited to, an oxygen sensor, an engine speed sensor, a mass air flow (MAF) sensor, and a manifold absolute pressure sensor (MAP) . Based on the foregoing, the vehicle controller 120 may determine a fuel economy for the vehicle 10 which may be provided to provider computing system 20 via the network 50.

[0027] The sensors may include a flow rate sensor that is structured to acquire data or information indicative of flow rate of a gas or liquid through the vehicle (e.g., exhaust gas through an aftertreatment system or fuel flow rate through an engine, exhaust gas recirculation flow at a particular location, a charge flow rate at a particular location, an oil flow rate at various positions, a hydraulic flow rate at a particular location, etc. ) . The flow rate sensor (s) may be coupled to the engine, an aftertreatment system of the vehicle 10, and / or elsewhere in the vehicle 10.

[0028] It should be understood that other different / additional sensors may also be included with the vehicle 10, such as an accelerator pedal position (APP) sensor, a pressure sensor, an engine torque sensor, a battery sensor, etc. Those of ordinary skill in the art will appreciate and recognize the high configurability of the sensors and their associated positions in the vehicle 10. The vehicle controller 120 is structured to provide the operational data to a communicatively coupled device (e.g., the provider computing system 20 and / or the client device 30) via the communication interface 130 or, in some embodiments, via the telematics unit / device 12.

[0029] The vehicle 10 may include a powertrain. In some examples, the powertrain includes an engine. The engine may be any type of engine that generates exhaust gas, such as a gasoline, natural gas, or diesel engine, and / or any other suitable engine. The engine may be an internal combustion engine (ICE) . The ICE may consume fuel (e.g., diesel, gasoline, propane, natural gas, hydrogen, etc. ) to generate power. The engine may include one or more cylinders and associated pistons whereby the one or more cylinders may be arranged in a variety of ways (e.g., v-arrangement, inline, etc. ) . Air from the atmosphere is combined with fuel, and combusted, to produce power for the vehicle. Combustion of the fuel and air in the compression chambers of the engine produces exhaust gas that is operatively vented to an exhaust pipe and to, in some embodiments, an exhaust aftertreatment system. The engine may also include an engine control module (ECM) to manage and control various aspects of the engine. The engine can also include a turbocharger. The turbocharger can force more air, such as oxygen, into the engine to increase the power output of the engine.

[0030] In some examples the engine is a part of a hybrid powertrain system having a combination of an internal combustion engine and an electric motor coupled to at least one battery. In some embodiments, the hybrid engine system may be configured as a mild-hybrid powertrain, a parallel hybrid powertrain, a series hybrid powertrain, or a series-parallel powertrain. In any of these embodiments, the battery may be electrically coupled to the engine, the electric motor, and / or another component of the system (e.g., a regenerative braking system, an alternator, etc. ) . For example, the vehicle 10 may include a fuel cell stack that includes individual membrane electrodes that use hydrogen and oxygen to produce electricity to power an electric engine, a fuel tank for storing hydrogen fuel, and one or more batteries for storing electrical power.

[0031] The powertrain may additionally include a transmission that is structured to accommodate any of the arrangements of the powertrain described above. For example, the transmission may be a manual transmission, where the driver manually selects gears using a clutch and gear stick, or an automatic transmission, which automatically changes gear ratios based on vehicle speed, load, and other driving conditions. In other examples, for example, in hybrid engine systems, the transmission may be an electronically controlled variable transmission (eCVT) , which divides power between an ICE and an electric motor using a planetary gear. While not shown, the vehicle 10 may also include additional systems, such as the exhaust aftertreatment system, a lubrication system, a hydraulic system, and / or other systems.

[0032] Referring more particularly to the vehicle controller 120. The vehicle controller 120 is shown to include at least one processing circuit 122. The processing circuit 122 includes at least one processor 124 coupled to at least one memory device 126. The vehicle controller further can include the communication interface 130.

[0033] The vehicle controller 120 may receive vehicle data from the telematics device 12 and / or the sensors disposed thereon. The vehicle controller 120 may organize the vehicle data into a variety of evaluation factors. In one embodiment, the evaluation factors include three main factors: (1) equipment performance data, (2) maintenance and operation history, and / or (3) vehicle or system appearance / condition. In other embodiments, a different number and / or type of evaluation factors are utilized. Each evaluation factor defines or is associated with a category of vehicle data. For example, the equipment performance factor may include information or data relating to oil consumption and / or powertrain usage (e.g., hours of operation, distance such as mileage traveled) . The maintenance and operation history may include data or information relating to maintenance or service of the vehicle 10 or component thereof, such as warranty information, a performance log of critical parts (e.g., transmission, battery, electrical power system, exhaust system, etc. ) , a damage history of the critical parts (i.e., part damage) , an accident history, etc. The maintenance and operation may also include data or information relating to a loading history (e.g., overloading) , overspeed events, abnormal operation, fuel quality, ODI (e.g., frequency of oil changes) , type of oil used in an oil change, etc. The vehicle or system appearance / condition factor may include, for example, dents, cracks, paint issues (e.g., scratches, chips, wear marks, etc. ) , misalignments in body panels, and the like.

[0034] The memory 126 may store the vehicle data 128. This includes information associated with one or more of the components of the vehicle 10 (e.g., type of vehicle, age, mileage, maintenance data, fault code history, etc. ) . The vehicle data 128 also includes information regarding the operation of the vehicle, such as powertrain information (e.g., oil consumption, powertrain mileage, operating time, etc. ) . The vehicle data 128 may also include a powertrain serial number, a vehicle identification number (VIN) , a calibration identification and / or verification number, a make of the vehicle, a model of the vehicle, a unit number of a power unit of the vehicle, a unique identifier regarding a controller of the vehicle (e.g., a unique identification value (UID) ) , and / or a vehicle maintenance and operation history.

[0035] The communication interface 130 may include any type and number of wired and / or wireless protocols (e.g., any standard under IEEE 802, etc. ) . For example, a wired connection may include a serial cable, a fiber optic cable, an SAE J1939 bus, a CAT5 cable, or any other form of wired connection. In comparison, a wireless connection may include the Internet, Wi-Fi, Bluetooth, ZigBee, cellular, radio, etc. In one embodiment, a controller area network (CAN) bus including any number of wired and wireless connections provides the exchange of signals, information, and / or data between the vehicle controller 120, the telematics device 12, and a remote computing system, such as the provider computing system 20. In still another embodiment, the communication between the components of the vehicle 10 (e.g., the vehicle controller 120, telematics device 12, and the communication interface 130) is via the unified diagnostic services (UDS) protocol.

[0036] As alluded above, the vehicle controller 120 may be structured to include the entirety of the communication interface 130 or include only a portion of the communication interface 130. In these latter embodiments, the communication interface 130 is communicatively coupled to the processing circuit 152. In other embodiments, the vehicle controller 120 is substantially separate from the communication interface 130. For example, the vehicle controller 120 and the communication interface 130 are separate control systems but may be communicatively and / or operatively coupled. Furthermore, the communication interface 130 may work together or in tandem with the telematics device 12 in order to communicate with other vehicles in the fleet of one or more vehicle (s) 10.

[0037] The provider computing system 20 is a remote computing system such as a remote server, a cloud computing system, and the like. Accordingly, as used herein, “remote computing system” and “cloud computing system” are interchangeably used to refer to a computing or data processing system that has terminals distant from the central processing unit (e.g., processing circuit 102) from which users and / or other computing systems (e.g., the client device 30 and / or computing / control systems of the vehicle 10) communicate with the central processing unit. In some embodiments, the provider computing system 20 is part of a larger computing system such as a multi-purpose server, or other multi-purpose computing system. In other embodiments, the provider computing system 20 is implemented on a third-party computing device operated by a third party service provider (e.g., AWS, Azure, GCP, and / or other third party computing services) .

[0038] The provider 5 or provider institution / entity is a service and / or system / component provider (e.g., an engine manufacturer for the engine of the vehicle 10, a vehicle manufacturer, a fleet operator, an exhaust aftertreatment system manufacturer, etc. ) . In the example shown, provider is associated with, and particularly controls or operates, the provider computing system 20. The provider computing system is a remote computing system relative to the vehicle 10 and the client device 30. Accordingly, an employee or other operator associated with the service and / or system / component provider may operate the provider computing system.

[0039] As shown in FIG. 1, the provider computing system 20 includes at least one processing circuit 102, a database 108, one or more specialized processing circuits shown as a vehicle assessment circuit 114, and a provider communication interface 116. The at least one processing circuit 102 is coupled to the specialized processing circuits, the database 108. The at least one processing circuit 102 includes at least one processor 104 and at least one memory device 106. The memory 106 is one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage) for storing data and / or computer code for completing and / or facilitating the various processes described herein. The memory 106 is or includes non-transient volatile memory, non-volatile memory, and non-transitory computer storage media. The memory 106 includes database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein. The memory 106 is communicatively coupled to the processor 104 and includes computer code or instructions for executing one or more processes described herein. The processor 104 is implemented as one or more application specific integrated circuits (ASICs) , field programmable gate arrays (FPGAs) , a group of processing components, or other suitable electronic processing components. As such, the provider computing system 20 is configured to run a variety of application programs and store associated data in a database and / or the memory 106.

[0040] The provider communication interface 116 is structured to receive communications from and provide communications to other computing devices associated with the provider computing system 20. The provider communication interface 116 is structured to exchange data, communications, instructions, and the like with an input / output device of the components of the system 100. In some arrangements, the provider communication interface 116 includes communication circuitry for facilitating the exchange of data, values, messages, etc. between the provider communication interface 116 and the components of the provider computing system 20. In some arrangements, the provider communication interface 116 includes machine-readable media for facilitating the exchange of information between the provider communication interface 116 and the components of the provider computing system 20. In some arrangements, the provider communication interface 116 includes any combination of hardware components, communication circuitry, and machine-readable media.

[0041] In some embodiments, the provider communication interface 116 includes a network interface. The network interface is used to establish connections with other computing devices by way of the network 50. The network interface includes program logic that facilitates connection of the provider computing system 20 to the network 50. In some arrangements, the network interface includes any combination of a wireless network transceiver (e.g., a cellular modem, a Bluetooth transceiver, a Wi-Fi transceiver) and / or a wired network transceiver (e.g., an Ethernet transceiver) . For example, the provider communication interface 116 includes an Ethernet device such as an Ethernet card and machine-readable media such as an Ethernet driver configured to facilitate connections with the network 50. In some arrangements, the network interface includes the hardware and machine-readable media sufficient to support communication over multiple channels of data communication. Further, in some arrangements, the network interface includes cryptography capabilities to establish a secure or relatively secure communication session in which data communicated over the session is encrypted. Accordingly, the provider computing system 20 may be structured to facilitate encrypting and decrypting data sent to and from the provider computing system 20. For example, the provider computing system 20 may be structured to encrypt data transmitted by the provider communication interface 116 to other devices on the network 50, such as the client device 30. Encrypting data may include transforming digital data using one or more mathematical techniques, along with a unique token (e.g., password, key, etc. ) . Decrypting data may include transforming encrypted digital data using one or mathematical techniques and the unique token to return the digital data to a readable state. Various methods of encrypting and / or decryption may be used including public-key encryption, symmetric key encryption, etc. In an example embodiment, the provider communication interface 116 is structured to  receive information from the client device 30 and provide the information to the components of the system 100, such as the vehicle 10.

[0042] The memory 106 may store a database 108, according to some arrangements (alternatively, the database 108 may be separate from the memory 106 as shown) . The database 108 is an information or data repository that retrievably stores data associated with the provider computing system 20 and / or any other component of the system 100. That is, the data includes information associated with each of the components of the system 100. For example, the data includes information about one or more vehicles such as the vehicle 10.Vehicle data 128 includes information about a specific vehicle 10, whereas fleet data 112 includes information about a fleet of associated vehicles.

[0043] The vehicle data 128 includes information received via the telematics device 12, which may include metadata including information about the vehicle 10. The fleet data 112 may be constructed or generated from vehicle data and, as such, represent vehicle data from multiple vehicles. For example, the vehicle data 10 may include vehicle identifiers or other identifying information. The processing circuit 102 may cross-check the identifying information in the database 108 to determine if the vehicle is associated with a fleet and, if so, which fleet (e.g., via a fleet identifier, which may be a numeric, alpha, and / or alphanumeric identifier specific to a fleet) . Then, the processing circuit may aggregate vehicle data specific to that fleet identifier to generate fleet data 112 specific to each fleet.

[0044] The vehicle data 128 and the fleet data 112 includes information about the evaluation factors, such as maintenance and operation history, and / or appearance of the vehicle and fleet of vehicles, respectively. The vehicle data 128 and fleet data 112 also includes equipment performance information such as fuel consumption information such as an engine fuel consumption rate, a total fuel consumption over a predetermined time period or distance, a fuel economy, and so on. The equipment performance data also includes equipment performance information such as power, drivability, engine work time, engine idle time, engine exhaust data (e.g., exhaust gas / particle concentration) , and / or other information regarding operation of the engine. The metadata may also include an engine serial number, a vehicle identification number (VIN) , a calibration identification and / or verification number, a software identification, a make of the vehicle, a model of the vehicle, a unit number of a power unit of the vehicle, a unique identifier regarding a controller of the vehicle (e.g., a unique identification value (UID) ) , and / or a vehicle maintenance and operation history. Any of the data described above may include additional metadata such as a timestamp of when the data was gathered and / or when the data was transmitted or received by the provider computing system 20. The predetermined time periods described above may include a trip time, a work cycle (e.g., day, week, month, etc. ) , a time period between vehicle service, a predetermined vehicle lifespan, and the like. Accordingly, any of the information described above may include corresponding metadata.

[0045] The database 108 may also store user device information associated with the client device 30, such as customer information including a number of vehicles owned, fleet identifiers, one or more vehicle identifiers, data reporting preferences, vehicle maintenance and operation history. The user device information may also include a user device registration, a user device ID, a user device software registration, a user device software ID, and / or other identifiers for identifying the client device 30 and / or software on the client device 30. The data stored by the database 108 is retrievable, viewable, and / or editable by the provider computing system 20 (e.g., by a user input) .

[0046] A user (e.g., a provider employee, a customer, etc. ) may log onto the application or web-based interface before usage of the application and / or web-based interface. In some embodiments, logging on may include receiving at least one authentication credential (e.g., a device token, a user name and password, a PIN, a combination thereof, and so on) . For example, the provider computing system 20 may receive the credential and authenticate the client device 30. Authentication of the client device 30 and / or user may enable the provider computing system 20 to access and receive the vehicle data from the client device 30. Without authenticating the client device 30, the vehicle data may be securely stored and inaccessible. As indicated above, the authentication credential may be a passkey, a code, a token, and / or other types of credentials.

[0047] In one embodiment, and as shown in FIG. 1, the vehicle assessment circuit 114 includes any combination of hardware and software for determining an evaluation factor based on the vehicle data 128 stored by the database 108. The vehicle assessment circuit 114 is structured to analyze the vehicle data 128 and / or fleet data 112 and based on a plurality of predefined evaluation factors. The evaluation factors include equipment performance (e.g., fuel economy, power, drivability, oil consumption, powertrain milage, operating time, idling time, etc. ) , maintenance and operation history (e.g., a warranty log, a performance log of critical parts, loading history, overspeed, overloading, quality of fuel, ODI, etc. ) , and vehicle or system appearance (e.g., a visual evaluation of the condition of the vehicle performed by an assessor) .

[0048] For example, the provider computing system 20 is structured to receive vehicle data via the communication interface 130. The received data is stored in the database 108 (e.g., with the vehicle data 128 and the fleet data 112) . The vehicle assessment circuit 114 may perform an assessment of the vehicle, based on the evaluation factors. In some embodiments, the vehicle assessment is a valuation of the vehicle. In other embodiments, the assessment is a different type of assessment of the equipment (e.g., a diagnostic and / or prognostic assessment) . In some embodiments, the vehicle assessment involves determining a valuation multiplier that may be used in relation to a current value (e.g., multiplied by a current value (e.g., bluebook value, trade in value, etc. ) ) to determine a recommended vehicle assessment (e.g., valuation) .

[0049] The vehicle assessment circuit may transform the valuation multiplier and / or the recommended vehicle valuation into a human-readable message and transmit the message to the client device 30. In some embodiments, the vehicle assessment circuit 114 may continuously or periodically determine or calculate a vehicle valuation based on the analysis of the one or more evaluation factors. The client device 30 may, in response to receiving a human-readable message from the provider computing system 20, display the human-readable message such that a user / operator may view the human-readable message. In some embodiments, the previous valuation multiplier and / or recommended vehicle valuation are displayed alongside the most recently determined vehicle valuation multiplier and / or recommended vehicle valuation. In this way, a user (e.g., a vehicle operator, a fleet manager, etc. ) may view the changes in the vehicle valuation over time.

[0050] In some embodiments, the vehicle assessment circuit 114 may determine when vehicle data associated with the various evaluation factors exceed a predefined threshold (or otherwise does not satisfy a predefined threshold or thresholds) . The vehicle data may include an emission value (e.g., a nitrous-oxide value, a carbon dioxide value, a particulate matter value, etc. ) , an engine knock value, a fuel consumption value, a maximum vehicle load value, an overspeed threshold value and / or other parameters related to the operation of the vehicle 10. Based on determining that one or more of the vehicle data points are not within a desired range or otherwise fail to satisfy a threshold (e.g., exceed a threshold such as being above a maximum value, below a minimum value, etc. ) , the vehicle assessment circuit 114 may determine a corrective action to bring the operational parameter within the desired range and / or to satisfy the threshold (e.g., below the maximum, above the minimum) . Based on determining the corrective action, the vehicle assessment circuit 114 may transform the evaluation factors and their associated operation parameter data into a human-readable message that includes the corrective action and transmit the human-readable message to the client device 30. For example, the vehicle assessment circuit 114 may determine that a vehicle operator is engaging in over-speed that affects the valuation of the vehicle negatively. The vehicle assessment circuit 114 may determine a corrective action (e.g., slow down to a speed range) , transform the corrective action into a human-readable message, and transmit the human-readable message containing the corrective action to the client device 30.

[0051] The vehicle assessment circuit 114 may perform real-time monitoring and analysis of the evaluation factors to identify and suggest corrective actions. For example, as the vehicle operates, the vehicle assessment circuit 114 may continuously or nearly continuously assess vehicle data, such as speed, engine load, and fuel consumption, to identify behaviors that may impact and improve the vehicle’s operational performance and operational efficiency. For example, if the vehicle assessment circuit detects sustained high-speed driving beyond predetermined efficiency ranges, the vehicle assessment circuit may determine that this behavior contributes to increased wear on the engine and negatively influences fuel economy relative to a vehicle regularly operating in the predetermined efficiency ranges. In response, the vehicle assessment circuit 114 determines an appropriate corrective action, such as suggesting the operator maintain a recommended speed range to minimize excess strain on the engine. The suggestion is transformed into, human-readable message and transmitted to the client device 30. The suggestion may be displayed on the client device for example as a pop-up notification, the suggestion may be populated in an application stored on the user device 30, as a message such as a text message or email message, or some combination thereof. To access the suggestion, a user may be prompted to enter an authentication credential, as discussed above (e.g., to open the application, to view the notification, to log into an email account, etc. ) . These suggestions enable the driver to adjust their behavior to improve vehicle performance, reduce wear on critical components, and promoting more efficient fuel usage-which may ultimately improve the vehicle assessment metric.

[0052] Referring now to FIG. 2, a flow chart of a method 200 for assessing equipment, such as vehicles, is shown, according to exemplary embodiments. In some embodiments, one or more of the computing systems of the system 100 is configured to perform the method 200. For example, the provider computing system 20 may be structured to perform, at least parts thereof, of the method 200. In an exemplary embodiment, the provider computing system 20 performs the method 200, alone or in combination with other devices, such as the client device 30 and the vehicle controller 120. It should be understood that in other embodiments, the method 200 may include other steps, the order of the steps may be changed, and / or certain of the depicted steps may be removed.

[0053] As an overview of the method 200, at process 202, the provider computing system 20 receives vehicle data 128 from the vehicle controller 120. The vehicle data may be combined and organized into at least one evaluation factor. At process 204, the provider computing system 20 applies one or more models to the to the vehicle data that makes up the various evaluation factors. In some examples, the model is a degradation model. In other examples, the provider computing system 20 applies multiple models. For example, the provider computing system may apply a statistical model, a machine learning model, and / or an empirical model. At process 206, the provider computing system 20 determines a valuation multiplier based on the output of the degradation model. At process 208, the provider computing system 20 multiplies the valuation multiplier with a current vehicle value estimation to determine a final recommended vehicle valuation. At process 210, the provider computing system 20 transmits the valuation multiplier alone, or in combination with, the final recommended vehicle valuation of the vehicle 10 to a user device (e.g., the client device 30) . At process 212, the client device may cause an associated display to display the valuation multiplier and / or the evaluation value to a user (e.g., a vehicle operator, a fleet manager, etc. ) .

[0054] Referring to the method 200 in more detail, at process 202, a vehicle controller 120 associated with a vehicle 10 transmits vehicle data 128 to the provider computing system 20. The vehicle data may be collected by a plurality of sensors disposed on / in the vehicle 10 and transmitted to and stored by the vehicle controller 120 (or determinations by the vehicle controller 120) . The vehicle controller may transmit all or some of the vehicle data 128 to the provider computing system 20. In some embodiments, the vehicle controller 120 categorizes the vehicle data into a plurality of evaluation factors that are specific to the assessment, such as valuation. An evaluation factor refers to specific vehicle data that may affect a remaining useful life (RUL) of a component (s) and / or system of the vehicle and / or a valuation of the vehicle 10. In an exemplary embodiment, the evaluation factors include (1) equipment performance, (2) maintenance and operation history, and (3) vehicle or system appearance / condition. In this way, the vehicle controller 120 may transmit the vehicle data 128 as evaluation factors or tagged with a particular evaluation factor (e.g., equipment performance, maintenance and operation history, or vehicle or system appearance / condition) .

[0055] In other embodiments, the provider computing system 20 receives the vehicle data 128 as raw data. In this embodiment, the provider computing system 20 may categorize the raw data into the various evaluation factors. For example, the provider computing system may categorize pieces of vehicle data based on the source of the vehicle data. For example, a sensor that measures the fill of oil in a vehicle 10 is associated with the engine of a vehicle, so that sensor data may be categorized as a piece of equipment performance vehicle data. As another example, a maintenance provider (e.g., a maintenance or repair technician) may transmit maintenance records associated with the vehicle 10. Since the source of the maintenance records is a maintenance provider, the provider computing system may categorize vehicle data associated with the maintenance records as a piece of maintenance and operation history vehicle data. Additionally or alternatively, the provider computing system 20 may receive maintenance records associated with the vehicle 10 from an insurance provider (e.g., past insurance claims, accident records, etc. ) . In some examples, the provider computing system 20 may compare vehicle data associated with the operation of the vehicle (e.g., accelerating, idling, etc. ) against predefined thresholds and / or historical data. If the vehicle data exceeds or otherwise does not satisfy a threshold (e.g., idling time exceeded historical idling times by 20%or more) , the provider computing system 20 may categorize the vehicle data as operation history. Some or all of the vehicle data may be included in the evaluation factors. For example, the some of the vehicle data may be unrelated to the evaluation factors (e.g., data unrelated to the predefined critical components such as cabin temperature, fan speeds, seat or mirror position data, etc. ) , and such data may fall into a non-evaluation factor category. Additionally, the provider computing system 20 may send specific requests for specific vehicle data.

[0056] Further, the provider computing system 20 may request representative data, such as averages, medians, etc., that will avoid continuous transmission of discrete data points. In this way, only a portion of the discrete data collected is transmitted to reduce data packet size for transmission. This reduces bandwidth occupancy and decreases processing times leading a technical improvement to the described and shown computing architecture. In some examples, each vehicle 10 or fleet of vehicles 10 include an associated code (e.g., an identifier) . The provider computing system 20 may send the associated code as part of the request for vehicle data so that when data is received in response with the code, it is easily categorized to the particular vehicle 10 and / or fleet by the provider computing system 20.

[0057] As mentioned above, the evaluation factors include equipment performance, maintenance and operation history, and vehicle or system appearance / condition, according to exemplary embodiments.

[0058] Equipment performance may include fuel economy, power, drivability, oil consumption, vehicle milage, operation time, turbo charger pressure, coolant temperature, portable emissions measurement systems (PEMS) , oil pressure, and fault codes. The vehicle data associated with the equipment performance evaluation factor may be collected by the telematics device 12 and transmitted to the provider computing system (e.g., by the communication interface 130, by the telematics device 12, etc. ) .

[0059] Maintenance and operation history may include the maintenance and operation history of certain components and / or systems. Maintenance and operation history of certain components and / or systems may include information associated with warranty claims. The maintenance and operation history of certain components and / or systems may include accident histories, maintenance and repair histories of an aftertreatment system, engine cylinders, a clutch, a starter, a battery, a turbo boost system, a fueling system (e.g., a fuel injector) and so on. The maintenance and operation history may further include a log of a vehicle’s failure to start. As mentioned above, the vehicle data associated with the maintenance and operation history evaluation factor may be collected and transmitted by a maintenance provider (e.g., a service technician or manager) , by an insurer, and / or by the telematics device 12. The maintenance and operation history may include an accident history and part damage history. The maintenance and operation history includes abnormal vehicle operation relative to a threshold. Abnormal operation may include, for example, over-loading, over-speeding, high idle time, tough duty cycle operation, high-speed starting, poor fuel use (e.g., fuel having sulfur) , extreme altitude or temperature, and high acceleration running. Vehicle data associated with the maintenance and operation history evaluation factor may be collected by the telematics device 12 and transmitted to the provider computing system (e.g., by the communication interface 130, by the telematics device 12, etc. ) .

[0060] Vehicle or system appearance / condition may be a visual assessment that is performed based on photos, videos, or an in-person viewing of the vehicle 10. Visual appearance / condition of the vehicle may include, for example, dents, cracks, paint issues (e.g., scratches, chips, wear marks, etc. ) , misalignments in body panels, and the like. The vehicle or system appearance / condition may be performed, for example, by a person and / or by the provider computing system 20 (e.g., using image recognition, applying an algorithm, etc. ) . For example, an image acquisition device (e.g., video, still, audio, and / or other image gathering device, such as a camera) may take images of the vehicle and transmit those images to the provider computing system 20. Or, as another example, a specialty image device, such as an x-ray device, may take images of the vehicle or of components thereof. Then, using one or more algorithms (e.g., a machine learning algorithm) , the provider computing system 20 may evaluate the appearance  / condition of the vehicle or system. As another example, an inspector may provide, via a user interface device, notes regarding their evaluation of the vehicle or system. The notes may be analyzed by the provider computing system 20 and stored in a record specific to the vehicle. In either situation, an evaluation of the system appearance / condition may be obtained by the provider computing system 20.

[0061] At process 204, the provider computing system 20 applies one or more degradation models to the evaluation factors received at process 202. The degradation models may estimate remaining useful life of the vehicle 10 based on a comparison to the population and based on the vehicle specific evaluation factors. This concept is discussed further in FIG. 4 and its associated description.

[0062] At process 206, the provider computing system 20 determines an assessment value or metric (e.g., an assessment multiplier) based on the estimated remaining useful life calculated at process 204. The evaluation factors are utilized to calculate remaining useful life, which is in turn utilized to calculate an assessment multiplier for a vehicle 10. The output assessment multiplier may be a value between 0 and 2, according to some examples. In one embodiment, the assessment multiplier is a valuation multiplier indicative of a value of a particular vehicle 10.

[0063] At process 208, the provider computing system 20 applies, particularly multiplies, the assessment multiplier determined at process 206 with an estimated current vehicle assessment (e.g., a currently assessed vehicle value) to determine a recommended vehicle assessment value. In some examples, the recommended vehicle assessment is a recommended vehicle value. The estimated current vehicle value may be calculated based on basic information such as the type of vehicle, the vehicle’s age, mileage, maintenance and operation history, etc. This calculation in isolation does not contemplate the remaining useful life of the vehicle’s powertrain. Advantageously, by multiplying the current vehicle valuation by the valuation multiplier, the output recommended vehicle evaluation accounts for the remaining useful life of the powertrain.

[0064] At process 210, the provider computing system 20 transmits the assessment multiplier and / or the recommended vehicle assessment to a user device (e.g., the client device 30) . In this way, the provider computing system 20 transforms the assessment multiplier and / or the final recommended vehicle assessment into a human-readable message. The human-readable message may be displayed on a user device at process 212. For example, the client device 30 may receive the human-readable message and may cause an associated client device display to display the assessment multiplier and / or the final recommended vehicle assessment.

[0065] Referring now to FIG. 3, a flow chart of a method 300 for assessing equipment, such as vehicles is shown, according to an exemplary embodiment. In some embodiments, one or more of the computing systems of the system 100 is configured to perform the method 200. For example, the provider computing system 20 may be structured to perform, at least parts thereof, of the method 200. In an exemplary embodiment, the provider computing system 20 performs the method 200, alone or in combination with other devices, such as the client device 30 and the vehicle controller 120. It should be understood that in other embodiments, the method 200 may include other steps, the order of the steps may be changed, and / or certain of the depicted steps may be removed.

[0066] At process 302, a vehicle controller (e.g., the vehicle controller 120) collects vehicle data from a vehicle (e.g., the vehicle 10) . The vehicle data may include oil consumption, mileage, operation time, turbo charger pressure, coolant temperature, PEMS, oil pressure, aftertreatment system maintenance and operation history, engine cylinder maintenance and operation history, vehicle fail start history, clutch maintenance and operation history, starter maintenance and operation history, battery maintenance and operation history, turbo boost maintenance and operation history, fuel injector history, over-loading data, over-speeding data, high idle time relative to average idle time, long operation, tough duty cycle operation, high speed starting data, fuel quality data, extreme temperature and / or altitude data, and high acceleration running data. At process 303, the vehicle data 128 is transmitted to the provider computing system 20. In some examples, the communication interface 130 transmits the vehicle data 128. In other examples, the telematics device 12 transmits the vehicle data 128. In some examples, the communication interface 130 transmits a portion of the vehicle data 128 the telematics device 12 transmits the remaining vehicle data 128.

[0067] At process 304, the provider computing system 20 acquires or receives evaluation factors. The evaluation factors may be input by a user, such as a provider operator, via an input / output device associated with the provider computing system 20 or received via the client device 30. In one embodiment, the evaluation factors include equipment performance information, maintenance and operation history information, and vehicle or system appearance / condition. The processing circuit 102 may determine types of vehicle data that are associated with each evaluation factor. For example, if the provider computing system 20 receives equipment performance as an evaluation factor from the client device 30, then the provider computing system 20 request and receives data from an oil flowmeter, an odometer, a vehicle timer, and an emissions sensor from the vehicle 10. The provider computing system 20 may provide a request for this information via the network 50 to the vehicle controller 120. The vehicle controller 120 determines receives information based on this request, such as an oil consumption value, a mileage value, an operation time value, turbo charger pressure value, a coolant temperature value, PEMS, an oil pressure value, etc. Each of these values is grouped under the equipment performance evaluation factor by at least one of the vehicle controller 120 or the provider computing system 20. In some embodiments, the vehicle controller 120 may calculate or determine a single equipment performance evaluation factor based on the associated equipment performance vehicle data values. For example, the vehicle controller 120 may use the oil consumption, mileage, operation time, turbo charger pressure, coolant temperature, PEMS, oil pressure as inputs into one or more of a statistical model, a machine learning model, experimental data, a lookup table, etc. to determine an equipment performance factor value.

[0068] At process 306, the provider computing system 20 receives vehicle population data which is a collection of vehicle data from a broader set of vehicles (e.g., vehicles other than and potentially including the vehicle 10 being evaluated) . Stated another way, vehicle population data refers to the aggregate information collected from a specific group of vehicles that share common characteristics, such as make, model, age, or usage patterns. Vehicle population data encompasses a broader dataset that includes various vehicles rather than focusing solely on a single vehicle 10. Vehicle population data can serve as a benchmark for how an individual vehicle 10 performs relative to similar vehicles within a defined population. For example, the vehicle population data may include all or some of the vehicle data transmitted to the provider computing system 20 in over a predefined time frame (e.g., one year, five years, etc. ) . Additionally or alternatively, the provider computing system 20 may receive vehicle population data from a third-party source. In this way, the provider 5 may receive data from a population of vehicles manufactured by or provided by the provider 5, as well as data from vehicles manufactured or provided by other providers.

[0069] At process 308, the provider computing system 20 receives vehicle data from the vehicle controller 120. This data is specific to an individual vehicle 10. The vehicle data is categorized into associated evaluation factors (e.g., equipment performance, maintenance and operation history, and vehicle appearance) . For example, oil consumption, mileage, operation time, turbo charger pressure, coolant temperature, PEMS, and oil pressure define vehicle data that is categorized into the equipment performance evaluation factor. As another example, aftertreatment system maintenance and operation history, engine cylinder maintenance and operation history, vehicle fail start history, clutch maintenance and operation history, starter maintenance and operation history, battery maintenance and operation history, turbo boost maintenance and operation history, fuel injector history may be categorized into the maintenance and operation history evaluation factor. As a yet another example, over-speeding data, high idle time relative to average idle time, long operation, tough duty cycle operation, high speed starting data, fuel quality data, extreme temperature and / or altitude data, and high acceleration running data may be categorized into the maintenance and operation history evaluation factor. As another example, structural or cosmetic defects such as dents, cracks, rust, paint imperfections (e.g., scratches, chips, wear marks, etc. ) , and misalignment of body panels may be categorized into the visual appearance / condition factor.

[0070] At process 310, the provider computing system 20 applies a degradation model to the various vehicle data included in the evaluation factors. The degradation model determines remaining useful life of the vehicle 10 by applying various models to the evaluation factors. For example, the degradation model may apply a statistics model, a machine learning model, and an empirical model to determine an accurate estimate of remaining useful life of a vehicle 10.

[0071] At process 312, the provider computing system 20 determines a valuation multiplier and / or a final recommended vehicle valuation based on the degradation model. In an exemplary embodiment, the provider computing system 20 multiplies a current vehicle value estimation by the vehicle valuation multiplier to determine a final recommended vehicle valuation. The provider computing system may transmit the valuation multiplier and / or the final recommended vehicle valuation to the client device 30. In some embodiments, the provider computing system determines a change in value of the valuation multiplier and determines the reason for the change in value based on the evaluation factors. In other embodiments, the provider computing system 20 may transmit the valuation multiplier and a corrective action recommendation to the client device 30.

[0072] For example, the provider computing system 20 may transmit the final recommended vehicle valuation and valuation multiplier to a user-accessible mobile app on a client device 30. Upon accessing the mobile app, a dashboard screen may display the vehicle’s current valuation (e.g., $20, 000) with the corresponding valuation multiplier (e.g., 0.85) and a timestamp indicating the last update. If the user selects the valuation multiplier, the app may display pertinent details, breaking down how specific evaluation factors influence the valuation multiplier. By way of example, maintenance and operation history data may show that a missed oil change six months prior decreased the valuation multiplier by 0.05. Similarly, the comparative model analysis may show that high idle time, relative to similar models, led to an additional reduction in the multiplier. Additionally, the dashboard may provide a corrective action recommendation, such as advising the user to schedule an engine tune-up or an oil change. In some examples, the corrective action may indicate an estimated increase in the valuation multiplier if the recommended corrective action is taken.

[0073] As another example, the provider computing system 20 may transmit the valuation multiplier to the dashboard of the vehicle 10. If an event occur that may lower the valuation multiplier, such as an engine overheating warning, the system 20 may alert the user directly on the dashboard display: “Engine overheating detected. Immediate action is recommended to avoid further impact on vehicle value. ” The dashboard may further display specific usage patterns that could contribute to abnormal component wear. For example, the display may note that frequent stop-and-go driving actions could accelerate transmission wear, along with a recommendation to modify driving habits to prevent further valuation impacts.

[0074] In another example, the provider computing system 20 may aggregate vehicle population data and transmit vehicle valuation multipliers to a mobile app or webpage for fleet management purposes. For example, the app or webpage may display a benchmark graph, comparing a specific vehicle’s engine hours to the fleet and population averages. Here, the data may reveal that Vehicle A’s engine hours exceed the population average by 20%, impacting its multiplier by -0.1. The app may also detail that excessive idle time on Vehicle B contributes a -0.05 change in the multiplier, with an option to view corrective idle management settings. As another example, a notification might alert the manager: “Vehicle C: High-frequency short trips detected. Consider alternate usage to avoid future valuation impacts due to increased engine strain. Advantageously, this allows fleet managers to benchmark individual vehicles against similar vehicles in the fleet or the general vehicle population.

[0075] At process 314, the client device 30 receives the valuation multiplier and / or the recommended vehicle valuation from the provider computing system 20. At process 316, the client device 30 causes a display to display the valuation multiplier and / or the recommended vehicle valuation to a user or operator. At process 318, the user device causes a display to display a change in recommended vehicle valuation and the corrective action recommendation. For example, if a vehicle operator idles a vehicle for a sustained period, the user display may cause a center console display to display the previous valuation multiplier and a new valuation multiplier, along with a notification regarding the idling negatively affecting the valuation multiplier.

[0076] Referring now to FIG. 4, a flow chart of a method 400 of applying a degradation model to determine remaining useful life is shown, according to an exemplary embodiment. In some embodiments, one or more of the computing systems of the system 100 is configured to perform the method 400. For example, the provider computing system 20 may be structured to perform, at least parts thereof, of the method 400. In an exemplary embodiment, the provider computing system 20 performs the method 400, alone or in combination with other devices, such as the client device 30 and the vehicle controller 120.

[0077] As an overview of the method 400, the provider computing system 20 acquires evaluation factors, vehicle specific data, and vehicle population data. The provider control system may apply one or more data driven models and one or more models driven by domain knowledge. By applying these models, the provider computing system determines the remaining useful life of the vehicle, and in turn, determines a valuation multiplier and / or a recommended valuation for the vehicle.

[0078] At process 402, the provider computing system acquires or receives one or more evaluation factors. The evaluations factors vehicle data associated with a vehicle. The vehicle data 128 is collected by one or more vehicle sensors is stored on a vehicle controller 120. In an exemplary embodiment, the evaluation factors are pre-programmed by a provider entity operator. The evaluation factors may include equipment performance, maintenance and operation history, and vehicle or system appearance / condition.

[0079] At process 404, the provider computing system 20 receives vehicle population data. The vehicle population data may comprise a data store that includes all or some of the vehicle data transmitted to the provider computing system 20. For example, the vehicle population data may include the vehicle data transmitted to the provider computing system 20 in the past five years. In some embodiments, the provider computing system 20 receives vehicle population data from a third-party source. In this way, the provider computing system 20 may receive data regarding a population of vehicles manufactured by or provided by the provider 5, as well as data from vehicles manufactured or provided by other providers. In some embodiments, the fleet data 112 is the vehicle population data.

[0080] At process 406, the provider computing system 20 receives vehicle data from a vehicle 10. The vehicle data may be collected by a telematics device 12 communicatively coupled to or physically coupled to one or more sensors. The vehicle data may include a variety of evaluation factors, for example, equipment performance data, maintenance and operation history, and / or vehicle or system appearance / condition. Each evaluation factor defines a category of vehicle data. For example, the equipment performance factor may include oil consumption, powertrain mileage, and operating time. The maintenance and operation history may include a warranty, a performance log of critical parts (e.g., transmission, battery, electrical power system, exhaust system, etc. ) , loading history, over speed events, abnormal operation, and fuel quality. The vehicle or system appearance / condition may include a log of structural or cosmetic defects such as dents, cracks, rust, paint imperfections (e.g., scratches, chips, wear marks, etc. ) , and misalignment of body panels may be categorized into the visual appearance / condition factor.

[0081] At process 408, the provider computing system 20 applies a degradation model to the evaluation factors. The degradation model includes one or more data evaluation models. At process 418, the provider computing system applies a data driven model. At process 410 the provider computing system 20 applies a domain knowledge driven model. The domain knowledge driven models are physics-based models that utilize preset failure thresholds or values (or ranges of values) of the evaluation factors as inputs. In some examples, the preset failure thresholds are determined by the manufacturer or provider of the vehicle (e.g., based on testing, measured data, etc. ) . The domain knowledge driven model may include an empirical model based on engineering data, testing data, and / or other similar experience based data. The data driven model may include applications of statistics model based on vehicle population data and a machine learning model. The data driven models utilize vehicle data associated with the evaluation factors and lifespan of vehicle and / or specific components of the vehicle as inputs to train the models. In this way, the data driven models may process vehicle data associated with the evaluation factors to determine, namely predict, a lifespan (i.e., a remaining useful life) of the vehicle and / or specific components of the vehicle. In some examples, the domain knowledge driven model is applied on its own while the data driven models are being trained (e.g., until enough data is collected to train the data driven models) .

[0082] At process 412, the provider computing system 20 determines an empirical model that estimates remaining useful life of a vehicle based on measured remaining useful life data. The empirical model is based on direct observations of remaining useful and failure thresholds in vehicles. In the context of vehicle degradation modeling, empirical models may be derived from physical tests, field measurements, or domain expertise. The empirical model incorporates knowledge of the vehicle's equipment performance, operating conditions, maintenance and operation history, and environmental factors to estimate degradation and predict RUL.

[0083] At process 414, the provider computing system 20 applies the empirical model determined at process 412 to vehicle specific data transmitted by a vehicle 10. In applying the empirical model, the provider computing system may graph an empirical relationship line between the input vehicle data variables and the predicted remaining useful life (e.g., in terms of hours, days, months, operational cycles, etc. ) . At process 416, the provider computing system determines the vehicle’s remaining useful life based on the empirical relationship established at process 414. The empirical model may include a failure threshold line that is established based on historical vehicle data and their measured condition indicators. By measuring the intersection between the failure threshold line and the empirical relationship line of a specific vehicle, the empirical model determines an estimated remaining useful life value (e.g., days, months, years or remaining useful life, and / or remaining estimated operational cycles) .

[0084] At process 418, the provider computing system 20 applies a data driven model to the evaluation factors. The data driven model includes applying a machine learning model and a statistical model. The machine learning model and statistical model are described with greater detail with regards to steps 420-430 below.

[0085] At process 420, the provider computing system 20 retrieves and applies at least one machine learning model. The machine learning model may be trained on known input-output pairs such that the machine learning model can learn how to predict known outputs given known inputs. Once the machine learning model has learned how to predict known input-output pairs, the machine learning model can operate on unknown inputs to predict an output. Training inputs for the machine learning model may include run-to-failure data from a fleet of similar vehicles (e.g., the same type, model, year of vehicle) including the evaluation factors of the fleet of similar vehicles (e.g., equipment performance data, maintenance and operation history, vehicle or system appearance / condition) . The data may include the time to failure for each critical part of the vehicle (e.g., the aftertreatment system, the engine cylinders, clutch, starter battery, fuel injector, etc. ) .

[0086] Specific target metrics are identified / preset (e.g., by a user, provider, etc. ) followed by feature engineering to transform the raw vehicle data into meaningful features. These features are then used to rank corresponding factors by their weight in the model. Specific target metrics may include, for example, an accuracy which measures the proportion of correct predictions out of a total amount of predictions, a precision which measures a ratio of true positive predictions relative to a total amount of actual positives, an absolute error (e.g., mean absolute error, root mean squared error, etc. ) which measures a difference (s) between a predicted value (s) and an actual value (s) . Feature engineering may involve for example, categorizing vehicle data into the evaluation factors (e.g., by extracting maintenance events from a past year from the vehicle data) and encoding the vehicle data into numerical code.

[0087] In exemplary embodiments, the machine learning model is a neural network model that includes a stack of distinct layers (vertically oriented) that transform a variable number of inputs being ingested by an input layer, into an output at the output layer. The neural network model may include a number of hidden layers between the input layer and output layer. Each hidden layer has a respective number of nodes. The nodes perform a particular computation and are interconnected to the nodes of adjacent layers. Each of the nodes sum up the values from adjacent nodes and apply an activation function, allowing the neural network model to detect nonlinear patterns in the inputs. Each of the nodes are interconnected by weights. Weights are tuned during training to adjust the strength of the node. Accordingly, each evaluation factor may be weighted. For example, the vehicle or system appearance / condition evaluation factor may have a lower weight than the equipment performance evaluation factor. The adjustment of the strength of the node facilitates the neural network’s ability to predict an accurate output. In some embodiments, the output may be one or more numbers. For example, the output may be a remaining useful life in terms of time, or in terms of remaining vehicle operational cycles (e.g., on / off cycles, trips, missions, etc. ) .

[0088] At process 422, the provider computing system 20 applies the machine learning model to the vehicle data to predict the remaining useful life of a vehicle component (e.g., each component of the powertrain, critical components predefined by the user, each component that affects the vehicle’s value by a preset monetary threshold or more) based on its current condition and similarity to past failure patterns observed in the training data. The machine learning model may repeat this for each critical component in the vehicle. In some embodiments, the machine learning algorithms used in the degradation modeling include random forests, support vector machines, neural networks, and ensemble methods like gradient boosting.

[0089] At process 424, provider computing system 20, using the machine learning model, determines an estimated remaining useful life of the vehicle by inputting the vehicle’s transmitted vehicle data and associated evaluation factors into the model. The model then calculates remaining useful life of the vehicle or each of the vehicle’s critical parts based on the vehicle’s current state and its similarities to past failure patterns observed in the model’s training data. The machine learning model outputs an estimated remaining useful life based on the similarities to the training data. The output estimate may be in terms of time or operational cycles. In some embodiments, the empirical model is used to estimate the remaining useful life of a vehicle in terms of time, whereas the machine learning model is used to estimate the remaining useful life of the vehicle in terms of operational cycles, or vice versa. In other embodiments, both the machine learning model and the empirical model are used to estimate remaining useful life of the vehicle in terms of time and operational cycles. In this way, an average between the estimated RUL by the machine learning model and the empirical model may be used in determining a vehicle valuation multiplier.

[0090] At process 426, the provider computing system 20 determines a comparative model based on vehicle population data. This model analyzes historical data of similar vehicles or components to identify patterns of degradation over time. It may use statistical methods such as regression analysis, time series analysis, or survival analysis to understand how various factors affect the degradation process. The statistical model helps establish baseline trends and can provide probabilistic estimates of future degradation.

[0091] At process 428, the provider computing system 20 applies the comparative model determined at process 426 to the vehicle data received from the vehicle 10. At process 430, the provider computing system determines a vehicle’s statistical position on the statistical model compared to the vehicle population (e.g., ranking by percentile, quartile, etc. ) . The vehicle’s placement / ranking on the statistical model is dependent on the evaluation factors, according to some embodiments. For example, a vehicle with a high operation time, a history of failing to start, and was operated at high altitudes will have a lower ranking relative to a vehicle with lower operation times, no history of failing to start, and regular operation at altitudes near sea level.

[0092] At process 432, the provider computing system determines a vehicle valuation multiplier based on the estimated RUL and the vehicle’s position in the vehicle population. This multiplier is determined based on the RUL estimate and a comparative average RUL estimate. The comparative average RUL estimate is a predetermined estimate; for example, the predicted lifetime set by the vehicle manufacturer (e.g., 15 years, 20 years, 5, 000 operational cycles etc. ) . If the estimated RUL for a vehicle is longer / greater in terms of time or operational cycles than the comparative average RUL, then the output valuation multiplier will be in a range, for example, between 1 and 2. Conversely, if the estimated RUL is shorter / lower in terms of time or operational cycles than the comparative average RUL, the output valuation will be in a range, for example, between 0 and 1. In this way, the valuation multiplier derived based on RUL of a particular vehicle. In this way, the valuation multiplier directly proportional to the remaining useful life of the vehicle. In some embodiments, the vehicle valuation multiplier is multiplied by a vehicle value estimate to yield a final recommended vehicle valuation. As an example, a 10-year-old vehicle valued at $50, 000 with a manufacturer estimated lifetime of 20 years is determined to have a remaining useful life of 12 years. The provider computing system determined the vehicle valuation multiplier is 1.2 based on the RUL and determines that a final recommended vehicle valuation is $60, 000 by multiplying the current vehicle valuation of $50, 000 by the valuation multiplier of 1.2.

[0093] Advantageously, the systems and methods described above leverage telematics data to determine more accurate and precise vehicle assessment, such as valuations. The vehicle controller collects data from an associated telematics device, and transmits the data (i.e., the vehicle data) to the provider computing system (e.g., via a communication interface, via the telematics device 12, via a network, by direct wiring, etc. ) . The provider computing system applies various models to the vehicle data to determine an estimated remaining useful life of the vehicle. This multiplier is computed based on the remaining useful life (RUL) , thereby reflecting the vehicle's expected longevity relative to other vehicles. Consequently, when determining the recommended valuation of the vehicle, this multiplier is employed to adjust the estimated value accordingly. By doing so, the recommended valuation reflects the unique characteristics and condition of the vehicle, thus moving away from generic estimations towards a more precise valuation approach.

[0094] Additionally, the remaining useful life estimates may be used by the provider computing system to determine one or more corrective actions. The corrective actions are transmitted to one or more users (e.g., the fleet manager, the vehicle operator, etc. ) . In this way, the vehicle operator may adjust their operation styles to prevent damage to one or more vehicle parts and / or to prevent negative impact on the remaining useful life estimates.

[0095] As utilized herein, the terms “approximately, ” “about, ” “substantially” , and similar terms are intended to have a broad meaning in harmony with the common and accepted usage by those of ordinary skill in the art to which the subject matter of this disclosure pertains. It should be understood by those of skill in the art who review this disclosure that these terms are intended to allow a description of certain features described and claimed without restricting the scope of these features to the precise numerical ranges provided. Accordingly, these terms should be interpreted as indicating that insubstantial or inconsequential modifications or alterations of the subject matter described and claimed are considered to be within the scope of the disclosure as recited in the appended claims.

[0096] It should be noted that the term “exemplary” and variations thereof, as used hereinto describe various embodiments, are intended to indicate that such embodiments are possible examples, representations, or illustrations of possible embodiments (and such terms are not intended to connote that such embodiments are necessarily extraordinary or superlative examples) .

[0097] The term “coupled” and variations thereof, as used herein, means the joining of two members directly or indirectly to one another. Such joining may be stationary (e.g., permanent or fixed) or moveable (e.g., removable or releasable) . Such joining may be achieved with the two members coupled directly to each other, with the two members coupled to each other using one or more separate intervening members, or with the two members coupled to each other using an intervening member that is integrally formed as a single unitary body with one of the two members. If “coupled” or variations thereof are modified by an additional term (e.g., directly coupled) , the generic definition of “coupled” provided above is modified by the plain language meaning of the additional term (e.g., “directly coupled” means the joining of two members without any separate intervening member) , resulting in a narrower definition than the generic definition of “coupled” provided above. Such coupling may be mechanical, electrical, or fluidic. For example, circuit A communicably “coupled” to circuit B may signify that the circuit A communicates directly with circuit B (i.e., no intermediary) or communicates indirectly with circuit B (e.g., through one or more intermediaries) .

[0098] While various circuits with particular functionality are shown in FIG. 1, it should be understood that the provider computing system 20, the client device 30, and / or the vehicle controller 12 may include any number of circuits for completing the functions described herein. For example, the activities performed by the vehicle assessment circuit 114 may be distributed into multiple circuits or combined as a single circuit. Additional circuits with additional functionality may also be included. Further, the provider computing system 20 and the vehicle controller 120 may further control other activity beyond the scope of the present disclosure.

[0099] As mentioned above and in one configuration, the “circuits” may be implemented in machine-readable medium storing instructions (e.g., embodied as executable code) for execution by various types of processors, such as the processor 104 and the vehicle assessment circuit 114 of FIG. 1. Executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the circuit and achieve the stated purpose for the circuit. Indeed, a circuit of computer readable program 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 circuits 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.

[0100] While the term “processor” is briefly defined above, the term “processor” and “processing circuit” are meant to be broadly interpreted. In this regard and as mentioned above, the “processor” may be implemented as one or more processors, application specific integrated circuits (ASICs) , field programmable gate arrays (FPGAs) , digital signal processors (DSPs) , or other suitable electronic data processing components structured to execute instructions provided by memory. The one or more processors may take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, quad core processor, etc. ) , microprocessor, etc. In some embodiments, the one or more processors may be external to the apparatus, for example the one or more processors may be a remote processor (e.g., a cloud based processor) . Alternatively or additionally, the one or more processors may be internal and / or local to the apparatus. In this regard, a given circuit, or components thereof may be disposed locally (e.g., as part of a local server, a local computing system, etc. ) or remotely (e.g., as part of a remote server such as a cloud based server) . To that end, a “circuit” as described herein may include components that are distributed across one or more locations.

[0101] Embodiments within the scope of the present disclosure include program products comprising computer or machine-readable media for carrying or having computer or machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a computer. The computer readable medium may be a tangible computer readable storage medium storing the computer readable program code. The computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable medium may include but are not limited to a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , a portable compact disc read-only memory (CD-ROM) , a digital versatile disc (DVD) , an optical storage device, a magnetic storage device, a holographic storage medium, a micromechanical storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, and / or store computer readable program code for use by and / or in connection with an instruction execution system, apparatus, or device. Machine-executable instructions include, for example, instructions and data which cause a computer or processing machine to perform a certain function or group of functions.

[0102] The computer readable medium may also be a computer readable signal medium. A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electrical, electro-magnetic, magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport computer readable program code for use by or in connection with an instruction execution system, apparatus, or device. Computer readable program code embodied on a computer readable signal medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, Radio Frequency (RF) , or the like, or any suitable combination of the foregoing.

[0103] In one embodiment, the computer readable medium may comprise a combination of one or more computer readable storage mediums and one or more computer readable signal mediums. For example, computer readable program code may be both propagated as an electro-magnetic signal through a fiber optic cable for execution by a processor and stored on RAM storage device for execution by the processor.

[0104] Computer readable program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more other programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone computer-readable package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN) , or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider) .

[0105] The program code may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function / act specified in the schematic flowchart diagrams and / or schematic block diagrams block or blocks.

[0106] Although the figures and description may illustrate a specific order of method steps, the order of such steps may differ from what is depicted and described, unless specified differently above. Also, two or more steps may be performed concurrently or with partial concurrence, unless specified differently above. Such variation may depend, for example, on the software and hardware systems chosen and on designer choice. All such variations are within the scope of the disclosure. Likewise, software implementations of the described methods could be accomplished with standard programming techniques with rule-based logic and other logic to accomplish the various connection steps, processing steps, comparison steps, and decision steps.

[0107] It is important to note that the construction and arrangement of the apparatus and system as shown in the various exemplary embodiments is illustrative only. Additionally, any element disclosed in one embodiment may be incorporated or utilized with any other embodiment disclosed herein.

Claims

A provider computing system, comprising:one or more processors; andat least one memory storing instructions thereon that, when executed by the one or more processors, cause the one or more processors to:receive, from at least one vehicle via a network, vehicle data regarding the at least one vehicle, the vehicle data associated with one or more evaluation factors;analyze the one or more evaluation factors to output a valuation metric;transform the valuation metric into a human-readable message;transmit, via the network, the human-readable message to a user device; andcause the user device to display the human-readable message including the valuation metric.The provider computing system of claim 1, wherein the one or more evaluation factors comprise at least one of equipment performance information regarding the at least one vehicle, maintenance and operation history information regarding the at least one vehicle, or an appearance of the at least one vehicle.The provider computing system of claim 1, wherein the one or more evaluation factors are analyzed by applying a degradation model to the vehicle data regarding the at least one vehicle, wherein the degradation model determines a remaining useful life of the at least one vehicle or a system or component associated with the at least one vehicle.The provider computing system of claim 3, wherein applying the degradation model includes at least one of a statistical model, a machine learning model, or an empirical model.The provider computing system of claim 1, wherein the instructions when executed, further cause the one or more processors to:determine a corrective action based on the vehicle data regarding the at least one vehicle and associated with the one or more evaluation factors;transform the corrective action into a second human-readable message; andtransmit, via the network, the second human-readable message containing the corrective action to the user device.The provider computing system of claim 1, wherein the instructions, when executed, cause the one or more processors to determine a final recommended vehicle assessment based on the valuation metric and a predetermined vehicle valuation.The provider computing system of claim 6, wherein the instructions, when executed, cause the one or more processors to:transform the final recommended vehicle assessment into a second human-readable message, andtransmit, via the network, the second human-readable message containing the final recommended vehicle assessment to the user device.The provider computing system of claim 1, wherein the instructions, when executed, further cause the one or more processors to:determine a characteristic of the vehicle data;categorize the vehicle data into an evaluation factor category or a non-evaluation factor category based on the characteristic of the vehicle data; andapply a degradation model to the vehicle data organized into the evaluation factor category to generate an estimated remaining useful life value of the at least one vehicle or a system or component associated with the at least one vehicle.A method for generating an equipment assessment, the method comprising:receiving, by a computing system and from at least one vehicle via a network, vehicle data regarding the at least one vehicle, the vehicle data associated with one or more evaluation factors;analyzing, by the computing system, the vehicle data associated with the one or more evaluation factors;generating, by the computing system and based on analyzing the vehicle data, a valuation metric for the at least one vehicle;transforming, by the computing system, the valuation metric into a human-readable message; andtransmitting, by the computing system, the human-readable message to a user device.The method of claim 9 further comprising causing the user device to display the human-readable message including the valuation metric.The method of claim 9 further comprising:determining a corrective action based on the vehicle data regarding the at least one vehicle associated with the one or more evaluation factors;transforming the corrective action into a second human-readable message; andtransmitting, by the computing system and via the network, the second human-readable message containing the corrective action to the user device; andcausing the user device to display the second human-readable message.The method of claim 9, wherein the one or more evaluation factors comprise at least one of:equipment performance information regarding the at least one vehicle, maintenance and operation history information regarding the at least one vehicle, or an appearance of the at least one vehicle.The method of claim 9 further comprising analyzing the one or more evaluation factors by applying a degradation model to the vehicle data regarding the at least one vehicle, wherein the degradation model determines a remaining useful life of the at least one vehicle, or a system or component associated with the at least one vehicle.The method of claim 13, further comprising:transforming, by the computing system, the remaining useful life into a second human-readable message; andtransmitting the second human-readable message containing the remaining useful life to a fleet manager.The method of claim 9, further comprising determining a final recommended vehicle assessment based on the valuation metric and a predetermined vehicle valuation.The method of claim 15 further comprising:transforming the final recommended vehicle assessment, by the computing system, into a second human-readable message; andtransmitting, by the computing system and via the network, the second human-readable message containing the final recommended vehicle assessment to the user device.The method of claim 9 further comprising:determining a characteristic of the vehicle data;categorizing the vehicle data into an evaluation factor category or a non-evaluation factor category based on the characteristic of the vehicle data; andapplying a degradation model to the vehicle data organized into the evaluation factor category to generate an estimated remaining useful life value of the at least one vehicle or a system or component associated with the at least one vehicle.A non-transitory computer-readable medium having computer-executable instructions embodied therein that, when executed by at least one processor of a computing system, cause the computing system to perform operations comprising:receiving, from at least one vehicle via a network, vehicle data regarding the at least one vehicle, the vehicle data associated with one or more evaluation factors;analyzing the one or more evaluation factors to output a valuation metric;transforming the valuation metric into a human-readable message;transmitting, via the network, the human-readable message to a user device; cause the user device to display the human-readable message including the valuation metric; andcausing the user device to display the human-readable message including the valuation metric.The non-transitory computer-readable medium of claim 18, wherein the operations further comprise:determining a corrective action based on the vehicle data associated with the one or more evaluation factors;transforming the corrective action into a second human-readable message; andtransmitting the second human-readable message containing the corrective action to the user device; andcausing the user device to display the second human-readable message including the corrective action.The non-transitory computer-readable medium of claim 19, wherein the user device is a dashboard of the at least one vehicle, and wherein the operations include causing the dashboard to display both the human-readable message including the valuation metric and the second human-readable message including the corrective action.

Images