DYNAMIC VEHICLE COMPONENT DATA APPARATUSES, SYSTEMS, AND METHODS

Abstract
A system includes a computing device with memory configured to store instructions and a processor to execute the instructions for operations that include causing a request to be transmitted from a computing device remote from the server, receiving, at the computing device, responsive to the request, a serial number for a vehicle component, and storing the serial number on a memory of the computing device.
Description
TECHNICAL FIELD

This description relates to techniques for controlling the transmissions of operational information from vehicles for remote analysis and processing.


BACKGROUND

With the increased interest in reducing dependency on fossil fuels, the use of alternative energy sources has been incorporated into various applications, such as transportation. Both public and private transportation vehicles have been developed to run on fuels other than traditional petroleum based fuels (i.e., petrol, diesel, etc.). Some vehicles solely use alternative energy sources while others combine the functionality of petroleum based systems with alternative energy based systems (e.g., electrical, biofuel, natural gas, etc.). Along with being potentially more cost-effective and having more abundant resources, such alternative energy sources and their byproducts are considered to be more environmentally friendly.


SUMMARY

The systems and techniques described herein relate to methods for extracting data from a vehicle in connection with the occurrence of particular events, such as replacing or installing a new vehicle component. As described herein, these vehicle components have unique serial numbers that get tied to the vehicle (VIN) for supply chain, warranty and tracking purposes. Once any component is installed, replaced, serviced or updated (including software), then the database for that VIN is updated to reflect the current state of art related to that component and associated systems. These systems advantageously reduce operator error when entering information, increase efficiency in the installation process, and optimize performance of system components by ensuring that all system software updates and protocols are appropriately used.


Various implementations provide systems including a computing device including a memory of the computing device configured to store instructions and a processor to execute the instructions to perform operations. The operations include causing a first request to be transmitted from the computing device remote from the computing device. The operations include receiving, at the computing device, responsive to the first request, a first serial number for a vehicle component. The operations include storing the first serial number on the memory of the computing device. The operations include causing a second request to be transmitted from the server from the computing device to the vehicle to the vehicle following a period of time after storing the first serial number on the memory of the computing device. The operations include receiving at the computing device, responsive to the second request, a second serial number for the vehicle component. The operations include comparing the second serial number received responsive to the second request to the first serial number previously stored on the memory of the computing device. The operations include updating the memory of the computing device with the second serial number in place of the first serial number if the second serial number received responsive to the second request is different from the first serial number stored on the memory of the computing device.


In certain implementations, the operations further comprise receiving a part number and a part name and storing the part number and the part name in the memory of the computing device with the first serial number.


In certain implementations, the operations further comprise receiving a software version of a software stored on a memory device of the vehicle component and storing the software version of the software in the memory of the computing device with the first serial number.


In certain implementations, a triggering event causes the first request to be transmitted.


In certain implementations, the operations further comprise causing the first request to be transmitted from the server responsive to a controller of the vehicle connecting to the server.


In certain implementations, the operations further comprise storing a date representing when the controller of the vehicle connected to the computing device.


In certain implementations, the first request identifies a plurality of vehicle components for being provided to the computing device.


In certain implementations, the operations further comprise identifying a location of the vehicle, the location being determined by the computing device or provided from the vehicle.


In certain implementations, the operations further comprise requesting a mileage of the vehicle in the first request and storing the mileage of the vehicle in the memory of the computing device with the first serial number.


In certain implementations, the operations further comprise requesting operational hours of the vehicle in the first request and storing the operational hours of the vehicle in the memory of the computing device with the first serial number.


In certain implementations, the operations further comprise requesting a vehicle identification number of the vehicle in the first request.


In certain implementations, the operations further comprise updating at least one operational parameter of the vehicle.


Various implementation provide vehicles including a vehicle propulsion system, a vehicle controller including a memory configured to store instructions, and a processor to execute the instructions to perform operations. The operations include connecting the vehicle controller of the vehicle to a server remote from the vehicle. The operations include receiving a request at the vehicle from the server for a serial number for a vehicle component. The operations include identifying a data set of the vehicle component in a vehicle memory storage device. The operations include selecting the serial number for the vehicle component from the data set identified. The operations include transmitting the serial number for the vehicle component to the server.


In certain implementations, the serial number is selected via a universal (UDS) protocol.


In certain implementations, the vehicle propulsion system comprises a combustion engine and an electric motor.


In certain implementations, the operations further comprise transmitting a vehicle identification number of the vehicle to the server in response to receiving the request.


In certain implementations, the operations further comprise transmitting a location of the vehicle to the server in response to receiving the request.


In certain implementations, the operations further comprise transmitting a mileage of the vehicle to the server in response to receiving the request.


In certain implementations, the operations further comprise transmitting operational hours of the vehicle to the server in response to receiving the request.


In certain implementations, the operations further comprise transmitting a software version of a software stored on a memory device of the vehicle component to the server.


In certain implementations, the operations further comprise transmitting a part number of the vehicle component to the server.


In certain implementations, the operations further comprise receiving an update from the server for the vehicle controller, wherein the update is stored in the memory of the vehicle controller.


In certain implementations, the propulsion system comprises a plug-in hybrid conversion system.


In certain implementations, the vehicle comprises a truck bed and wherein the truck bed comprises at least one component of the plug-in hybrid system.


In certain implementations, the at least one component comprises one or more of a motor drive, a telemetry system, a battery, and a plug-in hybrid controller.


Various implementations provide, one or more tangible computer readable media storing instructions that are executable by a processing device, and upon such execution cause the processing device to perform operations. The operations include causing a first request to be transmitted from the computing device remote from the computing device. The operations include receiving, at the computing device, responsive to the first request, a first serial number for a vehicle component. The operations include storing the first serial number on the memory of the computing device. The operations include causing a second request to be transmitted from the server from the computing device to the vehicle to the vehicle following a period of time after storing the first serial number on the memory of the computing device. The operations include receiving at the computing device, responsive to the second request, a second serial number for the vehicle component. The operations include comparing the second serial number received responsive to the second request to the first serial number previously stored on the memory of the computing device. The operations include updating the memory of the computing device with the second serial number in place of the first serial number if the second serial number received responsive to the second request is different from the first serial number stored on the memory of the computing device.


It should be appreciated that all combinations of the foregoing concepts and additional concepts discussed in greater detail below (provided such concepts are not mutually inconsistent) are contemplated as being part of the inventive subject matter disclosed herein. In particular, all combinations of claimed subject matter appearing at the end of this disclosure are contemplated as being part of the inventive subject matter disclosed herein. It should also be appreciated that terminology explicitly employed herein that also may appear in any disclosure incorporated by reference should be accorded a meaning most consistent with the particular concepts disclosed herein.





