A Design of a Lightweight In-Vehicle Edge Gateway for the Self-Diagnosis of an Autonomous Vehicle

applied sciences

Article A Design of a Lightweight In-Vehicle Edge Gateway for the Self-Diagnosis of an Autonomous Vehicle

YiNa Jeong 1, SuRak Son 1, EunHee Jeong 2 and ByungKwan Lee 1,*

1 Department of Computer Engineering, Catholic Kwandong University, Gangneung 25601, Korea; [email protected] (Y.J.); [email protected] (S.S.) 2 Department of Regional Economics, Kangwon National University, Samcheok 25913, Korea; [email protected] * Correspondence: [email protected]; Tel.: +82-033-649-7160

Received: 8 August 2018; Accepted: 6 September 2018; Published: 9 September 2018

Abstract: This paper proposes a Lightweight In-Vehicle Edge Gateway (LI-VEG) for the self-diagnosis of an autonomous vehicle, which supports a rapid and accurate communication between in-vehicle sensors and a self-diagnosis module and between in-vehicle protocols. A paper on the self-diagnosis module has been published previously, thus this paper only covers the LI-VEG, not the self-diagnosis. The LI-VEG consists of an In-Vehicle Sending and Receiving Layer (InV-SRL), an InV-Management Layer (InV-ML) and an InV-Data Translator Layer (InV-DTL). First, the InV-SRL receives the messages from FlexRay, Control Area Network (CAN), Media Oriented Systems Transport (MOST), and Ethernet and transfers the received messages to the InV-ML. Second, the InV-ML manages the message transmission and reception of FlexRay, CAN, MOST, and Ethernet and an Address Mapping Table. Third, the InV-DTL decomposes the message of FlexRay, CAN, MOST, and Ethernet and recomposes the decomposed messages to the frame suitable for a destination protocol. The performance analysis of the LI-VEG shows that the transmission delay time about message translation and transmission is reduced by an average of 10.83% and the transmission delay time caused by trafﬁc overhead is improved by an average of 0.95%. Therefore, the LI-VEG has higher compatibility and is more cost effective because it applies a software gateway to the OBD, compared to a hardware gateway. In addition, it can reduce the transmission error and overhead caused by message decomposition because of a lightweight message header.

Keywords: Address Mapping Table; In-Vehicle Edge Gateway; self-diagnosis

1. Introduction In the future, more than 200 billion devices will be connected to the cloud and each other in what is commonly called the Internet of Things (IoT) [1]. Therefore, An IoT gateway that is a physical device or software program as the connection point between the cloud and controllers, sensors and intelligent devices plays important role. IoT gateway provides a place to preprocess the data located at the edge before sending it on to the cloud and supports communication between heterogeneous devices. The gateways of connected cars, which are currently being developed, are similar to IoT gateways. As shown in Figure1, the connected car’s ECUs and Gateway need to handle many requirements, such as enhancing engine control and transmission control performance; securing stability through ABS, LDW, and FCW; and increasing convenience through camera and body control. To address these needs, the number of ECUs used in vehicles has increased dramatically and ECUs are connected to various protocols depending on their characteristics [2].

Appl. Sci. 2018, 8, 1594; doi:10.3390/app8091594 www.mdpi.com/journal/applsci Appl. Sci. 2018, 8, 1594 2 of 19 Appl. Sci. 2018, 8, x FOR PEER REVIEW 2 of 19

FigureFigure 1. VehicleVehicle gateways that need to handle in-vehiclein-vehicle sensor data.

To process process such such a alarge large amount amount of data, of data, various various communication communication protocols protocols such as such FlexRay, as FlexRay, MOST, MOST,CAN and CAN Ethernet and Ethernet are used are inside used the inside vehicle. the CAN,vehicle. a low-speedCAN, a low (1-speed Mbps) (1 communication Mbps) communication protocol protocolused in conventional used in conventional in-vehicle communications, in-vehicle communications, is used to process is used relatively to process less important relatively vehicle less importantcontrol sensor vehicle data. control FlexRay, sensor a high-speeddata. FlexRay, (10 a Mbps) high-speed communication (10 Mbps) protocol,communication is mainly protocol, used tois processmainly used control to process data of control major parts data of amajor vehicle. parts MOST of a vehicle. and Ethernet MOST haveand Ethernet speeds uphave to speeds 150 Mbps. up toMOST 150 Mbps. is a ring MOST type networkis a ring that type processes network multimedia that processes data multimedia such as voice data and such video as inside voice theand vehicle, video insideand Ethernet the vehicle, can be and used Ethernet as a backbone can be of used in-vehicle as a network backbone or of as in a V2X-vehicle communication network or protocol. as a V2X communicationTo support protoc these protocols,ol. there have been various studies on the gateway inside the vehicle. However,To support gateways these with protocols, minimum there transmission have been delayvarious only studies support on somethe gateway protocols inside such the as vehicle. CAN to However,FlexRay and gateways MOST to with CAN, minimum and gateways transmission that support delay communication only support some for all protocols protocols such had increased as CAN totransmission FlexRay and delay. MOST to CAN, and gateways that support communication for all protocols had increasedTo support transmission the four delay. major protocols (i.e., CAN, FlexRay, MOST, and Ethernet) used for in-vehicle communicationsTo support the and four to minimize major protocols the transmission (i.e., CAN, delay FlexRay, of gateways, MOST, and this Ethernet) paper proposes used for a inLightweight-vehicle communications In-Vehicle Edge and Gateway to minimize (LI-VEG) the for transmission the self-diagnosis delay of of an gateways, autonomous this vehicle. paper Theproposes LI-VEG a Ligh receivestweight the In messages-Vehicle from Edge the Gateway source sensor(LI-VEG) or actuator,for the self translates-diagnosis the of received an autonomous messages vehicle.into the formatThe LI- ofVEG a destination receives the protocol, messages and from transfers the the source translated sensor messages or actuator, to the translates destination the receivedECU, sensor, messages or actuator, into the and format the of messages a destination received protocol, from aand source transfers to the the self-diagnosis translated messages module. toBecause the destination the LI-VEG ECU, supports sensor, four or major actuator, protocols, and contrarythe messages to the received existing vehicle from a gateway, source to it has the selfgood-diagnosis scalability module. and compatibility. Because the In LI addition,-VEG supports The LI-VEG four major is indispensable protocols, tocontrary self-diagnosis to the existing module vehicleof an autonomous gateway, it vehiclehas good due scalability to its rapidity and comp and accuracy.atibility. AIn paperaddition, on theThe self-diagnosis LI-VEG is indispensable module has toalready self-diagnosis been published module [ 3of], thusan autonomous this paper only vehicle covers due the to its LI-VEG, rapidity not and the accuracy. self-diagnosis. A paper on the self-diagnosisThe remainder module of has the paperalready is been organized published as follows. [3], thus In Sectionthis paper2, related only covers works the are LI introduced.-VEG, not theIn Section self-diagnosis.3, the configuration and operation of LI-VEG are described. In Section4, the performance evaluationThe remainder focuses inof particularthe paper onis organized the transmission as follows. delay In andSection error 2, raterelated for messageworks are transmission. introduced. InFinally, Section Section 3, the5 configurationpresents the conclusions and operation of the of paper.LI-VEG are described. In Section 4, the performance evaluation focuses in particular on the transmission delay and error rate for message transmission. Finally,2. Related Section Works 5 presents the conclusions of the paper. 2.1. On-Board Diagnostics 2. Related Works Onboard-diagnostic (OBD) is an automotive term for self-diagnosis and reporting of vehicles. 2.1.OBD On system-Board isDiagnostics developed to detect engine operation conditions for air-pollution monitoring [4]. The basicOnboard meaning-diagnostic of OBD is as(OBD) above is andan automotive it is used in term various for ways.self-diagnosis OBD related and researchreporting is of as vehicles. follows. OBDConfiguration system is developed of on-board to detect diagnostics engine system operation and conditions diagnostic communicationfor air-pollution module monitoring ELM327 [4]. Theare introduced.basic meaning According of OBD to is elements as above of and ELM327 it is used and Keywordin various 2000 ways. protocols, OBD related an OBDII research diagnostic is as procedurefollows. is developed based on LabVIEW program [5]. ConfigurationOchs. T. et al. of [6 on] developed-board diagnostics exhaust system gas sensors and diagnostic for particulate communication matter (EGS-PM) module based ELM327 on aremultilayer introduced. ceramic According sensor technology. to elements Sensors of ELM327 must be and able Keyword to detect soot 2000 emissions protocols, directly an OBDII after diagnosticthe DPF, be procedure able to withstand is developed harsh based exhaust on gasLabVIEW environments, program and [5]. meet future OBD legislation that includesOchs. stricter T. et requirements al. [6] developed for monitoring exhaust gas the sensors function for of particulate the filter. matter (EGS-PM) based on multilayerKamimoto. ceramic T. etsensor al. [7 ]technology. reviewed currently Sensors must soot sensorsbe able developedto detect soot for on-boardemissions diagnosticsdirectly after to themonitor DPF, a be diesel able particulate to withstand filter harsh and exhaust detect the gas failure. environments, Original and equipment meet future manufacturers OBD legislation have that includes stricter requirements for monitoring the function of the filter. Appl. Sci. 2018, 8, 1594 3 of 19 selected a resistive soot sensor for the on-board diagnostics application because of its commercial feasibility in terms of functionality and cost. The sensor accumulates soot particles in exhaust gas on the sensing element. As powertrains become more electric, the number of on-board diagnostics relevant to Electronic Control Units (ECUs) continues to grow. Vector provides a summary of the on-board diagnostics functions integrated in the AUTOSAR basic software (BSW) and which use cases they support [8]. Mobile communication offers one-way data collection for remote surveillance when data transmission is continuously linked with server through mobile communication. Data acquisition is handled by on-board unit via EV CAN network. However, on-line data size, e.g., state of health, is so huge that it is not easily transmitted when hundreds of vehicles are simultaneously connected for data logging into server. Taking SOH as example, it is a challenge to effectively provide the continuity of curve variation for remote health estimation. Hence, estimation theory is applied and embedded into hardware implementation before data reporting [9]. Every vehicle will be equipped with a central unit which will acquire speed data (and compute the average speed) from the on-board sensors of a car using an OBD device, and process and deliver the data to the server using the ZigBee protocol, with a ZigBee transmitter employed in every vehicle and the receivers mounted on light poles. These receivers then route the received traffic information to a localized server shared by several junctions or clusters [10]. OBD a critical tool used for emission control in today’s automobiles. OBD generates fault codes when any system/component non-compliance is detected. Commercially available tools fetch fault codes from OBD and are providing only limited information/access of basic data to engineers. These tools are black box type of tools which provide very limited flexibility. In addition, the data storage capacity of these diagnostic tools is very limited. Next, we review the related study of OBD-II, which is the next version of OBD [11]. The extraction of all the available data in EV CAN network has been done systematically through OBD-II port and by using low-level software libraries and programming a development board based on ARM STM32F103RBT6 micro-controller [12]. An OBD II reader is designed to measure speed and mass air flow, from which the distance and fuel consumption are also computed. These data are then transmitted via WiFi to a remote server. The system also implements global positioning system tracking to determine the location of the vehicle. A database management system is implemented at the remote server for the storage and management of transmitted data and a graphical user interface is developed for analyzing the transmitted data [13]. One of the key issues enabling future solutions is achieving an effective integration between mobile apps and vehicles. Such integration can be efficiently achieved on all existing vehicles by relying on the OBD-II interface. This allows obtaining critical information such as speed, fuel consumption, gas emissions and system failures [14]. Tsai, Y.C. et al. [15] proposed an on-board safe driving assist system using vehicle dynamics and real-time traffic information. It immediately detects harsh driving behavior and alerts the driver. The in-vehicle dynamics are collected from OBD-II, an accelerometer and a gyroscope. The real-time traffic information is collected from a camera with image processing. The proposed estimator exploits low-cost inertial measurement unit (IMU) and OBD-II of the vehicle to achieve navigation data without any aid of GPS. The presented estimator is based on extended Kalman filter and linear Kalman filter for vehicle attitude and 3-D velocity estimations, respectively. For accurate estimations in GPS-free situations, the extended and linear Kalman filters receive the inertial data and the vehicle speed from the IMU and the OBD-II, respectively. The proposed estimator tracks the vehicle trajectory velocity in GPS-free environments [16]. The remote diagnostic system in a vehicle includes a LoRa module, an Arduino (Uno), and an OBD-II bridge. The OBD-II bridge can read some vehicle information to detect whether any is abnormal (e.g., coolant temperature is too high) and then transmits the abnormal vehicle information from OBD-II to Arduino by UART. When abnormal vehicle information is detected, the abnormal Appl. Sci. 2018, 8, 1594 4 of 19 events will immediately be sent to LoRa gateway via Arduino and LoRa module. Furthermore, LoRa gateway transmits abnormal vehicle information to cloud platform for recording the abnormal events via Ethernet. Moreover, the recorded abnormal events can be provided to vehicle maintenance plant [17].

