Data Export and Optimization Technique in Connected Vehicle

Introducing the “connected vehicle (CV) guidance system”, a brand-new category of guiding system. This system makes use of connected car [1] technology to achieve dynamic vehicle guidance. The “CV guidance system” enables dynamic guiding for “ECU network flow” through “’real-time Signal information” and is based on “vehicle-to-vehicle [2] (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-smart terminal (V2T) technologies”. The connections in modern cars can be internal (like the bus systems that link the sensors and processors inside, for example) or external (like the protocols that allow connectivity between passing vehicles). The connected car [3], which is a vehicle with Internet connectivity, communication capabilities with other vehicles and road infrastructure, and the ability to gather real-time data from multiple sources, is predicted to be a key player in the future Internet of Things [4]. With the support of hardware and software that facilitate widespread knowledge transfer rapidly via the internet, around the world, technology is developing [5] quickly. Information technology professionals can effortlessly by sending information over the internet. Not all data can be sent easily, though. A method of transforming data from one representation to another compressed (in bits) representation that retains the same information but is as small as possible is known as data compression. By deleting unwanted or duplicated information, the size of the data is decreased. Reduced storage and/or communication costs allow for the storage [6] or transmission of the data. By compressing a file to half its original size, the storage medium's capacity is increased. When this occurs, it might be possible to store the data higher up in the storage hierarchy, which would ease the load on the system's input/output channels. Lossless and Lossy compression are two different compression methods. The input image and the reconstructed image are identical in a lossless compression [7] strategy. Techniques for lossless picture compression first divide the images into their component pixels. Comparing lossy and lossless compression, lossy compression offers a higher compression ratio. With this process, there is some information loss in the compressed image, which makes it different from the original image. The entire transmission of information at a specific time is the basic objective of digital communications. If the data being transferred is huge, it will be challenging to accomplish this goal because larger data take longer to transmit fully. The “Huffman Algorithm, Lempel-Ziv Algorithm, Shannon-Fano Elias Encoding, Arithmetic Coding [8], and Adaptive Coding” are only a few of the source coding methods that are accessible. The bulk of ECUs shares important status information about the vehicle using the “controller area network (CAN) protocol”, which is the de facto standard for in-car network connectivity. To prevent hackers from learning about CAN [9] messages that control crucial commands, automakers have made the data in the “CAN database confidential (i.e., DBC format file)”. Some studies have tried to recreate a DBC format file to lessen this. Invasive and non-invasive strategies can be used to classify these attempts. The intrusive technique involves disassembling cars to directly examine an ECU and check its programming. The non-invasive method may be preferable for reconstruction because the intrusive procedure can easily be stopped by any preventative measure, like turning off a debugging port. This paper's major objective is to create an embedded system that can connect to an M2M broker, connect with other integrated devices using a cloud server, and be changeable using a cloud-based web service. The MQTT protocol was selected for this study's aims because it seemed to best fit the requirements presented. Using a publish-subscription architecture, MQTT [10] is an open-source TCP protocol. Clients "subscribe" to desired subjects in publish-subscribe ("pub-sub") by connecting to a central broker. Any client nodes that have subscribed to that topic will get any messages that a client "publishes" to. Since it is a TCP-based protocol, MQTT has a comparatively high overhead but also offers a high level of guaranteed [11] Quality of Service (QoS) and allows both one-to-one and one-to-many messages. MQTT is reasonably simple to utilize for apps thanks to its many open-source libraries and active support community.

For effective graphic user interface design and development, intelligent software and tools are needed. These tools are utilized when creating designs, beautifying the GUI [12], and acquiring necessary data. Utilizing these technologies has advantages such as a streamlined design tool that enables you to ship better designs more quickly. better typography, redlines, colors, measurement, and other tools. This survey offers a thorough examination of the instruments. Different frameworks and tools, including Figma, Whimsical, and Open Dataset, are examined based on their features and intended uses. We developed the Connected-Car Prototyping [13] Framework and repeatable program templates to enable the prototype of informatics services. The platform and templates speed up the time to market and make it easier to produce prototypes. They are constructed using cloud concepts to reduce the initial setup costs for prototypes and boost scalability. It is now simple to provide connected services that are online applications for desktops thanks to a range of tools and back-end technologies. For numerous Web platforms and programming languages, these frameworks and platforms provide software development kits. They frequently offer services like data storage, data compression, and enhancement of application development. Time-to-market and flexibility become essential when future client demand is unknown. We created the Connected-Car Prototyping [14] Platform to overcome these issues and make telematics and cloud service development simpler. It offers a back end for programs communicating with an automobile's ECU.

To help you understand our process more clearly, we've included some background information in this section.

3.1 In-vehicle network

Many car features are electronically regulated for the comfort and safety of the driver. A modern automobile has several ECUs fitted to run the digital features. The status of a vehicle is periodically measured by ECUs, and some operations are controlled based on these observations. The ECU either starts the engine on its own or sends instructions to another ECU to start the engine based on the measurement. Vehicles can function more safely and effectively thanks to this automated control system, and more are being created all the time. Modern luxury cars frequently have a number of ECUs fitted. A group of ECUs creates an internal network within the vehicle where they can communicate. The internal network can be further subdivided into sub-networks based on comparable functions. An ECU communication protocol, such as LIN, CAN, or Flex Ray, is re-quired for in-vehicle networks. The CAN protocol, which offers a limited transmission delay between ECUs, is the most popular of them.

3.2 CAN protocol

The two distinct frame formats that are provided in the CAN standard are the “standard frame format and the extended frame format (only described in CAN 2.0 B) [22]”. In contrast to the regular frame format, which only supports an “11-bit identifier, the extended frame format supports a 29-bit identification that is made up of the 11-bit identity plus an 18-bit extended identifier”. Most ECUs in a car is smaller than 2 power 11 and communicate with one another using the common frame format. “Data, remote, error, and overload frames” are the four main frame types used by ECUs to exchange data inside an “in-vehicle CAN network”. Data frame messages are the most typical CAN communications that ECUs send. A CAN data frame includes fields including an “identifier (ID), data length code (DLC), data, and cyclic redundancy check (CRC)”, as seen in Tables 1 and 2. The three stages involved in the process are as follows:

Table 1. Standard CAN frame format

Table 2. Extended CAN frame format

Instead of the receiver's identifier, the identifier field relates to the transmitters. In general, it is expected that ECUs do not share the same identifier and that a single ECU has several identifiers. Typically, manufacturers go to tremendous lengths to maintain the secrecy of which identifiers correspond to which functions.

3.3 Structure of data payload field

There must be at least one signal in a CAN data payload [23]. A signal is a bit of information that an ECU sends, like a car speed or the rotational speed of its wheels. The DBC format file for the appropriate vehicle specifies the length and quantity of the signals, which change depending on the CAN ID. Our method is intended to count the list of signals and their length in CAN data without the use of a DBC format file by analyzing CAN traffic. Additionally, signals include a variety of information types, including the following.

The values of a physical value signal, such as the speed of the wheels or the angle of the steering wheel, correspond to a physical state of a vehicle. As a result, various signals are transmitted over a CAN network inside the car. A signal called a counter always has a value that is one higher than the previous message. For a certain CAN ID, the counter allows “verification of the ECU transmitting messages”. Additionally, a receiving ECU can identify a retransmission of a previously received CAN message. A signal called a checksum contains the results of a checksum on a payload of data. Checksums frequently find transmission mistakes. Although the CRC field in the CAN data is specified, some manufacturers provide a second checksum field in the CAN data to enable a more robust, dependable CAN connection in their vehicles. An unchanging signal is one that is unused or constant. The DBC format file standard states that a signal's maximum and minimum values may be the same. It suggests a constant. Additionally, unused fields can be given to some bits in a data payload.

3.4 Data compression

Digital data transmission and reception are the focus of digital communications. These kinds of data can hold the data that must be conveyed. It can be in text, image, video, document, among other formats. Prior to transmission, the data must be transformed into digital format, which produces a stream of bits with a logic value of either 1 or 0. These details must always be transmitted in full at a specific time. Source encoding is employed in this situation to make up for it. Source encoding is a method for lowering the typical number of bits utilized for a particular file. To maximize data transfer, this is utilized to compress the data.

There are different kinds of source coding methods, including the “Shannon-Fano Algorithm, Lempel-Ziv Algorithm, and Huffman Algorithm”. “The Huffman and Lempel-Ziv algorithm” is the most often utilized of these since it produces code words with high compression ratios and a short average length. The entire transmission of information at a specific time is the basic objective of digital communications. If the data being transferred is huge, it will be challenging to accomplish this goal because larger data take longer to transmit fully.

The applications of the Huffman and Lempel-Ziv Algorithms, two source encoding methods, to many sorts of data formats, only text, are the main emphasis of this study. These algorithms were widely utilized because they produce code words with short average lengths and high compression ratios.

3.4.1 Huffman algorithm

The “Huffman code” is a variable-length, “prefix-free code” that can achieve the shortest codeword length for a given symbol that may be longer than its entropy. In this algorithm, the least frequent symbol is given the fewest bits, followed by the most frequent symbol given the most bits. ASCII character data compression is the focus of Huffman coding. Numerous types of data, including text, audio, video, and images, are compressed using it. This method is based on developing a complete binary tree for each symbol in the original file after figuring out the probability of each symbol and sorting the symbols by reducing probability. Lossless compression techniques are included in the Huffman compression algorithm [24]. A compression technique known as lossless compression does not alter the underlying data information to make it smaller.

Huffman's approach is that each ASCII character is typically represented by 8 bits. As an illustration, if a file has the character "UUVWX" in a row, it has 40 bits, 5 bytes, or 5 bits. We only require a file that is 10 bits in size (0010111110) if each character is assigned a code, such as U=0, V=10, W=111, or X=110. that specifies that codes must be identical, or that a code cannot be generated from some other code.

3.4.2 Run length encoding

RLE, also known as run-length encoding, is the most straightforward data compression approach. This algorithm distinguishes between runs and non-runs by identifying successive symbol sequences as runs. This algorithm handles a certain amount of redundancy. Based on their redundancies and their lengths, it evaluates whether there are any repetitive symbols. All other sequences are regarded as non-runs, while consecutive recurrent symbols are labelled as runs. For instance, if the file "AYAZZZZA" is chosen to optimize, the first three letters are regarded as a non-run with a length of 3, while the following four characters are regarded as a run with a length of 4 because the symbol Z is repeated. This algorithm's primary priority is to locate the runs in the source file and to mark each run's symbol and length [25]. While storing all the non-runs and not using any of those runs for the compression process, the RLE algorithm uses those runs to optimize the main research file.

The Run Length Encoding Algorithm and others are implemented and analyzed in a set of data files to calculate the performance of the lossless compression technique. The mentioned factors are evaluated to measure results.

3.4.3 Lempel Zev Welch algorithm

In general, the LZW method uses a dictionary and is a lossless compression algorithm. Dictionary-based techniques do this instead of having a statistical model as their core. A dictionary is a collection of all words that can be used in a language. Larger and more frequent dictionary words are represented by the entries' indexes, which are preserved in a table-like format. The most popular method is known as the LZW algorithm [26]. Instead of repeating string patterns, these index values are used during compression. Instead of using repetitive string patterns, these index values are used during compression. The dictionary is generated dynamically during the compression process; thus, it is not necessary to send it along with the encoded message for decompression. During decom-pression, the same dictionary is dynamically created.

3.4.4 Evaluate the performance of the different algorithms

Depending on the application, a compression algorithm's performance can be evaluated using a variety of factors. As a result, calculating effectiveness is challenging, and many measurements should be used to analyze the performance of those compression categories. The measurements used to evaluate how well lossless algorithms work are listed below.

Compression Ratio: It describes the proportion of the source file's size to the compressed file's size.

$C R=\frac{\text { Size after compression }}{\text { size before compression }}$

Saving percentage:

Saving %$=\frac{\text { size before compression }- \text { size after compression }}{\text { size before compression }}

$

Compression factor: It is the absolute opposite of compression ratio.

$C F=\frac{\text { Size before compression }}{\text { size after compression }}$

The relative compression ratios, compression factor, and saving percentage for each compression approach are shown in Table 3 and, as can be seen. Of all the data sets, the run length encoding has the most reasonable compression ratio. RLE is hardly ever used in lossless data compression today. The Huffman encoding approach, which focuses solely on minimizing input data redundancy, is the optimal alternative based on what is currently known about compression ratio. Although, Huffman encoding, which provides a moderate compression percentage and factor. The success of Lempel-Ziv-Welch encoding in obtaining higher compression ratios depends in large part on dictionary size.

Table 3. Shows the comparison between saving%, compression factor, and ratio

3.5 GUI design

As a starting point for designing our platform, we initially gathered high-level functional and non-functional requirements. A GUI's main objective is to free the user up to focus on the current task. The interface between a human and a computer must be flawless for this to happen. An effective GUI [27] design eliminates the barrier to user-computer communication and enables focus on the issue at hand. The market success of today's software applications relies on effective GUI design since a good GUI makes an application simple, useful, and efficient to execute. There are numerous ways to present information given a collection of data to display. The readability of the material is enhanced by proper grouping, which can also highlight connections between the information. Three selectable tabs have been used to organize the GUI information.

•Technical details and evaluation: The user must specify their name (for login credentials) and, if desired, the name of the testing organization. Other information about the car may be recorded, such its physical value, arbitration ID, hexadecimal value, vehicle identification (year of launched) etc. On the other hand, the vehicle model-dependent signal measurement parameters that are dynamically modifiable can be calibrated online.

•Real – Time data: Real-time data enables the user to view signal information immediately or as needed.

•Historical data record: Information from the database may be accessed and viewed, and it can also be compressed.

This Figure 1 shows the flowchart of GUI design, it describes how we design the GUI for our research so there are some steps:

•     First, search for the Car name (for example i.e... Maruti) it will fetch the data from the database.

•     After showing the data of the Car, it shows the data of the variant and launched a year of data.

•     There is an option for uploading a DBC text file.

•     After uploading the file, it will show the list of messages and signals with CAN ID.

•     After getting lists, we can get Real-time data of all signals which we selected.

1.png

Figure 1. Flowchart of GUI web design

CAN DBC format file: DBC files are sometimes used to refer to database files for CAN.

A straightforward text file called a DBC file offers instructions for turning raw CAN bus [28] data into numbers or into a human-readable format. The DBC file is offered since it is the most often used method of managing data identification and translation. In order to provide a mechanism to retain records in a CAN network, the DBC file [29] format was developed as shown in Figure 2.

2.png

Figure 2. CAN data using DBC file

A text file known as a CAN DBC file (CAN database) contains instructions for translating raw CAN bus data into "physical. We have a file, which we have taken from the Open-source platform (Nissan leaf) that "extracts" parameters (signals) from the data bytes, we have a CAN DBC that has decoding rules for the CAN ID. Steer angle rate, Gas pedal inverted, and many more such signals. Figure 3, specifies how to decode CAN messages and signals at the core of a DBC file:

DBC message syntax explained

•     The ID must be distinct and in decimal, and the message begins with BO_ (not hexadecimal).

•     To act as an "extended ID" indication, the DBC ID adds three additional bits to 29-bit CAN IDs.

•     The name should be distinct, 1-32 characters long, and allow for [A-z], numbers, and underscores.

•     A number between 0 and 1785 must make up the length (DLC).

•     The sender is the name of the transmitting node or, in the absence of a name, Vector XXX.

DBC signal syntax explained

•     There are one or more signals that begin with SG_ in every message.

•     The name may be up to 32 characters long, distinct, and may contain any combination of letters, digits, and underscores (a-z).

•     Beginning with 0, the bit start signals the beginning of the signal in tqhe data payload.

•     Signal length is equal to bit length.

•     The @1 indicates the byte order.

•     The plus symbol indicates that a value is unsigned (vs - for signed signals).

•     The physical value linear equation uses the (scale, offset) values (more below).

•     The receiving node's name is known as the receiver; once more, Vector XXX is used by default as shown in Figures 4 and 5.

3.png

Figure 3. DBC message and signal syntax

4.png

Figure 4. List of messages from the DBC file

5.png

Figure 5. List of signal from the DBC file

MQTT Cloud: MQTT is an OASIS standard messaging for IOT MQTT is utilized in many different industries today, including manufacturing, telecommunications, and the automobile sector. It utilizes one-to-one, one-to-many, and many-to-one communication mechanisms and has the highest overhead and QoS of TCP. The MQTT protocol is employed as a suitable protocol mechanism for the Internet of things and M2M claims. It makes use of a publish/subscribe protocol built for simple M2M protocol. An MQTT broker receives messages that an MQTT [30] client publishes and that other clients have subscribed to or have reserved for future subscriptions.

Benefits of using MQTT:

•     Lightweight and efficient.

•     Bi-directional communication.

•     Reliable message delivery.

•     Security enabled.

The widely used and well-supported Linux platform MQTT broker Mosquitto is simple to use. The cloud-based Mosquito [31] MQTT broker is in operation. As a result, it may receive messages from IoT devices everywhere. You can use that Cloud MQTT broker with many Telematics boards on various networks. To connect with the broker, each Telematics board needs to be attached to a router that provides internet access. The boards can communicate with one another by publishing and subscribing to the same topics because they use the same MQTT broker. You may have many IoT devices (such as ESP node MCU and Arduino Uno board) communicate with one another using a cloud MQTT broker even if they are on different networks by using a cloud based MQTT broker (different locations connected to different routers).

Figure 6 shows that we used Open DBC, a publicly accessible online database, as the baseline for evaluating our methodology. As previously indicated, it is challenging for researchers to secure a genuine DBC format because automobile makers keep them in strict confidence. One possible solution to this issue is Open DBC. SPI will be used to connect the CAN trans receiver to the Arduino, and CAN Hi/Low will be used to connect to the ECU. Using the software, we used a serial CAN trans receiver and Arduino to create an algorithm that transfers data to the cloud using the MQTT protocol. After transferring data and using an algorithm, compressed data will be shown in the GUI web application. In Figure 7, it shows the generalized system architecture of Raw data.

6.png

Figure 6. Integration between GUI design and hardware

7.png

Figure7. Generalized system architecture of cloud, raw data, and signals

Hardware Setup: The hardware configuration, shown in Figure 8, System Architecture consists of:

•     Arduino uno (with external Wi-fi module connected).

•     CAN trans receiver, the Arduino will be connected to the MCP2515 CAN-bus converter through the Serial Peripheral Interface (SPI).

•     By using software, we use a serial CAN trans receiver and Arduino to create an algorithm that transfers data to the cloud using the MQTT protocol.

•     After transferring data and using an algorithm, compressed data will be shown in the GUI web application.

8.png

Figure 8. Generalized system architecture of hardware

After the platform system experiment. The completed hardware setup is constructed, as shown in Figure 8. The Arduino UNO microcontroller will receive data in CAN communication from the ECU (Signal) via a CAN transceiver. SPI will be used to connect the CAN trans receiver to the Arduino, and CAN Hi/Low will be used to connect to the ECU. Data from the ECU will be in the form of a data packet, which will also include other data in hexadecimal format. Using the REST architectural technique and the Telematics Wi-Fi module, data obtained from the ECU will be sent to the cloud. By using software serial, the [32] MCP2515, and Arduino may create algorithms that transfer data using the MQTT protocol. For future works, this proposed system can be simulated in MATLAB & Simulink as this software by MathWorks has great capabilities [33, 34].