2020-01-5007 Published 27 Mar 2020

Standard Process for Establishment of ECU

Virtualization as Integral Part of Automotive

n
Software Development Life-Cycle

tio
Ritesh Goyal KPIT, India

Kushal K. S and Pratik Mistry KPIT Technologies Limited, India

ibu
Citation: Goyal, R., Kushal, K.S., and Mistry, P., “Standard Process for Establishment of ECU Virtualization as Integral Part of Automotive
Software Development Life-Cycle,” SAE Technical Paper 2020-01-5007, 2020, doi:10.4271/2020-01-5007.

s tr
Abstract
implementation of ECU virtualization is also presented. On

I
n recent year, Electronic Control Unit (ECU) virtualization the foundation of modified SDLC V-cycle, a standard process
is being promoted for development and validation of auto- flow is created to establish ECU virtualization as integral part

motive software. ECU virtualization allows execution of
integrated software on developer’s computer, enabling faster
algorithm testing. However, the challenge remains to establish
a process to be followed at organization level and its integra-
tion in the existing development process/es.
In this paper, an approach for integration of Virtual ECU
(V-ECU) in Software Development Life-Cycle (SDLC) is
discussed. The rationale of merging ECU virtualization in
for
standard SDLC V-cycle supplements milestones in testing &
ot
validation. Addition of this milestone with the
-N
Di
of software development in agile methodology.
We have implemented the discussed process with diversi-
fied tool chains on various automotive controller i.e. TCM,
ECM, BMS etc. The process is accomplished, and the benefits
of ECU virtualization are accumulated by algorithm develop-
ment and testing team. A case study of Battery Management
System (BMS) application is presented in this paper, using
dSPACE tool suite. A sprint plan is also presented to highlight
implementation of ECU virtualization and uses of system by
various stake holders.

I. Introduction
FIGURE 1 Traditional SDLC V-cycle
ly

The expedite feature of evaluating the software components

developed independent of the hardware platforms or proto-
types, is that these software components can be tested and
On

validated with the virtual control units, individually. The

virtual environment provides a platform to test and validate
these software components, in terms of their behavior and
functionalities, with agile methodologies. The need to curtail
the time for evolution of software and cost with an improve-
iew

ment in its quality, is driving the need to ratify virtualization

and virtual validation processes. For automotive ECUs, the
software development process follows a quintessential SDLC
V-cycle, as shown in Figure 1. With the challenges being posed
in the process definition, adherence and acceptance of the
ev

process for development and testing of the virtual platform,

the growing needs to faster development cycles push for the
© SAE International.

fundamental process definition and its integration in the

Pr

existing development process/es.

For an automotive application, the complex embedded
software is being developed by different domain specific func-
tional units. The development of these software components
by functional units adhering to the traditional SDLC V-cycle
are to be integrated and tested for their behavior. Similarly
individual components of an ECU are tested upon integration.
While testing of these various components may require
different testing and integration platforms. Specifically, the
algorithm software unit responsible of developing, managing
and testing the algorithm software components of an ECU
for a vehicle, requires a solitary process, platform and meth-
odology to enable the reuse of software development and test
the software component. This process of capturing the
 2 STANDARD PROCESS FOR ESTABLISHMENT OF ECU VIRTUALIZATION