2.2. Vehicle Protocol The CAN (bus arbitration mechanism) [18] protocol is used as standard in most vehicles today. However, it cannot handle many data. Both MOST and FlexRay communication mechanisms have been designed in consideration of the communication speed of these CAN buses and the limitation of data communication load [19]. The following is a related study of the vehicle protocol. Yang J.S. et al. [20] introduced a FlexRay-CAN gateway that uses node mapping. It is possible to solve the problem of the gateway of the vehicle such as the ID change of the message mapping-based gateway or the software complexity. Mejdi H. et al. [21] adopted a new way to achieve the design and the implementation of the FlexRay Controller which consists of the translation of the (Speciﬁcation and Description Language) SDL diagrams into State Flow diagrams. With these diagrams, we generate the VHDL code of the controller which will be implemented in an FPGA to create the hardware chip for FlexRay. The transmission reliability and the slot utilization are deﬁned for FlexRay network, and their quantitative calculating formulas are deduced. To ensure reliable network transmission and maximize bandwidth utilization of network, frame packing of FlexRay is formulated as generalized integer linear programming, and an optimized model is presented [22]. Chen Y.Y. et al. [23] proposed an effective two-level redundancy approach for safety-critical FlexRay network systems. The proposed approach demonstrates how to employ the backup nodes, mirrored tasks and task migration to sustain the operation of system when ECUs fail. We then perform the redundancy analysis and develop the analytical reliability models for the assessment of fault-tolerant FlexRay network systems in early design phase. Gu Z et al. [24] considered the problem of mapping an application task graph onto a FlexRay-based distributed hardware platform, to meet security and deadline requirements while minimizing the number of hardware coprocessors needed in the system. We present a Mixed Integer Linear Programming (MILP) formulation, a divide-and-conquer heuristic algorithm, and a Simulated Annealing algorithm. Jang S.J. et al. [25] proposed a FlexRay-based software reprogramming optimization, and we analyze the performance of FlexRay and CAN FD software reprogramming. To achieve this, we perform a theoretical analysis on the software reprogramming times of the protocol, and we compare the performance of the software reprogramming optimized FlexRay and CAN FD. Abdellaoui Z. et al. [26] focused on the development of FlexRay drivers and Simulink Block set implementations to validate performance and design, and to provide innovative capabilities for today and tomorrow to distributed systems in automotive applications. The proposed block set is dedicated for the SAE (Society of Automotive Engineers) application. The SAE benchmark model is normally connected by the CAN bus, but we extend it to the FlexRay bus. In [27], they also proposed a vehicle Simulink block set model. The proposed block set corresponds to the Society of Automotive Engineers SAE benchmark model which is normally connected by the CAN bus, but we extend it to the FlexRay bus. Zeng W. et al. [28] outlined improvements to FlexRay and Ethernet in automotive communications networks. Protocols need to improve the protocol to meet the needs of tomorrow’s automotive networks, but Ethernet can speed development and expand faster. Amel B.N. et al. [29] showed how to use DDS over an Ethernet network and proposed a SAE benchmark as a test application. The main goal is to calculate the worst-case response time (WCRT) based on the scheduling model and the use it as a metric to evaluate the DDS real-time QoS (Quality of Service). The results obtained using Ethernet are compared with those found using FlexRay. Appl. Sci. 2018, 8, 1594 5 of 19

Mundhenk P. et al. [30] proposed a virtual communication layer for time-triggered networks, enabling a policy-based message scheduling as well as preemption which in turn simplifies real-time verification. The introduced layer is particularly advantageous in the automotive domain since it reduces the complexity of scheduling time-triggered communication systems and simplifies incremental changes of existing schedules. Yan W. et al. [31] proposed a new FlexRay bus data acquisition and calibration system based on a high-speed and flexible USB interface. The system overcomes the shortcomings of traditional FlexRay bus test equipment, such as complex software and hardware. Dong Z.H. et al. [32] proposed a FlexRay-MOST gateway architecture. The proposed gateway system is designed with Verilog HDL and implemented using SoC kits. Lee S. et al. [33] explained the difference between the in-vehicle network CAN and MOST. CAN is a widely used in-vehicle network for control data and MOST is a network for multimedia data. However, CAN and MOST do not integrate and operate independently. Seo H.S. et al. [34] proposed a universal plug and play (UPnP) controller area network (CAN) gateway system using UPnP middleware for interoperability between external smart devices and an in-vehicle network. The proposed gateway consists of an UPnP communication device, a CAN communication device, and a device translator layer. An automatic CAN gateway test system has been proposed to solve the difficulties and complexity problems of manual vehicle gateway testing. The test system integrates IPC, CAN tools and network control module. It supports 2–4 channel gateways as well as complex gateways with signal routing, network status management and other complicated functions [35]. Mangan S. et al. [36] presented a novel “sensorless” longitudinal road-gradient estimation method, which was developed in two steps starting from a benchmark system design. The gradient benchmark system consists of an inclinometer sensor and an acceleration-based error correction algorithm, which can be used to verify the accuracy of the road gradient obtained using a sensorless estimation method. The sensorless road-gradient estimation algorithm uses the vehicle data currently available on the vehicle CAN bus. Gugapriya G. et al. [37] aimed at a new anti-theft vehicle lock system. Here, with high speed reliable CAN, a sensor-based mechanism is interfaced with Engine Control Module (ECM) using ARM7 TDMI microcontroller. To prevent vehicle from theft fuel flow sensor observes ignition of engine and attached GSM sends an alert message to owner. Guo H. et al. [38] presented info-security scheme, real-time hardware/software solutions and their application scenarios. The core is the Integrated Info-Security Circuit Board to communicate with ECUs and sensors inside a vehicle through CAN Bus, LIN Bus, FlexRay and MOST Bus with wire interfaces, and to communicate with other vehicles, road-side infrastructure and mobile phones with wireless interfaces.

3. A Design of a Lightweight In-Vehicle Edge Gateway (LI-VEG) for the Self-Diagnosis of an Autonomous Vehicle

