CA3200580A1 - Generating standardized format data from disparate, non-standardized vehicle data - Google Patents

Abstract

A system (1100) and method (1200) for generating vehicle data and surrounding contextual data into a standardized form by combining disparate, non- standardized onboard vehicle data into a central repository which is updated in real- time, that normalizes that data from non-standard to pre-defmed formats, and then makes the pre-defmed data available for consumption to authorized applications and users in raw form, or as outputs to a data product comprising data from multiple onboard signal generating sources through APIs. The system (1100) comprises an assigning authority engine (1105), a mobile device (110) for a vehicle (1000), a connected vehicle device (135) comprising on- vehicle data for the vehicle (1000), and an off vehicle source selected from a database (1125), a cloud source (1180), or a physical structure (1140).

Description

Title Generating Standardized Format Data From Disparate, Non-Standardized Vehicle Data (PLS-015W0) Technical Field [0001] The present invention generally relates to a backbone system for vehicle data.
Background Art

[0002] The prior art discusses various techniques for wireless networks for vehicles.

[0003] U.S. Patent Number 9215590 for Authentication Using Vehicle Data Pairing discloses the wireless pairing of a portable device with an on-board computer of a vehicle for authenticating a transaction with a third party.

[0004] General definitions for terms utilized in the pertinent art are set forth below.

[0005] Beacon is a management frame that contains all of the information about a network. In a WLAN, Beacon frames are periodically transmitted to announce the presence of the network.

[0006] BLUETOOTH technology is a standard short range radio link that operates in the unlicensed 2.4 gigaHertz band.

[0007] Media Access Control (MAC) Address is a unique identifier assigned to the network interface by the manufacturer.

[0008] Memory generally includes any type of integrated circuit or storage device configured for storing digital data including without limitation ROM, PROM, EEPROM, DRAM, SDRAM, SRAM, flash memory, and the like.

[0009] Organizationally Unique Identifier (OUT) is a 24-bit number that uniquely identifies a vendor, manufacturer, or organization on a worldwide basis. The OUT is used to help distinguish both physical devices and software, such as a network protocol, that belong to one entity from those that belong to another.

[00010] Processor generally includes all types of processors including without limitation microprocessors, general purpose processors, gate arrays, array processors, application specific integrated circuits (ASICs) and digital signal processors.

[00011] SCP (Secure Connection Packet) is used to provide authentication between multiple devices or a local party and remote host to allow for secure communication or the transfer of computer files.

[00012] SSID (Service Set Identifier) is a 1 to 32 byte string that uniquely names a wireless local area network.

[00013] Transfer Control Protocol/Internet Protocol ("TCP/IP") is a protocol for moving files over the Internet.

[00014] URL or Uniform Resource Locator is an address on the World Wide Web.

[00015] User Interface or UI is the junction between a user and a computer program. An interface is a set of commands or menus through which a user communicates with a program. A command driven interface is one in which the user enter commands. A menu-driven interface is one in which the user selects command choices from various menus displayed on the screen.

[00016] There are multiple sources of data that can be utilized by a vehicle for efficiency and cost savings. However, there is a need for collecting, processing and interpreting the data in a manner that can be utilized by a vehicle.
Summary Of The Invention

[00017] The present invention is a method and system for generating vehicle data and surrounding contextual data into a standardized form by combining disparate, non-standardized onboard vehicle data into a central repository which is updated in real-time, that normalizes that data from non-standard to pre-defined formats, and then makes the pre-defined data available for consumption to authorized applications and users in raw form, or as outputs to a data product comprising data from multiple onboard signal generating sources through Application Program Interfaces (APIs).

[00018] One aspect of the present invention is a method for combining disparate, non-standardized data from sources onboard a vehicle into a central repository which is updated in real-time, that normalizes that data from non-standard to pre-defined formats, and then makes that data in pre-defined form available for consumption to authorized applications and operators, based on at least one ruleset from an assigning authority.

[00019] Another aspect of the present invention is a method for generating vehicle data and surrounding contextual data into a standardized form. The method includes combining disparate, non-standardized data from a plurality of sources for a vehicle into a repository. The method also includes normalizing the non-standardized data from a non-standard format to a pre-defined format. The method also includes providing the data in the pre-defined format. The method also includes transferring the data in the pre-defined format to an RPM engine or an assigning authority

[00020] Yet another aspect of the present invention is a system for generating onboard data into a standardized form. The system preferably comprises multiple data sources for a vehicle, a communications manager, a translation layer engine, and an edge computing device. The translating layer engine is configured to translate the non-standardized data from a non-standard format to a standard format. The translation layer engine preferably combines disparate, non-standardized data from the plurality of sources for the vehicle.
The communications manager provides the data in the standard format.
Brief Description Of The Drawings

[00021] FIG. 1 is a block diagram of a system for remote profile management for utilizing data and computational information from on-vehicle and off-vehicle sources.

[00022] FIG. 2 is a block diagram of sources of data for remote profile management for a vehicle.

[00023] FIG. 3 is a block diagram of a system for remote profile management for utilizing data and computational information from on-vehicle and off-vehicle sources.

[00024] FIG. 4 is an illustration of multiple sensors on a truck.

[00025] FIG. 4A is an illustration of multiple sensors on a truck connected to a BUS for the truck.

[00026] FIG. 5 is a flow chart for a method for remote profile management for utilizing data from on-vehicle and off-vehicle sources.

[00027] FIG. 6 is a block diagram of system for a secure communication protocol for connecting a wireless device to a single access point in a vehicle.

[00028] FIG. 6A is a continuation of the block diagram of FIG. 1.

[00029] FIG. 7 is a flow chart of a method for a secure connection to a wireless network of a vehicle.

[00030] FIG. 8 is an illustration of a driver identifying a vehicle through connection of a tablet computer to an unpublished network.

[00031] FIG. 9 is an isolated view of general electrical components of a mobile communication device.

[00032] FIG. 10 is an isolated view of electrical components of a server.

[00033] FIG. 11 is a flow chart of method for securely connecting a wireless device to a single access point in a vehicle.

[00034] FIG. 12 is an illustration of a system for securely connecting a wireless device to a single access point in a vehicle.

[00035] FIG. 13 is an illustration of a driver identifying a vehicle through connection of a tablet computer to an unpublished network.

[00036] FIG. 14 is a block diagram of a system for remote profile management for utilizing data and computational information from on-vehicle and off-vehicle sources.

[00037] FIG. 15 is a block diagram of a method for generating standardized format data from disparate, non-standardized vehicle data.

[00038] FIG. 16 is a block diagram of a method for generating standardized format data from disparate, non-standardized vehicle data.

