See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/311252798

Workflow and toolchain for developing the automotive software according

AUTOSAR standard at a Virtual-ECU

Conference Paper · June 2016

DOI: 10.1109/ISIE.2016.7745004

CITATIONS READS

0 661

5 authors, including:

Felipe Franco João Henrique Zander Neme

Federal University of Technology - Paraná/Brazil (UTFPR) Federal University of Technology - Paraná/Brazil (UTFPR)
12 PUBLICATIONS   13 CITATIONS    14 PUBLICATIONS   15 CITATIONS   

SEE PROFILE SEE PROFILE

Max Mauro Santos

Federal Technological University of Paraná - Ponta Grossa - Brazil
53 PUBLICATIONS   85 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Model-Based Development View project

FLC - Forward Looking Camera View project

All content following this page was uploaded by Max Mauro Santos on 18 November 2017.

The user has requested enhancement of the downloaded file.

 Workflow and Toolchain for Developing the
Automotive Software According AUTOSAR
Standard at a Virtual-ECU
Felipe R. Franco; João H. Neme; Max M. Santos
Department of Electronics
UTFPR-PG
Ponta Grossa, Brazil
{felipefranco;neme}@alunos.utfpr.edu.br;
maxsantos@utfpr.edu.br
Abstract— The increasing demand of new functionalities in
next generation vehicles, leads to a growth of the complexity level
for the E/E automotive systems. On the same way, the automotive
software also tends to follow the same pace, so new methods
should be adopted to deal with this scenario of complexity. The
next generation of automotive embedded software is rapidly
migrating to the AUTOSAR standard, which is an architectural
composition of software components idealized to establish an
open industry standard for the automotive industry. AUTOSAR
aims to increase the reuse of these software components, in
particular between different vehicle platforms, and between
OEMs and suppliers. Inside this development process, software
control suppliers are able to check if the system functionalities
are attending to the requirements already in preliminary phases,
even if the ECU is not yet available. In this paper the authors
show the workflow to develop a virtual validation based on the
AUTOSAR standard with a Virtual ECU (V-ECU) using a
toolchain consisting of dSPACE (SystemDesk, VEOS and
TargetLink) and MathWorks (Matlab, Simulink and Stateflow)
software. The simulation of the architecture has been realized
considering the communication inside a same V-ECU and also
between two different V-ECUs considering a distributed
architecture. As result, a point-to-point explanation about
AUTOSAR methodology is done to show how the process is done.
Keywords—autosar; simulink; automotive software; matlab;
I. INTRODUCTION
Currently, vehicles are mechatronics systems with a high
number of functionalities implemented in embedded software
in which the high level of complexity of E/E automotive as
being the key point of investigations and innovations. The role
played by electronics in recent years has been analyzed by a
study of Mercer Management Consulting and can be the
market differential in some actuation segments [1]. The study
focuses on the question how the cost factors in the
development of a car will change between the years 2012 until
2015. In 2015, the costs for the development of electronics will
have a value of 35% of the total car production costs. Whereas
areas as power train and body have small increases, the costs
for the development of electronic systems will be almost
tripled.
João N. H. da Rosa; Inácio M. Dal Fabbro
Faculty of Agricultural Engineering - FEAGRI
UNICAMP
Campinas, Brazil
niltonhr@gmail.com; inacio@feagri.unicamp.br
Considering that the automotive product's features should
be done according the requirement of user, legislation and
performance with a certain level of customization, as well as
the increase of non-functional demand such the diagnosis has
aggravated the ECU development process complexity [2] [18].
This scenario implies the need to adopt new methodologies and
tools to ease the development, reducing costs, resources and
time to market. Since the automotive industry is a highly
dynamic and aggressive market, a short time to market can be
decisive if a new model will be whether or not successful.
In addition, in the current development environment, it is
difficult to reuse automotive embedded software that is already
developed for an ECU [3]. By introducing AUTOSAR
(AUTomotive Open System ARchitecture), a type of
standardized software architecture, the reusability may be
improved as well as time and cost can be saved, and
AUTSOAR may be a solution to handle. AUTOSAR [4] aims
for an industry standard for distributed control units in
vehicles.
AUTOSAR standard is an architectural composition by
software components technology. In addition, it is considered
the adoption of methodology of model-based development
which the key point is the system model is at the center of the
development process, from requirements development, through
design, implementation and testing. For the development
process, suppliers of software controls would test the
functionalities if attends the requirements in preliminary phases
even if the ECU is not yet available. Indeed, this fact can be
attended with a virtual ECU that is an emulated ECU that can
host the control software and has the real interaction with the
simulation model of the physical plant.
The main aim of this work is to teach how the AUTOSAR
workflow works and how this could be a good solution to new
developments for automotive market providing fast software
validation. The knowledge about this methodology in the most
of cases are only on the hands of OEMs and suppliers, not so
diffused on the academic place. A focus on model testing is
done to show how is possible to validate software applications
without hardware implementation. As Result, we hope to help
in the increase of the knowledge about new process to software
development using coding generation tools and cover the gap
between industry and academy.
We show how is the workflow to develop a virtual
validation based on the AUTOSAR standard with V-ECU with
toolchain of dSPACE (SystemDesk, VEOS and TargetLink)
and MathWorks (Matlab, Simulink and Stateflow). The
simulation of the architecture has been done considering the
communication for intra-ECU and inter-ECU.
The software architecture is defined in the SystemDesk
environment but according the AUTOSAR standard. The
software components are generated to encapsulate the
runnables created in TargetLink that runs with support of
MathWorks tool which has the controller behavior. Thus, the
complete SWC with the ARXML, .C, .h, .A2L and related
extensions are migrated come back to SystemDesk that can
host and run on a Virtual ECU that is created by VEOS tool of
dSPACE. After done all these steps, it is possible to simulate
the system considering the integration with the simulated plant
developed in Simulink.
This paper is organized as follows. Section II provides a
motivation for this work based on AUTOSAR standard
considering a workflow and toolchain. Section III presents the
overview of AUTOSAR concept and architecture for a virtual
ECU that supports the developed software to make simulation.
Section IV describes workflow and toolchain demanded for
AUTOSAR. In the Section V, important aspects regarding both
systems that will be developed are explained, while in Section
VI the actual implementation is presented. Section VII shows
all systems simulation and the paper is concluded in Section
VIII.
II. MOTIVATION FOR THIS WORK
There are several references describing the AUTOSAR
standard for automotive software; however it is not so easy to
find related work that describes in a clear and objective way
the workflow that should be undertaken, in whole or in parts, to
develop software based on the AUTOSAR standard. This is a
problem because developers need, as well as having deep
knowledge of the standard, know-how about the tool chain
employed by AUTOSAR, normally found in the industry field.
The challenge of defining which tools will be used on each
stage of development, is a crucial aspect and is not always well
described in the literature. Not to mention that in some
situations, in face of limitations, it is necessary to modify the
whole project workflow and toolchain. Although AUTOSAR
is being reported as the standard of the future, in some
situations, if the manufacturer is not willing to spend money
and resources on the migration process, the implementation is
not possible.
Nevertheless, once the tools and resources are available to
the developers, the entire development process based on the
AUTOSAR standard, from the specification of the SWC, RTE
and BSW to final the final embed process in a real hardware,
are steps that should be carried out successfully and prove the
standard effectiveness and real worth.
In this paper, since the authors only possess dSPACE and
Mathworks software tools, and not having access of the Basic
Software (BSW) and an ECU it was not possible to implement
the AUTOSAR standard in a real hardware as a final
implementation. Thus, using dSPACE tools like SystemDesk,
VEOS and Targetlink and MathWorks as Matlab, Simulink
and Stateflow, it was possible to develop an application using
the AUTOSAR standard with intra-ECU communication
mechanisms and also inter-ECU communication using a
controller area network (CAN bus). This is only possible due
the fact that with TargetLink and MathWorks tools it was
possible to describe and conduct the behavioral model of the
controller and the dynamics of the physical plant to be
controlled using a model-driven development. Also with
SystemDesk and VEOS it was possible to implement a Virtual
ECU (VECU), used for the simulation.
Indeed, this work had the motivation to present a clear and
objective development process for embedded automotive
software using AUTOSAR in a virtual platform instead of a
real ECU hardware. The relevance is proven once the
experiment has succeeded well even when important resources,
such as a real ECU and a Basic Software, are not available to
the developers.
III. AUTOSAR BACKGROUNDING
A. Main concept
AUTOSAR is a worldwide development partnership of car
manufacturers, suppliers and other companies from the
electronics, semiconductor and software industry [5].
AUTOSAR [6] is applied as a standard architecture to develop
automotive embedded software systems. AUTOSAR
originated [7] from component-based software engineering
where a system is divided into a number of software
components each of which encapsulates a set of related
functions which are called runnable entities.
These software components are mapped to ECUs, and the
interfaces of the software-components are generated. The result
is a system description as well as the description of the mapped
software components, including the interface of such
components and is given to the supplier who implements the
behavior of the software components, performs the mapping of
runnables to OS tasks, and configure the basic software
modules like the COM stack. Afterwards, the software is
compiled, built, and flashed to an ECU [8].
The main goal of AUTOSAR is to allow the re-usability of
pre-validated software components. That means developers
should be able to re-use existing functions in different
hardware. Also new model elements could be developed
without the drawback of starting from scratch.
AUTOSAR was design to achieve technical goals as [6]:
• Modularity: Enables tailoring of software according to
the individual requirements of ECUs and their tasks.
• Scalability: Ensures the adaptability of common
software modules to different vehicle platforms to avoid
proliferation of software with similar functionality.
 • Transferability: Optimizes the use of resources
