Beruflich Dokumente
Kultur Dokumente
net/publication/311252798
CITATIONS READS
0 661
5 authors, including:
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
All content following this page was uploaded by Max Mauro Santos on 18 November 2017.
Felipe R. Franco; João H. Neme; Max M. Santos João N. H. da Rosa; Inácio M. Dal Fabbro
Department of Electronics Faculty of Agricultural Engineering - FEAGRI
UTFPR-PG UNICAMP
Ponta Grossa, Brazil Campinas, Brazil
{felipefranco;neme}@alunos.utfpr.edu.br; niltonhr@gmail.com; inacio@feagri.unicamp.br
maxsantos@utfpr.edu.br
Abstract— The increasing demand of new functionalities in Considering that the automotive product's features should
next generation vehicles, leads to a growth of the complexity level be done according the requirement of user, legislation and
for the E/E automotive systems. On the same way, the automotive performance with a certain level of customization, as well as
software also tends to follow the same pace, so new methods the increase of non-functional demand such the diagnosis has
should be adopted to deal with this scenario of complexity. The aggravated the ECU development process complexity [2] [18].
next generation of automotive embedded software is rapidly This scenario implies the need to adopt new methodologies and
migrating to the AUTOSAR standard, which is an architectural tools to ease the development, reducing costs, resources and
composition of software components idealized to establish an time to market. Since the automotive industry is a highly
open industry standard for the automotive industry. AUTOSAR
dynamic and aggressive market, a short time to market can be
aims to increase the reuse of these software components, in
particular between different vehicle platforms, and between
decisive if a new model will be whether or not successful.
OEMs and suppliers. Inside this development process, software In addition, in the current development environment, it is
control suppliers are able to check if the system functionalities difficult to reuse automotive embedded software that is already
are attending to the requirements already in preliminary phases, developed for an ECU [3]. By introducing AUTOSAR
even if the ECU is not yet available. In this paper the authors (AUTomotive Open System ARchitecture), a type of
show the workflow to develop a virtual validation based on the standardized software architecture, the reusability may be
AUTOSAR standard with a Virtual ECU (V-ECU) using a improved as well as time and cost can be saved, and
toolchain consisting of dSPACE (SystemDesk, VEOS and
AUTSOAR may be a solution to handle. AUTOSAR [4] aims
TargetLink) and MathWorks (Matlab, Simulink and Stateflow)
software. The simulation of the architecture has been realized
for an industry standard for distributed control units in
considering the communication inside a same V-ECU and also vehicles.
between two different V-ECUs considering a distributed AUTOSAR standard is an architectural composition by
architecture. As result, a point-to-point explanation about software components technology. In addition, it is considered
AUTOSAR methodology is done to show how the process is done. the adoption of methodology of model-based development
which the key point is the system model is at the center of the
Keywords—autosar; simulink; automotive software; matlab;
development process, from requirements development, through
design, implementation and testing. For the development
I. INTRODUCTION process, suppliers of software controls would test the
Currently, vehicles are mechatronics systems with a high functionalities if attends the requirements in preliminary phases
number of functionalities implemented in embedded software even if the ECU is not yet available. Indeed, this fact can be
in which the high level of complexity of E/E automotive as attended with a virtual ECU that is an emulated ECU that can
being the key point of investigations and innovations. The role host the control software and has the real interaction with the
played by electronics in recent years has been analyzed by a simulation model of the physical plant.
study of Mercer Management Consulting and can be the The main aim of this work is to teach how the AUTOSAR
market differential in some actuation segments [1]. The study workflow works and how this could be a good solution to new
focuses on the question how the cost factors in the developments for automotive market providing fast software
development of a car will change between the years 2012 until validation. The knowledge about this methodology in the most
2015. In 2015, the costs for the development of electronics will of cases are only on the hands of OEMs and suppliers, not so
have a value of 35% of the total car production costs. Whereas diffused on the academic place. A focus on model testing is
areas as power train and body have small increases, the costs done to show how is possible to validate software applications
for the development of electronic systems will be almost without hardware implementation. As Result, we hope to help
tripled.
in the increase of the knowledge about new process to software In this paper, since the authors only possess dSPACE and
development using coding generation tools and cover the gap Mathworks software tools, and not having access of the Basic
between industry and academy. Software (BSW) and an ECU it was not possible to implement
the AUTOSAR standard in a real hardware as a final
We show how is the workflow to develop a virtual implementation. Thus, using dSPACE tools like SystemDesk,
validation based on the AUTOSAR standard with V-ECU with VEOS and Targetlink and MathWorks as Matlab, Simulink
toolchain of dSPACE (SystemDesk, VEOS and TargetLink) and Stateflow, it was possible to develop an application using
and MathWorks (Matlab, Simulink and Stateflow). The the AUTOSAR standard with intra-ECU communication
simulation of the architecture has been done considering the mechanisms and also inter-ECU communication using a
communication for intra-ECU and inter-ECU. controller area network (CAN bus). This is only possible due
The software architecture is defined in the SystemDesk the fact that with TargetLink and MathWorks tools it was
environment but according the AUTOSAR standard. The possible to describe and conduct the behavioral model of the
software components are generated to encapsulate the controller and the dynamics of the physical plant to be
runnables created in TargetLink that runs with support of controlled using a model-driven development. Also with
MathWorks tool which has the controller behavior. Thus, the SystemDesk and VEOS it was possible to implement a Virtual
complete SWC with the ARXML, .C, .h, .A2L and related ECU (VECU), used for the simulation.
extensions are migrated come back to SystemDesk that can Indeed, this work had the motivation to present a clear and
host and run on a Virtual ECU that is created by VEOS tool of objective development process for embedded automotive
dSPACE. After done all these steps, it is possible to simulate software using AUTOSAR in a virtual platform instead of a
the system considering the integration with the simulated plant real ECU hardware. The relevance is proven once the
developed in Simulink. experiment has succeeded well even when important resources,
This paper is organized as follows. Section II provides a such as a real ECU and a Basic Software, are not available to
motivation for this work based on AUTOSAR standard the developers.
considering a workflow and toolchain. Section III presents the
overview of AUTOSAR concept and architecture for a virtual III. AUTOSAR BACKGROUNDING
ECU that supports the developed software to make simulation.
Section IV describes workflow and toolchain demanded for A. Main concept
AUTOSAR. In the Section V, important aspects regarding both
AUTOSAR is a worldwide development partnership of car
systems that will be developed are explained, while in Section
manufacturers, suppliers and other companies from the
VI the actual implementation is presented. Section VII shows
electronics, semiconductor and software industry [5].
all systems simulation and the paper is concluded in Section
AUTOSAR [6] is applied as a standard architecture to develop
VIII.
automotive embedded software systems. AUTOSAR
originated [7] from component-based software engineering
II. MOTIVATION FOR THIS WORK where a system is divided into a number of software
There are several references describing the AUTOSAR components each of which encapsulates a set of related
standard for automotive software; however it is not so easy to functions which are called runnable entities.
find related work that describes in a clear and objective way These software components are mapped to ECUs, and the
the workflow that should be undertaken, in whole or in parts, to interfaces of the software-components are generated. The result
develop software based on the AUTOSAR standard. This is a is a system description as well as the description of the mapped
problem because developers need, as well as having deep software components, including the interface of such
knowledge of the standard, know-how about the tool chain components and is given to the supplier who implements the
employed by AUTOSAR, normally found in the industry field. behavior of the software components, performs the mapping of
The challenge of defining which tools will be used on each runnables to OS tasks, and configure the basic software
stage of development, is a crucial aspect and is not always well modules like the COM stack. Afterwards, the software is
described in the literature. Not to mention that in some compiled, built, and flashed to an ECU [8].
situations, in face of limitations, it is necessary to modify the The main goal of AUTOSAR is to allow the re-usability of
whole project workflow and toolchain. Although AUTOSAR pre-validated software components. That means developers
is being reported as the standard of the future, in some should be able to re-use existing functions in different
situations, if the manufacturer is not willing to spend money hardware. Also new model elements could be developed
and resources on the migration process, the implementation is without the drawback of starting from scratch.
not possible.
AUTOSAR was design to achieve technical goals as [6]:
Nevertheless, once the tools and resources are available to
the developers, the entire development process based on the • Modularity: Enables tailoring of software according to
AUTOSAR standard, from the specification of the SWC, RTE the individual requirements of ECUs and their tasks.
and BSW to final the final embed process in a real hardware, • Scalability: Ensures the adaptability of common
are steps that should be carried out successfully and prove the software modules to different vehicle platforms to avoid
standard effectiveness and real worth. 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.
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.
A. Verification
In the verification phase, a set of parameters in the
environment test needs to be configured to offer conditions as Fig. 11. Test signal result for engine temperature.
near as possible that in a real world test using virtual stimulus.
As result, the output signals can be plot in graphs to future The output signals represents the values that will be show
analyses behavior verification. in the displays and the activation of the alert signals. The alert
To the verification of the system was set a group of tests signal of the temperature is active when the temperature is
that represents the signals from the ADC sensors (Fig. 9). The greater than 95 °C, cursor Y1 (Fig. 11), and is deactivate when
target hardware has an ADC with 12 bits of resolution (0-4096) the signal is under or equal 93 °C, cursor Y2 (Fig. 13). The X
in range of 0 V to 5 V. The sensors are resistive and is need axis is represented in seconds. The input signal of the fuel level
the use of a pull-down resistor with a value of 1 kΩ to sensor was set with range 3000 – 4000 in the interval of 15 s
implement a voltage divider with the sensor resistance. (linear ramp) and return to value 0 in the interval of 15 s (linear
ramp). The input signal is shown in Fig. 12.
Providing too an upper view of the overall work process chain
and helping in a fast understanding of all the parts.
REFERENCES