BRIEF DESCRIPTION OF THE DRAWINGS

The drawings primarily are for illustrative purposes and are not intended to limit the scope of the inventive subject matter described herein. The drawings are not necessarily to scale; in some instances, various aspects of the inventive subject matter disclosed herein may be shown exaggerated or enlarged in the drawings to facilitate an understanding of different features. In the drawings, like reference characters generally refer to like features (e.g., functionally similar and/or structurally similar elements).


DESCRIPTION OF DRAWINGS


FIG. 1 illustrates a vehicle that includes a controller for managing vehicle information and transmission.



FIG. 2 illustrates a network-based vehicle analyzer for processing data transmitting from various vehicles.



FIG. 3 illustrates portions of a controller included in a vehicle for controlling the transmission of information associated with the vehicle.



FIG. 4A illustrates a flowchart representative of operations of a remote server for accessing a vehicle controller to electronically obtain the serial numbers for vehicle components.



FIG. 4B illustrates a flowchart of operations of a vehicle controller capable of controlling the transmission of vehicle component information.



FIGS. 5A and 5B illustrate an installation guideline that upfitters follow when installing components on a vehicle.



FIG. 5C illustrates a snapshot of an application upfitters use to release a vehicle after components have been installed on the vehicle.



FIG. 6 illustrates an example of a computing device and a mobile computing device that can be used to implement the techniques described here.



FIG. 7 illustrates vehicle components installed on a vehicle.





The features and advantages of the inventive subject matter disclosed herein will become more apparent from the detailed description set forth below when taken in conjunction with the drawings.


DETAILED DESCRIPTION

Following below are more detailed descriptions of various concepts related to, and exemplary embodiments of, inventive systems, methods and components of vehicular data extraction devices, systems, and methods.


Referring to FIG. 1, while operating (moving or sitting idle) a vehicle can generate a considerable amount of information that can be analyzed for potentially improving the performance of the vehicle. Improving that performance can involve analyzing the power usage of the vehicle to determine whether it would benefit from alternative fuel sources and if so to what degree or in what quantities and with what power and torque requirements. Once those requirements are determined, the appropriate parts corresponding to the performance improvements can be accurately selected and installed. To perform the analysis to determine how to improve performance, portions of the information may be transmitted to a location off-board the vehicle. Under some driving conditions, e.g., driving the long straightaways of a rural area, operations of the vehicle may not change over considerable periods of time (e.g., roughly the same speed and driving direction may be maintained). As such, some operational information may not considerably change for a period of time and would not need to be frequently transmitted from the vehicle for analysis. Information of more interest may coincide with the occurrence of particular vehicular events. For example, performing an analysis on information associated with an abrupt change in a vehicle operation, such as a change in efficiency or a vehicle fault may be of particular interest. Additionally, such events may provide insight into techniques for potentially improving vehicle performance. For example, due to the repeated occurrence of one or more events, employing different vehicle power sources may better lend itself to the driving conditions being experienced such as different types of traveled routes, environments (e.g., highway, city, rural, etc.), etc. The use of real time data can provide higher fidelity data to better inform driving strategies, to better inform vehicular system strategies, and for diagnosis of issues related to the vehicle driving strategies.


Under some conditions, analysis of the operational information may suggest that particular vehicles, types of vehicles, etc. may be optimum. For example, conventional internal combustion engine based vehicles may be optimal for some environments while alternative fuel vehicles, which may solely rely upon non-petroleum energy sources (e.g., electricity, natural gas, biofuels etc.), may be better suited for other environments. Other vehicles that may prove to be optimum may include hybrid vehicles that employ two or more distinct power sources (e.g., an electric motor and an internal combustion engine—referred to as a hybrid electric vehicle or HEV). Some hybrid vehicles (referred to as plug-in hybrid vehicles) may operate by using energy storage devices that can be replenished (e.g., rechargeable batteries). Determining the optimal power output for the energy storage devices and/or the optimal power/weight ratio for any such system may be enhanced by obtaining real-time real world driving and operational data. An analysis of this data may suggest modifying the power and/or weight of the energy storage device. Implementations described herein advantageously facilitate modifications vehicle components and correspondingly updating system software and control strategies based on modification of vehicle components.


In some arrangements, for electrical energy storage devices, one or more techniques may be implemented for charging and recharging the devices. For example, batteries may be charged through regenerative braking, strategic charging techniques, etc. during appropriate operating periods of the vehicle. In general, energy is typically lost as heat in conventional braking systems; however, a regenerative braking system may recover this energy by using an electric generator to assist braking operations. Some systems and techniques may also strategically collect (e.g., leech) energy from the combustion engine during periods of efficient operation (e.g., coasting, traveling, etc.) and later assist the engine during periods of lesser efficiency. For such vehicles, the electric generator can be a device separate from the electric motor, considered as a second operating mode of the electric motor, or implemented through one or more other techniques, individually or in combination. Energy recovered by regenerative braking may be considered insufficient to provide the power needed by the vehicle. To counteract this lack of energy, the electric motor may be engaged during defined periods to assist the combustion engine or to be the sole source of propulsion. One or more control strategies may be used to determine these time periods. Similarly, periods of time may also be determined to engage regenerative braking and strategic charging in order to replenish energy storage. Other operations of the vehicle (e.g., accelerate, decelerate, gear changes, etc.) may also be defined for the control strategies. By developing such strategies to control the assistance provided to combustion engines (e.g., during low efficiency periods), energy may be conserved without negatively impacting vehicle performance. Along with such strategies, individual vehicles, types of vehicles, etc. may be selected for use based on the operational environment.