available throughout a vehicle´s electronic architecture.
• Re-usability: Helps to improve product quality and
reliability and to reinforce corporate brand image across
product lines.
In order to reach these specific goals, AUTOSAR provides
a common software infrastructure for automotive systems of all
vehicle domains based on standardized interfaces for the
different layers [6], as explained below in section AUTOSAR
Structure.
B. AUTOSAR Structure
The AUTOSAR software architecture is divided in layers
that seek to abstract from hardware components. Each of these
layers has features that can be used by all AUTOSAR
applications.
In order to fulfill the goal of transferability, AUTOSAR
defines a layered SW architecture and a formal description
language for Software Components, so that these components
can be implemented independently from the underlying
hardware [6].
The upper most layers are the Application layer that
contains all application specific software components (SWC).
The next two layers below are the Runtime Environment
(RTE) and the Basic Software (BSW), where the BSW abstract
from the hardware and offer basic functionality to the software.
This lower layer is responsible by the interaction with the
microcontroller in the ECU.
Virtual Functional Bus (VFB) is the sum of all
communication mechanism and interfaces to the BSW. The
communication between different software components and its
environment can be specified independently of any underlying
hardware. From the VFB view ports of AUTOSAR Software
Components, Complex Device Drivers, the ECU abstraction
and AUTOSAR services can be connected [9]. The VFB is the
abstraction of the AUTOSAR software components
interconnection of the entire vehicle.
IV. WORKFLOW AND TOOLCHAIN FOR AUTOSAR
VIRTUAL VALIDATION
The architecture of AUTOSAR can be made using different
levels of programing, together or isolate, to set all the
parameters of the code. There is the minimum parameters that
should be settled to the architecture be validate as: SWCs
(Software Components) with your respectively codes and
internal behaviors, ports, data elements, interfaces of
communication, scales, data types and the connections of the
SWCs between them.
In an AUTOSAR workflow, a variety of tools offered by
different manufactures could be found to perform a specific
part of the process. Over all this solutions, they can be divided
in three classes of tools: BMT (Behavior Modeling Tools) and
C IDEs, System-level design tools and Basic software
configuration tools.
Fig. 1. Workflow for AUTOSAR virtual validation.
• BMT and C IDEs – correspond to the development of
Software Components (SWCs) utilizing Behavior Modeling
Tools (BMT), eg: Simulink, TargetLink or wrote manually in
C language. Each SWC is composed by an AUTOSAR XML
description file (.ARXML) and your respective .c file. This
corresponds to the upper layer in the AUTOSAR level.
• System-level design tools – responsible by the
development of the systems and sub-systems. Some actions
could be executed like SWCs connections and ECU mapping,
hardware topology, bus communication management, data
elements mapping, etc. The results of this tool are: System
Description files (.ARXML) and ECU Configuration files
(.ARXML) for each ECU in the system. SystemDesk is an
example of “System-level tool”.
• Basic Software configuration tools – this kind of tools
are responsible by to configure each ECU individually and
generate yours .hex files that will be recorded in the ECU
microcontrollers.
V. DASHBOARD APPLICATION
The application chosen to develop software function based
on the AUTOSAR standard was referring to the display control
system of engine temperature and the fuel level that is available
on dashboard in the form of on-board diagnostics on a vehicle.
The dash gauges are used to give drivers important information
about the vehicle. Both designed system combines a gauge that
shows the information regarding each functionality and a
warning light that is turned on when a certain limit is reached.
As the way to show a real implementation based on
AUTOSAR standard, a simple example was conducted to teach
how is the compatibility between the tools and the capability of
system simulation considering a workflow previously defined.
The entire system will be simulated using a virtual platform to
perform an important step of the development process for
automotive software. Some errors and bugs can be found in
these preliminary stages, which can also provide for the
developer the ability in develops a software function with
better quality, modular, scalable and less errors.
The development methodology is the model-based design
which in our case we doesn't apply in whole because in this
work is presented only a small example of a software
application function. For the development tools, was chosen in
the high level of programing using dSPACE (TargetLink 3.5,
SystemDesk 3.2 and VEOS 3.0) [16] and MathWorks There are two ways to communicate SWCs in AUTOSAR
(Matlab/Simulink/Stateflow) [17] software’s as mentioned in architecture, one is Intra-ECU and another is called Inter-ECU
Fig.1. Each software tool is responsible for one step of the communication. In vehicle system architecture, both of
entire process, that is bidirectional, so can be made changes of implementations work together, sharing data to the
the code or architecture independently of the process step. applications. Dashboard Application was implemented using
both implementation types, each topology will be explained in
The information regarding the dimensional values of the the topics below.
engine temperature and fuel level, given below based on
experiments and tests performed in the laboratory and it is
considered as merely illustrative examples in order to provide A. Intra-ECU Communication
the reader with a better understanding for this real application. In an Intra-ECU communication, all the SWCs that need to
For temperature, was used the unit ºC (degrees celsius) and for communicate with each other are available over the same
level the unit l (liters). processor (ECU). The data exchange between applications
occurs by means of regions inside of the chip (RAM memory).
The engine temperature is measured by a sensor which The implementation using Intra-ECU architecture was
measures the engine coolant temperature and has a performed placing all SWCs (Fuel Sens., Fuel Ind., Temp.
proportional correlation with the engine temperature and is Sens. and Temp Ind.) in a single ECU, connecting all the
used to provide readings for the gauge. The readings from this application via VFB (RTE+ BSW). The wire connection with
sensor are available for different ECU’s, which use this data to temperature sensor, level sensor, gauges and warning lights are
display information and to adjust other functions. If the sensor connected to a single ECU hardware. Fig. 2 shows the
detects that the temperature if too high a warning light is Dashboard Intra-ECU Application.
activated. This temperature upper threshold varies from
manufacturer to manufacturer and from model to model, but
commonly the warning light is turned on if the temperature
exceeds 95 ºC. To assure that the driver will take actions to
cool the temperature to a secure level, all systems provide a
hysteresis. Usually the warning light is turned off when the
temperature drops to 90 ºC. The developed system used in this
paper activates the warning light when the temperature reaches
95 ºC and deactivates it when the temperature drops to 93 ºC.
The fuel gauge offers a good estimate of the amount of fuel
remains in the tank. The sensing unit acquires information
about the level left in the tank and sends this information to the
ECU, the maximum amount of fuel considered is 50 l. Once
this information is processed, the indicator unit displays the
information in the fuel gauge. Again, when the level reaches a Fig. 2. The scenary for intra-ECU implementation – Stand-alone
certain limit, a warning light is turned on. This is limit was set architecture.
on 8 l. Hysteresis is also used in this system as a security way
to manage the status, avoiding blink phenomenon in the status B. Inter-ECU Communication
indicator, so the warning light will be turned off only when the
tank level reaches 9 l. Inter-ECU communication is defined by the connection
between two or more SWCs placed inside of different ECUs.
To implement the system, a group of tools available in our The connection is performed via VFB that takes in advantage
lab was utilized to create the SWCs, RTE and a BSW structure of the communication buses (i.e. CAN, LIN, FlexRay, etc) to
that allow us to virtualize a simple ECU and test the software interconnection and makes possible the signals
application behavior. The SWC implementations were done exchange over different hardware.
using the tolls TargetLink from dSPACE and Simulink from
Mathworks. To build the RTE level and a small part of BSW
layer that is necessary to the ECU virtualization, we worked
with SystemDesk, and finally VEOS to simulate the virtual
ECU, both manufactured by dSPACE.
In the TargetLink/Simulink environment, four applications
were built, as showed in the Fig. 4 and 5, to cover a specific
function necessary to the system. The groups could be divided
in two, Temperature and Fuel level. Each one has a SWC
responsible by read a value from a specific transducer and then
send to the other component that control the gauges. All the
SWCs communicate with your specific couple using the VFB
(Virtual Functional Bus) infrastructure, that will be performed
by RTE (Runtime Environment) and BSW (Basic Software) in
the further steps. Fig. 3. The scenary for inter-ECU implementation – Distributed architecture.
 In this implementation, the application was split in two
