Design of A FlexRay-Ethernet Gateway and Security Mechanism For In-Vehicle Networks
Design of A FlexRay-Ethernet Gateway and Security Mechanism For In-Vehicle Networks
Design of A FlexRay-Ethernet Gateway and Security Mechanism For In-Vehicle Networks
Article
Design of a FlexRay/Ethernet Gateway and Security
Mechanism for In-Vehicle Networks
Trong-Yen Lee *, I-An Lin and Ren-Hong Liao
Department of Electronic Engineering, National Taipei University of Technology, Taipei 106, Taiwan;
[email protected] (I-A.L.); [email protected] (R.-H.L.)
* Correspondence: [email protected]
Received: 15 November 2019; Accepted: 21 January 2020; Published: 23 January 2020
Abstract: Due to the development of the Internet of Vehicles (IoV) and advanced driver-assistance
systems (ADAS), the Ethernet has become one of the most important communication protocols for
the future of automotive networks. This is because the existing communication protocols (such
as FlexRay) do not provide sufficiently high bandwidth requirements. The main challenge for the
automotive industry will be to transfer and extend standard IP and Ethernet into vehicles and still
fulfill the automotive requirements. The automotive gateway not only links two or more protocols
and exchanges the data using each, but also monitors and ensures functional safety. This paper
proposes a FlexRay/Ethernet gateway by considering the development conditions of embedded
systems and the security in the field of vehicle networking. The proposed method is implemented
on the Field Programmable Gate Array (FPGA) system to evaluate running time and to analyze the
overhead of the security mechanism. For one-to-one mapping logic, the execution times of FlexRay
to the Ethernet path and Ethernet to FlexRay path are constant, at 4.67 µs and 6.71 µs, respectively.
In particular, cybersecurity can be integrated as an extension of the gateway with low latency and
power consumption.
Keywords: internet of vehicles; FlexRay; Ethernet; gateway; security; FPGA; power consumption
1. Introduction
FlexRay [1] is a standard of in-vehicle network (IVN) communication systems that provides
high-speed serial communication and is often used for new safety features. FlexRay supports a
time-triggered scheme and an optional event-triggered scheme. The advantage of event-triggered
communication is better bandwidth utilization, since communication only occurs if needed. The upper
bound of the data rate is 10 Mbps, and it provides two channels for redundancy. The Internet of Vehicles
(IoV) is a new concept that is an extension of the Internet of Things (IoT). The IoV allows valuable
information from other vehicles or the environment to be obtained. An increasing number of electronic
control units (ECUs), sensors, and cameras will be equipped in the vehicle for driver-assistance
applications. It has been observed that the security and reliability of in-vehicle communication are of
paramount importance because malicious attacks can endanger human lives. Therefore, both higher
bandwidths and increased security are required.
Ethernet is an important communication protocol, and it has several advantages, such as low
cost, high bandwidth, and mature technology. An Ethernet-based vehicle network can communicate
between a vehicle and other vehicles. Therefore, Ethernet must become one of the main protocols
for IVNs and the IoV in the future [2]. However, the existing Ethernet protocol must be modified
to support the delivery of time-critical traffic information and time-sensitive functionality for IVNs.
The gateway is an important and indispensable component for IVNs and the IoV. It means that for
the introduction of Ethernet, a gateway to currently existing automotive networking technologies,
is required for achieving a smooth migration. Therefore, a gateway is an essential component for
communication between FlexRay and Ethernet and also helps to further strengthen security. In this
paper, in addition to discussing the implementation of the FlexRay/Ethernet gateway system, we also
analyze the cost of the system security constraints on latency and power consumption.
2. Related Works
2.1. Gateways
In the automotive industry, embedded system architectures are set in vehicles. The gateway in
IVNs is designed to check internal and external messages and route data from one control protocol
to another. There are two kinds of vehicular network structures: centralized gateway and backbone
network. In a typical centralized gateway structure, communication protocols IVNs are interconnected
by a central gateway. The central gateway is usually implemented by processor to perform the tasks of
packing and unpacking messages, and lookup [3]. The scalability of the centralized gateway is related
to the switching mechanism. In the routing (switching) table, the valid IDs (devices) with priority
and destination addresses are listed. When the number of ports is increased, the routing table will be
expanded, and there will be some overhead costs in terms of latency and hardware resources.
First, an accelerated routing mechanism using a Field-Programmable Gate Array (FPGA) to
reduce the latency for a gateway was proposed in [4]. The authors also built several demonstrations
with different bus systems. They proposed that a modular gateway prototype based on an FPGA is a
powerful alternative for automotive gateways. To minimize the bandwidth requirements, a scheduling
algorithm, earliest deadline first (EDF), was proposed in [5]. EDF forwarding was able to achieve
real-time capability using fewer resources. In addition, the authors adopted a frame aggregation
mechanism to reduce the overhead of framing.
Recently, many studies have been published on the vehicular gateway [6–8]; comparisons of
platforms and functions of security are shown in Table 1. A variety of gateways [6] have been proposed
that use heterogeneous network protocols, including CAN, FlexRay, and Ethernet. The authors
proposed a reusable, verifiable gateway framework that could be easily developed and verified using
graphical user interface (GUI)-based configuration software. However, the verification environment
provided by the proposed gateway framework has not yet been verified. A configurable low-latency
gateway architecture on a hybrid FPGAs was proposed in [7]. A translation mechanism based on
a virtual MAC address was used. The virtual MAC address corresponds to a data type and a set
of receivers that are pre-loaded into the lookup and packing/unpacking module together with the
FlexRay message-type identifier. Furthermore, every slot also contains a preemption indicator (PI),
which allows preemption of long messages by high-priority messages and can be used to implement
Ethernet priority schemes, such as time-sensitive networking. A synchronization mechanism was
developed in [8] for FlexRay and Ethernet AVB networks that guarantees a high quality of service (QoS).
The authors also designed a corresponding embedded system-based gateway system to implement the
proposed synchronization mechanism. This gateway, which is an Ethernet-backbone network, will be
used in future automotive systems.
However, these methods have weaknesses in terms of cybersecurity. The two major objectives
of gateways for IVNs and the IoV include a conversion device between different protocols and a
Sensors 2020, 20, 641 3 of 15
supervisory role to ensure the packets are correct, and a gateway host to control and monitor the
gateway system that is aimed at improving the security of the Ethernet/FlexRay gateway. We previously
proposed a gateway system between the Ethernet and FlexRay in [9]. In this current paper, we describe
the proposed gateway system in more detail, providing information about each module of the
gateway host, risk-control strategies, and the embedded system used for implementation of the
proposed gateway.
3. Proposed Methodology
The functionality of the gateway is to play a role similar to an interface between a FlexRay bus and
an IEEE 802.3-based Ethernet network. The design of an automotive FlexRay/Ethernet gateway system
is shown in Figure 1. The concept of this system is to implement the data-packing and data-unpacking
FlexRay messages in Ethernet packets, a transmission control protocol/internet protocol (TCP/IP) stack,
and an Ethernet controller.
In general working conditions, the Ethernet utilizes specific addresses (the MAC addresses)
to identify the destination and source, and a transformation based on a virtual MAC address
that corresponds to a data type and a set of receivers with the FlexRay message type identifier is
used. However, in more concrete cases, attack and overloading problems always happen in the
heterogeneous network. When a malicious vehicle (non-valid device) wants to provide incorrect
messages, the switching mechanism will reject the messages. Additionally, when messages collide on
the network, the processing is done according to the priority queue in the routing table.
Sensors 2020, 20, 641 4 of 15
two different buffer registers of FlexRay and Ethernet in the module. The registers buffer frames from
the Rx bus and extract the important parts of the Header segments, the Payload data segments, and
the Trailer segments of the frames.
The security module is a part of the SDTM; there are four check mechanisms in the proposed
Security module. First, there is a cyclic redundancy check (CRC) to ensure that safety measures on the
data link layer integrate FlexRay and Ethernet bus technologies. Both consist of protection of header
and payload information as part of each frame using checksums, such as the CRC. Second, if Ethernet
is used in combination with the IP, additional mechanisms are incorporated to aid in security concerns.
Part of the IP header information (e.g., Source Address, Destination Address) is protected by a 16-bit
checksum. In Ethernet architectures, real-time data is exchanged by the widely used User Datagram
Protocol (UDP) in addition to the IP. UDP adds an additional 16-bit arithmetic checksum to protect
the underlying IP header. Both the sequence number and the acknowledgment number of the TCP
header are necessary roles in the three-way handshake of TCP protocol operations. Therefore, these
error detection mechanisms are adopted in the proposed Security module.
Third, the sequence number of the TCP header has dual roles. In the initial sequence number,
the synchronization (SYN) flag is set to 1 in the TCP header. The actual first data byte of the sequence
number and the acknowledged number in the corresponding acknowledgement (ACK) are then this
sequence number plus 1. If the SYN flag is clear (i.e., 0), then this is the accumulated sequence number
of the first data byte of this segment for the current session [15]. Fourth, the acknowledgment number
of the TCP header can also be adopted in the proposed check mechanism. If the ACK flag is set,
the value of this field is the next sequence number that the sender is expecting. If this is the case,
this acknowledges receipt of all prior bytes. The first ACK sent by each end acknowledges the other
end’s initial sequence number itself, but no data.
The central component of the gateway architecture is the transform module, transforming the
frame tasks to each other. The methods of the FlexRay/Ethernet frame [1,16] transformation are shown
in Figures 3 and 4. The transform module consists of the following three segments: header-generated
logic, payload data queue logic, and trailer generate logic. The data path from FlexRay to Ethernet
is shown in Algorithm 1. Since the length of Ethernet frames is more than ten times that of the
FlexRay frames, the Transform module adopts one-to-one mapping logic to encapsulate the frames.
The verification of the security mechanism is status-receiving process, frame CRC, and (FlexRay) ID
authentication. On the other hand, the purpose of encryption of the Ethernet frame is to protect
the privacy of secure data during communication with external devices or further prevent attacks.
The encrypted message from the network must be read and decrypted using the current configuration of
the cipher primitives before the information can be used by the application in the Ethernet node. In the
other case, the messages are from Ethernet to FlexRay, as shown in Algorithm 2. The Transform module
must divide the payload segment from an Ethernet frame into several frame packages (maximum of
six) with the same header and trailer. The message identifier is directly based on the message received,
and the length of Ethernet data is double that of FlexRay data. The virtual MAC address corresponds
to the data type and the FlexRay ID parameter forming one-to-one mapping to a virtual MAC address.
The transmission module packs the parts from the transform module into new frames, buffers the
frames, and schedules the output frames to the Tx bus according to their priorities. The protocol data
unit (PDU) is useful for network protocols that support a longer frame length than CAN, such as
FlexRay and Ethernet. In the case of Ethernet, a frame can include multiple PDUs because the minimum
frame length of the Ethernet is too long to store single data. PDU-based routing consists of direct and
indirect routing. Direct PDU-based routing immediately transmits a received PDU to the destination
network, but it can route part of the frame to a destination network without copying the entire frame.
A received PDU that is configured to direct PDU routing is immediately forwarded to the destination
interface module, such as the CAN or FlexRay interface.
Sensors 2020, 20, 641 6 of 15
/* divides the payload segment from Ethernet frame into several frames */
8: if (length of Ethernet > 255 Bytes) {
9: Divide the Data into several Data and calculate length of each Datum
10: Calculate the number of divided data (n)
11: }
12: else{/* security verification failure*/
13: The Gateway host drops the frame
14: Return
15: }
16: Generate Header CRC
17: Forach (n)
18: FlexRay_Data = Divided (Ethernet_Data)
19: Set FlexRay controller frame buffers
20: Send FlexRay frames to FlexRay Node
21: }
22: End While
Sensors 2020, 20, 641 8 of 15
Figure 5. The design of proposed gateway system based on Zynq-7000 AP SoC. The Ethernet node is
implemented by both PS and PL.
The FlexRay node is composed of the FlexRay controller and FlexRay transceiver. The FlexRay
controller adopted in the proposed gateway system is intellectual property developed by the PATAK
Engineering Company [17]. We modified the source code (hardware description language, i.e.,
Programmable Logic) for experiment planning. There are two communication paths (Receive path and
Transmission) between the gateway and the FlexRay controller. The interconnection of the gateway
control I/O port and the FlexRay controller are internal ports, such as Data input, Data output, and clock
(CLK). The external ports such as Tx, Rx, and Tx_Enable are connected via the FPGA Mezzanine Card
(FMC) pins on the ZedBoard for external communication. Furthermore, we designed and implemented
a FlexRay transceiver board to connect the external transceiver to verify the proposed gateway system
with the ZedBoard. Therefore, the FlexRay controller directly connects to the gateway and transmits
the FlexRay data to the transceiver with FMC ports.
In the Ethernet node, the PL fabric used implement a 10/100/1000 Ethernet port for a network
connection using a Marvell 88E1518 PHY (Physical), and the PHY interfaces to the Zynq-7000 AP
SoC via an RGMII. A simple TCP/IP stack is implemented on the Ethernet controller to handle the
Ethernet data with the Marvell PHY, and the AXI buses are used to communicate with the gateway,
which is also on PL fabric. In this system, the TCP/IP can be defined as a four-layer model, as shown in
Figure 6. The Application layer, Transport layer, and Internet layer are implemented using the LwIP
Application on a PS. The Lightweight IP (LwIP) [18] is an open-source TCP/IP networking stack for
resource-limited systems, such as embedded systems. The Link layer is composed of a MAC layer
Sensors 2020, 20, 641 9 of 15
and a Physical layer, which are implemented by a Gigabit Ethernet MAC Controller on a PS and an
Ethernet PHY interface on PL, respectively.
Security Mechanism
Security Applications
Level (Examples) Receive Frame UDP MAC
Status CRC Header Address/ID
Powertrain systems
High enable enable enable enable
X-by-wire
Collision avoidance system
Medium enable enable enable disable
Electronic stability control
suspension
Low enable enable disable disable
Traction control system
• Risk-control strategies
There are multi-level security strategies in the proposed method based on the application of
FlexRay data signals. Multilevel security protocols were also adopted in [21]. Wang et al. noted that
adding security mechanisms can protect the IVN by collaborating with current in-vehicle security
Sensors 2020, 20, 641 10 of 15
schemes. These discrepancies were made according to the applications in in-vehicle systems. At the
highest level, all of the security mechanisms are enabled, and the applications are often used for new
safety features, such as X-by-wire [22] and powertrain systems. When the proposed gateway is used
in the collision avoidance system or electronic stability control, the security level is set to medium,
and the checking of the MAC address and ID mechanism is disabled. In the low-security level mode,
only the checking states of receive interfaces and checking frames of CRC mechanisms are enabled.
The flow chart of the security module is shown in Figure 7. The processing of the checking UDP header
is implemented in the LwIP stack only applicable in the Ethernet to FlexRay path, and the packets are
dropped upon verification failure.
In such cases, when the gateway receives a frame from FlexRay or Ethernet, the status-receiving
process is an error; when the gateway receive a frame from FlexRay or Ethernet, the frame CRC is not
correct; when the gateway receives a frame from Ethernet, the sequence number and acknowledgment
number of the TCP header, which is related to TCP protocol operation, is an error; when the gateway
receives a frame from FlexRay, the MAC address is not in the whitelist. Then, the receiving process
will drop an incoming message and no further processing is required.
• Encryption methods
Although currently most IVNs do not use encryption, this might be a very important aspect in the
future [23]. There are three encryption methods that are used in the proposed SDTM: Data Encryption
Standard (DES), Advanced Encryption Standard (AES), and AES Counter with CBC-MAC (AES-CCM).
A comparison of encryption methods is shown in Table 3.
Parameters
Encryption
Methods Data Block Key Length Rounds Mode of
(Bits) (Bits) (Times) Operation
DES 64 56 16 N/A
AES 128 128/192/256 10/12/14 ECB-mode
AES-CCM 128 128/192/256 10/12/14 CCM-mode
• DES is a classical symmetric-key algorithm for the encryption of electronic data with a 56-bit key
size. The operation speed of encryption is the fastest of the three encryption methods, but the
DES key is easy to break in a short period of time.
Sensors 2020, 20, 641 11 of 15
• AES supersedes the DES with a 128-bit key size. It is a subset of the Rijndael block cipher. Research
into attacks on AES encryption has continued since the standard was finalized in 2000, which
means the security is sufficient for modern vehicle communications.
• AES-CCM is one of the authenticated encryption schemes as specified by the National Institute
of Standards and Technology (NIST) [24]. The CCM mode is a mode of AES operation for
cryptographic block ciphers and is used to protect the static segment of FlexRay, which is
recommended by the IEEE 802.11 standard. Thus, the AES-CCM is considered the future
encryption method in the IoV [25].
4. Experimental Results
The performance of the proposed FlexRay/Ethernet gateway is evaluated in this section.
The process of transforming FlexRay and Ethernet frames was proven by the experiment results.
Implementation Resource
Proposed Architectures EDK/Tools
Platform/OS Measurement
Xilinx Zedboard Xilinx Vivado 2018.1
FlexRay Node Xilinx Vivado 2018.1
Zynq-7000 AP SoC utilization report
Proposed Xilinx Zedboard Xilinx Vivado 2018.1 Xilinx Vivado 2018.1
Gateway host Zynq-7000 AP SoC Xilinx ISE 14.7 utilization report
Network Debug
Windows 7 Professional
Ethernet End Assistant N/A
Intel Core i7 3.6 GHz
Wireshark
Latency Components
Messages Path FlexRay Node Gateway Host Ethernet End Total
(PL) (PL) (LwIP in PS) Run Time
FlexRay -> Ethernet (with AES-CCM) 8.25 4.67 5.55 18.47
Ethernet -> FlexRay 7.96 6.71 1.36 16.03
For these experiments, the proposed gateway host was executed multiple times for every
FlexRay/Ethernet frame, consuming considerable processor cycles during the movement of data,
and there are 256 valid-IDs in the routing table to one-to-one mapping. The running time of the
Ethernet to the FlexRay path in the Gateway host was more than that of the FlexRay to Ethernet
path because the payload segment from the Ethernet frame was divided into several frames, as seen
in Algorithm 2. Furthermore, it was found that the execution time of the FlexRay to Ethernet path
in the Ethernet End was more than that of the Ethernet to FlexRay path; this was because of the
encryption (with the AES-CCM method) of the data field in the Ethernet frame, as shown in Algorithm
1. Furthermore, the security model maybe suit for critical situations according to the human response
time (200 ms in general).
using the current configuration of the cipher primitives before the information can be used by the
application. For a message from the FlexRay to Ethernet path per 8 bytes of data, the encryption
methods (DES, AES, and AES-CCM) take 1.17 µs, 1.23 µs, and 3.28 µs, respectively. When we applied
the AES-CCM method in the encryption processing, the method used 17.7% of the total execution time
of the FlexRay to Ethernet path.
To analyze the overhead of security mechanisms, two cases were implemented: the proposed
gateway with and without the security mechanism. While embedding security mechanisms into the
proposed gateway systems, there were some overhead costs in terms of latency, hardware resources,
and power consumption, as shown in Table 6. Increasing the security level increased the latency due to
the complexity associated with management of the check mechanism operations. The results showed
that the proposed SDTM can be integrated as an extension of the gateway with low-latency overhead.
Resource
Implementation Resource Power
Consumption
Method (LUTs) Consumption
(Reg, LUTs)
Proposed gateway 1.00× (4950), 1.00× (4880) 9.3% 1.00×
Proposed gateway with SDTM 1.25× (6125), 1.24× (6182) 11.62% 1.01×
Table 7. Detail for execution time (µs) of modules within the proposed gateway host.
The proposed gateway included a gateway host to control and monitor the gateway system in
order to improve the security of the Ethernet/FlexRay gateway. Although the comparisons of execution
time were not ideal, the latency overhead is constant under any conditions, architectural design
Sensors 2020, 20, 641 14 of 15
strategies for cybersecurity and functional safety were implemented. Then, the contributions of this
paper are as follows:
(1) Using the HW/SW (hardware/software) method, data communication is implemented between
the FlexRay and Ethernet network.
(2) The risk-control strategies are related to FlexRay data signals, and the proposed Security Data
Transmission Mechanism (SDTM) is integrated as an extension of the gateway.
(3) The novelty of the vehicular gateway is to improve the security with little overhead, and it is
more suitable for IVNs and the IoV in the future.
5. Conclusions
In this paper, a gateway for the FlexRay and Ethernet interface design using an FPGA hardware
core and a CPU software core is proposed. The proposed gateway is implemented on a Xilinx ZedBoard
using IP integration and the HW/SW method. The secure data transmission mechanism (SDTM)
including security module and encryption processing is designed for the detection and monitoring
of data packets. Three risk-control strategies based on the type of FlexRay data signals are designed
for different car applications or regions of the FlexRay protocol. An experimental method to verify
performance is conducted to make connections between the proposed gateway and an external FlexRay
node or Ethernet end. In the future, the gateway should be implemented on the platform designed
to meet the requirements for modern vehicles. Additionally, the evaluation environment should
be implemented in automotive software architecture such as AUTOSAR, which is closer to the real
automotive environment.
Author Contributions: Conceptualization, T.-Y.L.; Data curation, R.-H.L.; Formal analysis, I.-A.L.; Investigation,
I-A.L.; Methodology, T.-Y.L., I.-A.L. and R.-H.L.; Project administration, T.-Y.L.; Resources, I.-A.L.; Software,
R.-H.L.; Supervision, T.-Y.L.; Validation, I-A.L.; Visualization, I-A.L. and R.-H.L.; Writing – original draft, R.-H.L.;
Writing – review & editing, T.-Y.L. and I.-A.L. All authors have read and agreed to the published version of
the manuscript.
Funding: The authors would like to thank the Ministry of Science and Technology of the Republic of China, Taiwan,
for partially supporting this research under Contract No. MOST 108-2221-E-027-091 and MOST 107-2637-E-027-006.
Acknowledgments: The authors would like to thank the Editors and all the Reviewers for their valuable comments.
Conflicts of Interest: The authors declare no conflict of interest.
References
1. FlexRay Consortium. FlexRay Communications System—Protocol Specification—Version 2.1 Revision
A. Available online: https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=
2ahUKEwi--6TIo5nnAhVjL6YKHSzcDb8QFjAAegQIBBAB&url=https%3A%2F%2Fsvn.ipd.kit.edu%
2Fnlrp%2Fpublic%2FFlexRay%2FFlexRay%25E2%2584%25A2%2520Protocol%2520Specification%2520V2.
1%2520Rev.A.pdf&usg=AOvVaw0snIyyfkFMHWc7KHRLdS82 (accessed on 23 January 2020).
2. Shane, T.; Martin, G.; Ciaran, H.; Edward, J.; Mohan, T.; Liam, K. Intra-Vehicle Networks: A Review.
IEEE Trans. Intell. Transp. Syst. 2015, 16, 534–545.
3. Puhm, A.; Roessler, P.; Wimmer, M.; Swierczek, R.; Balog, P. Development of a flexible gateway platform for
automotive networks. In Proceedings of the IEEE International Conference on Emerging Technologies and
Factory Automation, Hamburg, Germany, 15–18 September 2008.
4. Sander, O.; Hubner, M.; Becker, J.; Traub, M. Reducing latency times by accelerated routing mechanisms
for an FPGA gateway in the automotive domain. In Proceedings of the IEEE International Conference on
Field-Programmable Technology, Taipei, Taiwan, 8–10 December 2008.
5. Herber, C.; Richter, A.; Wild, T.; Herkersdorf, A. Real-time capable CAN to AVB Ethernet gateway using
frame aggregation and scheduling. In Proceedings of the Design, Automation and Test in Europe Conference
and Exhibition, Grenoble, France, 20–21 March 2015.
6. Kim, J.H.; Seo, S.H.; Nguyen, T.; Cheon, B.M.; Lee, Y.S.; Jeon, J.W. Gateway Framework for In-Vehicle
Networks based on CAN, FlexRay and Ethernet. IEEE Trans. Veh. Technol. 2015, 64, 4472–4486. [CrossRef]
Sensors 2020, 20, 641 15 of 15
7. Shreejith, S.; Mundhenk, P.; Ettner, A.; Fahmy, A.; Steinhorst, S.; Lukasiewycz, M.; Chakraborty, S. VEGa: A
High Performance Vehicular Ethernet Gateway on Hybrid FPGA. IEEE Trans. Comput. 2017, 66, 1790–1803.
[CrossRef]
8. Lee, Y.S.; Kim, J.H.; Jeon, J.W. FlexRay and Ethernet AVB Synchronization for High QoS Automotive Gateway.
IEEE Trans. Veh. Technol. 2017, 66, 5737–5751.
9. Liao, R.H.; Lee, T.Y.; Lin, I.A. Design of FlexRay/Ethernet Automotive Gateway. In Proceedings of the 29th
Symposium on VLSI Design/CAD, Kaohsiung, Taiwan, 7–10 August 2018.
10. Mateus, K.; Königseder, T. Automotive Ethernet, 1st ed.; Cambridge University Press: Cambridge, UK, 2014.
11. Soares, F.L.; Campelo, D.R.; Yan, Y.; Ruepp, S.; Dittmann, L.; Ellegard, L. Reliability in Automotive Ethernet
Networks. In Proceedings of the IEEE International Conference on the Design of Reliable Communication
Networks, Kansas City, MO, USA, 24–27 March 2015.
12. Sakiz, F.; Sen, S. A survey of attacks and detection mechanisms on intelligent transportation systems: VANETs
and IoV. Ad. Hoc. Netw. 2017, 61, 33–50. [CrossRef]
13. Irshad, A.S.; Iftikhar, A.; Halabi, H.; Manan, J.L.B.A. Classes of attacks in VANET. In Proceedings of the
IEEE Saudi International Electronics, Communications and Photonics Conference, Riyadh, Saudi Arabia,
24–26 April 2011.
14. Bittl, S. Attack potential and efficient security enhancement of automotive bus networks using short MACs
with rapid key change. Commun. Technol. Veh. 2014, 113–125. [CrossRef]
15. TCP Connection Monitoring System. In Proceedings of the International Conference on Computational
Intelligence & IoT, Tripura, India, 11–15 December 2018; pp. 419–423.
16. Ethernet_Frame. Available online: https://en.wikipedia.org/wiki/Ethernet_frame (accessed on 1 March 2018).
17. PATAK Engineering FlexRay Controller Documentation. Available online: http://patakengineering.eu/
download/FlexRayController.pdf (accessed on 6 March 2018).
18. Dunkels, A. Design and Implementation of the lwIP TCP/IP Stack. Available online: http://www.sics.se/
~{}adam/lwip/doc/lwip.pdf. (accessed on 7 July 2018).
19. Liu, J.J.; Zhang, S.B.; Sun, W.; Shi, Y.P. In-Vehicle Network Attacks and Countermeasures: Challenges and
Future Directions. IEEE Netw. 2017, 31, 55–58. [CrossRef]
20. Fadlullah, Z.M.; Nishiyama, H.; Kato, N.; Fouda, M.M. Intrusion Detection System (IDS) for Combating
Attacks Against Cognitive Radio Networks. IEEE Netw. 2013, 31, 51–56. [CrossRef]
21. Wang, L.; Liu, X. NOTSA: Novel OBU With Three-Level Security Architecture for Internet of Vehicles.
IEEE Internet Things J. 2018, 5, 3548–3558. [CrossRef]
22. X-By-Wire Team. X-By-Wire: Safety Related Fault Tolerant Systems in Vehicles. Project No. BE 95/1329.
Available online: https://cordis.europa.eu/project/id/BRPR950032 (accessed on 23 January 2020).
23. A Structured Approach to Anomaly Detection for In-Vehicle Networks. In Proceedings of the 6th IEEE
International Conference on Information Assurance and Security, Atlanta, GA, USA, 22–23 August 2010.
24. National Institute of Standards and Technology. Recommendation for Block Cipher Mode of Operation: The
CCM Mode for Authentication and Confidentiality. Available online: https://www.nist.gov/publications/
recommendation-block-cipher-modes-operation-ccm-mode-authentication-and-confidentiality (accessed
on 23 January 2020).
25. Hung, C.W.; Hsu, W.T. Power Consumption and Calculation Requirement Analysis of AES for WSN IoT.
Sensors 2018, 18, 1675. [CrossRef] [PubMed]
26. Wireshark Go Deep. Available online: https://www.wireshark.org/ (accessed on 10 March 2018).
© 2020 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/).