defective/erroneous behavior of the algorithm software, a core
component defining the behavior of the vehicle, in the early
stages of SDLC V-cycle development process is required. This
requires a sophisticated abstraction in the physical environ-
ment to handle the complete functionality of a test-bench/
vehicle and capture the behavior of various software compo-
nents of an algorithm software. With the accelerating requests
of such requirements, a prominent know-how called
Virtualization was abstracted.
Virtualization is an augmented reality that enables
various functional domains to integrate various software
components onto a single platform, independent of the under-
lying hardware and basic software components. The virtual-
ization techniques have the capabilities of defining the appli-
cation software for a vehicle, integrate either complete or
partial components, hardware feature support or different
functional domains brought onto a single platform. The
process definition and adaptation, integration of the virtual-
ization process with the existing SDLC V-cycle has been the
major focus and key highlighted presented in this paper.
This paper focuses on coupling the virtualization tech-
niques in the traditional SDLC V-cycle. The merging process
involves various key activities at different phases within
V-cycle. This envisions major appraisals for the development
and testing of application software. Also the key factors that
impact and play a major role, at the organization level, with
the linking of virtualization techniques are evaluated. The
ot
metrics generated are compared with the traditional meth-
odologies and their offset and effects are analyzed and few
other factors are exclaimed in this paper.
-N
This paper is organized as follows; Section II providing
an overview and a detailed literature study on the virtualiza-
tion techniques and the process followed in virtualization.
Section III introduces to the developmental workflow of
augmented methodology. Section IV helps in substantiating
ly
the proposed workflow and process using a case-study (viz.
Battery Management System (BMS) V-ECU). Section V
discuss proposed development cycle with benefits of agile
On
development methodologies, Section VI provides improve-
ment matrix from the case study. Section VII details the limi-
tations of method and highlight areas for future enhancement.
Section VIII provide mechanism to for seamless switch
between virtual and physical environment for validation. At
iew
the end, Section IX gives a conclusive note for the method-
ology and the purview of the methodology it can be expressed
into, for further analytical procedures.
ev
II. Literature Survey
Pr
With the increasing complexity of software, next generation
car manufacturers and their suppliers are confronted with the
need to develop models of the electrical and physical parts of
the car at different levels of abstraction. The phases involved
in the development of the algorithm software augmented by
virtualization offers a virtual Hardware in the Loop (vHiL)
solution, which allows simulation of the ECU and coupling it
with external simulators. This scenario waives the need for
elemental hardware requirement. The abstraction of hardware
in virtualization, with the AUTOSAR initiative allows the
reuse of software and opportunity to develop and test the ECU
software before its typical use. Virtualization techniques
supports seamless transition from the need of physical
n
hardware to augmented reality that mimics the physical
hardware. Figure 2 symbolize that a software developed to
tio
run on a Microcontroller can be executed on windows PC and
enables the concept of V-ECU. The concept of V-ECU is to
compile production code to execute on Windows/Linux envi-
ibu
ronment and enable the verification of software integration,
feature behaviour etc. in PC environment.
Katyal et al. [1] proposed the methodology to enable the
modeling of systems based on its functionality and implement
the model as per their selected mechanisms. Thus modeled
s tr
systems were executed and analyzed for data statistics and
compared against the system specifications. This has enabled
them to have accurate design decisions at an early stage of
development process. This was very much in simultaneity with
Di
the traditional SDLC V-cycle.
The consolidation of sophisticated ECUs handling various
features adds an additional overhead and complexity to
software development and testing process. With each ECU
for
accommodated with its own infrastructure and requirements
with regards to functionality and behavior, poses the need for
multiple platforms and toolsets for development and testing.
From among the array of development and testing toolsets
and approaches, further complicating, the obligation for virtu-
alization techniques is considered [2]. The virtualization of
software provides means of re-configuration and scaling.
The combination of hardware and software virtualization
mechanisms, to provide a maximum on flexibility and effi-
ciency was proposed by Pelzl et al. [3]. This methodology offers
a great zeal of considering the increased safety and more
secure application software for vehicles.
While the effort involved in testing the software across
varying software simulation platforms must be minimized.
This inquires the simulation platforms to be reusable and
portable across domains and users. A unified platform is
necessary across the development phases in the traditional
SDLC V-cycle to enable early detection if errors and capture
them for analysis. This being an imperative factor along with
the short turn-around time during execution cycles with a
significant time-to-market process was duly highlighted by
Srinivas et al. [4].
FIGURE 2 Symbolic Representation of a V-ECU
© SAE International.
  STANDARD PROCESS FOR ESTABLISHMENT OF ECU VIRTUALIZATION