different ECUs, ECM (Engine Control Module) and ICM
(Instrument Control Module) and are connected through CAN
bus. Fig. 3 shows the Dashboard Inter-ECU Application. The
ECM was responsible to accommodate the sensors SWCs, this
kind of variables are used in the engine control loop and will
be shared with dashboard module. The other ECU (ICM) is
responsible to manage the dashboard and has the applications
responsible to control the dashboard gauges and warning lights
using the variables offered by ECM unit.
VI. DEVELOPMENT PROCESS
To implement the system virtualization, some steps needs
to be covered to build the necessary parts that together can
propitiate the parts behavior visualization.
A. SWC Creation Using TargetLink
The TargetLink is responsible by the definition of the
components parameters using the TargetLink Data Dictionary
Manager. Each component of the model in the Simulink is
referenced and associated with specifications of variables, data
types, data elements and functionalities. All the system was
projected with all the steps (Fig. 4); the sensor using the
Simscape Library and the ADC module, the treatment of the
signal from the ADC (Fig. 5) and the controller of the gauge
and alert (Fig. 6).
Fig. 4. The behaviour model in simulink system.
Fig. 5. ETs subsystem considering the runnable function.
Fig. 6. The SWC with runnable description on Simulink: A) SWC – ETc; B)
Chart Eng_Temp.
The definition starts encapsulating the group of blocks in
Simulink that execute some functionality. Preferably the group
of the blocks that already passed although the steps of MBD
(Model-Based Design) [14], this entails more credibility to the
system. This group will be set as a SWC, next defines the ports
of the SWC with respective interface communication that has
specified data elements, scales, data types and variables.
After the SWC creation, each application can be tested
individually to verify in the beginning of the process if the
desired algorithm works properly as expected.
B. Expor from TargetLink  Container  SystemDesk
After finished the development of all SWCs, the next step
is the export these parameters to the SystemDesk, that will be
the manager of the connectives of SWCs, hardware and
software topologies. The SWC applications developed using
TargetLink are now exported using a dSPACE feature called
“container”.
C. Design the System Architecture with SystemDesk
SystemDesk is responsible by to create the system
structure, in the other words the system model, to allow the
correct function of the ECU. Here, the main definitions will be:
Software Architecture, Hardware Topology, Bus
Communication and finally the Experiment or Simulation. A
project was created and all the SWCs developed in the
previous step were imported. The Fig. 7 has shown the SWCs
imported and connected with the respective application.
After project creation and the SWCs inclusions, the next
step is to configure the hardware topology. Here that the two
implementations (Inter and Intra) starts to have different
configurations. For Intra-ECU implementation, only a single
ECU configuration was created (hardware topology), following
by the System Definition phase were the SWC placement is
performed, all the applications will be place at the same ECU.
Fig. 7. The topology of software components.
In the Inter-ECU development, the Hardware Topology has
some more definitions to be configured. Here is necessary to
create a Communication Cluster that is responsible by the bus
communication. After this, is necessary to create the ECUs as
necessary (in our case, two were created), connect all the
hardware to a communication channel (that was generated by
the communication cluster) and then specify the Network
Communication (CAN bus). To finish this step is necessary to
execute the SWC placement; each ECU needs to receiver the
applications as planned. After this sequence, all necessary
system model configurations were done and your high level
AUTOSAR application is ready.
 To make a Virtual ECU simulation, is necessary to have a