3.1. Overview This paper proposes a Lightweight In-Vehicle Edge Gateway (LI-VEG) for the self-diagnosis of an autonomous vehicle, which supports the communication among FlexRay, CAN, Ethernet, and MOST protocols. The LI-VEG enables mutual communication by translating the messages of the FlexRay, MOST, and CAN inside a vehicle into the message type of a destination protocol and translates the structure of an in-vehicle communication protocol into an Ethernet structure to support the mutual communication with the RSU outside a vehicle, and the connection with an Ethernet backbone. Because the paper on the self-diagnosis module has already been published [38], this paper only covers LI-VEG, not the self-diagnosis. Figure2 shows the structure of OBD-II including the LI-VEG which is a part for the self-diagnosis of an autonomous vehicle. Appl. Sci. 2018, 8, x FOR PEER REVIEW 6 of 19 Appl. Sci. 2018, 8, 1594 6 of 19 Appl. Sci. 2018, 8, x FOR PEER REVIEW 6 of 19

Figure 2. The structure of the LI-VEG. FigureFigure 2.2.The The structurestructure ofof thethe LI-VEG.LI-VEG. The LI-VEG working in OBD consists of three layers: InV-SRL, InV-ML and InV-DTL. First, the InV-SRL receives the messages from FlexRay, CAN, MOST, and Ethernet and then transfers the TheThe LI-VEGLI-VEG working in in OBD OBD consists consists of of three three layers: layers: InV InV-SRL,-SRL, InV InV-ML-ML and and InV InV-DTL.-DTL. First, First, the received messages into the Gateway. Second, the InV-ML manages the message transmission and theInV InV-SRL-SRL receives receives the the messages messages from from FlexRay, FlexRay, CAN, CAN, MOST, MOST, and and Ethernet Ethernet and then transfers transfers the the reception of FlexRay, CAN, MOST, and Ethernet and the Address Mapping Table. Third, the receivedreceived messagesmessages intointo thethe Gateway.Gateway. Second,Second, thethe InV-MLInV-ML managesmanages thethe messagemessage transmissiontransmission andand InV-DTL decomposes the messages of FlaxRay, CAN, MOST, and Ethernet and recomposes them to receptionreception of of FlexRay, FlexRay, CAN, CAN, MOST, MOST, and Ethernetand Ethernet and the and Address the Address Mapping Mapping Table. Third, Table. the Third, InV-DTL the the frame suitable for a destination. decomposesInV-DTL decomposes the messages the ofmessages FlaxRay, of CAN, FlaxRay, MOST, CAN, and MOST, Ethernet and and Ethernet recomposes and recomposes them to the them frame to suitablethe frame for suitable a destination. for a destination. 3.2. A Design of a Sending and Receiving Layer (InV-SRL) 3.2. A Design of a Sending and Receiving Layer (InV-SRL) 3.2. AThe Design InV- SRLof a Sendingacts as anand interface Receiving to Layer transmit (InV and-SRL) receive the messages between the InV-ML and hardwareThe InV-SRL devices acts (transceiver as an interface and controller). to transmit A and transceiver receive the is messages a hardware between device the that InV-ML transmits and The InV-SRL acts as an interface to transmit and receive the messages between the InV-ML and hardwareand receives devices the messages (transceiver of each and controller).protocol. A Acontroller transceiver used is afor hardware message deviceprocess thatingtransmits is embedded and hardware devices (transceiver and controller). A transceiver is a hardware device that transmits receivesin the MCU. the messages The controller of each stores protocol. the bus A controller serial bits used of messages for message in processingthe MCU. isMessages embedded received in the and receives the messages of each protocol. A controller used for message processing is embedded MCU.through The the controller transceiver stores and the the bus controller serial bits are of transmitted messages in to the the MCU. InV-ML Messages via the receivedInV-SRL. through the in the MCU. The controller stores the bus serial bits of messages in the MCU. Messages received transceiverIf the InV and-SRL the controller receives area message, transmitted the to received the InV-ML messag viae the is InV-SRL.transferred to the InV-ML. The through the transceiver and the controller are transmitted to the InV-ML via the InV-SRL. transferredIf the InV-SRL message receives is stored a in message, an Input the Message received Queue. message If the is transferred InV-SRL needs to the to InV-ML. transmit The the If the InV-SRL receives a message, the received message is transferred to the InV-ML. The transferredmessage to messagehardware is storeddevices, in anit receives Input Message the message Queue. stored If the InV-SRLin an Output needs toMessage transmit Queue the message of the transferred message is stored in an Input Message Queue. If the InV-SRL needs to transmit the toInV hardware-ML and devices,transmits it it receives to hardw theare message devices. stored Figure in an3 shows Output the Message block diagram Queue ofof the the InV-ML transceiver and message to hardware devices, it receives the message stored in an Output Message Queue of the transmitsand the controller. it to hardware devices. Figure3 shows the block diagram of the transceiver and the controller. InV-ML and transmits it to hardware devices. Figure 3 shows the block diagram of the transceiver and the controller.

Figure 3. The block diagram of the hardware devices. 3.3. A Design of an InV-ManagementFigure 3. LayerThe block (InV-ML) diagram of the hardware devices.

The InV-ML has two functions. First, the InV-ML receives messages from the InV-SRL and extracts only the necessary data, such as source, destination address, etc., from the received messages to makes the received messages lightweight. Only the extracted data are stored in an Address Mapping Table. It must rapidly be mapped to actual data in the Input Message Queue. Appl. Sci. 2018, 8, x FOR PEER REVIEW 7 of 19

3.3. A Design of an InV-Management Layer (InV-ML) The InV-ML has two functions. First, the InV-ML receives messages from the InV-SRL and extracts only the necessary data, such as source, destination address, etc., from the received Appl.messages Sci. 2018 to, 8 , makes 1594 the received messages lightweight. Only the extracted data are stored 7 in of an 19 Address Mapping Table. It must rapidly be mapped to actual data in the Input Message Queue. Second, if the extracted data are stored in the Address Mapping Table for mapping, the Second, if the extracted data are stored in the Address Mapping Table for mapping, the message message is stored in the Input Message Queue according to the priority of a message. The Input Messageis stored inQueue the Input consi Messagests of a Priority Queue accordingMulti-Queue to the and priority an Event of a Queue. message. There The Inputare two Message types of Queue data transferredconsists ofa from Priority sensors: Multi-Queue the real time and ansensing Event messages Queue. There processed are two in typesthe Priority of data Multi transferred-Queue from and thesensors: event the sensing real time messages sensing messages processed processed in the inEvent the Priority Queue. Multi-Queue The event and sensing the event messages sensing is transmittedmessages processed more rapidly in the than Event the Queue. real time The sensing event sensing messages. messages is transmitted more rapidly than the realThe time Priority sensing Multi messages.-Queue is used to decide a priority between protocols and between inner messagesThe Priority of a protocol. Multi-Queue The priority is used of to protocol decide a prevents priority between the collision protocols between and protoco betweenls. inner The prioritymessages of of messages a protocol. provides The priority emergent of protocol messages prevents with thehigher collision priority between and general protocols. messages The priority with higherof messages priority provides in proportion emergent to the messages time when with a message higher priority stays in and the Input general Message messages Queue. with higher priorityThe in Event proportion Queue to is the used time to when process a message Event sensing stays in messages the Input Messageand the messagesQueue. of the Event QueueThe have Event higher Queue priority is used than to process those of Event the sensingProtocol messages Priority andMulti the-Queue. messages The of Output the Event messages Queue ofhave InV higher-ML are priority processed than thosein the ofOutput the Protocol Message Priority Queue. Multi-Queue. The Output TheMessage Output Queue messages is similar of InV-ML to an Inputare processed Message in theQueue Output in terms Message of Queue. function. The Figure Output 4 Message shows that Queue the is LI similar-VEG tostores an Input the receivedMessage messagesQueue in termsin an Input of function. Massage Figure Queue4 shows and only that thethe LI-VEGnecessary stores data the from received the message messages in an in anAddress Input MappingMassage QueueTable. and only the necessary data from the message in an Address Mapping Table.

Figure 4. The flowchart ﬂowchart to process the received message.

Figure 55 showsshows thethe processprocess thatthat a a messagemessage whichwhich mustmust be be translatedtranslated inin thethe LI-VEGLI-VEG isis mademade lightweight and is stored in the Input Message Queue. The operational process isis asas follows.follows. 1. The LI-VEG receives the messages from the ECUs, Actuators, and media of a vehicle and stores 1. The LI-VEG receives the messages from the ECUs, Actuators, and media of a vehicle and stores them in the Input Message Queue. them in the Input Message Queue. 2. The LI-VEG extracts only the data necessary for message translation such as source and 2. The LI-VEG extracts only the data necessary for message translation such as source and destination address, and ID from a header for being lightweight. Because there is a cycle field destination address, and ID from a header for being lightweight. Because there is a cycle ﬁeld describing a data transmission cycle in the case of FlexRay, the Cycle field must be extracted. describing a data transmission cycle in the case of FlexRay, the Cycle ﬁeld must be extracted. 3. Lightweight data are stored in an Address Mapping Table for the rapid message translation. 3. Lightweight data are stored in an Address Mapping Table for the rapid message translation. 4. The message in the Input Message Queue is translated in InV-TL and the extracted header information of the Address Mapping Table helps to translate it rapidly. The translated message is stored in the Output Message Queue. 5. The message in the Output Message Queue is transmitted to a destination protocol bus. Appl. Sci. 2018, 8, x FOR PEER REVIEW 8 of 19

