This article has been accepted for publication in a future issue of this journal, but has not been

fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/TIE.2014.2321342, IEEE Transactions on Industrial Electronics

IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS 1

Development of Autonomous Car

– Part I: Distributed System Architecture and
Development Process
Kichun Jo, Member, IEEE, Junsoo Kim, Student Member, IEEE, Dongchul Kim,
Chulhoon Jang, Student Member, IEEE and Myoungho Sunwoo, Member, IEEE

 car has to perceive driving environments, and should also

Abstract—An autonomous car is a self-driving vehicle that has perform path planning and control without human intervention.
the capability to perceive the surrounding environment and For the development of these autonomous driving
navigate itself without human intervention. For autonomous technologies, the Defensive Advanced Research Projects
driving, complex autonomous driving algorithms, including
perception, localization, planning, and control, are required with
Agency (DARPA) opened the Grand and Urban Challenge
many heterogeneous sensors, actuators, and computers. To competitions in the USA. The Grand Challenge competition
manage the complexity of the driving algorithms and the focused on the development of autonomous cars which can
heterogeneity of the system components, this paper applies traverse off-road terrain by themselves [1]. Based on the results
distributed system architecture to the autonomous driving system, of the Grand Challenge, the Urban Challenge competition
and proposes a development process and system platform for the aimed at the advancement of autonomous cars with urban
distributed system of an autonomous car. The development
process provides the guidelines to design and develop the
driving technology [2]. Through both of these competitions, the
distributed system of an autonomous vehicle. For the feasibility of the autonomous car realization has been
heterogeneous computing system of the distributed system, a confirmed. As a result, global automakers and IT companies
system platform is presented that provides a common such as GM, Volkswagen, Toyota, and Google have made an
development environment by minimizing the dependency between enormous investment in the commercialization of autonomous
the software and computing hardware. A time-triggered network cars.
protocol, FlexRay, is applied as the main network of the software
platform to improve the network bandwidth, fault tolerance, and
In Korea, in order to stimulate autonomous car research, two
system performance. Part II of this paper will provide the autonomous vehicle competitions (AVC) were held in 2010
evaluation of the development process and system platform by and 2012 by the Hyundai Motor Group. The purpose of the
using an autonomous car which has the ability to drive in an 2010 AVC was to establish the foundation of autonomous
urban area. driving technology in Korea. The missions of the 2010 AVC
concentrated on waypoint tracking and static obstacle
Index Terms—Autonomous car, distributed system, avoidance. Based on the fundamental technology, the 2012
development process, system platform, FlexRay
AVC tried to develop techniques for urban driving
environments; the missions were related to urban driving such
I. INTRODUCTION as traffic signal detection, overtaking, crosswalk stops, and
passenger detection and so on. This paper is based on the results
T ODAY, a paradigm in the automotive industry has been
shifted from high-performance vehicles to safe and
comfortable vehicles. This paradigm shift has accelerated the
of the 2012 AVC.
Developing an autonomous car refers to the integration of
technologies from two industry fields: the automotive industry
development of various intelligent vehicle technologies. and the mobile robot industry. The robust and reliable
Ultimately, maximizing safety and comfort can be achieved by mechanical and electrical platform for the autonomous car can
autonomous cars. In order to realize autonomous driving, the be achieved from the automotive industry. Many autonomous
driving algorithms have been researched for a long time in the
Manuscript received November 27, 2013; revised February 22, 2014;
accepted April 1, 2014.
robot industry, and they can be applied to the autonomous car.
Copyright © 2014 IEEE. Personal use of this material is permitted. However, Each industry field has their own environments in which to
permission to use this material for any other purposes must be obtained from develop an intelligent vehicle system. In the automotive
the IEEE by sending a request to [email protected]. industry, there are many standard development platforms
This work was supported by an NRF grant funded by the Korean
government (MEST) (No. 2011-0017495), Industrial Strategy Technology because the automotive industry consists of manufacturers and
Development Program of MKE (No. 10039673), and BK21 plus program suppliers. In order to communicate and cooperate with each
(22A20130000045) under the Ministry of Education, Republic of Korea. other, standard software and hardware platforms are essential.
The authors are with the Automotive Control and Electronics Laboratory
(ACE Lab), Department of Automotive Engineering, Hanyang University, AUTomotive Open System ARchitecture (AUTOSAR) is
Seoul 133-791, Korea (e-mail: [email protected]; [email protected]; standardized software architecture in the automotive industry
[email protected]; [email protected]; [email protected]). [3, 4]. AUTOSAR is based on a component-based software