small implementation of the BSW layer to manage the action
of the AUTOSAR structure (OS tasks, communication
peripherals, etc). SystemDesk is a System Level Tool but can
offer a small BSW stack that is enough to build a virtual ECU
that will be used in the simulation step.

D. Experiment Configuration
This step is the simulation of the system interaction that
includes all the model parts, including ECUs, communication Fig. 9. The ADC subsystem for the temperature sensor.
buses, and others parts.
With the data of the sensors, was obtained the range of
For the experiment is required to specify a set of values for voltage. In the temperature sensor the minimum is -40 °C, that
measurement and stimulus variables. The stimulus variables represents 0.1080 V and in the ADC 88, and the maximum is
have as option employed the input signals, as waves, ramps 130°C, that represents 4.5914V, and in the ADC 3761. In the
and constants. The values of these signals are chosen to fuel level sensor the minimum is 0 l, that represents 3.87 V and
guarantee the best coverage for the test of the system. The in the ADC 3170, and the maximum is 50 l, that represents
measurements variables have the option of measure a data 4.83V and in the ADC 3956.
element of a port of the SWCs, the data element of the I/O
abstraction of the V-ECU or a stimulus variable. The input signals represent the values from ADC. The input
signal of the temperature sensor was set with range 0 – 4000 in
The experiment configuration is responsible by the entire the interval of 15 s (linear ramp) and return to 0 in the interval
configuration of the environment under test which the of 15 s (linear ramp). The input signal is show in Fig. 10.
parameters as StopTime, BreakTime and Signal History shall
be set. Indeed, after all these parameters be settled is possible
to manage the simulation, generating the signals that will
excite the SWCs inputs, how many time the simulation will
take and analyze the outputs signals.