4. The message in the Input Message Queue is translated in InV-TL and the extracted header information of the Address Mapping Table helps to translate it rapidly. The translated message Appl. Sci.is stored2018, 8, in 1594 the Output Message Queue. 8 of 19 5. The message in the Output Message Queue is transmitted to a destination protocol bus.

FigureFigure 5.5.The The movementmovement ofof messagesmessages inin InV-ML.InV-ML.

TheThe FieldField NameName ofof TableTable1 1consists consists of of Cycle, Cycle, ID, ID, Priority, Priority, Source Source Protocol, Protocol, Source Source Bus Bus Number, Number, SourceSource Address, Address, Destination Destination Protocol, Protocol, Destination Destination Bus Bus Number, Number, and and Destination Destination Address. Address.

Table 1. The example of an Address Mapping Table. Table 1. The example of an Address Mapping Table. Field Name Ex1 (FlexRay) Ex2 (CAN) Ex3 (MOST) Ex4 (Ethernet) Field Name Ex1 (FlexRay) Ex2 (CAN) Ex3 (MOST) Ex4 (Ethernet) CycleCycle 44 00 11 2 2 IDID 1212 1515 57 57 22 22 PriorityPriority 00 33 22 4 4 Source Protocol 10 00 01 11 Source Protocol 10 00 01 11 Source Bus Number 1 2 2 0 Source Bus Number 1 2 2 0 Source Address 1002 0452 8847 4571 DestinationSource Protocol Address 001002 010452 8847 10 457100 DestinationDestination Bus Number Protocol 200 201 10 1 00 1 DestinationDestination Address Bus Number 05122 99602 11401 1 0324 Destination Address 0512 9960 1140 0324

The header information of a FlexRay message is extracted and each value of the extracted header The header information of a FlexRay message is extracted and each value of the extracted information is stored in the Ex1 column of Table1. header information is stored in the Ex1 column of Table 1. The Cycle field value in the header information of a FlexRay message is stored in the Cycle field The Cycle field value in the header information of a FlexRay message is stored in the Cycle in the EX1 of Table1 and the ID value in the header information of a FlexRay message is stored in the field in the EX1 of Table 1 and the ID value in the header information of a FlexRay message is ID field in the EX1 of Table1. The ID field value in the header information of a CAN message is stored stored in the ID field in the EX1 of Table 1. The ID field value in the header information of a CAN in the ID field in the EX2 of Table1. Because the header information of the CAN message has no a message is stored in the ID field in the EX2 of Table 1. Because the header information of the CAN Cycle field, it remains blank. message has no a Cycle field, it remains blank. Priority field value is stored in the Priority field in the EX1 of Table1. Because the FlexRay uses Priority field value is stored in the Priority field in the EX1 of Table 1. Because the FlexRay uses a timer, not priority, the priority field value is not needed. In the case InV-ML receives a FlexRay a timer, not priority, the priority field value is not needed. In the case InV-ML receives a FlexRay message, 0 value is stored in the Priority field. The Priority value of the CAN message frame is stored message, 0 value is stored in the Priority field. The Priority value of the CAN message frame is in the Priority field in the EX2 of Table1. stored in the Priority field in the EX2 of Table 1. The Source Protocol field is 2 bits and has a source protocol number in it. If the Source Protocol field value is 00, it means a CAN protocol. If it is 01, it means a MOST protocol. If it is 10, it means a FlexRay protocol. If it is 11, it means an Ethernet protocol. The source protocol bus number which sent a message is stored in the Source Bus Number field. Because the Source Protocol field value is 10 and Source Bus Number field value is 1 in the EX1 of Appl. Sci. 2018, 8, x FOR PEER REVIEW 9 of 19

The Source Protocol field is 2 bits and has a source protocol number in it. If the Source Protocol field value is 00, it means a CAN protocol. If it is 01, it means a MOST protocol. If it is 10, it means a FlexRay protocol. If it is 11, it means an Ethernet protocol. The source protocol bus number which sent a message is stored in the Source Bus Number Appl. Sci. 2018, 8, 1594 9 of 19 field. Because the Source Protocol field value is 10 and Source Bus Number field value is 1 in the EX1 of Table 1, it means that a message was received from the Bus 1 using a FlexRay protocol. TableBecause1, it meansthe Source that aProtocol message field was value received is 00 from and the Source Bus 1 using Bus Number a FlexRay field protocol. value is Because 2 in the the EX2 Sourceof Table Protocol 1, it means field that value a ismessag 00 ande was the Sourcereceived Bus from Number the Bus field 2 using value a isCAN 2 in protocol. the EX2of Table1, it meansThe that source a message address was of received the received from themessage Bus 2 is using stored a CAN in the protocol. Source Address field. TheThe source Destination address Protocol of the received field is message2 bits large is stored and has in thea destination Source Address protocol field. number in it. The destinationThe Destination protocol Protocolbus number field is is stored 2 bits in large the Destination and has a destination Bus Number protocol field. number in it. The destinationThe destination protocol bus address number of isthe stored received in the message Destination is stored Bus Numberin a Destination field. Address field. If the headerThe information destination addressis stored of in the the received Address message Mapping is Table, stored the in aInV Destination-ML transfers Address the stored field. header If the headerinformat informationion and the is stored original in the message Address of the Mapping Input Table, Message the Queue InV-ML to transfers the InV the-DTL stored according header to informationpriority. and the original message of the Input Message Queue to the InV-DTL according to priority. TheThe stepwise stepwise process process is is shown shown in in Figure Figure6. 6. 1. Before the Input Message Queue transfers messages to the InV-DTL, it searches for the tuple of 1. Before the Input Message Queue transfers messages to the InV-DTL, it searches for the tuple of the Address Mapping Table with the same the sending message ID as Address Mapping Table the Address Mapping Table with the same the sending message ID as Address Mapping Table ID. ID. 2. The message which must be translated and the tuple of the Address Mapping Table are transferred 2. The message which must be translated and the tuple of the Address Mapping Table are totransferred the InV-DTL. to the InV-DTL. 3.3. TheThe InV-DTL InV-DTL translates translates messages, messages, compares compares the destination the destination and source and address source of addr the translatedess of the messagetranslated to thosemessage of the to Address those of Mapping the Address Table. Mapping If they are Table. all the If same, they the are InV-DTL all the transfers same, the theInV message-DTL transfers to the InV-ML.the message to the InV-ML. 4.4. TheThe InV-MLInV-ML setssets thethe pathspaths of of the the translated translated messages, messages, and and delivers delivers the the messages messages to to the the Output Output MessageMessage QueueQueue andand transferstransfers thethe messagemessageof of the the Output Output Message Message Queue Queue to to the the SRL SRL according according thethe paths.paths.

FigureFigure 6. 6.Message Message Delivery Delivery Scenario. Scenario. 3.4. A Design of the InV-DTL

The InV-DTL translates the messages received from the Input Massage Queue by using the Translation Table and transfers the translated messages to the Output Massage Queue of the InV-ML. The InV-DTL works as follows. 1. The InV-DTL receives the original message of the Input Massage Queue and the header information of the Address Mapping Table and generates the values of the Translation Table ﬁeld by using the header information. Appl. Sci. 2018, 8, x FOR PEER REVIEW 10 of 19

3.4. A Design of the InV-DTL The InV-DTL translates the messages received from the Input Massage Queue by using the Translation Table and transfers the translated messages to the Output Massage Queue of the InV-ML.

Appl. Sci.The2018 InV, 8-,DTL 1594 works as follows. 10 of 19 1. The InV-DTL receives the original message of the Input Massage Queue and the header information of the Address Mapping Table and generates the values of the Translation Table 2. fieldThe by InV-DTL using the decomposes header information. the header and trailer from the message. 3.2. TheThe InV InV-DTL-DTL decomposes translates the the decomposed header and messagestrailer from based the message. on the Translation Table. 4.3. TheThe InV InV-DTL-DTL translates gives them the sequential decomposed numbers messages from thebased Translation on the Translation Table if the Table. translated messages 4. Theare divided. InV-DTL gives them sequential numbers from the Translation Table if the translated 5. messagesThe translated are divided. messages are transferred to the Output Massage Queue of InV-ML. 6.5. TheEvery translated protocol messages is different are transferred in the attributes to the Output of the TranslationMassage Queue Table of fields. InV-ML. The Translation 6. EveryTables protocol such as “FlexRay is different to CAN” in the Table, attributes “CAN of to the FlexRay” Translation Table, Table “MOST fields. to CAN” The Translation Table, and Tables“Ethernet such to as MOST” “FlexRay Table to CAN” are generated Table, “CAN and theto FlexRay” Translation Table, Table “MOST field values to CAN” are Table, generated and “Ethernetagain whenever to MOST” messages Table areare translated.generated and the Translation Table field values are generated again whenever messages are translated. Figure 77 shows shows thethe “MOST“MOST toto CAN”CAN” TranslationTranslation TableTable translating translating MOST MOST messagesmessages intointo CANCAN messages. The The “MOST “MOST to to CAN” CAN” Translation Translation Table Table consists consists of the of number the number of divided of divided messages, messages, Current MessageCurrent Message Number, Number, Source Address, Source Source Address, Protocol Source Bus Protocol Number, Bus Destination Number, DestinationAddress, Destination Address, ProtocolDestination Bus Protocol Number, Bus the Number, CAN priority, the CAN and thepriority, CAN and IDs. the The CAN CAN IDs. ID is The used CAN to enter ID is the used CAN to Busenter by the Event. CAN Tel Bus ID by and Event. Tel LenTel fieldID and are Tel translated Len field into are Servicetranslated type into ID Service of the CAN type messageID of the by CAN the CANmessage ID valueby the of CAN the TranslationID value of Table. the Translation The message Table. numbers The message are given numbers to every are divided given messageto every sequentially.divided messag Destinatione sequentially. Address Destination of the MOST Address message of is translated the MOST the message Destination is translated node ID of the CANDestination message node by Destination ID of the CAN Address message and Destination by Destination Protocol Address Bus Number and Destination in the Translation Protocol Table. Bus TheNumber Source in Addressthe Translation of the MOSTTable. isThe translated Source Address to the Source of the node MOST ID is of translated the CAN messageto the Source by Source node AddressID of the and CAN Source message Protocol by Source Bus Number Address in theand Translation Source Protocol Table. Bus The Number Request in not the response Translation field valueTable. of The the RequestCAN message not response is always field fixed value as 1, and of the the CAN Service message not message is always field of fixed the CAN as 1, message and the isService always not fixed message as 0. Thefield CAN of the Priority CAN message field value is always of the Translationfixed as 0. The Table CAN is generated Priority field by using value the of Addressthe Translation Mapping Table Table. is It generated is used to bymap using thePriority the Address field value Mapping of CAN Table. message. It is Theused fields to map such the as Fblock,Priority Inst, field Fkt value ID and of OP CAN Type message. are functional The fields blocks such of the as MOST Fblock, message. Inst, Fkt They ID andare not OP used Type in arethe CAN.functional The Synchronousblocks of the dataMOST and message. the Asynchronous They are not data used are in translated the CAN. to The the Synchronous Data field value data of and the CANthe Asynchronous message. data are translated to the Data field value of the CAN message.