[00039] FIG. 17 is a block diagram of a system for generating standardized format data from disparate, non-standardized vehicle data.

[00040] FIG. 18 is a block diagram for a backbone system for vehicle data.

[00041] FIG. 19 is a flow chart for a backbone system for vehicle data.

[00042] FIG. 20 is a flow chart for a method for generating vehicle data and surrounding contextual data into a standardized form.
Best Mode(s) For Carrying Out The Invention

[00043] As shown in FIGS. 15-20, the present invention is preferably a method and system for generating vehicle data and surrounding contextual data into a standardized form. The present invention combines disparate, non-standardized onboard vehicle data into a central repository which is updated in real-time, that normalizes the data from non-standard to pre-defined formats, provides the data in the pre-defined format based on at least one ruleset from an assigning authority, and then makes that data in pre-defined form available for consumption to authorized applications and to users in raw form, or as outputs to a data product comprising data from multiple onboard signal generating sources through Application Program Interfaces (APIs).

[00044] With a backbone, data is sent and received from the cloud. The backbone sends the translated data to the cloud. The backbone receives a subset of data from the cloud. The subset of data is pushed from a CVD to a tablet to Apps. Backbone data sources may include both on vehicle and off vehicle sources. In the cloud a user trains the model and the user has the power there to ship down inference algorithms. Real learning is on the cloud (but an edgebone can still do some inference learning).

[00045] The edgebone, is one embodiment of a backbone and operates in essentially the same way.

[00046] A method of this invention preferably includes identifying/deciding authorized applications or users that receive a subset of a translated data based on configured authorizations. The edgebone does this without the cloud, providing a defined subset of data to the Apps. The edgebone preferably follows the rules of the RPM, it defines the schema of the data. Access to data is core to the RPM, standard format would have to be there for the RPM to work. Onboard data, from a plurality of sources onboard a vehicle. An operator can use the data that the operator has in the cab; it has a stripped-down role of data brokering. The edgebone preferably operates offline, at an edge computing device. The difference comes down to the quality of the sources.

[00047] FIG. 15 is a block diagram of a system 100 for generating onboard data into a standardized form. The system includes data sources 151-154 for a vehicle, a communications manager 155, and a translation layer engine 156.
The translating layer engine 156 is configured to translate the non-standardized data from a non-standard format to a pre-defined format. The translation layer engine 156 combines disparate, non-standardized data from the plurality of sources for the vehicle. The communications manager 155 routes the data in the pre-defined format.

[00048] In a preferred embodiment, the system 100 comprises an API generator 158, as shown in FIG. 16, configured to transform the data into a plurality of outputs to a data product comprising data from a plurality of onboard signal generating sources. The sources comprise of at least one of an engine control unit, a non-oem component, a sensor, an onboard signal generating source, or an off-vehicle source. The translating layer engine is configured to standardize the non-standardized data against a table of a plurality of known variables.
The communications manager is configured to make the data available for consumption to authorized applications and also to users in a raw form. The authorized applications or users receive a subset of a translated data based on configured authorizations.

[00049] At the translation layer 156, translation would occur on an edge computing device 150 in a vehicle, as close to the source as possible. The edge computing device 150 is configured for on-board processing and routing to a communications manager 155 for routing to a plurality of endpoints 157.
Unless the device is incapable, the edge computing device 150 preferably translates the data before it is sent up into the cloud. The data could be combined on vehicle or in the cloud, and it follows the same rules as the RPM
1130.

[00050] The edge computing device 150, is preferably on vehicle. Translation preferably occurs here, as close to the source as possible, unless the device is incapable.

[00051] The communications manager 155 is a protocol or part of the assigning authority. It is anywhere connected to data: app to app, in the cloud, through device, etc.

[00052] All vehicle data signals are preferably available through APIs and SDKs.

[00053] APIs are made available to off-vehicle sources via instructions handled by the communications manager 155 which determines if the signals should be routed to clouds 180 and 183 off-vehicle, or, to an Edge Computing Device 150 "Edgebone" for on-board processing, followed by routing determined by the communications manager 155 to endpoints 157 off vehicle, or to on vehicle end-points.

[00054] The system can occur in Clouds, in an on-vehicle device (e.g., Edgebone), or a combination of both.

[00055] In one embodiment, authorized applications or operators would receive a subset of the translated data based on configured authorizations.

[00056] As shown in FIG. 16, data from an ECU (engine control unit) 153, multiple sensors 152, and tier 1 components 151 is collected at a translation layer 156. The edge computing device 150 processes and provides the data in a pre-defined form which is then made available for consumption to authorized applications and operators.

[00057] The invention also allows the assigning authority to access data (e.g., Driver Events, Data Events, or Sensor Events data) and to inform an instruction set based on off-vehicle and/or on-vehicle data.

[00058] An "Assigning Authority" is configured to access and combine off-vehicle content and/or on-vehicle data in order to enable, disable, or manage at least one function of a mobile device connected to a CVD.

[00059] The instruction set comes from the assigning authority but lives in the devices.

[00060] MDM (Mobile Device Management) reacts to the conditions and manages the devices. MDM does the following: Tells the tablet what a driver can do and when they can do it; Adapts to the current environment as informed by the RPM; and Mobile device edge self-healing: Used to diagnose and troubleshoot¨with RPM, troubleshooting in encompassing method is possible.

[00061] SCP may be used to provide secure connection to device. Dynamic MDM would enable, disable (limit access/views), or manage at least one function on the device.

[00062] Examples:

[00063] Wheels in motion-limiting access:

[00064] In one embodiment, the assigning authority may be configured to enable or disable at least one application on the mobile device based on the vehicle, timing, event, and/or positioning ("VTEP") data (e.g., based on vehicle drive status or duty status).

[00065] Uses multiple data points to detect wheel speed and sends these data points over the secure wireless connection to the mobile device. The Device accesses the Assigning Authority's instruction set and disables, enables, or manages the Device functionalities and/or applications.