Majority of the factors involved during integration valida-
tion with components from different origins, upon integration
has to be validated for their functionalities. Key aspects like
timings, sampling time, execution order, delays etc. are to
be considered within integrated control systems. With their
analysis and the evaluation of their impact on the life-span of
the vehicle has to be identified. This might call for a re-design
of the existing functionality and update a software component
in meeting the standards, needs to be tested aligned to the
process, for integrity. This was proposed by Coelingh et al. [5].
With the virtualization techniques gaining immense
popularity and significant support Gernot Heiser et al. [6]
gives an in-depth overview of the virtualization techniques.
The benefits of the virtualization in embedded systems and
how the environment allows the software to run on a bare
hardware benefits the process is essayed in their proposal.
Virtualization techniques allows the simulation of the
ECUs on the developers’ PC either in the closed-loop (with
Plant model - high-fidelity models) or in open-loop, in order
to speed up the development process. The motivating factor
is that the various runnable corresponding to different
software components could be integrated using virtualization
techniques. The model-based approaches in MATLAB/
Simulink, virtualization techniques and the application
benefits aided in proposal by Yohan Jordan et al. [7].
The parallel process of development, calibrating and
testing the software components of an ECU, aids in a secure
ot
simulation based validations and use physical data measure-
ment data for calibration and simulate along with the high-
fidelity models pays-off through reduction in costs, time and
-N
failure rates. Virtualization helps in timely-integration of
the software components from variant suppliers in the form
of prototypical simulation models. The ease of integration
and increase the number of software components, and
exchange of this platform gives a major push towards virtu-
ly
alization techniques. These techniques can be seamlessly
integrated into the existing development processes and envi-
ronments [8].
On
Virtualization techniques provides a model of real ECUs.
This enables the properties of real ECU visible that can be used
during the simulation on developers PC. This provides key
features like;
iew
1. Zero time execution with all the tasks running
exactly as scheduled.
2. Identify the missing basic software and
its dependency
3. Identification of defects of application software early
ev
in the development phase.
4. Module development in system context
Pr
The methodology was established for Renault with a
framework to develop engine control software for Diesel and
Gasoline engines [9].
Katumba et al. [11] summarized the applicability of agile
methodology in Automotive Software development process.
Here, the agile practices are mapped to mitigate the challenges
faced during automotive development cycle. The challenge
remains to validate an implementation in the same sprint if
validation supposed to happen on HIL.
3
Preubig has summarized various practices of agile scrum
methods in [12]. The methods have been used in software
development industry for long and now being adopted in auto-
motive software industry. Some of these practices have been
n
used in current project execution as highlighted in case study
in later sections.
tio
Critical assessment with integration, validation and test
of all the software components on the developers’ PC using
the virtualization techniques provides viability in capturing
ibu
the errors of the software components during the early stages
in the development process. The developers would able to
assess the behavior of the software components. The need for
the process integration, with virtualization techniques, with
the ever growing complexities of the number of sensors and
s tr
ECUs, it is further possible to shorten testing stages and
significantly reduce the number of dependencies on proto-
types. The extension capabilities of these techniques inte-
grated with the traditional SDLC V-cycle at the organizational
Di
level yields the milestone in testing & validation processes.
III. ECU Virtualization
for & Its Evolution
The technique which isolates the necessity of the bare hardware
and aids in the integration, development and testing of the
application software components, largely, reciprocates to
virtualization. Though, software components are derived from
various model-based tools like Simulink, IBM Rhapsody, etc.,
are represented by the analogy of AUTOSAR architectures.
These software components majorly would be part of the algo-
rithms/applications for a specific vehicle. The virtualization
techniques aided by the sophisticated tools (like Qtronic
Silver, dSPACE VEOS, AVL Model.Connect, etc.) helps in
defining the layers of software in coherence with the
AUTOSAR architecture and define their behavior. There are
some major benefits be fitted with the adaptation of virtualiza-
tion techniques, some of them being;
1. Reduce Dependency: With barely any hardware
resource required to perform testing, typical HIL
dependency is eliminated. The virtual platform/
environment would be with every developer/engineer
to test the developed software component. This would
also allow the developer as well as the test engineer to
test the AUTOSAR application layer/ multiple
software components/ single software component,
individually.
2. Improved Productivity: This aids in improved
productivity by capturing the errors and defunct
behavior of the components early in the development
phase. The capture of anomalies improves
the throughput.
3. Reusability: Aids in the integration of high-fidelity
plant models, between HIL and virtual environment.
The developed virtual environment can be exchanged
through IP, thus ensuring a safe and integrated
exchange of the information between the
development teams.
 4 STANDARD PROCESS FOR ESTABLISHMENT OF ECU VIRTUALIZATION