VII. SIMULATION INTER-ECU AND INTRA-ECU

After of the topologies and configurations are settled in the
SystemDesk, is now available to do the simulation of a V-ECU
using the software and hardware topologies (Fig. 8). To
execute the simulation, SystemDesk should be connected with
VEOS that runs in background to execute simulation.
Fig. 10. Test signal generation for engine temperature.

Fig. 8. Virtual ECUs according the communication as: A) Intra-ECU; B)

Inter-ECU.

A. Verification
In the verification phase, a set of parameters in the
environment test needs to be configured to offer conditions as
near as possible that in a real world test using virtual stimulus.
As result, the output signals can be plot in graphs to future
analyses behavior verification.
To the verification of the system was set a group of tests
that represents the signals from the ADC sensors (Fig. 9). The
target hardware has an ADC with 12 bits of resolution (0-4096)
in range of 0 V to 5 V. The sensors are resistive and is need
the use of a pull-down resistor with a value of 1 kΩ to
implement a voltage divider with the sensor resistance.
Fig. 11. Test signal result for engine temperature.
The output signals represents the values that will be show
in the displays and the activation of the alert signals. The alert
signal of the temperature is active when the temperature is
greater than 95 °C, cursor Y1 (Fig. 11), and is deactivate when
the signal is under or equal 93 °C, cursor Y2 (Fig. 13). The X
axis is represented in seconds. The input signal of the fuel level
sensor was set with range 3000 – 4000 in the interval of 15 s
(linear ramp) and return to value 0 in the interval of 15 s (linear
ramp). The input signal is shown in Fig. 12.

