Content uploaded by Adnan Shaout
Author content
All content in this area was uploaded by Adnan Shaout on May 21, 2016
Content may be subject to copyright.
Connected Car
Architecture and Virtualization
1Husein Dakroub, 2Adnan Shaout and 3Arafat Awajan
1&2The University of Michigan – Dearborn
The Electrical and Computer Engineering Department
Dearborn, MI
3Princess Sumaya University of Technology
The Computer Science Department
Amman, Jordan
Abstract- Connectivity has become an
essential need for daily device users. With the car
projected to be the “ultimate mobile device”,
connectivity modules will eventually be mainstream
in every car. Network providers are expanding their
infrastructure and technology to accommodate the
connected cars. Besides making voice and emergency
calls the connected car will be sharing data with
telematics service providers, back end systems and
other vehicles. This trend will increase vehicle
modules, complexity, entry points and vulnerabilities.
This paper will present the current connected car
architectures. The paper will present current
architectural issues of the connected car and its
vulnerabilities. The paper will present a new
proposed architecture for the future connected car
that enhances efficiency and security.
Keywords: Connectivity, Architecture, Autonomous
Cars, Efficiency, Security, Virtualization
[1] INTRODUCTION
The future of the automotive industry is to turn
the vehicle into a valuable partner in the Internet-of-
Things (IoT), where every device is connected to the
Internet. The practical way in generating data was
usually through human generated data, but going
forward we will see data generated by devices. This
trend will increase the amount of modules and software
in the vehicle. Sensors will eventually be placed
throughout the body of the vehicle. The automotive
industry is heading to self-driving autonomous cars. A
recent technology and product line driven by this is
Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure
which is generally referred to as Vehicle-to-Everything
(V2X). This is aimed for a standardized short range
communication between “things” and the vehicle. One
can see the architecture of the connected car as the
vehicle connected to anything with an electronic device.
With a focus on connectivity between the car and
everything, V2X, vehicle, cloud, smartphone, servers
and infrastructure can replace X. The process of
exchanging data is relatively straightforward for many
manufacturers and automotive suppliers, but the
competitive piece of the architecture is consolidation,
security and consumer privacy. With these connected
features, the modules open many entry points to
potential hackers. This can lead to loss of vehicle and
potentially life. Hackers can potentially cause accidents
and remotely control vehicles [1].
There can be multiple vulnerabilities for the
vehicle, but some of the physically achievable threats are
access to electronic control units (ECU’s), a driver’s
mobile device that is connected to the vehicle and the
cloud infrastructure. To achieve great security, the
protocol, authentication, authorization, encryption and
data protection have to be bulletproof. The ECU can be
reverse engineered. Hardware altered or probed to
potentially identify how to hack other components in the
vehicle [1]. In general, production systems usually have
diagnostic access which potentially can be a threat, but
that is out of the scope of this paper.
Over-the-Air updates (OTA) can alter code in
vehicle modules that updates their software to do new
things. Moreover, the vehicular network can easily be
Dr. Adnan Shaout is currently on sabbatical at Princess Sumaya University of Technology, Amman, Jordan
reversed engineered, that’s why it’s essential to protect
diagnostic data, firmware update, or critical commands
[1]. For connected devices to the infotainment or
connectivity system, the ability to get into the software
of the systems through the kernel can lead to the
exchange of deception techniques with malware.
Moreover, as vehicle functionality is growing,
so is the amount of hardware modules and software
within the vehicle. This trend increases the complexity
of software, cost and weight of the vehicle. Automakers
will need to reduce somewhere to accommodate for this
new drift of events to sustain the same bill of material
cost. Generally, marketing and sales teams will not allow
for an increase in price tag of the vehicle for added
functionality. Also, as government mandates an
improvement in fuel efficiency, OEMs have to increase
functionality while reducing weight. This paper will
present a solution that will benefit automakers by
reducing cost, creating a consistent environment and
increase security.
The paper is organized as follows: section II
presents the current connected car architectures, section
III presents the current connected car architecture issues,
section IV presents a new proposed architecture that
would achieve efficiency and security and finally section
V will present the conclusion.
[2] CONNECTED CAR ARCHITECTURES
What defines a connected car? Connected car is
a car equipped with Internet access. It allows the car to
be made available to the Internet for shared data. The
connection to the Internet is typically done by a built-in
embedded modem on-board the car called a Telematics
Control Module (TCU) and a Wi-Fi connection available
within a module inside the car [2]. Some of the functions
of a connected car include the following:
•Automatic roadside assistance in case of crashes
•Information calls to Telematics Service
Providers (TSP)
•Stolen Vehicle Tracking (SVT)
•Remote Service (Vehicle on/off, vehicle lock/un-
lock)
•Vehicle Updates
•Video streaming / Web browsing
The car can be connected in several ways.
Depending on what it is being connected, the car has a
different form of technology associated with that
respective connection. The following is a list of several
nodes that the car is typically connected to [3]:
•Car-to-Network: In this form of connection, the
car is connected to the cellular network (2G, 3G or
4G), and is the medium to where SMS, Data and
Voice Calls are transmitted.
•Car-to-TSP: This form of communication
utilizes the network but is connected to a backend
vehicle service provider. The Telematics Service
Provider (TSP) has the ability to share data with the
car,
•Car-to-Cloud: The cloud can store data and be
accessed by the car via the network.
•Car-to-Car: In this form, cars communicate
wirelessly among each other over short-range
communication with safety related alerts.
•Car-to-Infrastructure: In this form of
communication, the car is connected to the
surrounding environment and engaged in exchange
of data such as traffic lights, stop or speed limit
signs.
Figure -Connected Car (source Visteon [20])
Figure 1 displays a typical architecture for a
connected car, with many hardware modules that can
interact with the outside world. The following are the
hardware modules that enable connectivity to anything
outside the vehicle [3] [4]:
•V2X/DSRC: Vehicle-to-X (V2X) is a term used
to describe the connection of a vehicle to anything
such as a vehicle or infrastructure. V2X standards
are currently being defined and are expected to
operate using DSRC technology.
•TCU/Embedded Modem: The TCU, which
typically houses the embedded modem, provides an
Internet connection to the car based on a Cellular
connection using 2G, 3G or 4G.
•Infotainment: Infotainment system provides the
car with User Interface (UI) and
radio/entertainment/media functionality, giving the
driver the ability to connect over Wi-Fi or Bluetooth.
Vehicle
Module
Technology External to the Vehicle
V2X DSRC Vehicle/Infrastructure
TCU 2G/3G/4G Telematics Services
Infotainment Bluetooth/Wi-Fi Smartphone/Home
Figure - Technology Chart
The previous paragraph discusses the hardware
that enables the connected car features. The following
paragraph will depict the wireless technology that
enables the connectivity between the modules inside and
outside the vehicle as shown in Figure 2:
•Dedicated Short Range Communication
(DSRC): is a short-range wireless communication
channel designed for automotive use. It utilizes the
5.9 GHz band [3].
•Cellular Network (3G, 4G): 3G and 4G are
mobile telecommunication technologies. They are
based on a set of standards used for mobile
communication that you must comply with for using
the services and networks [4].
•Wi-Fi: A local area wireless communicating
technology which uses the 2.4 GHz and 5 GHz band.
It is defined by the Wi-Fi Alliance and is based on
the IEEE 802.11 standards [5].
•Bluetooth: Short ranged, low powered radio
waves. It communicates on the 2.4-2.48 GHz band
[5].
•NFC: Near Field Communication (NFC),
operates at 13.56 MHz and transfers wireless data up
to 424 Kbits/s over a range of 4-10cm [6].
[3] CONNECTED CAR ARCHITECTURE ISSUES
The current state of the art shown in section II
consists of a distributed system. Many ECU’s are
dispersed around the vehicle’s Controller Area Network
(CAN) bus, communicating and triggering different
commands, with some utilizing the same technology.
Automakers usually source multiple Tier 1 suppliers to
develop and manufacture the different ECUs in the
vehicle. This has some political and manufacturing
reasoning. To achieve better pricing, one would need
multiple suppliers to bid on several products and
leverage other ECUs currently in the vehicle in exchange
for pricing on new ECUs. Moreover, in case of a Tier 1
supplier filing bankruptcy or having manufacturing
constrains, automakers would need to have other Tier 1
suppliers already sourced on other projects to be
educated enough about the automakers’ logistics and
manufacturing process to be competent enough to pick
up added work, when needed.
The previous paragraph discusses some of the
pros in a distributed and multi-sourced architecture. This
paragraph discussed some of the cons. Typically, a
standalone ECU consists of a printed circuit board
(PCB) that is populated with discrete components, RAM
and Flash memory, a processor that would handle the
heavy processing and a Vehicle Interface Processor
(VIP) that would handle the application logic and
interfacing to the vehicular CAN bus. This redundancy
of material and work is pricy and can cause latency,
communication and upgrade capability issues, not
including the hefty cost it takes to manufacture, validate
and ship each ECU from the respective manufacturing
plant. Furthermore, it takes companies’ considerable
amount of effort and resources to bring an Operating
System (OS) up to the required automotive standards,
fine-tuning and validating similar Board Support
Packages (BSP) across multiple modules. This effort
needs a great amount of capital investment made by
OEMs to source multiple suppliers to develop something
of this caliber.
In addition to some of the financial hurdles
discussed, Firmware update Over-The-Air (FOTA) is an
essential component of the connected car with ever
changing protocols and features. The need to update
software has become a priority, and as shown in Figure
1, with multiple ECUs dispersed around the vehicle.
FOTA updates become increasingly difficult to conduct
with bottlenecks in entry points and vehicle network
speeds.
Moreover, governments are always mandating
automakers to improve their fuel efficiency. The Obama
administration issued a statement on August 2012 that
would require automakers to nearly double their average
fuel economy of new vehicles by 2025 [16].
Transportation secretary said the new standards would
save $1.7 trillion in fuel costs. There are many ways to
improve fuel efficiency, but the one method that
correlates with the topic of this paper is weight.
Reducing weight of the vehicle can drastically improve
fuel efficiency. Weight reduction is a new trend in the
automotive world, for example, the 2015 Ford F150
redesigned to all aluminum helped achieve greater fuel
efficiency. A research study conducted by Richard Broda
and Anrico Casadei [17] has shown the impact of vehicle
weight reduction on fuel economy. The author
conducted different tests that correlated weight reduction
with fuel consumption. Results concluded that reducing
the vehicle weight resulted in less tractive effort required
to accelerate the vehicle and less rolling resistance from
the tires. Drive cycles showed greater fuel economy
benefits from weight reduction [17]. To conclude, having
many ECUs around for the connected car can increase
the weight of the vehicle and can cause inefficiency with
respect to fuel consumption for automakers.
To have a robust and efficient security solution,
one has to understand the threats to the car. The
following are some threats to the vehicle:
•Software update. Perform software update with
altered unofficial re-flash image, which could
include malicious code.
•Antenna jamming. Use RF signal generators to
emit strong signal in the bands of interest to
jam/interfere normal operation of a wireless module
and/or a GPS module.
•Wireless network spoof. Use wireless network
simulator or small cell to gain access to vehicle's
OTA interface and accomplish intended tasks. This
could be used as a method to facilitate other attack
scenarios.
•Manipulate wireless account settings.
Unauthorized manipulation of wireless account
setting through the wireless carrier's control portal or
similar interface.
•Attack on WWAN. The infected Device initiates
attack on wireless wide area network (WWAN) by
flooding spam voice calls, data calls or SMS. This is
a scenario associated with other attack scenarios
•Spoofing TSP with SMS. Utilize WWAN
interface to spoof as a valid TSP by sending
legitimate SMS in right format. The attacker has
proper knowledge of message definition and
protocol used by TSP.
•Hijack Data Communication with Server.
Intentionally send bad URL/spoof DNS system (man
in the middle attack) to hijack data communication
between Device and server.
•Sniff SMS. Use techniques to receive and decode
SMS communications on interface between TCU
and TSP.
•Malicious Code Injection, Bluetooth. Crash the
product or inject malicious code by exploring the
weaknesses in the Bluetooth communication stack or
device software code, such as handling invalid or
out-of-range input.
•Unauthorized Access to Cryptographic Keys.
Exploit mismanagement of organizational processes
to gain access to cryptographic keys. Those
processes include the following:
oUnauthorized Data Access. Wi-Fi
Access Point Exploit vulnerabilities- allowing
access to device.
oRuntime Environment or JVM
Vulnerability. An application (from
TSP/OEM/3rd party) that is downloaded to the
device that allows access to features, data or
systems.
This section presents the multiple issues that
come with a distributed architecture. As discussed, the
connected car will need to have better and more efficient
communication within the vehicle network, reduce
latency and remove redundancy of material required to
meet automaker weight and price requirements. The next
section presents a new proposed solution.
[4] ARCHITECTURE SOLUTION
To achieve an efficient solution required for the
connected car, the current state of the art described in
section III must change. Figure 3 shows the suggested
architecture to achieve ECU consolidation and help
increase efficiency and security, reduce cost and
intuitively allow effective communication between
domains. Domain refers to the different functions
shown in Figure 3 (Infotainment, Telematics, Cluster,
and advanced driver assistance systems (ADAS)).
Figure - ECU consolidation by Hardware Virtualization
As discussed in section III current vehicle
architectures consist of separate repetitive hardware for
each respective domain; Infotainment, Telematics,
Cluster and ADAS. To consolidate, these standalone
ECU’s dispersed around the vehicle’s network will need
to be reduced into a single one Deutsches Institut für
Normung (DIN) (the German national organization for
standardization) ECU that will integrate the different
domains. Furthermore, inside the single one-DIN ECU a
single processor will host all the domains. This can be
achieved by using virtualization, which allows for
multiple operating systems to run independently on
different cores within a single processor [7]. For
example if utilizing a quad core processor:
•Core one can run infotainment related features
including AM/FM, navigation and audio amplifiers.
•Core two can run Telematics features and
downloadable applications defined by automakers.
•Core three can host a driver information
solution for the cluster and head-up-display (HUD).
•Core four can run Advanced Driver Assistance
Systems (ADAS), including rear-view camera, 360
camera, parking assist, and V2X communication.
All cores can run side by side on the same
system on chip (SOC), separate memory for each core
and a shared memory pool for based communication
between operating systems. Virtualization hides the
lower computing layers (processing, flash, memory, etc.)
from the users by presenting them in an abstract form.
This is typically done in the IT world, where many
servers are virtualized to give system users the ability to
scale hardware resources on demand [8].
The use of virtualization in the form of an
embedded hypervisor enables a software architect to
optimize the embedded device software using a wide
variety of configurations, including mixes of Instrument
amplifiers (AMP), Symmetric multiprocessing (SMP),
and core virtualization. A hypervisor is a software
component that is placed between the operating system
and hardware. The hypervisor manages the hardware and
creates partitions in which operating systems execute.
Each partition is given access to resources (processing
cores, memory and devices) as specified by the design of
the embedded system. Each partition can hold an
operating system and is protected from the other
partitions. The hypervisor can execute a single partition
on a single core, a single partition across multiple cores,
or multiple partitions on a single core [12]. This form is
typically addressed as hardware Virtualization.
For this paper a suggestion is being made for
hardware virtualization with the addition of a
virtualization extension, enabling full binary compatible
virtualization of the CPU, extended into the system and
IO through the memory management unit (MMU)
system. In an ideal environment the previous described
virtualization would not allow the OS’s to run at their
required speed. Hardware virtualization extension helps
reduce the need for trapping and emulating instructions
executed with a guest OS. The hypervisor will be able
to virtualize the entire instruction set using a classic trap-
and-emulate model in hardware, as opposed to doing it
in software [18] [19]. This type of virtualization
extension is currently available in processors using ARM
architecture [18] [19]. The ARM virtualization extension
consists of:
•A new hypervisor mode that has higher priority
than a supervisor mode. This enables the hypervisor
to run at higher authority than the OS’s, removing
the need of a Paravirtulization.
•Mechanisms to help interrupt handling.
•System MMU to help memory managing.
•Enabling debugger access to individual OS’s.
This paper does not depict the layers of
virtualization in detail, but rather raise awareness to the
newly developed extension introduced by ARM that
delivers a cohesive solution that would help reduce
software complexity and cost, and increase system
robustness and security. In addition, this form of
architecture will reduce the latency and increase the data
rate transmission among domains. Figure 4 presents a
hypothetical cost estimate of each module with its
respective discrete components, software development
and processor cost compared to a virtualized system. As
shown there can be a significant amount of cost and
weight reduction achieved by a virtualized system.
Module Discrete +
Software
Processor Total
Cluster (450g) $100 $20 $120
Infotainment (900g) $150 $20 $170
ADAS/V2X (250g) $50 $20 $70
Telematics/Android
(300g)
$100 $20 $120
Total price of all modules is $490 and with weight of 1900g
One-DIN ECU +
Virtualization (900g)
$200 $20 $220
Total price of a virtualized system is $220 and with weight
of 900g
Figure - Distributed vs. Consolidated Architecture
(Price & Weight)
In any given proposition, the advantage of
having virtualization is isolation of the different domains
within the processor, consolidation of multiple hardware
modules around the vehicle, flexibility in graphical
personalization and cost/weight efficiency. In this certain
use case, OEMs can isolate safety related features from
infotainment features, bringing domain stability to the
ECU. For example, rear view camera can be running on
its own core isolated from any other application or
OS/core that has a potential of crashing. The advantage
with utilizing virtualization in this instance is to isolate
safety critical features from downloadable 3rd party
applications. For example, Android applications can
have badly written code utilizing an extraordinary
amount of memory. Virtualization can ensure the
independence and separation among these different
domains. Consolidation is obviously achieved with
reducing multiple ECUs into one-DIN box.
Moreover, it’s strategically more appealing to
secure one entry point of a consolidated system shown in
figure 3, compared to the many entry points presented in
a distributed system. This will also increase the
efficiency of recourses working on a project. Instead of
developing multiple testing and validation scripts for the
modules in the vehicle, recourses will have to be
developed for only one system. Automakers will only
need to source one supplier to develop a complete and
robust security architecture for one platform, not needing
to work extensively with many suppliers to ensure safety
of multiple vulnerabilities on the CAN bus.
Furthermore, a consolidated system can become a hub
for updating all the OS’s inside the SOC. It can host a
software update gateway that will allow receiving
authorized secure software updates from a backend
server via Open Mobile Alliance (OMA) compatible
protocol. The update gateway can manage the secure and
efficient distribution of the update packages to all OS’s
of different domains. This is a much more effective and
efficient way to conduct the update compared to utilizing
the vehicular network to update multiple ECU’s per the
current state of the art architecture.
The proposed new architecture will allow for the
integration of various cockpit domains and features into
a single one-DIN ECU. Furthermore, the one-DIN ECU
would efficiently host only one processor that is fully
virtualized with an added ARM Virtualization extension.
This suggested architecture would not only increase
security but also reduce cost, workload, weight and
complexity.
Technology
Bluetooth
(4.0)
NFC Wi-Fi Cellular
Network
Uses Smartphone
connection
Pairing High
throughput
data
connection
Telematics
Services
Range 50m 5cm 100m Unlimited
Spectrum 2.4GHz 13.56M
Hz
2.4MHz 700MHz-
2200MHz
Security AES 128-bit
encryption
No
security
WPA2-
AES 256-
bit
encryption
KASUMI
Cipher/
WPA2
Figure - Technology Characteristics
The consolidated system that is achieved via
virtualization will have to host many technologies as
shown in Figure 5. There are already well-established
security protocols for the respective technologies.
Bluetooth and Wi-Fi are currently the most widely used
connectivity features within the vehicle. Bluetooth
utilizes a pre-shared key authentication and encryption
algorithm based on Advanced Encryption Standards
(AES), which is also used by Wi-Fi. The strength of the
Bluetooth security relies primarily on the length and
randomness of the passkey. The devices mutually
authenticate each other to set up a link for authentication
and encryption [12] [13].
Figure - One round of encryption and decryption
[21]
Advanced Encryption Standard (AES) is a
symmetric block cipher. It uses three block ciphers,
AES-128, AES-192 and AES-256. Secret-key ciphers
use the same key for encrypting and decrypting, so both
sender and receivers use the same key. 128-bit keys
consist of 10 rounds and 256-bit consists of 14 rounds,
with substation, shift, mixing and adding of the input to
create a final cipher text. Figure 6 shows a typical
round. The 128-bit key is also arranged in the form of a
matrix of 4x4 bytes, and the key is expanded into a key
schedule consisting of 44 4-byte words [13].
It is essential to ensure the Internet service
provider (ISP) WP is using Wi-Fi Protected Access 2
(WPA2) instead of Wired Equivalent Privacy (WEP).
Keep the WPA2 key a complex passphrase. Application
encryption (SSL or TLS) over the Internet will protect
the data being transmitted.
The consolidated system should also implement
a feature called “secure boot” which only allows signed
software to run on a device. The signed software is set
up by the device manufacture. Moreover for the threats
presented in section III, the consolidated system should
have to perform the following tasks:
•Protected accounts with password
•FOTA with authentication
•Antenna jamming detection
•Secure SIM card
•Backup source code
•Authentication for all connectivity
•Code integrity check
[5] CONCLUSION
In conclusion, this paper presented the current
state of architecture for the connected car and its issues.
Moreover, the paper presents a consolidated solution that
will ensure a more reliable and efficient architecture to
help give automakers more confidence in the
development process of the connected car. Finally,
current state of the art security/encryption algorithms
presents a secure protocol exchange between the wireless
connectivity technologies utilized by the car.
REFERENCES
[1] Tamas Becsi, Szilard Aradi, and Peter Gaspar,
“Security Issues and Vulnerabilities in Connected Car
Systems" In Proc. of MT-ITS, June 2015.
[2] Elliott, Amy-Mae (25 February 2011). "The Future of the
Connected Car". Mashable. As of January 4, 2016.
[3] "Federal Communications Commission. News Release,
October 1999". FCC. Accessed January 12, 2016.
[4] Cellular Network
https://en.wikipedia.org/wiki/Cellular_network. Accessed
January 4 2016.
[5] What is Wi-Fi? "What is Wi-Fi (IEEE 802.11x)? A
Webopedia Definition". www.webopedia.com. Accessed
January 4 2016.
[6] Near Field Communication
https://en.wikipedia.org/wiki/Near_field_communication as of
January 4, 2016.
[7] Wikipedia- Hypervisor
http://en.wikipedia.org/wiki/Hypervisor. Accessed January 4,
2016.
[8] Sung-Moon Chung; Hyun-Wook Jin, "Isolating System
Faults on Vehicular Network Gateways Using Virtualization,"
Embedded and Ubiquitous Computing (EUC), 2010
IEEE/IFIP 8th International Conference on , vol., no.,
pp.791,796, 11-13 Dec. 2010
[9] K. Adams and O. Agesen, "A comparison of software and
hardware techniques for x86 virtualization," In Proc. of
ASPLOS 2006, pp. 2-13, August 2006
[10] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A.
Ho, R. Neugebauer, I. Pratt, and A. Warfield, "Xen and the art
of virtualization," In ACM SIGOPS Operating Systems
Review 37(5): 164-177, 2003. (Pubitemid 40929695)
[11] M-Y. Lee, S-M. Chung, and H-W. Jin, "Automotive
Network Gateway to Control Electronic Units through MOST
Network," In Proc. of IEEE ICCE, January 2010.
[12] WindRiver Hypervisor
http://www.windriver.com/products/hypervisor/
Accessed January 12, 2016.
[13] http://www.yuuhaw.com/bluesec.pdf. Juha T. Vainio (25
May 2000). Helsinki University of Technology. Accessed
January 12, 2016.
[14] NSA “Systems and Netowk Analysis Center Information
Assurance Directorate” in IAD.
[15] Stephan Eichler “Architecture Concept for Vehicular
Network Nodes” in ICICS 2007.
[16] Bill Vlasic
http://www.nytimes.com/2012/08/29/business/energy-
environment/obama-unveils-tighter-fuel-efficiency-
standards.html?_r=0 . Accessed January 4, 2016.
[17]
Anrico Casadei, Richard Broda, “Impact of Vehicle Weight
Reduction on Fuel Economy for Various Vehicle
Architectures”, December 2007.
[18] Roberto Mijat, Andy Nightingale. “ Virtualization is
Coming to a Platform Near You” White Paper, ARM in 2011.
[19] John Goodacre “Hardware accelerated Virtualization I the
ARM Cortex Processors” XenSummit Asia, November 2011.
[20] Visteon
http://www.slideshare.net/VisteonCorporation/mgreen-mar5-
2015 . Accessed January 4, 2016.
[21]
https://engineering.purdue.edu/kak/compsec/Lectures.html,
lecture 8 of “computer and Network Security” by Avi Kak.
Accessed January 12, 2016.
A. CONTACT INFORMATION
Husein Dakroub received a B.S.E in Electrical Engineering
at University of Michigan, Dearborn, MI. He is pursuing a
M.S.E in Computer Engineering at University of Michigan,
Dearborn, MI. Husein Dakroub is currently a Technical Lead
Engineer at Visteon, where he worked since 2013. He has
been involved in the design and development of automotive
infotainment and telematics systems. His expertise is in
system design of infotainment and telematics products. His
email address is hdakroub@visteon.com
Dr. Adnan Shaout is a full professor and a Fulbright Scholar
in the Electrical and Computer Engineering Department at
the University of Michigan – Dearborn. At present, he
teaches courses in logic design, computer architecture, cloud
computing, fuzzy logic and engineering applications and
computer engineering (hardware and software). His current
research is in applications of software engineering methods,
computer architecture, embedded systems, fuzzy systems,
real time systems and artificial intelligence. Dr. Shaout has
more than 33 years of experience in teaching and conducting
research in the electrical and computer engineering fields at
Syracuse University and the University of Michigan -
Dearborn. Dr. Shaout has published over 175 papers in
topics related to electrical and computer engineering fields.
Dr. Shaout has obtained his B.Sc., M.S. and Ph.D. in
Computer Engineering from Syracuse University, Syracuse,
NY, in 1982, 1983, 1987, respectively.
Dr Arafat Awajan is a full professor at Princess Sumaya
University for Technology (PSUT). He received his PhD
degree in computer science from the University Of France-
Comte France in 1987. He held different academic positions
at the Royal Scientific Society and Princess Sumaya
University for Technology. He was appointed as the chair of
the Computer Science Department (2000-2003) and the chair
of the Computer Graphics and Animation Department (2005-
2006) at PSUT. He had been the dean of the King Hussein
School for Information Technology from 2004 to 2007, the
Dean of Student Affairs from 2011- 2014 and the director of
the Information Technology Center in the Royal Scientific
Society from 2008-2010. His research interests include e-
learning, natural language processing, text compression, and
image processing. He is currently the dean of the King
Hussein School for computing Sciences at PSUT.
