Browse Prior Art Database

Recommendations for Reducing Data Storage Requirements for CAN Data Disclosure Number: IPCOM000248448D
Publication Date: 2016-Nov-30
Document File: 2 page(s) / 243K

Publishing Venue

The Prior Art Database

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Recommendations for Reducing Data Storage Requirements for CAN Data

    Detailed connected vehicle data may be provided to Plug-In-Devices (PIDs), such as a mobile device. In a current approach, vehicle data from a CAN (control area network) bus is packaged by an Android or iOS app as zipped JSON (JavaScript Object Notation) files that require significant amounts of storage in a server cluster when stored for analytics purposes. This article outlines a number of approaches that may be used to reduce the storage and bandwidth requirements for CAN data.

    The CAN data may be in the form of data packets or documents in which both data labels (e.g., signal names) and values for the signals are in the form of text. For example, samples of an engine speed sensor output would be represented as the string "engine speed" and the measured value would be represented as the string of characters such as "4500 RPM." The data packet may include other data such as a time stamp (year, day, hour, minute, second, etc.), a vehicle identification number (VIN), a trip identifier, and other data. This data may also be represented as text, i.e. numbers will be represented by binary codes for numerals representing the value rather than a binary value equal to the value, e.g. "32" rather than b10000.

    CAN data storage and transmission requirements may be reduced by implementing the following practices:

1. Store "partitioned" data rather than highly repeated key data elements, such as vehicle trips, possibly with additional data analytics methods to identify key blocks of data and remove repetition.

2. Build "registries" of signal names so that signals are identified in 2 byte (typed) keys instead of in lengthy human-readable string names.

3. Store bytes as bytes, e.g. store signal timestamps as the appropriate data type in standard C99 instead of as strings and write out all data as bytes instead of as human-readable strings.

4. Store timestamps efficiently by storing as an offset relative to a base time.

5. Store arrays of data as arrays of data in-memory (even if read from files) to enable access to high performance computing libraries. Arrays of values may be appended to one another so that, given an applicable registry of signals, reading routines can seek immediately to the file sections of interest for analytics tasks.

    Fig. 1 illustrates the transformation of a CAN data packet 100 according to the above recommendations. As shown, the CAN data packet 100 may include various items of textual information in which signal names and values for signals are stored as character strings. The data packet may include identifying information such as a VIN 102 of the vehicle that generated the data packet 100 and an identifier 104 of the trip in which the data of the data packet 100 was received. Alternatively, data packets 100 may be grouped into trips by a server.

    The data packet 100 may further include one or more time stamps 106 indicating a time at which...