Fig. 12. Test signal generation for fuel level.
The alert signal of the low fuel level is active when the
level is under 8 l, cursor Y1 (Fig. 13), and is deactivate when
the signal is greater or equal than 9 l, cursor Y2 (Fig. 13). The
X axis is represented in seconds.
Fig. 13. Test signal generation for fuel level.
VIII. CONCLUSION AND FUTURE WORK
We presented a workflow and tool chain for develop
automotive software function based on AUTOSAR standard in
a virtual ECU. The workflow has been defined according the
model-based design but wasn't the scope present the physical
plant. The toolchain was the mix of MathWorks tools that
could be possible develop the behavior model after define the
software components and simulations using the dSPACE tools.
A virtual ECU has been done with the VEOS tool that could
emulate a real ECU with and without CAN interface according
the defined architectures as stand-alone and distributed. A
small example of dashboard in vehicle considering the engine
temperature and fuel level has been done demonstrating the on-
board diagnostic aspects and the software components and the
behavior models designed regardless of the architecture and
hardware implementation. Thus, it was possible to demonstrate
how to develop an automotive software in fact considering the
AUTOSAR standard without consider the target hardware
being possible to allocation function in later stages when we
have the hardware prototype.
With this workflow demonstration using tools that are
normally utilized in the industry, this work teach how young
engineers and new professionals, can start to develop
AUTOSAR applications and his virtual system validation.
Providing too an upper view of the overall work process chain
and helping in a fast understanding of all the parts.
REFERENCES
[1] M. Brou, S. Kirstan, H. Krcmar and B. Schartz, “What is the benefit of a
model-based design of embedded system in the car industry?” Emerging
Technologies for the Evolutin and Maintenance of Software Models, pp.
343-369, 2012.
[2] W. Dafang and et al., “Survey of the AUTOSAR Complex Drivers in
the Field of Automotive Electronics.” In Proc. of Int. Conf. on Int.
Comp. Tech. and Aut. (ICICTA’2010), Changsha, pp. 662-664, 11-12
May 2010.
[3] D. Kum, G. M. Park, S. Lee and W. Jung, “AUTOSAR migration from
existing automotive software.” In Proc. of Int. Conf. on Cont., Aut. and
Syst. (ICCAS’2008), Seoul, pp. 558-562, 14-17 Oct. 2008.
[4] G. Fraser, F. Wotawa and P. E. Ammann: Testing with Model Checkers:
A survey. SNA TECHNICAL REPORT, 2007.
[5] K Senthilkumar and R. Ramadoss, “Designing multicore ECU
architecture in vehicle networks using AUTOSAR.” In Proc. of Third
International Conference on Advanced Computing (ICoAC’2011),
Chennai, pp. 270-275, 14-16 Dec. 2011.
[6] www.autosar.org
[7] H. R. Fargardi, B. Lisper, K. Sandstrom and T. Nolte, “A
communication-aware solution framework for mapping AUTOSAR
runnables on multi-core systems.” In Proc. of IEEE Emerging
Technology and Factory Automation (ETFA’2014), Barcelona, pp. 1-9,
16-19 Sept. 2014.
[8] G. Park, D. Ku, S. Lee, W.-J. Won and W. Jung, “Test methods of the
AUTOSAR application software components.” In Proc. of the ICROS-
SICE International Joint Conference, Fukuoka – Japan, pp. 2601-2606,
2009.
[9] W. Dafang and et al., “Communication Mechanisms on the Virtual
Functional Bus of AUTOSAR.” In Proc. of Int. Conf. on Int. Comp.
Tech. and Aut. (ICICTA’2010), Changsha, pp. 982-985, 11-12 May
2010.
[10] H. C. Jo, S. Piao, S. R. Cho and W. Y. Jung, “RTE template structure for
AUTOSAR based Embedded Software Platform.” In Proc. of
IEEE/ASME Int. Conf. on Mechat. and Emb. Syst. and Applic.
(MESA’2008), Beijing, pp. 233-237, 12-15 Oct. 2008.
[11] N. Naumann,. AUTOSAR Runtime Environment and Virtual Function
Bus. Available in:
<http://hpi.de/fileadmin/user_upload/fachgebiete/giese/Ausarbeitungen_
AUTOSAR0809/NicoNaumann_RTE_VFB.pdf>. Access in: August,
29, 2015.
[12] D. Schreiner, M. Schordan and J. Knoop, “Adding timing-awareness to
AUTOSAR basic-software -- A component based approach.” In Proc. of
IEEE Inter. Symp. on object/component/service-oriented real-time
distrib. Comp. (ISORC’2009), Tokyo, pp. 288-292, 17-20 Mar. 2009.
[13] F. Schirrmeister; Cadence Design Systems, Automotive System &
Software Development Challenges: Part 1. 2013. Available in:
<http://www.edn.com/Home/PrintView?contentItemId=4423874>.
Access in: August, 29, 2015.
[14] M. M. D. Santos, J. H. Neme, F. R. Franco, S. L. Stevan, W. Torres, A.
B. Lugli, A. A. M. Lagana and J.F. Justo, “Model-Based Design of
Exterior Lighting Control Function for Automobile: MIL, SIL and
RCP,” International Journal of Innovative Computing, Information &
Control, v. 11, p. 1495-1507, 2015.
[15] J. A. och Ollen Nordin, “Implementation of CAN Communication Stack
in AUTOSAR.” Linkoping University, Department of Electrical
Engineering, PhD Thesis, pp. 99, 15 June 2015.
[16] www.dspace.com
[17] www.mathworks.com
[18] A. Sangiovanni and M. Di Natale. “Embedded System Design for
Automotive Applications”, IEEE Computer, vol. 40, no. 10, pp. 42-51,
2007.
View publication stats