4. Improved Quality: Rapid prototyping to test new
features. Auto-calibration modules can be tested in
offline modes. Multi-ECU/multi-core ECU with
virtualization of application software and
components of BSW (like CAN, LIN, Flex Ray) can
be virtualized.
With the reformed process definition and integration of
the virtualization techniques in the traditional SDLC V-cycle,
there happens to be a rise in the need to have the process
modified. The modified SDLC V-cycle, very much, considers
the aspects of virtualization streamlined across different
phases that corresponds to the various development and
testing phases in a traditional SDLC V-cycle, as shown in
Figure 3. The ECU being the core component in a vehicle and
place holder for various critical algorithms. Various applica-
tion software components are placed in an ECU.
The modified SDLC V-cycle benefits the development
process with features;
i. Faster development turn-around
ii. Continuous integration capabilities
iii.
iv.
v.
Common environment for developer and test engineer
Reduce the dependency on hardware
Algorithm development
It can be seen in Figure 3, that with the virtualization
ot
techniques the SDLC V-cycle also focuses on the ECU virtu-
alization that is composed of the software architecture design,
software module design, implementation and software code.
-N
The V-ECU implementation encapsulates the software
FIGURE 3 Modified SDLC V-cycle with ECU Virtualization
ly
On
iew
ev
Pr
architecture design, software design and implementation of
the software components with the emphasis on unit testing
and software integration testing, post the success of module
testing for the software component/s. Modified SDLC V-cycle
n
allows timely flow from development to testing phases,
through V-ECU implementation. The component vECU
tio
composition aids in Unit & Coverage testing, while the devel-
opment of individual software components is in the process
of continual development process. System architecture along
ibu
with their implementation and system V-ECU implementation
aids in Integration & Functionality testing. The system
requirements can be captured with high-fidelity Plant models.
Integration of this high-fidelity model with the V-ECU imple-
mentation emphasizes the key features to be tested along with
s tr
the functionality testing.
The functionality of the software components part of the
V-ECU implementation can also be tested, with the software
component tested for its behavior providing suitable stimuli
Di
by means of harness model integrated with the V-ECU. This
kind of testing is very much suitable for the application service
layer in AUTOSAR. While the sophisticated basic software
could be configured or by-passed with the V-ECU implemen-
for
tation integrated with the Plant models allowing the testing
of features set of software components integrated. This would
be in conformance with the system requirements. The process
corresponds to the Requirements-Based testing with the
P­ass-Fail analysis. Testing phases can be performed with the
Plant model in Close-Loop or without the Plant model in
Open-Loop. With emergence of Functional Mock-up
Interfaces (FMI) [10], It’s easier to exchange plant model
between development tools. FMI models, often call FMU
© SAE International.
  STANDARD PROCESS FOR ESTABLISHMENT OF ECU VIRTUALIZATION
(Functional Mock-up units) can easily be integrated with
V-ECU, hence enabling reuse of plant models from various
tools for close loop testing. The high-level overview of Open-
Loop testing is as shown in Figure 4.
The phases in Open-Loop can be differentiated as;
i. Preparatory Phase: Compatible & available tool
selection. Import the software component ARXMLs
in defining the software component architecture.
Validate the architecture of the software components.
ii. Foundation Development Phase: Configuration of
protocols like CAN/LIN/Flex Ray. Generation of RTE
& creation of V-ECU instance.
iii. Integration Phase: Defining the behavior of the
software components by means of importing the
software component code. Importing the common
shared utilities as part of V-ECU instance.
iv. Execution Phase: Creation of test harness for the
provision of stimuli to the V-ECU instance. Creation
of simulation environment, that corresponds to the
virtual environment. Measurement and recording
for analysis.
The process is well-defined for deployment, which includes;
i. Cleaning the system architecture from redundancies.
Also, handle the V-ECU related software component
specific
ot
architecture changes, without disturbing
the environment.
ii. While configuring the communication services like
-N
CAN/LIN/Flex Ray, incorporate dbc (Database)
importing specific processes. Maintain the execution
priorities for each runnable corresponding to
individual software component or multiple software
components. Generation of V-ECU specific RTE and
ly
handle changes related to the same.
iii. Handle the software dependencies for the software
components. Need to handle the hand-code
On
FIGURE 4 High-Level Overview of Open-Loop Testing
iew
ev
Pr © SAE International.
5
modifications (stub or inclusion) to enable the
creation and build of V-ECU implementations.
iv. Check for system dependencies that needs to
be addressed during integration of V-ECU & test
n
harness. Identify and stream-lining of standard test
profiles used to perform Back-to-Back testing.
tio
Definition of a standard test process.
The process for Open-Loop V-ECU implementation and
testing is in relation with the traditional SDLC V-cycle, but with
ibu
additional activities that needs to be performed to keep the
process of V-ECU with virtualization techniques in sync with it.
The extended version of the Open-Loop testing is Closed-
Loop testing. In addition to steps as in Open-Loop testing,
s tr
Closed-Loop testing also includes steps for plant model prepa-
ration and integration with V-ECU. The process phases remain
same, however there are additional steps at each phase. The
high-level overview of the additional steps in Close-Loop
Di
testing is as shown in Figure 5.
This involves the integration of high-fidelity Plant models
modeled using model-based tools like Simulink or from third
party physics modelling tool, as FMU. This kind of simulation
for
yields more realistic and intensive results that corresponds to
the behavior of the system with the software components
integrated, in real-world. The phases in the Closed-Loop can
be differentiated as;
i. Preparatory Phase: Execution of the Plant model in
the virtual environment is performed. Definition and
execution of the test profiles for V-ECU & Plant
models. Integration of V-ECU & Plant model (in case
of Close-Loop) by means of interfaces. (FMI in-case
of FMU for Plant model)
ii. Foundation Development Phase: This phase is more
correlated to the V-ECU implementations &
development of Plant models. Verifying the data-
types of the interfaces, its resolution and units
associated to each data element. Development of the
Plant model with the necessary fidelities included as
part of the Plant model.