FigureFigure 7. 7. TheThe Translation Translation of MOST into CAN message by the Translation Table.

Figure8 shows the “CAN to FlexRay” Translation Table translating CAN messages into FlexRay messages. Because the FlexRay is a protocol based on Timing, a Cycle ﬁeld is used and a Priority and an ID ﬁeld are not used when messages are translated. The translated messages enter a destination FlexRay Bus by using a Cycle value. Service type ID of the CAN message is translated into Frame ID of FlexRay message by FlexRay ID of the Translation Table. Message Cycle of the Translation Table is Appl. Sci. 2018, 8, x FOR PEER REVIEW 11 of 19 Appl. Sci. 2018, 8, x FOR PEER REVIEW 11 of 19

FigureFigure 8 8 shows shows the the “CAN “CAN to to FlexRay” FlexRay” Tran Translationslation Table Table translating translating CAN CAN messages messages into into FlexRayFlexRay messages.messages. BecauseBecause thethe FlexRayFlexRay isis aa protocolprotocol basedbased onon Timing,Timing, aa CycleCycle fieldfield isis usedused andand aa PriorityPriority andand anan IDID fieldfield areare notnot usedused whenwhen messagesmessages areare translated.translated. TheThe translatedtranslated messagesmessages enterenter aa Appl. Sci. 2018, 8, 1594 11 of 19 destinationdestination FleFlexRayxRay BusBus byby usingusing aa CycleCycle value.value. ServiceService typetype IDID ofof thethe CANCAN messagemessage isis translatedtranslated intointo FrameFrame ID ID of of FlexRay FlexRay message message by by FlexRay FlexRay ID ID of of the the Translation Translation Table. Table. Mess Messageage Cycle Cycle ofof the the Translation Table is generated based on the Address Mapping Table, and is used to decide Cycle generatedTranslation based Table on is the generated Address Mappingbased on Table,the Address and is used Mapping to decide Table, Cycle and count is used of FlexRay to decide message. Cycle Becausecountcount ofof the FlexRayFlexRay State bit,message.message. the Payload BecauseBecause Length, thethe StateState the bit, Headerbit, thethe PayloadPayload CRC and Length,Length, the CRC thethe are HeaderHeader not included CRCCRC andand in the thethe CAN CRCCRC are not included in the CAN message, they are generated by InV-DTL. message,are not included they are in generated the CAN bymessage, InV-DTL. they are generated by InV-DTL.

Figure 8. The Translation of a CAN into a FlexRay message by Translation Table. Figure 8. The Translation ofof aa CANCAN intointo a FlexRayFlexRay messagemessage byby TranslationTranslation Table.Table.

Figure9 shows the “MOST to Ethernet” Translation Table translating the MOST messages into FigureFigure 99 showsshows thethe “MOST“MOST toto Ethernet”Ethernet” TranslationTranslation TableTable translatingtranslating thethe MOSTMOST messagesmessages intointo thethethe EthernetEthernetEthernet messages.messages.messages. Because BecauseBecause the thethe Ethernet EthernetEthernet is isis used usedused as asas a Backboneaa BackboneBackbone with withwith high highhigh capacity, capacity,capacity, an an attributean attributeattribute on Bus number is not generated in the Translation Table. Therefore, the Translation speed is the highest onon Bus Bus number number is is not not generated generated in in the the TranslationTranslation Table Table.. Therefore, Therefore, the the Translation Translation speed speed is is the the whenhighesthighest the whenwhen MOST thethe messages MOSTMOST messagesmessages are translated areare translatedtranslated into the Ethernet intointo thethe messages. EthernetEthernet Destination messages.messages. DestinationDestination Address value AddressAddress of the MOSTvaluevalue ofof message thethe MOSTMOST is translated messagemessage isis Destination translatedtranslated AddressDestinationDestination value AddressAddress of the value Ethernetvalue ofof thethe message EthernetEthernet by message themessage Translation byby thethe Table.TranslationTranslation Source Table Table Address.. Sour Sour ofcece the Address Address MOST message of of the the is MOST MOST translated message message Source is is Address translated translated of the Source Source Ethernet Address Address message of of the the by theEthernetEthernet Translation messagemessage Table. byby the Thethe TranslationTranslation Tel Len value TableTable is translated.. TheThe TelTel toLenLen the valuevalue Length isis translatedtranslated value of the toto Ethernet thethe LengthLength message valuevalue byofof thethethe TranslationEthernetEthernet messagemessage Table. Thebyby thethe Synchronous TranslationTranslation data TableTable and.. TheThe the SynchronousSynchronous Asynchronous datadata data andand are thethe translated AsynchronousAsynchronous to the Data dadatata fieldareare translated translated value of the to to Ethernet the the Data Data message. field field value value The Preamble, of of the the Ethernet Ethernet the SFD message. message. and the Padding The The Preamble, Preamble, field values the the areSFD SFD generated and and the the byPaddingPadding InV-DTL fieldfield and valuesvalues FCS are fieldare generatedgenerated must be made byby InVInV by--DTLDTL CRC andand method. FCSFCS fieldfield mustmust bebe mademade byby CRCCRC method.method.

Figure 9. The Transformation of MOST into Ethernet messagemessage byby Mapping.Mapping. Figure 9. The Transformation of MOST into Ethernet message by Mapping. If the message translation is completed, the translated message is stored in the Output Message If the message translation is completed, the translated message is stored in the Output Message QueueIf ofthe the message InV-ML. translation If the message is completed, arrived atthe the translated Output Message messageQueue is stored normally, in the Output it is transferred Message Queue of the InV-ML. If the message arrived at the Output Message Queue normally, it is toQueue the destination of the InV protocol-ML. If bus the to message which the arrived message at belongs the Output according Message to priority Queue or normally, cycle. Because it is transferred to the destination protocol bus to which the message belongs according to priority or thetransferre FlexRayd protocolto the destination uses a Bus protocol based on bus Timing, to which it transfers the message the translated belongs messages according to to a destinationpriority or cycle. Because the FlexRay protocol uses a Bus based on Timing, it transfers the translated messages protocolcycle. Because bus by the using FlexRay Cycle protocol ﬁeld of auses header. a Bus The based transmission on Timing, of it messages transfers is the done translated in the InV-SRL. messages to a destination protocol bus by using Cycle field of a header. The transmission of messages is done to a destinationThis method protocol enables bus the by smooth using communicationCycle field of a header. of MOST, The FlexRay transmission and CAN, of messages and, if is MOST, done in the InV-SRL. FlexRayin the InV and-SRL. CAN messages are translated in Ethernet messages, the Ethernet messages are translated in WAVE signals to be able to communicate with RSU using an in-vehicle WAVE-to-Ethernet module. Appl. Sci. 2018, 8, x FOR PEER REVIEW 12 of 19

This method enables the smooth communication of MOST, FlexRay and CAN, and, if MOST, FlexRay and CAN messages are translated in Ethernet messages, the Ethernet messages are translatedAppl. Sci. 2018 , in8, 1594 WAVE signals to be able to communicate with RSU using an in-vehicle12 of 19 WAVE-to-Ethernet module.

4. The The Performance Analysis The model shown in Figure 10 uses one gateway connected to two CAN buses, two FlexRay buses, two MOST buses and one Ethernet backbone to verify the LI LI-VEG-VEG performance proposed in this paper and each bus has four nodes.

Figure 10. The simulation Model.