[00066] In another embodiment, the assigning authority may provide an instruction set to the Device that uses multiple data points to recognize the presence of an attached trailer and enable temporary access on the connected mobile device to additional functionality and/or Apps (e.g., access to an off-vehicle data source, temporary access, delivery instructions, or access protocols to a location (e.g., a delivery location, a building, a gate, an access controlled point of entry, a parking structure, a weigh station, a toll collection structure, a fueling equipment, a vehicle service equipment).

[00067] FIG. 20 is a flow chart for a method 1200 for generating vehicle data and surrounding contextual data into a standardized form. In block 1201, disparate, non-standardized data from several sources are combined into a repository. The sources are preferably at least one of an engine control unit (ECU), a tier 1 component, a sensor, an onboard signal generating source, or an off-vehicle source. In block 1202, the non-standardized data is normalized from a non-standard format to a pre-defined format. Preferably, normalizing the non-standardized data comprises standardizing the non-standardized data against a table of known variables. Then, in block 1203, the data in the pre-defined format, based on at least one ruleset from an assigning authority, is provided; preferably making the data available for consumption to authorized applications and also to users in a raw form.

[00068] Preferably, providing the pre-defined data comprises transforming the data into a plurality of outputs to a data product comprising data from a plurality of onboard signal generating sources through APIs. Each of the outputs is preferably defined by the data product.

[00069] The authorized applications or users receive a subset of translated data based on configured authorizations. The communications manager determines the routing of signals. Preferably, the signals are routed to an edge computing device for on-board processing, and routed by a communications manager to a plurality of endpoints. The endpoints comprise at least one of an RF manager, a mobile device, an HMI, and an on-vehicle sensors.

[00070] In another embodiment, the method further includes transferring the data in the pre-defined format to an RPM engine or an assigning authority.
Providing the data in a pre-defined format preferably comprises of transforming the data into a plurality of outputs to a data product comprising data from a plurality of onboard signal generating sources through APIs.

[00071] FIG. 1 is a block diagram of a system 1100 for remote profile management for utilizing data and computational information from on-vehicle and off-vehicle sources. The system 1100 includes a vehicle 1000, an assigning authority engine 1105, a remote profile manager (RPM) toolset 1130 with an RPM sync program 1135, and a plurality of databases 1125, both accessible through the cloud 1110. A vehicle 1000 preferably includes a CVD
135. The remote profile manager toolset 1130 preferably includes a server 1135. The plurality of databases 1125 is preferably composed of multiple databases 1125a-d.

[00072] The assigning authority engine 1105 preferably has a work assignment that has been generated for a specific vehicle 1000. In a preferred embodiment, the assigning authority engine 1105 resides at a server for the system 1100, and the RPM toolset 1130 resides at a separate server.
Alternatively, the assigning authority engine 1105 and the RPM toolset 1130 reside at the same server. The assigning authority engine 1105 is preferably configured to access and combine off-vehicle content and on-vehicle data, along with the work assignment, to produce dynamic, temporal combinations of data elements and instructions for the vehicle 1000. Additionally, the assigning authority engine 1105 provides permission to various applications to share data for app-to-app integration. In one example, the assigning authority engine 1105 grants permission to a workflow application running on a mobile communication device for the vehicle 1000 to obtain data from a navigation application running on the mobile communication device. The assigning authority engine 1105 instructs the navigation application to hare the data with the workflow application. In one specific example, the share data is GPS
coordinates for the vehicle.

[00073] FIG. 2 is a block diagram of a set 2000 of sources of data for remote profile management for a vehicle. The set 2000 preferably includes vehicles 2001, devices 2002, operations 2003, assignments 2004, third parties 2005, software apps 2006, miscellaneous 2007 and other 2008.

[00074] FIG. 3 is a block diagram of a system 1300 for remote profile management for utilizing data and computational information from on-vehicle and off-vehicle sources. As shown in FIG. 3, the system 1300 comprises an assigning authority engine 1105, a remote profile manager toolset 1130, databases (FIG. 2), cloud sources 1175, a vehicle 1000 and a CVD 135 within the vehicle 1000. The cloud sources 1175 include main protected server/cloud 1183, an original equipment manufacturer server/cloud 1182, a customer server/cloud 1181 and a public server/cloud 1180. Multiple other servers/clouds and/or databases can be utilized with the present invention without departing from the scope and spirit of the claims. The cloud sources 1175, databases, RPM 1130 and assigning authority engine 1105 communicate with the CVD 135 utilizing various wireless communication protocols including WiFi, cellular networks, BLUETOOTH, GPS, and the like. The contents of each of the databases (2001-2008) and cloud sources are accessible and combinable by the assigning authority engine 1105 to produce dynamic, temporal combinations of data elements and instructions for the vehicle 1000.
The assigning authority engine 1105 is configured to use the remote profile manager toolset 1130 to execute the dynamic, temporal combinations. The dynamic, temporal combinations access data from the cloud sources comprising third party data and vehicle, timing, event, and/or positioning ("VTEP") data 1160 to inform instruction sets delivered by the assigning authority engine 1105. The instruction sets are preferably temporal permission for the on-vehicle sources and off-vehicle sources (e.g., applications) to connect and share data with each other. One or more elements of the VTEP

data 1160 is used as the basis to synchronize timing between the data, or computational outputs of two or more sources of electronic information. A
single coherent information picture 1170 is formed from fusing data and computational information from the on-vehicle and the off-vehicle sources.
The new information data set combination (single coherent information picture) is a display of information generated from the combination of data from the on-vehicle sources and the off-vehicle sources. The data set can include dynamic route information (road condition changes due to weather, construction and the like), an updated driver's profile, vehicle engine date, cargo data, dynamic compliance rules, micro-navigation data, fuel stop data, inspection stations on the route, wireless communications connectivity status, time to destination, and the like. An example of a new information data set combination is imparting GPS location data from a truck/CVD onto cargo (the potato chips example). The new information data set combination is preferably any new combination of the connected data sources data for the specific vehicle of interest.

[00075] FIG. 14 is a block diagram of a system 1500 for remote profile management for utilizing data and computational information from on-vehicle and off-vehicle sources. At step A, VTEP data is gathered from multiple databases, cloud services and other off-vehicle sources, as well as on-vehicle sources. At step B, the RPM toolset is used to configure multiple assigning authority rules based on the collected VTEP data. At step C, multiple instruction sets are delivered to multiple cloud services, other off-vehicle sources and on-vehicle sources. At step D, off-vehicle sources such as physical infrastructure, vehicles, mobile devices, and mobile device applications share data per the delivered instruction sets. At step E, back office managers, physical infrastructure, on-vehicle and off-vehicle sources are provided with new information data set combinations enabling novel processing capabilities for the system.

[00076] In one embodiment, the off-vehicle source is a mobile application operating on a mobile device, and the data originates from the mobile application.

[00077] In another embodiment, app to app integration is utilized to generate the information data set. The app to app integration is performed at a remote server, within an app on a mobile device, on a CVD or a combination thereof.

[00078] The cloud sources preferably comprise a public cloud source, a private cloud source, a hybrid cloud source, a multi-cloud source, a service provider cloud, a telematics service provider cloud, an original equipment manufacturer cloud (truck manufacturer, Tier 1 supplier, device supplier and the like), a customer cloud (end user) and/or a public cloud.

[00079] The system also preferably includes physical infrastructures with communication devices comprising at least one of a building, a gate, an access controlled point of entry, a parking structure, a weigh station, a toll collection structure, a fueling equipment and a vehicle service equipment. In one embodiment, a passive device on a physical structure 1140, as shown in FIG.
1, broadcasts a unique ID which is received by a mobile device and a vehicle gateway device. If the passive device is a BLUETOOTH device, it broadcasts a BLUETOOTH advertisement.

[00080] Multiple vehicle connected mobility devices are preferably used with the system and comprise at least one of a tablet computer, a mobile phone, a scanning device, a beacon, a RF passive or active communication device and a signature capture device.

[00081] Affiliates with the system include at least one of another vehicle authorized to share data via vehicle-to-vehicle (V2V), Cloud, or other RF
communication protocols, a TMS system authorized by the assigning authority engine 1105 to directly take data from or provide data to the vehicle CVD 135, an authorized cloud provider, and an authorized user granted access by the assigning authority.

[00082] The vehicle 1000 is preferably one of a long-haul semi-truck, a bus, a sedan, a pick-up, a sports utility vehicle, a limousine, a sports car, a delivery truck, a van, or a mini-van.

[00083] As shown in FIG. 3, the vehicle 1000 has multiple endpoints with direct connectivity to the CVD 135, and requires no routing through a cloud service. The endpoints are user interfaces or built in displays, devices connected through fixed or wireless connection to the vehicle's CVD 135, sensors connected through a vehicle bus (see FIG. 4A) to the CVD 135, or directly to the CVD 135 via wired or wireless connection, like devices. The vehicle 1000 is preferably a primary generator and source of VTEP data 1160.

[00084] The RPM 1130 preferably comprises a RPM sync 1135 for syncing with other devices, servers, the Cloud, the CVD and the like.

[00085] The real-time data for the vehicle 1000 preferably comprises a real-time speed of the vehicle, tire pressure values from a plurality of tire sensors, refrigeration/HVAC unit values, a plurality of fluid levels, a plurality of power unit values, a real-time fuel tank capacity, and a fuel type.

[00086] The plurality of configurable real-time vehicle data trigger events comprises a value outside of a predetermined range for the real-time data of the vehicle.

[00087] The real-time driver/operator profile comprises amount of time driving during a pre-determined time period, number of rest breaks during the pre-determined time period, license compliance data, physical disabilities and driving violations.

[00088] One example of an off-vehicle source is a fuel stop. A profile of a fuel stop preferably comprises real-time types of fuels available, set billing instructions, physical dimensions of a plurality of fuel pumps, GPS
coordinates, hours of operation, food service availability, and resting area availability. The predetermined fueling time period is a time range to fuel the vehicle based on the real-time GPS location of the vehicle, the real-time speed of the vehicle, the distance to the selected fuel stop from the real-time GPS
location of the vehicle, and the hours of operation of the fuel stop.

[00089] A configuration of the vehicle 1000 is preferably selected from one of a single trailer, a dual trailer, a triple trailer, and a refrigeration trailer.

[00090] Another example of an off-vehicle source is a database (Federal, State local) with dynamic compliance rules. The dynamic compliance rules comprise speed limits, transport of toxic waste, the transport of refrigerated cargo, the rest durations for drivers/operators, the necessary insurance coverage, and the type of taxes and fees to be paid.

[00091] The workflow utilized by the assigning authority engine 1105 preferably comprises an origination location of the vehicle, a destination of the vehicle, a route to the destination, a cargo, a time of departure and a time of arrival.

[00092] In one non-limiting example, the assigning authority engine 1105 receives data over the cloud from a customer server 1181 that a shipment of bags of potato chips were damaged in transit. The assigning authority engine 1105 accesses a CVD 135 or mobile device for the vehicle that delivered the bags of potato chips to determine the origination location, the destination location and the route. The assigning authority engine 1105 uses a navigation app on the mobile device (tablet computer) to determine the route, and an elevation of the route. The assigning authority engine 1105 determines that the vehicle traveled over a high elevation mountain range that probably resulted in the damage to the bags of potato chips due to a pressure differential. The assigning authority engine 1105 uses this information to reroute a subsequent shipment of bags of potato chips to avoid the high elevation mountain range.

[00093] FIG. 4 is an illustration of multiple sensors on a truck 1000. The vehicle/truck 1000 preferably comprises an oil level sensor 1005, an engine sensor 1010, a power sensor 1015, a refrigeration/HVAC sensor 1020, a temperature sensor 1025, a tire pressure sensor 1030, and a fuel sensor 1035.

Those skilled in the pertinent art will recognize that multiple other sensors may be utilized without departing from the scope and spirit of the present invention. FIG. 4A is an illustration of multiple sensors on a truck connected to a data bus 105 for the truck. Each of the sensors (oil level sensor 1005, engine sensor 1010, a power sensor 1015, a refrigeration/HVAC sensor 1020, a temperature sensor 1025, tire pressure sensors 1030a-d, and fuel sensor 1035) is preferably connected to the data bus for transferring data to an on-board computer of the vehicle 1000, or directly to the CVD 135. Alternatively, some or all of the sensors use wireless communications to communication with the CVD 135.

[00094] FIG. 5 is a flow chart for a method 500 for remote profile management for utilizing data and computational information from on-vehicle and off-vehicle sources. At block 501, the contents of each of a plurality of databases are accessed by an assigning authority engine. At block 502, the contents are combined to produce a plurality of dynamic, temporal combinations of data elements and a plurality of instruction sets for a vehicle. At block 503, the plurality of dynamic, temporal combinations is executed. At block 504, data from a plurality of cloud sources comprising third party data and vehicle, timing, event, and/or positioning ("VTEP") data is accessed to inform the plurality of instruction sets delivered by the assigning authority engine to the RPM. At block 505, one or more elements of the VTEP data is used as a basis to synchronize timing between the data, or computational outputs of two or more sources of electronic information. At block 506, a single coherent information picture is formed from fusing data and computational information from the on-vehicle and the off-vehicle sources.

[00095] A system 10 for securely connecting a wireless device to a single access point in a vehicle for a predetermined work assignment is shown in FIGS. 6 and 6A. The system 10 preferably comprises a remote server (cloud) 11, a vehicle gateway device 130, a smart device 110 and a passive device 61.

The vehicle gateway device 130 is preferably a connected vehicle device ("CVD").

[00096] The server/cloud 11 accesses dataset 12 and obtains driver information.
Vehicle information, mobile device information (MAC address), passive device information (beacon ID) and other information to compile a SCP
packet 14. At block 15, the server 11 provides SCP definitions to the vehicle gateway device 130 and the mobile device 110. At block 16 the server/cloud 11 authorizes the SCP. At block 17, the server/cloud 11 communicates with the vehicle gateway device 130.

[00097] The vehicle gateway device 130 uses datasets 22, with the beacon ID
23, a scan of wireless devices 24 along with the SCP definitions 26 received from the server/cloud 11 to compile a CVD compiled SCP packet 25. The CVD compiled SCP packet is sent to the cloud/server 11 at block 16 and authorization/validation of the CVD compiled SCP packet is received at block 27. At block 28 the SCP is authorized for broadcasting at the vehicle gateway device 130 a wireless network with a hidden and hashed SSID unique to the vehicle, the hidden and hashed SSID generated from the validated SCP packet.
At block 29, the vehicle gateway device 130 communicates the broadcast with the server/cloud 11. At block 31, the vehicle gateway device 130 communicates with other devices, namely the smart device 110 over preferably a WiFi hotspot 32 and the passive device 61 by pairing using a BLUETOOTH communication protocol at block 33.

[00098] At block 49, the smart device (mobile device) 110 compiles a complied mobile device SCP packet from the SCP definitions 42, the data sets 48, the beacon ID 43, the Tablet ID 45, a driver ID 46, a vehicle ID 47 and scan of wireless devices 44. The mobile device 110 generates the hashed SSID and a passphrase from the complied mobile device SCP packet. At block 51, the mobile device 110 connects to the WiFi hotspot 32 of the vehicle device gateway 130.

[00099] The passive device 61 broadcast a unique ID at block 62 which is received by the mobile device 110 and the vehicle gateway device 130. At block 63, if a BLUETOOTH device, it broadcasts a BLUETOOTH
advertisement at block 64.

[000100] The SCP is defined by an assigning authority in the server/cloud 11.
The server/cloud 11 sends the SCP definition and any other required data in datasets to the CVD 130 and the mobile device 110. The CVD 130 adds the contextual data from local datasets to the sever-sent data to compile its SCP
based definition. The local datasets include data wirelessly scanned from passive devices, preferably transmitting a BLUETOOTH beacon. Other local datasets include information from the vehicle. The CVD 130 sends its compiled SCP packet to the server 11 for authorization. The server 11 verifies the CVD compiled SCP packet, and if valid, the server 11 transmits a validation/approval signal to the CVD 130. The CVD then generates an access point SSID/passphrase with SCP. Likewise, the mobile device 110 utilizes contextual data from local datasets to compile its SCP based on the definitions. The mobile device 110 connects to the access point of the CVD
130 using the SCP. The CVD 130 and the mobile device 110 also connect to the passive device 61 since it is part of the SCP definition.

[000101] As used by the assigning authority engine 1105, a predetermined work assignment is a temporal event with a fixed start and completion based on assignable boundary conditions. The assignable boundary condition is at least one of a predetermined time period, a geographical destination, and a set route. Alternatively, the assignable boundary condition is any feature with a beginning and a termination. The assigning authority is performed by a person or persons, who have the appropriate authority and mechanisms to assign specific tasks and assets to a specific vehicle and vehicle operator or custodian, and to assign workflow assignments to same. The predetermined work assignment is assigned to a known person or entity that has its own primary networked device accessible through a password protected user interface, a specific name and password that auto-populates or otherwise autoniadcally satisfies a p ura1ty of credentials requirements, wherein the plurality of credential requirements are automatically available or revoked based on the assignable boundary condition identified in a pairing event.

[000102] The CVD 130 preferably broadcasts a WiFi wireless network with a hidden and hashed SSID unique to the host vehicle and protected by a unique, dynamically generated and hashed passphrase. The vehicle ID is entered into an application on the tablet that is then converted to the same hashed SSID
and passphrase, which allows the tablet to attempt to connect to the corresponding CVD WiFi network and begin communication.

[000103] A method 900 for a secure connection to a wireless network of a vehicle is shown in FIG. 7. At block 901, a server generates definitions for a SCP packet for assigning authority for a vehicle. At block 902 the server transmits the definitions for the SCP packet to a CVD and a mobile device. At block 903, the CVD compiles the SCP packet to generate a CVD compiled SCP. At block 904, the CVD transmits the CVD compiled SCP to the server for authorization. At block 905, the server transmits authorization for the CVD
compiled SCP from to the CVD for creation of a validated SCP. At block 906, the mobile device generates a dataset to compile a mobile device compiled SCP. At block 907, the CVD broadcasts at a wireless network with a hidden and hashed SSID unique to the vehicle. The hidden and hashed SSID is generated from the validated SCP packet. At block 908, the mobile device generates the hashed SSID and a passphrase from the dataset, which allows the mobile device connect to the wireless network. At block 909, the mobile device searches for a vehicle having the CVD broadcasting the wireless network in a hidden mode. At block 910, the mobile device securely connects with the CVD.

[000104] One embodiment utilizes a system for vehicle to mobile device secure wireless communications. The system comprises a vehicle 210, a CVD 130, a mobile device 110 and a passive communication device 61. The vehicle 210 comprises an on-board computer with a memory having a vehicle identification number (VIN), a connector plug, and a motorized engine. The CVD 130 comprises a processor, a WiFi radio, a BLUETOOTH radio, a memory, and a connector for mating with the connector plug of the vehicle.
The mobile device 110 comprises a graphical user interface, a mobile application, a processor, a WiFi radio, and a cellular network interface. The passive communication device 61 operates on a BLUETOOTH
communication protocol. The server 11 is configured to generate a plurality of definitions for a SCP packet for assigning authority for the vehicle. The server 11 is configured to transmit the plurality of definitions for the SCP packet from the server to the CVD 130 and the mobile device 110. The CVD 130 is configured to compile the SCP packet to generate a CVD compiled SCP. The CVD 130 is configured to transmit the CVD compiled SCP to the server 11 for authorization. The server 11 is configured to transmit authorization for the CVD compiled SCP to the CVD 130 for creation of a validated SCP. The mobile device 110 is configured to generating a dataset to compile a mobile device compiled SCP. The CVD 130 is configured to broadcast a wireless network with a hidden and hashed SSID unique to the vehicle, the hidden and hashed SSID generated from the validated SCP packet. The mobile device 110 is configured to generate the hashed SSID and a passphrase from the dataset, which allows the mobile device connect to the wireless network. The mobile device 110 is configured to search for a vehicle having the CVD broadcasting the wireless network in a hidden mode. The mobile device 110 is configured to connect to the CVD 130 over the wireless network.

[000105] The dataset preferably comprises at least one of a plurality of definitions for the SCP packet, a tablet ID, a driver ID, a vehicle ID, a beacon ID, identified or defined entity/participant to the transaction, descriptions, actions, or states of thing, characteristics of identifiable devices, when present in a certain proximity and/or context.

[000106] Optionally, the mobile device 110 connects to a passive device, the passive device operating on a BLUETOOTH communication protocol. The passive device 61 is preferably a BLUETOOTH enabled device advertising a unique ID as a beacon or a complex system (speaker, computer, etc.) that emits BLUETOOTH enabled device advertising a unique ID as a beacon.

[000107] The mobile device 110 preferably receives input from a driver of the vehicle, and/or the server 11 contains the assigning authority that generates the SCP definitions.

[000108] The passive device 61 is preferably an internal device in the vehicle or an external device posted on a gate to a facility and generating a beacon. The beacon from the passive device is preferably a mechanism to ensure that the connection between the mobile device 110 and the CVD 130 occurs at a specific physical location dictated by the assigning authority through the server 11. Preferably, the automatic connection between the mobile device 110 and the CVD occurs because the assigning authority, through the server, has dictated that it occur.

[000109] As shown in FIG. 8, a staging yard for trucks 210a-201d, each of a multitude of trucks 210a-210d broadcast a wireless signal for a truck specific network, with one truck 210c broadcasting a wireless signal 225. However, the SSID is not published so unless a driver is already in possession of the SSID, the driver will not be able to pair the tablet computer 110 with the CVD

130 of the truck 210 to which the driver is assigned. So even though the wireless signals are being "broadcast", they will not appear on a driver's tablet computer 110 (or other mobile device) unless the tablet computer 110 has already been paired with the CVD 130 of the vehicle 210. A driver 205 in possession of a tablet computer 110 pairs, using a signal 230, the tablet computer 110 with the wireless network 225 of the CVD of the truck 210c, and thus the driver locates the specific truck 210c he is assigned to in a parking lot full of identical looking trucks 210a-d.

[000110] On an 'PHONE device from Apple, Inc., the "UDID," or Unique Device Identifier is a combination of forty numbers and letters, and is set by Apple and stays with the device forever. On an ANDROID based system, one that uses Google Inc.'s ANDROID operating system, the ID is set by Google and created when an end-user first boots up the device.

[000111] The mobile communication device 110, or mobile device, is preferably selected from mobile phones, smartphones, tablet computers, PDAs and the like. Examples of smartphones and the device vendors include the 'PHONE
smartphone from Apple, Inc., the DROID smartphone from Motorola Mobility Inc., GALAXY S smartphones from Samsung Electronics Co., Ltd., and many more. Examples of tablet computing devices include the IPAD tablet computer from Apple Inc., and the XOOMTm tablet computer from Motorola Mobility Inc.

[000112] Wireless standards utilized include 802.11a, 802.11b, 802.11g, AX.25, 3G, CDPD, CDMA, GSM, GPRS, radio, microwave, laser, Bluetooth, 802.15, 802.16, and IrDA.

[000113] BLUETOOTHTm technology operates in the unlicensed 2.4 GHz band of the radio-frequency spectrum, and in a preferred embodiment the secondary device 30 and/or primary device 25 is capable of receiving and transmitting signals using BLUETOOTHTm technology. LTE Frequency Bands include 698-7981V1Hz (Band 12, 13, 14, 17); 791-960MHz (Band 5, 6, 8, 18,19,20);
1710-2170MHz (Band 1, 2, 3, 4, 9, 10, 23, 25, 33, 34, 35, 36, 37, 39); 1427-1660.5MH (Band 11, 21, 24); 2300-2700MHz (Band 7, 38, 40, 41); 3400-3800MHz (Band 22, 42, 43), and in a preferred embodiment the secondary device 30 and/or the primary device 25 is capable of receiving and transmitting signals using one or more of the LTE frequency bands. WiFi preferably operates using 802.11a, 802.11b, 802.11g, 802.11n communication formats as set for the by the IEEE, and in in a preferred embodiment the secondary device 30 and/or the primary device 25 is capable of receiving and transmitting signals using one or more of the 802.11 communication formats.
Near-field communications (NFC) may also be utilized.

[000114] As shown in FIG. 9, a typical mobile communication device 110 preferably includes an accelerometer 301, I/0 (input/output) 302, a microphone 303, a speaker 304, a GPS chipset 305, a Bluetooth component 306, a Wi-Fi component 307, a 3G/4G component 308, RAM memory 309, a main processor 310, an OS (operating system) 311, applications/software 312, a Flash memory 313, SIM card 314, LCD display 315, a camera 316, a power management circuit 317, a battery 318 or power source, a magnetometer 319, and a gyroscope 320.

[000115] Each of the interface descriptions preferably discloses use of at least one communication protocol to establish handshaking or bi-directional communications. These protocols preferably include but are not limited to XML, HTTP, TCP/IP, Serial, UDP, FTP, Web Services, WAP, SMTP, SMPP, DTS, Stored Procedures, Import/Export, Global Positioning Triangulation, IM, SMS, MMS, GPRS and Flash. Databases that may be used with the system preferably include but are not limited to MSSQL, Access, MySQL, Progress, Oracle, DB2, Open Source DBs and others. Operating system used with the system preferably include Microsoft 2010, XP, Vista, 200o Server, 2003 Server, 2008 Server, Windows Mobile, Linux, Android, Unix, I series, AS 400 and Apple OS.

[000116] The underlying protocol at the cloud server 11, is preferably Internet Protocol Suite (Transfer Control Protocol/Internet Protocol ("TCP/IP")), and the transmission protocol to receive a file is preferably a file transfer protocol ("FTP"), Hypertext Transfer Protocol ("HTTP"), Secure Hypertext Transfer Protocol ("HTTPS") or other similar protocols. The transmission protocol ranges from SIP to MGCP to FTP and beyond. The protocol at the authentication server 40 is most preferably HTTPS.

[000117] Wireless standards include 802.11a, 802.11b, 802.11g, AX.25, 3G, CDPD, CDMA, GSM, GPRS, radio, microwave, laser, Bluetooth, 802.15, 802.16, and IrDA.

[000118] Components of a cloud computing server 40 of the system, as shown in FIG. 10, preferably includes a CPU component 401, a graphics component 402, PCl/PCI Express 403, memory 404, non-removable storage 407, removable storage 408, Network Interface 409, including one or more connections to a fixed network, and SQL database(s) 415a-415d. Included in the memory 404, is an operating system 405, a SQL server 406 or other database engine, and computer programs/software 410. The server 40 also preferably includes at least one computer program configured to receive data uploads and store the data uploads in the SQL database. Alternatively, the SQL server can be installed in a separate server from the server 40.

[000119] A flow chart for an alternative method 600 for a secure connection to a wireless network of a vehicle is shown in FIG. 11. At block 601, the CVD
broadcasts an encrypted, blind SSID based on specific vehicle data. At block 602, leveraging the known vehicle data and the encryption algorithm a mobile device searches for a vehicle having a CVD broadcasting the wireless network. At block 603, the mobile device is connected with the CVD.

[000120] A system for a secure connection to a wireless network of a vehicle is shown in FIG. 12. A truck 210a. Those skilled in the pertinent art will recognize that the truck 210a may be replaced by any type of vehicle (such as a bus, sedan, pick-up, sport utility vehicle, limousine, sports car, delivery truck, van, mini-van, motorcycle, and the like) without departing from the scope of spirit of the present invention. The truck 210a preferably comprises a motorized engine 234, a vehicle identification number ("VIN"), an on-board computer 232 with a memory 231 and a connector plug 235. The on-board computer 232 preferably has a digital copy of the VIN in the memory 231.
The on-board computer 232 is preferably in communication with the motorized engine 234. The truck 210a may also have a GPS component for location and navigation purposes, a satellite radio such as SIRIUS satellite radio, a driver graphical interface display, a battery, a source of fuel and other components found in a conventional long distance truck.

[000121] Also in the truck 210a is a CVD 130 comprising a processor, a WiFi radio, a BLUETOOTH radio, a memory and a connector to connect to the connector plug of the on-board computer 232.

[000122] A driver 205 preferably has a mobile communication device such as a tablet computer 110 in order to pair with a wireless network generated by the CVD 130 of the truck 210a. The tablet computer 110 preferably comprises a graphical user interface 335, a processor 310, a WiFi radio 307, a BLUETOOTH radio 306, and a cellular network interface 308.

[000123] As shown in FIG. 13, a staging yard for trucks 210a-210k, each of a multitude of trucks 210a-210k broadcast a wireless signal 224a-k for a truck specific network, with one truck 210f broadcasting a wireless signal 225.
However, all of the wireless signal 224a-224k and 225 do not publish their respective S SID so that a mobile device 110 must already be paired with the CVD 130 of the truck 210 in order to connect to the truck based wireless network 224a-224k or 225 of each of the CVDs 130 of each of the trucks 210a-210k. A driver 205 in possession of a tablet computer 110 pairs with the specific truck wireless network 225 of the CVD 130 of the truck 210f, and thus the driver locates the specific truck 210f he is assigned to in a parking lot full of identical looking trucks 210a-210k.

[000124] One embodiment is a system for utilizing a remote profile manager for vehicle dynamic compliance with multiple vehicle statutes and regulations.
The system comprises a truck 210, a CVD 130, a tablet computer 110, a server 140 and a plurality of databases. The vehicle comprises an on-board computer with a memory having a vehicle identification number (VIN), a connector plug, and a motorized engine. The CVD 130 comprises a processor, a WiFi radio, a BLUETOOTH radio, a memory, and a connector for mating with the connector plug of the vehicle. The tablet computer 110 comprises a graphical user interface, a processor, a WiFi radio, a BLUETOOTH radio, and a cellular network interface. A location of the truck 210 is determined using a GPS
component of the truck 210. The location of the truck 210 is transmitted to the server 140 by the CVD. The server 140 retrieves real-time compliance rules for the location of the truck from the plurality of databases, which are preferably State vehicle databases, municipal vehicle databases, county vehicle databases, and Federal vehicle databases. The server 140 transmits the real-time compliance rules to CVD 130 for display on the tablet computer 110 so that a driver of the truck 210 can stay in real-time compliance with State and Federal motor vehicle and driving rules. The rules pertain to speed limits, transport of toxic waste, the transport of refrigerated cargo, the rest durations for drivers, the necessary insurance coverage, the type of taxes and fees to be paid, and the like. The display on the tablet computer is preferably in the form of a visual alert, an audio alert or a haptic alert. Other displays include forms such as attestation forms, and data such as timers, current speed limits, and the like. The trigger for each jurisdiction is preferably from the GPS of the truck 210, the speed of the truck 210, cellular or WiFi triangulation from a network, and the like.

[000125] The CVD 130 obtains the vehicle identification number (VIN) from the on-board computer and transmits the VIN with the location to the server 140 for verification of the truck 210.

[000126] Another embodiment is a system for utilizing a remote profile manager for utilizing multiple vehicle odometer values. The system comprises a vehicle 210, a CVD 130, a tablet computer 110, a server 140 and a plurality of databases. The vehicle comprises an on-board computer with a memory having a vehicle identification number (VIN), a connector plug, a motorized engine, an odometer component from an engine source, an odometer component from a dashboard source, an odometer component from a chassis source, and an odometer component from a transmission source. Thus, the truck 210 has a multiple of odometers that can be used to determine a mileage of the truck 210. The connected vehicle device (CVD) 130 comprises a processor, a WiFi radio, a BLUETOOTH radio, a memory, and a connector for mating with the connector plug of the vehicle. The tablet computer 110 comprises a graphical user interface, a processor, a WiFi radio, a BLUETOOTH radio, and a cellular network interface. Each of the odometer component from an engine source, the odometer component from a dashboard source, the odometer component from a chassis source, and the odometer component from a transmission source generates an odometer value. The CVD 130 generates a delta value for odometer value relative to a control odometer value. The CVD 130 monitors the odometer value from each of the odometer component from an engine source, the odometer component from a dashboard source, the odometer component from a chassis source, and the odometer component from a transmission source. The CVD 130 generates a new odometer value for one of the odometer component from an engine source, the odometer component from a dashboard source, the odometer component from a chassis source, and the odometer component from a transmission source, and the CVD modifies the odometer value by the delta value to generate the new odometer value.

[000127] An operating system controls the execution of other computer programs, running of the PSO platform, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The operating system may be, for example Windows (available from Microsoft, Corp. of Redmond, Wash.), LINUX or other UNIX variants (available from Red Hat of Raleigh, N.C. and various other vendors), Android and variants thereof (available from Google, Inc. of Mountain View, Calif.), Apple OS X, iOs and variants thereof (available from Apple, Inc. of Cupertino, Calif.), or the like.

[000128] The system and method described in connection with the embodiments disclosed herein is preferably embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module preferably resides in flash memory, ROM memory, EPROM memory, EEPROM memory, RAM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is preferably coupled to the processor, so that the processor reads information from, and writes information to, the storage medium. In the alternative, the storage medium is integral to the processor.
In additional embodiments, the processor and the storage medium reside in an Application Specific Integrated Circuit (ASIC). In additional embodiments, the processor and the storage medium reside as discrete components in a computing device. In additional embodiments, the events and/or actions of a method reside as one or any combination or set of codes and/or instructions on a machine-readable medium and/or computer-readable medium, which are incorporated into a computer software program.

[000129] In additional embodiments, the functions described are implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions are stored or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage medium is any available media that is accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures, and that can be accessed by a computer. Also, any connection is termed a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.
"Disk" and "disc", as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and BLU-RAY disc where disks usually reproduce data magnetically, while discs usually reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable medium.

[000130] A computer program code for carrying out operations of the Present Invention is preferably written in an object oriented, scripted or unscripted programming language such as C++, C#, SQL, Java, Python, Javascript, Typescript, PHP, Ruby, or the like.

[000131] Each of the interface descriptions preferably discloses use of at least one communication protocol to establish handshaking or bi-directional communications. These protocols preferably include but are not limited to XML, HTTP, TCP/IP, Serial, UDP, FTP, Web Services, WAP, SMTP, SMPP, DTS, Stored Procedures, Import/Export, Global Positioning Triangulation, IM, SMS, MIMS, GPRS and Flash. The databases used with the system preferably include but are not limited to MS SQL, Access, My SQL, Oracle, DB2, Open Source DB s and others. Operating system used with the system preferably include Microsoft 2010, XP, Vista, 200o Server, 2003 Server, 2008 Server, Windows Mobile, Linux, Android, Unix, I series, AS 400 and Apple OS.

[000132] The underlying protocol at a server, is preferably Internet Protocol Suite (Transfer Control Protocol/Internet Protocol ("TCP/IP")), and the transmission protocol to receive a file is preferably a file transfer protocol ("FTP"), Hypertext Transfer Protocol ("HTTP"), Secure Hypertext Transfer Protocol ("HTTPS"), or other similar protocols. The protocol at the server is preferably HTTPS.Components of a server includes a CPU component, a graphics component, memory, non-removable storage, removable storage, Network Interface, including one or more connections to a fixed network, and SQL database(s). Included in the memory, is an operating system, a SQL
server or other database engine, and computer programs/software.

Claims (26)

Claims

1. A method for generating vehicle data and surrounding contextual data into a standardized form, the method comprising:
combining disparate, non-standardized data from a plurality of sources into a repository;
normalizing the non-standardized data from a non-standard format to a pre-defined format; and providing the data in the pre-defined format based on at least one ruleset from an assigning authority.

2. The method according to claim 1 wherein the plurality of sources comprises at least one of an engine control unit, a non-OEM component, a sensor, an onboard signal generating source, or an off-vehicle source.

3. The method according to claim 1 wherein normalizing the non-standardized data comprises standardizing the non-standardized data against a table of a plurality of known variables.

4. The method according to claim 1 wherein providing the data in a pre-defined format comprises transforming the data into a plurality of inputs to a data product comprising data from a plurality of onboard signal generating sources through application program interfaces.

5. The method according to claim 4 wherein each of the plurality of inputs is defined by the data product.

6. The method according to claim 1 wherein providing the data in a pre-defined format comprises making the data available for consumption to authorized applications and users.

7. The method according to claim 6 wherein a communications manager is configured to make the data available for consumption to users in a raw form.

8. The method according to claim 6 wherein authorized applications or users receive a subset of a translated data based on configured authorizations.

9. The method according to claim 1 further comprising determining a routing of signals via a communications manager.

10. The method according to claim 1 further comprising routing the signals to an edge computing device for on-board processing, and routing by a communications manager to a plurality of endpoints, wherein the plurality of endpoints comprises at least one of a RF manager, a mobile device, an HMI, and an on-vehicle sensors.

11. The method according to claim 1 further comprising transferring data in the standard format to an assigning authority or to an RPM engine.

12. A system for generating onboard data into a standardized form, the system comprising:
a plurality of data sources for a vehicle;
a communications manager; and a translation layer engine;
wherein the translating layer engine is configured to translate the non-standardized data from a non-standard format to a standard format;
wherein the translation layer engine combines disparate, non-standardized data from the plurality of sources for the vehicle;
and wherein the communications manager routes the data in the standard format.

13. The system according to claim 12 further comprising an edge computing device, wherein the edge computing device is configured for on-board processing and routing to a communications manager for routing to a plurality of endpoints.

14. The system according to claim 12 further comprising an API generator configured to transform the data into a plurality of outputs to a data product comprising data from a plurality of onboard signal generating sources.

15. The system according to claim 12 wherein the plurality of sources comprises at least one of an engine control unit, a non-OEM component, a sensor, an onboard signal generating source, or an off-vehicle source.

16. The system according to claim 12 wherein the translating layer engine is configured to standardize the non-standardized data against a table of a plurality of known variables.

17. The system according to claim 12 wherein the communications manager is configured to make the data available for consumption to authorized applications and users.

18. The method according to claim 17 wherein a communications manager is configured to make the data available for consumption to users in the raw form.

19. The system according to claim 17 wherein authorized applications or users receive a subset of a translated data based on configured authorizations.

20. A method for generating vehicle data and surrounding contextual data into a standardized form, the method comprising:
combining disparate, non-standardized data from a plurality of sources for a vehicle into a repository;

normalizing the non-standardized data from a non-standard format to a standard format;
providing the data in a pre-defined format; and transferring the data in the pre-defined format to an RPM engine or an assigning authority.

21. The method according to claim 20 wherein the plurality of sources comprises at least one of an engine control unit, a non-OEM component, a sensor, an onboard signal generating source, or an off-vehicle source.

22. The method according to claim 20 wherein normalizing the non-standardized data comprises standardizing the non-standardized data against a table of a plurality of known variables.

23. The method according to claim 20 wherein providing the data in a standard format comprises transforming the data into a plurality of outputs to a data product comprising data from a plurality of onboard signal generating sources through application program interfaces.

24. The method according to claim 23 wherein each of the plurality of outputs is defined by the data product.

25. The method according to claim 20 further comprising determining a routing of signals via a communications manager.

26. The method according to claim 20 further comprising routing the signals to an edge computing device for on-board processing, and routing by a communications manager to a plurality of endpoints.