Some vehicle manufacturers may recommend operations and control strategies for entire classes of vehicles or other types of large vehicle groups (e.g., same model vehicles, same vehicle line, etc.) at particular times (e.g., at the release of the vehicle line). Similarly, the level of assistance provided by an electric motor or other type of alternative fuel system may be constant. Being rather static, such recommendations do not account for the environment in which the vehicle is operated. Route specific information (e.g., vehicle is driven under highway, city, rural, etc. conditions), driver information (e.g., driver accelerating and braking tendencies, etc.), and other types of environmental information (e.g., time of day, season, etc.) are not accounted for in determining the appropriate operational strategies. Furthermore, vehicle selection is typically determined without consulting such route and environmental information. Typically a vehicle is selected absent this information because there is no other option (e.g., the driver has access to a single vehicle) or no information is provided for vehicle management (e.g., a vehicle is randomly assigned to a driver, such as a delivery truck). Absent taking steps to attain, analyze, and use such information for vehicle selection, poor performance may occur along with related negative impacts (e.g., reduced fuel efficiency, increased operating costs, etc.). One or more techniques may be implemented for appropriately selecting a vehicle, type of vehicle, etc. for operating in a particular environment. For example, data reflective of vehicles operating in the environment may be used for selecting a vehicle, which type of vehicle, etc. Vehicle selection may also identify that one vehicle type (e.g., a combustion engine based vehicle) should be converted into another vehicle type (e.g., hybrid vehicle) to improve performance (e.g., fuel efficiency, costs, etc.). Such operational data from vehicles may be used for other types of analysis. For example, vehicle operational data may be used for analysis to improve recommended operations and control strategies for a vehicle, type of vehicle, etc. For example, hybrid conversions may be more advantageous (e.g., reduced fuel consumption) for lower speed environments and less advantageous in high-speed environments.


One or more techniques may be employed for making such selections or other types of analysis. For example, from the vehicle operational parameters (e.g., operating speed, fuel economy, etc.) one or more metrics (e.g., performance metrics) may be calculated. In turn, the metrics may be utilized for further analysis. For example, along with using the information for vehicle selection, vehicle type selection, etc., converting one vehicle type (e.g., a combustion engine based vehicle) into another vehicle type (e.g., hybrid vehicle) may be determined through use of the operational parameters and metrics to achieve performance improvements in fuel efficiency, costs, etc.


As shown in FIG. 1, an example vehicle 100 (e.g., a hybrid automobile) is capable of collecting operational parameters for use in various analysis (e.g., identifying an appropriate vehicle, type of vehicle, etc. for operating in a particular environment). To provide this capability, the vehicle includes a vehicle information manager 102 (here embedded in the dashboard of the vehicle 100) that may be implemented in hardware (e.g., a controller 104), software (e.g., executable instructions residing on a computing device contained in the vehicle), a combination of hardware and software, etc. In some arrangements, the vehicle information manager 102 may operate in a generally autonomous manner for data collection, data transmission and other types of functionality. To collect vehicle operational information, data may be collected from one or more inputs. For example, the vehicle information manager 102 may communicate with one or more portions of the vehicle or vehicle controllers. A variety of sensors, components, processing units, etc. of the vehicle may exchange data with the vehicle information manager 102. These vehicle components can include smart components (e.g., batteries, telematics, hybrid controllers, inverters, chargers or other components with computing and communicating systems) that communicate (e.g., wirelessly) with the vehicle information manager 102. For example, operational parameters of the vehicle such as speed, acceleration, fuel consumption, etc., may be collected over time (e.g., as the vehicle operates) and provided to the vehicle informational manager 102. Location information (e.g., from a global positioning system receiver present in the vehicle) may also be collected by the vehicle information manager 102 to provide a record of the ground covered during vehicle operation. Similarly, data representing the direction that the vehicle is being driven may be provided to the vehicle information manager 102. Fuel consumption, temperature (e.g., of one or more vehicle components), etc. may be collected and provided. One or more timing signals can be collected, generated, etc. by the vehicle information manager 102. For example, a timing signal may be produced that represents the instances in which the vehicle's speed, location, etc. was sampled (e.g., every two seconds, etc.). Other type of operational parameters may also be provided from the vehicle; for example, data representing braking, steering, grade etc. may also be provided to the vehicle information manager 102. For example, a measure of braking pedal displacement, accelerator pedal displacement, displacement of a clutch pedal, etc. Vehicle components that provide information to the information manager 102 may also include interface modules, circuitry, etc. for controlling the operations of the combustion engine, the electrical motor, etc.