ThThee Main Main Processor Processor of of the the LI-VEG LI-VEG uses uses ARM ARM Cortex-A7 Cortex-A7 (900 (900 Mhz) Mhz) and andis simulated is simulated in the in RAM the RAMwith these with twothese experiments two experiments in PC. in PC. In the first ﬁrst simulation environment,environment, the transmission delay caused by message translation was measured while while messages messages are are transferred transferred between between four protocols four protocols (CAN, (CAN,MOST, FlexRay MOST, and FlexRay Ethernet). and Ethernet).The transmission The transmission delay was delay measured was measured based on based the eight on the Message eight Messagetransmissions transmissions from CAN from to CANFlexRay, to FlexRay, the eight Messagethe eight transmissions Message transmissions from CAN tofrom Ethernet, CAN to and Ethernet, the eight and Message the eight transmissions Message transmissionsfrom CAN to MOST. from CAN The transmission to MOST. The cycle transmission of each message cycle uses of each 14 ms. message The transmission uses 14 ms. delay The transmissionbetween the existing delay between message mapping the existing translation message system mapping not using translation a lightweight system header not using and the a lightweightmessage translation header and system the usingmessage a lightweight translation header system was using compared. a lightweight Table 2header shows was the simulationcompared. Tableenvironment 2 shows of the the simulation ﬁrst simulation. environment of the first simulation.

Table 2. The Simulation Environment.

SourceSource Protocol Protocol CANCAN CAN CAN CAN CAN destinationdestination protocol protocol FlexRayFlexRay MOST MOST Ethernet Ethernet the numberthe number of message of message transmissions transmissions 88 8 88 8 transmissiontransmission cycle cycle 1414 ms ms 14 14 ms ms 14 ms 14 ms

In the the second second simulation simulation environment, environment, the transmission the transmission delay caused delay causedby overhead by overhead was measured. was measured.The overhead The happensoverhead inhappens each protocol in each protocol bus because bus because of the continuousof the continuous signal signal from thefrom CAN. the CAN.Transmission Transmission delay between delay between the existing the existing message message translation translation system and system the proposedand the propo messagesed messagetranslation translation system was system compared was compared according according as network as trafﬁcnetwork increases. traffic increases. In the same In way the same as the way ﬁrst asexperiment, the first experiment,transmission transmission delay was measured delay was in the measured case the in CAN the messages case the areCAN translated messages to arethe translatedother three to protocols. the other three protocols. Figure 11a11a–c–c shows maximumaximumm transmission delay and its stabilization time when the CAN messages are transferred to the other protocols. The transmission delay delay means means the the time that it takes for a source message to be translated into a destination message in the LI LI-VEG.-VEG. The stabilizationstabilization time means the the time time between between when when translation translation overhead overhead occurs occurs and and when when its its overhead overhead disappears. disappears. Figure 11a11a shows the transmission delay and stabilization time when messages messages are are transferred from the CAN busbus toto thethe FlexRayFlexRay bus. bus. In In the the transmission, transmission, it it takes takes maximum maximum 278 278µs μs transmission transmission delay delay for forthe the existing existing method method to store to store and and translate translate a message a message and aboutand about 8 ms 8 to ms stabilize to stabilize the transmission the transmission delay. delay.It takes It atakes maximum a maximum of 274 ofµs 274 for theμs for proposed the proposed method method to store to and store transform and transform a message a message and about and about6 ms to 6 stabilize ms to stabil the transmissionize the transmission delay. Therefore, delay. Therefore, the maximum the transmission maximum transmission delay is improved delay by is improvedabout 2% andby about its stabilization 2% and its timestabilization about 25%. time about 25%. Appl. Sci. 2018, 8, x FOR PEER REVIEW 13 of 19

Figure 11b shows the transmission delay and stabilization time when messages are transferred from CAN bus to MOST bus. In the transmission, it takes maximum 3.03 ms transmission delay for the existing method to store and transform a message and 11 ms to stabilize the transmission delay. It takes a maximum of 2.84 ms for the proposed method to store and transform a message and 11 Appl.ms to Sci. stabilize2018, 8, 1594 the transmission delay. Therefore, the maximum transmission delay is improved13 of 19by about 7% and its stabilization time is the same.

(a)

(b)

(c)

FigureFigure 11. 11.The The transmission transmission delay delay and the and Stabilization the Stabilization Time when Time The when CAN The messages CAN are messages translated. are (atranslated.) From CAN (a) toFrom FlexRay, CAN (bto) FlexRay From CAN, (b) to From MOST, CAN (c) to From MOST CAN, (c) to From Ethernet. CAN to Ethernet.

FigureFigure 11 11cb showsshows thethe transmissiontransmission delaydelay andand stabilizationstabilization timetime whenwhen messagesmessages areare transferredtransferred fromfrom CAN CAN bus bus to to MOST Ethernet bus. bus. In theIn the transmission, transmission, it takes it takes maximum maximum 3.03 1.47 ms transmissionms transmission delay delay for thefor existingthe existing method method to store to store and transformand translate a message a message and and 11 ms 9 ms to stabilizeto stabilize the the transmission transmission delay. delay. It takesIt takes a maximum a maximum of 2.84of 1.29 ms ms for for the the proposed proposed method method to store to store and and transform transform a message a message and and 11 ms 7 ms to stabilizeto stabilize the transmission the transmission delay. delay. Therefore, Therefore, the maximum the maximum transmission transmission delay is improved delay is improved by about 7% by andabout its 11% stabilization and its stabilization time is the same. time about 20%. FigureTable 11 3 c shows shows how the transmission much the proposed delay and method stabilization is improved time when in comparison messages are to transferredthe existing frommethod. CAN Overall, bus to Ethernet the transmission bus. In the delay transmission, time about it takes message maximum transl 1.47ation ms and transmission transmission delay is forreduced the existing by an methodaverage toof store 10.83%. and That translate is, if athe message lightweight and 9 method ms to stabilize is used, the transmission transmission delay delay. is Itreduced takes a maximumand data processing of 1.29 ms is for improved. the proposed method to store and transform a message and 7 ms to stabilize the transmission delay. Therefore, the maximum transmission delay is improved by about 11% and its stabilization time about 20%. Table3 shows how much the proposed method is improved in comparison to the existing method. Overall, the transmission delay time about message translation and transmission is reduced by an Appl. Sci. 2018, 8, 1594 14 of 19

Appl.average Sci. 2018 of 10.83%., 8, x FOR ThatPEER is,REVIEW if the lightweight method is used, transmission delay is reduced and14 dataof 19 processing is improved. Table 3. The improvement rate of the proposed method. Table 3. The improvement rate of the proposed method. The Improvement Rate of The Improvement Rate of Direction Direction The ImprovementTransmission Rate of Transmission Delay Delay The ImprovementStabilization Rate of Time Stabilization Time FromFrom CAN CAN to FlexRay to FlexRay 2%2% 25% 25% FromFrom CAN CAN to MOST to MOST 7%7% 0% 0% From CAN to Etherney 11% 20% From CAN to Etherney 11% 20%

Figure 12 shows the average transmission delay by overhead happening when continuous messages are transferred from a CAN busbus to a destination protocol.protocol.

(a) (b)

(c)

Figure 12. TheThe transmission transmission delay delay as as traffic trafﬁc is isincreased. increased. (a) (CANa) CAN to FlexRay to FlexRay,, (b) (CANb) CAN to MOST to MOST,, (c) (CANc) CAN to Ethernet to Ethernet..

WWhenhen messages are transferred from the CAN to the FlexRay, Figure 12 12aa shows an average transmission delay delay according according to to network traffic traffic increase. In In the the case case the the network network traffic traffic is 25%, the transmission delay delay of of the existing method method was was measured measured as as about about 275 275 μsµs and that of the proposed method was was measured measured as as about about 250 250µs. μs. In the In case the case the network the netwo trafficrk traffic is 85%, is the 85%, transmission the transmission delay of delaythe existing of the methodexisting wasmethod measured was measured as about 656as aboutµs and 656 that μs ofand the that proposed of the methodproposed was method measured was measuredas about 670 as aboutµs. Therefore, 670 μs. Therefore, when traffic when increase traffic is increase low, the is proposed low, the proposed method is method faster by is aboutfaster 9%by aboutthan the 9% existingthan the method. existing However,method. However, when traffic when increase traffic isincrease high, thereis high, is nothere difference is no difference between betweenthe methods. the methods. When messages are transferred from the CAN to the MOST, Figure 12 12bb shows an average transmission delay delay according to to network traffic traffic increase. In In thecase thecase the the networ networkk traffic traffic is 25%, the transmission delay delay of of the existing method method was was measured measured as as about about 2 2 ms ms and that of the proposed method was was measured measured as as about about 2.5 2.5 ms. ms. In the In case the case the network the network traffic traffic is 85%, is the 85%, transmission the transmission delay of delaythe existing of the methodexisting wasmethod measured was measured as about 7.9as a msbout and 7.9 that ms ofand the that proposed of the methodproposed was method measured was measuredas about 8.1 as ms.about Therefore, 8.1 ms. Therefore, when traffic when increase traffic is increase low, the is proposed low, the methodproposed is fastermethod by is about faster 20% by about 20% than the existing method. However, when traffic increase is high, there is no difference between the methods. When messages are transferred from the CAN to the Ethernet, Figure 12c shows an average transmission delay according to network traffic increase. In the case the network traffic is 25%, the Appl. Sci. 2018, 8, 1594 15 of 19 than the existing method. However, when traffic increase is high, there is no difference between the methods. When messages are transferred from the CAN to the Ethernet, Figure 12c shows an average Appl. Sci. 2018, 8, x FOR PEER REVIEW 15 of 19 transmission delay according to network traffic increase. In the case the network traffic is 25%, the transmission delay of the existing method was measured as about 0.9 ms and that of the proposed method was was measured measured as as about about 0.7 0.7 ms. ms. In the In case the casethe network the network traffic trafficis 85%, is the 85%, transmission the transmission delay of thedelay existing of the methodexisting wasmethod measured was measured as about 2.26as about ms and 2.26 that ms of and the that proposed of the methodproposed was method measured was asmeasured about 2.24 as ms.about Therefore, 2.24 ms. whenTherefore, traffic when increase traffic is low, increase the proposed is low, the method proposed is faster method by about is faster 20% thanby about the existing 20% than method. the existing However, method. when However, traffic increase when is traffic high, there increase is almost is high, no differencethere is almost between no thedifference methods. between the methods. In brief, the transmission delay of of the the proposed proposed meth methodod is is lower lower as as traffic traffic value value gets gets smaller. smaller. There isis almostalmost nono difference difference between between the the two two methods methods as as traffic traffic value value gets gets larger, larger, which which it means it means that thethat two the methodstwo methods have have the same the same transmission transmission delay delay characteristic. characteristic. When messages messages are are sent sent and and received received between between a CAN a CAN bus andbus a and FlexRay a FlexRay bus, Figure bus, Figure13a shows 13a theshows error the rate error according rate according to the number to the number of messages. of messages. The error The rate error was rate measured was measured as follows. as follows.