0278-0046 (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/TIE.2014.2321342, IEEE Transactions on Industrial Electronics

IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS 2

design model and provides the design methodology and II. DISTRIBUTED ARCHITECTURE FOR AUTONOMOUS CARS
standard software platform for designing automotive software.
A. Basics of Autonomous Cars
OSEK/VDX is a standard real-time operating system (RTOS)
for automotive embedded software. LIN, CAN, FlexRay, and An autonomous car is a self-driving car that has the ability to
MOST are developed for the in-vehicle network of cars [5]. drive by itself without human intervention. There are five basic
Although standard platforms are useful for developing functions that drive the autonomous car: perception,
automotive systems, there are some limitations that apply for localization, planning, control, and system management. The
developing autonomous cars. Since the automotive industry is conceptual description of each function is shown in Fig. 1.
very conservative regarding the safety and robustness of the Perception is a process that senses the surrounding environment
system, it is not flexible for changes and additions of of the autonomous car using various types of sensor techniques
technologies. However, the investigation of automotive car such as RADAR, LIDAR, and computer vision. The
technologies is in progress, and many technical attempts will localization finds the position of the autonomous car using the
occur for autonomous driving systems. techniques of a GPS, dead-reckoning, and roadway maps. The
In the robot industry, development environments and system planning function determines the behavior and motion of the
platforms were researched and developed for a long time in autonomous car based on the information from perception and
order to manage the complexity of an autonomous robot system localization. The control function follows the desired command
[6-8]. The complexity of a robot system originates from the from the planning function by steering, accelerating, and
interaction between numerous heterogeneous sensors, braking the autonomous car. Finally, the system management
computers, and actuators. There are also many other reasons to supervises the overall autonomous driving system. The
use the robot development environment and platform such as example functions of the system management are the fault
promoting the integration of new technologies, simplifying management system, logging system, and human-machine
system design, abstracting the low-level components, interface (HMI).
improving software quality, and reusing software. Some of Almost all autonomous cars have the five basic functions,
these development environments are freely available and and each function has different functional sub-components
provide excellent functions. Therefore, developers can easily according to the purpose and complexity of the autonomous car.
access the robot development environments and platforms. The functional sub-component represents the actual
However, since the robot development environments and implementation of autonomous driving functions as shown in
platforms lack support for automotive technologies such as the Fig. 2. In order to implement the functional components on
OSEK/VDX, CAN, and FlexRay, their application towards the computing units of autonomous car, there are two types of
developing autonomous cars is limited. approaches: centralized architecture and distributed
This paper proposes a development process and system architecture [9].
platform to develop an autonomous car that has distributed Planning
system architecture. The process and platform are based on the Vehicle Control
. Longitudinal
methodology and platform of AUTOSAR; however, in order to . Lateral

improve the flexibility and scalability of the development of an

autonomous driving system, unnecessary processes of
AUTOSAR are discarded and reformed. Also, the FlexRay,
which is the next generation in-vehicle network in the
automotive industry, is applied for the back-bone network of
Localization Perception
the system platform in order to increase network bandwidth, . Vision
System management . LIDAR
fault tolerance, and system performance. The proposed . HMI . RADAR

development process and system platform are evaluated . Logging

. Fault management

through autonomous car A1 which participated in the AVC Fig. 1. Basic functions of autonomous cars
2010 and AVC 2012. A1 successfully completed all missions P: Perception task
C: Control task
of the AVCs, and won in 2010 and 2012 as well. Perception L: Localization task
S: System management task
This paper is organized as follows: Section II introduces the PL: Planning task
P1 P2 P3
distributed system architecture for the development of an
autonomous car; the development process of the distributed Localization Control

system is described in Section III; the system platform is L1 L2 L3 C1 C2 C3

explained in Section IV. Part II of the paper will present the Autonomous
autonomous driving algorithm of A1 and the algorithm Car
implementation based on the proposed process and platform.
System
Planning
The benefits of the process and platform will be discussed using Management

implementation results of autonomous car A1. S1 S2 S3 PL1 PL2 PL3

Fig. 2. Functional components of the autonomous driving system

0278-0046 (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/TIE.2014.2321342, IEEE Transactions on Industrial Electronics

IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS 3

B. Centralized System Architecture efficiency of the system can improve. The decentralized
In the centralized system architecture, most functional computational architecture can also increase the computational
components of the autonomous driving system are performance of entire system due to the parallel computation of
implemented into a single computing unit. All of the sensors the independent algorithm modules.
and actuators of autonomous driving system are connected into Fault management of the autonomous driving system can
the single centralized computing unit, as shown in Fig. 3. The become more convenient by using the distributed system
centralized system architecture has the benefit of simplifying architecture. Safety is the most important factor for operating
the system configuration because all of the devices including and developing an autonomous driving system. If the
the sensors and actuators are connected to the centralized autonomous system uses only a single computing unit to
computing unit. It is also possible to share information without operate all of the functions of the autonomous driving, it can be
an additional network, and there is minimum delay and very dangerous if the single computing system fails due to the
information loss due to the communication. hardware or software. Since the distributed autonomous driving
In contrast to the benefits, the centralized system has several system consists of several computing modules, each
weaknesses in many ways. First of all, the centralized system sub-module can check the health status of other computing
requires a high computational capability because the algorithms modules and backup the failed function.
of the autonomous driving system may be large and The noise and cost of wiring can be reduced by optimally
complicated. The centralized architecture may also lack positioning the distributed computing units. In order to
scalability. Even if there are any functions or devices that minimize noise problems, various grounding and shielding
should be added to the centralized system, a developer should techniques are applied, such as single point grounding,
consider various constraints including computational abilities, capacitive shielding, twisted wiring, cabling length
hardware capabilities, and installations. Moreover, it is hard to optimization and so on. Among these techniques, the cabling
guarantee reliable fault tolerance since building a backup length optimization is important for preventing electromagnetic
system and handling a malfunction are not easy for the noise in analog signals. In the cabling length optimization, the
centralized system architecture. Furthermore, since all sensors distributed system is more advantageous than the centralized
and actuators are attached to the central computing unit, wire system because of the configurable placement of computing
harnesses may become longer thereby causing unexpected units. Furthermore, the shorter length of the cable for
weights and noises. Lastly, in regards to the development and transferring signals from the sensors/actuator has the benefit of
test, collaboration is very difficult for the centralized system reducing the cost and weight of cables and preventing
because the developers cannot access the development and test electromagnetic noise.
environment concurrently. Each module of the autonomous system can be developed,
tested, and maintained independently through the distributed
system architecture. If the autonomous driving algorithm is
L1
Sensor 1 PL2 S3 P3 Actuator 1 implemented into a single computing module, it is impossible
Sensor 2
P2
C1
Actuator 2
for developers to access the development system at the same
P1

Sensor 3
time. Additionally, modification of local software modules may
Actuator 3
L3 C3
affect the reliability of the entire system due to the unexpected
C2
dependency of each module. The distributed system
PL3 L2
S2
S1
architecture can solve the dependency problem of the single
PL1
computing system by decentralizing and encapsulating it into
Sensors Computation unit Actuators local sub-computing modules. Developers can develop and test
Fig. 3. Centralized system architecture for an autonomous car each sub-module independently and concurrently; therefore,
the development efficiency can be improved and the stability of
C. Distributed System Architecture
the unit module can be ensured.
In the distributed system architecture, the functional The encapsulation of the sub-system module facilitates the
sub-components of the autonomous driving system are maintenance and extension of an autonomous driving system.
implemented into several local computing units, as shown in Changes to sensor configurations and required functions can
Fig. 4. Information from each computing unit is shared with the frequently occur depending on the changes to the required
common communication system. There are many benefits of mission. In the case of the centralized system, if a partial
the distributed system architecture compared to the centralized replacement or upgrade is needed for part of autonomous
system architecture. driving system, the entire system should be updated and tested.
The computational complexity of the system can be reduced However, in the case of the distributed system architecture,
through the distributed system architecture. The overall there is no need to update and test the entire system for a partial
autonomous driving algorithm can be large and complex replacement. The sub-modules that need maintenance are the
depending on the mission objectives; therefore a single only ones required to be updated and tested.
computation unit may not be enough to cover all of the
computations. By decentralizing the computational load into
the sub-computing modules, the computational stability and

0278-0046 (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/TIE.2014.2321342, IEEE Transactions on Industrial Electronics

IE
EEE TRANSA
ACTIONS ON
N INDUSTRIA
AL ELECTRO
ONICS 4

Sensor 1 Actuator 1 Actuator 2 Actuator 3 Sensor 2 A standard AU UTOSAR is used to devvelop automootive
prodducts with automobile manufacturerss and supplliers;
Computation unit 1 Computattion unit 2 Computation unit 3
subssequently, theere are manyy standard rulles and interffaces
L2
PL2
P2
S3 PL3 C
C2 S2
PL1
S1
avaiilable to hellp produce reeliable autom mobile parts with
minnimum defects. These stanndard rules and a interfacess are
mannaged with a standard desccription file eestablished byy the
Co
Communication syst
stem AUTOSAR consoortium. The deescription file should includde all
Computation unit 4 Computattion unit 5
the configurationns of the distributed system m. Subsequentlly, it
P1
contains large amounts of detailed info formation on the
L1
L3 C3 P3
3
C1
autoomotive disttributed systtem that inncludes softw ware
commponents descrription, system m constraints description,
d syystem
Sensor 3 Sensor 4
resoources descripttion, and ECU U configurationn description [[3, 4].
Figg. 4. Distributed system architectuure of autonomous cars Theese highly dettailed descripttion files are acceptable forr the
mannufacture of hhigh reliabilityy automobile products;
p howeever,
D.. Necessity off a Developmeent Process annd Common
therre is a large ovverhead cost w when it is applied to autonom mous
Sooftware Platform for the Disstributed Systeem Architecturre
car research. New w studies on autonomous ddriving algoritthms
Although thee distributed system has many benefiits for andd system archiitectures will result in flexxible changes and
deeveloping an aautonomous caar, it also has some drawbaacks to systtem structure extensions.
e
bee improved uppon. First, thee functional cconfiguration of the A commercial development
d t
tool chain willl be indispenssable
distributed systtem is not sim mple because it should coonsider to mmanage all thhe descriptionn files and foollow the stanndard
many constrainnts, such as the computinng power off each
m metthodology of AUTOSAR. However, a AUTOSAR tool
coomputer moddule, charactteristics of the networkk for chaiin is too expennsive to purchhase by small scale laboratoories,
coommunication, and the locattion of sensorrs/actuators. Seecond, andd there are com mpatibility probblems betweenn the differentt tool
coompatibility prroblems can ooccur when thhe different tyypes of chaiins. In order too solve this prroblem, previoous studies [100-13]
coomputing unitss and operatinng environmennts are used ffor the propposed a lighht weight vversion of AUTOSAR A called
different sub-syystem moduless of an autonom mous driving ssystem. AUTOSAR-Lite. AUTOSAR-L Lite reduces overhead
o problems
Fiinally, netwoork delay and jitter of the common caussed by excesssive standard AUTOSAR sspecifications that
coommunication systems mayy decrease the entire perform mance retaains the advaantages of AU UTSAR suchh as a scalabbility,
off the driving syystem. re-uusability, reliabbility, and trannsferability. Although
A this sstudy
In order to address the problems of distributed ssystem onlyy considers sinngle ECU com mponents for eengine control , the
arrchitecture, thiis paper propposes a develoopment processs and concept of reduceed AUTOSAR R can be applied to developp the
coommon softw ware platform m for develooping a distrributed disttributed systemm of autonomoous car describbed in this papper.
auutonomous drriving system m. The com mplex configuuration Inn this study, a system develoopment processs and platform m are
prroblem of the distributed syystem architectture is simpliffied by introoduced for the t flexible and stable ddevelopment of a
ussing the proposed developpment processs which consiists of disttributed systemm for an autonnomous car. T The process addopts
three steps: sooftware compponent design, computingg unit the advanced devvelopment meethodology annd the AUTOSAR
mapping, and iimplementatioon of functionn. The compattibility
m softtware platform m as well ass improves thhe system deesign
prroblem of diffferent computting units in a distributed ssystem flexxibility, omits overhead proocesses such as a large amounnt of
caan be solved ussing a commonn software plaatform. Furtherrmore, stanndards, docum mentation for system descriiptions and deesign
to minimize thhe problem oof network deelay and jitteer, the tooll chains.
sooftware platfoform supportts the time--triggered prrotocol
(F
FlexRay). The detailed conttents of the development
d pprocess
annd software plaatform will bee explained in Sections III annd IV.

III. DEVELO
OPMENT PROCESS FOR DISTR
RIBUTED SYST
TEM

A. AUTOSAR
motive field, thhere is an opeen and standaardized
In the autom
auutomotive softtware architeccture named A AUTOSAR (F Fig. 5).
Thhe AUTOSAR R is based oon a componnent based software
deesign model foor developing vehicular sofftware, and provides
the methodologgy for designing the autom motive softwaree. The
gooals of the A
AUTOSAR arre scalability of the softw ware to
different vehiclle and platform m variants, trransferability of the
syystem functioons throughouut the netwoork, integration of
fuunctional moddules from vaarious suppliers, maintainnability
throughout the w whole producct life cycle, sooftware updattes and
Fig. 5. AUTOSAR Software Architectture
uppgrades over thhe product’s liifetime [3, 4].

0278-0046 (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/TIE.2014.2321342, IEEE Transactions on Industrial Electronics

IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS 5

B. Development Process for Distributed System Development virtual functional bus (VFB), which is an abstraction of the
of Autonomous Car communication.
The development methodology of standard AUTOSAR is The VFB has two types of communication. One of the VFBs
highly dependent on standard description files that have a strict is a client-server communication. The client is a
template with an XML format. However, generating a standard service-requester, whereas the server is a service-provider
description file requires significant work and an expensive tool which waits for incoming requests from any client. The other
chain, it is not acceptable for the products being researched that type of communication is a sender-receiver. The sender does
frequently change are needed for their specifications and not know how many receivers are in the network, and provides
system structures. Therefore, the proposed development the information without any requests. In general, the type of
process for the distributed system of an autonomous car VFB chosen depends on the requirements of the
advocates the philosophy of AUTOSAR development communication system.
methodology; however, strict description rules are mitigated The consideration of the hardware and network can be
for development costs and flexibility. The developers focused excluded by using the VFB. Therefore, the software component
on the main idea and key algorithm of the autonomous driving developer can concentrate on designing the functional elements.
system with simple document files engaged in the research The abstraction of the hardware and network also helps the
group instead of following the complex descriptions of developer to flexibly cope with changes to hardware and
AUTOSAR. The development team can designate the network specifications.
document rules according to the nature of developments. Fig. 7 depicts an example of the software component design
The development process which is reduced version of the that includes two sensors, one control, and one actuator. For
AUTOSAR development methodology can be summarized into: each software component, individual runnables are pre-defined
software component design, computing unit mapping, and as S1 to S5, C1 to C2, and A1. Next, data flows are determined
function implementation (see Fig. 6). The main advantage of using VFB. The VFB of Fig. 7 shows that the results of two
the development process is that it can provide a common design sensor acquisitions are conveyed to the control unit and that the
approach to develop a distributed system. actuator receives commands from the control unit.

Software Software Software Software

Sensor 1 Sensor 2 Control Actuator
Component 1 Component 2 Component 3 Component n
SW-C SW-C SW-C SW-C
PL2 P2 S3 PL3 C2 S2 L2 PL1 S1 P# L# C#
S1 S2 S3 S4 S5 C1 C2 A1

Type 1: Server/Client
Virtual Functional Bus

Type 2: Sender/Receiver Virtual Functional Bus Fig. 7. Example of the soft component design including two sensors, one
control, and one actuator
Mapping

D. Computing Unit Mapping

Computer Unit Topology The designed software components should be assigned to
each distributed computing unit. In order to map the software
components into the computing units, the software designer
Implementation empirically deploys the software components. There are several
guides or constraints to assign the software components;
ECU 1 ECU 2 ECU #
SW-C 1 SW-C 2 SW-C 2 SW-C n
however, we consider the following.
PL2 P2 S3 PL3 C2 S2 L2 PL1 S1 P# L# C# First, a computing unit in charge of the sensor or actuator
RTE RTE RTE should be installed adjacent to the device and contain specific
Basic Software Basic Software Basic Software software components to operate the device. Second, all mapped
software components in one computing unit should work at a
pre-scheduled time. Third, some software components might
Fig. 6. Development process for distributed system of an autonomous car
have an operating system dependency due to device interfaces
or available libraries. Fourth, the amount of information
C. Software Component Design exchanged between different computing units should not
The software component represents the encapsulated part of exceed the network capability. Finally, the available hardware
the functionality in the autonomous driving application. At the peripheral is limited according to the type of computing unit;
software component design step, the software components of for instance, a universal serial bus (USB) might not be available
the autonomous driving functions are designed and the flow of for the embedded computing unit.
information between the components is defined. The Fig. 8 shows that the computing unit mapping methodology
connection for sharing information between the software is applied for the previous example. Four software components
components, sensors, and actuators can be defined by using a can be integrated into two computing units after considering

0278-0046 (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/TIE.2014.2321342, IEEE Transactions on Industrial Electronics

IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS 6

hardware installations, execution time for all software IV. SYSTEM PLATFORM
components or other constraints. Various types of computing units can be utilized for the
Optimization techniques can be applied to the computing distributed system of an autonomous car. The each computing
unit mapping problem in order to optimally assign the software unit operates on different operating systems (OS) and hardware
components to the computing units [14, 15]. However, the peripherals. Therefore, the developers of the autonomous
current optimization method has the limitation that it cannot driving functions should be familiar with the development
consider all types of mapping constraints. Therefore, in this environment of the corresponding computing unit and OS.
study, the software component mapping is dependent on the However, when the functions implemented on a computing unit
experience of the software designer. In future work, the authors have to move to another type of computing unit due to a change
plan to develop an efficient optimization method for the in system requirements, it will take long time for developers to
computing unit mapping problem. transfer the functions to the changed computing system and to
adapt to the new computing development environment. To
Sensor 1 Sensor 2 Control Actuator improve the reusability of the software functions and provide a
SW-C SW-C
SW-C SW-C
consistent development environment, a common system
S1 S2 S3 S4 S5 C1 C2 A1
platform for each local computing unit is necessary.
The system platform of the distributed system architecture
Computing Unit Mapping can be classified into a software platform and an in-vehicle
Sensor 1
network. The software platform provides a common software
development environment that minimizes the dependence of
Computing Unit #1 Sensor 2 Computing Unit #2
Actuator the software on the hardware and OS. Therefore, the developer
can achieve the reusability, reliability, transferability, and
Fig. 8. Example of computing unit mapping
maintainability of the software. The network platform allows
the distributed system to share the information for autonomous
E. Implementation of Functions driving hardware independently.
The software components should be implemented into an A. Structure of Software Platform
assigned computing unit platform by considering the
The proposed software platform follows the basic
computing performance, operating system, sensor and actuator
AUTOSAR concepts described in Fig. 5. The overall
interface, and network. Therefore, the implementation of the
AUTOSAR software structure contains too many constraints
software components may depend on the characteristic of the
for the creative and flexible development of an autonomous car,
computing unit platform; this dependency can increase the cost
that includes the limits of a standardized interface with huge
of the implementation and maintenance of the software. To
amounts of configuration parameters and functions that use
minimize the dependency problem of the software components,
standardized templates. The AUTOSAR standard was
a common software platform which can apply to different
developed for an automotive embedded system and it cannot
computing units should be developed.
support a general computing system. The proposed software
The common software platform is located between the
platform omits standards parameter configuration and auxiliary
application software components and the computing unit
functions that overcome the AUTOSAR limitations. Instead, it
hardware in order to isolate the impact of the hardware and
focuses on interface functions and adopts a general OS for
network on the software components, as shown in Fig. 9. The
system flexibility; subsequently, the proposed software
independence of the software platform can improve the
platform reduces the AUTOSAR overhead and follows the
reusability, transferability, scalability, and maintainability of
basic philosophy of the AUTOSAR.
the software, and reduce the development cost. In this paper, a
common system platform for a distributed system of
Application Layer
autonomous cars is proposed for the independency of the
Software Component Software Component Software Component
hardware and software. The structure details of the software
Runnable
platform and in-vehicle network will be introduced in the next Runnable
Runnable
chapter. Runnable
Runnable
Runnable
Software Software Software Software Software Software
Component Component Component Component Component Component
3 4 5
1 2 6

Run Time Environment (RTE)

Software Platform Software Platform Software Platform

Operating Communication I/O Hardware Complex

System Abstraction Driver
Computer 1 Computer 2
Computer 3 (Window 7,
Linux, FlexRay CAN GPIO DAC
OSEK/VDX)
Ethernet Serial PWM ADC

Fig. 9. Implementation of software components based on the software platform Computer Hardware

Fig. 10. Software architecture for a computing unit

0278-0046 (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/TIE.2014.2321342, IEEE Transactions on Industrial Electronics

IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS 7

specifications.
The software platform of the distributed system for an The RTE also provides the scheduler mapping function for
autonomous car is a layered architecture as described in Fig. 10. the application software components in the application layer.
There are three layers: the application layer, run-time At the RTE layer, the runnables of the application software
environment (RTE) and basic software layer. The application components are assigned the task of scheduler in the OS of the
layer contains the implementation of software components. The basic software layer. Therefore, the multiple runnables of the
basic software layer is a hardware-dependent layer and consists software component can execute concurrently due to the
of the OS, communication modules, input and output (I/O) scheduling algorithm of the OS.
hardware abstraction module, and a complex driver. The RTE An RTE layer is adopted in the proposed software platform
lies in the middle of the application layer and basic software with significant advantages carried over. However, the
layer in order to remove the dependency of the software proposed software platform only focuses on the port and
components from the hardware and networks. interface functions for the implementation of the RTE.
Additional standard AUTOSAR functions (such as trace and
1) Application Layer debug mode) are excluded. Commercial development tools for
The basic concept of application layer design is a software RTE configuration are not required and developers can directly
components based design that is identical to AUTOSAR implement the RTE code with a simple configuration. In
standards. Software components assigned to a certain addition, code complexity, processor overhead and memory
computing unit are implemented in the application layer of the requirements can also be reduced.
software platform. At this layer, only the structure of the I/O
interface and functional elements are focused on to implement 3) Basic Software
the software components, the information sources of the I/O, Basic software components in the basic software layer are
such as networks, computing unit hardware I/O, and other dependent on computing unit hardware and network
software components, are not considered. Therefore, a software specifications. The implementation of the basic software differ
component in the application layer is independent to the according to type of computing unit; subsequently, there are
hardware, networks and other software components. This many complicated configurations with standardized parameters
component-based software development architecture allows in AUTOSAR to meet this requirement. In addition, the
the developed software to be scalable and transferable to other standard basic software configurations only cover embedded
computing platforms. system applications. However, high performance general
One software component is implemented as a single software computing systems are essential to develop autonomous
module. The software module is composed of several runnables driving systems. To overcome the limitations of AUTOSAR
that are the smallest schedulable units of the software. One standards, the proposed software platform focuses on basic
software module for the software component can contain software port and interface functions as well as allows a
multiple runnables to execute the corresponding functions. The general-purpose OS for system flexibility and performance.
runnables are described in the single member function of the The basic software layer consists of four types of basic
software module. software components; these are the OS, communication,
hardware I/O abstraction, and complex driver. The OS software
2) Run-Time Environment (RTE) components provide the scheduler for the runnable of the
In the AUTOSAR standards, the RTE, the runtime software components. The different computing units of the
representation of a VFB, is a communication center of the distributed system use a different OS. The embedded
software platform. Each of the application software microcontroller uses the OSEK/VDX RTOS which is widely
components in the application layer can communicate to each applied to the automotive embedded system. The industrial
other through the RTE. The application software component high-performance computing unit uses Windows and Linux
can also exchange information with other computers, sensors, OSs for the scheduler. The communication software
and actuators through basic software components such as the component provides the common interface of the network such
network and I/O hardware drivers. The RTE provides a as the FlexRay, CAN, LIN, and Ethernet. The I/O hardware
connection between the application layer and the basic software abstraction component provides the common interface of the
layer. I/O peripherals such as the general purpose digital input and
Furthermore, to minimize the dependency of the application output (GPIO), pulse width modulation (PWM), digital to
software component on the hardware, network, and other analog converter (DAC) and analog to digital converter (ADC).
software components, the RTE abstracts the communication The purpose of the complex driver is implement complex
interface of the software components in the application layer sensor evaluation and actuator control of a non-AUTOSAR
and basic software layer. The RTE provides the same interface system. The complex driver provides an interface that directly
and services whether the communication is between application accesses hardware that includes complex microcontroller
software components or between an application software peripherals and external devices. The functions can also be
component and the basic software components. Therefore, the implemented in the complex driver component if there are
software components in the application layer can be designed hardware specific-functions that cannot be abstracted with a
without consideration of the hardware and network common interface. Therefore, software components can handle

0278-0046 (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/TIE.2014.2321342, IEEE Transactions on Industrial Electronics

IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS 8

the hardware via RTE using the complex driver interface. transmission and reception can be predictable.
We can implement all functions of each computing unit by Finally, the dual channel mode and active star topology of the
applying the software platform (see Fig. 11). Applications in FlexRay network enhance the fault tolerance of the system. In
charge of sensing are built in the application layer of the the dual channel mode, one channel can be configured as a
computing unit #1 and the control algorithm is placed in the replication of the other channel. This configuration is used for
application layer of the computing unit #2. The software checking for fault in received information and hardware backup.
platform provides sensing or control interfaces for the Active star topology of the FlexRay consists of several
application layer. individual branches connected to a center active star node. The
active star node can block error propagation from a failed
Computing Unit #1 Computing Unit #2 branch.
Application layer Application layer

Sensor
Acquisition 1
Sensor
Acquisition 2
Sensor
Integration
Controller 3) Basic Principle of FlexRay Protocol
RTE RTE
The FlexRay network protocol is based on a communication
cycle which repeats periodically with a fixed length as shown in
Basic Software Basic Software

OS
Complex Complex
Comm. OS Peripheral Comm.
Fig. 12. The communication cycle consists of a static segment,
Driver 1 Driver 2
a dynamic segment, a symbol window, and a network idle time
Sensor 1 Sensor 2 Actuator (NIT). The static segment is divided into the same length of
static slots. At each slot, nodes of the FlexRay network send
Fig. 11. Example of implementation of functions messages in a time division multiple access (TDMA) manner.
In the dynamic segment, event triggered messages with priority
are sent by using the flexible TMDA (FTDMA) method. The
B. In-vehicle Network
symbol window is used for network management, and the NIT
1) Requirements of Network for Autonomous Cars is the time correction period at each node to synchronize the
A network used for the distributed system of an autonomous
global time of the FlexRay network.
car has three requirements: high bandwidth, deterministic
characteristics, and fault tolerance. The high bandwidth is an
4) Design of FlexRay Network
essential property of the network for an autonomous car The FlexRay network design is divided into two steps, one is
because sensors and computing units of autonomous cars network parameter configuration and the other is network
generate a large amount of information. It is strongly message scheduling.
recommended that the maximum message delay for the Communication cycle length

network is predictable (deterministic), since an autonomous car Static segment length Dynamic segment length

is a safety-critical system. The network of safety-critical Static Slot 1 … Static Slot n Mini Slot 1 … Mini Slot n
Symbol
NIT
Window
systems should transfer information within a maximum
admissible delay, called the deadline. If the maximum delay of Static Slot
length
Network
Idle time length
the message exceeds the deadline, it can be directly related to
Fig. 12. FlexRay network protocol
degradation of the system performance. Finally, the network of
the autonomous driving system should be fault tolerant. The
The parameters of the FlexRay network should be configured
network of the distributed system should be able to detect the
properly in order to take advantage of the previously described
network failure and have a back-up system to recover from it.
FlexRay network protocol. There are several commercial tools
for configuring FlexRay that check fault configuration based on
2) Advantages of FlexRay Network
the parameter value constraints in the FlexRay protocol
FlexRay is a time-triggered protocol that has emerged as the
specification. However, the tools do not provide optimal
next generation network of the automotive industry [16, 17].
parameter configuration for optimal network utilization
The FlexRay network protocol has all of the characteristics
because the optimal configuration is a difficult problem to solve
required for network of autonomous cars. The FlexRay
due to the over 70 parameters and the complex relationships.
provides high bandwidth for the autonomous driving system.
There are previous studies for design optimization methods for
Since the FlexRay has a robust physical layer which uses a
the configuration of FlexRay parameters.
twisted pair cable with differential signaling, it can reduce the
A general FlexRay response time model is defined by a
effect of external noises and provide reliable high bandwidth up
heuristic method based on a FlexRay timing model [18]. This
to 10 megabits per second.
model analyzes the worst-case response time of each message
In addition, the FlexRay offers a deterministic characteristic.
and optimal FlexRay parameters are established to minimize
The determinism of the FlexRay network protocol is realized
the worst-case response time. However, the optimal
by a global timer which can be used as a common clock by all
configuration using this method can waste network resources
nodes in the FlexRay network. Based on this global time,
because this method does not consider network utilization.
network messages are sent by using the time division multiple
Another method focused on the configuration of optimal
access (TDMA) method. Because the TDMA method sends
static slot length and communication cycle length which are
each message at a specified time, the time of the message
highly related to the temporal behavior of the application

0278-0046 (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/TIE.2014.2321342, IEEE Transactions on Industrial Electronics

IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS 9

system [19-21]. Two parameters are optimized by minimizing V. CONCLUSION

the protocol overhead, wasted network resources, and This paper presents the development process and system
worst-case response time. This method can be applied to an platform for the development of the distributed system of an
event-triggered system because the system model is not autonomous car. A distributed system architecture is used for
constrained to the synchronization of application software and the system platform because it has many benefits for
communication. The proposed method is suitable to apply to developing an autonomous driving system, such as reduction of
development of autonomous cars since they have an the computational complexity of the entire system,
event-triggered system such as emergency stop and fault fault-tolerant characteristics, and modularity of the system. The
management. However, this method requires an unchangeable development process provides the guidelines to design and
fixed network configuration. Applying this method in the early integrate the distributed systems of an autonomous car. A
steps of autonomous car development is unsuitable because the layered architecture based software platform, which originated
network configuration can be frequently modified due to from AUTOSAR, is applied to the distributed system in order
system configuration changes. Thus, we recommend applying a to improve the reusability, scalability, transferability, and
heuristic configuration of FlexRay parameters (suitable for the maintainability of the application software. A FlexRay network
frequent modification of a network configuration) before the is applied for the main network of the software platform in
network configuration is fixed. After the system configuration order to improve the network bandwidth, fault tolerance, and
system performance. In part II of this paper, the development
is stabilized, the optimal configuration of FlexRay parameters
process and system platform presented will be verified with the
is acceptable with a fixed network configuration using the
autonomous car A1 which is the winner of the AVC 2010 and
second method.
2012.
In the second step, network messages are scheduled to The development process of this paper consists of three steps:
synchronize with the application software based on the component design, computing unit mapping, and
following process. First, a sequence of the application software implementation. Among these, the second step, computing unit
execution is defined. This is already done by the software mapping, can have a significant impact on the development
component design step using the VFB. Second, the execution cost, period, and system performance [14, 15]. However, the
time of the application software is estimated. There are several mapping process presented in this paper relies solely on the
methods such as the measurement based approach, static experience of the designers. Therefore, in the future the authors
analysis, and using commercial tools to estimate the execution are planning to develop an optimization algorithm for mapping
time [22]. In this paper, the execution time is directly measured the application software components to the distributed
by an oscilloscope, because measurement is a simple and computing units.
practical method. Finally, the network messages are scheduled The proposed development process and platform for the
in a static slot within the application software. The application reduced version of the AUTOSAR may be unsuitable for mass
software is arranged in order of execution sequence. The product applications because it omits many standard
arranged application software is represented based on the AUTOSAR components related to product reliability. However,
global time of the FlexRay using the measured execution time. the proposed compact development process and platform has
After this, the application software and messages are scheduled advantages that can improve the degree of freedom for the
to start execution right after receiving the results from the distributed system design and speed up the development
preceding application software. process. The proposed method is more acceptable for
An example of message scheduling is depicted in Fig. 13. In developing prototype products that require flexible changes and
this example, the application software is executed in the an extension of the system structure. The proposed
following order: three sensor components, one computation development process and platform can be applied to many other
component, and one actuator component. The application industrial fields that have distributed system architecture and
software is represented in the global time with execution time require a system feasibility check through rapid prototyping,
as shown in Fig. 13. In the last step, messages from sensor such as unmanned airplanes, unmanned submarines, distributed
components are allocated in slots 2, 3, and 4, which are robot systems, and factory automation.
synchronized with the end of the execution of each sensor
component. The result of the computation component is sent to
slot 8 in same manner as the sensor messages. REFERENCES
Sensor 1 Sensor 2 Sensor 3 Algorithm Actuator [1] S. Thrun, M. Montemerlo, H. Dahlkamp, D. Stavens, A. Aron, J.
Tx slot # 2 3 4 8 FlexRay bus Diebel, et al., "Stanley: The robot that won the DARPA Grand
Sense
Challenge," J. Field Robot., vol. 23, pp. 661-692, 2006.
Sense
Sense Sense
[2] C. Urmson, J. Anhalt, D. Bagnell, C. Baker, R. Bittner, M. N. Clark,
Sense Sense et al., "Autonomous driving in urban environments: Boss and the
Cycle
Compute Compute urban challenge," J. Field Robot., vol. 25, pp. 425-466, 2008.
Act Act
Start
Event
[3] S. Bunzel, "AUTOSAR–the Standardized Software Architecture,"
Informatik-Spektrum, vol. 34, pp. 79-83, 2011.
2 3 4 8 2 3 4 8 [4] "AUTOSAR Documents (V4.1)," AUTOSAR Consortium, vol.
Static Segment Static Segment
Cycle n Cycle n + 1
http://www.autosar.org/, 2013.
[5] N. Navet, Y. Song, F. Simonot-Lion, and C. Wilwert, "Trends in
Time [MT]
automotive communication systems," Proceedings of the IEEE, vol.
Fig. 13. Synchronization of application software 93, pp. 1204-1223, 2005.

0278-0046 (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/TIE.2014.2321342, IEEE Transactions on Industrial Electronics

IE
EEE TRANSA
ACTIONS ON
N INDUSTRIA
AL ELECTRO
ONICS 10

[6]] A. Elkaddy and T. Sobh, "Robotics middlleware: a compreehensive Kichun Jo (S’100 -M'14) receivedd a B.S. in Mechanical
literaturee survey and attriibute-based biblioography," J. Robbot., vol. Engineering in 22008, and Ph.D. degree in Autom motive
2012, 20012. Engineering in 2014
2 from Hanyaang University, Seoul,
S
[7]] J. Kram mer and M. Schheutz, "Developpment environmeents for Korea.
autonom mous mobile robotts: A survey," Auttonomous Robots, vol. 22, His main fieelds of interest arre autonomous ddriving
pp. 101--132, 2007. system, informattion fusion theories, distributed control
[8]] E. de L Lellis, V. di Vitoo, L. Garbarino, C. Lai, and F. Corraro, C systems, real-tim
me embedded sysstems, and in-vehicle
"Design process and real-time validaation of an innnovative networks. His cuurrent research acctivities include system
autonom mous mid-air flighht and landing sysstem," World Acaademy of design and impleementation of autoonomous cars.
Science, Engineering andd Technology, vol. 79, pp. 174-184, 2011.
[9]] U. Nunees, J. A. Fonsecaa, L. Almeida, R R. Araújo, and R R. Maia,
"Using distributed systeems in real-time control of autoonomous Junsoo Kim (S S’11) received a B.S. in Mechanical
vehicles," Robotica, vol. 221, pp. 271-281, 22003. Engineering in 2008
2 from Hanyaang University, Seoul,
S
[100] P. Inseook, L. Wootaik, aand S. Myounghoo, "Application Software S Korea, where hee is currently workking toward a Phh.D. in
Modelinng and Integratioon Methodology using AUTOSA AR-ready the Automotive CControl and Electtronics Laboratoryy.
Light Sooftware Architectture," Trans. Korr. Society of Auttomotive His main fields
fi of interestt are vehicle coontrol,
Engineerrs, vol. 20, pp. 1117-125, 2012. decision theories, path plannning algorithms, and
[111] L. Kanngseok, P. Inseok, S. Myounggho, and L. W Wootaik, real-time system
ms. His current research activities innclude
"AUTOS SAR-ready Lightt Software Archhitecture for Autoomotive behavior reasooning and trajjectory planningg of
Embeddded Control Systeems," Trans. Korr. Society of Auttomotive autonomous carss.
Engineerrs, vol. 21, pp. 688-77, 2013.
[122] A. Monoot, N. Navet, B. Bavoux, and F. Sim monot-Lion, "Mulltisource
Softwaree on Multicore A Automotive ECU Us-Combining R Runnable Dongchul Kim m received a B.S S. in Electronicss and
Sequenccing With Task Sccheduling," IEEE Trans. Ind. Electrron., vol. Computer Enginneering, and a M.S S degree in Autommotive
59, pp. 33934-3942, 2012. Engineering in 2008 and 2010, respectively, from
[133] T. Noltee, S. Insik, M. Behhnam, and M. Sjoodin, "A Synchronization Hanyang Univerrsity, Seoul, Koreaa, where he is currrently
Protocoll for Temporal Isolation of Sooftware Componnents in working towardd the Ph.D. degrree in the Autom motive
Vehiculaar Systems," IEEE E Trans. Ind. Elecctron., vol. 5, pp. 375-387,
3 Control and Elecctronics Laboratorry.
2009. His current research interestss are in detectionn and
[144] P. Wei, L L. Hong, Y. Min,, and S. Zheng, "D Deployment optim mization tracking of movving object and innformation fusionn. His
for AUT TOSAR system coonfiguration," in IE IEEE Int. Conf. Coomputer research activities include the ddesign of autonoomous
Engineerring and Technollogy (ICCET), 2010, pp. V4-189-V V4-193. driving system, distributed contrrol systems, in-vehicle
[155] A. Prayaati, C. Koulamass, S. Koubias, annd G. Papadopouulos, "A works, and real-tim
netw me embedded softtware developmennt.
methodoology for the devvelopment of disttributed real-time control
applicatiions with focuss on task alloccation in heteroggeneous Chulhoon Jangg (S’13) received a B.S. in Mechanical
systems,," IEEE Trans. Indd. Electron., vol. 51, pp. 1194-1207, 2004. Engineering in 2011
2 from Hanyaang University, Seoul,
S
[166] F. Baronnti, E. Petri, S. Sapponara, L. Fanuccci, R. Roncella, R. Saletti, Korea, where he is currently workking toward a Phh.D. in
et al., "D
Design and Veriffication of Hardw ware Building Bloocks for the Automotive Control
C and Electtronics Laboratoryy.
High-Sppeed and Fault-Toolerant In-Vehiclee Networks," IEEE E Trans. His main fieelds of interest arre autonomous ddriving
Ind. Elecctron., vol. 58, ppp. 792-801, 2011. system, image pprocessing, and m machine learningg. His
[177] M. Barrranco, J. Proeenza, and L. Almeida, "Quanntitative current research activities include object detectioon and
Compariison of the Error--Containment Caapabilities of a Buus and a classification usiing multiple sensor fusion and situuation
Star Toppology in CAN Networks," IEEE T Trans. Ind. Electroon., vol. assessment for urrban autonomous driving.
58, pp. 8802-813, 2011.
[188] T. Pop, PP. Pop, P. Eles, Z.. Peng, and A. Anndrei, "Timing anaalysis of
the FlexR Ray communicatiion protocol," Reaal-Time Systems, vol. 39, Myoungho Su unwoo (M’81) received a B.S. in
pp. 205--235, 2008. Electrical Engiineering from H Hanyang Universiity in
[199] K. Jangg, I. Park, J. Han, K. Lee, andd M. Sunwoo, "Design 1979, and M.S S. in Electrical Engineering from m the
framewoork for FlexRay network parametter optimization,"" Int. J. University of T
Texas at Austin inn 1983, and a Phh.D. in
Auto. Teech., vol. 12, pp. 5589-597, 2011. System Engineeering from Oaklannd University in 11990.
[200] I. Park aand M. Sunwoo, "FlexRay
" networkk parameter optim mization He joined General Motoors Research (G GMR)
method for automotive aapplications," IEE EE Trans. Ind. Ellectron., Laboratories, W
Warren, MI, in 19985 and has workked in
vol. 58, ppp. 1449-1459, 2011. the area of autoomotive electronnics and control ffor 28
[211] K. Minkkoo, P. Kiejin, aand J. Myong-K Kee, "Frame Packking for years. During his
h nine-year tenuure at GMR, he w worked
Minimizzing the Bandwiddth Consumptionn of the FlexRayy Static on the design aand developmentt of various elecctronic
Segmentt," IEEE Trans. Ind. Electron., vvol. 60, pp. 40001-4008, contrrol systems for powertrains
p and chassis.
c Since 19993, he has led ressearch
2013. activvities as a Professor with the Deppartment of Autoomotive Engineerring at
[222] R. Wilhelm, J. Engblom, A. Ermedahl, N. N Holsti, S. Thesing, D. Hanyyang University. His work has ffocused on autom motive electroniccs and
Whalleyy, et al., "The worstt-case executiion-time contrrols (such as moddeling and controll of internal combbustion engines, ddesign
problem m—overview of m methods and surveey of tools," ACM M Trans. of auutomotive distribbuted real-time coontrol systems, iintelligent autonoomous
Embeddded Computing Sysstems (TECS), vool. 7, p. 36, 2008. vehiccles, and automottive education proograms).

0278-0046 (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.