In some situations, data from sources other than the vehicle may also be collected. For example, user input may be provided. In this arrangement, the vehicle 100 includes an electronic display 106 that has been incorporated into its dashboard to present information such as selectable entries regarding different topics (e.g., operator ID, planned vehicle operations, trip destination, etc.). Upon selection, representative information may be gathered and provided to the vehicle information manager 102. To interact with the electronic display 106, a knob 108 illustrates a potential control device; however, one or more other types of devices may be used for user interaction (e.g., a touch screen display, etc.). Similar to using one or more sensors to collect operational data, other types of information may also be gathered; for example, a sensor 110 (here embedded in the dashboard of the vehicle 100) may collect information such as cabin temperature, location of the vehicle (e.g., the sensor being a GPS receiver) and other types of information. By collecting information such as GPS location, additional information may be provided to the vehicle information manager 102 (e.g., current location, start location, destination information) which may be used for quantifying vehicle performance. In some arrangements, information from other vehicles may be used by the vehicle information manager 102. For example, data may be collected from a fleet of vehicles (e.g., similar or dissimilar to the vehicle 100) and used, for example, in data comparisons. While one sensor 110 is illustrated in this example, multiple sensors may be located internally or externally to the vehicle for information collection (e.g., internal or external temperature or various vehicle components, etc.). One or more devices present in the vehicle 100 may also be used for information collection; for example, handheld devices (e.g., a smart phone 112, etc.) may collect and provide information (e.g., location information, identify individuals present in the vehicle such as vehicle operators, etc.) for use by the vehicle information manager 102 (e.g., identify driving characteristics of a vehicle operator). Similarly, portions of the vehicle itself (e.g., vehicle components) may collect information for the vehicle information manager 102; for example, one or more of the seats of the vehicle 100 (e.g., driver seat 114) may collect information (e.g., position of the seat to estimate the driver's weight) to provide to the vehicle information manager 102. Similar to data directly provided by one or more sensors, processed data may also be provided to the vehicle information manager 102. For example, gathered information may be processed by one or more computing devices (e.g., controllers) before being provided to the vehicle information manager 102.


In some arrangements, along with collecting information at the vehicle, remotely located information sources may be accessed by the vehicle. Once the vehicle information is collected, the data may be prepared and transmitted by the vehicle information manager 102 (along with assistance from the controller 104) to one or more locations by employing one or more communication techniques and methodologies. For example, wireless communication techniques (e.g., radio frequency, infrared, etc.) may be utilized that call upon one or more protocols and/or standards (e.g., the IEEE 802.11 family of standards such as WI-FI, the International Mobile Telecommunications-2000 (IMT-2000) specifications such as 3rd generation mobile telecommunications (3G), 4th generation cellular wireless standards (4G), 5th generation cellular wireless standards (5G), wireless technology standards for exchanging data over relatively short distances such as BLUETOOTH, etc.). While the figure illustrates the vehicle information manager 102 (and the controller 104) as being entirely located onboard the vehicle 100, some or all of the functionality of the vehicle information manager 102 may be provided from one or more other locations (including remote locations). In one such arrangement, vehicle equipment (e.g., sensors) may provide (e.g., stream) raw data to a remotely located vehicle information manager by employing one or more communication techniques and methodologies.


Referring to FIG. 2, an information-exchanging environment 200 is presented that allows information to be provided to a central location for storage and analysis (e.g., determining which vehicle, vehicle type, etc. should be operated in particular environments). In general, the information is collected from individual vehicles or other information sources for the analysis. One or more techniques and methodologies may be implemented; for example, one or more communication techniques and network architectures may be used to exchange information. In the illustrated example, a vehicle information service provider 202 communicates through a network 204 (e.g., the Internet, an intranet, a combination of networks, etc.) to exchange information with a collection of vehicles (e.g., a small fleet of supply trucks 206, 208, 210, and an automobile 212). Each of the vehicles may employ one type of propulsion system (e.g., a combustion engine, an electric motor, etc.) or a combination of system (e.g., a hybrid vehicle).


In some arrangements, the network architecture may be considered as including one or more of the vehicles. For example, vehicles may include equipment for providing one or more network nodes (e.g., supply truck 208 functions as a node for exchanging information between the supply truck 210 and the network 204). As such, the information exchanging capability may include the vehicles exchanging information with the vehicle information service provider 202 and other potential network components (e.g., other vehicles, or other vehicle components, etc.).


One or more technologies may be used to exchange information among the vehicle information service provider 202, the network 204 (or networks) and the collection of vehicles. For example, wireless technology (capable of two-way communication) may be incorporated into the vehicles to exchange information with the vehicle information service provider 202. Along with providing and collecting information (e.g., operational parameters) from the vehicles, the vehicle information service provider 202 may be capable of processing information (e.g., in concert with a vehicle data analyzer 214 to analyze data (e.g., determine vehicles for possible selection, conversion, etc.) and executing related operations (e.g., store collected and processed information).


In some arrangements, the vehicle information service provider 202 may operate as a single entity; however, operations may be distributed among various entities to provide the functionality. In some arrangements, some functionality (e.g., operations of the vehicle data analyzer 214) may be considered a service, rather than a product, and may be attained by entering into a relationship with the vehicle information service provider 202 (e.g., purchase a subscription, enter into a contractual agreement, etc.). As such, the vehicle information service provider 202 may be considered as being implemented as a cloud computing architecture in which its functionality is perceived by users (e.g., vehicle operators, business operators, vehicle designers and manufacturers, etc.) as a service rather than a product. For such arrangements, users may be provided information (e.g., vehicle or vehicle type selections for operating in particular environments, vehicle selections for conversion into hybrid vehicles, etc.) from one or more shared resources (e.g., hardware, software, etc.) used by the vehicle information service provider 202. For service compensation, one or more techniques may be utilized; for example, subscription plans for various time periods may be implemented (e.g., a time period for monitoring use of vehicles or vehicle types in particular environments, analyzing if new technology should be incorporated into or used to replace vehicles, etc.).


Along with information being provided by one or more vehicles (e.g., received through the network 204, etc.), the vehicle information service provider 202 may utilize data from other sources. For example, information sources 216 external to the vehicle information provider 202 may provide vehicle related information (e.g., manufacturer recommendations for performance, vehicle load conditions, etc.), environmental information (e.g., current road conditions where the vehicle is operating, traffic conditions, topographical information, weather conditions and forecasts, etc.). In some arrangements, the information sources 216 may be in direct communication with the vehicle information service provider 202; however, other communication techniques may also be implemented (e.g., information from the information sources 216 may be provided through one or more networks such as network 204).


In the illustrated example, to provide such functionality, the vehicle information service provider 202 includes a server 218 that receives information via the network 204 and the information sources 216. Additionally, the server 218 is illustrated as being in direct communication with a storage device 220 that is located at the vehicle information service provider 202 (however, remotely located storage may be accessed by the server 218). In this example, the functionality of the vehicle data analyzer 214 is located off-board the vehicle while the functionality of the vehicle information manager 102 (shown in FIG. 1) is located on-board the vehicle. In some examples, some functionality of the vehicle data analyzer 214 and the vehicle information manager 102 may be executed at other locations, distributed across multiple locations, etc. In one arrangement, a portion of the functionality of the vehicle data analyzer 214 may be executed on-board a vehicle or a portion of the vehicle information manager 102 may be executed at the vehicle information service provider 202. Provided the information from the one or more of sources, a variety of analysis may be developed by the vehicle data analyzer 214. For example, one or more performance metrics may be computed (e.g., from operational parameters), managed, stored etc. Comparisons between performance metrics (e.g., for a variety of vehicles, vehicle types, etc.) may also be calculated with or without employing one or more performance standards. Along with determining such metrics, comparisons, etc., functionality of the vehicle data analyzer 214 may include initiating the delivery of information (e.g., to service subscribers, entities, vehicles, etc.). One or more database systems, data management architectures and communication schemes may be utilized by the vehicle data analyzer 214 for information distribution. While a single server (e.g., server 218) is implemented in this arrangement to provide the functionality for the vehicle information service provider 202, additional servers or other types of computing devices may be used to provide the functionality. For example, operations of the vehicle data analyzer 214 may be distributed among multiple computing devices in one or more locations.


Referring to FIG. 3, one of the vehicles presented in FIG. 2 (i.e., vehicle 210) illustrates potential components included in the vehicle information manager 102, which may be implemented in hardware, software, a combination of hardware and software, etc. One included component for this arrangement is a data collector 300 that is capable of interfacing various components of the vehicle to collect vehicle-related information such as operational parameters. Additionally, the vehicle data collector 300 may be capable of collecting information from other sources external to the vehicle. Also included is a transceiver 302 that is capable of transmitting information from the vehicle to one or more locations (e.g., the vehicle information service provider 202). While the transceiver 302 is also capable of receiving information (e.g., from the vehicle information service 202), in some arrangements such a capability may be absent (thereby only allowing for transmission of information).


The vehicle information manager 102 may implement one or more techniques to improve the efficiency of transmitting information from the vehicle. For example, rather than simply transmitting all of the data (e.g., operational parameters) collected from the vehicle (by the data collector 300), techniques may be employed to reduce the amount of potentially unneeded transmissions and thereby improve efficiency and reduce costs. For example, rather than transmitting collected information at a relatively constant rate (e.g., as each segment of data is ready for transmission), one or more events may be defined and used as triggers for transmitting data. Such events may be associated with situations that occur during the operation of the vehicle 210 (although events may also be defined for situations that occur off-board the vehicle). In one instance, an event could be defined by one or more predefined rules associated with operations of the vehicle, activities detected in the vehicle, etc. For example, attaining a particular speed, acceleration, deceleration, fuel consumption level, etc., can be considered such an event, which triggers the transmission of information (e.g., time series data of the speed, acceleration, etc.) to one or more locations (e.g., the vehicle information service provider 202). Events may also be associated with vehicle location, route being driven, or other protocols. For example, based upon the GPS coordinates of the vehicle, travel direction, etc., the vehicle may stray from a predefined route and more information may be sent from the vehicle to the service provider 202. Activities of the vehicle driver may also be used to define one or more events. For example, displacement of the vehicle's accelerator pedal, brake pedal, etc. (due to the driver) may extend beyond a predefined amount and trigger the transmission of information from the transceiver 302. Detecting such predefined events may be implemented by employing one or more techniques, for example, the vehicle information manager 102 may include an event detector 304. In this arrangement, information such as operational parameters (e.g., collected by the data collector 300) is monitored by the event detector 304 to determine if one or more rules have been satisfied to declare a predefined event (or multiple events) as being detected. In some arrangements, the event detector 304 may use a series of predefined rules (e.g., “vehicle speed has exceeded 80 mph”, “battery charge is below 20%”, etc.) to determine if one or more events has occurred. In some arrangements, multiple rules may need detection before an event is considered to have occurred. For example, rules may reflect hysteresis by depending upon both current conditions of the vehicle and past conditions. To assist the operations of the event detector 304, the transceiver 302 and the data collector 300, one or more data storage techniques may be employed by the vehicle information manager 102. As illustrated, one or more storage devices (e.g., memory components, hard drives, etc.) such as storage device 306 may be included in the vehicle information manager 102. Also with assisting with the operations of the information manager components, the storage device 306 may also be considered as providing a data store for information such as operational parameters (collected during the operation of the vehicle) that can be later accessed. For example, after traveling its route, collected data may retrieved from the storage device 306 (e.g., by the vehicle owner, the vehicle information service provider 202, etc.) for analysis to quantify performance, to compare performance with other vehicles, etc. The data may be obtained in relation to particular system components and the analysis may provide insight on changing particular components to improve operating efficiencies. New vehicle components installed can have unique serial numbers that get tied to the vehicle (VIN). Once any component is installed, replaced, serviced or updated (including software), then the database for that VIN is updated to reflect the current state of art related to that component, the vehicle and associated systems.


Once a predefined event or multiple events have been detected (e.g., by the event detector 304), one or more type of changes may be introduced for transmitting data from the vehicle 210 to one or more locations (e.g., the vehicle information service provider 202). In one arrangement, upon detection the amount of information being transmitted increases, e.g., to allow for a more detailed analysis to be performed (by the vehicle information service provider 202). To increase the amount of information, one or more techniques may be utilized such as including more information in transmissions. The information may be obtained from vehicle components, particularly where those components have been replaced or upgraded with smart or intelligent vehicle components that provide self-identifying information (e.g., to the vehicle controller. For example, different information (e.g., a time series of pedal displacement) may be transmitted based upon the event detected (e.g., the vehicle brake pedal being abruptly stepped on by the driver). In some arrangements, this additional data to be included in transmissions may be defined along with the event. Data transmission properties may also be changed upon the detection of an event (by the event detector 304) to increase the amount of information being sent. For example, prior to detection, information may be transmitted (e.g., from the transceiver 302) at one frequency and post detection the transmission frequency may be increased (e.g., for a period of time). Bursts of information may be sent from the vehicle to the vehicle information service provider 202 due to event detection. Similar to adjusting transmission characteristics for a single period of time (e.g., increase transmission frequency for a period of time and then return to the original transmission frequency), such characteristics may be periodically adjusted. For example, based upon an event being detected, a repetitive sequence of higher transmission frequency periods followed by lower transmission frequency periods may be employed by the transceiver 302. As such, a sequence of information bursts followed by periods of less information being transmitted may be utilized for efficient data transfer. Similar to frequency, other transmission properties involving compression, modulation schemes, etc. may be changed due to the detection of an event (by the event detector 304).


The installation of vehicle components provided to improve the efficiency of a vehicle can be an event that prompts the transmission of information. The installation event can cause a vehicle controller onboard the vehicle to connect with a remote computing system of a vehicle information service provider. Referring to FIG. 4A, a flowchart 400a represents operations of a computing system (remotely located from a vehicle), such as the computer system 218 of the vehicle information service provider 202 in FIG. 2, operable through a server side user interface (UI). The server side user interface can be presented on the display of the computer system 218. At 402, a request is transmitted from the server side computing system 218 to a vehicle remote from the server (e.g., to the vehicle information manager 102 onboard vehicle 100). In particular implementations, the first request is transmitted from the server in response to the vehicle information manager 102 establishing a connection to the computer system 218. The vehicle information manager 102 can initiate a connection with the computer system 218 whenever a new part is installed (including part replacement) and/or whenever software for a vehicle component is updated. For example, one or more sensors can detect the installation of new component(s). The sensors may be configured to initiate a detection sequence upon start up of a vehicle, for example. These vehicle components have unique serial numbers that are tied to the vehicle identification number (VIN) (e.g., for supply chain, warranty and tracking purposes). Once any components is installed, replaced, serviced or updated (including software), then the database for that VIN is updated to reflect the updated component and associated systems. The computer system 218 electronically fetches the serial numbers, part numbers and software version from the vehicle information manager 102 and/or directly from one or more of the “smart” components (battery, telematics, hybrid controller, inverter, and charger) installed. A specific protocol is developed to fetch the serial numbers and transmit them to the computer system 218 upon request (e.g., upon installation. An automated check is then executed by the computer system 218 to see if the numbers reported by the vehicle match the existing numbers stored in the database for that vehicle. If they do not match, the database is updated with new data. In certain implementations, a reporting message is sent from the computer system 218 to the vehicle information manager 102 when the database is updated.


At 404, the computing system 218 receives a first serial number for a vehicle component responsive to the first request. In some implementations, the serial number may include a part number and/or a part name that is received with the first serial number for the vehicle component (or other type of data that represents this information). In certain implementations, the first request includes request for serial numbers for multiple parts. At 406, the first serial number is stored on a memory of the computing device. For example, stored on a storage device such as storage device 220. In certain implementations, distributed storing could also be used, for example across multiple storage devices. At 408, a second request is transmitted from computing system 218 to the vehicle following a time period after storing the first serial number on the memory of the computing device. In certain implementations, the time period may be a pre-set period or a minimum period. In some implementations, the time may be an arbitrary period and may be a period allotted for the vehicle to traverse a certain distance or mileage since the first request. For example, the first request may include a mileage of the vehicle and the second request may only be allowed and/or obtained after the vehicle has reached a particular mileage beyond the mileage at the first request. The mileage can include partial miles. In certain implementations, the computer system 218 periodically requests serial numbers from the vehicle and if it finds any mismatch then it will update the database with the latest data. The computer system 218 may also be configured to spot check serial numbers periodically. The computer system 218 may also be configured to periodically poll the vehicle for serial numbers and cross verifies it with database entries. This guards against components swaps being done without service notes being correspondingly updated by a technician. For example, this periodic checking can be programmed to occur every 7 days.


At 410, the computing system 218 receives a second serial number for the vehicle component responsive to the second request. In certain implementations, where the first request includes request for serial numbers for multiple parts the second request includes request for serial numbers for the parts for which numbers were requested in the first request. At 412, the computing system 218 compares the second serial number received to the first serial number previously stored on the memory of the computing device 218. Various comparisons techniques can be employed, such as compare received data, compare information embedded in the received data, compare data (e.g., compressed data) prior to processing or post processed data. If the second serial number received responsive to the second request is different from the first serial number stored on the memory of the computing device, then the memory of the computing device is updated with the second serial number stored in place of the first serial number. Other information associated with second serial number may also be saved with the second serial number, for example a new software version, a new part number, and/or a new vehicle mileage, a vehicle location. In certain implementations, the second serial number may cause the computing system to send updates to the vehicle related to the new vehicle components. The updates can include updates to a control strategy for the propulsion system, updates to software for the vehicle information manager 102, and/or updates for operating characteristics or parameters associated with the vehicle part replaced (e.g. updates for charging parameters, regenerative braking, acceleration, discharge rate, for a new battery component installed).


Referring to FIG. 4B, a flow chart 400b of operations of the vehicle information manager 102 is presented that represents an arrangement for transmitting data responsive to vehicular events. In general, the operations illustrate methods for extracting data from a vehicle in connection with the occurrence of particular events, such as replacing or installing a new vehicle component. As described herein, these vehicle components have unique serial numbers that are tied to the vehicle (VIN) for supply chain, warranty and tracking purposes. Once any component is installed, replaced, serviced or updated (including software), then the database for that VIN is updated to reflect the current state of art related to that component and associated systems. At 422, the vehicle information manager 102 connects to the server side computing system 218 remote from the vehicle. At 424, the vehicle information manager 102 receives a request from the computing system 218 for a serial number for a vehicle component. At 426, the vehicle information controller 102 identifies a data set of the vehicle component in a vehicle memory storage device and the vehicle information controller selects the serial number for the vehicle component from the data set identified at 428. The vehicle information manager 102 fetches the serial number for various vehicle components through a protocol such as a universal (UDS) protocol or a proprietary protocol or universal (UDS) protocol. At 430, the serial number for the vehicle component is transmitted to the computing system 218 for further analysis as described in connection with FIG. 4A.


Referring to FIGS. 5A and 5B, upfitters can follow an installation guideline provided by an installation application shown in FIG. 5C when installing components on a vehicle. The installation 500 demonstrates installation of an electric motor and driveshaft components on a vehicle, for example when upfitted a gasoline powered vehicle with electric components during a hybrid conversion. The installation may provide details to the upfitter regarding the level of difficulty 504 of the install, the number of steps 506, the amount of time required 508, and other details (e.g., the number of sections 510). The application provides various step by step illustrations 502, 512, and 534 that provide demonstrative images of phases of installation of the components (e.g., components 536, 538). These illustrations are accompanied by specific instructions 518, 520, and 522 and 544, 546, for the upfitter to follow at each phase, respectively for the upfitter. The upfitter is directed through these phases via the guidelines 550 shown in FIG. 5B, where the upfitter selects the appropriate selection 552 for the parts being installed.



FIG. 5C illustrates a snapshot of an application upfitters use to release a vehicle after components have been installed on the vehicle. The upfitter application 560 shows a snapshot of the application upfitters use to release vehicles. The application 560 is abstracted enough to tell the upfitter if the vehicle is good for release or not. Once all the “checks” are confirmed, the upfitters get an option to mark the vehicle for release—this, which saves time going back and forth with our production team on checking the status of each vehicle. The upfitter application 560 matches serial numbers 562 for the parts received to the vehicle identification number of the vehicle. The application can be used to check particular systems 564 being installed and may have certain minimum requirements 566 that must be met before a vehicle is considered “good” for release. The checks may include traversing a particular number of trips 570. The trips 570, which may have a particular mileage requirements may be checked by the vehicle information manager, which can record vehicle mileage when the part is initially installed and thereafter and report this information to the application 560. The status indicator 574 indicates when the trips have been successfully completed. The checks implemented by the application may include a tracking feature where the application queries serial numbers and checks the serial numbers queried against a remote database to make sure that components that were shipped in a kit for installation, were indeed the same components that got installed. This tracking feature is advantageous where multiple kits are shipped to an upfitting location for installing in several vehicles. The kits may be unique to the each vehicle, but an operator error could cause components to be installed in an incorrect vehicle. The tracking feature in the upfitter application will help protect against such operator errors.



FIG. 6 shows an example computer device 600 and example mobile computer device 650, which can be used to implement the techniques described herein. For example, a portion or all of the operations of an information manager (e.g., the vehicle information manger 102 shown in FIG. 1) and/or a vehicle analyzer (e.g., the vehicle data analyzer 214 shown in FIG. 2) may be executed by the computer device 600 and/or the mobile computer device 650. Computing device 600 is intended to represent various forms of digital computers, including, e.g., laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Computing device 650 is intended to represent various forms of mobile devices, including, e.g., personal digital assistants, cellular telephones, smartphones, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the techniques described and/or claimed in this document.


Computing device 600 includes processor 602, memory 604, storage device 606, high-speed interface 608 connecting to memory 604 and high-speed expansion ports 610, and low speed interface 612 connecting to low speed bus 614 and storage device 606. Each of components 602, 604, 606, 608, 610, and 612, are interconnected using various busses, and can be mounted on a common motherboard or in other manners as appropriate. Processor 602 can process instructions for execution within computing device 600, including instructions stored in memory 604 or on storage device 606, to display graphical data for a GUI on an external input/output device, including, e.g., display 616 coupled to high-speed interface 608. In other implementations, multiple processors and/or multiple buses can be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices 600 can be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).


Memory 604 stores data within computing device 600. In one implementation, memory 604 is a volatile memory unit or units. In another implementation, memory 604 is a non-volatile memory unit or units. Memory 604 also can be another form of computer-readable medium, including, e.g., a magnetic or optical disk.


Storage device 606 is capable of providing mass storage for computing device 600. In one implementation, storage device 606 can be or contain a computer-readable medium, including, e.g., a floppy disk device, a hard disk device, an optical disk device, a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. A computer program product can be tangibly embodied in a data carrier. The computer program product also can contain instructions that, when executed, perform one or more methods, including, e.g., those described above. The data carrier is a computer- or machine-readable medium, including, e.g., memory 604, storage device 606, memory on processor 602, and the like.


High-speed controller 608 manages bandwidth-intensive operations for computing device 600, while low speed controller 612 manages lower bandwidth-intensive operations. Such allocation of functions is an example only. In one implementation, high-speed controller 608 is coupled to memory 604, display 616 (e.g., through a graphics processor or accelerator), and to high-speed expansion ports 610, which can accept various expansion cards (not shown). In certain implementations, the low-speed controller 612 is coupled to storage device 606 and low-speed expansion port 614. The low-speed expansion port, which can include various communication ports (e.g., USB, Bluetooth®, Ethernet, wireless Ethernet), can be coupled to one or more input/output devices, including, e.g., a keyboard, a pointing device, a scanner, or a networking device including, e.g., a switch or router (e.g., through a network adapter).


Computing device 600 can be implemented in a number of different forms, as shown in the figure. For example, it can be implemented as standard server 620, or multiple times in a group of such servers. It also can be implemented as part of rack server system 624. In addition or as an alternative, it can be implemented in a personal computer (e.g., laptop computer 622). In some examples, components from computing device 600 can be combined with other components in a mobile device (not shown) (e.g., device 650). Each of such devices can contain one or more of computing device 600, 650, and an entire system can be made up of multiple computing devices 600, 650 communicating with each other.


Computing device 650 includes processor 652, memory 664, and an input/output device including, e.g., display 654, communication interface 666, and transceiver 668, among other components. Device 650 also can be provided with a storage device, including, e.g., a microdrive or other device, to provide additional storage. Components 650, 652, 664, 654, 666, and 668, may each be interconnected using various buses, and several of the components can be mounted on a common motherboard or in other manners as appropriate.


Processor 652 can execute instructions within computing device 650, including instructions stored in memory 664. The processor can be implemented as a chipset of chips that include separate and multiple analog and digital processors. The processor can provide, for example, for the coordination of the other components of device 650, including, e.g., control of user interfaces, applications run by device 650, and wireless communication by device 650.


Processor 652 can communicate with a user through control interface 658 and display interface 656 coupled to display 654. Display 654 can be, for example, a TFT LCD (Thin-Film-Transistor Liquid Crystal Display) or an OLED (Organic Light Emitting Diode) display, or other appropriate display technology. Display interface 656 can comprise appropriate circuitry for driving display 654 to present graphical and other data to a user. Control interface 658 can receive commands from a user and convert them for submission to processor 652. In addition, external interface 662 can communicate with processor 642, so as to enable near area communication of device 650 with other devices. External interface 662 can provide, for example, for wired communication in some implementations, or for wireless communication in other implementations. Multiple interfaces also can be used.


Memory 664 stores data within computing device 650. Memory 664 can be implemented as one or more of a computer-readable medium or media, a volatile memory unit or units, or a non-volatile memory unit or units. Expansion memory 674 also can be provided and connected to device 850 through expansion interface 672, which can include, for example, a SIMM (Single In Line Memory Module) card interface. Such expansion memory 674 can provide extra storage space for device 650, and/or may store applications or other data for device 650. Specifically, expansion memory 674 can also include instructions to carry out or supplement the processes described above and can include secure data. Thus, for example, expansion memory 674 can be provided as a security module for device 650 and can be programmed with instructions that permit secure use of device 650. In addition, secure applications can be provided through the SIMM cards, along with additional data, including, e.g., placing identifying data on the SIMM card in a non-hackable manner.


The memory can include, for example, flash memory and/or NVRAM memory, as discussed below. In one implementation, a computer program product is tangibly embodied in a data carrier. The computer program product contains instructions that, when executed, perform one or more methods, including, e.g., those described above. The data carrier is a computer- or machine-readable medium, including, e.g., memory 664, expansion memory 674, and/or memory on processor 652, which can be received, for example, over transceiver 668 or external interface 662.


Device 650 can communicate wirelessly through communication interface 666, which can include digital signal processing circuitry where necessary. Communication interface 666 can provide for communications under various modes or protocols, including, e.g., GSM voice calls, SMS, EMS, or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others. Such communication can occur, for example, through radio-frequency transceiver 668. In addition, short-range communication can occur, including, e.g., using a Bluetooth®, Wi-Fi, or other such transceiver (not shown). In addition, GPS (Global Positioning System) receiver module 670 can provide additional navigation- and location-related wireless data to device 650, which can be used as appropriate by applications running on device 650.


Device 650 also can communicate audibly using audio codec 660, which can receive spoken data from a user and convert it to usable digital data. Audio codec 660 can likewise generate audible sound for a user, including, e.g., through a speaker, e.g., in a handset of device 650. Such sound can include sound from voice telephone calls, recorded sound (e.g., voice messages, music files, and the like) and also sound generated by applications operating on device 650.


Computing device 650 can be implemented in a number of different forms, as shown in the figure. For example, it can be implemented as cellular telephone 680. It also can be implemented as part of smartphone 682, personal digital assistant, or other similar mobile device.


Referring to FIG. 7, vehicle components 702 can be installed in a bed 704 of a vehicle having a vehicle chassis 706. The vehicle components 702 can include vehicle components, such as a motor drive, a telemetry system hybrid controller, and a battery, which components may be smart components (i.e. components with processor and control systems for communicating with the vehicle information manager wirelessly). The vehicle components 702, illustrates vehicle components installed on a vehicle that initially is a combustion engine vehicle, but is converted to improve the efficiency and/or performance of a vehicle. As described herein, the installation of the components can be guided by the installation guide 550, via application, 560. The installation of the components 702 can cause the vehicle information manager 102 to connect the computing system 218 whereby the operations of flowcharts 400a and 400b are initiated to check and log the vehicle components along with the vehicle identification number for the vehicle in a system database and any system updates required for the vehicle information controller in connection with the updated parts can be determined and installed remotely.


Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include one or more computer programs that are executable and/or interpretable on a programmable system. This includes at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.


These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms machine-readable medium and computer-readable medium refer to a computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions.


To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for presenting data to the user, and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well. For example, feedback provided to the user can be a form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback). Input from the user can be received in a form, including acoustic, speech, or tactile input.


The systems and techniques described here can be implemented in a computing system that includes a backend component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a frontend component (e.g., a client computer having a user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or a combination of such backend, middleware, or frontend components. The components of the system can be interconnected by a form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.


The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.


In some implementations, the engines described herein can be separated, combined or incorporated into a single or combined engine. The engines depicted in the figures are not intended to limit the systems described here to the software architectures shown in the figures.


A number of embodiments have been described. Nevertheless, it will be understood that various modifications can be made without departing from the spirit and scope of the processes and techniques described herein. In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps can be provided, or steps can be eliminated, from the described flows, and other components can be added to, or removed from, the described systems. Accordingly, other embodiments are within the scope of the following claims.


Also, the technology described herein may be embodied as a method, of which at least one example has been provided. The acts performed as part of the method may be ordered in any suitable way. Accordingly, implementations may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative implementations.


The claims should not be read as limited to the described order or elements unless stated to that effect. It should be understood that various changes in form and detail may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims. All implementations that come within the spirit and scope of the following claims and equivalents thereto are claimed.

Claims
  • 1. A system comprising: a computing device comprising:a memory of the computing device configured to store instructions; anda processor to execute the instructions to perform operations comprising: causing a first request to be transmitted from the computing device to a vehicle remote from the computing device,receiving, at the computing device, responsive to the first request, a first serial number for a vehicle component,storing the first serial number on the memory of the computing device,causing a second request to be transmitted from the computing device from the computing device to the vehicle to the vehicle following a period of time after storing the first serial number on the memory of the computing device,receiving at the computing device, responsive to the second request, a second serial number for the vehicle component,comparing the second serial number received responsive to the second request to the first serial number previously stored on the memory of the computing device, andupdating the memory of the computing device if the second serial number received responsive to the second request is different than the first serial number stored on the memory of the computing device.
  • 2. The system of claim 1, wherein the operations further comprise receiving a part number and a part name and storing the part number and the part name in the memory of the computing device with the first serial number.
  • 3. The system of claim 1, wherein the operations further comprise receiving a software version of a software stored on a memory device of the vehicle component and storing the software version of the software in the memory of the computing device with the first serial number.
  • 4. The system of claim 1, wherein a triggering event caused the first request to be transmitted.
  • 5. The system of claim 1, wherein the operations further comprise causing the first request to be transmitted from the computing device responsive to a controller of the vehicle connecting to the computing device.
  • 6. The system of claim 5, wherein the operations further comprise storing a date representing when a controller of the vehicle connected to the computing device.
  • 7. The system of claim 1, wherein the first request identifies a plurality of vehicle components for being provided to the computing device.
  • 8. The system of claim 1, wherein the operations further comprise identifying a location of the vehicle, the location being determined by the computing device or provided from the vehicle.
  • 9. The system of claim 1, wherein the operations further comprise requesting a mileage of the vehicle in the first request and storing the mileage of the vehicle in the memory of the computing device with the first serial number.
  • 10. The system of claim 1, wherein the operations further comprise requesting operational hours of the vehicle in the first request and storing the operational hours of the vehicle in the memory of the computing device with the first serial number.
  • 11. The system of claim 1, wherein the operations further comprise requesting a vehicle identification number of the vehicle in the first request.
  • 12. The system of claim 1, wherein the operations further comprise updating at least one operational parameter of the vehicle.
  • 13. A vehicle comprising: a vehicle propulsion system; anda vehicle controller comprising:a memory of the vehicle controller configured to store instructions, anda processor to execute the instructions to perform operations comprising: connecting the vehicle controller of the vehicle to a server remote from the vehicle,receiving a request at the vehicle from the server for a serial number for a vehicle component,identifying a data set of the vehicle component in a vehicle memory storage device,selecting the serial number for the vehicle component from the data set identified, andtransmitting the serial number for the vehicle component to the server.
  • 14. The vehicle of claim 13, wherein the vehicle propulsion system comprises a combustion engine and an electric motor.
  • 15. The vehicle of claim 13, wherein the operations further comprise transmitting a vehicle identification number of the vehicle to the server in response to receiving the request.
  • 16. The vehicle of claim 13, wherein the operations further comprise transmitting a location of the vehicle to the server in response to receiving the request.
  • 17. The vehicle of claim 13, wherein the operations further comprise transmitting a mileage of the vehicle to the server in response to receiving the request.
  • 18. The vehicle of claim 13, wherein the operations further comprise transmitting operational hours of the vehicle to the server in response to receiving the request.
  • 19. The vehicle of claim 13, wherein the operations further comprise transmitting a software version of a software stored on a memory device of the vehicle component to the server.
  • 20. The vehicle of claim 13, wherein the operations further comprise transmitting a part number of the vehicle component to the server.
  • 21. The vehicle of claim 13, wherein the operations further comprise receiving an update from the server for the vehicle controller, wherein the update is stored in the memory of the vehicle controller.
  • 22. The vehicle of claim 13, wherein the propulsion system comprises a plug-in hybrid conversion system.
  • 23. The vehicle of claim 22, wherein the vehicle comprises a truck bed and wherein the truck bed comprises at least one component of the plug-in hybrid conversion system.
  • 24. The vehicle of claim 23, wherein the at least one component comprises one or more of a motor drive, a telemetry system, a battery, and a plug-in hybrid controller.
  • 25. One or more tangible computer readable media storing instructions that are executable by a processing device, and upon such execution cause the processing device to perform operations comprising: causing a first request to be transmitted from a server to a vehicle remote from the server;receiving, at the server responsive, responsive to the first request, a first serial number for a vehicle component;storing the first serial number on a server memory device;causing a second request to be transmitted from the server to the vehicle following a period of time after storing the first serial number on the server memory device;receiving at the server, responsive to the second request a second serial number for the vehicle component;comparing the second serial number received responsive to the second request to the first serial number previously stored on the server memory device; andupdating the server memory device if the second serial number received responsive to the second request is different than the first serial number stored on the server memory device.