(a) (b)

(c)

Figure 13. The error rate according to message quantity. (a)) The error rate between the CAN and the FlexRay,FlexRay, ((bb)) TheThe error error rate rate between between the the CAN CAN and and the the MOST, MOST (c,) The(c) The error error rate rate between between the CANthe CAN and theand Ethernet. the Ethernet.

First,First, the error error rate rate was was measured measured when when the the CAN CAN messages messages are are transferred transferred to toa FlexRay a FlexRay bus. bus. In Inthe the case case 50 50messages messages were were transferred, transferred, the the proposed proposed method method showed showed an an error error rate rate of of 0% 0% and the existing method of of 2%. 2%. In In the the case case 100 100 messages messages were were transferred, transferred, the the proposed proposed method method showed showed an anerror error rate rate of of 1% 1% and and the the existing existing method method of of 2%. 2%. In In the the case case 340 340 messages messages were transferred, the proposed methodmethod showed showed an an error erro rater rate of of 0.88% 0.88% and and the the existing existing method method of 1.47%. of 1.47%. Therefore, Therefore, the error the rateerror of rate the of proposed the proposed method method is lower is lower by about by about 1.3% compared1.3% compared to that to of that the existingof the existing method method as the numberas the number of messages of messages gets larger. gets larger. The average The average error rate error of rate the proposedof the proposed method method is 0.91% is and0.91% that and of thethat existing of the existing method method is 1.55%. is 1.55%. Second, the error rate was measured when the FlexRay messages are translated into a CAN bus. In the case 50 messages were transferred, the proposed method showed an error rate of 1% and the existing method of 1.2%. In the case 100 messages were transferred, the proposed method showed an error rate of 1.8% and the existing method of 1.9%. In the case 340 messages were transferred, the proposed method showed an error rate of 1.5% and the existing method of 2.09%. Therefore, the error rate of the proposed method is lower by about 0.5% compared to that of the existing method as the number of messages gets larger. The average error rate of the proposed Appl. Sci. 2018, 8, 1594 16 of 19

Second, the error rate was measured when the FlexRay messages are translated into a CAN bus. In the case 50 messages were transferred, the proposed method showed an error rate of 1% and the existing method of 1.2%. In the case 100 messages were transferred, the proposed method showed an error rate of 1.8% and the existing method of 1.9%. In the case 340 messages were transferred, the proposed method showed an error rate of 1.5% and the existing method of 2.09%. Therefore, the error rate of the proposed method is lower by about 0.5% compared to that of the existing method as the number of messages gets larger. The average error rate of the proposed method is 1.59% and that of the existing method is 1.94%. Here, because one FlexRay message was divided into several CAN messages, the average error rate of the second gets higher by about 0.5% compared to that of the first. When messages are sent and received between a CAN bus and a MOST bus, Figure 13b shows the error rate according to the number of messages. The error rate was measured as follows. First, the error rate was measured when the CAN messages are transferred to a MOST bus. In the case 50 messages were transferred, the proposed method showed an error rate of 0% and the existing method 2%. In the case 100 messages were transferred, the proposed method showed an error rate of 1% and the existing method of 1%. In the case 340 messages were transferred, the proposed method showed an error rate of 0.59% and the existing method of 0.88%. Therefore, the error rate of the proposed method is lower by about 0.3% compared to that of the existing method as the number of messages gets larger. The average error rate of the proposed method is 0.45% and that of the existing method is 1.16%. Second, the error rate was measured when the MOST messages are transferred to a CAN bus. In the case 50 messages were transferred, the proposed method showed an error rate of 3% and the existing method of 3.2%. In the case 100 messages were transferred, the proposed method showed an error rate of 2.7% and the existing method of 2.6%. In the case 340 messages were transferred, the proposed method showed an error rate of 2.06% and the existing method of 2.15%. Therefore, the error rate of the proposed method is lower by about 0.1% compared to that of the existing method as the number of messages gets larger. The average error rate of the proposed method is 2.53% and that of the existing method is 2.59%. Here, because one MOST message is divided into several CAN messages, the average error rate of the second gets higher by about 2% compared to that of the first. When messages are sent and received between a CAN bus and an Ethernet bus, Figure 13c shows the error rate according to the number of messages. The error rate was measured as follows. First, the error rate was measured when the CAN messages are transferred to an Ethernet backbone. In the case 50 messages were transferred, the proposed method showed an error rate of 0% and the existing method of 0%. In the case 100 messages were transferred, the proposed method showed an error rate of 0% and the existing method of 0.4%. In the case 340 messages were transferred, the proposed method showed an error rate of 0.41% and the existing method of 0.74%. Therefore, the error rate of the proposed method is lower by about 0.5% compared to that of the existing method as the number of messages gets larger. The average error rate of the proposed method is 0.35% and that of the existing method is 0.55%. Second, the error rate is measured when the Ethernet messages are transferred to a CAN bus. In the case 50 messages were transferred, the proposed method showed an error rate of 0.4% and the existing method of 0.5%. In the case 100 messages were transferred, the proposed method showed an error rate of 0.7% and the existing method of 0.6%. In the case 340 messages were transferred, the proposed method showed an error rate of 1.03% and the existing method of 1.03%. Therefore, the average error rate of the proposed method is 0.81% and that of the existing method is 0.84%. The proposed method is lower than the existing method by about 0.03%. Here, the average error rate of the second gets higher by about 0.5% compared to that of the first. Overall, this experiment says that the error rate of the proposed method is lower compared to that of the existing method. According to the three experiments above, the LI-VEG proposed in this paper has the following advantages: Appl. Sci. 2018, 8, 1594 17 of 19

• When messages are transferred to the other protocol, the LI-VEG has lower transmission delay than the existing protocols. • When network trafﬁc becomes lower, the LI-VEG has a lower transmission delay than the existing protocols. However, when network trafﬁc becomes higher, the LI-VEG has almost the same transmission delay as the existing protocols. • When messages are transferred between protocols, the LI_VEG has a lower error rate than the existing protocols.

5. Conclusions This paper proposes the LI-VEG for smooth communication between in-vehicle protocols and presents results from three experiments. The results are as follows. The LI-VEG reduces the transmission delay time by an average of 10.83% and the error rate by 0.8% for message translation and transmission, compared to the existing in-vehicle gateways. When network trafﬁc becomes lower, the LI-VEG reduces the transmission delay by about 16.3%. Therefore, the LI-VEG has a lower error rate and a lower transmission delay than the existing method when a message is translated and transferred. According to the experiment, the LI-VEG has the following characteristics. First, the header is much lighter because only the necessary information for transformation is extracted from the header information of a message. Second, because the Input Queue and Output Queue managing messages are classiﬁed into a Priority Multi-Queue and an Event Queue, the LI-VEG translates emergent messages more rapidly than the existing FIFO. Third, the LI-VEG supports communication among all primary protocols used inside a current vehicle. The LI-VEG must be tested on real vehicles. If the real experiment on the vehicle is almost the same as the simulation result, the LI-VEG could be applied to the gateway of future autonomous vehicles.

Author Contributions: B.L. proposed the idea. Y.J., S.S. and E.J. made the paper based on the idea and carried out the experiments in Korean Language. B.L. guided and supervised the research and translated the paper into English. All authors read and approved the final manuscript. Funding: This work was supported by the National Research Foundation of Korea (NRF) grant funded by the Korea government (MSIT) (No. NRF-2018R1A2B6007710). Conflicts of Interest: The authors declare no conflict of interest.

References

1. Gateway Solutions Iot Brief. Available online: https://www.intel.com/content/dam/www/public/us/en/ documents/product-briefs/gateway-solutions-iot-brief.pdf (accessed on 17 May 2018). 2. Leen, G.; Hefferman, D.; Dunne, A. Digital Networks in the automotive vehicle. IEEE Comput. Control Eng. J. 1999, 10, 257–266. [CrossRef] 3. Jeong, Y.; Sonm, S.; Jeong, E.; Lee, B. An Integrated Self-Diagnosis System for an Autonomous Vehicle Based on an IoT Gateway and Deep Learning. Appl. Sci. 2018, 8, 1164. [CrossRef] 4. Lin, C.E.; Shiao, Y.-S.; Li, C.C.; Yang, S.H.; Lin, S.H.; Lin, C.Y. Real-Time Remote Onboard Diagnostics Using Embedded GPRS Surveillance Technology. IEEE Trans Veh. Technol. 2007, 56, 1108–1118. [CrossRef] 5. Zou, X.D.; Wang, F.Y.; Qiu, R. The Development of the on Board Diagnostics System on the Keyword Protocol. Appl. Mech. Mater. 2010, 43, 752–755. 6. Ochs, T.; Schittenhelm, H.; Genssle, A.; Kamp, B. Particulate Matter Sensor for On Board Diagnostics (OBD) of Diesel Particulate Filters (DPF). SAE Int. J. Fuels Lubr. 2010, 3, 61–69. [CrossRef] 7. Kamimoto, T. A review of soot sensors considered for on-board diagnostics application. Int. J. Eng. Res. 2017, 18, 5–6. [CrossRef] 8. Necker, T.; Garnatz, O. On-board Diagnostics Meets AUTOSAR. ATZextra Worldw. 2013, 18, 37. [CrossRef] 9. Chen, C.L.; Hsu, C.W. Enhancement of Ev On-Board Diagnostics System into Preliminary Operation Using Estimation Theory. Appl. Mech. Mater. 2013, 391, 592–595. [CrossRef] Appl. Sci. 2018, 8, 1594 18 of 19

10. Sujit, H.; Ramachandra, K.; Reddy, N.; Vivek, R.V.; Karanth, S.; Kamath, T. A novel dynamic traffic management system using on board diagnostics and Zigbee protocol. In Proceedings of the 2016 International Conference on Communication and Electronics Systems (ICCES), Coimbatore, India, 21–22 October 2016. 11. Kulkarni, P.; Rajani, P.K.; Varma, K. Development of On Board Diagnostics (OBD) testing tool to scan emission control system. In Proceedings of the 2016 International Conference on Computing Communication Control and automation (ICCUBEA), Pune, India, 12–13 August 2016. 12. Khorsravinia, K.; Hassan, M.K.; Abdul Rahman, R.Z.; Rahman Al-Haddad, S.A. Integrated OBD-II and mobile application for electric vehicle (EV) monitoring system. In Proceedings of the 2017 IEEE 2nd International Conference on Automatic Control and Intelligent Systems (I2CACIS), Kota Kinabalu, Malaysia, 21 October 2017. 13. Malekian, R.; Moloisane, N.R.; Nair, L.; Maharaj, B.T.; Chude-Okonkwo, U.A.K. Design and Implementation of a Wireless OBD II Fleet Management System. IEEE Sens. J. 2016, 17, 1154–1164. [CrossRef] 14. Alvear, O.; Calafate, C.Y.; Cano, J.C.; Manzoni, P. Validation of a vehicle emulation platform supporting OBD-II communications. In Proceedings of the 2015 12th Annual IEEE Consumer Communications and Networking Conference (CCNC), Las Vegas, NV, USA, 9–12 January 2015. 15. Tsai, Y.C.; Lee, W.H.; Chou, C.M. A safety driving assistance system by integrating in-vehicle dynamics and real-time traffic information. In Proceedings of the 2017 IEEE 8th International Conference on Awareness Science and Technology (iCAST), Taichung, Taiwan, 8–10 November 2017. 16. Choi, E.; Chang, S. A consumer tracking estimator for vehicles in GPS-free environments. IEEE Trans. Consum. Electron. 2017, 63, 450–458. [CrossRef] 17. Chou, Y.S.; Mo, Y.C.; Su, J.P.; Chang, W.J.; Chen, L.B.; Tang, J.J.; Yu, C.Y. i-Car system: A LoRa-based low power wide area networks vehicle diagnostic system for driving safety. In Proceedings of the 2017 International Conference on Applied System Innovation (ICASI), Sapporo, Japan, 13–17 May 2017. 18. Wey, C.L.; Hsu, C.H.; Chang, K.C.; Jui, P.C. Enhancement of Controller Area Network (CAN) bus arbitration mechanism. In Proceedings of the 2013 International Conference on Connected Vehicles and Expo (ICCVE), Las Vegas, NV, USA, 2–6 December 2013. 19. Chen, J.; Cao, D.; Lv, X. Design of FlexRay-based communication on triplex redundancy flight control computer. In Proceedings of the 2015 Chinese Automation Congress (CAC), Wuhan, China, 27–29 November 2015. 20. Yang, J.S.; Lee, S.; Lee, K.C.; Kim, M.H. Design of FlexRay-CAN gateway using node mapping method for in-vehicle networking systems. In Proceedings of the 2011 11th International Conference on Control, Automation and Systems, Gyeonggi-do, South Korea, 26–29 October 2011. 21. Mejdi, H.; Jedli, B.; Hasnaoui, S. Designing a FlexRay controller—From SDL to StateFlow and Simulink blocks: Generation and verification. In Proceedings of the 2017 8th International Conference on Information and Communication Systems (ICICS), Irbid, Jordan, 4–6 April 2017. 22. Wang, Y.; Liu, H.; Huang, B.; Sun, X. Frame Design for Vehicular FlexRay Network Based on Transmission Reliability and Slot Utilization. In Proceedings of the 2016 9th International Symposium on Computational Intelligence and Design (ISCID), Hangzhou, China, 10–11 December 2016; pp. 447–452. 23. Chen, Y.Y.; Leu, K.L. An Effective Two-Level Redundancy Approach for FlexRay Network Systems. In Proceedings of the 2016 46th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshop (DSN-W), Toulouse, France, 28 June–1 July 2016; pp. 54–55. 24. Gu, Z.; Han, G.; Zeng, H.; Zhao, Q. Security-Aware Mapping and Scheduling with Hardware Co-Processors for FlexRay-Based Distributed Embedded Systems. IEEE Trans. Parallel Distrib. Syst. 2016, 27, 3044–3057. [CrossRef] 25. Jang, S.J.; Jeon, J.W. Software reprogramming performance analysis of CAN FD and FlexRay protocols. In Proceedings of the 2015 IEEE International Conference on Information and Automation, Lijiang, China, 8–10 August 2015. 26. Abdellaoui, Z.; Bouhouch, R.; Jaouaini, H.; Hasnaoui, S. FlexRay networks for SAE benchamrk application using DDS middleware: Development of FlexRay driver and its Simulink Blockset implementation. In Proceedings of the 2015 2nd World Symposium on Web Applications and Networking (WSWAN), Sousse, Tunisia, 21–23 March 2015. Appl. Sci. 2018, 8, 1594 19 of 19

27. Abdellaoui, Z.; Mbarek, I.B.; Bouhouch, R.; Hasnaoui, S. DDS middleware on FlexRay network: Simulink blockset implementation of wheel's sub-blocks and its adaptation to DDS concept. In Proceedings of the 2015 IEEE 9th International Symposium on Intelligent Signal Processing (WISP) Proceedings, Siena, Italy, 15–17 May 2015. 28. Zeng, W.; Khalid, M.; Chowdhury, S. A qualitative comparison of FlexRay and Ethernet in vehicle networks. In Proceedings of the 2015 IEEE 28th Canadian Conference on Electrical and Computer Engineering (CCECE), Halifax, NS, Canada, 3–6 May 2015; pp. 571–576. 29. Amel, B.N.; Rim, B.; Houda, J.; Salem, H.; Khaled, J. Flexray versus Ethernet for vehicular networks. In Proceedings of the 2014 IEEE International Electric Vehicle Conference (IEVC), Florence, Italy, 17–19 December 2014. 30. Mundhenk, P.; Sagstetter, F.; Steinhorst, S.; Lukasiewycz, M.; Chakraborty, S. Policy-based message scheduling using FlexRay. In Proceedings of the 2014 International Conference on Hardware/Software Codesign and System Synthesis (CODES+ISSS), New Delhi, India, 12–17 October 2014. 31. Yan, W.; Lifang, W.; Chenglin, L.; Fang, L. In-vehicle FlexRay bus monitoring system. In Proceedings of the 2014 IEEE Conference and Expo Transportation Electrification Asia-Pacific (ITEC Asia-Pacific), Beijing, China, 31 August–3 September 2014. 32. Dong, Z.H.; Piao, Z.Y.; Jang, I.G.; Chung, J.G.; Lee, C.D. Design of FlexRay-MOST gateway using static segments and control messages. In Proceedings of the 2012 IEEE International Symposium on Circuits and Systems, Seoul, South Korea, 20–23 May 2012. 33. Lee, S.; Cho, B.S.; Choi, Y.J.; Baek, K.R. Implementation of MOST/CAN network protocol. In Proceedings of the 2011 International Conference on Electrical and Control Engineering, Yichang, China, 16–18 September 2011. 34. Seo, H.S.; Kim, B.C.; Park, P.S.; Lee, C.D.; Lee, S.S. Design and implementation of a UPnP-can gateway for automotive environments. Int. J. Autom. Technol. 2013, 14, 91–99. [CrossRef] 35. Luo, F.; Yang, T.Y.; Liu, C. Development of Automatic CAN Gateway Test System. Appl. Mech. Mater. 2014, 734, 161–167. 36. Mangan, S.; Wang, J. Development of a Novel Sensorless Longitudinal Road Gradient Estimation Method Based on Vehicle CAN Bus Data. Inst. Electr. Electron. Eng. 2007, 12, 375–386. [CrossRef] 37. Gugapriya, G.; Siyal, K. Anti-Theft Vehicle Locking System using CAN. Indian J. Sci. Technol. 2016, 9, 45. 38. Guo, H.; Ngoh, L.H.; Wu, Y.D.; Teo, J.C.M. Secure wireless vehicle monitoring and control. In Proceedings of the 2009 IEEE Asia-Pacific Services Computing Conference (APSCC), Singapore, 7–11 December 2009.

© 2018 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).